Design Secure Architectures

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

DOMAIN 1 · 30% OF EXAM

Design Secure Architectures

IAM & Identity · Network Security · Data Protection · Connectivity

🔑IAM & Identity↑ Top

D1 · Secure

IAM

AWS Identity and Access Management

"Siapa boleh buat apa dalam AWS"

🎯 Sebab Apa Wujud

IAM wujud sebab tanpa dia, semua orang yang ada akses akaun = root (boleh buat APA SAJA — padam DB, buka bil ribu dollar). IAM bagi kau pecahkan akses ikut "least privilege" — setiap user/app dapat HANYA apa yang dia perlu. Dan Role wujud khas untuk selesaikan masalah besar: macam mana app dalam EC2/Lambda nak akses S3 tanpa kita HARDCODE access key dalam code (yang nanti bocor masuk GitHub)? Jawapan: attach Role → app dapat temp creds auto-expire, takde rahsia tersimpan.

Apa Dia

Mengurus identiti dan akses kepada perkhidmatan dan sumber AWS dengan policies

Contoh Guna

Create IAM Role untuk EC2 boleh read S3 — attach role ke EC2, bukan hardcode credentials dalam code

IAM — komponen utama

Principal → entiti yang hantar request (User, Role, atau AWS service). Hanya Principal boleh "buat" sesuatu

User → identiti KEKAL untuk 1 orang/app. Ada credentials sendiri (password + access keys long-term)

Group → bakul untuk kumpul Users. BUKAN identity — tak boleh login, tak boleh jadi Principal. Attach policy kat sini (best practice)

Role → identiti SEMENTARA yang di-assume. Tiada long-term creds — dapat temp creds via STS yang auto-expire

Policy → JSON Allow/Deny. Identity-based (attach kat User/Group/Role) atau Resource-based (attach kat S3/SQS/KMS)

Permission Boundary → siling MAKSIMUM permission untuk satu entity (had, bukan bagi)

MFA → faktor kedua (app/hardware token) selain password

Policy evaluation — request DIBENARKAN atau DITOLAK? (decision tree)

Rendering diagram…

Urutan: (1) Explicit DENY mana-mana policy → terus DENIED. (2) Guardrail (SCP/Boundary/Session) mesti BENARKAN — ini intersection, hanya boleh SEKAT. (3) Mesti ada explicit ALLOW dalam identity ATAU resource policy (union). (4) Kalau tiada allow → implicit deny. INGAT exam: explicit Deny > guardrail > explicit Allow > implicit Deny. Allow + Deny pada action sama = DENIED.

Analogi — IAM = sekuriti bangunan pejabat

Rendering diagram…

User = staf tetap dengan kad akses sendiri (long-term creds). Group = jabatan — kumpul staf & bagi kebenaran pintu sekali gus (attach policy kat Group). Role = pas pelawat sementara — sesiapa boleh pinjam & auto-luput (temp creds, no hardcode). Policy = senarai pintu mana boleh buka. Permission Boundary = aras tertinggi lif dibenarkan, walau kad kata boleh ke penthouse. INGAT exam: app dalam EC2 = bagi ia "pas pelawat" (Role), JANGAN salin kad staf masuk kod (hardcode access key).

4 lapisan permission — mana PAGAR (sekat), mana PEMBERI (bagi)

Rendering diagram…

Dua keluarga: PEMBERI (Identity + Resource — union, satu Allow dah cukup, dan Resource-based boleh bagi cross-account TANPA assume role) duduk DI DALAM tiga PAGAR (SCP siling account → Permission Boundary siling entity → Session policy siling sesi — intersection, SEMUA mesti benarkan, tak pernah BAGI). INGAT exam: pagar (SCP/Boundary/Session) HANYA sekat, tak boleh grant; explicit DENY tembus semua lapisan. Susunan menang: explicit Deny > pagar > explicit Allow > implicit Deny.

Cross-account: Resource-based policy ATAU Role + AssumeRole?

Rendering diagram…

Dua-dua SAH untuk cross-account. Akses langsung & kemas ke satu service (S3/SQS/SNS/KMS) → Resource-based policy (ingat Dua Kunci: IAM source + resource policy destination). Perlu set permission kompleks / temp credentials / sentuh banyak service → IAM Role + AssumeRole. INGAT exam: "org luar nak read S3 / send to SQS" → resource-based policy; "assume identity & dapat temp creds merentas account" → Role + STS.

IAM User vs Group vs Role (jangan keliru)

Aspect	IAM User	IAM Group	IAM Role
Apa dia	Identiti KEKAL untuk 1 orang/app	Bakul kumpul Users	Identiti SEMENTARA yang di-assume
Credentials	Password + access keys (long-term)	❌ Tiada (bukan identity)	Temp creds via STS (auto-expire)
Boleh login / jadi Principal?	🟢 Ya	❌ Tidak	Di-assume, bukan login terus
Attach policy?	Boleh (tapi elak)	🟢 Ya (cara terbaik)	🟢 Ya
Guna bila	Manusia / app tetap	Urus permission ramai user sekali gus	EC2 · Lambda · cross-account · federation

Ingat: Group BUKAN identity — tak boleh login, tak boleh jadi Principal, cuma alat urus permission. Role = tiada long-term creds, sentiasa pilihan untuk EC2/Lambda/cross-account/federation. Hardcode access key dalam EC2 = SALAH → guna Role.

Jenis Policy — mana boleh BAGI akses, mana cuma HAD

Jenis Policy	Attach kat	Fungsi	Boleh GRANT?
Identity-based	User / Group / Role	Apa identiti ni boleh buat	🟢 Ya
Resource-based	Resource (S3/SQS/KMS)	Siapa boleh akses resource ni	🟢 Ya (+ cross-account tanpa assume role)
SCP (Organizations)	OU / Account	Siling maksimum untuk account	❌ Tak — hanya SEKAT
Permission Boundary	User / Role	Siling maksimum untuk satu entity	❌ Tak — hanya SEKAT
Session Policy	Masa AssumeRole	Sekat lagi permission sesi tu	❌ Tak — hanya SEKAT

Ingat: Identity & Resource policy = boleh BAGI akses (union — allow mana-mana satu cukup). SCP/Boundary/Session = guardrail, hanya boleh SEKAT (intersection — semua mesti allow). Resource-based policy boleh bagi cross-account access TANPA assume role. Explicit deny dalam mana-mana satu menang atas semua.

Cross-Account "Dua Kunci" — kedua-dua belah WAJIB allow

Senario	Kunci 1 — Source Account	Kunci 2 — Destination / HQ	Logik
S3 cross-account	IAM policy bagi user/role s3:PutObject	S3 Bucket Policy (resource-based) sebut Principal = Source acct	🟢 IAM AND Bucket Policy
SQS cross-account	IAM policy bagi sqs:SendMessage	SQS Queue Policy (resource-based) sebut Principal = Source acct	🟢 IAM AND Queue Policy
KMS decrypt cross-account	IAM policy bagi kms:Decrypt	KMS Key Policy (resource-based) sebut Principal = Source acct	🟢 IAM AND Key Policy
Akaun anak bawah Organizations	IAM policy dalam member account	SCP di OU/Management = siling maksimum	🟢 IAM AND SCP (intersection)

Ingat: Cross-account = sistem DOUBLE-CHECK: dua-dua pintu kena buka. Set satu belah je → BLOCKED. S3/SQS/KMS: IAM (source) + Resource-based policy (destination, ada Principal). Member account: IAM + SCP. Pangkah mana-mana jawapan exam yang kata "set IAM sahaja" atau "set resource policy sahaja". Resource-based policy = satu-satunya yang boleh bagi cross-account TANPA assume role.

ABAC vs RBAC — mana scale bila projek/team makin banyak

Aspect	RBAC (role/policy-based)	ABAC (tag-based)
Asas keputusan	Identiti/role ada policy spesifik	Padanan TAG (aws:PrincipalTag = aws:ResourceTag)
Projek/team baru	Tulis policy / role BARU tiap kali	🟢 Cuma tag — guna policy SEDIA ADA
Bilangan policy	Membesar ikut bilangan team (ratusan)	🟢 Sikit & tetap (satu policy guna conditions)
Scale	Penat & meletup bila banyak projek	🟢 Scale automatik
Guna bila	Sikit role, struktur stabil	Banyak projek/team, fast-growing, multi-tenant
Keyword exam	"distinct roles, small set"	"scale without new policy per project/team / tag-based"

Ingat: RBAC = satu policy per peranan (membesar ikut bilangan team). ABAC = satu policy yang padan TAG principal dengan TAG resource — projek baru cuma perlu tag, tak perlu policy baru. Keyword "scale permissions across many projects/teams without writing a new policy each time" / "tag-based access" → ABAC. "few well-defined roles" → RBAC.

⚡ Quick Sifir — hafal ni

▪Explicit DENY menang atas SEMUA — Allow + Deny pada action sama = DENIED
▪Identity & Resource policy = boleh BAGI akses (union). SCP / Permission Boundary / Session = guardrail, hanya boleh SEKAT (intersection), tak boleh bagi
▪EC2/Lambda akses AWS service → IAM Role, BUKAN hardcode access keys
▪Group = bakul untuk Users, BUKAN identity — tak boleh login, tak boleh jadi Principal
▪User/Group = permanent creds. Role = temp creds (STS, auto-expire)
▪Default = implicit DENY. Kena ada explicit Allow baru boleh buat
▪Baca policy macam ayat: Principal=SIAPA · Action=NAK BUAT APA · Resource=DEKAT MANA · Effect=BOLEH/TAK · Condition=BILA
▪"Principal":"*" dalam resource policy = SESIAPA (anonymous/public) boleh akses — ni punca #1 S3 bucket bocor. Identity-based policy TAKDE Principal (dah tau siapa); resource-based WAJIB ada Principal
▪Cross-account S3/SQS/KMS = DUA kunci: IAM policy (source acct) AND resource-based policy yang ada Principal (destination acct). Satu belah je → Access Denied. Member account → IAM + SCP

💡 Exam Scenario

"App dalam EC2 perlu akses S3" → IAM Role (BUKAN hardcode access keys). "Account A akses resource Account B" → assume Role cross-account ATAU resource-based policy. "Hadkan permission MAKSIMUM developer walau admin bagi lebih" → Permissions Boundary. "Sekat semua account dalam OU dari guna region tertentu" → SCP. "Explicit Deny + Allow pada action sama" → DENIED. "User luar login Google/Facebook nak akses" → Cognito/federation (BUKAN cipta IAM user). Keywords: least privilege, temporary credentials, cross-account, explicit deny, permission boundary.

🪤 Perangkap Soalan

Q: Sebuah application berjalan dalam EC2 perlu read/write objek dalam S3 bucket. Cara PALING SELAMAT untuk bagi akses?

⚠ Umpan: Create IAM User, generate access key + secret key, simpan dalam environment variable / config file aplikasi tu. Nampak senang sebab access key memang cara biasa app authenticate.

✓ Betul: Attach IAM Role kepada EC2 instance (instance profile). Keyword "running on EC2 / running on AWS compute" → Role, BUKAN access keys. Access key dalam code/config = long-term secret yang boleh bocor; Role bagi temp creds auto-rotate.

Q: Satu SCP pada OU ada Allow untuk S3, tapi IAM policy user tu takde sebut S3 langsung. User boleh akses S3?

⚠ Umpan: Boleh — SCP dah Allow S3, jadi user dapat akses. Nampak logik sebab SCP "bagi" permission.

✓ Betul: TAK BOLEH. SCP cuma guardrail — ia SEKAT, tak pernah BAGI. User masih perlu explicit Allow dalam IAM (identity) atau resource policy. SCP Allow cuma maksud "tak disekat di peringkat OU", bukan "dibenarkan". Keyword: SCP/Boundary = had maksimum, bukan pemberi akses.

Q: Security audit jumpa satu S3 bucket policy ada "Principal": "*" dengan Effect Allow untuk s3:GetObject. Apa maksud & risiko?

⚠ Umpan: "*" tu wildcard untuk semua IAM user dalam account aku je — selamat sebab orang luar account tetap kena ada IAM creds. Nampak munasabah sebab "*" selalu maksud "semua dalam scope".

✓ Betul: BAHAYA — "Principal": "*" dalam resource-based policy = SESIAPA di internet (anonymous, tanpa login) boleh akses. Ni punca #1 S3 data leak. Keyword "Principal":"*" + public/anonymous = buang atau ganti dengan ARN spesifik + Block Public Access ON. (Nota: identity-based policy TAKDE Principal langsung — dah tahu siapa.)

Q: App dalam Account A (Dev) nak hantar mesej ke SQS queue dalam Account B (Prod). Admin dah set IAM policy dalam Account A bagi sqs:SendMessage, tapi masih "Access Denied". Kenapa?

⚠ Umpan: IAM policy dah ada kat source, patutnya cukup. Orang ingat satu belah (IAM) dah memadai sebab itu cara biasa bagi izin dalam-account.

✓ Betul: Cross-account = WAJIB DUA kunci: IAM policy (source acct) AND resource-based policy pada queue (destination acct). SQS Queue Policy belum sebut Principal Account A → ditolak. Keyword "cross-account S3/SQS/KMS" → IAM Policy + Resource-based policy serentak; set satu belah je = SALAH. (Sama logik: member account = IAM + SCP.)

Q: Syarikat ada 200+ projek, tiap projek ada team & resource sendiri (EC2, S3) yang ditag Project=X. Bila projek baru lahir, team kena akses HANYA resource projek dia. Admin penat tulis IAM policy baru tiap kali projek lahir. Cara paling scalable?

⚠ Umpan: Buat satu IAM Group + policy per projek (RBAC), tambah policy baru bila projek baru lahir. Nampak betul sebab Group memang cara urus permission. SALAH: 200 projek = 200 policy, projek ke-201 lahir → tulis policy lagi. Tak scale, meletup bila projek makin banyak.

✓ Betul: ABAC (Attribute-Based Access Control) — tag user/role dengan Project=X, tag resource dengan Project=X, tulis SATU policy guna kondisi aws:PrincipalTag/Project = aws:ResourceTag/Project. Projek baru? Cuma tag — TAK perlu policy baru. Keyword "scale permissions across many teams/projects without writing new policy each time" → ABAC, BUKAN RBAC (role/policy per kumpulan).

Q: Syarikat nak benarkan developer cipta IAM role sendiri untuk Lambda mereka (self-service), TAPI takut developer bagi role tu AdministratorAccess (privilege escalation). Macam mana benarkan create role tapi cap kuasa maksimum?

⚠ Umpan: Bagi developer kuasa iam:CreateRole je, kemudian audit manual lepas tu / harap mereka tak silap. Atau guna SCP. Nampak betul sebab "had kuasa". SALAH: tanpa cap, developer boleh attach AdministratorAccess pada role ciptaan dia → escalate. SCP pula apply ke SELURUH account, bukan cap role ciptaan developer secara spesifik.

✓ Betul: Permissions Boundary — attach managed policy sebagai boundary, dan guna IAM condition (iam:PermissionsBoundary) supaya developer WAJIB attach boundary tu pada mana-mana role dia cipta. Role ciptaan tak boleh lebih kuasa dari boundary, walau policy kata Admin. Keyword "delegate role/permission creation safely / cap max permission of created entities" → Permissions Boundary, BUKAN SCP (itu siling account), BUKAN audit manual.

Q: Kau bagi satu AWS service (cth SNS / CloudWatch / SES) satu role untuk akses bucket S3 kau. Tapi kau risau service tu "tertipu" hantar data ke / baca dari bucket pihak ketiga yang menyamar guna ARN kau. Macam mana halang silap-pegang merentas-service ni (Confused Deputy)?

⚠ Umpan: Buat role berasingan untuk tiap pemanggil, atau harap ARN je dah cukup unik. Nampak betul sebab "asingkan role". SALAH: tanpa syarat, AWS service (si deputy) boleh diperdaya guna kuasa kau bagi pihak ketiga — ARN sahaja tak buktikan SIAPA account yang betul-betul memanggil.

✓ Betul: Confused Deputy protection — dalam ROLE TRUST POLICY, tambah condition aws:SourceArn (resource spesifik yang dibenarkan trigger) dan/atau aws:SourceAccount (account ID yang dibenarkan). Service cuma boleh assume role bila request betul-betul datang dari ARN/account kau. Keyword "prevent confused deputy / cross-service impersonation / restrict which account/resource can use this role" → aws:SourceArn + aws:SourceAccount dalam trust policy.

🧠 Cara Mudah Ingat

→IAM Principals: entity yang boleh buat request kat AWS — Users (individu), Groups (kumpulan users), atau Roles (identity sementara yang boleh di-assume)
→Users & Groups = permanent identities — perlu credentials (password untuk console, access keys untuk CLI) untuk login. Roles = temporary identities — bagi short-lived credentials yang di-assume oleh Users/Applications, tak perlu hardcode long-term credentials
→IAM Policy: JSON document yang define Allow/Deny untuk action tertentu pada resource tertentu — attach kat User/Group/Role
→Multi-Factor Authentication (MFA): extra layer security — selain password, perlu code dari device (app/hardware token) untuk login
→Account best practices: (1) JANGAN guna ROOT user untuk daily tasks — ROOT hanya untuk tasks yang memang require ROOT (billing, close account, dll). (2) Create Administrative User untuk daily admin tasks. (3) Enable MFA untuk ROOT & semua Users. (4) Add Users ke Groups, assign permissions kat Group — bukan standalone kat User
→Identity Federation: user luar AWS (corporate AD, Google, Facebook) dapat temporary access AWS resources tanpa IAM user baru — guna SAML/OIDC/STS
→Policy evaluation logic: (1) Bila User baru created, semua request implicitly DENIED by default (kecuali ROOT). (2) Explicit Allow dalam Identity-based atau Resource-based Policy overrides implicit Deny tu. (3) Tapi explicit Deny SENTIASA override explicit Allow — Allow + Deny dalam policy = DENIED. (4) Permission Boundary, SCP, atau Session Policy boleh override (restrict) Allow dengan implicit Deny mereka sendiri — even kalau IAM Policy bagi Allow
→IAM Role types: (1) Service Role — role yang AWS service assume untuk buat actions on behalf of User (cth: Lambda execution role). (2) Service Role for EC2 — application dalam EC2 assume role ni untuk access resource lain (cth: S3) tanpa hardcode credentials. (3) Service-Linked Role — AWS Managed role yang predefined & linked terus ke satu service, permissions tak boleh edit oleh User. (4) Role Chaining — assume satu role, lepas tu guna credentials tu untuk assume role lain (cth: cross-account role → read-only role untuk S3)
→Exam: "Which is NOT a feature of IAM?" → "IAM Resource" is the trick option. Resource = target YANG DIKAWAL aksesnya oleh IAM (cth: S3 bucket, EC2), bukan komponen/feature IAM itu sendiri
→Confused Deputy: bila kau bagi satu AWS service (deputy) kuasa akses resource kau, pihak ketiga boleh perdaya service tu guna kuasa kau. Lindung dengan condition aws:SourceArn (resource spesifik) + aws:SourceAccount (account ID) dalam ROLE TRUST POLICY → service cuma assume role bila request betul-betul dari ARN/account kau. Keyword "cross-service confused deputy" → aws:SourceArn/aws:SourceAccount
→Least-privilege tooling — Credential Report: CSV semua IAM users + status credential (password age, access key age/last-used, MFA on/tak) → audit & buang creds lapuk, satu account satu report. Access Advisor (Last Accessed): tab pada user/role/group/policy yang tunjuk service mana TERAKHIR diakses & bila → buang permission yang tak pernah dipakai. Keyword "identify unused permissions / which services has this role actually used / audit stale credentials" → Access Advisor (last accessed) + Credential Report
→PRICING: IAM sendiri PERCUMA (users, groups, roles, policies, Credential Report, Access Advisor, MFA semua tiada caj). Bayar hanya resource AWS yang diakses. (IAM Access Analyzer External = free; Unused Access = bayar per resource.)
→Least-privilege pattern (critical vs non-critical): critical resources → assign permission ke IAM Role, user ASSUME role on-demand bila perlu (selepas siap switch balik → kecilkan attack surface); non-critical → guna regular credentials harian. Bukan cipta user ID berasingan (kena urus banyak credential), bukan full access, bukan resource-based policy je (BUKAN semua resource support). Exam: "least privilege + critical on required basis + non-critical daily" → Role untuk critical, assume on-demand.

Guna Bila

Control who can access what AWS resources

usersgroupsrolespoliciesleast privilegeMFAprincipalsidentity federationIAM RoleIAM UserIAM Groupidentity-based policyresource-based policypermission boundarySCPexplicit denyimplicit denypolicy evaluationservice-linked rolerole chainingsession policycross-account accessPrincipalPrincipal *anonymous accesspublic accesspolicy anatomyEffect Action Resourcesource accountdestination accounttwo keysdouble-checkbucket policyqueue policykey policyABACRBACattribute-based access controltag-based accessaws:PrincipalTagaws:ResourceTagscale permissionspermissions boundary delegateiam:PermissionsBoundaryprivilege escalationdelegate role creationconfused deputyaws:SourceArnaws:SourceAccountcross-servicetrust policy conditioncredential reportaccess advisorlast accessedunused permissionsstale credentialspricing

📎 IAM policy evaluation logic 📎 Security best practices in IAM 📎 Confused deputy problem (cross-service)📎 Credential reports & last accessed

D1 · Secure

STS

AWS Security Token Service

"Pinjam IC sementara — short-lived credentials, auto-expire"

🎯 Sebab Apa Wujud

Wujud sebab hardcode long-term access key dalam app/script = bom jangka — kalau bocor, penyerang boleh guna selama-lamanya sampai kau rotate manual. STS bagi credentials SEMENTARA yang auto-expire (15 min sampai 12 jam), jadi walaupun bocor, ia mati sendiri. Dan untuk cross-account access, kau tak perlu cipta IAM user di setiap account — cukup AssumeRole ke role di account lain dan dapat temp creds.

Apa Dia

Bagi short-lived credentials (access key + secret key + session token) yang auto-expire. Pilih API ikut SIAPA yang minta: AssumeRole (cross-account / EC2 role), AssumeRoleWithSAML (enterprise AD/SAML), AssumeRoleWithWebIdentity (Google/Facebook/Cognito/OIDC). Tak perlu cipta IAM user baru.

Contoh Guna

App dalam Account A nak akses S3 dalam Account B — AssumeRole ke role dalam B, dapat temp credentials, tak perlu hardcode long-term keys

Analogi — Kaunter Pengawal cetak Pas Pelawat sementara (AssumeRole)

Rendering diagram…

Kaitkan dengan familiar: STS = kaunter pengawal yang cetak Pas Pelawat plastik. Pengawal semak buku peraturan (Trust Policy) dulu, baru cetak pas. Pas tu (1) buka pintu tertentu je (role permission), (2) mati sendiri lepas jam tutup (auto-expire). INGAT exam: "temporary credentials / short-term access / cross-account tanpa hardcode key" → STS AssumeRole; pas TAK kekal, jadi walau bocor pun mati sendiri.

STS API — pilih ikut SIAPA yang call

API	Siapa boleh call	Guna bila	Lifetime
AssumeRole	IAM user / role sedia ada	Cross-account access ATAU role chaining dalam AWS	15 min → max session (default 1 jam)
AssumeRoleWithSAML	User yang dah authenticate via SAML 2.0 IdP	Enterprise federation — corporate AD / ADFS / Okta	15 min → max session (default 1 jam)
AssumeRoleWithWebIdentity	User yang login via OIDC (Google, Facebook, Amazon, Cognito)	Web/mobile app — public identity federation	15 min → max session (default 1 jam)
GetSessionToken	IAM user / root	Hardened MFA-protected temp creds untuk user yang sama	15 min → 36 jam (default 12 jam)
GetFederationToken	IAM user / root	Custom identity broker bagi creds kat federated user (no role)	15 min → 36 jam (default 12 jam)

Ingat: Cross-account / EC2 / chaining → AssumeRole. SAML enterprise IdP → AssumeRoleWithSAML. Public social/OIDC login → AssumeRoleWithWebIdentity. Cognito Identity Pool guna AssumeRoleWithWebIdentity bawah hood.

⚡ Quick Sifir — hafal ni

▪STS = TEMPORARY credentials, auto-expire (15 min → max session role)
▪Cross-account / EC2 role / role chaining → AssumeRole
▪Enterprise SAML/AD IdP → AssumeRoleWithSAML
▪Public login Google/Facebook/Cognito (OIDC) → AssumeRoleWithWebIdentity
▪Role chaining = sesi auto-cap 1 jam (DurationSeconds > 1 jam akan gagal)
▪Session policy = SEKAT lagi (intersection), tak boleh TAMBAH permission lebih dari role

🪤 Perangkap Soalan

Q: Mobile app perlu user login guna akaun Google, lepas tu app nak akses S3 & DynamoDB terus dari device. Macam mana bagi temp AWS credentials dengan selamat?

⚠ Umpan: Cipta IAM user untuk app + embed access key dalam app. Nampak senang sebab terus boleh sign API call. SALAH: access key dalam app mobile = bocor terus (boleh decompile), dan ia long-term tak expire.

✓ Betul: STS AssumeRoleWithWebIdentity (selalu via Cognito Identity Pool). Keyword 'login Google/Facebook + temp AWS creds untuk mobile' = web identity federation, BUKAN IAM user access key.

Q: App dalam Account A perlu baca S3 bucket dalam Account B sekali-sekala. Cara paling selamat?

⚠ Umpan: Buat IAM user dalam Account B, share access key ke Account A. Nampak betul sebab terus dapat akses. SALAH: long-term key kongsi merentas account = susah audit + rotate, dan kekal hidup kalau bocor.

✓ Betul: Buat IAM role dalam Account B, Account A panggil STS AssumeRole ke role tu → dapat temp creds yang auto-expire. Keyword 'cross-account access' = AssumeRole.

🧠 Cara Mudah Ingat

→Semua AssumeRole* return temp creds dengan lifetime 15 min sampai "maximum session duration" role tu (default 1 jam, boleh set sampai 12 jam). DurationSeconds tak boleh exceed setting role
→Role chaining = guna temp creds dari satu AssumeRole untuk AssumeRole lagi sekali. Bila chain, sesi di-cap kepada 1 jam — DurationSeconds > 1 jam akan gagal
→Session policy: pass policy masa AssumeRole untuk SEKAT lagi permissions sesi tu (effective = intersection role policy ∩ session policy). Tak boleh tambah permissions melebihi role
→STS endpoint: ada global endpoint + Regional endpoints. Guna Regional endpoint untuk kurangkan latency dan teruskan operasi kalau satu Region down
→Exam: "app dalam account lain perlu akses resource saya buat sementara" → AssumeRole (cross-account). "corporate AD users perlu akses AWS" → AssumeRoleWithSAML. "mobile app users login Google/Facebook nak temp AWS creds" → AssumeRoleWithWebIdentity (atau Cognito Identity Pool yang panggil ia)
→Exam trap: STS = TEMPORARY credentials yang AUTO-EXPIRE. Kalau soalan minta elak hardcode long-term access keys / rotate manual → STS roles, bukan IAM user access keys

Guna Bila

Generate temporary security credentials

temporary credentialsAssumeRoleAssumeRoleWithSAMLAssumeRoleWithWebIdentityGetSessionTokenGetFederationTokencross-accountrole chainingsession policyfederationauto-expire

📎 Compare AWS STS credentials

D1 · Secure

Directory Service

AWS Directory Service

"Active Directory dalam AWS — tiga jenis, pilih ikut use case"

🎯 Sebab Apa Wujud

Wujud sebab banyak syarikat dah ada Active Directory on-prem (uruskan user Windows, Group Policy, login domain) dan bila pindah workload ke AWS, mereka tak nak buang AD tu atau cipta sistem user baru. Directory Service bagi AWS "cakap bahasa AD" — EC2 Windows boleh join domain, app boleh authenticate guna AD sedia ada. Tiga rasa: bawa AD penuh ke cloud (Managed Microsoft AD), kekalkan AD on-prem & cuma proxy (AD Connector), atau AD ringkas murah untuk workload kecil (Simple AD).

Apa Dia

AWS Directory Service ada tiga pilihan: (1) AWS Managed Microsoft AD — full AD dalam AWS. (2) AD Connector — proxy ke on-premises AD. (3) Simple AD — Samba-based, lightweight, bukan full AD.

Pilih Directory Service mana?

Rendering diagram…

INGAT exam: data AD TAK boleh masuk cloud → AD Connector. Full AD/trust/RDS-M365 → Managed Microsoft AD. Kecil & murah → Simple AD. User external → Cognito (bukan Directory Service).

Managed Microsoft AD vs AD Connector vs Simple AD

Aspect	Managed Microsoft AD	AD Connector	Simple AD
Apa dia	🟢 Real Microsoft AD dalam AWS	Proxy/redirect ke on-prem AD	Samba 4 — AD-compatible, BUKAN real AD
Directory ada kat mana	Dalam AWS (managed by AWS)	Kekal on-premises (tiada dalam cloud)	Dalam AWS (standalone)
Trust ke on-prem AD	🟢 Ya (one-way / two-way)	N/A — guna terus on-prem AD	❌ Tiada trust
Group Policy / Kerberos / LDAP	🟢 Penuh	Guna feature on-prem AD	Asas sahaja (subset)
Guna bila	Perlu full AD features dalam AWS, atau migrate AD	Dah ada on-prem AD, tak nak replicate ke cloud	Workload kecil, basic AD features, no on-prem

Ingat: Full AD dalam cloud / ada trust → Managed Microsoft AD. AD kekal on-prem, AWS cuma proxy auth → AD Connector. Kecil + murah + basic → Simple AD. (User external Google/Facebook → Cognito, bukan Directory Service.)

⚡ Quick Sifir — hafal ni

▪Full AD dalam cloud / perlu trust ke on-prem → Managed Microsoft AD
▪AD KEKAL on-prem, AWS cuma proxy auth (data tak masuk cloud) → AD Connector
▪Kecil + murah + basic LDAP/Kerberos, no on-prem → Simple AD
▪User external (Google/Facebook) → Cognito, BUKAN Directory Service
▪SSO ke banyak AWS account guna AD → IAM Identity Center + Managed Microsoft AD

🪤 Perangkap Soalan

Q: Syarikat ada on-prem Active Directory dan nak EC2 dalam AWS authenticate guna AD tu, TAPI dasar keselamatan TAK BENARKAN sebarang directory data disimpan/replicate dalam cloud. Pilih apa?

⚠ Umpan: AWS Managed Microsoft AD dengan two-way trust ke on-prem AD. Nampak betul sebab dia "managed AD" dan boleh trust on-prem.

✓ Betul: AD Connector. Ia cuma PROXY/redirect request authentication ke on-prem AD — tiada directory data disimpan dalam cloud. Managed Microsoft AD sebenarnya cipta directory DALAM AWS (langgar dasar "no data in cloud"). Keyword "AD stays on-prem / no directory data in cloud" → AD Connector.

🧠 Cara Mudah Ingat

→AWS Managed Microsoft AD: full Microsoft AD dalam AWS. Untuk apps yang perlukan actual AD features (Group Policy, Kerberos, LDAP). Boleh trust ke on-premises AD
→AD Connector: BUKAN AD dalam cloud — ia redirect authentication requests ke on-premises AD. Data tetap on-prem. Untuk existing on-prem AD yang tak nak migrate
→Simple AD: Samba-based, basic AD features, standalone (no trust ke on-prem). Untuk simple Linux/Windows workloads yang perlukan basic LDAP/Kerberos
→IAM Identity Center + AWS Managed Microsoft AD = SSO untuk AWS + SaaS apps dengan full AD features
→Exam: "join EC2 to existing on-premises domain, AD stays on-prem" → AD Connector. "Full AD in cloud, migrate off-prem" → AWS Managed Microsoft AD
→Exam: "users all WITHIN AWS, need FULL AD features" → AWS Managed Microsoft AD. "users all WITHIN AWS, need BASIC AD features" → Simple AD. "users on-premises, authenticate to Cloud Native apps using existing on-prem directory" → AD Connector. "users are external (Facebook/Google), no AD needed" → Cognito User Pools (bukan Directory Service)
→PRICING: Managed Microsoft AD ~$0.40/jam (Standard) / ~$0.60/jam (Enterprise) — billing per jam, sentiasa ON. AD Connector ~$0.05/jam (Small) — paling murah sebab takde directory dalam cloud. Simple AD ~$0.05/jam (Small). Cost discriminator: dah ada on-prem AD → AD Connector jimat (tak duplicate directory).

Guna Bila

Managed Microsoft Active Directory, AD Connector, or Simple AD for AWS workloads

Active DirectoryManaged Microsoft ADAD ConnectorSimple ADLDAPKerberosGroup Policyon-premises ADpricing

📎 AWS Directory Service options 📎 AD Connector

D1 · Secure

IAM Identity Center

AWS IAM Identity Center (SSO)

"Satu login, semua AWS accounts"

🎯 Sebab Apa Wujud

Wujud sebab bila syarikat ada banyak AWS account (Organizations), buat IAM user dalam SETIAP account = mimpi ngeri: 50 staff × 10 account = 500 user nak urus, 500 password, susah revoke bila staff resign. IAM Identity Center bagi satu identity (dari corporate AD/Okta/Entra) → assign sekali → staff masuk semua account yang dibenarkan dengan temporary creds. Bila staff keluar, matikan SATU identity, terus hilang akses semua account. Tujuan: central workforce access + temp creds + tak payah IAM user per-account.

Apa Dia

Membolehkan pengguna login sekali dan access multiple AWS accounts dan business applications

Contoh Guna

Staff login dengan corporate email (Microsoft AD / Okta), dapat access semua 10 AWS accounts yang dibenarkan tanpa login semula

IAM Identity Center — anatomy

Identity source → dari mana user datang: built-in directory, AWS Managed Microsoft AD, atau external IdP (Okta, Entra ID/Azure AD) via SAML 2.0.

Permission Set → koleksi IAM policies (macam "role template") yang define apa user boleh buat. Contoh: AdministratorAccess, ReadOnly, atau custom. Permission set ni dirender jadi IAM role dalam tiap assigned account.

Account assignment → map (User/Group) × (Permission Set) × (AWS Account). Ni yang tentukan siapa boleh masuk account mana dengan kebenaran apa.

Access portal → satu URL login; user nampak semua accounts + roles yang dia boleh masuk. Creds yang dikeluarkan TEMPORARY (auto-expire via STS).

Satu badge → banyak account (corporate access card)

Rendering diagram…

Satu identity → permission set (template kebenaran) → assign ke banyak account; creds temporary, auto-expire hujung session. Lawan plain IAM users = buat kunci berasingan untuk setiap pintu setiap cawangan. INGAT exam: "workforce SSO across many accounts + temporary creds" → IAM Identity Center.

Plain IAM Users vs IAM Identity Center (SSO)

Aspect	Plain IAM Users	IAM Identity Center
Credentials	Per-account, per-user (banyak password)	🟢 Satu identity → semua accounts
Skala multi-account	Susah — create user tiap account	🟢 Central — assign permission set ke accounts
Access keys	Long-term (kekal sampai di-rotate)	🟢 Temporary (auto-expire via STS)
Sumber identity	IAM directory sahaja	Built-in / Managed AD / external IdP (Okta, Entra)
SaaS SSO (Salesforce, M365)	❌	🟢 Ya (SAML 2.0)
Guna bila	1 account, sikit user, programmatic/service	Banyak account (Organizations), workforce SSO

Ingat: Satu account + service/programmatic access → IAM users/roles. Banyak AWS accounts + ramai staff + nak central SSO + temporary creds → IAM Identity Center. Exam: "centrally manage workforce access across many accounts" → IAM Identity Center, BUKAN create IAM users tiap account.

⚡ Quick Sifir — hafal ni

▪"Workforce SSO across many accounts" → IAM Identity Center, BUKAN IAM user per account
▪Permission Set = role template → render jadi IAM role dalam tiap assigned account
▪Creds yang dikeluarkan TEMPORARY (auto-expire via STS), bukan long-term access key
▪Identity source: built-in / Managed Microsoft AD / external IdP (Okta, Entra) via SAML 2.0
▪SSO ke SaaS (Salesforce, M365) → IAM Identity Center. Public social login → Cognito
▪IAM Identity Center = FREE (bayar Managed AD je kalau guna sebagai source)

