SNS #

Dalam arsitektur cloud modern—terutama yang berbasis event-driven dan serverless—mekanisme komunikasi antar komponen menjadi sangat krusial. Sistem harus mampu mengirimkan event, notifikasi, atau sinyal tanpa membuat komponen saling bergantung secara ketat (tight coupling).

AWS Simple Notification Service (SNS) hadir sebagai solusi fully managed pub/sub messaging service yang memungkinkan sistem mengirim pesan ke banyak konsumen secara bersamaan, dengan latensi rendah dan skalabilitas tinggi.

Artikel ini akan membahas AWS SNS secara menyeluruh: mulai dari definisi, alasan mengapa SNS termasuk serverless, jenis-jenisnya, perbedaan dengan SQS, konfigurasi, monitoring, hingga best practice serta pros & cons dalam penggunaan di dunia nyata.

Apa Itu AWS SNS? #

AWS Simple Notification Service (SNS) adalah layanan publish-subscribe (pub/sub) yang memungkinkan publisher mengirim pesan ke sebuah topic, lalu SNS akan mendistribusikan pesan tersebut ke satu atau lebih subscriber.

Karakteristik utama SNS:

  • Berbasis topic
  • Model fan-out (1 publisher → banyak subscriber)
  • Fully managed oleh AWS
  • Mendukung berbagai protokol delivery

SNS sering digunakan untuk:

  • Event notification
  • Fan-out ke beberapa service
  • Trigger workflow serverless
  • Sistem notifikasi (email, SMS, webhook)

Kenapa AWS SNS Disebut Serverless? #

SNS dikategorikan sebagai serverless service karena:

  1. Tidak Perlu Provisioning Server Anda tidak mengelola instance, cluster, atau kapasitas.

  2. Auto Scaling SNS otomatis menangani lonjakan trafik, dari puluhan hingga jutaan pesan.

  3. Pay-as-you-go Biaya dihitung berdasarkan jumlah request publish dan delivery.

  4. High Availability Built-in Replikasi dan availability ditangani langsung oleh AWS.

  5. Event-driven Native Sangat cocok untuk arsitektur Lambda, Step Functions, dan microservices.

Dengan kata lain, SNS memungkinkan fokus ke logic bisnis, bukan ke operasional infrastruktur.


Konsep Dasar AWS SNS #

Topic #

Entity utama tempat publisher mengirim pesan.

Contoh:

  • user-registered-topic
  • order-created-topic

Publisher #

Service atau aplikasi yang mengirim pesan ke topic.

Contoh:

  • Lambda Function
  • EC2
  • Backend API

Subscriber #

Endpoint yang menerima pesan dari topic.

SNS mendukung banyak subscriber dalam satu topic.


Jenis-Jenis Subscription di AWS SNS #

SNS mendukung berbagai protokol delivery:

Lambda #

  • Paling umum dalam arsitektur serverless
  • Event langsung memicu Lambda

Use case:

  • Fan-out event ke banyak Lambda

Amazon SQS #

  • SNS → SQS → Consumer
  • Kombinasi populer untuk decoupling dan durability

Use case:

  • Event-driven microservices
  • Buffering dan retry

HTTP / HTTPS #

  • Webhook ke endpoint eksternal

Use case:

  • Integrasi dengan sistem non-AWS

Email / Email-JSON #

  • Mengirim notifikasi ke email

Use case:

  • Alert manual
  • Approval workflow

SMS #

  • Mengirim pesan ke nomor ponsel

Use case:

  • OTP
  • Critical alert

Mobile Push Notification #

  • Integrasi dengan APNs, FCM, ADM

Use case:

  • Notifikasi aplikasi mobile

Perbedaan AWS SNS vs AWS SQS #

AspekAWS SNSAWS SQS
ModelPub/SubQueue
PolaFan-outPoint-to-point
Jumlah ConsumerBanyakBiasanya satu
DeliveryPushPull
Message PersistenceTidak lamaTahan lama
OrderingTidak dijaminFIFO tersedia
Use CaseEvent broadcastTask processing

