What If Your Cloud Foundation Was a Lego Set?
Anyone can spin up an AWS account and deploy a handful of resources.
But making that process repeatable, secure, and scalable across dozens or even hundreds of accounts? That’s where it usually breaks down.
Over the past few years, I’ve worked with multiple organizations that ran into the same problem: they either postponed setting up a solid foundation or built something so monolithic it couldn’t evolve with their teams.
The solution?
Start treating your Landing Zone like a modular architecture more like a set of Lego bricks than a static blueprint.
The Same Pain Points, Everywhere
I’ve walked into environments where:
– A single misconfigured IAM permission accidentally exposed 40 accounts.
– Cost tracking was a nightmare because tagging wasn’t enforced.
– Developers didn’t know who to contact to deploy something new.
– CI/CD pipelines failed every time teams tried to deploy to a new region.
In every case, the core issue was the same: the Landing Zone was either an afterthought or a black box. So I began treating Landing Zones as product platforms: modular, composable, and extensible.
What a Well-Designed Modular Landing Zone Looks Like
A great Landing Zone should feel like a box of Lego bricks:
– Prebuilt, reusable modules: Separate modules for account creation, security, networking, and more.
– Composable pipelines: Each account follows a standardized CI/CD bootstrap, versioned, auditable, and easy to scale.
– Governance baked in: SCPs, tagging policies, and security baselines applied automatically.
– Decoupled components: Swap out a VPC or update GuardDuty without breaking everything else.
Here’s how we approach this.
Account Factory Fundamentals
– Each account is treated as an independent unit of work.
– Security, networking, and monitoring are applied through reusable modules.
– GitLab CI jobs deploy accounts in parallel using a matrix strategy.
This isn’t “just infrastructure.” It’s a productized foundation that teams can build on without waiting weeks.
Why This Matters More Than Ever
Cloud platforms are evolving fast.
– Data teams need isolated environments for experiments.
– AI teams want GPU-ready accounts with tailored baselines.
– Networking teams demand full control and visibility over subnets and VPCs.
– Security teams need consistency and transparency across every workload.
If your Landing Zone can’t deliver this agility, you’ll slow everyone down.
“Platforms harmonize and standardize without restricting. By standardizing, they actually enable and allow people to do more things.”
— Gregor Hohpe, Sr. Principal Evangelist @ AWS & Author of Platform Strategy
What was once a one-time setup task is now a strategic enabler or blocker for modern cloud adoption.
Skip modularity today, and you’ll pay later:
– Rewriting Terraform modules under pressure.
– Backfilling tags and budgets.
– Rethinking your security posture on the fly.
A Proven Architecture That Actually Scales
We manage hundreds of AWS accounts by sticking to a simple principle: every building block should be replaceable without breaking the whole set.
Core features
– Security Baseline: CloudTrail, Config, Security Hub, and GuardDuty enabled by default.
– Account Vending: Automated and policy-driven.
– Networking: Delete default VPCs, deploy environment-specific VPCs, optionally connect via Transit Gateway with RAM.
– SCPs: Block risky actions like root usage, enforce encryption, restrict to approved regions, and allow only vetted resources.
– Tagging: Enforced via tag policies and Terraform validate hooks.
All of it is GitOps driven, so teams can fork, test, and deploy in hours not weeks.
Steal These Principles
Want to avoid enterprise paralysis and build a Landing Zone that truly helps your teams?
Anchor on these principles:
| Principle | Why It Works |
| Composable modules | Teams build what they need without starting from scratch. |
| Guardrails over gates | Security happens automatically, without becoming a bottleneck. |
| GitOps workflows | Changes are auditable, repeatable, and CI-driven by default. |
| Cost of change < cost of delay | You’ll pay either way — choose the right currency. |
And remember: you don’t need everything on Day 1. But you do need to design like you’ll scale.
