บทที่ 02: Multi-Account Governance (AWS Organizations & Control Tower)

Domain: Domain 1 — Design Solutions for Organizational Complexity คำอธิบายเป็นไทย; ชื่อบริการ/ศัพท์เทคนิค/CLI/JSON เป็นอังกฤษเสมอ; keyword ในโจทย์คงเป็นภาษาอังกฤษ (italic)

1. วัตถุประสงค์บท

หลังอ่านบทนี้จบ คุณจะสามารถ:

อธิบายได้ว่า “ทำไมองค์กรระดับ enterprise จึงต้องใช้หลาย AWS account” โดยเชื่อมโยงเข้ากับ blast radius, การแยก billing, การแยก environment และการหลบ soft limit ที่ผูกกับ account
ออกแบบโครงสร้าง AWS Organizations ได้: แยกบทบาท management (payer) account กับ member account, วาง Organizational Unit (OU) hierarchy ตาม AWS best practice (Security / Infrastructure / Workloads / Sandbox / Suspended)
เข้าใจกลไก Service Control Policies (SCP) อย่างลึก: เหตุใด SCP เป็น guardrail ที่ “ไม่เคยให้สิทธิ์เอง”, policy evaluation logic เมื่อรวมกับ identity policy, ผลกระทบพิเศษต่อ management account, และเขียน SCP ตัวอย่าง (deny region, deny root, require encryption)
ตัดสินใจได้ว่าเมื่อไหร่ควรใช้ AWS Control Tower (landing zone สำเร็จรูป) กับเมื่อไหร่ควรสร้าง custom landing zone เอง — และเข้าใจ guardrails (preventive / detective / proactive), Account Factory, Account Factory for Terraform (AFT)
วางกลยุทธ์ governance เสริม: Tag Policies, AWS Config aggregator ระดับ org, delegated administration และ consolidated billing ในมุม governance
รู้วิธี migrate account เดิมเข้าสู่ Organization และ enroll เข้า Control Tower อย่างปลอดภัย

หัวข้อ IAM/federation เชิงลึกอยู่บทที่ 03, cost optimization เชิงลึกอยู่บทที่ 10, และรายละเอียดฟังก์ชันของ security service (GuardDuty/Config rules) อยู่บทที่ 09 — บทนี้แตะเฉพาะมุม governance ที่ผูกกับ Organizations เท่านั้น

2. แนวคิดหลัก

2.1 ทำไมต้อง multi-account (ไม่ใช่แค่ multi-VPC)

คำถามระดับ Professional มักไม่ถามว่า “multi-account คืออะไร” แต่ถามว่า “workload นี้ควรอยู่ account เดียวกับ workload อื่นหรือควรแยก” การตอบได้ต้องเข้าใจ 5 แรงผลักดันหลัก:

1) Blast radius isolation (ลดรัศมีความเสียหาย) account คือขอบเขต isolation ที่แข็งแรงที่สุดของ AWS — แข็งกว่า IAM policy หรือ VPC เพราะเป็นขอบเขตในระดับ control plane เอง หาก credential ของ account หนึ่งรั่ว, มี misconfiguration, หรือมี runaway automation ที่สร้าง resource มหาศาล ความเสียหายจะถูกกักอยู่ใน account นั้น ไม่ลามข้ามไปยัง production account อื่น นี่คือการนำแนวคิด blast radius จากบทที่ 01 (mindset ระดับ Professional) มาลงมือทำจริง

2) Environment separation (แยก dev/staging/prod) การแยก environment คนละ account ป้องกัน “การเผลอแก้ prod ขณะตั้งใจแก้ dev” ได้เด็ดขาดกว่าการใช้ tag หรือ naming convention เพราะ credential/role คนละชุดกันโดยสิ้นเชิง และยังทำให้ apply SCP ที่เข้มกับ prod OU ต่างจาก sandbox OU ได้

3) Billing & cost allocation แต่ละ account สร้าง usage record แยกกัน ทำให้ต้นทุนต่อทีม/ต่อ product ชัดเจนโดยไม่ต้องพึ่ง cost allocation tag อย่างเดียว (ซึ่งทีมมักลืมติด) ภายใต้ consolidated billing ทุก account ยังรวมบิลที่ management account เพื่อได้ volume discount และ shared Reserved Instances/Savings Plans — รายละเอียดเชิง cost อยู่บทที่ 10

4) Soft-limit / quota isolation service quota จำนวนมาก (เช่น จำนวน EC2 instance ต่อ region, Lambda concurrency, VPC ต่อ region) เป็น per-account per-region เมื่อ workload หนึ่งกิน quota จนเต็ม จะไม่ไปเบียด quota ของ workload อื่นถ้าอยู่คนละ account การแยก account จึงเป็นเทคนิค scaling อย่างหนึ่ง ไม่ใช่แค่เรื่อง security

5) Security & compliance boundary workload ที่อยู่ภายใต้ regulation ต่างกัน (เช่น PCI-DSS vs ทั่วไป) ควรแยก account เพื่อจำกัด audit scope และ apply guardrail เฉพาะกลุ่ม การมี account แยกทำให้พิสูจน์ต่อ auditor ได้ง่ายว่า data ไม่ปนกัน

