บทที่ 04: Networking at Scale & Hybrid Connectivity

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

บทนี้คือกระดูกสันหลังของทั้ง Domain 1 (Design Solutions for Organizational Complexity) และ Domain 2 (Design for New Solutions) เพราะเครือข่ายคือชั้นที่ “ผูก” ทุกอย่างเข้าด้วยกัน — account หลายร้อยตัวที่บทที่ 02 (ดูบทที่ 02 — Multi-Account Governance) ออกแบบไว้, workload ที่ต้องคุยข้าม account, และ data center เดิมที่ต้องเชื่อมเข้ามาแบบ hybrid บทที่ 03 (ดูบทที่ 03 — Identity, Access & Federation) ได้ฝากมาว่า networking สำหรับ Active Directory hybrid, การแชร์ Transit Gateway/subnet ผ่าน AWS Resource Access Manager (RAM), และการเปรียบเทียบ VPC peering vs Transit Gateway vs PrivateLink เป็นหน้าที่ของบทนี้ — จะครอบคลุมให้ครบ

ในบริบท SAP-C02 คำถามด้าน networking แทบไม่เคยถาม “VPC คืออะไร” (นั่นคือระดับ Associate) แต่จะถามว่า “มี 200 VPC ใน 80 account ต้องเชื่อมทั้งหมดเข้า on-premises ผ่านสองสาย Direct Connect แบบ resilient และให้ centralized egress inspection โดย least operational overhead — ออกแบบอย่างไร” คำตอบต้องชั่ง trade-off ระหว่าง cost, operational overhead, blast radius, และ scalability ให้ครบ

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

• วางแผน CIDR ทั้ง organization โดยไม่ให้ overlap และเข้าใจว่าทำไม overlap ถึงเป็นปัญหาที่ “แก้ไม่ได้ย้อนหลัง” ในหลายกรณี
• เลือกกลไกเชื่อม VPC ให้ถูก: VPC peering (non-transitive) vs Transit Gateway (hub-spoke) vs PrivateLink (service exposure) vs Cloud WAN
• ออกแบบ hybrid connectivity ด้วย Direct Connect + Site-to-Site VPN โดยเข้าใจ resiliency model และ failover pattern
• เลือก Route 53 routing policy ให้ตรงกับ requirement (latency, failover, geolocation, weighted ฯลฯ) และออกแบบ hybrid DNS ด้วย Route 53 Resolver
• แยกได้ว่าเมื่อไหร่ใช้ CloudFront vs Global Accelerator
• วาง network security: Security Group vs NACL, AWS Network Firewall, และ centralized inspection VPC

ขอบเขต: WAF และ AWS Shield เชิงลึก (managed rules, DDoS response) → บทที่ 09 (อ้างอิงเท่านั้น); content delivery strategy เชิง performance (cache behavior tuning, origin optimization) → บทที่ 11; compute ที่อยู่หลัง load balancer (target group, Auto Scaling, ECS/EKS) → บทที่ 05; load balancer แต่ละชนิด (ALB/NLB/GWLB) จะนิยามเต็มที่บทที่ 05 บทนี้แตะเฉพาะมุม network insertion

---

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

2.1 VPC design: CIDR planning ระดับ organization

VPC (Virtual Private Cloud) คือเครือข่ายเสมือนที่กำหนดด้วย CIDR block (เช่น 10.0.0.0/16) จุดที่ SA Pro ต้องคิดต่างจาก Associate คือ การวางแผน CIDR ทั้ง org ก่อนสร้าง VPC ตัวแรก เพราะเมื่อ VPC เชื่อมกัน (ผ่าน peering, Transit Gateway, VPN, Direct Connect) ระบบ routing ใช้ IP เป็นตัวตัดสิน ถ้า CIDR สอง VPC ทับกัน (overlap) จะ route หากันไม่ได้เลย และการเปลี่ยน CIDR หลักของ VPC ที่มี workload อยู่แล้วทำได้ยากมาก (ต้อง migrate)

หลักการวางแผน:

• จองช่วง CIDR ใหญ่ให้ทั้ง org จาก private ranges (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) แล้วแบ่งเป็น block ต่อ region ต่อ environment ต่อ account อย่างเป็นระบบ — มักใช้ AWS VPC IP Address Manager (IPAM) เป็น source of truth ในการจัดสรร CIDR แบบไม่ทับกันทั่ว org และตรวจ utilization
• หลีกเลี่ยงการใช้ CIDR ที่ทับกับ on-premises เพราะจะเชื่อม hybrid ไม่ได้
• เผื่อโต: VPC รับได้ตั้งแต่ /28 (16 IP) ถึง /16 (65,536 IP) และเพิ่ม secondary CIDR ได้ภายหลัง แต่การวางแผนแต่แรกดีกว่าการมาต่อทีหลัง
• IP หายไป 5 ตัวต่อ subnet เสมอ: AWS จอง 5 IP แรกของทุก subnet (network address, VPC router, DNS, future use, broadcast) — /28 จึงใช้ได้จริง 11 IP

CIDR overlap เป็น distractor ยอดฮิต: ถ้าโจทย์บอกว่าสอง VPC มี CIDR เดียวกันแล้วถามให้ peering — peering ทำไม่ได้เมื่อ overlap ทางแก้คือ PrivateLink (ดูข้อ 2.5) หรือ NAT/re-IP

2.2 Subnet tiers, route tables และ gateway ต่าง ๆ

Subnet เป็นทรัพยากรระดับ AZ เดียว (subnet หนึ่งอยู่ได้ AZ เดียวเท่านั้น) การออกแบบ multi-AZ จึงต้องมี subnet ในแต่ละ AZ ที่ต้องการ HA รูปแบบมาตรฐานคือ 3-tier subnet:

• Public subnet: มี route ไป Internet Gateway (IGW) — วาง load balancer, NAT Gateway, bastion (แต่ SA Pro นิยมใช้ SSM Session Manager แทน bastion, ดูบทที่ 11)
• Private subnet (app tier): ไม่มี route ตรงสู่ internet; ออก internet ผ่าน NAT Gateway ใน public subnet
• Private subnet (data tier): database, ไม่มี outbound internet เลยหากไม่จำเป็น

Route table ตัดสินว่า traffic จาก subnet ไปทางไหน — subnet หนึ่งผูกกับ route table เดียว (แต่ route table หนึ่งใช้กับหลาย subnet ได้) การกำหนด “subnet เป็น public หรือ private” ไม่ได้อยู่ที่ชื่อ แต่อยู่ที่ route table มี route ไป IGW หรือไม่

Gateway ที่ต้องแยกให้ออก:

Gateway	ทิศทาง	ใช้กับ	หมายเหตุ
Internet Gateway (IGW)	ทั้ง inbound + outbound, IPv4/IPv6	ทั้ง VPC (1 ตัวต่อ VPC)	ต้องมี public IP หรือ Elastic IP; ตัว IGW เองไม่มีค่าใช้จ่าย
NAT Gateway	outbound-only (IPv4)	private subnet ออก internet	managed, scale เอง, คิดเงินต่อชั่วโมง + ต่อ GB ที่ประมวลผล
Egress-only IGW	outbound-only (IPv6)	private subnet IPv6 ออก internet	คู่ขนานของ NAT Gateway แต่สำหรับ IPv6 (IPv6 เป็น public เสมอ ไม่มี NAT)

2.3 NAT Gateway vs NAT instance

ทั้งคู่ทำหน้าที่ให้ private subnet ออก internet ได้ (เช่น ดึง OS update) โดยไม่เปิดให้ internet เข้ามา แต่ต่างกันเชิง operational มาก:

ประเด็น	NAT Gateway	NAT instance
การจัดการ	fully managed	ต้องดูแล EC2 เอง (patch, sizing)
HA	HA ภายใน AZ เดียวโดยอัตโนมัติ (แต่ต้องวางหนึ่งตัวต่อ AZ เพื่อกัน AZ ล่ม)	ต้องทำ HA เอง (script failover)
Bandwidth	สูงถึง ~100 Gbps อัตโนมัติ	จำกัดตาม instance type
Security Group	แนบไม่ได้ (ใช้ NACL ที่ subnet)	แนบได้
Port forwarding / bastion	ทำไม่ได้	ทำได้ (ใช้เป็น bastion ได้)
ค่าใช้จ่าย	ต่อชั่วโมง + ต่อ GB processed	ค่า EC2 (อาจถูกกว่าที่ traffic ต่ำมาก)

คำตอบมาตรฐาน SA Pro = NAT Gateway เพราะ least operational overhead และ HA ในตัว NAT instance เป็นคำตอบเฉพาะเมื่อโจทย์ต้องการ port forwarding, ใช้เป็น bastion ด้วย, หรือ traffic ต่ำมากจนต้องการประหยัดสุด ๆ (พบน้อย) ข้อควรระวังเรื่อง HA: ถ้าวาง NAT Gateway ตัวเดียวใน AZ-A แล้ว AZ-A ล่ม private subnet ใน AZ-B จะออก internet ไม่ได้ → ต้องวาง NAT Gateway หนึ่งตัวต่อ AZ และให้ route table ของแต่ละ AZ ชี้ NAT ใน AZ ตัวเอง (trade-off: cost เพิ่มตามจำนวน AZ)

2.4 การเชื่อม VPC: peering vs Transit Gateway vs Cloud WAN

นี่คือหัวใจของบทและออกสอบหนักที่สุด

VPC peering = การเชื่อม VPC สองตัวแบบ 1:1 ผ่าน AWS backbone (ไม่ผ่าน internet) ข้อจำกัดที่ต้องท่องให้ขึ้นใจ:

• Non-transitive: ถ้า A-B peering และ B-C peering, A จะคุยกับ C ไม่ได้ (ต้องสร้าง A-C แยก) — นี่คือ distractor ที่บทที่ 01 ฝากมา (ดูบทที่ 01) ว่าเป็น “ตัวเลือกที่เป็นไปไม่ได้ทางเทคนิค”
• ต้องสร้าง peering + route + security แบบ full mesh: N VPC ต้องการ N(N-1)/2 connection — 10 VPC = 45 connection, 100 VPC = 4,950 connection → ไม่ scale
• CIDR ห้าม overlap
• ข้าม region และข้าม account ได้ (inter-region peering)
• ค่าใช้จ่าย: ไม่มีค่า connection ต่อชั่วโมง จ่ายเฉพาะ data transfer (ถูกกว่า TGW ที่ traffic ต่ำ)

AWS Transit Gateway (TGW) = network hub ที่ทุก VPC/VPN/Direct Connect เชื่อมเข้า (hub-and-spoke) แล้ว route หากันผ่าน hub แก้ปัญหา full mesh:

• Transitive by design: attach VPC หลายตัวเข้า TGW เดียว แล้วทุกตัวคุยกันได้ (ตาม route table) — N VPC ใช้ N attachment แทน N(N-1)/2
• TGW route tables: หัวใจของการทำ network segmentation — สร้างหลาย route table แล้ว associate attachment ต่างกันเพื่อคุมว่า VPC ไหนคุยกับใครได้ เช่น แยก prod/non-prod, ทำ isolated VPC ที่ออก internet ผ่าน central egress ได้แต่คุยกันเองไม่ได้
• Inter-region peering: เชื่อม TGW ข้าม region ได้ (encrypted over AWS backbone) สร้าง global network
• Appliance mode: เปิดเมื่อมี stateful appliance (firewall) ใน inspection VPC ที่ multi-AZ — บังคับให้ traffic ทั้ง flow (ไป-กลับ) ผ่าน AZ เดียวกันของ appliance เพื่อไม่ให้ stateful firewall drop packet เพราะเห็นครึ่ง flow (จุดออกสอบสำคัญเมื่อทำ centralized inspection แบบ multi-AZ)
• แชร์ข้าม account ด้วย RAM (ดูบทที่ 03): Networking account ใน Infrastructure OU เป็นเจ้าของ TGW แล้วแชร์ให้ทุก account ใน org attach VPC เข้ามา — นี่คือ cross-reference ที่บทที่ 02/03 ฝากมา
• ค่าใช้จ่าย: ต่อ attachment ต่อชั่วโมง + ต่อ GB ที่ผ่าน TGW (แพงกว่า peering ที่ scale เล็ก แต่คุ้มและจัดการง่ายกว่ามากที่ scale ใหญ่)

AWS Cloud WAN = บริการจัดการ global network แบบ policy-driven ที่วางทับ TGW ขึ้นไปอีกชั้น [uncertain รายละเอียดเชิงลึกล่าสุด] — ใช้ central policy document (JSON) กำหนด segment และ region แล้ว Cloud WAN provision/เชื่อม core network ให้อัตโนมัติทั่วโลก เหมาะกับองค์กรระดับ global ที่มีหลาย region และต้องการ network segmentation แบบ centralized โดยไม่ต้อง peer TGW ข้าม region เองทีละคู่ แกนตัดสินใจ: TGW = regional hub (peer ข้าม region เองได้แต่ต้องจัดการ); Cloud WAN = global orchestration หลาย region ด้วย policy เดียว หากโจทย์เน้น “global, หลาย region มาก, centralized segmentation policy, least operational overhead” → Cloud WAN; หากเป็น regional หรือไม่กี่ region → TGW เพียงพอ

