--- title: "CloudWatch の電話アラート：EventBridge で Lambda 不要" description: "SNS は電話をかけられず、ペイロードも扱いにくい。CloudWatch アラームを EventBridge 経由で着信 Webhook へ流す設定・フィルタ・注意点。" date: 2026-10-16 author: Nooc authorAvatarLink: /images/avatars/nooc.webp authorLink: https://nooc.me tags: - AWS - CloudWatch - EventBridge - 電話アラート - Webhook - オンコール --- # CloudWatch アラームの電話アラート：EventBridge からスマホへ、Lambda は不要 CloudWatch アラームはあなたに電話をかけられません。組み込みのアクションは SNS、Auto Scaling、EC2、Systems Manager だけで、SNS の行き着く先はメール、SMS、あるいは見張っていなければ気づけないキューです。実際に電話を鳴らすチュートリアルは、Lambda 関数と Twilio アカウントを組み合わせています。どちらも不要です。EventBridge にアラームの状態変化を受け取らせ、小さな JSON ボディに整形して、Echobell の着信チャンネルへ POST すれば済みます。 この記事では経路全体を扱います。チャンネル、EventBridge ルール、入力トランスフォーマー、着信音に意味を持たせ続けるフィルタ、そして SNS を Webhook に直接向けると動きそうに見えてほとんど動かない理由です。 ## 定番の SNS 経路が扱いにくい理由 よくある助言は「アラーム → SNS トピック → サブスクライバー」です。電話にするには、これに 3 つの問題があります。 - **SNS には音声プロトコルがありません。** サブスクライバーの種類はメール、SMS、モバイルプッシュ、SQS、Lambda、Firehose、HTTP(S) です。SMS は見逃しやすく、おやすみモードにも阻まれます。音声通話は自分で作るしかありません。 - **HTTPS のメッセージは文字列の中の文字列です。** SNS はエンベロープを `Content-Type: text/plain` で配信し、アラーム本体は JSON ドキュメントとしてシリアライズされ、エンベロープの `Message` フィールドに入っています。`AlarmName` や `NewStateValue` のようにフィールドを読む Webhook 受信側には、中身の見えないひとかたまりにしか見えません。 - **エンベロープが大きい。** 署名、署名証明書の URL、配信停止リンクだけで、アラームの文面が始まる前に 1 キロバイトを優に超えます。Echobell は通知本文を 1500 バイトで切り詰めるため、「ボディ全部を出す」テンプレートは、肝心な部分が始まるところでちょうど切れてしまいます。 メッセージを取り出して転送する Lambda を置けば SNS でも動かせます。しかし CloudWatch は、アラームの状態変化をすべてきれいな JSON イベントとして EventBridge にすでに発行しています（アクションの設定は不要）。そして EventBridge 自身が、整形して HTTPS エンドポイントを呼べます。 ## 必要なもの - AWS アカウントと、EventBridge のルール、コネクション、API destination を作成する権限 - Echobell のインストール（[App Store](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-cloudwatch-alarm-phone-call-alerts-ja&mt=8) / [Google Play](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid)） - 既存の CloudWatch アラームを少なくとも 1 つ - 10 分 あなた側でインバウンド通信を受け付ける必要はありません。アウトバウンドのリクエストは EventBridge が送ります。 ## ステップ 1 — 鳴るチャンネルを作る Echobell でチャンネルを作り、通知タイプを **着信（Calling）** にします。着信チャンネルはプッシュではなく着信として振る舞うので、iOS の集中モードやおやすみモードを突破します。 ステップ 3 のトランスフォーマーは `alarm`、`state`、`reason`、`region`、`link` のフィールドを持つフラットなボディを送るので、テンプレートは短く済みます。 ``` タイトル: {{state}}: {{alarm}} 本文: {{reason}} ``` 詳細設定で **リンクテンプレート** を設定しておくと、通知をタップしてコンソールでアラームを開けます。 ``` {{link}} ``` チャンネル詳細画面から、チャンネルの Webhook URL をコピーします。 ``` https://hook.echobell.one/t/ ``` ## ステップ 2 — コネクションと API destination を作る EventBridge は **API destination** を通して外部の HTTPS エンドポイントを呼び出し、それには認証情報を持つ **connection** が必要です。Echobell は URL 内の秘密トークンで認証するので、コネクションは形式的なものです。ただし、これがないと EventBridge は destination を作らせてくれません。 1. **EventBridge → Integration → API destinations → Connections → Create connection** を開く 2. **Name**：`echobell` 3. **Authorization type**：**API key** 4. **API key name**：`x-source`、**Value**：`eventbridge` 5. 作成したら **API destinations → Create API destination** へ 6. **Name**：`echobell-calling` 7. **API destination endpoint**：ステップ 1 の Echobell チャンネル URL 8. **HTTP method**：`POST` 9. **Invocation rate limit**：毎秒 `1` 回で十分で、安全弁にもなります 10. **Connection**：`echobell` API キーのヘッダーは毎回のリクエストで送られます。トークンの手前にもう一枚ゲートが欲しければ、Echobell のチャンネル条件で確認できます。 ``` header["x-source"] == "eventbridge" ``` ## ステップ 3 — ルールと入力トランスフォーマーを作る アラームと同じリージョンで **EventBridge → Rules → Create rule** に進みます。ルールはリージョン単位です。`eu-west-1` のアラームは `us-east-1` のルールからは見えません。 **default** イベントバスと **event pattern** ルールを使います。次のパターンは、`ALARM` に遷移したすべてのアラームに一致します。 ```json { "source": ["aws.cloudwatch"], "detail-type": ["CloudWatch Alarm State Change"], "detail": { "state": { "value": ["ALARM"] } } } ``` ターゲットには **EventBridge API destination** を選び、`echobell-calling` を指定します。実行ロールはコンソールに新規作成させてください。この destination に対する `events:InvokeApiDestination` だけが付与され、それ以外は何も付きません。 続けて **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": "