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

CloudFormation

AWS CloudFormation

"Blueprint untuk AWS resources"

🎯 Sebab Apa Wujud

CloudFormation wujud sebab buat infra manual (klik console satu-satu) = lambat, tak konsisten antara env (dev/prod), dan susah nak replicate atau rollback. CloudFormation = Infrastructure as Code: tulis template (YAML/JSON) sekali, deploy infra yang sama berulang kali, dan kalau gagal auto-rollback. Buang human error + 'works on dev tapi tak sama kat prod'. Ia FREE — bayar resource je.

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

CloudFormation = manual IKEA untuk infra (analogi)

Rendering diagram…

Macam manual IKEA: template sama → perabot sama setiap kali, takda silap manusia. INGAT exam: preview = Change Set; kesan ubah manual = Drift Detection; deploy multi-account/region = StackSets; kekalkan data masa delete = DeletionPolicy: Retain.

Pilih konsep operasi CFN — decision tree (yang mana aku guna?)

Rendering diagram…

Tiga "protect" yang selalu keliru: Stack Policy = lindung masa UPDATE · DeletionPolicy: Retain = kekalkan resource bila stack DELETE · Termination Protection = halang stack itu sendiri dari delete. INGAT exam: "multiple accounts/regions" → StackSets; "reusable/modular" → Nested Stacks; "preview" → Change Set; "manual change/drift" → Drift Detection.

CloudFormation vs Terraform vs Elastic Beanstalk

AspectCloudFormationTerraformElastic Beanstalk
JenisAWS-native IaCMulti-cloud IaC (HashiCorp)PaaS — deploy app, infra auto
SkopAWS resources sahajaAWS + GCP + Azure + dllApp platform (EC2/ASG/ELB auto)
BahasaYAML / JSON templateHCLTak tulis infra — push code je
StateManaged by AWStfstate file (kau urus sendiri)Managed by AWS
Keyword"AWS-only IaC, no extra cost""multi-cloud / satu tool semua""deploy web app cepat, jangan urus infra"

Ingat: AWS-only IaC + percuma → CloudFormation. Multi-cloud satu tool → Terraform. Deploy app tanpa fikir infra → Elastic Beanstalk (dia sebenarnya guna CloudFormation di bawah hood).

Template SECTIONS — 7 bahagian (apa kau TULIS dalam fail YAML/JSON)

SectionApa diaWajib?Exam keyword
ResourcesDefine resource nak dicipta (EC2/S3/VPC/RDS...)🔴 WAJIB — satu-satunya"the only required section"
ParametersInput DINAMIK masa launch (user pilih env/saiz)Optional"user chooses env / instance size"
MappingsLookup table STATIC (region → AMI ID)Optional"region-specific AMI / static lookup"
ConditionsCipta resource bersyarat (if prod → buat X)Optional"create only if / conditional logic"
OutputsEXPORT value keluar untuk stack lain importOptional"share between stacks → Fn::ImportValue"
MetadataInfo tambahan + config untuk cfn-initOptionaljarang keluar — kenal nama je
TransformGuna SAM (serverless) atau macrosOptional"serverless + CloudFormation → SAM/Transform"

Ingat: Resources = SATU-SATUNYA section WAJIB; yang lain optional. Mnemonic 4 exam-favourite: Output keLUAR (kongsi), Parameter masUK (input), Mapping ikut REGION, Condition ikut SYARAT. Transform = SAM (serverless app). INGAT exam: "only required section" → Resources; "region-specific AMI" → Mappings; "share between stacks" → Outputs.

Operasi STACK — konsep CARA CloudFormation urus (bukan section template)

KonsepApa diaExam keyword
StackKumpulan resource dari 1 template, urus sekali. Delete stack = semua resource padam (kemas)"group of resources / manage together"
StackSetsDeploy 1 template ke BANYAK account + region sekali gus (guna Organizations)"across multiple accounts/regions"
Nested StacksStack dalam stack — pecah jadi modul reusable (VPC/security layer)"reusable / modular templates"
Change SetPREVIEW perubahan SEBELUM apply pada stack"preview changes before applying"
Drift DetectionKesan resource diubah MANUAL di luar CFN (console)"detect manual / console changes, config drift"
DeletionPolicyApa jadi pada resource bila stack delete. Retain = resource KEKAL"preserve data when stack deleted → Retain"
Stack PolicyLindungi resource penting dari terubah/terpadam masa UPDATE"protect resource during stack update"

Ingat: Section = apa kau TULIS dalam template; Operasi = macam mana CFN URUS stack. INGAT exam: multi-account/region → StackSets; modular/reusable → Nested Stacks; preview → Change Set; manual change → Drift Detection; keep data on delete → DeletionPolicy: Retain; protect during update → Stack Policy.

Helper scripts — 4 keping (topik SEMPADAN: kenal cfn-init je dah cukup)

