AWS SAA-C03 Study

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

📨Messaging & Serverless↑ Top

D3 · High-Performing

SQS

Simple Queue Service

"Baris gilir message"

🎯 Sebab Apa Wujud

Wujud sebab kalau service A panggil service B terus (synchronous), bila B sibuk/down → A tersekat/gagal, dan bila trafik melonjak B kena hentam terus sampai pengsan. SQS letak "baris gilir" di tengah: A campak mesej masuk queue & teruskan kerja, B amik (pull) ikut kadar SENDIRI. Kalau B mati, mesej tunggu dalam queue (tak hilang) sampai B sihat balik. Tujuan: decouple service + serap lonjakan (buffer) + tahan kegagalan (retry/DLQ).

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.

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

Lambda producer → SQS → Lambda consumer (throttling fix)

Rendering diagram…

Exam pattern: pecah 1 Lambda jadi 2 — producer ACK cepat (return selepas enqueue), SQS buffer burst, consumer poll & proses ikut kadar sendiri → kurang 429 throttle. SNS SALAH: push real-time, tak buffer. DAX/DynamoDB SALAH: root cause = Lambda concurrency, bukan DB read cache. INGAT: "throttling / acknowledge when accepted / decouple" → SQS antara 2 Lambda.

Pilih messaging service — SQS vs SNS vs EventBridge vs Amazon MQ (decision tree)

Rendering diagram…

Tanya ikut urutan: (1) legacy broker? → Amazon MQ. (2) route ikut isi / event AWS / cron? → EventBridge. (3) satu-ke-ramai serentak? → SNS. (4) selainnya, buffer & pull → SQS. INGAT exam: SQS = pull & buffer · SNS = push & broadcast · EventBridge = route pintar · Amazon MQ = jambatan legacy.

Analogi — 4 cara hantar mesej di pejabat

Rendering diagram…

Kaitkan dengan familiar: pos = beratur & pull (SQS), pembesar suara surau = broadcast serentak (SNS), switchboard = route ikut jenis (EventBridge), adapter palam = sambung legacy ke cloud (Amazon MQ). INGAT exam: "decouple/buffer" → SQS, "notify many/fan-out" → SNS, "route by content/schedule" → EventBridge, "migrate existing broker" → Amazon MQ.

DLQ — aliran mesej gagal + analogi Kotak Surat Mati

Rendering diagram…

Analogi: posmen (consumer) cuba hantar surat rosak 3 kali (maxReceiveCount), asyik gagal → ketua pos lempar masuk Kotak Surat Mati (DLQ) supaya surat lain tak tersekat; pegawai siasat (developer) buka kotak kaji punca, lepas betul tekan Redrive hantar balik. INGAT exam: "mesej corrupt/poison pill blok queue, nak isolate & debug" → DLQ + maxReceiveCount; "hantar balik lepas fix" → Redrive.

Cross-account SQS — "Dua Kunci" (analogi Ali hantar surat ke Peti Syarikat B)

Rendering diagram…

Kaitkan dengan familiar: Ali (Syarikat A) nak masuk surat ke Peti-SQS (Syarikat B). Syarikat A bagi Ali pas keluar (IAM Policy, Resource = ID akaun B). Syarikat B tulis memo kat pengawal peti (Queue Policy, Principal = ID akaun A:root). Dua-dua belah WAJIB izin — set satu belah je → pintu tutup, Access Denied. INGAT exam: cross-account SQS = IAM policy (source) AND SQS queue policy (destination, ada Principal).

Standard vs FIFO queue

Aspect	Standard	FIFO
Ordering	Best-effort (can arrive out of order)	🟢 Strict order (per MessageGroupId)
Delivery	At-least-once (can duplicate)	Exactly-once (deduplication)
Throughput	Nearly unlimited	300 msg/s (3000 with batching)
Name suffix	any	must end in .fifo
Use when	Max throughput, dupes OK	Order + no duplicates matter

Ingat: "Duplicate processing must be eliminated" or "order must be preserved" → FIFO. Default high-throughput decoupling → Standard.

Cross-account SQS — rupa JSON Kunci 1 (IAM, source) vs Kunci 2 (Queue Policy, destination)

Aspect	Kunci 1 — IAM Policy	Kunci 2 — SQS Queue Policy
Lekat di mana	Source Account 1111 (pada user/role Ali)	Destination Account 2222 (pada queue itu sendiri)
Jenis policy	Identity-based	Resource-based
Ada "Principal"?	❌ Tiada (dah tahu siapa — Ali)	🟢 WAJIB ada → "AWS": "arn:aws:iam::1111:root"
Effect / Action	Allow · sqs:SendMessage	Allow · sqs:SendMessage
"Resource" ID	arn:...:2222:Peti-SQS (ID akaun DESTINATION)	arn:...:2222:Peti-SQS (queue sendiri)
Maksud	"Ali dibenarkan hantar KELUAR ke queue akaun 2222"	"Aku (queue) percaya root akaun 1111 hantar masuk"

Ingat: Cara baca cepat: Principal HANYA wujud di resource-based policy (Kunci 2) — itu cara nak kenal mana satu. IAM (Kunci 1) sebut ID akaun destination dalam Resource; Queue Policy (Kunci 2) sebut ID akaun source dalam Principal. Silang ID = corak cross-account. Set satu belah je → Access Denied. Exam: pangkah jawapan "IAM policy sahaja" atau "queue policy sahaja".

⚡ Quick Sifir — hafal ni

▪SQS = PULL queue, satu mesej diproses oleh SATU consumer. SNS = PUSH ke ramai
▪Standard = at-least-once (boleh duplicate) + best-effort order. FIFO = exactly-once + strict order
▪Order penting / no duplicate → FIFO (.fifo, 300/s atau 3000 batch)
▪Visibility Timeout < masa proses → mesej muncul balik → DUPLICATE. Naikkan timeout
▪Cross-account hantar ke queue → SQS queue policy (resource-based), bukan IAM je
▪Long polling (WaitTime>0, max 20s) → kurangkan empty response & kos API
▪DLQ = SQS queue asing untuk mesej gagal. Cetus bila ReceiveCount > maxReceiveCount
▪Poison pill (data corrupt) → DLQ, kalau tak server pusing proses sampai bil melambung
▪DLQ source FIFO → DLQ kena FIFO juga; source Standard → DLQ kena Standard
▪Lepas fix bug → DLQ Redrive tolak balik mesej ke queue utama, tak payah tulis kod
▪Scale consumer (ECS/EC2) ikut queue backlog BUKAN CPU/Memory — CPU rendah walau queue penuh sebab container proses satu-satu. Guna custom metric ApproximateNumberOfMessagesVisible atau backlog per task (queue depth ÷ target capacity)

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

🪤 Perangkap Soalan

Q: Sistem pembayaran proses mesej dua kali kadang-kadang, dan susunan transaksi mesti tepat. Queue SQS sedia ada Standard. Pembetulan minimum?

⚠ Umpan: Tambah logik dedup & susun semula dalam kod aplikasi consumer. Nampak betul sebab "betulkan dalam kod".

✓ Betul: Tukar ke SQS FIFO queue — ia bagi exactly-once (deduplication) + strict ordering per MessageGroupId secara built-in, perubahan kod minimum. Standard memang at-least-once + best-effort order. Keyword "no duplicates / order preserved" → FIFO.

Q: Consumer EC2 (Spot) ditamatkan separuh jalan semasa memproses mesej SQS. Adakah mesej hilang?

⚠ Umpan: Ya, hilang — sebab consumer dah amik mesej tu dari queue dan mati sebelum siap. Nampak betul sebab "dah diambil".

✓ Betul: TIDAK hilang. Mesej cuma jadi INVISIBLE semasa Visibility Timeout; sebab consumer tak panggil DeleteMessage, ia jadi VISIBLE semula lepas timeout dan consumer lain proses. Mesej hanya hilang bila DeleteMessage dipanggil selepas berjaya. Keyword "consumer dies mid-processing" → mesej selamat (visibility timeout).

Q: App ECS ingest file (PDF/JPEG/DOCX) async & upload ke DMS. Masa campaign trafik naik 500%, kadang upload gagal → file HILANG sebab tak disimpan sementara. Pilih redesign: (A) S3 simpan file + SQS queue request, (B) RDS simpan file + SNS notify, (C) DynamoDB simpan metadata file + Lambda proses upload, (D) EFS simpan file + Amazon MQ.

⚠ Umpan: C (DynamoDB + Lambda) paling menipu — Lambda nampak "auto-scale untuk burst" & DynamoDB nampak "tempat simpan". TAPI DynamoDB simpan METADATA je (nama/saiz/status), BUKAN file sebenar — ada had 400 KB per item, PDF/DOCX tak muat. Jadi root cause "file tak disimpan" MASIH tak selesai → file tetap hilang. B (RDS) salah: RDS bukan untuk binary blob besar + mahal; SNS = notify, bukan buffer. D (EFS+MQ) salah: EFS mahal vs S3, Amazon MQ untuk legacy broker — bukan cost-efficient.

✓ Betul: A — S3 simpan FILE sebenar (durable 11 nines, murah, scale auto → file tak hilang walau upload ke DMS gagal) + SQS buffer/decouple request masa burst 500% (DMS sibuk → mesej tunggu dalam queue, proses ikut kadar DMS). Keyword: "file hilang sebab tak disimpan" → simpan file kat S3 (BUKAN RDS/DynamoDB); "burst + async + jangan hilang" → SQS. INGAT: simpan FILE = S3; simpan METADATA = DynamoDB.

Q: Data lake terpusat dalam Analytics Account ada satu SQS queue. App dalam BANYAK account lain perlu hantar (SendMessage) ke queue terpusat tu. Cara paling efficient & scalable? (A) IAM policy dalam Analytics Account bagi SendMessage ke account lain, (B) SQS queue policy bagi SendMessage ke account lain, (C) IAM role dalam Analytics Account, account lain assume role tu untuk hantar, (D) Both B and C valid & sama efficient.

