Deep Notes

Detailed Explanations

Baca, faham, ingat. Setiap service dijelaskan dengan context exam — kenapa guna, bila guna, dan exam scenario.

DOMAIN 1 · 30% OF EXAM

Design Secure Architectures

IAM & Identity · Network Security · Data Protection · Connectivity

🔑IAM & Identity↑ Top

IAM

AWS Identity and Access Management

"Siapa boleh buat apa dalam AWS"

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

🧠 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

Guna Bila

Control who can access what AWS resources

usersgroupsrolespoliciesleast privilegeMFAprincipalsidentity federation

STS

AWS Security Token Service

"Pinjam IC sementara"

Apa Dia

Menyediakan credentials sementara (access key, secret key, session token) untuk access AWS resources

Contoh Guna

Developer nak test dengan AWS account lain — AssumeRole via STS, dapat temp credentials tanpa perlu IAM user baru

Guna Bila

Generate temporary security credentials

temporary credentialsAssumeRolecross-accountfederation

Directory Service

AWS Directory Service

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

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.

🧠 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)

Guna Bila

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

Active DirectoryManaged Microsoft ADAD ConnectorSimple ADLDAPKerberosGroup Policyon-premises AD

IAM Identity Center

AWS IAM Identity Center (SSO)

"Satu login, semua AWS accounts"

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

🧠 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

Guna Bila

Centralized SSO untuk multiple AWS accounts

SSOsingle sign-onmultiple accountsfederationSAML 2.0Active DirectorySaaS integrationEC2 WindowsFleet Manager

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

Penetration Testing

AWS Penetration Testing Policy

"Boleh test sendiri — tapi ada had"

Apa Dia

AWS membenarkan pelanggan menjalankan security assessments atau penetration tests terhadap infrastruktur AWS mereka sendiri tanpa kelulusan awal untuk 8 perkhidmatan yang dibenarkan. Activities yang dilarang termasuk DoS/DDoS simulation, port flooding, dan DNS zone walking.

Contoh Guna

Security team nak test EC2 instances atau RDS databases untuk vulnerabilities — dibenarkan tanpa minta izin AWS terlebih dahulu.

💡 Exam Scenario

"AWS Acceptable Use Policy", "penetration testing position", "security assessments on AWS" → AWS allow for SOME resources WITHOUT prior authorization (not all, not none). 8 permitted services include EC2, RDS, CloudFront, Aurora, API Gateways, Lambda, Lightsail, Elastic Beanstalk.

Guna Bila

Security assessments on your own AWS infrastructure

penetration testingsecurity assessmentAcceptable Use PolicyAUPno prior approval8 servicesprohibited activities

Cognito

Amazon Cognito

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

Apa Dia

User auth untuk web/mobile apps. User Pools (authentication) vs Identity Pools (AWS credentials).

💡 Exam Scenario

"Web app perlu user registration dan login" → Cognito User Pools. "Mobile app user perlu access S3 directly" → Identity Pool untuk temp AWS credentials.

🧠 Cara Mudah Ingat

→Cognito User Pools support federated identity — users TAK PERLU di-create dalam AWS, boleh authenticate guna external IdPs (Facebook, Google, etc.)

Guna Bila

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

User PoolsIdentity PoolsOAuthJWTfederated identityMFA

RAM

AWS Resource Access Manager

"Share AWS resources antara accounts tanpa copy"

Apa Dia

Membenarkan perkongsian resources AWS merentasi akaun tanpa pendua.

💡 Exam Scenario

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

🧠 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

AWS Organizations

AWS Organizations + Control Tower + SCPs

"HQ yang kawal semua anak syarikat"

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

🧠 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

Guna Bila

Manage multiple AWS accounts centrally with guardrails

multi-accountSCPsguardrailsControl Towermanagement accountOUmanagement account exemptionSCP cannot grantS3 Block Public Access SCP

🛡️Network Security↑ Top

Security Groups

VPC Security Groups

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

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.

💡 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).

🧠 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

Guna Bila

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

statefulinstance-levelallow onlycustom SG defaultinbound deniedoutbound allowed

📎 Security Groups

NACLs

Network Access Control Lists

"Guard kat pintu masuk subnet — check both ways"

Apa Dia

Mengawal traffic masuk dan keluar subnet secara stateless — kena ada rule eksplisit untuk inbound DAN outbound

Contoh Guna

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

🧠 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. DENY rule kena nombor lebih kecil dari ALLOW
→Outbound replies perlu allow ephemeral ports 1024–65535

Guna Bila

Subnet-level firewall, stateless, boleh block IP

statelesssubnet-levelallow & denynumbered rulesexplicit both ways

📎 Network ACLs

WAF

AWS Web Application Firewall

"Penapis website dari serangan Layer 7"

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

🧠 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

Guna Bila

Protect against SQL injection, XSS, rate limiting

Layer 7SQL injectionXSSrate limitingmanaged rulesALBCloudFrontURI-specific rate-based ruletargeted throttling

AWS Shield

AWS Shield Standard & Advanced

"Pelindung DDoS — Standard free, Advanced bayar"

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

🧠 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

Guna Bila

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

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

Network Firewall

AWS Network Firewall

"Polis traffic dalam VPC — deep inspection"

Apa Dia

Menyediakan firewall managed untuk inspect dan filter traffic dalam VPC dengan stateful rules dan intrusion prevention

Contoh Guna

Company policy semua outbound traffic kena inspect untuk block malicious domains — deploy Network Firewall kat centralized VPC, route semua traffic melaluinya

Guna Bila

VPC-level stateful deep packet inspection, domain filtering

deep packet inspectionstatefulVPC-levelintrusion preventiondomain filtering

GuardDuty

Amazon GuardDuty

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

Apa Dia

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

💡 Exam Scenario

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

🧠 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

Guna Bila

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

threat detectionMLCloudTrail logsVPC Flow Logsno agentsfindingsS3 Protectionmanagement eventsdata eventsobject-level API

Detective

Amazon Detective

"Siasatan selepas GuardDuty detect — forensics AWS"

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.

💡 Exam Scenario

"GuardDuty flagged suspicious EC2 activity — siasatan lanjut untuk faham scope dan root cause" → Amazon 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

Inspector

Amazon Inspector

"Scanner kelemahan EC2 dan containers"

Apa Dia

Pengimbasan kelemahan automatik untuk EC2 dan container images.

💡 Exam Scenario

"Audit EC2 instances untuk known CVEs dan security misconfigurations" → Amazon Inspector. Bukan GuardDuty (yang untuk active threats).

Guna Bila

Find OS vulnerabilities, CVEs in EC2 instances and ECR images

vulnerability scanningCVEEC2ECRautomatedsecurity findings

Macie

Amazon Macie

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

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.

💡 Exam Scenario

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

🧠 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)

Guna Bila

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

PII detectionsensitive dataS3ML-baseddata privacyGDPRdata discoverypolicy findings

Penetration Testing

AWS Penetration Testing Policy

"AWS bagi pentest 8 services — tak perlu minta kebenaran dulu"

Apa Dia

AWS membenarkan customers jalankan security assessments dan penetration tests terhadap AWS infrastructure mereka TANPA kelulusan awal untuk 8 services: EC2, RDS, CloudFront, Aurora, API Gateway, Lambda, Lightsail, Elastic Beanstalk. Aktiviti yang DILARANG: DoS/DDoS simulation, DNS zone walking, port/protocol/request flooding.

💡 Exam Scenario

"What is AWS position on penetration testing?" → AWS allow pentest on SOME resources WITHOUT prior authorization. Bukan semua resources, bukan tiada langsung — 8 services spesifik sahaja.

🧠 Cara Mudah Ingat

→AWS MEMBENARKAN pentest pada 8 services tanpa perlu minta approval — ini exam trick, ramai sangka kena minta dulu
→Yang DILARANG: DoS/DDoS simulation, DNS zone walking, port flooding — semua ini violate AUP
→SALAH: "AWS tak benarkan pentest langsung" — salah, AWS memang bagi untuk services tertentu
→SALAH: "Boleh pentest SEMUA resources" — salah, ada services yang tidak dibenarkan
→AWS Acceptable Use Policy (AUP) = dokumen yang define apa yang boleh dan tak boleh buat kat AWS

Guna Bila

Understand AWS policy on security testing and acceptable use

penetration testingpentestsecurity assessmentAUPAcceptable Use Policyno prior approval8 services

📎 AWS Penetration Testing

🔐Data Protection↑ Top

KMS

AWS Key Management Service

"Simpan dan urus kunci enkripsi"

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

🧠 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 keysdigital signingmulti-region keysaws:SourceVpce

Secrets Manager

AWS Secrets Manager

"Simpan password apps, auto-rotate"

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

Guna Bila

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

auto-rotationcredentialsAPI keysno hardcoded secretsLambda integration

S3 Object Lock

Amazon S3 Object Lock

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

Apa Dia

Menghalang objek S3 dari dihapuskan atau diubah suai dalam tempoh tertentu untuk pematuhan kawal selia

Contoh Guna

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

Guna Bila

WORM compliance, prevent deletion/modification

WORMcomplianceretention periodGovernance modeCompliance modelegal hold

S3 Glacier Vault

Amazon S3 Glacier Vault Lock & Access Policy

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

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.

🧠 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
→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 archive

Amazon Redshift

Amazon Redshift — Encryption & DataShare

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

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.

💡 Exam Scenario

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

🧠 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
→AQUA (Advanced Query Accelerator): distributed cache yang bawa computation dekat ke storage dalam Redshift
→AQUA offload data-intensive query processing — reduce CPU dan network bottlenecks pada compute nodes
→Available pada Redshift ra3 instances, no extra charge. Bukan Redshift Spectrum (yang query external S3 data)
→Exam: "improve Redshift query performance, minimize cost and overhead" → AQUA (bukan ElastiCache atau Spectrum)

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 ETLAQUAquery acceleratorra3

📎 Redshift Encryption

CloudTrail

AWS CloudTrail

"CCTV untuk semua API calls AWS"

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.

💡 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.

🧠 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).

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 Events

ACM

AWS Certificate Manager

"SSL cert percuma untuk HTTPS"

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.

💡 Exam Scenario

"Website perlu HTTPS" → request ACM cert, attach ke ALB atau CloudFront (free). Ingat: ACM certs tak boleh export untuk pakai dalam EC2 sendiri — untuk tu kena beli cert luar.

🧠 Cara Mudah Ingat

→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 certs. Email validation = manual action required
→ACM certs cannot be exported/installed on EC2 directly — for EC2, buy third-party cert or use ACM with ALB/CloudFront

Guna Bila

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

SSLTLSHTTPSfree certificateauto-renewalALBCloudFrontAPI GatewayDNS validationemail validationpending validation

CloudHSM

AWS CloudHSM

"KMS tapi kau fully control dedicated hardware"

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.

💡 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.

🧠 Cara Mudah Ingat

→Transparent Data Encryption (TDE) support: Oracle RDS + CloudHSM = supported. SQL Server RDS + CloudHSM = NOT directly supported
→Single-tenant HSM requirement + TDE + RDS → use Oracle on RDS with CloudHSM integration
→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

Guna Bila

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

dedicated HSMFIPS 140-2 Level 3customer controlsingle-tenanthardware securityTDEOracle RDSTransparent Data EncryptionEBKPBKbackup

🔗Connectivity↑ Top

Direct Connect

AWS Direct Connect

"Kabel terus ke AWS — private dedicated lane"

Apa Dia

Menyediakan sambungan jaringan peribadi yang berdedikasi antara data center on-premises dengan AWS

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

Guna Bila

Private dedicated connection from on-premises to AWS

dedicated connectionprivateconsistent latency1Gbps/10Gbpsno internet

Site-to-Site VPN

AWS Site-to-Site VPN

"Tunnel rahsia ke AWS, guna internet biasa"

Apa Dia

Mewujudkan sambungan VPN yang disulitkan antara on-premises network dengan AWS VPC menggunakan internet sedia ada

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

Guna Bila

Encrypted IPSec tunnel from on-premises to VPC over internet

IPSecencryptedinternet-basedVirtual Private Gatewayquick setupcost-effective

Client VPN

AWS Client VPN

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

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.

💡 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.

🧠 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

Guna Bila

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

Client VPNuser authenticationOpenVPNSAMLauthorization rulesper-user accessremote accesstemporary access

🏘️VPC & Networking↑ Top

