AWS Organizations and Multi-Account Strategy: Landing Zone, SCPs, and Cross-Account Access
Running everything in a single AWS account is the most common infrastructure mistake startups make. It starts simple, but by the time you have production workloads, staging environments, CI/CD pipelines, and developer sandboxes sharing the same account, you have a security boundary problem. One misconfigured IAM policy in a dev environment can expose production data. A runaway Lambda in staging can hit your account-wide service limits and take down production.
AWS Organizations lets you create a hierarchy of accounts with centralized billing and governance. The recommended structure is an organizational unit (OU) tree: a Security OU for audit and logging accounts, an Infrastructure OU for shared services like networking and DNS, a Workloads OU split into Production and Non-Production, and a Sandbox OU for developer experimentation. Service Control Policies (SCPs) enforce guardrails across the organization - prevent disabling CloudTrail, restrict which regions can be used, block public S3 buckets, and require encryption on all resources. SCPs are deny-by-default boundaries that even account administrators cannot override.
Cross-account access uses IAM roles with sts:AssumeRole. A developer in the development account assumes a role in the production account with read-only permissions for debugging. CI/CD pipelines in a shared tools account assume deployment roles in each environment account. The key pattern is: identity lives in one account, permissions are granted via roles in target accounts. AWS Control Tower automates the Landing Zone setup with account factory, guardrails, and a dashboard for compliance - it is the fastest path to a well-structured multi-account environment if you are starting from scratch.
Need help structuring your AWS accounts? InstaDevOps designs and implements multi-account strategies for growing teams. Book a free consultation.
Top comments (0)