No repeatable way to stand up an environment
A new title, or a new region for an existing one, meant someone hand-building an account from memory, with guardrails included only if that person remembered them.
Every new title meant a new set of AWS accounts, and non-production already outnumbered production by a wide margin before the estate had a repeatable shape to grow into. The landing zone had to answer two questions from day one: how fast can we vend an account, and does the network hold when a launch sends a spike of concurrent players into a region that has never carried load like that before.
← Some of our past work · anonymised prior delivery, no client named
Stack
Rough timeline
| Phase | Typical duration |
|---|---|
| Landing zone design — OUs, network and IP plan | 2–3 weeks |
| Control Tower and Account Factory build-out, guardrails | 3–5 weeks |
| Workload accounts onboarded, phased by title and region | ongoing as new titles land |
The company was not short of AWS experience — it was short of a repeatable shape. Every studio team had its own accounts, its own conventions, and its own idea of what production-ready meant.
A new title, or a new region for an existing one, meant someone hand-building an account from memory, with guardrails included only if that person remembered them.
Build, QA and per-feature test accounts had multiplied far faster than the live accounts they eventually shipped to, with no factory-shaped way to manage that many.
A title that launched in one region was going to need a second and a third as its player base grew, and the network had not been planned with that in mind.
None of this was visible until we asked what a shared network, or a second region, would actually require.
Several non-production accounts had been given overlapping ranges, which cost nothing while every account stood alone and would have blocked a shared network the moment they did not.
CloudTrail existed everywhere, but reconstructing activity across a single title’s accounts meant asking each account for its own answer, in whatever region it happened to run in.
Some accounts blocked risky configurations outright; none of them would have flagged it if a resource had already drifted into one before the guardrail existed.
Compute and networking limits nobody had reviewed, because nothing had yet asked them to carry the concurrency a launch would bring.
The honest trade-off first: a fully custom landing zone would have allowed more control over the account and OU shape. Control Tower gave some of that up for a maintained baseline and an account factory that did not have to be built from nothing — the right trade for a company about to vend more accounts than it could hand-build.
| Change | What it did |
|---|---|
| Control Tower adopted, Account Factory for Terraform layered on top | Control Tower supplied the baseline — Log Archive and Audit accounts, and the guardrail catalogue. Account Factory for Terraform sat on top, so a new account request is a pull request reviewed like any other change, not a console workflow someone has to remember correctly. |
| OUs built around how accounts are actually used | A Security OU for Log Archive and Audit, an Infrastructure OU for shared tooling, a Workloads OU split into production and non-production per title, and a Sandbox OU for build and experimentation accounts with tighter default limits. |
| Service control policies as the org-wide ceiling | SCPs deny the actions no account should ever be able to take, regardless of who is signed in — leaving the AWS Organization, disabling CloudTrail, using a region outside the approved footprint. They apply even to an account’s own administrators. |
| Permission boundaries where a team needed to self-serve | Where a build team needed to create its own CI roles without waiting on a ticket, a permission boundary capped what any role they created could ever be granted — a per-principal ceiling for delegation, not an org-wide prohibition. |
| Network topology planned ahead of the accounts that would need it | A Transit Gateway per region, spoke VPCs attached per workload account, and centralised egress through a dedicated account — outbound traffic inspectable in one place rather than through as many NAT gateways as there are accounts. |
| IP address plan reserved before it was needed | CIDR ranges allocated per account and per region up front, so a title’s second region does not mean renumbering its first. |
| Centralised logging | An organization CloudTrail trail delivering into the Log Archive account, and an AWS Config aggregator in the Audit account collecting configuration from every account and region as titles came online. |
| IAM Identity Center for people, OIDC for the build fleets | Human access moved onto IAM Identity Center with permission sets scoped per OU, replacing long-lived IAM users. Build pipelines authenticate through a per-account OIDC trust rather than a stored access key. |
| Guardrails, preventive and detective | Preventive SCPs stop the actions that should never happen. Detective guardrails — AWS Config rules and conformance packs — catch what an SCP would have had to be too strict to prevent, and route the finding to a named owner rather than the next audit. |
The test that mattered was not the design document. It was standing up a new title’s accounts through the factory and watching the guardrails apply themselves.
Vending an environment no longer depends on who is free that week or what they remember to configure — every account arrives in the right OU, under the right SCPs, with logging and Config aggregation already wired in. The network and IP plan were sized for the regions the roadmap named, not just the one already live, so the next region is an account request rather than a renumbering project.
Twenty minutes, no charge. We work out what would actually help — which is sometimes us and sometimes not. Nothing is priced on the call; if there is work worth doing, a written scope and a price reach you within 24 hours.