Topic 0.2
Regions, Availability Zones & the Shared Responsibility Model
In one line
A region is a real, distinct geographic area; an Availability Zone is a physically separate data center within it — and the shared responsibility model draws a hard, explicit line between what AWS secures and what you must.
Think of it like this
A REGION is like a country you've chosen to operate in (say, 'US East'); an AVAILABILITY ZONE (AZ) is one specific, physically separate office building within that country — AWS deliberately builds multiple, genuinely independent AZs per region specifically so a single building's power outage or hardware failure can't take down everything in that entire country at once.
Key ideas
- 01
A REGION is a distinct, physically separate geographic area (
us-east-1,eu-west-1) — choosing a region is choosing WHERE your infrastructure physically runs, directly affecting latency to your actual users (Topic 0.1) and, for some industries, genuine data-residency/compliance requirements about which country data is physically allowed to be stored in. - 02
An AVAILABILITY ZONE is one or more genuinely separate, physically isolated data centers WITHIN a region, each with independent power, cooling, and networking — a region typically has 3+ AZs specifically so a real, genuine failure in one (a power outage, a fire) doesn't take down infrastructure in the others, letting an application deployed across multiple AZs stay available even if one entire data center goes offline.
- 03
This directly connects to Kubernetes' own course (that course's Phase 4.2, pod anti-affinity spreading replicas across zones) — the exact same 'don't put all your eggs in one physical basket' principle, just now understood at the AWS infrastructure level that Kubernetes' own zone-awareness is actually built on top of.
- 04
The SHARED RESPONSIBILITY MODEL is AWS's own explicit, published boundary: AWS is responsible for the SECURITY OF THE CLOUD (physical data center security, the underlying hardware, the virtualization layer, network infrastructure) — YOU are responsible for SECURITY IN THE CLOUD (your own data, your IAM configuration, your operating system patches on any EC2 instances, your network configuration, your application's own security).
- 05
This distinction genuinely matters in practice: AWS will never patch an operating system vulnerability inside YOUR EC2 instance, will never fix an overly permissive IAM policy YOU configured, and will never encrypt YOUR data for you unless you explicitly enable it — 'AWS is secure' does NOT mean 'anything I build on AWS is automatically secure'; the exact line drawn depends on which specific service you're using (a fully-managed service like Lambda shifts more responsibility to AWS than a raw EC2 instance does).
Code & diagrams
Multiple, physically independent AZs within one region — the actual mechanism behind cloud resilience.
The line that decides whose job a given security gap actually is.
Explain it without notes
Why does AWS deliberately build multiple Availability Zones within a single region, rather than one large, very reliable data center per region?
A company's S3 bucket was accidentally left publicly readable, exposing customer data. Whose responsibility was this under the shared responsibility model, and why?
Practice
Look up how many Availability Zones a specific AWS region you might use (like us-east-1) actually has, and explain in one sentence why an application should be deployed across more than one.
For each of these three real incidents — a leaked IAM access key, a hardware failure in an AWS data center, an unpatched OS vulnerability on your own EC2 instance — decide whether it falls under AWS's responsibility or the customer's, and explain why.
Trade-offs
- ↔
Different AWS services shift the shared responsibility line differently — a raw EC2 instance leaves you responsible for patching its entire operating system yourself, while a fully-managed service like Lambda (Phase 5) removes that specific burden entirely, since AWS manages the underlying runtime for you; choosing a more managed service genuinely reduces your own operational and security responsibility, at the cost of less low-level control over exactly how that infrastructure runs.
Done when you can
I can explain the difference between a region and an Availability Zone.
I understand why deploying across multiple AZs provides real resilience against a physical data center failure.
I can correctly classify a given security incident as AWS's responsibility or the customer's under the shared responsibility model.