🏗️ Account & Landing Zone

Level: Foundation Solves: Thiết kế multi-account strategy và landing zone cho enterprise AWS environment

🎯 Mục tiêu (Outcomes)

Sau khi áp dụng kiến thức trong trang này, bạn sẽ có khả năng:

Thiết kế OU Structure phù hợp cho tổ chức từ 10 đến 1000+ accounts
Triển khai Control Tower với guardrails đáp ứng yêu cầu compliance (PCI-DSS, HIPAA, SOX)
Xây dựng Account Vending tự động hóa để provision accounts trong vài phút thay vì vài ngày
Áp dụng SCPs như defense-in-depth layer ngăn chặn privilege escalation
Thiết lập baseline security nhất quán cho mọi account mới
Quản lý blast radius thông qua account isolation strategy

✅ Khi nào dùng

Áp dụng Multi-Account Strategy khi:

Tình huống	Lý do	Ưu tiên
Tổ chức có nhiều team/BU độc lập	Mỗi team cần autonomy về resources và budget	🔴 Bắt buộc
Yêu cầu compliance (PCI, HIPAA, SOX)	Cần hard boundary giữa production và non-production	🔴 Bắt buộc
Production workloads	Giới hạn blast radius khi có incident	🔴 Bắt buộc
Cost allocation phức tạp	Cần chargeback/showback theo team hoặc project	🟡 Khuyến nghị
Service limits bị hit	Tách accounts để có limits riêng	🟡 Khuyến nghị

❌ Khi nào KHÔNG dùng

Cân nhắc kỹ trước khi áp dụng Multi-Account trong các trường hợp:

Tình huống	Vấn đề	Thay thế
Startup < 10 người, 1 product	Overhead quản lý accounts lớn hơn lợi ích	Dùng 2-3 accounts (prod/nonprod/shared)
POC hoặc hackathon	Time-to-value quan trọng hơn isolation	Single account với tagging
Team chưa có kinh nghiệm AWS	Complexity overwhelm team	Bắt đầu đơn giản, evolve dần
Không có automation	Manual account management không scale	Xây automation trước khi scale accounts

⚠️ Cảnh báo từ Raizo

"Tôi đã thấy nhiều org tạo 50+ accounts mà không có automation. Kết quả? 6 tháng sau, configuration drift khắp nơi, không ai biết account nào làm gì, và security baseline không nhất quán. Multi-account chỉ work khi có Account Factory automation."

Tại sao cần Multi-Account Strategy?

💡 Giáo sư Tom

Single account cho production là anti-pattern lớn nhất trong enterprise AWS. Blast radius không giới hạn, billing nightmare, và security boundaries không tồn tại. Multi-account là foundation của mọi enterprise deployment.

Vấn đề với Single Account

┌─────────────────────────────────────────────────────────────────┐
│                    SINGLE ACCOUNT CHAOS                         │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │                    AWS Account                          │    │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐       │    │
│  │  │   Dev   │ │  Test   │ │  Prod   │ │ Sandbox │       │    │
│  │  └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘       │    │
│  │       │           │           │           │             │    │
│  │       └───────────┴───────────┴───────────┘             │    │
│  │                       │                                 │    │
│  │              SHARED EVERYTHING:                         │    │
│  │              • IAM Users/Roles                          │    │
│  │              • Service Limits                           │    │
│  │              • Billing                                  │    │
│  │              • Security Boundaries                      │    │
│  └─────────────────────────────────────────────────────────┘    │
│                                                                 │
│  RISKS:                                                         │
│  ❌ Dev mistake affects Production                              │
│  ❌ Cannot isolate costs per environment                        │
│  ❌ Service limits shared across all workloads                  │
│  ❌ Compliance nightmare (PCI, HIPAA boundaries)                │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

AWS Organizations

Organizational Unit (OU) Structure

