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

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

บทนี้เป็นเจ้าของ Operational Excellence pillar และ Performance Efficiency pillar ของ Well-Architected Framework (นิยาม 6 pillars ดูบทที่ 01) ในบริบท Domain 3 ของ SAP-C02 (“Continuous Improvement for Existing Solutions”) ซึ่งเน้นคำถามแนว “ระบบทำงานอยู่แล้ว จะ observe / operate / automate / improve อย่างไรให้ least operational overhead”

เป้าหมายเมื่อจบบท คุณต้องตอบข้อสอบที่ผสมประเด็นเหล่านี้ได้อย่างมั่นใจ:

ออกแบบ observability ครบสามเสา (metrics / logs / traces) ด้วย Amazon CloudWatch + AWS X-Ray และรู้ว่าเมื่อไหร่ใช้ metric ธรรมดา, custom metric, high-resolution, EMF, หรือ Contributor Insights
ออกแบบ centralized logging ข้าม account ทั้ง organization (log archive account, subscription filter → Kinesis/OpenSearch) — ต่อยอดจาก governance บทที่ 02
ใช้ AWS Systems Manager ทั้ง suite เพื่อ operate fleet โดยไม่ต้อง SSH/bastion (Session Manager), patch เป็นมาตรฐาน (Patch Manager), และ automate remediation (Automation runbook)
เลือก Infrastructure as Code ที่เหมาะ (CloudFormation vs StackSets vs CDK) และรู้กลไก drift detection, change set, nested stack, StackSet ข้าม account/region
เลือก deployment strategy (in-place / blue-green / canary / linear) และออกแบบ rollback อัตโนมัติผ่าน CodePipeline/CodeDeploy
ประกอบ self-healing / auto-remediation จาก EventBridge + SSM Automation + AWS Config remediation
รู้กระบวนการ Well-Architected Review และ AWS Trusted Advisor ในฐานะเครื่องมือ continuous improvement

ขอบเขตที่บทนี้ไม่ลงลึก (cross-reference แทน): cost optimization และ Compute Optimizer เชิง cost → บทที่ 10; security detective controls (GuardDuty/Security Hub/Config compliance detail) → บทที่ 09; DR runbook / game day เชิง strategy → บทที่ 08 (บทนี้รับเฉพาะ กลไก automation ของ runbook). บทนี้สืบทอด convention <details><summary>เฉลย</summary> และ bullet “ทำไมตัวเลือกอื่นผิด” จากบท 01–10 และใช้ตาราง “requirement/keyword → บริการ → เหตุผล/trade-off” เป็นรูปแบบหลักของส่วนที่ 3

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

2.1 Operational Excellence pillar: กรอบคิด 4 หน้าที่

Operational Excellence ในระดับ Professional ไม่ใช่ “ตั้ง CloudWatch alarm” แต่คือความสามารถขององค์กรในการ run และ monitor systems เพื่อส่งมอบ business value และ improve อย่างต่อเนื่อง design principle สำคัญที่ข้อสอบชอบสะท้อน:

Perform operations as code — ทุกอย่าง (infra, runbook, response) เป็น code ที่ version ได้ → CloudFormation/CDK + SSM Automation runbook
Make frequent, small, reversible changes — deploy บ่อยครั้งเล็ก ๆ ที่ rollback ได้ → canary/linear deployment
Anticipate failure & learn from operational events — pre-mortem, game day, observability
Refine operations procedures frequently — WA Review ซ้ำ ๆ

จำ mental model นี้: สิ่งที่ทำด้วยมือ (manual/console) มักเป็นคำตอบผิดในข้อสอบ Pro เมื่อโจทย์พูดว่า repeatable, consistent across accounts, least operational overhead, auditable — คำตอบเกือบเสมอคือ automate ด้วย IaC + SSM + EventBridge

2.2 Observability สามเสา: Metrics / Logs / Traces

ต้องแยกให้ขาดว่าแต่ละเสาตอบคำถามคนละแบบ เพราะข้อสอบชอบให้เลือกเครื่องมือผิดเสา:

เสา	ตอบคำถาม	เก็บอะไร	เครื่องมือหลัก
Metrics	“ระบบสุขภาพดีไหม ตอนนี้/แนวโน้ม”	ตัวเลข time-series aggregate (CPU, latency p99, error rate)	CloudWatch Metrics + Alarms
Logs	“เกิดอะไรขึ้นกันแน่ในเหตุการณ์นี้”	event รายละเอียด (structured/unstructured)	CloudWatch Logs + Logs Insights
Traces	“request นี้ช้า/พังที่ service ไหนในห่วงโซ่”	end-to-end request path ข้าม service	AWS X-Ray + ServiceLens

หลัก: metric สำหรับ alarm/trend, log สำหรับ forensics, trace สำหรับ distributed bottleneck. ระบบ microservice/serverless ที่โจทย์บอกว่า “หา latency สะสมข้ามหลาย service ไม่เจอ” → คำตอบคือ X-Ray ไม่ใช่ CloudWatch metric

2.3 Amazon CloudWatch เชิงลึก

Metrics — CloudWatch เก็บ metric แบบ time-series ใน namespace โดยมีระดับสำคัญ:

