AWS SAA-C03 Study

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

💾Storage↑ Top

D3 · High-Performing

EBS

Elastic Block Store

"Hard disk untuk EC2"

🎯 Sebab Apa Wujud

EBS wujud sebab EC2 perlukan disk yang PERSISTENT — data mesti kekal walaupun instance stop/start atau pindah host. Instance Store (disk fizikal host) ephemeral & hilang bila stop, jadi tak boleh untuk OS drive / database. EBS = network-attached block storage yang persistent, boleh snapshot ke S3, boleh resize tanpa downtime (Elastic Volumes), dan boleh encrypt — supaya data EC2 selamat & kekal.

Apa Dia

Menyediakan block-level storage yang boleh di-attach kepada EC2 instance

Contoh Guna

OS drive untuk EC2, database storage

EBS — pecahan component (anatomy)

Volume → "hard disk" maya, attach ke 1 EC2 (network-attached). Hidup dalam SATU AZ je

Snapshot → backup volume ke S3 (incremental). Boleh copy cross-region/cross-account untuk DR

DeleteOnTermination → flag: root volume default TRUE (hilang bila terminate), extra volume default FALSE (kekal)

Multi-Attach → io1/io2 SAHAJA boleh attach ke banyak EC2 dalam AZ sama (cluster-aware FS je)

Encryption (KMS) → at rest + in transit + snapshot + semua volume dari snapshot tu, auto

EBS-Optimized → throughput EBS dedicated, tak rebut bandwidth dengan network instance

EBS vs Instance Store — pilih yang mana

Rendering diagram…

INGAT exam: soalan sebut "persistent / survive failure / boleh snapshot" = EBS. "temporary / scratch / fastest local" = Instance Store.

EBS vs Instance Store — persistent ke ephemeral?

Ciri	EBS	Instance Store
Persistent?	✅ Kekal lepas stop/start	❌ HILANG bila stop/terminate (ephemeral)
Lokasi disk	Network-attached (luar host)	Fizikal pada host EC2
Bila boleh tambah	Bila-bila masa (attach/detach)	HANYA masa launch
Snapshot ke S3	✅ Boleh	❌ Tak boleh
Resize tanpa downtime	✅ Elastic Volumes	❌ Tak boleh
Guna untuk	OS drive, database, data penting	cache, buffer, scratch, temp data

Ingat: Keyword "survive stop / persistent / boleh backup" → EBS. Keyword "temporary / cache / highest IOPS sebab local" → Instance Store. DB & data penting SELALU EBS.

⚡ Quick Sifir — hafal ni

▪EBS = persistent block storage, attach ke 1 EC2 (kecuali Multi-Attach io1/io2)
▪Persistent: data KEKAL lepas stop/start (lawan Instance Store ephemeral)
▪Elastic Volumes = resize/retype/adjust IOPS TANPA detach atau downtime
▪Encryption = at rest + in transit (volume <-> instance), guna KMS
▪Unencrypted snapshot -> encrypted volume = BOLEH (pilih encrypt masa create)
▪PRICING: sc1 paling murah $0.015/GB-mo; gp3 $0.08; io2 $0.125 + $0.065/IOPS; snapshot $0.05/GB-mo

🪤 Perangkap Soalan

Q: EBS volume hampir penuh, perlu tambah saiz dengan perubahan config paling minimum & tiada downtime. Cara terbaik?

⚠ Umpan: Buat snapshot, create volume baru lebih besar dari snapshot, detach lama attach baru — nampak macam cara standard.

✓ Betul: Elastic Volumes — increase saiz EBS terus (online, no detach), lepas tu extend filesystem (growpart + resize2fs). Keyword 'minimal config change + no downtime'. Snapshot+new volume = extra steps & downtime.

Q: Database storage perlu survive instance failure/stop. Instance Store atau EBS?

⚠ Umpan: Instance Store — sebab IOPS tinggi nampak bagus untuk DB.

✓ Betul: EBS — keyword 'survive stop/failure (persistent)'. Instance Store ephemeral; EBS persistent + boleh snapshot.

🧠 Cara Mudah Ingat

→Instance store vs EBS: Instance store = ephemeral (data HILANG bila stop/terminate). EBS = persistent (data kekal)
→Instance store volumes BOLEH ditentukan HANYA masa launch — tak boleh tambah lepas instance running
→EBS encryption: encrypts at rest AND in transit (between volume and instance). ALL current AND previous gen instance types supported.
→EBS Elastic Volumes: resize, retype, adjust IOPS/throughput TANPA detach atau downtime. Lepas resize, extend filesystem: growpart + resize2fs (Linux)
→"Volume running out of space, minimal config changes" → increase EBS volume size (Elastic Volumes). Bukan snapshot+new volume (extra steps).
→Unencrypted snapshot → encrypted volume: BOLEH. Pilih encrypt semasa create volume dari snapshot. Tak perlu enable account-level default encryption.
→PRICING (us-east-1): gp3 = $0.08/GB-mo (base, includes 3K IOPS + 125 MB/s). io2 = $0.125/GB-mo + $0.065/provisioned-IOPS-mo. st1 = $0.045/GB-mo. sc1 = $0.015/GB-mo. Snapshots = $0.05/GB-mo (incremental, stored in S3). Data transfer IN = free. Cross-region snapshot copy = standard data transfer rates.
→Exam: "cheapest EBS type" → sc1 ($0.015/GB). "default boot volume" → gp3. "mission-critical DB" → io2. "sequential log processing" → st1.

Guna Bila

Block storage, attach ke 1 EC2

block storagesingle EC2persistent diskinstance storeephemeralElastic Volumesresizeencryptiondata in transitpricinggp3 costio2 costst1 costsc1 costsnapshot cost

📎 Amazon EBS volumes 📎 Amazon EBS encryption

D3 · High-Performing

EBS Volume Types

Amazon EBS — Volume Types & Multi-Attach

"gp3 = general best. io2 = mission-critical + Multi-Attach. st1 = sequential log. sc1 = cold"

🎯 Sebab Apa Wujud

Banyak jenis EBS wujud sebab workload ada profil I/O berbeza & tak masuk akal guna satu jenis untuk semua (mahal/tak optimum). Cara fikir = 2 soalan je: (1) RANDOM atau SEQUENTIAL access? Random (database, boot, rekod kecil berselerak) → SSD (gp/io) sebab IOPS tinggi. Sequential (log, big data, throughput besar berturutan) → HDD (st1/sc1) sebab jauh lebih murah per GB. (2) Berapa kritikal / berapa murah nak? SSD: biasa → gp3, kritikal/IOPS gila → io2. HDD: kerap → st1, jarang/paling murah → sc1. Empat pilihan utama tu cuma kombinasi 2 soalan ni.

Apa Dia

Pilih "jenis hard disk" EBS ikut corak kerja. Faham SATU benda dulu, lepas tu semua jatuh tempat — IOPS vs throughput: IOPS = berapa BANYAK operasi baca/tulis kecil sesaat (untuk data berselerak / RANDOM, macam database baca rekod sana-sini). Throughput = berapa BANYAK DATA (MB/s) mengalir sesaat (untuk data besar berturutan / SEQUENTIAL, macam log/video/backup). Ada 6 jenis aktif: 4 SSD (gp3, gp2, io2, io1) untuk IOPS/random, 2 HDD (st1, sc1) untuk throughput/sequential — plus 1 legacy Magnetic (standard) yang dah usang.

EBS Types

gp3 → General Purpose SSD (default). Baseline 3,000 IOPS + 125 MB/s INCLUDED free; boleh provision IOPS & throughput BERASINGAN dari saiz (up to 16,000 IOPS / 1,000 MB/s — exam classic; docs terkini list ceiling lebih tinggi pada Nitro). Boot volume ✓

gp2 → Older General Purpose SSD. IOPS terikat saiz (3 IOPS/GB, burst 3,000). Less predictable; migrate ke gp3 (gp3 ~20% murah)

io2 / io2 Block Express → Provisioned IOPS SSD, paling power. 99.999% durability. io2 standard ~64,000 IOPS; io2 Block Express sampai 256,000 IOPS / 4,000 MB/s, sub-ms latency. Supports Multi-Attach

io1 → Older Provisioned IOPS SSD. Up to 64,000 IOPS / 1,000 MB/s. Supports Multi-Attach (sama macam io2)

st1 → Throughput-Optimized HDD. Max 500 MB/s · 500 IOPS. Sequential: log, ETL, big data. BUKAN random I/O. TAK boleh boot volume

sc1 → Cold HDD. Max 250 MB/s · 250 IOPS. Kos PALING rendah ($0.015/GB). Infrequent/cold. TAK boleh boot volume

Magnetic (standard) → LEGACY (previous-gen). ~100 IOPS, magnetic platter. Jangan pilih untuk sistem moden — kadang jadi umpan exam

Pilih EBS type — decision tree

Rendering diagram…

Tanya profil I/O dulu. Random I/O → SSD (gp3 default, io2 kritikal + satu-satunya Multi-Attach). Sequential → HDD (st1 kerap-akses, sc1 cold). INGAT exam: "highest IOPS / Multi-Attach" → io2 · "cost-effective default / boot" → gp3 · "big data / log sequential" → st1 · "lowest cost / infrequent" → sc1.

Cara ingat — analogi kenderaan

Rendering diagram…

SSD (gp/io) = perlu laju respon macam database; HDD (st/sc) = perlu simpan banyak/murah macam log & arkib. gp3 sedan (default), io2 kereta lumba (kritikal + Multi-Attach), st1 lori (throughput sequential), sc1 peti sejuk (cold, paling murah).

Konsep IOPS vs Throughput — analogi tol & lori

Rendering diagram…

INGAT exam: IOPS = kira BILANGAN operasi kecil (tol: berapa kereta lalu) → random → SSD. Throughput = kira ISIPADU data (lori: berapa tan barang) → sequential → HDD. Soalan sebut "high IOPS / random / database" → SSD; "high throughput / sequential / log / big data" → HDD.

KONSEP TERAS: IOPS vs Throughput (faham ni dulu)

Aspek	IOPS	Throughput
Ukur apa	Bilangan operasi baca/tulis sesaat	Jumlah DATA (MB/s) mengalir sesaat
Analogi	Berapa kereta lalu tol sesaat	Berapa tan barang lori angkut
Corak akses	RANDOM (rekod kecil berselerak)	SEQUENTIAL (data besar berturutan)
Workload tipikal	Database, boot volume, transaksi	Log processing, big data, video, backup
EBS keluarga	SSD → gp3 / io2	HDD → st1 / sc1

Ingat: Dua soalan je masa exam: (1) RANDOM atau SEQUENTIAL? Random → SSD (gp/io), Sequential → HDD (st1/sc1). (2) Kritikal/IOPS gila → io2; biasa → gp3; throughput murah → st1; cold paling murah → sc1. Keyword "IOPS / random / database / low latency" → SSD; "throughput / sequential / log / big data / cheap" → HDD.

EBS volume types — IOPS vs throughput vs cost

