目次

AWS Health 完全ガイド v2.0

AWS リソースのヘルスイベント・インシデント管理

AWS Health は、AWS リソース・サービス・アカウントに影響する AWS イベント（障害・メンテナンス・セキュリティ通知）をリアルタイムで通知する Management & Governance サービス である。Personal Health Dashboard で自分のアカウント固有のイベントを監視し、EventBridge・Lambda・SNS と連携して自動通知・自動対応を実現する。Organizations 全体のヘルスイベント集約・Slack / Teams への統合・SLA 監視にも利用される。本ドキュメントは AWS Health の概念・イベントタイプ・自動対応パターン・ベストプラクティスを体系的に解説。

ドキュメントの目的

本ガイドは以下を対象としています。

  • SRE / インフラエンジニア向け：AWS Health イベント検知・自動対応のワークフロー構築
  • DevOps エンジニア向け：EventBridge・Lambda による自動復旧パイプライン
  • セキュリティチーム向け：セキュリティ脆弱性・ハードウェア障害の事前対応
  • 運用マネージャー向け：Organizations 全体のヘルス監視・SLA 管理
  • 意思決定者向け：Azure Service Health・GCP Status Dashboard との比較

2025-2026 年の AWS Health エコシステム

  • AI 駆動のインシデント予測：機械学習で障害予兆を検出、事前アラート
  • 自動修復の高度化：Systems Manager Automation との深い統合、セルフヒーリング基盤
  • マルチリージョン・マルチアカウント集約強化：AWS Resilience Hub との統合でアーキテクチャレベルの冗長性を可視化
  • カスタムイベントルール拡大：顧客定義イベントを Health Dashboard に統合
  • SLA 監視の自動化：CloudWatch メトリクスとして Health イベント SLA を追跡

目次

  1. 概要・課題・特徴
  2. AWS Health が解決する課題
  3. 主な特徴
  4. アーキテクチャ・イベントフロー
  5. イベントタイプ詳細
  6. コアコンポーネント
  7. 主要ユースケース（10+）
  8. 設定・操作の具体例
  9. 類似サービス比較表
  10. ベストプラクティス
  11. トラブルシューティング
  12. 2025-2026 最新動向
  13. 学習リソース・参考文献
  14. 実装チェックリスト・導入ロードマップ
  15. まとめ

概要・課題・特徴

本質

AWS Health は「自分の AWS アカウント・リソースに影響する AWS イベントをリアルタイムに検知・通知するサービス」。

汎用の AWS Service Health Dashboard（全ユーザー向けの公開ステータスページ）とは異なり、自分のアカウントで使用しているリソースへの影響のみをフィルタリング して表示する。EC2 ホストメンテナンス・EBS ボリューム移行・RDS アップグレード・セキュリティ脆弱性・サービス障害などのイベントを事前に通知し、計画的な対応・自動復旧を実現する。

AWS Health が解決する課題

課題 AWS Health の解決策
計画メンテナンスの不意打ち 事前通知 → 計画的な対応・移行スケジューリング可能
本番サービス停止への対応遅延 リアルタイムイベント通知 → MTTD（平均検出時間）短縮
スポットインスタンス中断の対応 中断通知を EventBridge で受け取り → 自動フリート補充で No SLA breach
セキュリティ脆弱性への手動対応 脆弱性アラート → Lambda で自動パッチ適用
Organizations 全体のヘルス可視化 管理アカウントから全メンバーアカウントのイベント一元監視
本番環境の突然のサービス停止 イベント → EventBridge → Lambda → 自動フェイルオーバー

主な特徴

1. Personal Health Dashboard（PHD）

アカウント固有のヘルスイベント監視

対象:
  ✓ 自分の EC2 インスタンス・EBS ボリューム
  ✓ 自分の RDS インスタンス
  ✓ 自分の Lambda 関数・レイヤー
  ✓ 自分の DynamoDB テーブル
  ✓ 使用しているサービスのセキュリティ通知

特徴:
  → 無料（全 AWS ユーザーで利用可能）
  → セットアップ不要（AWS Management Console から即利用）
  → リアルタイムで最新イベント表示

2. Service Health Dashboard（SHD）との違い

┌──────────────────────┬──────────────────────┬──────────────────────┐
│ 観点                 │ Service Health       │ Personal Health      │
│                      │ Dashboard（公開）    │ Dashboard（個人）    │
├──────────────────────┼──────────────────────┼──────────────────────┤
│ 対象                 │ 全ユーザー向け       │ 自分のアカウント向け │
│ 情報粒度             │ サービス全体の状態   │ 自リソースへの影響   │
│ 例                   │ us-east-1 EC2 ダウン │ 自 EC2 i-xxx に影響 │
│ 事前通知             │ なし（障害時のみ）  │ あり（計画的対応用）│
│ API サポート         │ なし                 │ あり                 │
│ EventBridge 連携    │ なし                 │ あり                 │
│ 料金                 │ 無料                 │ 無料 / API 有料      │
└──────────────────────┴──────────────────────┴──────────────────────┘

