Fundamentals & Account Structure

Table of Contents#

1. Why AWS Gets a Dedicated Series
2. What "The Cloud" Actually Is
3. Regions, Availability Zones, and Edge Locations
4. Choosing a Region — Real Constraints
5. The AWS Account — The Real Unit of Isolation
6. Why One Account for Everything Is a Trap
7. AWS Organizations — Managing Many Accounts as One
8. Organizational Units (OUs) — Grouping Accounts by Purpose
9. Service Control Policies (SCPs) — Guardrails, Not Grants
10. A Realistic Multi-Account Landing Zone
11. AWS Control Tower — Automating the Landing Zone
12. The AWS Well-Architected Framework — The Six Pillars
13. The Shared Responsibility Model
14. Understanding the AWS Bill — Free Tier, On-Demand, and Beyond
15. The AWS CLI and SDKs — Your Actual Daily Tools
16. Tagging — The Unglamorous Habit That Saves Every Team
17. Tag Policies — Enforcing Tagging Org-Wide
18. AWS Config — Continuous Configuration Compliance
19. AWS Trusted Advisor
20. Resource Groups and the Tag Editor
21. Delegated Administration — Spreading Org-Wide Duties
22. AWS Support Plans
23. AWS Artifact — Compliance Documentation On Demand
24. Service Quotas — Planning Around AWS's Own Limits
25. A Full Worked Landing Zone Bootstrap, Start to Finish
26. Working Across Multiple Accounts From the CLI — Profiles
27. Part 1 CLI Cheat Sheet
28. Common Mistakes
29. A Worked Example: Sizing an Initial Multi-Account Structure for a 50-Person Startup
30. Worked Practice Problems
31. Summary and What's Next

---

Why AWS Gets a Dedicated Series#

Every topic so far in this course has taught concepts that apply everywhere — replication (Databases series), rolling deployments (Automation series), the CAP theorem (Reliability series). Those ideas don't belong to any one vendor. This series is different on purpose: AWS is a specific, massive product, with its own naming, its own quirks, and its own gotchas that show up constantly in real SRE and Platform Engineering work — and just as constantly in interviews for those roles.

Think of everything you've learned so far as the theory of how reliable systems work. This series is the specific dialect one of the three major cloud providers uses to let you actually build those systems. The concepts transfer directly: an Availability Zone is a concrete implementation of the "redundancy at every layer" idea from the Reliability & Architecture Patterns series; an Auto Scaling Group is a concrete implementation of the horizontal scaling ideas from Capacity Planning; IAM policies are a concrete implementation of the least-privilege principle from DevSecOps. Every part of this series will explicitly point back to the general concept it's an implementation of — the goal is never to memorize AWS trivia in isolation, but to see AWS as one specific answer to problems you already deeply understand.

---

What "The Cloud" Actually Is#

Strip away the marketing, and "the cloud" is simple: someone else's data centers, rented to you by the second (or millisecond), accessed entirely through an API.

Diagram

The single most important mental model shift, worth internalizing early: in a traditional data center, "provisioning a server" means a physical, human, hours-or-days-long process. In AWS, provisioning a server is an API call that returns in seconds. This is precisely why Infrastructure as Code (Automation series, Part 2) became possible at all — it needs an API-driven infrastructure to declare state against. AWS didn't just make data centers rentable; it made infrastructure itself into something you can version-control, review in a pull request, and roll back — the same way you already treat application code.

---

Regions, Availability Zones, and Edge Locations#

This is the single most foundational piece of AWS geography, and it maps directly onto the "Availability Zones vs Regions" concept already introduced generically in the Reliability & Architecture Patterns series (Part 1) — AWS is where that abstract concept became a concrete, purchasable product.

Diagram

Why "AZs have independent power and cooling" is the single fact worth memorizing here, worth stating explicitly: it's the entire reason multi-AZ deployment provides real fault tolerance. A power outage or cooling failure that takes down one AZ's data centers is, by design, extremely unlikely to simultaneously affect another AZ in the same region — directly satisfying the "eliminate single points of failure" principle from the Reliability & Architecture Patterns series. A region, by contrast, can have a regional failure (a bad control-plane deployment, a BGP misconfiguration, a widespread service issue) that no amount of multi-AZ redundancy protects against — which is exactly why the Disaster Recovery series' multi-region strategies exist as a separate, higher tier of protection above multi-AZ.

