บทที่ 06: Storage & Data Transfer

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

บทนี้ครอบคลุมชั้น “storage” ทั้งหมดที่ workload วางอยู่บนนั้น และ “data transfer” ที่ย้ายข้อมูลเข้า/ออก/ข้าม AWS — เกี่ยวข้องกับทั้ง Domain 2 (Design for New Solutions) และ Domain 4 (Accelerate Workload Migration & Modernization) หลังจากบทที่ 05 (ดูบทที่ 05 — Compute & Application Integration) พูดถึงสิ่งที่ “วิ่ง” บนเครือข่ายจากบทที่ 04 แล้ว บทนี้คือ “ที่ที่ข้อมูลอยู่” — และในระดับ Professional การเลือก storage ผิดชนิดเป็นสาเหตุอันดับต้น ๆ ของ over-cost, latency ที่ยอมรับไม่ได้, และ architecture ที่ scale ไม่ได้

จุดที่ SA Pro ต่างจาก Associate ไม่ใช่การรู้ว่า “S3 คือ object storage” แต่คือการตอบได้ว่า เมื่อไหร่ควรเลือก S3 vs EBS vs EFS vs FSx, storage class ใดตาม access pattern, และเมื่อไหร่ควรย้ายข้อมูล online (DataSync) vs offline (Snow Family) โดยชั่ง trade-off ระหว่าง durability, availability, latency, throughput, cost (รวม data transfer/egress cost ที่ซ่อนอยู่), และ operational overhead โจทย์มักซ่อน constraint เช่น shared across thousands of instances, sub-millisecond latency, write once read many, petabyte-scale over limited bandwidth, lowest cost for rarely accessed archive — แต่ละคำชี้ไปที่บริการ/คลาสต่างกัน

บทที่ 05 ฝากมาว่า EBS volume type สำหรับ EC2, instance store detail, และ S3 event ที่ trigger Lambda/EventBridge ต้องครอบคลุมที่นี่ — จะจัดการให้ครบ

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

• เลือก S3 storage class ตาม access pattern และออกแบบ lifecycle policy, versioning, Object Lock, replication (CRR/SRR/RTC), Access Points/MRAP ได้
• เลือก EBS volume type (gp3/io2 Block Express/st1/sc1) ตาม IOPS/throughput requirement และเข้าใจ snapshot, Fast Snapshot Restore, multi-attach, encryption
• แยกได้ว่าเมื่อไหร่ใช้ instance store (ephemeral) vs EBS
• เลือกระหว่าง EFS (NFS/Linux, regional) vs FSx (Windows/Lustre/ONTAP/OpenZFS) ตาม protocol และ workload
• ตัดสินใจ hybrid storage ด้วย Storage Gateway และเลือก transfer service (DataSync/Transfer Family/Snow) ให้ถูก
• ตัดสินใจ online vs offline transfer ตามปริมาณ/bandwidth/เวลา และเข้าใจ egress cost เชิงสถาปัตยกรรม

ขอบเขต: storage ที่เป็นของ database engine (RDS/Aurora storage layer, DynamoDB) → บทที่ 07; การ orchestrate backup/DR ข้าม region (AWS Backup policy, pilot light/warm standby) → บทที่ 08 (บทนี้ให้เฉพาะ primitive อย่าง snapshot/replication); รายละเอียด cost model เต็ม (การคำนวณ TCO, tiered pricing breakdown) → บทที่ 10 บทนี้ให้ storage primitive และการเลือกใช้เชิงสถาปัตยกรรม

---

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

2.1 สามตระกูล storage: object vs block vs file

ก่อนลงรายละเอียด ต้องแยกให้ชัดว่า AWS แบ่ง storage เป็นสามตระกูล เพราะ โจทย์มักตัดตัวเลือกได้ทันทีจากตระกูล:

ตระกูล	บริการหลัก	เข้าถึงผ่าน	หน่วย	เหมาะกับ
Object	Amazon S3, S3 Glacier	HTTP(S) API (GET/PUT), key-based	object + metadata (flat namespace)	web asset, backup, data lake, media, log archive, static content — อ่าน/เขียนทั้ง object
Block	Amazon EBS, instance store	attach เป็น block device ให้ 1 OS	block (raw disk)	boot volume, database, filesystem ที่ต้อง low-latency random I/O
File	Amazon EFS, Amazon FSx	NFS / SMB mount	file + directory hierarchy	shared filesystem ที่หลาย client mount พร้อมกัน

หลักตัดสินใจแรก: “ต้อง mount เป็น disk ให้ OS เดียว” → block (EBS); “หลาย instance/client ต้องแชร์ไฟล์เดียวกันพร้อมกัน” → file (EFS/FSx); “เก็บ object จำนวนมหาศาลผ่าน API, ไม่ต้อง POSIX” → object (S3) การจำแยกนี้ตัด distractor ได้ครึ่งข้อในหลายโจทย์ เช่น “หลาย EC2 ต้องอ่าน/เขียนไฟล์ชุดเดียวกัน” — EBS ตัดทิ้งทันที (ยกเว้น io2 multi-attach ซึ่งเป็นกรณีพิเศษ ดู 2.10)

2.2 Amazon S3: durability, availability, และโครงสร้าง

S3 ให้ durability ที่ออกแบบไว้ 99.999999999% (11 nines) โดยเก็บ object ซ้ำหลาย copy ข้ามอย่างน้อย 3 Availability Zone ภายใน region (ยกเว้น One Zone class) durability ระดับนี้หมายถึงถ้าเก็บ 10 ล้าน object คาดว่าจะเสียหาย 1 object ทุก ~10,000 ปี — จึงเป็นคำตอบมาตรฐานเมื่อโจทย์บอก highly durable หรือ eleven nines

ต้องแยก durability (ข้อมูลไม่หาย) ออกจาก availability (เข้าถึงได้ตอนนี้) — ทุก storage class มี durability 11 nines เท่ากัน แต่ availability SLA ต่างกัน (S3 Standard 99.99%, One Zone-IA 99.5%) นี่คือกับดักออกสอบ: One Zone-IA ไม่ได้ durability ต่ำกว่าในแง่ redundancy ภายใน AZ เดียว แต่ถ้า AZ นั้นถูกทำลายทั้ง AZ ข้อมูลหาย — จึงเหมาะเฉพาะข้อมูลที่ re-create ได้

โครงสร้าง: S3 มี flat namespace (ไม่มีโฟลเดอร์จริง; prefix คั่นด้วย / เป็นแค่ convention) bucket name เป็น global unique ทั่วโลก S3 ให้ strong read-after-write consistency สำหรับทุก operation อัตโนมัติ (ไม่ต้องตั้งค่า — เปลี่ยนจากอดีตที่ eventually consistent) จึงไม่ต้องกังวลเรื่อง stale read หลัง PUT/DELETE อีกต่อไป

2.3 S3 storage classes

การเลือก storage class คือหัวใจ cost optimization ของ object storage ทุกคลาสมี durability 11 nines เท่ากัน ต่างที่ availability, จำนวน AZ, minimum duration, retrieval fee, และ retrieval time:

Storage class	ออกแบบเพื่อ	AZ	Min duration	Retrieval	หมายเหตุ
S3 Standard	data ที่ access บ่อย	≥3	ไม่มี	ทันที, ไม่มี fee	default; latency ต่ำ throughput สูง
S3 Intelligent-Tiering	access pattern ไม่รู้/เปลี่ยน	≥3	ไม่มี	ทันที (tier ที่ frequent/infrequent)	ย้าย tier อัตโนมัติตาม access, มี monitoring fee ต่อ object; ไม่มี retrieval fee
S3 Standard-IA	access น้อยแต่ต้องเร็วเมื่อเรียก	≥3	30 วัน	ทันที, มี per-GB retrieval fee	เก็บถูกกว่า Standard ~40% แต่จ่ายตอนอ่าน
S3 One Zone-IA	IA ที่ re-create ได้	1	30 วัน	ทันที, มี fee	ถูกกว่า Standard-IA ~20% แต่เสี่ยง AZ loss
S3 Glacier Instant Retrieval	archive ที่ต้องอ่านทันทีเป็นครั้งคราว	≥3	90 วัน	ทันที (ms), มี fee	ถูกกว่า IA มาก, สำหรับ archive ที่ยัง query เร็ว (medical image)
S3 Glacier Flexible Retrieval	archive ที่รอได้เป็นนาที-ชม.	≥3	90 วัน	Expedited (1-5 นาที) / Standard (3-5 ชม.) / Bulk (5-12 ชม.)	เดิมชื่อ “S3 Glacier”
S3 Glacier Deep Archive	archive ระยะยาวสุด, เข้าถึงน้อยมาก	≥3	180 วัน	Standard (12 ชม.) / Bulk (48 ชม.)	ถูกที่สุด, compliance retention 7-10 ปี

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

• access pattern ไม่แน่นอน / เปลี่ยนตามเวลา / ไม่อยากบริหาร lifecycle เอง → Intelligent-Tiering (least ops สำหรับ cost — ไม่มี retrieval fee ทำให้ปลอดภัยถ้าเดา pattern ผิด) นี่คือคำตอบยอดนิยมเมื่อโจทย์บอก “unknown or changing access patterns”
• rarely accessed แต่ต้องอ่านทันทีเมื่อเรียก → Standard-IA (หรือ One Zone-IA ถ้า re-creatable)
• archive ที่บางครั้งต้องอ่านทันที (ms) → Glacier Instant Retrieval
• archive ที่รอได้ + ถูกที่สุด + retention หลายปี → Glacier Deep Archive
• ระวัง: minimum duration charge — ถ้าลบ object ก่อน min duration ยังถูกเก็บเงินเต็ม period จึงไม่ควรใส่ short-lived object ลง IA/Glacier

2.4 S3 lifecycle policies

Lifecycle policy คือ rule ที่ให้ S3 transition object ไป class ที่ถูกกว่าตามอายุ หรือ expire (ลบ) อัตโนมัติ ตัวอย่าง pattern คลาสสิก: Standard (0-30 วัน) → Standard-IA (30-90) → Glacier Flexible (90-365) → Deep Archive (>365) → expire ที่ 7 ปี

ประเด็นออกสอบ:

• transition มี cost (per-1000-object request) — การ transition object เล็กจำนวนมหาศาลอาจแพงกว่าที่ประหยัด; Intelligent-Tiering เหมาะกว่าถ้าไม่แน่ใจ
• lifecycle ทำงานกับทั้ง current และ noncurrent version (เมื่อเปิด versioning) — สามารถตั้งให้ลบ noncurrent version เก่าเพื่อคุม cost ของ version history
• ตั้ง rule ตาม prefix หรือ tag ได้ (เช่น เฉพาะ logs/ หรือ object ที่ tag archive=true)
• ไม่สามารถ transition จาก class ที่ “restrictive กว่า” ย้อนกลับได้ (ต้องไล่ตามลำดับ Standard → IA → Glacier)

2.5 S3 versioning และ MFA Delete

Versioning เก็บทุก version ของ object (รวม delete marker) เมื่อเปิดแล้วปิดไม่ได้ ทำได้แค่ suspend — ป้องกันการเขียนทับ/ลบโดยไม่ตั้งใจ และเป็นรากฐานของ CRR (replication ต้องเปิด versioning) trade-off: เก็บทุก version = จ่าย storage ทุก version → ต้องคู่กับ lifecycle ลบ noncurrent version

MFA Delete: บังคับให้การลบ version หรือปิด versioning ต้องใช้ MFA token — เปิด/ปิดได้เฉพาะ root account ผ่าน CLI เท่านั้น เป็น control ป้องกันการลบข้อมูลสำคัญ (แม้ credential รั่วก็ลบไม่ได้ถ้าไม่มี MFA) โจทย์ที่บอก prevent accidental or malicious deletion + require additional authentication → MFA Delete

2.6 S3 Object Lock (WORM)

Object Lock บังคับ Write Once Read Many (WORM) — object ที่ lock แล้วลบ/แก้ไม่ได้จนหมด retention (ต้องเปิด versioning) มีสองโหมด:

โหมด	ใครลบ/ลด retention ได้	ใช้เมื่อ
Governance mode	user ที่มีสิทธิ์พิเศษ (s3:BypassGovernanceRetention) override ได้	ป้องกันภายในทั่วไป, ยังต้องมีทางแก้
Compliance mode	ไม่มีใครลบได้ แม้แต่ root account จนหมด retention	regulatory (SEC 17a-4, FINRA), audit ที่ต้องพิสูจน์ immutability

นอกจาก retention period ยังมี Legal Hold (lock ไม่มีกำหนดจนกว่าจะปลด, แยกจาก retention) โจทย์ที่บอก regulatory compliance, immutable, cannot be deleted even by administrators → Compliance mode Object Lock (ไม่ใช่แค่ versioning หรือ MFA Delete ซึ่ง admin ยัง override ได้)

2.7 S3 Replication: CRR / SRR / RTC

Replication คัดลอก object อัตโนมัติจาก source bucket ไป destination bucket (ต้องเปิด versioning ทั้งสองฝั่ง):

• CRR (Cross-Region Replication): ข้าม region — เพื่อ compliance (เก็บสำเนาคนละภูมิภาค), latency (ให้ผู้ใช้อีกทวีปอ่าน bucket ใกล้), DR, หรือ isolate ระหว่าง account
• SRR (Same-Region Replication): ภายใน region เดียว — รวม log จากหลาย bucket ไปที่เดียว, replicate ข้าม account (prod → log archive), หรือแยก dev/test copy
• S3 Replication Time Control (RTC): SLA ว่า 99.99% ของ object จะถูก replicate ภายใน 15 นาที พร้อม metric/notification — ใช้เมื่อมี compliance RPO ที่ต้องรับประกันเวลา

ประเด็นออกสอบ:

• replication เป็น async (ไม่ใช่ real-time; default ไม่มี SLA เวลา → ใช้ RTC ถ้าต้องรับประกัน)
• default replicate เฉพาะ object ใหม่หลังเปิด — object เก่าต้องใช้ S3 Batch Replication (ย้อนหลัง)
• replicate ข้าม account ได้ + เปลี่ยน owner ได้ (สำหรับ log archive pattern จากบทที่ 02)
• ไม่ replicate แบบ chain (A→B→C) โดย default; delete marker replicate ได้แบบ optional

2.8 S3 Access Points และ Multi-Region Access Points (MRAP)

เมื่อ bucket เดียวถูกใช้โดยหลายทีม/แอป การเขียน bucket policy เดียวยาวเหยียดจัดการยาก S3 Access Point คือ endpoint แยก (แต่ละอันมีชื่อ + policy + network origin ของตัวเอง) ที่ชี้เข้า bucket เดียวกัน — แต่ละแอปได้ access point ของตัวเองพร้อม policy แคบ ๆ (เช่น access point หนึ่งอ่าน prefix finance/ เท่านั้น, อีกอันจำกัดให้เข้าจาก VPC เดียว) ลดความซับซ้อนของ bucket policy กลาง