🪤 Perangkap Soalan

Q: Syarikat ada 15 AWS account dalam Organizations dan nak staff guna corporate credentials sedia ada untuk akses account yang dibenarkan, dengan central management. Cara terbaik?

⚠ Umpan: Cipta IAM user dalam setiap account untuk setiap staff, kumpulkan dalam Group dan attach policy. Nampak betul sebab IAM user memang cara login standard.

✓ Betul: AWS IAM Identity Center disambung ke corporate IdP. Buat IAM user per-account = ratusan user, susah urus & revoke, dan guna long-term creds. Identity Center = satu identity, central assignment, temp creds. Keyword "many accounts + workforce + central + existing corporate credentials" → IAM Identity Center.

🧠 Cara Mudah Ingat

→IAM Identity Center + SAML 2.0: untuk SSO dari on-premises Active Directory ke AWS + third-party SaaS (Salesforce, etc.)
→SAML 2.0 IAM roles alone (tanpa Identity Center) = tak ada SSO portal, tak integrate SaaS apps
→Web identity federation = untuk PUBLIC providers (Google, Amazon, Facebook) — bukan enterprise AD
→Exam: "on-premises AD + SSO to AWS + SaaS apps" → IAM Identity Center with SAML 2.0
→IAM Identity Center features: (1) Multi-account access — centralized access ke multiple AWS accounts dalam Organization, elak repeat config Users per account. (2) SSO ke AWS applications — satu login, tak payah ingat password berasingan. (3) SSO ke Cloud-based/SaaS apps (Salesforce, Microsoft 365) via SAML 2.0. (4) SSO ke EC2 — TAPI khusus untuk EC2 WINDOWS instances (via Fleet Manager, guna existing corporate credentials, elak share admin RDP credentials) — BUKAN Linux
→Permission Set = "role template" — koleksi IAM policies yang Identity Center render jadi IAM role dalam setiap assigned account. Tukar permission set sekali → apply merentas semua account. Ni beza utama dari buat IAM role manual tiap account.
→PRICING: IAM Identity Center PERCUMA — tiada caj untuk SSO, permission sets, atau account assignments. Bayar hanya untuk Managed Microsoft AD kalau guna sebagai identity source.

Guna Bila

Centralized SSO untuk multiple AWS accounts

SSOsingle sign-onmultiple accountsfederationSAML 2.0Active DirectorySaaS integrationEC2 WindowsFleet Managerpermission setaccount assignmentaccess portaltemporary credentialsworkforce identityOktaEntra IDpricing

📎 IAM Identity Center Features 📎 Permission sets 📎 Seamless SSO to EC2 Windows instances

D1 · Secure

IAM Access Analyzer

AWS IAM Access Analyzer

"Pengawal yang jerit bila ada pintu kau terbuka ke luar"

🎯 Sebab Apa Wujud

Wujud sebab bila kau dah set banyak resource-based policy (corak "Dua Kunci" tu), SENANG terlepas pandang satu bucket atau role yang ter-set Principal terlalu luas (cth "Principal":"*" → bocor ke seluruh internet, atau tertinggal account ID lama). Manusia tak larat audit ratusan policy satu-satu. Access Analyzer audit automatik & jerit "findings" bila ada akses keluar zon kau — supaya kau tutup sebelum kena leak. Tujuan: jaring keselamatan untuk silap konfigurasi cross-account/public.

Apa Dia

Servis yang scan resource-based policy kau (S3 bucket, IAM role trust, KMS key, SQS queue, Lambda, Secrets Manager) dan bagitau mana satu boleh diakses oleh entiti LUAR zon kepercayaan kau (public internet, account lain, Org lain). Dia guna automated reasoning (bukti matematik) untuk pastikan, jadi bukan tekaan. Juga ada Unused Access Analyzer (cari role/permission tak guna) dan policy validation/generation.

IAM Access Analyzer — apa dia cari

External Access findings → resource (S3/role/KMS/SQS/Lambda/Secrets) yang boleh diakses dari LUAR zone of trust (public / account lain / Org lain). FREE.

Unused Access findings → IAM role/user, access key, atau permission yang tak digunakan dalam tempoh tertentu — untuk right-size ke least privilege. BAYAR per resource.

Policy validation → semak policy lawan IAM best practice + grammar semasa kau tulis (>100 checks).

Policy generation → jana IAM policy dari sejarah CloudTrail (apa yang principal betul-betul guna) → least privilege siap.

Analogi — pemeriksa keselamatan rumah cari pintu/tingkap tak berkunci

Rendering diagram…

Kaitkan dengan familiar: macam upah pemeriksa keselamatan pusing rumah, dia senaraikan tiap pintu/tingkap yang terbuka ke luar (findings). Kau tengok satu-satu: kalau memang sengaja (cth memang nak share dengan vendor) → archive; kalau silap → tutup. INGAT exam: "continuously identify resources shared with external entities / public" → IAM Access Analyzer.

Access Analyzer vs GuardDuty vs Config vs Macie (jangan keliru — semua "security" tapi beza tugas)

Servis	Dia jawab soalan	Jenis
IAM Access Analyzer	"Resource mana TER-EXPOSE ke luar / permission mana tak guna?"	Config/policy exposure
Amazon GuardDuty	"Ada ANCAMAN aktif? (mining, recon, creds curi)"	Threat detection (aktif)
AWS Config	"Resource ni patuh rules aku & apa berubah?"	Compliance/config state
Amazon Macie	"Ada data SENSITIF (PII) dalam S3 aku?"	Data classification

Ingat: Access Analyzer = pintu mana terbuka ke luar (policy exposure) + permission tak guna. GuardDuty = ada penceroboh aktif. Config = patuh peraturan + sejarah perubahan. Macie = data sensitif dalam S3. Keyword "exposed/shared with external account or public" → Access Analyzer; "active threat/anomaly" → GuardDuty; "compliance/drift" → Config; "PII in S3" → Macie.

⚡ Quick Sifir — hafal ni

▪Access Analyzer = CARI resource yang ter-expose ke LUAR (public / cross-account / cross-Org) — dia DETECT, bukan block
▪Zone of trust = account kau (atau Organization kau kalau set di peringkat Org). Apa-apa akses dari luar zon = "finding"
▪External Access Analyzer = FREE. Unused Access Analyzer (cari role/key/permission tak guna) = BAYAR per resource/bulan
▪Guna automated reasoning (provable security) — bukti matematik, bukan sekadar pattern match
▪Boleh validate policy (semasa tulis) + generate policy dari CloudTrail activity (least privilege)
▪Lawan: GuardDuty = detect ANCAMAN aktif (threat). Access Analyzer = detect POLICY ter-expose (config). Macie = cari data sensitif dalam S3

🪤 Perangkap Soalan

Q: Syarikat ada ratusan S3 bucket & IAM role merentas banyak account. Security mahu tahu mana satu resource yang TER-EXPOSE ke public atau account luar, secara berterusan & automatik. Servis mana?

⚠ Umpan: AWS Config dengan rules custom, atau scan manual semua bucket policy. Config nampak betul sebab "audit compliance". SALAH: Config semak STATE/compliance ikut rules yang KAU tulis, ia tak buktikan secara matematik sama ada policy itu benar-benar boleh diakses dari luar.

✓ Betul: IAM Access Analyzer — direka khusus kenal pasti resource yang dikongsi dengan entiti luar zone of trust (public/cross-account/cross-Org), guna automated reasoning. Keyword "identify resources shared/exposed to external/public/other accounts" → IAM Access Analyzer, BUKAN Config, BUKAN GuardDuty (itu threat aktif).

Q: Audit jumpa banyak IAM role lama yang mungkin ada permission lebih dari keperluan (over-permissioned) & tak pernah dipakai. Nak kemas ikut least privilege. Tooling mana paling sesuai?

⚠ Umpan: Baca CloudTrail satu-satu cari role mana tak aktif. Nampak betul sebab CloudTrail ada log. SALAH: meleret & manual — CloudTrail rekod event, bukan rumuskan "role ni / permission ni tak pernah guna".

✓ Betul: IAM Access Analyzer — Unused Access findings (kenal pasti role/permission/key tak guna) + policy generation dari aktiviti CloudTrail untuk hasilkan policy least-privilege. Keyword "find unused permissions / right-size to least privilege" → Access Analyzer Unused Access.

🧠 Cara Mudah Ingat

→Access Analyzer kenal pasti akses LUAR untuk: S3 buckets, IAM roles (trust policy), KMS keys, Lambda functions/layers, SQS queues, Secrets Manager secrets, dan lagi
→Set analyzer di peringkat ORGANIZATION (bukan account) supaya zone of trust = seluruh Org → apa-apa akses dari luar Org baru jadi finding (akses antara account dalam Org sama tak dikira ancaman)
→Findings boleh di-ARCHIVE (kalau memang sengaja expose, cth public website bucket) supaya tak asyik muncul — archive rules automate ni
→Policy generation: jana IAM policy least-privilege dari CloudTrail history — jawapan bila exam tanya "right-size an over-permissioned role based on actual usage"
→PRICING: External Access Analyzer = PERCUMA. Unused Access Analyzer = bayar ~$0.20 per resource dianalisis sebulan. Policy validation/generation = free.
→Exam discriminator: "shared with / accessible from EXTERNAL account or public" → IAM Access Analyzer. Jangan keliru dengan GuardDuty (threat aktif) atau Config (compliance rules).

Guna Bila

Detect resources yang ter-expose ke public / account luar / Org luar

IAM Access Analyzerexternal accessunused accesszone of trustpublic accesscross-account exposureresource shared externalautomated reasoningprovable securitypolicy validationpolicy generationleast privilegefindingsarchive findingsAccess Analyzer vs GuardDutyAccess Analyzer vs Configpricing

📎 IAM Access Analyzer 📎 Access Analyzer findings

D1 · Secure

AWS RAM

AWS Resource Access Manager

"Kongsi resource antara account — tak payah buat salinan"

🎯 Sebab Apa Wujud

Wujud sebab dalam Organizations dengan banyak account, kalau setiap account kena bina VPC + subnet + Transit Gateway sendiri = duplikasi banyak, mahal, & susah urus rangkaian. Dengan RAM, networking team buat SATU VPC/subnet/TGW di account pusat, lepas tu SHARE ke account Dev/Prod/Finance — mereka deploy EC2 terus dalam subnet kongsi tu (VPC Sharing). Tujuan: elak duplikasi infra + central network management + jimat.

Apa Dia

Membolehkan kau KONGSI satu resource (VPC subnet, Transit Gateway, Route 53 Resolver rules, License Manager config, Aurora cluster, dll) dengan account AWS lain — tanpa buat salinan & tanpa setup IAM role per account. Owner kekal owner; account yang dikongsi (consumer) boleh GUNA resource tu terus dalam VPC mereka.

AWS RAM — apa boleh dikongsi

Resource share → bekas yang kau letak resource + senarai principal (account/OU/Org) yang dibenarkan.

Owner account → yang MEMILIKI & urus resource; kekal kawal penuh.

Consumer/participant account → yang dikongsikan; boleh GUNA resource (cth launch EC2 dalam subnet kongsi) tapi tak boleh ubah/padam resource.

Lazim dikongsi → VPC subnets (VPC Sharing), Transit Gateway, Route 53 Resolver rules, License Manager, Aurora, Outposts, Image Builder.

AWS RAM vs Resource-based policy vs VPC Peering (tiga cara "cross-account", beza tujuan)

Mekanik	Untuk apa	Contoh
AWS RAM	KONGSI guna resource sedia ada ke account lain	Subnet, Transit Gateway, Resolver rules
Resource-based policy	BAGI account lain panggil API resource kau	S3 GetObject, SQS SendMessage, KMS Decrypt
VPC Peering / TGW	SAMBUNG rangkaian 2+ VPC supaya route antara mereka	EC2 di VPC A cakap dengan EC2 di VPC B

Ingat: RAM = "guna barang aku sama-sama" (share resource). Resource-based policy = "panggil API barang aku" (grant access). Peering/TGW = "sambung wayar antara network". Keyword "share subnets/TGW/Resolver across accounts" → RAM; "let account X call my S3/SQS/KMS" → resource-based policy; "connect two VPCs" → peering/TGW.

⚡ Quick Sifir — hafal ni

▪RAM = SHARE resource sedia ada ke account lain (tak salin, tak duplicate)
▪Owner kekal owner & kawal; consumer cuma GUNA
▪Share dalam Organization → boleh share ke whole OU/account terus (no invite). Luar Org → consumer kena ACCEPT invitation
▪Boleh share: VPC subnets (VPC Sharing), Transit Gateway, Route 53 Resolver rules, License Manager, Aurora, Outposts, dll
▪RAM = FREE (bayar resource underlying je)
▪VPC Sharing (subnet kongsi) → guna RAM. Sambung 2 VPC berasingan → VPC Peering / Transit Gateway (beza konsep)

🪤 Perangkap Soalan

Q: Syarikat ada 30 account dalam Organizations. Networking team nak SEMUA account deploy EC2 ke dalam subnet yang DIURUS BERPUSAT (central VPC), tak nak tiap account bina VPC sendiri. Cara terbaik?

⚠ Umpan: Buat VPC Peering dari setiap account ke central VPC. Nampak betul sebab "sambung ke VPC pusat". SALAH: peering cuma SAMBUNG dua VPC berasingan (route antara mereka), bukan benarkan account lain deploy EC2 TERUS dalam subnet kau; 30 account = 30 peering, meleret.

✓ Betul: AWS RAM — share subnet central VPC ke account-account tu (VPC Sharing). Mereka launch EC2 terus dalam subnet kongsi, networking team kawal central. Keyword "share subnets / centrally managed VPC / multiple accounts deploy into same VPC" → AWS RAM, BUKAN VPC Peering.

🧠 Cara Mudah Ingat

→VPC Sharing (via RAM): owner share subnet, participant account launch resource (EC2, RDS, ALB) terus dalam subnet tu. Networking dikawal central, billing resource ikut account masing-masing
→Dalam Organizations: enable resource sharing dengan Organizations → boleh share ke OU/account tanpa invitation. Luar Org: consumer mesti ACCEPT resource share invitation dulu
→Transit Gateway selalu dikongsi via RAM supaya banyak account attach VPC mereka ke satu TGW hub central
→PRICING: AWS RAM PERCUMA — tiada caj untuk berkongsi. Bayar hanya resource underlying (data transfer, TGW attachment, dll)
→Exam discriminator: "centrally manage & share subnets/TGW/Resolver across many accounts" → AWS RAM. Jangan keliru: "connect separate VPCs" → Peering/TGW; "grant API access to my bucket/queue" → resource-based policy.

Guna Bila

Share AWS resources merentas account / OU dalam Organization

AWS RAMResource Access Managershare resourcesVPC sharingshared subnetsTransit Gateway sharingRoute 53 Resolver rulescross-account sharingresource shareOrganizations sharingcentral VPCowner consumerpricingfree

📎 What is AWS RAM 📎 VPC sharing

D1 · Secure

IAM Roles Anywhere

AWS IAM Roles Anywhere

"Server luar AWS (on-prem) dapat temp IAM creds guna sijil X.509 — bukan access key"

🎯 Sebab Apa Wujud

Wujud sebab server on-prem yang nak akses S3/DynamoDB selalunya kena simpan IAM access key — long-term secret yang bocor = bahaya kekal. Untuk workload DALAM AWS, kita guna IAM Role (EC2/Lambda dapat temp creds auto). Tapi server LUAR AWS tak boleh assume role macam tu. IAM Roles Anywhere isi jurang ni: server tunjuk sijil X.509 (dari CA yang kau percaya) → dapat temp creds via STS yang auto-expire. So on-prem gets the same "no hardcoded keys" benefit as EC2.

Apa Dia

Lets workloads that run OUTSIDE AWS (on-prem servers, other clouds, IoT) obtain temporary IAM credentials by authenticating with an X.509 certificate, instead of storing long-term IAM access keys. The certificate is issued by a Certificate Authority (CA) that you register as a trust anchor.

Macam mana workload dapat AWS creds — ikut DI MANA ia berjalan

Workload jalan di mana	Cara dapat creds	Service
EC2 / ECS / Lambda (dalam AWS)	Attach IAM Role (instance profile / task role)	IAM Role
On-prem / other cloud (luar AWS)	Sijil X.509 → temp creds	IAM Roles Anywhere
Mobile/web app (user login Google/FB)	Token OIDC → temp creds	Cognito / STS WebIdentity
Corporate AD users	SAML assertion → temp creds	IAM Identity Center / STS SAML

Ingat: Semua jalan ke temp creds (STS), beza pada CARA authenticate. Dalam AWS → IAM Role. Luar AWS (server) → IAM Roles Anywhere (X.509). User app → Cognito/WebIdentity. Enterprise AD → SAML/Identity Center. Keyword "on-prem server, no long-term keys" → Roles Anywhere.

⚡ Quick Sifir — hafal ni

▪IAM Roles Anywhere = temp IAM creds untuk workload LUAR AWS (on-prem/other cloud), guna sijil X.509
▪Trust anchor = CA (AWS Private CA atau CA sendiri) yang kau daftar supaya AWS percaya sijil tu
▪Profile = had role mana boleh di-assume + session policy
▪Ganti pattern lama: simpan IAM access key panjang dalam server on-prem (bahaya)
▪Bawah hood guna STS → temp creds auto-expire. Sama falsafah dengan EC2 instance role, tapi untuk luar AWS

🪤 Perangkap Soalan

Q: Server data center on-prem perlu muat naik fail ke S3 setiap malam. Sekarang ia simpan IAM access key dalam config. Security mahu buang long-term key tapi kekalkan akses. Cara terbaik?

⚠ Umpan: Rotate access key tu setiap 90 hari guna script. Nampak betul sebab "rotate = lebih selamat". SALAH: ia masih long-term secret yang tersimpan dalam server — kalau bocor antara rotation, tetap boleh disalahguna; rotation tak hapus risiko punca.

✓ Betul: IAM Roles Anywhere — server authenticate guna sijil X.509 (dari CA yang didaftar sebagai trust anchor) → dapat temp creds auto-expire, tiada access key tersimpan langsung. Keyword "on-premises / non-AWS server needs AWS access without long-term keys" → IAM Roles Anywhere.

🧠 Cara Mudah Ingat

→Komponen: (1) Trust Anchor — daftar CA (AWS Private CA atau CA sendiri) yang sijilnya AWS akan percaya. (2) Profile — tetapkan role mana boleh di-assume + had permission
→Server guna alat helper untuk tukar sijil X.509 → temp AWS credentials (akses S3/DynamoDB/dll seperti biasa)
→Guna bila: hybrid — server on-prem atau cloud lain perlu akses AWS service TANPA simpan IAM access key panjang
→PRICING: IAM Roles Anywhere sendiri PERCUMA. Bayar hanya AWS Private CA kalau guna ($400/bulan per CA) + resource yang diakses
→Exam discriminator: "on-premises servers / workloads outside AWS need AWS credentials securely without long-term access keys" → IAM Roles Anywhere (X.509). Dalam AWS → IAM Role biasa

Guna Bila

Give on-prem / non-AWS servers temporary AWS credentials without access keys

IAM Roles Anywhereon-premisesX.509 certificatetrust anchorhybridtemporary credentialsno access keysnon-AWS workloadPrivate CAprofileoutside AWSpricing

📎 What is IAM Roles Anywhere

D1 · Secure

AWS Artifact

"Self-service muat turun laporan pematuhan AWS (SOC, ISO, PCI)"

🎯 Sebab Apa Wujud

Wujud sebab bila syarikat kau kena audit (cth nak cert PCI/ISO/HIPAA), juruaudit akan minta bukti yang AWS (sebagai penyedia infra) pun patuh standard tu. Kau tak boleh audit data center AWS sendiri. AWS Artifact bagi kau muat turun laporan rasmi (SOC, ISO, PCI) terus — bukti untuk bahagian "OF the cloud" dalam shared responsibility. So you hand auditors AWS's certificates instead of trying to inspect AWS yourself.

Apa Dia

A self-service portal to download AWS compliance reports (SOC 1/2/3, ISO 27001, PCI DSS, FedRAMP, etc.) and to review/accept legal agreements like the BAA (for HIPAA) or GDPR DPA. The reports prove AWS's side of the shared responsibility model to your auditors.

⚡ Quick Sifir — hafal ni

▪AWS Artifact = portal muat turun laporan pematuhan AWS (SOC, ISO, PCI, FedRAMP) + terima agreement (BAA, GDPR DPA)
▪Laporan = bukti bahagian AWS dalam Shared Responsibility Model ("security OF the cloud")
▪Artifact Reports = dokumen audit AWS. Artifact Agreements = perjanjian undang-undang (cth BAA untuk HIPAA)
▪PERCUMA — kau bayar tiada apa untuk muat turun
▪Jangan keliru: Artifact = dokumen pematuhan AWS; Audit Manager = kumpul bukti untuk audit KAU; Config = semak compliance resource KAU

🪤 Perangkap Soalan

Q: Juruaudit syarikat minta bukti yang AWS (penyedia infrastruktur) mematuhi SOC 2 dan ISO 27001. Dari mana dapat laporan rasmi ni?

⚠ Umpan: Hubungi AWS Support buka kes, atau guna AWS Config untuk jana laporan compliance. Nampak betul sebab Config ada "compliance". SALAH: Config semak compliance RESOURCE kau, bukan keluarkan sijil audit AWS sendiri.

✓ Betul: AWS Artifact — muat turun terus laporan SOC 2, ISO 27001, PCI DSS AWS (self-service, percuma). Keyword "download AWS compliance/audit reports (SOC/ISO/PCI) for auditors" → AWS Artifact, BUKAN Config/Audit Manager.

🧠 Cara Mudah Ingat

→Dua bahagian: Artifact Reports (muat turun laporan audit AWS — SOC, ISO, PCI, FedRAMP) dan Artifact Agreements (semak & terima BAA, GDPR DPA)
→BAA (Business Associate Addendum) untuk HIPAA workload diterima melalui AWS Artifact
→Laporan ialah bukti untuk bahagian AWS ("OF the cloud") dalam Shared Responsibility Model — bukan compliance KAU
→PRICING: PERCUMA
→Exam discriminator: "obtain/download AWS's compliance or audit reports (SOC, ISO, PCI) for our own auditors" → AWS Artifact. "assess MY resources' compliance" → Config/Audit Manager

Guna Bila

Download AWS compliance reports & accept agreements

AWS Artifactcompliance reportsSOCISO 27001PCI DSSFedRAMPBAAHIPAAGDPR DPAaudit reportsshared responsibilityagreementsfree

📎 What is AWS Artifact

D1 · Secure

Cognito

Amazon Cognito

"Login untuk user apps — User Pool = siapa kau, Identity Pool = boleh buat apa"

🎯 Sebab Apa Wujud

Wujud sebab setiap app perlu sistem login (sign-up, password, MFA, "log in with Google") — kalau kau bina sendiri, banyak kerja + risiko security. Dan lepas login, app mobile selalu nak akses S3/DynamoDB terus, tapi kau TAK boleh letak AWS access key dalam app (bocor terus). Cognito selesai dua-dua: User Pool handle login & bagi JWT (siapa kau), Identity Pool tukar JWT jadi temp AWS credentials via STS (boleh buat apa) — jadi app akses AWS dengan selamat tanpa hardcode key.

Apa Dia

Identity platform untuk web/mobile apps. Dua komponen yang operate independent atau bersama: User Pools (authentication — siapa user, issue JWT) vs Identity Pools (authorization — tukar token jadi temp AWS credentials via STS).

User Pool + Identity Pool flow

User

User Pool

auth → JWT

Identity Pool

JWT → STS creds

DynamoDB

1) Sign in ikut User Pool → dapat JWT. 2) Tukar JWT kat Identity Pool → dapat temp AWS credentials (STS). 3) Guna credentials access AWS services. Dua-dua boleh guna sendiri-sendiri.

User Pool vs Identity Pool

Aspect	User Pool	Identity Pool
Job	Authentication — "siapa kau"	Authorization — "boleh access apa kat AWS"
Issues	JWT tokens (ID, access, refresh)	Temp AWS credentials (via STS)
Backed by	User directory + OIDC IdP	IAM roles (role + attribute based)
Federated IdP	🟢 SAML, OIDC, Google, Facebook, Apple	🟢 Accepts User Pool or external IdP claims
Guest/anonymous	No	🟢 Yes — boleh issue creds untuk guest
Use when	App perlu sign-up / sign-in	App perlu call AWS APIs (S3, DynamoDB) directly

Ingat: "Web app perlu login/registration" → User Pool. "App perlu access S3/DynamoDB terus dengan temp credentials" → Identity Pool. Selalu pair: User Pool authenticate → Identity Pool bagi AWS creds.

⚡ Quick Sifir — hafal ni

▪User Pool = AUTHENTICATION ("siapa kau") → issue JWT
▪Identity Pool = AUTHORIZATION ("boleh akses apa AWS") → issue temp AWS creds via STS
▪Login social/SAML tukar jadi temp AWS creds untuk S3/DynamoDB → Identity Pool
▪Managed user directory + sign-up + MFA + password policy → User Pool
▪Selalu pair: User Pool authenticate → Identity Pool bagi AWS creds

🪤 Perangkap Soalan

Q: App mobile dah login (social). Sekarang nak akses S3 terus dengan temp AWS credentials. Komponen Cognito mana?

⚠ Umpan: User Pool — sebab dia yang handle login & user, mesti dia bagi akses. SALAH: User Pool bagi JWT je, bukan AWS credentials.

✓ Betul: Identity Pool — tukar JWT/social token jadi temp AWS credentials (STS). Keyword "temp AWS credentials untuk akses S3/DynamoDB" = Identity Pool.

🧠 Cara Mudah Ingat

→Cognito User Pools support federated identity — users TAK PERLU di-create dalam AWS, boleh authenticate guna external IdPs (Facebook, Google, Apple, SAML, OIDC)
→Identity Pool guna IAM roles (role-based + attribute-based access control) untuk decide apa user boleh access. Boleh issue credentials untuk guest/unauthenticated users juga
→Exam: "exchange social/SAML login for temporary AWS credentials to access S3" → Identity Pool. "Managed user directory with sign-up, MFA, password policies" → User Pool

Guna Bila

User sign-up/sign-in, federated identity (Google/Facebook), mobile app auth

User PoolsIdentity PoolsOAuthJWTfederated identityMFASTStemp credentialsOIDCSAMLauthenticationauthorizationguest access

📎 What is Amazon Cognito (User vs Identity pools)

D1 · Secure

RAM

AWS Resource Access Manager

"Share AWS resources antara accounts tanpa copy"

🎯 Sebab Apa Wujud

Wujud sebab dalam setup multi-account, banyak account selalu perlu guna infrastruktur yang SAMA — satu Transit Gateway, satu set subnet, satu Route 53 Resolver rule. Kalau setiap account buat sendiri = pendua mahal + huru-hara. RAM bagi kau cipta resource SEKALI dalam satu account, lepas tu kongsi (bukan copy) ke account lain dalam Organization. Account lain guna resource sebenar tu terus. Tujuan: hapus duplikasi infrastruktur + central management + jimat kos.

Apa Dia

Membenarkan perkongsian resources AWS merentasi akaun tanpa pendua.

RAM vs VPC Peering vs Resource-based policy

Aspect	AWS RAM	VPC Peering	Resource-based policy
Buat apa	Share resource sebenar cross-account (no duplicate)	Sambung network 2 VPC supaya boleh route traffic	Bagi specific principal akses satu resource
Use case	Banyak account guna subnet / TGW / Resolver rule yang SAMA	Resource dalam VPC lain perlu cakap antara satu sama lain via IP	Share satu S3 bucket / SQS / KMS key ke account tertentu
Skala org	🟢 Auto-share ke semua account dalam Organization / OU	Pairwise sahaja — N VPC = banyak peering	🟡 Configure satu-satu per resource / account
Contoh resource	Subnet, Transit Gateway, Route 53 Resolver rule, License Manager config, Prefix list	VPC ↔ VPC	S3 bucket policy, SQS policy, KMS key policy

Ingat: Kongsi infrastruktur (subnet/TGW/Resolver) merentas banyak account → RAM. Cuma nak network connectivity antara 2 VPC → Peering. Bagi akses satu resource ke account tertentu → resource-based policy. RAM + Organizations = create sekali, share ke semua member auto.

⚡ Quick Sifir — hafal ni

▪Kongsi resource SEBENAR cross-account tanpa pendua → RAM
▪Cuma nak connectivity antara 2 VPC → VPC Peering, BUKAN RAM
▪Bagi akses 1 resource (S3/SQS/KMS) ke account tertentu → resource-based policy
▪Shareable: subnet, Transit Gateway, Route 53 Resolver rule, License Manager, prefix list
▪RAM + Organizations = create sekali, auto-share ke semua member account

💡 Exam Scenario

"Company ada 10 AWS accounts, semua perlu access sama subnet" → AWS RAM share the subnet. Bukan VPC Peering untuk ni.

🪤 Perangkap Soalan

Q: Syarikat ada 12 account dan mahu semua deploy resource ke dalam set subnet/VPC yang SAMA dan dikongsi (shared VPC), urus secara central. Servis mana?

⚠ Umpan: Setup VPC Peering antara VPC tiap account supaya semua boleh capai subnet pusat. Nampak betul sebab peering "sambung" VPC.

✓ Betul: AWS RAM — kongsi subnet dari account pusat ke semua member account (shared VPC). VPC Peering cuma bagi connectivity rangkaian antara VPC berasingan, bukan benarkan account lain DEPLOY ke subnet yang sama. Keyword "share subnet / shared VPC across accounts" → RAM.

🧠 Cara Mudah Ingat

→RAM + AWS Organizations → create resources ONCE in one account, share across ALL member accounts — jimat kos dan elak duplicate infrastructure
→Shareable resources: VPC subnets, Transit Gateway, Route 53 Resolver rules, License Manager configs, Resource Groups
→Exam: "centralized shared resources across multiple accounts, reduce operational overhead" → AWS RAM (bukan resource-based policies yang perlu configure per-account)
→Resource-based policies = share satu resource ke specific account. RAM = share ke semua accounts dalam Org systematically

Guna Bila

Share subnets, Transit Gateway, Route 53 resolver rules cross-account

cross-account sharingshared subnetsTransit Gateway sharingno resource duplicationAWS Organizationscentralized resources

📎 What is AWS RAM

D1 · Secure

AWS Organizations

AWS Organizations + Control Tower + SCPs

"HQ yang kawal semua anak syarikat"

🎯 Sebab Apa Wujud

Wujud sebab bila syarikat membesar, satu AWS account jadi huru-hara — dev, prod, billing semua bercampur, susah nak asingkan blast radius & kawal kos. Organizations bagi kau pisah jadi banyak account (prod terpisah dari dev) tapi urus dari SATU tempat: satu bil (consolidated billing + volume discount), dan SCP sebagai "guardrail" yang halang admin account anak buat benda bahaya (cth disable CloudTrail) walau dia admin penuh dalam account dia. Tujuan: isolation + central guardrail + jimat bil.

Apa Dia

Mengurus pelbagai AWS accounts dalam satu organisasi dengan Service Control Policies (SCPs) sebagai guardrails

Contoh Guna

Prevent semua dev accounts dari disable CloudTrail — SCP: Deny cloudtrail:StopLogging. Control Tower automate setup multi-account environment

Struktur Organizations — HQ → OU (folder) → Member accounts

Rendering diagram…

INGAT exam: Management Account = HQ (ada Root user, jadi payer consolidated billing, tulis SCP — tapi SCP TAK kena dia sendiri). OU = folder susun member accounts. Finance/Dev/Prod = SEMUANYA Member Account, sengaja diasingkan supaya Dev meletup/kena godam tak jejas Prod atau Finance (isolation blast radius). "Centralized management many accounts / consolidated billing" → Organizations; "restrict member accounts org-wide" → SCP.

Adakah action ni dibenarkan? (SCP + IAM evaluation)

Rendering diagram…

Effective permission = intersection SCP ∩ IAM policy. SCP tak grant apa-apa — kena ADA Allow dalam IAM policy juga. Management account tak terkena SCP langsung.

AWS Control Tower — landing zone workflow (orchestration diagram)

Rendering diagram…

Control Tower = automation DI ATAS Organizations (bukan ganti Organizations). Orchestrate IAM Identity Center + Service Catalog + guardrails untuk landing zone <1 jam. Account Factory provision account konsisten. INGAT exam: "monitor OU hierarchy + subscribe alerts + least overhead" → enable account drift notifications (SNS), BUKAN Config aggregated rules (resource compliance) atau StackSets drift (template infra).

SCP vs IAM Policy

Aspect	SCP (Organizations)	IAM Policy
Boleh GRANT akses?	❌ Tak — RESTRICT je (guardrail)	✅ Ya — pemberi akses sebenar
Skop	Whole account / OU (semua principal dalam account)	User / role / group tertentu
Apply ke management account?	❌ Tidak	✅ Ya
Effective permission	Intersection: SCP ∩ IAM (kedua-dua kena Allow)	Union semua IAM policy attached
Keyword	"org-wide guardrail / max permission"	"bagi user ni akses ke X"

Ingat: SCP = had MAKSIMUM (pagar), tak pernah bagi akses. IAM = pemberi akses sebenar. SCP Allow ≠ akses; kena ADA Allow dalam IAM JUGA. "org-wide guardrail / restrict all accounts" → SCP; "grant this user" → IAM.

AWS Organizations vs Control Tower (jangan keliru)

Aspect	AWS Organizations	AWS Control Tower
Apa dia	Building block mentah — OU, SCP, consolidated billing	Automation DI ATAS Organizations — landing zone siap-pakai
Setup	Manual — kau pasang sendiri SCP, logging, baseline	Automated — landing zone + baseline auto-deploy
Account baru	Create manual satu-satu	Account Factory — self-service, provision konsisten
Guardrails	Tulis SCP sendiri	Pre-built: Mandatory · Strongly-recommended · Elective
Drift detection	❌ Tiada	🟢 Ada — bagitau bila config terpesong dari baseline
Guna bila	Nak kawalan penuh / setup ringkas	Roll-out banyak account dengan governance konsisten, laju

Ingat: Organizations = LEGO blocks (kau bina sendiri). Control Tower = LEGO set siap-bina dengan arahan (landing zone + Account Factory + guardrail + drift detection) di atas Organizations. Keyword "automated landing zone / provision many accounts at scale / governed baseline" → Control Tower; "consolidated billing / SCP guardrail manual" → Organizations.

⚡ Quick Sifir — hafal ni

▪SCP = RESTRICT je, TAK PERNAH grant. Kena ada IAM Allow juga (intersection)
▪SCP TAK apply ke management/root account — member accounts sahaja
▪Satu bil + volume discount across accounts → Consolidated Billing (free)
▪Auto setup landing zone / multi-account baseline → Control Tower
▪Organizations = building block manual; Control Tower = automated landing zone + guardrail siap-pakai DI ATAS Organizations
▪Control Tower guardrail: Mandatory (wajib) · Strongly-recommended · Elective. Drift detection bagitau bila config terpesong dari baseline
▪Organizations + SCP + Consolidated Billing = FREE (bayar resource je)
▪Hierarki: Management Account (HQ, ada Root user, payer) → OU (folder) → Member accounts (Finance/Dev/Prod). Asingkan account = kurung blast radius (Dev meletup tak jejas Prod)

💡 Exam Scenario

"Restrict apa member accounts boleh buat org-wide, exempt management account" → SCP (member accounts only). "Enforce guardrails + auto setup landing zone / multi-account baseline" → Control Tower. "Monitor perubahan OU hierarchy + subscribe alert, least overhead" → Control Tower account drift notifications (SNS), BUKAN CloudFormation StackSets drift (check resource dalam stack, manual). "Satu bil + kongsi diskaun" → Consolidated Billing (bukan SCP). Ingat: SCP RESTRICT sahaja, tak GRANT.

🪤 Perangkap Soalan

Q: Syarikat nak halang SEMUA account (termasuk yang akan datang) daripada guna region selain ap-southeast-1, secara org-wide. Cara paling scalable?