┌─────────────────────────────────────────────────────────────────┐
│                 RECOMMENDED OU STRUCTURE                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│                    ┌──────────────┐                             │
│                    │     Root     │                             │
│                    └──────┬───────┘                             │
│                           │                                     │
│     ┌─────────────────────┼─────────────────────┐               │
│     │                     │                     │               │
│     ▼                     ▼                     ▼               │
│ ┌────────┐          ┌──────────┐          ┌──────────┐          │
│ │Security│          │Infrastructure│      │Workloads │          │
│ └───┬────┘          └─────┬────┘          └────┬─────┘          │
│     │                     │                    │                │
│     ▼                     ▼                    ▼                │
│ • Log Archive        • Network             ┌───────────┐        │
│ • Security Tooling   • Shared Services     │    Dev    │        │
│ • Audit              • Backup              ├───────────┤        │
│                                            │   Test    │        │
│                                            ├───────────┤        │
│                                            │   Prod    │        │
│                                            └───────────┘        │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Service Control Policies (SCPs)

SCPs là guardrails ở organization level - chúng DENY actions ngay cả khi IAM policy ALLOW.

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    },
    {
      "Sid": "RequireIMDSv2",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotEquals": {
          "ec2:MetadataHttpTokens": "required"
        }
      }
    }
  ]
}

⚠️ SCP Best Practices

SCPs không grant permissions, chỉ restrict
Test SCPs trong sandbox OU trước khi apply production
Luôn có "break glass" procedure cho emergency access
Document mọi SCP với business justification

AWS Control Tower

Landing Zone Components

┌─────────────────────────────────────────────────────────────────┐
│                 CONTROL TOWER LANDING ZONE                      │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐    │
│  │                  Management Account                      │    │
│  │  • AWS Organizations                                     │    │
│  │  • Control Tower                                         │    │
│  │  • SSO/Identity Center                                   │    │
│  └─────────────────────────────────────────────────────────┘    │
│                           │                                     │
│           ┌───────────────┼───────────────┐                     │
│           ▼               ▼               ▼                     │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐              │
│  │ Log Archive │  │    Audit    │  │  Workload   │              │
│  │   Account   │  │   Account   │  │  Accounts   │              │
│  │             │  │             │  │             │              │
│  │ • CloudTrail│  │ • Config    │  │ • Dev       │              │
│  │ • Config    │  │ • Security  │  │ • Test      │              │
│  │ • VPC Flow  │  │   Hub       │  │ • Prod      │              │
│  └─────────────┘  └─────────────┘  └─────────────┘              │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Guardrails Categories

Category	Type	Example
Mandatory	Preventive	Disallow changes to CloudTrail configuration
Strongly Recommended	Preventive	Disallow public read access to S3 buckets
Elective	Detective	Detect whether MFA is enabled for root user

Account Factory

Account Factory tự động hóa việc tạo accounts với:

Pre-configured VPC
IAM roles cho cross-account access
CloudTrail và Config enabled
SSO integration

Account Vending Best Practices

Naming Convention

{org}-{env}-{workload}-{region}

Examples:
- acme-prod-payments-useast1
- acme-dev-analytics-euwest1
- acme-shared-network-global

Tagging Strategy

json

{
  "Environment": "production",
  "CostCenter": "engineering-platform",
  "Owner": "platform-team@company.com",
  "Project": "payment-gateway",
  "Compliance": "pci-dss",
  "DataClassification": "confidential"
}

Account Baseline Checklist

[ ] CloudTrail enabled (organization trail)
[ ] Config enabled with required rules
[ ] GuardDuty enabled
[ ] Security Hub enabled
[ ] IAM Access Analyzer enabled
[ ] Default VPC deleted
[ ] EBS encryption by default enabled
[ ] S3 Block Public Access enabled
[ ] Password policy configured

⚖️ Trade-offs

Trade-off 1: Control Tower vs Custom Landing Zone

Khía cạnh	Control Tower	Custom Landing Zone
Time-to-value	Vài giờ đến vài ngày	Vài tuần đến vài tháng
Flexibility	Hạn chế bởi AWS blueprints	Toàn quyền customization
Maintenance	AWS managed updates	Team phải maintain
Guardrails	Pre-built, tested	Phải tự viết và test

Ngữ cảnh enterprise: Một ngân hàng lớn tại Việt Nam đã chọn Custom Landing Zone vì yêu cầu compliance đặc thù từ Ngân hàng Nhà nước không match với Control Tower guardrails. Họ mất 6 tháng và 4 engineers để xây dựng, nhưng có full control. Ngược lại, một e-commerce startup dùng Control Tower và go-live trong 2 tuần.

