SAAF — Fundamentals

Why this module exists

The SAA-C03 exam guide describes its target candidate in one sentence — "at least 1 year of hands-on experience designing cloud solutions that use AWS services" — and then writes fourteen task statements that take a layer of fundamentals for granted. SAA0 starts at the Well-Architected Framework, which is already above that layer.

This module is the layer. Every topic in it is named in a domain's "Knowledge of" or "Skills in" lines, and none of them is taught there:

"AWS global infrastructure (for example, Availability Zones, AWS Regions)" — Tasks 1.1, 2.2, 3.3, 4.2
"The AWS shared responsibility model" — Task 1.1
"network segmentation strategies (for example, using public subnets and private subnets)" — Task 1.2
"Encrypting data at rest" / "Encrypting data in transit" — Task 1.3
"subnet tiers, routing, IP addressing" — Task 3.4
"virtualization" — Task 4.2
"Network services with appropriate use cases (for example, DNS)" — Task 4.4

It carries no exam weight of its own. It is the vocabulary the weighted domains are written in.

The one idea to hold onto

Every design question is secretly a boundary question: which physical boundary does this sit inside, and whose side of the responsibility line is it on?

   WHERE IT LIVES                  WHAT IT SURVIVES           WHOSE JOB
   ──────────────                  ────────────────           ─────────
   AZ   (EC2, EBS, subnet)    →    nothing beyond its AZ  →   you add a 2nd AZ
   Region (S3, DynamoDB, SQS) →    loss of an AZ          →   you add a 2nd Region
   Global (IAM, Route 53,     →    data plane: a Region   →   you keep its control
           CloudFront)              control plane: ONE        plane out of recovery
                                    Region (often us-east-1)

   and on every one of them:  your data · your IAM · your encryption choices  = YOURS

What you'll be able to do

Distinguish NIST's five essential characteristics from AWS's six advantages, and say which list a phrase comes from.
Explain Region, Availability Zone, Local Zone, Wavelength Zone, Outpost and edge location — and pick one from a latency, residency or 5G requirement.
Use AZ IDs rather than AZ names when two accounts must line up, and say why.
Classify a service as zonal, Regional or global from its own documentation, and name what you must add to survive the next failure up.
Explain why "global" services still have a single-Region dependency, and name the anti-patterns that put it in a recovery path.
Place the Shared Responsibility line for EC2, RDS, Lambda and S3 — including the RDS optional-update and Lambda container-image traps.
Do CIDR arithmetic, state what makes a subnet public, and describe what DNSSEC signing does and does not protect.

Lessons

#	Lesson	Anchors	Read	Listen
1	What cloud computing is — definitions, deployment models, what AWS sells	guide home; 4.1, 4.2	22 min	9 min
2	Global infrastructure — Regions, AZs, Local Zones, Wavelength, the edge	1.1, 2.2, 3.2, 3.3, 4.2	26 min	9 min
3	The resilience taxonomy — zonal, Regional and global services	2.2	28 min	9 min
4	The Shared Responsibility Model — how the line moves per service	1.1	24 min	9 min
5	General fundamentals — CIDR, Nitro, encryption, DNS and DNSSEC	1.2, 1.3, 3.4, 4.2, 4.4	30 min	10 min
Then: Cheat sheet · Lab · Quiz · Interview

Where this sits in the track

Study it first. SAA0 (whitepapers and FAQs) builds on lessons 2–3; SAA1 (Domain 1) builds on lessons 4–5; SAA2 (Domain 2) builds on lesson 3 directly — its data-plane rule is the same rule the Fault Isolation Boundaries whitepaper applies to global services.

A note on sources

Every page cited was fetched on 2026-09-25. The exam guide is the HTML guide at docs.aws.amazon.com/aws-certification/latest/solutions-architect-associate-03/, not the d1.awsstatic.com PDF.

Three things worth knowing about how this module was sourced:

The taxonomy has an AWS source after all. PLAN.md expected no AWS page to enumerate zonal/Regional/global services. The AWS Fault Isolation Boundaries whitepaper (November 16, 2022) defines all three and names examples — but it is not an exhaustive per-service table, so lesson 3 still builds its table one service page at a time and cites each row.
NIST's definition came from the PDF. The NIST landing page carries only the abstract; the five characteristics are quoted from SP 800-145 itself.
Some pages were read as raw HTML. Where the summarising fetch paraphrased (the Shared Responsibility page) or returned nothing usable (Lambda), the page was retrieved directly and quoted from its text. Quotes are verbatim either way.

Flags left inline with ⚠️ — the ones that matter most:

The HTML guide home page has no "recommended knowledge" list — only the one-sentence target candidate description (lesson 1).
Region counts disagree between AWS's docs (34, standard accounts) and its marketing page (39 geographic Regions) on the same day; not reconciled (lesson 2).
"Price varies by Region" isn't stated on any Region page fetched (lesson 2).
The SQS guide says "multiple servers", not AZs; its Regional classification rests on the whitepaper (lesson 3).
Lambda's main security page couldn't be retrieved; the OS-responsibility sentence for Lambda is unverified (lesson 4).
Local Zones aren't named on the In-Scope Services page (a non-exhaustive list) (lesson 2).

Facts verified 2026-09-25 against the pages cited in each lesson.

Keeps playing into the following modules — 372 min from here to the end of certification prep.