Multi-Region Access Points (MRAP): endpoint global เดียวที่ route request ไป bucket ในหลาย region อัตโนมัติตาม latency ต่ำสุด (ใช้ AWS global network คล้าย Global Accelerator) + failover ได้ เหมาะ active-active multi-region application ที่ต้องการ single endpoint โดยไม่จัดการ routing เอง trade-off: ค่าใช้จ่าย data routing เพิ่ม และต้องตั้ง replication ระหว่าง bucket เอง

จุดออกสอบ: global application ต้องเข้า S3 ผ่าน endpoint เดียวด้วย latency ต่ำสุด + failover → MRAP; แยก access ต่อทีมเข้า bucket เดียวโดยไม่บวม bucket policy → Access Point

2.9 S3 features เสริม: Select, Requester Pays, presigned URL, event

• S3 Select: query ข้อมูลบางส่วนใน object (CSV/JSON/Parquet) ด้วย SQL โดยไม่ต้องดึงทั้ง object — ลด data transfer และ compute ฝั่ง client เมื่อต้องการแค่บาง row/column (สำหรับ analytics เต็มรูปแบบข้าม object จำนวนมากใช้ Athena ซึ่งต่างระดับ)
• Requester Pays: ให้ผู้ request จ่ายค่า data transfer + request แทนเจ้าของ bucket — เหมาะ dataset สาธารณะ/แชร์ขนาดใหญ่ที่เจ้าของไม่อยากแบกค่า egress; requester ต้องส่ง header ยืนยันและต้อง authenticated (ไม่ anonymous)
• Presigned URL: URL ชั่วคราวที่ให้สิทธิ์ GET/PUT object เฉพาะเจาะจงมีเวลาหมดอายุ โดยไม่ต้องให้ IAM credential — ใช้ให้ผู้ใช้ upload/download ตรงกับ S3 (offload จาก application server) โดยควบคุมสิทธิ์และเวลา
• S3 Event Notifications: ตอบ cross-reference จากบทที่ 05 — เมื่อมี s3:ObjectCreated:* / ObjectRemoved ฯลฯ S3 ส่ง event ไป Lambda, SQS, SNS ได้โดยตรง หรือส่งเข้า Amazon EventBridge (เปิด “Send to EventBridge”) เพื่อ content-based routing/filter ที่ยืดหยุ่นกว่า (ดูบทที่ 05 — EventBridge) นี่คือ trigger หลักของ event-driven pipeline บน S3 (เช่น upload ภาพ → Lambda สร้าง thumbnail) ตัวอย่างในสถาปัตยกรรม 4.2 EventBridge เหมาะเมื่อต้อง route ไปหลาย target/หลาย rule; direct-to-Lambda เหมาะ 1:1 ง่าย ๆ

2.10 Amazon EBS: volume types

EBS เป็น block storage แบบ network-attached ที่ attach ให้ EC2 หนึ่ง instance (ยกเว้น multi-attach) เป็น persistent (คงอยู่หลัง stop/terminate ถ้าไม่ตั้ง delete-on-termination) และ replicate ภายใน AZ เดียว (EBS ผูก AZ — snapshot ไป S3 คือทางข้าม AZ/region) ตอบ cross-reference จากบทที่ 05 เรื่อง volume type สำหรับ EC2:

Type	หมวด	max IOPS	max throughput	เหมาะกับ
gp3	SSD general	16,000	1,000 MB/s	default แนะนำ — IOPS/throughput ปรับแยกจาก size, ถูกกว่า gp2 ~20%
gp2	SSD general (legacy)	16,000	250 MB/s	IOPS ผูกกับ size (3 IOPS/GB) — gp3 แทนที่ได้เกือบทุกกรณี
io2 Block Express	SSD provisioned IOPS	256,000	4,000 MB/s	latency ต่ำสุด, IOPS สูงสุด — mission-critical DB (Oracle, SAP HANA, high-perf)
io1	SSD provisioned IOPS (legacy)	64,000	1,000 MB/s	io2 ดีกว่าในทุกด้าน (durability สูงกว่า, ราคาเท่ากัน)
st1	HDD throughput-optimized	500	500 MB/s	sequential throughput สูง cost ต่ำ — big data, log processing, data warehouse
sc1	HDD cold	250	250 MB/s	access น้อยมาก, ถูกที่สุด — cold data ที่ยังต้อง block

จุดตัดสินใจ:

• ทั่วไป/boot volume → gp3 (default ที่ถูกและยืดหยุ่น; ถ้าเจอ gp2 ในโจทย์ปัจจุบันมักเป็น distractor เทียบกับ gp3)
• ต้องการ IOPS สูงมาก + latency ต่ำสุด + durability สูง (99.999%) สำหรับ critical database → io2 Block Express
• workload sequential throughput (streaming read/write ไฟล์ใหญ่) ที่ไม่ต้อง IOPS สูง → st1 (ถูกกว่า SSD มาก); HDD ไม่เหมาะ random small I/O
• gp3 แยก provision IOPS/throughput จาก capacity ได้ — ต่างจาก gp2 ที่ต้องเพิ่ม size เพื่อเพิ่ม IOPS (จุดที่ข้อสอบชอบถามเรื่อง cost optimization: แอปที่ต้อง IOPS สูงแต่ storage น้อย → gp3 ประหยัดกว่า gp2 มาก)

2.11 EBS snapshots, FSR, multi-attach, encryption

• Snapshots: backup ของ volume ไปเก็บใน S3 (managed by AWS) เป็น incremental — snapshot แรก full, ต่อไปเก็บเฉพาะ block ที่เปลี่ยน (ประหยัด storage) restore สร้าง volume ใหม่ (lazy-load block จาก S3) copy ข้าม region/account ได้ (encrypt ระหว่าง copy ได้) — เป็น primitive ของ backup/DR (orchestration เต็มด้วย AWS Backup → บทที่ 08)
• Fast Snapshot Restore (FSR): pre-initialize snapshot ในแต่ละ AZ ให้ volume ที่ restore ได้ full performance ทันที (ไม่ต้องรอ lazy-load) — เหมาะเมื่อต้อง restore แล้วใช้ทันที (เช่น golden image สำหรับ scale-out เร็ว) trade-off: มีค่าใช้จ่ายต่อ snapshot ต่อ AZ ต่อชั่วโมง
• Multi-Attach: io1/io2 attach ให้ สูงสุด 16 instance ใน AZ เดียวกัน พร้อมกัน — แต่ต้องใช้ cluster-aware filesystem (เช่น GFS2) เพราะ EBS ไม่จัดการ write coordination ให้ ไม่ใช่ทางแก้ “แชร์ไฟล์ทั่วไป” (นั่นคือ EFS) จุดออกสอบ: multi-attach เหมาะ HA cluster application ที่จัดการ concurrent write เอง ไม่ใช่ shared file storage
• Encryption: EBS encryption ใช้ AWS KMS (ดูบทที่ 09 — KMS) เข้ารหัส at-rest + in-transit ระหว่าง instance กับ volume + snapshot ที่สร้างจาก encrypted volume ก็ encrypted เปิด EBS encryption by default ระดับ account/region ได้ (bootstrapping ที่ข้อสอบชอบเมื่อโจทย์บอก “ทุก volume ใหม่ต้อง encrypt”)

2.12 Instance store (ephemeral)

Instance store คือ block storage บน physical disk ที่ติดกับ host โดยตรง (NVMe บน i-series/im4gn) — throughput/IOPS สูงกว่า EBS มาก เพราะไม่ผ่าน network แต่ ephemeral: ข้อมูลหายเมื่อ stop/terminate/hardware failure (คงอยู่เมื่อ reboot) ราคารวมอยู่ในค่า instance แล้ว