3. EventBridge 統合による自動対応

フロー:
  AWS Health Event
    ↓ EventBridge で検知
  Rule（フィルター）
    ↓ サービス・イベントタイプで条件判定
  Target（自動実行）
    ├─ Lambda（自動復旧・スケーリング）
    ├─ SNS（Slack 通知）
    ├─ SQS（キューイング）
    └─ Systems Manager Automation（自動実行ドキュメント）

4. Organizations サポート

管理アカウントから全メンバーアカウントのイベント一元監視

前提: Business / Enterprise / Enterprise On-Ramp サポートプラン加入

機能:
  ✓ describe-events-for-organization：全アカウントイベント取得
  ✓ describe-affected-entities-for-organization：影響リソース一覧
  ✓ 一元ダッシュボード：全アカウントの Health 状態可視化

AWS Health が解決する課題

ビジネス課題

  1. 本番サービスの計画メンテナンス対応

    • AWS が EC2 ホストメンテナンスを定期実施する際、事前通知がないと不意打ちで停止
    • AWS Health で事前通知 → テスト→ 本番切り替え計画を立てられる

  2. スポットインスタンス中断への即応

    • スポットインスタンス中断時は 2 分の警告
    • AWS Health イベント → EventBridge で自動フリート補充 → No SLA breach

  3. セキュリティ脆弱性の手動対応コスト

    • 脆弱性公開 → 全インスタンス手動調査・パッチが負担
    • AWS Health アラート → Lambda 自動パッチ適用で対応時間 90% 削減

  4. 複数データセンターの冗長性確保

    • AZ 全体ダウン時の自動フェイルオーバーが未設定だと長時間停止
    • Health イベント → Lambda → 別 AZ への自動フェイルオーバー

技術課題

  1. リアルタイムイベント検知

    • 障害時に Status Page を確認するだけでは遅い
    • EventBridge でプログラマティックに検知・自動対応

  2. マルチリージョン監視の複雑さ

    • 5+ リージョン運用時、各リージョンの Personal Health Dashboard を別々に確認は非効率
    • Organizations で一元監視

  3. ステートレスな自動復旧

    • 単なるアラートではなく、自動的に復旧アクション実行
    • Lambda / Systems Manager で自動修復パイプライン構築

主な特徴

イベントライフサイクル

graph LR
    A["AWS インフライベント<br/>EC2 メンテナンス"] --> B["Health Event生成"]
    B --> C["Personal Health<br/>Dashboard 表示"]
    C --> D["EventBridge<br/>Rule トリガー"]
    D --> E["Lambda<br/>自動対応"]
    E --> F["Slack 通知<br/>+<br/>自動修復実行"]
    
    C -.-> G["CloudTrail<br/>ログ記録"]
    E -.-> G
    
    style A fill:#ffcccc
    style F fill:#ccffcc

AWS Health イベント分類

イベントカテゴリ（主要 3 つ）:

1. Operational Issue（運用上の問題）
   - リアルタイム障害
   - 例：us-east-1 EC2 パフォーマンス低下、RDS 接続エラー
   - Status: Open（解決まで）

2. Scheduled Change（スケジュール済み変更）
   - AWS がスケジュールした計画メンテナンス
   - 例：EC2 ホスト定期メンテナンス、RDS メンテナンスウィンドウ
   - Status: Upcoming → In Progress → Closed
   - 対応例：事前にリソース移行・テスト実施

3. Account Notification（アカウント通知）
   - セキュリティ脆弱性・リタイア予定・規制準拠
   - 例：古い EC2 インスタンスタイプリタイア、SSL/TLS 脆弱性
   - Status: Open（対応後 Closed）

アーキテクチャ・イベントフロー

Health イベント検知 → 自動対応フロー

Step 1: AWS Health Event 発生
  例) "EC2 Host maintenance scheduled"
      Resource: i-0123456789abcdef0
      Start Time: 2026-04-27 02:00 UTC
      Status: Upcoming

Step 2: EventBridge で検知
  Rule:
    Source: aws.health
    Event Type: AWS Health Event
    Service: EC2
    EventTypeCategory: scheduledChange

Step 3: Lambda で自動対応
  def lambda_handler(event, context):
    detail = event['detail']
    instance_id = detail['affectedEntities'][0]['entityValue']
    
    # Step 3a: インスタンス停止
    ec2 = boto3.client('ec2')
    ec2.stop_instances(InstanceIds=[instance_id])
    
    # Step 3b: AMI 作成（復旧用）
    ec2.create_image(InstanceId=instance_id, Name=f"backup-{instance_id}")
    
    # Step 3c: Slack 通知
    sns = boto3.client('sns')
    sns.publish(
      TopicArn='arn:aws:sns:...:health-alerts',
      Message=f"EC2 メンテナンス開始：{instance_id} が停止しました"
    )