VPC

Amazon Virtual Private Cloud

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

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

💡 Exam Scenario

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

🧠 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

CIDR & Subnets

IP Addressing & Subnet Calculator

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

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)

💡 Exam Scenario

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

🧠 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

Internet Gateway

VPC Internet Gateway (IGW)

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

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.

💡 Exam Scenario

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

🧠 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

NAT Gateway

Network Address Translation Gateway

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

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.

💡 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.

🧠 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

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 charges

📎 NAT Gateways

Route Tables

VPC Route Tables

"Papan tanda jalan — arah ke mana traffic pergi"

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)

💡 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?

🧠 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

SG vs NACL

Security Groups vs Network ACLs — Defence Layers

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

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.

SG vs NACL

Level → SG: EC2/ENI | NACL: Subnet boundary

Stateful → SG: YES (reply auto OK) | NACL: NO (check every packet)

Rules → SG: Allow only | NACL: Allow + Deny

Default → SG: Deny all in, Allow all out | NACL: Default = Allow all

Can deny IPs → SG: NO | NACL: YES

Rule order → SG: All rules checked | NACL: Lowest number first

💡 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.

🧠 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

VPC Peering

VPC Peering Connection

"Jambatan terus antara dua VPC — non-transitive"

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.

💡 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.

🧠 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

Transit Gateway

AWS Transit Gateway

"Hub tengah yang connect semua VPCs — gantikan peering mesh"

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.

💡 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.

🧠 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

VPC Endpoints

VPC Endpoints (Gateway & Interface)

"Highway terus ke AWS services — tanpa internet, tanpa NAT fees"

Apa Dia

Dua jenis: Gateway Endpoint (S3 + DynamoDB, free, guna route table) dan Interface Endpoint (services lain via PrivateLink, ada ENI dalam subnet, berbayar). Traffic tak keluar ke internet langsung — lebih selamat dan murah (jimat NAT GW data fees).

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.

💡 Exam Scenario

"Access S3/DynamoDB dari private subnet tanpa internet" → Gateway VPC Endpoint (free). "Access ECR, SSM, atau services lain privately" → Interface Endpoint (PrivateLink).

🧠 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

Guna Bila

Access S3/DynamoDB (free) atau AWS services lain (paid) dari private subnet secara private

VPC endpointGateway endpointInterface endpointPrivateLinkS3DynamoDBno internetfree

📎 VPC Endpoints 📎 Gateway Endpoints

DOMAIN 2 · 26% OF EXAM

Design Resilient Architectures

High Availability · Disaster Recovery · Backup & Storage Resilience

⚡High Availability & Scaling↑ Top

Auto Scaling Groups

Amazon EC2 Auto Scaling

"Auto tambah/kurang server ikut demand"

Apa Dia

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

💡 Exam Scenario

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

🧠 Cara Mudah Ingat

→Termination Policies — menentukan instance MANA yang ditamatkan semasa scale in:
→OldestLaunchTemplate → terminate instances guna launch template LAMA (guna ni untuk rolling AMI updates — pastikan instances lama diganti dengan yang baru)
→OldestInstance → terminate instance yang PALING LAMA berjalan (bukan template, tapi instance age)
→ClosestToNextInstanceHour → terminate instance yang paling dekat dengan next billing hour (optimise kos)
→AllocationStrategy → untuk Spot instances, terminate berdasarkan allocation strategy
→Default policy: OldestLaunchConfiguration → OldestInstance → ClosestToNextInstanceHour
→Exam: "phase out old AMI, replace with new" → OldestLaunchTemplate termination policy

Guna Bila

Automatically scale EC2 instances based on load

horizontal scalingscale out/inlaunch templatescaling policiesdesired capacitymin/maxOldestLaunchTemplatetermination policyAMI rollout

RDS Multi-AZ

Amazon RDS Multi-AZ Deployment

"Backup database sedia tunggu dalam AZ lain"

Apa Dia

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

💡 Exam Scenario

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

🧠 Cara Mudah Ingat

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

Guna Bila

High availability for RDS — automatic failover

automatic failoverstandbydifferent AZsync replicationsame endpointHA onlyautomated backupsmanual snapshotpoint-in-time restoreretention period

RDS Read Replicas

Amazon RDS Read Replicas

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

Apa Dia

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

Contoh Guna

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

💡 Exam Scenario

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

🧠 Cara Mudah Ingat

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

Guna Bila

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

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

📎 RDS Read Replicas

RDS Proxy

Amazon RDS Proxy

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

Apa Dia

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

💡 Exam Scenario

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

🧠 Cara Mudah Ingat

→RDS Proxy solves: "too many connections", "idle connections", "connection exhaustion"
→Bukan untuk slow query performance — guna Read Replicas atau upgrade instance untuk query scaling
→Bukan untuk read scaling — guna Read Replicas untuk distribute read load
→Sangat berguna dengan Lambda (yang scale drastically dan close/open connections rapidly)
→Supports IAM authentication + Secrets Manager integration untuk credentials

Guna Bila

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

connection poolingtoo many connectionsLambda scalingidle connectionsconnection multiplexing

Global Accelerator

AWS Global Accelerator

"Highway AWS untuk user seluruh dunia"

Apa Dia

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

💡 Exam Scenario

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

🧠 Cara Mudah Ingat

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

Guna Bila

Route global users to nearest healthy endpoint via AWS backbone

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

Aurora

Amazon Aurora

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

Apa Dia

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

Contoh Guna

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

💡 Exam Scenario

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

🧠 Cara Mudah Ingat

→Aurora = 6 copies across 3 AZs auto. RDS Multi-AZ = 1 standby copy sahaja
→Aurora failover <30 saat. RDS Multi-AZ failover 1-2 minit
→Aurora storage auto-grow hingga 256 TiB — zero storage management
→Storage scaling: start 10 GiB, auto-grow dalam 10 GiB increments hingga max (128-256 TiB ikut engine version) — ni SAMA untuk Aurora provisioned dan Aurora Serverless. Jangan keliru dengan Serverless v2 COMPUTE capacity range (0.5-256 ACU)
→Aurora Global Database: primary region + up to 5 read-only secondary regions
→Aurora Global Database RTO: < 1 minit (automatic managed failover). RPO: ~1 saat (replication lag)
→Aurora Global Database failover: secondary region promote jadi primary automatically bila primary region down — minimal manual effort
→Exam: "cross-region DR, downtime < 1 minit, minimal manual ops" → Aurora Global Database. Bukan Multi-AZ (same region). Bukan manual snapshot restore (kena buat sendiri)
→Multi-AZ Aurora Replicas = same region HA (failover dalam AZ, bukan region)

Guna Bila

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

MySQL compatiblePostgreSQL compatible6 copies3 AZsauto storage 256 TiBfast failover15 read replicasGlobal Databasecross-region DRRTO 1 minRPO 1s

📎 What is Amazon Aurora?

Aurora Serverless

Amazon Aurora Serverless

"Database yang tidur bila tak pakai, scale sendiri"

Apa Dia

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

💡 Exam Scenario

"Dev/test database hanya pakai waktu office hours", "app traffic sangat unpredictable, nak zero DB cost masa idle" → Aurora Serverless. Keywords: intermittent, variable traffic, dev/test, scale to zero.

🧠 Cara Mudah Ingat

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

Guna Bila

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

scale to zeroACUpay per secondintermittentdev/testauto-pausevariable trafficv1 vs v20.5 ACU incrementsno connection drops

📎 Using Aurora serverless (v2)

DynamoDB

Amazon DynamoDB

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

Apa Dia

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

Contoh Guna

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

💡 Exam Scenario

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

🧠 Cara Mudah Ingat

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

Guna Bila

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

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

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

DAX

Amazon DynamoDB Accelerator (DAX)

"Cache depan DynamoDB — baca dalam microseconds"

Apa Dia

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

💡 Exam Scenario

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

🧠 Cara Mudah Ingat

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

Guna Bila

Read-heavy DynamoDB workloads needing microsecond response times

DynamoDB Acceleratormicrosecond latencyin-memory cacheread cachingdrop-in compatible

🔄Disaster Recovery Patterns↑ Top

Backup & Restore

DR Pattern: Backup & Restore

"Save game — kalau rosak restore dari backup"

Apa Dia

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

💡 Exam Scenario

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

Guna Bila

Non-critical systems, lowest cost DR strategy

RPO: hours/daysRTO: hourslowest costno standby infraS3/Glacier backup

Pilot Light

DR Pattern: Pilot Light

"Api kecil sedia — boleh bakar besar bila perlu"

Apa Dia

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

💡 Exam Scenario

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

Guna Bila

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

RPO: minutesRTO: minutes-hourscore DB runningapp servers offmedium cost

Warm Standby

DR Pattern: Warm Standby

"Anak syarikat kecil sedia — scale up masa emergency"

Apa Dia

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

💡 Exam Scenario

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

Guna Bila

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

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

Multi-Site Active/Active

DR Pattern: Multi-Site Active/Active

"Dua HQ berjalan serentak — saling backup"

Apa Dia

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

💡 Exam Scenario

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

Guna Bila

Mission-critical — full capacity in both regions simultaneously

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

🗂️Backup & Storage Resilience↑ Top

AWS Backup

"Backup manager untuk semua AWS services"

Apa Dia

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

💡 Exam Scenario

Company kena comply dengan policy backup 90-hari untuk semua databases — AWS Backup create backup plan, auto backup RDS + DynamoDB + EFS setiap hari, retain 90 hari, auto copy ke DR region.

🧠 Cara Mudah Ingat

→AWS Backup supports: EFS, EBS, RDS, Aurora, DynamoDB, S3, FSx, EC2 AMIs, Storage Gateway volumes
→"centralized backup management + monitoring + auditing reporting" → AWS Backup (every time)
→Backup Audit Manager: compliance framework + reporting for audit — "prove backups meet policy" → Backup Audit Manager
→S3 File Gateway ≠ EFS backup. FSx File Gateway ≠ EFS backup. For EFS backup → AWS Backup.

Guna Bila

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

centralized backupbackup plansretentioncross-regioncomplianceautomatedEFS backupBackup Audit Managermonitoring

S3 Versioning & CRR

S3 Versioning + Cross-Region Replication

"Simpan semua versi, auto copy ke region lain"

Apa Dia

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

💡 Exam Scenario

Developer accidentally delete important file dalam S3 — Versioning enable restore previous version. CRR auto-copy semua objects ke DR bucket kat region lain untuk disaster recovery.

Guna Bila

Protect against accidental deletion, cross-region DR for S3

versioningCRRaccidental deletioncross-region replicationSRRpoint-in-time recovery

EBS Snapshots

Amazon EBS Snapshots

"Gambar volume pada satu masa — restore anytime"

Apa Dia

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

💡 Exam Scenario

EC2 kena ransomware, OS corrupted — restore EBS dari snapshot semalam. Atau copy snapshot ke region lain untuk DR, create new EC2 dari snapshot tu.

Guna Bila

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

incremental backuppoint-in-timecross-AZcross-region copyEC2 recovery

FSx

Amazon FSx

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

Apa Dia

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

💡 Exam Scenario

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

🧠 Cara Mudah Ingat

→FSx for Lustre: natively integrates with S3 via Data Repository Associations (DRA) — objects lazily imported from S3, processed files can be exported back to S3
→FSx for Lustre + DataSync: DataSync supports FSx for Lustre as a transfer location — use for scheduled bulk transfers to/from FSx Lustre
→Exam: "POSIX + S3 integration + high throughput" → FSx for Lustre (not EFS). EFS is general-purpose NFS, no S3 native integration
→FSx for Windows: Single-AZ or Multi-AZ deployments; SSD or HDD storage; SMB/NTFS NOT POSIX
→FSx for Windows access: supports cross-VPC/account/region via VPC Peering or Transit Gateway; on-premises via Direct Connect or VPN
→DRA = Data Repository Association: links FSx Lustre file system to an S3 bucket for automatic import/export

Guna Bila

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

Windows SMBNTFSActive DirectoryLustre HPCNetApp ONTAPOpenZFSmanaged file systemS3 integrationDRADataSyncmulti-AZsingle-AZPOSIX

Storage Gateway

AWS Storage Gateway

"Jambatan antara on-premises apps dan AWS storage"

Apa Dia

