Design Resilient Architectures

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

DOMAIN 2 · 26% OF EXAM

Design Resilient Architectures

High Availability · Disaster Recovery · Backup & Storage Resilience

⚡High Availability & Scaling↑ Top

D2 · Resilient

Region & AZ

AWS Global Infrastructure — Region, Availability Zone, Edge

"Region = bandar · AZ = mall berasingan dalam bandar"

🎯 Sebab Apa Wujud

Wujud sebab kalau semua server kau dalam SATU bangunan dan bangunan tu terbakar/banjir/putus kuasa → semua mati. AWS pecahkan jadi banyak AZ yang berasingan secara fizikal (berkilometer jauh, grid kuasa lain) tapi cukup dekat untuk replicate SYNC tanpa lag. Jadi kau letak server merentas ≥2 AZ → satu AZ tumbang, yang lain terus jalan (itu maksud Multi-AZ). Region pula asingkan ikut geografi/undang-undang: kau pilih Region dekat user (latency rendah) atau Region yang patuhi data residency (cth data kena duduk dalam Malaysia/EU). Edge wujud sebab Region jauh dari user → cache kandungan di PoP berhampiran supaya laju.

Apa Dia

Ni peta dunia AWS. Region = satu kawasan geografi (cth ap-southeast-1 Singapore, us-east-1 N. Virginia) yang ada beberapa Availability Zone (AZ). AZ = satu atau lebih datacenter fizikal yang berasingan (kuasa, penyejuk, rangkaian sendiri) dalam Region tu, tapi disambung sesama sendiri dengan link laju (<2ms). Edge Location = ratusan PoP kecil global (CloudFront) untuk caching dekat user. Pilih Region = pilih di mana data & server kau "duduk".

Anatomi Global Infrastructure (besar → kecil)

Region → kawasan geografi (cth ap-southeast-1). Servis & harga berbeza ikut Region. Pilih ikut latency, kos, compliance/data residency, ketersediaan servis

Availability Zone (AZ) → 1+ datacenter fizikal berasingan dalam Region (kuasa/penyejuk/rangkaian sendiri). Berkilometer jauh tapi link <2ms. Min 3 AZ per Region biasanya

AZ ID (cth use1-az1) → ID fizikal tetap; nama AZ (us-east-1a) di-map rawak per account supaya beban seimbang. Guna AZ ID bila nak padan AZ across account (RAM/shared VPC)

Edge Location → 600+ PoP CloudFront global untuk cache & terminate TLS dekat user. BUKAN tempat run server kau

Local Zone → extension Region letak compute/storage dekat bandar besar (latency single-digit ms untuk metro tu)

Wavelength Zone → infra AWS dalam rangkaian 5G telco untuk mobile edge ultra-low latency

Geografi AWS — Region → AZ → datacenter (+ Edge global)

Rendering diagram…

INGAT exam: Region = bandar (geografi), AZ = datacenter berasingan dalam bandar tu (link <2ms sesama sendiri). Sebar across ≥2 AZ = Multi-AZ (tahan satu AZ jatuh). Edge = PoP cache global, BUKAN tempat run server. "survive AZ outage" → Multi-AZ; "survive Region outage / data residency" → Multi-Region.

Kaitkan dengan familiar — bandar & mall

Rendering diagram…

Bayangkan kedai kau ada cawangan dalam BEBERAPA mall (AZ) dalam satu bandar (Region) — satu mall kebakaran, cawangan mall lain terus jalan (Multi-AZ). Kalau seluruh bandar banjir besar, baru kau perlu cawangan di bandar lain (Multi-Region). INGAT: jangan buka Multi-Region (bandar lain) semata-mata untuk tahan satu mall terbakar — itu membazir.

Region vs AZ vs Edge vs Local Zone — pilih ikut keperluan

Lapisan	Apa dia	Guna bila (keyword)
Region	Kawasan geografi, ada banyak AZ	Data residency · pilih latency/kos · DR Multi-Region
Availability Zone	Datacenter berasingan fizikal dlm Region	HA — survive AZ outage (Multi-AZ)
Edge Location	PoP cache CloudFront, global	Latency rendah static/dynamic content · cache dekat user
Local Zone	Compute/storage dekat bandar besar	Single-digit ms untuk metro tertentu (gaming/media)
Wavelength	Infra dalam rangkaian 5G telco	Mobile edge ultra-low latency (5G app)

Ingat: Run server tahan kerosakan → AZ (Multi-AZ). Tahan bencana seluruh Region / data residency → Region (Multi-Region). Cache dekat user → Edge. Compute dekat metro → Local Zone. 5G mobile → Wavelength.

Multi-AZ vs Multi-Region (jangan keliru)

Aspect	Multi-AZ	Multi-Region
Lindung dari	Satu AZ / datacenter tumbang	Seluruh Region tumbang / bencana besar
Kos & kompleksiti	Rendah-sederhana	Tinggi (replicate data + DNS failover)
Latency replikasi	Sangat rendah (<2ms) → boleh SYNC	Tinggi → biasanya ASYNC
Data residency	❌ Tak selesaikan	🟢 Boleh pilih Region patuh undang-undang
Keyword exam	"survive AZ failure / HA"	"survive Region outage / DR / data sovereignty"

Ingat: Default HA = Multi-AZ (murah, cukup untuk 99% soalan "survive outage"). Naik ke Multi-Region HANYA bila exam sebut "entire Region down", "disaster recovery across regions", atau "data must stay in country". Jangan over-engineer Multi-Region untuk soalan AZ.

⚡ Quick Sifir — hafal ni

▪Region = geografi (bandar) · AZ = datacenter berasingan dalam Region (mall) · Edge = PoP cache global
▪Multi-AZ = tahan AZ outage (1 Region). Multi-Region = tahan Region outage + data residency
▪Min 3 AZ per Region (biasanya). Sebar ≥2 AZ = HA paling asas
▪AZ name (us-east-1a) di-map RAWAK per account → guna AZ ID (use1-az1) untuk padan across account
▪Pilih Region ikut: latency, kos, compliance/data residency, servis tersedia
▪Data dalam Region tak keluar Region melainkan kau pindah sendiri (asas data residency)
▪Edge ≠ compute kau — ia cache/CDN je. Run server → AZ

💡 Exam Scenario

"Survive satu datacenter / AZ outage" → sebar across Multi-AZ (dalam SATU Region). "Survive seluruh Region tumbang / bencana besar / data residency negara lain" → Multi-Region (DR). "Latency rendah untuk user global / cache static content" → Edge Location (CloudFront). "Compute ultra-dekat metro tertentu" → Local Zone. "5G mobile edge" → Wavelength.

🪤 Perangkap Soalan

Q: App mesti terus jalan walaupun satu Availability Zone tumbang sepenuhnya. Reka bentuk paling tepat & kos efektif?

⚠ Umpan: Deploy ke Multi-Region (replicate ke Region kedua) supaya sentiasa ada backup. Nampak betul sebab "sentiasa hidup".

✓ Betul: Sebar resource across MULTIPLE AZ dalam SATU Region (Multi-AZ) — cth ASG + ELB merentas 2-3 AZ. AZ memang direka berasingan secara fizikal, jadi satu AZ jatuh, AZ lain terus serve. Multi-Region itu untuk tahan seluruh REGION tumbang (mahal & kompleks, over-engineered untuk satu AZ). Keyword "survive AZ failure / single datacenter outage" → Multi-AZ, BUKAN Multi-Region.

Q: Syarikat kerajaan wajib SEMUA data pelanggan kekal dalam sempadan negara untuk pematuhan undang-undang. Apa kawalan asas?

⚠ Umpan: Enable Multi-AZ dan encryption supaya data selamat. Nampak betul sebab "data selamat = compliance".

✓ Betul: Pilih & hadkan kepada Region dalam negara tu (data residency) — data dalam satu Region tak keluar Region melainkan dipindah secara eksplisit. Multi-AZ/encryption bagus tapi tak jawab "data kena duduk negara mana". Boleh kuatkan lagi dengan SCP halang Region lain. Keyword "data must stay in country / data residency / sovereignty" → pilih Region yang betul (+ SCP region restriction).

Q: Dua AWS account kongsi subnet via shared VPC, tapi "us-east-1a" di account A nampak macam beza lokasi fizikal dari "us-east-1a" account B. Macam mana pastikan padan AZ fizikal yang sama?

⚠ Umpan: AZ name memang konsisten merentas account — us-east-1a sentiasa AZ fizikal sama. Nampak betul sebab nama sama.

✓ Betul: Nama AZ (us-east-1a) di-map RAWAK per account — "1a" account A boleh ≠ "1a" account B secara fizikal. Guna AZ ID (use1-az1) yang TETAP merentas semua account untuk padan AZ fizikal sebenar. Keyword "match AZ across accounts / consistent physical AZ" → AZ ID, BUKAN AZ name.

🧠 Cara Mudah Ingat

→AZ direka berasingan secara fizikal (kuasa/penyejuk/rangkaian sendiri) tapi disambung dengan link redundan latency rendah (<2ms) — itu sebab boleh replicate SYNC across AZ
→Setiap Region ada minimum 3 AZ (kebanyakannya); sebar ≥2 AZ untuk HA asas
→AZ name (us-east-1a) di-map rawak per account untuk seimbangkan beban; AZ ID (use1-az1) tetap merentas account — guna AZ ID bila nak padan AZ fizikal across account (shared VPC / RAM)
→Beberapa servis bersifat GLOBAL (IAM, Route 53, CloudFront, WAF for CloudFront), kebanyakan lain Regional (EC2, RDS, S3 bucket terikat Region walau nama global)
→PRICING: data transfer SAME AZ (private IP) = FREE. Cross-AZ dalam Region = $0.01/GB SETIAP arah (in + out). Cross-Region = ~$0.02/GB (varies). Egress ke Internet = ~$0.09/GB (10TB pertama). Data IN dari Internet = FREE.
→Exam cost trap: trafik antara AZ kena caj ($0.01/GB tiap arah) — sebab tu NLB cross-zone OFF by default (elak caj inter-AZ). "minimize data transfer cost" → kekalkan trafik dalam SATU AZ bila boleh, atau guna private IP.

Guna Bila

Faham geografi AWS — asas semua keputusan HA, DR, latency & data residency

regionavailability zoneAZAZ IDedge locationlocal zonewavelengthglobal infrastructuremulti-AZmulti-regiondata residencydata sovereigntycross-AZ data transferinter-AZlatencyCloudFront PoPphysical isolationdatacenterpricingdata transfer costsurvive AZ outagesurvive region outageglobal vs regional service

📎 AWS Global Infrastructure 📎 Regions, AZ & Local Zones

D2 · Resilient

Auto Scaling Groups

Amazon EC2 Auto Scaling

"Auto tambah/kurang server ikut demand"

🎯 Sebab Apa Wujud

Wujud sebab kalau kau provision server tetap (fixed), dua masalah: bila traffic spike (sale event) server tak cukup → website hang; bila traffic sepi server idle → bayar lebih sia-sia. ASG selesaikan dua-dua: auto TAMBAH instance bila beban naik (elastic, jimat masa sysadmin), auto KURANG bila sepi (jimat kos). Bonus HA: kalau instance mati / AZ jatuh, ASG auto ganti & sebar across AZ supaya min capacity sentiasa dijaga. Tujuan: elasticity + cost saving + self-healing.

Apa Dia

Menambah atau mengurangkan bilangan EC2 instances secara automatik berdasarkan policies, schedules, atau metrics

Scaling policies — pilih cara scale ikut corak traffic

Policy	Macam mana ia scale	Guna bila
Target Tracking	Kekalkan 1 metric pada target (cth CPU 50%) — auto naik/turun	🟢 Default & paling senang — most workloads
Step Scaling	Adjustment berbeza ikut SAIZ breach (CPU 60%→+1, 90%→+3)	Perlu reaksi bertingkat ikut keterukan beban
Simple Scaling	1 adjustment per alarm, tunggu cooldown dulu	Legacy — guna Step/Target instead
Scheduled	Scale pada masa tetap (cth Isnin 9am +5)	Traffic ikut jadual yang DIKETAHUI
Predictive	ML forecast beban, scale AWAL sebelum spike	Traffic berulang / cyclical (proactive)

Ingat: Senang + default → Target Tracking. Tahu jadual → Scheduled. Corak berulang → Predictive (scale dulu sebelum spike). Reaksi ikut keterukan → Step. Cooldown elak scale berulang terlalu cepat; warm-up bagi instance baru "matang" sebelum dikira dalam metric.

Konsep asas: HA vs Fault Tolerance vs Scalability vs Elasticity vs Throughput

Konsep	Maksud mudah	Keyword exam
High Availability (HA)	Sistem kekal hidup, tapi failover ambil masa sekejap (~minit). Ada gap kecil.	minimize downtime · failover · multi-AZ · eliminate SPOF
Fault Tolerance (FT)	ZERO downtime — backup ambil alih real-time, user tak perasan langsung.	zero downtime · no interruption · mission-critical · continuous
Scalability	Boleh tampung beban makin besar (manual/auto). Up (vertical) atau out (horizontal).	handle growth · increase capacity · scale up / scale out
Elasticity	Auto tambah server bila sibuk + auto buang bila lengang (cost-optimize).	dynamic demand · auto scale up AND down · cost optimization
Throughput	Berapa banyak data/request lalu per saat (Mbps/Gbps).	high throughput · bandwidth · transfer large files · Mbps/Gbps

Ingat: HA = downtime MINIMUM (ada failover gap); FT = downtime SIFAR (real-time takeover). Scalability = boleh besar; Elasticity = auto besar+kecik. Throughput = laju aliran data. Exam: "zero downtime / no interruption" → FT; "minimize downtime / failover" → HA; "auto scale up AND down to match demand" → Elasticity; "handle more load" → Scalability. Vertical = upgrade saiz (Scale Up, perlu restart); Horizontal = tambah instance (Scale Out, pilihan AWS).

⚡ Quick Sifir — hafal ni

▪ASG = horizontal scaling (tambah/kurang instance), BUKAN vertical (besarkan saiz)
▪Default & paling senang → Target Tracking (kekal metric pada target, cth CPU 50%)
▪Tahu jadual (Isnin 9am) → Scheduled. Corak berulang/cyclical → Predictive (scale awal)
▪min = HA floor (set ≥2 across AZ), desired = sekarang, max = siling
▪Phase out AMI lama masa scale-in → OldestLaunchTemplate termination policy
▪ASG sendiri FREE — bayar EC2 yang dilancarkan je
▪Scale on SQS queue backlog → custom metric (ApproximateNumberOfMessagesVisible / backlog per task), BUKAN CPU/Memory (CPU buta terhadap queue depth — container proses satu-satu)
▪Lifecycle hooks: PAUSE instance sebelum terminate (wait state, default 1 jam) → sempat copy data/log keluar sebelum mati. Bukan cooldown (itu delay antara scaling action)

💡 Exam Scenario

E-commerce traffic spike masa sale event — ASG scale out bila CPU >70%, tambah EC2 instances automatik. Bila traffic turun, scale in untuk jimat kos. Set minimum=2 untuk high availability.

🪤 Perangkap Soalan

Q: Aplikasi web makin perlahan bila traffic naik. Pasukan nak guna instance lebih besar (vertical) secara automatik bila CPU tinggi. Pendekatan AWS yang betul?

⚠ Umpan: Konfigur Auto Scaling untuk auto-tukar ke instance type lebih besar (scale UP) bila CPU tinggi. Nampak betul sebab "scale automatik bila CPU tinggi".

✓ Betul: ASG buat HORIZONTAL scaling — tambah lebih banyak instance (scale out), bukan besarkan instance sedia ada. Letak instance di belakang ELB + ASG dengan Target Tracking pada CPU. Vertical scaling (tukar saiz) perlukan stop/restart, bukan apa yang ASG buat. Keyword "scale automatically with load" → ASG scale out (horizontal).

Q: Traffic melonjak setiap hari jam 8 malam (corak yang DIKETAHUI & berulang), dan ASG yang reaktif sentiasa lambat sikit sampai user kena lag awal-awal lonjakan. Penambahbaikan?

⚠ Umpan: Turunkan threshold Target Tracking (cth CPU 30%) supaya scale lebih awal. Nampak betul sebab "scale lebih awal".

✓ Betul: Guna Scheduled scaling (kerana masa diketahui) atau Predictive scaling (ML forecast corak berulang) untuk tambah kapasiti SEBELUM lonjakan. Target Tracking sentiasa reaktif (tunggu metric naik dulu). Keyword "known schedule / recurring pattern / scale ahead of spike" → Scheduled / Predictive.

Q: Masa campaign, trafik web naik 500%. Pasukan nak handle lonjakan tapi kekalkan kos rendah DAN app mesti kekal fault-tolerant walau instance kena ambil balik. Konfigurasi ASG mana?

⚠ Umpan: Set ASG guna Spot Instances 100% sebab 90% lebih murah. Nampak betul sebab "kos rendah + scale". TAPI kalau AWS rampas balik semua Spot serentak masa burst, app crash — bukan fault-tolerant.

✓ Betul: ASG dengan Mixed Instances Policy: baseline On-Demand (cth min 2-3 instance yang AWS tak rampas = jaminan tak mati) + selebihnya Spot (jimat 90% masa burst). Spot kena rampas → On-Demand tahan app + ASG auto cari Spot type lain ganti. Keyword "lowest cost + fault-tolerant + handle spike" → ASG Mixed Instances Policy (On-Demand baseline + Spot), BUKAN Spot 100%.

Q: Sistem mission-critical kena ZERO downtime — walau satu komponen rosak, user langsung tak boleh perasan apa-apa gangguan. Konsep mana paling tepat?

⚠ Umpan: High Availability (Multi-AZ). Nampak betul sebab HA memang pasal "sistem tak mati" + failover automatik.

✓ Betul: Fault Tolerance. HA masih ada GAP failover sekejap (~minit) — user mungkin rasa sangkut. FT = takeover REAL-TIME, sifar saat gangguan. Keyword "zero downtime / no interruption / mission-critical" = Fault Tolerance, BUKAN HA. (Contoh FT: Aurora replicas + Route 53 active-active.)

🧠 Cara Mudah Ingat

→Termination Policies — menentukan instance MANA yang ditamatkan semasa scale in:
→OldestLaunchTemplate → terminate instances guna launch template LAMA (guna ni untuk rolling AMI updates — pastikan instances lama diganti dengan yang baru)
→OldestInstance → terminate instance yang PALING LAMA berjalan (bukan template, tapi instance age)
→ClosestToNextInstanceHour → terminate instance yang paling dekat dengan next billing hour (optimise kos)
→AllocationStrategy → untuk Spot instances, terminate berdasarkan allocation strategy
→Default policy: OldestLaunchConfiguration → OldestInstance → ClosestToNextInstanceHour
→Exam: "phase out old AMI, replace with new" → OldestLaunchTemplate termination policy
→Queue-based scaling: bila consumer tarik kerja dari SQS, scale ikut queue backlog (custom metric ApproximateNumberOfMessagesVisible atau backlog per task = queue depth ÷ target capacity) guna Target Tracking, BUKAN CPU/Memory. CPU/Memory maintain rendah sebab container proses satu-satu → tak scale walau queue meletup. Keyword "scale ECS/EC2 based on SQS queue" → custom metric backlog.
→Lifecycle Hooks: bila ASG terminate instance (scale-in / Spot rampas), hook PAUSE instance ke wait state (default 1 JAM) → sempat invoke Lambda / connect ke instance untuk copy critical data atau drain sebelum mati. Notifikasi via EventBridge. BUKAN cooldown (cooldown = delay antara scaling action, bukan selamatkan data). BUKAN termination policy (itu pilih instance MANA nak terminate). Exam: "copy data before instance termination / data loss on scale-in" → Lifecycle Hooks.

Guna Bila

Automatically scale EC2 instances based on load

horizontal scalingscale out/inlaunch templatescaling policiesdesired capacitymin/maxOldestLaunchTemplatetermination policyAMI rolloutMixed Instances PolicyOn-Demand baselineSpotfault-tolerantcost optimization spikehigh availabilityfault tolerancescalabilityelasticitythroughputvertical scalingscale upzero downtimeeliminate single point of failurecustom metricSQS backlogApproximateNumberOfMessagesVisiblebacklog per taskqueue-based scalinglifecycle hooks

D2 · Resilient

RDS Multi-AZ

Amazon RDS Multi-AZ Deployment

"Backup database sedia tunggu dalam AZ lain"

🎯 Sebab Apa Wujud

Kalau primary DB mati (AZ outage, hardware rosak, masa patching), normally app down sampai kau restore manual — boleh berjam. Multi-AZ wujud supaya ada standby IDENTICAL dalam AZ lain yang AWS auto-promote. Downtime turun dari jam → ~1-2 minit, tanpa kau buat apa-apa. Tujuan dia TAHAN bencana (HA), bukan buat laju.

Apa Dia

Menyimpan satu salinan database standby dalam Availability Zone berbeza yang akan take over secara automatik jika primary fail

Anatomy failover — endpoint SAMA flip ke standby

App

1 endpoint (DNS)

Primary DB

AZ-a · read + write

Standby DB

AZ-b · idle, no reads