กับดักข้อสอบ: ถ้าโจทย์บอกว่าต้อง “แยก billing ต่อทีมแบบเด็ดขาด + จำกัด blast radius + ให้แต่ละทีม autonomy” คำตอบเกือบทุกครั้งคือ แยกเป็น account ต่อทีม/environment ภายใต้ Organizations ไม่ใช่ “แยก VPC” หรือ “แยก IAM group ใน account เดียว”

2.2 AWS Organizations: โครงสร้างพื้นฐาน

AWS Organizations คือบริการที่รวมหลาย AWS account ให้บริหารแบบรวมศูนย์ (centralized governance + consolidated billing) องค์ประกอบสำคัญ:

องค์ประกอบ	บทบาท
Management account (payer)	account ที่สร้าง organization; เป็นเจ้าของ consolidated billing, เป็นที่เดียวที่ apply/บริหาร SCP, สร้าง OU, เชิญ/สร้าง member account
Member account	account อื่นทั้งหมดใน org; อยู่ภายใต้ SCP และ policy ที่ management account กำหนด
Root (organization root)	จุดสูงสุดของ hierarchy (ไม่ใช่ root user); เป็นที่แขวน OU และ account ทั้งหมด
Organizational Unit (OU)	คอนเทนเนอร์จัดกลุ่ม account; ซ้อนกันได้หลายชั้น (nested OU) เพื่อ apply policy ตามลำดับชั้น

หัวใจที่ต้องเข้าใจเรื่อง management account:

management account มีอำนาจสูงสุดและ SCP ไม่มีผลบังคับกับ management account แม้จะ attach SCP ที่ deny ทุกอย่างไว้ที่ root — management account ก็ยังทำได้ นี่เป็นเหตุผลด้านความปลอดภัยที่สำคัญมาก (ดูข้อ 2.4)
ด้วยเหตุนี้ AWS best practice จึงกำหนดว่า อย่ารัน workload ใด ๆ ใน management account ให้ใช้มันทำแค่ billing และ org management เท่านั้น เพื่อลด attack surface ของ account ที่ SCP ควบคุมไม่ได้

Feature set สองแบบ:

Consolidated Billing only — รวมบิลอย่างเดียว, ไม่มี SCP/policy governance
All Features (default และแนะนำ) — ปลดล็อก SCP, Tag Policies, delegated admin, integration กับ Control Tower ฯลฯ

ข้อสอบมักถือว่าองค์กรอยู่ในโหมด All Features เสมอ ถ้าโจทย์บอกว่า “ต้องบังคับ policy ข้าม account” แต่มีตัวเลือกว่า organization อยู่ใน Consolidated Billing only — นั่นคือ constraint ซ่อนที่ต้องแก้ก่อน (ต้อง enable All Features)

2.3 การออกแบบ OU hierarchy (AWS best practice)

AWS แนะนำให้จัด OU ตาม ฟังก์ชัน/lifecycle ของ workload ไม่ใช่ตามผังองค์กร (org chart) เพราะผังองค์กรเปลี่ยนบ่อย แต่ความต้องการด้าน security/operation ของ workload เปลี่ยนช้ากว่า โครงสร้างอ้างอิง (จาก AWS “Organizing Your AWS Environment Using Multiple Accounts”):

OU	วัตถุประสงค์	ตัวอย่าง account ข้างใน
Security	บริการ security/audit รวมศูนย์	Log Archive account, Security Tooling / Audit account
Infrastructure	shared services ที่ทุก workload ใช้	Networking account (TGW, DX), Shared Services (AD, CI/CD)
Workloads	workload จริงของธุรกิจ	Prod OU, Non-Prod (SDLC) OU ซ้อนข้างใน
Sandbox	พื้นที่ทดลองอิสระของ dev	account ทดลองที่ตัดจาก corporate network
Policy Staging / Deployments	ทดสอบ SCP/policy ก่อนใช้จริง	account ทดสอบ guardrail
Suspended	account ที่รอปิด/ถูกกักกัน	attach SCP deny-all ไว้

หลักการออกแบบที่ข้อสอบชอบถาม:

แยก Prod กับ Non-Prod เป็น OU คนละตัว เพื่อ apply SCP เข้มกับ Prod (เช่น deny การลบ CloudTrail, deny การปิด encryption) โดยไม่กระทบความคล่องตัวของ dev
Log Archive account ต้องเป็น account แยก ที่แทบไม่มีใครเข้าถึง เก็บ CloudTrail log และ Config snapshot ขององค์กรทั้งหมดแบบ write-once เพื่อให้ log พิสูจน์ได้แม้ production account ถูกเจาะ (log ไม่ได้อยู่ที่เดียวกับสิ่งที่ถูกโจมตี)
SCP ถูก inherit ลงตามลำดับชั้น — policy ที่ attach ที่ root มีผลกับทุก OU/account ใต้ลงมา, ที่ OU ชั้นบนมีผลกับ OU/account ที่ซ้อนอยู่ ใช้หลักนี้วาง guardrail กว้าง ๆ ที่ root/ชั้นบน แล้วเจาะจงขึ้นเรื่อย ๆ เมื่อลงลึก

2.4 Service Control Policies (SCP) — กลไกเชิงลึก

SCP เป็นหัวใจของ Domain 1 และเป็นเรื่องที่ข้อสอบวางกับดักบ่อยที่สุด (บทที่ 01 ได้ฝากประเด็นนี้มา) ต้องเข้าใจ 4 ข้อนี้ให้ขึ้นใจ:

(1) SCP เป็น guardrail — ไม่เคยให้สิทธิ์เอง SCP กำหนดเพียง “เพดานสิทธิ์สูงสุด (maximum available permissions)” ที่ principal ใน account นั้น มีโอกาส ได้รับ แต่ตัว SCP เองไม่ได้มอบสิทธิ์ให้ใครเลย การจะทำ action ใดได้จริง principal ต้องได้ allow จาก identity-based policy (หรือ resource-based policy) ด้วย เสมอ พูดง่าย ๆ: SCP allow เพียง “เปิดทาง” แต่ยังต้องมี IAM policy allow จริงถึงจะทำได้

สูตรผลลัพธ์สุดท้าย (effective permission) สำหรับ member account:

อนุญาตจริง = (allow ใน IAM identity policy) ∩ (allow ที่ SCP ยอมให้)  แล้วต้องไม่มี explicit deny ที่ใดเลย

(2) Evaluation logic — explicit deny ชนะทุกอย่าง ลำดับตัดสิน (สรุปจาก IAM policy evaluation — รายละเอียดเต็มบทที่ 03):

มี explicit Deny ที่ใดก็ตาม (SCP, IAM, resource policy, boundary) → ปฏิเสธทันที จบ
ไม่มี allow ที่ตรงกัน → ปฏิเสธ (implicit deny)
SCP ต้องมี allow ครอบ action นั้น (โดย default SCP มี FullAWSAccess ที่ allow ทุกอย่าง)
IAM identity policy ต้องมี allow ครอบ action นั้น

(3) รูปแบบ SCP: deny list vs allow list

Deny list strategy (พบบ่อยสุด, แนะนำ): ปล่อย default FullAWSAccess ไว้ แล้ว attach SCP เพิ่มที่ระบุเฉพาะสิ่งที่ ห้าม — ยืดหยุ่นสูง service ใหม่ใช้ได้เลยโดยไม่ต้องแก้ policy
Allow list strategy: ถอด FullAWSAccess ออก แล้วระบุเฉพาะ service ที่ อนุญาต — เข้มมากแต่ดูแลยาก เพราะทุกครั้งที่อยากใช้ service ใหม่ต้องแก้ SCP; เหมาะกับ environment ที่ต้อง lock ดาวน์สุด ๆ

(4) ผลพิเศษต่อ management account ย้ำอีกครั้งเพราะสำคัญมากในข้อสอบ: SCP ไม่มีผลกับ management account เด็ดขาด ต่อให้ attach SCP ที่ root คลุมทุกอย่าง management account ก็ไม่ถูกจำกัด นี่เป็นสาเหตุที่ต้องย้าย workload ออกจาก management account และใช้ delegated administration แทน

ตัวอย่าง SCP ที่ข้อสอบชอบ:

ก) จำกัดการใช้เฉพาะ region ที่กำหนด (data residency) — deny ทุก action นอก ap-southeast-1 และ us-east-1 แต่ยกเว้น global service ที่ผูก endpoint กับ us-east-1 (IAM, CloudFront, Route 53, Organizations, Support):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideAllowedRegions",
    "Effect": "Deny",
    "NotAction": [
      "iam:*", "organizations:*", "route53:*",
      "cloudfront:*", "support:*", "sts:*"
    ],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": ["ap-southeast-1", "us-east-1"]
      }
    }
  }]
}

ข) ห้ามใช้ root user ของ member account ทำ action ใด ๆ:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyRootUser",
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:root" }
    }
  }]
}

ค) บังคับ encryption ตอนอัปโหลด S3 (require SSE) — deny s3:PutObject ถ้า header ไม่ระบุ server-side encryption:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyUnencryptedUploads",
    "Effect": "Deny",
    "Action": "s3:PutObject",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "s3:x-amz-server-side-encryption": ["aws:kms", "AES256"]
      }
    }
  }]
}

ง) กันไม่ให้ปิด/ลบ guardrail หลัก — deny การ cloudtrail:StopLogging, cloudtrail:DeleteTrail, config:DeleteConfigurationRecorder, guardduty:DeleteDetector เพื่อป้องกัน member account ปิดตัวตรวจจับของตัวเอง (นี่คือการใช้ preventive control ปกป้อง detective control — แนวคิด defense-in-depth ที่ต่อยอดบทที่ 09)

จุดพลาดยอดฮิต: ผู้สอบมักคิดว่า “attach SCP allow แล้ว user จะทำได้ทันที” — ผิด SCP allow แค่ยกเพดาน ยังต้องมี IAM policy allow จริง และถ้าพบ explicit deny ที่ SCP → ต่อให้ IAM allow เต็มที่ก็ทำไม่ได้ (explicit deny ชนะ)

2.5 AWS Control Tower

AWS Control Tower คือบริการที่ตั้ง landing zone (สภาพแวดล้อม multi-account ที่ปลอดภัย ทำตาม best practice) ให้อัตโนมัติ โดยประกอบ Organizations + SCP + AWS Config + CloudTrail + IAM Identity Center + centralized logging เข้าด้วยกันแบบสำเร็จรูป แทนที่จะต้อง wire เองทีละชิ้น

สิ่งที่ Control Tower ตั้งให้อัตโนมัติ (ตอน set up landing zone):

สร้าง OU พื้นฐาน: Security OU และ Sandbox OU (ปรับแต่ง/เพิ่มได้)
สร้าง shared account หลักสองตัว: Log Archive account (เก็บ CloudTrail/Config log ทั้ง org แบบรวมศูนย์) และ Audit account (สำหรับ security team, มี cross-account role เข้าไปตรวจ account อื่น)
เปิด org-wide CloudTrail, AWS Config, และวาง guardrail ชุดเริ่มต้น
ตั้ง IAM Identity Center สำหรับ federated access (รายละเอียด Identity Center อยู่บทที่ 03)

Guardrails (ปัจจุบัน AWS เรียกรวมว่า “controls”) — 3 ประเภท:

ประเภท	กลไก	เบื้องหลัง	ตัวอย่าง
Preventive	ป้องกันไม่ให้ทำ (บล็อก action)	ใช้ SCP	ห้าม disable CloudTrail, ห้ามสร้าง resource นอก region ที่กำหนด
Detective	ตรวจจับหลังเกิด + รายงาน compliance	ใช้ AWS Config rules	ตรวจว่า EBS volume ไม่ได้ encrypt, ตรวจว่า S3 bucket เปิด public
Proactive	บล็อก resource ที่ไม่ compliant “ก่อน” ถูก provision	ใช้ CloudFormation Hooks	บล็อก stack ที่จะสร้าง RDS ไม่เข้ารหัส ตั้งแต่ตอน deploy

ระดับความเข้มยังแบ่งเป็น mandatory (บังคับเสมอ), strongly recommended, และ elective นอกจากนี้ยังมีมิติ region deny และ data residency controls

จุดต่างที่ข้อสอบเจาะ: preventive = SCP (กันไว้ก่อน, ทำไม่ได้เลย); detective = Config (เกิดแล้วค่อยรู้, รายงานว่า non-compliant); proactive = CloudFormation Hooks (กันตอน provision ผ่าน IaC ก่อนทรัพยากรจะเกิดจริง) — ถ้าโจทย์บอก “ต้อง prevent ไม่ให้เกิดขึ้นได้เลย” ให้เลือก preventive/SCP ไม่ใช่ Config

Account Factory เทมเพลตสำหรับ provision account ใหม่ให้เข้ามาตรฐาน landing zone อัตโนมัติ (vend account ผ่าน Service Catalog) — กำหนด network baseline, guardrail, และ enroll เข้า OU ที่กำหนดให้ทันที ทำให้ทุก account ที่เกิดใหม่ compliant ตั้งแต่วันแรก

Account Factory for Terraform (AFT) สำหรับองค์กรที่ทำ Infrastructure as Code ด้วย Terraform — AFT เป็น pipeline (GitOps) ที่ vend account ผ่าน Control Tower โดยขับเคลื่อนจาก Terraform ทำให้ customization ต่อ account (baseline resource, IAM role, tag) เป็น code, ทำ review/version control ได้ เหมาะกับองค์กรที่ต้องการ automation ระดับสูงและใช้ Terraform เป็นมาตรฐานอยู่แล้ว

การ enroll / ความสัมพันธ์กับ Organizations:

Control Tower ทำงานบน AWS Organizations — มันไม่ใช่ตัวแทน แต่เป็นชั้น orchestration ที่จัดการ Organizations ให้
account ที่มีอยู่แล้วสามารถ enroll เข้า Control Tower ได้ (ต้องมี prerequisite เช่น มี AWSControlTowerExecution role และไม่มี config recorder ที่ชนกัน)
ข้อควรระวังสำคัญ: เมื่อใช้ Control Tower แล้ว ควรจัดการ OU/account/guardrail ผ่าน Control Tower เป็นหลัก การไปแก้ SCP หรือย้าย account ตรง ๆ ใน Organizations console อาจทำให้ landing zone เข้าสถานะ “drift” ซึ่งต้อง re-register/repair — ข้อนี้เป็น trade-off สำคัญของ Control Tower (ดูข้อ 4)

2.6 Governance เสริม: Tagging, Config aggregator, Delegated admin, Billing

Tag Policies (ผ่าน Organizations) กำหนด “มาตรฐาน tag” ทั้ง org — บังคับ key ให้สะกดตรง (CostCenter ไม่ใช่ costcenter), บังคับค่าที่อนุญาต, และรายงาน resource ที่ไม่ตรงมาตรฐาน

ข้อจำกัดที่ต้องรู้: Tag Policy ไม่ได้บังคับให้ต้องมี tag ตอนสร้าง resource โดยตัวมันเอง มันตรวจ compliance และบังคับ รูปแบบ ถ้าจะ “บังคับต้องติด tag ตั้งแต่สร้าง” ต้องใช้ SCP ร่วมกับ condition aws:RequestTag/aws:TagKeys (preventive) หรือ IAM policy — Tag Policy เพียงอย่างเดียวเป็น detective เป็นหลัก
ประโยชน์ต่อ cost allocation: tag ที่สม่ำเสมอทำให้ cost report แยกตามทีม/product ได้แม่น (cost เชิงลึกบทที่ 10)

AWS Config aggregator ระดับ org รวม config/compliance data จากทุก account/ทุก region มาไว้ที่ aggregator เดียว (มักตั้งที่ Audit/Security account) ทำให้ security team เห็นภาพ compliance ทั้ง org จากที่เดียว — ใช้ organization aggregator แทนการไปตั้ง aggregator ทีละ account รายละเอียด Config rules อยู่บทที่ 09