Tiga jenis: File Gateway (NFS/SMB → S3), Volume Gateway (iSCSI block storage → EBS snapshots), Tape Gateway (virtual tape library → S3 Glacier). On-premises apps tak perlu tahu depa sebenarnya guna cloud storage.

💡 Exam Scenario

"On-premises apps nak access S3 via NFS" → File Gateway. "Replace physical tape library dengan cloud backup" → Tape Gateway. "Ongoing hybrid access" → Storage Gateway. Bukan DataSync (yang untuk one-time migration).

Guna Bila

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

hybrid storageFile GatewayVolume GatewayTape Gatewayon-premisesNFSSMBiSCSI

DataSync

AWS DataSync

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

Apa Dia

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

💡 Exam Scenario

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

🧠 Cara Mudah Ingat

→DataSync juga handle EFS → EFS cross-region replication (bukan setakat on-prem ke AWS sahaja)
→EFS cross-region via DataSync: transfer melalui AWS private network (bukan public internet) — secure by default
→Bukan Snowball untuk cross-region EFS (Snowball = physical device, untuk migration, bukan replication)
→Bukan VPN/open-source tools (lebih complex, kena manage sendiri)
→Exam: "replicate EFS data between regions securely without public internet" → AWS DataSync

Guna Bila

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

data migrationautomated transferS3EFSFSxNFSSMBHDFSone-time migrationEFS cross-regionprivate networkno public internet

DMS

AWS Database Migration Service

"Pindah database ke AWS tanpa downtime"

Apa Dia

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

💡 Exam Scenario

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

Guna Bila

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

database migrationminimal downtimehomogeneousheterogeneousSchema Conversion ToolCDCreplication

Snow Family

AWS Snow Family

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

Apa Dia

Physical devices: Snowcone (8TB, smallest, edge compute), Snowball Edge (80TB, compute + storage), Snowmobile (100PB, truck untuk exabyte). Encrypt data, hantar ke AWS, AWS load ke S3.

💡 Exam Scenario

"Transfer 100TB data tapi internet ambil berbulan-bulan atau bandwidth mahal" → Snow Family. Rule of thumb: >1 week via internet → consider Snowball. Exabyte-scale → Snowmobile (literally a truck).

Guna Bila

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

SnowconeSnowball EdgeSnowmobilephysical transferpetabyteedge computingoffline migration

🚚Migration & Transfer↑ Top

Transfer Family

AWS Transfer Family

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

Apa Dia

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

💡 Exam Scenario

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

🧠 Cara Mudah Ingat

→Protocols supported: SFTP (SSH), FTPS (TLS), FTP (plain, dalam VPC je), AS2 (B2B EDI)
→Backend storage: S3 atau EFS. Files appear as normal S3 objects atau EFS files
→Exam keyword: "SFTP", "FTP", "legacy file transfer", "partner file exchange", "no code change" → Transfer Family
→Bukan DataSync (DataSync = automated scheduled migration. Transfer Family = ongoing SFTP endpoint for users/partners)
→Bukan Storage Gateway (Storage Gateway = hybrid storage access. Transfer Family = file transfer protocol endpoint)
→Identity providers: Service managed, Active Directory, custom Lambda-based

Guna Bila

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

SFTPFTPFTPSAS2S3 backendEFS backendmanaged FTPlegacy protocolB2B file transferno code change

AWS MGN

AWS Application Migration Service (MGN)

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

Apa Dia

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

🧠 Cara Mudah Ingat

→MGN = server migration (OS + apps + data). DMS = database migration only. DataSync = file/object data transfer
→Application Discovery Service = discovery/planning phase bukan migration
→Exam: "migrate entire server/application to EC2 with minimal downtime" → AWS MGN
→Supports: physical servers, VMware, Hyper-V, cloud instances → EC2

Guna Bila

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

MGNlift-and-shiftserver migrationEC2 migrationblock replicationminimal downtime

AWS Outposts

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

Apa Dia

AWS Outposts adalah physical rack AWS yang dihantar dan dipasang dalam data center kau. Kau boleh run EC2, RDS, ECS, EKS, S3 on Outposts — semua dengan AWS APIs yang sama. Data tak keluar dari premise kau.

🧠 Cara Mudah Ingat

→Outposts = AWS infrastructure ON-PREMISES — bukan data transfer service
→Use case: regulatory compliance (data must stay on-prem), low-latency access to on-prem systems, local data processing
→Bukan DataSync (data transfer), bukan Storage Gateway (hybrid storage only), bukan Snow Family (one-time migration)
→Exam: "database must stay on-premises due to compliance, extend AWS services to on-prem" → AWS Outposts
→Outposts connect ke AWS region melalui internet atau Direct Connect untuk management plane

Apa Dia

Mengurus dan menjalankan Docker containers pada cluster

Contoh Guna

Run microservices dalam Docker, e-commerce modules

🧠 Cara Mudah Ingat

→Task Definition = JSON template yang describe containers untuk application (image, CPU, memory, ports, env vars, volumes)
→Task Definition BUKAN: IAM template, bukan service yang launch clusters, bukan program yang run — ia BLUEPRINT untuk containers
→ECS Launch Types: Fargate (serverless, AWS manage infrastructure) vs EC2 (kau manage EC2 cluster)
→Task = running instance of a Task Definition. Service = maintain desired number of running tasks
→Exam: "best describes a task definition" → JSON template that describes containers that form your application

Guna Bila

Run containers

Dockercontainersmicroservicestask definitionJSON templateFargateEC2 launch typeservice

EKS

Elastic Kubernetes Service

"Kubernetes manager"

Apa Dia

Mengurus Kubernetes cluster untuk container orchestration

Contoh Guna

Large-scale containerized apps yang guna K8s

🧠 Cara Mudah Ingat

→IRSA (IAM Roles for Service Accounts): pods assume IAM roles via service account annotation — no credentials stored anywhere
→Best practice for EKS pods to access AWS services (Secrets Manager, S3, DynamoDB) without embedding credentials
→ConfigMaps = non-sensitive config data. NOT for secrets. Kubernetes Secrets + IRSA = proper pattern
→Exam: "EKS pods need access to Secrets Manager without credentials in container image" → IRSA + Kubernetes Secrets

Guna Bila

Container orchestration guna K8s

KubernetesK8scontainer orchestrationIRSAIAM Roles for Service Accountspod identity

EKS Variants

EKS Anywhere vs EKS Distro vs ECS Anywhere

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

Apa Dia

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

Variants

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

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

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

🧠 Cara Mudah Ingat

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

Guna Bila

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

EKS AnywhereEKS DistroECS Anywhereon-premises Kuberneteshybrid containers

EC2 User Data

EC2 User Data Scripts

"Script masa launch"

Apa Dia

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

Contoh Guna

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

💡 Exam Scenario

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

Guna Bila

Auto-configure EC2 instance on first boot

bootstraplaunch scriptcloud-initfirst bootinitialization16KB limit

EC2 Hibernation

Amazon EC2 Hibernation

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

Apa Dia

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

🧠 Cara Mudah Ingat

→Hibernation saves RAM to EBS root volume (must be encrypted)
→Resume time = sangat cepat vs cold start (no app re-initialization)
→Use case: memory-intensive apps yang ambil masa lama nak load (e.g. in-memory cache warm-up)
→Not all instance types support hibernation. Root EBS volume MESTI encrypted
→Exam: "preserve in-memory state + fast recovery" → EC2 Hibernation. Bukan AMI (AMI = snapshot, no RAM state)

Guna Bila

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

hibernationRAM saveEBS rootfast resumein-memory stateencrypted root volume

EC2 Metadata

EC2 Instance Metadata Service (IMDS)

"ID kad instance sendiri"

Apa Dia

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

Contoh Guna

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

💡 Exam Scenario

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

Guna Bila

Get info about the running instance from within the instance

169.254.169.254instance infoIMDSv2hostnameIP addressIAM role name

Recycle Bin

AWS Recycle Bin (AMI & EBS Snapshots)

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

Apa Dia

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

🧠 Cara Mudah Ingat

→Recycle Bin = safety net untuk accidental AMI/EBS snapshot deletion
→Retention period: 1 day to 1 year. Set via Retention Rule dalam Recycle Bin console
→Exam: "prevent permanent loss of accidentally deleted AMIs" → Recycle Bin
→CloudFormation StackSets tidak boleh recover deleted AMIs — ia untuk multi-account/region deployment

Guna Bila

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

Recycle BinAMI recoveryEBS snapshot recoveryaccidental deletionretention period

AWS Batch

"Managed batch jobs — tak payah manage EC2 fleet sendiri"

Apa Dia

AWS Batch menguruskan semua infrastruktur untuk batch jobs: provision compute resources yang sesuai, schedule jobs dalam queues, monitor dan scale EC2 fleet secara automatik. Menggantikan third-party batch software seperti PBS, Slurm, LSF.

💡 Exam Scenario

"Company guna third-party software untuk manage EC2 fleet untuk batch jobs, nak switch ke AWS managed service" → AWS Batch.

🧠 Cara Mudah Ingat

→Batch = untuk jobs yang run sampai habis (start-to-finish), bukan continuous workloads
→AWS Batch auto-provision EC2 (termasuk Spot untuk jimat kos)
→Ingat: Batch ≠ SSM (SSM = manage existing infra). Batch ≠ Athena (Athena = query S3 data)

Guna Bila

Run batch computing jobs at scale without managing EC2 infrastructure

AWS Batchbatch computingmanagedjob queueEC2 fleetreplace third-party

📎 AWS Batch

Fargate

AWS Fargate

"ECS/EKS tanpa urus EC2 — serverless containers"

Apa Dia

Fargate adalah serverless compute engine untuk ECS dan EKS. Kau define CPU/memory per task, Fargate provision dan manage compute automatically. Bayar per vCPU/memory per second.

💡 Exam Scenario

"Run containers without managing EC2 instances" → Fargate. ECS on EC2 = kau manage EC2 (patching, scaling). ECS/EKS on Fargate = AWS manage compute. Fargate lagi mahal tapi zero infra management.

Guna Bila

Run containers without managing any EC2 server infrastructure

serverless containersECSEKSno EC2 managementpay per vCPU/memoryzero infra

ECR

Amazon Elastic Container Registry

"Docker Hub tapi dalam AWS, private"

Apa Dia

Fully managed private container registry. Integrated dengan IAM untuk access control. Images boleh di-scan secara automatik untuk vulnerabilities. Native integration dengan ECS, EKS, dan Fargate.

💡 Exam Scenario

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

Guna Bila

Store, version, and deploy Docker container images privately in AWS

container registryDocker imagesprivate registryIAM integrationvulnerability scanningECSEKS

💾Storage↑ Top

EBS

Elastic Block Store

"Hard disk untuk EC2"

Apa Dia

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

Contoh Guna

OS drive untuk EC2, database storage

🧠 Cara Mudah Ingat

→Instance store vs EBS: Instance store = ephemeral (data HILANG bila stop/terminate). EBS = persistent (data kekal)
→Instance store volumes BOLEH ditentukan HANYA masa launch — tak boleh tambah lepas instance running
→EBS encryption: encrypts at rest AND in transit (between volume and instance). ALL current AND previous gen instance types supported.
→EBS Elastic Volumes: resize, retype, adjust IOPS/throughput TANPA detach atau downtime. Lepas resize, extend filesystem: growpart + resize2fs (Linux)
→"Volume running out of space, minimal config changes" → increase EBS volume size (Elastic Volumes). Bukan snapshot+new volume (extra steps).
→Unencrypted snapshot → encrypted volume: BOLEH. Pilih encrypt semasa create volume dari snapshot. Tak perlu enable account-level default encryption.

Guna Bila

Block storage, attach ke 1 EC2

block storagesingle EC2persistent diskinstance storeephemeralElastic Volumesresizeencryptiondata in transit

EBS Volume Types

Amazon EBS — Volume Types & Multi-Attach

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

Apa Dia

EBS ada 4 jenis: SSD-backed (gp2, gp3, io1, io2) untuk IOPS-intensive, HDD-backed (st1, sc1) untuk throughput-intensive sequential.

EBS Types

gp3 → General Purpose SSD. Up to 16,000 IOPS, 1,000 MB/s throughput independently configurable. Default choice.

gp2 → Older General Purpose. Burst IOPS (3 IOPS/GB). Less predictable under sustained load

io2 → Provisioned IOPS SSD. Up to 64,000 IOPS. 99.999% durability. Supports Multi-Attach

