บทที่ 05: Compute & Application Integration

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

บทนี้เป็นหัวใจของ Domain 2 (Design for New Solutions) ซึ่งเป็น domain ที่มีน้ำหนักมากที่สุดในข้อสอบ (29% — ดูบทที่ 01) เพราะทุก workload ต้องรันบน compute อย่างใดอย่างหนึ่ง และเกือบทุก architecture ระดับ Professional ต้อง “decouple” ส่วนประกอบเข้าด้วยกันผ่าน application integration service เมื่อเครือข่ายจากบทที่ 04 (ดูบทที่ 04 — Networking at Scale) วางท่อไว้แล้ว บทนี้คือสิ่งที่ “วิ่งอยู่บนท่อ” นั้น

จุดที่ SA Pro ต่างจาก Associate ไม่ใช่การรู้ว่า “Lambda คือ serverless” แต่คือการตอบได้ว่า เมื่อไหร่ควรเลือก Lambda vs Fargate vs EC2, เมื่อไหร่ควร sync vs async, เมื่อไหร่ SQS vs SNS vs EventBridge โดยชั่ง trade-off ระหว่าง operational overhead, cost, latency, scale, และ coupling ให้ครบ โจทย์มักยาวและซ่อน constraint เช่น “spiky traffic”, “unpredictable”, “cannot lose messages”, “process exactly once”, “decouple”, “微服务ต้องไม่รู้จักกัน” — แต่ละคำชี้ไปที่บริการต่างกัน

บทที่ 01 ฝากมาว่า decoupling ด้วย SQS/SNS/EventBridge/Step Functions ต้องครอบคลุมที่นี่; บทที่ 03 ฝากมาว่า instance profile บน EC2/ASG และ IRSA (OIDC) สำหรับ EKS service account ต้องต่อยอดที่นี่; บทที่ 04 ฝากมาว่า load balancer เต็มรูปแบบ (ALB/NLB/GWLB), target group, Auto Scaling, และ compute หลัง endpoint เป็นหน้าที่บทนี้ — จะครอบคลุมให้ครบ

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

• เลือก EC2 instance family, placement group, tenancy และเข้าใจ instance store vs EBS-backed
• ออกแบบ Auto Scaling ให้ตรง traffic pattern (target tracking / step / predictive / scheduled) พร้อม lifecycle hook และ warm pool
• แยกได้ชัดว่าเมื่อไหร่ใช้ ALB vs NLB vs GWLB
• เลือกระหว่าง ECS vs EKS vs Fargate vs EC2 launch type โดยเข้าใจ control plane / data plane trade-off
• ออกแบบ Lambda ให้ถูก (concurrency, cold start, memory=CPU) และแยก Lambda@Edge vs CloudFront Functions
• เลือก integration service ให้ถูก: SQS vs SNS vs EventBridge vs Step Functions vs API Gateway vs AppSync
• ออกแบบ event-driven / microservices พร้อมจัดการ idempotency และ throttling

ขอบเขต: กลยุทธ์ containerization/refactor ในบริบท migration (strangler fig, App2Container) → บทที่ 13; การเลือก database engine (RDS/Aurora/DynamoDB) → บทที่ 07; DR ของ compute (multi-region failover, pilot light) → บทที่ 08; edge caching tuning ของ CloudFront → บทที่ 11 บทนี้พูดถึง compute + integration primitive และการเลือกใช้เท่านั้น

---

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

2.1 Amazon EC2: instance families

EC2 instance ถูกจัดกลุ่มเป็น family ตามอัตราส่วน vCPU : memory : network : accelerator ตัวอักษรตัวแรกบอก family, ตัวเลขบอก generation, ตัวอักษรท้าย (suffix) บอก variant เช่น m6g = general purpose, gen 6, Graviton (ARM); c7gn = compute optimized, gen 7, Graviton, network-optimized

Family	ตัวอย่าง	อัตราส่วนเด่น	use case
General purpose	M-series (m7i, m7g), T-series (t3/t4g burstable)	สมดุล CPU:memory (~1:4)	web server, app server ทั่วไป, microservice
Compute optimized	C-series (c7g, c7i)	CPU สูงต่อ memory (~1:2)	batch, HPC, game server, ad serving, high-throughput API
Memory optimized	R-series (r7g), X-series (x2), z1d, High Memory (u-)	memory สูงมาก (~1:8+)	in-memory DB, SAP HANA, large cache, analytics
Storage optimized	I-series (i4i — NVMe local), D-series (d3 — HDD), Im4gn	local storage IOPS/throughput สูง	NoSQL, data warehouse, distributed file system, log processing
Accelerated computing	P-series (GPU), G-series (GPU graphics/ML inference), Inf (Inferentia), Trn (Trainium), F-series (FPGA)	มี accelerator เฉพาะทาง	ML training/inference, rendering, genomics

จุดที่ออกสอบ:

• Graviton (ARM, suffix g): ให้ price/performance ดีกว่า x86 ~20-40% หากโจทย์บอก most cost-effective และ workload รองรับ ARM (Linux, container ที่ recompile ได้) → Graviton เป็นคำตอบที่ดี trade-off คือต้อง recompile/รองรับ ARM (บาง legacy binary ไม่รองรับ)
• T-series (burstable): สะสม CPU credit ตอน idle แล้วใช้ตอน burst เหมาะ workload ที่ CPU ต่ำเป็นส่วนใหญ่แต่ spike เป็นครั้งคราว (dev, low-traffic web) trade-off: ถ้า sustained high CPU จะหมด credit แล้ว throttle (ยกเว้นตั้ง unlimited mode ซึ่งคิดเงินเพิ่ม) — โจทย์ที่บอก “sustained CPU-intensive” แล้วมีตัวเลือก T-series คือ distractor
• การเลือก instance family ในข้อสอบมักมาจากคำใบ้ workload: “in-memory” → R/X, “batch compute” → C, “ML inference cost-optimized” → Inf/G, “high local IOPS NoSQL” → I

2.2 Placement groups

Placement group ควบคุมว่า EC2 instance วางใกล้/ไกลกันบน hardware อย่างไร มี 3 แบบ:

แบบ	การวาง	เพื่อ	trade-off
Cluster	ทุก instance ใน rack เดียวกัน AZ เดียว	low-latency, high throughput (up to 10 Gbps ระหว่าง instance), HPC, tightly-coupled	เสี่ยงสูง: rack ล่ม = ล่มทั้งกลุ่ม; จำกัด 1 AZ
Spread	แต่ละ instance คนละ hardware (rack/underlying host)	ลดความเสี่ยง correlated failure สูงสุด	จำกัด 7 instance ต่อ AZ ต่อ group; เหมาะ small critical set
Partition	แบ่งเป็น partition แต่ละ partition คนละ rack	large distributed system ที่ต้องรู้ topology (Hadoop, Cassandra, Kafka)	สูงสุด 7 partition ต่อ AZ; instance ต่อ partition ไม่จำกัด

จุดออกสอบ: “ต้องการ lowest inter-node latency สำหรับ HPC” → cluster; “distributed database ต้องกระจายให้ rack ล่มไม่ทำ replica หายพร้อมกัน” → partition; “critical instance จำนวนน้อยที่ต้องไม่ share hardware กัน” → spread

2.3 Tenancy

Tenancy กำหนดว่า instance รันบน hardware ที่ share กับลูกค้าอื่นหรือไม่:

Tenancy	ความหมาย	ใช้เมื่อ
Shared (default)	หลาย account share physical host (แยกด้วย hypervisor)	ทั่วไป, ถูกที่สุด
Dedicated Instance	hardware แยกเฉพาะ account เรา (แต่ AWS จัดการ host ให้)	compliance ที่ห้าม share hardware
Dedicated Host	เราได้ physical server ทั้งเครื่อง เห็น socket/core	BYOL license ที่ผูกกับ physical core (Windows Server, Oracle, SQL Server per-socket), ต้องการ host-level control/placement

จุดออกสอบสำคัญ: หากโจทย์พูดถึง software license ที่คิดตาม physical core/socket (BYOL) เช่น Oracle DB, Windows per-core → คำตอบคือ Dedicated Host เพราะเห็นและควบคุม core mapping ได้ (Dedicated Instance ไม่ให้ visibility ระดับ socket)

2.4 Instance store vs EBS-backed

• Instance store (ephemeral): block storage บน disk ที่ติดกับ physical host โดยตรง — throughput/IOPS สูงมาก (NVMe) แต่ ephemeral: ข้อมูลหายเมื่อ stop/terminate/hardware fail (แต่คงอยู่เมื่อ reboot) เหมาะ cache, scratch, buffer, replicated data ที่หายได้ (เช่น shard ของ distributed DB)
• EBS-backed: root/data volume อยู่บน Amazon EBS (network-attached, ดูบทที่ 06 สำหรับ volume type) — persistent, snapshot ได้, detach/attach ได้

จุดออกสอบ: “ต้องการ local NVMe IOPS สูงสุดสำหรับ temp/cache และข้อมูลหายได้” → instance store (i-series); “data ต้อง persist หลัง stop/terminate” → EBS ห้ามใช้ instance store — เป็น distractor คลาสสิกที่โจทย์บอก “ข้อมูลต้องอยู่รอด” แล้วมีตัวเลือก instance store

2.5 Auto Scaling

Auto Scaling Group (ASG) รักษาจำนวน instance ให้อยู่ระหว่าง min/desired/max, ทำ health check + แทน instance ที่ตาย, และกระจายข้าม AZ (เป็นรากฐาน HA ที่ถูกและ managed) การ scale มีหลายนโยบาย:

Scaling policy	กลไก	เหมาะกับ
Target tracking	ตั้ง metric เป้าหมาย (เช่น CPU 50% หรือ ALBRequestCountPerTarget) ASG ปรับ capacity ให้เข้าเป้า	default ที่แนะนำ — ง่ายสุด, least ops, จัดการ steady load ได้ดี
Step scaling	เพิ่ม/ลดตามขั้นตาม alarm breach magnitude (เกิน 60% +1, เกิน 80% +3)	ต้องการควบคุมละเอียดตามความรุนแรง
Simple scaling	+N เมื่อ alarm trip แล้วรอ cooldown	legacy, ไม่แนะนำ (step ดีกว่า)
Scheduled scaling	scale ตามเวลาที่รู้ล่วงหน้า (เช่น 08:00 เพิ่ม capacity)	traffic pattern ตามเวลาแน่นอน (office hours, batch window)
Predictive scaling	ML วิเคราะห์ history แล้ว pre-provision ก่อน load มา	traffic cyclical/recurring ที่ reactive scaling ตามไม่ทัน (เช่น spike ทุกเช้า)

จุดออกสอบ:

• traffic “predictable, recurring daily/weekly pattern” + ต้องการ pre-warm → predictive scaling (มักคู่กับ dynamic เป็น safety net)
• “รู้เวลาแน่นอน” (Black Friday 00:00) → scheduled
• ทั่วไป least ops → target tracking

Lifecycle hooks: หยุด instance ไว้ในสถานะ Pending:Wait (ตอน launch) หรือ Terminating:Wait (ตอน terminate) เพื่อรัน custom action เช่น โหลด data/register ก่อนรับ traffic, หรือ drain connection/upload log ก่อนถูกฆ่า — จุดออกสอบ: “ต้องรัน bootstrap/cleanup ก่อน instance เข้า/ออก service” → lifecycle hook

Warm pools: pool ของ instance ที่ pre-initialized (stopped/hibernated/running) รอ ASG ดึงมาใช้ทันทีเมื่อต้อง scale out — แก้ปัญหา instance ที่ boot/warm-up นานมาก (เช่น app โหลด dataset ใหญ่ตอน start) ให้ scale-out เร็วขึ้นโดยไม่ต้องรัน full bootstrap ทุกครั้ง trade-off: จ่ายค่า storage (และ compute ถ้า running-state) ของ warm instance

Launch template (แทน launch configuration ที่ deprecated): กำหนด AMI, instance type, key, SG, user data พร้อม versioning — จำเป็นสำหรับฟีเจอร์ใหม่ ๆ EC2 access S3 ผ่าน instance profile ที่ระบุใน launch template (ดูบทที่ 03 — instance profile + IMDSv2) นี่คือ cross-reference ที่บทที่ 03 ฝากมา: ASG ไม่ hardcode key แต่ผูก IAM role ผ่าน instance profile ใน launch template

Mixed instances policy: ให้ ASG เดียวใช้หลาย instance type และผสม On-Demand + Spot ตามสัดส่วน (เช่น base 2 On-Demand + ที่เหลือ 100% Spot) เลือก allocation strategy เป็น capacity-optimized เพื่อลด Spot interruption หรือ lowest-price — เป็นรากฐานการประหยัดด้วย Spot (รายละเอียด Spot strategy → บทที่ 10) จุดออกสอบ: “web fleet ที่ทน interruption ได้บางส่วนและต้องการ cost-effective” → mixed instances policy (On-Demand base + Spot) หลัง ALB

2.6 Elastic Load Balancing: ALB vs NLB vs GWLB

บทที่ 04 แตะเฉพาะ network insertion — ที่นี่เจาะเต็ม โหลดบาลานเซอร์ทั้งสามใช้ target group เป็นปลายทาง (target = instance / IP / Lambda / ALB) และมัก integrate กับ ASG

	Application LB (ALB)	Network LB (NLB)	Gateway LB (GWLB)
Layer	L7 (HTTP/HTTPS/gRPC/WebSocket)	L4 (TCP/UDP/TLS)	L3/4 (GENEVE encapsulation)
routing	path-based, host-based, header, query, method	ตาม flow hash (5-tuple)	ส่งทุก packet ไป appliance fleet
latency	สูงกว่า NLB เล็กน้อย	ultra-low, ~microseconds	ตาม appliance
static IP	ไม่มี (DNS name); ใช้ผ่าน GA เพื่อได้ static IP	มี static IP ต่อ AZ + Elastic IP ได้	ผ่าน GWLB endpoint
ขีดความสามารถ	TLS termination, WAF integration, redirect, fixed response, cognito auth, sticky	preserve source IP, ล้าน RPS, TLS passthrough/termination	ส่ง traffic ไป third-party firewall/IDS/IPS แบบ transparent
target = Lambda	ได้	ไม่ได้	ไม่ได้
use case	HTTP microservice, container routing, API หลัง path	game/IoT/high-perf TCP-UDP, ต้องการ static IP, PrivateLink provider	inline security appliance insertion (ดูบทที่ 04 GWLBe)

จุดตัดสินใจที่ออกสอบบ่อย:

• ต้อง route ตาม URL path / host (เช่น /api ไป service หนึ่ง, /img ไปอีก service) → ALB (L7 เท่านั้นที่เห็น path)
• ต้องการ static IP / Elastic IP ที่ whitelist ได้, ultra-low latency, หรือรองรับ non-HTTP (UDP/TCP raw) → NLB
• ต้องการ preserve client source IP โดยไม่พึ่ง X-Forwarded-For → NLB (ALB จะซ่อน source IP; NLB ส่งผ่าน)
• ต้องการ expose service ผ่าน PrivateLink endpoint service → ต้องมี NLB อยู่หน้า (ดูบทที่ 04)
• ต้องการเสียบ third-party firewall appliance แบบ transparent → GWLB (ดูบทที่ 04 — GENEVE, appliance mode)
• ต้อง integrate WAF (L7 rule) หรือ Cognito user pool authentication ที่ LB → ALB (NLB ทำไม่ได้)

trade-off ที่ SA Pro ต้องเห็น: บางโจทย์ต้องได้ทั้ง static IP และ HTTP path routing — คำตอบคือ Global Accelerator หน้า ALB (GA ให้ static anycast IP, ALB ทำ L7 routing — ดูบทที่ 04) ไม่ใช่พยายามให้ ALB มี static IP เอง

2.7 Containers: ECS vs EKS vs Fargate

โจทย์ container ระดับ Pro มักถามเรื่อง control plane / data plane trade-off และ operational overhead

แกน 1 — orchestration (control plane):

	Amazon ECS	Amazon EKS
API	AWS-proprietary, เรียบง่าย	Kubernetes มาตรฐาน (portable, ecosystem ใหญ่)
ops overhead	ต่ำกว่า — AWS จัดการเกือบหมด, integrate IAM/ALB/CloudWatch native	สูงกว่า — ต้องเข้าใจ k8s (RBAC, addon, upgrade) แม้ control plane เป็น managed
เหมาะเมื่อ	ทีมอยู่ใน AWS อยู่แล้ว, ต้องการ least operational overhead, ไม่ต้องการ k8s portability	ต้องการ k8s portability/multi-cloud, มี k8s expertise, ใช้ Helm/operator/CRD ecosystem
identity	task role (IAM) ต่อ task	IRSA (IAM Roles for Service Accounts ผ่าน OIDC) หรือ EKS Pod Identity

จุดออกสอบ: “ทีมมี Kubernetes expertise / ต้องการ portable ข้าม cloud / ใช้ Helm” → EKS; “ต้องการ container orchestration บน AWS โดย least operational overhead และไม่ต้องการเรียนรู้ k8s” → ECS

IRSA (IAM Roles for Service Accounts) — cross-reference จากบทที่ 03: EKS ใช้ OIDC provider ของ cluster เพื่อ map Kubernetes service account เข้ากับ IAM role ทำให้ pod แต่ละตัวได้ credential เฉพาะ (fine-grained, least privilege) แทนที่จะใช้ IAM role ของ node ทั้งก้อน (ซึ่งทำให้ทุก pod บน node ได้สิทธิ์เท่ากัน) — เป็นคำตอบมาตรฐานเมื่อโจทย์ถาม “pod ต้องเข้า AWS resource ด้วยสิทธิ์เฉพาะ pod บน EKS”

แกน 2 — data plane (ที่ container รันจริง):

	Fargate	EC2 launch type
การจัดการ node	ไม่มี node ให้จัดการ (serverless container)	ต้อง provision/patch/scale EC2 เอง
pricing	จ่ายต่อ vCPU/memory ต่อ task ที่รัน	จ่ายค่า EC2 ตลอด (จ่ายแม้ container ไม่เต็ม node)
เหมาะเมื่อ	least operational overhead, spiky/variable workload, ไม่อยากบริหาร node	ต้องการควบคุม instance (GPU, special instance, Spot ราคาถูก, high density), workload ใหญ่คงที่ที่ EC2 คุ้มกว่า
ข้อจำกัด	ไม่มี GPU (บางกรณี), ไม่มี privileged container/daemonset เต็มรูป, size จำกัด	ต้องบริหาร capacity เอง (ใช้ capacity provider ช่วย)

Capacity providers: กลไกให้ ECS จัดการ capacity อัตโนมัติ — Fargate / Fargate Spot / Auto Scaling Group (สำหรับ EC2) กำหนด strategy ผสมได้ (เช่น base Fargate + burst Fargate Spot) ช่วยให้ scaling ของ task ผูกกับ capacity อย่าง managed

Amazon ECR = private container registry — เก็บ image, สแกน vulnerability (scan on push), lifecycle policy ลบ image เก่า, cross-region replication, และ integrate IAM/PrivateLink (ดึง image แบบ private จาก VPC)

กลยุทธ์การย้ายเข้า container / เลือก orchestration ในบริบท modernization (App2Container, strangler) → บทที่ 13 บทนี้เน้นการเลือกใช้เชิงสถาปัตยกรรมเท่านั้น

2.8 AWS Lambda

Lambda รันโค้ดแบบ event-driven โดยไม่ต้องบริหาร server จ่ายตาม request + duration × memory จุดที่ SA Pro ต้องเข้าใจลึก:

• Memory = CPU: การตั้ง memory (128 MB – 10,240 MB) จะเพิ่ม vCPU ตามสัดส่วนอัตโนมัติ — CPU-bound function เร่งได้โดยเพิ่ม memory (บ่อยครั้งเพิ่ม memory ทำให้ทั้งเร็วขึ้น และถูกลง เพราะรันสั้นลง) จุดออกสอบ: “Lambda ช้าที่งาน CPU-heavy” → เพิ่ม memory (ไม่ใช่ refactor เป็น EC2 ทันที)
• Cold start: การ init environment + runtime + โค้ด init ครั้งแรก/ตอน scale ใหม่ ทำให้ latency แรกสูง — ลดด้วย provisioned concurrency (pre-init environment รอไว้, ตัด cold start, จ่ายเพิ่ม) เหมาะ latency-sensitive API. ภาษาที่ init เร็ว (Go, Python, Node) cold start ต่ำกว่า JVM/.NET
• Concurrency:
  • Reserved concurrency: จองเพดาน concurrency ให้ function หนึ่ง (กันไม่ให้ function อื่นแย่ง account concurrency และจำกัดไม่ให้ function นี้ทะลุเพดานไป overwhelm downstream เช่น DB)
  • Provisioned concurrency: pre-warmed instance จำนวนหนึ่ง — ตัด cold start (คนละเรื่องกับ reserved)
  • account มี concurrency limit รวม (default 1,000, เพิ่มได้) — ทะลุแล้ว throttle
• Layers: แพ็กเกจ dependency/shared code ใช้ร่วมหลาย function ลด package size และ deploy ง่าย
• Event source mapping: สำหรับ poll-based source (SQS, Kinesis, DynamoDB Streams, MSK) — Lambda service poll แล้ว invoke ให้ (batch), จัดการ retry/checkpoint, และ scale ตาม queue depth/shard
• ข้อจำกัดสำคัญ: timeout สูงสุด 15 นาที, ephemeral /tmp (512 MB – 10 GB), payload sync 6 MB / async 256 KB — โจทย์ที่งานรัน “นานกว่า 15 นาที” → ตัด Lambda ใช้ Fargate/Step Functions/batch แทน

Lambda@Edge vs CloudFront Functions (ทั้งคู่รันที่ edge บน CloudFront — ดูบทที่ 04):

	CloudFront Functions	Lambda@Edge
runtime	JavaScript เบา, sub-millisecond	Node.js/Python เต็ม
ที่รัน	edge location (มากที่สุด)	Regional edge cache
trigger	viewer request / viewer response เท่านั้น	ทั้ง 4 (viewer + origin request/response)
ทำได้	header manipulation, URL rewrite, redirect, JWT/token check เบา ๆ, A/B	network access, ขนาดใหญ่, external call, ปรับ origin request/response
cost/scale	ถูกมาก, สูงสุด ล้าน RPS	แพงกว่า, latency สูงกว่า