2.5 AWS PrivateLink & VPC endpoints

โดยปกติการเรียก AWS service API (เช่น S3, DynamoDB) จาก private subnet ต้องออก internet ผ่าน NAT Gateway VPC endpoint ทำให้เข้าถึง service ได้แบบ private ไม่ออก internet เลย มี 3 แบบ:

ประเภท endpoint	ใช้กับ	กลไก	ค่าใช้จ่าย
Gateway endpoint	S3, DynamoDB เท่านั้น	เพิ่ม route ใน route table ชี้ prefix list ของ service	ฟรี
Interface endpoint (PrivateLink)	service อื่นเกือบทั้งหมด (SQS, KMS, EC2 API, …) + service ของบุคคลอื่น	สร้าง ENI ที่มี private IP ใน subnet ของคุณ	ต่อชั่วโมง + ต่อ GB
Gateway Load Balancer endpoint (GWLBe)	ส่ง traffic ไป fleet ของ third-party appliance (firewall/IDS)	คู่กับ Gateway Load Balancer	ต่อชั่วโมง + ต่อ GB

Gateway endpoint ฟรีและเหมาะกับ S3/DynamoDB — โจทย์ที่บอก “EC2 ใน private subnet ต้องเข้า S3 โดยไม่ผ่าน internet และประหยัดที่สุด” คำตอบคือ gateway endpoint (ไม่ใช่ interface endpoint ที่มีค่าใช้จ่าย, ไม่ใช่ NAT Gateway ที่ทั้งแพงและออก internet)

AWS PrivateLink (interface endpoint + endpoint service) เป็นแนวคิดที่ทรงพลังสำหรับ SA Pro: ผู้ให้บริการ (provider) วาง service หลัง Network Load Balancer แล้วสร้าง endpoint service ผู้บริโภค (consumer) สร้าง interface endpoint เชื่อมเข้ามา ได้ private IP ใน VPC ตนเอง — service ปรากฏเหมือนอยู่ใน VPC ของ consumer เอง

การแก้ปัญหา CIDR overlap ด้วย PrivateLink (จุดที่ออกสอบและ elegant มาก): เมื่อสอง VPC มี CIDR ทับกันจน peering/TGW routing ทำไม่ได้ แต่ต้องการให้ VPC หนึ่งเรียก service เฉพาะตัวในอีก VPC — PrivateLink แก้ได้เพราะการเชื่อมผ่าน endpoint ไม่พึ่ง IP routing ระหว่าง VPC (traffic ไปที่ ENI ของ endpoint ไม่ได้ route ไปทั้ง CIDR) จึง expose เฉพาะ endpoint ที่ต้องการโดยไม่สน CIDR overlap trade-off: PrivateLink เปิดทาง one-way, per-service (unidirectional จาก consumer → provider service) ไม่ใช่การเชื่อมเครือข่ายเต็มแบบ peering/TGW

2.6 Hybrid: AWS Direct Connect (DX)

Direct Connect = สายเชื่อม dedicated ระหว่าง data center ของลูกค้ากับ AWS ผ่าน DX location (ไม่ผ่าน public internet) ให้ bandwidth คงที่, latency ต่ำและคงเส้นคงวา ต่างจาก VPN ที่วิ่งบน internet (latency แปรปรวน)

VIF (Virtual Interface) 3 ชนิด:

VIF	เข้าถึงอะไร	ใช้เมื่อ
Private VIF	resource ใน VPC เดียว (private IP) ผ่าน VGW	เชื่อม 1 VPC โดยตรง
Public VIF	AWS public services (S3, DynamoDB public endpoint) ผ่าน public IP บน DX	ต้องการเข้า S3 ผ่านสาย DX โดยไม่ผ่าน internet
Transit VIF	เชื่อม DX เข้า Transit Gateway ผ่าน Direct Connect Gateway	เชื่อม on-prem เข้าหลาย VPC ผ่าน TGW hub

Direct Connect Gateway (DXGW) = global resource ที่ให้ DX connection เดียวเข้าถึง VPC ในหลาย region (ยกเว้น China) และเชื่อมกับ VGW หรือ TGW ได้ — แก้ปัญหาที่ private VIF ผูกกับ VGW ตัวเดียว DXGW ทำให้ 1 สาย DX เข้าหลาย VPC/region ได้

LAG (Link Aggregation Group) = รวมหลาย DX connection ทางกายภาพให้เป็น logical link เดียว เพิ่ม bandwidth และ redundancy (ต้องเป็น port ความเร็วเดียวกันและ DX location เดียวกัน)

Resiliency models (ออกสอบเรื่อง SLA และการวางสาย):

• Maximum Resiliency: สอง DX connection จาก สอง DX location แยกกัน (แต่ละ location มีอุปกรณ์แยก) — ทน device และ location ล่ม, SLA สูงสุด (99.99%)
• High Resiliency: สอง DX connection จากสอง DX location แต่ไม่ redundant ระดับ device ในแต่ละ location — ทน location ล่ม (99.9%)
• Development/single: connection เดียว — ไม่มี SLA สำหรับ production

SiteLink = ฟีเจอร์ที่ให้สอง DX location คุยกันตรงผ่าน AWS global backbone (site-to-site ผ่าน AWS) โดยไม่ต้อง route ผ่าน region ใด region หนึ่ง — ใช้เชื่อม branch office/data center หลายแห่งเข้าหากันโดยใช้ AWS backbone เป็น WAN

ข้อจำกัดสำคัญ: DX เพียงสายเดียวไม่ถือเป็น HA (สายขาด/อุปกรณ์ล่มได้) และการ provision DX ใช้เวลาเป็นสัปดาห์ถึงเดือน — จึงมักจับคู่กับ Site-to-Site VPN เป็น backup ที่ตั้งได้ทันที

2.7 Site-to-Site VPN

Site-to-Site VPN = IPsec tunnel ระหว่าง on-prem (customer gateway) กับ AWS (VGW หรือ TGW) วิ่งบน internet ตั้งได้ภายในไม่กี่นาที แต่ latency แปรปรวนตาม internet และ bandwidth จำกัด (~1.25 Gbps ต่อ tunnel)

• ทุก VPN connection มี 2 tunnel ไปคนละ endpoint ของ AWS เพื่อ HA (ควร config ทั้งสอง)
• VPN เป็น backup ของ DX: pattern มาตรฐานคือ DX เป็น primary (เร็ว/นิ่ง) + VPN เป็น backup (ถูก/ตั้งเร็ว) ใช้ BGP routing ให้ failover อัตโนมัติ — โจทย์ “resilient hybrid แต่คุมงบ” มักตอบ DX + VPN backup แทน DX คู่ (สองสาย DX แพงกว่า)
• ECMP (Equal-Cost Multi-Path): เมื่อ attach VPN เข้า Transit Gateway สามารถรวมหลาย tunnel เพื่อ aggregate bandwidth เกินขีดจำกัด tunnel เดียว (ECMP ใช้ได้บน TGW ไม่ได้บน VGW)
• Accelerated VPN: route VPN traffic ผ่าน AWS Global Accelerator edge (anycast) เพื่อลด latency/jitter โดยเข้า AWS backbone เร็วที่สุดจาก edge ใกล้ที่สุด