Analogi Sederhana #

  • SNS: Pengumuman di speaker (semua dengar)
  • SQS: Antrian loket (satu per satu)

Seringkali SNS dan SQS digunakan bersama, bukan dipertentangkan.

Konfigurasi yang Bisa Diset di AWS SNS #

Topic Type #

  • Standard (default)
  • FIFO (ordering + deduplication)

Message Filtering (Subscription Filter Policy) #

Memungkinkan subscriber hanya menerima pesan tertentu.

Contoh:

  • Filter berdasarkan event_type
  • Filter berdasarkan attribute tertentu

Manfaat:

  • Mengurangi processing yang tidak perlu

Message Attributes #

Metadata tambahan pada pesan.

Use case:

  • Routing
  • Filtering
  • Context tambahan

Delivery Retry Policy #

  • Jumlah retry
  • Backoff

Dead Letter Queue (DLQ) #

  • SNS bisa mengirim pesan gagal ke SQS DLQ

Manfaat:

  • Observability
  • Debugging

Encryption (KMS) #

  • Enkripsi pesan menggunakan AWS KMS

Access Policy (IAM Policy) #

  • Kontrol siapa yang boleh publish/subscribe

Apa Saja yang Bisa Dimonitor dari AWS SNS? #

SNS terintegrasi dengan Amazon CloudWatch.

Metric Utama #

  • NumberOfMessagesPublished
  • NumberOfNotificationsDelivered
  • NumberOfNotificationsFailed
  • PublishSize

Monitoring Use Case #

  • Deteksi pesan gagal
  • Lonjakan trafik
  • Delivery latency

Logging #

  • Delivery status logging
  • CloudTrail untuk audit API call

Pros & Cons AWS SNS #

✅ Pros #

  1. Scalable & Reliable
  2. Integrasi Native dengan AWS Services
  3. Cocok untuk Fan-out Pattern
  4. Low Latency
  5. Biaya Relatif Murah untuk Event Broadcast

❌ Cons #

  1. Tidak Cocok untuk Task Queue
  2. Ordering Tidak Dijamin (Standard Topic)
  3. Message Retention Pendek
  4. Debugging Lebih Sulit dibanding Queue
  5. At-least-once Delivery (potensi duplikasi)

Pola Arsitektur Umum dengan SNS #

Event Fan-out Microservices #

API → SNS → (Lambda A, Lambda B, SQS C)

Domain Event Architecture #

Setiap domain mem-publish event ke SNS topic.

Notification Hub #

Satu topic → Email, SMS, Push Notification.


Best Practice #

Gunakan SNS untuk Event, Bukan Task #

SNS ideal untuk event notification, bukan untuk job processing berat.

Kombinasikan SNS + SQS untuk Reliability #

  • SNS untuk fan-out
  • SQS untuk durability dan retry

Manfaatkan Message Filtering #

Kurangi beban consumer dengan filter policy.

Selalu Aktifkan DLQ #

DLQ sangat penting untuk observability dan debugging.

Gunakan FIFO Topic Jika Ordering Penting #

Tapi pahami trade-off throughput.

Monitor Cost dan Delivery Failure #

Set alarm CloudWatch untuk:

  • Failure rate
  • Anomali publish

Jangan Jadikan SNS sebagai Single Point of Business Logic #

SNS sebaiknya menjadi transport layer, bukan tempat logic kompleks.


Penutup #

AWS SNS adalah komponen fundamental dalam arsitektur serverless dan event-driven di AWS. Ia unggul dalam distribusi event secara cepat dan scalable, terutama untuk pola fan-out dan notifikasi.

Namun, SNS bukan pengganti SQS, melainkan pasangan yang saling melengkapi. Dengan pemahaman yang tepat, konfigurasi yang benar, serta best practice yang disiplin, SNS dapat menjadi tulang punggung komunikasi antar service yang efisien, reliable, dan cost-effective.

Jika digunakan pada konteks yang tepat, AWS SNS akan sangat menyederhanakan desain sistem cloud modern.

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact