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

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

บทนี้เป็นหัวใจของ Domain 2 (Design for New Solutions) และ Domain 3 (Continuous Improvement for Existing Solutions) ที่รวมกันคิดเป็นน้ำหนักมากกว่าครึ่งของข้อสอบ — เพราะแทบทุกโจทย์ระดับ Professional มี requirement เรื่อง “ระบบต้องอยู่รอด” ซ่อนอยู่เสมอ ไม่ว่าจะเป็น highly available, minimal downtime, no data loss, recover within X minutes, survive an AZ/region failure หรือ automatic failover คำเหล่านี้ (เชื่อมโยงบทที่ 01 — keyword mapping) ล้วนบีบให้เราต้องเลือกระหว่าง trade-off ของ cost vs RTO/RPO ซึ่งเป็นแกนตัดสินใจกลางของทั้งบท

จุดที่ SA Pro ต่างจาก Associate ไม่ใช่การรู้ว่า “Multi-AZ ทำให้ available” แต่คือการตอบได้ว่า business requirement (RTO/RPO/budget) ตัวนี้ควร map ไปที่ DR strategy แบบใดใน 4 แบบ, ต้องใช้ Multi-AZ หรือ Multi-Region, ใช้ replication แบบ sync หรือ async, orchestrate backup ทั้ง organization อย่างไร, และออกแบบ fault isolation (cell-based/bulkhead/shuffle sharding/static stability) เพื่อไม่ให้ความล้มเหลวลามทั้งระบบอย่างไร โดยชั่งต้นทุนที่จ่ายกับความเสี่ยงที่ยอมรับได้

บทที่ 01 ฝากมาว่า นิยาม RTO/RPO เต็มและ 4 DR strategies ต้องอยู่ที่นี่; บทที่ 04 ให้ networking failover primitive (Route 53, Global Accelerator) มาแล้ว บทนี้จะนำมาประกอบเป็น DR; บทที่ 05 ฝาก DR ของ compute (multi-region ASG/ECS/Lambda, ASG เป็น self-healing primitive); บทที่ 06 ฝาก orchestration ของ backup (AWS Backup, EBS snapshot + S3 CRR); บทที่ 07 ฝาก การ map Multi-AZ/read replica/Aurora Global Database/DynamoDB Global Tables เข้ากับ DR strategies — จะครอบคลุมให้ครบที่นี่

เมื่อจบบทนี้คุณจะสามารถ:

แยก availability vs resilience vs durability และคำนวณ SLA compounding ของหลายบริการต่อกัน
นิยาม RTO/RPO และ map เข้ากับ business requirement + ต้นทุนได้แม่นยำ
เลือก DR strategy 1 ใน 4 (Backup & Restore, Pilot Light, Warm Standby, Multi-Site Active-Active) พร้อมเหตุผล trade-off
ออกแบบ AWS Backup แบบ centralized/cross-region/cross-account + Vault Lock + org-wide policy
แยก AWS Elastic Disaster Recovery (DRS) ออกจาก MGN ให้ขาด และเลือก data replication ต่อบริการ
ออกแบบ failover ด้วย Route 53 health check + Application Recovery Controller (ARC)
ประยุกต์ fault isolation patterns (cell-based, bulkhead, shuffle sharding, static stability) เพื่อจำกัด blast radius

ขอบเขต: MGN (Application Migration Service) สำหรับ migration → บทที่ 12 (บทนี้ชี้ความต่าง MGN vs DRS ให้ชัดเท่านั้น); monitoring/alarm/CloudWatch เชิงลึก → บทที่ 11 (บทนี้ใช้ health check เป็น primitive); networking failover primitive (Route 53 routing policies, Global Accelerator) → บทที่ 04 (บทนี้นำมาประกอบเป็น DR pattern)

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

2.1 Availability vs Resilience vs Durability — สามคำที่ห้ามสับสน

โจทย์มักใช้คำเหล่านี้เป็น keyword บีบ ถ้าแยกไม่ออกจะตอบผิดตั้งแต่ต้น:

คำ	นิยาม	วัดด้วย	ตัวอย่าง
Availability	สัดส่วนเวลาที่ระบบ “ให้บริการได้” (uptime)	% หรือ “nines” (99.9% = 8.76 ชม./ปี downtime)	EC2 SLA, RDS SLA
Durability	โอกาสที่ข้อมูลที่เก็บไว้ “ไม่สูญหาย”	nines ของความคงอยู่ของ data	S3 11 nines (ดูบทที่ 06)
Resilience	ความสามารถ “ฟื้นตัว” จากความล้มเหลว/degrade แล้วกลับสู่ปกติ	RTO/RPO, การ degrade แบบ graceful	ระบบทน AZ ล่มแล้ว auto-recover

จุดออกสอบสำคัญ: availability สูง ไม่ได้แปลว่า durable สูงเสมอ — instance store (ดูบทที่ 06) อาจ available ตอนรันแต่ durability ต่ำ (ephemeral); กลับกัน S3 durable 11 nines แต่ availability ของแต่ละ storage class ต่างกัน (One Zone-IA availability ต่ำกว่า Standard) เมื่อโจทย์บอก no data loss = พูดถึง durability/RPO; always reachable = availability; recover quickly after failure = resilience/RTO

2.2 SLA Compounding — ยิ่งต่อกันยิ่งเปราะ

เมื่อ request ต้องผ่านหลายบริการแบบ series (ต้องทำงานพร้อมกันทุกตัว) availability รวม = คูณกัน ไม่ใช่ค่าเฉลี่ย:

3 บริการ series ที่ต่างก็ 99.9% → 0.999³ = 99.7% (downtime เพิ่มจาก ~8.76 ชม. เป็น ~26 ชม./ปี)
ยิ่งเพิ่ม component ในเส้นทาง (hard dependency) availability รวมยิ่งลด — นี่คือเหตุผลเชิงสถาปัตยกรรมที่ต้องลด hard dependency และทำให้ dependency เป็น “soft” (ระบบทำงานต่อได้แม้ dependency ล่ม)

กลับกัน การวาง redundant component แบบ parallel เพิ่ม availability: 2 ตัวที่ 99% ขนานกัน → 1 − (0.01 × 0.01) = 99.99% นี่คือหลักการเบื้องหลัง Multi-AZ (วาง resource ขนานข้าม AZ) จุดที่ SA Pro ต้องเห็น: การเพิ่มบริการเข้าไปใน critical path โดยไม่ทำให้ redundant จะลด availability รวมเสมอ — ดังนั้น decouple (SQS/SNS ดูบทที่ 05) และ static stability (2.13) จึงช่วยตัด hard dependency ออกจากเส้นทางวิกฤต

2.3 RTO & RPO — นิยามเต็ม (บทที่ 01 ฝากมา)

สองตัวชี้วัดนี้เป็นแกนกลางของทุกการตัดสินใจ DR:

RTO (Recovery Time Objective) = เวลาสูงสุดที่ยอมรับได้ตั้งแต่เกิดเหตุจนระบบกลับมาให้บริการ — ตอบคำถาม “ระบบล่มได้นานแค่ไหน?” วัดเป็นหน่วยเวลา (นาที/ชั่วโมง)
RPO (Recovery Point Objective) = ปริมาณข้อมูลสูงสุด (วัดเป็นเวลา) ที่ยอมให้สูญหาย — ตอบคำถาม “ข้อมูลย้อนหลังหายได้แค่ไหน?” เช่น RPO 5 นาที = backup/replicate อย่างน้อยทุก 5 นาที

เทคนิคจำ: RPO มองย้อนหลัง (backup ล่าสุดถึงจุดเกิดเหตุ = ข้อมูลที่หาย); RTO มองไปข้างหน้า (จุดเกิดเหตุถึงกลับมา = downtime) โจทย์มักให้ตัวเลขทั้งสองแล้วบีบให้เลือก strategy — ตัวเลขยิ่งเข้าใกล้ 0 ต้นทุนยิ่งพุ่งแบบไม่เชิงเส้น

การ map เข้ากับ business + cost: RTO/RPO ไม่ควรเป็นตัวเลขที่ engineer เลือกเอง แต่มาจาก business impact — ระบบชำระเงินอาจต้อง RPO≈0 (ห้ามเสีย transaction), ส่วน reporting batch อาจ RPO 24 ชม. ได้ ต้นทุนของ RPO≈0 (sync replication, multi-site) สูงกว่า RPO 24 ชม. (nightly backup) หลายเท่า หลักคือ: จ่ายให้พอดีกับที่ business ต้องการ ไม่ over/under (เชื่อมโยง Cost Optimization pillar และเทคนิคตัด over-engineering ในบทที่ 01)

2.4 4 DR Strategies — เรียงตามต้นทุน/RTO (หัวใจของบท)

AWS นิยาม DR 4 แบบ เรียงจาก RTO/RPO สูง+ถูก ไปต่ำ+แพง นี่คือ mental model ที่ต้องท่องให้ขึ้นใจ:

Strategy	RTO	RPO	Cost	หลักการ
Backup & Restore	ชั่วโมง–วัน	ชั่วโมง	ต่ำสุด	backup ไป region อื่น แล้ว restore/provision ใหม่ตอนเกิดเหตุ
Pilot Light	สิบนาที–ชั่วโมง	นาที	ต่ำ	core (database replicate ต่อเนื่อง) รันเบา ๆ, app tier ปิดไว้ scale ตอนเกิดเหตุ
Warm Standby	นาที	วินาที–นาที	ปานกลาง	full stack รันขนาดเล็ก (scaled-down) พร้อม scale up ทันที
Multi-Site Active-Active	~0 (วินาที)	~0	สูงสุด	รันเต็มทุก region รับ traffic พร้อมกัน

Backup & Restore: ถูกที่สุด เก็บ backup (AWS Backup/snapshot/S3 CRR) ข้าม region ตอนปกติไม่มี infrastructure รันที่ DR region เลย ตอนเกิดเหตุจึง provision ใหม่ทั้งหมด (IaC ช่วยเร่ง) — RTO เป็นชั่วโมง เหมาะ non-critical workload หรือที่ทน downtime ได้ trade-off: ถูกสุดแต่ช้าสุด และเสี่ยงว่า restore procedure ไม่เคยทดสอบจริง

Pilot Light: “ไฟนำร่อง” — เก็บส่วนแกน (โดยเฉพาะ database) ให้ replicate ต่อเนื่องและรันอยู่ (แต่เล็ก) ขณะที่ app/web tier ถูก provision ไว้แต่ปิด (AMI/launch template พร้อม) ตอนเกิดเหตุจึง “จุดไฟ” scale app tier ขึ้นและ switch traffic — RTO สิบนาทีถึงชั่วโมง, RPO ต่ำเพราะ data replicate ตลอด trade-off: จ่ายค่า database replication + storage ตลอดเวลา แต่ประหยัด compute

Warm Standby: full stack ทำงานจริงที่ DR region แต่ scaled-down (เช่น instance เล็ก/จำนวนน้อย) รับ traffic จริงได้เลย (อาจสัดส่วนเล็ก) ตอนเกิดเหตุแค่ scale up + shift traffic เต็ม — RTO นาที trade-off: แพงกว่า pilot light (compute รันตลอด) แต่เร็วกว่ามากและทดสอบได้ต่อเนื่อง (ระบบมีชีวิตอยู่จริง ลด bimodal behavior — ดู 2.14)

Multi-Site Active-Active (Hot Standby): รันเต็มทุก region พร้อมรับ traffic active-active (ผ่าน Route 53 latency/weighted หรือ Global Accelerator ดูบทที่ 04) — RTO/RPO ≈ 0 trade-off: แพงสุด (จ่าย 2×+ ตลอดเวลา) และ ซับซ้อนสุด โดยเฉพาะ data consistency ข้าม region (ต้องใช้ DynamoDB Global Tables multi-active หรือ conflict resolution) เหมาะเฉพาะ mission-critical ที่ downtime = เสียเงินมหาศาล

จุดตัดสินใจออกสอบ: โจทย์ให้ตัวเลข RTO/RPO + คำว่า cost-effective → เลือก strategy ที่ “แพงพอดี” กับ RTO/RPO ที่ระบุ ตัวอย่าง: RTO 4 ชม., budget จำกัด → Backup & Restore หรือ Pilot Light; RTO นาที, RPO วินาที → Warm Standby; near-zero downtime, active-active global → Multi-Site กับดักคือเลือก Multi-Site เมื่อโจทย์ RTO ยอม 2 ชม. (over-engineering) หรือเลือก Backup & Restore เมื่อโจทย์บอก RTO นาที (under-engineering)

2.5 Multi-AZ vs Multi-Region — แก้คนละปัญหา

นี่คือรากฐานที่ต้องแยกให้ขาดก่อนพูดถึง DR ใด ๆ:

มิติ	Multi-AZ	Multi-Region
ป้องกันอะไร	AZ ล่ม (ไฟดับ, network, hardware ระดับ datacenter)	Region ล่มทั้งหมด, disaster ระดับภูมิภาค, compliance/latency ระดับโลก
latency ระหว่างกัน	ต่ำมาก (< 1-2 ms, sync replication ได้)	สูง (สิบ–ร้อย ms, ต้อง async replication)
ความซับซ้อน	ต่ำ (บริการส่วนใหญ่ทำให้ built-in)	สูง (data consistency, DNS failover, IAM/quota ต่อ region)
จัดเป็น	HA (High Availability)	DR (Disaster Recovery)
ต้นทุน	เพิ่มเล็กน้อย (มักคุ้ม, เปิด default)	เพิ่มมาก (จ่ายซ้ำต่อ region)

