AWS Global Infrastructure and Resilience

Every AWS workload eventually answers one question: where does it run, and what happens when that place breaks? The exam calls this Domain 3, Task 3.2: "Define the AWS global infrastructure", and it is one of the highest-yield tasks on CLF-C02 because a single vocabulary error (Region vs Availability Zone vs edge location) can cost you several questions at once. AWS's own framing is blunt: Amazon CTO Werner Vogels says "Everything fails, all the time", and the Well-Architected Framework exists so you can "prepare your workload for failure" rather than pretend it will not happen.

In this lesson you will:

• separate Regions, Availability Zones and edge locations by definition, count and capability;
• explain why Regions are isolated: fault tolerance, data residency and latency;
• choose a Region using the compliance, latency, price and features decision set;
• apply the AZ design rule (AWS ships ≥3 AZs per Region; your application uses ≥2);
• tell CloudFront, Route 53 and Global Accelerator apart by their entry plane;
• place Local Zones, Wavelength, Outposts and Snow on the hybrid edge continuum;
• define resiliency, availability, fault tolerance, high availability and disaster recovery precisely;
• read and compute RTO and RPO, and rank the four DR strategies by cost versus recovery speed;
• study four AWS-published resilience case studies, two of them added in this revision;
• learn what AWS actually launched between 2025 and October 2026: Regions, Local Zones and announced-but-not-open plans;
• practise with 12 exam-style questions plus four interactive checks.

---

1. Regions, Availability Zones and edge locations

1.1 The three definitions, in AWS's own words

Three facts about the relationship do most of the exam work:

1. A Region contains at least three AZs: "Each AWS Region consists of a minimum of three, isolated, and physically separate AZs within a geographic area" (as of Oct 2026: 39 Regions and 124 AZs live, with 7 more AZs and 2 more Regions announced for the Kingdom of Saudi Arabia and Chile).
2. AZs do not share single points of failure. Task 3.2 in the exam guide explicitly requires knowledge that "Availability Zones do not share single points of failure."
3. Edge locations are a delivery layer, not a compute layer. Benefits of edge locations, per the exam guide, are latency and offload for delivery: never "run my application here".

1.2 Example E1: reconciling the AZ count

AWS's statistics block says 124 AZs (as of Oct 2026). The AZ ID tables in the global-infrastructure documentation cover only the 34 Regions a standard account can see. Reconcile the two:

The arithmetic only closes if the published 124 counts the Regions that exist today, not the announced-but-not-yet-open Saudi Region. Announced additions (+7 AZs, +2 Regions) are plans, never launch facts: the exam will not credit you for treating an announcement as an opening.

1.3 What each layer is for

• 📚 Did you know? AWS interconnects "all AZs … with high-bandwidth, low-latency networking over fully redundant, dedicated metro fiber", encrypts all traffic between AZs, and states the performance "is sufficient to accomplish synchronous replication between AZs." The AZs are "physically separated by a meaningful distance, many kilometers" yet "all are within 100 km (60 miles) of each other" (as of Oct 2026). That tight-but-not-tiny envelope is exactly why multi-AZ synchronous replication is possible and why an entire Region can still be knocked out by one regional event.

1.4 Where the Regions are (as of Oct 2026)

Counting the launched Regions by geography gives a useful sanity check on "global reach" claims, and it shows why you cannot assume your preferred Region exists:

Two lessons follow. First, "AWS has no Region in X" is a legitimate exam answer: service availability is a real Region-selection factor, not a formality, because a defined set of core services ships with every Region launch while a further tier "usually launch within 12 months of a new Region launch." Second, counts shift every quarter: treat the table as a snapshot stamped as of Oct 2026, and re-check AWS's global-infrastructure pages before quoting any figure outside this lesson. (This research could not reconcile every map entry with AWS's own documentation table, so the "listed" column is a map count, not an official total.)

2026 Updates (as of October 2026)

