99. Cross-References & ดัชนีรวมทั้งเล่ม

ประกอบขึ้นจาก compacted context ของทั้ง 14 บท โดยอัตโนมัติหลังเขียนครบทุกบท ใช้เป็นดัชนีค้นหาข้ามบท: แผนที่การอ้างอิงระหว่างบท, อภิธานศัพท์ (นิยามอยู่บทใด), ดัชนีหัวข้อ/บริการ → บท, และบทสรุปย่อรายบทสำหรับทบทวนรอบสุดท้าย

สารบัญของหน้านี้:

ก. แผนที่ Cross-Reference ระหว่างบท
ข. อภิธานศัพท์และตัวย่อ (Glossary)
ค. ดัชนีหัวข้อ/บริการ → บท (Topic Index)
ง. บทสรุปย่อรายบท (Chapter Recaps)

ก. แผนที่ Cross-Reference ระหว่างบท

แต่ละบทเชื่อมโยงกับบทอื่นอย่างไร (forward = บทนี้อ้างไปที่ไหน, ← ถูกอ้างถึงจาก = บทใดชี้กลับมาที่บทนี้)

บทที่ 01 — Exam Blueprint & SA-Pro Mindset

อ้างอิงไปยัง:

→ บทที่ 02 — กลไก SCP (allow/deny evaluation), OU hierarchy, preventive guardrails — บทนี้อ้างถึงในตัวอย่างที่ 3 และข้อผิดพลาดเรื่อง SCP ไม่ให้สิทธิ์เอง
→ บทที่ 03 — policy evaluation logic (explicit deny > allow), federation SAML/OIDC — โยงกับ constraint ‘existing identity provider’
→ บทที่ 04 — VPC peering non-transitive (ตัวอย่าง distractor technically impossible), Transit Gateway สำหรับ scale ระดับ org
→ บทที่ 05 — decoupling ด้วย SQS/SNS/EventBridge/Step Functions ที่ใช้ในตัวอย่างที่ 2 และคำถามข้อ 6
→ บทที่ 08 — นิยาม RTO/RPO เชิงลึกและ 4 DR strategies — บทนี้ฝากไว้ว่าต้องนิยามเต็มที่บท 08 (keyword minimal downtime/no data loss)
→ บทที่ 09 — detective vs preventive controls (Config/GuardDuty vs SCP), least privilege เป็นแกน Security pillar
→ บทที่ 10 — Spot/RI/Savings Plans ที่ใช้ในตัวอย่างที่ 1 และ keyword most cost-effective
→ บทที่ 12 — 7 Rs และ constraint ‘cannot modify code’/‘lift-and-shift’ ที่ถอดจาก keyword ในบทนี้
→ บทที่ 14 — นำ keyword→pillar mapping และเทคนิคตัดตัวเลือกไปใช้กับ scenario เต็มรูปแบบ + สรุป distractor patterns ทั้งเล่ม

← ถูกอ้างถึงจาก: บทที่ 02, บทที่ 03, บทที่ 05, บทที่ 07, บทที่ 08, บทที่ 09, บทที่ 10, บทที่ 12, บทที่ 13, บทที่ 14

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

อ้างอิงไปยัง:

→ บทที่ 01 — ปิด cross-reference ที่บท 01 ฝากมาเรื่องกลไก SCP allow/deny, OU hierarchy, preventive guardrail; ต่อยอด keyword mapping และ blast radius
→ บทที่ 03 — ฝาก IAM policy evaluation logic เต็ม, permission boundary/session policy, IAM Identity Center (permission sets, external IdP), cross-account role — บท 02 แตะเฉพาะกลไก SCP × IAM
→ บทที่ 04 — Networking account ใน Infrastructure OU (Transit Gateway, Direct Connect, shared VPC) เป็นของบท 04
→ บทที่ 09 — รายละเอียดฟังก์ชัน GuardDuty/Config rules/Security Hub, KMS, defense-in-depth; บท 02 แตะเฉพาะ delegated admin และ guardrail mechanism
→ บทที่ 10 — consolidated billing เชิงลึก, RI/Savings Plans sharing, Cost Categories/Budgets, cost allocation tag; บท 02 แตะเฉพาะมุม governance
→ บทที่ 14 — decision framework ‘เมื่อไหร่แยก account / Control Tower vs DIY / preventive vs detective’ จะถูกนำไปใช้ใน scenario ข้ามโดเมน

← ถูกอ้างถึงจาก: บทที่ 01, บทที่ 03, บทที่ 04, บทที่ 06, บทที่ 08, บทที่ 09, บทที่ 10, บทที่ 11, บทที่ 12, บทที่ 14

บทที่ 03 — Identity, Access & Federation at Scale

อ้างอิงไปยัง:

→ บทที่ 02 — อ้างอิง SCP mechanics, deny list/allow list, SCP×IAM intersection, การบังคับ tag ตอนสร้างด้วย aws:RequestTag (ใช้คู่ ABAC); ไม่นิยามซ้ำ
→ บทที่ 04 — ฝาก networking สำหรับ AD hybrid (DX/VPN, DNS, SG), การแชร์ TGW/subnet ผ่าน RAM ในบริบท network, VPC peering vs TGW vs PrivateLink
→ บทที่ 05 — instance profile ในบริบท EC2/ASG และ IRSA (OIDC) สำหรับ EKS service account
→ บทที่ 09 — KMS key policy vs IAM vs grant, cross-account key usage, Secrets Manager rotation ต่อยอดหลัก ‘อย่า hardcode credential’, CloudHSM
→ บทที่ 01 — keyword mapping (existing IdP, SSO, temporary credentials, least operational overhead) และหลัก explicit deny > allow ที่บทนี้ขยายเต็ม
→ บทที่ 11 — CloudTrail audit ของ AssumeRole/federation events และ Config ตรวจ tag compliance รองรับ ABAC
→ บทที่ 12 — การย้าย workload ที่พึ่ง AD (rehost domain-joined servers) ในบริบท migration

← ถูกอ้างถึงจาก: บทที่ 01, บทที่ 02, บทที่ 04, บทที่ 05, บทที่ 06, บทที่ 09, บทที่ 11, บทที่ 12, บทที่ 14

บทที่ 04 — Networking at Scale & Hybrid Connectivity

อ้างอิงไปยัง:

→ บทที่ 05 — load balancer เต็มรูปแบบ (ALB/NLB/GWLB), target group, Auto Scaling, ECS/EKS หลัง endpoint; instance profile บน EC2 ที่ออก NAT — บท 04 แตะเฉพาะ network insertion
→ บทที่ 08 — Route 53 failover + Global Accelerator เป็น failover primitive ของ DR strategy; multi-AZ vs multi-region เป็นรากฐาน DR — บท 04 ให้เครื่องมือ networking
→ บทที่ 09 — WAF/Shield เชิงลึกที่วางบน CloudFront/ALB, Network Firewall ในบริบท defense in depth, data perimeter (endpoint policy + RCP) — บท 04 อ้างอิงเท่านั้น
→ บทที่ 11 — CloudFront cache/performance tuning, VPC Flow Logs + CloudWatch network observability, Reachability/Network Access Analyzer
→ บทที่ 02 — รับช่วง: Networking account ใน Infrastructure OU เป็นเจ้าของ TGW/DX/shared VPC; blast radius isolation ทำให้ over-consolidation VPC เดียวเป็นคำตอบผิด
→ บทที่ 03 — รับช่วง: แชร์ TGW/subnet ข้าม account ผ่าน RAM (VPC Sharing), networking สำหรับ AD hybrid (DX/VPN, SG, DNS), PrivateLink complement ของ cross-account access — ครอบคลุมครบแล้ว
→ บทที่ 12 — network cutover ตอน migration (DX/VPN hybrid), ย้าย workload ที่พึ่ง on-prem connectivity

← ถูกอ้างถึงจาก: บทที่ 01, บทที่ 02, บทที่ 03, บทที่ 05, บทที่ 06, บทที่ 07, บทที่ 08, บทที่ 09, บทที่ 10, บทที่ 11, บทที่ 12, บทที่ 14

บทที่ 05 — Compute & Application Integration

อ้างอิงไปยัง:

→ บทที่ 01 — ตอบ cross-reference เรื่อง decoupling ด้วย SQS/SNS/EventBridge/Step Functions (ตัวอย่าง 4.1, คำถามข้อ 2,6); ใช้ keyword mapping ต่อเนื่อง
→ บทที่ 03 — ตอบ cross-reference instance profile+IMDSv2 บน EC2/ASG (ผ่าน launch template), task role บน ECS, IRSA/OIDC สำหรับ EKS (ข้อ 2.7, คำถามข้อ 7)
→ บทที่ 04 — เจาะ ALB/NLB/GWLB เต็ม (บท 04 แตะเฉพาะ network insertion); PrivateLink ต้องมี NLB หน้า; GA หน้า ALB/NLB เพื่อ static IP; Lambda@Edge/CloudFront Functions บน CloudFront
→ บทที่ 06 — ฝากให้บท 06: EBS volume type สำหรับ EC2, instance store detail, S3 event trigger Lambda/EventBridge
→ บทที่ 07 — ฝากให้บท 07: การเลือก database (DynamoDB เป็น idempotency/order store, RDS Proxy connection pooling จาก Lambda)
→ บทที่ 08 — ฝากให้บท 08: DR ของ compute (multi-region failover ของ ASG/ECS/Lambda), ASG เป็น self-healing HA primitive
→ บทที่ 10 — ฝากให้บท 10: Spot strategy เชิงลึก (Spot Fleet/EC2 Fleet, capacity-optimized, interruption handling), Savings Plans สำหรับ Fargate/Lambda
→ บทที่ 11 — ฝากให้บท 11: monitoring queue depth/DLQ, X-Ray tracing event-driven, SSM Session Manager แทน bastion
→ บทที่ 13 — ฝากให้บท 13: containerization (App2Container), monolith→microservices (strangler fig), serverless refactoring pattern ที่ใช้ primitive จากบทนี้

← ถูกอ้างถึงจาก: บทที่ 01, บทที่ 03, บทที่ 04, บทที่ 06, บทที่ 07, บทที่ 08, บทที่ 10, บทที่ 11, บทที่ 13, บทที่ 14

บทที่ 06 — Storage & Data Transfer

อ้างอิงไปยัง:

→ บทที่ 05 — ตอบ cross-reference ที่บท 05 ฝากมาครบ: EBS volume type สำหรับ EC2 (2.10), instance store detail (2.12), S3 event→Lambda/EventBridge (2.9 + สถาปัตยกรรม 4.2)
→ บทที่ 07 — ฝากให้บท 07: storage layer ของ database engine (RDS/Aurora shared storage, DynamoDB) และ AWS DMS สำหรับ database migration (คู่กับ DataSync/Snow ที่บทนี้ให้สำหรับ file/object)
→ บทที่ 08 — ฝากให้บท 08: orchestration ของ backup/DR (AWS Backup policy-based, EBS snapshot + S3 CRR ในฐานะ DR primitive, RPO/RTO กำหนด replication แบบใด) — บท 06 ให้เฉพาะ primitive
→ บทที่ 09 — ฝากให้บท 09: encryption ของ EBS/S3/EFS/FSx ผ่าน KMS และ S3 encryption options เต็ม (SSE-S3/SSE-KMS/SSE-C/DSSE)
→ บทที่ 10 — ฝากให้บท 10: cost model เต็มของ storage (tiered pricing, request cost, minimum duration, egress/data transfer breakdown, S3 Storage Lens)
→ บทที่ 12 — ฝากให้บท 12: DataSync/Transfer Family/Snow ในบริบท migration wave และ 7 Rs; online vs offline decision เชื่อมกับ MGN
→ บทที่ 04 — อ้างอิงบท 04: VPC gateway endpoint สำหรับ S3/DynamoDB (ฟรี, ลด egress/NAT), Direct Connect + DataSync สำหรับ hybrid throughput, CloudFront ลด egress
→ บทที่ 02 — อ้างอิงบท 02: S3 SRR ข้าม account ไป Log Archive account, S3 encryption ที่ SCP บังคับ
→ บทที่ 03 — อ้างอิงบท 03: S3 Access Point/bucket policy (resource-based cross-account), presigned URL แทน IAM credential, FSx for Windows + Managed Microsoft AD

← ถูกอ้างถึงจาก: บทที่ 05, บทที่ 07, บทที่ 08, บทที่ 09, บทที่ 10, บทที่ 11, บทที่ 12, บทที่ 13, บทที่ 14

บทที่ 07 — Databases & Data Migration

อ้างอิงไปยัง:

→ บทที่ 05 — รับ cross-ref: DynamoDB idempotency/order store, RDS Proxy connection pooling จาก Lambda, DynamoDB Streams→Lambda event source mapping, externalize session ไป ElastiCache/DynamoDB — ครอบคลุมครบแล้ว
→ บทที่ 06 — รับ cross-ref: storage layer ของ database engine (Aurora distributed storage), S3 เป็น data lake กลาง, DMS สำหรับ DB migration คู่กับ DataSync/Snow/Transfer Family, DMS+Snowball สำหรับ DB มหาศาล — ครอบคลุมครบแล้ว
→ บทที่ 08 — ฝากไป: นิยาม RTO/RPO เต็ม, map Multi-AZ/read replica/Aurora Global Database/DynamoDB Global Tables เข้ากับ 4 DR strategies, AWS Backup cross-region สำหรับ database
→ บทที่ 09 — ฝากไป: encryption at rest ด้วย KMS, RDS Proxy + Secrets Manager rotation, IAM database authentication, Lake Formation fine-grained access เชิง security
→ บทที่ 10 — ฝากไป: DynamoDB reserved capacity vs on-demand, Aurora I/O-Optimized vs Standard, RDS Reserved Instances, Redshift RA3 cost model เชิง TCO
→ บทที่ 13 — ฝากไป: Babelfish + strangler pattern บริบท refactor ออกจาก SQL Server, decompose monolithic relational ไป purpose-built ตาม bounded context
→ บทที่ 04 — อ้างอิง: DMS replication instance network path ผ่าน DX/VPN, gateway endpoint สำหรับ DynamoDB, database subnet tier/security group
→ บทที่ 01 — อ้างอิง: keyword mapping (minimal downtime→Blue/Green+DMS CDC, no data loss→sync/Aurora, any scale→DynamoDB, least ops→serverless)

← ถูกอ้างถึงจาก: บทที่ 05, บทที่ 06, บทที่ 08, บทที่ 09, บทที่ 10, บทที่ 11, บทที่ 12, บทที่ 13, บทที่ 14

บทที่ 08 — Resilience, High Availability & Disaster Recovery

อ้างอิงไปยัง:

→ บทที่ 01 — รับ cross-ref: นิยาม RTO/RPO เต็ม + 4 DR strategies (บทนี้เป็นเจ้าของ); keyword mapping no data loss/minimal downtime/cost-effective DR
→ บทที่ 02 — blast radius isolation → fault isolation (cell/bulkhead); AWS Backup org policy เหมือนกลไก SCP; backup account แยก = Log Archive account concept
→ บทที่ 04 — รับ cross-ref: Route 53 routing/health check + Global Accelerator เป็น failover primitive ที่บทนี้ประกอบเป็น DR; DX/VPN สำหรับ DRS replication
→ บทที่ 05 — รับ cross-ref: ASG self-healing, multi-region AMI/launch template/ECR, Lambda regional, decouple SQS/SNS ลด SLA compounding
→ บทที่ 06 — รับ cross-ref: EBS snapshot cross-region + S3 CRR/RTC เป็น DR primitive; durability vs availability; Object Lock คู่ขนาน Vault Lock
→ บทที่ 07 — รับ cross-ref: Multi-AZ/read replica/Aurora Global DB/DynamoDB Global Tables map เข้า 4 DR strategies; AWS Backup cross-region สำหรับ database
→ บทที่ 09 — ฝากไป: KMS encryption ของ backup/replica (cross-region key), key policy สำหรับ cross-account backup, Vault Lock เชิง data protection
→ บทที่ 11 — ฝากไป: CloudWatch health check/alarm เชิงลึก, monitor replication lag/RPO, DR game day + AWS FIS fault injection, runbook automation ด้วย Systems Manager
→ บทที่ 12 — ฝากไป: AWS MGN สำหรับ rehost migration เต็ม — บทนี้ชี้ความต่าง MGN vs DRS ให้ชัด
→ บทที่ 14 — ฝากไป: decision framework เลือก DR strategy (RTO/RPO/cost → 1 ใน 4) เป็น flowchart หลักของบทสังเคราะห์

← ถูกอ้างถึงจาก: บทที่ 01, บทที่ 04, บทที่ 05, บทที่ 06, บทที่ 07, บทที่ 09, บทที่ 11, บทที่ 12, บทที่ 13, บทที่ 14

บทที่ 09 — Security Architecture & Data Protection

อ้างอิงไปยัง:

→ บทที่ 01 — รับ: detective vs preventive control + least privilege เป็นแกน Security pillar — ขยายเต็มเป็น preventive/detective/responsive; ใช้ keyword mapping
→ บทที่ 02 — รับ: รายละเอียด GuardDuty/Config/Security Hub/KMS/defense-in-depth ที่บท 02 ฝากมา; ต่อยอด delegated admin (Audit account), Log Archive org CloudTrail, SCP preventive layer, Firewall Manager
→ บทที่ 03 — รับ: KMS key policy(resource-based) vs IAM vs grant, cross-account KMS สองด่าน AND, Secrets Manager ต่อยอด ‘อย่า hardcode’, CloudHSM, RCP/data perimeter, IAM database auth
→ บทที่ 04 — รับ: WAF/Shield เชิงลึกบน CloudFront/ALB, Network Firewall ใน DiD, data perimeter (endpoint policy + PrincipalOrgID/SourceVpce); SG/NACL เป็น network layer
→ บทที่ 06 — รับ: S3 encryption options เต็ม (SSE-S3/SSE-KMS/SSE-C/DSSE) + Bucket Keys, EBS/EFS/FSx KMS encryption, S3 Object Lock สำหรับ evidence/immutable
→ บทที่ 07 — รับ: RDS/Aurora/DynamoDB encryption at rest KMS (RDS เปิดหลังสร้างไม่ได้ ต้อง snapshot+restore), RDS Proxy + Secrets Manager rotation, IAM database auth, Lake Formation
→ บทที่ 08 — รับ: KMS multi-region key สำหรับ backup/replica ข้าม region, key policy cross-account backup (AWS Backup principal), Vault Lock Compliance mode เป็น data protection
→ บทที่ 11 — ฝากไป: SSM Automation/Patch Manager/Session Manager เชิง operation เต็ม, CloudWatch security metric/alarm, centralized logging — บท 09 ใช้ SSM/EventBridge เป็น response primitive เท่านั้น
→ บทที่ 14 — ฝากไป: decision framework detect→service, key management→KMS/CloudHSM, secret→Secrets Manager/Parameter Store สำหรับสังเคราะห์ cross-domain scenario

← ถูกอ้างถึงจาก: บทที่ 01, บทที่ 02, บทที่ 03, บทที่ 04, บทที่ 06, บทที่ 07, บทที่ 08, บทที่ 11, บทที่ 12, บทที่ 14

บทที่ 10 — Cost Optimization & Financial Governance

อ้างอิงไปยัง:

→ บทที่ 01 — รับ cross-ref keyword most cost-effective และตัวอย่าง Spot batch มาขยายเต็ม; ใช้ Cost Optimization pillar เป็นกรอบตัดสินใจ
→ บทที่ 02 — รับ cross-ref consolidated billing (RI/SP sharing, volume tiering), cost allocation tag + Tag Policy (detective) + SCP (บล็อก), Budget Actions apply SCP, deploy Budgets ผ่าน Control Tower/StackSets
→ บทที่ 04 — อ้างอิงการลด data transfer/egress cost — gateway endpoint (ฟรี), CloudFront, cross-AZ, NAT processing cost
→ บทที่ 05 — รับ cross-ref Spot strategy เชิงลึก (allocation, Fleet, mixed instances policy, Fargate Spot) และ Savings Plans ครอบ Fargate/Lambda; Auto Scaling/scheduling เป็น demand management
→ บทที่ 06 — รับ cross-ref cost model ของ storage (storage class/lifecycle/Intelligent-Tiering/minimum duration/gp3, S3 Storage Lens); รายละเอียด storage class อยู่บท 06
→ บทที่ 07 — รับ cross-ref RDS/Redshift/ElastiCache Reserved Instances/Nodes (SP ไม่ครอบ), DynamoDB reserved capacity, Aurora I/O-Optimized
→ บทที่ 11 — ฝากไป: performance tuning และ observability เชิงลึก; Compute Optimizer มุม under-provisioned/performance และ CloudWatch metric เป็นฐาน right-sizing
→ บทที่ 14 — ฝากไป: decision framework เลือก pricing model และ cost governance เข้าเป็น flowchart สังเคราะห์ + cross-domain scenario (cost+security+networking)

← ถูกอ้างถึงจาก: บทที่ 01, บทที่ 02, บทที่ 05, บทที่ 06, บทที่ 07, บทที่ 11, บทที่ 14

บทที่ 11 — Operational Excellence, Monitoring & Continuous Improvement

อ้างอิงไปยัง:

→ บทที่ 03 — รับ pending: CloudTrail audit ของ AssumeRole/federation + Config tag compliance — ครอบใน centralized logging + auto-remediation
→ บทที่ 04 — รับ pending: VPC Flow Logs/network observability + CloudFront/RUM มุมผู้ใช้ — ครอบใน RUM + log sink; Reachability/Network Access Analyzer อ้างอิงกลับบท 04
→ บทที่ 05 — รับ pending: monitor queue depth/DLQ, X-Ray event-driven, Session Manager แทน bastion — ครอบครบ
→ บทที่ 08 — รับ pending: CloudWatch alarm เชิงลึก, replication lag/RPO monitoring, SSM runbook automation — ครอบ automation primitive; ฝาก DR game day + AWS FIS + DR strategy กลับบท 08
→ บทที่ 09 — รับ pending: SSM suite + CloudWatch security metric + centralized logging เชิง operation — ครอบครบ; ฝาก Config compliance/GuardDuty/Security Hub/CloudTrail data events detail กลับบท 09
→ บทที่ 10 — รับ pending: performance/observability เชิงลึก + Compute Optimizer มุม under-provisioned — ครอบใน 2.10; ฝาก cost optimization + Compute Optimizer มุม over-provisioned + CUR กลับบท 10
→ บทที่ 02 — อ้างอิง: Control Tower drift, StackSets ผูก Organizations, Log Archive/Audit account สำหรับ centralized observability rollout
→ บทที่ 06 — อ้างอิง: log sink S3+Athena vs OpenSearch, S3 Object Lock สำหรับ audit log WORM
→ บทที่ 07 — อ้างอิง: Contributor Insights หา hot partition key ของ DynamoDB (write sharding)
→ บทที่ 14 — ฝาก decision framework observability/deployment แบบสังเคราะห์

← ถูกอ้างถึงจาก: บทที่ 03, บทที่ 04, บทที่ 05, บทที่ 08, บทที่ 09, บทที่ 10, บทที่ 12, บทที่ 13, บทที่ 14

บทที่ 12 — Migration Strategy & Execution

อ้างอิงไปยัง:

→ บทที่ 01 — 7 Rs และ constraint lift-and-shift/cannot modify code ถอดจาก keyword; mindset Assess-before-migrate สะท้อน Pro thinking
→ บทที่ 02 — landing zone/Control Tower/OU/SCP ที่ต้องพร้อมก่อน migrate (readiness)
→ บทที่ 03 — identity/AD ในช่วง hybrid: Managed Microsoft AD + two-way trust, AD Connector สำหรับ rehosted domain-joined servers
→ บทที่ 04 — network cutover, DX/VPN hybrid connectivity, CIDR overlap, Route 53 DNS cutover
→ บทที่ 06 — DataSync/Transfer Family/Snow ในบริบท migration wave และ online vs offline decision; transfer service internals เป็นของบท 06
→ บทที่ 07 — DMS full load + CDC, SCT, homogeneous vs heterogeneous ในเฟส Migrate database tier
→ บทที่ 08 — MGN vs DRS แยกให้ขาด (migration vs DR); DNS TTL failover primitive — บทนี้ตอบ cross-ref ที่บท 08 ฝากมา
→ บทที่ 09 — security baseline (KMS/CloudTrail org trail/GuardDuty) ใน landing zone readiness
→ บทที่ 11 — CloudWatch/SSM สำหรับ operate fleet หลัง migrate; Compute Optimizer เป็น post-migration right-sizing (แยกจาก Migration Evaluator)
→ บทที่ 13 — ฝากไป: modernization pattern เชิงลึก (strangler fig ผ่าน Refactor Spaces, decomposition, App2Container, serverless refactoring); บทนี้แตะ Refactor เพียงในฐานะ 1 ใน 7 Rs
→ บทที่ 14 — ฝากไป: decision framework สังเคราะห์เลือก R, เลือก migration tool, wave planning เป็นส่วนของ cross-domain scenario

← ถูกอ้างถึงจาก: บทที่ 01, บทที่ 03, บทที่ 04, บทที่ 06, บทที่ 08, บทที่ 13, บทที่ 14

บทที่ 13 — Modernization & Refactoring

อ้างอิงไปยัง:

→ บทที่ 05 — ต่อยอด compute/integration primitive (ECS/EKS/Fargate/Lambda/EventBridge/Step Functions/API Gateway) เป็น refactor target — บทนี้ประกอบเป็น pattern ไม่ซ้ำ internals
→ บทที่ 07 — รับ cross-ref จากบท 07: Babelfish + strangler บริบท refactor ออกจาก SQL Server, decompose relational ไป purpose-built ตาม bounded context, SCT+DMS re-engine — engine detail อยู่บท 07
→ บทที่ 12 — รับ cross-ref จากบท 12: modernization pattern เชิงลึก (strangler fig ผ่าน Refactor Spaces, decomposition, A2C, serverless) ที่บท 12 แตะ Refactor เพียงในฐานะ 1 ใน 7 Rs; A2C vs MGN vs DRS
→ บทที่ 11 — อ้างอิง IaC/CI-CD, deployment strategies (blue/green/canary/linear + auto-rollback), observability/tracing สำหรับ distributed microservices
→ บทที่ 08 — เทียบ A2C/MGN vs DRS (DR ต่อเนื่อง); resilience จาก fault isolation ของ microservices
→ บทที่ 06 — S3 durability/storage class เป็นฐาน data lake; DataSync/Kinesis ingest
→ บทที่ 01 — หลัก over-engineering + keyword tie-break ในการตัดสินใจ modernize/ไม่ modernize
→ บทที่ 14 — ฝากแกนตัดสินใจ modernization path (strangler/bounded context/A2C/serverless/Babelfish/data lake/migrate-then-modernize) ให้บทสังเคราะห์

← ถูกอ้างถึงจาก: บทที่ 05, บทที่ 07, บทที่ 12, บทที่ 14

บทที่ 14 — Exam Scenarios, Decision Frameworks & Final Review

อ้างอิงไปยัง:

→ บทที่ 01 — ใช้ keyword→pillar mapping, requirement-first reading, เทคนิคตัดตัวเลือก 5 ขั้น, over/under-engineering เป็นรากฐานทุก scenario; สรุป distractor patterns ทั้งเล่ม
→ บทที่ 02 — SCP/Control Tower/preventive-detective ใน Scenario 1 และ 12
→ บทที่ 03 — cross-account AND, IAM evaluation ใน Scenario 2; identity group model
→ บทที่ 04 — Framework 3 connectivity, CIDR overlap/PrivateLink ใน Scenario 3, data perimeter endpoint ใน Scenario 8, gateway endpoint ใน ข้อ 11
→ บทที่ 05 — Framework 2 compute, fan-out ใน Scenario 4, Spot ใน Scenario 5, Step Functions ใน ข้อ 8
→ บทที่ 06 — Framework 6 storage, Object Lock ใน ข้อ 7, Snow/DataSync/Transfer
→ บทที่ 07 — Framework 1 database, Multi-AZ vs replica, Aurora Global DB, Babelfish ใน Scenario 6/10 และ ข้อ 1/3/6
→ บทที่ 08 — Framework 4 DR strategy (flowchart หลัก), RTO/RPO, DRS vs MGN, ARC ใน Scenario 6/10 และ ข้อ 10
→ บทที่ 09 — detect→service, KMS/data perimeter/Vault Lock ใน Scenario 8/12 และ ข้อ 5/7
→ บทที่ 10 — Framework 2 pricing, Savings Plans vs Spot ใน Scenario 5/10 และ ข้อ 4; ลด transfer cost ข้อ 11
→ บทที่ 11 — observability 3 เสา/X-Ray ใน Scenario 9, SSM Session Manager ใน ข้อ 9, deployment strategies
→ บทที่ 12 — Framework 5 7 Rs/MGN/wave planning ใน Scenario 7; Migration Evaluator vs Compute Optimizer
→ บทที่ 13 — strangler fig, migrate-then-modernize ใน Scenario 7 และ ข้อ 6 (Babelfish modernization angle)

← ถูกอ้างถึงจาก: บทที่ 01, บทที่ 02, บทที่ 08, บทที่ 09, บทที่ 10, บทที่ 11, บทที่ 12, บทที่ 13

ข. อภิธานศัพท์และตัวย่อ (Glossary)

รวม 250 คำ/ตัวย่อ ที่ถูกนิยามในเล่ม — ระบุว่าคำนั้น นิยามครั้งแรก ในบทใด (ค้นด้วย Ctrl+F ได้)