io1 → Older Provisioned IOPS. Up to 64,000 IOPS. Supports Multi-Attach

st1 → Throughput-Optimized HDD. Sequential workloads: log processing, ETL, big data. NOT for random I/O

sc1 → Cold HDD. Lowest cost. Infrequently accessed data

🧠 Cara Mudah Ingat

→Multi-Attach: HANYA io1 dan io2 — attach satu EBS ke multiple EC2 instances simultaneously
→gp2, gp3, st1, sc1 TIDAK support Multi-Attach
→Exam: "shared block storage across multiple EC2 nodes (EKS)" → io2 with Multi-Attach. "Truly shared file storage" → EFS
→Database needing consistent IOPS under sustained load → gp3 (cheaper) atau io2 (mission-critical)
→Large sequential writes (log processing) → st1 (bukan gp3 atau io2 — they are random I/O optimized)
→Pattern: "database + log processing on same EC2" → io2 or gp3 for DB, st1 for logs

Guna Bila

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

gp3io2st1sc1Multi-AttachProvisioned IOPSthroughput HDDEBS types

EFS

Elastic File System

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

Apa Dia

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

Contoh Guna

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

💡 Exam Scenario

Multi-EC2 shared storage → EFS. Single-instance persistent block storage → EBS. Object storage (images, backups) → S3.

🧠 Cara Mudah Ingat

→Performance modes (set at creation): General Purpose = lowest latency, recommended for MOST workloads including web serving. Max I/O = HIGHER latency (not lower!), for massive parallel HPC workloads with 100s of connections.
→Throughput modes (can change): Bursting = scales with storage size (50 KiB/s per GiB baseline — 25 GB file system gets only ~1.25 MiB/s). Provisioned = set specific MiB/s regardless of file system size. Elastic (recommended) = auto-scales, pay per use.
→Trap: "small EFS + high throughput demand" → Provisioned Throughput. "large file system + occasional access" → Bursting is fine.
→Encryption in transit: NOT enabled by default. Enable at MOUNT TIME with EFS mount helper: sudo mount -t efs -o tls fs-xxxx /mnt/efs. Uses TLS 1.2 + AES-256. No console toggle.
→Encryption at rest: can enable at CREATION time only. Uses KMS. Encrypts data + metadata + directory names.
→Cross-VPC access: create NEW mount targets in VPC B (same file system, no data duplication). Alternatively via VPC peering but need to use mount target IP instead of DNS name.
→Connection timeout to EFS mount target = check: (1) SG inbound TCP 2049 from EC2 CIDR, (2) NACL allows TCP 2049. DNS failure → different error (not timeout).
→EFS backup: use AWS Backup natively. S3 File Gateway ≠ EFS backup.
→Storage classes: Standard (multi-AZ), Standard-IA (infrequent access), One Zone, One Zone-IA (cheapest — data in single AZ).

Guna Bila

Shared file storage for multiple EC2 instances simultaneously

shared storagemultiple EC2NFSGeneral PurposeMax I/OProvisioned ThroughputBursting ThroughputElastic ThroughputTLS 1.2mount helper-o tlsTCP 2049cross-VPC EFSEFS mount target

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

S3

Simple Storage Service

"Infinite storage bucket"

Apa Dia

Menyimpan dan mendapatkan semula sebarang jumlah data sebagai objects

Contoh Guna

Store images, videos, backups, static website hosting

Guna Bila

Object storage, images, backups

object storagestatic websitebackupunlimited

S3 Glacier

Amazon S3 Glacier

"S3 yang sejuk beku"

Apa Dia

Menyediakan arkib data jangka panjang dengan kos yang rendah

Contoh Guna

Store old financial records, compliance archives, log archives

Guna Bila

Archiving, jarang access

archivinglong-term storageinfrequent accesscold storage

🌐Networking & Delivery↑ Top

CloudFront

Amazon CloudFront

"CDN, content laju sampai"

Apa Dia

Menghantar content kepada pengguna melalui edge locations global dengan latency rendah

Contoh Guna

Deliver images & videos untuk global users, static website laju

🧠 Cara Mudah Ingat

→OAC (Origin Access Control) = GANTI OAI. Wajib guna OAC untuk S3 origins yang guna SSE-KMS. OAI tidak support KMS. Update bucket policy grant s3:GetObject kepada CloudFront service principal.
→Lambda@Edge = run Lambda functions AT CloudFront edge nodes. 4 hooks: Viewer Request, Viewer Response, Origin Request, Origin Response. "Custom auth headers / transform request before origin" → Lambda@Edge
→Lambda@Edge vs CloudFront Functions: CF Functions = ultra-fast, lightweight JS at viewer level. Lambda@Edge = full Node.js/Python, longer timeout, can call AWS services, runs at origin/viewer events.
→"Serve private S3 objects via CloudFront securely" → OAC + bucket policy. Keep bucket block public access = ON.

Guna Bila

Deliver content laju via edge locations

CDNedge locationlow latencystatic contentOACOrigin Access ControlLambda@EdgeSSE-KMSprivate S3

ALB

Application Load Balancer

"Traffic director — by path/host, Layer 7"

Apa Dia

Mengagihkan traffic HTTP/HTTPS berdasarkan path atau host rules (Layer 7). Boleh route ke instances dalam peered VPCs menggunakan IP address sebagai target — bukan hanya dalam satu VPC.

Contoh Guna

myshop.com/products → service A, myshop.com/cart → service B. Cross-VPC: route ke EC2 instances dalam peered VPCs guna IP targets.

💡 Exam Scenario

Cross-VPC load balancing: company ada 3 VPCs peered. Guna satu ALB dengan IP address targets untuk route ke instances dalam semua 3 VPCs. Classic Load Balancer (CLB) tak boleh buat ni — CLB hanya support instance ID targets dalam same VPC.

🧠 Cara Mudah Ingat

→ALB = Layer 7 (HTTP/HTTPS). NLB = Layer 4 (TCP/UDP). CLB = legacy, avoid
→IP targets membolehkan ALB/NLB route ke peered VPCs, on-premises (via Direct Connect/VPN)
→CLB limitation: instance ID only, same VPC only — exam trap!
→SNI (Server Name Indication): ALB HTTPS listener boleh hold MULTIPLE TLS certificates serentak. Client sends hostname in TLS ClientHello → ALB picks the right cert. No extra ALB needed per domain!
→"two domains, same ALB, each with its own ACM cert, no combined cert" → Add both certs to ALB listener using SNI

Guna Bila

HTTP/HTTPS path-based routing, microservices, containers

path-based routingHTTPlayer 7IP targetscross-VPCmicroservices

📎 ALB IP Targets 📎 ALB User Guide

NLB

Network Load Balancer

"Traffic director — ultra laju, Layer 4, static IP"

Apa Dia

Mengagihkan traffic TCP/UDP pada Layer 4 dengan latency sangat rendah. Seperti ALB, NLB juga boleh route ke instances dalam peered VPCs menggunakan IP address targets.

Contoh Guna

Gaming servers, IoT, VoIP. Cross-VPC: NLB dengan IP targets route ke instances dalam peered VPCs.

💡 Exam Scenario

NLB diperlukan bila: (1) perlukan static IP atau Elastic IP untuk load balancer, (2) TCP/UDP traffic bukan HTTP, (3) extreme performance/low latency. Untuk cross-VPC dengan IP targets, both NLB dan ALB boleh digunakan.

🧠 Cara Mudah Ingat

→NLB = static IP/Elastic IP support. ALB = tiada static IP (guna static IP alias CloudFront/Global Accelerator)
→NLB dan ALB BOLEH route cross-VPC via IP targets. CLB TIDAK boleh
→NLB preserve client IP address. ALB tidak (guna X-Forwarded-For header)

Guna Bila

TCP/UDP, low latency, static IP, cross-VPC with IP targets

TCPUDPlayer 4static IPIP targetscross-VPClow latency

📎 NLB User Guide

Route 53

Amazon Route 53

"GPS untuk domain"

Apa Dia

Mengurus DNS dan mengarahkan traffic kepada endpoint yang betul

Contoh Guna

Point domain ke server, failover ke backup region

🧠 Cara Mudah Ingat

→Alias record: AWS-specific DNS extension. Boleh guna untuk APEX/root domain (e.g. example.com). Points ke ALB, CloudFront, S3 website, other Route 53 records
→CNAME record: standard DNS. TIDAK BOLEH guna untuk apex/root domain (DNS spec prohibition)
→Pattern: apex domain (example.com) → ALWAYS use Alias. Subdomain (www.example.com) → CNAME or Alias both work
→Exam: "root domain + www subdomain pointing to ALB" → Alias for root + CNAME (or Alias) for www

Guna Bila

DNS management, domain routing

DNSdomainrouting policyfailoverAlias recordCNAMEapex domainroot domaincannot CNAME apex

Route 53 Routing Policies

Amazon Route 53 — Routing Policies

"Cara Route 53 decide siapa dapat traffic"

Apa Dia

Pelbagai routing policies untuk optimize availability, performance, failover, dan geolocation berdasarkan health checks dan rules

Routing Policies

Simple → 1 resource, no health check, no failover

Weighted → split traffic by % (A=70%, B=30%)

Latency-based → route to lowest latency AWS region

Failover → primary (active) + secondary (passive) via health check

Geolocation → route by user's country/continent

Geoproximity → route by geographic distance + bias

Multi-Value → up to 8 healthy records, random selection

💡 Exam Scenario

ALB (primary) unhealthy → Route 53 Failover policy auto-redirect ke S3 static error page (secondary). Health check detect ALB down, traffic pindah ke secondary automatik. BUKAN CloudFront — CF cache content tapi tak handle active-passive failover.

🧠 Cara Mudah Ingat

→Hybrid failover (AWS primary + on-premises secondary): PERLU DUA alias records berasingan
→Record 1 (Primary): Alias ke ALB/CloudFront, Evaluate Target Health = Yes — Route 53 check health automatically
→Record 2 (Secondary): Alias ke on-premises IP/endpoint, associate Route 53 health check explicitly
→Evaluate Target Health (ETH): untuk AWS resources yang support alias (ALB, ELB, CloudFront) — Route 53 check health target automatically TANPA perlu attach health check
→On-premises / non-alias resources: MESTI attach health check explicitly — ETH tak apply
→Exam: "AWS primary + on-premises secondary failover" → 2 failover alias records, AWS dengan ETH=Yes, on-premises dengan explicit health check

Guna Bila

Control how DNS traffic is routed to resources

failoveractive-passivehealth checkweightedlatency-basedgeolocationsimpleEvaluate Target Healthhybrid failovertwo alias recordson-premises secondary

📨Messaging & Serverless↑ Top

SQS

Simple Queue Service

"Baris gilir message"

Apa Dia

Mengurus queue untuk menghantar mesej antara komponen aplikasi secara asynchronous. Standard queue: at-least-once delivery, best-effort ordering. FIFO queue: exactly-once, strict order.

Contoh Guna

Order processing queue — EC2/Lambda poll SQS, proses order, delete message bila siap.

SQS Key Concepts

Visibility Timeout → Message invisible semasa diproses (max 12 jam). Jika consumer mati sebelum siap → message visible semula selepas timeout

Delay Seconds → Delay sebelum message pertama kali visible dalam queue (max 15 minit)

Dead Letter Queue (DLQ) → Message yang gagal diproses N kali dihantar ke DLQ untuk debug

Message Retention → Default 4 hari, max 14 hari

💡 Exam Scenario

Spot instance terminated masa process SQS message → message TIDAK hilang. Ia akan visible semula selepas Visibility Timeout expired. Message hanya deleted bila consumer call DeleteMessage API selepas berjaya process.

🧠 Cara Mudah Ingat