⚠ Umpan: D "Both B and C valid" paling menipu — sebab C (assume role) MEMANG boleh jadi (account lain assume role → dapat temp creds → SendMessage), jadi nampak "dua-dua betul". TAPI exam tanya paling EFFICIENT & SCALABLE: C paksa setiap account buat STS AssumeRole dulu (extra hop + kena urus trust setiap account) → meleret bila account makin ramai. A pula salah konsep: IAM policy dalam Analytics Account urus apa principal Analytics SENDIRI boleh buat — ia TAK boleh "bagi" account lain akses; cross-account grant kena datang dari sisi resource.

✓ Betul: B — SQS queue policy (resource-based) pada queue, terus sebut Principal account lain + Allow SendMessage. Satu policy kat queue cover semua account (boleh guna kondisi aws:PrincipalOrgID untuk seluruh Org sekali gus), takde assume-role hop. Keyword "allow OTHER accounts to send to centralized SQS" → SQS queue policy (resource-based), BUKAN IAM policy sahaja, BUKAN assume-role (over-engineered untuk hantar mesej je).

Q: Satu mesej dalam queue ada data corrupt — consumer cuba proses, crash, mesej balik queue, cuba lagi, crash lagi… berulang sampai blok mesej lain & bil naik. Kau nak isolate mesej bermasalah tu untuk debug tanpa ganggu trafik live. Apa setup terbaik?

⚠ Umpan: Naikkan Visibility Timeout supaya mesej tu "rehat" lama-lama, atau tambah logik retry + try/catch dalam kod consumer. Nampak betul sebab "uruskan mesej gagal". SALAH: naikkan visibility timeout cuma LAMBATKAN mesej muncul balik — ia tetap balik & crash lagi (loop tak putus). Retry dalam kod pun masih pusing benda corrupt yang sama (poison pill) selamanya.

✓ Betul: Setup Dead-Letter Queue (DLQ) + set maxReceiveCount (cth 3) pada source queue. Lepas mesej gagal diproses 3 kali (ReceiveCount > maxReceiveCount), SQS AUTO pindahkan ia keluar dari queue utama masuk DLQ → trafik live jalan semula, developer bedah mesej dalam DLQ asingan. Keyword "corrupt/poison message blok queue + isolate untuk debug" → DLQ + maxReceiveCount, BUKAN visibility timeout, BUKAN retry dalam kod.

Q: E-commerce (EC2 + ALB + RDS) jangka lonjakan WRITE besar masa product launch. RDS hampir cecah IOPS limit; vertical scaling tak nak sebab bajet. Cara cost-effective handle write-heavy? (A) Tambah RDS Read Replica, (B) Letak SQS queue depan — app tulis ke queue, consumer proses ke RDS ikut kadar mampu, (C) Upgrade instance class RDS, (D) Migrate ke DynamoDB.

⚠ Umpan: A (Read Replica) paling menipu — nampak "scaling RDS" terus pilih. TAPI Read Replica scale READ je (offload SELECT); ia LANGSUNG tak bantu WRITE — malah write kena replicate ke replica juga. C (upgrade instance) = vertical scaling, dah dikecualikan (bajet). D (DynamoDB) = re-architecture besar, mahal & berisiko untuk relational e-commerce, bukan "cost-effective minimal change".

✓ Betul: B — SQS di depan RDS (queue-based load leveling): app campak write request masuk queue, consumer proses ke RDS ikut kadar yang RDS MAMPU. Lonjakan write diserap dalam queue (buffer) → RDS tak kena hentam lebih IOPS limit. Murah (SQS sen je) + tak perlu vertical scaling. Keyword "write-heavy spike / nearing IOPS limit / cost-effective / no vertical scaling" → SQS buffer writes (queue-based load leveling). INGAT: Read Replica = READ scaling, BUKAN write.

Q: API Gateway → Lambda terima 5KB JSON, simpan ke Aurora. App cuma perlu ACK bila request diterima (bukan bila siap proses). Banyak Lambda throttle (429), terpaksa naikkan concurrent execution berkali-kali. Fix?

⚠ Umpan: Pecah 2 Lambda + SNS antara keduanya — SNS nampak "signal work" macam queue. SALAH: SNS PUSH real-time ke subscriber; bila burst, consumer Lambda masih kena hentam serentak = masih throttle.

✓ Betul: Pecah 2 Lambda + SQS di tengah — producer enqueue & return cepat; SQS BUFFER burst; consumer poll ikut kadar (Event Source Mapping + backoff bila throttle). Keyword "acknowledge when accepted / throttling / decouple" → SQS, BUKAN SNS. DAX/DynamoDB tak selesai root cause (Lambda concurrency, bukan DB read).

🧠 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.
→DLQ (Dead-Letter Queue): setup via RedrivePolicy pada SOURCE queue, set maxReceiveCount. Bila ReceiveCount > maxReceiveCount → SQS auto-move mesej ke DLQ. DLQ sendiri queue SQS biasa.
→Poison pill = mesej corrupt yang asyik gagal proses. Tanpa DLQ → consumer pusing proses benda sama berulang → kos & throughput terbakar. DLQ keluarkan ia supaya queue utama jalan semula.
→DLQ jenis mesti SAMA dengan source: source FIFO → DLQ FIFO; source Standard → DLQ Standard. Salah jenis = tak boleh attach.
→DLQ Redrive: lepas developer fix bug, guna Redrive (console / StartMessageMoveTask API) tolak balik mesej dari DLQ ke queue utama untuk reproses — tak perlu tulis kod pindah manual.
→DLQ retention: kira dari masa mesej MASUK queue ASAL (bukan masa masuk DLQ). Set retention DLQ lebih panjang (cth 14 hari) supaya ada masa debug sebelum mesej luput.
→Exam trigger: "messages failing repeatedly block the queue" / "isolate & analyze corrupted messages separately" → Dead-Letter Queue + tune maxReceiveCount (BUKAN naikkan visibility timeout, BUKAN retry dalam kod).
→Queue-based scaling (SQS + ASG/ECS): scale consumer ikut queue backlog, BUKAN CPU/Memory. CPU/Memory BUTA terhadap barisan queue (container proses satu-satu → CPU kekal rendah walau 10,000 mesej sangkut). Guna custom metric ApproximateNumberOfMessagesVisible (CloudWatch) atau backlog per task (queue depth ÷ ECS target capacity) → Target Tracking scale out bila backlog tinggi. Keyword "scale based on SQS queue" → custom metric backlog, BUKAN CPU/Memory.
→PRICING (us-east-1): SQS Standard ~$0.40 per 1M requests; FIFO ~$0.50/1M (more expensive). Free tier 1M requests/mo (Standard). 1 request = any API call (SendMessage, ReceiveMessage, DeleteMessage) — BUKAN ikut tempoh queue hidup. Jimat kos: (1) BATCHING — up to 10 messages per request → 10x kurang request bill; (2) LONG POLLING (WaitTimeSeconds>0) → kurang empty-poll request. Payload >256KB → simpan kat S3 + SQS message rujuk je (Extended Client Library).

Guna Bila

Decouple services, async queue

queuedecoupleasyncpull-basedvisibility timeoutFIFODLQat-least-onceexactly-oncelong pollingshort pollingbatch operationsduplicate messagesqueue policycross-account SQSresource-based policySNS SQS Lambda fan-outSQS vs SNS vs EventBridgepilih messaging servicepull vs pushS3 SQS decoupleasync file uploadburst traffic bufferstore file S3 not DynamoDBtemporary file storagemaxReceiveCountRedrivePolicyDLQ redrivepoison pillfailed messagesisolate corrupted messagesdead-letter queuePrincipalsource accountdestination accounttwo keysdua kunciSendMessage cross-accountaws:PrincipalOrgIDqueue policy JSONqueue-based scalingApproximateNumberOfMessagesVisiblebacklog per taskcustom metric scalingscale on queue depthLambda producer consumerLambda throttling bufferacknowledge when acceptedpricing

📎 SQS — visibility timeout 📎 SQS — short vs long polling 📎 SQS — dead-letter queues

D3 · High-Performing

SNS

Simple Notification Service

"Broadcast message ke ramai sekaligus — push, bukan pull"

🎯 Sebab Apa Wujud

Wujud sebab kadang SATU event perlu cetuskan BANYAK tindakan berasingan serentak — cth gambar di-upload perlu buat thumbnail + index metadata + arkib, semua sekali gus. Kalau publisher kena panggil setiap downstream satu-satu, dia jadi coupled & rapuh. SNS = pembesar suara: publisher campak SATU mesej ke topic, SNS PUSH salinan ke SEMUA subscriber (fan-out) serentak. Tujuan: pub/sub broadcast — satu-ke-ramai tanpa publisher kenal siapa subscriber.

Apa Dia

Pub/sub messaging service — publisher hantar message ke SNS topic, semua subscribers terima serentak. Subscribers boleh jadi SQS, Lambda, HTTP/S endpoints, email, SMS. Push-based (SNS hantar ke subscriber), bukan pull-based macam SQS.

SNS Key Concepts

Message Filtering → Subscriber boleh set filter policy (JSON) supaya hanya terima message yang match criteria — tak perlu filter dalam app code

Message Delivery → Push-based, SNS hantar ke subscriber endpoint. Retry policy built-in untuk HTTP/S

FIFO Topics → Ordered, deduplicated delivery (pair dengan SQS FIFO queues). Max 300 publishes/sec (3000 with batching)

Message Size → Max 256 KB per message. Guna Extended Client Library + S3 untuk larger payloads

Fan-out anatomy

S3 Upload

event source

SNS Topic

1 publish

SQS

thumbnail

SQS

metadata

SQS

Kinesis

Amazon Kinesis (Data Streams vs Firehose)

"Streaming pipe — Streams = real-time + code, Firehose = auto-deliver no code"

🎯 Sebab Apa Wujud

Wujud sebab data streaming (clickstream, IoT telemetry, log) datang TERUS-MENERUS & laju — SQS sesuai untuk task discrete tapi tak direka untuk replay atau ramai consumer baca aliran SAMA. Kinesis = paip streaming: tampung jutaan rekod/saat, simpan sekejap (retention) supaya BANYAK consumer boleh baca & main semula (replay). Data Streams bila kau nak proses sendiri (code, real-time, replay); Firehose bila kau cuma nak HANTAR aliran ke store (S3/Redshift) tanpa kod. Tujuan: ingest & proses data streaming berskala besar.