Networking สำหรับ AD hybrid (cross-reference จากบทที่ 03): การให้ EC2 domain-join กับ on-prem AD หรือทำ two-way trust กับ AWS Managed Microsoft AD ต้องมี connectivity (DX หรือ VPN), security group เปิด port ที่ AD ใช้ (LDAP 389, Kerberos 88, DNS 53 ฯลฯ), และ DNS resolution สองทาง ผ่าน Route 53 Resolver (ดูข้อ 2.8) เพื่อ resolve ทั้ง on-prem domain และ AWS

2.8 DNS: Amazon Route 53 และ Route 53 Resolver

Routing policies ของ Route 53 (ต้องแยกให้ออกว่าอันไหนแก้ปัญหาอะไร):

Policy	ตัดสินใจตาม	use case	health check
Simple	ไม่มีเงื่อนไข (1 record, หลาย IP สุ่ม)	single resource	ไม่รองรับ
Weighted	สัดส่วนน้ำหนักที่กำหนด	A/B testing, canary, gradual shift	รองรับ
Latency-based	region ที่ latency ต่ำสุดต่อผู้ใช้	ผู้ใช้ทั่วโลก, ลด latency	รองรับ
Failover	primary/secondary ตาม health	active-passive DR	จำเป็น (ตัวขับ failover)
Geolocation	ตำแหน่งทางภูมิศาสตร์ของผู้ใช้ (ทวีป/ประเทศ/รัฐ)	compliance ต่อประเทศ, localize content	รองรับ
Geoproximity	ระยะทางภูมิศาสตร์ + bias ที่ปรับได้	ปรับสัดส่วน traffic ตามพื้นที่ (traffic flow)	รองรับ
Multivalue answer	คืนหลาย IP ที่ healthy (สุ่ม)	HA แบบง่ายคล้าย DNS round-robin แต่มี health check	รองรับ

จุดที่สับสนบ่อย: latency-based vs geolocation — latency เลือกตาม “network latency จริง” (อาจไม่ใช่ region ที่ใกล้ที่สุดทางภูมิศาสตร์), geolocation เลือกตาม “ตำแหน่งผู้ใช้” (ใช้เมื่อ requirement เป็น compliance/legal ต้อง serve จาก region เฉพาะ) และ geolocation vs geoproximity — geolocation = ตาม boundary การเมือง (ประเทศ), geoproximity = ตามระยะทาง + bias ที่ขยาย/หด “รัศมี” ของ region ได้

Health checks: ตรวจ endpoint (HTTP/HTTPS/TCP), รวมกันเป็น calculated health check, และ CloudWatch alarm ได้ — เป็นตัวขับ failover routing

Private hosted zone (PHZ): DNS zone ที่ resolve ได้เฉพาะภายใน VPC ที่ associate — ใช้ตั้งชื่อภายใน (db.internal.example.com) ที่ไม่เปิดสู่ internet associate หลาย VPC/ข้าม account ได้

Route 53 Resolver (สำหรับ hybrid DNS):

• Inbound endpoint: ให้ on-prem query DNS ของ AWS (resolve ชื่อใน private hosted zone) — on-prem DNS forward query มาที่ IP ของ inbound endpoint
• Outbound endpoint + forwarding rules: ให้ resource ใน VPC query ชื่อ on-prem (เช่น corp.example.com) โดย forward ไป on-prem DNS server — จำเป็นสำหรับ AD hybrid ที่ต้อง resolve domain controller on-prem
• Route 53 Resolver DNS Firewall: บล็อก/อนุญาต query ตาม domain (block DNS exfiltration, บล็อก domain ที่รู้ว่าเป็น malware) ผ่าน domain list — เป็น control ระดับ DNS ที่คู่กับ Network Firewall

2.9 Edge & Global: CloudFront vs Global Accelerator

Amazon CloudFront = CDN ที่ cache content ที่ edge location ทั่วโลก ลด latency สำหรับ static + dynamic content ผ่าน HTTP/HTTPS (L7) ในบทนี้สนใจมุม routing/security: CloudFront terminate TLS ที่ edge, รองรับ origin เป็น S3/ALB/custom, และเป็นจุดวาง AWS WAF (ดูบทที่ 09) รายละเอียด cache behavior/performance tuning → บทที่ 11

AWS Global Accelerator (GA) = ให้ anycast static IP สองตัว ที่ประกาศจาก edge ทั่วโลก traffic เข้า edge ใกล้สุดแล้ววิ่งบน AWS backbone ไปยัง endpoint (ALB/NLB/EC2/EIP) ทำงานที่ L4 (TCP/UDP) ไม่ cache

แกนตัดสินใจ CloudFront vs Global Accelerator:

ประเด็น	CloudFront	Global Accelerator
Layer	L7 (HTTP/HTTPS)	L4 (TCP/UDP)
Caching	มี (CDN)	ไม่มี
IP	domain name (CloudFront)	static anycast IP 2 ตัว
Protocol	เว็บ/HTTP เป็นหลัก	non-HTTP ได้ (game, IoT, VoIP, MQTT)
Use case	เว็บไซต์, static/dynamic content, media	non-HTTP workload, ต้องการ static IP ที่ whitelist ได้, fast regional failover, TCP/UDP
Failover	origin failover	ข้าม region ระดับวินาที (health-based)

keyword ที่ชี้ GA: static IP address ที่ต้อง whitelist ใน firewall, non-HTTP protocol (UDP/TCP gaming), fast failover across regions, ต้องการ deterministic AWS backbone path keyword ที่ชี้ CloudFront: cache static content, reduce latency for web, media streaming, WAF ที่ edge

2.10 Network security: Security Group vs NACL

ประเด็น	Security Group (SG)	Network ACL (NACL)
ระดับ	ENI / instance	subnet
State	stateful (reply กลับอัตโนมัติ)	stateless (ต้องเปิด rule ทั้ง in และ out)
Rule	allow เท่านั้น (implicit deny ที่เหลือ)	allow และ deny (มีลำดับ rule number)
การประเมิน	รวมทุก rule (ไม่มีลำดับ)	ตามลำดับ rule number จากน้อยไปมาก, เจอ match แรกใช้เลย
default	deny inbound ทั้งหมด, allow outbound ทั้งหมด	default NACL: allow ทั้งหมด; custom NACL: deny ทั้งหมด