Step 4: 結果ログ記録
  CloudTrail に全自動アクション記録
  → 監査証跡を完全に保持

マルチアカウント集約

Organizations 構成:

Management Account（管理）
  │
  ├─ HealthAggregator Lambda
  │  ├─ describe-events-for-organization
  │  │  → 全メンバーアカウントの Health イベント取得
  │  │
  │  ├─ フィルター
  │  │  Open or Upcoming イベントのみ
  │  │
  │  └─ ダッシュボード集約
  │     → QuickSight / CloudWatch で可視化
  │
  ├─ Member Account A（Dev）
  │  └─ EC2・RDS 運用
  │
  └─ Member Account B（Prod）
     └─ EC2・RDS 運用
        （Health イベントはこのアカウントで発生）

イベントタイプ詳細

1. Scheduled Change（計画変更）

主要イベント:

EC2 Host Maintenance
  → EC2 インスタンスが実行中のハードウェアの定期メンテナンス
  → 影響：インスタンス再起動必須
  → 対応例：
     - 別 AZ の インスタンスへの事前移行
     - EIP（Elastic IP）を別インスタンスに付け替え
     - ALB Target Group を別インスタンスに切り替え

RDS Maintenance Window
  → RDS エンジンアップグレード・パッチ適用
  → 影響：数秒～数分のダウンタイム
  → 対応例：
     - Read Replica フェイルオーバー
     - Aurora の場合：レプリケーション遅延なし

Aurora MySQL バージョンアップ
  → Aurora エンジンのメジャーバージョン更新
  → 影響：互換性確認必須
  → 対応例：Blue/Green デプロイで事前検証

Lambda ランタイムリタイア
  → Python 3.9 など古いランタイムの廃止予定
  → 影響：事前に新ランタイムへ移行必須
  → 対応例：Lambda 関数の一括 updateFunctionConfiguration

EBS ボリューム最適化
  → ボリュームタイプの段階的廃止（gp2 → gp3）
  → 対応例：計画的な gp3 へのマイグレーション

2. Operational Issue（運用上の問題）

主要イベント:

Service Availability Issues
  → リージョン / AZ レベルのサービス障害
  → 例：us-east-1 EC2 API レスポンスタイム低下
  → Status: Open（解決まで） → Closed

Performance Degradation
  → リソースのパフォーマンス低下
  → 例：Redshift クラスター遅延増加
  → 対応例：CloudWatch メトリクス確認 / ノード追加

Hardware Issue
  → ハードウェア障害検出
  → 例：EBS ボリューム I/O エラー
  → 対応例：スナップショット → 新ボリュームへの復元

API Throttling
  → API リクエストレート制限
  → 例：Lambda Concurrency 上限到達
  → 対応例：自動スケーリング・リクエストバックオフ

3. Account Notification（アカウント通知）

主要イベント:

Security Advisory
  → AWS リソースに影響する脆弱性公開
  → 例：EC2 AMI に Linux カーネル脆弱性
  → 対応例：
     - 脆弱性 ID で影響インスタンス特定
     - セキュリティパッチ適用
     - 自動スキャンで合致インスタンス一覧化

Resource Retirement Notification
  → リソースタイプのリタイア予定通知
  → 例：
     - t2 インスタンスタイプが 2026 年 12 月リタイア予定
     - MySQL 5.7 が 2027 年 9 月にサポート終了
  → 対応例：t3 / MySQL 8.0 への事前移行

Billing Alert
  → 異常な使用量 / 請求増加
  → 例：Lambda コンカレント実行数が前月比 200% 増加
  → 対応例：コスト最適化 / ユースケース検証

Compliance Notification
  → 規制準拠要件の通知
  → 例：HIPAA 準拠リソースが非準拠状態に変更
  → 対応例：AWS Config による準拠状態復帰

コアコンポーネント

1. Health Dashboard（AWS Console）

機能:

Events ページ
  → イベント一覧（Open / Upcoming / Closed）
  → フィルター：サービス・リージョン・イベントカテゴリ

Affected Resources
  → 各イベントで影響を受ける自分のリソース一覧
  → 例：EC2 メンテナンス → i-0123... / i-4567...

Timeline
  → イベント時系列表示
  → 対応のドキュメント化

Affected Accounts（Organizations）
  → 全メンバーアカウント向けイベント表示

2. Health API

主要オペレーション:

describe-events
  → Personal Health Dashboard の個別アカウント向けイベント取得
  
  aws health describe-events \
    --filter eventStatusCodes=open,upcoming \
    --region us-east-1

describe-events-for-organization
  → Organizations 全体のイベント取得（管理アカウントのみ）
  
  aws health describe-events-for-organization \
    --filter eventStatusCodes=open

describe-affected-entities
  → 個別アカウントの影響リソース取得

