AWS SAA-C03 Study

← D3 · High-Performing 🖥️ Compute 💾 Storage 🌐 Networking & Delivery 📨 Messaging & Serverless 🏗️ Infrastructure 🗄️ Databases 📊 Analytics & Streaming

🌐Networking & Delivery↑ Top

D3 · High-Performing

CloudFront

Amazon CloudFront

"CDN, content laju sampai — cache kat edge"

🎯 Sebab Apa Wujud

Wujud sebab kalau user di Jepun ambil gambar dari S3 bucket di Virginia, setiap request kena pergi balik separuh dunia → lambat + origin kena hentam beribu request sama. CloudFront letak salinan content (cache) di 600+ edge location dekat user → request dijawab dari edge terdekat (laju) dan origin kau bernafas (offload). Bonus: dia jadi pintu masuk selamat — boleh kunci content (signed URL/cookie, OAC), block ikut negara, dan jadi tempat WAF/Shield jaga.

Apa Dia

Menghantar content kepada pengguna melalui 600+ edge locations global dengan latency rendah. Cache content dekat dengan user, restrict access (signed URL/cookie, OAC, geo), dan offload origin.

Contoh Guna

Deliver images & videos untuk global users, static website laju, stream private paid media

Signed URL vs S3 Presigned URL

CloudFront Signed URL/Cookie → access private content MELALUI CloudFront (edge-cached, global low latency, boleh restrict by IP range + expiry, guna trusted key group). Untuk serve at scale via CDN.

S3 Presigned URL → direct access ke SATU S3 object, signed dengan IAM credentials orang yang generate (inherit permission dia), takde CDN caching. Untuk one-off upload/download terus ke S3.

Analogi Netflix — Signed URL vs Signed Cookie

Rendering diagram…

Analogi Netflix: pelanggan langgan Netflix nak tengok 10 episod dalam satu folder S3 — guna Signed Cookie: satu cookie bagi akses SEMUA fail tanpa perlu jana URL baru tiap episod. Kalau setakat satu fail (cth muat turun satu installer), Signed URL dah cukup. Dua-dua untuk private content VIA CloudFront; OAC pula untuk kunci bucket S3 supaya kekal private.

CloudFront Signed URL vs S3 Presigned URL

Aspect	CloudFront Signed URL/Cookie	S3 Presigned URL
Akses melalui	CloudFront (edge cache, global)	Direct ke S3 (tiada CDN)
Sign guna	Trusted key group (public/private key)	IAM creds orang yang generate
Permission	Independent dari IAM caller	Inherit permission si-pemberi
Skop	URL = 1 file; Cookie = banyak file	1 object sahaja
Extra control	🟢 Restrict by IP, expiry, geo, caching	Expiry sahaja
Best untuk	Serve private media AT SCALE via CDN	One-off upload/download terus ke S3

Ingat: Private content ramai user + low latency (paid video, downloads) → CloudFront signed URL/cookie. Bagi satu orang upload/download terus satu file → S3 presigned URL. Nak bucket kekal private tapi serve via CF → OAC + bucket policy (bukan signed URL).

⚡ Quick Sifir — hafal ni

▪CDN, cache di edge → laju untuk global user + offload origin
▪Private content VIA CloudFront → Signed URL (1 file) / Signed Cookie (banyak file)
▪Kunci S3 bucket supaya kekal private tapi serve via CF → OAC (ganti OAI; OAC support SSE-KMS)
▪CloudFront cert untuk HTTPS → MESTI di us-east-1
▪Block ikut negara → Geo Restriction. Jimat kos → Price Class (100 = paling murah)
▪Transform request di edge: ringkas/laju → CloudFront Functions; berat/panggil AWS → Lambda@Edge

💡 Exam Scenario

Serve private paid video globally dengan low latency → CloudFront signed URLs/cookies (cache kat edge + restrict access). BUKAN S3 presigned URL — presigned = direct S3, takde edge caching, takde IP restriction. Untuk serve private S3 objects → OAC + bucket policy (bucket kekal private).

🪤 Perangkap Soalan

Q: Aplikasi nak bagi pelanggan berbayar download SATU installer file secara selamat, expire selepas 1 jam, dan content perlu disampaikan laju ke user global. Pilih apa?

⚠ Umpan: S3 Presigned URL — sebab ia memang untuk bagi akses sementara ke satu S3 object dengan expiry. Nampak betul sebab "satu file + expiry".

✓ Betul: CloudFront Signed URL. Presigned URL pergi DIRECT ke S3 (tiada edge cache, tiada penyampaian global laju, tiada restrict IP). Keyword "laju ke global user / at scale via CDN + private" → CloudFront Signed URL. (Presigned URL betul cuma untuk one-off direct-to-S3 upload/download.)

Q: Nak serve objek S3 PRIVATE melalui CloudFront, dan bucket guna SSE-KMS encryption. Bucket mesti kekal block-public-access. Setup mana?

⚠ Umpan: Guna OAI (Origin Access Identity) + bucket policy bagi akses ke OAI. Nampak betul sebab OAI memang cara klasik kunci bucket untuk CloudFront.

✓ Betul: OAC (Origin Access Control) + bucket policy ke CloudFront service principal. OAI TAK support SSE-KMS — kena OAC. Keyword "S3 origin + SSE-KMS / private bucket via CloudFront" → OAC, bukan OAI.

🧠 Cara Mudah Ingat

→OAC (Origin Access Control) = GANTI OAI. Wajib guna OAC untuk S3 origins yang guna SSE-KMS. OAI tidak support KMS. Update bucket policy grant s3:GetObject kepada CloudFront service principal.
→"Serve private S3 objects via CloudFront securely" → OAC + bucket policy. Keep bucket block public access = ON.
→Signed URL vs signed cookie (dua-dua CloudFront private content): Signed URL = restrict access ke SATU file individual, atau client yang tak support cookies. Signed cookie = restrict access ke BANYAK files (e.g. semua HLS video segments) tanpa tukar URL.
→CloudFront signed URL vs S3 presigned URL: signed URL serve content via CDN (edge cache, IP restriction, trusted key group); S3 presigned = direct S3 object access guna creator IAM creds. Private content at scale → CloudFront. One-off direct S3 → presigned.
→Caching / TTL: Minimum / Default / Maximum TTL kawal berapa lama object cached at edge. Origin Cache-Control / Expires headers set freshness; TTL boleh override. Invalidation = force-remove cached object sebelum expiry (berbayar lepas free tier).
→Geo restriction (geo blocking): allowlist / denylist at COUNTRY level — block/allow user ikut negara. Native CloudFront feature (akurasi ~99.8%). Untuk granularity lebih halus (state/city) → guna third-party geolocation service.
→Price Classes (cost lever): PriceClass_All (semua edge locations, perf terbaik, mahal), PriceClass_200 (exclude region paling mahal), PriceClass_100 (US/Canada/Europe sahaja, paling murah).
→Lambda@Edge = run Lambda functions AT CloudFront edge nodes. 4 hooks: Viewer Request, Viewer Response, Origin Request, Origin Response. "Custom auth headers / transform request before origin" → Lambda@Edge
→Lambda@Edge vs CloudFront Functions: CF Functions = ultra-fast, lightweight JS at viewer level. Lambda@Edge = full Node.js/Python, longer timeout, can call AWS services, runs at origin/viewer events.

Guna Bila

Deliver content laju via edge locations + serve private content securely

CDNedge locationlow latencystatic contentOACOrigin Access ControlLambda@EdgeCloudFront FunctionsSSE-KMSprivate S3signed URLsigned cookieS3 presigned URLTTLcachinginvalidationgeo restrictiongeo blockingprice class

📎 Serve private content (signed URLs/cookies)📎 Geographic restrictions