ScriptKerjaExam keyword
cfn-initBaca metadata + INSTALL packages/files/services masa EC2 launch"read metadata + install software on launch" (paling kerap)
cfn-signalHantar isyarat SUCCESS/FAIL balik ke CFN"signal stack when setup complete" (pair CreationPolicy/WaitCondition)
cfn-hupDaemon pantau perubahan metadata → re-run cfn-init bila stack update"re-run on metadata change"
cfn-get-metadataAmbil metadata SAHAJA — tak install apa-apa"just fetch metadata"

Ingat: init = mula/SETUP (install) · signal = bagi tahu SIAP · hup = PANTAU perubahan · get-metadata = AMBIL info je. INGAT exam: "read metadata and install packages when instance launches" → cfn-init. Ni topik sempadan SAA-C03 (jarang keluar) — cukup hafal cfn-init = install/setup + cfn-signal = bagi tahu siap, tak payah stress 4-4.

⚡ Quick Sifir — hafal ni

  • ▪CloudFormation FREE — bayar hanya resource yang dibuat (EC2/RDS/S3), stacks & StackSets percuma
  • ▪INGAT 4 komponen: Output keLUAR (kongsi antara stack), Parameter masUK (input launch), Mapping ikut REGION (lookup static), Condition ikut SYARAT (if/else)
  • ▪Cross-stack: Stack A guna Outputs + Export → Stack B guna Fn::ImportValue untuk import. Exported value TAK boleh delete/ubah selagi stack lain masih import dia
  • ▪Change Set = PREVIEW perubahan sebelum apply; Drift Detection = detect perubahan manual luar CFN
  • ▪Mappings = static lookup (region→AMI); Outputs+Fn::ImportValue = cross-stack ref; Parameters = user input
  • ▪cfn-init = install packages dari metadata; cfn-signal = hantar SUCCESS/FAIL; cfn-hup = re-run bila metadata berubah
  • ▪DeletionPolicy: Retain = resource KEKAL walau stack dipadam (untuk RDS/S3)
  • ▪Nested Stacks = reusable component (VPC/security layer); StackSets = deploy multi-account/region
  • ▪Stack update gagal → auto-ROLLBACK ke state lama (default)

🪤 Perangkap Soalan

Q: Satu CloudFormation template untuk banyak region, auto-pilih AMI ID betul ikut region. Guna apa?

⚠ Umpan: Parameters — sangka user kena input AMI ID setiap region.

✓ Betul: Mappings (static region→AMI lookup) atau Lambda-backed custom resource (dynamic lookup SSM). Bukan Parameters (manual). Keyword: 'region-specific AMI' → Mappings/custom resource.

Q: Nak detect kalau ada orang ubah resource stack secara MANUAL via console. Feature?

⚠ Umpan: Change Set — sangka ia tunjuk perubahan yang dah berlaku.

✓ Betul: Drift Detection. Change Set = preview perubahan SEBELUM apply; Drift = detect perubahan manual yang dah terjadi di luar CFN. Keyword: 'manual console changes' → Drift Detection.

Q: Padam stack tapi nak data RDS/S3 KEKAL (jangan lenyap). Macam mana?

⚠ Umpan: Backup manual dulu sebelum delete stack — leceh + boleh terlupa.

✓ Betul: Set DeletionPolicy: Retain pada resource tu. Stack dipadam, resource kekal. Keyword: 'retain data on stack deletion' → DeletionPolicy: Retain.

Q: Stack urus RDS dengan data production kritikal. Kalau stack TER-delete, nak pastikan database TAK musnah & data kekal. Set apa?

⚠ Umpan: Termination Protection — bunyi macam betul sebab ia 'protect dari delete'. Tapi ia halang STACK dari dipadam langsung; ia TAK kawal nasib resource kalau stack memang jadi dipadam.

✓ Betul: DeletionPolicy: Retain pada RDS resource — kalau stack dipadam, database tetap kekal. Keyword 'if stack deleted, preserve the resource/data' → DeletionPolicy: Retain. (Termination Protection = halang stack delete; DeletionPolicy = nasib resource bila stack memang delete.)

Q: Masa stack UPDATE, nak lindungi database production kritikal daripada terganti/terpadam oleh operasi update tu sendiri. Feature?

⚠ Umpan: DeletionPolicy: Retain — nampak betul sebab 'protect resource'. Tapi DeletionPolicy cuma terpakai bila STACK dipadam, bukan masa update.

✓ Betul: Stack Policy — JSON policy yang lindungi resource tertentu daripada diubah/diganti masa stack UPDATE. Keyword 'protect resource during stack update' → Stack Policy. (Stack Policy = masa UPDATE; DeletionPolicy = masa DELETE.)

Q: EC2 perlu READ METADATA dari CloudFormation template + INSTALL software packages bila instance launch. Helper script mana?

⚠ Umpan: cfn-hup atau cfn-signal — bunyi macam uruskan setup masa launch. SALAH: cfn-hup pantau perubahan metadata (re-run je), cfn-signal cuma bagi tahu CFN dah siap.