Delegated administration โดย default บริการ org-wide หลายตัว (GuardDuty, Security Hub, Config, Firewall Manager, IAM Access Analyzer ฯลฯ) ถูกบริหารจาก management account แต่ AWS best practice คือ มอบหมาย (delegate) การบริหารให้ member account เฉพาะทาง (เช่น Audit/Security Tooling account) เพื่อ:

ลดการใช้งาน management account ให้เหลือน้อยที่สุด (ตามหลักในข้อ 2.2)
ให้ security team ทำงานใน account ของตัวเองโดยไม่ต้องมี credential ใน management account

ตัวอย่าง: กำหนด Security Tooling account เป็น delegated administrator ของ GuardDuty และ Security Hub — team จัดการ finding ทั้ง org ได้จาก account เดียวโดยไม่แตะ management account

Consolidated billing ในมุม governance

ทุก member account ส่ง usage ไปรวมบิลเดียวที่ management (payer) account
ระดับ governance ที่ต้องรู้ (รายละเอียด cost/pricing บทที่ 10): การรวมช่วยให้ได้ volume tiering ข้าม account และ แชร์ Reserved Instances / Savings Plans discount ข้าม account โดยอัตโนมัติ (เว้นแต่จะปิด RI/SP sharing ของบาง account)
management account ตั้ง consolidated billing เป็น single source of truth และใช้ AWS Budgets / Cost Categories map ต้นทุนตาม OU ได้

3. ตารางเปรียบเทียบบริการ

3.1 Single account vs Multi-account

มิติ	Single account (แยกด้วย IAM/VPC/tag)	Multi-account (Organizations)
Blast radius	จำกัดยาก — พึ่ง IAM policy ล้วน	แข็งแรงที่สุด (ขอบเขต account)
Billing separation	ต้องพึ่ง cost allocation tag	แยกโดยธรรมชาติ + consolidated
Quota/soft limit	ทุก workload แย่ง quota เดียวกัน	แยก quota ต่อ account
Operational overhead	ต่ำตอนเริ่ม	สูงขึ้น ต้องมี governance layer
เหมาะกับ	ระบบเล็ก/ทีมเดียว/PoC	enterprise, หลายทีม, compliance

3.2 SCP vs IAM policy vs Permission boundary (มุม governance)

	SCP	IAM identity policy	Permission boundary
ให้สิทธิ์ได้เองไหม	ไม่ (guardrail)	ได้	ไม่ (จำกัดเพดาน)
ขอบเขต	ทั้ง account/OU	เฉพาะ principal ที่ attach	เฉพาะ principal ที่ attach
ใครตั้ง	management account	admin ใน account	admin ใน account
มีผลกับ management account	ไม่	ได้	ได้
ประเภท control	preventive (org-wide)	grant	preventive (per-principal)

รายละเอียด permission boundary/session policy และ evaluation logic แบบเต็ม → บทที่ 03

3.3 Control Tower guardrails 3 ประเภท

	Preventive	Detective	Proactive
จังหวะทำงาน	ก่อน action (บล็อกเลย)	หลัง resource เกิด	ตอน provision ผ่าน CFN
กลไกเบื้องหลัง	SCP	AWS Config rule	CloudFormation Hooks
ผลลัพธ์	ทำไม่ได้เลย	รายงาน non-compliant	บล็อก stack ก่อน deploy
keyword โจทย์	prevent, block, not allowed	detect, report, audit, flag	before provisioning, IaC

3.4 Control Tower vs Custom (DIY) landing zone

มิติ	AWS Control Tower	Custom landing zone (DIY)
เวลา set up	เร็ว (สำเร็จรูป, ชั่วโมง)	ช้า (สร้างเอง, สัปดาห์+)
ความยืดหยุ่น	จำกัดในกรอบ Control Tower	สูงสุด ปรับได้ทุกอย่าง
Operational overhead	ต่ำ (AWS ดูแล pattern)	สูง (ทีมดูแลเอง)
region/feature ที่รองรับ	จำกัดตามที่ Control Tower รองรับ	ทำได้ทุกที่ที่ service มี
ความเสี่ยง drift	ต้องระวังการแก้ตรง Organizations	ควบคุมเองทั้งหมด
เหมาะกับ	องค์กรที่ต้อง governed baseline เร็ว, least operational overhead	องค์กรที่มี requirement เฉพาะเกินกรอบ Control Tower

4. สถาปัตยกรรมตัวอย่างและ trade-off

สถาปัตยกรรมที่ 1 — Enterprise landing zone ด้วย Control Tower

โจทย์: บริษัทกำลังจะย้ายขึ้น AWS มีหลายทีม ต้องการ multi-account ที่ปลอดภัยตาม best practice, centralized logging, guardrail ป้องกันการปิด audit และให้ทีม provision account ใหม่ได้เร็ว โดย least operational overhead

การออกแบบ:

ใช้ AWS Control Tower ตั้ง landing zone → ได้ Security OU (Log Archive + Audit account) และ Sandbox OU อัตโนมัติ พร้อม org-wide CloudTrail/Config
เพิ่ม OU: Infrastructure (Networking + Shared Services), Workloads (ซ้อน Prod และ Non-Prod)
Preventive guardrails (SCP): ห้าม disable CloudTrail, deny region นอกที่อนุญาต, ห้าม root user ของ member account
Detective guardrails (Config): ตรวจ EBS/S3 encryption, ตรวจ S3 public access
ใช้ Account Factory ให้ทีม vend account ใหม่ผ่าน Service Catalog เข้ามาตรฐานทันที
delegate GuardDuty + Security Hub ให้ Audit account

