GPUインスタンス起動失敗を自動検知！EventBridgeとSlackで作るAWSキャパシティ監視アラート

はじめに
課題：「サイレント障害」の恐怖
解決策：イベント駆動の監視アーキテクチャ
EventBridgeルールの設定（コア部分）
実装例（CloudFormationテンプレート）
運用面の工夫
おわりに（シリーズまとめ）

はじめに

AWSのGPUインスタンス確保に向けた戦いを解説する連載も、いよいよ今回が最終回です。

これまでに「リトライ処理」「フォールバック戦略」「容量予約（ODCR）」「AWS Batchへの移行」と、アーキテクチャを堅牢にするための様々な手法を紹介してきました。

しかし、どれだけ対策をしても「すべてのAZで本当に在庫が枯渇している」「設定ミスで代替インスタンスが起動できない」といった事態は起こり得ます。

今回は運用・SREの視点から、「ユーザーからクレームが来る前に、GPUの確保失敗（サイレント障害）をいち早く検知する監視の仕組み」の構築方法を解説します。

課題：「サイレント障害」の恐怖

バッチ処理や自動化スクリプトでEC2を起動している場合、起動に失敗したときの監視が漏れていると以下のような事態に陥ります。

Lambdaの起動スクリプトがエラーを出してひっそりと終了している。
AWS Batchのジョブキューにタスクが延々と溜まり続けている（RUNNABLE状態のまま）。
ユーザーから「画像生成（またはAI推論）の処理が1時間経っても終わらないんですが…」と問い合わせが来て、初めて障害に気づく。

インフラ運用において、「システムが止まっていることに、顧客からの連絡で気づく」というのは最悪のパターンです。これを防ぐために、AWSのイベントをフックしてSlackへ即時通知する仕組みを作ります。

解決策：イベント駆動の監視アーキテクチャ

AWSでは、APIの呼び出し履歴（CloudTrail）やリソースの状態変化を Amazon EventBridge でリアルタイムに検知できます。

今回は以下のような流れで、Slackへアラートを飛ばすアーキテクチャを構築します。

CloudTrail: EC2の起動（RunInstances）APIのエラーを記録。
EventBridge: InsufficientInstanceCapacity（在庫不足エラー）をピンポイントで検知。
Amazon SNS: メッセージの受け渡し（トピック）。
AWS Chatbot: SNSからの通知を整形し、Slackチャンネルへ送信。

EventBridgeルールの設定（コア部分）

この仕組みの心臓部となるのが、EventBridgeの「イベントパターン」です。
以下のようなJSONを定義することで、「EC2の起動時に容量不足エラーが出た瞬間」だけをキャッチできます。

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["RunInstances"],
    "errorCode": [
      "InsufficientInstanceCapacity",
      "InsufficientCapacity"
    ]
  }
}

注意: この検知を行うには、対象リージョンで CloudTrailの証跡（Trail） が有効になっている（管理イベントが記録されている）必要があります。

実装例（CloudFormationテンプレート）

コンソールからポチポチ設定しても良いですが、Infrastructure as Code (IaC) として管理するのがベストプラクティスです。
SNSトピックとEventBridgeルールを作成するCloudFormation（YAML）の例を紹介します。

AWSTemplateFormatVersion: '2010-09-09'
Description: "Alert for EC2 InsufficientInstanceCapacity"

Resources:
  # 1. Slack通知用のSNSトピック
  GpuAlertSnsTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: gpu-capacity-alert-topic

  # 2. SNSトピックのアクセスポリシー（EventBridgeからの発行を許可）
  SnsTopicPolicy:
    Type: AWS::SNS::TopicPolicy
    Properties:
      Topics:
        - !Ref GpuAlertSnsTopic
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: events.amazonaws.com
            Action: sns:Publish
            Resource: !Ref GpuAlertSnsTopic

  # 3. EventBridge ルール
  CapacityErrorEventRule:
    Type: AWS::Events::Rule
    Properties:
      Name: detect-insufficient-capacity
      Description: "Detect EC2 RunInstances InsufficientInstanceCapacity errors"
      State: ENABLED
      EventPattern:
        source:
          - aws.ec2
        detail-type:
          - "AWS API Call via CloudTrail"
        detail:
          eventSource:
            - ec2.amazonaws.com
          eventName:
            - RunInstances
          errorCode:
            - InsufficientInstanceCapacity
            - InsufficientCapacity
      Targets:
        - Arn: !Ref GpuAlertSnsTopic
          Id: "SnsTarget"

このテンプレートをデプロイした後、AWS Chatbot のコンソールからSlackワークスペースを連携し、作成したSNSトピック（gpu-capacity-alert-topic）を紐付ければ設定完了です。

運用面の工夫

アラートが鳴った後の「運用フロー（プレイブック）」を決めておくことも重要です。

一次対応: Slackのアラートを見たら、まずは対象のジョブがどのくらい遅延しても許容されるビジネスなのかを確認する。
二次対応: 長時間空きが出ない場合は、第3回で紹介した「オンデマンド容量予約」を手動で確保しにいくか、別リージョン（大阪リージョンや海外など）へ処理を逃がす運用を検討する。

エラーを検知し、素早くアクションを起こせる体制を作ることで、ビジネスへの影響を最小限に抑えることができます。

おわりに（シリーズまとめ）

全5回にわたって、AWSにおけるGPUインスタンス枯渇への対策をお届けしてきました。

AWS GPUインスタンスが起動しない！InsufficientInstanceCapacityとAPI制限エラーの正しい対処法
GPUインスタンスの枯渇を回避！複数AZ・代替インスタンスタイプを活用したEC2起動戦略
どうしてもGPUが必要な処理に！AWS「オンデマンド容量予約」と「Capacity Blocks」入門
自作EC2スクリプトから卒業！AWS Batchを活用したGPUタスクの確実なジョブキューイング
GPUインスタンス起動失敗を自動検知！EventBridgeとSlackで作るAWSキャパシティ監視アラート（本記事）

コードレベルのリトライ処理から始まり、アーキテクチャの進化、そして監視運用まで、これらのノウハウが皆様の安定したAI/ML基盤構築の助けになれば幸いです！