AWS SAA-C03 Study

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

🖥️Compute↑ Top

D3 · High-Performing

EC2

Elastic Compute Cloud

"Virtual computer"

🎯 Sebab Apa Wujud

Dulu nak run aplikasi kena beli server fizikal, tunggu berminggu, setup data center sendiri — mahal & lambat. EC2 wujud bagi kau 'sewa' virtual server dalam minit, scale up/down ikut keperluan, bayar ikut guna, dengan full control atas OS. Pain yang ia buang: tak payah beli/jaga hardware fizikal untuk dapat compute dengan kawalan penuh.

Apa Dia

Menyediakan kapasiti compute yang boleh diubah saiz dalam cloud

Contoh Guna

Host web server, run database, legacy app migration

Placement Groups — macam mana EC2 disusun atas hardware fizikal

Aspect	Cluster	Partition	Spread
Susunan	Pack RAPAT dalam 1 AZ, segment network high-bandwidth sama	Bahagi kepada partition; tiap partition guna rack (kuasa + network) berasingan	Tiap instance atas hardware BERLAINAN (rack berbeza)
Tujuan	🟢 Latency rendah + throughput tinggi (sampai 10 Gbps single-flow)	🟢 Hadkan kesan kegagalan hardware ke satu partition sahaja	🟢 Kurangkan correlated failure — instance kritikal tak fail serentak
Best untuk	HPC, tightly-coupled (banyak traffic node-to-node)	Big data teragih: HDFS, HBase, Cassandra, Kafka	Segelintir instance kritikal (cth domain controller, node quorum)
Span AZ?	🔴 1 AZ sahaja	🟢 Multi-AZ (maks 7 partition / AZ)	🟢 Multi-AZ (maks 7 instance / AZ / group)
Tahan failure	Paling lemah — 1 rack/AZ jatuh, semua kena	Sederhana — failure terhad ke 1 partition	🟢 Paling tahan — hardware berasingan sepenuhnya

Ingat: Cara ingat 3C-P-S: Cluster = "Close" (rapat, low-latency HPC). Partition = "Pisah rack" (big data teragih — Hadoop/Cassandra/Kafka). Spread = "Separate hardware" (instance kritikal, maks 7/AZ). Placement group PERCUMA. Satu instance = satu placement group sahaja; tak boleh merge group.

⚡ Quick Sifir — hafal ni

▪Cluster PG = low-latency/HPC (1 AZ); Partition = big data teragih (Hadoop/Kafka); Spread = critical instances (maks 7/AZ)
▪On-Demand = no commit; Reserved/Savings Plan = commit 1-3yr (jimat ~72%); Spot = ~90% murah (boleh reclaim)
▪Spot interruption notice = 2 minit
▪Linux billing per-second (min 60s); Windows per-hour
▪Dedicated Host = bayar per-host (BYOL lesen); Dedicated Instance = +region fee tapi tak dapat host visibility

💡 Exam Scenario

"Full control atas OS / custom kernel / lift-and-shift legacy app" → EC2. "Lowest latency / HPC node-to-node" → Cluster placement group. "Fault-tolerant + cheapest + interruptible" → Spot. "Steady predictable 1-3yr" → Reserved/Savings Plans. "Per-second billing (Linux)" → EC2. "EC2 + RDS jalan office-hours/weekday je, jimat kos least ops" → AWS Instance Scheduler (start/stop ikut jadual), BUKAN Savings Plan/RI (commit) atau custom CloudWatch+Lambda (lebih ops). Kerja pendek event-driven & nak scale-to-zero → Lambda, BUKAN EC2.

🪤 Perangkap Soalan

Q: HPC workload perlu node-to-node latency paling rendah + throughput paling tinggi. Placement group mana?

⚠ Umpan: Spread placement group — 'spread' bunyi macam bagus untuk performance, tapi spread = sebar untuk availability, bukan low latency.

✓ Betul: Cluster placement group — keyword 'lowest latency / highest throughput / HPC / tightly-coupled' = Cluster (1 AZ).

Q: Batch job boleh interrupt, nak jimat kos maksimum, tak kisah kalau instance kena ambil balik. Pilih apa?

⚠ Umpan: Reserved Instance — jimat tapi kena commit 1-3 tahun; untuk workload sementara/interruptible ia bukan paling murah.

✓ Betul: Spot Instances — keyword 'fault-tolerant / interruptible / cheapest / flexible timing' = Spot (sampai 90% off, 2-min notice).

Q: EC2 + RDS PostgreSQL jalan waktu pejabat weekday SAHAJA. Nak optimize kos dengan operational overhead MINIMUM. Pilih apa?

⚠ Umpan: Compute Savings Plan / Reserved Instance untuk EC2 & RDS — nampak jimat, tapi commit 24/7 selama 1-3 tahun = kau bayar masa malam & weekend yang kau langsung tak guna. Bukan optimal untuk part-time.

✓ Betul: Deploy AWS Instance Scheduler (CloudFormation template) — auto start/stop EC2 + RDS ikut jadual office-hours. Custom CloudWatch alarm + Lambda boleh juga TAPI lebih ops (build & maintain sendiri). Instance Scheduler = ready-made, least overhead.

🧠 Cara Mudah Ingat

→Soalan sebut "lowest latency / highest throughput / HPC" → Cluster. Sebut "large distributed/replicated (Hadoop, Cassandra, Kafka)" → Partition. Sebut "critical instances mesti elak simultaneous failure" → Spread
→SCHEDULE / part-time — "EC2 + RDS jalan waktu kerja je (weekday office hours), nak jimat kos, least ops" → deploy AWS Instance Scheduler on AWS (AWS Solution, CloudFormation template) untuk auto start/stop EC2 & RDS ikut jadual. JANGAN pilih Savings Plan/Reserved (commit penuh 1-3thn = bazir untuk part-time) atau custom CloudWatch alarm + Lambda (boleh, tapi kena build & maintain sendiri = lebih ops overhead).
→Spread = maks 7 running instances per AZ per group; Partition = maks 7 partition per AZ — angka 7 ni selalu jadi distractor exam
→EC2 purchasing: On-Demand (bayar ikut guna, no commit) · Reserved/Savings Plans (commit 1–3 thn, jimat sampai ~72%) · Spot (sampai 90% murah, boleh kena reclaim) · Dedicated Host (hardware fizikal khas, untuk lesen BYOL)
→PRICING: (us-east-1, t3.medium approx) On-Demand ~$0.0416/hr. Reserved (3yr All Upfront) ~72% off. Savings Plans ~66% off. Spot up to 90% off. Dedicated Instance: +$2/hr region fee. Dedicated Host: billed per-host (~$3.20/hr for t3 host). Billing: Linux/Ubuntu per-second (min 60s), Windows per-hour. (Lihat card On-Demand / Reserved / Spot / Savings Plans dalam Domain 4 untuk perincian setiap model.)
→Exam: "Linux per-second billing, minimum 60 seconds" → EC2. "Windows billed per-hour" → EC2 Windows. "Dedicated Host billed per physical host" → not per-instance.

Guna Bila

Run any workload, full control

full controlcustom OSlift and shiftplacement groupscluster/partition/spreadpricingper-second billingper-hour WindowsOn-Demand costReserved discountDedicated Host billingInstance Schedulerstart stop scheduleoffice hourspart-time workloadscheduled start stopweekday only

📎 What is Amazon EC2 📎 EC2 placement groups

D3 · High-Performing

Lambda

AWS Lambda

"Jalankan code, bayar per run"

🎯 Sebab Apa Wujud

Untuk kerja kecil & event-driven (resize image bila upload, handle webhook), sewa EC2 24/7 = bayar walau idle + kena patch/scale server sendiri. Lambda wujud supaya kau hantar code je, AWS run bila ada event, scale auto, dan kau bayar HANYA bila code jalan (scale to zero bila takda trafik). Pain yang ia buang: tak payah provision/patch/scale server untuk kerja pendek bersifat event-driven.

Apa Dia

Bayangkan Lambda macam fungsi JavaScript/Python kau (cth `const proses = (data) => {...}`) tapi diletak atas cloud: kau campak KOD je, tak payah sewa/patch/scale server. Dia jenis TIDUR — bangun bila ada event (S3 upload, API call, webhook), jalankan kod kau beberapa saat, lepas tu mati balik. Bayar per milisaat masa kod jalan je. PENTING jangan keliru: Lambda = TUKANG MASAK (compute — tempat letak LOGIK/kod kau), BUKAN pelayan pintu yang agih trafik (itu kerja ELB/ALB — networking). Sebab tu dalam soalan "route trafik masuk ke EKS ikut URL path", Lambda SALAH — itu kerja router (ALB), bukan worker.

Contoh Guna

Resize image bila upload ke S3, webhook handler, scheduled tasks

Lambda — komponen & anatomy

Function → unit code + config (memory, timeout, runtime, env vars, role). Ini benda yang kau deploy

Handler → entry point: method yang Lambda panggil tiap kali invoke (cth handler(event, context))

Execution Environment → micro-VM (Firecracker) yang isolate + run code. Init sekali (= COLD START), lepas tu di-reuse (WARM)

Trigger / Event Source → benda yang cetus Lambda: S3 upload, API Gateway, EventBridge, SQS, DynamoDB Streams, dll

Event Source Mapping → untuk POLL-based source (SQS · Kinesis · DynamoDB Streams) — Lambda yang POLL & batch source, bukan source push. Resource ini kawal batch size + concurrency

Execution Role (IAM) → role Lambda assume masa run untuk akses AWS lain (S3, DynamoDB). Sama konsep macam EC2 instance role — JANGAN hardcode key

Layers → pakej .zip shared (library/dependency/custom runtime) yang dikongsi antara function. Max 5/function. NOTA: BUKAN cold-start fix

Destinations → hala hasil ASYNC invoke (onSuccess / onFailure) ke SQS · SNS · Lambda · EventBridge. Lebih kaya context dari DLQ lama

Concurrency → berapa invocation serentak. Reserved = cap kuota (percuma); Provisioned = pre-warm (bayar)

Versions & Aliases → Version = snapshot immutable code+config; Alias = pointer ke version (cth "prod" → v5). Weighted alias untuk canary deployment

Function URL → HTTPS endpoint terus ke function (tanpa API Gateway) untuk kes simple / response streaming

Lambda producer → SQS → Lambda consumer (throttling fix)

Rendering diagram…

Pattern exam klasik: app cuma perlu ACK bila request diterima, BUKAN bila siap proses. Producer campak ke SQS & return laju; consumer proses ikut kadar mampu → burst diratakan, kurang throttle (429). SNS SALAH di sini — push real-time, tak buffer, consumer masih kena hentam. INGAT: "throttling / decouple / acknowledge fast" → 2 Lambda + SQS.

Cara ingat — Lambda = Food Truck 🚚, EC2 = kedai 24 jam 🏪

Rendering diagram…

Analogi: Lambda = Food Truck (hidup bila ada order, tutup bila habis — kalau takda orang, kos = RM0). EC2 = kedai makan 24 jam (kena bayar sewa + gaji walaupun pukul 3 pagi takda pelanggan). INGAT exam: "pay only when running / scale to zero / event-driven" → Lambda. "lebih 15 minit" → Lambda GAGAL, guna Fargate atau AWS Batch.

Pilih cold-start fix — SnapStart vs Provisioned Concurrency

Rendering diagram…

INGAT exam: "Java + cold start + cost-effective" → SnapStart. "predictable spike + mesti zero cold start (any runtime)" → Provisioned Concurrency. Reserved Concurrency BUKAN cold-start fix — ia cuma cap/jamin kuota.

Reserved vs Provisioned Concurrency — selalu tertukar

Aspect	Reserved Concurrency	Provisioned Concurrency
Buat apa	Reserve & HADKAN bilangan concurrent execution untuk satu function	Pre-init (warm) sejumlah execution environment supaya siap sedia
Tujuan utama	Jamin kuota function kritikal + halang ia makan semua kuota account	Hapuskan COLD START — environment dah init, respond serta-merta
Cold start?	🔴 Masih ada cold start	🟢 Tiada cold start (dah pre-initialized)
Kos	🟢 Percuma — cuma agih semula kuota sedia ada	💰 Bayar untuk environment yang di-warm (caj per jam)
Guna bila	Elak runaway function / jamin kuota function penting	Latency-sensitive + trafik boleh dijangka (cth waktu puncak)

Ingat: Reserved = "RESERVE seat + cap" (jamin & hadkan kuota, masih cold start, percuma). Provisioned = "PRE-warm" (bayar untuk buang cold start). Default account = 1,000 concurrent execution per region (soft limit — boleh mohon naik ke puluhan ribu).

Cold-start fix: Provisioned Concurrency vs SnapStart (exam trap baru)

Aspect	Provisioned Concurrency	SnapStart
Cara kerja	Pre-warm N environment, sentiasa standby	Snapshot (Firecracker) env yang DAH init masa publish version → resume dari snapshot
Runtime	🟢 Semua runtime	🔴 Java 11+ · Python 3.12+ · .NET 8+ SAHAJA (no Node.js/Ruby/OS-only/container image)
Kos	💰 Bayar per jam (config + execution) walau idle	🟢 Jauh lebih murah — caching snapshot + per-restore charge je, takde kos idle 24/7
Cold start	🟢 Tiada (double-digit ms)	🟢 Sub-second (kurangkan drastik, bukan 100% hapus)
Limitation	Boleh combine versions/alias	🔴 Tak boleh combine Provisioned Concurrency, EFS, /tmp >512MB; published version je (bukan $LATEST); hati-hati state unik

Ingat: Java/Python/.NET + cold start + "MOST cost-effective" → SnapStart (murah). "strict / mesti zero cold start, ANY runtime, predictable spike" → Provisioned Concurrency (bayar per jam). Node.js/Ruby/container → SnapStart TAK boleh, terpaksa Provisioned Concurrency. Reserved Concurrency BUKAN cold-start fix.

Invocation models — sync vs async vs poll-based

Model	Contoh source	Retry / error handling
Synchronous (push)	API Gateway · ALB · Function URL · invoke terus	Caller TUNGGU jawapan; retry = tanggungjawab caller
Asynchronous (push)	S3 · SNS · EventBridge	Lambda queue event, retry 2× auto, gagal → DLQ / Destinations
Poll-based (Event Source Mapping)	SQS · Kinesis · DynamoDB Streams	Lambda POLL & batch; SQS buffer burst → kawal concurrency, elak throttle

Ingat: Sebut "S3/SNS/EventBridge cetus Lambda" = ASYNC (ada retry + DLQ/Destinations). Sebut "SQS/Kinesis/DynamoDB Streams" = POLL-based via Event Source Mapping (Lambda TARIK, bukan ditolak). Throttling masa burst → masukkan SQS depan Lambda untuk buffer.

⚡ Quick Sifir — hafal ni

▪Lambda = serverless event-driven; bayar bila run je (scale to zero)
▪Maks 15 minit (900s) per invocation; lebih lama → Fargate / AWS Batch / Step Functions
▪Memory 128MB–10,240MB; CPU naik IKUT memory (1,769MB = 1 vCPU penuh)
▪Reserved Concurrency = cap/jamin kuota (PERCUMA, masih cold start); Provisioned Concurrency = buang cold start (BAYAR per jam)
▪SnapStart = snapshot env yang dah init → resume sub-second; Java 11+/Python 3.12+/.NET 8+ SAHAJA (no Node/Ruby/container), murah
▪Default 1,000 concurrent execution/region (soft); /tmp 512MB default sampai 10GB
▪Throttle (429) masa burst? Letak SQS depan Lambda → buffer burst, smooth → no throttle (SNS tak buffer)

💡 Exam Scenario