ข้อจำกัดของ single-region ที่ต้องเข้าใจ: แม้ Multi-AZ จะทน AZ ล่มได้ แต่ถ้า service ระดับ region มีปัญหา (regional API outage, control plane) หรือเกิด disaster ครอบทั้ง region → Multi-AZ ช่วยไม่ได้ นี่คือเหตุผลที่ workload ต้องการ region resilience จริง ๆ ต้องไป Multi-Region ทั้งนี้ AWS ออกแบบให้ AZ แต่ละตัวมี physical isolation (คนละ power/cooling/network) และห่างกันพอที่ disaster เดียวไม่กระทบหลาย AZ แต่ใกล้พอให้ sync replication ได้ — จึง Multi-AZ แก้ปัญหาส่วนใหญ่ในต้นทุนต่ำ

หลักปฏิบัติ: เริ่มจาก Multi-AZ ให้แน่นก่อน (ตอบ highly available ส่วนใหญ่) แล้วค่อยพิจารณา Multi-Region เมื่อโจทย์บอกชัดว่า survive region failure, regulatory requires geographic separation, หรือ global low-latency — อย่ากระโดดไป Multi-Region เมื่อ Multi-AZ พอ (over-engineering + cost)

2.6 Compute resilience primitives (บทที่ 05 ฝากมา)

DR/HA ของ compute สร้างจาก primitive ที่บทที่ 05 วางไว้ นำมาประกอบดังนี้:

Auto Scaling Group (ASG) เป็น self-healing primitive: health check ตรวจ instance ที่ล่ม แล้ว replace อัตโนมัติ + กระจายข้าม AZ (multi-AZ ASG) → HA ระดับ instance โดยไม่ต้องแทรกแซง เมื่อโจทย์บอก automatically recover from instance failure → ASG + ELB health check
Multi-region compute failover: launch template + AMI ต้อง replicate/มีในทุก region (AMI เป็น region-scoped ต้อง copy), ASG แยกต่อ region; container image ต้องอยู่ใน ECR แต่ละ region (หรือ ECR replication) — สำหรับ pilot light/warm standby ให้เตรียม launch template ไว้ล่วงหน้าแล้ว scale ตอน failover
Lambda เป็น regional service — DR ทำโดย deploy function ในหลาย region (ผ่าน IaC/pipeline) และให้ event source/trigger อยู่ใน region นั้น; state ต้องอยู่ใน data store ที่ replicate (DynamoDB Global Tables)
ELB/ASG health check เป็น input ให้ Route 53 health check ระดับบนอีกชั้น (2.11)

2.7 Data replication strategies ต่อบริการ (บทที่ 06/07 ฝากมา)

DR ที่แท้จริงขึ้นกับ “data อยู่ที่ไหนตอนเกิดเหตุ” การเลือก replication mechanism ต่อบริการคือหัวใจของ RPO:

บริการ	กลไก replicate ข้าม region	RPO ที่ได้	Writer model
Amazon S3	CRR (Cross-Region Replication) + RTC 15 นาที (ดูบทที่ 06)	async, นาที (RTC รับประกัน 15 นาที)	เขียน primary, replicate ไป
Amazon Aurora	Aurora Global Database (ดูบทที่ 07)	< 1 วินาที typical	single writer, secondary read-only
Amazon RDS	cross-region read replica → promote	นาที (lag)	promote manual
Amazon DynamoDB	Global Tables (multi-active)	ต่ำมาก (วินาที)	เขียนได้ทุก region
Amazon EBS	snapshot + cross-region copy / DRS block replication	ตาม snapshot freq / DRS ~วินาที	restore เป็น volume ใหม่
Amazon EFS	AWS Backup cross-region / EFS replication	ตาม config	—

หลักการ map เข้า strategy:

no data loss / RPO≈0 relational → Aurora Global Database (single writer) หรือ Multi-AZ sync ใน region
active-active global writes → DynamoDB Global Tables (multi-active — ต่างจาก Aurora ที่ single writer, ดูบทที่ 07)
object/file DR → S3 CRR (+ RTC ถ้าต้องรับประกันเวลาเชิง compliance)
กับดัก: ตอบ Aurora Global Database เมื่อโจทย์ต้องการ active-active writes ทุก region = ผิด (Aurora secondary เป็น read-only จน promote)

2.8 AWS Backup — orchestration แบบ centralized (บทที่ 06 ฝากมา)

AWS Backup เป็น managed service ที่รวมศูนย์การ backup ข้ามหลายบริการ (EBS, EFS, RDS, Aurora, DynamoDB, FSx, S3, EC2 AMI, Storage Gateway, VMware ฯลฯ) — แทนการเขียน script snapshot แยกทีละบริการ ตอบ keyword centralized backup / least operational overhead:

Backup plan: กำหนด schedule (frequency), retention (lifecycle เช่นย้ายไป cold storage หลัง N วัน), และ backup vault ปลายทาง — resource ถูกเลือกเข้า plan ด้วย tag (resource selection) จึงครอบคลุม resource ใหม่อัตโนมัติ
Cross-region backup: copy recovery point ไป vault ที่ region อื่นอัตโนมัติในตัว plan → เป็นรากฐานของ Backup & Restore DR (ดู 2.4)
Cross-account backup: copy ไป vault ใน account อื่น (เช่น backup account แยก) ผ่าน AWS Organizations → ป้องกันกรณี production account ถูกลบ/เจาะ (แนวคิดเดียวกับ Log Archive account บทที่ 02)
AWS Backup Vault Lock: บังคับ WORM กับ recovery point (คล้าย S3 Object Lock บทที่ 06) — Compliance mode = ไม่มีใครลบ backup ได้แม้ root จนหมด retention (กัน ransomware/insider ลบ backup); Governance mode = user ที่มีสิทธิ์พิเศษ override ได้ ตอบโจทย์ immutable backups / protect against ransomware / regulatory retention
Organization-wide backup policy: กำหนด backup plan จาก management account บังคับลงทุก member account ผ่าน Organizations (เหมือน SCP บทที่ 02 แต่เป็น backup policy) → enforce backup governance ทั้ง org

จุดออกสอบ: centrally manage and enforce backups across all accounts with cross-region copies and immutable retention → AWS Backup + org policy + cross-region copy + Vault Lock (Compliance mode) ครบชุด — ไม่ใช่การเขียน Lambda snapshot เอง

2.9 AWS Elastic Disaster Recovery (DRS) — และความต่างจาก MGN

AWS Elastic Disaster Recovery (DRS, เดิม CloudEndure Disaster Recovery) ทำ continuous block-level replication จาก source server (on-prem หรือ cloud อื่นหรือ EC2) ไปยัง lightweight staging area ใน AWS (EBS ราคาถูกในสถานะ standby) — ให้ RPO วินาที และ RTO นาที โดยไม่ต้องรัน full instance ที่ปลายทางตอนปกติ (จ่ายแค่ staging storage + replication) ตอนเกิด disaster จึง launch instance เต็มจาก block ที่ replicate ไว้ → เป็นวิธีทำ DR ที่ใกล้ warm/pilot สำหรับ server-level (โดยเฉพาะ workload ที่ยัง lift-and-shift ไม่ได้ refactor)

