Design Cost-Optimized Architectures

← Deep Notes D1 · Secure D2 · Resilient D3 · High-Performing D4 · Cost-Optimized Framework + Extras

DOMAIN 4 · 20% OF EXAM

Design Cost-Optimized Architectures

Pricing Models · Storage · Networking · Database

💰EC2 Pricing Models↑ Top

D4 · Cost-Optimized

On-Demand

EC2 On-Demand Instances

"Bayar ikut jam, bila-bila boleh stop"

🎯 Sebab Apa Wujud

Wujud sebab kadang kau memang TAK tahu berapa lama atau berapa banyak compute kau perlu (startup baru, dev/test, beban spiky) — commit 1-3 tahun (RI/SP) jadi membazir kalau beban berubah. On-Demand bagi kau guna-bayar-ikut-jam tanpa komitmen, hilang risiko terlock pada kapasiti yang kau tak guna.

Apa Dia

Menyediakan kapasiti compute tanpa komitmen jangka panjang pada kadar tetap per jam

EC2 purchasing options — pick per workload

Option	Discount	Commit	Best for
On-Demand	None (most $)	None	Spiky / unknown / short-term
Reserved Instances	Up to 72%	1 or 3 yr (instance type)	Steady 24/7 predictable workload
Savings Plans	Up to 66%	1 or 3 yr ($/hr spend)	Steady but want flexibility (any type/region)
Spot	Up to 90%	None (interruptible)	Fault-tolerant batch / can resume

Ingat: "Steady 24/7" → RI/Savings Plan. "Flexible across instance types" → Savings Plan. "Interruptible batch" → Spot. "Unpredictable / short-term" → On-Demand. NEVER Spot for critical stateful prod.

⚡ Quick Sifir — hafal ni

▪On-Demand = no commitment, paling fleksibel, paling MAHAL per jam
▪Billing per-second (Linux, min 60s); per-hour (Windows)
▪Guna bila: spiky / unknown / short-term / dev-test
▪Steady 24/7 → RI/Savings Plans (bukan On-Demand)
▪Fault-tolerant batch + termurah → Spot (bukan On-Demand)

💡 Exam Scenario

Startup baru launch app, tak tahu lagi berapa traffic. Atau developer nak test environment kejap je — tak nak commit lama.

🪤 Perangkap Soalan

Q: Startup baru launch app, tak pasti traffic, nak elak terlock komitmen. Pricing model mana mula-mula?

⚠ Umpan: Reserved Instances 1-tahun untuk 'jimat' — nampak murah, tapi kalau traffic tak menentu / instance type berubah, RI jadi membazir sebab dah commit.

✓ Betul: On-Demand dulu sampai pattern stabil, baru tukar ke RI/Savings Plans. Keyword: 'unpredictable', 'short-term', 'no commitment', 'startup baru'.

🧠 Cara Mudah Ingat

→PRICING: On-Demand = baseline (paling mahal per jam, takde diskaun). Contoh t3.medium Linux ~$0.0416/jam. Billing per-SECOND untuk Linux (minimum 60 saat); per-HOUR untuk Windows & sesetengah Marketplace AMI. Untuk diskaun → RI / Savings Plans (steady) atau Spot (interruptible).
→Per-second billing (Linux) bermakna kalau instance jalan 90 saat, kau bayar 90 saat je (lepas min 60s) — bagus untuk beban pendek/spiky. Windows dibulatkan ke jam penuh.
→On-Demand = baseline harga yang semua diskaun (RI/SP/Spot) dikira relatif kepadanya. Untuk perbandingan 4 model penuh + decision tree, tengok card "Savings Plans" (anchor EC2 purchasing).
→On-Demand Capacity Reservation (ODCR) = reserve kapasiti dalam satu AZ tanpa komitmen 1-3 tahun (bayar On-Demand rate walaupun tak guna). Beza dengan Zonal RI yang gabung capacity reservation + diskaun. Keyword "guaranteed capacity tanpa long-term commitment" → ODCR.

Guna Bila

Workload tak menentu, short-term, testing

no commitmentflexibleshort-termhighest costper-second billingper-hour billingpricingOn-Demand Capacity ReservationODCRguaranteed capacity

📎 EC2 On-Demand pricing & billing 📎 On-Demand Capacity Reservations

D4 · Cost-Optimized

Reserved Instances

EC2 Reserved Instances (RI)

"Commit 1-3 thn → diskaun sampai 72%. Standard = murah-tegar, Convertible = fleksibel-kurang"

🎯 Sebab Apa Wujud

Wujud sebab beban yang jalan 24/7 sepanjang tahun (cth database production) bayar harga penuh On-Demand = membazir. RI bagi kau commit 1-3 tahun pada config tertentu tukar diskaun sampai 72%, dan Zonal RI lagi bagi jaminan kapasiti dalam AZ supaya kau tak gagal launch instance bila region sibuk.

Apa Dia

Komitmen 1 atau 3 tahun pada konfigurasi instance tertentu → diskaun sampai 72% vs On-Demand. Dua kelas: Standard (diskaun besar, boleh MODIFY AZ/saiz dalam family, boleh jual di RI Marketplace) dan Convertible (diskaun kurang, boleh EXCHANGE tukar family/OS/tenancy). Scope: Regional (fleksibel AZ, no capacity reservation) atau Zonal (lock 1 AZ + capacity reservation).

Standard vs Convertible RI

Aspect	Standard RI	Convertible RI
Diskaun	🟢 Sampai 72%	Sampai 66% (kurang sikit)
Tukar instance family/OS	❌ Tak boleh	🟢 Boleh exchange
Modify AZ / saiz dalam family	✅ Boleh	✅ Boleh
Jual di RI Marketplace	🟢 Boleh	❌ Tak boleh
Best bila	Konfigurasi takkan berubah, nak diskaun max	Mungkin perlu tukar family/OS kemudian

Ingat: Pasti tak berubah + diskaun max → Standard. Nak fleksibiliti tukar family/OS → Convertible. Tapi kalau nak fleksibel SAMBIL auto-apply tanpa exchange manual → consider Savings Plans.

Payment options (sama untuk Standard & Convertible)

Bayaran	Diskaun	Bila pilih
All Upfront	🟢 Paling tinggi	Ada cash, nak jimat maksimum
Partial Upfront	Pertengahan	Imbang cash flow vs diskaun
No Upfront	Paling rendah	Tak nak bayar awal, masih commit 1-3 thn

Ingat: Lagi banyak bayar awal = lagi besar diskaun. All Upfront 3-tahun Standard RI = diskaun paling besar yang ada (~72%).

⚡ Quick Sifir — hafal ni

▪RI = commit 1/3 tahun pada instance config → diskaun sampai 72%
▪Standard RI = diskaun max tapi TAK boleh tukar family (boleh modify saiz/AZ dalam family)
▪Convertible RI = boleh EXCHANGE family/OS/tenancy, diskaun kurang (sampai 66%)
▪Regional RI = fleksibel AZ tapi NO capacity reservation; Zonal RI = lock 1 AZ + capacity reservation
▪Payment: All Upfront > Partial > No Upfront (ikut diskaun)
▪Billing apply order: RI dulu, baru Savings Plans
▪'flexibility' tanpa exchange manual → Savings Plans, bukan RI

💡 Exam Scenario

"Database 24/7 sepanjang tahun, instance type takkan berubah, nak diskaun maksimum" → Standard RI (3-tahun All Upfront). "Steady tapi mungkin tukar instance family tahun depan" → Convertible RI. "Perlu jaminan kapasiti dalam AZ tertentu" → Zonal RI (regional RI TIDAK reserve capacity).

🪤 Perangkap Soalan

Q: Database 24/7 sepanjang tahun, instance type takkan berubah, nak diskaun MAKSIMUM. Pilih apa?

⚠ Umpan: Convertible RI — nampak 'lagi bagus sebab fleksibel', tapi Convertible diskaun KURANG; kalau config memang takkan berubah, fleksibiliti tu tak berguna dan kau rugi diskaun.

✓ Betul: Standard RI (3-tahun All Upfront) — diskaun paling besar (~72%) bila config tetap. Keyword: 'config takkan berubah', 'diskaun maksimum', '24/7'.

Q: Perlu JAMINAN kapasiti EC2 dalam satu AZ tertentu untuk DR. RI jenis mana?

⚠ Umpan: Regional RI — orang sangka semua RI reserve capacity, tapi Regional RI TIDAK bagi capacity reservation (cuma billing discount fleksibel merentas AZ).

✓ Betul: Zonal RI — lock satu AZ DAN dapat capacity reservation. Keyword: 'capacity reservation', 'specific AZ', 'guaranteed capacity'.

🧠 Cara Mudah Ingat

→Standard RI = diskaun lebih besar tapi TAK boleh tukar instance family. Convertible RI = boleh exchange family/OS/tenancy tapi diskaun kurang.
→Regional RI (default, disyorkan): apply ke mana-mana AZ dalam region, boleh modify, TAPI tiada capacity reservation. Zonal RI: lock satu AZ + dapat capacity reservation.
→Payment: All Upfront > Partial Upfront > No Upfront (ikut saiz diskaun). Term: 3 tahun > 1 tahun.
→RI vs Savings Plans: RI lock pada instance config (atau exchange manual untuk Convertible). Savings Plans commit $/jam, auto-apply lebih fleksibel — exam selalu pilih Savings Plans bila soalan tekankan "flexibility".
→RI bukan cuma EC2 — ada juga untuk RDS, Redshift, ElastiCache, OpenSearch.
→Billing order: RI diapply DULU, baru Savings Plans (EC2 Instance SP → Compute SP) pada usage yang tinggal.

Guna Bila

Workload steady predictable 24/7 untuk 1-3 tahun

1 or 3 yearup to 72% discountStandard RIConvertible RIexchangemodifyAll UpfrontPartial UpfrontNo UpfrontRegional RIZonal RIcapacity reservationRI Marketplace

📎 Reserved Instance types (Standard vs Convertible)

D4 · Cost-Optimized

Spot Instances

EC2 Spot Instances

"Kapasiti EC2 lebihan, sampai 90% murah — tapi AWS boleh ambil balik dengan notis 2 minit"

🎯 Sebab Apa Wujud

Wujud sebab AWS ada kapasiti EC2 LEBIHAN yang terbiar — daripada idle, AWS jual murah (sampai 90% off). Tukarannya AWS boleh ambil balik bila perlu (notis 2 minit). Ini buang kos besar untuk beban yang fault-tolerant / boleh resume — kau bayar harga rendah sebab kau sanggup terima risiko interrupt.

Apa Dia

Guna kapasiti EC2 yang tidak digunakan pada harga sehingga 90% lebih murah dari On-Demand. Tukaran-nya: AWS boleh INTERRUPT (ambil balik) instance bila perlukan kapasiti semula, dengan notis 2 minit sahaja. Sebab tu sesuai untuk beban yang fault-tolerant / boleh resume, BUKAN untuk server kritikal yang stateful.

Macam mana dapat notis interrupt

Notis interrupt 2 minit datang melalui DUA saluran: (1) EventBridge event "EC2 Spot Instance Interruption Warning" (detail-type), dan (2) instance metadata pada instance itu sendiri. Best practice: poll metadata setiap 5 saat. Ada juga Rebalance Recommendation — signal AWAL sebelum notis 2 minit, bagi peluang pindahkan beban lebih cepat. NOTA: kalau interruption behavior = hibernate, kau dapat notis tapi BUKAN 2 minit awal (hibernate mula serta-merta).

Analogi — Spot = tiket kapal terbang "standby"

Rendering diagram…

Spot = tiket standby kapal terbang: kerusi kosong dilelong 90% murah, tapi kalau VIP (pelanggan On-Demand bayar penuh) datang, kau kena turun dengan notis 2 minit. On-Demand = tiket biasa: kerusi hak kau, takde sapa halau. INGAT exam: "fault-tolerant + lowest cost" → Spot (sanggup kena halau); "critical/stateful tak boleh putus" → On-Demand/RI (kerusi terjamin).

Provision Spot dengan resilien (Fleet & Auto Scaling)

Rendering diagram…

EC2 Fleet/Spot Fleet atau ASG Mixed Instances Policy = sebar merentas banyak instance type & AZ supaya kalau satu pool kena ambil balik, yang lain sambung. capacity-optimized = ambil dari pool paling banyak kapasiti (kurang interrupt). price-capacity-optimized = pilihan default disyorkan (imbang murah + kurang interrupt).

Spot interruption behaviors + bila guna apa

Behavior	Apa jadi bila interrupt	Syarat / nota
Terminate (default)	Instance ditamatkan terus	Default. Beban stateless / boleh start fresh
Stop	Instance di-stop, EBS dikekalkan	Request type mesti persistent (Fleet: maintain). Hanya AWS boleh restart bila kapasiti ada balik
Hibernate	RAM disimpan ke EBS, resume balik	Dapat notis tapi TIADA 2-minit awal (hibernate mula serta-merta)

Ingat: Default = terminate. Nak simpan EBS & sambung kerja → stop (persistent/maintain). Nak resume state RAM → hibernate. Soalan "resume work after interruption" → stop/hibernate, bukan terminate.

Fleet — EC2 Fleet vs Spot Fleet vs ASG Mixed Instances Policy

Pilihan	Apa dia ("Fleet" = sekumpulan instance diurus jadi satu)	Bila guna
EC2 Fleet	Satu request minta kombinasi On-Demand + Spot merentas BANYAK instance type/saiz/AZ. Kawalan penuh, TIADA auto-scaling sendiri	Nak provision kapasiti gabungan sekali-shot (cth HPC/batch besar), tak perlu scale ikut trafik
Spot Fleet	Versi lama/awal — fokus urus kumpulan Spot (boleh campur sikit On-Demand) ikut target capacity/bajet	Legacy — AWS sekarang sorong ke EC2 Fleet. Elak untuk projek baru
ASG Mixed Instances Policy	Auto Scaling Group campur On-Demand (baseline stabil) + Spot (jimat), naik/turun ikut trafik	🟢 Paling biasa & disyorkan: nak AUTO-SCALING + jimat Spot serentak

Ingat: Semua tujuan sama: sebar banyak instance type/AZ supaya tahan interrupt. Nak auto-scaling + campur Spot → ASG Mixed Instances Policy. Nak satu-shot kapasiti gabungan tanpa scaling → EC2 Fleet. Spot Fleet = legacy (EC2 Fleet ganti). INGAT: "Fleet" = pakej borong sekumpulan server campuran diurus sebagai satu.

⚡ Quick Sifir — hafal ni

▪Spot = sampai 90% murah, no commitment, TAPI boleh di-interrupt (notis 2 MINIT)
▪Notis 2 minit datang via EventBridge event DAN instance metadata (poll ~5 saat)
▪Interruption behavior: terminate (default), stop (perlu persistent/maintain), hibernate (tiada 2-min awal)
▪Capacity Rebalancing = ganti instance berisiko AWAL sebelum notis 2 minit penuh
▪price-capacity-optimized = strategi allocation default disyorkan AWS
▪EC2 Fleet/Spot Fleet/ASG Mixed = sebar banyak type+AZ supaya tahan interrupt
▪JANGAN Spot untuk: DB stateful, production kritikal, payment service

💡 Exam Scenario

"Batch processing / big data / render farm yang boleh interrupt & resume" → Spot, jimat besar. "Production database / stateful app / payment service yang TAK boleh putus" → JANGAN Spot, guna On-Demand atau RI/Savings Plans. Soalan tekan "fault-tolerant + lowest cost" hampir mesti = Spot.

🪤 Perangkap Soalan

Q: Beban batch big-data yang boleh interrupt & resume, nak kos PALING rendah. Pricing mana?

⚠ Umpan: Reserved Instances / Savings Plans — nampak 'jimat jadi pilih commit', tapi untuk batch fault-tolerant, Spot jauh lebih murah (90% vs 72%) dan interrupt tak jadi masalah.

✓ Betul: Spot Instances — 'fault-tolerant + lowest cost' hampir mesti Spot. Keyword: 'fault-tolerant', 'batch', 'can resume', 'lowest cost'.

Q: Spot workload perlu SAMBUNG kerja (resume state) selepas di-interrupt, bukan start fresh. Interruption behavior mana?

⚠ Umpan: Terminate (default) — biar default, tapi terminate buang instance terus, kerja hilang, kena start dari awal.

✓ Betul: Stop (request persistent/Fleet maintain) untuk kekalkan EBS, atau Hibernate untuk simpan RAM. Keyword: 'resume work after interruption', 'preserve state'.

🧠 Cara Mudah Ingat

→Notis interrupt = 2 MINIT, dihantar via EventBridge event DAN instance metadata. Poll metadata setiap ~5 saat. (Exam selalu tanya angka 2 minit ni.)
→Interruption behaviors: terminate (default), stop, hibernate. Stop perlu request persistent / Fleet maintain. Hibernate dapat notis tapi tak ada 2-minit awal.
→EC2 Fleet & Spot Fleet: minta kapasiti merentas BANYAK instance type, saiz & AZ dalam satu request → lebih tahan interrupt. Spot Fleet boleh campur Spot + On-Demand juga.
→Auto Scaling Mixed Instances Policy: satu ASG campur On-Demand (baseline stabil) + Spot (jimat). Letak % On-Demand sebagai baseline, selebihnya Spot.
→Allocation strategy capacity-optimized = ambil Spot dari pool dengan kapasiti paling banyak → kurang kemungkinan interrupt (bagus untuk beban yang mahal kalau interrupt). price-capacity-optimized = default disyorkan AWS (imbang harga + kapasiti).
→Capacity Rebalancing (rebalance recommendation): ASG/Fleet ganti instance yang BERISIKO TINGGI interrupt secara proaktif, sebelum notis 2 minit penuh.
→JANGAN guna Spot untuk: database stateful, production kritikal, beban yang tak boleh putus / tak boleh resume. Untuk itu → On-Demand / RI / Savings Plans.

Guna Bila

Batch jobs, fault-tolerant & stateless workloads, flexible timing

up to 90% discountinterruptible2-minute interruption noticeEventBridgeinstance metadatarebalance recommendationterminatestophibernatepersistent requestSpot FleetEC2 Fleetmixed instances policycapacity-optimizedprice-capacity-optimizedcapacity rebalancingfault-tolerantbatch jobs

📎 Spot Instance interruption notices (2-min)📎 Behavior of Spot Instance interruptions 📎 EC2 Fleet / Spot Fleet allocation strategies

D4 · Cost-Optimized

Savings Plans

AWS Savings Plans (SP)

"Commit $/jam, bukan instance. Compute = paling fleksibel (+Fargate/Lambda), EC2 Instance = diskaun lebih besar"

🎯 Sebab Apa Wujud

Wujud sebab RI lock kau pada instance config tertentu — kalau kau tukar family/region atau guna Fargate/Lambda, RI tak apply dan kau kena exchange manual. Savings Plans commit pada $/jam belanja compute je, jadi diskaun AUTO-apply merentas instance, region, dan termasuk Fargate + Lambda — hilang kerja urus exchange tiap kali beban berubah.

Apa Dia

Komitmen pada jumlah belanja compute ($/jam) untuk 1 atau 3 tahun → diskaun auto-apply. Dua jenis: Compute Savings Plans (paling fleksibel — apply ke mana-mana instance family, saiz, OS, tenancy, region, dan TERMASUK Fargate & Lambda; sampai 66%) dan EC2 Instance Savings Plans (commit pada satu instance family dalam satu region; diskaun lebih besar sampai 72% tapi kurang fleksibel).

Pilih EC2 purchasing option (decision tree)

Rendering diagram…

Boleh interrupt → Spot. Tak predictable → On-Demand. Predictable + fleksibel (+Fargate/Lambda) → Compute SP. Predictable + lock family untuk diskaun max → EC2 Instance SP / Standard RI. Soalan tekan "flexibility" biasanya = Savings Plans (bukan RI).

4 EC2 pricing models — pick per workload (overview)

Model	Komitmen	Diskaun	Boleh interrupt?	Guna bila
On-Demand	Tiada	Baseline (paling mahal)	Tak	Spiky / short-term / tak predictable / dev-test
Spot	Tiada	🟢 Sampai 90%	🔴 Ya (notis 2 min)	Fault-tolerant batch, stateless, masa fleksibel
Savings Plans	$/jam · 1-3 thn	Sampai 66-72%	Tak	Steady spend + nak fleksibel (auto-apply, +Fargate/Lambda)
Reserved Instances	Instance config · 1-3 thn	Sampai 72%	Tak	Steady 24/7 config tetap; perlu capacity reservation (Zonal)

Ingat: Boleh interrupt + termurah → Spot. Tak predictable → On-Demand. Steady + fleksibel → Savings Plans. Steady config tetap / perlu capacity reservation → Reserved Instances. INGAT exam: "flexibility" → Savings Plans · "capacity reservation" → Zonal RI · "fault-tolerant + cheapest" → Spot · "spiky/unpredictable" → On-Demand.

Compute SP vs EC2 Instance SP vs RI

Aspect	Compute SP	EC2 Instance SP	Reserved Instances
Diskaun	Sampai 66%	🟢 Sampai 72%	Sampai 72%
Komit pada	$/jam (apa-apa compute)	$/jam (1 family + region)	Instance config tertentu
Tukar family/region	🟢 Bebas	Region & family terkunci	Exchange (Convertible) je
Fargate / Lambda	🟢 Ya, termasuk	❌ EC2 sahaja	❌ EC2 sahaja
Capacity reservation	❌ Tiada	❌ Tiada	🟢 Zonal RI ada

Ingat: Paling fleksibel + cover Fargate/Lambda → Compute SP. Diskaun lebih besar tapi lock family/region → EC2 Instance SP. Perlu jaminan kapasiti AZ → Zonal RI. Billing apply order: RI → EC2 Instance SP → Compute SP (highest discount dulu).

⚡ Quick Sifir — hafal ni

▪SP = commit $/jam compute (bukan instance config) → auto-apply, no exchange manual
▪Compute SP = paling FLEKSIBEL (any family/region/OS + Fargate + Lambda), sampai 66%
▪EC2 Instance SP = lock 1 family + 1 region, diskaun lebih besar (sampai 72%), EC2 sahaja
▪SP TIADA capacity reservation (kalau perlu → Zonal RI)
▪Billing apply order: RI → EC2 Instance SP → Compute SP (highest discount dulu)
▪Soalan tekan 'flexibility / minimal management' → Savings Plans (bukan RI)
▪Boleh interrupt batch → Spot, bukan SP

💡 Exam Scenario

"Nak jimat tapi mungkin tukar instance type/region/OS, dan ada beban Fargate + Lambda sekali" → Compute Savings Plans (auto-apply tanpa exchange manual). "Komited pada family tertentu (cth m5) dalam satu region, nak diskaun lebih besar dari Compute SP" → EC2 Instance Savings Plans. "Beban batch boleh interrupt" → Spot (bukan SP).

🪤 Perangkap Soalan

Q: Beban compute steady tapi mungkin tukar instance type/region nanti, DAN ada Fargate + Lambda. Nak jimat + minimal management. Pilih apa?

⚠ Umpan: Reserved Instances — orang default ke RI untuk 'steady workload', tapi RI lock config + tak cover Fargate/Lambda + perlu exchange manual bila tukar.

✓ Betul: Compute Savings Plans — auto-apply merentas family/region + cover Fargate & Lambda. Keyword: 'flexibility', 'Fargate/Lambda', 'auto-apply', 'minimal management'.

Q: Komited pada satu family (m5) dalam satu region je, nak diskaun lebih besar dari Compute SP. Pilih apa?

⚠ Umpan: Compute SP — sebab nama 'Savings Plans', tapi Compute SP diskaun lebih kecil (66%) sebab dia paling fleksibel.

✓ Betul: EC2 Instance Savings Plans — lock 1 family/region tukar diskaun lebih tinggi (sampai 72%). Keyword: 'specific family + region', 'higher discount'.

🧠 Cara Mudah Ingat

→Compute Savings Plans = paling fleksibel: apa-apa instance family, saiz, OS, tenancy, region — DAN apply ke Fargate + Lambda. Sampai 66%.
→EC2 Instance Savings Plans = lock pada satu instance family dalam satu region (boleh tukar saiz/OS/AZ dalam family). Diskaun lebih besar (sampai 72%) tapi kurang fleksibel. EC2 sahaja.
→SP vs RI: dua-dua commit 1/3 tahun. SP commit $/jam (auto-apply, tak payah exchange). RI commit pada instance config. Soalan tekan "flexibility / minimal management" → Savings Plans.
→Spot ≠ SP: Spot untuk beban yang boleh di-interrupt (sampai 90% murah, no commitment). SP untuk beban steady yang TAK boleh interrupt.
→Payment: All / Partial / No Upfront — sama macam RI, lagi banyak upfront = lagi besar diskaun.
→Billing apply order penting: AWS apply RI dulu, lepas tu EC2 Instance SP, last sekali Compute SP (ikut highest discount).

