What exactly is an AWS Landing Zone?
A mental model for designing and implementing a solid and scalable AWS Cloud foundation
“Indifference towards people and the reality in which they live is actually the one and only cardinal sin in design.”
— Dieter Rams
A Landing Zone should provide account governance and management, identity controls, security guardrails, centralised logging, and foundational cost visibility - nothing more. Despite most organisations treating AWS Landing Zones as monolithic systems, we advocate that supporting domains such as Cloud Networks and Tenant Management should be handled separately from the Landing Zone implementation due to ownership and configuration lifecycle.
This article clarifies these boundaries based on real-world implementations, helping you avoid the cookie-cutter traps that generate technical debt within months.
Main insights
Modularity: Clear ownership boundaries reduce operational friction and enable independent team workflows;
Precise Scope: Landing Zones handle governance, accounts, security, logging, and basic cost management - not networks or tenant management;
Security-First: Threat models must address account isolation, identity compromise, and complete audit trails;
Avoid Monoliths: AWS LZA bundles everything into one complex framework; modular Terraform provides flexibility without vendor lock-in;
Infrastructure as Code: Use standard CI/CD patterns for maintainability and extensibility;
Confusion about AWS Landing Zone boundaries
As an infrastructure leader, it is very probable that you have inherited an AWS environment that grew with little governance: different teams provisioned accounts manually, security controls are inconsistent, tagging is at times non-existing. You then get a lot of flak from compliance audit findings because no one can explain who has access to what. The network team operates independently. Application teams wait weeks for new environments.
Several attempts have been made by AWS to provide a simple and effective way of preventing this pain, from the legacy and overly complex Landing Zone, and lately to the AWS Landing Zone Accelerator (LZA) which bundles governance, networking, observability, and tenant management into one layered CDK project.
This creates a false belief that everything must be deployed together, resulting in added operational complexity, deployment bottlenecks, and limited infrastructure optionality. Take the example of LZA - making a network change requires coordination with non-related deployments (e.g. guardrails, logging, security, etc), and you may need to wait a couple of hours for its monolithic CodePipeline to complete, before knowing if your change will succeed or not.
This bundling of different infrastructure domains violates a basic principle: related infrastructure should change together, but unrelated systems must evolve independently. When everything is coupled, every change becomes a wider risk, the system becomes fragile because one team’s mistake impacts everyone.
The empirical evidence and success factors from my actual implementations reveal a case for a modular approach:
Landing Zones, Core Networks, and Tenant Management, represent distinct functional domains with different ownership, different life-cycles, and different operational requirements. Treating them as separate systems simplifies operations and eliminates coordination overhead;
Do not use software for business critical components, which (i) will force you into deployment cycles of 4-8 hours before you get feedback on your changes, (ii) will surely break in production, and (iii) you will likely not have the knowledge, time, or willingness to fix it.
Our AWS Landing Zone architecture
Our AWS Landing Zone reference architecture consists of six capabilities which address specific governance requirements without reaching into networking or application domains. This modular separation creates clear ownership boundaries and operational independence, allowing changes to happen with minimal coordination overhead.
The following diagram describes our capabilities, built on top of the undercurrents (Source Code Management, CI/CD, configuration state), and topped with a threat model that looks into threat actors and response.
AWS Landing Zone
In our view, a Landing Zone provides exactly six capabilities. Each capability addresses specific governance requirements without reaching into networking or application domains.
Multi-Account Governance: AWS Control Tower (and AWS Organizations) establishes the organisational structure and base account vending. Standardised guardrails (using SCPs, Config), aligned with compliance frameworks, are also available to deploy from Control Tower. Account tagging policies ensure consistent resource classification;
Account Vending: Account Request mechanisms provide self-service interfaces, Account Provisioning automates account creation, and Account Customisation applies baseline configurations specific to workload types. The objective is to get a fully automated workflow completing in minutes, not days;
Identity and Access Management: Permissions Management Strategy defines how access is granted and revoked across accounts. AWS IAM Identity Center provides Single Sign-On capabilities. Service Roles establish cross-account access patterns for automation. This ensures identity management scales without creating security vulnerabilities or operational bottlenecks;
Security and Guardrails: Preventative Controls use Service Control Policies and Resource Control Policies, to block disallowed actions before they occur. Detective Controls leverage AWS Security Hub, AWS Config, and Amazon GuardDuty to identify misconfigurations and threats. Data Protection Strategy implements encryption requirements through AWS KMS. These controls operate at the account and Organization Unit level;
Centralised Logging: AWS CloudTrail logs control plane API events for all accounts in a central location. Application, Access, and Service logs can be captured using Amazon CloudWatch Logs or sent directly to S3 or OpenSearch. VPC Flow Logs can be used to monitor network traffic flows. Log Analysis and Investigation tools (e.g. Amazon Athena, OpenSearch) enable security teams to investigate incidents. This provides visibility without dictating how networks or applications are constructed, while allowing for a centralised location for log analysis, forensics, retention;
Foundational Cost Management: Cost Allocation and Visibility establishes tagging strategies that enable accurate cost attribution. Automated Cost Controls implement budgets and alerts. Cost Monitoring and Alerting provides real-time spending visibility through AWS Cost Explorer and Budgets.
Undercurrents of the Landing Zone
Every component should be implemented using Infrastructure-as-Code. We strongly favour an approach where each functional area lives in its own repository with its own CI/CD pipeline, as described in this blog post: The Landing Zone repository contains only Landing Zone code; the Core Network repository contains only network code; the Tenant Management repository contains only tenant provisioning code, and so on.
This pattern creates functional boundaries that mirror how organisations actually operate: each team deploys independently, without strong dependencies requiring synchronised releases across domains. State management follows the same hierarchical pattern as defined at the repository level: each central platform repository has dedicated Terraform state storage, storing the different stack state files which are managed through that repository (see the same blog post for further detail).
We also favour using vanilla GitLab CI or GitHub Actions pipelines as the deployment mechanism, avoiding specialised orchestration frameworks if possible (see the cases for simplified Terraform workflows and vanilla CI/CD pipeline orchestration).
Threat modelling
When designing and implementing a Landing Zone, it is critically important to identify and plan for different threats, and to understand how the architecture responds to them.
External Threats: The Landing Zone operates at the control plane with minimal external attack surface. If attackers compromise a workload account, SCPs prevent dangerous actions such as disable logging, or modify security controls. GuardDuty detects reconnaissance, compromised credentials, and exfiltration attempts. Automated response workflows quarantine compromised resources via Lambda functions triggered by EventBridge rules.
Internal Threats: Legitimate users with excessive privileges pose greater risk than external attackers. IAM Identity Center provides centralized authentication with corporate SSO integration. Implement least-privilege access with just-in-time (JIT) mechanisms for temporary elevated permissions. Break-glass procedures require immediate multi-stakeholder alerts, automated activity screenshots, and time-limited access.
Identity Compromise: CloudTrail captures all API calls with source IP, user agent, and role. GuardDuty alerts on anomalous patterns. Automated Lambda functions triggered by high-severity findings immediately suspend compromised identities and terminate sessions. SCPs provide a secondary control layer preventing privilege escalation even if administrative credentials are compromised.
Data Protection: KMS centralizes key management. S3 policies enforce encryption at rest. SCPs prevent unencrypted storage creation. VPC endpoints for S3 keep data transfer within AWS networks. GuardDuty identifies suspicious transfer patterns; Macie discovers sensitive data in unexpected locations. Defense-in-depth requires bypassing multiple independent layers for successful exfiltration.
Audit Integrity: CloudTrail logs flow to the Log Archive account with read-only cross-account access. SCPs prevent log deletion. Deletion attempts trigger immediate multi-channel alerts. This ensures immutable audit trails for security incidents and compliance evidence.
Zero-Day Response: SCPs enable rapid response with minimal environment disruption. If vulnerabilities affect specific services, SCPs block usage across organizational units within seconds. Amazon Inspector provides automated vulnerability scanning with EventBridge integration for quarantine workflows.
What does not belong in an AWS Landing Zone
Cloud Networks form a separate functional domain. Transit Gateways, VPCs, Network Firewalls, DNS resolution, and hybrid connectivity require different expertise. Usually a Cloud Networks team will own this domain, either a different team, or a sub-team. Changes to network architecture should not require Landing Zone modifications, and vice-versa. This separation eliminates coordination overhead.
Tenant Management represents another distinct domain. Tenant-specific VPCs, application infrastructure, and workload configurations belong to application teams. The Landing Zone provides the governance framework. Tenant Management provides the standardised templates and self-service capabilities. Application teams own their deployments.
The Hammurabi test: Does this architecture make risk visible?
The Code of Hammurabi established a simple principle: if a builder constructed a house that collapsed and killed the owner, the builder was executed - a naive interpretation may see it as “an eye for an eye”, but it’s way more sophisticated - it deals with the invisible transfer of risk. The principle applies to infrastructure architecture. When consultants and vendors design complex systems, do they share the consequences when those systems fail? Or at the very least, can they make risk visible, so you know what to watch out and prepare for?
Our reference architecture answers the hard questions that reveal whether an approach is robust or merely sophisticated.
How does your Landing Zone facilitate rapid workload isolation during a zero-day vulnerability? Service Control Policies enable immediate restriction of dangerous actions across all accounts. The account structure allows quarantine of specific workloads without touching un-related configuration. Incident response happens in minutes, not hours while the LZA CDK Framework pipeline is still running and comparing irrelevant and unchanged settings.
What percentage of your cloud budget comes from shared infrastructure vs. applications specific infrastructure? The modular approach makes this transparent. The Landing Zone consumes specific resources with specific costs. Networks consume different resources. Each domain reports costs independently. Bundled frameworks obscure this visibility because everything shares the same deployment stack.
Can you describe the implications of changing traffic patterns or data sovereignty, over your cloud infrastructure? The Landing Zone makes no assumptions about network topology. If data sovereignty rules change, the network team reconfigures routing without Landing Zone involvement. If traffic patterns shift, network architecture adapts independently. The Landing Zone remains stable because it never depended on network details. Bundled frameworks embed network assumptions throughout the governance layer, making adaptation expensive.
How does your compliance monitoring differentiate between technical compliance and actual security? Service Control Policies prevent dangerous actions regardless of whether someone ticked a compliance checkbox. AWS Config continuously validates actual resource configurations. Security Hub aggregates evidence from multiple detective controls. Compliance teams review transparent and modular code showing what is actually deployed.
If key platform engineers leave, can the remaining team maintain and evolve the infrastructure? The modular approach uses standard tools that any competent engineer understands. There are no proprietary frameworks requiring specialized knowledge. Documentation lives in code. New engineers read the repository structure and understand the system. Complex vendor frameworks create knowledge concentration and operational risk.
The difference between architectures that account for your risk and architectures that create risk becomes obvious when you ask questions about actual failure scenarios rather than idealised success paths.
Final thoughts
In my view, the distinction between a Landing Zone and other domains determines operational success: clear boundaries ensure teams’ autonomy. When everything is bundled together, coordination overhead dominates.
We recommend our clients to start with a clear definition of what the Landing Zone provides, and to build it with standard tools that any engineer can maintain. Keep it separate from networks and tenant management.
Here are some key principles that work really well for our clients.
Operational autonomy: Teams work with minimal coordination overhead across domains. The network team modifies routing without waiting for the platform team. The platform team updates security controls without consulting application teams. This independence reduces brittleness and accelerates time-to-market from weeks to days (see case-study);
Flexibility and extensibility: Approaches like AWS Landing Zone Accelerator locks you into a complex monolithic CDK implementation. Modifying the framework requires understanding AWS-specific abstractions: if your use-case differs from the author’s platonic design and implementation, you may find yourself stuck with infrastructure that doesn’t adapt;
Maintainability: Complex frameworks require specialists. When something breaks, only a few people understand the system. In the case of AWS Landing Zone Accelerator, encountering an unexpected bug (more often than not) means that your deployment mechanism is halted until the bug is fixed, or you remove the stack that caused it (sometimes clean Cloudformation) - blog post coming soon;
Compliance and Security: Your compliance and risk team needs provable controls. Service Control Policies provide preventative guardrails that auditors can verify. Detective controls provide evidence that the organisation monitors for threats. Centralised logging provides the audit trail regulators demand.
Modularity always wins: The modular approach simplifies compliance by creating clear ownership - each function or domain is aligned with its own repository, each team maintains documentation for their domain, audits become faster because responsibilities are explicit.
I invite you to subscribe to my blog, and to read a few of my favourite case-studies describing how some of my clients achieved success in their high-stakes technology projects, using the very same approach described.
Have a great day!
João