บทที่ 07: Databases & Data Migration

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

บทนี้ครอบคลุมชั้น “database” ทั้งหมดที่ workload พึ่งพา และกระบวนการ “data migration” ที่ย้ายฐานข้อมูลเข้าสู่ AWS — เกี่ยวข้องกับทั้ง Domain 2 (Design for New Solutions) และ Domain 4 (Accelerate Workload Migration & Modernization) หลังจากบทที่ 06 (ดูบทที่ 06 — Storage & Data Transfer) วาง storage primitive อย่าง object/block/file ให้แล้ว บทนี้คือ “ชั้นข้อมูลที่มีโครงสร้างและ query semantics” — และในระดับ Professional การเลือก database ผิดชนิดเป็นสาเหตุอันดับต้น ๆ ของ scaling ceiling ที่ทลายไม่ได้, latency ที่แก้ไม่ตก, และ re-architecture ที่แพงมหาศาลในภายหลัง

จุดที่ SA Pro ต่างจาก Associate ไม่ใช่การรู้ว่า “RDS คือ managed relational database” แต่คือการตอบได้ว่า เมื่อไหร่ควรเลือก relational (RDS/Aurora) vs key-value (DynamoDB) vs in-memory (ElastiCache/MemoryDB) vs purpose-built (Redshift/Neptune/DocumentDB/Keyspaces/Timestream), เมื่อไหร่ Multi-AZ พอ vs ต้อง Global Database, และย้าย database เดิมด้วย DMS แบบ minimal downtime อย่างไร โดยชั่ง trade-off ระหว่าง consistency, scalability, latency, RPO/RTO, cost และ operational overhead โจทย์มักซ่อน constraint เช่น single-digit millisecond latency at any scale, multi-region active-active, unpredictable spiky traffic, relational with cross-region read replicas, fully managed with least operational overhead, migrate with near-zero downtime, purpose-built for the data model — แต่ละคำชี้ไปที่บริการต่างกัน

บทที่ 05 ฝากมาว่า DynamoDB ในฐานะ idempotency/order store และ RDS Proxy สำหรับ connection pooling จาก Lambda ต้องครอบคลุมที่นี่; บทที่ 06 ฝากมาว่า storage layer ของ database engine และ AWS DMS สำหรับ database migration (คู่กับ DataSync/Snow ที่บท 06 ให้สำหรับ file/object) ต้องจัดการที่นี่ — จะครอบคลุมให้ครบ

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

เลือก database engine ตาม data model และ access pattern พร้อมเหตุผลเชิงสถาปัตยกรรม
แยก RDS Multi-AZ (HA, sync) vs read replica (scale reads, async) และออกแบบ RDS Proxy, Blue/Green Deployment, backup/PITR
เข้าใจ Aurora shared-storage architecture, Aurora Replica, Global Database (RPO/RTO), Serverless v2, cloning
ออกแบบ DynamoDB (partition key, GSI vs LSI, on-demand vs provisioned, DAX, Streams, Global Tables, TTL, transactions) โดยเลี่ยง hot partition
เลือก ElastiCache (Redis vs Memcached) และ purpose-built database ตาม data model
วางแผน migration ด้วย DMS + SCT (homogeneous vs heterogeneous) และจัดการ downtime ด้วย full load + CDC
เข้าใจ analytics stack (Athena/Glue/Lake Formation/EMR/Kinesis) เชิงสถาปัตยกรรมที่เชื่อมกับ data lake บน S3

ขอบเขต: generic object/file storage → บทที่ 06; DR strategy เชิง orchestration (pilot light/warm standby/backup & restore) → บทที่ 08 (บทนี้ให้เฉพาะ database primitive อย่าง Multi-AZ/replica/Global Database/PITR); modernization ไป purpose-built ด้วย strangler pattern และ Babelfish ในบริบท refactor → บทที่ 13 (บทนี้กล่าว Babelfish เชิงกลไก compatibility เท่านั้น)

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

2.1 แกนตัดสินใจแรก: data model → database category

ก่อนลงรายละเอียด ต้องแยก database ตาม data model เพราะ โจทย์มักตัดตัวเลือกได้ทันทีจากรูปแบบข้อมูล นี่คือ mental model แรกที่ SA Pro ต้องมี:

Data model / requirement	บริการหลัก	เหตุผล
Relational, ACID, SQL, joins ซับซ้อน	Amazon RDS, Amazon Aurora	schema คงที่, transaction, referential integrity
Key-value / document, scale ไม่จำกัด, latency ต่ำคงที่	Amazon DynamoDB	serverless NoSQL, single-digit ms ที่ any scale
In-memory cache / session / leaderboard	Amazon ElastiCache, MemoryDB	microsecond latency, ลด load จาก DB หลัก
Data warehouse / OLAP / analytics บน PB	Amazon Redshift	columnar, MPP, query ข้อมูลมหาศาล
Document (MongoDB-compatible)	Amazon DocumentDB	JSON document ที่ต้อง MongoDB API
Graph / relationship (social, fraud, recommendation)	Amazon Neptune	traverse ความสัมพันธ์ (Gremlin/SPARQL/openCypher)
Wide-column (Cassandra-compatible)	Amazon Keyspaces	Cassandra API แบบ serverless
Time-series (IoT, metrics, telemetry)	Amazon Timestream	เก็บ/query ข้อมูลตามเวลา, tiering อัตโนมัติ
Ledger / immutable audit trail	Amazon QLDB [uncertain สถานะ — ดู 2.13]	cryptographically verifiable history

หลักสำคัญของ SA Pro: purpose-built database — AWS สนับสนุนให้เลือก database ที่ตรงกับ access pattern ที่สุด แทนการยัดทุกอย่างลง relational database เดียว (one-size-fits-all เป็น anti-pattern) เมื่อโจทย์บรรยาย data model ชัด (graph, time-series, ledger) คำตอบมักคือ purpose-built ตัวนั้นตรง ๆ ไม่ใช่ RDS + custom logic

OLTP vs OLAP เป็นอีกแกนที่ต้องแยก: OLTP (transactional, read/write เล็ก ๆ จำนวนมาก, low latency) → RDS/Aurora/DynamoDB; OLAP (analytical, aggregate ข้อมูลมหาศาล) → Redshift/Athena เมื่อโจทย์บอก complex analytical queries over historical data หรือ reporting/BI → OLAP; high-throughput transactions → OLTP

2.2 Amazon RDS: engines และ managed model

Amazon RDS เป็น managed relational database รองรับ 6 engine: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, และ Amazon Aurora (Aurora เป็น engine พิเศษที่ AWS สร้างเอง — ดู 2.5) AWS จัดการ OS patching, backup, monitoring, failover ให้ แต่ ยังไม่ใช่ serverless — ต้องเลือก instance class และ storage เอง

Managed แลกกับ control: RDS ไม่ให้ SSH เข้า host และไม่ให้ superuser OS-level ทำให้ feature ที่ต้อง OS access (บาง extension, custom agent) ใช้ไม่ได้ — ถ้าโจทย์บอก need full OS control / custom database engine build ต้องไปทาง EC2 self-managed (แลก operational overhead สูงขึ้นมาก) ตัวกลางคือ RDS Custom (สำหรับ Oracle/SQL Server) ที่ให้ OS/database access บางส่วนสำหรับ legacy app ที่ต้องการ