Standard metrics — บริการ AWS ส่งให้อัตโนมัติ granularity 5 นาที (พื้นฐานฟรีของหลายบริการ) หรือ 1 นาทีเมื่อเปิด detailed monitoring (EC2 detailed monitoring มีค่าใช้จ่าย)
Custom metrics — แอปส่งเองผ่าน PutMetricData (เช่น business metric: orders/sec, queue backlog)
High-resolution metrics — granularity ถึง 1 วินาที (StorageResolution=1) สำหรับ workload ที่ spike เร็วต้อง react ในไม่กี่วินาที; high-resolution alarm ประเมินได้ทุก 10/30 วินาที — คำตอบเมื่อโจทย์ต้องการ sub-minute reaction
ข้อจำกัดสำคัญ: EC2 memory และ disk usage ไม่ใช่ standard metric — ต้องติดตั้ง CloudWatch unified agent ถึงจะได้ (จุดหลอกคลาสสิก: “monitor memory utilization” ตอบ agent เสมอ)

CloudWatch unified agent — agent เดียวเก็บทั้ง system-level metric (memory, disk, process) และ push logs ขึ้น CloudWatch Logs พร้อมกัน แทน agent เก่าสองตัว รองรับ on-prem ด้วย (hybrid observability) config ผ่าน SSM Parameter Store ได้

Embedded Metric Format (EMF) — วิธี emit log JSON ที่ CloudWatch สกัดเป็น metric อัตโนมัติ ทำให้ได้ทั้ง high-cardinality log และ metric จากการเขียนครั้งเดียว โดยไม่ต้องเรียก PutMetricData แยก (ลด API throttle/ต้นทุน) — เหมาะมากกับ Lambda ที่ต้องการ custom metric โดยไม่เพิ่ม latency จาก synchronous API call

Alarms:

Metric alarm — เฝ้า metric เดียวเทียบ threshold, มี state OK/ALARM/INSUFFICIENT_DATA, action → SNS / Auto Scaling / EC2 action / SSM
Composite alarm — รวมหลาย alarm ด้วย boolean logic (AND/OR) เพื่อ ลด alarm noise / alert fatigue — คำตอบเมื่อโจทย์บอก “ได้ alert มากเกินไป อยากแจ้งเฉพาะเมื่อหลายเงื่อนไขจริงพร้อมกัน”
CloudWatch anomaly detection — สร้าง ML band รอบ metric แล้ว alarm เมื่อหลุด band แทน static threshold — เหมาะ metric ที่มี pattern ตามเวลา (เช่น traffic กลางวัน/กลางคืน) ที่ static threshold ทำ false positive

Logs & Logs Insights — CloudWatch Logs เก็บเป็น log group/stream ตั้ง retention ต่อ group ได้ (ค่า default = never expire = จุดต้นทุนบานปลาย, ควรตั้ง retention). Logs Insights เป็น query language interactive สำหรับ ad-hoc analysis (เร็ว ไม่ต้อง ETL) — เหมาะ troubleshooting เฉพาะกิจ; ถ้าต้อง full-text search / dashboard เชิงลึก / long-term analytics ปริมาณมหาศาล → ส่งต่อ Amazon OpenSearch Service (ดู 2.5)

Metric filter vs subscription filter (แยกให้ขาด — ออกสอบบ่อย):

Metric filter — สแกน log ที่เข้ามาแล้วแปลง pattern เป็น CloudWatch metric (เช่น นับจำนวน “ERROR”) เพื่อ alarm
Subscription filter — stream log แบบ near-real-time ออกจาก log group ไป Kinesis Data Streams / Kinesis Data Firehose / Lambda / OpenSearch เป็นแกนหลักของ centralized logging

Synthetics (canaries) — script (Puppeteer/Selenium) รันตามตารางเพื่อ probe endpoint/flow จากภายนอกเหมือนผู้ใช้จริง → วัด availability/latency เชิง proactive ก่อน ผู้ใช้เจอปัญหา (outside-in). ต่างจาก metric ที่เป็น inside-out

RUM (Real User Monitoring) — เก็บ performance จริงจาก browser ของผู้ใช้ (page load, JS error, Core Web Vitals) — client-side observability; ตอบ cross-reference บทที่ 04 มุม CloudFront/performance ฝั่งผู้ใช้

Contributor Insights — วิเคราะห์ log/metric แบบ real-time เพื่อหา “top-N contributor” (เช่น top IP ที่ยิงมาก, top partition key ที่ throttle DynamoDB) — คำตอบเมื่อโจทย์ถาม who/what is causing the load เช่นหา hot partition (เชื่อมบทที่ 07)

Dashboards — CloudWatch dashboard รวม widget ข้าม region และ ข้าม account ได้ (cross-account observability) เพื่อ single pane of glass

2.4 AWS X-Ray, ServiceLens และ distributed tracing

X-Ray เก็บ trace ของ request ที่ propagate ผ่าน trace header (X-Amzn-Trace-Id) ข้าม service สร้าง service map ให้เห็น topology + latency + error rate ต่อ node การ instrument:

ทางง่าย/least-ops: เปิด active tracing บน Lambda, API Gateway, App Mesh หรือใช้ ALB ที่ inject trace header
ทางลึก: ฝัง X-Ray SDK หรือ AWS Distro for OpenTelemetry (ADOT) ในโค้ด (ADOT = คำตอบเมื่อโจทย์ต้องการ open standard / vendor-neutral / OpenTelemetry)
ใช้ sampling rule ควบคุมสัดส่วน trace ที่เก็บ เพื่อคุมต้นทุนบน high-throughput

ServiceLens รวม trace (X-Ray) + metric + log เข้าด้วยกันบน service map เดียว ให้ correlate จาก “node ช้า” → drill ไป trace → ไป log ได้ในที่เดียว

