AWS HealthのLifecycleイベントをAWS DevOps Agentで自動調査させてみた

import hashlib
import hmac
import json
import os
import urllib.request
from base64 import b64encode
from datetime import datetime, timezone

WEBHOOK_URL = os.environ["DEVOPS_AGENT_WEBHOOK_URL"]
WEBHOOK_SECRET = os.environ["DEVOPS_AGENT_WEBHOOK_SECRET"]

def build_payload(event: dict) -> dict:
    detail = event["detail"]
    service = detail["service"]
    event_type_code = detail["eventTypeCode"]
    event_region = detail.get("eventRegion", event["region"])

    descriptions = detail.get("eventDescription", [])
    description_text = next(
        (d["latestDescription"] for d in descriptions if d["language"] == "en_US"),
        next((d["latestDescription"] for d in descriptions), ""),
    )

    # PENDING状態のリソースのみ対象（RESOLVEDは除外）
    affected = [
        e["entityValue"]
        for e in detail.get("affectedEntities", [])
        if e.get("status", "PENDING") != "RESOLVED"
    ] or event.get("resources", [])

    affected_str = "\n".join(f"- {e}" for e in affected)

    return {
        "eventType": "incident",
        "incidentId": detail["eventArn"],
        "action": "created",
        "priority": "HIGH",
        "title": f"AWS Health: {service} / {event_type_code}",
        "description": (
            f"【通知内容】\n{description_text}\n\n"
            f"【影響リソース ({len(affected)}件)】\n{affected_str}"
        ),
        "timestamp": event["time"],
        "service": "AWSHealth",
        "data": {
            "metadata": {
                "eventArn": detail["eventArn"],
                "service": service,
                "eventTypeCode": event_type_code,
                "eventTypeCategory": detail["eventTypeCategory"],
                "statusCode": detail["statusCode"],
                "actionability": detail.get("actionability", ""),
                "region": event_region,
                "accountId": event["account"],
                "startTime": detail.get("startTime", ""),
                "affectedResources": affected,
            }
        },
    }

def send_webhook(payload: dict) -> int:
    body = json.dumps(payload).encode("utf-8")
    timestamp = datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%S.000Z")

    sig = hmac.new(
        WEBHOOK_SECRET.encode("utf-8"),
        f"{timestamp}:{body.decode('utf-8')}".encode("utf-8"),
        hashlib.sha256,
    ).digest()
    signature = b64encode(sig).decode("utf-8")

    req = urllib.request.Request(
        WEBHOOK_URL,
        data=body,
        headers={
            "Content-Type": "application/json",
            "x-amzn-event-timestamp": timestamp,
            "x-amzn-event-signature": signature,
        },
        method="POST",
    )
    with urllib.request.urlopen(req) as resp:
        return resp.status

def handler(event, context):
    detail = event.get("detail", {})
    status = detail.get("statusCode", "")

    # closed は調査不要なのでスキップ
    if status == "closed":
        print(f"Skipped: statusCode={status}")
        return {"status": "skipped"}

    payload = build_payload(event)
    print(f"Sending webhook: eventArn={detail['eventArn']}")

    status_code = send_webhook(payload)
    print(f"Webhook response: {status_code}")

    return {"status": "sent", "httpStatus": status_code}

---
name: aws-health-lifecycle-investigation
description: >
  Investigation procedures for AWS Health lifecycle events (scheduledChange category),
  including runtime deprecations, end-of-support notices, and instance type retirement for any
  AWS service. Use this skill when the incident title matches the pattern "AWS Health: {SERVICE} /
  {EVENT_TYPE_CODE}" — for example "AWS Health: Lambda / AWS_LAMBDA_PLANNED_LIFECYCLE_EVENT",
  "AWS Health: RDS / AWS_RDS_PLANNED_LIFECYCLE_EVENT", or "AWS Health: EC2 / AWS_EC2_INSTANCE_RETIREMENT_SCHEDULED".
  Activates whenever the incident originates from AWS Health and concerns a planned lifecycle change
  requiring customer action.
---

# AWS Health Lifecycle Event Investigation

Use this skill when an AWS Health notification arrives for a planned lifecycle change
(runtime deprecation, end-of-support, instance type retirement, etc.) on any AWS service.

## Step 1: Identify affected resources and current state

From the incident metadata (eventArn, service, eventTypeCode, affectedResources):
- Confirm each affected resource exists and retrieve its current configuration
- Check whether the resource has already been migrated (if so, mark as "Already mitigated" and exclude from plan)
- Note the region for each resource

## Step 2: Analyze each resource's role and criticality

