AWS Scenarios
Landing Zone Guardrails For Multi-Account AWS
Design a governed AWS landing zone using AWS Organizations, Control Tower, OUs, SCPs, Account Factory, IAM Identity Center, centralized logs, preventive controls, detective controls, and account enrollment.
After this, you will understand
A landing zone teaches learners that accounts are security and ownership boundaries, not just containers for resources.
Use Organizations and Control Tower to create governed accounts, apply controls by OU, centralize logs, and give teams safe account vending instead of ad hoc account creation.
Every team creates accounts differently, SCPs are attached without testing, logs stay in workload accounts, or access is managed user by user.
Separate OUs by risk and lifecycle, provision accounts through a standard path, apply preventive and detective controls, centralize audit evidence, and delegate daily administration.
Think before readingWhat is the most important SCP mental model?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Landing zones
- AWS Organizations
- Organizational units
- Control Tower
- Preventive and detective controls
- Service control policies
- Account Factory
- IAM Identity Center
- Log archive and audit accounts
- SAA-C03 governance traps
1. Situation
A company is moving from a few AWS accounts to dozens or hundreds. Teams need separate accounts for production, development, security tooling, networking, analytics, and sandboxes.
The company wants account isolation without chaos. Every account should have baseline logging, identity access, security controls, and network expectations.
The question is:
how do we let teams move fast without letting every account become a snowflake?
A landing zone is the governed multi-account foundation. AWS Organizations provides the account hierarchy. AWS Control Tower can orchestrate account setup and controls. SCPs and Control Tower controls define boundaries.
2. Naive Design
The naive design lets every team create its own AWS account with its own root email, IAM users, logging, VPC style, and security settings.
This works for a while, then becomes an audit and operations problem. No one knows which accounts exist, which Regions are allowed, where logs go, or who has admin access.
Another naive design attaches a strict SCP to the whole organization root without testing. That can break deployments across every account at once.
A third mistake is using the management account for daily operations. The management account should be protected because many organization-level actions depend on it.
3. What Breaks
Governance breaks when account creation is manual and inconsistent.
Security breaks when logs, Config, GuardDuty, IAM Identity Center, and CloudTrail are not uniformly enabled.
Ownership breaks when accounts do not have clear business owners, environments, cost tags, or support paths.
Permissions break when learners think SCPs grant access. SCPs do not grant permissions. They restrict the maximum permissions that identity and resource policies can grant in member accounts.
Operations break when existing accounts are moved into OUs without understanding inherited controls.
4. AWS Architecture
Use AWS Organizations as the foundation. Create OUs that reflect governance boundaries, such as Security, Infrastructure, Production, Development, Sandbox, Suspended, and Workloads.
Use AWS Control Tower when the organization wants a managed landing zone experience with account provisioning, baseline controls, shared accounts, and drift visibility.
Use Account Factory to provision new accounts through a standard path. This gives teams a repeatable account vending process.
Use IAM Identity Center for workforce access into accounts. Prefer permission sets and groups over long-lived IAM users.
Use SCPs for broad guardrails such as denying disabling security tooling, denying unsupported Regions, or preventing dangerous root-user activity in member accounts.
Use centralized log archive and security accounts for audit evidence and security tooling.
5. Request Or Data Flow
A team requests a new production account.
The cloud platform team chooses the correct OU. Account Factory provisions or enrolls the account with baseline settings.
Controls apply at the OU level. Preventive controls block prohibited actions. Detective controls monitor for noncompliance. Proactive controls can check resources before provisioning where supported.
IAM Identity Center grants the right groups access through permission sets.
CloudTrail, Config, and security services report to central accounts or delegated administrators.
The account owner deploys workloads inside the boundary rather than inventing the boundary.
6. Security Controls
Protect the management account. Use it only for tasks that require it.
Use delegated administrator accounts for supported services. Security teams should not need daily access to the management account just to manage findings.
Use SCPs carefully. Test in a smaller OU before broad rollout. Keep emergency access and rollback plans.
Use centralized CloudTrail logging. Workload accounts should not be able to delete their own audit history.
Use IAM Identity Center for human access and short-lived credentials. Avoid account-local IAM users for workforce access.
Apply controls by OU, not by scattered manual account configuration.
7. Resilience Controls
Keep account provisioning repeatable. A standard account vending process is a resilience control for the cloud platform itself.
Monitor Control Tower drift where applicable. Drift means the environment has moved away from the governed baseline.
Do not put all workloads into one production account. Account boundaries reduce blast radius for incidents, quotas, permissions, and billing ownership.
Keep break-glass access documented and tested. A locked-down organization with no recovery path is not secure.
Use tagging, account metadata, and owner records so incidents route to the right people.
8. Performance Controls
Landing zones are mostly governance architecture, but they affect operational speed.
Good account vending reduces friction. Teams can get accounts faster because the security baseline is already handled.
Poor guardrail design slows every deployment. Overly broad SCPs can break service-linked roles, CloudFormation, regional deployments, or managed service behavior.
Use service last accessed data, CloudTrail, and staged testing to understand impact before tightening policies.
9. Cost Controls
Multi-account strategy improves cost attribution. Accounts can map to products, environments, or teams.
Use AWS Budgets, Cost Explorer, CUR/Data Exports, and account-level tagging strategy to track spend.
SCPs can help restrict expensive regions or services, but billing controls also need budgets, alerts, quotas, and ownership.
Control Tower, Config rules, security services, logs, NAT gateways, and baseline resources can create per-account cost. A sandbox account baseline should still be intentional.
10. Exam Variants
"Set up and govern many AWS accounts using best practices" points to Control Tower.
"Create accounts through a repeatable governed process" points to Account Factory.
"Set maximum permissions across member accounts" points to SCPs.
"SCP should grant access" is a trap. SCPs only set boundaries.
"Centralize workforce access" points to IAM Identity Center.
"Reduce use of the management account" points to delegated administrators where supported.
11. Common Traps
Do not attach an untested SCP to the organization root.
Do not use SCPs as identity policies.
Do not forget that SCPs do not affect users and roles in the management account.
Do not let every account create its own logging pattern.
Do not skip account ownership metadata.
Do not confuse consolidated billing with full Organizations features.
12. Related Topics
Review AWS Account Model, AWS Organizations, Service Control Policies, AWS Control Tower, AWS IAM Identity Center, and Secure Cross-Account CloudTrail Logging.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.