Global infrastructure did not stand still while you were revising. What follows is every dated, AWS-published infrastructure addition from 2025 to 26 found in this research cycle: launches carry a date, plans do not, and only launches count:

• 📚 Did you know? 2025 was the densest year for Region openings in this research cycle, four Regions in just over eight months (Thailand 2025-01-07, Mexico 2025-01-14, Taipei 2025-06-06, New Zealand 2025-09-02), yet AWS's headline figure published in Oct 2026 was still 39 Regions and 124 AZs. Every one of those openings comes with AWS's design minimum of at least three isolated, physically separate AZs, which is why the AZ total and the Region total rise together rather than independently.

---

2. Why Regions are isolated: fault tolerance, data residency, latency

2.1 Fault tolerance: separate failure domains on purpose

Regions are isolated so that no single regional event can take down everything you run. The mechanism is fault isolation, AWS's prescriptive guidance defines it as restricting "the scope of impact to an intended fault container when a failure occurs", and states that "Redundancy, Fault tolerance is achieved through redundancy that eliminates single points of failure (SPOFs)."

Fault tolerance itself has a precise definition: "the ability to withstand subsystem failure and maintain availability (doing the right thing within an established SLA). To implement fault tolerance, workloads use spare (or redundant) subsystems." Hot spares cost money; that cost is why fault tolerance sits above plain high availability on the price ladder.

2.2 Data residency and sovereignty

Some workloads may only legally or contractually run in a specific geography. AWS gives you three nesting levels of residency control:

1. Region level: choose a Region inside the required jurisdiction (and, where needed, a special account type such as AWS GovCloud (US) or the AWS China Regions);
2. Local Zone level: AWS describes Local Zones as a way to "address data residency requirements" by letting you "control where your workloads run and where your data resides" in a specific metro;
3. Wavelength Zone level: data "stays within the geographic boundaries you specify" when you place compute inside a carrier's 5G facility.

2.3 Latency: proximity is a design input

AWS's Region documentation is direct: "you can lower network latency when you select a Region that is close to the majority of your users" (as of Oct 2026). The practical consequence is a two-tier rule:

• Compute that must be close to users → pick the nearest Region that has the services you need, or a Local Zone / Wavelength Zone in that metro;
• Content that can be cached → leave the workload in one Region and let CloudFront's 750+ PoPs (as of Oct 2026) shorten the path for everyone else.

2.4 Example E2: redundancy multiplies availability

AWS's reliability documentation shows the arithmetic of independent components. Two components that are each 99.9% available, failing independently, combine as:

$$1 - (0.001 \times 0.001) = 1 - 10^{-6} = 0.999999 = \mathbf{99.9999\%}$$

That is the promise behind running in two AZs: each AZ's failure probability is (roughly) independent of the other's, so the pair is vastly more available than either member. The same formula explains the downside: three hard dependencies that are each 99.99% cap the whole workload at:

$$0.9999^3 = 0.9997 = \mathbf{99.97\%}$$

One weak link lowers the ceiling of an otherwise excellent architecture. This is the exam's favourite resilience arithmetic: redundancy helps only when the redundant parts are genuinely independent (different AZs, not two servers in one rack).

---

3. Choosing a Region: compliance, latency, price and features

3.1 The four factors (plus two you forget)

The order matters more than the list: on the exam, a stated legal or regulatory boundary beats every other factor, and "it is cheaper elsewhere" never wins when residency is in play. AWS's own wording for the cost factor is conditional: deploy in a pricier Region only when latency, residency or sovereignty requires it.

3.2 Example E3: the availability budget per year

Availability percentages are annual budgets, not per-outage guarantees. 8,760 hours in a year:

Read it as a budget: a workload promised at 99.9% has already spent a third of its annual allowance after 2 hours 55 minutes of downtime. That is why a business requirement of "four nines or better" changes your architecture; it pushes you from single-AZ to multi-AZ, and eventually from one Region to two.

Chart the same table and the shape of the budget is unmistakable: each extra nine is roughly a tenfold cut in the downtime you are allowed:

