Multi-Account Architecture with Organizations

Prerequisites: An AWS Organizations management account (or the ability to create one — note this requires a payment method on the account and cannot be undone easily), and at least one additional AWS account to invite as a member (a free secondary account works fine for this exercise).

Every AWS environment past a certain size stops being 'one account' and becomes a multi-account architecture — separate accounts for production, staging, security tooling, logging, and individual teams, all under one AWS Organization. The reasons are blast-radius isolation (a mistake in staging can't touch production IAM), billing clarity, and the ability to apply guardrails that no identity-based policy inside an account can override.

This project builds the core primitives: the Organization itself, an OU hierarchy, Service Control Policies (SCPs) that cap what any principal — including the account's own root user — can do, delegated administration (so a security team doesn't need management-account access to run GuardDuty or CloudTrail org-wide), and a tag policy for consistency across accounts. This is the manual, CLI-level version of what AWS Control Tower automates; doing it by hand once is what makes Control Tower's abstractions make sense later.