Khuyến nghị: Bắt đầu với Control Tower cho 80% use cases. Chỉ custom khi có yêu cầu compliance đặc thù mà Control Tower không đáp ứng.

Trade-off 2: Granular SCPs vs Operational Agility

Khía cạnh	SCPs nghiêm ngặt	SCPs tối thiểu
Security	Phòng thủ sâu, nhiều layers	Dựa vào IAM policies
Developer Experience	Nhiều friction, requests chậm	Agile, deploy nhanh
Blast radius khi breach	Nhỏ, contained	Lớn, lan rộng
Operational overhead	Cao, cần governance process	Thấp

Ngữ cảnh enterprise: Team Platform của một công ty fintech đã apply SCP cấm tất cả regions ngoại trừ ap-southeast-1. Sau 2 tháng, team ML cần dùng specific GPU instances chỉ available ở us-east-1. Process exception request mất 2 tuần, delay project 1 sprint.

Khuyến nghị:

SCPs nên: 
✅ Block high-risk actions (leave org, disable logging, disable encryption)
✅ Enforce baseline requirements (IMDSv2, encryption)
❌ Không nên micro-manage service usage

Trade-off 3: Số lượng Accounts vs Operational Complexity

Số Accounts	Ưu điểm	Nhược điểm
Ít (5-10)	Dễ quản lý, team nhỏ handle được	Isolation kém, shared limits
Vừa (20-50)	Balance tốt cho mid-size org	Cần automation
Nhiều (100+)	Isolation tốt nhất, blast radius nhỏ nhất	Cần dedicated Platform team, tooling phức tạp

Ngữ cảnh enterprise: Một tập đoàn với 15 công ty con ban đầu dùng 1 account/company (15 accounts). Sau 2 năm, họ expand thành mỗi company có dev/staging/prod (45 accounts). Cost management và cross-account access trở nên nightmare. Họ đã phải đầu tư xây dựng internal platform tool để manage.

Khuyến nghị: Rule of thumb: Số accounts = Số BU × Số environments × Số compliance boundaries. Nhưng đừng vượt quá khả năng automation của team.

🚨 Failure Modes

Failure Mode 1: Account Sprawl (Lan tràn accounts không kiểm soát)

┌─────────────────────────────────────────────────────────────────┐
│                    ACCOUNT SPRAWL PATTERN                       │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Year 1:          Year 2:              Year 3:                  │
│  ┌────────┐       ┌────────────────┐   ┌────────────────────┐   │
│  │   5    │  →    │      25        │ → │        80+         │   │
│  │accounts│       │   accounts     │   │   accounts         │   │
│  └────────┘       │ "ai dev biết?" │   │   ❓❓❓           │   │
│                   └────────────────┘   └────────────────────┘   │
│                                                                 │
│  Triệu chứng:                                                   │
│  • Không ai biết account XYZ dùng để làm gì                     │
│  • Resources bị "orphaned" - có resources nhưng không có owner  │
│  • Cost tăng nhưng không trace được nguồn                       │
│  • Security baseline không consistent                           │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Cách phát hiện	Cách phòng tránh
Monthly review accounts không có `Owner` tag	Enforce mandatory tags khi tạo account
Audit accounts với 0 cost trong 30 ngày	Account lifecycle policy với expiry date
Check accounts không trong OU nào	Bắt buộc assign OU khi vending
Review accounts chưa có baseline security	Automated baseline checks via Config

Failure Mode 2: SCP Lockout (Tự khóa mình khỏi account)

🔥 Incident thực tế

Một DevOps engineer apply SCP "Effect": "Deny", "Action": "*" lên Root OU để test. Kết quả: Toàn bộ organization bị lock, kể cả management account. AWS Support mất 4 giờ để recover. Downtime ảnh hưởng toàn bộ production.