• 📚 Did you know? AWS operates "nearly 20 million kilometers" of network fiber as of Oct 2026, and Region pricing is not uniform: the Well-Architected cost pillar explicitly tells you to "Identify Regional cost differences" rather than assume a global price list. Local Zone resources are also priced above their parent Region (as of Oct 2026): proximity costs money. Any option that claims "identical pricing in every Region" is wrong on its face.

3.3 Example E4: why "39 Regions" is not what your account sees

Three different Region totals circulate in AWS documentation, and only one of them is what your console shows (all as of Oct 2026):

Check the arithmetic: $39 - 2 - 2 - 1 = 34$, and $34 - 17 = 17$. The exam uses this to test whether you confuse launched, visible and enabled:

If a question says "all 39 Regions are available to every customer by default", it is wrong on two counts at once: account type and opt-in status.

---

4. The Availability Zone design rule

4.1 Two different numbers, both correct

This is the single most reliably examined distinction in Domain 3, and candidates miss it by conflating two rules that answer different questions:

So: AWS gives you ≥3; you must use ≥2. A question describing your architecture with only one AZ's subnets is describing a single point of failure: regardless of how many AZs the Region happens to contain. AWS also notes you can "run in multiple AZs to achieve even greater fault-tolerance", i.e. three is available if your budget and complexity tolerance allow it.

4.2 AZ IDs versus AZ codes

A subtle trap that has appeared on real exams:

• AZ codes (us-east-1a, us-east-1b) are account-relative: in older Regions, the letter a given account sees is mapped to a different physical data centre for different accounts (accounts created before November 2025).
• AZ IDs (euw1-az1, use1-az1) identify the same physical location in every AWS account: the safe identifier for cross-account rules, landing zones and network peerings.

As of Oct 2026 the AZ ID tables list 109 AZ IDs across the 34 standard Regions. Rule of thumb for the exam: if a question involves two accounts, the answer involves AZ IDs, not letters.

4.3 Example E5: does your design use the AZs you were given?

A Region with 3 AZs (as of Oct 2026, the most common configuration) runs an application with an ALB whose subnets all sit in one AZ, one EC2 instance, and a database with no standby:

Fix in priority order: (1) add subnets and instances in a second AZ (ALB minimum, removes the AZ single point of failure); (2) enable a multi-AZ database deployment (synchronous standby in the second AZ); (3) only then consider a second Region with a DR strategy for regional failure. Step 1 costs the least and removes the failure the exam asks about most often.

---

5. Edge services: CloudFront, Route 53 and Global Accelerator

All three sit in front of your Regions, and all three show up in Task 3.2 as benefits of edge locations. The exam distinguishes them by entry plane: DNS answers, cached content, or a static anycast IP address.

5.1 Amazon CloudFront: the cache/CDN plane

• "Reduce latency by delivering data through 750+ globally dispersed Points of Presence (PoPs)": 750+ PoPs in 100+ cities across 50+ countries, plus 1,140+ embedded PoPs across 300+ cities inside ISPs, and 15 Regional edge caches that sit inside a Region (all as of Oct 2026).
• Mechanics: DNS resolves the user to the nearest PoP → on a cache hit the PoP answers → on a cache miss it fetches from your origin (Amazon S3, an ALB, a media origin) and caches the result.
• SLA: at least 99.9% monthly uptime (as of Oct 2026).
• Exam use: caching and delivering content close to users, plus origin failover as a documented traffic-shifting lever for DR.

5.2 Amazon Route 53: the DNS plane

• "Route 53 uses a global network of DNS servers at a series of world-wide locations to offer you high availability and increased performance."
• Routing policies the exam names: latency, geoproximity, IP-based, failover and weighted: plus health checks, which is how automated DNS failover is achieved.
• SLA: unavailable "only if all four virtual name servers assigned to the Hosted Zone fail to respond to all DNS queries"; service credits begin below 100% uptime (as of Oct 2026).
• The catch you must memorise: DNS answers are cached by resolvers according to TTL, so a failover can take as long as the TTL you configured.