describe-affected-entities-for-organization
  → Organizations 全体の影響リソース取得

3. EventBridge 統合

Event Source: aws.health

Rule 例:

EC2 メンテナンス 2 時間前の通知 + Lambda 実行
{
  "Name": "ec2-maintenance-notification",
  "EventPattern": {
    "source": ["aws.health"],
    "detail-type": ["AWS Health Event"],
    "detail": {
      "service": ["EC2"],
      "eventTypeCategory": ["scheduledChange"],
      "eventTypeCode": ["EC2 Host Maintenance Scheduled"]
    }
  },
  "Targets": [
    {
      "Arn": "arn:aws:lambda:...",
      "RoleArn": "arn:aws:iam::...:role/EventBridgeRole"
    }
  ]
}

RDS メンテナンス → Slack 通知
{
  "source": ["aws.health"],
  "detail": {
    "service": ["RDS"],
    "eventTypeCategory": ["scheduledChange"]
  }
}
→ SNS Topic → Slack Lambda → Slack

スポットインスタンス中断 → 自動フリート補充
{
  "source": ["aws.health"],
  "detail": {
    "service": ["EC2"],
    "eventTypeCode": ["EC2 Spot Instance Interruption Warning"]
  }
}
→ Lambda（Auto Scaling Group に新インスタンス追加）

4. CloudWatch メトリクス連携

Health イベント → CloudWatch メトリクス化

メトリクス例:

HealthEventCount
  → EventTypeCategory=scheduledChange のイベント数
  → CloudWatch アラーム：重要イベント 5 件以上 → SNS

TimeToResolution
  → イベント発生～解決までの時間
  → SLA 管理（例：2 時間以内に解決すべき）

AffectedResourceCount
  → 各イベントで影響を受けるリソース数
  → 影響度合いの可視化

主要ユースケース

1. EC2 メンテナンスの計画的対応

シナリオ:
  AWS から「2026-04-27 02:00 UTC に EC2 ホストメンテナンス」通知

従来（Health なし）:
  → 予期しない再起動 → サービス停止 → 顧客に謝罪
  → MTTD 無し = 回復時間が長い

Health + EventBridge の場合:
  Step 1: Health Event 発生
    EventType: EC2 Host Maintenance Scheduled
    Time: 2026-04-27 02:00 UTC

  Step 2: EventBridge Rule トリガー
    Rule: "ec2-maintenance-7day-alert"
    発火：イベント検知 7 日前

  Step 3: Lambda 自動実行
    def lambda_handler(event, context):
      instance_id = event['detail']['affectedEntities'][0]['entityValue']
      
      # ステップ 3a: EIP 取得
      eip = ec2.describe_addresses(Filters=[
        {'Name': 'instance-id', 'Values': [instance_id]}
      ])['Addresses'][0]
      
      # ステップ 3b: スタンバイインスタンス起動
      standby = ec2.run_instances(ImageId=ami_id, MinCount=1, MaxCount=1)
      standby_id = standby['Instances'][0]['InstanceId']
      
      # ステップ 3c: EIP 再割り当て
      ec2.associate_address(InstanceId=standby_id, AllocationId=eip['AllocationId'])
      
      # ステップ 3d: ALB Target Group 切り替え
      elbv2 = boto3.client('elbv2')
      elbv2.deregister_targets(
        TargetGroupArn=tg_arn,
        Targets=[{'Id': instance_id}]
      )
      elbv2.register_targets(
        TargetGroupArn=tg_arn,
        Targets=[{'Id': standby_id}]
      )

  Step 4: Slack 通知
    SNS → Slack Lambda
    Message: "EC2 メンテナンス：i-0123 から i-4567 へ切り替え完了"

  結果: SLA 維持、ダウンタイム 0（Blue/Green 切り替え）

2. スポットインスタンス中断への自動対応

シナリオ:
  スポット価格上昇 → AWS が 2 分後に中断予定

従来（Health なし）:
  → 2 分後に突然停止 → アプリケーション停止

Health + EventBridge:
  Step 1: Spot Interruption Warning（2 分前）
    Event: "EC2 Spot Instance Interruption Warning"
    AffectedEntities: [i-spot-001, i-spot-002, ...]

  Step 2: Lambda 自動実行
    asg = boto3.client('autoscaling')
    asg.set_desired_capacity(
      AutoScalingGroupName='spot-fleet-asg',
      DesiredCapacity=current + 3  # 新インスタンス 3 つ追加
    )

  Step 3: オンデマンドインスタンスが即座に起動
    → トラフィック引き継ぎ完了
    → スポットインスタンス中断しても SLA breach なし

コスト削減: オンデマンド費用 30% vs スポット 60% オフ活用

3. RDS メンテナンスの計画的タイミング

シナリオ:
  RDS MySQL 8.0 アップグレード通知
  デフォルト："自動メンテナンスウィンドウに実施"