Type	Kategori	Max prestasi	Best untuk	Multi-Attach
gp3	SSD	baseline 3K IOPS+125MB/s free · up to 16K IOPS/1,000MB/s	🟢 Default — boot, most workloads	❌
gp2	SSD	16,000 IOPS (3 IOPS/GB, burst 3K)	Older general purpose	❌
io2 Block Express	SSD	256,000 IOPS · 4,000 MB/s · 99.999% durable	Mission-critical DB (SAP HANA/Oracle), latency sub-ms	🟢 Ya
io1	SSD	64,000 IOPS · 1,000 MB/s	Older provisioned IOPS	🟢 Ya
st1	HDD	500 IOPS · 500 MB/s throughput	Big data, log, ETL (sequential)	❌
sc1	HDD	250 IOPS · 250 MB/s · kos terendah	Cold / infrequent access	❌
Magnetic (standard)	Legacy	~100 IOPS	Previous-gen, jangan guna (umpan exam)	❌

Ingat: SSD (gp/io) = random I/O & IOPS-bound (database, boot volume). HDD (st1/sc1) = sequential throughput / cold storage — BUKAN untuk random I/O. Multi-Attach HANYA io1/io2 (max 16 EC2, sama AZ). HDD TAK boleh boot. Tak pasti? → gp3.

⚡ Quick Sifir — hafal ni

▪KONSEP: IOPS = banyak operasi kecil (RANDOM, database) → SSD; Throughput = data besar berturutan (SEQUENTIAL, log) → HDD
▪gp3 = default SSD; baseline 3,000 IOPS + 125 MB/s FREE; IOPS & throughput configure berasingan (gp2 IOPS terikat saiz)
▪io2 = mission-critical SSD, 99.999% durable; io2 Block Express sampai 256,000 IOPS / 4,000 MB/s; support Multi-Attach
▪io1 = 64,000 IOPS, support Multi-Attach (sama macam io2)
▪st1 = HDD sequential (log/ETL/big data), 500 MB/s, BUKAN random I/O; sc1 = HDD cold, 250 MB/s, paling murah
▪Multi-Attach HANYA io1/io2 (max 16 EC2, SAMA AZ); gp2/gp3/st1/sc1 TAK boleh
▪HDD (st1/sc1) TAK boleh jadi boot volume; SSD + Magnetic legacy boleh
▪Tak pasti = gp3; SSD = random I/O; HDD = sequential/cold

🪤 Perangkap Soalan

Q: EKS perlu shared block storage di-attach serentak ke beberapa EC2 node. Pilih EBS type?

⚠ Umpan: gp3 — sebab default & paling biasa, orang terus pilih gp3.

✓ Betul: Dua lapis: (1) keyword 'shared access by multiple PODS on different nodes' = ReadWriteMany (RWX) = Amazon EFS (EFS CSI Driver) — itu jawapan ideal. (2) TAPI kalau option semua EBS je (takde EFS), pilih io1/io2 sebab HANYA io1/io2 support Multi-Attach (gp3/st1/sc1 tak boleh). 'EKS + shared + different nodes' BUKAN soalan rosak bila option semua EBS — ia uji fakta Multi-Attach = io1/io2. Sifir: EFS ada → EFS; option EBS sahaja → io1/io2 (block RWO, wajib cluster-aware FS).

Q: Workload log processing — sequential write besar, kos rendah. Pilih EBS type?

⚠ Umpan: gp3 atau io2 — sebab 'performance tinggi' nampak betul.

✓ Betul: st1 (Throughput-Optimized HDD) — keyword 'sequential / log / big data'. gp3 & io2 dioptimum untuk RANDOM I/O dan lebih mahal; st1 murah & laju untuk sequential throughput.

Q: Database mission-critical (SAP HANA) perlukan 100,000+ IOPS, latency sub-millisecond konsisten. Pilih EBS type?

⚠ Umpan: gp3 — sebab 'default & boleh provision IOPS sendiri', orang sangka gp3 boleh push setinggi mana pun.

✓ Betul: io2 Block Express — keyword '100,000+ IOPS / sub-ms latency / mission-critical'. gp3 ceiling rendah (classic 16,000 IOPS); io1/io2 standard ~64,000; HANYA io2 Block Express cecah 256,000 IOPS / 4,000 MB/s. Lebih 64,000 IOPS → io2 Block Express.

Q: Nak EBS volume PALING MURAH untuk simpan data jarang akses. Magnetic (standard) atau sc1?

⚠ Umpan: Magnetic (standard) — sebab nama bunyi 'old & basic', orang sangka mesti paling murah.

✓ Betul: sc1 (Cold HDD, $0.015/GB) — keyword 'cheapest current-gen + infrequent'. Magnetic (standard) = LEGACY/previous-gen, ~100 IOPS, AWS tak galak guna; untuk current-gen cold storage jawapan = sc1. Magnetic cuma umpan.

🧠 Cara Mudah Ingat

→KONSEP teras: IOPS = bilangan operasi kecil sesaat (random, database) → SSD. Throughput = isipadu data MB/s (sequential, log) → HDD. Faham ni dulu, semua jenis EBS jatuh tempat.
→gp3 INCLUDE baseline 3,000 IOPS + 125 MB/s FREE — naik IOPS & throughput BERASINGAN dari saiz. gp2 sebaliknya: IOPS terikat saiz (3 IOPS/GB). Sebab tu migrate gp2→gp3 (gp3 ~20% murah, lagi predictable).
→gp3 ceiling: exam classic = 16,000 IOPS / 1,000 MB/s. (AWS docs terkini list ceiling lebih tinggi pada Nitro, tapi yang diuji selalu baseline 3,000 + cap 16,000.) Perlu LEBIH dari tu → io2.
→io2 Block Express = tier paling power: 256,000 IOPS, 4,000 MB/s, 99.999% durability, latency sub-ms. Soalan sebut ">64,000 IOPS / SAP HANA / mission-critical sub-ms" → io2 Block Express, BUKAN gp3.
→Multi-Attach: HANYA io1 dan io2 — attach satu EBS ke multiple EC2 (max 16) dalam SAMA AZ, perlu cluster-aware filesystem. gp2, gp3, st1, sc1 TIDAK support.
→Exam: "shared block storage across multiple EC2 nodes (EKS)" → io1/io2 Multi-Attach. "Truly shared FILE storage / multi-AZ / POSIX" → EFS (bukan EBS).
→st1 vs sc1: dua-dua HDD sequential. st1 (500 MB/s) untuk kerap akses (log/ETL/big data); sc1 (250 MB/s, paling murah $0.015/GB) untuk jarang/cold. HDD TAK boleh jadi boot volume.
→Magnetic (standard) = LEGACY/previous-gen (~100 IOPS). Jangan pilih untuk sistem moden; AWS sendiri tak galak. Kadang jadi umpan "cheapest" — current-gen cheapest sebenarnya sc1.
→PRICING (us-east-1): gp3 $0.08/GB-mo (base, includes 3K IOPS + 125 MB/s) · io2 $0.125/GB-mo + $0.065/provisioned-IOPS-mo (paling mahal) · io1 sama family · st1 $0.045/GB-mo · sc1 $0.015/GB-mo (cheapest current-gen). Exam: "cheapest EBS" → sc1; "mission-critical DB" → io2.
→Pattern: "database + log processing on same EC2" → io2/gp3 for DB (random IOPS), st1 for logs (sequential throughput).

Guna Bila

Choose right EBS type for workload: random I/O vs sequential, IOPS vs throughput, cost vs performance

gp3gp2io2io1io2 Block Expressst1sc1Magneticstandard volumeMulti-AttachProvisioned IOPSthroughput HDDIOPSthroughputrandom I/Osequentialboot volumeEBS typespricingbaseline IOPS

📎 Amazon EBS volume types 📎 Provisioned IOPS SSD (io1/io2) & Block Express 📎 Attach a volume to multiple instances (Multi-Attach)

D3 · High-Performing

EFS

Elastic File System

"Shared drive, ramai boleh access — multi-AZ NFS"

🎯 Sebab Apa Wujud

EFS wujud sebab EBS hanya boleh attach ke satu EC2 (kecuali Multi-Attach io1/io2 dalam satu AZ), jadi bila banyak EC2 across AZ perlu baca/tulis FAIL yang SAMA serentak (web content, CMS, shared config), EBS tak cukup. EFS = managed NFS yang auto-scale, multi-AZ, boleh di-mount oleh ratusan EC2 sekali gus supaya semua kongsi satu file system tanpa duplicate data.

Apa Dia

Managed NFS (Network File System) that scales automatically. Multiple EC2 instances across AZs can mount and read/write the same file system at the same time.

Contoh Guna

Web content serving across 20 EC2 instances, shared config files, content management systems

EFS — pecahan component (anatomy)

File System → "shared drive" NFS sebenar, auto-scale (bayar ikut guna). Span banyak AZ

Mount Target → 1 ENI per AZ (alamat EC2 mount). Setiap AZ kena ada satu; SG-nya MESTI allow inbound TCP 2049

Performance Mode (set masa create) → General Purpose (latency rendah, default) vs Max I/O (latency lebih tinggi, parallel besar)

Throughput Mode (boleh tukar) → Bursting (scale ikut saiz) / Provisioned (set MiB/s tetap) / Elastic (auto, recommended)

Storage Classes → Standard / Standard-IA (multi-AZ) + One Zone / One Zone-IA (1 AZ). Lifecycle auto-pindah ke IA

Encryption → at rest (KMS, masa create je) + in transit (TLS, masa mount: mount -o tls)

Pilih kelas EFS (decision tree) — 2 soalan

Rendering diagram…

Dua soalan je: (1) kerap atau jarang akses → jarang pilih IA. (2) perlu multi-AZ atau 1 AZ cukup → kalau data boleh dijana semula, One Zone. INGAT exam: "low-cost + rarely accessed + single AZ + can be regenerated/re-creatable" = EFS One Zone-IA (kombinasi paling murah). "frequently accessed + highly available / multi-AZ" = EFS Standard. "high-throughput + shared banyak EC2" = EFS sememangnya (file storage), throughput pakai Elastic/Provisioned.

Kelas storage EFS — 2 soalan je: kerap akses? + berapa AZ?

Kelas	Akses	AZ	Harga/GB-mo	Guna bila / keyword exam
Standard	Kerap	Multi-AZ (≥3)	$0.30	Default, data aktif, perlu tahan AZ outage (HA)
Standard-IA	Jarang	Multi-AZ (≥3)	$0.016 (+retrieval)	"infrequent access" TAPI masih perlu redundansi multi-AZ
One Zone	Kerap	1 AZ je	$0.16	Data aktif tapi re-creatable / dev-test — jimat
One Zone-IA	Jarang	1 AZ je	🟢 $0.0133 (+retrieval)	🟢 PALING MURAH — "rarely accessed + single AZ + re-creatable"