2.5 Centralized logging ข้าม account (สถาปัตยกรรมหลักของ Domain 3)

ต่อยอด multi-account governance (บทที่ 02: Log Archive account อยู่ใน Security OU) รูปแบบมาตรฐาน:

แต่ละ member account มี log group และ cross-account CloudWatch observability / CloudWatch cross-account sharing เพื่อ view รวม หรือ
ใช้ subscription filter ต่อ log group ส่ง log ไป Kinesis Data Streams ที่ centralized logging account → Firehose → OpenSearch/S3, หรือ
AWS CloudTrail organization trail และ AWS Config aggregator ส่งเข้า Log Archive account (บทที่ 02/09)

ตัดสินใจ sink: ต้องการ query/search/visualize เชิง log analytics → OpenSearch; ต้องการเก็บถูก long-term + query ครั้งคราว → S3 + Athena (เชื่อมบทที่ 06/07); ต้องการ near-real-time stream ให้หลาย consumer → Kinesis Data Streams; ต้องการ managed delivery ไม่เขียน consumer → Firehose

2.6 AWS Systems Manager (SSM): operate fleet ทั้งชุด

SSM เป็นกล่องเครื่องมือ operation ที่ข้อสอบ Pro รักมาก เพราะแทบทุกฟีเจอร์ตอบ least operational overhead / no bastion / consistent / auditable:

Capability	ทำอะไร	keyword ที่ชี้มาหา
Session Manager	shell เข้า instance ผ่าน SSM agent ไม่ต้องเปิด port 22/RDP, ไม่ต้อง bastion, ไม่ต้อง SSH key; log ทุก session ลง S3/CloudWatch	no bastion, no inbound port, audit shell access
Run Command	รันคำสั่ง/script ทีเดียวบน fleet ตาม tag/target	run script across fleet, ad-hoc
Patch Manager	นิยาม patch baseline + maintenance window patch OS/app ตามตารางทั้ง fleet, รายงาน compliance	standardize patching, compliance report
State Manager	บังคับให้ instance คงอยู่ใน desired state ต่อเนื่อง (association) เช่น agent installed/config นี้เสมอ	enforce configuration continuously
Automation runbook	workflow อัตโนมัติหลายขั้น (SSM document) เช่น restart, snapshot-then-patch, remediate	automated remediation, operational workflow
OpsCenter	รวม operational issue (OpsItem) จากหลายแหล่งเป็น central queue + contextual data + suggested runbook	aggregate operational issues, central ops view
Parameter Store	เก็บ config/secret hierarchical (ดูบทที่ 09 สำหรับ secret vs Secrets Manager)	store config, hierarchical parameters
Fleet Manager / Inventory	inventory software/patch/config ของ fleet	fleet visibility

Session Manager โดยเฉพาะ ตอบ cross-reference บทที่ 05/09: แทน bastion host ทั้งหมด ลด attack surface (ไม่ต้องเปิด inbound) และให้ audit trail ครบผ่าน CloudTrail + session log

2.7 Infrastructure as Code: CloudFormation, StackSets, CDK

AWS CloudFormation — declarative template (YAML/JSON) → stack ของ resource กลไกที่ออกสอบ:

Change set — preview ว่าการ update จะ create/modify/delete อะไร ก่อน execute (ป้องกัน replacement ที่ทำ data loss เช่น RDS rename)
Drift detection — ตรวจว่า resource ถูกแก้นอก CloudFormation (manual console) จน “drift” จาก template หรือไม่ (เชื่อม Control Tower drift บทที่ 02)
Nested stacks — แตก template ใหญ่เป็น reusable child stack (DRY) เมื่อชนขีดจำกัด resource/template ต่อ stack
StackSets — deploy stack เดียวกัน ข้ามหลาย account และหลาย region พร้อมกันจากที่เดียว โดยผูกกับ AWS Organizations (service-managed permission) → auto-deploy ไป account ใหม่ที่ join OU; นี่คือคำตอบเมื่อโจทย์ว่า “baseline resource เหมือนกันทุก account ทั้ง org, account ใหม่ต้องได้อัตโนมัติ”
DeletionPolicy / UpdateReplacePolicy = Retain/Snapshot ป้องกัน stateful resource หายตอน stack update/delete
Helper: cfn-init/cfn-signal + CreationPolicy/WaitCondition, DependsOn คุมลำดับ

AWS CDK — เขียน infra ด้วยภาษาโปรแกรม (TypeScript/Python/…) แล้ว synth เป็น CloudFormation template ได้ abstraction (construct), loop/condition แบบภาษาจริง, unit test infra — เหมาะทีม dev ที่ต้องการ logic/reuse สูง; ปลายทางยังเป็น CloudFormation stack

เลือก IaC อย่างไร: ต้อง declarative มาตรฐาน AWS-native, ทีม ops → CloudFormation; ต้อง programmatic/abstraction/test → CDK; ต้อง multi-cloud หรือทีมใช้ Terraform อยู่แล้ว → Terraform (รวม AFT บทที่ 02) [uncertain รายละเอียด provider feature ล่าสุด]; ต้อง deploy ข้าม account/region ทั้ง org → StackSets

2.8 CI/CD และ deployment strategies

AWS native pipeline: CodePipeline (orchestrator) → CodeBuild (build/test) → CodeDeploy (deploy) เก็บ artifact ที่ CodeArtifact, image ที่ ECR (บทที่ 05); โจทย์อาจใช้ third-party (Jenkins/GitHub Actions) — หลักการ deployment strategy เหมือนกัน

