Building an AWS Landing Zone: What Most Companies Get Wrong
By Joel Gray, Solution Architect
Organizations often rush into AWS with the best intentions: move faster, reduce infrastructure costs, improve scalability, and modernize applications. However, one of the most common mistakes I see is companies begin their cloud journey before establishing a proper AWS Landing Zone.
A Landing Zone is more than just a collection of AWS accounts. It’s the foundation upon which security, governance, networking, compliance, and operational excellence are built. When organizations skip this step or treat it as an afterthought, technical debt accumulates quickly and becomes expensive to fix later.
What Is an AWS Landing Zone?
An AWS Landing Zone is a multi-account AWS environment designed according to AWS best practices. It provides a secure, scalable, and governed foundation for workloads.
A well-designed Landing Zone typically includes:
- AWS Organizations
- Separate accounts for production, development, testing, and shared services
- Centralized logging
- Identity and access management
- Network architecture
- Security guardrails
- Compliance controls
- Cost management frameworks
Think of it as building the roads, utilities, and zoning regulations before constructing a city.
Mistake #1: Starting with a Single AWS Account
Many organizations begin with a single AWS account because it seems simpler.
Initially, it works.
Then the environment grows.
Development, testing, production, security tools, and multiple teams all end up sharing the same account. Permissions become difficult to manage, resources become harder to track, and troubleshooting grows increasingly complex.
Better Approach
Use a multi-account strategy from day one:
- Management Account
- Security Account
- Log Archive Account
- Shared Services Account
- Development Accounts
- Production Accounts
Account boundaries provide one of the strongest security controls available in AWS.
Mistake #2: Ignoring Identity Strategy
Many cloud deployments still rely heavily on IAM users and manually managed credentials.
This creates unnecessary risk and administrative overhead.
Better Approach
Integrate AWS with your existing identity provider:
- Microsoft Entra ID (Azure AD)
- Okta
- Ping Identity
Implement:
- Single Sign-On (SSO)
- Multi-Factor Authentication (MFA)
- Role-Based Access Control (RBAC)
- Least-Privilege Access
Identity should be centralized and managed consistently across every AWS account.
Mistake #3: Weak Network Design
Networking is often treated as an afterthought.
Teams deploy workloads first and attempt to solve connectivity challenges later.
The result is overlapping IP space, difficult routing decisions, and expensive redesigns.
Better Approach
Design networking before workloads arrive.
Consider:
- VPC strategy
- CIDR planning
- Transit Gateway architecture
- Hybrid connectivity
- VPN and Direct Connect requirements
- DNS design
As someone with a networking background, I’ve learned that poor network planning creates problems that persist for years.
Cloud does not eliminate networking fundamentals—it makes them even more important.
Mistake #4: No Centralized Logging
Security incidents become much harder to investigate when logs are scattered across multiple accounts.
I’ve seen organizations discover too late that critical logs were never retained or were overwritten.
Better Approach
Centralize logging from the beginning.
Implement:
- AWS CloudTrail
- Amazon CloudWatch
- VPC Flow Logs
- AWS Config
- Security findings aggregation
Store logs in a dedicated Log Archive account with restricted access.
When an incident occurs, you’ll be grateful you invested in centralized visibility.
Mistake #5: Overly Permissive IAM Policies
One of the most common findings during security reviews is excessive permissions.
Policies granting AdministratorAccess become the default solution because they’re easy.
They’re also dangerous.
Better Approach
Adopt the Principle of Least Privilege.
Use:
- Permission boundaries
- Service Control Policies (SCPs)
- Role-based access
- Access Analyzer
- Regular permission reviews
The goal is to provide users only the access they need to perform their job—and nothing more.
Mistake #6: Lack of Security Guardrails
Organizations frequently rely on manual processes to enforce security standards.
Manual processes eventually fail.
Better Approach
Automate security controls.
Examples include:
- Enforcing encryption at rest
- Blocking public S3 buckets
- Requiring approved regions
- Restricting root account usage
- Mandatory tagging standards
Guardrails should prevent bad configurations before they become security incidents.
Mistake #7: Ignoring Cost Governance
Cloud costs rarely become a problem overnight.
They grow quietly until leadership asks why the monthly bill doubled.
Better Approach
Establish financial governance early.
Implement:
- Cost allocation tags
- Budgets and alerts
- Savings Plans
- Reserved Instances
- Cost anomaly detection
Every resource should have a business owner and a purpose.
If nobody owns it, it shouldn’t exist.
Mistake #8: Treating the Landing Zone as a One-Time Project
Many organizations view Landing Zone deployment as a project with a finish line.
In reality, it’s a living platform.
New services emerge. Security requirements evolve. Business priorities change.
Better Approach
Treat the Landing Zone like a product.
Continuously improve:
- Security controls
- Governance policies
- Automation
- Compliance monitoring
- Operational procedures
A mature Landing Zone evolves alongside the business. While the Landing Zone should be used to manage global governance, security, networking, and account provisioning, workload-specific infrastructure—such as VPCs, Amazon RDS databases, Amazon S3 buckets, and Amazon EKS clusters—should be deployed and managed using Infrastructure as Code tools like AWS CloudFormation or Terraform.
Key Takeaways
An AWS Landing Zone is not simply an infrastructure project. It is the foundation for every future cloud initiative.
Organizations that invest in proper governance, identity management, networking, security, logging, and cost controls early in their cloud journey avoid many of the challenges that plague large-scale AWS environments later.
I’ve found that the most successful cloud transformations aren’t necessarily driven by the newest technology. They’re driven by disciplined planning and strong foundations.
Before deploying your next workload, ask yourself:
“Is our AWS environment designed for where we are today—or where we plan to be three years from now?”
The answer may determine the success of your cloud strategy.
How Does Tekstream Address These Challenges with AWS Landing Zone Accelerator?
AWS addresses many of these common cloud governance challenges through the AWS Landing Zone Accelerator (LZA). LZA is an open-source solution that codifies AWS best practices into an automated deployment framework, enabling organizations to establish a secure, scalable, and well-governed multi-account AWS environment. It is particularly well suited for large enterprises and highly regulated industries, including government, healthcare, and financial services.
One of the greatest advantages of AWS Landing Zone Accelerator is that the source code, documentation, and deployment examples are publicly available, allowing organizations to adopt proven architectural patterns without starting from scratch.
At TekStream, we leverage AWS Landing Zone Accelerator to accelerate cloud adoption while tailoring the implementation to each customer’s business, security, and compliance requirements. Rather than spending months building a landing zone from the ground up, we can deploy a production-ready AWS foundation that incorporates governance, security guardrails, centralized logging, networking, identity management, and automation—helping customers reduce risk and focus on delivering business value.