✓ Betul: cfn-init — baca AWS::CloudFormation::Init metadata + install packages/files/services masa launch. Logik nama: init = initialize/SETUP. Keyword 'read metadata + install packages on launch' → cfn-init.

🧠 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).
  • →PRICING: CloudFormation is FREE — kau bayar hanya untuk AWS resources yang ia create (EC2, RDS, S3, dll). Tiada charge untuk stacks, templates, changes, drift detection, StackSets. Designer & change sets juga free.
  • →StackSets: deploy ke multiple accounts/regions sekali gus. Perlukan AWS Organizations atau self-managed permissions. Boleh auto-reconcile drift.
  • →Exam: "no additional charge for using CloudFormation" → hanya bayar resources yang dibuat. Nested stacks & StackSets percuma.
  • →AWS Solutions (e.g. Instance Scheduler on AWS) = pre-built CloudFormation templates — deploy stack, bukan native service. Instance Scheduler auto start/stop EC2+RDS on schedule.
  • →Resources = SATU-SATUNYA section yang WAJIB dalam template. Template tanpa Resources tak sah. Exam: "the only required section in a CloudFormation template" → Resources.
  • →Transform: section untuk guna SAM (Serverless Application Model — AWS::Serverless-2016-10-31) atau CloudFormation macros. Exam: "simplify serverless (Lambda/API Gateway/DynamoDB) definitions in CloudFormation" → Transform / SAM.
  • →Stack Policy: JSON policy yang lindungi resource kritikal (e.g. database) daripada terubah/terpadam masa stack UPDATE — beza dengan DeletionPolicy (yang protect masa stack DELETE). Exam: "prevent accidental updates to specific resources during a stack update" → Stack Policy.
  • →Termination Protection: setting di STACK level yang halang stack itu sendiri daripada dipadam (mesti disable dulu sebelum boleh delete). BEZA: Termination Protection = halang stack DELETE; DeletionPolicy: Retain = kalau stack memang dipadam, kekalkan resource tertentu. Exam: "prevent the stack from being deleted" → Termination Protection; "keep the database if the stack is deleted" → DeletionPolicy: Retain.
  • →INGAT 3-cara keliru: Termination Protection (halang stack delete) · DeletionPolicy (nasib resource bila stack DELETE) · Stack Policy (lindung resource masa stack UPDATE).

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 templatesStackSetsfreepricingno additional chargeResourcesTransformSAMServerless Application ModelStack PolicyTermination ProtectionMetadatatemplate sectionsConditionsParameters
D3 · High-Performing

SSM

AWS Systems Manager

"Remote control untuk EC2 fleet"

🎯 Sebab Apa Wujud

SSM wujud sebab urus ratusan-ribuan EC2 (patch, run command, store config) secara manual via SSH = mustahil + bahaya (kena buka port 22, urus SSH keys, bastion host). SSM bagi kau control fleet at scale tanpa SSH: Run Command jalankan script serentak, Session Manager bagi shell tanpa buka port, Patch Manager auto-patch, Parameter Store simpan config/secret. Buang SSH key management + bastion + kerja manual per-instance.

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.

SSM: akses EC2 cara mana? (Run Command vs Session Manager vs User Data)

Rendering diagram…

INGAT exam: User Data = masa LAUNCH sahaja (tak boleh re-run on existing fleet). Existing fleet + no SSH → Run Command. Shell interactive tanpa port 22/bastion → Session Manager.

Parameter Store vs Secrets Manager

AspectParameter StoreSecrets Manager
Auto-rotation❌ Tiada (kena buat sendiri)✅ Native (RDS / Redshift / DocumentDB)
Kos🟢 Standard FREE (10K params)~$0.40/secret/mo + $0.05/10K API calls
EncryptSecureString (KMS, opt-in)Sentiasa encrypted (KMS)
Cross-accountAdvanced tier sahaja✅ Resource policy
Guna bilaConfig + secret, no rotation, jimatSecret yang WAJIB auto-rotate
Keyword"store config, minimize cost""auto-rotate DB password"

Ingat: Jimat + tak perlu rotation → Parameter Store (Standard percuma, SecureString untuk encrypt). Perlu auto-rotation native → Secrets Manager. Exam trap: "auto-rotate" = Secrets Manager, BUKAN Parameter Store SecureString.

⚡ Quick Sifir — hafal ni

  • ▪Run Command = jalankan command at scale tanpa SSH (perlu SSM Agent + AmazonSSMManagedInstanceCore role)
  • ▪Run Command = PARALLEL automated (banyak EC2 serentak); Session Manager = MANUAL shell satu-satu — bila dua pilihan sama-sama SSM, 'in parallel' → Run Command
  • ▪Session Manager = interactive shell TANPA port 22/bastion; audit ke S3/CloudWatch/CloudTrail
  • ▪Parameter Store Standard = FREE (10,000 params); Advanced = $0.05/param/mo + policies
  • ▪SecureString = encrypt value guna KMS (password/API key)
  • ▪Parameter Store = murah, NO auto-rotation; Secrets Manager = auto-rotation (~$0.40/secret/mo)
  • ▪SSM Agent pre-installed pada Amazon Linux 2 + Windows Server

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

🪤 Perangkap Soalan

Q: Update 100 EC2 instances serentak, policy LARANG SSH/port 22. Guna apa?

⚠ Umpan: User Data script — sangka boleh re-run untuk update.

✓ Betul: SSM Run Command. User Data hanya jalan masa LAUNCH, tak boleh re-run on existing fleet. Keyword: 'existing instances' + 'no SSH' + 'at scale' → Run Command.

Q: Simpan DB password yang kena auto-rotate setiap 30 hari. Parameter Store?

⚠ Umpan: Parameter Store SecureString — sangka SecureString = auto-rotate.

✓ Betul: Secrets Manager. Parameter Store tiada auto-rotation; Secrets Manager rotate native (RDS/Redshift/DocumentDB). Keyword: 'auto-rotate' → Secrets Manager, BUKAN Parameter Store.

Q: Nak interactive shell access ke EC2 tanpa buka port 22 atau bastion host. Service?

⚠ Umpan: Run Command — sangka command execution = shell access.

✓ Betul: Session Manager (browser-based interactive shell, no port 22, full audit). Run Command = non-interactive script je. Keyword: 'interactive shell' + 'no port 22/bastion' → Session Manager.

Q: Patch/update 100 EC2 dengan latest software packages. SSH dah DISABLED (DevSecOps refuse). Cara paling efficient + secure + IN PARALLEL? (A) AWS Config push update ke semua, (B) Attach IAM role SSM + Run Command, (C) Session Manager connect setiap instance manual, install satu-satu, (D) Minta SSH credentials DevSecOps.

⚠ Umpan: C (Session Manager) PALING menipu — dia pun SSM, pun TAK perlu SSH/port 22, jadi nampak betul. TAPI baca teliti: 'manually connect to EACH instance... install individually' = buat 100 kali satu-satu, lawan terus dengan 'in parallel + efficient'. A (Config) salah tujuan — Config track/audit STATE config je, TAK boleh push package update. D langgar polisi (DevSecOps refuse SSH) + kongsi credential = tak secure.

✓ Betul: B — IAM role (AmazonSSMManagedInstanceCore) + Run Command. Run Command hantar SATU command, semua 100 EC2 buat SERENTAK, automatik, tanpa SSH. Keyword pembeza bila DUA pilihan sama-sama SSM: 'in parallel / efficient / at scale' → Run Command; 'manual / individually / interactive shell' → Session Manager.

🧠 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.
  • →PRICING: Free tier — 2,000 activation registrations, 1,000 managed instances. Parameter Store Standard = FREE (up to 10,000 params). Advanced params = $0.05/param/mo + parameter policies. Session Manager = included (no additional charge). Run Command = included. Patch Manager = included. Only Advanced params + OpsCenter + State Manager associations ada charge.
  • →Exam: "minimize cost for storing parameters" → Parameter Store Standard (free, up to 10,000). "advanced features (policies, expiration)" → Advanced ($0.05/param/mo). "Session Manager cost" → free (included in SSM).

Guna Bila

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

Run CommandPatch ManagerParameter StoreSession Managerno SSHfleet managementparallel executionAmazonSSMManagedInstanceCoreSecureStringKMSStandard tierAdvanced tierbastion-freeSecrets Managerauto-rotationpricingfree tieradvanced params costsession manager included
D3 · High-Performing

AWS Config

AWS Config

"Audit & track apa yang berubah"

🎯 Sebab Apa Wujud

Config wujud sebab tanpa dia, kau tak ada cara tahu 'apa rupa setting resource ni semalam' atau 'siapa langgar policy encryption'. Sebelum ni team kena audit manual satu-satu — tak scalable. Config auto-rekod setiap perubahan config (state over time) + boleh enforce rules (cth 'semua S3 mesti encrypted') dan auto-fix bila ada yang langgar, jadi compliance jadi automatik bukan manual.

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.

AWS Config — komponen utama

Configuration Recorder → enjin yang detect & rekod setiap perubahan config resource. Kena ON dulu, kalau OFF Config tak rekod apa-apa

Configuration Item (CI) → 1 snapshot point-in-time bagi SATU resource (state + relationship + metadata). Ini unit yang kau bayar $0.003 setiap satu

Configuration History → timeline semua CI bagi satu resource — boleh banding "semalam vs hari ni"

Delivery Channel → saluran hantar config snapshot + history ke S3 bucket (+ notify via SNS/EventBridge)

Config Rule → evaluate CI lawan desired state → tanda Compliant / Non-compliant (managed atau custom Lambda)

Remediation (SSM Automation) → auto-fix resource yang non-compliant