→Cross-account SQS access: guna SQS RESOURCE-BASED policy (queue policy) pada queue — bukan IAM policy dalam source account
→IAM policy dalam target account SAHAJA tidak cukup untuk cross-account SQS access. Queue policy mesti explicitly allow source account principal
→Exam: "allow another AWS account to send messages to SQS queue" → SQS queue policy (resource-based)
→Long Polling (ReceiveMessageWaitTimeSeconds > 0, max 20s): consumer WAITS for message before returning. Reduces empty responses + API call costs. Short polling = returns immediately even if empty.
→Visibility Timeout: message hidden from OTHER consumers after retrieved. If processing takes longer than timeout → message becomes visible again → DUPLICATE processing. Fix: increase timeout to exceed max processing time, or use ChangeMessageVisibility mid-processing.
→Duplicate messages: Standard queue = at-least-once delivery (can duplicate). FIFO queue = exactly-once delivery with deduplication. Switch to FIFO to eliminate duplicates with minimal code change.
→Batch operations: ReceiveMessage gets up to 10 messages per call; DeleteMessageBatch deletes up to 10 per call. Use batching to reduce API call count and costs.
→SNS→SQS→Lambda pattern: add SQS queue between SNS and Lambda for reliable async processing. If Lambda fails transiently, message waits in SQS and is retried — no message loss, no manual intervention.
→SQS FIFO + Lambda: message ordering within MessageGroupId guaranteed. Requires event source mapping (ESM) to connect Lambda to FIFO queue.

Guna Bila

Decouple services, async queue

queuedecoupleasyncpull-basedvisibility timeoutFIFODLQat-least-onceexactly-oncelong pollingshort pollingbatch operationsduplicate messagesqueue policycross-account SQSresource-based policySNS SQS Lambda fan-out

SNS

Simple Notification Service

"Broadcast message"

Apa Dia

Menghantar notifikasi kepada pelbagai subscribers secara serentak

Contoh Guna

Alert ramai users sekaligus, trigger multiple Lambda functions

Guna Bila

Push notification ke many subscribers

pub/subpush notificationfan-outbroadcast

Kinesis

Amazon Kinesis

"SQS tapi real-time streaming"

Apa Dia

Memproses dan menganalisis data streaming secara real-time

Contoh Guna

Real-time analytics, live dashboard, clickstream data

Guna Bila

Real-time data streaming & analytics

real-timestreamingdata pipelineanalytics

API Gateway

Amazon API Gateway

"Pintu masuk untuk API"

Apa Dia

Mencipta, mengurus dan mendedahkan API pada mana-mana skala

Contoh Guna

Frontend → API Gateway → Lambda → DynamoDB

🧠 Cara Mudah Ingat

→Mapping Templates: transform request/response format antara client dan backend — untuk backward compatibility
→Guna mapping templates bila legacy clients expect format lama tapi backend dah upgrade. Transform response tanpa modify backend code
→Mapping templates guna Velocity Template Language (VTL). Boleh reshape JSON, rename fields, tambah/buang fields
→Method Response Models: define schema untuk response (documentation/validation) — BUKAN untuk transform format
→Gateway Response: customize error responses (4xx, 5xx) dari API Gateway itself — bukan dari backend
→Exam: "backend upgrade broke legacy clients due to response format change, fix without modifying backend" → Mapping Templates
→API Gateway Caching: cache method responses at the stage level. Cache key boleh INCLUDE query string parameters — different param values → different cache entries (e.g. ?type=equity vs ?type=fixed-income cached separately)
→"Two product categories, same API, cache must not share entries" → include query param in cache key
→Integration types: HTTP (public internet), Lambda (same or cross-account), VPC Link (private VPC resources via NLB/ALB)
→CORS: enable on API Gateway untuk allow browser cross-origin requests. REST APIs: OPTIONS preflight handler auto-created.

Guna Bila

Manage & expose REST/WebSocket APIs

REST APIWebSocketAPI managementthrottlingmapping templatesbackward compatibilityVTLresponse transformationcache keyCORSVPC Linkcross-account Lambda

EventBridge

Amazon EventBridge

"Trafik light untuk events — route events ke tempat betul"

Apa Dia

EventBridge route events dari sources (EC2 state change, S3 upload, custom apps, SaaS) ke targets (Lambda, SQS, SNS, Step Functions) berdasarkan rules. Gantikan CloudWatch Events. Boleh schedule events (cron/rate).

Contoh Guna

EC2 instance terminate → EventBridge rule detect → trigger Lambda untuk cleanup. Atau schedule Lambda setiap hari pukul 9pm.

💡 Exam Scenario

"EC2 instance stop → trigger Lambda automatically" → EventBridge rule. "Schedule Lambda every day at midnight" → EventBridge Scheduler. Bukan SNS (yang untuk broadcast notifications, bukan event routing).

Guna Bila

Serverless event bus: decouple services, schedule tasks, react to AWS service changes

event busevent-drivencron schedulerule-based routingdecoupleSaaS integrationCloudWatch Events

Step Functions

AWS Step Functions

"Flowchart yang run sendiri — orchestrate multi-step workflows"

Apa Dia

Visual workflow orchestration. Setiap step boleh timeout, retry, atau branch ikut result. Integrate dengan Lambda, ECS, Glue, DynamoDB, dan 200+ services. State machine dengan JSON definition.

💡 Exam Scenario

"Order processing: validate → charge card → notify warehouse → send email, dengan error handling pada setiap step" → Step Functions. Bukan Lambda je (Lambda tak ada built-in retry/branching logic across services).

🧠 Cara Mudah Ingat

→Distributed Map state: parallelizes processing over large datasets (e.g. chunk a text file and process each chunk concurrently) — key for PT5 text-to-speech pipeline question
→"Graphical/visual console to see each step's state" → Step Functions (not SQS, not SWF)
→SWF vs Step Functions: Step Functions is the modern replacement; SWF is legacy and lacks the visual console

Guna Bila

Coordinate multi-step processes with error handling, retry, and branching

workflowstate machineorchestrationretry logicerror handlingLambda orchestrationvisual workflowDistributed Mapparallel processing

Amazon MQ

"SQS tapi untuk apps lama yang guna ActiveMQ/RabbitMQ"

Apa Dia

Managed message broker service yang support ActiveMQ dan RabbitMQ. Guna AMQP, MQTT, STOMP, OpenWire protocols. Untuk lift-and-shift apps yang dah guna standard protocols.

💡 Exam Scenario

"Company ada on-premises app guna ActiveMQ, nak migrate ke AWS tanpa tukar code" → Amazon MQ. App baru? → guna SQS/SNS (simpler, cheaper, cloud-native). Amazon MQ = MIGRATION/LEGACY. SQS = cloud-native new apps.

Guna Bila

Migrate existing ActiveMQ/RabbitMQ message brokers to AWS without code changes

ActiveMQRabbitMQAMQPMQTTlift-and-shiftmessage brokerlegacy migrationopen protocols

Kinesis Data Firehose

Amazon Kinesis Data Firehose

"Paip streaming data terus ke S3/Redshift — no code needed"

Apa Dia

Fully managed delivery stream — tak perlu tulis consumer code. Buffer data sebelum write. Boleh transform inline dengan Lambda. Kinesis Data Streams = real-time processing (kena tulis consumer). Firehose = delivery/loading (no consumer needed).

💡 Exam Scenario

"Ingest clickstream data to S3 for analysis" → Kinesis Firehose (automatic, no consumer code). "Real-time fraud detection processing streaming events" → Kinesis Data Streams (more control, write consumer). Ingat perbezaan Streams vs Firehose!

Guna Bila

Capture and load streaming data to S3, Redshift, OpenSearch, Splunk automatically

delivery streamS3 deliveryRedshiftOpenSearchno consumer codebuffertransform with Lambda

AppFlow

AWS AppFlow

"Penyambung SaaS → AWS, tanpa code"

Apa Dia

Fully managed integration service dengan 50+ built-in SaaS connectors. Boleh transfer data bidirectionally antara SaaS platforms dan S3, Redshift, EventBridge. Support scheduling, field mapping, filtering, and data transformation.

💡 Exam Scenario

"Company guna Salesforce dan ServiceNow, nak sync data ke S3 untuk analytics tanpa custom code" → AppFlow. DataSync = file/storage migration (NFS, SMB, S3). Glue = ETL untuk structured data. AppFlow = SaaS API connectors.

🧠 Cara Mudah Ingat

→AppFlow vs DataSync: AppFlow = SaaS API integration (Salesforce, ServiceNow, Zendesk). DataSync = file protocol migration (NFS, SMB, HDFS, S3)
→AppFlow vs Glue: AppFlow = no-code, event-triggered SaaS sync. Glue = code-based ETL (PySpark/Python), for data lakes
→"automate transfer between SaaS app and S3 with no custom development" → AppFlow (every time)

Guna Bila

Automated no-code data transfer between SaaS apps (Salesforce, ServiceNow, Slack) and AWS services

AppFlowSaaS integrationSalesforceServiceNowno-code connectordata transferbidirectionalS3Redshift

🏗️Infrastructure↑ Top

CloudFormation

AWS CloudFormation

"Blueprint untuk AWS resources"

Apa Dia

Mengurus dan menyediakan infrastruktur AWS secara automatik menggunakan template (IaC)

Contoh Guna

Deploy EC2 + S3 + RDS sekaligus dari satu template YAML/JSON, replicate environment dev/staging/prod

🧠 Cara Mudah Ingat

→Lambda-backed Custom Resources: guna Lambda untuk perform logic masa CloudFormation create/update/delete — contoh: lookup AMI ID dynamically
→AMI IDs berbeza tiap region + instance type → Lambda custom resource query SSM Parameter Store atau EC2 API untuk get correct AMI ID masa stack creation
→Tanpa custom resource: kena maintain separate template per region (manual overhead). Dengan custom resource: satu template, Lambda inject AMI ID automatik
→Custom resource flow: CFN trigger Lambda → Lambda query API → return value → CFN inject ke template
→Bukan SNS/SQS untuk AMI lookup — SNS = notifications, SQS = queuing, bukan dynamic lookup
→Exam: "single CloudFormation template for multiple regions, auto-select correct AMI ID" → Lambda-backed custom resource
→Mappings: static key-value lookup tables dalam template (e.g. region → AMI ID). Tak perlu user input, hardcoded dalam template
→Outputs: export values dari stack untuk cross-stack reference. Consuming stack guna Fn::ImportValue untuk import
→Parameters: user input masa stack launch (dynamic). Conditions: conditional resource creation berdasarkan parameter values
→EXAM KEY: "region-specific AMI selection" → Mappings. "Share values between stacks" → Outputs + ImportValue. "User chooses env" → Parameters
→cfn-init: reads AWS::CloudFormation::Init metadata + install packages/files/services — PRIMARY bootstrap script
→cfn-signal: hantar SUCCESS/FAILURE signal ke CloudFormation (untuk WaitCondition/CreationPolicy)
→cfn-hup: daemon yang detect metadata changes dan re-run cfn-init bila stack update
→cfn-get-metadata: retrieve metadata SAHAJA — tidak install apa-apa
→Exam: "read metadata and install packages on EC2 launch" → cfn-init
→Change set: PREVIEW perubahan (resources akan create/update/delete) SEBELUM execute — tak terus apply. Best practice: always review change set before updating production stack
→Drift detection: detect bila resource dalam stack diubah MANUALLY (outside CloudFormation, e.g. via console) — stack jadi "DRIFTED" dari template. Tak auto-fix, just detect & report
→Stack update failure → automatic ROLLBACK ke previous working state (default behaviour)
→Stack deletion: resources dengan DeletionPolicy: Retain akan KEKAL walaupun stack dipadam — guna untuk data store (RDS, S3) yang tak nak accidentally lenyap
→Exam: "preview changes before applying" → Change Sets. "Detect manual console changes to stack resources" → Drift Detection
→Nested Stacks: stack yang dipanggil dari dalam stack lain (parent stack) menggunakan AWS::CloudFormation::Stack resource type. Guna bila template dah terlalu besar atau ada reusable components (e.g. network layer, security layer yang dipakai oleh banyak stacks).
→Nested Stacks benefit: modularization — separate VPC stack, app stack, DB stack. Parent orchestrate semua. Setiap nested stack diupdate/rolledback independently.
→Exam: "reuse common infrastructure components (VPC, subnets) across multiple CloudFormation stacks" → Nested Stacks. "Share VPC ID between stacks" → Outputs + ImportValue (cross-stack ref).

Guna Bila

Automate infrastructure deployment, consistent environment

IaCInfrastructure as Codetemplatestackrollbackrepeatable deploymentLambda-backed custom resourceAMI lookupdynamic parametersmulti-region templateMappingsOutputscross-stack referenceFn::ImportValuecfn-initcfn-signalcfn-hupcfn-get-metadatachange setdrift detectionstack rollbackDeletionPolicynested stacksAWS::CloudFormation::Stackmodular templates

SSM

AWS Systems Manager

"Remote control untuk EC2 fleet"

Apa Dia