Guna Bila

Steady compute spend tapi nak fleksibiliti tukar instance/region — auto-apply

flexiblehourly commitmentup to 66% discountCompute Savings PlansEC2 Instance Savings PlansFargateLambdaauto-applyvs Reserved Instancesbilling apply order

📎 Compute vs EC2 Instance Savings Plans

D4 · Cost-Optimized

Compute Optimizer

AWS Compute Optimizer

"AI yang cadang right-size EC2, Lambda, EBS — guna ML analyse usage"

🎯 Sebab Apa Wujud

Wujud sebab manusia teruk teka saiz instance yang betul — selalu over-provision 'just in case' jadi bayar lebih, atau under-provision jadi lembap. Compute Optimizer guna ML atas 14 hari metric sebenar untuk cadang config optimal + jangka penjimatan, hilang kerja analisa rightsizing manual.

Apa Dia

Compute Optimizer analyse historical utilization metrics (14 days) menggunakan ML untuk recommend optimal resource configurations. Bagi projected cost savings, performance risk, dan comparison antara current vs recommended.

Compute Optimizer vs Trusted Advisor

Aspect	Compute Optimizer	Trusted Advisor
Focus	Deep rightsizing of compute	Broad account-wide checks
Method	🟢 ML on 14 days of metrics	Rule-based best-practice checks
Covers	EC2, ASG, EBS, Lambda, ECS/Fargate	Cost, Security, Performance, Fault Tolerance, Service Limits
Output	Optimal instance config + projected savings	Flags idle/risky resources + recommendations
Use when	"ML rightsizing for EC2/Lambda"	"general best-practice/cost/security review"

Ingat: "ML-based deep rightsizing for compute" → Compute Optimizer. "Broad checks across cost/security/performance/limits" → Trusted Advisor (5 categories).

⚡ Quick Sifir — hafal ni

▪Compute Optimizer = ML rightsizing untuk compute (EC2, ASG, EBS, Lambda, ECS/Fargate)
▪Guna ML atas 14 hari CloudWatch metric (perlu minimum 14 hari data)
▪Bagi projected savings + performance risk + current vs recommended
▪PERCUMA (kau bayar CloudWatch je kalau enhanced/custom metrics)
▪vs Trusted Advisor: TA = broad rule-based 5 kategori; CO = ML deep compute rightsizing
▪'ML rightsizing untuk EC2/Lambda' → Compute Optimizer

💡 Exam Scenario

"EC2 instances consistently underutilized, nak reduce cost without manual analysis" → Compute Optimizer untuk get rightsizing recommendations.

🪤 Perangkap Soalan

Q: EC2 instances consistently underutilized — nak ML-based rightsizing recommendation khusus untuk EC2/Lambda tanpa analisa manual. Servis mana?

⚠ Umpan: Trusted Advisor — ada kategori 'Cost Optimization' yang flag idle resource, jadi nampak boleh, tapi TA rule-based broad, bukan ML deep rightsizing dengan config optimal cadangan.

✓ Betul: AWS Compute Optimizer — ML atas 14 hari metric, cadang instance config optimal + projected savings. Keyword: 'ML rightsizing', 'optimal config', 'EC2/Lambda'.

🧠 Cara Mudah Ingat

→Compute Optimizer vs Trusted Advisor: Compute Optimizer = ML-based deep rightsizing untuk compute. Trusted Advisor = broader checks (cost, security, performance, service limits)
→Supported resources: EC2 instances, EC2 Auto Scaling Groups, EBS volumes, Lambda functions, ECS on Fargate
→Requires CloudWatch metrics — needs at least 14 days of usage data for recommendations
→Exam: "get ML-based rightsizing recommendations for EC2/Lambda" → Compute Optimizer. "General cost recommendations across many services" → Trusted Advisor
→PRICING: Compute Optimizer is FREE — tiada charge untuk recommendations. Ia guna CloudWatch metrics sedia ada (kau hanya bayar kalau enable enhanced CloudWatch metrics/custom metrics). Opt-in per account atau org-wide via Organizations.

Guna Bila

Rightsizing recommendations for EC2, Lambda, EBS, ECS on Fargate, Auto Scaling Groups

rightsizingML recommendationsEC2 optimizationLambda optimizationcost savingsunderutilizedvs Trusted Advisor14 days metricsfreepricing

📎 What is AWS Compute Optimizer

D4 · Cost-Optimized

Trusted Advisor

AWS Trusted Advisor

"Penasihat jimat kos AWS"

🎯 Sebab Apa Wujud

Wujud sebab senang terlepas pandang amalan terbaik (security group terbuka, S3 public, RI tak guna, hampir cecah service limit) merentas banyak servis. Trusted Advisor scan akaun automatik ikut rule dan flag isu dalam 5 kategori, jadi kau tak payah audit manual satu-satu.

Apa Dia

Menganalisis persekitaran AWS dan memberikan cadangan rule-based merentas LIMA kategori. Flag resources yang membazir, risiko security, bottleneck performance, kelemahan fault tolerance, dan service limits yang hampir penuh.

5 kategori checks

Cost Optimization → idle/underutilized resources, idle load balancers, unassociated Elastic IPs, RI/SP purchase opportunities

Performance → over-utilized instances, high-latency config, EBS throughput, service config yang melambatkan

Security → open security groups, public S3 buckets, MFA on root, IAM key exposure, exposed access keys

Fault Tolerance → Multi-AZ, backup/snapshot coverage, ASG health, cross-AZ redundancy

Service Limits → resource usage hampir cecah service quota (cth bilangan VPC, EIP, EC2)

Cost / optimization tool mana? (decision tree)

Rendering diagram…

INGAT exam: broad 5-kategori (CP-SFS) → Trusted Advisor; ML rightsizing EC2/Lambda → Compute Optimizer; alert sebelum overspend → Budgets; visualize trend → Cost Explorer. Full TA checks perlu Business/Enterprise support.

Trusted Advisor vs Compute Optimizer vs Budgets

Aspect	Trusted Advisor	Compute Optimizer	AWS Budgets
Job	Broad best-practice checks (5 kategori)	ML rightsizing compute	Alert sebelum overspend
Method	Rule-based	🟢 ML on 14 days metrics	Threshold on cost/usage
Scope	Cost + Security + Perf + FaultTol + Limits	EC2 / ASG / EBS / Lambda / Fargate	Cost / Usage / RI / SP budget
Output	Flag risky/idle + recommendations	Optimal config + projected savings	Email/SNS alert + Budget Actions
Keyword	"broad account review"	"ML rightsizing EC2/Lambda"	"alert at 80% spend"

Ingat: Broad 5-category review → Trusted Advisor. ML deep compute rightsizing → Compute Optimizer. Proactive spend alert → Budgets. Jangan keliru: TA = broad rule-based; CO = compute-only ML.

⚡ Quick Sifir — hafal ni

▪Trusted Advisor = rule-based broad checks, 5 kategori: Cost, Performance, Security, Fault Tolerance, Service Limits (ingat 'CP-SFS')
▪Basic/Developer support = 7 core checks SAHAJA; full 5 kategori perlu Business/Enterprise support
▪API access (automate) perlu Business/Enterprise support
▪vs Compute Optimizer: TA = broad rule-based; CO = ML deep compute rightsizing
▪'all Trusted Advisor checks' → perlu Business/Enterprise support
▪'alert before overspend' → Budgets (bukan TA)

💡 Exam Scenario

CFO tanya "mana resources kita yang membazir?" — Trusted Advisor akan highlight EC2 yang underutilized, S3 buckets tak pakai, Elastic IPs yang idle, dan bagi estimate savings. "ML rightsizing untuk EC2/Lambda spesifik" pula → Compute Optimizer, BUKAN Trusted Advisor.

🪤 Perangkap Soalan

Q: Syarikat nak enable SEMUA Trusted Advisor checks (5 kategori penuh + API automation) tapi guna Developer support plan. Apa masalahnya?

⚠ Umpan: Sangka semua check available di mana-mana plan — sebab Trusted Advisor sendiri tiada caj, orang ingat semua check percuma.

✓ Betul: Developer support cuma dapat 7 core checks. Full 5-category + API perlu UPGRADE ke Business/Enterprise support. Keyword: 'all checks', 'Business/Enterprise support'.

Q: Nak broad best-practice review merentas cost, security, performance, dan service limit untuk seluruh akaun. Servis mana?

⚠ Umpan: Compute Optimizer — nampak 'optimization jadi pilih', tapi CO fokus compute rightsizing (EC2/Lambda/EBS) je, bukan security atau service limit.

✓ Betul: Trusted Advisor — broad rule-based 5-category account-wide review. Keyword: 'broad best-practice', 'security + cost + limits', 'account-wide'.

🧠 Cara Mudah Ingat

→Lima kategori checks: Cost Optimization, Performance, Security, Fault Tolerance, Service Limits (ingat: "CP-SFS")
→Tahap akses: Basic/Developer support = 7 core checks SAHAJA (mostly security + service limits). Business/Enterprise support = SEMUA checks (5 kategori penuh) + API access (boleh automate via AWS Support API)
→PRICING: Trusted Advisor sendiri tiada caj langsung — tapi akses penuh DIKUNCI di belakang support plan. Basic/Developer (free/$29) = 7 core checks. Full 5-category checks perlu Business ($100/bln atau 10% usage) atau Enterprise support. Exam: "all Trusted Advisor checks" → perlu Business/Enterprise support.
→Bukan Compute Optimizer (yang ML-based deep compute rightsizing untuk EC2/ASG/EBS/Lambda/Fargate). Trusted Advisor = broader, rule-based, 5 kategori account-wide
→Exam: "broad best-practice checks across cost/security/performance/limits" → Trusted Advisor. "ML rightsizing for EC2/Lambda" → Compute Optimizer. "alert before overspend" → Budgets

Guna Bila

Identify idle resources, cost optimization recommendations

cost recommendationsidle resourcesrightsizingunderutilizedservice limitsfive categoriesCost OptimizationPerformanceSecurityFault Tolerancerule-basedvs Compute Optimizer7 core checksBusiness supportEnterprise supportpricing

📎 AWS Trusted Advisor

D4 · Cost-Optimized

AWS Budgets

"Alarm sebelum spend cecah limit"

🎯 Sebab Apa Wujud

Wujud sebab Cost Explorer cuma tunjuk duit dah pergi mana SELEPAS jadi (reactive) — kau cuma sedar over-budget bila bil dah keluar. Budgets bagi amaran PROAKTIF: set threshold, dan ia alert (atau auto-act) sebelum/sebaik kos cecah limit, jadi kau tak terkejut dengan bil besar.

Apa Dia

Buat budget untuk kos, usage, atau Reserved Instance coverage. Alert via email atau SNS bila actual atau forecast spend melebihi threshold yang ditetapkan.

⚡ Quick Sifir — hafal ni

▪Budgets = PROACTIVE alert sebelum/sebaik cecah threshold (Cost Explorer = reactive analysis)
▪4 jenis: Cost, Usage, Reservation (RI coverage/util), Savings Plans budget
▪Alert boleh actual ATAU forecast; boleh set banyak threshold (80%/100%/120%)
▪Budget Actions: auto-respond — apply IAM policy, attach SCP, atau stop EC2
▪Free tier: 2 budgets percuma, lebih $0.02/hari setiap satu
▪'alert before overspend' → Budgets; 'detailed line-item billing' → CUR

💡 Exam Scenario

"Alert bila monthly EC2 cost nak cecah $1000" → AWS Budgets. Bukan Cost Explorer (yang untuk analysis/visualization, bukan alerting). Budgets = PROACTIVE ALERTS. Cost Explorer = REACTIVE ANALYSIS.

🪤 Perangkap Soalan

Q: Finance nak dapat email amaran SEBELUM monthly EC2 cost cecah $1000. Servis mana?

⚠ Umpan: Cost Explorer — orang ingat 'kos jadi Cost Explorer', tapi Cost Explorer cuma VISUALIZE/analyse past spend, tak hantar alert proaktif.

✓ Betul: AWS Budgets — set threshold + alert (boleh forecast) sebelum overspend. Keyword: 'alert before overspending', 'notify at threshold'.

Q: Bila kos cecah threshold, sistem mesti AUTO stop EC2 non-prod, bukan sekadar hantar email. Apa guna?

⚠ Umpan: Cost Anomaly Detection — nampak macam auto-respond, tapi ia detect+alert anomali, tak ambil tindakan auto-stop.

✓ Betul: AWS Budgets + Budget Actions — auto apply IAM/SCP atau stop EC2 bila threshold dilanggar. Keyword: 'budget actions', 'auto-stop on threshold'.

