One account for everything
Production, staging and one-off experiments sat side by side, told apart only by naming convention.
Platform baseline
A founder-managed AWS account, turned into a platform the team could inherit.
Most of the estate had been created by hand in the console, by whoever was free at the time. It worked. Nobody could say why it was shaped the way it was, or change it safely without that person in the room.
← Some of our past work · anonymised prior delivery, no client named
Stack
AWS OrganizationsIAM Identity CenterTerraformGitHub ActionsAWS CloudTrailAmazon RDS
Rough timeline
| Phase | Typical duration |
|---|---|
| Estate mapping and account design | 1–2 weeks |
| Core resources into Terraform, pipeline built | 3–5 weeks |
| Runbooks, ownership docs, handover | 1 week |
The challenge
One account held everything, and one person held the account.
The company was past the point where a single AWS account and a single memory could safely hold production. Nobody had decided that on purpose — it was just how the estate had grown.
The console was the source of truth
Nobody could say with confidence what a resource’s configuration was without opening it and looking.
One person carried the estate in their head
The founder was still the only person who could safely make an infrastructure change, so every change waited for them.
What we found
No boundary between environments, and no record of how either had changed.
No account boundary between environments
A mistake in staging could reach production, because they were the same account with the same IAM.
IAM had grown by addition, never subtraction
Permissions granted for a task months earlier that nobody had thought to remove.
CloudTrail was evidence stored with the crime scene
Default retention, in the same account it was meant to be the record of — useful for debugging, thin as an incident record.
What InfraEdge changed
A multi-account structure, core resources in Terraform, and a pipeline with a human gate.
The shape of the fix is unremarkable, which is the point. The work was deciding what belonged in code, in a separate account, or in a runbook — and holding that line.
| Change | What it did |
|---|---|
| Multi-account structure | Separate AWS accounts for production and non-production under AWS Organizations, joined by IAM Identity Center for a single sign-in. |
| Core resources into Terraform | VPC, RDS, S3 and the IAM roles the application depends on described as code and imported into state, so a change is a diff rather than a click. |
| GitHub Actions with approval gates | Plans run automatically on every pull request. Applying to production requires a named environment reviewer. |
| Centralised logging | An organization CloudTrail trail delivering into a separate log-archive account, so an incident’s evidence does not depend on the account under investigation being intact. |
| Ownership documented | Every resource and account has a named owner and a runbook, so "who owns this" no longer requires asking the founder. |
Outcome
A reviewer among several, not the only person who could approve a change.
By the end of the engagement the founder was one reviewer on production changes, not a bottleneck on every one of them.
What is left behind is a repository a new engineer can read on day one: the accounts, the modules, the pipeline and the reasoning, all in one place. For a team growing past the point one person can hold, InfraEdge also helped scope the role and vet candidates for the platform-minded engineer who took account ownership on from here — with the Terraform, the pipeline and the runbooks as the starting point of the job, not a knowledge-transfer meeting on the way out.
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.