คำศัพท์ / ตัวย่อ	นิยามย่อ	นิยามในบท
11 nines durability	durability ที่ S3 ออกแบบไว้ 99.999999999% โดยเก็บ object ซ้ำข้ามอย่างน้อย 3 AZ (ยกเว้น One Zone) — ต่างจาก availability	บทที่ 06
3-phase migration	migration journey ของ AWS: Assess (ประเมิน+business case) → Mobilize (ปิด gap, landing zone, pilot) → Migrate & Modernize (ย้ายจริงเป็น wave)	บทที่ 12
7 Rs	กลยุทธ์การย้ายราย application 7 แบบ: Rehost (lift-and-shift), Replatform (lift-tinker-and-shift), Repurchase (drop-and-shop/SaaS), Refactor (re-architect), Retire (ปิดทิ้ง), Retain (คงไว้), Relocate (ย้ายทั้งกล่องไม่แปลง)	บทที่ 12
ABAC (Attribute-Based Access Control)	การให้สิทธิ์ตาม tag ที่ตรงกันระหว่าง principal และ resource (aws:PrincipalTag == aws:ResourceTag) เขียน policy ครั้งเดียว scale ตาม project	บทที่ 03
Account Factory	เทมเพลต Control Tower ที่ vend account ใหม่ผ่าน Service Catalog ให้เข้ามาตรฐาน landing zone ทันที	บทที่ 02
Account Factory for Terraform (AFT)	pipeline GitOps ที่ vend/customize account ผ่าน Control Tower โดยขับเคลื่อนด้วย Terraform ทำให้ customization เป็น code	บทที่ 02
ACM Private CA	managed private certificate authority สำหรับออก private/internal cert (mTLS, IoT, internal PKI) โดยไม่ต้องรัน CA infrastructure เอง	บทที่ 09
AD Connector	proxy ที่ redirect authentication ไป on-prem AD โดยไม่เก็บ user ใน AWS ใช้ reuse AD เดิมโดยไม่ replicate	บทที่ 03
Amazon Detective	บริการ root-cause investigation ที่สร้าง behavior graph จาก log ต่อยอดจาก GuardDuty finding	บทที่ 09
Amazon GuardDuty	detective service ใช้ ML+threat intel วิเคราะห์ VPC Flow/DNS/CloudTrail log (agentless) ตรวจจับ threat behavior เช่น cryptomining/C2	บทที่ 09
Amazon Inspector	บริการสแกน software vulnerability (CVE) + network exposure ของ EC2/ECR/Lambda อัตโนมัติ continuous	บทที่ 09
Amazon Macie	ML service ค้นหาและจัดประเภท sensitive data (PII/PHI/credential) ใน S3 พร้อมชี้ bucket public/unencrypted	บทที่ 09
Amazon MemoryDB for Redis	Redis-compatible in-memory database ที่ durable (Multi-AZ transaction log) ใช้เป็น primary source of truth ได้ ต่างจาก ElastiCache ที่เป็น cache	บทที่ 07
Amazon Neptune	graph database รองรับ Gremlin/openCypher/SPARQL สำหรับ relationship traversal (social/recommendation/fraud)	บทที่ 07
Amazon Timestream	time-series database purpose-built มี memory store (recent) + magnetic store (historical) tiering อัตโนมัติ query แบบ time-based	บทที่ 07
Anti-Corruption Layer (ACL)	ชั้น translation ที่คั่นระหว่าง service ใหม่กับ legacy/monolith เพื่อแปลง model/protocol ไม่ให้ model ของระบบเก่าปนเปื้อน domain model ใหม่ (นิยามในบท 13)	บทที่ 13
Application Recovery Controller (ARC)	บริการ Route 53 ที่มี readiness checks (ตรวจ standby พร้อมจริง) + routing controls (สลับ failover แบบ deterministic ผ่าน data plane 5 region) + safety rules	บทที่ 08
ASFF (AWS Security Finding Format)	รูปแบบมาตรฐานของ security finding ที่ Security Hub ใช้รวม finding จากหลาย service	บทที่ 09
Audit account (Security Tooling account)	account สำหรับ security team มี cross-account role และมักเป็น delegated administrator ของ GuardDuty/Security Hub/Config aggregator	บทที่ 02
Aurora backtrack	ฟีเจอร์ Aurora MySQL ย้อน database กลับไปจุดเวลาก่อนหน้าแบบ in-place โดยไม่ต้อง restore instance ใหม่	บทที่ 07
Aurora cloning (copy-on-write)	การสร้าง clone ของ Aurora database เกือบทันทีโดยไม่ copy ข้อมูลจริงจนกว่าจะเขียน เหมาะ test/dev จาก production	บทที่ 07
Aurora Global Database	replicate ข้าม region ที่ storage layer (สูงสุด 5 secondary) RPO<1s RTO<1min, secondary เป็น read-only จน promote — single writer	บทที่ 07
Aurora I/O-Optimized	configuration ของ Aurora ที่เหมาะเมื่อ I/O cost เกิน ~25% ของ bill (cost model ต่อยอดจากบท 07)	บทที่ 10
Aurora Replica	read replica ของ Aurora (สูงสุด 15) ที่แชร์ storage เดียวกับ writer จึง lag ต่ำมากและ promote เป็น writer ได้เร็ว (~30 วินาที)	บทที่ 07
Aurora Serverless v2	Aurora ที่ auto-scale capacity (ACU) แบบ fine-grained ตาม load รองรับ Multi-AZ/replica/Global Database (ต่างจาก v1)	บทที่ 07
Aurora shared storage (6 copies/3 AZ)	storage layer แบบ distributed ที่เก็บข้อมูล 6 copies ข้าม 3 AZ, write quorum 4/6 read 3/6, แยกจาก compute — ทำให้ replica lag ต่ำและ failover เร็ว	บทที่ 07
AWS App2Container (A2C)	CLI tool ที่วิเคราะห์ Java/.NET application ที่รันอยู่แล้วสร้าง container image + ECS task definition/EKS manifest + CloudFormation อัตโนมัติ โดยไม่ต้องแก้ source code (นิยามในบท 13)	บทที่ 13
AWS Application Discovery Service (ADS)	บริการเก็บ inventory/performance/dependency ของ on-prem server มี 2 โหมด: agentless (OVA appliance บน vCenter, VM-level) และ agent-based (ลง agent, process/network dependency ลึก)	บทที่ 12
AWS Application Migration Service (MGN)	บริการ rehost หลักของ AWS ทำ continuous block-level replication จาก source ไป staging area ราคาถูกแล้ว cutover เป็น EC2; migration ครั้งเดียว decommission source (แทน CloudEndure Migration)	บทที่ 12
AWS Artifact	portal ดาวน์โหลด compliance report/agreement ของ AWS (SOC/ISO/PCI/HIPAA BAA) สำหรับส่ง auditor	บทที่ 09
AWS Audit Manager	บริการ automate การเก็บ evidence ของ workload ลูกค้าต่อ compliance framework โดยดึงจาก Config/CloudTrail/Security Hub	บทที่ 09
AWS Backup	managed service รวมศูนย์ backup ข้ามหลายบริการด้วย backup plan (schedule/retention/vault) + cross-region/cross-account copy + org policy	บทที่ 08
AWS Budgets + Budget Actions	guardrail ตั้งเพดาน cost/usage/RI-SP coverage; Budget Actions trigger อัตโนมัติเมื่อถึง threshold เช่น apply restrictive SCP/IAM, stop EC2/RDS, ส่ง SNS	บทที่ 10
AWS Cloud Adoption Framework (CAF)	กรอบประเมินความพร้อม cloud ขององค์กรแบ่งเป็น 6 perspective (Business/People/Governance = foundational, Platform/Security/Operations = technical) ใช้ชี้ gap ก่อน migrate	บทที่ 12
AWS Cloud WAN	บริการจัดการ global network แบบ policy-driven ที่วางทับ TGW กำหนด segment/region ด้วย central policy document [uncertain รายละเอียดล่าสุด]	บทที่ 04
AWS CloudHSM	dedicated single-tenant hardware security module ที่ลูกค้าถือ key material แต่เพียงผู้เดียว AWS เข้าไม่ถึง; ใช้เมื่อ regulatory บังคับ single-tenant/FIPS L3 dedicated	บทที่ 09
AWS Cost Explorer	UI/API สำเร็จรูปดู cost trend, forecast, group ตาม service/tag/account, RI/SP utilization & coverage, right-sizing recommendation (least ops แต่ granularity จำกัดกว่า CUR)	บทที่ 10
AWS DataSync	บริการ online transfer แบบ agent-based ย้ายไฟล์จำนวนมาก (NFS/SMB/HDFS/object) ระหว่าง on-prem↔AWS หรือ AWS↔AWS พร้อม validation/incremental — จำกัดด้วย bandwidth	บทที่ 06
AWS Distro for OpenTelemetry (ADOT)	distribution ของ OpenTelemetry ที่ AWS รองรับ สำหรับ tracing/metric แบบ open standard/vendor-neutral ส่งเข้า X-Ray/CloudWatch	บทที่ 11
AWS DMS (Database Migration Service)	บริการย้าย database ด้วย full load (copy ข้อมูลเดิม) + CDC (จับการเปลี่ยนแปลงต่อเนื่อง) เพื่อ near-zero downtime migration	บทที่ 07
AWS Elastic Disaster Recovery (DRS)	บริการ DR ที่ทำ continuous block-level replication จาก source server ไป staging area ราคาถูกใน AWS; RPO วินาที RTO นาที; เดิม CloudEndure DR — ต่างจาก MGN ที่ใช้ migrate	บทที่ 08
AWS Firewall Manager	บริการจัดการ WAF/Shield Advanced/Network Firewall/SG policy ทั้ง organization จากที่เดียว auto-apply กับ resource ใหม่	บทที่ 09
AWS Global Accelerator (GA)	บริการให้ static anycast IP 2 ตัวจาก edge ทั่วโลก วิ่งบน AWS backbone ไป endpoint ทำงาน L4 (TCP/UDP) ไม่ cache failover ระดับวินาที	บทที่ 04
AWS Managed Microsoft AD	Active Directory จริงที่ AWS host เต็มรูปแบบ รองรับ trust กับ on-prem, group policy, schema extension, domain join	บทที่ 03
AWS Migration Evaluator	เครื่องมือสร้าง business case/TCO เทียบต้นทุน on-prem กับ projected AWS cost + licensing scenario (เดิม TSO Logic) ใช้ pre-migration justify to leadership	บทที่ 12
AWS Migration Hub	single pane of glass รวม discovery data และ track สถานะการย้ายข้ามเครื่องมือ/region; มี application grouping, Strategy Recommendations, Refactor Spaces	บทที่ 12
AWS Network Firewall	managed stateful/stateless firewall ระดับ VPC (built บน GWLB) ทำ deep packet inspection, IPS/IDS (Suricata), domain filtering	บทที่ 04
AWS Resilience Hub	บริการที่กำหนด RTO/RPO เป้าหมายต่อ application แล้ว assess สถาปัตยกรรมจริงว่าจะบรรลุหรือไม่ ชี้ SPOF + แนะนำแก้ + track ต่อเนื่อง	บทที่ 08
AWS Resource Access Manager (RAM)	บริการแชร์ resource (subnet, Transit Gateway, resolver rule, license) ข้าม account ภายใน/ข้าม organization โดยเจ้าของยังคุมได้	บทที่ 03
AWS SCT (Schema Conversion Tool)	เครื่องมือแปลง schema/stored procedure/code จาก source engine ไป target engine สำหรับ heterogeneous migration พร้อม assessment report	บทที่ 07
AWS Security Hub	aggregator ของ security finding หลายแหล่งในรูปแบบ ASFF + รัน compliance standard (CIS/PCI/NIST) ให้ compliance score	บทที่ 09
AWS Service Quotas	บริการดู/ขอเพิ่ม quota ของ AWS service และตั้ง CloudWatch alarm เตือนก่อนชน limit	บทที่ 11
AWS Shield Advanced	บริการ DDoS protection ระดับสูง L3/L4/L7 พร้อม DDoS Response Team, cost protection, auto WAF mitigation (ต่างจาก Shield Standard ที่ฟรีแค่ L3/L4)	บทที่ 09
AWS Transfer Family	managed SFTP/FTPS/FTP/AS2 server ที่ backend เป็น S3/EFS สำหรับ integrate partner ที่พูด protocol เหล่านี้โดยไม่บริหาร server เอง	บทที่ 06
AWS Trusted Advisor	บริการตรวจ best practice 5 หมวด (cost/performance/security/fault tolerance/service limits) รวม service limit check ที่เชื่อมกับ Service Quotas	บทที่ 11
AWS WAF	web application firewall L7 กรอง HTTP request ด้วย managed rule groups (OWASP/bot), rate-based rules, custom rules บน CloudFront/ALB/API GW	บทที่ 09
Babelfish for Aurora PostgreSQL	translation layer ที่ให้ Aurora PostgreSQL เข้าใจ SQL Server T-SQL และ TDS protocol เพื่อ migrate ออกจาก SQL Server โดยแก้ code น้อย	บทที่ 07
Backup & Restore	DR strategy ถูกสุด: backup ข้าม region แล้ว provision/restore ใหม่ตอนเกิดเหตุ; RTO ชั่วโมง-วัน	บทที่ 08
Backup Vault Lock	บังคับ WORM กับ recovery point ใน AWS Backup — Compliance mode (ลบไม่ได้แม้ root จนหมด retention) vs Governance mode (user สิทธิ์พิเศษ override ได้)	บทที่ 08
Bimodal behavior	ระบบที่ทำงานคนละแบบระหว่างโหมดปกติกับโหมดเกิดเหตุ — อันตรายเพราะ path เกิดเหตุแทบไม่เคยถูกทดสอบ; หลีกเลี่ยงโดยให้ DR region active อยู่จริง	บทที่ 08
blast radius isolation	การใช้ขอบเขต AWS account เป็น isolation ที่แข็งแรงที่สุดเพื่อกักความเสียหาย (credential รั่ว/misconfig/runaway) ไม่ให้ลามข้าม account	บทที่ 02
Bounded context	หลัก Domain-Driven Design ในการกำหนดขอบเขต microservice ตาม domain ธุรกิจที่มีความหมายชัด (Order/Payment/Inventory) แทนแตกตาม technical layer เพื่อเลี่ยง distributed monolith (นิยามในบท 13)	บทที่ 13
break-glass access	emergency role สิทธิ์สูงที่เก็บ credential ปิดผนึก ใช้เฉพาะภาวะฉุกเฉินเมื่อ identity provider ปกติล่ม พร้อม audit+alert ทุกการใช้	บทที่ 09
Bulkhead pattern	แบ่ง resource pool เป็นส่วน ๆ (connection/queue/thread ต่อ tenant) เพื่อไม่ให้ workload หนึ่งกินทรัพยากรจนกระทบทั้งหมด	บทที่ 08
BYOK (import key material)	option ของ customer managed key ที่ลูกค้า import key material ต้นทางเข้า KMS เอง (ยังอยู่บน multi-tenant KMS)	บทที่ 09
capacity provider	กลไก ECS จัดการ capacity อัตโนมัติ (Fargate/Fargate Spot/ASG) ผูก task scaling กับ capacity แบบ managed	บทที่ 05
CCoE (Cloud Center of Excellence)	ทีมกลางที่ตั้งขึ้นในเฟส Mobilize เพื่อวางมาตรฐาน/best practice/governance และปิด gap ด้าน People/Governance	บทที่ 12
CDC (Change Data Capture)	เฟสของ DMS ที่จับและ apply การเปลี่ยนแปลงที่เกิดหลัง full load เพื่อให้ target ตาม source ทันก่อน cutover	บทที่ 07
Cell-based architecture	แบ่งระบบเป็น cell อิสระหลายชุด (แต่ละ cell = full stack ให้บริการ subset ผู้ใช้) เมื่อ cell ล่มกระทบเฉพาะ 1/N ของระบบ	บทที่ 08
chargeback vs showback	chargeback = คิดเงินคืนแต่ละทีม/BU ตาม usage จริง; showback = แสดงให้เห็นว่าใครใช้เท่าไรเพื่อความโปร่งใสแต่ยังไม่คิดเงินจริง	บทที่ 10
CIDR overlap	สถานการณ์ที่สอง VPC ใช้ช่วง IP ทับกัน ทำให้ route หากันไม่ได้ผ่าน peering/TGW แก้ด้วย PrivateLink หรือ re-IP	บทที่ 04
CloudFormation change set	การ preview ว่าการ update stack จะ create/modify/delete/replace อะไรก่อน execute เพื่อกัน data loss	บทที่ 11
CloudFormation drift detection	การตรวจว่า resource ถูกแก้นอก CloudFormation (manual) จน drift จาก template หรือไม่	บทที่ 11
CloudFormation StackSets	การ deploy CloudFormation stack เดียวกันข้ามหลาย account และ region จากที่เดียว; service-managed ผูก Organizations auto-deploy ไป account ใหม่ที่ join OU	บทที่ 11
CloudFront Functions	function JavaScript เบา sub-millisecond รันที่ edge (viewer request/response) สำหรับ header/URL rewrite/redirect ถูกและ scale สูง; ต่างจาก Lambda@Edge ที่หนักกว่าและ call external ได้	บทที่ 05
CloudTrail data events	event ระดับ data plane ปริมาณสูง (S3 GetObject/PutObject, Lambda Invoke) ต้องเปิดเองมีค่าใช้จ่าย สำหรับ audit object-level access	บทที่ 09
CloudTrail Lake	managed SQL-queryable data store สำหรับ analyze CloudTrail event โดยไม่ต้อง export ไป Athena	บทที่ 09
CloudWatch anomaly detection	การสร้าง ML band รอบ metric แล้ว alarm เมื่อหลุด band แทน static threshold เหมาะ metric ที่มี seasonality	บทที่ 11
CloudWatch RUM (Real User Monitoring)	การเก็บ performance จริงจาก browser ผู้ใช้ (page load, JS error, Core Web Vitals) client-side observability	บทที่ 11
CloudWatch Synthetics canary	script (Puppeteer/Selenium) รันตามตาราง probe endpoint/flow จากภายนอกเหมือนผู้ใช้ (outside-in) วัด availability เชิง proactive	บทที่ 11
CloudWatch unified agent	agent เดียวที่เก็บทั้ง system metric (memory/disk/process) และ push log ขึ้น CloudWatch Logs รองรับ on-prem; จำเป็นเพราะ memory/disk ไม่ใช่ standard metric	บทที่ 11
Cognito identity pool	กลไกแลก token เป็น AWS temporary credential ผ่าน STS ให้ผู้ใช้แอปเข้าถึง AWS resource ตรง รองรับ guest identity	บทที่ 03
Cognito user pool	directory ผู้ใช้แอปสำหรับ sign-up/sign-in/MFA/social login ให้ผลลัพธ์เป็น JWT (authentication)	บทที่ 03
compensatory scoring	คะแนนรวมทั้งฉบับตัดสินผ่าน/ไม่ผ่าน ไม่ต้องผ่านรายทีละ domain	บทที่ 01
composite alarm	CloudWatch alarm ที่รวมหลาย metric alarm ด้วย boolean logic (AND/OR) เพื่อลด alert noise/alert fatigue	บทที่ 11
Compute Optimizer	บริการ ML แนะนำ right-sizing (EC2 type, ASG, EBS, Lambda memory) จาก CloudWatch metric ที่มีอยู่ ชี้ over/under-provisioned	บทที่ 10
Config conformance pack	ชุด Config rules + remediation ที่ deploy เป็นแพ็กเดียว (PCI/HIPAA) และ deploy ทั้ง org ได้	บทที่ 09
confused deputy	ช่องโหว่ที่ third party ที่มีสิทธิ์เข้าถึงหลายบัญชีถูกหลอกให้ใช้สิทธิ์ในบัญชีที่ไม่ใช่ของผู้เรียก แก้ด้วย external ID	บทที่ 03
Contributor Insights	CloudWatch feature วิเคราะห์ log/metric real-time หา top-N contributor เช่น top IP หรือ hot partition key ของ DynamoDB	บทที่ 11
Cost and Usage Report (CUR)	รายงาน cost ดิบละเอียดสุดระดับ line-item ต่อชั่วโมงต่อ resource ส่งเข้า S3 แล้ว query ด้วย Athena / visualize ด้วย QuickSight สำหรับ custom analysis/amortized/chargeback	บทที่ 10
Cost Anomaly Detection	บริการ ML ตรวจจับ cost spike ผิดปกติต่อ service/account/tag แล้วแจ้งเตือนอัตโนมัติโดยไม่ต้องตั้ง threshold เอง	บทที่ 10
Cost Categories	กฎ rule-based จัดกลุ่ม cost (map account+tag เป็น business unit) พร้อม split charge rule สำหรับ shared cost ใช้ใน Cost Explorer/Budgets/CUR	บทที่ 10
CRR / SRR (S3 Replication)	Cross-Region Replication (ข้าม region เพื่อ compliance/latency/DR) vs Same-Region Replication (ภายใน region เพื่อ log aggregation/cross-account); async, ต้องเปิด versioning	บทที่ 06
cutover	จังหวะสลับ traffic จริงไประบบบน AWS; ออกแบบให้ปลอดภัยด้วย test launch, ลด cutover window (sync delta), keep source รอ rollback, ลด DNS TTL	บทที่ 12
data perimeter	ขอบเขตให้เฉพาะ identity/network ที่เชื่อถือเข้าถึงเฉพาะ resource ที่เชื่อถือ ผ่าน endpoint policy + resource policy Condition (aws:PrincipalOrgID/aws:SourceVpce) + RCP เพื่อกัน data exfiltration	บทที่ 09
Database-per-service	หลักที่แต่ละ microservice เป็นเจ้าของ data store ของตัวเอง service อื่นเข้าผ่าน API เท่านั้น ทำให้ deploy/scale/เปลี่ยน schema อิสระ (นิยามในบท 13)	บทที่ 13
DAX (DynamoDB Accelerator)	in-memory cache เฉพาะ DynamoDB แบบ write-through ให้ read latency microsecond โดยไม่ต้องเขียน cache logic เอง	บทที่ 07
dead-letter queue (DLQ)	queue ปลายทางสำหรับ message ที่ประมวลผลล้มเหลวเกิน maxReceiveCount เพื่อ investigate โดยไม่ block queue หลัก	บทที่ 05
Dedicated Host	tenancy ที่ได้ physical server ทั้งเครื่อง เห็น/ควบคุม socket-core mapping รองรับ BYOL license แบบ per physical core	บทที่ 05
Defense in depth	หลักการวาง security control หลายชั้นซ้อนกัน (org/identity/network/compute/data/detection/response) เพื่อไม่ให้ชั้นเดียวเป็น single point of security failure	บทที่ 09
delegated administration	การมอบหมายการบริหารบริการ org-wide (GuardDuty/Security Hub/Config ฯลฯ) ให้ member account เฉพาะทาง แทนการทำจาก management account	บทที่ 02
deny list vs allow list (SCP strategy)	deny list = คง FullAWSAccess แล้วระบุเฉพาะที่ห้าม (ยืดหยุ่น, แนะนำ); allow list = ถอด FullAWSAccess แล้วระบุเฉพาะที่อนุญาต (เข้มแต่ดูแลยาก)	บทที่ 02
deployment strategy (in-place/blue-green/canary/linear)	รูปแบบการ deploy: in-place=อัปเดตเครื่องเดิม, blue/green=ยก env ใหม่แล้ว switch, canary=ปล่อย traffic ส่วนน้อยก่อน, linear=เพิ่ม traffic เป็นขั้นเท่า ๆ กัน	บทที่ 11
Direct Connect (DX)	สายเชื่อม dedicated ระหว่าง data center ลูกค้ากับ AWS ผ่าน DX location ให้ bandwidth คงที่ latency นิ่ง ไม่ผ่าน internet	บทที่ 04
Direct Connect Gateway (DXGW)	global resource ที่ให้ 1 สาย DX เข้าถึง VPC หลาย region และเชื่อมกับ VGW หรือ TGW ได้	บทที่ 04
distractor	ตัวเลือกลวงที่มักทำงานได้จริงแต่ไม่ตรง keyword/constraint ที่สุด	บทที่ 01
drift (Control Tower)	สภาวะที่ landing zone ไม่ตรงกับที่ Control Tower คาดหวัง เกิดจากการแก้ SCP/ย้าย account ตรงใน Organizations ต้อง re-register/repair	บทที่ 02
DX resiliency models	Maximum Resiliency (2 location + device redundant, 99.99%), High Resiliency (2 location, 99.9%), single (ไม่มี SLA production)	บทที่ 04
DynamoDB Global Tables	multi-region multi-active replication แบบ managed (เขียนได้ทุก region, last-writer-wins) เป็น DR active-active RPO ต่ำมาก	บทที่ 07
DynamoDB Streams	stream ของการเปลี่ยนแปลง item (INSERT/MODIFY/REMOVE) แบบ ordered ที่ trigger Lambda เพื่อ replication/aggregation/audit	บทที่ 07
EBS Multi-Attach	io1/io2 attach ให้สูงสุด 16 instance ใน AZ เดียวพร้อมกัน ต้องใช้ cluster-aware filesystem เอง — ไม่ใช่ shared file storage ทั่วไป	บทที่ 06
EC2 Rebalance Recommendation	สัญญาณเตือนล่วงหน้าเร็วกว่า 2-min interruption notice ว่า Spot instance เสี่ยงถูก reclaim เร็ว ๆ ให้ ASG launch replacement ก่อน	บทที่ 10
ECMP (Equal-Cost Multi-Path)	การรวมหลาย VPN tunnel บน Transit Gateway เพื่อ aggregate bandwidth เกินขีดจำกัด tunnel เดียว (ใช้ได้เฉพาะบน TGW)	บทที่ 04
EFS One Zone	EFS class ที่เก็บใน AZ เดียว ถูกกว่า Regional ~47% แต่เสี่ยง AZ loss เหมาะ dev/test หรือ data ที่ re-create ได้	บทที่ 06
EFS throughput mode	โหมด throughput ของ EFS: Elastic (auto scale, least ops), Provisioned (คงที่แยกจาก size), Bursting (legacy โตตาม size + credit)	บทที่ 06
egress cost	ค่า data-out จาก AWS สู่ internet (คิดต่อ GB; data-in ฟรี) และ cross-AZ transfer — ต้นทุนซ่อนที่ต้องออกแบบให้ลดด้วย gateway endpoint/CloudFront	บทที่ 06
egress-only Internet Gateway	gateway ที่ให้ private subnet IPv6 ออก internet ทางเดียว (คู่ขนานของ NAT Gateway สำหรับ IPv6)	บทที่ 04
Embedded Metric Format (EMF)	การ emit structured log JSON ที่ CloudWatch สกัดเป็น metric อัตโนมัติแบบ asynchronous โดยไม่ต้องเรียก PutMetricData ลด latency/throttle เหมาะ Lambda	บทที่ 11
Envelope encryption	กลไก KMS สร้าง data key เข้ารหัสข้อมูลจริงในเครื่อง (plaintext) แล้วเก็บเฉพาะ encrypted data key ข้างข้อมูล ทำให้ KMS scale กับข้อมูลขนาดใหญ่	บทที่ 09
event source mapping	กลไก Lambda ที่ poll source (SQS/Kinesis/DynamoDB Streams) แล้ว invoke function แบบ batch พร้อมจัดการ retry/checkpoint และ scale ตาม queue depth	บทที่ 05
EventBridge Pipes	point-to-point integration source→filter→enrich→target แบบ managed ลด glue code	บทที่ 05
external ID	secret string ที่ third party ต้องส่งใน sts:ExternalId ตอน AssumeRole และ trust policy บังคับด้วย Condition เพื่อกัน confused deputy	บทที่ 03
fan-out pattern	SNS topic กระจาย event เดียวไปหลาย SQS queue ให้หลาย consumer ประมวลผลอิสระพร้อม buffer/retry	บทที่ 05
Fargate	data plane แบบ serverless container (ไม่มี node ให้จัดการ) จ่ายต่อ vCPU/memory ต่อ task; คู่กับ EC2 launch type	บทที่ 05
Fast Snapshot Restore (FSR)	ฟีเจอร์ pre-initialize EBS snapshot ในแต่ละ AZ ให้ volume ที่ restore ได้ full performance ทันทีโดยไม่ต้องรอ lazy-load (มีค่าใช้จ่ายต่อ snapshot ต่อ AZ)	บทที่ 06
FSx for Lustre	managed HPC-grade parallel filesystem (throughput หลายร้อย GB/s) ที่ integrate S3 native (lazy-load + export) สำหรับ HPC/ML training	บทที่ 06
FSx for NetApp ONTAP	managed ONTAP file system รองรับ NFS+SMB+iSCSI พร้อม dedup/compression/SnapMirror สำหรับ migrate NetApp on-prem / multi-protocol	บทที่ 06
FSx for OpenZFS	managed ZFS-based NFS file system รองรับ snapshot/clone ทันที latency ต่ำ สำหรับ migrate ZFS/Linux NFS workload	บทที่ 06
FSx for Windows File Server	managed SMB file system integrate Active Directory + NTFS ACL สำหรับ Windows workload	บทที่ 06
Gateway endpoint	VPC endpoint สำหรับ S3/DynamoDB เท่านั้น ทำงานผ่าน route ชี้ prefix list; ฟรี ไม่ผ่าน internet	บทที่ 04
Gateway Load Balancer (GWLB)	load balancer L3/4 ที่ส่งทุก packet ผ่าน GENEVE encapsulation ไป fleet third-party appliance (firewall/IDS) แบบ transparent	บทที่ 05
Gateway Load Balancer endpoint (GWLBe)	endpoint ที่ส่ง traffic ไป fleet third-party appliance (firewall/IDS) ผ่าน GWLB โดยใช้ GENEVE encapsulation	บทที่ 04
gp3 (EBS)	EBS SSD general-purpose รุ่นปัจจุบันที่ provision IOPS/throughput แยกจาก capacity ได้ ถูกกว่า gp2 ~20% — default ที่แนะนำ	บทที่ 06
GSI (Global Secondary Index)	index DynamoDB ที่มี partition key ต่างจาก table ได้ สร้าง/ลบได้ทุกเมื่อ มี capacity ของตัวเอง eventually consistent	บทที่ 07
guardrails / controls (3 ประเภท)	preventive (SCP, บล็อกก่อนทำ), detective (Config rule, ตรวจหลังเกิด), proactive (CloudFormation Hooks, บล็อกตอน provision ผ่าน IaC)	บทที่ 02
high-resolution metric	CloudWatch custom metric granularity 1 วินาที (StorageResolution=1) รองรับ high-resolution alarm ประเมินทุก 10/30 วินาที สำหรับ workload ที่ต้อง react ใน sub-minute	บทที่ 11
homogeneous vs heterogeneous migration	homogeneous = engine เดิม (DMS อย่างเดียว); heterogeneous = เปลี่ยน engine ต้อง SCT แปลง schema ก่อนแล้ว DMS ย้ายข้อมูล	บทที่ 07
hot partition	ภาวะที่ throughput ของ DynamoDB กระจุกที่ partition เดียว (จาก partition key cardinality ต่ำ/access กระจุก) จน throttle แก้ด้วย high-cardinality key หรือ write sharding	บทที่ 07
idempotency	การออกแบบ consumer ให้ประมวลผล message ซ้ำแล้วผลไม่เปลี่ยน (idempotency key + conditional write) เพื่อรับมือ at-least-once delivery	บทที่ 05
Inspection VPC / centralized egress	VPC กลางที่รวม Network Firewall + NAT Gateway ให้ spoke VPC ทุกตัวออก internet/inspect ผ่านที่เดียวผ่าน TGW	บทที่ 04
instance profile	wrapper ที่ผูก IAM role เข้ากับ EC2 instance ให้ application ดึง temporary credential ผ่าน IMDS โดยไม่ต้อง hardcode key	บทที่ 03
Interface endpoint (PrivateLink)	VPC endpoint แบบ ENI มี private IP ใน subnet เข้าถึง AWS/third-party service แบบ private; มีค่าใช้จ่าย hourly + per-GB	บทที่ 04
io2 Block Express	EBS SSD provisioned IOPS ระดับสูงสุด (256k IOPS, 4000 MB/s, durability 99.999%) สำหรับ mission-critical database	บทที่ 06
IRSA (IAM Roles for Service Accounts)	กลไก EKS ที่ map Kubernetes service account เข้ากับ IAM role ผ่าน OIDC ให้แต่ละ pod ได้ credential เฉพาะ (least privilege)	บทที่ 05
Key policy	resource-based policy ที่ติดกับ KMS key เอง เป็น root of trust; ทุก key ต้องมีและถ้าไม่ allow ก็เข้าถึง key ไม่ได้เลยแม้ IAM allow	บทที่ 09
keyword บีบ (requirement signal)	คำในโจทย์ที่ชี้ pillar/แนวทางที่ต้องให้น้ำหนัก เช่น least operational overhead, most cost-effective	บทที่ 01
Kinesis Data Firehose	delivery stream แบบ fully managed ที่ buffer แล้ว load เข้า S3/Redshift/OpenSearch อัตโนมัติ (near-real-time, least ops, ไม่ต้องเขียน consumer)	บทที่ 07
KMS custom key store	KMS ที่ backed ด้วย CloudHSM cluster ของลูกค้า — KMS เป็นหน้าบ้าน integration ง่ายแต่ key material อยู่ใน CloudHSM	บทที่ 09
KMS grant	การมอบสิทธิ์ใช้ KMS key แบบชั่วคราวและ programmatic เฉพาะ operation ให้ principal/AWS service โดยไม่แก้ key policy และ revoke ได้ทันที	บทที่ 09
KMS key (CMK)	key ของ AWS KMS แบ่ง 3 ประเภท: AWS owned, AWS managed, customer managed — customer managed ควบคุม policy/rotation/audit/revoke ได้เต็ม	บทที่ 09
LAG (Link Aggregation Group)	การรวมหลาย DX connection กายภาพเป็น logical link เดียวเพื่อเพิ่ม bandwidth/redundancy (port speed และ location เดียวกัน)	บทที่ 04
landing zone	สภาพแวดล้อม multi-account ที่ปลอดภัยตาม best practice; Control Tower ตั้งให้อัตโนมัติโดยรวม Organizations+SCP+Config+CloudTrail+Identity Center	บทที่ 02
lifecycle hook	การหยุด instance ที่สถานะ Pending:Wait/Terminating:Wait เพื่อรัน custom action (bootstrap/drain) ก่อนเข้า-ออก service	บทที่ 05
Log Archive account	account แยกที่เก็บ CloudTrail/Config log ทั้ง org แบบรวมศูนย์ เพื่อให้ log พิสูจน์ได้แม้ production account ถูกเจาะ	บทที่ 02
LSI (Local Secondary Index)	index DynamoDB ที่ใช้ partition key เดียวกับ table (ต่างแค่ sort key) สร้างได้เฉพาะตอนสร้าง table รองรับ strong consistency จำกัด 10GB/partition	บทที่ 07
management account (payer account)	account ที่สร้าง organization; เจ้าของ consolidated billing และเป็นที่เดียวที่บริหาร SCP/OU; SCP ไม่มีผลบังคับกับมัน จึงห้ามรัน workload	บทที่ 02
member account	account อื่นทั้งหมดใน organization ที่อยู่ภายใต้ SCP/policy ที่ management account กำหนด	บทที่ 02
metric filter	filter ที่สแกน log ที่เข้า log group แล้วแปลง pattern (เช่นนับ ERROR) เป็น CloudWatch metric เพื่อ alarm (ต่างจาก subscription filter)	บทที่ 11
MFA Delete	control S3 ที่บังคับ MFA token ในการลบ version หรือปิด versioning เปิด/ปิดได้เฉพาะ root ผ่าน CLI	บทที่ 06
migrate then modernize	กลยุทธ์ rehost/relocate ย้ายก่อนเมื่อ deadline สั้น แล้วค่อย re-architect/modernize ทีหลังบน AWS เพื่อลดความเสี่ยง cutover (นิยามในบท 13)	บทที่ 13
Migration Hub Refactor Spaces	infrastructure สำหรับทำ strangler fig pattern (ค่อย ๆ route ไป service ใหม่); รายละเอียด refactor อยู่บท 13	บทที่ 12
Migration Readiness Assessment (MRA)	workshop ในเฟส Assess ที่ให้คะแนน readiness ตาม 6 perspective ของ CAF เพื่อชี้ gap ก่อน mobilize	บทที่ 12
minimum duration charge	ค่าเก็บขั้นต่ำของ IA/Glacier class (IA 30 วัน, Glacier 90/180 วัน) ที่ยังถูกคิดเต็มแม้ลบ object ก่อนครบ	บทที่ 06
mixed instances policy	การให้ ASG เดียวใช้หลาย instance type และผสม On-Demand+Spot ตามสัดส่วน พร้อม allocation strategy (capacity-optimized/lowest-price)	บทที่ 05
Multi-Region Access Point (MRAP)	global endpoint เดียวที่ route request ไป S3 bucket ในหลาย region ตาม latency ต่ำสุด + failover ผ่าน AWS global network	บทที่ 06
Multi-region KMS key	KMS key แบบ primary+replica ที่มี key material เดียวกันข้าม region ให้ decrypt ข้อมูลข้าม region ได้โดยไม่ต้อง re-encrypt เหมาะ DR	บทที่ 09
Multi-Site Active-Active	DR strategy แพงสุด: รันเต็มทุก region รับ traffic พร้อมกัน; RTO/RPO≈0; ซับซ้อนสุดเรื่อง data consistency	บทที่ 08
multiple response	ข้อที่เลือกหลายคำตอบ (2–3) และต้องถูกครบทุกตัวจึงได้คะแนน (no partial credit)	บทที่ 01
Object Lock (WORM)	ฟีเจอร์ S3 บังคับ Write Once Read Many — Governance mode (user สิทธิ์พิเศษ override ได้) vs Compliance mode (ไม่มีใครลบได้แม้ root จนหมด retention); ต้องเปิด versioning	บทที่ 06
OLTP vs OLAP	OLTP = transactional read/write เล็กจำนวนมาก latency ต่ำ (RDS/Aurora/DynamoDB); OLAP = analytical aggregate ข้อมูลมหาศาล (Redshift/Athena)	บทที่ 07
On-Demand Capacity Reservation (ODCR)	การจอง capacity ใน AZ เฉพาะแยกจาก billing discount ใช้คู่ Savings Plans เมื่อต้องการทั้ง capacity guarantee และความยืดหยุ่นของ SP	บทที่ 10
organization trail	CloudTrail trail เดียวจาก management account ครอบทุก account ส่งไป Log Archive account; member account ปิด/แก้ไม่ได้	บทที่ 09
Organizational Unit (OU)	คอนเทนเนอร์จัดกลุ่ม account ใน Organizations ซ้อนกันได้ (nested) และ SCP ถูก inherit ลงตามลำดับชั้น	บทที่ 02
permission boundary	guardrail ระดับ IAM identity เดี่ยว กำหนดเพดานสิทธิ์สูงสุดของ user/role นั้น ไม่ให้สิทธิ์เอง	บทที่ 03
permission set	template สิทธิ์ใน IAM Identity Center (managed policy + inline + boundary + session duration) ที่ materialize เป็น IAM role ในแต่ละ account ที่ assign	บทที่ 03
Pilot Light	DR strategy: core (database) replicate ต่อเนื่องและรันเบา, app tier ปิดไว้ scale ตอนเกิดเหตุ; RTO สิบนาที-ชั่วโมง, RPO ต่ำ	บทที่ 08
pilot migration (wave 0)	การย้าย application ตัวแทน 1-2 ตัวก่อนเพื่อ validate landing zone/runbook/tooling/estimate ก่อน scale ทั้ง portfolio	บทที่ 12
placement group (cluster/spread/partition)	การควบคุมการวาง EC2 บน hardware: cluster=rack เดียว low-latency, spread=คนละ hardware สูงสุด 7/AZ, partition=คนละ rack ต่อ partition สำหรับ distributed system	บทที่ 05
predictive scaling	ASG policy ที่ใช้ ML วิเคราะห์ history แล้ว pre-provision ก่อน load มา เหมาะ traffic cyclical/recurring	บทที่ 05
presigned URL	URL ชั่วคราวมีเวลาหมดอายุที่ให้สิทธิ์ GET/PUT object เฉพาะเจาะจงกับ S3 โดยไม่แจก IAM credential	บทที่ 06
preventive vs detective control	preventive = ป้องกัน/ห้ามทำ (SCP, IAM); detective = ตรวจจับหลังเกิด (Config, GuardDuty, CloudTrail)	บทที่ 01
provisioned concurrency	Lambda instance ที่ pre-warmed ไว้เพื่อตัด cold start (คนละเรื่องกับ reserved)	บทที่ 05
purpose-built database	ปรัชญา AWS ที่เลือก database ตรงกับ access pattern/data model ที่สุด แทนยัดทุกอย่างลง relational เดียว (one-size-fits-all เป็น anti-pattern)	บทที่ 07
RBAC (Role-Based Access Control)	การให้สิทธิ์ตาม role/หน้าที่ที่กำหนดล่วงหน้า จำนวน policy โตตาม project/team	บทที่ 03
RDS Blue/Green Deployment	สร้าง green environment sync จาก production ทำ upgrade/change แล้ว switch over ด้วย downtime ระดับวินาที พร้อม rollback (blue ยังอยู่)	บทที่ 07
RDS Multi-AZ	deployment ที่ replicate synchronous ไป standby ใน AZ อื่นเพื่อ HA/automatic failover; standby (instance mode) ไม่รับ read; RPO≈0; region เดียว	บทที่ 07
RDS Proxy	managed connection pool คั่นระหว่าง application (โดยเฉพาะ Lambda) กับ RDS/Aurora ทำ pooling/multiplexing, failover เร็วขึ้น, ดึง credential จาก Secrets Manager	บทที่ 07
read replica (RDS)	สำเนา asynchronous ที่รับ read traffic เพื่อ scale reads; ข้าม region ได้; มี replication lag (RPO>0); ต้อง promote manual	บทที่ 07
Redshift Concurrency Scaling	เพิ่ม cluster ชั่วคราวอัตโนมัติเมื่อ concurrent query พุ่งแล้วคืนเมื่อลด แก้ query queue peak โดยไม่ over-provision	บทที่ 07
Redshift RA3	Redshift node type ที่แยก compute จาก managed storage (backing S3) scale compute แยกจาก data	บทที่ 07
Redshift Spectrum	ฟีเจอร์ Redshift ที่ query ข้อมูลบน S3 โดยตรงและ join กับ warehouse โดยไม่ต้อง load	บทที่ 07
Regional vs Zonal RI	Regional RI = billing discount ทั้ง region + instance size flexibility แต่ไม่การันตี capacity; Zonal RI = ผูก AZ เดียว + การันตี capacity reservation	บทที่ 10
requirement-first reading	เทคนิคอ่านคำถาม+keyword ท้ายโจทย์ก่อน แล้วย้อนอ่าน scenario เฉพาะข้อเท็จจริงที่เกี่ยวกับ requirement	บทที่ 01
reserved concurrency	การจองเพดาน concurrency ให้ Lambda function หนึ่ง เพื่อกันแย่ง account limit และจำกัดไม่ให้ overwhelm downstream	บทที่ 05
Reserved Instance (RI) Standard vs Convertible	Standard RI ส่วนลดสูงกว่าแต่แลก family ไม่ได้/ขาย Marketplace ได้; Convertible RI ส่วนลดต่ำกว่าแต่ exchange family/OS/tenancy ได้	บทที่ 10
resource-based policy	policy ที่ติดกับตัว resource เอง (S3, SQS, KMS, Lambda) มี Principal element และให้สิทธิ์ข้าม account ได้	บทที่ 03
RI/Savings Plans sharing	ฟีเจอร์ consolidated billing ที่ commitment ซื้อใน account ใดถูกแชร์ apply ให้ทุก account ใน organization เปิด/ปิดได้จาก payer	บทที่ 10
role chaining	การ assume role หนึ่งแล้วใช้ credential นั้นไป assume อีก role; session จำกัด max 1 ชั่วโมงเสมอ	บทที่ 03
Route 53 Resolver DNS Firewall	control ระดับ DNS ที่ allow/deny query ตาม domain list (บล็อก DNS exfiltration/malware domain)	บทที่ 04
Route 53 Resolver inbound/outbound endpoint	inbound = ให้ on-prem query DNS ของ AWS; outbound + forwarding rule = ให้ VPC forward query ไป on-prem DNS (hybrid DNS)	บทที่ 04
RPO (Recovery Point Objective)	ปริมาณข้อมูล (วัดเป็นเวลา) สูงสุดที่ยอมให้สูญหาย (มองย้อนหลัง = จาก backup ล่าสุดถึงจุดเกิดเหตุ)	บทที่ 08
RTO (Recovery Time Objective)	เวลาสูงสุดที่ยอมรับได้ตั้งแต่เกิดเหตุจนระบบกลับมาให้บริการ (มองไปข้างหน้า = downtime)	บทที่ 08
S3 Access Point	endpoint แยกที่มีชื่อ+policy+network origin ของตัวเองชี้เข้า bucket เดียวกัน ลดความซับซ้อนของ bucket policy กลางเมื่อหลายทีมใช้ bucket เดียว	บทที่ 06
S3 File Gateway	Storage Gateway ที่ให้ on-prem app เขียน NFS/SMB ที่กลายเป็น S3 object พร้อม local cache ของ hot data	บทที่ 06
S3 Intelligent-Tiering	storage class ที่ย้าย object ระหว่าง tier ตาม access pattern อัตโนมัติ ไม่มี retrieval fee มี monitoring fee ต่อ object — เหมาะ access pattern ที่ไม่รู้/เปลี่ยน	บทที่ 06
S3 Replication Time Control (RTC)	SLA ว่า 99.99% ของ object ถูก replicate ภายใน 15 นาที พร้อม metric ใช้เมื่อมี compliance RPO ที่ต้องรับประกันเวลา	บทที่ 06
S3 Transfer Acceleration	ฟีเจอร์เร่ง upload ไป S3 ข้ามทวีปผ่าน CloudFront edge (จ่ายเพิ่ม) เมื่อผู้ใช้ทั่วโลก upload object ใหญ่ไป bucket ปลายทางไกล	บทที่ 06
Saga pattern	pattern จัดการ business transaction ที่ครอบหลาย microservice แบบ eventual consistency ด้วยลำดับ step + compensating action เมื่อ step ล้มเหลว มักorchestrate ด้วย Step Functions (นิยามในบท 13)	บทที่ 13
SAP-C02	รหัสข้อสอบ AWS Certified Solutions Architect – Professional เวอร์ชันปัจจุบัน	บทที่ 01
Savings Plans (SP)	commitment แบบ $ ต่อชั่วโมง 1/3 ปี แลกส่วนลด; Compute SP ครอบ EC2 ทุก region/family + Fargate + Lambda, EC2 Instance SP ครอบ family เดียว region เดียว, SageMaker SP เฉพาะ SageMaker — ไม่ครอบ database	บทที่ 10
scaled score	คะแนนช่วง 100–1000 ที่ผ่าน psychometric weighting ไม่ใช่เปอร์เซ็นต์ตรง ผ่านที่ 750	บทที่ 01
Service Control Policy (SCP)	guardrail ระดับ org/OU/account ที่กำหนดเพดานสิทธิ์สูงสุด แต่ไม่ให้สิทธิ์เอง; สิทธิ์จริง = SCP allow ∩ IAM allow และต้องไม่มี explicit deny	บทที่ 02
ServiceLens	CloudWatch feature รวม X-Ray trace + metric + log บน service map เดียว ให้ correlate จาก node ช้าไป trace ไป log	บทที่ 11
session policy	policy ที่ส่งตอน AssumeRole/GetFederationToken เพื่อ filter สิทธิ์ของ session ชั่วคราวให้แคบลง ไม่เพิ่มสิทธิ์	บทที่ 03
session tag / principal tag	attribute จาก IdP (department, project) ที่ส่งเข้ามาเป็น tag ของ session ผ่าน SAML/AssumeRole เป็นรากฐานของ ABAC	บทที่ 03
Shuffle sharding	assign แต่ละลูกค้าไป subset สุ่มของ worker ที่ทับซ้อนต่างกัน ทำให้ลูกค้าที่มีปัญหากระทบเฉพาะ shard ตน (combinatorial isolation กัน noisy neighbor)	บทที่ 08
Simple AD	Samba-based directory ราคาถูกฟีเจอร์จำกัด ไม่รองรับ trust/MFA/schema extension เหมาะ dev/test	บทที่ 03
SiteLink	ฟีเจอร์ DX ที่ให้สอง DX location คุยกันตรงผ่าน AWS global backbone โดยไม่ต้อง route ผ่าน region	บทที่ 04
SLA compounding	availability ของบริการที่ต่อกันแบบ series = คูณกัน (ลดลง) ไม่ใช่เฉลี่ย; parallel/redundant = เพิ่ม availability	บทที่ 08
Snow Family	อุปกรณ์ offline transfer: Snowcone (~8-14TB, rugged edge), Snowball Edge (~80TB, Storage/Compute Optimized), Snowmobile (exabyte [uncertain สถานะ]) — สำหรับปริมาณมหาศาลบน bandwidth จำกัด	บทที่ 06
Spot allocation strategy	วิธีเลือก Spot pool: capacity-optimized (interruption ต่ำสุด, default production), lowest-price (ถูกสุด/เสี่ยงกว่า), price-capacity-optimized (balance)	บทที่ 10
SSE-S3 / SSE-KMS / SSE-C / DSSE-KMS	4 แบบ encryption at rest ของ S3: AWS จัดการ key เต็ม / KMS key + audit / ลูกค้าถือ key ส่งทุก request / double-layer KMS	บทที่ 09
SSM Automation runbook	SSM document เป็น workflow อัตโนมัติหลายขั้นสำหรับ operational task/remediation (operations as code)	บทที่ 11
SSM OpsCenter	SSM capability รวม operational issue (OpsItem) จากหลายแหล่งเป็น central queue พร้อม contextual data และ suggested runbook	บทที่ 11
SSM Patch Manager	SSM capability นิยาม patch baseline + maintenance window patch OS/app ทั้ง fleet ตามตารางพร้อม compliance report	บทที่ 11
SSM Session Manager	SSM capability ให้ shell เข้า instance ผ่าน SSM agent โดยไม่เปิด inbound port/ไม่ต้อง bastion/SSH key พร้อม audit log ทุก session	บทที่ 11
SSM State Manager	SSM capability บังคับให้ instance คงอยู่ใน desired state ต่อเนื่องผ่าน association (เช่น agent/config นี้เสมอ)	บทที่ 11
Static stability	ออกแบบให้ระบบทำงานต่อได้โดยไม่ต้องพึ่ง control plane action ตอนเกิดเหตุ (pre-provision capacity เผื่อ) เพราะ control plane เปราะกว่า data plane ตอนวิกฤต	บทที่ 08
Step Functions Standard vs Express	Standard=long-running ถึง 1 ปี exactly-once มี history เหมาะ workflow มี audit; Express=สั้น 5 นาที throughput สูงมาก เหมาะ high-volume event pipeline	บทที่ 05
storage class (S3)	ระดับของ S3 object ที่ durability เท่ากัน (11 nines) แต่ต่างที่ availability, จำนวน AZ, minimum duration, retrieval fee และ retrieval time	บทที่ 06
Storage Gateway (4 types)	appliance hybrid on-prem: S3 File Gateway (NFS/SMB→S3), FSx File Gateway (SMB→FSx Windows), Volume Gateway (iSCSI block, Cached/Stored), Tape Gateway (VTL→Glacier)	บทที่ 06
Strangler fig pattern	การแตก monolith โดยวาง facade/proxy หน้าระบบเดิม แล้วค่อย ๆ ดึงฟังก์ชันออกเป็น service ใหม่ทีละส่วนพร้อม route traffic ไป จนแทนที่ระบบเดิมทั้งหมด — ตรงข้าม big-bang rewrite (นิยามในบท 13)	บทที่ 13
subscription filter	filter บน CloudWatch log group ที่ stream log near-real-time ไป Kinesis Data Streams/Firehose/Lambda/OpenSearch เป็นแกน centralized logging	บทที่ 11
Tag Policy	นโยบายมาตรฐาน tag ระดับ org ที่บังคับรูปแบบ key/value และรายงาน non-compliant (detective); ไม่บังคับให้ต้องมี tag ตอนสร้างด้วยตัวเอง	บทที่ 02
Tape Gateway (VTL)	Storage Gateway ที่ให้ virtual tape library ผ่าน iSCSI ให้ backup software เดิมใช้ได้ backend เก็บ S3/Glacier แทน physical tape	บทที่ 06
target tracking scaling	Auto Scaling policy ที่ตั้ง metric เป้าหมาย (เช่น CPU 50%) แล้ว ASG ปรับ capacity ให้เข้าเป้า — default ที่ least ops	บทที่ 05
TGW appliance mode	โหมด TGW ที่บังคับ symmetric routing (flow ไป-กลับผ่าน AZ เดียว) เพื่อไม่ให้ stateful firewall multi-AZ เห็นครึ่ง flow แล้ว drop	บทที่ 04
Transit Gateway (TGW)	network hub แบบ transitive ที่ VPC/VPN/DX เชื่อมเข้า แล้ว route หากันผ่าน hub; segment ด้วย TGW route table	บทที่ 04
trust policy	resource-based policy ของ IAM role ที่ระบุ Principal ว่าใครได้รับอนุญาตให้ assume role นี้	บทที่ 03
unscored questions	ข้อทดลอง (pretest) ประมาณ 10 ข้อที่ไม่นับคะแนนและไม่ระบุว่าข้อใด	บทที่ 01
Virtual Interface (VIF)	logical interface บน DX: private VIF (1 VPC ผ่าน VGW), public VIF (AWS public services), transit VIF (เข้า TGW ผ่าน DXGW)	บทที่ 04
visibility timeout	เวลาที่ SQS ซ่อน message ไม่ให้ consumer อื่นเห็นหลังถูกรับ จนกว่าจะลบหรือหมดเวลา ต้องตั้งยาวพอกับเวลาประมวลผล	บทที่ 05
VPC endpoint service (PrivateLink provider)	การ expose service หลัง NLB ให้ consumer สร้าง interface endpoint เชื่อมเข้ามาแบบ per-service one-way	บทที่ 04
VPC IP Address Manager (IPAM)	บริการจัดสรร/ติดตาม CIDR แบบไม่ทับกันทั่ว organization เป็น source of truth การวางแผน IP	บทที่ 04
VPC peering	การเชื่อม VPC สองตัวแบบ 1:1 ผ่าน AWS backbone; non-transitive และ CIDR ห้าม overlap	บทที่ 04
warm pool	pool ของ instance ที่ pre-initialized รอ ASG ดึงมาใช้ทันที เพื่อ scale-out เร็วเมื่อ boot/warm-up นาน	บทที่ 05
Warm Standby	DR strategy: full stack รัน scaled-down จริงพร้อม scale up ทันที; RTO นาที; ลด bimodal เพราะระบบมีชีวิตอยู่จริง	บทที่ 08
wave planning	การจัด application เป็นกลุ่ม (wave) ที่ย้ายพร้อมกันเป็นรอบ ตาม dependency (app ที่คุยกันแน่นอยู่ wave เดียว), complexity/risk ต่ำ→สูง, business criticality	บทที่ 12
Well-Architected Framework (WAF) 6 pillars	Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability — ใช้เป็นกรอบชั่ง trade-off	บทที่ 01
Well-Architected Review	กระบวนการประเมิน workload อย่างเป็นระบบตาม 6 pillars ด้วย Well-Architected Tool ได้ High/Medium Risk Issues + improvement plan ทำซ้ำเป็น cadence	บทที่ 11