เหมาะกับ: cache, scratch space, buffer, temp data, หรือ data ที่ replicate ไว้ที่อื่นแล้ว (เช่น shard/replica ของ distributed database, node ของ Cassandra/Kafka ที่ replicate ข้าม node) trade-off ที่ชัด: performance สูงสุดแลกกับ persistence เป็นศูนย์ — โจทย์ที่บอก “ข้อมูลต้องอยู่รอดหลัง stop/terminate” แล้วมี instance store เป็นตัวเลือกคือ distractor คลาสสิก (สืบเนื่องจากบทที่ 05 — instance store vs EBS)

2.13 Amazon EFS: shared NFS file storage

EFS เป็น managed NFS (v4) filesystem สำหรับ Linux ที่หลาย EC2/container/Lambda mount พร้อมกันได้ — elastic (โตอัตโนมัติ ไม่ต้อง provision size) และ (โดย default regional class) เก็บข้อมูลข้าม หลาย AZ จึงเป็น shared storage ที่ HA ในตัว

Storage/availability class:

• EFS Regional (Standard): ข้ามหลาย AZ — HA, durable ระดับ region เหมาะ production shared storage
• EFS One Zone: AZ เดียว — ถูกกว่า ~47% แต่เสี่ยง AZ loss เหมาะ dev/test หรือ data ที่ re-create ได้ (คู่ขนานแนวคิด S3 One Zone-IA)

Throughput mode:

Mode	กลไก	เหมาะกับ
Elastic (แนะนำ)	scale throughput ขึ้น-ลงอัตโนมัติตาม demand, จ่ายตามใช้	workload ที่ pattern ไม่แน่นอน/spiky — least ops
Provisioned	กำหนด throughput คงที่แยกจาก size	ต้องการ throughput สูงกว่าที่ size ให้ + คาดการณ์ได้
Bursting (legacy default)	throughput โตตาม size + burst credit	workload ที่ throughput สัมพันธ์กับ data size

Performance mode: General Purpose (latency ต่ำสุด, default, เหมาะเกือบทุกกรณี) vs Max I/O (throughput/IOPS รวมสูงกว่าแต่ latency สูงขึ้น สำหรับงาน parallel หนัก ๆ หลายพัน client — ปัจจุบัน Elastic throughput ลดความจำเป็นของ Max I/O ลงมาก [uncertain สถานะ default ปัจจุบัน])

Lifecycle management: ย้ายไฟล์ที่ไม่ถูก access ไป EFS Infrequent Access (IA) หรือ Archive อัตโนมัติเพื่อลด cost (คล้าย S3 lifecycle) Access Points: application-specific entry point ที่บังคับ user/group id + root directory เฉพาะ (เช่นแต่ละ container ได้ dir ของตัวเอง) คุม POSIX permission แบบ managed

จุดออกสอบ: หลาย EC2/container (Linux) ต้องแชร์ filesystem POSIX พร้อมกัน, HA, ไม่อยาก provision capacity → EFS Regional + Elastic throughput (least ops)

2.14 Amazon FSx: managed file systems เฉพาะทาง

FSx คือกลุ่ม managed file system สำหรับ workload ที่ต้อง protocol/feature เฉพาะที่ EFS ไม่ให้ (EFS = NFS/Linux เท่านั้น) มีสี่ตัว:

FSx flavor	protocol	จุดเด่น	เหมาะกับ
FSx for Windows File Server	SMB	integrate Active Directory, NTFS ACL, DFS, shadow copy	Windows workload ที่ต้อง shared drive, .NET app, home directory องค์กร (ดูบทที่ 03 — AD)
FSx for Lustre	Lustre (POSIX)	HPC-grade, throughput หลายร้อย GB/s, integrate S3 native (lazy-load จาก + export กลับ S3)	HPC, ML training, genomics, media rendering, big data ที่ต้อง scratch เร็วบน dataset ใน S3
FSx for NetApp ONTAP	NFS + SMB + iSCSI	ONTAP features: snapshot, dedup/compression, SnapMirror, multi-protocol, tiering	ย้าย on-prem NetApp มา cloud, workload ที่ต้องหลาย protocol พร้อมกัน
FSx for OpenZFS	NFS	ZFS features: snapshot, clone ทันที, sub-ms latency	migrate ZFS/Linux NFS workload, ต้องการ point-in-time clone เร็ว

จุดตัดสินใจออกสอบ (สำคัญมาก — ข้อสอบชอบให้เลือก FSx ตัวไหน):

• Windows / SMB / Active Directory → FSx for Windows File Server (EFS ไม่ทำ SMB; นี่คือคำตอบเมื่อโจทย์มีคำว่า Windows หรือ SMB share)
• HPC / ML training / high-performance compute + dataset อยู่ใน S3 → FSx for Lustre (throughput สุด + S3 integration; โจทย์คำว่า “HPC”, “Lustre”, “sub-millisecond”, “millions of IOPS”, “process S3 data at high speed”)
• ต้องหลาย protocol (NFS + SMB) พร้อมกัน / ย้ายจาก NetApp on-prem / ต้อง dedup+tiering → FSx for NetApp ONTAP
• ย้าย ZFS/Linux NFS workload ที่ต้อง clone/snapshot ZFS-style → FSx for OpenZFS
• Linux NFS ทั่วไป ไม่ต้องการ feature พิเศษ → EFS (ไม่ใช่ FSx — EFS ops ต่ำกว่า, serverless, elastic)

2.15 AWS Storage Gateway: hybrid bridge

Storage Gateway คือ VM/appliance (หรือ hardware) ที่รันบน on-prem ให้ application ในองค์กรใช้ AWS storage ผ่าน protocol เดิม โดยมี local cache เพื่อ low-latency access ของ hot data มีสี่ประเภท:

ประเภท	protocol on-prem	backend AWS	use case
S3 File Gateway	NFS / SMB	object ใน S3	ให้ on-prem app เขียนไฟล์ที่กลายเป็น S3 object (backup, tiering ไป cloud, ingest data lake)
FSx File Gateway	SMB	FSx for Windows	low-latency access ไป FSx for Windows จาก on-prem (cache local)
Volume Gateway	iSCSI (block)	EBS snapshot ใน S3	block volume บน cloud; Cached (hot บน local, primary บน AWS) หรือ Stored (primary local, async backup ไป AWS)
Tape Gateway (VTL)	iSCSI VTL	S3 / Glacier	แทน physical tape library — backup app เดิมเขียน “virtual tape” ที่ลง Glacier

จุดออกสอบ: on-prem app เขียน SMB/NFS แต่อยากให้ data ไปอยู่ S3 โดยไม่แก้ app + cache local เพื่อ low latency → S3 File Gateway; เลิกใช้ physical tape backup แต่ backup software เดิมพูด VTL → Tape Gateway (โจทย์คำว่า “tape”, “existing backup software”, “eliminate tape infrastructure”)

2.16 AWS DataSync, Transfer Family, Snow Family

AWS DataSync: บริการ online transfer แบบ agent-based ที่ย้ายไฟล์จำนวนมากเร็ว (NFS/SMB/HDFS/object) ระหว่าง on-prem ↔ AWS หรือ AWS ↔ AWS โดยอัตโนมัติ พร้อม data validation, incremental, scheduling, encryption ระหว่างทาง ใช้ agent VM บน on-prem อ่าน source แล้วส่งผ่าน network มา S3/EFS/FSx เหมาะ migration/replication ต่อเนื่องผ่าน network ที่มี bandwidth พอ trade-off: จำกัดด้วย bandwidth ที่มี — ปริมาณมหาศาลบน link แคบใช้เวลานาน (เทียบ Snow)

