AWS Global Infrastructure

TL;DR

• AWS infrastructure is a hierarchy: Regions (isolated) → Availability Zones (physically separate, low-latency-linked) → Edge Locations / Local Zones / Wavelength Zones / Outposts (latency or on-prem extensions of a Region).
• Every placement decision trades off latency, resilience, compliance, and cost — there is no default-correct answer, only the answer matching the actual requirement.
• AZ names (ap-south-1a) are account-specific mappings, not physical identifiers — use AZ IDs (aps1-az1) for cross-account capacity or blast-radius reasoning.
• Cross-AZ data transfer is billed per-GB in both directions; chatty multi-AZ microservices are a common hidden cost driver.
• The Shared Responsibility Model’s line moves with the abstraction level (EC2 vs. Lambda vs. RDS) — it is not one fixed split.
• Global AWS services (IAM, STS, parts of CloudFront/Route 53 config) have historically depended on us-east-1’s control plane, making it a hidden single point of failure even for workloads deployed elsewhere.

Core Concepts

Regions

Regions are fully isolated infrastructure footprints, each with its own control plane, data replication boundary, and typically its own compliance scope. Region selection is driven by three factors: data residency (regulatory regimes such as RBI or GDPR mandate specific jurisdictions), proximity to end users, and service availability. Not every AWS service or feature launches in every Region simultaneously — new services (recent Bedrock models, newer VPC Lattice features) often roll out to a handful of Regions first. Regional service availability must be validated at design time, not discovered after a proof of concept is built.

Availability Zones (AZs)

AZs are physically separate datacenters within a Region, connected by a private, high-bandwidth, low-latency backbone (typically single-digit-millisecond round trips). Multi-AZ is the baseline resilience pattern. Quorum-based systems (RDS Multi-AZ, MSK, self-managed etcd/Consul clusters) require a minimum of three AZs — a two-AZ deployment cannot survive the loss of one AZ without losing quorum.

Two operational gotchas:

1. AZ names are account-specific mappings. ap-south-1a in one account is not guaranteed to map to the same physical datacenter as ap-south-1a in another account. AWS deliberately randomizes this mapping per account to spread load evenly across physical AZs. Cross-account capacity planning or blast-radius reasoning must use AZ IDs (aps1-az1), which are consistent identifiers for the physical facility.
2. Cross-AZ traffic is not free. Most services bill per-GB, in both directions, for traffic crossing an AZ boundary — even within the same Region and VPC. A chatty microservice architecture spread across AZs is a common and often unbudgeted cost driver.

Edge Locations

Edge Locations are CloudFront/Route 53 points of presence — numbering in the hundreds worldwide, far more numerous than Regions. Their role is caching content and resolving DNS close to the end user, not running general compute. Lambda@Edge and CloudFront Functions are the exception: they allow limited logic (auth checks, header rewrites, A/B routing) to run at the edge without a round trip to origin.

Local Zones

Local Zones extend a parent Region into a metro area with no full Region present, delivering single-digit-millisecond latency to that population center. Typical use cases include media rendering pipelines and ad-bidding systems where round-tripping to a Region tens of milliseconds away is the binding latency constraint. Service parity with the parent Region is narrower — available services must be validated explicitly before a design assumes full Region-equivalence.

Wavelength Zones

Wavelength Zones embed AWS compute directly inside a telco’s 5G network, delivering roughly 10-15ms latency to devices on that carrier’s mobile network. This is a narrow use case: connected-vehicle telemetry, mobile AR/VR, real-time multiplayer over cellular. Workloads whose latency budget is satisfied by a standard Region do not need Wavelength.

AWS Outposts

Outposts ships physical AWS-managed hardware into a customer datacenter, extending the same APIs and control plane on-premises. It addresses cases where data cannot leave a facility (regulatory mandate, air-gapped requirement) or where consistent low-latency processing is needed alongside on-prem systems during a phased migration.

The key operational nuance: Outposts is not fully autonomous. The data plane for supported services continues serving traffic locally during a network outage to the parent Region, but a meaningful set of control-plane operations — provisioning new resources, certain API calls — depends on connectivity back to the parent Region and degrades or fails until that link is restored. DR runbooks must be built around this partial dependency, not an assumption of full independence.

Shared Responsibility Model

The responsibility line is not fixed — it shifts with the abstraction level of the service in use.

• EC2: the customer owns guest OS patching, IAM configuration, security groups, and data.
• Lambda: AWS owns runtime patching; the customer owns function code, its dependencies, and any secrets it handles.
• RDS: AWS handles DB engine patching for supported paths; the customer controls the timing of major version upgrades and owns backup/restore testing.

The abstraction level determines what moves from customer-owned to AWS-owned — reciting “AWS does security of the cloud, the customer does security in the cloud” without being able to apply it to a specific service is an incomplete answer.

Global Services and the us-east-1 dependency

IAM, Route 53, CloudFront configuration, Organizations, and (mostly) WAF are not tied to a single Region from a customer-facing perspective. Operationally, several of these control planes have historically routed critical operations through us-east-1. This makes a hard dependency on us-east-1 a hidden blast-radius risk even for accounts with zero workloads deployed there — degradation in that Region has, on prior occasions, affected IAM/STS operations or CloudFront deployment pipelines for customers with no direct footprint in it.

Local Zones vs. Wavelength Zones vs. Outposts

Common Pitfalls

• Pitfall: Treating Region selection as a checkbox. Why: Teams default to whichever Region a proof of concept happened to run in. Fix: Select Region explicitly against data residency, latency, and service-availability requirements before committing to an architecture.
• Pitfall: Reasoning about cross-account capacity or isolation using AZ names. Why: AZ name-to-physical-AZ mapping is account-specific. Fix: Use AZ IDs for any cross-account blast-radius or capacity analysis.
• Pitfall: Unbudgeted cross-AZ data transfer costs. Why: A chatty microservice design spanning AZs incurs per-GB charges in both directions that are easy to overlook during design. Fix: Model cross-AZ traffic volume and cost explicitly for multi-AZ, multi-tier architectures.
• Pitfall: Assuming Outposts or Local Zones behave identically to a full Region during an incident. Why: Both have narrower service parity and, for Outposts, a control-plane dependency on the parent Region. Fix: Write DR runbooks that reflect the specific, narrower guarantees of each extension.
• Pitfall: A design that works in one account cannot be replicated when a second team adopts the same pattern. Why: Manual, undocumented setup does not scale or generalize. Fix: Treat placement decisions as governed, repeatable, auditable patterns rather than one-off configuration.

Interview Questions

• Explain why Local Zones would be chosen over Wavelength Zones for a given workload, and identify a case where neither applies — tests whether latency numbers and service-parity trade-offs are understood concretely, not just the names.
• Draw the request path, identity path, and failure path for a 3-AZ deployment, including what happens to in-flight requests when one AZ drops — tests whether the architecture is actually understood end-to-end, not just described at a high level.
• A us-east-1 IAM incident caused deployment failures in ap-south-1 despite no workloads running in us-east-1 — explain why, and how to mitigate it — tests understanding of global service control-plane dependencies.
• A client asserts Outposts carries the exact same SLA as a full Region — evaluate that claim — tests the ability to translate an infrastructure nuance into an accurate client-facing statement.
• Explain the difference between AZ names and AZ IDs and when each is the correct tool — tests whether the account-specific mapping gotcha is understood, not just memorized as trivia.