Cách phát hiện	Cách phòng tránh
Test SCPs trong Sandbox OU trước	Luôn có "Sandbox" OU để test policies
CI/CD validate SCP syntax trước khi apply	Dùng `aws organizations simulate-custom-policy`
Monitor CloudTrail cho SCP changes	Alert ngay khi có SCP modification ở Root
Có "break glass" procedure document	Emergency IAM User với MFA hardware token

Break Glass Procedure:

1. Sử dụng Root credentials của Management Account (stored offline)
2. Login với Hardware MFA token
3. Navigate đến Organizations → SCPs
4. Detach problematic SCP từ affected OUs
5. Document incident và run post-mortem

Failure Mode 3: Cross-Account Access Misconfiguration

Cách phát hiện	Cách phòng tránh
IAM Access Analyzer findings	Enable Access Analyzer ở organization level
CloudTrail `AssumeRole` events từ unexpected principals	Monitor cross-account assume role patterns
Trust policies với `Principal: "*"`	SCP deny overly permissive trust policies
External accounts trong trust relationships	Regular audit với automated scripts

Ví dụ Trust Policy có vấn đề:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"  // ❌ NGUY HIỂM: Bất kỳ AWS account nào cũng assume được
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Trust Policy đúng:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/SpecificRole"  // ✅ Chỉ định cụ thể
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-id-12345"  // ✅ Thêm ExternalId
        }
      }
    }
  ]
}

🔐 Security Baseline

IAM Requirements

Yêu cầu	Implementation	Kiểm tra
Không dùng Root User	SCP deny root actions	Config Rule: `root-account-mfa-enabled`
MFA cho tất cả console access	SSO với MFA enforcement	IAM Credential Report
Cross-account access qua Roles	No IAM Users cho cross-account	Access Analyzer
Permission Boundaries cho delegated admin	Attach boundary khi tạo roles	Custom Config Rule

Keys/Secrets Management

┌─────────────────────────────────────────────────────────────────┐
│              ACCOUNT-LEVEL SECRETS STRATEGY                     │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  Management Account:                                            │
│  ├── Root credentials → Offline storage (vault/safe)            │
│  ├── Break glass IAM User → Hardware MFA, sealed envelope       │
│  └── Organization API keys → Secrets Manager + rotation         │
│                                                                 │
│  Workload Accounts:                                             │
│  ├── No long-term credentials → Use IAM Roles                   │
│  ├── Service account keys → Secrets Manager với auto-rotation   │
│  └── Cross-account access → AssumeRole với ExternalId           │
│                                                                 │
│  Audit Account:                                                 │
│  └── Read-only cross-account roles → Để collect logs            │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Data Access Patterns

Account Type	Data Access Policy
Log Archive	Write-only từ workload accounts, read-only cho security team
Audit	Read-only aggregate access, no direct resource access
Production	Strict least-privilege, no developer direct access
Development	Broader access cho experimentation, isolated data

📊 Ops Readiness

Metrics cần monitoring

Metric	Nguồn	Alert Threshold
Số accounts trong org	Organizations API	Spike > 10% monthly
Accounts không có baseline	Config Aggregator	> 0
SCP changes	CloudTrail	Bất kỳ change nào
Cross-account AssumeRole failures	CloudTrail	Spike pattern
Account vending failures	Service Catalog	> 0

Alerting Configuration

json

{
  "EventPattern": {
    "source": ["aws.organizations"],
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
      "eventSource": ["organizations.amazonaws.com"],
      "eventName": [
        "CreatePolicy",
        "UpdatePolicy", 
        "AttachPolicy",
        "DetachPolicy",
        "CreateAccount",
        "CloseAccount"
      ]
    }
  },
  "Targets": [
    {
      "Arn": "arn:aws:sns:ap-southeast-1:123456789012:platform-alerts",
      "Id": "OrgChangesAlert"
    }
  ]
}

Runbook Entry Points

Tình huống	Runbook
New account request	`runbook/account-vending.md`
Account decommission	`runbook/account-closure.md`
SCP update request	`runbook/scp-change-management.md`
Break glass activation	`runbook/break-glass-procedure.md`
Cross-account access issue	`runbook/cross-account-troubleshooting.md`
Account baseline drift	`runbook/baseline-remediation.md`

✅ Design Review Checklist

