In Part 1 we saw how AWS physically distributes its infrastructure, and in Part 2 how to pick the right region among the four forces that pull at that decision.
But there’s a limit no choice of region can beat: the speed of light. No matter how close a region you pick, for many of your users it will still be hundreds or thousands of kilometers away. A real-time gamer, a surgeon operating remotely, an autonomous car making decisions: for them, even the best region is too far away.
When that happens, AWS has a whole family of ways to push the cloud closer than any region can reach. And it helps to order them by a single idea: how close to the user they place the infrastructure. From a simple cache at the edge of the internet, all the way to a rack of AWS gear installed inside your own building.
Let’s climb that proximity step by step.
Edge Locations: the first step out of the region
The first jump toward the user doesn’t move your application: it moves your content.
Edge Locations are points of presence distributed around the world, far more numerous than regions — AWS operates more than 750. Their job is to act as a CDN: keep cached copies of your content (images, videos, responses) close to each user, so they don’t have to travel all the way to the region every time.
Here’s the key distinction, and it’s the same tension running through the whole series:
A region runs your application and stores your data. An Edge Location only delivers: it accelerates and caches, it doesn’t run your business logic.
The flagship service is Amazon CloudFront, but the edge network supports several more: Route 53 (DNS), Global Accelerator, AWS Shield and WAF (protection), API Gateway. And it’s not just reads: CloudFront also accelerates uploads to S3 using that same network. You can even run small pieces of compute at the edge with Lambda@Edge.
Caching content solves delivery. But what if you genuinely need full compute — an entire application, not a cache — closer than the region?
Local Zones: a piece of a region, moved to the city
That’s where Local Zones come in. If an Edge Location is a cache, a Local Zone is a real chunk of a region placed near a major city: you can deploy genuine compute and storage (EC2 instances, EBS volumes) a few kilometers from your users, achieving single-digit millisecond latencies.
Technically, a Local Zone is an extension of your VPC: you stretch it from the parent region into the local zone, and your private resources operate closer to the edge without ceasing to be part of your network.
When does it make sense?
- Latency-sensitive applications: real-time experiences the region simply can’t offer because of sheer geographic distance.
- Local compliance: when regulation requires you to keep resources within a specific country or city.
- Content delivery and caching: EC2 autoscaling groups close to the user to distribute content more efficiently.
The difference from the edge is that here your application actually runs, it’s not just cached.
But Local Zones live in cities, along the public internet path. What about users whose “last mile” is a mobile network — where traffic first has to leave the carrier’s network to reach AWS?
Wavelength Zones: inside the carrier’s 5G network
Wavelength Zones bring AWS infrastructure inside a mobile carrier’s data center, at the very edge of its 5G network.
The trick is in what doesn’t happen. Normally, traffic from a mobile device has to climb up the carrier’s network, exit onto the public internet, and traverse it to reach AWS. With Wavelength, AWS infrastructure is already right there inside: traffic doesn’t need to go out to the public internet, that long chain of hops is eliminated, and latency drops to single-digit milliseconds for the mobile device.
Just like with Local Zones, you use it by extending your VPC into the Wavelength Zone.
The ideal scenario? Everything that breaks with the slightest delay over a mobile network:
- High-quality gaming, where latency and packet loss ruin the experience.
- Augmented and virtual reality and live video streaming.
- Autonomous systems: connected vehicles and industrial robotics that depend on immediate response over mobile connectivity.
Local Zones and Wavelength bring the cloud remarkably close. But both still live in AWS or partner facilities. What if regulation — or physics — demands the cloud be literally inside your own building?
Outposts: the cloud inside your own data center
AWS Outposts takes the final step: it brings AWS infrastructure to your own premises.
They’re physical racks of AWS servers installed directly in the customer’s on-premises data center. There you can run the same AWS services (EC2, S3, RDS) locally, with ultra-low latency, for workloads that by law or by physics can’t leave your building.
And here an important inversion happens compared to everything before. In a region or an AZ, the physical layer is 100% AWS’s responsibility — in fact, in Part 1 we saw that the data center is “the layer you don’t decide.” With Outposts, that boundary moves:
Shared responsibility: AWS manages the technical infrastructure (hardware and patches), but you take charge of the physical security, power, and networking of the rack, because it lives inside your facilities.
It’s as close as the cloud can get to the user: inside your own server room.
We now have five ways to place the cloud. How do you know which one?
The ladder of proximity
This whole family sorts along two questions: how close to the user the infrastructure lives, and who manages the physical layer.
FARTHER (the base)
│
├── Region / AZ ........ your default base │ physical: AWS
├── Local Zone ......... real compute near the city │ physical: AWS
├── Wavelength Zone .... inside the carrier's 5G network │ physical: AWS
└── Outposts ........... inside YOUR own building │ physical: AWS + YOU
│
CLOSER (the user)
Edge Locations ...... cross-cutting DELIVERY layer (caches, doesn't run)Region and AZ are your base: that’s what you design against almost always. Local Zones, Wavelength, and Outposts are extensions that bring compute closer when the region is too far away for a specific case. And Edge Locations are a separate, cross-cutting layer: they don’t run your app, they accelerate its delivery.
What this changes (and what it doesn’t)
It’s worth closing with the same warning that runs through the whole series. Bringing compute to the edge solves a problem of latency and physical location. Nothing more.
Remember the punchline of Part 1: the infrastructure covers infrastructure failures, not your
own mistakes. A bad deploy ships just as fast to your Local Zone; a DELETE without a
WHERE wipes the table in your Outpost too. Pushing the cloud to the edge doesn’t save you
from that.
And all these extensions add cost and complexity. Each one is a deliberate decision for a specific problem — 5G gaming, a regulatory requirement, remote surgery — never a default you turn on just in case. The vast majority of applications never need anything beyond region + multi-AZ.
Closing the series
I’ll close where we started. Across three parts we took apart the complete model:
- Part 1 — how AWS distributes its infrastructure (region → AZ → data center) and what each level of the failure ladder protects you against.
- Part 2 — how to choose the right region among latency, price, regulation, and service availability.
- Part 3 — how AWS extends the cloud beyond the region to get closer to the user, all the way into your own building.
The mental model you walk away with is simple: region and AZ are your base; everything else is an extension for a specific problem. Always start from the base, and climb a level only when a real problem — of resilience, of latency, or of law — forces you to.
