Choosing a Region, and who secures what

By the end you'll know

The four things that decide a Region: the law, distance, services and price
How to compare Regions yourself, from AWS's own public lists and price data
Which services are global, which are Regional, and which live in one Availability Zone
The shared responsibility model: what AWS secures, what you secure, and how that moves from service to service
The jobs that stay yours on every service, however much AWS runs for you

Before you start

You need: the juniper-rye profile from Lesson 4, signed in. If it's been more than 12 hours, run aws login --profile juniper-rye again.
Cost: $0. Everything in this lesson only reads.
The script: compare-regions.sh from the practice folder's lesson-05. It prints public Region facts and prices only.
Where you run things: your own machine, labelled (Your machine).
Every output below is from a real run on November 9, 2026.

The short version

Choose a Region in this order: what the law requires, where your users are, which services you need, then price.
Prices differ by Region. The bakery's server costs $12.26 a month in Ohio and $19.56 in São Paulo.
Services differ by Region. The biggest Regions get new services first.
Some services are global, most are Regional, and some things live in a single Availability Zone. A Regional resource is invisible from every other Region.
AWS secures the cloud; you secure what you put in it. How much is yours depends on the service: on a server you patch the operating system, on S3 you never do.
Your data, and who can reach it, is always yours. No service takes that off you.

What this lesson costs

Part	Cost
Reading AWS's public Region lists through Systems Manager	$0
The Price List API	$0
Listing IAM roles and VPCs	$0
This lesson	$0, and nothing created

Choosing a Region

Lesson 1 showed where AWS's Regions are. Choosing one comes down to four questions, and AWS's own advice puts them in this order:

Question	Why it comes in this order	For the bakery
1. Does the law say where the data must live?	Data residency rules aren't negotiable: if customer data must stay in a country, only Regions in that country count. Everything else is a preference.	No rule for a US bakery's orders. Any US Region will do.
2. Where are the users?	Every request travels to the Region and back. A Region near your users is faster for them.	Customers are in the eastern US, so an eastern Region.
3. Does it have the services you need?	New services reach the largest Regions first, and smaller ones later, or not at all.	Everything the track uses, checked below.
4. What does it cost there?	Prices differ by Region, sometimes by more than half.	Checked below.

In the new sign-up, AWS answered the question for you: it chose us-east-2, Ohio, from your contact details, and the service control policy keeps you there. Most people still choose, and the rest of this section is how.

Compare six Regions yourself

In the console: The Region name at the top right of every page opens the list of Regions. Global services such as IAM show Global there instead.

(Your machine)

BASH

cd ~/Apps/aws-practice/lesson-05
chmod +x compare-regions.sh
./compare-regions.sh

OUTPUT

