AWS Cloud Practitioner #20: SNS, SQS y Messaging

Model: 1 publisher → Many subscribers
 
Publisher:
Application publica mensaje a SNS Topic
 
Subscribers:
- Email
- SMS
- HTTP/HTTPS endpoints
- Lambda functions
- SQS queues
- Mobile push notifications
 
Ejemplo:
Order placed → SNS Topic "OrdersCreated"
Subscribers:
- Email a admin
- SMS a customer
- Lambda para inventory update
- SQS queue para analytics

# Create SNS topic
aws sns create-topic --name OrdersCreated
 
# Subscribe email
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:OrdersCreated \
  --protocol email \
  --notification-endpoint admin@empresa.com
 
# Publish message
aws sns publish \
  --topic-arn arn:aws:sns:us-east-1:123456789012:OrdersCreated \
  --message "New order #1234 created" \
  --subject "Order Notification"
 
# All subscribers receive message instantly

1. Notifications:
   CloudWatch Alarm → SNS → Email/SMS
   "EC2 CPU > 80%"
 
2. Fan-out:
   1 event → Multiple systems
   Order → Email + SMS + Inventory + Analytics
 
3. Mobile push:
   Backend → SNS → iOS/Android app
   "Your package shipped"
 
4. Webhooks:
   Event → SNS → HTTP endpoint
   External system integration

Model: Producer → Queue → Consumer
 
Producer: Sends messages to queue
Queue: Stores messages
Consumer: Polls queue, processes messages
 
Example:
User uploads video → SQS queue "VideoProcessing"
Worker instances poll queue → Process video → Delete message
 
Benefits:
✅ Decoupling (producer/consumer independent)
✅ Buffering (handle traffic spikes)
✅ Reliability (messages persisted)

Características:
✅ Unlimited throughput
✅ At-least-once delivery (puede duplicar)
✅ Best-effort ordering (no guarantee)
✅ Cheaper
 
Use when:
- High throughput needed
- Duplicates OK
- Order doesn't matter
 
Example:
Log aggregation
Email sending (duplicates filtered by recipient)

Características:
✅ Exactly-once processing (no duplicates)
✅ Strict ordering (FIFO)
✅ 300 messages/sec (3000 with batching)
✅ Slightly more expensive
 
Use when:
- Order critical
- No duplicates allowed
 
Example:
Financial transactions
Order processing (avoid duplicate charges)
 
Queue name must end with .fifo

# Send message
aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/VideoQueue \
  --message-body "Process video: video123.mp4"
 
# Receive message
aws sqs receive-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/VideoQueue
 
# Message returned:
{
  "MessageId": "abc-123",
  "ReceiptHandle": "xyz-789",  # Para delete
  "Body": "Process video: video123.mp4"
}
 
# Process message
process_video("video123.mp4")
 
# Delete message (acknowledge)
aws sqs delete-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/VideoQueue \
  --receipt-handle xyz-789
 
# Si no delete → Message reappears después de visibility timeout

Problem:
Consumer 1 receives message → Processing...
Consumer 2 también recibe mismo message (duplicate processing)
 
Solution: Visibility Timeout
 
Flow:
1. Consumer receives message
2. Message hidden for visibility timeout (default: 30s)
3. Consumer processes
4. Consumer deletes message
5. Si consumer falla → Message reappears después de timeout
 
Config: 1 second - 12 hours

Problem:
Message fails processing repeatedly (poison message)
 
Solution: DLQ
 
Setup:
Main queue: VideoQueue
DLQ: VideoQueue-DLQ
Max receives: 3
 
Flow:
Message processed → Fails → Back to queue (1)
Message processed → Fails → Back to queue (2)
Message processed → Fails → Back to queue (3)
Exceeds max → Moved to DLQ
 
Investigate DLQ manually, fix issues

Use SNS when:
✅ Múltiples sistemas deben recibir mismo event
✅ Real-time notifications
✅ Broadcasting
 
Use SQS when:
✅ Decouple producer/consumer
✅ Buffer traffic spikes
✅ Process messages at your pace
✅ Retry logic needed
 
Ejemplo SNS:
Order created → Notify email, SMS, inventory (all at once)
 
Ejemplo SQS:
Video uploaded → Queue → Workers process (one by one)

Architecture:
 
Order Service
    ↓
SNS Topic "OrdersCreated"
    ├→ SQS Queue "EmailQueue" → Email Worker
    ├→ SQS Queue "InventoryQueue" → Inventory Service
    └→ SQS Queue "AnalyticsQueue" → Analytics Service
 
Beneficios:
✅ SNS broadcasts a todos
✅ Each SQS queue buffers independientemente
✅ Each service processes at own pace
✅ Retry logic per queue
✅ No message loss (SQS persistence)
 
Setup:
1. Create SNS topic
2. Create múltiples SQS queues
3. Subscribe each queue to topic
4. Consumers poll their queues

Requests:
$0.50 per 1M requests (publish)
 
Notifications:
- Email: $2 per 100K
- SMS: $0.00645 per SMS (US)
- HTTP: $0.60 per 1M
- Lambda/SQS: $0
 
Free Tier:
1M requests/month
100K HTTP deliveries
1K email notifications

Requests:
$0.40 per 1M requests (Standard)
$0.50 per 1M requests (FIFO)
 
Data transfer:
Free dentro de region
 
Free Tier:
1M requests/month (always free)
 
Example:
10M messages/month:
(10M - 1M free) × $0.40/1M = $3.60/month

SNS:
✅ Use topics para different event types
✅ Filter policies (subscribers solo reciben relevant messages)
✅ Enable encryption at rest
✅ Monitor delivery failures
 
SQS:
✅ Set appropriate visibility timeout (>processing time)
✅ Use DLQ para failed messages
✅ Batch operations (SendMessageBatch)
✅ Long polling (reduces empty receives)
✅ FIFO solo cuando strictly needed (overhead)
 
SNS + SQS:
✅ Fan-out pattern para reliability
✅ Each service independent
✅ Retry logic aislado