Application Integration
& Messaging
Bayangkan aplikasi modern seperti tim restoran besar, pesanan, dapur, kasir, kurir, dan notifikasi harus saling bicara tanpa saling menunggu terus-menerus.
Kenapa Aplikasi Perlu Integrasi?
Analogi restoran: pesanan masuk, dapur bekerja, kasir mencatat, kurir mengantar, pelanggan menerima kabar.
Semakin banyak bagian aplikasi, semakin penting cara mereka berkomunikasi.
Dalam aplikasi kecil, satu program bisa menerima request, memproses pembayaran, mengirim email, memperbarui stok, dan menulis laporan sekaligus. Ini seperti satu orang yang menjadi kasir, koki, pelayan, dan kurir. Awalnya cepat, tetapi ketika pesanan ramai, semua pekerjaan ikut macet.
Application integration membantu aplikasi dipecah menjadi bagian-bagian yang bisa bekerja sendiri, tetapi tetap terhubung. Di AWS, bagian ini biasanya dihubungkan dengan antrean, topik publikasi, event bus, workflow, atau API. Modul ini fokus pada layanan yang paling relevan untuk CLF-C02, yaitu Amazon SQS, Amazon SNS, Amazon EventBridge, AWS Step Functions, dan Amazon API Gateway.
SQS seperti rak pesanan dapur, SNS seperti pengeras suara untuk banyak petugas, EventBridge seperti petugas routing yang membaca jenis kejadian, Step Functions seperti checklist SOP, dan API Gateway seperti resepsionis pintu depan.
Untuk ujian, target utamanya bukan menghafal semua konfigurasi detail. Targetnya adalah menjawab, “layanan mana yang paling tepat untuk pola komunikasi ini?” Begitu kamu memetakan tiap layanan ke satu kata kerja inti (terima, antre, siarkan, rute, orkestrasi), pilihan ganda yang tadinya membingungkan menjadi jauh lebih mudah dieliminasi.
Menurut Exam Guide CLF-C02, topik integrasi aplikasi terutama masuk Domain 3 (Cloud Technology and Services, bobot 34%), tetapi juga menyentuh Domain 2 (akses aman, enkripsi, audit) dan Domain 4 (model pay-per-request dan free tier). Catatan scope penting yang sering keliru: di exam guide, kategori resmi Application Integration hanya berisi SQS, SNS, EventBridge, dan Step Functions. API Gateway sebenarnya ada di kategori Networking and Content Delivery, dan AppSync di kategori Frontend Web and Mobile. Modul ini tetap membahas API Gateway karena pola “pintu depan API” sangat sering muncul bersama layanan integrasi, tetapi ingat letak kategorinya.
Decoupling, Messaging, dan Event
Fondasi yang membuat SQS, SNS, EventBridge, dan Step Functions terasa masuk akal.
Decoupling berarti komponen tidak saling menggenggam terlalu erat.
Jika layanan pembayaran langsung memanggil layanan email dan email sedang error, pembayaran bisa ikut lambat. Dengan decoupling, pembayaran cukup menaruh pesan “kirim email tanda terima” ke layanan perantara. Email boleh memproses beberapa detik kemudian tanpa membuat pembayaran gagal. Inilah inti loose coupling: kegagalan satu komponen tidak langsung menyeret komponen lain ikut jatuh.
Synchronous
Pengirim menunggu jawaban saat itu juga, seperti pelanggan bertanya harga ke kasir.
Asynchronous
Pengirim menitipkan pesan lalu lanjut bekerja, seperti pelanggan mengambil nomor antrean.
Event-driven
Sistem bereaksi terhadap kejadian, seperti “order dibuat” memicu stok, email, dan laporan.
Dalam CLF-C02, kata kunci yang sering mengarah ke integrasi aplikasi adalah loosely coupled, message queue, publish-subscribe, event-driven, workflow orchestration, API front door, fanout, dan asynchronous processing.
Jika soal berkata “komponen harus tetap berjalan walau komponen lain sibuk”, pikirkan decoupling. Jika soal berkata “satu event harus memicu banyak target”, pikirkan SNS atau EventBridge.
Pesan vs event
Pesan biasanya adalah instruksi atau data yang harus diproses, misalnya “proses order 123”. Event biasanya adalah fakta bahwa sesuatu sudah terjadi, misalnya “order 123 dibuat”. Perbedaannya halus, tetapi penting. SQS sangat kuat untuk antrean pekerjaan, SNS kuat untuk menyebarkan pesan ke banyak subscriber, EventBridge kuat untuk merutekan event berdasarkan pola, dan Step Functions kuat untuk mengatur urutan langkah.
Pesan seperti memo tugas di meja rekan kerja (“tolong kerjakan ini”), event seperti pengumuman di grup (“acara sudah dimulai”). Memo ditujukan ke satu pelaksana, pengumuman boleh ditanggapi siapa pun yang berkepentingan.
Peta Layanan Integrasi AWS
Lihat dulu gambaran besarnya sebelum masuk satu per satu.
Setiap layanan punya peran, jangan dipaksa menyelesaikan semua masalah dengan satu layanan.
Amazon SQS
Antrean pesan untuk memisahkan producer dan consumer, cocok untuk job background, buffering, dan beban yang naik turun.
Amazon SNS
Layanan publish-subscribe untuk menyebarkan satu pesan ke banyak subscriber, cocok untuk fanout dan notifikasi.
Amazon EventBridge
Event bus serverless untuk merutekan event dari aplikasi, layanan AWS, atau SaaS ke target berdasarkan rule.
AWS Step Functions
Workflow visual untuk mengatur langkah-langkah proses, retry, percabangan, dan orkestrasi layanan.
Amazon API Gateway
Pintu depan API untuk membuat, memublikasikan, memantau, dan mengamankan HTTP, REST, atau WebSocket API. Catatan: di exam guide ada di kategori Networking, bukan Application Integration.
Layanan terkait (kenali saja)
Kenali nama AWS AppSync (in-scope, kategori Frontend), Amazon MQ, dan Amazon AppFlow. Penting: Amazon MQ, AppFlow, dan Amazon SWF BUKAN in-scope CLF-C02, jadi kalau muncul sebagai opsi jawaban integrasi biasanya distractor.
Queue menahan pekerjaan, topic menyiarkan, event bus memilah kejadian, workflow mengatur langkah, API Gateway menerima request dari luar.
Amazon MQ relevan hanya saat soal menyebut migrasi message broker existing seperti ActiveMQ atau RabbitMQ (lift-and-shift JMS, AMQP, MQTT). Tetap di luar in-scope CLF-C02, jadi jangan menghafalnya sebagai jawaban integrasi default.
Amazon SQS: Antrean Kerja
Untuk pekerjaan yang boleh diproses nanti, tidak harus langsung selesai di depan pengguna.
Amazon SQS adalah rak antrean, producer menaruh pekerjaan, consumer mengambil pekerjaan saat siap.
Amazon Simple Queue Service adalah layanan message queue terkelola yang membantu memisahkan sistem terdistribusi. Producer mengirim pesan ke queue. Consumer membaca, memproses, lalu menghapus pesan. Jika consumer sedang sibuk, pesan tetap menunggu di queue.
Aplikasi order menaruh pesan “proses pembayaran” atau “buat thumbnail gambar” ke queue.
Queue menjadi buffer agar lonjakan request tidak langsung membanjiri worker.
Worker, Lambda, atau aplikasi backend memproses pesan sesuai kapasitasnya.
Jika consumer gagal menghapus pesan, pesan bisa terlihat lagi setelah visibility timeout.
Standard Queue vs FIFO Queue
SQS Standard cocok untuk proses seperti resize gambar, kirim log, atau sinkronisasi inventori yang toleran terhadap urutan. SQS FIFO cocok untuk proses seperti transaksi rekening, urutan status order, atau operasi yang tidak boleh tertukar.
- At-least-once delivery: pesan bisa terkirim lebih dari sekali, jadi consumer harus idempotent.
- Best-effort ordering: urutan tidak dijamin sempurna.
- Throughput hampir tak terbatas, cocok untuk volume sangat tinggi.
- Pilih saat urutan dan duplikasi tidak kritis: resize gambar, log, notifikasi.
- Exactly-once processing: tidak ada duplikat dalam window deduplikasi.
- First-in-first-out: urutan pesan dijaga ketat.
- Throughput lebih rendah (default sekitar 300 TPS, lebih tinggi dengan high-throughput mode; cek dokumentasi karena angka per region).
- Pilih hanya saat order atau dedup penting: transaksi keuangan, urutan status.
At-least-once berarti consumer harus idempotent, karena pesan bisa saja diproses lebih dari sekali pada kondisi tertentu. Jangan memilih FIFO hanya karena terdengar lebih rapi, FIFO menukar throughput demi urutan dan dedup.
Istilah SQS yang perlu dikenal
- Visibility timeout: periode ketika pesan yang sedang diproses disembunyikan dari consumer lain. Default 30 detik, minimum 0 detik, maksimum 12 jam. Catatan halus: batas 12 jam dihitung sejak pesan pertama kali diterima dan tidak ter-reset saat kamu meng-extend timeout.
- Message retention: lamanya pesan bertahan di queue sebelum kedaluwarsa. Default 4 hari, minimum 60 detik, maksimum 14 hari.
- Long polling: consumer menunggu sampai ada pesan (maksimum 20 detik) agar empty response berkurang dan biaya turun. Short polling adalah default untuk queue baru. Jangan tertukar: long polling maksimum 20 detik, visibility timeout maksimum 12 jam.
- Max message size: kini 1 MiB (1.048.576 byte) untuk Standard dan FIFO, naik dari 256 KiB sejak Agustus 2025. Untuk payload lebih besar pakai Extended Client Library + Amazon S3 (hingga 2 GB).
- In-flight messages: pesan yang sedang diproses tetapi belum dihapus, dibatasi sekitar 120.000 untuk Standard maupun FIFO (limit FIFO dinaikkan dari 20.000 ke 120.000 pada 2024). Jika tercapai, SQS mengembalikan error OverLimit.
- Dead-letter queue (DLQ): queue khusus untuk pesan yang gagal diproses berulang kali, agar tidak mengganggu pesan sehat. DLQ adalah pola lintas layanan: SNS, Lambda, dan EventBridge juga bisa mengirim pesan gagal ke SQS sebagai DLQ.
SQS punya free tier always-free: 1 juta request SQS gratis tiap bulan (bukan hanya 12 bulan pertama). Tiap chunk 64 KB payload dihitung sebagai 1 request, jadi pesan besar bisa memakai beberapa request. Lihat pricing SQS untuk angka terbaru.
Jika soal menyebut “decouple microservices”, “buffer workload”, “process later”, “background job”, atau “worker mengambil pesan”, jawaban kuat biasanya Amazon SQS. Ingat juga angka aman: visibility timeout maksimum 12 jam, long polling maksimum 20 detik, retention default 4 hari (maksimum 14 hari), max size 1 MiB. Angka bisa berubah, tetap cek dokumentasi resmi.
Amazon SNS: Pengumuman ke Banyak Tujuan
Untuk satu pesan yang perlu disebarkan ke banyak penerima sekaligus.
Amazon SNS seperti papan pengumuman, publisher menempel pesan, subscriber yang terdaftar menerima salinannya.
Amazon Simple Notification Service adalah layanan publish-subscribe. Aplikasi mengirim pesan ke topic, lalu SNS mengirim pesan tersebut ke subscriber seperti SQS queue, AWS Lambda, endpoint HTTP/S, email, SMS, atau layanan lain sesuai dukungan region dan konfigurasi.
Topic
Tempat publisher mengirim pesan, seperti kanal pengumuman “OrderCreated”.
Subscriber
Penerima pesan dari topic, misalnya queue billing, queue analytics, dan fungsi notifikasi.
Fanout
Satu pesan disalin ke banyak tujuan, sehingga tiap tim bisa memproses tanpa saling mengganggu.
Filtering
Subscriber dapat menerima pesan tertentu saja berdasarkan atribut, sehingga pengiriman lebih relevan.
Contoh nyata fanout
Sebuah aplikasi toko online membuat event “order selesai dibayar”. SNS topic menerima pesan tersebut. Queue gudang menerima untuk proses packing, fungsi notifikasi menerima untuk kirim email, queue analitik menerima untuk laporan penjualan. Satu kejadian bisnis menyebar ke banyak proses tanpa order service harus mengenal semua penerima.
SNS Standard topic vs FIFO topic
Seperti SQS, SNS juga punya dua tipe topic. Standard topic mengutamakan throughput tinggi dengan best-effort ordering, sedangkan FIFO topic menjaga urutan dan menghindari duplikat. Pola yang sering dipakai untuk fanout yang tetap berurutan adalah SNS FIFO topic → SQS FIFO queue, sehingga banyak consumer tetap menerima pesan dalam urutan yang benar.
Catatan ukuran pesan dan biaya
Max message size SNS adalah 256 KB. Ini berbeda dari SQS yang naik ke 1 MiB pada Agustus 2025; SNS tidak ikut naik, jadi jangan asumsikan keduanya sama besar. Untuk payload lebih dari 256 KB pakai Extended Client Library + Amazon S3 (hingga 2 GB).
SNS punya free tier always-free per bulan: 1 juta SNS request, 100.000 HTTP/S deliveries, 1.000 email deliveries, dan 1 juta mobile push notifications. SMS ditagih terpisah. Lihat pricing SNS untuk angka terbaru.
Pilih SNS saat satu publisher perlu mengirim pesan ke banyak subscriber, terutama pola fanout SNS ke beberapa SQS queue, atau notifikasi via email, SMS, dan mobile push.
Jika soal hanya butuh antrean satu consumer group, SQS lebih tepat (pull). Jika soal butuh broadcast ke banyak subscriber, SNS lebih tepat (push). Ingat: SNS push-based, SQS pull-based, dan ukuran pesan SNS tetap 256 KB.
Amazon EventBridge: Jalur Event
Untuk merutekan event dari banyak sumber ke target yang tepat berdasarkan pola.
EventBridge seperti petugas sortir paket, ia membaca label event lalu mengirim ke tujuan yang cocok.
Amazon EventBridge adalah event bus serverless untuk membangun aplikasi event-driven. Event dapat berasal dari aplikasi sendiri, layanan AWS, atau aplikasi SaaS partner. EventBridge menggunakan rule dan event pattern untuk menentukan target yang harus menerima event.
Event
Catatan bahwa sesuatu terjadi, misalnya file baru diunggah, pembayaran sukses, atau ticket support dibuat.
Event bus
Router yang menerima event dan mengirimnya ke target yang cocok.
Rule
Aturan pencocokan event, misalnya hanya event dari sumber tertentu atau tipe tertentu.
Target
Tujuan event, misalnya Lambda, SQS, Step Functions, Kinesis, atau target lain yang didukung.
EventBridge sering terlihat mirip SNS karena sama-sama bisa mengirim ke target. Bedanya, SNS sederhana untuk pub/sub dan fanout pesan, sedangkan EventBridge lebih kaya untuk routing event berdasarkan pola, integrasi SaaS, event bus lintas akun, schema registry, dan event-driven architecture yang lebih terstruktur. Catatan sejarah yang berguna untuk ujian: EventBridge adalah evolusi atau rename dari Amazon CloudWatch Events (sejak 2019). API-nya kompatibel, tetapi EventBridge menambah ingestion event dari SaaS partner, schema registry, custom events, Pipes, dan Scheduler. Kata kunci “event dari SaaS atau third-party” kuat mengarah ke EventBridge, bukan CloudWatch Events.
SNS seperti pengeras suara yang menyiarkan ke semua pendengar terdaftar, EventBridge seperti pusat sortir yang melihat isi label lalu memilih jalur paling cocok.
- Fokus pub/sub dan fanout pesan ke subscriber (SQS, Lambda, HTTP/S, email, SMS, push).
- Latensi rendah, throughput tinggi untuk fanout sederhana.
- Tidak membaca event dari SaaS pihak ketiga.
- Pilih saat soal sebut simple pub/sub, high-throughput fanout, atau notifikasi SMS/email/push.
- Event bus serverless yang menerima event dari aplikasi sendiri, layanan AWS, dan SaaS partner.
- Routing berdasarkan event pattern yang kaya, plus schema registry dan event bus lintas akun.
- Punya Pipes (point-to-point) dan Scheduler (penjadwalan task).
- Pilih saat soal sebut event dari SaaS/third-party atau route based on event content/pattern.
EventBridge Pipes dan EventBridge Scheduler
Selain rule biasa, EventBridge punya dua kemampuan yang sering disebut di materi modern. EventBridge Pipes (GA Desember 2022) adalah integrasi point-to-point antara satu producer dan satu consumer, misalnya dari SQS, DynamoDB Streams, atau Kinesis ke target, dengan opsi filter dan enrichment di tengah jalan. Ini berbeda dari rule yang merutekan ke banyak target sekaligus. EventBridge Scheduler (diluncurkan November 2022) adalah penjadwal serverless untuk task one-time atau recurring ke ratusan layanan AWS, terpisah dari scheduled events lama berbasis rule.
Kapan memilih EventBridge
Pilih EventBridge saat kamu ingin aplikasi bereaksi terhadap event dari banyak sumber, termasuk layanan AWS dan SaaS, dengan aturan routing yang jelas. Contohnya, event “customer updated” dari SaaS CRM masuk ke EventBridge, lalu EventBridge mengirim ke Lambda untuk validasi, Step Functions untuk proses onboarding, dan SQS untuk sinkronisasi data.
Ingestion management events dari layanan AWS ke default event bus gratis. Custom events dan partner/SaaS events ditagih sekitar $1,00 per juta. Pipes sekitar $0,40 per juta request, dan Scheduler sekitar $1,00 per juta invocation setelah free tier 14 juta invocation per bulan. Tiap chunk 64 KB dihitung sebagai 1 event; cek pricing EventBridge untuk angka terbaru.
Jika soal sebut “event from SaaS app” atau “route based on event content/pattern”, jawabannya EventBridge. Jika soal sebut “simple pub/sub”, “high throughput fanout to SQS”, atau “SMS/email/mobile push”, jawabannya SNS. Jangan tertukar dengan CloudWatch Alarms yang memicu aksi berdasar threshold metrik, bukan merutekan event.
AWS Step Functions: Workflow Bertahap
Untuk proses yang punya urutan, cabang keputusan, retry, dan status yang perlu terlihat.
Step Functions seperti checklist SOP, setiap langkah tahu apa yang harus dilakukan berikutnya.
AWS Step Functions membantu membuat workflow, disebut state machine, untuk membangun aplikasi terdistribusi, mengotomasi proses, dan mengorkestrasi microservices. Ia tidak menggantikan Lambda, SQS, atau API Gateway. Ia mengatur kapan layanan-layanan itu dipanggil dan apa yang terjadi jika sukses atau gagal.
Misalnya order baru memulai proses validasi, pembayaran, packing, dan notifikasi.
Workflow memanggil Lambda, layanan AWS, atau API sesuai desain proses.
Jika pembayaran sukses lanjut packing, jika gagal kirim notifikasi gagal.
Retry dan catch membantu proses tidak langsung berhenti karena gangguan sementara.
State machine didefinisikan dengan Amazon States Language (ASL), sebuah format JSON yang menggambarkan state, transisi, retry, dan catch. Tipe workflow bersifat immutable setelah dibuat: kamu tidak bisa mengubah Standard menjadi Express tanpa membuat ulang. Untuk Cloud Practitioner kamu tidak perlu menulis ASL, cukup tahu bahwa Step Functions adalah orchestration, bukan messaging.
Standard vs Express
- Durasi maksimum sampai 1 tahun.
- Model exactly-once, cocok untuk proses non-idempotent (pembayaran, start EMR).
- Riwayat eksekusi tersimpan 90 hari, mudah diaudit.
- Ditagih per state transition.
- Durasi maksimum 5 menit, untuk event processing volume tinggi.
- Express Async = at-least-once, Express Sync = at-most-once, jadi cocok untuk aksi idempotent.
- Observability lewat CloudWatch Logs, bukan riwayat 90 hari.
- Ditagih per jumlah eksekusi plus durasi dan memori.
Pembeda exactly-once vs at-least/at-most-once sering jadi penentu: jika setiap langkah harus berjalan tepat sekali (mis. memproses pembayaran), Standard lebih aman. Jika aksi idempotent dan volumenya sangat tinggi, Express lebih hemat dan cepat. Jika soal menggambarkan proses banyak langkah seperti validasi dokumen, approval, pemanggilan beberapa layanan, retry, dan cabang keputusan, Step Functions adalah kandidat kuat.
”Coordinate components”, “visual workflow”, “state machine”, “multi-step process”, “retry”, dan “branching logic” sering mengarah ke AWS Step Functions. Bedakan dari SQS yang hanya buffer/antrean: jika soal sebut orkestrasi banyak langkah dengan retry dan percabangan, jawabannya Step Functions, bukan SQS.
Amazon API Gateway: Pintu Depan API
Untuk menerima request dari client dan meneruskannya ke backend dengan kontrol keamanan dan operasi.
API Gateway seperti resepsionis gedung, ia menerima tamu, mengecek akses, mencatat kunjungan, lalu mengarahkan ke ruangan yang benar.
Amazon API Gateway membantu membuat, memublikasikan, memelihara, memantau, dan mengamankan API pada skala besar. API dapat mengarah ke AWS Lambda, endpoint HTTP, atau layanan AWS lain. Untuk ujian, pahami tiga keluarga utama: HTTP API, REST API, dan WebSocket API.
HTTP API
API ringan untuk banyak skenario modern, sering dipakai dengan Lambda atau backend HTTP.
REST API
Fitur API management lebih lengkap, cocok saat butuh kapabilitas REST API yang lebih kaya.
WebSocket API
Koneksi dua arah real-time, cocok untuk chat, notifikasi live, dan dashboard interaktif.
API Gateway dapat membantu autentikasi dan otorisasi (IAM, Lambda authorizer, Amazon Cognito), throttling, logging ke CloudWatch dan CloudTrail, monitoring, canary deployment, serta integrasi dengan WAF dan AWS X-Ray. Untuk CLF-C02, ingat fungsinya sebagai front door aplikasi, bukan tempat utama menyimpan data atau menjalankan batch job.
HTTP API vs REST API: kapan pilih mana
- Lebih murah dan latensi lebih rendah.
- Fitur minimal, cocok sebagai proxy ke Lambda atau backend HTTP.
- Pilihan default modern untuk API sederhana.
- Fitur API management lengkap: API keys, usage plans, request validation.
- Mendukung edge-optimized dan private endpoint, plus integrasi WAF.
- Pilih saat butuh kontrol dan kapabilitas REST yang kaya.
WebSocket API berbeda dari keduanya: ia stateful dan full-duplex, merutekan pesan berdasarkan isi, cocok untuk chat, dashboard live, dan notifikasi real-time. HTTP dan REST API bersifat stateless.
Pilih API Gateway saat client eksternal perlu memanggil backend melalui endpoint API yang dikelola, diamankan, dipantau, dan diskalakan. Pola umum decoupling: API Gateway dapat langsung mengirim ke SQS atau Step Functions tanpa Lambda di tengah (service integration), sehingga request berat bisa diantre dan diproses async.
API Gateway adalah API management (auth, throttling, versioning, REST/HTTP/WebSocket, integrasi Lambda). Application Load Balancer membagi trafik ke target seperti EC2, ECS, IP, atau Lambda. Jika soal sebut “managed API front door dengan auth dan throttling”, jawabannya API Gateway, bukan ALB.
Pola Arsitektur yang Sering Muncul
Bukan hanya hafal layanan, tetapi paham pola memilihnya.
Soal CLF-C02 sering menanyakan pola, bukan nama menu di console.
1. Asynchronous job processing
Aplikasi menerima upload gambar. Daripada pengguna menunggu proses resize lama, aplikasi menaruh pesan ke SQS. Worker mengambil pesan dan memproses gambar di belakang layar. Ini membuat pengalaman pengguna lebih cepat dan backend lebih tahan terhadap lonjakan.
2. Fanout dengan SNS ke banyak SQS queue
Order service publish ke SNS topic “OrderPaid”. SNS mengirim salinan ke queue gudang, queue analitik, dan queue notifikasi. Setiap consumer punya ritme sendiri. Jika analitik lambat, gudang tetap bisa bekerja.
3. Event-driven routing dengan EventBridge
Aplikasi SaaS mengirim event “lead created” ke EventBridge. Rule pertama mengirim ke Step Functions untuk onboarding, rule kedua mengirim ke SQS untuk sinkronisasi data warehouse, rule ketiga mengirim ke Lambda untuk enrich data.
4. Workflow approval dengan Step Functions
Pengajuan refund melewati validasi, cek fraud, approval manager, update database, dan notifikasi pelanggan. Step Functions membuat alur terlihat, bisa diberi retry, dan mudah diaudit secara konseptual.
5. API front door dengan API Gateway
Mobile app memanggil endpoint /orders. API Gateway menerima request, menerapkan autentikasi, lalu meneruskan ke Lambda atau backend container. Untuk request yang perlu diproses nanti, API Gateway juga dapat menjadi pintu masuk menuju SQS atau Step Functions melalui integrasi yang sesuai.
Tanyakan dulu “apakah pengirim butuh jawaban langsung, perlu antrean, perlu broadcast, perlu routing event, atau perlu workflow bertahap?”
Keamanan, Monitoring, dan Keandalan
Domain 2 tetap penting walau topiknya layanan integrasi.
Integrasi yang baik bukan hanya tersambung, tetapi juga aman, terlihat, dan tahan gangguan.
IAM least privilege
Berikan izin minimum, misalnya producer hanya boleh mengirim ke queue tertentu dan consumer hanya boleh membaca queue tertentu.
Encryption
Gunakan enkripsi yang disediakan layanan saat data sensitif masuk ke queue, topic, event, atau workflow.
Resource policy
SNS topic, SQS queue, dan API dapat memakai policy untuk mengontrol siapa yang boleh mengakses resource.
Monitoring
Gunakan Amazon CloudWatch untuk metrik, log, alarm, dan observability pada antrean, API, workflow, dan event.
DLQ dan retry
Pesan gagal jangan dibiarkan berputar selamanya, arahkan ke dead-letter queue atau tangani dengan retry yang terkontrol.
Idempotency
Desain consumer agar aman jika pesan atau event diproses lebih dari sekali.
Jangan menaruh rahasia seperti password atau token jangka panjang langsung di pesan. Gunakan layanan seperti AWS Secrets Manager untuk rahasia aplikasi.
Shared responsibility dalam konteks integrasi
AWS mengelola infrastruktur layanan terkelola seperti SQS, SNS, EventBridge, Step Functions, dan API Gateway. Pelanggan tetap bertanggung jawab atas konfigurasi akses, data yang dikirim, policy, enkripsi yang dipilih, observability, dan desain error handling. Inilah pola shared responsibility yang sering muncul lintas domain ujian.
Hands-on Konseptual
Walkthrough ringan tanpa harus membuat akun atau mengeluarkan biaya.
Kita akan merancang alur order toko online dengan layanan integrasi yang tepat.
Mobile app mengirim order ke Amazon API Gateway, lalu API meneruskan request ke backend order service.
Backend menyimpan order dan segera mengembalikan respons “order diterima” agar pengguna tidak menunggu proses panjang.
Order service mengirim pesan ke SQS queue untuk proses pembayaran atau packing yang bisa berjalan async.
Setelah order dibayar, sistem publish ke SNS topic agar gudang, notifikasi, dan analitik menerima salinan pesan.
Event “OrderPaid” dapat dirutekan ke target berbeda berdasarkan pola event, misalnya loyalty service atau audit pipeline.
Untuk refund yang punya validasi, approval, dan cabang keputusan, gunakan Step Functions agar alur terlihat dan terkontrol.
Pertanyaan refleksi
- Jika worker pembayaran lambat, apakah pengguna harus menunggu? Tidak, SQS membantu buffering.
- Jika satu order perlu memberi tahu tiga sistem, apakah order service harus memanggil semuanya satu per satu? Tidak, SNS atau EventBridge bisa membantu.
- Jika proses refund punya beberapa langkah dan keputusan, apakah SQS saja cukup? Tidak ideal, Step Functions lebih jelas untuk workflow.
- Jika aplikasi mobile butuh endpoint publik yang aman, layanan apa yang menjadi pintu depan? API Gateway.
Coba gambar ulang alur ini dengan lima kotak: Client, API Gateway, SQS, SNS atau EventBridge, dan Step Functions. Lalu jelaskan fungsi tiap kotak dalam satu kalimat.
Kesalahan Umum dan Jebakan Soal
Bagian ini sengaja praktis karena CLF-C02 sering menguji perbedaan layanan yang tampak mirip.
Banyak jawaban salah terjadi karena semua layanan integrasi terlihat seperti “penghubung”.
SQS vs SNS
SQS menyimpan pesan untuk diproses consumer, SNS menyebarkan pesan ke subscriber.
SNS vs EventBridge
SNS kuat untuk pub/sub sederhana, EventBridge kuat untuk event routing berdasarkan pola dan sumber yang beragam.
SQS vs Step Functions
SQS adalah queue, Step Functions adalah orkestrator workflow bertahap.
API Gateway vs Load Balancer
API Gateway adalah layanan API management, load balancer membagi trafik ke target seperti instance atau container.
EventBridge vs CloudWatch Alarms
EventBridge merutekan event, CloudWatch Alarms memberi alarm berdasarkan metrik atau kondisi yang dipantau.
FIFO bukan default untuk semua
Gunakan FIFO saat urutan dan duplikasi penting, jangan memilihnya hanya karena terdengar lebih “rapi”. FIFO menukar throughput demi urutan.
SNS vs SQS ukuran pesan
SQS naik ke 1 MiB (Agustus 2025), tetapi SNS tetap 256 KB. Jangan asumsikan keduanya sama besar.
Angka SQS yang mirip
Long polling maksimum 20 detik, visibility timeout maksimum 12 jam, retention default 4 hari. Jangan tertukar angkanya.
Membuat semua service saling memanggil langsung bisa menghasilkan sistem rapuh. Gunakan queue atau event saat proses tidak perlu selesai sinkron.
Jebakan pilihan ganda
- “Memisahkan komponen agar tetap bisa memproses saat downstream lambat” mengarah ke SQS.
- “Mengirim satu pesan ke beberapa sistem secara paralel” mengarah ke SNS fanout atau EventBridge, lihat apakah soal menekankan topic sederhana atau routing event.
- “Membangun workflow visual dengan retry dan branching” mengarah ke Step Functions.
- “Menerima request dari aplikasi web atau mobile melalui endpoint API” mengarah ke API Gateway.
- “React to events from AWS services, custom apps, or SaaS” mengarah ke EventBridge.
- “Lift-and-shift existing ActiveMQ or RabbitMQ broker” mengarah ke Amazon MQ (perhatikan: di luar in-scope CLF-C02, jarang jadi jawaban benar di level ini).
- “Process each step exactly once for a payment workflow” mengarah ke Step Functions Standard, bukan Express.
Ringkasan & Tips Ujian
Peta cepat untuk mengunci materi ke domain CLF-C02.
Kunci modul ini adalah memilih layanan berdasarkan pola komunikasi.
Poin Penting
- SQS (pull) adalah queue untuk decoupling, buffering, worker, dan pemrosesan async. Standard = at-least-once + best-effort order; FIFO = exactly-once + urutan. Visibility timeout maks 12 jam, long polling maks 20 detik, retention default 4 hari (maks 14 hari), max size 1 MiB.
- SNS (push) adalah pub/sub topic untuk fanout dan notifikasi ke banyak subscriber. Max size 256 KB (tidak ikut naik seperti SQS). Punya Standard dan FIFO topic.
- EventBridge adalah event bus untuk routing event dari aplikasi, AWS services, dan SaaS. Punya Pipes (point-to-point) dan Scheduler (penjadwalan); evolusi dari CloudWatch Events.
- Step Functions adalah workflow orchestration. Standard = sampai 1 tahun, exactly-once, audit 90 hari; Express = sampai 5 menit, at-least/at-most-once, untuk volume tinggi.
- API Gateway adalah front door API (HTTP, REST, WebSocket). Catatan scope: kategori Networking di exam guide, bukan Application Integration.
- In-scope Application Integration hanya SQS, SNS, EventBridge, dan Step Functions. Amazon MQ, AppFlow, dan SWF tidak in-scope.
Pemetaan ke domain CLF-C02
| Domain | Kaitan materi | Yang perlu dikuasai |
|---|---|---|
| Domain 1, Cloud Concepts | Agility, elasticity, loose coupling, managed services | Kenapa async dan event-driven membuat aplikasi lebih scalable dan resilient. |
| Domain 2, Security and Compliance | IAM, resource policy, encryption, logging, shared responsibility | Siapa boleh mengirim, membaca, menjalankan workflow, dan memanggil API. |
| Domain 3, Cloud Technology and Services | SQS, SNS, EventBridge, Step Functions, API Gateway | Pilih layanan yang tepat dari skenario bisnis. Ini porsi paling penting untuk modul ini. |
| Domain 4, Billing, Pricing, and Support | Model pay-per-request dan free tier always-free | Pahami bahwa request, pesan, event, dan eksekusi memengaruhi biaya. SQS dan SNS punya 1 juta request gratis per bulan; EventBridge management events gratis; Scheduler punya 14 juta invocation gratis. Tidak perlu hafal angka detail. |
Checklist jawab soal
Jika client butuh endpoint API, pikirkan API Gateway. Jika tidak harus langsung, pertimbangkan asynchronous.
Jika pekerjaan perlu ditahan sampai worker siap, pilih SQS.
Jika ya, pilih SNS untuk pub/sub sederhana atau EventBridge untuk routing event lebih kaya.
Jika perlu state, retry, percabangan, dan visual workflow, pilih Step Functions.
Di ujian, jangan memilih layanan paling kompleks. Pilih layanan paling sesuai dengan kata kunci: queue = SQS, fanout = SNS, event bus = EventBridge, workflow = Step Functions, API endpoint = API Gateway. Untuk SQS vs SNS, ingat pull vs push; untuk SNS vs EventBridge, ingat simple pub/sub vs event dari SaaS plus pola.
Referensi resmi untuk pendalaman
- AWS Certified Cloud Practitioner CLF-C02 Exam Guide
- In-Scope AWS Services for CLF-C02
- Amazon SQS Developer Guide
- Amazon SNS Developer Guide
- Amazon EventBridge User Guide
- AWS Step Functions Developer Guide
- Step Functions Standard vs Express Workflows
- Amazon API Gateway Developer Guide
- SQS Visibility Timeout · Short vs Long Polling
- EventBridge Pipes · EventBridge Scheduler