⚠ Umpan: Tulis IAM policy "Deny" region lain dan attach kat setiap user dalam setiap account. Nampak betul sebab IAM kawal permission.

✓ Betul: Guna SCP pada root OU / Organizations. SCP apply automatik ke semua member account (sekarang & masa depan) tanpa sentuh IAM setiap user. IAM-per-user = tak scalable & senang terlepas. Keyword "org-wide guardrail / all accounts" → SCP.

Q: Selepas attach SCP yang "Allow" S3 pada satu OU, developer dalam account tu masih tak boleh akses S3. Kenapa?

⚠ Umpan: SCP tu salah configure / belum propagate. Cuba tunggu atau re-attach. Nampak betul sebab SCP dah Allow.

✓ Betul: SCP TAK GRANT akses — ia cuma tetapkan had maksimum. Developer masih perlu explicit Allow dalam IAM policy dia. SCP Allow cuma "tak disekat di peringkat OU". Keyword: SCP = guardrail, IAM = pemberi akses sebenar.

Q: Syarikat nak roll-out 50+ AWS account baru dengan baseline security yang konsisten (logging, guardrails, SSO, network) secara automatik & boleh self-service oleh team. Cara terbaik?

⚠ Umpan: Guna AWS Organizations + tulis SCP + manual create setiap account + setup CloudTrail/Config satu-satu. Nampak betul sebab Organizations memang urus multi-account.

✓ Betul: AWS Control Tower — dia automate "landing zone" (baseline siap-pakai) + Account Factory untuk provision account baru secara self-service + pre-built guardrails + drift detection, semua DI ATAS Organizations. Keyword "automated landing zone / governed baseline / provision many accounts at scale" = Control Tower, BUKAN Organizations mentah (tu building block manual).

Q: Accounts disusun dalam OU. Perlu MONITOR perubahan pada hierarki OU & benarkan stakeholder subscribe alert, dengan least admin overhead. Pilih apa?

⚠ Umpan: CloudFormation StackSets + drift detection — perkataan "drift detection" bunyi tepat, tapi StackSets drift check resource DALAM stack (template vs sebenar), BUKAN perubahan struktur OU/account, dan kena trigger manual pula.

✓ Betul: AWS Control Tower + enable account drift notifications — Control Tower auto-detect drift (termasuk OU & account changes dari landing zone baseline) dan publish ke SNS topic yang stakeholder boleh subscribe. Built-in, least overhead. Keyword "monitor OU hierarchy changes + subscribe alerts + least overhead" = Control Tower drift notifications.

Q: Same OU monitoring stem — engineer cadang Control Tower + AWS Config aggregated rules. Betul?

⚠ Umpan: Config aggregated rules — nampak betul sebab "span multiple accounts" & compliance, tapi Config evaluate RESOURCE configuration, bukan perubahan hierarki OU/account.

✓ Betul: Tak sesuai untuk OU hierarchy — guna Control Tower account drift notifications (built-in, SNS subscribe). Config aggregated rules untuk resource compliance across accounts, bukan OU structure changes.

Q: Same stem — Service Catalog create accounts + CloudTrail organization trail untuk OU changes?

⚠ Umpan: CloudTrail org trail log semua events — technically ada data OU changes, tapi kena parse log sendiri + tooling tambahan = overhead tinggi.

✓ Betul: Control Tower drift notifications — built-in, least overhead. Org trail = raw logs, bukan purpose-built OU hierarchy alerting.

🧠 Cara Mudah Ingat

→SCP TIDAK apply ke management (root) account by default — SCPs hanya restrict MEMBER accounts
→Kalau soalan tanya "prevent actions org-wide tapi exempt management account" → answer specify "member accounts only"
→SCPs cannot GRANT permissions — they only RESTRICT maximum available permissions. IAM policies still needed untuk grant access
→S3 Block Public Access via SCP: most scalable way nak prevent public S3 org-wide. SCP prevent members dari disable BPA setting
→PRICING: AWS Organizations is FREE — tiada charge untuk OUs, SCPs, atau consolidated billing. Yang kau bayar adalah resources dalam setiap account. Consolidated billing percuma dan boleh dapat volume discounts (S3, EC2 reserved, dll) kerana aggregate usage.
→Exam: "no charge for Organizations" → free. "consolidated billing discount" → volume pricing benefit dari aggregate usage across all member accounts.
→DRIFT — Control Tower auto-detect drift dari landing zone baseline (termasuk OU structure & account changes) dan boleh publish notification ke SNS topic → stakeholder subscribe untuk alert. Ini ganti monitor manual. JANGAN keliru: CloudFormation StackSets drift = check resource dalam stack (manual trigger); AWS Config = resource compliance, bukan OU hierarchy.

Guna Bila

Manage multiple AWS accounts centrally with guardrails

multi-accountSCPsguardrailsControl Towermanagement accountOUmanagement account exemptionSCP cannot grantS3 Block Public Access SCPpricingfreeconsolidated billingvolume discountlanding zoneAccount Factorydrift detectiongoverned baselinemandatory guardrailelective guardrailprovision accounts at scalemember accountFinance accountDev accountProd accountblast radiusaccount hierarchyRoot userpayer accountaccount drift notificationsdrift notification SNSmonitor OU changesOU hierarchy changes

🛡️Network Security↑ Top

D1 · Secure

Security Groups

VPC Security Groups

"Bodyguard EC2 — stateful, allow only, ingat connections"

🎯 Sebab Apa Wujud

Wujud sebab setiap EC2 perlu firewall sendiri di pintu instance — kalau bergantung pada NACL (subnet) je, semua instance dalam subnet sama dapat rule yang sama, tak boleh tailor per-server. SG bagi kau "web boleh kena 443, DB cuma kena 3306 dari web je". Dia STATEFUL supaya kau tak payah fikir return traffic — bagi masuk = auto bagi balik, kurang silap manusia (lupa allow ephemeral port macam NACL).

Apa Dia

Mengawal inbound dan outbound traffic pada peringkat EC2 secara stateful. Custom SG baru: tiada inbound rules (semua inbound ditolak secara implicit), ada satu default outbound rule yang allow semua traffic ke 0.0.0.0/0. Default SG (yang auto-create bersama VPC): ada inbound allow dari dalam group yang sama.

Contoh Guna

Web server SG: allow port 443 dari 0.0.0.0/0. DB SG: allow port 3306 dari Web-SG je — DB hanya boleh diakses dari web servers, bukan dari internet.

⚡ Quick Sifir — hafal ni

▪SG = STATEFUL (ingat connection, reply auto-allow). NACL = stateless
▪SG = ALLOW only — tak boleh deny IP. Nak block IP → NACL
▪SG level = instance/ENI. NACL level = subnet
▪Custom SG baru: inbound KOSONG (deny all), outbound allow all
▪SG boleh reference SG lain sebagai source — "allow FROM web-sg", bukan hardcode IP

💡 Exam Scenario

Exam: "New custom SG, no rules — what is default state?" → Inbound: NO rules = ALL DENIED. Outbound: default rule = ALL ALLOWED to 0.0.0.0/0. Jangan confuse dengan default SG (berbeza).

🪤 Perangkap Soalan

Q: EC2 punya SG: inbound allow 443, TIADA outbound rule yang allow balik ke client. Boleh ke user dapat response web?

⚠ Umpan: Tak boleh — sebab outbound kena ada rule untuk reply keluar (cara fikir NACL/stateless).

✓ Betul: BOLEH. SG stateful — sekali inbound 443 dibenarkan, reply keluar auto dibenarkan tanpa outbound rule. (Kalau ni NACL, baru kena allow ephemeral port balik.)

Q: Nak BLOCK satu IP penyerang (1.2.3.4) sahaja daripada reach EC2. Guna apa?

⚠ Umpan: Add DENY rule untuk 1.2.3.4 dalam Security Group. SALAH: SG takde konsep DENY langsung.

✓ Betul: Guna NACL — letak Deny rule untuk 1.2.3.4 (nombor rule kecil). SG allow-only, jadi tak boleh block IP tertentu.

🧠 Cara Mudah Ingat

→Custom SG default: NO inbound rules (deny all) + 1 outbound rule (allow all to 0.0.0.0/0)
→Default SG vs Custom SG: Default SG ada inbound rule allow dari same SG. Custom SG starts empty.
→Stateful = SG ingat connections. Outbound reply auto dibenarkan — tak perlu explicit outbound rule
→SG = allow only. Nak deny specific IP? → Guna NACL
→SG boleh reference SG lain sebagai source — "allow 3306 FROM web-sg" bukan hardcode IP
→Analogi: SG = Pengawal pejabat 👮 (stateful — ingat muka, dah bagi masuk auto bagi keluar). Lawan NACL = Kastam 🛂 (stateless — cek pasport tiap kali)

Guna Bila

Instance-level firewall — control inbound/outbound per EC2/ENI

statefulinstance-levelallow onlycustom SG defaultinbound deniedoutbound allowed

📎 Security Groups

D1 · Secure

NACLs

Network Access Control Lists

"Guard kat pintu masuk subnet — check both ways"

🎯 Sebab Apa Wujud

Security Group jaga setiap instance & allow-only — tak boleh block satu IP jahat, dan tak boleh tapis di peringkat subnet. NACL wujud sebagai firewall peringkat SUBNET yang boleh DENY (block IP range) & dinilai ikut nombor. Sebab dia STATELESS (tak ingat connection), dia jadi "Kastam" yang cek tiap packet dua hala — bukan "pengawal" yang ingat muka.

Apa Dia

Mengawal traffic masuk dan keluar subnet secara stateless — kena ada rule eksplisit untuk inbound DAN outbound. Rules diproses ikut nombor (rendah → tinggi); rule pertama yang match terus apply. Boleh ALLOW dan DENY (tak macam SG yang allow-only). Custom NACL: deny all by default. Default NACL: allow all.

Contoh Guna

Block IP range 192.168.1.0/24 dari masuk subnet — tambah DENY rule dalam NACL (Security Groups tak boleh explicitly deny).

Security Group vs NACL — THE classic exam trap

Aspect	Security Group	NACL
Beroperasi di	Instance / ENI level	Subnet level
State	🟢 Stateful — return traffic auto-allow	Stateless — kena rule untuk SETIAP arah
Rules	ALLOW only (implicit deny)	ALLOW dan DENY
Evaluation	Semua rules dinilai, kalau ada allow → pass	Ikut nombor, rendah → tinggi, first match menang
Default (custom)	No inbound, allow all outbound	DENY semua inbound & outbound
Apply ke	Setiap instance yang attach SG tu	Auto semua instance dalam subnet

Ingat: Stateful + allow-only + instance level → Security Group. Stateless + boleh DENY + subnet level + numbered rules → NACL. Nak block satu IP jahat = NACL (SG tak boleh deny). Return traffic kena fikir ephemeral ports = NACL je (SG ingat sendiri).

⚡ Quick Sifir — hafal ni

▪NACL = subnet level, STATELESS, boleh ALLOW & DENY, numbered rules
▪Stateless = return traffic TAK auto-allow → kena rule inbound DAN outbound
▪First match menang: rule nombor kecil baca dulu, lepas match terus stop
▪Nombor rule (100, 200…) = priority/urutan baca, BUKAN kod. Guna increment 100 supaya senang selit rule baru di tengah
▪Return reply guna ephemeral ports 1024-65535 → kena allow outbound
▪Block satu IP jahat → NACL (SG tak boleh deny). SG = stateful, allow-only, instance level

💡 Exam Scenario

"Block satu malicious IP daripada akses semua instance dalam subnet" → NACL DENY rule (SG tak boleh deny). "Allow/deny per EC2 ikut role" → Security Group. Exam keyword "explicit deny" atau "block specific IP" hampir selalu = NACL.

🪤 Perangkap Soalan

Q: NACL: Inbound 100 "allow all", Outbound 200 "deny SSH(22)". Statement: "effectively allows SSH connectivity" — True/False?

⚠ Umpan: TRUE — sebab inbound dah allow all, nampak macam SSH boleh masuk = OK. Itu cara fikir STATEFUL (Security Group).

✓ Betul: FALSE. NACL stateless — server reply SSH kena keluar ikut outbound, tapi outbound DENY SSH → reply tersekat, connection mati. Stateless = kena allow DUA hala.

Q: Outbound NACL: rule 100 "DENY all traffic", rule 200 "ALLOW SSH". SSH reply boleh keluar?

⚠ Umpan: Boleh — sebab ada rule 200 Allow SSH. SALAH: rule 200 tak pernah dibaca.

✓ Betul: TAK boleh. First-match: rule 100 (nombor kecil) baca dulu, "DENY all" terus match & stop. Letak ALLOW di nombor lebih KECIL dari DENY kalau nak ia menang.

🧠 Cara Mudah Ingat

→Stateless = check every packet — kena ada rules untuk BOTH inbound DAN outbound directions
→Custom NACL: deny all by default. Default NACL: allow all (berbeza dengan SG!)
→Rules by number — rule 100 diprocess sebelum rule 200. First match menang, jadi letak DENY rule nombor lebih kecil dari ALLOW yang nak override
→Outbound replies perlu allow ephemeral ports 1024–65535 (Linux 32768–60999, Windows 49152–65535) — sebab NACL stateless, return traffic guna random high port
→SG = allow only. Nak EXPLICITLY DENY satu IP/range? → NACL je yang boleh
→Mnemonic: NACL = Numbered + Allow/deny + Check both ways + subnet Level. SG = Stateful + allow-only + instance-level
→Analogi: NACL = Kastam 🛂 (stateless — cek pasport tiap kali lalu, cepat lupa, jaga sempadan subnet). SG = Pengawal pejabat 👮 (stateful — ingat muka, auto lepas balik, jaga pintu instance)

Guna Bila

Subnet-level firewall, stateless, boleh block IP

statelesssubnet-levelallow & denynumbered rulesexplicit both waysephemeral portsexplicit denyblock IPSG vs NACL

📎 Network ACLs 📎 Compare security groups and network ACLs

D1 · Secure

WAF

AWS Web Application Firewall

"Penapis website dari serangan Layer 7"

🎯 Sebab Apa Wujud

Wujud sebab penyerang hantar request HTTP yang nampak normal tapi ada niat jahat — SQL injection (curi DB), XSS (curi session user), atau bot spam ribuan request. Security Group/NACL tak boleh tengok ISI request HTTP (mereka Layer 3/4 je). WAF duduk depan ALB/CloudFront/API GW, baca setiap HTTP request Layer 7, dan block ikut rules (managed rule groups untuk CVE/OWASP, rate-based untuk throttle bot) SEBELUM ia sampai app.

Apa Dia

Menapis requests HTTP/HTTPS berbahaya sebelum sampai ke aplikasi dengan rules dan managed rule groups

Contoh Guna

API kena SQL injection attack — deploy WAF dengan AWS Managed Rules kat ALB atau CloudFront. Boleh rate limit 1000 req/IP per minit

Serangan jenis apa? → lapisan perlindungan mana

Rendering diagram…

INGAT exam: isi HTTP request (SQLi/XSS/bot) → WAF. Banjir trafik (DDoS) → Shield. Traffic VPC-wide ikut domain/egress → Network Firewall. Banyak account nak satu policy → Firewall Manager.

WAF — 4 jenis rule (apa block apa)

Jenis rule	Block apa	Keyword exam
Managed rule groups	Known exploits — OWASP Top 10, CVE, bad inputs, Anonymous IP	"AWS Managed Rules", "OWASP", "common vulnerabilities"
Rate-based rule	IP yang lebih threshold req/5min — anti bot/brute-force	"rate limit", "too many requests from one IP", "brute force"
IP set / geo match	Allow/block ikut senarai IP atau negara	"block country", "allowlist office IP", "geo restriction L7"
String/regex/SQLi/XSS match	Custom pattern dalam header/body/URI	"block specific URI", "inspect request body", "custom rule"

Ingat: Managed rule group = senjata default (auto-cover OWASP/CVE). Rate-based = anti-flood satu IP. SQLi/XSS = WAF (BUKAN Shield). Untuk WAF vs Shield vs Network Firewall, tengok card Shield / Network Firewall.

⚡ Quick Sifir — hafal ni

▪WAF = Layer 7 (HTTP/S) — block SQLi, XSS, bad bots, rate limit
▪Anatomy: Web ACL (tampal kat ALB/CloudFront/API GW) → dalam dia ada Rules + Rule Groups → Rule rujuk IP Set (himpunan IP) & Regex Pattern Set (corak)
▪Pasang kat: CloudFront, ALB, API Gateway, AppSync, Cognito
▪Rate-based rule = throttle IP lebih threshold. URI-specific = throttle endpoint mahal je
▪WAF = web exploit (L7). Shield = DDoS (L3/4). Network Firewall = traffic VPC (L3-7)
▪Managed rule groups = auto block known exploit/CVE/OWASP Top 10

🪤 Perangkap Soalan

Q: API endpoint /api/report (computationally expensive) kena spam, tapi endpoint lain elok. Nak throttle yang mahal je.

⚠ Umpan: Rate-based rule biasa untuk seluruh web ACL. SALAH: itu limit SEMUA endpoint, termasuk yang ringan = pengguna sah pun kena.

✓ Betul: URI-specific rate-based rule — scope rate limit pada /api/report je. Keyword "throttle specific expensive endpoint" = URI-specific rate-based rule.

🧠 Cara Mudah Ingat

→Rate-based rule: throttle requests dari satu IP yang melebihi threshold
→URI-specific rate-based rule → throttle ONLY heavy/expensive endpoints (e.g. /api/compute) sambil biarkan lightweight endpoints unrestricted
→Blanket rate-based rule = semua endpoint kena limit (too broad). URI-specific = targeted throttling
→IP reputation rule = block known bad IPs. Managed rule groups = block known exploits/CVEs
→Exam: "throttle specific API endpoint yang computationally expensive" → URI-specific rate-based rule
→PRICING: WAF = $5/web ACL/bulan + $1/rule/bulan + $0.60/1M requests. Managed rule groups (AWS) free; Marketplace managed rules ada surcharge. Bot Control / Fraud Control = add-on berasingan.

Guna Bila

Protect against SQL injection, XSS, rate limiting

Layer 7SQL injectionXSSrate limitingmanaged rulesALBCloudFrontURI-specific rate-based ruletargeted throttlingweb ACLrule groupsIP setregex pattern setpricing

📎 How AWS WAF works 📎 Rate-based rule statement

D1 · Secure

AWS Shield

AWS Shield Standard & Advanced

"Pelindung DDoS — Standard free, Advanced bayar"

🎯 Sebab Apa Wujud

Wujud sebab DDoS = penyerang banjirkan service kau dengan jutaan request/packet sampai server tumbang (pengguna sah tak boleh masuk). Kau seorang tak mampu lawan trafik berjuta — kena infrastruktur besar. Shield Standard auto-lindung semua pelanggan AWS dari DDoS L3/4 (SYN flood, UDP reflection) PERCUMA tanpa setup. Shield Advanced tambah lindungan L7 berskala besar + DDoS Response Team (DRT) + cost protection (bil tak melonjak masa diserang) untuk yang high-risk.

Apa Dia

Melindungi dari serangan DDoS — Standard free untuk semua, Advanced untuk protection 24/7 + DDoS Response Team

Contoh Guna

Website kena volumetric DDoS — Shield Standard protect automatically. Enterprise nak protection + cost protection + DRT = Shield Advanced

WAF vs Shield Standard vs Shield Advanced — yang mana untuk apa

Aspect	AWS WAF	Shield Standard	Shield Advanced
Lindung dari	L7 web exploits (SQLi, XSS, bots)	L3/L4 DDoS (SYN flood, UDP reflection)	L3/L4 + L7 DDoS, scale besar
Layer	Layer 7 (HTTP/S)	Layer 3/4	Layer 3/4/7
Harga	Bayar per rule + request	🟢 FREE, auto untuk semua	$3,000/bulan/org + data
Pasang kat	CloudFront, ALB, API GW, AppSync, Cognito	Auto (semua AWS edge)	CloudFront, ALB, NLB, EIP, Route 53, GA
Extra	Custom + managed rule groups, rate limit	Tiada visibility / custom rules	DRT/SRT 24/7, cost protection, real-time metrics, WAF percuma

Ingat: SQLi/XSS/bad-bot/rate-limit (Layer 7) → WAF. DDoS asas percuma → Shield Standard (auto, takyah buat apa). DDoS besar + DDoS Response Team + bil tak naik masa diserang → Shield Advanced (selalu dgn WAF).

⚡ Quick Sifir — hafal ni

▪Shield Standard = FREE, auto, L3/4 DDoS — takyah buat apa-apa
▪Shield Advanced = $3000/bulan: L3/4/7, DRT 24/7, cost protection, WAF percuma
▪WAF = web exploit L7 (SQLi/XSS). Shield = DDoS. Jangan campur
▪Keyword Shield Advanced: "DRT", "cost protection", "real-time visibility", "maximum DDoS"

💡 Exam Scenario

"Volumetric DDoS auto-protection, free, no setup" → Shield Standard. "24/7 DDoS Response Team + cost protection (bil tak melonjak masa diserang) + maximum DDoS visibility" → Shield Advanced. "SQLi/XSS / web exploit" → WAF (BUKAN Shield). "Threat detection / suspicious API" → GuardDuty.

🪤 Perangkap Soalan

Q: Website kena SQL injection + XSS. Pasang Shield untuk block?

⚠ Umpan: Shield Advanced — sebab dia maximum protection, mesti cover semua serangan. SALAH: Shield untuk DDoS, bukan web exploit macam SQLi/XSS.

✓ Betul: AWS WAF — block SQLi/XSS (Layer 7 web exploit). Shield = DDoS sahaja. Keyword "SQL injection/XSS" = WAF.

Q: Filter SEMUA outbound traffic VPC ikut domain name (allow *.amazonaws.com je), IDS/IPS. WAF?

⚠ Umpan: WAF — sebab dia firewall, mesti boleh filter traffic. SALAH: WAF Layer 7 HTTP request je, bukan traffic VPC umum.

✓ Betul: AWS Network Firewall — inspect/filter semua traffic VPC (L3-7), domain filtering, Suricata IDS/IPS. Keyword "egress/domain filter VPC-wide" = Network Firewall.

🧠 Cara Mudah Ingat

→Shield Standard: FREE, automatic, protect Layer 3/4 DDoS. TIADA: custom rules, real-time visibility, WAF integration
→Shield Advanced: PAID ($3,000/month). Ada: DDoS Response Team (DRT), real-time metrics, WAF integration, custom mitigation
→GuardDuty = detects threats, bukan protect DDoS. Inspector = vulnerability scanning EC2. Detective = investigate security events
→Exam: "custom mitigations + real-time visibility + maximum DDoS protection" → Shield Advanced + WAF
→PRICING: Shield Standard = FREE (auto untuk semua AWS customer, L3/4 — takyah subscribe). Shield Advanced = US$3,000/bulan per organization (commit 1 tahun) + data transfer fee — TAPI include WAF percuma + DDoS Response Team (DRT) + cost protection (credit balik untuk scaling akibat DDoS pada EC2/ELB/CloudFront/Route 53/GA). Exam: "free DDoS protection" → Standard; angka "$3,000/month + DRT + cost protection" → Advanced.

Guna Bila

DDoS protection Layer 3/4 (Standard) and Layer 7 (Advanced)

DDoSLayer 3/4Shield StandardShield AdvancedDRTalways-onShield Standard freeShield Advanced paidcustom mitigationreal-time visibilitycost protectionpricing

📎 AWS Shield — DDoS protection overview 📎 Shield Advanced capabilities

D1 · Secure

Network Firewall

AWS Network Firewall

"Polis traffic dalam VPC — deep inspection, Layer 3-7, pakai Suricata"

🎯 Sebab Apa Wujud

Wujud sebab SG/NACL terlalu kasar (cuma IP & port, tak faham domain atau isi packet) dan WAF cuma jaga HTTP web app — tiada apa yang inspect SEMUA traffic masuk/keluar VPC secara mendalam. Kalau nak buat sendiri, kena urus EC2 firewall appliance (IDS/IPS) yang pening nak scale & maintain. Network Firewall = managed firewall VPC-wide guna Suricata rules, boleh filter ikut domain (allow *.amazonaws.com je) dan buat egress control tanpa urus appliance sendiri.

Apa Dia

Managed network firewall + IDS/IPS untuk VPC. Ada DUA engine: stateless engine (macam NACL, nilai packet sorang-sorang ikut priority) dan stateful engine (guna Suricata-compatible rules, nilai dalam konteks traffic flow). Boleh buat domain/URL filtering, intrusion prevention, dan filter traffic Layer 3 sampai 7. Deploy dalam dedicated firewall subnet, route traffic VPC melaluinya.

Contoh Guna

Company policy: semua outbound traffic kena inspect dan block malicious/unapproved domains — deploy Network Firewall kat centralized inspection VPC, route semua traffic melaluinya guna stateful domain-list rules.

WAF vs Shield vs Network Firewall — 3 lapisan, jangan campur

Aspect	AWS WAF	AWS Shield	Network Firewall
Lindung apa	Web app exploits (SQLi, XSS, bad bots)	DDoS (volumetric, protocol)	Traffic masuk/keluar VPC
Layer	Layer 7 (HTTP/S)	Layer 3/4 (+ L7 Advanced)	Layer 3-7 (packet + flow)
Skop	CloudFront, ALB, API GW, AppSync	Edge / AWS resources	Seluruh VPC (subnet route)
Engine / rules	Web ACL + managed rule groups	Auto mitigation	Stateless + Suricata stateful, domain filter
Guna untuk	Tapis HTTP request berbahaya	Tahan serangan DDoS	IDS/IPS, domain filtering, egress control

Ingat: HTTP/web exploit (SQLi/XSS) → WAF. DDoS → Shield. Inspect/filter SEMUA traffic VPC ikut domain atau Suricata rule (IDS/IPS, egress filtering) → Network Firewall. Ketiga-tiga boleh berlapis sekali.

⚡ Quick Sifir — hafal ni

▪Network Firewall = inspect traffic VPC, Layer 3-7. WAF = HTTP web je (Layer 7)
▪Dua engine: stateless (macam NACL, priority order) + stateful (Suricata rules)
▪Domain/URL filtering (TLS SNI / HTTP host) → egress control
▪Deploy dalam dedicated firewall subnet; route table hala traffic VPC melaluinya
▪Keyword 'domain filtering / egress / IDS-IPS VPC-wide' → Network Firewall, BUKAN WAF

💡 Exam Scenario

"Filter outbound traffic ikut domain name (allow *.amazonaws.com je), VPC-wide, managed" → AWS Network Firewall. "Block SQLi/XSS pada HTTP request ke website" → WAF (bukan Network Firewall). "DDoS volumetric" → Shield. Network Firewall = traffic dalam/keluar VPC, bukan khusus web app.

🪤 Perangkap Soalan

Q: Compliance: SEMUA outbound traffic dari VPC kena disekat kecuali ke domain yang diluluskan (cth *.amazonaws.com). Servis mana?

⚠ Umpan: AWS WAF dengan rule block domain. Nampak betul sebab WAF pun boleh filter request. SALAH: WAF cuma inspect HTTP request ke CloudFront/ALB/API GW — bukan egress traffic VPC-wide.

✓ Betul: AWS Network Firewall dengan stateful domain-list rule. Keyword 'filter outbound VPC ikut domain / egress control' = Network Firewall.

Q: Nak block SQL injection & XSS pada request ke aplikasi web di belakang ALB. Servis mana?

⚠ Umpan: Network Firewall sebab dia firewall canggih Layer 3-7. Nampak betul sebab 'firewall'. SALAH: SQLi/XSS = web app exploit Layer 7, itu kerja WAF.

✓ Betul: AWS WAF (Web ACL + managed rule group). Keyword 'SQLi/XSS pada HTTP/web app' = WAF, bukan Network Firewall.

🧠 Cara Mudah Ingat

→Network Firewall = managed AWS alternative kepada third-party firewall appliance — tak payah urus EC2 firewall sendiri
→Dua engine: stateless (macam NACL, priority order, first match) + stateful (Suricata-compatible rules, nilai ikut traffic flow)
→Stateful rules support pass / drop / reject / alert + domain-list filtering (TLS SNI / HTTP host) untuk allow/block domain
→Deploy dalam dedicated firewall subnet; route table hantar traffic VPC melaluinya (selalu pakai centralized inspection VPC + Transit Gateway)
→Network Firewall = traffic VPC (Layer 3-7). WAF = HTTP request je (Layer 7 web). Jangan keliru bila soalan sebut "domain filtering / egress" → Network Firewall

Guna Bila

VPC-level managed firewall — stateful deep packet inspection, domain filtering, IDS/IPS

deep packet inspectionstatefulstatelessVPC-levelintrusion preventionIDS/IPSdomain filteringSuricataegress filteringfirewall subnetmanaged firewall

📎 Network Firewall rules engines 📎 Stateful rule groups (Suricata)

D1 · Secure

VPC Flow Logs

"CCTV network VPC — log SIAPA cakap dengan SIAPA, bukan APA dia cakap"

🎯 Sebab Apa Wujud

Wujud sebab bila EC2 dalam private subnet tak boleh terima traffic, kau tertanya-tanya 'SG ke NACL yang block?' — tanpa log, kau buta. VPC Flow Logs rakam metadata setiap traffic (siapa→siapa, port, ACCEPT/REJECT) supaya kau boleh nampak record REJECT dan tahu apa yang sekat. Ia dikumpul DI LUAR path network jadi takde kesan latency/throughput — kau dapat visibility percuma tanpa slow down traffic.

Apa Dia

Rakam METADATA traffic (srcaddr, dstaddr, src/dst port, protocol, packets, bytes, action ACCEPT/REJECT, log-status) untuk traffic masuk/keluar network interfaces — BUKAN isi packet (payload). Boleh enable pada 3 level: VPC (semua ENI), Subnet, atau satu ENI. Dihantar ke CloudWatch Logs, S3, atau Data Firehose. Dikumpul DI LUAR path network → tiada kesan pada throughput/latency.

Flow Logs anatomy

VPC

all ENIs

Subnet

ENI

single

Flow Log

metadata only

CloudWatch Logs

alarm / Insights

archive + Athena

Data Firehose

stream

Pilih level capture (VPC/Subnet/ENI) → Flow Log rakam metadata → hantar ke salah satu dari 3 destinations. Field action = ACCEPT atau REJECT → ini yang tolong jawab "kenapa traffic tak sampai".

Flow Logs vs Traffic Mirroring

Aspect	VPC Flow Logs	Traffic Mirroring
Captures	🟢 Metadata only (headers, ACCEPT/REJECT)	Full packet content (payload)
Use for	Troubleshoot SG/NACL, security analysis, compliance	Deep inspection — IDS/IPS, packet forensics
Destination	CloudWatch Logs, S3, Data Firehose	Monitoring appliance (ENI / NLB)
Cost/overhead	🟢 Low, outside traffic path	Higher — copies real traffic
Exam keyword	"which rule blocked", "REJECT", "audit flows"	"packet capture", "payload", "IDS/IPS"

Ingat: Nak tau traffic kena ACCEPT/REJECT (siapa→siapa) → Flow Logs. Nak baca actual packet content (apa dalam packet) → Traffic Mirroring.

⚡ Quick Sifir — hafal ni

▪Flow Logs = METADATA je (srcaddr, dstaddr, port, protocol, ACCEPT/REJECT) — BUKAN payload
▪3 capture level: VPC (semua ENI), Subnet, single ENI
▪3 destination: CloudWatch Logs, S3 (Athena), Data Firehose
▪action = REJECT → cari ni bila 'traffic tak sampai, SG/NACL block?'
▪Nak isi packet (payload/forensics) → Traffic Mirroring, BUKAN Flow Logs
▪Dikumpul luar path network → zero impact latency/throughput

💡 Exam Scenario

"EC2 dalam private subnet tak boleh terima traffic, nak tahu SG atau NACL yang block" → enable VPC Flow Logs, cari record dengan action = REJECT. Inbound REJECT = sesuatu blocking. Nak actual packet content (IDS/forensics deep inspection)? → Traffic Mirroring, BUKAN Flow Logs.

🪤 Perangkap Soalan

Q: EC2 dalam private subnet tak terima traffic. Kau perlu tahu sama ada SG atau NACL yang sekat, tanpa jejas prestasi. Apa kau enable?

⚠ Umpan: Traffic Mirroring untuk capture packet dan lihat apa berlaku. Nampak betul sebab 'capture traffic'. SALAH: Traffic Mirroring salin full packet (mahal + overhead) — terlebih untuk sekadar tahu ACCEPT/REJECT.

✓ Betul: VPC Flow Logs — cari record action = REJECT. Keyword 'rule mana yang block / audit flow / tanpa overhead' = Flow Logs (metadata).

Q: Pasukan security nak inspect isi sebenar packet (payload) untuk IDS/IPS forensics dalam VPC. Guna apa?

⚠ Umpan: VPC Flow Logs, hantar ke OpenSearch untuk analisa. Nampak betul sebab Flow Logs pun untuk security analysis. SALAH: Flow Logs metadata je — takde payload, tak boleh buat deep packet inspection.

✓ Betul: Traffic Mirroring (copy ke monitoring appliance/NLB). Keyword 'packet content/payload/deep inspection' = Traffic Mirroring, bukan Flow Logs.

🧠 Cara Mudah Ingat

→Rakam METADATA sahaja, bukan packet payload. Nak isi packet → Traffic Mirroring (Nitro instances)
→3 capture levels: VPC (auto semua ENI termasuk yang baru), Subnet, atau single ENI
→3 destinations: CloudWatch Logs (alarm + Logs Insights query), S3 (murah, archive, query guna Athena), Data Firehose (stream ke OpenSearch/Splunk)
→action field = ACCEPT atau REJECT. "Traffic tak sampai instance, SG ke NACL block?" → cari REJECT records dalam Flow Logs
→SG stateful: kalau inbound dibenarkan, return traffic auto-allow. NACL stateless: kena allow inbound DAN outbound rule berasingan — Flow Logs boleh tunjuk satu arah ACCEPT, arah balik REJECT (petunjuk NACL)
→Immutable: tak boleh edit config/format selepas create — kena delete & buat baru
→Tiada data sampai ada active traffic pada ENI/subnet/VPC yang dipilih
→Aggregation interval: max 10 minit atau 1 minit (Nitro-based instances SELALU ≤1 minit)
→TIDAK log: Amazon DNS server traffic, instance metadata (169.254.169.254), Time Sync (169.254.169.123), DHCP, Windows license activation, ARP, default VPC router reserved IP
→Source utama untuk GuardDuty threat detection + Amazon Detective investigation
→Tak boleh enable Flow Logs untuk peered VPC melainkan peer VPC dalam account yang sama

Guna Bila

Capture IP traffic metadata to/from ENIs — troubleshoot SG/NACL, security analysis, compliance

VPC Flow Logsnetwork monitoringACCEPTREJECTmetadataCloudWatch LogsS3Data FirehoseAthenatroubleshoot SG NACLsecurity analysisTraffic Mirroringaggregation intervalENIsubnet levelGuardDuty source

📎 VPC Flow Logs 📎 Flow log limitations

D1 · Secure

GuardDuty

Amazon GuardDuty

"Mata-mata AWS — detect threats auto guna ML"

🎯 Sebab Apa Wujud

Wujud sebab serangan jahat tersembunyi dalam jutaan baris log (CloudTrail, VPC Flow, DNS) — manusia takkan perasan EC2 tiba-tiba call ke IP crypto-mining atau API calls pelik dari negara asing. GuardDuty baca semua log tu guna ML + threat intel feeds, detect anomali, dan alert — TANPA kau install agent atau setup apa-apa. Jadi kau dapat "mata-mata" automatik yang jaga 24/7.

Apa Dia

Pengesanan ancaman menggunakan ML pada CloudTrail, VPC Flow Logs, DNS logs.

Pilih security service yang betul

Rendering diagram…

Detect dari logs → GuardDuty. CVE/patch → Inspector. PII dalam S3 → Macie. Siasat selepas detect → Detective. Satu dashboard untuk semua + check compliance → Security Hub.

Threat-detection family — 5 yang selalu keliru