จุดออกสอบ: “แก้ header / URL rewrite / redirect เบา ๆ ที่ scale สูงสุดและถูกสุด” → CloudFront Functions; “ต้อง call external service / ปรับ origin request / logic หนัก” → Lambda@Edge

2.9 Amazon SQS (decoupling ด้วย queue)

cross-reference จากบทที่ 01 — SQS เป็น managed message queue สำหรับ decouple producer/consumer (async, pull-based)

• Standard queue: throughput แทบไม่จำกัด, at-least-once delivery (อาจซ้ำ), best-effort ordering (ไม่รับประกันลำดับ)
• FIFO queue: exactly-once processing + ordering ตาม MessageGroupId, throughput จำกัดกว่า (สูงสุด ~3,000 msg/s ต่อ API batch หรือ ~300 ต่อ default; สูงขึ้นด้วย high throughput mode) — ใช้เมื่อ ต้องลำดับ/ห้ามซ้ำ เช่น financial transaction, order processing
• Visibility timeout: เมื่อ consumer รับ message มันจะ “ซ่อน” ชั่วคราวไม่ให้ consumer อื่นเห็น จนกว่าจะลบหรือหมดเวลา — ต้องตั้งให้ยาวพอกับเวลาประมวลผล ไม่งั้น message โผล่กลับมาแล้วถูกประมวลผลซ้ำ
• Dead-letter queue (DLQ): message ที่ประมวลผลล้มเหลวเกิน maxReceiveCount ถูกย้ายไป DLQ เพื่อ investigate โดยไม่ block queue หลัก
• Long polling (WaitTimeSeconds) ลด empty response และค่า API เทียบ short polling
• SQS ไม่ push ต้องมี consumer poll (หรือ Lambda event source mapping poll ให้) และเป็น point-to-point (หลาย consumer แย่งกันดึง, แต่ละ message ไปหนึ่ง consumer)

จุดออกสอบ: “buffer งานไว้ให้ worker ประมวลผลตามกำลัง / smooth out spike / decouple” → SQS; “ต้อง ordering + no duplicate” → SQS FIFO; “งานถูก process ซ้ำเพราะ timeout” → ปรับ visibility timeout + ทำ idempotency

2.10 Amazon SNS (fan-out ด้วย pub/sub)

SNS เป็น push-based pub/sub: publisher ส่งไป topic เดียว แล้ว SNS fan-out ไปทุก subscriber (SQS, Lambda, HTTP, email, SMS, Kinesis Data Firehose)

• Fan-out pattern: SNS topic → หลาย SQS queue — event เดียวกระจายไปหลาย consumer ที่ประมวลผลอิสระ (แต่ละ service มี queue ของตัวเอง, buffer ได้, retry ได้) นี่คือ pattern มาตรฐานเมื่อ หนึ่ง event ต้องให้หลาย downstream ทำงานพร้อมกัน
• Message filtering (filter policy): subscriber ตั้ง filter ให้รับเฉพาะ message ที่ attribute ตรง — ลดการส่ง message ที่ไม่เกี่ยว โดยไม่ต้องแยก topic
• SNS FIFO: จับคู่กับ SQS FIFO เพื่อ ordering + dedup ใน fan-out
• ต่างจาก SQS: SNS push ทันที ไม่ persist ให้ poll (ถ้า subscriber ล่มและไม่มี retry/DLQ อาจหาย) — จึงนิยม SNS→SQS เพื่อได้ทั้ง fan-out และ durability/buffer

จุดออกสอบ: “หนึ่ง event ต้อง trigger หลายระบบพร้อมกัน แต่ละระบบ buffer/retry เอง” → SNS + หลาย SQS (fan-out); “แจ้งเตือน email/SMS” → SNS ตรง

2.11 Amazon EventBridge

EventBridge เป็น serverless event bus ที่ทรงพลังกว่า SNS ในเชิง routing และ integration — เป็นแกนของ event-driven architecture ระดับองค์กร

• Event bus + rules: event (JSON) เข้ามา bus แล้ว rule ที่ match ตาม content-based pattern (ดูค่าใน event body ได้ ไม่ใช่แค่ attribute) route ไป target หลายชนิด (Lambda, Step Functions, SQS, SNS, Kinesis, API destination ฯลฯ) — filtering ละเอียดกว่า SNS มาก
• Sources: AWS service events (เกือบทุกบริการส่ง event เข้า default bus), custom application events, และ SaaS partner events (Zendesk, Datadog ฯลฯ ผ่าน partner event bus) — จุดเด่นที่ SNS ทำไม่ได้
• Schema registry: จัดเก็บ schema ของ event + generate code binding — ช่วย governance ของ event-driven ขนาดใหญ่
• EventBridge Pipes: point-to-point integration source→(filter→enrich)→target แบบ managed ลด glue code (เช่น DynamoDB Stream → enrich ด้วย Lambda → Step Functions) — เหมาะเชื่อม service เข้าด้วยกันโดยไม่เขียน plumbing เอง
• Scheduler: cron/rate schedule แบบ managed (แทน CloudWatch Events rule เดิม) scale สูง
• trade-off vs SNS: EventBridge latency สูงกว่า SNS เล็กน้อยและ throughput ต่อ target มี quota — SNS เหมาะ fan-out ปริมาณมหาศาล latency ต่ำ; EventBridge เหมาะ routing ซับซ้อน, content filtering, integrate SaaS/AWS events, schema governance

จุดออกสอบ (แกนตัดสินใจสำคัญ):

• “route event ตามเนื้อหา ไปหลายปลายทางต่างกัน + integrate AWS service events / SaaS + least code” → EventBridge
• “fan-out event เดียวไปหลาย consumer, throughput สูง, latency ต่ำ” → SNS
• “buffer งานให้ worker, decouple, retry” → SQS

2.12 AWS Step Functions (orchestration)

Step Functions เป็น serverless workflow orchestration — ประสาน service หลายตัวเป็น state machine (sequence, parallel, choice, retry, catch, wait) โดยไม่ต้องเขียน orchestration logic เอง เหมาะแทน “Lambda เรียก Lambda เรียก Lambda” ที่ error handling ยุ่งเหยิง

	Standard workflow	Express workflow
duration สูงสุด	1 ปี	5 นาที
execution model	exactly-once, durable, มี full history	at-least-once, ไม่เก็บ history ละเอียด
throughput	ต่ำกว่า (~ hundreds/s start rate)	สูงมาก (>100,000/s)
pricing	ต่อ state transition	ต่อ request + duration
เหมาะกับ	long-running, human approval, audit ต้องการ history (ETL, order fulfillment, ML pipeline)	high-volume, short, event-processing/streaming ingestion

• มี service integration ตรงกับ 200+ AWS service (เรียก Lambda, ECS, Batch, DynamoDB, SNS, SQS ได้โดยไม่ต้องเขียน SDK glue)
• Retry/Catch ระดับ state ทำให้จัดการ error/backoff แบบ declarative — ลด boilerplate error handling
• รองรับ callback pattern (waitForTaskToken) รอ external system/human ตอบกลับ

จุดออกสอบ: “orchestrate multi-step workflow ที่มี error handling / retry / human approval / long-running” → Step Functions Standard; “high-volume short event processing pipeline” → Express; อย่าตอบ “โซ่ Lambda เรียกกันเอง” เมื่อโจทย์ต้องการ visibility/retry/state management

2.13 API Gateway และ AWS AppSync