Storage ของ RDS วางบน EBS (ดูบทที่ 06 — EBS volume types) เลือก gp3/io1/io2 ได้ และรองรับ storage autoscaling RDS ทำ automated backup (retention สูงสุด 35 วัน) + manual snapshot (เก็บได้ไม่จำกัดจนกว่าลบเอง) — automated backup เปิดใช้ Point-in-Time Recovery (PITR) คือ restore ไปช่วงเวลาใด ๆ ในกรอบ retention (ละเอียดถึงระดับวินาที) โดย restore เป็น instance ใหม่ เสมอ (ไม่ overwrite ตัวเดิม)

2.3 Multi-AZ vs Read Replica — จุดออกสอบสำคัญที่สุดของ RDS

นี่คือคู่ที่ผู้สอบสับสนบ่อยที่สุด ต้องแยกให้ขาด สองสิ่งนี้แก้ปัญหาคนละเรื่อง:

มิติ	Multi-AZ (HA)	Read Replica (scale reads)
วัตถุประสงค์	High Availability / failover	scale read traffic
Replication	synchronous ไปยัง standby	asynchronous ไป replica
Standby/replica รับ traffic?	ไม่ (standby เฉย ๆ รอ failover)¹	ใช่ — รับ read ได้ (endpoint แยก)
Failover อัตโนมัติ?	ใช่ (AWS สลับ DNS ให้ ~60-120 วินาที)	ไม่ (ต้อง promote manual/manual automation)
Cross-region?	ไม่ (Multi-AZ อยู่ใน region เดียว)²	ใช่ — read replica ข้าม region ได้
ผลต่อ RPO	RPO ≈ 0 (sync, ไม่เสียข้อมูล)	อาจมี replication lag (ข้อมูลหายได้ถ้า promote)
จำนวน	1 standby (หรือ 2 ใน Multi-AZ DB cluster)	สูงสุด 5-15 แล้วแต่ engine

¹ Multi-AZ DB cluster (ต่างจาก Multi-AZ instance เดิม) มี 2 readable standby ที่รับ read ได้ด้วย — เป็น deployment option ใหม่กว่า ² แก้ด้วยการสร้าง cross-region read replica แล้ว promote เมื่อต้อง DR ข้าม region (RPO ไม่เป็น 0 เพราะ async)

จุดตัดสินใจออกสอบ:

highly available / automatic failover / minimal downtime during AZ failure → Multi-AZ
read-heavy workload / offload reporting queries / scale reads → read replica
both → ทำทั้งคู่ (Multi-AZ + read replica พร้อมกันได้)
cross-region DR for relational database → cross-region read replica (async, RPO > 0) หรือใช้ Aurora Global Database ถ้าต้องการ RPO/RTO ต่ำกว่า (ดู 2.6)
กับดัก: Multi-AZ ไม่ได้ ช่วยเรื่อง read scaling (standby ไม่รับ traffic ในโหมด instance) — ถ้าโจทย์บอก scale reads แล้วเลือก Multi-AZ = ผิด

Failover ของ Multi-AZ เกิดเมื่อ AZ ล่ม, instance ล่ม, storage ล่ม, หรือตอน patching/instance-type change — AWS สลับไป standby โดยเปลี่ยน CNAME ของ endpoint เดิม (application ไม่ต้องเปลี่ยน connection string แต่ต้อง reconnect)

2.4 RDS Proxy — connection pooling (cross-ref บทที่ 05)

RDS Proxy เป็น managed connection pool ที่คั่นระหว่าง application กับ RDS/Aurora แก้ปัญหา connection exhaustion โดยเฉพาะจาก Lambda: Lambda scale เป็นพัน concurrent execution แต่ละตัวเปิด DB connection ของตัวเอง — relational database มี max_connections จำกัด จึงล้มเมื่อ burst (นี่คือ cross-reference ที่บทที่ 05 ฝากมา — Lambda + RDS Proxy)

RDS Proxy ทำ:

pooling & multiplexing — reuse connection จาก pool แทนเปิดใหม่ทุกครั้ง
failover เร็วขึ้น — proxy ถือ connection ไว้และ redirect ไป standby ใหม่ ลด failover time ที่ application เห็นได้ถึง ~66%
ดึง credential จาก Secrets Manager (ดูบทที่ 09) และ enforce IAM authentication

จุดออกสอบ: โจทย์ serverless application (Lambda) connecting to RDS experiencing “too many connections” errors → คำตอบคือ RDS Proxy (least ops) ไม่ใช่การเพิ่ม instance size หรือเขียน connection pool เอง

2.5 RDS Blue/Green Deployments

Blue/Green Deployment ของ RDS สร้าง green environment (สำเนา topology ของ production ที่ sync ด้วย logical replication) ให้ทำการเปลี่ยนแปลง (major version upgrade, schema change, parameter change) บน green แล้ว switch over ด้วย downtime ระดับวินาที (มัก < 1 นาที) โดย AWS จัดการ promotion + endpoint redirect ให้

ข้อดี: ทดสอบบน green ก่อนได้, rollback ง่าย (blue ยังอยู่), downtime ต่ำมาก — ตอบโจทย์ upgrade database engine version with minimal downtime (keyword minimal downtime — เชื่อมโยงบทที่ 01 keyword mapping) เทียบกับการ upgrade in-place ที่ downtime นานและ rollback ยาก

2.6 Amazon Aurora: architecture ที่ต่างจาก RDS ทั่วไป

Aurora เป็น engine ที่ AWS ออกแบบใหม่ (MySQL-compatible และ PostgreSQL-compatible) โดย แยก compute ออกจาก storage อย่างสิ้นเชิง — นี่คือหัวใจที่ทำให้ Aurora ต่างจาก RDS MySQL/PostgreSQL ธรรมดา:

Shared storage layer: ข้อมูลถูกเก็บใน distributed storage volume ที่กระจาย 6 copies ข้าม 3 AZ (2 copies ต่อ AZ) โดยอัตโนมัติ storage โตเองได้ถึง 128 TB (auto-scaling)
quorum-based durability: write สำเร็จเมื่อได้ 4/6 copies (write quorum), read ต้อง 3/6 — ทนต่อการเสีย 2 copies โดยไม่กระทบ write และเสียทั้ง AZ (3 copies) โดยยัง read ได้
compute แยกจาก storage: instance (writer/reader) ทั้งหมดเห็น storage เดียวกัน — จึงไม่ต้อง copy ข้อมูลไปแต่ละ replica (ต่างจาก RDS read replica ที่ copy จริง)

ผลลัพธ์เชิงสถาปัตยกรรม:

Aurora Replica (สูงสุด 15) แชร์ storage เดียวกับ writer → replication lag ต่ำมาก (มัก < 100 ms) และ failover เร็ว (promote replica เป็น writer ~30 วินาที เพราะไม่ต้อง copy data) — reader endpoint กระจาย read อัตโนมัติ
ประสิทธิภาพสูงกว่า RDS MySQL ~5 เท่า / PostgreSQL ~3 เท่า [uncertain ตัวเลขปัจจุบัน] เพราะ storage offload งาน redo log processing
cloning: สร้าง clone ของ database ได้เกือบทันทีด้วย copy-on-write (ไม่ copy ข้อมูลจริงจนกว่าจะเขียน) — เหมาะทำ test/dev environment จาก production โดยไม่เพิ่ม storage cost ทันที
backtrack (Aurora MySQL): ย้อน database กลับไปจุดเวลาก่อนหน้าได้โดยไม่ต้อง restore (in-place, เร็ว) — ต่างจาก PITR ที่สร้าง instance ใหม่

