AWS is not a single giant computer: it is a network of data centers distributed around the world, organized into regions. Understanding what a region is and how to choose the right one is one of the first practical decisions you’ll make, and it affects the speed, cost, and legality of your project.

What is a region

An AWS region is a geographical area of the world where AWS has a group of data centers. Each region is independent from the others.

Some examples of regions (with their code, which you’ll use a lot):

Region Location Code
Europe (Ireland) Dublin eu-west-1
Europe (Frankfurt) Germany eu-central-1
Europe (Spain) Aragon eu-south-2
US East (Northern Virginia) Virginia us-east-1
Asia Pacific (Tokyo) Japan ap-northeast-1
South America (São Paulo) Brazil sa-east-1

There are dozens of regions all over the planet, and AWS frequently adds new ones. The code (eu-west-1, etc.) is the technical name you’ll see in the console and in Terraform code.

Why there are multiple regions

Having data centers in many locations solves three things:

  1. Proximity to users → less latency (the app runs faster).
  2. Legal compliance → some data must remain in a specific country.
  3. Resilience → if a region has a serious problem, you can operate from another.

Important: regions are intentionally isolated from each other. If you deploy something in Ireland, it doesn’t automatically appear in Tokyo. This is good for security and fault tolerance, but it means that you decide where everything goes.

How to choose the right region

Choosing a region is a decision worth considering. These are the four key factors:

  1. Proximity to your users (latency)

The closer the region is to your users, the faster your application will be.

Example: If your customers are in Spain, choose a European region (Spain, Ireland, or Frankfurt), not one in Tokyo. Data traveling back and forth to Japan would add a noticeable delay.

  1. Legal compliance and data sovereignty

Some laws require that citizens’ data be stored within certain borders.

Example: The European GDPR makes many companies prefer to keep European customer data in EU regions. We’ll see this in subchapter 3.4.

  1. Cost

Prices vary between regions. The same server may cost differently in Virginia than in São Paulo.

Useful fact: us-east-1 (Northern Virginia) is usually one of the cheapest and where new services appear first. But if your users are in Europe, the savings don’t make up for the latency.

  1. Available services

Not all regions have all services. Newer or smaller regions may not yet have the latest services. Before choosing, check that the region has what you need.

A special case: us-east-1

The Northern Virginia region (us-east-1) is AWS’s oldest and “central” region. Two things to know:

  • It’s where AWS usually launches new services first.
  • Some global services (like certain billing features or the certificate service for CloudFront) require us-east-1, even if your users are elsewhere. You’ll see this later in the book.

Practical rule to start

If you’re learning or unsure, a good default rule:

Choose the region closest to you (or your users) that has the services you need.

For someone in Spain, Europe (Spain), Europe (Ireland), or Europe (Frankfurt) are sensible choices for most projects.

What you should remember

  • A region is a geographic area with AWS data centers; there are many around the world and each has a code (eu-west-1, us-east-1…).
  • Regions are isolated from each other: you decide where to put everything.
  • Choose a region based on latency (proximity), legality (data sovereignty), cost, and available services.
  • us-east-1 is special: the cheapest, where new services arrive first, and required by some global services.

In the next subchapter we’ll go one level deeper: within each region there are several availability zones (AZ), the key to high availability.

Cloud, AWS & Terraform — From Zero to Expert

Chapter 1 · What is cloud computing

Chapter 2 · The cloud market and major providers

Chapter 3 · Regions, availability zones and edge

Chapter 4 · Compute: EC2

Chapter 5 · Storage: S3

Chapter 6 · Networking: VPC

Chapter 7 · Identity and access: IAM

Chapter 8 · Managed databases

Chapter 9 · Why Infrastructure as Code

Chapter 10 · HCL: the Terraform language

Chapter 11 · Providers and state

Chapter 12 · Your first real infrastructure in Terraform

Chapter 13 · Load balancing and auto scaling

Chapter 14 · Serverless with Lambda

Chapter 15 · Messaging and events

Chapter 16 · Content delivery and DNS

Chapter 17 · Containers on AWS

Chapter 18 · Modules: reuse and composition

Chapter 19 · Workspaces and environment management

Chapter 20 · Remote backends and locking

Chapter 21 · Infrastructure testing

Chapter 22 · Terraform in CI/CD

Chapter 23 · Defense in depth

Chapter 24 · Observability: logs, metrics and traces

Chapter 25 · Cost optimization

Chapter 26 · High availability and disaster recovery

Chapter 27 · AWS Well-Architected Framework

Chapter 28 · Serverless architectures at scale

Chapter 29 · Data platforms on AWS

Chapter 30 · Multi-account and landing zones

Chapter 31 · Platform Engineering and Internal Developer Platform

Chapter 32 · Relevant AWS certifications

Chapter 33 · Projects to consolidate what you've learned

Chapter 34 · Resources and community

© Copyright 2024. All rights reserved