For each affected resource, determine:
- **Role / purpose**: What workload does this resource serve?
- **Public exposure**: Is it reachable from the internet or directly customer-facing?
- **Usage frequency**: Check relevant CloudWatch metrics over the past 30 days
- **Downstream dependencies**: What services or systems depend on this resource?

Classify each resource by criticality:

| Criticality | Criteria |
|---|---|
| HIGH | Directly customer-facing or on a critical data path |
| MEDIUM | Internal workloads, batch processing, event-driven pipelines |
| LOW | Scheduled jobs, dev/test resources, low-traffic background tasks |

Service-specific signals to look for:
- **Lambda**: trigger type (API Gateway → HIGH), attached Layers, invocation frequency
- **RDS**: Multi-AZ, read replicas, connected applications, backup retention
- **EC2**: instance type, attached EBS volumes, Elastic IP, Auto Scaling group membership

## Step 3: Extract the lifecycle timeline from the notification

Parse the schedule from the notification description (available in the incident description field).
Identify and present all deadline dates in chronological order, with the impact of each date.

## Step 4: Assess migration complexity per resource

- **Lambda**: target runtime version, breaking changes between current and target, Layer compatibility
- **RDS**: target engine version, major vs minor upgrade path, parameter group changes, downtime window
- **EC2**: replacement instance type, AMI compatibility, user data, instance store vs EBS

## Step 5: Produce a prioritized migration plan

Output a summary table with: Resource / Criticality / Complexity / Recommended action / Suggested deadline.

Scheduling guidance relative to the earliest hard deadline:
- HIGH: complete 3 months before / MEDIUM: 2 months before / LOW: 1 month before

## Notes

- The affectedEntities list may not enumerate all affected resources in large accounts.
  Cross-check with service APIs (e.g., lambda:ListFunctions filtered by runtime).
- If a resource cannot be updated, flag for manual review and escalation.

{
  "version": "0",
  "id": "test-event-001",
  "detail-type": "AWS Health Event",
  "source": "aws.health",
  "account": "<アカウントID>",
  "time": "2026-05-24T02:00:00Z",
  "region": "us-east-1",
  "resources": [
    "arn:aws:lambda:ap-northeast-1:<アカウントID>:function:myFunction"
  ],
  "detail": {
    "eventArn": "arn:aws:health:ap-northeast-1::event/LAMBDA/AWS_LAMBDA_PLANNED_LIFECYCLE_EVENT/...",
    "service": "LAMBDA",
    "eventTypeCode": "AWS_LAMBDA_PLANNED_LIFECYCLE_EVENT",
    "eventTypeCategory": "scheduledChange",
    "eventScopeCode": "ACCOUNT_SPECIFIC",
    "communicationId": "...",
    "statusCode": "upcoming",
    "eventRegion": "ap-northeast-1",
    "startTime": "Thu, 31 Oct 2026 07:00:00 GMT",
    "lastUpdatedTime": "...",
    "eventDescription": [{
      "language": "en_US",
      "latestDescription": "We are contacting you as we have identified..."
    }],
    "affectedEntities": [
      {"entityValue": "arn:aws:lambda:...:function:myFunction", "status": "PENDING"}
    ],
    "actionability": "ACTION_REQUIRED"
  }
}

収集した情報を基に、移行計画をまとめます。

AWS Health: Lambda Python 3.10 ランタイム廃止対応 - 調査報告
概要
AWS Healthから、Python 3.10ランタイムの計画的な廃止に関する通知を受け取りました。アカウント内の3つのLambda関数が影響を受けます。