== Which services each Region has (AWS's public list, read through Systems Manager)
  Region          Name                         services ec2       s3        lambda    rds       eks       lightsail bedrock  
  us-east-1       US East (N. Virginia)             394 yes       yes       yes       yes       yes       yes       yes      
  us-east-2       US East (Ohio)                    310 yes       yes       yes       yes       yes       yes       yes      
  us-west-2       US West (Oregon)                  363 yes       yes       yes       yes       yes       yes       yes      
  eu-west-1       Europe (Ireland)                  347 yes       yes       yes       yes       yes       yes       yes      
  ap-southeast-2  Asia Pacific (Sydney)             342 yes       yes       yes       yes       yes       yes       yes      
  sa-east-1       South America (Sao Paulo)         266 yes       yes       yes       yes       yes       yes       yes      
== The same server in each Region: t4g.small, Linux, on demand (AWS Price List API)
  us-east-1       $0.0168 an hour, $ 12.26 for a 730-hour month
  us-east-2       $0.0168 an hour, $ 12.26 for a 730-hour month
  us-west-2       $0.0168 an hour, $ 12.26 for a 730-hour month
  eu-west-1       $0.0184 an hour, $ 13.43 for a 730-hour month
  ap-southeast-2  $0.0212 an hour, $ 15.48 for a 730-hour month
  sa-east-1       $0.0268 an hour, $ 19.56 for a 730-hour month
== Global and Regional: the same account, asked two ways
  IAM roles (global, no Region needed):            9
  VPCs in us-east-2  (Regional, one Region at a time): 1
  VPCs in us-west-2  (Regional, one Region at a time): denied, explicit deny in a service control policy

Services

AWS publishes which services run in which Region as public parameters in Systems Manager (SSM), a service you'll use properly in Lesson 11. Anyone can read them; the script counts them per Region and looks for seven by name.

N. Virginia has 394 entries, São Paulo 266: 128 fewer. Ohio, this account's Region, has 84 fewer than N. Virginia.
All seven services this track uses run in all six Regions, Bedrock included. For the bakery, services don't decide anything.
The counts include features and regional variants as well as whole services, so treat them as a measure of how much a Region has, not an exact number of products.

Price

The same small server, from AWS's Price List API:

Region	A month	Compared with Ohio
N. Virginia, Ohio, Oregon	$12.26	the same
Ireland	$13.43	9.5% more
Sydney	$15.48	26.2% more
São Paulo	$19.56	59.5% more

The difference is a few dollars for one small server, and it scales with everything you run. Lesson 1's bakery month of $56.15 would cost noticeably more in São Paulo, before data transfer. But price comes last for a reason: if the bakery's customers were in Brazil, São Paulo would still be the right Region, because faster pages for them matter more than a few dollars.

For the bakery: Ohio. Its customers are in the eastern US, it has every service the track uses, and it costs the same as N. Virginia. Being away from us-east-1, the most crowded Region and the one at the centre of Lesson 1's October 2025 outage, is a small bonus.

Global, Regional and zonal

The last part of the run asked the same account two different ways:

IAM is global. The 9 roles are in the account, not in a Region, so the question needed no Region at all. They're roles AWS created for the new sign-up, like the AccountFullAccessRole you sign in through.
VPCs are Regional. Ohio has 1 VPC, a default VPC AWS creates in each Region so there's somewhere to put a server straight away. Asking Oregon gave the service control policy's deny: in the new sign-up, the other Regions are closed.

Scope	Means	Examples
Global	One per account, the same everywhere	IAM, Route 53, CloudFront
Regional	Separate in each Region; invisible from the others	VPCs, Lambda functions, RDS, S3 buckets (their names are global, but each bucket lives in one Region)
Zonal	Lives in one Availability Zone	EC2 servers, EBS disks, subnets

This explains a common scare: you create something, switch the console to another Region by mistake, and it's "gone". It isn't. You're looking in the wrong Region. It also explains Lesson 2's warning about checking every Region after a compromise: a Regional resource only shows up where it is.

Who secures what

When the bakery rents a unit in a shopping centre, the centre's owners look after the building: the walls, the roof, the fire alarms and the guards at the doors. The bakery looks after what's inside: its till, its stock, who has a key to the back door, and whether the door is locked at night. If the bakery leaves the back door open, that's not the shopping centre's fault.

AWS calls this the shared responsibility model:

AWS is responsible for security of the cloud: the buildings, hardware, network and the software that runs AWS's services.
You are responsible for security in the cloud: what you build and store on it, and who can reach it.

Where the line falls depends on the service:

A grid of who secures what for EC2, RDS, Lambda and S3. Your data and who can reach it: you, on all four. Network access settings: you for EC2 and RDS; AWS for Lambda unless you put it in a VPC; you for S3, through bucket policies. Your application code: you for EC2 and Lambda; your queries and schema for RDS; none to run for S3. Operating system and software patches: you for EC2; AWS for RDS, where you pick the maintenance window; AWS for Lambda, where you pick the runtime version; AWS for S3. Hardware, network and buildings: AWS on every service. — Simplified from AWS's shared responsibility model. Read down a column for one service, or across a row for one job.

This is Lesson 1's places to live again, seen from the security side. On EC2, IaaS, the apartment, you keep everything inside running, patches included. RDS and Lambda are closer to PaaS, the serviced apartment: AWS does the repairs, and you bring your things. S3 is nearer the hotel, with nothing for you to run at all. But in every one of them, who gets a key is your decision.

Read it across the rows:

Patches move to AWS as you move right. On EC2 you run the server, so updating its operating system is your job. On RDS, AWS patches the database engine in a maintenance window you choose. On Lambda and S3 there's no server for you to patch.
The top row never moves. Who can read your data, whether it's encrypted, whether a bucket is public: those are yours on every service. Most cloud breaches you read about are a misconfiguration in that row, not a failure of AWS's buildings.

Not AWS's job

AWS won't stop you making your own data public, or patch a server you run. A bucket you open to the world, a database with a weak password, an EC2 server nobody updates: AWS's side can be perfect and you're still exposed. "It's on AWS, so it's secure" is the most expensive sentence in this track.

AWS describes some controls as shared, done by both sides, each in its own place:

Control	AWS does	You do
Patch management	Patches its infrastructure and managed services	Patches your operating systems and applications
Configuration management	Configures its own devices	Configures your systems, databases and applications
Awareness and training	Trains AWS staff	Trains your own people

Some controls you simply inherit, like the physical security of AWS's data centres: you couldn't do them if you tried. When an auditor asks, AWS publishes its own audit reports, such as SOC 2 (System and Organization Controls) reports and ISO certificates, free in AWS Artifact in the console, so you can show your side and point to AWS's.

In real systems

The Region is written down as a decision, with the reason: a data residency rule, the users' location, a service, the price. Changing it later means moving data, so it's rarely revisited.
Organizations block the Regions they don't use with a service control policy, exactly like the one you just hit. Fewer Regions means fewer places for a forgotten or stolen resource to hide.
Teams prefer managed services partly for the patching. Moving from EC2 to RDS, Lambda or containers on Fargate moves whole rows of work to AWS's side.
The shared responsibility split shows up in security reviews: for each service, who patches, who configures, who checks. Lesson 38's review uses it.

Spot the problem

Work out what's wrong before you read the explanation.

"It's on AWS, so it's patched." The bakery runs its ordering site on an EC2 server set up 18 months ago. Nobody has logged in since; everyone assumed AWS keeps it up to date. A security scan finds a known, fixed flaw in the server's operating system, from over a year ago. What went wrong? On EC2, the operating system is the customer's job. AWS patches the hardware and the systems that run EC2, not the operating system inside your server. The fix: turn on automatic patching with Systems Manager Patch Manager (Lesson 11), or move the site to a service where AWS patches the operating system, like containers on Fargate or Lambda. Then check: when was each server last patched, and who is named as responsible?

Keep this

Remember	Why
Law, users, services, price, in that order	A legal requirement can't be traded for a cheaper Region
Prices and services differ by Region	Check both before choosing: the script does it in seconds
Global, Regional, zonal	"Missing" resources are usually in another Region
AWS secures the cloud; you secure what's in it	Your data and who can reach it are always yours
EC2: you patch the OS	Managed services move patching to AWS
AWS Artifact	AWS's own audit reports, free, for your auditors

Where you are now

You can choose a Region for a reason, and check the facts behind that reason from your own machine: which services a Region has and what it costs there. You know which services are global, Regional and zonal, why something can seem to vanish, and where the line falls between AWS's security work and yours for each kind of service. Next, Lesson 6 closes Part 1 with the Well-Architected Framework: AWS's checklist for building things well, which the rest of the track keeps coming back to.

Check yourself

Customer data must legally stay in Germany. A Region in Ireland is cheaper. Which do you choose?
From the run, how much more does the bakery's server cost in São Paulo than in Ohio?
You created a Lambda function, but the console's function list is empty. What's the likely reason?
Which of these is global, one per account?
Who patches the operating system of an EC2 server you run?
Which job stays yours on every AWS service?
An auditor asks for proof of AWS's data centre security. Where do you get it?

Key terms

Data residency: a rule that data must stay in a particular country or area.
Latency: how long a request takes to travel to a Region and back.
Public parameters: facts AWS publishes in Systems Manager (SSM) for anyone to read, including which services run in each Region.
Price List API: AWS's API for current prices, by service, Region and option.
Global, Regional, zonal: one per account; separate in each Region; inside one Availability Zone.
Default VPC: a network AWS creates in each Region, so a server has somewhere to go straight away.
Shared responsibility model: AWS secures the cloud itself; you secure what you put in it.
Inherited control: one AWS does entirely, like physical security. Shared control: one each side does in its own place, like patching.
AWS Artifact: where AWS publishes its audit reports and certificates, free.

Go deeper

AWS: What to consider when selecting a Region for your workloads (opens in a new tab), the four factors.
AWS: The shared responsibility model (opens in a new tab), with the inherited and shared controls.
AWS Well-Architected: Choose Regions based on cost (opens in a new tab).
Try: change REGIONS in compare-regions.sh to add ca-central-1 and eu-central-1, and add sagemaker to SERVICES. Which Region is cheapest for the bakery outside the US?