Apa Dia

Kinesis Data Streams (KDS): real-time, data dalam shards, custom consumers baca dengrn code (Lambda/KCL). Retention default 24 jam, boleh extend sampai 365 hari. Kinesis Data Firehose: near-real-time (buffer ~60s/MB), fully managed, ZERO code — auto-deliver ke S3, Redshift, OpenSearch, Splunk, boleh transform guna Lambda.

Streaming pipeline anatomy

Producers

IoT · app · logs

Shard 1

Shard 2

Shard 3

Consumers

Lambda / KCL

Data masuk shards by partition key. Throughput = bilangan shards (1 shard = 1MB/s in, 2MB/s out). Retention 24h→365d → consumers boleh replay. Firehose ganti consumers ni dengan auto-deliver no-code.

Pilih ahli keluarga Kinesis (decision tree)

Rendering diagram…

Nota: "Kinesis Data Analytics" dah ditukar nama jadi Amazon Managed Service for Apache Flink — soalan lama mungkin masih guna nama lama. 4 ahli: Data Streams (real-time + code), Firehose (auto-deliver no code), Managed Flink (proses/analisa stream), Video Streams (video).

Analogi Belt Sushi vs Hos Bomba — Streams vs Firehose

Rendering diagram…

Data Streams = belt sushi (kaiten): pinggan (record) lalu atas belt, RAMAI pelanggan (consumers) boleh ambil & proses ikut cara sendiri guna code, belt pusing simpan sekejap (retention 24j–365hari) jadi boleh ambil balik (replay) — kau yang atur berapa lorong belt (shards). Firehose = hos bomba: air (data) terus pancut ke kolam (S3/Redshift/OpenSearch/Splunk) automatik tanpa sesiapa pegang gelas (no code, fully managed), TAPI kena tunggu tong kumpul dulu (buffer ~60s) jadi near-real-time, dan tiada simpanan untuk replay. INGAT exam: "custom real-time + replay + ramai consumer" → Streams. "Just deliver ke store, no code" → Firehose.

Data Streams vs Firehose

Aspect	Kinesis Data Streams	Kinesis Data Firehose
Latency	Real-time (~200ms)	Near-real-time (min ~60s buffer)
Management	You manage shards + consumers	🟢 Fully managed, serverless
Consumers	Custom code (Lambda, KCL apps)	Fixed targets: S3, Redshift, OpenSearch, Splunk
Storage / replay	Retention 24h → 365 days, replayable	No storage — delivers then gone
Scaling	Provision/adjust shards	Auto-scales

Ingat: "Custom real-time processing / replay / multiple apps read same stream" → Data Streams. "Just deliver streaming data to a store, no code" → Firehose.

⚡ Quick Sifir — hafal ni

▪Data Streams = real-time (~200ms) + code (Lambda/KCL) + replay + ramai consumer
▪Firehose = near-real-time (buffer ~60s) + ZERO code + auto-deliver ke S3/Redshift/OpenSearch/Splunk
▪Firehose TIADA replay/storage (deliver lepas tu hilang). Streams retention 24j→365hari
▪Streams: kau urus shards (1 shard = 1MB/s in, 2MB/s out). Firehose auto-scale
▪Transform/analisa stream guna SQL/Flink → Managed Service for Apache Flink (dulu Kinesis Data Analytics)
▪Stream VIDEO (CCTV/webcam) untuk playback/ML → Kinesis Video Streams (KVS), bukan Data Streams
▪Bukan streaming (task discrete, decouple) → SQS, bukan Kinesis

💡 Exam Scenario

"Real-time, sub-second, multiple consumers, replay data" → Data Streams (shards + retention up to 365 days). "Load streaming data ke S3/Redshift/OpenSearch with no servers and no code" → Firehose. "Analisa/transform streaming data guna SQL atau Apache Flink real-time" → Managed Service for Apache Flink (bekas Kinesis Data Analytics).

🪤 Perangkap Soalan

Q: Pasukan cuma nak muatkan log streaming ke S3 dan Redshift untuk analisa, tanpa urus server atau tulis kod consumer. Servis mana?

⚠ Umpan: Kinesis Data Streams + Lambda consumer yang tulis ke S3/Redshift. Nampak betul sebab "Kinesis untuk streaming".

✓ Betul: Kinesis Data Firehose. Ia fully managed, ZERO code, auto-deliver terus ke S3/Redshift/OpenSearch/Splunk (boleh transform guna Lambda kalau perlu). Data Streams perlukan kau urus shards + tulis consumer. Keyword "just load/deliver streaming data, no code, no servers" → Firehose, bukan Data Streams.

Q: Berbilang aplikasi berbeza perlu membaca aliran data SAMA secara real-time, dan boleh main semula (replay) data sehingga beberapa hari lalu untuk pemprosesan semula. Servis mana?

⚠ Umpan: SQS — letak mesej dalam queue dan biar setiap app baca. Nampak betul sebab SQS pun "hantar mesej antara komponen".

✓ Betul: Kinesis Data Streams. SQS: satu mesej diproses oleh SATU consumer lepas tu hilang (tiada replay, tiada banyak consumer baca rekod sama). Streams simpan rekod (retention sampai 365 hari) supaya banyak consumer baca & replay. Keyword "multiple consumers same stream + replay + real-time" → Data Streams, bukan SQS.

Guna Bila

Ingest & process real-time streaming data (logs, clickstream, IoT, metrics)

real-timestreamingdata pipelineanalyticsData StreamsFirehoseshardsretentionclickstreamIoTreplayserverless deliveryKinesis Video StreamsKVSvideo streamCCTVManaged Service for Apache FlinkKinesis Data Analytics

📎 Change data retention period

D3 · High-Performing

Kinesis Video Streams

Amazon Kinesis Video Streams (KVS)

"Paip VIDEO — bukan paip data. CCTV/drone/doorbell masuk cloud. Dua mod: simpan+playback ATAU WebRTC dua-hala"

🎯 Sebab Apa Wujud

Wujud sebab video itu BEZA dengan data text. Kalau kau cuba paksa feed CCTV masuk Kinesis Data Streams (yang direka untuk JSON/log/telemetry kecil), kau kena handle sendiri fragmentation, buffering, timestamp sync, encoding, playback protocol (HLS), TURN/STUN untuk NAT traversal — pening + mahal. KVS buang semua sakit kepala tu: device cuma kena push frame (guna Producer SDK / GStreamer kvssink / RTSP), AWS urus storage tahan lama, time-indexing, encryption, dan playback. Untuk interaktif dua-hala (baby monitor, doorbell sembang balik), WebRTC mode bagi peer-to-peer real-time tanpa kau bina sendiri media-relay server.

Apa Dia

Bayangkan macam YouTube Live / TikTok Live tapi untuk APP kau sendiri: KVS adalah paip yang sambut feed video live dari banyak sumber (CCTV, webcam, drone, dashcam, video doorbell), simpan elok-elok dalam cloud (encrypted at rest), index ikut masa (timestamp), pastu app kau boleh tonton live ATAU main semula rakaman lama. Dua mod: (1) **KVS classic** = ingest → durable storage → playback (HLS/DASH) + feed ke ML (Rekognition Video / SageMaker); (2) **KVS with WebRTC** = live dua-hala ultra-low-latency peer-to-peer (macam video call) — contoh video doorbell yang kau boleh cakap balik.

KVS pipeline anatomy

Devices

CCTV · drone · doorbell

Producer SDK

kvssink / RTSP

KVS

ingest · store · time-index

Playback

HLS / DASH

Rekognition / SageMaker

Device push frame (Producer SDK / GStreamer kvssink / RTSP) → KVS ingest, store (encrypted, time-indexed), serah ke consumer: playback live/lama (HLS/DASH/GetMedia) ATAU ML real-time (Rekognition Video). WebRTC mode = laluan peer-to-peer terus, langkau storage, untuk interaktif dua-hala.

KVS classic vs WebRTC vs Data Streams (decision tree)

Rendering diagram…

Pertama tapis MEDIA vs data biasa: video/audio/thermal → KVS; text/log/telemetry → Data Streams. Dalam KVS, tanya perlu dua-hala ke tak: satu-hala (rakam/tonton/ML) → classic; dua-hala interaktif latency rendah → WebRTC. INGAT exam: "video + camera" = KVS; "two-way live" = WebRTC.

Analogi: CCTV Rumah vs Video Call

Rendering diagram…

KVS classic = macam CCTV / Ring doorbell yang rakam masuk cloud: satu-hala, simpan, tonton live atau main semula, boleh suruh AI (Rekognition) tengokkan untuk kau. KVS WebRTC = macam video call WhatsApp/Google Meet: dua-hala, peer-to-peer, latency rendah, kedua-dua pihak cakap & dengar serentak. INGAT exam: "rakam/playback/analisa video" → classic; "two-way interactive call" → WebRTC.

KVS classic vs KVS with WebRTC

Aspect	KVS classic	KVS with WebRTC
Arah	One-way (device → cloud → viewer)	🟢 Two-way / peer-to-peer interactive
Latency	Detik (HLS/DASH buffer)	🟢 Ultra-low (real-time human interaction)
Storage	🟢 Durable, time-indexed, retention boleh set	Tiada — laluan media live je
Playback rakaman lama	🟢 Ya (GetMedia / HLS / DASH)	❌ Live sahaja
ML integration	🟢 Rekognition Video / SageMaker	Atas peer (tak melalui storage)
Guna untuk	CCTV rakam, dashcam, video analytics	Video doorbell sembang balik, baby monitor, telehealth

Ingat: Nak SIMPAN + playback + ML atas video → classic. Nak DUA-HALA real-time latency rendah (video call style) → WebRTC. INGAT: "two-way / interactive / talk back" = WebRTC.

Kinesis Video Streams vs Kinesis Data Streams

Aspect	Kinesis Video Streams (KVS)	Kinesis Data Streams (KDS)
Data type	🎥 Time-encoded MEDIA: video, audio, thermal, RADAR/LIDAR	📊 Rekod data: JSON, log, clickstream, telemetry
Sumber tipikal	CCTV, drone, dashcam, video doorbell, webcam	App, IoT sensor, log agent
Cara hantar	Producer SDK / GStreamer kvssink / RTSP	PutRecord / KPL / agent
Consumer	HLS/DASH playback, GetMedia, Rekognition Video	Lambda / KCL custom code
Salah guna	❌ Jangan paksa telemetry text masuk sini	❌ Jangan paksa frame video masuk sini