Trade-off:

ได้: เวลา set up สั้น, baseline ตาม AWS best practice, overhead ต่ำ, log แยกใน Log Archive account พิสูจน์ได้แม้ prod ถูกเจาะ
เสีย/แลก: ผูกกับกรอบ Control Tower — ถ้าไป modify SCP หรือย้าย account ตรงใน Organizations จะเกิด drift ต้อง repair; รองรับบาง region/feature ช้ากว่า; customization นอกกรอบทำได้จำกัด
ทำไมไม่เลือก custom: โจทย์เน้น least operational overhead และ “ตาม best practice” — custom landing zone ให้ยืดหยุ่นกว่าแต่ overhead สูงเกินความจำเป็น

สถาปัตยกรรมที่ 2 — Data residency + compliance boundary ด้วย SCP

โจทย์: องค์กรการเงินต้องบังคับว่า workload ทั้งหมด ห้าม provision นอก region ที่กำหนด และ data ต้องเข้ารหัสเสมอ; ต้อง prevent ไม่ให้เกิดขึ้นได้เลย ไม่ใช่แค่ตรวจจับภายหลัง; ทีมความปลอดภัยต้องเห็น compliance ทั้ง org

การออกแบบ:

attach SCP deny-region (ตัวอย่าง 2.4ก) ที่ Workloads OU — บล็อกทุก action นอก region ที่อนุญาต (ยกเว้น global service)
attach SCP require-encryption (2.4ค) บังคับ SSE ตอน PutObject; และ SCP ห้าม ec2:RunInstances/rds:CreateDBInstance ที่ไม่ระบุ encryption ผ่าน condition
ตั้ง AWS Config organization aggregator ที่ Audit account เพื่อรวม compliance ทั้ง org
ตั้ง Config rule (detective) เสริมสำหรับตรวจสิ่งที่ SCP บังคับไม่ได้ทั้งหมด

Trade-off:

ได้: preventive control ระดับ org แข็งกว่า detective — ผิด compliance ทำไม่ได้ตั้งแต่แรก; ครอบทุก account ใต้ OU โดยอัตโนมัติ
เสีย/แลก: SCP เขียนผิดเงื่อนไข region อาจบล็อก global service โดยไม่ตั้งใจ (ต้อง NotAction ยกเว้นให้ถูก); ทดสอบยากใน production — ควรใช้ Policy Staging OU ทดลองก่อน
ทำไมไม่ใช้ Config อย่างเดียว: Config เป็น detective (รู้หลังเกิด) โจทย์บอก prevent — Config ไม่บล็อกการสร้าง จึงต้องนำด้วย SCP เป็นหลัก, ใช้ Config เสริมมุมที่ SCP ทำไม่ได้

สถาปัตยกรรมที่ 3 — Governance เดิมที่ต้อง migrate account เข้ามา

โจทย์: มี AWS account เดิมกระจัดกระจาย 30 account ที่ทีมสร้างเองต่างกรรมต่างวาระ ต้องการรวมเข้า governance เดียว, ใช้ Terraform เป็นมาตรฐาน IaC, และ enroll เข้า guardrail กลาง

การออกแบบ:

สร้าง organization (All Features) จาก management account ใหม่ที่สะอาด (ไม่มี workload)
เชิญ (invite) account เดิม เข้า organization → account เจ้าของต้องยอมรับคำเชิญ; ต้องระวัง account เดิมที่มี config recorder/CloudTrail อยู่แล้วอาจชนกับ Control Tower
ตั้ง Control Tower + AFT (Account Factory for Terraform) เพื่อ vend/customize account ผ่าน Terraform pipeline (GitOps)
ค่อย ๆ enroll account เดิมเข้า Control Tower ทีละกลุ่ม (ต้องมี AWSControlTowerExecution role, เคลียร์ config ที่ชน)
จัด account เข้า OU ตามฟังก์ชัน (Prod/Non-Prod/Sandbox)

Trade-off:

ได้: รวม governance + billing, customization เป็น code review ได้ผ่าน AFT, เหมาะกับองค์กรที่ใช้ Terraform อยู่แล้ว
เสีย/แลก: การ enroll account เดิมมี prerequisite ยุ่ง (role, config recorder conflict), ต้องทำเป็น wave ไม่ใช่ทีเดียวหมด; ถ้า account เดิมมี resource เยอะต้องตรวจ SCP ที่จะ apply ว่าไม่ทำ workload พังทันที
ทางเลือกที่ตัดทิ้ง: สร้าง account ใหม่แล้ว migrate workload ข้ามไป — ให้ความสะอาดกว่าแต่ overhead/downtime สูงเกินไปเมื่อ account เดิมใช้งาน production อยู่ (การ invite + enroll รบกวนน้อยกว่า)

จำ: account ย้ายข้าม organization ไม่ได้โดยตรง — ต้องออกจาก org เดิม (leave) แล้วรับ invite เข้า org ใหม่ และ account ที่จะ leave ต้องมีข้อมูล billing/contact ครบ (standalone-ready)

5. ข้อผิดพลาดที่พบบ่อยในข้อสอบ