ค. ดัชนีหัวข้อ/บริการ → บท (Topic Index)

หัวข้อและบริการหลักที่แต่ละบทครอบคลุม — ใช้หาว่าเรื่องที่ต้องการอยู่บทใด

บทที่ 01 — Exam Blueprint & SA-Pro Mindset

โครงสร้างข้อสอบ SAP-C02 (75 ข้อ, 180 นาที, ผ่าน 750/1000, scaled/compensatory scoring, unscored questions)
น้ำหนัก 4 domains และสัดส่วน
multiple choice vs multiple response (no partial credit)
การถอดรหัส keyword ในโจทย์ (least operational overhead, most cost-effective, highest availability, minimal downtime, real-time, decouple, durable ฯลฯ)
requirement-first reading
เทคนิคตัดตัวเลือก (eliminate distractors) 5 ขั้น
การจับ constraint ที่ซ่อนในโจทย์ยาว
ประเภทกับดัก/distractor patterns
Well-Architected Framework 6 pillars เป็นกรอบตัดสินใจ + design principles
Sustainability pillar
mindset Associate vs Professional
กลยุทธ์บริหารเวลา 180 นาที + flag & review
keyword→pillar→แนวคำตอบ mapping

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

ทำไมต้อง multi-account (blast radius, environment separation, billing, soft-limit/quota isolation, compliance boundary)
AWS Organizations: management/payer account vs member account, root, OU, feature sets (All Features vs Consolidated Billing only)
การออกแบบ OU hierarchy ตาม AWS best practice (Security/Infrastructure/Workloads/Sandbox/Suspended, จัดตามฟังก์ชันไม่ใช่ org chart)
Log Archive account และ Audit account
Service Control Policies (SCP): guardrail ไม่ให้สิทธิ์เอง, evaluation logic, effective permission = intersection, explicit deny ชนะ
SCP deny list vs allow list strategy
SCP ไม่มีผลกับ management account
ตัวอย่าง SCP: deny region (RequestedRegion + NotAction global services), deny root user, require S3 encryption, ห้ามปิด guardrail
AWS Control Tower: landing zone, org-wide CloudTrail/Config, guardrails 3 ประเภท (preventive=SCP / detective=Config / proactive=CloudFormation Hooks)
Account Factory และ Account Factory for Terraform (AFT)
Control Tower enroll account, drift, ความสัมพันธ์กับ Organizations
Control Tower vs custom/DIY landing zone
Tag Policies (detective; การบังคับ tag ตอนสร้างต้องใช้ SCP)
AWS Config organization aggregator
Delegated administration (GuardDuty/Security Hub/Config ที่ Audit account)
Consolidated billing มุม governance
การ migrate/invite/enroll account เข้า organization, account ย้ายข้าม org ตรงไม่ได้

