Your first architectural decisions on AWS have long-term impact. A well-designed landing zone gives your team a secure, scalable foundation, and prevents complexity from creeping in as you grow.
Forrict helps you build AWS foundations that are clear, predictable, and fully under your control.
What is an AWS landing zone?
AWS describes a landing zone as a well-architected, multi-account environment based on security and compliance best practices. It is the container that holds all of your organizational units (OUs), accounts, users and other resources that you want to be subject to compliance regulation. (source)
In short: not one account where everything is mixed together, but a fixed structure where every new account is set up securely from its first minute.
Why landing zones matter
Without a solid foundation, AWS environments tend to grow organically, and unpredictably. Accounts multiply, permissions drift, costs become harder to track, and security controls slowly weaken.
A strong landing zone helps you:
- scale safely across teams and environments
- reduce security and compliance risk
- keep costs visible and predictable
- avoid rework later on
It’s much easier to build this right from the start than to fix it later.
The building blocks of a Forrict landing zone
Every landing zone is tailored, but these parts are always in it.
Account vending
New accounts in minutes
A new account lands in the right OU automatically, with networking, logging, security settings, access and budget alerts already in place. No tickets, no forgotten steps.
Guardrails
SCPs and AWS Config
Service Control Policies define what is never allowed, such as disabling CloudTrail or deploying outside the agreed regions. AWS Config rules flag anything that drifts anyway.
Networking
Transit Gateway and DNS
A fixed address plan, connections between VPCs, shared services and on-premises, and clear choices for egress, DNS and firewalls.
Identity and access
IAM Identity Center
People sign in through your existing identity provider, with permissions per role. Applications use IAM roles, not long-lived access keys.
Logging and security
Central and separated
CloudTrail, VPC Flow Logs, Config history and GuardDuty and Security Hub findings come together in a dedicated Log Archive account. Security tooling runs in its own account.
Cost
Tags and budgets
Mandatory tags, budget alerts and anomaly detection are part of the baseline from day one, so you always see what each team and environment costs.
All built using AWS best practices and services. How we approach each part technically is covered in AWS Landing Zones with CDK.
An example account structure
AWS recommends grouping accounts into organizational units (OUs), each with its own purpose. (source) A common starting point looks like this:
| OU | Purpose according to AWS | Example accounts |
|---|---|---|
| Security | Accounts that apply security policies, governance and compliance controls across the organization | Log Archive, Security Tooling |
| Infrastructure | Shared infrastructure and networking services | Network (Transit Gateway), shared services |
| Workloads | Your own applications, production and non-production | Development, test and production accounts per team |
| Sandbox | Experimentation, testing and development, typically with limited access to production | Developer sandbox accounts |
We tailor the exact layout to your teams, environments and compliance requirements.
Three kinds of guardrails
AWS distinguishes three kinds of controls (guardrails) in a landing zone. (source)
| Kind | What it does | How it works |
|---|---|---|
| Preventive | Stops an action from happening | Service Control Policies (SCPs) and Resource Control Policies (RCPs) |
| Detective | Flags when something drifts | AWS Config rules |
| Proactive | Checks resources before they are created | CloudFormation hooks |
An SCP grants no permissions itself. It sets the maximum permissions that users and roles in an account can have, whatever their IAM policies say. SCPs apply to member accounts, not to the management account. (source) Our advice: start strict. Relaxing a guardrail for a legitimate exception is much easier than enforcing one after the fact.
Governance without bureaucracy
Governance doesn’t have to slow teams down. At Forrict, governance means setting clear boundaries that help teams move faster and safer, not adding layers of approval.
We focus on:
- Guardrails instead of manual controls
- Automation over documentation
- Clear ownership and responsibilities
- Visibility instead of restriction
This way, teams know what’s allowed, what’s not, and why.
Built as code, and yours
We build your landing zone as code with AWS CDK, and treat that code as software:
- Tested. Assertion tests check that the CDK code produces the expected CloudFormation, and
cdk-nagruns in the pipeline. - Safe to update.
cdk diffshows what a change will do before it happens, and updates roll out in stages. - Yours. The Git repository, the pipeline and the deployment process belong to you. You can maintain and evolve your landing zone yourself, also without us.
How we build this with you
-
Understand your context Your teams, workloads, risks, and growth plans.
-
Design the foundation Clear architecture that fits your organization — not a generic template.
-
Build openly Everything is documented, explained, and visible.
-
Enable your team We make sure your team understands the setup and can work with it confidently.
No black boxes. No vendor lock-in.
What you get
- A secure, scalable AWS foundation
- Clear account and permission structures
- Strong security and compliance baselines
- Easier operations and cost control
- A setup your team actually understands
You’re ready to grow, without losing control.
When this is useful
Landing Zones & Governance are especially valuable if you:
- Are starting fresh on AWS
- Are growing beyond a single AWS account
- Need better security or compliance controls
- Want to standardize across teams
- Are tired of fixing foundational issues later
Frequently asked questions
What is an AWS landing zone? A multi-account AWS environment set up according to fixed rules: a clear account structure, central access, networking, logging and guardrails. Every new account meets your security and compliance agreements straight away.
Why multiple AWS accounts instead of one? An account is the strongest boundary AWS offers, stronger than a VPC or an IAM policy. If something goes wrong in a development account, production stays out of it. You also see exactly what each account costs.
What is the difference between an SCP and an IAM policy? An IAM policy grants permissions. An SCP grants none, but sets the limit of what is allowed in an account at most. (source)
Who owns the code? You do. The CDK code, the repository and the pipeline belong to your organization, so you are not tied to us.
Where is Forrict based? Forrict is based in ‘s-Gravenmoer, in North Brabant, the Netherlands.
Further reading
- AWS Landing Zones with CDK: the technical approach, step by step
- Connect Overlapping IP Ranges Without Renumbering: 1:1 NAT in Transit Gateway and Cloud WAN
- AWS Security Assessment: find out where your current environment stands
Ready to build your AWS foundation?
Let’s design a landing zone that supports your growth, now and in the future. Email info@forrict.nl to get started.