Sync replication Primary → Standby (sentiasa identical). AZ-a fail → AWS auto-flip DNS endpoint ke Standby (AZ-b) dalam ~60–120s; app guna endpoint yang SAMA, tak payah tukar config. Standby TAK serve reads — nak offload reads guna Read Replica.

Multi-AZ vs Read Replica vs dua-dua — pilih yang mana (decision tree)

Rendering diagram…

Tiga benda beza tujuan: Multi-AZ = tahan outage (HA). Read Replica = scale read / read global. Dua-dua boleh dipakai serentak. INGAT exam: "survive AZ outage / auto-failover" → Multi-AZ. "reporting slow down production / global read access" → Read Replica. Multi-AZ = SYNC same-region, Read Replica = ASYNC boleh cross-region.

Analogi — Multi-AZ = genset standby · Read Replica = kaunter baca tambahan

Rendering diagram…

Multi-AZ = genset standby: tunggu diam, auto-ganti bila primary mati — tujuan TAHAN bencana, bukan tambah laju (genset tak layan customer masa normal = standby idle, no reads). Read Replica = buka kaunter baca tambahan: kurangkan beban kaunter utama, boleh letak di cawangan jauh (cross-region) — tujuan SCALE baca. INGAT exam: outage → genset (Multi-AZ); reporting/global read → kaunter tambahan (Read Replica).

Multi-AZ vs Read Replicas — THE classic exam comparison

Aspect	Multi-AZ	Read Replicas
Purpose	High availability (failover)	Scale read traffic
Replication	🟢 Synchronous	🟡 Asynchronous
Standby usable?	❌ Standby idle — no reads	✅ Serves read queries
Failover	Automatic (~1–2 min)	Manual — can promote to standalone
Region	Same region (across AZs)	Same OR cross-region
How many	1 standby	Up to 15

Ingat: Multi-AZ = HA / disaster survival (same region). Read Replicas = read scaling + cross-region reads. Soalan "reporting queries slow down prod" → Read Replica. "Survive an AZ outage" → Multi-AZ. Boleh guna dua-dua sekali.

Segitiga Emas RDS — Multi-AZ vs Read Replica vs Backup (3-hala)

Aspect	Multi-AZ	Read Replica	Backup / Snapshot
Masalah yang dia selesai	AZ outage / hardware fail / patching	read-heavy queries cekik prod	human error / data corrupt / tersalah delete
Solusi	🟢 standby sync, auto-failover ~1-2min	🟡 async copy, offload read	🔵 point-in-time recovery / restore
Replication	Synchronous	Asynchronous	— (snapshot, bukan live copy)
Bila pulih?	Automatik (DNS flip)	Manual (promote to standalone)	Manual restore → instance BARU
Kategori	High Availability	Performance Scaling	Data Recovery

Ingat: Tiga penjuru beza tujuan: "survive AZ outage / auto-failover" → Multi-AZ (HA). "reporting slow down prod / global read" → Read Replica (scaling). "tersalah delete / corrupt / restore ke masa lalu" → Snapshot/PITR (recovery). Soalan exam tembak ikut PUNCA masalah, bukan nama service.

DUA jenis "Multi-AZ" — DB Instance vs DB Cluster (jangan keliru)

Aspect	Multi-AZ DB Instance	Multi-AZ DB Cluster
Bentuk	1 primary + 1 standby	1 writer + 2 readable standbys
AZ	2 AZ	🟢 3 AZ
Standby boleh dibaca?	❌ Standby IDLE — no reads	✅ 2 reader BOLEH serve reads
Replication	Synchronous	Semisynchronous (tunggu 1 reader je)
Failover	~60–120s	🟢 Biasanya < 35s
Write latency	Baseline	🟢 Lower (semisync, tak tunggu semua)
Engine	MySQL, PostgreSQL, MariaDB, Oracle, SQL Server	MySQL & PostgreSQL SAHAJA

Ingat: Default "Multi-AZ" exam maksudkan DB INSTANCE (1 standby idle, no reads — ni yang semua perangkap lain rujuk). Multi-AZ DB CLUSTER (2022) = 1 writer + 2 readable standby, 3 AZ, failover laju (<35s), reader BOLEH baca = HA + sikit read capacity sekali. Keyword "readable standby / faster failover / lower write latency + MySQL/PostgreSQL" → DB Cluster. AWASS: Multi-AZ DB Cluster ≠ Aurora cluster (Aurora = storan kongsi 6-copy/3-AZ, sampai 15 reader).

⚡ Quick Sifir — hafal ni

▪Multi-AZ = HIGH AVAILABILITY, BUKAN read scaling
▪Replication SYNC; standby IDLE (tak serve read langsung)
▪Failover auto ~60-120s, endpoint SAMA (DNS flip) — app tak tukar config
▪Same region je (across AZ). Cross-region → Read Replica / Aurora Global DB
▪1 standby sahaja (ni DB Instance — default exam)
▪Multi-AZ DB CLUSTER = 1 writer + 2 readable standby, 3 AZ, failover <35s (MySQL/PostgreSQL je)
▪RDS encryption-at-rest: set masa CREATE instance je — TAK boleh modify existing unencrypted in-place
▪Encrypt existing unencrypted RDS: snapshot → COPY snapshot (enable encryption + KMS key) → restore NEW encrypted instance → update app endpoint → buang lama
▪Read Replica WARISI encryption source: primary unencrypted → replica unencrypted (same-region, tak boleh encrypted). Buang RR lama, create RR baru dari encrypted primary → auto encrypted

💡 Exam Scenario

Production RDS kat AZ-1 fail — automatic failover ke standby kat AZ-2 dalam 1-2 minit. Same connection endpoint, app tak perlu tukar config. BUKAN untuk scale reads — guna Read Replicas untuk tu.

🪤 Perangkap Soalan

Q: Reporting queries tengah perlahankan production RDS. Solution paling sesuai?

⚠ Umpan: Enable Multi-AZ — nampak macam "tambah satu lagi DB jadi laju". SALAH: standby Multi-AZ IDLE, tak serve read langsung.

✓ Betul: Read Replica (offload read traffic). Keyword "reporting / read queries slow down prod" → Read Replica.

Q: Database kena survive AZ outage dengan downtime minimum & auto recovery. Pilih satu.

⚠ Umpan: Read Replica + promote — boleh, tapi "promote" tu MANUAL = bukan auto, RTO lama.

✓ Betul: Multi-AZ (synchronous standby, auto-failover ~1-2 min). Keyword "survive AZ outage / automatic failover" → Multi-AZ.

Q: Perlu HA + standby yang BOLEH serve read + failover lebih laju, guna MySQL/PostgreSQL. Pilih satu.

⚠ Umpan: Multi-AZ DB Instance — nampak betul sebab "Multi-AZ". SALAH: DB Instance standby IDLE (no reads), failover ~60-120s je.

✓ Betul: Multi-AZ DB CLUSTER (1 writer + 2 readable standby, 3 AZ, failover <35s). Keyword "readable standby + faster failover + MySQL/PostgreSQL" → DB Cluster, BUKAN DB Instance.

Q: Security audit jumpa RDS MySQL instance unencrypted + Read Replica (same region) pun unencrypted. Fix secepat mungkin. Cara betul?

⚠ Umpan: Modify running instance → enable encryption in-place, lepas tu encrypt Read Replica terus. SALAH: butang "turn on encryption" pada existing RDS TAK WUJUD — encryption cuma set masa CREATE. Dan Read Replica tak boleh encrypt terus dari source unencrypted.

✓ Betul: Snapshot primary → COPY snapshot (tick Enable Encryption + pilih KMS key) → restore NEW encrypted instance → update app endpoint → buang lama. Lepas tu buang RR unencrypted, create Read Replica BARU dari encrypted primary (auto encrypted, warisi source). Keyword: "encrypt existing unencrypted RDS" = snapshot→copy→restore, BUKAN modify in-place.

🧠 Cara Mudah Ingat

→Automated backups: AWS backup daily (snapshot volume during backup window) + transaction logs di-upload ke S3 setiap 5 MINIT → RPO ~5 minit, boleh restore ke ANY point-in-time dalam retention period (1-35 hari). Auto-deleted bila instance dipadam.
→Manual snapshots: kau trigger sendiri, bila-bila masa — KEKAL walaupun RDS instance dipadam. Guna untuk "before major upgrade" atau long-term retention.
→Restore dari snapshot/PITR = create instance BARU dengan endpoint BARU — bukan restore in-place
→Exam: "retain backup walaupun delete DB instance" → manual snapshot (automated backups deleted together with instance)

Guna Bila

High availability for RDS — automatic failover

automatic failoverstandbydifferent AZsync replicationsame endpointHA onlyautomated backupsmanual snapshotpoint-in-time restoreretention periodMulti-AZ DB clusterMulti-AZ DB instancereadable standbysemisynchronoustwo readable standbysthree AZfaster failover

📎 Multi-AZ deployments for high availability 📎 Multi-AZ DB cluster deployments

D2 · Resilient

RDS Read Replicas

Amazon RDS Read Replicas

"Photocopy database untuk baca je — boleh cross-region"

🎯 Sebab Apa Wujud

Satu primary DB ada had — terlalu banyak read (reporting, analytics, global users) boleh cekik dia, dan write pun jadi slow. Read Replica wujud untuk offload semua read ke salinan read-only (boleh letak region lain dekat user) supaya primary fokus pada write je. Bonus: replica boleh dipromote jadi standalone = pilihan DR.

Apa Dia

Mencipta salinan database read-only untuk mengagihkan beban queries baca. Async replication dari primary. Boleh cross-region — master kat Frankfurt, replicas kat US, Singapore, Tokyo untuk serve local users laju. Up to 15 read replicas. Boleh promoted to master untuk DR.

Contoh Guna

Multinational company: master DB kat EU-Frankfurt, cross-region read replicas kat US, AP, SA — local users baca dari nearest replica tanpa hantar semua traffic ke Frankfurt.

Analogi kedai mamak — chef simpanan vs tambah pelayan

Rendering diagram…

Analogi kedai mamak: Multi-AZ = chef simpanan — gaji tetap tapi DUDUK DIAM (standby pasif, tak boleh dibaca), cuma ambil alih bila chef utama tumbang (auto-failover, HA). Read Replica = tambah pelayan untuk ambil order BACA (read) supaya kaunter utama (write) tak sesak — aktif, async, sampai 15 orang. INGAT exam: "survive AZ outage" → Multi-AZ; "reporting slow down prod / global read" → Read Replica. Jangan terbalik.

Multi-AZ vs Read Replica — beza paling kerap kena tanya

Aspect	Multi-AZ	Read Replica
Tujuan	🟢 HA / auto-failover	Read scaling + cross-region read
Replication	Synchronous (sync)	Asynchronous (boleh lag)
Region	Same region (standby di AZ lain)	🟢 Same ATAU cross-region
Boleh dibaca?	❌ Standby PASIF (tak boleh baca)	🟢 Aktif — read-only, layan query
Failover	🟢 Automatik (1-2 min)	Manual — kena PROMOTE jadi standalone
Bilangan	1 standby je	🟢 Up to 15
Guna bila	Survive AZ outage	Reporting/analytics cekik prod, global read

Ingat: Keyword "survive AZ outage / HA / auto-failover" → Multi-AZ (standby PASIF, tak boleh baca). Keyword "reporting slow down production / scale reads / global low-latency read" → Read Replica (aktif, async). Multi-AZ ≠ scaling; Read Replica ≠ auto-HA. Mission-critical + busy reads → guna DUA-DUA sekali (Multi-AZ untuk HA + Read Replicas untuk read).

⚡ Quick Sifir — hafal ni

▪Read Replica = READ SCALING (+ cross-region read), BUKAN HA
▪Replication ASYNC (boleh lag sikit, eventual)
▪Up to 15 per primary; boleh buat replica-of-replica
▪Boleh PROMOTE → standalone DB (option DR)
▪Cross-region replica = local read laju + DR region lain

💡 Exam Scenario

Multi-region database design → RDS cross-region Read Replicas. Reporting queries slow down production → create Read Replica in same/different region, point reporting app ke replica. INGAT: Multi-AZ = same region HA (failover). Read Replicas = read scaling + cross-region reads.

🪤 Perangkap Soalan

Q: Nak DR untuk RDS (bukan Aurora): kalau region utama down, ada DB region lain boleh ambil alih. Guna apa?

⚠ Umpan: Multi-AZ — ramai ingat Multi-AZ = DR. SALAH: Multi-AZ same-region je, tak lindung kalau SELURUH region outage.

✓ Betul: Cross-region Read Replica, promote jadi standalone bila region utama down. (Aurora → Global Database.)

🧠 Cara Mudah Ingat

→Multi-AZ = HIGH AVAILABILITY (same region, synchronous, auto-failover). Read Replica = READ SCALING (async, can be cross-region)
→Cross-region Read Replica untuk: (1) local read access untuk global users, (2) DR in another region
→Read Replica boleh dipromote jadi master — guna untuk DR bila primary region down
→Up to 15 read replicas per primary. Boleh create replica of replica

Guna Bila

Scale read traffic, reporting queries, multi-region read access

read scalingasync replicationcross-regionup to 15 replicasread-onlymulti-regionpromote to master

📎 RDS Read Replicas

D2 · Resilient

RDS Proxy

Amazon RDS Proxy

"Perantara yang pool connections — jimat RDS dari connection tsunami"

🎯 Sebab Apa Wujud

Lambda / Auto Scaling boleh buka beribu connection serentak — tapi RDS ada had connection & tiap connection makan memory. Akibatnya "too many connections" error & DB pengsan. RDS Proxy wujud sebagai orang tengah yang pool & reuse connection, supaya RDS nampak bilangan kecil je walaupun beribu app instance.

Apa Dia

RDS Proxy duduk antara application dan RDS, multiplex connections. Bila Lambda scale up kepada 1000 instances, RDS Proxy pool connections — RDS hanya nampak bilangan connections yang manageable. Mengatasi "too many connections" errors.

Analogi operator telefon — pool connection supaya RDS tak banjir

Rendering diagram…

Analogi operator telefon: tanpa RDS Proxy, beribu Lambda call terus CEO (RDS) → "too many connections", DB pengsan. RDS Proxy = operator yang POOL & reuse talian terhad — CEO nampak sikit connection je walaupun beribu caller. Bonus: masa DB failover, Proxy tahan connection (app tak nampak putus penuh, ~66% lagi laju). INGAT exam: "too many connections" + Lambda/Auto Scaling → RDS Proxy (BUKAN Read Replica — itu untuk read load, bukan connection count).

⚡ Quick Sifir — hafal ni

▪RDS Proxy = CONNECTION POOLING, BUKAN read scaling / query speed
▪Selesai: "too many connections", idle connections, connection exhaustion
▪Power combo dengan Lambda (scale drastik, buka/tutup connection laju)
▪Failover lagi laju (~66% kurang), tahan connection masa DB flip
▪Sokong IAM auth + Secrets Manager untuk credentials

💡 Exam Scenario

"Lambda functions causing too many RDS connections" → RDS Proxy. "Idle connections from Auto Scaling EC2" → RDS Proxy. Read Replicas = read scaling. Multi-AZ = HA. RDS Proxy = connection management.

🪤 Perangkap Soalan

Q: Lambda app bila scale tinggi keluar error "too many connections" ke RDS. Fix?

⚠ Umpan: Tambah Read Replica — nampak macam "agih beban". SALAH: masalah ni bilangan CONNECTION, bukan read load.

✓ Betul: RDS Proxy (pool & multiplex connections). Keyword "too many connections + Lambda/RDS" → RDS Proxy.

Q: App atas EC2 Auto Scaling guna RDS MySQL. Bila ASG scale out, banyak idle connection bertimbun, RDS hampir cecah connection limit & query jadi lembab. Pilih: (A) RDS Proxy, (B) naikkan instance class RDS untuk lebih CPU/RAM, (C) tukar Multi-AZ, (D) tambah Read Replica.

⚠ Umpan: B (instance lebih besar) & D (Read Replica) nampak betul sebab query "lembab" → org ingat masalah compute/read. C (Multi-AZ) umpan untuk yang baca "hampir limit" sebagai isu availability. Semua SALAH puncanya: punca = bilangan CONNECTION dari ASG yang naik-turun, bukan CPU, bukan read load, bukan HA.

✓ Betul: A — RDS Proxy. Dia POOL & reuse connection, jadi walaupun ASG tambah/buang EC2, RDS nampak sikit connection je → idle connection hilang, limit tak cecah. Keyword: "Auto Scaling + idle/too many connections" → RDS Proxy.

🧠 Cara Mudah Ingat

→RDS Proxy solves: "too many connections", "idle connections", "connection exhaustion"
→Bukan untuk slow query performance — guna Read Replicas atau upgrade instance untuk query scaling
→Bukan untuk read scaling — guna Read Replicas untuk distribute read load
→Sangat berguna dengan Lambda (yang scale drastically dan close/open connections rapidly)
→Supports IAM authentication + Secrets Manager integration untuk credentials
→Faster failover: masa RDS/Aurora failover, Proxy tahan incoming connections & route ke DB baru — kurangkan failover time sehingga ~66%, app tak nampak full disconnect
→Analogi: RDS Proxy = operator telefon 📞 — beratus caller (Lambda) tak terus call CEO (RDS); operator pool & sambung guna talian terhad supaya CEO tak dibanjiri "too many connections".

Guna Bila

Connection pooling for RDS — handle too many connections from Lambda/Auto Scaling

connection poolingtoo many connectionsLambda scalingidle connectionsconnection multiplexingfaster failoverIAM authenticationSecrets Manager

D2 · Resilient

Global Accelerator

AWS Global Accelerator

"Highway AWS untuk user seluruh dunia"

🎯 Sebab Apa Wujud

Wujud sebab traffic yang melalui public internet melintasi banyak ISP/router yang slow & tak menentu — latency naik turun, kadang putus. Global Accelerator bagi user masuk AWS backbone secepat mungkin di edge terdekat, lepas tu jalan dalam "lebuhraya peribadi" AWS yang laju & stabil ke region. Lebih dari itu: dia bagi 2 STATIC anycast IP (tak berubah) supaya IoT/firewall boleh whitelist sekali, dan failover cross-region <30s tanpa tunggu DNS propagate. Tujuan: routing TCP/UDP global laju + static IP + failover pantas.

Apa Dia

Menggunakan AWS global network untuk route traffic ke endpoint yang paling dekat dan sihat, bukan melalui internet awam

Global Accelerator vs CloudFront — dua-dua guna AWS edge, tapi beza tujuan

Aspect	Global Accelerator	CloudFront
Tujuan utama	Optimize ROUTING ke regional endpoint	CACHE content dekat user (CDN)
Protocol	🟢 TCP/UDP (apa-apa app)	HTTP/HTTPS sahaja
Caching	❌ Tiada — proxy traffic terus	🟢 Ya, cache kat edge
Entry point	2 static anycast IP	Domain (dxxxx.cloudfront.net)
Endpoint	ALB, NLB, EC2, Elastic IP	S3, ALB, custom origin (HTTP)
Best untuk	Gaming, IoT, VoIP, non-HTTP, fixed IP, failover Region <30s	Website, video/image, static + dynamic web

Ingat: Content boleh cache + HTTP → CloudFront. TCP/UDP atau perlu static IP (gaming/IoT/VoIP) atau cross-Region failover pantas → Global Accelerator. Boleh combine: CloudFront depan untuk caching, GA untuk non-HTTP.

⚡ Quick Sifir — hafal ni

▪GA = optimize ROUTING via AWS backbone (TCP/UDP). CloudFront = CACHE content (HTTP) — beza tujuan
▪GA bagi 2 STATIC anycast IP — tak berubah, bagus untuk whitelist & IoT hard-coded IP
▪GA TIADA caching — proxy traffic terus ke ALB/NLB/EC2/EIP
▪Cross-region failover GA <30s (tak tunggu DNS TTL/propagation)
▪Non-HTTP / gaming / VoIP / IoT / perlu static IP global → GA. Web content cache → CloudFront

💡 Exam Scenario

App dengan users dari US dan Asia — Global Accelerator route via AWS backbone (bukan public internet), lagi laju. Kalau satu region fail, auto-failover ke region lain dalam <30 saat. Beza dengan CloudFront: GA untuk TCP/UDP apps, bukan static content caching.

🪤 Perangkap Soalan

Q: Beribu IoT device ada IP endpoint HARD-CODED dan tak boleh update senang. Backend pindah region kadang-kadang, dan device perlu sentiasa sampai ke endpoint sihat dengan latency rendah. Servis mana?

⚠ Umpan: Route 53 dengan latency/failover routing — tukar DNS record point ke backend baru. Nampak betul sebab Route 53 memang untuk arah traffic.

✓ Betul: AWS Global Accelerator. Device yang hard-code IP tak hormat perubahan DNS (cache IP lama / tak buat DNS lookup). GA bagi 2 static IP yang KEKAL — device sentiasa hubungi IP sama, GA route ke endpoint sihat di belakang. Keyword "hard-coded/static IP + global + failover" → Global Accelerator.

Q: Aplikasi web (HTTP) nak laju untuk user global dengan banyak imej/video statik. GA atau CloudFront?