ความต่าง MGN vs DRS — จุดออกสอบที่ AWS ชอบหลอก:

มิติ	AWS DRS (Elastic Disaster Recovery)	AWS MGN (Application Migration Service)
วัตถุประสงค์	Disaster Recovery (ต่อเนื่อง, พร้อม failover ตลอด)	Migration (ย้ายครั้งเดียวแล้วจบ — ดูบทที่ 12)
การใช้งาน	replicate ตลอดไป, failover/failback ซ้ำได้	cutover ครั้งเดียว, decommission source
กลไก	continuous block-level replication	continuous block-level replication (เทคโนโลยีร่วมราก CloudEndure)
ผลลัพธ์	source เดิมยังรัน (เป็น DR copy)	source ถูกเลิกใช้หลัง cutover
keyword	disaster recovery, RPO seconds, failover to AWS	migrate/rehost to AWS, lift-and-shift

หลักจำ: กลไกคล้ายกันมาก (ทั้งคู่มาจาก CloudEndure) แต่ เจตนาต่างกัน — DRS = อยู่ยาวเพื่อ failover ซ้ำ ๆ; MGN = ย้ายทีเดียวแล้วเลิก โจทย์ที่บอก set up disaster recovery for on-prem servers into AWS with RPO of seconds → DRS; migrate on-prem servers to AWS (rehost) → MGN เลือกสลับกัน = ผิดทันที (บทที่ 12 เป็นเจ้าของ MGN เต็ม)

2.10 Route 53 สำหรับ failover (บทที่ 04 ให้ primitive)

DR ระดับ region ต้องมีกลไก “พาผู้ใช้ไป region ที่ยังรอด” — Route 53 (ดูบทที่ 04 — routing policies + health check) ทำหน้าที่นี้:

Health check + Failover routing policy: ตั้ง primary record (region หลัก) + secondary (DR region) พร้อม health check ที่ endpoint หลัก — เมื่อ health check fail, Route 53 สลับ DNS ไป secondary อัตโนมัติ ตอบ automatic DNS failover to DR region
ข้อจำกัดที่ต้องรู้: DNS TTL ทำให้ client cache record เดิม → failover ไม่ instant (ตั้ง TTL ต่ำเช่น 60s ช่วยได้แต่มี trade-off query cost); Global Accelerator (บทที่ 04) ให้ failover ระดับวินาทีกว่าเพราะไม่พึ่ง DNS cache (static anycast IP)
Multi-value / weighted + health check ใช้กับ active-active (Multi-Site) กระจาย traffic และถอน endpoint ที่ป่วยออก

2.11 Application Recovery Controller (ARC) — DR ที่ควบคุมได้จริง

Amazon Route 53 Application Recovery Controller (ARC) แก้ปัญหาสำคัญของ DNS failover อัตโนมัติ: health check อัตโนมัติอาจ flap หรือ failover ตอนที่ DR region ยังไม่พร้อมจริง ARC มี 2 ส่วน:

Readiness checks: ตรวจต่อเนื่องว่า DR region “พร้อมรับ” จริง (capacity, quota, config, resource มีครบ, เทียบ config ระหว่าง region) — เตือนก่อนเกิดเหตุว่า DR ใช้การไม่ได้ (แก้ปัญหา DR ที่ไม่เคยทดสอบ)
Routing controls: สวิตช์ failover แบบ manual/programmatic ที่ผู้ควบคุมกด (แทนพึ่ง health check อัตโนมัติล้วน) — มี safety rules กันการสลับผิด (เช่น กันปิดทั้งสอง region พร้อมกัน) และมี highly available data plane กระจาย 5 region ให้กด failover ได้แม้ region ควบคุมมีปัญหา

จุดออกสอบ: reliably control regional failover / ensure standby is truly ready / avoid accidental failover → ARC (routing controls + readiness checks) เหนือกว่า DNS health check ล้วน เมื่อต้องการ deterministic, operator-controlled failover สำหรับ mission-critical

2.12 Fault isolation — Cell-based & Bulkhead

Fault isolation คือการออกแบบให้ความล้มเหลว “ถูกกัก” ไม่ลามทั้งระบบ — แนวคิดขั้นสูงที่ SA Pro ต้องเข้าใจ (ต่อยอดจาก blast radius isolation บทที่ 02 ที่ทำระดับ account):

Bulkhead pattern (ผนังกันน้ำเรือ): แบ่ง resource pool เป็นส่วน ๆ เพื่อไม่ให้ลูกค้า/workload หนึ่งกินทรัพยากรจนกระทบทั้งหมด เช่น แยก connection pool/queue/thread pool ต่อ tenant — ถ้าส่วนหนึ่งล่มหรือ overload ส่วนอื่นยังทำงาน
Cell-based architecture: แบ่งระบบเป็น “cell” อิสระหลายชุด (แต่ละ cell = full stack ที่ให้บริการ subset ของผู้ใช้) มี router บาง ๆ นำผู้ใช้ไป cell ของตน — เมื่อ cell หนึ่งล่ม กระทบเฉพาะผู้ใช้ใน cell นั้น (blast radius = 1/N ของระบบ) ไม่ใช่ทั้งระบบ ขยายด้วยการเพิ่ม cell (scale-out เชิงจำนวน cell) ทำให้ failure domain เล็กและคาดเดาได้

2.13 Shuffle sharding — กัน “noisy neighbor” ทำทั้งระบบล่ม

Shuffle sharding เป็นเทคนิคขั้นสูงต่อยอด cell/bulkhead: แทนที่จะ assign ลูกค้าไป shard เดียว ให้ assign แต่ละลูกค้าไปยัง ชุดย่อยสุ่ม (subset) ของ worker หลายตัว ที่ทับซ้อนกันแบบต่างกัน — ผลคือแม้ worker ชุดหนึ่งถูก “poison” ด้วยลูกค้าที่มีปัญหา (bad request/DDoS) ลูกค้ารายอื่นที่ shard สุ่มไม่ตรงกันทั้งหมดยังมี worker ที่ดีเหลือให้บริการ ด้วยคณิตศาสตร์ combinatorial ทำให้โอกาสที่ลูกค้าสองรายจะ “ชนกันครบทุก worker” ต่ำมาก → ลูกค้าที่มีปัญหากระทบเฉพาะตัวเอง ระบบโดยรวมยังทำงาน (AWS ใช้เทคนิคนี้ใน Route 53/service หลายตัว) เมื่อโจทย์บอก isolate impact of a single bad tenant/client across a shared fleet → shuffle sharding

2.14 Static stability & การหลีกเลี่ยง bimodal behavior

Static stability = ออกแบบให้ระบบ “ทำงานต่อได้โดยไม่ต้องพึ่งการเปลี่ยนแปลง (control plane action) ตอนเกิดเหตุ” เพราะ control plane มักเปราะกว่า data plane ตอน region/AZ มีปัญหา ตัวอย่าง:

Warm standby ที่ pre-provision capacity เต็มไว้ (over-provision เผื่อ) แทนพึ่งการ auto-scale ตอน failover — เพราะตอน AZ ล่ม การขอ instance ใหม่ (control plane) อาจล้มเหลว/ช้า ระบบที่ static stable จะมี capacity รออยู่แล้ว
ตัวอย่างคลาสสิก: EC2 ที่รันอยู่แล้ว (data plane) ยังทำงานต่อได้แม้ EC2 control plane (launch API) ล่ม — ออกแบบให้ไม่ต้อง launch ใหม่ตอนวิกฤต

Bimodal behavior = ระบบที่ทำงานคนละแบบระหว่าง “โหมดปกติ” กับ “โหมดเกิดเหตุ” — อันตรายเพราะ path เกิดเหตุแทบไม่เคยถูกทดสอบ (เช่น failover procedure ที่รันปีละครั้ง) จึงมักพังตอนต้องใช้จริง หลีกเลี่ยงด้วย: ให้ DR region “มีชีวิต” ตลอด (warm standby/active-active รับ traffic จริง) เพื่อให้ path เดียวกับปกติ — นี่คือเหตุผลลึกที่ warm standby/multi-site เชื่อถือได้กว่า backup & restore (ที่ restore path ไม่เคยรันจริง) เมื่อโจทย์เน้น reliable, tested failover ให้เอนไปทาง strategy ที่ DR region active อยู่แล้ว

2.15 AWS Resilience Hub — ประเมินและติดตาม resilience

AWS Resilience Hub เป็นบริการที่ให้กำหนด RTO/RPO เป้าหมายต่อ application แล้ว ประเมิน (assess) สถาปัตยกรรมจริง (ดึงจาก CloudFormation/Resource Groups/Terraform state) ว่า จะบรรลุ RTO/RPO ที่ตั้งไว้หรือไม่ พร้อมชี้จุดอ่อน (single point of failure, config ที่ไม่ตรงเป้า) และแนะนำการแก้ไข + สร้าง runbook/SOP และ integrate การทดสอบ (รวมถึง fault injection ผ่าน FIS [uncertain รายละเอียด integration ปัจจุบัน]) เพื่อ track resilience ต่อเนื่อง — ตอบ keyword continuously assess whether the architecture meets recovery objectives (เชื่อม Domain 3 continuous improvement) ต่างจาก Well-Architected Tool ตรงที่เจาะจง resilience เชิงปริมาณ (RTO/RPO) และตรวจซ้ำได้อัตโนมัติ

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

3.1 เลือก DR strategy ตาม requirement/keyword

Requirement / keyword ในโจทย์	Strategy	เหตุผล / trade-off
lowest cost, RTO hours acceptable, non-critical	Backup & Restore	ถูกสุด, ไม่มี infra ที่ DR; restore ช้าและเสี่ยงไม่เคยทดสอบ
low cost, keep database current, RTO < 1 hour	Pilot Light	database replicate ต่อเนื่อง, app scale ตอนเกิดเหตุ
RTO minutes, RPO seconds, tested failover	Warm Standby	full stack scaled-down รันจริง, scale up เร็ว, ลด bimodal
near-zero RTO/RPO, active-active, global users	Multi-Site Active-Active	แพงสุด+ซับซ้อน consistency; เหมาะ mission-critical
DR for on-prem servers, RPO seconds, failover to AWS	AWS DRS	continuous block replication, ไม่ใช่ MGN (migration)
centralized cross-account/region immutable backups	AWS Backup + Vault Lock + org policy	WORM, enforce ทั้ง org

3.2 HA vs DR mechanism เปรียบเทียบ

กลไก	ระดับ	ป้องกัน	Auto?	RPO
Multi-AZ (RDS/Aurora, ดูบทที่ 07)	HA	AZ ล่ม	ใช่ (sync failover)	≈0
ASG multi-AZ + ELB health check	HA	instance/AZ ล่ม	ใช่ (self-healing)	— (stateless)
Aurora Global Database	DR	region ล่ม	promote (fast)	< 1s
DynamoDB Global Tables	DR (active-active)	region ล่ม	ไม่ต้อง (multi-active)	วินาที
S3 CRR (+ RTC)	DR (data)	region ล่ม	อัตโนมัติ (async)	นาที (RTC 15 นาที)
Route 53 failover	DR (routing)	endpoint/region ล่ม	ใช่ (health check)	— (จำกัดด้วย DNS TTL)
ARC routing controls	DR (routing)	region ล่ม	manual/programmatic	— (deterministic)

3.3 เครื่องมือ replication/backup เปรียบเทียบ

เครื่องมือ	ใช้กับ	โหมด	จุดเด่น
AWS Backup	หลายบริการรวมศูนย์	scheduled snapshot + copy	centralized, org policy, Vault Lock
AWS DRS	server (on-prem/EC2/other cloud)	continuous block-level	RPO วินาที, RTO นาที, DR โดยเฉพาะ
EBS snapshot + cross-region copy	EBS volume	incremental snapshot	primitive พื้นฐาน (ดูบทที่ 06)
S3 CRR	S3 object	async replication	data DR, ต้องเปิด versioning
Aurora Global DB / DynamoDB Global Tables	database (ดูบทที่ 07)	storage/managed replication	RPO ต่ำมาก, DB-level DR

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

4.1 Pilot Light DR ข้าม region สำหรับ 3-tier web app

โจทย์: ระบบ 3-tier (web/app บน EC2+ASG, database บน RDS) ต้องการ DR ข้าม region ด้วย RTO < 1 ชม., RPO < 5 นาที, cost-effective

การออกแบบ:

Database: สร้าง cross-region read replica (หรือย้ายไป Aurora Global Database ถ้าต้อง RPO ต่ำกว่า) — replicate ต่อเนื่อง (นี่คือ “pilot light”)
App/web tier: เตรียม launch template + AMI copy ไปยัง DR region, ASG ตั้ง desired=0 (ปิดไว้)
S3 asset: เปิด CRR ไป DR region
Route 53 failover record ชี้ primary region + health check
ตอน failover: promote replica เป็น writer, scale ASG ขึ้น, Route 53 สลับ DNS

Trade-off: จ่ายแค่ database replication + storage + AMI ตลอดเวลา (ถูกกว่า warm standby มาก) แลกกับ RTO ที่นานกว่า (ต้องรอ scale + promote) เทียบกับ Backup & Restore: pilot light RPO ต่ำกว่ามาก (data replicate สด) และ RTO เร็วกว่า (infra เตรียมไว้แล้ว) เหตุผลที่เลือก: RTO 1 ชม. ไม่ต้องถึงขั้น warm standby (ประหยัด compute) แต่ RPO 5 นาทีตัด backup & restore ออก (nightly backup RPO เป็นชั่วโมง)