บทที่ 03 — Identity, Access & Federation at Scale

IAM policy types ทั้ง 6 (identity-based, resource-based, permission boundary, session policy, SCP, RCP) และหน้าที่ต่างกัน
Policy evaluation logic เต็มรูปแบบ (implicit deny, explicit deny ชนะ, intersection guardrail ∩ union grant)
same-account (OR/union) vs cross-account (AND ทั้งสองฝั่ง) สำหรับ resource-based policy
IAM roles & AWS STS: AssumeRole, temporary credential, trust policy vs permission policy
instance profile + IMDSv2 สำหรับ EC2 workload
cross-account role, role chaining (max 1 ชม.)
external ID และ confused deputy problem
IAM Identity Center: identity source, permission set (materialize เป็น IAM role), assignment ระดับ OU, SCIM
Federation: SAML 2.0 (AssumeRoleWithSAML), OIDC/web identity (AssumeRoleWithWebIdentity), session tags/PrincipalTag
ABAC vs RBAC และ trade-off tag governance
Permission boundary สำหรับ delegated administration ที่ปลอดภัย
AWS Resource Access Manager (RAM): แชร์ subnet/TGW ข้าม account, VPC Sharing
Amazon Cognito: user pool (authentication/JWT) vs identity pool (แลก AWS temporary credential)
AWS Directory Service: Managed Microsoft AD, AD Connector, Simple AD และ hybrid two-way forest trust