จุดออกสอบ:

• stateful vs stateless: SG จำ connection ได้ — เปิด inbound แล้ว reply ออกได้เอง; NACL ต้องเปิด ephemeral port range (1024–65535) ฝั่ง outbound สำหรับ return traffic เอง (ลืมข้อนี้ = distractor)
• NACL ทำ explicit deny ได้ (บล็อก IP เฉพาะ) ในขณะที่ SG ทำไม่ได้ (SG allow เท่านั้น) — โจทย์ “block a specific malicious IP range” → NACL (หรือ Network Firewall/WAF)
• SG อ้างอิง SG อื่นเป็น source ได้ (chaining, เช่น “app tier รับจาก SG ของ web tier”) ทำให้ scale ดีกว่า IP-based
• Defense in depth: ใช้ทั้งสองชั้น — NACL เป็น broad guardrail ระดับ subnet, SG เป็น fine-grained ระดับ instance

2.11 AWS Network Firewall และ centralized inspection

AWS Network Firewall = managed stateful/stateless firewall ระดับ VPC (built บน GWLB) ที่ทำ deep packet inspection, IPS/IDS (Suricata-compatible rules), domain filtering, และ protocol detection — เหนือกว่า SG/NACL ที่ทำได้แค่ L3/L4 ตาม IP/port

Centralized egress / inspection architecture: แทนที่ทุก VPC จะมี NAT Gateway + firewall ของตัวเอง (แพงและกระจัดกระจาย) ใช้ inspection VPC / egress VPC กลาง:

• ทุก spoke VPC attach เข้า Transit Gateway
• TGW route table บังคับให้ traffic ที่จะออก internet (หรือข้าม VPC) วิ่งผ่าน inspection VPC ที่มี Network Firewall (หรือ third-party appliance หลัง GWLB) ก่อน
• inspection VPC มี NAT Gateway กลางสำหรับ egress → รวม NAT ไว้ที่เดียว (ลด cost, รวม inspection)
• เมื่อ inspection appliance เป็น stateful และ multi-AZ ต้องเปิด TGW appliance mode (ดูข้อ 2.4) เพื่อไม่ให้ traffic ไป-กลับข้าม AZ จน firewall เห็นครึ่ง flow

trade-off: centralized inspection ลด cost/ops และให้ single point of control แต่เพิ่ม latency (traffic วิ่งผ่าน hub) และทำให้ inspection VPC เป็น critical path (ต้องออกแบบ HA ให้ดี)

GWLB + endpoint เป็นกลไกเบื้องหลังการ “insert” third-party appliance (Palo Alto, Fortinet ฯลฯ) แบบ transparent — GWLB ใช้ GENEVE encapsulation ส่ง traffic ไป fleet ของ appliance โดยไม่ต้องเปลี่ยน routing ที่ปลายทาง (WAF/Shield เชิงลึก → บทที่ 09)

---

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

3.1 เลือกกลไกเชื่อมต่อ VPC-to-VPC / VPC-to-service

ต้องการ	ใช้	ทำไม / trade-off
เชื่อม 2 VPC, จำนวนน้อย, คุมงบ	VPC peering	ถูก (ไม่มีค่า hourly) แต่ non-transitive, ไม่ scale, CIDR ห้าม overlap
เชื่อมหลายสิบ–ร้อย VPC + on-prem, ทั้ง org	Transit Gateway	transitive, hub เดียว, segment ด้วย route table; แพงกว่าแต่ scale + ops ต่ำ
global หลาย region + centralized segmentation policy	Cloud WAN	policy-driven ทั่วโลก [uncertain]; over-engineered ถ้าไม่กี่ region
expose service เฉพาะตัว ให้ VPC/บุคคลอื่นเรียก	PrivateLink (interface endpoint + endpoint service)	one-way per-service, แก้ CIDR overlap, ไม่เชื่อมทั้งเครือข่าย
EC2 private subnet เข้า S3/DynamoDB ประหยัดสุด	Gateway endpoint	ฟรี, ไม่ผ่าน internet
EC2 private subnet เข้า service AWS อื่น (KMS, SQS…) แบบ private	Interface endpoint	มี ENI + ค่าใช้จ่าย; private ไม่ผ่าน internet

3.2 เลือก hybrid connectivity

requirement	ใช้	หมายเหตุ
bandwidth สูง, latency นิ่ง, production critical	Direct Connect	ตั้งนาน (สัปดาห์–เดือน), ต้องคู่ backup
ตั้งเร็ว, ชั่วคราว, backup ของ DX, คุมงบ	Site-to-Site VPN	วิ่งบน internet, latency แปรปรวน
resilient hybrid สูงสุด	DX จาก 2 location (Maximum Resiliency)	แพงสุด, SLA 99.99%
resilient hybrid คุมงบ	DX (primary) + VPN (backup) BGP failover	คุ้มกว่า DX คู่
DX เข้าหลาย VPC/หลาย region	DX + Transit VIF + DXGW + TGW	1 สายเข้าหลาย VPC
aggregate VPN bandwidth เกิน 1 tunnel	VPN บน TGW + ECMP	ECMP ใช้ได้เฉพาะบน TGW

3.3 เลือก edge / global routing

requirement	ใช้
cache static/dynamic web content, WAF ที่ edge	CloudFront
static anycast IP, non-HTTP (TCP/UDP), fast regional failover	Global Accelerator
serve จาก region เฉพาะตาม compliance ประเทศ	Route 53 geolocation
ลด latency ให้ผู้ใช้ทั่วโลก (multi-region app)	Route 53 latency-based
active-passive DR failover	Route 53 failover + health check

---

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

4.1 Hub-and-spoke ทั้ง organization ด้วย Transit Gateway + centralized egress

โจทย์: องค์กรมี 60 account, ~150 VPC ใน 2 region, ต้องเชื่อมทุก VPC เข้า on-prem ผ่าน DX, ให้ prod และ non-prod แยกกันไม่คุยกัน, และรวม egress internet + inspection ไว้ที่เดียวเพื่อลด cost และ audit ง่าย โดย least operational overhead

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

• Networking account ใน Infrastructure OU (ดูบทที่ 02) เป็นเจ้าของ Transit Gateway ต่อ region และแชร์ให้ทุก account ผ่าน RAM (ดูบทที่ 03) → account อื่นแค่ attach VPC เข้ามา ไม่ต้องดูแล hub เอง
• TGW route tables แยก: route table “prod” (associate เฉพาะ prod VPC), “non-prod”, และ “inspection/egress” — คุมว่า prod ↔ non-prod คุยกันไม่ได้ (network segmentation)
• Inspection VPC กลางมี AWS Network Firewall (multi-AZ, เปิด appliance mode บน TGW) + NAT Gateway กลางสำหรับ egress
• DX + Transit VIF + Direct Connect Gateway เชื่อม on-prem เข้า TGW ทั้งสอง region; VPN backup ผ่าน TGW (ECMP) สำหรับ resiliency คุมงบ
• TGW inter-region peering เชื่อมสอง region เข้าด้วยกัน

Trade-off:

• ได้: scale เชิงเส้น (เพิ่ม VPC = 1 attachment), segmentation ชัด, egress/inspection รวมศูนย์ (cost + audit), ops ต่ำ (hub บริหารที่เดียว)
• เสีย: TGW มีค่า attachment + data processing (แพงกว่า peering ที่ scale เล็ก), traffic ผ่าน hub เพิ่ม latency นิดหน่อย, inspection VPC เป็น critical path (ต้อง HA), appliance mode เป็นรายละเอียดที่ต้องไม่ลืม
• ทำไมไม่ใช้ peering: 150 VPC = 11,000+ peering full mesh + non-transitive → เป็นไปไม่ได้เชิงปฏิบัติ

4.2 แก้ CIDR overlap ระหว่างองค์กรที่ควบรวมด้วย PrivateLink

โจทย์: บริษัท A ซื้อบริษัท B ทั้งคู่ใช้ 10.0.0.0/16 เหมือนกัน (overlap เต็ม) A ต้องเรียก REST API เพียงตัวเดียวที่รันใน VPC ของ B ไม่สามารถ re-IP VPC ของ B ได้ในระยะสั้น (workload เยอะ) วิธี minimal disruption

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

• ฝั่ง B: วาง API service หลัง Network Load Balancer แล้วสร้าง VPC endpoint service (PrivateLink)
• ฝั่ง A: สร้าง interface endpoint ชี้ไป endpoint service ของ B → ได้ private IP ใน CIDR ของ A เอง ที่ผูกกับ ENI ของ endpoint
• A เรียก API ผ่าน DNS ของ endpoint (หรือ private hosted zone) เหมือน service อยู่ใน VPC ตัวเอง

Trade-off:

• ได้: ข้ามปัญหา CIDR overlap ทันทีโดยไม่ต้อง re-IP, expose เฉพาะ 1 service (least privilege เชิง network), unidirectional ปลอดภัย
• เสีย: เชื่อมได้เฉพาะ per-service ไม่ใช่ทั้งเครือข่าย (ถ้าต้องเชื่อมหลาย service/สองทาง จะยุ่ง), มีค่า endpoint hourly + data
• ทำไมไม่ใช้ peering/TGW: routing ทั้ง CIDR ทับกัน → เป็นไปไม่ได้จนกว่าจะ re-IP ฝ่ายใดฝ่ายหนึ่ง

4.3 Multi-region active-passive DR ด้วย Route 53 + Global Accelerator

โจทย์: แอปสำคัญรันใน us-east-1 (primary) และมี warm standby ใน eu-west-1 (ดู DR strategy ที่บทที่ 08) ต้องการ failover ข้าม region อัตโนมัติเร็วที่สุด และ client บางส่วนเป็น IoT ที่ hardcode IP ปลายทาง (whitelist IP ได้ยาก)

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

• AWS Global Accelerator ให้ static anycast IP 2 ตัว ที่ client/IoT ใช้ตายตัว — endpoint group ชี้ ALB ในทั้งสอง region, health check ขับ failover ระดับวินาทีบน AWS backbone
• สำหรับ traffic เว็บ HTTP: อาจใช้ Route 53 failover routing + health check เป็นชั้น DNS เสริม (แต่ DNS failover ช้ากว่าเพราะ TTL/cache)

Trade-off:

• ได้: static IP ที่ whitelist ได้ (แก้ปัญหา IoT), failover เร็วกว่า DNS มาก (ไม่ต้องรอ TTL หมดอายุ), path บน AWS backbone นิ่ง
• เสีย: GA มีค่า fixed hourly + data premium; ถ้าเป็นเว็บ static ล้วน CloudFront อาจเหมาะกว่าและถูกกว่า
• ทำไมไม่ใช้ Route 53 อย่างเดียว: DNS caching ทำให้ failover ช้าและ client ที่ hardcode IP ไม่ได้ประโยชน์จาก DNS

4.4 Hybrid DNS + AD สำหรับ Windows workload (cross-reference บทที่ 03)

โจทย์: มี on-prem Active Directory เป็น source of truth, EC2 Windows บน AWS ต้อง domain-join และ resolve ทั้งชื่อ on-prem (corp.example.com) และชื่อภายใน AWS

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

• DX หรือ Site-to-Site VPN เป็น connectivity layer, security group เปิด port ที่ AD ต้องใช้ (DNS 53, LDAP 389/636, Kerberos 88, SMB 445 ฯลฯ)
• Route 53 Resolver outbound endpoint + forwarding rule: forward query ของ corp.example.com ไป on-prem DNS/domain controller
• Route 53 Resolver inbound endpoint: ให้ on-prem resolve ชื่อใน AWS private hosted zone (สองทาง)
• AWS Managed Microsoft AD ตั้ง two-way forest trust กับ on-prem AD (ดูบทที่ 03) หรือใช้ AD Connector หากไม่ต้อง host directory ใน AWS

Trade-off:

• ได้: SSO/domain-join ทำงานข้าม on-prem ↔ AWS, DNS resolve สองทางครบ
• เสีย: ต้องดูแล connectivity HA (DX+VPN backup), เปิด security group/NACL หลาย port (attack surface กว้างขึ้น ต้องคุมด้วย SG ที่แคบ), forwarding rule ต้อง maintain
• ทำไมไม่ใช้ public DNS: ชื่อภายในและ AD ไม่ควรอยู่บน public DNS (security)

---

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