Ingat: Discriminator paling penting di exam: perkataan "VIDEO / camera / CCTV / media" → KVS. "log / clickstream / telemetry / JSON record" → Data Streams. Dua-dua nama ada "Kinesis" + "Streams" — itu umpan.

⚡ Quick Sifir — hafal ni

▪KVS = VIDEO/audio stream (CCTV, drone, dashcam, doorbell). BUKAN Kinesis Data Streams (itu text/JSON/log)
▪Soalan sebut "video", "camera", "CCTV", "live media", "playback rakaman" → Kinesis Video Streams
▪Real-time face/object detection atas video live → KVS + Rekognition Video (BUKAN Data Streams)
▪Dua-hala / two-way / interactive (video call, doorbell sembang balik, baby monitor) → KVS with WebRTC
▪WebRTC = peer-to-peer ultra-low latency + pakai signaling channel + STUN/TURN (NAT traversal)
▪Device hantar video guna Producer SDK / GStreamer kvssink / RTSP. Playback guna HLS / DASH / GetMedia
▪Durable storage retention boleh set (encrypted at rest, time-indexed by producer + ingest timestamp)

💡 Exam Scenario

"Ingest live video dari ribuan kamera/CCTV/drone untuk simpan & analisa" → Kinesis Video Streams. "Real-time facial / object recognition atas video stream" → KVS + Rekognition Video. "Two-way / interactive live video atau audio (video doorbell, baby monitor, telehealth, video chat)" → KVS with WebRTC. "Telemetry/log/JSON streaming" → Kinesis Data Streams (BUKAN KVS).

🪤 Perangkap Soalan

Q: Syarikat nak ingest live video dari beribu CCTV kedai untuk buat real-time facial recognition (kesan suspek). Servis apa untuk ingest video tu?

⚠ Umpan: Kinesis Data Streams — sangka semua "Kinesis = streaming jadi guna Data Streams", pastu pipe ke Rekognition.

✓ Betul: Kinesis Video Streams (KVS) + Rekognition Video. Kinesis Data Streams cuma sambut rekod data text/JSON kecil (clickstream, log, telemetry) — ia TAK direka untuk frame video. Keyword "live video / camera / CCTV / facial recognition on video" → KVS, bukan Data Streams.

Q: Video doorbell perlu biar tuan rumah tengok LIVE siapa di pintu dan BERCAKAP balik (two-way audio/video) dengan latency paling rendah. Pilih?

⚠ Umpan: Kinesis Video Streams classic (ingest + playback HLS) — nampak betul sebab "video doorbell = video stream".

✓ Betul: Kinesis Video Streams with WebRTC. Classic ingest→storage→playback ada latency (HLS buffer beberapa saat) dan satu-hala. Two-way + ultra-low-latency + peer-to-peer = WebRTC mode (signaling channel + STUN/TURN). Keyword "two-way / interactive / talk back / lowest latency live" → WebRTC.

Q: IoT sensor hantar data suhu & getaran (telemetry kecil) setiap saat untuk analisa real-time. Kinesis yang mana?

⚠ Umpan: Kinesis Video Streams — nampak "device streaming" jadi sangka KVS handle semua IoT.

✓ Betul: Kinesis Data Streams (atau Firehose kalau cuma nak deliver ke S3). KVS HANYA untuk time-encoded MEDIA (video, audio, thermal, RADAR/LIDAR depth). Telemetry text/numerik biasa → Data Streams. Keyword "video/audio/media" = KVS; "telemetry/log/JSON" = Data Streams.

🧠 Cara Mudah Ingat

→Producer (hantar masuk): Producer SDK (C/C++/Java/Android), GStreamer kvssink plugin, atau RTSP dari kamera rangkaian. Source-agnostic.
→Consumer (ambil keluar): HLS / MPEG-DASH untuk playback dalam browser/player, atau GetMedia / GetMediaForFragmentList untuk frame-by-frame.
→Fragment = unit asas KVS: satu jujukan frame media yang lengkap, ada fragment number + producer/server timestamp. Time-indexing guna timestamp ni.
→WebRTC mode pakai signaling channel (bukan video stream) untuk peer jumpa satu sama lain, pastu STUN/TURN tembusi NAT/firewall untuk sambungan peer-to-peer.
→Integrasi ML: KVS + Rekognition Video = real-time face/object detection (CCTV pengesanan). Untuk model sendiri → consume ke SageMaker.
→PRICING (us-east-1, approx): classic — Data Ingested ~$0.0085/GB, Data Consumed ~$0.0085/GB, Data Stored ~$0.023/GB-month (durable, encrypted). Tiada free tier. WebRTC dicaj ikut bilangan signaling message + minit streaming TURN (relay bila peer-to-peer langsung gagal). pricing

Guna Bila

Ingest, simpan, playback & proses VIDEO/audio live dari beribu kamera/IoT device (CCTV, drone, dashcam, video doorbell) untuk ML/playback

Kinesis Video StreamsKVSvideo streamCCTVcameradronedashcamvideo doorbellbaby monitorWebRTCtwo-waypeer-to-peersignaling channelSTUNTURNHLSDASHRTSPGStreamerkvssinkfragmentRekognition Videotime-encoded datamedia streamlive videoplaybacktelehealthpricing

📎 What is Amazon Kinesis Video Streams?📎 What is KVS with WebRTC?

D3 · High-Performing

API Gateway

Amazon API Gateway

"Pintu masuk untuk API — REST / HTTP / WebSocket"

🎯 Sebab Apa Wujud

API Gateway wujud sebab kalau setiap backend (Lambda/server) kena uruskan sendiri auth, throttling, caching, request validation, dan rate-limit = banyak code berulang + tak konsisten. API Gateway jadi 'pintu masuk' tunggal yang handle semua benda repetitif tu, backend fokus business logic je. Ia juga lindung backend dari traffic spike (429 throttle) supaya tak pengsan.

Apa Dia

Mencipta, mengurus dan mendedahkan API pada mana-mana skala. Handle auth, throttling, caching, request validation, dan integrate ke Lambda / HTTP backend / VPC resources.

Contoh Guna

Frontend → API Gateway → Lambda → DynamoDB

REST vs HTTP vs WebSocket

REST API → full features: API keys + usage plans (per-client throttling), request validation, AWS WAF, resource policies, private endpoint, endpoint types edge-optimized/regional/private

HTTP API → minimal features, ~70% lebih murah, lower latency, JWT (OIDC/OAuth2) authorizer, regional sahaja — pilih bila tak perlu REST extras

WebSocket API → bidirectional real-time (chat, games, trading, live dashboard) — server push ke client

Serverless API anatomy

Client

web / mobile

API Gateway

auth · throttle · cache

Lambda

business logic

DynamoDB

data

API Gateway = pintu masuk: handle auth (Cognito/IAM/Lambda authorizer), throttling (429 bila exceed), caching, request validation — backend (Lambda) fokus logic je.

Decision tree: REST vs HTTP vs WebSocket

Rendering diagram…

Mula dengan: server perlu push ke client tak? Ya → WebSocket. Tak → kalau perlu API keys/WAF/request validation/private endpoint → REST; kalau tak (cuma proxy ringkas ke Lambda) → HTTP API (lebih murah + laju). INGAT exam: HTTP = default murah; REST = bila perlu extras; WebSocket = real-time dua-arah.

REST vs HTTP vs WebSocket API

Aspect	REST API	HTTP API	WebSocket API
Model	Request-response	Request-response	🟢 Bidirectional (server push)
Cost	Paling mahal	🟢 ~70% lebih murah	Per-message + connection
Latency	Higher	🟢 Lower	Real-time
API keys + usage plans	🟢 Ya	❌ Tak	❌ Tak
AWS WAF	🟢 Ya	❌ Tak	❌ Tak
Request validation	🟢 Ya	❌ Tak	❌ Tak
Private endpoint (VPC)	🟢 Ya	❌ (regional je)	❌
Authorizer	IAM / Cognito / Lambda	JWT (OIDC/OAuth2) + IAM/Lambda	IAM / Lambda

Ingat: Real-time two-way push → WebSocket. Simple & murah serverless proxy → HTTP API. Perlu API keys / usage plans / WAF / request validation / private endpoint → REST API. INGAT exam: "low-cost simple proxy" → HTTP; "API keys/WAF/private VPC" → REST; "real-time push/bidirectional" → WebSocket.

⚡ Quick Sifir — hafal ni

▪3 jenis: REST (full features) · HTTP (~70% murah, lower latency) · WebSocket (real-time 2-way)
▪API keys + usage plans + WAF + request validation = REST SAHAJA
▪HTTP API tambah JWT (OIDC/OAuth2) authorizer; REST guna IAM/Cognito/Lambda authorizer
▪Throttling exceed → 429 Too Many Requests (lindung backend)
▪Endpoint types REST: Edge-optimized (default) · Regional · Private (VPC only)
▪Mapping Templates (VTL) = transform request/response tanpa ubah backend
▪Caching at stage level; cache key boleh include query params
▪API Gateway = SERVERLESS (no server, auto-scale, bayar per request) — pasangan emas dengan Lambda

💡 Exam Scenario

Real-time multiplayer game / chat → WebSocket API (server boleh push ke client, two-way). Simple low-cost serverless proxy ke Lambda tanpa API keys/WAF → HTTP API (~70% lebih murah, lower latency). Enterprise API perlu API keys, usage plans, request validation, WAF, atau private endpoint → REST API.

🪤 Perangkap Soalan

Q: Real-time multiplayer game perlu server PUSH update ke client (two-way). API type mana?

⚠ Umpan: REST API dengan polling — sangka client boleh poll cepat-cepat.

✓ Betul: WebSocket API. REST/HTTP = request-response sahaja, server tak boleh push. Keyword: 'real-time' + 'bidirectional' + 'push' → WebSocket.

