← Fundamentals

▶ Play from here · 354 min

Starts this lesson and continues through 33 more to the end of certification prep.

The resilience taxonomy — zonal, Regional and global services

Why this lesson matters

Task 2.2's first skill line is "Determining the AWS services required to provide a highly available and/or fault-tolerant architecture across AWS Regions or Availability Zones" (domain 2 page, fetched 2026-09-25). You cannot do that without knowing, for each service, what failure it already survives on its own — and therefore what you have to add.

That is the taxonomy:

First: what AWS does and doesn't publish

The plan for this module said: "I have not found a single authoritative AWS page that enumerates it per service." That was half right, and the correction matters.

What exists: the whitepaper AWS Fault Isolation Boundaries (publication date on the page: November 16, 2022; fetched 2026-09-25). Its abstract, verbatim:

"This paper details how AWS uses these boundaries to create zonal, Regional, and global services."

So the taxonomy is AWS's own vocabulary, not a course invention.

What doesn't exist, as far as I found: an exhaustive per-service table. The whitepaper defines each category and gives examples — and for global services, explicit named lists — but it does not classify every AWS service. ⚠️ So the table in this lesson is built service by service, from each service's own documentation, and each row says where it came from. Where a service page doesn't state its scope in those terms, the row says so.

Zonal services

From Zonal services, verbatim:

"Availability Zone Independence (AZI) enables AWS to offer zonal services, like Amazon EC2 and Amazon EBS. A zonal service is one that provides the ability to specify which Availability Zone the resources are deployed into. These services operate independently in each Availability Zone within a Region, and more importantly, fail independently in each Availability Zone as well."

The definitional test is in that sentence: if you choose the AZ, it's zonal.

EC2 instance — zonal

EC2 Regions and Zones, fetched 2026-09-25:

"When you launch an instance, you select a Region and a virtual private cloud (VPC). Then, you can either select a subnet from one of the Availability Zones or let us choose a subnet for you."

"If you distribute instances across multiple Availability Zones and an instance fails, you can design your application so that an instance in another Availability Zone handles requests instead."

And the reason an instance can't span zones, from Subnets for your VPC: "Each subnet must reside entirely within one Availability Zone and cannot span zones."

EBS volume — zonal

Amazon EBS volumes, fetched 2026-09-25:

"You can attach multiple EBS volumes to a single instance. The volume and instance must be in the same Availability Zone."

⚠️ This is the most-tested zonal fact. "Attach the existing EBS volume to an instance in another AZ" is impossible as written; the volume has to go via a snapshot. (EBS snapshots' own scope isn't stated on the page I fetched — ⚠️ read the EBS snapshots page before quoting one.)

The zonal lesson: static stability

The same whitepaper page gives the arithmetic worth memorising:

"during normal operation, let's assume your workload requires six instances to serve customer traffic across three Availability Zones. To be statically-stable against a single Availability Zone failure, you would deploy three instances in each Availability Zone, for a total of nine. … you are running 50% additional instances."

And why not just rely on Auto Scaling to replace the lost AZ's capacity:

"deploying new instances through auto scaling relies on the EC2 control plane."

That's the data-plane/control-plane rule from SAA2 lesson 6, arriving at the zonal level.

Regional services

From Regional services, verbatim:

"Regional services are services that AWS has built on top of multiple Availability Zones so that customers don't have to figure out how to make the best use of zonal services. We logically group together the service deployed across multiple Availability Zones to present a single Regional endpoint to customers. Amazon SQS and Amazon DynamoDB are examples of Regional services. … Amazon S3, for example, spreads requests and data across multiple Availability Zones and is designed to automatically recover from the failure of an Availability Zone."

The test: if you only ever talk to a Regional endpoint and never pick an AZ, it's Regional.

S3 — Regional (with one zonal storage class)

Data protection in Amazon S3, fetched 2026-09-25:

"S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, and S3 Glacier Deep Archive redundantly store objects on multiple devices across a minimum of three Availability Zones in an AWS Region."

"The S3 One Zone-IA storage class stores data redundantly across multiple devices within a single Availability Zone."

⚠️ So "S3 is Regional" has an exception you choose. One Zone-IA trades AZ resilience for price. In an exam stem, "data can be recreated" or "secondary copy" is the signal that One Zone-IA is acceptable; anything else and it's the distractor.

DynamoDB — Regional

What is Amazon DynamoDB?, fetched 2026-09-25:

"By default, DynamoDB automatically replicates your data across three Availability Zones to provide high durability and a 99.99% availability SLA."

And the step up to multi-Region: "DynamoDB global tables enable a 99.999% availability SLA and multi-Region resilience."

SQS — Regional (per the whitepaper; the SQS page says "servers", not AZs)

The whitepaper names SQS as Regional. The SQS developer guide, fetched 2026-09-25, says only:

"For the safety of your messages, Amazon SQS stores them on multiple servers."

⚠️ The SQS page I fetched does not say "multiple Availability Zones". The Regional classification here rests on the whitepaper, not on the SQS guide.

EFS — your choice

What is Amazon EFS?, fetched 2026-09-25:

"Regional (Recommended) – Regional file systems (recommended) store data redundantly across multiple geographically separated Availability Zones within the same AWS Region."

"One Zone – One Zone file systems store data within a single Availability Zone. … In the unlikely case of the loss or damage to all or part of the Availability Zone, however, data that is stored in these types of file systems might be lost."

RDS — zonal instance, Regional deployment if you pay for it

Multi-AZ DB instance deployments, fetched 2026-09-25:

"In a Multi-AZ DB instance deployment, Amazon RDS automatically provisions and maintains a synchronous standby replica in a different Availability Zone."

"The high availability option isn't a scaling solution for read-only scenarios. You can't use a standby replica to serve read traffic."

So RDS is the cleanest example of a service whose resilience scope is a configuration decision: a single-AZ DB instance lives and dies with its AZ; Multi-AZ buys you AZ resilience. SAA2 lesson 5 covers what Multi-AZ doesn't buy.

Regional is not multi-Region

From the same whitepaper page, and it's the sentence that defeats most "we're resilient" claims:

"AWS believes that most customers can achieve their resilience goals in a single Region by using Regional services or Multi-AZ architectures that rely on zonal services."

"AWS does not provide a synchronous Cross-Region replication feature at this time. When using an asynchronously replicated datastore … across Regions, there is the possibility of data loss or inconsistency when you fail over…"

That second line is why cross-Region RPO is never zero in SAA2 lesson 6.

Global services

From Global services, verbatim:

"there is a small set of AWS services whose control planes and data planes don't exist independently in each Region. Because their resources are not Region-specific, they are commonly referred to as global. … The significant difference for most global services is that their control plane is hosted in a single AWS Region, while their data plane is globally distributed."

⚠️ "Global" does not mean "no single Region". It means the data plane is everywhere and the control plane is in one place. That is the whole exam-relevant point.

The whitepaper names three kinds, each with an explicit list.

1. Partitional services — one per partition

"In the aws partition, the IAM service's control plane is in the us-east-1 Region, with isolated data planes in each Region of the partition."

The named list, verbatim, with control-plane location:

2. Global services in the edge network

"Route 53 operates its control plane in the us-east-1 Region, but its data plane is distributed across hundreds of PoPs globally, as well as each AWS Region… Route 53 health checks are also part of the data plane, and are performed from eight AWS Regions."

Named list, verbatim: Route 53 Public DNS (us-east-1), Amazon CloudFront (us-east-1), AWS WAF Classic for CloudFront and AWS WAF for CloudFront (us-east-1), ACM for CloudFront (us-east-1), AWS Global Accelerator (us-west-2), AWS Shield Advanced (us-east-1).