AWS Transfer Family: managed SFTP / FTPS / FTP (และ AS2) server ที่ backend เป็น S3/EFS — สำหรับ integrate กับ partner/ระบบเดิมที่พูด protocol เหล่านี้ โดยไม่ต้องบริหาร FTP server เอง (auth ผ่าน service-managed, AD, หรือ custom IdP) จุดออกสอบ: partner ส่งไฟล์ผ่าน SFTP อยู่แล้ว ต้องรับเข้า S3 โดยไม่บริหาร server → Transfer Family (ต่างจาก DataSync ที่เป็น bulk sync ภายใน ไม่ใช่ protocol endpoint สำหรับ external partner)

Snow Family (offline / edge): อุปกรณ์กายภาพที่ AWS ส่งให้ copy data แล้วส่งกลับ เข้าไปที่ S3 — สำหรับปริมาณมหาศาลบน bandwidth จำกัด หรือสถานที่ไม่มี network ดี:

• AWS Snowcone: เล็กสุด (~8 TB / 14 TB SSD), พกพา, มี compute เบา, ทน rugged — edge/field
• AWS Snowball Edge: Storage Optimized (~80 TB usable) หรือ Compute Optimized (มี vCPU/GPU รัน EC2/Lambda ที่ edge) — petabyte-scale migration, edge processing สถานที่ห่างไกล
• AWS Snowmobile: รถบรรทุกคอนเทนเนอร์ขน exabyte-scale [uncertain — สถานะบริการปัจจุบันไม่ชัดเจน; อาจ discontinued/ไม่เน้นแล้ว อย่าเลือกในข้อสอบยุคใหม่เว้นแต่โจทย์ระบุ exabyte ชัดเจน]

Snow ทั้งหมด encrypt data, ใช้ tamper-evident, และ integrate กับ NFS/S3 interface

2.17 การตัดสินใจ online vs offline transfer + egress cost

หัวใจ Domain 4 ข้อหนึ่งคือการเลือก online (DataSync/Transfer/DX) vs offline (Snow) โดยดู “ปริมาณ vs bandwidth vs เวลาที่ยอมรับได้” กฎง่าย ๆ: คำนวณเวลาที่ต้องใช้ transfer ผ่าน network ที่มี — ถ้านานเกินยอมรับ ให้ offline

ตัวอย่างการประมาณ (ใช้ ~80% utilization โดยประมาณ):

• 100 Mbps เต็มที่ ≈ ~1 TB/วัน → 100 TB ≈ 3+ เดือน (ไม่ไหว → Snow)
• 1 Gbps ≈ ~10 TB/วัน → 100 TB ≈ ~10-12 วัน (ก้ำกึ่ง; ถ้ามี DX/bandwidth ว่างอาจ online ได้)
• 10 Gbps (มี Direct Connect — ดูบทที่ 04) ≈ ~100 TB/วัน → online ได้แม้ปริมาณสูง

หลักออกสอบ: petabyte-scale + limited bandwidth + one-time migration → Snowball Edge; ongoing/incremental sync ที่มี bandwidth พอ → DataSync; เชื่อมต่อถาวร throughput สูงสำหรับ migration ต่อเนื่อง → Direct Connect + DataSync (ดูบทที่ 04)

Egress cost เชิงสถาปัตยกรรม (รายละเอียด cost model → บทที่ 10): data-in สู่ AWS ฟรี, แต่ data-out สู่ internet คิดเงินต่อ GB และเป็นต้นทุนซ่อนที่ SA Pro ต้องออกแบบให้ลด:

• data ที่วิ่งภายใน AZ เดียวกันผ่าน private IP ฟรี; ข้าม AZ มีค่าใช้จ่าย → วาง chatty component ใน AZ เดียว (ชั่งกับ HA)
• VPC gateway endpoint สำหรับ S3/DynamoDB (ฟรี — ดูบทที่ 04) ทำให้ traffic ไป S3 ไม่ผ่าน NAT Gateway (ประหยัดทั้งค่า NAT processing และ egress) — คำตอบมาตรฐานเมื่อโจทย์บอก “EC2 in private subnet เข้า S3 อย่าง cost-effective + private”
• CloudFront ลด egress: data-out จาก S3 ไป CloudFront ฟรี และ CloudFront egress ถูกกว่า S3-to-internet ตรง + cache ลด origin fetch (ดูบทที่ 04 — CloudFront)
• S3 Transfer Acceleration: ใช้ CloudFront edge เร่ง upload ไป S3 ข้ามทวีป (จ่ายเพิ่ม) — เมื่อผู้ใช้ทั่วโลก upload object ใหญ่ไป bucket ปลายทางไกล

---

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

3.1 เลือก storage platform หลัก (requirement → บริการ → เหตุผล/trade-off)

Requirement / keyword ในโจทย์	บริการ	เหตุผล / trade-off
object จำนวนมหาศาลผ่าน API, durable, data lake, web asset	S3	11 nines, unlimited scale; ไม่ใช่ POSIX filesystem
boot volume / low-latency random I/O ให้ 1 EC2	EBS gp3	block, persistent; ผูก 1 AZ, 1 instance
critical DB ต้อง IOPS สูงสุด + latency ต่ำสุด	EBS io2 Block Express	256k IOPS, 99.999% durability; แพงกว่า gp3
local NVMe เร็วสุด, data หายได้ (cache/scratch)	instance store	throughput สูงสุด; ephemeral (หายเมื่อ stop/terminate)
หลาย Linux EC2/container แชร์ POSIX filesystem, HA	EFS (Regional, Elastic)	NFS multi-AZ, elastic, least ops
Windows / SMB share + Active Directory	FSx for Windows	SMB + NTFS ACL + AD; EFS ทำ SMB ไม่ได้
HPC / ML training throughput สูง + dataset ใน S3	FSx for Lustre	หลายร้อย GB/s + S3 integration
หลาย protocol (NFS+SMB) / migrate NetApp	FSx for ONTAP	multi-protocol + dedup/SnapMirror
archive ถูกที่สุด, เข้าถึงน้อยมาก, retention หลายปี	S3 Glacier Deep Archive	ถูกสุด; retrieval 12-48 ชม.
WORM / immutable / regulatory, admin ก็ลบไม่ได้	S3 Object Lock (Compliance)	immutable จนหมด retention

3.2 เลือก S3 storage class (access pattern → class)

Access pattern	Class	ทำไม
access บ่อย, ทั่วไป	S3 Standard	latency ต่ำ ไม่มี retrieval fee
ไม่รู้/เปลี่ยน pattern	Intelligent-Tiering	auto-tier, ไม่มี retrieval fee, least ops
access น้อยแต่ต้องเร็วเมื่อเรียก	Standard-IA	ถูกกว่า Standard, จ่ายตอนอ่าน
IA ที่ re-create ได้ (secondary copy)	One Zone-IA	ถูกกว่า IA, เสี่ยง AZ loss
archive ที่บางครั้งต้องอ่านทันที (ms)	Glacier Instant Retrieval	ถูกกว่า IA, retrieval ทันที
archive รอได้ นาที-ชม.	Glacier Flexible Retrieval	ถูก, retrieval นาที-ชม.
archive ถูกสุด, retention ยาว	Glacier Deep Archive	ถูกสุด, retrieval 12-48 ชม.

3.3 เลือก transfer / hybrid service (สถานการณ์ → บริการ)