Ingat: Cuma 2 soalan: (1) kerap ke jarang akses? jarang → IA. (2) perlu tahan AZ outage, atau 1 AZ cukup sebab data boleh dijana semula? 1 AZ cukup → One Zone. Gabung "jarang + 1 AZ + re-creatable + low-cost" = One Zone-IA (paling murah). "kerap + multi-AZ HA" = Standard. Durability semua kelas tinggi; beza = availability (multi-AZ vs 1 AZ) + retrieval fee (IA).

⚡ Quick Sifir — hafal ni

▪EFS = managed NFS, shared, multi-AZ, ramai EC2 mount serentak
▪4 storage classes: Standard / Standard-IA (multi-AZ ≥3) + One Zone / One Zone-IA (1 AZ je)
▪Performance mode: General Purpose (latency rendah, default) vs Max I/O (latency LEBIH TINGGI, untuk parallel besar)
▪Throughput mode: Bursting (scale ikut saiz) / Provisioned (set MiB/s tetap) / Elastic (auto, recommended)
▪Encryption in transit BUKAN default — enable masa mount: mount -o tls (TLS 1.2)
▪Mount target connection timeout = check SG inbound TCP 2049 + NACL
▪EFS = MOUNT macam folder (network drive pejabat, edit in-place/POSIX); S3 = UPLOAD/DOWNLOAD macam Google Drive — JANGAN keliru
▪PRICING: Standard $0.30 · One Zone $0.16 · Standard-IA $0.016 · One Zone-IA $0.0133/GB-mo (cheapest); EFS lebih mahal dari S3 tapi shared

💡 Exam Scenario

Multi-EC2 shared storage → EFS. Single-instance persistent block storage → EBS. Object storage (images, backups) → S3. PILIH KELAS EFS: "rarely accessed + single AZ + can be regenerated/re-creatable + low-cost" → One Zone-IA (paling murah); "frequently accessed + highly available / multi-AZ" → Standard; "infrequent access TAPI masih perlu multi-AZ redundancy" → Standard-IA; "active data tapi re-creatable / dev-test, nak jimat" → One Zone.

🪤 Perangkap Soalan

Q: 20 EC2 across multiple AZ perlu baca/tulis fail web content yang SAMA serentak. Pilih storage?

⚠ Umpan: EBS Multi-Attach (io2) — sebab 'attach ke banyak EC2' nampak padan.

✓ Betul: EFS — keyword 'shared FILE storage, multi-AZ, ramai EC2 serentak'. EBS Multi-Attach = block storage, max dalam satu AZ & io1/io2 sahaja; EFS = file system NFS multi-AZ sebenar.

Q: EFS kecil (25 GB) tapi perlu throughput tinggi konsisten. Apa setting?

⚠ Umpan: Bursting Throughput — sebab ia default, orang biar je.

✓ Betul: Provisioned (atau Elastic) Throughput — Bursting scale ikut saiz (25 GB = ~1.25 MiB/s baseline je, tak cukup). Keyword 'small file system + high throughput' = Provisioned/Elastic.

Q: EC2 cuba mount EFS tapi connection TIMEOUT. Punca paling mungkin?

⚠ Umpan: Salah DNS name file system — tapi DNS failure bagi error lain, bukan timeout.

✓ Betul: Security Group / NACL block TCP 2049 — keyword 'timeout'. Mount target SG mesti allow inbound TCP 2049 dari CIDR EC2; ini punca timeout, bukan DNS.

Q: Syarikat berita perlu storan backup/redundant: low-cost, high-throughput, dikongsi banyak EC2, JARANG diakses kecuali masa recovery, dalam SATU AZ je, dan boleh dijana semula kalau hilang. Kelas EFS mana?

⚠ Umpan: EFS Standard-IA — nampak 'infrequent access' terus pilih IA. SALAH separa: Standard-IA simpan merentas ≥3 AZ, jadi bayar lebih untuk redundansi yang soalan TAK perlu (data re-creatable + 1 AZ je dah cukup).

✓ Betul: EFS One Zone-IA — keyword 'rarely accessed' (→ IA) + 'single AZ + can be regenerated/re-creatable' (→ One Zone) + 'low-cost' = One Zone-IA, kombinasi PALING MURAH ($0.016/GB · 1 AZ).

Q: App Linux perlu banyak EC2 baca/tulis fail yang SAMA, mount macam folder biasa & edit terus in-place (POSIX). EFS atau S3?

⚠ Umpan: S3 — sebab 'boleh kongsi & ramai akses' nampak macam Google Drive. SALAH: S3 = object, kau UPLOAD/DOWNLOAD guna API, TAK boleh mount & edit in-place macam folder.

✓ Betul: EFS — keyword 'mount / POSIX / edit fail terus / shared file system'. EFS = folder kongsi yang kau MOUNT (macam network drive pejabat); S3 = Google Drive (upload/download je). Dua-dua boleh kongsi, tapi cara guna beza.

🧠 Cara Mudah Ingat

→Performance modes (set at creation): General Purpose = lowest latency, recommended for MOST workloads including web serving. Max I/O = HIGHER latency (not lower!), for massive parallel HPC workloads with 100s of connections.
→Throughput modes (can change): Bursting = scales with storage size (50 KiB/s per GiB baseline — 25 GB file system gets only ~1.25 MiB/s). Provisioned = set specific MiB/s regardless of file system size. Elastic (recommended) = auto-scales, pay per use.
→Trap: "small EFS + high throughput demand" → Provisioned Throughput. "large file system + occasional access" → Bursting is fine.
→Encryption in transit: NOT enabled by default. Enable at MOUNT TIME with EFS mount helper: sudo mount -t efs -o tls fs-xxxx /mnt/efs. Uses TLS 1.2 + AES-256. No console toggle.
→Encryption at rest: can enable at CREATION time only. Uses KMS. Encrypts data + metadata + directory names.
→Cross-VPC access: create NEW mount targets in VPC B (same file system, no data duplication). Alternatively via VPC peering but need to use mount target IP instead of DNS name.
→EFS vs S3 (jangan keliru): EFS = file system kau MOUNT macam folder (POSIX, edit fail terus in-place, banyak EC2 serentak). S3 = object storage, kau UPLOAD/DOWNLOAD guna API (tak boleh edit in-place). Trigger EFS = "mount / POSIX / shared file system / edit like a folder". Trigger S3 = "object / store-retrieve / static / presigned URL".
→Connection timeout to EFS mount target = check: (1) SG inbound TCP 2049 from EC2 CIDR, (2) NACL allows TCP 2049. DNS failure → different error (not timeout).
→EFS backup: use AWS Backup natively. S3 File Gateway ≠ EFS backup.
→Storage classes: Standard (multi-AZ), Standard-IA (infrequent access), One Zone, One Zone-IA (cheapest — data in single AZ).
→PRICING (us-east-1): Standard = $0.30/GB-mo. One Zone = $0.16/GB-mo. Standard-IA = $0.016/GB-mo (+ retrieval fee). One Zone-IA = $0.0133/GB-mo (+ retrieval fee — cheaper than Standard-IA sebab 1 AZ je). Provisioned Throughput = $6.00/provisioned-MB/s-mo. Elastic Throughput = pay per throughput used. IA lifecycle = auto-move to IA for savings.
→Exam: "cheapest EFS class" → One Zone-IA ($0.0133/GB, cheaper than Standard-IA $0.016). "multi-AZ EFS" → Standard ($0.30/GB). "infrequently accessed EFS data" → Standard-IA (multi-AZ) atau One Zone-IA (1 AZ). EFS is MORE expensive than S3 ($0.023/GB) but cheaper than EBS for shared multi-instance.
→EFS Lifecycle Management: auto-pindah ke IA (min 1 hari, max 365 hari selepas last access). TRAP: tak boleh set 730 hari (2 tahun) — kalau soalan "older than 2 years" → S3 Lifecycle, BUKAN EFS.

Guna Bila

Shared file storage for multiple EC2 instances simultaneously

shared storagemultiple EC2NFSGeneral PurposeMax I/OProvisioned ThroughputBursting ThroughputElastic ThroughputTLS 1.2mount helper-o tlsTCP 2049cross-VPC EFSEFS mount targetReadWriteManyRWXReadWriteOnceRWOEFS CSI DriverEKS shared storagepods different nodesKubernetes persistent volumeEFS storage classesOne Zone-IAStandard-IAEFS One Zonerarely accessedsingle AZre-creatableregenerated if lostlow-costcheapest EFSredundant storagehigh-throughputEFS lifecycle365 days maxvs S3 lifecycle 730 days

📎 EFS Performance 📎 EFS Encryption in Transit 📎 EFS Cross-VPC Mounting

D3 · High-Performing

S3

Simple Storage Service

"Infinite bucket — object storage, 11 nines durability"

🎯 Sebab Apa Wujud

S3 wujud sebab simpan fail kat disk EBS/server sendiri ada had saiz, kena urus capacity, kena backup manual, dan susah nak share antara banyak server. S3 buang semua sakit kepala tu — object storage tanpa had, auto-replicate across ≥3 AZ (11 nines durability) jadi kau tak payah risau data hilang, bayar ikut guna je. Inilah sebab S3 jadi 'tulang belakang' hampir semua AWS workload: data lake, backup, static site, log.

Apa Dia

Object storage tanpa had — simpan apa-apa jenis fail sebagai OBJECT dalam BUCKET. Bukan block (EBS) bukan file system (EFS). Tiap object ada key (nama penuh), value (data), metadata, version ID. Bucket nama global unik. Max 1 object = 5TB. 11 nines durability (99.999999999%) sebab tiap object auto-replicate across ≥3 AZ.

Contoh Guna

Store images/video, backup & restore, data lake untuk Athena/Redshift, static website hosting, log storage, distribute software

S3 Anatomy — Bucket → Object

Bucket → bekas top-level, nama GLOBAL unik (semua AWS), terikat pada 1 Region

Object → fail sebenar; identified by Key (full path nama, cth photos/2026/cat.jpg)

Key → "nama penuh" object dalam bucket (prefix + nama). Tiada folder sebenar — prefix je

Value → kandungan data object (max 5TB)

Metadata → key-value tags pasal object (content-type, dll)

Version ID → bila versioning ON, tiap update dapat ID baru

S3 Request → Durability Flow

Client PUT

upload object

S3 Bucket

Region X

AZ-1

copy

AZ-2

copy

AZ-3

copy

11 Nines

99.999999999%

Satu PUT → S3 auto-replicate object across ≥3 AZ dalam Region → 11 nines durability. Ni sebab S3 boleh "kehilangan" 1 object dalam 10,000 tahun untuk 10 juta object.

Pilih Encryption S3 (decision tree)

Rendering diagram…

Default sejak 2023: semua bucket auto SSE-S3. Nak audit siapa decrypt + rotate key → SSE-KMS (tapi kena ingat KMS ada request limit). Compliance pegang key sendiri → SSE-C atau client-side.

Block vs File vs Object — EBS vs EFS vs S3 (foundational!)