1. คิดว่า VPC peering เป็น transitive — A-B และ B-C ไม่ทำให้ A คุย C ได้; คำตอบที่พึ่ง transitive peering เป็น distractor “เป็นไปไม่ได้ทางเทคนิค” (ดูบทที่ 01) ใช้ TGW แทน
2. พยายาม peer/route VPC ที่ CIDR overlap — ทำไม่ได้; ทางแก้คือ PrivateLink (per-service) หรือ re-IP ไม่ใช่ peering/TGW
3. เลือก interface endpoint สำหรับ S3/DynamoDB — สองบริการนี้ใช้ gateway endpoint ที่ฟรี; interface endpoint มีค่าใช้จ่ายและไม่จำเป็น (ยกเว้นต้องเข้าจาก on-prem ผ่าน DX/VPN ซึ่ง gateway endpoint ทำไม่ได้ → ต้องใช้ interface endpoint หรือ S3 access via public VIF)
4. วาง NAT Gateway ตัวเดียวแล้วคิดว่า HA — AZ ที่มี NAT ล่ม = AZ อื่นออก internet ไม่ได้; ต้องหนึ่งตัวต่อ AZ
5. ลืม ephemeral port บน NACL — NACL stateless ต้องเปิด return traffic (1024–65535) outbound เอง; SG stateful ไม่ต้อง
6. ใช้ SG เพื่อ block IP เฉพาะ — SG allow เท่านั้น (ทำ deny ไม่ได้); block IP ต้องใช้ NACL / Network Firewall / WAF
7. สับสน latency-based กับ geolocation routing — latency = network latency จริง (performance); geolocation = ตำแหน่งผู้ใช้ (compliance/legal)
8. เลือก CloudFront สำหรับ non-HTTP หรือ static IP — CloudFront เป็น L7/HTTP และไม่ให้ static IP; UDP/TCP หรือ whitelist IP → Global Accelerator
9. คิดว่า DX สายเดียว = HA — สายขาด/อุปกรณ์ล่มได้; production ต้อง DX คู่ หรือ DX + VPN backup
10. ลืม appliance mode บน TGW เมื่อทำ stateful inspection multi-AZ — traffic ไป-กลับข้าม AZ ทำให้ firewall เห็นครึ่ง flow แล้ว drop
11. สับสน Transit VIF กับ Private VIF — Private VIF = 1 VPC ผ่าน VGW; Transit VIF = เข้า TGW (หลาย VPC) ผ่าน DXGW
12. ใช้ Direct Connect เมื่อ requirement คือ “ตั้งได้เร็ว/ชั่วคราว” — DX ตั้งเป็นสัปดาห์–เดือน; ต้องการเร็ว = Site-to-Site VPN
13. คิดว่า Route 53 failover เร็วเท่า Global Accelerator — DNS ติด TTL/caching; failover ระดับวินาทีต้อง Global Accelerator
14. แชร์ subnet/TGW ด้วย VPC peering แทน RAM — RAM ใช้แชร์ resource ให้ deploy/attach ร่วม (ดูบทที่ 03); peering เชื่อม path ระหว่าง VPC คนละเรื่อง

---

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

ข้อ 1 — องค์กรมี 120 VPC ใน 40 account ต้องเชื่อมทั้งหมดให้คุยกันได้และเชื่อมเข้า on-prem โดย least operational overhead และรองรับการเติบโต แนวทางที่เหมาะสุดคือ?

A. VPC peering full mesh ระหว่างทุก VPC B. Transit Gateway เป็น hub, แชร์ผ่าน RAM, ทุก VPC attach เข้ามา C. เชื่อมทุก VPC ด้วย Site-to-Site VPN หากัน D. รวมทุก workload เป็น VPC เดียว

เฉลย

B — TGW เป็น transitive hub, attach เชิงเส้น, แชร์ข้าม account ด้วย RAM, segment ด้วย route table

• A ผิด: 120 VPC = ~7,140 peering + non-transitive → ไม่ scale และจัดการไม่ไหว
• C ผิด: VPN VPC-to-VPC ไม่ใช่รูปแบบที่ใช้จริง, ops มหาศาล
• D ผิด: ทำลาย blast radius isolation และ account boundary (ดูบทที่ 02) — over-consolidation

ข้อ 2 — สองบริษัทควบรวม ทั้งคู่ใช้ CIDR 10.0.0.0/16 ทับกันเต็ม บริษัท A ต้องเรียก API หนึ่งตัวใน VPC ของ B ไม่สามารถ re-IP ได้ในระยะสั้น วิธีที่ทำได้คือ?

A. VPC peering ระหว่าง A และ B B. Transit Gateway attach ทั้งสอง VPC C. AWS PrivateLink: B สร้าง endpoint service (หลัง NLB), A สร้าง interface endpoint D. เปลี่ยน CIDR ของ B ทันที

เฉลย

C — PrivateLink เชื่อม per-service ผ่าน ENI ไม่พึ่ง IP routing ระหว่าง VPC จึงข้าม CIDR overlap ได้

• A, B ผิด: routing พึ่ง IP; CIDR ทับกัน → ทำไม่ได้
• D ผิด: re-IP VPC ที่มี workload เยอะทำไม่ได้ในระยะสั้น (ขัด minimal disruption)

ข้อ 3 — EC2 ใน private subnet ต้องอ่าน/เขียน S3 โดยไม่ผ่าน public internet และต้องการ most cost-effective ควรใช้อะไร?

A. NAT Gateway B. Interface endpoint (PrivateLink) สำหรับ S3 C. Gateway endpoint สำหรับ S3 D. Internet Gateway + public IP

เฉลย

C — gateway endpoint สำหรับ S3/DynamoDB ฟรี และไม่ผ่าน internet (เพิ่ม route ชี้ prefix list)

• A ผิด: NAT Gateway ออก internet และมีค่า hourly + per-GB
• B ผิด: interface endpoint ใช้ได้แต่มีค่าใช้จ่าย ไม่คุ้มเมื่อ gateway endpoint ฟรี (ยกเว้นต้องเข้าจาก on-prem)
• D ผิด: ออก public internet ขัด requirement

ข้อ 4 — ต้องการเชื่อม on-prem เข้า AWS แบบ bandwidth สูง latency นิ่งสำหรับ production และต้อง resilient แต่คุมงบ (ไม่อยากซื้อ DX สองสาย) แนวทางที่เหมาะสุด?

A. Site-to-Site VPN อย่างเดียว B. Direct Connect สายเดียว C. Direct Connect (primary) + Site-to-Site VPN (backup) ด้วย BGP failover D. Direct Connect สองสายจากสอง location

เฉลย

C — DX ให้ performance, VPN backup ตั้งเร็ว/ถูก, BGP failover อัตโนมัติ — resilient แบบคุมงบ

• A ผิด: VPN บน internet latency แปรปรวน ไม่ตรง “นิ่ง/production”
• B ผิด: DX สายเดียวไม่ HA
• D ผิด: resilient สูงสุดแต่แพงกว่า (ขัด “คุมงบ/ไม่อยากซื้อ DX สองสาย”)

ข้อ 5 — เกมออนไลน์ใช้ UDP มีผู้เล่นทั่วโลก ต้องการ latency ต่ำ, static IP ที่ whitelist ได้, และ failover ข้าม region เร็ว ควรใช้อะไร?

A. Amazon CloudFront B. AWS Global Accelerator C. Route 53 latency-based routing D. Application Load Balancer ต่อ region

เฉลย

B — Global Accelerator ให้ static anycast IP, รองรับ UDP (L4), วิ่งบน backbone, failover ระดับวินาที

