I have a confession that will sound strange for someone studying cloud.
I know what Lambda does. I can tell you what S3 is, what DynamoDB is, what API Gateway is for. I have made flashcards for all of them. And for months I thought that was progress.
Then I sat down to design something. A simple problem, the kind that shows up in every interview. And the flashcards were useless. I knew the definitions. I had no idea when to use the services, why they fit together, or what I was giving up by choosing one.
That gap is the real subject of this piece. Knowing what a service does and knowing when to use it are two different skills. The second one is the one that gets people hired.
The wrong map: AWS as a list
AWS has over 200 services. When you are starting out, the obvious strategy is to treat them like a vocabulary list.
EC2 does this. S3 does that. Lambda is serverless. Pass the exam, get hired.
That strategy worked for a while. It still works if your only goal is a certification. But it collapses the moment the problem stops being "name the service" and becomes "design the system."
Here is what I kept noticing in interview prep content and practice sessions: people can rattle off what services do, then freeze when asked to combine them. Because a business brief does not arrive as a list of services. It arrives as a problem. A startup about to go viral. A store that crashes on its biggest day. A bank drowning in documents.
The better map is not a longer list. It is a way of walking through any problem so the services show up because the problem demands them.
The decision stack
Every cloud architecture can be read through six layers. I keep the names simple:
Traffic: how users reach the system, how fast content arrives, how services talk to each other.
Compute: where the actual work happens when a user clicks, submits, or uploads.
Data: where information is stored, how it flows, and whether services wait for each other or work from queues.
Security: who is allowed to do what, at every level, from the start.
Cost: what this costs now, and how easy it is to change when requirements change.
Observability: how you know the system is healthy before your users do.
That is the whole framework. Six layers. You can walk into a problem you have never seen and know where to start, because the layers give you the questions.
The rest of this piece is the proof. Three businesses, three completely different architectures, the same six layers.
Scenario one: the startup about to go viral
Brief: a startup runs everything on one server. A thousand users are fine. A marketing campaign is about to bring 100,000 users in a weekend. The budget is nearly zero.
The problem is not "we need more servers." The problem is: the architecture cannot scale, and they cannot afford capacity they are not using. Two failures in one sentence.
Traffic layer. Right now the domain points straight at the one server. Everything passes through it: files, code, database, all of it. The first move is to stop treating the server as the front door. Route 53 points the domain at CloudFront, which serves content from edge locations around the world. The static files, the images, the page layout, move to S3, which costs almost nothing compared to a server doing the same job. A web application firewall filters bots and scrapers at the edge, before they reach anything behind it.
Compute layer. The server no longer delivers files. Now it only handles user actions. But one server still cannot handle 100,000 signups. Lambda replaces it: code that runs when an event happens, scales automatically, and costs nothing when nobody is using the app. API Gateway sits in front of it as the public address that routes each request to the right function.
The trade-off gets named honestly. Lambda has cold starts, a delay when the runtime spins up after idle. For a signup form, the user has already spent seconds reading the page. A few hundred milliseconds is noise. For a real-time trading system or a multiplayer game, it is not. The question is never "is Lambda good" but "does the latency matter for this specific application."
Data layer. DynamoDB stores the accounts. It is a key-value database, fast, single-digit milliseconds. The real reason it fits here is capacity. It has two modes: on-demand and provisioned. On-demand means you pay per request and never plan capacity. Provisioned means you guess reads and writes per second in advance. This startup has no usage history. Nobody knows if the campaign brings 5,000 signups or 50,000. Guessing low breaks the app. Guessing high wastes money they do not have.
So we start on-demand. Later, with real data, we can switch to provisioned and save money. The database does not change. The capacity model matches what we actually know. Do not optimize around a guess.
Security, cost, observability. IAM gives each service a key card that opens only the doors it needs. The signup function can write to DynamoDB and nothing else. The S3 bucket can be read by CloudFront and nothing else. Cost follows usage: near zero when quiet, exact when busy, instead of a server billing the same every hour whether it has 10,000 users or zero. CloudWatch collects metrics, and alarms fire when Lambda errors spike or the database throttles.
One weekend. 100,000 users. And a bill that mostly disappears when the campaign ends.
Scenario two: the store that crashed on Black Friday
Brief: a mid-size e-commerce company runs several servers behind a load balancer and one database, all in a single availability zone. On Black Friday, traffic tripled in two hours and the site died. They estimate $50,000 per hour of downtime.
This brief looks similar to the first one. It is not. And the difference is a senior skill: reading the brief before fixing anything.
Not every detail in a brief is a problem. The single availability zone did not cause this crash. The load balancer did not cause it either, and this is the part most people miss: a load balancer spreads traffic across the servers that already exist. It does not create new servers. Traffic tripled, every server overloaded, and the load balancer had nowhere to send requests. That is the crash.
Compute layer. The fix is an Auto Scaling Group. Define a rule: when average CPU crosses a threshold, launch new instances; when it drops, remove them. The load balancer checks health and only sends traffic to servers that pass. That alone would have handled Black Friday: capacity appears as demand rises and disappears after.
Lambda does not fit here. The store runs a real application with long-running processes and dependencies that need a full server environment, and Lambda caps out at 15 minutes per execution. EC2 stays. We fix how capacity is managed, not what the servers are.
Availability zones. The crash was a capacity problem, not a data center failure. But for a revenue system losing $50,000 an hour, one zone is still not a production design. We spread the load balancer and the server fleet across two zones. If one zone fails, traffic keeps flowing to the other. We do not overcorrect into multi-region. That complexity is not earned yet.
Data layer. When the servers drowned, the database drowned too. Connections piled up and the database stopped responding. That does not prove the database is broken. It was a chain reaction. Fix the fire before you redecorate the kitchen: stabilize compute first, then investigate whether queries, indexes, or sizing have their own problems.
One improvement is worth making while we are here. The RDS database handles complex queries across connected data: orders, customers, revenue reports. But inventory lookups, stock level by product ID, are simple and constant. They do not need joins or reports. Adding DynamoDB for inventory separates the two workloads. The tool matches the access pattern, not the other way around.
Cost. The company was running oversized servers all year out of fear of the next spike. That is paying for Black Friday 365 days a year. The baseline, sized for a normal Tuesday, gets a Savings Plan: committed pricing for servers you will run anyway. The burst capacity from autoscaling stays on-demand. Committed for the steady state, on-demand for the spike.
Observability. They found out the site was down from customer complaints on social media. That is the definition of no monitoring. CloudWatch tracks servers, errors, database connections, scaling events. The dashboard also tracks business metrics: orders per minute, checkout conversion. The CTO does not think in CPU. They think in revenue. CloudTrail records who changed what configuration, so the next post-mortem is not a guessing game.
Same five user steps, whether a thousand people shop or a hundred thousand.
Scenario three: the bank automating documents
Brief: a financial services company has 40 people reading contracts, compliance reports, and filings by hand, extracting the key information, and routing it to the right department. It is slow, expensive, and error-prone.
No website. No public users. No spike. The traffic here is documents.
Traffic layer. Documents land in S3. But a document should not immediately trigger processing. At 9 a.m. on a Monday, 200 reports arrive at once. Without a queue, all 200 try to process simultaneously, and you pay for peak capacity all day. SQS holds a message for each document. The processing side pulls messages at its own pace. This is decoupling: the upload side and the processing side never need to know about each other.
Compute layer. Lambda is tempting and wrong. Documents run dozens of pages, AI analysis takes time, and the 15-minute limit can cut the job off mid-process. Lambda also spins up and down per document, paying setup overhead thousands of times a day. Instead, ECS on Fargate runs a container continuously. It sits there pulling from the queue, keeping its connections warm, processing one document after another. When the queue builds up, more containers start. When it drains, they stop. You pay for the capacity you actually need.
The AI step. The container calls Amazon Bedrock through private VPC endpoints, not the public internet. This is a regulated industry; the data does not leave the private environment. But a general model is not enough. The company has its own compliance frameworks, routing rules, and deadlines. General knowledge cannot apply them. Retrieval augmented generation, RAG, pulls the relevant internal context and sends it with the document. The model gets the contract plus the company's rules. That is the difference between AI that works in a demo and AI that replaces a manual workflow.
Data layer. Results go into Aurora, one database for the whole processed-document pool. Legal searches by client name. Compliance runs reports across thousands of documents. Same data, different questions, one database to manage and secure. The original files stay in S3 with versioning, so nothing is ever lost. Lifecycle rules move old documents to cheaper storage after 90 days and deep archive after a year.
Security. The containers can do exactly three things: read documents, read the queue, call Bedrock. They cannot write to the database. Writes happen through a separate control process. The thing that handles untrusted documents must not hold the keys to production data. Everything is encrypted, and CloudTrail records every API call for the audit trail.
Cost. The business case is calculable before you build: cost per document, compute time, storage, queue messages. A fraction of 40 salaries, with fewer errors and faster turnaround. A billing alarm catches a stuck container retrying a broken document before it runs up a bill.
Observability. The business dashboard has one number: documents processed per hour. That is what proves the system is doing the work 40 people used to do.
The pattern underneath
Three businesses. Three architectures. One set of questions.
Every time, the work started with the problem, not the service. Every time, the layers decided the architecture. And every time, the answer included a trade-off stated out loud: Lambda versus containers, on-demand versus provisioned, one database versus two, fix the fire before redecorating the kitchen.
That last line is the discipline. When the store crashed, the temptation is to rearchitect the database. The honest move is to fix the capacity problem first and measure what is left. When the bank wants AI, the temptation is to throw a model at the documents. The honest move is to design intake, queueing, permissions, and cost before the model ever runs.
The walk-the-brief routine
This is the routine I use now on every practice brief:
Name the problem in one sentence, including what happens if it is not solved. No services allowed yet.
Walk the six layers. Traffic first, then compute, then data. Security, cost, and observability are not afterthoughts; they shape the choices above them.
For each layer, pick one option and state the trade-off. If you cannot name what you are giving up, you have not chosen yet.
Check the failure mode. What happens when each component dies? Does anything become a single point of failure?
Only then touch a service name.
The exam asks what Lambda does. The interview asks when Lambda is the right call and when it is not. The first question tests memory. The second tests judgment.
I failed the second question for a long time, because I was studying for the first one.
The changed lens
AWS is not a list of 200 services. It is a stack of decisions. Traffic, compute, data, security, cost, observability. Run any problem through those six layers and the services stop being vocabulary and start being answers.
The flashcards were not wasted. The definitions matter. They just were not the skill. The skill is standing in front of a blank page with a business problem and knowing where to start. That is the part that gets hired, and it is the part you can practice every single day with nothing but a brief and six questions.