Sebut "predictable spike, mesti respond cepat TANPA cold start" → Provisioned Concurrency. Sebut "Java/Python/.NET cold start + paling jimat kos (most cost-effective)" → SnapStart (BUKAN Provisioned Concurrency yang bayar per jam). Sebut "Node.js/Ruby/container nak zero cold start" → Provisioned Concurrency (SnapStart tak support runtime tu). Sebut "Lambda throttling masa burst / decouple / buffer / smooth load" → letak SQS depan Lambda (SQS buffer; SNS tidak). Sebut "satu function jangan habiskan semua kuota / jamin kuota function kritikal" → Reserved Concurrency. Sebut "job ambil masa lebih 15 minit" → Lambda TAK sesuai (guna Fargate/Batch/Step Functions). STORAGE: "persistent / shared storage across invocations" atau "data > 10 GB / ML model besar" → mount Amazon EFS (function dalam VPC). "scratch sementara dalam satu run" → /tmp (512 MB–10 GB).

🪤 Perangkap Soalan

Q: App Java event-driven kerap kena cold start & outlier latency. Nak kurangkan dengan kos PALING rendah (most cost-effective). Pilih apa?

⚠ Umpan: Provisioned Concurrency — ia memang hapus cold start, TAPI bayar per jam walau idle = mahal, jadi bukan 'most cost-effective'.

✓ Betul: Lambda SnapStart — Java/Python/.NET + cold start + cost-effective = SnapStart (snapshot env yang dah init, murah). Provisioned Concurrency baru relevan kalau runtime Node/Ruby/container ATAU perlu strict zero cold start.

Q: API Gateway → Lambda terima JSON, simpan ke Aurora. Banyak throttling error masa burst, terpaksa naikkan concurrent execution berkali-kali. Macam mana scale elok?

⚠ Umpan: Pecah jadi 2 function + SNS antara keduanya — SNS push TERUS, tak buffer, jadi burst masih banjir function kedua = masih throttle.

✓ Betul: Pecah jadi 2 function + SQS di tengah — SQS BUFFER burst, Lambda poll ikut kadar yang dia mampu → smooth, no throttle. Keyword 'throttling / decouple / buffer burst' = SQS, BUKAN SNS.

Q: API latency-sensitive ada spike trafik boleh dijangka pagi setiap hari, mesti respond tanpa cold start (runtime Node.js). Pilih apa?

⚠ Umpan: Reserved Concurrency — bunyi macam 'reserve capacity siap sedia', tapi Reserved cuma HADKAN/jamin kuota, MASIH ada cold start. (SnapStart pula tak support Node.js.)

✓ Betul: Provisioned Concurrency — keyword 'no cold start / pre-warmed / predictable spike' + runtime bukan Java/Python/.NET = Provisioned Concurrency.

Q: Job pemprosesan ambil masa 30 minit setiap run. Lambda sesuai ke?

⚠ Umpan: Ya, tambah memory & Provisioned Concurrency — orang ingat naik resource boleh extend masa, tapi hard limit 15 min tetap kekal.

✓ Betul: TIDAK — Lambda hard cap 15 minit. Keyword '>15 min / long-running' → Fargate, AWS Batch, atau Step Functions.

🧠 Cara Mudah Ingat

→Had penting: maks 15 minit (900s) per invocation. Job lebih lama → guna ECS/Fargate, AWS Batch, atau Step Functions
→Memory 128 MB–10,240 MB (step 1 MB). CPU naik IKUT memory — 1,769 MB = 1 vCPU penuh. Nak laju? naik memory, CPU auto naik
→Concurrent executions default = 1,000/region (soft). Lebih → throttle (429 TooManyRequestsException)
→/tmp ephemeral storage: 512 MB default, boleh naik sampai 10,240 MB (10 GB). Ini EPHEMERAL — tak dikongsi antara invocation, hilang bila environment recycle.
→STORAGE persistent/shared: mount Amazon EFS untuk data yang KEKAL & dikongsi across invocations/functions (cth ML model besar, shared state, data > 10 GB). SYARAT: function mesti dalam VPC (sama VPC dengan EFS mount target) + EFS access point + elasticfilesystem permission pada execution role. /tmp = scratch sementara; EFS = persistent shared.
→Deployment package: 50 MB (zip, direct upload) / 250 MB (unzipped + layers), atau container image sampai 10 GB
→Cold start = masa init environment + load code; teruk untuk runtime berat (Java) / package besar. Fix: SnapStart (Java/Python/.NET, murah) atau Provisioned Concurrency (any runtime, bayar). Layers TAK fix cold start.
→SnapStart: Lambda ambil Firecracker SNAPSHOT environment yang DAH init (masa publish version), encrypt & cache. Invoke → resume dari snapshot (bukan init dari kosong) → cold start sub-second. Support Java 11+, Python 3.12+, .NET 8+ SAHAJA. TAK support: Node.js, Ruby, OS-only runtime, container image. TAK boleh combine: Provisioned Concurrency, EFS, S3 files, /tmp >512MB. Mesti published version/alias (bukan $LATEST). Hati-hati state unik (cth random seed) sebab snapshot dikongsi.
→PRICING SnapStart: jauh lebih murah dari Provisioned Concurrency — caj = caching snapshot (per GB sambil cache) + restoration charge tiap kali resume (ikut memory). Takde kos "warm 24/7" macam Provisioned Concurrency. Exam "Java cold start + most cost-effective" → SnapStart.
→Throttling fix (decouple): kalau Lambda kena throttle masa burst (429 TooManyRequests), letak SQS antara source dan Lambda. SQS BUFFER mesej, Lambda poll & proses ikut kadar — burst diratakan. SNS TAK buffer (push terus) jadi tak selesaikan throttle. Exam: "reduce throttling / smooth burst / decouple" → SQS.
→Lambda Layers = pakej .zip berasingan untuk shared library/dependency/custom runtime — kongsi antara banyak function & kecikkan deployment package. Max 5 layer/function. NOTA: Layers BUKAN penyelesaian cold start (jangan tertipu soalan yang offer "Lambda layers" untuk minimize cold start).
→Invocation model: SYNCHRONOUS (API Gateway/ALB/Function URL — caller tunggu, retry caller punya hal) · ASYNCHRONOUS (S3/SNS/EventBridge — Lambda queue event, retry 2× auto, gagal → DLQ / Lambda Destinations) · POLL-based / Event Source Mapping (SQS/Kinesis/DynamoDB Streams — Lambda POLL & batch). Response streaming = hantar output berperingkat (Function URL) untuk TTFB cepat / payload besar; ini BUKAN cold-start fix.
→PRICING: Free tier — 1M requests/mo + 400,000 GB-seconds/mo (forever). Selepas free tier: $0.20 per 1M requests + $0.0000166667 per GB-second. GB-second = memory allocated × duration. Provisioned Concurrency = $0.0000041667 per vCPU-hour + $0.000000111 per GB-hour (config + execution).
→Exam: "1 million free requests per month forever" → Lambda free tier. "pay per request + duration" → Lambda pricing model. "Provisioned Concurrency has hourly cost" → yes, separate from execution.
→Environment variables: tukar CONFIGURATION (endpoint URL, flag toggle, feature switch) INSTANT tanpa ubah code Lambda — set di console, Lambda pakai nilai baru invocation seterusnya. Secure env var sensitif (API key/password) guna ENCRYPTION HELPERS (KMS) — Lambda auto-decrypt masa runtime. JANGAN pass config via request header (user boleh manipulate). Lambda Layers = shared library/dependency BUKAN config; Aliases = label version BUKAN config. Exam: "modify config instantly without code change + securely" → env vars + encryption helpers (KMS).
→Exam pairing: "Lambda + RDS too many connections" → RDS Proxy (pool connection). "Lambda react to DynamoDB changes" → DynamoDB Streams + Event Source Mapping.

Guna Bila

Serverless, event-driven

serverlessevent-driven15-min maxreserved concurrencyprovisioned concurrencycold startsnapstartLambda SnapStartFirecracker snapshotJava cold startevent source mappinginvocation modelasynchronous invocationsynchronous invocationpoll-basedLambda destinationsDLQdead letter queueLambda layersresponse streamingSQS decouplethrottling429execution environmentexecution role/tmp ephemeral storageEFS mountLambda EFSpersistent storageshared storagefunction URLenvironment variablesencryption helpersKMS env var

📎 Lambda SnapStart 📎 Provisioned & Reserved Concurrency 📎 Invocation & Event Source Mapping 📎 Lambda Layers

D3 · High-Performing

Elastic Beanstalk

AWS Elastic Beanstalk

"Hantar code je, AWS urus selebihnya"

🎯 Sebab Apa Wujud

Developer nak deploy app cepat tapi tak nak setup EC2 + ALB + Auto Scaling + health monitoring satu-satu secara manual. Elastic Beanstalk wujud sebagai PaaS: kau hantar code (.zip/.war), ia auto-bina & urus semua infra bawah, tapi kau MASIH boleh akses & tweak resource tu (beza dengan Lambda yang fully abstracted). Pain yang ia buang: deploy app tanpa jadi expert infra, tapi tak hilang kawalan.

Apa Dia

Mengurus deployment, scaling dan monitoring aplikasi secara automatik

Contoh Guna

Deploy Node.js / Python app tanpa urus EC2 sendiri

Elastic Beanstalk — komponen & anatomy

Application → bekas teratas (umbrella) untuk app kau — pegang banyak version + environment

Application Version → satu source bundle (.zip/.war) yang dilabel & disimpan dalam S3. Deploy = pilih version untuk satu environment

Environment → set resource AWS (EC2 + ALB + ASG + health monitoring) yang menjalankan SATU version. Satu app boleh ada banyak environment (dev/test/prod)

Environment Tier → Web Server tier (handle HTTP request, depan ALB) ATAU Worker tier (proses background job — baca SQS guna daemon sqsd, POST ke app)

Platform → runtime + OS yang Beanstalk uruskan (Node, Python, Java, .NET, Go, Ruby, Docker). Managed platform updates auto-patch

.ebextensions → fail config YAML/JSON untuk customize resource & option (env var, packages, instance type) tanpa keluar Beanstalk

Saved Configuration → snapshot setting yang boleh guna semula untuk launch environment serupa

Pilih deployment policy Beanstalk

Rendering diagram…

INGAT exam: downtime OK + murah = All-at-once · no downtime jimat = Rolling · full capacity = Rolling+batch · paling selamat satu env = Immutable · swap environment = Blue/Green (DNS change).

JANGAN KELIRU — semua "Elastic ___" & short form yang serupa

Short form	Nama penuh	Ia apa SEBENARNYA
Elastic Beanstalk	AWS Elastic Beanstalk	🚀 PaaS — hantar code, AWS auto-bina EC2 + ALB + ASG. Platform untuk DEPLOY app
EBS	Elastic Block Store	💾 Disk (block storage) yang attach ke EC2. STORAGE — bukan deploy!
EFS	Elastic File System	📁 Shared file storage (NFS) — banyak EC2 mount serentak
ELB	Elastic Load Balancing	⚖️ Service load balancer (payung untuk ALB/NLB/GWLB/CLB)
ALB / NLB / GWLB	Application / Network / Gateway LB	Jenis ELB: ALB = L7 HTTP, NLB = L4 TCP/UDP + static IP, GWLB = security appliance
EC2	Elastic Compute Cloud	🖥️ Virtual server (compute)
ECS / EKS / ECR	Container Service / Kubernetes / Registry	ECS = run Docker · EKS = run Kubernetes · ECR = simpan image Docker
ElastiCache	Amazon ElastiCache	⚡ In-memory cache (Redis/Memcached) — bukan storage kekal

Ingat: Trick: nama ada "Store/Storage/System/File" = SIMPAN data (EBS, EFS). "Beanstalk" = Bina & deploy APP. "Load Balancing/ALB/NLB" = edar trafik. "Compute/EC2" = server. Yang paling kerap tertukar: EBS (disk) vs Elastic Beanstalk (deploy) — keduanya start "EB" tapi langsung tak sama!

Deployment policies — paling kerap ditanya exam

Policy	Downtime?	Capacity masa deploy	Laju (1=cepat·4=lambat)	Rollback	Deploy ke
All at once	🔴 Ada (semua sekali gus)	Penuh → 0 sekejap	1 — paling laju + murah	Manual redeploy	Instance sedia ada
Rolling	🟢 Takda	⬇️ Turun (batch keluar service)	2 — sederhana	Manual redeploy	Instance sedia ada
Rolling + additional batch	🟢 Takda	✅ PENUH kekal (launch batch tambahan)	3 — lebih lambat	Manual redeploy	Instance baru + sedia ada
Immutable	🟢 Takda	✅ Penuh (ASG kedua penuh)	4 — paling lambat	✅ Senang: terminate instance baru	Instance baru sahaja
Traffic splitting (canary)	🟢 Takda	✅ Penuh + % trafik ke versi baru	4 — paling lambat	Reroute trafik + terminate baru	Instance baru sahaja
Blue/Green (swap URL)	🟢 Takda	✅ Environment berasingan	4 — paling lambat	✅ Swap CNAME balik	Environment baru (DNS change!)

Ingat: Exam discriminator: "paling laju/murah, boleh terima sikit downtime" = All-at-once. "no downtime, jimat, tak kisah capacity turun sikit" = Rolling. "maintain FULL capacity sepanjang deploy" = Rolling + additional batch. "paling selamat, rollback senang, instance baru je, satu env" = Immutable. "zero downtime + instant rollback + tukar environment" = Blue/Green (libatkan DNS/CNAME swap). "test versi baru dengan % trafik" = Traffic splitting (canary).

⚡ Quick Sifir — hafal ni

▪Beanstalk = PaaS; hantar code, ia auto-create EC2 + ALB + ASG + health monitoring
▪Beanstalk PERCUMA; bayar resource bawah (EC2, ALB) yang ia provision
▪Beanstalk = opinionated deploy APP; CloudFormation = IaC general semua resource
▪Beanstalk = app run atas server (kau nampak EC2); Lambda = no server, event-driven
▪JANGAN keliru: EBS = Elastic Block Store (disk) ≠ Elastic Beanstalk (deploy app)
▪Deploy: All-at-once = laju+murah TAPI downtime; Rolling = batch demi batch (capacity turun sekejap); Rolling+additional batch = capacity PENUH kekal; Immutable = ASG baru penuh, rollback paling selamat (terminate je)
▪Blue/Green = environment baru + SWAP URL (CNAME) → zero downtime + rollback senang (swap balik); SATU-SATUNYA yang libatkan DNS change
▪2 environment tier: Web Server (handle HTTP, depan ALB) vs Worker (proses background job, baca SQS guna daemon sqsd)

💡 Exam Scenario

Sebut "developer nak deploy web app cepat, ada CI/CD, tak nak urus infra TAPI masih nak kawalan ke atas EC2/scaling" → Elastic Beanstalk. "Fully serverless, no server langsung" → Lambda/Fargate. "Attach disk ke EC2" → itu EBS, bukan Beanstalk. "deploy tanpa downtime + maintain FULL capacity" → Rolling with additional batch. "zero downtime + instant rollback + swap environment URL" → Blue/Green. "process background job from queue" → Worker environment tier (sqsd).

🪤 Perangkap Soalan

Q: Developer nak deploy web app cepat, tak nak urus infra, TAPI masih nak boleh tweak EC2/scaling settings. Pilih apa?

⚠ Umpan: AWS Lambda — serverless senang, tapi Lambda fully abstracted (no server akses) + had 15 min, bukan untuk app web sentiasa run.

✓ Betul: Elastic Beanstalk — keyword 'deploy app fast + still control underlying EC2/scaling' = Beanstalk (PaaS).

Q: Soalan sebut 'EBS' untuk deploy aplikasi. Maksudnya Elastic Beanstalk?

⚠ Umpan: Ya, EBS = Elastic Beanstalk — singkatan menipu, kedua start 'EB'.

✓ Betul: TIDAK — EBS = Elastic Block Store (disk storage). Deploy app = Elastic Beanstalk (jarang disingkat EBS dalam exam).

Q: Nak deploy versi baru TANPA downtime DAN kekal kapasiti PENUH sepanjang masa, kos paling rendah. Pilih deployment policy mana?

