Well-Architected architecture study
Multi-Account Landing Zone Guardrails
A governance-first landing zone design for separating workloads, centralizing audit, and enforcing guardrails before application teams deploy.
AWS
AWS Organizations
AWS
Workload accounts
AWS
SCPs + IAM Identity Center
AWS
Central logging account
AWS
Security Hub + AWS Config
Problem
A single AWS account becomes difficult to secure as environments, teams, and workloads grow. The architecture needs separation of duties, centralized audit, consistent guardrails, and a repeatable path for new accounts.
Design
- AWS Organizations groups accounts by environment and ownership.
- Control Tower or an account vending workflow creates standardized workload accounts.
- IAM Identity Center centralizes human access with permission sets instead of long-lived IAM users.
- Service control policies prevent high-risk actions such as disabling CloudTrail or creating public S3 buckets outside approved workflows.
- A central logging account receives CloudTrail, Config, and security findings.
Well-Architected lens
- Security: account boundaries, least privilege, immutable audit logging, and preventive guardrails.
- Operational excellence: repeatable account creation and standardized baseline controls.
- Cost optimization: budgets and cost allocation tags applied at account creation.
- Reliability: blast-radius reduction through environment and workload isolation.
Why it is not live here
A real landing zone requires AWS Organizations and multiple accounts. Keeping that structure purely for a personal portfolio would add administrative overhead without improving the public site's runtime value.