Assess, fix, keep it that way

EdgeReadyEdgeResolveEdgeAssure

For investors

EdgeSignalAll services
How it works Find your path Case studies Security About What we take on Book a 20-minute triage call
Landing zone

An AWS landing zone for a gaming company, built for launch spikes and a non-production estate far bigger than production.

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

AWS Control TowerAccount Factory for TerraformAWS OrganizationsService control policiesAWS Transit GatewayIAM Identity CenterAWS ConfigAWS CloudTrail

Rough timeline

PhaseTypical duration
Landing zone design — OUs, network and IP plan2–3 weeks
Control Tower and Account Factory build-out, guardrails3–5 weeks
Workload accounts onboarded, phased by title and regionongoing as new titles land
The challenge

A new title meant a new set of accounts, built however whoever was free that week built them.

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.

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.

Non-production already dwarfed production

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.

Player latency meant more regions than the estate was built for

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.

What we found

An IP plan that only worked because nothing had needed to talk to anything else yet.

None of this was visible until we asked what a shared network, or a second region, would actually require.

CIDR ranges were assigned per account, not planned

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.

Logging was per account, not per estate

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.

Guardrails were preventive only, and inconsistent between accounts

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.

Default service quotas sat unchecked in the accounts closest to launch

Compute and networking limits nobody had reviewed, because nothing had yet asked them to carry the concurrency a launch would bring.

What InfraEdge changed

Control Tower for the baseline, Account Factory for the vending, and the network planned before it was needed.

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.

ChangeWhat it did
Control Tower adopted, Account Factory for Terraform layered on topControl 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 usedA 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 ceilingSCPs 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-serveWhere 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 itA 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 neededCIDR ranges allocated per account and per region up front, so a title’s second region does not mean renumbering its first.
Centralised loggingAn 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 fleetsHuman 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 detectivePreventive 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.
Outcome

A new account is a pull request now, not a console session someone has to get right from memory.

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.

Book a 20-minute triage call

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.