Choosing Wavelength, Local Zones, or Outposts at the Edge

The situation

A manufacturing group has deployed an augmented-reality maintenance application. Technicians on the factory floor use tablets that stream video to an inference backend; the backend detects machine parts, returns annotations overlaid on the tablet. The application requires sub-10ms round-trip latency for the video-annotation cycle to feel real-time.

Network landscape:

• The factory has enterprise 5G service from a carrier (Verizon in the US pilot site, Vodafone in the UK one).
• Tablets connect via 5G, not WiFi.
• The public cloud Region (us-east-1 or eu-west-2) adds 40-60ms round-trip from the factory’s carrier edge.
• A WiFi-only alternative would be 2ms to an on-site server, but the floor’s RF environment makes WiFi reliability a nightmare.

Today the backend runs in us-east-1. RTT from tablet to inference is ~55ms (5ms tablet to carrier, 5ms carrier to internet, 45ms internet to us-east-1, return path the same). The UX is laggy; the physical-world overlay drifts when the technician moves.

Options:

• AWS Wavelength, compute inside the 5G carrier’s network edge. The carrier routes the traffic from the tablet’s radio directly to Wavelength without traversing the public internet.
• AWS Local Zones. AWS-managed edge Region extension in major cities. Not inside the carrier, but geographically closer than parent Region.
• AWS Outposts, hardware on-premises. Latency ~1ms from the floor; bypasses the carrier entirely for tablets on WiFi, but tablets are 5G here.
• CDN edge compute (CloudFront Functions, Lambda@Edge), useful for HTTP workloads, not general compute.

What actually matters

The core trade at the network edge is proximity in exchange for infrastructure locality. Every hop saved is 1-5ms; getting into the carrier network itself saves the backhaul-to-internet step. But edge services cost more, offer fewer services than the parent Region, and have specific deployment gotchas.

The first thing to ask is: where does the latency actually live? For the factory-AR case, the measured RTT decomposes roughly as: ~2ms radio to cell tower, ~3ms cell tower to carrier gateway, ~3ms carrier gateway to public internet, ~45ms internet to parent Region, return path mirrors. Each edge option only eliminates the hops it can sit between, compute inside the carrier saves the ~45ms internet leg; compute in the same metro saves most of it; compute on-premises saves all of it but only for clients on the local LAN.

The second is: how does the client reach the edge? Some options sit inside a specific carrier’s network and only short-path clients on that carrier; clients on a different carrier still go via the public internet and see no benefit. Other options sit at metro level and are reachable by any client on a nearby network. Knowing the client’s network shape is what makes “edge” mean anything specific.

The third is: what runs there? Every edge offering is a subset of the parent Region’s catalogue. Knowing the gap matters more than knowing the inclusions, the missing services either get hosted back in the parent Region (round-tripping the saved latency) or get replaced.

The fourth is: carrier and metro coverage. The edge option only helps where its footprint covers the client. Carrier-inside options are constrained to specific cities with specific carriers; metro-level options have broader but still uneven coverage; customer-located hardware is wherever you ship it. The map decides as much as the feature list.

The fifth is: cost. Edge compute carries a premium over parent-Region pricing, tens of percent, sometimes more, plus separate data transfer rates. For a latency-bound workload, the premium is the point; for a latency-tolerant one, it’s a waste.

What we’ll filter on

1. Latency floor, what’s the best achievable RTT from the target client?
2. Carrier dependency, does the client have to be on a specific carrier?
3. Service breadth, what AWS services run at that edge?
4. Coverage, how many locations exist worldwide?
5. Cost premium, what’s the markup over parent-Region pricing?

The edge-compute landscape

1. AWS Wavelength. Compute inside a 5G carrier’s network edge. Single-digit-ms latency from clients on the same carrier. Subset of AWS services. Carrier- and city-specific.

2. AWS Local Zones. AWS edge infrastructure in specific metros (usually without a full Region nearby). Carrier-agnostic; tens-of-ms latency from the same metro. Broader service set than Wavelength.

3. AWS Outposts Rack / Servers. Customer-located AWS hardware. ~1ms local latency; constrained by customer network. Covered in detail in a companion post.

4. AWS Snowball Edge Compute Optimized. Ruggedised edge compute; not metro-scale.

5. CloudFront edge + Lambda@Edge / Functions. HTTP-specific edge. CloudFront has 450+ PoPs worldwide. Great for HTTP response shaping at the edge; not a substitute for arbitrary compute.

6. Parent Region only. Baseline. Good enough for anything latency-tolerant.

Side by side

Option	Latency floor	Carrier dependency	Service breadth	Coverage	Cost premium
Wavelength	Single-digit ms	Specific carrier	EC2, EBS, ECS, EKS, Lambda (some)	Specific cities + carriers	~30-50%
Local Zones	~5-15ms	None	Broader than Wavelength	Specific metros	~10-20%
Outposts	~1ms LAN	None (customer LAN)	Subset of AWS	Wherever you put it	Subscription
Snowball Edge	~ms (local)	None	EC2 + S3 subset	Anywhere you ship	Per-job
CloudFront + L@E	Depends (HTTP)	None	HTTP functions only	450+	Per-request
Parent Region	~30-100ms	None	Full	All Regions	Baseline

For the factory-AR case on 5G: Wavelength if the carrier has a zone nearby. For the same workload in a city without a nearby Wavelength Zone: Local Zones. For WiFi-only edge with full local compute: Outposts.

The Wavelength architecture

The picks in depth

The Wavelength Zone and the carrier gateway. Enable a Wavelength Zone in the AWS console (it’s a one-line action once the account is onboarded with the carrier). The Zone appears as an AZ-like object in the Region; subnets in the VPC can be created on the Zone. The Carrier Gateway (CGW, distinct from the more common “Customer Gateway” for VPN) attaches to the VPC and routes traffic to/from the carrier network.