🧠 Cara Mudah Ingat

→Four budget types: Cost budget, Usage budget, Reservation budget (RI utilization/coverage), Savings Plans budget
→Budget Actions: auto-respond when threshold exceeded — apply IAM policy, attach SCP, or stop EC2 instances
→Budgets alerts: actual OR forecast. Set multiple thresholds (e.g., alert at 80%, 100%, 120%)
→Exam: "alert BEFORE overspending" → Budgets. "analyze WHERE money went" → Cost Explorer. "detailed line-item billing data" → Cost and Usage Report (CUR)
→PRICING: AWS Budgets = 2 budgets PERCUMA per account; lebih = $0.02/hari setiap budget (~$0.60/bulan). Budget Actions free. Cost discriminator: Budgets murah sangat — guna untuk semua threshold alerting. (Compare penuh Cost Explorer vs Budgets vs CUR: lihat card Cost Explorer.)

Guna Bila

Set cost/usage thresholds and get alerted before overspending

budget alertscost thresholdSNS notificationusage budgetforecast alertbefore overspendbudget actionspricing

📎 Managing your costs with AWS Budgets 📎 Configuring budget actions

D4 · Cost-Optimized

Cost Explorer

AWS Cost Explorer

"Graf dan analisis spending AWS"

🎯 Sebab Apa Wujud

Wujud sebab bil AWS mentah susah nak faham — kau tak nampak servis/akaun/tag mana makan duit paling banyak atau trend naik. Cost Explorer bagi UI siap dengan graf, breakdown, forecast, dan cadangan RI/SP supaya kau faham corak belanja tanpa olah data CSV sendiri.

Apa Dia

Interactive UI untuk analyse AWS spending by service, account, tag, region. Bagi RI dan Savings Plans recommendations. Boleh forecast future costs. Granular hingga hourly.

Cost monitoring — tool mana?

Rendering diagram…

INGAT exam: "unusual/anomalous spending + ML" → Cost Anomaly Detection (BUKAN Budgets threshold, BUKAN CloudWatch yang tak beza anomali vs growth). "alert before overspend" → Budgets. "visualize trends" → Cost Explorer.

Cost Explorer vs Budgets vs CUR

Aspect	Cost Explorer	AWS Budgets	Cost & Usage Report
Job	Visualize & analyze past spend	Alert before/over a threshold	Most granular billing line items
Direction	Reactive — "where did money go?"	🟢 Proactive — "warn me at 80%"	Raw data for deep/custom analysis
Output	Charts, trends, forecast, RI/SP recs	Email/SNS alerts + Budget Actions	CSV/Parquet to S3 (query w/ Athena)
Granularity	Monthly / daily / hourly	Per budget threshold	Hourly, per-resource, per-tag
Keyword	"visualize / analyze trends"	"alert before overspending"	"detailed line-item billing data"

Ingat: Analyze trends → Cost Explorer. Alert before overspend → Budgets (proactive). Deepest raw billing data for custom queries → Cost & Usage Report (CUR) → S3 + Athena.

Unusual / anomalous spending — tool mana? (4-way exam trap)

Tool	Tugas	Keyword exam	Bukan untuk
Cost Anomaly Detection	🟢 ML auto-detect spike pelik + alert (SNS/email) + root-cause	"unusual / anomalous spending", "ML detect"	BUKAN threshold tetap, BUKAN auto-stop instance
AWS Budgets	Alert bila cecah threshold (actual/forecast) + Budget Actions	"alert before overspend", "notify at threshold"	BUKAN ML anomaly, BUKAN visualize
Cost Explorer	Visualize & analyse past spend + forecast 12 bln	"visualize trends", "analyze spend"	BUKAN alert proaktif
CloudWatch (EstimateCharges)	Metric kasar bil anggaran + alarm	"billing metric alarm"	BUKAN boleh bezakan unusual vs normal growth

Ingat: Soalan sebut "unusual/anomalous spending + ML + alert" → Cost Anomaly Detection. "alert at fixed threshold" → Budgets. "visualize trends" → Cost Explorer. CloudWatch EstimateCharges tak boleh beza anomali vs growth normal — itu umpan.

⚡ Quick Sifir — hafal ni

▪Cost Explorer = VISUALIZE & analyse spend (reactive 'duit pergi mana?')
▪Forecast sampai 12 bulan ke depan (80% prediction interval)
▪Granularity: monthly/daily/hourly (hourly perlu detailed billing on)
▪Bagi RI + Savings Plans purchase recommendations
▪Cost Anomaly Detection: ML auto-detect spike pelik + alert
▪'visualize trends' → Cost Explorer; 'alert before overspend' → Budgets; 'raw CSV/SQL' → CUR

💡 Exam Scenario

"Nak tengok mana service paling banyak cost bulan lepas" → Cost Explorer. "Dapat recommendations untuk beli Reserved Instances" → Cost Explorer. Bukan Trusted Advisor (general recommendations). Bukan Budgets (alerts). Cost Explorer = VISUALIZATION & ANALYSIS.

🪤 Perangkap Soalan

Q: Pasukan nak tengok graf service mana cost paling banyak 6 bulan lepas DAN dapat cadangan RI nak beli. Servis mana?

⚠ Umpan: Cost & Usage Report — nampak 'cost detail jadi CUR', tapi CUR raw data mentah ke S3 yang kau kena query/olah sendiri, bukan graf siap + recommendation.

✓ Betul: Cost Explorer — UI interaktif dengan chart, trend, forecast + RI/SP recommendation. Keyword: 'visualize trends', 'analyze spend', 'RI recommendation'.

🧠 Cara Mudah Ingat

→Forecast: predict future spend up to 12 months ahead using historical data (80% prediction interval)
→Granularity: monthly, daily, or hourly. Hourly only available with detailed billing enabled
→RI + Savings Plans recommendations: Cost Explorer recommends which RIs/SPs to buy based on usage patterns
→Filters: by service, linked account, tag, AZ, instance type, purchase option, etc.
→Cost anomaly detection: ML-powered, auto-detects unusual spending spikes and alerts you
→Exam: "visualize spending trends" → Cost Explorer. "alert when budget exceeded" → Budgets. "detailed CSV billing report" → Cost and Usage Report (CUR)

Guna Bila

Visualise and analyse AWS costs — understand patterns, get RI/SP recommendations

cost analysisspending visualizationRI recommendationsusage patternsrightsizingforecasthourly granularityanomaly detectionCost Anomaly Detectionunusual spendinganomalous spendvs BudgetsCUR

D4 · Cost-Optimized

Cost Anomaly Detection

AWS Cost Anomaly Detection

"ML detect spike pelik → alert + root cause — bukan threshold tetap"

🎯 Sebab Apa Wujud

Wujud sebab Budgets cuma alert bila cecah threshold TETAP — kalau kos naik perlahan-lahan (growth normal) atau spike kecil, kau tak sedar sampai terlambat. CloudWatch EstimateCharges pun tak boleh bezakan "unusual" vs "expected growth". Cost Anomaly Detection guna ML (account for seasonality, weekly/monthly patterns) untuk detect spike PELIK & bagitau department yang betul sebelum jadi surprise besar.

Apa Dia

Feature dalam AWS Billing & Cost Management yang guna machine learning untuk detect corak belanja yang TIDAK BIASA (anomalous) pada EC2, RDS, S3, dll — kemudian hantar alert (email atau SNS) dengan root-cause analysis (account, service, Region, usage type). Boleh configure cost monitor ikut granularity (semua services, member account, cost allocation tag, cost category).

Cost Anomaly Detection — 4 langkah (AWS whitepaper flow)

Rendering diagram…

INGAT exam: "monitor unusual spending + alert departments" → create cost monitor (Cost Anomaly Detection) dalam Billing & Cost Management console. ML handle seasonality supaya tak alert setiap kali growth normal. Lepas alert, investigate root cause — bukan sekadar threshold Budgets.

⚡ Quick Sifir — hafal ni

▪Cost Anomaly Detection = ML detect UNUSUAL spend + alert + root-cause
▪Workflow: create cost monitor → get alerted (email/SNS) → analyze root cause
▪ML minimize false positives (seasonality, natural growth)
▪BUKAN Budgets (threshold tetap / zero-spend template = Free Tier alert je)
▪BUKAN Cost Explorer (visualize trend, tak actively alert anomaly)
▪BUKAN CloudWatch EstimateCharges (tak bezakan unusual vs normal growth)
▪Keyword: "unusual spending patterns / anomalous spend / ML detect" → Cost Anomaly Detection

💡 Exam Scenario

Finance review infra — nampak corak belanja pelik pada EC2/RDS/S3. Nak ML auto-detect + alert department + root-cause (service/region/account) → Billing console → create cost monitor (Cost Anomaly Detection). BUKAN Budgets (threshold), BUKAN CloudWatch EstimateCharges.

🪤 Perangkap Soalan

Q: EC2 + RDS + S3 — company nampak unusual spending patterns, nak monitor kos & alert department bila ada spend pelik. Pilih?

⚠ Umpan: AWS Budgets zero spend template — nampak "budget = alert kos", tapi zero-spend template cuma alert bila exceed Free Tier, bukan anomaly detection.

✓ Betul: AWS Cost Anomaly Detection — create cost monitor dalam Billing console; ML detect anomalous patterns + alert email/SNS + root-cause. Keyword "unusual/anomalous spending + alert departments".

Q: Nak alert bila total bill cecah $5000/bulan (threshold tetap). Guna Cost Anomaly Detection?

⚠ Umpan: Cost Anomaly Detection — ada "detection" dalam nama, nampak sesuai untuk semua alert kos.

✓ Betul: AWS Budgets — threshold tetap (actual/forecast). Cost Anomaly Detection untuk spike PELIK (ML), bukan fixed dollar limit.

Q: Enable CloudWatch EstimateCharges metric untuk detect unusual spending?

⚠ Umpan: CloudWatch boleh alarm pada billing metric — nampak betul sebab EstimateCharges = kos.

✓ Betul: Tak cukup — CloudWatch EstimateCharges tak boleh bezakan unusual spike vs normal/expected growth. Keyword "anomalous/unusual" → Cost Anomaly Detection (ML).

Q: Cost Explorer multi-year monthly granularity untuk detect unusual spending?

⚠ Umpan: Cost Explorer = analisa trend — nampak betul untuk "review spending", tapi ia REACTIVE visualization, tak actively alert pada anomaly.

✓ Betul: Cost Anomaly Detection untuk alert anomaly. Cost Explorer untuk visualize/analyse trend lepas (bukan proactive anomaly alert).

Guna Bila

Detect unusual/anomalous AWS spend patterns and alert departments automatically

Cost Anomaly Detectionunusual spendinganomalous spendMLcost monitorroot causeSNS alertseasonalityvs Budgetsvs CloudWatch EstimateChargesvs Cost Explorerzero spend budgetpricing

📎 Managing cost anomalies

D4 · Cost-Optimized

Instance Scheduler

Instance Scheduler on AWS

"Office hours je — auto stop EC2 + RDS malam & weekend (CFN template)"

🎯 Sebab Apa Wujud

App internal jalan weekday office hours je — bayar EC2+RDS 24/7 = membazir 118 jam/minggu idle. RI/Savings Plans commit hourly 24/7 (masih bayar waktu stopped untuk SP discount layer, RI commit tetap). Custom CloudWatch+Lambda boleh stop ikut CPU tapi overhead tinggi + RDS stop ikut CPU = risiko downtime waktu kerja. Instance Scheduler = deploy CFN template sekali, set jadual, least operational overhead.

Apa Dia

BUKAN AWS service native — ia **AWS Solution** (ready-made CloudFormation template) yang deploy stack: EventBridge timer → Lambda baca jadual dari DynamoDB → start/stop EC2 & RDS yang ditag. Kau set schedule (cth office-hours weekday), tag instances, solution handle rest. Boleh jimat ~70% bila guna ~50 jam/minggu vs 168 jam (24/7).

Instance Scheduler on AWS — architecture (CloudFormation solution)

Rendering diagram…

Bukan native AWS service — deploy CloudFormation template dari AWS Solutions. EventBridge cetus Lambda → baca schedule dari DynamoDB → start/stop EC2 & RDS yang ditag. INGAT exam: "office hours weekday + EC2 + RDS + least overhead" → Instance Scheduler template, BUKAN RI/SP (24/7 commit) atau CloudWatch CPU+Lambda (more ops + RDS trap).

Part-time workload — Instance Scheduler vs RI/SP vs custom Lambda