สถานการณ์	บริการ	trade-off / ทำไม
bulk online sync/migration, bandwidth พอ	DataSync	เร็ว, incremental, validate; จำกัดด้วย bandwidth
partner ส่งไฟล์ผ่าน SFTP/FTPS เข้า S3	Transfer Family	managed protocol endpoint; ไม่ใช่ bulk internal sync
petabyte + bandwidth จำกัด, one-time	Snowball Edge	offline, เร็วกว่าเมื่อคำนวณเวลา; ต้องรออุปกรณ์ส่ง
edge/field, rugged, ปริมาณเล็ก + compute	Snowcone	เล็ก พกพา; capacity จำกัด
on-prem SMB/NFS app เขียนไฟล์ลง S3 + cache	S3 File Gateway	ไม่ต้องแก้ app; cache hot data local
แทน physical tape backup	Tape Gateway (VTL)	backup software เดิมใช้ได้; backend Glacier
on-prem app ต้อง block volume บน cloud	Volume Gateway	iSCSI; Cached vs Stored
ต่อเนื่อง throughput สูง, dedicated	Direct Connect + DataSync	latency นิ่ง (ดูบทที่ 04)

---

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

4.1 Data lake tiering: hot → warm → archive อัตโนมัติ

โจทย์: บริษัทเก็บ IoT/log data หลาย PB ลง S3, access หนักช่วง 30 วันแรก แล้วแทบไม่แตะ แต่ต้องเก็บ 7 ปีตาม compliance และบางครั้ง (นาน ๆ ครั้ง) audit ต้องดึงย้อนหลัง ต้องการ most cost-effective โดย least operational overhead

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

• ingest ลง S3 Standard (raw/ prefix)
• Lifecycle policy: Standard → Standard-IA ที่ 30 วัน → Glacier Flexible Retrieval ที่ 90 วัน → Glacier Deep Archive ที่ 1 ปี → ยังไม่ expire (เก็บครบ 7 ปีตาม compliance)
• เปิด versioning + Object Lock (Compliance mode, 7 ปี) เพื่อ immutability ตาม regulatory
• ใช้ S3 Select / Athena query โดยไม่ดึงทั้ง object

ทำไมแบบนี้: lifecycle จัดการ transition อัตโนมัติ (least ops); Deep Archive ให้ต้นทุน archive ต่ำสุดสำหรับ retention ยาว; Object Lock Compliance ตอบ regulatory ที่ห้ามลบ

Trade-off: object เก่าใน Deep Archive ดึงกลับใช้เวลา 12-48 ชม. (ยอมรับได้เพราะ audit ไม่เร่งด่วน); ถ้า access pattern จริงไม่แน่นอน/เดายาก ควรพิจารณา Intelligent-Tiering แทน lifecycle แบบ fixed (แลก monitoring fee กับความปลอดภัยเรื่อง retrieval fee) — ที่นี่เลือก fixed lifecycle เพราะ pattern ชัด (access หนัก 30 วันแรกแล้วเย็น)

4.2 Serverless media pipeline: S3 event → EventBridge → processing

โจทย์: ผู้ใช้ upload รูป/วิดีโอเข้า S3 ต้อง process (thumbnail, transcode, virus scan) หลายขั้นแบบ decoupled, scale ตาม upload, least operational overhead ตอบ cross-reference จากบทที่ 05 เรื่อง S3 event trigger

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

• ผู้ใช้ upload ผ่าน presigned URL ตรงเข้า S3 (offload จาก application server)
• S3 → EventBridge (s3:ObjectCreated:*) — เปิด Send to EventBridge เพื่อ route หลาย rule
• EventBridge rule แยกตาม suffix/prefix: .jpg → Lambda thumbnail; .mp4 → Step Functions orchestrate MediaConvert; ทุกไฟล์ → Lambda virus scan (fan-out ผ่านหลาย rule/target — ดูบทที่ 05)
• ผลลัพธ์เขียนกลับ S3 (processed/ prefix) แยก storage class

ทำไมแบบนี้: EventBridge (แทน direct-to-Lambda) ให้ content-based routing ไปหลาย target ตาม type โดยไม่ผูก S3 กับ consumer เดียว; presigned URL ให้ upload ตรง ลด load + ควบคุมสิทธิ์/เวลา; serverless ทั้งสาย = least ops

Trade-off: EventBridge เพิ่ม latency เล็กน้อยและซับซ้อนกว่า direct-to-Lambda 1:1 — ถ้ามี consumer เดียวจริง ๆ direct-to-Lambda ง่ายกว่า; ที่นี่เลือก EventBridge เพราะมีหลาย consumer/type และต้องการ decouple (routing เปลี่ยนได้โดยไม่แตะ producer)

4.3 Hybrid: on-prem file server + cloud backup + PB-scale migration

โจทย์: องค์กรมี on-prem Windows file server (SMB) หลาย TB, ต้องการ (1) เริ่ม backup/tier ไป cloud โดยไม่แก้ app, (2) migrate historical archive 500 TB ขึ้น S3 ครั้งเดียว, (3) ระยะยาว sync data ใหม่ต่อเนื่อง bandwidth link 500 Mbps

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

• S3 File Gateway (หรือ FSx File Gateway ถ้าต้อง SMB latency ต่ำ) ให้ file server เขียน SMB ที่ไหลเป็น S3 object + cache hot data local
• migration ครั้งแรก 500 TB: Snowball Edge (offline) — 500 TB บน 500 Mbps ≈ นานเกินไป (500 Mbps ≈ ~5 TB/วัน → ~100 วัน) จึงใช้ Snow
• sync ต่อเนื่องหลังจากนั้น: DataSync ผ่าน link 500 Mbps (incremental รายวันปริมาณน้อยพอไหว)
• S3 lifecycle → Glacier สำหรับ archive tier

ทำไมแบบนี้: แยก “one-time bulk เยอะบน bandwidth จำกัด” (Snow) จาก “ongoing incremental” (DataSync) — เป็น pattern มาตรฐาน Domain 4; File Gateway ให้ on-prem app ทำงานต่อโดยไม่แก้โค้ด

Trade-off: Snow มี lead time (รออุปกรณ์ส่ง/ส่งกลับ ~สัปดาห์) แต่คุ้มกว่ารอ transfer 100 วัน; DataSync ผูกกับ bandwidth — ถ้า data ใหม่โตเร็วกว่า link รับได้ ต้องพิจารณา Direct Connect (ดูบทที่ 04)

---

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