⚠ Umpan: Global Accelerator — sebab dia guna AWS backbone "laju global". Nampak betul sebab GA = "global + laju".

✓ Betul: CloudFront. Untuk content HTTP yang boleh di-CACHE, CloudFront simpan salinan di edge (offload origin + laju). GA tiada caching — dia cuma optimize routing, sesuai untuk TCP/UDP / non-cacheable. Keyword "cacheable HTTP content global" → CloudFront, bukan GA.

🧠 Cara Mudah Ingat

→Global Accelerator provisions TWO static Anycast IP addresses — clients always connect to the same two IPs regardless of region
→IP caching problem (IoT devices, hard-coded IPs): use Global Accelerator (fixed IPs) not Route 53 (DNS changes require propagation + clients may cache old IPs)
→HIPAA-eligible, supports TLS in-transit encryption — suitable for healthcare/IoT workloads
→Anycast = both IPs are advertised from ALL edge PoPs; network routes to nearest PoP automatically

Guna Bila

Route global users to nearest healthy endpoint via AWS backbone

global routingAWS backboneanycaststatic IPTCP/UDPfailover <30stwo static IPsIP cachingIoTHIPAA

D2 · Resilient

Aurora

Amazon Aurora

"RDS tapi 5x laju, 6 copies auto, failover 30 saat"

🎯 Sebab Apa Wujud

Orang nak kuasa & HA peringkat enterprise tapi tak nak urus replication/storage sendiri macam RDS biasa. Aurora wujud dengan pisahkan compute & storage — storage layer auto simpan 6 copy merentas 3 AZ, auto-grow, failover <30s. Kau dapat MySQL/PostgreSQL yang 3-5x laju & tahan lasak tanpa kerja manual.

Apa Dia

Aurora simpan 6 salinan data merentasi 3 AZs secara automatik. Storage auto-grow hingga 256 TiB. Up to 15 Read Replicas dengan lag <10ms. Failover automatik dalam <30 saat.

Contoh Guna

Replace RDS MySQL production — Aurora bagi HA automatik, 6 copies, failover <30s, storage auto-scale, tanpa manage sendiri.

Cluster anatomy — compute & storage TERPISAH

App

Writer endpoint

→ primary

Reader endpoint

load-balance replicas

Primary (Writer)

read + write · 1 je

Aurora Replicas

up to 15 · read-only · failover target

Shared Cluster Volume

6 copies · 3 AZs (2/AZ) · auto-grow → 256 TiB

SEMUA instance (writer + readers) share SATU cluster volume — bukan tiap instance ada copy sendiri (beza dengan RDS Multi-AZ). Tambah replica = laju sebab tak perlu copy data. Writer endpoint sentiasa tunjuk primary; reader endpoint auto load-balance across replicas. Primary fail → replica dipromote <30s.

Aurora Global Database — cross-region DR

Primary Region

read + write

Storage replication

typical < 1s lag

Secondary Region(s)

up to 5 · read-only

Promote on outage

RTO < 1 min · RPO ~1s

1 primary region + up to 5 secondary read-only regions, replicate di peringkat storage (typical <1s lag). Region utama down → promote secondary jadi primary (RTO <1 min). Exam: "cross-region DR, downtime <1 min, low data loss" → Aurora Global Database (bukan Multi-AZ yang same-region je).

Analogi gudang pusat — Aurora kongsi storage, RDS gudang sendiri

Rendering diagram…

Aurora = gudang pusat berkongsi: semua instance (1 writer + sampai 15 reader) ambil dari SATU cluster volume yang auto simpan 6 salinan merentas 3 AZ. Tambah reader = laju sebab tak payah pindah data (share volume). RDS Multi-AZ = tiap instance ada gudang sendiri; primary hantar sync copy ke standby PASIF (tak boleh dibaca). INGAT exam: "6 copies / 3 AZ / shared storage / failover <30s" = Aurora; "1 standby" = RDS Multi-AZ.

Pokok keputusan — pilih flavor relational DB

Rendering diagram…

INGAT exam: engine Oracle / SQL Server / MariaDB → RDS biasa je (Aurora HANYA MySQL & PostgreSQL compatible). MySQL/Postgres + nak HA terbaik atau cross-region DR → Aurora. Traffic on-off / tak menentu → Aurora Serverless v2 (scale near-zero, bayar per second).

Aurora vs RDS Multi-AZ — bila pilih yang mana

Aspect	RDS Multi-AZ	Aurora
Salinan data	1 standby (sync)	🟢 6 copies / 3 AZ auto (2/AZ)
Failover	1-2 minit	🟢 <30 saat
Read replicas	Up to 15 (MySQL/PG/Maria) / 5 (Oracle/SQL Svr), async	🟢 Up to 15, lag <10ms
Storage	Provision saiz, per-instance	🟢 Shared volume auto-grow 128 TiB
Engine	MySQL/Postgres/MariaDB/Oracle/SQL Server	MySQL & PostgreSQL compatible SAHAJA
Cross-region DR	Cross-region replica (manual promote)	🟢 Global Database (RTO<1min, RPO~1s)
Kos	🟢 Murah sikit	~20% lebih, tapi 3-5x laju + HA terbaik

Ingat: Engine MySQL/PostgreSQL + nak HA enterprise (6 copy, failover <30s) atau global DR → Aurora. Engine Oracle / SQL Server / MariaDB → RDS biasa (Aurora TAK support engine tu). Workload on-off / spiky → Aurora Serverless v2. Keyword "failover <30s / 6 copies / cross-region <1s" = Aurora; "1 standby" = RDS Multi-AZ.

⚡ Quick Sifir — hafal ni

▪Aurora = 6 copies / 3 AZ auto (2 per AZ); RDS Multi-AZ = 1 standby je
▪Failover Aurora <30s; RDS Multi-AZ 1-2 min
▪Semua instance SHARE satu cluster volume (bukan copy sendiri) → tambah replica laju
▪Up to 15 Aurora Replicas (read), lag <10ms
▪MySQL & PostgreSQL compatible; storage auto-grow → 256 TiB (128 TiB engine lama)
▪Global Database = 1 primary + up to 5 region; RTO <1min, RPO ~1s
▪Aurora cluster ≠ RDS Multi-AZ DB Cluster: Aurora = shared storage 6-copy/3-AZ + ≤15 reader; Multi-AZ DB Cluster = standard RDS engine, 2 reader je, local storage per node

💡 Exam Scenario

"High availability relational DB, auto-failover, multiple copies" → Aurora. Bukan RDS Multi-AZ (Aurora lebih canggih: 6 copies vs 1 standby, failover 30s vs 1-2 minit). Aurora Serverless untuk unpredictable/intermittent workloads.

🪤 Perangkap Soalan

Q: Perlu cross-region DR: downtime <1 min, data loss minimum, minimal manual ops. Pilih.

⚠ Umpan: RDS Multi-AZ — "kan ni HA?". SALAH: Multi-AZ same-region je, tak lindung kalau SELURUH region down.

✓ Betul: Aurora Global Database (RTO <1min, RPO ~1s, auto-promote secondary region).

Q: Nak HA relational DB dengan failover lebih laju & lebih banyak salinan dari RDS Multi-AZ.

⚠ Umpan: RDS Multi-AZ — nampak cukup. Tapi soalan tekan "lebih laju + lebih banyak copy".

✓ Betul: Aurora (6 copies/3 AZ, failover <30s vs RDS Multi-AZ 1 standby/1-2 min).

Q: Nak MySQL HA dengan 2 readable standby + failover laju TAPI kekal guna standard RDS engine (bukan tukar ke Aurora). Pilih.

⚠ Umpan: Aurora — "readable replica + fast failover" bunyi sangat macam Aurora, ramai terjebak.

✓ Betul: RDS Multi-AZ DB Cluster — kekal standard RDS MySQL/PostgreSQL engine, 2 readable standby, 3 AZ. Aurora = engine berasingan + shared storage (6-copy) + ≤15 reader. Keyword "shared storage / 6 copies / up to 15 readers" → Aurora; "standard RDS engine + 2 readable standby" → Multi-AZ DB Cluster.

🧠 Cara Mudah Ingat

→Aurora = 6 copies across 3 AZs auto. RDS Multi-AZ = 1 standby copy sahaja
→Aurora failover <30 saat. RDS Multi-AZ failover 1-2 minit
→Aurora storage auto-grow hingga 256 TiB — zero storage management
→Storage scaling: start 10 GiB, auto-grow dalam 10 GiB increments hingga max (128-256 TiB ikut engine version) — ni SAMA untuk Aurora provisioned dan Aurora Serverless. Jangan keliru dengan Serverless v2 COMPUTE capacity range (0.5-256 ACU)
→Aurora Global Database: primary region + up to 5 read-only secondary regions
→Aurora Global Database RTO: < 1 minit (automatic managed failover). RPO: ~1 saat (replication lag)
→Aurora Global Database failover: secondary region promote jadi primary automatically bila primary region down — minimal manual effort
→Exam: "cross-region DR, downtime < 1 minit, minimal manual ops" → Aurora Global Database. Bukan Multi-AZ (same region). Bukan manual snapshot restore (kena buat sendiri)
→Multi-AZ Aurora Replicas = same region HA (failover dalam AZ, bukan region)
→JANGAN keliru Aurora cluster dengan RDS Multi-AZ DB Cluster: Aurora = engine berasingan, shared cluster volume (6 copies/3 AZ, storage terpisah dari compute), ≤15 reader, ~5x throughput. Multi-AZ DB Cluster = standard RDS engine (MySQL/PostgreSQL je), setiap node ada LOCAL storage sendiri, tepat 2 readable standby, semisynchronous, failover <35s. Lihat kad "RDS Multi-AZ" untuk DB Instance vs DB Cluster.

Guna Bila

High-performance relational DB, MySQL/PostgreSQL compatible, enterprise HA

MySQL compatiblePostgreSQL compatible6 copies3 AZsauto storage 256 TiBfast failover15 read replicasGlobal Databasecross-region DRRTO 1 minRPO 1sshared cluster volumeMulti-AZ DB ClusterAurora vs Multi-AZ DB Clustershared storage

📎 What is Amazon Aurora?

D2 · Resilient

Aurora Serverless

Amazon Aurora Serverless

"Database yang tidur bila tak pakai, scale sendiri"

🎯 Sebab Apa Wujud

Workload on-off / tak menentu (dev-test office hours, app baru, traffic spiky) — kau tak nak bayar instance penuh 24/7 sedangkan DB selalu idle. Aurora Serverless wujud supaya capacity auto naik-turun ikut demand & boleh pause ke near-zero bila tiada traffic. Bayar per second, bukan per instance 24/7.

Apa Dia

Aurora Serverless v2 auto-scale capacity dalam fractions of seconds dari minimum hingga ratusan ACUs, dalam increments 0.5 ACU. Boleh scale to near-zero (auto-pause/resume) bila idle.

Aurora anatomy — compute pisah dari storage (boleh mix provisioned + serverless)

Rendering diagram…

Aurora = compute & storage DECOUPLED (beza RDS biasa). Serverless v2 boleh MIX dengan provisioned writer/reader dalam cluster sama — contoh: provisioned writer (writes konsisten) + serverless reader (read spike). Storage shared & replicate 6 salinan / 3 AZ. INGAT exam: "mix provisioned + serverless" = Aurora Serverless v2 sahaja (v1 tak boleh).

Analogi aircond inverter — auto naik-turun, padam bila takde orang

Rendering diagram…

Aurora Serverless = aircond inverter: auto naik bila ramai (scale fine-grained 0.5 ACU, tanpa putus connection di v2), turun near-zero bila bilik kosong (auto-pause). Bayar per second ikut guna sebenar — bukan bayar instance penuh 24/7. INGAT exam: "intermittent / unpredictable / dev-test / scale to zero / variable traffic" → Aurora Serverless (v2 = default sekarang).

Aurora Serverless v1 vs v2

Aspect	Serverless v1	Serverless v2
Scaling	Steps (whole capacity-unit jumps)	🟢 Fine-grained 0.5 ACU, fractions of a second
Connection drop masa scale	🔴 Boleh drop	🟢 Tak drop
Auto-pause idle	🟢 Ya (full pause → zero)	Set min 0 ACU → auto-pause (newer versions)
Mix dgn provisioned instances	❌ Tidak	🟢 Ya — dalam cluster yang sama
Global DB / Multi-AZ / Read Replica	Limited	🟢 Penuh
Guna bila	Legacy / simple intermittent	Current default — variable traffic, no connection drops

Ingat: v2 = current default (fine-grained, no connection drops, boleh mix dgn provisioned, full features). v1 = legacy. Exam: "instant scaling tanpa drop connection" atau "mix serverless + provisioned dalam satu cluster" → Aurora Serverless v2.

Aurora Serverless v2 vs provisioned vs DynamoDB (exam trap)

Aspect	Aurora Serverless v2	Aurora/RDS provisioned	DynamoDB
MySQL-compatible	🟢 Ya	🟢 Ya	❌ NoSQL — re-architecture
Compute scaling	🟢 Auto ACU (0.5 steps)	🔴 Fixed instance size	Auto RCU/WCU or On-Demand
Pay model	Per second (ACU used)	Per hour (instance 24/7)	Per request / capacity unit
Best when	Unpredictable / intermittent relational	Steady predictable OLTP	Key-value / ms latency NoSQL

Ingat: "MySQL-compatible + unpredictable traffic + auto-scale capacity" → Aurora Serverless v2. "Fixed memory OK" → provisioned. "NoSQL / key-value" → DynamoDB (BUKAN untuk ganti MySQL app).

⚡ Quick Sifir — hafal ni

▪Aurora Serverless = auto-scale COMPUTE (ACU), bayar per second
▪1 ACU ≈ 2 GiB memory + matching CPU/network — min 1 max 8 ACU = ~2–16 GiB range
▪v2 = default: fine-grained 0.5 ACU, NO connection drop, boleh MIX provisioned + serverless dalam satu cluster
▪v1 = legacy: scale step-step, connection boleh DROP
▪MySQL/PostgreSQL compatible — DynamoDB BUKAN MySQL (NoSQL re-architecture)
▪Keyword: intermittent / unpredictable / memory range known / on-prem MySQL replace → Aurora Serverless v2

💡 Exam Scenario

On-prem MySQL (2–16 GiB memory) via VPN, traffic unpredictable spike + zero activity → Aurora Serverless v2 min 1 max 8 ACU. Dev/test office hours only → Aurora Serverless. Keywords: intermittent, variable traffic, MySQL-compatible, memory range, auto-scale capacity.

🪤 Perangkap Soalan

Q: Nak instant scaling tanpa putus connection, DAN mix serverless + provisioned dalam SATU cluster.

⚠ Umpan: Aurora Serverless v1 — orang main pilih "Serverless". SALAH: v1 boleh drop connection masa scale & tak boleh mix dgn provisioned.

✓ Betul: Aurora Serverless v2 (no connection drop, boleh campur dgn provisioned instances).

Q: Three-tier app — on-prem MySQL-compatible DB (2–16 GiB memory) via Site-to-Site VPN, traffic unpredictable (spike + zero activity). Nak managed service auto-scale capacity. Pilih?

⚠ Umpan: Aurora memory-optimized provisioned instance — nampak "memory-optimized = betul untuk memory range". SALAH: provisioned = FIXED capacity, tak auto-scale ikut spike/zero activity.

✓ Betul: Aurora Serverless v2 — set min 1 ACU max 8 ACU (1 ACU ≈ 2 GiB → cover 2–16 GiB). Auto-scale compute ikut demand, MySQL-compatible. Keyword "unpredictable traffic + memory range + MySQL-compatible + managed auto-scale" → Aurora Serverless v2.

Q: Same stem — engineer cadang DynamoDB + auto-scaling 2–16 capacity units sebab "serverless". Betul?

⚠ Umpan: DynamoDB serverless + auto-scale — nampak betul sebab "scale dengan app". SALAH: DynamoDB = NoSQL, BUKAN MySQL-compatible; app three-tier relational kena rewrite besar.

✓ Betul: Tak sesuai — keyword "MySQL-compatible" = Aurora/RDS, BUKAN DynamoDB. DAX pula untuk cache DynamoDB read, bukan solve relational migration.

Q: Same stem — RDS MySQL 4 GiB fixed memory. Cukup?

⚠ Umpan: RDS managed MySQL — nampak betul sebab MySQL-compatible. SALAH: fixed 4 GiB tak cover range 2–16 GiB & tak auto-scale bila spike/zero.

✓ Betul: Tak cukup — provisioned RDS = saiz tetap. Nak auto-scale ikut unpredictable load → Aurora Serverless v2 dengan ACU range.

🧠 Cara Mudah Ingat

→v1 (legacy): scale dalam STEPS (whole capacity unit jumps), connections boleh DROP semasa scaling, limited engine versions
→v2 (current): fine-grained scaling 0.5 ACU increments dalam fractions of seconds, NO connection drops, boleh dicampur dengan provisioned Aurora instances dalam cluster yang sama
→v2 sokong lebih banyak feature: Global Database, Multi-AZ, Read Replicas — v1 lebih limited
→Exam: kalau soalan sebut "instant scaling without dropping connections" atau "mix serverless + provisioned instances" → Aurora Serverless v2
→Setup: pilih DB instance class "Serverless v2", set capacity range 0–256 ACU dalam increments 0.5 ACU (limit sebenar ikut engine/version)
→Set minimum capacity = 0 ACU → enable auto-pause/resume (database pause sepenuhnya bila tiada connections, resume automatik bila ada request baru)

Guna Bila

Unpredictable/intermittent workloads — auto-scale DB capacity, pay per second

scale to zeroACUpay per secondintermittentdev/testauto-pausevariable trafficv1 vs v20.5 ACU incrementsno connection dropsMySQL-compatible2 GiB per ACUmemory 2-16 GiBon-premises replacementunpredictable spikesmix provisioned serverless

📎 Using Aurora serverless (v2)

D2 · Resilient

DynamoDB

Amazon DynamoDB

"NoSQL yang tak pernah slow — milliseconds at any scale"

🎯 Sebab Apa Wujud

Bila kau perlu NoSQL yang laju KONSISTEN (single-digit ms) pada apa-apa scale tanpa urus server/sharding sendiri. Relational DB (RDS/Aurora) kena scale up & boleh jadi bottleneck untuk key-value workload besar. DynamoDB wujud serverless, auto-partition data — latency tetap stabil walau traffic meletup (Black Friday, viral game).

Apa Dia

Fully managed NoSQL database. Auto-scale, no servers. DynamoDB Streams capture changes untuk event-driven patterns. DAX (DynamoDB Accelerator) untuk microsecond reads. Global Tables untuk multi-region active-active.

Contoh Guna

Shopping cart, user sessions, real-time leaderboards, gaming scores — workloads yang perlu high throughput, low latency, dan serverless.

Pokok keputusan — LSI atau GSI? (soalan paling kerap)

Rendering diagram…

INGAT exam: table DAH wujud + perlu query pattern baru → GSI (boleh tambah bila-bila masa, partition key bebas, own capacity, max 20). Masa create table + nak sort key alternatif dengan partition key SAMA → LSI (max 5, MESTI define awal, tak boleh tambah lepas table jadi). Keyword "create anytime / new access pattern" = GSI; "must define at creation / same partition key" = LSI.

SQL vs NoSQL — RDS vs DynamoDB (foundational!)

Ciri	Amazon RDS (SQL / Relational)	DynamoDB (NoSQL)
Model data	Jadual berpetak — baris & lajur, ada relationship (JOIN)	Key-value / document (JSON), schema fleksibel
Sambungan app	DB connection string (engine driver)	AWS SDK / API
Scaling	Scale UP (vertical) + Read Replica untuk read	🟢 Scale OUT auto (horizontal), serverless
Latency	Bergantung saiz instance & query	🟢 Single-digit ms konsisten at any scale
Query	🟢 SQL penuh — JOIN, aggregate, ad-hoc complex query	Akses by key; query pattern kena design awal (GSI/LSI)
Analogi	Buku akaun bank berpetak (data ada hubungan)	Buku nota conteng ringkas, tulis laju
Exam keyword	"OLTP / relational / JOIN / MySQL/PostgreSQL / ACID transaction"	"serverless / millisecond / NoSQL / key-value / any scale"

Ingat: Perlu relationship + JOIN + SQL kompleks + transaction → RDS/Aurora (relational). Perlu serverless, latency tetap walau traffic meletup, key-value/document → DynamoDB. Soalan "millisecond at any scale / serverless NoSQL" → DynamoDB; "traditional app / MySQL / complex query / JOIN" → RDS.

Capacity modes — On-Demand vs Provisioned

Aspect	On-Demand	Provisioned
Billing	Pay per request	Pay for RCU/WCU reserved per jam
Capacity planning	🟢 Zero — auto instant	Set RCU/WCU (+ optional Auto Scaling)
Best untuk	Unpredictable / spiky / baru launch	Predictable steady traffic
Cost	Mahal sikit per request	🟢 Murah kalau traffic stabil
Throttling risk	Sangat rendah (scale terus)	Boleh throttle kalau lebih provisioned

Ingat: Traffic tak menentu / app baru / tak nak fikir capacity → On-Demand. Traffic stabil & nak jimat → Provisioned + Auto Scaling. Boleh tukar mode (had sekali per 24 jam).