⚠ Umpan: Immutable — bunyi paling selamat/zero downtime, TAPI ia paling lambat + buka ASG kedua PENUH (double instance sementara) = bukan 'kos paling rendah'.

✓ Betul: Rolling with additional batch — keyword 'no downtime + maintain FULL capacity + jimat' = launch SATU batch tambahan je (bukan ASG penuh), capacity penuh kekal. (Rolling biasa = capacity turun sekejap.)

Q: App Beanstalk perlu proses background/async job dari satu queue. Guna tier mana?

⚠ Umpan: Web Server tier + tulis kod poll SQS sendiri — boleh jalan tapi bukan cara Beanstalk; Web tier direka untuk handle HTTP request.

✓ Betul: Worker environment tier — Beanstalk auto-pasang daemon sqsd yang baca SQS & POST ke app kau. Keyword 'background/async job dari queue / decouple' = Worker tier.

🧠 Cara Mudah Ingat

→Beanstalk = PaaS: kau hantar code (.zip/.war), ia auto-create EC2 + ALB + Auto Scaling + health monitoring. Kau MASIH boleh akses & tweak resource bawah (beza dengan Lambda yang fully managed)
→PRICING: Elastic Beanstalk PERCUMA — kau bayar HANYA resource bawah yang ia provision (EC2, ALB ~$0.0225/hr + $0.008/LCU-hr, EBS volume, data transfer). Single-instance environment (no ALB) = lebih murah untuk dev/test
→Deployment policy: All at once = paling laju + murah TAPI ada downtime (semua instance sekali gus). Rolling = no downtime tapi capacity turun sekejap (batch demi batch). Rolling + additional batch = capacity PENUH kekal (launch 1 batch tambahan dulu). Immutable = paling selamat, ASG kedua penuh, rollback = terminate instance baru je
→Blue/Green = BUKAN deployment policy biasa — kau launch environment KEDUA (baru), test, lepas tu SWAP CNAME/URL. Zero downtime + rollback = swap balik. Satu-satunya cara yang libatkan DNS change. Exam: "zero downtime + instant rollback + tukar environment" = Blue/Green
→Environment tier: Web Server tier = handle HTTP (depan ALB). Worker tier = proses background/async job — Beanstalk pasang daemon sqsd yang baca mesej dari SQS & POST ke aplikasi. Exam keyword "background job / decouple / long-running task from queue" → Worker environment
→.ebextensions = folder config (YAML/JSON) untuk customize resource Beanstalk (env var, packages, instance type) tanpa keluar dari Beanstalk. Managed platform updates = auto-patch OS/runtime (boleh jadual maintenance window)
→Beanstalk vs CloudFormation: Beanstalk = deploy APP cepat (opinionated, behind-the-scenes Beanstalk SENDIRI guna CloudFormation); CloudFormation = IaC general untuk SEMUA jenis resource
→Beanstalk vs Lambda: Beanstalk = app sentiasa run atas server (kau nampak EC2); Lambda = event-driven, no server
→INGAT: EBS = disk storage. Elastic Beanstalk = deploy app. Exam suka uji kekeliruan ni!

Guna Bila

Deploy app tanpa urus server

PaaSdeploy appdeveloper friendlyauto EC2+ALB+ASGfree servicedeployment policyall at oncerollingrolling with additional batchimmutable deploymentblue greenblue/green CNAME swaptraffic splittingcanaryweb server tierworker tiersqsd.ebextensionsmanaged platform updateszero downtime deploymentpricing

📎 Deploying applications (deployment policies + methods table)📎 Deployment policies & settings (rolling/immutable detail)📎 Environment tiers — Web Server vs Worker

D3 · High-Performing

ECS

Elastic Container Service

"Docker manager AWS-native — Cluster → Service → Task ikut Task Definition"

🎯 Sebab Apa Wujud

Run Docker container atas EC2 sendiri = kena urus cluster, scheduling container mana pergi host mana, restart bila mati, register ke load balancer — semua manual. ECS wujud sebagai orchestrator Docker AWS-native: kau define Task Definition (resepi), ECS jaga Service supaya desired count tasks sentiasa running, restart bila fail, attach ke ALB + auto-scale. Pain yang ia buang: jalankan & jaga container berskala tanpa build orchestration sendiri (dan tak perlu belajar Kubernetes macam EKS).

Apa Dia

Mengurus dan menjalankan Docker containers pada cluster. Hierarki: Cluster (pool capacity) → Service (jaga desired count) → Task (satu running unit) yang dicetak dari Task Definition (blueprint JSON). Dua launch type: EC2 (kau urus instances) atau Fargate (serverless).

Contoh Guna

Run microservices dalam Docker, e-commerce modules

ECS — komponen & hierarki

Cluster → pool logikal capacity (EC2 instances atau Fargate) tempat tasks jalan

Task Definition → blueprint JSON: image, vCPU, memory, ports, env vars, volumes + Task Role + Task Execution Role. BUKAN benda yang "run" — ia resepi sahaja

Task → satu running instance dari Task Definition (boleh ada 1+ container)

Service → pastikan desired count tasks SENTIASA running (restart kalau mati), boleh attach ke ALB + auto-scaling

Task Role → IAM role yang APP DALAM container guna untuk panggil AWS (S3, DynamoDB) — per-task IAM

Task Execution Role → IAM role yang ECS/Fargate AGENT guna untuk pull image dari ECR + tulis log ke CloudWatch (bukan untuk app code)

Container Instance → EC2 instance yang register ke cluster + run ECS Agent (EC2 launch type sahaja)

ECS Agent → software atas EC2 yang communicate dengan ECS control plane. Fargate tak perlu — AWS manage

Capacity Provider → strategy untuk provision compute: Fargate, Fargate Spot (murah, interruptible), atau EC2 Auto Scaling Group

Anatomi ECS — Cluster → Service → Task ← Task Definition

Rendering diagram…

Cluster = bangunan, Service = ketua yang pastikan sentiasa ada N pinggan, Task = satu pinggan yang sedang dimasak, Task Definition = resepi (blueprint, bukan benda yang run). INGAT exam: "best describes a task definition" → JSON blueprint/template yang describe containers, BUKAN service/task yang running.

Analogi — ECS = restoran mamak

Rendering diagram…

Kaitkan dengan familiar: menu = Task Definition (cuma kertas resepi), pinggan terhidang = Task, ketua dapur jaga stok = Service (desired count), dapur = Cluster. Sewa dapur sendiri = EC2 launch type; guna dapur kongsi tanpa urus = Fargate. INGAT exam: "least operational overhead / no servers" → Fargate; "kawal host (GPU/fleet murah)" → EC2.

EC2 launch type vs Fargate

Aspect	EC2 launch type	Fargate
Infrastructure	🔴 You manage EC2 instances	🟢 Serverless — AWS manages it
Patching/scaling hosts	Your responsibility	No hosts to manage
Pricing	Pay for EC2 instances (per-instance)	Pay per task vCPU + memory
Best for	Cost control at scale, GPU, special host config	Variable load, least ops overhead

Ingat: "Least operational overhead / no servers to manage" → Fargate. "Need control over the host (GPU, large reserved fleet, cheaper at steady scale)" → EC2 launch type.

Task Placement Strategies (EC2 launch type sahaja)

Strategy	Buat apa	Optimize untuk
binpack	Pack tasks ke instance yang ada paling SIKIT CPU/mem lagi cukup	🟢 Kos — guna instance sepenuh, kurangkan bilangan instance
spread	Agih tasks SAMA RATA ikut attribute (cth AZ, instanceId)	🟢 Availability / HA
random	Letak tasks secara rawak	Mudah, tiada keutamaan

Ingat: Jimat duit / packing padat → binpack. Tahan failure / sebar across AZ → spread (selalu spread by AZ). Constraint pula: distinctInstance (satu task satu instance), memberOf (ikut syarat). NOTA: Fargate = best-effort AZ spread sahaja, TAK support strategy/constraint.

3 IAM role dalam ECS — jangan keliru (selalu kena exam)

Role	Siapa guna	Untuk apa
Task Role	🟢 APP kau dalam container	Panggil AWS API: S3, DynamoDB, SQS — per-task IAM, app-level
Task Execution Role	ECS / Fargate AGENT	Pull image dari ECR + tulis log ke CloudWatch + amik secret. BUKAN app code
EC2 Instance Role	EC2 host (EC2 launch type)	Benarkan ECS agent register instance ke cluster. Hanya wujud bila EC2 launch type

Ingat: "Container/app perlu akses S3/DynamoDB" → Task Role. "Task gagal pull image dari ECR / tak boleh tulis log" → fix Task Execution Role. Fargate = TIADA instance role (no host). NOTA: EC2 launch type tiada task isolation — container boleh capai credentials task lain di host sama; nak isolation ketat → Fargate.

ECS task storage — pilih volume jenis mana

Volume	Persistence	Launch type	Guna bila
Bind mount	🔴 Ephemeral (hilang bila task stop)	Fargate + EC2	Scratch space / kongsi data antara container dalam SATU task
Amazon EFS	🟢 Persistent + shared (multi-AZ, concurrent)	Fargate + EC2	Shared file storage across tasks/AZ — analytics, CMS, web serving
Amazon EBS	🟡 Persistent (standalone task); EPHEMERAL kalau task diurus Service	Fargate + EC2	Block storage 1-task: database, throughput-intensive
FSx Windows / NetApp ONTAP	🟢 Persistent shared	EC2 only	Windows SMB (.NET) / enterprise NFS-SMB high-perf
Docker volumes	🟢 Persistent (host-tied)	EC2 only	Pakai third-party / local volume driver atas host

Ingat: Shared persistent across tasks/AZ → EFS (jawapan default stateful ECS). Block 1-task → EBS (TAPI jadi ephemeral bila task diurus Service!). Scratch dalam task → bind mount (ephemeral). FSx & Docker volumes = EC2 launch type SAHAJA. Sama prinsip macam EKS: shared = EFS (RWX), block 1:1 = EBS (RWO).

⚡ Quick Sifir — hafal ni

▪Hierarki: Cluster → Service (jaga desired count) → Task (dari Task Definition blueprint JSON)
▪Launch type: EC2 (kau urus host) vs Fargate (serverless, no host)
▪Task Role = app dalam container call AWS API; Task Execution Role = agent pull image ECR + tulis log
▪Placement: binpack = jimat kos (pack padat); spread = HA (sebar by AZ) — EC2 launch type je
▪Fargate = best-effort AZ spread, no placement strategy/constraint, no instance role

💡 Exam Scenario

"Best describes a task definition" → JSON blueprint/template yang describe containers (image, CPU, memory, ports). "Container app perlu akses S3 dengan least privilege" → Task Role (per-task IAM). "Task tak boleh pull image dari ECR" → Task Execution Role rosak. "Maintain N running copies + auto-restart" → Service. "Run container least ops, no servers" → Fargate. "Pack tasks jimat kos" → binpack; "sebar AZ untuk HA" → spread. STORAGE: "ECS tasks perlu shared persistent file storage across AZ" → Amazon EFS (RWX-style). "Block storage untuk satu task (DB)" → EBS (RWO-style). "Scratch space dalam task" → bind mount (ephemeral).

🪤 Perangkap Soalan

Q: Run Docker containers dengan operational overhead PALING rendah, tak nak urus/patch server. Launch type mana?

⚠ Umpan: EC2 launch type + Auto Scaling — boleh scale, tapi kau MASIH kena patch & manage EC2 host = ada ops overhead.

✓ Betul: Fargate — keyword 'least operational overhead / no servers to manage / serverless container' = Fargate.

Q: Container ECS gagal pull image dari ECR dan tak boleh tulis log ke CloudWatch. IAM role mana kena betulkan?

⚠ Umpan: Task Role — orang ingat semua akses AWS guna Task Role, tapi Task Role untuk APP code (S3/DynamoDB), bukan pull image.

✓ Betul: Task Execution Role — keyword 'pull image from ECR / write logs to CloudWatch' = Task Execution Role (agent), bukan Task Role.

🧠 Cara Mudah Ingat

→Task Role vs Task Execution Role (SELALU kena exam): Task Role = IAM untuk APP DALAM container panggil AWS (S3, DynamoDB) — per-task least privilege. Task Execution Role = IAM untuk ECS/Fargate AGENT pull image dari ECR + tulis CloudWatch logs + amik Secrets Manager. Keliru dua ni = silap jawab.
→Task placement: binpack = jimat kos (padat), spread = HA (sebar AZ), random = rawak. Constraint: distinctInstance, memberOf
→Task Definition = JSON template yang describe containers untuk application (image, CPU, memory, ports, env vars, volumes)
→Task Definition BUKAN: IAM template, bukan service yang launch clusters, bukan program yang run — ia BLUEPRINT untuk containers
→ECS Launch Types: Fargate (serverless, AWS manage infrastructure) vs EC2 (kau manage EC2 cluster)
→Task = running instance of a Task Definition. Service = maintain desired number of running tasks
→Task Role (taskRoleArn) = IAM role untuk container access AWS services. Execution Role (executionRoleArn) = IAM role untuk ECS agent pull image dari ECR + send logs
→Service boleh attach load balancer — ALB untuk path-based routing, NLB untuk TCP/UDP. Standalone Task TIDAK boleh attach LB
→Capacity Provider Strategy: Fargate (default), Fargate Spot (cheaper, interruptible), EC2 ASG (kau manage)
→Exam: "best describes a task definition" → JSON template that describes containers that form your application
→STORAGE — ECS stateful: Amazon EFS = persistent + shared across tasks & AZ (RWX-style), pilihan default container yang scale horizontal & kongsi fail. EBS = block storage 1-task (RWO-style). Sama prinsip macam EKS.
→STORAGE trap: EBS attached ke task yang diurus oleh Service = EPHEMERAL (hilang bila task diganti). Nak EBS persistent → standalone task. Nak persistent + shared yang selamat → EFS.
→STORAGE: bind mount = ephemeral scratch (hilang bila task stop). FSx for Windows / NetApp ONTAP & Docker volumes = EC2 launch type SAHAJA, BUKAN Fargate.

Guna Bila

Run & orchestrate Docker containers (AWS-native, bukan Kubernetes)

Dockercontainersmicroservicestask definitionJSON templateFargateEC2 launch typeservicetaskclusterTask RoleTask Execution Roleper-task IAMbinpackspreadrandomtask placementdesired countECS storageEFS volumesEBS volumesbind mountsephemeral storagepersistent storagestateful containersshared storagecontainer instanceECS agentcapacity provider

📎 ECS task IAM role (Task Role)📎 ECS task execution IAM role 📎 ECS task placement strategies 📎 Storage options for Amazon ECS tasks

D3 · High-Performing

EKS

Elastic Kubernetes Service

"Kubernetes manager"

🎯 Sebab Apa Wujud

EKS wujud sebab ramai team dah pakai Kubernetes (K8s) on-prem / multi-cloud dengan semua YAML, Helm chart & tooling sedia ada — tapi run K8s control plane sendiri (etcd, API server, scheduler) memang menyakitkan dan kena patch + HA sendiri. EKS ambil alih kepala (control plane) yang managed + HA across AZ, kau urus worker nodes/pods je, supaya skill K8s kau boleh terus pakai tanpa lock ke AWS-proprietary macam ECS. IRSA pula wujud sebab dulu pod kena simpan AWS credentials dalam image — bahaya; IRSA bagi pod assume IAM role terus, no secret tersimpan.

Apa Dia

Mengurus Kubernetes cluster untuk container orchestration

Contoh Guna

Large-scale containerized apps yang guna K8s

EKS — komponen & persistent storage (CSI drivers)

Control Plane (AWS managed) → API server (min 2 node, multi-AZ) + etcd (3 AZ) + scheduler. Kau tak sentuh langsung

Worker Nodes → EC2 yang run kubelet + container runtime. 3 jenis: Managed Node Groups, Self-Managed, Fargate (serverless per-pod)

Pod → unit terkecil K8s (1+ container). Dapat REAL VPC IP via AWS VPC CNI plugin

