AWS Architecture Guide

Local Zones and Wavelength Zones

Goal

Introduce AWS placement options for latency-sensitive or locality-sensitive workloads that need more than a standard Region design.

The Short Version

Local Zones and Wavelength Zones extend AWS infrastructure closer to users or networks where lower latency or stronger locality matters. They are not the default answer for every workload. They are specialized placement tools for cases where the Region is not close enough to the user, device, or regulatory boundary.

The durable idea is:

Specialized placement should solve a specific locality problem, not create a new complexity problem without a payoff.

Mental Model

flowchart LR
    A["Regional AWS deployment<br/><small>Good default for most workloads</small>"]
    B["Local Zone<br/><small>Closer to a metro area</small>"]
    C["Wavelength Zone<br/><small>In a telco partner data center for 5G edge use cases</small>"]

    A --> B --> C

These are not interchangeable with standard Regions. They are placement options that extend AWS closer to a specific locality or network boundary, and they are most useful when the default Region is no longer close enough to satisfy the requirement.

When Local Zones Help

Local Zones are useful when a workload needs:

  • lower latency to users in a specific metro area

  • stronger locality for regulated or contractual reasons

  • a migration path for legacy applications that depend on nearby systems

AWS describes Local Zones as extending core AWS services to more metros, which makes them a practical bridge between a central Region and a more distributed edge design.

When Wavelength Helps

Wavelength is for workloads that need AWS services inside telecom partner data centers, typically to satisfy low-latency, data residency, or resiliency needs for edge applications.

That matters when the timing of the application is tied to the network edge itself, such as 5G, real-time inference, gaming, or other latency-sensitive flows.

Practical Meaning

These options change the architecture question from:

Which Region should host this workload?

to:

Which part of the workload needs to be closer to the user, device, or locality constraint?

That is a better conversation because it avoids moving the whole system when only one part actually needs special placement.

Example: Keep The Main System Regional, Move The Latency-Sensitive Part

Suppose a team runs a media workflow in a central Region but needs a low-latency editing or rendering component near a metro user base. A Local Zone may fit that edge component while the main control plane remains in the Region.

That keeps the design focused. The team is not forced to rebuild the whole application around a specialized edge location.

Common Mistakes

  • Using Local Zones or Wavelength without a clear locality requirement.

  • Moving too much of the application just because a closer placement exists.

  • Forgetting that specialized placement can complicate operations and data movement.

  • Treating edge locality as a substitute for poor application design.

If Someone Asks You

If someone asks, "When would I use Local Zones or Wavelength instead of a normal Region?" a clear answer is:

Use them when a workload needs lower latency or stronger locality than a standard Region deployment can provide. They are specialized placement choices for specific user, network, or regulatory needs, not the default design for every system.

What You Should Remember

If only part of the workload needs special placement, only that part should move.

Questions to Check Your Understanding

  1. What problem do Local Zones solve?

  2. What kind of workloads fit Wavelength?

  3. Why is specialized placement not a default choice?

Further Study

  • AWS Local Zones - Metro-close AWS placement for low-latency and locality-sensitive workloads.

  • AWS Wavelength - Telco-edge AWS placement for low-latency and data residency needs.