AWS: Zero to Hero — Week 2: What's Actually Underneath AWS
Week 2 of learning AWS from zero, with Claude as my research partner. This time: where AWS infrastructure actually lives, physically. Regions and Availability Zones as deliberately isolated blast-radius boundaries, Edge/Local/Wavelength Zones explained, and a deep look at the Nitro System, the hardware that offloads virtualization off the host CPU so EC2 performs like bare metal.
Series: AWS: Zero to Hero (9 articles)
- 2AWS: Zero to Hero — Week 2: What's Actually Underneath AWS This article
Last week was about what "the cloud" means as a concept — on-demand capacity, virtualization as the enabling idea, the economics behind why it took off. This week I wanted to go one level more literal: when AWS says your data "lives in the cloud," where does it actually, physically live? And when your EC2 instance (An EC2 instance is a virtual server provided by Amazon Elastic Compute Cloud (EC2), a core service of Amazon Web Services (AWS) that allows users to rent scalable computing power in the cloud. Instead of investing in physical hardware, you can launch these resizable instances to run applications, host websites, or process data, paying only for the compute time you use) boots up, what's really happening on the hardware underneath it?
Turns out the answer has two layers — one about geography, one about a single physical server — and both exist for the same underlying reason: isolating failure.
The Deep Dive
Regions: AWS's biggest blast-radius boundary
An AWS Region is a physical cluster of data centers in one geographic area — Mumbai, Frankfurt, N. Virginia, and so on. As of right now, AWS runs 39 Regions worldwide, with more (Saudi Arabia and Chile among them) already announced. That number keeps climbing every year, and it will probably be out of date by the time you read this — which is itself a small demonstration of how fast this industry moves.
Here's the part that matters more than the count: every Region is completely independent of every other Region. No shared power, no shared networking, no automatic data replication between them. If something catastrophic happens to one Region, the others are architecturally incapable of being affected by it. That's not an accident — it's the entire point. AWS deliberately trades away convenience (data doesn't just magically sync everywhere) for a hard guarantee: one Region's disaster is contained to that Region.
This is also why "which Region should I use" is a real architectural decision, not a formality — it usually comes down to three things:
- Latency — put your compute physically close to your actual users.
- Compliance and data residency — some data is legally required to stay within a country's borders (a big deal for anything involving government, finance, or healthcare data).
- Service availability — not every AWS service launches in every Region on day one.
Availability Zones: independence, one level down
Zoom into a single Region, and you'll find it's made up of multiple Availability Zones (AZs) — currently 123 AZs spread across those 39 Regions, almost always at least 3 per Region. Each AZs is one or more entire data centers, with its own power, cooling, and networking, physically separated from the other AZs in the same Region — far enough apart (often tens of kilometers) that a single flood, fire, or power grid failure can't plausibly take out two AZs at once, but close enough together that a network link between them is still fast (single-digit milliseconds).
This is the actual mechanical reason AWS architecture diagrams always show things spread across "at least 2 AZs." It's not a best practice for its own sake — it's the smallest unit at which you get real fault tolerance without leaving the Region (and therefore without giving up low latency between your own components).
Edge Locations: a completely different job
Regions and AZs are about compute and storage. Edge Locations solve a different problem entirely: getting content physically close to a user who's just trying to load a webpage or stream a video, regardless of where your actual servers live. AWS runs edge infrastructure in far more cities than it runs full Regions in — think hundreds of cities across dozens of countries — specifically so that a CDN service like CloudFront can cache and serve content from whichever edge location is geographically nearest the person requesting it.
Two more variants worth knowing, since they came up while I was reading and they explain some naming you'll see in AWS docs:
- Local Zones — a small extension of a full Region, placed closer to large population or industry centers that don't have a full Region nearby, for latency-sensitive workloads that still need real compute, not just cached content.
- Wavelength Zones — AWS compute embedded directly inside telecom providers' 5G networks, built for mobile applications that need single-digit-millisecond latency (think real-time gaming or AR, not a typical web app).
Now zoom all the way in: what's happening inside one server
This is the part I actually found the most surprising. Regions and AZs explain where your stuff lives geographically. But there's a second, completely different layer of "underneath" — what's physically happening on the one server your EC2 instance is running on — and AWS's answer to that is a purpose-built system called Nitro.
Here's the problem Nitro solves. A traditional hypervisor (the software that lets one physical machine run multiple virtual machines) has to do a lot: manage CPU and memory allocation, virtualize networking, virtualize storage, handle security boundaries between tenants, and more — and all of that runs as software competing for the same host CPU your virtual machine is also trying to use. That's overhead, and it's also attack surface: more code running with privileged access means more that could theoretically go wrong.
AWS's fix was almost architectural surgery: physically rip most of that work off the host CPU entirely and hand it to dedicated hardware. The Nitro System has three pieces:
- Nitro Cards — separate physical hardware (built by Annapurna Labs, the AWS-owned chip design team) that handle networking, EBS storage access, and local instance storage — so the host CPU never has to implement any of that itself.
- Nitro Security Chip — provides a hardware root of trust and secure boot, and enforces a locked-down security model so strict that it blocks all administrative access to the underlying hardware — including AWS's own employees. That's a genuinely unusual design goal: removing even the possibility of insider tampering, not just defending against outside attackers.
- Nitro Hypervisor — with the networking, storage, and security work already offloaded to the cards above, what's left is a hypervisor so minimal it has no shell, no SSH server, no general-purpose file system, and no background processes running when idle. AWS's own description for this is "quiescent" — it does nothing at all unless an instance is actively asking it to do something.
The payoff of this design is that performance on a modern EC2 instance is close to indistinguishable from running directly on bare metal — and AWS can also literally offer bare-metal instances (
*.metal types, no hypervisor at all) for workloads that want direct hardware access, something that would be far riskier to offer safely without Nitro's hardware-enforced isolation underneath it. There's also Nitro Enclaves — fully isolated compute environments built on the same Nitro hypervisor technology, used for processing especially sensitive data (health records, financial data) with an extra wall between it and even the rest of your own instance.One detail I liked enough to note down: the same Annapurna Labs team behind the Nitro Cards also designs AWS's Graviton processors (their own Arm-based chips) and the Trainium and Inferentia chips built specifically for AI training and inference. Same silicon team, same underlying design philosophy — which is a small preview of where this series is headed once we get to the cloud-and-AI section in a few weeks.
Putting the two layers together
So "what's actually underneath AWS" has a genuinely two-layer answer:
- Macro layer — Regions and AZs, deliberately isolated from each other geographically, so a disaster in one place stays contained to that place.
- Micro layer — inside a single server, the Nitro System deliberately isolates the "renting out compute to strangers" problem away from the host CPU entirely, using dedicated hardware instead of trusting software alone.
Different scales, same underlying instinct: contain failure and blast radius as close to its source as physically possible, at every level of the stack.
My Take
I was amazed to learn about the macro and micro layers of AWS systems and how AWS handles massive amounts of traffic at scale.
What surprised me even more was learning that even Amazon employees are locked out of hardware-level access! Obviously, this is for security reasons, but the level of isolation and security still amazes me.
So, next week, let’s dive into IAM**,** understanding who has access to what, how permissions are managed, and how AWS controls access across its systems.
Next week — Part 3: IAM and the Shared Responsibility Model — who's actually responsible for securing what, before I touch a single service for real.
Series: AWS: Zero to Hero (9 articles)
- 2AWS: Zero to Hero — Week 2: What's Actually Underneath AWS This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article