AWS CDK運用者が見落とすCloudWatchアラーム無効化の落とし穴

AWS CDK（Cloud Development Kit）でインフラをコード管理しているSREやインフラ担当者向けに、2026年8月のCDKアップデートに含まれる「見えない変更」を整理します。特にCloudWatchのアラーム定義をaws-cdk-libで管理している場合、気づかないうちにアラームが機能しなくなるケースがあるため、確認方法まで含めて解説します。

CDKはAWSが提供するIaC（Infrastructure as Code、インフラをコードで定義・管理する仕組み）ツールで、TypeScriptやPythonなどのプログラミング言語でAWSリソースを定義できます。Terraformが宣言的なHCL（HashiCorp Configuration Language）でリソースを記述するのに対し、CDKはプログラミング言語の型チェックやループ・条件分岐をそのまま使える点が特徴です。ただし内部ではCloudFormationのテンプレートに変換（synthと呼ばれる工程）されてからデプロイされるため、CDK側の変更がCloudFormationのふるまいにどう影響するかを追う必要があります。

何が起きるか：アラームが「無音の誤検知」を起こす

2026年8月のアップデートで、Bedrock AgentCore（AWSの生成AIエージェント実行基盤）関連のメトリクスディメンションが修正されました。RuntimeBaseやGatewayのメトリクスヘルパーが出力するCloudWatchのディメンション（メトリクスを識別するための属性の組み合わせ）が、実際にサービスが発行しているものと食い違っていたためです。

修正前は、リソース単位のメトリクスが{ Resource }というディメンションで定義されていましたが、実際のサービスは{ Operation, Name, Resource }で発行していました。ゲートウェイ側も同様に{ Resource }から{ Operation, Protocol, Resource }への変更です。

これが意味するのは、古いディメンション定義でアラームやダッシュボードを組んでいた場合、そのアラームは「データなし」の状態が続き、実際に異常が起きても発火しなかった可能性があるということです。SLO（Service Level Objective、サービスレベル目標）を支えるアラート基盤としては見過ごせない話です。

なぜ起きるか：ディメンション不一致は珍しくない

この問題の根本原因は、CDKのL2コンストラクト（AWSリソースを扱いやすくラップした高レベルAPI）が提供するメトリクスヘルパーメソッドと、実際にサービスがCloudWatchへ送信するメトリクスの仕様が、開発時点でずれていたことにあります。

AWSのマネージドサービスは頻繁にメトリクス仕様をアップデートしますが、CDKのアルファモジュールや比較的新しいL2コンストラクトは、そのアップデートに追従しきれないことがあります。Bedrock AgentCoreのように2024年以降に登場した比較的新しいサービスでは、この手の後追い修正が起きやすい傾向があります。

さらに厄介なのは、ディメンションが一致していないアラームは「エラーが出ない」という点です。CloudFormationのデプロイは成功し、CloudWatchコンソール上でもアラームは「作成済み」に見えます。ただし裏側では該当するメトリクスデータが一切届かないため、アラームの状態はINSUFFICIENT_DATAのまま固まります。これは典型的な「サイレント障害」のパターンで、障害対応の仕組み化を考えるうえで特に注意したい落とし穴です。

自分のプロジェクトが該当するか確認する

以下の手順で、影響範囲を具体的に確認できます。

CDKのバージョンを確認する: npx cdk --version を実行し、aws-cdk-libが2.264.0より前かどうかをpackage.jsonまたはnpx cdk-lib version相当のロックファイルで確認する
コード内でBedrock AgentCoreのメトリクスヘルパーを使っているか検索する: grep -r "metricInvocations\|RuntimeBase\|AgentCoreGateway" ./lib（プロジェクトのCDKソースディレクトリに読み替え）
既存のCloudWatchアラームの状態を確認する: AWSコンソールのCloudWatch > アラーム画面で、対象アラームが長期間INSUFFICIENT_DATAのままになっていないか目視確認する
CLIから一括確認する場合は以下のコマンドが使えます

aws cloudwatch describe-alarms \
  --state-value INSUFFICIENT_DATA \
  --query "MetricAlarms[?contains(AlarmName, 'AgentCore')].{Name:AlarmName,State:StateValue,Updated:StateUpdatedTimestamp}" \
  --output table

StateUpdatedTimestampがアラーム作成直後からずっと変わっていない場合、メトリクスデータが届いていない疑いが強いといえます。

アラームが「作成できている」ことと「正しく発火する」ことは別問題であり、ディメンション不一致は監視の盲点になりやすい落とし穴です。

対策の手順

該当する場合は、次の手順で復旧します。

1. aws-cdk-libを2.264.0以降（できればアップデート内容を確認した上で最新の2.267.0系）にアップデートする

npm install aws-cdk-lib@^2.267.0 aws-cdk@^2.1139.0

2. cdk diffを実行し、メトリクスヘルパーが生成するCloudWatchアラームリソースの差分を確認する。ディメンションの変更はアラームの置き換え（削除→再作成）を伴うことが多いため、cdk diffの出力でResource replacementが出ていないか必ず目視する

3. 既存の古いアラームを手動で棚卸しする。CDKが古いディメンションで作成したアラームは、新しいディメンション定義のアラームがデプロイされても自動的には削除されない場合があるため、CloudFormationのスタック差分を確認したうえで不要なアラームを明示的に削除する

4. 再デプロイ後、しばらく待ってからアラーム状態がOKまたはALARMに遷移するか確認する。INSUFFICIENT_DATAのまま残る場合はメトリクス名やネームスペースの指定ミスを疑う

5. 恒久対策として、アラームのディメンションをコードでハードコードせず、CDKが提供する公式のメトリクスヘルパーメソッド（.metricXxx()系）を使う運用に統一する。手書きのMetricコンストラクトでディメンションを直書きしていると、今回のような仕様変更に気づきにくくなります

この機会に、Terraform運用者であればAWS Provider側のaws_cloudwatch_metric_alarmリソースでも同種の問題が起き得る点を意識しておくと安心です。IaCツールの種類を問わず、マネージドサービスのメトリクス仕様変更にアラーム定義が追従できているかという観点は共通の点検項目になります。

確認しておきたいこと

今回のケースから、日常的な運用として押さえておきたい点を整理します。

CDKやTerraformのプロバイダをアップデートする際は、リリースノートの「メトリクス」「アラーム」関連の変更を必ず確認する
INSUFFICIENT_DATA状態が続くアラームを定期的に棚卸しする仕組み（週次のスクリプトチェックなど）を用意する
メトリクスのディメンションをコードに直書きせず、公式ヘルパーメソッド経由で生成する
アップデート後はcdk diffでリソースの置き換えが発生していないか必ず目視する

監視基盤は「動いているように見える」状態が一番見落とされやすい部分です。定期的なアラーム状態の棚卸しを、運用のルーティンに組み込んでおくと安心です。