คิดว่า SCP ให้สิทธิ์เอง — SCP allow แค่ยกเพดาน ยังต้องมี IAM identity policy allow จริง principal ถึงทำได้ (ประเด็นที่บทที่ 01 ฝากมา)
ลืมว่า SCP ไม่มีผลกับ management account — โจทย์ที่บอก “attach deny ที่ root แล้วคาดว่าทุก account รวม management ถูกจำกัด” เป็นกับดัก; ต้องย้าย workload ออกจาก management account เสมอ
สับสน preventive vs detective vs proactive — prevent/block → SCP (preventive); detect/report/audit → Config (detective); before provisioning via IaC → CloudFormation Hooks (proactive)
เลือก Config เมื่อโจทย์ต้อง “ป้องกัน” — Config รู้หลังเกิด (detective) บล็อกการสร้างไม่ได้ ถ้าโจทย์ prevent ต้องใช้ SCP
แยกด้วย VPC/IAM แทนที่จะแยก account เมื่อโจทย์เน้น blast radius/billing เด็ดขาด — ขอบเขตที่แข็งที่สุดคือ account ไม่ใช่ VPC
จัด OU ตาม org chart แทนตามฟังก์ชัน — best practice คือจัดตามฟังก์ชัน/lifecycle เพราะ org chart เปลี่ยนบ่อย
คิดว่า Tag Policy บังคับให้ต้องมี tag ตอนสร้าง — Tag Policy ตรวจ รูปแบบ เป็นหลัก (detective); การบังคับ “ต้องติด tag ตั้งแต่สร้าง” ต้องใช้ SCP/IAM ด้วย condition aws:RequestTag
บริหาร GuardDuty/Security Hub จาก management account — best practice คือ delegate ให้ Audit/Security account เพื่อลดการใช้ management account
แก้ SCP/ย้าย account ตรงใน Organizations ทั้งที่ใช้ Control Tower — ทำให้ landing zone drift ต้อง repair; ควรจัดการผ่าน Control Tower
เขียน SCP deny-region โดยลืมยกเว้น global service — IAM, CloudFront, Route 53, Organizations, STS ผูก endpoint กับ us-east-1; deny แบบไม่ NotAction ยกเว้นจะทำ global service ล่มทั้ง org
คิดว่า account ย้ายข้าม organization ได้ตรง ๆ — ต้อง leave org เดิมแล้ว invite เข้า org ใหม่

6. คำถามทบทวน

ข้อ 1. องค์กรต้องการให้ workload ทั้งหมดใน Prod OU ไม่สามารถ ปิดการทำงานของ CloudTrail ได้เลย ไม่ว่า IAM ของ principal จะให้สิทธิ์อะไร ควรใช้อะไร?

เฉลย

ใช้ **SCP (preventive)** ที่ deny `cloudtrail:StopLogging`, `cloudtrail:DeleteTrail` attach ที่ `Prod` OU เพราะ explicit deny ใน SCP ชนะทุก allow ใน IAM — ไม่ว่า principal จะได้สิทธิ์อะไรก็ทำไม่ได้ - *AWS Config rule ผิด:* เป็น detective รู้หลังปิดแล้ว บล็อกไม่ได้ - *IAM policy ผิด:* ควบคุมได้เฉพาะ principal ที่ attach ไม่ครอบทั้ง account และ admin ใน account อาจแก้ policy เอง - *CloudFormation Hooks ผิด:* proactive คุมตอน provision ผ่าน IaC ไม่ครอบการ StopLogging runtime

ข้อ 2. ทีม security รายงานว่า attach SCP ที่ allow s3:* ให้ member account แล้ว แต่ user ยังทำ s3:PutObject ไม่ได้ เพราะอะไร?

เฉลย

เพราะ **SCP ไม่ให้สิทธิ์เอง** — มันแค่ยกเพดานให้ทำ S3 ได้ แต่ตัว user ยังต้องมี **IAM identity policy** ที่ allow `s3:PutObject` ด้วย เมื่อ IAM policy ยังไม่ได้ allow (implicit deny) จึงทำไม่ได้ (หรืออาจมี explicit deny ที่ SCP/boundary อื่น). สิทธิ์จริง = intersection ของ SCP allow กับ IAM allow และต้องไม่มี explicit deny

ข้อ 3. บริษัทต้องการตั้ง multi-account landing zone ที่ปลอดภัยตาม best practice ให้เร็วที่สุด มี centralized logging และ guardrail พร้อมใช้ โดย least operational overhead ควรเลือกอะไร?

เฉลย

**AWS Control Tower** — ตั้ง landing zone สำเร็จรูป ได้ Log Archive + Audit account, org-wide CloudTrail/Config, guardrail ชุดเริ่มต้น และ Account Factory สำหรับ vend account - *Custom landing zone (DIY) ผิด:* ยืดหยุ่นกว่าแต่ overhead สูง ขัด keyword *least operational overhead* - *Organizations เปล่า ๆ ผิด:* ต้อง wire logging/guardrail เอง overhead สูงกว่า

ข้อ 4. ต้องบังคับให้ workload ห้าม provision นอก ap-southeast-1 แต่ยังต้องใช้ IAM, CloudFront, Route 53 ได้ตามปกติ SCP ควรเขียนอย่างไร?

เฉลย