AWS Config = album gambar config resource (analogi)

Rendering diagram…

Macam CCTV ambil gambar setiap kali bilik berubah → boleh banding "semalam vs hari ni" + auto-kemas bila bersepah. INGAT exam: "compliance + apa config berubah + auto-fix violations" → AWS Config (Rules + remediation).

AWS Config vs CloudTrail (WHAT vs WHO)

AspectAWS ConfigCloudTrail
Soalan dijawabApa STATE config resource (kini & dulu)? Compliant?SIAPA call API, bila, dari IP mana?
RekodSnapshot config resource over timeSetiap API call (user / time / IP / hasil)
Boleh enforce rule?✅ Config Rules + auto-remediation❌ Audit sahaja, tak enforce
Contoh"semua S3 mesti encrypted, auto-fix yang langgar""siapa buka SG port 22 semalam"
Keyword"compliance, config drift, resource history""who did what, API audit"

Ingat: Config = WHAT/STATE + compliance (boleh auto-fix). CloudTrail = WHO/API audit. Selalu guna sekali. Exam: "compliance + configuration over time / drift" → AWS Config, BUKAN CloudTrail. (3-way penuh dgn CloudWatch ada di card CloudTrail.)

⚡ Quick Sifir — hafal ni

  • ▪Config = WHAT/state config resource (sekarang & dulu). CloudTrail = WHO call API bila.
  • ▪Config Rules: managed (AWS pre-built) atau custom (Lambda) — evaluate continuous/on-change.
  • ▪Auto-remediation = Config rule + SSM Automation document (auto-fix non-compliant).
  • ▪Conformance Pack = bundle rules + remediation (CIS/NIST/PCI) deploy org-wide via StackSets.
  • ▪Per-region service, bukan global; Config Aggregator = view multi-account + multi-region central.
  • ▪PRICING: $0.003/config item recorded + $0.001/rule evaluation per region (bukan free).

💡 Exam Scenario

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

🪤 Perangkap Soalan

Q: Company nak tahu siapa yang ubah Security Group dan bila API call dibuat untuk audit. Service mana?

⚠ Umpan: AWS Config — sebab Config memang track perubahan resource, nampak macam betul.

✓ Betul: CloudTrail — keyword 'siapa call API & bila' = WHO/API audit = CloudTrail. Config jawab 'apa state config', bukan 'siapa call API'. (Selalunya guna dua-dua sekali.)

Q: Pastikan SEMUA S3 buckets encrypted dan auto-fix mana-mana yang tak comply. Pilihan terbaik?

⚠ Umpan: Lambda function scan bucket + fix — boleh jalan tapi kau bina & maintain sendiri.

✓ Betul: AWS Config Rule (managed 's3-bucket-server-side-encryption-enabled') + auto-remediation via SSM Automation. Keyword 'enforce compliance + auto-fix violations' = Config rules, bukan Lambda alone, bukan CloudTrail.

🧠 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.
  • →PRICING: $0.003 per configuration item recorded per region. $0.001 per config rule evaluation per region. Conformance packs = $0.001 per rule evaluation. Bukan free — kau bayar untuk setiap config item yang direkod dan setiap rule yang di-evaluate.
  • →Exam: "Config has per-item recording cost" → $0.003/configuration item. "conformance pack cost" → $0.001 per rule evaluation.

Guna Bila

Track configuration changes and compliance of AWS resources

complianceauditconfig changesconfig rulesresource historydrift detectionauto-remediationconformance packsConfig aggregatorSSM Automationmanaged rulescustom rulespricingper configuration itemper rule evaluation
D3 · High-Performing

CodeCommit

AWS CodeCommit

"GitHub tapi dalam AWS"

🎯 Sebab Apa Wujud

CodeCommit wujud sebab dulu kalau nak private Git repo dalam AWS kau kena host GitHub Enterprise/GitLab sendiri atas EC2 — kena patch, scale, backup. CodeCommit hapuskan beban tu: managed Git repo yang access control terus guna IAM (tak payah user system asing) dan plug terus ke CodePipeline/CodeBuild. (Nota: AWS dah tutup CodeCommit untuk pelanggan baru, tapi konsep masih keluar exam.)

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.

⚡ Quick Sifir — hafal ni

  • ▪CodeCommit = managed private Git repo dalam AWS, access guna IAM (bukan user asing).
  • ▪Native integrate dengan CodePipeline/CodeBuild/CodeDeploy — push trigger pipeline.
  • ▪Encryption: data at rest auto-encrypt (KMS), in-transit HTTPS/SSH.
  • ▪Bukan untuk store artifact besar/binary — itu kerja S3.

💡 Exam Scenario

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

🪤 Perangkap Soalan

Q: Team nak private Git source control dalam AWS dengan access control yang integrate terus dengan IAM users/roles. Service?

⚠ Umpan: Host GitHub Enterprise atas EC2 — boleh, tapi kau urus server sendiri (patch/scale).

