Foundations

Five things are true of every AWS service. Learn them once here and every service afterwards is mostly detail. Skip them and you will keep meeting the same confusions wearing different service names — a denied API call you can't explain, a bill nobody can attribute, a quota that reset itself when you opened a new region.

Why this topic exists

Most AWS learning starts with a service — launch an instance, create a bucket — and picks up the platform by osmosis. That works until it doesn't. The moment something goes wrong, the question is almost never about the service:

• "Why is this call denied? The role clearly has s3:GetObject." → policy evaluation, not S3.
• "Why did our quota increase not apply in Frankfurt?" → quotas are per region, not per account.
• "Why can't we tell which team spent $40,000?" → tagging, not Cost Explorer.
• "Why did a script in dev take down prod?" → account boundaries, not the script.
• "Why does terraform apply fail on a resource that definitely exists?" → eventual consistency.

Every one of those is a platform question. They recur in every service topic, and answering them thirty times in thirty places would be both repetitive and — worse — inconsistent. So they live here, and each service topic links back in one line rather than re-explaining.

This is also the material that separates someone who has used AWS from someone who can reason about it. Interviewers know that, which is why so many senior questions turn out to be foundations questions in a service costume.

The five things that are true of every service

1. The account is the real boundary. Not the VPC, not the region — the account. It is the isolation boundary for blast radius, the unit that quotas are counted against, the unit that appears on a bill, and the thing Organizations and Service Control Policies act upon. "One account per environment" is the single most consequential structural decision in an AWS estate, and it's completely invisible if you only ever read service documentation.

2. Every tool is a client of the same signed, regional API. The console, the AWS CLI, every SDK, Terraform, CloudFormation, and CDK all send authenticated requests to the same regional endpoints. There is no privileged back door for the console. Once you understand the request model — credentials, signing, eventual consistency, throttling and retries, and the split between control plane and data plane — provisioning behaviour stops being mysterious across every service at once.

3. IAM is one evaluation algorithm, not a pile of per-service permissions. Identity policies, resource policies, Service Control Policies, permission boundaries, and session policies combine according to rules that never change: explicit deny wins, then SCPs and boundaries must allow, then something must explicitly allow. Learn that order once and "why is this denied" becomes a procedure rather than a guess.

4. Regions and Availability Zones are the physics. Regions are isolated by design and most resources never cross between them without you doing something explicit. AZs are the unit of correlated failure. Some services are global, most are regional, a few are zonal — and knowing which is which is the difference between a design that survives an AZ event and one that merely looks like it does.

5. ARNs, tags, and quotas are the connective tissue. The ARN is the identifier every policy, every tool, and every log entry consumes. Tags are what make cost attributable and automation targetable — untagged infrastructure is unattributable spend. Quotas are per account and per region, mostly soft, and slow enough to raise that discovering one during an incident is discovering it too late.

Key facts at a glance

What this topic is	The cross-cutting platform model — not a service
Why it's first	Every service topic assumes it and links back to it
The outer boundary	The account. Isolation, quota, and billing all key off it
The control plane	One signed REST API per region; every tool is a client of it
The authorisation model	One evaluation algorithm across five policy types
The failure domain	The Availability Zone; the region is the isolation domain
Read it when	Before your first service topic — or the moment something denies, throttles, or bills unexpectedly
Time to read	Roughly an hour end to end; each sub-topic stands alone

What this topic covers

#	Sub-topic	What it covers
1	Accounts & Organizations	The account as the real boundary; organisational units, Service Control Policies, Control Tower, consolidated billing, and why account-per-environment beats VPC-per-environment
2	The API & Control Plane	One signed regional API behind every tool; the credential chain, SigV4, eventual consistency, throttling and retries, idempotency, and control plane vs. data plane
3	IAM & Identity	Principals, the five policy types, the evaluation algorithm, roles over users, AssumeRole and short-lived credentials, IAM Identity Center
4	Regions & Availability	Regions, Availability Zones and AZ IDs, global vs. regional vs. zonal services, opt-in regions, data residency, and what "multi-region" actually costs
5	ARNs, Tagging & Quotas	The ARN format every policy consumes, a tag schema that survives contact with reality, and how Service Quotas actually work

New to AWS? Start at Accounts & Organizations.

The three ideas that pay for themselves immediately

If you read nothing else here, read these.

Explicit deny always wins, and an SCP that doesn't allow is a deny. Most "impossible" permission problems are one of two things: an explicit Deny somewhere in the chain, or an SCP that never permitted the action in the first place — so the account's administrator genuinely cannot grant it. Knowing this turns a frustrating afternoon into a five-minute check.

Quotas are per account and per region. A new region starts you at defaults. This causes a specific, recurring outage: a team expands to a second region on launch day, hits a limit they raised eighteen months ago in the first region, and discovers that increases take hours to days to approve.

Nothing is attributable without tags. Cost allocation, automation targeting, tag-based access control, and backup selection all key off tags. Decide the schema — Environment, Service, Owner, CostCenter — before you have two hundred resources, and enforce it, because retrofitting tags across an existing estate is genuinely painful work nobody volunteers for.

When you can skip ahead

Go straight to a service topic if you can already answer these without hesitating:

• What happens to your blast radius when dev and prod share one account?
• In what order are SCPs, permission boundaries, identity policies, and resource policies evaluated?
• Why might a Describe call return a resource that a subsequent call says doesn't exist?
• Which is the failure domain and which is the isolation domain — the AZ or the region?
• Is a Service Quota increase per account, per region, or both?

If any of those made you pause, the relevant sub-topic will take ten minutes and save you considerably more than that later.

Reading paths

• New to AWS: 1 → 4 → 3 → 2 → 5. Boundaries and geography first, then identity, then the API model.
• Coming from another cloud: 1 → 3 → 5. The account model and IAM are where AWS differs most from Azure's subscription/RBAC model and GCP's project/IAM model.
• Interview preparation: 3 → 2 → 1. Policy evaluation and the control-plane/data-plane split are the two most-probed areas.
• Setting up a new estate: 1 → 5 → 3. Account structure and tagging are the decisions that are expensive to reverse.
• Debugging right now: 3 for a denial, 2 for a throttle or a consistency surprise, 5 for a quota error.

---

On numbers. Quotas, region counts, and service availability change constantly. Anywhere this topic states a volatile figure it is either labelled "as of writing" or flagged ⚠️ verify against current AWS docs. Treat those as prompts to check, not facts to memorise.

← All topics