Cloud fundamentals — regions, AZs, shared responsibility

What “the cloud” is: regions, AZs, and who secures what

Section 1 of 5 · ~3 min

The cloud is a simple idea dressed in jargon: it is someone else’s computers, rented by the second. Instead of buying and racking servers, you make an API call and a server exists about ninety seconds later — and you pay only while it runs. That is the whole pitch: on-demand (capacity the moment you ask) and pay-as-you-go (billed for what you use, then you turn it off). Amazon Web Services, Microsoft Azure, and Google Cloud all sell the same raw materials — compute, storage, networking — behind different names.

Those computers live somewhere physical, and where matters. A Region is a geographic area with its own cluster of data centres — us-east-1 in Northern Virginia, ap-south-1 in Mumbai, eu-west-1 in Ireland. There are more than thirty worldwide, and almost nothing you create is global: an instance you launch in Mumbai simply does not exist in Ohio. You pick a region for three reasons — latency (put your app near your users), data residency (a law may require customer data stay in-country), and price (the same server costs different amounts in different regions).

Zoom in and each region is built from multiple Availability Zones (AZs) — usually three or more. An AZ is one or more discrete data centres with its own power, cooling, and networking, far enough from its siblings that a fire, flood, or power cut hits only one, but linked to them by private high-speed fibre. This is the single most important operational fact about the cloud: run in at least two AZs. A single-AZ app dies the day that one building has a bad day; a multi-AZ app shrugs and keeps serving.

Finally: who secures all this? The shared responsibility model draws a line. AWS is responsible OF the cloud — the buildings, the hardware, the hypervisor, the backbone network — and you are responsible IN the cloud — your OS patches, your firewall rules, who can log in, and your data and its encryption. The line slides by service: on a raw EC2 instance you patch the OS; on a managed service like S3 the provider handles far more. The lesson every breach report repeats: the failure is almost always on the customer’s side of the line — a publicly exposed bucket, a leaked access key — not the provider’s buildings.

Real world: Think of a rented apartment. The landlord secures the building — foundation, roof, the lock on the street door, the wiring in the walls. You secure your own unit: you decide who gets a key, you lock your door, you insure what’s inside. Leave your own door wide open and get robbed, and that is on you, not the landlord. AWS is the landlord; your account is your apartment.

A named example makes it real. Netflix runs almost entirely on AWS, spread across multiple regions and AZs; when a single zone degrades, traffic shifts to the others and members keep watching — they even kill instances on purpose to prove the design holds. That is multi-AZ thinking at scale.

Today is mostly reading. The lab just proves your access works and shows regions and zones from the command line — nothing billable.

What this costs: ₹0. Every command today is read-only — signing in, aws configure, and identity and region queries create nothing you can be charged for. There is no resource to delete at the end, and you cannot run up a bill by listing regions. (From Day 48, when labs launch real infrastructure, this box always tells you exactly what to terminate.)

Hands-On Lab

Section 2 of 5 · ~2 min

Budget about 20 minutes. First, in a browser, go to aws.amazon.com and create a free account (or sign in). Do two things in the console immediately: on the root user, open Security credentials and enable MFA, then stop using root for daily work — it has unlimited power over the account. For this lab create an IAM user (or an IAM Identity Center user) with the ReadOnlyAccess policy and generate an access key for it. Then drop to your terminal — everything below is read-only and free.

# 1. Confirm the AWS CLI v2 is installed. (If not: see the Go Deeper install link.)
aws --version
# Output (yours will differ slightly by version and OS):
# aws-cli/2.17.20 Python/3.11.9 Linux/6.6.36 exe/x86_64.ubuntu.24

# 2. Store your IAM user's credentials + a default region. Paste the key,
#    then a secret; pick a region near you (ap-south-1 = Mumbai).
aws configure
# AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
# AWS Secret Access Key [None]: ****************************************
# Default region name [None]: ap-south-1
# Default output format [None]: json

# 3. Prove who you are. This is the free "am I authenticated?" check.
aws sts get-caller-identity
# Output (your Account, UserId and Arn will differ):
# {
#     "UserId": "AIDAEXAMPLEUSERID",
#     "Account": "123456789012",
#     "Arn": "arn:aws:iam::123456789012:user/mission90"
# }

# 4. Read back the default region you just set (no API call — reads your config).
aws configure get region
# Output:
# ap-south-1