Strategy	กลไก	downtime/risk	เหมาะกับ
In-place (rolling)	อัปเดต instance เดิมทีละชุด	เสี่ยง mixed-version, rollback ช้า	dev, ยอม downtime สั้น
Blue/Green	ยก environment ใหม่ (green) ทั้งชุดแล้ว switch traffic; blue ยังอยู่	rollback เร็ว (switch กลับ), ต้นทุน 2 เท่าชั่วคราว	prod ที่ต้อง minimal downtime + fast rollback
Canary	ปล่อยให้ traffic ส่วนน้อย (เช่น 10%) ก่อน แล้วค่อยยกที่เหลือ	จำกัด blast radius, ตรวจก่อนเต็ม	prod ที่ต้อง validate กับ traffic จริง
Linear	เพิ่ม traffic เป็นขั้นเท่า ๆ กัน (เช่น +10% ทุก 10 นาที)	ค่อยเป็นค่อยไป	prod, มี alarm คอยเฝ้า

CodeDeploy รองรับ blue/green บน EC2/ASG, ECS, และ Lambda (canary/linear ผ่าน alias shifting) พร้อม automatic rollback เมื่อ CloudWatch alarm trip ระหว่าง deploy — นี่คือ safety loop ที่โจทย์ชอบ: “deploy แล้ว error rate พุ่งให้ย้อนอัตโนมัติ”

2.9 Self-healing / auto-remediation

รูปแบบ event-driven ที่เป็นแกนซ้ำ (ต่อยอด บทที่ 09 ที่ใช้เป็น security response):

CloudWatch alarm / EC2 status check → EC2 auto-recovery หรือ ASG replace unhealthy → self-heal ระดับ instance
Amazon EventBridge rule (จับ event/finding) → target = SSM Automation runbook / Lambda / Step Functions → remediate อัตโนมัติ
AWS Config rule → remediation action (SSM Automation) → บังคับ resource กลับ compliant (เช่น เปิด encryption, ปิด public access) — detective+responsive; รายละเอียด Config compliance เชิง security ดูบทที่ 09
EventBridge Scheduler สำหรับ operational task ตามเวลา (แทน cron บน instance)

2.10 Performance Efficiency pillar & continuous improvement

Performance Efficiency = ใช้ resource ให้ตรง/มีประสิทธิภาพและ evolve ตามเทคโนโลยีใหม่ design principle: democratize advanced tech (ใช้ managed service แทน build เอง), go global in minutes, use serverless, experiment often, mechanical sympathy (เลือก resource ให้ตรง workload)

เครื่องมือ continuous improvement ที่ต้องรู้:

AWS Compute Optimizer — มุม performance: ชี้ instance ที่ under-provisioned (คอขวด) ไม่ใช่แค่ over-provisioned (มุม cost อยู่บทที่ 10) โดยใช้ CloudWatch metric เป็นฐาน
AWS Trusted Advisor — ตรวจ 5 หมวด (cost, performance, security, fault tolerance, service limits/quota); service limit check เชื่อม Service Quotas ที่ตั้ง alarm ก่อนชน quota ได้
Well-Architected Tool — ทำ WA Review อย่างเป็นระบบต่อ workload: ตอบคำถามตาม 6 pillars → ได้ list of high/medium risk (HRI/MRI) + improvement plan; ทำซ้ำเป็น cadence = continuous improvement; รองรับ custom lens และ profile

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

3.1 requirement/keyword → observability service

โจทย์บอกว่า…	บริการ/ฟีเจอร์	เหตุผล / trade-off
monitor memory/disk บน EC2	CloudWatch unified agent	memory/disk ไม่ใช่ standard metric ต้องมี agent
react ต่อ spike ใน seconds	high-resolution metric + alarm	granularity 1s, alarm ทุก 10/30s; standard 1-5 นาทีช้าเกิน
custom metric จาก Lambda ไม่เพิ่ม latency	EMF	สกัด metric จาก log ไม่ต้องเรียก PutMetricData synchronous
ลด alert noise/แจ้งเมื่อหลายเงื่อนไขจริงพร้อม	composite alarm	รวมด้วย boolean, ตัด false alert
threshold คงที่ทำ false positive เพราะ pattern ตามเวลา	anomaly detection	ML band ปรับตาม seasonality
หา top contributor / hot key	Contributor Insights	จัดอันดับ top-N real-time
probe endpoint outside-in ก่อนผู้ใช้เจอ	Synthetics canary	simulate user flow ตามตาราง
performance จริงจาก browser ผู้ใช้	RUM	client-side, Core Web Vitals
หา latency ข้าม microservices	X-Ray + ServiceLens	trace end-to-end, service map
open standard / vendor-neutral tracing	ADOT (OpenTelemetry)	หลีกเลี่ยง lock-in
ad-hoc query log เร็ว	Logs Insights	interactive ไม่ต้อง ETL
full-text search + dashboard log ปริมาณมหาศาล	subscription filter → OpenSearch	Logs Insights ไม่เหมาะ analytics หนัก

3.2 requirement → Systems Manager capability

โจทย์บอกว่า…	SSM capability	เหตุผล
shell เข้า instance ไม่มี bastion / ไม่เปิด port	Session Manager	ผ่าน SSM agent, audit ครบ, ลด attack surface
patch OS ทั้ง fleet เป็นมาตรฐาน + compliance	Patch Manager	baseline + maintenance window
รันคำสั่งเดียวข้าม fleet ตาม tag	Run Command	ไม่ต้อง login ทีละเครื่อง
บังคับ config ให้คงอยู่ต่อเนื่อง	State Manager	association ตรวจ+แก้ให้ตรง desired
automate หลายขั้น (remediate/snapshot)	Automation runbook	workflow เป็น code, reuse
รวม operational issue เป็น central queue	OpsCenter	OpsItem + context + suggested runbook

