Your AWS account is not a strategy. Ten unmanaged accounts? That’s a liability waiting to show up in your next audit.
We learned this the hard way. When we started building landing zones for enterprises the pattern was always the same. Inconsistent security baselines. Developers getting accounts with zero guardrails. A networking setup held together by tribal knowledge and a Confluence page nobody’s updated since 2021.
A landing zone fixes this. It’s the foundation that makes governance, security, cost control, and developer velocity work together. But how you build that landing zone matters just as much as building one at all.
Why enterprises need a multi-account strategy
You know what an AWS account is. The question worth asking: why do organizations with 5, 50, or 500 accounts need a formalized approach?
Blast radius containment. A misconfigured IAM role in dev shouldn’t touch production data. Account-level isolation is the strongest boundary AWS offers. Stronger than VPCs, stronger than IAM policies. Use it.
Compliance at scale. GDPR, SOC 2, NIS2. The regulatory landscape keeps expanding. Manually auditing each account is a losing game. You need guardrails that prevent violations, not detectives that find them after the damage is done.
Cost visibility. Without proper account structure and tagging enforcement, your FinOps team is flying blind. We’ve seen organizations burn through six figures in unattributed spend because nobody enforced tagging from day one.
Developer velocity. This one surprises people. Good governance doesn’t slow teams down. When a developer can self-service a new account that comes pre-configured with networking, logging, and security baselines, they ship faster than the team waiting three weeks for IT to set things up manually. We’ve seen this firsthand at clients: proper account vending turned a multi-week process into minutes.
Key components of a landing zone
Every enterprise landing zone needs these building blocks, regardless of tooling choice.
1. Account vending
Automated account creation with pre-configured baselines. A developer requests a workload account, and within minutes gets:
- An account in the correct OU with appropriate SCPs applied
- VPC with standardized CIDR ranges connected to Transit Gateway or access to a Shared VPC
- CloudTrail, GuardDuty, Config, and Security Hub enabled
- IAM Identity Center access configured
- Budget alerts set
No tickets. No waiting. No manual setup where someone forgets a step.
We treat account vending as an internal product, not a one-off project. It needs versioning, testing, and a backlog. The teams consuming accounts are your users, and their experience matters.
2. Guardrails: SCPs and Config Rules
Service Control Policies are your first line of defense. They define what can’t happen, regardless of IAM permissions:
- Prevent disabling CloudTrail or GuardDuty
- Restrict deployments to approved regions (
eu-west-1,eu-central-1, critical for GDPR) - Block public S3 buckets and unencrypted EBS volumes
- Require specific tags on all resources
AWS Config rules complement SCPs by detecting drift continuously. Together: preventive and detective controls.
Our advice? Start opinionated. Lock things down. It’s much easier to relax a guardrail for a legitimate use case than to retroactively enforce one after teams have built around its absence.
3. Networking
Transit Gateway as the backbone, connecting workload VPCs to shared services and on-premises networks. The key decisions:
- Hub-and-spoke vs. or Shared VPC’s
- Centralized vs. distributed egress
- DNS resolution strategy (Route 53 Resolver rules)
- Network Firewall placement
Get networking wrong and everything else suffers. This is consistently where we see the most technical debt in organizations that grew their AWS footprint organically.
4. Identity and access
IAM Identity Center for human access. Federate with your existing IdP (Entra ID, Okta) and define permission sets mapped to organizational roles.
For machine-to-machine: IAM roles with clearly scoped policies. Cross-account access through role assumption. Never long-lived credentials. We’re amazed how many enterprise environments we still find with static access keys older than some of the team members using them.
5. Centralized logging and security
A dedicated Log Archive account aggregating:
- CloudTrail organization trails
- VPC Flow Logs
- Config snapshots and compliance history
- GuardDuty and Security Hub findings
A separate Security Tooling account runs your automation: remediation lambdas, SIEM integrations, compliance dashboards. Keep security tooling isolated from the logs it acts on.
What the docs don’t tell you
We’ve built enough of these to know where the real pitfalls are. What we wish someone had told us earlier.
Test your landing zone like software. We use CDK’s assertion testing to validate that constructs produce the expected CloudFormation output. We test SCPs against realistic scenarios. We run cdk-nag in CI. Infrastructure code deserves the same quality bar as application code. Most organizations don’t treat it that way, and they pay for it later.
Don’t ignore day-two operations. A landing zone that deploys beautifully but can’t be updated safely is a ticking time bomb. Design for incremental updates from the start. CDK’s cdk diff and staged rollouts make this manageable, but only if you plan for it.
FinOps from day one. Bake cost allocation tags, budget alerts, and anomaly detection into your baseline. Retrofitting cost visibility after 18 months of untagged resources is painful and expensive. We’ve helped clients cut their AWS bill by 30% just by implementing proper tagging and account structure. That’s not optimization, that’s visibility.
Code ownership is non-negotiable. This is core to how we work at Forrict. Every line of CDK code we write for your landing zone? You own it. The Git repo, the pipeline, the deployment process, all yours. We don’t create vendor lock-in to ourselves. When we leave, you should be able to maintain and evolve your landing zone independently. That’s freedom through craftsmanship.
Ready to build your AWS foundation?
A solid landing zone is the difference between an AWS environment that scales with confidence and one that gets more fragile as you grow. The investment pays for itself in security posture, compliance readiness, developer productivity, and cost visibility.
At Forrict, we build landing zones you own completely. No proprietary tools, no managed-service lock-in. Solid CDK code, battle-tested patterns, and the knowledge transfer to run it yourself.
Want to set up your AWS foundation the right way? Let’s talk.
Forrict
AWS expert and consultant at Forrict, specializing in cloud architecture and AWS best practices for Dutch businesses.