1. ตอบ EBS เมื่อโจทย์ต้องการหลาย instance แชร์ไฟล์พร้อมกัน — EBS ผูก 1 instance (ยกเว้น multi-attach ที่ต้อง cluster-aware FS และไม่ใช่ shared file); คำตอบคือ EFS (Linux) หรือ FSx
2. ใช้ instance store กับข้อมูลที่ต้อง persist — ephemeral หายเมื่อ stop/terminate → ต้อง EBS หรือ EFS
3. เลือก EFS สำหรับ Windows/SMB workload — EFS = NFS/Linux เท่านั้น; SMB ต้อง FSx for Windows (หรือ ONTAP)
4. มองข้าม One Zone-IA เรื่อง AZ loss — durability redundancy ภายใน AZ ยัง 11 nines แต่ AZ ถูกทำลาย = ข้อมูลหาย; ใช้เฉพาะ data ที่ re-create ได้
5. คิดว่า versioning/MFA Delete = immutable — admin/root ยัง override versioning ได้; regulatory immutability ต้อง Object Lock Compliance mode
6. ใส่ short-lived object ลง IA/Glacier — โดน minimum duration charge (IA 30 วัน, Glacier 90/180) แม้ลบก่อน = ไม่ประหยัด
7. ตอบ DataSync เมื่อโจทย์เป็น petabyte บน bandwidth จำกัด — คำนวณเวลา; ปริมาณมหาศาลบน link แคบต้อง Snowball Edge (offline)
8. ตอบ Snowball เมื่อเป็น ongoing/incremental sync — Snow คือ one-time bulk offline; sync ต่อเนื่องคือ DataSync
9. สับสน DataSync vs Transfer Family — DataSync = bulk internal migration/replication; Transfer Family = managed SFTP/FTPS endpoint สำหรับ external partner protocol
10. ตอบ gp2 เมื่อต้อง IOPS สูงบน storage เล็ก — gp2 ผูก IOPS กับ size; gp3 (หรือ io2) provision IOPS แยกได้ = cost-effective กว่า
11. เลือก io2/Provisioned IOPS สำหรับ sequential throughput workload — big data streaming ต้อง throughput ไม่ใช่ IOPS → st1 (HDD) ถูกกว่ามาก
12. ลืม VPC gateway endpoint เมื่อ EC2 ใน private subnet เข้า S3 — routing ผ่าน NAT Gateway เสียเงิน + ออก internet; gateway endpoint ฟรี + private (ดูบทที่ 04)
13. ตอบ Storage Gateway เมื่อโจทย์เป็น cloud-native ล้วน — Storage Gateway คือ hybrid bridge สำหรับ on-prem; ถ้าไม่มี on-prem อย่าเลือก
14. มองข้าม Intelligent-Tiering เมื่อ access pattern ไม่แน่นอน — พยายาม fix lifecycle บน pattern ที่เดาไม่ได้เสี่ยง retrieval fee; Intelligent-Tiering ไม่มี retrieval fee = ปลอดภัยและ least ops
15. ลืมว่า S3 replication เป็น async และ default ไม่ replicate object เก่า — ต้อง RTC ถ้าต้อง SLA เวลา, ต้อง Batch Replication สำหรับ object ที่มีอยู่ก่อน

---

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

ข้อ 1 — 20 EC2 instance (Amazon Linux) รัน web application ที่ต้องอ่าน/เขียนไฟล์ media ชุดเดียวกันพร้อมกัน, ต้องการ HA ข้าม AZ และไม่อยาก provision capacity ล่วงหน้า ควรใช้ storage ใด?

A. EBS gp3 แชร์ผ่าน io2 multi-attach B. Amazon EFS (Regional) throughput mode Elastic C. Amazon S3 mount ผ่าน instance store D. FSx for Windows File Server

เฉลย

B — EFS เป็น shared NFS สำหรับ Linux, multi-AZ (HA), elastic (ไม่ต้อง provision size), scale throughput อัตโนมัติ

• A ผิด: EBS ผูก 1 AZ; multi-attach จำกัด io1/io2 + AZ เดียว + ต้อง cluster-aware FS ไม่ใช่ shared file ทั่วไป
• C ผิด: S3 ไม่ใช่ mountable POSIX filesystem; instance store เป็น ephemeral local ไม่แชร์ข้าม instance
• D ผิด: FSx for Windows เป็น SMB สำหรับ Windows; workload นี้ Linux → EFS ตรงกว่าและ ops ต่ำกว่า

ข้อ 2 — บริษัทต้องเก็บ financial record ตาม regulation ที่กำหนดว่า ห้ามลบหรือแก้ไขได้เลยแม้แต่ผู้ดูแลระบบ เป็นเวลา 7 ปี ควรใช้อะไร?

A. S3 versioning + MFA Delete B. S3 Glacier Deep Archive + IAM deny policy C. S3 Object Lock ใน Compliance mode retention 7 ปี D. S3 Object Lock ใน Governance mode retention 7 ปี

เฉลย

C — Compliance mode ทำให้ไม่มีใครลบ/ลด retention ได้ แม้แต่ root จนหมด 7 ปี = immutable ตาม regulatory

• A ผิด: root ยังปิด versioning/ลบได้; MFA Delete ไม่ใช่ WORM ที่พิสูจน์ immutability ต่อ auditor
• B ผิด: IAM deny แก้ได้โดย admin; Deep Archive เป็น cost tier ไม่ใช่ immutability control
• D ผิด: Governance mode ให้ user ที่มี BypassGovernanceRetention override ได้ → ไม่ตรง “แม้แต่ผู้ดูแลก็ลบไม่ได้”

ข้อ 3 — ต้องย้าย 600 TB จาก on-prem data center ขึ้น S3 เป็นการ migration ครั้งเดียว, internet link มี 200 Mbps และใช้สำหรับ production ด้วย ต้องเสร็จภายในไม่กี่สัปดาห์ ควรใช้อะไร?

A. AWS DataSync ผ่าน internet link B. AWS Snowball Edge Storage Optimized C. AWS Transfer Family (SFTP) D. S3 Transfer Acceleration

เฉลย

B — 600 TB บน 200 Mbps ≈ หลายเดือน (200 Mbps ≈ ~2 TB/วัน → ~300 วัน) และยังแย่ bandwidth กับ production → offline Snowball Edge เร็วและไม่กิน link

• A ผิด: DataSync จำกัดด้วย 200 Mbps → นานเกินไปและแย่ bandwidth production
• C ผิด: Transfer Family เป็น protocol endpoint สำหรับ partner ไม่ใช่ bulk migration และก็ยังจำกัด bandwidth
• D ผิด: Transfer Acceleration เร่ง upload ผ่าน edge แต่ยังผ่าน network เดิม ไม่แก้ปัญหา throughput/ปริมาณ

ข้อ 4 — ทีม HPC ต้องรัน ML training บน dataset 200 TB ที่เก็บใน S3 ต้องการ filesystem ที่ให้ throughput หลายร้อย GB/s และ integrate กับ S3 ได้เพื่อโหลด data เข้ามาประมวลผลแล้ว export ผลกลับ ควรใช้อะไร?

A. Amazon EFS Max I/O B. FSx for Lustre C. EBS io2 Block Express multi-attach D. FSx for NetApp ONTAP

เฉลย

B — FSx for Lustre เป็น HPC-grade throughput สูงมาก และ integrate S3 native (lazy-load จาก + export กลับ) ตรงกับ ML training

• A ผิด: EFS Max I/O throughput สูงกว่า General Purpose แต่ยังต่ำกว่า Lustre มากและไม่มี S3 native integration
• C ผิด: EBS ผูก AZ/instance, ไม่ใช่ parallel HPC filesystem, ไม่ integrate S3
• D ผิด: ONTAP เด่นเรื่อง multi-protocol/dedup ไม่ใช่ HPC throughput + S3 scratch — Lustre ตรงกว่า

ข้อ 5 — แอปมี access pattern ที่ ไม่แน่นอนและเปลี่ยนไปเรื่อย ๆ บาง object ร้อนบางช่วง เย็นบางช่วง ทีมไม่อยากบริหาร lifecycle เอง และกลัวจ่าย retrieval fee โดยไม่ตั้งใจ ควรใช้ S3 class ใด?

A. S3 Standard-IA B. S3 Intelligent-Tiering C. S3 One Zone-IA + lifecycle D. S3 Glacier Instant Retrieval

เฉลย

B — Intelligent-Tiering ย้าย tier อัตโนมัติตาม access (least ops) และ ไม่มี retrieval fee → ปลอดภัยเมื่อ pattern เดาไม่ได้

• A ผิด: Standard-IA มี retrieval fee → object ที่กลับมาร้อนจะเสียเงินอ่านซ้ำ ๆ
• C ผิด: One Zone-IA เสี่ยง AZ loss + ยังมี retrieval fee + ต้องบริหาร lifecycle เอง
• D ผิด: Glacier Instant Retrieval สำหรับ archive ที่เย็นจริง + มี retrieval fee; pattern แกว่งขึ้น-ลงไม่เหมาะ