• A ผิด: CloudFront เป็น L7/HTTP และไม่ให้ static IP — ไม่เหมาะ UDP game
• C ผิด: DNS ติด TTL/caching, ไม่ให้ static IP, failover ช้า
• D ผิด: ALB เป็น L7 ต่อ region ไม่ให้ global anycast/static IP

ข้อ 6 — ต้องบล็อก inbound จาก IP range ที่เป็นอันตรายเฉพาะช่วงหนึ่งที่ระดับ subnet ควรใช้กลไกใด?

A. Security Group deny rule B. Network ACL deny rule ที่ subnet C. IAM policy D. Route table

เฉลย

B — NACL ทำ explicit deny ตาม IP ได้ และทำงานที่ระดับ subnet

• A ผิด: SG มีแต่ allow (ทำ deny ไม่ได้)
• C ผิด: IAM คุมสิทธิ์ API ไม่เกี่ยวกับ network filtering
• D ผิด: route table กำหนดเส้นทาง ไม่ใช่ filter security

ข้อ 7 — บริษัทมี on-prem AD และ EC2 Windows บน AWS ต้อง resolve ทั้งชื่อ corp.example.com (on-prem) และชื่อภายใน AWS ควรตั้งอะไร?

A. Route 53 public hosted zone อย่างเดียว B. Route 53 Resolver outbound endpoint (forward corp.example.com ไป on-prem) + inbound endpoint (ให้ on-prem resolve AWS) C. NAT Gateway D. CloudFront

เฉลย

B — outbound endpoint + forwarding rule ส่ง query on-prem domain ไป on-prem DNS; inbound endpoint ให้ on-prem resolve ชื่อ AWS (hybrid DNS สองทาง)

• A ผิด: public zone ไม่ resolve ชื่อภายใน/AD และไม่ควรเปิด internal names สู่ internet
• C, D ผิด: ไม่เกี่ยวกับ DNS resolution

ข้อ 8 — ทำ centralized egress + stateful firewall inspection ที่ inspection VPC แบบ multi-AZ ผ่าน Transit Gateway พบว่า connection บางส่วนถูก drop เป็นครั้งคราว สาเหตุที่น่าจะเป็นและวิธีแก้คือ?

A. NAT Gateway น้อยเกินไป — เพิ่ม NAT B. traffic ไป-กลับข้าม AZ ทำให้ stateful firewall เห็นครึ่ง flow — เปิด TGW appliance mode C. CIDR overlap — re-IP D. SG ปิด outbound — เปิด SG

เฉลย

B — stateful appliance ต้องเห็นทั้งสองทิศของ flow ใน AZ เดียว; TGW appliance mode บังคับ symmetric routing

• A ผิด: ปัญหาไม่ใช่ throughput NAT แต่เป็น asymmetric flow
• C ผิด: ถ้า CIDR overlap จะเชื่อมไม่ได้เลย ไม่ใช่ drop เป็นครั้งคราว
• D ผิด: ถ้า SG ปิด outbound จะไม่ผ่านเลยตั้งแต่ต้น ไม่ใช่ intermittent

ข้อ 9 — ต้องเชื่อม Direct Connect หนึ่งสายให้เข้าถึง VPC หลายตัวในหลาย region ควรใช้อะไร?

A. Private VIF ต่อ VGW ของ VPC หนึ่งตัว B. Public VIF C. Transit VIF + Direct Connect Gateway + Transit Gateway D. Site-to-Site VPN

เฉลย

C — Transit VIF เชื่อม DX เข้า TGW ผ่าน DXGW ทำให้ 1 สายเข้าหลาย VPC/หลาย region ได้

• A ผิด: Private VIF ผูก VGW ของ VPC เดียว ไม่ scale หลาย VPC
• B ผิด: Public VIF เข้า AWS public services ไม่ใช่ resource ใน VPC
• D ผิด: VPN เป็นทางเลือก connectivity แต่โจทย์ระบุ DX

ข้อ 10 — ต้องการ shift traffic แบบค่อยเป็นค่อยไป 10% ไป stack ใหม่เพื่อทำ canary ที่ระดับ DNS ควรใช้ routing policy ใด?

A. Failover B. Geolocation C. Weighted D. Multivalue answer

เฉลย

C — weighted routing กำหนดสัดส่วนน้ำหนัก (เช่น 90/10) เหมาะกับ canary/A-B testing

• A ผิด: failover เป็น active-passive ตาม health ไม่ใช่สัดส่วน
• B ผิด: geolocation ตามตำแหน่งผู้ใช้ ไม่ใช่สัดส่วน canary
• D ผิด: multivalue คืนหลาย IP แบบสุ่มเพื่อ HA ไม่ควบคุมสัดส่วน canary

---

7. Cross-references

• บทที่ 01 — keyword mapping (least operational overhead → managed/TGW/NAT Gateway, most cost-effective → gateway endpoint/VPN backup, static IP/non-HTTP → Global Accelerator); distractor “VPC peering transitive” เป็นตัวเลือกที่เป็นไปไม่ได้ทางเทคนิค
• บทที่ 02 — Networking account ใน Infrastructure OU เป็นเจ้าของ TGW/DX/shared VPC; blast radius isolation ที่ทำให้ over-consolidation VPC เดียวเป็นคำตอบผิด; segmentation ผ่าน TGW route table เสริม SCP
• บทที่ 03 — การแชร์ Transit Gateway/subnet ข้าม account ผ่าน AWS RAM (VPC Sharing); networking layer สำหรับ AD hybrid (DX/VPN, security group, DNS) ต่อยอดจาก Directory Service; PrivateLink เป็น network complement ของ cross-account access
• บทที่ 05 — load balancer เต็มรูปแบบ (ALB L7 / NLB L4 / GWLB appliance insertion), target group, Auto Scaling, ECS/EKS ที่อยู่หลัง endpoint เหล่านี้; instance profile/IMDSv2 บน EC2 ที่ออก internet ผ่าน NAT
• บทที่ 08 — multi-AZ vs multi-region เป็นรากฐานของ DR; Route 53 failover + Global Accelerator เป็น failover primitive ของ DR strategy (pilot light / warm standby / active-active)
• บทที่ 09 — AWS WAF และ Shield เชิงลึก (managed rules, DDoS response) ที่วางบน CloudFront/ALB; Network Firewall ในบริบท defense in depth; data perimeter (VPC endpoint policy + RCP)
• บทที่ 11 — CloudFront cache behavior/performance tuning, edge optimization; VPC Flow Logs + CloudWatch สำหรับ network observability; Reachability Analyzer/Network Access Analyzer
• บทที่ 12 — network cutover ตอน migration (DX/VPN สำหรับ hybrid migration), การย้าย workload ที่พึ่ง on-prem connectivity