Ciri	EBS (Block)	EFS (File)	S3 (Object)
Jenis storage	Block (hard disk)	File (shared folder)	Object (cloud drive)
Sambungan	🔴 1 EC2 je (kecuali io1/io2 Multi-Attach)	🟢 Banyak EC2 serentak (NFS)	Akses guna URL/API dari mana-mana
Skop	1 AZ (kena attach instance sama AZ)	Multi-AZ (regional)	Regional, auto ≥3 AZ
Analogi komputer	SSD dalaman laptop (1 komputer je)	Network drive / folder kongsi pejabat (NAS)	Google Drive / Dropbox
Cara akses	Attach + format, baca/tulis macam disk	🟢 MOUNT macam folder — edit terus in-place (POSIX)	🟢 UPLOAD/DOWNLOAD guna API — tak boleh edit in-place
Exam keyword	"EC2 root volume / boot disk / Provisioned IOPS"	"shared storage / banyak EC2 / POSIX / mount / Linux"	"static website / unstructured / data lake / presigned URL / store-retrieve"

Ingat: Block = satu disk untuk satu server (EBS). File = satu folder dikongsi ramai server serentak (EFS). Object = simpan fail akses guna URL/API tanpa server (S3). JANGAN keliru EFS dengan Google Drive: EFS kau MOUNT macam folder pejabat & edit terus (POSIX); S3 kau UPLOAD/DOWNLOAD macam Google Drive (tak edit in-place). Soalan "banyak EC2 access folder sama serentak / mount / POSIX" → EFS, BUKAN EBS/S3. "root/boot volume satu instance" → EBS. "unstructured / web-accessible / data lake / store-retrieve object" → S3.

S3 Encryption — 4 pilihan

Aspect	SSE-S3	SSE-KMS	SSE-C	Client-Side
Sapa urus key	AWS sepenuhnya	AWS KMS (kau control)	Kau bagi key tiap request	Kau, sebelum upload
Audit trail	❌	🟢 CloudTrail	❌	❌
Key rotation	Auto (AWS)	🟢 Boleh atur	Manual	Manual
Kos / had	Free	KMS request cost + throttle	Free	Free
Best bila	Default, senang	Perlu audit + access control atas key	Wajib pegang key sendiri	AWS tak boleh nampak plaintext langsung

Ingat: Default = SSE-S3 (auto ON sejak 2023). "Audit & control siapa guna key" → SSE-KMS. "App high-throughput tapi kena 503 sebab KMS throttle" → tukar ke SSE-S3 atau guna S3 Bucket Keys untuk kurangkan KMS calls.

Versioning · Replication · Lock — guna bila

Feature	Apa dia	Exam trigger
Versioning	Simpan semua versi object; delete = delete marker, boleh restore	"Protect from accidental delete/overwrite" → enable Versioning
MFA Delete	Perlu MFA untuk delete version / matikan versioning	"Extra protection against deletion"
CRR (Cross-Region)	Auto-copy object ke bucket Region LAIN	"DR / latency / compliance simpan di Region berbeza"
SRR (Same-Region)	Auto-copy dalam Region sama, bucket lain	"Aggregate logs / replicate prod→test sama Region"
Object Lock (WORM)	Write-Once-Read-Many: object tak boleh delete/ubah sampai tarikh	"Compliance, immutable, tak boleh padam" → Object Lock

Ingat: Replication (CRR/SRR) WAJIB versioning ON di SUMBER dan DESTINASI. Replication hanya untuk object BARU selepas enable (guna S3 Batch Replication untuk yang lama).

⚡ Quick Sifir — hafal ni

▪Durability 11 nines (99.999999999%) SEMUA class — beza availability je
▪Max 1 object = 5TB; single PUT max 5GB; >5GB WAJIB Multipart
▪Strong read-after-write consistency (sejak Dec 2020) — soalan 'eventual' = usang
▪3,500 PUT + 5,500 GET per PREFIX per saat; prefix tak terhad → parallelize
▪503 Slow Down = S3 tengah auto-scale, retry with exponential backoff
▪Block Public Access (default ON) menang atas bucket policy/ACL

💡 Exam Scenario

App tetiba dapat banyak HTTP 503 "Slow Down" masa upload laju → bukan kena scale apa-apa, S3 tengah auto-scale; agih objek across MULTIPLE PREFIX (3,500 PUT / 5,500 GET per prefix/saat, prefix tak terhad). Nak hantar fail besar laju merentas benua → S3 Transfer Acceleration (guna edge CloudFront). Fail >100MB → guna Multipart Upload (wajib >5GB).

🪤 Perangkap Soalan

Q: App upload laju dapat banyak HTTP 503 'Slow Down'. Apa fix paling betul?

⚠ Umpan: Tukar storage class atau request limit increase via support — nampak macam kena 'naikkan quota'.

✓ Betul: Agih object across MULTIPLE PREFIX + retry with exponential backoff. S3 auto-scale per prefix (3,500 PUT/5,500 GET tiap prefix), tiada hard limit nak naik. Keyword: 'prefix' + '503 slow down'.

Q: Nak host static website + custom domain + HTTPS guna S3. Cukup ke S3 sahaja?

⚠ Umpan: Enable S3 Static Website Hosting je — nampak macam dah lengkap.

✓ Betul: Letak CloudFront DEPAN S3. S3 static hosting HTTP sahaja; HTTPS + custom domain (ACM cert) kena CloudFront. Keyword: 'HTTPS' + 'custom domain'.

Q: Global users upload files ke EC2 ASG; files >2 years old kena storage class lebih murah, durable & HA. Pilih DUA.

⚠ Umpan: EFS lifecycle ke EFS-IA selepas 2 tahun — nampak 'lifecycle + infrequent' = EFS. SALAH: EFS lifecycle max 365 hari je, tak boleh 730 hari (2 tahun).

✓ Betul: DUA jawapan S3 Lifecycle: (1) transition ke Standard-IA selepas 2 tahun, (2) transition ke Glacier (Flexible) selepas 2 tahun. Object storage scalable untuk upload global; lifecycle age-based. BUKAN EBS/DLM/RAID — block storage, tak scalable multi-instance upload.

🧠 Cara Mudah Ingat

→Durability = 11 nines (99.999999999%) SEMUA storage class (kecuali One Zone — masih 11 nines tapi 1 AZ je, risiko bila AZ musnah). Availability lain-lain: Standard 99.99%, Standard-IA 99.9%, One Zone-IA 99.5%.
→Consistency: STRONG read-after-write untuk semua operation (sejak Dec 2020) — PUT object baru terus boleh GET, tiada "eventual consistency" lagi. Soalan lama cakap eventual = jawapan dah usang.
→Performance: 3,500 PUT/COPY/POST/DELETE + 5,500 GET/HEAD per PREFIX per saat. Prefix tak terhad → parallelize across prefix untuk scale. 503 Slow Down = tengah scale, retry with backoff.
→Saiz: max 1 object = 5TB. Single PUT max 5GB. Multipart Upload: disyorkan >100MB, WAJIB >5GB. Multipart boleh resume + parallel part.
→Encryption default: sejak Jan 2023 semua object baru auto SSE-S3 (AES-256). Nak audit/control key → SSE-KMS (hati2 KMS throttle → guna S3 Bucket Keys).
→Security: Block Public Access (account + bucket level, default ON) > bucket policy/ACL. Bucket policy (resource-based JSON) untuk grant cross-account / public; ACL = legacy, AWS galak matikan. "Bucket tak sengaja public" → hidupkan Block Public Access.
→Static website hosting: S3 boleh host static site (HTML/JS/CSS) tapi HTTP sahaja — nak HTTPS + custom domain → letak CloudFront depan.
→Event notification: S3 boleh trigger SNS / SQS / Lambda / EventBridge bila object dibuat/dipadam (cth auto-process gambar bila upload).
→PRICING (us-east-1): Storage — Standard $0.023/GB-mo, Standard-IA $0.0125/GB-mo, One Zone-IA $0.01/GB-mo, Glacier Instant $0.004/GB-mo, Glacier Flexible $0.0036/GB-mo, Deep Archive $0.00099/GB-mo. Requests — PUT/POST/LIST $0.005/1K, GET $0.0004/1K. Data transfer OUT = free to CloudFront, $0.09/GB to internet (first 100GB free/mo). Intelligent-Tiering monitoring fee = $0.0025/GB-mo (free for objects <128KB).
→Exam: "cheapest S3 storage" → Deep Archive ($0.00099/GB). "default S3 class" → Standard ($0.023/GB). "S3 data transfer to CloudFront" → free.

Guna Bila

Object storage: images, video, backup, data lake, static website

object storage11 nines durabilitystrong consistencybucket policyblock public accessversioningCRRSRRSSE-S3SSE-KMSSSE-Cmultipart upload5TBtransfer acceleration503 slow downprefixstatic websiteevent notificationlifecycle policy2 years730 daysStandard-IAGlacierglobal upload

📎 S3 performance best practices 📎 S3 encryption options 📎 S3 Replication

D3 · High-Performing

S3 Access Control

S3 Access Control & Policies (IAM · Bucket Policy · ACL · BPA)

"Banyak 'policy' tu sebenarnya 2 famili: SIAPA boleh sentuh vs APA jadi kat data"

🎯 Sebab Apa Wujud

Wujud sebab satu bucket boleh kena access dari banyak sudut — user dalam akaun kau, account luar, public internet, app. Tiap satu ada cara kawal sendiri: IAM untuk 'user aku', Bucket Policy untuk 'whole bucket / cross-account / force HTTPS', ACL legacy yang AWS dah galak matikan, dan Block Public Access sebagai safety net last line supaya tak tersilap expose. Sebab ramai mechanism inilah yang buat rasa 'banyak sangat policy' — padahal kalau asingkan ikut SIAPA yang kau nak kawal, ia jadi simple.

Apa Dia

Punca orang confused: perkataan "policy" dalam S3 dipakai untuk DUA benda berlainan. (A) ACCESS CONTROL = siapa boleh sentuh data: IAM Policy (attach ke user/role), Bucket Policy (attach ke bucket, resource-based JSON), ACL (legacy per-object/bucket), Block Public Access (master safety switch). (B) DATA MANAGEMENT = apa jadi kat data ikut masa: Lifecycle, Replication (CRR/SRR), Object Lock / Vault Lock — itu BUKAN access control. Card ni fokus famili (A).

Contoh Guna

Web app share fail dengan partner account → Bucket Policy. Pasukan internal akses bucket → IAM Policy. Pastikan bucket tak tersilap public → Block Public Access ON. Distribute private content via CDN → keep bucket private + CloudFront OAC (bukan bucket public).

Famili "policy" S3 — pecahan

IAM Policy → attach ke USER/ROLE (identity-based). "Apa user aku boleh buat" dalam akaun sama

Bucket Policy → attach ke BUCKET (resource-based JSON). Cross-account, public, force HTTPS/encryption

ACL → legacy, per-object/bucket, coarse. AWS galak DISABLE (Bucket owner enforced)

Block Public Access → master switch account/bucket level (default ON). Override semua di atas

