Navigation

AWS aws getting-started 6 min read

How to Choose a Region

An AWS Region is a physical location in the world (like Northern Virginia or Frankfurt) where AWS runs a cluster of data centers. When you create almost any resource, you must place it in a Region, and that single choice quietly affects how fast your app feels, how much you pay, whether you stay on the right side of data laws, and even which AWS features you can use at all. Picking the wrong Region rarely breaks things on day one, but it can cost you money and pain to fix later. This page walks through the four factors that matter and gives you a safe default to start with.

The four factors that decide a Region

Most Region decisions come down to four questions. Work through them in this order, because the first two are usually harder to undo than the last two.

Factor	What it affects	How much it can vary
Proximity to users (latency)	How fast the app feels	Tens to hundreds of milliseconds
Data residency / compliance	Whether you’re allowed to store data there	Pass/fail (legal)
Pricing	Your monthly bill	Often 10-30% between Regions
Service availability	Which features even exist	Some services missing entirely

Proximity to users (latency)

Latency is the delay between a user clicking something and getting a response. The closer your servers are to your users, the lower the latency, because data travels a shorter physical distance. A user in London hitting a server in Sydney can easily add 250+ milliseconds (ms) of round-trip delay; the same user hitting Frankfurt sees around 20 ms.

The rule is simple: host your app in the Region closest to the bulk of your users. If most of your customers are in Europe, pick eu-west-1 (Ireland) or eu-central-1 (Frankfurt). If they are on the US East Coast, pick us-east-1 (N. Virginia).

Tip: You can measure real latency yourself before committing. AWS publishes a public latency test at cloudping.info, or you can ping a Region’s endpoint directly. Don’t guess based on a map alone.

Data residency and compliance

Data residency means the legal requirement that certain data must physically stay inside a particular country or region. For example, the GDPR (General Data Protection Regulation, the EU’s privacy law) often pushes companies to keep EU citizens’ personal data inside EU Regions. Health, finance, and government data frequently carry similar rules.

When this matters: if you handle personal, medical, financial, or government data, treat compliance as a hard filter. Pick the Region first to satisfy the law, then optimize for latency and price among the Regions that qualify. When it does not matter: a hobby project or internal tool with no regulated data can ignore this entirely.

Per-Region pricing differences

AWS prices the same service differently per Region. Land, power, and operating costs differ around the world, and AWS passes that through. As a rule of thumb, us-east-1 (N. Virginia) is the oldest and usually the cheapest Region, while newer or remote Regions (like Sao Paulo or some Asia-Pacific Regions) cost noticeably more.

A t3.micro virtual server, for example, can cost meaningfully more in sa-east-1 (Sao Paulo) than in us-east-1 for the exact same machine. Over a fleet of servers running 24/7, a 20% difference adds up to real money.

Gotcha: Never choose a Region on price alone. Saving 20% on compute is pointless if your users sit 200 ms away and the app feels sluggish, or if a law forbids storing the data there. Price is the tie-breaker, not the headline.

Service and instance-type availability

Not every AWS service, and not every server (instance) type, exists in every Region. New services almost always launch in us-east-1 first and roll out to other Regions over months or years. A specialized GPU instance or a brand-new managed service might simply not be selectable in a smaller Region.

Always verify availability before you commit. Use the AWS CLI (the official command-line tool for AWS, version 2 in 2026) to check.

Check which Regions are enabled on your account:

aws ec2 describe-regions \
  --query "Regions[].RegionName" \
  --output table

Output:

-------------------------
|     DescribeRegions   |
+-----------------------+
|  us-east-1            |
|  us-west-2            |
|  eu-west-1            |
|  eu-central-1         |
|  ap-south-1           |
+-----------------------+

Check whether a specific instance type (for example m7g.large) exists in a Region:

aws ec2 describe-instance-type-offerings \
  --location-type region \
  --filters "Name=instance-type,Values=m7g.large" \
  --region eu-central-1 \
  --query "InstanceTypeOfferings[].InstanceType" \
  --output text

Output:

m7g.large

If the output is empty, that instance type is not offered in that Region and you must pick a different Region or instance.

A recommended default for beginners

If you are learning and have no compliance constraints and no specific user base yet, start with us-east-1 (N. Virginia). It is the cheapest, has every service available first, and almost every tutorial and Stack Overflow answer assumes it. Once you have real users in a known location, create new resources in the Region closest to them.

Cost note: A handful of services are global, not regional (such as IAM, Route 53, and CloudFront). The AWS console always points global services at us-east-1 behind the scenes, which is another reason it’s a sensible home base while learning.

How to set your Region

In the AWS Management Console

Sign in to the AWS Management Console.
Look at the top-right corner of the screen, next to your account name.
Click the Region dropdown (it shows the current Region, e.g. “N. Virginia”).
Pick the Region you want from the list. The console reloads scoped to that Region.

The console only ever shows resources in the currently selected Region. If a resource “disappears,” you are almost always just looking at the wrong Region.

In the AWS CLI

Set a default Region for your CLI profile so you don’t pass --region every time:

aws configure set region eu-central-1

You can override it per command with --region, or set it for one shell session with an environment variable:

export AWS_DEFAULT_REGION=eu-central-1

In infrastructure as code

If you manage infrastructure with code, set the Region in your provider configuration. In Terraform:

provider "aws" {
  region = "eu-central-1"
}

Best Practices

Decide compliance first, then latency, and use price only as a tie-breaker among the Regions that pass.
Confirm the services and instance types you need actually exist in your chosen Region with describe-instance-type-offerings before you build.
Keep all resources for one workload in the same Region to avoid cross-Region data transfer charges, which are billed per gigabyte.
Use us-east-1 as a learning default, but move production resources close to your real users.
Pin the Region explicitly in your CLI profile and IaC so resources never land somewhere unexpected.
Remember that global services (IAM, Route 53, CloudFront) are not affected by the Region selector, so don’t hunt for them in regional menus.