How a Request Actually Flows Through AWS (A Beginner's Mental Model)

Before you can reason about AWS, you need a mental model of what happens between a click and a response. Here's how I walk through a basic AWS architecture diagram — DNS, CDN, storage, compute, and database — using plain-language analogies that hold up as a starting point, not a finish line.

Start With the Diagram, Not the Definitions

Whenever I'm introducing someone to AWS, I resist the urge to start with a glossary. "Route 53 is a DNS service." "CloudFront is a CDN." "RDS is a managed relational database." Those definitions are all technically correct, and they're also completely useless if you don't already know what a DNS service or a CDN does in practice.

What actually works, in my experience, is tracing a single request from the moment someone types a URL to the moment they see data on their screen. Every stop along that path corresponds to a real AWS service, and once you can picture the path, the vocabulary attaches itself naturally instead of needing to be memorized.

So that's what I want to walk through here: one request, five stops. I'll use some rough analogies to get the shape of the system into your head first. They're simplifications — useful for building intuition, not a substitute for the actual documentation once you're implementing something for real. I'll flag where that distinction matters as we go.

The Address Lookup: Route 53

The first stop isn't really part of "the app" at all — it's the internet figuring out where your app even lives. That's Route 53's job. I think of it like looking up an address to find a specific post office box: you type a domain name, and Route 53 translates that human-readable name into the actual network location where your infrastructure sits.

It's a small step, and it happens before any of your own code runs. But it's worth pausing on because it establishes the pattern for everything that follows: the user never needs to know the technical location of anything. They ask for a name, and a service resolves it for them. That's the first example of a theme that shows up again and again in AWS: something abstracts away a lookup or a routing decision so you don't have to think about it.

The Front Door: CloudFront

Once the address resolves, the request arrives at what I like to describe as the front door of the application — that's CloudFront. A good front door doesn't just let people in; it figures out what they actually need before deciding where to send them. CloudFront does something similar: it looks at the incoming request and decides how the content should be served.

This is the point in the diagram where the story splits into two paths, and the split is the most important conceptual idea in the whole walkthrough. Some requests are for content that already exists — a video that's already been rendered, an image, a static page. Other requests need something to be computed on the spot — checking a password, pulling a record that might have changed a second ago. CloudFront is the layer that helps route between those two realities, and understanding that split is what makes the rest of the diagram click.

When Nothing Needs to Happen: S3

If the request is for something that already exists — say, a video someone previously uploaded — it gets served out of S3. I find it useful to think of S3 as a big, flat storage container that can hold basically any kind of file: video, images, text, whatever. Nothing about serving that file requires computing anything, because the content was already created ahead of time. That's why CloudFront and S3 work well together: CloudFront caches and delivers what's sitting in S3, and the user gets it without lag or buffering.

The way I usually frame this to beginners is that S3-served content lives entirely outside the compute layer — no application server, no virtual private cloud, none of that machinery gets involved. That's a genuinely useful simplification for a first mental model, and it holds for a lot of straightforward static-content cases. I'll add one caveat, though: it's a simplification. Depending on how a bucket is configured, you can still have things like signed URLs, access policies, or edge functions layered on top of that delivery path, so treat "S3 needs zero compute, ever" as the beginner's version of the rule rather than an ironclad technical guarantee. It's the right mental model to start with; just don't assume it's the whole story once you're actually building something with access control or dynamic transformations involved.

When Something Needs to Happen: Load Balancers and Availability Zones

The other branch is more interesting, because it's where actual computation enters the picture. Say a user wants to change their password. That's not something you can hand back from a static file — something needs to run, check state, and produce a result. I'll admit up front that a password change is a slightly far-fetched example for this specific diagram, and it's worth being explicit about why: real authentication flows typically go through dedicated identity services rather than touching passwords directly in the way this simplified walkthrough implies. I'm using it here purely because it's a request everyone intuitively understands as "something has to actually happen," not because it reflects how credential handling actually works under the hood.

What happens next, in the diagram, is that the request hits a load balancer, which distributes it across availability zones — physically separate data center clusters designed so that a problem in one doesn't take down the whole system. As a first mental model, it's fair to say the load balancer decides which availability zone handles a given request, and the user never has to know or care which one they landed on. That's the useful takeaway for a beginner. The actual mechanics of how traffic gets distributed and how failover works between zones are more nuanced than "the load balancer picks a zone," so if you're the kind of person who wants to go one layer deeper, that's a good next thing to read up on rather than something to take as fully settled from a single diagram.

The Database Layer, and Why Everything Is 'a Service'

The last stop is the database layer — the place where structured information actually lives, the kind of thing you'd historically associate with a SQL or Oracle-style database. In this diagram, that's represented by RDS, which stands for Relational Database Service.

That name is doing a lot of work, and it's honestly the detail I most want people to walk away remembering. RDS isn't the database — it's the thing that manages the database for you. It handles provisioning, patching, backups, failover, all the operational overhead that used to require a dedicated database administrator. You still get a real relational database underneath, but AWS is selling you the management layer on top of it.

Once you see that pattern in RDS, you start noticing it everywhere in AWS's naming. A lot of these products are named for the service they provide around a piece of technology, not the technology itself. I want to be careful about how strongly I state that, though — it's a genuinely useful lens for reading AWS product names, but it's a generalization, not a rule that's been checked against every single service AWS offers. Treat it as a heuristic that will serve you well most of the time, not a guarantee that holds for literally every acronym in their catalog.

Still, as a closing idea, it's the one I'd want to stick: almost everything in AWS is, at its core, a manager of something — compute, storage, routing, database operations — packaged as a service so you don't have to run that thing yourself. Once that idea is in your head, new AWS products stop feeling like a wall of unfamiliar acronyms and start feeling like variations on a theme you already understand.

Conclusion

That's the shape of the diagram: an address lookup, a front door, a fork between static content and real computation, and a database layer humming underneath it all. None of these explanations are meant to be the final word on how any of these services work — they're scaffolding, meant to hold up long enough for the more precise, more technical version to make sense later. If you want a genuinely good next step, take a request your own app handles and try to sketch which of these five stops it actually touches. You'll probably find it clarifies which pieces you understand solidly and which ones are worth reading the real documentation for.