AWS Cloud Practitioner #23: AWS Organizations - Multi-Account Management

Sin Organizations:
- Account 1 (Production): Billing separado
- Account 2 (Development): Billing separado
- Account 3 (Testing): Billing separado
Each: Separate login, separate billing, separate management
 
Con Organizations:
- Organization (root)
  ├── Production Account
  ├── Development Account
  └── Testing Account
 
Benefits:
✅ Single bill (consolidated)
✅ Centralized management
✅ Volume discounts
✅ Policies aplicadas a multiple accounts

Root container para todos accounts:
 
Management Account (antes Master):
- Crea organization
- Invita/crea member accounts
- Full control sobre organization
- Paga consolidated bill
 
Member Accounts:
- Pertenecen a organization
- Pueden tener resources
- Subject a policies de organization

Logical containers para accounts:
 
Organization Root
├── OU: Production
│   ├── Account: Prod-US
│   └── Account: Prod-EU
├── OU: Development
│   ├── Account: Dev-Team1
│   └── Account: Dev-Team2
└── OU: Sandbox
    └── Account: Experimentation
 
Benefits:
- Group accounts por purpose
- Apply policies a OU level (inherited)
- Delegation (OU admin)

SCP vs. IAM:
 
IAM:
Define qué users/roles PUEDEN hacer dentro de account
 
SCP:
Define máximo qué account PUEDE hacer
Acts as guardrail
 
Example:
IAM da user AdministratorAccess
SCP niega EC2 termination
→ User NO puede terminar EC2 (SCP wins)
 
Rule: SCP limits max permissions
Even admin can't exceed SCP

// Example 1: Deny specific regions
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": ["us-east-1", "eu-west-1"]
      }
    }
  }]
}
// Only permite US-East-1 y EU-West-1
 
// Example 2: Deny root account usage
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringLike": {
        "aws:PrincipalArn": "arn:aws:iam::*:root"
      }
    }
  }]
}
// Blocks root user access (force IAM users)
 
// Example 3: Require MFA
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "BoolIfExists": {
        "aws:MultiFactorAuthPresent": "false"
      }
    }
  }]
}
// Actions require MFA

Organization Root (SCP1: Allow all except delete S3)
├── OU: Production (SCP2: Deny EC2 instance types > m5.large)
│   └── Account: Prod (IAM: AdministratorAccess)
 
Effective permissions en Prod Account:
= SCP1 ∩ SCP2 ∩ IAM policies
 
User en Prod puede:
✅ Launch m5.large EC2
❌ Launch m5.2xlarge EC2 (SCP2 denies)
❌ Delete S3 buckets (SCP1 denies)
 
All SCPs en hierarchy aplicados

Without consolidated billing:
Account 1: $500/month bill
Account 2: $300/month bill
Account 3: $200/month bill
Total: $1,000 en 3 separate bills
 
With consolidated billing:
Organization: $1,000/month en single bill
  - Account 1: $500
  - Account 2: $300
  - Account 3: $200
 
Management account paga todo

S3 tiered pricing:
0-50 TB: $0.023/GB
50-500 TB: $0.022/GB
>500 TB: $0.021/GB
 
Without consolidation:
Account 1: 30 TB × $0.023 = $690
Account 2: 40 TB × $0.023 = $920
Total: $1,610
 
With consolidation:
Total: 70 TB combined
First 50 TB: 50 × $0.023 = $1,150
Next 20 TB: 20 × $0.022 = $440
Total: $1,590
Savings: $20 (increases with more usage)
 
Benefits increase con más accounts y usage

Account A: Purchased 10 Reserved Instances (m5.large)
Account A usage: 7 instances
Unused: 3 instances
 
Without RI sharing:
3 RIs wasted (paid but not used)
 
With RI sharing (Organizations):
Account B: Launching 5 m5.large On-Demand
→ 3 automatically use Account A's unused RIs
→ Account B saves money
→ Account A's RIs fully utilized
 
Benefit: Maximize RI utilization across organization

1. Security isolation:
   Production ≠ Development
   Breach en dev NO afecta prod
 
2. Billing separation:
   Track costs por team/project
   Chargeback accurate
 
3. Compliance:
   Different accounts para different data classifications
   PCI data en separate account
 
4. Resource limits:
   Each account tiene own limits
   Organization = combined limits
 
5. Blast radius:
   Error en 1 account NO afecta otros

Organization
├── OU: Infrastructure
│   ├── Logging Account (CloudTrail, Config)
│   └── Security Account (GuardDuty, SecurityHub)
├── OU: Production
│   ├── Prod-WebApp
│   └── Prod-Database
├── OU: Development
│   ├── Dev-Team1
│   └── Dev-Team2
└── OU: Sandbox
    └── Experimentation (no production data)
 
SCPs:
- Infrastructure: Read-only para most teams
- Production: Strict controls, change approval
- Development: More permissive
- Sandbox: Very permissive, cost limits

1. Separate management account:
   ✅ Use ONLY para organization management
   ❌ NO deploy production workloads
   Reason: Security (management account compromise = all accounts)
 
2. Enable CloudTrail organization trail:
   Logs from ALL accounts → centralized bucket
   Comprehensive audit trail
 
3. Use SCPs as guardrails:
   Prevent accidental actions
   Example: Deny delete production RDS
 
4. Naming conventions:
   Accounts: prod-webapp-us, dev-team1
   OUs: Production, Development, Sandbox
 
5. Tagging strategy:
   Consistent tags across accounts
   Cost allocation, automation
 
6. Limit management account access:
   Only senior engineers
   MFA required
   Break-glass procedure
 
7. Regular SCP audits:
   Review and update
   Remove unnecessary restrictions

Control Tower provides:
✅ Pre-configured organization structure
✅ Guardrails (SCPs) predefined
✅ Account Factory (automated provisioning)
✅ Dashboard (compliance view)
 
Landing Zone:
Baseline environment con best practices
 
Guardrails:
- Preventive: SCPs (deny actions)
- Detective: Config rules (detect violations)
 
Use when:
Starting fresh multi-account setup
Want AWS best practices automated