Health 活用:
  Step 1: AWS Health で通知受取
    EventType: "RDS DB Instance Maintenance Scheduled"
    StartTime: "2026-04-28 03:00 JST"

  Step 2: チームで対応検討
    - テスト環境で事前アップグレード検証
    - 本番環境のメンテナンスウィンドウ変更要求（ビジネス時間外）

  Step 3: Lambda で自動テスト
    rds = boto3.client('rds')
    
    # Read Replica で事前テスト
    rds.modify_db_instance(
      DBInstanceIdentifier='test-replica',
      EngineVersion='8.0.latest',
      ApplyImmediately=True
    )
    
    # 10 分後に互換性チェック
    # → Slack で結果報告

  Step 4: 本番アップグレード実行
    rds.modify_db_instance(
      DBInstanceIdentifier='prod-mysql',
      EngineVersion='8.0.latest',
      PreferredMaintenanceWindow='mon:01:00-mon:02:00',  # 日本時間 10 時～11 時
      ApplyImmediately=False  # ウィンドウで実施
    )

結果: 計画的で低リスクなアップグレード

4. セキュリティ脆弱性の自動対応

シナリオ:
  AWS Health: "Linux kernel vulnerability affecting EC2"
  脆弱性 CVE-XXXX-XXXXX

Health + Lambda + Systems Manager:
  Step 1: 脆弱性アラート受取
    EventType: "AWS Health Security Advisory"
    AffectedResources: [AMI-001, AMI-002, ...]

  Step 2: Lambda が影響インスタンス特定
    ec2 = boto3.client('ec2')
    instances = ec2.describe_instances(Filters=[
      {'Name': 'image-id', 'Values': ['ami-001', 'ami-002']}
    ])
    
    affected_ids = [i['InstanceId'] for r in instances['Reservations'] 
                    for i in r['Instances']]

  Step 3: Systems Manager で自動パッチ
    ssm = boto3.client('ssm')
    ssm.send_command(
      InstanceIds=affected_ids,
      DocumentName='AWS-RunShellScript',
      Parameters={'commands': [
        'yum update -y',
        'reboot'
      ]}
    )

  Step 4: パッチ適用結果を CloudWatch に記録
    → Compliance ダッシュボード更新

結果: 脆弱性検出～パッチ適用を数分で自動化

5. Organizations マルチアカウント監視

シナリオ:
  5 つのメンバーアカウント（Dev・Test・Staging・Prod 東・Prod 西）を一元監視

Management Account での実装:
  Step 1: Lambda で Organizations API 呼び出し
    health = boto3.client('health')
    
    events = health.describe_events_for_organization(
      Filter={
        'eventStatusCodes': ['open', 'upcoming']
      }
    )
    
    # メンバーアカウント・サービス別に分類
    for event in events['events']:
      account_id = event['arn'].split(':')[4]
      service = event['service']
      
      # CloudWatch メトリクス記録
      cloudwatch.put_metric_data(
        Namespace='HealthAggregator',
        MetricData=[{
          'MetricName': f'{service}-{account_id}',
          'Value': 1,
          'Unit': 'Count'
        }]
      )

  Step 2: QuickSight で一元ダッシュボード
    CloudWatch メトリクス → QuickSight Dataset
    
    ダッシュボード:
      - アカウント別イベント数
      - サービス別イベント分布
      - 重要度別イベントリスト（Prod > Test > Dev）

  Step 3: Slack アラート
    Critical events（Prod アカウント）
      → #ops-critical Slack チャネル

結果: 5 アカウントを 1 ダッシュボードで一元管理

6. SLA 監視・自動レポート生成

シナリオ:
  本番サービスの SLA 目標：ダウンタイム < 1 時間/月

実装:
  Step 1: Health Event → CloudWatch メトリクス化
    IncidentCount: Open Operational Issues 数
    TimeToResolution: 各イベントの解決時間
    AffectedResourceCount: 影響度

  Step 2: CloudWatch Logs Insights で集計
    fields @timestamp, service, status
    | filter status == "Closed"
    | stats sum(timeToResolution) as total_downtime by service

  Step 3: 月 1 回自動レポート生成
    Lambda (CloudWatch Logs Insights クエリ)
      → SLA 達成状況（✅ / ❌）
      → 事件詳細分析
      → PDF レポート生成（QuickSight）
      → Slack / メール配信

  Step 4: 関係者への定期報告
    Prod Account: ダウンタイム 45 分（SLA OK）
    Test Account: ダウンタイム 0 分（SLA OK）

7. キャパシティプランニング

シナリオ:
  Health Event で「Lambda Concurrency approaching limit」