— — — (famili lain, BUKAN access control) — — —

Lifecycle / Replication / Object Lock → famili DATA MANAGEMENT (apa jadi kat data), lihat card masing-masing

Decision tree: "policy" mana aku guna?

Rendering diagram…

Step 1: asingkan famili — "siapa access" (A) vs "apa jadi kat data" (B). Step 2 dalam famili A: user aku → IAM; account lain/public/force HTTPS → Bucket Policy; legacy → ACL; safety net → BPA. INGAT exam: "grant another account" → Bucket Policy; "bucket policy allow public tapi tetap private" → BPA ON; "Allow vs Deny" → Explicit Deny menang.

IAM Policy vs Bucket Policy vs ACL vs Block Public Access

Aspect	IAM Policy	Bucket Policy	ACL (legacy)	Block Public Access
Attach kat	User / Role (identity)	Bucket (resource)	Object / Bucket	Account / Bucket
Cross-account?	Tak terus	🟢 Ya (sebut Principal)	Terhad	N/A (safety switch)
Format	JSON identity policy	JSON resource policy	Grant list (coarse)	On/Off toggles
Granularity	Per-action, per-resource halus	Whole bucket / prefix + condition	Kasar (read/write/full)	Master override
Status 2024+	🟢 Recommended	🟢 Recommended	AWS galak DISABLE	🟢 Default ON
Guna bila	Kawal user dalam akaun aku	Cross-account / public / force HTTPS	Elak — guna kalau terpaksa	Pastikan tak tersilap public

Ingat: SIAPA dalam akaun aku → IAM. Account LAIN / whole bucket / force HTTPS/encryption → Bucket Policy. Legacy coarse → ACL (elak). Safety net → Block Public Access (override semua). Bila clash → EXPLICIT DENY menang. Ni famili "siapa access" — jangan campur dengan Lifecycle/Replication/Lock (famili "apa jadi kat data").

⚡ Quick Sifir — hafal ni

▪2 famili: (A) ACCESS = siapa sentuh; (B) DATA MGMT = apa jadi (Lifecycle/Replication/Lock)
▪IAM Policy = identity-based (user/role aku). Bucket Policy = resource-based (whole bucket, cross-account)
▪Cross-account / public / force HTTPS / force encryption → BUCKET POLICY
▪ACL = legacy, coarse — AWS recommend DISABLE (Bucket owner enforced jadi default)
▪Block Public Access (default ON) MENANG atas bucket policy + ACL
▪Bila clash: EXPLICIT DENY sentiasa menang atas mana-mana Allow

💡 Exam Scenario

"Grant another AWS account access" → Bucket Policy. "Control my own users" → IAM Policy. "Bucket tak sengaja jadi public" → enable Block Public Access. "Bucket policy allow public tapi tetap private" → BPA masih ON. "Allow vs Deny clash" → Explicit Deny wins. "Force semua request guna HTTPS / encryption" → Bucket Policy condition (aws:SecureTransport / s3:x-amz-server-side-encryption).

🪤 Perangkap Soalan

Q: Nak grant satu AWS account LAIN read access ke bucket kau. Policy mana paling betul?

⚠ Umpan: Tambah IAM policy — nampak betul sebab IAM memang untuk grant permission. SALAH: IAM policy hanya untuk identity dalam akaun KAU; tak boleh terus bagi account lain access bucket kau.

✓ Betul: Bucket Policy (resource-based) — boleh sebut Principal account lain terus. Keyword 'grant another account / cross-account access' → Bucket Policy, BUKAN IAM.

Q: Bucket Policy dah Allow public read, tapi objek tetap tak boleh diakses public. Kenapa?

⚠ Umpan: Mesti salah tulis JSON Bucket Policy — betulkan Principal/Action. Mungkin, tapi exam selalu nak benda lebih asas yang override.

✓ Betul: Block Public Access masih ON — ia OVERRIDE bucket policy/ACL. Matikan BPA dulu (atau settle dengan CloudFront OAC kalau nak kekal private). Keyword 'bucket policy allow public tapi masih private' → Block Public Access.

Q: Satu IAM policy Allow s3:GetObject, tapi bucket policy ada Deny untuk action sama. User boleh GET ke tak?

⚠ Umpan: Boleh — sebab IAM dah Allow, jadi access diberi. SALAH: anggapan 'Allow di mana-mana = boleh'.

✓ Betul: TAK BOLEH. Explicit Deny (di bucket policy) sentiasa menang atas mana-mana Allow. Keyword 'Allow vs Deny clash' → Explicit Deny wins.

🧠 Cara Mudah Ingat

→IAM Policy = identity-based ("apa user/role aku boleh buat"). Bucket Policy = resource-based ("apa boleh jadi kat bucket ni, termasuk account lain").
→Cross-account access ke bucket → Bucket Policy (sebut Principal account lain). IAM sahaja TAK boleh grant account lain access bucket kau.
→Block Public Access (default ON, account + bucket level) OVERRIDE bucket policy + ACL. "Bucket policy allow public tapi masih private" = BPA masih ON.
→ACL legacy & coarse — AWS recommend "Bucket owner enforced" (ACL disabled) sebagai default. Kalau ACL muncul sebagai jawapan moden, selalunya umpan.
→Evaluation: Explicit DENY > Allow. Kalau bucket policy Deny + IAM Allow → Deny menang. Default semua = implicit deny.
→Force HTTPS → bucket policy condition aws:SecureTransport=false → Deny. Force encryption upload → condition s3:x-amz-server-side-encryption.
→Nak distribute private content via CDN → JANGAN public-kan bucket; keep private + CloudFront OAC (Origin Access Control). Bucket policy bagi access ke OAC sahaja.
→PRICING: IAM, Bucket Policy, ACL, Block Public Access semua FREE — kau bayar untuk storage + request je, bukan untuk mechanism access control.

Guna Bila

Kawal siapa boleh access bucket/object — pilih antara IAM Policy, Bucket Policy, ACL, atau Block Public Access

S3 access controlIAM policybucket policyACLaccess control listblock public accessBPAcross-accountresource-based policyidentity-based policyexplicit denyaws:SecureTransportforce HTTPSOACCloudFront OACpublic bucketprincipalpricing

📎 S3 access control overview 📎 Bucket policies 📎 Blocking public access

D3 · High-Performing

S3 Glacier

Amazon S3 Glacier (storage classes)

"S3 sejuk beku — murah, tapi tunggu lama nak retrieve"

🎯 Sebab Apa Wujud

Glacier wujud sebab data arkib (rekod 7-10 tahun, backup yang mungkin tak pernah dibuka) tak patut bayar harga S3 Standard yang mahal. Kau tukar 'laju retrieve' dengan 'murah simpan' — makin sanggup tunggu lama nak cairkan data, makin murah storan. Ni buang pembaziran bayar storan panas untuk data sejuk yang duduk diam je.

Apa Dia

Glacier = kelas storan S3 paling murah untuk ARKIB. Tiga jenis ikut berapa laju kau perlu data balik: Instant Retrieval (ms), Flexible Retrieval (minit–jam), Deep Archive (jam). Makin sejuk makin murah, tapi makin lama nak "cairkan" (restore). Nota: servis lama "Glacier Vault" yang berasingan dah legacy — exam & AWS sekarang guna S3 Glacier storage classes.

Contoh Guna

Rekod kewangan 7 tahun, arkib perubatan, log compliance, backup yang mungkin tak pernah dibuka

Pilih Glacier class (decision tree)

Rendering diagram…

Deep Archive TIADA Expedited — paling laju pun Standard ~12 jam. Kalau soalan kata "retrieve dalam minit" + Deep Archive = jawapan SALAH.

Glacier 3 classes — retrieval & kos

Aspect	Instant Retrieval	Flexible Retrieval	Deep Archive
Retrieval speed	🟢 Milliseconds (terus GET)	Minit – jam (kena restore)	Jam (kena restore)
Min storage duration	90 hari	90 hari	180 hari
Kos storage	Murah	Lagi murah	🟢 Paling murah (~$0.00099/GB)
Access pattern	Jarang, tapi kena segera bila perlu	Arkib, sekali-sekala	Arkib jangka sangat panjang
Contoh	Medical imaging, news media lama	Backup, DR, log arkib	Compliance 7-10 thn, regulatory

Ingat: Pilih ikut keperluan retrieval: "rarely access TAPI bila perlu kena ms" → Instant Retrieval (bukan Flexible/Deep). "Petabytes, 10-year retention, paling murah" → Deep Archive.

Retrieval tiers — masa & kos (verified AWS docs)

Tier	Flexible Retrieval	Deep Archive	Kos
Expedited	1–5 minit	❌ Tiada	Paling mahal
Standard	3–5 jam	~12 jam	Sederhana
Bulk	5–12 jam	~48 jam	🟢 Paling murah

Ingat: Trap utama: Deep Archive TAK ADA Expedited. Glacier Instant Retrieval TAK PERLU restore langsung — terus GET macam Standard-IA.

⚡ Quick Sifir — hafal ni

▪3 class: Instant (ms, no restore) · Flexible (min-jam) · Deep Archive (jam)
▪Min duration: Instant 90 hari · Flexible 90 hari · Deep Archive 180 hari
▪Deep Archive TIADA Expedited — paling laju Standard ~12 jam, Bulk ~48 jam
▪Flexible restore: Expedited 1-5min · Standard 3-5jam · Bulk 5-12jam
▪Glacier Instant = terus GET (macam Standard-IA), TAK perlu restore job
▪Deep Archive paling murah ~$0.00099/GB-mo

💡 Exam Scenario

Hospital simpan imej X-ray jarang dibuka TAPI bila doktor minta kena dapat dalam milisaat → S3 Glacier Instant Retrieval (bukan Flexible — Flexible kena tunggu minit-jam). Firma guaman simpan rekod 10 tahun, petabytes, hampir tak pernah buka, nak paling murah → S3 Glacier Deep Archive. Auto-pindah guna S3 Lifecycle Policy (Standard → IA → Glacier ikut umur object).

🪤 Perangkap Soalan

Q: Imej X-ray jarang dibuka TAPI bila doktor minta kena dapat dalam milisaat, kos rendah. Class mana?

⚠ Umpan: Glacier Flexible Retrieval — nampak 'jarang access = Glacier' jadi pilih Flexible.

✓ Betul: Glacier Instant Retrieval. Flexible kena restore job (minit-jam), tak boleh ms. Keyword: 'millisecond retrieval' + 'rarely access' → Instant.

Q: Data compliance dalam Deep Archive, audit minta retrieve 'dalam beberapa minit'. Boleh?

⚠ Umpan: Pilih Expedited tier untuk Deep Archive — anggap semua Glacier ada Expedited.

✓ Betul: TAK BOLEH. Deep Archive tiada Expedited; paling laju Standard ~12 jam. Kalau perlu segera kena Glacier Flexible/Instant. Keyword: 'Deep Archive' + 'minutes' = trap.

🧠 Cara Mudah Ingat

