Definition
- Multi-account strategy – structuring a company's cloud into many AWS accounts (dev, staging, prod, per-team, per-workload) for strong blast-radius isolation, security, and billing separation.
- AWS Organizations – ties accounts together for consolidated billing, volume discounts, and Service Control Policies (guardrails that cap what any account can do).
- IAM Identity Center (SSO) – single sign-on with role-based access into permitted accounts, ideally federated from the corporate identity provider.
- Service Control Policy (SCP) – organization-wide guardrail that sets the maximum permissions any account can have; even account administrators cannot override it.
- Management account – the root account of the organization that should hold almost no workloads and be tightly guarded.
Imagine National Bank of India kept all its money, customer records, training materials, and experiments in one single giant room with one door. A junior running an experiment could knock over the shelf holding real customer records. A multi-account strategy is having separate locked rooms -- a production vault, a staging practice vault, a development sandbox -- each with its own door and guard. Organizations is the head office that pays one combined bill and sets rules every room must follow. SSO is the single badge that opens only the specific rooms each employee is allowed into.
Understanding the Concepts
What is a multi-account strategy?
The core idea is that an AWS account is the strongest isolation boundary AWS provides. Resources in one account are, by default, completely separate from another account. Separating environments and workloads into their own accounts contains failures and breaches.
// Multi-account structure concept
package com.bank.infrastructure;
import java.util.List;
public class MultiAccountStructure {
public static final List<String> ACCOUNTS = List.of(
"Management (governance, billing, SCPs)",
"Log Archive (centralized CloudTrail and VPC Flow Logs)",
"Security Audit (GuardDuty, Security Hub)",
"Shared Services (DNS, CI/CD, container registry)",
"Development (engineers experiment freely)",
"Staging (mirrors production for testing)",
"Production (tightly locked down, real customers)"
);
public static void main(String[] args) {
System.out.println("NBI Multi-Account Structure:");
ACCOUNTS.forEach(a -> System.out.println(" - " + a));
}
}
What is AWS Organizations?
Organizations is the governance layer that makes many accounts manageable. It gives consolidated billing, so all accounts roll up into one invoice with volume discounts. It provides Service Control Policies (SCPs), which are organization-wide guardrails that set the maximum permissions any account can have. Organizations also groups accounts into Organizational Units (OUs) and applies policies per group.
// Service Control Policy: deny disabling audit logging
package com.bank.infrastructure;
public class ScpExample {
public static String denyDisableAudit() {
return """
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail"],
"Resource": "*"
}]
}
""";
}
public static void main(String[] args) {
System.out.println("SCP: Deny disabling CloudTrail in ANY account");
System.out.println("Even account administrators cannot override this.");
System.out.println(denyDisableAudit());
}
}
What is IAM Identity Center (SSO)?
Instead of separate IAM users in every account, users sign in once through IAM Identity Center and assume roles into the accounts and permission sets they are entitled to. This centralizes who can access what, makes onboarding and offboarding a single action, and avoids long-lived credentials scattered across accounts.
// SSO access model
package com.bank.infrastructure;
public class SsoAccessModel {
public static void main(String[] args) {
System.out.println("Developer Rajesh signs in once via SSO.");
System.out.println("Available roles:");
System.out.println(" - Development: PowerUser (full access to experiment)");
System.out.println(" - Staging: Developer (read-write for testing)");
System.out.println(" - Production: NO ACCESS (cannot even see production)");
System.out.println();
System.out.println("Offboarding: disable SSO user -> all access revoked instantly.");
}
}
Why is one big account a bad idea?
Concretely, there are four problems with a single account. No blast-radius isolation: a runaway script or compromised credential in development can delete or read production resources. Shared service quotas: one team's load test can exhaust capacity for everyone. Muddy cost attribution: separating spend relies entirely on tagging discipline. And a single breach exposes everything.
// Risks of a single account
package com.bank.infrastructure;
import java.util.List;
public class SingleAccountRisks {
public static final List<String> RISKS = List.of(
"1. No isolation: dev mistake can destroy production data",
"2. Shared quotas: one team's load test starves everyone",
"3. Muddy costs: no clean per-environment or per-team billing",
"4. Security: one breach = total exposure of all resources",
"5. Compliance: harder to prove environment separation to auditors"
);
public static void main(String[] args) {
System.out.println("Risks of one big account:");
RISKS.forEach(System.out::println);
}
}
What are Service Control Policies and how do they work?
SCPs set the maximum permissions any account in the organization can have. They do not grant permissions; they cap what IAM policies in the account can do. For example, an SCP that denies creating resources outside approved Regions prevents any team from accidentally deploying in the wrong Region, even if their IAM policy allows it.
// SCP: restrict to approved Regions only
package com.bank.infrastructure;
public class RegionRestrictionScp {
public static String restrictToApprovedRegions() {
return """
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["ap-south-1", "us-east-1"]
}
}
}]
}
""";
}
}
What is the role of the management account?
The management account is the root of the organization. It controls billing, creates accounts, and applies SCPs. Because of its power, it should hold almost no workloads and be guarded tightly. Access should be restricted to a very small number of administrators, and it should be protected with MFA.
// Management account best practices
package com.bank.infrastructure;
public class ManagementAccountBestPractices {
public static void main(String[] args) {
System.out.println("Management Account Rules:");
System.out.println(" 1. No workloads (no applications, no databases)");
System.out.println(" 2. Minimal users (only org admins)");
System.out.println(" 3. Root user MFA enabled and rarely used");
System.out.println(" 4. CloudTrail enabled for all API calls");
System.out.println(" 5. SCPs do NOT apply to the management account itself");
System.out.println(" (so keep it clean and guarded)");
}
}
What is AWS Control Tower?
AWS Control Tower automates setting up a multi-account landing zone. It creates the management account, a log-archive account, and a security/audit account, applies baseline guardrails (SCPs), sets up CloudTrail and Config across all accounts, and provides a dashboard for governance. This saves weeks of manual setup.
// Control Tower landing zone
package com.bank.infrastructure;
public class ControlTowerSetup {
public static void main(String[] args) {
System.out.println("AWS Control Tower creates:");
System.out.println(" 1. Management Account (governance)");
System.out.println(" 2. Log Archive Account (centralized logs)");
System.out.println(" 3. Audit Account (security tooling)");
System.out.println(" 4. Baseline guardrails (SCPs)");
System.out.println(" 5. CloudTrail + Config in all accounts");
System.out.println(" 6. Account factory for creating new accounts");
}
}
What should a senior engineer know?
The multi-account model is the AWS-recommended landing zone pattern. The trade-off of many accounts is more structure to manage, which Organizations, SSO, and infrastructure-as-code handle. Senior engineers know that SCPs do not apply to the management account itself, which is why it must have almost no workloads. They also know that cross-account access uses IAM roles and resource policies, not shared credentials, and that centralized logging (CloudTrail, VPC Flow Logs) should go to a dedicated log-archive account that nobody except the security team can write to.
Visual Overview
Multi-Account Landing Zone Architecture ┌──────────────────────────────────────────────────────────┐ │ AWS Organizations │ │ (consolidated billing, SCPs) │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Management │ │ Log Archive │ │ Security │ │ │ │ (governance) │ │ (CloudTrail, │ │ (GuardDuty, │ │ │ │ NO workloads │ │ VPC Flow │ │ Sec Hub) │ │ │ │ │ │ Logs) │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Development │ │ Staging │ │ Production │ │ │ │ │ │ │ │ │ │ │ │ Experiment │ │ Mirror of │ │ LOCKED DOWN │ │ │ │ freely │ │ production │ │ Real traffic │ │ │ │ │ │ │ │ │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ SCPs: No CloudTrail disable, Region restrictions │ │ SSO: One login, role-based access per account │ │ Blast radius: dev cannot touch prod (hard wall) │ └──────────────────────────────────────────────────────────┘ vs. One Big Account: ┌──────────────────────────────────────────────────────────┐ │ EVERYTHING in one account: dev + staging + prod │ │ One mistake = blast radius covers EVERYTHING │ │ Shared quotas, muddy costs, one breach = total exposure │ └──────────────────────────────────────────────────────────┘
Key Takeaway
A multi-account AWS strategy structures an organization's cloud into many separate AWS accounts, because an account is the strongest isolation boundary AWS provides. The standard approach is at least separate accounts for development, staging, and production, plus dedicated accounts for logging, security, and shared services. The point is blast-radius isolation: because accounts are hard walls by default, a runaway script or leaked credential in development simply cannot reach the production ledger.
AWS Organizations is the governance layer that makes many accounts manageable. It gives consolidated billing with volume discounts, Service Control Policies that cap what any account can do (even administrators cannot override them), and Organizational Units for grouping and policy inheritance. IAM Identity Center provides single sign-on so users sign in once and assume only the roles and accounts they are entitled to.
Putting everything in one big account is a bad idea for concrete reasons: no blast-radius isolation, shared service quotas, muddy cost attribution, and a single breach exposing everything.
At National Bank of India I used a multi-account landing zone. Development, staging, and production were separate accounts. Organizations gave us consolidated billing and SCPs that made it impossible for any account to disable audit logging. SSO gave engineers access only to the accounts they needed. The management account held no workloads and was guarded tightly.
Remember one sentence: use separate AWS accounts for blast-radius isolation, govern them centrally with Organizations and SCPs, and access them through SSO -- because one big account gives a mistake or breach unlimited reach across everything.
---