EventBridge と自動修復の設計パターン

一言まとめ

数値のしきい値は CloudWatch アラーム、状態変化のイベントは EventBridge が担う。EventBridge は Bus(1 対多)/ Pipes(1 対 1)/ Scheduler(時間)の 3 形態。修復は Spot 中断・物理ホスト障害・AZ 不均衡・脅威検知の 4 シナリオと、Config + SSM Automation の組み合わせが定番。

作成 · 更新 · #aws#eventbridge#automation#soa-c03
目次 7 sections
  1. 01 CloudWatch アラームと EventBridge の分担
  2. 02 EventBridge の 3 つの呼び出しパターン
  3. カスタムバスの分割
  4. 03 SNS の位置づけ
  5. 04 自動修復の 4 シナリオ
  6. EC2 ステータスチェックとアクションの対応
  7. 05 AWS Config + SSM Automation による構成修復
  8. 06 関連
  9. 07 更新履歴

調査時点: 2026-07。

CloudWatch アラームと EventBridge の分担#

比較CloudWatch アラームEventBridge
監視対象メトリクス(蓄積された数値)イベント(瞬間的な状態変化・API コール)
例CPU 80% 超、エビクション増加EC2 が終了した、S3 にオブジェクトが置かれた
状態保持する(OK / ALARM)保持しない(ステートレス)
判定時間経過に伴う負荷・容量のしきい値判定状態変化をフックにした自動処理

EventBridge 単体で「2 つのアラームが同時に ALARM」を待つことはできない。AND 条件は CloudWatch の複合アラームで組む。

EventBridge の 3 つの呼び出しパターン#

形態つなぎ方主なソース強み
イベントバス + ルール1 対多(ファンアウト)AWS サービスの状態変化、CloudTrail、自作アプリ、SaaS1 イベントを複数ターゲット(Lambda / SNS / SQS)へ同時配信
Pipes1 対 1(ポイントツーポイント)SQS、DynamoDB Streams、Kinesis Data Streams(ポーリング型)キュー監視の中継コードを書かずに、フィルタ・変換・エンリッチメント(Lambda 呼び出し)を宣言的に定義
Scheduler時間cron / rate / 単発指定数百万タスクの単発実行、タイムゾーン指定。夜間の EC2 / RDS 停止起動など

バスとパイプの違いは、フィルタの位置(バスは出口のルールごと、パイプは入口)と変換の深さ(バスは Input Transformer まで、パイプは Enrichment で Lambda 等を呼べる)。

カスタムバスの分割#

  • 基本はドメイン(注文、決済など)ごとに分ける
  • 加えて本番 / 開発は AWS アカウント単位で物理的に分離し、開発のテストイベントが本番を起動する事故を防ぐ
  • チームが 1 つで規模が小さい、イベント量が少ないなら 1 つのカスタムバスにまとめる。細分化は早すぎる最適化になる

SNS の位置づけ#

Pub/Sub の配信ハブ。トピックにパブリッシャー(CloudWatch アラーム、EventBridge ルール、アプリ)が送り、サブスクライバーが受ける。人間(メール、SMS、モバイルプッシュ)とシステム(SQS、Lambda、HTTPS)を同列に登録できる。

用途構成
システム監視CloudWatch アラーム → SNS → Slack / PagerDuty / メール
コスト管理Budgets / コスト異常検出 → SNS → 財務担当
セキュリティGuardDuty → EventBridge → SNS → 担当者の SMS
ワークフローStep Functions → SNS → 承認メール → API Gateway で再開
ファンアウトSNS → 複数 SQS に同一メッセージをコピー。サブスクライバーごとのメッセージフィルタリングで必要なものだけ通す

自動修復の 4 シナリオ#

トリガー検知修復
Spot インスタンスの 2 分前中断警告EventBridge の EC2 Spot Instance Interruption WarningLambda で対象を ALB ターゲットグループから登録解除(ドレイン)し、代替をプロビジョニング
物理ホスト障害CloudWatch アラーム StatusCheckFailed_Systemアラームアクション「Recover」で別ホストへ自動移設
AZ 間のインスタンス数不均衡Auto Scaling の標準機能AZ 再バランスが自動で平準化(追加設定不要)
脅威検知GuardDuty → EventBridgeSSM Automation で対象 EC2 のセキュリティグループを隔離用に書き換え

EC2 ステータスチェックとアクションの対応#

原因メトリクスアクション挙動
AWS 側の物理ホスト・電源・ネットワーク障害StatusCheckFailed_SystemRecoverインスタンス ID、プライベート IP、EIP、EBS、メタデータを維持したまま別ホストで再起動
OS 内部のハング・カーネルパニック・FS 破損StatusCheckFailed_InstanceReboot(または停止 → 起動)同一ホストで OS を立ち上げ直す

「Everything fails, all the time」の前提で、原因究明より先に復旧を自動化しておく。スパイク時のデータロストは SQS(バッファ + デッドレターキュー)、再試行は Step Functions の指数バックオフで吸収する。

AWS Config + SSM Automation による構成修復#

  • Config のマネージドルール(restricted-ssh、required-tags、EBS 暗号化など)でリソース構成の違反を検知し、Non-compliant イベントを出す
  • 修復(Remediation)に SSM Automation ランブック(AWS-RevokeSecurityGroupIngressFromAnywhere、AWS-DisableIncomingSSHOnPort22 など)を紐付けると、コードなしで自動是正できる
  • 複数リージョン・組織全体へのルール配信は適合パック(Conformance Pack)や組織ルール

役割分担:

  • Config = 発見的・事後(作られた後に検知して直す)
  • SCP = 予防的・事前(そもそも作らせない)。ただし SCP はセキュリティグループの IP パラメータ内容までは判定できない

CloudWatch アラームはメトリクスの監視であり、タグの有無のようなメタデータは評価できない。CloudTrail は操作の記録であり、現在のリソース状態の評価には向かない。SSM Inventory は OS 内の構成を収集する機能であり、適合判定はしない。

関連#

更新履歴#

  • 2026-07-18: 初版(ローカル調査ノート)
  • 2026-10-17: Wiki へ移植、概念ページとして再構成

同じトピック — AWS