→Glacier Instant Retrieval: retrieve MILLISECONDS, tak payah restore job — terus GET. Untuk data jarang access tapi perlu segera (medical, news archive). Min 90 hari.
→Glacier Flexible Retrieval (dulu nama "Glacier"): kena buat restore job dulu. Expedited 1-5min / Standard 3-5jam / Bulk 5-12jam. Min 90 hari.
→Glacier Deep Archive: PALING MURAH. Restore Standard ~12 jam, Bulk ~48 jam. TIADA Expedited. Min 180 hari. Untuk compliance 7-10 tahun.
→Min storage charge: kalau delete sebelum tempoh minimum (90/90/180 hari) tetap kena bayar baki tempoh — jangan letak data jangka pendek dalam Glacier.
→S3 Object Lock + Glacier = WORM compliance (immutable, tak boleh padam sampai tarikh) — untuk regulatory (SEC, FINRA).
→Lifecycle Policy: auto-transition object ikut umur (cth >30 hari → Standard-IA, >90 hari → Glacier Flexible, >365 hari → Deep Archive) + auto-expire/delete.
→Trap: "rarely accessed + millisecond retrieval" = Instant Retrieval. "retrieve dalam minit" + Deep Archive = SALAH (Deep paling laju ~12 jam).

Guna Bila

Archive jangka panjang, jarang/tak pernah access (compliance, backup lama)

archivingcold storageGlacier Instant RetrievalGlacier Flexible RetrievalGlacier Deep Archiverestore jobExpeditedStandardBulkmin storage durationlifecycle policyWORM11 nines

📎 S3 Glacier storage classes 📎 Archive retrieval options

D3 · High-Performing

S3 Storage Classes

S3 Storage Classes — 7 Main Tiers + Express One Zone

"7 tingkat storan + Express One Zone — makin sejuk makin murah, makin lama nak cairkan"

🎯 Sebab Apa Wujud

Storage classes wujud sebab bukan semua data sama 'panas' — ada yang access tiap saat, ada yang duduk diam bertahun. Bayar harga Standard untuk semua = membazir. Class bagi kau padankan kos dengan access pattern: panas bayar mahal+laju, sejuk bayar murah+lambat. Inilah jawapan no.1 untuk soalan 'cost optimization' dalam exam.

Apa Dia

S3 ada 7 storage classes utama (+ S3 Express One Zone yang baru) untuk optimize kos ikut access frequency. Semua class ada 11 nines durability (99.999999999%) — yang BEZA = availability, AZ resilience, retrieval speed, minimum duration, dan kos. Faham SATU benda dulu: cara retrieve ada DUA jenis — (1) direct GET (millisecond, ambik terus) untuk Standard, IA, One Zone-IA, Intelligent-Tiering, Express One Zone, dan Glacier INSTANT; (2) RESTORE job (kena "order" dulu, tunggu) untuk Glacier Flexible & Deep Archive. Garis pemisah ni paling kerap exam umpan.

Storage Classes — anatomy (7 utama + Express One Zone)

S3 Standard → Hot data, access frequent, default untuk most workloads (99.99% avail, ≥3 AZ)

S3 Standard-IA → Infrequent access (~sebulan sekali) TAPI masih perlu millisecond retrieval; multi-AZ (contoh: DR backup)

S3 One Zone-IA → Infrequent access, data dalam 1 AZ sahaja (20% lebih murah dari Standard-IA, risiko AZ musnah)

S3 Intelligent-Tiering → Auto-pindah object antara tiers ikut access pattern (no retrieval fee, monitoring fee)

S3 Express One Zone → BARU: single-digit ms, 10x laju Standard, 1 AZ, untuk latency-sensitive hot data (mahal ~$0.16/GB)

S3 Glacier Instant Retrieval → Arkib, jarang access (~suku tahun), TAPI bila perlu kena millisecond (direct GET, tak perlu restore)

S3 Glacier Flexible Retrieval → Arkib (~setahun sekali), WAJIB restore job, tunggu minit-jam

S3 Glacier Deep Archive → Paling murah, arkib jangka sangat panjang (compliance 7-10 tahun), WAJIB restore job, retrieve 12-48 jam

Pilih S3 Storage Class (decision tree)

Rendering diagram…

Cara ingat: makin sejuk makin murah, makin lama nak "cair". Standard = panas (mahal, laju). Deep Archive = beku (murah, retrieve 12-48 jam). IA = sejuk sikit (murah dari Standard, retrieval fee). Intelligent-Tiering = auto thermostat. INGAT exam: One Zone-IA 20% lebih murah dari Standard-IA tapi data hilang kalau AZ musnah — guna untuk re-creatable data sahaja.

Cara ingat — analogi dapur: peti ais → peti beku → stor sejukbeku

Rendering diagram…

Kaitkan dengan dapur: barang selalu guna letak atas meja (Standard, ambik free bila-bila). Barang jarang → peti ais bawah (IA, tiap kali ambik kena bayar "tol" = retrieval fee). Beku tapi nak segera → peti beku (Glacier Instant, capai terus ms tanpa restore). Barang simpan lama betul → stor sejukbeku luar (Glacier Flexible/Deep Archive) = kena "order/booking" dulu (RESTORE job), tunggu min-jam atau 12-48 jam. INGAT exam: garis pemisah BESAR = Glacier Flexible & Deep Archive WAJIB restore job; semua yang lain (termasuk Glacier Instant) = direct GET ms.

S3 Storage Class Transition Waterfall (lifecycle)

Rendering diagram…

Lifecycle transition = waterfall MENURUN je (hot → cold). Standard boleh pindah ke mana-mana class bawah; setiap tier boleh skip ke bawah tapi tak boleh "naik" balik via lifecycle. INGAT exam: "files older than 2 years → cheaper class" + global upload → S3 Lifecycle (Standard-IA DAN/ATAU Glacier), BUKAN EFS (max 365 hari lifecycle), BUKAN EBS/DLM snapshots.

DISCRIMINATOR: retrieval MECHANISM + availability + AZ (D3 angle — kos all-in di card "S3 Storage Tiers")

Class	Cara retrieve	Availability (designed)	AZ	Akses (AWS design for)
Standard	direct GET (ms)	99.99%	≥3	>1×/bulan (hot)
Standard-IA	direct GET (ms)	99.9%	≥3	~1×/bulan
One Zone-IA	direct GET (ms)	99.5%	1 AZ	~1×/bulan, re-creatable
Intelligent-Tiering	direct GET (ms, auto-tier)	99.9%	≥3	unknown / berubah
Express One Zone ⚡	direct GET (single-digit ms)	99.95%	1 AZ	hot + latency-sensitive
Glacier Instant	direct GET (ms, NO restore)	99.9%	≥3	~1×/suku tahun
Glacier Flexible	RESTORE job dulu (min–jam)	99.99% (lepas restore)	≥3	~1×/tahun
Deep Archive	RESTORE job dulu (12–48 jam)	99.99% (lepas restore)	≥3	hampir tak pernah

Ingat: Discriminator no.1 = direct GET (ms) vs RESTORE job. Standard / IA / One Zone-IA / Intelligent-Tiering / Express One Zone / Glacier INSTANT = direct GET (millisecond). Glacier FLEXIBLE & Deep Archive = WAJIB restore job dulu, bukan GET terus. Semua 11 nines durability — yang beza availability + AZ resilience (One Zone classes = 1 AZ, hilang kalau AZ musnah).

All S3 Storage Classes — pricing & key facts (us-east-1)

Class	Storage $/GB-mo	Retrieval	Min Duration	AZ	Best untuk
Standard	$0.023	ms (free)	None	Multi-AZ (≥3)	Hot data, frequent access — default
Standard-IA	$0.0125	ms (retrieval fee)	30 hari	Multi-AZ (≥3)	Infrequent access, long-lived data
One Zone-IA	$0.01	ms (retrieval fee)	30 hari	1 AZ	Infrequent, re-creatable data — cheapest IA
Intelligent-Tiering	$0.023 (hot tier)	ms (auto-tier)	None	Multi-AZ	Unknown/unpredictable access pattern
Express One Zone	~$0.16 (mahal!)	single-digit ms	None	1 AZ	Latency-sensitive hot data (10x laju Standard)
Glacier Instant	$0.004	ms (no restore!)	90 hari	Multi-AZ	Archive, rare access BUT ms needed
Glacier Flexible	$0.0036	min–jam (restore)	90 hari	Multi-AZ	Archive, boleh tunggu untuk restore
Deep Archive	$0.00099	12–48 jam (restore)	180 hari	Multi-AZ	Compliance 7-10 thn, hampir tak pernah access

Ingat: Hot data → Standard. Latency-paling-kritikal (single-digit ms) → Express One Zone (mahal, 1 AZ). Infrequent but ms retrieval → Standard-IA (multi-AZ) atau One Zone-IA (murah, 1 AZ). Unknown pattern → Intelligent-Tiering (auto-move). Archive + ms retrieval → Glacier Instant. Archive + boleh tunggu → Glacier Flexible. Cheapest long-term → Deep Archive.

⚡ Quick Sifir — hafal ni

▪Semua class = 11 nines durability; beza availability + AZ resilience + retrieval + min duration
▪Direct GET (ms): Standard, IA, One Zone-IA, Intelligent-Tiering, Express One Zone, Glacier INSTANT
▪RESTORE job (tunggu): Glacier Flexible (min-jam) + Deep Archive (12-48 jam) — BUKAN GET terus
▪Glacier Instant vs Standard-IA: kedua ms; beza frekuensi (IA ~bulanan, Glacier IR ~suku tahun)
▪One Zone-IA = 20% lebih murah Standard-IA TAPI 1 AZ je (data hilang kalau AZ musnah)
▪Intelligent-Tiering: auto-move ikut access, NO retrieval fee, monitoring $0.0025/GB (free objek <128KB)
▪Express One Zone = single-digit ms (10x laju Standard) tapi 1 AZ + MAHAL — latency-sensitive je
▪Cheapest = Deep Archive $0.00099/GB; default/hot = Standard $0.023/GB

💡 Exam Scenario

"Medical images rarely access but need ms retrieval when doctor requests" → Glacier Instant Retrieval (bukan Flexible). "Log files 90-day retention, infrequent access, re-creatable" → One Zone-IA. "Don't know access pattern yet" → Intelligent-Tiering. "Compliance records 7 years, petabytes, almost never access" → Deep Archive. "Active web content" → Standard.

🪤 Perangkap Soalan

Q: Access pattern data baru TAK DIKETAHUI, nak auto-optimize kos tanpa risiko salah pilih. Class?

⚠ Umpan: Standard-IA — anggap 'jimat sikit' selamat, atau set Lifecycle manual.

✓ Betul: Intelligent-Tiering. Ia auto-pindah antara tiers ikut access sebenar, jadi tak perlu teka. Standard-IA salah kalau data sebenarnya kerap diakses (kena retrieval fee). Keyword: 'unknown/unpredictable access pattern'.

