はじめに
AWS環境を運用していると、Lambdaランタイムのサポート終了やRDSのエンジンバージョンのサポート終了、サービスの廃止など、様々なサービスのEOL(End of Life)やEOS(End of Support)に遭遇することがあります。
これらの情報を見落としてしまうと、サービス停止やセキュリティリスクに繋がる可能性があり、適切なタイミングでのメンテナンス作業が重要になります。
そこで今回は、AWS Organizations配下の全アカウントに対して、AWS Health APIを活用してEOL・EOS情報を自動収集し、Amazon Bedrockで分析してSlackに通知するシステムを構築しました。
解決したい課題
現状の問題点
- 情報の分散: 各種サービスのEOL・EOS情報が様々な場所に散在
- 監視対象の多さ: 複数のAWSアカウント・リージョンにまたがるリソース
- 通知の見落とし: メール通知などの重要な情報を見逃すリスク
- 分析の手間: 影響範囲の特定や対応優先度の判断が困難
目指す解決策
- AWS Health APIを活用した組織全体の一元監視
- AI(Amazon Bedrock)による自動分析とサマリー生成
- Slack通知による即座の情報共有
- EventBridgeによる定期実行で継続的な監視
AWS Health
AWS Healthは、AWSのリソースパフォーマンスとAWSのサービス・アカウントの可用性について、継続的な可視性を提供するサービスです。このサービスを通じて、以下のような機能が利用できます。
• AWSリソースの健全性をリアルタイムで監視
• サービスやリソースの変更がアプリケーションに与える影響を把握
• 進行中のイベントに関する関連性の高いタイムリーな情報の提供
• 計画されたメンテナンスや活動に関する事前通知
• リソースの健全性変化に基づくアラートと通知の配信
• トラブルシューティングのためのガイダンス提供
AWS Health Organizational view
AWS Health Organizational view は、AWS Organizations全体のAWSリソースの健全性を一元的に監視・管理できるツールです。主な特徴は以下の通りです。
• 組織内の全てのAWSアカウントのヘルスイベントを単一のダッシュボードで確認可能
• 複数のリージョンやアカウントにまたがるイベントの集約表示
• セキュリティ関連の問題、予定されたメンテナンス、その他のAWSサービスの状態変更などを一括監視
• アカウント間のイベントフィルタリングと検索機能
• AWS Organizations内の全アカウントに影響を与えるイベントの通知管理
システムアーキテクチャ
全体構成
EventBridge Schedule → Lambda Function (Container)
↓
AWS Health API → Organizations API
↓
Amazon Bedrock (Claude 3.7) → 分析・サマリー生成
↓
SNS → Amazon Q Developer in chat applications → Slack通知
主要コンポーネント
- EventBridge Schedule: 定期実行のトリガー(週次など)
- Lambda Function: コンテナイメージでデプロイされたメイン処理
- AWS Health API: 組織全体のヘルスイベント取得
- Amazon Bedrock: EOL・EOS情報の自動分析
- SNS + ChatBot: Slack通知の配信
実装詳細
コードは以下の Github 取得できます。なお、コードは Amazon Q Developer を利用して作成しました。
Lambda関数の実装
今回はコンテナイメージを使用してLambdaをデプロイしています。
主な理由として、依存関係の管理やカスタマイズの柔軟性、そしてランタイムバージョンのEOL対応を柔軟に行えるためです。
メイン処理フロー
def lambda_handler(event, context):
try:
# 1. AWS Health APIから組織全体のスケジュール変更イベントを取得
events = get_health_events_for_organization()
# 2. 各イベントの詳細情報を収集
event_details = collect_event_details(events)
# 3. Amazon Bedrockで分析
analysis_result = analyze_with_bedrock(event_details)
# 4. Slack通知の送信
send_slack_notification(analysis_result)
except Exception as e:
logger.error(f"エラーが発生しました: {str(e)}")
raise
AWS Health API の活用
AWS Health APIは、AWSサービスの健全性に関する情報にプログラムでアクセスできるインターフェースです。以下の機能を提供します。
• AWSリソースの健全性イベントをプログラム的に取得可能
• カスタムモニタリングアプリケーションの作成が可能
• イベント通知の自動化が実現可能
• AWS Lambdaと連携した自動対応の実装が可能
• サービスの状態変更を自動的に検知し対応
• 予定されたメンテナンス情報への自動アクセス
• 組織全体のヘルスイベントの一括取得(AWS Organizations使用時)
なお、AWS Health APIを使用するには、AWSサポートのビジネス、エンタープライズオンランプ、またはエンタープライズサポートプランに加入している必要があるため注意してください。
今回は AWS Organizations管理アカウントから、以下のAPIを使用して組織全体の情報を取得します。
-
health:DescribeEventsForOrganization
: 組織全体のヘルスイベント取得 -
health:DescribeAffectedAccountsForOrganization
: 影響を受けるアカウント情報 -
health:DescribeAffectedEntitiesForOrganization
: 影響を受けるリソース情報 -
health:DescribeEventDetailsForOrganization
: イベント詳細情報
Amazon Bedrock による分析
今回は Claude 3.7を使用して、取得したヘルスイベント情報から以下の項目を自動抽出します:
- サービス名: Lambda、ECS、WAFなど
- プラットフォーム/ランタイム: Python、Node.js、Java等
- バージョン: 具体的なバージョン番号
- サポート終了日: EOL・EOS の具体的な日付
- 影響範囲: 対象リージョンやアカウント
- 対応必要性: 緊急度の評価
def analyze_with_bedrock(event_details):
prompt = f"""
以下のAWS Health イベント情報を分析し、EOL・EOS関連の重要な情報を抽出してください:
{event_details}
以下の形式で回答してください:
- サービス名
- プラットフォーム
- バージョン
- サポート終了日
- 影響範囲
- 推奨アクション
"""
response = bedrock_client.invoke_model(
modelId="anthropic.claude-3-7-20241014:1:0",
body=json.dumps({
"anthropic_version": "bedrock-2023-05-31",
"messages": [{"role": "user", "content": prompt}],
"max_tokens": 4000
})
)
return json.loads(response['body'].read())
通知の方法
Amazon Q Developer in chat applications Custom notifications とは
Amazon Q Developer in chat applications(旧AWS ChatBot)のCustom notifications機能を使用することで、従来の定型的な通知メッセージではなく、カスタマイズされた通知をSlackやMicrosoft Teamsに送信できます。
従来の通知との違い
項目 | 従来の通知 | Custom notifications |
---|---|---|
メッセージ形式 | 固定フォーマット(英語) | カスタマイズ可能(日本語対応) |
情報の詳細度 | 基本情報のみ | 任意の詳細情報を追加可能 |
デザイン | AWS標準デザイン | Markdown、絵文字、メンション対応 |
スレッド化 | 不可 | threadIdによる関連通知のグループ化 |
コンテキスト情報 | 限定的 | ビジネス固有の情報を追加可能 |
Custom notifications の仕組み
Lambda/EventBridge → 特定のJSONスキーマ → SNS Topic
↓
Amazon Q Developer → Slack/Teams Channel
通知は以下のJSONスキーマ形式でSNSトピックに送信する必要があります:
{
"version": "1.0",
"source": "custom",
"id": "unique-event-id",
"content": {
"textType": "client-markdown",
"title": "通知タイトル",
"description": "詳細説明(Markdownサポート)",
"nextSteps": [
"推奨アクション1",
"推奨アクション2"
],
"keywords": ["キーワード1", "キーワード2"]
},
"metadata": {
"threadId": "関連通知をグループ化するID",
"summary": "更新サマリー",
"eventType": "イベントタイプ",
"relatedResources": ["リソースID1", "リソースID2"],
"additionalContext": {
"priority": "high",
"environment": "production"
}
}
}
デプロイ方法
前提条件
- AWS Organizations管理アカウントでの実行権限
- 必要なIAM権限の設定
- SNSトピックとAWS ChatBot の設定
- Finch(コンテナビルド用)
IAM権限設定
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"health:DescribeEventsForOrganization",
"health:DescribeAffectedAccountsForOrganization",
"health:DescribeAffectedEntitiesForOrganization",
"health:DescribeEventDetailsForOrganization",
"organizations:ListAccounts",
"bedrock:InvokeModel",
"sns:Publish"
],
"Resource": "*"
}
]
}
デプロイ実行
# リポジトリをクローン
git clone https://github.com/hibira/AWSHealthScheduledChangeEventsForOrganizationList
# デプロイスクリプトを実行
cd AWSHealthScheduledChangeEventsForOrganizationList
chmod +x deploy-container.sh
./deploy-container.sh
EventBridge設定
定期実行のためのEventBridge Scheduleを設定します:
{
"ScheduleExpression": "rate(7 days)",
"Target": {
"Arn": "arn:aws:lambda:us-east-1:123456789012:function:health-eol-monitor",
"Id": "HealthEOLMonitorTarget"
}
}
実行結果と通知例
Slack通知フォーマット
システムが検出したEOL・EOS情報は以下のような形式でSlackに通知されます:
⚠️ AWS Health EOL Events Alert - 3件のイベント検出
EOL関連のイベントが検出されました。
## 分析結果
**1234567890 他4つ**:
• サービス名: LAMBDA
• プラットフォーム: Python
• バージョン: 3.9
• サポート終了日: 2025/12/15
• 関連リージョン: eu-central-1 他11個
• ステータス: upcoming
• サマリー: Python 3.9のEOL到達により、Lambdaでのサポートが終了...
**1234567890**:
• サービス名: LAMBDA
• プラットフォーム: Node.js
• バージョン: 18
• サポート終了日: 2025/09/01
• 関連リージョン: us-east-1, us-west-2
• ステータス: open
• サマリー: Node.js 18のEOL到達により、Lambdaでのサポートが終了...
実際の通知結果はこのようになります。
おわりに
AWS Health APIとAmazon Bedrockを活用することで、従来手動で行っていたEOL・EOS監視を自動化し、組織全体での見落としリスクを大幅に削減することができました。
特にAIによる自動分析機能により、大量のヘルスイベント情報から重要な項目を効率的に抽出できる点が、実運用上の大きなメリットとなっています。
AWSの進化とともに新しいサービスやEOL・EOS情報も増えてきているため、メンテナンスの管理をできるだけ自動化したいですね。