5.3 AWS Global Accelerator: the anycast IP plane

• "Improve network performance for your applications by up to 60%" and provide "fast failover for multi-Region and multi-AZ architectures" with "deterministic routing by removing DNS cache dependencies" (claims as of Oct 2026).
• Gives your application static IP addresses anycast from the AWS edge network: clients connect to a fixed IP, and traffic is steered at the edge to healthy endpoints.
• 130 Points of Presence in 95 cities across 53 countries (as of Oct 2026).
• The exam use: non-HTTP or IP-allowlist-sensitive workloads and failover that must not wait for DNS TTL.

5.4 The three-plane comparison

• 📚 Did you know? The three services can be stacked rather than chosen in isolation: Route 53 resolves a friendly name, CloudFront serves the cached front end from the nearest of 750+ PoPs (as of Oct 2026), and Global Accelerator carries the API traffic on static anycast IPs to two Regions with health-check failover. AWS's disaster-recovery whitepaper lists exactly these three, Route 53, Global Accelerator and CloudFront origin failover, as the traffic management toolkit for shifting users during recovery.

5.5 Example E6: the DNS TTL window is part of your failover time

Suppose a Route 53 failover record has a TTL of 300 seconds, and the primary endpoint fails at t = 0. A recursive resolver that asked for the answer 240 seconds before the failure still holds a valid cached answer:

Nothing here condemns DNS failover, Route 53 health checks and failover routing are a documented DR traffic-management lever, and for global DNS policy (latency, geoproximity, weighted) it is the correct answer. The examinable point is arithmetic about your own objectives: if the stated RTO is 60 seconds and your failover record's TTL is 300 seconds, the DNS layer alone can blow the budget, and the stem is pointing you at Global Accelerator (static anycast IPs, "deterministic routing by removing DNS cache dependencies") or at shortening the TTL. Always treat TTL as an invisible component of recovery time, as of Oct 2026 AWS publishes no default failover time, so the number you configure is the number you get.

---

6. The hybrid edge continuum: Local Zones, Wavelength, Outposts and Snow

Not every workload belongs in a Region core. AWS offers a continuum from fully AWS-operated, deep inside a Region to hardware sitting in your own building: the exam tests whether you can place each option on that continuum.

Three clarifications that exam questions love to blur:

• Local Zones are AWS-deployed; Outposts are customer-deployed. Both present the same AWS APIs, so the deciding stem phrase is "in a metro AWS operates" (Local Zone) versus "in my data centre" (Outposts).
• Wavelength is carrier-embedded; you do not choose it for residency alone; you choose it when the workload must sit next to a 5G/telecom network.
• Snowball is a transfer device, not a compute destination, and AWS has published a hard date: "On December 31, 2026, AWS will discontinue support for AWS Snowball devices in all AWS commercial Regions" (Storage Optimized and Compute Optimized), while GovCloud and ADC Region customers with active Snow jobs are unaffected (announcement as of Oct 2026).

• 📚 Did you know? AWS's Local Zones product page describes "30+ metros worldwide" across six continents (as of Oct 2026), while AWS's global-infrastructure statistics block publishes a different Local Zones figure and its location page lists more city headings than either; this research could not reconcile those counts, so treat any Local Zone total as unverified and re-check before quoting it. The same caution applies to Wavelength Zones (the stats block and the counted zone codes disagree). Counts move; relationships don't.

---

7. Resilience vocabulary: fault tolerance, high availability, disaster recovery

7.1 Five terms, five meanings

AWS's "what is high availability" page adds the boundary the exam tests verbatim: "High-availability systems are not a part of disaster recovery … Disaster recovery is about getting your systems back up and running if your existing HA systems fail." In other words: HA keeps it up; DR brings it back. Fault tolerance is the more expensive cousin of HA; it does not merely recover quickly, it never visibly stops.

