Here’s an uncomfortable truth I’ve learned after building hundreds of AWS Landing Zones: the one you deployed two years ago is already out of date. And the longer you wait to address it, the more expensive the fix becomes.
According to AWS, customers typically rebuild their Landing Zones every three years. Not update. Rebuild. The reasons are predictable: accumulated technical debt, shifting business requirements, and team transitions that were never properly documented. These rebuilds can cost hundreds of thousands of dollars when you factor in engineering time, migration risk, and the inevitable production incidents along the way.
It doesn’t have to be this way.
The Maintenance Burden Nobody Budgets For
A well-architected Landing Zone isn’t a single service or a one-time deployment. It’s the coordinated configuration of roughly 45 different AWS services spanning management, security, identity, observability, networking, backup, and financial controls.
Management alone includes Control Tower, CloudFormation, Organizations, KMS, Well-Architected Tool, and EventBridge. Security adds Security Hub, GuardDuty, Config, CloudTrail, Macie, Detective, and Inspector. Then there’s IAM, Identity Center, CloudWatch, Trusted Advisor, VPC, IPAM, Cost Explorer, Budgets, and dozens more.
Every one of these services releases updates throughout the year. New features. Deprecated configurations. Changed defaults. Security patches. Keeping them aligned and functioning as a cohesive Landing Zone is a full-time job—often multiple full-time jobs.
The Documentation Problem
The rebuild cycle isn’t just about technical drift. It’s about knowledge drift.
The engineer who made the original architecture decisions left eighteen months ago. The runbooks live in a Confluence page that hasn’t been updated since the initial deployment. The IAM policies were modified in response to a production incident, but nobody remembers why those specific permissions were added.
When a new platform engineer inherits this environment, they face an impossible choice: spend months reverse-engineering decisions they don’t understand, or start fresh and risk breaking things that were working. Most choose the rebuild, and the cycle repeats.
Build vs. Buy: The Real Math
Here’s what I’ve learned building Landing Zones for startups and enterprises alike: the structural patterns are remarkably similar. The account hierarchy, the security baseline, the networking topology, the compliance controls—these aren’t unique differentiators. They’re infrastructure plumbing.
The question isn’t whether you can build your own Landing Zone. Of course you can. Your engineers are smart. But let’s look at the actual numbers.
Building a Landing Zone from scratch typically costs $80K–$500K in initial development and takes 2–12 months before you see production value. Annual maintenance requires 1–2 dedicated FTEs, adding another $100K–$250K per year. That’s before you factor in the hidden costs: context switching when those engineers get pulled to feature work, technical debt that accumulates when Landing Zone updates compete with revenue-generating projects, and the knowledge gaps that emerge when your original architect moves on.
Then ask yourself: Is your Landing Zone a competitive differentiator? Do customers choose you because of your Landing Zone capabilities? Does it appear in your sales materials? For most companies, the honest answer is no. Infrastructure is expected, not valued. Your customers care about what you build on top of that foundation.
The Ownership Problem
Who owns your Landing Zone maintenance and evolution? What happens when the original architect leaves? Is Landing Zone work prioritized, or does it become perpetual technical debt?
I’ve seen this pattern repeatedly: Landing Zone ownership becomes “nobody’s job.” It competes with feature development for roadmap priority. Documentation grows stale because updating it isn’t billable work. When something breaks, there’s no clear escalation path—just engineers scrambling to reverse-engineer decisions made two years ago by people who no longer work there.
The red flags are predictable. “We’ll build it when we have time”—it never gets proper attention. “It can’t be that hard”—underestimating complexity leads to technical debt. The original architect leaves, and suddenly you’re facing a knowledge transfer nightmare. Sales waits weeks for infrastructure provisioning. Customers ask “why so long?” and you’ve created a competitive disadvantage.
When Building Makes Sense
Building your own Landing Zone makes sense in exactly one scenario: when cloud infrastructure is your core product offering. If you have a dedicated expert infrastructure team of 3+ FTEs, unique requirements that no vendor can meet, 9+ months to invest before customer delivery, and a track record of successfully maintaining complex infrastructure products—then building might be the right choice.
For everyone else, it’s a distraction.
The Alternative
Buy your Landing Zone from people who maintain it year-round. People who’ve seen the patterns across hundreds of deployments and know which configurations cause problems at scale. People whose entire job is tracking AWS service updates and ensuring your foundation stays current.
The math shifts dramatically. No initial development investment—you’re operational in hours instead of months. Maintenance is included, not a separate budget line requiring dedicated headcount. Compliance updates happen automatically. When AWS releases new best practices or deprecates old patterns, someone else handles the upgrade path.
This isn’t about capability. It’s about focus and total cost of ownership over a five-year horizon. Your platform team’s time is finite and expensive. Every hour they spend debugging Control Tower upgrades or implementing CIS benchmarks manually is an hour they’re not spending on the infrastructure that actually differentiates your business.
The Landing Zone you deploy today will be technical debt in three years—unless someone is actively maintaining it. The only question is whether that someone should be you, or whether you should leverage ongoing innovation without the maintenance burden.