Q: Backend upgrade tukar format response → break legacy clients. Fix tanpa ubah backend code?

⚠ Umpan: Tambah versioning ke backend atau ubah Lambda — sangka kena patch backend.

✓ Betul: Mapping Templates (VTL) di API Gateway untuk reshape response ikut format lama. Backend tak disentuh. Keyword: 'response format change' + 'without modifying backend'.

Q: Nak serverless API proxy ke Lambda yang paling murah & latency rendah, tak perlu API keys/WAF. Pilih?

⚠ Umpan: REST API — anggap REST = pilihan default/lengkap.

✓ Betul: HTTP API (~70% lebih murah, lower latency). REST hanya bila perlu API keys/usage plans/WAF/private endpoint. Keyword: 'low-cost' + 'simple proxy' → HTTP API.

🧠 Cara Mudah Ingat

→REST vs HTTP API: REST = API keys, per-client throttling (usage plans), request validation, AWS WAF, resource policies, private endpoints, edge-optimized/regional/private. HTTP API = minimal, ~70% murah, lower latency, regional sahaja, JWT authorizer — pilih bila simple proxy.
→WebSocket API: untuk bidirectional / real-time — server boleh push message ke client (chat, multiplayer game, trading platform, live dashboard). REST/HTTP = request-response sahaja.
→Authorizers: IAM (SigV4), Amazon Cognito user pools, Lambda authorizer (TOKEN atau REQUEST — custom auth via bearer token/OAuth/SAML, return IAM policy). HTTP API tambah JWT authorizer (OIDC/OAuth2). Dua-dua support IAM + Lambda authorizer.
→Throttling: account-level + per-method + per-client (usage plans + API keys, REST sahaja). Exceed → 429 Too Many Requests. Protect backend dari traffic spikes.
→Endpoint types (REST): Edge-optimized (default, via CloudFront edge — global clients), Regional (client dalam region sama / lower in-region latency), Private (access dari dalam VPC sahaja via interface endpoint).
→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.
→Logging 2 jenis: EXECUTION logging (CloudWatch) = tangkap request & response PAYLOADS + error traces untuk debug "apa jadi". ACCESS logging = rekod SIAPA akses API + method (ke Kinesis Data Firehose/S3/CloudWatch) macam ALB access log. CloudTrail = audit API call AWS, BUKAN payload request app. Exam: "log request & response payloads + error traces" → CloudWatch EXECUTION logging (bukan CloudTrail, bukan access logging).
→OpenAPI (Swagger) import: tulis API blueprint guna OpenAPI YAML/JSON → import ke API Gateway → auto-provision SEMUA endpoints ikut blueprint. OpenAPI = spec/blueprint (resipi); API Gateway = service yang jalankan (restoran). Exam: "standardize API documentation + build API from blueprint / import definition" → import OpenAPI definition ke API Gateway.

Guna Bila

Manage & expose REST, HTTP, dan WebSocket APIs

REST APIHTTP APIWebSocketreal-timebidirectionalAPI managementthrottlingusage plansAPI keysrequest validationAWS WAFJWT authorizerCognitoLambda authorizerIAM authorizeredge-optimizedregional endpointprivate endpointmapping templatesbackward compatibilityVTLresponse transformationcache keyCORSexecution loggingaccess loggingrequest response payloadsVPC Linkcross-account LambdaOpenAPISwaggerimport definitionserverless

📎 Choose between REST APIs and HTTP APIs 📎 WebSocket APIs

D3 · High-Performing

EventBridge

Amazon EventBridge

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

🎯 Sebab Apa Wujud

EventBridge wujud sebab nak react automatik bila SESUATU berlaku dalam AWS (EC2 stop, S3 upload, SaaS event) tanpa code 'polling' yang tunggu-tunggu. Ia event bus pintar: route event ke target betul berdasarkan ISI event (content-based filter), bukan broadcast semua macam SNS. Ganti CloudWatch Events lama, dan bagi kau decouple services + schedule cron tanpa server.

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.

SQS vs SNS vs EventBridge — 3 yang selalu keliru

Aspect	SQS	SNS	EventBridge
Model	Queue (pull)	Pub/Sub (push)	Event bus (push, rule-based)
Consumer	1 queue, ramai poller kongsi	Ramai subscriber dapat SAMA salinan	Target ikut event pattern
Routing pintar	❌ Tiada	❌ Tiada (broadcast semua)	🟢 Content-based (filter by field)
Buffer / retry	🟢 Simpan msg (4–14 hari), DLQ	Tiada storage (retry + DLQ)	Retry + archive/replay
Sumber	App kau	App kau	🟢 90+ AWS service + SaaS + custom
Guna bila	Decouple + buffer kerja, proses ikut kadar sendiri	Fan-out satu mesej ke ramai (SNS→banyak SQS)	React ke event AWS, route by content, jadual cron

Ingat: Buffer + proses ikut kadar sendiri → SQS. Hantar SATU mesej ke RAMAI serentak → SNS. Route ikut ISI event / event AWS / SaaS / jadual → EventBridge. Fan-out klasik = SNS → banyak SQS. EventBridge latency lebih tinggi (~0.5s) tapi paling pintar.

⚡ Quick Sifir — hafal ni

▪Content-based routing (filter by event field) — SNS tak boleh, broadcast je
▪Sumber: 90+ AWS service + SaaS partner + custom app event
▪Archive & Replay event (debug/reprocess); SNS tiada
▪EventBridge Scheduler = cron/rate, timezone-aware, ganti CloudWatch Events schedule
▪EventBridge Pipes = point-to-point source→target dengan filter/enrich, no Lambda glue
▪Latency lebih tinggi (~0.5s) dari SNS tapi paling pintar

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

🪤 Perangkap Soalan

Q: Nak route event ke target BERBEZA berdasarkan content/field dalam event. Guna apa?

⚠ Umpan: SNS dengan banyak subscriber — sangka SNS boleh pilih siapa terima.

✓ Betul: EventBridge (content-based routing via event pattern). SNS broadcast SAMA mesej ke semua subscriber, tak boleh filter by content. Keyword: 'route based on content' → EventBridge.

Q: EC2 instance terminate → auto-trigger Lambda untuk cleanup. Service mana?

⚠ Umpan: SNS notification ke Lambda — sangka SNS yang detect state change.

✓ Betul: EventBridge rule (detect EC2 state change event → trigger Lambda). SNS tak detect AWS service events. Keyword: 'AWS service state change' → EventBridge.

🧠 Cara Mudah Ingat

→Schema Registry: EventBridge auto-discovers event schemas dari event bus. Boleh generate code bindings (Java, Python, TypeScript) dari schema — speeds up development
→Archive & Replay: archive events dari event bus, replay later untuk debugging atau reprocessing. Useful bila downstream service was down
→EventBridge Pipes: point-to-point integration — connect source (SQS, Kinesis, DynamoDB Streams) directly to target dengan optional filtering, enrichment, and transformation. Simpler than writing Lambda glue code
→EventBridge vs SNS: EventBridge = content-based routing (route by event pattern/field values), schema discovery, SaaS integration, archive/replay. SNS = simple fan-out to many subscribers, higher throughput
→EventBridge Scheduler: one-time or recurring schedules (cron/rate). Replaces CloudWatch Events scheduled rules. Supports >14,000 targets, timezone-aware, flexible time windows
→Custom event bus: isolate events per application/team. Default event bus receives AWS service events. Custom bus for your app events + SaaS partner events
→Exam: "route events based on content to different targets" → EventBridge. "Simple broadcast to all subscribers" → SNS

Guna Bila

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

event busevent-drivencron schedulerule-based routingdecoupleSaaS integrationCloudWatch Eventsschema registryarchive replayEventBridge PipesEventBridge Scheduler

📎 EventBridge — what is it (event bus & rules)📎 EventBridge Scheduler

D3 · High-Performing

Step Functions

AWS Step Functions

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

🎯 Sebab Apa Wujud

Step Functions wujud sebab chain banyak Lambda/service manual (Lambda panggil Lambda panggil Lambda) jadi mimpi ngeri bila kena handle retry, timeout, branching, dan error pada SETIAP langkah — code jadi spaghetti + susah debug. Step Functions jadi 'flowchart yang run sendiri': retry/catch/branch terbina dalam, visual console tunjuk state tiap langkah. Buang glue code rapuh + bagi resilience automatik.

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.

Order workflow (state machine)

Validate

order

Charge Card

retry on fail

Notify

warehouse

Send Email

confirm

Tiap step ada built-in retry + timeout + branch (Choice state). Kalau step gagal → catch & route ke fallback, bukan crash whole flow. Visual console tunjuk state setiap step.

Standard vs Express — pilih jenis workflow (decision tree)

Rendering diagram…

Soalan pertama exam = tempoh + idempotency. >5 min ATAU non-idempotent (payment, start cluster) → Standard (exactly-once, audit penuh). ≤5 min + idempotent + volume tinggi (IoT/streaming) → Express (at-least-once, bayar per execution). INGAT: human-approval/callback (.waitForTaskToken), .sync job-run, Distributed Map & Activities → STANDARD SAHAJA.

Analogi — Pos Berdaftar vs Blast SMS

Rendering diagram…

Standard = pos berdaftar: setiap langkah ada resit (execution history/audit), dijamin exactly-once (tak hantar 2 kali) → sesuai bayar duit, start EMR cluster, workflow berhari/berbulan. Express = blast SMS: laju + murah + volume besar, tapi boleh sampai 2 kali (at-least-once) → sesuai IoT ingest & streaming yang idempotent. INGAT exam: "non-idempotent / payment / long-running / audit trail" → Standard; "high-volume event / IoT / streaming, short" → Express.

Standard vs Express Workflow (discriminator utama exam)

Ciri	Standard	Express
Tempoh max	🟢 1 tahun	5 minit
Execution semantics	Exactly-once	Async = at-least-once · Sync = at-most-once
Sesuai untuk	Non-idempotent (bayar, start EMR), long-running, audit	High-volume event: IoT ingest, streaming, mobile backend (idempotent)
Harga	Per state transition	Per execution + tempoh + memory
Execution history	🟢 Penuh (API 90 hari) + visual console	CloudWatch Logs sahaja
Callback (.waitForTaskToken) & .sync job-run	🟢 Ya	❌ Tidak
Distributed Map & Activities	🟢 Ya	❌ Tidak

