How a 120-Engineer SaaS Company Migrated from One AWS Account to a Multi-Account Landing Zone
A B2B SaaS company collapsed security blast radius and achieved compliance by adopting AWS Organizations, Control Tower, and SCPs — learning hard lessons about OU design and SCP ordering along the way.
Infrastructure · intermediate · 12 min read · 2314 words · By Sandip Das · Published
What this covers
- The Situation
- The Problem
- Constraints
- Options Considered
- The Solution
- Implementation
- Results
- What Went Wrong Along the Way
- Lessons Learned
- Apply It Yourself
Key numbers
| Metric | Before | After |
|---|---|---|
| IAM users with long-lived access keys | 340 | 0 |
| Untagged AWS spend | 35% | 3% |
| Mean time to detect a misconfiguration | ~4 days | 11 minutes |
| SOC 2 audit blockers | 14 | 0 |
| Time to provision a new AWS account | 2-3 days | 22 minutes |
Key components
- AWS Control Tower — Bootstraps the landing zone, provisions Log Archive and Audit accounts, and deploys baseline guardrails across all enrolled accounts.
- AWS Organizations SCPs — Preventive guardrails that enforce hard boundaries (no root user actions, no CloudTrail disabling) at the OU level, applying to every account beneath them.
- Account Factory for Terraform (AFT) — GitOps pipeline that provisions new AWS accounts on demand via Terraform, applying baseline customisations consistently and reproducibly.
- IAM Identity Center — Replaces all IAM users with federated, short-lived sessions; engineers authenticate once and assume roles in any account without long-lived credentials.
- Centralised Networking Account — Owns the Transit Gateway and Route 53 Resolver, preventing CIDR conflicts and giving the platform team a single pane for cross-account connectivity.
- Log Archive Account with S3 Object Lock — Provides an immutable, tamper-proof audit trail that satisfies SOC 2 log retention requirements even if any other account is compromised.
The Situation
The organisation is a 120-engineer B2B SaaS company selling workflow-automation software to mid-market financial services firms. Their platform runs entirely on AWS: roughly 400 EC2 instances, 60-odd RDS databases, a handful of EKS clusters, and several hundred Lambda functions. The engineering team is split across a platform squad (8 engineers), three product squads, a data squad, and a security engineer who joined 14 months before the migration. Everything — production, staging, development, CI/CD tooling, and the data warehouse — lived in a single AWS account, account ID ending in …4471, which the team had been calling "the monoaccount" with increasing dread.
The rest of this case study — the trade-offs, the scaling numbers and the build prompt — is available to LearnXops members. Create an account or see membership.
Topics: aws, multi-account, control-tower, organizations, scp, landing-zone
Related case studies
- How 37signals Saved $10M by Leaving AWS for Owned Hardware
- How a B2B SaaS Team Cut CI and Batch Costs by 70% Using Spot Instances Without Losing Jobs
- How a B2B SaaS Team Cut Their AWS Bill by 40% with Rightsizing, Graviton, Savings Plans and S3 Lifecycle Policies
- How a B2B SaaS Team Split a 4,000-Resource Terraform Monolith Into Modules Without Downtime
- Lift-and-Shift to AWS First, Then Modernise: How a B2B SaaS Company Escaped the Data Centre
- The 2017 Amazon S3 Outage: One Mistyped Command and the Cost of a Slow Restart