4.2 Multi-Site Active-Active global สำหรับ mission-critical

โจทย์: แพลตฟอร์มระดับโลก near-zero downtime, users เขียนข้อมูลจากทุกภูมิภาค low latency, survive full region failure

การออกแบบ:

Compute: full stack (ECS/EKS + ASG) รันเต็มใน 2+ region
Data: DynamoDB Global Tables (multi-active — เขียนได้ทุก region, ดูบทที่ 07) เป็น system of record
Routing: Global Accelerator (บทที่ 04) static anycast IP + latency-based → ผู้ใช้เข้า region ใกล้สุด, failover ระดับวินาที (ไม่พึ่ง DNS TTL); หรือ Route 53 latency routing + health check
Static objects: S3 + CloudFront (multi-origin หรือ MRAP)

Trade-off: จ่าย 2×+ ตลอดเวลา (compute + data ทุก region) และซับซ้อนสุดเรื่อง consistency — DynamoDB last-writer-wins ต้องออกแบบ app ให้ทน eventual consistency ข้าม region เหตุผลที่เลือก: keyword near-zero + active-active writes ตัดทุก strategy อื่นออก (Aurora Global Database single-writer ไม่ตอบ active-active writes); Global Accelerator เหนือ Route 53 ตรง failover ที่ไม่ติด DNS cache สิ่งที่แลก: cost สูงสุดเพื่อ RTO/RPO ≈ 0 — สมเหตุสมผลเฉพาะเมื่อ downtime = เสียเงินมหาศาล

4.3 Centralized immutable backup ทั้ง organization (กัน ransomware)

โจทย์: องค์กรมีหลาย account ต้องการ enforce backups across all accounts, cross-region copies, immutable retention for compliance, protect against accidental/malicious deletion

การออกแบบ:

AWS Backup organization policy จาก management account → บังคับ backup plan ลงทุก member account (resource selection by tag)
แต่ละ plan copy recovery point ไป backup account แยก (cross-account) และไป region ที่สอง (cross-region)
เปิด Backup Vault Lock — Compliance mode ที่ vault ปลายทาง → WORM ไม่มีใครลบได้แม้ root จนหมด retention
ใช้ tag policy (บทที่ 02) บังคับ tag เพื่อให้ resource selection ครอบคลุม

Trade-off: Vault Lock Compliance mode ตั้งแล้ว ถอนไม่ได้ จนหมด retention (ต้องคำนวณ retention ให้ดี — ถ้าตั้งพลาดจะติดค่า storage นาน) แลกกับความมั่นใจว่า backup ปลอดภัยจาก insider/ransomware เหตุผลที่เลือก: keyword centralized + enforce across accounts + immutable + protect against deletion map ตรงเป็น AWS Backup org policy + cross-account/region + Vault Lock ครบชุด — ตัดการเขียน Lambda snapshot เอง (operational overhead สูง, ไม่ immutable) และ backup account แยกให้ blast radius isolation (บทที่ 02)

4.4 DR สำหรับ on-prem servers ด้วย DRS

โจทย์: มี on-prem application servers (บาง OS/app ยัง refactor ไม่ได้) ต้องการ disaster recovery to AWS, RPO seconds, RTO minutes, ทดสอบ failover ได้โดยไม่กระทบ production

การออกแบบ:

ติดตั้ง AWS DRS agent บน source servers → continuous block-level replication ไปยัง staging area (EBS ราคาถูก) ใน AWS
ตั้ง launch settings (instance type, subnet, security group) ไว้ล่วงหน้า
ทำ recovery drill เป็นระยะ (launch จาก point-in-time เข้า isolated subnet) เพื่อทดสอบโดยไม่กระทบ replication — แก้ปัญหา bimodal (2.14)
ตอน disaster: launch recovery instances เต็ม, switch traffic; รองรับ failback กลับ on-prem เมื่อฟื้น

Trade-off: จ่ายแค่ staging storage + replication ตลอดเวลา (ถูก เพราะไม่รัน full instance จนกว่าเกิดเหตุ) แลกกับ RTO นาที (ต้อง boot instance) เหตุผลที่เลือก: keyword disaster recovery + on-prem servers + RPO seconds → DRS ตรง ๆ ไม่ใช่ MGN (MGN = migration ครั้งเดียว ดูบทที่ 12); ไม่ใช่ AWS Backup (backup ไม่ให้ RPO วินาทีสำหรับ server-level failover ต่อเนื่อง)

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

สับสน RTO กับ RPO: RTO = เวลากลับมา (downtime), RPO = ข้อมูลที่ยอมหาย (เวลาย้อนหลัง) — โจทย์ no data loss คือ RPO≈0 ไม่ใช่ RTO; recover in 15 minutes คือ RTO
เลือก Multi-Site Active-Active เมื่อ RTO ยอมเป็นชั่วโมง: over-engineering + cost มหาศาล — RTO ชั่วโมง → Backup & Restore/Pilot Light พอ
เลือก Backup & Restore เมื่อโจทย์บอก RPO วินาที/RTO นาที: under-engineering — backup nightly ให้ RPO เป็นชั่วโมง ต้อง warm standby/replication ต่อเนื่อง
สับสน DRS กับ MGN: DRS = disaster recovery (อยู่ยาว, failover ซ้ำ); MGN = migration (ย้ายทีเดียวเลิก source) — โจทย์ DR for servers → DRS; rehost/migrate → MGN (บทที่ 12)
คิดว่า Multi-AZ ป้องกัน region failure: Multi-AZ = HA ระดับ AZ ใน region เดียว — region ล่มต้อง Multi-Region (Aurora Global DB/DynamoDB Global Tables/CRR)
ตอบ Aurora Global Database สำหรับ active-active writes: Aurora single-writer (secondary read-only จน promote) — active-active writes ทุก region คือ DynamoDB Global Tables
ลืม DNS TTL limitation ของ Route 53 failover: failover ไม่ instant เพราะ client cache — ต้องการ failover ระดับวินาที → Global Accelerator (บทที่ 04) หรือ ARC
ไม่รู้จัก ARC เมื่อโจทย์ต้อง deterministic/tested failover: DNS health check ล้วนอาจ flap หรือ failover ตอน DR ไม่พร้อม — ARC readiness check + routing control ตอบตรงกว่า
เขียน Lambda snapshot เองแทน AWS Backup: centralized/least ops backup across accounts → AWS Backup + org policy — ไม่ใช่ script เอง
ลืม Vault Lock Compliance mode เมื่อโจทย์บอก immutable/ransomware protection: ต้อง WORM ที่ลบไม่ได้แม้ root — Compliance mode (Governance mode ยัง override ได้)
มองข้าม static stability / bimodal: strategy ที่ DR path ไม่เคยทดสอบ (backup & restore) เสี่ยงพังตอนใช้จริง — โจทย์เน้น tested/reliable failover เอนไป warm standby/active-active หรือทำ DR drill (DRS)
ลืม cross-region AMI/ECR/launch template สำหรับ compute DR: AMI เป็น region-scoped ต้อง copy ล่วงหน้า; pilot light/warm standby ที่ลืมเตรียม artifact จะ launch ไม่ได้ตอนเกิดเหตุ
ตอบ read replica ว่าให้ RPO=0 cross-region: cross-region read replica async มี lag เสมอ (RPO>0) — zero-RPO ต้อง sync (Multi-AZ ใน region) หรือยอม RPO<1s (Aurora Global DB)
สับสน durability กับ availability: no data loss = durability/RPO (S3 11 nines, sync replication); always reachable = availability (Multi-AZ, redundancy) — คนละเรื่อง

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