3.3 IaC & deployment decision

requirement	เลือก	เหตุผล / trade-off
baseline resource เหมือนกัน ทุก account ทั้ง org + account ใหม่ auto	CloudFormation StackSets (service-managed)	deploy ข้าม account/region จากที่เดียว, auto-enroll
preview ผลกระทบก่อน update	change set	เห็น replacement ก่อนเกิด data loss
ตรวจว่ามีใครแก้ manual นอก IaC	drift detection	เทียบกับ template
ต้องการ programmatic abstraction + test infra	CDK	synth เป็น CFN, ใช้ logic ภาษาจริง
multi-cloud / ทีมใช้ Terraform	Terraform / AFT	[uncertain] provider feature
deploy prod minimal downtime + fast rollback	Blue/Green	switch กลับได้ทันที, ต้นทุน 2x ชั่วคราว
validate กับ traffic จริงก่อนเต็ม	Canary / Linear	จำกัด blast radius, auto-rollback ด้วย alarm

3.4 self-healing pattern

trigger	target	ผลลัพธ์
EC2 system status check fail	EC2 auto-recovery / ASG replace	self-heal instance
CloudWatch alarm (error/latency)	CodeDeploy auto-rollback	ย้อน deploy อัตโนมัติ
EventBridge จับ finding/event	SSM Automation runbook	remediate (restart/isolate/snapshot)
Config rule non-compliant	Config remediation (SSM Automation)	บังคับ resource compliant

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

4.1 Centralized observability ข้าม organization (log archive + OpenSearch)

โจทย์: องค์กรมี ~120 account ต้องการ single pane of glass ของ metric/log/trace, เก็บ audit log แบบ tamper-evident, ทีม security ค้น log ได้ทั้ง org, least operational overhead และ account ใหม่ต้อง onboard อัตโนมัติ

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

CloudWatch cross-account observability: ตั้ง monitoring account (มักเป็น Audit/Security Tooling account) เป็น sink, member account เป็น source → ดู metric/log/dashboard/X-Ray รวมได้โดยไม่ย้ายข้อมูล
Application log: แต่ละ log group ตั้ง subscription filter → Kinesis Data Streams (centralized logging account) → Firehose → Amazon OpenSearch Service สำหรับ full-text search + dashboard
Audit log: CloudTrail organization trail + Config aggregator → Log Archive account (S3 + Object Lock/Compliance mode สำหรับ WORM — บทที่ 06/09)
Rollout: baseline (agent config, subscription filter, IAM role) deploy ด้วย CloudFormation StackSets service-managed → account ใหม่ที่ join OU ได้ auto

Trade-off: OpenSearch ให้ search/dashboard ทรงพลังแต่มีต้นทุน cluster ต่อเนื่อง + ต้อง sizing (ถ้าปริมาณไม่แน่นอน พิจารณา OpenSearch Serverless [uncertain]); ทางเลือกถูกกว่าคือ S3 + Athena ถ้าการค้นเป็น occasional ไม่ต้อง real-time. เลือก cross-account observability (native) แทน self-host aggregator ตาม least ops. แลก: การ query ข้าม account มี boundary permission ต้องจัดการ

4.2 No-bastion operations + auto-patching + auto-remediation

โจทย์: fleet EC2 หลายร้อยเครื่องหลาย account, security กำหนดว่าห้ามเปิด inbound 22/3389, ต้อง patch เป็นมาตรฐานทุกเดือนพร้อม compliance report, และเมื่อ config drift (เช่น SG เปิด public) ต้องแก้อัตโนมัติ

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

Session Manager สำหรับ admin เข้า shell → ปิด inbound port ทั้งหมด, log ทุก session ลง S3/CloudWatch (audit) → ตอบข้อกำหนด security
Patch Manager: patch baseline + maintenance window ต่อ environment, กระจายผ่าน SSM ตาม tag; รายงาน compliance รวมใน OpsCenter
State Manager: บังคับให้ SSM agent + CloudWatch agent installed เสมอ
Auto-remediation: AWS Config rule (เช่น restricted-ssh, s3-no-public) → remediation = SSM Automation runbook แก้กลับ; finding ระดับ threat → EventBridge → SSM Automation (ดูบทที่ 09 สำหรับ security detail)
Baseline ทั้งหมด vend ด้วย StackSets/Control Tower (บทที่ 02)

Trade-off: Session Manager ต้องมี SSM agent + endpoint (interface VPC endpoint ถ้า private ไม่มี NAT — เชื่อมบทที่ 04) และ IAM instance profile ที่ถูก; แลกความสะดวก no-bastion กับการต้องดูแล agent/endpoint. auto-remediation ต้องระวัง remediation loop / แก้ผิดจังหวะ production — ควรมี approval step ใน Automation สำหรับ change ที่เสี่ยง (static stability, บทที่ 08)

4.3 Safe deployment pipeline พร้อม auto-rollback

โจทย์: ทีม deploy microservice (ECS Fargate) วันละหลายครั้ง ต้อง minimal downtime, จับ regression ก่อนกระทบผู้ใช้ทั้งหมด, และย้อนอัตโนมัติเมื่อ error พุ่ง — ทั้งหมดเป็น operations-as-code

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