Copy
# List all AWS regions
aws ec2 describe-regions --output table

# List all Availability Zones in a specific region
aws ec2 describe-availability-zones --region us-east-1 --output table

---

Choosing a Region — Real Constraints#

A genuinely practical decision, worth walking through explicitly rather than treating as an afterthought.

Diagram

Three real constraints worth naming explicitly, each a common interview follow-up:

1. Latency — physical distance to the speed of light is a real, unavoidable floor (directly connects to the TCP/networking discussion in the Linux & Networking series); a user in Singapore hitting a server in us-east-1 pays for that distance on every single request.
2. Compliance and data residency — GDPR (covered in the DevSecOps series' Compliance part) and similar regulations can legally require certain data to stay within specific geographic boundaries, overriding a pure latency-based decision.
3. Service and pricing parity — not every AWS service launches in every region simultaneously, and prices genuinely differ by region; a region choice sometimes has to accommodate "which region actually has the service I need."

---

The AWS Account — The Real Unit of Isolation#

An AWS account is not like a username on a website — it's a completely separate, walled-off universe of resources, billing, and limits.

Diagram

Why this matters more than it sounds like it should, worth stating precisely: an AWS account is the STRONGEST isolation boundary AWS offers — stronger than a VPC (Part 4), stronger than an IAM policy (Part 2). Two resources in two different AWS accounts cannot accidentally interact with each other at all unless you deliberately, explicitly set up a mechanism (like cross-account IAM roles) to allow it. This is the AWS-specific, concrete version of the "bulkhead" resilience pattern already covered in the Reliability & Architecture Patterns series — a account boundary is a hard bulkhead wall.

---

Why One Account for Everything Is a Trap#

A genuinely common real-world mistake, worth naming explicitly before introducing the fix.

Diagram

Why this is such a strong, senior-level interview answer, worth stating explicitly: "single-account AWS setups are a classic early-stage mistake that becomes exponentially more expensive to unwind the longer an organization waits — the fix (a multi-account structure) is dramatically easier to adopt on day one than to migrate into after hundreds of resources and IAM policies already exist tangled together in one account."

---

AWS Organizations — Managing Many Accounts as One#

AWS's own answer to the one-account trap: a service for creating and centrally managing many AWS accounts as a single, coherent hierarchy.

Diagram

Why the management account should NEVER run actual workloads, a real, important operational rule worth stating explicitly: it has ultimate authority over every account in the organization (it can, for example, close any member account) — running production workloads there mixes an extremely high-privilege control plane with ordinary application risk, exactly the kind of unnecessary privilege concentration the least-privilege principle (DevSecOps series) warns against. Consolidated billing is a genuinely useful side effect: all member accounts' costs roll up to one bill, often unlocking volume discounts, while each account still keeps its own resource isolation.

Copy
# Create a new AWS account under an Organization (from the management account)
aws organizations create-account \
  --email "aws-prod-payments@example.com" \
  --account-name "prod-payments"

# List all accounts in the organization
aws organizations list-accounts --output table

---

Organizational Units (OUs) — Grouping Accounts by Purpose#

OUs let policies apply to a whole GROUP of accounts at once, instead of one account at a time — directly reusing the same "apply a rule at the right layer of a hierarchy" idea already seen in Kubernetes namespaces (Kubernetes Deep Dive series) and organizational rule scoping generally.

---

Service Control Policies (SCPs) — Guardrails, Not Grants#

The single most commonly misunderstood AWS Organizations concept — worth getting exactly right for an interview.

Diagram

Why this distinction is worth stating precisely and explicitly, a genuinely strong interview line: "An SCP by itself never grants anyone the ability to do anything — even an SCP that explicitly 'allows' an action grants nothing on its own. It only sets the outer boundary of what's POSSIBLE within that account; an IAM policy inside the account still has to separately grant the actual permission. This is why SCPs are described as guardrails, not grants — even the account's root user can never exceed what the SCP for their account allows, no matter what IAM policy they're given."

Copy
# An SCP that DENIES leaving a specific set of approved regions,
# no matter what any IAM policy inside the account allows
cat <<'SCP'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "NotAction": ["iam:*", "organizations:*", "route53:*", "support:*"],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": ["us-east-1", "us-west-2"]
      }
    }
  }]
}
SCP

