TECH **AWS Multi-Account Strategies: A Zero-Fluff, Hands-On Guide**

AWS Multi-Account Strategies: A Zero-Fluff, Hands-On Guide

(AWS Organizations, SCPs, Control Tower for AWS SAA & Real-World Deployments)

1. What This Is & Why It Matters

You’re a cloud engineer at a mid-sized company. Your CISO just handed you a mandate:

"We need to isolate dev, staging, and prod environments. Finance wants cost visibility per team. And by the way, no one should accidentally delete the production database."

This is where multi-account strategies come in.
AWS Organizations, Service Control Policies (SCPs), and Control Tower are the tools that let you: - Enforce security guardrails (e.g., "No public S3 buckets in prod").
- Isolate workloads (e.g., "Dev team can’t touch prod resources").
- Track costs per team/department (e.g., "Marketing’s ad spend is $X this month").
- Automate compliance (e.g., "All accounts must enable AWS Config").

What breaks if you ignore this?
- A rogue IAM user deletes a critical S3 bucket (no SCPs to block s3:DeleteBucket).
- Finance can’t allocate costs—your CFO sees one giant AWS bill.
- A misconfigured Lambda in dev accidentally triggers a prod API (no account isolation).
- Auditors fail your SOC 2 audit because you can’t prove least-privilege access.

Superpower you gain:
You can scale securely without micromanaging every account. Think of it like a corporate credit card system: - AWS Organizations = The corporate card program (centralized billing, rules).
- SCPs = Spending limits ("No alcohol purchases; max $10K/month").
- Control Tower = The automated expense report tool (pre-approved templates, alerts).

2. Core Concepts & Components

? AWS Organizations

• What it is: A service to centrally manage multiple AWS accounts (like a parent company managing subsidiaries).
• Production insight: Without Organizations, you’re stuck managing accounts manually (e.g., sharing IAM users, no consolidated billing).
• Key features:
• Consolidated billing (one bill for all accounts).
• Hierarchical structure (Organization Units, or OUs, like folders for accounts).
• SCPs (Service Control Policies—like IAM policies but for accounts).

? Organization Units (OUs)

• What it is: A container for accounts (e.g., Prod, Dev, Sandbox).
• Production insight: Use OUs to group accounts by function (e.g., "All security accounts go in the Security OU").
• Example structure:
  Root ├── Prod (OU) │ ├── Prod-App1 (Account) │ └── Prod-DB (Account) ├── Dev (OU) │ ├── Dev-App1 (Account) │ └── Dev-DB (Account) └── Security (OU)
└── Audit (Account)

? Service Control Policies (SCPs)

• What it is: Deny rules that apply to all IAM users/roles in an account or OU (even the root user!).
• Production insight: SCPs are not permissions—they’re guardrails. Think of them like a bouncer at a club:
• IAM policies = "Who gets in" (allow list).
• SCPs = "What’s not allowed inside" (deny list).
• Example: Block public S3 buckets in prod: json {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "s3:PutBucketPublicAccessBlock",
"Resource": "*",
"Condition": {
"Bool": { "s3:BlockPublicAcls": false }
}
}
] }

? AWS Control Tower

• What it is: A managed service to automate multi-account setups (like a "multi-account factory").
• Production insight: Control Tower saves weeks of manual work by:
• Creating a landing zone (pre-configured OUs, SCPs, and accounts).
• Enforcing guardrails (e.g., "All accounts must enable AWS CloudTrail").
• Providing a dashboard to monitor compliance.
• Key components:
• Landing zone (the initial multi-account setup).
• Guardrails (pre-built SCPs and Config rules).
• Account Factory (automated account provisioning).

? AWS Single Sign-On (SSO)

• What it is: A centralized identity provider for all AWS accounts (e.g., log in once to access dev, prod, and security accounts).
• Production insight: Without SSO, users share IAM credentials (security nightmare) or manage separate logins (UX nightmare).
• How it works:
• Connect to Active Directory, Okta, or AWS SSO.
• Assign permission sets (e.g., "DevTeam" gets ReadOnly in dev accounts).