✓ Betul: CodeCommit — keyword 'private Git + IAM access control + fully managed' = CodeCommit, no server to manage.

🧠 Cara Mudah Ingat

  • →CodeCommit vs S3: CodeCommit = Git version control untuk SOURCE CODE (branch, commit, merge). S3 = object store untuk artifact/binary besar — bukan source control.
  • →Access control = IAM policies + IAM users/roles (no separate accounts). Encryption: at-rest auto via KMS, in-transit HTTPS/SSH.
  • →PRICING: free tier 5 active users/account (50GB storage + 10K Git requests/user/mo), lepas tu $1.00 per active user/bulan. NOTA: AWS dah tutup CodeCommit untuk pelanggan BARU (sejak 2024) — repo sedia ada masih jalan; konsep masih boleh keluar exam.

Guna Bila

Private Git repository dalam AWS ecosystem

Gitsource controlversion controlprivate repoIAM integrationpricing
📎 What is AWS CodeCommit
D3 · High-Performing

CI/CD Pipeline

CodeCommit → CodeBuild → CodeDeploy → CodePipeline

"4 Code services = full DevOps pipeline"

🎯 Sebab Apa Wujud

Suite ni wujud sebab buat deployment manual (copy code, run test, SSH masuk server, restart) itu lambat + senang silap + tak boleh ulang konsisten. 4 Code services automate seluruh aliran build→test→deploy supaya setiap code push terus jalan pipeline yang sama tiap kali — tiada manusia tersilap langkah, deploy laju & boleh ulang.

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

Aliran 4 Code services — siapa buat apa (CodePipeline = otak)

Rendering diagram…

CodePipeline = orchestrator (otak) yang detect push & sambung setiap stage ikut urutan. INGAT exam: "automate end-to-end on push / orchestrate" → CodePipeline; CodeBuild = build+test je (satu stage); CodeDeploy = deploy + blue-green/canary.

⚡ Quick Sifir — hafal ni

  • ▪CodeCommit = store code. CodeBuild = compile + test. CodeDeploy = deploy. CodePipeline = orchestrate semua.
  • ▪CodePipeline = ORCHESTRATOR (otak) — detect push, sambung step ikut urutan.
  • ▪CodeDeploy boleh deploy ke EC2, Lambda, ECS, on-premises.
  • ▪CodeBuild serverless build — bayar per build minute, no build server to manage.
  • ▪CodeDeploy support blue/green & canary deployment (kurangkan risiko release).

💡 Exam Scenario

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

🪤 Perangkap Soalan

Q: Setiap code push mesti auto-build, run test, dan deploy ke production EC2 tanpa langkah manual. Service utama yang orchestrate?

⚠ Umpan: CodeBuild — sebab dia yang build & test, nampak macam pusat aliran.

✓ Betul: CodePipeline — keyword 'orchestrate / automate end-to-end on push' = CodePipeline (orchestrator). CodeBuild hanya satu stage (build/test) dalam pipeline tu.

🧠 Cara Mudah Ingat

  • →CodePipeline = ORCHESTRATOR (otak). CodeBuild = build+test (satu stage). CodeDeploy = deploy (blue-green/canary). Jangan pilih CodeBuild bila soalan tanya "yang orchestrate end-to-end".
  • →CodeDeploy deployment strategy: in-place, blue/green (EC2/ECS/Lambda), canary & linear (Lambda/ECS) — kurangkan risiko release. Keyword "gradual / shift traffic / rollback automatic" → CodeDeploy.
  • →PRICING: (approx)CodePipeline V1 = $1.00/active pipeline/bulan (1 free first 30 days/pipeline). CodeBuild = per build-minute ikut compute (general1.small ~$0.005/min, 100 min/mo free tier). CodeDeploy = FREE deploy ke EC2/Lambda/ECS; on-prem $0.02/instance update. Exam: CodeDeploy ke EC2/Lambda/ECS percuma — bayar resource je.

Guna Bila

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

CI/CDCodePipelineCodeBuildCodeDeployDevOpsautomationpipelineblue-greencanaryorchestratorpricing
📎 AWS CodePipeline — what is📎 CodeDeploy deployment types (blue/green, canary)
D3 · High-Performing

CloudWatch

Amazon CloudWatch

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

🎯 Sebab Apa Wujud

CloudWatch wujud sebab kau tak boleh manage benda yang kau tak nampak — tanpa dia kau takkan tahu CPU EC2 dah 95%, Lambda error, atau bila perlu scale out. Dia kumpul metrics + logs di satu tempat dan boleh trigger action (alarm → SNS / Auto Scaling) bila threshold lepas, jadi masalah dikesan & dibetulkan automatik sebelum user sedar.

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.

CloudWatch = doktor pantau vital signs (analogi)

Rendering diagram…

