Case Study · E-Commerce
Scalable E-Commerce Platform on AWS Lightsail
Well-Architected Design
1. Executive Summary
This case study documents the architecture, design decisions, and operational strategy behind a horizontally scaled e-commerce platform deployed on Amazon Lightsail. The system runs WordPress with WooCommerce across multiple Lightsail instances, fronted by a Lightsail Distribution (CDN) and a Lightsail Load Balancer, backed by a high-availability managed database, and with media offloaded to object storage.
The architecture delivers high availability, edge-accelerated performance, and a defined recovery posture while staying within the cost envelope of a small-to-mid-size e-commerce operation. Every layer aligns with the AWS Well-Architected Framework and establishes a clear migration path as the business scales.
Business Value
Predictable monthly infrastructure cost, no server management overhead, global content delivery, and automated failover — without requiring dedicated DevOps resources.
Key Architectural Decision
Lightsail chosen over EC2 to eliminate networking, AMI, and autoscaling configuration complexity while retaining horizontal scaling via load-balanced instances.
Reliability Posture
Multi-instance deployment behind a health-checked load balancer, HA managed database with automatic standby failover, and daily snapshot-based backup policy.
2. Business Problem
A retail client operating a WooCommerce-based online store experienced recurring problems as transaction volume grew: single-instance deployments became a reliability liability, seasonal traffic spikes caused page timeouts, media assets slowed global page loads, and the total cost of an EC2-based architecture exceeded what the business could justify at its current stage.
Traffic Volatility
Flash sales and promotional events generated 8–12× baseline traffic in under 10 minutes. A single-instance setup had no mechanism to absorb this without manual intervention.
Reliability Risk
A single Lightsail instance with no standby represented a single point of failure for both compute and the database layer. Any instance restart caused full checkout downtime.
Performance Degradation
Product images and WooCommerce assets served directly from the instance created bandwidth pressure and increased time-to-first-byte for users outside the hosting region.
Cost Constraint
An EC2-based architecture with ALB, RDS Multi-AZ, and CloudFront carried a setup and ongoing management cost disproportionate to the business's current revenue and technical team size.
Design Constraints
- No dedicated infrastructure team — architecture must minimise operational burden
- Monthly infrastructure budget ceiling requiring predictable, bundled pricing
- WordPress and WooCommerce are non-negotiable — existing platform, existing plugins
- Recovery time objective (RTO) of under 30 minutes for full platform restoration
- Recovery point objective (RPO) of under 24 hours via automated snapshots
3. Architecture Overview
The system is composed of five tiers: edge delivery, load distribution, compute, data, and storage. Traffic enters at the CDN edge, is distributed across healthy compute instances, processed by WooCommerce, and persisted to a managed relational database. Media assets bypass compute entirely and are served directly from object storage via the CDN.
Why Lightsail Over EC2
EC2 delivers more granular control — custom VPCs, launch templates, autoscaling policies, and fine-grained IAM at the resource level. However, that control carries a configuration and management cost. For a WordPress/WooCommerce workload with a constrained ops team, Lightsail provides the right abstraction: bundled compute, storage, and transfer at a fixed price, with managed load balancing, a managed database tier, and a CDN product — all accessible through a simplified console.
Lightsail's underlying infrastructure runs on the same AWS hypervisors and availability zones as EC2. The trade-off is not in physical reliability — it is in the degree of configurability exposed to the operator. For this workload at this scale, that trade-off is appropriate and intentional.
4. Detailed Architecture Breakdown
Lightsail Instances (Compute Tier)
Each instance runs a pre-configured WordPress blueprint with WooCommerce. A minimum of two instances are deployed and registered with the load balancer, ensuring no single instance failure takes the storefront offline. Instances are sized to a fixed plan balancing memory (WordPress is PHP-memory-intensive), vCPU for request processing, and included transfer allowance.
Best practice alignment: Elimination of single points of failure at compute; consistent known-cost units; snapshots enable point-in-time recovery independent of database backups.
Lightsail Load Balancer
Distributes HTTP/HTTPS traffic across registered instances using round-robin and performs active health checks against a configured path. Instances failing health checks are automatically removed from rotation. TLS termination is handled at the load balancer using a managed ACM certificate.
Best practice alignment: Health-check-driven routing; TLS offloading at compute edge; no single-instance dependency for request handling.
Lightsail Distribution (CDN)
Powered by Amazon CloudFront, sits in front of the load balancer. Caches static assets at edge locations globally, reducing origin load and improving time-to-first-byte for geographically distributed customers. Dynamic WooCommerce requests (cart, checkout) are forwarded to origin uncached via cache behaviour rules that honour session cookies.
Best practice alignment: Edge caching reduces compute pressure; separation of static and dynamic behaviours preserves checkout correctness; global PoP network reduces latency independently of hosting region.
Lightsail Managed Database (High Availability)
HA plan provisions a primary MySQL instance and a synchronous standby replica in a separate availability zone. On primary failure, Lightsail performs automatic failover via DNS endpoint flip — WordPress reconnects without application changes. Automatic backups are retained for a fixed 7-day window (not configurable); manual snapshots persist indefinitely at $0.05/GB-month.
Best practice alignment: Multi-AZ removes the database as a single point of failure; automated backups satisfy RPO requirements; managed patching eliminates a class of operational risk.
Lightsail Bucket / S3 (Media Storage)
Product images and media are offloaded from the instance filesystem to a Lightsail Bucket using a WordPress offload plugin. The Distribution is configured with the bucket as an additional origin for /wp-content/uploads/, serving media from CDN edge rather than compute. This decouples instance storage from the media library and eliminates per-instance disk as a scaling constraint.
Versioning: Bucket versioning is disabled by default and must be explicitly enabled. For a production media library this is required — without versioning, accidental overwrites or deletions are permanent.
Static IP: Each instance must have a Lightsail static IP attached. Without it, stopping and restarting an instance assigns a new dynamic IP, breaking the load balancer's origin connection silently.
Best practice alignment: Stateless compute instances; durable replicated object storage independent of instance lifecycle; reduced bandwidth at compute tier.
5. Request Flow
Browsing Flow
DNS Resolution
Customer's browser resolves the storefront domain to the Lightsail Distribution endpoint.
CDN Cache Check
The Distribution checks its edge cache. Cacheable requests (product pages, static assets) are served directly from the nearest PoP — origin is never contacted.
Cache Miss — Origin Request
On a cache miss, the Distribution forwards the request to the Lightsail Load Balancer as the configured origin.
Load Balancer Routing
The Load Balancer selects a healthy instance via round-robin, excluding instances that have failed health checks.
WordPress Processing
The selected instance runs PHP, queries the Managed Database for product and page data, renders the WooCommerce template, and returns HTML.
Response Caching
The Distribution caches the response per TTL and delivers it to the customer. Subsequent requests for the same resource are served from cache.
Cart & Checkout Flow
Bypass Cache
Cart and checkout requests carry WooCommerce session cookies. The Distribution cache behaviour forwards these to origin uncached — no stale cart state is served from edge.
Session Affinity
The Load Balancer uses cookie-based session stickiness for cart and authenticated sessions, consistently routing a customer to the same instance during the transaction window.
Order Processing
The instance processes the order and writes transaction records to the Managed Database primary node over the private Lightsail network.
Payment Gateway
The instance communicates with the payment processor (Stripe / PayPal) over HTTPS. No payment card data is stored on the instance or in the database.
Order Confirmation
WooCommerce sends the confirmation email, updates the database, and returns the confirmation page to the customer.
Media Delivery Flow
Asset Request
Product image or media asset requested at a URL under /wp-content/uploads/.
CDN Cache Hit
Distribution serves the asset from the nearest edge PoP. No origin contact, no compute consumed.
Cache Miss — Bucket Origin
On a miss, the Distribution fetches the asset directly from the Lightsail Bucket. Compute instances are never in the media delivery path.
Edge Caching
The asset is cached at the edge per TTL and served at CDN speed globally for all subsequent requests.
Failure Handling Flow
Instance Failure Detected
Load Balancer health check fails for Instance A. Instance removed from rotation within the health check interval. All traffic redirected to Instance B.
Database Primary Failure
Managed Database detects primary failure and initiates automatic failover to the standby replica. The DNS endpoint is updated. WordPress reconnects on the next query — no application change required.
Full Instance Restore
New instance provisioned from the most recent snapshot, configured with the Managed Database endpoint, and registered with the Load Balancer. Traffic redistributed once health checks pass.
CDN Serves Stale Cache
During origin unavailability, the Distribution can serve stale cached responses for non-transactional pages, keeping the storefront browsable while compute recovers.
6. AWS Well-Architected Analysis
Security
TLS at the edge: HTTPS enforced at the Distribution and Load Balancer with ACM-managed certificates (auto-renewed every 60–90 days). Note: the Distribution-to-origin connection travels over HTTP by default — TLS terminates at the CloudFront edge, not end-to-end through to the instance.
TLS policy: Load balancer configured with TLS-FS-1-2-Res-2019-08 (TLS 1.2 only, forward secrecy) rather than the default TLS-2016-08 (TLS 1.0–1.2). Only two policies exist in Lightsail — no custom cipher suites are supported.
Managed credentials: WordPress admin credentials and database connection strings stored in AWS Secrets Manager; no plaintext credentials in instance configuration files.
Network isolation: Managed Database has no public endpoint; instances communicate with the database over Lightsail's private network only.
Instance firewall: Inbound restricted to ports 80 and 443; SSH (port 22) restricted to operator IP range only. All other ports blocked by default.
Reliability
No SPOF at compute: Minimum two instances behind a health-checked load balancer ensure one instance failure does not cause downtime.
Multi-AZ database: HA Managed Database provides synchronous standby replication and automatic failover.
Snapshot-based recovery: Daily automated snapshots satisfy the defined RPO. RTO is bounded by snapshot restore time, which is predictable and testable.
CDN resilience: Distribution continues serving cached content from edge even if origin experiences transient degradation.
Performance Efficiency
Edge delivery: Distribution serves static and media assets from the nearest CloudFront PoP, reducing latency for global customers independently of instance location.
Origin offload: Effective cache configuration reduces the volume of requests reaching compute, allowing the instance fleet to handle higher concurrency without vertical scaling.
Media decoupling: Offloading media to object storage eliminates instance I/O pressure, keeping PHP execution resources available for WooCommerce processing.
Cost Optimization
Predictable bundled pricing: Lightsail's fixed monthly plans bundle compute, storage, and transfer — eliminating surprise billing from data transfer overages common in EC2 architectures.
Right-sizing simplicity: Plan tiers make right-sizing straightforward; plans can be upgraded with a snapshot-and-restore operation.
Reduced ops cost: Managed database, load balancer, and CDN eliminate engineering time associated with configuring equivalent services in EC2/VPC.
Operational Excellence
Snapshot discipline: Automated instance and database snapshots are tested periodically by performing a restore-and-verify cycle, confirming recovery procedures before they are needed.
Runbook documentation: Post-deployment runbooks cover instance replacement, database failover validation, CDN cache invalidation, and snapshot restore procedures.
CloudWatch integration: Lightsail metrics (CPU, connection count, burst capacity) surface in CloudWatch and trigger alarms on HealthyHostCount, InstanceResponseTime, and burst capacity before resource exhaustion occurs.
Sustainability (6th Pillar)
Managed infrastructure: Lightsail's managed primitives (load balancer, database, CDN) run on shared AWS infrastructure with higher hardware utilisation across many tenants — a more efficient environmental footprint than equivalent dedicated EC2 resources at this scale.
CDN edge offload: Serving static and media assets from CloudFront edge rather than origin compute reduces the number of origin compute cycles per request — a measurable reduction in energy per page view.
Right-sizing: Fixed Lightsail plan tiers enforce intentional right-sizing. Oversized instances consume power without productive output — plan selection should target 60–70% average CPU utilisation.
Storage lifecycle: Enabling Lightsail Bucket versioning combined with a cleanup policy for obsolete media versions reduces unnecessary storage consumption and the associated energy footprint of replication.
7. Security Design
Network Security
- Instance firewall: inbound 443/80 from anywhere; SSH (22) restricted to operator IP range only
- Database firewall: no public endpoint; accepts connections from Lightsail private network only
- Load balancer handles public TLS termination — instances never receive raw internet traffic directly
- Distribution enforces HTTPS-only; HTTP requests redirected to HTTPS at the edge
Data Encryption
- Data in transit: TLS terminates at the CloudFront edge (Distribution); the Distribution-to-origin leg travels over HTTP by default — end-to-end encryption to the instance is not provided by Lightsail without additional configuration
- Data at rest: Managed Database encrypts storage volumes at rest by default
- Lightsail Bucket storage encrypted at rest; object access controlled via bucket permissions
- No payment card data stored in the database — payment processing scoped to gateway integration
Access Control
- WordPress admin access restricted to allowlisted IPs via the instance firewall
- Database credentials managed via Secrets Manager — rotatable without instance redeployment
- IAM role scoped to Secrets Manager read-only; no broad AWS access granted to instances
- SSH keys managed per operator; no shared or long-lived root credentials
Edge Protection
- Lightsail Distribution inherits CloudFront DDoS protection (AWS Shield Standard) at no additional cost
- Rate limiting and bot mitigation applicable via CloudFront-compatible WAF rules at the distribution layer
- WordPress hardening: wp-login.php access restricted; XML-RPC disabled; security plugin installed
8. Scalability Strategy
Lightsail does not provide native auto scaling. Horizontal scale-out is a manual or semi-automated operation: a new instance is created from a snapshot, configured to connect to the shared Managed Database endpoint, and registered with the Load Balancer. This process can be completed in under 10 minutes from a current snapshot.
The CDN layer provides a significant scaling multiplier. By absorbing static and media traffic at the edge, the effective origin request rate is substantially lower than the raw traffic figure. A well-tuned cache hit ratio of 80–90% means the instance fleet handles only 10–20% of total requests — making horizontal scale-out a less frequent operational requirement.
Horizontal Compute Scale-Out
Add instance → restore from snapshot → configure DB connection → register with load balancer → validate health check. Approximately 8–12 minutes. No DNS change required.
CDN Scaling Multiplier
CloudFront-backed Distribution scales automatically and absorbs the majority of traffic at the edge. Origin scaling requirements are a fraction of total user concurrency.
Database Vertical Scaling
Managed Database can be scaled to a larger plan via snapshot-and-restore. For read-heavy workloads, a read replica can be added and WordPress configured to route SELECT queries accordingly.
9. Reliability & Disaster Recovery
Recovery Objectives
- RTO (compute): <15 minutes — restore from snapshot, register with load balancer
- RTO (database): ~1–2 minutes — automatic HA failover to standby (AWS RDS Multi-AZ baseline; Lightsail does not formally document a specific SLA)
- RPO: <24 hours — daily automated snapshots; promote automatic snapshot to manual for indefinite retention
- RTO (full platform): <30 minutes — combined instance and database restore
Multi-AZ Strategy
- Managed Database HA plan: primary and standby in separate availability zones
- Automatic failover initiated by Lightsail on primary node failure
- DNS endpoint remains constant — application reconnects transparently
- Lightsail instances can be distributed across AZs for compute HA
Snapshot Policy
- Daily automated snapshots of all instances and the Managed Database
- Automatic snapshot retention: fixed 7-day rolling window — the 8th snapshot replaces the 1st; this is not configurable
- Manual snapshots: stored indefinitely until explicitly deleted at $0.05/GB-month; promote any automatic snapshot to manual for long-term retention
- Cross-region copy: use aws lightsail copy-snapshot --target-region to replicate to a second region for DR (CLI/API only)
- Disk automatic snapshots: accessible via CLI/API only — not available through the Lightsail console
- Snapshot restore tested on a schedule to validate RTO assumptions
Health Check Configuration
- Load balancer polls each instance health check path every 30 seconds (fixed — not user-configurable)
- Health check path is configurable; use a lightweight dedicated path (e.g. /health) rather than the homepage to avoid slow asset-heavy responses skewing results
- Lightsail does not publicly document healthy/unhealthy threshold counts — configure CloudWatch alarms on HealthyHostCount and UnhealthyHostCount metrics for detection
- CloudWatch alarm triggered on HealthyHostCount = 0 as a critical failsafe
10. Cost Optimization Strategy
Lightsail's pricing model bundles compute, SSD storage, and data transfer into a fixed monthly plan. This predictability is a meaningful advantage for a small e-commerce operation where variable EC2 billing — particularly data transfer at scale — can produce unexpected cost events.
| Component | Lightsail | Equivalent EC2 Architecture |
|---|---|---|
| Compute | Fixed plan (e.g. $10–20/mo per instance) | On-demand or Reserved EC2; variable with instance type |
| Load Balancer | $18/mo fixed | ALB: $0.008/LCU-hour + $0.018/hour; variable |
| Database | Fixed HA plan (e.g. $60–100/mo) | RDS Multi-AZ: instance + storage + I/O charges |
| CDN | $0/mo (included with Distribution transfer) | CloudFront: $0.0085–0.12/GB by region |
| Data Transfer | Included in plan allowance; overage $0.09/GB | EC2 egress: $0.09/GB from first byte |
| Management Overhead | Low — managed DB, managed LB, managed CDN | High — VPC config, SG rules, parameter groups, lifecycle policies |
11. Trade-Offs & Limitations
Architectural honesty is a component of good design. The following limitations are understood, accepted given the current scale, and inform the migration path in the next section.
| Area | Lightsail Constraint | EC2/RDS/ECS Alternative | Accepted Trade-Off |
|---|---|---|---|
| Auto Scaling | No native autoscaling; scale-out is a manual or scripted operation | EC2 Auto Scaling Groups with scheduled or metric-based policies | Acceptable at current traffic profile; CDN absorbs spikes at edge |
| Networking Control | No custom VPC, no fine-grained subnet routing, no VPC peering | Full VPC with private subnets, NACLs, Transit Gateway | Acceptable; Lightsail private network provides adequate isolation for this workload |
| Database Flexibility | Managed DB limited to MySQL/PostgreSQL; no Aurora, no deep parameter groups | RDS with full parameter group control, Aurora Serverless v2 | WooCommerce's MySQL requirements are fully satisfied by Managed DB |
| CDN Customisation | Distribution exposes limited CloudFront config; no Lambda@Edge | Native CloudFront with full behaviour rules, Lambda@Edge, Functions | Standard cache behaviour rules cover WooCommerce requirements |
| Architecture Pattern | Monolithic WordPress/WooCommerce on each instance | Decoupled microservices via ECS/Fargate or Lambda backends | WordPress is inherently monolithic; decomposition requires replatforming |
| IAM Granularity | Lightsail has limited native IAM resource-level policy support | Full IAM with resource conditions, SCPs, permission boundaries | Acceptable for single-team usage; constraint grows in multi-team or compliance environments |
12. Evolution & Migration Path
This architecture is the appropriate starting point, not the destination. The following evolution stages are sequenced to match business growth milestones, each triggered by a specific scaling or capability constraint rather than arbitrary technical preference.
Stage 1 → EC2 + Auto Scaling (Trigger: traffic unpredictability requiring automated scale-out)
Export Lightsail instance to an AMI. Deploy an EC2 Auto Scaling Group behind an Application Load Balancer within a custom VPC. Migrate the Managed Database to RDS MySQL Multi-AZ. Migrate the Distribution to a native CloudFront distribution with full behaviour rule control.
- Gain: Metric-based and scheduled auto scaling; VPC-level network segmentation; RDS parameter control
- Cost: Higher baseline cost; engineering time for VPC, SG, and ALB configuration
- Trigger: Traffic spikes regularly exceed manual scale-out response time
Stage 2 → Containerised WordPress on ECS/Fargate (Trigger: multi-environment deployment and release velocity requirements)
Package WordPress into a Docker image with configuration injection via environment variables and Secrets Manager. Deploy on ECS Fargate behind an ALB. Store persistent media in S3 and database state in RDS Aurora MySQL.
- Gain: Zero server management; immutable deployments; horizontal scaling via Fargate task count
- Cost: Higher per-task cost than Lightsail plans for low concurrency; justified by deployment velocity gains
- Trigger: Deployment frequency increases; WordPress instance configuration drift becomes a management problem
Stage 3 → Headless / Serverless Commerce (Trigger: performance requirements exceeding WordPress as a monolith)
Decouple the WooCommerce backend (REST API / WPGraphQL) from the frontend. Deploy a Next.js storefront on CloudFront with static generation and ISR. Backend API calls routed to Lambda functions or ECS tasks. WooCommerce used as a headless commerce engine rather than a templated monolith.
- Gain: Sub-second global page loads via static generation; independently scalable API layer
- Cost: Highest complexity and engineering investment; justified only when WordPress template rendering is a measurable constraint
- Trigger: Core Web Vitals are a competitive differentiator; team has frontend capability for replatforming
13. Positioning Statement
This architecture shows that high availability, edge-accelerated performance, and a defensible recovery posture do not require EC2 as a starting point. By selecting the right level of abstraction for the workload's current scale, Lightsail's managed primitives deliver measurable reliability at a lower total cost of ownership, with a documented migration path that preserves optionality as the business grows.
Every architectural decision in this design is a deliberate trade-off, not a simplification. The constraints of Lightsail are understood, quantified, and accepted at this stage. The evolution path is defined not as aspirational future work, but as a sequenced response to specific, identifiable business and technical triggers.