---

A Realistic Multi-Account Landing Zone#

Bringing the last several sections together into one concrete, worked structure — a "landing zone" is simply the name for this whole foundational account/OU/policy setup.

Diagram

Why centralizing logs in a SEPARATE, dedicated account matters so much, worth explaining precisely: if an attacker (or a mistaken engineer) compromises a workload account, having that account's own audit logs stored ONLY in that same account means the logs themselves could be tampered with or deleted to cover the tracks. Shipping logs to a separate log-archive account, where the workload account has no delete permission at all, guarantees a tamper-evident audit trail survives even a full compromise of the source account — directly extending the "assume breach" principle from the DevSecOps series' shift-left discussion.

---

AWS Control Tower — Automating the Landing Zone#

Setting up everything in the previous section by hand, account by account, policy by policy, is exactly the kind of repetitive, error-prone, well-defined manual process that the Toil discussion (SRE Fundamentals series) flags as a prime automation target. AWS Control Tower is AWS's own opinionated automation for standing up and governing a multi-account landing zone.

Worth stating as a balanced, honest tradeoff rather than a pure sales pitch: Control Tower is opinionated — it makes strong defaults for you, which is genuinely valuable for a team standing up their FIRST landing zone, but a team with very specific existing conventions may find its guardrails and account structure less flexible than hand-rolling the same setup with Terraform (Automation series, Part 2) directly against AWS Organizations' own API.

---

The AWS Well-Architected Framework — The Six Pillars#

AWS's own distilled, opinionated best-practices framework — genuinely worth knowing by name and by pillar, since it's referenced constantly in AWS documentation, AWS certifications, and AWS-focused interviews.

Diagram

A genuinely useful framing, worth stating explicitly: every one of these six pillars is just a formal, AWS-branded restatement of a concept already covered elsewhere in this course — Reliability is the entire Reliability & Architecture Patterns and Disaster Recovery series; Operational Excellence is SRE Fundamentals and Incident Management; Security is the DevSecOps series; Performance Efficiency and Cost Optimization are Capacity Planning. Recognizing this mapping instantly, out loud, is a strong interview move — it shows the framework isn't new information to memorize, but a vendor-specific lens on principles you already understand deeply.

Copy
# AWS provides an actual, free tool implementing this framework —
# the Well-Architected Tool, which walks through structured
# questions per pillar and flags risks
aws wellarchitected list-workloads

---

The Shared Responsibility Model#

Directly connects to the identically-named concept already introduced generically in the DevSecOps series (Part 1) and the Kubernetes managed-K8s discussion (Kubernetes Deep Dive, Part 5) — this is AWS's own specific version of it.

Diagram

Why this split moves depending on the SERVICE, a genuinely important, frequently-tested nuance: for EC2 (Part 3), you're responsible for patching the guest operating system yourself; for a fully managed service like Lambda (Part 7) or RDS (Part 6), AWS handles the OS entirely — you're only responsible for your code/data and your access configuration. A strong interview answer names this explicitly: "the exact line moves up the stack as you move from raw infrastructure (EC2) toward fully managed/serverless services (Lambda) — but 'my data, my access control' never moves off my side of the line, no matter which service I'm using."

---

Understanding the AWS Bill — Free Tier, On-Demand, and Beyond#

A practical, foundational topic worth covering before diving into any specific service, since every subsequent part will reference pricing models.

A full, dedicated treatment of cost optimization strategy — Reserved Instances vs Savings Plans math, Spot fleet design, rightsizing — is covered later in this series (Part 12), since it deserves its own focused discussion once the underlying services (compute, storage, databases) are already understood.