対応:
  Step 1: イベント受取
    EventType: "Operational Issue"
    Detail: "Lambda concurrent executions at 90% of quota"

  Step 2: Lambda で自動スケール判定
    sq = boto3.client('service-quotas')
    quota = sq.get_service_quota(
      ServiceCode='lambda',
      QuotaCode='L-B99A9384'  # Concurrent executions
    )
    
    if utilization > 80:
      # クォータ引き上げリクエスト
      sq.request_service_quota_increase(
        ServiceCode='lambda',
        QuotaCode='L-B99A9384',
        DesiredValue=quota['ServiceQuota']['QuotaValue'] * 2
      )

  Step 3: 承認まで待つ間、一時的なスロットリング対策
    sqs = boto3.client('sqs')
    
    # Lambda が処理しきれないリクエストを SQS キュー化
    # → 別リージョン Lambda で処理（負荷分散）

結果: キャパシティ限界前に事前拡張

8. クロスリージョン冗長性の自動検証

シナリオ:
  東京リージョン（ap-northeast-1）で障害

Health Event:
  Region: ap-northeast-1
  Service: EC2
  EventType: "Service Availability Issue"

自動応答:
  Step 1: 東京リージョンのリソース影響確認
    affected = health.describe_affected_entities(
      Filter={'eventArn': event_arn}
    )

  Step 2: 大阪リージョンへのフェイルオーバー実行
    # Route 53 ヘルスチェック自動変更
    r53 = boto3.client('route53')
    r53.change_resource_record_sets(
      HostedZoneId='Z...',
      ChangeBatch={
        'Changes': [{
          'Action': 'UPSERT',
          'ResourceRecordSet': {
            'Name': 'api.example.com',
            'Type': 'A',
            'SetIdentifier': 'Tokyo',
            'Failover': 'SECONDARY',  # 東京は予備に変更
            'HealthCheckId': '...'
          }
        }]
      }
    )

  Step 3: 大阪リージョンの DNS を Primary に
    # Primary failover rule がアクティブになる

結果: リージョン障害を自動検出 → DNS フェイルオーバー

9. 機械学習による障害予測（未来の活用）

現状（2025）:
  Health Event は AWS インフラ側で検出した「現在の問題」通知

将来（2026+）:
  AWS Health + ML による「3 日後に障害予測」

例:
  Health ML Model が以下を検出:
    - CPU 使用率トレンド + メモリ増加傾向
    - ディスク I/O エラー率上昇
    - ネットワークレイテンシー増加

  Health Event:
    "EC2 Hardware Degradation Predicted"
    Confidence: 85%
    EstimatedTimeToFailure: 72 hours

  自動対応:
    → スナップショット + 新インスタンス作成
    → DNS フェイルオーバー設定

10. コンプライアンス監査

シナリオ:
  SOC 2 Type II 監査で「AWS インフラ変更の記録」確認

Health イベント ← → CloudTrail：2 つのレイヤーで記録

例:
  Event: RDS Maintenance Scheduled
    → Health API で検知
    → Health Dashboard に表示
    → CloudTrail に「Health API 呼び出し」記録

  Event: EC2 ホスト移行（AWS が自動実施）
    → Health Event で通知
    → Lambda が自動対応実行
    → CloudTrail に「Lambda 実行・EC2 변경」記録

結果: AWS インフラ変更の完全な監査証跡を取得

設定・操作の具体例

CLI 例

# 自アカウントのオープンイベント取得
aws health describe-events \
  --filter 'eventStatusCodes=open' \
  --region us-east-1 \
  --query 'events[].[service,eventTypeCode,startTime,statusCode]' \
  --output table

# Organizations 全体のイベント取得（管理アカウントのみ）
aws health describe-events-for-organization \
  --filter 'eventStatusCodes=open,upcoming' \
  --query 'events[].[arn,service,statusCode]'

# 特定イベントの影響リソース取得
aws health describe-affected-entities \
  --filter 'eventArns=arn:aws:health:region:account:event/service/eventid' \
  --query 'entities[].[entityArn,entityValue,lastUpdatedTime]'

# Organizations 全体の影響リソース取得
aws health describe-affected-entities-for-organization \
  --organization-entity-filters '[{
    "eventArn": "arn:aws:health:...",
    "awsAccountId": "123456789012"
  }]'

SDK 例（Python）

import boto3
import json
from datetime import datetime, timedelta

health = boto3.client('health', region_name='us-east-1')
sns = boto3.client('sns')

