Multi-Account Strategy & Security Baseline

In one line

Production AWS uses many accounts under AWS Organizations as hard isolation boundaries, with SCP guardrails, centralized identity and logging, and threat detection from GuardDuty, Security Hub, and Config running everywhere by default.

0/4 · 0%

Think of it like this

A company doesn't put every department in one giant room with shared keys. Separate offices (ACCOUNTS) mean a fire in marketing doesn't spread to finance; building-wide rules (SCPs) apply to every office; and a central security desk (the security account) watches every camera.

Key ideas

01
An AWS ACCOUNT is the strongest isolation boundary AWS offers — separate IAM, separate resource limits, separate billing lines. Standard layout: a management account (billing and Organizations only), a LOG ARCHIVE account, a SECURITY/audit account, and separate workload accounts per environment (dev, staging, prod), often per team.
02
AWS ORGANIZATIONS groups accounts into OUs and applies SERVICE CONTROL POLICIES (Phase 1.3) — e.g. deny leaving the organization, deny disabling CloudTrail/GuardDuty, deny regions you don't use, deny creating IAM users with access keys. CONTROL TOWER automates setting this landing zone up.
03
Humans sign in once via IAM IDENTITY CENTER (Phase 1.4) and get role-based access into each account; nobody uses the root user of member accounts.
04
Detection services, enabled organization-wide with a delegated admin in the security account: GUARDDUTY (threat detection from CloudTrail, VPC Flow Logs, and DNS — crypto-mining, credential exfiltration, known-bad IPs); AWS CONFIG (records resource configuration history and evaluates rules like 'no public S3 buckets', 'EBS encrypted'); SECURITY HUB (aggregates findings and scores accounts against standards like CIS and AWS Foundational Best Practices); IAM ACCESS ANALYZER (resources shared outside your organization).
05
Findings are only useful if someone acts on them: route high-severity findings through EventBridge to your paging/ticketing system, and auto-remediate the obvious ones (e.g. re-enable Block Public Access).

Code & diagrams

baseline-scp.jsonjson

Attached to the workloads OU: nobody in member accounts — including admins — can disable the security baseline.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectSecurityServices",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging", "cloudtrail:DeleteTrail",
        "guardduty:DeleteDetector", "guardduty:DisassociateFromMasterAccount",
        "config:StopConfigurationRecorder", "config:DeleteConfigurationRecorder",
        "organizations:LeaveOrganization"
      ],
      "Resource": "*"
    },
    {
      "Sid": "NoLongLivedUserKeys",
      "Effect": "Deny",
      "Action": ["iam:CreateUser", "iam:CreateAccessKey"],
      "Resource": "*"
    }
  ]
}

detection.shbash

# From the management account: make the security account the delegated admin
aws guardduty enable-organization-admin-account --admin-account-id 222233334444
aws securityhub enable-organization-admin-account --admin-account-id 222233334444

# From the security account: auto-enable for every current and future account
aws guardduty update-organization-configuration --detector-id $DETECTOR \
  --auto-enable-organization-members ALL

# Review high-severity findings
aws guardduty list-findings --detector-id $DETECTOR \
  --finding-criteria '{"Criterion":{"severity":{"Gte":7}}}'

LandingZonediagram

Rendering diagram…

Explain it without notes

Why use separate AWS accounts for dev and prod instead of separating them with IAM policies and tags in one account?

What's the difference between GuardDuty and AWS Config?

Practice

GuardDuty reports UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS. What happened, and what do you do first?

List the first five things you'd set up in a brand-new AWS Organization for a company about to go to production.

Trade-offs

↔
Many accounts give strong isolation and clear cost ownership, but add overhead: cross-account networking, shared services, and deployments pipelines that must assume roles into each account — which is why landing-zone tooling like Control Tower exists.

Done when you can

I can explain why accounts are the primary isolation boundary.
I know the standard landing-zone account layout.
I use SCPs to protect the security baseline.
GuardDuty, Config, and Security Hub are enabled organization-wide with findings routed to people.