7.2 RTO and RPO: the two numbers a DR plan lives or dies by

Both are defined by your organization, not by AWS (as of Oct 2026):

• RTO: Recovery Time Objective: "the maximum acceptable delay between the interruption of service and restoration of service." → how long you are allowed to be down.
• RPO: Recovery Point Objective: "the maximum acceptable amount of time since the last data recovery point." → how much data you are allowed to lose.

Direction is where candidates lose marks: RTO = downtime, RPO = data loss. A larger RPO window is worse (more data lost); a larger RTO is worse (longer outage). For measurement, RTO behaves like MTTR, and RPO always sits before the disaster on the timeline.

7.3 Example E7: reading RTO and RPO off a timeline

A database fails at 12:00. The most recent usable backup was written at 09:00, and the service was restored at 14:00.

$$RPO = 12{:}00 - 09{:}00 = \mathbf{3\ hours\ of\ acceptable\ data\ loss}, \qquad RTO = 14{:}00 - 12{:}00 = \mathbf{2\ hours\ of\ downtime}$$

Now flip it into a requirement: the business declares RTO ≤ 1 minute, RPO ≤ 1 second for checkout. A 3-hour RPO and 2-hour RTO fail both targets by orders of magnitude: the answer is a strategy with continuous replication (warm standby or multi-site active-active), not a better backup schedule. And if the business instead declares RTO ≤ 24 hours, RPO in hours, backup and restore may satisfy it at the lowest cost of the four strategies.

7.4 Availability, fault tolerance and DR are three different questions

7.5 Turning a question stem into the right term

The fastest way to score on vocabulary is to read the time shape of the stem rather than its nouns:

Two sentences close the vocabulary loop: "HA keeps a running workload running; fault tolerance keeps serving through a failure; DR restores a workload that went down." And AWS's own boundary sentence, "High-availability systems are not a part of disaster recovery", means a question offering "our multi-AZ design satisfies our DR requirements" is offering a trap: multi-AZ covers one AZ failing, not the whole Region.

---

8. Disaster recovery strategies: cost versus recovery speed

8.1 The four strategies and their published bands

The Well-Architected Reliability Pillar (REL13-BP02) publishes the objective bands, and the DR whitepaper publishes the cost/complexity shape (all as of Oct 2026):

The sentence that decides most pilot-light-vs-warm-standby questions: "pilot light cannot process requests without additional action taken first, while warm standby can handle traffic (at reduced capacity levels) immediately." (A warm standby run at full capacity is often called a hot standby.)

8.2 Example E8; which strategy fits the objective?

The business publishes these objectives (all as of Oct 2026):

Cost and recovery move together: as you demand smaller RTO/RPO you buy more idle capacity. The exam's pattern is to hand you one number ("RTO in tens of minutes") and ask for the strategy: tens of minutes is the pilot-light signature; seconds RPO with minutes RTO is warm standby; near zero / potentially zero is active-active.

8.3 Traffic shifting and testing: the DR mechanics

Recovery is useless if users cannot reach the recovered copy. AWS's DR whitepaper names the traffic-management toolkit explicitly:

And the discipline that makes any of it real: "regularly assess and test your disaster recovery strategy." AWS Resilience Hub exists to validate your stated RTO and RPO targets against your actual architecture (as of Oct 2026). An untested DR plan is a hypothesis, not a strategy.

• 📚 Did you know? AWS's reliability pillar publishes an availability math table you can reuse verbatim: 99% → 3 days 15 hours, 99.9% → 8 hours 45 minutes, 99.95% → 4 hours 22 minutes, 99.99% → 52 minutes, 99.999% → 5 minutes of downtime per year (as of Oct 2026). Pair it with the DR bands and you can convert any business SLA into a strategy: four nines of availability cannot be met by a once-a-day restore, and five nines essentially mandates warm standby or active-active plus automatic recovery.

8.4 Active/passive, hot/warm, and the three questions to ask first

