TL;DR(要約)

RDSのイベント通知をAWS Chatbot経由でSlackに通知する方法とはまりポイントについて記載する。
RDS→Amazon EventBridge→SNS→AWS Chatbot→Slackという流れで実現可能。
SNSのアクセスポリシーには要注意。

何故この通知を実装する必要があるか？

RDSのフェイルオーバー等のイベントはCloudWatchのメトリクスにない。

そのため、フェイルオーバー等のイベントが発生した場合、それをキャッチするためにはイベント通知を実装する必要がある。

RDSのイベントの種類については下記参照。

docs.aws.amazon.com

CloudWatchAlarmをAWS Chatbot経由で通知するのはかなり一般的であるが、イベント通知もAWS Chatbot経由で通知するとChatbot側でいい感じに整形してSlackに通知してくれるのでとても便利。前はこの辺りはLambdaで作り込まなければいけなかった。

Monitoring AWS services using AWS Chatbot - AWS Chatbot

通知を実装する選択肢

イベント通知の方法は下記の方法があるが、個人的にはAmazon EventBridgeに集約した方が管理しやすいので大体後者で実装する。

RDSのイベントサブスクリプションで直接SNSに送る
Amazon EventBridgeを経由させてSNSに送る

dev.classmethod.jp

それぞれのコンポーネントの設定内容

Amazon EventBridge

イベントパターン

{
  "source": ["aws.rds"],
  "detail-type": ["RDS DB Cluster Event", "RDS DB Instance Event"]
}

ターゲット

後述のSNSを指定する。

Event通知が失敗する場合は下記参照

EventBridge通知を受信しないAmazonSNSのトラブルシューティング

SNS

SNS自体は普通に作成すれば良いがアクセスポリシーは要注意

注意点としては"events.amazonaws.com"の条件説でAWS:SourceOwnerで絞らないこと。

ここを絞ってしまったことでかなり私はハマってしまった。

失敗した理由としてはeventsの発行元は自アカウント外（AWSの管理）のため、アクセスポリシーで絞ってしまうとそこから自アカウントのSNSにアクセスできなく、エラーが発生していた。

エラーも自アカウントのSNSの配信ログに残らないため、原因不明で特定にかなり時間がかかった。

結論、以下のようにアクセスポリシーを設定すれば良い。 SNSをKMSで暗号化している場合は以下アクセスポリシーにKMSの権限も付与する必要があるので要注意。

{
  "Version": "2012-10-17",
  "Id": "__chatbot_policy_ID",
  "Statement": [
    {
      "Sid": "cloudwatch",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudwatch.amazonaws.com"
      },
      "Action": [
        "SNS:Subscribe",
        "SNS:Receive",
        "SNS:Publish"
      ],
      "Resource": "arn:aws:sns:ap-northeast-1:xxxxxxxxx:my-sns",
      "Condition": {
        "StringEquals": {
          "AWS:SourceOwner": "xxxxxxxxx"
        }
      }
    },
    {
      "Sid": "cloudwatchevents",
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "SNS:Publish",
      "Resource": "arn:aws:sns:ap-northeast-1:xxxxxxxxx:my-sns"
    }
  ]
}