AWS Landing Zone Accelerator: What Enterprise IT Directors Need to Know
A practical breakdown of AWS LZA for teams migrating from on-prem DC environments — governance, networking, and the gotchas no one talks about.
Most AWS documentation assumes you’re starting from a greenfield cloud environment. It rarely acknowledges the reality that your on-prem estate has 15 years of accumulated network architecture, Active Directory hierarchy, and compliance posture baked into it.
This post is for IT directors who know their DC inside out and need a honest translation of what Landing Zone Accelerator (LZA) actually does — and what it doesn’t solve for you.
What LZA Actually Is
AWS Landing Zone Accelerator is an open-source CDK application that deploys a multi-account AWS environment following AWS best practices. It configures AWS Control Tower guardrails, SCPs, networking baselines, security tooling (GuardDuty, Security Hub, Config), and centralised logging in a single deployment pipeline.
Think of it as the AWS interpretation of what your on-prem team already built over the last decade — network segmentation, centralised security visibility, privileged access management — but reimplemented in cloud-native primitives.
The Three Things That Catch Teams Off Guard
1. The OU structure maps to your org, not your tech topology. On-prem teams often design their network zones around technical tiers (web, app, data). LZA structures accounts around business units and risk posture. If your CISO hasn’t been in the room during the OU design session, that’s a problem to fix before you deploy.
2. Transit Gateway is not your MPLS replacement — it’s a complement. Teams coming from hub-and-spoke MPLS networks reach for Transit Gateway instinctively. It’s the right call for inter-VPC connectivity, but your hybrid connectivity layer (Direct Connect or VPN) still needs to be designed separately, and the BGP community strategy matters far more than most AWS guides acknowledge.
3. The pipeline is the product. LZA deploys everything through a CodePipeline. If your security team isn’t comfortable approving infrastructure changes via pull request and pipeline approval gates, you’ll have friction on day one. This is actually a feature, not a bug — it forces infrastructure-as-code discipline from the start — but it requires a change in operating model that needs to be socialised early.
A Starting Point for DC-Heavy Environments
If you’re migrating from a traditional DC setup, consider this phased LZA rollout:
- Phase 1: Deploy LZA into a non-production OU first. Validate networking, logging, and GuardDuty coverage before touching production.
- Phase 2: Establish Direct Connect or Site-to-Site VPN for hybrid connectivity before migrating workloads. Running LZA doesn’t automatically give you a network path to on-prem.
- Phase 3: Pilot one non-critical workload migration to validate your operating model — runbooks, change management, on-call routing.
The organisations that get this right treat LZA as the foundation, not the project. The project is the operating model change.
ZoomZoom Cloud specialises in enterprise cloud transformations for organisations with significant on-prem estate. Get in touch to discuss your migration roadmap.
Working on a cloud transformation?
Talk to us. We'll give you a direct, honest assessment of your situation — no sales pitch.
Book a Discovery Call