Approach	Fits office-hours?	Ops overhead	Exam trap
Instance Scheduler (CFN)	🟢 Start/stop on schedule	🟢 Low — deploy template	Correct for fixed weekday hours
Reserved Instances	🔴 24/7 commit assumed	Low	Umpan: "save money" — wrong for part-time
Compute Savings Plan	🔴 Hourly commit even if stopped	Low	Umpan: "Savings Plan" — no RDS, not stop
CloudWatch + Lambda (CPU)	Dynamic, not fixed schedule	🔴 High — custom code	Umpan: "automate stop" — RDS CPU risk

Ingat: Fixed weekday/office-hours pattern + minimal ops → Instance Scheduler CFN template. Continuous 24/7 → RI/SP. "Unusual" dynamic idle → maybe custom Lambda (but exam prefers scheduler for fixed hours).

⚡ Quick Sifir — hafal ni

▪Instance Scheduler = AWS Solution (CloudFormation template), BUKAN native service
▪Auto start/stop EC2 + RDS ikut tag-based schedule (office hours / weekday)
▪Stack: EventBridge → Lambda → DynamoDB (schedules) + IAM + KMS + SNS
▪RI / Savings Plan = commit 24/7 hourly — BUKAN untuk part-time/stopped workloads
▪Compute Savings Plan = EC2/Lambda/Fargate je — TAK cover RDS instance types
▪CloudWatch CPU alarm + Lambda = dynamic idle stop, lebih ops + RDS CPU trap
▪Keyword: "weekday office hours / minimal operational overhead" → Instance Scheduler CFN

💡 Exam Scenario

Internal app — EC2 + RDS PostgreSQL, run weekday working hours only. Deploy AWS Instance Scheduler CloudFormation template, configure office-hour start/stop for both. Up to ~70% savings vs 24/7 On-Demand. BUKAN RI/SP (24/7 commit). BUKAN hand-built CloudWatch+Lambda (more ops).

🪤 Perangkap Soalan

Q: EC2 + RDS PostgreSQL jalan weekday office hours SAHAJA. Optimize cost, minimal operational overhead. Pilih?

⚠ Umpan: Compute Savings Plan / Reserved Instance — nampak jimat, tapi commit 24/7 selama 1-3 tahun = bayar masa malam & weekend yang tak guna.

✓ Betul: Deploy Instance Scheduler on AWS (CloudFormation template) — set start/stop schedule EC2 + RDS ikut office hours. Ready-made, least overhead. Keyword "office hours / weekday only / minimal ops".

Q: Same stem — engineer cadang CloudWatch alarm + Lambda bila CPU rendah untuk stop EC2 & RDS.

⚠ Umpan: Dynamic idle detection — nampak pintar sebab "stop bila tak guna".

✓ Betul: Tak ideal — lebih ops (build & maintain), dan stop RDS ikut CPU boleh trigger downtime waktu kerja bila utilization drop sementara. Fixed schedule = Instance Scheduler.

Q: Purchase compute Savings Plan for EC2 and RDS for this part-time app?

⚠ Umpan: Savings Plan cover both — nampak betul sebab "compute savings".

✓ Betul: Salah dua-dua: (1) Savings Plan assume consistent hourly use — stopped hours still committed; (2) Compute SP = EC2/Lambda/Fargate, BUKAN RDS DB instance types. Part-time → start/stop schedule.

Guna Bila

Auto start/stop EC2 + RDS on a fixed weekday schedule with minimal ops overhead

Instance Scheduler on AWSstart stop scheduleoffice hoursweekday onlypart-time workloadCloudFormation solutionEC2 RDS scheduleminimal operational overheadAWS Solutionstag-based schedule70% savingsvs Reserved Instancesvs Savings Planspricing

📎 Instance Scheduler on AWS — solution overview

D4 · Cost-Optimized

Cost & Usage Report

AWS Cost and Usage Report (CUR)

"Data billing PALING detail → drop ke S3 → query guna Athena"

🎯 Sebab Apa Wujud

Wujud sebab Cost Explorer (UI siap) tak cukup detail bila kau nak buat custom report atau analisa per-resource/per-tag guna SQL sendiri. CUR drop billing data PALING granular ke S3 supaya kau boleh query guna Athena, load ke Redshift, atau dashboard QuickSight — kawalan penuh atas data billing mentah.

Apa Dia

Report billing PALING terperinci yang AWS ada — setiap line item kos & usage (per jam, per resource, per tag, termasuk RI & Savings Plans utilization). Dihantar automatik ke S3 bucket kau dalam format CSV (atau Parquet untuk Athena). Lepas tu boleh query guna Amazon Athena (SQL terus atas S3), load ke Redshift, atau visualize dalam QuickSight.

CUR vs Cost Explorer vs Budgets

Aspect	Cost & Usage Report	Cost Explorer	AWS Budgets
Job	🟢 Raw line items paling granular	Visualize & analyze spend	Alert before/over threshold
Output	CSV/Parquet ke S3	Charts, trends, forecast	Email/SNS + Budget Actions
Cara guna	Query Athena/Redshift/QuickSight	Interactive UI siap	Set threshold → tunggu alert
Keyword	"detailed line-item / SQL billing"	"visualize / analyze trends"	"alert before overspending"

Ingat: Nak data mentah paling detail untuk olah sendiri → CUR (S3 + Athena). Nak tengok graf siap → Cost Explorer. Nak amaran sebelum lebih bajet → Budgets.

⚡ Quick Sifir — hafal ni

▪CUR = billing data PALING granular (hourly, per-resource, per-tag, RI/SP utilization)
▪Auto-deliver ke S3 bucket kau: CSV atau Parquet
▪Athena hanya support Parquet — pilih Parquet kalau nak query Athena
▪Query via Athena (SQL atas S3), load Redshift, atau QuickSight dashboard
▪Lebih detail dari Cost Explorer (yang UI siap je)
▪'detailed line-item / raw billing for SQL' → CUR; 'visualize trends' → Cost Explorer

💡 Exam Scenario

"Nak data billing mentah paling detail untuk buat custom report / query sendiri guna SQL" → Cost & Usage Report → S3 + Athena. Bukan Cost Explorer (itu untuk VISUALIZE dalam UI siap). Bukan Budgets (itu untuk ALERT). CUR = raw data, kau yang olah sendiri.

🪤 Perangkap Soalan

Q: Finance nak data billing mentah paling detail (per-resource, per-hour) untuk query custom guna SQL. Servis mana?

⚠ Umpan: Cost Explorer — orang ingat 'analisa cost jadi Cost Explorer', tapi Cost Explorer UI siap dengan granularity terhad, bukan raw line-item untuk SQL custom.

✓ Betul: Cost and Usage Report (CUR) → S3 + Athena (Parquet). Keyword: 'detailed line-item', 'raw billing data', 'query with SQL', 'most granular'.

🧠 Cara Mudah Ingat

→Output ke S3: CSV (boleh gzip/zip) atau Parquet. Athena hanya support Parquet — pilih Parquet kalau nak query guna Athena.
→Query options: Amazon Athena (SQL terus atas S3, tak payah data warehouse), Amazon Redshift (load masuk), atau Amazon QuickSight (dashboard).
→Paling granular: hourly, per-resource, per-tag, plus Savings Plans & RI utilization/coverage. Lebih detail dari Cost Explorer.
→CUR boleh auto-refresh line item bila ada late-arriving data, dan support versioning fail dalam S3.
→Exam keyword: "detailed line-item billing data" / "raw billing data to query with SQL" → Cost & Usage Report (CUR). "visualize trends" → Cost Explorer. "alert before overspend" → Budgets.

Guna Bila

Raw line-item billing paling granular untuk custom/deep cost analysis

Cost and Usage ReportCURline-item billingmost granularS3 deliveryCSVParquetAthenaRedshiftQuickSightper-resourcehourlyraw billing data

📎 What is the AWS Cost and Usage Report 📎 Query CUR using Amazon Athena

D4 · Cost-Optimized

Cost Allocation Tags

AWS Cost Allocation Tags

"Label resource → tahu duit pergi mana"

🎯 Sebab Apa Wujud

Wujud sebab dalam SATU account, kos semua team/projek bercampur jadi satu lump — kau tak boleh tahu department mana belanja berapa. Cost Allocation Tags label resource (key-value) yang bila DIAKTIFKAN, biar AWS kumpulkan kos ikut label dalam Cost Explorer/Budgets/CUR, jadi kau boleh chargeback ikut projek/team.

Apa Dia

Tag (key-value) yang kau AKTIFKAN di Billing console supaya AWS kumpulkan kos ikut label dalam Cost Explorer, Budgets, dan Cost & Usage Report. Boleh tag ikut cost center, nama app, owner, atau environment.

AWS-generated vs User-defined cost allocation tags

Aspect	AWS-generated	User-defined
Siapa buat	AWS auto-create & apply	Kau define & apply sendiri
Prefix	aws: (cth aws:createdBy)	user:
Contoh	createdBy, aws:cloudformation:stack-name	CostCenter, Project, Environment, Owner
Kena activate?	🟡 Ya — activate berasingan di Billing console	🟡 Ya — activate berasingan di Billing console

Ingat: Kedua-dua jenis MESTI di-ACTIVATE di Billing/Cost Management console dulu baru muncul dalam Cost Explorer / cost allocation report (boleh ambil masa ~24 jam). Tag = cara utama group kos ikut team/projek/environment.

⚡ Quick Sifir — hafal ni

▪Cost Allocation Tags = group kos ikut tag (team/projek/env) dalam SATU account
▪Tag = key+value (cth Project=Alpha); satu key satu value per resource
▪Apply tag SAHAJA tak cukup — kena ACTIVATE di Billing console (boleh ambil ~24 jam)
▪Dua jenis: AWS-generated (prefix aws:) + User-defined (prefix user:) — dua-dua kena activate
▪Lepas aktif: filter Cost Explorer, set Budget per tag, muncul dalam CUR
▪Pisah kos merentas BANYAK account → Consolidated Billing (bukan tags)

💡 Exam Scenario

"Nak tahu berapa kos setiap department/projek dalam SATU account" → tag resource (cth Project=Alpha) → ACTIVATE tag → group/filter dalam Cost Explorer. Tanpa tag, semua kos bercampur jadi satu.

🪤 Perangkap Soalan

Q: Dah tag semua resource dengan Project=Alpha tapi tak nampak breakdown kos ikut projek dalam Cost Explorer. Kenapa?

⚠ Umpan: Sangka tag auto muncul dalam cost report sebaik di-apply — orang skip langkah activate sebab ingat tagging dah cukup.

✓ Betul: Tag kena di-ACTIVATE di Billing/Cost Management console dulu (boleh ambil ~24 jam) baru muncul. Keyword: 'activate cost allocation tag', 'tag tak muncul dalam report'.

Q: Syarikat ada 12 AWS account berasingan, nak asingkan kos ikut account untuk chargeback. Guna apa?

⚠ Umpan: Cost Allocation Tags — nampak 'track cost jadi pakai tag', tapi tags untuk group dalam satu account; merentas banyak account ada cara lebih kemas.

✓ Betul: Consolidated Billing (Organizations linked accounts) — kos per account auto-asing dalam satu bil. Keyword: 'multiple accounts', 'per-account cost', 'consolidated billing'.

🧠 Cara Mudah Ingat

→Tag = key + value (cth Environment=Prod). Satu key cuma boleh ada satu value per resource
→Apply tag SAHAJA tak cukup — kena activate dalam Billing console, kalau tak ia tak muncul dalam report
→Lepas aktif: boleh filter/group dalam Cost Explorer, set Budget per tag, dan muncul dalam CUR
→Exam: "track cost by department/project/team dalam SATU account" → Cost Allocation Tags. "pisah kos merentas BANYAK account" → Consolidated Billing (linked accounts)

Guna Bila

Track & group kos ikut team / projek / environment

cost allocation tagsAWS-generateduser-definedactivate in billingtrack cost by tagcost center

D4 · Cost-Optimized

Consolidated Billing

AWS Organizations Consolidated Billing

"Satu bil untuk semua account + diskaun dikongsi"

🎯 Sebab Apa Wujud

Kalau setiap AWS account bayar bil sendiri, kau rugi sebab volume discount, Reserved Instances & Savings Plans kira per-account — usage kecik tak naik tier murah. Consolidated Billing wujud supaya semua account dalam Organizations DIGABUNG jadi satu payer → usage besar terus, diskaun dikongsi, satu bil je. Lagi banyak account, lagi murah per unit.

Apa Dia

Ciri AWS Organizations: management (payer) account bayar untuk semua member account. Usage semua account DIGABUNG → kongsi volume pricing discount, Reserved Instance discount, dan Savings Plans merentas account. Percuma.

