AWS Global Infrastructure

A Region is a separate geographic area, identified by a code such as us-east-1 (N. Virginia), eu-west-1 (Ireland) or ap-southeast-2 (Sydney). Each Region is completely independent of the others: its own control plane, its own service endpoints (ec2.us-east-1.amazonaws.com) and its own set of resources. A resource created in one Region is invisible in another, and data never leaves a Region unless you configure replication or copy it yourself. That isolation limits the blast radius of a failure and is the basis of AWS' data-residency commitments: content stays in the Region you pick unless you move it.

Almost every resource in this section is regional: a VPC, an ECS cluster, a Lambda function, an RDS instance or an SQS queue exists in exactly one Region. The most common beginner error is looking at the right account in the wrong Region and concluding that a resource has vanished.

An Availability Zone is one or more discrete data centers inside a Region, with redundant power, networking and connectivity, housed in separate facilities. A Region has at least three AZs (a few have more; for example us-east-1 has six), and AZs in a Region are connected by high-bandwidth, low-latency private fiber that is fast enough for synchronous replication. They are physically separated by a meaningful distance so a fire, flood or power failure in one is unlikely to affect another, yet close enough that an application can span them without noticeable latency.

AZs are how you build high availability on AWS. A subnet lives in exactly one AZ, a VPC spans every AZ of its Region, and multi-AZ services (an Application Load Balancer, an Auto Scaling group, RDS Multi-AZ, Aurora, an ECS service) spread capacity across the subnets you give them. Designing for one AZ failing is the baseline expectation; designing for a whole Region failing is a separate, more expensive decision covered in Architecture, migration and hybrid.

Zone names versus zone IDs. The name us-east-1a in your account is mapped to a physical zone independently of the same name in another account, so that load does not concentrate on "a". When two accounts must agree on the same physical zone (for example when sharing subnets or a VPC endpoint service), compare the zone ID (use1-az1), which is the same for everyone.

Regions launched on or before 20 March 2019 are enabled by default in every account: the 17 Regions us-east-1, us-east-2, us-west-1, us-west-2, ap-south-1, ap-northeast-1, ap-northeast-2, ap-northeast-3, ap-southeast-1, ap-southeast-2, ca-central-1, eu-central-1, eu-west-1, eu-west-2, eu-west-3, eu-north-1 and sa-east-1. Every Region introduced after that date is an opt-in Region, disabled until you enable it for the account. At the time of writing this includes Cape Town (af-south-1), Hong Kong (ap-east-1), Hyderabad, Jakarta, Malaysia, Melbourne, New Zealand, Taipei, Thailand, Calgary (ca-west-1), Milan, Spain, Zurich, Tel Aviv (il-central-1), Mexico (mx-central-1), Bahrain and the UAE.

Enabling a Region distributes IAM resources (users, roles, groups) to it, which usually takes minutes but can take hours, and the Region cannot be used or disabled until that finishes. Enabling is free; you pay only for what you run. Disabling a Region removes access to it but does not delete resources already created there, so clean up first. Opt-in Regions also differ in practice: global service endpoints and some legacy STS tokens behave differently for them, and a few services or features arrive later than in older Regions. In an AWS Organization the management account (or a delegated administrator) can enable or disable Regions for member accounts, and a Service Control Policy can additionally deny actions in Regions you do not want used (see Accounts and Organizations).

Three offerings extend a Region towards where users or data actually are. All of them are managed through the control plane of a parent Region and appear in your account as extra zones of that Region.

Because each of these is a thin extension, only some services run in them, instance types and prices differ from the parent Region, and traffic back to the Region is billed as data transfer. Check service availability before designing around one.

Edge locations (also called points of presence, or PoPs) are sites in many more cities than there are Regions. They terminate user connections close to the user and serve cached content or forward traffic over the AWS backbone instead of the public internet. They do not run your general compute: they host a specific set of global services, namely Amazon CloudFront (including CloudFront Functions and its regional edge caches), Amazon Route 53 DNS, AWS Global Accelerator, AWS WAF at the edge and AWS Shield. See Amazon CloudFront and Route 53 and certificates for how to use them. Edge locations are not a place you deploy to, so there is nothing to select in the console or CLI. Their locations and the regional edge caches are listed on the infrastructure site (see References).

A partition is a group of Regions that share an ARN namespace, an IAM and billing system and a sign-in domain. Most customers only ever use the standard partition, aws. Three other partitions are isolated from it: an identity, IAM user or resource from one partition does not exist in another, and you cannot peer VPCs or assume roles across partitions. The partition appears as the second field of every ARN (arn:aws:s3:::bookshelf-uploads-111122223333 versus arn:aws-us-gov:s3:::…​), so hard-coding arn:aws: in policies or templates breaks them elsewhere; use the AWS::Partition pseudo parameter in CloudFormation or the Partition helpers of the SDKs.

Treat a non-standard partition as a separate deployment target from day one: accounts, IAM, CLI profiles (aws configure with the partition’s endpoints), AMIs, marketplace listings and some service features all differ. Because identities are separate, plan their access with Identity and access separately for each partition.

Selecting a Region is a trade-off across four criteria, and rarely does one Region win on all of them.

Beyond those, us-east-1 is the oldest and largest Region and the place some global control planes live: IAM and billing are global services, but CloudFront certificates from ACM must be requested in us-east-1, and a few account-wide features are only configurable there. Treat it as a special case and avoid putting production workloads there only because it is the default. Within a Region, spread subnets over at least two (preferably three) AZs, and keep every resource of a request path in the same AZ where practical to reduce cross-AZ transfer charges.

Knowing a service’s scope tells you where to look for it and how it fails.

Pick the broadest scope that meets the availability goal: prefer regional or multi-AZ configurations over zonal ones, and keep zonal resources such as EBS volumes in the same AZ as the instances that use them. Services that can span Regions (S3 Cross-Region Replication, DynamoDB global tables, Aurora Global Database, KMS multi-Region keys, Route 53 failover) are opt-in features, not defaults.

Pricing and limits for this topic are mostly indirect: the infrastructure itself is free, but data transfer between AZs, between Regions and out to the internet is billed, public IPv4 addresses are charged per hour, and some Local Zone and Wavelength Zone resources cost more than the parent Region. Quotas (service quotas) are applied per Region, so a limit raised in one Region does not apply in another. Older guides still show only the original handful of Regions and describe every Region as enabled by default, which no longer holds; always check the opt-in status.