---

The AWS CLI and SDKs — Your Actual Daily Tools#

The AWS Console (the web UI) is genuinely useful for exploration and learning, but real production work — and every command shown throughout this series — goes through the AWS CLI or a Software Development Kit (SDK), both of which are just clients calling the exact same underlying AWS API.

Copy
# Configure the CLI with credentials (interactive)
aws configure

# Verify who you're currently authenticated as —
# genuinely the first command to run when anything seems wrong
aws sts get-caller-identity

# Every AWS CLI command follows the same shape:
# aws <service> <action> [options]
aws ec2 describe-instances --region us-east-1
aws s3 ls
aws iam list-users

Why "the Console, CLI, and SDK are just three different clients for the same API" is worth stating explicitly, a genuinely clarifying interview line: nothing you can do in the Console is fundamentally different from what the CLI or Terraform (Automation series) can do — they're all just different ways of calling the same underlying AWS API operations. This is precisely why Infrastructure as Code works at all: Terraform's AWS provider is, under the hood, making the exact same API calls the CLI makes.

---

Tagging — The Unglamorous Habit That Saves Every Team#

A genuinely small, easy-to-skip practice that becomes critically important at real scale — worth taking seriously from day one rather than retrofitting later.

Copy
# Tag an EC2 instance at creation time
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t3.micro \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Environment,Value=production},{Key=Team,Value=payments},{Key=CostCenter,Value=CC-1042}]'

---

Tag Policies — Enforcing Tagging Org-Wide#

A tagging convention that lives only in a wiki page is exactly the kind of well-intentioned rule that quietly erodes over time — worth backing with an actual enforcement mechanism at the Organizations level, not just documentation.

Copy
# A Tag Policy, attached to an OU, that ENFORCES allowed values
# for the Environment tag — non-compliant tags are flagged
# (and can optionally be blocked outright)
cat <<'TAGPOLICY'
{
  "tags": {
    "Environment": {
      "tag_key": { "@@assign": "Environment" },
      "tag_value": { "@@assign": ["production", "staging", "development", "sandbox"] },
      "enforced_for": { "@@assign": ["ec2:instance", "s3:bucket", "rds:db"] }
    }
  }
}
TAGPOLICY

aws organizations create-policy \
  --name "StandardTagging" --type TAG_POLICY \
  --content file://tag-policy.json \
  --description "Enforces standard tag values org-wide"

aws organizations attach-policy \
  --policy-id p-tagpolicy123 --target-id ou-prod-abc123

Why a Tag Policy is meaningfully different from an SCP here, worth stating precisely: an SCP can only ever ALLOW or DENY an API call outright — it has no concept of "this tag value is wrong, but the call itself is fine." A Tag Policy instead reports non-compliance (visible in AWS Config and Resource Groups, covered shortly) without necessarily blocking the action, which is often the more practical default — teams can be nudged toward compliance via visibility and reporting before graduating to a harder SCP-based block once the convention has actually stabilized.

---

AWS Config — Continuous Configuration Compliance#

AWS Config continuously records the configuration state of every resource in an account and evaluates it against rules — the direct, concrete implementation of the "continuous compliance" idea already introduced generically in the DevSecOps series' compliance discussion.

Diagram

Copy
# Enable AWS Config to start recording
aws configservice put-configuration-recorder \
  --configuration-recorder name=default,roleARN=arn:aws:iam::123456789012:role/ConfigRole \
  --recording-group allSupported=true,includeGlobalResourceTypes=true

# Enable a managed rule — flags any S3 bucket without encryption
aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "s3-bucket-server-side-encryption-enabled",
    "Source": {"Owner": "AWS", "SourceIdentifier": "S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED"}
  }'

# Query the current compliance state across the account
aws configservice describe-compliance-by-config-rule \
  --config-rule-names s3-bucket-server-side-encryption-enabled

# Config also keeps a full HISTORY — genuinely useful during
# an incident: "what did this security group actually look like
# 3 hours ago, before the outage started?"
aws configservice get-resource-config-history \
  --resource-type AWS::EC2::SecurityGroup \
  --resource-id sg-0123456789abcdef0