? AWS Config & AWS CloudTrail

• What they are:
• AWS Config = Tracks resource changes (e.g., "Who modified this security group?").
• AWS CloudTrail = Tracks API calls (e.g., "Who deleted this S3 bucket?").
• Production insight: Enable both in every account—they’re your audit logs for compliance (SOC 2, HIPAA, etc.).

3. Step-by-Step: Deploy a Multi-Account Setup with Control Tower

Prerequisites

• An AWS account (your "management account").
• Admin IAM permissions (or root access).
• No existing AWS Organizations (Control Tower will create one).

Step 1: Enable AWS Control Tower

1. Go to the AWS Control Tower console.
2. Click "Set up landing zone".
3. Select "Create a new landing zone".
4. Configure:
5. Home Region: us-east-1 (or your preferred region).
6. Governed Regions: Select all regions you’ll use (e.g., us-east-1, eu-west-1).
7. Foundational OUs: Keep default (Security, Sandbox).
8. Additional OUs: Add Prod and Dev.
9. Click "Set up landing zone" (takes ~30 minutes).

Step 2: Verify the Landing Zone

1. After setup completes, go to the Control Tower dashboard.
2. Check:
3. 3 accounts created (Audit, Log Archive, and your management account).
4. 2 OUs created (Security, Sandbox).
5. Guardrails enabled (e.g., "Disallow public read access to S3 buckets").

Step 3: Create a New Account (Account Factory)

1. In the Control Tower console, go to "Account Factory".
2. Click "Enroll account".
3. Fill in:
4. Account name: Dev-App1
5. Email: [email protected] (must be unique).
6. OU: Dev
7. SSO email: [email protected]
8. Click "Enroll account" (takes ~5 minutes).

Step 4: Apply an SCP to the Prod OU

1. Go to AWS Organizations > Policies > Service Control Policies.
2. Click "Create policy".
3. Name: Deny-Public-S3-Prod
4. Paste this JSON (blocks public S3 buckets):
   json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "s3:PutBucketPublicAccessBlock",
"Resource": "*",
"Condition": {
"Bool": { "s3:BlockPublicAcls": false }
}
}
]
}
5. Click "Create policy".
6. Go to the Prod OU > Policies > Attach SCP.
7. Select Deny-Public-S3-Prod and click "Attach policy".

Step 5: Test the SCP

1. Log in to the Prod-App1 account (via AWS SSO).
2. Try to create a public S3 bucket:
   bash
aws s3api create-bucket --bucket prod-app1-test-bucket --region us-east-1
aws s3api put-public-access-block --bucket prod-app1-test-bucket \
--public-access-block-configuration "BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false"
3. Expected result: The command fails with:
   An error occurred (AccessDenied) when calling the PutPublicAccessBlock operation: Access denied
4. Why? The SCP blocked the action.

Step 6: Set Up AWS SSO

1. Go to AWS SSO > Settings.
2. Click "Enable AWS SSO".
3. Under "Identity source", select "AWS SSO" (or connect to Active Directory/Okta).
4. Go to "Permission sets" > "Create permission set".
5. Name: DevTeam-ReadOnly
6. Select "Read-only access" and click "Create".
7. Go to "AWS accounts" > Select the Dev-App1 account.
8. Click "Assign users" > Add your email (or a test user).
9. Select the DevTeam-ReadOnly permission set and click "Finish".

Step 7: Verify SSO Access

1. Go to the AWS SSO user portal (URL provided in the SSO console).
2. Log in with your email.
3. You should see the Dev-App1 account with read-only access.

4. ? Production-Ready Best Practices

? Security

• Least privilege SCPs: Start with deny-all SCPs, then whitelist what’s needed.
  json {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*"
}
] }
• Enable AWS Config & CloudTrail in all accounts (use Control Tower guardrails).
• Rotate IAM keys every 90 days (use AWS IAM Access Analyzer to find unused keys).
• Use AWS SSO (never share IAM credentials across accounts).