Macam doktor pantau jantung & tekanan darah → bunyi alarm bila bacaan bahaya, terus bertindak (SNS/Auto Scaling). INGAT exam: memory & disk SPACE BUKAN default metric — kena pasang (unified) CloudWatch agent dulu.

CloudWatch vs CloudTrail vs Config vs X-Ray (observability 4-way)

AspectCloudWatchCloudTrailAWS ConfigX-Ray
Soalan dijawabApa berlaku SEKARANG?SIAPA call API?Resource compliant? apa BERUBAH?KENAPA lambat / mana gagal?
DataMetrics, logs, alarms, dashboardAPI call audit historyConfig state history + rulesEnd-to-end request trace + service map
Keyword"CPU > 80% alarm, monitor logs""who deleted resource""compliance, config drift""bottleneck merentas microservices"

Ingat: NOW (metrics/alarm) → CloudWatch · WHO (API audit) → CloudTrail · COMPLIANT/CHANGED → Config · WHY SLOW (trace) → X-Ray. Confusion paling kerap di exam: CloudWatch vs CloudTrail vs Config.

⚡ Quick Sifir — hafal ni

  • ▪CloudWatch = METRICS + LOGS + ALARMS. CloudTrail = API audit. X-Ray = trace latency.
  • ▪EC2 CPU/network/disk I/O = default metric. MEMORY & disk SPACE = kena install CloudWatch agent.
  • ▪Unified CloudWatch Agent = metrics (incl memory) + logs + traces, Linux & Windows.
  • ▪Standard monitoring = 5 min (free). Detailed = 1 min ($0.015/instance/hr).
  • ▪Logs Insights = query logs dalam CloudWatch (SQL-like). Athena = query logs dalam S3.
  • ▪PRICING free tier: 10 metrics, 10 alarms, 5GB logs, 3 dashboards/bulan.

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

🪤 Perangkap Soalan

Q: Kau perlu monitor MEMORY utilization EC2 instance dan alert bila lebih 90%. Apa kena buat?

⚠ Umpan: Terus buat CloudWatch alarm atas memory metric — sebab CloudWatch memang monitor EC2.

✓ Betul: Install/configure (unified) CloudWatch agent DULU, baru boleh alarm. Keyword: memory & disk space BUKAN default metric — default cuma CPU/network/disk I/O.

Q: Team nak query & analyze log Lambda secara interactive guna SQL-like query. Service?

⚠ Umpan: Amazon Athena — sebab Athena guna SQL untuk analyze logs, nampak betul.

✓ Betul: CloudWatch Logs Insights — keyword 'query CloudWatch Logs interactively' = Logs Insights. Athena = untuk log yang dah dalam S3, bukan dalam CloudWatch Logs.

🧠 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.
  • →PRICING: Free tier — 10 custom metrics, 10 alarms, 5 GB log ingestion, 3 dashboards/month. Detailed monitoring (1-min) = $0.015/instance/hr. Custom metrics = $0.30/1,000 metrics/mo. Alarms = $0.10/alarm/mo. Logs ingestion = $0.50/GB. Logs archival = $0.03/GB/mo. Dashboards (3 free, then $3/dashboard/mo).
  • →Exam: "free tier includes 10 alarms" → CloudWatch. "detailed monitoring cost" → $0.015/instance/hr on top of standard (free, 5-min).

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-likepricingfree tiercustom metrics costlog ingestion cost
D3 · High-Performing

X-Ray

AWS X-Ray

"GPS untuk trace request melalui microservices"

🎯 Sebab Apa Wujud

X-Ray wujud sebab bila request lalu 10+ microservices (API Gateway → Lambda → DynamoDB → SQS...), kalau lambat atau gagal kau tak tahu komponen MANA yang punca — log berselerak tiap service. X-Ray jahit semua jadi satu trace end-to-end + service map visual, jadi kau nampak terus mana bottleneck/error tanpa teka.

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.

X-Ray = GPS jejak perjalanan request (analogi)

Rendering diagram…

Macam GPS tunjuk highway mana jam — X-Ray trace setiap hop & highlight node paling lambat. INGAT exam: "mana bottleneck / message hilang merentas microservices" → X-Ray service map; auto anomaly + notify → X-Ray Insights.

CloudWatch vs CloudTrail vs X-Ray

AspectCloudWatchCloudTrailX-Ray
Soalan dijawabApa berlaku sekarang? (metrics/logs)Siapa call API bila?Kenapa lambat / mana gagal?
DataMetrics, logs, alarmsAPI call history (audit)End-to-end request trace + service map
Guna untukMonitoring + alertAudit + forensicsDebug latency merentas microservices
Keyword"CPU > 80% alarm""who deleted resource""mana bottleneck dalam 10 microservices"

Ingat: Metrics/alarm → CloudWatch. WHO did WHAT → CloudTrail. WHY slow / WHERE fail merentas service → X-Ray service map. Exam: "distributed tracing / find bottleneck across microservices" → X-Ray, BUKAN CloudWatch.

