--- title: "Alertes CloudWatch par appel sans Lambda ni Twilio" description: "SNS ne peut pas appeler un téléphone. Routez les alarmes CloudWatch via EventBridge vers un webhook d'appel : mise en place, filtres et pièges." date: 2026-10-16 author: Nooc authorAvatarLink: /images/avatars/nooc.webp authorLink: https://nooc.me tags: - AWS - CloudWatch - EventBridge - alertes par appel - webhooks - astreinte --- # Alertes CloudWatch par appel : d'EventBridge à votre téléphone, sans Lambda Une alarme CloudWatch ne peut pas appeler votre téléphone. Ses seules actions intégrées sont SNS, Auto Scaling, EC2 et Systems Manager, et SNS finit en e-mail, en SMS ou dans une file que vous devez surveiller. Les tutoriels qui font réellement sonner un téléphone montent une fonction Lambda et un compte Twilio. Vous pouvez vous passer des deux : laissez EventBridge recevoir le changement d'état de l'alarme, le remodeler en un petit corps JSON et l'envoyer en POST à un canal d'appel Echobell. Ce guide couvre tout le chemin : le canal, la règle EventBridge, le transformateur d'entrée, les filtres qui gardent la sonnerie pertinente, et pourquoi brancher SNS directement sur le webhook semble devoir fonctionner alors que ce n'est presque jamais le cas. ## Pourquoi la route SNS habituelle devient pénible Le conseil par défaut est « alarme → topic SNS → abonné ». Pour un appel téléphonique, cela pose trois problèmes : - **SNS n'a pas de protocole vocal.** Les types d'abonnés sont e-mail, SMS, push mobile, SQS, Lambda, Firehose et HTTP(S). Le SMS se manque facilement et est bloqué par Ne pas déranger ; un appel vocal demande quelque chose que vous construisez vous-même. - **Le message HTTPS est une chaîne dans une chaîne.** SNS livre son enveloppe avec `Content-Type: text/plain`, et l'alarme est un document JSON sérialisé dans le champ `Message` de l'enveloppe. Un récepteur de webhook qui lit des champs — `AlarmName`, `NewStateValue` — ne trouve qu'un bloc opaque. - **L'enveloppe est volumineuse.** Entre la signature, l'URL du certificat de signature et le lien de désabonnement, l'enveloppe ajoute bien plus d'un kilo-octet avant même que le texte de votre alarme ne commence. Echobell tronque le corps d'une notification à 1500 octets : un modèle « tout déverser » est donc coupé juste là où commence la partie utile. On peut faire fonctionner SNS avec une Lambda qui déballe le message et le retransmet. Mais CloudWatch publie déjà chaque changement d'état d'alarme vers EventBridge sous forme d'événement JSON propre — sans aucune action à configurer — et EventBridge peut le remodeler et appeler lui-même un endpoint HTTPS. ## Ce qu'il vous faut - Un compte AWS et l'autorisation de créer des règles, connexions et API destinations EventBridge - Echobell installé ([App Store](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-cloudwatch-alarm-phone-call-alerts-fr&mt=8) / [Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid)) - Au moins une alarme CloudWatch existante - Dix minutes Rien n'a besoin d'accepter du trafic entrant de votre côté. C'est EventBridge qui émet la requête sortante. ## Étape 1 — Créer un canal qui sonne Dans Echobell, créez un canal et réglez son type de notification sur **Appel**. Un canal d'appel se comporte comme un appel entrant plutôt que comme un push, il traverse donc le mode Concentration d'iOS et Ne pas déranger. Le transformateur de l'étape 3 envoie un corps plat avec les champs `alarm`, `state`, `reason`, `region` et `link`, ce qui garde les modèles courts : ``` Titre : {{state}}: {{alarm}} Corps : {{reason}} ``` Configurez le **modèle de lien** dans les réglages avancés pour qu'un appui sur la notification ouvre l'alarme dans la console : ``` {{link}} ``` Copiez l'URL du webhook du canal depuis la vue détaillée : ``` https://hook.echobell.one/t/ ``` ## Étape 2 — Créer la connexion et l'API destination EventBridge appelle les endpoints HTTPS externes via une **API destination**, qui a besoin d'une **connexion** portant l'authentification. Echobell s'authentifie par le jeton secret présent dans l'URL : la connexion est donc une formalité — mais EventBridge ne crée pas de destination sans elle. 1. Ouvrez **EventBridge → Integration → API destinations → Connections → Create connection** 2. **Name** : `echobell` 3. **Authorization type** : **API key** 4. **API key name** : `x-source`, **Value** : `eventbridge` 5. Créez-la, puis allez dans **API destinations → Create API destination** 6. **Name** : `echobell-calling` 7. **API destination endpoint** : l'URL de votre canal Echobell de l'étape 1 8. **HTTP method** : `POST` 9. **Invocation rate limit** : `1` par seconde suffit largement et sert de soupape de sécurité 10. **Connection** : `echobell` L'en-tête de la clé d'API est envoyé à chaque requête. Vous pouvez le vérifier dans une condition de canal Echobell si vous voulez une seconde barrière devant le jeton : ``` header["x-source"] == "eventbridge" ``` ## Étape 3 — Créer la règle et le transformateur d'entrée Allez dans **EventBridge → Rules → Create rule**, dans la même région que vos alarmes. Les règles sont régionales : une alarme en `eu-west-1` est invisible pour une règle en `us-east-1`. Utilisez le bus d'événements **default** et une règle de type **event pattern**. Ce motif correspond à chaque alarme qui passe en `ALARM` : ```json { "source": ["aws.cloudwatch"], "detail-type": ["CloudWatch Alarm State Change"], "detail": { "state": { "value": ["ALARM"] } } } ``` Pour la cible, choisissez **EventBridge API destination** et sélectionnez `echobell-calling`. Laissez la console créer un nouveau rôle d'exécution — il accorde `events:InvokeApiDestination` pour cette destination et rien d'autre. Puis déployez **Additional settings → Configure target input → Input transformer** : **Input path** ```json { "alarm": "$.detail.alarmName", "state": "$.detail.state.value", "reason": "$.detail.state.reason", "region": "$.region", "time": "$.time" } ``` **Template** ```json { "alarm": "", "state": "", "reason": "", "region": "", "time": "