Why the configuration HISTORY feature is worth calling out explicitly as an incident-response tool, directly connecting to the Incident Management series: a Config timeline answering "exactly what changed, and when" is frequently the fastest way to find the root cause of an incident caused by a bad configuration change — far faster than manually reconstructing the timeline from memory or scattered change-request tickets.

---

AWS Trusted Advisor#

A built-in, automated advisor that scans an account against AWS's own best-practice checklist across five categories: cost optimization, performance, security, fault tolerance, and service limits.

Copy
# List available Trusted Advisor checks (Business/Enterprise support plans get the full set)
aws support describe-trusted-advisor-checks --language en

# Get the results of a specific check (e.g. security groups
# with unrestricted access)
aws support describe-trusted-advisor-check-result --check-id <check-id>

Worth stating as an honest, practical limitation, not a criticism: Trusted Advisor's full check catalog requires a Business or Enterprise support plan (covered later in this part) — the free tier only exposes a handful of core checks. Even so, it's a genuinely useful first pass for a new account: it will flag things like open security groups, idle load balancers, unattached EBS volumes racking up cost, and S3 buckets with open access — a fast way to catch the most common, avoidable mistakes early.

---

Resource Groups and the Tag Editor#

As an account accumulates hundreds or thousands of resources, finding "every resource tagged Team=payments" by hand becomes impractical — Resource Groups solve this directly.

Copy
# Create a resource group based on a tag query
aws resource-groups create-group \
  --name payments-team-resources \
  --resource-query '{
    "Type": "TAG_FILTERS_1_0",
    "Query": "{\"ResourceTypeFilters\":[\"AWS::AllSupported\"],\"TagFilters\":[{\"Key\":\"Team\",\"Values\":[\"payments\"]}]}"
  }'

# List every resource currently matching that group's query
aws resource-groups list-group-resources --group-name payments-team-resources

This is the practical, day-to-day payoff of the tagging discipline covered earlier in this part — a well-tagged account turns "find everything owned by team X" from a manual hunt into a single query.

---

Delegated Administration — Spreading Org-Wide Duties#

Not every org-wide administrative duty should route through the management account (Part 1's earlier warning against running WORKLOADS there still stands — but some administrative services genuinely need org-wide visibility). Delegated administration lets specific services (GuardDuty, Security Hub, Config, and others covered further in Part 9) be administered from a DIFFERENT, dedicated account instead of the management account itself.

Copy
# Delegate GuardDuty administration to the security-audit account,
# instead of managing it from the management account directly
aws organizations register-delegated-administrator \
  --account-id 111122223333 \
  --service-principal guardduty.amazonaws.com

Why this matters, worth stating explicitly: it keeps the management account's blast radius as small as possible (directly reinforcing Part 1's core "never run anything unnecessary there" principle) while still letting security/compliance tooling see and act across the entire organization from a purpose-built, appropriately-access-controlled account instead.

---

AWS Support Plans#

Why the support-plan choice is a genuinely real operational decision, not just a cost line item, worth stating explicitly: it directly determines incident response time available from AWS itself during an outage — a Business-or-higher plan's sub-1-hour response guarantee can be the difference between resolving a P1 AWS-side issue quickly and being stuck waiting on the free-tier community forums during a real incident, directly connecting to the severity/response-time discipline already covered in the Incident Management series.

---

AWS Artifact — Compliance Documentation On Demand#

A self-service portal for downloading AWS's own compliance reports and agreements — SOC 2 reports, ISO 27001 certifications, PCI-DSS attestations, and the Business Associate Addendum (BAA) for HIPAA — directly feeding into the compliance discussion already covered in depth in the DevSecOps series (Part 6).

Copy
aws artifact list-reports

Why this matters concretely: when your own organization is pursuing SOC 2 or ISO 27001 certification (DevSecOps series, Part 6), an auditor will typically ask for evidence that YOUR infrastructure provider (AWS) is itself compliant — AWS Artifact is precisely where that third-party evidence comes from, rather than something your team needs to chase down through account managers or support tickets.