Service / Ingress → Service = stable endpoint untuk group of pods; Ingress = HTTP/HTTPS routing rules — AWS Load Balancer Controller auto-provision ALB

Namespace → virtual cluster untuk isolate workloads (dev/staging/prod) dalam satu physical cluster

Karpenter → auto-provision EC2 node saiz tepat ikut keperluan pod (alternative Cluster Autoscaler)

EBS CSI Driver → mount EBS sebagai ReadWriteOnce (RWO): satu volume terikat ke satu pod, satu AZ je. Sesuai StatefulSet macam database pod (satu pod = satu disk).

EFS CSI Driver → mount EFS sebagai ReadWriteMany (RWX): banyak pod across nodes & AZ kongsi SATU file system serentak. Ini jawapan untuk "shared storage across pods".

FSx for Lustre CSI → shared storage (RWX) throughput tinggi untuk HPC / ML training.

FSx for NetApp ONTAP CSI → shared storage multi-protocol (NFS/SMB) untuk enterprise workload.

EBS Multi-Attach (io1/io2 only) → kongsi satu BLOCK volume ke ≤16 EC2 dalam SATU AZ, wajib cluster-aware filesystem (GFS2/etc). Ini block-level RWO, BUKAN shared file system biasa untuk pods.

Pilih storage untuk EKS pods

Rendering diagram…

Kongsi across nodes = RWX = EFS (default jawapan). Satu pod satu volume = RWO = EBS. Throughput gila = FSx Lustre. INGAT exam: "shared access by multiple pods on different EC2 nodes" → EFS, BUKAN EBS Multi-Attach (block RWO, satu AZ je).

ECS vs EKS — bila pilih yang mana

Aspect	ECS	EKS
Orchestrator	AWS proprietary (mudah)	Kubernetes (standard industri)
Learning curve	🟢 Rendah — AWS-native	🔴 Tinggi — perlu tahu K8s
Portability	AWS-centric	🟢 Portable (K8s di mana-mana)
Kos control plane	Percuma	~$0.10/jam per cluster
Serverless data plane	Fargate	Fargate (boleh juga)
Guna bila	Nak cepat, AWS sahaja, simple	Dah ada K8s skill/tooling, multi-cloud, ekosistem K8s

Ingat: Default + ringkas + AWS sahaja → ECS. Dah pakai Kubernetes / nak portable / ada team K8s → EKS. Dua-dua boleh guna Fargate untuk buang urusan server. "Least ops + no K8s knowledge" → ECS Fargate.

EKS persistent storage — EBS vs EFS vs FSx (access mode)

Storage (CSI driver)	Access mode	Scope	Best untuk
EBS (EBS CSI)	ReadWriteOnce (RWO)	Satu node · satu AZ	StatefulSet 1-pod-1-volume (DB pod)
EFS (EFS CSI)	🟢 ReadWriteMany (RWX)	Multi-AZ · ramai node	Shared access pods across nodes (default jawapan)
FSx for Lustre	ReadWriteMany (RWX)	Multi-node high-perf	HPC / ML training throughput tinggi
FSx for NetApp ONTAP	RWX (NFS/SMB)	Multi-protocol	Enterprise shared, multi-protocol

Ingat: Pods kongsi fail across different nodes → EFS (RWX). Satu pod satu volume (DB) → EBS (RWO). HPC/ML throughput → FSx Lustre. EBS Multi-Attach (io1/io2) = block RWO, satu AZ je, wajib cluster-aware FS — BUKAN shared file system untuk pods. Exam: "shared access by multiple pods on different EC2 nodes" → EFS.

EKS load balancing / ingress — route trafik masuk ke pods

Pilihan	Layer / routing	Bila pilih
ALB (AWS Load Balancer Controller)	L7 — host/PATH-based routing (Ingress)	🟢 Route ikut URL path/host, least setup, AWS-managed
NLB (AWS Load Balancer Controller)	L4 — IP/port je, TIADA path routing	TCP/UDP, ultra-low latency, static IP
NGINX Ingress Controller	L7 — boleh path routing tapi self-managed	Perlu feature NGINX khusus; lebih banyak setup + maintenance

Ingat: Route ke EKS services ikut URL PATH dengan setup paling sikit → ALB via AWS Load Balancer Controller (Ingress = L7). NLB = L4 (port je, tak boleh path). NGINX ingress = boleh path tapi kau maintain sendiri = lebih ops. Lambda proxy ke EKS = over-engineering, bukan "least setup".

⚡ Quick Sifir — hafal ni

▪EKS = managed Kubernetes; ECS = AWS-proprietary orchestrator
▪EKS control plane ~$0.10/jam/cluster; ECS control plane FREE
▪Pilih EKS bila: dah ada K8s skill/YAML/Helm atau nak portable multi-cloud
▪Pod access AWS tanpa simpan credentials = IRSA (IAM Roles for Service Accounts)
▪ConfigMap = non-sensitive config je, BUKAN tempat secret
▪Least ops + tak reti K8s = ECS Fargate, BUKAN EKS

💡 Exam Scenario

"Route ke EKS services ikut URL path / host dengan least setup" → ALB via AWS Load Balancer Controller (Ingress L7); NLB = L4 (port je, no path); NGINX Ingress = boleh path tapi self-managed = lebih ops. "Dah ada Kubernetes skill/YAML/Helm, nak portable across cloud" → EKS (bukan ECS). "Just run containers, AWS-only, least learning" → ECS. "EKS pods access AWS tanpa simpan credentials" → IRSA. "K8s control plane managed tapi nak run on-prem consistent" → EKS Anywhere. STORAGE: "shared access by multiple pods on different EC2 nodes" → EFS (RWX, EFS CSI Driver), BUKAN EBS Multi-Attach. "Satu pod satu volume / database StatefulSet" → EBS (RWO, EBS CSI Driver). "HPC / ML training throughput tinggi" → FSx for Lustre. NOTA: control plane EKS ada kos (~$0.10/jam/cluster); ECS control plane percuma.

🪤 Perangkap Soalan

Q: Company nak run containers di AWS, team baru, tak ada pengalaman Kubernetes, nak least operational overhead. Pilih mana?

⚠ Umpan: EKS — sebab 'Kubernetes' bunyi macam standard industri & power, ramai ingat container = K8s.

✓ Betul: ECS Fargate — keyword 'no K8s knowledge + least ops'. EKS ada learning curve tinggi + bayar control plane. ECS Fargate = AWS-native, serverless, paling senang.

Q: EKS pods perlu baca secret dari Secrets Manager tanpa hardcode credentials dalam container image. Cara terbaik?

⚠ Umpan: Simpan access key dalam Kubernetes ConfigMap atau dalam image — nampak macam senang, terus boleh pakai.

✓ Betul: IRSA (IAM Roles for Service Accounts) — pod assume IAM role via service account annotation, zero credentials tersimpan. ConfigMap BUKAN untuk secret.

Q: App pada EKS perlu route request ke service berbeza IKUT URL path, dengan setup PALING sikit. Pilih apa?

⚠ Umpan: NLB via Load Balancer Controller atau NGINX Ingress Controller — nampak macam standard K8s ingress, tapi NLB = L4 (tak boleh path) & NGINX kena deploy+maintain sendiri = lebih ops.

✓ Betul: ALB via AWS Load Balancer Controller (Ingress, L7) — host/path-based routing, AWS-managed, least setup. Lambda proxy ke EKS = effort tinggi, bukan jawapan.

🧠 Cara Mudah Ingat

→IRSA (IAM Roles for Service Accounts): pods assume IAM roles via service account annotation — no credentials stored anywhere
→Best practice for EKS pods to access AWS services (Secrets Manager, S3, DynamoDB) without embedding credentials
→ConfigMaps = non-sensitive config data. NOT for secrets. Kubernetes Secrets + IRSA = proper pattern
→Managed Node Groups = AWS manage EC2 provisioning + patching. Self-Managed = kau urus sendiri. Fargate = serverless, per-pod
→AWS VPC CNI plugin: setiap pod dapat real VPC IP → boleh communicate terus dengan AWS services tanpa NAT
→Control Plane fully managed by AWS — multi-AZ, auto-scaling API servers, etcd across 3 AZs
→Exam: "EKS pods need access to Secrets Manager without credentials in container image" → IRSA + Kubernetes Secrets
→STORAGE — EBS CSI Driver = ReadWriteOnce (RWO): satu pod, satu AZ. EFS CSI Driver = ReadWriteMany (RWX): banyak pod across nodes/AZ kongsi satu file system.
→STORAGE exam: "EKS pods perlu shared access ke storage across different EC2 nodes" → Amazon EFS (RWX), BUKAN EBS Multi-Attach (RWO, satu AZ je).
→STORAGE trap: EBS Multi-Attach hanya io1/io2, kongsi BLOCK volume ke ≤16 EC2 dalam SATU AZ + wajib cluster-aware filesystem — ia bukan shared file system biasa untuk pods.
→STORAGE: FSx for Lustre (RWX) = high-performance shared storage untuk HPC / ML training atas EKS.
→INGRESS/LB — AWS Load Balancer Controller = add-on K8s yang provision ALB (untuk Ingress, L7 host/path routing) atau NLB (untuk Service type LoadBalancer, L4). "Route ke EKS services ikut URL path, least setup" → ALB Ingress via Load Balancer Controller.
→INGRESS trap: NLB = L4 (IP/port), TAK boleh routing ikut URL path/host. NGINX Ingress Controller boleh path-routing tapi kau kena deploy & maintain sendiri = lebih operational overhead vs ALB. Lambda proxy ke EKS = effort tinggi, bukan "least setup".

Guna Bila

Container orchestration guna K8s

KubernetesK8scontainer orchestrationIRSAIAM Roles for Service Accountspod identityECS vs EKScontrol plane costEKS storagepersistent volumeEBS CSI DriverEFS CSI DriverReadWriteManyRWXReadWriteOnceRWOshared storage podspods different nodesFSx for Lustre EKSEBS Multi-AttachAWS Load Balancer ControllerALB ingressKubernetes ingresspath-based routing EKSNLB EKSNGINX ingressroute by URL pathcontrol planeworker nodesVPC CNINamespaceKarpenter

📎 Amazon EKS — what is it 📎 IAM Roles for Service Accounts (IRSA)📎 Storage for Amazon EKS (EBS/EFS/FSx CSI)

D3 · High-Performing

EKS Variants

EKS Anywhere vs EKS Distro vs ECS Anywhere

"EKS Anywhere = K8s on-prem + AWS control plane. EKS Distro = pure on-prem, no AWS control plane. ECS Anywhere = ECS on-prem"

🎯 Sebab Apa Wujud

Variants ni wujud sebab tak semua workload boleh hidup penuh dalam cloud — ada compliance/latency/data residency yang paksa container run on-premises, tapi team tetap nak experience & consistency AWS. EKS Anywhere bagi kau run K8s on-prem tapi connect ke AWS untuk management consistency; EKS Distro pula bagi distribusi K8s yang sama macam EKS guna tapi 100% on-prem tanpa bergantung AWS control plane (elak lock-in); ECS Anywhere bawak ECS task ke server on-prem kau sendiri.

Apa Dia

AWS menyediakan pelbagai pilihan untuk run containers on-premises dengan degrees berbeza dari AWS control plane dependency.

Variants

EKS Anywhere → Deploy K8s clusters on-prem using open-source tools, connected to AWS control plane for management consistency

EKS Distro → AWS K8s distribution used by EKS — run fully on-prem, NO AWS control plane dependency. Full open-source freedom

ECS Anywhere → Run ECS tasks on on-premises servers, managed by AWS ECS control plane

Pilih variant on-prem mana?

Rendering diagram…

Cabang pertama: ECS ke Kubernetes? Kalau K8s, cabang kedua yang penting: ADA atau TIADA AWS control plane. INGAT exam: "open-source K8s on-prem + consistency with AWS" → EKS Anywhere; "no AWS dependency / avoid lock-in" → EKS Distro.

3 variant on-prem — orchestrator & AWS control plane

Variant	Orchestrator	AWS control plane?	Pilih bila
EKS Anywhere	Kubernetes	🟢 Ya — connect AWS untuk consistency	Nak run K8s on-prem TAPI nak management & consistency macam EKS cloud
EKS Distro	Kubernetes	🔴 Tiada — 100% on-prem, no lock-in	Nak distribusi K8s SAMA macam EKS guna tapi fully self-managed on-prem
ECS Anywhere	ECS (AWS-native)	🟢 Ya — ECS control plane urus task	Dah pakai ECS, nak bawak task ECS turun ke server on-prem sendiri

Ingat: K8s + on-prem + "consistency with AWS control plane" → EKS Anywhere. K8s + on-prem + "no AWS dependency / no lock-in" → EKS Distro. ECS (bukan K8s) + on-prem → ECS Anywhere. Perangkap utama: "open-source K8s on-prem" SAHAJA tak cukup beza — kena tengok ada/tiada AWS control plane.

⚡ Quick Sifir — hafal ni

▪EKS Anywhere = K8s on-prem + connect AWS control plane untuk consistency
▪EKS Distro = distribusi K8s sama macam EKS, run penuh on-prem, NO AWS control plane
▪ECS Anywhere = run ECS task atas server on-prem kau
▪Keyword 'open-source + on-prem + AWS consistency' = EKS Anywhere
▪Keyword 'no AWS lock-in + on-prem K8s' = EKS Distro

🪤 Perangkap Soalan

Q: Company nak run open-source Kubernetes on-premises tapi nak konsistensi & management dari AWS control plane. Pilih mana?

⚠ Umpan: EKS Distro — sebab 'open-source Kubernetes on-prem' padan, orang terus pilih.

✓ Betul: EKS Anywhere — keyword pembeza ialah 'consistency with AWS control plane'. EKS Distro JUSTRU tiada AWS control plane dependency (untuk no lock-in).

🧠 Cara Mudah Ingat

→EKS Anywhere: "open-source Kubernetes + on-prem + consistency with AWS control plane" → EKS Anywhere
→EKS Distro: "no AWS lock-in + no AWS control plane + on-prem Kubernetes" → EKS Distro
→ECS Anywhere: "run ECS tasks on-premises" → ECS Anywhere
→Exam trick: kalau soalan sebut "open-source" + "on-prem" + "AWS control plane consistency" → EKS Anywhere (bukan EKS Distro)

Guna Bila

Run container workloads on-premises with varying levels of AWS integration

EKS AnywhereEKS DistroECS Anywhereon-premises Kuberneteshybrid containers

📎 Amazon EKS Anywhere 📎 Amazon EKS Distro

D3 · High-Performing

AWS LB Controller

AWS Load Balancer Controller

"Kubernetes Ingress → auto-provision ALB/NLB. Path-based routing = ALB, least setup"

Apa Dia

Kubernetes controller add-on yang watch for Ingress resources dan auto-create ALB, atau watch for Service type LoadBalancer dan auto-create NLB. Install dalam EKS cluster, integrate terus dengan AWS APIs. Kau define routing rules dalam Kubernetes YAML → controller buat semua AWS infra automatically.

Contoh Guna

Define Kubernetes Ingress dengan path rules (/api → service-a, /web → service-b) → Controller auto-provision ALB dengan matching target groups dan listener rules

LB Controller Components

Ingress Resource → Kubernetes YAML yang define HTTP routing rules (path, host). Controller watch ni dan create ALB

ALB (auto-created) → Layer 7 load balancer dengan path/host rules. Controller create target groups + listener rules automatically

NLB (auto-created) → For Service type LoadBalancer. Controller create NLB untuk TCP/UDP traffic

Target Groups → Controller register pods directly as IP targets (pod IP mode) — traffic bypass kube-proxy

Annotations → kubernetes.io/ingress.class: alb, alb.ingress.kubernetes.io/scheme: internet-facing, etc.

💡 Exam Scenario