LSI vs GSI — secondary indexes

Aspect	LSI (Local)	GSI (Global)
Partition key	SAME as base table	Can be DIFFERENT
Sort key	Alternate sort key	Different partition + sort key
When created	🔴 Only at table creation	🟢 Anytime (create/delete)
Capacity	Shares base table throughput	Own provisioned RCU/WCU
Consistency	Strong OR eventual	Eventual only
Limit per table	5	20

Ingat: "Alternate sort order, must define at creation, same partition key" → LSI. "New query pattern, create anytime, own capacity" → GSI.

⚡ Quick Sifir — hafal ni

▪DynamoDB = NoSQL serverless, single-digit ms, any scale
▪On-Demand = bayar per request (spiky/baru); Provisioned = RCU/WCU (stabil, murah)
▪LSI = SAME partition key, beza sort key, MESTI masa create table, max 5, share throughput
▪GSI = beza partition/sort key, bila-bila masa, max 20, OWN throughput
▪Streams (INSERT/MODIFY/REMOVE) kekal 24 jam → trigger Lambda
▪Global Tables = multi-region active-active; DAX = microsecond read
▪Partition key high-cardinality elak hot partition

💡 Exam Scenario

"Serverless NoSQL millisecond latency at any scale" → DynamoDB. "Microsecond reads for DynamoDB" → DAX. "Multi-region active-active database" → DynamoDB Global Tables. "Capture DynamoDB changes → trigger Lambda" → DynamoDB Streams.

🪤 Perangkap Soalan

Q: App dah live & running, tetiba perlu query pattern baru (cari by attribute lain). Tambah apa?

⚠ Umpan: LSI — sebab "index". SALAH: LSI MESTI dicipta MASA create table; tak boleh tambah lepas table dah wujud.

✓ Betul: GSI (boleh dicipta bila-bila masa, own capacity, partition key boleh lain).

Q: DynamoDB read perlu microsecond (bukan millisecond). Pilih cache.

⚠ Umpan: ElastiCache — cache umum. Boleh secara teori tapi kena tulis cache logic sendiri & bukan jawapan exam.

✓ Betul: DAX (drop-in, microsecond, khusus DynamoDB). Keyword "microsecond + DynamoDB" → DAX.

🧠 Cara Mudah Ingat

→DynamoDB = NoSQL (key-value/document). Aurora/RDS = SQL (relational)
→DAX = DynamoDB Accelerator = microsecond reads (in-memory cache for DynamoDB)
→Global Tables = automatic multi-region active-active replication
→DynamoDB Streams → trigger Lambda = event-driven serverless pattern
→Partition key design: choose attribute dengan HIGH CARDINALITY (banyak unique values) supaya traffic diagihkan rata across partitions — elak "hot partition"
→Provisioned capacity (set RCU/WCU + Auto Scaling target %) = predictable steady traffic, lebih jimat. On-Demand (pay per request) = unpredictable/spiky traffic, zero capacity planning
→Item collection: untuk composite primary key (partition key + sort key), semua item dengan SAME partition key disimpan together dalam satu partition, sorted by sort key — ni yang buat Query by partition key + sort key range jadi efficient
→LSI (Local Secondary Index): SAME partition key as base table, alternate SORT key. Mesti dicipta SEMASA create table. Limit 10GB per partition key value — limit ni applies kat ITEM COLLECTION (base table item + semua LSI items utk partition key tu)
→GSI (Global Secondary Index): DIFFERENT partition key AND/OR sort key dari base table. Boleh dicipta/delete BILA-BILA masa. Ada own provisioned throughput (RCU/WCU) berasingan dari base table.
→Exam shortcut: "alternate query pattern, create anytime, own capacity" → GSI. "Alternate sort order, same partition key, must define at table creation" → LSI
→Default quota: 20 GSI dan 5 LSI per table. Partition key jugak dipanggil "hash attribute", sort key dipanggil "range attribute" — istilah ni kadang muncul dalam exam wording
→DynamoDB Streams: setiap stream record (INSERT/MODIFY/REMOVE) kekal 24 jam je sebelum auto-removed — kalau Lambda trigger gagal proses dalam masa tu, data tu lost
→Item boleh ada NESTED attributes (JSON-like, e.g. Address dalam satu item) sampai 32 levels deep — DynamoDB schemaless except primary key
→Primary key attribute (partition key / sort key) MESTI scalar — String, Number, atau Binary sahaja. Tak boleh guna List, Map, atau Set sebagai primary key

Guna Bila

Serverless key-value/document store, single-digit ms latency at any scale

NoSQLkey-valueserverlessmillisecond latencyDAXGlobal Tablesstreamsauto-scalepartition keyLSIGSIsecondary indexprovisionedon-demandhot partitionitem collectionhash attributerange attributenested attributes

📎 Improving data access with secondary indexes 📎 Partitions and data distribution 📎 Core components of Amazon DynamoDB

D2 · Resilient

DAX

Amazon DynamoDB Accelerator (DAX)

"Cache depan DynamoDB — baca dalam microseconds"

🎯 Sebab Apa Wujud

DynamoDB sendiri dah laju (single-digit ms), tapi sesetengah read-heavy app (banyak repeat read item sama, contoh leaderboard / product hot) perlu lagi laju — MICROSECOND. DAX wujud sebagai in-memory cache depan DynamoDB, drop-in (code tak ubah), supaya read berulang tak pukul table & jimat RCU.

Apa Dia

Fully managed, highly available in-memory cache khusus untuk DynamoDB. Drop-in compatible — tak perlu tukar application logic, cuma point ke DAX endpoint. Hanya cache READ operations (GetItem, Query, Scan).

Pokok keputusan — DAX atau ElastiCache?

Rendering diagram…

INGAT exam: "microsecond + DynamoDB" → DAX (drop-in, code tak berubah, cache read sahaja). "cache untuk RDS/Aurora atau data am" → ElastiCache. TRAP klasik: "cache untuk RDS → DAX?" SALAH — DAX cakap DynamoDB API SAHAJA, langsung tak boleh sentuh RDS. Cache am = ElastiCache.

DAX vs ElastiCache — bila guna cache yang mana

Aspect	DAX	ElastiCache
Cache untuk	🟢 DynamoDB SAHAJA	Apa-apa (RDS, Aurora, custom data)
Integrasi	Drop-in — guna DAX SDK, code tak ubah	Tulis cache logic sendiri di app
Cache apa	Read sahaja (GetItem/Query/Scan)	Apa-apa value yang kau letak
Latency	Microseconds	Sub-millisecond (Redis/Memcached)
Guna bila	Read-heavy DynamoDB perlu microsecond	Cache depan RDS/Aurora atau data am

Ingat: Cache khusus DynamoDB + zero code change + microsecond → DAX. Cache untuk RDS/Aurora atau data am → ElastiCache. Exam trap: "cache untuk RDS" BUKAN DAX — DAX hanya cakap DynamoDB API.

⚡ Quick Sifir — hafal ni

▪DAX = microsecond read; DynamoDB sendiri = single-digit ms
▪DAX cache DynamoDB SAHAJA (cakap DynamoDB API je)
▪Drop-in: guna DAX SDK, code logic tak berubah
▪Cache READ je (GetItem/Query/Scan); write tetap terus ke DynamoDB
▪Cache untuk RDS/Aurora/data am → ElastiCache, BUKAN DAX

💡 Exam Scenario

"DynamoDB read latency perlu microseconds, bukan milliseconds" → DAX. "Cache untuk RDS/Aurora" → ElastiCache, BUKAN DAX (DAX khusus DynamoDB sahaja).

🪤 Perangkap Soalan

Q: Read-heavy app atas RDS perlu cache laju. Pilih.

⚠ Umpan: DAX — sebab "cache AWS untuk DB". SALAH: DAX hanya cakap DynamoDB API, tak boleh cache RDS langsung.

✓ Betul: ElastiCache (Redis/Memcached) — cache untuk apa-apa termasuk RDS/Aurora.

🧠 Cara Mudah Ingat

→DAX = microsecond reads. DynamoDB sendiri = single-digit millisecond reads. Beza tu yang exam test.
→DAX hanya untuk READS — write masih terus ke DynamoDB (write-through cache pada writes yang lalu DAX API)
→Drop-in compatible: guna DAX SDK client, code logic tak berubah
→DAX ≠ ElastiCache: DAX khusus DynamoDB API. ElastiCache untuk general-purpose caching (RDS, custom data)

Guna Bila

Read-heavy DynamoDB workloads needing microsecond response times

DynamoDB Acceleratormicrosecond latencyin-memory cacheread cachingdrop-in compatibleDAX vs ElastiCache

📎 In-memory acceleration with DynamoDB Accelerator (DAX)

🔄Disaster Recovery Patterns↑ Top

D2 · Resilient

Backup & Restore

DR Pattern: Backup & Restore

"Save game — kalau rosak restore dari backup"

🎯 Sebab Apa Wujud

Wujud sebab bencana region/data corruption MEMANG akan jadi suatu hari, dan tak semua sistem mampu (atau perlu) bayar untuk standby panas. Backup & Restore = strategi DR paling murah: simpan backup je (S3/Glacier), TIADA infra berjalan di DR region. Bila bencana, baru bina semula dari backup. Tujuan: perlindungan DR minimum untuk sistem yang downtime beberapa jam OK — bayar storage je, bukan duplicate infra.

Apa Dia

Strategi DR paling asas — backup data ke S3/Glacier, restore bila diperlukan. Tiada infrastruktur standby di DR region

AWS DR spectrum — active/passive → active/active (RTO/RPO vs cost)

Rendering diagram…

Diagram rasmi AWS whitepaper — kiri→kanan = laju & mahal naik. Tiga kiri = active/passive (infra DR tak melayan traffic penuh). Multi-Site = active/active (dua region LIVE). INGAT exam: financial institute RTO/RPO ~20 min + budget ketat → Pilot Light ($$, puluhan minit), BUKAN Warm Standby ($$$ walaupun RTO minit) atau Backup&Restore (jam).

Pilih DR strategy mana — decision tree (RTO/RPO vs kos)

Rendering diagram…

Tanya RTO/RPO dulu, baru bajet. Downtime jam OK + termurah → Backup & Restore. Zero-downtime/RTO saat → Multi-Site (termahal). Antara dua: DB sedia tapi tak nak bayar app idle → Pilot Light; full stack kecil sentiasa jalan → Warm Standby. INGAT exam: keyword "lowest cost" → Backup&Restore · "core DB only / app off" → Pilot Light · "scaled-down running / scale up" → Warm Standby · "near-zero RPO + seconds RTO / mission-critical" → Multi-Site.

Analogi — backup elektrik kedai bila bekalan putus

Rendering diagram…

Spektrum kesediaan: makin sedia (genset dah hidup), makin laju pulih tapi makin mahal. Backup&Restore = genset dalam stor (kena pasang dulu = RTO jam). Pilot Light = genset dah sambung tinggal start (DB on, app off). Warm Standby = genset idle kecil (full stack scaled-down). Multi-Site = dua sumber penuh, takde "recover" langsung (zero downtime). INGAT exam: bajet ketat & downtime OK → kiri; mission-critical zero-downtime → kanan.

RTO vs RPO — jangan keliru!

Term	Maksud	Soalan	Arah masa
RPO (Recovery Point Objective)	Berapa banyak DATA boleh hilang	"Berapa kerap aku backup?"	⏪ Ke BELAKANG dari masa crash
RTO (Recovery Time Objective)	Berapa lama nak PULIH semula	"Berapa lama downtime boleh tahan?"	⏩ Ke HADAPAN dari masa crash

Ingat: RPO = Point = titik data terakhir yang selamat (data loss tolerance). RTO = Time = masa untuk online balik (downtime tolerance). RPO 1 jam → backup tiap jam. RTO 5 minit → kena ada standby panas. Makin kecil dua-dua → makin mahal.

The 4 DR strategies — cost ↔ speed spectrum

Aspect	Backup & Restore	Pilot Light	Warm Standby	Multi-Site Active/Active
RPO	Hours–days	Minutes (10s of min)	Seconds–minutes	🟢 Near-zero
RTO	Hours	10s of minutes	Minutes	🟢 Seconds (real-time)
What runs in DR	Nothing — just backups	Core DB only (app off)	Scaled-down full stack	🟢 Full capacity, live
Cost	🟢 $	$$	$$$	$$$$
Use when	Non-critical, downtime OK	Can tolerate some recovery time	Need fast recovery, low traffic loss	Mission-critical, zero downtime

Ingat: Cost & recovery speed naik dari kiri → kanan ($ → $$$$). Cheapest+slowest = Backup & Restore (hours). Sweet spot bajet + RTO puluhan minit = Pilot Light ($$). Warm Standby = minit tapi $$$. Multi-Site = real-time tapi $$$$. INGAT exam: "RTO/RPO ~20 min + budget tight" → Pilot Light, BUKAN Warm Standby (lebih mahal walaupun RTO minit).

⚡ Quick Sifir — hafal ni

▪RPO = data boleh hilang (berapa kerap backup). RTO = masa pulih (downtime tolerance)
▪Backup & Restore: RPO jam-hari, RTO jam, kos PALING RENDAH, takde standby
▪Pilot Light: DB on, app OFF. RPO minit, RTO minit-jam
▪Warm Standby: full stack scaled-DOWN running. RPO saat-minit, RTO minit
▪Multi-Site Active/Active: full capacity dua region live. RPO~0, RTO saat, PALING MAHAL
▪Kiri→kanan = laju & mahal naik. Pilih ikut RTO/RPO vs bajet

💡 Exam Scenario

Non-critical archival system — backup snapshots ke S3/Glacier regularly. RPO: hours/days. RTO: hours. Paling murah tapi paling lambat recover. Guna bila downtime beberapa jam boleh diterima.

🪤 Perangkap Soalan

Q: Aplikasi mission-critical perbanking perlu RTO beberapa saat dan RPO hampir sifar (hampir tiada data loss, hampir tiada downtime). Strategi DR mana?

⚠ Umpan: Warm Standby — full stack dah berjalan (scaled-down) di DR, jadi failover laju. Nampak betul sebab "ada infra berjalan = laju".

✓ Betul: Multi-Site Active/Active. Warm Standby masih perlu masa SCALE UP semasa failover (RTO minit, bukan saat). Untuk RTO saat + RPO~0, perlu full capacity LIVE di dua region serentak. Keyword "near-zero RPO + seconds RTO + mission-critical / zero downtime" → Multi-Site Active/Active.

Q: Sistem arkib dalaman, bukan kritikal, downtime beberapa jam OK. Mahu kos DR PALING RENDAH. Pilih?

⚠ Umpan: Pilot Light — DB sentiasa replicate, jadi recovery cepat dan masih agak murah. Nampak betul sebab Pilot Light dikenali sebagai murah.

✓ Betul: Backup & Restore. Pilot Light masih jalankan core DB (kos berterusan). Untuk kos PALING RENDAH bila downtime jam OK, cukup simpan backup di S3/Glacier tanpa infra berjalan langsung. Keyword "lowest cost / downtime hours acceptable / non-critical" → Backup & Restore.

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

⚠ Umpan: Warm Standby — RTO dalam minit memang cukup untuk ~20 minit, full stack scaled-down dah berjalan. Nampak betul sebab "RTO minit = meet requirement". SALAH: Warm Standby bayar app compute idle 24/7 → lebih mahal dari yang diperlukan bila soalan tekan budget.

✓ Betul: Pilot Light — RTO/RPO dalam "10s of minutes" (puluhan minit) memenuhi ~20 minit, tapi data replication aktif & app server OFF sampai bencana → kos backup infra lebih rendah dari Warm Standby. Keyword "RTO/RPO tens of minutes + budget concerns / backup cost not very high" → Pilot Light, BUKAN Warm Standby (lebih mahal) atau Multi-Site ($$$$).

Guna Bila

Non-critical systems, lowest cost DR strategy

RPO: hours/daysRTO: hourslowest costno standby infraS3/Glacier backupDR spectrumPilot LightWarm StandbyMulti-Siteactive/passiveactive/activefinancial institutebudget concerns20 minutes RTO

📎 Disaster recovery options in the cloud (AWS whitepaper)

D2 · Resilient

Pilot Light

DR Pattern: Pilot Light

"Api kecil sedia — boleh bakar besar bila perlu"

🎯 Sebab Apa Wujud

Wujud sebab Backup & Restore terlalu lambat (kena bina DB dari kosong + restore = jam), tapi kau tak nak bayar full standby. Pilot Light = nyalakan "api kecil": core DB sentiasa replicate & berjalan minimal di DR, tapi app server MATI (tak bayar compute). Bila bencana, kau cuma "bakar" — hidupkan & scale app server, point DNS. Tujuan: recovery lebih laju dari backup (DB dah sedia) pada kos sederhana.

Apa Dia

Hanya core components (database) yang running kat DR region scaled down. App servers dilancarkan hanya bila disaster berlaku

⚡ Quick Sifir — hafal ni

▪Pilot Light = DB ON (replicate), app server OFF sampai bencana
▪RPO minit, RTO minit-jam. Lebih laju dari Backup&Restore, lebih murah dari Warm Standby
▪Beza utama vs Warm Standby: Pilot Light app OFF; Warm Standby app ON (scaled-down)
▪"DB sentiasa sedia tapi tak nak bayar app compute idle" → Pilot Light

💡 Exam Scenario

Core DB replicated ke DR region (running minimal). App servers OFF. Disaster berlaku — turn on app servers, scale up, point DNS ke DR. RPO: minutes, RTO: minutes to hours. Lebih murah dari Warm Standby.

🪤 Perangkap Soalan

Q: DR strategy: kos sederhana, RTO minit-jam OK, tapi tak nak bayar app compute idle 24/7. Core DB mesti sentiasa sedia. Pola mana?

⚠ Umpan: Warm Standby — sebab dia pun cepat recover & ada DB sedia. Nampak betul sebab 'DB sedia + cepat'. SALAH: Warm Standby app server SENTIASA ON (kecil) → bayar compute idle, lebih mahal.

✓ Betul: Pilot Light — DB ON (replicate), app server OFF sampai bencana. Keyword 'tak nak bayar app compute idle / DB sedia / kos sederhana' = Pilot Light.

Q: Pilot Light setup: bila bencana berlaku, apa yang kena buat sebelum traffic boleh dilayan?

⚠ Umpan: Terus failover DNS sahaja sebab semua dah berjalan. Nampak betul sebab 'DB dah replicate'. SALAH: dalam Pilot Light app server MATI — kena hidupkan & scale up dulu, baru DNS.

✓ Betul: Hidupkan + scale up app server, kemudian point DNS ke DR. Keyword 'app OFF sampai disaster' = perlu launch app dulu (RTO minit-jam).

Q: Financial institute — RTO/RPO ~20 minit, backup infra cost tak boleh tinggi. Mana strategi paling sesuai?

⚠ Umpan: Warm Standby — RTO minit memenuhi 20 minit. Nampak betul sebab 'cepat recover'. SALAH: soalan tekan BUDGET — Warm Standby bayar full stack idle (lebih mahal).

✓ Betul: Pilot Light — RTO/RPO '10s of minutes' cukup untuk ~20 min, data replicate aktif, app OFF → kos lebih rendah. Keyword 'tens of minutes + budget / backup cost not high' → Pilot Light.

Guna Bila

Core DB running in DR region, app servers off until needed

RPO: minutesRTO: minutes-hourscore DB runningapp servers offmedium costfinancial institutebudget concerns20 minutes RTOtens of minutes

📎 Pilot Light — Disaster recovery options in the cloud

D2 · Resilient

Warm Standby

DR Pattern: Warm Standby

"Anak syarikat kecil sedia — scale up masa emergency"

🎯 Sebab Apa Wujud

Wujud sebab Pilot Light masih perlu masa hidupkan & konfigur app server semasa bencana. Warm Standby = FULL stack (app + DB) dah BERJALAN di DR tapi saiz kecil (cth 2 EC2 vs 20 prod) — sentiasa hidup & boleh terima traffic sikit. Bila bencana, kau cuma SCALE UP yang sedia ada (laju) + failover DNS. Tujuan: recovery lebih laju dari Pilot Light (semua dah berjalan, cuma kena besarkan) dengan kos lebih rendah dari full active/active.

Apa Dia

Versi scaled-down penuh dari aplikasi running di DR region. Boleh handle traffic pada kapasiti rendah, scale up bila failover diperlukan

⚡ Quick Sifir — hafal ni

▪Warm Standby = full stack scaled-DOWN, sentiasa BERJALAN (app ON, kecil)
▪RPO saat-minit, RTO minit. Recovery = scale up + DNS failover
▪Beza vs Pilot Light: Warm Standby app ON (kecil); Pilot Light app OFF
▪Beza vs Multi-Site: Warm Standby kena scale up dulu (RTO minit); Multi-Site dah full (RTO saat)

💡 Exam Scenario

DR region running dengan 2 EC2 (vs 20 in prod). Disaster — scale up ASG, Route 53 failover ke DR. RPO: seconds/minutes, RTO: minutes. Lebih mahal dari Pilot Light tapi lagi cepat recover.

🪤 Perangkap Soalan