---

Service Quotas — Planning Around AWS's Own Limits#

Every AWS account has default limits (quotas) on nearly everything — the number of VPCs per region, EC2 instances of a given type, Lambda concurrent executions — and hitting an unexpected quota mid-incident (or mid-launch) is a genuinely common, avoidable failure mode.

Copy
# Check the current quota (and default) for a specific limit,
# e.g. running On-Demand EC2 instances
aws service-quotas get-service-quota \
  --service-code ec2 --quota-code L-1216C47A

# Request a quota increase BEFORE you actually need it —
# not during an incident or a launch under time pressure
aws service-quotas request-service-quota-increase \
  --service-code ec2 --quota-code L-1216C47A --desired-value 500

Why proactively reviewing quotas is worth treating as a real pre-launch capacity-planning step, directly connecting to the Capacity Planning series: a sudden autoscaling event (Part 3) that hits an account's EC2 instance-count quota fails SILENTLY from the application's perspective — new instances simply don't launch, capacity never grows to meet demand, and the resulting outage looks identical to a completely different kind of failure until someone specifically checks Service Quotas. Reviewing and pre-requesting increases for anything close to a real production ceiling is worth doing well before a launch, not reactively.

---

A Full Worked Landing Zone Bootstrap, Start to Finish#

Bringing every concept in this part together into one concrete, ordered, CLI-driven bootstrap sequence — genuinely worth having as a mental checklist for standing up a brand-new AWS environment correctly from day one.

Copy
# 1. Enable AWS Organizations from the management account
aws organizations create-organization --feature-set ALL

# 2. Create the core OU structure
aws organizations create-organizational-unit --parent-id r-root123 --name Security
aws organizations create-organizational-unit --parent-id r-root123 --name Infrastructure
aws organizations create-organizational-unit --parent-id r-root123 --name Workloads
aws organizations create-organizational-unit --parent-id r-root123 --name Sandbox

# 3. Create the foundational accounts
aws organizations create-account --email log-archive@example.com --account-name log-archive
aws organizations create-account --email security-audit@example.com --account-name security-audit
aws organizations create-account --email shared-networking@example.com --account-name shared-networking

# 4. Attach a baseline SCP denying region sprawl, org-wide
aws organizations attach-policy --policy-id p-regionlock123 --target-id r-root123

# 5. Attach a tag policy enforcing the standard tag set
aws organizations attach-policy --policy-id p-tagpolicy123 --target-id r-root123

# 6. Delegate GuardDuty/Config/Security Hub administration
#    to the security-audit account (Part 9 covers these in depth)
aws organizations register-delegated-administrator \
  --account-id <security-audit-account-id> --service-principal guardduty.amazonaws.com

# 7. Enable AWS Config org-wide, aggregating findings to the
#    security-audit account
aws configservice put-configuration-aggregator \
  --configuration-aggregator-name org-aggregator \
  --organization-aggregation-source '{"RoleArn":"arn:aws:iam::<security-audit-account-id>:role/ConfigAggregatorRole","AllAwsRegions":true}'

# 8. Enable a Business (or higher) support plan before going live

Why doing these steps roughly in THIS order matters, worth stating explicitly: guardrails (SCPs, tag policies) and centralized logging/security tooling should exist BEFORE workload accounts are created and populated with real resources — bootstrapping governance retroactively, after resources already exist, is dramatically more painful (and more likely to be skipped under delivery pressure) than building it in from the very first account.

---

Working Across Multiple Accounts From the CLI — Profiles#

A genuinely practical, daily-use skill worth covering explicitly: once a multi-account structure exists, switching between accounts on the command line needs to be fast and low-friction, or engineers will quietly avoid using it correctly.

Copy
# ~/.aws/config — define a named profile PER account/role,
# using role assumption (Part 2) instead of separate credentials
cat <<'CONFIG' >> ~/.aws/config
[profile prod]
role_arn = arn:aws:iam::111122223333:role/DeployRole
source_profile = identity
region = us-east-1

[profile staging]
role_arn = arn:aws:iam::444455556666:role/DeployRole
source_profile = identity
region = us-east-1
CONFIG