Suite alat untuk visibility dan kawalan ke atas infrastruktur AWS. Run Command jalankan commands pada existing instances tanpa SSH. Patch Manager automate OS patching. Parameter Store simpan config/secrets.

Contoh Guna

Perlu patch 500 EC2 instances serentak — SSM Patch Manager buat semua tanpa perlu SSH satu-satu. Run Command untuk restart service pada semua app servers.

💡 Exam Scenario

"Manage existing instances remotely, run commands without SSH, patch fleet at scale" → SSM Run Command. Bukan User Data (User Data hanya masa launch sahaja).

🧠 Cara Mudah Ingat

→SSM Run Command: jalankan commands pada EC2 instances AT SCALE tanpa SSH. Requirement: SSM Agent installed + instance profile ada AmazonSSMManagedInstanceCore policy
→SSM Agent dah pre-installed pada Amazon Linux 2 dan Windows Server. Custom AMI mungkin perlu install sendiri
→Run Command vs Session Manager: Run Command = execute scripts/commands (non-interactive, good for patch/config). Session Manager = interactive browser-based shell — NO port 22, NO bastion host needed
→Session Manager audit: semua session commands logged ke S3 and/or CloudWatch Logs, dan session start/end dicatat dalam CloudTrail. Fully traceable, no SSH keys to manage.
→Parameter Store (free tier): Standard parameters = up to 10,000 params, free, no expiration. Advanced parameters = higher limits + parameter policies (expiration, notification via EventBridge).
→Parameter Store SecureString: encrypt value dengan KMS key (default aws/ssm atau custom CMK). Guna untuk passwords, API keys — retrieved via SSM API, plaintext only bila caller ada KMS decrypt permission.
→Parameter Store vs Secrets Manager: Parameter Store = cheaper (free for standard), no auto-rotation. Secrets Manager = automatic rotation (supports RDS, Redshift, DocumentDB natively), cross-account access, costs ~$0.40/secret/month.
→Exam: "update 100 EC2 instances in parallel, no SSH allowed" → SSM Run Command. "Interactive shell access without opening port 22" → Session Manager. "Store DB password, auto-rotate every 30 days" → Secrets Manager (not Parameter Store).
→Exam: "store config values and DB passwords centrally, no rotation needed, minimize cost" → Parameter Store SecureString.

Guna Bila

Manage, patch, and run commands on EC2 instances at scale

Run CommandPatch ManagerParameter StoreSession Managerno SSHfleet managementparallel executionAmazonSSMManagedInstanceCoreSecureStringKMSStandard tierAdvanced tierbastion-freeSecrets Managerauto-rotation

AWS Config

"Audit & track apa yang berubah"

Apa Dia

Memantau dan merekod konfigurasi AWS resources dari masa ke masa. Boleh set rules untuk enforce compliance — contoh: "semua S3 mesti ada encryption". Bukan untuk run scripts.

Contoh Guna

Security team nak tau siapa yang ubah Security Group semalam dan bila — AWS Config simpan history semua config changes.

💡 Exam Scenario

"Audit config changes, check compliance, who changed what and when" → AWS Config. Keyword: configuration changes, compliance, audit trail, resource history.

🧠 Cara Mudah Ingat

→Config Rules: managed rules (AWS pre-built) atau custom rules (Lambda). Evaluate resources against rules continuously or on change. Non-compliant = flagged, boleh trigger remediation.
→Auto-remediation: link Config rule ke SSM Automation document. E.g. rule "S3-bucket-public-read-prohibited" violated → auto remediation revoke public access. Tak perlu manual fix.
→Conformance Packs: kumpulan Config rules + remediation actions dalam satu package (YAML). Boleh deploy ke seluruh Org via StackSets. Use cases: CIS AWS Foundations, NIST, PCI DSS compliance bundles.
→Config vs CloudTrail: Config = WHAT IS THE CURRENT/PAST STATE of resource config? CloudTrail = WHO CALLED WHAT API WHEN? Dua tool berbeza, sering digunakan bersama.
→Config vs CloudWatch: Config = resource config history & compliance. CloudWatch = performance metrics & alarms. Config tidak monitor CPU — CloudWatch yang buat.
→Config perlu IAM role dengan permissions untuk describe/record resources. Enable per-region — bukan global service (tapi boleh aggregate ke multi-account, multi-region Config aggregator).
→Exam: "ensure all EC2 instances are tagged" atau "enforce all S3 buckets encrypted" + "auto-fix violations" → Config rules + auto-remediation (bukan Lambda alone, bukan CloudTrail).
→Config Aggregator: view Config data across multiple accounts & regions dari satu central account — senang untuk compliance reporting org-wide.

Guna Bila

Track configuration changes and compliance of AWS resources

complianceauditconfig changesconfig rulesresource historydrift detectionauto-remediationconformance packsConfig aggregatorSSM Automationmanaged rulescustom rules

CodeCommit

AWS CodeCommit

"GitHub tapi dalam AWS"

Apa Dia

Managed source control service — store, version, dan collaborate on code securely dalam AWS. Integrate terus dengan IAM untuk access control, dan native dengan CodePipeline/CodeBuild.

Contoh Guna

Dev team simpan code dalam CodeCommit → setiap push trigger CodePipeline automatically.

💡 Exam Scenario

"Source control dalam AWS", "private Git repository", "version control integrated dengan IAM" → CodeCommit.

Guna Bila

Private Git repository dalam AWS ecosystem

Gitsource controlversion controlprivate repoIAM integration

CI/CD Pipeline

CodeCommit → CodeBuild → CodeDeploy → CodePipeline

"4 Code services = full DevOps pipeline"

Apa Dia

Suite 4 perkhidmatan: CodeCommit (store code) → CodeBuild (compile + test) → CodeDeploy (deploy ke EC2/Lambda/ECS) → CodePipeline (orchestrate semua steps automatically bila ada code push).

Contoh Guna

Developer push ke CodeCommit → CodePipeline detect → CodeBuild run tests → CodeDeploy push ke production EC2 — semua automatik.

CI/CD Suite

CodeCommit → Store & version control source code (Git)

CodeBuild → Compile, test, produce build artifacts

CodeDeploy → Deploy ke EC2, Lambda, ECS, on-premises

CodePipeline → Orchestrate & automate the full pipeline

💡 Exam Scenario

Soalan sebut "automate deployment", "CI/CD pipeline in AWS", "deploy code automatically on push" → CodePipeline sebagai orchestrator utama.

Guna Bila

Automate build, test, and deploy pipeline end-to-end

CI/CDCodePipelineCodeBuildCodeDeployDevOpsautomationpipeline

CloudWatch

Amazon CloudWatch

"Dashboard, logs, dan alarm untuk semua dalam AWS"

Apa Dia

CloudWatch Metrics (CPU, network, custom app metrics). CloudWatch Logs (Lambda logs, EC2 app logs, VPC Flow Logs — set retention). CloudWatch Alarms (trigger SNS/Auto Scaling bila threshold exceeded). Dashboards untuk visualize.

Contoh Guna

EC2 CPU >80% → CloudWatch Alarm → SNS notification ke team. Lambda error logs → CloudWatch Logs untuk debug.

💡 Exam Scenario

"CPU EC2 melebihi 80%, send alert" → CloudWatch Alarm. "View logs dari Lambda" → CloudWatch Logs. "Custom app metric" → CloudWatch custom metrics. CloudWatch = METRICS & LOGS. CloudTrail = API AUDIT. Ingat perbezaan!

🧠 Cara Mudah Ingat

→Default EC2 metrics (CPU, network, disk I/O, status checks) = "host-level" metrics dari hypervisor — tak perlu install apa-apa
→EC2 MEMORY usage dan DISK SPACE usage = BUKAN default metric — kena install CloudWatch agent untuk collect ni
→Unified CloudWatch Agent (current): satu agent untuk metrics (termasuk memory/disk) + logs + traces (X-Ray), support Linux & Windows, boleh push custom metrics via StatsD/collectd
→CloudWatch Logs Agent (deprecated/legacy): logs-only, Linux-only — AWS recommend migrate ke unified agent
→Exam: "collect EC2 memory utilization metric" → install/configure (unified) CloudWatch agent. Default monitoring TAK CUKUP.
→Standard monitoring = every 5 min (free). Detailed monitoring = every 1 min (additional cost)
→CloudWatch Logs Insights: interactive query language (SQL-like) untuk search dan analyze log data in CloudWatch Logs. Boleh query across multiple Log Groups. Guna untuk: "find all ERROR logs in last 1 hour from Lambda", "count request counts by status code". Bukan Athena (Athena untuk S3 data).
→Exam: "query and analyze CloudWatch Logs with an interactive query interface" → CloudWatch Logs Insights. "Analyze logs stored in S3" → Athena.

Guna Bila

Monitor metrics, collect logs, set alarms, create dashboards for AWS resources

metricslogsalarmsdashboardsCPU monitoringcustom metricsLog GroupsVPC Flow LogsCloudWatch agentunified agentmemory utilizationdetailed monitoringLogs Insightsquery logsSQL-like

X-Ray

AWS X-Ray

"GPS untuk trace request melalui microservices"

Apa Dia

X-Ray trace setiap request dari masuk (API Gateway) hingga keluar (DynamoDB), nampak berapa lama setiap component ambil masa. Service map visual tunjuk bottleneck. Works dengan Lambda, EC2, ECS, API Gateway.

💡 Exam Scenario

"API lambat, tak tahu kat mana bottleneck dalam 10 microservices" → X-Ray service map. Trace request dari API Gateway → Lambda → DynamoDB dan nampak mana paling slow. Keywords: distributed tracing, latency, microservices debugging.

🧠 Cara Mudah Ingat

→X-Ray traces message paths end-to-end melalui SQS, Lambda, API Gateway — identify bottlenecks atau missing messages
→CloudTrail = WHO DID WHAT (API audit). CloudWatch = metrics/alarms. X-Ray = WHY IS IT SLOW / WHERE IS IT FAILING (distributed trace)
→Exam: "debug message not reaching destination through SQS distributed system" → X-Ray (not CloudWatch, not CloudTrail)
→X-Ray Insights: automatically detects anomalies (error/latency spikes) in your X-Ray data and sends notifications via SNS/EventBridge — answers "automatic anomaly detection with notifications" requirement
→"graphical end-to-end visibility" + "anomaly notifications" → X-Ray + X-Ray Insights

Guna Bila

Distributed tracing — debug latency and errors across microservices and serverless

distributed tracingservice maplatency analysismicroservicesLambda tracingbottleneckdebuggingSQS tracingend-to-end tracebottleneck detectionX-Ray Insightsanomaly detection

AWS Health Dashboard

"Status AWS untuk AKAUN KAU sendiri, bukan global"

Apa Dia

Dua bahagian: (1) Service Health Dashboard — overall AWS service status (public, semua org boleh tengok). (2) AWS Health Dashboard (account-specific) — personalized view of operational issues, scheduled maintenance/changes, dan event yang affect resources dalam account kau.

💡 Exam Scenario

"AWS region kau experiencing issue — adakah resources SAYA affected?" → AWS Health Dashboard (account view), bukan general Service Health page. Boleh integrate dengan EventBridge untuk auto-notify (e.g. Lambda → Slack) bila ada event affecting your resources.

🧠 Cara Mudah Ingat

→Service Health Dashboard = general AWS-wide status (public). AWS Health Dashboard = PERSONALIZED, account-specific events/scheduled changes affecting YOUR resources
→Boleh route AWS Health events ke EventBridge → Lambda/SNS untuk automated alerting (e.g. notify team bila ada scheduled EC2 retirement)
→Full AWS Health API access requires Business atau Enterprise Support plan
→Beza dengan Trusted Advisor: Trusted Advisor = proactive recommendations (cost/security/perf checks). AWS Health = reactive/scheduled — notifies about actual AWS-side EVENTS affecting your resources (outages, maintenance, deprecations)

Guna Bila

See AWS service issues and scheduled changes that affect YOUR specific account/resources

service healthpersonal health dashboardscheduled changesaccount eventsEventBridgeoperational issuesmaintenance notification

📎 What is AWS Health?

🗄️Databases↑ Top

DocumentDB

Amazon DocumentDB

"MongoDB dalam AWS — JSON documents"

Apa Dia

Fully managed document database yang compatible dengan MongoDB APIs. Store data sebagai JSON documents dalam collections. Auto-scale storage hingga 64TB.