"EKS cluster perlu route requests by URL path with LEAST setup" → AWS Load Balancer Controller + ALB. Sebab: (1) ALB natively support path-based routing (Layer 7), (2) Controller auto-provision — tak perlu manual create LB. Lambda proxy = overkill + kena tulis routing logic. NLB = Layer 4, tak faham URL paths. NGINX Ingress = more setup (install + manage NGINX pods sendiri).

🧠 Cara Mudah Ingat

→Ingress resource + AWS LB Controller = auto ALB. Service type LoadBalancer + Controller = auto NLB
→ALB = path-based routing (Layer 7). NLB = TCP/UDP (Layer 4). Soalan sebut "URL path routing" → ALB
→AWS LB Controller is the OFFICIAL AWS-native solution untuk EKS load balancing — least setup vs NGINX Ingress
→NGINX Ingress Controller = alternative tapi more setup (kena install, manage, scale NGINX pods sendiri)
→Lambda proxy = overkill untuk simple routing — kena tulis custom routing code, tak scalable
→Controller register pods sebagai IP targets (bypass kube-proxy) — better performance
→Exam: "EKS + route by URL path + least setup" → ALB via AWS Load Balancer Controller. Bukan NLB (Layer 4), bukan Lambda, bukan NGINX

Guna Bila

Auto-provision AWS load balancers (ALB/NLB) dari Kubernetes Ingress/Service resources

AWS Load Balancer ControllerALBNLBIngresspath-based routingEKSKubernetesLayer 7auto-provision

📎 AWS LB Controller 📎 ALB Ingress on EKS

D3 · High-Performing

EC2 User Data

EC2 User Data Scripts

"Script masa launch"

🎯 Sebab Apa Wujud

User Data wujud sebab tak masuk akal nak SSH masuk satu-satu setiap EC2 baru untuk install software & configure — apatah lagi bila ASG auto-launch 50 instance. User Data bagi instance configure DIRI SENDIRI masa first boot (install package, pull code, set config) supaya launch boleh full automated, no manual touch.

Apa Dia

Skrip yang dijalankan sekali masa instance pertama kali launch — install software, configure app, pull code dari repo. Max 16KB. Guna bash script atau cloud-init.

Contoh Guna

Launch EC2 → User Data install Apache + download web app secara automatik. Developer tak perlu SSH masuk untuk setup.

Analogi — User Data vs Metadata (check-in hotel)

Rendering diagram…

User Data = senarai ARAHAN dibuat SEKALI masa check-in (first boot). Metadata = KAD info bilik yang kau BACA bila-bila. INGAT exam: "auto-install / bootstrap on launch" → User Data (RUN); "retrieve instance ID / IAM role creds" → Metadata (BACA).

EC2 User Data vs Instance Metadata — JANGAN keliru (selalu kena exam)

Aspect	User Data	Instance Metadata (IMDS)
Apa dia	🟢 SCRIPT yang RUN	INFO yang kau BACA
Tujuan	Bootstrap: install, pull code, config	Tahu instance ID, IP, IAM role, hostname
Bila jalan	Sekali, masa FIRST BOOT	Bila-bila, query dari dalam instance
Endpoint	169.254.169.254/latest/user-data/	169.254.169.254/latest/meta-data/

Ingat: User Data = RUN script (verb). Metadata = BACA info (noun). "bootstrap / auto-install on launch" → User Data; "retrieve instance ID / IAM role credentials from inside" → Metadata. Dua-dua guna 169.254.169.254 tapi path beza (user-data vs meta-data).

⚡ Quick Sifir — hafal ni

▪User Data run SEKALI je — masa instance first boot
▪Max size = 16KB (base64 sebelum encode)
▪Run as root, guna bash script atau cloud-init
▪Keyword exam: 'bootstrap / initialization script during launch' = User Data
▪Metadata = info pasal instance; User Data = SCRIPT yang run — jangan keliru

💡 Exam Scenario

"EC2 fleet baru launch perlu auto-install software tanpa manual SSH" → User Data. Keyword: during instance launch, bootstrap, initialization script.

🪤 Perangkap Soalan

Q: ASG launch instance EC2 baru perlu auto-install Apache + download app config setiap kali scale-out, tanpa admin SSH masuk. Guna apa?

⚠ Umpan: EC2 Instance Metadata — sebab nama bunyi macam 'set up instance', orang campur aduk metadata dengan user data.

✓ Betul: EC2 User Data — keyword 'auto-install on launch / bootstrap'. Metadata cuma BACA info pasal instance (IP, instance ID, IAM role), ia tak RUN script.

🧠 Cara Mudah Ingat

→User Data run SEKALI masa first boot, as root (cloud-init). Nak run setiap boot → cloud-init directive / mime multipart.
→Limit 16 KB (sebelum base64). Script besar → letak User Data kecil yang pull script penuh dari S3.
→User Data BOLEH dibaca balik via metadata (169.254.169.254/latest/user-data) → JANGAN letak password/secret plain. Guna Secrets Manager / SSM Parameter Store.
→PRICING: User Data percuma — bayar EC2 je.

Guna Bila

Auto-configure EC2 instance on first boot

bootstraplaunch scriptcloud-initfirst bootinitialization16KB limituser data vs metadataauto-configurepull from S3

📎 Run commands on your Linux instance at launch (User Data)

D3 · High-Performing

EC2 Hibernation

Amazon EC2 Hibernation

"EC2 tidur tapi ingat semua — RAM saved to EBS"

🎯 Sebab Apa Wujud

Hibernation wujud sebab sesetengah app ambil masa lama untuk warm-up RAM (in-memory cache, JVM, dataset besar dalam memory) — kalau Stop biasa, RAM state hilang & kena re-initialize dari kosong setiap start (cold start lambat). Hibernation simpan seluruh isi RAM ke EBS root volume, jadi bila resume, OS & app sambung balik EXACTLY macam sebelum — no re-warm, resume laju.

Apa Dia

Hibernation saves seluruh RAM contents ke EBS root volume. Bila resume, OS dan app state adalah exactly sama seperti sebelum — tiada re-initialization. Berbeza dengan Stop/Start (yang lose RAM state) dan reboot (yang restart OS).

Nak "matikan" EC2 — pilih transition mana?

Rendering diagram…

Hibernate = satu-satunya cara stop instance (tak bayar compute) TAPI kekalkan RAM. Reboot kekal RAM tapi masih bayar (running). INGAT exam: "memory-intensive + long warm-up + preserve state sambil jimat kos idle" → Hibernate.

EC2 lifecycle — Hibernate vs Stop/Start vs Reboot vs Terminate

Aspect	Hibernate	Stop / Start	Reboot	Terminate
RAM / in-memory state	KEKAL (ditulis ke EBS root)	HILANG (dikosongkan)	KEKAL (instance tak stop)	HILANG
Instance store (ephemeral) data	HILANG	HILANG	KEKAL	HILANG
Public IPv4 (no EIP)	Berubah	Berubah	Kekal	N/A
Compute billing	Tak bayar (state = stopped)	Tak bayar (stopped)	Bayar (masih running)	Tak bayar
EBS billing	Bayar — termasuk RAM dump di root	Bayar	Bayar	Hilang (jika DeleteOnTermination)
Resume	Laju, no re-init (state sama)	Cold boot, RAM re-warm	Cepat (OS restart je)	N/A — instance gone

Ingat: Nak preserve RAM merentas stop → Hibernate. RAM tak penting / nak jimat → Stop/Start. Tukar nothing-persistent / clear glitch → Reboot. Buang terus → Terminate. INGAT exam: hanya Hibernate & Reboot kekalkan RAM; hanya Reboot kekalkan instance-store + public IP.

⚡ Quick Sifir — hafal ni

▪Hibernation = simpan isi RAM ke EBS root volume, resume laju tanpa re-init
▪EBS root volume MESTI encrypted untuk hibernation
▪Bukan semua instance type support hibernation
▪Stop/Start biasa = RAM HILANG; Reboot = OS restart; Hibernate = RAM KEKAL
▪Keyword 'preserve in-memory state + fast recovery' = Hibernation, BUKAN AMI

💡 Exam Scenario

Formula poket: "memory-intensive app" + "long initialization / warm-up time" + "preserve application state across restart" → EC2 Hibernation. BUKAN Stop/Start (RAM cleared, kena warm-up balik), BUKAN AMI/launch baru (disk snapshot je, cold boot, RAM kosong), BUKAN Reboot (tak simpan RAM state).

🪤 Perangkap Soalan

Q: App in-memory cache ambil 20 minit untuk warm-up. Nak stop instance waktu malam jimat kos, tapi pagi resume terus warm tanpa re-load. Pilih apa?

⚠ Umpan: Buat AMI sebelum stop, restore dari AMI pagi esok — nampak macam 'simpan state'.

✓ Betul: EC2 Hibernation — AMI cuma snapshot DISK, ia TAK simpan RAM/in-memory state. Hanya Hibernation preserve RAM contents (saved to encrypted EBS root).

Q: Memory-intensive app, nak elak long initialization time & resume dengan application state SAMA atas backup instance, on-demand. Cara paling tepat?

⚠ Umpan: Stop instance bila tak guna, Start balik bila perlu — nampak paling jimat kos & macam 'instance sama balik'.

✓ Betul: EC2 Hibernation atas backup instance, resume on-demand. Stop/Start biasa KOSONGKAN RAM → memory-intensive app kena re-initialize dari kosong = long init time. Hanya Hibernate simpan RAM state untuk resume pantas.

🧠 Cara Mudah Ingat

→Hibernation saves RAM to EBS root volume (must be encrypted)
→Resume time = sangat cepat vs cold start (no app re-initialization)
→Use case: memory-intensive apps yang ambil masa lama nak load (e.g. in-memory cache warm-up)
→Not all instance types support hibernation. Root EBS volume MESTI encrypted
→Exam: "preserve in-memory state + fast recovery" → EC2 Hibernation. Bukan AMI (AMI = snapshot, no RAM state)
→Prereq: enable hibernation MASA launch (tak boleh tambah lepas). RAM ≤ 150 GB, root volume cukup besar untuk muat RAM, instance tak boleh hibernate > 60 hari berturut
→PRICING: Hibernation feature = FREE. Bila hibernated instance dalam "stopped" state → TAK bayar compute (per-second/jam), TAPI bayar EBS storage untuk root volume TERMASUK RAM dump (gp3 ~$0.08/GB-bulan). Contoh: instance 32 GB RAM perlu +32 GB EBS untuk simpan RAM = ~$2.56/bulan tambahan storan. Masih bayar EIP jika allocated tapi tak attached. Exam cost: Hibernate jimat compute tapi NAIK sikit kos EBS berbanding Stop biasa.

Guna Bila

Preserve in-memory state across stop/start — fast resume for memory-intensive apps

hibernationRAM saveEBS rootfast resumein-memory stateencrypted root volumestop start reboot terminateinstance lifecyclewarm-up timepricing

📎 Hibernate your Amazon EC2 instance 📎 Hibernation prerequisites

D3 · High-Performing

EC2 Metadata

EC2 Instance Metadata Service (IMDS)

"ID kad instance sendiri"

🎯 Sebab Apa Wujud

IMDS wujud sebab app dalam EC2 selalu perlu tahu 'aku ni siapa' — public/private IP sendiri, instance ID, IAM role yang attached — tanpa kena hardcode atau panggil AWS API dari luar. Endpoint 169.254.169.254 bagi instance query info diri sendiri & retrieve temporary IAM credentials secara automatik. IMDSv2 wujud pula untuk patch SSRF attack (paksa guna session token, bukan simple GET) yang IMDSv1 terdedah.

Apa Dia

Menyediakan data tentang instance itu sendiri — IP address, instance ID, IAM role name, security groups, hostname. Accessible dari dalam instance via http://169.254.169.254/latest/meta-data/

Contoh Guna

App dalam EC2 nak tau public IP dia sendiri atau nama IAM role yang attached — query Metadata endpoint tanpa perlu AWS CLI.

IMDS paths (169.254.169.254/latest/)

meta-data/ → info instance: instance-id, local/public-ipv4, hostname, security-groups, placement/az

meta-data/iam/security-credentials/<role> → temporary IAM role credentials (auto-rotate) — ni yang SSRF nak curi

dynamic/instance-identity/document → JSON identity (region, accountId, instanceType) untuk verify identity

user-data/ → baca balik User Data script (sebab tu JANGAN letak secret dalam User Data)

IMDSv2 token flow — kenapa SSRF gagal

Rendering diagram…

IMDSv2 tambah langkah PUT token sebelum GET — request SSRF naif (yang cuma boleh GET) gagal. INGAT exam: "prevent metadata credential theft / SSRF" → enforce IMDSv2 (HttpTokens=required), BUKAN security group (tak boleh control link-local 169.254.169.254).

IMDSv1 vs IMDSv2 — security discriminator

Aspect	IMDSv1	IMDSv2
Cara request	🔴 Simple GET (no token)	🟢 PUT token dulu, baru GET pakai token
Tahan SSRF?	❌ Terdedah (attacker GET terus)	🟢 Token + hop limit halang SSRF
Session	Stateless	Session-oriented (token ada TTL)
Recommend	Legacy je	🟢 Default & enforce (HttpTokens=required)

Ingat: "SSRF / steal IAM credentials from metadata / harden instance" → enforce IMDSv2 (HttpTokens=required). IMDSv2 paksa PUT session token + default IP hop limit = 1. Security group / NACL TAK boleh block 169.254.169.254 (link-local) — IMDSv2 satu-satunya kawalan betul.

⚡ Quick Sifir — hafal ni

▪Endpoint metadata = http://169.254.169.254/latest/meta-data/
▪Bagi info: instance ID, IP, hostname, IAM role name, security groups
▪IMDSv2 = token-based (lebih selamat, lawan SSRF); IMDSv1 = simple request
▪Metadata = info pasal instance; User Data = script yang run — beza!
▪IAM role credentials di-retrieve via metadata endpoint (auto-rotate)

💡 Exam Scenario

"Script dalam EC2 nak retrieve IAM role credentials atau instance ID" → Instance Metadata. Bukan untuk run scripts. Keyword: 169.254.169.254, info about instance.

🪤 Perangkap Soalan

Q: App dalam EC2 perlu retrieve temporary IAM role credentials & instance ID dari dalam instance itu sendiri. Guna apa?

⚠ Umpan: EC2 User Data — sebab dua-dua duduk 'dalam EC2' & nama bunyi serupa, mudah tertukar.

✓ Betul: EC2 Instance Metadata (IMDS, 169.254.169.254) — ia BACA info & credentials pasal instance. User Data cuma RUN script masa boot, bukan untuk query info.

Q: Security audit nak halang SSRF attack curi IAM credentials dari metadata endpoint. Tindakan?

⚠ Umpan: Block port 169.254.169.254 dengan security group — SG tak boleh control link-local address, jadi tak jalan.

✓ Betul: Enforce IMDSv2 (token/session-based) — keyword 'SSRF / metadata credential theft'. IMDSv2 paksa PUT token dulu, halang attack yang exploit IMDSv1.

🧠 Cara Mudah Ingat

→IMDSv2 enforce: set HttpTokens=required pada instance metadata options (boleh paksa via launch template / SCP / org policy).
→IMDSv2 default hop limit = 1 → halang request transit melalui container network / reverse proxy (lapisan SSRF defense extra).
→Security group / NACL TAK boleh block 169.254.169.254 (link-local) — satu-satunya kawalan = IMDSv2, atau matikan IMDS terus kalau tak perlu.
→Metadata BACA info; nak IAM role temporary credentials → meta-data/iam/security-credentials/<role-name> (auto-rotate, no hardcode).
→PRICING: IMDS percuma — sebahagian EC2.

Guna Bila

Get info about the running instance from within the instance

169.254.169.254instance infoIMDSv2IMDSv1hostnameIP addressIAM role nameSSRFHttpTokenshop limitlink-local

📎 Instance metadata and user data (IMDS)📎 Use IMDSv2

D3 · High-Performing

Recycle Bin

AWS Recycle Bin (AMI & EBS Snapshots)

"Tong sampah untuk AMI dan snapshots — boleh recover dalam tempoh tertentu"