ข้อ 6 — EC2 ใน private subnet ต้องอ่าน/เขียน S3 ปริมาณมาก, ต้องการให้ traffic ไม่ออก internet และ most cost-effective ควรทำอย่างไร?

A. route ผ่าน NAT Gateway ไป S3 public endpoint B. สร้าง VPC gateway endpoint สำหรับ S3 C. สร้าง interface endpoint (PrivateLink) สำหรับ S3 D. ตั้ง S3 File Gateway ใน VPC

เฉลย

B — gateway endpoint สำหรับ S3/DynamoDB ฟรี และให้ traffic วิ่ง private ผ่าน route table โดยไม่ผ่าน NAT/internet (ดูบทที่ 04)

• A ผิด: NAT Gateway เสียทั้งค่า hourly + per-GB processing และ traffic ออก internet — แพงและไม่ private
• C ผิด: interface endpoint สำหรับ S3 มีจริงแต่มีค่า hourly + per-GB; gateway endpoint ฟรีจึง cost-effective กว่าเมื่ออยู่ใน VPC เดียวกัน
• D ผิด: Storage Gateway เป็น hybrid bridge สำหรับ on-prem ไม่ใช่ทางเข้า S3 จากใน VPC

ข้อ 7 — organization ต้องการเลิกใช้ physical tape library สำหรับ backup แต่ backup software เดิมพูดกับ tape ผ่าน iSCSI VTL เท่านั้นและทีมไม่อยากเปลี่ยน software ควรใช้อะไร?

A. AWS Backup B. S3 File Gateway C. Tape Gateway (Storage Gateway VTL) D. AWS DataSync

เฉลย

C — Tape Gateway ให้ virtual tape library ผ่าน iSCSI ที่ backup software เดิมใช้ได้ทันที โดย backend เก็บใน S3/Glacier = เลิก physical tape โดยไม่เปลี่ยน software

• A ผิด: AWS Backup เป็น managed backup ของ AWS resource ไม่ใช่ VTL endpoint สำหรับ backup software on-prem เดิม
• B ผิด: S3 File Gateway ให้ NFS/SMB ไม่ใช่ VTL ที่ backup software เขียน tape
• D ผิด: DataSync คือ bulk file transfer ไม่ใช่ tape interface

ข้อ 8 — application global เขียน/อ่าน S3 จากหลาย region ต้องการ single endpoint ที่ route ไป bucket ที่ latency ต่ำสุดอัตโนมัติและ failover ได้ ควรใช้อะไร?

A. S3 Cross-Region Replication อย่างเดียว B. S3 Multi-Region Access Point (MRAP) C. Amazon CloudFront หน้า S3 D. S3 Transfer Acceleration

เฉลย

B — MRAP ให้ global endpoint เดียว route request ไป bucket ในหลาย region ตาม latency ต่ำสุด + failover (ใช้ AWS global network)

• A ผิด: CRR ทำสำเนาข้าม region แต่ไม่ให้ single endpoint/latency routing — ต้องคู่กับ MRAP
• C ผิด: CloudFront เร่ง read/cache แต่ไม่ route write ไปหลาย bucket ตาม latency แบบ active-active
• D ผิด: Transfer Acceleration เร่ง upload ไป bucket เดียว ไม่ใช่ multi-region routing

ข้อ 9 — database บน EC2 ต้องการ IOPS สูงมากบน volume ขนาดเพียง 200 GB, ปัจจุบันใช้ gp2 แล้ว IOPS ไม่พอเพราะต้องเพิ่ม size เพื่อเพิ่ม IOPS ทำให้เปลือง storage ต้องการ cost-effective ควรทำอย่างไร?

A. เพิ่มขนาด gp2 เป็นหลาย TB เพื่อได้ IOPS B. เปลี่ยนเป็น gp3 แล้ว provision IOPS แยกจาก size C. เปลี่ยนเป็น st1 D. ใช้ instance store แทน

เฉลย

B — gp3 แยก provision IOPS/throughput ออกจาก capacity → ได้ IOPS ที่ต้องบน 200 GB โดยไม่ต้องซื้อ storage เกิน = cost-effective

• A ผิด: เพิ่ม size เพื่อ IOPS บน gp2 คือปัญหาเดิมที่เปลือง storage
• C ผิด: st1 เป็น HDD throughput-optimized ไม่เหมาะ random IOPS ของ database
• D ผิด: instance store เร็วแต่ ephemeral → database เสี่ยงข้อมูลหายเมื่อ stop/terminate

---

7. Cross-references

• บทที่ 01 — Exam Blueprint & SA-Pro Mindset: keyword mapping ที่ใช้ตลอดบทนี้ (durable→S3 11 nines, most cost-effective→storage class/lifecycle/st1/gp3, unknown access pattern→Intelligent-Tiering, immutable/WORM→Object Lock, petabyte + limited bandwidth→Snow, least operational overhead→managed/serverless เช่น EFS Elastic, Intelligent-Tiering)
• บทที่ 02 — Multi-Account Governance: S3 SRR ข้าม account ไป Log Archive account (log centralization pattern), S3 encryption ที่ SCP บังคับ (require encryption) — ดูบทที่ 02
• บทที่ 03 — Identity, Access & Federation: S3 Access Point policy + bucket policy (resource-based cross-account), presigned URL แทนการแจก IAM credential, FSx for Windows integrate Active Directory (Managed Microsoft AD) — ดูบทที่ 03
• บทที่ 04 — Networking at Scale: VPC gateway endpoint สำหรับ S3/DynamoDB (ฟรี, ประหยัด egress/NAT), interface endpoint สำหรับ FSx/other, CloudFront/Transfer Acceleration ลด egress, Direct Connect + DataSync สำหรับ hybrid throughput สูง — ดูบทที่ 04
• บทที่ 05 — Compute & Application Integration: บทนี้ตอบ cross-reference ที่บทที่ 05 ฝากมา — EBS volume type สำหรับ EC2 (ข้อ 2.10), instance store detail (ข้อ 2.12), และ S3 event → Lambda/EventBridge (ข้อ 2.9 และสถาปัตยกรรม 4.2); ยังเชื่อมกับ instance profile/IAM role ในการเข้าถึง S3
• บทที่ 07 — Databases & Data Migration: storage ของ database engine (RDS/Aurora shared storage layer, DynamoDB) และ AWS DMS สำหรับ database migration (คู่กับ DataSync/Snow สำหรับ file/object) → ดูบทที่ 07
• บทที่ 08 — Resilience, HA & DR: การ orchestrate backup ด้วย AWS Backup (policy-based cross-account/cross-region), EBS snapshot + S3 CRR ในฐานะ DR primitive, RPO/RTO ที่กำหนดว่าจะใช้ replication แบบใด (บทนี้ให้ primitive; strategy เต็ม → บทที่ 08)
• บทที่ 09 — Security & Data Protection: EBS/S3/EFS/FSx encryption ผ่าน AWS KMS (key policy, envelope encryption, multi-region key), S3 encryption options เต็ม (SSE-S3/SSE-KMS/SSE-C/DSSE) → ดูบทที่ 09
• บทที่ 10 — Cost Optimization: cost model เต็มของ storage (tiered pricing, request cost, minimum duration, egress/data transfer breakdown, S3 Storage Lens/Cost Explorer) → ดูบทที่ 10
• บทที่ 12 — Migration Strategy & Execution: DataSync/Transfer Family/Snow ในบริบท migration wave, online vs offline decision, dependency กับ Application Migration Service (MGN) — บทนี้ให้ transfer primitive; strategy 7 Rs และ tooling → บทที่ 12