Kiến trúc

[ ] OU structure phản ánh đúng org structure và compliance boundaries
[ ] Separation of duties: Security OU tách biệt khỏi Workload OU
[ ] Log Archive account isolated, write-only access
[ ] Management account chỉ chứa Organizations và Control Tower

Security

[ ] Root user credentials stored offline với hardware MFA
[ ] Break glass procedure documented và tested
[ ] SCPs block high-risk actions ở tất cả accounts
[ ] Cross-account access chỉ qua Roles với ExternalId
[ ] No IAM Users cho human access (chỉ SSO)

Operations

[ ] Account Factory automated với approval workflow
[ ] Baseline security verified qua Config Rules
[ ] CloudTrail organization trail enabled
[ ] Alerting cho organization-level changes
[ ] Cost alerts per account/OU configured

Governance

[ ] Account naming convention documented và enforced
[ ] Tagging strategy với mandatory tags
[ ] Account lifecycle policy (creation → active → decommission)
[ ] Regular access reviews scheduled (quarterly)

📎 Liên kết

📎 GCP Resource Hierarchy - So sánh với Org/Folder/Project model của GCP
📎 IAM Fundamentals - Chi tiết về IAM trong multi-account setup
📎 Terraform State Management - Quản lý state cho multi-account IaC
📎 Terraform Security - OIDC assumeRole cho CI/CD pipelines

🏗️ Account & Landing Zone ​

🎯 Mục tiêu (Outcomes) ​

✅ Khi nào dùng ​

❌ Khi nào KHÔNG dùng ​

Tại sao cần Multi-Account Strategy? ​

Vấn đề với Single Account ​

AWS Organizations ​

Organizational Unit (OU) Structure ​

Service Control Policies (SCPs) ​

AWS Control Tower ​

Landing Zone Components ​

Guardrails Categories ​

Account Factory ​

Account Vending Best Practices ​

Naming Convention ​

Tagging Strategy ​

Account Baseline Checklist ​

⚖️ Trade-offs ​

Trade-off 1: Control Tower vs Custom Landing Zone ​

Trade-off 2: Granular SCPs vs Operational Agility ​

Trade-off 3: Số lượng Accounts vs Operational Complexity ​

🚨 Failure Modes ​

Failure Mode 1: Account Sprawl (Lan tràn accounts không kiểm soát) ​

Failure Mode 2: SCP Lockout (Tự khóa mình khỏi account) ​

Failure Mode 3: Cross-Account Access Misconfiguration ​

🔐 Security Baseline ​

IAM Requirements ​

Keys/Secrets Management ​

Data Access Patterns ​

📊 Ops Readiness ​

Metrics cần monitoring ​

Alerting Configuration ​

Runbook Entry Points ​

✅ Design Review Checklist ​

Kiến trúc ​

Security ​

Operations ​

Governance ​

📎 Liên kết ​

🏗️ Account & Landing Zone

🎯 Mục tiêu (Outcomes)

✅ Khi nào dùng

❌ Khi nào KHÔNG dùng

Tại sao cần Multi-Account Strategy?

Vấn đề với Single Account

AWS Organizations

Organizational Unit (OU) Structure

Service Control Policies (SCPs)

AWS Control Tower

Landing Zone Components

Guardrails Categories

Account Factory

Account Vending Best Practices

Naming Convention

Tagging Strategy

Account Baseline Checklist

⚖️ Trade-offs

Trade-off 1: Control Tower vs Custom Landing Zone

Trade-off 2: Granular SCPs vs Operational Agility

Trade-off 3: Số lượng Accounts vs Operational Complexity

🚨 Failure Modes

Failure Mode 1: Account Sprawl (Lan tràn accounts không kiểm soát)

Failure Mode 2: SCP Lockout (Tự khóa mình khỏi account)

Failure Mode 3: Cross-Account Access Misconfiguration

🔐 Security Baseline

IAM Requirements

Keys/Secrets Management

Data Access Patterns

📊 Ops Readiness

Metrics cần monitoring

Alerting Configuration

Runbook Entry Points

✅ Design Review Checklist

Kiến trúc

Security

Operations

Governance

📎 Liên kết