บทที่ 04 — Networking at Scale & Hybrid Connectivity

VPC design & CIDR planning (RFC 1918, IPAM, overlap, 5 reserved IPs per subnet)
Subnet tiers (public/private/data), route tables, IGW, egress-only IGW
NAT Gateway vs NAT instance (HA, cost, port forwarding)
VPC peering (non-transitive, full mesh N(N-1)/2, CIDR no-overlap)
Transit Gateway (hub-spoke, TGW route tables, inter-region peering, appliance mode, RAM sharing)
AWS Cloud WAN (policy-driven global, TGW vs Cloud WAN decision) [uncertain]
VPC endpoints: gateway endpoint (S3/DynamoDB free) vs interface endpoint (PrivateLink) vs GWLB endpoint
PrivateLink endpoint service + solving CIDR overlap per-service
Direct Connect: private/public/transit VIF, DX Gateway, LAG, resiliency models (maximum/high), SiteLink
Site-to-Site VPN (2 tunnels, DX backup, ECMP on TGW, accelerated VPN)
Hybrid AD networking (DX/VPN, ports, Route 53 Resolver)
Route 53 routing policies (simple/weighted/latency/failover/geolocation/geoproximity/multivalue), health checks, private hosted zone
Route 53 Resolver inbound/outbound endpoints, forwarding rules, DNS Firewall
CloudFront vs Global Accelerator (L7 vs L4, cache vs anycast static IP)
Security Group vs NACL (stateful vs stateless, allow-only vs allow+deny, ephemeral ports)
AWS Network Firewall & centralized egress/inspection VPC architecture
Gateway Load Balancer (GENEVE) appliance insertion

บทที่ 05 — Compute & Application Integration

EC2 instance families (general/compute/memory/storage/accelerated, Graviton, T-series burstable)
Placement groups (cluster/spread/partition)
Tenancy (shared/Dedicated Instance/Dedicated Host, BYOL per-core)
Instance store vs EBS-backed (ephemeral vs persistent)
Auto Scaling policies (target tracking/step/simple/scheduled/predictive)
Lifecycle hooks, warm pools
Launch template + instance profile, mixed instances policy (On-Demand+Spot base)
Elastic Load Balancing: ALB vs NLB vs GWLB (L7 path routing vs L4 static IP/UDP vs GENEVE appliance)
Target groups, GA-หน้า-ALB สำหรับ static IP+L7
Containers: ECS vs EKS (control plane trade-off), Fargate vs EC2 launch type (data plane)
IRSA (IAM Roles for Service Accounts via OIDC), ECS task role, capacity providers, Amazon ECR
AWS Lambda: memory=CPU, cold start, reserved vs provisioned concurrency, layers, event source mapping, 15-min limit
Lambda@Edge vs CloudFront Functions
Amazon SQS (standard vs FIFO, visibility timeout, DLQ, long polling, point-to-point)
Amazon SNS (pub/sub fan-out, filter policy, FIFO, SNS→SQS)
Amazon EventBridge (event bus, content-based rules, schema registry, Pipes, Scheduler, SaaS partner events)
AWS Step Functions (Standard vs Express, service integration, retry/catch, callback pattern)
API Gateway (REST vs HTTP vs WebSocket, throttling, usage plan, authorizer)
AWS AppSync (GraphQL, real-time subscription)
Sync vs async decision, idempotency, throttling/backpressure

บทที่ 06 — Storage & Data Transfer

สามตระกูล storage: object (S3) vs block (EBS/instance store) vs file (EFS/FSx)
S3 durability 11 nines vs availability, strong read-after-write consistency, flat namespace
S3 storage classes ทั้งหมด (Standard/Intelligent-Tiering/Standard-IA/One Zone-IA/Glacier Instant/Flexible/Deep Archive) + minimum duration/retrieval
S3 lifecycle policies (transition/expire, noncurrent version, cost)
S3 versioning และ MFA Delete
S3 Object Lock (WORM) — Governance vs Compliance mode, Legal Hold
S3 Replication CRR/SRR/RTC + Batch Replication + async caveat
S3 Access Points และ Multi-Region Access Points (MRAP)
S3 Select, Requester Pays, presigned URL, S3 Event Notifications (Lambda/SQS/SNS/EventBridge)
EBS volume types (gp3/gp2/io2 Block Express/io1/st1/sc1) + IOPS/throughput decision
EBS snapshots (incremental, cross-region copy), Fast Snapshot Restore, multi-attach, encryption by default
instance store (ephemeral) use case และ trade-off
Amazon EFS: Regional vs One Zone, throughput modes (Elastic/Provisioned/Bursting), performance modes (General/Max I/O), lifecycle IA/Archive, Access Points
Amazon FSx: Windows File Server (SMB/AD), Lustre (HPC/S3), NetApp ONTAP (multi-protocol), OpenZFS — เลือกตัวไหน
AWS Storage Gateway: S3 File / FSx File / Volume (Cached/Stored) / Tape Gateway (VTL)
AWS DataSync (online bulk), Transfer Family (SFTP/FTPS/FTP), Snow Family (Snowcone/Snowball Edge/Snowmobile[uncertain])
การตัดสินใจ online vs offline transfer ตามปริมาณ/bandwidth/เวลา
egress/data transfer cost เชิงสถาปัตยกรรม (cross-AZ, gateway endpoint, CloudFront, Transfer Acceleration)

บทที่ 07 — Databases & Data Migration

แกนตัดสินใจ data model → database category (relational/key-value/in-memory/warehouse/graph/document/time-series/ledger)
OLTP vs OLAP
purpose-built database philosophy
Amazon RDS engines + managed model + RDS Custom
RDS automated backup/manual snapshot/PITR
RDS Multi-AZ vs read replica (sync vs async, HA vs scale reads, Multi-AZ DB cluster)
RDS Proxy connection pooling (Lambda)
RDS Blue/Green Deployments
Aurora shared-storage architecture (6 copies/3 AZ, quorum)
Aurora Replica, cluster/reader/custom endpoint, cloning, backtrack
Aurora Global Database (RPO/RTO cross-region)
Aurora Serverless v2
Babelfish for Aurora PostgreSQL
DynamoDB partition key design & hot partition & write sharding
DynamoDB GSI vs LSI
DynamoDB on-demand vs provisioned + auto scaling + reserved capacity
DynamoDB DAX
DynamoDB Streams
DynamoDB Global Tables (multi-active)
DynamoDB TTL & transactions
ElastiCache Redis vs Memcached, cache-aside/session/leaderboard
Amazon MemoryDB (durable in-memory primary)
Amazon Redshift RA3, Spectrum, Concurrency Scaling, Serverless
DocumentDB, Neptune, Keyspaces, Timestream
QLDB [uncertain]
AWS DMS full load + CDC
AWS SCT + homogeneous vs heterogeneous migration
DMS + Snowball for large DB
Analytics stack: Athena, Glue, Lake Formation, EMR
Kinesis Data Streams vs Firehose
data lake pattern on S3

บทที่ 08 — Resilience, High Availability & Disaster Recovery

Availability vs Resilience vs Durability (แยกสามคำ)
SLA compounding (series คูณกัน, parallel เพิ่ม availability, ลด hard dependency)
RTO & RPO นิยามเต็ม + map เข้า business/cost
4 DR strategies: Backup & Restore, Pilot Light, Warm Standby, Multi-Site Active-Active + trade-off cost/RTO/RPO
Multi-AZ (HA) vs Multi-Region (DR) และข้อจำกัด single-region
Compute resilience: ASG self-healing, multi-region AMI/launch template/ECR, Lambda regional
Data replication per service map เข้า DR (S3 CRR/RTC, Aurora Global DB, RDS cross-region replica, DynamoDB Global Tables, EBS snapshot)
AWS Backup: backup plan, cross-region/cross-account copy, org-wide backup policy, Vault Lock (Compliance/Governance)
AWS Elastic Disaster Recovery (DRS) continuous block-level replication + failback + drill
DRS vs MGN ความต่าง (DR ต่อเนื่อง vs migration ครั้งเดียว)
Route 53 failover (health check + failover routing) + DNS TTL limitation
Application Recovery Controller (ARC): readiness checks + routing controls + safety rules
Fault isolation: Bulkhead, Cell-based architecture
Shuffle sharding (กัน noisy neighbor/poison request)
Static stability + หลีกเลี่ยง bimodal behavior
AWS Resilience Hub (assess RTO/RPO ต่อ application)

บทที่ 09 — Security Architecture & Data Protection

Defense in depth เชิงสถาปัตยกรรม (layer model)
Shared responsibility model ในบริบท Pro (IaaS/managed/serverless)
AWS KMS CMK types (AWS owned/managed/customer managed)
Key policy vs IAM vs grant + cross-account KMS (สองด่าน AND)
Envelope encryption + S3 Bucket Keys
Multi-region KMS keys
KMS key rotation (auto/manual)
AWS CloudHSM vs KMS (เมื่อไหร่จำเป็น, FIPS)
Secrets Manager vs SSM Parameter Store + rotation กลไก
ACM vs ACM Private CA (mTLS/internal PKI)
Encryption at rest ทุกบริการผ่าน KMS + in transit/TLS
S3 encryption options (SSE-S3/SSE-KMS/SSE-C/DSSE-KMS)
CloudTrail (management vs data events, organization trail, Lake, log integrity)
GuardDuty threat detection (agentless, org-wide)
Security Hub (aggregation ASFF, compliance standards CIS/PCI)
Amazon Detective (behavior graph/root cause)
Amazon Macie (PII/PHI discovery ใน S3)
AWS Config (rules, conformance packs, remediation, aggregator)
Amazon Inspector (CVE vulnerability EC2/ECR/Lambda)
Automated remediation (EventBridge + SSM Automation runbook)
AWS WAF (managed rules, rate-based)
AWS Shield Standard vs Advanced (DDoS, DRT, cost protection)
AWS Firewall Manager (org-wide policy)
Data perimeter / anti-exfiltration (endpoint policy + RCP + PrincipalOrgID)
Incident response (isolation, forensics account, evidence preservation, break-glass)
Compliance: AWS Artifact vs AWS Audit Manager

บทที่ 10 — Cost Optimization & Financial Governance

Cost Optimization pillar 5 แกน (mental model)
Pricing models ภาพรวม: On-Demand vs Savings Plans vs RI vs Spot + trade-off
Reserved Instances เชิงลึก: Standard vs Convertible, Regional vs Zonal, payment options (All/Partial/No Upfront)
capacity reservation ทำได้เฉพาะ zonal RI/ODCR
Savings Plans 3 ชนิด: Compute (ครอบ EC2+Fargate+Lambda) / EC2 Instance / SageMaker
กรอบตัดสินใจ Savings Plans vs RI (flexibility vs discount) + การ combine/layer commitment
Savings Plans ไม่ครอบ RDS/Redshift/ElastiCache (ต้องใช้ Reserved Instances/Nodes แยก)
Spot Instances: 2-min notice, Rebalance Recommendation, interruption behavior
Spot allocation strategies: capacity-optimized / lowest-price / price-capacity-optimized
EC2 Fleet vs Spot Fleet vs ASG mixed instances policy
Cost visibility stack: Cost Explorer, CUR + Athena + QuickSight, Cost Anomaly Detection, S3 Storage Lens
AWS Budgets (cost/usage/RI-SP utilization/coverage) + Budget Actions + billing alarm
Cost governance multi-account: consolidated billing (RI/SP sharing, volume tiering)
cost allocation tags (user vs AWS-generated) + activation + Tag Policy/SCP enforcement
Cost Categories + chargeback vs showback + split charge
Right-sizing: AWS Compute Optimizer, Trusted Advisor cost checks
ลด data transfer/egress cost เชิงสถาปัตยกรรม (gateway endpoint, CloudFront, cross-AZ, NAT)
ลด storage cost (lifecycle, Intelligent-Tiering, gp3) อ้างอิงบท 06

บทที่ 11 — Operational Excellence, Monitoring & Continuous Improvement

Operational Excellence pillar (4 design principles, operations as code)
Performance Efficiency pillar + continuous improvement
Observability สามเสา metrics/logs/traces
CloudWatch metrics: standard/custom/high-resolution + detailed monitoring
CloudWatch unified agent (memory/disk + log push, hybrid)
Embedded Metric Format (EMF)
CloudWatch alarms: metric alarm, composite alarm, anomaly detection
CloudWatch Logs + Logs Insights
metric filter vs subscription filter
CloudWatch Synthetics canaries + RUM
Contributor Insights
CloudWatch dashboards + cross-account observability
AWS X-Ray, service map, instrumentation, ADOT/OpenTelemetry, ServiceLens
Centralized logging ข้าม account (subscription filter → Kinesis/Firehose → OpenSearch, S3+Athena sink)
AWS Systems Manager: Session Manager, Run Command, Patch Manager, State Manager, Automation runbook, OpsCenter, Parameter Store, Fleet Manager
Infrastructure as Code: CloudFormation change set/drift/nested stacks/DeletionPolicy
CloudFormation StackSets ข้าม account/region (service-managed)
AWS CDK และการเลือก IaC
CI/CD: CodePipeline/CodeBuild/CodeDeploy/CodeArtifact
Deployment strategies: in-place/blue-green/canary/linear + auto-rollback ด้วย CloudWatch alarm
Self-healing/auto-remediation: EC2 auto-recovery, EventBridge→SSM Automation, Config remediation
AWS Compute Optimizer มุม performance (under-provisioned)
AWS Trusted Advisor 5 หมวด + Service Quotas
Well-Architected Review + Well-Architected Tool (HRI/MRI)

บทที่ 12 — Migration Strategy & Execution

AWS Cloud Adoption Framework (CAF) 6 perspectives (Business/People/Governance/Platform/Security/Operations) และ organizational vs technical gap
Migration Readiness Assessment (MRA) workshop และ CCoE
3-phase migration: Assess / Mobilize / Migrate & Modernize
The 7 Rs: Rehost, Replatform, Repurchase, Refactor, Retire, Retain, Relocate — นิยาม+สัญญาณ keyword+effort
AWS Application Discovery Service (ADS) agentless (OVA/vCenter) vs agent-based (process/network dependency)
AWS Migration Hub (single pane of glass, application grouping, Strategy Recommendations, Refactor Spaces)
AWS Migration Evaluator (TCO/business case) และการแยกจาก Compute Optimizer (post-migration right-sizing)
portfolio analysis & dependency mapping
AWS Application Migration Service (MGN) rehost: replication agent, staging area, test launch, cutover, post-launch actions
MGN vs DRS distinction (migration ครั้งเดียว/decommission vs DR ต่อเนื่อง/failback)
บทบาทของ DMS/DataSync/Transfer Family/Snow ใน migration wave (อ้างบท 06/07)
VMware Cloud on AWS สำหรับ Relocate [uncertain post-Broadcom]
wave planning ตาม dependency/complexity/risk และ pilot migration (wave 0)
online vs offline bulk transfer decision + CDC/delta หลัง Snow
hybrid interim state, network cutover, DX/VPN, CIDR overlap, AD (Managed Microsoft AD trust/AD Connector) ในช่วง migration
landing zone readiness ก่อน migrate (Control Tower/identity/network/security/observability)
cutover strategies (big-bang vs phased/canary via Route 53 weighted) และ rollback (keep source, DNS TTL)

บทที่ 13 — Modernization & Refactoring

แรงจูงใจ modernize (agility/scale/cost/resilience) และเมื่อไหร่ไม่ควร modernize + migrate-then-modernize
Strangler fig pattern และ AWS Migration Hub Refactor Spaces (มุม refactor เชิงลึก)
Decomposition ตาม bounded context (DDD), database-per-service, anti-corruption layer
Cross-service data: event-driven/eventual consistency, Saga pattern (Step Functions), CQRS
Containerization path: AWS App2Container (A2C) และการเลือก orchestration ECS Fargate vs EKS vs EC2
Serverless refactoring: Lambda+API Gateway+EventBridge+Step Functions และเมื่อ serverless เหมาะ/ไม่เหมาะ
Database modernization: re-platform สู่ managed, re-engine heterogeneous, Babelfish for Aurora PostgreSQL (มุม modernization)
Data & analytics modernization: data lake บน S3 + Glue + Lake Formation + Athena, decouple ingest/process/serve
DevOps modernization: IaC/CI-CD, ลด undifferentiated heavy lifting ด้วย managed services
Deployment patterns ความเสี่ยงต่ำระหว่าง modernize: blue/green, canary, weighted routing (มุม modernization)

บทที่ 14 — Exam Scenarios, Decision Frameworks & Final Review