The subnet’s route table:

• 0.0.0.0/0 (carrier) -> Carrier Gateway.
• Local VPC CIDR -> local.
• S3/DynamoDB via VPC endpoints, bypassing CGW.

The CGW publishes public IP addresses within the carrier’s IP space, these IPs are reachable from the carrier’s clients but not from the public internet. Inference service gets a carrier IP and a DNS name; tablets on the same carrier resolve and connect to the carrier IP.

EC2 instances in the Wavelength Zone. Same launch API, different subnet ID. Instance types are constrained, typically a subset of compute and GPU families appropriate for edge inference. The instance boots normally, draws from the Wavelength Zone’s capacity.

Auto Scaling works within the Zone’s capacity envelope (similar to Outposts, you have a pool of available capacity).

VPC spanning Region and Zone. The VPC’s CIDR includes subnets in both the parent Region and the Wavelength Zone. A carrier-gateway-routed subnet for the Wavelength workloads, a normal NAT-gateway-routed subnet for anything else. Instances in Wavelength can reach Region services over AWS backbone (e.g., DynamoDB writes from the inference service land in Region DDB tables asynchronously).

Networking semantics.

• Carrier IP addresses are the public-facing IPs from the carrier’s perspective. Tablets connect to these.
• Wavelength instances can have a Carrier IP (customer-facing) and a private IP (for VPC-internal traffic).
• Outbound from Wavelength to the internet can go via CGW (using carrier network’s egress) or back to parent Region via VPC routing + parent Region’s NAT.

DNS. A Route 53 hosted zone with the inference service’s hostname pointing at the Wavelength EC2’s carrier IP. Tablets on the same carrier resolve and reach Wavelength; tablets on other carriers can’t reach the carrier IP and fall back to a separate DNS record pointing at parent Region.

Latency-based routing in Route 53 can do this automatically: primary record to Wavelength carrier IP, secondary to parent-Region ALB; GeoDNS selection pushes same-carrier clients to Wavelength, everyone else to Region.

Deployment. Same IaC as cloud. CloudFormation and Terraform understand Wavelength subnets and CGWs. The CI/CD pipeline deploys to Region first, then to Wavelength as a separate stage (different subnet, different instance pool). A canary deploy at Wavelength tests real-user latency before rolling the full update.

Cost modelling. For the factory’s inference service: 4x g5.xlarge instances in Wavelength (for GPU inference) at ~$1.20/hour each = ~$3500/month. Parent-Region equivalent would be ~$2500/month. ~$1000/month premium for the latency. Data transfer within the carrier network is billed differently (carrier-specific); for internal communication (Wavelength -> Region over AWS backbone) the usual inter-AZ/inter-Region rates apply.

When Wavelength doesn’t pay back. If the tablet’s carrier doesn’t have a Wavelength Zone near the factory, the benefit evaporates, the carrier still backhauls to the internet to reach whichever Wavelength Zone you deployed in. If the workload isn’t latency-critical, the premium buys nothing. If the tablet is on WiFi (not 5G), Wavelength isn’t even reachable.

A worked latency breakdown

A tablet on Verizon 5G in a factory in Columbus, Ohio, with a Wavelength Zone co-located at a Verizon edge facility in Columbus:

1. Tablet captures frame, sends to inference.ar.company.com.
2. DNS resolves to Verizon Wavelength Zone carrier IP (Route 53 latency-based).
3. Tablet packet: radio to cell tower (~1.5ms).
4. Tower to Verizon’s mobile core gateway (~3ms).
5. Gateway to Wavelength EC2 via internal peering (~1ms).
6. Inference: 3ms of GPU compute.
7. Return path mirrors: total RTT ~10-12ms. Within budget.

Same workflow for a tablet connected via a different factory’s enterprise WiFi, which doesn’t go through Verizon: DNS returns parent-Region endpoint; RTT ~80-100ms. The workflow still works, but the AR UX degrades. The business accepts that some factories are not Wavelength-compatible and run with the parent-Region fallback.

What’s worth remembering

1. Wavelength is carrier-specific edge compute. Benefits only clients on that carrier’s network. Other carriers’ clients go through the public internet to reach it, losing the advantage.
2. Carrier Gateway is the edge of the edge. Routes traffic between the carrier’s IP space and your Wavelength VPC subnet. Different object from Internet Gateway or Transit Gateway.
3. Latency floor is single-digit ms for same-carrier clients. The point. Any workload not bound by single-digit-ms latency doesn’t need Wavelength.
4. Service breadth is narrower than parent Region. EC2, EBS, ECS, EKS, Lambda in some Zones. Many managed services require round-tripping to parent Region. Plan for async writes to Region DynamoDB / S3.
5. Local Zones are carrier-agnostic metro edge. ~10-20ms latency, more service breadth than Wavelength, carrier-agnostic. Often the better choice when the factor isn’t “same 5G radio” but “same city.”
6. Outposts for sub-ms with customer network. WiFi-only factories might get better latency from Outposts than Wavelength, and Outposts is carrier-agnostic.
7. Route 53 latency-based routing handles same-carrier vs internet-routing. Same-carrier clients get Wavelength; others get parent-Region fallback transparently.
8. Data transfer pricing differs at the edge. Carrier-specific rates for traffic in/out of Wavelength, and standard inter-AZ/inter-Region for backhaul. Factor into the total cost model.

Compute at the tower, but only when the tower is the client’s tower. When the 5G radio is the bottleneck and shaving 40ms matters, Wavelength earns it; when the latency is tolerable or the clients span multiple carriers, a cheaper answer usually fits.