🎯 Sebab Apa Wujud

Recycle Bin wujud sebab dulu kalau orang tersilap delete AMI atau EBS snapshot, ia terus PERMANENT hilang — tiada undo, recovery susah/mustahil. Recycle Bin jadi safety net: resource yang deleted ditahan untuk tempoh retention (1 hari sampai 1 tahun) sebelum benar-benar dipadam, jadi accidental deletion boleh di-restore.

Apa Dia

Recycle Bin menyimpan AMIs dan EBS snapshots yang deleted untuk tempoh yang kau tentukan (up to 1 year). Kalau terhapus, boleh restore dari Recycle Bin. Selepas retention period, permanently deleted.

Recycle Bin vs DLM vs AWS Backup — jangan keliru 3 "snapshot" service

Aspect	Recycle Bin	Data Lifecycle Manager (DLM)	AWS Backup
Buat apa	UNDO delete — tahan AMI/snapshot ter-delete	AUTO-create + retain + delete snapshot ikut jadual	Centralized backup policy merentas service
Trigger	Bila resource di-DELETE (safety net)	Jadual (cth tiap 12 jam)	Backup plan (jadual + vault + lifecycle)
Skop	EBS snapshot + AMI sahaja	EBS snapshot + AMI	EBS, EFS, RDS, DynamoDB, FSx, S3, dll
Keyword exam	"recover accidentally deleted"	"automate/schedule snapshot creation"	"centralized / cross-service backup + compliance"

Ingat: UNDO accidental delete → Recycle Bin. SCHEDULE snapshot creation → DLM. CENTRALIZED backup banyak service + Vault Lock compliance → AWS Backup. INGAT exam: Recycle Bin = undo, bukan create.

⚡ Quick Sifir — hafal ni

▪Recycle Bin = safety net untuk AMI & EBS snapshot yang ter-delete
▪Retention period: 1 hari sampai 1 tahun (set via Retention Rule)
▪Lepas retention habis = permanently deleted
▪Keyword 'recover accidentally deleted AMI/snapshot' = Recycle Bin
▪Cover AMI + EBS snapshot je — bukan EC2 instance / EBS volume

💡 Exam Scenario

"Recover accidentally deleted AMI / EBS snapshot within a retention window" → Recycle Bin. "Automate snapshot CREATION on a schedule" → Data Lifecycle Manager (DLM). "Centralized backup policy across many services (RDS, EFS, DynamoDB...)" → AWS Backup. Recycle Bin = UNDO delete sahaja, AMI + EBS snapshot je.

🪤 Perangkap Soalan

Q: Admin tersilap delete production AMI. Nak ada cara recover AMI/snapshot yang ter-delete dalam tempoh tertentu. Setup apa?

⚠ Umpan: CloudFormation StackSets — sebab 'restore/redeploy' bunyi macam boleh bring back resources.

✓ Betul: Recycle Bin + Retention Rule — keyword 'recover accidentally deleted AMI/snapshot'. StackSets cuma untuk deploy stack multi-account/region, ia TAK boleh recover AMI yang dah delete.

Q: Nak AUTO-create EBS snapshot setiap 12 jam & buang yang lebih 30 hari. Recycle Bin?

⚠ Umpan: Recycle Bin — sebab ia uruskan snapshot retention, nampak macam betul.

✓ Betul: Data Lifecycle Manager (DLM) — ia automate CREATION + retention snapshot ikut jadual. Recycle Bin cuma tahan snapshot yang DAH ter-DELETE (undo), bukan create ikut jadual. Keyword 'schedule/automate snapshot creation' → DLM.

🧠 Cara Mudah Ingat

→Recycle Bin = safety net untuk accidental AMI/EBS snapshot deletion
→Retention period: 1 day to 1 year. Set via Retention Rule dalam Recycle Bin console
→Exam: "prevent permanent loss of accidentally deleted AMIs" → Recycle Bin
→CloudFormation StackSets tidak boleh recover deleted AMIs — ia untuk multi-account/region deployment
→PRICING: Recycle Bin sendiri TIADA caj tambahan — kau bayar storan biasa untuk AMI/EBS snapshot yang ditahan dalam bin sepanjang retention (EBS snapshot ~$0.05/GB-mo). Jadi retention period panjang × banyak snapshot = kos storan naik. Exam: kos Recycle Bin = kos storan snapshot, bukan fee feature.

Guna Bila

Recover accidentally deleted AMIs and EBS snapshots within a defined retention period

Recycle BinAMI recoveryEBS snapshot recoveryaccidental deletionretention periodretention ruleData Lifecycle ManagerDLMAWS Backuppricing

📎 Recover deleted snapshots & AMIs with Recycle Bin

D3 · High-Performing

AWS Batch

"Ketua pekerja batch jobs — submit kerja, AWS upah & bubar pekerja (compute) sendiri"

🎯 Sebab Apa Wujud

AWS Batch wujud sebab kalau kau ada beribu job berat (rendering, genomics, simulation, ETL berjam-jam) yang perlu beratur ikut priority, dulu kau kena urus sendiri EC2 fleet + scheduler third-party (Slurm/LSF/PBS) — provision, scale, bubar, semua manual & menyakitkan. Batch ambil alih: kau hantar job ke queue, Batch provision compute sesuai (boleh Spot untuk jimat), run sampai habis, lepas tu BUBAR fleet auto. Tiada had masa 15 minit macam Lambda.

Apa Dia

AWS Batch menguruskan semua infrastruktur untuk batch jobs: provision compute resources yang sesuai, schedule jobs dalam queues, monitor dan scale fleet secara automatik, kemudian BUBAR bila kerja habis. Tiada had masa macam Lambda — sesuai untuk job berjam-jam (rendering, genomics, ETL berat, simulation). Menggantikan third-party batch software seperti PBS, Slurm, LSF.

AWS Batch — 4 komponen

Job → satu unit kerja (container/script) yang kau submit

Job Definition → blueprint: image mana, vCPU, memory, IAM role

Job Queue → tempat job beratur ikut priority sebelum dijalankan

Compute Environment → EC2 atau Fargate resources yang Batch provision (boleh guna Spot untuk jimat)

Cara ingat — "Job ambil masa berapa lama?"

Rendering diagram…

Analogi: AWS Batch = KETUA PEKERJA projek — kau hantar senarai kerja (jobs) dalam baris (queue), ketua upah pekerja (EC2/Fargate, boleh upah pekerja kontrak murah = Spot) ikut keperluan, siap kerja terus bubar. Macam "basuh 100 helai baju": Lambda = tangan tapi kena berhenti lepas 15 min; Batch = upah ramai pekerja basuh serentak ikut baris kerja. INGAT exam: "batch", "queue of jobs", "run-to-completion at scale" → AWS Batch.

Job lama / berat — Batch vs Fargate vs Lambda vs EC2

Service	Sesuai bila	Had masa	Siapa urus compute
AWS Batch	🟢 Banyak batch job / array job berjadual, perlu queue + priority + Spot	Tiada had	AWS provision & bubar fleet auto
ECS/EKS Fargate	Satu app/job container run lama atau 24/7, no queue needed	Tiada had	AWS (serverless container)
Lambda	Tugas pendek event-driven	🔴 Maks 15 minit	AWS (serverless function)
EC2 (sendiri/ASG)	Perlu kawalan penuh OS / GPU / fleet steady murah	Tiada had	🔴 Kau patch & scale sendiri

Ingat: Exam keyword "batch processing", "queue of jobs", "run to completion at scale", "scientific/rendering/genomics" → AWS Batch (queue + auto Spot). Satu container long-running tanpa queue → Fargate. "Lebih 15 minit" je → BUKAN Lambda. Batch SENDIRI percuma — bayar hanya EC2/Fargate di bawahnya.

Penjadualan & automation — EventBridge vs Lambda vs AWS Batch

Service	Peranan	Bila pakai
Amazon EventBridge	Cron SEBENAR AWS — TRIGGER ikut jadual/event (cth setiap Ahad 1 pagi). Dia sendiri tak buat kerja, cuma cetus servis lain	Nak mulakan sesuatu ikut masa/event
AWS Lambda	Run automation RINGAN & cepat (🔴 max 15 min)	Skrip pendek event-driven: cleanup temp file, resize image, hantar notification
AWS Batch	Run job BERAT/lama/pukal (Docker, tiada had masa)	Tugasan berjadual yang berat: big-data analysis, rendering, genomics berjam-jam

Ingat: EventBridge = jam loceng (cetus ikut masa) — BUKAN dia yang buat kerja. Lambda = kerja ringan <15 min. Batch = kerja berat berjam-jam. Senario gabungan klasik: "Setiap Ahad 1 pagi, EventBridge cetus AWS Batch jalankan analisis big-data 5 jam (Compute-Optimized C5)" → EventBridge (cron) + Batch (heavy lifter), BUKAN Lambda (15-min tak muat).

⚡ Quick Sifir — hafal ni

▪Batch SENDIRI percuma — bayar EC2/Fargate + EBS di bawah je
▪Tiada had masa (Lambda max 15 min) — sesuai job berjam-jam
▪4 komponen: Job, Job Definition, Job Queue, Compute Environment
▪Compute Environment boleh guna Spot = jimat sampai 90%
▪Keyword 'batch / queue of jobs / run-to-completion at scale' = AWS Batch
▪Satu container long-running tanpa queue = Fargate, BUKAN Batch

💡 Exam Scenario

"Company guna third-party software (Slurm/LSF/PBS) untuk manage EC2 fleet untuk batch jobs, nak switch ke AWS managed service" → AWS Batch. "Job genomics/rendering/simulation berjam-jam, banyak job beratur" → AWS Batch. "Lebih 15 minit tapi satu container je" → Fargate (bukan Lambda).

🪤 Perangkap Soalan

Q: Company guna Slurm untuk manage EC2 fleet jalankan ribuan genomics job berjam-jam dengan queue & priority. Nak switch ke AWS managed service, jimat guna Spot. Pilih?

⚠ Umpan: Lambda — sebab 'managed, no server' bunyi menarik & serverless.

✓ Betul: AWS Batch — keyword 'queue of jobs + run-to-completion at scale + Spot'. Lambda ada had 15 minit (job berjam-jam tak muat), dan tiada concept job queue/priority macam Batch.

Q: Satu container processing job yang ambil 40 minit, run satu-satu bila ada request, tiada queue banyak job. Pilih?

⚠ Umpan: AWS Batch — sebab '40 minit > 15 minit jadi bukan Lambda, mesti Batch'.

✓ Betul: Fargate — keyword 'satu container, tiada queue of jobs'. Batch sesuai bila ada MANY jobs beratur + priority. Satu long-running container tanpa queue = Fargate.

🧠 Cara Mudah Ingat

→Batch = untuk jobs yang run sampai habis (start-to-finish) di skala besar dengan queue, BUKAN continuous web workloads (itu Fargate/EC2)
→AWS Batch auto-provision compute (EC2 atau Fargate) — termasuk Spot untuk jimat sampai 90%
→Tiada had masa 15 minit macam Lambda — sebab tu Batch/Fargate jadi jawapan untuk "long-running job"
→Ingat: Batch ≠ SSM (SSM = manage existing infra). Batch ≠ Athena (Athena = query S3 data). Batch ≠ Step Functions (SF = orchestrate workflow, bukan provision compute)
→STORAGE — scratch: job dapat EBS/instance store dari Compute Environment (EC2) atau ephemeral storage (Fargate). SHARED data across banyak job → mount Amazon EFS (RWX); high-throughput HPC/genomics → FSx for Lustre. Same prinsip macam ECS/EKS: shared = EFS/FSx, scratch = EBS/ephemeral.
→PRICING: AWS Batch SENDIRI percuma — tiada caj tambahan. Kau bayar HANYA resources di bawahnya (EC2/Fargate + EBS). Guna Spot dalam Compute Environment untuk diskaun besar.

Guna Bila

Run batch / long-running compute jobs at scale without managing EC2 infrastructure

AWS Batchbatch computinglong-running jobmanagedjob queuejob definitioncompute environmentEC2 fleetFargateSpotrun to completionreplace third-partypricingjob storageEFS shared dataFSx for Lustrescratch storage

📎 What Is AWS Batch?📎 AWS Batch

D3 · High-Performing

Fargate

AWS Fargate

"Serverless CONTAINER — bawak Docker image je, tak payah ada EC2"

🎯 Sebab Apa Wujud

Fargate wujud sebab run container atas ECS/EKS guna EC2 bermakna kau kena urus host: patch OS, scale cluster, capacity planning, bin-packing task — semua ops yang membebankan. Fargate buang semua itu: kau bagi Docker image + set CPU/memory, AWS provision compute terpencil & scale auto. Zero server untuk diurus — kau fikir container je, bukan host.

Apa Dia

Fargate = serverless compute engine untuk CONTAINER (ECS & EKS). Kau bungkus app dalam Docker image, set CPU + memory per task, define networking + IAM — Fargate yang provision, run, patch & scale compute secara automatik. Tiada EC2 instance untuk kau urus. Tiap task ada isolation sendiri (tak kongsi kernel/CPU/memory/ENI dengan task lain). Bayar per vCPU + memory per SAAT masa task running.

Macam mana Fargate jalan — kau bagi image, AWS bagi compute

Docker Image

app kau (dari ECR)

Task Definition

set vCPU + memory + IAM

ECS / EKS

orchestrator

Fargate

auto-provision compute terpencil

Task Running

bayar per vCPU+mem / saat

Kau TAK pernah sentuh EC2 — no patching, no cluster scaling, no capacity planning. Fargate uruskan compute; kau urus container je. Nak murah + boleh kena interrupt? guna Fargate Spot (diskaun, amaran 2 minit sebelum reclaim).

Fargate vs Lambda — dua-dua "serverless" tapi LAIN

Aspect	Fargate	Lambda
Unit	CONTAINER (Docker image) — task/pod	FUNCTION (code handler)
Cocok untuk	App long-running: web server, API, microservice	Tugas pendek event-driven: trigger, webhook, ETL kecil
Had masa	🟢 Tiada had — boleh run 24/7	🔴 Maks 15 minit per invocation
Cetusan	Sentiasa run / desired count (ada orchestrator)	Event (S3, API Gateway, EventBridge, dll)
Scaling	Naik/turun ikut task count (autoscaling)	🟢 Auto, sampai ke ZERO, per-request
Bil	Per vCPU + memory / saat (masa running)	Per request + duration (ms)
Kawalan	Penuh atas container/OS image + networking	Minimal — AWS urus runtime

Ingat: Cara ingat: Lambda = "Fungsi pendek, event cetus, ≤15 min, scale to zero." Fargate = "Container penuh, run lama/sentiasa, no time limit." Dah ada Docker image / app run berterusan / perlu >15 min → Fargate. Cebisan code dicetus oleh event → Lambda.

3 cara run container atas AWS — siapa urus server?

Cara	Siapa urus server?	Guna bila
ECS/EKS on EC2	🔴 Kau urus EC2 (patch, scale, pack)	Nak kawal host (GPU, fleet besar steady, murah at scale)
ECS/EKS on Fargate	🟢 AWS urus (serverless)	Least ops, variable load, tak nak fikir server
Lambda	🟢 AWS urus (serverless)	Event-driven, tugas pendek ≤15 min

Ingat: "Run container, least operational overhead, no servers" → Fargate. "Need host-level control / cheapest at steady scale" → EC2 launch type. "Short event-driven function" → Lambda (bukan container).

⚡ Quick Sifir — hafal ni

▪Fargate = serverless compute untuk CONTAINER (ECS & EKS)
▪Bayar per vCPU + memory per SAAT masa task running
▪Tiada had masa — boleh run 24/7 (lawan Lambda max 15 min)
▪Fargate Spot = diskaun besar, amaran 2 minit sebelum reclaim
▪Tiap task terpencil (own kernel/CPU/memory/ENI)
▪'Run container, least ops, no servers' = Fargate; 'host-level control / murah at steady scale' = EC2 launch type