Service	What it does	Data / target	Keyword
GuardDuty	Threat detection (ML)	CloudTrail, VPC Flow, DNS logs	unusual activity, crypto-mining, compromised
Inspector	Vulnerability scan	EC2, ECR images, Lambda	CVE, patch, vulnerability
Macie	Sensitive-data discovery	S3 objects	PII, credit card, GDPR, S3
Detective	Investigate / root cause	GuardDuty findings + logs (graph)	investigate, root cause, behavior graph
Security Hub	Aggregate + compliance	Findings dari GD/Inspector/Macie + standards	central dashboard, posture, CIS/PCI standards

Ingat: Threats from logs → GuardDuty. Software vulns/CVEs → Inspector. PII in S3 → Macie. Investigate a finding → Detective. ONE place untuk semua finding + compliance score → Security Hub.

⚡ Quick Sifir — hafal ni

▪GuardDuty = DETECT threat dari LOGS (CloudTrail/VPC Flow/DNS), ML, NO agent
▪GuardDuty = detect. Detective = investigate (forensics). Beza ni selalu kena tanya
▪Inspector = CVE/vuln scan. Macie = PII dalam S3. GuardDuty = aktiviti jahat dari logs
▪Security Hub = central dashboard kumpul semua finding + compliance score (bukan dia detect)
▪Keyword GuardDuty: "unusual activity", "crypto-mining", "compromised instance", "no agent"

💡 Exam Scenario

"EC2 buat unusual API calls ke cryptocurrency mining" → GuardDuty detect and alert. Tak perlu install agents.

🪤 Perangkap Soalan

Q: EC2 tiba-tiba sambung ke IP crypto-mining + buat API calls luar biasa. Service mana detect?

⚠ Umpan: Inspector — sebab dia security scan untuk EC2, mesti dia jumpa. SALAH: Inspector scan CVE/vuln software, bukan aktiviti masa nyata.

✓ Betul: GuardDuty — detect aktiviti jahat (crypto-mining, unusual API) dari logs guna ML. Keyword "unusual activity/compromised" = GuardDuty.

Q: GuardDuty dah flag satu finding. Sekarang nak SIASAT scope & root cause serangan, visualize relationship. Guna apa?

⚠ Umpan: GuardDuty sendiri — sebab dia yang detect, mesti dia ada detail. SALAH: GuardDuty detect je, bukan tool siasatan.

✓ Betul: Amazon Detective — behavior graph untuk investigate finding & root cause. GuardDuty = detect, Detective = investigate.

🧠 Cara Mudah Ingat

→GuardDuty → detect threats (SIEM-like). Detective → investigate findings (forensics). Ingat: GD = detect, Detective = investigate
→GuardDuty findings integrate dengan Security Hub untuk centralized view
→Foundational threat detection (CloudTrail MANAGEMENT events) ON by default bila GuardDuty enabled — TAK boleh disable. ListBuckets/DeleteBucket = management events, bukan data events
→S3 Protection (optional, enable berasingan): monitor CloudTrail DATA events untuk S3 — object-level ops (GetObject, PutObject, DeleteObject, ListObjects) untuk detect data exfiltration/destruction. Tak perlu manually configure S3 data event logging dalam CloudTrail
→Security Hub = aggregator/CSPM (kumpul finding GuardDuty + Inspector + Macie + run compliance standards). Bukan dia yang detect — dia central dashboard. Cross-Region aggregation pun ada

Guna Bila

Automated threat detection: crypto-mining, unusual API calls, compromised instances

threat detectionMLCloudTrail logsVPC Flow Logsno agentsfindingsS3 Protectionmanagement eventsdata eventsobject-level APISecurity HubDetectiveCSPM

📎 What is Amazon GuardDuty

D1 · Secure

Detective

Amazon Detective

"Siasatan selepas GuardDuty detect — forensics AWS"

🎯 Sebab Apa Wujud

Wujud sebab bila GuardDuty bagi alert 'EC2 ni buat benda pelik', kau masih tertanya 'apa sebenarnya jadi, dari mana, scope dia sampai mana?' — nak sambung sendiri CloudTrail + VPC Flow Logs + finding manual = mimpi ngeri. Detective auto kumpul semua log tu dan guna ML/graph analysis untuk lukis timeline & hubungan antara resource, jadi kau boleh siasat root cause selepas insiden tanpa korek log satu-satu.

Apa Dia

Amazon Detective automatically collects log data (CloudTrail, VPC Flow Logs, GuardDuty findings) dan guna ML/graph analysis untuk visualize security investigations. Bagi timeline, entity relationships, dan root cause analysis.

⚡ Quick Sifir — hafal ni

▪Detective = POST-INCIDENT investigation (siasat). GuardDuty = REAL-TIME detection (cari)
▪Auto kumpul: CloudTrail, VPC Flow Logs, GuardDuty findings, EKS audit logs
▪Guna behavior graph → visualize hubungan resource + timeline
▪Keyword 'investigate finding / root cause / scope / visualize attack' → Detective
▪Bukan Inspector (vuln scan), bukan Macie (PII S3), bukan GuardDuty (detect)

💡 Exam Scenario

"GuardDuty flagged suspicious EC2 activity — siasatan lanjut untuk faham scope dan root cause" → Amazon Detective.

🪤 Perangkap Soalan

Q: GuardDuty flag aktiviti mencurigakan pada EC2. Pasukan nak faham scope & root cause serangan dengan visualkan hubungan & timeline. Servis mana?

⚠ Umpan: GuardDuty sendiri — sebab dia yang detect, mesti boleh tunjuk butiran penuh. Nampak betul sebab 'dah ada finding'. SALAH: GuardDuty cuma detect & alert, bukan tools siasat mendalam.

✓ Betul: Amazon Detective — kumpul log + behavior graph untuk root cause. Keyword 'investigate / root cause / visualize / scope finding' = Detective.

🧠 Cara Mudah Ingat

→Detective = POST-INCIDENT investigation tool. GuardDuty = REAL-TIME threat detection
→Detective guna behavior graph — visualize relationships antara AWS resources masa incident
→Sources: CloudTrail, VPC Flow Logs, GuardDuty findings, EKS audit logs
→Exam: "investigate GuardDuty findings, understand root cause, visualize attack" → Amazon Detective
→Bukan Inspector (vulnerability scan). Bukan GuardDuty (active detection). Detective = forensics

Guna Bila

Investigate and analyze security findings from GuardDuty, Security Hub, Macie

security investigationforensicsGuardDuty findingsroot causebehavior graphpost-incident

📎 What is Amazon Detective?

D1 · Secure

Inspector

Amazon Inspector

"Scanner kelemahan — CVE/vuln untuk EC2, ECR, Lambda (continuous, automatic)"

🎯 Sebab Apa Wujud

Wujud sebab software kau ada ribuan package/library — mana satu ada known vulnerability (CVE)? Tak mungkin check manual, dan CVE baru keluar setiap hari. Inspector scan EC2/ECR/Lambda secara BERTERUSAN — auto re-scan bila CVE baru keluar atau code berubah — jadi kau tahu "package X versi Y aku ada lsubang" sebelum penyerang jumpa. Beza dengan GuardDuty: Inspector cari LUBANG (potensi), GuardDuty cari PENCEROBOH (sedang berlaku).

Apa Dia

Pengimbasan kelemahan automatik dan BERTERUSAN untuk EC2, ECR container images, dan Lambda. Detect CVEs, OS + programming-language package vulnerabilities, dan unintended network exposure / network reachability. Auto re-scan bila CVE baru keluar atau image/function berubah. Aktif sekali → semua scan type auto-on (Lambda code scanning optional).

⚡ Quick Sifir — hafal ni

▪Inspector = CVE/vulnerability scan, target EC2 + ECR images + Lambda
▪2 jenis scan: (1) Network Reachability = port/route mana terdedah ke internet · (2) Host/Package Vulnerability = CVE dalam OS + library (guna SSM Agent atau EBS snapshot agentless)
▪CONTINUOUS — auto re-scan bila CVE baru atau resource berubah
▪Inspector cari LUBANG (vuln/CVE). GuardDuty cari PENCEROBOH (aktiviti jahat)
▪Scan ECR image SEBELUM deploy = Inspector. Keyword "CVE/patch/vulnerability" = Inspector
▪Bukan Macie (PII S3), bukan Detective (siasat finding)

💡 Exam Scenario

"Audit EC2 instances untuk known CVEs dan security misconfigurations" → Amazon Inspector. "Scan container image dalam ECR sebelum deploy untuk vulnerability" → Inspector ECR scanning. Bukan GuardDuty (yang untuk active threats dari logs).

🪤 Perangkap Soalan

Q: Nak scan container image dalam ECR untuk known CVE sebelum deploy ke production. Guna apa?

⚠ Umpan: GuardDuty — sebab dia threat detection, mesti detect benda bahaya dalam image. SALAH: GuardDuty baca logs runtime, tak scan image untuk CVE.

✓ Betul: Amazon Inspector (ECR scanning). Keyword "CVE/vulnerability/scan image" = Inspector. GuardDuty untuk aktiviti jahat masa nyata.

🧠 Cara Mudah Ingat

→Inspector = vulnerability/CVE scan (software lemah). GuardDuty = threat detection (aktiviti jahat dari logs). Beza ni THE exam trap
→3 target: EC2, ECR container images, Lambda functions. Aktif sekali → auto enroll semua (Lambda CODE scanning optional, enable bila-bila)
→EC2 scan guna SSM agent ATAU EBS snapshot (agentless/hybrid mode) — detect CVE, OS + language package vuln, dan network reachability
→CONTINUOUS, bukan one-off — auto re-scan bila ada CVE baru atau resource berubah, generate findings
→Findings boleh push ke Security Hub + EventBridge untuk automated remediation
→Bukan Macie (PII dalam S3). Bukan Detective (siasat finding). Inspector = "apa software aku ada known vulnerability?"
→Analogi: Inspector = Puspakom 🔧 — periksa "kereta" (EC2/ECR/Lambda) cari karat/defect (CVE/vulnerability) sebelum lulus jalan; continuous = auto re-check tiap kali ada recall (CVE) baru keluar.

Guna Bila

Find OS/software vulnerabilities, CVEs, unintended network exposure in EC2, ECR images, Lambda

vulnerability scanningCVEEC2ECRLambdacontinuousnetwork reachabilitypackage vulnerabilityautomatedsecurity findingsSSM agentagentless

📎 Amazon Inspector scan types

D1 · Secure

Macie

Amazon Macie

"Pemburu data sensitif dalam S3 — ML scan PII, credentials, financial data"

🎯 Sebab Apa Wujud

Wujud sebab orang tersilap upload data sensitif (IC, credit card, passport, credentials) ke S3 tanpa sedar — dan kalau bucket tu public, habis bocor + langgar GDPR/PCI. Kau ada beribu bucket, mustahil check manual setiap object. Macie guna ML + pattern matching scan S3 cari PII, dan alert bila bucket jadi public atau ada data sensitif. Jadi kau jumpa kebocoran SEBELUM jadi insiden.

Apa Dia

Macie adalah data security service yang guna machine learning dan pattern matching untuk discover sensitive data dalam S3. Ia maintain inventory semua S3 buckets, monitor access control, dan alert bila bucket jadi publicly accessible atau ada sensitive data terdetect.

⚡ Quick Sifir — hafal ni

▪Macie = cari PII/sensitive data dalam S3 SAHAJA (bukan RDS/EBS)
▪Detect: PII (IC, passport), financial (credit card), credentials, IP
▪Keyword Macie: "PII", "sensitive data", "GDPR", "S3 data discovery"
▪Macie = data dalam S3. GuardDuty = threat dari logs. Inspector = CVE software

💡 Exam Scenario

"Audit S3 buckets untuk cari data sensitif yang ter-upload secara tak sengaja" → Amazon Macie. Keyword: PII, sensitive data, S3 data discovery.

🪤 Perangkap Soalan

Q: Compliance nak pastikan takde credit card / IC tersilap upload ke S3 buckets syarikat. Guna apa?

⚠ Umpan: GuardDuty — sebab dia monitor S3 (S3 Protection) untuk benda mencurigakan. SALAH: GuardDuty detect AKSES jahat, bukan KANDUNGAN PII.

✓ Betul: Amazon Macie — scan KANDUNGAN object S3 cari PII/sensitive data guna ML. Keyword "PII/sensitive data dalam S3" = Macie.

🧠 Cara Mudah Ingat

→Macie KHUSUS untuk S3 — bukan untuk RDS, EBS, atau services lain
→Detect: PII (nama, IC, passport), financial data (credit card), credentials, intellectual property
→Dua jenis discovery: (1) Automated sensitive data discovery — continuous sampling. (2) Sensitive data discovery jobs — targeted, scheduled
→Macie generate dua jenis findings: Policy findings (bucket jadi public/misconfigured) + Sensitive data findings (PII found in object)
→Integrate dengan EventBridge dan Security Hub untuk automated remediation workflow
→Exam: "detect PII or sensitive data accidentally uploaded to S3" → Amazon Macie. Bukan GuardDuty (threats), bukan Inspector (vulnerabilities)
→Analogi: Macie = anjing pengesan 🐕 di airport — hidu "beg" (S3 objects) cari barang sensitif (PII, passport, credit card). Tapi dia hanya kawal terminal S3 — bukan RDS/EBS.
→PRICING: Macie = $0.10/GB untuk automated sensitive-data discovery (bucket inventory + evaluation murah) + per-GB untuk sensitive-data discovery jobs (scan kandungan). Free 30 hari trial. Cost discriminator: scan kandungan object MAHAL → guna automated sampling dulu, target job hanya bucket berisiko.

Guna Bila

Discover and protect sensitive data in S3: PII, credentials, financial data, compliance

PII detectionsensitive dataS3ML-baseddata privacyGDPRdata discoverypolicy findingspricing

📎 What is Amazon Macie?

D1 · Secure

Security Hub

AWS Security Hub

"Satu dashboard kumpul SEMUA finding security + compliance score"

🎯 Sebab Apa Wujud

Wujud sebab bila kau dah hidupkan GuardDuty + Inspector + Macie + Access Analyzer, setiap satu ada console & format finding sendiri — security team kena buka 5 tempat, tiap account lain pulak. Penat & senang terlepas. Security Hub kumpul SEMUA jadi satu paparan ternormalisasi (satu format ASFF), satu skor, merentas semua account dalam Organization. So you triage from ONE place instead of five.

Apa Dia

A single dashboard that AGGREGATES security findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager (and partner tools) into one normalized format (ASFF). It also runs automated compliance checks against standards (CIS, PCI DSS, AWS Foundational Best Practices) and gives you a security score.

Security Hub = papan kawalan pusat

Rendering diagram…

Macam pusat kawalan keselamatan bangunan: tiap kamera/sensor (GuardDuty, Inspector, Macie, Access Analyzer) hantar amaran ke SATU bilik kawalan (Security Hub), yang susun semua dalam satu format + bagi skor. INGAT exam: nampak "aggregate findings from multiple security services + compliance score across accounts" → Security Hub, BUKAN GuardDuty (itu satu sumber je).

Security Hub vs sumber findingnya (jangan keliru: aggregator vs detector)

Service	Peranan	Detect sendiri?
Security Hub	Kumpul finding + compliance score (one dashboard)	❌ Tak — aggregator
GuardDuty	Threat detection (logs: VPC Flow, DNS, CloudTrail)	🟢 Ya
Inspector	Vulnerability scan (EC2, ECR images, Lambda)	🟢 Ya
Macie	Sensitive data (PII) discovery dalam S3	🟢 Ya
Detective	Investigate / root-cause sesuatu finding (graph)	🟢 Ya (analisis)

Ingat: Security Hub = "single pane of glass" yang KUMPUL finding + bagi compliance score; ia tak detect apa-apa sendiri. GuardDuty/Inspector/Macie = detector (sumber). Detective = siasat punca selepas finding. Keyword "aggregate/centralize findings + compliance" → Security Hub; "investigate the root cause" → Detective.

⚡ Quick Sifir — hafal ni

▪Security Hub = AGGREGATOR + compliance checker. It does NOT detect threats itself — it collects findings from other services
▪Sumber finding: GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Systems Manager + partner products
▪Compliance standards built-in: CIS AWS Foundations, PCI DSS, AWS Foundational Security Best Practices (FSBP) → security score
▪Semua finding ditukar jadi satu format: ASFF (AWS Security Finding Format)
▪Cross-account: jadikan satu account sebagai delegated administrator dalam Organizations → kumpul finding semua account
▪Boleh auto-remediate: Security Hub finding → EventBridge → Lambda/SSM Automation

🪤 Perangkap Soalan

Q: Syarikat dah hidupkan GuardDuty, Inspector, dan Macie merentas 30 account. Security team penat sebab kena log masuk tiap service, tiap account untuk tengok finding. Mahu SATU paparan berpusat + skor pematuhan (CIS/PCI). Service mana?

⚠ Umpan: Hidupkan GuardDuty di management account, atau guna CloudWatch dashboard. Nampak betul sebab GuardDuty pun ada "findings". SALAH: GuardDuty satu sumber je (threat detection), ia tak kumpul finding Inspector/Macie atau bagi compliance score.

✓ Betul: AWS Security Hub — aggregates findings dari GuardDuty + Inspector + Macie + lagi, normalize ke ASFF, jalankan compliance checks (CIS/PCI/FSBP) untuk security score, merentas semua account. Keyword "single pane of glass / aggregate security findings / compliance score across accounts" → Security Hub.

🧠 Cara Mudah Ingat

→Security Hub TAK detect threat sendiri — ia aggregate. Kalau soalan tanya "detect malicious activity / compromised instance" itu GuardDuty; "central dashboard + compliance" baru Security Hub
→Compliance standards: CIS AWS Foundations Benchmark, PCI DSS, AWS Foundational Security Best Practices → automated checks + security score
→Cross-account: set satu account sebagai delegated administrator via Organizations → satu Security Hub kumpul finding semua member account
→Auto-remediation: Security Hub finding → Amazon EventBridge rule → Lambda function atau SSM Automation document untuk auto-fix
→PRICING: ada per finding ingested + per compliance check (security check) sebulan. Free trial 30 hari. Bukan free tier kekal.
→Exam discriminator: "single pane of glass for security across many AWS accounts" / "continuous compliance check against CIS/PCI" → Security Hub

Guna Bila

Central view of security findings across accounts + compliance checks

Security Hubaggregate findingssingle pane of glasscompliance scoreCISPCI DSSFSBPASFFsecurity posturecentralized securitydelegated administratorcompliance checkspricing

📎 What is AWS Security Hub

D1 · Secure

Firewall Manager

AWS Firewall Manager

"Satu tempat urus WAF/Shield/SG/Network Firewall untuk SEMUA account"

🎯 Sebab Apa Wujud

Wujud sebab dalam Organization dengan banyak account, kalau kau set WAF rule atau Security Group satu-satu per account, mustahil nak pastikan SEMUA account patuh — account baru lahir tanpa WAF, ada team terlupa. Firewall Manager apply policy SEKALI di peringkat Organization, dan ia auto-enforce + auto-cover resource baru. So compliance is automatic, not manual per account.

Apa Dia

A central management service that lets you set up firewall rules (WAF rules, Shield Advanced, Security Groups, Network Firewall, Route 53 Resolver DNS Firewall) ONCE and apply them automatically across all accounts and resources in your AWS Organization — including new accounts/resources created later.

Firewall Manager sebar policy ke semua account

Rendering diagram…

Macam pihak pengurusan pusat hantar SOP keselamatan yang sama ke semua cawangan — cawangan baru buka, terus dapat SOP. INGAT exam: "enforce consistent firewall/WAF rules across ALL accounts in the org, including future ones" → Firewall Manager (perlu Organizations + Config dulu).

Firewall Manager vs WAF vs Shield (siapa buat apa)

Service	Skop	Peranan
Firewall Manager	Seluruh Organization (banyak account)	CENTRAL apply/enforce rules + auto-cover baru
AWS WAF	Satu resource (ALB/CloudFront/API GW)	Tulis rule Layer 7 (SQLi/XSS/rate limit)
Shield Advanced	Resource tertentu	DDoS protection + 24/7 DRT + cost protection

Ingat: Firewall Manager = lapisan PENGURUSAN di atas WAF/Shield/SG/Network Firewall — sebar & enforce merentas Organization. WAF/Shield = enjin sebenar pada satu resource. Keyword "central/across all accounts + auto new accounts" → Firewall Manager; "rule for this one ALB" → WAF.

⚡ Quick Sifir — hafal ni

▪Firewall Manager = CENTRAL enforce firewall policy merentas seluruh Organization (auto-cover account/resource baru)
▪Urus: AWS WAF rules, Shield Advanced, Security Groups, AWS Network Firewall, Route 53 Resolver DNS Firewall
▪WAJIB: AWS Organizations + AWS Config enabled dulu
▪Set policy SEKALI → auto-apply ke semua account; account baru auto-patuh
▪Beza dengan WAF sorang: WAF = tulis rule untuk SATU resource; Firewall Manager = sebar rule ke SEMUA account/resource

🪤 Perangkap Soalan

Q: Syarikat ada 50 account dalam Organizations. Security mahu PASTIKAN setiap ALB di setiap account ada WAF rule yang sama, termasuk account baru yang akan dibuat nanti — tanpa set manual satu-satu. Service mana?

⚠ Umpan: Tulis WAF Web ACL dan attach ke tiap ALB di tiap account. Nampak betul sebab WAF memang buat rule. SALAH: itu manual per resource — account ke-51 lahir, kena buat lagi; senang terlepas, tak scale.

✓ Betul: AWS Firewall Manager — set satu WAF policy di peringkat Organization, ia auto-apply ke semua ALB merentas semua account DAN auto-cover account/resource baru. Keyword "centrally enforce WAF/firewall rules across all accounts incl. new ones" → Firewall Manager, BUKAN WAF sorang-sorang.

🧠 Cara Mudah Ingat

→Prasyarat: AWS Organizations + AWS Config mesti enabled dulu sebelum guna Firewall Manager
→Boleh urus: AWS WAF, Shield Advanced, VPC Security Groups (audit + baseline), AWS Network Firewall, Route 53 Resolver DNS Firewall
→Auto-remediation: kalau ada resource tak patuh policy (cth ALB tanpa WAF), Firewall Manager boleh auto-apply rule yang betul
→Set satu account sebagai Firewall Manager administrator account dalam Organization
→PRICING: $100/bulan per policy (per region) + kos underlying (WAF Web ACL, Shield Advanced, dll)
→Exam discriminator: "centrally configure & manage firewall rules across the entire Organization" / "ensure new accounts automatically comply" → Firewall Manager. Satu resource je → WAF/SG terus

Guna Bila

Centrally manage firewall rules across all accounts in an Organization

Firewall Managercentral firewallacross accountsOrganization wideWAF policyShield Advancedsecurity group policyNetwork Firewall policyDNS Firewallauto enforcecompliancenew accountspricing

📎 AWS Firewall Manager

D1 · Secure

Penetration Testing

AWS Penetration Testing Policy

"AWS bagi pentest 8 services — tak perlu minta kebenaran dulu, tapi DoS dilarang"

🎯 Sebab Apa Wujud

Wujud sebab AWS shared responsibility — pelanggan tanggung security 'IN the cloud', jadi memang patut boleh test app sendiri. Tapi sebab infra AWS dikongsi ramai tenant, AWS tetapkan policy jelas: boleh pentest 8 service tertentu tanpa minta izin dulu, tapi aktiviti yang boleh kacau tenant lain (DoS/DDoS, flooding) tetap dilarang walaupun atas resource sendiri.

Apa Dia

AWS membenarkan pelanggan jalankan security assessment / penetration test pada infrastruktur AWS mereka SENDIRI tanpa kelulusan awal untuk 8 service: EC2, RDS, Aurora, CloudFront, API Gateway, Lambda (+ Lambda@Edge), Lightsail, Elastic Beanstalk. Aktiviti DILARANG (walau atas resource sendiri): DoS/DDoS simulation, port/protocol/request flooding, DNS zone walking.

Contoh Guna

Security team nak test EC2 instances atau RDS databases untuk vulnerabilities — dibenarkan tanpa minta izin AWS terlebih dahulu. Tapi nak uji DDoS resilience → engage AWS DDoS Simulation Testing program dulu.

Pentest policy — 3 kategori aktiviti

🟢 Pre-authorized (NO approval) → 8 service: EC2, RDS, Aurora, CloudFront, API Gateway, Lambda (+ Lambda@Edge), Lightsail, Elastic Beanstalk. Terus test resource sendiri.

🔴 Prohibited (haram, walau resource sendiri) → DoS/DDoS simulation, port flooding, protocol flooding, request flooding, DNS zone walking via Route 53.

🟡 Needs separate program → DDoS / network stress / simulated event testing: kena engage AWS DDoS Simulation Testing program / dapat kebenaran khas dulu.

Decision tree — boleh terus pentest ke tak?

Rendering diagram…

INGAT exam: dua syarat untuk "terus pentest tanpa izin" — (1) salah satu 8 service pre-authorized, DAN (2) bukan aktiviti DoS/DDoS/flooding/zone-walking. Gagal mana-mana satu → tak boleh terus. "request approval first" untuk 8 service tu = jawapan SALAH.

Pentest — boleh terus, haram, atau perlu program lain?

Aktiviti	Status	Tindakan
Vuln scan / pentest EC2, RDS, Aurora, CloudFront, API GW, Lambda, Lightsail, Beanstalk	🟢 Pre-authorized	Terus buat — no approval
Pentest service LUAR 8 senarai tu	🟡 Semak	Rujuk AWS / minta kebenaran dulu
DoS / DDoS / flooding simulation	🔴 Prohibited	Engage AWS DDoS Simulation Testing program
DNS zone walking (Route 53)	🔴 Prohibited	Tak dibenarkan langsung
Test infra AWS underlying / tenant lain	🔴 Prohibited	Tak dibenarkan langsung

Ingat: Tiga kategori: 🟢 8 service = terus pentest tanpa approval; 🔴 DoS/DDoS/flooding/zone-walking = haram walau atas resource sendiri; 🟡 nak uji DDoS resilience = engage AWS DDoS Simulation Testing program. Exam trap: "kena minta approval AWS dulu untuk 8 service" = SALAH; "boleh DDoS sebab resource sendiri" = SALAH.

⚡ Quick Sifir — hafal ni

▪8 service pre-authorized (NO approval): EC2, RDS, Aurora, CloudFront, API Gateway, Lambda, Lightsail, Elastic Beanstalk
▪DILARANG walau atas resource sendiri: DoS/DDoS simulation, port/protocol/request flooding, DNS zone walking
▪Bukan 'kena minta approval dulu', bukan 'boleh test semua' — 8 service spesifik
▪Test resource SENDIRI je, BUKAN AWS underlying infra / tenant lain
▪DDoS simulation perlu engage AWS DDoS Simulation Testing program berasingan
▪AUP (Acceptable Use Policy) = dokumen tetap apa boleh/tak boleh

💡 Exam Scenario

"AWS Acceptable Use Policy", "penetration testing position", "security assessments on AWS" → AWS allow pentest on SOME resources WITHOUT prior authorization. Bukan semua resources, bukan tiada langsung — 8 services spesifik. "DDoS/stress simulation" → prohibited under AUP, perlu AWS DDoS Simulation Testing program. Keyword "request AWS approval first / open support case" untuk 8 service ni → SALAH (dah pre-authorized).

🪤 Perangkap Soalan

Q: Apa pendirian (position) AWS terhadap penetration testing oleh pelanggan?

⚠ Umpan: AWS tak benarkan pentest langsung sebab infra dikongsi. Nampak masuk akal sebab 'jaga tenant lain'. SALAH: AWS memang benarkan pentest pada service tertentu.

✓ Betul: AWS benarkan pentest pada SETENGAH resource (8 service) TANPA kelulusan awal — bukan semua, bukan tiada. Keyword '8 permitted services / no prior authorization'.

Q: Security team nak jalankan pentest pada EC2 & RDS production. Apa langkah PERTAMA yang diperlukan?

⚠ Umpan: Buka AWS Support case / minta kelulusan AWS dulu sebelum mula. Nampak betul sebab 'ini infra AWS, mesti kena izin'. SALAH: AWS dah PRE-AUTHORIZE 8 service ni termasuk EC2 & RDS — tak perlu approval.

✓ Betul: Terus pentest — EC2 & RDS antara 8 service pre-authorized. Keyword 'pentest 8 permitted services' = no prior approval needed.

Q: Pasukan nak uji ketahanan app dengan simulate DDoS volumetrik pada ALB mereka sendiri. Boleh terus buat?

⚠ Umpan: Boleh, sebab ia resource sendiri dan pentest dibenarkan. Nampak betul sebab 'resource saya'. SALAH: DoS/DDoS simulation DILARANG di bawah AUP walaupun atas resource sendiri.

✓ Betul: Tak boleh terus — DDoS simulation prohibited; kena engage AWS DDoS Simulation Testing program berasingan. Keyword 'DDoS/flooding' = prohibited activity.

🧠 Cara Mudah Ingat

→AWS MEMBENARKAN pentest pada 8 services tanpa perlu minta approval — ini exam trick, ramai sangka kena minta dulu
→8 permitted services: EC2, RDS, Aurora, CloudFront, API Gateway, Lambda + Lambda@Edge, Lightsail, Elastic Beanstalk
→PROHIBITED (tetap tak boleh, walau atas resource sendiri): DoS / DDoS simulation, port flooding, protocol flooding, request flooding, DNS zone walking via Route 53
→Test atas resource SENDIRI sahaja — bukan infrastruktur AWS underlying atau resource tenant lain
→SALAH: "AWS tak benarkan pentest langsung" / "Boleh pentest SEMUA resources" — dua-dua salah; jawapan betul = SEBAHAGIAN (8 service) tanpa approval
→Nak uji DDoS resilience? Engage AWS DDoS Simulation Testing program berasingan — bukan pentest biasa
→PRICING: pentest pada 8 service tu PERCUMA (tiada caj AWS untuk kebenaran) — kau bayar hanya resource yang berjalan masa test. AUP = polisi, bukan service berbayar.

Guna Bila

Faham polisi AWS untuk security testing & Acceptable Use Policy

penetration testingpentestsecurity assessmentAUPAcceptable Use Policyno prior approval8 servicesprohibited activitiesDoS DDoS prohibitedDNS zone walkingDDoS simulation testingpre-authorized services

📎 AWS Penetration Testing

D1 · Secure

Security Stack

AWS Security Services — Custom Rules & Integration

"Lego keselamatan AWS — detection auto (ML), protection kau TULIS rules, Security Hub gam semua jadi satu"

🎯 Sebab Apa Wujud

Wujud sebab pelajar hafal service satu-satu tapi exam uji macam mana diorang BERGABUNG — "GuardDuty detect, Detective siasat, Security Hub kumpul" atau "WAF + Shield jaga web". Dan exam suka tukar jawapan ikut keyword arah: tambah "cost-effective" je → tukar dari Shield Advanced ke Standard. Faham peta besar ni = boleh pangkah jawapan reka + baca keyword arah betul-betul, bukan main tembak ikut topik.

Apa Dia

Ini BUKAN satu service — ini gambaran besar macam mana SEMUA security service AWS bekerja sebagai satu sistem berlapis (defense in depth). Dua soalan besar exam: (1) service mana boleh kau TULIS custom rules vs yang auto guna ML/DB AWS; (2) service mana feed/integrate dengan service lain (cth GuardDuty → Detective → Security Hub).

Sistem keselamatan berlapis — macam mana semua bekerja bersama

Rendering diagram…

Bayangkan sistem keselamatan bangunan berlapis: Shield+WAF = pengawal pintu luar (halang penceroboh), Network Firewall = pagar dalaman, GuardDuty/Inspector/Macie = CCTV & sensor (auto), Security Hub = bilik kawalan pusat (1 skrin semua CCTV), Detective = penyiasat, CloudTrail = buku log, KMS = peti besi kunci. INGAT exam: security services AWS direka BEKERJA BERSAMA — bukan berdiri sendiri.

Boleh tulis custom rules ke tak?

Rendering diagram…

INGAT exam: "write custom rules / block specific pattern" → protection service (WAF/Network Firewall), BUKAN detection service. Detection (GuardDuty/Inspector/Macie) guna ML/DB AWS — kau cuma boleh tweak (suppress finding, tambah custom data identifier), tak tulis logic detection sendiri.

Custom rules? + integrate dengan apa (semua security service)

Service	Custom rules?	Integrate / feed dengan
WAF	🟢 Penuh — rule statement, regex, rate-based, IP/geo set, managed groups	CloudFront, ALB, API GW, AppSync, Cognito; Shield Adv; Firewall Manager
Shield Standard	🔴 Tiada (auto sepenuhnya)	Auto semua AWS edge
Shield Advanced	🟢 Custom mitigation (via SRT)	WAF (free), CloudFront/ALB/NLB/EIP/Route 53; Firewall Manager
Network Firewall	🟢 Custom Suricata stateful + stateless rules	VPC (firewall subnet), Transit Gateway; Firewall Manager
GuardDuty	🟡 Separa — suppression rule + threat/trusted IP list (BUKAN detection logic)	Source: CloudTrail/VPC Flow/DNS → Security Hub, Detective, EventBridge
Inspector	🔴 Tiada — AWS-managed CVE database	→ Security Hub, EventBridge
Macie	🟡 Custom data identifier (regex) + allow list	S3 → Security Hub, EventBridge
Detective	🔴 Tiada — auto behavior graph	Source: GuardDuty findings + CloudTrail/VPC Flow
Security Hub	🟢 Custom insight + automation rule + custom action	Aggregate GuardDuty/Inspector/Macie/Access Analyzer → EventBridge
Config	🟢 Custom rule (Lambda / Guard DSL)	→ Security Hub; prasyarat Firewall Manager
IAM	🟢 Custom policy	Hampir semua service
KMS	🟢 Custom key policy	S3/EBS/RDS/hampir semua

Ingat: Protection/access (WAF, Network Firewall, IAM, KMS, Config, Shield Adv) = kau TULIS rules. Detection (GuardDuty, Inspector, Macie, Detective) = AWS auto ML/DB — paling banyak "tweak" je (suppression / custom data identifier / IP list), BUKAN detection logic. Semua detection → feed Security Hub. Keyword "write custom rules / block specific pattern" → WAF/Network Firewall; "aggregate findings" → Security Hub.

Keyword "arah" — tolak jawapan ke versi JIMAT atau PREMIUM

Keyword dalam soalan	Tolak ke	Contoh pasangan
"cost-effective / minimize cost / free / no additional cost"	Versi JIMAT/asas	Shield Standard, Parameter Store, KMS
"maximum / highest / advanced / custom mitigation"	Versi PREMIUM	Shield Advanced, CloudHSM
"compliance / regulatory / FIPS 140-2 Level 3 / single-tenant"	Paling KETAT	CloudHSM
"managed / minimize operational overhead / serverless"	AWS urus	KMS (bukan CloudHSM), Secrets Manager rotation
"automatic / no configuration / ML-based detection"	Auto	GuardDuty
"auto-rotation / rotate credentials"	Auto-rotate	Secrets Manager (bukan Parameter Store)

Ingat: Topik sama, keyword arah tukar jawapan. "cost-effective" di hujung ayat selalu tolak ke versi PERCUMA/murah (Shield Standard, Parameter Store, KMS); "maximum/FIPS/single-tenant" tolak ke premium (Shield Advanced, CloudHSM). Baca habis soalan dulu — keyword arah selalu di hujung.

⚡ Quick Sifir — hafal ni

▪Detection (GuardDuty/Inspector/Macie/Detective) = AWS AUTO guna ML/DB — TAK tulis custom detection logic (tweak je: suppression, custom data identifier, IP list)
▪Protection/Access (WAF/Network Firewall/IAM/KMS/Config/Shield Adv) = kau TULIS custom rules sendiri
▪Security Hub = AGGREGATOR: kumpul finding GuardDuty+Inspector+Macie+Access Analyzer jadi 1 format (ASFF) + compliance — bukan detector
▪Aliran klasik: GuardDuty detect → Detective investigate → EventBridge → Lambda/SSM auto-remediate. CloudTrail = SOURCE GuardDuty
▪Combo web klasik: WAF + Shield Advanced pada CloudFront/ALB (Shield jaga DDoS, WAF jaga L7 + custom rules)
▪Keyword "cost-effective" tolak ke versi JIMAT (Shield Standard, Parameter Store, KMS); "maximum/FIPS/single-tenant" ke PREMIUM (Shield Advanced, CloudHSM)