D3 · High-Performing

ALB

Application Load Balancer

"Traffic director — by path/host, Layer 7"

🎯 Sebab Apa Wujud

Wujud sebab kalau kau ada banyak server web/microservice, kau tak nak user kena tahu IP setiap server, dan kau nak elak satu server mati = website down. ALB jadi "satu pintu masuk" yang sebarkan request ke server yang sihat. Lebih dari NLB: ALB faham HTTP, jadi dia boleh baca path/host/header dan hantar /cart ke service A, /video ke service B — satu LB untuk banyak microservice. Tujuan: HA + scaling + routing pintar di Layer 7.

Apa Dia

Bayangkan ALB macam kaunter pertanyaan / resepsionis hospital untuk website kau: SATU pintu masuk yang baca setiap request HTTP/HTTPS (Layer 7) — tengok URL path, hostname, header, cookie — pastu hantar ke kumpulan server (target group) yang betul, dan server yang SIHAT je. Persis macam kau setup routing dengan React Router / Next.js (`/dashboard` → komponen dashboard), tapi ALB buat di peringkat infrastructure: `/api` → service A, `/images` → service B. Boleh route ke instances dalam peered VPCs guna IP target — bukan satu VPC je.

Contoh Guna

myshop.com/products → service A, myshop.com/cart → service B. Cross-VPC: route ke EC2 instances dalam peered VPCs guna IP targets.

Anatomy ALB — 3 komponen wajib ingat (+ targets & health check)

Listener → "telinga" ALB yang dengar request pada port + protocol tertentu (cth HTTP:80, HTTPS:443). Sini kau pasang ACM cert untuk SSL/TLS termination.

Rules → undang-undang saringan pada listener: "kalau path = /api/* → hantar ke Target Group Backend". Dinilai ikut priority; ada default rule sebagai fallback. Condition boleh path, host, header, query string, source IP.

Target Group → bakul server yang buat satu tugas. Health check jalan ke SETIAP target dalam bakul ni. Satu rule tunjuk ke satu target group.

Targets → benda sebenar dalam target group. 3 jenis: instance (EC2 by ID), ip (IP — peered VPC / on-prem), lambda (function). ASG daftar/buang EC2 sini automatik.

Health Check → ALB ketuk pintu setiap target ikut tempoh (interval). Lulus healthy threshold → terima trafik; gagal unhealthy threshold → ALB berhenti hantar trafik ke target tu, alih ke yang sihat.

ALB request flow (Listener → Rules → Target Groups)

Client

browser HTTPS

Listener :443

ACM cert · TLS termination