Faedah Consolidated Billing

Faedah	Maksudnya
One bill	Satu bil untuk semua account (management account yang bayar)
Combined usage	🟢 Usage digabung → naik tier volume discount lebih cepat
Shared RI / Savings Plans	🟢 RI & SP yang tak terpakai di satu account auto-apply ke account lain
No extra fee	Percuma — tiada caj tambahan
Easy tracking	Download combined cost & usage; ada cost report per member account

Ingat: Management account = payer. Diskaun (volume, RI, Savings Plans) DIKONGSI merentas semua member account → total lebih murah dari account berasingan. Member account keluar org → hilang akses Cost Explorer data lama (management account masih simpan).

⚡ Quick Sifir — hafal ni

▪Management (payer) account = bayar semua; member bill = informational je
▪Usage SEMUA account digabung → naik volume tier diskaun lebih cepat (cth S3 tiered)
▪RI + Savings Plans tak terpakai di satu account auto-apply ke account lain
▪Consolidated Billing = PERCUMA (sebahagian dari AWS Organizations)
▪Nak HAD apa member boleh buat = SCP (guardrail), BUKAN billing

💡 Exam Scenario

"Syarikat ada 10 AWS account, nak satu bil je + maksimumkan diskaun" → Organizations Consolidated Billing. Usage digabung sampai naik tier diskaun lebih tinggi (cth S3 tiered pricing), dan RI/Savings Plans yang tak terpakai di satu account auto-apply ke account lain.

🪤 Perangkap Soalan

Q: Syarikat ada 12 AWS account, nak satu bil + maksimumkan volume/RI discount merentas semua account. Apa setup?

⚠ Umpan: Cost Allocation Tags — sebab nampak macam 'urus kos'. SALAH: tags cuma label kos untuk reporting dalam SATU bil, tak gabungkan usage atau kongsi diskaun.

✓ Betul: AWS Organizations Consolidated Billing — usage digabung, RI/Savings Plans/volume discount dikongsi merentas account. Keyword: 'single bill + maximize discounts across accounts'.

🧠 Cara Mudah Ingat

→Management (payer) account bayar semua; member account bills = informational sahaja
→Volume discount + RI + Savings Plans dikongsi merentas semua account dalam organization
→Consolidated Billing PERCUMA — ia sebahagian dari AWS Organizations
→Exam: "single bill + maximize discounts across many accounts" → Consolidated Billing. "restrict apa member account boleh buat" → SCPs (guardrails, BUKAN billing)

Guna Bila

Gabung billing banyak account, kongsi volume/RI/SP discount

consolidated billingmanagement accountmember accountsvolume discountshared RIshared Savings Plansone billfree

💾Storage Cost Optimization↑ Top

D4 · Cost-Optimized

S3 Storage Tiers

Amazon S3 Storage Classes — Cost View (the TOTAL bill, bukan storage je)

"4 lapisan bil: storan + retrieval fee + min-duration + min 128KB/objek"

🎯 Sebab Apa Wujud

Kalau semua data duduk dalam S3 Standard, kau bayar harga penuh ($0.023/GB-mo) walaupun data dah lama tak disentuh. Storage classes wujud sebab access pattern berubah ikut umur data — log baru kena laju, log lama jarang baca. TAPI jebakan kos: pindah ke IA/Glacier nampak jimat (storage murah), padahal kalau kau access kerap kau kena retrieval fee + kalau delete awal kena early-delete charge. Jadi 'tier paling murah' = bergantung pada berapa KERAP access + berapa LAMA simpan, bukan storage price semata.

Apa Dia

Sama set 7 storage classes macam card D3, TAPI lihat dari sudut KOS. Bil S3 bukan storage price je — ada 4 lapisan kos tersembunyi yang exam suka umpan: (1) storan $/GB-mo, (2) retrieval fee setiap GB kau tarik balik, (3) minimum storage duration (delete awal = still kena bayar baki), (4) minimum billable object size 128KB (objek kecik dalam IA/Glacier dibil macam saiz 128KB). Pilih tier salah = bil naik walaupun storage price nampak murah.

Anatomy KOS — 4 lapisan bil tiap class (bukan storage price je)

Lapisan 1 — Storage $/GB-mo → harga simpan tiap GB sebulan (Standard mahal → Deep Archive paling murah)

Lapisan 2 — Retrieval fee $/GB → bayar tiap kali tarik data balik (Standard & Intelligent-Tiering = $0; IA & Glacier kena caj, makin sejuk makin mahal tarik)

Lapisan 3 — Minimum storage duration → delete sebelum tempoh min still kena bayar baki (Standard none · IA 30d · Glacier 90d · Deep Archive 180d)

Lapisan 4 — Minimum billable object size 128KB → objek <128KB dalam IA/Glacier dibil macam 128KB (jutaan objek kecik = mahal)

+ Lifecycle/transition request cost → setiap transition antara class ada caj per 1,000 request

Tier paling MURAH all-in (cost decision tree)

Rendering diagram…

Cost analogy — macam sewa storan barang: barang selalu pakai letak rumah (Standard, ambik bila-bila free). Barang musim jarang pakai → sewa self-storage murah (IA), tapi tiap kali masuk ambik kena bayar tol (retrieval fee) + kontrak min sebulan. Barang pusaka simpan 10 tahun → gudang jauh paling murah (Deep Archive), tapi nak ambik kena booking lori tunggu 2 hari. INGAT exam: "frequently accessed" + "small objects" = JANGAN IA; "unknown/changing access pattern" = Intelligent-Tiering (satu-satunya tiada retrieval fee).

Cost mechanics — yang exam guna untuk umpan (us-east-1, approx)

Class	Storan $/GB-mo	Retrieval fee	Min duration	Min objek	Cost trap
Standard	$0.023	$0 (free)	None	None	Mahal untuk data sejuk — jangan biar data lama duduk sini
Intelligent-Tiering	$0.023→ auto turun	$0 (no retrieval!)	None	None*	Monitoring $0.0025/GB; *free untuk objek <128KB (tak monitor)
Standard-IA	$0.0125	~$0.01/GB	30 hari	128KB	Access kerap = retrieval fee bunuh penjimatan
One Zone-IA	$0.01	~$0.01/GB	30 hari	128KB	1 AZ je — AZ musnah = data hilang. Re-creatable only
Glacier Instant	$0.004	~$0.03/GB	90 hari	128KB	Retrieval fee tinggi — jangan kalau access bulanan
Glacier Flexible	$0.0036	per restore job	90 hari	40KB	Kena restore job (min–jam), bukan GET terus
Deep Archive	$0.00099	paling mahal tarik	180 hari	40KB	Delete <180d = bayar baki; retrieve 12–48jam

Ingat: Storage price murah ≠ bil murah. Tambah retrieval fee + early-delete penalty + min 128KB/objek dulu. Access KERAP → Standard. Access TAK TENTU → Intelligent-Tiering (satu-satunya no retrieval fee + auto-move). Access JARANG + objek besar + simpan lama → IA/Glacier ikut berapa laju nak retrieve. Banyak objek KECIK → elak IA (min 128KB billing).

⚡ Quick Sifir — hafal ni

▪4 lapisan kos: storan + retrieval fee + min-duration penalty + min 128KB/objek (IA & Glacier)
▪Storan: Standard $0.023 · Standard-IA $0.0125 · One Zone-IA $0.01 · Glacier Instant $0.004 · Flexible $0.0036 · Deep Archive $0.00099 (CHEAPEST)
▪Retrieval fee: Standard & Int-Tiering = $0 · IA ~$0.01/GB · Glacier Instant ~$0.03/GB · Deep Archive paling mahal tarik balik
▪Min duration (early-delete): Standard none · IA 30d · Glacier 90d · Deep Archive 180d
▪Access KERAP tapi guna IA = retrieval fee bunuh penjimatan → patut Standard atau Intelligent-Tiering
▪Pattern TAK TENTU = Intelligent-Tiering (no retrieval fee, auto-move, monitoring $0.0025/GB)

💡 Exam Scenario

"Unknown / changing / unpredictable access pattern, nak auto-optimize kos" → Intelligent-Tiering (no retrieval fee). "Frequently accessed data tapi team letak IA, bil naik" → patut Standard (retrieval fee makan penjimatan). "10-year retention, rarely accessed, petabytes, lowest cost" → Glacier Deep Archive via Lifecycle. "Rarely accessed BUT millisecond retrieval" → Glacier Instant Retrieval. "Re-creatable + infrequent, cheapest" → One Zone-IA. "Many small objects, infrequent" → elak IA (min 128KB billing) → Standard/Intelligent-Tiering.

🪤 Perangkap Soalan

Q: Data jarang diakses TAPI bila perlu kena dapat dalam millisecond (medical imaging). Tier mana paling murah?

⚠ Umpan: Glacier Deep Archive — sebab nampak 'jarang akses + paling murah'. SALAH: Deep Archive retrieve 12–48 jam, bukan ms.

✓ Betul: S3 Glacier Instant Retrieval — rarely accessed + millisecond retrieval, storan lebih murah dari Standard-IA. Keyword: 'millisecond' + 'rarely accessed'.

Q: Compliance simpan 10 tahun, petabytes, hampir tak pernah baca, kos paling rendah. Pilih?

⚠ Umpan: S3 Standard-IA — sebab 'infrequent access'. SALAH: IA masih $0.0125/GB, mahal untuk PB jangka panjang.

✓ Betul: S3 Glacier Deep Archive via Lifecycle Policy — $0.00099/GB, retrieve 12–48hr OK untuk archive. Keyword: '10-year retention, rarely accessed'.

Q: Team pindah data ke Standard-IA untuk jimat, tapi bil naik bukan turun. Kenapa?

⚠ Umpan: Anggap IA mesti lebih murah dari Standard sebab storage price lebih rendah ($0.0125 < $0.023).

✓ Betul: Data tu di-access KERAP → retrieval fee + minimum 30-day + min 128KB/objek makan balik penjimatan. IA hanya jimat kalau betul-betul infrequent (access < ~sekali sebulan) + objek besar. Access tak tentu → Intelligent-Tiering (no retrieval fee). Keyword: 'frequently accessed' + 'small objects' = JANGAN IA.

Q: Banyak objek KECIK (cth thumbnail 20KB) jarang access — nak letak One Zone-IA untuk jimat. OK?

⚠ Umpan: One Zone-IA storage paling murah antara IA → nampak pilihan jimat.

✓ Betul: Objek <128KB dalam IA/Glacier dibil macam 128KB (minimum billable object size) → jutaan objek kecik = bayar lebih dari saiz sebenar. Untuk objek kecik banyak, Standard atau Intelligent-Tiering selalunya lebih murah. Keyword: 'many small objects'.

🧠 Cara Mudah Ingat

→PRICING: 4 lapisan kos — storan $/GB-mo + retrieval fee/GB + min-duration penalty (delete awal bayar baki) + min billable object size 128KB (IA & Glacier). Storage price murah ≠ bil murah.
→PRICING: Storan/GB-mo — Standard $0.023 · Standard-IA $0.0125 · One Zone-IA $0.01 · Glacier Instant $0.004 · Flexible $0.0036 · Deep Archive $0.00099 (cheapest, ~23x murah dari Standard).
→PRICING: Retrieval fee — Standard & Intelligent-Tiering = $0. Standard-IA/One Zone-IA ~$0.01/GB. Glacier Instant ~$0.03/GB. Glacier Flexible/Deep Archive caj per restore job (Expedited mahal, Bulk murah).
→PRICING: Minimum storage duration — Standard none · IA 30 hari · Glacier (Instant/Flexible) 90 hari · Deep Archive 180 hari. Delete sebelum tempoh = still bayar baki (early-delete fee).
→PRICING: Minimum billable object size 128KB untuk IA & Glacier — objek <128KB dibil macam 128KB. Banyak objek kecik (thumbnail, log kecik) dalam IA = bayar lebih dari saiz sebenar. Guna Standard/Intelligent-Tiering.
→Intelligent-Tiering = satu-satunya class TIADA retrieval fee + auto-move antara tiers ikut access. Monitoring fee $0.0025/GB/mo (free untuk objek <128KB). Default untuk "unknown/changing access pattern".
→Break-even rule of thumb: IA jimat hanya kalau objek di-access < ~sekali sebulan DAN objek besar (>128KB) DAN simpan ≥ 30 hari. Kalau tak — Standard atau Intelligent-Tiering lebih murah.
→S3 Storage Class Analysis (analytics) tengok access pattern sebenar untuk cadang bila pindah Standard → Standard-IA. Guna kalau tak pasti sebelum set Lifecycle.
→Lifecycle transition ada caj per 1,000 transition requests — banyak objek kecik yang ditransition kerap boleh jadi mahal. Kira sebelum auto-transition jutaan objek.
→S3 One Zone-IA: SINGLE AZ — AZ musnah = data hilang. Re-creatable/reproducible data only. EFS One Zone-IA = analog EFS yang paling murah (single AZ + infrequent).