💡 Exam Scenario

"Migrate Docker app ke AWS, run berterusan, TAK nak urus EC2 langsung" → ECS/EKS on Fargate. "Job ambil masa >15 minit" → Fargate (bukan Lambda). "Resize image bila upload S3" → Lambda (event pendek). "Perlu GPU / fleet besar 24/7 paling murah" → ECS on EC2. STORAGE: "Fargate task perlu persistent shared storage" → Amazon EFS. "Perlu lebih 20 GiB scratch" → naikkan ephemeral storage (max 200 GiB).

🪤 Perangkap Soalan

Q: Migrate Docker microservice yang run berterusan (24/7) ke AWS dengan operational overhead paling minimum, tak nak urus EC2 langsung. Pilih?

⚠ Umpan: Lambda — sebab 'serverless, no infra' & dua-dua 'serverless' jadi orang campur.

✓ Betul: ECS/EKS on Fargate — keyword 'container + run berterusan + no EC2'. Lambda = FUNCTION event-driven max 15 min, bukan untuk container long-running 24/7.

Q: Workload steady 24/7 besar yang perlu paling murah per unit + kawalan host (GPU). Pilih?

⚠ Umpan: Fargate — sebab 'no server management' nampak senang & moden.

✓ Betul: ECS/EKS on EC2 — keyword 'cheapest at steady scale + host-level/GPU control'. Fargate lagi mahal per unit & tiada akses host; EC2 (+RI/SP) lebih murah untuk fleet steady.

🧠 Cara Mudah Ingat

→Fargate = serverless CONTAINER engine untuk ECS & EKS. Kau bawak image, AWS bawak compute
→Fargate Spot: diskaun besar untuk task yang tahan interrupt (amaran 2 minit) — macam Spot untuk container
→Tiap Fargate task terpencil (own kernel/CPU/memory/ENI) — tak kongsi dengan task lain
→Beza dengan Lambda: Fargate = "Full container, no time limit." Lambda = "Function, ≤15 min, event-driven, scale to zero."
→Fargate lagi mahal per unit dari EC2 reserved, tapi zero infra management — kau bayar untuk kesenangan
→STORAGE — Fargate ephemeral storage: 20 GiB default, boleh configure 20–200 GiB (ephemeralStorage), AES-256 encrypted. Ini EPHEMERAL — hilang bila task stop.
→STORAGE — Fargate persistent/shared: mount Amazon EFS (platform 1.4.0+) untuk data yang kekal & dikongsi across tasks/AZ (RWX-style). EBS volume pun boleh attach ke Fargate task untuk block storage 1-task.
→STORAGE trap: FSx for Windows / NetApp ONTAP & Docker volumes = EC2 launch type SAHAJA, tak boleh dengan Fargate. Fargate persistent shared = EFS.

Guna Bila

Run container (ECS/EKS) tanpa urus EC2 langsung

serverless containersECSEKSno EC2 managementpay per vCPU/memoryFargate Spotvs Lambdano time limitFargate storageephemeral storage20 GiB200 GiBephemeralStorageEFS volumespersistent storage

📎 AWS Fargate for Amazon ECS 📎 Fargate task ephemeral storage

D3 · High-Performing

ECR

Amazon Elastic Container Registry

"Docker Hub versi AWS — private, IAM-controlled"

🎯 Sebab Apa Wujud

ECR wujud sebab kalau kau simpan Docker image di Docker Hub (public) untuk production, ada risiko security, rate limit, dan tiada IAM control yang rapat. ECR jadi private registry dalam AWS: access ikut IAM (bukan login Docker Hub), auto-scan vulnerability, encrypt at rest dengan KMS, dan integrate native dengan ECS/EKS/Fargate supaya pull image masa launch jadi seamless & selamat.

Apa Dia

Fully managed PRIVATE container registry. Simpan & version Docker/OCI images. Integrate dengan IAM untuk access control, auto-scan vulnerability, encrypt at rest (KMS). Native dengan ECS, EKS, dan Fargate.

ECR — pecahan component (anatomy)

Registry → satu registry private per akaun AWS per region (auto-wujud)

Repository → "folder" untuk satu app/image (cth my-app), simpan banyak versi