? Cost Optimization

• Tag all resources (e.g., Environment=Prod, Team=Marketing).
• Use AWS Cost Explorer to track spending per account/OU.
• Set billing alarms in each account (e.g., "Alert if >$1K/month").
• Use AWS Budgets to cap spending (e.g., "Dev accounts max $500/month").

? Reliability & Maintainability

• Standardize account naming (e.g., Prod-App1, Dev-DB).
• Use Infrastructure as Code (IaC) (e.g., Terraform, AWS CDK) to deploy accounts.
• Automate account provisioning (use Control Tower Account Factory or AWS Service Catalog).
• Document SCPs (e.g., "SCP Deny-Public-S3-Prod blocks public S3 buckets in prod").

? Observability

• Enable AWS CloudTrail in all accounts (log to a central S3 bucket in the Log Archive account).
• Use AWS Config to track compliance (e.g., "Are all S3 buckets encrypted?").
• Set up Amazon CloudWatch alarms for critical events (e.g., "Root login detected").
• Use AWS Security Hub to aggregate security findings across accounts.

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus (AWS SAA)

Typical Question Patterns

1. SCP vs. IAM Policy:
2. "A user in Account A can’t launch an EC2 instance, even though their IAM policy allows it. Why?"
   • Answer: An SCP in the account’s OU is blocking ec2:RunInstances.

3. Trap: SCPs override IAM policies (deny > allow).

4. Control Tower vs. Manual Setup:

5. "You need to deploy 50 accounts with consistent security policies. What’s the fastest way?"
   • Answer: Use AWS Control Tower (automates account creation + guardrails).

6. Trap: "Use AWS Organizations alone" is wrong—Control Tower adds automation.

7. Cost Allocation:

8. "How do you track costs per department?"
   • Answer: Use AWS Organizations + Cost Allocation Tags.

9. Trap: "Use AWS Budgets" is wrong—Budgets cap spending, but don’t allocate costs.

10. Guardrails:

11. "How do you enforce that all S3 buckets are encrypted?"
    • Answer: Use a Control Tower guardrail (or an SCP + AWS Config rule).
12. Trap: "Use IAM policies" is wrong—IAM policies apply to users, not resources.

Key ⚠️ Trap Distinctions

7. ? Hands-On Challenge (with Solution)

Challenge:

"You’re a cloud engineer. Your CISO demands that no one can disable AWS CloudTrail in any account. How do you enforce this?"

Solution:

1. Create an SCP named Deny-Disable-CloudTrail:
   json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "cloudtrail:StopLogging",
"Resource": "*"
}
]
}
2. Attach it to the Root OU (applies to all accounts).
3. Why it works: SCPs override all IAM permissions, so even the root user can’t disable CloudTrail.

8. ? Rapid-Reference Crib Sheet

AWS Organizations CLI Commands

# Create an organization
aws organizations create-organization --feature-set ALL

# Create an OU
aws organizations create-organizational-unit --parent-id r-xxxx --name Prod

# Create an account
aws organizations create-account --email [email protected] --account-name Prod-App1

# Attach an SCP to an OU
aws organizations attach-policy --policy-id p-xxxx --target-id ou-xxxx-xxxxxxxx

SCP Examples

Control Tower Guardrails (Pre-Built SCPs)

⚠️ Exam Traps

• SCPs don’t grant permissions (only deny).
• Control Tower requires AWS Organizations (it’s not a standalone service).
• Default SCPs allow everything (you must explicitly deny actions).
• SCPs apply to all IAM users/roles (including root).

9. ? Where to Go Next

1. AWS Organizations User Guide (Official docs).
2. AWS Control Tower Workshop (Hands-on lab).
3. AWS Multi-Account Security Reference Architecture (Best practices).
4. AWS Well-Architected Multi-Account Strategy (Security pillar).