Integrazione di SNS e SQS con CloudWatch

Monitoraggio e risoluzione dei problemi su AWS

John Q. Martin

Principal Consultant

Collegare gli allarmi CloudWatch a SNS

aws cloudwatch put-metric-alarm \
  --alarm-name HighCPUUtilization \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --evaluation-periods 2 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:production-alerts \
  --ok-actions arn:aws:sns:us-east-1:123456789012:recovery-notifications

Flusso: un allarme CloudWatch invia tramite --alarm-actions a un topic SNS, che smista ai subscriber — Email, SMS, Lambda e SQS

Concetti base di SNS

Componenti

SNS è publisher/subscriber: topic, publisher, subscriber
Topic: canale con nome; i publisher inviano, i subscriber ricevono
Pubblica una volta, consegnato in parallelo a tutti i subscriber

Protocolli dei subscriber (un topic, molti endpoint):

Email, SMS
HTTP / HTTPS
Lambda, SQS
Mobile push, Kinesis Firehose

Tipi di topic SNS

Confronto dei tipi di topic SNS Standard e FIFO per ordinamento, throughput e garanzie di consegna

Creare topic SNS: AWS CLI

Topic Standard

aws sns create-topic \
  --name production-alerts

Topic FIFO

aws sns create-topic \
  --name production-alerts.fifo \
  --attributes FifoTopic=true,\
    ContentBasedDeduplication=true

Con crittografia

aws sns create-topic \
  --name production-alerts \
  --attributes KmsMasterKeyId=alias/aws/sns

Aggiungere subscriber Lambda e SMS

Lambda

aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:production-alerts \
  --protocol lambda \
  --notification-endpoint arn:aws:lambda:us-east-1:123456789012:function:ProcessAlert

SMS

aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789012:critical-alerts \
  --protocol sms \
  --notification-endpoint +1234567890

Formato del messaggio SNS dagli allarmi CloudWatch

{
  "AlarmName": "HighCPUUtilization",
  "NewStateValue": "ALARM",
  "OldStateValue": "OK",
  "NewStateReason": "Threshold Crossed: 2 datapoints [85.0, 90.0] were greater than the threshold (80.0).",
  "StateChangeTime": "2026-03-27T10:30:45.123+0000",
  "Trigger": {
    "MetricName": "CPUUtilization",
    "Namespace": "AWS/EC2",
    "Statistic": "AVERAGE",
    "Period": 300,
    "Threshold": 80.0,
    "ComparisonOperator": "GreaterThanThreshold"
  }
}

Filtro dei messaggi SNS

aws sns set-subscription-attributes \
  --subscription-arn arn:aws:sns:...:production-alerts:abc123 \
  --attribute-name FilterPolicy \
  --attribute-value '{"AlarmName":["HighCPUUtilization"],"NewStateValue":["ALARM"]}'

aws sns set-subscription-attributes \
  --subscription-arn arn:aws:sns:...:production-alerts:abc123 \
  --attribute-name FilterPolicyScope \
  --attribute-value MessageBody

Formattazione personalizzata con Lambda

def lambda_handler(event, context):
    alarm = json.loads(event['Records'][0]['Sns']['Message'])

    message = f"""
ALERT: {alarm['AlarmName']}
Status: {alarm['NewStateValue']}
Reason: {alarm['NewStateReason']}
Resource: {alarm['Trigger']['Dimensions'][0]['value']}
Runbook: https://wiki.example.com/runbooks/high-cpu
    """

    sns.publish(
        TopicArn='arn:aws:sns:...:formatted-alerts',
        Subject=f"{alarm['AlarmName']}",
        Message=message
    )

Catena: il topic degli allarmi grezzi alimenta una Lambda che formatta un messaggio leggibile e lo pubblica sul topic formatted-alerts per l'on-call, mentre i consumer automatici restano sul topic grezzo

Architettura fan-out con SQS

Architettura fan-out in cui un messaggio SNS viene consegnato a più code SQS e a un consumer Lambda

Configurare il fan-out

Quattro passaggi

Crea le code SQS (una per consumer)
Configura le policy della coda (consenti a SNS di inviare)
Iscrivi le code al topic SNS
Implementa i consumer (poll, process, delete)

Policy della coda

{
  "Effect": "Allow",
  "Principal": { "Service": "sns.amazonaws.com" },
  "Action": "sqs:SendMessage",
  "Resource": "arn:aws:sqs:...:alarm-logging-queue",
  "Condition": {
    "ArnEquals": {
      "aws:SourceArn": "arn:aws:sns:...:production-alerts"
    }
  }
}

Iscrivere le code

Iscrivere ogni coda

aws sns subscribe \
  --topic-arn arn:aws:sns:...:production-alerts \
  --protocol sqs \
  --notification-endpoint arn:aws:sqs:...:alarm-logging-queue

Elaborare i messaggi

Pattern del consumer

response = sqs.receive_message(
    QueueUrl=queue_url,
    MaxNumberOfMessages=10,
    WaitTimeSeconds=20       # Long polling
)
for message in response.get('Messages', []):
    sns_msg = json.loads(message['Body'])
    alarm = json.loads(sns_msg['Message'])
    # Process alarm data
    sqs.delete_message(QueueUrl=queue_url,
                       ReceiptHandle=message['ReceiptHandle'])

Fan-out con filtri e dead letter queues

Consegna mirata per sottoscrizione

Coda ticketing: {"NewStateValue":["ALARM"],"Severity":["Critical"]}
Coda logging: nessun filtro (riceve tutto)
Coda metriche: {"MessageType":["Metric"]}

Dead letter queues (DLQ)

aws sqs set-queue-attributes \
  --queue-url https://sqs..../alarm-logging-queue \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:...:alarm-logging-dlq\",\"maxReceiveCount\":\"3\"}"
  }'

SNS vs. SQS: quando usare ciascuno

Confronto tra consegna push di SNS e accodamento pull di SQS

Esempi di architettura

Schema di alert semplice che invia una notifica SNS via email

Schema di elaborazione asincrona con un'API che invia a una coda SQS consumata da un worker

Schema di alert multicanale in cui un allarme si dirama verso più canali di notifica

Schema di pipeline eventi che instrada un evento sorgente verso più code SQS per l'elaborazione

Riepilogo video

I topic SNS recapitano notifiche di allarme via email, SMS, HTTP, Lambda e SQS
Pattern fan-out: un messaggio SNS → più code SQS per elaborazione parallela e affidabile
Il filtro dei messaggi riduce il rumore per subscriber
Le dead letter queues intercettano i messaggi non riusciti
SNS per notifiche push, SQS per elaborazione affidabile; insieme per fan-out affidabile

Esercitiamoci!

Monitoraggio e risoluzione dei problemi su AWS