💡 Exam Scenario

"Migrate MongoDB to AWS managed service" → DocumentDB. NOT Neptune (graph). NOT DynamoDB (key-value). DocumentDB = DOCUMENT/MONGODB. Keywords: JSON, semi-structured data, MongoDB compatible, collections.

Guna Bila

JSON document store, MongoDB-compatible workloads migrate to AWS

MongoDB compatibledocument storeJSONcollectionsNoSQLMongoDB migration

Neptune

Amazon Neptune

"Database untuk connections antara data — graph"

Apa Dia

Fully managed graph database. Optimized untuk traverse relationships dalam data. Support Gremlin (property graph) dan SPARQL (RDF). Highly connected datasets.

💡 Exam Scenario

"Social network: cari semua mutual friends antara dua users" → Neptune (graph query efficient). "Fraud detection: cari pattern dalam linked transactions" → Neptune. Bukan DynamoDB (key-value) atau RDS (relational tabular). Keywords: graph, relationships, connected data.

Guna Bila

Social networks, fraud detection, knowledge graphs, recommendation engines

graph databasesocial networkfraud detectionGremlinSPARQLrelationshipsknowledge graph

Keyspaces

Amazon Keyspaces

"Cassandra dalam AWS — wide column, IoT, time-series"

Apa Dia

Fully managed Cassandra-compatible database. Guna CQL (Cassandra Query Language) yang sama. Serverless — auto-scale, pay per request. High write throughput.

💡 Exam Scenario

"Migrate Apache Cassandra to fully managed AWS service" → Amazon Keyspaces. Same CQL queries, no server management. Atau IoT telemetry data yang perlu high write throughput. Keywords: Cassandra, CQL, wide column.

Guna Bila

Migrate Apache Cassandra workloads, IoT telemetry, time-series data

Cassandra compatibleCQLwide columnIoT telemetrytime-serieshigh write throughput

📊Analytics & Streaming↑ Top

QuickSight

Amazon QuickSight

"BI dashboard AWS — kau drag-drop, dia visualize"

Apa Dia

Serverless BI service. Connect directly to S3, RDS, Redshift, Athena, or other sources. Build dashboards and visualizations. ML Insights feature includes anomaly detection, forecasting (seasonality, trends), and auto-narratives — no separate ML infrastructure needed.

💡 Exam Scenario

"Executive dashboards dari IoT data dalam S3 dengan forecasting, no data warehouse" → QuickSight + S3 direct. QuickSight bukan untuk ad-hoc SQL (→ Athena), bukan untuk ETL (→ Glue). Keywords: dashboard, forecast, trend, BI, visualization.

🧠 Cara Mudah Ingat

→QuickSight connects directly to S3 — no need to load into Redshift first for dashboard use cases
→ML Insights = built-in forecasting dan anomaly detection — "usage trends + forecasting" → QuickSight ML Insights
→SPICE = QuickSight in-memory engine untuk fast queries on imported data
→Exam trap: "dashboards + forecasting, minimal ops" → QuickSight (not Redshift + custom ML)

Guna Bila

Business intelligence dashboards, data visualization, ML-powered analytics

QuickSightBIdashboardforecastingML InsightsvisualizationS3 directSPICEIoT analytics

Athena

Amazon Athena

"SQL terus pada S3 — serverless, bayar per TB scan"

Apa Dia

Serverless interactive query service. Point ke S3, tulis SQL, dapat results. Bayar per TB data yang di-scan. Sokong CSV, JSON, Parquet, ORC. Pair dengan Glue Data Catalog sebagai metadata store.

💡 Exam Scenario

"Analyse CloudTrail logs atau ALB access logs dalam S3 guna SQL" → Athena. "Ad-hoc analysis tanpa setup database" → Athena. Bukan Redshift (yang untuk structured, recurring analytics dengan dedicated cluster).

Guna Bila

Ad-hoc SQL analysis of data in S3 without loading to a database

serverless SQLS3 queriespay per scanParquetORCGlue Cataloglog analysisad-hoc

Glue

AWS Glue

"Penyambung data — ETL serverless dan data catalog"

Apa Dia

Glue Data Catalog = metadata store untuk semua data assets (S3, RDS, Redshift). Glue ETL = serverless Spark jobs untuk transform data. Glue Crawler = auto-discover dan catalog schema dari S3/databases.

💡 Exam Scenario

"Transform raw CSV dalam S3 ke Parquet format untuk Athena" → Glue ETL job. "Auto-catalog all data sources for data lake" → Glue Crawler + Data Catalog. Keywords: ETL, data lake, data catalog, transform, Spark.

🧠 Cara Mudah Ingat

→Glue Crawler specifically = the component that connects to a data source, infers schema, and POPULATES the Glue Data Catalog with table metadata
→Exam pattern: "determine schema from DynamoDB/S3 and populate Glue Data Catalog" → Crawler (not a Table, not a Classifier)
→Glue Classifier helps the Crawler recognize custom data formats — but Crawler is the orchestrator that calls Classifiers

Guna Bila

ETL jobs, data catalog for data lake, prepare and transform data for analytics

ETLdata catalogSparkserverlesscrawlerdata laketransformParquetschema discoveryDynamoDBschema inference

Lake Formation

AWS Lake Formation

"Lapisan keselamatan atas S3/Glue — row, column, cell level access"

Apa Dia

Lake Formation duduk atas S3 + Glue Data Catalog dan enforce fine-grained permissions. Glue Data Catalog je hanya ada table/column metadata — Lake Formation enforce ACTUAL access control hingga row, column, dan cell level.

🧠 Cara Mudah Ingat

→Glue Data Catalog = metadata store (what data exists). Lake Formation = access control (who can access what data)
→Lake Formation supports row-level, column-level, dan cell-level security — Glue je tak boleh buat ni
→Use case: data lake dengan sensitive data, analysts boleh access hanya specific columns/rows
→Exam: "fine-grained access control" atau "row/column/cell-level security" untuk data lake → Lake Formation
→Lake Formation juga support data cleansing, data catalog, secure data sharing — one-stop data lake governance

Guna Bila

Fine-grained access control on data lake: row-level, column-level, cell-level security

Lake Formationrow-level securitycolumn-levelcell-levelfine-grained accessdata lakeGlue Data Catalog

EMR

Amazon EMR

"Hadoop/Spark cluster untuk big data — kau control cluster"

Apa Dia

Managed cluster platform untuk big data frameworks. Kau choose cluster size, instance types, frameworks. Spot instances untuk cost saving. Lebih control dari Glue — untuk complex custom jobs.

💡 Exam Scenario

"Process petabytes of log data using custom Spark jobs" → EMR. "Machine learning training on large datasets" → EMR. Glue = serverless ETL (simpler, less control). EMR = full cluster (more control, more complex). Keywords: Hadoop, Spark, big data cluster.

Guna Bila

Process petabyte-scale data with Spark, Hadoop, Hive, Presto — full control

HadoopSparkHivePrestobig dataclusterpetabytemanagedSpot instances

OpenSearch

Amazon OpenSearch Service

"Enjin carian dan log analytics — Elasticsearch dalam AWS"

Apa Dia

Managed OpenSearch (Elasticsearch fork) cluster. Ingestion via Kinesis Firehose atau Lambda. Visualise dengan OpenSearch Dashboards (Kibana). Guna untuk search yang perlu ranking, fuzzy matching, atau aggregations.

💡 Exam Scenario

"E-commerce product search dengan fuzzy matching" → OpenSearch. "Ingest dan search application logs real-time dengan visualisation" → OpenSearch. DynamoDB = exact key lookups. OpenSearch = full-text search. Keywords: search engine, log analytics, Elasticsearch.

Guna Bila

Full-text search, real-time log/event analytics, dashboard visualisation

search enginelog analyticsElasticsearch compatibleKibanareal-time analyticsfull-text searchfuzzy

MSK

Amazon MSK

"Kafka dalam AWS — managed, tak payah urus brokers"

Apa Dia

Fully managed Apache Kafka service. AWS manage brokers, ZooKeeper, patching. Kau guna Kafka Producer/Consumer API yang sama. Cross-AZ untuk HA.

💡 Exam Scenario

"Migrate on-premises Apache Kafka cluster ke AWS" → Amazon MSK. Atau streaming pipeline yang perlu Kafka API compatibility. Kinesis = AWS-native proprietary. MSK = Kafka-compatible (for migration or Kafka expertise teams).

🧠 Cara Mudah Ingat

→MSK is managed BUT does NOT provide SSH/direct access to Kafka brokers — AWS manages the underlying infrastructure.
→Lambda + MSK integration REQUIRES configuring an Event Source Mapping (ESM) — Lambda does not automatically pick up MSK events.
→MSK Auto Scaling: automatically expands broker storage based on utilization threshold. MSK Serverless: auto-scales compute AND storage, no broker capacity management.
→MSK is NOT multi-cloud — AWS-only service. Does NOT span other cloud providers.
→Kinesis vs MSK: Kinesis = AWS-native, simpler, no Kafka expertise needed. MSK = Kafka API compatible, for teams with Kafka expertise or migrating existing Kafka workloads.

Guna Bila

Real-time event streaming dengan Kafka API — migrate or build Kafka workloads

Kafkamanagedstreamingevent streamingmigrationKafka APIreal-time pipelinebrokersno SSHevent source mappingMSK Serverlessauto scaling storage

Kendra

Amazon Kendra

"Google-like ML search for your enterprise documents"

Apa Dia

ML-powered enterprise search. Indexes PDFs, Word docs, HTML, emails, FAQs across S3, SharePoint, Confluence, databases. Understands natural language queries to return precise answers, not just keyword matches.

💡 Exam Scenario

"Enterprise wants to search across internal docs, FAQs, emails, PDFs with natural language queries" → Kendra. "E-commerce product search with spell-check/synonyms" → OpenSearch (keyword search engine). Kendra = understanding context + intent. OpenSearch = scalable keyword/full-text search.

🧠 Cara Mudah Ingat

→Kendra vs OpenSearch: Kendra = ML semantic search for enterprise "find the answer" use cases. OpenSearch = scalable keyword full-text search for high-volume queries (e-commerce, log analytics).
→Kendra natively handles FAQs — can provide direct question-answer responses from FAQ documents.
→Kendra indexes unstructured content: PDFs, Word, PowerPoint, HTML, emails, wikis.

Guna Bila

Intelligent enterprise search across diverse document repositories

Kendraenterprise searchML searchsemantic searchnatural language queryFAQsunstructured documentsintelligent search

Data Exchange

AWS Data Exchange

"AWS marketplace untuk beli/subscribe third-party data"

Apa Dia

Marketplace for external data products. Providers publish datasets (market data, financial data, regulatory filings, weather, etc.). Subscribers browse, subscribe, data delivered directly to S3. Handles licensing and subscription management automatically.

💡 Exam Scenario

"Company wants to subscribe to market data, economic indicators, and regulatory filings from third-party providers and deliver them to their AWS accounts for analytics" → AWS Data Exchange. Kinesis = your own real-time data. Data Exchange = external third-party data products.

Guna Bila

Subscribe to and access third-party datasets for analytics

Data Exchangethird-party datadata marketplacedata subscriptionmarket datafinancial datadata productsS3 deliverylicensing

AWS AI/ML Services

AWS AI Services — Polly, Rekognition, Lex, Comprehend, Textract, Transcribe, Translate

"Polly = cakap. Transcribe = dengar. Lex = faham + balas. Rekognition = nampak. Comprehend = baca. Textract = scan dokumen. Translate = tukar bahasa"

Apa Dia

AWS menyediakan pelbagai AI services ready-to-use: speech, vision, NLP, document processing.

AI Services Comparison

Amazon Polly → Text-to-Speech (TTS): convert text jadi audio (natural voice)

Amazon Transcribe → Speech-to-Text (STT): convert audio/video jadi text

Amazon Lex → Conversational chatbot: NLU + ASR, maintains context, integrates Lambda (powers Alexa)

Amazon Rekognition → Image/Video analysis: face detection, object/scene detection, labels

Amazon Comprehend → NLP: sentiment analysis, entities, key phrases, language detection

Amazon Textract → Document OCR: extract text, forms, tables from PDFs/images

Amazon Translate → Neural machine translation: convert text between languages, real-time + batch

Kinesis Video Streams → Ingest, store, process video/audio streams (for Rekognition real-time analysis)

🧠 Cara Mudah Ingat