Ingat: Long-running / non-idempotent / perlu audit / human-approval-callback / Distributed Map → Standard. Short (<5 min) + high-volume + idempotent (IoT/streaming) → Express. Jenis workflow IMMUTABLE — tak boleh tukar lepas create.

Step Functions vs Lambda-sahaja vs SWF — bila orchestrate?

Situasi	Pilih
Multi-step merentas banyak service, perlu retry/branch/visual	🟢 Step Functions
Satu fungsi ringkas, tiada coordination antara langkah	Lambda sahaja
Perlu visual console tengok state setiap langkah	Step Functions (BUKAN SQS/SWF)
Legacy / perlu external "deciders" & "workers" sendiri	SWF (lama — elak untuk projek baru)

Ingat: Step Functions = orchestrator moden (state machine + visual + built-in retry/catch). Lambda-sahaja kalau takde langkah nak coordinate. SWF legacy — Step Functions ganti dia.

Step Functions vs SQS vs Batch vs Glue — jangan keliru "orchestrate"

Service	Sebenarnya buat apa	Keyword exam
🟢 Step Functions	ORCHESTRATE workflow berlangkah (visual + track state tiap step + retry/catch terbina)	"coordinate steps visually / track each step / state machine / avoid custom failure logic"
SQS	DECOUPLE & buffer mesej antara service (queue je — takde orchestrate/visual/state)	"decouple / buffer burst / async queue"
AWS Batch	Jalankan BATCH compute jobs ramai (HPC, render, simulation)	"batch jobs / array of compute / HPC"
AWS Glue	ETL — extract/transform/load data (serverless Spark + Data Catalog)	"ETL / transform data / data catalog"

Ingat: Orchestrate langkah business secara visual + track setiap step + elak tulis custom state/failure logic → Step Functions. Hantar mesej decouple → SQS. Jalankan banyak compute job → Batch. Transform data (ETL) → Glue. Soalan "Lambda+SNS dah kompleks, nak orchestrate visual & maintainable" = Step Functions, BUKAN SQS/Batch/Glue.

⚡ Quick Sifir — hafal ni

▪Standard = max 1 tahun, exactly-once, audit penuh; Express = max 5 min, at-least-once, murah
▪Non-idempotent (payment, start EMR) → Standard; high-volume idempotent (IoT/stream) → Express
▪Callback (.waitForTaskToken), .sync job-run, Distributed Map, Activities → STANDARD SAHAJA
▪Workflow type IMMUTABLE — tak boleh tukar Standard↔Express lepas create
▪Choice=branch · Parallel=serentak · Map=loop array · Distributed Map=dataset besar
▪Error handling ASL: Retry (backoff) + Catch (route ke fallback)

💡 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). "Payment / non-idempotent / berjam-jam / perlu audit trail penuh" → Standard. "IoT ingestion / streaming transform / high-volume, idempotent, <5 min" → Express. "Workflow kena tunggu kelulusan manusia dulu sebelum sambung" → Standard + Callback pattern (.waitForTaskToken).

🪤 Perangkap Soalan

Q: Workflow charge payment + start EMR cluster, kena exactly-once + audit trail penuh. Standard atau Express?

⚠ Umpan: Express — sebab 'laju & murah', anggap workflow pendek.

✓ Betul: Standard. Express = at-least-once (boleh run 2x → double charge!) + max 5 min. Non-idempotent/payment/audit → Standard. Keyword: 'payment' + 'exactly-once' + 'audit'.

Q: Workflow kena PAUSE tunggu kelulusan manusia dulu sebelum sambung. Macam mana?

⚠ Umpan: Express workflow dengan wait state — sangka Express boleh tunggu callback.

✓ Betul: Standard + Callback pattern (.waitForTaskToken). Express TAK support .waitForTaskToken. Keyword: 'human approval' + 'wait for callback' → Standard.

Q: App serverless guna Lambda + SNS coordinate order processing (notify restaurant, accept/reject). Dah kompleks; team nak (1) orchestrate semua step secara VISUAL & maintainable, (2) track status setiap step & event, (3) ELAK tulis custom logic untuk failure tracking / state transition. Pilih: (A) AWS Batch, (B) Step Functions, (C) SQS, (D) Glue.

⚠ Umpan: C (SQS) menipu sebab dah ada SNS → orang sambung 'tambah queue'. TAPI SQS cuma decouple/buffer mesej — dia TAK orchestrate langkah, takde visual console, takde state tracking; kau kena tulis sendiri logic transition. A (Batch) = jalankan batch compute jobs (HPC/render), bukan coordinate workflow. D (Glue) = ETL transform data, bukan orchestrate business steps.

✓ Betul: B — Step Functions. State machine = visual workflow + track state tiap step automatik + retry/catch terbina dalam (tak payah tulis custom failure/state logic). Keyword: 'orchestrate steps visually + track each step + avoid custom state/failure logic' → Step Functions. INGAT: SQS = decouple (bukan orchestrate); Batch = batch compute; Glue = ETL.

🧠 Cara Mudah Ingat

→Standard vs Express adalah discriminator #1: ingat tempoh (1 tahun vs 5 minit) + idempotency. Non-idempotent (charge payment, start EMR cluster) → Standard (exactly-once). High-volume idempotent (IoT, streaming) → Express (at-least-once).
→Workflow type IMMUTABLE — tak boleh tukar Standard↔Express selepas state machine dicipta. Kena buat state machine baru.
→Express ada 2 rasa: Synchronous Express = tunggu & pulang result (sesuai orchestrate API backend / API Gateway integration); Asynchronous Express = fire-and-forget (sesuai streaming/log ingestion).
→Service integration patterns: Request-Response (default, terus sambung), .sync (Job-run — tunggu job AWS habis, cth EMR/Glue/ECS), .waitForTaskToken (Callback — pause sampai external system/human hantar token balik). .sync & Callback → STANDARD SAHAJA, Express tak support.
→Error handling terbina dalam ASL: Retry (cuba semula dengan backoff), Catch (tangkap error & route ke fallback state). Sebab tu Step Functions menang vs Lambda-chaining manual untuk workflow yang perlu resilience.
→Choice state = branching (if/else ikut input). Parallel state = jalankan beberapa cabang serentak. Map state = ulang langkah atas array. Distributed Map = versi besar Map untuk dataset besar (Standard sahaja).
→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. Standard sahaja.
→"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
→PRICING (us-east-1): Standard = $0.025 per 1,000 state transitions (free tier 4,000 transitions/mo). Express = bayar per execution + duration × memory (model macam Lambda) — murah untuk high-volume short workflows. Standard caj ikut STATE TRANSITION (berapa kali lompat status), BUKAN tempoh menunggu — boleh pause tunggu human approval sampai 1 tahun tanpa caj masa. Exam: "Step Functions Standard bill melonjak sebab jutaan high-volume request" → tukar ke Express Workflow.

Guna Bila

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

workflowstate machineorchestrationretry logicerror handlingLambda orchestrationvisual workflowDistributed Mapparallel processingStandard workflowExpress workflowexactly-onceat-least-onceidempotentcallback patternwaitForTaskTokensync integrationASLAmazon States LanguageChoice stateMap stateActivitiesSWFpricingstate transition pricing

📎 Choosing workflow type (Standard vs Express)📎 Service integration patterns (.sync, .waitForTaskToken)

D3 · High-Performing

Amazon MQ

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

🎯 Sebab Apa Wujud

Amazon MQ wujud sebab banyak app lama (on-prem) dah guna ActiveMQ/RabbitMQ dengan protokol standard (AMQP, MQTT, STOMP, JMS). Kalau nak migrate ke AWS dan tukar ke SQS/SNS = kena rewrite code (API AWS proprietary). Amazon MQ = managed broker yang cakap protokol standard tu, jadi app lama boleh lift-and-shift tanpa ubah code. Ia 'jambatan' untuk legacy, bukan pilihan default.

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.

Amazon MQ — komponen utama

Engine → ActiveMQ atau RabbitMQ (pilih ikut protokol app sedia ada)

Protokol terbuka → AMQP, MQTT, STOMP, OpenWire, WebSocket, JMS — sebab itu app lama boleh sambung tanpa tukar code

Broker → instance yang AWS urus (patching, HA). Bukan serverless macam SQS

Deployment → single-instance (dev/test) atau active/standby multi-AZ (production HA, auto-failover guna EFS)

Queue & Topic → satu broker boleh ada queues (point-to-point) DAN topics (pub/sub) sekali

Analogi — Amazon MQ = adapter palam lama

Rendering diagram…

Kaitkan dengan familiar: app legacy = perkakas berplug lama; Amazon MQ = adapter yang biar ia masuk soket AWS tanpa beli perkakas baru. App baru tak payah adapter — terus SQS/SNS. INGAT exam: "migrate / existing broker / MQTT / AMQP / tanpa tukar code" → Amazon MQ; app baru → SQS/SNS.

Amazon MQ vs SQS + SNS — bila pilih yang mana

Aspect	Amazon MQ	SQS + SNS
Bila guna	🟠 Lift-and-shift app SEDIA ADA	🟢 App cloud-native BARU
Protokol	Terbuka: AMQP, MQTT, STOMP, OpenWire, JMS	API AWS proprietary (SDK sahaja)
Bentuk	Managed broker (instance)	Fully serverless (no broker)
Skala	Terhad ikut saiz broker	🟢 Hampir tanpa had, auto-scale
Kos & urus	Mahal sikit, kena saiz broker	🟢 Bayar ikut guna, no infra

Ingat: "migrate", "existing ActiveMQ/RabbitMQ", "MQTT/AMQP/STOMP", "tanpa tukar code" → Amazon MQ. App baru / nak scale / serverless → SQS + SNS. MQ = jambatan untuk legacy, BUKAN pilihan default.

ActiveMQ vs RabbitMQ — engine mana untuk protokol apa

Aspect	ActiveMQ	RabbitMQ
Protokol	AMQP, MQTT, STOMP, OpenWire, WebSocket	AMQP terutamanya
Pilih bila app guna	MQTT (IoT) / STOMP / OpenWire / JMS	AMQP standard, routing fleksibel
Model	JMS-style queues & topics	Exchange → binding → queue routing