Q: Perlu recovery laju (RTO minit), full stack dah berjalan supaya bencana cuma perlu scale up + failover, tapi tak nak bayar 2× infra penuh. Pola mana?

⚠ Umpan: Multi-Site Active/Active — sebab dia paling laju recover. Nampak betul sebab 'recovery laju'. SALAH: Multi-Site bayar 2× full capacity, terlebih mahal untuk keperluan ni.

✓ Betul: Warm Standby — full stack scaled-DOWN, sentiasa ON, scale up bila failover. Keyword 'full stack jalan kecil / scale up / tak nak 2× penuh' = Warm Standby.

Q: Apa beza utama Warm Standby dengan Pilot Light?

⚠ Umpan: Warm Standby DB lebih besar, Pilot Light DB lebih kecil. Nampak betul sebab 'standby = lebih banyak'. SALAH: beza utama bukan saiz DB — ia status app server.

✓ Betul: Warm Standby app server ON (scaled-down, melayan traffic kecil); Pilot Light app server OFF. Keyword 'app ON vs OFF'.

Guna Bila

Scaled-down full stack running in DR, quick scale up

RPO: seconds/minutesRTO: minutesscaled-down activequick scale uphigher cost

📎 Warm Standby — Disaster recovery options in the cloud

D2 · Resilient

Multi-Site Active/Active

DR Pattern: Multi-Site Active/Active

"Dua HQ berjalan serentak — saling backup"

🎯 Sebab Apa Wujud

Wujud sebab ada sistem (banking, trading, kesihatan) yang downtime walau beberapa minit = bencana bes(rugi/jiwa). Semua strategi lain ada masa "recover". Multi-Site Active/Active = takde recovery langsung — DUA region jalan full capacity serentak, traffic dibahagi. Satu region mati, region lain dah pun melayan 100%, user tak perasan. Tujuan: zero-downtime, near-zero data loss untuk mission-critical — dengan harga paling mahal (bayar 2× infra penuh).

Apa Dia

Kedua-dua regions running full capacity serentak dengan traffic diagihkan. Tiada downtime bila satu region fail

⚡ Quick Sifir — hafal ni

▪Multi-Site = dua region FULL capacity, LIVE serentak (Route 53 weighted/latency)
▪RPO near-zero, RTO saat. Region fail = takde scale up, terus serap traffic
▪PALING MAHAL (2× full infra) — guna HANYA untuk mission-critical/zero-downtime
▪Bukan "near-zero/seconds"? Strategi lebih murah cukup (Warm Standby/Pilot Light)

💡 Exam Scenario

Banking app yang tak boleh ada downtime — full production environment kat dua regions. Route 53 weighted routing 50/50. Satu region fail → 100% traffic ke region sihat automatik. RPO: near-zero, RTO: seconds. Paling mahal tapi paling reliable.

🪤 Perangkap Soalan

Q: Banking app — downtime walau beberapa minit pun tak boleh diterima, RPO near-zero, RTO saat. Pola DR mana?

⚠ Umpan: Warm Standby + Route 53 failover — sebab dia cepat recover. Nampak betul sebab 'cepat'. SALAH: Warm Standby masih kena SCALE UP dulu (RTO minit), bukan saat → ada downtime.

✓ Betul: Multi-Site Active/Active — dua region full capacity LIVE serentak, region fail terus serap traffic (RTO saat). Keyword 'zero downtime / RTO saat / mission-critical' = Multi-Site.

Q: App dalaman, downtime sejam pun OK, nak jimat kos. Engineer cadang Multi-Site Active/Active untuk 'lebih selamat'. Sesuai?

⚠ Umpan: Sesuai — lebih reliable, kenapa tak. Nampak betul sebab 'paling selamat'. SALAH: Multi-Site bayar 2× infra penuh — membazir bila RTO/RPO longgar.

✓ Betul: Tak sesuai — guna Pilot Light atau Warm Standby yang lebih murah. Multi-Site HANYA untuk mission-critical/zero-downtime. Keyword 'RTO/RPO longgar → strategi murah'.

Guna Bila

Mission-critical — full capacity in both regions simultaneously

RPO: near-zeroRTO: secondsfull capacity bothhighest costmission-criticalzero downtime

📎 Multi-Site Active/Active — Disaster recovery options in the cloud

D2 · Resilient

AWS Elastic Disaster Recovery

AWS Elastic Disaster Recovery (AWS DRS)

"Replicate server berterusan ke AWS — failover bila bencana, failback bila pulih"

🎯 Sebab Apa Wujud

Wujud sebab nak bina DR sendiri (Pilot Light/Warm Standby) bermakna kau urus replikasi, AMI, scripting failover — leceh & senang silap. AWS DRS automate semua: ia replicate server kau berterusan (block-level) ke kawasan staging MURAH dalam AWS (cuma storage + compute kecil, BUKAN full instance), jadi kos rendah. Bila bencana, satu klik → ia spin up EC2 penuh dari state terkini (RPO saat, RTO minit). Lepas primary pulih, boleh failback. So you get near-Warm-Standby recovery at near-Pilot-Light cost, tanpa urus sendiri.

Apa Dia

The AWS service that implements low-cost disaster recovery. It does continuous block-level replication of your servers (on-prem, other cloud, or EC2) into a low-cost staging area in AWS. When disaster strikes you fail over — DRS launches full EC2 instances from the latest replicated state in minutes; when the primary recovers you can fail back. Formerly CloudEndure Disaster Recovery.

AWS DRS — replikasi murah → failover bila bencana

Rendering diagram…

Macam ada pelan insurans yang sentiasa simpan salinan terkini rumah kau di gudang murah — bila rumah terbakar, sehari boleh siap rumah penuh dari salinan tu, lepas tu boleh pindah balik. INGAT exam: "low-cost DR for servers, continuous replication, seconds RPO / minutes RTO, failover + failback" → AWS Elastic Disaster Recovery (DRS), BUKAN MGN (itu migration one-time).

AWS DRS vs MGN vs strategi DR (jangan keliru DR vs Migration)

Aspect	AWS DRS	AWS MGN	Warm Standby (DIY)
Tujuan	Disaster recovery (sedia failover)	Migration (pindah kekal)	Disaster recovery (urus sendiri)
Replikasi	Berterusan, block-level	Berterusan sampai cutover	Kau urus sendiri
Lepas selesai	Kekal standby, boleh failback	Cutover → habis, matikan source	Sentiasa berjalan (scaled-down)
Kos	Rendah (staging area minimal)	Bayar masa migrate je	Tinggi (full infra jalan)
RPO / RTO	Saat / minit	— (one-time)	Saat–minit / minit

Ingat: DRS & MGN guna teknologi replikasi sama, beza NIAT: DRS = DR (kekal sedia, failover + failback), MGN = migrate (one-time cutover, lepas tu matikan source). DRS bagi recovery hampir Warm Standby pada kos rendah & automated. Keyword "disaster recovery / failover" → DRS; "lift-and-shift migrate" → MGN.

⚡ Quick Sifir — hafal ni

▪AWS DRS = DR-as-a-service: continuous block-level replication server → staging area MURAH dalam AWS
▪RPO: saat (sub-second to seconds). RTO: minit. Kos rendah (staging guna resource minimal, bukan full instance)
▪Source boleh: on-prem, cloud lain, ATAU EC2 (cross-region/cross-AZ DR)
▪Failover = launch EC2 penuh dari replika terkini. Failback = balik ke primary bila pulih
▪Formerly CloudEndure Disaster Recovery
▪JANGAN keliru: DRS = Disaster recovery (replikasi berterusan, failover/failback). MGN = Migration (one-time cutover, lepas pindah habis cerita)

🪤 Perangkap Soalan

Q: Syarikat ada server on-prem kritikal. Mahu DR ke AWS dengan RPO beberapa saat & RTO beberapa minit, tapi TAK nak bayar full duplicate infra berjalan macam Warm Standby. Cara terbaik?

⚠ Umpan: Warm Standby — full stack scaled-down berjalan di AWS, jadi failover laju. Nampak betul sebab "ada infra = laju". SALAH: Warm Standby tetap bayar infra berjalan berterusan + kau urus replikasi sendiri; lebih mahal & leceh dari yang diperlukan.

✓ Betul: AWS Elastic Disaster Recovery (DRS) — continuous replication ke staging area MURAH (bukan full instance), failover spin up EC2 penuh dalam minit (RTO minit, RPO saat). Dapat kelajuan hampir Warm Standby pada kos hampir Pilot Light, automated. Keyword "DR for servers, seconds RPO + minutes RTO, low cost, no full standby" → AWS DRS.

Q: Pasukan nak PINDAH (migrate) server on-prem ke AWS sebagai EC2 secara kekal — lepas pindah, server lama dimatikan. Guna DRS?

⚠ Umpan: Guna AWS DRS sebab ia pun buat block-level replication server ke AWS. Nampak betul sebab "replicate server ke EC2". SALAH: DRS untuk DR (kekal sedia failover/failback), bukan untuk pindah-habis-cerita.

✓ Betul: AWS MGN (Application Migration Service) — direka untuk lift-and-shift migration (one-time cutover, server lama dimatikan). DRS untuk DR berterusan. Keyword "migrate/lift-and-shift permanently" → MGN; "ongoing disaster recovery / failover-failback" → DRS.

🧠 Cara Mudah Ingat

→AWS DRS = formerly CloudEndure Disaster Recovery — DR-as-a-service yang automate replikasi + failover
→Replikasi block-level berterusan ke staging area kos rendah (guna resource minimal, bukan full-size instance) → murah berbanding Warm Standby
→Failover: launch EC2 penuh dari replika terkini (RTO minit, RPO saat). Failback: balik ke source bila primary pulih
→Source: on-prem servers, server cloud lain, ATAU EC2 (untuk cross-region / cross-AZ DR antara region AWS)
→Boleh buat drill (test recovery) tanpa ganggu production — pastikan DR betul-betul jalan
→PRICING: ~$0.028/jam per source server direplikasi + kos staging (EBS snapshot/storage rendah) + EC2 penuh hanya semasa drill/failover. Jauh lebih murah dari full standby berjalan
→Exam discriminator: "low-cost DR / continuously replicate servers to AWS / fast failover + failback" → AWS DRS. "migrate servers to AWS permanently (lift-and-shift)" → MGN. "DIY DR tiers" → Backup&Restore/Pilot Light/Warm Standby/Multi-Site

Guna Bila

DR-as-a-service: continuously replicate on-prem/cloud/EC2 servers to AWS

AWS DRSElastic Disaster RecoveryCloudEndure Disaster Recoverycontinuous replicationblock-level replicationfailoverfailbackstaging arealow-cost DRDR as a serviceon-premises DRcross-region DRDRS vs MGNRPO secondsRTO minutespricing

📎 What is AWS Elastic Disaster Recovery

🗂️Backup & Storage Resilience↑ Top

D2 · Resilient

AWS Backup

"Backup manager untuk semua AWS services"

🎯 Sebab Apa Wujud

Dulu setiap service ada cara backup sendiri — RDS snapshot, EBS snapshot, EFS backup, DynamoDB PITR — semua manual, lain-lain tempat, susah nak prove ke auditor company comply. AWS Backup wujud sebagai satu 'control panel' tunggal: satu backup plan, satu retention policy, satu audit report untuk SEMUA service sekali gus. Pain yang ia buang: tak payah tulis script backup berasingan + senang nak buktikan compliance.

Apa Dia

Mengurus backup terpusat untuk pelbagai AWS services dengan backup policies, retention rules dan cross-region backup

AWS Backup — pecahan component (anatomy)

Backup Plan → "resepi": schedule (frequency) + retention + lifecycle (transition ke cold storage) + cross-region / cross-account copy

Resource assignment → pilih resource ikut TAG atau resource ID (auto-cover resource baru yang match tag)

Backup Vault → bekas tempat recovery point disimpan, encrypt dengan KMS

Vault Lock → WORM / immutable — Compliance mode TAK BOLEH undo (lindung dari delete admin/ransomware); Governance mode boleh dengan permission khas

Recovery Point → satu backup pada satu masa (macam snapshot) untuk satu resource

Backup Audit Manager → framework compliance + report (buktikan backup ikut policy ke auditor)

Pilih tool backup mana?

Rendering diagram…

Banyak service + audit → AWS Backup; EBS sahaja → DLM; satu service cukup → native. Kalau backup mesti immutable (ransomware/compliance) → Vault Lock Compliance mode (tak boleh undo). INGAT exam: "centralized + compliance report" = AWS Backup; "immutable backup" = Vault Lock.

AWS Backup vs DLM vs native per-service backup

Aspect	AWS Backup	Data Lifecycle Manager (DLM)	Native per-service
Skop	🟢 Banyak service (EBS, RDS, EFS, DynamoDB, FSx, S3, EC2…)	EBS snapshot + AMI SAHAJA	Satu service je (RDS auto-backup, DynamoDB PITR)
Centralized + audit	🟢 Ya — satu tempat + Backup Audit Manager	🔴 Tak	🔴 Tak (berselerak)
Immutable / WORM	🟢 Vault Lock (anti-ransomware)	🔴 Tak	Terhad
Kos service	Free (bayar storage backup)	Free	Selalunya included
Guna bila	Compliance / cross-service / audit / cross-region	Automate EBS snapshot je, ringkas	Cukup untuk satu service sahaja

Ingat: "Centralized / cross-service / compliance report / immutable backup" → AWS Backup. "Automate EBS snapshot je" → DLM (lagi ringkas + free). Satu service sahaja & dah cukup → native (RDS automated backup, DynamoDB PITR).

⚡ Quick Sifir — hafal ni

▪AWS Backup = CENTRALIZED backup across services (EFS, EBS, RDS, Aurora, DynamoDB, S3, FSx, EC2 AMI, Storage Gateway)
▪Backup Plan = schedule + retention + cross-region copy, semua di satu tempat
▪Backup Audit Manager = compliance report (prove backups ikut policy)
▪EFS backup = AWS Backup (BUKAN File Gateway, BUKAN FSx Gateway)
▪PERCUMA service; bayar storage backup (cth backup ke Backup Vault, Glacier-class untuk cold)

💡 Exam Scenario

Company kena comply dengan policy backup 90-hari untuk semua databases — AWS Backup create backup plan, auto backup RDS + DynamoDB + EFS setiap hari, retain 90 hari, auto copy ke DR region. "Backup tak boleh delete walaupun admin/ransomware" → Vault Lock (WORM, compliance mode).

🪤 Perangkap Soalan

Q: Company kena backup EFS file system ikut retention policy 90 hari + prove ke auditor. Service mana?

⚠ Umpan: S3 File Gateway / FSx File Gateway — nampak macam 'gateway' boleh backup file, tapi Gateway = hybrid ACCESS storage, bukan backup tool.

✓ Betul: AWS Backup — keyword 'centralized backup + retention + compliance report' = AWS Backup (+ Backup Audit Manager untuk audit).

Q: Nak satu tempat manage + audit backup untuk RDS, DynamoDB, dan EBS sekali gus. Apa pilih?

⚠ Umpan: Buat manual RDS automated backup + DynamoDB PITR + EBS snapshot lifecycle — boleh jadi tapi berselerak, susah audit, bukan 'centralized'.

✓ Betul: AWS Backup — keyword 'single place / centralized / cross-service' terus pointing ke AWS Backup.

🧠 Cara Mudah Ingat

→AWS Backup supports: EFS, EBS, RDS, Aurora, DynamoDB, S3, FSx, EC2 AMIs, Storage Gateway volumes, DocumentDB, Neptune, Redshift
→"centralized backup management + monitoring + auditing reporting" → AWS Backup (every time)
→Backup Audit Manager: compliance framework + reporting for audit — "prove backups meet policy" → Backup Audit Manager
→Vault Lock (WORM): Compliance mode = TAK BOLEH undo/delete walaupun root (anti-ransomware/regulatory); Governance mode = boleh dengan permission khas. Keyword "immutable / cannot be deleted / ransomware protection" → Vault Lock
→S3 File Gateway ≠ EFS backup. FSx File Gateway ≠ EFS backup. For EFS backup → AWS Backup.
→PRICING: service PERCUMA — bayar (1) storage backup (warm ~$0.05/GB-mo EBS-class; cold storage lagi murah untuk EFS/DynamoDB) + (2) restore + (3) cross-region/cross-account copy = data transfer. Cost note: lifecycle ke cold storage jimat untuk retention panjang.

Guna Bila

Centralized backup across EC2, RDS, EFS, DynamoDB, S3

centralized backupbackup plansbackup vaultvault lockWORMimmutable backupransomware protectionretentioncross-regioncross-accountcomplianceautomatedEFS backupBackup Audit Managermonitoringpricing

📎 What is AWS Backup?📎 AWS Backup Vault Lock 📎 Backup Audit Manager

D2 · Resilient

S3 Versioning & CRR

S3 Versioning + Cross-Region Replication

"Simpan semua versi, auto copy ke region lain"

🎯 Sebab Apa Wujud

S3 by default OVERWRITE atau DELETE terus — sekali tersilap delete atau replace file, hilang selamanya. Versioning wujud supaya setiap perubahan jadi 'version' baru, version lama masih ada untuk restore (termasuk recover dari accidental delete sebab delete cuma letak delete marker). CRR pula wujud sebab data dalam satu region je = risiko bila region down atau untuk compliance 'data mesti ada di region lain' — ia auto-copy objects ke bucket region berbeza.

Apa Dia

Versioning simpan semua versi object untuk recovery. CRR auto-replicate objects ke S3 bucket dalam region lain untuk disaster recovery

Versioning + Replication — pecahan component

Versioning → setiap PUT jadi version baru (version ID unik); delete = letak delete marker (object "hilang" tapi versi lama kekal, boleh undo). Kena enable per bucket; sekali ON cuma boleh suspend, tak boleh OFF

Delete marker → penanda "latest = deleted"; buang delete marker = object muncul balik

MFA Delete → wajib kod MFA untuk delete version / suspend versioning (lindung dari delete malicious)

Replication (CRR/SRR) → auto-copy object ke bucket lain, ASYNC, objek BARU sahaja selepas enable

S3 Batch Replication → replicate object SEDIA ADA (existing) yang wujud sebelum rule di-enable

Replication rules → boleh tapis by prefix/tag, tukar storage class di destinasi, tukar owner (cross-account)

Versioning / CRR / SRR — pilih yang mana

Rendering diagram…

Undo delete → Versioning. Salinan region lain → CRR. Salinan region sama → SRR. Replication WAJIB versioning ON dua-dua hujung, async, objek baru je (existing → S3 Batch Replication). INGAT exam: "previous version" = Versioning; "different region" = CRR; "same region, another bucket/account" = SRR.

Versioning vs CRR vs SRR — recovery ke DR?

Feature	Buat apa	Guna bila (keyword)
Versioning	Simpan semua versi dalam bucket SAMA; undo overwrite/delete	"restore previous version / accidental delete / undo overwrite"
CRR (Cross-Region)	Auto-copy ke bucket region BERBEZA	"DR / different region / data residency / latency dekat user region lain"
SRR (Same-Region)	Auto-copy ke bucket region SAMA (beza bucket/account)	"aggregate logs / compliance / replicate to another account, same region"

Ingat: Undo silap delete/overwrite → Versioning (bucket sama). Region lain untuk DR/residency → CRR. Region sama (log aggregation / cross-account) → SRR. PENTING: Versioning WAJIB ON di source & destination sebelum replication boleh jalan. CRR ≠ backup versi lama — ia copy ke region lain je.

⚡ Quick Sifir — hafal ni

▪Versioning = simpan SEMUA versi; delete = letak delete marker je, boleh undo
▪Versioning kena ENABLE dulu BEFORE replication — CRR wajib versioning ON kat source & destination
▪CRR = Cross-Region (region lain) ; SRR = Same-Region Replication (region sama, beza account/bucket)
▪Replication = ASYNC + objek BARU sahaja (existing object kena S3 Batch Replication)
▪MFA Delete = extra protection, kena MFA untuk delete version (lawan accidental/malicious delete)

💡 Exam Scenario

Developer accidentally delete important file dalam S3 — Versioning enable restore previous version. CRR auto-copy semua objects ke DR bucket kat region lain untuk disaster recovery. "Replicate ke region lain, latency rendah untuk user" → CRR. "Compliance kena data 2 region" → CRR. "Aggregate log dari banyak bucket ke satu bucket region sama" → SRR.

🪤 Perangkap Soalan

Q: Developer accidentally overwrite file penting dalam S3. Macam mana recover ke versi sebelum?

⚠ Umpan: Enable CRR — orang ingat 'replication = backup', tapi CRR cuma copy ke region lain, tak bagi balik versi LAMA dalam bucket asal.

✓ Betul: S3 Versioning — keyword 'restore previous version / undo overwrite' = Versioning (setiap overwrite jadi version baru).

Q: Compliance kata objects mesti disimpan di region kedua untuk DR. Pilih apa?

⚠ Umpan: S3 Versioning sahaja — versioning lindung dari delete tapi semua versi DUDUK region sama; region down = tetap hilang.

✓ Betul: Cross-Region Replication (CRR) — keyword 'different region / DR / data residency' = CRR (ingat: versioning kena ON dulu).

🧠 Cara Mudah Ingat