# Use a profile explicitly on any command
aws s3 ls --profile prod

# Or set it for the whole shell session, reducing the risk
# of accidentally running a command against the wrong account
export AWS_PROFILE=staging
aws sts get-caller-identity   # ALWAYS confirm before a risky command

# List every profile currently configured
aws configure list-profiles

Why running aws sts get-caller-identity before any destructive command is worth treating as a hard personal habit, worth stating explicitly, and directly reinforcing Problem 1's lesson earlier in this part: the single fastest way to accidentally run a command against the wrong account is a stale AWS_PROFILE environment variable left over from a previous terminal session — a five-second identity check costs nothing and eliminates an entire, genuinely common class of "wrong account" incident before it happens.

---

Part 1 CLI Cheat Sheet#

A dense, consolidated reference of every command family introduced in this part — genuinely worth keeping open in a second terminal tab while working through real AWS Organizations/governance tasks.

---

Common Mistakes#

---

A Worked Example: Sizing an Initial Multi-Account Structure for a 50-Person Startup#

Bringing this part's concepts down to a genuinely concrete, realistic sizing decision — a question worth having a ready, reasoned answer for.

Diagram

For a genuinely small team (50 people, one product), a full "one account per microservice" structure is usually over-engineering — the right-sized starting point is closer to 6-8 accounts total: log-archive, security-audit, shared-networking, production, staging, and one or two shared sandbox accounts, with individual engineers using IAM Identity Center federation (Part 2) rather than separate personal accounts. Why NOT one account per microservice at this stage, worth stating explicitly as a real, deliberate tradeoff: account-level isolation is genuinely valuable, but each additional account also adds real operational overhead — more SCPs to maintain consistently, more places logging/monitoring must be wired up, more surface area for governance drift. The right account granularity scales UP as the organization and its compliance requirements grow — a 50-person startup and a 5,000-person enterprise reasonably land in very different places on this spectrum, and forcing enterprise-scale account sprawl onto a small team is its own kind of premature complexity.

---

Worked Practice Problems#

Problem 1: A startup begins with a single AWS account containing production, staging, and every engineer's personal dev resources, all mixed together. As the team grows to 30 engineers, a junior engineer's terraform destroy run against what they believed was a staging workspace ends up deleting production database resources, because both were tagged inconsistently in the same account. What's the underlying architectural failure, and what's the fix going forward?

Answer: The underlying failure isn't the specific terraform destroy command — it's that the account itself provided no real isolation between production and staging, so a single mistake (bad tagging, wrong workspace) had a blast radius spanning the entire company's infrastructure. Tags and naming conventions are a much weaker isolation boundary than a genuine account boundary (this tutorial's core point). The fix: migrate to a multi-account structure via AWS Organizations, with production and staging as fully separate accounts under different OUs — a destructive command run against the wrong Terraform workspace would then, at worst, only be able to reach resources within that ONE account's boundary, since cross-account access requires deliberate, explicit configuration.

Problem 2: An organization sets up an SCP on their Production OU that denies all actions outside us-east-1 and us-west-2, expecting this to fully lock down where resources can be created. Six months later, a security review finds an IAM role in a production account with a policy explicitly allowing ec2:RunInstances in eu-west-1, but no instances were ever actually launched there despite this permission existing. Why didn't the IAM policy's broader permission create a real risk, and what does this demonstrate about SCPs?

Answer: This demonstrates exactly the guardrail-vs-grant relationship at the heart of SCPs. Even though the IAM policy granted ec2:RunInstances in eu-west-1, the SCP attached to the Production OU sets an absolute ceiling that denies any action outside the two approved regions — no IAM policy inside that account, no matter how permissive, can exceed that ceiling. The overly broad IAM policy is still worth tightening as a defense-in-depth cleanup (least privilege, per DevSecOps), but the SCP already prevented the actual risk (resources being created in an unapproved region) from ever materializing — a clean, concrete demonstration of why SCPs are described as guardrails, not grants.