Ingat: App guna MQTT atau STOMP → mesti ActiveMQ engine. App AMQP biasa → mana-mana, RabbitMQ popular untuk routing. Exam jarang masuk dalam, tapi "MQTT" condong ke ActiveMQ.

⚡ Quick Sifir — hafal ni

▪Amazon MQ = MIGRATION/legacy; SQS+SNS = cloud-native app BARU
▪Support protokol terbuka: AMQP, MQTT, STOMP, OpenWire, JMS, WebSocket
▪2 engine: ActiveMQ (banyak protokol) · RabbitMQ (AMQP terutamanya)
▪App guna MQTT/STOMP → mesti engine ActiveMQ
▪Managed BROKER (instance), bukan serverless macam SQS — skala terhad ikut saiz broker
▪Deployment: single-instance (dev) · active/standby multi-AZ (prod HA, guna EFS)

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

🪤 Perangkap Soalan

Q: On-prem app guna ActiveMQ (AMQP), nak migrate ke AWS TANPA ubah code. Service mana?

⚠ Umpan: SQS + SNS — sangka 'messaging di AWS mesti SQS/SNS'.

✓ Betul: Amazon MQ. SQS/SNS guna API proprietary → kena rewrite code. MQ support protokol standard untuk lift-and-shift. Keyword: 'migrate existing' + 'AMQP/MQTT' + 'no code change'.

Q: Bina app messaging cloud-native BARU, perlu auto-scale hampir tanpa had. Amazon MQ?

⚠ Umpan: Amazon MQ — sangka ia general-purpose messaging untuk semua.

✓ Betul: SQS + SNS. MQ = broker instance (skala terhad, mahal sikit). App baru → SQS/SNS serverless. Keyword: 'new app' + 'scale' → SQS/SNS, BUKAN MQ.

🧠 Cara Mudah Ingat

→Amazon MQ vs SQS/SNS: Amazon MQ = lift-and-shift apps yang ALREADY use AMQP/MQTT/STOMP protocols. SQS/SNS = cloud-native new applications (simpler, cheaper, scales better)
→Supports both ActiveMQ and RabbitMQ engines. ActiveMQ supports more protocols (AMQP, MQTT, STOMP, OpenWire, WebSocket). RabbitMQ = AMQP + JMS sahaja. App guna MQTT/STOMP → mesti ActiveMQ engine
→Deployment: single-instance (dev/test) or active/standby (production HA). Active/standby uses EFS for shared storage — automatic failover
→Exam keyword: "migrate", "existing messaging system", "MQTT", "AMQP", "without changing application code" → Amazon MQ. Jangan pilih SQS/SNS untuk migration scenarios

Guna Bila

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

ActiveMQRabbitMQAMQPMQTTlift-and-shiftmessage brokerlegacy migrationopen protocolsSTOMPOpenWireJMSAmazon MQ vs SQSmanaged broker

📎 Amazon MQ — what is it 📎 Amazon MQ — broker engines & protocols

D3 · High-Performing

Kinesis Data Firehose

Amazon Kinesis Data Firehose

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

🎯 Sebab Apa Wujud

Firehose wujud sebab nak load streaming data terus ke destinasi (S3, Redshift, OpenSearch, Splunk) tanpa tulis consumer code sendiri — dengan Kinesis Data Streams kau kena bina + maintain consumer app. Firehose fully managed: ia buffer, optional transform inline (Lambda), dan deliver automatik. Buang kerja bina pipeline delivery — pilih bila kau cuma nak 'pipe data masuk store', bukan real-time processing.

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

⚡ Quick Sifir — hafal ni

▪Firehose = DELIVERY/loading (no consumer code); Data Streams = real-time PROCESSING (tulis consumer)
▪Destinasi: S3, Redshift, OpenSearch, Splunk (managed delivery)
▪Buffer ikut size/time sebelum write (near real-time, ada sikit delay)
▪Inline transform optional guna Lambda sebelum deliver
▪Fully managed, auto-scale — tiada shard nak urus macam Data Streams

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

🪤 Perangkap Soalan

Q: Ingest clickstream data terus ke S3 untuk analytics, tak nak tulis/maintain consumer code. Service?

⚠ Umpan: Kinesis Data Streams — sangka semua streaming mesti Data Streams.

✓ Betul: Kinesis Data Firehose. Firehose auto-deliver ke S3 tanpa consumer code. Data Streams kena bina consumer sendiri. Keyword: 'load to S3' + 'no consumer code' → Firehose.

Q: Real-time fraud detection proses event streaming dengan custom logic + low latency. Firehose?

⚠ Umpan: Firehose dengan Lambda transform — sangka transform = processing.

✓ Betul: Kinesis Data Streams. Real-time processing + custom consumer logic + sub-second → Data Streams. Firehose ada buffer delay (near real-time). Keyword: 'real-time processing' → Data Streams.

🧠 Cara Mudah Ingat

→Buffer hints: size (1-128 MB) ATAU interval (60-900 saat) — mana cukup dulu. Buffer kecil = lebih real-time tapi lebih banyak PUT ke destinasi; buffer besar = lebih jimat tapi lebih lambat
→Inline transform guna Lambda (cth tukar JSON→Parquet untuk Athena). Boleh convert format ke Parquet/ORC tanpa Lambda (built-in)
→Firehose TIADA replay/storage — data deliver lepas tu hilang. Perlu replay / banyak consumer baca aliran sama → Kinesis Data Streams
→PRICING: Firehose = $0.029/GB ingested (per-GB, no shard cost) — bayar ikut data masuk je, tiada caj jam idle. Format conversion + VPC delivery ada caj tambahan. Cost discriminator: tak nak urus shard / bayar bila guna je → Firehose lebih murah dari Data Streams untuk delivery pure.
→Untuk compare penuh Data Streams vs Firehose vs Video Streams + decision tree, lihat card Kinesis (anchor).

Guna Bila

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

delivery streamS3 deliveryRedshiftOpenSearchno consumer codebuffertransform with LambdaParquet conversionpricing

📎 What is Amazon Data Firehose?📎 Firehose data transformation (Lambda)

D3 · High-Performing

AppFlow

AWS AppFlow

"Penyambung SaaS → AWS, tanpa code"

🎯 Sebab Apa Wujud

AppFlow wujud sebab tarik data dari SaaS apps (Salesforce, ServiceNow, Slack) ke AWS biasanya kena tulis custom integration guna API setiap SaaS — leceh + kena maintain bila API berubah. AppFlow = 50+ connector siap, no-code: kau pilih source, mapping, schedule → data mengalir ke S3/Redshift. Buang kerja bina + jaga API integration sendiri.

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.

AppFlow vs DataSync vs Glue — "pindah data" tiga jenis, jangan keliru

Aspect	AppFlow	DataSync	Glue
Sumber data	SaaS API (Salesforce, ServiceNow, Slack, Zendesk)	File/storage protocol (NFS, SMB, HDFS, object)	Data store (S3, RDS, Redshift, JDBC)
Cara kerja	No-code connector + field mapping	No-code agent, sync fail pukal	Code ETL (PySpark/Python) + crawler/catalog
Guna untuk	Tarik data SaaS → AWS (bidirectional)	Migrate/replicate fail on-prem ↔ AWS	Transform data untuk data lake/warehouse
Keyword exam	"SaaS app", "Salesforce", "no custom code"	"NFS/SMB", "file migration", "on-prem share"	"ETL", "transform", "data catalog", "PySpark"

Ingat: Sumber = SaaS app (Salesforce/ServiceNow) → AppFlow. Sumber = fail on-prem (NFS/SMB) → DataSync. Perlu TRANSFORM/ETL untuk data lake → Glue. INGAT exam: padankan ikut JENIS SUMBER, bukan destinasi (semua boleh tuju S3).

⚡ Quick Sifir — hafal ni

▪AppFlow = SaaS API integration (Salesforce, ServiceNow, Slack, Zendesk)
▪DataSync = file/storage protocol (NFS, SMB, HDFS, S3) — BUKAN SaaS
▪Glue = code-based ETL (PySpark/Python) untuk data lake — AppFlow no-code
▪Bidirectional transfer + scheduling + field mapping + filter
▪Destinasi AWS: S3, Redshift, EventBridge

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

🪤 Perangkap Soalan

Q: Sync data Salesforce + ServiceNow ke S3 untuk analytics, tanpa custom development. Service?

⚠ Umpan: AWS Glue — sangka 'data ke S3 = ETL = Glue'.

✓ Betul: AppFlow. Glue = code-based ETL (tulis PySpark). AppFlow = no-code SaaS connector. Keyword: 'SaaS app' (Salesforce/ServiceNow) + 'no code' → AppFlow.

Q: Migrate fail dari on-prem NFS share ke S3. AppFlow?

⚠ Umpan: AppFlow — sangka semua 'transfer ke AWS' guna AppFlow.

✓ Betul: DataSync. AppFlow untuk SaaS API; file protocol (NFS/SMB) → DataSync. Keyword: 'NFS/SMB file migration' → DataSync, BUKAN AppFlow.

🧠 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)
→PRICING: (approx, no free tier)$0.001 per flow run + $0.02 per GB data diproses. Murah untuk sync berjadual; kos naik ikut volume data. Exam: AppFlow bil per-flow-run + per-GB, bukan per jam.

Guna Bila

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

AppFlowSaaS integrationSalesforceServiceNowno-code connectordata transferbidirectionalS3RedshiftDataSyncGluepricing

📎 What is Amazon AppFlow

D3 · High-Performing

AppSync

AWS AppSync

"GraphQL API yang managed — real-time + offline sync"

🎯 Sebab Apa Wujud

AppSync wujud sebab app moden (mobile/web) selalu nak (1) GraphQL — satu query tarik data dari banyak source sekaligus, (2) real-time push update, dan (3) offline sync dengan auto conflict resolution. Bina semua ni sendiri atas API Gateway + WebSocket + DynamoDB = banyak kerja. AppSync managed GraphQL bagi semua tu siap — buang kerja bina resolver, subscription, dan offline sync engine.

Apa Dia