→Polly = text → speech. Transcribe = speech → text. INGAT: P=produce speech, T=transcribe speech
→Lex = chatbot dengan context awareness. Kalau soalan sebut "chatbot", "natural language", "conversation turns" → Lex
→Rekognition + Kinesis VIDEO Streams = real-time video analysis (e.g. CCTV face mask detection, surveillance cameras)
→Rekognition + Kinesis DATA Streams = SALAH untuk video. Data Streams untuk text/structured records
→Textract vs Comprehend: Textract = extract text FROM documents (OCR, forms, tables). Comprehend = analyze/understand text content (sentiment, entities)
→Exam shortcut: "read quiz questions aloud" → Polly. "CCTV face detection" → Rekognition + Kinesis Video Streams. "Chatbot" → Lex
→Polly StartSpeechSynthesisTask = async TTS: starts a long synthesis job and writes audio directly to S3 (use for large text files; SynthesizeSpeech is synchronous/streaming only)
→"scanned PDFs → audiobook" = Textract (extract text) + Polly (text → audio)
→Kinesis Video Streams = INGESTION layer (secure ingest from cameras/devices). Rekognition Video = ANALYSIS layer. You need both for a real-time surveillance pipeline.
→Comprehend = NLP text ANALYSIS (sentiment, entities, key phrases, topic modeling). Use for support tickets, social media, reviews. NOT for document OCR (use Textract) and NOT for chatbots (use Lex).
→Textract = EXTRACT structured data from scanned documents. Key-value pairs from forms, data from tables, dates and amounts from invoices/contracts. Goes beyond basic OCR.
→Lex = CONVERSATIONAL chatbot with multi-turn dialogue, intent recognition, slot filling. Powers Amazon Alexa. Manages conversation state.
→Enterprise search across PDFs/Word/email with natural language? → Amazon Kendra (see Kendra card). Product search with spell-check/synonyms? → OpenSearch.
→Translate = neural machine translation (text → text, different language). NOT speech (combine with Transcribe/Polly for audio) dan NOT sentiment analysis (use Comprehend)
→"Multilingual chatbot/support ticket pipeline": Transcribe (speech→text) → Translate (translate text) → Comprehend (analyze sentiment) → Polly (text→speech in target language)

Guna Bila

AI/ML services untuk audio, video, text, image analysis without training models

PollyTranscribeLexRekognitionComprehendTextractTranslateKinesis Video Streamstext-to-speechspeech-to-textchatbotimage analysisStartSpeechSynthesisTaskaudiobookOCRNLPsentiment analysisentity recognitiondocument extractionmachine translation

SageMaker

Amazon SageMaker

"Custom ML end-to-end — train, tune, deploy your own models"

Apa Dia

End-to-end managed ML platform: data prep (Data Wrangler, Feature Store), training (built-in algorithms, custom code in any framework), AutoML (Autopilot), HPO, model registry, and deployment (real-time, serverless, batch, async endpoints). Supports CI/CD via SageMaker Pipelines.

💡 Exam Scenario

"Build a churn prediction model from historical data using custom Python code, tune hyperparameters, and deploy to a real-time endpoint" → SageMaker. Pre-built AI services (Polly, Lex, Rekognition, Comprehend) = no training needed, call the API. SageMaker = you control the model.

🧠 Cara Mudah Ingat

→SageMaker vs pre-built AI services: SageMaker = custom model training (your data, your algorithm). Rekognition/Polly/Lex/Comprehend = pre-trained, call API directly
→SageMaker Autopilot = AutoML: automatically tries different algorithms and hyperparameters, picks the best model
→"Train a custom model on company data" → SageMaker. "Detect faces in images" → Rekognition (no training needed)

Apa Dia

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

💡 Exam Scenario

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

🧠 Cara Mudah Ingat

→Compute Optimizer vs Trusted Advisor: Compute Optimizer = ML-based deep rightsizing untuk compute. Trusted Advisor = broader checks (cost, security, performance, service limits)
→Supported resources: EC2 instances, EC2 Auto Scaling Groups, EBS volumes, Lambda functions, ECS on Fargate
→Requires CloudWatch metrics — needs at least 14 days of usage data for recommendations
→Exam: "get ML-based rightsizing recommendations for EC2/Lambda" → Compute Optimizer. "General cost recommendations across many services" → Trusted Advisor

Guna Bila

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

rightsizingML recommendationsEC2 optimizationLambda optimizationcost savingsunderutilized

Trusted Advisor

AWS Trusted Advisor

"Penasihat jimat kos AWS"

Apa Dia

Menganalisis persekitaran AWS dan memberikan cadangan untuk optimasi kos, security, dan performance

💡 Exam Scenario

CFO tanya "mana resources kita yang membazir?" — Trusted Advisor akan highlight EC2 yang underutilized, S3 buckets tak pakai, Elastic IPs yang idle, dan bagi estimate savings.

🧠 Cara Mudah Ingat

→Lima kategori checks: Cost Optimization, Performance, Security, Fault Tolerance, Service Limits
→Free tier: 7 core checks. Business/Enterprise support: semua checks + API access
→Bukan Compute Optimizer (yang ML-based deep compute rightsizing). Trusted Advisor = broader, rule-based

Guna Bila

Identify idle resources, cost optimization recommendations

cost recommendationsidle resourcesrightsizingunderutilizedservice limitsfive categories

AWS Budgets

"Alarm sebelum spend cecah limit"

Apa Dia

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

💡 Exam Scenario

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

Guna Bila

Set cost/usage thresholds and get alerted before overspending

budget alertscost thresholdSNS notificationusage budgetforecast alertbefore overspend

Cost Explorer

AWS Cost Explorer

"Graf dan analisis spending AWS"

Apa Dia

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

💡 Exam Scenario

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

Guna Bila

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

cost analysisspending visualizationRI recommendationsusage patternsrightsizingforecasthourly granularity

💾Storage Cost Optimization↑ Top

S3 Storage Tiers

Amazon S3 Storage Classes

"Pilih tier ikut seberapa selalu kau access"

Apa Dia

Menyediakan pelbagai kelas storan dengan harga berbeza berdasarkan keperluan akses data

Storage Classes

S3 Standard → selalu access, harga tinggi

S3 Standard-IA → jarang access tapi kena cepat bila diperlukan

S3 One Zone-IA → same tapi 1 AZ je, lagi murah

S3 Glacier Instant → archive, retrieve dalam miliseconds

S3 Glacier Flexible → archive, retrieve dalam minit-jam

S3 Glacier Deep Archive → paling murah, retrieve 12-48 jam

💡 Exam Scenario

Log files yang baru = S3 Standard. Log files 30 hari lepas = S3-IA. Log files setahun lepas untuk compliance = S3 Glacier. Guna S3 Lifecycle Policy untuk auto-move between tiers.

🧠 Cara Mudah Ingat

→S3 Glacier Instant Retrieval: rarely accessed + millisecond retrieval. Medical/lab records yang perlu immediate access. Min 90-day storage
→S3 Glacier Deep Archive: CHEAPEST ($0.00099/GB). 12-hour retrieval. For 10-year compliance retention (genomics, legal). Min 180-day
→S3 One Zone-IA: SINGLE AZ only. For data yang boleh regenerated/reproduced. Cheaper than Standard-IA. Risk: AZ failure = data loss
→S3 Standard-IA: multi-AZ, infrequent access, ms retrieval. Min 30-day storage charge
→Pattern: "10-year retention, rarely accessed, petabytes" → S3 Glacier Deep Archive via lifecycle policy
→Pattern: "millisecond retrieval but rarely accessed" → S3 Glacier Instant Retrieval (not Flexible/Deep Archive)
→EFS One Zone-IA: cheapest EFS. Single AZ + infrequent access. Good when data can be regenerated

Guna Bila

Kurangkan kos storage ikut frequency of access

storage classeslifecycle policyinfrequent accessglacierGlacier Instant RetrievalGlacier Deep ArchiveOne Zone-IAmin storage charge

S3 Intelligent-Tiering

"AWS pilihkan tier yang paling murah secara auto"

Apa Dia

Memindahkan objek secara automatik antara access tiers berdasarkan corak penggunaan

💡 Exam Scenario

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

Guna Bila

Data dengan access pattern tak menentu

auto-tieringunpredictable accessno retrieval fees

🌐Networking Cost Optimization↑ Top

CloudFront

Amazon CloudFront

"CDN yang jimatkan data transfer cost"

Apa Dia

Mengurangkan kos data transfer dengan menyimpan cache content di edge locations

💡 Exam Scenario

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

Guna Bila

Reduce data transfer cost, cache content dekat user

reduce data transferedge cachingCDNcost saving

VPC Endpoints

AWS VPC Endpoints

"Jalan dalam rumah, tak payah keluar internet"

Apa Dia

Menghubungkan VPC kepada perkhidmatan AWS secara terus tanpa melalui internet awam

💡 Exam Scenario

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

Guna Bila

EC2 → S3/DynamoDB tanpa kena NAT Gateway fees

no NAT feesprivate connectionS3 gatewayno internet

🗄️Database Cost Optimization↑ Top

ElastiCache

Amazon ElastiCache

"Cache depan database, kurangkan DB load"

Apa Dia

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

💡 Exam Scenario

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

🧠 Cara Mudah Ingat

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

Guna Bila

Cache frequent queries, reduce RDS cost

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

📎 Caching strategies (lazy loading & write-through)

DynamoDB On-Demand

Amazon DynamoDB On-Demand

"Database bayar per request, zero urus capacity"

Apa Dia

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

💡 Exam Scenario

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

Well-Architected: Sustainability

"Kurangkan environmental impact — pillar ke-6 (2021)"

Apa Dia

Sustainability pillar (ditambah 2021) fokus pada reducing carbon footprint: maximise utilisation, use efficient hardware, minimise resources provisioned, adopt serverless/managed services.

🧠 Cara Mudah Ingat

→Pillar ke-6 — ramai ingat 5 pillars je. Sustainability ditambah pada November 2021
→Cara reduce: use serverless (Lambda, Fargate) — no idle servers. Use auto-scaling — no over-provisioning. Choose region dengan renewable energy
→Serverless = sustainability win: no idle compute, AWS manages utilization
→Exam: "reduce environmental impact, minimize carbon footprint" → Sustainability pillar strategies
→6 pillars: Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability

Guna Bila

Minimize environmental impacts of running cloud workloads

sustainabilitycarbon footprintenvironmental impact6th pillarserverlessutilisationrenewable energy2021

not in SAA-C03 exam

BONUS · NOT IN EXAM

Extra Tools & Open-Source

Bukan AWS native — tapi berguna untuk real-world. Tak keluar dalam SAA-C03.

🛠️Open-Source Database Tools↑ Top

Litestream

Litestream (SQLite Streaming Replication)

"SQLite backup ke S3 secara real-time — murah, mudah, auto"

Apa Dia

Litestream berjalan sebagai sidecar process sebelah app kau. Ia shadow-read SQLite WAL (Write-Ahead Log) dan stream setiap perubahan ke S3 secara real-time tanpa kena pause app. Bila server restart atau crash, Litestream restore snapshot + WAL terbaru dari S3 sebelum app start. Kos storage = S3 rate sahaja (~$0.023/GB). Tiada managed DB fee.

Contoh Guna

Deploy app di single EC2 atau fly.io dengan SQLite. Litestream stream WAL ke S3. Kalau instance crash, launch baru → Litestream restore dari S3 dalam beberapa saat → app up semula. Zero data loss.

💡 Exam Scenario

Bukan SAA-C03 exam content. Guna dalam real-world: small SaaS, indie apps, side projects yang nak avoid RDS cost ($50–300+/month) tapi masih nak reliable backup.

🧠 Cara Mudah Ingat

→SQLite MUST be in WAL mode: PRAGMA journal_mode=WAL
→Litestream mesti start SEBELUM app process
→Config dalam litestream.yml: dbs path + S3 bucket URL
→Boleh guna dengan fly.io, Railway, Render, Coolify, bare EC2
→Max practical DB size: ~10 GB sebelum SQLite mula slow

Guna Bila

Continuously replicate a SQLite database to S3 (or GCS / Azure Blob) for near-zero-cost backup and restore

SQLiteWALS3 replicationsidecaropen-sourcebackupnot AWS nativesingle servercheap DB

📎 litestream.io 📎 GitHub: benbjohnson/litestream