ข้อ 1. แอปพลิเคชันมี requirement RTO 30 นาที, RPO 5 นาที และต้องประหยัดต้นทุน (ไม่อยากรัน compute เต็มที่ DR region ตลอดเวลา) แต่ database ต้องทันสมัยเสมอ ควรเลือก DR strategy ใด

เฉลย

Pilot Light — database replicate ต่อเนื่อง (RPO ต่ำ) ส่วน app/web tier เตรียมไว้แต่ปิด scale ขึ้นตอนเกิดเหตุ (RTO 30 นาทีทำได้)

Backup & Restore ผิด — RPO เป็นชั่วโมง (backup เป็นระยะ) ไม่ตรง RPO 5 นาที และ RTO นานเกิน
Warm Standby ทำงานได้แต่แพงกว่าจำเป็น (รัน compute เต็มตลอด) — โจทย์บอกชัดว่าไม่อยากรัน compute เต็ม จึง over-provision
Multi-Site Active-Active over-engineering + cost สูงสุดสำหรับ RTO 30 นาที

ข้อ 2. ต้องตั้ง disaster recovery สำหรับ physical servers ใน on-prem data center ขึ้น AWS โดยต้องการ RPO ระดับวินาที และสามารถทดสอบ failover ได้เป็นระยะโดยไม่กระทบ production ควรใช้บริการใด

เฉลย

AWS Elastic Disaster Recovery (DRS) — continuous block-level replication ให้ RPO วินาที, ทำ recovery drill เข้า isolated subnet ได้โดยไม่กระทบ replication

AWS Application Migration Service (MGN) ผิด — MGN สำหรับ migration ครั้งเดียวแล้ว decommission source ไม่ใช่ DR ต่อเนื่อง (ดูบทที่ 12)
AWS Backup ผิด — backup เป็นระยะให้ RPO นาที/ชั่วโมง ไม่ใช่วินาที และไม่ทำ server-level failover ต่อเนื่อง
cross-region snapshot copy ไม่เกี่ยว on-prem source และ RPO สูงกว่ามาก

ข้อ 3. องค์กรมี 50 account ใน AWS Organizations ต้องการบังคับให้ทุก account มี backup ตาม policy เดียวกัน คัดลอกข้ามภูมิภาค และ backup ต้องลบไม่ได้แม้ผู้ดูแลระดับสูง (กัน ransomware) ควรทำอย่างไร

เฉลย

AWS Backup organization backup policy (บังคับจาก management account) + cross-region copy + Backup Vault Lock ในโหมด Compliance

เขียน Lambda + EventBridge snapshot เอง ผิด — operational overhead สูง, ไม่ centralized, ไม่ immutable
Vault Lock Governance mode ผิด — user สิทธิ์พิเศษยัง override/ลบได้ ไม่กัน insider/ransomware ตามโจทย์
S3 Object Lock อย่างเดียว ครอบเฉพาะ object ใน S3 ไม่ครอบ EBS/RDS/DynamoDB backup ทั้ง org

ข้อ 4. ระบบต้องการ failover ข้าม region ที่รวดเร็วระดับวินาทีสำหรับ TCP-based application และไม่ต้องการให้ผลกระทบจาก DNS caching ทำให้ failover ช้า ควรใช้อะไร

เฉลย

AWS Global Accelerator (ดูบทที่ 04) — static anycast IP บน AWS backbone, health check + failover ระดับวินาที ไม่พึ่ง DNS TTL

Route 53 failover routing ผิดในบริบทนี้ — พึ่ง DNS ที่ client cache ตาม TTL ทำให้ failover ไม่ instant
CloudFront ผิด — เป็น L7/HTTP caching CDN ไม่เหมาะ generic TCP application
VPC peering ไม่เกี่ยวกับ failover routing

ข้อ 5. แอปพลิเคชันระดับโลกต้องการให้ผู้ใช้ทุกภูมิภาคเขียนข้อมูลด้วย latency ต่ำ (active-active) และระบบต้องรอดแม้ทั้ง region ล่ม โดย RTO/RPO ใกล้ศูนย์ ควรออกแบบชั้นข้อมูลอย่างไร

เฉลย

Amazon DynamoDB Global Tables (multi-region, multi-active — เขียนได้ทุก region, ดูบทที่ 07) เป็น system of record

Aurora Global Database ผิด — single writer, secondary region read-only จน promote จึงไม่ active-active writes
RDS Multi-AZ ผิด — region เดียว ไม่รอด region failure
S3 CRR เป็น object storage ไม่ใช่ transactional data store สำหรับ active-active writes

ข้อ 6. ทีมกังวลว่าแผน DR ที่มี (failover ไป standby region) อาจใช้การไม่ได้จริงตอนเกิดเหตุ เพราะ standby อาจ capacity/config ไม่พร้อม และต้องการควบคุมการ failover แบบ deterministic (ไม่พึ่ง health check อัตโนมัติล้วน) ควรใช้อะไร

เฉลย

Amazon Route 53 Application Recovery Controller (ARC) — readiness checks ตรวจว่า standby พร้อมจริง + routing controls ให้ operator สลับ failover แบบ deterministic พร้อม safety rules

Route 53 health check + failover routing อย่างเดียว ผิด — เป็น automatic ล้วน ไม่ตรวจ readiness ล่วงหน้าและอาจ failover ตอน standby ไม่พร้อม
CloudWatch alarm ตรวจ metric ได้แต่ไม่ควบคุม regional failover + safety rule เชิงระบบ
AWS Config เป็น detective compliance ไม่ใช่ failover control

ข้อ 7. ระบบประกอบด้วย 4 microservices ต่อกันแบบ series แต่ละตัว availability 99.9% ผู้ออกแบบกังวลเรื่อง availability รวม ข้อใดอธิบายถูกและแนวทางแก้ที่เหมาะสม

เฉลย

availability รวม = 0.999⁴ ≈ 99.6% (ต่ำกว่าแต่ละตัว เพราะ series คูณกัน) แก้ด้วยการ ลด hard dependency ใน critical path — decouple ด้วย SQS/SNS (ดูบทที่ 05) และทำ dependency เป็น soft (ระบบทำงานต่อได้แม้บางส่วนล่ม) + redundancy ขนาน

