See which resources belong to a Region and which are global

Steps

1. List the Regions this account can use, and read one Region's opt-in status:

aws ec2 describe-regions --query 'Regions[].RegionName' --output text
aws ec2 describe-regions --region-names eu-west-2 --query 'Regions[0].OptInStatus' --output text
aws ec2 describe-regions --all-regions --query "Regions[?OptInStatus=='not-opted-in'].RegionName" --output text

The second command prints opt-in-not-required. The third lists Regions that are turned off until someone opts in to them; leave them as they are. Do not count the Regions to memorise them: AWS adds more. 2. List the Availability Zones inside two Regions:

aws ec2 describe-availability-zones --region eu-west-2 --query 'AvailabilityZones[].[ZoneName,ZoneId,State]' --output table
aws ec2 describe-availability-zones --region ap-southeast-2 --query 'AvailabilityZones[].[ZoneName,ZoneId,State]' --output table

Each Region contains several AZs, and every zone name starts with its Region's code: a Region contains AZs, never the reverse. The zone name, such as eu-west-2a, can point to a different physical AZ in another account; the zone ID, such as euw2-az1, is the same for everyone. 3. Put a bucket in eu-west-2. Use your own account ID in the name:

aws s3api create-bucket --bucket clf-lab13-111122223333 --region eu-west-2 --create-bucket-configuration LocationConstraint=eu-west-2

New buckets keep S3 Block Public Access on, and this one holds nothing. 4. Ask where the bucket lives, first from its own Region and then from a different one:

aws s3api get-bucket-location --bucket clf-lab13-111122223333 --region eu-west-2 --query LocationConstraint --output text
aws s3api get-bucket-location --bucket clf-lab13-111122223333 --region us-east-1 --query LocationConstraint --output text

Both print eu-west-2. The bucket and anything put in it stay in London unless you copy them elsewhere: AWS does not move it. In the S3 console's bucket list, its AWS Region column reads Europe (London) eu-west-2. That is why choosing the Region is how you meet a data residency rule. 5. Now a global service. Make an IAM group and read it back through two distant Regions:

aws iam create-group --group-name clf-lab13-group
aws iam get-group --group-name clf-lab13-group --region ap-southeast-2 --query 'Group.GroupName' --output text
aws iam get-group --group-name clf-lab13-group --region us-west-2 --query 'Group.GroupName' --output text

Both print clf-lab13-group. IAM is global: the Region you name makes no difference, because the group belongs to the account, not to a Region. 6. Look at the edge network in the console. Open IAM, then Amazon CloudFront, then Route 53, and read the Region selector at the top right each time: for all three it reads Global. CloudFront caches content and Route 53 answers DNS queries from edge locations in many more cities than there are Regions. Do not create a CloudFront distribution; reading the page is enough. 7. In your own notes, match each problem to the layer that solves it: one data centre losing power (several AZs in one Region); a whole Region becoming unavailable (a second Region); users in Sydney waiting for images served from Europe (CloudFront at edge locations, or a Region nearer them); a law that customer records stay in the United Kingdom (choose a UK Region and keep the data there).