Global services and single-Region dependencies
Nearly every AWS service is Regional: its control plane and its data plane exist independently in each Region, and a failure in one Region does not reach another. A small number of services do not work that way, and a larger number of ordinary Regional services depend, somewhere in their control plane, on a single Region. Both matter for the same reason: a recovery plan that calls an API which happens to live in the Region that is currently failing is not a recovery plan.
Services that are global
Section titled “Services that are global”AWS separates these into two groups. In both, the control plane — the APIs that create, read, update, list and delete resources — runs in exactly one Region, while the data plane is distributed.
Partitional services
Section titled “Partitional services”Their data plane is isolated and distributed across every Region of the partition, but
configuration changes go to one Region. In the commercial aws partition:
| Service | Control plane Region |
|---|---|
| AWS Identity and Access Management (IAM) | us-east-1 |
| AWS Organizations | us-east-1 |
| AWS Account Management | us-east-1 |
| Route 53 private DNS | us-east-1 |
| Route 53 Application Recovery Controller | us-west-2 |
| AWS Network Manager | us-west-2 |
The GovCloud (aws-us-gov) and China (aws-cn) partitions run their own independent control and
data planes for these services.
Edge network services
Section titled “Edge network services”Their data plane runs in the global points of presence rather than in Regions, and can be reached from any partition and from the public internet.
| Service | Control plane Region |
|---|---|
| Route 53 public DNS | us-east-1 |
| Amazon CloudFront | us-east-1 |
| AWS WAF for CloudFront | us-east-1 |
| AWS Certificate Manager for CloudFront | us-east-1 |
| AWS Shield Advanced | us-east-1 |
| AWS Global Accelerator | us-west-2 |
AWS WAF and AWS Certificate Manager are only pinned to us-east-1 for their CloudFront scope. Used
in front of an Application Load Balancer or an API Gateway stage, both are ordinary Regional
services, and the certificate or web ACL must live in the same Region as the resource it protects.
Regional services with a single-Region dependency
Section titled “Regional services with a single-Region dependency”These services are Regional, but specific control-plane operations reach into one Region behind the scenes. The data-plane operations do not.
Route 53. Creating, updating or deleting a DNS record, hosted zone or health check depends on
the Route 53 control plane in us-east-1. That dependency is inherited by every service that
provisions a DNS name on a customer’s behalf: API Gateway REST and HTTP APIs, Elastic Load Balancing,
PrivateLink VPC endpoints, Lambda function URLs, ElastiCache, OpenSearch Service, MemoryDB,
Neptune, DynamoDB Accelerator, Global Accelerator, ECS DNS-based service discovery and the EKS
Kubernetes control plane. The VPC DNS service that resolves EC2 instance hostnames is the exception
— it exists independently in each Region and does not touch the Route 53 control plane.
Amazon S3. CreateBucket and DeleteBucket depend on us-east-1, because bucket names are
globally unique and uniqueness is settled there — even when the call targets another Region. A
group of bucket-configuration calls carries the same dependency, among them PutBucketPolicy,
PutBucketVersioning, PutBucketEncryption, PutBucketReplication, PutBucketLifecycle,
PutBucketNotification, PutBucketTagging and PutBucketPublicAccessBlock. The control plane for
S3 Multi-Region Access Points is hosted only in us-west-2.
CloudFront. Creating an edge-optimised API Gateway endpoint provisions a CloudFront
distribution, so it depends on the CloudFront control plane in us-east-1.
AWS STS. The SDKs and CLI default to the global STS endpoint, which resolves to us-east-1.
Regional STS endpoints exist and are enabled by default in Regions that are themselves enabled by
default; configure the SDK or CLI to use them. SigV4A signing requires credentials from a Regional
endpoint and cannot use the global one.
What to do about it
Section titled “What to do about it”AWS’s guidance is consistent across all of these: keep control-plane calls off the recovery path. In practice that means pre-provisioning the resources a failover needs — load balancers, DNS records, health checks, buckets, API Gateway endpoints — rather than creating them during an incident, and relying on data-plane operations to shift traffic. Where a recovery procedure needs data that only a control plane can produce, cache it somewhere with a highly available data plane, such as a Parameter Store parameter, a DynamoDB table or an S3 bucket, in more than one Region.
The common anti-patterns are worth naming, because they look reasonable in a runbook: editing Route 53 record values or weights to fail over, creating or amending IAM roles and policies during a failover, changing Global Accelerator traffic dials by hand, repointing a CloudFront origin away from an impaired one, and provisioning disaster-recovery resources that themselves need new DNS records.
Regional services with cross-Region features
Section titled “Regional services with cross-Region features”Being Regional does not mean being confined to one Region. These are the mechanisms a Regional service offers for reaching another:
Storage and data
- Amazon S3 Cross-Region Replication copies objects to a bucket in another Region.
- DynamoDB global tables replicate multi-active: every replica accepts reads and writes.
- Amazon RDS supports cross-Region read replicas; Aurora Global Database replicates a cluster to secondary Regions with a single writable primary.
- EBS snapshots and AMIs can be copied to another Region.
- AWS Backup copies backups across Regions.
Networking
- VPC peering connects VPCs in different Regions.
- Transit Gateway peering connects transit gateways in different Regions.
- A Direct Connect gateway associates one connection with VPCs in multiple Regions.
Security and management
- AWS Secrets Manager replicates a secret to other Regions. AWS Systems Manager Parameter Store has no equivalent — there is no built-in cross-Region replication for parameters, and AWS points at Secrets Manager where that is needed.
- AWS Config aggregators collect configuration and compliance data from several Regions and accounts into one view.
- CloudTrail can deliver logs to an S3 bucket in a different Region.
- CloudWatch dashboards can display metrics from more than one Region.
Deployment
- CloudFormation StackSets deploy a stack to many Regions and accounts from one operation.
- CodePipeline can run deploy actions in Regions other than the pipeline’s own.
- Lambda@Edge runs functions at CloudFront points of presence rather than in a Region.
Sources
Section titled “Sources”- Global services, AWS Fault Isolation Boundaries whitepaper — the authority for the control-plane Regions above.
- AWS Systems Manager Parameter Store — on what Parameter Store does and does not replicate.