Hybrid Cloud Compute — Outposts, Local Zones & Wavelength
Recap: Where We Left Off
Day 49 established the Snow Family as the offline-transfer answer when the network itself is the bottleneck — Snowcone for small or rugged edge sites, Snowball Edge Storage Optimized at roughly 80TB usable per device, Snowball Edge Compute Optimized with GPU for edge processing, and Snowmobile for exabyte-scale shipping-container transfers, all coordinated through OpsHub. The common thread was that when moving data over the wire is impractical, you move the hardware instead.
Today extends that same instinct in a different direction. Snow Family moves data to AWS; Outposts, Local Zones, and Wavelength move AWS compute to where the data and the users already are. The constraint is no longer bandwidth but latency and data residency — a manufacturing plant that needs single-digit-millisecond round trips to its own control systems cannot be served by a Region hundreds of miles away, no matter how much bandwidth you provision. The question shifts from "how do we get the bytes to AWS" to "how much of AWS can we put inside the building, the metro, or the carrier network."
Foundations You'll Need Today
Regions and Availability Zones
A Region is a physical cluster of data centers in one geographic area — Northern Virginia, Ireland, Singapore, and so on. Inside each Region are Availability Zones, which are separate buildings with independent power and networking, close enough to each other that you can connect them with low-latency links but far enough apart that a single fire or flood will not take both down. When you launch a server "in AWS," you are really launching it into one Availability Zone inside one Region. This matters for today because every hybrid compute option is defined by its relationship to a Region: an Outpost is an extension of a Region that happens to sit in your building, a Local Zone is a small piece of a Region placed in a city, and a Wavelength Zone is a piece of a Region placed inside a phone carrier's network. None of them is a Region of its own.
Latency and Why Distance Causes It
Latency is the time it takes for a request to travel from a client to a server and for the response to come back — the round trip. It is measured in milliseconds, and a millisecond is one thousandth of a second. The speed of light in fiber is roughly 200,000 kilometers per second, which sounds fast until you do the arithmetic: a round trip from a factory in the middle of a country to a data center 1,500 kilometers away costs at least 15 milliseconds of pure travel time before any server does any work. That is why "single-digit milliseconds" is a hard physical constraint and not a tuning problem. You cannot optimize your way out of distance; you have to move the compute closer to the client. Every service covered here exists to do exactly that.
VPCs and Subnets
A Virtual Private Cloud (VPC) is your own private network inside AWS — a logically isolated space where you decide the IP address ranges, the routing, and who can talk to whom. Inside a VPC you carve out subnets, which are smaller slices of that address range tied to a specific Availability Zone. A subnet is where a server actually lives; it is the network segment the server's network interface attaches to. When today's material says a Local Zone "adds a new set of subnets to your VPC," it means AWS has extended your private network into a new physical location, and you can now place servers there as if they were in any other subnet — except that traffic between that subnet and your other subnets has to physically travel between the metro and the Region.
Control Plane vs. Data Plane
Every AWS service has two halves. The control plane is the management layer: the APIs you call to create, modify, and delete resources, and the console you click through to do the same. The data plane is the resources themselves doing their job — a server serving HTTP requests, a database answering queries, a load balancer forwarding packets. These two halves can fail independently, and that distinction is the single most important idea for understanding hybrid compute failure modes. If the control plane is unreachable but the data plane is healthy, your application keeps serving users while you are completely unable to launch a new server, change a security rule, or even see fresh metrics. That is precisely what happens when an Outpost loses its connection to its parent Region, and it is why "the app is up but I can't do anything" is a recognizable symptom rather than a contradiction.
Direct Connect and VPN
A VPN is an encrypted tunnel over the public internet between your network and AWS — quick to set up, cheap, but subject to the internet's variable latency and occasional congestion. AWS Direct Connect is a dedicated private physical circuit from your data center to an AWS facility, bypassing the public internet entirely. It costs more and takes weeks to provision, but it delivers consistent, low latency and predictable bandwidth. Today's material assumes you know both because an Outpost needs a reliable, low-latency link back to its parent Region, and Direct Connect is the recommended way to provide it. When the lesson says the "service link" is down, it is talking about this connection — and the choice between VPN and Direct Connect is often the difference between an Outpost that meets its latency requirement and one that does not.
With that grounding, here is why Outposts, Local Zones, and Wavelength exist and what problem each one actually solves.
1. Why This Is on the Exam
SAP-C02 scenarios that mention latency in single-digit milliseconds, data that legally cannot leave a facility, or workloads that must talk to industrial control systems on the factory floor are almost always testing whether you know the boundary between the three hybrid compute options. The exam does not ask you to recite Outposts rack dimensions; it asks you to pick the right extension of AWS for a stated constraint, and to recognize when the correct answer is actually "none of these — use a Region."
The trap is that all three services sound like "AWS, but closer." They are not interchangeable. Outposts is customer-owned real estate running AWS-managed hardware under your physical control. Local Zones are AWS-owned infrastructure in a metro area you do not manage. Wavelength is AWS compute embedded inside a telecommunications provider's 5G network, reachable only through that carrier's mobile data path. Each one answers a different question, and the exam will give you a scenario where two of them are plausible and only one is correct.
This maps most directly to Domain 1 (Design Solutions for Organizational Complexity) for the residency and governance angles, and to Domain 2 (Design for New Solutions) for the latency-driven architecture choices. It also shows up in Domain 4 cost questions, because Outposts carries a substantial fixed monthly commitment that Local Zones and Wavelength do not.
2. How Each Option Actually Works
Outposts ships AWS-designed racks or individual servers into your data center. AWS installs and manages the hardware, but you provide the power, cooling, networking, and physical security. The Outpost connects back to its parent Region over a service link — a VPN or, more commonly, a Direct Connect connection — and appears in the AWS console as a distinct resource pool. You launch EC2 instances, EBS volumes, and in some configurations RDS and ECS resources onto it exactly as you would in a Region, but the compute physically sits in your building. The parent Region remains authoritative for control-plane operations: IAM, CloudWatch, and the APIs that manage the Outpost all live there, which means a service link outage does not stop running instances but does stop you from launching new ones.
Local Zones are a different animal entirely. AWS builds a small extension of a parent Region in a specific metro area — Los Angeles, Boston, Houston, and dozens of others — and you opt in per account. When you enable a Local Zone, a new set of subnets appears that you can create in your VPC, and resources launched there have single-digit-millisecond latency to users in that metro. You do not own or manage any hardware; you pay for what you use, and the Local Zone is connected to its parent Region over AWS's own low-latency network. The parent Region still owns the control plane, so the same service-link reasoning applies, but the failure domain is AWS's problem rather than yours.
Wavelength takes the same idea and pushes it into the carrier network. AWS deploys compute and storage inside a telecommunications provider's data center at the edge of a 5G network, and traffic from mobile devices on that carrier reaches the Wavelength Zone without leaving the carrier's network. That last hop is the entire point: a request from a phone to a Wavelength Zone never traverses the public internet, which is what makes sub-10-millisecond round trips achievable for mobile applications. Wavelength Zones are available only in specific carrier networks and specific metros, and they are reached through carrier gateways rather than standard internet gateways.
3. The Core Decision Boundary
Every scenario question in this space reduces to two questions asked in order. First: does the workload require AWS-managed hardware to be physically located on premises that the customer controls? If yes, the answer is Outposts and nothing else will do. If no, the second question is: is the latency-sensitive client a mobile device on a specific carrier's 5G network, or is it a general population of users in a metro area? Mobile-on-carrier points to Wavelength; general metro users point to Local Zones.
The reason this ordering matters is that Outposts is the only option that satisfies data residency requirements in the strict sense. Local Zones and Wavelength are still AWS-operated facilities; if a regulator requires that data never leave the customer's physical premises, neither of them qualifies, regardless of how low the latency is. Conversely, if the requirement is purely latency and the customer has no interest in owning hardware, Outposts is the wrong answer even though it would technically work — it carries a fixed cost and an operational burden that the other two avoid.
| Constraint | Outposts | Local Zone | Wavelength |
|---|---|---|---|
| Hardware location | Customer data center | AWS metro facility | Carrier 5G data center |
| Who owns/operates hardware | AWS owns, customer hosts | AWS | AWS + carrier |
| Data residency on customer premises | Yes | No | No |
| Typical latency target | Sub-millisecond to on-prem systems | Single-digit ms to metro users | Sub-10 ms to mobile devices |
| Billing model | Fixed monthly + usage | Usage only | Usage only |
| Requires customer facilities | Yes (power, cooling, space) | No | No |
| Reachable from public internet | Via parent Region | Yes | Only via carrier network |
4. Configuration Modes and Their Tradeoffs
Outposts comes in two form factors, and the choice between them is driven by capacity and by whether you need the full rack-level service set. The rack form factor is a standard 42U rack that AWS ships and installs, supporting the widest range of instance types and services including RDS and ECS on Outposts. The server form factor is a single 1U or 2U server intended for smaller sites — retail stores, branch offices, factory floors — where a full rack is impractical. The server form factor supports a narrower set of instance types and does not support all the services the rack does, so a scenario that requires RDS on Outposts is implicitly requiring the rack.
Local Zones have essentially one configuration decision: which Local Zones to opt into, and which subnets to extend into them. The tradeoff is not about modes but about placement — you enable a Local Zone in your account, create a subnet in it, and then decide which resources to launch there. The subtlety is that a Local Zone subnet is part of your VPC, so it inherits your VPC's routing and security posture, but it is physically distant from your other subnets. Cross-subnet traffic between a Local Zone and its parent Region traverses AWS's network and incurs latency, so the design question is what belongs in the Local Zone versus what stays in the Region.
Wavelength has a similar shape but a harder constraint: resources in a Wavelength Zone are reachable from the carrier network through a carrier gateway, and from your VPC through the parent Region. You cannot reach a Wavelength Zone from the public internet directly. That means the application architecture has to be split — the latency-sensitive portion runs in the Wavelength Zone, and everything else runs in the Region, with the two communicating over the AWS backbone. The tradeoff is that you gain the carrier-network path but you take on a split-architecture design that has to handle the case where the Wavelength Zone is unavailable.
5. Sizing, Limits and Quotas
The numbers that matter here are mostly about what each option can and cannot host, and about the connectivity requirements that gate whether it works at all. Outposts requires a reliable, low-latency connection back to the parent Region — AWS documents a service link latency requirement in the low single-digit milliseconds, and a Direct Connect connection is the recommended path. If the service link is down, existing instances keep running but you cannot launch, terminate, or modify resources, and control-plane operations fail.
Local Zones are available in a specific and growing list of metros, and each one is tied to a parent Region. Not every instance type is available in every Local Zone, and the available capacity is smaller than a full Region, so a scenario that assumes you can launch a large fleet in a Local Zone is usually wrong. Wavelength Zones are even more constrained: they exist only where a participating carrier has deployed them, and the instance types available are a subset oriented toward the mobile edge use case.
| Dimension | Outposts | Local Zone | Wavelength |
|---|---|---|---|
| Form factors | Rack (42U) or server (1U/2U) | N/A (AWS-managed) | N/A (carrier-managed) |
| Service coverage | Broadest on rack; narrower on server | Subset of Region services | Narrowest, mobile-edge focused |
| Parent Region dependency | Required for control plane | Required for control plane | Required for control plane |
| Connectivity requirement | Service link, low single-digit ms | AWS backbone to parent Region | Carrier network + AWS backbone |
| Availability footprint | Wherever customer has facilities | Specific metros | Specific carrier metros |
The practical sizing rule is that Outposts capacity is fixed by the hardware you order and cannot burst beyond it, while Local Zones and Wavelength Zones draw on AWS-managed capacity that you do not provision. That difference shows up in capacity-planning scenarios: an Outposts deployment needs a capacity headroom decision up front, whereas a Local Zone deployment can scale within whatever AWS has made available in that metro.
6. Failure Modes and What They Look Like in Production
The signature Outposts failure is the service link going down. The symptom is peculiar: your instances keep serving traffic, your application looks healthy, but every API call that tries to launch, stop, or modify a resource fails, and CloudWatch metrics from the Outpost stop arriving in the Region. The first diagnostic move is to check the service link status in the Outposts console and verify the underlying Direct Connect or VPN connection, not to start debugging the application. Teams that have never seen this before waste time looking at the workload when the control plane is the problem.
A second Outposts failure mode is physical: power, cooling, or network failure in the customer's own data center. AWS manages the hardware but not the facility, so a UPS failure or a cooling outage takes the Outpost down in a way that no AWS-side remediation can fix. This is the operational cost of hosting AWS hardware yourself, and it is why Outposts deployments need the same facility redundancy planning as any on-premises rack.
Local Zones fail in a way that looks like a normal Regional degradation, because that is essentially what it is. If the Local Zone loses connectivity to its parent Region, resources in the Local Zone may continue running but control-plane operations fail, and any application that depends on Regional services — a database in the Region, an S3 bucket, an IAM call — will see elevated latency or errors. Wavelength failures are similar but compounded by the carrier dependency: if the carrier network has an issue, mobile clients cannot reach the Wavelength Zone at all, even if the AWS-side infrastructure is healthy. The diagnostic move in both cases is to determine whether the failure is in the AWS control plane, the network path, or the carrier, because the remediation differs entirely.
7. Operational and SRE Angle
Monitoring hybrid compute requires watching two planes at once. The data plane — the instances and their application metrics — behaves like any other EC2 workload and can be monitored with the standard CloudWatch agent and alarms. The control plane is the part that is easy to forget: the service link status, the connectivity to the parent Region, and the health of the Outpost itself are all separate signals that need their own alarms. A useful pattern is to alarm on the absence of metrics from the Outpost, because a silent Outpost is more likely to indicate a link failure than a healthy idle one.
For Local Zones and Wavelength, the SRE concern is latency SLOs rather than hardware health. If the entire reason you deployed to a Local Zone is to hit a single-digit-millisecond latency target for metro users, then that target is your SLO and it needs to be measured from the user's perspective, not from inside the VPC. CloudWatch Synthetics canaries running from the metro, or client-side real user monitoring, are the right instruments. A canary that runs from the parent Region will happily report healthy latency while users in the metro experience something entirely different.
The runbook shape for all three is similar: first determine whether the failure is in the control plane, the data plane, or the network path; then determine whether the remediation is an AWS-side action or a customer-side one. For Outposts, the customer-side actions — power, cooling, physical network — are the ones that most often require a human on site, which means the runbook needs an escalation path to whoever has physical access to the facility. That is a genuinely different operational model from a pure-Region workload, and it is worth writing down explicitly rather than assuming the on-call engineer will figure it out at 3 a.m.
8. Edge Cases and Exam Gotchas
The most common exam trap is treating Outposts as a latency solution when the scenario is really about data residency, or vice versa. Read the scenario carefully: if it says the data must remain on the customer's premises, that is residency and the answer is Outposts. If it says users in a specific city need low latency and there is no residency requirement, that is Local Zones. If it says mobile users on a specific carrier need sub-10-millisecond latency, that is Wavelength.
A second gotcha is the assumption that Outposts removes the need for a parent Region. It does not. The control plane, IAM, CloudWatch, and most AWS services still live in the Region, and the Outpost is an extension of it, not a replacement. Scenarios that describe a fully disconnected Outpost are describing something Outposts does not do — running instances survive a link outage, but the Outpost is not an autonomous Region.
A third gotcha is cost. Outposts carries a fixed monthly commitment for the hardware plus a service link charge, which makes it expensive for small workloads even when it is technically the right fit. Local Zones and Wavelength are usage-based. A cost-optimization scenario that proposes Outposts for a small latency-sensitive workload is usually wrong; the correct answer is more likely a Local Zone or a Region with CloudFront in front of it.
Finally, remember that Wavelength is not reachable from the public internet. Any scenario that describes a Wavelength Zone serving general web traffic is describing something that cannot work — Wavelength is for mobile clients on the carrier's network, reached through a carrier gateway.
9. This vs. the Services It Gets Confused With
The services most often confused with this cluster are CloudFront, Global Accelerator, and the Snow Family. CloudFront and Global Accelerator both reduce latency, but they do it by moving content or traffic closer to users over the existing internet, not by moving compute. If the requirement is to run code close to the user, CloudFront Functions and Lambda@Edge cover some cases, but they are constrained in runtime and cannot host arbitrary workloads. The Snow Family moves data, not compute, and is the right answer when the problem is bandwidth rather than latency.
| Service | What it moves | Pick it when… |
|---|---|---|
| AWS Outposts | AWS compute into your facility | Data residency or sub-ms latency to on-prem systems is required |
| Local Zones | AWS compute into a metro | Metro users need single-digit-ms latency and you don't want to own hardware |
| Wavelength | AWS compute into a carrier 5G edge | Mobile clients on a specific carrier need sub-10-ms latency |
| CloudFront | Cached content closer to users | The workload is cacheable HTTP content, not arbitrary compute |
| Global Accelerator | Traffic onto the AWS backbone | You need faster, more reliable routing to existing Regional endpoints |
| Snow Family | Data into AWS | The network is the bottleneck for a bulk data transfer |
The decision rule that resolves most scenarios: if the constraint is where the data must physically live, choose Outposts. If the constraint is how fast a metro user gets a response and you do not want to own hardware, choose Local Zones. If the constraint is a mobile device on a carrier network, choose Wavelength. If the constraint is bandwidth for a one-time data move, choose the Snow Family. And if the constraint is simply "make the website faster for global users," the answer is almost always CloudFront or Global Accelerator, not any of the hybrid compute options.
Hands-on Lab: Choosing Hybrid Compute for a Manufacturing Plant
Scenario. A manufacturing company runs a plant with industrial control systems (PLCs and SCADA) on the factory floor. The plant has a small server room with power and cooling, a 1 Gbps fiber connection to the corporate WAN, and a Direct Connect connection to AWS. The company wants to run a machine-vision quality-inspection workload that reads camera feeds from the line and must respond within single-digit milliseconds to stop a defective part. They also want a dashboard for plant managers in the same city, and a mobile app for field technicians on a national carrier's 5G network. Budget is a stated concern, and the company has no appetite for managing servers.
Step 1 — Separate the three latency domains. Write down the three distinct client populations: the control systems on the factory floor, the plant managers in the metro, and the field technicians on mobile. Each has a different latency target and a different physical location, and each will likely map to a different AWS extension. Do not try to solve all three with one service.
Step 2 — Evaluate the control-system workload against Outposts. The machine-vision workload must respond to the PLC within single-digit milliseconds, and the camera feeds are large. Measure the round trip from the plant server room to the nearest Region and confirm it exceeds the target. Then confirm the plant has the power, cooling, and rack space for an Outposts server form factor, and that the Direct Connect service link meets the latency requirement. Document the fixed monthly cost and compare it against the cost of the defect rate the workload is meant to reduce.
Step 3 — Evaluate the manager dashboard against a Local Zone. The dashboard is a web application serving users in one metro. Check whether a Local Zone exists in that metro and whether the required instance types are available. If so, deploy the dashboard there and measure latency from a client in the metro. If no Local Zone exists, the fallback is a Region with CloudFront in front of it — document that as the alternative and note the latency difference.
Step 4 — Evaluate the mobile app against Wavelength. Confirm the carrier the field technicians use participates in Wavelength and has a zone in the relevant metro. If so, deploy the latency-sensitive portion of the mobile backend there and keep the rest in the Region. If the carrier does not participate, the answer is a Region with Global Accelerator, and the sub-10-millisecond target is not achievable — document that as an accepted tradeoff.
Step 5 — Design the failure handling. For each of the three deployments, write down what happens when the connection to the parent Region fails. For Outposts, instances keep running but control-plane operations fail. For the Local Zone and Wavelength Zone, determine which application components depend on Regional services and will degrade. Define the alarm for each and the first diagnostic step.
Step 6 — Produce the recommendation. Write a one-page decision memo with a table of the three workloads, the chosen AWS extension, the latency target, the monthly cost, and the failure-handling plan. Justify each choice against the constraint that drove it, and explicitly note where a requirement could not be met and what the fallback is.
Scenario Question Drills (20 min)
Q1. A hospital must keep patient data physically on-premises for regulatory reasons while still using native AWS APIs (EC2, EBS, RDS on Outposts) for its applications.
Q2. A media company wants to serve a video-editing application to users in a single metro area with single-digit-millisecond latency, but has no interest in owning or operating any hardware.
Q3. A gaming company wants sub-10-millisecond latency for players on a specific carrier's 5G network, and the game traffic must not traverse the public internet.
Q4. An Outposts deployment's instances are still serving traffic, but the operations team cannot launch new instances or modify existing ones, and CloudWatch metrics from the Outpost have stopped arriving.
Q5. A retail chain wants to run a small point-of-sale application in each of 200 stores, each with limited rack space and no dedicated server room.
Q6. A team wants to reduce latency for users in a metro area but the workload is a cacheable HTTP website with no dynamic compute requirement.
Q7. A company is deploying an Outposts rack and asks what happens to the workload if the connection to the parent Region is severed for several hours.
Q8. A financial services firm needs to run a latency-sensitive trading application that must communicate with an on-premises market data feed with sub-millisecond latency, and the data cannot leave the firm's data center.
Q9. A team is designing a Wavelength deployment and asks how clients reach the application running in the Wavelength Zone.
Q10. A company wants to run RDS on Outposts for a workload that must stay on-premises, but is considering the server form factor to save space.
Q11. An application runs in a Local Zone and depends on an RDS database in the parent Region. Users in the metro report that the application feels slow despite the Local Zone deployment.
Q12. A company is comparing Outposts and Local Zones for a workload that needs low latency for users in a specific city, and the company has no data residency requirement and wants to minimize fixed costs.
Q13. A team wants to monitor whether a Local Zone deployment is meeting its latency SLO for metro users.
Q14. A company is deploying Outposts and asks what connectivity is recommended between the Outpost and its parent Region.
Q15. A scenario describes a workload that must run on AWS-managed hardware inside the customer's own data center, and the customer wants to use the same EC2 APIs and IAM policies they use in a Region.
Peek into Tomorrow
Everything in this day assumed that the workload being placed at the edge is either cloud-native or can be rehosted onto EC2. That assumption breaks for the large population of enterprises whose applications are virtualized on VMware and whose operational tooling, backup software, and team skills are all built around vSphere. For those workloads, the question is not "which AWS extension do we deploy to" but "can we move the VM to AWS without converting it out of the VMware format at all."
That is the Relocate strategy, and it raises a genuine tension with everything we have covered in this phase. Rehosting via MGN lands the workload on native EC2, which means it can use every AWS service and every hybrid compute option we just discussed. Relocating to VMware Cloud on AWS preserves the hypervisor layer and the existing VMware tooling, but it also preserves the operational model — which is exactly the point for teams that are not ready to refactor. The open question is when preserving the hypervisor is the right call versus when it is technical debt deferred, and how HCX actually performs the migration without a conversion step.
Sources
- AWS Outposts User Guide — What Is AWS Outposts?
- AWS Outposts User Guide — Rack and Server Form Factors
- AWS Local Zones User Guide — What Are AWS Local Zones?
- AWS Wavelength Developer Guide — What Is AWS Wavelength?
- AWS Whitepaper — Fault Isolation Boundaries: Outposts
- AWS Outposts Pricing
- AWS Local Zones Product Page
- AWS Wavelength Product Page