บทสังเคราะห์ปิดเล่ม (capstone) — ไม่มีเนื้อหาใหม่ อ้างกลับบท 01-13
ปรัชญาทำข้อสอบ Pro: keyword → constraint → framework → ตัด distractor → ตรวจ trade-off
WAF 6 pillars เป็นแกนชั่ง trade-off เมื่อ keyword ขัดกัน
รวม mental model ซ้ำจากบทก่อน (preventive/detective/responsive, identity group, connectivity, compute, LB, integration, storage, database, HA vs DR, DR strategy, MGN vs DRS, 7Rs, modernization)
Decision Framework 1: เลือก Database (flowchart + ตาราง)
Decision Framework 2: เลือก Compute
Decision Framework 3: เลือก Connectivity (peering/TGW/PrivateLink/VPN/DX)
Decision Framework 4: เลือก DR Strategy (4 กลยุทธ์)
Decision Framework 5: เลือก Migration R (7 Rs)
Decision Framework 6: เลือก Storage (object/block/file)
Scenario walkthrough 10 ข้อครอบทุก domain + cross-domain (security+networking, cost+performance, migration+resilience+cost)
Distractor patterns & traps รวมทั้งเล่ม (mindset traps, ตารางคู่สับสน 20+ คู่, กับดักเชิงบริการ)
Keyword → Service cheat sheet (lookup table สุดท้าย)
Final readiness checklist + แนวทางทบทวนวันสุดท้าย + กลยุทธ์วันสอบ
คำถามทบทวน 12 ข้อ (รวม multiple response) พร้อมเฉลยและเหตุผลตัวเลือกผิด

ง. บทสรุปย่อรายบท (Chapter Recaps)

สรุป ~200 คำต่อบท (จาก compacted context) — อ่านรวดเดียวเพื่อทบทวนทั้งเล่มก่อนสอบ

บทที่ 01 — Exam Blueprint & SA-Pro Mindset

บทที่ 01 เป็น meta-chapter วางกรอบคิดและวิธีทำข้อสอบ SAP-C02 โดยไม่ลงลึกบริการรายตัว ครอบคลุมโครงสร้างข้อสอบ (75 ข้อ = 65 นับคะแนน + 10 unscored, 180 นาที, ผ่าน 750/1000 แบบ scaled/compensatory ไม่ใช่ 75% ตรง), น้ำหนัก 4 domains (D2 29%, D1 26%, D3 25%, D4 20%), และความต่าง multiple choice vs multiple response (response = no partial credit ต้องถูกครบ). หัวใจของบทคือตาราง “keyword→pillar→แนวคำตอบ”: least operational overhead→managed/serverless, most cost-effective→Spot/tiered/Savings Plans, highest availability→Multi-AZ/Region, minimal downtime→blue-green/DMS CDC, real-time→streaming/cache, decouple→SQS/SNS/EventBridge, no data loss→RPO≈0/sync replication. สอน requirement-first reading (อ่านคำถาม+keyword ท้ายก่อน), เทคนิคตัดตัวเลือก 5 ขั้น (ตัด technically-wrong→ตัดที่ละเมิด constraint→ตัด over/under-engineered→เลือกตัวตรง keyword) สำหรับกรณี “ทุกตัวเลือกทำงานได้”, และการจับ constraint ซ่อน (ทีมเล็ก=low ops, regulated=encrypt+audit, cannot modify code=ตัด Refactor). อธิบาย WAF 6 pillars เป็น decision lens (ไม่ใช่ท่องจำ) พร้อม design principles, ชี้ว่า Sustainability สนับสนุนคำตอบเดียวกับ Cost/Performance. เน้น mindset Associate (บริการเดี่ยว/account เดียว) vs Professional (ข้าม account/region/org พร้อม trade-off, blast radius, governance). ให้ 3 ตัวอย่างวิธีวิเคราะห์โจทย์ (Spot batch, decoupled e-commerce, SCP org-wide), 10 ข้อผิดพลาดพบบ่อย (สับสน RTO/RPO, preventive vs detective, SCP ไม่ให้สิทธิ์เอง, over-engineering), และ 9 คำถามทบทวนพร้อมเฉลย. บทถัดไปควรใช้ keyword mapping และ convention

เฉลย; นิยาม RTO/RPO เต็มฝากไว้ที่บท 08, SCP mechanics ที่บท 02.

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

บทที่ 02 ครอบคลุม multi-account governance ใน Domain 1. เริ่มจาก 5 แรงผลักดันของ multi-account (blast radius, environment separation, billing, soft-limit/quota isolation, compliance boundary) โดยย้ำว่า account เป็นขอบเขต isolation แข็งที่สุด (แข็งกว่า VPC/IAM). อธิบาย AWS Organizations: management/payer vs member account, root, OU, feature set All Features vs Consolidated Billing only. การออกแบบ OU ตาม best practice (Security ที่มี Log Archive+Audit / Infrastructure / Workloads แยก Prod-NonProd / Sandbox / Suspended) จัดตามฟังก์ชันไม่ใช่ org chart. หัวใจของบทคือ SCP: เป็น guardrail ที่ไม่ให้สิทธิ์เอง, effective permission = SCP allow ∩ IAM allow และ explicit deny ชนะทุกอย่าง, deny list vs allow list, และประเด็นสำคัญที่ข้อสอบเจาะ—SCP ไม่มีผลกับ management account จึงห้ามรัน workload ที่นั่น. ให้ตัวอย่าง SCP JSON 4 แบบ (deny region ด้วย RequestedRegion+NotAction ยกเว้น global service, deny root user, require S3 encryption, ห้ามปิด CloudTrail/Config/GuardDuty). Control Tower: landing zone สำเร็จรูป, guardrails 3 ประเภท (preventive=SCP / detective=Config / proactive=CloudFormation Hooks), Account Factory, AFT (Terraform), enroll+drift. Governance เสริม: Tag Policy (detective—บังคับ tag ตอนสร้างต้องใช้ SCP), Config organization aggregator, delegated administration (GuardDuty/Security Hub ที่ Audit account), consolidated billing มุม governance. รวมถึงการ invite+enroll account เดิม (account ย้ายข้าม org ตรงไม่ได้). มี 3 สถาปัตยกรรมพร้อม trade-off, 11 ข้อผิดพลาด, 9 คำถามทบทวน. keyword ที่บทถัดไปควรใช้ต่อ: prevent/block→SCP, detect/report→Config, least operational overhead→Control Tower. บทถัดไป (03) รับช่วง IAM evaluation logic เต็ม, permission boundary, Identity Center, cross-account role ที่บทนี้แตะเพียงกลไก SCP×IAM.

บทที่ 03 — Identity, Access & Federation at Scale

บทที่ 03 ครอบคลุม identity/access/federation ระดับ scale ใน Domain 1 รับช่วงจากบท 02 (SCP guardrail) มาสู่ “สิทธิ์จริงของ principal”. แกนหลัก: IAM policy 6 ชนิด แยก grant (identity-based, resource-based เท่านั้นที่ให้สิทธิ์) vs guardrail (permission boundary, session policy, SCP, RCP ที่หั่นสิทธิ์ ไม่เพิ่ม). Evaluation logic เต็ม: default implicit deny → explicit deny ชนะทุกอย่าง → intersection ของ guardrail ∩ union ของ grant. จุดออกสอบสำคัญ: same-account = identity OR resource policy (union), cross-account = ต้องผ่านทั้งสองฝั่ง (AND) — S3 cross-account เปิด bucket policy อย่างเดียวไม่พอ. IAM role/STS: temporary credential, trust vs permission policy, instance profile+IMDSv2 (คำตอบมาตรฐาน EC2 access S3), role chaining จำกัด 1 ชม., external ID กัน confused deputy สำหรับ third-party. IAM Identity Center = workforce SSO multi-account (permission set materialize เป็น IAM role, assign ระดับ OU, external IdP ผ่าน SAML+SCIM) = least ops. Federation SAML (AssumeRoleWithSAML) vs OIDC/web identity (AssumeRoleWithWebIdentity), session tag → ABAC. ABAC vs RBAC: ABAC scale ดี policy คงที่แต่พึ่ง tag governance 100%. Permission boundary = safe delegated administration. RAM แชร์ subnet/TGW ข้าม account. Cognito: user pool (authentication/JWT) vs identity pool (แลก AWS credential) — เป็น customer identity ต่างจาก Identity Center (workforce). Directory Service: Managed Microsoft AD (AD จริง+trust), AD Connector (proxy ไม่ replicate), Simple AD (dev/test). มี 4 สถาปัตยกรรม, 12 ข้อผิดพลาด, 9 คำถาม. บทถัดไปควรรู้: networking สำหรับ AD hybrid และการแชร์ RAM/TGW → บท 04; KMS/Secrets → บท 09; instance profile/IRSA → บท 05. keyword: existing IdP/SSO→Identity Center, third-party access→cross-account role+external ID, app users→Cognito, corporate AD→Directory Service.

บทที่ 04 — Networking at Scale & Hybrid Connectivity

บทที่ 04 ครอบคลุม networking ระดับ scale และ hybrid (Domain 1&2) รับช่วง cross-reference จากบท 02/03 ครบ (Networking account ใน Infrastructure OU เป็นเจ้าของ TGW/DX/shared VPC, แชร์ TGW/subnet ผ่าน RAM, networking สำหรับ AD hybrid, peering vs TGW vs PrivateLink). แกนหลัก: (1) VPC/CIDR planning — วางแผน CIDR ทั้ง org ก่อนสร้าง VPC เพราะ overlap แก้ย้อนหลังไม่ได้, ใช้ IPAM, subnet ผูก AZ เดียว, 5 IP สงวนต่อ subnet, NAT Gateway (managed, HA ต่อ AZ) vs NAT instance. (2) การเชื่อม VPC เป็นหัวใจออกสอบ: peering (non-transitive, full mesh ไม่ scale, CIDR ห้าม overlap) vs Transit Gateway (transitive hub, TGW route table ทำ segmentation, inter-region peering, appliance mode สำหรับ stateful inspection multi-AZ) vs Cloud WAN (global policy-driven [uncertain]). (3) VPC endpoints: gateway endpoint (S3/DynamoDB ฟรี) vs interface endpoint/PrivateLink (มี ENI, มีค่าใช้จ่าย) vs GWLBe; PrivateLink แก้ CIDR overlap แบบ per-service. (4) Hybrid: Direct Connect (private/public/transit VIF, DXGW, LAG, resiliency maximum/high, SiteLink) + Site-to-Site VPN เป็น backup (2 tunnel, ECMP บน TGW, accelerated VPN). (5) DNS: Route 53 routing policies 7 แบบ + health check + private hosted zone + Route 53 Resolver inbound/outbound + DNS Firewall. (6) Edge: CloudFront (L7/cache) vs Global Accelerator (L4/static anycast IP/non-HTTP/fast failover). (7) Security: SG (stateful/allow-only) vs NACL (stateless/allow+deny/ephemeral ports), Network Firewall, centralized inspection/egress VPC. มี 4 สถาปัตยกรรม (TGW hub+central egress, PrivateLink แก้ overlap, GA active-passive DR, hybrid DNS+AD), 14 ข้อผิดพลาด, 10 คำถาม. บทถัดไป: บท 05 รับช่วง load balancer เต็ม (ALB/NLB/GWLB), compute หลัง endpoint; บท 08 ใช้ Route 53/GA failover เป็น DR primitive; บท 09 รับ WAF/Shield/data perimeter เชิงลึก; บท 11 รับ CloudFront tuning + Flow Logs.

บทที่ 05 — Compute & Application Integration

บทที่ 05 ครอบคลุม Compute & Application Integration (Domain 2, น้ำหนักสูงสุด) เน้นการ “เลือกใช้” เชิงสถาปัตยกรรมพร้อม trade-off. EC2: instance families (Graviton price/performance, T-series burstable trap), placement groups (cluster/spread/partition), tenancy (Dedicated Host สำหรับ BYOL per-core), instance store (ephemeral) vs EBS. Auto Scaling: target tracking (default least-ops), predictive (cyclical), scheduled (รู้เวลาแน่นอน), step/simple, lifecycle hooks, warm pools, launch template+instance profile, mixed instances policy (On-Demand base+Spot). ELB: ALB (L7 path/host+WAF/Cognito) vs NLB (L4 static IP/UDP/preserve source IP/PrivateLink provider) vs GWLB (appliance insertion); GA หน้า ALB เมื่อต้อง static IP+L7. Containers: ECS (least-ops) vs EKS (k8s portability, IRSA/OIDC), Fargate (serverless data plane) vs EC2 launch type, capacity providers, ECR. Lambda: memory=CPU (เร่ง CPU-bound), cold start→provisioned concurrency, reserved concurrency (จำกัด/protect downstream), event source mapping, 15-min limit; Lambda@Edge vs CloudFront Functions. Integration: SQS (buffer/point-to-point, standard vs FIFO, visibility timeout, DLQ), SNS (fan-out push→SQS), EventBridge (content routing + AWS/SaaS events + Pipes), Step Functions (Standard long-running/audit vs Express high-volume), API Gateway (REST vs HTTP vs WebSocket, usage plan), AppSync (GraphQL+real-time). Sync vs async, idempotency (at-least-once), throttling. มี 4 สถาปัตยกรรม (SNS→SQS fan-out order processing, ALB+Fargate microservice, Step Functions+Fargate pipeline, GA+NLB ingestion), 14 ข้อผิดพลาด, 11 คำถาม. ตอบ cross-reference จากบท 01/03/04 ครบ. บทถัดไป: บท 06 รับ EBS/S3 detail, บท 07 รับ database, บท 08 รับ DR compute, บท 10 รับ Spot/Savings Plans เชิงลึก. แกนตัดสินใจที่วางไว้ให้บทหลังใช้ต่อ: compute (Lambda/Fargate/EKS/EC2), LB (ALB/NLB/GWLB), integration (SQS/SNS/EventBridge/Step Functions).

บทที่ 06 — Storage & Data Transfer

บทที่ 06 ครอบคลุม Storage & Data Transfer (Domain 2&4) วางแกนตัดสินใจแรกคือสามตระกูล: object (S3) vs block (EBS/instance store) vs file (EFS/FSx) ซึ่งตัด distractor ได้ครึ่งข้อ. S3: durability 11 nines (แยกจาก availability), strong read-after-write, storage classes ครบ 7 แบบพร้อม minimum duration/retrieval fee — Intelligent-Tiering เป็นคำตอบเมื่อ access pattern ไม่แน่นอน (ไม่มี retrieval fee, least ops), Deep Archive ถูกสุด. ครอบ lifecycle, versioning, MFA Delete, Object Lock (Compliance mode = immutable แม้ root สำหรับ regulatory), Replication CRR/SRR/RTC (async, ต้อง Batch สำหรับ object เก่า), Access Points/MRAP, Select, Requester Pays, presigned URL, และ S3 event→Lambda/EventBridge (ตอบ cross-ref บท 05). EBS: gp3 เป็น default (provision IOPS แยก size), io2 Block Express สำหรับ critical DB, st1 สำหรับ sequential throughput; snapshot incremental, FSR, multi-attach (cluster-aware FS ไม่ใช่ shared file), encryption. instance store = ephemeral cache/scratch. EFS = NFS/Linux multi-AZ elastic. FSx สี่ตัว (Windows/SMB+AD, Lustre HPC+S3, ONTAP multi-protocol, OpenZFS). Hybrid: Storage Gateway 4 ประเภท (S3 File/FSx File/Volume/Tape). Transfer: DataSync (online bulk), Transfer Family (SFTP endpoint external), Snow (offline PB/limited bandwidth); กฎ online vs offline คำนวณเวลาจาก bandwidth. egress cost (gateway endpoint ฟรี, CloudFront ลด egress). บทถัดไปควรรู้: database storage→บท07, backup/DR orchestration→บท08 (บทนี้ให้แค่ snapshot/replication primitive), encryption/KMS→บท09, cost model เต็ม→บท10, migration wave→บท12. ยึด convention

เฉลย

+ bullet ‘ทำไมตัวเลือกอื่นผิด’.

บทที่ 07 — Databases & Data Migration

บทที่ 07 ครอบคลุม Databases & Data Migration (Domain 2&4) วางแกนตัดสินใจแรก: data model → database category (relational RDS/Aurora, key-value DynamoDB, in-memory ElastiCache/MemoryDB, warehouse Redshift, graph Neptune, document DocumentDB, wide-column Keyspaces, time-series Timestream, ledger QLDB[uncertain]) พร้อมแยก OLTP vs OLAP และปรัชญา purpose-built (ไม่ยัดทุกอย่างลง relational). RDS: engines, PITR/backup, RDS Custom; หัวใจออกสอบคือ Multi-AZ (sync, HA, RPO≈0, standby ไม่รับ read) vs read replica (async, scale reads, cross-region); RDS Proxy แก้ Lambda connection exhaustion (cross-ref บท05); Blue/Green สำหรับ upgrade minimal downtime. Aurora: shared storage 6 copies/3AZ quorum, Aurora Replica (promote เร็ว), Global Database (RPO<1s RTO<1min single-writer), Serverless v2, cloning/backtrack, Babelfish (SQL Server T-SQL→PostgreSQL, ฝากบท13). DynamoDB: partition key design & hot partition/write sharding, GSI (เพิ่มภายหลังได้) vs LSI (ตอนสร้างเท่านั้น), on-demand vs provisioned, DAX (microsecond, no code), Streams, Global Tables (multi-active — ต่างจาก Aurora single-writer), TTL, transactions, idempotency store (cross-ref บท05). ElastiCache Redis vs Memcached; MemoryDB (durable primary in-memory). Redshift RA3/Spectrum/Concurrency Scaling. Migration: DMS full load + CDC = near-zero downtime; homogeneous (DMS อย่างเดียว) vs heterogeneous (SCT แปลง schema ก่อน + DMS); DMS+Snowball. Analytics: Athena (query S3 SQL serverless), Glue (ETL+catalog), Lake Formation (governance), EMR, Kinesis Data Streams vs Firehose, data lake บน S3 (cross-ref บท06). 14 ข้อผิดพลาด, 10 คำถาม. บทถัดไป (08) ต้องนิยาม RTO/RPO เต็มและ map primitive เหล่านี้เข้ากับ 4 DR strategies; encryption/Secrets → บท09; cost model → บท10; modernization → บท13. ~4,600 คำ.