That list is why SAA1 taught that an ACM certificate for CloudFront must be in us-east-1: the CloudFront control plane is there.

3. Global single-Region operations — inside Regional services

The subtle one. Some control-plane operations of Regional services depend on one Region:

"Amazon S3 bucket names are globally unique and all calls to the CreateBucket and DeleteBucket APIs depend on us-east-1, in the aws partition, to ensure name uniqueness, even though the API call is directed at the specific Region in which you want to create the bucket."

And a list of S3 bucket-configuration calls (PutBucketPolicy, PutBucketReplication, PutBucketEncryption, PutBucketVersioning and others) with "an underlying dependency on us-east-1". Plus: creating an ELB, API Gateway REST API or OpenSearch domain creates Route 53 records, so it depends on the Route 53 control plane.

And the default-endpoint trap: "STS usage from the AWS software development kit (SDK) and command line interface (CLI) defaults to us-east-1." The recommendation: "Update your SDK and CLI configuration to use the Regional STS endpoints."

The anti-patterns, verbatim

The whitepaper's own list of mistakes that put a global control plane in your recovery path:

• "Making changes to Route 53 records, like updating an A record's value or changing a weighted record set's weights, to perform failover."
• "Creating or updating IAM resources, including IAM roles and policies, during a failover."
• "Making changes to AGA traffic dial weights to manually perform a Regional failover."
• "Updating a CloudFront distribution's origin configuration to fail away from an impaired origin."
• "Provisioning disaster recovery (DR) resources, like ELBs and RDS instances during a failure event, that depend on creating DNS records in Route 53."

Every one of those matches a control-plane row in SAA2 lesson 6's data plane table. The fix is always the same: pre-provision, and fail over with data-plane operations only.

The taxonomy table

Built per service. Source column says which page backs each row.

FIB = AWS Fault Isolation Boundaries whitepaper.

⚠️ Not in the table because I didn't fetch their pages: ELB, Lambda, ElastiCache, Aurora, NAT gateway, Global Accelerator's data plane behaviour. SAA1 lesson 3 already flagged that NAT gateways now have a Regional mode — read nat-gateways-regional.html before classifying it from habit.

Check yourself

1. What single test tells you a service is zonal?
2. Name the three kinds of global service in the whitepaper, and one example of each.
3. Where is IAM's control plane, and what does that mean for a DR runbook that creates a new role?
4. Your company keeps logs in S3 One Zone-IA "because S3 is Regional". What's wrong?
5. Is there an AWS feature for synchronous cross-Region replication?

Answers

1. You choose the AZ. "A zonal service is one that provides the ability to specify which Availability Zone the resources are deployed into."
2. Partitional (IAM), edge network (CloudFront, Route 53 public DNS), global single-Region operations (S3 CreateBucket depending on us-east-1).
3. us-east-1. The runbook depends on a control plane in one Region during a failure — the whitepaper lists "Creating or updating IAM resources… during a failover" as an anti-pattern. Pre-create the role.
4. One Zone-IA "stores data… within a single Availability Zone". It's the one S3 class that isn't AZ-resilient.
5. No. "AWS does not provide a synchronous Cross-Region replication feature at this time."

Teaching this section

• Say the correction out loud: "There is an AWS whitepaper that names the three categories — but no table that classifies every service. So we build the table ourselves, one service page at a time." That's the method, and it transfers to any service not in this lesson.
• Best whiteboard: three columns — zonal, Regional, global — and have the room place ten services. Then reveal which ones the docs actually confirm. The SQS row is a good moment: the classification is right, but the SQS page doesn't say it.
• Discussion prompt: "IAM is global. Is it a single point of failure?" The answer — data plane no, control plane yes — is the lesson.
• Watch for: "global = no Region dependency"; "S3 is always multi-AZ"; "RDS is Regional".
• Timing: 30 minutes. The table exercise takes 10.