Regions and Zones
Amazon EC2 is hosted in multiple locations world-wide. These locations are composed of AWS Regions, Availability Zones, Local Zones, AWS Outposts, and Wavelength Zones.
-
Each Region is a separate geographic area.
-
Availability Zones are multiple, isolated locations within each Region.
-
Local Zones provide you the ability to place resources, such as compute and storage, in multiple locations closer to your end users.
-
AWS Outposts brings native AWS services, infrastructure, and operating models to virtually any data center, co-location space, or on-premises facility.
-
Wavelength Zones allow developers to build applications that deliver ultra-low latencies to 5G devices and end users. Wavelength deploys standard AWS compute and storage services to the edge of telecommunication carriers' 5G networks.
AWS operates state-of-the-art, highly available data centers. Although rare, failures can occur that affect the availability of instances that are in the same location. If you host all of your instances in a single location that is affected by a failure, none of your instances would be available.
Regions
Each Region is designed to be isolated from the other Regions. This achieves the greatest possible fault tolerance and stability.
When you view your resources, you see only the resources that are tied to the Region that you specified. This is because Regions are isolated from each other, and we don't automatically replicate resources across Regions.
When you launch an instance, you must select an AMI that's in the same Region. If the AMI is in another Region, you can copy the AMI to the Region you're using. For more information, see Copy an Amazon EC2 AMI.
Note that there is a charge for data transfer between Regions. For more information,
see Amazon EC2 Pricing -
Data Transfer
Available Regions
Your account determines the Regions that are available to you.
-
An AWS account provides multiple Regions so that you can launch Amazon EC2 instances in locations that meet your requirements. For example, you might want to launch instances in Europe to be closer to your European customers or to meet legal requirements.
-
An AWS GovCloud (US-West) account provides access to the AWS GovCloud (US-West) Region and the AWS GovCloud (US-East) Region. For more information, see AWS GovCloud (US)
. -
An Amazon AWS (China) account provides access to the Beijing and Ningxia Regions only. For more information, see Amazon Web Services in China
.
The following table lists the Regions provided by an AWS account. You can't describe or access additional Regions from an AWS account, such as the AWS GovCloud (US) Regions or the China Regions. To use a Region introduced after March 20, 2019, you must enable the Region. For more information, see Specify which AWS Regions your account can use in the AWS Account Management Reference Guide.
Code | Name | Opt-in status |
---|---|---|
us-east-1 | US East (N. Virginia) | Not required |
us-east-2 | US East (Ohio) | Not required |
us-west-1 | US West (N. California) | Not required |
us-west-2 | US West (Oregon) | Not required |
af-south-1 | Africa (Cape Town) | Required |
ap-east-1 | Asia Pacific (Hong Kong) | Required |
ap-south-2 | Asia Pacific (Hyderabad) | Required |
ap-southeast-3 | Asia Pacific (Jakarta) | Required |
ap-southeast-5 | Asia Pacific (Malaysia) | Required |
ap-southeast-4 | Asia Pacific (Melbourne) | Required |
ap-south-1 | Asia Pacific (Mumbai) | Not required |
ap-northeast-3 | Asia Pacific (Osaka) | Not required |
ap-northeast-2 | Asia Pacific (Seoul) | Not required |
ap-southeast-1 | Asia Pacific (Singapore) | Not required |
ap-southeast-2 | Asia Pacific (Sydney) | Not required |
ap-northeast-1 | Asia Pacific (Tokyo) | Not required |
ca-central-1 | Canada (Central) | Not required |
ca-west-1 | Canada West (Calgary) | Required |
cn-north-1 | China (Beijing) | Not required |
cn-northwest-1 | China (Ningxia) | Not required |
eu-central-1 | Europe (Frankfurt) | Not required |
eu-west-1 | Europe (Ireland) | Not required |
eu-west-2 | Europe (London) | Not required |
eu-south-1 | Europe (Milan) | Required |
eu-west-3 | Europe (Paris) | Not required |
eu-south-2 | Europe (Spain) | Required |
eu-north-1 | Europe (Stockholm) | Not required |
eu-central-2 | Europe (Zurich) | Required |
il-central-1 | Israel (Tel Aviv) | Required |
me-south-1 | Middle East (Bahrain) | Required |
me-central-1 | Middle East (UAE) | Required |
sa-east-1 | South America (São Paulo) | Not required |
For more information, see AWS Global
Infrastructure
Regional endpoints
When you work with an instance using the command line interface or API actions, you must specify its Regional endpoint. For more information about the Regions and endpoints for Amazon EC2, see Amazon EC2 service endpoints in the Amazon EC2 Developer Guide.
For more information about endpoints and protocols in AWS GovCloud (US-West), see Service Endpoints in the AWS GovCloud (US) User Guide.
Availability Zones
Each Region has multiple, isolated locations known as Availability
Zones. The code for Availability Zone is its Region code followed by a
letter identifier. For example, us-east-1a
.
When you launch an instance, you select a Region and a virtual private cloud (VPC), and then you can either select a subnet from one of the Availability Zones or let us choose one for you. If you distribute your instances across multiple Availability Zones and one instance fails, you can design your application so that an instance in another Availability Zone can handle requests. You can also use Elastic IP addresses to mask the failure of an instance in one Availability Zone by rapidly remapping the address to an instance in another Availability Zone.
The following diagram illustrates multiple Availability Zones in an AWS Region. Availability Zone A and Availability Zone B each have one subnet, and each subnet has instances. Availability Zone C has no subnets, therefore you can't launch instances into this Availability Zone.
![A Region with instances in one Availability Zone.](/images/AWSEC2/latest/UserGuide/images/region-with-azs.png)
As Availability Zones grow over time, our ability to expand them can become constrained. If this happens, we might restrict you from launching an instance in a constrained Availability Zone unless you already have an instance in that Availability Zone. Eventually, we might also remove the constrained Availability Zone from the list of Availability Zones for new accounts. Therefore, your account might have a different number of available Availability Zones in a Region than another account.
AZ IDs
To ensure that resources are distributed across the Availability Zones for a
Region, we independently map Availability Zones to codes for each AWS account
in our oldest Regions. For example, the us-east-1a
for
your AWS account might not be the same physical location as the
us-east-1a
for another AWS account.
To coordinate Availability Zones across accounts in all Regions even those
that map Availability Zones, use the AZ IDs, which are
unique and consistent identifiers for an Availability Zone. For example,
use1-az1
is an AZ ID for the us-east-1
Region,
and it has the same physical location in every AWS account. You can view
the AZ IDs for your account to determine the physical location of your resources
relative to the resources in another account. For example, if you share a subnet in
the Availability Zone with the AZ ID use1-az2
with another account,
this subnet is available to that account in the Availability Zone whose AZ ID is
also use1-az2
.
To view the AZ IDs for your account, check the Service health
panel on the EC2 Dashboard
The following diagram illustrates two accounts with different mappings of Availability Zone code to AZ ID.
![Two accounts with different mappings of Availability Zone code to AZ ID.](/images/AWSEC2/latest/UserGuide/images/availability-zone-mapping.png)
Available Availability Zones
Each Region has multiple Availability Zones, as shown in the following list.
-
US East (N. Virginia) –
use1-az1
|use1-az2
|use1-az3
|use1-az4
|use1-az5
|use1-az6
-
US East (Ohio) –
use2-az1
|use2-az2
|use2-az3
-
US West (N. California) –
usw1-az1
|usw1-az2
|usw1-az3
† -
US West (Oregon) –
usw2-az1
|usw2-az2
|usw2-az3
|usw2-az4
-
Africa (Cape Town) –
afs1-az1
|afs1-az2
|afs1-az3
-
Asia Pacific (Hong Kong) –
ape1-az1
|ape1-az2
|ape1-az3
-
Asia Pacific (Hyderabad) –
aps2-az1
|aps2-az2
|aps2-az3
-
Asia Pacific (Jakarta) –
apse3-az1
|apse3-az2
|apse3-az3
-
Asia Pacific (Malaysia) –
apse5-az1
|apse5-az2
|apse5-az3
-
Asia Pacific (Melbourne) –
apse4-az1
|apse4-az2
|apse4-az3
-
Asia Pacific (Mumbai) –
aps1-az1
|aps1-az2
|aps1-az3
-
Asia Pacific (Osaka) –
apne3-az1
|apne3-az2
|apne3-az3
-
Asia Pacific (Seoul) –
apne2-az1
|apne2-az2
|apne2-az3
|apne2-az4
-
Asia Pacific (Singapore) –
apse1-az1
|apse1-az2
|apse1-az3
-
Asia Pacific (Sydney) –
apse2-az1
|apse2-az2
|apse2-az3
-
Asia Pacific (Tokyo) –
apne1-az1
|apne1-az2
|apne1-az3
|apne1-az4
-
Canada (Central) –
cac1-az1
|cac1-az2
|cac1-az4
-
Canada West (Calgary) –
caw1-az1
|caw1-az2
|caw1-az3
-
Europe (Frankfurt) –
euc1-az1
|euc1-az2
|euc1-az3
-
Europe (Ireland) –
euw1-az1
|euw1-az2
|euw1-az3
-
Europe (London) –
euw2-az1
|euw2-az2
|euw2-az3
-
Europe (Milan) –
eus1-az1
|eus1-az2
|eus1-az3
-
Europe (Paris) –
euw3-az1
|euw3-az2
|euw3-az3
-
Europe (Spain) –
eus2-az1
|eus2-az2
|eus2-az3
-
Europe (Stockholm) –
eun1-az1
|eun1-az2
|eun1-az3
-
Europe (Zurich) –
euc2-az1
|euc2-az2
|euc2-az3
-
Israel (Tel Aviv) –
ilc1-az1
|ilc1-az2
|ilc1-az3
-
Middle East (Bahrain) –
mes1-az1
|mes1-az2
|mes1-az3
-
Middle East (UAE) –
mec1-az1
|mec1-az2
|mec1-az3
-
South America (São Paulo) –
sae1-az1
|sae1-az2
|sae1-az3
-
AWS GovCloud (US-East) –
usge1-az1
|usge1-az2
|usge1-az3
-
AWS GovCloud (US-West) –
usgw1-az1
|usgw1-az2
|usgw1-az3
† Newer accounts can access two Availability Zones in US West (N. California).
Instances in Availability Zones
When you launch an instance, select a Region that puts your instances closer to specific customers, or meets the legal or other requirements that you have. By launching your instances in separate Availability Zones, you can protect your applications from the failure of a single location in the Region.
When you launch an instance, you can optionally specify an Availability Zone in the Region that you are using. If you do not specify an Availability Zone, we select an Availability Zone for you. When you launch your initial instances, we recommend that you accept the default Availability Zone, because this allows us to select the best Availability Zone for you based on system health and available capacity. If you launch additional instances, specify an Availability Zone only if your new instances must be close to, or separated from, your running instances.
Local Zones
A Local Zone is an extension of an AWS Region in geographic proximity to your users. Local Zones have their own connections to the internet and support AWS Direct Connect, so that resources created in a Local Zone can serve local users with low-latency communications. For more information, see What is AWS Local Zones? in the AWS Local Zones User Guide.
The code for a Local Zone is its Region code followed by an identifier that indicates its
physical location. For example, us-west-2-lax-1
in Los Angeles.
The following diagram illustrates the AWS Region us-west-2
, two of its
Availability Zones, and two of its Local Zones. The VPC spans the Availability Zones and
one of the Local Zones. Each zone in the VPC has one subnet, and each subnet has an
instance.
![A VPC with Availability Zones and Local Zones.](/images/AWSEC2/latest/UserGuide/images/region-with-lzs.png)
Available Local Zones
For the list of available Local Zones, see Available Local Zones
in the AWS Local Zones User Guide.
For the list of announced Local Zones, see AWS Local Zones locations
Instances in Local Zones
To use a Local Zone, you must first enable it. Then, create a subnet in the Local Zone. You can specify the Local Zone subnet when you launch instances, which places it in the Local Zone subnet in the Local Zone.
When you launch an instance in a Local Zone, you also allocate an IP address from
a network border group. A network border group is a unique set of Availability
Zones, Local Zones, or Wavelength Zones from which AWS advertises IP addresses,
for example, us-west-2-lax-1a
. You can allocate the following IP
addresses from a network border group:
-
Amazon-provided Elastic IPv4 addresses
-
Amazon-provided IPv6 VPC addresses (available only in the Los Angeles zones)
For more information about how to launch an instance in a Local Zone, see Getting started with AWS Local Zones in the AWS Local Zones User Guide.
Wavelength Zones
AWS Wavelength enables developers to build applications that deliver ultra-low latencies to mobile devices and end users. Wavelength deploys standard AWS compute and storage services to the edge of telecommunication carriers' 5G networks. Developers can extend a virtual private cloud (VPC) to one or more Wavelength Zones, and then use AWS resources like Amazon EC2 instances to run applications that require ultra-low latency and a connection to AWS services in the Region.
A Wavelength Zone is an isolated zone in the carrier location where the Wavelength infrastructure is deployed. Wavelength Zones are tied to a Region. A Wavelength Zone is a logical extension of a Region, and is managed by the control plane in the Region.
The code for a Wavelength Zone is its Region code followed by an identifier that
indicates the physical location. For example, us-east-1-wl1-bos-wlz-1
in
Boston.
The following diagram illustrates the AWS Region us-west-2
, two of its
Availability Zones, and a Wavelength Zone. The VPC spans the Availability Zones and the
Wavelength Zone. Each zone in the VPC has one subnet, and each subnet has an
instance.
![A VPC with Availability Zones and a Wavelength Zone.](/images/AWSEC2/latest/UserGuide/images/region-with-wavelength-zones.png)
Wavelength Zones are not available in every Region. For information about the Regions that support Wavelength Zones, see Available Wavelength Zones in the AWS Wavelength Developer Guide.
Available Wavelength Zones
For the list of available Wavelength Zones, see Available Wavelength Zones in the AWS Wavelength Guide.
Instances in Wavelength Zones
To use a Wavelength Zone, you must first opt in to the Zone. Then, create a subnet
in the Wavelength Zone. You can specify the Wavelength subnet when you launch instances.
You also allocate a carrier IP address from a network border group, which is a
unique set of Availability Zones, Local Zones, or Wavelength Zones from which AWS
advertises IP addresses, for example, us-east-1-wl1-bos-wlz-1
.
For step-by-step directions to launch an instance in a Wavelength Zone, see Get started with AWS Wavelength in the AWS Wavelength Developer Guide.
AWS Outposts
AWS Outposts is a fully managed service that extends AWS infrastructure, services, APIs, and tools to customer premises. By providing local access to AWS managed infrastructure, AWS Outposts enables customers to build and run applications on premises using the same programming interfaces as in AWS Regions, while using local compute and storage resources for lower latency and local data processing needs.
An Outpost is a pool of AWS compute and storage capacity deployed at a customer site. AWS operates, monitors, and manages this capacity as part of an AWS Region. You can create subnets on your Outpost and specify them when you create AWS resources. Instances in Outpost subnets communicate with other instances in the AWS Region using private IP addresses, all within the same VPC.
The following diagram illustrates the AWS Region us-west-2
, two of its
Availability Zones, and an Outpost. The VPC spans the Availability Zones and the
Outpost. The Outpost is in an on-premises customer data center. Each zone in the VPC has
one subnet, and each subnet has an instance.
![A VPC with Availability Zones and an Outpost.](/images/AWSEC2/latest/UserGuide/images/region-with-outpost.png)
Instances on an Outpost
To begin using AWS Outposts, you must create an Outpost and order Outpost capacity.
AWS Outposts offers two form factors, Outposts racks and Outposts servers. For
more information about Outposts configurations, see AWS Outposts Family
To launch EC2 instances you must create an Outpost subnet. Security groups control inbound and outbound traffic for instances in an Outpost subnet, just as they do for instances in an Availability Zone subnet. To connect to an EC2 instance in an Outpost subnet, you can specify a key pair when you launch the instance, just as you do for instances in an Availability Zone subnet to allow connections using SSH.
For more information, see Get started with Outposts racks or Get started with Outposts servers.
Volumes on an Outposts rack
If your Outposts compute capacity is on an Outpost rack, you can create EBS volumes in the Outpost subnet that you created. When you create the volume, specify the Amazon Resource Name (ARN) of the Outpost.
The following create-volume command creates an empty 50 GB volume on the specified Outpost.
aws ec2 create-volume --availability-zone
us-east-2a
--outpost-arn arn:aws:outposts:us-east-2
:123456789012
:outpost/op-03e6fecad652a6138
--size50
You can dynamically modify the size of your Amazon EBS gp2 volumes without detaching them. For more information about modifying a volume without detaching it, see Request modifications to your EBS volumes in the Amazon EBS User Guide.
We recommend that you limit the root volume for an instance on an Outpost rack to
30 GiB or smaller. You can specify data volumes in the block device mapping of the
AMI or the instance to provide additional storage. To trim unused blocks from the
boot volume, see How to Build Sparse EBS Volumes
We recommend that you increase the NVMe timeout for the root volume. For more information, see I/O operation timeout in the Amazon EBS User Guide.
Volumes on an Outposts server
Instances on Outposts servers provide instance store volumes but do not support EBS volumes. Choose an Amazon EBS-backed AMI with only a single EBS snapshot. Choose an instance size with enough instance storage to meet the needs of your application. For more information, see Instance store limits.