Regions

AWS provides a more extensive global footprint than any other cloud provider, and to support its global footprint and ensure customers are served across the world, AWS opens new Regions rapidly. AWS maintains multiple geographic Regions, including Regions in North America, South America, Europe, China, Asia Pacific, South Africa, and the Middle East.

One amazing thing to acknowledge is the sheer size of the AWS global network, and what that means for us and our infrastructure. Not only do we get access to a rediculous amount of AWS services, we also get choose where in the world we want our infrastructure to exist.

There are currently 36 regions, but amazon is constantly trying to expand their global footprint and add more regions. Here's the current state of the AWS world as of 2025:

World Map

Each of those dots on the map is a region, it's a physical location in the world where AWS has built some data centres. And we must select a single region to deploy most of our infrastructure. https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/

Regions are a core part of AWS and cloud computing in general.

In the top right of the AWS console, we can see which region we're currently working in and we can switch to another region at any time.

Almost anything we deploy on AWS is going to exist inside of a single region.

AWS Console region selector dropdown in the top navigation bar

Let's say we want to deploy an EC2 instance and we select us-east-1 as our region. We're going to be running a virtual machine inside of a computer owned by Amazon that is physically located in North Virginia.

Or if we setup an S3 bucket in ca-west-2, then we're going to have storage that is physically located in Calgary.

America Map

It's important to remember that "the cloud" is just a bunch of physical data centres. And physical data centers have to exist in a physical location. And when we deploy infrastructure to "the cloud", most of our infrastructure will need to exist in a single region.

Of course, we can deploy infrastructure in multiple regions. For example, we could have a web app that is horizontally scaled across the globe. We could deploy ec2 instances everywhere and they can all communicate with each other over Amazon's fast backbone network.

We can achieve global scale in multiple ways when we're using a cloud provider like AWS. But that doesn't change the fact that each individual server, bucket, network, etc. will exist in a single region.

Choosing a Region

So the cloud is just a bunch of data centers in different regions around the world, and we are responsible for choosing the right region for our infrastructure. But which region should we choose?

Here are the four main factors to consider:

One of the most critical factors in choosing a region is compliance. Different countries and regions have their own laws about where data can be stored, like GDPR in Europe, PIPEDA in Canada, or industry-specific requirements like HIPAA.

If you're a healthcare company in Germany, you might be legally required to keep patient data within German borders, so you'd want to use the eu-central-1 (Frankfurt) region.

2. Proximity to Your Customers

The speed of light is still a limiting factor when it comes to serving data across the globe. The closer your infrastructure is to your users, the faster your application will respond.

Approximate latency measurements from CloudPing.co:
FromToLatency
us-west-1 (N. California)us-west-2 (Oregon)19ms
us-west-1 (N. California)us-east-1 (N. Virginia)72ms
us-west-1 (N. California)eu-west-1 (Ireland)140ms
us-west-1 (N. California)ap-southeast-2 (Sydney)176ms

Those milliseconds add up. If most of your users are in Australia, it makes sense to deploy in the Sydney region rather than North Virginia.

3. Available Services Within a Region

Not all AWS services are available in all regions. When AWS launches a new service or feature, it's typically available in the primary regions first like us-east-1.

Here's a quick glance at the number of services available in each region:

World Map

171

199

225

95

218

186

166

111

135

230

206

120

164

238

135

154

189

215

132

119

138

119

77

189

112

77

92

211

118

167

144

219

109

If you need access to cutting-edge AWS services, you might be limited in which regions you can choose. But you can check out the AWS Regional Services List to see what's available.

4. Pricing Variations Between Regions

AWS doesn't charge the same price across all regions. Pricing can vary significantly based on factors like local infrastructure costs, energy prices, and regional taxes.

Example: EC2 t4g.micro instance prices (cents per hour):
RegionLocationPrice (cents/hour)
us-east-1N. Virginia8.4
us-west-1N. California10
ca-central-1Canada9.2
eu-west-1Ireland9.2
ap-northeast-1Tokyo10.8
sa-east-1São Paulo13.4

These differences might seem small, but they can add up dramatically when you're running hundreds of instances or storing terabytes of data.