💡 Exam Scenario

"Write custom rules / block specific SQLi pattern / rate-limit IP" → WAF (atau Network Firewall untuk VPC traffic), BUKAN GuardDuty (ML auto). "Aggregate findings dari banyak security service + compliance score" → Security Hub. "Investigate root cause selepas finding" → Detective. "Cost-effective basic DDoS" → Shield Standard (free), BUKAN Advanced.

🪤 Perangkap Soalan

Q: App perlu perlindungan DDoS asas yang COST-EFFECTIVE, tanpa kos tambahan. Pilih apa?

⚠ Umpan: Shield Advanced — sebab dia maximum DDoS protection, mesti paling selamat. SALAH: Advanced $3,000/bulan; soalan tekankan "cost-effective + no additional cost".

✓ Betul: Shield Standard — FREE, auto, L3/4 DDoS. Keyword "cost-effective / basic / no additional cost" → Standard. (Kalau soalan sebut "maximum / DRT / cost protection" baru Advanced.)

Q: Security team nak TULIS peraturan tersuai untuk block corak SQL injection tertentu + rate-limit satu IP. Service mana?

⚠ Umpan: GuardDuty — sebab dia threat detection, mesti boleh set rule apa nak detect. SALAH: GuardDuty guna ML AWS, kau tak tulis custom detection rules (suppression rule je untuk tapis finding).

✓ Betul: AWS WAF — custom rule statements (SQLi match + rate-based rule). Keyword "write custom rules / block specific pattern / rate limit" → WAF, bukan GuardDuty.

🧠 Cara Mudah Ingat

→GuardDuty "customize" = suppression rule (tapis false-positive finding) + trusted IP / threat IP / entity list — BUKAN tulis detection logic sendiri (itu ML AWS)
→Macie "customize" = custom data identifier (regex sendiri) + allow list — untuk format PII khusus (cth nombor IC Malaysia)
→Config custom rule = tulis guna Lambda atau Guard DSL untuk compliance check sendiri (selain managed rules)
→Semua detection finding boleh push ke EventBridge → Lambda / SSM Automation untuk auto-remediation — corak yang exam suka uji
→Firewall Manager = lapisan ATAS yang sebar & enforce WAF/Shield Adv/SG/Network Firewall/DNS Firewall merentas seluruh Organization (perlu Organizations + Config dulu)
→Combo klasik exam: WAF + Shield Advanced pada CloudFront/ALB · Secrets Manager auto-rotate RDS · KMS encrypt S3/EBS/RDS
→PRICING (rujuk card masing-masing): Shield Advanced $3,000/bln + WAF free; WAF $5/web ACL + $1/rule + $0.60/1M req; GuardDuty/Macie/Inspector/Security Hub = pay-as-you-go (no free tier kekal); Shield Standard + Parameter Store Standard = FREE. Keyword "cost-effective" → pilih yang free/murah.

Guna Bila

Faham service mana boleh custom rules vs auto, macam mana security services integrate, + keyword cost tolak jawapan ke versi jimat/premium

security stackdefense in depthlayered securitycustom rulessuppression rulescustom data identifierthreat IP listintegrationwork togetheraggregate findingsASFFEventBridgeauto-remediationSecurity HubGuardDuty DetectiveWAF Shield combocost-effectiveShield Standard vs Advancedkeyword directionpricing

📎 GuardDuty suppression rules 📎 GuardDuty entity & IP lists (customize detection)📎 Macie custom data identifiers 📎 What is AWS Security Hub 📎 AWS Config custom rules

🔐Data Protection↑ Top

D1 · Secure

KMS

AWS Key Management Service

"Simpan dan urus kunci enkripsi"

🎯 Sebab Apa Wujud

Wujud sebab encrypt data sendiri = mimpi ngeri: kau kena simpan kunci di mana? Kalau kunci bocor, habis semua data. Kalau kunci hilang, data tak boleh baca selamanya. KMS pegang kunci master dalam hardware AWS (kunci master TAK PERNAH keluar KMS), audit setiap guna dalam CloudTrail, dan buat envelope encryption (kunci data di-encrypt dengan kunci master) supaya kau encrypt data besar laju tanpa hantar semua ke KMS. Jadi kau dapat encryption tanpa pening urus kunci.

Apa Dia

Mencipta dan mengurus cryptographic keys untuk encrypt/decrypt data di pelbagai AWS services

Contoh Guna

Encrypt S3, RDS, EBS — enable SSE-KMS. Semua penggunaan key di-audit dalam CloudTrail. KMS key rotation auto setahun sekali

Pilih KMS key type yang betul

Rendering diagram…

Dedicated HW + FIPS Level 3 + kawalan eksklusif → CloudHSM. Sign/asymmetric → Asymmetric CMK. Nak custom policy + rotation + audit penuh → Customer Managed Key. Terhad satu service, tak nak customize → AWS Managed Key. Zero management → AWS Owned Key.

Cara ingat — cop mohor diraja (symmetric vs asymmetric)

Rendering diagram…

Asymmetric = cop mohor diraja: hanya raja ada cop (private key) untuk SIGN; sesiapa pun boleh tengok & sahkan cop tu tulen (public key VERIFY) tapi tak boleh tiru. Itu pengasingan "only sender signs, others verify". Symmetric = satu kunci pintu: sesiapa pegang boleh buat semua op — tak boleh asingkan sign dari verify. INGAT exam: "digital signing / sign and verify / only sender signs" → Asymmetric (Sign and Verify); encryption biasa AWS service → Symmetric.

KMS vs CloudHSM