def check_health_events():
    """Health イベントを確認、重要なものはアラート"""
    
    # 過去 7 日間のオープンイベント
    response = health.describe_events(
        filter={
            'eventStatusCodes': ['open'],
            'eventTypeCategories': ['scheduledChange', 'issue']
        },
        maxResults=100
    )
    
    for event in response['events']:
        event_arn = event['arn']
        service = event['service']
        event_type = event['eventTypeCode']
        
        # 影響リソース取得
        entities_response = health.describe_affected_entities(
            filter={'eventArns': [event_arn]}
        )
        
        affected_count = len(entities_response['entities'])
        
        # Prod サービス & 複数リソース影響 = 重要度高
        if service in ['EC2', 'RDS'] and affected_count > 5:
            severity = 'CRITICAL'
        elif affected_count > 0:
            severity = 'WARNING'
        else:
            severity = 'INFO'
        
        # SNS で通知
        message = {
            'severity': severity,
            'service': service,
            'event': event_type,
            'affected_resources': affected_count,
            'start_time': str(event['startTime']),
            'details': json.dumps(event, default=str, indent=2)
        }
        
        sns.publish(
            TopicArn='arn:aws:sns:us-east-1:123456789012:health-alerts',
            Subject=f'[{severity}] AWS Health: {service} {event_type}',
            Message=json.dumps(message, indent=2)
        )

def organizations_health_aggregator():
    """Organizations 全体の Health イベント集約"""
    
    # Business / Enterprise サポートプラン必須
    response = health.describe_events_for_organization(
        filter={
            'eventStatusCodes': ['open', 'upcoming']
        }
    )
    
    # アカウント・サービス別に分類
    event_map = {}
    for event in response['events']:
        account_id = event['arn'].split(':')[4]
        service = event['service']
        
        key = f"{account_id}:{service}"
        if key not in event_map:
            event_map[key] = []
        
        event_map[key].append(event)
    
    # CloudWatch メトリクスに記録
    cloudwatch = boto3.client('cloudwatch')
    
    for key, events in event_map.items():
        account_id, service = key.split(':')
        
        cloudwatch.put_metric_data(
            Namespace='HealthAggregator',
            MetricData=[{
                'MetricName': f'{service}-Events',
                'Value': len(events),
                'Unit': 'Count',
                'Dimensions': [
                    {'Name': 'AccountId', 'Value': account_id},
                    {'Name': 'Service', 'Value': service}
                ]
            }]
        )
    
    # ダッシュボード用
    return event_map

if __name__ == '__main__':
    check_health_events()
    print("Health events checked and alerts sent.")

EventBridge Rule 例（JSON）

{
  "Name": "ec2-maintenance-auto-failover",
  "Description": "EC2 メンテナンス 7 日前に自動フェイルオーバー準備",
  "EventPattern": {
    "source": ["aws.health"],
    "detail-type": ["AWS Health Event"],
    "detail": {
      "service": ["EC2"],
      "eventTypeCategory": ["scheduledChange"],
      "eventTypeCode": ["EC2 Host Maintenance Scheduled"]
    }
  },
  "State": "ENABLED",
  "Targets": [
    {
      "Arn": "arn:aws:lambda:ap-northeast-1:123456789012:function:ec2-maintenance-handler",
      "RoleArn": "arn:aws:iam::123456789012:role/EventBridgeInvokeRole"
    },
    {
      "Arn": "arn:aws:sns:ap-northeast-1:123456789012:topic/health-alerts",
      "RoleArn": "arn:aws:iam::123456789012:role/EventBridgeInvokeRole"
    }
  ]
}

類似サービス比較表

┌──────────────────────┬─────────────────────┬────────────────┬────────────────┐
│ 観点                 │ AWS Health          │ Azure Service  │ GCP Status     │
│                      │                     │ Health         │ Dashboard      │
├──────────────────────┼─────────────────────┼────────────────┼────────────────┤
│ アカウント別イベント │ ✅ Personal Health  │ ✅ Resource    │ ❌ 公開のみ    │
│ 計画メンテナンス通知 │ ✅ スケジュール変更 │ ✅ Planned      │ ❌ 概略のみ    │
│ EventBridge 連携    │ ✅ ネイティブ       │ ⚠️ Event Grid  │ ❌ なし       │
│ Organizations 統合   │ ✅ 一元監視         │ ✅ Tenant       │ ❌ 対応なし    │
│ API 提供            │ ✅ 有料             │ ✅ 有料         │ ⚠️ 限定的      │
│ 自動修復パイプライン │ ✅ Lambda で可能    │ ✅ Automation   │ ⚠️ Cloud Tasks │
│ 料金                │ 無料 / API 有料     │ 無料           │ 無料          │
│ 学習曲線            │ 中程度              │ 急             │ 緩い          │
└──────────────────────┴─────────────────────┴────────────────┴────────────────┘

ベストプラクティス

セキュリティ

✅ DO

  1. EventBridge Rule に最小権限 IAM ロール

    Lambda 実行ロール に EC2:DescribeInstances・SNS:Publish のみ許可
（過度な管理権限 ❌）

  2. Health イベント → CloudTrail ログ記録

    AWS Health API 呼び出しは CloudTrail に自動記録
→ 監査証跡の完全性を確保

  3. Slack / Teams への通知を HTTPS over VPC

    外部 API 呼び出しは Lambda Private Subnet + NAT Gateway
→ 内部 IP のみで通信