⚡ Quick Sifir — hafal ni

  • ▪X-Ray = distributed tracing / service map — WHY slow & WHERE fail.
  • ▪CloudWatch = metrics/alarms. CloudTrail = WHO call API. X-Ray = trace request path.
  • ▪Works dengan Lambda, EC2, ECS, API Gateway, SQS — end-to-end.
  • ▪X-Ray Insights = auto-detect anomaly (latency/error spike) + notify via SNS/EventBridge.
  • ▪Service map = peta visual tunjuk node mana paling lambat / paling banyak error.

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

🪤 Perangkap Soalan

Q: App microservices (API Gateway → Lambda → DynamoDB) jadi lambat tapi team tak tahu komponen mana punca latency. Service untuk identify bottleneck?

⚠ Umpan: CloudWatch — sebab dia kumpul metrics latency tiap service, nampak boleh diagnose.

✓ Betul: AWS X-Ray — keyword 'distributed tracing / mana bottleneck merentas microservices' = X-Ray service map. CloudWatch bagi angka per-service, tapi tak jahit jadi satu trace end-to-end.

Q: Message kadang tak sampai destinasi dalam sistem SQS + Lambda + API Gateway. Nak debug aliran message. Service?

⚠ Umpan: CloudTrail — sebab nak audit apa jadi, nampak macam jejak aktiviti.

✓ Betul: X-Ray — keyword 'trace message path / mana message hilang dalam distributed system' = X-Ray. CloudTrail jejak API call, bukan aliran message dalam app.

🧠 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
  • →PRICING: Free tier 100,000 traces/mo. Selepas itu ~$5.00 per 100,000 traces recorded. Tak caj untuk traces yang tak di-sampled. Exam: "distributed tracing cost / free tier 100K traces" → X-Ray.

Guna Bila

Distributed tracing — debug latency and errors across microservices and serverless

distributed tracingservice maplatency analysismicroservicesLambda tracingbottleneckdebuggingSQS tracingend-to-end tracebottleneck detectionX-Ray Insightsanomaly detectionpricing
📎 AWS X-Ray concepts
D3 · High-Performing

AWS Health Dashboard

AWS Health Dashboard

"Status AWS untuk AKAUN KAU sendiri, bukan global"

🎯 Sebab Apa Wujud

Health Dashboard wujud sebab Service Health page yang public itu cakap pasal AWS keseluruhan — tak bagitahu sama ada RESOURCE KAU sendiri yang kena. Account-level Health Dashboard bagi pandangan peribadi: event/maintenance/retirement yang betul-betul affect resource dalam akaun kau, plus boleh auto-notify via EventBridge supaya team tahu awal (cth EC2 nak retire) bukan terkejut bila benda dah mati.

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.

Service Health vs Account Health — pilih ikut soalan

Rendering diagram…

"Adakah AWS down?" = Service Health (public). "Adakah RESOURCE SAYA kena + nak auto-alert" = AWS Health account view → EventBridge. INGAT: Health = REACTIVE (event), Trusted Advisor = PROACTIVE (cadangan).

Service Health vs Account Health vs Trusted Advisor

AspectService Health DashboardAWS Health (account view)Trusted Advisor
SkopAWS global status (public)Event affecting RESOURCE KAUBest-practice checks akaun kau
Reactive / ProactiveReactive — outage globalReactive — event/maintenance resource kauProactive — recommendations
Personalized?❌ Semua orang nampak sama✅ Ikut resource dalam akaun kau✅ Ikut akaun kau
Auto-notify❌ Manual check page✅ EventBridge → Lambda / SNSWeekly email (Business+)
Keyword"is AWS down globally?""is MY resource affected / scheduled retirement""am I following best practice?"

Ingat: "AWS global down?" → Service Health (public page). "Resource SAYA kena / scheduled maintenance + auto-notify Slack" → AWS Health account view + EventBridge. "Best-practice review" → Trusted Advisor.

⚡ Quick Sifir — hafal ni

  • ▪Service Health Dashboard = status AWS global (public). AWS Health Dashboard = personalized, akaun kau.
  • ▪Health = REACTIVE (event/maintenance/outage affect resource kau). Trusted Advisor = PROACTIVE (cadangan cost/security/perf).
  • ▪Route Health events ke EventBridge → Lambda/SNS untuk auto-alert (cth Slack notify).
  • ▪Full Health API access perlu Business/Enterprise Support plan.

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

🪤 Perangkap Soalan

Q: Ada isu di satu region — team nak tahu adakah resource SPESIFIK syarikat mereka yang terkesan, dan nak auto-notify Slack. Penyelesaian?

⚠ Umpan: Pantau Service Health Dashboard (status.aws) — sebab dia tunjuk isu region, nampak relevan.

✓ Betul: AWS Health Dashboard (account view) + EventBridge → Lambda → Slack. Keyword 'resource SAYA terkesan / personalized event' = account Health Dashboard, bukan public Service Health page.

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