Q: Log files re-creatable, infrequent access, nak paling murah untuk infrequent tier. Pilih mana?

⚠ Umpan: Standard-IA — nampak 'infrequent' terus pilih IA standard.

✓ Betul: One Zone-IA — 20% lebih murah, dan sebab data re-creatable, risiko AZ musnah OK. Keyword: 're-creatable' + 'infrequent' → One Zone-IA.

Q: Medical images rarely accessed (sekali sesuku tahun) TAPI bila doktor minta kena dapat dalam millisecond. Standard-IA atau Glacier Instant Retrieval?

⚠ Umpan: Standard-IA — sebab kedua-dua bagi retrieval millisecond, jadi nampak sama je, pilih yang familiar.

✓ Betul: Glacier Instant Retrieval — kedua-dua memang ms, tapi DISCRIMINATOR = berapa KERAP. Standard-IA = AWS design for ~sebulan sekali; Glacier Instant = ~sesuku tahun sekali (lagi sejuk, storan lagi murah $0.004 vs $0.0125). Keyword: 'rarely accessed' + 'millisecond' → Glacier INSTANT, bukan IA.

Q: Data archive perlu diretrieve dalam millisecond bila perlu. Boss pilih Glacier Flexible sebab 'Glacier murah'. Betul ke?

⚠ Umpan: Glacier Flexible — nampak 'archive + murah', dan ingat semua Glacier boleh ambik terus.

✓ Betul: SALAH — Glacier Flexible & Deep Archive WAJIB buat RESTORE job dulu (min–jam / 12–48 jam), bukan direct GET. Untuk archive + millisecond, satu-satunya pilihan = Glacier INSTANT Retrieval (direct GET ms, no restore). Keyword: 'archive' + 'millisecond' → Glacier Instant; 'restore job' / 'minutes to hours' → Flexible/Deep.

🧠 Cara Mudah Ingat

→Intelligent-Tiering ada monitoring fee ($0.0025/GB/mo) tapi auto-pindah antara tiers → elak tebak access pattern salah. Free untuk objects <128KB (too small to monitor).
→One Zone-IA = 20% lebih murah dari Standard-IA. TAPI hanya 1 AZ — kalau AZ musnah, data lenyap. Guna untuk re-creatable data atau backup yang ada copy di tempat lain.
→Standard-IA dan One Zone-IA ada retrieval fee ($0.01/GB) + min 30 hari storage duration. Kalau access lebih frequent dari itu, Standard lebih murah.
→Intelligent-Tiering = pindah ke IA automatically kalau object tak di-access selama 30 hari berturut-turut. Pindah balik ke Standard kalau di-access.
→Glacier Instant Retrieval = ms retrieval, TAK PERLU restore job. Sama macam GET Standard-IA. Untuk data jarang access tapi bila perlu kena segera.
→Min storage duration: delete sebelum tempoh minimum tetap kena bayar baki. Standard = no min. IA = 30 hari. Glacier = 90/90/180 hari.
→Semua class ada 11 nines durability — beza adalah pada availability (Standard 99.99%, IA 99.9%, One Zone-IA 99.5%) dan retrieval speed.
→Lifecycle Policy: auto-transition ikut umur — Standard → IA (30d) → Glacier Flexible (90d) → Deep Archive (365d). Letak Intelligent-Tiering kalau tak yakin pattern.
→RESTORE job: Glacier Flexible & Deep Archive BUKAN direct GET — kena initiate restore job dulu (Flexible: Expedited 1-5min / Standard 3-5hr / Bulk 5-12hr; Deep Archive: Standard ~12hr / Bulk ~48hr, NO Expedited). Glacier Instant tak perlu restore (GET terus ms).
→S3 Express One Zone (BARU, makin masuk exam 2024+): single-digit ms, up to 10x laju Standard, request cost 50% lebih murah TAPI storan mahal (~$0.16/GB) + 1 AZ je. Trigger: "lowest latency / latency-sensitive / single-digit millisecond". Bukan untuk jimat storan — untuk laju.
→PRICING: storan/GB-mo — Standard $0.023 · Standard-IA $0.0125 · One Zone-IA $0.01 · Express One Zone ~$0.16 · Glacier Instant $0.004 · Flexible $0.0036 · Deep Archive $0.00099 (cheapest). Untuk breakdown KOS penuh (retrieval fee + min-duration + min 128KB billing + break-even rule) tengok card "S3 Storage Tiers" (D4 cost angle).

Guna Bila

Pilih S3 class ikut access pattern + retrieval speed + kos (the THE exam storage decision)

S3 StandardStandard-IAOne Zone-IAIntelligent-TieringS3 Express One ZoneGlacier Instant RetrievalGlacier Flexible RetrievalDeep Archivepricingstorage classretrieval feemin storage durationavailability11 nines durabilitylifecycle transitionauto-tieringrestore jobdirect GETmillisecond retrievalsingle-digit millisecondlatency-sensitiveAZ resiliencerarely accessed

📎 S3 storage classes overview 📎 S3 storage class comparison

D3 · High-Performing

S3 Lifecycle

S3 Lifecycle Management

"Auto-pindah object ke kelas murah ikut umur — macam roti: fresh → semalam → beku"

🎯 Sebab Apa Wujud

Lifecycle wujud sebab kalau kena tukar storage class atau padam object lama secara manual untuk berjuta object = mustahil + mudah terlupa → bil membengkak. Lifecycle automate: kau set jadual sekali ('30 hari → IA, 90 hari → Glacier, 7 tahun → delete'), AWS pindah & padam sendiri ikut umur object. Buang kerja manual + elak bayar storan panas untuk data lama.

Apa Dia

Lifecycle rules automatik pindah object ke storage class yang lebih murah berdasarkan umur (days sejak creation), dan boleh auto-expire (delete) object lama. Dua jenis rule: Transition (pindah ke class lain) dan Expiration (padam object). Rules boleh untuk whole bucket atau specific prefix/tags.

Contoh Guna

Log file masuk Standard → 30 hari pindah ke Standard-IA → 90 hari pindah ke Glacier Flexible → 365 hari pindah Deep Archive → 2555 hari (7 tahun) auto-delete.

Lifecycle rule anatomy

Transition rule → "bila object umur X hari, pindah ke class Y" (cth: 30 hari → Standard-IA)

Expiration rule → "bila object umur Z hari, delete permanently" (cth: 2555 hari → delete)

Filter → boleh scope rule ikut prefix (folder), tags, atau object size

Current versions vs Previous versions → boleh set rules berbeza untuk version aktif vs lama

Noncurrent version expiration → auto-padam versi lama selepas X hari (clean up versioning clutter)

Noncurrent version transition → pindah versi lama ke class murah

Analogi roti & beku — Lifecycle aging

Rendering diagram…

Analogi kilang roti: roti fresh (Standard) → selepas 30 hari jadi roti semalam (IA) → sejuk beku (Glacier) → deep freeze (Deep Archive) → tong sampah (auto-delete). Lifecycle automation = kau tetapkan jadual, AWS pindah sendiri. INGAT exam: "automatically transition S3 objects to cheaper tiers by age" → Lifecycle Rules. "auto-detect access pattern" → Intelligent-Tiering.

S3 Storage Class Transition Waterfall

Rendering diagram…

Waterfall menurun: setiap class boleh transition ke mana-mana tier di BAWAH (tak naik balik). Standard = puncak; Deep Archive = hujung. S3 & EFS ada lifecycle, tapi EFS max 365 hari transition — tak boleh 2 tahun (730 hari). Exam SELECT TWO: S3 Lifecycle → Standard-IA + Glacier selepas 2 tahun.

Lifecycle vs Intelligent-Tiering — dua cara auto-optimize kos

Aspect	Lifecycle Rules	Intelligent-Tiering
Cara decide	AGE-based (umur object, X hari selepas creation)	ACCESS-based (auto-detect kalau tak di-access 30 hari)
Rule type	Manual: kau set transition + expiration schedule	Automatic: S3 auto-pindah ikut access pattern
Boleh delete?	🟢 Ya — expiration rule auto-padam object lama	❌ Tidak — auto-pindah sahaja, tak auto-delete
Granularity	Prefix, tag, size filter — rule per-prefix	Per-object automatic (semua object dalam class ni)
Best bila	Access pattern DIKETAHUI (log → IA → Glacier → delete)	Access pattern TAK DIKETAHUI (unpredictable)

Ingat: Tahu bila data jadi sejuk (log, backup, compliance) → Lifecycle (age-based, boleh auto-delete). Tak tahu corak access → Intelligent-Tiering (auto-detect, tapi tak auto-delete). Selalu guna dua-dua: Intelligent-Tiering untuk unknown + Lifecycle expiration untuk auto-cleanup.

⚡ Quick Sifir — hafal ni

▪Lifecycle = AGE-based (umur object); Intelligent-Tiering = ACCESS-based (auto-detect)
▪2 jenis rule: Transition (pindah class) + Expiration (auto-delete)
▪Lifecycle BOLEH auto-delete; Intelligent-Tiering TAK boleh delete (pindah je)
▪Standard → Standard-IA minimum 30 hari sebelum boleh transition
▪Noncurrent version rules = clean up versi LAMA bila versioning ON
▪Boleh scope rule ikut prefix / tag / object size
▪Lifecycle cover SEMUA storage class (Standard → IA → Glacier Instant → Flexible → Deep Archive), BUKAN Glacier je — ia 'jalan raya' auto-tolak object menuruni kasta murah
▪Transition action = pindah class; Expiration action = auto-DELETE (compliance/retain-then-delete)

💡 Exam Scenario

"Automatically move log files from Standard to IA after 30 days, to Glacier after 90 days, delete after 1 year" → S3 Lifecycle Policy. "Don't know access pattern, want S3 to auto-choose tier" → Intelligent-Tiering (bukan Lifecycle). "Clean up old versions of objects after 30 days" → Noncurrent version expiration rule.

🪤 Perangkap Soalan

Q: Nak auto-pindah log ke IA selepas 30 hari, Glacier selepas 90, dan PADAM selepas 1 tahun. Guna apa?

⚠ Umpan: Intelligent-Tiering — anggap ia uruskan semua auto-tiering.

✓ Betul: S3 Lifecycle Policy (Transition + Expiration). Intelligent-Tiering tak boleh auto-DELETE, dan ia access-based bukan age-based. Keyword: 'after X days' + 'delete' → Lifecycle.

Q: Versioning ON, nak buang versi lama object selepas 30 hari untuk jimat kos. Rule apa?

⚠ Umpan: Expiration rule biasa — sangka ia padam current version sahaja.

✓ Betul: Noncurrent version expiration rule. Expiration biasa kena current version; untuk versi lama kena rule 'noncurrent'. Keyword: 'old/previous versions cleanup'.

Q: Files >2 years old kena cheaper storage; global upload via EC2 ASG. Pilih DUA lifecycle approach.

⚠ Umpan: EFS lifecycle ke EFS-IA — nampak lifecycle = EFS. SALAH: EFS lifecycle max 365 hari, tak capai 730 hari (2 tahun).

