Governance and Multi-account Strategy

เมื่อระบบโตขึ้น การแยก account และวาง guardrails สำคัญกว่า permission รายคน เพราะช่วยลด blast radius และทำให้ governance ชัดเจน

AWS Organizations

AWS Organizations ช่วยจัดการหลาย AWS accounts ภายใต้ organization เดียว มี management account, member accounts, Organizational Units และ policy controls เช่น Service Control Policy

Multi-account strategy

แยก account ตามหน้าที่และความเสี่ยง เช่น Production, Non-production, Security, Log Archive และ Shared Services การแยกแบบนี้ทำให้ billing, IAM boundary, audit log และ incident response ชัดกว่าใช้ account เดียวรวมทุกอย่าง

Organizational Unit และ Service Control Policy

Organizational Unit หรือ OU ใช้จัดกลุ่ม accounts ตาม policy boundary เช่น Sandbox, Workloads หรือ Security Service Control Policy หรือ SCP ใช้กำหนด permission ceiling ของ accounts ใน OU นั้น SCP ไม่ grant permission เอง แต่ใช้จำกัดสิ่งที่ IAM ภายใน account สามารถทำได้

Example SCP intent:
- Deny disabling CloudTrail
- Deny leaving the Organization
- Deny creating resources outside approved Regions
- Deny public S3 bucket policy except approved accounts

Production และ Non-production separation

Production ควรแยกจาก dev/staging เพื่อป้องกันการทดลองกระทบระบบจริง แยก deployment role, network, data, budget, monitoring และ access approval ให้ชัดเจน

Control Tower

AWS Control Tower ช่วยตั้ง landing zone, account factory และ guardrails บน AWS Organizations เหมาะเมื่อทีมต้องการ bootstrap multi-account environment แบบมี baseline governance ตั้งแต่ต้น

Common mistakes

• ใช้ management account ทำ workload ปกติ ทำให้ blast radius สูง
• เขียน SCP กว้างหรือผิด logic จนปิดกั้นทีม deploy ระบบจำเป็น
• รวม production และ non-production data ใน account เดียวกันโดยไม่มี isolation

Review questions

1. SCP ต่างจาก IAM Policy อย่างไร?
2. ทำไมต้องแยก Production และ Non-production Account?
3. Log Archive Account มีประโยชน์อย่างไร?