Serverless in Practice on AWS: URL Shortener + Realtime Analytics
Build a complete serverless product on AWS from scratch: a URL shortening service with realtime analytics. The series does not teach each service in isolation; it builds one production-ready backend end to end — Lambda, API Gateway, DynamoDB single-table, Cognito, EventBridge, Step Functions, WebSocket API — then operates it for real: idempotency, DLQ, X-Ray tracing, cold start, IAM least-privilege, CI/CD canary, cost analysis and load testing. All infrastructure is built with AWS SAM, code in Node.js + TypeScript, every command run for real on AWS, code at github.com/nghiadaulau/serverless-url-shortener-aws. Grounded in the official AWS documentation.
Step Functions: Orchestrating Multi-Step Workflows and the Saga Pattern
When a process has many steps, branches, and error handling, cramming it all into one Lambda gets messy and hard to read. Step Functions pulls the orchestration logic out into a declarative state machine. Build a link-moderation workflow (safety scan, then activate or reject), with Retry, Catch, and a direct DynamoDB call without Lambda. Covers Standard vs Express, and the saga pattern for undoing a mid-process failure.
Observability: Lambda Powertools and X-Ray Tracing
Start operating like production by being able to see inside. Wire in Lambda Powertools for structured JSON logs and pushed metrics, enable X-Ray to trace which services a request passes through. Read a real trace showing the resolver calling DynamoDB and EventBridge as subsegments, and a log line carrying a trace id to link logs to traces.
CloudWatch: Alarms, Dashboards, and SLOs for the API
With logs, traces, and metrics in place, the next step is knowing automatically when the system has a problem. Define SLOs for the API, build CloudWatch alarms that fire when errors or throttles cross a threshold, gather metrics into a dashboard, and use Logs Insights to compute indicators from structured logs. Push a real alarm into ALARM state by causing a throttle.
Cold Start: Measure It for Real, Then Optimize What's Optimizable
Back to cold start with real numbers. Force a cold start on the resolve handler to see Init Duration and the cost of the first call, then examine the ways to reduce it: more memory (also more CPU), smaller package, SnapStart, and provisioned concurrency — each has its own place, and on the test account one doesn't apply.
Security: IAM Least-Privilege, Throttling, and WAF
Tighten security for the product. Shrink each function's IAM to exactly the actions it needs instead of granting the whole read-write set, set throttling at API Gateway to fight abuse, discuss where to store secrets, and how to attach WAF to an HTTP API. Verify that least-privilege doesn't break functionality, and watch the system shed load when flooded.
CI/CD: Automating Build and Canary Deploy With Rollback
Throughout the series we deployed by typing sam deploy by hand. This article builds CI/CD: a GitHub Actions workflow that builds and validates the template on every push, and deploys safely with canary via CodeDeploy, shifting traffic gradually and rolling back automatically if an error alarm fires. Plus two real traps hit along the way: esbuild missing from the CI PATH, and a circular dependency between the function and the alarm.
The Real Bill: How Much Serverless Costs, and Where It Saves
Opening the real bill of this very product. Cost Explorer shows that building and testing across the whole series cost essentially nothing, because serverless doesn't charge while idle and usage stays inside the free tier. We walk through the pricing model service by service, and point out where design choices in the series cut cost.
Load Testing With k6: Finding the Bottleneck Under Real Load
Throwing real load at the system with k6 and reading how it scales. Firing over 25,000 requests at the link-open path, then cross-checking the k6 results against CloudWatch metrics to find the bottleneck. The numbers point straight at a figure seen many times in the series: the concurrency limit of 10, and show the system sheds excess load fast instead of collapsing.
Capstone: Reviewing Against Well-Architected, Cleanup, and Extensions
The final article of the series. Putting the whole architecture back together, reviewing it through the five Well-Architected pillars to see where each article contributed, walking through a one-command clean teardown, and sketching the next extensions: custom domain, multi-region, and a real dashboard.