Amazon API Gateway — managed front door สำหรับ API มี 3 แบบ:

แบบ	โปรโตคอล	เด่น	เหมาะ
REST API	HTTP request/response	feature เต็ม: API keys, usage plan, request/response transform (VTL), WAF, caching, canary	API ที่ต้องการ feature ครบ, rate limit ต่อ customer
HTTP API	HTTP request/response	เบา, ถูกกว่า ~70%, latency ต่ำกว่า, feature น้อยกว่า	proxy ไป Lambda/HTTP ตรง ๆ, JWT auth, cost-effective
WebSocket API	WebSocket	สอง-ทาง persistent connection	chat, real-time notification, live dashboard

• มี throttling (rate + burst) ต่อ stage/method และ usage plan + API key จำกัดต่อ client — ตอบโจทย์ “ป้องกัน backend ถูก overwhelm / จำกัดโควตาต่อ customer”
• Authorizer: IAM, Cognito user pool (ดูบทที่ 03), หรือ Lambda authorizer (custom)
• caching (REST) ลด backend load

AWS AppSync — managed GraphQL (และ Pub/Sub): ให้ client query เฉพาะ field ที่ต้องการจากหลาย data source (DynamoDB, RDS, Lambda, HTTP) ใน request เดียว + real-time subscription (push update ผ่าน WebSocket) + offline sync จุดออกสอบ: “mobile/web ต้อง query ข้อมูลรวมจากหลาย source แบบ flexible + real-time update + ลด over-fetching” → AppSync (GraphQL); ถ้าเป็น RESTful ธรรมดา → API Gateway

2.14 Event-driven, sync vs async, idempotency, throttling

Sync vs async — แกนตัดสินใจ:

• Synchronous (client รอผล): API Gateway→Lambda, ALB→app, request/response — เหมาะเมื่อ client ต้องได้คำตอบทันที trade-off: coupling แน่น, ถ้า downstream ช้า/ล่ม client กระทบทันที, scale ผูกกัน
• Asynchronous (fire-and-return): ส่งเข้า SQS/SNS/EventBridge แล้วประมวลผลเบื้องหลัง — decouple, absorb spike (queue เป็น buffer), fault isolation (downstream ล่ม message ยังอยู่), scale อิสระ trade-off: eventual consistency, ต้องจัดการ ordering/duplicate/monitoring เอง

หลักการ SA Pro: เมื่อโจทย์มีคำว่า decouple, spiky/unpredictable traffic, absorb burst, resilient to downstream failure, independent scaling → เอียงไปทาง async (SQS/SNS/EventBridge) หากมี real-time response required → sync

Idempotency — เพราะ SQS standard/SNS/EventBridge เป็น at-least-once (อาจส่งซ้ำ) consumer ต้องออกแบบให้ประมวลผลซ้ำแล้วผลไม่เปลี่ยน เช่น ใช้ idempotency key + เช็ค DynamoDB conditional write, หรือ dedup ด้วย unique constraint จุดออกสอบ: “message ถูก process หลายครั้งทำให้ charge ซ้ำ” → ทำ idempotency (ไม่ใช่แค่หวังว่า infra จะไม่ส่งซ้ำ) หรือใช้ FIFO ที่ dedup ได้

Throttling / backpressure — ป้องกัน downstream ล่มเมื่อ upstream พุ่ง:

• SQS + reserved concurrency ของ Lambda: queue absorb spike, Lambda ดึงตามกำลัง, reserved concurrency กันไม่ให้ทะลุ DB connection
• API Gateway throttling / usage plan: จำกัด rate ที่ front door
• RDS Proxy / connection pooling (ดูบทที่ 07): กัน Lambda จำนวนมากเปิด DB connection ล้น

---

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

3.1 เลือก compute platform (requirement → บริการ → trade-off)

Requirement / keyword	เลือก	เหตุผล / trade-off
event-driven, spiky, สั้น (<15 นาที), least ops	Lambda	จ่ายตาม use, scale อัตโนมัติ; ระวัง cold start + 15-min limit
container, least ops, ไม่อยากจัดการ node	Fargate (บน ECS)	serverless container; แพงกว่า EC2 ที่ workload ใหญ่คงที่
container + portability/k8s ecosystem	EKS	มาตรฐาน k8s; ops overhead สูงกว่า ECS
workload คงที่ใหญ่, ต้องการ GPU/Spot/custom, คุมต้นทุนสุด	EC2 (ASG) + mixed instances	ควบคุมเต็ม, Spot ถูก; ต้องบริหาร capacity เอง
BYOL license per physical core	EC2 Dedicated Host	เห็น/คุม socket; แพงและต้องบริหาร
งานรันนานเกิน 15 นาที / batch	Fargate / AWS Batch / EC2	Lambda timeout ไม่พอ
lightweight logic ที่ edge (header/redirect)	CloudFront Functions	ถูก, scale สูง; JS จำกัด

3.2 เลือก load balancer

Requirement / keyword	เลือก	เหตุผล
route ตาม URL path / host / header	ALB	เห็น L7
static IP / Elastic IP, ultra-low latency, UDP/TCP raw	NLB	L4, static IP
preserve client source IP	NLB	ส่ง source IP ผ่าน
expose เป็น PrivateLink endpoint service	NLB	PrivateLink ต้องมี NLB หน้า
integrate WAF / Cognito auth ที่ LB	ALB	NLB ไม่รองรับ
เสียบ firewall/IDS appliance แบบ transparent	GWLB	GENEVE (ดูบทที่ 04)
ต้องทั้ง static IP และ L7 path routing	GA หน้า ALB	GA=static IP, ALB=L7

3.3 เลือก messaging / integration

Requirement / keyword	เลือก	เหตุผล
buffer / decouple / smooth spike, worker ดึงตามกำลัง	SQS	queue, at-least-once
ordering + no duplicate (financial/order)	SQS FIFO	exactly-once + order
หนึ่ง event → หลาย consumer พร้อมกัน, throughput สูง	SNS (+ SQS fan-out)	pub/sub push
route ตามเนื้อหา event ไปหลายปลายทาง + AWS/SaaS events	EventBridge	content filtering, integration ครบ
orchestrate multi-step workflow + retry + long-running	Step Functions (Standard)	state machine, error handling
high-volume short event pipeline	Step Functions Express	throughput สูง
RESTful managed API + rate limit ต่อ customer	API Gateway	throttle, usage plan
GraphQL, query หลาย source, real-time subscription	AppSync	flexible query + push

---

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

4.1 Decoupled e-commerce order processing (async, resilient)

โจทย์: ระบบสั่งซื้อรับ order spiky (แคมเปญ), backend inventory/payment/shipping ทำงานช้ากว่า, cannot lose orders, ต้อง decouple และ scale อิสระ ระบบ downstream หลายตัวต้องรู้เมื่อมี order ใหม่

สถาปัตยกรรม:

1. API Gateway (HTTP API) → Lambda รับ order → validate + write ลง DynamoDB (ดูบทที่ 07) แล้ว publish event ไป SNS topic OrderPlaced
2. SNS fan-out → หลาย SQS queue: inventory-queue, payment-queue, shipping-queue แต่ละ service มี queue ของตัวเอง
3. แต่ละ service เป็น Lambda (event source mapping) หรือ Fargate ดึงจาก queue ตัวเอง, ประมวลผลแบบ idempotent (idempotency key ใน DynamoDB), มี DLQ ต่อ queue
4. reserved concurrency ที่ payment Lambda กัน DB overwhelm

ทำไมเลือกแบบนี้ / trade-off:

• SNS→SQS fan-out ให้ทั้ง fan-out (หนึ่ง event หลาย consumer) และ durability/buffer (queue เก็บไว้ถ้า service ล่ม) — ตอบ cannot lose orders และ decouple
• async ให้ absorb spike (queue เป็น buffer) และ downstream ล่มไม่กระทบ client — order ถูกรับไว้แล้ว
• idempotency + DLQ จัดการ at-least-once delivery และ failure โดยไม่ block
• trade-off: eventual consistency (order ไม่ได้ประมวลผลทันที), ต้อง monitoring queue depth/DLQ; ถ้าต้อง strict ordering ต่อ customer ต้องเปลี่ยนเป็น SNS FIFO + SQS FIFO (throughput ลด)
• ทางเลือกที่แย่กว่า: sync chain (API→Lambda→เรียก payment sync→shipping sync) จะ coupling แน่น, spike ทำ backend ล่มลามถึง client

4.2 Microservice API หลัง ALB บน ECS Fargate + Auto Scaling

โจทย์: หลาย microservice HTTP (/users, /orders, /catalog), ทีมเล็กไม่อยากบริหาร server/node, traffic แปรผัน, ต้องการ least operational overhead และ scale ตาม request

สถาปัตยกรรม:

1. ALB ทำ path-based routing: /users/*→target group A, /orders/*→B, /catalog/*→C
2. แต่ละ service เป็น ECS service บน Fargate (data plane serverless), แต่ละ task ได้ task IAM role เฉพาะ (least privilege)
3. ECS Service Auto Scaling ด้วย target tracking ที่ metric ALBRequestCountPerTarget หรือ CPU — scale task ตามโหลด; ใช้ Fargate + Fargate Spot capacity provider ผสมเพื่อลดต้นทุน
4. image ใน ECR (scan on push), ดึงผ่าน PrivateLink จาก private subnet

ทำไมเลือกแบบนี้ / trade-off:

• ALB L7 จำเป็นเพราะต้อง route ตาม path (NLB/GWLB ทำไม่ได้)
• Fargate ตอบ least operational overhead (ไม่มี node ให้ patch/scale) เหมาะทีมเล็ก + traffic แปรผัน
• ECS ไม่ใช่ EKS เพราะไม่มีความต้องการ k8s portability และ ECS ops ต่ำกว่า
• target tracking เป็น scaling policy ที่ least ops
• trade-off: Fargate แพงต่อหน่วยกว่า EC2 ที่โหลดสูงคงที่ — ถ้า workload โตใหญ่และคงที่มากอาจย้ายบางส่วนไป EC2 launch type; Fargate Spot ลดต้นทุนได้แต่ task อาจถูก reclaim (ต้องทน interruption)

4.3 Serverless workflow: image/document processing pipeline

โจทย์: ผู้ใช้ upload ไฟล์ ต้องประมวลผลหลายขั้น (virus scan → thumbnail → OCR → index) บางขั้นนานเกิน Lambda 15 นาที, ต้องการ retry อัตโนมัติ, เห็น state ของแต่ละงาน, และ least operational overhead

สถาปัตยกรรม:

1. upload ไป S3 (ดูบทที่ 06) → S3 event → EventBridge (หรือ trigger Step Functions ตรง)
2. Step Functions Standard orchestrate: state 1 scan (Lambda) → state 2 thumbnail (Lambda) → state 3 OCR ที่นานมาก (รันบน Fargate task ผ่าน service integration) → state 4 index ลง OpenSearch
3. แต่ละ state มี Retry (exponential backoff) + Catch ส่งงานที่ fail ไป error-handling branch/SNS แจ้งเตือน
4. ขั้นที่รอ human review ใช้ callback pattern (waitForTaskToken)

ทำไมเลือกแบบนี้ / trade-off:

• Step Functions Standard จัดการ orchestration + retry + long-running (สูงสุด 1 ปี) + visibility ของ state — แทนการเขียน Lambda เรียกกันเองที่ error handling เปราะและมองไม่เห็น state
• Fargate สำหรับขั้น OCR ที่เกิน 15 นาที (Lambda ทำไม่ได้) — ผสม Lambda (สั้น) + Fargate (นาน) ใน workflow เดียว
• EventBridge เป็น entry ที่ decouple S3 จาก workflow และ route ได้หลายชนิด event
• trade-off: Step Functions Standard คิดต่อ state transition — ถ้า volume มหาศาลและ workflow สั้น ควรพิจารณา Express (แต่เสีย exactly-once/history); ที่ volume ปานกลางและต้องการ audit → Standard คุ้ม

4.4 High-throughput ingestion หลัง NLB + Global Accelerator

โจทย์: IoT/game backend รับ UDP/TCP จำนวนมหาศาลทั่วโลก, ต้องการ static IP ที่ whitelist ได้, latency ต่ำสุด, และ failover ข้าม region เร็ว

สถาปัตยกรรม:

1. Global Accelerator (static anycast IP — ดูบทที่ 04) หน้าสุด
2. GA → NLB ต่อ region (L4, ultra-low latency, preserve source IP)
3. NLB → target group เป็น EC2 ASG (compute-optimized C-series) หรือ Fargate
4. failover: GA ตรวจ endpoint health แล้วสลับ region ระดับวินาที

ทำไมเลือกแบบนี้ / trade-off:

• NLB เพราะ non-HTTP (UDP), ultra-low latency, static IP, preserve source IP — ALB ทำไม่ได้
• GA ให้ static anycast IP + fast cross-region failover (DNS ช้าเพราะ TTL — ดูบทที่ 04) — ไม่ใช่ CloudFront (L7/HTTP/cache ไม่เหมาะ UDP)
• trade-off: GA มีค่า fixed hourly + data transfer; ถ้าเป็น HTTP ที่ cache ได้ CloudFront จะเหมาะกว่าและถูกกว่า

---

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

1. ตอบ ALB เมื่อโจทย์ต้องการ static IP / UDP / preserve source IP — สามอย่างนี้คือสัญญาณ NLB (ALB ไม่มี static IP, ไม่รองรับ UDP, ซ่อน source IP)
2. ตอบ NLB/GWLB เมื่อต้อง route ตาม URL path/host — L7 routing มีแต่ ALB เท่านั้น
3. เลือก EKS ทั้งที่โจทย์เน้น least operational overhead และไม่มีความต้องการ k8s — ECS (หรือ Fargate) ops ต่ำกว่า; EKS เมื่อมี k8s expertise/portability เท่านั้น
4. ใช้ Lambda กับงานที่รันเกิน 15 นาที — timeout สูงสุด 15 นาที → ใช้ Fargate/Batch/Step Functions+Fargate
5. สับสน reserved vs provisioned concurrency — reserved = จองเพดาน/จำกัด (protect downstream); provisioned = pre-warm ตัด cold start คนละวัตถุประสงค์
6. ใช้ instance store กับข้อมูลที่ต้อง persist — instance store หายเมื่อ stop/terminate → ต้อง EBS
7. ตอบ SNS เมื่อโจทย์ต้อง buffer/retry ให้ worker ดึงตามกำลัง — SNS push ไม่ persist; ต้อง SQS (หรือ SNS→SQS)
8. ตอบ SQS เดี่ยวเมื่อหนึ่ง event ต้องไปหลาย consumer — SQS เป็น point-to-point (message ไปหนึ่ง consumer) → ต้อง SNS fan-out หรือ EventBridge
9. ใช้ SNS เมื่อโจทย์ต้อง content-based routing / integrate AWS service events / SaaS — นั่นคือ EventBridge (SNS filter ได้แค่ message attribute ไม่ใช่ body ลึก)
10. ต่อ Lambda เรียกกันเองเป็นโซ่แล้วหวัง error handling ดี — orchestration ที่ต้อง retry/state/visibility คือ Step Functions
11. ลืม idempotency ในระบบ async — at-least-once delivery ทำให้ process ซ้ำ; ต้องออกแบบ idempotent (หรือ FIFO)
12. เลือก REST API เมื่อโจทย์เน้น cost-effective/simple proxy — HTTP API ถูกกว่า ~70% และ latency ต่ำกว่า; REST เมื่อต้องการ feature เต็ม (usage plan, VTL transform, API key ต่อ customer)
13. ตอบ predictive scaling กับ spike ที่ไม่มี pattern — predictive ต้องมี history เป็นรอบ; spike สุ่ม/ไม่รู้ล่วงหน้าให้ใช้ target tracking + buffer (SQS); รู้เวลาแน่นอนใช้ scheduled
14. ลืม Dedicated Host เมื่อเป็น BYOL per-core license — Dedicated Instance ให้ hardware แยกแต่ไม่เห็น socket; license ผูก core ต้อง Dedicated Host

---

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

ข้อ 1 — แอปมี microservice หลายตัวรับ HTTP และต้อง route ตาม URL path (/api, /static), ทีมเล็กต้องการ least operational overhead ในการรัน container โดยไม่บริหาร server ควรใช้อะไร?

A. NLB + EKS บน EC2 launch type B. ALB + ECS บน Fargate C. GWLB + EC2 ASG D. API Gateway REST + Lambda เท่านั้น

เฉลย

B — ALB ทำ L7 path routing, Fargate ให้ container โดยไม่ต้องบริหาร node (least ops), ECS ops ต่ำกว่า EKS

• A ผิด: NLB ไม่เห็น path (L7); EKS+EC2 ops สูงกว่ามาก
• C ผิด: GWLB เป็น appliance insertion ไม่ใช่ app routing; EC2 ต้องบริหารเอง
• D ผิด: Lambda อาจได้ แต่โจทย์ระบุ “รัน container” และ path routing ที่ ALB ทำตรงกว่า

ข้อ 2 — ระบบสั่งซื้อรับ order แบบ spiky, backend ประมวลผลช้ากว่า, ห้ามสูญเสีย order, และมี downstream หลายระบบ (inventory, payment, shipping) ต้องรู้ทุก order ใหม่พร้อมกัน ควรออกแบบอย่างไร?

A. API sync เรียก payment แล้ว shipping ต่อกันเป็นโซ่ B. SNS topic fan-out ไปหลาย SQS queue, แต่ละ service ดึงจาก queue ตัวเองแบบ idempotent + DLQ C. SQS queue เดียวให้ทุก service แย่งกันดึง D. EventBridge scheduler รัน batch ทุก 5 นาที

เฉลย

B — SNS fan-out ให้หนึ่ง event ไปทุก consumer; SQS ต่อ service ให้ buffer + durability + retry (ไม่สูญ order)

• A ผิด: sync chain coupling แน่น spike ทำ backend ล่มลามถึง client
• C ผิด: SQS เดี่ยวเป็น point-to-point message ไปแค่หนึ่ง consumer ไม่ fan-out
• D ผิด: batch เพิ่ม latency โดยไม่จำเป็นและไม่ตอบ fan-out realtime

ข้อ 3 — Lambda function ทำงาน CPU-intensive ช้ามาก ต้องการเร่งให้เร็วขึ้นโดย least effort ควรทำอะไรก่อน?

A. เพิ่ม memory ที่จัดสรรให้ function (memory=CPU) B. ย้ายไป EC2 ทันที C. เพิ่ม reserved concurrency D. เพิ่ม timeout เป็น 15 นาที

เฉลย

A — Lambda เพิ่ม memory จะเพิ่ม vCPU ตามสัดส่วน (memory=CPU) เร่ง CPU-bound งานได้ทันที และบ่อยครั้งถูกลงเพราะรันสั้นลง

• B ผิด: over-engineering, ยังไม่จำเป็นและ ops สูงขึ้น
• C ผิด: reserved concurrency คุมจำนวน invocation พร้อมกัน ไม่ได้เร่งความเร็วต่อ invocation
• D ผิด: timeout ไม่เพิ่มความเร็ว แค่ปล่อยให้รันนานขึ้น

ข้อ 4 — Distributed NoSQL cluster ต้องกระจาย node ให้การล่มของ rack เดียวไม่ทำ replica หายพร้อมกัน และต้องรู้ topology ควรใช้ placement group แบบใด?

A. Cluster placement group B. Spread placement group C. Partition placement group D. ไม่ใช้ placement group

เฉลย

C — partition placement group แบ่งเป็น partition คนละ rack, รองรับ node จำนวนมากต่อ partition, และ instance รู้ว่าตนอยู่ partition ใด (เหมาะ Cassandra/HDFS/Kafka)

• A ผิด: cluster รวมทุก instance ใน rack เดียว = correlated failure สูง
• B ผิด: spread จำกัด 7 instance ต่อ AZ ไม่พอสำหรับ cluster ใหญ่
• D ผิด: ไม่ควบคุมการกระจาย เสี่ยง replica อยู่ rack เดียวกัน

ข้อ 5 — ต้อง orchestrate workflow ประมวลผลเอกสารหลายขั้น มีขั้นที่รันนานเกิน 15 นาที, ต้องการ retry อัตโนมัติต่อ state และเห็น state ของแต่ละงานเพื่อ audit ควรใช้อะไร?

A. โซ่ Lambda เรียกกันเองพร้อม try/catch ในโค้ด B. AWS Step Functions Standard + Fargate สำหรับขั้นที่นาน C. SQS queue หลายตัวต่อกัน D. EventBridge rule เรียก Lambda

เฉลย

B — Step Functions Standard ให้ orchestration + retry/catch แบบ declarative + long-running (ถึง 1 ปี) + full execution history; Fargate รองรับขั้นที่เกิน Lambda 15 นาที

• A ผิด: error handling เปราะ, มองไม่เห็น state, ไม่มี durable history
• C ผิด: SQS ไม่ทำ orchestration/branching/retry-per-state
• D ผิด: EventBridge route event ได้แต่ไม่ orchestrate multi-step ที่มี state/retry ในตัว

ข้อ 6 — event เดียวต้อง route ไปหลายปลายทางต่างกันตาม เนื้อหาใน event body, ต้อง integrate กับ event จาก AWS service และ SaaS partner โดยเขียน glue code น้อยที่สุด ควรใช้อะไร? (cross-reference บทที่ 01)

A. SNS ที่มี message attribute filter B. SQS หลาย queue C. Amazon EventBridge (rule + content-based pattern) D. Kinesis Data Streams

เฉลย

C — EventBridge ทำ content-based routing (match ใน body), รับ AWS service events + SaaS partner events, มี target หลากหลาย และ Pipes ลด glue code

• A ผิด: SNS filter ได้แค่ message attribute ไม่ลึกถึง body และไม่รับ AWS/SaaS event bus
• B ผิด: SQS ไม่ทำ content routing/fan-out
• D ผิด: Kinesis เหมาะ streaming/ordered records ไม่ใช่ content-based event routing

ข้อ 7 — Pod บน Amazon EKS ต้องเข้าถึง S3 ด้วยสิทธิ์ที่จำกัดเฉพาะ pod นั้น (ไม่ใช่สิทธิ์ระดับ node ทั้งก้อน) ควรใช้อะไร? (cross-reference บทที่ 03)

A. hardcode IAM access key ใน pod B. IAM role ผูกกับ EC2 node ทั้งหมด C. IRSA (IAM Roles for Service Accounts ผ่าน OIDC) หรือ EKS Pod Identity D. instance profile ของ node group

เฉลย

C — IRSA map Kubernetes service account เข้ากับ IAM role ผ่าน OIDC ให้แต่ละ pod ได้ credential เฉพาะ (least privilege)

• A ผิด: hardcode key ละเมิดหลัก security (ดูบทที่ 03)
• B, D ผิด: node role/instance profile ให้สิทธิ์ระดับ node → ทุก pod บน node ได้สิทธิ์เท่ากัน ไม่ fine-grained

ข้อ 8 — Software เก่ามี Oracle license แบบ BYOL ที่คิดตาม physical core ต้องย้ายมา AWS โดยคง license เดิมและ compliance ต้องการควบคุม core mapping ควรใช้อะไร?

A. EC2 shared tenancy B. EC2 Dedicated Instance C. EC2 Dedicated Host D. Fargate

เฉลย

C — Dedicated Host ให้ physical server ทั้งเครื่อง เห็นและควบคุม socket/core mapping รองรับ BYOL per-core license

• A ผิด: shared tenancy ไม่เห็น hardware, ไม่รองรับ per-core BYOL
• B ผิด: Dedicated Instance ให้ hardware แยกแต่ไม่ให้ visibility ระดับ socket/core
• D ผิด: Fargate เป็น serverless container ไม่มี concept ของ physical core mapping

ข้อ 9 — Web fleet หลัง ALB ต้องการ most cost-effective โดยทน interruption ได้บางส่วน และต้องมี baseline capacity ที่เสถียร ควรตั้ง Auto Scaling อย่างไร?

A. On-Demand ทั้งหมด B. Spot ทั้งหมด C. Mixed instances policy: On-Demand base + Spot ส่วนที่เหลือ (capacity-optimized) D. Reserved Instances ทั้งหมดที่ max capacity

เฉลย

C — mixed instances policy ให้ On-Demand base รับประกัน baseline + Spot ส่วนที่เหลือเพื่อประหยัด; capacity-optimized ลด interruption (รายละเอียด Spot → บทที่ 10)

• A ผิด: On-Demand ทั้งหมดแพงเกินจำเป็นเมื่อ workload ทน interruption ได้
• B ผิด: Spot ทั้งหมดเสี่ยงไม่มี baseline เมื่อถูก reclaim พร้อมกัน
• D ผิด: RI ที่ max capacity จ่ายเต็มตลอดแม้ไม่ได้ใช้ (ขัด cost-effective สำหรับ variable load)

ข้อ 10 — API สาธารณะต้องจำกัด request rate ต่อ customer แต่ละราย, ออก API key, และ transform request/response ควรใช้อะไร และต่างจาก HTTP API อย่างไร?

A. HTTP API เพราะถูกกว่า B. REST API เพราะรองรับ usage plan + API key + request/response transform (VTL) C. WebSocket API D. AppSync

เฉลย

B — REST API มี usage plan + API key (จำกัดโควตาต่อ customer) และ VTL transform ครบ; HTTP API เบา/ถูกแต่ไม่มีฟีเจอร์เหล่านี้เต็ม

• A ผิด: HTTP API ถูกกว่าแต่ไม่มี usage plan/API key/transform เต็มรูปแบบ
• C ผิด: WebSocket สำหรับ two-way persistent ไม่ใช่ REST rate limiting
• D ผิด: AppSync เป็น GraphQL ไม่ตรงกับ RESTful + usage plan ต่อ customer

ข้อ 11 — Message ใน SQS ถูกประมวลผลซ้ำทำให้ลูกค้าถูก charge หลายครั้ง วิธีแก้ที่ถูกต้องที่สุดคือ?

A. หวังว่า SQS จะไม่ส่งซ้ำ B. ออกแบบ consumer ให้ idempotent (idempotency key + conditional write) และ/หรือใช้ FIFO queue C. ลด visibility timeout ให้ต่ำสุด D. เพิ่ม consumer ให้มากขึ้น

เฉลย

B — SQS standard เป็น at-least-once จึงต้องออกแบบ idempotent เอง; FIFO ช่วย dedup + ordering ได้เมื่อ requirement เข้ม

• A ผิด: standard delivery ซ้ำได้เสมอ พึ่งโครงสร้างไม่ได้
• C ผิด: ลด visibility timeout ยิ่งเสี่ยง message โผล่กลับก่อนประมวลผลเสร็จ = ซ้ำมากขึ้น
• D ผิด: เพิ่ม consumer ไม่แก้การประมวลผลซ้ำ

---

7. Cross-references

• บทที่ 01 — Exam Blueprint & SA-Pro Mindset: keyword mapping (decouple→SQS/SNS/EventBridge, least operational overhead→serverless/managed, spiky/unpredictable→async+queue, cost-effective→Spot/Graviton/Fargate Spot) ที่ใช้ตลอดบทนี้ บทนี้ตอบ cross-reference ที่บทที่ 01 ฝากมาเรื่อง decoupling ด้วย SQS/SNS/EventBridge/Step Functions (ตัวอย่างที่ 4.1 และคำถามข้อ 2, 6)
• บทที่ 03 — Identity, Access & Federation: instance profile + IMDSv2 บน EC2/ASG (ผูกผ่าน launch template — ข้อ 2.5), task IAM role บน ECS, และ IRSA (OIDC) สำหรับ EKS service account (ข้อ 2.7 และคำถามข้อ 7) — ตอบ cross-reference ที่บทที่ 03 ฝากมา
• บทที่ 04 — Networking at Scale: บทนี้เจาะ ALB/NLB/GWLB เต็มรูปแบบที่บทที่ 04 แตะเฉพาะ network insertion; PrivateLink endpoint service ต้องมี NLB หน้า (ข้อ 2.6); Global Accelerator หน้า ALB/NLB เพื่อ static IP (ตัวอย่าง 4.4); Lambda@Edge/CloudFront Functions รันบน CloudFront
• บทที่ 06 — Storage & Data Transfer: EBS volume type (gp3/io2) สำหรับ EC2, instance store detail, และ S3 event ที่ trigger Lambda/EventBridge (ตัวอย่าง 4.3) → ดูบทที่ 06
• บทที่ 07 — Databases & Data Migration: การเลือก database (DynamoDB สำหรับ idempotency store/order table, RDS Proxy สำหรับ connection pooling จาก Lambda) → ดูบทที่ 07
• บทที่ 08 — Resilience, HA & DR: DR ของ compute (multi-region failover ของ ASG/ECS/Lambda, pilot light/warm standby) และ ASG ในฐานะ self-healing HA primitive → ดูบทที่ 08
• บทที่ 10 — Cost Optimization: Spot strategy เชิงลึก (Spot Fleet/EC2 Fleet, capacity-optimized, interruption handling), Savings Plans สำหรับ Fargate/Lambda, การเลือก pricing model → ดูบทที่ 10
• บทที่ 11 — Operational Excellence & Monitoring: monitoring queue depth/DLQ, X-Ray tracing ของ event-driven, SSM Session Manager แทน bastion → ดูบทที่ 11
• บทที่ 13 — Modernization & Refactoring: กลยุทธ์ containerization (App2Container), monolith→microservices (strangler fig), serverless refactoring pattern ที่ใช้ compute/integration primitive จากบทนี้ → ดูบทที่ 13