Aspect	AWS KMS	AWS CloudHSM
Tenancy	Multi-tenant, shared (AWS managed)	🟢 Single-tenant, dedicated hardware
Who controls keys	AWS manages HSM; you manage key policy	🟢 You fully control — AWS cannot access
FIPS 140-2	Level 2 (overall)	🟢 Level 3
Key types	Symmetric + asymmetric, AWS service integration	Symmetric + asymmetric, your own crypto (PKCS#11, JCE)
Effort	🟢 Low — fully managed	High — you manage cluster, users, backups
Use when	Default encryption for S3/RDS/EBS, easy & cheap	Regulatory need for dedicated HW + exclusive control

Ingat: "Customer-exclusive control / dedicated hardware / FIPS 140-2 Level 3" → CloudHSM. Anything else (normal encrypt-at-rest for AWS services) → KMS. KMS boleh guna CloudHSM sebagai custom key store kalau perlu both.

Symmetric vs Asymmetric KMS key — bila pilih yang mana

Aspect	Symmetric key	Asymmetric key
Kunci	1 kunci sama (encrypt = decrypt)	🟢 Pasangan public + private
Digital signing?	❌ Tak boleh (kunci sama untuk semua op)	🟢 Boleh — private SIGN, public VERIFY
Key usage	Encrypt & Decrypt (HMAC = Generate/Verify MAC)	Pilih SATU masa create (immutable): "Sign & Verify" ATAU "Encrypt & Decrypt"
Keluar KMS?	Tak pernah keluar	Public key boleh download/share; private TAK keluar
AWS service integration (SSE-KMS S3/RDS/EBS)	🟢 Ya — AWS service guna symmetric SAHAJA	❌ Tak boleh untuk SSE
Guna bila	Encryption biasa AWS (default, senang)	Sign/verify dokumen, atau encrypt oleh pihak LUAR yang tak boleh call KMS

Ingat: Keyword "digital signing / sign and verify / verify authenticity + not tampered / ONLY sender signs, others verify" → Asymmetric key (key usage "Sign and Verify"). Encryption biasa untuk AWS service → Symmetric (default). Symmetric TAK boleh digital signing sebab kunci sama = sesiapa yang verify pun boleh sign (tak boleh asingkan). Cop mohor diraja: private = cop raja (sign), public = sesiapa sahkan cop tu tulen (verify).

⚡ Quick Sifir — hafal ni

▪Envelope encryption = data key encrypt data, KMS master key encrypt data key (master tak pernah keluar KMS)
▪CMK (Customer Managed) = full control: custom policy + rotation + audit. Exam keyword "lifecycle/rotation/access control"
▪AWS Managed key = auto, terhad 1 service, TAK boleh customize. AWS Owned = free, tak boleh audit
▪Symmetric = encrypt+decrypt (default, AWS service SSE guna ni SAHAJA). Asymmetric = public+private pair (sign/verify atau encrypt oleh pihak luar)
▪Asymmetric ada 2 KEY USAGE (pilih masa create, immutable): "Sign & Verify" (digital signature) ATAU "Encrypt & Decrypt". Digital signing → Sign & Verify. Private TAK keluar KMS; public boleh download
▪Multi-Region key = same key material across regions, elak cross-region API call
▪FIPS 140-2 Level 3 + dedicated hardware + AWS tak boleh access = CloudHSM, BUKAN KMS
▪Key Policy = ROOT of trust KMS. By default WAJIB key policy bagi akses (atau delegate ke IAM lewat Principal=account-root). IAM Allow SAHAJA tak cukup kalau key policy tak izin — even admin kena blok
▪Cross-account KMS = DUA kunci (macam S3/SQS): IAM policy (source) AND KMS Key Policy sebut Principal source acct (destination). Set satu belah je → Access Denied

🪤 Perangkap Soalan

Q: Perlu "comprehensive lifecycle management, key rotation, auditing & access control" untuk encryption key. Guna apa?

⚠ Umpan: AWS Managed Key — sebab dia pun auto-rotate & ada dalam account kau. SALAH: AWS Managed Key TAK boleh customize policy/rotation.

✓ Betul: Customer Managed Key (CMK). Keyword "lifecycle/custom rotation/access control" = CMK. AWS Managed key restricted, tak boleh kau kawal.

Q: Regulatory wajib dedicated single-tenant hardware, FIPS 140-2 Level 3, AWS langsung tak boleh akses kunci. KMS?

⚠ Umpan: KMS dengan CMK — sebab CMK kau yang kawal penuh. SALAH: KMS multi-tenant, FIPS Level 2, AWS still urus HSM.

✓ Betul: CloudHSM — single-tenant dedicated hardware, FIPS 140-2 Level 3, AWS tak boleh access. Keyword "dedicated HW + Level 3 + exclusive control" = CloudHSM.

Q: App e-commerce multinasional simpan data encrypted merentas banyak region. Latency naik bila data diakses di LUAR region tempat KMS key dicipta. Cara terbaik kurangkan latency tapi kekal encrypted ikut region?

⚠ Umpan: Anggap single-Region KMS key globally available (D), atau re-encrypt data dengan key region destinasi setiap kali, atau simpan semua data dalam SATU region (A). Nampak betul sebab "guna key region tu". SALAH: single-Region key TERIKAT region ciptaan (cross-region call = punca latency tu); re-encrypt = overhead besar; satu region = kalahkan tujuan multinasional.

✓ Betul: Multi-Region KMS Keys — replicate primary key ke region tempat data diakses. Replica share SAME key ID + key material, jadi decrypt jadi LOCAL dalam region itu → hapus cross-region KMS API call. Keyword "cross-region latency + kekal secure region-specific encryption" → Multi-Region keys. (Disable encryption = NEVER jawapan.)

Q: User dalam Account A perlu decrypt S3 object dalam Account B yang di-encrypt guna KMS CMK Account B. Admin dah bagi IAM policy kms:Decrypt + s3:GetObject dalam Account A. Masih "Access Denied" pada decrypt. Apa yang tertinggal?

⚠ Umpan: IAM dah bagi kms:Decrypt, jadi patut boleh. Anggap key boleh diguna selagi IAM Allow — sama macam akses S3/SQS dalam account sendiri.

✓ Betul: KMS Key Policy (di Account B) belum sebut Principal Account A. Key policy = ROOT of trust — IAM Allow sahaja tak cukup merentas account; key policy WAJIB delegate/izin Principal source acct. Keyword "cross-account KMS decrypt" → IAM policy (source) + Key Policy (destination) serentak.

Q: Files mesti digitally signed; receiver kena verify authenticity + sahkan tak diubah; HANYA sending app boleh sign, orang lain verify je. KMS key jenis apa?

⚠ Umpan: Symmetric KMS key — sebab default & senang. SALAH: symmetric guna kunci SAMA untuk semua operasi, jadi sesiapa yang boleh verify pun boleh sign — tak boleh asingkan "hanya penghantar sign".

✓ Betul: Asymmetric KMS key, key usage "Sign and Verify". Private key (sending app sahaja) sign; public key (boleh kongsi) verify. Pengasingan sign-vs-verify HANYA boleh dengan asymmetric. Keyword "digital signing / verify authenticity / only sender signs, others verify" → Asymmetric Sign and Verify.

Q: Pilih asymmetric KMS key untuk digital signing — key usage mana yang betul?

⚠ Umpan: Asymmetric "Encrypt and Decrypt" — sebab asymmetric, jadi nampak betul. SALAH: itu untuk encryption guna public/private, BUKAN signing. Satu asymmetric key buat SATU benda je.

✓ Betul: Asymmetric "Sign and Verify". Asymmetric key pilih key usage masa create & TAK boleh tukar: "Sign and Verify" (digital signature) ATAU "Encrypt and Decrypt" (encrypt by external party). Digital signing → Sign and Verify.

🧠 Cara Mudah Ingat

→Symmetric KMS keys: satu 256-bit key untuk encrypt + decrypt; never leaves KMS unencrypted; AWS services pakai symmetric
→Asymmetric KMS keys: public/private key pair; untuk digital signing atau asymmetric encryption; hanya public key boleh export
→For digital signing (only sender signs): Asymmetric. For transparent encrypt+decrypt (no own/manage): Symmetric AWS managed key
→Multi-Region KMS keys: replicated across regions, same key material — elak cross-region API calls, reduce latency untuk global apps
→KMS key policy + VPC endpoint: guna condition "aws:SourceVpce" (endpoint ID) bukan "aws:SourceVpc" (VPC ID) untuk least-privilege
→3 jenis KMS key: (1) AWS Owned keys — fully managed by AWS, free, tak boleh view/manage/audit langsung. (2) AWS Managed keys (aws/service-name) — dalam account anda tapi RESTRICTED kepada satu service, rotation automatic (anual), TAK boleh customize policy/rotation. (3) Customer Managed Keys (CMK) — FULL control: custom key policy, manual/auto rotation, enable/disable, audit penuh dalam CloudTrail
→Exam trick: "comprehensive lifecycle management, key rotation, auditing & access control" = ciri CUSTOMER Managed Key (CMK), BUKAN AWS Managed Key — AWS Managed Key tak boleh di-customize oleh user

Guna Bila

Encrypt data at rest, manage encryption keys

encryption at restCMKkey rotationSSE-KMSenvelope encryptionCloudTrail auditasymmetric keyssymmetric keysdigital signingsign and verifykey usageverify authenticitytamperpublic keyprivate keyonly sender signsmulti-region keysaws:SourceVpceCloudHSMFIPS 140-2single-tenantcustom key storekey policycross-account KMSroot of trustcross-account decrypt

📎 AWS KMS concepts 📎 Rotating AWS KMS keys 📎 Asymmetric keys in AWS KMS

D1 · Secure

Secrets Manager

AWS Secrets Manager

"Simpan password apps, auto-rotate"

🎯 Sebab Apa Wujud

Wujud sebab developer suka hardcode password dalam code/env var → bila code bocor (GitHub leak), password bocor. Dan tukar password manual = kena update semua app, leceh, jadi orang malas rotate. Secrets Manager simpan secret encrypted, app retrieve masa runtime (tak pernah dalam code), dan AUTO-ROTATE (Lambda tukar password di RDS + update secret serentak) tanpa downtime — jadi rotation jadi senang, orang buat betul-betul.

Apa Dia

Menyimpan, mendapatkan semula dan memutar rahsia secara automatik tanpa perlu update aplikasi

Contoh Guna

Lambda function perlu DB password — jangan letak dalam env var atau code. Store dalam Secrets Manager, Lambda retrieve masa runtime. Auto-rotate setiap 30 hari

Secrets Manager vs Parameter Store

Aspect	Secrets Manager	SSM Parameter Store
Built for	Secrets (DB creds, API keys, OAuth tokens)	Config data + secrets (AMI IDs, license codes, passwords)
Auto-rotation	🟢 Built-in (Lambda, scheduled)	No native rotation (boleh reference Secrets Manager)
Cost	Paid per secret + per API call	🟢 Standard tier free (Advanced tier paid)
Encryption	Always KMS-encrypted	Plaintext (String) or KMS (SecureString)
Cross-region replicate	🟢 Yes, built-in	No (per-region)
Use when	Rotate DB creds automatically, RDS/Redshift integration	Store config cheaply, occasional secrets, hierarchy

Ingat: "Auto-rotate database credentials" → Secrets Manager. "Cheap/free config + plain parameters, no rotation needed" → Parameter Store. Parameter Store boleh reference Secrets Manager secrets via /aws/reference/secretsmanager.

⚡ Quick Sifir — hafal ni

▪Secrets Manager = AUTO-ROTATE built-in (Lambda). Parameter Store = TAKDE native rotation
▪Auto-rotate DB credentials (RDS/Aurora/Redshift/DocumentDB) → Secrets Manager. Itu keyword pembeza
▪DB luar/on-prem/3rd-party? Masih Secrets Manager — tulis CUSTOM Lambda rotation function
▪Parameter Store Standard = FREE. Secrets Manager = bayar per secret + per API call
▪Config murah / tak perlu rotate (AMI ID, license) → Parameter Store (SecureString utk encrypt)
▪Secrets Manager always KMS-encrypted + cross-region replicate built-in
▪PRICING: $0.40/secret/bulan + $0.05/10,000 API call (us-east-1). Free 30-hari trial. Parameter Store Standard FREE — itu sebab config biasa letak Parameter Store

💡 Exam Scenario

Formula poket: "store password / API key / DB credentials" + "rotate automatically / rotate regularly / every N days" + "least operational overhead" → AWS Secrets Manager (configure automatic rotation). BUKAN Parameter Store (takde native rotation, kena code sendiri). Config biasa tak rahsia (AMI ID, URL, license) + kos rendah → SSM Parameter Store Standard (FREE).

🪤 Perangkap Soalan

Q: Nak simpan DB password dan AUTO-ROTATE setiap 30 hari tanpa ubah app. Parameter Store SecureString?

⚠ Umpan: Parameter Store SecureString — sebab dia free & encrypted dengan KMS, jimat. SALAH: Parameter Store takde native rotation.

✓ Betul: Secrets Manager — satu-satunya yang ada built-in auto-rotation (Lambda). Keyword "auto-rotate credentials" = Secrets Manager.

Q: Nak simpan AMI ID, config value, license code yang jarang berubah, kos serendah mungkin. Secrets Manager?

⚠ Umpan: Secrets Manager — sebab dia memang untuk simpan benda rahsia, selamat. SALAH: bayar per secret, mahal untuk config biasa.

✓ Betul: SSM Parameter Store (Standard tier FREE). Config + tak perlu rotation → Parameter Store. Pakai SecureString kalau perlu encrypt.

Q: Database on-premises (bukan RDS) perlu credentials di-rotate auto setiap 90 hari, least operational overhead. Boleh guna Secrets Manager ke?

⚠ Umpan: Tak boleh — Secrets Manager rotation untuk RDS/Aurora je, jadi pilih Parameter Store + cron sendiri. SALAH: itu lagi banyak kerja.

✓ Betul: Boleh — Secrets Manager + CUSTOM Lambda rotation function untuk database non-AWS/on-prem. Native rotation untuk RDS/Aurora/Redshift/DocumentDB; selain tu tulis Lambda. Tetap "least operational overhead" vs build sistem rotation dari kosong.

Guna Bila

Store dan auto-rotate credentials, API keys, DB passwords

auto-rotationcredentialsAPI keysno hardcoded secretsLambda integrationcustom rotationon-premises databaseParameter StoreSecureStringcross-region replicationKMSRDSAuroraDocumentDBpricingleast operational overhead

📎 Secrets Manager vs Parameter Store 📎 Rotate secrets (custom Lambda)

D1 · Secure

S3 Object Lock

Amazon S3 Object Lock

"Lock file — tak boleh delete atau ubah (WORM)"

🎯 Sebab Apa Wujud

Wujud sebab regulator (SEC 17a-4, FINRA) wajibkan rekod kewangan/perubatan disimpan tak boleh diubah atau dipadam untuk bertahun — dan masalahnya admin (atau penyerang yang curi kredential admin) boleh padam objek S3 macam biasa. Object Lock kunci objek dalam model WORM (Write Once Read Many): sekali lock, tiada sesiapa — termasuk root dalam Compliance mode — boleh padam/ubah sampai retention tamat. Jadi kau penuhi audit/compliance tanpa risiko padam tak sengaja atau niat jahat.

Apa Dia

Menghalang objek S3 dari dipadam atau di-overwrite untuk tempoh tetap (retention period) atau selamanya (legal hold) — WORM model untuk pematuhan kawal selia. WAJIB Versioning ON pada bucket.

Contoh Guna

Financial records kena simpan 7 tahun tak boleh diubah — enable Object Lock Compliance mode + retention period 7 tahun. Governance mode untuk internal policy yang admin boleh override.

Compliance vs Governance vs Legal Hold

Aspect	Compliance mode	Governance mode	Legal Hold
Siapa boleh padam/ubah	🟢 TIADA sesiapa — termasuk root account	Hanya user dengan s3:BypassGovernanceRetention	TIADA sampai legal hold di-remove
Boleh shorten retention?	Tidak — mode & period tak boleh dikurangkan	Boleh, kalau ada bypass permission	Takde retention period — no expiry
Ada tarikh tamat?	🟢 Ya, Retain Until Date	Ya, Retain Until Date	❌ Kekal sampai di-remove manual
Cara override	Mustahil (satu-satunya jalan: tutup AWS account)	x-amz-bypass-governance-retention:true + permission	s3:PutObjectLegalHold untuk remove
Guna bila	Regulatory ketat (SEC 17a-4, FINRA, CFTC)	Internal policy, test retention dulu	Litigation / siasatan, tempoh tak tentu

Ingat: "Tak boleh padam langsung walau root" → Compliance. "Admin masih boleh override bila perlu" → Governance. "Hold tanpa tarikh tamat" → Legal Hold. Semua mode WAJIB Versioning ON dulu.

⚡ Quick Sifir — hafal ni

▪Object Lock WAJIB Versioning ON dulu
▪Compliance mode = TIADA sesiapa boleh padam (root pun tak), sampai retention tamat
▪Governance mode = boleh override KALAU ada s3:BypassGovernanceRetention + header
▪Legal Hold = TAKDE expiry, independent dari retention, sampai di-remove manual
▪Retention boleh EXTEND, tak boleh SHORTEN dalam Compliance mode
▪Keyword 'SEC 17a-4/FINRA/mutlak tak boleh ubah' = Compliance mode

💡 Exam Scenario

"Records mesti immutable, takde sesiapa termasuk root boleh padam dalam tempoh retention" → Compliance mode. "Admin tertentu masih perlu boleh override/padam" → Governance mode (perlu s3:BypassGovernanceRetention). "Hold tanpa tarikh tamat sampai siasatan selesai" → Legal Hold.

🪤 Perangkap Soalan

Q: Rekod kewangan kena simpan 7 tahun, mutlak tak boleh dipadam atau diubah oleh sesiapa termasuk admin/root, untuk patuhi SEC 17a-4. Setting mana?

⚠ Umpan: Governance mode dengan retention 7 tahun — sebab dia pun halang delete. Nampak betul sebab 'ada retention'. SALAH: Governance boleh di-override oleh user dengan s3:BypassGovernanceRetention, jadi tak mutlak.

✓ Betul: Compliance mode + retention 7 tahun. Keyword 'tiada sesiapa termasuk root, regulatory' = Compliance, BUKAN Governance.

Q: Dokumen kena di-hold untuk litigation, tapi tak tahu bila siasatan habis (tiada tarikh tamat). Guna apa?

⚠ Umpan: Compliance mode dengan retention period panjang. Nampak betul sebab 'tak boleh padam'. SALAH: Compliance mode WAJIB ada Retain Until Date (tarikh tetap), bukan hold terbuka.

✓ Betul: Legal Hold — takde expiry, kekal sampai di-remove manual. Keyword 'litigation / tak tahu bila habis / no end date' = Legal Hold.

🧠 Cara Mudah Ingat

→Object Lock WAJIB ada S3 Versioning ON — kalau soalan kata versioning off, enable dulu
→Compliance mode: SATU-SATUNYA cara padam sebelum retention tamat = tutup AWS account. Root pun tak boleh
→Governance mode: override perlu DUA benda — permission s3:BypassGovernanceRetention + header x-amz-bypass-governance-retention:true
→Legal Hold = TAKDE expiry, independent dari retention period. Boleh ada legal hold + retention period serentak
→Retention period boleh EXTEND (Retain Until Date lebih lewat) tapi tak boleh shorten dalam compliance mode
→Exam: "WORM untuk SEC/FINRA, mutlak tak boleh ubah" → Compliance. "Hold dokumen untuk litigation, tak tahu bila habis" → Legal Hold

Guna Bila

WORM compliance, prevent deletion/modification

WORMcomplianceretention periodGovernance modeCompliance modelegal holdversioning requiredBypassGovernanceRetentionimmutableSEC 17a-4FINRARetain Until Date

📎 S3 Object Lock overview

D1 · Secure

S3 Glacier Vault

Amazon S3 Glacier Vault Lock & Access Policy

"Vault Lock = immutable compliance. Vault Access Policy = mutable access control"

🎯 Sebab Apa Wujud

Wujud sebab arkib jangka panjang dalam Glacier pun perlu jaminan compliance — regulator nak bukti retention policy TAK BOLEH diubah oleh sesiapa, walaupun admin sendiri. Vault Access Policy biasa boleh diedit bila-bila (tak cukup untuk audit). Vault Lock Policy pula, sekali locked, jadi IMMUTABLE selamanya — enforce WORM/retention secara mutlak. Ada 24-jam in-progress window supaya kau boleh test policy dulu sebelum commit, elak tersilap kunci policy yang salah.

Apa Dia

Dua policies berbeza: (1) Vault Lock Policy = IMMUTABLE selepas locked, enforce compliance controls (WORM, retention). Cannot be changed. (2) Vault Access Policy = MUTABLE, untuk access control (siapa boleh access). Untuk compliance = Vault Lock. Nota: Glacier vault (standalone) sekarang legacy — AWS galak guna S3 Glacier storage classes untuk arkib baru.

Vault Lock Policy vs Vault Access Policy

Aspect	Vault Lock Policy	Vault Access Policy
Boleh ubah lepas set?	❌ IMMUTABLE selepas locked	🟢 MUTABLE — boleh ubah bila-bila
Tujuan	Compliance / WORM / retention enforcement	Access control biasa (siapa boleh access)
Proses set	2 langkah: initiate (in-progress) → complete dalam 24 jam	Terus attach, no lock step
Boleh test dulu?	🟢 Ya — 24 jam in-progress window untuk validate sebelum complete	N/A — boleh edit bila-bila
Guna bila	Regulatory retention, deny deletes	Temporary / kerap berubah, grant reads

Ingat: "Compliance, retention, tak boleh diubah lagi" → Vault Lock Policy. "Access control yang fleksibel/sementara" → Vault Access Policy. Boleh guna kedua-dua serentak (Lock deny deletes + Access grant reads).

⚡ Quick Sifir — hafal ni

▪Vault Lock Policy = IMMUTABLE lepas locked (compliance/WORM/retention)
▪Vault Access Policy = MUTABLE, untuk access control biasa (boleh edit bila-bila)
▪Lock 2 langkah: initiate (in-progress, 24 jam test) → complete guna lock ID
▪Tak complete dalam 24 jam → policy auto-deleted
▪Compliance/retention → Vault Lock, BUKAN Vault Access
▪'Legal hold' = S3 Object Lock feature, BUKAN Glacier Vault

💡 Exam Scenario

"Lock retention policy supaya takde sesiapa boleh ubah/padam archive untuk compliance" → Vault Lock Policy. "Grant business partner read access yang boleh berubah-ubah" → Vault Access Policy. "Legal hold tanpa tarikh tamat" → BUKAN Glacier, itu S3 Object Lock feature.

🪤 Perangkap Soalan

Q: Arkib Glacier kena ada retention policy yang TAK BOLEH diubah oleh sesiapa untuk compliance. Policy mana?

⚠ Umpan: Vault Access Policy dengan deny delete — sebab dia kawal access. Nampak betul sebab 'control access'. SALAH: Vault Access Policy MUTABLE, boleh diedit/buang bila-bila → tak penuhi compliance immutable.

✓ Betul: Vault Lock Policy — IMMUTABLE lepas locked. Keyword 'tak boleh diubah / WORM / compliance retention' = Vault Lock Policy.

Q: Kau dah initiate Vault Lock policy tapi belum complete dalam 24 jam. Apa jadi?

⚠ Umpan: Policy auto-locked sebab dah initiate. Nampak betul sebab 'dah mula proses lock'. SALAH: lock cuma sah lepas langkah COMPLETE guna lock ID.

✓ Betul: Policy auto-DELETED — kena initiate semula. Keyword '24-hour in-progress window, complete dengan lock ID' = belum lock kalau tak complete.

🧠 Cara Mudah Ingat

→Vault Lock Policy: IMMUTABLE once locked — enforce WORM, retention periods, tag-based deny. Cannot be modified or deleted
→Vault Access Policy: MUTABLE — for access control only. Can be changed anytime
→Lock process 2 langkah: (1) initiate → in-progress state + lock ID, ada 24 JAM untuk test/validate; (2) complete guna lock ID. Tak complete dalam 24 jam → policy auto-deleted
→Best practice: create vault → complete Vault Lock policy → baru upload archives, supaya policy apply pada semua
→For compliance/retention requirements → always Vault Lock Policy, BUKAN Vault Access Policy
→"Set a legal hold" bukan Glacier Vault feature — legal hold ialah S3 Object Lock feature
→Exam: "prevent deletion of archives, compliance, WORM" → Vault Lock Policy + set retention period

Guna Bila

WORM compliance for Glacier archives — enforce retention policies that cannot be changed

Vault LockVault Access PolicyWORMcomplianceimmutableretentionGlacier archivein-progress state24-hour windowlock IDtwo-step lock

📎 Glacier Vault Lock

D1 · Secure

Amazon Redshift

Amazon Redshift — Encryption & DataShare

"Data warehouse — KMS untuk at rest, SSL untuk in transit, DataShare untuk cross-account"

🎯 Sebab Apa Wujud

Wujud sebab data warehouse simpan data sensitif berskala besar — perlu encryption at rest (disk) DAN in transit (network), dan selalunya kena share data dengan account/team lain tanpa nak buat ETL atau salin data (mahal + lambat + senang basi). Redshift selesai dua-dua: KMS encrypt data on-disk (AES-256), SSL/TLS encrypt traffic client↔cluster, dan DataShare bagi cross-account access ke data LIVE tanpa duplicate atau pipeline ETL.

Apa Dia

Redshift menyimpan data secara terenkripsi menggunakan KMS (AES-256) untuk data at rest. SSL/TLS encrypt data in transit antara client dan cluster. Redshift TIDAK guna EBS — ia manage storage sendiri. Redshift DataShare membenarkan cross-account data sharing tanpa ETL atau data duplication.

⚡ Quick Sifir — hafal ni

▪KMS = encrypt DATA AT REST (disk). SSL/TLS = encrypt DATA IN TRANSIT (network)
▪Redshift TIDAK guna EBS — manage storage sendiri
▪DataShare = cross-account sharing, NO ETL, NO data duplication (data live)
▪'Encrypt unencrypted Redshift at rest' → enable KMS
▪Pindah cluster ke private subnet = network security, BUKAN encryption

💡 Exam Scenario

"Encrypt unencrypted Redshift data at rest" → Enable KMS. At rest ≠ in transit. Moving cluster to private subnet = network security, bukan encryption.

🪤 Perangkap Soalan

Q: Redshift cluster sedia ada tak encrypted. Audit mahu data AT REST di-encrypt. Apa kau buat?

⚠ Umpan: Pindahkan cluster ke private subnet supaya tak terdedah. Nampak betul sebab 'lebih selamat'. SALAH: private subnet = network isolation, bukan encryption — data on-disk masih plaintext.

✓ Betul: Enable encryption guna KMS (AES-256) untuk data at rest. Keyword 'encrypt at rest / data on disk' = KMS, bukan network/subnet.

Q: Team analytics dalam account lain perlu query data dalam Redshift kau secara live, tanpa salin atau pipeline. Cara mana?

⚠ Umpan: Export data ke S3, copy ke account lain, COPY masuk Redshift mereka. Nampak betul sebab 'mereka dapat data'. SALAH: itu duplication + ETL, data jadi basi & mahal — bercanggah dengan 'tanpa salin/live'.

✓ Betul: Redshift DataShare — cross-account share data live tanpa ETL/duplication. Keyword 'share cross-account, no ETL, no copy' = DataShare.

🧠 Cara Mudah Ingat

→KMS = encrypt DATA AT REST (stored on disk)
→SSL/TLS = encrypt DATA IN TRANSIT (network)
→Redshift tidak guna EBS — cannot encrypt via EBS
→Private subnet = network isolation, BUKAN encryption
→Redshift DataShare: share live data cross-account TANPA export/ETL/duplication — QA account boleh query production data secara langsung
→DataShare vs S3 export: DataShare = live, no copy, secure. S3 export = snapshot, kena sync semula, extra cost
→Exam: "separate AWS account needs analytics access to Redshift, no ETL, no duplication" → Redshift DataShare

Guna Bila

Encrypt data warehouse at rest (KMS) and in transit (SSL); share data cross-account via DataShare

RedshiftKMSencryption at restSSL TLSin transitAES-256data warehouseDataSharecross-account analyticsno ETL

📎 Redshift Encryption

D1 · Secure

CloudTrail

AWS CloudTrail

"CCTV untuk semua API calls AWS"

🎯 Sebab Apa Wujud

Wujud sebab bila resource hilang atau ada perubahan mencurigakan, soalan pertama ialah 'SIAPA buat ni, bila, dari IP mana?' — tanpa log, mustahil nak siasat atau buktikan untuk audit/compliance. CloudTrail rakam SETIAP API call dalam account (user, masa, source IP, hasil) secara automatik, jadi kau ada jejak audit lengkap untuk forensics & compliance. Management event default ON dan free, jadi visibility asas dah ada tanpa setup.

Apa Dia

Merekod setiap API call dalam AWS account: siapa buat, bila, dari mana, apa hasilnya. Default simpan 90 hari. Boleh hantar ke S3 untuk long-term retention.

Contoh Guna

Security team nak tau siapa delete S3 bucket semalam — CloudTrail log ada: user, timestamp, source IP, action.

CloudTrail vs CloudWatch vs Config — pilih ikut soalan

Rendering diagram…

"Who deleted / audit log of API calls" → CloudTrail. "Alarm bila CPU > 80%, monitor logs" → CloudWatch. "Is this resource compliant, what changed over time, config drift" → AWS Config.

CloudTrail vs CloudWatch vs Config

Aspect	CloudTrail	CloudWatch	AWS Config
Question it answers	WHO did WHAT? (API calls)	WHAT is happening NOW? (metrics/logs)	Is config COMPLIANT & what CHANGED?
Records	Every API call (user, time, IP, action)	Metrics, logs, alarms, dashboards	Resource config snapshots over time
Main use	Audit, forensics, compliance trail	Monitoring, alerting, troubleshooting	Compliance rules, config history, drift
Triggers on	API activity	Threshold breach → alarm/action	Config change → rule evaluation
Keyword	"who deleted…", "audit log of API"	"alarm when CPU > 80%", "log metrics"	"is this resource compliant", "config drift"

Ingat: CloudTrail = WHO DID WHAT (API audit). CloudWatch = WHAT IS HAPPENING NOW (metrics/alarms). Config = IS IT COMPLIANT + WHAT CHANGED (resource state history). Soalan sebut "compliance + configuration over time" → Config, bukan CloudTrail.

⚡ Quick Sifir — hafal ni

▪CloudTrail = WHO did WHAT (API audit). CloudWatch = WHAT happening NOW (metrics)
▪Management events = default ON + FREE (CreateBucket, TerminateInstances...)
▪Data events = OFF by default, ada kos (S3 object-level Get/Put, Lambda invoke)
▪Standard retention 90 hari; CloudTrail Lake = sampai 7 tahun + query SQL terus
▪Console trail = ALL regions by default (multi-region)
▪Log file validation = SHA-256 hash + digest file → buktikan log TAK diusik (tamper-proof)
▪'Compliance + config over time / drift' → AWS Config, BUKAN CloudTrail

💡 Exam Scenario

"Who deleted this resource?", "compliance audit log of all API activity" → CloudTrail. Bukan CloudWatch (yang untuk metrics/logs dari apps). CloudTrail = WHO DID WHAT. CloudWatch = WHAT IS HAPPENING NOW.

🪤 Perangkap Soalan

Q: Pasukan security nak query 7 tahun aktiviti API secara SQL tanpa export ke S3/Athena. Guna apa?

⚠ Umpan: Standard CloudTrail trail hantar ke S3 + Athena untuk query. Nampak betul sebab 'CloudTrail simpan log'. SALAH: standard trail simpan 90 hari je dan perlu setup S3 + Athena untuk query.

✓ Betul: CloudTrail Lake — managed data lake, simpan sampai 7 tahun, query SQL terus dalam console. Keyword 'long-term + queryable tanpa export' = CloudTrail Lake.

Q: Audit mahu log setiap kali objek di-download (GetObject) dari bucket S3 sensitif. CloudTrail dah ON. Cukup ke?

⚠ Umpan: Cukup — CloudTrail default dah log semua, termasuk akses S3. Nampak betul sebab 'CloudTrail dah enabled'. SALAH: default cuma management events; S3 object-level GetObject ialah DATA event yang OFF by default.

✓ Betul: Enable CloudTrail DATA events untuk bucket tu (ada kos $0.10/100K events). Keyword 'object-level / GetObject / data-plane' = data events, bukan management events.

🧠 Cara Mudah Ingat

→CloudTrail Lake: managed data lake untuk CloudTrail events. SQL queries DIRECT dalam console — tanpa export ke S3 atau setup Athena
→CloudTrail Lake stores events up to 7 years. Standard CloudTrail = 90 days (kena export ke S3 untuk long-term)
→Exam: "query activity logs without exporting to external tools" atau "long-term retention + queryable interface" → CloudTrail Lake
→Management Events (Control Plane): merekod MANAGEMENT OPERATIONS pada resources — CreateBucket, TerminateInstances, AttachRolePolicy, CreateTrail etc. ENABLED BY DEFAULT untuk semua Trails.
→Data Events (Data Plane): merekod data-level operations — S3 object-level (GetObject, PutObject, DeleteObject) dan Lambda function invocations. TIDAK enabled by default — perlu explicitly enable, ada additional cost.
→Setting up CloudTrail itself (CreateTrail) = management event. CloudTrail writing log files to S3 = BUKAN data event — itu management event (PutObject dari CloudTrail service).
→Console-created Trail applies to ALL REGIONS by default (multi-region trail). CloudTrail Events dari semua regions dihantar ke satu S3 bucket.
→Insight Events: detect unusual API activity patterns (e.g. sudden spike in EC2 TerminateInstances calls). Optional, additional cost.
→Exam: "S3 object download activity logging" → CloudTrail data events (not management events). "Who created this IAM role?" → CloudTrail management events (default logging).
→Log file validation: CloudTrail kira SHA-256 hash setiap log file + hasilkan digest file (yang signed) setiap jam → kau boleh sahkan log TAK diubah/dipadam selepas delivery (tamper-proof audit). Ini CIRI CloudTrail, BUKAN S3. Keyword "ensure logs not tampered / integrity / prove log authenticity" → enable log file validation.
→PRICING: First copy of management events = FREE (all accounts). Data events (S3 object-level, Lambda invocations) = $0.10 per 100,000 events. CloudTrail Lake = $0.75/GB ingested + $0.005/GB scanned. Insight events = additional cost. Long-term: export ke S3 (bayar S3 storage sahaja, CloudTrail tak charge untuk export).
→Exam: "free audit trail of API calls" → CloudTrail management events (free). "log S3 object-level API calls" → data events ($0.10/100K events, not free).

Guna Bila

Audit who did what and when — compliance, forensics, account activity

API auditwho did whatcomplianceforensicsaccount activity90-day retentionCloudTrail LakeSQL querylong-term retention7 yearsmanagement eventsdata eventscontrol planedata planeS3 object-levelLambda invocationsmulti-region trailInsight Eventsvs CloudWatchvs Config

D1 · Secure

ACM

AWS Certificate Manager

"SSL cert percuma untuk HTTPS"

🎯 Sebab Apa Wujud

ACM wujud sebab urus SSL cert secara manual = sakit kepala: beli cert, install, lepas tu LUPA renew → cert expire → website tetiba "Not Secure", customer lari. Setiap renewal kena buat manual sebelum tarikh luput. ACM bagi cert PERCUMA dan auto-renew dia sendiri (selagi DNS validation) — kau set sekali, lupakan. Tujuan utama: hilangkan risiko "cert expired" outage + jimat duit beli cert.

Apa Dia

Menyediakan, mengurus dan auto-renew SSL/TLS certificates secara percuma. Attach terus ke ALB, CloudFront, atau API Gateway. Cert tidak boleh di-export dari ACM untuk install sendiri dalam EC2.

ACM — 3 jenis cert

ACM Public Certificate → cert percuma untuk public-facing HTTPS (browser-trusted). Auto-renew selagi DNS validation. Tak boleh export.

ACM Private CA (Private Certificate Authority) → private PKI untuk internal resources/IoT devices — TAK browser-trusted. Berbayar ($400/bln per CA). Boleh export private certs.

Imported Certificate → cert kau beli dari pihak ketiga (DigiCert dll), import masuk ACM untuk guna kat ALB/CloudFront. ACM TAK auto-renew imported cert — kau jaga renewal sendiri.

ACM Public vs Private CA vs Imported

Aspect	ACM Public	ACM Private CA	Imported Cert
Kos	🟢 FREE (+ auto-renew)	$400/bln per CA + $0.75/cert	Free guna — beli cert luar
Auto-renew	🟢 Ya (DNS validation)	🟢 Ya (internal)	❌ Manual — kau jaga sendiri
Trust	Public CA (browser percaya)	Private/internal sahaja	Ikut issuer
Export private key?	❌ Tak boleh	🟢 Boleh (private cert)	N/A (kau dah ada)
Guna untuk	Public HTTPS (ALB/CloudFront/API GW)	Internal services, private PKI, IoT	Existing cert nak attach kat ALB/CloudFront

Ingat: Public website HTTPS percuma → ACM Public. Internal/private PKI (no public trust) → ACM Private CA (bayar). Dah ada cert luar → import (tapi kau jaga renewal). CloudFront → cert MESTI di us-east-1.

⚡ Quick Sifir — hafal ni

▪CloudFront → cert MESTI di us-east-1 (N. Virginia), walau resource kau region lain
▪ALB / API Gateway → cert di region SAMA dengan resource tu
▪Auto-renew HANYA untuk DNS-validated public cert. Email-validated + imported = manual renew
▪ACM Public cert TAK BOLEH export → tak boleh install dalam EC2 sendiri
▪Public HTTPS percuma → ACM Public. Internal/private PKI → ACM Private CA ($400/bln)

💡 Exam Scenario

"Website perlu HTTPS percuma + auto-renew" → ACM Public cert, attach ke ALB/CloudFront/API GW. "CloudFront cert tak muncul dalam dropdown" → cert bukan di us-east-1. "Internal microservices perlu mutual TLS / private trust" → ACM Private CA. "Dah beli cert dari DigiCert nak guna kat ALB" → import ke ACM. Ingat: ACM Public certs tak boleh export untuk EC2 sendiri.

🪤 Perangkap Soalan

Q: Kau dah request ACM cert dan attach ke ALB elok-elok. Tapi bila nak guna cert sama untuk CloudFront distribution, cert tu tak muncul langsung dalam dropdown CloudFront. Kenapa?

⚠ Umpan: Cert tu belum fully validated / belum issued, jadi CloudFront tak nampak. Atau perlu request cert baru khas untuk CloudFront. Nampak munasabah sebab cert kena "issued" dulu.

✓ Betul: Cert berada di region yang salah. CloudFront HANYA baca ACM cert dari us-east-1 (N. Virginia), tak kira di mana resource lain berada. Request/import cert di us-east-1. Keyword: "CloudFront cert not showing in dropdown" → us-east-1.

Q: Aplikasi legacy berjalan terus atas EC2 (bukan belakang ALB) perlu HTTPS. Boleh guna ACM Public cert percuma untuk install dalam EC2?

⚠ Umpan: Boleh — ACM bagi cert percuma, jadi request je dan install dalam EC2. Nampak betul sebab ACM = "free SSL cert".

✓ Betul: TAK BOLEH. ACM Public cert tak boleh di-EXPORT, jadi mustahil install terus dalam EC2. Pilihan: (1) letak EC2 belakang ALB/CloudFront dan attach ACM di situ, ATAU (2) beli cert third-party / guna ACM Private CA (yang boleh export). Keyword: "install cert on EC2 directly" → ACM Public tak boleh.

Q: Cert ACM kat ALB akan expire 13 bulan lagi, asalnya di-validate guna EMAIL. Status sekarang "Pending validation". Manager nak pastikan cert tak expire mengejut. Punca + fix: (A) cert hampir expire, perlu respond email validation manual sebelum ACM boleh renew, (B) cert dah expired, tak boleh renew — request cert baru, (C) ACM akan auto-renew nanti, takde action perlu, (D) cert dah expired, contact AWS Support renew manual.

⚠ Umpan: C paling menipu — "ACM auto-renew" memang famous, jadi orang ingat takde action. TAPI auto-renew penuh HANYA untuk DNS-validated cert; email-validated WAJIB respond email setiap renewal. B & D pula umpan untuk yang baca "Pending validation" sebagai "dah expired" — padahal soalan kata expire 13 bulan LAGI (belum expire), dan "Pending validation" = tunggu kau confirm, BUKAN expired.

✓ Betul: A — cert email-validated, ACM dah hantar email renewal tapi belum ada orang confirm → tersangkut "Pending validation". Respond email tu untuk lengkapkan validation. Keyword: "email validation + Pending validation" → manual respond. Best practice: tukar ke DNS validation supaya auto-renew sepenuhnya. INGAT: DNS = auto-renew senang hati; Email = manual respond tiap renewal.

🧠 Cara Mudah Ingat

→PALING PENTING (exam trap): untuk CloudFront, cert MESTI di-request/import di region us-east-1 (N. Virginia) — CloudFront global tapi hanya baca ACM dari us-east-1. Cert betul tapi di region lain → CloudFront tak nampak. Untuk ALB/API Gateway: cert di region yang SAMA dengan resource.
→ACM auto-renews certs HANYA bila DNS validation digunakan. Email-validated certs = kena manual re-validate semasa renewal → status "Pending Validation"
→Exam trap: "ACM manages renewal automatically" adalah HANYA betul untuk DNS-validated public certs. Email validation + imported certs = manual action required
→ACM Public vs Private: Public = browser-trusted untuk public website. Private CA = internal/private trust sahaja (private PKI, IoT device certs), no public trust
→ACM certs cannot be exported/installed on EC2 directly — for EC2, buy third-party cert or use ACM with ALB/CloudFront/API Gateway
→Analogi: ACM = pejabat pos bagi & perbaharui "pasport HTTPS" percuma — auto-renew selagi guna DNS validation, tapi pasport ni hanya boleh guna kat kaunter AWS (ALB/CloudFront/API GW), tak boleh bawa balik (export) untuk EC2 sendiri.
→PRICING: ACM Public certs PERCUMA termasuk auto-renew. ACM Private CA = $400/bulan per CA + $0.75/cert (first 1,000, turun lepas tu). Imported certs free guna tapi kau urus renewal sendiri.

Guna Bila

Provision free SSL/TLS certificates for ALB, CloudFront, API Gateway

SSLTLSHTTPSfree certificateauto-renewalALBCloudFrontAPI GatewayDNS validationemail validationpending validationus-east-1N. VirginiaACM Private CAprivate PKIimported certificatecannot exportpricing

📎 ACM — issuing & managing certs 📎 CloudFront — require cert in us-east-1

D1 · Secure

CloudHSM

AWS CloudHSM

"KMS tapi kau fully control dedicated hardware"

🎯 Sebab Apa Wujud

CloudHSM wujud sebab ada compliance/regulasi (bank, kerajaan, FIPS 140-2 Level 3) yang TAK BENARKAN keys dikongsi atas infrastruktur shared, dan TAK BENARKAN cloud provider ada apa-apa kemungkinan akses keys kau. KMS pun selamat, tapi ia multi-tenant + AWS yang manage HSM. CloudHSM bagi kau hardware HSM SINGLE-TENANT — kau sorang je guna, kau pegang kunci, AWS langsung tak boleh masuk. Tujuan: penuhi keperluan "customer-exclusive / dedicated hardware / FIPS Level 3".

Apa Dia

Hardware Security Module yang dedicated untuk kau sahaja — bukan shared infrastructure macam KMS. Kau control dan manage keys sendiri. AWS tak boleh access keys kau.

RDS TDE — engine mana support + key store mana (exam discriminator)

RDS engine	Support TDE?	CloudHSM untuk TDE key?
Oracle	🟢 Ya	🟢 Ya — PKCS#11, single-tenant HSM
SQL Server	🟢 Ya	❌ Tak — cert RDS-managed/KMS
MySQL	❌ Tak (RDS encryption + KMS)	—
MariaDB	❌ Tak (RDS encryption + KMS)	—
PostgreSQL	❌ Tak (RDS encryption + KMS)	—

Ingat: Soalan 2-lapis: (1) "TDE" → buang MySQL/MariaDB/PostgreSQL (tinggal Oracle + SQL Server). (2) "single-tenant HSM" → CloudHSM, dan hanya Oracle integrate CloudHSM untuk TDE → Oracle RDS + CloudHSM. Kalau soalan cuma "encrypt at rest" biasa (tak sebut single-tenant/TDE) → RDS encryption + KMS, jangan terlebih pilih CloudHSM (mahal).

⚡ Quick Sifir — hafal ni

▪CloudHSM = single-tenant dedicated hardware. KMS = multi-tenant, AWS managed
▪FIPS 140-2 Level 3 → CloudHSM. Level 2 (default) → KMS
▪"AWS must have NO access to keys" / "customer-exclusive control" → CloudHSM
▪Kau urus sendiri (patching, HA, backup). KMS = AWS urus semua
▪RDS TDE = Oracle & SQL Server SAHAJA (MySQL/MariaDB/PostgreSQL guna RDS encryption + KMS, BUKAN TDE)
▪TDE master key dalam CloudHSM → HANYA Oracle RDS (PKCS#11). SQL Server RDS TDE guna cert RDS-managed, bukan CloudHSM

💡 Exam Scenario

"Compliance requires customer-exclusive control of encryption keys with dedicated hardware" → CloudHSM. Bukan KMS (KMS = shared, AWS-managed). CloudHSM = dedicated hardware, kau control. KMS = multi-tenant, AWS managed. FIPS 140-2 Level 3 = CloudHSM. Level 2 = KMS.

🪤 Perangkap Soalan

Q: Syarikat kewangan perlu encryption keys di mana AWS DIJAMIN tiada cara untuk akses key material, dengan pematuhan FIPS 140-2 Level 3 dan kawalan hardware eksklusif pelanggan. Servis mana?

⚠ Umpan: AWS KMS dengan customer managed key (CMK) + key policy ketat. Nampak betul sebab CMK = "customer managed" dan kau kawal key policy.

✓ Betul: AWS CloudHSM. Walaupun KMS CMK dipanggil "customer managed", ia masih multi-tenant dan AWS yang urus HSM (FIPS 140-2 Level 3 untuk single-tenant HSM = CloudHSM). Keyword "dedicated/single-tenant hardware", "AWS no access", "FIPS 140-2 Level 3" → CloudHSM, BUKAN KMS.

Q: Private bank deploy RDS untuk core banking. Data WAJIB encrypted at rest, kunci dalam single-tenant HSM, TANPA ubah aplikasi. Pilih: (A) Oracle RDS + TDE + CloudHSM, (B) MariaDB RDS + TDE + CloudHSM, (C) SQL Server RDS + TDE + KMS, (D) PostgreSQL RDS + TDE + KMS.

⚠ Umpan: C nampak betul — SQL Server memang support TDE. Atau B sebab "CloudHSM = single-tenant betul". SALAH dua-dua: C guna KMS (multi-tenant, bukan single-tenant); B guna MariaDB yang LANGSUNG tak support TDE dalam RDS.

✓ Betul: A — Oracle RDS + TDE + CloudHSM. Soalan 2-lapis: (1) "TDE" → RDS TDE HANYA Oracle & SQL Server, buang MariaDB+PostgreSQL. (2) "single-tenant HSM" → CloudHSM, bukan KMS, buang C & D. Tinggal A. Tambah: hanya Oracle RDS integrate CloudHSM untuk TDE master key (PKCS#11). INGAT: jangan pilih ikut "bank besar jadi Oracle" — pilih ikut keyword teknikal (TDE + single-tenant HSM).

🧠 Cara Mudah Ingat

→TDE (Transparent Data Encryption) = encrypt at rest pada peringkat DB engine, TRANSPARENT — aplikasi TAK perlu ubah kod. RDS yang support TDE: HANYA Oracle & SQL Server. MySQL/MariaDB/PostgreSQL → guna RDS encryption (KMS) sebagai ganti, bukan TDE. INGAT: "TDE" dalam soalan → terus buang pilihan MySQL/MariaDB/PostgreSQL.
→TDE + CloudHSM integration: HANYA Oracle RDS boleh simpan TDE master key dalam CloudHSM (via PKCS#11). SQL Server RDS TDE guna cert RDS-managed/KMS, BUKAN CloudHSM langsung. Jadi "single-tenant HSM + TDE + no app changes + RDS" → Oracle RDS + TDE + CloudHSM.
→Backup mechanism: EBK (Ephemeral Backup Key) encrypts the HSM data; PBK (Persistent Backup Key) encrypts the EBK — encrypted backup stored in S3 in the SAME region as the cluster
→Cross-region backup: must explicitly copy the S3 backup to another region — not automatic
→Analogi: CloudHSM = peti besi peribadi 🔐 — bank (AWS) bagi bilik khas dedicated, kau pegang kunci sendiri, bank pun tak boleh buka. Lawan KMS = locker awam yang bank uruskan (multi-tenant, AWS managed).
→PRICING: CloudHSM = ~$1.45/jam per HSM instance (sentiasa ON, billing per jam) — JAUH lebih mahal dari KMS ($1/key/bulan + $0.03/10K requests). Untuk HA perlu ≥2 HSM = ~$2.90/jam. Cost discriminator: kalau soalan tak sebut FIPS Level 3 / dedicated / "AWS no access", pilih KMS sebab CloudHSM mahal.

Guna Bila

FIPS 140-2 Level 3 compliance, customer-exclusive HSM hardware

dedicated HSMFIPS 140-2 Level 3customer controlsingle-tenanthardware securityTDEOracle RDSSQL Server RDSMySQLMariaDBPostgreSQLTransparent Data Encryptionencrypt at restno application changesPKCS#11EBKPBKbackuppricing

📎 What is AWS CloudHSM?📎 KMS custom key store (backed by CloudHSM)

🔗Connectivity↑ Top

D1 · Secure

Direct Connect

AWS Direct Connect

"Kabel terus ke AWS — private dedicated lane"

🎯 Sebab Apa Wujud

Wujud sebab traffic melalui public internet tak menentu — latency naik-turun, bandwidth tak terjamin, dan data transfer mahal bila volume besar. Untuk syarikat yang kerap pindah TB data atau jalankan app sensitif latency (trading, video), itu tak boleh pakai. DX bagi kabel fiber PRIBADI yang berdedikasi terus ke AWS (langkau internet/ISP) → latency konsisten, bandwidth terjamin, dan data transfer lebih murah pada skala. Tujuan: sambungan hybrid yang predictable & high-bandwidth.

Apa Dia

Menyediakan sambungan jaringan peribadi yang berdedikasi antara data center on-premises dengan AWS melalui fiber-optic cable di Direct Connect location (bypass internet/ISP). Private VIF → access VPC. Public VIF → access public AWS services (S3) guna private line. NOTA: DX TIDAK encrypted by default — kalau perlu encryption, run VPN over DX (IPSec).

Contoh Guna

Company transfer 100TB data sebulan dari on-prem ke AWS — Direct Connect lebih murah (no internet data transfer charges), consistent latency berbanding internet

Decision tree: DX vs VPN vs DX+VPN

Rendering diagram…

Analogi: VPN = jalan awam tapi naik kereta berperisai (encrypted, sambungan cepat). DX = highway tol PRIBADI sendiri (laju konsisten tapi kena bina dulu, lama). INGAT exam: "quickly/urgent" → VPN; "consistent low latency + high bandwidth" → DX; "private + encrypted/compliance" → DX + VPN (sebab DX tak encrypted by default).

Direct Connect vs Site-to-Site VPN

Aspect	Direct Connect (DX)	Site-to-Site VPN
Path	Private dedicated line (no internet)	Encrypted IPSec tunnel over public internet
Latency	🟢 Consistent, low	Variable (depends on internet)
Bandwidth	High, dedicated (1/10/100 Gbps)	Up to ~1.25 Gbps per tunnel
Setup time	Weeks–months (physical provisioning)	🟢 Minutes–hours
Cost	Higher fixed cost, cheaper data transfer at scale	🟢 Low, pay-as-you-go
Encryption	Not encrypted by default (add VPN over DX)	🟢 Encrypted by default (IPSec)
Use when	Steady high-volume, low-latency, predictable	Quick, cheap, encrypted, or DX backup

Ingat: "Consistent low latency + high bandwidth + private" → Direct Connect. "Quick, cheap, encrypted over internet" → Site-to-Site VPN. Best resilience = DX primary + VPN backup (encrypted DX = run VPN over DX).

⚡ Quick Sifir — hafal ni

▪DX = private dedicated fiber, BUKAN over internet. VPN = IPSec over internet
▪DX TAK encrypted by default — perlu encrypted+private → DX + VPN (IPSec over DX)
▪DX provisioning ambil minggu-bulan → soalan "quickly/immediately" = VPN, BUKAN DX
▪Resilient murah: DX primary + Site-to-Site VPN backup (bukan dual-DX)
▪Public VIF → akses S3/DynamoDB. Private VIF → akses VPC. Transit VIF → akses TGW
▪Satu DX → banyak VPC merentas region/account → Direct Connect Gateway

💡 Exam Scenario

"Steady high-volume transfer + consistent low latency + predictable bandwidth" → Direct Connect. "DX kena encrypted juga (compliance)" → DX + Site-to-Site VPN (run IPSec over DX). "Connect DX ke banyak VPC merentas region/account" → Direct Connect Gateway (global resource).

🪤 Perangkap Soalan

Q: Syarikat perlu sambungan ke AWS dengan latency konsisten & bandwidth tinggi, dan perlu LIVE secepat mungkin (dalam beberapa hari) untuk migrasi mendesak. Pilih?

⚠ Umpan: Direct Connect — sebab ia memang untuk latency konsisten + bandwidth tinggi. Nampak betul sebab soalan sebut dua syarat tu.

✓ Betul: Site-to-Site VPN dulu (boleh siap dalam minit/jam), kemudian migrasi ke DX bila kabel fizikal siap (minggu-bulan). DX provisioning fizikal terlalu lambat untuk "secepat mungkin". Keyword "quickly / immediately / urgent" mengatasi syarat latency → VPN. Boleh sebut DX sebagai fasa kedua.

Q: Pematuhan memerlukan SEMUA data antara on-prem dan AWS disulitkan dalam transit, dengan sambungan private berlatency rendah. Penyelesaian?

⚠ Umpan: Direct Connect sahaja — sebab ia private dedicated line, jadi dah selamat. Nampak betul sebab "private line = selamat".

✓ Betul: Direct Connect + Site-to-Site VPN (jalankan IPSec over DX). DX TIDAK encrypted by default — private ≠ encrypted. Untuk penuhi syarat encryption-in-transit + private low-latency, lapis VPN di atas DX. Keyword "encrypted + private/low-latency" → DX + VPN.

🧠 Cara Mudah Ingat

→DX = "Dedicated eXpensive" — physical fiber, weeks-months to provision. Tak suitable bila jawapan perlu "quickly/immediately" → itu VPN
→DX NOT encrypted by default — exam trap! Perlu private + encrypted = DX + Site-to-Site VPN (IPSec over DX)
→Resilience pattern: DX primary + Site-to-Site VPN backup (failover bila DX down). Cheaper than dual-DX
→Direct Connect Gateway = global resource, connect satu DX ke banyak VPC merentas Regions + accounts (associate dengan VGW atau Transit Gateway)
→Public VIF = access public AWS services (S3, DynamoDB) over private line. Private VIF = access VPC. Transit VIF = access TGW
→Bukan untuk "fast setup" — provisioning ambil masa. Untuk migration segera guna VPN dulu, DX kemudian

Guna Bila

Private dedicated connection from on-premises to AWS

dedicated connectionprivateconsistent latency1Gbps/10Gbpsno internetvs VPNIPSec backupdata transfer costDirect Connect Gatewaynot encryptedVPN over DXpublic VIFprivate VIF

📎 What is Direct Connect 📎 Direct Connect Gateways

D1 · Secure

Site-to-Site VPN

AWS Site-to-Site VPN

"Tunnel rahsia ke AWS, guna internet biasa — NETWORK ke NETWORK"

🎯 Sebab Apa Wujud

Wujud sebab kau nak sambung SELURUH rangkaian office/data center ke VPC dengan selamat, TANPA tunggu berbulan & bayar mahal untuk Direct Connect. Site-to-Site VPN guna internet sedia ada tapi bungkus traffic dalam terowong IPSec yang disulitkan — siap dalam minit/jam. Tujuan: hybrid network yang cepat, murah & encrypted (atau jadi backup untuk DX).

Apa Dia

Mewujudkan sambungan IPSec yang disulitkan antara seluruh on-premises NETWORK dengan AWS VPC menggunakan internet sedia ada. Dua komponen: Customer Gateway (CGW = device/info kat sebelah kau) + target gateway kat AWS — sama ada Virtual Private Gateway (VGW, attach ke 1 VPC) atau Transit Gateway (banyak VPC). Setiap VPN connection ada 2 tunnels untuk high availability. Routing: static atau dynamic (BGP).

Contoh Guna

Small office nak access resources dalam VPC secara selamat — setup Site-to-Site VPN. Lebih murah dan cepat setup dari Direct Connect tapi latency tak konsisten (ikut internet)

Which hybrid connectivity? (decision tree)

Rendering diagram…

Users vs network is the first fork. DX = consistent/predictable; VPN = quick/cheap/encrypted; combine for encrypted-private or resilient.

Site-to-Site VPN vs Client VPN — siapa yang connect?

Aspect	Site-to-Site VPN	Client VPN
Siapa connect	🟢 Entire NETWORK (office/data center)	🟢 Individual USERS (laptop/device)
Sebelah customer	Customer Gateway device (router)	OpenVPN software client per user
Auth	Pre-shared key / certificate (device)	AD / SAML / mutual certificate (per user)
AWS endpoint	Virtual Private Gateway atau TGW	Client VPN endpoint
Use case	Hybrid network, branch office, DX backup	Remote/WFH staff, vendor temporary access

Ingat: Soalan sebut "network/office/data center connect to VPC" → Site-to-Site. Sebut "users/employees/remote/laptop connect to VPC" → Client VPN.

⚡ Quick Sifir — hafal ni

▪Site-to-Site = NETWORK ke NETWORK (office/DC). Client VPN = USER (laptop) ke VPC
▪Encrypted by default (IPSec) → bagus bila soalan nak "encrypted + cepat/murah"
▪2 komponen: Customer Gateway (sebelah kau) + VGW/Transit Gateway (sebelah AWS)
▪Setiap VPN connection = 2 tunnels auto untuk HA
▪VGW = 1 VPC je. Banyak VPC / nak ECMP throughput → Transit Gateway
▪Classic resilient combo: DX primary + Site-to-Site VPN backup

💡 Exam Scenario

"Connect entire branch/office NETWORK ke VPC, encrypted, cepat & murah" → Site-to-Site VPN. "Backup untuk Direct Connect" → Site-to-Site VPN as failover. "Individual remote workers (laptop) nak access VPC" → itu Client VPN, BUKAN Site-to-Site.

🪤 Perangkap Soalan

Q: Sebuah cawangan office (seluruh rangkaian, ramai pekerja) perlu akses selamat ke VPC, perlu siap cepat dan kos rendah. Penyelesaian?

⚠ Umpan: AWS Client VPN — sebab pekerja office nak akses, jadi guna Client VPN per user. Nampak betul sebab "pekerja akses".

✓ Betul: Site-to-Site VPN. Yang perlu disambung ialah SELURUH RANGKAIAN office (via Customer Gateway), bukan setiap laptop satu-satu. Client VPN untuk individual remote user (WFH/vendor). Keyword "office/branch/network connect to VPC" → Site-to-Site, bukan Client VPN.

🧠 Cara Mudah Ingat

→Site-to-Site = NETWORK to NETWORK. Client VPN = USER to network. Ini pembeza utama dalam soalan
→2 komponen: Customer Gateway (sebelah kau) + Virtual Private Gateway / Transit Gateway (sebelah AWS)
→Setiap VPN connection = 2 tunnels auto untuk HA (redundancy)
→Encrypted by default (IPSec) — bagus bila jawapan perlu "encrypted" + "quick/cheap setup"
→VGW = attach ke 1 VPC sahaja. Nak banyak VPC → guna Transit Gateway sebagai target gateway
→Single tunnel ~1.25 Gbps. Nak lebih throughput → multiple VPN ke TGW dengan ECMP (VGW tak support ECMP)
→Classic combo: DX primary + Site-to-Site VPN backup = resilient hybrid tanpa dual-DX

Guna Bila

Encrypted IPSec tunnel from on-premises network to VPC over internet

IPSecencryptedinternet-basedVirtual Private GatewayCustomer GatewayTransit Gatewaytwo tunnelsquick setupcost-effectivenetwork to networkDX backupBGPvs Client VPN

📎 What is Site-to-Site VPN

D1 · Secure

Client VPN

AWS Client VPN

"VPN untuk individual users — bukan network-to-network"

🎯 Sebab Apa Wujud

Wujud sebab pekerja WFH / vendor sementara guna laptop sendiri dari rumah perlu akses selamat ke resource dalam VPC — tapi mereka BUKAN satu rangkaian office yang tetap (jadi Site-to-Site tak sesuai). Client VPN bagi setiap user pasang software client + authenticate (AD/SAML/cert) → dapat akses peribadi yang disulitkan, dan authorization rules hadkan setiap user ke subnet tertentu sahaja. Tujuan: remote access peringkat INDIVIDU dengan least-privilege.

Apa Dia

Managed VPN endpoint yang individual users install client (OpenVPN-compatible) and authenticate via AD, SAML, or mutual certificate auth. Each user's connection is governed by authorization rules that restrict access to specific subnets.

Client VPN vs Site-to-Site VPN vs Direct Connect — 3 cara sambung ke VPC

Aspect	Client VPN	Site-to-Site VPN	Direct Connect (DX)
Sambung apa	USER individu (laptop/device)	NETWORK (office/data center)	NETWORK via private line dedicated
Atas apa	Internet (encrypted, OpenVPN)	Internet (IPSec tunnel)	Private fiber (bukan internet)
Auth	Per-user (AD / SAML / mutual cert)	Tunnel device-to-device (CGW)	Physical cross-connect
Latency/BW	Ikut internet (berubah-ubah)	Ikut internet (berubah-ubah)	Konsisten, low-latency, high-BW
Guna bila	WFH/vendor, remote individual access	Hubung office ke AWS, cepat & murah	Konsisten/high-throughput/sensitive

Ingat: INDIVIDU (laptop, WFH, per-user auth) → Client VPN. NETWORK office ke AWS, murah, atas internet → Site-to-Site VPN. NETWORK perlu bandwidth konsisten + low latency + tak nak atas internet → Direct Connect (lihat card Direct Connect). Keyword "individual users / per-user / specific subnets" = Client VPN.

⚡ Quick Sifir — hafal ni

▪Client VPN = USER (laptop) ke VPC. Site-to-Site = NETWORK (office) ke VPC
▪User pasang OpenVPN-compatible client; auth via AD / SAML / mutual cert
▪Authorization rules = hadkan tiap user/group ke subnet tertentu (least privilege)
▪Caj per endpoint-hour + per client connection-hour → jimat untuk team kecil
▪"remote/WFH/vendor individual access" → Client VPN, bukan Site-to-Site

💡 Exam Scenario

"Small vendor team needs temporary authenticated access to specific VPC subnets, cost-efficient" → Client VPN. Site-to-Site VPN = entire on-premises NETWORK connects to AWS (not per-user). Client VPN = INDIVIDUAL USER level access.

🪤 Perangkap Soalan

Q: Pasukan vendor kecil (5 orang, kerja dari lokasi masing-masing) perlu akses sementara yang dibenarkan ke subnet tertentu dalam VPC, dengan kos efektif. Servis mana?

⚠ Umpan: Site-to-Site VPN dengan Customer Gateway di lokasi vendor. Nampak betul sebab "VPN ke VPC".

✓ Betul: AWS Client VPN. Mereka individu yang bertaburan (bukan satu rangkaian office dengan router tetap), perlu auth per-user dan had ke subnet tertentu (authorization rules). Site-to-Site perlukan Customer Gateway device per-site & sambung seluruh network. Keyword "individual users / per-user auth / specific subnets / temporary" → Client VPN.

🧠 Cara Mudah Ingat

→Authorization rules: restrict each user/group to specific subnets — principle of least privilege at the user level
→Scales per connection (charged per endpoint-hour + per client connection-hour) — cost-efficient for small teams
→Exam key: "user-level authentication" + "restrict to specific subnets" + "individual remote access" → Client VPN
→Not for site-to-site (entire network) connectivity — that is Site-to-Site VPN or Direct Connect
→PRICING: (approx, us-east-1) $0.10/jam per subnet association (endpoint) + $0.05/jam per connected client. Contoh: 1 subnet + 5 user connect 8 jam/hari ≈ $0.10×24×30 (endpoint) + $0.05×5×8×30 ≈ $132/bulan. Bayar bila ada client connect je → jimat untuk team kecil/sementara berbanding Site-to-Site (per VPN connection-hour ~$0.05/hr).

Guna Bila

Allow individual users to authenticate and connect to a VPC from their devices

Client VPNuser authenticationOpenVPNSAMLauthorization rulesper-user accessremote accesstemporary accessSite-to-Site VPNDirect Connectpricing

📎 What is AWS Client VPN

🏘️VPC & Networking↑ Top

D1 · Secure

VPC

Amazon Virtual Private Cloud

"Kawasan perumahan gated sendiri dalam AWS — kau yang design layout"

🎯 Sebab Apa Wujud

Wujud sebab kalau semua pelanggan AWS kongsi satu rangkaian rata, EC2 kau boleh ternampak/terhubung dengan server orang lain — bencana security. VPC bagi kau 'tanah' rangkaian peribadi terpencil dalam AWS di mana kau kawal segala-galanya: IP range (CIDR), subnet mana public/private, route table, dan gateway. Jadi DB & app server kau terlindung secara default, dan kau buka akses internet HANYA bila & di mana kau benarkan.

Apa Dia

VPC ialah private network terpencil dalam AWS cloud. Macam Tailscale yang buat private overlay network antara devices kau, tapi VPC lebih fundamental — ia adalah "tanah" dimana resources kau dilahirkan, bukan tunnel yang menghubungkan tempat yang dah ada. Kau tentukan IP range (CIDR), buat subnets, configure route tables dan gateways.

Contoh Guna

Semua EC2, RDS, Lambda dalam VPC kau sendiri — orang lain tak boleh access kecuali kau explicitly benarkan. Default VPC dah ada di setiap region.

VPC Components

VPC CIDR → IP range keseluruhan (172.16.0.0/16 = 65,536 IPs)

Public Subnet → Ada route ke IGW. EC2 boleh dapat public IP

Private Subnet → Tiada route terus ke internet. DB, app servers letak sini

Availability Zone → Setiap subnet duduk dalam SATU AZ sahaja

⚡ Quick Sifir — hafal ni

▪VPC = private network terpencil; span SATU region, subnet boleh banyak AZ
▪Subnet duduk dalam SATU AZ sahaja
▪Default VPC ada di setiap region (172.31.0.0/16)
▪Public subnet = ada route ke IGW; Private subnet = takde route terus ke internet
▪Max 5 VPC per region (soft limit, boleh request increase)

💡 Exam Scenario

"Deploy web servers dengan databases yang tak boleh diakses dari internet" → EC2 dalam Public Subnet, RDS dalam Private Subnet, dalam satu VPC.

🪤 Perangkap Soalan

Q: Web server kena boleh diakses dari internet, tapi database TAK boleh langsung. Macam mana susun dalam VPC?

⚠ Umpan: Letak web server & DB dalam dua VPC berasingan supaya DB terpencil. Nampak betul sebab 'asingkan DB'. SALAH: terlebih kompleks — dalam satu VPC pun boleh isolate guna subnet + route.

✓ Betul: Satu VPC: web server dalam public subnet (route ke IGW), DB dalam private subnet (takde route ke internet). Keyword 'tak boleh diakses dari internet' = private subnet.

Q: Kau nak satu subnet bentang merentas dua AZ untuk high availability. Boleh?

⚠ Umpan: Boleh, buat satu subnet besar yang span 2 AZ. Nampak betul sebab 'subnet besar = lebih HA'. SALAH: subnet TERIKAT pada satu AZ sahaja.

✓ Betul: Tak boleh — satu subnet = satu AZ. Untuk HA, buat subnet berasingan dalam setiap AZ. Keyword 'subnet span satu AZ je'.

🧠 Cara Mudah Ingat

→VPC ≈ Tailscale dari segi konsep private network, tapi VPC adalah "tanah" AWS resources kau. Tailscale lebih mirip Site-to-Site VPN (connect existing places)
→VPC span SATU region, tapi subnets boleh tersebar di banyak AZs dalam region tu
→Default VPC ada di setiap region — EC2 launch tanpa setup guna default VPC
→Satu region boleh ada max 5 VPCs (soft limit, boleh request increase)

Guna Bila

Isolated private network — the foundation for all AWS resources

VPCCIDRsubnetpublicprivateisolated networkdefault VPCprivate network

📎 VPC User Guide

D1 · Secure

CIDR & Subnets

IP Addressing & Subnet Calculator

"2^(32−prefix) = total IPs, tolak 5 = usable"

🎯 Sebab Apa Wujud

Wujud sebab sebelum boleh letak apa-apa dalam VPC, kau kena tetapkan berapa besar rangkaian (berapa IP) dan bahagikannya jadi subnet — silap kira, subnet jadi terlalu kecil (kehabisan IP) atau bertindih. CIDR ialah cara ringkas tulis saiz rangkaian (/16, /24) dan exam suka uji 'berapa usable IP'. AWS reserve 5 IP setiap subnet, jadi kira tepat penting supaya kau plan IP betul tanpa terkejut kehabisan alamat.

Apa Dia

CIDR (Classless Inter-Domain Routing) tentukan berapa banyak IP dalam sesebuah network. Format: <network address>/<prefix length>, contoh 172.31.0.0/16. Nombor IP (e.g. 172.31.0.0) — kau yang pilih masa create VPC, dari RFC 1918 private ranges: • 10.0.0.0/8 — besar, enterprise • 172.16.0.0/12 → 172.16–31.x.x — AWS default VPC guna 172.31.0.0/16 • 192.168.0.0/16 — rumah/pejabat kecil Ranges ni tak boleh route kat internet — private sahaja, sebab tu EC2 private subnet pakai IP macam ni. Nombor selepas slash (/16, /24) = prefix length = berapa bits "dikunci" sebagai network. IPv4 ada 32 bits total. Baki bits = hosts. • /16 → 16 bits kunci, 16 bits bebas → 2^16 = 65,536 IPs • /24 → 24 bits kunci, 8 bits bebas → 2^8 = 256 IPs • /25 → 25 bits kunci, 7 bits bebas → 2^7 = 128 IPs AWS reserve 5 IPs setiap subnet: .0 network, .1 VPC router, .2 DNS, .3 future, .255 broadcast.

Contoh Guna

192.168.0.0/26 → 32−26=6 bits, 2^6=64 IPs, tolak 5 = 59 usable. VPC /16 boleh dibahagi kepada banyak subnets /24 atau /26.

CIDR Quick Reference

/16 → 65,536 total → 65,531 usable (guna untuk VPC range)

/24 → 256 total → 251 usable (subnet standard)

/25 → 128 total → 123 usable

/26 → 64 total → 59 usable

/27 → 32 total → 27 usable (exam favourite)

/28 → 16 total → 11 usable (AWS minimum)

⚡ Quick Sifir — hafal ni

▪Formula: 32 − prefix = bits bebas; 2^bits = total IP; tolak 5 = usable
▪AWS reserve 5 IP/subnet: .0 network, .1 router, .2 DNS, .3 future, .255 broadcast
▪/24 = 251 usable, /26 = 59 usable, /27 = 27 usable (hafal 3 ni)
▪AWS minimum subnet = /28 (11 usable je)
▪Private ranges (RFC 1918): 10.0.0.0/8, 172.16-31.x, 192.168.0.0/16
▪Nombor lepas slash = bits dikunci, BUKAN bilangan IP

💡 Exam Scenario

"Exam soal berapa usable IPs dalam /27?" → 32 total, tolak 5 = 27 usable. AWS ALWAYS reserves 5 IPs per subnet.

🪤 Perangkap Soalan

Q: Berapa usable IP address dalam subnet /27?

⚠ Umpan: 32 — sebab 2^(32−27) = 2^5 = 32 total IP. Nampak betul sebab dah kira 2^bits. SALAH: lupa AWS reserve 5 IP setiap subnet.

✓ Betul: 27 usable — 32 total tolak 5 reserved. Keyword 'usable = total − 5 (AWS reserved)'.

Q: Kau nak subnet sekecil mungkin untuk segelintir host. Saiz prefix paling kecil yang AWS benarkan?

⚠ Umpan: /30 (4 IP) atau /32 (1 IP) sebab itu paling kecil dalam networking biasa. Nampak betul sebab 'paling kecil'. SALAH: AWS ada minimum tersendiri.

✓ Betul: /28 — minimum subnet AWS (16 total, 11 usable). Keyword 'AWS minimum subnet = /28'.

🧠 Cara Mudah Ingat

→Formula: 32 − prefix = bits bebas. 2^bits = total IPs. Tolak 5 = usable
→IP address tu kau pilih sendiri dari private ranges: 10.x, 172.16–31.x, 192.168.x — bukan public IP
→AWS default VPC guna 172.31.0.0/16 — sebab tu nampak 172.31 dalam route tables
→Nombor selepas slash bukan bilangan IP — ia bilangan bits yang dikunci. /16 = 65k IPs, /24 = 256 IPs
→Hafal 3 ni cukup: /24 = 251, /26 = 59, /27 = 27 usable
→5 reserved: .0 (network) .1 (router) .2 (DNS) .3 (future) .255 (broadcast)
→AWS minimum subnet = /28 (hanya 11 usable IPs)

Guna Bila

Plan IP address ranges — VPC perlu CIDR sebelum boleh buat subnets

CIDRsubnet maskIP addressing/24/26/275 reserved IPsusable hosts

📎 VPC CIDR Blocks 📎 Subnet Sizing

D1 · Secure

Private/Public/Elastic IP

EC2 IP Addresses — Private vs Public vs Elastic

"Private = borak dalam rumah (kekal). Public = alamat sewa (tukar bila Stop/Start). Elastic = alamat beli tetap (statik, boleh alih)"

🎯 Sebab Apa Wujud

Tiga ni wujud sebab keperluan alamat berbeza. Private IP wujud sebab setiap EC2 perlu alamat untuk bercakap dalam VPC tanpa terdedah ke internet (DB, app server). Public IP wujud supaya instance boleh dicapai dari internet — tapi ia ephemeral (AWS recycle balik ke pool), sebab tu ia BERUBAH bila Stop/Start → tak boleh harap untuk DNS/whitelist. Elastic IP wujud untuk selesaikan masalah tu: kau perlukan alamat internet yang KEKAL (point DNS, firewall whitelist pihak ketiga) DAN boleh dialih masa server rosak — cabut EIP dari EC2 mati, cucuk ke EC2 backup, user di internet tak perasan apa-apa.

Apa Dia

Tiga jenis alamat IP pada EC2. Private IP = alamat dalaman auto-assign dari CIDR subnet, untuk komunikasi DALAM VPC (EC2↔EC2, EC2↔RDS) — bukan internet. Public IP = alamat internet sementara dari pool AWS, BERUBAH setiap kali Stop/Start. Elastic IP (EIP) = Public IPv4 statik yang kau "tempah & pegang" untuk akaun kau — tak berubah langsung, boleh cabut & alih ke instance lain (mask failure).

Private vs Public vs Elastic IP — anatomy

Private IP → Auto-assign dari CIDR subnet masa launch (wajib ada minimum satu). Internal VPC sahaja. Kekal melekat selagi EC2 wujud; hanya lepas bila Terminate. Stop/Start TAK ubah private IP.

Public IP → Optional, auto-assign dari pool awam AWS bila EC2 dalam public subnet (setting "auto-assign public IP"). BERUBAH setiap Stop/Start (lepas balik ke pool, dapat baru bila start). Tak boleh dialih manual. IPv4.

Elastic IP → Allocate ke akaun kau, kekal milik kau sampai release. Associate ke instance/ENI. Static — tak berubah walau Stop/Start. Boleh disassociate & re-associate ke EC2 lain (failover). Property of ENI. Limit 5/region. IPv4 sahaja.

Decision: IP mana aku perlu?

Rendering diagram…

INGAT exam: Public IP BERUBAH bila Stop/Start. Soalan minta "consistent / static public IP" (DNS, firewall whitelist, least operational overhead) → Elastic IP, JANGAN Public IP biasa.

Analogi: alamat rumah (sewa vs beli)

Rendering diagram…

Private = borak dalam rumah (internal). Public = alamat sewa yang berubah. Elastic = alamat beli yang tetap & boleh bawa pindah. INGAT: nak IP internet yang TAK BERUBAH → Elastic IP.

Private IP vs Public IP vs Elastic IP

Ciri	Private IP	Public IP	Elastic IP
Akses	Internal VPC sahaja	Internet awam	Internet awam
Statik / kekal?	Ya (sepanjang hayat EC2)	❌ Berubah bila Stop/Start	🟢 Ya (100% statik)
Boleh alih ke EC2 lain?	❌	❌	🟢 Boleh (disassociate → associate)
IPv6?	Ya (boleh IPv6 dalam VPC)	IPv4 (+ IPv6 auto)	❌ IPv4 sahaja
Sesuai untuk DNS A-record?	Tidak (private)	❌ Pecah bila IP berubah	🟢 Ya — alamat tetap
Kos	Free	$0.005/jam (sejak Feb 2024)	$0.005/jam (attached/idle sama)

Ingat: Internal je → Private IP. Internet sementara/test → Public IP (tapi ingat ia BERUBAH bila Stop/Start). Internet KEKAL (DNS, firewall whitelist, failover, least ops overhead) → Elastic IP. Discriminator exam: "consistent/static public IP across Stop/Start" → Elastic IP, BUKAN Public IP.

⚡ Quick Sifir — hafal ni

▪Private IP = internal VPC, kekal sepanjang hayat EC2 (hilang bila Terminate je, BUKAN Stop/Start)
▪Public IP = ephemeral, BERUBAH setiap Stop/Start (perangkap exam #1)
▪Elastic IP = static public IPv4, milik akaun kau, tak berubah, boleh alih ke EC2 lain
▪Nak IP internet konsisten (DNS A-record / firewall whitelist / least ops overhead) → Elastic IP, BUKAN Public IP
▪EIP limit 5 per region (default; boleh minta naik)
▪EIP = IPv4 sahaja (no Elastic IP untuk IPv6)
▪Failover: cabut EIP dari EC2 rosak → attach ke EC2 backup (user tak perasan server bertukar)

💡 Exam Scenario

"Consistent/static public IP walau Stop/Start (DNS, firewall whitelist)" → Elastic IP. "EC2 ke RDS dalam VPC sama" → Private IP. "Public IP hilang/tukar lepas reboot" → memang sifat Public IP, guna Elastic IP kalau nak kekal. "Idle Elastic IP membazir kos" → release EIP yang tak attach.

🪤 Perangkap Soalan

Q: Aplikasi di EC2 kerap di-Stop/Start setiap hujung minggu, dan perlu alamat IP awam yang KONSISTEN untuk di-whitelist oleh firewall pihak ketiga. Pilihan dengan least operational overhead?

⚠ Umpan: Public IP biasa + update firewall setiap kali server start — nampak 'cukup' sebab Public IP pun boleh akses internet. SALAH: Public IP BERUBAH bila Stop/Start, jadi firewall whitelist pecah setiap minggu.

✓ Betul: Elastic IP — keyword 'consistent/static public IP + Stop/Start + least operational overhead' = EIP. Sekali attach, IP tak berubah walau berapa kali Stop/Start.

Q: Kau allocate beberapa Elastic IP tapi sebahagiannya tak attach ke mana-mana instance. Apa kesan?

⚠ Umpan: Free je sebab EIP percuma bila kau ada akaun — nampak betul ikut 'rule lama' (free bila attached). SALAH: idle EIP memang dicaj, dan sejak Feb 2024 SEMUA public IPv4 dicaj.

✓ Betul: Kena caj $0.005/jam tiap public IPv4 (idle EIP pun kena; dulu idle je kena, sekarang semua). Fix: release EIP yang tak guna. Keyword 'idle/unattached Elastic IP' = cost waste.

🧠 Cara Mudah Ingat

→Private IP TAK berubah bila Stop/Start — hanya hilang bila Terminate. Public IP pula BERUBAH setiap Stop/Start.
→Public IP biasa TAK boleh point DNS A-record dengan selamat (link pecah bila server reboot/stop). Untuk DNS guna Elastic IP, atau lagi baik guna ALB + Route 53 Alias.
→Elastic IP boleh dialih: disassociate dari EC2 rosak → associate ke EC2 sihat dalam beberapa saat = mask failure tanpa user perasan.
→Associate EIP ke primary ENI → public IP sedia ada dilepas ke pool. Disassociate → dapat public IP baru automatik.
→Elastic IP = IPv4 sahaja. Tiada konsep Elastic IP untuk IPv6 (IPv6 dalam AWS global-routable terus).
→Limit default 5 EIP per region — kalau perlu banyak public IP statik, fikir guna NAT/ALB/NLB dulu sebelum minta naik limit.
→PRICING: Sejak 1 Feb 2024, SEMUA public IPv4 dicaj $0.005/jam (~$3.60/bulan) — termasuk auto-assign Public IP DAN Elastic IP, sama ada attached atau idle. (Rule LAMA, masih kadang diuji exam: EIP free bila attached, denda bila idle.) Free tier: 750 jam public IPv4/bulan untuk 12 bulan pertama akaun baru. Private IP percuma.

Guna Bila

Tentukan macam mana EC2 dialamatkan — internal (Private), internet sementara (Public), atau internet statik yang tak berubah (Elastic)

Private IPPublic IPElastic IPEIPstatic IPconsistent public IPStop Start IP changefailover IPwhitelistDNS A recordinternal communicationIPv4idle Elastic IPleast operational overheadpublic IPv4 chargepricing

📎 Elastic IP address concepts and rules 📎 Public IPv4 addresses (EC2)

D1 · Secure

Internet Gateway

VPC Internet Gateway (IGW)

"Pintu pagar utama — dua arah, free, satu per VPC"

🎯 Sebab Apa Wujud

Wujud sebab VPC by default TERTUTUP — takde apa boleh masuk/keluar internet. IGW = pintu pagar rasmi yang AWS urus (HA, auto-scale, free) supaya kau tak payah bina router sendiri. Sebab dia bidirectional (internet boleh initiate masuk), dia hanya patut dipakai untuk resource yang memang nak expose (web/bastion) — itu sebab ada NAT Gateway berasingan untuk yang nak keluar SAHAJA.

Apa Dia

IGW enable komunikasi dua arah antara VPC dan internet. Highly available, horizontally scaled, free. Satu VPC = satu IGW sahaja. Sebuah subnet baru jadi "public" bila ada 3 syarat: (1) IGW attached ke VPC, (2) route table ada 0.0.0.0/0 → IGW, (3) EC2 ada public/Elastic IP.

Contoh Guna

Web server EC2 dalam public subnet — route table ada 0.0.0.0/0 → igw-xxx. EC2 dapat public IP, users dari internet boleh reach web server.

Analogi: Pintu pagar rumah

Rendering diagram…

IGW = pintu utama dua arah (expose). NAT = pintu belakang sehala IPv4. Egress-Only IGW = pintu sehala IPv6. INGAT exam: private subnet IPv6 nak keluar internet → Egress-Only IGW, sebab NAT Gateway tak handle IPv6.

IGW vs NAT Gateway vs Egress-Only IGW

Aspect	Internet Gateway	NAT Gateway	Egress-Only IGW
Arah	🟢 Dua arah (in + out)	Outbound only	Outbound only
IP version	IPv4 + IPv6	IPv4 sahaja	🟢 IPv6 sahaja
Letak kat	Attach ke VPC	Dalam public subnet	Attach ke VPC
Subnet sasaran	Public subnet	Private subnet (IPv4)	Private subnet (IPv6)
Cost	🟢 Free	$0.045/hr + $0.045/GB	🟢 Free
Internet boleh initiate masuk?	Ya (terdedah)	Tidak	Tidak

Ingat: Nak expose ke internet (web/bastion) → IGW (dua arah). Private IPv4 keluar je (patch/update) → NAT Gateway. Private IPv6 keluar je → Egress-Only IGW (sebab NAT GW IPv4 sahaja). Discriminator exam: "IPv6 + outbound only" → Egress-Only IGW, BUKAN NAT Gateway.

⚡ Quick Sifir — hafal ni

▪IGW = bidirectional (in + out). NAT GW = outbound ONLY
▪Satu VPC = satu IGW. Free, HA, auto-scale
▪Subnet "public" = 3 syarat: IGW attach + route 0.0.0.0/0→IGW + EC2 ada public IP
▪Takde public IP pada EC2 = walaupun route betul, tetap tak boleh keluar via IGW

💡 Exam Scenario

"Public subnet boleh access internet" → Internet Gateway. Route table mesti ada 0.0.0.0/0 → IGW untuk subnet jadi public.

🪤 Perangkap Soalan

Q: EC2 dalam subnet, route table ada 0.0.0.0/0 → IGW, IGW attached ke VPC. Tapi EC2 tetap tak boleh reach internet. Kenapa?

⚠ Umpan: Mesti NACL atau SG block — tukar firewall rules. Mungkin betul, tapi exam selalunya nak benda lebih asas.

✓ Betul: EC2 takde public/Elastic IP. 3 syarat public subnet: IGW + route + PUBLIC IP. Tanpa public IP, IGW takde alamat untuk reply ke instance tu.

Q: Nak private subnet EC2 download patches dari internet tapi JANGAN biar internet initiate connection masuk. Route ke IGW?

⚠ Umpan: Route 0.0.0.0/0 → IGW. SALAH: IGW bidirectional, jadi internet boleh initiate masuk = subnet jadi public, instance terdedah.

✓ Betul: Route 0.0.0.0/0 → NAT Gateway (outbound only). IGW untuk yang nak expose; NAT untuk yang nak keluar je.

🧠 Cara Mudah Ingat

→IGW = free, highly available, satu per VPC — tak boleh ada 2 IGW dalam satu VPC
→3 syarat subnet "public": (1) IGW attach ke VPC, (2) route 0.0.0.0/0 → IGW, (3) EC2 ada public/Elastic IP
→IGW = bidirectional (internet boleh masuk). NAT GW = outbound only. Ingat perbezaan ni!

Guna Bila

Connect VPC to internet (bidirectional) — kena ada untuk public subnet

IGWinternet gatewaypublic subnetbidirectionalfree0.0.0.0/0

📎 Internet Gateways

D1 · Secure

NAT Gateway

Network Address Translation Gateway

"Keluar boleh, masuk tak boleh — untuk private subnet"

🎯 Sebab Apa Wujud

Wujud sebab private subnet ada dilema: server (RDS, app) perlu keluar internet untuk patch/update/call API, TAPI kau tak nak internet boleh masuk balik (kalau guna IGW + public IP, instance jadi terdedah). NAT GW selesai ni — dia satu hala je (outbound), pakai Elastic IP dia sendiri jadi instance kau tak pernah dedah IP. AWS urus HA + auto-scale supaya kau tak payah maintain NAT Instance (EC2) sendiri.

Apa Dia

NAT GW allow instances dalam private subnet buat OUTBOUND connection ke internet (download packages, call external APIs) tanpa exposed kepada inbound connections. NAT GW duduk dalam PUBLIC subnet (bukan private!), ada Elastic IP. Private subnet route: 0.0.0.0/0 → NAT GW.

Contoh Guna

RDS dalam private subnet perlu download security patches. Traffic: RDS → NAT GW (public subnet) → IGW → internet. Internet tak boleh initiate connection masuk ke RDS.

Analogi Grab — NAT Gateway vs NAT Instance

Rendering diagram…

Analogi Grab: NAT Gateway = naik Grab — bayar sikit lebih tapi orang lain (AWS) yang bawa & jaga kereta, kau duduk diam (managed, auto-scale, HA). NAT Instance = bawa kereta sendiri — boleh jimat / kawalan penuh, tapi kau kena beli, isi minyak, dan baiki sendiri bila rosak (EC2 yang kau urus). Default exam = NAT Gateway.

Kongsi vs Asing — 1 NAT GW untuk semua AZ, atau 1 per AZ?

Rendering diagram…

KONGSI 1 NAT GW = jimat sewa jam, TAPI EC2 di AZ lain kena bayar cross-AZ data charge ($0.01/GB) + kalau AZ NAT GW tu tumbang, SEMUA AZ lain putus internet (single point of failure). ASING 1 NAT GW per AZ = takde cross-AZ charge + HA (satu AZ jatuh, lain tak terjejas). INGAT exam: "cross-AZ cost" + "highly available" → 1 NAT Gateway PER AZ (public subnet AZ tu sendiri).

Finance nak kos NAT GW SEMUA account dalam Organization — guna apa?

Rendering diagram…

Bila dah masuk AWS Organizations (banyak account), Finance tak payah login satu-satu — semua kos berkumpul di MANAGEMENT (payer) account. INGAT exam: "combined/consolidated cost across all accounts" → Cost Explorer di Management Account, Group by Linked Account. Nak amaran auto = AWS Budgets. Nak analisis BI mendalam (SQL/QuickSight) = Cost and Usage Report (CUR)/Data Exports → S3 → Athena/QuickSight.

NAT Gateway vs NAT Instance

Aspect	NAT Gateway	NAT Instance
Urus oleh	🟢 AWS (fully managed)	Kau sendiri (EC2 biasa)
Availability	🟢 HA dalam 1 AZ auto (deploy 1 per AZ utk multi-AZ)	Manual — kena script failover sendiri
Bandwidth	🟢 Auto scale 5→100 Gbps	Ikut saiz EC2 instance
Security Group	❌ Tak boleh attach SG	🟢 Boleh (ia EC2)
Bastion / port forward	❌ Tak boleh	🟢 Boleh (guna sebagai bastion juga)
Patch / maintenance	🟢 AWS handle	Kau patch OS sendiri
Kos	Per jam + per GB	Kos EC2 (boleh lagi murah utk traffic kecik)

Ingat: Default jawapan exam = NAT Gateway (managed, HA, auto-scale). Pilih NAT Instance HANYA bila perlu SG/bastion/port-forwarding atau nak jimat untuk traffic sangat kecil. Source/destination check MESTI disable untuk NAT Instance.

⚡ Quick Sifir — hafal ni

▪NAT GW DUDUK DALAM PUBLIC subnet (bukan private!) — trap paling kerap
▪NAT GW = OUTBOUND only. Internet TAK boleh initiate masuk
▪NAT GW = STATEFUL (ingat jalan balik, SNAT) + serverless/managed — auto-scale 5→100 Gbps, tak boleh SSH masuk
▪NAT GW perlukan IGW untuk sampai internet — dia bukan ganti IGW
▪Default exam = NAT Gateway (managed). NAT Instance hanya bila perlu SG/bastion/port-forward
▪Multi-AZ HA = deploy 1 NAT GW per AZ; elak cross-AZ data charge
▪Banyak traffic ke S3/DynamoDB? Gateway VPC Endpoint (FREE) lagi murah dari NAT GW per-GB
▪IPv6 + outbound-only → Egress-Only IGW (EIGW), BUKAN NAT GW (NAT GW=IPv4; NAT64 cuma IPv6→IPv4)
▪Had connection = 55,000 per unique destination per IP → ErrorPortAllocation. Tambah IP (max 8) / split subnet, BUKAN upgrade bandwidth
▪NAT GW TAKDE Stop/Start (lain dari EC2) — nak matikan kena DELETE, nak hidup CREATE semula. Automate jadual: Lambda + EventBridge
▪Check kos: Cost Explorer → Service = EC2-Other → Group by Usage Type → NatGateway-Hours (sewa) + NatGateway-Bytes (data)
▪Kos NAT GW SEMUA account org → Cost Explorer di MANAGEMENT account, Group by Linked Account (tak payah login satu-satu)

💡 Exam Scenario

"Private subnet EC2 perlu access internet tapi tak nak exposed" → NAT Gateway. Letak NAT GW dalam public subnet, route private subnet 0.0.0.0/0 → NAT GW.

🪤 Perangkap Soalan

Q: Letak NAT Gateway dalam mana untuk private subnet EC2 boleh keluar internet?

⚠ Umpan: Dalam PRIVATE subnet — sebab dia "untuk" private subnet, logik kan? Itu umpan paling popular.

✓ Betul: Dalam PUBLIC subnet. NAT GW sendiri kena boleh sampai IGW (route 0.0.0.0/0→IGW). Private subnet route 0.0.0.0/0 → nat-xxx.

Q: App private subnet upload beratus GB/hari ke S3 lalu NAT Gateway. Bil membengkak. Macam mana jimat?

⚠ Umpan: Tukar ke NAT Instance kecil supaya murah. Boleh jimat sikit, tapi masih bayar per-GB + kau maintain EC2.

✓ Betul: S3 Gateway VPC Endpoint (FREE, no per-GB) — traffic terus dalam AWS network, langsung tak sentuh NAT GW. Keyword: "private subnet → S3 → reduce cost" = Gateway Endpoint.

Q: Satu Public NAT GW dalam AZ-A je, tapi EC2 tersebar multi-AZ. Cross-AZ traffic naikkan kos. Paling cost-effective + kekal internet access?

⚠ Umpan: Create PRIVATE NAT Gateway (option C/D) — sebab "private" bunyi macam murah/jimat. Salah: Private NAT GW langsung TAK boleh keluar internet (no IGW route), dia untuk VPC-to-VPC / on-prem private routing je.

✓ Betul: Deploy SATU Public NAT Gateway PER AZ dalam PUBLIC subnet AZ tu sendiri. Traffic stay dalam AZ → eliminate cross-AZ data charge + kekal internet. Keyword: "cross-AZ cost" + "maintain internet access" → NAT GW per AZ (public), BUKAN private NAT GW.

Q: EC2 IPv6 dalam private subnet perlu OUTBOUND internet sahaja (tak nak inbound). Guna apa?

⚠ Umpan: NAT Gateway — sebab "private subnet nak keluar internet" = reflex NAT GW. Tapi NAT GW untuk IPv4 (NAT64 dia cuma untuk IPv6→IPv4). Untuk IPv6 ke internet IPv6, NAT GW bukan jawapan.

✓ Betul: Egress-Only Internet Gateway (EIGW). IPv6 address global-routable (takde private IPv6), jadi tak perlu NAT — EIGW bagi outbound-only sambil block inbound. Keyword: "IPv6" + "outbound only" → Egress-Only IGW, BUKAN NAT GW.

Q: App belakang NAT GW buat ribuan connection ke SATU endpoint (API/DB). Mula nampak ErrorPortAllocation, connection fail. Fix?

⚠ Umpan: NAT GW dah max bandwidth, scale ke yang lebih besar — tapi NAT GW auto-scale bandwidth sendiri (5→100 Gbps), ni bukan isu bandwidth.

✓ Betul: Had 55,000 simultaneous connection PER unique destination per IP. Fix: associate lebih IP pada NAT GW (sampai 8), atau sebar resource ke banyak subnet + NAT GW. Keyword: "ErrorPortAllocation" / "many connections to same destination".

Q: Syarikat ada banyak AWS account bawah satu Organization. Finance nak SATU laporan kos NAT Gateway tiap account tanpa login satu-satu. Cara paling mudah?

⚠ Umpan: Login setiap member account, buka Cost Explorer satu-satu, lepas tu jumlah manual dalam Excel. Penat + senang silap — ini yang exam nak kau ELAK.

✓ Betul: Buka Cost Explorer di MANAGEMENT (payer) account → Group by Linked Account → Filter Service = EC2-Other + Usage Type "NatGateway". Satu skrin nampak kos tiap account. Keyword: "combined/consolidated cost across all accounts / per linked account" → Cost Explorer di Management Account. Nak emel amaran auto → AWS Budgets. Nak data mentah utk BI → CUR/Data Exports → S3 → Athena/QuickSight.

🧠 Cara Mudah Ingat

→NAT GW DUDUK DALAM PUBLIC SUBNET — bukan private! Ini exam trap paling common
→Private subnet route: 0.0.0.0/0 → nat-xxx. Public subnet route: 0.0.0.0/0 → igw-xxx
→IGW MESTI attached ke VPC — tanpa IGW, NAT GW tak boleh hantar traffic ke internet walaupun route betul
→NAT GW ada Elastic IP. Kena bayar per hour + per GB processed
→NAT Instance (lama, EC2 manual) vs NAT Gateway (managed, auto-scale, recommended)
→Nak SSH ke private instance? Tak boleh direct dari internet — guna bastion host (EC2 dalam public subnet)
→Cross-AZ cost reduction: instances dalam AZ-B routing melalui NAT GW di AZ-A kena bayar cross-AZ transfer charges
→Fix: deploy NAT Gateway SATU PER AZ dalam public subnet yang sama AZ dengan EC2 instances — eliminates cross-AZ fees
→Public NAT Gateway MESTI dalam PUBLIC subnet (bukan private). Private NAT Gateway = untuk private routing, tak perlu IGW
→IPv6 outbound-only → Egress-Only Internet Gateway (EIGW), bukan NAT GW. NAT GW IPv6 = NAT64 (IPv6→IPv4) sahaja
→Connection limit: 55,000 simultaneous per unique destination per IP. Hit limit → ErrorPortAllocation metric. Tambah sampai 8 IP atau split subnet
→Tak boleh route ke NAT GW dari VPN/Direct Connect via VGW — guna Transit Gateway (TGW) instead
→PRICING: NAT Gateway = $0.045/jam + $0.045/GB processed (us-east-1, no free tier). Per-AZ → darab bilangan AZ. Heavy S3/DynamoDB traffic → Gateway VPC Endpoint (FREE) jauh lebih murah
→NAT GW TAKDE butang Stop/Start (lain dari EC2). Nak jimat luar waktu kerja → DELETE then CREATE semula. Automate: Lambda + EventBridge (cron) — delete malam, recreate pagi (NOTE: EIP & route table kena re-associate bila recreate)
→Check SEMUA kos NAT GW dalam 1 tempat: Cost Explorer → Filter Service = EC2-Other → Group by Usage Type → cari NatGateway-Hours (sewa jam) + NatGateway-Bytes (data processed). Bukan bawah service "EC2-Instances"
→ORG-LEVEL (Finance): kos NAT GW gabungan SEMUA account dalam AWS Organizations → buka Cost Explorer di MANAGEMENT (payer) account, Group by Linked Account → nampak kos tiap account 1 skrin. Tak payah login satu-satu member account
→Amaran kos auto (Finance malas belek dashboard) → AWS Budgets: set threshold (cth $2,000/bulan), emel bila lepas 80%. Analisis BI mendalam (SQL/dashboard) → AWS Cost and Usage Report (CUR)/Data Exports → S3 → Athena / QuickSight

Guna Bila

Private subnet instances download patches/call APIs without being exposed to internet

NAToutbound onlyprivate subnetElastic IPpaidno inboundbastion hostcross-AZ costper-AZ NAT Gatewaydata transfer chargesIPv6Egress-Only Internet GatewayEIGWNAT64ErrorPortAllocationconnection limit55000 connectionspricingStop Startdelete recreateLambda EventBridgeCost ExplorerEC2-OtherNatGateway-HoursNatGateway-BytesLinked AccountManagement Accountpayer accountAWS BudgetsCost and Usage ReportCURData ExportsQuickSightAthenaOrganizations costconsolidated costkongsi vs asing

📎 NAT Gateways 📎 NAT gateway basics

D1 · Secure

Route Tables

VPC Route Tables

"Papan tanda jalan — arah ke mana traffic pergi"

🎯 Sebab Apa Wujud

Wujud sebab dalam VPC, ada IGW atau NAT GW sahaja TAK CUKUP — traffic tak tahu nak pergi mana melainkan route table beritahu arahnya. Route table = papan tanda jalan: ia tetapkan destinasi (cth 0.0.0.0/0) pergi ke target mana (IGW untuk public, NAT GW untuk private outbound). Ini sebab punca paling biasa 'subnet takde internet walaupun ada IGW' ialah route table salah/tak associate.

Apa Dia

Setiap subnet mesti associate dengan satu route table. Route table ada rules yang tentukan ke mana traffic pergi. Tanpa route yang betul, internet tak boleh reach walaupun ada IGW. Main route table (default) dan custom route tables boleh ada dalam satu VPC.

Contoh Guna

Public RT: 172.16.0.0/16 → local, 0.0.0.0/0 → igw. Private RT: 172.16.0.0/16 → local, 0.0.0.0/0 → nat-gw.

Common Routes

Local → traffic dalam VPC sendiri (auto, tak boleh delete)

0.0.0.0/0 → igw-xxx (public subnet — keluar ke internet)

0.0.0.0/0 → nat-xxx (private subnet — outbound je)

10.0.0.0/16 → pcx-xxx (VPC peering route)

⚡ Quick Sifir — hafal ni

▪Setiap subnet WAJIB associate dengan SATU route table
▪Public subnet: 0.0.0.0/0 → IGW. Private outbound: 0.0.0.0/0 → NAT GW
▪Local route (CIDR VPC → local) auto ada, tak boleh delete
▪Satu subnet → satu route table; satu route table → boleh banyak subnet
▪No internet? Check: (1) route 0.0.0.0/0 ada? (2) subnet associate betul? (3) EC2 ada public IP?

💡 Exam Scenario

"Subnet tak dapat access internet walaupun ada IGW" → check route table! Ada 0.0.0.0/0 → IGW? Subnet dah associate dengan route table tu?

🪤 Perangkap Soalan

Q: EC2 dalam public subnet ada public IP, IGW dah attach ke VPC, tapi masih tak boleh akses internet. Apa paling mungkin punca?

⚠ Umpan: Security Group block outbound — kena tambah outbound rule. Nampak betul sebab 'SG kawal traffic'. SALAH: SG default outbound allow-all; lagi mungkin punca lain.

✓ Betul: Route table subnet tiada route 0.0.0.0/0 → IGW (atau subnet associate route table salah). Keyword 'ada IGW tapi takde internet' = check route table dulu.

🧠 Cara Mudah Ingat

→Troubleshoot no internet: (1) route 0.0.0.0/0 ada? (2) subnet associate route table betul? (3) EC2 ada public IP?
→Local route (e.g. 172.16.0.0/16 → local) auto ada — tak boleh delete
→Satu subnet → satu route table je. Satu route table → boleh serve banyak subnets

Guna Bila

Control traffic direction: public subnet → IGW, private subnet → NAT GW

route tablerouting0.0.0.0/0local routesubnet associationmain route table

📎 Route Tables

D1 · Secure

SG vs NACL

Security Groups vs Network ACLs — Defence Layers

"SG = Smart/Stateful (instance). NACL = Needs-both-ways/stateless (subnet)"

🎯 Sebab Apa Wujud

Dua lapisan wujud sebab satu firewall tak cukup untuk semua keperluan. SG jaga setiap instance secara pintar (stateful — ingat siapa kau, reply auto-lepas) tapi dia ALLOW-only, tak boleh block IP penyerang tertentu. NACL jaga sempadan subnet, boleh DENY (block IP/range), tapi stateless (cek setiap packet dua hala — kena allow ephemeral port balik). Guna dua-dua = defense-in-depth: SG kawal "siapa boleh cakap dengan siapa", NACL block ancaman di sempadan.

Apa Dia

SG dan NACL bekerja bersama sebagai firewall berlapis. SG (stateful) bekerja pada peringkat EC2 — ingat connections, reply auto dibenarkan, allow-only rules. NACL (stateless) bekerja pada peringkat subnet — check tiap packet, perlu explicit rules untuk inbound DAN outbound, boleh deny IPs.

Cara mudah ingat — NACL = Kastam 🛂, SG = Pengawal Pejabat 👮

Rendering diagram…

Analogi yang kau sendiri jumpa: NACL = Kastam (stateless — cerewet, cepat lupa, cek pasport tiap-tiap kali kau lintas sempadan). Security Group = Pengawal pejabat (stateful — ingat muka kau, dah kenal terus lepas). INGAT exam: sebab NACL "cepat lupa", trafik BALIK (reply) pun kena ada outbound rule allow port ephemeral 1024-65535 — kalau tak, sambungan mati separuh jalan.

Kenapa SSH gagal walaupun inbound allow — perangkap stateless

Rendering diagram…

Inbound benarkan SSH masuk, server pun terima — tapi bila server nak HANTAR BALIK reply (guna random high port 1024-65535), outbound NACL sekat. Sebab NACL stateless, return traffic tak auto-allow macam SG. INGAT exam: "Inbound allow tapi connection tetap gagal" → fikir outbound ephemeral ports. Kalau ini Security Group, dah jalan (stateful, reply auto-allow).

Security Group vs NACL

Aspect	Security Group	Network ACL
Level	EC2 instance / ENI	Subnet boundary
State	🟢 Stateful — reply auto-allowed	🔴 Stateless — check every packet both ways
Rules	Allow only	Allow + Deny
Default	Deny all in, allow all out	Default NACL: allow all · custom NACL: deny all
Block an IP	❌ Cannot deny	✅ Deny rule (lowest number wins)
Evaluation	All rules combined	Rules in order, stops at first match
Reference SG?	✅ Can reference another SG as source	❌ CIDR ranges only

Ingat: "Block a specific IP range" → NACL (only NACL can Deny). "Allow app→DB on port 3306 only" → Security Group. Guna dua-dua = defense-in-depth.

⚡ Quick Sifir — hafal ni

▪SG = Stateful (reply auto-allow) + level INSTANCE. NACL = Stateless + level SUBNET
▪SG = ALLOW only. Nak DENY/block IP tertentu → NACL
▪NACL stateless → kena allow outbound ephemeral port (1024-65535) untuk reply
▪SG boleh reference SG lain sebagai source. NACL = CIDR je
▪Custom SG: inbound deny-all. Custom NACL: deny-all (kena tambah rule sendiri)
▪NACL TAK nampak traffic dalam subnet SAMA (intra-subnet) → hanya SG kawal komunikasi 2 instance sesama subnet

💡 Exam Scenario

"Block specific IP range" → NACL Deny rule (SG cannot deny). "Allow web servers talk to DB on port 3306 only" → Security Group. Best practice: guna kedua-dua untuk defense-in-depth.

🪤 Perangkap Soalan

Q: Kau tambah inbound NACL rule allow SSH (port 22), tapi SSH ke EC2 masih GAGAL/timeout. SG dah allow 22. Apa puncanya?

⚠ Umpan: Inbound NACL salah priority / kena tambah lagi satu inbound rule. Nampak betul sebab fokus pada inbound (port 22).

✓ Betul: NACL stateless — reply server keluar guna ephemeral port (1024-65535), tapi outbound NACL tak allow port tu → reply tersekat, SSH gagal. Tambah outbound NACL allow 1024-65535. (Kalau ni SG je, dah jalan sebab stateful.) Keyword "inbound allowed tapi connection gagal" → outbound ephemeral NACL.

Q: Perlu BLOK satu julat IP penyerang (203.0.113.0/24) daripada mencapai keseluruhan subnet. Guna apa?

⚠ Umpan: Security Group — tambah rule untuk deny IP tu. Nampak betul sebab SG = firewall instance.

✓ Betul: NACL Deny rule (nombor rule rendah menang). SG TAK BOLEH deny — ia allow-only, jadi mustahil block IP tertentu dengan SG. Keyword "block/deny specific IP range" → NACL.

Q: Dua EC2 dalam subnet yang SAMA perlu bercakap sesama sendiri. Apa yang kawal traffic antara mereka?

⚠ Umpan: NACL — sebab NACL jaga subnet, dan dua-dua instance dalam subnet yang sama. Nampak betul tapi terbalik.

✓ Betul: Security Group sahaja. NACL beroperasi di SEMPADAN subnet (subnet boundary) — traffic yang tak keluar/masuk subnet TAK lalu NACL langsung, jadi NACL tak nampak komunikasi intra-subnet. Keyword "same subnet / instance-to-instance dalam subnet sama" → SG.

Q: SG inbound benarkan HTTPS (443) dari 0.0.0.0/0, tapi outbound dibiar default. Client komplen reply HTTPS tak sampai balik. Kena tambah outbound rule untuk port 443 atau ephemeral ports?

⚠ Umpan: Ya, tambah outbound allow ephemeral ports (1024-65535) supaya reply boleh keluar. Nampak betul sebab itu betul untuk NACL.

✓ Betul: Tak perlu tambah apa-apa. SG = STATEFUL — return traffic untuk connection masuk auto-dibenarkan keluar tanpa kira outbound rule. Cara fikir "tambah outbound ephemeral" tu untuk NACL (stateless), BUKAN SG. Keyword "stateful + return traffic" → auto-allow.

🧠 Cara Mudah Ingat

→SG = Stateful (ingat conversations). NACL = Stateless (check every packet)
→SG boleh reference SG lain sebagai source — "allow traffic FROM web-sg TO db-sg"
→NACL kena ada outbound ephemeral port rules (1024–65535) untuk replies boleh keluar
→Default NACL = allow all. Custom NACL = deny all — kena add rules sendiri

Guna Bila

Two-layer defence: SG guards each EC2, NACL guards each subnet

SGNACLstatefulstatelessinstance-levelsubnet-leveldenydefense-in-depth

📎 Security Groups 📎 Network ACLs

D1 · Secure

Laluan Packet VPC

Perjalanan Satu Packet — VPC Traffic Flow (end-to-end)

"Jejak JALAN, bukan hafal komponen. Pergi: IGW → Route Table → NACL → SG → EC2. Balik: terbalik, tapi SG ingat (auto), NACL lupa (kena rule)."

🎯 Sebab Apa Wujud

Wujud sebagai kad sebab punca #1 orang stuck dengan VPC ialah depa hafal komponen SECARA BERASINGAN ("NACL = subnet level", "SG = instance level") tanpa nampak susunan dia dalam satu laluan. Bila kau tahu urutan checkpoint, soalan macam "ada IGW tapi takde internet", "inbound allow tapi connection gagal", "dua EC2 subnet sama dikawal apa" — semua jadi automatik sebab kau cuma tanya: "packet ni sampai checkpoint mana, dan checkpoint tu buat apa?" Jejak laluan = ganti hafalan dengan logik.

Apa Dia

Ini bukan satu "servis" — ia model mental untuk faham macam mana semua komponen VPC bekerja sebagai SATU laluan. Bila satu packet datang dari internet ke EC2 kau, dia lalu checkpoint ikut turutan tetap: IGW (pintu VPC) → Route Table (papan tanda arah) → NACL (pengawal sempadan subnet) → Security Group (pengawal pintu instance) → baru sampai EC2. Reply balik ikut jalan terbalik. Hafal LALUAN ni, semua soalan VPC jadi automatik.

Perjalanan satu packet — pergi & balik (urutan checkpoint)

Rendering diagram…

Garisan tegas = packet pergi (request). Garisan putus = packet balik (reply). INGAT exam: masa BALIK, SG (stateful) auto-lepas reply tanpa outbound rule, tapi NACL (stateless) "kuat lupa" → kena ada outbound rule allow ephemeral port 1024-65535, kalau tak reply mati separuh jalan. Inilah punca trap "inbound allow tapi connection tetap gagal".

Public vs Private subnet — laluan keluar internet

Rendering diagram…

Public/private subnet BUKAN setting pada subnet — ia sifat ROUTE TABLE. Route 0.0.0.0/0 → IGW = subnet jadi public. Route 0.0.0.0/0 → NAT GW = subnet jadi private. INGAT exam: tukar route je, subnet sama tu bertukar sifat.

4 Checkpoint sepanjang laluan packet

Checkpoint	Peranan	Stateful?	Simptom bila tersilap
1️⃣ IGW	Pintu VPC ↔ internet + NAT public/private IP	—	Takde IGW/route → langsung no internet
2️⃣ Route Table	Tentukan arah (IGW / NAT / local)	—	"Ada IGW tapi takde internet" → route 0.0.0.0/0 hilang
3️⃣ NACL	Pengawal sempadan subnet, allow + deny	🔴 Stateless (2 hala)	"Inbound allow tapi gagal" → outbound ephemeral tak allow
4️⃣ Security Group	Pengawal instance, allow-only	🟢 Stateful (reply auto)	Lupa SG tak boleh block IP tertentu (guna NACL)

Ingat: Setiap simptom troubleshoot VPC = satu checkpoint tertentu pada laluan. Kenal pasti checkpoint = terus dapat jawapan. Inbound order: Route Table → NACL → SG.

⚡ Quick Sifir — hafal ni

▪Packet PERGI: IGW → Route Table → NACL → SG → EC2
▪Packet BALIK: EC2 → SG (stateful, AUTO lepas) → NACL (stateless, kena outbound ephemeral rule) → Route Table → IGW
▪NACL = pagar SUBNET (nampak bila lintas sempadan je). SG = pintu INSTANCE (nampak intra-subnet pun)
▪Public subnet = route 0.0.0.0/0 → IGW. Private subnet = route 0.0.0.0/0 → NAT GW
▪Bila stuck, tanya: "packet ni LINTAS sempadan subnet tak?" — itu tentukan NACL terlibat ke tidak

💡 Exam Scenario

"Order of evaluation packet masuk" → IGW → Route Table → NACL → SG → EC2. "Private subnet outbound internet" → NAT GW (bukan IGW terus). "Dua EC2 subnet sama" → SG je (tak lintas NACL).

🪤 Perangkap Soalan

Q: Packet dari internet menuju EC2 kau. Checkpoint mana ia jumpa DULU — Security Group atau NACL?

⚠ Umpan: Security Group dulu, sebab SG paling rapat dengan EC2 jadi ia "pertahanan pertama". Nampak masuk akal.

✓ Betul: NACL dulu, BARU Security Group. Packet kena lintas sempadan subnet (jumpa NACL = pagar) sebelum boleh sampai ke instance (jumpa SG = pintu rumah). Urutan masuk: IGW → Route Table → NACL → SG → EC2. Keyword "order of evaluation inbound" → NACL sebelum SG.

Q: EC2 dalam PRIVATE subnet perlu download patch dari internet. Route table dia patut tunjuk 0.0.0.0/0 ke mana?

⚠ Umpan: Terus ke IGW (Internet Gateway) — sebab nak akses internet kan? Nampak betul.

✓ Betul: Ke NAT Gateway (yang duduk dalam PUBLIC subnet), bukan terus ke IGW. EC2 private takde public IP, jadi tak boleh guna IGW terus — NAT GW yang tukar private IP → public untuk outbound sahaja. Keyword "private subnet + outbound internet" → NAT GW.

🧠 Cara Mudah Ingat

→Inbound: NACL (subnet) DULU, baru SG (instance). Outbound: SG dulu, baru NACL
→SG stateful → reply auto-allow. NACL stateless → reply kena outbound rule (ephemeral 1024-65535)
→Public/private subnet = sifat ROUTE TABLE (→ IGW vs → NAT GW), bukan setting subnet
→PRICING: laluan packet itu sendiri tiada caj. Tapi NAT GW (laluan private→internet) = $0.045/jam + $0.045/GB diproses — cost-trap biasa untuk traffic private subnet keluar internet

Guna Bila

Faham urutan checkpoint satu packet lalui dari internet sampai EC2 dan balik — kunci untuk semua soalan troubleshoot VPC

packet journeytraffic flowlaluan packetorder of evaluationIGW route table NACL SGinbound orderoutbound orderpublic subnetprivate subnetNAT Gatewayephemeral portsstatefulstatelesstroubleshoot VPCpricing

📎 How traffic flows (VPC)📎 Route tables 📎 Compare SG and NACL

D1 · Secure

VPC Peering

VPC Peering Connection

"Jambatan terus antara dua VPC — non-transitive"

🎯 Sebab Apa Wujud

Wujud sebab dua VPC by default terpencil sepenuhnya — tak boleh cakap antara satu sama lain walaupun dalam akaun sama. VPC Peering buat "jambatan" private terus antara dua VPC supaya resource boleh guna private IP tanpa lalu internet. Ringkas & murah (takde hourly fee) untuk sambungan 1-ke-1. Tapi dia NON-transitive (jambatan A-B + B-C tak buat A nampak C) — itu yang buat dia tak sesuai bila VPC dah ramai.

Apa Dia

VPC Peering allow dua VPC communicate menggunakan private IPs seolah-olah dalam network yang sama. NON-transitive — kalau A↔B dan B↔C, A TIDAK boleh reach C secara automatik. Kena buat A↔C peering berasingan.

Contoh Guna

Production VPC (172.16.0.0/16) peer dengan Shared Services VPC (10.0.0.0/16) — team boleh access shared tools secara private.

Analogi: Jambatan rumah-ke-rumah (non-transitive)

Rendering diagram…

Peering NON-transitive: jambatan A-B + B-C tak buatkan A nampak C. Ramai VPC → terlalu banyak jambatan (mesh). INGAT exam: 3+ VPC mesh / hybrid on-prem → Transit Gateway (roundabout tengah).

VPC Peering vs Transit Gateway

Aspect	VPC Peering	Transit Gateway
Topology	🟢 1-to-1 link antara 2 VPC	Hub-and-spoke (hub tengah)
Transitive	No — A↔B + B↔C tapi A✗C	🟢 Yes — A reach C via hub
Scale (10 VPC)	45 link [n(n-1)/2] 😵	🟢 10 attachment je
On-prem (VPN/DX)	Tak boleh attach	🟢 Attach VPN + Direct Connect ke hub
Edge-to-edge	TAK sokong (B tak boleh guna NAT/IGW A)	Routing via hub
Cost	🟢 No hourly fee (data transfer je)	Hourly per attachment + data processing

Ingat: 2 VPC sahaja → Peering (murah, simple, no hourly fee). 3+ VPC all-to-all atau perlu connect on-prem → Transit Gateway. Discriminator exam: "non-transitive / overlap CIDR / 2 VPC" → Peering; "mesh / banyak VPC / hybrid / ECMP" → TGW.

⚡ Quick Sifir — hafal ni

▪2 VPC sahaja → Peering (murah, no hourly fee, data transfer je)
▪NON-transitive: A↔B + B↔C TAK buat A↔C. Kena peering A↔C sendiri
▪IP CIDR WAJIB tak overlap — overlap = tak boleh peer
▪Edge-to-edge TAK disokong: VPC B tak boleh guna NAT/IGW/VPN/DX milik VPC A
▪3+ VPC all-to-all atau perlu connect on-prem → Transit Gateway

💡 Exam Scenario

"Connect dua VPC" → VPC Peering. Ingat: IP ranges TAK BOLEH overlap! Non-transitive — A reach C kena buat A↔C peering sendiri. 3+ VPCs all-to-all = guna Transit Gateway.

🪤 Perangkap Soalan

Q: Syarikat ada 6 VPC dan semua perlu boleh cakap antara satu sama lain (full mesh). Mereka mula buat VPC Peering. Pendekatan terbaik?

⚠ Umpan: Teruskan VPC Peering antara setiap pasangan VPC. Nampak betul sebab peering memang untuk sambung VPC dan lebih murah per-link.

✓ Betul: AWS Transit Gateway. Peering non-transitive, jadi 6 VPC full-mesh = 15 peering link (n(n-1)/2) untuk urus — tak scalable & mimpi ngeri routing. TGW = hub transitive, 6 attachment je. Keyword "3+ VPC all-to-all / mesh / banyak VPC" → Transit Gateway.

Q: VPC A ada NAT Gateway. VPC B di-peer dengan A. Boleh ke instance dalam B keluar internet melalui NAT Gateway milik A?

⚠ Umpan: Boleh — dah peered, jadi B boleh guna resource A termasuk NAT Gateway. Nampak betul sebab "peered = berkongsi".

✓ Betul: TAK BOLEH. VPC Peering tak sokong edge-to-edge routing — B tak boleh guna NAT/IGW/VPN/DX milik A. VPC B kena ada NAT Gateway sendiri. Keyword "peered VPC share NAT/IGW" → tidak.

🧠 Cara Mudah Ingat

→Non-transitive: A↔B dan B↔C, tapi A TIDAK reach C. Macam "kawan kawan bukan kawan aku"
→IP ranges WAJIB tak overlap — 172.16.0.0/16 dengan 172.16.0.0/24 = KONFLIK, tak boleh peer
→3+ VPCs semua perlu communicate = Transit Gateway (lebih simple dari peering mesh)
→Edge-to-edge routing TIDAK disokong: NAT Gateway, IGW, VPN, Direct Connect, dan S3 Gateway endpoint dalam VPC A TIDAK boleh digunakan oleh resources dalam peered VPC B
→"VPC A ada NAT Gateway, VPC B peered dengan A, boleh B guna NAT tu?" → TIDAK. B kena ada NAT Gateway sendiri
→Route table untuk VPC peering: guna SPECIFIC subnet CIDR (bukan full VPC CIDR) untuk limit access between specific subnets only

Guna Bila

Connect 2 VPCs privately — same account, cross-account, atau cross-region

VPC peeringcross-accountcross-regionnon-transitiveno IP overlapprivate routing

📎 VPC Peering Guide

D1 · Secure

Transit Gateway

AWS Transit Gateway

"Hub tengah yang connect semua VPCs — gantikan peering mesh"

🎯 Sebab Apa Wujud

Wujud sebab VPC Peering jadi mimpi ngeri bila VPC ramai — non-transitive, jadi 20 VPC full-mesh = 190 peering link untuk urus & route. TGW jadi HUB tengah: setiap VPC/VPN/Direct Connect "attach" sekali ke hub, dan hub uruskan routing transitif (A boleh capai C melalui hub tanpa link langsung). Tambah on-prem pun senang (attach VPN/DX ke hub). Tujuan: ganti peering mesh kompleks dengan satu hub yang scalable + sambung hybrid.

Apa Dia

TGW bertindak sebagai network transit hub yang boleh connect ribuan VPCs, VPNs, dan Direct Connect. Menggantikan peering mesh yang kompleks. TRANSITIVE — VPC A boleh reach VPC C melalui TGW tanpa A↔C peering. Tanpa TGW, 10 VPCs = n*(n-1)/2 = 45 peering connections.

Contoh Guna

Company ada 10 VPCs dari pelbagai teams + 2 on-premises data centers → satu TGW connect semua. Kos naik tapi operationally jauh lebih simple.

Analogi: Roundabout tengah (hub transitive)

Rendering diagram…

TGW = satu roundabout: semua VPC + on-prem attach SEKALI ke hub, hub route semua (transitive). 10 VPC = 10 attachment je, bukan 45 jambatan. INGAT exam: "banyak VPC mesh / sambung on-prem / ECMP aggregate VPN" → Transit Gateway.

VPC Peering vs Transit Gateway

Aspect	VPC Peering	Transit Gateway
Topology	1-to-1 link between 2 VPCs	🟢 Hub-and-spoke, central hub
Transitive routing	No — A↔B, B↔C tapi A✗C	🟢 Yes — A reach C via hub
Scale	Mesh grows fast: 10 VPCs = 45 links	🟢 10 VPCs = 10 attachments
On-prem (VPN/DX)	Not via peering	🟢 Attach VPN + Direct Connect to hub
Cost	🟢 No hourly fee (data transfer only)	Hourly per attachment + data processing
Use when	Just 2 VPCs, simplest + cheapest	3+ VPCs all-to-all, or hybrid network

Ingat: 2 VPCs → Peering (cheaper, simple). 3+ VPCs all-to-all atau perlu connect on-prem → Transit Gateway (transitive hub, elak peering mesh). Peering non-transitive, TGW transitive.

⚡ Quick Sifir — hafal ni

▪TGW = hub-and-spoke TRANSITIVE. Peering = 1-to-1 non-transitive
▪10 VPC: TGW = 10 attachment; Peering mesh = 45 link
▪TGW boleh attach VPN + Direct Connect → sambung on-prem ke hub (peering tak boleh)
▪TGW ada hourly fee per attachment + data processing. Peering takde hourly fee
▪ECMP untuk aggregate throughput VPN → TGW sahaja (VGW tak support ECMP)
▪2 VPC je → Peering (murah). 3+ all-to-all / hybrid → TGW

💡 Exam Scenario

"Many VPCs perlu communicate dengan satu sama lain" → Transit Gateway. "Hanya 2 VPCs" → VPC Peering (simpler, lebih murah). TGW = transitive, VPC Peering = non-transitive.

🪤 Perangkap Soalan

Q: Perlu naikkan throughput Site-to-Site VPN melebihi had ~1.25 Gbps satu tunnel, dengan agregat beberapa tunnel. Setup mana?

⚠ Umpan: Sambung multiple VPN ke Virtual Private Gateway (VGW) dan biar ia agregat tunnel. Nampak betul sebab VGW memang endpoint VPN standard.

✓ Betul: Multiple Site-to-Site VPN ke Transit Gateway dengan ECMP enabled. VGW TIDAK menyokong ECMP, jadi tak boleh agregat tunnel. Hanya TGW boleh ECMP untuk gabungkan bandwidth beberapa tunnel. Keyword "aggregate VPN throughput / ECMP" → Transit Gateway, bukan VGW.

🧠 Cara Mudah Ingat

→2 VPCs = Peering (cheaper). 3+ VPCs all-to-all = Transit Gateway (simpler)
→TGW support TRANSITIVE routing — ini perbezaan utama dari VPC Peering
→TGW boleh connect cross-region (Inter-Region Peering) dan cross-account
→ECMP (Equal Cost Multi-Path): hanya Transit Gateway yang support ECMP untuk VPN — Virtual Private Gateway (VGW) TIDAK support
→Untuk tingkatkan VPN throughput: buat multiple Site-to-Site VPN connections ke TGW dengan ECMP enabled — aggregate bandwidth
→Satu VPN tunnel = max 1.25 Gbps. Dengan ECMP + TGW: boleh aggregate multiple tunnels untuk higher total throughput

Guna Bila

Connect 3+ VPCs dan on-premises networks melalui satu hub yang transitive

Transit Gatewayhubtransitive routingmany VPCsreplace peering meshon-premisescross-accountECMPVPN throughputmultiple tunnelsaggregate bandwidth

📎 Transit Gateway

D1 · Secure

VPC Endpoints

VPC Endpoints (Gateway & Interface)

Sepasang akronim poket: "GD Free" = Gateway → DynamoDB + S3, FREE, Route Table | "IP Paid" = Interface → PrivateLink/Pelbagai servis, PAID, ENI. Habis 100% skop VPC Endpoints.

🎯 Sebab Apa Wujud

Wujud sebab tanpa endpoint, private subnet nak cakap dengan S3/DynamoDB/SSM kena lalu NAT Gateway → IGW → internet (public path) → bayar NAT per-GB + traffic keluar internet (kurang selamat). VPC Endpoint bagi laluan PRIVATE terus ke AWS service dalam network AWS — Gateway Endpoint (S3/DynamoDB) percuma jimat NAT fees, Interface Endpoint (PrivateLink) untuk service lain. Bonus: boleh kunci S3 bucket supaya HANYA terima dari endpoint ni (compliance).

Apa Dia

Tiga jenis: Gateway Endpoint (S3 + DynamoDB, free, guna route table), Interface Endpoint (services lain via PrivateLink, ada ENI dalam subnet, berbayar), dan Gateway Load Balancer Endpoint/GWLBe (salurkan traffic ke inline security appliance). Traffic tak keluar ke internet langsung — lebih selamat dan murah (jimat NAT GW data fees). PENTING: PrivateLink bukan saja untuk GUNA service orang — kau pun boleh DEDAH service sendiri ke VPC/customer lain (Endpoint Service + NLB) tanpa VPC Peering.

Contoh Guna

EC2 private subnet banyak upload ke S3. Tanpa endpoint: bayar NAT GW per GB. Dengan S3 Gateway Endpoint (free): traffic terus dalam AWS network.

Soalan exam: EC2 akses Secrets Manager tanpa internet

Rendering diagram…

INGAT exam: Secrets Manager API memang public endpoint, jadi tanpa endpoint EC2 kena keluar internet (lalu NAT GW/IGW). Interface VPC Endpoint letak ENI (private IP) dalam subnet kau → traffic terus ke Secrets Manager dalam network AWS, tak pernah sentuh internet. Itu jawapan A. NAT Gateway (D) tetap lalu internet = tak selesai masalah; Site-to-Site VPN (B) untuk on-prem; Gateway Endpoint (C) hanya S3/DynamoDB.

Decision: Gateway vs Interface Endpoint

Rendering diagram…

Cara cepat: hanya DUA service guna Gateway Endpoint — S3 & DynamoDB ("GD Free"). Apa-apa service lain yang nak diakses private = Interface Endpoint (PrivateLink). Secrets Manager bukan S3/DynamoDB → mesti Interface.

PrivateLink provider → consumer (dedah service tanpa peering)

Rendering diagram…

Provider letak app belakang NLB → daftar sebagai Endpoint Service. Consumer cucuk Interface Endpoint → connect terus ke SATU service tu sahaja. Tiada VPC Peering, tiada IGW, CIDR tak perlu unik. INGAT exam: "expose/share my own application privately to other VPCs or SaaS customers" → AWS PrivateLink (Endpoint Service + NLB), BUKAN VPC Peering/TGW.

Gateway vs Interface vs Gateway LB Endpoint (3 jenis)

Aspect	Gateway Endpoint	Interface Endpoint	GWLBe
Teknologi	Route table (prefix list)	🟢 PrivateLink (ENI + private IP)	🟢 PrivateLink
Sokong	S3 + DynamoDB SAHAJA	Hampir semua AWS service + SaaS	Inline security appliance (firewall/IDS)
Cost	🟢 Free	~$0.01/hr/AZ + $0.01/GB	Per-hour + GWLCU
Akses dari on-prem	❌ In-VPC je	🟢 Ya (VPN/DX, ada private IP)	Via routing ke appliance
DNS	No private DNS	Private DNS → resolve ke ENI	N/A (routing-based)
Guna bila	S3/DynamoDB, jimat NAT	Service lain / SaaS / from on-prem	Salurkan traffic ke 3rd-party firewall

Ingat: "GD Free" → Gateway = S3 + DynamoDB sahaja, route table, percuma. Service lain / SaaS / from on-prem → Interface (PrivateLink, ENI, berbayar). Inline firewall/IDS appliance → GWLBe. Interface & GWLBe dua-dua PrivateLink-powered; Gateway TIDAK.

PrivateLink: Consumer side vs Provider side (selalu terlepas!)

Aspect	Consumer (guna service orang)	Provider (dedah service aku)
Komponen	Interface Endpoint (ENI dalam subnet aku)	🟢 Endpoint Service + NLB (atau GWLB)
Tujuan	Aku nak GUNA AWS/SaaS service privately	Aku nak EXPOSE app aku ke VPC/customer lain
Arah	Consumer → Provider (one-directional)	Provider terima dari consumer
Vs Peering/TGW	N/A	🟢 Dedah SATU service je (bukan whole network), CIDR boleh overlap
Guna bila	Access Secrets Manager/KMS/SSM tanpa internet	Jual/kongsi app sendiri privately tanpa peering

Ingat: PrivateLink ada DUA hala: CONSUMER = Interface Endpoint (guna service orang); PROVIDER = Endpoint Service + NLB (dedah service sendiri). INGAT exam: "expose my own app to another VPC/customer privately tanpa peering/internet" → PrivateLink Endpoint Service + NLB, BUKAN VPC Peering/TGW.

aws:SourceVpc vs aws:SourceVpce — beza SATU huruf (condition key dalam bucket/resource policy)

Condition key	Skop	Least privilege?
aws:SourceVpc	SELURUH VPC (VPC ID) — mana-mana dalam VPC tu lepas	Lebih LUAS
aws:SourceVpce	Satu VPC Endpoint TERTENTU je (endpoint ID — ada "e" hujung)	🟢 Lebih KETAT / spesifik

Ingat: Vpc = seluruh VPC ("benarkan sesiapa dalam bangunan"); Vpce = satu endpoint je ("hanya orang lalu pintu khas ni"). INGAT exam: soalan sebut "least privilege / restrict to a specific endpoint" → aws:SourceVpce. Detail ni jarang keluar SAA-C03 (lebih ke Security Specialty) — yang WAJIB cuma "private access tanpa internet → VPC Endpoint".

⚡ Quick Sifir — hafal ni

▪"GD Free" → Gateway Endpoint = S3 + DynamoDB SAHAJA, percuma, guna route table
▪"IP Paid" → Interface Endpoint = PrivateLink, Pelbagai service (ECR/SSM/KMS/SQS…), ada ENI, berbayar (per-jam + per-GB)
▪Gateway Endpoint = in-VPC only. Interface Endpoint = boleh dari on-prem (VPN/DX) sebab ada DNS+ENI
▪aws:sourceVpce dalam bucket policy = kunci S3 terima dari satu endpoint je
▪Connectivity ≠ Authorization: route betul ≠ S3 terima; bucket policy boleh DENY walaupun network sampai
▪PrivateLink 2 hala: CONSUMER = Interface Endpoint (guna service orang); PROVIDER = Endpoint Service + NLB (dedah service aku)
▪Expose app sendiri ke VPC/customer lain tanpa peering → PrivateLink Endpoint Service (BUKAN VPC Peering/TGW)
▪Jenis ke-3: GWLBe (Gateway Load Balancer Endpoint) → salurkan traffic ke inline firewall/IDS appliance, pun PrivateLink

💡 Exam Scenario

"Access S3/DynamoDB dari private subnet tanpa internet" → Gateway VPC Endpoint (free). "Access ECR, SSM, Secrets Manager, KMS atau services lain privately / tanpa internet" → Interface Endpoint (PrivateLink). Jangan terpedaya NAT Gateway — NAT GW tetap lalu public internet.

🪤 Perangkap Soalan

Q: Nak access SSM Parameter Store + ECR secara private dari private subnet. Gateway Endpoint?

⚠ Umpan: Gateway Endpoint — sebab dia free, kenapa tak guna. SALAH: Gateway Endpoint sokong S3 + DynamoDB SAHAJA.

✓ Betul: Interface Endpoint (PrivateLink). SSM, ECR, KMS, SQS dll semua Interface Endpoint. Gateway Endpoint cuma S3 & DynamoDB ("GD Free").

Q: Bucket policy ada Condition aws:sourceVpce = vpce-123. EC2 reach S3 lalu NAT Gateway (network route OK). Request berjaya?

⚠ Umpan: Berjaya — sebab NAT Gateway secara teknikal boleh route sampai S3, connectivity ada.

✓ Betul: GAGAL (Access Denied). Request lalu NAT→IGW (public path), bukan via vpce-123, jadi bucket policy DENY. Connectivity (boleh sampai) ≠ Authorization (dibenarkan).

Q: EC2 perlu akses Secrets Manager secara PRIVATE (tak nak lalu public internet). Security team risau Secrets Manager perlu internet. Recommend apa?

⚠ Umpan: NAT Gateway dalam public subnet (D) — atau Gateway Endpoint (C) sebab "VPC Endpoint untuk private access". SALAH dua-dua: NAT GW tetap lalu internet (tak selesai), Gateway Endpoint sokong S3/DynamoDB SAHAJA.

✓ Betul: Interface VPC Endpoint (PrivateLink) untuk Secrets Manager. Letak ENI private IP dalam subnet → traffic terus dalam network AWS, tak sentuh internet. Keyword: "access AWS service (selain S3/DynamoDB) privately / tanpa internet" → Interface Endpoint.

Q: Syarikat SaaS nak biar customer (VPC/akaun lain) akses aplikasi mereka secara private — tanpa expose ke internet dan tanpa VPC Peering. Cara terbaik?

⚠ Umpan: VPC Peering atau Transit Gateway antara provider dan setiap customer. Nampak betul sebab "sambung VPC". SALAH: peering/TGW buka network penuh dua-hala + kena urus CIDR tak overlap untuk setiap customer = tak scalable & kurang selamat.

✓ Betul: AWS PrivateLink — provider daftar Endpoint Service (belakang NLB), customer connect guna Interface Endpoint. Dedah SATU service je, one-directional, CIDR boleh overlap. Keyword "expose my own app/SaaS to other VPCs privately, no peering" → PrivateLink Endpoint Service.

Q: EC2 connect ke KMS lalu AWS network (BUKAN internet), least privilege, restrict ke endpoint TERTENTU. Key policy condition guna apa?

⚠ Umpan: aws:SourceVpc — nampak betul sebab "dari VPC aku". SALAH: SourceVpc benarkan SELURUH VPC, kurang ketat untuk "least privilege".

✓ Betul: aws:SourceVpce (ada "e" hujung = VPC Endpoint ID) — hadkan ke satu endpoint tertentu sahaja = paling spesifik = least privilege. Buang dulu pilihan "over the internet" + NAT Gateway (dua-dua lalu internet). Keyword "least privilege + specific endpoint" → SourceVpce.

🧠 Cara Mudah Ingat

→"GD Free" — Gateway Endpoint untuk S3 + DynamoDB = PERCUMA
→Interface Endpoint = semua services lain (ECR, SSM, KMS...) = berbayar (ada ENI)
→Gateway Endpoint guna route table. Interface Endpoint guna DNS/PrivateLink
→Gateway Endpoint jimatkan NAT GW cost bila EC2 banyak access S3/DynamoDB
→TRAP: Bucket policy boleh kunci S3 supaya HANYA terima request dari satu VPC endpoint guna Condition aws:sourceVpce (atau aws:sourceVpc). Bila ON, request yang lalu NAT Gateway → Internet Gateway (jalan public) di-DENY — walaupun NAT Gateway secara teknikal boleh sampai S3. Soalan uji sama ada kau perasan bucket policy, bukan sekadar network path.
→Connectivity ≠ Authorization: NAT Gateway "boleh route ke S3" (connectivity) berbeza dengan "S3 terima request ni" (bucket policy authorization). Dua kawalan berasingan — endpoint kena ada dalam route table DAN bucket policy kena benarkan sumbernya.

Guna Bila

Access S3/DynamoDB (free) atau AWS services lain (paid) dari private subnet secara private

VPC endpointGateway endpointInterface endpointPrivateLinkS3DynamoDBno internetfreeaws:sourceVpcebucket policyNAT Gateway deniedaws:sourceVpcEndpoint ServiceGWLBeGateway Load Balancer EndpointNLBexpose own serviceMarketplace SaaSprovider consumerno peering

📎 VPC Endpoints 📎 Gateway Endpoints 📎 Restrict S3 bucket access to a VPC endpoint