Guna Bila

Pilih tier yang paling MURAH all-in untuk access pattern data — cost-optimization (D4 angle, bukan retrieval-speed)

storage classescost optimizationlifecycle policyinfrequent accessglacierGlacier Instant RetrievalGlacier Deep ArchiveOne Zone-IAStandard-IAIntelligent-Tieringretrieval feeminimum storage durationearly delete feeminimum billable object size128KBbreak-evensmall objectsStorage Class Analysistransition request costpricing

📎 S3 storage classes (intro)📎 S3 storage classes comparison + pricing 📎 S3 pricing (retrieval & request fees)

D4 · Cost-Optimized

S3 Intelligent-Tiering

"AWS pilihkan tier yang paling murah secara auto"

🎯 Sebab Apa Wujud

Bila kau TAK BOLEH predict mana data akan dipanggil (cth video kadang viral, kadang mati), pilih tier manual jadi tekaan — silap pilih = bayar lebih atau kena retrieval fee. Intelligent-Tiering wujud supaya AWS auto-pindah objek antara access tier ikut pattern sebenar, tanpa retrieval fee. Bayar monitoring kecik ($0.0025/1K objek) tapi tak risau salah tier.

Apa Dia

Memindahkan objek secara automatik antara access tiers berdasarkan corak penggunaan

S3 Intelligent-Tiering — 5 access tier (objek auto-pindah)

Frequent Access → tier default masuk. Sama harga macam S3 Standard ($0.023/GB)

Infrequent Access → auto turun lepas 30 hari TAK akses. Sama harga Standard-IA ($0.0125/GB)

Archive Instant Access → auto turun lepas 90 hari tak akses. Retrieval ms (instant). ~$0.004/GB

Archive Access (optional) → kena ENABLE sendiri. Lepas 90-730 hari. Retrieval minit-jam (async)

Deep Archive Access (optional) → kena ENABLE sendiri. Lepas 180-730 hari. Retrieval 12 jam (async)

S3 Intelligent-Tiering — aliran auto antara tier

Rendering diagram…

INGAT exam: tier auto turun bila objek "sejuk", auto naik balik bila diakses — TANPA retrieval fee. 2 tier Archive paling bawah = optional + async retrieval. Trigger: "unpredictable / unknown access pattern".

Intelligent-Tiering vs pilih kelas manual — bila guna yang mana?

Situasi	Pilih	Sebab
Access pattern TAK boleh ramal	Intelligent-Tiering	AWS auto-tier, no retrieval fee, tak risau salah pilih
Tahu data kerap diakses	S3 Standard	Tak payah bayar monitoring fee
Tahu data jarang, tapi kena instant bila perlu	Standard-IA	Lagi murah dari Intelligent kalau pattern stabil
Tahu data arkib, OK tunggu jam	Glacier Flexible/Deep Archive	Paling murah, tapi ada retrieval delay + fee
Objek kecik banyak (<128KB)	Standard (bukan Int-Tier)	Objek <128KB tak turun tier; monitoring fee jadi membazir

Ingat: Discriminator: "unpredictable / changing / unknown access" → Intelligent-Tiering. Kalau pattern dah DIKETAHUI (kerap / jarang / arkib), pilih kelas manual lagi jimat sebab elak monitoring fee.

⚡ Quick Sifir — hafal ni

▪Auto-move antara tier ikut access pattern — NO retrieval fee bila tier berubah
▪Caj monitoring ~$0.0025 per 1,000 objek/bulan (selain storage)
▪Frequent → Infrequent auto lepas 30 hari tak akses
▪Archive Instant auto lepas 90 hari; retrieval masih INSTANT (ms)
▪2 tier dalam (Archive Access, Deep Archive Access) = OPTIONAL, kena enable + retrieval async
▪Objek <128KB tak pernah turun tier (kekal Frequent), tak kena monitoring fee
▪Best bila access pattern TAK MENENTU / tak dapat ramal

💡 Exam Scenario

Media company simpan assets — ada video yang viral tiba-tiba, ada yang tak pernah ditonton. Tak boleh predict mana yang akan kena access. Intelligent-Tiering auto-optimize kos tanpa perlu urus manually.

🪤 Perangkap Soalan

Q: Access pattern objek tak boleh diramal langsung, nak optimize kos automatik tanpa risiko retrieval fee. Pilih?

⚠ Umpan: Lifecycle Policy ke Standard-IA — sebab nampak 'optimize kos'. SALAH: lifecycle ikut UMUR objek (statik), bukan access sebenar; salah ramal = retrieval fee + kos lebih.

✓ Betul: S3 Intelligent-Tiering — auto-tier ikut access sebenar, no retrieval fee. Keyword: 'unpredictable / unknown access patterns'.

Guna Bila

Data dengan access pattern tak menentu

auto-tieringunpredictable accessno retrieval feesaccess tiersfrequent accessinfrequent accessarchive instant accessarchive accessdeep archive accessmonitoring feechanging access pattern128KB minimumS3 storage classespricing

📎 Amazon S3 Intelligent-Tiering storage class 📎 Managing Intelligent-Tiering archive tiers

🌐Networking Cost Optimization↑ Top

D4 · Cost-Optimized

CloudFront

Amazon CloudFront

"CDN yang jimatkan data transfer cost"

🎯 Sebab Apa Wujud

Tanpa CDN, setiap user di Asia/Europe tarik content terus dari origin (cth S3/EC2 di us-east-1) — jauh = lambat + bayar data transfer out penuh setiap kali. CloudFront wujud untuk cache content di edge location dekat user → request hit cache (tak sampai origin), latency turun & data transfer cost turun (transfer keluar dari CloudFront lebih murah dari EC2/S3 langsung).

Apa Dia

Mengurangkan kos data transfer dengan menyimpan cache content di edge locations

⚡ Quick Sifir — hafal ni

▪Cache di edge location dekat user → kurang origin hit + laju
▪Data transfer out via CloudFront lebih murah dari direct dari EC2/S3
▪OAC (Origin Access Control) = S3 bucket private, hanya CloudFront boleh akses
▪Static + dynamic content; integrate dengan WAF/Shield untuk security
▪TTL kawal berapa lama objek duduk dalam cache sebelum re-fetch origin

💡 Exam Scenario

Website ada users dari US, Europe, Asia. Tanpa CloudFront, setiap request kena bayar data transfer dari origin server. Dengan CloudFront, content cached kat edge location dekat user — jimat kos transfer + lagi laju.

🪤 Perangkap Soalan

Q: Global users complain laju lambat + bil data transfer dari S3 tinggi. Cara murahkan + cepatkan?

⚠ Umpan: Replicate S3 bucket ke banyak region (CRR) — sebab nampak 'dekatkan data'. SALAH: CRR gandakan kos storan + kau kena urus routing; tak selesaikan caching/transfer.

✓ Betul: Letak CloudFront depan S3 — cache di edge, kurang origin fetch, transfer lebih murah. Keyword: 'global users + reduce latency + reduce data transfer cost'.

Guna Bila

Reduce data transfer cost, cache content dekat user

reduce data transferedge cachingCDNcost saving

D4 · Cost-Optimized

VPC Endpoints

AWS VPC Endpoints

"Jalan dalam rumah, tak payah keluar internet"

🎯 Sebab Apa Wujud

EC2 dalam private subnet yang nak cakap dengan S3/DynamoDB biasanya kena keluar ikut NAT Gateway → bayar per-hour + per-GB processed (mahal kalau pukul S3 banyak). VPC Endpoint wujud supaya traffic ke AWS service pergi terus dalam AWS network (tak keluar internet) → buang NAT cost + lagi selamat (data tak lalu public internet).

Apa Dia

Menghubungkan VPC kepada perkhidmatan AWS secara terus tanpa melalui internet awam

⚡ Quick Sifir — hafal ni

▪Gateway Endpoint = S3 & DynamoDB SAHAJA — PERCUMA (route table entry)
▪Interface Endpoint (PrivateLink/ENI) = service lain — bayar per-hour + per-GB
▪Traffic tak keluar internet → no NAT Gateway data processing fee
▪Private subnet → S3/DynamoDB tanpa IGW/NAT = guna Gateway Endpoint
▪Lagi selamat: data stay dalam AWS network

💡 Exam Scenario

EC2 dalam private subnet selalu upload/download dari S3. Kalau guna NAT Gateway, kena bayar per GB. Pasang VPC Endpoint → traffic pergi terus dalam AWS network, no NAT fees, lagi jimat.

🪤 Perangkap Soalan

Q: EC2 private subnet upload banyak ke S3, bil NAT Gateway tinggi. Cara hapuskan kos itu untuk S3 traffic?

⚠ Umpan: Tambah lagi NAT Gateway / besarkan instance — sebab fikir 'throughput'. SALAH: tambah NAT = tambah kos, bukan buang.

✓ Betul: Pasang S3 Gateway VPC Endpoint (PERCUMA) — traffic S3 tak lalu NAT lagi. Keyword: 'private subnet → S3 + remove NAT cost'.

Guna Bila

EC2 → S3/DynamoDB tanpa kena NAT Gateway fees

no NAT feesprivate connectionS3 gatewayno internet

🗄️Database Cost Optimization↑ Top

D4 · Cost-Optimized

ElastiCache

Amazon ElastiCache

"Cache depan database, kurangkan DB load"

🎯 Sebab Apa Wujud

Pukul database berkali-kali untuk data SAMA (product listing, user session, leaderboard) mahal & lambat — DB kena scale up (mahal). ElastiCache wujud untuk simpan data panas dalam memory (sub-ms read) supaya DB tak terbeban, latency turun & kos turun. Kalau data sama diminta berjuta kali, cache je.

Apa Dia

Menyediakan in-memory caching untuk mengurangkan beban dan kos pada database utama

Pokok keputusan — Redis atau Memcached?

Rendering diagram…

INGAT exam: perlu persistence / replication / Multi-AZ / data structure kaya (leaderboard, session store, pub-sub) → Redis (default answer). Cuma perlu simple key-value, multi-threaded, horizontal scale → Memcached. TRAP: "session store tak boleh hilang" → Redis, BUKAN Memcached (Memcached data lenyap bila node fail).

Lazy Loading vs Write-Through — bila cache di-isi

Rendering diagram…

Lazy Loading = isi cache hanya bila cache MISS (jimat memory — simpan data yang pernah diminta je; risiko stale → fix dengan TTL; miss = 3 trips). Write-Through = update cache setiap kali WRITE ke DB (sentiasa fresh, takde miss penalty untuk data baru ditulis; tapi boros memory + write lambat sikit). INGAT exam: pattern paling common = Lazy Loading + TTL untuk imbang freshness vs saiz cache.

Redis vs Memcached

Aspect	Redis	Memcached
Data structures	Rich (lists, sets, sorted sets, pub/sub)	Simple key-value only
Persistence	✅ Snapshots / backup	❌ None — data lost on restart
Replication + Multi-AZ	✅ Yes (auto-failover)	❌ No
Threading	Single-threaded	🟢 Multi-threaded
Use case	Leaderboards, session store, pub/sub, HA cache	Simple cache, scale out horizontally

Ingat: Perlu persistence / replication / Multi-AZ / complex data → Redis. Perlu simple multi-threaded cache, horizontal scale → Memcached. Default exam answer biasanya Redis.

Caching strategies — Lazy Loading vs Write-Through

Aspect	Lazy Loading	Write-Through
Bila cache di-isi	Bila cache MISS (read dulu)	Setiap kali WRITE ke DB
Data dalam cache	Hanya yang pernah diminta	Semua yang pernah ditulis
Cache miss penalty	Ya — 3 trips (cache→DB→cache)	🟢 Tiada untuk data baru ditulis
Risiko stale data	Boleh stale (fix: TTL)	🟢 Sentiasa fresh
Kelemahan	First read lambat	Cache penuh data tak pernah dibaca + write latency naik

Ingat: Lazy Loading = isi bila diminta (jimat memory, boleh stale). Write-Through = isi masa tulis (fresh, tapi boros). Pattern paling common di exam: Lazy Loading + TTL untuk imbang freshness vs saiz cache.

⚡ Quick Sifir — hafal ni

