What does a practical AWS Landing Zone architecture actually look like?
A Landing Zone isn't simply "multiple AWS accounts". The important part is how those accounts are structured, governed and connected.
The reference architecture in the diagram shows the main building blocks I would expect to think about when designing a governed multi-account AWS environment.
Management Account
This sits at the top of AWS Organizations and should primarily be used for organisation-level governance and administration — not as somewhere to deploy normal application workloads.
Organizational Units (OUs)
Accounts are grouped into OUs so governance can be applied deliberately. The OU structure becomes important because policies such as Service Control Policies can be applied to groups of accounts rather than managed individually.
Security / Audit Account
Security functions can be separated from the workload accounts they're monitoring. This provides a central place for security visibility and administration rather than making every workload account responsible for its own security oversight.
Log Archive Account
Centralised logs such as CloudTrail records can be stored separately from the accounts generating them.
That separation matters because a compromised workload account shouldn't also provide the easiest route to the historical logs you may need to investigate it.
Workload Accounts
Applications and environments live outside the Management Account and can be separated according to the organisation's requirements.
The account boundary itself becomes part of the architecture rather than relying entirely on permissions inside one large AWS account.
Identity
IAM Identity Center can provide central workforce access across the AWS organisation, with users and groups receiving appropriate permission sets rather than maintaining separate IAM users across every account.
Guardrails
Service Control Policies and other controls can establish boundaries around what accounts are allowed to do.
One important distinction: an SCP doesn't grant a user permission to perform an action. It sets the maximum permissions available within the accounts it applies to. IAM permissions still determine what the principal can actually do.
Central security and monitoring
Services such as AWS Config, CloudTrail, GuardDuty and Security Hub can form part of the wider governance and security architecture rather than being treated as isolated services configured independently in every account.
Networking
The account structure also needs a networking strategy.
As the environment grows, you need to decide which networks should communicate, what should remain isolated, where shared connectivity belongs and how that connectivity will be governed.
The main point is that a Landing Zone is a foundation for running AWS, not simply an AWS Organizations account tree.
The account structure, identity model, guardrails, logging, security and networking all need to work together.
I've written a more complete walkthrough of the architecture here, including the design decisions, common mistakes and the full reference architecture:
CloudOps Studio — AWS Landing Zone Architecture: Secure Multi-Account Design
Interested to hear how others structure their Landing Zones — particularly where you draw the boundaries between workload, security, shared services and networking accounts.
Source: r/AWSLandingZones · by /u/One-Interview2664