Architecture Consultation
Certification & Cloud Learning Consultation
Multi-Cloud Identity Pro: AWS & Azure
AWS Secure Landing Zone with Control Tower and AFT
HashiCorp Certified: Terraform Professional
OpenTofu & Terragrunt: From zero to migration from Terraform
AWS infrastructure via Terraform and Terragrunt
7 Structural Mistakes in Production AWS Landing Zones
Over the past years working with multi-account architectures, I've spotted many cases that initially looked "correct," but eventually led to painful refactoring. I've seen these situations across companies of all sizes that aimed to implement Landing Zones properly.
Most of them focused only on their initial requirements:
- Multiple accounts
- Infrastructure as Code for implementation
- Centralized activity tracking
- A structured identity system across the organization
All of these points are valid, and tooling is rarely the issue. The real problem is the structural assumption that a Landing Zone is just a deployment template. It's not.
A Landing Zone is a governance architecture that must be carefully designed and properly maintained over time.
Based on this experience, below I've outlined seven structural issues I most frequently see in production AWS environments and how to evaluate them during audits.
Designing the Structure for Today, Not for Growth
Most companies build their OUs and accounts structure following current needs:
Organization
└── OU root
├── Account Security
├── Account Shared Services
├── OU production
│ ├── account1
│ ├── account2
│ └── ...
├── OU stage
│ └── account1
└── OU dev
└── account1
And it looks reasonable — like it covers all environments and isolates them. But problems come later, when:
Even if it looks similar, it's not just a cosmetic change. It determines future operational complexity and provides flexibility on management sub-OUs and accounts.
Organization
└── OU root
├── OU security
│ └── Account Security
├── OU share
│ └── Account Shared Services
└── OU Workloads
├── OU APP1
│ ├── OU Prod
│ │ ├── account1
│ │ └── account2
│ ├── OU Stage
│ └── OU Dev
└── OU APP2
└── ...
IAM Governance Without Identity Lifecycle Control
What is the most common pattern for IAM identity management in many organizations?
- Create batches of roles per project
- Grant permissions incrementally over time
- No defined ownership or expiration
- No tracking or periodic review
Role_A ├── Policy_1 ├── Policy_2 ├── Policy_3 └── +10 inline policies
Identity management is often one of the most common sources of security issues in cloud environments. And following these practices, they often evolve into something like the above.
At this point, simple questions like "Who owns this role?" or "Why were these permissions granted?" becomes difficult to answer. Without lifecycle enforcement, IAM identities management becomes chaotic.
Landing Zones help address this problem by enabling centralized identity governance from a dedicated account. Identity management can be controlled, shared, and maintained from a single place. This makes it possible to enforce a governance lifecycle such as:
With clear ownership and regular reviews, identity sprawl becomes manageable and auditable.
SCP Guardrails That Don't Enforce Risk Boundaries
In many organizations, Service Control Policies (SCPs) exist, but they are symbolic and designed only around immediate operational needs. Typical examples look like:
Deny: * in region X Deny: EC2:* if instance type X
These policies enforce technical preferences, but they rarely address the actual security risks within the environment.
Critical controls are often missing, such as preventing IAM privilege escalation, disabling logging, or exposing storage resources publicly. A simple misconfiguration — like creating a public S3 bucket — can lead to significant security incidents if proper guardrails are not enforced.
Instead, SCPs should be designed around the organization's risk boundaries. For example:
Deny: - Disable CloudTrail - Modify Security Hub configuration - Create public S3 buckets without encryption - Create IAM users
When SCPs are structured around risk controls rather than operational preferences, they become an effective governance layer that reflects the company's security posture.
Logging Without Detection Architecture
Most environments enable logging in each account:
This is a good starting point, but logging alone is not observability yet. If detection mechanisms are missing, logs simply become additional storage cost and create a false sense of security.
Security teams often assume that because logs exist, incidents can be detected. In reality, without detection rules, correlation, and monitoring pipelines, these logs are rarely analyzed in practice.
Landing Zones help address this by introducing a centralized logging architecture. Instead of storing logs independently in each account, they can be aggregated into a dedicated logging account where security monitoring and detection systems operate. This enables to implement much easier:
With a proper detection layer, logs become part of a security architecture rather than passive data storage.
Network Architecture Without Clear Ownership
In many environments, networking is implemented independently inside each workload account:
Account A - VPC Account B - VPC ... Account N - VPC
Works initially, but over time leads to duplicated components, inconsistent configs, and complicated cross-account connectivity.
Network Account ├── Transit Gateway └── Shared VPCs to Account A/B/.../N
Workload accounts connect to central architecture. Resources shared via AWS RAM.
Landing Zones usually introduce a dedicated networking domain. Clear network ownership simplifies connectivity management and enforces consistent security boundaries across the organization.
Infrastructure as Code Only for "Compute"
A common pattern is using Terraform for workload resources (VPCs, EC2/EKS, IAM roles, RDS), while the governance layer remains managed manually.
- VPCs
- EC2 / EKS
- IAM roles
- RDS
- AWS Accounts
- OUs
- SCPs
- Organizational controls
This creates drift between environments and makes scaling painful.
Landing Zones work best when the governance layer is treated as code as well. This means core elements such as accounts, OUs, SCPs, and baseline configurations should be versioned, reviewed, and deployed through controlled pipelines.
No Cost Governance Embedded in Architecture
Cost management is one of the most important concerns for every organization operating in the cloud. However, even a single missing element from the governance model can lead to financial problems:
All these elements should be integrated into the architecture as part of financial governance. And Landing Zones helps us to organize proper model:
Business account ├── Workload Account ├── Budget Threshold ├── Cost Allocation Tags └── Alerts to Owner
Embedding these controls into the Landing Zone architecture makes costs visible and predictable. As without this, cloud cost management becomes reactive instead of predictable.
Conclusion
Most Landing Zones fail not because of incorrect Terraform or missing tools.
They fail because the architecture was designed for current needs rather than long-term scale.
We always need to remember, that Landing Zone is not just an infrastructure template, it is a governance system.
And AWS highlights many of these lessons in their own guidance. Reviewing these structural elements early helps ensure that a Landing Zone can support both current workloads and future organizational growth.