The account structure you would design if you had the time
You know what good looks like. Separate accounts with real boundaries, an address plan that survives the third region, identity that is not a pile of roles, guardrails that cannot be argued with. You also know it is two quarters of work before a single product team benefits from it.
What you are actually arguing about
The design is not the hard part for a good platform engineer. The hard part is the six months of unglamorous implementation between the diagram and a team using it.
Everything runs in one account, or in a structure that grew by accident, and the platform team has been asked to fix it without stopping delivery.
-
“Our cloud account structure made sense when we were five people.”
Environments share a blast radius, and every new team negotiates its own boundaries inside it.
-
“Every team sets up infrastructure differently.”
Each variation is defensible on its own and impossible to govern together. Security and cost reviews become archaeology.
-
Address ranges were chosen when there was one region and one environment.
Overlapping ranges block peering and expansion later, when changing them is at its most expensive.
-
Roles were added one at a time, by whoever needed access.
There is no access model to describe, only an inventory, and nobody can say what production access actually means.
-
Guardrails are documented in a wiki page rather than enforced.
A policy that depends on people remembering it is a suggestion, and it will be violated during the next incident.
What building it yourself costs
Not whether your team could build this. Whether this is the best use of the two quarters it would take.
- Time to first benefit
- Account structure, network, identity, logging, guardrails and pipelines have to be finished together before a single product team can move onto them.
- The parts nobody budgets for
- Address planning, policy edge cases, cross-account observability, drift handling and the review tooling are where bespoke landing zones stall.
- Opportunity cost
- Your platform engineers are the people who would otherwise be removing friction for product teams. A landing-zone build takes them off that entirely.
- Maintenance ownership
- Whatever you build, someone owns forever. A bespoke landing zone means the upgrade path is also bespoke.
What we do about it
We deliver a landing zone that is already written, customize it to your naming, regions and address plan, deploy it into your accounts, and hand over the repositories.
-
Account structure with intent
Dedicated accounts for security, audit, identity, network, DNS, artifacts, automation, internal tools and intentionally public assets, plus identical workload accounts built from one template.
-
A network you can extend
Hub and spoke topology with isolation between production and non-production traffic, centralized egress across three availability zones, and address management that refuses hardcoded ranges in review.
-
Identity as a model, not an inventory
Single sign-on with defined permission sets per role, production read-only except for named leads, auditor roles with an explicit deny on data, and no cloud users or access keys anywhere.
-
Guardrails that are enforced, not documented
Service control policies that deny long-lived credentials, restrict regions and protect the audit trail, with a tag policy that can move from reporting to enforcement with one flag.
-
Expansion as routine work
A new account is a map entry and a folder. A new region is a folder. Address management, the region policy and the tag policy pick both of them up.
The outcome: You get the landing zone you would have designed, running in your own accounts, defined in code your team reviews and extends. Your platform engineers spend their quarters on developer experience instead of on rediscovering network design.
What that is, in the portfolio
-
BuiltForProd Baseline
A multi-account cloud foundation in OpenTofu and Terragrunt, customized for your organization, deployed into your accounts by our engineers, then handed over with the repositories and the documentation.
-
BuiltForProd Managed
Experienced engineers who operate, secure and evolve production as an extension of your team, working through your own access, pull requests and pipelines.
What you get
-
The full account and organization structure
Core accounts for security, audit, identity, networking, DNS, artifacts, automation and internal tooling, and workload accounts per environment, all defined in code.
-
Network topology and address plan
Hub and spoke connectivity, isolation domains between production and non-production, centralized egress, flow logging on every network and an address plan sized for many regions.
-
Identity and permission sets
Role-based access across every account through single sign-on, with session limits and unused-access reporting built in.
-
A review-driven pipeline
Plans posted on pull requests, dependency-ordered applies across accounts, production gated on approval, and federated credentials instead of stored keys.
-
Guard scripts that keep the code honest
Automated checks for hardcoded ranges, network map integrity, stack layout, module versions and required inputs, so a new environment can be planned before anything exists.
-
Every decision marked and explained
Deployment-specific values and optional choices are tagged in the code, with the cost written next to each switch that carries one.
-
The upstream upgrade path
Your repositories are forks, and improvements come downstream through a documented compare, branch, plan and review flow with a risk matrix.
Every repository and every cloud account stays yours. We keep no standing access after handover. See security and ownership for how that is enforced, and pricing for how an engagement is quoted.
The specification
What gets deployed, counted. Argue with the design by all means; these are the numbers behind it.
| What | Figure | Where it comes from |
|---|---|---|
| Accounts and organizational units | 14 accounts, 2 OUs | The AWS Enterprise Baseline: nine core accounts, four workload accounts from one template, and the management account outside the OUs. |
| Guardrail policies | 3 SCPs | Security guardrails, region restriction and audit protection in the AWS Enterprise Baseline, plus a tag policy. |
| Permission sets | 11 | The AWS Enterprise Baseline identity design, with production read-only except for platform and DevOps leads. |
| Address plan | 16 regions x 8 stages | The AWS Enterprise Baseline IPAM plan, with one address map that CI enforces. |
| Centralized egress | 3 availability zones | NAT per availability zone in the AWS Enterprise Baseline hub. Spoke networks carry no NAT of their own. |
| Adding an account | 2 pull requests | A map entry and a folder in the AWS Enterprise Baseline. Adding a region is a folder. |
The same evidence is documented page by page in the product documentation and measured against the BuiltForProd Standard.
How it works
Four steps from the first conversation to a platform your team owns.
-
A design review, not a pitch
We walk your platform engineers through the account model, the network topology, the identity design and the guardrails, and argue about the trade-offs properly.
-
Your names, regions and address map
Namespace, home region, address plan, which optional controls earn their cost, which compliance packs apply. Every decision is recorded, then the fee is fixed.
-
Deployment, phase by phase
State backend, organization, pipeline identity, identity and networking, security services, DNS, spoke networks and secrets, each verified before the next.
-
Handover to your platform team
Your engineers add an account, make a change, review a plan, apply it and handle a drift issue themselves. Then the repositories and accounts are yours.
Yes, but…
The objections we hear on the first call, answered plainly.
We could build this ourselves.
You could, and we will tell you when you should. The question is whether your platform engineers should spend two quarters on account structure and address planning, or on the developer experience your product teams are waiting for.
Is this a wrapper around a managed landing-zone service?
No. It is infrastructure code in your repositories, written in OpenTofu and Terragrunt, that you can read, change, extend and fork. There is no console we control and no runtime dependency on us.
We already have a landing zone we have outgrown.
That is a common starting point, and there is a documented migration path from AWS Control Tower. Existing accounts can be brought into the structure rather than recreated.
How opinionated is it? We have our own conventions.
Opinionated about properties, flexible about names. Naming, regions, addressing, optional controls and compliance packs are yours to set. The isolation model and the guardrails are the part we will argue for.
What happens when the upstream code improves?
Your repositories are forks, so you pull improvements through a compare, branch, plan and review flow with a documented risk matrix. You decide what to take and when.
Questions
What is a landing zone?
A landing zone is the multi-account cloud foundation that everything else runs inside: account structure, identity, network topology, logging, guardrails and the delivery pipeline. It is the part that is expensive to change later, which is why it is worth designing once and correctly.
Is this specific to one cloud?
BuiltForProd Baseline is delivered as the AWS Enterprise Baseline, the Azure Enterprise Baseline and the GCP Enterprise Baseline, each engineered around that cloud's own architecture framework and all built to the same BuiltForProd Standard. The counts on this page describe the AWS edition.
What tooling is it written in?
OpenTofu and Terragrunt, with GitHub Actions pipelines, and static analysis and policy checks in the review path. It is source-available under the PolyForm Internal Use License and built on open-source tooling.
Can existing workloads move in gradually?
Yes. Workload accounts are created from one template, so teams migrate one environment at a time while the original environment keeps running.
Who operates it afterward?
Your platform team, which is the point of the handover session. Managed engineers are available for upgrades, findings triage and expansion work, through your own pull requests.
More answers are in the FAQ and the support center.
Skip the two quarters.
Send us your current account structure and what you want it to become. We will walk your platform engineers through the design, the trade-offs and what a deployment would cost.