จุดตัดสินใจ: เมื่อโจทย์บอก MySQL/PostgreSQL-compatible + high availability + high performance + least ops → Aurora มักเหนือกว่า RDS ธรรมดา; endpoint ของ Aurora มี cluster endpoint (ชี้ writer), reader endpoint (load-balance ไป replica), และ custom endpoint (กลุ่ม instance ที่กำหนดเอง)

2.7 Aurora Global Database, Serverless v2, Babelfish

Aurora Global Database: replicate ข้าม region ผ่าน dedicated storage-level replication (ไม่ผ่าน compute) ได้ถึง 5 secondary region

RPO ต่ำ (ทั่วไป < 1 วินาที) และ RTO ระดับ < 1 นาที เมื่อ failover ข้าม region เพราะ replication ที่ storage layer มี latency ต่ำ (< 1 วินาที typical cross-region lag)
secondary region ใช้เป็น read replica ระดับ region ได้ (local low-latency read) และ promote เป็น primary ได้เมื่อ region หลักล่ม
เทียบกับ RDS cross-region read replica: Global Database เร็วกว่าและ RPO/RTO ต่ำกว่ามาก → เป็นคำตอบเมื่อโจทย์ต้องการ relational, cross-region DR with low RPO/RTO หรือ global read latency (รายละเอียด DR strategy เต็ม → บทที่ 08)

Aurora Serverless v2: auto-scale capacity (ACU — Aurora Capacity Unit) แบบ fine-grained ขึ้น/ลงตาม load ในไม่กี่วินาที รองรับ workload ที่ spiky/unpredictable โดยไม่ต้อง provision instance คงที่ — ต่างจาก v1 ที่ scale เป็นขั้นและมี cold-pause; v2 รองรับ Multi-AZ, read replica, Global Database ได้ (v1 ทำไม่ได้) จุดออกสอบ: variable/unpredictable database workload + don’t want to over-provision → Aurora Serverless v2

Babelfish for Aurora PostgreSQL: translation layer ที่ให้ Aurora PostgreSQL เข้าใจ SQL Server T-SQL และ TDS wire protocol — application ที่เขียนสำหรับ SQL Server เชื่อมต่อได้โดยแทบไม่แก้ code ใช้เป็นเส้นทาง migrate ออกจาก SQL Server license ราคาแพงไปสู่ open-source engine (บริบท modernization/refactor เต็ม → บทที่ 13) จุดออกสอบ: migrate SQL Server to AWS, reduce licensing cost, minimize application code changes → Babelfish (คู่กับ DMS/SCT — ดู 2.14)

2.8 Amazon DynamoDB: partition key design และ hot partition

DynamoDB เป็น serverless key-value/document database ให้ single-digit millisecond latency ที่ any scale — ไม่มี server ให้จัดการ, scale throughput/storage ไม่จำกัด นี่คือคำตอบมาตรฐานเมื่อโจทย์บอก massive scale, consistent low latency, fully managed NoSQL, no capacity planning

Partition key design เป็นหัวใจ ที่ตัดสิน performance: DynamoDB แบ่งข้อมูลเป็น partition ตาม hash ของ partition key ถ้า key มี cardinality ต่ำหรือ access กระจุกที่ค่าเดียว (เช่น partition key = “date ของวันนี้”, หรือ status = “ACTIVE”) จะเกิด hot partition — throughput กระจุกที่ partition เดียวจน throttle ขณะที่ partition อื่นว่าง

หลักออกแบบ key:

เลือก partition key ที่ high cardinality + กระจาย access สม่ำเสมอ (เช่น userId, orderId แทน status/date)
ถ้าจำเป็นต้องใช้ key ที่ hot ให้ write sharding (เติม suffix สุ่ม เช่น date#01..date#10) เพื่อกระจาย
ใช้ composite key (partition key + sort key) เพื่อ query แบบ range ภายใน partition (เช่น PK=userId, SK=timestamp → ดึง event ของ user ตามช่วงเวลา)
Adaptive Capacity ช่วยกระจาย throughput ให้ hot partition อัตโนมัติบางส่วน แต่ไม่แก้ปัญหา design ที่แย่ทั้งหมด

Cross-reference บทที่ 05: DynamoDB เป็น idempotency store ที่นิยม (conditional write บน idempotency key ป้องกันประมวลผลซ้ำจาก at-least-once delivery) และ order/state store สำหรับ event-driven architecture

2.9 DynamoDB: GSI vs LSI, capacity, DAX, Streams, Global Tables

Secondary index — ให้ query ด้วย attribute อื่นนอกจาก primary key:

มิติ	Global Secondary Index (GSI)	Local Secondary Index (LSI)
Partition key	ต่างจาก table ได้	เหมือน table (ต่างแค่ sort key)
สร้างเมื่อไหร่	สร้าง/ลบได้ ทุกเมื่อ	สร้างได้ เฉพาะตอนสร้าง table เท่านั้น
Capacity	มี capacity ของตัวเอง	ใช้ร่วมกับ table
Consistency	eventually consistent เท่านั้น	รองรับ strongly consistent
จำนวน / ข้อจำกัด	สูงสุด 20 (soft)	สูงสุด 5, จำกัด 10 GB ต่อ partition key

จุดออกสอบ: ต้อง query ด้วย attribute ที่ไม่ใช่ key และ table สร้างไปแล้ว → GSI (LSI เพิ่มภายหลังไม่ได้); ต้อง strong consistency บน alternate sort key ใน partition เดียวกัน → LSI

Capacity mode:

On-demand: จ่ายตาม request จริง, scale อัตโนมัติทันที, ไม่ต้อง capacity planning → เหมาะ unpredictable/spiky traffic หรือ workload ใหม่ที่ไม่รู้ pattern (least ops)
Provisioned + Auto Scaling: กำหนด RCU/WCU + auto scaling ตาม target utilization → ถูกกว่าเมื่อ traffic คาดเดาได้/สม่ำเสมอ; ถ้ารู้ baseline คงที่ยังซื้อ reserved capacity ลดราคาได้อีก

DAX (DynamoDB Accelerator): in-memory cache เฉพาะทางของ DynamoDB ให้ read latency ระดับ microsecond (จาก millisecond) แบบ write-through — โจทย์ read-heavy on DynamoDB, need microsecond latency → DAX (ไม่ต้องเขียน cache logic เอง ต่างจาก ElastiCache ที่ต้องจัดการ cache-aside)

DynamoDB Streams: capture การเปลี่ยนแปลง item (INSERT/MODIFY/REMOVE) เป็น ordered stream — trigger Lambda ได้ (event-driven, cross-ref บทที่ 05 event source mapping) ใช้ทำ replication, aggregation, audit, หรือ downstream sync

Global Tables: multi-region, multi-active (เขียนได้ทุก region) replication แบบ managed — ใช้ last-writer-wins สำหรับ conflict resolution เหมาะ global application with local low-latency read/write in each region และเป็น DR ระดับ region (RPO ต่ำมาก, active-active) ต่างจาก Aurora Global Database ที่ single writer (secondary read-only จนกว่า promote)

TTL: ตั้ง attribute เป็น expiry timestamp ให้ DynamoDB ลบ item อัตโนมัติเมื่อหมดอายุ (ฟรี, ลด storage) เหมาะ session/temporary data

Transactions: TransactWriteItems/TransactGetItems ให้ ACID ข้ามหลาย item/table ในคำสั่งเดียว (all-or-nothing)

2.10 Amazon ElastiCache & MemoryDB

ElastiCache เป็น managed in-memory cache สองแบบ:

มิติ	ElastiCache for Redis	ElastiCache for Memcached
Data structure	rich (string, hash, list, set, sorted set, stream)	string ล้วน (key-value)
Persistence / snapshot	มี (RDB/AOF)	ไม่มี (pure cache)
Replication / HA	มี replica + Multi-AZ + automatic failover	ไม่มี replication (แค่ sharding แนวนอน)
Cluster mode	มี (sharding + replica)	multi-node sharding
Pub/Sub, sorted set (leaderboard)	ได้	ไม่ได้
Use case	session store, leaderboard, cache-aside ที่ต้อง HA/persistence	simple cache ที่ต้องการ scale-out แนวนอนล้วน

จุดออกสอบ: leaderboard / sorted set / pub-sub / persistence / HA / geospatial → Redis; simplest possible cache, multi-threaded scale-out, no persistence needed → Memcached — เมื่อไม่แน่ใจ Redis เป็น default ที่ปลอดภัยกว่าเพราะ feature ครบกว่า

Pattern: cache-aside (application อ่าน cache ก่อน, miss แล้วอ่าน DB + เขียน cache), session store (เก็บ session นอก application server ให้ stateless — ดูบทที่ 05 ที่แนะนำ externalize session), rate limiting, leaderboard (Redis sorted set)

Amazon MemoryDB for Redis: Redis-compatible แต่เป็น durable primary database (ไม่ใช่แค่ cache) — เก็บ data ลง Multi-AZ transaction log ให้ durability เต็ม พร้อม microsecond read / single-digit ms write เหมาะเมื่อต้องการ in-memory database ที่เป็น source of truth ได้ (ไม่ใช่แค่ cache หน้า database อื่น) จุดออกสอบ: ultra-fast primary database, Redis API, durable, no separate database needed → MemoryDB (ต่างจาก ElastiCache ที่เป็น cache หน้า database หลัก)

2.11 Amazon Redshift — data warehouse

Redshift เป็น columnar MPP (massively parallel processing) data warehouse สำหรับ OLAP/analytics บนข้อมูลระดับ PB ต่างจาก OLTP database โดยสิ้นเชิง (query aggregate จำนวนมาก ไม่ใช่ transaction เล็ก ๆ)

RA3 nodes (managed storage): แยก compute จาก storage — scale compute แยกจาก data ที่เก็บบน managed storage (RMS ที่ backing ด้วย S3) จ่ายตาม compute ที่ใช้จริง; ต่างจาก DC2 รุ่นเก่าที่ storage ผูกกับ node
Redshift Spectrum: query ข้อมูลบน S3 โดยตรง (ไม่ต้อง load เข้า Redshift) — ใช้ join ข้อมูลใน warehouse กับ data lake บน S3, เหมาะ query ข้อมูล cold/มหาศาลที่ไม่คุ้ม load
Concurrency Scaling: เพิ่ม cluster ชั่วคราวอัตโนมัติเมื่อ concurrent query พุ่ง แล้วคืนเมื่อลด → แก้ปัญหา query queue ช่วง peak โดยไม่ over-provision ถาวร
Redshift Serverless: รันโดยไม่ต้อง provision cluster จ่ายตาม usage เหมาะ workload ไม่สม่ำเสมอ
AQUA / data sharing / federated query [uncertain รายละเอียดปัจจุบัน]

จุดออกสอบ: complex analytical/BI queries over petabytes, joins across large fact tables, reporting → Redshift; query S3 data lake occasionally without ETL/loading → Athena (serverless, ดู 2.15) — Redshift คุ้มเมื่อ query บ่อยและต้อง performance คงที่, Athena คุ้มเมื่อ query ไม่บ่อยแบบ ad-hoc

2.12 Purpose-built: DocumentDB, Neptune, Keyspaces, Timestream

Amazon DocumentDB: MongoDB-compatible (API 3.6/4.0/5.0) managed document database — เมื่อ application ใช้ MongoDB driver อยู่แล้วและต้องการ managed ที่ scale ได้บน AWS โดยไม่ self-manage MongoDB บน EC2 จุดออกสอบ: existing MongoDB workload, JSON documents, want managed → DocumentDB
Amazon Neptune: graph database รองรับ Gremlin, openCypher (property graph) และ SPARQL (RDF) — เหมาะ social network, recommendation engine, fraud detection, knowledge graph ที่ query คือ “traverse ความสัมพันธ์หลายชั้น” (เช่น “เพื่อนของเพื่อนที่ซื้อสินค้านี้”) ซึ่ง relational join ทำได้แย่ จุดออกสอบ: highly connected data / relationship traversal / recommendation → Neptune
Amazon Keyspaces: Apache Cassandra-compatible (CQL) แบบ serverless — wide-column, scale ไม่จำกัด, on-demand capacity; เมื่อ migrate Cassandra workload มา AWS โดยไม่บริหาร cluster เอง
Amazon Timestream: time-series database purpose-built — เก็บ metric/IoT/telemetry ที่มี timestamp, มี memory store (recent, fast) + magnetic store (historical, cheap) และย้าย tier อัตโนมัติ, query แบบ time-based (interpolation, smoothing) จุดออกสอบ: IoT sensor data / metrics at scale, time-series → Timestream (ไม่ใช่ยัดลง RDS/DynamoDB)

2.13 MemoryDB สรุปตำแหน่ง & QLDB [uncertain]

Amazon MemoryDB (สรุปจาก 2.10): in-memory database ที่ durable — ต่างจาก ElastiCache ตรงเป็น primary database ได้
Amazon QLDB (Quantum Ledger Database) [uncertain สถานะ — มีประกาศ end-of-support ในบางช่วง ควรตรวจสอบ ณ วันสอบ]: ledger database ที่มี immutable, cryptographically verifiable transaction log (journal) เหมาะ audit trail/financial ledger ที่ต้องพิสูจน์ว่าไม่ถูกแก้ย้อนหลัง — หากโจทย์ถาม centralized immutable verifiable ledger owned by single trusted authority คือ QLDB (ต่างจาก blockchain แบบ decentralized คือ Amazon Managed Blockchain) ด้วยความไม่แน่นอนของสถานะบริการ ให้พิจารณา requirement มากกว่าจำชื่อ

2.14 AWS DMS + Schema Conversion Tool (SCT) — cross-ref บทที่ 06

บทที่ 06 ฝากมาให้ครอบคลุม AWS DMS สำหรับ database migration (คู่กับ DataSync/Snow ที่ใช้กับ file/object) — นี่คือแกนหลักของ Domain 4 ในบทนี้

AWS Database Migration Service (DMS) ย้ายข้อมูล database เข้า AWS โดย source ยังทำงานได้ระหว่าง migrate มีสองเฟส:

Full load — copy ข้อมูลที่มีอยู่ทั้งหมดไป target
CDC (Change Data Capture) — จับการเปลี่ยนแปลงที่เกิดระหว่าง/หลัง full load แล้ว apply ต่อเนื่อง ทำให้ target ตาม source ทัน

การใช้ full load + CDC ร่วมกันคือเทคนิค minimal/near-zero downtime migration: ทำ full load ระหว่าง source ยัง live, CDC ตามให้ทัน, แล้วตัด (cutover) application ไป target ในช่วงสั้น ๆ เมื่อ lag ≈ 0 — นี่คือคำตอบเมื่อโจทย์บอก migrate database with minimal downtime (เชื่อม keyword จากบทที่ 01)

Homogeneous vs Heterogeneous migration:

ประเภท	คำอธิบาย	เครื่องมือ
Homogeneous	engine เดิม → engine เดียวกัน (Oracle→Oracle, MySQL→Aurora MySQL)	DMS อย่างเดียว (schema เข้ากันได้)
Heterogeneous	เปลี่ยน engine (Oracle→Aurora PostgreSQL, SQL Server→MySQL)	SCT แปลง schema/stored procedure/code ก่อน แล้ว DMS ย้ายข้อมูล

AWS Schema Conversion Tool (SCT): แปลง schema, stored procedure, function, view จาก source engine ไป target engine (heterogeneous) และออก assessment report ระบุส่วนที่แปลงอัตโนมัติไม่ได้ (ต้องแก้ manual) — สำหรับ heterogeneous migration ต้องใช้ SCT ก่อน DMS เสมอ [uncertain: บาง feature ของ SCT ถูกรวมเข้า DMS Schema Conversion แบบ managed แล้ว]

จุดออกสอบ:

migrate Oracle to Aurora PostgreSQL → SCT (แปลง schema) + DMS (ย้ายข้อมูล full load + CDC) — heterogeneous
migrate on-prem MySQL to Aurora MySQL with minimal downtime → DMS full load + CDC (homogeneous, ไม่ต้อง SCT)
DMS replication instance ต้องมี network path ถึงทั้ง source และ target (VPC, DX/VPN สำหรับ on-prem — ดูบทที่ 04)
ข้อมูลมหาศาลบน bandwidth จำกัด: ใช้ DMS ร่วมกับ Snowball (export ลง Snow แล้ว DMS ทำ CDC ตามภายหลัง) — เชื่อมกับ Snow Family บทที่ 06

2.15 Analytics stack เชิงสถาปัตยกรรม (data lake บน S3)

ในระดับ Pro ต้องรู้จัก analytics service ในฐานะ “จุดต่อของ data” ไม่ต้องลึกเชิง operation:

Amazon Athena: serverless query engine (Presto/Trino) query ข้อมูลบน S3 ด้วย SQL โดยไม่ต้อง provision อะไร จ่ายตามข้อมูลที่ scan → เหมาะ ad-hoc query บน data lake, log analysis; ลด cost ด้วย partition + columnar format (Parquet/ORC) จุดออกสอบ: query S3 data with SQL, serverless, pay per query, no infrastructure → Athena
AWS Glue: serverless ETL + Data Catalog — crawler สแกน schema ของ data ใน S3 สร้าง catalog (metadata) ที่ Athena/Redshift Spectrum/EMR ใช้ร่วมกัน; Glue jobs (Spark) ทำ ETL transform จุดออกสอบ: serverless ETL / build data catalog / prepare data for analytics → Glue
AWS Lake Formation: ชั้น governance/permission เหนือ data lake บน S3 + Glue Catalog — กำหนดสิทธิ์ระดับ table/column/row แบบรวมศูนย์ (fine-grained) ให้ Athena/Redshift/EMR เคารพ; เหมาะเมื่อโจทย์บอก centrally govern data lake access, column/row-level security
Amazon EMR: managed Hadoop/Spark cluster สำหรับ big-data processing ขนาดใหญ่ที่ต้อง framework เต็ม (Spark, Hive, Presto, HBase) — เมื่อ Glue serverless ไม่พอ/ต้องคุม cluster/ใช้ Spot ลด cost งาน batch มหาศาล
Amazon Kinesis (streaming ingestion):
- Kinesis Data Streams: real-time stream ที่ consumer หลายตัวอ่านได้, retention กำหนดได้, ต้องจัดการ shard — เหมาะ real-time processing, custom consumers, replay
- Kinesis Data Firehose: fully managed delivery stream ที่ buffer แล้ว load เข้า S3/Redshift/OpenSearch อัตโนมัติ (near-real-time, ไม่ต้องเขียน consumer) — เหมาะ simplest ingestion to data lake, least ops
- จุดออกสอบ: deliver streaming data to S3/Redshift with least operational overhead → Firehose; real-time custom processing / multiple consumers / replay → Data Streams

รูปแบบ data lake ทั่วไป: streaming/batch → Kinesis Firehose/Glue → เก็บเป็น Parquet บน S3 (data lake) → catalog ด้วย Glue → governance ด้วย Lake Formation → query ด้วย Athena/Redshift Spectrum/EMR (S3 เป็น storage กลาง — ดูบทที่ 06)

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

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

Requirement / keyword ในโจทย์	บริการ	เหตุผล / trade-off
relational, ACID, existing SQL app	RDS หรือ Aurora	Aurora ถ้าต้อง performance/HA สูง + MySQL/PG-compatible
MySQL/PostgreSQL-compatible, highest performance & HA, least ops	Aurora	shared storage 6/3AZ, replica lag ต่ำ, failover เร็ว
cross-region DR for relational, low RPO/RTO	Aurora Global Database	RPO<1s, RTO<1min; ดีกว่า cross-region read replica
unpredictable/variable relational workload	Aurora Serverless v2	auto-scale ACU ไม่ต้อง provision คงที่
massive scale key-value, single-digit ms, no capacity planning	DynamoDB (on-demand)	serverless NoSQL
multi-region active-active, low-latency writes everywhere	DynamoDB Global Tables	multi-active, last-writer-wins
microsecond read on DynamoDB	DAX	in-memory cache เฉพาะ DynamoDB, write-through
session / leaderboard / pub-sub / cache with HA	ElastiCache for Redis	rich structure + replication
simplest cache, horizontal scale, no persistence	ElastiCache for Memcached	multi-threaded, sharding ล้วน
durable in-memory primary database, Redis API	MemoryDB	durable ไม่ใช่แค่ cache
petabyte analytical/BI queries, joins on fact tables	Redshift (RA3)	columnar MPP
query S3 with SQL, serverless, pay-per-query	Athena	ไม่ต้อง load/provision
graph / relationship traversal / recommendation	Neptune	graph engine
time-series / IoT / metrics at scale	Timestream	tiering + time query
MongoDB-compatible managed document DB	DocumentDB	MongoDB API
Cassandra-compatible serverless	Keyspaces	CQL serverless

3.2 HA / replication mechanism เปรียบเทียบ

กลไก	Sync/Async	Cross-region	Writer	RPO	ใช้เมื่อ
RDS Multi-AZ (instance)	sync	ไม่	1 (standby ไม่รับ read)	≈0	HA ใน region
RDS read replica	async	ได้	อ่านอย่างเดียว	>0 (lag)	scale reads / DR แบบง่าย
Aurora Replica	async (shared storage)	ไม่ (ใน cluster)	อ่านอย่างเดียว, promote เร็ว	ต่ำมาก	HA + scale reads
Aurora Global Database	async storage-level	ได้ (5 region)	1 primary, secondary read-only	<1s typical	global read + cross-region DR
DynamoDB Global Tables	async	ได้	multi-active (ทุก region เขียนได้)	ต่ำมาก	global active-active

3.3 Migration tool เปรียบเทียบ

สถานการณ์	เครื่องมือ	หมายเหตุ
database เดียวกัน engine → engine เดิม	DMS (full load + CDC)	homogeneous, ไม่ต้อง SCT
เปลี่ยน engine (Oracle→PostgreSQL)	SCT + DMS	heterogeneous, SCT แปลง schema ก่อน
SQL Server → open-source ลด license, แก้ code น้อย	Babelfish + DMS/SCT	Aurora PostgreSQL รับ T-SQL
ข้อมูล DB มหาศาล bandwidth จำกัด	DMS + Snowball	offline seed + CDC ตาม
file/object migration (ไม่ใช่ DB)	DataSync / Snow / Transfer Family	ดูบทที่ 06

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

4.1 Serverless web app + DynamoDB + DAX (scale + microsecond read)

โจทย์: e-commerce catalog + cart, traffic spiky มาก (flash sale), ต้อง single-digit ms latency, read-heavy บนสินค้า, fully managed, least operational overhead, scale automatically

สถาปัตยกรรม: API Gateway → Lambda (ดูบทที่ 05) → DynamoDB (on-demand capacity) โดยมี DAX หน้าตารางสินค้าสำหรับ read-heavy; cart ใช้ DynamoDB + TTL ลบ cart ที่ทิ้งอัตโนมัติ; order เขียนด้วย conditional write เป็น idempotency store (cross-ref บทที่ 05); DynamoDB Streams → Lambda ส่ง event ไป fulfillment

ทำไมเลือกแบบนี้:

DynamoDB on-demand รับ spike ได้ทันทีโดยไม่ต้อง capacity planning — ตรง unpredictable spiky traffic
DAX ตัด read latency เป็น microsecond บน catalog ที่อ่านซ้ำมาก โดยไม่ต้องเขียน cache logic
partition key = productId (high cardinality) เลี่ยง hot partition

Trade-off: DynamoDB บังคับ design ตาม access pattern ล่วงหน้า (query แบบ relational join ทำไม่ได้ — ต้อง denormalize หรือใช้ GSI); ถ้า access pattern เปลี่ยนบ่อยหรือต้อง ad-hoc query จำนวนมาก relational อาจเหมาะกว่า; on-demand แพงกว่า provisioned เมื่อ traffic จริง ๆ คงที่คาดเดาได้

4.2 Relational app ย้ายขึ้น Aurora + Global Database (HA + cross-region DR)

โจทย์: monolithic app ใช้ PostgreSQL on-prem, ต้องขึ้น cloud, high availability, scale read reporting, cross-region disaster recovery with low RPO/RTO, minimal downtime during migration

สถาปัตยกรรม: migrate ด้วย DMS full load + CDC (homogeneous PostgreSQL→Aurora PostgreSQL, ไม่ต้อง SCT) ผ่าน DX/VPN (ดูบทที่ 04); ปลายทางเป็น Aurora PostgreSQL cluster — writer + Aurora Replica หลายตัว (reader endpoint สำหรับ reporting), Aurora Global Database ไป secondary region สำหรับ DR; RDS Proxy หน้า cluster ให้ app server pool connection

ทำไมเลือกแบบนี้:

DMS + CDC ให้ cutover downtime ระดับนาที — ตรง minimal downtime
Aurora Replica แก้ scale read reporting พร้อม failover เร็ว (HA)
Global Database ให้ RPO<1s / RTO<1min ข้าม region — ดีกว่า cross-region read replica ของ RDS ธรรมดา (low RPO/RTO) — รายละเอียด DR runbook → บทที่ 08
homogeneous จึงไม่ต้อง SCT ลด effort

Trade-off: Aurora ผูกกับ AWS (ไม่ portable กลับ on-prem ง่ายเท่า RDS PostgreSQL มาตรฐาน); Global Database secondary region เป็น read-only จน promote (ไม่ active-active เหมือน DynamoDB Global Tables) — ถ้าต้อง write หลาย region พร้อมกันต้องพิจารณา design อื่น; cost สูงกว่า single-region RDS มาก

4.3 Heterogeneous migration ออกจาก Oracle (ลด license cost)

โจทย์: enterprise ใช้ Oracle on-prem license แพง, ต้องการ reduce licensing cost, migrate to open-source engine, purpose-built where appropriate, ทีมกังวลเรื่อง stored procedure จำนวนมาก

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

SCT วิเคราะห์และแปลง schema/PL-SQL → PostgreSQL (Aurora PostgreSQL) พร้อม assessment report ระบุส่วนที่ต้องแก้ manual
DMS full load + CDC ย้ายข้อมูล (heterogeneous) โดย Oracle ยัง live
workload ที่เป็น time-series (log sensor) แยกไป Timestream, ส่วน analytics/reporting แยกไป Redshift + Athena บน S3 data lake — decompose ออกจาก monolithic Oracle ไป purpose-built (บริบท modernization → บทที่ 13)
cutover เมื่อ CDC lag ≈ 0

ทำไมเลือกแบบนี้:

SCT จำเป็นสำหรับ heterogeneous (schema/PL-SQL เข้ากันไม่ได้ตรง ๆ)
แยก workload ไป purpose-built ลดภาระ relational และเพิ่ม performance ต่อ access pattern
DMS CDC ให้ downtime ต่ำ

Trade-off: heterogeneous migration ใช้เวลา/effort สูงสุด (ต้อง test stored procedure ที่แปลง, application code อาจต้องแก้); การ decompose เพิ่ม operational complexity (หลาย database ต้องดูแล) แลกกับ scale/cost/performance — ถ้าเวลาจำกัดและ risk สูง อาจเลือก re-platform ไป Aurora ก่อนแล้วค่อย decompose ทีหลัง (strangler → บทที่ 13); ถ้าอยากแก้ code น้อยที่สุดพิจารณา Babelfish สำหรับส่วน SQL Server (กรณีนี้เป็น Oracle จึงไม่ตรง — Babelfish เป็น T-SQL)

4.4 Streaming analytics → data lake (real-time + batch)

โจทย์: IoT platform รับ telemetry หลายล้าน event/วินาที, ต้อง ingest streaming data, store in data lake, run ad-hoc SQL analytics, least operational overhead สำหรับ delivery

สถาปัตยกรรม: devices → Kinesis Data Streams (real-time, consumer หลายตัว: Lambda ประมวลผล real-time alert) → Kinesis Data Firehose buffer แล้ว deliver เป็น Parquet ลง S3 data lake; Glue crawler สร้าง catalog; time-series metric ที่ต้อง query ตามเวลา → Timestream; ad-hoc SQL → Athena; BI dashboard บนข้อมูลรวม → Redshift (Spectrum join S3); governance → Lake Formation

ทำไมเลือกแบบนี้:

Data Streams สำหรับ real-time custom consumer + replay; Firehose สำหรับ delivery ที่ least ops (ไม่เขียน consumer เอง)
S3 เป็น storage กลางราคาถูก durable (ดูบทที่ 06) — Athena query โดยไม่ load
Timestream สำหรับ time-series query ที่ RDS/DynamoDB ทำได้แย่

Trade-off: Data Streams ต้องจัดการ shard/capacity (มากกว่า Firehose); ถ้าต้องแค่ deliver ลง S3 อย่างเดียว Firehose อย่างเดียวพอ (เพิ่ม Data Streams เมื่อต้อง real-time processing/replay จริง) — over-engineering ถ้าใส่ทั้งคู่โดยไม่มี requirement real-time

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

สับสน Multi-AZ กับ read replica: Multi-AZ = HA/failover (standby ไม่รับ read), read replica = scale reads (async) — เลือก Multi-AZ เพื่อ “scale reads” คือผิด; เลือก read replica เพื่อ “automatic failover/HA” ก็ผิด (ไม่ auto-failover)
คิดว่า RDS read replica ให้ RPO=0: replica เป็น async มี lag เสมอ — ถ้าโจทย์บอก no data loss / RPO zero ต้องเป็น Multi-AZ (sync) หรือ Aurora; อย่าตอบ cross-region read replica สำหรับ zero-RPO
เลือก RDS แทน DynamoDB เมื่อโจทย์บอก massive scale + consistent low latency: relational มี scaling ceiling (write ยังผูก single writer) — any scale, single-digit ms คือ DynamoDB
ยัดทุก data model ลง relational: graph→Neptune, time-series→Timestream, ledger→QLDB, document→DocumentDB — purpose-built ตรงกว่า; ตอบ RDS สำหรับ recommendation engine graph traversal = ผิด
ลืมว่า LSI สร้างภายหลังไม่ได้: ถ้า table สร้างแล้วต้อง index ด้วย attribute ใหม่ → GSI เท่านั้น (LSI ต้องกำหนดตอนสร้าง table)
hot partition จาก partition key cardinality ต่ำ: เลือก key เป็น status/date/boolean → throttle; ต้องเลือก high-cardinality key หรือ write sharding
เขียน connection pool เองแทน RDS Proxy จาก Lambda: โจทย์ Lambda + RDS + “too many connections” → RDS Proxy (least ops) ไม่ใช่เพิ่ม instance size หรือ code เอง
ใช้ DMS โดยไม่มี SCT สำหรับ heterogeneous: เปลี่ยน engine (Oracle→PostgreSQL) ต้อง SCT แปลง schema ก่อน; ตอบ “DMS อย่างเดียว” สำหรับ heterogeneous คือขาดขั้น
สับสน DAX กับ ElastiCache: DAX = cache เฉพาะ DynamoDB (write-through, no code) — โจทย์ microsecond on DynamoDB ตอบ DAX ไม่ใช่ ElastiCache (ที่ต้องเขียน cache-aside เอง)
สับสน Aurora Global Database (single writer) กับ DynamoDB Global Tables (multi-active): multi-region active-active writes = DynamoDB Global Tables; Aurora Global Database secondary เป็น read-only จน promote
เลือก Redshift สำหรับ OLTP หรือ RDS สำหรับ PB-scale analytics: Redshift = OLAP/warehouse, RDS/Aurora = OLTP — ผิดฝั่งเมื่อ query pattern ไม่ตรง
ตอบ full load อย่างเดียวเมื่อโจทย์ต้อง minimal downtime: ต้อง full load + CDC จึงจะ cutover downtime ต่ำ; full load อย่างเดียว = source ต้อง freeze (downtime นาน)
เลือก Aurora Serverless v1 คุณสมบัติแบบ v2: v1 ไม่รองรับ Multi-AZ/read replica/Global Database และมี cold-start; workload spiky ที่ต้อง feature เต็ม → v2
มองข้าม Firehose เมื่อโจทย์บอก least ops delivery to S3: Data Streams ต้องเขียน consumer เอง; deliver to S3/Redshift with least ops → Firehose

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

ข้อ 1. แอปพลิเคชัน serverless (Lambda) เชื่อมต่อ Amazon RDS for MySQL ช่วง traffic peak เกิด error “too many connections” ต้องแก้ด้วย least operational overhead ควรทำอย่างไร

เฉลย

ใช้ Amazon RDS Proxy คั่นระหว่าง Lambda กับ RDS เพื่อ pool/multiplex connection

เพิ่ม instance size ผิด — max_connections เพิ่มเล็กน้อยตาม memory แต่ Lambda scale เป็นพัน connection ยังชนเพดาน และไม่ least ops
เขียน connection pool ใน Lambda เอง ผิด — Lambda แต่ละ invocation แยกกัน pool ข้าม invocation ไม่ได้จริง และเพิ่ม code/maintenance
ย้ายไป DynamoDB เป็นการเปลี่ยน data model ใหญ่เกินความจำเป็น (over-engineering) เมื่อ requirement คือแก้ connection ไม่ใช่เปลี่ยน database

ข้อ 2. ต้องการ relational database ที่ให้ cross-region disaster recovery ด้วย RPO ต่ำกว่า 1 วินาที และ RTO ต่ำกว่า 1 นาที พร้อม local read latency ต่ำในแต่ละ region ควรเลือกอะไร

เฉลย

Amazon Aurora Global Database

RDS Multi-AZ ผิด — อยู่ใน region เดียว ไม่ช่วย cross-region DR
RDS cross-region read replica ทำงานได้แต่ RPO/RTO สูงกว่า (async ผ่าน compute, lag มากกว่า, promote ช้ากว่า) — ไม่ตรง RPO<1s/RTO<1min
DynamoDB Global Tables ผิด data model — โจทย์ระบุ relational

ข้อ 3. DynamoDB table ที่ deploy ไปแล้วต้อง query ด้วย attribute ใหม่ (email) ที่ไม่ใช่ partition key เดิม ควรทำอย่างไร

เฉลย

สร้าง Global Secondary Index (GSI) โดยใช้ email เป็น partition key ของ index

Local Secondary Index (LSI) ผิด — LSI สร้างได้เฉพาะตอนสร้าง table เท่านั้น เพิ่มภายหลังไม่ได้ และ LSI ต้องใช้ partition key เดียวกับ table
Scan + filter ผิด — scan ทั้ง table แพงและช้ามากที่ scale
สร้าง table ใหม่ over-engineering เมื่อ GSI แก้ได้ตรงจุด

ข้อ 4. ต้อง migrate on-prem Oracle ไป Amazon Aurora PostgreSQL โดยมี stored procedure จำนวนมาก และต้องการ downtime น้อยที่สุด ควรใช้เครื่องมือและลำดับใด

เฉลย

ใช้ AWS SCT แปลง schema/stored procedure ก่อน แล้ว AWS DMS ทำ full load + CDC (heterogeneous migration)

DMS อย่างเดียว ผิด — เปลี่ยน engine (Oracle→PostgreSQL) schema/PL-SQL เข้ากันไม่ได้ ต้อง SCT ก่อน
DMS full load อย่างเดียว (ไม่มี CDC) ผิด — ต้อง freeze source ระหว่าง load = downtime นาน; CDC ทำให้ cutover downtime ต่ำ
Snowball export ไม่จำเป็นถ้า bandwidth พอ และไม่แก้เรื่อง schema conversion

ข้อ 5. แอปพลิเคชัน read-heavy บน DynamoDB ต้องการ read latency ระดับ microsecond โดยไม่อยากเขียน caching logic เอง ควรใช้อะไร

เฉลย

Amazon DynamoDB Accelerator (DAX)

ElastiCache for Redis ทำงานได้แต่ต้องเขียน cache-aside logic เอง (invalidation, populate) — ไม่ตรง “ไม่อยากเขียน caching logic”
เพิ่ม RCU / provisioned capacity ลด throttle แต่ไม่ลด latency เป็น microsecond (DynamoDB base คือ single-digit ms)
read replica DynamoDB ไม่มีแนวคิดนี้ (เป็น concept ของ RDS)

ข้อ 6. ระบบ IoT รับ telemetry จาก sensor หลายล้านตัว ต้องเก็บและ query ตามช่วงเวลา (last 24h, aggregate per hour) ด้วยประสิทธิภาพสูง ควรเลือก database ใด

เฉลย

Amazon Timestream (purpose-built time-series database)

DynamoDB เก็บได้แต่ time-based aggregation/interpolation ต้องเขียนเองและ scan แพง
RDS/Aurora relational ไม่เหมาะ time-series scale นี้ (write throughput + time query ไม่ optimize)
Redshift เป็น warehouse สำหรับ batch analytics ไม่ใช่ ingestion time-series real-time

ข้อ 7. ทีมต้องการ query ข้อมูล log ที่เก็บเป็นไฟล์บน Amazon S3 ด้วย SQL เป็นครั้งคราว (ad-hoc) โดยไม่ต้องดูแล infrastructure และจ่ายตามการใช้จริง ควรใช้อะไร

เฉลย

Amazon Athena (serverless, query S3 ด้วย SQL, จ่ายตามข้อมูลที่ scan)

Redshift ต้อง provision cluster + load ข้อมูล — over-provisioned สำหรับ ad-hoc ไม่บ่อย (แม้ Redshift Serverless ก็ยัง heavyweight กว่า และเหมาะ query บ่อย/ซับซ้อน)
EMR heavyweight สำหรับ ad-hoc SQL ธรรมดา
RDS ต้อง load ข้อมูลเข้าก่อน ไม่ query S3 ตรง
Tip: ลด cost Athena ด้วย partition + Parquet/ORC

ข้อ 8. แอปพลิเคชันระดับโลกต้องการให้ผู้ใช้ในทุก region เขียนข้อมูลด้วย low latency (active-active) และ replicate อัตโนมัติข้าม region ควรเลือกอะไร

เฉลย

Amazon DynamoDB Global Tables (multi-region, multi-active)

Aurora Global Database ผิด — มี single writer (primary), secondary region เป็น read-only จน promote จึงไม่ active-active
RDS Multi-AZ อยู่ region เดียว
ElastiCache Global Datastore เป็น cache ไม่ใช่ system of record และ write ที่ secondary จำกัด

ข้อ 9. ต้องการ in-memory data store ที่เป็น primary database ได้ (durable, เป็น source of truth) ด้วย Redis API และ latency microsecond ควรเลือกอะไร

เฉลย

Amazon MemoryDB for Redis (durable in-memory primary database)

ElastiCache for Redis ผิด — เป็น cache หน้า database อื่น ไม่ออกแบบเป็น durable source of truth (ข้อมูลอาจหายเมื่อ node fail แม้มี snapshot/replica)
DynamoDB + DAX ให้ single-digit ms + microsecond cache แต่ไม่ใช่ Redis API และ DAX ไม่ใช่ primary
RDS ไม่ใช่ in-memory

ข้อ 10. ต้อง upgrade major version ของ Amazon Aurora MySQL production ด้วย downtime น้อยที่สุดและสามารถ rollback ได้ทันทีหากมีปัญหา ควรใช้วิธีใด

เฉลย

RDS/Aurora Blue/Green Deployment — สร้าง green environment ที่ sync กับ blue, upgrade บน green, test, แล้ว switch over ด้วย downtime ระดับวินาที (blue ยังอยู่ให้ rollback)

in-place upgrade ผิด — downtime นานและ rollback ยาก
restore snapshot ไป instance ใหม่แล้วสลับ manual มาก และข้อมูลระหว่างนั้นไม่ sync (ต้อง freeze)
สร้าง read replica แล้ว promote ไม่ใช่กลไก version upgrade ที่ปลอดภัย/มี rollback ในตัว

7. Cross-references

บทที่ 01 — Exam Blueprint & SA-Pro Mindset: keyword mapping ที่ใช้ในบทนี้ — minimal downtime → Blue/Green + DMS CDC, no data loss/RPO zero → Multi-AZ sync/Aurora, any scale + single-digit ms → DynamoDB, least operational overhead → serverless (Aurora Serverless v2/DynamoDB on-demand/Athena/Firehose); convention <details> ห่อเฉลย และ bullet “ทำไมตัวเลือกอื่นผิด” สืบทอดมาจากบทนี้
บทที่ 04 — Networking at Scale & Hybrid Connectivity: DMS replication instance ต้องมี network path ถึง source/target ผ่าน DX/VPN; database subnet tier และ security group; PrivateLink/VPC endpoint สำหรับเข้าถึง DynamoDB (gateway endpoint) และ service อื่นแบบ private
บทที่ 05 — Compute & Application Integration: (รับ cross-ref) DynamoDB เป็น idempotency/order store, RDS Proxy connection pooling จาก Lambda, DynamoDB Streams → Lambda ผ่าน event source mapping, externalize session ไป ElastiCache/DynamoDB
บทที่ 06 — Storage & Data Transfer: (รับ cross-ref) storage layer ของ database engine (RDS/Aurora บน EBS-like managed storage, Aurora distributed storage), S3 เป็น data lake กลางของ analytics stack, DMS สำหรับ database migration คู่กับ DataSync/Snow/Transfer Family ที่ใช้กับ file/object; DMS + Snowball สำหรับ DB มหาศาลบน bandwidth จำกัด
บทที่ 08 — Resilience, HA & Disaster Recovery (ฝากไป): นิยาม RTO/RPO เต็ม, การ map Multi-AZ/read replica/Aurora Global Database/DynamoDB Global Tables เข้ากับ 4 DR strategies (backup & restore/pilot light/warm standby/multi-site), AWS Backup orchestration cross-region สำหรับ database
บทที่ 09 — Security Architecture & Data Protection (ฝากไป): encryption at rest ของ RDS/Aurora/DynamoDB ด้วย KMS, RDS Proxy ดึง credential จาก Secrets Manager + rotation, IAM database authentication, Lake Formation fine-grained access เชิง security
บทที่ 10 — Cost Optimization (ฝากไป): DynamoDB reserved capacity vs on-demand cost model, Aurora I/O-Optimized vs Standard, RDS Reserved Instances, Redshift RA3 cost model เชิง TCO
บทที่ 13 — Modernization & Refactoring (ฝากไป): Babelfish + strangler pattern ในบริบท refactor ออกจาก SQL Server, decompose monolithic relational ไป purpose-built database ตาม bounded context, migrate ไป serverless data layer