The DR vocabulary has two extra axes that exam questions slide in without warning:

Before any strategy is chosen, AWS's DR whitepaper makes you settle three decisions:

1. What are the numeric RTO and RPO? Both are "defined by the organization": without numbers, every strategy "qualifies" and none is justified.
2. What is the write topology? Active-active only makes sense when writes can be handled across Regions (global, local or partitioned writes): a read-mostly workload and a globally partitioned one have completely different costs.
3. What will idle capacity cost, and has the strategy been tested? AWS's whitepaper instructs teams to "regularly assess and test your disaster recovery strategy", and AWS Resilience Hub validates the stated RTO and RPO targets against the architecture (as of Oct 2026).

A useful exam heuristic: if the stem gives you numbers and a budget, work down the ladder from active-active until the objectives are still met at the lowest cost; if the stem gives you numbers and says cost is no object, the answer is the fastest strategy that meets them.

---

9. Design for failure: the operating principles

9.1 The Well-Architected reliability design principles

Infrastructure choices only pay off when they are paired with operating habits. The Well-Architected reliability design principles (as of Oct 2026) are short enough to memorise:

AWS's architecture blog distils the mindset to Vogels's line, "Everything fails, all the time", and adds that "we should design with failure in mind … The AWS Well-Architected Framework is designed to help you prepare your workload for failure." The connected-mobility lens states the corollary as a hard requirement: "The architecture should ensure that there isn't any single point of failure."

9.2 The anti-patterns the exam calls wrong

---

Real-World Case Studies

AWS publishes what these patterns look like in production. Every figure below is customer- or AWS-claimed and unaudited, quoted so you can check the source: the examinable point is the pattern (which failure domain was being protected, which service did the shifting, which objective moved), not the marketing number.

Case A, Capital One: automated Regional failover (multi-Region resilience)

Exam lesson: Capital One's resilience page is a multi-Region story, while its migration page is a cost/agility story: do not mix their numbers (the migration page's DR test time −70% and dev environment 3 months → minutes belong to a different case page). What makes this a resilience case is the combination of automated failover + Route 53 traffic shifting + continuous testing.

Case B, Amazon Prime Video: six Regions for one live broadcast (global scale resilience)

Exam lesson: this is what "use of multiple Regions" (exam-guide Task 3.2) looks like when the reason is global reach and low latency, not sovereignty. Note that six Regions were used for delivery and processing, while CloudFront still carried the last mile: the edge layer and the Region layer solve different parts of the same problem.

Case C, Bangkok Flight Services: multi-AZ disaster recovery for a cargo handler

Exam lesson: this is the ≥2-AZ application design rule bought as a business outcome. With no DR site on premises, the first AWS resilience move was multi-AZ inside one Region: high availability and fault isolation, not multi-Region disaster recovery. If the stem asks what protects against an AZ failing, Bangkok is the shape of the answer; if it asks about the whole Region failing, this design alone is not enough.

Case D, NASA JPL / Perseverance: fault-tolerant scale for a mission you cannot retry

Exam lesson: Perseverance is the Well-Architected pair "scale horizontally to increase aggregate workload availability" and "stop guessing capacity" in production: a burst of telemetry is absorbed by more small units rather than one bigger one, and Spot is affordable because the work is fault-tolerant and interruptible; which is exactly how AWS frames which workloads Spot is for. Note the date on the blog: a 2021 mission story with an Oct 2026 access date, never presented as a fresh figure.

What all four cases share

• 📚 Did you know? The four cases stack into one failure-domain ladder: Bangkok Flight Services protects the AZ (multi-AZ inside one Region), Capital One protects the Region (automated Regional failover, hours → minutes), Prime Video protects global delivery (six Regions plus the CloudFront edge), and NASA JPL protects capacity itself (Auto Scaling over Spot and On-Demand, 4.4 TB of telemetry a day). Different rungs, same rule: match the rung to the failure the stem describes, and never pay for a higher rung than the one you were asked about.

---

Practice Questions