ステップ2: 影響を受けるリソースの分析
1. userRegistHandler
ARN: arn:aws:lambda:ap-northeast-1:<アカウントID>:function:userRegistHandler
役割: DynamoDBへの読み書きを行うバックエンド、RESTful APIエンドポイント（API Gateway連携）
構成:
ハンドラー: lambda_function.lambda_handler
タイムアウト: 10秒
メモリ: 512 MB
環境変数: SAVEBUCKET=example-contents
レイヤー: なし
最終更新: 2025-11-08
公開状態: API Gateway経由で外部公開されている可能性が高い
使用頻度: 過去30日間の呼び出しメトリクスなし（低使用率または未使用）
下流依存: DynamoDB、S3バケット
重要度: MEDIUM〜HIGH - API Gateway連携のため顧客向けの可能性あり
2. s3EventProcessor
ARN: arn:aws:lambda:ap-northeast-1:<アカウントID>:function:s3EventProcessor
役割: S3トリガーでオブジェクトメタデータを取得
構成:
ハンドラー: lambda_function.lambda_handler
タイムアウト: 3秒
メモリ: 128 MB
レイヤー: なし
最終更新: 2024-10-07
公開状態: 内部処理（S3イベント駆動）
使用頻度: 過去30日間の呼び出しメトリクスなし
下流依存: S3バケット
重要度: MEDIUM - イベント駆動の内部ワークロード
3. bounceNotifier
ARN: arn:aws:lambda:ap-northeast-1:<アカウントID>:function:bounceNotifier
役割: SNSトリガーでメッセージをログに記録
構成:
ハンドラー: lambda_function.lambda_handler
タイムアウト: 3秒
メモリ: 128 MB
レイヤー: なし
最終更新: 2024-10-07
公開状態: 内部処理（SNSイベント駆動）
使用頻度: 過去30日間の呼び出しメトリクスなし
下流依存: SNSトピック、CloudWatch Logs
重要度: LOW〜MEDIUM - ログ記録用の補助機能
ステップ3: ライフサイクルタイムライン
日付	影響内容
2026年10月31日	セキュリティパッチおよび更新の適用終了
2026年11月30日	Python 3.10を使用した新規Lambda関数の作成不可
2027年1月15日	Python 3.10を使用する既存関数の更新不可（ハードデッドライン）
ステップ4: 移行の複雑性評価
関数	移行の複雑性	理由
userRegistHandler	低	Layerなし、標準的なハンドラー構成
s3EventProcessor	低	Layerなし、標準的なハンドラー構成
bounceNotifier	低	Layerなし、標準的なハンドラー構成
移行要件:

ターゲットランタイム: Python 3.13 または Python 3.12（推奨）
破壊的変更の確認: Python 3.10から3.12/3.13への移行に伴う非互換性の確認が必要
依存ライブラリ: 各関数で使用されているPythonライブラリの互換性確認
テスト: 移行後の動作検証（特にuserRegistHandlerはAPI経由での検証が必要）
ステップ5: 優先順位付けされた移行計画
リソース	重要度	複雑性	推奨アクション	推奨期限
userRegistHandler	MEDIUM〜HIGH	低	Python 3.13への移行、API Gateway経由での段階的ロールアウト（Canaryデプロイ推奨）	2026年10月15日まで（ハードデッドラインの3ヶ月前）
s3EventProcessor	MEDIUM	低	Python 3.13への移行、S3イベントでの動作検証	2026年11月15日まで（ハードデッドラインの2ヶ月前）
bounceNotifier	LOW〜MEDIUM	低	Python 3.13への移行、SNSイベントでの動作検証	2026年12月15日まで（ハードデッドラインの1ヶ月前）
推奨アクション
即時対応（1〜2週間以内）
コード互換性チェック:

各関数のコードをローカルまたは開発環境でPython 3.12/3.13環境でテスト
使用しているライブラリの互換性を確認（特にboto3、その他のAWS SDKや外部ライブラリ）
未使用関数の確認:

過去30日間のメトリクスがないため、これらの関数が実際に使用されているか確認
未使用の場合は削除を検討
短期対応（1〜3ヶ月以内）
userRegistHandler の優先移行:

API Gateway連携のため、顧客影響を避けるため最優先で対応
Lambda バージョニングとエイリアスを使用したCanaryデプロイを推奨:
新バージョン（Python 3.13）を作成
API Gatewayで加重ルーティング（例: 10% → 50% → 100%）を設定
各段階でエラー率、レイテンシを監視
s3EventProcessorとbounceNotifierの移行:

userRegistHandlerの移行が成功した後に実施
S3/SNSトリガーでの動作検証を実施
中期対応（移行完了後）
モニタリングと検証:

移行後、CloudWatch Logsでエラーを監視
Invocations、Errors、Durationメトリクスを確認
本番環境での動作を少なくとも2週間監視
ドキュメント更新:

ランタイムバージョンの変更履歴を記録
IaCコード（Terraform、CloudFormationなど）がある場合は更新
注意事項
Lambda Layer: 現在3つの関数すべてLayerを使用していないため、Layer互換性の懸念はありません
最終更新日: すべての関数が2023年10月頃に最終更新されており、約2年半更新されていません。コードレビューと動作確認が特に重要です
権限制約: 現在のIAMロール（DevOpsAgentRole）にはlambda:GetFunction権限がないため、関数コードの詳細確認には追加の権限が必要です
調査の制約
以下の制約により、一部の情報が取得できませんでした:

Lambda関数の詳細設定: lambda:GetFunction権限がないため、関数コードや詳細設定を直接確認できませんでした
実際の使用状況: 過去30日間のメトリクスが空のため、関数が実際に使用されているか、使用されていない（開発/テスト環境）かの判断ができませんでした
この報告書に基づき、まずuserRegistHandlerの優先移行から着手することを強く推奨します。ご不明点や追加の調査が必要な場合はお知らせください。