Rule /api/*

→ TG Backend

Rule /static/*

→ TG Frontend

TG + health check

EC2 / IP / Lambda

ASG (On-Demand + Spot)

auto register/drain

Trafik internet TAK terus serang EC2 — masuk Listener (TLS termination guna ACM cert), Rules saring ikut path/host, hantar ke Target Group betul. Health check buang target rosak; ASG daftar/drain target automatik (penting bila Spot kena rampas). INGAT exam: Listener → Rules → Target Group → Targets.

Keluarga ELB — ELB = payung, ALB/NLB/GWLB/CLB = anak-anaknya

Rendering diagram…

ELB BUKAN produk berasingan — ia nama payung untuk 4 jenis load balancer. ALB cuma SATU jenis ELB. Jadi "ALB vs ELB" tak masuk akal (macam banding "sedan vs kenderaan"); yang betul nak banding ialah ALB vs NLB. INGAT exam: pilihan tulis "ELB" = konsep am; jawapan betul biasanya paksa pilih jenis spesifik — "route by path/host" → ALB, "static IP + TCP + extreme perf" → NLB.

Pilih load balancer (ALB vs NLB vs GWLB vs CLB)

Rendering diagram…

HTTP + routing pintar (path/host) → ALB. TCP/UDP + static IP + latency rendah → NLB. Salur ke security appliance (firewall/IDS/IPS) → GWLB. CLB = legacy, elak. INGAT exam: "web application + route by path/URL/host" → ALB; "extreme performance + millions of requests + static IP + TCP" → NLB.

Analogi: Kaunter Hospital + Food Court (Spot draining)

Rendering diagram…

ALB = kaunter pertanyaan hospital: baca surat rujukan (URL path) → hantar ke blok betul (target group). Klinik runtuh (health check gagal) → kaunter pusing pesakit ke klinik sihat. Gerai food court (Spot) tutup mengejut → ALB jadi pengawal yang tutup pintu masuk baru tapi biar pelanggan dalam habis dulu (deregistration delay) → no error 502. INGAT exam: health check = buang target rosak; deregistration delay = habiskan request lama masa Spot/scale-in.

ELB types — pilih load balancer ikut layer & keperluan

Aspect	ALB	NLB	GWLB
OSI Layer	7 — HTTP/HTTPS	4 — TCP/UDP/TLS	3 — IP packets
Routing	Path / host / header / query	Connection (ultra-low latency)	Forward ke virtual appliance
Static IP	❌ DNS name je	🟢 Elastic IP per AZ	Via GWLB endpoint
Preserve client IP	❌ guna X-Forwarded-For	🟢 Ya	🟢 Ya (transparent)
Best untuk	Web, microservices, containers	Gaming/IoT/VoIP, extreme perf, static IP	Firewall / IDS / IPS (GENEVE 6081)

Ingat: HTTP + routing pintar (path/host) → ALB. TCP/UDP, latency rendah, perlu static IP → NLB. Nak salurkan traffic melalui virtual appliance (firewall/IDS/IPS) → GWLB. CLB = legacy (L4/L7, instance-ID + same-VPC sahaja) — elak untuk design baru.

⚡ Quick Sifir — hafal ni

▪ELB (Elastic Load Balancing) = NAMA KELUARGA, BUKAN 1 produk. 4 jenis: ALB (L7), NLB (L4), GWLB (L3), CLB (legacy). ALB = SATU jenis ELB. "behind ELB" = am; "behind ALB" = spesifik
▪ALB = Layer 7 (HTTP/HTTPS), routing by path/host/header. NLB = Layer 4 (TCP/UDP)
▪Anatomy: Listener (port) → Rules (saringan) → Target Group (bakul server) → Targets (EC2/IP/Lambda)
▪ALB takde static IP (DNS name je). Perlu static IP → NLB
▪SSL/TLS termination kat ALB: pasang ACM cert kat listener; ALB→EC2 boleh HTTP biasa (jimat CPU server)
▪Health check = ALB auto-buang target rosak dari rotation. Ini asas HA, bukan Spot
▪Deregistration delay (Connection Draining) = DEFAULT 300s; range 0–3600s. Habiskan request lama sebelum target mati → elak error 500/502
▪Spot + ASG Mixed Instances + ALB = resipi cost-optimized + HA. Spot kena rampas → ASG deregister → ALB drain → no error
▪Banyak domain satu ALB, cert berasingan → SNI (multi-cert pada satu listener)
▪ALB cross-zone = SENTIASA ON & free. NLB cross-zone = OFF default (enable = caj inter-AZ)
▪Stateful app perlu session sama → enable ALB stickiness (cookie AWSALB)
▪ALB & NLB boleh IP targets (cross-VPC / on-prem). CLB = instance-ID + same-VPC je (legacy)

💡 Exam Scenario

Cross-VPC load balancing: company ada 3 VPCs peered. Guna satu ALB dengan IP address targets untuk route ke instances dalam semua 3 VPCs. Classic Load Balancer (CLB) tak boleh buat ni — CLB hanya support instance ID targets dalam same VPC. "Web app cost-optimized + fault-tolerant walau Spot ditutup" → ALB + ASG Mixed Instances Policy (On-Demand baseline + Spot) + deregistration delay. "Cuma route ikut path/host" → ALB Listener Rules.

🪤 Perangkap Soalan

Q: Aplikasi perlu host DUA domain berbeza (shop.com & blog.com) di belakang SATU load balancer, setiap satu dengan ACM cert sendiri, tanpa gabungkan jadi satu cert. Macam mana?

⚠ Umpan: Buat DUA ALB berasingan, satu per domain dengan certnya. Atau guna satu SAN/wildcard cert yang cover dua-dua domain. Nampak betul sebab "satu cert satu listener".

✓ Betul: Satu ALB, tambah kedua-dua ACM cert pada HTTPS listener guna SNI (Server Name Indication). Client hantar hostname dalam TLS handshake → ALB pilih cert betul. Tak perlu ALB berasingan atau combined cert. Keyword "multiple domains/certs on one ALB" → SNI.

Q: Beban kerja TCP gaming latency-sensitif perlu satu STATIC IP untuk whitelisting firewall pelanggan. Load balancer mana?

⚠ Umpan: ALB — sebab ia load balancer paling popular & feature-rich. Nampak betul sebab ALB selalu jadi default.

✓ Betul: NLB. ALB tiada static IP (DNS name sahaja) dan ia Layer 7 HTTP, bukan untuk raw TCP gaming. NLB = Layer 4, ultra-low latency, dan bagi Elastic/static IP per AZ. Keyword "static IP + TCP/UDP + extreme low latency" → NLB.

Q: Web app jalan atas ASG campuran On-Demand + Spot di belakang ALB untuk jimat kos. Bila Spot kena rampas, sesetengah user dapat error HTTP 500/502 masa tengah checkout. Macam mana hentikan error tu tanpa buang Spot?

⚠ Umpan: Tukar semua Spot ke On-Demand (atau scale up) supaya tiada instance kena rampas. Nampak betul sebab "error sebab Spot mati, jadi buang Spot".

✓ Betul: Aktif/naikkan Deregistration Delay (Connection Draining) pada target group + pastikan ASG guna ELB health check. Bila Spot dapat 2-min termination notice, ASG deregister instance → ALB tukar status ke draining, berhenti hantar trafik BARU, tapi biar request sedia ada habis dulu (default 300s) → no dropped connection. Buang Spot = bunuh penjimatan kos; betulkan draining je. Keyword "Spot interruption + 5xx error + keep cost low" → deregistration delay + ELB health check, BUKAN tukar ke On-Demand.

Q: Apa beza "EC2 behind ELB" dengan "EC2 behind ALB"? ELB lawan ALB tu dua produk berbeza ke?

⚠ Umpan: Anggap ELB dan ALB dua produk berasingan yang kau kena banding (ELB vs ALB). Nampak betul sebab nama lain-lain. SALAH: ELB BUKAN produk berasingan — ia nama keluarga.

✓ Betul: ALB ialah SATU JENIS ELB (bukan lawan ELB). ELB (Elastic Load Balancing) = nama payung untuk 4 jenis: ALB/NLB/GWLB/CLB. "EC2 behind ELB" = di belakang mana-mana jenis load balancer (am); "EC2 behind ALB" = spesifik Application Load Balancer (L7 routing). Yang patut dibanding ialah ALB vs NLB (dua jenis ELB), bukan ALB vs ELB. Analogi: ELB = "kenderaan", ALB = "sedan".

🧠 Cara Mudah Ingat

→ALB = Layer 7 (HTTP/HTTPS). NLB = Layer 4 (TCP/UDP). CLB = legacy, avoid
→Anatomy: Listener (dengar port/protocol) → Rules (saring ikut path/host/header/query/source-IP, by priority + 1 default) → Target Group (health check di sini) → Targets. Hafal aliran ni — soalan suka tanya "letak rule kat mana".
→Target types: instance (EC2 by ID), ip (peered VPC / on-prem via DX/VPN), lambda (ALB → Lambda terus, no API Gateway). Satu target group = satu jenis.
→SSL/TLS Termination: pasang ACM cert kat ALB HTTPS listener. User→ALB encrypted (HTTPS); ALB→EC2 boleh HTTP biasa dalam private subnet → jimat CPU server, tak payah urus cert dalam app. Nak end-to-end encryption → guna HTTPS sampai target juga.
→Health check: ALB ketuk path (cth /health) ikut interval; lulus HealthyThreshold kali → InService; gagal UnhealthyThreshold → buang dari rotation. Ini sumber HA asas — auto-elak server mati. ASG patut guna ELB health check (bukan EC2 je) supaya app-level failure pun dikira unhealthy.
→Deregistration Delay (= "Connection Draining" pada CLB): DEFAULT 300 saat, set 0–3600. Bila target di-deregister (scale-in / Spot rampas / deploy), ALB stop trafik BARU tapi biar request sedia ada habis (state: draining → unused). Kalau target putus connection sebelum delay habis → client dapat error 500-level. Turunkan delay = scale-in laju; naikkan = lindung request panjang (upload/checkout).
→ALB + Auto Scaling + Spot = combo cost-optimized klasik: ASG Mixed Instances Policy (On-Demand baseline + Spot untuk lebihan murah, jimat sampai 90%). ASG auto-register instance baru ke target group ALB & auto-drain bila Spot dapat 2-min termination notice. Capacity Rebalancing boleh launch ganti AWAL sebelum Spot betul-betul mati.
→Exam combo: "web app, paling murah, kekal HA walau Spot ditutup tiba-tiba" → ALB + ASG Mixed Instances (On-Demand + Spot) + deregistration delay. Jangan pilih "tukar semua ke On-Demand" — itu bunuh penjimatan.
→IP targets membolehkan ALB/NLB route ke peered VPCs, on-premises (via Direct Connect/VPN)
→CLB limitation: instance ID only, same VPC only — exam trap!
→SNI (Server Name Indication): ALB HTTPS listener boleh hold MULTIPLE TLS certificates serentak. Client sends hostname in TLS ClientHello → ALB picks the right cert. No extra ALB needed per domain!
→"two domains, same ALB, each with its own ACM cert, no combined cert" → Add both certs to ALB listener using SNI
→Stickiness (session affinity): ALB boleh bind user session ke specific target guna cookie. Duration 1s–7 days. Guna untuk: stateful app yang tak support distributed session. ALB generates cookie (AWSALB) atau app provides custom cookie. NLB juga support stickiness (TCP, 1s–7 days).
→Cross-Zone Load Balancing: ALB = ALWAYS ON (free, distributes traffic across all AZ targets). NLB = OFF by default (each AZ node only routes to targets dalam AZ yang sama; enable cross-zone = ada charge per-GB inter-AZ). CLB = OFF by default (enable at no charge).
→Exam: "ALB cross-zone" → always enabled, free. "NLB cross-zone" → disabled by default, enable = inter-AZ data transfer charge. "stickiness for stateful app" → enable ALB stickiness (cookie-based).
→PRICING (us-east-1): ALB = $0.0225/hour ($16.20/mo) + $0.008 per LCU-hour. NLB = $0.0225/hour + $0.006 per NLCU-hour. GWLB = $0.0135/hour + $0.0035 per GWLCU-hour. CLB = $0.025/hour + $0.008 per GB processed (legacy). LCU = Load Balancer Capacity Unit (new connections, active connections, bytes processed, rule evaluations).
→Exam: "ALB pricing" → hourly + per-LCU. "NLB cheaper per unit" → yes ($0.006 vs $0.008 per LCU). "CLB most expensive per GB" → $0.008/GB. GWLB paling murah per hour.

Guna Bila

HTTP/HTTPS path-based routing, microservices, containers

ELBElastic Load BalancingELB vs ALBEC2 behind ELBEC2 behind ALBload balancer typesALB vs NLBpath-based routinghost-based routingHTTPHTTPSlayer 7IP targetscross-VPCmicroservicesListenerListener RulesTarget Grouptarget typeshealth checkSSL terminationTLS terminationACM certificateSNIstickinesssession affinitycross-zone load balancingderegistration delayconnection drainingSpot interruptionAuto ScalingASGMixed Instances Policycapacity rebalancing502 Bad GatewayLambda targetX-Forwarded-Forpricing

📎 ALB IP Targets 📎 ALB User Guide

D3 · High-Performing

NLB

Network Load Balancer

"Traffic director — ultra laju, Layer 4, static IP"

🎯 Sebab Apa Wujud

Wujud sebab ada workload yang BUKAN HTTP (game server, VoIP, IoT, database protocol) dan perlukan kelajuan ekstrem + satu static IP yang firewall pelanggan boleh whitelist. ALB tak boleh — dia HTTP-only dan takde static IP. NLB beroperasi di Layer 4 (TCP/UDP), boleh handle berjuta connection per saat dengan latency super rendah, bagi Elastic IP tetap, dan preserve source IP client. Lagi satu sebab penting: kalau kau nak EXPOSE service kau secara private ke VPC/account orang lain guna AWS PrivateLink (VPC Endpoint Service), kau WAJIB letak NLB (atau GWLB) sebagai muka depan — ALB tak layak. Tujuan: load balancing untuk protocol bukan-HTTP, performance ekstrem, static IP, dan jadi pintu PrivateLink.

Apa Dia

Bayangkan NLB macam tukang pos kilat yang TAK buka surat: dia agih connection TCP/UDP pada Layer 4 (tak baca isi HTTP/URL langsung) dengan latency super rendah dan boleh telan jutaan connection sesaat. Lawan ALB yang "baca surat rujukan" (URL path/host), NLB cuma tengok IP + port lalu hantar paket mentah ke target group secepat kilat. Bonus: dia bagi static / Elastic IP tetap per AZ (ALB takde — DNS name je), jadi firewall pelanggan boleh whitelist IP tu. Dia juga satu-satunya LB (selain GWLB) yang boleh jadi "muka depan" untuk VPC Endpoint Service (PrivateLink).

Contoh Guna

Game server, VoIP, IoT/MQTT, database, high-frequency trading, WebSocket. Front untuk VPC Endpoint Service (PrivateLink) supaya service kau boleh dishare private ke VPC/account lain. Cross-VPC via IP targets.

Anatomy NLB — Listener (L4) → Target Group → Targets (+ static IP & idle timeout)

Listener → dengar pada protokol Layer 4: TCP, UDP, TCP_UDP, atau TLS (+ QUIC). TIADA "Rules path/host" macam ALB — NLB tak baca HTTP. TLS listener boleh terminate SSL guna ACM cert (offload decrypt dari target).

Target Group → bakul target; protokol TCP/UDP/TCP_UDP/TLS/QUIC. Health check PER target group, boleh guna TCP, HTTP, atau HTTPS (boleh ketuk path /health walaupun NLB sendiri L4).

Targets → 3 jenis: instance (EC2 by ID), ip (peered VPC / on-prem via DX/VPN), atau ALB (NLB boleh daftar ALB sebagai target → dapat static IP + L7 path routing serentak). ASG daftar/drain automatik.

Static IP → satu IP per AZ; boleh assign Elastic IP tetap. Ini yang ALB TAKDE.

Idle timeout → TCP flow default 350s, BOLEH ubah 60–6000s (listener attribute). TLS listener = 350s, TAK boleh ubah.

NLB sebagai front PrivateLink (VPC Endpoint Service)

Rendering diagram…

PrivateLink = cara expose service private ke VPC/account lain tanpa lalu internet. Provider WAJIB letak NLB (atau GWLB) sebagai muka depan endpoint service — ALB TAK layak jadi front. Consumer akses via interface endpoint (ENI dengan private IP). INGAT exam: "expose service privately / PrivateLink / endpoint service" → NLB front, BUKAN ALB.

NLB TLS listener — terminate vs passthrough

Rendering diagram…

NLB TLS listener = terminate SSL kat NLB (pasang ACM cert, offload decrypt dari target) — jimat CPU server. NLB TCP listener = passthrough, hantar TLS mentah sampai target untuk end-to-end encryption (target yang decrypt). INGAT exam: "offload SSL at LB for TCP app" → NLB TLS listener; "end-to-end encryption, target must decrypt" → NLB TCP passthrough.

NLB TLS listener — terminate vs TCP passthrough

Aspect	TLS listener (terminate)	TCP listener (passthrough)
SSL decrypt di mana	Kat NLB (ACM cert)	Kat target (server)
Cert duduk mana	NLB (ACM)	Target sendiri urus
Beban CPU decrypt	NLB tanggung (offload server)	Server tanggung
Encryption	Client→NLB encrypted; NLB→target plaintext	End-to-end (client→target)
Bila guna	Offload SSL, urus cert terpusat	Compliance / mesti end-to-end encrypted

Ingat: TLS listener = NLB terminate SSL (offload CPU server, cert kat ACM). TCP passthrough = target decrypt sendiri (end-to-end encryption). INGAT exam: "offload SSL at LB + TCP" → NLB TLS listener; "end-to-end / target must see encrypted" → TCP passthrough. Untuk ALB vs NLB vs GWLB, lihat card ALB.

⚡ Quick Sifir — hafal ni

▪NLB = Layer 4 (TCP/UDP/TLS/QUIC), ultra-low latency, jutaan conn/saat
▪NLB = static / Elastic IP per AZ. ALB = takde (DNS name je)
▪NLB preserve client/source IP terus (no header). ALB guna X-Forwarded-For
▪NLB cross-zone OFF by default (enable = caj data inter-AZ). ALB sentiasa ON & free
▪VPC Endpoint Service (PrivateLink) WAJIB depan NLB atau GWLB — BUKAN ALB
▪NLB idle timeout TCP = 350s default, boleh ubah 60–6000s. TLS listener = 350s fixed
▪NLB TLS listener boleh terminate SSL (ACM cert) — offload decrypt dari target
▪NLB boleh daftar ALB sebagai target → static IP + L7 path routing serentak
▪Bukan HTTP / static IP / extreme perf / PrivateLink → NLB. HTTP routing pintar → ALB

💡 Exam Scenario

"Preserve client source IP + TCP/UDP" → NLB (native, no XFF). "Static IP / Elastic IP untuk firewall whitelist" → NLB (ALB takde). "Expose service private ke VPC/account lain via PrivateLink / VPC Endpoint Service" → NLB (atau GWLB) sebagai front, BUKAN ALB. "Extreme performance / millions of req/s / lowest latency / gaming / IoT" → NLB. "Long-lived TCP connection putus masa idle" → naikkan NLB TCP idle timeout (60–6000s). Untuk ALB vs NLB vs GWLB family compare, lihat card ALB (anchor).

🪤 Perangkap Soalan

Q: Aplikasi backend perlu tahu alamat IP SEBENAR client untuk logging & rate-limiting, dan guna TCP. Load balancer & cara mana paling mudah?

⚠ Umpan: ALB dan baca header X-Forwarded-For untuk dapat client IP. Nampak betul sebab XFF memang cara biasa dapat client IP belakang LB.

✓ Betul: NLB — ia preserve source/client IP secara native (target nampak IP client sebenar terus), tanpa perlu parse header. Plus client guna TCP, jadi NLB (L4) lebih sesuai dari ALB (L7 HTTP). Keyword "preserve client IP + TCP" → NLB.

Q: Syarikat SaaS nak EXPOSE service mereka secara PRIVATE kepada VPC pelanggan lain (merentas account) guna AWS PrivateLink — pelanggan akses via interface endpoint tanpa lalu internet. Load balancer mana letak depan service tu?

⚠ Umpan: ALB — sebab service tu HTTP-based dan ALB paling biasa untuk web. Nampak betul sebab "service web → ALB".

✓ Betul: NLB. VPC Endpoint Service (PrivateLink) WAJIB guna NLB atau GWLB sebagai front — ALB TAK boleh jadi muka depan endpoint service. Kalau betul-betul perlu L7 routing, daftar ALB sebagai TARGET di belakang NLB. Keyword "PrivateLink / endpoint service / expose service privately to other VPCs" → NLB (bukan ALB).

Q: Aplikasi long-lived TCP (database / streaming) di belakang NLB putus connection lepas ~6 minit idle, padahal protokol ni patut kekal terbuka lama. Cara paling mudah betulkan tanpa tukar load balancer?

⚠ Umpan: Tukar ke ALB sebab "NLB idle timeout 350s fixed, tak boleh ubah". Nampak betul sebab dulu memang NLB TCP idle timeout terkunci.

✓ Betul: Naikkan TCP idle timeout pada NLB listener — sekarang BOLEH ubah 60–6000 saat (attribute tcp.idle_timeout.seconds), default 350s. Tak payah tukar LB. Nota: idle timeout untuk TLS listener pula KEKAL 350s (tak boleh ubah). Keyword "long-lived TCP connection dropped on NLB" → naikkan TCP idle timeout (TCP listener je).

🧠 Cara Mudah Ingat

→Anatomy: Listener (TCP/UDP/TCP_UDP/TLS/QUIC) → Target Group (health check di sini) → Targets. TIADA Rules path/host macam ALB — NLB L4 tak baca HTTP.
→Target types: instance (EC2 by ID), ip (peered VPC / on-prem via DX/VPN), atau ALB-as-target (NLB depan ALB = static IP + L7 routing serentak). Health check boleh TCP/HTTP/HTTPS walaupun NLB L4.
→NLB = static IP/Elastic IP per AZ. ALB = tiada static IP (kalau nak static IP untuk ALB, letak ALB belakang NLB, atau guna Global Accelerator).
→NLB dan ALB BOLEH route cross-VPC via IP targets. CLB TIDAK boleh.
→NLB preserve client/source IP secara native — target nampak IP client sebenar. ALB tidak (guna X-Forwarded-For header).
→PrivateLink: VPC Endpoint Service WAJIB depan NLB atau GWLB. ALB TAK boleh jadi front endpoint service — kalau perlu L7, daftar ALB sebagai target belakang NLB. "expose service private ke VPC/account lain" → NLB + endpoint service.
→Idle timeout: NLB TCP flow default 350s, BOLEH ubah 60–6000s (attribute tcp.idle_timeout.seconds pada listener). TLS listener = 350s, TAK boleh ubah. "long-lived TCP connection dropped" → naikkan TCP idle timeout. (ALB idle timeout default 60s, configurable 1–4000s.)
→TLS termination: NLB TLS listener boleh decrypt SSL guna ACM cert (offload dari target). TCP listener = passthrough (end-to-end, target decrypt sendiri).
→Cross-zone: NLB OFF by default — setiap node hantar ke target dalam AZ sendiri je; enable cross-zone = caj data inter-AZ ($0.01/GB). ALB cross-zone SENTIASA ON & free. "NLB cross-zone" → disabled default + ada caj inter-AZ.
→PRICING: NLB = $0.0225/jam + $0.006/NLCU-jam — per-unit LEBIH MURAH dari ALB ($0.008/LCU-jam). Cost discriminator: "cheapest LB per unit + TCP" → NLB. Untuk ALB vs NLB vs GWLB harga penuh, lihat card ALB.

Guna Bila

TCP/UDP, low latency, static IP, PrivateLink endpoint service, cross-VPC with IP targets

TCPUDPTCP_UDPTLSQUIClayer 4static IPElastic IPIP targetscross-VPClow latencymillions of requestspreserve source IPpreserve client IPPrivateLinkVPC Endpoint Serviceendpoint serviceNLB frontTLS terminationTLS passthroughidle timeouttcp.idle_timeout.secondslong-lived connectioncross-zone load balancingALB as targethealth checkgamingIoTVoIPpricing

📎 What is a Network Load Balancer?📎 NLB TCP idle timeout 📎 Create a PrivateLink endpoint service

D3 · High-Performing

GWLB

Gateway Load Balancer

"Pos pemeriksaan keselamatan — semua paket lalu firewall/IDS, Layer 3, GENEVE 6081"

🎯 Sebab Apa Wujud

Wujud sebab syarikat besar nak SEMUA trafik (egress ke internet, east-west antara VPC) diperiksa oleh firewall/IDS pihak ketiga SEBELUM sampai destinasi — tapi tak nak pasang appliance dalam SETIAP VPC satu-satu (mahal, susah urus, tak scale). Tanpa GWLB, kau kena hand-craft routing + bina HA appliance sendiri dalam tiap VPC. GWLB selesaikan dengan: letak fleet appliance SEKALI dalam satu security VPC, pastu semua VPC lain salur trafik melaluinya guna GWLBe. Dia transparent (bump-in-the-wire) — app tak perlu diubah, IP tak berubah. Dia load-balance + auto-scale + health-check fleet appliance tu automatik. Flow stickiness pastikan stateful firewall (yang kena nampak request DAN response) dapat kedua-dua arah pada appliance sama. Tujuan: inspection keselamatan terpusat, transparent, scalable untuk virtual appliance.

Apa Dia

Bayangkan GWLB macam pos pemeriksaan keselamatan / imigresen lapangan terbang yang SEMUA penumpang (setiap IP packet) WAJIB lalu sebelum masuk atau keluar — tapi penumpang tak perlu tukar tiket atau tahu pos tu wujud (transparent, "bump-in-the-wire"). Kerja dia DUA-DALAM-SATU: (1) gateway telus — satu pintu masuk/keluar untuk semua trafik, dan (2) load balancer — sebar trafik ke sekumpulan mesin pemeriksa (virtual appliance macam Palo Alto / Fortinet / Cisco firewall, IDS/IPS, deep packet inspection), buang yang rosak (health check), tambah mesin bila ramai (auto-scale). Dia beroperasi di Layer 3 (network) — dengar SEMUA IP packet pada SEMUA port, bukan HTTP (ALB) atau TCP/UDP connection (NLB). Trafik dibungkus guna protokol GENEVE port 6081 supaya paket ASAL sampai ke appliance tanpa diubah untuk diperiksa.

Contoh Guna

Centralized inspection: satu "security VPC" pegang fleet firewall, semua spoke VPC salur trafik egress/east-west melalui GWLB untuk diperiksa sebelum keluar internet. 3rd-party virtual firewall (Palo Alto VM-Series, Fortinet, Check Point) yang nak inspect setiap packet secara transparent.

Anatomy GWLB — Listener (semua IP packet) → Target Group (appliance) → GWLBe + GENEVE 6081 + flow stickiness

Listener → dengar SEMUA IP packet merentas SEMUA port (Layer 3). Tiada port/protocol spesifik macam ALB (HTTP:443) atau NLB (TCP:80) — GWLB telan semua. Satu listener, hantar ke satu target group.

Target Group → bakul virtual appliance (firewall / IDS / IPS / DPI). Target jenis instance (EC2 by ID) atau ip. Health check pastikan appliance hidup; appliance rosak dibuang dari rotation.

Targets → mesin pemeriksa sebenar (3rd-party security appliance). GWLB + appliance bertukar trafik guna GENEVE encapsulation port 6081 — paket asal dibalut, dihantar ke appliance untuk inspect, pastu dipulangkan.

Flow stickiness → GWLB hantar SEMUA paket satu "flow" (aliran) ke appliance SAMA supaya stateful firewall nampak kedua-dua arah. Default 5-tuple (src IP, dst IP, src port, dst port, protocol); boleh tukar 3-tuple atau 2-tuple.

GWLBe (Gateway Load Balancer Endpoint) → VPC endpoint khas (kuasa PrivateLink) yang sambung consumer VPC ↔ provider/security VPC secara private. Diletak sebagai NEXT HOP dalam route table subnet aplikasi. GWLBe & app server WAJIB dalam subnet berbeza.

GWLB inspection flow (consumer VPC → GWLBe → GWLB → appliance → balik)

App subnet

route 0.0.0.0/0 → GWLBe

GWLBe (next hop)

VPC endpoint · PrivateLink

GWLB (security VPC)

GENEVE 6081 · flow stickiness

Firewall appliance

inspect packet

IDS/IPS fleet

health-checked · auto-scale

Balik ke GWLBe → internet/dst

paket lulus inspection

Trafik subnet app dipaksa (route table next hop = GWLBe) lalu GWLBe → PrivateLink → GWLB dalam security VPC → fleet appliance periksa (GENEVE 6081, flow stickiness pastikan satu flow = satu appliance) → pulang ke GWLBe → teruskan ke destinasi. Transparent: app tak berubah. INGAT exam: GWLBe = next hop; GENEVE = 6081; appliance = target.

Centralized inspection — security VPC + spoke VPC via GWLBe

Rendering diagram…

Satu security VPC pegang fleet appliance; setiap spoke VPC salur trafik melaluinya guna GWLBe (next hop dalam route table). Tak perlu pasang firewall dalam tiap VPC. GWLB load-balance + auto-scale + health-check fleet tu. INGAT exam: "centralized 3rd-party firewall inspection untuk banyak VPC" → GWLB + GWLBe dalam security VPC.

Analogi: Pos imigresen lapangan terbang (transparent inspection)

Rendering diagram…

GWLB = pos imigresen yang SEMUA penumpang (packet) wajib lalu sebelum masuk/keluar — tapi transparent, penumpang tak perlu tukar tiket (bump-in-the-wire). Flow stickiness = penumpang sama balik ke kaunter sama (stateful firewall nampak dua hala). Kaunter tutup (health check gagal) → GWLB agih ke kaunter lain + tambah kaunter bila ramai (auto-scale). INGAT exam: transparent + semua trafik + 3rd-party appliance → GWLB.

Centralized inspection: GWLB vs appliance per-VPC vs NLB-fronted

Aspect	GWLB + GWLBe	Appliance inline per-VPC	NLB depan appliance
Layer / skop	L3 — SEMUA IP packet, semua port	Ikut appliance	L4 — TCP/UDP connection
Transparent (bump-in-wire)	🟢 Ya — app tak berubah	⚠️ Kena hand-craft routing	❌ Bukan inspection telus penuh
Centralized (banyak VPC)	🟢 1 security VPC, spoke via GWLBe	❌ Pasang dalam tiap VPC	⚠️ Per-service, bukan all-traffic
Encapsulation	GENEVE 6081 (paket asal utuh)	Tiada	Tiada
Stateful flow	🟢 Flow stickiness (5/3/2-tuple)	Bergantung setup	Per-connection
Auto-scale fleet appliance	🟢 GWLB urus	❌ DIY	⚠️ NLB sebar je

Ingat: Nak inspect SEMUA trafik (semua port, transparent) melalui 3rd-party firewall/IDS secara terpusat untuk banyak VPC → GWLB + GWLBe. Pasang appliance dalam tiap VPC = mahal + tak scale. NLB depan appliance = untuk expose service spesifik, bukan transparent all-traffic inspection. INGAT exam: GENEVE 6081 + transparent + virtual appliance = GWLB. Untuk ALB vs NLB vs GWLB family table, lihat card ALB.

⚡ Quick Sifir — hafal ni

▪GWLB = Layer 3 (IP packets), dengar SEMUA port. ALB = L7 HTTP, NLB = L4 TCP/UDP
▪GENEVE encapsulation port 6081 — nombor wajib hafal untuk GWLB
▪Target = virtual appliance (firewall / IDS / IPS / DPI), BUKAN web server biasa
▪Transparent "bump-in-the-wire" — app tak perasan, IP tak berubah
▪Flow stickiness: 5-tuple (default) / 3-tuple / 2-tuple → paket sama-flow pergi appliance sama (stateful firewall)
▪GWLBe (Gateway LB Endpoint) = pasangan wajib, kuasa PrivateLink, jadi NEXT HOP dalam route table
▪GWLBe & app server MESTI subnet berbeza (supaya GWLBe boleh jadi next hop subnet app)
▪GWLB & NLB = boleh jadi front VPC Endpoint Service / appliance via PrivateLink; ALB TAK boleh
▪Centralized inspection (1 security VPC, banyak spoke) → GWLB, bukan appliance per-VPC

💡 Exam Scenario

"Transparent inspection + 3rd-party firewall/IDS/IPS + semua trafik + centralized" → GWLB. "GENEVE 6081" → GWLB (nombor pengenalan). "Stateful appliance miss return traffic" → flow stickiness (tuple), bukan tambah kapasiti. "Route trafik subnet app lalu appliance" → GWLBe sebagai next hop route table. "Expose service private ke VPC lain (bukan appliance)" → NLB/GWLB front PrivateLink. Untuk ALB vs NLB vs GWLB family compare + harga penuh, lihat card ALB (anchor).

🪤 Perangkap Soalan

Q: Syarikat nak SEMUA trafik egress dari banyak VPC diperiksa oleh fleet 3rd-party firewall (Palo Alto) secara TRANSPARENT, terpusat, dan auto-scale — tanpa ubah aplikasi atau pasang firewall dalam tiap VPC. Service mana?

⚠ Umpan: NLB depan fleet firewall — sebab NLB pun boleh front appliance via PrivateLink dan handle TCP. Atau letak firewall EC2 inline dalam tiap VPC. Nampak betul sebab NLB selalu jadi front untuk appliance.

✓ Betul: Gateway Load Balancer (GWLB) + GWLB endpoint. GWLB direka KHAS untuk salur trafik ke virtual security appliance secara transparent di Layer 3 (semua IP packet, semua port) guna GENEVE 6081, dengan flow stickiness untuk stateful firewall. NLB cuma L4 connection + tak transparent untuk inspection inline penuh. Keyword "transparent inspection + 3rd-party firewall/IDS + centralized + all traffic" → GWLB.

Q: Stateful firewall di belakang GWLB nampak request masuk tapi MISS response balik (atau sebaliknya), jadi connection tracking pecah. Apa puncanya & betulkan macam mana?

⚠ Umpan: Tambah lebih banyak appliance dalam target group supaya ada kapasiti. Nampak betul sebab "firewall miss trafik = tak cukup kapasiti".

✓ Betul: Isu flow stickiness — paket arah berbeza pergi appliance BERBEZA, jadi stateful firewall tak nampak kedua-dua hala satu flow. Betulkan dengan pastikan flow stickiness sesuai (5-tuple default hantar semua paket flow sama ke appliance sama; guna 3-tuple/2-tuple kalau perlu kumpul lebih luas). Tambah appliance TAK selesai — malah boleh pecahkan lagi tanpa stickiness betul. Keyword "stateful appliance miss return traffic behind GWLB" → flow stickiness (tuple), bukan tambah kapasiti.

Q: Trafik dari subnet aplikasi nak dipaksa lalu GWLB dalam security VPC sebelum keluar internet. Macam mana arahkan trafik ke sana?

⚠ Umpan: Daftar appliance terus sebagai target dan biar GWLB tarik trafik automatik. Atau letak GWLBe dalam subnet SAMA dengan app server. Nampak betul sebab "target group automatik handle trafik".

✓ Betul: Letak GWLB Endpoint (GWLBe) sebagai NEXT HOP dalam route table subnet aplikasi — trafik 0.0.0.0/0 → GWLBe → (PrivateLink) → GWLB → appliance → balik. GWLBe & app server WAJIB dalam subnet BERBEZA supaya GWLBe boleh jadi next hop. Routing GWLB berasaskan route table, bukan auto-magnet. Keyword "route traffic through inspection appliances" → GWLBe sebagai next hop dalam route table.

🧠 Cara Mudah Ingat

→Anatomy: Listener (dengar SEMUA IP packet, semua port — L3) → Target Group (virtual appliance) → Targets (instance/ip). Tiada Rules path/host (ALB) atau port spesifik (NLB).
→GENEVE encapsulation port 6081 — hafal nombor ni. GWLB balut paket asal dalam GENEVE, hantar ke appliance untuk inspect tanpa ubah paket asal, pastu pulangkan.
→Flow stickiness: 5-tuple (default: src/dst IP + src/dst port + protocol), 3-tuple (src/dst IP + protocol), 2-tuple (src/dst IP). Pastikan semua paket satu flow → appliance SAMA (kritikal untuk stateful firewall yang kena nampak dua hala). "stateful appliance miss return traffic" → setel flow stickiness, bukan tambah node.
→GWLBe (Gateway Load Balancer Endpoint): VPC endpoint dikuasai PrivateLink. Diletak sebagai NEXT HOP dalam route table subnet app. GWLBe & app server WAJIB subnet berbeza. Trafik: app subnet → GWLBe → PrivateLink → GWLB (security VPC) → appliance → balik.
→Transparent "bump-in-the-wire": IP & app tak berubah; appliance nampak paket asal. Lawan proxy yang ubah paket. Inilah jualan utama GWLB.
→Target = 3rd-party VIRTUAL APPLIANCE (firewall, IDS/IPS, DPI — Palo Alto VM-Series, Fortinet, Check Point, dll), BUKAN web/app server biasa. Kalau soalan cakap "load balance web servers" → itu ALB/NLB, bukan GWLB.
→Centralized inspection architecture: satu security/inspection VPC pegang GWLB + fleet appliance; spoke VPC (atau egress via Transit Gateway) salur trafik melaluinya guna GWLBe. Elak pasang appliance dalam setiap VPC.
→GWLB & NLB sahaja boleh berperanan dengan PrivateLink untuk expose appliance/service; ALB TAK boleh. (Lihat card NLB untuk PrivateLink endpoint service.)
→PRICING (us-east-1): GWLB = $0.0135/jam (~$9.72/bulan) + $0.0035/GWLCU-jam — paling MURAH per jam antara ALB/NLB/GWLB. GWLCU diukur ikut new connections, active connections, & bytes processed. "cheapest LB per hour" → GWLB. Harga penuh ALB/NLB/GWLB ada di card ALB.

Guna Bila

Salur SEMUA trafik melalui fleet virtual appliance (firewall / IDS / IPS / DPI) secara terpusat & transparent

GWLBGateway Load Balancerlayer 3IP packetsGENEVEGENEVE 6081port 6081virtual appliancefirewallIDSIPSdeep packet inspectionDPItransparentbump-in-the-wireflow stickiness5-tuple3-tuple2-tupleGWLBeGateway Load Balancer EndpointPrivateLinkcentralized inspectionsecurity VPCinspection VPCnext hoproute tablePalo AltoFortinet3rd-party applianceegress inspectioneast-west trafficpricing

📎 What is a Gateway Load Balancer?📎 Access virtual appliances through AWS PrivateLink (GWLBe)📎 GWLB flow stickiness (target group attributes)

D3 · High-Performing

Route 53

Amazon Route 53

"GPS untuk domain"

🎯 Sebab Apa Wujud

Wujud sebab manusia ingat "myshop.com", bukan "54.x.x.x". DNS = buku telefon internet yang tukar nama → IP. Route 53 bukan sekadar buku telefon — dia GPS pintar: boleh hantar user ke region paling laju (latency), ke backup bila primary mati (failover via health check), atau ikut negara user (geolocation). Nama "53" dari port DNS (port 53). Tujuan: terjemah domain + arah traffic secara pintar berdasarkan kesihatan & lokasi.

Apa Dia

Mengurus DNS dan mengarahkan traffic kepada endpoint yang betul

Contoh Guna

Point domain ke server, failover ke backup region

Decision: Alias atau CNAME?

Rendering diagram…

Apex/root domain takde pilihan — MESTI Alias (CNAME dilarang oleh DNS spec kat apex). Subdomain ke AWS resource pun lebih elok guna Alias (percuma + ikut IP target automatik). INGAT exam: "root/apex → ALB/CloudFront/S3" → Alias record.

Alias vs CNAME

Aspect	Alias record	CNAME record
Apex/root (example.com)	🟢 Boleh	❌ TAK boleh (DNS spec larang)
Subdomain (www)	🟢 Boleh	🟢 Boleh
Point ke apa	AWS resource (ALB/CloudFront/S3/R53 record)	Mana-mana hostname
Query cost	🟢 FREE	Dikenakan caj (standard DNS query)
Record type	Type A/AAAA (alias flag)	Type CNAME
Auto-track target IP?	🟢 Ya — IP AWS resource berubah, alias ikut	Tidak (point ke nama je)

Ingat: Apex/root domain → MESTI Alias (CNAME haram kat apex). Subdomain → dua-dua boleh tapi Alias lebih baik (FREE + auto-track IP). INGAT exam: "point root/apex domain ke ALB/CloudFront/S3" → Alias, BUKAN CNAME.

⚡ Quick Sifir — hafal ni

▪APEX/root domain (example.com) → MESTI Alias record, CNAME TAK BOLEH
▪Subdomain (www) → CNAME atau Alias dua-dua boleh
▪Alias = AWS-only, FREE query, point ke ALB/CloudFront/S3/Route53 record
▪Route 53 = DNS + domain registration + health check + routing policy
▪"53" = port DNS. Routing pintar (latency/failover/geo) → guna routing policy

💡 Exam Scenario

"Point root/apex domain (example.com) ke ALB/CloudFront/S3" → Alias record (type A), BUKAN CNAME (DNS spec larang CNAME kat apex). "Subdomain (www) ke hostname luar AWS" → CNAME. "Smart routing (failover/latency/geo/weighted)" → lihat card Route 53 Routing Policies.

🪤 Perangkap Soalan

Q: Nak point root domain example.com terus ke sebuah ALB. Rekod DNS mana yang digunakan?

⚠ Umpan: CNAME record yang point ke DNS name ALB. Nampak betul sebab ALB bagi DNS name, dan CNAME memang untuk point nama ke nama.

✓ Betul: Alias record (type A) ke ALB. Spec DNS LARANG CNAME pada apex/root domain (example.com) — CNAME cuma boleh untuk subdomain (www). Alias = sambungan AWS yang benarkan apex point ke ALB/CloudFront/S3, dan query percuma. Keyword "root/apex domain → AWS resource" → Alias.

Q: E-commerce ALB perlu dilayan dari root (myshoppingweb.com) DAN subdomain (www.myshoppingweb.com). Konfig Route 53 mana? (A) CNAME untuk root + Alias untuk www, (B) CNAME untuk root + CNAME untuk www, (C) Alias untuk root + CNAME untuk www, (D) A record untuk root + AAAA record untuk www.

⚠ Umpan: D nampak "betul secara teknikal" sebab A/AAAA record memang record DNS sah — tapi A/AAAA point ke IP TETAP, sedangkan ALB takde static IP (IP dia berubah-ubah), jadi tak boleh hardcode. A & B pula letak CNAME kat ROOT/apex → DNS spec larang, salah terus.

✓ Betul: C — Alias untuk root + CNAME untuk www. Root/apex MESTI Alias (CNAME haram kat apex). Subdomain www boleh CNAME (atau Alias). Alias = point ke ALB tanpa perlu IP (auto-track IP ALB yang berubah) + query FREE. INGAT: apex → Alias; www → CNAME/Alias; JANGAN A-record-dengan-IP untuk ALB sebab ALB takde IP tetap.

🧠 Cara Mudah Ingat

→Alias record: AWS-specific DNS extension. Boleh guna untuk APEX/root domain (e.g. example.com). Points ke ALB, CloudFront, S3 website, other Route 53 records
→CNAME record: standard DNS. TIDAK BOLEH guna untuk apex/root domain (DNS spec prohibition)
→Pattern: apex domain (example.com) → ALWAYS use Alias. Subdomain (www.example.com) → CNAME or Alias both work
→Exam: "root domain + www subdomain pointing to ALB" → Alias for root + CNAME (or Alias) for www
→Hosted Zones: PUBLIC hosted zone = DNS record untuk domain internet awam (orang luar resolve). PRIVATE hosted zone = record HANYA dalam VPC kau (internal apps/database, split-horizon, orang luar tak nampak). Associate private hosted zone ke VPC → EC2 dalam VPC resolve nama dalaman. Satu domain = satu hosted zone. Exam: "internal DNS name dalam VPC / private domain untuk app dalaman" → private hosted zone.
→PRICING (us-east-1): Hosted zone ~$0.50/month per zone (first 25 zones). Standard queries ~$0.40 per million (first 1 billion). Health checks ~$0.50/health-check/month (first 50 free) + optional endpoint monitoring extra. Alias query ke AWS resource = FREE. Exam cost: "cheapest DNS query to ALB/CloudFront/S3" → Alias (free) bukan CNAME. Health check berlebihan = kos tersembunyi.

Guna Bila

DNS management, domain routing

DNSdomainrouting policyfailoverAlias recordCNAMEapex domainroot domaincannot CNAME apexhosted zonepublic hosted zoneprivate hosted zonepricing

📎 What is Amazon Route 53

D3 · High-Performing

Route 53 Routing Policies

Amazon Route 53 — Routing Policies

"Cara Route 53 decide siapa dapat traffic"

🎯 Sebab Apa Wujud

Wujud sebab "satu nama → satu IP" tak cukup bila kau ada server di banyak region. Kau nak DNS itu sendiri buat keputusan pintar: hantar user ke region paling LAJU (latency), tukar ke backup bila primary MATI (failover), bahagi traffic 70/30 untuk A/B test (weighted), atau patuh undang-undang dengan hantar user ikut NEGARA (geolocation). Routing policy = otak Route 53 yang decide siapa dapat jawapan DNS mana. Tujuan: optimize availability, performance & compliance di lapisan DNS.

Apa Dia

Pelbagai routing policies untuk optimize availability, performance, failover, dan geolocation berdasarkan health checks dan rules

Routing Policies

Simple → 1 resource, no health check, no failover

Weighted → split traffic by % (A=70%, B=30%)

Latency-based → route to lowest latency AWS region

Failover → primary (active) + secondary (passive) via health check

Geolocation → route by user's country/continent

Geoproximity → route by geographic distance + bias

Multi-Value → up to 8 healthy records, random selection

Decision tree: routing policy mana?

Rendering diagram…

Jangan keliru Latency vs Geolocation: Latency = paling LAJU (performance, region terbaik network); Geolocation = ikut NEGARA user (compliance/bahasa) walaupun bukan paling laju. INGAT exam: "fastest/lowest latency" → Latency-based; "by country/comply/serve language" → Geolocation; "active-passive DR" → Failover.

Scenario → Policy mana? (exam pakai keyword ni)

Keyword dalam soalan	Policy	Kenapa
"Satu resource, no rules"	Simple	Default, tiada health check
"A/B test", "split %", "blue-green by %", "gradual shift"	Weighted	Bahagi traffic ikut peratus
"Lowest latency", "fastest response", "nearest Region"	Latency-based	Route ke Region paling rendah latency (bukan paling dekat geo)
"Active-passive", "DR", "failover ke backup"	Failover	Primary + secondary, ikut health check
"Comply by country", "block/serve by location", "bahasa ikut negara"	Geolocation	Ikut lokasi USER (negara/benua)
"Shift traffic toward a Region", "bias"	Geoproximity	Ikut jarak + bias (besar/kecilkan Region)
"Client-side HA", "return multiple healthy IPs"	Multivalue Answer	Sampai 8 record sihat, random — bukan LB betul

Ingat: Latency-based ≠ Geolocation! Latency = laju (performance). Geolocation = lokasi user (compliance/bahasa). "Fastest" → Latency. "By country/comply" → Geolocation. Active-passive DR → Failover.

⚡ Quick Sifir — hafal ni

▪Latency-based = LAJU (performance). Geolocation = LOKASI user (compliance/bahasa) — JANGAN keliru
▪A/B test / split % / gradual shift → Weighted
▪Active-passive / DR / failover ke backup → Failover (+ health check)
▪Return banyak IP sihat untuk client pilih (bukan LB betul) → Multivalue Answer (max 8)
▪Geoproximity = jarak + bias (boleh "tarik" traffic ke satu region)
▪AWS alias target → Evaluate Target Health auto. On-prem/non-alias → kena attach health check sendiri

💡 Exam Scenario

ALB (primary) unhealthy → Route 53 Failover policy auto-redirect ke S3 static error page (secondary). Health check detect ALB down, traffic pindah ke secondary automatik. BUKAN CloudFront — CF cache content tapi tak handle active-passive failover.

🪤 Perangkap Soalan

Q: Syarikat global nak user disambung ke region AWS yang bagi response PALING PANTAS untuk mereka. Routing policy mana?

⚠ Umpan: Geolocation routing — hantar user ikut lokasi geografi mereka ke region terdekat. Nampak betul sebab "dekat = laju".

✓ Betul: Latency-based routing. Geolocation route ikut LOKASI user (untuk compliance/bahasa), bukan ikut kelajuan sebenar — region terdekat secara geografi tak semestinya latency terendah (network path berbeza). Keyword "fastest / lowest latency" → Latency-based. "by country / comply" → Geolocation.

🧠 Cara Mudah Ingat

→Hybrid failover (AWS primary + on-premises secondary): PERLU DUA alias records berasingan
→Record 1 (Primary): Alias ke ALB/CloudFront, Evaluate Target Health = Yes — Route 53 check health automatically
→Record 2 (Secondary): Alias ke on-premises IP/endpoint, associate Route 53 health check explicitly
→Evaluate Target Health (ETH): untuk AWS resources yang support alias (ALB, ELB, CloudFront) — Route 53 check health target automatically TANPA perlu attach health check
→On-premises / non-alias resources: MESTI attach health check explicitly — ETH tak apply
→Exam: "AWS primary + on-premises secondary failover" → 2 failover alias records, AWS dengan ETH=Yes, on-premises dengan explicit health check

Guna Bila

Control how DNS traffic is routed to resources

failoveractive-passivehealth checkweightedlatency-basedgeolocationsimpleEvaluate Target Healthhybrid failovertwo alias recordson-premises secondary

📎 Choosing a routing policy