Image tag → versi image (cth :latest, :v1.2) — tag boleh mutable atau immutable (immutable = elak orang timpa :v1

Image scanning → basic (scan masa push, guna CVE database) atau enhanced (Amazon Inspector, continuous)

Lifecycle policy → rule auto-buang image lama/untagged supaya storage tak membengkak

Replication → cross-region + cross-account (image sampai dekat dengan cluster yang pull)

Encryption → at rest dengan KMS; access via IAM + repository policy

Anatomy push → store → pull

docker build

buat image lokal

docker push

ke ECR repo (IAM auth)

ECR Repository

private · encrypted · scanned

ECS / EKS / Fargate

pull image → run task

Login dulu (ecr get-login-password), kemudian push image. ECS/EKS/Fargate akan pull dari ECR masa launch task. Lifecycle policy auto-buang image lama supaya jimat storage.

ECR vs Docker Hub — kenapa exam selalu pilih ECR

Aspect	Amazon ECR	Docker Hub
Access control	🟢 IAM + repository policy (least privilege)	Login Docker Hub (bukan IAM)
Privacy	🟢 Private by default	Public default; private repo terhad/berbayar
Vulnerability scan	🟢 Native (basic on-push / enhanced via Inspector)	Terhad / pelan berbayar
Rate limit	🟢 Tiada pull-rate cap macam Docker Hub	🔴 Anonymous/free pull di-rate-limit
AWS integration	🟢 Native ECS / EKS / Fargate, encrypt KMS	Bukan AWS-native

Ingat: "Private + IAM-controlled + vulnerability scan + native ECS/EKS" → ECR. Docker Hub kena exam sebagai umpan ("tempat simpan Docker image") tapi takda IAM, ada rate limit, scan tak native. Production AWS = ECR.

⚡ Quick Sifir — hafal ni

▪ECR = PRIVATE container registry (lawan Docker Hub public)
▪Access guna IAM, bukan login Docker Hub
▪Image scanning: basic (on push) atau enhanced (Amazon Inspector) untuk CVE
▪Encrypt at rest dengan KMS; ada cross-region & cross-account replication
▪Lifecycle policy auto-buang image lama/untagged supaya jimat storage
▪Keyword 'store container image privately untuk ECS/EKS' = ECR

💡 Exam Scenario

"Store container images untuk ECS/EKS deployment" → ECR. Bukan Docker Hub (public). ECR = private, IAM-controlled, vulnerability scanning built-in. Images auto-encrypt at rest dengan KMS.

🪤 Perangkap Soalan

Q: Company nak simpan Docker image untuk deployment ECS/EKS secara private dengan access control IAM + auto-scan vulnerability. Pilih?

⚠ Umpan: Docker Hub private repo — sebab 'tempat simpan Docker image' terus terlintas Docker Hub.

✓ Betul: Amazon ECR — keyword 'private + IAM-controlled + vulnerability scanning + ECS/EKS native'. Docker Hub bukan AWS-IAM integrated & scanning tak native.

🧠 Cara Mudah Ingat

→ECR = PRIVATE registry (lawan Docker Hub yang public). Access guna IAM, bukan login Docker Hub
→Image scanning: basic (on push) atau enhanced (guna Amazon Inspector) untuk cari CVE/vulnerability
→Lifecycle policy: auto-expire image lama / untagged supaya storage tak membengkak
→Encrypt at rest dengan KMS; ada cross-region & cross-account replication
→Exam: "store container images privately untuk ECS/EKS" → ECR. "scan image untuk vulnerability" → ECR image scanning (+ Inspector)
→PRICING: $0.10 per GB-month storage (private). Free tier: 500 MB-month private storage (12 bulan) + 50 GB-month public (forever). Pull dalam region sama = percuma; cross-region/internet = data transfer biasa. Diskaun storage guna lifecycle policy buang image lama.

Guna Bila

Simpan, version & deploy Docker image secara private dalam AWS

container registryDocker imagesprivate registryIAM integrationimage scanninglifecycle policyimmutable tagsreplicationAmazon Inspectorrate limitDocker HubKMSpricingECSEKS

📎 What is Amazon ECR?📎 ECR image scanning 📎 ECR lifecycle policies

D3 · High-Performing

Instance Store

Amazon EC2 Instance Store

"Disk sementara dalam EC2 — laju tapi data hilang bila stop"

🎯 Sebab Apa Wujud

Instance Store wujud sebab EBS adalah network-attached (lalu network) jadi ada limit IOPS & latency — tak cukup laju untuk workload yang perlukan disk SUPER pantas (scratch space HPC, shuffle Spark/Hadoop, temporary cache). Instance Store ialah disk FIZIKAL pada host server, jadi IOPS jutaan tanpa overhead network. Tukarannya: ia ephemeral — data HILANG bila stop/terminate/host fail, sebab itu hanya untuk data yang boleh rebuild.

Apa Dia

Instance store adalah ephemeral disk yang FIZIKAL berada pada host server EC2. Performance paling tinggi (NVMe, IOPS jutaan) sebab tak melalui network macam EBS. TAPI data HILANG bila instance stop, terminate, atau fail — ia tak persistent. Tak boleh detach, tak boleh snapshot, tak boleh recover.

Contoh Guna

Scratch disk untuk HPC/big data processing, temporary cache, buffer, shuffle space untuk Spark/Hadoop

Instance Store anatomy

Disk fizikal pada HOST → tak boleh detach, tak boleh pindah ke instance lain

Ephemeral → data HILANG bila instance stop/terminate/fail

NVMe atau SSD/HDD → IOPS jauh melebihi EBS (jutaan)

Kos → PERCUMA (termasuk dengan harga instance)

Size → tetap ikut instance type (tak boleh resize)

Boleh ditambah HANYA masa launch — tak boleh tambah lepas running

Instance Store vs EBS — the ephemeral vs persistent trap

Aspect	Instance Store	EBS
Data persistence	🔴 EPHEMERAL — hilang bila stop/terminate	🟢 PERSISTENT — data kekal selepas stop/start
Performance	🟢 Jutaan IOPS (fizikal NVMe)	Up to 256K IOPS (io2), 16K (gp3)
Kos	🟢 Percuma (dalam harga instance)	Bayar per GB + IOPS per bulan
Snapshot	❌ Tak boleh snapshot	🟢 Boleh snapshot ke S3
Resize	❌ Tetap ikut instance type	🟢 Elastic Volumes (resize on the fly)
Attach	Fizikal pada host — tak boleh detach	Network-attached — boleh detach/attach
Multi-Attach	❌	🟢 io1/io2 sahaja

Ingat: Nak performance maksimum + tak kisah data hilang (scratch, cache, temp) → Instance Store. Nak data kekal, boleh snapshot, boleh resize → EBS. Exam: "temporary high-IOPS storage, data can be lost" → Instance Store. "persistent storage survive reboot" → EBS.

⚡ Quick Sifir — hafal ni

▪Instance Store = disk FIZIKAL pada host = jutaan IOPS (lawan EBS network-attached)
▪EPHEMERAL: data HILANG bila stop/terminate/host fail; REBOOT = data KEKAL
▪Percuma (dah termasuk harga instance)
▪Tak boleh snapshot, tak boleh detach, tak boleh resize
▪Hanya boleh tambah masa LAUNCH; cuma instance type tertentu (m5d, r5d, i3, z1d)
▪Keyword 'high-IOPS temporary, data boleh hilang' = Instance Store; 'survive failure' = EBS

💡 Exam Scenario

"HPC workload perlu jutaan IOPS untuk scratch space, data boleh hilang takpe" → Instance Store. "Database storage mesti survive instance failure" → EBS (bukan Instance Store). "Cache yang boleh rebuild kalau hilang" → Instance Store.

🪤 Perangkap Soalan

Q: HPC workload perlu jutaan IOPS untuk scratch/shuffle space, data sementara boleh dibina semula kalau hilang. Pilih?

⚠ Umpan: EBS io2 — sebab 'IOPS tinggi' terus terfikir io2 Provisioned IOPS.

✓ Betul: Instance Store — keyword 'jutaan IOPS + scratch + data boleh hilang'. io2 max 64K IOPS & melalui network; Instance Store fizikal = jutaan IOPS, percuma, sesuai untuk scratch.

Q: Database storage MESTI survive walaupun instance stop atau host fail. Pilih?

⚠ Umpan: Instance Store — sebab 'laju' nampak bagus untuk database.

✓ Betul: EBS — keyword 'survive stop/failure (persistent)'. Instance Store EPHEMERAL: stop/terminate/host fail = data hilang. Database perlu persistent = EBS.

🧠 Cara Mudah Ingat

→Instance Store = EPHEMERAL. Stop/start EC2 → data HILANG (instance mungkin pindah ke host fizikal lain). Reboot = data KEKAL (same host).
→Tak boleh tambah instance store volume selepas instance running — mesti pilih instance type yang ada store SAAT launch.
→Instance store ada HANYA pada instance types tertentu (cth m5d, r5d, i3, z1d). Bukan semua instance type ada disk fizikal.
→Exam: "data mesti survive even if instance fails" → JANGAN guna Instance Store → EBS.
→Instance Store data hilang bila: (1) instance stop/terminate, (2) instance underlying host fails, (3) instance dipindah ke host lain. Reboot = data KEKAL.

Guna Bila

Temporary block storage physically attached to the host server — highest IOPS, zero cost

ephemeraltemporary storagehigh IOPSNVMescratch diskdata lost on stopphysically attachedno snapshotfreeHPCbig datashuffle space

📎 Amazon EC2 instance store

D3 · High-Performing

ENI/ENA/EFA

EC2 Network Interfaces — ENI · ENA · EFA

"Huruf belakang main peranan: Interface (biasa) · Adapter (laju) · Fabric (ekstrem HPC). Macam enjin kereta: Kancil → Sports Turbo → Formula 1"

🎯 Sebab Apa Wujud

Tiga jenis ni wujud sebab keperluan network EC2 berbeza-beza. ENI wujud supaya satu IP/security-group/MAC boleh dipindah antara instance (failover IP dalam subnet). ENA wujud sebab driver network biasa tak cukup untuk app moden yang perlu throughput tinggi (sampai 100 Gbps). EFA wujud sebab workload HPC/ML distributed (MPI) perlu latency super-rendah antara node — EFA bagi OS-bypass (app cakap terus dengan NIC, langkau OS network stack) untuk latency paling rendah.

Apa Dia

Tiga jenis network "kad" pada EC2: ENI (Elastic Network Interface) = kad network virtual standard, ENA (Elastic Network Adapter) = driver untuk network performance tinggi, EFA (Elastic Fabric Adapter) = kad network special untuk HPC dengan OS-bypass.

ENI vs ENA vs EFA — anatomy

ENI → Virtual network card (NIC). Boleh attach ke EC2 untuk network tambahan. Boleh ada IP private, public IP, security groups, MAC address. Boleh detach dari satu EC2 → attach ke EC2 lain (failover IP). Guna untuk: management network, NAT, bastion.

ENA → Elastic Network Adapter = driver/software untuk enable network performance tinggi pada instance yang support. Up to 100 Gbps. Dua versi: ENA (standard, sampai 25 Gbps) dan ENAv2 (sampai 100 Gbps).

EFA → Elastic Fabric Adapter = NIC special untuk HPC. Ada ENA capabilities + OS-bypass (libfabric API). Instance boleh communicate terus (bypass OS network stack) → latency rendah + throughput tinggi untuk message passing (MPI, CUDA). Hanya Linux.

Analogi: Jenis enjin kereta (Kancil → Sports → F1)

Rendering diagram…

INGAT exam: huruf belakang main peranan — Interface (biasa, pindah IP) · Adapter (laju, 10–100 Gbps) · Fabric (ekstrem HPC, OS-bypass). Soalan sebut HPC / MPI / ultra-low latency / OS bypass → EFA, JANGAN tertipu pilih ENA.

ENI vs ENA vs EFA — macam mana pilih

Aspect	ENI	ENA	EFA
Apakah dia	Virtual NIC (network card)	Network driver/adapter	HPC network adapter + OS-bypass
Performance	Standard (1–10 Gbps)	High (up to 25 Gbps), ENAv2 up to 100 Gbps	Highest (up to 100 Gbps) + lowest latency
OS-bypass	❌	❌	🟢 Ya (libfabric, MPI, CUDA direct)
Best untuk	Standard networking, management, NAT, failover IP	High-throughput apps, most modern instance types	HPC, ML distributed training, tightly-coupled cluster workloads
Platform	Semua instance types	Most modern instance types (c5, m5, r5…)	Hanya HPC-optimized (c5n, p4d, hpc6a…), Linux only

Ingat: Standard networking + failover → ENI. Network performance tinggi untuk app biasa → ENA (dah default pada most modern instances). HPC + MPI + ML distributed training + lowest latency → EFA. Exam: "HPC cluster need lowest latency inter-node communication" → EFA.

⚡ Quick Sifir — hafal ni

▪ENI = virtual NIC, boleh detach & pindah ke EC2 lain (failover IP private)
▪ENA = driver high-throughput, sampai 25 Gbps (ENAv2 sampai 100 Gbps), default most modern instances
▪EFA = ENA + OS-bypass (libfabric/MPI) = latency paling rendah, HPC only, Linux only
▪Keyword 'lowest latency inter-node HPC / MPI / distributed ML' = EFA
▪EFA + Cluster Placement Group = combo HPC dalam same AZ
▪EFA Linux sahaja (Windows tak support OS-bypass)

💡 Exam Scenario

"HPC cluster dengan MPI, perlu lowest latency inter-node" → EFA. "Failover IP — pindah ENI dari EC2 mati ke EC2 baru" → ENI. "App biasa perlukan network lebih laju dari standard" → instance dengan ENA (default on modern types).

🪤 Perangkap Soalan

Q: HPC cluster jalankan MPI distributed ML training, perlu latency paling rendah antara node yang tightly-coupled. Pilih adapter?

⚠ Umpan: ENA — sebab 'high performance network' nampak macam jawapan paling laju.

✓ Betul: EFA (Elastic Fabric Adapter) — keyword 'lowest latency + MPI + tightly-coupled HPC'. ENA laju tapi tiada OS-bypass; hanya EFA bagi OS-bypass untuk latency paling rendah inter-node.

Q: EC2 di subnet failover — bila instance utama mati, alamat IP private mesti pindah cepat ke instance standby. Guna apa?

⚠ Umpan: Tukar IP guna ENA — sebab orang ingat ENA = 'network adapter' jadi boleh urus IP.

✓ Betul: ENI (Elastic Network Interface) — detach ENI dari instance mati, attach ke standby = IP private ikut sama. ENA cuma driver throughput, bukan untuk pindah IP.

🧠 Cara Mudah Ingat

→ENI boleh pindah antara instances — attach ENI ke EC2 baru untuk failover IP. Ini cara failover IP private dalam subnet.
→ENA dah default pada hampir semua instance type moden (c5, m5, r5, dll). ENAv2 (up to 100 Gbps) pada select types.
→EFA = ENA + OS-bypass. OS-bypass = app access network card TERUS tanpa OS overhead → latency paling rendah untuk HPC/MPI.
→EFA hanya Linux (Windows tak support OS-bypass). EFA hanya pada HPC-optimized instance types.
→Placement Group Cluster + EFA = combo untuk HPC (low latency + high throughput antara nodes dalam same AZ).
→Exam: "MPI / distributed ML training / lowest latency / tightly-coupled HPC inter-node" → EFA (bukan ENA, bukan ENI).
→PRICING: ENI, ENA, dan EFA semua FREE — takde caj tambahan untuk adapter itu sendiri. Kau bayar untuk EC2 instance + data transfer macam biasa. (Note: ENI ada had IP private/instance ikut instance type; secondary ENI yang attach guna IP dalam VPC kau, bukan caj berasingan.)

Guna Bila

Network connectivity dan performance — pilih ikut keperluan (standard vs high-throughput vs HPC)

ENIENAEFAnetwork interfacevirtual NICOS-bypasslibfabricMPIHPC networkinglow latencyultra-low latencyenhanced networkinghigh throughputfailover IPdetach attach100 Gbpsplacement group clustermachine learning trainingtightly-coupledpricing

📎 Elastic Network Interfaces (ENI)📎 Elastic Fabric Adapter (EFA)

D3 · High-Performing

Lambda@Edge

AWS Lambda@Edge

"Lambda yang jalan di CloudFront edge — code dekat dengan user, bukan di region"

🎯 Sebab Apa Wujud

Lambda@Edge wujud sebab logik customize request/response (auth, redirect, A/B test, URL rewrite, header inject) kalau buat di origin region akan tambah latency untuk user yang jauh. Lambda@Edge run code di CloudFront edge location (dekat user) supaya keputusan dibuat dekat user — laju. Ia juga benarkan logik kompleks yang panggil AWS service (DynamoDB/S3) di edge, sesuatu yang CloudFront Functions (lightweight) tak boleh buat.

Apa Dia

Lambda@Edge jalankan Lambda function di CloudFront edge locations (600+ globally). Function execute dekat dengan user — bukan di AWS region. Empat trigger points: Viewer Request, Viewer Response, Origin Request, Origin Response. Boleh ubah request/response, custom auth, URL rewrite, A/B testing.

Contoh Guna

Custom auth header check di edge, A/B testing redirect, rewrite URL dari old ke new path, inject custom HTTP headers

4 trigger points — bila function jalan

Viewer Request → bila user hantar request ke CloudFront (sebelum cache check). Boleh inspect/modify request, redirect.

Viewer Response → sebelum CloudFront hantar response ke user. Boleh modify headers, inject content.

Origin Request → bila cache MISS, sebelum CloudFront hantar request ke origin. Boleh rewrite path, pilih origin.

Origin Response → selepas origin reply, sebelum cache. Boleh modify response dari origin.

4 trigger points — di mana function intercept

Rendering diagram…

Viewer events = dekat dengan user (boleh di semua edge). Origin events = hanya di edge yang MISS cache. Empat chances untuk ubah request/response. INGAT exam: "modify HTTP headers at edge" → CloudFront Functions atau Lambda@Edge Viewer Request.

Lambda@Edge vs CloudFront Functions — dua-dua "code at edge"

Aspect	Lambda@Edge	CloudFront Functions
Bahasa	Node.js, Python	JavaScript (lightweight)
Runtime	Full Lambda runtime (Node.js/Python)	Ultra-lightweight JS (subset)
Execution time	Up to 5 sec (viewer), 30 sec (origin)	Up to 1 ms (sub-millisecond)
Memory	128 MB – 10 GB	2 MB only
Boleh panggil AWS?	🟢 Ya (S3, DynamoDB, dll)	❌ Tak boleh (no network/file access)
Network access	🟢 Ya	❌ No
Kos	Bayar per request + duration	🟢 Lebih murah — per invocation (flat)
Best untuk	Complex logic, AWS API calls, heavy transform	Simple header manipulation, URL rewrite, auth token check

Ingat: Simple lightweight (header rewrite, token check) → CloudFront Functions. Complex logic + panggil AWS services + Node.js/Python → Lambda@Edge. "Inspect request, call DynamoDB, return custom response at edge" → Lambda@Edge.

⚡ Quick Sifir — hafal ni

▪Lambda@Edge = Node.js/Python di CloudFront edge; deploy di us-east-1, CloudFront auto-replicate
▪4 trigger: Viewer Request, Viewer Response, Origin Request, Origin Response
▪Boleh panggil AWS services (DynamoDB/S3) + ada network access
▪CloudFront Functions = JS sub-ms, 2MB, NO network, NO AWS calls — lebih murah & laju untuk header/URL rewrite ringkas
▪Viewer events = semua edge; Origin events = hanya bila cache MISS
▪Keyword 'code at edge + call AWS service' = Lambda@Edge; 'simple header/URL rewrite' = CloudFront Functions

💡 Exam Scenario

"Custom authentication check HTTP header bila user request CloudFront" → Lambda@Edge Viewer Request. "Simple rewrite URL from /old to /new at edge, no AWS API calls" → CloudFront Functions. "A/B test — redirect 10% users to new origin" → Lambda@Edge.

🪤 Perangkap Soalan

Q: Nak run custom code di CloudFront edge yang perlu query DynamoDB untuk authorize setiap request. Pilih?

⚠ Umpan: CloudFront Functions — sebab 'code at edge' & lebih murah/laju nampak menarik.

✓ Betul: Lambda@Edge — keyword 'call DynamoDB / AWS service at edge'. CloudFront Functions tiada network access & tak boleh panggil AWS service; hanya Lambda@Edge boleh.

Q: Simple rewrite header / redirect URL di edge, sub-millisecond, tiada panggilan AWS, nak paling murah. Pilih?

⚠ Umpan: Lambda@Edge — sebab 'run code at edge' biasa terus terfikir Lambda@Edge.

✓ Betul: CloudFront Functions — keyword 'simple header/URL rewrite + sub-ms + no AWS call + cheapest'. Lambda@Edge overkill & lagi mahal untuk transform ringkas.

🧠 Cara Mudah Ingat

→Lambda@Edge function mesti di-deploy di us-east-1 (CloudFront manages replication to all edges).
→Viewer Request/Response = jalan di SEMUA edge locations (close to user). Origin Request/Response = jalan hanya di edge yang MISS cache.
→Lambda@Edge boleh guna IAM role → boleh panggil AWS services (DynamoDB, S3, SSM). CloudFront Functions TAK boleh.
→CloudFront Functions: sub-millisecond, max 1ms, no network → untuk simple header manipulation, URL rewrite, token validation.
→Exam: "run custom code at CloudFront edge, need to access DynamoDB" → Lambda@Edge (bukan CloudFront Functions).
→Lambda@Edge vs standard Lambda: standard Lambda jalan di satu region; Lambda@Edge jalan secara global di semua edge locations. Function deploy di us-east-1, CloudFront auto-replicate.

Guna Bila

Run Lambda functions AT CloudFront edge locations — customize content delivery closer to users

Lambda@Edgeedge computingCloudFrontViewer RequestViewer ResponseOrigin RequestOrigin ResponseCloudFront FunctionsA/B testingcustom authURL rewriteus-east-1Node.jsPythonlightweight JS

📎 Lambda@Edge overview 📎 CloudFront Functions vs Lambda@Edge

D3 · High-Performing

EC2 Tenancy

EC2 Tenancy & Dedicated Hosts

"Shared = ramai kongsi. Dedicated Instance = hardware sendiri tapi tak pilih physical. Dedicated Host = physical server sendiri, boleh lihat socket/core untuk lesen BYOL"

🎯 Sebab Apa Wujud

Tenancy options wujud sebab keperluan isolation & licensing berbeza. Shared (default) cukup & murah untuk kebanyakan workload. Dedicated Instance wujud bila compliance kata hardware mesti single-tenant (kau sahaja, tiada pelanggan lain kongsi). Dedicated Host wujud sebab licensing BYOL (Oracle, SQL Server, Windows) sering ikut socket/core fizikal — kau perlu NAMPAK & kawal physical server (socket, core, host ID) untuk audit license compliance, sesuatu yang shared/dedicated instance tak bagi.

Apa Dia

Tiga tahap tenancy: (1) Shared (default) — instance jalan pada hardware shared dengan pelanggan lain. (2) Dedicated Instance — instance jalan pada hardware single-tenant (kau sahaja) tapi kau tak pilih server mana. (3) Dedicated Host — physical server penuh untuk kau, kau nampak socket/core, boleh guna untuk BYOL (bring-your-own-license) software.

Contoh Guna

Oracle/SQL Server license guna BYOL — perlu nampak physical socket/core → Dedicated Host. Compliance perlu single-tenant hardware tapi tak kisah server mana → Dedicated Instance. Workload biasa → Shared (murah).

3 tenancy levels — isolation vs kos

Aspect	Shared (default)	Dedicated Instance	Dicated Host
Hardware	Shared dengan pelanggan lain	Single-tenant (kau sahaja)	Physical server penuh untuk kau
Boleh pilih server?	❌	❌ (AWS pilih)	🟢 Ya — kau nampak socket, core, host ID
BYOL support	❌	❌	🟢 Ya — audit socket/core untuk license compliance
Kos	🟢 Standard On-Demand/RI/SP	+ $2/jam region fee (per-instance)	💰 Paling mahal — bayar per-host
Affinity	N/A	N/A	🟢 Boleh set host affinity (instance sentiasa pada host yang sama)
Best untuk	Workload biasa, tak perlu isolation	Compliance perlu single-tenant, tak perlu audit	BYOL (Oracle, SQL Server), license compliance, audit socket/core

Ingat: Biasa → Shared. Perlu single-tenant tapi tak perlu pilih server → Dedicated Instance. Perlu physical server + nampak socket/core + BYOL → Dedicated Host. Exam: "Oracle license BYOL, need to track physical cores" → Dedicated Host.

⚡ Quick Sifir — hafal ni

▪Shared (default) = kongsi hardware, paling murah
▪Dedicated Instance = single-tenant, AWS pilih server, +$2/jam region fee
▪Dedicated Host = physical server penuh, nampak socket/core/host ID, paling mahal
▪BYOL (Oracle/SQL Server) + audit socket/core = Dedicated Host
▪Host Affinity = instance sentiasa pada host fizikal sama (untuk license tied to hardware)
▪Dedicated Host billing per-HOST; Dedicated Instance per-instance

💡 Exam Scenario

"Company guna Oracle database dengan BYOL license, perlu audit physical cores untuk compliance" → Dedicated Host. "Compliance policy: instances must be on single-tenant hardware, no sharing" → Dedicated Instance. "Just run a web server, cheapest option" → Shared (default tenancy).

🪤 Perangkap Soalan

Q: Company guna Oracle DB dengan BYOL license yang dikira ikut physical core/socket, perlu audit hardware untuk compliance. Pilih tenancy?

⚠ Umpan: Dedicated Instance — sebab 'single-tenant hardware' bunyi padan untuk license/compliance.

✓ Betul: Dedicated Host — keyword 'BYOL + visibility socket/core + audit hardware'. Dedicated Instance single-tenant TAPI kau tak nampak physical socket/core; hanya Dedicated Host bagi visibility untuk BYOL audit.

Q: Policy compliance kata instance mesti pada single-tenant hardware (tiada pelanggan lain kongsi), tapi tak perlu pilih server / audit core. Pilih paling kos-efektif?

⚠ Umpan: Dedicated Host — sebab 'single-tenant, fully isolated' nampak paling selamat.

✓ Betul: Dedicated Instance — keyword 'single-tenant TAPI tak perlu audit core/pilih server'. Dedicated Host lebih mahal (per-host) & overkill bila tak perlu visibility socket/core.

🧠 Cara Mudah Ingat

→Dedicated Host: kau LIHAT physical attributes (sockets, cores, host ID) → essential untuk BYOL license audit (Oracle, SQL Server, Windows)
→Dedicated Instance: single-tenant tapi AWS pilih hardware mana — kau tak nampak server fizikal. Ada $2/jam per-region fee.
→Dedicated Host boleh set HOST AFFINITY — instance sentiasa attach ke physical host yang sama. Berguna untuk license yang tie ke hardware.
→Dedicated Host juga boleh guna RI/SP → lebih jimat dari On-Demand Dedicated Host.
→Exam keyword: "BYOL", "physical core/socket visibility", "existing license tied to physical hardware" → Dedicated Host.
→Dedicated Host billing: per-host, bayar kadar jam untuk setiap host. Bukan per-instance.

Guna Bila

Pilih tahap isolation hardware — shared vs dedicated instance vs dedicated host

tenancyshareddedicated instancededicated hostsingle-tenantBYOLbring your own licenseOracleSQL Serversocketcorehost affinitylicense compliancephysical server

📎 Dedicated Hosts overview 📎 Dedicated Instances