❌ DON’T

  • Health イベントで無制限リソース削除 → Lambda ロール制限・削除は明示的に承認
  • EventBridge Rule を全ユーザーに公開 → 管理者のみアクセス

パフォーマンス

✅ DO

  1. 複数リージョン Health イベントの並列取得

    # 悪い例：リージョン順序待機
for region in regions:
    events = health_client(region).describe_events()

# 良い例：並列実行
import concurrent.futures
with concurrent.futures.ThreadPoolExecutor() as executor:
    results = executor.map(fetch_events, regions)

  2. Health API ページネーション

    paginator = health.get_paginator('describe_events')
for page in paginator.paginate():
    process_events(page['events'])

❌ DON’T

  • 全イベント常時ポーリング → EventBridge で push 式通知
  • Organizations 全体を単発クエリ → ページネーション必須

運用

✅ DO

  1. Health ダッシュボード定期確認

    週 1 回のチェック習慣
→ 計画メンテナンスの見落とし防止

  2. EventBridge Rule の定期監査

    月 1 回、作成後 6 ヶ月以上未使用の Rule 削除

  3. 自動対応ロジックの安全装置

    Lambda が自動修復実行する場合、
→ 必ず事前に Slack で確認メッセージ
→ 5 分以内に承認なければ自動ロールバック

❌ DON’T

  • Health イベント無視して運用継続 → Personal Health Dashboard を見落とすと計画メンテナンスに不意打ち
  • Organizations アカウント新設後、Health 設定なし → 最初からイベント監視設定

トラブルシューティング

症状 原因 解決策
Health イベントが表示されない 使用していないサービスのイベント Health は「使用中リソース」のみ表示。新規リソース作成後 24h で表示
EventBridge Rule がトリガーされない イベントパターン不一致 CloudTrail で実際のイベント JSON 確認後、EventPattern 修正
Organizations API 403 エラー Business / Enterprise サポートなし Support plan upgrade 必須。Management Account からのみ呼び出し可
Lambda 自動対応が実行されない IAM ロール権限不足 iam:GetRole で実行ロール確認、EC2:* / SNS:* 追加
Slack 通知が届かない SNS Topic ポリシー制限 SNS Topic の「EventBridge から発行可」ポリシー設定確認

2025-2026 最新動向

AI 駆動の予測メンテナンス

Health イベント + ML による障害予測が 2026 年に本格化。単なる「現在の問題」通知から「3 日後に予測される問題」の事前アラートへ。

Resilience Hub との統合

Resilience Hub（アプリケーション冗長性評価）と Health Event をクロスリファレンス。「このアーキテクチャは Region 障害に対応しているか？」を Health Event 履歴から検証。

Custom Health Events

顧客が独自のヘルスイベント（営業時間外ブロック等）を Personal Health Dashboard に統合可能に（ロードマップに記載）。

学習リソース・参考文献

公式リソース

  1. AWS 公式ドキュメント

  2. ブログ・記事

比較・ベンチマーク

実装チェックリスト・導入ロードマップ

導入前チェック

  • [ ] AWS Support Plan が Business / Enterprise 以上か確認
  • [ ] Personal Health Dashboard にアクセス可能（IAM Permission）
  • [ ] Organizations を使用しているか確認（マルチアカウント監視用）
  • [ ] Slack / Teams など通知先の確認
  • [ ] 自動対応の範囲・権限を定義（何を自動化するか）

Phase 1: PoC（1 週間）

  1. Personal Health Dashboard にアクセス・イベント確認
  2. 小規模 EventBridge Rule 1 つ作成（EC2 メンテナンス通知 → SNS）
  3. 3-5 チームメンバーで検証

Phase 2: 本格導入（2 週間）

  1. EventBridge Rule 3-5 個作成（EC2・RDS・セキュリティ等）
  2. Lambda 自動対応ロジック実装
  3. Organizations 全体 Health Event 集約（管理アカウント）

Phase 3: 最適化（継続）

  1. CloudWatch ダッシュボード化
  2. 月 1 回の SLA 監視
  3. EventBridge Rule の定期監査

まとめ

AWS Health は「自分の AWS リソースに影響する AWS イベントをリアルタイム通知し、EventBridge / Lambda で自動対応を実現するサービス」。

強み

  • 無料（Personal Health Dashboard）
  • AWS サービスとのネイティブ統合
  • EventBridge で自動化パイプライン構築容易
  • Organizations で一元監視可能

弱み

  • Business / Enterprise サポートプランで Organizations API 有料
  • リアルタイム API ポーリング対応（Push は EventBridge のみ）
  • カスタムイベント定義未対応（ロードマップ）

採用判断

AWS Health は以下に最適：

✅ AWS 環境の本番運用・計画メンテナンス対応 ✅ EventBridge / Lambda で自動復旧パイプライン構築 ✅ Organizations マルチアカウント監視 ✅ SLA 管理・インシデント追跡

最終更新：2026-04-26 バージョン：v2.0