✓ Betul: DUA S3 Lifecycle transitions: Standard-IA selepas 2 tahun DAN Glacier (Flexible) selepas 2 tahun. S3 scalable object store + lifecycle boleh 730+ hari. BUKAN EBS/DLM/RAID.

🧠 Cara Mudah Ingat

→Lifecycle = age-based (umur object), Intelligent-Tiering = access-based (auto-detect). Pilih Lifecycle bila tahu corak access.
→Expiration rule = auto-DELETE object lama. Berguna untuk compliance ("retain 7 years then delete") atau cleanup storage.
→Noncurrent version rules: bila versioning ON, set rules untuk padam/pindah versi LAMA (previous versions) — bukan current version. Auto-cleanup versioning clutter.
→Min transition days: Standard → Standard-IA minimum 30 hari (AWS require at least 30 days in Standard before transitioning to IA).
→Lifecycle boleh combine dengan Intelligent-Tiering: Intelligent-Tiering untuk unknown pattern + Lifecycle expiration untuk auto-delete old data.
→Exam: "automatically move objects to Glacier after 90 days" → Lifecycle Transition Rule. "auto-delete logs after 365 days" → Lifecycle Expiration Rule. "unknown access pattern, auto-optimize" → Intelligent-Tiering.

Guna Bila

Automatically transition objects to cheaper storage classes + expire old objects

lifecycletransition ruleexpiration ruleauto-moveauto-deleteage-basedstorage class transitiontransition waterfallnoncurrent versionversioning cleanupS3 lifecycle policycost optimizationprefix filtertag filter2 years730 daysEFS lifecycle 365 max

📎 S3 Lifecycle configuration

D3 · High-Performing

S3 CORS

S3 Cross-Origin Resource Sharing (CORS)

"Browser block request dari domain lain — CORS rule bagi kebenaran"

🎯 Sebab Apa Wujud

CORS wujud sebab BROWSER (bukan AWS) ada rules keselamatan: by default browser block JavaScript di domain A daripada fetch resource di domain B (cross-origin). Bila web app kau perlu upload/download terus ke S3 dari browser, S3 kena 'beritahu' browser ia benarkan domain kau — itulah CORS config. Tanpa ia, browser block request walaupun IAM dah bagi akses.

Apa Dia

CORS (Cross-Origin Resource Sharing) adalah mechanism browser yang control sama ada web app di domain A boleh akses resources di domain B. Untuk S3, kau set CORS configuration pada bucket untuk allow specific origins, methods, dan headers.

Contoh Guna

Web app di https://app.example.com nak upload images terus ke S3 bucket (https://cdn.example.com) dari browser — CORS rule pada S3 bucket allow origin https://app.example.com.

CORS vs Bucket Policy vs Pre-Signed URL — 3 S3 access mechanisms

Mechanism	Layer	Untuk apa
CORS	Browser security	Allow browser app di domain A access resources di domain B
Bucket Policy	IAM / resource-level	Grant/deny access to principals (users, accounts, services)
Pre-Signed URL	Temporary credential	Give time-limited access to one object guna IAM creds

Ingat: CORS = "boleh ke browser ni akses bucket domain lain?" (browser-level). Bucket Policy = "siapa boleh akses bucket ni?" (IAM-level). Pre-Signed URL = "berapa lama URL ni sah?" (object-level). CORS tak replace bucket policy — kau masih perlu allow IAM access SELAIN dari CORS.

⚡ Quick Sifir — hafal ni

▪CORS = browser-level permission, BUKAN IAM/bucket policy
▪Set per-BUCKET (PutBucketCors), bukan per-object
▪Config: AllowedOrigin + AllowedMethod + AllowedHeader
▪Error 'Access-Control-Allow-Origin missing' = kena set CORS rule
▪CORS tak ganti bucket policy — masih perlu IAM allow access JUGA

💡 Exam Scenario

"Browser app at www.example.com needs to GET/PUT objects in S3 bucket directly" → configure CORS on the S3 bucket to allow origin www.example.com. Bukan bucket policy (yang control IAM-level access). CORS = browser-level permission.

🪤 Perangkap Soalan

Q: Browser app di www.example.com tak boleh GET/PUT object dari S3 bucket di domain lain, walaupun IAM dah betul. Fix?

⚠ Umpan: Ubah bucket policy untuk allow domain — sangka ini masalah permission IAM.

✓ Betul: Configure CORS pada S3 bucket (allow origin www.example.com). Ini browser-level block, bukan IAM. Bucket policy dah betul. Keyword: 'browser' + 'cross-origin'.

🧠 Cara Mudah Ingat

→CORS = browser security policy, BUKAN IAM. Browser block cross-origin requests by default; CORS rule pada S3 bucket memberi kebenaran.
→CORS configuration adalah XML/JSON pada S3 bucket: <CORSRule> dengan <AllowedOrigin>, <AllowedMethod>, <AllowedHeader>.
→Error tipikal: "Access-Control-Allow-Origin" missing → browser block → kena set CORS rule pada S3 bucket tu.
→CORS tak replace Bucket Policy — kau masih perlu IAM/permission allow access ke bucket. CORS cuma buka browser-level block.
→Exam: "browser app di domain A tak boleh access S3 bucket di domain B" → configure CORS on S3 bucket (allow origin). Bukan tukar bucket policy.
→S3 CORS boleh set via console atau API (PutBucketCors). Set per-bucket, bukan per-object.

Guna Bila

Allow web apps on one domain to access S3 resources on a different domain

CORScross-originbrowser securityAllowedOriginAccess-Control-Allow-Originweb appdomainbucket CORSXML configuration

📎 S3 CORS configuration

D3 · High-Performing

S3 Pre-Signed URL

S3 Pre-Signed URLs

"URL dengan tiket sementara — siapa ada boleh access, tapi hanya untuk tempoh tertentu"

🎯 Sebab Apa Wujud

Pre-Signed URL wujud sebab kau nak bagi orang luar (yang TIADA AWS account) akses upload/download SATU object sementara, tanpa kau kongsi credentials atau buat bucket jadi public. Daripada bagi orang IAM user atau buka bucket public (bahaya), kau jana URL bertarikh luput — siapa ada link boleh akses dalam tempoh tu je. Buang risiko credential leak + public bucket.

Apa Dia

Pre-signed URL adalah URL S3 yang ada signature + expiry time. Siapa punya URL tu boleh upload atau download object tersebut tanpa perlu AWS credentials. Permission ikut IAM user yang generate URL tersebut.

Contoh Guna

Generate pre-signed URL valid 1 jam → hantar ke customer → customer download file besar dari S3 terus tanpa perlu AWS account/login.

Analogi Tiket Konsert — Pre-Signed URL

Rendering diagram…

Analogi: kau (penjual tiket) jana tiket dengan tarikh luput. Customer (pembeli) tunjuk tiket dekat pintu masuk S3. Tiket sah = masuk. Tiket expired = kena tolak. Permission tiket = ikut hak kau (IAM pemberi). INGAT exam: "temporary access to ONE S3 object without credentials" → Pre-Signed URL. "private content via CDN at scale" → CloudFront Signed URL.

S3 Pre-Signed URL vs CloudFront Signed URL — yang mana?

Aspect	S3 Pre-Signed URL	CloudFront Signed URL/Cookie
Akses melalui	Direct ke S3 (tiada CDN)	Through CloudFront (edge cache, global)
Sign guna	IAM credentials pemberi	Trusted key group (public/private key)
Permission	Inherit IAM permission si-pemberi	Independent dari IAM
Skop	1 object sahaja	URL = 1 file; Cookie = banyak files
Extra control	Expiry time sahaja	Restrict by IP, expiry, geo, caching
Kos	Free	CloudFront charges
Best untuk	One-off upload/download terus ke S3	Private content at scale via CDN (paid media)

Ingat: One-off direct S3 access → Pre-Signed URL (simple, free, IAM creds). Private content at scale globally via CDN → CloudFront Signed URL/Cookie (IP restriction, edge cache, trusted key group). Exam: "give customer temporary access to download one file from S3" → Pre-Signed URL.

⚡ Quick Sifir — hafal ni

▪Permission ikut IAM creds yang GENERATE URL (bukan yang guna)
▪Expiry: 1 saat hingga 7 hari max (default SDK = 7 hari)
▪Boleh untuk GET (download) DAN PUT (upload) — bukan GET sahaja
▪TAK boleh restrict by IP — itu CloudFront Signed URL je
▪Guna STS temporary creds: URL expiry tak boleh lebih dari creds expiry (pendek menang)
▪Skop = 1 object; expired → 403 Forbidden

💡 Exam Scenario

"Give temporary download access to one S3 file for 1 hour, no AWS credentials needed" → S3 Pre-Signed URL. "Serve private video globally via CDN with IP restriction" → CloudFront Signed URL. "User uploads file to S3 from browser without credentials" → Pre-Signed URL for PUT operation.

🪤 Perangkap Soalan

Q: Bagi customer download SATU file S3 untuk 1 jam tanpa AWS account. Guna apa?

⚠ Umpan: Buat bucket public / bagi IAM user — atau pilih CloudFront Signed URL.

✓ Betul: S3 Pre-Signed URL. Simple, free, expiry-based, 1 object. CloudFront Signed URL untuk private content at scale via CDN. Keyword: 'temporary' + 'one file' + 'no credentials'.

Q: Nak hadkan akses private video by IP + global CDN delivery. Pre-Signed URL boleh?

⚠ Umpan: Pre-Signed URL dengan IP restriction — sangka boleh letak syarat IP.

✓ Betul: CloudFront Signed URL/Cookie. Pre-Signed URL HANYA boleh expiry time, tak boleh restrict IP/geo. Keyword: 'IP restriction' + 'CDN' → CloudFront.

🧠 Cara Mudah Ingat

→Pre-Signed URL = IAM credentials yang GENERATE URL menentukan permission. Kalau generator ada s3:GetObject permission → URL holder boleh download.
→Expiry: default 7 hari (bila guna SDK), boleh set dari 1 saat hingga 7 hari maksima. Bila expired → 403 Forbidden.
→Pre-signed URL BOLEH guna untuk PUT juga — bukan hanya GET. Generate PUT pre-signed URL untuk allow upload tanpa credentials.
→Pre-signed URL TAK boleh restrict by IP — itu hanya CloudFront Signed URL. Pre-signed = expiry time sahaja.
→Bila guna STS temporary credentials untuk generate → URL expiry TIDAK boleh melebihi credential expiry. Yang lebih pendek menang.
→Exam: "give temporary access to download S3 object, no AWS account needed" → Pre-Signed URL. "private content via CDN with IP restriction" → CloudFront Signed URL.

Guna Bila

Grant temporary time-limited access to a single S3 object without sharing credentials

presigned URLtemporary accessno credentialsIAM credentialsexpiry timedownloaduploadPUTGET403one objectvs CloudFront signed URL

📎 S3 pre-signed URLs