CodePipeline: source (CodeCommit/GitHub) → CodeBuild (build + unit test, push image → ECR) → CodeDeploy (blue/green บน ECS)
CodeDeploy canary: shift 10% → bake window เฝ้า CloudWatch alarm (5xx rate, p99 latency) + X-Ray/ServiceLens → ถ้า alarm ALARM = automatic rollback ไป blue task set ทันที; ถ้าเขียว shift ที่เหลือ
Synthetics canary probe endpoint หลัง deploy เป็น gate เพิ่ม; EventBridge จับ deployment event ส่ง notify
Infra ทั้งหมด (cluster, pipeline, alarm) เป็น CDK/CloudFormation → operations as code

Trade-off: blue/green บน ECS ใช้ capacity สองชุดชั่วคราว (ต้นทุน + ต้องมี quota — เชื่อม Service Quotas); canary bake ทำให้ deploy ช้าลงแต่ปลอดภัยกว่า in-place. ทางเลือก in-place rolling ถูก/เร็วกว่าแต่ rollback ช้าและมี mixed-version — ไม่เหมาะ prod ที่ต้อง minimal downtime

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

ลืมว่า memory/disk ต้องใช้ CloudWatch agent — เลือก “enable detailed monitoring” เพื่อดู memory (ผิด; detailed monitoring แค่ทำให้ granularity 1 นาทีของ metric ที่มีอยู่ ไม่เพิ่ม memory metric)
ใช้ metric แทน trace — โจทย์ latency ข้าม microservice แต่ไปเลือก CloudWatch metric/dashboard; คำตอบคือ X-Ray
ใช้ Logs Insights แทน OpenSearch (หรือกลับกัน) — ad-hoc query ครั้งคราว = Logs Insights; full-text search + dashboard analytics ต่อเนื่องปริมาณมหาศาล = OpenSearch
สับสน metric filter กับ subscription filter — นับ pattern เป็น metric = metric filter; stream log ออกไป Kinesis/OpenSearch = subscription filter
แก้ alert fatigue ผิดทาง — ไปปรับ threshold ทีละ alarm แทนใช้ composite alarm
เลือก static threshold ให้ metric ที่มี seasonality — ควร anomaly detection
มองข้าม StackSets — โจทย์ “deploy เหมือนกันทุก account ทั้ง org” แล้วเลือก run CloudFormation ทีละ account ด้วยมือ (ผิด least-ops); คำตอบ StackSets service-managed
ลืม change set / DeletionPolicy — update stack แล้ว RDS/EBS ถูก replace หายข้อมูล; ควร preview ด้วย change set และตั้ง DeletionPolicy: Retain/Snapshot
เลือก bastion แทน Session Manager — ยังตอบ “harden bastion host” ทั้งที่ Session Manager ตัด bastion ทิ้งทั้งก้อน (no inbound, audit ครบ)
สับสน Session Manager vs Run Command — เข้า interactive shell = Session Manager; รันคำสั่ง batch ข้าม fleet = Run Command
in-place deploy ทั้งที่โจทย์ขอ minimal downtime + fast rollback — คำตอบ blue/green หรือ canary + auto-rollback ด้วย alarm
auto-remediation โดยไม่มี guardrail — ลืมว่า remediation ที่แก้ production อัตโนมัติต้องมี approval/safety สำหรับ change เสี่ยง
สับสน Compute Optimizer มุม cost vs performance — บทนี้เน้น under-provisioned (คอขวด performance); over-provisioned เชิง cost อยู่บทที่ 10
มองข้าม Service Quotas / Trusted Advisor limit check — โจทย์ “launch เพิ่มไม่ได้เพราะชน limit” คำตอบคือ monitor Service Quotas และตั้ง CloudWatch alarm ก่อนชน ไม่ใช่ scale เฉย ๆ
ใช้ Contributor Insights ผิดที่หรือไม่นึกถึง — โจทย์ “หา top talker / hot partition key” คำตอบคือ Contributor Insights ไม่ใช่ dashboard ธรรมดา

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

ข้อ 1. ทีมงานต้อง monitor memory utilization และรวบรวม application log จาก EC2 หลายร้อยเครื่องขึ้น CloudWatch ด้วย overhead น้อยที่สุด ควรทำอย่างไร

เฉลย

ติดตั้ง **CloudWatch unified agent** แล้วจัดการ config ผ่าน SSM (เช่น State Manager/Parameter Store) — agent เดียวเก็บทั้ง memory/disk metric และ push log ได้พร้อมกัน

“เปิด EC2 detailed monitoring”: ผิด — ให้แค่ granularity 1 นาทีของ metric ที่มีอยู่ (CPU/network) ไม่มี memory metric
“เขียน script เรียก PutMetricData เอง + push log แยก”: ทำได้แต่ overhead สูง ต้องดูแล script เอง ไม่ใช่ least ops
“ใช้ X-Ray”: ผิดเสา — X-Ray สำหรับ trace ไม่ใช่ system metric/log

ข้อ 2. ระบบ microservice บน ECS มีอาการ request ช้าเป็นครั้งคราว แต่ทีมหา service ต้นเหตุใน chain ไม่เจอจาก metric/log แยกส่วน ควรใช้อะไร

เฉลย

**AWS X-Ray** (ดู service map + trace) เสริมด้วย **ServiceLens** เพื่อ correlate trace+metric+log; instrument ผ่าน active tracing หรือ ADOT