Problem 3: A finance team asks for a cost breakdown by team and by environment (prod vs staging vs dev) across the organization's 40 AWS accounts. The engineering team discovers that roughly 30% of monthly spend shows up as "untagged" in the cost report, and cannot be attributed to any specific team. What's the root cause, and what governance change would prevent this going forward?

Answer: The root cause is that resource tagging was never enforced as a mandatory practice — engineers created resources without consistently applying the Team, Environment, and CostCenter tags this tutorial recommends as a minimum baseline, so a meaningful fraction of spend has no attribution metadata at all. The fix has two parts: first, retroactively identify and tag the existing untagged resources where still possible; second, and more importantly, use a preventive control going forward — either an SCP or a Config rule that denies resource creation without the required tags present, turning tagging from a "best practice engineers might forget" into a structurally enforced requirement, the same shift-left philosophy already covered for security scanning in the DevSecOps series.

Problem 4: A newly formed platform team is bootstrapping an AWS Organization from scratch and debates whether to enable AWS Config immediately, or defer it until after the first production workload account is fully built out, arguing "we can add compliance tooling once things are stable." What's the risk in that ordering, and what would you recommend instead?

Answer: Deferring Config until after resources already exist means every resource created in the meantime has zero configuration history and no automated compliance evaluation from day one — if a security-relevant misconfiguration (an unencrypted bucket, an overly permissive security group) happens during that early build-out window, there's no historical record to investigate it against later, and no automated signal ever flagged it in the first place. The stronger recommendation is enabling AWS Config, with an org-wide aggregator reporting to the security-audit account, as part of the initial landing zone bootstrap, before the first workload account is populated — governance tooling is far cheaper to build in from the start than to retrofit after hundreds of resources already exist without any compliance history behind them.

Problem 5: An engineering team requests a large EC2 Auto Scaling Group scale-out ahead of an expected traffic surge for a major product launch, but during the actual event, the ASG's desired capacity increases in CloudWatch while the ACTUAL running instance count stays flat. What AWS-account-level cause, unrelated to the ASG configuration itself, could explain this, and how should it have been caught beforehand?

Answer: A Service Quota limit — most likely the account's default limit on running On-Demand EC2 instances of the relevant instance type/family — being silently hit. When a quota is exceeded, new RunInstances calls the ASG issues internally simply fail, with the ASG's desired capacity showing the INTENDED state while the actual instance count never catches up, producing exactly this symptom. This should have been caught during pre-launch capacity planning by explicitly checking, and proactively requesting an increase for, the relevant Service Quotas well ahead of the expected peak load — treating quota review as a standard, mandatory step of any major launch's capacity plan, not an afterthought discovered only once the limit is actually hit under real traffic pressure.

---

Summary and What's Next#

• AWS is a specific, concrete implementation of concepts already deeply covered elsewhere in this course — every AWS feature in this series maps back to a general principle you already understand.
• Regions are large geographic areas containing multiple Availability Zones — physically independent data centers with separate power/cooling, the real mechanism behind multi-AZ fault tolerance.
• The AWS account is the strongest isolation boundary AWS offers — stronger than a VPC, stronger than an IAM policy — and a single shared account for everything is one of the most common, costly early-stage architectural mistakes.
• AWS Organizations manages many accounts as one hierarchy using OUs; Service Control Policies (SCPs) set a ceiling on what's possible, never grant anything themselves — a critical, frequently-tested distinction from IAM policies (which actually grant permissions).
• AWS Control Tower automates standing up this multi-account "landing zone" pattern, trading some flexibility for a strong, opinionated default.
• The Well-Architected Framework's six pillars (Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability) are AWS's own branded restatement of principles already covered across this entire course.
• The Shared Responsibility Model shifts based on how managed a service is — AWS takes on more of the stack as you move from raw EC2 toward fully managed/serverless services, but your data and access configuration are always your responsibility.
• Tagging, though easy to skip, is foundational infrastructure for cost attribution and blast-radius-aware automation — worth enforcing from the very first resource.

Continue to Part 2 (02-iam-and-identity.md) for a deep dive into IAM — the permission system that governs literally everything you can do inside an AWS account, once you're inside its boundary.