เฉลี่ย availability = 99.9% ผิด — series ไม่ใช่เฉลี่ย แต่คูณกัน
เพิ่มบริการเข้า critical path เพื่อ “ตรวจสอบ” ผิด — ยิ่งเพิ่ม hard dependency availability ยิ่งลด
redundant/parallel component ต่างหากที่เพิ่ม availability

ข้อ 8. บริการแบบ multi-tenant พบว่า tenant รายเดียวที่ส่ง request ผิดปกติ (poison request) ทำให้ worker fleet ทั้งหมดล่มกระทบทุก tenant ต้องการออกแบบให้ผลกระทบจาก tenant เดียวถูกจำกัด ควรใช้ pattern ใด

เฉลย

Shuffle sharding — assign แต่ละ tenant ไปยัง subset สุ่มของ worker ที่ทับซ้อนต่างกัน ทำให้ tenant ที่มีปัญหากระทบเฉพาะ worker ชุดของตน tenant อื่นยังมี worker ดีเหลือให้บริการ

เพิ่ม worker ทั้ง fleet ผิด — poison request ยังลามทั้ง fleet เหมือนเดิม (blast radius ไม่ลด)
auto scaling ช่วยเรื่อง load แต่ไม่ isolate poison request
single shared queue ยิ่งทำให้ทุก tenant แชร์ failure domain เดียว
(bulkhead/cell-based ก็ช่วย isolate ได้ แต่ shuffle sharding เหมาะสุดกับการกัน noisy neighbor ข้าม shared fleet ด้วย combinatorial isolation)

ข้อ 9. ต้องการออกแบบ warm standby ให้เชื่อถือได้แม้ตอน AZ/region หลักมีปัญหา โดยหลีกเลี่ยงการพึ่งการ auto-scale (control plane) ตอน failover ควรใช้หลักการใด

เฉลย

Static stability — pre-provision capacity เต็ม (over-provision เผื่อ) ที่ standby ไว้ล่วงหน้า เพื่อไม่ต้องพึ่ง control plane action (launch instance ใหม่) ตอนเกิดเหตุ เพราะ control plane มักเปราะกว่า data plane ตอนวิกฤต และช่วยลด bimodal behavior (path เกิดเหตุ = path ปกติ)

พึ่ง auto scaling ตอน failover ผิด — ตอน region มีปัญหา การขอ capacity ใหม่อาจล้มเหลว/ช้า
restore จาก backup ตอนเกิดเหตุ เป็น bimodal (path ไม่เคยทดสอบ) และ RTO สูง
static stability แลกด้วย cost (จ่าย capacity ที่ไม่ได้ใช้ตอนปกติ) เพื่อความน่าเชื่อถือ

ข้อ 10. ผู้จัดการต้องการเครื่องมือที่ประเมินได้ว่าสถาปัตยกรรมปัจจุบัน “บรรลุ RTO/RPO เป้าหมายที่ตั้งไว้หรือไม่” และติดตามอย่างต่อเนื่องพร้อมข้อเสนอแก้ไข ควรใช้บริการใด

เฉลย

AWS Resilience Hub — กำหนด RTO/RPO เป้าหมายต่อ application แล้ว assess สถาปัตยกรรมจริงว่าจะบรรลุหรือไม่ ชี้ SPOF และแนะนำแก้ไข + track ต่อเนื่อง

AWS Well-Architected Tool ให้ review กว้างตาม 6 pillars แต่ไม่ประเมิน RTO/RPO เชิงปริมาณเฉพาะ resilience แบบ Resilience Hub
CloudWatch monitor metric runtime แต่ไม่ประเมิน architecture ต่อ recovery objective
Trusted Advisor ให้ best-practice check ทั่วไป ไม่เจาะ RTO/RPO validation

7. Cross-references

บทที่ 01 — Exam Blueprint & SA-Pro Mindset: (รับ cross-ref) นิยาม RTO/RPO เต็มและ 4 DR strategies ที่บทนี้เป็นเจ้าของ; keyword mapping — no data loss → RPO≈0 (sync/Aurora), minimal downtime/RTO low → warm standby/active-active, cost-effective DR → backup & restore/pilot light, survive region failure → multi-region; convention <details> ห่อเฉลย + bullet “ทำไมตัวเลือกอื่นผิด”
บทที่ 02 — Multi-Account Governance: blast radius isolation ระดับ account ต่อยอดเป็น fault isolation ระดับ architecture (cell/bulkhead); AWS Backup organization policy บังคับจาก management account เหมือนกลไก SCP; backup account แยก = แนวคิดเดียวกับ Log Archive account
บทที่ 04 — Networking at Scale & Hybrid: (รับ cross-ref) Route 53 routing policies + health check และ Global Accelerator เป็น failover primitive ที่บทนี้นำมาประกอบเป็น DR; DX/VPN สำหรับ DRS replication path
บทที่ 05 — Compute & Application Integration: (รับ cross-ref) ASG multi-AZ เป็น self-healing HA primitive, launch template/AMI/ECR สำหรับ multi-region compute DR, Lambda เป็น regional service, decouple ด้วย SQS/SNS เพื่อตัด hard dependency (ลด SLA compounding)
บทที่ 06 — Storage & Data Transfer: (รับ cross-ref) EBS snapshot + cross-region copy และ S3 CRR/RTC เป็น DR primitive; durability 11 nines vs availability; Object Lock WORM คู่ขนานกับ Backup Vault Lock; AWS Backup orchestrate primitive เหล่านี้
บทที่ 07 — Databases & Data Migration: (รับ cross-ref) Multi-AZ (HA/sync/RPO≈0) vs read replica (async), Aurora Global Database (single-writer, RPO<1s), DynamoDB Global Tables (multi-active) map เข้ากับ 4 DR strategies; AWS Backup cross-region สำหรับ database
บทที่ 09 — Security Architecture & Data Protection (ฝากไป): encryption ของ backup/replica ด้วย KMS (cross-region key สำหรับ CRR/cross-region backup), key policy สำหรับ cross-account backup, การป้องกัน backup (Vault Lock) เชิง data protection
บทที่ 11 — Operational Excellence & Monitoring (ฝากไป): CloudWatch alarm/health check เชิงลึกที่ trigger failover, monitoring RPO/replication lag, การทดสอบ DR (game day) และ AWS FIS (fault injection) สำหรับ chaos engineering, runbook automation ด้วย Systems Manager
บทที่ 12 — Migration Strategy & Execution (ฝากไป): AWS MGN สำหรับ rehost migration — บทนี้ชี้ความต่าง MGN (migration ครั้งเดียว) vs DRS (DR ต่อเนื่อง) ให้ชัด, บทที่ 12 เป็นเจ้าของ MGN เต็ม
บทที่ 14 — Exam Scenarios & Decision Frameworks (ฝากไป): decision framework “เลือก DR strategy” (RTO/RPO/cost → 1 ใน 4 strategy) เป็นหนึ่งใน flowchart หลักของบทสังเคราะห์