Show timestamps
00:00
When we're deploying infrastructure to a cloud provider like AWS, it's not just that we're
00:06
getting to rent a piece of infrastructure and pay for what we use. We also get access to all
00:11
the locations around the world where they have data centers.
00:15
So, these are all the regions in AWS.
00:18
Currently, I think there are around thirty-seven. You can see as I hover over all the different
00:22
places—some in Canada, in the US, in Europe, Australia—so a bunch of places all around the world.
00:29
And we can choose where we deploy our infrastructure into any of these regions. This is a
00:34
really important concept in AWS. So if we go into the console, I'm just gonna go into the
00:40
playground account for now. In the top right corner, once it loads, you'll always see which region
00:45
you're currently working in. So right now, I have Ohio, US East 2, selected, but I can scroll
00:51
down this list and select any of those regions that you saw there.
00:55
And this is where we'll deploy infrastructure to. So if I were to change this to US West 2,
01:00
anything I deploy here now—so if I set up S3 or an EC2 instance—this would be
01:05
deployed in that single region. This is really important to consider because it will be
01:10
literally physically located in the place we specify. So if I set up a bucket in CA West 1,
01:17
that's going to exist in Canada. All my data, all my storage, is going to exist in Canada, in Calgary. And
01:22
if I were to set up a server in US East 1, then all of my servers and compute would be
01:28
running in North Virginia. So in a sense, this is the cloud—it's just a bunch of data centers
01:33
distributed globally, and we can deploy to the cloud, but we still have to select a region
01:39
in the world where our infrastructure exists. We need to select a data center that physically exists
01:44
in a location. And we could deploy infrastructure to multiple regions and connect them over AWS's
01:50
private network and essentially horizontally scale globally, but we still need to select each
01:55
individual region where our infrastructure will exist. And this isn't true for all services—we'll
02:00
get to the global network and edge locations later on—but for the most part, you will have to
02:04
select a region before you create any infrastructure. And this is an important consideration
02:09
because you have to factor in things like compliance. If you're working with people in the EU,
02:15
it might be required that you keep your data in the EU, so you might have to select one of the
02:19
regions in the EU. Or, I'm an instructor in Canada, so if I'm working with some of my students'
02:24
data, I'm required to keep that data inside Canada. So I might deploy my infrastructure over here
02:29
in Calgary and make sure it never leaves Canada. There are also things like proximity to your
02:33
customers. So if you know all of your customers are going to be in Australia, it would be a really
02:37
bad idea to deploy your infrastructure anywhere other than in Australia, because the latency—
02:42
just the time it takes for data to travel around the world—can really impact the performance of
02:47
your applications. There are also certain services that might not be provided in a region. This is a
02:53
map where the number of services that you can use are labeled here.
02:58
So we can see that US East 1, North Virginia, is the flagship location.
03:02
This probably will always have the most services. When there's a new
03:05
service, AWS usually rolls it out in this location.
03:08
So there are two hundred and thirty-eight different services that we can use here. But if I look
03:12
at Calgary—that's CA West 1—there are only ninety-five available services. The basic ones
03:18
will almost always be available. I can always set up an S3 bucket or an EC2 instance.
03:22
But if there is some cutting-edge new service that AWS has just released—like right now, DSQL
03:27
with Aurora has been released in preview mode—that is only available in some locations like US
03:33
East 1. And then on top of all of that, the pricing for the same service will be different
03:38
depending on which region you choose. So right here, I have a list of a couple of regions. If you
03:44
were to just set up a really basic EC2 instance, this is the price in cents per hour that you
03:49
would pay depending on which region you choose. So, if electricity, taxes, or land are just
03:55
cheaper in North Virginia, that allows an EC2 instance to be cheaper in North Virginia than it
03:59
would be in California. And these little nuances kind of change globally. So if you're looking for
04:04
the most cost-effective option, you would have to look at which regions are providing the service
04:09
you want at the lowest cost, while also being close enough to your users. And most importantly,
04:15
you have to make sure that you're not breaking any compliance laws. So that's regions in a
04:19
nutshell. We're going to talk more about regions, availability zones, and edge locations throughout the course.
04:24
But the next thing I want to do is actually just set up some infrastructure in a region so we can get a feel for how we use AWS.