▪Redis = rich data + persistence + replication + Multi-AZ (default exam answer)
▪Memcached = simple key-value, multi-threaded, NO persistence/replication
▪Lazy Loading = isi masa cache MISS (jimat memory, boleh stale → fix TTL)
▪Write-Through = isi masa WRITE (sentiasa fresh, tapi boros memory)
▪Session store / leaderboard / pub-sub → Redis

💡 Exam Scenario

E-commerce app — product listing query kena berjuta kali sehari. Tanpa cache, RDS kena scale up (mahal). Dengan ElastiCache (Redis), query popular disimpan dalam memory — RDS tak terlalu terbeban, kos lebih rendah.

🪤 Perangkap Soalan

Q: Perlu cache dengan persistence, replication & Multi-AZ failover (session store tak boleh hilang bila node fail). Pilih engine.

⚠ Umpan: Memcached — sebab "multi-threaded laju". SALAH: Memcached takda persistence/replication, data HILANG bila node restart/fail.

✓ Betul: ElastiCache for Redis (persistence + replication + Multi-AZ auto-failover).

🧠 Cara Mudah Ingat

→ElastiCache for Redis: sub-millisecond latency, key-value + data structures (lists, sets, sorted sets), persistence (snapshots), replication, Multi-AZ auto-failover
→ElastiCache for Memcached: multi-threaded, simple key-value only, NO persistence, NO replication — data hilang bila node restart/fail
→Redis vs Memcached: perlu persistence/replication/Multi-AZ/complex data structures (leaderboards, pub-sub) → Redis. Perlu simple cache, multi-threaded, horizontal scale ringkas → Memcached
→Session store pattern: simpan user session dalam Redis (persistence + Multi-AZ) supaya session tak hilang bila satu node fail
→Use cases: real-time leaderboards, session store, caching, real-time recommendation lookups
→Neptune = graph database (social networks, fraud detection). Redis = low-latency in-memory data store
→Exam: "real-time recommendations + low-latency reads AND writes at scale" → ElastiCache for Redis (not Neptune, not Aurora)
→Lazy Loading: load data ke cache ONLY bila ada request (cache miss → query DB → write to cache). Pro: cache tak penuh dengan data tak guna, node fail tak fatal. Con: cache miss = 3 trips (cache→DB→cache), data boleh jadi stale.
→Write-Through: setiap kali data ditulis ke DB, terus update cache sekali. Pro: cache data sentiasa fresh, tak ada cache miss penalty untuk written data. Con: cache penuh dengan data yang mungkin tak pernah dibaca (wasted space), write latency lebih tinggi.
→Exam: gabungkan lazy loading + TTL untuk imbangkan freshness vs cache size — pattern paling common

Guna Bila

Cache frequent queries, reduce RDS cost

RedisMemcachedin-memoryreduce DB loadcachingsub-millisecondleaderboardssession storelazy loadingwrite-throughcache missTTLmulti-threadedpersistencereplication

📎 Caching strategies (lazy loading & write-through)

D4 · Cost-Optimized

DynamoDB On-Demand

Amazon DynamoDB On-Demand

"Database bayar per request, zero urus capacity"

🎯 Sebab Apa Wujud

Provisioned capacity kena tetapkan RCU/WCU awal — kalau silap ramal, traffic spike = throttle (request gagal), traffic rendah = bayar capacity idle. DynamoDB On-Demand wujud untuk app yang traffic tak menentu / baru: bayar per-request je, auto-scale serta-merta, zero urus capacity. Tak payah teka, tak kena throttle masa spike.

Apa Dia

Menyediakan kapasiti database NoSQL yang skala secara automatik dan dikenakan caj berdasarkan permintaan sebenar

On-Demand vs Provisioned — dua capacity mode DynamoDB

Aspect	On-Demand	Provisioned (+ Auto Scaling)
Cara bayar	Per read/write REQUEST (RRU/WRU)	Per RCU/WCU PROVISIONED sejam (set awal)
Capacity planning	Tiada — auto-scale serta-merta	Kena anggar RCU/WCU; auto-scaling react lambat
Spike tiba-tiba	Handle instant (no throttle)	Boleh throttle sebelum auto-scale catch up
Kos bila traffic STEADY	Lebih MAHAL per-unit	Lebih MURAH (+ Reserved Capacity diskaun)
Kos bila traffic SPIKY/rendah	Lebih MURAH (bayar bila guna je)	Boros — bayar capacity idle
Sesuai untuk	App baru, traffic tak menentu, dev/test	Traffic predictable, sustained, high-volume

Ingat: Unknown/spiky/new + no capacity planning → On-Demand. Predictable steady high-volume → Provisioned (boleh tambah Reserved Capacity untuk diskaun besar). INGAT exam: keyword "unpredictable / unknown traffic" → On-Demand; "steady predictable + cost-optimize" → Provisioned.

⚡ Quick Sifir — hafal ni

▪On-Demand = bayar per read/write request, auto-scale, zero capacity planning
▪Provisioned = set RCU/WCU (boleh + auto-scaling) → lebih murah untuk traffic stabil/predictable
▪On-Demand per-request lebih MAHAL/unit dari Provisioned bila traffic steady
▪Spiky / unknown / new app → On-Demand; steady predictable → Provisioned
▪Boleh tukar mode On-Demand ↔ Provisioned (had sekali per 24 jam)

💡 Exam Scenario

App baru yang tak tahu lagi berapa reads/writes per second. DynamoDB On-Demand auto-scale dan kau bayar per request je — tak perlu provision capacity in advance. Kalau traffic rendah, bayar rendah.

🪤 Perangkap Soalan

Q: App baru, tak tahu corak traffic, mahu elak throttle masa spike & elak bayar capacity idle. Mode mana?

⚠ Umpan: Provisioned + Auto Scaling — sebab nampak 'auto-scale jugak'. SALAH: auto-scaling react LAMBAT, spike tiba-tiba boleh kena throttle sebelum sempat scale.

✓ Betul: DynamoDB On-Demand — instant accommodate spike, bayar per request. Keyword: 'unpredictable / unknown traffic + no capacity planning'.

🧠 Cara Mudah Ingat

→Tukar mode On-Demand ↔ Provisioned dibenarkan sekali setiap 24 jam
→On-Demand auto-handle spike instant — TAPI ada had: throttle kalau double previous peak dalam 30 minit (peak baru perlu masa naik)
→PRICING: (us-east-1) On-Demand = $1.25 per juta write request units (WRU) + $0.25 per juta read request units (RRU). Provisioned = WCU $0.00065/jam + RCU $0.00013/jam (≈ jauh lebih murah kalau utilization tinggi & stabil; tambah Reserved Capacity untuk diskaun sampai ~50–77%). Storan kedua-dua mode = $0.25/GB-bulan. Free tier = 25 GB storan + 25 WCU + 25 RCU (Provisioned sahaja, selamanya). Exam cost rule: On-Demand jimat HANYA bila traffic jauh di bawah sustained peak (spiky/rendah); traffic steady tinggi → Provisioned + Reserved.

Guna Bila

Unpredictable traffic, serverless apps

NoSQLpay per requestserverlessauto-scaleunpredictable trafficprovisioned capacityRCUWCUread request unitswrite request unitsreserved capacitycapacity modepricing

📎 DynamoDB read/write capacity modes (On-Demand vs Provisioned)📎 DynamoDB pricing

🔄DR Strategies (Cost vs RTO/RPO)↑ Top

D4 · Cost-Optimized

DR Cost Spectrum

Disaster Recovery — Cost vs RTO/RPO Spectrum

"Kiri murah+lambat → kanan mahal+laju. Bajet ketat + RTO puluhan minit = Pilot Light"

🎯 Sebab Apa Wujud

Wujud sebab tak semua org mampu bayar Multi-Site ($$$$) — exam D4 nak kau match requirement RTO/RPO dengan strategi PALING MURAH yang masih cukup. Financial institute dengan RTO ~20 minit + budget ketat = sweet spot Pilot Light: data sentiasa replicate (RPO minit), app OFF (jimat compute), RTO puluhan minit cukup — Warm Standby lebih laju (minit) tapi bayar full stack idle.

Apa Dia

Empat strategi DR AWS diukur pada spektrum kos vs kelajuan pulih. RPO = berapa banyak data boleh hilang (titik backup terakhir). RTO = berapa lama downtime sebelum app online balik. Makin kecil RPO/RTO → makin mahal infra backup yang kena jalan.

Empat strategi — apa yang berjalan bila bencana

Backup & Restore — tiada infra DR. Bencana → provision semua + restore backup. RTO/RPO jam. Kos $.

Pilot Light — data replicate & LIVE (DB on). App server OFF. Bencana → hidupkan app + scale. RTO/RPO puluhan minit. Kos $$.

Warm Standby — full stack scaled-down SENTIASA ON. Bencana → scale up + failover DNS. RTO/RPO minit. Kos $$$.

Multi-Site Active/Active — dua region full LIVE serentak. Bencana = tiada "recovery step". RTO/RPO real-time. Kos $$$$.

AWS DR spectrum — active/passive → active/active (diagram rasmi whitepaper)

Rendering diagram…

Sama macam AWS Disaster Recovery whitepaper — kiri→kanan = laju & mahal naik. INGAT exam D4: financial institute RTO/RPO ~20 min + "backup cost not very high" → Pilot Light (bukan Warm Standby walaupun RTO minit juga OK).

The 4 DR strategies — AWS whitepaper spectrum

Strategy	RTO / RPO	Cost	Active/passive?	What runs in DR
Backup & Restore	Hours	$	Passive	Backups only — provision ALL after disaster
Pilot Light	10s of minutes	$$	Passive	Data replicated LIVE; app servers OFF
Warm Standby	Minutes	$$$	Passive	Full stack scaled-DOWN, always ON
Multi-Site Active/Active	Real-time	$$$$	Active/active	Full production both regions LIVE

Ingat: Tiga kiri = active/passive (DR region tak melayan traffic penuh). Multi-Site = active/active. Pilih PALING MURAH yang masih meet RTO/RPO. ~20 min + budget → Pilot Light ($$).

⚡ Quick Sifir — hafal ni

▪RPO = data loss tolerance (⏪ ke belakang). RTO = downtime tolerance (⏩ ke hadapan)
▪Backup & Restore: RTO/RPO jam · $ — tiada infra DR berjalan
▪Pilot Light: RTO/RPO 10s of min · $$ — data live, app OFF
▪Warm Standby: RTO/RPO minit · $$$ — full stack ON kecil
▪Multi-Site active/active: real-time · $$$$ — zero downtime
▪"RTO ~20 min + budget tight" → Pilot Light, BUKAN Warm Standby

💡 Exam Scenario

Financial institute — critical web app, RTO/RPO ~20 minit, backup infra cost tak boleh tinggi → Pilot Light. Data sync aktif (RPO minit), app OFF (jimat), provision app selepas bencana (RTO puluhan minit). Warm Standby overkill kos; Backup & Restore terlalu lambat (jam); Multi-Site terlalu mahal.

🪤 Perangkap Soalan

Q: Financial institute — critical web app, RTO/RPO dalam 20 minit, backup infra cost tak boleh tinggi. Strategi mana?

⚠ Umpan: Warm Standby — RTO minit memenuhi 20 minit, stack scaled-down dah berjalan. Nampak betul sebab "cepat recover".

✓ Betul: Pilot Light — "10s of minutes" RTO/RPO cukup untuk ~20 min, data replicate aktif, app server OFF → kos lebih rendah. Warm Standby = app ON idle = $$$ extra. Multi-Site = $$$$. Backup & Restore = jam. Keyword "tens of minutes + budget / backup cost not very high" → Pilot Light.

Q: Soalan sebut "RTO dalam minit" — auto pilih Warm Standby?

⚠ Umpan: Ya — "minit" = Warm Standby. Nampak betul sebab whitepaper kata Warm Standby RTO minit.

✓ Betul: Baca BUDGET dulu. Pilot Light juga "10s of minutes" (puluhan minit) — kalau soalan tekan kos backup rendah, Pilot Light cukup walaupun RTO ~20 min. Warm Standby hanya bila perlu app ON idle untuk RTO lebih ketat ATAU soalan tak sebut budget.

Guna Bila

Pick the cheapest DR pattern that still meets stated RTO/RPO — exam loves budget + recovery-time trade-offs

DR spectrumRTORPOPilot LightWarm StandbyBackup and RestoreMulti-Siteactive/passiveactive/activebudget concernsfinancial institute20 minutescost-optimized DRpricing

📎 Disaster recovery options in the cloud (AWS whitepaper)