aws · landing-zone · multi-account
By Shayan Ghasemnezhad3min read
A single AWS account works until it does not. The minimal multi-account structure that protects production without adding overhead.
Most startups begin with a single AWS account. It is fast, simple, and nobody needs to think about account structure when there are three engineers and one environment. Then the team grows, staging and production share the same account, someone accidentally deletes a production S3 bucket while cleaning up staging, and the conversation about multi-account structure happens six months too late.
A single account means a single blast radius. IAM policies are the only barrier between a junior developer’s credentials and production data. Service limits are shared across environments—a load test in staging can exhaust API rate limits that production depends on. Billing is a single invoice with no attribution. And when you eventually need to separate accounts for compliance (SOC 2, GDPR, a customer security questionnaire), the migration is painful.
You do not need AWS Control Tower or a 12-account structure from day one. Start with four accounts:
This structure takes an afternoon to set up and prevents the most common single-account failures: accidental cross-environment access, shared service limits, and billing opacity.
SCPs are the guardrails at the organisation level. They restrict what any principal in a member account can do, regardless of their IAM permissions. Start with a deny-list approach: block the actions that are never acceptable in production.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyRootUser",
"Effect": "Deny"
aws · cloud-cost
Cloud spend scales with product success—until it scales faster. A practical framework for cost visibility, accountability, and control.
Use AWS IAM Identity Center (formerly SSO) from day one. Engineers authenticate once and assume roles in the appropriate account. No long-lived access keys. No shared credentials. Map permission sets to job functions: Developer gets broad access in staging and read-only in production. Operator gets deployment permissions in production. Administrator is restricted to the security team and requires MFA.
Keep networking simple at this stage. Each account gets its own VPC with non-overlapping CIDR ranges. If staging needs to talk to production (for data replication or shared services), use VPC peering or Transit Gateway. Do not share a VPC across accounts—it defeats the purpose of account-level isolation.
Set up multi-account when any of these become true: you have more than five engineers with AWS access, you are preparing for a compliance audit, or you have experienced a staging-production accident. The cost of delay is not the migration itself—it is the incident that forces the migration under pressure.
Over-engineering the landing zone is as costly as under-engineering it. Teams that deploy Control Tower with 15 accounts for a 10-person startup spend more time managing the structure than building product. Start with four accounts. Add more when a specific need arises—a shared-services account for CI/CD, a data account for analytics, a sandbox account for experimentation.
The other common failure: setting up multi-account but not using SCPs. Without guardrails, account separation is cosmetic. An engineer with AdministratorAccess in the production account can still do everything a single-account setup allows. The accounts provide the boundaries; SCPs enforce them.
The best time to set up multi-account was before your first production deployment. The second-best time is now. Four accounts, basic SCPs, IAM Identity Center. An afternoon of work that saves months of cleanup later.