บทที่ 08 — Resilience, High Availability & Disaster Recovery

บทที่ 08 ครอบคลุม Resilience, HA & DR (Domain 2&3) เป็นเจ้าของนิยาม RTO/RPO เต็มที่บทก่อนฝากไว้. เริ่มแยกสามคำ availability (uptime) vs durability (data ไม่หาย) vs resilience (ฟื้นตัว) และ SLA compounding (series คูณกันลด availability → ลด hard dependency, decouple). หัวใจคือ 4 DR strategies เรียงตาม cost/RTO/RPO: Backup & Restore (ถูก/ช้า) < Pilot Light (database replicate สด, app ปิดรอ) < Warm Standby (full stack scaled-down) < Multi-Site Active-Active (แพง/RTO≈0). แกนตัดสินใจซ้ำ: Multi-AZ = HA ระดับ AZ (sync/RPO≈0) vs Multi-Region = DR ระดับ region (async). Data replication map เข้า DR: S3 CRR/RTC, Aurora Global DB (single-writer RPO<1s), DynamoDB Global Tables (multi-active), EBS snapshot copy. AWS Backup = centralized orchestration + cross-region/account copy + org policy + Vault Lock (Compliance mode = WORM กัน ransomware). DRS = continuous block-level replication สำหรับ DR (RPO วินาที) — ต่างจาก MGN ที่ migrate ครั้งเดียว (จุดหลอกสำคัญ). Failover: Route 53 health check + failover routing (ติด DNS TTL) → Global Accelerator/ARC เร็วกว่า; ARC = readiness checks + routing controls + safety rules สำหรับ deterministic failover. Fault isolation: bulkhead, cell-based (blast radius 1/N), shuffle sharding (กัน poison request ด้วย combinatorial), static stability (pre-provision กันพึ่ง control plane) + หลีกเลี่ยง bimodal (DR path ไม่เคยทดสอบ). Resilience Hub = assess RTO/RPO ต่อ architecture. บทถัดไปควรรู้: KMS สำหรับ encrypt backup/replica → บท 09; monitoring/FIS/DR drill → บท 11; MGN เต็ม → บท 12; decision framework DR → บท 14. ~4,300 คำ, ยึด convention

เฉลย + bullet ทำไมตัวเลือกอื่นผิด.

บทที่ 09 — Security Architecture & Data Protection

บทที่ 09 ครอบคลุม Security Architecture & Data Protection (Domain 1,2,3) เป็นเจ้าของ Security pillar เชิงลึก รับ cross-ref จำนวนมากจากบทก่อน. แกนหลัก: (1) Defense in depth หลายชั้น (org/identity/network/compute/data/detection/response) + shared responsibility ที่เลื่อนตามระดับ managed (IaaS→serverless). (2) AWS KMS หัวใจ: CMK 3 ประเภท (AWS owned/managed/customer managed) — customer managed เท่านั้นที่ควบคุม policy/rotate/audit/revoke ได้; key policy(root of trust) vs IAM(ต้อง delegate) vs grant; cross-account KMS ต้องผ่านสองด่าน (key policy AND IAM); envelope encryption+Bucket Keys; multi-region key สำหรับ DR; automatic rotation โปร่งใส; CloudHSM เฉพาะเมื่อ single-tenant/FIPS L3/AWS-no-access. (3) Secrets Manager (native rotation) vs Parameter Store (ฟรี ไม่มี rotation); ACM public(auto-renew, export ไม่ได้) vs ACM Private CA(mTLS/internal PKI). (4) Data protection: encryption at rest ทุกบริการผ่าน KMS (RDS เปิดหลังสร้างไม่ได้ ต้อง snapshot+restore), S3 4 แบบ (SSE-S3/KMS/C/DSSE). (5) Detective แยกให้ขาด: GuardDuty(threat,agentless), Inspector(CVE), Macie(PII ใน S3), Config(config compliance+remediation), Security Hub(aggregation+CIS/PCI score), Detective(root cause), CloudTrail(org trail+data events+Lake). (6) Perimeter: WAF(managed+rate-based), Shield Std vs Advanced(DDoS+DRT+cost protection), Firewall Manager(org-wide). (7) Automated remediation pattern: finding→EventBridge→SSM Automation. (8) Incident response: isolation(SG deny)+snapshot ก่อน terminate, forensics account, break-glass. (9) Compliance: Artifact(report ของ AWS) vs Audit Manager(evidence ของลูกค้า). บทถัดไป: บท 11 รับ SSM/CloudWatch/logging เชิง operation เต็ม; บท 14 รับ decision framework detect→service. ยึด convention

เฉลย + bullet ‘ทำไมตัวเลือกอื่นผิด’ และตาราง requirement→service→trade-off.

บทที่ 10 — Cost Optimization & Financial Governance

บทที่ 10 ครอบคลุม Cost Optimization & Financial Governance (Domain 3) เป็นเจ้าของ Cost Optimization pillar. วางแกน mental model 5 ด้าน (FinOps/awareness/cost-effective resources/manage demand/optimize over time). หัวใจคือ pricing models 4 กลุ่มและ trade-off: On-Demand (spiky/unpredictable) < Spot (fault-tolerant ~90% off) กับ commitment แลกส่วนลดระยะยาว — Savings Plans vs RI. RI แยก Standard vs Convertible (exchange family), Regional (billing discount + size flexibility, ไม่การันตี capacity) vs Zonal (การันตี capacity), payment options (All/Partial/No Upfront). Savings Plans 3 ชนิด: Compute SP (ครอบ EC2+Fargate+Lambda ยืดหยุ่นสุด = default modern), EC2 Instance SP (family+region เดียว ส่วนลดสูงกว่า), SageMaker SP. จุดหลอกสำคัญ: SP ไม่ครอบ RDS/Redshift/ElastiCache (ต้อง Reserved Instances/Nodes แยก) และ SP/regional RI ไม่การันตี capacity (ต้อง zonal RI/ODCR). Spot: 2-min notice + Rebalance Recommendation, allocation capacity-optimized (production) vs lowest-price (batch), ใช้ผ่าน ASG mixed instances policy. Visibility stack แยกบทบาท: Cost Explorer (dashboard สำเร็จรูป) vs CUR+Athena+QuickSight (custom/amortized/chargeback line-item) vs Cost Anomaly Detection (ML spike) vs Budgets+Budget Actions (guardrail หยุด/เตือน apply SCP) vs Compute Optimizer (ML right-sizing) vs Trusted Advisor. Multi-account governance: consolidated billing (RI/SP sharing ข้าม account + volume tiering), cost allocation tag (activate ก่อน + Tag Policy detective + SCP บล็อก), Cost Categories/split charge, chargeback vs showback. ลด data transfer (gateway endpoint ฟรี/CloudFront) และ storage cost (อ้างบท 06). มี 3 สถาปัตยกรรม (layered commitment portfolio, sandbox financial guardrail, CUR chargeback), 14 ข้อผิดพลาด, 10 คำถาม. ~4,350 คำ. บทถัดไป (11) รับ performance/observability; Compute Optimizer มุม performance และ CloudWatch metric; บท 14 รับ decision framework สังเคราะห์. ยึด convention details เฉลย + bullet ทำไมตัวเลือกอื่นผิด.

บทที่ 11 — Operational Excellence, Monitoring & Continuous Improvement

บทที่ 11 ครอบคลุม Operational Excellence & Performance Efficiency pillars (Domain 3) เน้น “ระบบรันอยู่แล้ว จะ observe/operate/automate/improve อย่าง least operational overhead” วางแกน operations-as-code (manual/console มักเป็นคำตอบผิด) และ observability สามเสา: metrics (alarm/trend) vs logs (forensics) vs traces (distributed bottleneck) เป็น mental model ตัด distractor. CloudWatch เชิงลึก: standard/custom/high-resolution metric (memory/disk ต้องใช้ unified agent — จุดหลอก), EMF (metric จาก log ไม่เพิ่ม latency), metric alarm/composite alarm (ลด alert fatigue)/anomaly detection (seasonality), Logs Insights vs OpenSearch, แยก metric filter (log→metric) vs subscription filter (log→Kinesis/OpenSearch), Synthetics canary (outside-in), RUM (client-side), Contributor Insights (hot key/top talker), cross-account dashboards. X-Ray + ServiceLens + ADOT สำหรับ distributed tracing. Centralized logging ข้าม org: CloudWatch cross-account observability + subscription filter→Kinesis→Firehose→OpenSearch, audit ผ่าน org trail→Log Archive account, rollout ด้วย StackSets. SSM suite: Session Manager (no-bastion shell), Run Command, Patch Manager, State Manager, Automation runbook, OpsCenter, Parameter Store. IaC: CloudFormation (change set/drift/nested/DeletionPolicy), StackSets service-managed ข้าม account/region auto-enroll, CDK, การเลือก IaC. CI/CD: CodePipeline/Build/Deploy + deployment strategies (in-place/blue-green/canary/linear) พร้อม auto-rollback ผ่าน CloudWatch alarm. Self-healing: EC2 auto-recovery, EventBridge→SSM Automation, Config remediation. Continuous improvement: Compute Optimizer มุม under-provisioned, Trusted Advisor + Service Quotas, Well-Architected Review/Tool. มี 3 สถาปัตยกรรม (centralized observability, no-bastion+auto-patch+remediation, safe deploy pipeline), 15 ข้อผิดพลาด, 10 คำถาม. รับ pending cross-ref จากบท 03/04/05/08/09/10 ครบ. บทถัดไป: บท 12 (Migration) รับ MGN/discovery/7Rs — บทนี้ให้ SSM/observability เป็นฐาน operation หลัง migrate; DR game day/FIS ฝากบท 08; cost/Compute Optimizer มุม cost บท 10; decision framework สังเคราะห์บท 14. ยึด convention details เฉลย + bullet ทำไมตัวเลือกอื่นผิด + ตารางเชิงตัดสินใจ.

บทที่ 12 — Migration Strategy & Execution

บทที่ 12 เป็นเจ้าของ Domain 4 (~20%) ส่วน “การวางแผนและลงมือย้าย workload จริง” ในมุม SA Pro ที่ต้องบริหาร migration ทั้ง portfolio ไม่ใช่เครื่องเดียว. แกนหลัก: (1) AWS CAF 6 perspective แยก organizational (Business/People/Governance) vs technical (Platform/Security/Operations) — โจทย์ที่ทีมไม่มี skill/governance คือ gap เชิง organization ต้องปิดก่อนย้าย; (2) 3-phase migration Assess→Mobilize→Migrate&Modernize พร้อม MRA workshop และ CCoE; (3) 7 Rs (Rehost/Replatform/Repurchase/Refactor/Retire/Retain/Relocate) map ตาม keyword เป็นหัวใจออกสอบ — cannot modify code ตัด Refactor→Rehost, redundant→Retire, compliance ผูก on-prem→Retain; (4) discovery: ADS agentless (VMware/VM-level) vs agent-based (dependency ลึก), Migration Hub (single pane + Strategy Recommendations + Refactor Spaces), Migration Evaluator (pre-migration TCO/business case) แยกจาก Compute Optimizer (post-migration right-sizing); (5) execution: MGN rehost (block-level replication + short cutover, decommission source) และ MGN vs DRS ที่แยกให้ขาด (migration ครั้งเดียว vs DR ต่อเนื่อง/failback), DMS/DataSync/Snow อ้างบท 06/07; (6) wave planning (dependent apps อยู่ wave เดียว, เรียง complexity ต่ำ→สูง) + pilot wave 0; (7) online vs offline transfer + CDC เก็บ delta หลัง Snow; (8) hybrid interim state (DX/VPN, AD trust/Connector, CIDR overlap); (9) landing zone readiness (Control Tower) ต้องพร้อมก่อนย้าย; (10) cutover/rollback (test launch, keep source รอ rollback, ลด DNS TTL, phased canary vs big-bang). ตอบ pending cross-ref จากบท 01/03/04/06/08 ครบ. บทถัดไป: บท 13 รับ modernization pattern เชิงลึก (strangler fig/decomposition/App2Container/serverless) — บทนี้แตะ Refactor เพียงในฐานะ 1 ใน 7 Rs; บท 14 รับ decision framework สังเคราะห์. มี 3 สถาปัตยกรรม, 14 ข้อผิดพลาด, 9 คำถาม. ~4,300 คำ.

บทที่ 13 — Modernization & Refactoring

บทที่ 13 เป็นเจ้าของครึ่งหลังของ Domain 4 (modernization & refactoring) ต่อจากบท 12 ที่แตะ Refactor เพียงในฐานะ 1 ใน 7 Rs. แกนสำคัญ: (1) modernize ต่อเมื่อมี business driver ชัด (agility/scale/cost/resilience ผูก WAF pillars) — ข้อสอบวางกับดัก ‘อย่าเพิ่ง modernize’ เมื่อไม่มี driver/ใกล้ EOL/deadline สั้น/ทีมยังไม่พร้อม, และคำตอบเมื่อ tight deadline+modernize คือ ‘migrate then modernize’ (rehost ก่อน re-architect ทีหลัง). (2) monolith→microservices ใช้ strangler fig (facade/proxy + route ทีละส่วน ผ่าน Refactor Spaces) ไม่ใช่ big-bang rewrite; แตกตาม bounded context (DDD) + database-per-service + anti-corruption layer; cross-service data ใช้ event-driven/eventual consistency, Saga (Step Functions), CQRS ไม่ใช่ 2PC/shared DB. (3) containerize ด้วย AWS App2Container (A2C) สร้าง image+ECS/EKS artifact อัตโนมัติไม่แก้ code; เลือก orchestration ตามแกนบท 05: Fargate=least ops, EKS=k8s portability/tooling, EC2=คุมเต็ม/Spot. (4) serverless (Lambda+API Gateway+EventBridge+Step Functions) เหมาะ spiky/event-driven/least ops แต่ไม่เหมาะ long-running>15นาที, cold-start-sensitive, หรือ traffic สูงคงที่มหาศาล (container+Savings Plans ถูกกว่า). (5) database modernize: Babelfish for Aurora PostgreSQL ย้ายออกจาก SQL Server แก้ code น้อย+เลิก license (ต้องรัน SCT assessment), หรือ SCT+DMS re-engine heterogeneous. (6) analytics modernize = data lake บน S3 (Glue/Lake Formation/Athena/Redshift Spectrum) decouple ingest/process/serve. (7) DevOps: IaC/CI-CD + managed services ลด heavy lifting. (8) deployment ปลอดภัย: blue/green/canary + weighted routing. บทถัดไป (14) เป็นบทสังเคราะห์ — รับ decision framework เลือก compute/database/modernization path ข้าม domain, ไม่มีเนื้อหาใหม่ ให้อ้างกลับบท 01-13. บทนี้สืบทอด convention เฉลย

+ bullet ทำไมตัวเลือกอื่นผิด + ตารางเชิงตัดสินใจ.

บทที่ 14 — Exam Scenarios, Decision Frameworks & Final Review

บทที่ 14 เป็นบทปิดเล่ม (capstone/synthesis) ของคู่มือ SAP-C02 ไม่มีเนื้อหาใหม่ ทำหน้าที่ประกอบชิ้นส่วนบท 01-13 เป็นเครื่องมือตัดสินใจพร้อมใช้ในห้องสอบ วางปรัชญาแกน: keyword → จับ constraint → เดิน decision framework → ตัด distractor 5 ขั้น → ตรวจ trade-off ด้วย WAF 6 pillars (เมื่อ pillar ขัดกันให้เลือกตัวบาลานซ์ ไม่สุดขั้ว = หลีก over/under-engineering). หัวใจคือ 6 decision frameworks นำเสนอเป็น flowchart (code block) + ตาราง requirement→บริการ→trade-off: (1) database ตาม data model, (2) compute Lambda/Fargate/EKS/EC2, (3) connectivity peering/TGW/PrivateLink/VPN/DX, (4) DR strategy 4 แบบเรียงตาม cost/RTO/RPO, (5) migration 7 Rs, (6) storage object/block/file. ตามด้วย scenario walkthrough 10 ข้อแบบข้อสอบจริง ครอบทุก domain รวม cross-domain (security+networking data perimeter, cost+performance Spot/Savings Plans, migration+resilience+cost DRS/Aurora/SP) วิเคราะห์ทีละตัวเลือกว่าถูก/ผิด. รวม distractor patterns ทั้งเล่ม: mindset traps + ตารางคู่สับสน 20+ คู่ (RTO/RPO, Multi-AZ/Multi-Region, MGN/DRS, SCP/IAM, gateway/interface endpoint ฯลฯ) + กับดักเชิงบริการ (SCP ไม่คุม management account, cross-account=AND, SP ไม่ครอบ RDS, standby ไม่รับ read). ปิดด้วย keyword→service cheat sheet (lookup สุดท้าย) และ readiness checklist + กลยุทธ์วันสอบ (2.4 นาที/ข้อ, ผ่าน 750/1000 compensatory, ตอบให้ครบไม่มีติดลบ). สืบทอด convention เดิมครบ (

เฉลย + bullet ทำไมตัวเลือกอื่นผิด + ตารางตัดสินใจ + keyword อังกฤษ italic) เพิ่มรูปแบบ flowchart. เป็นบทสุดท้ายของเล่ม ไม่มีบทถัดไปให้ส่งต่อ — deliverable คือคู่มือครบ 14 บท.

ดัชนีนี้ถูกสร้างอัตโนมัติจาก compacted context ของทุกบท หากแก้ไขเนื้อหาบทใด ควรปรับดัชนีให้สอดคล้อง