→Versioning sekali ENABLE tak boleh OFF — cuma boleh SUSPEND (versi sedia ada kekal). Delete object = delete marker; nak betul-betul buang kena delete version ID
→Replication = ASYNC + objek BARU selepas rule enable. Object SEDIA ADA → guna S3 Batch Replication. Replication TAK retroaktif
→CRR vs SRR: CRR = region BEZA (DR, data residency, latency dekat user region lain). SRR = region SAMA (log aggregation, cross-account, compliance same-region)
→MFA Delete: extra layer — kena MFA untuk delete version atau suspend versioning. Lindung dari delete accidental/malicious
→Versioning naikkan kos sebab simpan SEMUA versi — guna S3 Lifecycle untuk expire noncurrent versions / transition ke kelas murah
→PRICING: Versioning sendiri free, TAPI kau bayar storage SETIAP versi (versi lama makan ruang). Replication = bayar storage di destinasi + request + cross-region data transfer (CRR). Jimat: lifecycle rule buang noncurrent versions.

Guna Bila

Protect against accidental deletion, cross-region DR for S3

versioningCRRSRRdelete markerMFA Deleteaccidental deletioncross-region replicationsame-region replicationS3 Batch Replicationnoncurrent versiondata residencypoint-in-time recoverypricing

📎 Using versioning in S3 buckets 📎 S3 Replication (CRR & SRR)📎 S3 Batch Replication (existing objects)

D2 · Resilient

EBS Snapshots

Amazon EBS Snapshots

"Gambar volume pada satu masa — restore anytime"

🎯 Sebab Apa Wujud

EBS volume tied ke satu AZ — kalau AZ rosak, atau OS dalam volume corrupt/kena ransomware, kau hilang data. Snapshot wujud sebagai backup point-in-time yang disimpan dalam S3 (durable, 11 nines, merentas AZ), jadi kau boleh restore volume balik atau create volume baru di AZ/region lain. Pain yang ia buang: EBS sendiri tak survive AZ failure — snapshot bagi recovery + portability.

Apa Dia

Mencipta backup incremental EBS volume ke S3 untuk recovery atau create volumes baru dalam AZ atau region lain

EBS Snapshots — bahagian & feature (semua duduk atas S3 belakang tabir)

Standard tier → snapshot biasa, INCREMENTAL (block berubah je disimpan), disimpan dalam S3 managed. $0.05/GB-mo

Archive tier (Snapshot Archive) → untuk snapshot rarely-accessed simpan 90+ hari. Convert incremental → FULL snapshot, sampai 75% lebih murah. Restore ambil 24-72 jam

Fast Snapshot Restore (FSR) → volume yang dibuat dari snapshot terus fully-initialized, takde first-access latency. Enable per snapshot + per AZ, max 5/Region, snapshot ≤16 TiB. Mahal (DSU-hours)

Data Lifecycle Manager (DLM) → automate create + retention + copy snapshot ikut schedule (tag-based). PERCUMA

Copy & Share → copy snapshot cross-region/cross-account (cara pindah EBS data merentas region); share private (modify permissions) atau public

Recycle Bin → retention rule untuk recover snapshot/AMI yang ter-delete dalam tempoh tertentu

Mekanik incremental — kenapa snapshot ke-2 murah

Rendering diagram…

Snapshot INCREMENTAL: hanya block yang berubah disimpan, tapi restore tetap bagi full volume. Sebab tu snapshot ke-2 ke-3 murah. INGAT exam: "incremental storage tapi full restore" = EBS snapshot. Padam snapshot lama selamat — AWS pindah block yang masih diperlukan ke snapshot berikut.

Pilih: snapshot lifecycle & feature mana

Rendering diagram…

Setiap pain ada feature sendiri. INGAT exam: cross-region → COPY snapshot · automate → DLM (free) · arkib jimat kos → Archive tier · hapus first-access latency → FSR · undo delete → Recycle Bin. Jangan keliru DLM (automate) dengan FSR (laju restore).

Standard tier vs Archive tier (jangan keliru kos & kelajuan)

Aspect	Standard tier	Archive tier
Format simpan	Incremental (block berubah je)	Full snapshot (semua block)
Kos	$0.05/GB-mo	Sampai 75% lebih murah (~$0.0125/GB-mo)
Kelajuan restore	Serta-merta (terus guna)	24-72 jam (kena restore ke standard dulu)
Min retention	Tiada	90 hari
Guna bila	Backup aktif, DR, restore kerap	Compliance / end-of-project, jarang akses

Ingat: Keyword "rarely accessed / long-term / 90+ days / compliance archive" → Archive tier (jimat sampai 75% TAPI restore lambat 24-72 jam + min 90 hari). Backup yang mungkin kena restore cepat → kekal Standard tier.

EBS Snapshot vs AMI vs Recycle Bin (sering tertukar)

Benda	Apa dia	Guna bila
EBS Snapshot	Backup point-in-time SATU volume → S3	Restore/clone volume, DR cross-region
AMI	Template launch EC2 (root volume + metadata, boleh banyak snapshot)	Boot EC2 baru yang identical
Recycle Bin	Retention rule untuk recover snapshot/AMI ter-delete	Undo accidental/malicious delete

Ingat: Snapshot = backup 1 volume. AMI = blueprint untuk boot EC2 (mengandungi snapshot). Recycle Bin = jaring keselamatan bila tersilap padam. Keyword "accidentally deleted snapshot / protect against deletion" → Recycle Bin.

⚡ Quick Sifir — hafal ni

▪Snapshot = INCREMENTAL (cuma block yang berubah disimpan) tapi restore = full volume
▪Snapshot disimpan dalam S3 (managed, kau tak nampak bucket) — durable merentas AZ
▪Copy snapshot ke region lain = cara pindah EBS data cross-region (volume sendiri AZ-locked)
▪DLM (Data Lifecycle Manager) = automate snapshot schedule + retention, PERCUMA
▪PRICING: snapshot $0.05/GB-month (incremental). Fast Snapshot Restore (FSR) = extra cost, no first-access latency

💡 Exam Scenario

EC2 kena ransomware, OS corrupted — restore EBS dari snapshot semalam. Atau copy snapshot ke region lain untuk DR, create new EC2 dari snapshot tu. "Rarely-accessed snapshot simpan 90+ hari, jimat kos" → Snapshot Archive tier. "Restore volume tanpa first-access latency" → Fast Snapshot Restore (FSR). "Automate schedule + retention" → Data Lifecycle Manager (DLM). "Tersilap delete snapshot, nak recover" → Recycle Bin.

🪤 Perangkap Soalan

Q: Nak pindah EBS volume dari us-east-1 ke eu-west-1 untuk DR. Macam mana?

⚠ Umpan: Detach volume, attach ke region lain — TAK BOLEH, EBS volume terkunci dalam satu AZ/region, tak boleh attach merentas region.

✓ Betul: Buat snapshot → COPY snapshot ke region lain → create volume baru dari snapshot. Keyword 'cross-region EBS' = copy snapshot.

Q: Nak automate daily EBS backup + buang yang lebih 30 hari, tanpa script sendiri. Guna apa?

⚠ Umpan: Tulis Lambda + EventBridge cron untuk create/delete snapshot — boleh tapi extra ops, ada service siap sedia.

✓ Betul: Data Lifecycle Manager (DLM) — keyword 'automated EBS snapshot schedule + retention' = DLM (free).

🧠 Cara Mudah Ingat

→Incremental tapi self-contained: padam snapshot lama TAK rosakkan snapshot baru — AWS pindah block yang masih diperlukan. Restore sentiasa bagi full volume
→Cross-region DR: COPY snapshot ke region lain (EBS volume AZ-locked, tak boleh attach cross-region). Cross-account: modify permissions / share. Snapshot encrypted dengan custom KMS key kena share key tu juga
→Encryption: snapshot dari encrypted volume = encrypted. Copy snapshot boleh tukar/ tambah encryption (re-encrypt dengan KMS key lain). Unencrypted → encrypted: BOLEH masa copy/create volume
→Fast Snapshot Restore (FSR): volume terus fully-initialized, takde first-access I/O latency. Enable per snapshot + per AZ, max 5/Region, snapshot ≤16 TiB, TAK support Outposts/Local Zones/Wavelength. Mahal — guna untuk RTO ketat je
→Data Lifecycle Manager (DLM): automate create/retain/copy snapshot & AMI guna tag, PERCUMA — elak tulis Lambda+EventBridge sendiri. AWS Backup pula centralized merentas banyak service (EBS+RDS+EFS+DynamoDB...)
→PRICING: Standard snapshot $0.05/GB-mo (incremental). Archive tier sampai 75% lebih murah (~$0.0125/GB-mo) min 90 hari + restore fee. FSR dicaj per DSU-hour setiap AZ yang di-enable (mahal). DLM percuma. Copy snapshot = caj data transfer + storage di destinasi

Guna Bila

Point-in-time backup of EBS volumes, cross-region DR

incremental backuppoint-in-timecross-AZcross-region copyEC2 recoverySnapshot Archivearchive tierFast Snapshot RestoreFSRData Lifecycle ManagerDLMRecycle BinAMI vs snapshotsnapshot encryptionKMScross-account sharerarely accessedlong-term backupfirst-access latencypricing

📎 EBS snapshots 📎 Snapshot Archive 📎 Fast Snapshot Restore

D2 · Resilient

FSx

Amazon FSx

"EFS tapi untuk Windows, HPC, atau enterprise NAS"

🎯 Sebab Apa Wujud

EFS cuma support NFS (Linux/POSIX) — tapi ramai enterprise guna Windows apps yang perlu SMB + Active Directory, atau HPC yang perlu throughput gila-gila, atau dah ada NetApp on-prem nak migrate. FSx wujud bagi managed file system untuk kes-kes yang EFS tak boleh handle: Windows SMB, Lustre HPC, NetApp ONTAP, OpenZFS. Pain yang ia buang: tak payah build & patch Windows file server atau Lustre cluster sendiri atas EC2.

Apa Dia

Empat pilihan: FSx for Windows (SMB/NTFS, AD integration), FSx for Lustre (high-throughput HPC, S3 integration), FSx for NetApp ONTAP (enterprise NAS migration), FSx for OpenZFS.

FSx — 4 jenis file system (pilih ikut workload)

FSx for Windows File Server → SMB / NTFS + Active Directory, DFS namespaces, VSS shadow copies. Single-AZ atau Multi-AZ. Untuk Windows apps & file share

FSx for Lustre → POSIX, throughput ratus GB/s + jutaan IOPS, sub-ms latency. Native S3 integration (DRA). Dua deployment: Scratch (sementara, no replication, murah) vs Persistent (durable, replicated dalam AZ). Untuk HPC / ML / media

FSx for NetApp ONTAP → MULTI-PROTOCOL (NFS + SMB + iSCSI serentak), feature ONTAP penuh: snapshot, SnapMirror, dedup, compression, auto data tiering ke capacity pool murah. Untuk migrate NetApp enterprise

FSx for OpenZFS → NFS (v3/v4.x), powered by OpenZFS, snapshot + low latency. Untuk migrate ZFS / Linux NFS workload

Semua → fully managed (no patch/scale server), backup automatik, encrypt at rest (KMS) + in transit

Pilih FSx (atau EFS) mana?

Rendering diagram…

Cabang ikut workload: Windows→Windows, HPC+S3→Lustre, NetApp/multi-protocol→ONTAP, ZFS→OpenZFS, general Linux NFS→EFS. INGAT exam: "Windows" atau "SMB" muncul → FSx Windows, BUKAN EFS. "high throughput + S3 integration" → Lustre. "multi-protocol / NetApp" → ONTAP.

4 jenis FSx — protokol, kekuatan, keyword exam

FSx type	Protokol	Kekuatan utama	Keyword exam
FSx for Windows	SMB (NTFS)	Active Directory, DFS, VSS — Windows-native	"Windows / SMB / Active Directory / NTFS file share"
FSx for Lustre	POSIX (Linux)	Throughput gila + S3 integration (DRA)	"HPC / ML / high throughput / POSIX + S3"
FSx for NetApp ONTAP	NFS + SMB + iSCSI	Multi-protocol + ONTAP features + tiering	"NetApp / migrate NAS / multi-protocol / SnapMirror"
FSx for OpenZFS	NFS	ZFS snapshots, low-latency, migrate ZFS	"ZFS / Linux NFS migration / OpenZFS"

Ingat: Windows+SMB+AD → Windows. HPC POSIX + S3 → Lustre. Multi-protocol (NFS+SMB+iSCSI) atau NetApp → ONTAP. ZFS/Linux NFS → OpenZFS. Lawan EFS: EFS = general NFS Linux SAHAJA, no SMB, no S3-native. Bila soalan sebut "Windows" atau "SMB" → JANGAN pilih EFS.

⚡ Quick Sifir — hafal ni

▪FSx for Windows = SMB/NTFS + Active Directory (Windows file share)
▪FSx for Lustre = HPC high-throughput + native S3 integration (DRA)
▪FSx for NetApp ONTAP = migrate enterprise NetApp/NAS ke AWS (multi-protocol)
▪FSx for OpenZFS = migrate ZFS / Linux NFS workload
▪EFS = general NFS (Linux je); Windows SMB → FSx Windows, BUKAN EFS

💡 Exam Scenario

"Windows apps perlu SMB file share" → FSx for Windows. "HPC workload perlu high-throughput scratch storage" → FSx for Lustre. "Migrate on-prem NetApp storage ke AWS" → FSx for NetApp ONTAP. "Migrate ZFS / Linux NFS workload" → FSx for OpenZFS.

🪤 Perangkap Soalan

Q: Windows application perlu shared file storage guna SMB protocol + integrate Active Directory. Pilih apa?

⚠ Umpan: Amazon EFS — orang ingat 'EFS = shared file storage' jadi pilih EFS, tapi EFS NFS-only, tak support SMB/Windows.

✓ Betul: FSx for Windows File Server — keyword 'SMB / NTFS / Active Directory / Windows file share' = FSx Windows.

Q: HPC workload perlu POSIX file system, throughput sangat tinggi, dan baca/tulis data terus dari S3. Pilih apa?

⚠ Umpan: EFS — POSIX betul, tapi EFS tak ada S3 native integration dan throughput tak setanding Lustre untuk HPC.

✓ Betul: FSx for Lustre — keyword 'HPC + high throughput + S3 integration (DRA)' = FSx for Lustre.

Q: Migrate enterprise NetApp NAS on-prem ke AWS tapi nak kekalkan feature ONTAP (snapshot, SnapMirror, dedup) + access guna NFS DAN SMB sekali. Pilih apa?

⚠ Umpan: FSx for OpenZFS — nampak macam 'NAS migration', tapi OpenZFS untuk ZFS/Linux NFS workload, bukan NetApp.

✓ Betul: FSx for NetApp ONTAP — keyword 'NetApp / multi-protocol NFS+SMB+iSCSI / SnapMirror / enterprise NAS' = ONTAP.

🧠 Cara Mudah Ingat

→FSx for Lustre: natively integrates with S3 via Data Repository Associations (DRA) — objects lazily imported from S3, processed files can be exported back to S3
→FSx for Lustre deployment: Scratch = temporary, NO replication, cheapest (HPC scratch, data boleh rebuild); Persistent = durable, replicated dalam satu AZ (long-lived). Keyword "temporary scratch / cheapest" → Scratch
→FSx for Lustre + DataSync: DataSync supports FSx for Lustre as a transfer location — use for scheduled bulk transfers to/from FSx Lustre
→Exam: "POSIX + S3 integration + high throughput" → FSx for Lustre (not EFS). EFS is general-purpose NFS, no S3 native integration
→FSx for Windows: Single-AZ or Multi-AZ deployments; SSD or HDD storage; SMB/NTFS NOT POSIX. Multi-AZ = HA (standby di AZ lain)
→FSx for NetApp ONTAP: SATU-SATUNYA FSx multi-protocol (NFS + SMB + iSCSI serentak). Ada auto-tiering ke "capacity pool" yang murah untuk data sejuk
→FSx for Windows access: supports cross-VPC/account/region via VPC Peering or Transit Gateway; on-premises via Direct Connect or VPN
→DRA = Data Repository Association: links FSx Lustre file system to an S3 bucket for automatic import/export
→PRICING: (approximate, per GB-month) FSx Lustre Scratch SSD ~$0.140 (cheapest, no replication); Lustre Persistent lebih mahal ikut throughput tier; FSx Windows SSD ~$0.13 + throughput capacity, HDD ~$0.013 (murah); FSx ONTAP SSD primary ~$0.022/GB-mo + capacity-pool tiering lagi murah untuk data sejuk; FSx OpenZFS SSD ~$0.09. Cost discriminator: HPC temporary → Lustre Scratch; nak murah Windows → HDD; data sejuk besar → ONTAP tiering.

Guna Bila

Managed file systems: Windows SMB, HPC Lustre, NetApp ONTAP, OpenZFS

Windows SMBNTFSActive DirectoryDFSVSSLustre HPCScratchPersistentNetApp ONTAPSnapMirrormulti-protocolOpenZFSZFSmanaged file systemS3 integrationDRADataSyncmulti-AZsingle-AZPOSIXcapacity pool tieringpricing

📎 Choosing an Amazon FSx file system 📎 FSx for Lustre — link to S3 (DRA)📎 FSx for NetApp ONTAP

D2 · Resilient

Storage Gateway

AWS Storage Gateway

"Jambatan on-prem ↔ AWS." Mnemonic 4 jenis = FBT: Fail (File GW → S3 atau FSx), Blok (Volume GW, iSCSI), Tape (Tape GW, VTL). Cached vs Stored → "Cached = Cloud dulu (primary S3); Stored = Simpan Sini (primary on-prem)".

🎯 Sebab Apa Wujud

Banyak company ada apps lama on-premises yang expect local storage (NFS, SMB, iSCSI, atau tape) — tak boleh tukar code untuk cakap dengan S3 API. Storage Gateway wujud sebagai 'penterjemah' yang duduk on-prem: apps fikir depa guna disk/tape biasa, tapi belakang tabir data masuk S3/Glacier/EBS. Pain yang ia buang: extend storage ke cloud TANPA tukar aplikasi, dan ini ONGOING (bukan one-time macam DataSync).

Apa Dia

EMPAT jenis: S3 File Gateway (NFS/SMB → S3), FSx File Gateway (SMB → Amazon FSx for Windows, ada AD), Volume Gateway (iSCSI block → EBS snapshots, mode Cached vs Stored), Tape Gateway (virtual tape library/VTL → S3 + Glacier). On-premises apps tak perlu tahu depa sebenarnya guna cloud storage — ada local cache untuk akses laju.

Storage Gateway — 4 jenis (protokol on-prem → backend AWS)

S3 File Gateway → mount NFS/SMB on-prem, file disimpan sebagai object dalam S3 (boleh lifecycle ke Glacier). Local cache untuk akses laju

FSx File Gateway → mount SMB on-prem dengan Active Directory, backend Amazon FSx for Windows File Server. Untuk Windows file share low-latency

Volume Gateway → expose iSCSI block volume ke server on-prem. Backup point-in-time = EBS snapshot dalam S3. Dua mode: Cached vs Stored

Tape Gateway → virtual tape library (VTL) — backup software lama tulis "tape", sebenarnya masuk S3 lepas tu arkib ke Glacier / Deep Archive

Local cache / upload buffer → semua gateway ada disk tempatan untuk cache hot data + buffer sebelum hantar ke AWS (akses latency rendah)

Anatomi — gateway jadi jambatan on-prem ↔ AWS storage

Rendering diagram…

Gateway = penterjemah on-prem: apps fikir depa guna disk/tape biasa, belakang tabir data masuk AWS. Local cache bagi akses latency rendah. INGAT exam: NFS/SMB→S3 = S3 File GW · SMB+AD→FSx Windows = FSx File GW · iSCSI block = Volume GW · ganti tape/VTL = Tape GW. Storage Gateway = akses HYBRID berterusan, bukan migration one-time (itu DataSync) atau offline bulk (Snow).

Pilih gateway type — decision tree

Rendering diagram…

Tanya jenis akses dulu. File → FSx File GW (Windows/AD) atau S3 File GW (generik). Block iSCSI → Stored (low-latency seluruh dataset, primary local) atau Cached (jimat on-prem, primary di S3). Tape/VTL → Tape Gateway. INGAT exam: "Windows file share + AD" = FSx File GW; "low latency to entire dataset" = Stored volume.

4 jenis Storage Gateway — pilih ikut protokol & backend

Type	Protokol on-prem	Backend AWS	Guna bila (keyword)
S3 File Gateway	NFS / SMB	S3 (+ lifecycle Glacier)	File share on-prem → object S3, ongoing
FSx File Gateway	SMB	Amazon FSx for Windows	Windows file share + Active Directory, low-latency
Volume Gateway	iSCSI (block)	EBS snapshots dalam S3	Block volume on-prem + backup ke cloud
Tape Gateway	iSCSI VTL (tape)	S3 + Glacier/Deep Archive	Ganti physical tape / legacy backup software

Ingat: File NFS/SMB → S3 File GW. Windows+AD → FSx File GW. Block iSCSI → Volume GW. Tape/VTL → Tape GW. Semua ada local cache untuk latency rendah. Storage Gateway = hybrid ONGOING; DataSync = migration; Snow = offline bulk.

