AWS gives eCommerce teams everything they need to run reliably at scale — and everything they need to build an expensive, overcomplicated system nobody fully understands. The difference is restraint. Good commerce infrastructure on AWS is usually boring.
What commerce workloads actually need
An eCommerce platform has a specific load profile: sustained moderate traffic, sharp campaign peaks, an uncacheable checkout path, and a database that matters more than everything else. Infrastructure should be designed around these facts, not around service catalogs.
The baseline that works
- Compute behind an autoscaling group or containers (ECS) — stateless PHP application servers that scale horizontally, session state in Redis, never on the instance
- RDS/Aurora for MySQL — managed backups, failover and patching; read replicas only after read/write patterns justify them
- ElastiCache for Redis — sessions and cache, sized deliberately with a defined eviction policy
- CloudFront in front of everything — assets and cacheable pages served at the edge; origin traffic shrinks dramatically
- SQS or Amazon MQ — asynchronous work out of the request path
Where the money leaks
The recurring cost findings in our reviews: instances sized for last year’s peak running 24/7, environments nobody uses, cross-AZ traffic from unpinned service placement, and logs stored forever at premium tiers. Rightsizing plus scheduled scaling routinely cuts 30–40% of spend without touching performance.
Reliability comes from simplicity
Every additional service is an additional failure mode, IAM surface and upgrade obligation. A commerce platform does not become more reliable by using more of AWS — it becomes more reliable when the team can draw the whole architecture on a whiteboard and explain what happens when each box fails.
Takeaway
Design for your actual load profile, keep the component count low, and measure cost as an engineering metric. Boring infrastructure is what lets you sleep during campaigns.
