AWS Account Strategy, Organizations, and Landing Zones
What This Chapter Is About
Teach AWS hierarchy, multi-account design, and landing zones as the operating structure that turns governance goals into practical team boundaries.
Keep one durable idea in view:
In AWS, account boundaries are architecture boundaries for blast radius, ownership, policy, and cost.
Sections
How the Chapter Develops
The chapter develops in this order:
Start with the reason AWS architects use multiple accounts instead of only bigger VPC layouts.
Explain Organizations, OUs, and SCPs as the hierarchy for governance and delegation.
Show how landing zones and account vending make the hierarchy operational.
Place shared services, logging, and platform capabilities into the right accounts and boundaries.
Apply the model to a global enterprise with central controls and independent business units.
Together, these sections show that account strategy is the backbone of AWS operating design, not just an administrative setup choice.
What You Will Be Able to Do
By the end of this chapter, the reader should be able to:
Explain why multi-account design is a default AWS architecture pattern.
Describe how Organizations, OUs, accounts, and SCPs work together.
Explain the purpose of landing zones, account vending, and prepared environments.
Separate workload accounts, security accounts, logging accounts, and shared platform accounts by responsibility.
Recommend a practical multi-account strategy for a growing enterprise.
Key Ideas
AWS accounts are one of the most important isolation and ownership boundaries in the platform.
Organizations and OUs help express policy, delegation, and operational structure.
Landing zones are operating models, not just one service or setup script.
Shared services and central controls should support team autonomy rather than erase boundaries.
Good account strategy improves security, cost ownership, evidence, and delivery independence together.