Volume Gateway: Cached vs Stored (jangan keliru)

Aspect	Cached volume	Stored volume
Data utama (primary)	🪣 S3 (cloud)	💽 On-prem (local disk)
Cache on-prem	Hot data je	Semua data dah local
Backup ke S3	Primary memang di S3	Async EBS snapshot (point-in-time)
Max saiz / volume	32 TB (max 1 PB/gateway)	16 TB (max 512 TB/gateway)
Guna bila	Jimat storage on-prem, dataset besar	Low-latency akses SELURUH dataset + DR backup

Ingat: Soalan kunci: "primary data DEKAT MANA?" Cached = primary di S3 (on-prem cache hot je → jimat ruang). Stored = primary on-prem (akses penuh latency rendah), snapshot ke S3 untuk DR. Keyword "low latency to ENTIRE dataset" → Stored; "minimize on-prem storage / cache only hot data" → Cached.

⚡ Quick Sifir — hafal ni

▪S3 File Gateway = NFS/SMB → S3 (file access). FSx File Gateway = SMB + Active Directory → Amazon FSx for Windows
▪Volume Gateway = iSCSI block → backup ke EBS snapshot (Cached vs Stored mode)
▪Tape Gateway = virtual tape library (VTL) → S3 Glacier (ganti physical tape)
▪Storage Gateway = ONGOING hybrid access; DataSync = ONE-TIME/scheduled migration; Snow = offline bulk
▪Volume Cached = data utama di S3, hot data cache on-prem (max 32TB/vol); Stored = data utama on-prem, snapshot ke S3 (max 16TB/vol)
▪Keyword: 'low latency to ENTIRE dataset' → Stored; 'minimize on-prem storage / cache hot je' → Cached

💡 Exam Scenario

"On-premises apps nak access S3 via NFS/SMB" → S3 File Gateway. "Windows file share + Active Directory, low latency" → FSx File Gateway. "Replace physical tape library / legacy backup software (VTL)" → Tape Gateway. "Block volume iSCSI on-prem + backup ke cloud" → Volume Gateway. "Low latency akses SELURUH dataset" → Stored volume; "jimat storage on-prem, cache hot je" → Cached volume. "Ongoing hybrid access" → Storage Gateway (BUKAN DataSync = one-time migration, BUKAN Snow = offline bulk).

🪤 Perangkap Soalan

Q: Company nak ganti physical tape backup library dengan cloud tapi backup software lama mereka cuma tahu cakap dengan tape. Pilih apa?

⚠ Umpan: S3 Glacier terus — Glacier murah untuk archive, tapi backup software lama tak tahu cakap S3 API, kena tape interface.

✓ Betul: Tape Gateway — keyword 'replace physical tape / VTL / legacy backup software' = Tape Gateway (belakang ia simpan ke Glacier).

Q: On-prem apps perlu access S3 secara ONGOING melalui NFS mount tanpa tukar code. Pilih apa?

⚠ Umpan: AWS DataSync — DataSync pindah file ke S3, tapi ia untuk MIGRATION berjadual, bukan mount NFS ongoing untuk app.

✓ Betul: File Gateway (Storage Gateway) — keyword 'ongoing hybrid access / NFS-SMB mount ke S3' = File Gateway.

🧠 Cara Mudah Ingat

→S3 File Gateway vs FSx File Gateway: dua-dua file, tapi S3 File GW = generik NFS/SMB → object S3 (boleh lifecycle ke Glacier); FSx File GW = khusus SMB + Active Directory → Amazon FSx for Windows (native Windows file share, low-latency). Keyword "Windows / SMB / Active Directory / NTFS" → FSx File Gateway
→Volume Gateway Cached: primary data di S3, cache hot data on-prem — max 32TB/volume, sampai 1PB per gateway (32 volume). Guna bila nak jimat ruang on-prem
→Volume Gateway Stored: primary data SEMUA on-prem (low-latency penuh), async snapshot ke S3 sebagai EBS snapshot untuk DR — max 16TB/volume, sampai 512TB per gateway
→Tape Gateway = ganti physical tape library; backup software lama tulis ke "virtual tape", AWS simpan ke S3 lepas tu arkib ke Glacier / Deep Archive. Keyword "replace tape / VTL / legacy backup" → Tape Gateway
→Storage Gateway (ongoing hybrid) vs DataSync (one-time/scheduled migration) vs Snow Family (offline bulk bila network tak praktikal) — exam favourite untuk keliru tiga ni
→PRICING: bayar (1) underlying AWS storage yang diguna pada kadar standard (S3 $0.023/GB-mo, Glacier, EBS snapshot $0.05/GB-mo) + (2) ~$0.01/GB data ditulis ke AWS melalui gateway, capped ~$125/gateway/bulan + (3) request & data transfer-out ikut kadar biasa. Tiada caj untuk gateway VM itu sendiri.
→Exam cost: "cheapest archive backend untuk Tape Gateway" → Glacier Deep Archive ($0.00099/GB-mo). "minimize on-prem storage cost" → Cached volume (primary di S3) atau S3 File Gateway + lifecycle ke Glacier

Guna Bila

Hybrid cloud storage — on-premises apps guna AWS storage secara seamless

hybrid storageS3 File GatewayFSx File GatewayVolume GatewayTape Gatewaycached volumestored volumeVTLvirtual tape libraryon-premisesNFSSMBiSCSIActive DirectoryEBS snapshotlocal cacheongoing hybrid accesslegacy backup softwarereplace physical tapelow latency entire datasetminimize on-prem storagepricing

📎 What is Storage Gateway (Volume)📎 Amazon FSx File Gateway 📎 Storage Gateway pricing

D2 · Resilient

DataSync

AWS DataSync

"Pemindah data automatik dan laju — dari on-prem ke AWS atau cross-region"

🎯 Sebab Apa Wujud

Pindah data besar dari on-prem ke AWS guna script (rsync, cp) atau tulis sendiri = lambat, tak ada verification, senang putus di tengah, dan kena manage network throttling. DataSync wujud sebagai pemindah data automatik yang handle scheduling, integrity verification (checksum), encryption, dan optimize network — laju sampai 10x rsync. Pain yang ia buang: migration/transfer data yang reliable & laju tanpa tulis tooling sendiri.

Apa Dia

Automated data transfer service yang handle scheduling, verification, dan network optimization. Boleh transfer data dari NFS, SMB, HDFS, atau S3-compatible storage ke AWS. Juga boleh replicate EFS data ANTARA regions melalui AWS private network.

DataSync vs Storage Gateway vs Snow — 3 cara data masuk AWS (selalu kena exam)

Aspect	DataSync	Storage Gateway	Snow Family
Tujuan	🟢 MIGRATION/transfer (one-time / scheduled)	ONGOING hybrid access on-prem↔AWS	OFFLINE bulk transfer (peti fizikal)
Network	Online (network ada), optimized 10x rsync	Online (cache panas on-prem)	🔴 Offline — internet TAK praktikal
Bila pilih	Pindah 10s–100s TB cepat + verify	On-prem app perlu akses fail AWS berterusan	PB-scale / bandwidth lambat / lokasi terpencil
Verification	🟢 Auto checksum + encryption in-transit	N/A (cache layer)	Encrypt KMS + tamper-resistant
Keyword	"one-time/scheduled migration to S3/EFS/FSx"	"hybrid / low-latency on-prem cache"	"petabyte / weeks online / disconnected"

Ingat: Migration berjadual + network ada → DataSync. Akses hybrid berterusan → Storage Gateway. Offline/PB/bandwidth lambat → Snow. Perangkap: ketiga-tiga "pindah data ke AWS" tapi DataSync=migration online, Storage Gateway=ongoing access, Snow=offline fizikal.

⚡ Quick Sifir — hafal ni

▪DataSync = MIGRATION/transfer (one-time atau scheduled); Storage Gateway = ongoing hybrid access
▪Source: NFS, SMB, HDFS, S3-compatible, object storage → Target: S3, EFS, FSx
▪Auto checksum verification + encryption in-transit (TLS)
▪Boleh EFS → EFS cross-region replication melalui AWS private network (no public internet)
▪Online transfer (network ada); kalau internet terlalu lambat / petabyte → Snow Family instead
▪Incremental: hanya hantar fail yang BERUBAH (delta) → jimat bandwidth = cost-effective untuk recurring/scheduled sync (EFS cross-region pun)

💡 Exam Scenario

"Migrate 50TB dari on-premises NAS ke S3" → DataSync (lebih laju dan auto-verify vs manual). DataSync = MIGRATION task. Storage Gateway = ONGOING hybrid access. Ingat perbezaan ni — exam favourite!

🪤 Perangkap Soalan

Q: Migrate 50TB dari on-prem NAS ke S3, sekali sahaja, dengan auto-verify integrity. Pilih apa?

⚠ Umpan: Storage Gateway File Gateway — boleh letak file ke S3, tapi ia untuk ONGOING access, bukan bulk one-time migration berjadual.

✓ Betul: AWS DataSync — keyword 'one-time bulk migration + verification + faster than rsync' = DataSync.

Q: Replicate EFS data antara dua region secara selamat tanpa lalu public internet. Pilih apa?

⚠ Umpan: Snowball — Snow = physical device untuk migration offline, bukan replication berterusan antara region.

✓ Betul: AWS DataSync — keyword 'EFS cross-region + secure + no public internet' = DataSync (lalu AWS private network).

🧠 Cara Mudah Ingat

→DataSync juga handle EFS → EFS cross-region replication (bukan setakat on-prem ke AWS sahaja)
→EFS cross-region via DataSync: transfer melalui AWS private network (bukan public internet) — secure by default
→Bukan Snowball untuk cross-region EFS (Snowball = physical device, untuk migration, bukan replication)
→Bukan VPN/open-source tools (lebih complex, kena manage sendiri)
→Exam: "replicate EFS data between regions securely without public internet" → AWS DataSync
→PRICING: $0.0125 per GB data dipindah (per-GB copied). Takda free tier. Bayar juga request/storage di target (S3/EFS/FSx) macam biasa. Lawan Snow: DataSync per-GB murah untuk TB-scale online; Snow per-job fee lagi worth bila PB-scale / bandwidth tak cukup.

Guna Bila

One-time or recurring data migration from on-premises to S3, EFS, or FSx; also EFS cross-region replication

data migrationautomated transferS3EFSFSxNFSSMBHDFSone-time migrationscheduled transferStorage GatewayEFS cross-regionprivate networkno public internetincrementalrecurringcost-effectivepricing

📎 What is AWS DataSync?📎 DataSync transfer locations (NFS/SMB/S3/EFS/FSx)

D2 · Resilient

DMS

AWS Database Migration Service

"Pindah database ke AWS tanpa downtime"

🎯 Sebab Apa Wujud

Nak migrate database ke AWS tapi kalau matikan DB untuk copy = business down berjam-jam, dan kalau tukar engine (Oracle ke PostgreSQL) schema + stored procedure tak serasi. DMS wujud supaya source DB KEKAL running masa data dipindah (CDC keep sync sampai cutover) = near-zero downtime; SCT pula convert schema bila engine berbeza. Pain yang ia buang: migration DB tanpa matikan production + handle perbezaan engine.

Apa Dia

DMS replicate data dari source ke target dengan minimal downtime. Source database kekal running semasa migration. Schema Conversion Tool (SCT) untuk convert schema bila beza engine.

DMS sahaja vs DMS + SCT — tengok engine

Rendering diagram…

Engine SAMA → DMS sorang cukup. Engine BEZA → wajib SCT convert schema dulu, baru DMS pindah data. CDC (Change Data Capture) buat source kekal sync dengan target sampai cutover = minimal downtime. INGAT exam: "different/heterogeneous engine" = trigger SCT.

⚡ Quick Sifir — hafal ni

▪DMS = database migration ONLY; source kekal running (minimal downtime)
▪Homogeneous (engine sama, MySQL→RDS MySQL) = DMS sahaja
▪Heterogeneous (engine beza, Oracle→Aurora PostgreSQL) = DMS + SCT (Schema Conversion Tool)
▪CDC (Change Data Capture) = continuous sync source↔target sampai cutover
▪DMS replication instance duduk dalam VPC; boleh on-prem→AWS, AWS→AWS, AWS→on-prem

💡 Exam Scenario

"Migrate Oracle on-prem ke Aurora PostgreSQL" → DMS + SCT (heterogeneous). "Migrate MySQL on-prem ke RDS MySQL" → DMS sahaja (homogeneous). Source kekal up masa migration — near-zero downtime.

🪤 Perangkap Soalan

Q: Migrate Oracle on-prem ke Aurora PostgreSQL dengan minimal downtime. Pilih apa?

⚠ Umpan: DMS sahaja — DMS pindah data, tapi engine beza (Oracle→PostgreSQL) jadi schema + stored procedure kena convert dulu, DMS sorang tak buat tu.

✓ Betul: DMS + SCT — keyword 'different engine / heterogeneous' wajib SCT untuk convert schema, baru DMS pindah data.

Q: Nak migrate keseluruhan server (OS + apps + DB) ke EC2 dengan minimal downtime. Pilih apa?

⚠ Umpan: DMS — ada perkataan 'minimal downtime' yang bait orang, tapi DMS cuma untuk DATABASE, bukan whole server.

✓ Betul: AWS MGN — keyword 'entire server / OS + apps / lift-and-shift ke EC2' = MGN, BUKAN DMS.

🧠 Cara Mudah Ingat

→Homogeneous migration (same engine): DMS sahaja cukup. E.g. MySQL → RDS MySQL, PostgreSQL → Aurora PostgreSQL
→Heterogeneous migration (different engine): DMS + SCT. SCT convert schema/stored procedures first, then DMS migrates data. E.g. Oracle → Aurora PostgreSQL
→CDC (Change Data Capture): continuous replication mode — keeps source and target in sync during cutover. Minimal downtime migration
→DMS replication instance runs in a VPC. Must have connectivity to both source and target databases
→Exam: "migrate database with minimal downtime" → DMS. "migrate entire server (OS + apps)" → MGN. "transfer files to S3" → DataSync
→Supports: on-prem → AWS, AWS → AWS (cross-region), AWS → on-prem. Not just one-way!
→Multi-AZ replication instance available for high availability during migration
→PRICING: bayar replication instance ikut jam (macam EC2, cth dms.t3.medium ~$0.146/hr) + storage + data transfer. DMS Serverless = bayar per DCU-hour (auto-scale). FREE 6 bulan bila migrate KE Aurora / Redshift / DynamoDB / DocumentDB (DMS free tier untuk target ni). SCT = percuma.
→Migrate ke NoSQL/DynamoDB (heterogeneous): DMS + SCT convert schema, guna S3 sebagai STAGING area sebelum load ke DynamoDB — S3 murah & serverless (BUKAN EC2 untuk staging = mahal + overkill). Istilah betul = Schema Conversion Tool (SCT), BUKAN "engine conversion tool". Exam: "legacy DB → DynamoDB, cost-effective" → DMS + SCT + S3 staging (BUKAN simpan staging kat EC2).

Guna Bila

Migrate databases to AWS — homogeneous (MySQL→RDS MySQL) or heterogeneous (Oracle→Aurora)

database migrationminimal downtimehomogeneousheterogeneousSchema Conversion ToolSCTCDCchange data captureDMS Serverlessreplication instanceMulti-AZpricingS3 stagingDynamoDB targetNoSQL migration

📎 What is AWS DMS?📎 AWS DMS Serverless 📎 Schema Conversion Tool (SCT)

D2 · Resilient

Snow Family

AWS Snow Family

"Peti besi AWS untuk data besar-besaran — hantar by post"

🎯 Sebab Apa Wujud

Pindah ratus TB atau petabyte data melalui internet boleh ambil berbulan-bulan dan bandwidth mahal gila — atau lokasi langsung tiada internet (kapal, ladang minyak, kawasan terpencil). Snow Family wujud sebagai peti besi fizikal: AWS hantar device, kau load + encrypt data, pos balik, AWS muat naik ke S3. Pain yang ia buang: transfer data besar bila network TAK praktikal, plus edge compute di tempat disconnected.

Apa Dia

Physical devices: Snowcone (8-14TB, smallest, edge compute), Snowball Edge Storage Optimized (210TB), Snowball Edge Compute Optimized (28TB NVMe, 104 vCPUs). Encrypt data, hantar ke AWS, AWS load ke S3.

Pick a Snow device by data size + compute

Device	Capacity	Pick when
Snowcone	8TB HDD / 14TB SSD	Small, rugged, portable; light edge + transfer
Snowball Edge Storage Optimized	210TB NVMe	Large-scale data migration (default Snowball answer)
Snowball Edge Compute Optimized	28TB · 104 vCPUs · 416GB RAM	Edge ML inference / video processing

Ingat: Pilih ikut data size + compute need. >1 week via internet → go Snow. Online migration to S3/EFS (network available) → DataSync, bukan Snow.

⚡ Quick Sifir — hafal ni

▪Snowcone = 8TB HDD / 14TB SSD, paling kecik (4.5 lbs), edge + transfer
▪Snowball Edge Storage Optimized = 210TB NVMe (default jawapan 'Snowball')
▪Snowball Edge Compute Optimized = 28TB, 104 vCPU, 416GB RAM (edge ML/video)
▪Rule of thumb: transfer ambil >1 minggu via internet → guna Snow
▪Semua encrypted KMS 256-bit + tamper-resistant; online transfer (network ada) → DataSync, BUKAN Snow

💡 Exam Scenario

"Transfer 100TB data tapi internet ambil berbulan-bulan atau bandwidth mahal" → Snow Family. Rule of thumb: >1 week via internet → consider Snowball. Petabyte-scale → order multiple Snowball Edge devices.

🪤 Perangkap Soalan

Q: Nak transfer 80TB ke S3 tapi internet link company lambat + ambil berbulan kalau upload online. Pilih apa?

⚠ Umpan: AWS DataSync — DataSync laju untuk online transfer, tapi kalau network sendiri yang jadi bottleneck, online tetap berbulan.

✓ Betul: Snowball Edge — keyword 'limited bandwidth / would take weeks-months online / petabyte-scale offline' = Snow Family.

Q: Perlu run ML inference di lokasi terpencil tiada internet, lepas tu hantar data balik ke AWS. Pilih apa?

⚠ Umpan: Snowball Edge Storage Optimized — banyak storage, tapi inference perlu compute (vCPU/RAM), Storage Optimized kurang power.

✓ Betul: Snowball Edge Compute Optimized — keyword 'edge ML inference / heavy compute disconnected' = Compute Optimized (104 vCPU).

🧠 Cara Mudah Ingat

→Snowcone: 8TB HDD or 14TB SSD. Smallest, lightest (4.5 lbs). Edge computing + data transfer. Battery-powered option. Use DataSync agent to send data online
→Snowball Edge Storage Optimized: 210TB NVMe. For large-scale data migration. Supports S3-compatible storage, NFS, EC2 compute
→Snowball Edge Compute Optimized: 28TB NVMe, 104 vCPUs, 416GB RAM. For ML inference, video processing at edge. Supports EC2 + EKS Anywhere
→All Snow devices: data encrypted with KMS keys (256-bit). Tamper-resistant enclosure. AWS wipes device after import
→Exam: "transfer petabytes offline" → Snowball Edge. "edge computing in disconnected location" → Snow Family. "online migration to S3/EFS" → DataSync (not Snow)
→Snowmobile: 100PB per truck. For exabyte-scale. Must be requested specially — rarely tested on SAA exam
→OpsHub: GUI application to manage Snow devices locally — configure, transfer data, launch EC2 instances
→PRICING: per-JOB service fee + per-day usage selepas hari free + shipping. Snowball Edge ~ service fee per job (beberapa hari guna included), lebih hari = caj harian; Snowcone lebih murah per job. Takda kos per-GB macam DataSync. Cost discriminator: PB-scale / bandwidth lambat → Snow per-job lagi worth; TB-scale online → DataSync per-GB lagi murah.

Guna Bila

Petabyte-scale data transfer bila internet terlalu lambat/mahal, atau edge computing

SnowconeSnowball EdgeSnowmobilephysical transferpetabyteedge computingoffline migrationOpsHubcompute optimizedstorage optimized210TBpricing

📎 AWS Snow Family 📎 Snowball Edge device options

🚚Migration & Transfer↑ Top

D2 · Resilient

Transfer Family

AWS Transfer Family

"SFTP/FTP managed server — files terus masuk S3 atau EFS"

🎯 Sebab Apa Wujud

Ramai partner/customer masih hantar file guna protokol lama SFTP/FTPS/FTP/AS2, dan workflow mereka tak boleh tukar ke S3 API. Kalau host SFTP server sendiri atas EC2 = kena patch, scale, jaga HA, urus keys. Transfer Family wujud sebagai SFTP/FTPS/FTP/AS2 endpoint fully managed yang terus simpan file dalam S3/EFS. Pain yang ia buang: bagi partner guna protokol lama TANPA tukar workflow + tanpa kau manage server FTP.

Apa Dia

Fully managed SFTP, FTPS, FTP, dan AS2 endpoints. Files yang di-upload terus land dalam S3 atau EFS. Partner companies boleh hantar files guna protokol lama tanpa kena tukar workflow mereka.

⚡ Quick Sifir — hafal ni

