Serverless web app on AWS
CloudFront serves the site from S3 and sends API calls through API Gateway to Lambda functions backed by DynamoDB.
Click any box to open its page. Open it in the playground to rewire it, change the traffic or take parts down.
A web app with no servers to patch and almost no cost when nobody is using it. Static files (HTML, JavaScript, images) sit in S3 behind CloudFront’s cache. API calls go through API Gateway, which checks and throttles them, to Lambda functions that start on demand and keep their state in DynamoDB. Every piece scales by itself, and you pay per request.
How it flows
- 1
The page comes from the edge
A browser asks CloudFront for the site. Most files are already cached at the edge location nearest the user; on a miss, CloudFront fetches them from the S3 bucket and keeps a copy.
- 2
API calls are checked first
Calls to the API’s own domain go to API Gateway, which validates the user’s token and enforces rate limits before any of your code runs. Requests over the limit get a
429.UsersAmazon API Gateway - 3
Lambda runs your handler
Each call runs a Lambda function. If no instance is free, Lambda starts a new one (a cold start, from under 100 ms to over a second); idle instances are reclaimed after a while.
- 4
State lives in DynamoDB
The function reads and writes items in DynamoDB, which answers in single-digit milliseconds at any scale. Because functions keep nothing between calls, any instance can serve any request.
Why this shape works
- Close to zero cost at zero traffic, and no servers or capacity to manage
- Each layer scales independently and automatically, from one request a day to thousands a second
- The CDN absorbs most page traffic and keeps static files close to users
- Security boundaries are explicit: the gateway authenticates, IAM controls what each function may touch
Where it strains
- Cold starts add latency to the first requests after a quiet spell or during a burst
- Lambda’s 15-minute limit and stateless model don’t suit long jobs or persistent connections
- DynamoDB rewards designing tables around your access patterns up front; ad-hoc queries are awkward
- At steady high traffic, per-request pricing can cost more than a few always-on containers
Common swaps
Prefer SQL? Put PostgreSQL behind the functions, with a connection pooler so bursts of Lambdas don’t exhaust its connections.
For steady traffic or long requests, run the API as containers on Fargate behind a load balancer instead of Lambda.
Off AWS, the same shape is Cloudflare in front of Workers and R2, or Cloud Run behind Google’s CDN.
Built from
Amazon CloudFrontAWSCDNsAWS’s CDN: more than 750 edge locations that cache your S3 files and front your load balancers and APIs.
Amazon S3AWSObject storageAWS’s object storage, and the de facto API most object stores copy.
Amazon API GatewayAWSAPI gatewaysAWS’s managed API front door: REST, HTTP and WebSocket APIs that authenticate, throttle and route calls to Lambda and other backends.
AWS LambdaAWSServerless functions (FaaS)AWS’s functions service: upload a handler, connect a trigger, and pay per request and per millisecond.
Amazon DynamoDBAWSKey-value storesAWS’s serverless key-value and document database, with single-digit-millisecond reads at any size.