Serverless E-commerce Platform on AWS

Problem

Small e-commerce operators waste money running EC2 fleets that sit idle 80% of the day, then fall over during sales spikes. I wanted a reference architecture that costs almost nothing at zero traffic and absorbs bursts without manual scaling.

Solution

A fully serverless backend: API Gateway routes requests to Lambda functions written in TypeScript, which read and write product, cart and order data in DynamoDB. The static storefront is built once and served from S3 behind CloudFront with edge caching, so 90% of read traffic never reaches the origin. Authentication and authorization use Cognito + IAM scoped roles per Lambda — no shared secrets, no long-lived credentials.

Architecture

• ▸CloudFront edge caches the static SPA hosted on S3 (TTL tuned per asset class).
• ▸API Gateway with HTTP API mode forwards to per-resource Lambda functions.
• ▸DynamoDB single-table design with GSIs for product lookup and order history.
• ▸Cognito user pools issue JWTs; API Gateway authorizers validate them.
• ▸CloudWatch + X-Ray trace every request end-to-end for cold-start tuning.

Outcomes

• ✓Idle cost ≈ $0/month — only S3, DynamoDB on-demand, and CloudFront pay-per-request.
• ✓Cold start p95 brought under 400 ms by trimming bundle size and using provisioned concurrency on the checkout function only.
• ✓Single-table DynamoDB design replaced what would have been 4–5 RDS tables, cutting query latency to single-digit ms.

What I'd do differently

Serverless is cheaper at small scale, but only if you treat IAM, observability and cold starts as first-class concerns from day one. Single-table DynamoDB design is unforgiving of schema drift — invest in modelling before code.