▪Transfer Family = managed SFTP / FTPS / FTP / AS2 endpoint
▪Backend = S3 atau EFS (file jadi object S3 / file EFS biasa)
▪FTP plain = dalam VPC sahaja; AS2 = B2B EDI exchange
▪Identity: service-managed, Active Directory, atau custom Lambda auth
▪Partner pakai protokol lama, NO code change — vs DataSync (migration) / Storage Gateway (hybrid access)

💡 Exam Scenario

"Partner hantar files guna SFTP protocol, nak store dalam S3" → Transfer Family. Fully managed SFTP endpoint — tak perlu setup EC2 SFTP server sendiri.

🪤 Perangkap Soalan

Q: Partner luar hantar file harian guna SFTP, company nak file terus masuk S3 tanpa manage server. Pilih apa?

⚠ Umpan: Launch EC2 + install OpenSSH SFTP server — boleh, tapi kena patch, scale, jaga HA sendiri = banyak ops overhead.

✓ Betul: AWS Transfer Family — keyword 'managed SFTP / partner file exchange / land in S3 / no code change' = Transfer Family.

Q: Nak terima file dari partner via SFTP secara ONGOING. DataSync ke?

⚠ Umpan: AWS DataSync — DataSync ada kaitan 'transfer file', tapi ia untuk migration berjadual ke AWS, bukan endpoint SFTP untuk partner upload.

✓ Betul: AWS Transfer Family — keyword 'SFTP/FTP endpoint untuk users/partners' = Transfer Family, BUKAN DataSync.

🧠 Cara Mudah Ingat

→Protocols supported: SFTP (SSH), FTPS (TLS), FTP (plain, dalam VPC je), AS2 (B2B EDI)
→Backend storage: S3 atau EFS. Files appear as normal S3 objects atau EFS files
→Exam keyword: "SFTP", "FTP", "legacy file transfer", "partner file exchange", "no code change" → Transfer Family
→Bukan DataSync (DataSync = automated scheduled migration. Transfer Family = ongoing SFTP endpoint for users/partners)
→Bukan Storage Gateway (Storage Gateway = hybrid storage access. Transfer Family = file transfer protocol endpoint)
→Identity providers: Service managed, Active Directory, custom Lambda-based
→PRICING: ~$0.30 per jam per protokol yang di-enable pada endpoint (SFTP/FTPS/FTP/AS2 dikira berasingan) + ~$0.04 per GB upload/download. Takda free tier. Cost note: endpoint sentiasa "on" (bayar per jam walaupun takda transfer) — vs DataSync yang per-GB sahaja. Banyak protokol enable = berganda kos jam.

Guna Bila

Legacy FTP/SFTP/FTPS/AS2 file transfers stored directly into S3 or EFS — no code changes needed

SFTPFTPFTPSAS2S3 backendEFS backendmanaged FTPlegacy protocolB2B file transferActive Directoryno code changepricing

📎 What is AWS Transfer Family?📎 Transfer Family identity providers

D2 · Resilient

AWS MGN

AWS Application Migration Service (MGN)

"Lift-and-shift server migration ke EC2 — continuous replication, minimal downtime"

🎯 Sebab Apa Wujud

Nak 'lift-and-shift' keseluruhan server (OS + apps + data) ke AWS tapi kalau snapshot manual + rebuild = downtime panjang dan senang tertinggal config. MGN wujud buat continuous block-level replication dari source server ke AWS di latar belakang — bila ready, satu klik cutover launch EC2 dari replika terkini = minimal downtime. Pain yang ia buang: migrate whole server ke EC2 tanpa rebuild manual & tanpa downtime panjang (gantikan CloudEndure).

Apa Dia

MGN melakukan continuous block-level replication dari source server ke AWS. Bila ready cutover, MGN launch EC2 instance dari replikasi latest. Minimal downtime. Gantikan CloudEndure Migration.

MASTER decision tree — pilih migration/transfer tool mana?

Rendering diagram…

Cabang utama: SERVER → MGN, DATABASE → DMS (+SCT kalau engine beza), FILE → DataSync (online) / Snow (offline) / Storage Gateway (ongoing hybrid), SFTP partner → Transfer Family. Fasa plan: ADS = discover, Migration Hub = track. INGAT exam: baca KATA KUNCI objek yang dipindah dulu, baru pilih tool.

MGN vs DMS vs DataSync — what are you moving?

Aspect	MGN	DMS	DataSync
Moves	Whole server (OS + apps + data)	Databases	Files / objects
Target	EC2	RDS, Aurora, EC2 DB, on-prem	S3, EFS, FSx
How	Continuous block-level replication	Replication + CDC (live sync)	Scheduled transfer + verification
Engine change	N/A (same server)	🟢 Heterogeneous via SCT (Oracle→Aurora)	N/A
Keyword	"lift-and-shift server to EC2"	"migrate database, minimal downtime"	"transfer NAS/NFS files to S3"

Ingat: Server (OS+apps) → MGN. Database → DMS (+SCT kalau tukar engine). Files to S3/EFS/FSx → DataSync. Application Discovery Service = planning sahaja, bukan migrate.

Application Discovery Service — Agentless vs Agent-based (fasa PLANNING, sebelum migrate)

Aspect	Agentless	Agent-based
Cara pasang	OVA appliance kat VMware vCenter (satu je, tak per-server)	Install AWS Discovery Agent dalam setiap OS (Windows/Linux)
Nampak apa	Config asas: server, CPU, RAM, disk, OS	🟢 + network connections (inbound/outbound) → dependency mapping
Bila guna	Environment VMware je, nak ringan & cepat	Perlu map dependency antara server (proses ↔ port)
Keyword	"VMware vCenter, no agent install"	"map network dependencies between servers/processes"

Ingat: ADS = DISCOVER + inventory on-prem sebelum migrate (BUKAN migrate sendiri). Agentless = VMware vCenter, config asas. Agent-based = install agent, nampak network dependency. Hasil → AWS Migration Hub (dependency map + application groups). INGAT exam: "map dependencies between servers" → Agent-based; "what does ADS do" → discover + inventory + dependencies + resource utilization (BUKAN deploy/monitor/security-scan).

⚡ Quick Sifir — hafal ni

▪MGN = whole SERVER (OS + apps + data) → EC2; lift-and-shift / rehost
▪Continuous block-level replication + one-click cutover = minimal downtime
▪Source: physical, VMware, Hyper-V, cloud instance → target EC2
▪MGN = server; DMS = database; DataSync = file/object
▪Application Discovery Service = PLANNING/discovery je, BUKAN migrate

🪤 Perangkap Soalan

Q: Migrate 100 on-prem servers (OS + applications) ke EC2 dengan minimal downtime, lift-and-shift. Pilih apa?

⚠ Umpan: AWS DMS — 'minimal downtime' ada, tapi DMS cuma DATABASE; server penuh OS+apps bukan kerja DMS.

✓ Betul: AWS MGN — keyword 'entire server / rehost / lift-and-shift ke EC2' = MGN (continuous block replication).

Q: Sebelum migrate, team nak discover & map dependency aplikasi on-prem dulu. Guna apa?

⚠ Umpan: AWS MGN — MGN handle migration, tapi tak buat discovery/dependency mapping fasa perancangan.

✓ Betul: Application Discovery Service — keyword 'discover / inventory / dependency / planning' = ADS, bukan MGN.

🧠 Cara Mudah Ingat

→MGN = server migration (OS + apps + data). DMS = database migration only. DataSync = file/object data transfer
→Application Discovery Service = discovery/planning phase bukan migration
→Exam: "migrate entire server/application to EC2 with minimal downtime" → AWS MGN
→Supports: physical servers, VMware, Hyper-V, cloud instances → EC2
→PRICING: MGN PERCUMA untuk migrate — 90 hari free per source server (continuous replication). Kau bayar HANYA resource AWS yang MGN guna (staging EBS, replication EC2, dan EC2 sebenar selepas cutover). Lepas 90 hari/server ada caj kecil per-server kalau masih replicate. Lawan: rebuild manual = jauh lebih mahal masa + risiko.

Guna Bila

Migrate servers (physical/virtual/cloud) to AWS EC2 with minimal downtime

MGNApplication Migration Servicelift-and-shiftrehostserver migrationEC2 migrationblock replicationCloudEndureApplication Discovery Serviceminimal downtimepricing

📎 What is Application Migration Service (MGN)?📎 MGN vs other AWS migration tools

D2 · Resilient

Migration Hub

AWS Migration Hub

"Dashboard pusat untuk track semua migration activities"

🎯 Sebab Apa Wujud

Bila kau migrate guna banyak tool sekali gus — MGN untuk server, DMS untuk DB, DataSync untuk file — status berselerak, susah nak tahu projek dah berapa peratus siap. Migration Hub wujud sebagai 'single pane of glass' yang kumpul status dari semua tool tu ke satu dashboard, group resource ikut application. Pain yang ia buang: visibility progress migration merentas banyak tool tanpa cek satu-satu console.

Apa Dia

Migration Hub aggregates migration status dari pelbagai tools (DMS, MGN, DataSync) ke satu dashboard. Kau boleh group resources into applications dan track progress setiap migration. Requires setting a home region.

⚡ Quick Sifir — hafal ni

▪Migration Hub = TRACK/visibility sahaja, ia TAK migrate apa-apa
▪Aggregate status dari MGN + DMS + DataSync ke satu dashboard
▪Wajib pilih HOME REGION untuk simpan data tracking (migration boleh target region lain)
▪Strategy Recommendations = nasihat rehost/replatform/refactor
▪Group resources jadi 'application' untuk track progress per-app

💡 Exam Scenario

"Migrating 50 servers using MGN + 10 databases using DMS — nak track semua dari satu tempat" → Migration Hub. Track progress, view status, group by application.

🪤 Perangkap Soalan

Q: Tengah migrate 50 server (MGN) + 10 database (DMS), nak track semua progress dari SATU tempat. Pilih apa?

⚠ Umpan: Buka console MGN dan DMS berasingan untuk tengok status — boleh tapi berselerak, bukan single view.

✓ Betul: AWS Migration Hub — keyword 'single dashboard / track migrations across tools' = Migration Hub.

Q: Pasukan kata 'guna Migration Hub untuk migrate server ke EC2'. Betul ke?

⚠ Umpan: Ya — nama 'Migration Hub' bunyi macam ia yang buat migration, ini perangkap utama.

✓ Betul: TIDAK — Migration Hub cuma TRACK; yang migrate server = MGN, migrate DB = DMS. Hub = dashboard sahaja.

🧠 Cara Mudah Ingat

→Migration Hub does NOT perform migration — it TRACKS migrations done by other tools (DMS, MGN, etc.)
→Home region: must select one region to store all migration tracking data. Migration itself can target any region
→Strategy Recommendations: helps plan which apps to rehost, replatform, or refactor
→Migration Hub Orchestrator: automate migration workflows with predefined templates
→Refactor Spaces: starting point for incremental refactoring to microservices
→Exam: "single dashboard to track migrations across tools" → Migration Hub. "actually migrate servers" → MGN. "migrate databases" → DMS
→PRICING: Migration Hub sendiri PERCUMA (dashboard + tracking + Strategy Recommendations). Kau bayar hanya tool migrasi yang sebenar (MGN, DMS, DataSync) + resource AWS. Takda caj untuk track.

Guna Bila

Single pane of glass to track application migrations across multiple AWS tools

migration trackingsingle pane of glassdashboardhome regionstrategy recommendationsorchestratorrefactor spacespricing

📎 What is AWS Migration Hub?📎 Migration Hub Strategy Recommendations

D2 · Resilient

AWS Outposts

"AWS datang ke rumah kau — rack AWS dalam data center sendiri"

🎯 Sebab Apa Wujud

Sesetengah workload TAK boleh pergi cloud — data mesti duduk on-prem atas sebab regulatory/data residency, atau perlu single-digit millisecond latency ke sistem factory/trading/hospital on-prem. Outposts wujud sebagai rack/server hardware AWS sebenar yang AWS hantar & pasang dalam data center kau, run EC2/RDS/EKS/S3 guna API AWS yang SAMA — data tak keluar premise. Pain yang ia buang: kau dapat pengalaman + API AWS (consistent hybrid) sambil data & compute kekal fizikal on-prem, TANPA perlu migrate apa-apa ke cloud.

Apa Dia

AWS Outposts adalah hardware AWS sebenar (rack 42U penuh, atau server 1U/2U) yang AWS hantar & pasang dalam data center kau. Kau boleh run EC2, EBS, RDS, ECS, EKS, S3 on Outposts — semua guna AWS API, console, dan tools yang SAMA macam cloud. Data & compute kekal fizikal dalam premise kau; cuma control plane (management) sambung balik ke parent AWS Region.

Anatomy Outposts — komponen wajib ingat

Outposts hardware → rack 42U atau server 1U/2U yang AWS hantar & pasang dalam data center kau (AWS yang maintain).

Supported services on Outposts → EC2, EBS, S3 on Outposts, ECS, EKS, RDS, EMR, ElastiCache — run LOCAL, data kekal on-prem.

Service Link → sambungan (VPN over internet / Direct Connect) balik ke parent AWS Region untuk control plane (management, monitoring).

Local Gateway (LGW) → untuk racks: pintu trafik antara Outposts dan rangkaian on-prem kau (low-latency, CoIP).

Local Network Interface (LNI) → untuk servers: sambung terus ke LAN on-prem.

Parent Region → Region AWS yang Outposts "tergantung" — kalau Service Link putus, instance terus jalan tapi tak boleh urus dari console.

Outposts — on-prem compute, control plane ke Region

App / sistem on-prem

factory · hospital · DB compliance

AWS Outposts (on-prem)

EC2 · RDS · EBS · S3 · EKS — API AWS sama

Local Gateway / LNI

trafik low-latency ke LAN on-prem

Service Link

control plane → parent Region

Parent AWS Region

management, monitoring, broad services

Data + compute kekal on-prem (Local Gateway/LNI). Cuma management plane lalu Service Link ke parent Region. Service Link putus → instance JALAN lagi, cuma tak boleh urus dari console. INGAT exam: "data cannot leave premises + need AWS API locally" = Outposts.

Pilih hybrid/edge service (decision tree)

Rendering diagram…

Analogi: Outposts = pasang "cawangan AWS mini" dalam rumah kau sendiri (sebab barang tak boleh keluar rumah). Local Zones = AWS buka kedai dekat taman perumahan kau (dia punya kedai, kau singgah je). Wavelength = kiosk AWS dalam tower 5G. Storage Gateway = peti simpanan yang auto-sync ke gudang pusat. DataSync/Snow = lori pindah barang (online vs offline). INGAT exam: "cannot migrate + data residency + run AWS locally" = Outposts; "low latency to users + no hardware" = Local Zones.

Outposts vs hybrid/edge confusables (jangan keliru!)

Service	Apa dia	Siapa punya hardware	Guna bila (keyword exam)
AWS Outposts	Rack/server AWS DALAM data center kau, run AWS services local	Kau punya premise, AWS punya + maintain hardware	"data must stay on-prem / cannot migrate + run AWS locally + low latency to on-prem systems"
AWS Local Zones	Infra AWS dalam metro besar, dekat end-user	AWS (kau tak perlu hardware)	"low latency to end-users in a city, no on-prem hardware"
AWS Wavelength	Compute dalam rangkaian 5G telco (edge)	AWS + telco	"ultra-low latency to mobile / 5G users"
Storage Gateway	Appliance on-prem = bridge STORAGE ke cloud (file/volume/tape)	Kau (VM/appliance)	"hybrid storage / cache on-prem, backup ke S3" — bukan run compute
DataSync	Online transfer data on-prem ↔ AWS (NFS/SMB/S3)	—	"migrate / sync / move data online ke AWS"
Snow Family	Offline transfer (truk fizikal) + edge compute	AWS (pinjam device)	"transfer petabytes, network slow / no bandwidth, one-time migration"

Ingat: Soalan kata RUN AWS services / database / compute on-prem tanpa migrate → Outposts. Low latency ke END-USER tanpa hardware sendiri → Local Zones (5G → Wavelength). Cuma STORAGE bridge → Storage Gateway. PINDAH data → DataSync (online) / Snow (offline). Kalau soalan kata "without migrating" tapi pilihan ada Snowball/DataSync — itu umpan, sebab dua-dua tu MIGRATE.

⚡ Quick Sifir — hafal ni

▪Outposts = rack/server hardware AWS DALAM data center kau (on-prem), API AWS sama
▪2 form factor: rack 42U (penuh) · server 1U/2U (kecik, single server)
▪Run EC2, EBS, RDS, ECS, EKS, S3 on Outposts — data kekal on-prem
▪Use case: data residency/compliance, ultra-low latency ke sistem on-prem, local processing, consistent hybrid
▪Service Link = control plane balik ke parent Region; Local Gateway (LGW) = trafik on-prem (racks)
▪Outposts ≠ data transfer (itu DataSync/Snow) ; ≠ hybrid storage je (itu Storage Gateway) ; ≠ AWS-owned metro infra (itu Local Zones)

💡 Exam Scenario

"Database must stay on-premises (regulatory/compliance), cannot migrate, but extend AWS services + low latency + consistent hybrid" → AWS Outposts (BUKAN Storage Gateway/DataSync/Snowball). "Single-digit ms latency to on-prem factory/trading systems + AWS ecosystem" → Outposts. "Low latency to end-users in a metro, no on-prem hardware" → Local Zones. "Ultra-low latency to 5G mobile users" → Wavelength. "Hybrid storage / backup on-prem to S3" → Storage Gateway. "Move/sync data online to AWS" → DataSync. "Transfer petabytes offline, slow network" → Snow Family.

🪤 Perangkap Soalan

Q: Regulasi kata database mesti kekal on-premises (tak boleh migrate), tapi team nak extend AWS services + API yang sama, low latency, consistent hybrid. Pilih apa?

⚠ Umpan: AWS Storage Gateway — ia hybrid, tapi cuma untuk STORAGE bridge ke cloud, tak boleh run compute/RDS penuh on-prem.

✓ Betul: AWS Outposts — keyword 'database must stay on-prem / cannot migrate + run AWS services locally + hybrid' = Outposts.

Q: Factory perlu compute latency single-digit ms ke peralatan on-prem, tapi nak ekosistem AWS. Pilih apa?

⚠ Umpan: Run kat AWS region terdekat — latency tetap ada hop ke cloud, tak cukup laju untuk control loop factory.

✓ Betul: AWS Outposts — keyword 'low latency to on-prem systems + local processing' = Outposts (compute duduk on-prem).

Q: Game studio nak latency rendah ke pengguna bandar besar, TAPI tak nak beli/urus hardware sendiri. Pilih apa?

⚠ Umpan: AWS Outposts — nampak 'low latency' terus pilih. SALAH: Outposts kau yang kena ada premise + hardware on-prem.

✓ Betul: AWS Local Zones — AWS yang punya infra, letak dekat metro besar untuk latency rendah, kau tak perlu hardware sendiri. (Wavelength = latency rendah dalam rangkaian 5G telco.) Keyword: 'low latency to end-users, no on-prem hardware' = Local Zones.

🧠 Cara Mudah Ingat

→Outposts = AWS infrastructure ON-PREMISES (hardware sebenar) — bukan data transfer service, bukan storage bridge.
→2 form factor: Outposts rack (42U penuh, banyak capacity) dan Outposts server (1U/2U, single server untuk ruang kecik / cawangan).
→Use case: regulatory compliance (data must stay on-prem), low-latency access to on-prem systems, local data processing, consistent hybrid (API sama).
→Bukan DataSync (data transfer online), bukan Storage Gateway (hybrid STORAGE only), bukan Snow Family (one-time offline migration), bukan Local Zones (AWS-owned metro infra, tiada hardware kau).
→Service Link = sambungan control plane balik ke parent Region (VPN over internet atau Direct Connect). Kalau putus, instance on-prem TERUS jalan, cuma tak boleh urus dari console/API.
→Local Gateway (LGW) untuk racks = pintu trafik low-latency antara Outposts & rangkaian on-prem. Local Network Interface (LNI) untuk servers.
→Exam keyword: "database/data must stay on-premises due to compliance + extend AWS services to on-prem + cannot migrate" → AWS Outposts.
→PRICING: Outposts TIADA free tier. Capacity-based — kau order konfigurasi (compute + storage) dengan komitmen term (biasa 3 tahun), bayar All / Partial / No Upfront. Harga dah termasuk hardware, penghantaran, install & maintenance oleh AWS. Outposts server = entry cost jauh lebih murah dari rack. Compute/EBS atas Outposts tak dicaj per-jam berasingan (dah termasuk dalam langganan Outposts); S3 on Outposts dicaj per-GB capacity yang kau provision.

Guna Bila

Run AWS services on-premises for compliance, low latency, or data residency requirements

OutpostsOutposts rackOutposts serveron-premises AWSdata residencycompliancecannot migratelocal processinglow latencyconsistent hybridService LinkLocal GatewayLGWLocal Network InterfaceLNIparent RegionLocal ZonesWavelengthStorage GatewayDataSyncSnow Familyhybridpricing

📎 What is AWS Outposts?📎 How AWS Outposts works (Service Link, Local Gateway, LNI)📎 AWS Outposts pricing