“สร้าง CloudWatch dashboard รวม metric ทุก service”: เห็นภาพรวมแต่ไม่ตอบว่า request เดี่ยวช้าที่ node ไหน
“เพิ่ม log verbosity + Logs Insights”: ช่วย forensics แต่ไม่ให้ end-to-end trace อัตโนมัติข้าม service
“เปิด high-resolution metric”: ช่วยเรื่อง granularity ไม่ใช่การ trace ข้าม service

ข้อ 3. องค์กร 100+ account ต้องการให้ทุก account มี CloudWatch agent config + subscription filter ส่ง log ไป central account เหมือนกัน และ account ใหม่ที่ join organization ต้องได้ config นี้อัตโนมัติ ด้วย overhead ต่ำสุด

เฉลย

ใช้ **CloudFormation StackSets แบบ service-managed** ผูกกับ AWS Organizations กำหนด target เป็น OU → deploy อัตโนมัติ รวมถึง auto-deploy ไป account ใหม่ที่ join OU

“รัน CloudFormation ทีละ account ด้วยมือ/สคริปต์”: ไม่ scale, account ใหม่ไม่ auto = ไม่ least ops
“ให้แต่ละทีม deploy เอง”: inconsistent, ละเมิด governance
“ใช้ Config เท่านั้น”: Config ตรวจ compliance ได้แต่ไม่ deploy baseline resource เอง

ข้อ 4. ทีม ops บ่นว่าได้รับ alert มากเกินไป เพราะ alarm แต่ละตัวยิงแยกกันแม้เป็นเหตุการณ์เดียว ต้องการแจ้งเฉพาะเมื่อ “error rate สูง และ latency สูง และ healthy host ต่ำ” พร้อมกัน

เฉลย

สร้าง **composite alarm** รวม metric alarm หลายตัวด้วย boolean logic (AND) แล้วส่ง notification จาก composite alarm ตัวเดียว

“เพิ่ม threshold ทุก alarm”: ลด noise บางส่วนแต่ไม่แก้ปัญหาเชิงโครงสร้างและอาจพลาด true positive
“ใช้ anomaly detection”: แก้ false positive จาก seasonality ไม่ใช่การรวมเงื่อนไขหลาย metric
“ปิด alarm บางตัว”: เสี่ยงพลาด incident จริง

ข้อ 5. ต้องเข้า shell ของ EC2 ใน private subnet เพื่อ troubleshoot โดยฝ่าย security ห้ามเปิด inbound port ใด ๆ และต้องมี audit log ของทุก session

เฉลย

ใช้ **SSM Session Manager** (instance มี SSM agent + IAM instance profile + reachability ไป SSM endpoint) — ไม่ต้องเปิด inbound, ไม่ต้อง bastion/SSH key, log ทุก session ลง S3/CloudWatch

“ตั้ง bastion host ใน public subnet”: ยังเปิด inbound + เพิ่ม attack surface + ต้องดูแลเอง
“เปิด SG ให้ IP office เข้า 22”: ละเมิดข้อกำหนดห้ามเปิด inbound
“ใช้ Run Command”: รันคำสั่ง batch ได้แต่ไม่ใช่ interactive shell

ข้อ 6. ทีม deploy Lambda/ECS วันละหลายครั้ง ต้องการปล่อยเวอร์ชันใหม่กับ traffic ส่วนน้อยก่อน แล้วย้อนกลับอัตโนมัติถ้า error rate พุ่งภายในไม่กี่นาที

เฉลย

ใช้ **CodeDeploy canary (หรือ linear) deployment** shift traffic บางส่วน + bake window ที่ผูกกับ **CloudWatch alarm** → **automatic rollback** เมื่อ alarm ALARM

“in-place rolling update”: rollback ช้า, มี mixed-version, ไม่จำกัด blast radius
“blue/green switch 100% ทันที”: ปลอดภัยเรื่อง downtime แต่ไม่ได้ validate กับ traffic ส่วนน้อยก่อน (โจทย์ขอ subset ก่อน)
“deploy แล้วเฝ้าด้วยมือ”: ไม่ auto-rollback = ไม่ตรง requirement

ข้อ 7. ต้องบังคับว่าเมื่อ AWS Config พบ S3 bucket ที่เปิด public หรือ SG ที่เปิด SSH กว้าง ต้องแก้กลับให้ compliant อัตโนมัติทั้ง organization โดยไม่ต้องรอคนแก้

เฉลย

ใช้ **AWS Config rule + remediation action (SSM Automation runbook)** deploy เป็น conformance pack ทั้ง org (บทที่ 09) → non-compliant แล้ว remediate อัตโนมัติ; ทางเลือก event-driven คือ **EventBridge → SSM Automation/Lambda**

“GuardDuty”: ตรวจ threat behavior ไม่ใช่ config compliance remediation (บทที่ 09)
“แจ้ง SNS ให้คนแก้”: detective + manual ไม่ใช่ auto-remediation
“SCP บล็อก”: preventive ป้องกันการสร้างได้ แต่โจทย์ถามการ “แก้ resource ที่ผิดอยู่แล้ว” ให้กลับ compliant

ข้อ 8. DynamoDB table มี throttling เป็นระยะ ทีมสงสัยว่ามี partition key บางค่าถูกยิงหนักผิดปกติ (hot key) ต้องการระบุ key ต้นเหตุแบบ real-time

เฉลย