# 5. List every region available to your account (read-only, nothing created).
aws ec2 describe-regions --query "Regions[].RegionName" --output table
# Output (abridged — you'll see ~17 rows (the regions enabled for your account; opt-in regions appear only with --all-regions)):
# --------------------
# |  DescribeRegions |
# +------------------+
# |  us-east-1       |
# |  us-west-2       |
# |  eu-west-1       |
# |  ap-south-1      |
# |  ap-southeast-1  |
# +------------------+

# 6. Now the payoff: list the Availability Zones INSIDE one region.
aws ec2 describe-availability-zones \
  --region ap-south-1 \
  --query "AvailabilityZones[].ZoneName" --output text
# Output — three separate data centres in the Mumbai region:
# ap-south-1a	ap-south-1b	ap-south-1c

# 7. Compare a different region to see AZ names are region-scoped.
aws ec2 describe-availability-zones \
  --region us-east-1 \
  --query "AvailabilityZones[].ZoneName" --output text
# Output — Northern Virginia has six:
# us-east-1a	us-east-1b	us-east-1c	us-east-1d	us-east-1e	us-east-1f

Read the last two outputs back: one region, several named zones, each a separate building. That is the whole reason “deploy across two AZs” is the baseline — and you proved your access works without creating a single billable resource.

Common Errors & Fixes

Section 3 of 5 · ~2 min

These three trip up almost everyone on their first day with the AWS CLI. Read the error text slowly — parsing it is the skill.

Common error: Running an aws command before aws configure, or in a shell that never picked up the credentials:

Unable to locate credentials. You can configure credentials by running "aws configure".

Why: The CLI looks for an access key and secret in ~/.aws/credentials, environment variables, or an instance role — and found none. Nothing is authenticated, so it refuses before making any API call.

Fix: Run aws configure and paste the IAM user’s access key and secret, or export AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY for the session. Confirm with aws sts get-caller-identity.

How you’d spot it in prod: A CI job or script that fails on its very first aws call with “Unable to locate credentials” almost never has a code bug — the runner has no credentials configured, or the IAM role it should assume isn’t attached. Check the environment, not the command.

Common error: A typo in the access key, or a key that was deleted or belongs to another account:

An error occurred (InvalidClientTokenId) when calling the GetCallerIdentity operation: The security token included in the request is invalid.

Why: AWS received a request but the access-key ID it carries does not exist or is disabled. The credentials are present but not valid — a different failure from “not found.”

Fix: Re-run aws configure and paste the key carefully (no trailing spaces), or generate a fresh access key for the IAM user in the console and use that. If you rotated keys, delete the old one after confirming the new pair works.

How you’d spot it in prod: InvalidClientTokenId on a job that worked last week usually means someone rotated or revoked the key it was using. Check when the key was last rotated and whether the secret store has the new value.

Common error: Calling a service the IAM user isn’t allowed to, e.g. a read-only user hitting a write action, or a user with no EC2 permissions running describe-regions:

An error occurred (UnauthorizedOperation) when calling the DescribeRegions operation: You are not authorized to perform this operation.

Why: Least-privilege in action. The IAM user’s attached policies don’t grant ec2:DescribeRegions, so IAM denies the call. This is the system working correctly, not a bug.

Fix: Attach a policy that grants the needed action — ReadOnlyAccess covers every command in today’s lab. Grant the narrowest policy that lets the task succeed rather than reaching for AdministratorAccess.

How you’d spot it in prod: UnauthorizedOperation or AccessDenied naming a specific action tells you exactly which permission to add — read the action in the message (ec2:DescribeRegions) and grant that, instead of widening the policy blindly.

Cloud Interview Questions

Section 4 of 5 · ~1 min

Region-versus-AZ and the shared responsibility model are the two most common opening questions in any cloud screen — a calm, concrete answer that names why multi-AZ beats a memorised definition. The answer bank renders right after this note. Cover each answer, say your own version out loud first, then compare — recalling before revealing is what makes it stick for interview day.

Go Deeper

Section 5 of 5 · ~1 min

Optional extras if you have ~25 more minutes today:

• 5 min — Open the AWS global infrastructure map and find the region nearest you, then count its Availability Zones.
• 10 min — Read the official Shared Responsibility Model page and note how the line shifts between EC2 (you patch the OS) and a managed service like S3.
• 10 min — Skim the Reliability pillar of the AWS Well-Architected Framework for why multi-AZ is treated as the production baseline.