ใช้ SCP `Effect: Deny` กับ condition `aws:RequestedRegion` StringNotEquals `ap-southeast-1` และใช้ **`NotAction`** ยกเว้น global service (`iam:*`, `cloudfront:*`, `route53:*`, `organizations:*`, `sts:*`, `support:*`) เพราะ global service ผูก endpoint กับ `us-east-1` — ถ้า deny แบบไม่ยกเว้นจะทำให้ IAM/CloudFront ใช้ไม่ได้ทั้ง org

ข้อ 5. ทีม security ต้องบริหาร GuardDuty และ Security Hub finding ของทุก account ใน org จากที่เดียว โดย AWS best practice ห้ามให้ทำจาก management account ควรทำอย่างไร?

เฉลย

ตั้ง **delegated administrator** ให้ Audit/Security Tooling account เป็นผู้บริหาร GuardDuty และ Security Hub ทั้ง org — team จัดการ finding จาก account เดียวโดยไม่ต้องมี credential ใน management account (ลดการใช้และ attack surface ของ management account ที่ SCP ควบคุมไม่ได้)

ข้อ 6. โจทย์ต้องการให้ทุก resource ต้องมี tag CostCenter ตั้งแต่ ตอนสร้าง มิฉะนั้นสร้างไม่ได้ ควรใช้อะไร? Tag Policy พอไหม?

เฉลย

Tag Policy **ไม่พอ** — มันตรวจ *รูปแบบ/compliance* เป็นหลัก (detective) ไม่บล็อกการสร้าง ต้องใช้ **SCP (หรือ IAM policy)** ที่ deny การ create ถ้าไม่มี tag ผ่าน condition `aws:RequestTag/CostCenter` หรือ `aws:TagKeys` (preventive). ใช้ Tag Policy ควบคู่เพื่อบังคับให้ค่าถูกต้องและรายงาน non-compliant

ข้อ 7. องค์กรมี 30 account เดิมที่ทีมสร้างเอง ต้องการรวมเข้า organization เดียวและ customize baseline เป็น code (ใช้ Terraform อยู่แล้ว) ควรใช้แนวทางใด?

เฉลย

สร้าง organization (All Features) + Control Tower แล้วใช้ **Account Factory for Terraform (AFT)** vend/customize account ผ่าน Terraform pipeline; **เชิญ (invite)** account เดิมเข้า org แล้ว **enroll** เข้า Control Tower ทีละ wave (เคลียร์ config recorder ที่ชน, ต้องมี `AWSControlTowerExecution` role) - *สร้าง account ใหม่แล้ว migrate ทั้งหมด ผิด/แพงเกิน:* overhead/downtime สูงเมื่อ account เดิมรัน production อยู่

ข้อ 8. เหตุใด AWS best practice จึงห้ามรัน production workload ใน management account?

เฉลย

เพราะ **SCP ไม่มีผลบังคับกับ management account** — workload ใน management account จึงไม่ถูก guardrail องค์กรควบคุม ทำให้เป็น attack surface ที่อันตราย นอกจากนี้ management account ถืออำนาจสูงสุด (billing, org control) การมี workload เพิ่มความเสี่ยงและ blast radius ต่อทั้ง org ควรใช้ management account ทำแค่ billing/org management และ delegate งาน security ไปยัง member account

ข้อ 9. โจทย์บอกว่าองค์กรต้อง “detect and report” resource ที่ไม่ได้เข้ารหัส ทั่วทุก account เพื่อให้ security team ดูจากที่เดียว ควรใช้อะไร?

เฉลย

ใช้ **AWS Config rules (detective)** ตรวจ encryption + ตั้ง **Config organization aggregator** ที่ Audit account เพื่อรวม compliance ทั้ง org มาที่เดียว — keyword *detect and report* ชี้ detective ไม่ใช่ preventive - *SCP ผิดสำหรับข้อนี้:* ถ้าโจทย์ขอ *prevent* ถึงใช้ SCP แต่ข้อนี้ขอ *detect/report* เท่านั้น

7. Cross-references

บทที่ 01 — Exam Blueprint & SA-Pro Mindset: บทนี้ต่อยอด keyword mapping (least operational overhead → Control Tower; prevent/block → SCP; detect/report → Config) และแนวคิด blast radius / mindset ระดับ Professional; ได้ปิด cross-reference ที่บท 01 ฝากมาเรื่องกลไก SCP allow/deny, OU hierarchy และ preventive guardrail
บทที่ 03 — Identity, Access & Federation at Scale: IAM policy evaluation logic เต็มรูปแบบ, permission boundary/session policy, IAM Identity Center (permission sets, external IdP), cross-account role — บทนี้อ้างถึงเชิงกลไก SCP × IAM เท่านั้น
บทที่ 04 — Networking at Scale: Networking account ใน Infrastructure OU (Transit Gateway, Direct Connect, shared VPC) เป็นเจ้าของรายละเอียด
บทที่ 09 — Security Architecture & Data Protection: รายละเอียดฟังก์ชัน GuardDuty/Config rules/Security Hub, KMS, defense-in-depth — บทนี้แตะเฉพาะมุม delegated admin และ guardrail
บทที่ 10 — Cost Optimization & Financial Governance: consolidated billing เชิงลึก, RI/Savings Plans sharing, Cost Categories/Budgets, cost allocation tag — บทนี้แตะเฉพาะมุม governance ของ billing
บทที่ 14 — Exam Scenarios: จะนำ decision framework “เมื่อไหร่แยก account / Control Tower vs DIY / preventive vs detective” ไปใช้กับ scenario ข้ามโดเมน