ใช้ **CloudWatch Contributor Insights** (มี rule สำเร็จรูปสำหรับ DynamoDB) เพื่อจัดอันดับ top partition key/most-throttled key แบบ real-time (เชื่อมบทที่ 07 เรื่อง hot partition + write sharding)

“CloudWatch dashboard ของ ConsumedCapacity”: เห็นว่ามี throttle แต่ไม่บอกว่า key ไหน
“Logs Insights”: query log ทั่วไปได้แต่ไม่ได้ออกแบบมาจัดอันดับ contributor real-time โดยตรง
“X-Ray”: trace request path ไม่ใช่การหา hot key ระดับ item

ข้อ 9. อยากประเมิน workload อย่างเป็นระบบตาม best practice ทั้ง 6 มิติ ได้รายการความเสี่ยงเรียงลำดับ + improvement plan และทำซ้ำเป็นรอบเพื่อ continuous improvement

เฉลย

ทำ **Well-Architected Review** ด้วย **AWS Well-Architected Tool** → ได้ High/Medium Risk Issues + improvement plan ต่อ pillar; เสริมด้วย **Trusted Advisor** สำหรับ check เชิงบริการ (cost/perf/security/fault tolerance/service limit)

“อ่าน CloudWatch dashboard”: operational monitoring ไม่ใช่ structured architecture review
“จ้าง audit ครั้งเดียว”: ไม่ใช่ continuous cadence และไม่ใช่ AWS-native tool
“เปิด Security Hub อย่างเดียว”: ครอบ security/compliance standard ไม่ครบทั้ง 6 pillars

ข้อ 10. Lambda ปริมาณสูงต้องการ emit custom business metric (เช่น จำนวน order) โดยไม่เพิ่ม latency จาก synchronous API call และไม่ชน API throttle ของ PutMetricData

เฉลย

ใช้ **Embedded Metric Format (EMF)** — เขียน structured log JSON ที่ CloudWatch สกัดเป็น metric อัตโนมัติแบบ asynchronous ผ่าน log ไม่ต้องเรียก PutMetricData ตรง

“เรียก PutMetricData ทุก invocation”: เพิ่ม latency + เสี่ยง throttle ที่ throughput สูง
“ตั้ง metric filter บน log”: ทำได้แต่ต้องออกแบบ pattern เอง; EMF เป็นวิธี native ที่ตรงกว่าและได้ dimension/high-cardinality
“ส่งไป Kinesis แล้วประมวลผลเอง”: overhead สูงเกินความจำเป็น

7. Cross-references

บทนี้รับ pending cross-reference จากบทก่อนและครอบคลุมแล้ว:

จากบทที่ 03 — CloudTrail audit ของ AssumeRole/federation events และ Config ตรวจ tag compliance: บทนี้ครอบใน centralized logging (2.5) + auto-remediation (2.9); รายละเอียด CloudTrail data/organization trail อยู่บทที่ 09
จากบทที่ 04 — VPC Flow Logs + CloudWatch network observability, CloudFront/RUM มุมผู้ใช้: ครอบใน RUM (2.3) และ log sink; Reachability/Network Access Analyzer เป็นเครื่องมือ network verify (อ้างอิงบทที่ 04)
จากบทที่ 05 — monitor queue depth/DLQ, X-Ray tracing event-driven, Session Manager แทน bastion: ครอบใน X-Ray (2.4), SSM Session Manager (2.6), Contributor Insights/metric สำหรับ queue
จากบทที่ 08 — CloudWatch health check/alarm เชิงลึก, monitor replication lag/RPO, runbook automation ด้วย SSM: ครอบใน alarm (2.3) + SSM Automation (2.6, 2.9); DR game day + AWS FIS fault injection เป็นของ resilience testing — ดูบทที่ 08 (บทนี้ให้เฉพาะ automation primitive) [uncertain FIS integration detail]
จากบทที่ 09 — SSM Automation/Patch Manager/Session Manager เชิง operation เต็ม, CloudWatch security metric/alarm, centralized logging: ครอบใน SSM suite (2.6) + centralized logging (2.5); Config compliance/GuardDuty/Security Hub detail = บทที่ 09
จากบทที่ 10 — performance tuning + observability เชิงลึก, Compute Optimizer มุม under-provisioned/performance: ครอบใน 2.10

บทนี้ฝาก/อ้างอิงไปบทอื่น:

บทที่ 10 — cost optimization, Compute Optimizer มุม over-provisioned/cost, CUR analytics
บทที่ 09 — security detective controls (GuardDuty/Config/Security Hub), CloudTrail data events, secret vs Parameter Store
บทที่ 08 — DR strategy/runbook เชิงกลยุทธ์, RTO/RPO, FIS/game day, replication lag monitoring
บทที่ 02 — Control Tower drift, StackSets ผูก Organizations, Log Archive/Audit account
บทที่ 06/07 — log sink S3+Athena vs OpenSearch, hot partition (Contributor Insights)
บทที่ 14 — decision framework observability/deployment แบบสังเคราะห์

ศัพท์ใหม่ที่นิยามในบทนี้ (ใช้ต่อในบทหลัง): high-resolution metric, Embedded Metric Format (EMF), composite alarm, CloudWatch anomaly detection, Contributor Insights, Synthetics canary, CloudWatch RUM, ServiceLens, ADOT, subscription filter, metric filter, unified agent, Session Manager, Patch Manager, State Manager, Automation runbook, OpsCenter, StackSets, change set, drift detection, deployment strategy (in-place/blue-green/canary/linear), Well-Architected Review, Trusted Advisor, Service Quotas