Fully managed GraphQL service. Automatically generates resolvers untuk DynamoDB, Lambda, Aurora, OpenSearch, HTTP. Real-time subscriptions via WebSocket. Offline data sync untuk mobile/web apps (conflict resolution built-in). Combine multiple data sources dalam single GraphQL query.

Contoh Guna

Mobile app perlukan real-time chat + offline support → AppSync GraphQL API. Frontend query satu endpoint, AppSync resolve dari DynamoDB + Lambda + Aurora sekaligus.

AppSync vs API Gateway — dua-dua "managed API front door", beza paradigm

Aspect	AWS AppSync	API Gateway
Paradigm	GraphQL (satu query, tarik apa perlu je)	REST / HTTP / WebSocket
Multi-source query	Ya — satu query resolve dari DynamoDB+Lambda+Aurora sekaligus	Tak — satu endpoint = satu integration (banyak round-trip)
Real-time	Built-in subscriptions (push via WebSocket)	Perlu WebSocket API + manual wiring
Offline sync	Ya (Amplify DataStore + conflict resolution)	Tiada
Guna bila	Mobile/web app, GraphQL, real-time, offline	REST microservices, throttling, API keys, usage plans

Ingat: Keyword "GraphQL / offline sync / conflict resolution / satu query banyak source" → AppSync. Keyword "REST API / HTTP / throttling / API key / usage plan" → API Gateway. Jangan pilih API Gateway WebSocket bila soalan sebut offline sync — itu AppSync je yang ada built-in.

⚡ Quick Sifir — hafal ni

▪AppSync = GraphQL + real-time subscription + offline sync; API Gateway = REST/HTTP/WebSocket
▪Satu query boleh resolve dari MULTIPLE data source (DynamoDB+Lambda+Aurora) sekaligus
▪Real-time = GraphQL subscription over WebSocket (push, no polling)
▪Offline: AppSync + Amplify DataStore; conflict: Optimistic Concurrency / Auto Merge / Custom Lambda
▪Data source: DynamoDB, Aurora, OpenSearch, Lambda, HTTP endpoint
▪Server-side caching optional (kurangkan resolver execution + latency)

💡 Exam Scenario

"Mobile app needs real-time updates and offline data sync with automatic conflict resolution" → AppSync. "REST API for microservices" → API Gateway. AppSync = GraphQL + real-time + offline. API Gateway = REST/WebSocket + throttling + API keys.

🪤 Perangkap Soalan

Q: Mobile app perlu real-time update + offline data sync dengan automatic conflict resolution. Service?

⚠ Umpan: API Gateway WebSocket — sangka WebSocket = real-time = jawapan.

✓ Betul: AppSync. Ia ada offline sync + conflict resolution built-in (via Amplify DataStore); API Gateway tiada. Keyword: 'GraphQL' / 'offline sync' / 'conflict resolution' → AppSync.

Q: Satu query frontend perlu aggregate data dari DynamoDB + Aurora + Lambda sekaligus. Pilih?

⚠ Umpan: API Gateway + banyak REST endpoint — sangka kena panggil banyak endpoint.

✓ Betul: AppSync GraphQL — satu query resolve dari multiple data source. REST kena banyak round-trip. Keyword: 'single query, multiple sources' → AppSync.

🧠 Cara Mudah Ingat

→AppSync vs API Gateway: AppSync = GraphQL, real-time subscriptions, offline sync, multiple data sources in one query. API Gateway = REST/HTTP/WebSocket APIs, throttling, usage plans, API keys
→Data sources: DynamoDB, Aurora, OpenSearch, Lambda, HTTP endpoints, other AWS services. Satu query boleh resolve dari MULTIPLE data sources sekaligus — powerful for aggregation
→Real-time: GraphQL subscriptions over WebSocket — clients get push updates automatically. No polling needed
→Offline + conflict resolution: AppSync + Amplify DataStore = offline-first mobile/web apps. Data sync automatically bila device reconnects. Conflict resolution strategies: Optimistic Concurrency, Auto Merge, Custom Lambda
→Caching: AppSync has server-side caching (optional). Reduces resolver execution and improves latency
→Exam: "GraphQL" or "real-time data sync" or "offline mobile app" → AppSync. Bukan API Gateway (yang untuk REST/HTTP)
→PRICING: (approx)$4.00 per juta query & data-modification operation + $2.00 per juta real-time update + $0.08 per juta connection-minute (subscription). Caching optional (per node-hour). Free tier 12 bulan: 250K query ops + 250K real-time updates/bulan. Exam: bil ikut jumlah operation + connection-time, bukan per jam endpoint.

Guna Bila

Build GraphQL APIs with real-time data sync and offline capability

GraphQLreal-timesubscriptionsWebSocketoffline syncconflict resolutionresolversDynamoDBmultiple data sourcesmobileAmplifyAPI Gatewaypricing

📎 What is AWS AppSync (GraphQL)

D3 · High-Performing

Amplify

AWS Amplify

"Heroku/Vercel-nya AWS — fullstack web/mobile hosting + backend"

🎯 Sebab Apa Wujud

Amplify wujud sebab developer frontend nak deploy fullstack web/mobile app cepat (CI/CD + hosting + auth + API + storage) tanpa pasang infra sendiri (EC2, pipeline, CDN setup). Amplify = 'Vercel/Heroku-nya AWS': connect Git repo → auto build & deploy ke CDN, dan tambah backend (Cognito/AppSync/DynamoDB/S3) secara managed. Buang kerja wiring infra — fokus tulis app.

Apa Dia

Platform untuk build fullstack apps. Amplify Hosting = CI/CD + CDN hosting untuk SSR/SSG web apps (connect Git repo, auto-deploy). Amplify Studio = visual builder untuk backend (auth, data, storage). Backend powered by Cognito (auth), AppSync (API), DynamoDB (data), S3 (storage).

Contoh Guna

React/Next.js app → connect GitHub repo ke Amplify → auto build + deploy ke CDN. Add auth dengan Cognito, API dengan AppSync, storage dengan S3 — semua managed.

Firebase ↔ Amplify — kembar BaaS (kaitkan untuk ingat)

Fungsi app	Google Firebase	AWS Amplify	AWS sebenar di belakang
Login user	Firebase Authentication	Amplify Auth	Amazon Cognito
DB laju (NoSQL)	Firestore / Realtime DB	Amplify Data (GraphQL/REST)	DynamoDB + AppSync
Simpan fail/gambar	Firebase Storage	Amplify Storage	Amazon S3
Host laman web	Firebase Hosting	Amplify Hosting	CloudFront + S3
Run kod serverless	Cloud Functions	Amplify Functions	AWS Lambda

Ingat: Amplify = jawapan AWS kepada Firebase — dua-dua BaaS (Backend-as-a-Service) untuk dev frontend/mobile bina app laju tanpa manage infra. Beza utama: Amplify cuma "wrapper" atas servis AWS sebenar (Cognito/S3/DynamoDB) — kalau app membesar boleh "cabut" Amplify, servis tu kekal hidup & boleh urus manual. Firebase lebih terkunci dalam ekosistem Google. Exam: "developer nak mobile app cepat, Auth + NoSQL, tak nak manage cloud" (bunyi macam Firebase) → pilih Amplify.

⚡ Quick Sifir — hafal ni

▪Amplify = frontend/fullstack (React, Next.js, mobile); Beanstalk = backend server app (Node/Java/Docker)
▪Hosting = Git-based CI/CD (GitHub/GitLab/Bitbucket) + CloudFront CDN + HTTPS auto
▪Support SSR (Next.js/Nuxt), SSG, SPA
▪Backend guna Cognito (auth) + AppSync/API GW (API) + DynamoDB (data) + S3 + Lambda
▪vs S3+CloudFront: Amplify include CI/CD + backend; S3+CF = static hosting je (setup pipeline sendiri)

💡 Exam Scenario

"Developer team wants to quickly deploy a React web app with CI/CD, authentication, and a GraphQL backend without managing infrastructure" → Amplify. Bukan EC2 + manual setup. Bukan Elastic Beanstalk (yang untuk traditional server apps).

🪤 Perangkap Soalan

Q: Team nak deploy React app cepat dengan CI/CD + auth + GraphQL backend tanpa urus infra. Service?

⚠ Umpan: Elastic Beanstalk — sangka 'deploy app = Beanstalk'.

✓ Betul: Amplify. Beanstalk untuk backend server app (Node/Java/Docker), bukan frontend/fullstack JS. Keyword: 'React/Next.js' + 'CI/CD' + 'fullstack' → Amplify.

Q: Host static website paling murah, tak perlu CI/CD atau backend. Amplify?

⚠ Umpan: Amplify — sangka Amplify = cara standard host web.

✓ Betul: S3 + CloudFront. Untuk static murah tanpa pipeline/backend, S3+CF cukup. Amplify bila perlu CI/CD + backend. Keyword: 'static website' + 'cheap' → S3+CloudFront.

🧠 Cara Mudah Ingat

→Amplify Hosting: Git-based CI/CD (GitHub, GitLab, Bitbucket). Supports SSR (Next.js, Nuxt), SSG, SPA. Instant cache invalidation via CloudFront CDN. Custom domains + HTTPS automatic
→Amplify vs Elastic Beanstalk: Amplify = frontend/fullstack apps (React, Next.js, mobile). Beanstalk = backend server apps (Node.js, Python, Java, Docker). Different use cases
→Amplify vs CloudFront + S3: Amplify includes CI/CD pipeline + backend services. S3+CloudFront = static hosting sahaja, perlu setup pipeline sendiri
→Backend: Amplify uses Cognito (auth), AppSync/API Gateway (API), DynamoDB (data), S3 (file storage), Lambda (functions) under the hood. Abstracts away the complexity
→Exam: "quickly build and deploy fullstack web application" or "frontend hosting with CI/CD" → Amplify. "Host static website cheaply" → S3 + CloudFront

Guna Bila

Build and host fullstack web/mobile apps with managed backend services

fullstackCI/CDfrontend hostingmobileReactNext.jsCognitoAppSyncbackend-as-a-serviceBaaSFirebaseFirebase alternativeAmplify AuthAmplify StorageGit deployCDN

📎 What is AWS Amplify