みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 めっきり日が短くなり、気づけば今年も残すところ 2 か月あまりとなりました。今週は Amazon Bedrock 上の Claude モデルでの Structured Outputs 対応や、Amazon Connect の脅威検出、AWS Trainium 向けネイティブ PyTorch「TorchNeuron」のベータなど、開発・運用の現場をじわりと支えるアップデートが揃いました。そして年末といえば、いよいよ 11/30（月）〜 12/4（金） に米国ラスベガスで AWS 最大のカンファレンス AWS re:Invent 2026 が開催されます。新サービスがステージで発表され、その日のうちにライブデモや技術セッションで深掘りできる 1 年で最もアツい 5 日間です。現地参加はもちろん、基調講演はオンラインでも視聴できますので、ぜひ予定に入れておいてください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年10月19日週の主要なアップデート 10/19(月) Amazon GuardDuty が Runtime Monitoring 向けのオプション脅威検出ルールを追加 Amazon GuardDuty の Runtime Monitoring に、オプトインで有効化できる脅威検出ルール (Custom Detection Rules) が追加されました。sudoers ファイルの変更や監査ログの無効化のように、ある環境では正常でも別の環境では侵害の兆候となるプロセス・ファイル・ネットワークアクティビティを、環境ごとに選択して検出できます。ルールは AWS が構築・保守するプリビルトで 55 個あり、MITRE ATT&CK のタクティクスに対応した 13 の finding types を生成します。dry-run mode で検出量を事前評価してから live mode に切り替えられます。すべての AWS 商用リージョンと AWS GovCloud (US) リージョンで利用できます。 EC2 Image Builder が ASG と統合しイメージビルドを高速化 EC2 Image Builder が、Auto Scaling Group (ASG) で稼働中の既存 EC2 インスタンスをビルドに使用できるようになりました。従来はビルドのたびに新規インスタンスの起動と初期化を待つ必要がありましたが、この時間を省略できます。インフラストラクチャ設定で ASG を指定すると、Image Builder はその ASG から稼働中のインスタンスを 1 台取り出してビルドコンポーネントを適用し、イメージを作成します。ASG は希望容量の維持によりインスタンスを自動補充するため、次回以降のパイプライン実行にもインスタンスを利用できます。本機能はオプトイン方式で、既存パイプラインへの影響はなく、全リージョンで追加料金なしで利用できます。 Amazon CloudWatch Omni が追加の AWS リージョンで利用可能に Amazon CloudWatch Omni が新たに 8 リージョンに拡大し、東京リージョンを含む合計 11 リージョンで利用できるようになりました。CloudWatch Omni は AWS マネジメントコンソールの外 (SSO 対応の専用 Web UI または IDE 拡張) で提供される AI を活用した可観測性のためのインターフェースで、アプリケーションと AI エージェントのテレメトリを 1 か所で確認できます。OpenTelemetry を基盤とし、既存の CloudWatch テレメトリは再設定なしでそのまま表示されます。今回の拡大により、日本の組織は東京リージョンにスペースを作成し、IAM Identity Center と組み合わせた SSO 構成をリージョン内で完結できます。 10/20(火) AWS IAM Identity Center が Active Directory からのアイデンティティソース変更を簡素化 AWS IAM Identity Center は、アイデンティティソースを Active Directory から外部 IdP (Okta、Microsoft Entra ID など) または Identity Center ディレクトリに変更する際、ユーザー、グループ、グループメンバーシップ、許可セット割り当て、アプリケーション割り当てを保持するようになりました。従来はこの変更で全データが削除され、再作成が必要でした。既存の identity store が維持されるため、ユーザー ID・グループ ID・Identity Store ID は変わらず、これらの ID を参照するポリシーも引き続き動作します。本機能は組織インスタンスを対象に、IAM Identity Center が利用可能な全リージョンで追加料金なしで利用できます。なお、逆方向 (Active Directory への変更) は従来どおり全データが削除されます。 Amazon Bedrock Guardrails が contextual grounding checks の Standard tier をサポート Amazon Bedrock Guardrails のハルシネーション検出機能である contextual grounding checks に Standard tier が追加されました。従来の Classic tier は要約・言い換え・質問応答向けの厳密なグラウンディング評価のみに対応していましたが、Standard tier では推論過程や会話調の内容を含む応答も評価できます。対応言語は英語・フランス語・スペイン語の 3 言語から日本語を含む 80 以上の言語に拡大され、日本語は「最適化およびサポート済み」の位置付けです。料金は Classic tier と同じ 1,000 テキストユニットあたり 0.10 USD です。利用にはガードレールプロファイルによる cross-Region inference の有効化が必要で、東京リージョンを含む 11 リージョンで利用できます。 AWS Clean Rooms が Databricks をデータソースとしてサポート AWS Clean Rooms が Databricks をデータソースとしてサポートしました。コラボレーションのメンバーは、Delta Sharing で共有された Databricks のテーブルを、S3 へエクスポートや複製をせずにコラボレーション内で直接クエリできます。これまで Databricks にデータを持つメンバーは S3 へのエクスポートパイプラインの構築と、コピーされたデータの追加のガバナンスが必要でした。認証には IAM のアウトバウンド ID フェデレーションによる JWT 交換を使うため、長期シークレットの保管は不要です。サポートされるデータソースは AWS Glue (S3)、Amazon Athena、Snowflake に Databricks が加わり 4 種類になりました。 Amazon Bedrock 上の Claude モデルで Structured Outputs が利用可能に Amazon Bedrock が、Anthropic Claude の全モデルで Structured Outputs を一般提供しました。ユーザーが定義した JSON Schema に必ず準拠した JSON レスポンスを受け取れるため、独自のパース処理、リトライロジック、事後検証コードが不要になります。bedrock-runtime エンドポイント (Converse API / InvokeModel API) と bedrock-mantle エンドポイント (Anthropic Messages API) の両方に対応します。レスポンス全体を構造化する「JSON Schema output format」と、ツール呼び出しの入力を検証する「strict tool use」の 2 つの機構があり、併用もできます。Claude モデルが利用可能なすべてのリージョンで使えます。 10/21(水) AWS Transform が新規ネットワークの構築とセキュリティグループの最新化に対応 AWS Transform for migrations のネットワーク移行機能が拡張され、ネットワークを AWS に持ち込む方法が 3 つになりました。従来の「ソースネットワークを新規 VPC にマッピングする移行」に加え、ソース設定ファイルを使わずにゼロから AWS ベストプラクティスに沿った新規ネットワークを設計・構築する方式と、オンプレミスのファイアウォールルールをセキュリティグループに変換して既存 VPC へデプロイする方式を選択できます。セキュリティグループ変換では、実トラフィックデータに基づく未使用ルールの検出や、CIDR ベースのルールからセキュリティグループ参照への変換などの最新化を行います。AWS Transform 自体の利用は無料で、すべての AWS 商用リージョンおよび GovCloud リージョンへの移行に対応します。 AWS Neuron 2.33 がネイティブ PyTorch サポート、Neuron Observer などの新機能を追加 AWS Neuron 2.33 がリリースされました。最大の変更点は、AWS Trainium 向けのネイティブ PyTorch バックエンドである TorchNeuron のパブリックベータ提供です。torch-xla を経由せず、.to(“neuron”) と指定するだけで標準の PyTorch コードを Trn2 / Trn3 インスタンス上で eager mode または torch.compile で実行できます。あわせて、Trainium の稼働状態の異常を 1 秒未満で検知する Neuron Observer、vLLM 0.29.0 対応、Wan2.2 動画生成向け vLLM Omni Neuron plugin、NKI Library への 25 個の実験的カーネル追加が含まれます。また、Neuron 2.34 で Trn2 / Trn3 の Torch/XLA 推論パスと NxD Inference がサポート終了になる予告が出ており、ネイティブ PyTorch パスへの移行計画が必要です。 AWS Transform が Amazon S3、EBS、EFS、FSx 向けのストレージ移行評価を追加 AWS Transform の移行評価 (migration assessment) 機能が、オンプレミスストレージの評価に対応しました。NetApp Digital Advisor エクスポートや RVTools ファイルなどのストレージインベントリをアップロードすると、NAS 共有、SAN LUN、直接接続ディスク、バックアップリポジトリの各ワークロードを Amazon S3、Amazon EBS、Amazon EFS、Amazon FSx (NetApp ONTAP、Windows File Server、OpenZFS、Lustre) に自動でマッピングし、サイジングとコスト予測を含む TCO ビジネスケースを生成します。Single-AZ と Multi-AZ、コスト最適化とパフォーマンス最適化といった What-if シナリオを比較でき、結果についてチャットで追加質問もできます。評価機能は無料で、AWS Transform が利用可能なすべてのリージョンで提供されます。 10/22(木) Amazon SageMaker AI が Muse Glimmer、Qwen 3.8、Ministral 3 モデルのサーバーレスモデルカスタマイズをサポート Amazon SageMaker AI のサーバーレスモデルカスタマイズに、Meta の Muse Glimmer 30B、Alibaba の Qwen 3.8 27B、Mistral AI の Ministral 3 (3B / 8B / 14B) が追加されました。これらのモデルに対して、SFT (教師ありファインチューニング)、DPO (直接選好最適化)、RFT (強化ファインチューニング) の 3 手法を、LoRA またはフルファインチューニングで実行できます。インフラのプロビジョニングとトレーニングのオーケストレーションは SageMaker AI が管理するため、GPU クラスタの運用なしに従量課金でモデルを適応できます。利用可能なリージョンはバージニア北部リージョン、オレゴンリージョン、東京リージョン、アイルランドリージョンの 4 つです。 AgentCore Gateway が Bedrock InvokeModel API とモデルフォールバックに対応 Amazon Bedrock AgentCore Gateway の推論エンドポイントが、Amazon Bedrock の InvokeModel および InvokeModelWithResponseStream API に対応しました。既存の Bedrock SDK (boto3 の bedrock-runtime クライアントなど) は endpoint_url をゲートウェイに向けるだけで、OpenAI や Anthropic を含む複数のモデルプロバイダーに 1 つの統制されたエンドポイント経由でアクセスできます。あわせてモデルフォールバックルーティングが追加され、プライマリの宛先がスロットリング、容量不足、到達不能のときに、ゲートウェイがルールで定義した代替の宛先へ自動で切り替えます。サーキットブレーカーが組み込まれており、障害中の宛先をスキップして無駄な試行による遅延を抑えます。中国リージョンを除く、AgentCore Gateway が利用できるすべてのリージョンで利用できます。 AWS Interconnect – last mile の Megaport とのプレビュー提供を発表 AWS は、ブランチオフィス、データセンター、リモート拠点を AWS にプライベート接続するマネージドサービス AWS Interconnect – last mile について、Megaport をパートナーとするプレビュー提供を発表しました。AWS マネジメントコンソールからリージョン、帯域幅、Direct Connect Gateway ID、パートナーのサブスクライバー ID を指定するだけで接続を作成でき、BGP ピアリング、VLAN、ASN の設定は自動化されます。2 つの物理サイトにまたがる 4 本の冗長接続が自動的にプロビジョニングされ、99.99% の SLA が提供されます。プレビューはサンノゼと北バージニアの 2 メトロで利用でき、北カリフォルニアリージョンとバージニア北部リージョンに接続できます。 AWS Continuum for code vulnerabilities が一般提供開始 AWS は、コード脆弱性の発見・検証・優先順位付け・修復を自動化する AWS Continuum for code vulnerabilities の一般提供を開始しました。AWS 環境からリソーストポロジー、IAM の関係、ネットワーク到達性を含むコンテキストグラフを構築し、検出した脆弱性を隔離サンドボックスで実際にテストして悪用可能かを確認します。悪用可能性の証拠とブラストラディウス評価を添えた修正パッチを、GitHub の Pull Request または Amazon S3 へのパッチファイルとして届けます。料金はコード 100 万行あたり月額 200 USD からの段階制コンテキスト料金と、1 推論ユニットあたり 10 USD の従量料金の 2 軸です。Amazon GuardDuty や AWS Security Hub など既存のセキュリティサービスと併用する前提で設計されています。 今週は GuardDuty や AWS Continuum for code vulnerabilities といったセキュリティ強化から、AWS Transform によるネットワーク・ストレージ移行支援、SageMaker のモデルカスタマイズまで、守りと攻めの両面でアップデートが広がった印象です。re:Invent を目前に控え、各サービスが着々と足場を固めているのを感じますね。来週はどんな発表が飛び出すでしょうか。それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

本記事は、2026年10月5日にNetworking &amp; Content Delivery で公開された Powering predictable costs with AWS Direct Connect flat-rate pricing を翻訳したものです。 従来のオンプレミスネットワークでは、コストの予測可能性が常にネットワーク接続予算編成において中心的な要素でした。組織は専用線、Multiprotocol Label Switching (MPLS) リンク、専用クロスコネクトを利用しており、どれだけ多くのデータを転送しても請求額は変わりませんでした。クラウド上にアーキテクチャを再構築すると、従量課金制の柔軟性が得られます。初期コミットメントがないため、この柔軟性はほとんどのワークロードに適しています。一方、AWS からオンプレミスインフラストラクチャへ大量のデータを継続的に転送するワークロードでは、データ転送（送信）(DTO) 料金が送信トラフィックに応じて増加します。変動する DTO コストは、予測と予算策定が次第に難しくなります。一般的な例として、生成 AI のトレーニングと推論、医用画像、動画レンダリング、大規模データ分析があります。 予算策定を簡素化するため、 AWS Direct Connect は 10 Gbps および 100 Gbps の専用接続で 定額料金 を提供するようになりました。この料金モデルでは固定料金が適用され、選択したティアに含まれる AWS リージョン からの DTO については GB 単位の料金が発生しません。ティアは接続範囲に応じて区分されており、トラフィックの流れに合ったティアを選べます。 ※訳者注記：定額料金は接続（物理ポート/ポートペア）単位の課金で、仮想インターフェース（VIF）単位ではありません。対象となるのは、接続とその配下のすべての VIF が同一 AWS アカウントで所有されている専用接続のみです（ホスト型接続・ホスト型 VIF は対象外）。 この記事では、定額料金を使用する Direct Connect 接続の設定方法を説明します。続いて、ワークロード要件に基づくティアの選択、定額料金と従量課金制の併用、既存接続の変換について、シナリオを通じて解説します。 Direct Connect の定額料金で得られるもの 予測可能な時間あたり固定コスト: ティアの対象リージョンでは GB 単位の DTO 料金が発生せず、接続またはポートペアごとに固定料金を支払います。これにより、コストの予測、予算策定、チーム間での配分が容易になります。 標準装備の回復性: 定額料金では、デフォルトで異なるデバイスまたはロケーションに接続をポートペアとしてプロビジョニングします。回復性は追加の手順ではなく、このサービスの一部として組み込まれています。 選択肢と柔軟性: 定額料金を利用しながら従量課金制も使用でき、ワークロードに合った請求モードを選択できます。 Direct Connect の定額料金の仕組み 定額料金を使用する新しい Direct Connect 接続の作成方法を順に説明します。 ステップ 1. トポロジを選択する 接続を作成するときに、請求モードと回復性トポロジを選択します。図 1 は、定額請求モードと 高い回復性 トポロジを示しています。このトポロジでは、2 つの異なる Direct Connect ロケーション に 1 つずつ接続をプロビジョニングします。回復性トポロジの詳細については、 Direct Connect の回復性に関する推奨事項 ページをご覧ください。 図 1. 新しい Direct Connect 接続の請求モードと回復性トポロジの選択 ステップ 2. 接続を設定する 定額接続を設定するには、10 Gbps または 100 Gbps を選択します。次に、意図する回復性トポロジを宣言する接続の論理グループである、回復性グループを定義します。各ポートペアは、同一または異なる Direct Connect ロケーション内の別々のデバイスにある 2 つの物理ポートで構成されます。図 2 では、高い回復性トポロジ用に analytics-prod-ap という回復性グループを作成しています。シナリオ 1 で説明するように、定額接続を 1 つだけリクエストし、その接続と既存の対象接続を同じ回復性グループに追加してペアにすることもできます。 図 2. 回復性グループ、ロケーション、定額料金ティアの設定 2 つの接続は、アクティブ-アクティブまたはアクティブ-スタンバイ構成で使用します。実効帯域幅は 1 ポート分です。たとえば、10 Gbps のポートペアが提供する帯域幅は 20 Gbps ではなく 10 Gbps です。ワークロードで単一ポートを超えるスループットが必要な場合は、追加のポートペアをプロビジョニングします。 定額料金のティアは、接続の地理的範囲に基づきます。ティアは、AWS リージョンと Direct Connect ロケーション間のトラフィックパスを定義します。トラフィックフローに合ったティアを選択すると、その契約対象パスでは GB 単位の DTO 料金が発生しません。契約対象外の地理的範囲を経由して送信されるトラフィックには、標準の DTO 料金が適用されます。詳細については、 AWS Direct Connect 料金ガイド をご覧ください。 ※訳者注記：[Tierとは？] Tierは、地理的範囲の区分としてTier1(ローカル)からTier5(全AWSリージョン)まで存在し、送信元リージョンとDirect Connectロケーションが地理的に近く、狭い範囲であれば安価なTier1、より広くカバーするほど高価なTier5に寄ります。詳細は AWS DocumentのDirect Connect Flat-rate ページ と Direct Connect Flat-rateの料金ページ を参照ください。 ステップ 3. 確認して作成する トポロジ、接続ロケーション、ポート速度、請求モードを確認し、[作成] を選択します（図 3）。これで Direct Connect 接続に定額料金が設定され、固定の時間料金と、ティアの対象リージョンに含まれる GB 単位の DTO が適用されます。 図 3. 作成前の定額接続注文の確認 定額料金の実用例 以下のシナリオでは、シングルリージョン構成からマルチリージョンワークロード、既存接続の変換、アカウントをまたいだ請求モードの分離まで、定額料金の実際の利用方法を示します。 シナリオ 1: シングルリージョン – ローカルの Direct Connect ロケーションを介して接続する 図 4 は、us-west-2 に AWS Transit Gateway があるシングルリージョン構成を示しています。オンプレミスシステムは Seattle メトロ圏の Direct Connect ロケーションを介して AWS に接続し、施設内のユーザーはローカルアプリケーションへデータを取得します。たとえば、耐久性と一元管理のために画像検査データを AWS に保存し、医療従事者が必要に応じて閲覧する大規模な医療システムを運用しているとします。このワークロードから、2 つの要件が生じます。繁忙期に送信転送が急増して従量課金制のコストが上昇するため、年間を通じて予測可能な請求が必要です。また、ユーザーはそのデータに依存しているため、光ファイバーの切断、デバイス障害、ロケーション障害が発生してもオンライン状態を維持する必要があります。 すでに Seattle, WA の Digital Realty SEA10 に Direct Connect 接続が 1 つあります。Seattle, WA の TierPoint に 2 つ目の接続を作成し、両方を回復性グループに追加します。送信元リージョンが Direct Connect ロケーションと同じメトロ圏にあるため、ポートペアの請求モードを Tier 1 に設定します。アクティブ-スタンバイを設定し、一方の接続でトラフィックを伝送し、もう一方は障害発生時に備えて待機させます。 これらのロケーションを経由する us-west-2 からのデータ転送（送信）は、GB 単位の DTO 料金なしで時間あたり固定料金の対象になります。受信転送は、従量課金制の場合と同様に引き続き無料です。これにより、予測可能な請求と、AWS リージョンへの 2 ロケーションにまたがる回復性の高いハイブリッド接続が得られます。 図 4. 1 つのメトロ圏内の 2 つの Direct Connect ロケーションにまたがるシングルリージョンの定額料金構成 シナリオ 2: マルチリージョン – すべてのワークロードリージョンをカバーするティアを選択する 図 5 は、 AWS Cloud WAN 上に構築されたマルチリージョンネットワークを示しています。 Amazon VPC リソースは本番セグメントにアタッチされ、 Direct Connect ゲートウェイ はハイブリッドセグメントにアタッチされています。コアネットワークエッジは us-east-1 と ca-central-1 にあります。データセンターへの接続は、Direct Connect ゲートウェイにアタッチされた トランジット仮想インターフェイス を介して送信されます。AWS から米国とカナダの地上波送信施設へ高ビットレート動画をストリーミングするリニアチャンネル送出システムを運用しています。送出は、米国市場向けには us-east-1、カナダ市場向けには ca-central-1 で実行されます。 まず、us-east-1 用に Reston, VA の CoreSite VA1 にポートペアを、ca-central-1 用に Montreal, CAN の Cologix MTL3 に 2 つ目のポートペアを用意し、どちらにも Tier 1 の定額料金を適用します。各契約は、それぞれのリージョンから Direct Connect ロケーションへのローカルパスをカバーするため、各国内の定常時トラフィックは、GB 単位の DTO 料金なしで選択した定額料金ティアの対象になります。 両方のリージョンにまたがる 最大回復性 トポロジが必要です。一方のリージョンに障害が発生した場合、稼働中のリージョンから同じ Direct Connect ロケーションを介して、その市場向けのサービスを提供します。このクロスリージョンパスは Tier 1 の対象範囲を超えるため、標準の DTO 料金に戻ります。そこで、同一大陸など、同じ一般的な地理的範囲にある送信元リージョンと、それらに対応する Direct Connect ロケーションをカバーする Tier 2 にアップグレードします。これにより、いずれのロケーションを経由する us-east-1 と ca-central-1 からのトラフィックも 1 つの定額料金ティアの対象となり、通常運用時とフェイルオーバー時の両方でコストを予測できます。 他の地域へ拡張するときは、ローカルの Direct Connect ロケーションにポートペアを追加し、必要に応じて、下位ティアのリージョンを含む上位ティアへ移行します。公開されているティアを超える対象範囲については、AWS アカウントチームにお問い合わせください。 図 5. 2 つのメトロ圏にまたがる Cloud WAN とリージョナルポートペアを使用したマルチリージョンの定額料金構成 シナリオ 3: 既存接続を定額料金へ変換する Amazon Simple Storage Service (Amazon S3) からオンプレミスインフラストラクチャへ、大量のデータを従量課金制で継続的に転送するワークロードを、高い回復性トポロジで運用しています（図 6）。回復性グループ内には、Slough, GBR の Equinix LD5 と London, GBR の Telehouse West に 100 Gbps の専用接続が 1 つずつあります。ルーティングにはアクティブ-アクティブ構成を使用しています。送信トラフィックによって、eu-west-2 からデータセンターへデータセットを転送します。データセットの増加に伴って DTO も増え続けるため、予測可能な時間あたりコストが必要です。同じトポロジを維持して請求モードだけを変更し、これらの接続を定額料金の Tier 1 に変換することを計画しています。 図 6. アクティブ-アクティブ接続を定額料金へ変換する大容量 DataSync ワークロード 従量課金制では、各接続のポート時間料金に加えて GB 単位の DTO 料金を支払うため、送信量に応じて請求額が増加し、継続的に大量のデータを転送する場合は予測が難しくなります。定額料金では、ペアに対する単一のポート料金として時間あたり固定料金を支払い、ティアの対象リージョンからの DTO が含まれます。ティアの対象リージョン内であれば、転送量にかかわらずコストは一定です。 転送量に基づいて 2 つの選択肢を比較した後、新しい接続をリクエストする代わりに、Equinix LD5 と Telehouse West の既存接続を定額料金の Tier 1 に変換します。両方のポートは同じトポロジで同じトラフィックを引き続き伝送し、請求だけが変わるため、トラフィックには影響しません。図 7 は、コンソールの [請求モードを変更] ダイアログを示しています。 UpdateConnectionsBillingMode アクションは、 AWS Direct Connect API を使用して、同じ操作をプログラムで実行します。変換はロケーションレベルで適用されるため、1 つの接続を定額料金に変換すると、同じアカウントのその Direct Connect ロケーションにあるすべての接続が変換されます。 図 7. コンソールで既存接続を従量課金制から定額料金へ変換 各ポートペアがアクティブ-アクティブモードで提供するスループットは 1 ポート分であるため、2 つの接続は合計 200 Gbps のポート容量に対して、100 Gbps の使用可能な帯域幅を提供します。単一ロケーションに障害が発生しても、稼働中のサイトには正常な接続が 1 つ残り、そのロケーションの全負荷を伝送できます。100 Gbps の実効帯域幅内に収めるため、 AWS DataSync でデータを移動し、タスクの帯域幅制限を 100 Gbps に設定します。次に、 Amazon CloudWatch で、両方の接続の ConnectionBpsEgress の合計に対するアラームを追加し、総ポート容量の使用率が 50% に近づいたときにトリガーされるように設定します。これにより、十分な余裕を確保し、単一ロケーションに障害が発生しても 1 ポートペアの実効帯域幅を超えないようにできます。 シナリオ 4: 同じ Direct Connect ロケーションで異なる請求モードを使用する あるワークロードには定額料金が適していても、別のワークロードには適さない場合があります。たとえば、大量のトラフィックを継続的に送信する高ボリュームのストリーミングワークロードと、データ転送量がはるかに少ない社内イントラネットの業務アプリケーションを同時に運用しているとします。ストリーミングワークロードの継続的なトラフィックには定額料金の方が経済的である一方、イントラネットアプリケーションの少ない使用量には従量課金制が適しています。レイテンシー要件と既存のコロケーション拠点の都合で、両方のワークロードが同じ Direct Connect ロケーションを経由するため、ロケーションだけで分離することはできません。 請求モードは、アカウント内のロケーション単位で設定されます。同じロケーションで異なる請求モードを使用するには、 AWS Organizations の同じ組織内にある 2 つのネットワークアカウントへ、2 つのワークロードを分離します。ストリーミング接続は、専用のネットワークアカウントで定額料金を使用してプロビジョニングします。イントラネットアプリケーションは、一元管理するネットワークアカウントで従量課金制のままにします。図 8 では、両方のワークロードが同じ Direct Connect ロケーションと物理接続を共有し、ストリーミングワークロードには定額料金、イントラネットワークロードには従量課金制を適用しています。 図 8. 同じ Direct Connect ロケーションにある 2 つのアカウントで請求モードを分離 データを使用して定額料金を評価する 定額料金へ切り替える前に、まず手元にあるデータを確認します。トラフィックメトリクスと請求記録は、定額料金がワークロードに適しているかどうかを判断するのに役立ちます。以下の手順では、確認すべき CloudWatch メトリクスとコストデータを説明します。 Amazon CloudWatch で転送パターンを分析する 各 Direct Connect 接続の ConnectionBpsEgress CloudWatch メトリクス を確認します。このメトリクスは送信ビット数/秒を記録し、トラフィックの傾向を把握できます。 RUNNING_SUM() CloudWatch 数式 を適用して、請求期間中の累積 DTO 量を可視化できます。図 9 は、ピーク需要と増加傾向を可視化する方法を示しています。継続的な高スループット、累積転送量の月ごとの増加、予測できない急増は、定額料金が適している可能性を示す兆候です。 図 9. Amazon CloudWatch で Direct Connect のトラフィックと累積データ転送量をモニタリング AWS Cost Explorer と AWS Data Exports で現在の支出を確認する AWS Cost Explorer を使って、Direct Connect の DTO にかかっている支出を確認します。さらに詳しく見るには AWS Data Exports を使います。ここでは、Direct Connect の DTO が次の形式の使用タイプとして表示されます: {Region}-{DirectConnectLocation}-DataXfer-Out:dc.{#} 。 たとえば EUW2-THNO2-DataXfer-Out:dc.3 は、eu-west-2 から英国ロンドンの Telehouse West への DTO を表します。この内訳はロケーションごとの転送コストを示します。定額料金はそのロケーションのすべての接続に影響するため、この粒度が重要になります。図 10 は、月ごとのコストと使用量の内訳です。 図 10. AWS Cost Explorer における月次の Direct Connect コストと使用量の内訳 月平均の送信支出を、対象ティアの定額料金と比較します。次に、その定額料金を GB 単位の DTO レートで割ります。転送量がそのしきい値を常に満たす (または上回る) 場合や、CloudWatch メトリクスが増加傾向にある場合は、定額料金が適している可能性があります。 考慮事項 専用接続のみ対応: 定額料金はホスト接続では利用できません。 マルチリージョンリソース: 1 つの接続から、Direct Connect ゲートウェイ、AWS Transit Gateway、AWS Cloud WAN を介して複数リージョンのリソースに到達できます。マルチリージョンリソースをアタッチする前にティアを確認し、対象に含めたい各リージョンがカバーされているか確かめてください。 新しいリージョンへの拡張: プロビジョニング後にトポロジを新しいリージョンへ広げる場合、ティアの変更が必要になることがあります。ティア対象外のリージョンからのトラフィックは、ティアを引き上げるまで標準の DTO 料金で請求されます。 別途請求される料金: AWS Transit Gateway や AWS Cloud WAN でのデータ処理など、その他の AWS サービス料金は別途発生します。 AWS Direct Connect SiteLink でのデータ転送はどのティアでもカバーされず、標準料金で請求されます。 プロバイダー料金: コロケーションプロバイダーや AWS Direct Connect パートナー によるクロスコネクト料金・コロケーション料金、およびネットワークプロバイダーによるラストマイル回線料金は、定額料金には含まれません。 接続ごとの請求モード: 1 つの AWS アカウント内では、同じ Direct Connect ロケーションにあるすべての接続が同じ請求モードを使う必要があります。ただし、同じアカウントでもロケーションが異なれば別のモードを使えるため、一方のロケーションは定額料金、もう一方は従量課金制、という使い分けが可能です。 回復性と SLA のカバー範囲: 回復性のためにはポートペアを推奨しますが、必須ではありません。現在接続が 1 つだけの場合は、同じロケーションにもう 1 つ接続を追加し、両方を同じ回復性グループに関連付けてポートペアを構成できます。アクティブ-アクティブとアクティブ-スタンバイのいずれかを選択します。ペアの 2 つ目の接続は追加料金なしで含まれます。回復性グループを持たない定額接続は、引き続き AWS Direct Connect サービスレベルアグリーメント の単一接続 SLA の対象となります。 まとめ この記事では、AWS Direct Connect の定額料金によって、大容量ワークロードの変動する GB 単位 DTO 料金を、時間あたり固定料金に置き換える方法を紹介しました。設定手順を順に説明し、シングルリージョンの医用画像から、クロスリージョンフェイルオーバーを伴うマルチリージョンの動画プレイアウトまでのシナリオを取り上げました。さらに、既存接続を変換する方法や、アカウントをまたいで請求モードを使い分ける方法も示しました。CloudWatch メトリクスと Cost Explorer のデータを使えば、自社の転送量と増加傾向が切り替えに見合うかを評価できます。トラフィックの流れに合ったティアを選び、回復性グループと組み合わせることで、時間あたり固定料金・標準装備の回復性・予測可能でチーム間に配分しやすい請求が得られます。 まずは、 AWS Direct Connect コンソール と、最新料金を掲載した 定額料金ページ をご覧ください。 ご不明な点があれば、 AWS re:Post でスレッドを立てるか、 AWS サポート にお問い合わせください。 この記事の翻訳はソリューションアーキテクトの長屋が担当しました。 <!-- '"` -->

本記事は 2025 年 8 月 5 日に公開された「 Best practices for analyzing AWS Config recording frequencies 」を翻訳したものです。 AWS Config は、AWS リソースおよび AWS Organizations 全体の設定変更を追跡します。AWS Config は設定レコーダーを使用して変更を検出し、それを設定項目 (CI) として記録します。インフラストラクチャが成長し複雑になるにつれ、運用上の可視性の維持、コンプライアンス要件への対応、セキュリティ態勢を支えるために、適切な記録頻度を選択することが重要になります。 2023 年の 定期的記録機能のローンチ 以降、記録方法には 2 つの選択肢があります。1 つ目は継続的記録で、設定変更が発生するたびにすべてをキャプチャし、環境をリアルタイムに可視化します。2 つ目は定期的記録で、リソースの最新の状態を 24 時間ごとにキャプチャしますが、記録されるのは前回記録した状態と異なる場合のみです。定期的記録は、変更が多い環境において CI の総数を削減できます。それぞれのアプローチは異なる運用ニーズに対応しており、最適な記録頻度を選択することで、個々のユースケースに適した可視性のレベルを維持できます。 この記事では、環境を評価し、運用、セキュリティ、コンプライアンスの目標に最も適した記録頻度を選択する方法を解説します。AWS Config を導入する際の意思決定のフレームワークと一般的なシナリオを取り上げ、リソースインベントリやコンプライアンスレポート、およびコストを最適化するためのベストプラクティスを紹介します。さらに、これらのベストプラクティスは、プロアクティブコントロールを適用して大規模なガバナンスを実現し、運用上の俊敏性を高めることにも役立ちます。 AWS Config に求める要件を理解する AWS Config は環境内の変更を追跡することで、主に次の 4 つの目的を果たします。それぞれ記録頻度の要件は異なります。 リソースインベントリの管理 コンプライアンス評価のための Compliance-as-Code 運用調査とセキュリティ調査の効率化 継続的な監査 記録頻度の決定は、これらの目的において AWS Config をどのように使用するかに合わせる必要があります。ワークロードによって要件は異なります。リアルタイムのコンプライアンス監視やセキュリティインシデント対応には、通常、継続的記録が必要です。リソースインベントリや運用上のトラブルシューティングは、変更のパターンや対応時間の要件によっては、定期的記録でも十分に機能する場合があります。AWS Config を使用すると、ユースケースにとって最も重要な環境内の変更を追跡できます。そして、修復ルール、アラート、分析を作成することで、それらの変更に対応し、将来の変更に備えることができます。こうした違いを理解することで、運用ニーズに合ったきめ細かな記録戦略を実装できます。 環境の特性 AWS 環境の特性は、最適な記録頻度に大きく影響します。動的な環境には、 AWS Lambda 、 Amazon EKS 、 Amazon EMR といったサービスを使用して自動的にスケールする一時的なリソースが含まれます。これらのリソースは、ワークロード、スケジュール、開発およびデプロイのパターンに応じて頻繁に状態が変化します。静的な環境には、 Amazon RDS や Amazon VPC といったサービスを使用した、より永続的なリソースが含まれます。これらのリソースは、ネットワークやデータの要件により、長期にわたって存続し、一定の状態を保つことが期待されます。変更頻度の低い長時間稼働のリソースは、どちらの記録モードでも同程度の CI 数になる可能性があるため、完全な可視性を得られる継続的記録が望ましくなります。 記録頻度の意思決定フレームワークを検討するにあたり、次の例を考えてみましょう。 シナリオ A: 開発環境で、Amazon EMR と Amazon EC2 スポットインスタンス を使用して短時間のタスクをデプロイし、終了させています。各タスクの実行時間は 1 時間未満です。ジョブごとにスポットインスタンスを解放し、Amazon EMR クラスターを終了させます。また、複数の変更を加えています。 シナリオ B: 本番環境で、クラスターとタスクは終了前に少なくとも 24 時間稼働し、クラスターやタスクの設定への変更はほとんど行いません。 記録頻度の選択を成功させるには、主要なユースケースと併せて次の 3 つの重要な要素を評価する必要があります。 リソースの静的性 リソース間の関係 ベースラインの変更頻度 図 1. Amazon EMR および関連サービスと AWS Config 設定項目の関係 リソースの静的性 リソースの静的性の分析とは、リソースがいつ、どのように状態を変えるかを理解することです。記録モード間で CI 数を比較することで、生成されるデータ量の差を定量化し、リソースの追跡を最適化できます。シナリオ A のように短命なリソースが存在する環境では、継続的記録によって開始、終了、および関連する変更が記録され、運用状況を漏れなく把握できます。定期的記録では、開始と停止が 24 時間以内に収まるようなリソースの一時的な状態変化は記録されないため、運用状況の把握に欠落が生じる可能性があります。シナリオ B のように 24 時間を超えて稼働するリソースがある静的な環境では、継続的記録であれば引き続き運用状況を漏れなく把握できます。そして定期的記録では、2 日間にわたる状態の遷移が記録されます。AWS Config は、24 時間を超えて存続するリソースについては、どちらの記録方法でも開始と終了を記録します。 訳注：ここでの分岐点はリソースの寿命です。例えば、10 月 1 日に起動して 10 月 5 日に停止したリソースは、開始と終了が別々の記録タイミングに入るため、どちらの記録方法でも 2 つの CI が記録されます。つまり継続的記録を定期的記録に切り替えても CI 数は減りません。一方、1 時間で起動と停止が完了するようなリソースは、定期的記録では次の記録タイミングを迎える前に消えてしまうため記録されません。CI 数は減りますが、その分の可視性は失われます。 リソース間の関係 Amazon EMR の環境と DescribeCluster API アクションで確認できるコンポーネントを考えてみましょう。Amazon EMR クラスターを作成すると、多くのやり取りが発生します。例を挙げます。 Amazon EC2 インスタンスがアタッチされる Amazon VPC 上で動作する IAM プロファイルを利用する EBS ボリュームがアタッチされる EC2 インスタンスにパッチを適用するため AWS Systems Manager にアタッチされる AWS Config ルールがトリガーされる つまり、1 つの変更が関連リソースにおいて複数の CI を生成する可能性があります。 間接的な関係 を使用している場合、EC2 インスタンスへの 1 つの変更が 4 つの CI を生成することがあります。 セキュリティグループ サブネット VPC EC2 インスタンス 訳注：間接的な関係 (indirect relationship) はデフォルトで有効な設定で、リソース A の Describe API からは導出できない逆方向の関係 (例: セキュリティグループから EC2 インスタンスへの関係) に基づいて CI を生成する仕組みです。AWS サポートへの依頼により、アカウントおよびリージョン単位で無効化できます。詳細は AWS Config FAQ を参照してください。 Systems Manager のマネージドインスタンスの場合、定期的記録でも開始と停止の少なくとも 2 つの CI が記録されます。これは非マネージドのインスタンスとは異なり、追加の CI が生成されることを意味します。しかもこれは、 コンプライアンスチェックのための AWS Config ルール (これもまた関係のひとつです) が動作する前の段階での話です。 環境内に存在し得る AWS サービス間のこうした関係を理解することは、適切なリソースに適切な記録頻度を設定するために重要です。 ベースラインの変更頻度 記録設定を停止またはオーバーライドすると、リソースタイプごとに記録頻度が変わることになります。また、AWS Config のレコーダーの料金は AWS アカウントごと、および AWS リージョンごとに配信された CI 単位で発生するため、頻度の変更が妥当かどうかを判断するには、リソースタイプごとの変更頻度を理解する必要があります。 Amazon EMR や Amazon EKS を考えてみましょう。クラスターの作成で 1 CI、クラスターの終了で 1 CI が生成されます。本記事の公開時点では、継続的記録のコストは配信された CI あたり $0.003、定期的記録は配信された CI あたり $0.012 です。シナリオ B では、クラスターと同様に、一時的な EC2 インスタンスが 24 時間を超えて稼働します。定期的記録のほうがコスト効率が高くなるのは、インスタンスの開始・停止のタイミングがクラスターの開始・停止と一致せず、かつインスタンスの開始から停止までの 2 日間にインスタンス以外で 3 つの CI が発生する場合に限られます。インスタンスタイプの変更やタグの更新といった変更は、通常、CI の総数を削減できるほど頻繁には発生しません。 分析 定期的記録と継続的記録の違いを理解するには、まず継続的記録から始めて、CI 数の推移を観察します。次に、特定のリソースについて定期的記録に切り替え、CI 数を比較します。CI をクエリする方法の例については、「 AWS Config の請求を把握するために、月ごとに記録された CI 数を利用する方法を教えてください。 」を参照してください。 以下の表は、シナリオ A を想定した場合の、継続的記録と定期的記録における全リソースの 1 日あたりの CI 数をまとめたものです。 リソースタイプ 継続的 定期的 AWS::EC2::NetworkInterface 1477 303 AWS::EC2::SecurityGroup 535 86 AWS::EC2::Subnet 278 45 AWS::ECS::Service 505 0 AWS::EC2::VPC 111 6 AWS::ServiceDiscovery::Instance 20 0 AWS::Lambda::Function 10 0 AWS::ECS::TaskDefinition 8 0 AWS::EC2::SubnetRouteTableAssociation 3 0 AWS::KMS::Key 2 0 AWS::EC2::NatGateway 1 0 AWS::KMS::Alias 2 0 AWS::Events::Rule 1 0 AWS::ECS::Cluster 1 0 表 1. シナリオ A を想定した場合の、継続的記録と定期的記録における全リソースの 1 日あたりの CI 数の比較 以下の表は、シナリオ B を想定した場合の、継続的記録における全リソースの 1 日あたりの CI 数と、EC2 タイプにおける定期的記録との差分をまとめたものです。 リソースタイプ 継続的 定期的 AWS::CloudWatch::Alarm 465 460 AWS::Config::ConformancePackCompliance 45 47 AWS::Config::ResourceCompliance 42784 10090 AWS::EC2::Instance 1383 139 AWS::EC2::NetworkInterface 1562 1029 AWS::EC2::SecurityGroup 184 24 AWS::EC2::Subnet 134 16 AWS::EC2::Volume 4469 3179 AWS::EC2::VPC 127 14 AWS::DynamoDB::Table 3298 3113 AWS::SSM::AssociationCompliance 9576 6879 AWS::SSM::Document 1 AWS::SSM::ManagedInstanceInventory 3308 2184 AWS::SSM::PatchCompliance 1481 766 表 2. シナリオ B を想定した場合の、継続的記録における全リソースの 1 日あたりの CI 数と、EC2 タイプにおける定期的記録との差分 訳注：表 2 では EC2 関連のリソースタイプのみを定期的記録に切り替えており、それ以外のリソースタイプは継続的記録のままです。そのため非 EC2 行の「定期的記録」列は、定期的記録による削減効果を示すものではありません。たとえば AWS::Config::ResourceCompliance の大幅な減少は、EC2 の変更が減ったことでルール評価の回数が減った結果です ( AWS::Config::ResourceCompliance と AWS::Config::ConformancePackCompliance は AWS Config の 仕様上、定期的記録に設定できません )。また AWS::SSM::Document の定期的記録の欄が空なのは、計測時にデータが得られなかったためです。 この分析の目的は、継続的記録において 1 日あたりの CI が 4 を超え、かつ定期的記録に切り替えることで CI の総数が 75% 以上削減されるリソースタイプを見つけることです。表 2 では、EC2 インスタンスは定期的記録により CI が 90% 減少していますが、 NetworkInterface は 34%、 Volume は 30% の削減にとどまっています。表 1 では、 EC2::SubnetRouteTableAssociation 、 KMS::Key 、 EC2::NatGateway 、 KMS::Alias 、 Events::Rule 、 ECS::Cluster は CI が 4 を超えておらず、定期的記録では CI がゼロになりました。 その結果、前述の 3 つの重要な要素を踏まえると、(継続的記録から定期的記録に切り替えた場合に) 表 2 では NetworkInterface と Volume により AWS Config の全体コストがむしろ増加し、その一方で表 1 では全体コストが削減されることがわかります。 ここからは、AWS Config の記録機能における 4 つの一般的なユースケースについて説明します。 ユースケース 1: リソースインベントリの管理 AWS リソースの正確なインベントリを維持するには、AWS Config において適切な設定追跡のアプローチを選択する必要があります。定期的記録モードと継続的記録モードがコスト、効率、セキュリティ、運用上の可視性にどう影響するかを理解することで、リソース管理の戦略を最適化できます。また、AWS が (リソース間の) 関係を利用して既にインベントリを取得していることも理解しておく必要があります。AWS Config では、すべての関係のインベントリを一元的に取得することになるため、どの関係に追跡する価値があるのかを理解し、インベントリが重複している箇所を特定することが重要です。 Amazon EMR のタスクフローの例の分析に基づくと、まずは 1 つのリソースタイプ、たとえば EC2 インスタンスについて定期的記録を有効にしたいと考えるかもしれません。しかし、前述のリソース間の関係のセクションで述べたとおり、他のリソースも分析する必要があります。シナリオ A の場合、AWS Config は (EC2 インスタンスタイプとは異なり) 少なくとも Systems Manager に関連付けられた開始イベントと停止イベント、およびインスタンスに関連付けられた EBS ボリュームを引き続き記録します。EC2 インスタンス上のソフトウェアインベントリの変更を記録し続けるには、 ManagedInstanceInventory を記録する必要があります。以下のグラフは、Amazon EMR クラスターの起動に伴って多数のサービスで CI が増減する様子を示しています。 図 2. 継続的記録において、Amazon EMR クラスターの起動と停止に伴って増減する Amazon EMR および関連サービスの AWS Config 設定項目 ベストプラクティス: 環境の要件に基づき、複数のサービス (EC2、Systems Manager) からの追跡が必要かどうかを評価してください。 ユースケース 2: コンプライアンス評価のための Compliance-as-Code HIPAA (Health Insurance Portability and Accountability Act)、GDPR (General Data Protection Regulation)、PCI DSS (Payment Card Industry Data Security Standard) などの規制の対象となる組織は、AWS Config を使用して Compliance-as-Code のフレームワークを導入するのが一般的です。このアプローチでは、ルールをコードとして定義することでコンプライアンスの監視を自動化し、AWS 環境全体で一貫性のあるスケーラブルなコンプライアンスチェックを実現します。本番環境では、PHI を処理するリソースに影響する設定変更について、詳細な監査履歴とリアルタイムの可視化を維持するために、継続的記録を導入することが考えられます。 Amazon EMR のタスクフローの例の分析に基づくと、 AWS::Config::ResourceCompliance の CI が最も多いことに気づくかもしれません。ここで重要なのは、コンプライアンスステータスを正確にレポートし、AWS Config の設定タイムラインを使用するには、このリソースタイプを記録する必要があるという点です。さらに前述のとおり、多くの AWS Config ルールは変更をトリガーとして実行され、 ResourceCompliance の CI を生成します。コンプライアンスのために AWS Config ルールを利用する場合は、ルールのトリガーと記録頻度の戦略を揃えることで、効果を最大化できます。また、関連する AWS Config や AWS Security Hub のコントロール に必要なリソースタイプも評価する必要があります。 ベストプラクティス: AWS Config ルールと記録頻度を揃えることで、コンプライアンスレポートとコストの両方を最適化してください。 ユースケース 3: 運用調査とセキュリティ調査の効率化 リソースの状態を正確に把握し続けることで、リソースに関する確かな情報が得られ、開発のプラクティスを効率化できます。また、問題の修復とその状態の確認をより迅速に行えます。AWS Config ルールは変更に基づいて迅速に対応するのに役立ち、予期しないイベントの通知を受け取ることができます。変更に対する可視性のレベルやニアリアルタイムの更新は、環境とワークフローによって異なります。下位の開発環境 (本番環境から遠い開発段階の環境) では、リソース変更のうち、24 時間を超えて残っているもののみを追跡したい場合があります。ステージング環境では、他のワークロードとの依存関係や関係を追跡したいものの、即時の修復アクションを実装する必要はない場合があります。 前述の分析に基づくと、短命なリソースについて記録頻度を比較した結果 (表 1) から、頻繁に変更が発生する下位環境における日次の異常が明らかになります。Amazon EMR クラスターを作成する際、AWS Key Management Service (AWS KMS)、DynamoDB、Events といったサービスがインフラストラクチャにおける重要な依存関係として浮かび上がることがあります。CI が最も多いリソースタイプを選ぶのではなく、頻繁に変更が発生する下位環境における異常や、本番前環境における関係ベースのサービス (他の多くのリソースタイプを伴うサービス) といったように、環境ごとの役割を評価する必要があります。以下のグラフは CI の増減を示していますが、図 2 とは異なりより散発的であり、運用上のニーズに基づいてサービスの監視対象をより絞り込めることを表しています。 図 3. 定期的記録において、Amazon EMR クラスターの起動と停止に伴って増減する Amazon EMR および関連サービスの AWS Config 設定項目 ベストプラクティス: 複数のアカウントを使用して環境とワークロードを分離し、AWS Config の記録戦略をより細かく調整してください。 ユースケース 4: 継続的な監査とニアリアルタイム検出 多くの組織では、チームの運用を標準化するための組織内のプロセスやコントロールが定められています。コンプライアンスフレームワークは体系化された要件を提供しますが、組織は固有のセキュリティニーズやリスク許容度に基づいて、追加のコントロールやオプションのコントロールを実装することもできます。AWS Config を使用してコントロールを継続的に監査する場合は、影響度を分類し、デプロイ戦略を検討することが重要です。IDE や CI/CD パイプラインにランタイムバージョンの開発・デプロイのコントロールがある場合は、AWS Config のランタイム評価で取り組みを重複させるのではなく、既存のコントロールを使用することをお勧めします。同様に、ニアリアルタイムでアクションを実行するイベントベースのアーキテクチャがある場合は、重要な変更の即時検出と対応を確実に行うために、定期的記録ではなく継続的記録を使用することをお勧めします。 前述の分析に基づくと、短命なリソースについて記録頻度を比較した結果 (表 1) から、AWS Lambda 関数における一時性の影響がわかります。AWS Lambda 関数をアドホックに作成・削除しており、かつ IDE や CI/CD にコントロールがある場合、内部監査のための継続的記録は開発者にとってノイズになる可能性があります。組織内コントロールごとに影響を評価し、記録が 24 時間ごとの定期的記録に設定されているにもかかわらず 8 時間ごとにルールをトリガーしてしまわないよう、ルールを記録頻度に合わせる必要があります。 ベストプラクティス: 環境を影響度のレベルで分類し、開発者により近いコントロールを検討したうえで、そのギャップを埋めるために AWS Config の活用を検討してください。 まとめ この記事で紹介したガイダンスとベストプラクティスは、固有の運用ニーズに応じた AWS Config の記録頻度について、十分な情報に基づいた意思決定を行うのに役立ちます。3 つの重要な要素を主要なユースケースと併せて理解し、それらを固有の環境特性に適用することで、組織がクラウド運用を成功させるために必要となる設定の可視性を維持しながら、運用の効果を最適化できます。 この記事では、リソースの静的性、サービス間の関係、ベースラインの変更頻度、および主要なユースケースが CI の生成にどう影響するかを探りました。実践的な例と分析を通じて、これらの要素を体系的に評価するための意思決定のフレームワークとベストプラクティスを紹介しました。 組織にとっての意思決定に役立つベストプラクティスは以下のとおりです。 現在の CI のパターンを分析する リソースの関係に関する戦略を特定し、既存の関係と比較する 記録頻度をニーズに合わせる ルールの評価を記録頻度に合わせる 環境固有の要件を実装する アカウントと環境の分離を検討する 定期的記録を有効にする手順の詳細については、「 AWS Config の定期的な記録を使用した設定項目の検出 」を参照してください。 著者について Jake Izumi Jake Izumi は AWS で NAMER の ISV のお客様を担当するシニアソリューションアーキテクトです。企業の成長戦略を支援してきた経験を活かし、ビジネスリーダーやテクノロジーリーダーが AWS 上でイノベーションを実現し、ビジネスを成長させられるよう支援しています。 LinkedIn で Jake とつながりましょう。 Matej Macek Matej Macek はシニアソリューションアーキテクトとして、世界中のさまざまな業界におけるクラウド運用の課題解決に情熱を注いでいます。効率化を推進するオーダーメイドのソリューションを設計し、組織がプロセスを合理化し、絶えず変化するデジタル環境で優位性を保てるよう支援しています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

Kiro を組織全体に展開すると、利用状況とコストを定期的に、複数の AWS アカウントにまたがって確認する必要が出てきます。確認したいときにすぐに確認できる状態にしておけると、運用の負担が減ります。 本記事では Part 2 として、Kiro の利用状況とコストを可視化する 2 つのダッシュボードを紹介します。1 つは AWS 全体のコストを見るための CUDOS Dashboard に含まれる Kiro のセクション、もう 1 つは Kiro 専用に作られた Kiro User Activity Dashboard です。どちらも Cloud Intelligence Dashboards (CID) &nbsp;の一部として提供されており、 Amazon Quick Sight 上で動作します。 なお、別記事となる Part 1 では、Kiro の利用状況とコストの情報がどこに記録され、どう取り出せるのかを整理しています。 注：本記事は CUDOS Dashboard 5.8.0 以降 と Kiro User Activity Dashboard v1.1.1 以降 を前提に記述しています。ダッシュボードは更新されるため、最新の情報はそれぞれの CHANGELOG ( CUDOS , Kiro User Activity Dashboard ) をご確認ください。また、Part 1 と同様に、 Kiro の ID プロバイダー として AWS IAM Identity Center を使う構成を前提としています。 1. Part 1 の振り返り Part 1 &nbsp;の要点は以下の 4 つです。 Kiro の利用状況とコストの情報源は 2 つあります。 Kiro User Activity Report はユーザーごとの利用実態を、 AWS Cost and Usage Reports (CUR) 2.0 は請求の観点からサブスクリプションごとの月額料金と超過料金を記録します。 Kiro User Activity Report は日次で出力され、メッセージ数やモデル別の内訳を確認できます。 CUR 2.0 を Amazon Athena で分析すれば、ヘビーユーザーの特定、クレジット超過の発見、課金されているのに使われていないサブスクリプションの洗い出しができます。 Kiro 使用状況ダッシュボード を使うと、何もデプロイせずに概況を確認できます。ただし、ユーザー単位の内訳やモデル別の内訳は見えません。 CUR 2.0 と Kiro User Activity Report はユーザー単位までの分析を行うことができますが、CUR 2.0 については Athena でのクエリ実行、Kiro User Activity Report については出力されたファイルの集約をその都度行う必要があります。 この点を解消する方法として、ここでは 2 つのダッシュボードを紹介します。 2. CUDOS Dashboard CUDOS Dashboard (以下、CUDOS) は、CUR をもとにコストと使用状況を多面的に可視化する、CID の中核となるダッシュボードです。既に導入されている組織も少なくないかと思います。 CUDOS 5.8.0 以降であれば、AI/ML タブ内に Kiro のセクションが含まれています。つまり、追加のデプロイは不要で、タブを開くだけで Kiro の状況を確認できます。 注：CUDOS は デモ環境 で実際に操作してみることもできます。AI/ML タブを開いて下方にスクロールすると Kiro のセクションがあります。 図 1: CUDOS Dashboard の AI/ML タブ (Kiro セクション) CUDOS では Kiro について以下のようなビジュアルが用意されており、大きく 3 つの観点で状況を確認できます。 コストはどのように推移しているか アカウントやリージョンなどの要素ごとのコストの推移 ( Kiro and Amazon Q Developer Spend per &lt;要素&gt; ) サブスクリプション数およびコストの推移 ( Kiro and Amazon Q Developer Daily Subscriptions Count and Spend ) アクティブユーザー数の推移 ( Kiro Daily Active Users ) 誰がどれだけ使っているか ユーザーごとのクレジット消費の推移 ( Kiro Daily Credits Usage per User ) ユーザーごとのサブスクリプションの明細 ( Kiro and Amazon Q Developer per User Subscriptions Details )　… プラン、発生している料金、および使用量 使われていないサブスクリプションはあるか Kiro を使えるサブスクリプション (ユーザー) の数 ( Total Kiro Subscriptions ) と、その内訳 ( Total Active Kiro Users / Total Inactive Kiro Users ) クレジットを消費していないユーザー ( Kiro Users with No Credits Usage ) とその総サブスクリプションコスト ( Total Cost for Inactive Kiro Users ) Part 1 では Athena で SQL クエリを発行して取得していた情報が、CUDOS ではそれを行わずに確認することができます。アカウントや期間はコントロールで絞り込むことができます。 CUDOS は CUR だけを情報源とするため、Kiro User Activity Report を有効にしていなくても使えます。また、他のサービスと同じダッシュボードで Kiro のコストを見られるので、毎月のコストの確認の中で Kiro の状況を併せて把握する、といった使い方に向いています。 3. Kiro User Activity Dashboard Kiro User Activity Dashboard は、CID のダッシュボード群に新たに追加された Kiro 専用のダッシュボードです。CUDOS が CUR のみを情報源とするのに対し、こちらは Kiro User Activity Report と CUR 2.0 の両方を情報源 としています。 それにより、Kiro User Activity Dashboard では、何か月使われていないかやモデル別の内訳など、CUDOS では見ることのできなかった情報も確認することができます。 注：Kiro User Activity Dashboard も デモ環境 で操作してみることができます。 Kiro User Activity Dashboard は 5 つのタブから構成されています。 タブ 内容 Executive Summary 全体像 (サブスクリプション数、メッセージ数、クレジット消費と超過) User Engagement ユーザーごとの利用実態、メッセージ数、アクティブユーザー数の推移 Credit &amp; Overage Tracking クレジット消費と超過の追跡、プランの過不足の判定 Model &amp; Client Breakdown モデル別とクライアント別の内訳 About 免責事項とバージョン番号 このうち、Executive Summary タブでは、以下のような全体像を把握することができます。 総サブスクリプション数 ( Total Kiro Subscriptions ) 使われているサブスクリプションの数 ( Active Kiro Licences ) 使われていないサブスクリプションの数 ( Idle Kiro Licences ) 利用量 ( Total Messages , Credits Used ) 超過クレジット量 ( Overage Credits ) クライアントタイプ (KIRO_CLI、KIRO_IDE 等) ごとの利用状況 ( Active Users by Client Type , Daily Active Users by Client Type ) プラン (PRO, PRO_PLUS 等) ごとの利用状況 ( Credits by Subscription Tier ) モデル (Auto, Claude Sonnet 5 等) ごとの利用状況 ( Messages by Model ) 注：Kiro User Activity Dashboard の v1.1.0 以降では、課金されているサブスクリプションを「ライセンス (Licence)」という単位で呼んでいます。サブスクリプションは AWS アカウントごとに数えるため、同じユーザーが 2 つのアカウントでサブスクライブされていれば 2 ライセンスとカウントされます。 図 2: Kiro User Activity Dashboard の Executive Summary タブ ここで使われていないサブスクリプション (ライセンス) が多いと分かれば、「 どのサブスクリプションでどのくらい無駄になっているか 」を User Engagement タブで確認します (→ 3.1.)。クレジットの超過が発生していると分かれば、「 誰が超過しているのか、適切なプランにサブスクライブしているのか 」を Credit &amp; Overage Tracking タブで確認します (→ 3.2.)。 また、「 なぜクレジットを多く消費しているのか 」は User Engagement タブで確認できます (→ 3.3.)。 3.1. 使われていないサブスクリプションを見つける User Engagement タブには、 Idle Kiro Licences という「 課金されているのに使われていないサブスクリプション 」の一覧が含まれています。 図 3: Kiro User Activity Dashboard の User Engagement タブの Idle Kiro Licences ビジュアル この一覧には、以下のカラムが含まれています。 アカウント ( Account ) ユーザー ( User )　… Kiro User Activity Report に一度も記録がないサブスクリプションは、メールアドレスではなく IAM Identity Center のユーザー ID で表示されます サブスクリプションプラン ( Subscription Type ) そのユーザーで最初に課金が発生した日 ( Licence Since ) 最後にクレジットが消費された日 ( Last Activity (all-time) )　… 空欄の場合は一度もクレジットが消費されていないことを意味します 使われなくなる前に、どれだけの期間使われていたか ( Months Active ) 使われていない月数 (暦月) ( Months Idle ) 1 か月あたりの料金 ( Monthly Fee ) 使われていない期間に発生した料金 ( Inactivity Cost )　… Months Idle × Monthly Fee に相当 ここで「使われていない」と判定されるのは、「 Billing period (ダッシュボード上部のコントロール欄で設定) で選んだ期間に課金されていて、かつクレジットの消費がなかったサブスクリプション 」です。課金されていてクレジット消費があれば Active 、課金されているのにクレジット消費がなければ Idle と判定されます (注)。 注：「サブスクライブされたが、まだ有効化されていない」状態 ( Part 1 で述べた Pending の状態) のサブスクリプションは課金されないため、Kiro User Activity Dashboard のサブスクリプションの数には含まれず、Active にも Idle にも数えられません。 図 3 の例では、Pro / ProPlus のサブスクリプションがいずれも 1 か月使われておらず、 Inactivity Cost としてそれぞれ $20&nbsp;と&nbsp;$40 が計上されています。上位のプランを放置した場合の金額が大きくなることが分かります。 こうして見つかったサブスクリプションは、 対象のユーザーにヒアリングした上で解約の候補 になります。 3.2. 現在のプランが適切かを確認する Credit &amp; Overage Tracking タブでは、 プランのクレジット枠に対する利用状況 を確認することができます。 図 4: Kiro User Activity Dashboard の Credit &amp; Overage Tracking タブ 画面の上部には、以下の 4 つの指標が並びます。 枠の 75% 以上を使っているユーザーの数 ( Users at Risk (≥75% plan) )　… 超過の予兆 枠を超えたユーザーの数 ( Users in Overage ) 枠の 25% も使っていないユーザーの数 ( Users Below 25% of Plan )　… プランが過剰な可能性 超過分の料金 ( Overage Cost ) Credit &amp; Overage Tracking タブの下方にある&nbsp; Monthly Credits and Overage by User ビジュアルでは、ユーザーごとの明細を月単位で確認することができます。プラン ( Subscription Tier ) とクレジット枠 ( Plan Credits )、消費したクレジット ( Credits Used )、枠に対する利用率 ( Plan Utilization % )、枠から超過したクレジット ( Overage Credits ) が並び、加えて Tier Recommendation というカラムに次に取るべき行動が示されます。 消費クレジットが枠を超過しているので上位プランへアップグレードすべき ( Upgrade Candidate ) 枠に対してクレジットの利用率が低いので下位のプランへダウングレードすべき ( Downgrade Candidate ) 現在のプランで適切 ( Right-Sized ) 消費クレジットが枠を超過しているものの、既に最上位のプラン (＝Kiro Power) であるため、超過を許容するかの判断になる ( Review Overage Settings ) 注：ダッシュボードが認識できないプラン (例：新規に追加されたプラン) の場合は Unknown Tier と表示されます。 ただし、 Users Below 25% of Plan に該当するユーザーについては、 すぐにプランを下げるのではなく、対象のユーザーやそのマネージャーと相談した上で適切なプランを判断するべき でしょう。利用が少ない理由は、数字からだけでは必ずしも分からないためです。 なお、超過を許容するかを判断する際は、その超過が何によって生じているのかも手掛かりになります (→ 3.3.)。 3.3. クレジットを多く消費している原因を調べる 3.2. で超過しているユーザーや超過しそうなユーザーが見つかった場合は、User Engagement タブでその詳細な原因を確認することができます。 図 5: Kiro User Activity Dashboard の User Engagement タブ User Engagement タブには、3.1. で紹介した Idle Kiro Licences 以外に、ユーザーごとの利用状況を示す以下のビジュアルが含まれています。 ユーザーごとのメッセージ数をモデル別に示したもの ( Top 50 Users by Message Count (by Model) ) 日ごとのメッセージ数をユーザー別に示したもの ( Users by Message Count ) ユーザーごとの月単位の明細 ( User Summary ) メッセージ数 ( Total Messages ) やクレジット消費量 ( Credits Used )、1 メッセージあたりのクレジット消費 ( Credits per Message ) など クレジットを多く消費しているユーザーがいる場合、その理由として「単純に利用量が多い」「 クレジット消費の多いモデルを使っている 」などが考えられます。まずは対象のユーザーの Credits per Message を確認し、それが他のユーザーと同程度であれば Total Messages そのもの、つまり利用量が多いことが原因であると言えるため、3.2. のようにプランの見直しを検討することになります。 一方、 Credits per Message が他のユーザーよりも高いようであれば、ダッシュボード上部のコントロール欄の User で対象のユーザーに絞り込んだ上で、 Top 50 Users by Message Count (by Model) でモデルごとのメッセージ内訳を確認します。利用が消費の多いモデルに偏っていれば、モデルの選び方が原因である可能性があるため、対象のユーザーと相談した上で、作業の内容に応じたモデルの使い分けを検討します。偏っていなければ、クレジット消費の大きい複雑な作業が多いと考えられるため、この場合もプランの見直しを検討することになります。 4. 2 つのダッシュボードの違い 2 つのダッシュボードは、主に何を指標にしているかが異なります。CUDOS は CUR をもとに、Kiro のコスト (金額) の推移や内訳を示します。一方、Kiro User Activity Dashboard は Kiro User Activity Report 以外に CUR (CUR 2.0) も情報源としているものの、一部のビジュアルを除いてコストは扱っておらず、サブスクリプションの数やクレジットの量を指標にしています。Kiro User Activity Dashboard で金額が表示されるのは、使われていないサブスクリプションの料金 ( Idle Kiro Licences ) と、超過料金の合計 ( Overage Cost ) だけです。 確認したいこと CUDOS Dashboard Kiro User Activity Dashboard Kiro のコストの推移や内訳 ○ 確認可能 (アカウントやリージョンなどの軸で確認可能) × 確認不可 (クレジットの量の推移は確認可能) 使われていないサブスクリプションと、それによって発生しているコスト ○ 確認可能 (クレジットを消費していないユーザーと、そのサブスクリプションコストの合計) ○&nbsp;確認可能 (CUDOS でできることに加え、使われていない月数と、その間に発生した料金も確認可能) プランが利用実態に見合っているか △ 一部確認可能 (ユーザーごとのクレジット消費量は分かるが、プラン枠との比較は自分で行う必要あり) ○&nbsp;確認可能 (プランごとのクレジット枠に対する利用率と、プラン変更の推奨の有無まで確認可能) 超過が過度に起きていないか ○&nbsp;確認可能 (ユーザーごとの明細で、超過分の料金を確認可能) ○&nbsp;確認可能 (超過クレジット量、超過の予兆、超過料金の合計を確認可能) クレジットを多く消費している原因 × 確認不可 ○&nbsp;確認可能 (メッセージ数、1 メッセージあたりのクレジット消費、モデル別の内訳を確認可能) コストの推移や内訳を見たい場合は、CUDOS が向いています 。使われていないサブスクリプションがないか、プランが適切か、超過が過度に起きていないかを、 ユーザー単位で掘り下げて確認したい場合は、Kiro User Activity Dashboard が向いています 。CUDOS を既に導入済みであれば、まずは 5.8.0 以降に更新して AI/ML タブで状況を確認し、より詳しく見たくなった段階で Kiro User Activity Dashboard を追加する、という順で検討するとよいでしょう。 5. ダッシュボードのデプロイ どちらのダッシュボードも Cloud Intelligence Dashboards の仕組みでデプロイします。詳しい手順は公式ドキュメントを参照してください。ここではそれぞれの手順の参照先と、デプロイにあたって注意しておきたい点を紹介します。 ダッシュボードを動かすには、Amazon Quick Sight のユーザー料金と SPICE の容量、Amazon Athena のクエリ、CUR やレポートを保存する Amazon S3 などの料金がかかります。費用の目安は、前提条件と共に CID の FAQ に記載されています。Kiro User Activity Dashboard では、これに加えてレポートを収集する仕組み (AWS Lambda など) の料金がかかります。 5.1. CUDOS Dashboard 新規にデプロイする場合は「 Deployment in Global Regions 」を参照してください。 既にご利用中の場合は「 Update Dashboards 」でダッシュボードの更新を行ってください。なお、 AI/ML タブで Kiro を見るには CUDOS の 5.8.0 以降が必要です 。5.8.0 への更新ではデータセットが移行されるため、データセットをカスタマイズしている場合には事前に CHANGELOG の 5.8.0 の項に記載の注意点 を確認してください。 5.2. Kiro User Activity Dashboard 新規・更新のいずれも「 Kiro User Activity Dashboard 」に手順があります。 Kiro User Activity Dashboard のデプロイの前に、以下を実施しておく必要があります。 CID の Foundational ダッシュボード (CUDOS Dashboard、Cost Intelligence Dashboard、KPI Dashboard) のいずれかと、CUR 2.0 のデータエクスポート Foundational ダッシュボードを新規にデプロイする場合は、CUR 2.0 のデータエクスポートも一緒に設定されます 既に Foundational ダッシュボードを導入済みで、情報源として CUR 2.0 を使っている場合は、追加の作業は不要です 既に Foundational ダッシュボードを導入済みで、情報源として Legacy CUR (CUR 1.0) を使っている場合は、別途 CUR 2.0 のデータエクスポートが必要です (CUDOS は CUR 1.0 にも対応していますが、Kiro User Activity Dashboard で対応しているのは CUR 2.0 のみです) この場合の CUR 2.0 のデータエクスポートは、AWS Billing and Cost Management コンソールで作成するのではなく、CID の Data Exports の手順で作成してください。CID が対応しているのは、この手順で作成した CUR 2.0 のデータエクスポートのみです (データエクスポートの作成に加えて、Athena テーブルの作成なども行われます) Kiro User Activity Report の有効化 と S3 バケットへの CSV 形式でのレポート出力設定 出力先の S3 バケットが SSE-KMS で暗号化されている場合、Kiro User Activity Dashboard がレポートを読み取れないのでご注意ください S3 バケットのプレフィックスには「 kiro/ 」を指定してください なお、Kiro User Activity Report は、ユーザーがサブスクライブされている AWS アカウントごとに出力され、別のアカウントのバケットには出力できません。 部署ごとに別のアカウントで Kiro を導入している場合 は、それぞれのアカウントでレポートを有効化した上で、 ドキュメントの手順 の Step 1 の中でそれらのバケットをすべて読み取り元として指定する必要があります。 6. まとめ Part 2 では、Kiro の利用状況とコストを継続的に可視化する 2 つのダッシュボードを紹介しました。 CUDOS Dashboard (5.8.0 以降) は、AI/ML タブ内で Kiro の状況を確認できます。CUR だけを情報源とするので、Kiro User Activity Report がなくても使え、毎月のコスト確認の中で、Kiro のコストの推移や内訳を併せて把握するのに向いています。 Kiro User Activity Dashboard は、Kiro User Activity Report と CUR 2.0 の両方を情報源とする Kiro 専用のダッシュボードです。使われていないサブスクリプションにいくら払い続けているか、現在のプランが適切か、クレジットを多く消費している原因は何かを、ユーザー単位で掘り下げられます。 Part 1 と Part 2 で紹介した方法を使えば、 誰がどれだけ Kiro を使い、どこにコストが発生しているのかを、ユーザー単位で把握できます 。大切なのは、見えるようにした上で「 使われていないサブスクリプションを解約する 」「 プランが見合っていないユーザーのプランを変える 」「 利用が消費の多いモデルに偏っているならモデルの使い分けを検討する 」などの手を打つことです。Kiro を組織全体に広げていく段階では、こうした見直しを定期的に回せる状態を作っておくと、コストの見通しが立てやすくなります。 著者について 堀沢 伸吾 (Shingo Horisawa) アマゾン ウェブ サービス ジャパン合同会社のテクニカルアカウントマネージャーとして、ISV のお客様を中心に、AWS を効率的・効果的にご利用いただくための運用やコスト効率化をご支援しています。休日は趣味のロードバイクで主に東京郊外を走ったり、ロングライドをしたりしています。

組織で Kiro を導入すると、誰がどれだけ使い、そのコストがどこで発生しているのかを継続的に把握する必要が出てきます。 Part 1 の本記事では、Kiro の利用状況とコストを確認することのできる情報源として Kiro User Activity Report と AWS Cost and Usage Reports (CUR) 2.0 を取り上げ、その概要を紹介します。また、CUR 2.0 を Amazon Athena で分析する方法と、Kiro が標準で備えている Kiro 使用状況ダッシュボード についても紹介します。 なお、別記事となる Part 2 では、これらの情報を継続的に可視化する 2 つのダッシュボードについて紹介します。 注：本記事に記載の料金およびクレジット枠は 2026 年 10 月時点のものです。最新の情報は Kiro の料金ページ をご確認ください。 1. 背景：「誰が、どれだけ使っているのか」が見えない Kiro を数人で試している段階なら、コストの内訳はそれほど問題にはなりません。ところが組織全体へ展開し、数十人・数百人が日々 Kiro を使うようになると、話が変わってきます。 Kiro の利用量は「 クレジット 」という単位で測られます。 各プラン には月あたりのクレジット枠が含まれており、その枠内であればプランの月額料金だけで利用できます。枠を超えた分は「 超過 (overage) 」となり、デフォルトでは月内はそれ以上使えなくなります。Kiro の設定で超過を許可すると、クレジット単位の追加料金を払って使い続けられます。 つまり、組織で Kiro を運用する管理者は、「 誰がどれだけクレジットを使い、追加料金が膨らんでいないか、プランが見合っているか 」を継続的に見ていく必要があります。その際、多くの管理者が、以下のような困りごとに直面します。 多くのメンバーに Kiro サブスクリプションを割り当てたものの、 実際に誰がどれだけ使っているのか を把握できない 請求額が想定を超えているものの、 クレジットの超過がどのユーザーで起きているのか を特定できず、プランの見直しが必要かどうかも判断できない 契約したのにほとんど使っていない ユーザーがいるはずだが、特定できずコストが無駄になっている可能性がある 裏を返せば、 ユーザー単位で利用状況とコストが見えるようになれば 、これらの問題は解消します。 2. Kiro の利用状況とコストを記録する 2 つの情報源 Kiro の利用状況とコストは、2 つの異なる情報源に記録されます。それぞれで見ている対象が異なるため、両方を知っておくことで使い分けが可能になります。 Kiro User Activity Report ：Kiro が出力する日次のレポート。 ユーザーごとの利用実態 を記録します。 AWS Cost and Usage Reports (CUR) 2.0 ：AWS の請求・使用状況データ。 請求の観点 から Kiro のサブスクリプションごとの月額料金と超過料金を記録します。 まず、Kiro が何を単位として利用を記録するのかを押さえておきます。 2.1. 識別の単位：ID プロバイダーとサブスクリプション Kiro の利用状況は、組織の ID プロバイダーで管理されるユーザー単位で識別されます。Kiro は AWS IAM Identity Center 経由、および Okta / Microsoft Entra ID の直接接続 のどちらにも対応しています (注)。組織で Kiro を導入する場合、管理者が ID プロバイダー上のメンバー (またはグループ) を Kiro にサブスクライブし、プランを割り当てます。こうしてサブスクライブされたユーザーを Kiro enterprise user と呼びます。 注：本記事では、 Kiro の ID プロバイダー として IAM Identity Center を使う構成を前提としています。 一方、 請求の側ではサブスクリプションを AWS アカウントごとに数えます 。Kiro の管理単位である「プロファイル」は「 AWS アカウント × リージョン 」ごとに作成されるため、 サブスクライブを管理アカウントだけで行うとは限りません (“ Deployment options ” を参照)。 例えば部署ごとに別のアカウントで Kiro を導入している場合、 異動や兼務で同じ IAM Identity Center ユーザーが 2 つのアカウントでサブスクライブされ、二重に課金される ことがあります。この場合、ユーザーとしては 1 人でも、サブスクリプションとしては 2 件になります。そして実際に使っているのが片方だけなら、もう片方は無駄なコストになります。 2.2. Kiro User Activity Report：ユーザー単位の利用実態 Kiro User Activity Report は、ユーザーごとの利用実態を日次で記録したレポートです。Kiro の設定で有効化します。 出力形式は CSV ファイルを Amazon S3 バケットに出力 する方法と OpenTelemetry で送る 方法の 2 つがあります。内容は同じで、どちらか一方を有効にすることも、両方有効にすることもできます。本記事では CSV を前提に説明します。 主な内容は以下の通りです (カッコ内は実際のカラム名)： ユーザーの識別情報 ( UserId , User_Email ) ユーザーに割り当てられたプラン ( Subscription_Tier ) クライアントタイプ ( Client_Type )　… Kiro IDE、Kiro CLI、IDE プラグインなど、どこから使ったか クレジットの消費と超過 ( Credits_Used , Overage_Credits_Used , Overage_Cap )　… 消費したクレジット、プランの枠を超えて消費したクレジット、超過できるクレジットの上限値 メッセージや対話の数 ( Total_Messages , Chat_Conversations ) モデル別の内訳 　… 使ったモデルごとのメッセージ数 ( auto_messages , claude_opus_4.5_messages など、利用したモデルに応じたカラム) CSV ファイルは「 KIRO_CLI_&lt;accountId&gt;_user_report_202609030000.csv 」のように日付とクライアントタイプごとに分かれて出力されます。内容はおおよそ以下のようなイメージです (値はサンプル)： Date UserId Client_Type Total_Messages Credits_Used Overage_Credits_Used Subscription_Tier 2026-09-03 042874c8-xxxx-xxxx-xxxx-xxxxxxxxxxxx KIRO_CLI 44 8.29 0 PRO 2026-09-03 044884a8-xxxx-xxxx-xxxx-xxxxxxxxxxxx KIRO_CLI 77 34.84 0 PRO_PLUS ここで押さえておきたい Kiro User Activity Report の特性が 1 つあります。 このレポートには、実際に Kiro を使ったユーザーの行しか含まれません 。その日に Kiro を使わなかったユーザーの行は出力されず、サブスクライブしたまま一度も使っていないユーザーは、そもそもここには現れません。この点が、次に説明する CUR 2.0 との大きな違いのひとつになっています。 2.3. CUR 2.0：請求から見たサブスクリプションとコスト CUR 2.0 は、AWS アカウントごとのコストと使用状況を明細項目 (line item) レベルで記録したレポートです。 AWS Data Exports で設定することで S3 バケットに出力されます。 CUR 2.0 には、Kiro のサブスクリプションが請求の明細として記録されます。サブスクリプションは line_item_resource_id に IAM Identity Center ユーザーの ARN (例： arn:aws:identitystore:::user/&lt;uuid&gt; ) として現れます。 Kiro の明細は、 pricing_unit の値で 2 種類に分かれます (カラム名の詳細は CUR 2.0 のテーブルディクショナリ を参照してください)。 pricing_unit 使用タイプの例 何の明細か Count USE1-KiroEnterprise-Pro USE1-KiroEnterprise-ProPlus USE1-KiroEnterprise-ProMax USE1-KiroEnterprise-Power プランの月額料金 Credits USE1-KiroEnterprise-Credits クレジットの消費 どちらの明細も、 数量は line_item_usage_amount 、 金額は line_item_unblended_cost のそれぞれのカラムに記録されます。 なお、Kiro User Activity Report を有効化していなくても、「誰がどれだけクレジットを使ったか」は CUR 2.0 だけでも把握することができます。利用がプランの枠内に収まっている場合は追加料金が発生しないため line_item_unblended_cost は 0 になりますが、消費した量そのものは line_item_usage_amount に記録されるためです。 Credits の明細は、 単価の異なる 2 種類 に分類されます。 line_item_line_item_description カラムには、プランの枠内で消費した分は $0.00 per Credit for KiroEnterprise-Credits in US East (N. Virginia) 、枠を超えた分は $0.04 per Credit for KiroEnterprise-Credits in US East (N. Virginia) のように記録されます (3.1. のクエリ結果を参照)。どちらも同じ使用タイプなので、 line_item_usage_amount を合計すると 消費したクレジットの総量 、 line_item_unblended_cost を合計すると 超過料金 になります。 そしてプランの月額料金は、クレジットを 消費していない月でも記録されます 。サブスクライブしている限り料金は発生するためです。この 2 種類の明細を組み合わせると、次の判定が可能です。 プランの月額料金 ( Count ) の明細があり、クレジット ( Credits ) の明細もある 　→ そのサブスクリプションはその月に使われている プランの月額料金 ( Count ) の明細はあるが、クレジット ( Credits ) の明細がない (または消費量が 0) 　→ 課金されているのに使われていない 後者が、サブスクリプションの見直しの対象になります (注)。 注：ここでいう「使われていない」は、Kiro コンソールに表示されるサブスクリプションの ステータス ( Active / Pending / Canceled ) とは別の観点です。 Pending は「サブスクライブされたが、まだ有効化されていない」状態を指し、課金は発生しません。ここで問題にしているのは「 課金が発生している ( Active ) のに、その期間は使われていない 」サブスクリプションです。 2.4. 2 つの情報源の違い Kiro User Activity Report と CUR 2.0 を整理すると、次のようになります。 &nbsp; Kiro User Activity Report CUR 2.0 数える単位 ID プロバイダーのユーザー アカウントごとのサブスクリプション クレジット消費量 取れる 取れる プラン料金・超過料金の金額 取れない (注) 取れる 使われていないサブスクリプションの把握 取れない 取れる メッセージ数 取れる 取れない モデル別・クライアントタイプ別 取れる 取れない 現れる対象 使ったユーザーのみ 課金対象のサブスクリプションすべて 注：プランと超過クレジット数から金額を推定することは原理的に可能ですが、 価格表 が必要で、また月途中の加入による日割りや未使用のサブスクリプションには対応できません。そのため、金額は CUR 2.0 から取るのが確実です。 また、両者は 母集団が異なります 。前者は「使ったユーザー」、後者は「課金対象のサブスクリプション」を数えているため、 数が一致しないことがあります 。どちらかが間違っているのではなく、見ているものが違うということです。 なお、Builder ID による個人利用は AWS アカウントに課金されないため、どちらの情報源にも現れません (認証方式ごとの支払い方法の違いは こちらのブログ が詳しく解説しています)。 3. CUR 2.0 を Athena で分析する 2 つの情報源のうち、 CUR 2.0 は Amazon Athena に接続していれば すぐに SQL で分析できます 。既に CUR 2.0 が有効になっている組織では追加の準備なしに始められることが多いはずです。 以下のクエリでは、 &lt;your_cur_table_name&gt; を実際の CUR 2.0 テーブル名 (例： cid_data_export.cur2 ) に置き換えてください。 billing_period は対象の請求月です。 注：対象期間は暦月単位で指定してください。 クレジット枠は請求月の開始時にリセットされ、繰り越されません 。プランの月額料金も暦月単位で計上されるため、「9 月 20 日まで」のように月の途中で切ると、料金の明細がまだ計上されていないサブスクリプションが漏れて数や金額が実際より少なく出ます。また CUR のデータは 請求が確定するまで更新が続く ので、分析は完了した月を対象にするのが確実です。 3.1. プラン料金とクレジット消費の全体像 まず Kiro の明細がどう構成されているかを確認します。 SELECT line_item_usage_type, pricing_unit, line_item_line_item_description AS description, SUM(line_item_usage_amount) AS usage_amount, SUM(line_item_unblended_cost) AS cost FROM &lt;your_cur_table_name&gt; WHERE billing_period = '2026-09' AND line_item_product_code = 'Kiro' GROUP BY 1, 2, 3 ORDER BY 1; 出力例 line_item_usage_type pricing_unit description usage_amount cost USE1-KiroEnterprise-Credits Credits $0.00 per Credit for … 1100.83 0.00 USE1-KiroEnterprise-Credits Credits $0.04 per Credit for … 11.75 0.47 USE1-KiroEnterprise-Pro Count Kiro Enterprise Pro plan 3.00 60.00 USE1-KiroEnterprise-ProMax Count Kiro Enterprise Pro Max plan 1.00 100.00 USE1-KiroEnterprise-ProPlus Count Kiro Enterprise Pro+ plan 1.00 40.00 Count の行にプランごとの月額料金が、 Credits の行にクレジットの消費が現れます。後者は cost が 0 でも usage_amount に消費量が記録されていることが確認できます。この例では超過が発生しているため、 Credits の行は description が $0.00 per Credit for ... の行と $0.04 per Credit for ... の行の 2 つに分かれています。 3.2. サブスクリプションごとのクレジット消費量と料金 次に、サブスクリプション単位で「いくら払って、どれだけ使ったか」を確認します。 SELECT line_item_usage_account_id AS account_id, line_item_resource_id AS subscription, MAX(CASE WHEN pricing_unit &lt;&gt; 'Credits' THEN line_item_usage_type END) AS plan, SUM(CASE WHEN pricing_unit &lt;&gt; 'Credits' THEN line_item_unblended_cost ELSE 0 END) AS plan_fee, SUM(CASE WHEN pricing_unit = 'Credits' THEN line_item_unblended_cost ELSE 0 END) AS overage_fee, SUM(CASE WHEN pricing_unit = 'Credits' THEN line_item_usage_amount ELSE 0 END) AS credits_used FROM &lt;your_cur_table_name&gt; WHERE billing_period = '2026-09' AND line_item_product_code = 'Kiro' AND line_item_resource_id &lt;&gt; '' GROUP BY 1, 2 ORDER BY credits_used DESC; 出力例 account_id subscription plan plan_fee overage_fee credits_used 111122223333 arn:aws:identitystore:::user/5e6f7a8b-… USE1-KiroEnterprise-Pro 20.00 0.47 1011.75 111122223333 arn:aws:identitystore:::user/1a2b3c4d-… USE1-KiroEnterprise-ProMax 100.00 0.00 57.70 111122223333 arn:aws:identitystore:::user/2b3c4d5e-… USE1-KiroEnterprise-ProPlus 40.00 0.00 34.84 111122223333 arn:aws:identitystore:::user/3c4d5e6f-… USE1-KiroEnterprise-Pro 20.00 0.00 8.29 111122223333 arn:aws:identitystore:::user/4d5e6f7a-… USE1-KiroEnterprise-Pro 20.00 0.00 0.00 クレジット消費量の多い順に並ぶので、 ヘビーユーザーの特定 ができます。冒頭に挙げた 1 つめの困りごと (利用状況の把握) への答えです。 overage_fee に金額が入っているサブスクリプションは、 プランの枠を超えて使っています 。この例では 1 行目の Pro プランのユーザーが 1,011.75 クレジットを消費し、枠の 1,000 を超えた 11.75 クレジット分の $0.47 が超過料金として発生しています。冒頭の 2 つめの困りごと (利用超過ユーザーの把握) への答えです。 credits_used を プランに含まれるクレジット数 と比べれば、 プランが利用実態に見合っているか も判断できます。枠のごく一部しか使っていないなら下位プラン、超過が続いているなら上位プランの検討材料になります。例えば Pro ($20 / 1,000 クレジット) と Pro+ ($40 / 2,000 クレジット) の差額 $20 は、超過 500 クレジット分に相当します。毎月それ以上超過しているならば、プランを上げた方が安くなります。 plan は使用タイプをそのまま表示しています。 plan_fee からも推測できますが、料金は変わり得るため明示しておくと確実です。なお、月の途中でプランを変更した場合は、その月に 2 つの使用タイプが現れます。 3.3. 課金されているが使われていないサブスクリプションを見つける 冒頭の 3 つめの困りごと (無駄なコストの把握) に答えるクエリです。 SELECT line_item_usage_account_id AS account_id, line_item_resource_id AS subscription, SUM(CASE WHEN pricing_unit &lt;&gt; 'Credits' THEN line_item_unblended_cost ELSE 0 END) AS wasted_fee FROM &lt;your_cur_table_name&gt; WHERE billing_period = '2026-09' AND line_item_product_code = 'Kiro' AND line_item_resource_id &lt;&gt; '' GROUP BY 1, 2 HAVING SUM(CASE WHEN pricing_unit = 'Credits' THEN line_item_usage_amount ELSE 0 END) = 0 AND SUM(CASE WHEN pricing_unit &lt;&gt; 'Credits' THEN line_item_unblended_cost ELSE 0 END) &gt; 0 ORDER BY wasted_fee DESC; 出力例 account_id subscription wasted_fee 111122223333 arn:aws:identitystore:::user/4d5e6f7a-… 20.00 「 プラン料金は発生しているが、クレジットを 1 つも消費していない 」サブスクリプションが、金額の多い順に並びます。この例では Pro プランの 1 か月分がそのまま無駄になっています。これが見直しの候補です。 該当するものがなければクエリ結果は空になります。その月に課金されているすべてのユーザーが Kiro を使っていた、ということです。 3.4. Kiro User Activity Report を Athena で分析する場合 もう 1 つの情報源である Kiro User Activity Report も、CUR 2.0 と 同じように Athena で分析できます 。S3 に出力されたファイルを AWS Glue でテーブル化すれば、CUR 2.0 では取れない ユーザーごとのメッセージ数、モデル別やクライアントタイプ別の内訳 を SQL で集計できます。 ただし、 すぐに SQL を実行できる状態になるわけではありません 。CUR 2.0 は Athena 連携用の AWS CloudFormation テンプレート が用意されていますが、Kiro User Activity Report にはそうした仕組みが (2026 年 10 月時点では) 提供されておらず、日々出力されるファイルの収集とテーブル定義を自分で用意することになります。 Part 2 では、この部分も含めて可視化する方法を紹介しています。 4. Kiro 使用状況ダッシュボード：追加のデプロイなしで見る ここまでは情報源とその取り出し方を見てきました。一方、 何もデプロイせずに概況を見る手段 もあります。Kiro コンソールに組み込まれた Kiro 使用状況ダッシュボード です。 Kiro の設定で「Kiro 使用状況ダッシュボード」を有効化すると、Kiro コンソールから以下の 情報 を確認できます。 サブスクリプション数 ：保留中 / アクティブ / 合計 (それぞれプラン別の内訳も確認可能) 消費されたクレジット ：クライアントタイプ別とプラン別の推移 アクティブユーザー数 ：クライアントタイプ別とプラン別の推移 グラフは日次・週次・月次を切り替えられます。また、画面上部にはプロファイル名や IAM Identity Center のリージョンといった設定に加えて、 クレジット超過が有効になっているかどうか も表示されます。 図 1: Kiro 使用状況ダッシュボード メトリクスは概ね 1 時間ごとに更新 されます (アクティブユーザーのウィジェットのみ日次)。 鮮度という点では Kiro User Activity Report や CUR 2.0 よりも高い と言えます。 一方で、 誰がどれだけ使ったかというユーザー単位の内訳や、モデル別の利用状況は表示されません 。また、表示されるのは基本的に現在サインインしている AWS アカウントの情報です。例外は管理アカウントでサインインし、設定で「メンバーアカウントのサブスクリプション」を有効にしている場合で、このときはサブスクリプションの合計数にメンバーアカウントの分も含まれます。 このことから、まず 全体の傾向をつかむには、手軽に利用可能な Kiro 使用状況ダッシュボード が適していると言えます。一方、 ユーザー単位まで詳細な分析が必要な場合は Kiro User Activity Report や CUR 2.0 を使うことになります。 5. まとめ Part 1 では、Kiro の利用とコストがどこに記録され、どう取り出せるのかを見てきました。 Kiro の利用は ID プロバイダーのユーザー単位 で識別され、請求は AWS アカウントのサブスクリプション単位 で計上されます。 情報源は 2 つあります。 Kiro User Activity Report はユーザーごとの利用実態 (メッセージ数、モデル別、クライアントタイプ別) を、 CUR 2.0 は請求の観点からサブスクリプションごとの月額料金と超過料金を記録します。 クレジット消費量は両方から取得できます 。 CUR 2.0 を Athena で分析 すれば、ヘビーユーザーの特定や、課金されているのに使われていないサブスクリプションの洗い出しができます。 ただし、これらの 2 つの情報源はいずれも、そのままでは継続的に複数アカウントを横断して眺めたいという要求には応えられません。Kiro User Activity Report では CSV や OpenTelemetry の出力を確認する必要がありますし、CUR 2.0 では Athena でクエリを実行する必要があります。そこで Part 2 では、CUR 2.0 と Kiro User Activity Report をダッシュボードとして可視化するための 2 つの方法を紹介 します。 著者について 堀沢 伸吾 (Shingo Horisawa) アマゾン ウェブ サービス ジャパン合同会社のテクニカルアカウントマネージャーとして、ISV のお客様を中心に、AWS を効率的・効果的にご利用いただくための運用やコスト効率化をご支援しています。休日は趣味のロードバイクで主に東京郊外を走ったり、ロングライドをしたりしています。

本日、 Kiro IDE と CLI にメモリ機能を導入します。Kiro は、あなたが好む作業の進め方、リポジトリ固有のコマンドや規約、受けた訂正、デバッグで得た知見、すでに除外したアプローチを覚えておけるようになります。それらが再び関係する場面になると、Kiro はあなたのコンテキストを引き継ぎます。コンテキストを説明し直したり同じ訂正を繰り返したりする時間が減り、Kiro は言われなくてもあなたの好みに沿って動けるようになり、使い込むほど役に立つ存在になります。 (元記事では、Kiro CLI でメモリを操作するターミナルの録画を掲載しています。 元記事 でご覧ください。) 作業の途中で出てきたことを覚える ルールやプロジェクトドキュメント は、あらかじめ意図して書き出せるコンテキストを、Kiro に一貫して適用させたい場合に向いています。メモリは、作業を進めるうちに出てきて、放っておけば書き留められないままになりがちなコンテキストのためのものです。 たとえば、ある種のロジックをどこに置くべきかについて Kiro を訂正することがあるでしょう。デバッグ中に、ローカルのサービスを起動してからでないと統合テストが通らないと気づくこともあります。Kiro に変更をどう進めてほしいかという好みが固まることもあります。メモリを有効にすると、Kiro はこうした細かな点を、出てきたその場で記録します。 メモリは過去の会話を再生するのではなく、後の作業に役立つ具体的なコンテキストを保持します。理解が変われば、Kiro はメモリを更新して精度を上げられます。メモリはお使いのマシンのローカルに保存され、そのマシン上の Kiro IDE と CLI の間で共有されます。そのため、一方のクライアントで記録したコンテキストをもう一方でも使えます。各メモリはグローバルにも特定のリポジトリにも適用でき、Kiro は全般的な作業の好みと、特定のコードベースに属するコンテキストを区別できます。 Kiro が覚えている内容を確認し、管理する IDE では、Kiro がメモリにアクセス、作成、更新、削除したときにチャットに表示されるので、Kiro が覚えている内容をいつ使い、いつ変更しているかがわかります。アクティビティバーから Memories ビューを開くと、Kiro が覚えている内容を一覧・検索でき、各メモリの適用範囲を確認し、個々のエントリを詳しく見て、もう残しておきたくないものを削除できます。CLI では、呼び出されたメモリがチャットに Memory エントリとして表示され、 /memories で保存済みのメモリを検索、プレビュー、表示できます。 今回のリリースでは、メモリは既定でオフになっています。IDE と CLI のどちらでも、Kiro が既存のメモリを使えるかどうかと、メモリを作成・更新できるかどうかを設定できます。呼び出されたメモリは Kiro が使えるコンテキストの一部になるため、メモリを使うとコンテキストの使用量が増えることがあります。これらの設定によって、Kiro に何を引き継がせるか、そして作業を進めながら学習を続けさせるかどうかを決められます。 使い始める Kiro IDE では、アクティビティバーから Memories ビューを開いて設定を開き、 Use and learn を選びます。これで Kiro は既存のメモリを使い、作業に合わせてメモリを自動的に作成・更新するようになります。有効にした後は、いつもどおり Kiro と作業してください。Memories ビューにはいつでも戻って、Kiro が覚えている内容を確認したり、不要になったメモリを削除したり、メモリの動作を変更したりできます。 Kiro CLI では、メモリはローカルの V3 セッションで利用できます。 /memories と入力すると、保存済みのメモリを確認したり、アクセスを設定したりできます。 read &amp; write アクセスにすると、メモリの自動更新を有効にでき、Kiro が作業に合わせてメモリを作成・更新するようになります。メモリのアクセス設定の変更は、新しい CLI セッションから反映されます。 提供状況 メモリは Kiro IDE 1.4.0 以降と、Kiro CLI 2.29.0 以降のローカル V3 セッションで利用できます。メモリは既定でオフになっており、IDE と CLI のどちらからでも有効化と設定ができます。 同じ説明を繰り返す時間を減らし、作業を前に進めることに時間を使いましょう。次の Kiro セッションでメモリをオンにしてみてください。設定と管理の詳細は メモリのドキュメント をご覧ください。 この記事は Kiro ブログの Introducing memory in Kiro IDE and CLI を翻訳したものです。

本記事は 2026 年 10 月 23 日 に公開された「 Build RAG-ready indexes from Amazon S3 with Amazon OpenSearch intelligent ingestion 」を翻訳したものです。 組織の価値ある知識の多くは、契約書、製品マニュアル、調査レポート、サポートの runbook、財務書類などのドキュメントに蓄積されています。こうしたコンテンツは Amazon Simple Storage Service (Amazon S3) に、構造化データ (JSON、NDJSON、JSON 配列) と非構造化データ (PDF、Word、テキスト、Markdown) として保存されています。生成 AI アプリケーション、検索拡張生成 (RAG) アシスタント、エンタープライズ検索の体験の品質は、こうしたコンテンツにどれだけアクセスできるかで決まります。しかし、こうしたデータは検索対象として扱いやすい形にするのが最も難しい部類に入ります。データを抽出するには、顧客は複数のステップから成る複雑な取り込みパイプラインを運用する必要があります。 レイアウト、読み順、表を保ったままテキストを抽出するドキュメントパーサーの実行 ドキュメント内のチャート、図、スクリーンショットの抽出と内容の解釈 抽出したテキストのチャンク分割と埋め込みモデルによる処理、ベクトルインデックスへの書き込み レイヤーごとに専用のインフラ、スケーリングの検討、起こりうる障害のパターンがあります。複雑さは積み重なり、エンドツーエンドで動かすまでに数週間を費やす組織も少なくありません。 本日、 Amazon OpenSearch intelligent ingestion を発表します。Amazon OpenSearch Serverless (NextGen) 上で動作するフルマネージドかつサーバーレスの取り込み機能です。コレクションから Amazon S3 のデータを指定し、処理方法を選ぶだけで利用できます。残りは intelligent ingestion が引き受けます。S3 からコンテンツを発見し、ドキュメントを解析し、画像の内容を記述し、コンテンツをチャンクに分割し、ベクトル埋め込みを生成し、結果をインデックスに書き込みます。設定が必要なパイプラインも、運用するドキュメント処理インフラも、事前に見積もるキャパシティもありません。 intelligent ingestion で以下のことができます。 手動パイプラインなしで生のドキュメントからセマンティック検索へ。 PDF、Word、Markdown ファイルを取り込み、レイアウトや表を保ったまま解析して、セマンティック検索やハイブリッド検索に対応したインデックスに格納します。 視覚的なコンテンツも検索可能に。 ドキュメントにチャート、図、スクリーンショット、写真が含まれる場合、ビジョン言語モデルが詳細なテキスト記述を生成します。画像にしか含まれない情報も検索できます。 パイプラインのコードなしで構造化データを取り込み。 JSON、NDJSON、CSV のデータを読み込み、取り込み時に変換を適用できます。オプションでセマンティック検索向けの付与も可能です。 単発の取り込みと継続的なストリームを選択可能。 移行やバックフィルなど一度きりまたは定期的なロードには Ingestion Jobs を使い、バケットに新しいオブジェクトが到着するたびにインデックスを継続的に同期するには Ingestion Streams を使います。 実際の処理分だけ課金。 キャパシティはワークロードに合わせて自動的にスケールし、アイドル状態の取り込みキャパシティには課金されません。 本記事では、intelligent ingestion の仕組みと、Ingestion Jobs と Ingestion Streams の使い分けを説明します。続いて、Amazon S3 の非構造化ドキュメントをまとめて取り込み、Amazon OpenSearch Serverless (NextGen) で RAG 対応のインデックスとして処理するまでの流れを示します。ログや構造化データも同じワークフローで取り込めます。アプリケーションログ、監査証跡、商品カタログなどの JSON、NDJSON、JSON 配列データを Amazon S3 から読み込み、取り込み時に変換を適用し、オプションでセマンティックエンリッチメントも適用できます。RAG のナレッジベースとログ分析で同じ取り込み体験を共有できます。 ソリューション概要 intelligent ingestion は Amazon OpenSearch Serverless (NextGen) コレクションの内部で動作し、S3 バケットからインデックスまでの経路全体を管理します。Ingestion Job または Ingestion Stream を作成するときに指定するのは次の 2 つだけです。 ソース – データが格納された Amazon S3 バケットとプレフィックス デスティネーション – 処理されたデータの格納先となる Amazon OpenSearch Serverless (NextGen) コレクション内のインデックス この指定を受けて、intelligent ingestion は以下のステップを実行します。 データ検出: intelligent ingestion は S3 プレフィックス配下のオブジェクトを自動的にスキャンします。Ingestion Streams では、Amazon Simple Queue Service (Amazon SQS) 通知を使って新しいオブジェクトの到着を検出します。 ドキュメント解析: PDF や Word ファイルを検出すると、intelligent ingestion は見出し、読み順、表を保ったまま構造化されたコンテンツに解析します。 画像からの情報抽出: PDF や Word ファイル内に画像を検出した場合、豊富なテキスト記述を生成し、視覚的なコンテンツを周囲のテキストと並べてインデックス化できるようにします。 チャンク分割と埋め込み: intelligent ingestion は検索に適したサイズにコンテンツをチャンク分割し、OpenSearch Automatic Semantic Enrichment を使ってベクトル埋め込みを生成します。 インデックス化: intelligent ingestion はチャンク、スパース埋め込み、メタデータをインデックスに書き込みます。コレクショングループで事前に設定した OpenSearch Compute Unit (OCU) の上限内で、ワークロードに応じてキャパシティを自動的にスケールします。 Ingestion Jobs と Ingestion Streams &nbsp; Ingestion Jobs Ingestion Streams 使うタイミング 固定のデータセットを一度だけロードする データが継続的に到着または変化する 典型的なシナリオ 初期ロード、移行、バックフィル、PoC 成長を続けるナレッジベース、継続的に更新されるドキュメントライブラリ 動作 プレフィックス配下の全オブジェクトを取り込んで完了する 新しいオブジェクトが到着するたびにインデックスを同期し続ける 前提条件 本記事の内容を試すには、以下が必要です。 Amazon OpenSearch Serverless (NextGen) コレクションの作成と管理の権限を持つ AWS アカウント データを格納した Amazon S3 バケット intelligent ingestion が Amazon S3 からデータを読み取るための AWS Identity and Access Management (IAM) ロールと権限 仕組み Amazon OpenSearch Serverless の AWS マネジメントコンソールページに、新しく Ingestion タブが追加されました。 Create ingestion job を選んで取り込みを開始したり、タブ上で既存のジョブを確認したりできます。 図 1: Amazon OpenSearch Service コンソールの Ingestion タブ intelligent ingestion はソースの構成に応じて 3 つのモードをサポートします。Amazon S3 上の静的なデータセットには One-time batch を選択します。一度取り込みを行い、取り込みジョブは完了後に自動で終了します。 図 2: One-time batch 取り込みモードの選択 これから新しいデータが入ってくる S3 バケットには Continuous streaming を選択すると、通知を継続的に監視し、新しいデータが到着するたびに取り込みを行います。S3 バケットに既にデータが入っている場合は Batch then stream を選択すると、既存データを取り込んでから継続ストリーミングモードに切り替わります。いずれのシナリオでも、intelligent ingestion は Amazon SQS キューを使って Amazon S3 のオブジェクト通知を受け取り、データ取り込みのために引き受ける IAM ロールの Amazon Resource Name (ARN) を必要とします。 図 3: Amazon SQS キューと IAM ロールを使った Continuous streaming の設定 Backfill then stream は上記 2 つのモードを組み合わせた動作です。初期バックフィル用に 1 つのバケットを指定し、新しいデータのストリーミング用に別のバケットを追加できます。 intelligent ingestion は同一 AWS アカウント内の S3 バケットと自動で連携します。このページで S3 バケットを選択し、オプションでプレフィックスを指定して、バケット内のどのフォルダやファイルを取り込むかを絞り込めます。別の AWS アカウントの S3 バケットにも対応しています。クロスアカウントで利用する場合は、対象アカウントの AWS アカウント ID、Amazon S3 バケット、IAM ロール ARN、そして両方のリソースにアクセスするためにオプションで Amazon SQS を指定します。 図 4: Amazon S3 バケットの選択とクロスアカウントアクセスの設定 (オプション) 開始するには、 Create ingestion job を選んで設定を完了し、 Validate and continue を選択します。このページで設定を確認し、取り込みジョブまたはストリームの名前を入力して、取り込みを開始します。開始した取り込みジョブまたはストリームは、Amazon OpenSearch Serverless (NextGen) コレクションの Ingestion タブに表示され、まとめて管理できます。 図 5: 取り込みジョブの設定と名前を確認してから開始 開始後、intelligent ingestion はまず S3 バケット内のデータ型をスキャンし、コンテンツ (構造化データ、非構造化データ、画像を含むデータ) に応じた処理方式を決定します。取り込みに必要な作業は intelligent ingestion が自動的に行います。同じページでスキャン済みおよびインデックス化済みのドキュメント数を確認できます。これでデータが Amazon OpenSearch Serverless で検索可能になります。 図 6: スキャン済みおよびインデックス化済みドキュメント数のモニタリング 料金 intelligent ingestion は実際に利用した分だけ課金されます。 JSON などの構造化データは、OpenSearch Serverless に直接取り込んでインデックス化できます。各データ取り込みワーカーが実際に動作している時間に対して標準の OCU 料金が発生します。取り込みジョブが完了すると自動的に終了し、課金も停止します。 PDF や Word ドキュメントなどの非構造化データは、追加の解析とチャンク分割、場合によっては画像からの情報抽出を必要とします。intelligent ingestion は、事前に設定した上限の範囲内でサーバーレスインデックス作成 OCU を自動的に使い、テキストを抽出してページを構造化データにチャンク分割します。料金は標準の OCU レート、たとえば US East (バージニア北部) で 1 時間あたり 0.24 USD です。この料金は構造化データ取り込みに上乗せで発生します。社内テストによると、追加で 1 OCU あれば 1 時間あたり 600 ページの PDF を処理でき、取り込み可能な状態まで処理するコストは PDF 1,000 ページあたり 0.40 USD となります。intelligent ingestion は Amazon Nova 2 Lite を使って PDF や Word ファイル内の画像から情報を抽出します。Amazon Bedrock のモデル推論料金は Nova 2 Lite の Amazon Bedrock 公開料金 と同じで、入力トークン 100 万あたり 0.30 USD、出力トークン 100 万あたり 2.50 USD です。社内テストによると、画像 1,000 枚あたり平均で入力トークン 50 万、出力トークン 50 万を消費します。画像 1,000 枚の処理コストはおよそ 1.40 USD になります。 クリーンアップ 今後の課金を避けるため、本記事のウォークスルーで作成したリソースを削除します。作成した Ingestion Streams を削除し、不要であれば OpenSearch コレクションと S3 バケット内のサンプルドキュメントも削除します。Ingestion Jobs は完了後にキャパシティの消費が停止します。 まとめ 本記事では、Amazon OpenSearch intelligent ingestion が Amazon S3 のエンタープライズドキュメントを、管理対象の取り込みパイプラインなしに RAG 対応の情報源に変換する方法を紹介しました。ソース、処理動作、デスティネーションを選ぶだけで、intelligent ingestion がドキュメントを解析し、画像の内容を記述し、コンテンツをチャンクに分割し、ベクトル埋め込みを生成し、結果をインデックス化します。ワークロードに応じてスケールし、実際の処理分だけ課金します。これまでパイプラインの構築に数週間かかっていた作業が、わずか数クリックまたは 1 回の API 呼び出しで完了します。チームは、ユーザーが求める検索や生成 AI の体験づくりに集中できます。intelligent ingestion は本日より、6 つの対応 AWS リージョンで Amazon OpenSearch Serverless (NextGen) コレクションの Amazon S3 データソースとして利用可能です。 ドキュメントを検索可能にしたい方は、 Amazon OpenSearch Service コンソール を開き、コレクションを選択して、最初の Ingestion Job を作成してください。少量のドキュメントから始めれば、数分で結果を確認できます。その後、Ingestion Stream を追加すれば、コンテンツの増加に合わせてインデックスを同期し続けられます。詳細は Amazon OpenSearch Service 開発者ガイドの Intelligent ingestion を参照してください。料金の詳細は Amazon OpenSearch Service の料金 を参照してください。 著者について Arthur Hang Zuo Arthur は Amazon OpenSearch Service のシニアプロダクトマネージャーです。intelligent ingestion、OpenSearch UI プラットフォーム、オブザーバビリティと検索のユースケースを支える AI アシスタントをリードしています。エージェント型 AI とデータプロダクトのトピックに関心を持っています。 David Venable David は Amazon Web Services の OpenSearch で取り込みとオブザーバビリティに取り組むシニアソフトウェアエンジニアです。オープンソースの OpenSearch Data Prepper プロジェクトのメンテナーを務めています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

みなさん、こんにちは。 シニアスペシャリストソリューションアーキテクトの加藤です。 2026 年 10 月 7 日に、AWS 東京オフィスで「AWS 秋のクラウドオペレーション祭り 2026 〜AI をクラウド運用にも活用しよう〜」と題したイベントを開催しました。 ご参加いただいたみなさま、ありがとうございました。 これまで AWS は、クラウド運用に関するイベントを「AWS 秋のオブザーバビリティ祭り」と「AWS 秋の Cost Optimization 祭り」というように、テーマごとに深掘りする形で開催してきました。昨年秋の開催報告ブログはこちらです。 【開催報告 &amp; 資料公開】AWS 秋のオブザーバビリティ祭り 2025 【開催報告 &amp; 資料公開】AWS 秋の Cost Optimization 祭り 2025 昨今、コーディングエージェントの普及によって、開発の進め方は大きく変わりつつあります。 クラウド運用でも、re:Invent 2025 で AWS DevOps Agent をはじめとするフロンティアエージェントが発表され、続いてコスト管理を担う AWS FinOps Agent（プレビュー）が加わったことで、運用業務を AI エージェントに任せる選択肢が現実のものとなりつつあります。 そこで今回はテーマをクラウド運用 × AI とし、運用のカテゴリを広くカバーする形で実施してみました。 当日は、運用業務をどこまで AI に任せられるのか、そのために何を備えるべきか、という問いを軸に 5 つのセッションをお届けしました。 本記事では各セッションの概要と発表資料をご紹介します。 イベント概要 当日のアジェンダは以下のとおりです。 時間 内容 19:00-19:05 オープニング 19:05-19:25 AWS DevOps Agent で変わるリリースと運用対応 〜リリース管理機能と Directed actions のご紹介〜 19:25-19:40 Well-Architected Agent (プレビュー) で加速する Well-Architected Framework Review 19:40-19:55 AWS FinOps Agent (プレビュー) による FinOps の推進 19:55-20:05 休憩 20:05-20:25 集める・貯める・見る ── AI 時代の CloudWatch 20:25-20:45 業務用の AI エージェントをセキュアに活用する 20:45-20:55 全体 Q&amp;A 20:55-21:00 クロージング セッションの紹介 AWS DevOps Agent で変わるリリースと運用対応 〜リリース管理機能と Directed actions のご紹介〜 アマゾン ウェブ サービス ジャパン合同会社 シニアクラウドサポートエンジニア 古野 俊広 発表資料 本セッションでは、AWS Summit Tokyo で私が登壇した「 AWS DevOps Agent による自律的インシデント対応 −その能力を引き出す設計のベストプラクティス− 」の後に追加された機能を中心に、障害からの復旧と障害の未然防止の 2 つの観点でご紹介しました。 復旧の観点では、これまでの AWS DevOps Agent は障害の調査と復旧方法の提示までを提供しており、復旧のための AWS CLI コマンドの実行などのリソース操作はお客様ご自身で実施いただく必要がありました。 新たに追加された Directed actions により、人の承認を経たうえで AWS DevOps Agent がリソースを直接操作できるようになったことと、エラーの調査から修正の実行、アラームの解消までのデモをご紹介しました。 また、AI コーディングエージェントの普及でコードの変更量が増え、人によるレビューやテストだけでは本番前に問題を発見できないケースが想定されます。 そこで重要になるのが、コードが本番環境で動く前に検証するシフトレフトです。 これを実現するリリース管理機能として、プルリクエストを自動レビューしてリリース可否を判定する Release Readiness Review と、デプロイ済みのアプリケーションに実際のリクエストを送ってリグレッションを検出する Release Testing をご紹介しました。 この 2 つのリリース管理機能はプレビュー中（イベント開催時点）で、us-east-1 リージョンでのみ利用可能となっています。 Well-Architected Agent (プレビュー) で加速する Well-Architected Framework Review アマゾン ウェブ サービス ジャパン合同会社 テクニカルアカウントマネージャー 荻野 魁人 発表資料 本セッションでは、2026 年 10 月 1 日に公開された AWS Well-Architected Agent (プレビュー) を使って Well-Architected Framework Review（WAFR）を進める方法をご紹介しました。 WAFR は、クラウド設計のベストプラクティス集である AWS Well-Architected Framework に照らして現在の設計を確認し、学ぶ、測る、改善するというサイクルを回す取り組みです。 ただし、対象となるベストプラクティスは 300 を超えるため、手作業で進めると数週間を要し、指摘をどこから改善すればよいかの判断も難しくなりがちです。 AWS Well-Architected Agent (プレビュー) は、お客様が登録したビジネス目標とアプリケーションコンテキスト（アプリケーションやアーキテクチャの概要、運用上の制約など）をもとに AWS 環境を分析し、影響と労力に基づいて優先順位を付けた推奨事項を提示します。 各推奨事項には、その推奨が必要な理由に加えて、変更した場合に他の柱へ及ぶトレードオフとその緩和策、修正手順が示されます。 セッションでは、内部監査で高リスクの指摘をゼロにするという目標を登録した発注システムを例に、データベースのログを CloudWatch Logs へエクスポートする推奨事項と、ログの取り込み料金が増えるトレードオフ、保持期間を 365 日に設定する緩和策が提示される流れをご紹介しました。 AWS FinOps Agent (プレビュー) による FinOps の推進 アマゾン ウェブ サービス ジャパン合同会社 テクニカルアカウントマネージャー 加須屋 悠己 発表資料 本セッションでは、AWS FinOps Agent（プレビュー）を使って FinOps を推進する方法をご紹介しました。 FinOps は、FinOps Foundation が定義する、エンジニアリング、財務、ビジネスの各チームを結び付けてクラウドのコストを管理する運用フレームワークであり、文化的な実践です。 ただし、FinOps Foundation による年次のサーベイである State of FinOps 2026 では、1〜4 名の FinOps チームですべてのアカウントを担っている、コストのスパイクのたびにアラート対応に追われて根本原因の調査が遅れる、毎週や毎月の定期レポートの作成に時間を取られる、アイドルリソースやライトサイジングの推奨事項が先送りされて溜まり続ける、といった課題が挙がっています。 さらに、同サーベイでは今後 12 か月の優先事項のトップが FinOps for AI になっており、AI コストの可視化、配分と配賦、AI の価値や ROI の把握といった新たな課題も加わっています。 AWS FinOps Agent（プレビュー） は、コストに関する問い合わせや指示を自然言語で行えるフロンティアエージェントです。 AWS Cost Explorer や AWS Cost Anomaly Detection、AWS Cost Optimization Hub などのデータをもとに、コストの増減要因の分析、日次や週次、月次の定期レポートの作成、コスト異常の調査、最適化機会の提示を行います。 結果は、Slack チャネルへの投稿や Jira チケットの作成によって共有することも可能です。 セッションでは、Cost Anomaly Detection を起点にコスト異常の調査と Slack への通知を自動化する例と、手作業で作っていた月次レポートを定期実行に置き換える例をご紹介しました。 日本語のハンズオンワークショップも公開されているので、資料内のリンクからお試しください。 集める・貯める・見る ── AI 時代の CloudWatch アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 梅津 寛子 発表資料 本セッションでは、AI エージェントに障害調査を任せる前提として、テレメトリを集める、貯める、見るという 3 つの観点で Amazon CloudWatch の最新機能をご紹介しました。 テレメトリが足りなければ、AI であっても人と同じように仮説を絞り込めず、根本原因にたどり着けないまま人が調べ直すことになり、復旧が遅れてしまいます。 反対に、メトリクスとトレースがそろっていた弁護士ドットコム株式会社では、AWS DevOps Agent によって調査開始から約 10 分で性能劣化の根本原因を特定できたことを、 AWS ブログ にご寄稿いただいています。 こうした状態を先に整えておけるよう、セッションでは集める、貯める、見るのそれぞれについて、CloudWatch の今年の主要アップデートをご紹介しました。 まず集める観点では、CloudWatch の ログ と メトリクス が OpenTelemetry Protocol（OTLP）での取り込みに対応し、トレースとあわせて 3 つのシグナルすべてを OpenTelemetry のまま CloudWatch に送れるようになったことをご紹介しました。 次に貯める観点では、2026 年 7 月に登場した CloudWatch Logs の Intelligent Tiering をご紹介しました。 アクセスされていないログを低コストのストレージ階層へ自動で移しつつ、どの階層のログも同じクエリで遅延なく検索できるため、コストを理由に保持期間を短くする必要がなくなります。 最後に見る観点では、2026 年 9 月 23 日に一般提供が始まった CloudWatch Omni をご紹介しました。 CloudWatch Omni は、CloudWatch のデータを AWS マネジメントコンソール外部の独立した Web UI に加えて、IDE 拡張からも利用可能な、AI を組み込んだ新しい可視化・分析機能です。 自然言語の指示に従い AI がクエリを発行し、自動で適切な UI が表示されるというのが大きな特徴です。 なお、イベント開催時点では東京リージョンに未対応でしたが、2026 年 10 月 15 日から東京リージョンでも利用できるようになりました。ぜひお試しください。 業務用の AI エージェントをセキュアに活用する アマゾン ウェブ サービス ジャパン合同会社 シニアスペシャリストソリューションアーキテクト 須田 聡 発表資料 本セッションでは、業務で AI エージェントを活用するためのセキュリティを、 AWS の AI セキュリティフレームワーク に沿ってご紹介しました。 McKinsey の The State of AI in 2026 では、AI の展開をビジネス戦略上クリティカルと回答した経営者が 94% にのぼる一方で、AI をガバナンスできていると回答した企業は 10% にとどまっています。 こうした状況を踏まえ、AI にセキュリティを後から追加するのではなく、今すでにあるセキュリティ基盤の上に AI を構築するという考え方をご紹介しました。 運用で AI を活用するアプローチとしては、AWS DevOps Agent や AWS FinOps Agent（プレビュー）、AWS Security Agent といった目的別に特化されたマネージド AI エージェントサービスを使う方法と、Kiro や Amazon Bedrock 上の AI エージェントのような汎用的な AI で業務を効率化する方法をご紹介しました。 目的別のサービスはカスタマイズ部分をセキュアに構成して利用することでセキュリティ脅威の対策にもなり、汎用的な AI はマネージドな基盤の上で AI エージェントを動かして利用します。 さらに、AI のユースケースを質問に答える AI、連携する AI、実行する AI の 3 つに、統制をかける場所をインフラストラクチャ、アイデンティティとデータ、AI アプリケーションの 3 つのレイヤーに区分し、ユースケースが広がるのにあわせてガバナンスの領域を拡大していく進め方をご紹介しました。 まとめ 今回は「AI をクラウド運用にも活用しよう」というテーマで、障害対応とリリース、アーキテクチャレビュー、コスト管理、オブザーバビリティ、セキュリティの 5 つの領域を取り上げました。 AWS DevOps Agent、AWS Well-Architected Agent（プレビュー）、AWS FinOps Agent（プレビュー）のセッションでは運用業務をどこまで AI エージェントに任せられるのかを、CloudWatch とセキュリティのセッションではそのために何を備えるべきかを、それぞれご紹介しました。 今後もクラウド運用に 関連するイベントや情報発信を続けていきますので、次回もぜひご参加ください。

プラットフォームチームが Amazon Elastic Container Service (Amazon ECS) でコンテナ化されたアプリケーションを大規模に管理する場合 、各サービスの入力ネットワークを設定することがボトルネックになることがよくあります。新しいサービスごとに、&lt;tag&gt;チームは Application Load Balancers (ALBs) 、 AWS Certificate Manager (ACM) 証明書、 AWS WAF &nbsp;の web ACL、およびセキュリティグループをプロビジョニングして接続し、サービスの拡張、更新、運用に合わせてそれらのリソースを同期させる必要があります。このサービスごとのオーバーヘッドは、導入速度を低下させ、組織全体での構成ドリフトのリスクを高めます。 2026 年 10 月 20 日、Amazon ECS Gateway を発表しました。 Amazon ECS Gateway は、すべてのリソースをお客様のアカウントで直接作成して、お客様に代わって必要なインフラストラクチャを動的にプロビジョニングおよび管理することで、コンテナ化されたワークロードの進入ネットワークを簡素化する新しいアカウントレベルのリソースです。 ECS Gateway は、プラットフォームチームとアプリケーションチーム間の責任を明確に分離します。 プラットフォームチームは 、サブネット、セキュリティグループ、TLS 証明書、リスナー設定、WAF Web ACL などの組織のネットワーク標準を定義するゲートウェイを1か所で作成および構成します。次に、ゲートウェイを 1 つ以上の ECS クラスターに関連付け、それらのクラスターで実行されているサービスが使用できるようにします。 アプリケーションチームは 、サービスの作成または更新時にゲートウェイコネクタパラメータを追加することでサービスをオプトインします。ECSは、必要なサービスごとのリソース（ACM 証明書、一意の DNS ホスト名、リスナールール、ターゲットグループ、ALB からのインバウンドトラフィックのみを許可するサービスセキュリティグループ）を自動的にプロビジョニングします。ネットワークの専門知識は必要ありません。 ECS Gateway は、ALB を使用したホストベースのルーティングを提供し、最大25のサービスが1つの ALB を共有できるようにすることで、インフラストラクチャのコストを最適化します。ECS は基盤となるインフラストラクチャのライフサイクル全体を管理し、最初のサービスが接続されたときに最初の ALB をプロビジョニングし、容量に達すると ALB を追加し、不要になったら削除します。各サービスには固有の DNS ホスト名が割り当てられるため、プロビジョニングが完了した瞬間にチームがすぐに使えるエンドポイントを入手できます。 ECS Gateway の概要 ECS コンソールでは 、プラットフォームチームがゲートウェイを作成し、その構成を設定できます。インフラストラクチャロールは、アカウントの ALB、セキュリティグループ、証明書などのネットワークリソースをプロビジョニングおよび管理するために ECS が引き受ける IAM ロールです。ゲートウェイを作成するには、ゲートウェイ名を指定し、インフラストラクチャロールを選択します。オプションで、作成中または作成後にゲートウェイを ECS クラスターに関連付けることができます。 パブリックトラフィックルーティングまたは VPC 内部トラフィックルーティングのどちらかの負荷分散スキームを選択します。「 その他の設定 」では、リスナー、ポート、ゲートウェイがスケーリングできるロードバランサーの最大数を設定したり、ウェブアプリケーションを保護するためのウェブ ACL を設定したりできます。名前、スキーム、VPC、サブネット、IP アドレスタイプ、リスナープロトコル、ポートなどの一部の設定は、ゲートウェイの作成後に変更できません。 AWS コマンドラインインターフェイス (AWS CLI) を使用して、名前 (アカウントごとに一意)、インフラストラクチャロール、および設定オブジェクトを指定して CreateGateway を呼び出します。サービスがゲートウェイコネクタに接続するまで、インフラストラクチャはプロビジョニングされません。 aws ecs create-gateway \ --name my-team-gateway \ --infrastructure-role-arn arn:aws:iam::123456789012:role/ECSGatewayRole \ --configuration '{ 「HostSharedAlb」: { "networkConfiguration": { "subnets": [ 「subnet-080779f9bd887757a」, 「subnet-03d5b2fead6bc6258」, 「subnet-0861210a397d31252」, 「subnet-06539e194023cb77a」 ], 「ipAddressType」: 「ipv4」 }, 「scheme」: 「internet-facing」 } }' ゲートウェイを作成したら、詳細な構成、ゲートウェイルート、ロードバランサー、および関連するクラスターを確認できます。 次に、ゲートウェイを 1 つまたは複数のクラスター (多対多) に関連付けて、それらのクラスターの ECS サービスで使用できるようにします。 AssociateGatewayWithCluster を使用して、ゲートウェイをクラスター上のサービスで使用できるようにします。 aws ecs associate-gateway-with-cluster \ --gateway my-team-gateway \ --cluster arn:aws:ecs:us-east-1:123456789012:cluster/my-cluster API の呼び出しやドキュメントの検索など、ECS ゲートウェイをプログラムで作成・管理するには、お好みの AI コーディングツールで AWS MCP サーバー と プラグイン を試してください。詳細については、 Amazon ECS ゲートウェイのドキュメントをご覧ください 。 ECS ゲートウェイ:舞台裏 ゲートウェイは最大 10,000 個のクラスターに関連付けることができ、1 つのクラスターは最大 5 つのゲートウェイアソシエーションをサポートします。この多対多リレーションシップにより、プラットフォームチームは複数の環境間でゲートウェイを共有したり、単一のクラスターに複数のゲートウェイ (パブリックとプライベートなど) を割り当てたりする柔軟性が得られます。 プラットフォームチームは、どのゲートウェイをどのクラスターに関連付けるかを選択することでアクセスを制御できます。さらに制御するには、IAM ポリシーを使用して、特定のクラスターにサービスをデプロイできるユーザーを制限します。 アプリケーションチームは、 CreateService または UpdateService の各サービス定義にゲートウェイコネクタを追加します。独自のロードバランサーを備えた既存のECSサービスがある場合は、 UpdateService を呼び出してゲートウェイコネクタを追加することで、ECS Gatewayを段階的に採用できます。どちらの入力パスも引き続き利用できるため、既存のロードバランサー設定を削除する前にゲートウェイ接続を検証できます。 aws ecs create-service \ --cluster my-cluster \ --service my-api-service \ --task-definition my-api-service:1 \ --gateway-connectors 『[{ 「portName」: 「api」, 「filters」: {「accessTypes」: [「PUBLIC」]}, 「healthCheck」: {...} }]』 デプロイ時に、Amazon ECS はクラスターに関連するゲートウェイを評価し、互換性のあるすべてのゲートウェイにサービスを接続します。ゲートウェイは、アクセスタイプがサービスのコネクタフィルターと一致し、サービスと同じ VPC にあり、サービスの設定済みサブネットで使用されるすべてのアベイラビリティーゾーンをカバーしている場合に互換性があります。 接続ごとに、Amazon ECS は利用可能な容量がある ALB にサービスを割り当て、サービスごとのリソースをプロビジョニングします。これらのリソースとは、ACM 証明書、一意の DNS ホスト名、そのホスト名のトラフィックをサービスターゲットグループにルーティングするリスナールール、および ALB セキュリティグループからのインバウンドトラフィックのみを許可するサービスセキュリティグループです。既存の ALB に容量の空きがない場合、ECS は新しい ALB を作成します（クォータ制限に基づき、最大で maxAlbCount まで作成可能です）。プロビジョニングが完了すると、ゲートウェイルートは ACTIVE になり、サービス URL はトラフィックを受信できるようになります。 ECS Gateway は、一般的な運用シナリオを自動的に処理します。 再デプロイ:デプロイのたびに 、ECSはゲートウェイの関連付けを再評価します。前回のデプロイ以降、互換性のある新しいゲートウェイが関連付けられている場合、サービスはそれらに接続します。ゲートウェイの関連付けが解除されると、サービスは切断され、ルートは削除されます。サービスには、デプロイ時に常にクラスターゲートウェイの現在の状態が反映されます。 サービスの削除 : ECS は、すべてのゲートウェイからサービスを自動的に切断し、すべてのゲートウェイルートを削除し、サービスごとのすべてのリソースをクリーンアップします。サービスが ALB の最後のルートを保持していた場合、その ALB はプロビジョニング解除されます。 知っておくべきこと 覚えておくべき重要な詳細は次のとおりです。 ネットワーク : ECS ゲートウェイは、すべての起動タイプ (Amazon ECS EC2、AWS Fargate、ECS マネージドインスタンス) で awsvpc ネットワークモードを使用する ECS サービスで使用できます。サービスアベイラビリティーゾーン (AZ) は、クラスター上の各ゲートウェイの AZ のサブセットである必要があります。ゲートウェイ ALB は、サブネットがある AZ 内のタスクにのみトラフィックをルーティングします。同じ AZ セットを使用して特定のクラスターのゲートウェイとサービスを作成することをお勧めします。 キャパシティ : maxAlbCount に達しても、使用可能なキャパシティがあるALBがない場合、デプロイは失敗します。 maxAlbCount のデフォルトのクォータ制限は 10 です。 maxAlbCount の設定は、接続する予定のサービスの数に合わせて計画してください。 オブザーバビリティ :CloudWatch の ALB メトリクスを TargetGroup ディメンションとともに使用してサービスごとのトラフィックをモニタリングし、 LoadBalancer ディメンションを使用して共有 ALB 全体のトラフィックをモニタリングします。 describe-target-health を使用して、ターゲットのステータスをリアルタイムで確認します。CloudWatch アラームを、 HealthyHostCount 、 TargetResponseTime 、 HTTPCode_Target_5XX_Count などのメトリックスに対して設定し、ゲートウェイ ARN ベースのタグ付けを使用することで、モニタリングが maxAlbCount に合わせて自動的にスケーリングするようにします。 今すぐご利用いただけます Amazon ECS ゲートウェイは、ECS が追加料金なしで利用できるすべての商用 AWS リージョンでご利用いただけるようになりました。サービスがゲートウェイに接続されたときに、該当する ALB 料金、CloudWatch ログとメトリックス、ACM 証明書、データ転送料金など、アカウントにプロビジョニングされた基盤インフラストラクチャの料金のみをお支払いいただきます。詳細については、 Amazon ECS の料金ページ をご覧ください。 開始するには、今すぐ ECS コンソールで最初のゲートウェイを作成し 、 フィードバックを AWS re: Post for ECS に送信するか、通常の AWS サポート担当者を通じて送信してください。 – Channy 原文は こちら です。

2026 年 10 月 13 日週に起きたことは、新しい種類のコンピュートを追加したわけではありません。代わりに実現したのは、すでにお持ちのコードと、そのコードが本番稼働するまでの距離を縮めることでした。 AWS Lambda は、手前にアダプターを置かずにプレーンな HTTP サーバーを実行できるようになり、 Amazon S3 は、AWS マネジメントコンソールを開かずに、すでに使用しているツールの中からプロビジョニングできるものになりました。異なるサービス、同じ方向性です。 カウンターバランスとなる話題は木曜日に登場しました。本番環境に物事を投入するのが容易になるほど、それらが何を許可されているかを明言できることの重要性が増します。今週最も興味深い読み物はまさにその点についてです。それでは、今週の AWS ニュースを見ていきましょう… 主なトピック AWS Lambda Web Functions は、標準的な HTTP Web アプリケーションをイベントハンドラーに書き換えることなく Lambda 上で実行する新しいフォームファクターです。Express、Hono、Fastify、Next.js で構築したポート待ち受けサーバーを用意し、 aws lambda-web deploy を実行すると、1 分以内に稼働中の HTTPS URL が返ってきます。アダプター不要、事前のインフラ構築不要、フレームワークのロックインなし。Lambda には現在、同じ Firecracker 分離上で 3 つのフォームファクターがあり、1 つのアプリケーション内で組み合わせられます。非同期処理向けの Event Functions (すでにご存じのモデル)、ユーザー向けレイヤー向けの Web Functions、信頼できないコードを実行するステートフルなサンドボックス向けの MicroVM です。 2 つのポイントが、これを単なる再パッケージにとどまらないものにしています。各実行環境は最大 128 件の同時リクエストを処理するため、トラフィックの急増時はリクエストごとに 1 つの環境を割り当てるのではなくウォーム環境を共有し、課金は実時間ではなくコードが実際に使用した CPU 時間を計測します。サーバーサイドレンダリング、API バックエンド、トークンをストリーミングする推論エンドポイントなど、経過時間の大半を待機に費やすケースでは、これにより計算が変わります。同じデプロイコマンドに --regions を追加すると、コードがレプリケートされ、単一のグローバル URL の背後でレイテンシーベースのルーティングが構成されます。また、カナリアリリースのためにリビジョン間でトラフィックを重み付けして分割できます。5 つのリージョンで利用可能で、Arm64 上で Node.js 24 を実行し、VPC 接続に対応しています。 AWS Compute Blog にはより詳細なウォークスルーがあり、 Amazon CloudFront はオリジンアクセスコントロールを使用して Web Function エンドポイントをオリジンとして利用 できるようになりました。 10 月 19 日週のもう 1 つの見出しはローンチではありません。 Trust in Depth: giving agents more autonomy without losing control は、実務で何度も出会う主張を展開しています。エージェントのあらゆる行動に人を介在させる仕組みは小規模では機能しますが、その後は静かに機能しなくなります。すべてを確認するよう求められた人は、重要なものを見逃すようになるからです。代替案は、4 つの時点で答える 4 つの問いであり、AWS はこれを scope、know、bound、observe と呼んでいます。じっくり考える価値があるのは、エージェントの限界はエージェント自身の推論の外側、すなわちゲートウェイで適用される Amazon Bedrock AgentCore のポリシーに属するという点です。エージェントは、自分が実行していない制御を無効にできないからです。AWS は 10 年以上にわたり本番環境で自動推論を運用しており、AWS Identity and Access Management では毎秒 21 億件を超えるリクエストを処理しています。ここでの主張は、それをエージェント向けに記述するルールに適用するというものです。 10 月 13 日週のリリース 10 月 13 日週のリリースのうち、私が注目したものをいくつかご紹介します。 Amazon S3 is now available on the Vercel Marketplace and v0 by Vercel – Vercel ダッシュボードから、または v0 で構築したい内容を説明することで、S3 汎用バケット、 S3 Tables 、 S3 Vectors をプロビジョニングできるようになりました。これは Amazon Aurora 、 Amazon DynamoDB 、 Amazon OpenSearch Serverless の既存の統合に加わるため、スタック全体が 1 つの AWS アカウントと 1 つの請求に収まります。認証の詳細が優れている点です。短命の OIDC トークンを実行時に AWS Security Token Service と交換し、そのリソースにスコープされた認証情報を取得するため、静的キーはどこにも保存されません。 Amazon EC2 T8i instances are now available in South America (São Paulo) – 最新のバースタブル世代がサンパウロリージョンに登場しました。これはワークロードの地味な部分、つまりログインゲートウェイ、小規模データベース、CI/CD ランナー、低トラフィックのサイトにとって重要です。 Amazon EC2 T8i は、T3 と比べて最大 30% 優れた価格性能を提供し、コンピューティング性能は最大 70% 高く、Amazon EBS 帯域幅は 2.4 倍です。T3 と同じ CPU クレジットシステムを維持するため、移行は再設計ではなくサイズ変更になります。また、 t8i.micro と t8i.small は AWS 無料利用枠で利用できます。 Reflection Beam, an open-weight model for agentic coding, is now on AWS – Reflection AI のエージェントコーディングおよび長期タスク向けオープンウェイトモデルである Beam を、 Amazon SageMaker JumpStart からデプロイできるようになりました。これは合計 5,010 億、アクティブ 230 億パラメーターのスパースな Mixture-of-Experts モデルで、Apache 2.0 の下で Hugging Face に公開されており、Reflection は有効コンテキスト長が 100 万トークンであると報告しています。まずは JumpStart のリアルタイムエンドポイントから始めるか、Kubernetes ネイティブの制御が必要な場合は SGLang または vLLM を備えた SageMaker HyperPod Inference を使用してください。また、 AWS Trainium3 向けに移植および最適化 され、N. Virginia と Ohio でリリースされました。 AWS Lambda Durable Execution SDK for Go is now generally available – 外部イベントを待つ間、最大 1 年間一時停止し、自らの進捗をチェックポイントするマルチステップの Go ワークフローを、進捗追跡を自分で構築することなく記述できるようになりました。これにより、承認ゲート付きのデプロイロールアウトや、モデルを呼び出してから人によるレビューのために停止するパイプラインに対応できます。通常の Go ツールと同じように扱えます。 go get で追加し、 provided.al2023 ランタイムに単一の静的バイナリをデプロイし、 durabletest パッケージでワークフロー全体をローカルでテストできます。ネットワークアクセスや認証情報は不要です。 Amazon CloudWatch announces log routing and chained log parsers – Amazon CloudWatch パイプラインでルートを定義し、処理済みフィールドに対して評価された条件に基づいて各イベントを異なるロググループに送信できるようになりました。これにより、重大度、送信元、イベントタイプごとに、それぞれ独自の保持期間とアクセス制御を持つ場所に振り分けられます。連鎖パーサーがもう半分を担います。パーサーは順番に実行され、後続のパーサーが先行するパーサーの生成したフィールドを利用します。そのため、まず JSON エンベロープを解析し、次に抽出されたフィールドに対して Grok パーサーを実行できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 皆さんが興味を持つと思われるその他の記事とリソースをいくつかご紹介します。 AWS Security Agent exploited 33 of 37 new real-world CVEs – チームは、現在 AWS Continuum の一部となっている自律型ペネトレーションテストエージェントを、ライブのコンテナ化ターゲットとしてパッケージ化された最近公開された 37 件の CVE に向けました。開始時の情報はエンドポイント URL と 1 行のヒントだけでした。35 個のフラグを獲得し、各成功をチャレンジの正規の概念実証と照合して監査した結果、37 件中 33 件 (89.2%) が真のエンドツーエンド悪用として確認されました。失敗した 2 件こそが、この記事を読む価値のあるものにしています。どちらも、エージェントはバグを発見して悪用しましたが、フラグを読み取る前にターゲットをダウンさせてしまいました。有能な自律型攻撃者は、破壊的な攻撃者でもあります。 AWS re:Invent 2026 サーバーレス参加者ガイド – 非常に大規模なカタログを巡る厳選ルートで、人気セッションが満席になる前に入手しておく価値があります。 Dynata が AI-DLC と Kiro IDE で開発ライフサイクル全体に AI を拡大した方法 – エージェントコーディングが個人の習慣ではなくチームの働き方になったとき、何が変わるのか。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS re:Invent – re:Invent は 11 月 30 日から 12 月 4 日までラスベガスに戻り、2,200 を超えるセッションを開催します。 イベントカタログ が公開され、予約席も受付中です。ぜひ 登録 して、満席になる前に席を確保してください。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンスです。ここブラジルでは、2026 シーズンは 10 月 31 日にベレンで開催される AWS Community Day Brasil Norte で幕を閉じます。これは、国内のすべての地域を初めてカバーした 1 年の最後の開催地です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 10 月 19 日週のニュースは以上です。10 月 26 日週の次回 Weekly Roundup もお楽しみに! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

この記事は Under the hood: how Amazon EKS Auto Mode detects, repairs, and diagnoses node failures (記事公開日: 2026 年 8 月 5 日) を翻訳したものです。 GPU が PCIe バスから脱落する、ネットワークインターフェイスが応答しなくなる、コンテナランタイムが固まる。多くの Kubernetes クラスターでは、ここからオンコール対応が始まります。担当者が起こされ、ダッシュボードを確認し、SSH で接続して、cordon (スケジュール対象外としてマーク) とドレインを行い、インスタンスを手作業で終了します。 Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode では、誰かがノート PC を開くより先に、障害が起きたノードが自動的に検出され、ドレインされ、置き換えられます。 この仕組みは、2 つのコンポーネントの連携で成り立っています。 Amazon EKS ノードモニタリングエージェント (NMA) が障害を検出し、Kubernetes のノードの Condition として記録します。Karpenter はその Condition を読み取り、ノードを置き換えます。EKS Auto Mode では、どちらも設定なしで自動的に動作します。EKS Auto Mode 以外のコンピューティング (マネージドノードグループやセルフマネージドの Karpenter) でも、ノードモニタリングエージェントを EKS アドオン としてインストールすれば、同じ検出シグナルが得られます。修復の動作も同じです。Auto Mode での違いは、エージェントが DaemonSet ではなく、AMI に組み込まれた systemd サービスとして動作することです。そのため、エージェントは Pod のスケジューリングが正常に機能しない状況でも動作し続け、誤って退避させられたり、誤った設定にされたりすることもありません。 この記事では、修復サイクルの動作を順を追って見ながら、特定の障害がノードの置き換えをトリガーする一方で、他の障害が通知にとどまる理由を説明します。また、安全のためのしきい値が障害の連鎖を防ぐ仕組みと、ノードにログインせずに、どのノードからでも診断情報を収集する方法も紹介します。 検出と修復が連携する仕組み このサイクルは 2 つの部分からなり、両者の間には明確な取り決めがあります。 検出 (ノードモニタリングエージェント): エージェントは、カーネル、コンテナランタイム、ネットワーキング、ストレージ、高速コンピューティングハードウェアを監視します。そして、雑多な低レベルのシグナルを、少数の Kubernetes のノードの Condition にまとめます。障害が致命的で、ノードを置き換えるべきものであれば、エージェントは該当する Condition を False に切り替えます。 status: conditions: - type: AcceleratedHardwareReady status: "False" reason: NvidiaDeviceCountMismatch message: "Expected 8 GPUs, found 7." 修復 (Karpenter): Karpenter は、EKS Auto Mode のすべてのノードのプロビジョニングとスケーリングをすでに担っている、マネージドのコンピューティングコントローラーです。Karpenter は、これらの Condition を直接読み取ります。修復のために別のバックエンドを有効にする必要も、ノードグループごとにオプトインする必要もありません。ノードを起動したコントローラーが、そのままノードの置き換えも行います。Karpenter のクラウドプロバイダーが修復ポリシーを定義します。各ポリシーは、Condition のタイプと「このノードを置き換える」ことを意味するステータスを対応づけます。 置き換えが、Karpenter の唯一の修復アクションです。この点は、マネージドノードグループの自動修復と異なります。マネージドノードグループでは、Condition に応じてインスタンスの再起動か置き換えかを選びます。EKS Auto Mode では、異常なノードは常に新しいノードに置き換えられます。ノードがポリシーの条件に当てはまり、猶予期間を過ぎてもその状態が続くと、Karpenter が動きます。ノードに Taint を付与し、ドレインし、インスタンスを終了して、代替ノードを起動します。 ノードの Condition が、2 つの部分をつなぐ唯一のインターフェイスです。エージェントは Karpenter を呼び出さず、Karpenter はエージェントがどのように判定したかを知りません。エージェントは Kubernetes の標準の仕組みで Condition を書き込み、Karpenter はその Condition を見て動作します。両者が共有するのは Kubernetes API サーバーだけです。この疎結合によって、サイクルの信頼性が保たれています。 エージェントが検出するもの エージェントは、検出内容を 5 つのモニタリング用の Condition に分類します。 KernelReady 、 ContainerRuntimeReady 、 NetworkingReady 、 StorageReady 、 AcceleratedHardwareReady です。検出には、2 つの重大度のどちらかが付きます。 Condition 重大度の検出は致命的な障害で、該当する Condition を False に切り替え、ノードを置き換えの対象にします。 Event 重大度の検出は一時的な問題や最適でない設定で、ノードは稼働を続けたまま、状況を把握できるように Kubernetes イベントとして通知されます。修復を実行するかどうかは、この重大度で決まります。 修復をトリガーする障害は、そのままでは回復を待てないものです。高速コンピューティングインスタンスでは、GPU のデバイス数の不一致、重大な XID エラー、ダブルビット ECC エラーがこれにあたります。NVLink と NVSwitch のファブリック障害、Fabric Manager の欠落、Neuron の DMA、HBM、SRAM の訂正不能エラーも含まれます。これらは自然には回復しないハードウェア障害で、ノードを稼働させたままにすると、トレーニングのステップごとに GPU 時間を無駄にします。ネットワークでは、Amazon Virtual Private Cloud (Amazon VPC) Container Networking Interface (CNI) のプロセスの停止や、IPAMD が API サーバーに到達できない状態がこれにあたります。インターフェイスが起動しない場合や、ループバックがない場合も含まれます。カーネルとランタイムにも、それぞれ致命的なケースがあります。PID やメモリの枯渇による fork の失敗と、コンテナランタイムの故障により Pod が Terminating 状態のままになることです。 エージェントは、Event 重大度の検出も行います。こちらは Condition 重大度とは異なり、通知にとどまります。エージェントは Kubernetes イベントを発行し、ノードは稼働を続けます。対象は、帯域幅の上限、接続追跡 (conntrack) の上限、Amazon Elastic Block Store (Amazon EBS) の IOPS のスロットリング、I/O の遅延などです。ファイルシステムの断片化、クロックドリフト、Probe の失敗、kube-proxy の異常、GPU の温度と電力の警告も通知します。これらは、障害が致命的になる前に、その兆候を読み取る手がかりになります。理由コードとその重大度の一覧は、 ノードヘルスのドキュメント にあります。NVIDIA の GPU については、DCGM によって幅広い項目を検出します。DCGM は NVML の上に構築されていて、NVML の情報に加えて、プッシュ型のポリシーイベント、診断、NVSwitch のファブリックのヘルスを提供します。P5e や P6 のような複数の GPU を搭載したインスタンスでは、1 つの不良デバイスがトレーニングジョブ全体を止めてしまうことがあるため、この検出範囲が欠かせません。 Condition が False になってから新しいノードが動くまで ここからは、検出がどのようにノードの置き換えにつながるかを説明します。Karpenter の AWS クラウドプロバイダーは、一連の修復ポリシーを定義します。各ポリシーは、Condition のタイプと、異常とみなされるステータス、そして修復を開始する前に Condition が異常な状態を維持しなければならない許容ウィンドウ (toleration window) を対応づけます。 モニタリング用の Condition ステータス 修復までの許容ウィンドウ NodeReady (kubelet) False 30 分 NodeReady (kubelet) Unknown 30 分 KernelReady False 30 分 ContainerRuntimeReady False 30 分 NetworkingReady False 30 分 StorageReady False 30 分 AcceleratedHardwareReady False 10 分 処理の流れは次のとおりです。 エージェントが Condition を切り替える。 Condition 重大度の検出は、該当するノードの Condition を False に設定し、理由コード ( reason ) と、人が読めるメッセージ ( message ) を付けます。 Event 重大度の検出は、このステップに進みません。Kubernetes イベントを発行するだけで、ノードの Condition は True のままです。 Karpenter のヘルスコントローラーが時間を計る。Karpenter はノードの Condition を監視し、Condition の LastTransitionTime を起点にタイマーを開始します。許容ウィンドウが経過する前に自然に解消する一時的な問題であれば、タイマーがリセットされるだけで、ノードはまったく影響を受けません。 許容ウィンドウが修復の速さを決める。高速コンピューティングハードウェアの障害は 10 分待ちます。カーネル、ランタイム、ネットワーキング、ストレージの障害と、kubelet が報告する NodeReady は 30 分待ちます。 セーフティゲートがフリートを守る。NodePool またはクラスター内の異常なノードがしきい値 (20%) を超えると、Karpenter は修復を行いません。また、 Amazon Application Recovery Controller (ARC) のゾーンシフトが有効な間も、自動修復は停止します。この仕組みの狙いは、1 台の不良ノードを修復することであり、広範囲の問題を決して拡大させないことです。 修復が実行される。許容ウィンドウを過ぎ、安全のためのしきい値の範囲内であれば、Karpenter はノードに Taint を付与して新しい Pod のスケジューリングを止め、Pod Disruption Budget に従って実行中の Pod をドレインします。その後、インスタンスを終了し、退避させた Pod に見合うサイズの代替ノードをプロビジョニングします。分散トレーニングのようなステートフルなワークロードでは、回復できるかどうかは、ワークロードがチェックポイントから再開できるかどうかで決まります。システムはノードを置き換えて Pod を再スケジュールしますが、最後に保存した状態から再開するのはワークロードの役割です。 訳注: 2026 年 10 月時点では、EKS Auto Mode の自動修復は、通常のドレインではなく、ごく短い猶予期間で異常なノードの Pod を削除し、Pod Disruption Budget を考慮しません。猶予期間を設けて Pod Disruption Budget を考慮するのは、セルフマネージドの Karpenter v1.15.0 以降です。また、ARC のゾーンシフトで自動修復が停止するのは、マネージドノードグループの場合です。詳細については、 Automatically repair nodes in EKS clusters のドキュメント をご覧ください。 この一連の処理は、人手を介さずに実行されます。代替ノードは起動するとクラスターに登録され、新しいエージェントによる監視が始まり、すぐにワークロードを実行できる状態になります。 大規模な運用から得た教訓 ノードモニタリングエージェントを数千のクラスターで運用するなかで、紹介しておきたい設計原則がいくつか見えてきました。 障害を致命的なものと通知だけのものに分ける理由: PCIe バスから脱落した GPU は、再起動しない限り回復しません。この障害を Warning のままにしていたため、性能が低下したノードにワークロードがスケジュールされ続けていました。一方、帯域幅の上限は一時的なもので、ワークロードによって変わります。分類のルールは次のとおりです。どの Pod が実行されているかに関係なく障害が続き、自然に回復しない場合は、Condition 重大度として置き換えをトリガーします。ワークロードの動作によって変わる場合や、自然に解消する場合は、Event 重大度として通知にとどめます。 安全のためのしきい値を 20% にした理由: フリート全体の上限がなければ、同じ原因による誤検知で、正常なノードが数十台同時に異常と判定されるおそれがあります。不良な AMI、コントロールプレーンの一時的な不調、モニターの設定の誤りが、大量の置き換えを引き起こしかねません。上限を 20% にすることで、Karpenter が一度に終了するノードは NodePool の 5 分の 1 までになり、実際の障害は修復しながら、キャパシティの大部分を維持できます。このしきい値は Karpenter のヘルスコントローラーで固定されていて、NodePool の設定では変えられません。上限に達して修復が止まると、Karpenter はノードに NodeRepairBlocked イベントを発行し、5 分ごとに再確認します。 許容ウィンドウが異なる理由: 高速コンピューティングハードウェアの障害の許容ウィンドウが 10 分なのは、判定がはっきりしていて (バス上に GPU があるかないかのどちらか)、放置すると損失が大きいからです。カーネル、ランタイム、ネットワーキング、ストレージの障害が 30 分なのは、これらのサブシステムでは一時的な状態が自然に解消することがあるからです。ネットワークの瞬断やランタイムの一時的な再起動で、ノードを失うべきではありません。 理由コードはパブリック API として扱う: 理由コードを利用する下流のもの (修復コントローラー、ダッシュボード、お客様の自動化) はすべて、理由コードの文字列の完全一致で判定しています。v1.6.2 で、 NvidiaDeviceCountMismatch の重大度を Warning から Fatal に変更しました。技術的には妥当な判断でしたが、古い重大度を前提に修復を設定していたお客様の自動化が動かなくなりました。それ以来、理由コードの追加は機能の開発として、重大度の変更は破壊的変更として扱っています。 「Condition がない」ことを「正常」と同じに扱ってはならない: モニターが無効になっているとき、エージェントは True も Unknown も書き込まず、Condition そのものを出力しません。 True を書き込むと、エージェントが監視していないのに、ノードが正常だと自動修復に伝えてしまいます。 Unknown を書き込むと意味があいまいになり、不要な修復をトリガーするおそれがあります。何も出力しないことが、唯一の安全な選択です。 修復サイクルの実際の動作 次の例では、稼働中の Amazon EKS Auto Mode クラスターで、修復サイクルが最初から最後まで実行される様子を示します。 このクラスターには、Bottlerocket の EKS Auto Nvidia バリアントで動作する g6e.xlarge の GPU ノードがあります。GPU が正常なとき、NMA はすべてのノードの Condition を正常 (True) と報告します。 $ kubectl get node i-0981...e7d \ -o jsonpath='{range .status.conditions[*]}{.type}={.status} ({.reason}){"\n"}{end}' AcceleratedHardwareReady=True (NvidiaGPUIsReady) ContainerRuntimeReady=True (ContainerRuntimeIsReady) NetworkingReady=True (NetworkingIsReady) KernelReady=True (KernelIsReady) StorageReady=True (DiskIsReady) シリコンが実際に故障するのを待たずに GPU の障害を再現するため、ノードの DCGM ホストエンジンにダブルビット ECC エラーを注入します。DCGM ホストエンジンは、NMA がテレメトリを読み取っている情報源そのものです。EKS Auto Mode のノードは、SSH でアクセスできないマネージドインスタンスです。そこで、障害を注入するために、DCGM のツールを含む特権 Pod を実行します。 apiVersion: v1 kind: Pod metadata: name: dcgm-inject spec: nodeName: i-0981...e7d hostPID: true containers: - name: dcgm image: nvcr.io/nvidia/cloud-native/dcgm:3.3.7-1-ubuntu22.04 command: ["sleep", "3600"] securityContext: privileged: true volumeMounts: - name: dev mountPath: /dev volumes: - name: dev hostPath: path: /dev tolerations: - operator: Exists この Pod がホストの DCGM エンジンと通信するには、 privileged: true と hostPID: true が必要です。Pod が起動したら、exec で Pod に入り、障害を注入します。 $ kubectl exec dcgm-inject -- dcgmi test --inject --gpuid 0 -f 319 -v 4 Successfully injected field info. NMA は数秒後の次のポーリングでこのエラーを検出し、Condition を False に切り替えます。 $ kubectl get node i-0981...e7d -o jsonpath='{range .status.conditions[?(@.type=="AcceleratedHardwareReady")]}{.status} {.reason}: {.message}{"\n"}{end}' False NvidiaDoubleBitError: detected 4 Nvidia Double Bit error(s) on location Device エージェントは、この Condition の切り替えをノードのイベントとして記録します。Karpenter が監視しているのは、このシグナルです。 $ kubectl get events --field-selector involvedObject.name=i-0981...e7d ... AcceleratedHardwareReady Status condition transitioned, Type: AcceleratedHardwareReady, Status: True -&gt; False, Reason: NvidiaDoubleBitError, Message: detected 4 Nvidia Double Bit error(s) on location Device ここから先は、誰も何も操作しません。Condition が False になってから 10 分後 (高速コンピューティングハードウェアの許容ウィンドウ)、Karpenter が自動で修復を始めます。異常なノードをドレインしながら、代替ノードを起動します。 $ kubectl get nodeclaims NAME TYPE ZONE NODE READY gpu-demo-fdthm g6e.xlarge us-west-2c Unknown # 代替ノード、起動中 gpu-demo-xfqcb g6e.xlarge us-west-2b i-0981...e7d True # 異常、ドレイン中 数分後には、異常なノードはなくなり、新しいノードが代わりに稼働して、ワークロードが再び実行されています。 $ kubectl get node i-0bb2...fb4 -o jsonpath='{range .status.conditions[?(@.type=="AcceleratedHardwareReady")]}{.status} {.reason}{"\n"}{end}' True NvidiaGPUIsReady $ kubectl get pods -l app=gpu-demo -o wide NAME READY STATUS NODE gpu-demo-workload-...-j97n5 1/1 Running i-0bb2...fb4 障害を 1 回注入すると、数秒で Condition が切り替わり、意図して設けた 10 分の許容ウィンドウの後、およそ 90 秒で再プロビジョニングとクラスターへの再参加が終わります。最初から最後まで、人手は要りません。 リソースのクリーンアップ 手順を試した後は、テスト用のリソースを削除します。 kubectl delete pod dcgm-inject SSH を使わない診断: ノードに障害が起きた原因を調べる 自動修復が対応するのは、よくあるケースです。異常なノードは置き換えられ、ワークロードは動き続けます。しかし、ノードに障害が起きた 原因 を知る必要がある場合もあります。同じ障害が繰り返し起きている場合や、サポートケースで証拠が必要な場合です。 従来の EKS ノードで診断情報を集めるには、ノードに SSH でアクセスし、ログ収集のスクリプトを手作業で実行する必要がありました。NodeDiagnostic カスタムリソース定義 (CRD) は、この方法に代わる手段です。SSH でのアクセスはコンプライアンス上禁止されていることが多く、ネットワークに障害があると使えません。EKS Auto Mode では、この方法はまったく使えません。Auto Mode のノードは、設計上 SSH でアクセスできない Amazon Elastic Compute Cloud (Amazon EC2) マネージドインスタンスだからです。これらのノードで何が起きたかを知る手段は、NodeDiagnostic CRD と kubectl ekslogs だけです。 kubectl ekslogs の仕組み kubectl-ekslogs プラグイン は、NodeDiagnostic の一連の手順を 1 つのコマンドにまとめたものです。 $ kubectl ekslogs i-0abc123def456 ✔ Transfer mode: node proxy API ⟳ Validating node(s)... ✔ 1 node validated ⟳ Creating NodeDiagnostic resources... ⟳ Waiting for log collection to complete (timeout: 300s)... ✔ Log collection completed on 1 node ⟳ Downloading log bundles... ✔ Saved: ./i-0abc123def456-logs.tar.gz (288K) ✔ Done: 1 log bundle downloaded to ./ 内部的には、このプラグインは次の処理を行います。 ノード名と destination: node を指定して、 NodeDiagnostic カスタムリソースを作成します。 対象のノードで動くエージェントが、Kubernetes の watch でそのリソースを検出します。 エージェントが、システムログ、カーネルメッセージ、ネットワーキングの状態、ランタイムの診断情報を集め、圧縮した tarball にまとめます。 エージェントが、tarball をノードに一時的に保存します (10 分間取得可能)。 プラグインが、kubelet の Node Log Query API (KEP-2258、Kubernetes 1.36 で一般提供) を使って tarball をダウンロードします。 SSH も、セキュリティグループの変更も、キーペアも必要ありません。シェルでアクセスできない Auto Mode のマネージドインスタンスでも使えます。 ログを kubelet API 経由でストリーミングせずに Amazon Simple Storage Service (Amazon S3) に保存したい場合は、NodeDiagnostic の宛先に S3 の署名付き PUT URL を指定します。手順は ノードログの取得のドキュメント で順を追って説明しています。同じ仕組みで ネットワークトラフィックをキャプチャ することもできます。エージェントがノードで tcpdump を実行し、キャプチャファイルを圧縮して、指定したバケットにアップロードします。 検出と診断は別々の役割 このアーキテクチャでは、検出と診断を意図的に分けています。検出は「このノードは正常か」に答えるもので、最小限のオーバーヘッドで常に動作し、ノードの Condition を書き込みます。診断は「何が問題だったのか」に答えるもので、必要なときにだけ動作し、NodeDiagnostic を通じて詳細な情報を集めます。検出と診断は同じエージェントのバイナリで動きますが、結果を使う相手が違います。検出の結果は修復サイクルが使います。診断の結果は、事後に原因を調べる人が使います。 役割を分けているので、検出が証拠集めのために遅くなることはなく、診断を常に動かしておく必要もありません。自動修復がすでに異常と判定したものの、まだ終了していないノードを診断することもできます。 EKS Auto Mode で得られるもの ノードのヘルスモニタリングは、Auto Mode の AMI に組み込まれている機能の 1 つです。全体像は Auto Mode のアーキテクチャの記事 で紹介しています。この記事で説明した機能は、すべてデフォルトで有効です。必要に応じて用意するのは、手元の端末にインストールする診断ツールだけです。 必要なときに診断するには、 kubectl-ekslogs プラグイン をインストールし、 kubectl ekslogs &lt;node-name&gt; を実行して、ログ一式を取得します。ネットワークのキャプチャには、宛先に tcpdump を指定した NodeDiagnostic リソースを作成します。 EKS Auto Mode 以外のコンピューティングでは、同じ仕組みを自分で構成できます。ノードモニタリングエージェントを EKS アドオン としてインストールし、バージョンを最新に保ち、ノードグループごとに修復にオプトインします。インストールとオプトインの手順は、 ノードモニタリングと自動修復のドキュメント で説明しています。 まとめ この記事では、Amazon EKS Auto Mode が人手を介さずにノード障害を検出、修復、診断する仕組みを紹介しました。ノードモニタリングエージェントは低レベルの障害を Kubernetes のノードの Condition に変換し、Karpenter はその Condition に基づいてノードを置き換えます。両者の間の取り決めはノードの Condition だけで、ノードの Condition はごく普通の Kubernetes の仕組みにすぎません。だからこそ、このサイクルは信頼できます。修復を実行するかどうかは重大度で決まります。Condition 重大度の検出は置き換えをトリガーし、Event 重大度の検出は通知にとどまり、ノードは稼働を続けます。 このシステムは、すぐに反応するのではなく、意図的に慎重に動くように作られています。許容ウィンドウによって一時的な障害が自然に解消するのを待ち、フリート全体の安全のためのしきい値によって、同じ原因の障害が拡大するのを防ぎます。また、理由コードをパブリック API として扱うので、理由コードを前提に作った自動化が知らないうちに動かなくなることはありません。そして、ノードに障害が起きた原因を知りたいときは、NodeDiagnostic CRD と kubectl ekslogs で、Kubernetes API を通じてログ一式を取得できます。SSH は不要で、ログインできないマネージドインスタンスでも使えます。 EKS Auto Mode では、これらはどれも、自分で有効にする機能ではありません。アドオンも、オプトインのフラグも、管理するバージョンもありません。検出、修復、診断は、AWS がお客様に代わって運用するデータプレーンのライフサイクルの一部で、クラスターを作成したときから有効です。 EKS Auto Mode がコンピューティングを管理するので、お客様はワークロードに時間を使えます。また、 ノードモニタリングエージェントはオープンソース なので、お客様が大規模な運用で遭遇した障害モードを、プルリクエストで新しい検出に直接反映できます。 関連情報 詳解: Amazon EKS Auto Mode (アーキテクチャの概要)。 Amazon EKS introduces node monitoring and auto-repair (提供開始の発表)。 ノードのヘルス問題を検出し、自動ノード修復を有効にする (Amazon EKS ユーザーガイド)。 kubectl と S3 を使用してマネージドノードのノードログを取得する 。 kubectl と S3 を使用して、マネージドノード上のネットワークトラフィックをキャプチャする 。 kubectl-ekslogs プラグイン 。 EKS Node Monitoring Agent (GitHub) 。 Karpenter provider-aws (GitHub) 。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

本ブログは 2026 年 10 月 21 日に公開された AWS Blog “ Using AWS WAF to apply mitigations for PHP2Shell RCE vulnerabilities (CVE-2026-109618 and CVE-2026-109619) ” を翻訳したものです。 2026 年 10 月 21 日、PHP プロジェクトは、PHP コアランタイムに存在する 2 件の重大なリモートコード実行 (RCE) 脆弱性に対して 緊急の修正をリリース しました。これらの脆弱性は CVE-2026-109618 および CVE-2026-109619 として追跡されており、総称して PHP2Shell と呼ばれています。いずれも CVSS v4.0 で 9.2 (Critical: 緊急) と評価されており、認証されていない攻撃者が脆弱なサーバー上でコードを実行できます。修正済みのリリースは PHP 8.5.12、8.4.27、8.3.36、8.2.35 です。 完全な修正はパッチ適用以外になく、PHP のアップグレードを最優先で進める必要があります。ただし、サーバーのフリート全体へのパッチ適用には時間がかかります。PHP が稼働している場所の棚卸し、メンテナンスウィンドウの調整、新しいビルドでのアプリケーションのテストが必要になるためです。本記事では、 AWS WAF を使用して、パッチ適用が完了するまでの間、確認済みの攻撃経路への露出を低減する方法を紹介します。ブロックすべきリクエストパターン、AWS WAFv2 でのルールの記述方法、正当なトラフィックに影響を与えずにルールをデプロイする方法を説明します。また、誤った安心感を抱かないよう、AWS WAF による保護の限界についても説明します。Amazon の脅威インテリジェンスが脆弱性の公表前に PHP2Shell の悪用をどのように検出したかについては、「 Amazon Threat Intelligence が PHP2Shell の脆弱性公開前の悪用を MadPot で特定 」を参照してください。AWS サービスの状況と AWS が推奨する AWS WAF ルールについては、「 AWS Security Bulletin 2026-143-AWS 」を参照してください。 重要: 完全な修正はパッチ適用以外になく、PHP のアップグレードを最優先で進める必要があります。 脆弱性の概要 PHP2Shell の 2 つの脆弱性はいずれも認証不要の RCE であり、アプリケーションコードが実行される前に PHP が multipart/form-data リクエスト (ブラウザがファイルアップロードに使用するリクエスト形式) を処理する方法に起因しています。そのため、本記事の AWS WAF ルールでは、multipart トラフィック、リクエスト本文のサイズ、セッションアップロード進捗 (session upload progress) フィールドに焦点を当てています。大まかに言えば、CVE-2026-109618 は、リクエストの処理中に PHP がメモリ不足 (out-of-memory) に陥った際にメモリ破壊を引き起こします。CVE-2026-109619 は、あるリクエストが残した古いデータを、同じワーカープロセス上の後続のリクエストが再利用してしまう脆弱性です。根本原因の分析、影響を受けるバージョン、PHP プロジェクト自身のガイダンスについては、PHP の公式アドバイザリとリリースアナウンスを参照してください。 CVE-2026-109618 (メモリ不足によるメモリ破壊) – PHP アドバイザリ GHSA-w8hw-w9fx-j79w CVE-2026-109619 (古いグローバル状態: stale global state) – PHP アドバイザリ GHSA-6wmf-4rv5-p3rp PHP セキュリティリリースのアナウンス (2026 年 10 月 21 日) 対応策における AWS WAF の位置付け 今回のケースでは、AWS WAF は多層防御のための制御であり、PHP のアップグレードに代わるものではありません。PHP のアドバイザリでも、パッチ適用済みのリリースへの更新が唯一の完全な緩和策であると明言されています。後述するとおり、2 つの脆弱性のうち 1 つは、その大部分がウェブアプリケーションファイアウォールでは対処できない範囲にあります。本記事のルールは、パッチ適用が完了するまでの間の露出を低減する緩和策として扱い、パッチ適用後は削除するか、補助的な制御として維持してください。 AWS WAF はエッジで HTTP リクエストを検査します。multipart 本文の内部構造は解析せず、PHP ワーカーのメモリやサーバー側の設定も把握できません。次の表に、各攻撃要素に対して AWS WAF が緩和策として機能するかどうかを示します。 攻撃要素 AWS WAF の対応範囲 multipart POST に含まれるセッションアップロード進捗フィールド ( PHP_SESSION_UPLOAD_PROGRESS 、PHP のアップロード追跡機能を有効にするフォームフィールド) 対応可能。このフィールドを含むリクエストを対象としたルールでブロックできます。 multipart アップロード経路 ( multipart/form-data 、ファイルアップロードに使用されるリクエストタイプであり、両方の脆弱性の侵入口) 対応可能。ただし、アプリケーションに正当な multipart アップロードがない場合に限ります。ブロック対象: multipart/form-data. サイズ超過の本文によるメモリ不足状態 一部対応。リクエスト本文のサイズに上限を設定します。ただし、上限内に収まるヘッダー増幅 (header amplification: 多数の小さなパートヘッダーにより、送信時のサイズをはるかに上回るメモリが消費されるもの) は検出できません。 同じワーカー (多数のリクエストの処理に再利用される PHP プロセス) に対する繰り返しの試行 対応可能。レートベースのルールにより、エクスプロイトに必要な大量のリクエスト送信を抑制できます。 プロデューサー (producer) として機能する fatal_error_backtraces (リクエストをまたいでクラッシュトレースの状態を保持する PHP 8.5 の設定) 対応不可。これはサーバーの構成設定です ( fatal_error_backtraces=0 )。 コンシューマー (consumer) として機能する、無効または非推奨の INI 設定に関する診断 (不正な構成設定の適用時に PHP が出力する警告) 対応不可。この経路はクライアントからの HTTP 通信ではなく、サーバー側で実行されます。 アプリケーションが multipart アップロードを受け付けない場合は、 multipart/form-data をブロックするルールをエッジに適用することで、あらゆるアプリケーションに対して悪用可能な、multipart 処理でメモリ不足を引き起こす攻撃経路と、セッションアップロード進捗のトリガーを排除できます。これは、パッチ適用期間中の多層防御として機能します。 アプリケーションで multipart アップロードを使用している場合、AWS WAF でリスクは低減できますが、脆弱性を解消することはできません。ヘッダー増幅 (数キロバイトのパートヘッダーが、PHP 内部ではるかに大きなメモリに展開されるもの) はサイズ制限内に収まるうえ、ファイアウォールは本文の各パート内にあるヘッダーを解析できないためです。この場合は、PHP のアップグレードを優先し、後述するサーバー側の緩和策を適用してください。 AWS WAF ルールの実装 以下のルールは AWS WAFv2 の JSON 形式です。各ルールを、PHP ワークロードの前段にある Amazon CloudFront ディストリビューション、Application Load Balancer、または Amazon API Gateway ステージに関連付けられた AWS WAF 保護パック (ウェブ ACL) にデプロイしてください。 重要: 変更を実装する前に、AWS WAF のログ記録に関するガイダンスに沿って WAFv2 のログ記録が設定されていることを確認してください。すべてのルールはまず Count モードで開始し、正当なトラフィックに一致しないことを確認してから Block に切り替えてください。 リクエスト本文の検査サイズ制限 AWS WAF は、リクエスト本文を一定のサイズまで検査します。Application Load Balancer と AWS AppSync では、この制限は 8 KB で固定されています。CloudFront や API Gateway などの AWS サービスでは、デフォルトは 16 KB で、以下のようにウェブ ACL の AssociationConfig を使用して 32、48、または 64 KB に引き上げることができます。本文検査サイズ制限を超えた部分は、サイズ超過として扱われます。本文サイズのルールで適用できる上限は検査対象のサイズまでであるため、デプロイするルールに合わせて制限を選択してください。 aws wafv2 update-web-acl ... --association-config \ 'RequestBody={CLOUDFRONT={DefaultSizeInspectionLimit=KB_16}}' AWS WAF ルール このルールは両方の CVE を対象とし、 AndStatement 内の 3 つの条件すべて が同時に満たされた場合にのみリクエストをブロックします。 メソッドが POST と完全に一致する – HTTP メソッドで照合 (変換なし) PHP のセッション識別子が存在する (ネストされた OrStatement により、次のいずれかのサブ条件を満たせば成立) PHPSESSID が Cookie のキーとして存在する (すべての Cookie を対象に、キーを完全一致で照合)、または PHPSESSID がリクエスト本文のいずれかの場所に存在する (部分一致) 本文に PHP_SESSION_UPLOAD_PROGRESS が含まれる – PHP のセッションアップロード進捗機能を有効にするフォームフィールド このルールと併せて、サーバー側で session.upload_progress.enabled=0 を設定し、この機能を無効にしてください。 { "Name": "PHP2Shell", "Priority": 0, "Statement": { "AndStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "POST", "FieldToMatch": { "Method": {} }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "EXACTLY" } }, { "OrStatement": { "Statements": [ { "ByteMatchStatement": { "SearchString": "PHPSESSID", "FieldToMatch": { "Cookies": { "MatchPattern": { "All": {} }, "MatchScope": "KEY", "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "EXACTLY" } }, { "ByteMatchStatement": { "SearchString": "PHPSESSID", "FieldToMatch": { "Body": { "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } ] } }, { "ByteMatchStatement": { "SearchString": "PHP_SESSION_UPLOAD_PROGRESS", "FieldToMatch": { "Body": { "OversizeHandling": "CONTINUE" } }, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ], "PositionalConstraint": "CONTAINS" } } ] } }, "Action": { "Block": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2Shell" } } 検討すべきその他の AWS WAF ルール アプリケーションでアップロードを使用しない場合に multipart リクエストをブロックする 注: このルールを Block モードで実装すると、ファイルアップロードを必要とするアプリケーションが動作しなくなります。アプリケーションでファイルアップロードが不要な場合は、 multipart/form-data をブロックすることで、両方の CVE について、あらゆるアプリケーションに対して悪用可能な、multipart 処理でメモリ不足を引き起こす攻撃経路をエッジで排除できます。 名前を指定した単一のヘッダーは 8 KB のヘッダー上限の対象外で、全体が検査されます。そのため、 Content-Type ヘッダーでの照合は確実に機能します。 { "Name": "Block-Multipart-FormData", "Priority": 1, "Action": { "Count": {} }, "Statement": { "ByteMatchStatement": { "FieldToMatch": { "SingleHeader": { "Name": "content-type" } }, "PositionalConstraint": "CONTAINS", "SearchString": "multipart/form-data", "TextTransformations": [ { "Priority": 0, "Type": "LOWERCASE" } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellBlockMultipart" } } リクエスト本文のサイズに上限を設定する 本文サイズに上限を設定すると、CVE-2026-109618 の原因となるメモリ不足状態と、それによって残る可能性のある古い状態を抑制できます。サイズ制約と併せて OversizeHandling: MATCH を使用すると、本文検査サイズ制限を超える本文も含め、しきい値より大きい本文をすべてブロックできます。N バイトの上限を適用するには、ウェブ ACL の本文検査サイズ制限を N 以上にする必要があります。なお、サイズ制約で Content-Length の数値に上限を設定することはできません。サイズ制約が測定するのはヘッダー値の文字列の長さであり、値が表す数値ではないためです。アプリケーションに正当な大容量アップロードがある場合は、URI パスに対する AndStatement を使用して、このルールの対象をアップロード以外のパスに限定してください。限定しない場合、それらのアップロードが動作しなくなります。 { "Name": "Block-Oversize-Body", "Priority": 3, "Action": { "Count": {} }, "Statement": { "SizeConstraintStatement": { "FieldToMatch": { "Body": { "OversizeHandling": "MATCH" } }, "ComparisonOperator": "GT", "Size": 8192, "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellBlockOversizeBody" } } 注: AWSManagedRulesCommonRuleSet マネージドルールグループを既に使用している場合、そのグループに含まれる SizeRestrictions_BODY ルールが、デフォルトで 8 KB を超える本文をブロックします。特定のマネージドルールが正当なトラフィックに影響する場合は、グループ全体を無効にするのではなく、そのルールのみを Count にオーバーライドしてください。 繰り返しの試行をレート制限する POST リクエストにレートベースのルールを適用すると、攻撃者が送信できるリクエスト量を抑え、ワーカーへの過負荷によって脆弱性がトリガーされる可能性を下げることができます。また、古い状態を悪用する経路が成立するには、プロデューサーのリクエストとコンシューマーのリクエストが同じワーカーに到達する必要があります。このルールは、リクエストごとにワーカーをリサイクルするサーバー設定 pm.max_requests=1 を補完するものです。 { "Name": "RateLimit-Posts", "Priority": 4, "Action": { "Count": {} }, "Statement": { "RateBasedStatement": { "Limit": 100, "EvaluationWindowSec": 60, "AggregateKeyType": "IP", "ScopeDownStatement": { "ByteMatchStatement": { "FieldToMatch": { "Method": {} }, "PositionalConstraint": "EXACTLY", "SearchString": "POST", "TextTransformations": [ { "Priority": 0, "Type": "NONE" } ] } } } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "PHP2ShellRateLimitPosts" } } AWS WAF を補完するサーバー側の緩和策 以下のホストとランタイムの変更は、ウェブアプリケーションファイアウォールが検査する HTTP レイヤーより下にある CVE-2026-109619 の要素に対処するものです。そのため、これらの要素は、そもそもファイアウォールの対象範囲外にあります。防御におけるホストおよびランタイムのレイヤーとして、AWS WAF ルールと併せて適用してください。 PHP を 8.5.12、8.4.27、8.3.36、または 8.2.35 にアップグレードします。 これが唯一の完全な修正です。PHP 8.1 以前はアップストリームでのサポートが終了しています。ディストリビューションまたは長期サポートベンダーにバックポートされた修正があるかを確認するか、サポート対象のブランチへの移行を計画してください。 PHP レベルで CVE-2026-109618 に対処します。 アプリケーションが上書きできないように memory_limit=-1 を設定し、post_max_size は小さい値に抑えます (アプリケーションがアップロードを受け付けない場合は 8M、受け付ける場合は 32M)。メモリの上限はコンテナまたは cgroup の制限で適用してください。RLIMIT_AS や RLIMIT_DATA は脆弱なメモリ不足経路をトリガーするため、決して使用しないでください。 PHP 8.5 で fatal_error_backtraces=0 を設定し、すべてのワーカーを再起動します。 これにより、リクエストをまたいでクラッシュトレースの状態を保持する設定が無効になります。この設定は、脆弱性をトリガーする方法として確認されているものの 1 つです。 サーバー側で session.upload_progress.enabled=0 を設定し、すべてのワーカーを再起動します。 これにより、もう 1 つの確認済みのトリガーであるアップロード追跡機能が無効になります。この機能は、パッチ適用後も無効のままにしておくことをお勧めします。 設定には php.ini 、FPM プール、またはサーバー起動時の構成を 、リクエストごとの INI オーバーライド (リクエスト単位で設定を適用する .htaccess 、 php_value 、または FastCGI の PHP_VALUE) よりも優先して使用してください。また、診断警告が発生しないよう、廃止されたディレクティブは削除してください。 致命的なエラーと実行タイムアウトを解消します。 対象は、アップロード、インポート、エラーページ、シャットダウン、シリアル化、拡張機能のパスなど、攻撃者が到達可能なルートです。 パフォーマンス上問題がなければ、 pm.max_requests=1 を設定します。 これにより、各ワーカープロセスは 1 つのリクエストを処理するたびにリサイクルされ、古いデータを残すリクエストと、そのデータを再利用する後続のリクエストとのつながりが断たれます。 エラーログ記録を有効にします ( log_errors=On 、有効な出力先を指定した error_log 、 error_reporting=E_ALL )。そのうえで、Apache、FPM、またはプロキシのログを確認し、攻撃者が制御可能なルートで警告、非推奨の通知、致命的なエラー、タイムアウトが繰り返し発生していないかを調べてください。エラーが出ていないからといって、安全であるとは限りません。 開始方法 次の手順で対応を開始してください。 PHP が稼働している場所と、使用中のバージョンおよびサーバー API (mod_php、FPM、FrankenPHP、LSAPI) を棚卸しします。また、リクエスト本文を受け付けるパブリックエンドポイントを特定します。 各アプリケーションが multipart アップロードを使用しているかどうかを確認します。これにより、multipart リクエストをブロックする AWS WAF ルールをデプロイできるかどうかが決まります。 各 PHP ワークロードの前段にあるウェブ ACL を作成または更新し、該当するルールを Count モードで追加します。ルールで必要な場合は、CloudFront または API Gateway の本文検査サイズ制限を引き上げます。 各ルールのサンプリングされたリクエストと Amazon CloudWatch メトリクスを監視し、正当なアップロードや大容量の JSON 本文を含む POST リクエストがルールに一致していないことを確認します。 メトリクスに問題がなければ、ルールを Block に切り替えます。セッションアップロード進捗フィールドのルールと multipart ルールが、本文サイズルールとレートベースのルールより先に評価されるよう、優先度を設定します。 無害な multipart/form-data の POST、設定したサイズ上限を超える本文、 PHP_SESSION_UPLOAD_PROGRESS を含むリクエストでテストします。403 レスポンスが返され、一致したルールのメトリクスが記録されることを確認します。 並行して、PHP のアップグレードと構成の緩和策を適用します。フリートへのパッチ適用が完了したら、AWS WAF ルールを削除するか、補助的な制御として維持します。 まとめ PHP2Shell 脆弱性 (CVE-2026-109618 および CVE-2026-109619) は、アプリケーションコードが実行される前の段階で PHP に到達する、認証不要の RCE 脆弱性です。AWS WAF は、パッチ適用期間中のアタックサーフェスの縮小に役立ちます。具体的には、セッションアップロード進捗フィールドのブロック、アップロードが想定されない場合の multipart リクエストのブロック、リクエスト本文サイズの上限設定、繰り返しの試行のレート制限です。これらの緩和策は露出の低減に役立ちますが、脆弱性そのものを解消するものではありません。PHP を修正済みのリリースにアップグレードし、サーバー構成の変更を適用してください。AWS WAF ルールは修正そのものではなく、それらの修正を支えるエッジのレイヤーとして位置付けてください。 ここで使用したルールタイプの詳細については、AWS WAF ドキュメントの ウェブ ACL の本文検査サイズ制限 、 サイズ超過のリクエストコンポーネントの処理 、および サイズ超過の HTTP リクエスト本文の処理 に関するページを参照してください。脆弱性の詳細については、PHP アドバイザリ GHSA-w8hw-w9fx-j79w および GHSA-6wmf-4rv5-p3rp 、PHP の セッションアップロード進捗のマニュアル を参照してください。 Alex Waddell Alex Waddell は、AWS の Worldwide Specialist Organization でセキュリティを専門とする Principal Solutions Architect で、スコットランドを拠点としています。1999 年からセキュリティ分野に携わり、2021 年に AWS に入社しました。EMEA 全域のお客様とともに、クラウドセキュリティアーキテクチャ、アイデンティティ、脅威検出、アプリケーションセキュリティに取り組んでいます。仕事以外では、世界各地のラム酒の飲み比べ (Alex はウイスキーを好まない珍しいスコットランド人の 1 人です)、地元の森の小道での犬の散歩、旅行を楽しんでいます。 Lawton Pittenger Lawton は、ニューヨーク市を拠点とする AWS の Worldwide Security Specialist Solutions Architect です。効果的なネットワークセキュリティ制御の設計と実装について、お客様を支援することを専門としています。AWS では、幅広いお客様と協力するとともに、サービスチームと緊密に連携し、お客様のニーズとフィードバックに基づいてセキュリティサービスの継続的な改善を推進しています。仕事以外では、スケートボード、スノーボード、自然の中で過ごすことを楽しんでいます。 Ian Olson Ian は AWS の Senior Security Specialist Solutions Architect です。お客様がセキュリティサービスを自動化し、DDoS やウェブの脆弱性を悪用した攻撃などの脅威から環境を保護できるよう支援しています。インテリジェントオートメーションを通じて、あらゆる規模の組織に合わせたセキュリティソリューションを提供しています。仕事以外では、2 人の幼い子どもと過ごす時間を大切にしています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2026 年 10 月 21 日に公開された AWS Blog “ Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot ” を翻訳したものです。 Amazon Threat Intelligence は、MadPot のテレメトリから、2026 年 10 月 17 日に PHP2Shell の悪用の試みがあったことを特定しました。これは CVE-2026-109618 と CVE-2026-109619 が一般に公開される 4 日前のことです。この悪用の試みは、商用の匿名化ネットワークに関連する IP アドレスから行われていました。この脆弱性に関する情報がエンバーゴ (公開制限) の対象となっていた間に、匿名化された IP アドレスからハニーポットが標的にされました。このことから、このアクティビティは脅威アクターによるものと考えられます。ただし、このアクターが公開前にどのようにエクスプロイトの情報を入手したのかは、原文公開時点ではまだ不明でした。 PHP のエンバーゴは、2026 年 10 月 21 日 14:00 (UTC、日本時間同日 23:00) に解除される予定でした。解除当日、Amazon Threat Intelligence はこの脆弱性に対する複数の概念実証エクスプロイトを特定しました。最も早いものは 2026 年 10 月 21 日 2:00 (UTC、日本時間同日 11:00) ごろに確認されています。その後、2026 年 10 月 21 日 2:00 から 8:00 (UTC、日本時間同日 11:00 から 17:00) までの間にも、Amazon Threat Intelligence は、別の匿名化インフラストラクチャから MadPot を標的とした PHP2Shell の悪用の試みを新たに特定しました。実際のペイロードや使用された匿名化インフラストラクチャはそれぞれ異なっており、複数のアクターによるものであることが示唆されています。2026 年 10 月 21 日の原文公開時点では技術的な分析が継続中で、これらの試みが実環境のシステムでも成功し得るものだったかどうかは明らかになっていませんでした。 エンバーゴが実際に解除されたのは、2026 年 10 月 21 日 14:00 (UTC、日本時間同日 23:00) でした。エンバーゴの解除とパッチのリリース後、数時間以内に新たな概念実証エクスプロイトが登場しました。AWS は、それらがほぼ直ちに自社のセンサーに対して使用されたことを確認しました。原文公開時点で、PHP2Shell は既に実環境で広く悪用されていました。 今回の事例から得られた 2 つの教訓は、この脆弱性に限らず広く当てはまります。 エンバーゴが防御側を守れるのは、他の誰かが同じバグを発見するまでの間だけです。協調的開示 (Coordinated Disclosure) は、引き続き適切なモデルです。しかし防御側は、公開日が悪用の始まった最も早い日であると想定すべきではありません。PHP2Shell の場合、アドバイザリの公開よりも前に侵害が発生していた可能性があります。 パッチのリリースから実際に動作するエクスプロイトが登場するまでの時間は、構造的な理由で短くなっています。これまで AWS が観測してきた悪用の大半は、概念実証が公開された後に発生していました。高い能力を持つ少数のアクターがエクスプロイトを作成し、それ以外のアクターはその公開を待つという構図でした。しかし、この依存関係は弱まりつつあります。AI を活用した分析によって、パッチの差分やアドバイザリから実際に動作するエクスプロイトを作成するコストが下がっています。その結果、脆弱性の技術的な詳細が公開されると、より多くのアクターが数時間、場合によっては数分以内に行動を起こせるようになっています。 セキュリティリーダーにとっては、これにより実務上のいくつかの前提が変わります。 インターネットに公開されたシステムの重大な脆弱性については、パッチ適用と緩和策のタイムラインを時間単位で管理してください。7 日間や 30 日間の SLA は、もはや存在しない猶予を前提としています。 調査は公開日からではなく、既知の最も早い悪用の時点から開始してください。PHP2Shell については、少なくとも 2026 年 10 月 17 日以降を調査対象としてください。 特定の CVE 向けのシグネチャに依存しない検出に投資してください。多くの場合、最初の悪用はそうしたシグネチャが作成される前に発生します。 AWS がお客様を保護する仕組み AWS は、お客様の保護に役立つ多層的な防御策を導入しています。AWS 社内の脅威インテリジェンスシステムは、この脆弱性を標的とした悪意のあるスキャンを自動的に検出し、その活動を制限しました。AWS は、毎分 2,000 億件を超えるイベントの分析と、MadPot ハニーポットネットワークから得た脅威インテリジェンスの統合によって、既知の悪用の試みをリアルタイムで特定し、ブロックしています。このハニーポットシステムによって悪用の試みを早期に検出できるため、迅速な対応と脅威分析が可能になります。 直ちに実施すべき推奨対策 脆弱性が修正された PHP バージョンに直ちにアップグレードしてください。CVE-2026-109618 と CVE-2026-109619 の両方を完全に修正する唯一の方法は、アップグレードです。設定変更だけで両方の問題に完全に対処できる回避策はありません。 直ちにパッチを適用できない PHP 環境では、マルチパートファイルアップロードのブロックを検討してください。ただし、導入する前に、アプリケーションへの影響を確認してください。 フォームアップロードで、PHP_SESSION_UPLOAD_PROGRESS 文字列を含む POST リクエストがないか確認してください。 ウェブサーバーのログに不審なアクティビティがないか確認してください。 ウェブアプリケーションサーバーで、予期しないプロセスの実行やファイルの変更がないか確認してください。 侵害指標 (IOC) IP アドレス 観測日 103.216.220.92 2026/10/17 31.223.184.166 2026/10/21 37.19.200.5 2026/10/21 134.209.159.64 2026/10/21 103.114.163.188 2026/10/21 95.217.98.37 2026/10/21 特定された IP アドレスには共有の匿名化インフラストラクチャのアドレスが含まれており、今回の脅威アクティビティだけに使用されているわけではありません。これらのアドレスが観測された場合は、ブロックするのではなく調査することをお勧めします。 ご質問がある場合は、 AWS re:Post で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。CJ はこの役職で、Amazon 全体のセキュリティエンジニアリングとオペレーションを統括しています。CJ の使命は、セキュリティのメリットを最も手間なく得られるようにすることで、Amazon の各事業を支援することです。CJ は 2007 年 12 月に Amazon に入社し、Consumer CISO、直近では AWS CISO などのさまざまな役職を歴任した後、2023 年 9 月に Amazon Integrated Security の CISO に就任しました。 CJ は Amazon に入社する前、米国連邦捜査局のサイバー部門で、コンピュータおよびネットワークへの侵入に関する技術分析を統括していました。また、米国空軍特別捜査局 (AFOSI) の特別捜査官も務めました。今日のセキュリティ業界の基礎とみなされている複数のコンピュータ侵入捜査を指揮した実績もあります。 CJ はコンピュータサイエンスと刑事司法の学位を持ち、SRO GT America の GT2 クラスに参戦する現役のレーシングドライバーでもあります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 11 月 25 日に公開された AWS Blog “ Introducing guidelines for network scanning ” を翻訳したものです。 Amazon Web Services (AWS) は、お客様のワークロードを対象としたネットワークスキャンのガイドラインを導入します。ガイドラインに準拠したスキャナーは、より正確なデータを収集でき、不正利用として報告されることも最小限に抑えられます。さらに、すべての人にとってのインターネットのセキュリティ向上にも貢献できます。 ネットワークスキャンは、現代の IT 環境で用いられる手法です。正当なセキュリティ目的で使われることもあれば、悪意のある活動に悪用されることもあります。正当な用途としては、組織がネットワークスキャンを実施して、資産の正確なインベントリを維持し、セキュリティ設定を検証します。また、対応が必要な潜在的な脆弱性や古いバージョンのソフトウェアを特定します。セキュリティチーム、システム管理者、認可を受けたサードパーティのセキュリティ研究者にとって、スキャンはセキュリティポスチャのデータを収集するための標準的なツールの 1 つです。一方で、スキャンは脅威アクターも実行しており、システムの列挙、弱点の発見、攻撃に向けた情報収集に利用されています。正当なスキャン活動と潜在的に有害な偵察を見分けることは、セキュリティ運用における絶え間ない課題です。 スキャンによって特定のシステムでソフトウェアの脆弱性が見つかる場合、そのスキャナーが善意に基づいてスキャンしていることが特に重要です。ソフトウェアの脆弱性が脅威アクターに発見され、攻撃に悪用されると、組織の IT システムへの不正アクセスにつながるおそれがあります。組織は、ランサムウェア、データ窃取、運用上の問題、規制上の罰則から自らを守るため、ソフトウェアの脆弱性を効果的に管理する必要があります。その一方で、NIST National Vulnerability Database のデータが示すとおり、既知の脆弱性の数は過去 10 年間、年率 21% のペースで急速に増加しています。 こうした状況を踏まえ、ネットワークスキャナーには、スキャンの実施と収集したセキュリティデータの管理を慎重に行うことが求められます。セキュリティデータに関心を持つ関係者はさまざまで、グループごとにデータの使い方も異なります。セキュリティデータが脅威アクターに発見されて悪用されると、システムの侵害、ランサムウェア、サービス拒否によって、システム所有者に業務の混乱やコストが生じる可能性があります。エネルギー、製造、ヘルスケア、政府、教育、金融、運輸の各分野で重要なサービスを提供するデータセンターやネットワークに接続されたソフトウェアワークロードは、指数関数的に増加しています。そのため、セキュリティデータが悪意のある者の手に渡った場合、現実世界に重大な影響を及ぼすおそれがあります。 複数の関係者 セキュリティデータには複数の関係者が利害を持っています。少なくとも次のようなグループが挙げられます。 組織は、資産を保護するため、資産インベントリを把握し、脆弱性に迅速にパッチを適用したいと考えています。 プログラム監査人は、組織がインフラストラクチャを管理するための堅牢な統制を整備している証拠を求めています。 サイバー保険会社は、組織のセキュリティポスチャのリスク評価を求めています。 デューデリジェンスを実施する投資家は、組織のサイバーリスクプロファイルを把握したいと考えています。 セキュリティ研究者は、リスクを特定して組織に通知し、対策を促したいと考えています。 脅威アクターは、不正アクセスを目的として、パッチが適用されていない脆弱性や弱点を悪用しようとしています。 セキュリティデータは機密性が高いため、利害が対立する関係者が入り組んだ複雑なエコシステムが形成されています。組織はその中で、関係者ごとに異なるレベルのデータアクセスを維持しなければなりません。 ガイドラインを導入する理由 ここまで、ネットワークスキャンの正当な用途と悪意のある用途、そしてスキャン結果のデータに関心を持つさまざまな関係者について説明しました。AWS がこのガイドラインを導入する理由は、AWS のネットワークとお客様を保護する必要があり、同時にこれらの関係者を見分けるのが難しいためです。インターネットでネットワークスキャナーを識別するための単一の標準は存在しません。そのため、システム所有者や防御担当者は、誰がシステムをスキャンしているのかを把握できていないことが少なくありません。これらのさまざまな関係者の識別は、各システム所有者が個別に管理する必要があります。ネットワークスキャナーは、逆引き DNS、カスタムユーザーエージェント、専用のネットワーク範囲など、独自の方法で自らの身元を示す場合があります。悪意のあるアクターであれば、識別そのものを回避しようとすることもあります。このように識別方法がまちまちなため、システム所有者がネットワークスキャンを実行している関係者の動機を把握するのは困難です。 この課題に対処するため、AWS はネットワークスキャンに関する行動ガイドラインを導入します。AWS はすべてのお客様にネットワークセキュリティを提供することを目指しており、このガイドラインを満たさない不正なスキャンを排除することを目標としています。広範囲にネットワークスキャンを行う関係者は、このガイドラインに従うことで、AWS の IP 空間からより信頼性の高いデータを取得できます。また、AWS でワークロードを運用する組織は、リスク管理においてより高い確実性を得られます。 ネットワークスキャンがこのガイドラインに沿って管理されれば、システム所有者は防御を強化し、デジタルエコシステム全体の可視性を高めることができます。例えば、 Amazon Inspector は、このガイドラインに準拠しながら、ソフトウェアの脆弱性を検出し、修復作業の優先順位付けを行えます。同様に、AWS Marketplace のパートナーも、このガイドラインに従ってインターネット全体のシグナルを収集し、組織がサイバーリスクを把握し、管理できるよう支援しています。 「組織が自らのセキュリティポスチャとサードパーティのセキュリティポスチャをデータに基づいて明確に可視化できれば、より迅速かつ的確な意思決定を行い、エコシステム全体のサイバーリスクを低減できます」 – Bitsight CTO、Dave Casion 氏 もちろん、セキュリティは協力して取り組むことでより効果を発揮します。AWS のお客様は、不正なスキャンを Trust &amp; Safety Center に報告できます。報告の際は、種類として [Network Activity] &gt; [Port Scanning and Intrusion Attempts] (ネットワークアクティビティ &gt; ポートスキャンと侵入の試み) を選択してください。それぞれの報告が、セキュリティデータの悪用に対する全体的な保護の強化につながります。 訳注: 2026 年 10 月時点の報告フォームでは選択肢が原文の記載と異なり、[Port Scanning and Intrusion Attempts] という項目はありません。[AWS] (AWS が所有するリソース) と [Network Activity] (ネットワークアクティビティ) を選択した後、[Type of abuse] (不正使用の種類) で、不正なスキャンの報告には [Port scanning] (ポートスキャン) を選択します。ログイン試行や脆弱性の悪用など侵入の試みを伴う場合は [Intrusion attempts (ssh, FTP, etc.)] (侵入の試み (ssh、FTP など))、HTTP のクローリングやボットによるアクセスの場合は [Web crawling, scraping, and bots] (ウェブクローリング、スクレイピング、ボット) も該当します。 ガイドライン 正当なネットワークスキャナーが脅威アクターとの違いを明確に示せるよう、AWS はお客様のワークロードをスキャンする際のガイダンスを次のとおり提供します。このネットワークスキャンに関するガイダンスは、 ペネトレーションテスト と 脆弱性の報告 に関するポリシーを補完するものです。AWS は、このガイドラインに準拠していないと見られるトラフィックを制限またはブロックする権利を留保します。このガイドラインに準拠したスキャナーは、次のプラクティスに従います。 観察のみ 検出したエンドポイント上のリソースやデータを作成、変更、削除しようとする操作は一切行いません。 対象システムの完全性を尊重します。スキャンによってシステムの機能を低下させたり、システム設定を変更したりしません。 変更を伴わないスキャンの例は次のとおりです。 TCP ハンドシェイクの開始と完了 SSH サービスからのバナーの取得 識別可能 スキャン活動の送信元を公開し、透明性を確保します。 スキャン活動の真正性を確認できる検証可能なプロセスを実装します。 識別可能なスキャンの例は次のとおりです。 スキャン元 IP の逆引き DNS ルックアップのサポート (自組織のパブリック DNS ゾーンのいずれかに属する名前を返す) リクエストの種類 (サービスの存在確認、脆弱性チェックなど) ごとに整理したスキャン用 IP 範囲の公開 HTTP スキャンの場合は、ユーザーエージェント文字列への意味のある情報 (自組織のパブリック DNS ゾーン内の名前、オプトアウト用の URL など) の記載 協調的 対象システムへの影響を最小限に抑えるため、スキャンレートを制限します。 検証済みのリソース所有者がスキャン活動の停止を要求できるよう、オプトアウトの仕組みを提供します。 妥当な期間内にオプトアウトの要求に従います。 協調的なスキャンの例は次のとおりです。 宛先サービスごとに、スキャンを 1 秒あたり 1 サービストランザクションまでに制限 robots.txt や security.txt など、サイト所有者の意図を表すための業界標準で示されたサイト設定の尊重 機密保持 SOC2 などの業界標準の認証に示されるような、安全なインフラストラクチャとデータ取り扱いのプラクティスを維持します。 収集したスキャンデータに対して、認証されていないアクセスや権限のないアクセスが発生しないようにします。 ユーザーの識別と検証のプロセスを実装します。 AWS が公開しているガイダンスの全文をご覧ください 。 今後の展望 このガイダンスに従うネットワークスキャナーが増えれば、システム所有者は機密性、完全性、可用性に対するリスクを低減できます。正当なネットワークスキャナーは、自らの意図を明確に示し、可視性の質も向上させます。ネットワークを取り巻く状況は絶えず変化しているため、AWS は、このガイダンスが技術的な統制とともに今後も進化していくと考えています。AWS とインターネット全体のセキュリティポスチャを継続的に改善していくため、お客様、システム所有者、ネットワークスキャナーをはじめとする皆様からのご意見をお待ちしています。 この記事に関するフィードバックがある場合は、 AWS サポートにお問い合わせ ください。 Stephen Goodman Stephen は、Amazon active defense のシニアマネージャーとして、AWS のお客様とインターネットを脅威アクターから守るためのデータ駆動型プログラムを主導しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 7 月 11 日に公開された AWS Blog “ Proactive strategies for cyber resilience and business continuity on AWS ” を翻訳したものです。 Amazon Web Services (AWS) は、サイバーセキュリティインシデントや、技術的な障害、自然災害といった事業継続を脅かすイベントに備えて、ワークロードを復旧できるよう準備しておくことを組織に推奨しています。この記事では、公共部門の組織が AWS インフラストラクチャを使用して、クラウド上でレジリエントなシステムを運用するためのガイダンスと戦略を紹介します。AWS がお客様に推奨している内容は次のとおりです。 サイバーセキュリティと AWS アーキテクチャのベストプラクティスに関するフレームワークを使用する マルチアカウント環境を実装する AWS 環境とワークロードのデプロイに Infrastructure as Code (IaC) を使用する プライマリワークロードとは異なるアベイラビリティーゾーンまたは リージョン に復旧用アカウントを準備する すべてのアプリケーションコード、IaC コード、設定ファイル、その他の依存関係を復旧用アカウントに配置する 復旧用アカウントにデータをバックアップする戦略を定義する 復旧用アカウントで、ユニットテストとワークロード全体のテストを自動化する 確立されたフレームワークを使用する ランサムウェアなどのサイバーセキュリティインシデントが増加し続ける中、公共部門の組織は、サイバーセキュリティリスクをより適切に管理するためのガイダンスとして、 NIST Cybersecurity Framework (CSF) 2.0 などのフレームワークを参考にしています。このフレームワークは 米国国立標準技術研究所 (NIST) が策定したものです。CSF はサイバーセキュリティの成果を機能 (統治、識別、防御、検知、対応、復旧) ごとに整理していますが、NIST はその成果を達成する具体的な方法までは規定していません。 より具体的なガイダンスについては、「 AWS Blueprint for Ransomware Defense 」などのリソースを参照してください。このリソースでは、具体的な AWS サービスを CSF の各機能にマッピングしています。AWS でのアーキテクチャ設計のベストプラクティスを深く理解するには、 AWS Well-Architected フレームワーク が役立ちます。このフレームワークは 6 つの柱に沿ってベストプラクティスを詳しく解説しており、クラウドアーキテクトが AWS 責任共有モデル に従って、さまざまなアプリケーションやワークロード向けに、安全で高性能、レジリエントかつ効率的なインフラストラクチャを構築できるよう支援します。さらに、これらのフレームワークを補完するのが AWS Security Reference Architecture (AWS SRA) です。AWS SRA は、AWS の推奨プラクティスに沿って AWS のセキュリティサービスを設計、実装、管理するのに役立ちます。この記事では、CSF と AWS Well-Architected を橋渡しする形で、サイバーセキュリティイベントや災害からの復旧に備えるための重要なパターンを紹介します。 AWS でマルチアカウント戦略を実装する AWS では、ベストプラクティスとして、マルチアカウント戦略に基づいてクラウド環境を構築することを推奨しています。このようにマルチアカウント戦略に基づいて構築した環境は ランディングゾーン とも呼ばれます。 AWS Organizations を AWS Control Tower または Landing Zone Accelerator on AWS と組み合わせて使用すると、管理と自動化が容易な環境を構築できます。複数の AWS アカウントを使用すると、アプリケーションとデータを分離して管理しやすくなり、環境内での意図しない横方向の移動 (ラテラルムーブメント) を排除できます。 マルチアカウント戦略の一環として、AWS は AWS IAM Identity Center を使用してアイデンティティを一元管理することを推奨しています。AWS 外部の ID プロバイダーを IAM Identity Center と統合することも可能です。ただし、復旧時にはルート認証情報を使用しなければならない場合があります。 AWS では、AWS アカウントへのルートアクセスは必要な場合にのみ使用することを推奨しています 。アカウントの乗っ取りや不正アクセスを防ぐために、ルート認証情報は適切に保護する必要があります。AWS は 2024 年 11 月に、ブログ記事「 AWS Organizations を使用するお客様のためのルートアクセスの一元管理 」で、ルート認証情報を一元管理するための新機能を発表しました。ルート認証情報を一元管理することで、長期間有効なルート認証情報を削除し、認証情報が意図せず、または不正にリカバリされることを防止できるため、AWS 環境全体のセキュリティポスチャを強化できます。 自動化によって AWS インフラストラクチャを構築する AWS は、DevSecOps の重要な原則として、すべての AWS インフラストラクチャを IaC でデプロイすることを推奨しています。IaC を使用すると、インフラストラクチャを迅速に反復改善できるほか、一貫性と再現性の向上、設定ミスの削減、バージョン管理も実現できます。復旧の観点で特に重要なのは、IaC がインフラストラクチャのドキュメントとしても機能することです。IaC は、事業継続を脅かすイベントからの復旧と、それに備えたテストを迅速化します。これにより、新しい AWS アカウントや AWS リージョンにインフラストラクチャをすばやくデプロイできます。 AWS のサービスは IaC を前提に設計されており、組織のニーズに合わせてさまざまな IaC ツール から選択できます。AWS は、 AWS CloudFormation や AWS Cloud Development Kit (AWS CDK) などの選択肢を提供しています。AWS CloudFormation ではテンプレートを使用してインフラストラクチャを定義でき、AWS CDK では使い慣れたプログラミング言語でクラウドリソースを定義できます。また、AWS CloudFormation では 既存のインフラストラクチャからスタックを作成 することもできるため、IaC への移行が容易になります。アプリケーションレベルでは、 AWS サーバーレスアプリケーションモデル (AWS SAM) を利用できます。AWS SAM は、IaC を使用してサーバーレスアプリケーションを構築するためのオープンソースフレームワークです。AWS は HashiCorp Terraform もサポートしています。HashiCorp Terraform は、複数のクラウドサービスプロバイダーにまたがるリソースとオンプレミスのリソースの両方を、人間が読める形式の設定ファイルで定義できる IaC ツールです。この設定ファイルは、バージョン管理、再利用、共有が可能です。 どのツールを使用する場合でも、IaC はリソース名、AWS リージョン、IP 範囲などを変数化して開発できるため、AWS アカウントやリージョンをまたいでコードを簡単に再利用でき、復旧プロセスを迅速化できます。IaC コードは、GitLab などのソースコードリポジトリに保存してください。より迅速に復旧できるよう、独自の DevSecOps パイプラインを構築することも、AWS 規範ガイダンスに従って標準化することもできます。 DevOps Pipeline Accelerator (DPA) は、前述のツールを使用して、アプリケーションやインフラストラクチャをデプロイするための 継続的インテグレーションと継続的デリバリー (CI/CD) パイプライン全体の構築に役立つテンプレート群で構成されたソリューションです。IaC の詳細については、 Infrastructure as Code のホワイトペーパー を参照してください。 復旧先を準備する アイデンティティの侵害などのサイバーセキュリティインシデントに備えて、AWS は前述のマルチアカウント戦略を活用し、復旧用のアカウントを個別に用意することを推奨しています。AWS アカウント内のアイデンティティはロールに基づいて管理すべきですが、悪意のある攻撃者がルートアクセスを取得しているか、自身の権限を昇格させることができる場合は、同じアカウント内のバックアップも侵害される可能性があるためです。 技術的な障害や自然災害への対策として、可能性は低いものの、 AWS アベイラビリティーゾーン が利用できなくなるシナリオからワークロードを保護できます。リージョン内でアベイラビリティーゾーン単位の復旧を行う場合は、復旧用のアベイラビリティーゾーンが、ワークロードのデプロイ先とは別のゾーンであることを確認してください。そのためには、アカウント間で一貫したアベイラビリティーゾーン ID (AZ ID) を使用します。 AWS は、アカウントごとに AZ の名前をランダムに割り当てます 。別のアカウントのアベイラビリティーゾーンを復旧に効果的に使用するには、リージョン内の すべてのアカウントで一貫した AZ ID を使用 してください。この方法により、同じリージョン内の 2 つ以上のアベイラビリティーゾーンにワークロードを分散デプロイしてレジリエンスを確保しつつ、復旧用には別のアベイラビリティーゾーンを使用できます。一貫した AZ ID を使用すれば、復旧用のアベイラビリティーゾーンを、すべてのワークロードのデプロイ先とは確実に異なるゾーンにできます。 訳注: 2025 年 11 月以降に作成されたアカウントでは、従来はアカウントごとに AZ 名の対応がランダムだったリージョンでも、すべてのアカウントで同じ AZ 名が同じ AZ を指します。それより前に作成されたアカウントでは、従来どおり AZ 名がアカウントごとに個別に対応付けられているため、アカウント間で AZ を揃えるには引き続き AZ ID を使用します。参照: AZ IDs – AWS Regions and Availability Zones 次の図は、AZ ID を使用したワークロードアカウントと復旧用アカウントのアーキテクチャを示しています。 図 1. アベイラビリティーゾーン ID を使用したワークロードアカウントと復旧用アカウントの例 より広範囲に及ぶ技術的な障害や自然災害に対するレジリエンスを確保するには、マルチリージョンでの復旧を選択することもできます。AWS は、可能であれば、復旧用アカウントに別のリージョンを使用することを検討するよう推奨しています。例えば、米国東部 (バージニア北部) リージョン ( us-east-1 ) をメインに、米国東部 (オハイオ) リージョン ( us-east-2 ) をバックアップ先にする構成です。少なくとも、データは別のリージョンにバックアップすることを AWS は推奨しています。クロスリージョンのバックアップ先を使用する場合、別のアカウントでバックアップデータを復号できるよう、 AWS Key Management Service (AWS KMS) を使用した暗号化キーの戦略を検討する必要があります。 なお、リージョン間のデータ転送料金はアベイラビリティーゾーン間よりも高くなる可能性があります。この点も、バックアップ先の戦略全体を検討する際に考慮してください。 バックアップ戦略を定義し、自動テストを実装する AWS は、クラウドベースのソリューションに合わせてバックアップ戦略を策定することを推奨しています。前述のとおり復旧先を準備したら、 AWS Backup を使用してワークロードデータを復旧用アカウントにバックアップできます。AWS Backup は、IaC、インフラストラクチャの設定データ、アプリケーションコード、アプリケーションの設定を復旧先に保存する用途にも使用できます。ほとんどのシナリオでは、ワークロードの復元にこれらすべての種類のデータが必要になります。クラウドベースのコードリポジトリを使用している場合は、十分なバックアップ機能がそのソリューションに既に備わっている可能性があります。 バックアップしたデータが実際に使用できるかを検証するために、AWS は復旧用アカウントで自動テストを実装することを推奨しています。例えば、バックアップの完了後に実行され、バックアップを正しく読み取れることを確認する自動プロセスを実装すると、ランサムウェアなどの脅威に対する効果的な緩和策になります。こうした攻撃への対策をさらに強化するために、バックアップしたすべてのコンポーネントについて複数のバージョンを保持し、必要に応じて古いバージョンのバックアップを復元できるようにしておくこともできます。また、バックアップ戦略の一環として、 AWS Backup Vault Lock などの機能を使用したイミュータブルなバックアップの採用を検討するのもよいでしょう。 バックアップと IaC の戦略の一環として、ワークロードに必要なコンポーネントが復旧先に保存されていることを確認してください。対象には、IaC コード、インフラストラクチャの設定データ、 Amazon マシンイメージ (AMI)、アプリケーションコード、アプリケーションの設定が含まれます。このプロセスは、DevSecOps と IaC の戦略全体に組み込む必要があります。DevSecOps パイプラインで変更が行われたときに、これらすべてのコンポーネントのバックアップをトリガーする自動プロセスを実装すれば、復旧用アカウントのバックアップを常に最新の状態に保つことができます。パイプラインの変更が頻繁に発生するシステムでは、毎日など定期的に実行される自動バックアッププロセスを選択することもできます。 復旧用アカウントの準備、IaC の実装、バックアップ戦略の確立が完了したら、復旧用アカウントでワークロード全体をテストすることを AWS は推奨しています。復旧用アカウント内の IaC コードとバックアップを使用して、そのアカウントでワークロード全体を定期的に構築してください。多くの場合、既存のコンポーネントテスト、統合テスト、ユーザー受け入れテストのスクリプトを、定期的な事業継続訓練に活用できます。このようなテストによって復旧機能の有効性を検証でき、事業継続を脅かすイベントが発生した場合にワークロードを復旧できることを確認できます。 まとめ この記事で紹介したベストプラクティスに従うことで、公共部門の組織は AWS の機能を活用して、事業継続を脅かすイベントからの復旧に備えることができます。さらに詳しいガイダンスについては、AWS アカウントチームとソリューションアーキテクトにお問い合わせください。 Devin Gordon Devin は Amazon Web Services (AWS) のプリンシパルソリューションアーキテクトとして、米国連邦政府の文民機関を支援しています。AWS ではセキュリティを専門としており、お客様が新興テクノロジーを活用しながら安全な環境を実装できるよう支援することに情熱を注いでいます。旅行が好きで、特にスキューバダイビングやハイキングなどのアウトドア活動を楽しんでいます。 Henrik Balle Henrik は AWS のプリンシパルソリューションアーキテクトとして、米国の公共部門を支援しています。機械学習から大規模環境でのセキュリティとガバナンスまで、幅広いトピックについてお客様と緊密に連携しています。余暇にはロードバイクやオートバイを楽しむほか、自宅のリフォームに次々と取り組んでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 7 月 24 日に公開された AWS Blog “ AWS Security Incident Response: The customer’s journey to accelerating the incident response lifecycle ” を翻訳したものです。 2025 年 8 月 1 日: この記事は、AWS WAF と AWS Shield への誤った言及を削除するために再公開されました。 効果的なセキュリティインシデント対応プログラムを構築し、維持するうえで、組織が直面する課題は増え続けています。 IBM と Morning Consult の調査によると、セキュリティチームは 2 つの大きな課題に直面しています。1 つは、リソースの制約とアラート疲れにより、50% を超えるセキュリティアラートが未対応のままになっていることです。もう 1 つは、誤検知 (フォールスポジティブ) が調査時間の 30% を占め、真陽性 (トゥルーポジティブ) と判定された脅威への対応が遅れていることです。 調査レポート「 2024 IBM Cost of a Data Breach Report 」によると、組織がセキュリティイベントを特定して封じ込めるまでに、平均 258 日を要していました。同レポートでは、SOC (セキュリティオペレーションセンター) チームの半数近くが、調査時点までの 2 年間で検出と対応にかかる時間が長くなったと報告しています。さらに 80% が、手動での脅威調査が対応時間に大きく影響していると回答しています。 こうした課題がある一方で、「2024 IBM Security Services Benchmark Report」によると、成熟したインシデント対応能力を持つ組織では、平均解決時間 (MTTR) が 50% 短縮され、インシデントあたり最大 58% のコスト削減を実現しています。これらの改善は、脅威の検出と封じ込めを加速する自動化されたワークフロー、統合ツール、効率化されたコミュニケーションプロセスの導入によってもたらされています。 この記事では、実環境を想定したシナリオを通じて、 AWS Security Incident Response がインシデント対応ライフサイクルのあらゆるステップを加速し、すぐに効果をもたらす仕組みを紹介します。また、 Amazon GuardDuty 、 AWS Security Hub 、 AWS Systems Manager といった他の AWS ネイティブサービスとの統合方法や、サードパーティーによる脅威の検出結果を取り込み、自動化されたモニタリング、トリアージ、封じ込めの機能に組み込む方法についても説明します。 AWS Security Incident Response による支援 AWS Security Incident Response は、2024 年 12 月にリリースされた Tier 1 サービスです。お客様向けに専用に構築された AWS ネイティブのセキュリティインシデント対応ソリューションであり、検出と対応 (GuardDuty と Security Hub)、管理とガバナンス (Systems Manager) の分野の他の AWS サービスと組み合わせることで、より大きな効果を発揮します。また、AWS Security Incident Response は、サービス固有のパートナースペシャライゼーションプログラムを通じて AWS パートナーとも統合されています。詳細については、 AWS Security Incident Response のドキュメント を参照してください。 AWS Security Incident Response は、セキュリティイベントの発生前、発生中、発生後を通じて効率的なインシデント管理機能を提供し、セキュリティポスチャを強化することで、既存のサービスを補完します。 主な課題 AWS Security Incident Response は、次の 3 つの一般的な課題に対応します。 アラート疲れ : 自動化されたモニタリングとインテリジェントなトリアージにより、アラート疲れを軽減し、セキュリティ調査を加速できます。誤検知が減ることで、セキュリティチームの燃え尽きの防止にも役立ちます。 アクセスとコミュニケーションの分断 : AWS マネジメントコンソールのアクセス許可管理を簡素化し、インシデント対応チームのコミュニケーションを一元化することで、アクセスの分断に関する問題を解決できます。 セキュリティスキルのギャップ : 認証情報の侵害、データ流出、ランサムウェアなどのインシデントに対応する AWS のセキュリティエキスパートに 24 時間 365 日アクセスできるため、クラウドセキュリティに関するスキルのギャップを埋めることができます。AWS Security Incident Response サービスを利用することで、セキュリティチームは目の前のセキュリティ課題に対処しながら、戦略的かつ長期的な備えと運用の改善にも引き続き注力できます。 サービスの統合 AWS Security Incident Response は、AWS のセキュリティサービスを補完し、それらと統合することで、包括的なインシデント対応機能を提供します。このサービスは、次のものとシームレスに連携します。 検出サービス : GuardDuty、Security Hub 管理ツール : Systems Manager サードパーティーソリューション : Security Hub の統合機能と&nbsp; AWS Security Incident Response パートナースペシャライゼーションプログラム を通じて連携 訳注: 本記事で説明している AWS Security Hub は、翻訳時点 (2026 年 10 月) では AWS Security Hub CSPM に名称が変更されており、同じ名前の新しい AWS Security Hub が別途提供されています。AWS Security Incident Response は、サードパーティーの検出結果を AWS Security Hub CSPM 経由で取り込みます。参照: 「 ほぼリアルタイムの分析とリスクの優先順位付けが可能な AWS Security Hub が一般公開されました 」、「 ステップ 4: 既存のツールと統合する – AWS Security Incident Response ユーザーガイド 」 この統合により、組織のクラウドジャーニー全体を通じて、セキュリティイベントにかかる時間、コスト、影響を最小限に抑える効率的なインシデント対応機能を構築できます。また、人員の追加、トレーニング、ツールのメンテナンスへの投資の削減にも役立ちます。 独自の機能 AWS Security Incident Response サービスでは、次のものが提供されます。 AWS Security Incident Response Engineering (SIRE) チームの専門知識 API とコンソールを通じて利用できるツール セキュリティインシデントに対処するための効率化されたプロセス 前提条件 この記事で説明する機能を実装する前に、次の条件を満たしていることを確認してください。 適切な AWS Identity and Access Management (IAM) のアクセス許可を設定済みであること インシデント対応チームの連絡先を設定済みであること 通知チャネルを設定済みであること (オプション) アカウントと AWS リージョンで GuardDuty を有効化済みであること (オプション) アカウントとリージョンで Security Hub を有効化済みであること (オプション) 自動アクションに必要な AWS CloudFormation StackSets をデプロイ済みであること これらの前提条件を満たしておくことで、このサービスの自動検出、トリアージ、対応の機能を最大限に活用できます。 このサービスは、独自のサービスインフラストラクチャ内で自動化されたモニタリングと分析の機能を提供しており、GuardDuty と Security Hub の検出結果を自動的にトリアージできます。 AWS アカウントで自動封じ込めアクションを実行するには、まず必要な CloudFormation StackSets をデプロイし、適切な IAM アクセス許可を設定する必要があります。これにより、このサービスの検出機能を活用しつつ、環境内で実行される自動アクションを完全に制御できます。この自動化は、既知の CIDR 範囲 (ネットワークを定義する特定の IP アドレス範囲) や IP アドレスなど、お客様が設定する変数に基づいてカスタマイズできます。また、GuardDuty の抑制ルールを実装して、誤検知やアラートの量を減らすこともできます。その結果、このサービスは、既存のセキュリティインシデント対応プログラムやツールを補完する強力な手段となります。 AWS Security Incident Response のセットアップ クラウド管理者は、 AWSSecurityIncidentResponseFullAccess のアクセス許可を使用して、サービス内にインシデント対応チームを設定済みです。このサービスは、チームに追加された個人、パートナーまたはマネージドセキュリティサービスプロバイダー (MSSP)、その他の連絡先に通知を送信します。これにより、迅速にエスカレーションして必要な関係者にアラートを送り、イベントに対応できます。 ベストプラクティスとして、チームは AWS Security Incident Response のケース内の情報へのアクセスと管理に必要な最小限の権限を設定します。これにより、セキュリティとコンプライアンスの要件を満たしつつ、チームメンバーがケースの詳細、検出結果、調査データに適切なレベルでアクセスできるようになります。AWS Security Incident Response には、ケースごとに誰がどのアクションを実行できるかを制限できるよう、 CreateCaseComment (調査にメモを追加する) や&nbsp; GetCase (ケースのメタデータを取得する) など、複数の API アクションが用意されています。開発環境とテスト環境向けには、ロールベースのアクセス制御に使用できる AWSSecurityIncidentResponseCaseFullAccess や AWSSecurityIncidentResponseReadOnlyAccess などのロールベースのポリシーが AWS から提供されています (図 1 を参照)。本番環境では、セキュリティ要件に基づき、最小権限の原則に従ったカスタム IAM ポリシーを作成することをお勧めします。 図 1: セキュリティインシデント対応のアクセス許可ポリシー AWS Security Incident Response サービスの設定後、セキュリティチームは、図 2 に示すように、このサービスからの通知を受け取る E メール配信リストまたはエイリアスを確認します。また、今後は追加の通知メカニズムとして PagerDuty や Jira などのサービスを追加できるよう、 Amazon EventBridge との統合を活用するタスクをバックログに登録しています。 図 2: コンソールを使用してインシデント対応チームのメンバーシップを管理する 不審なアクティビティの検出と対応 AWS Security Incident Response のセットアップから数日後の午前 2 時、このサービスは GuardDuty の検出結果を通じて、一連の不審なアクティビティを検出します。具体的には、IAM ユーザーの異常な動作 (図 3 に示すようなもの)、不明な IP アドレスからの通常とは異なる API コール、アカウントの通常のベースラインから逸脱した Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの大量作成などです。このアクティビティのパターンは、 GuardDuty 拡張脅威検出 がモニタリングしている既知の脅威の動作と一致します。このサービスがなければ、セキュリティチームはアカウントとリージョンをまたいで、これらの個別の検出結果を手動で分析し、相関付ける必要があります。しかし、このサービスを使用すれば、不審なアクティビティのパターンが自動的に特定されます。 図 3: 不審と思われるアクティビティのパターン 異常な動作の 1 つは、身に覚えのない EC2 インスタンスの大量作成です。これらのインスタンスには SSH キー (リモートアクセスに使用される安全な認証情報) が設定され、インターネット接続を許可するセキュリティグループ設定 (ネットワークトラフィックを制御するファイアウォールルール) も適用されています。このシナリオ例を使用して、このサービスの自動化されたモニタリング、トリアージ、封じ込めの機能、アクセス管理、カスタム統合用の API アクション、コラボレーションツール、そして 24 時間 365 日対応の AWS セキュリティエキスパートがどのように連携し、AWS 環境全体のセキュリティインシデント対応の課題への対処を支援するのかを順を追って見ていきましょう。 Incident Response Timeline &nbsp;&nbsp; &nbsp;dateFormat HH:mm &nbsp;&nbsp; &nbsp;axisFormat %H:%M &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp;section Detection &nbsp;&nbsp; &nbsp;GuardDuty Alerts &nbsp; &nbsp; &nbsp; &nbsp;&nbsp; :02:00, 15m &nbsp;&nbsp; &nbsp;Automated Analysis &nbsp; &nbsp; &nbsp;&nbsp; :after Detection, 10m &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp;section Investigation &nbsp;&nbsp; &nbsp;Case Creation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; :02:25, 5m &nbsp;&nbsp; &nbsp;Team Notification &nbsp; &nbsp; &nbsp; &nbsp; :02:30, 5m &nbsp;&nbsp; &nbsp;Initial Assessment &nbsp; &nbsp; &nbsp; &nbsp;:02:35, 25m &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp;section Response &nbsp;&nbsp; &nbsp;AWS SIRE Engagement &nbsp; &nbsp; &nbsp; :03:00, 30m &nbsp;&nbsp; &nbsp;Resource Tagging &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;:03:30, 15m &nbsp;&nbsp; &nbsp;Containment Actions &nbsp; &nbsp; &nbsp; :03:45, 30m &nbsp;&nbsp; &nbsp; &nbsp;&nbsp; &nbsp;section Resolution &nbsp;&nbsp; &nbsp;Threat Elimination &nbsp; &nbsp; &nbsp; &nbsp;:04:15, 30m &nbsp;&nbsp; &nbsp;Service Restoration &nbsp; &nbsp; &nbsp; :04:45, 45m &nbsp;&nbsp; &nbsp;Documentation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;:05:30, 30m 初期検出が完了したら、次のフェーズでは、インシデントの全容を把握するために、セキュリティの検出結果を一元化して分析します。 セキュリティ検出結果の一元化: 体系的なアプローチ GuardDuty を有効化したリージョンで、検出結果の生成が開始されます。 注: GuardDuty は、アカウントとリージョンで有効化されている必要があります。セットアップ手順については、 GuardDuty のドキュメント を参照してください。 AWS Security Incident Response は GuardDuty と統合されているため、これらの検出結果は手作業なしで自動的にサービスに送信され、内部での処理、分析、自動トリアージが行われます。このサービスの プロアクティブな対応とアラートのトリアージ 機能は、アカウントの過去のアクティビティに基づくベースライン、GuardDuty の具体的な検出結果タイプ、アカウント間の相関パターンなど、複数の要素を分析します。この例では、環境の通常のパターンから大きく逸脱した、異常な EC2 インスタンス作成アクティビティを特定しました。 このサービスが真陽性を特定すると、AWS Security Incident Response のケースが自動的に作成され (図 4 を参照)、先ほど設定したインシデント対応チームに通知が送信されます。大きなメリットは、このサービスが個別のイベントを相関付け、インスタンスの作成とセキュリティグループの変更を結び付けることで、潜在的なセキュリティイベントの全体像を描き出せる点です。 図 4: 自動化されたインシデント修復フロー 月次サービスレポートに記録されているとおり、このプロアクティブなモニタリングと分析は、アラート疲れを軽減し、SOC チームにインテリジェントなトリアージ機能を日々提供することで、目に見えるメリットをもたらします。このサービスの自動分析と相関付けの機能により、セキュリティイベントの発生時に迅速に対応するための土台が整うため、チームはアラートの手動調査に時間を費やすことなく、戦略的なセキュリティイニシアチブに集中できます。このサービスの機能は、次の 2 つの点で強固なセキュリティの維持に役立ちます。 設定したリージョン全体にわたる包括的なモニタリング。 サードパーティーのセキュリティツールとの統合。この自動化されたアプローチにより、セキュリティイベントにかかる時間、コスト、影響が軽減されます。 調査が初期検出から詳細な分析へと進むなかで、GuardDuty との統合により、脅威のパターンに関する重要なインサイトが得られます。 検出からアクションへ: GuardDuty との統合 セキュリティチームが内部の検出メカニズムから得られた情報に対応するなかで、AWS Security Incident Response は、次の 3 つの主要なステップでセキュリティの検出結果を処理します。 GuardDuty のアラートを分析して、実際のセキュリティ脅威を特定する GuardDuty 拡張脅威検出を使用して関連するイベントを相関付け、脅威のパターンを特定する 初期アクション (ログの削除や不正なアクセス手段の作成) から、データ窃取の試みが疑われる段階に至るまで、脅威のシーケンスを追跡する 今回のイベントでは、AWS CloudTrail ログの削除から始まり、続いて不正なアクセスキーが作成されました。脅威が進行するにつれて、このサービスは Amazon Simple Storage Service (Amazon S3) オブジェクトへの不審なアクセスパターン、データ流出が疑われる試み、さらに高度な回避手法と永続化メカニズムを特定しました。これらのシグナルはそれぞれ MITRE ATT&amp;CK® の特定の戦術、技術、手順 (TTP) に直接対応しており、ランサムウェアの疑いがある脅威が体系的に進行していることを示しています。AWS Security Incident Response の検出結果と MITRE ATT&amp;CK® フレームワークとの詳細なマッピングについては、「 Mapping AWS security services to MITRE frameworks for threat detection and mitigation 」を参照してください。 このサービスは相関付けと分析を支援し、CloudTrail 証跡の削除、新しいアクセスキーの作成、S3 オブジェクトを標的とした不審なアクションなどのパターンを評価します。GuardDuty の AI と機械学習 (AI/ML) の機能が一定期間にわたってこうした懸念すべきパターンを検出すると、このサービスはお客様に代わって AWS Security Incident Response のケースを自動的に作成して状況をエスカレーションします。これにより、追加のリソースが投入され、この状況に重点的に対処できるようになります。その後、前の手順で定義したインシデント対応チームに、トリアージ済みの新しいイベントが作成されたことが E メールやその他の方法 (図 5 を参照) で通知され、チームは調査を開始します。 メリットの 1 つは、影響を受けるアカウント全体のコミュニケーションをこのサービスが調整することです。複数のアラートに振り回されたり、断片的な情報をつなぎ合わせてランサムウェアインシデントの疑いがある事象の範囲を把握しようとしたりする必要はありません。GuardDuty 拡張脅威検出が脅威のシーケンスの包括的なビューを提供し、AWS Security Incident Response のケースがこれらのシグナルをトリアージするための一貫した単一のチャネルとなります。さらに、世界各地のチームがオンラインになって対応に加わる際の調整にも役立ちます。 図 5: インシデントアラートメッセージ その他の例と詳細については、「 Amazon GuardDuty Extended Threat Detection のご紹介: AI/ML 攻撃シーケンスを識別し、クラウドセキュリティを強化 」を参照してください。 注: Security Hub のワークフローは、前述の GuardDuty のモニタリングとエスカレーションのプロセスと同様のため、ここでは簡潔さを優先して詳細を省略しています。両サービスは緊密に統合されており、同様の運用パターンを共有しています。GuardDuty の検出結果は、検出から 5 分以内に Security Hub に送信されます。Security Hub は、複数の AWS サービスとサードパーティーのパートナーからの検出結果を集約することで、セキュリティのカバレッジを強化します。 脅威のパターンが特定されたら、お客様のチームは次のフェーズに進み、専門知識と高度な調査機能を得るために AWS SIRE に協力を依頼します。 インシデント対応ケースを通じた AWS SIRE との連携 お客様のチームはイベントの調査を続けるなかで、追加の支援が必要だと判断します。アカウント内で必要な権限を持つユーザーが、AWS がサポートするケースを作成して支援を依頼します。 AWS Security Incident Response のケースでは、コンソール内でワンクリックでケースをエスカレーションするだけで AWS SIRE との直接的なコミュニケーションチャネルが確立され (図 6 を参照)、専門知識をすぐに利用できます。ケースがエスカレーションされると、AWS SIRE は 15 分以内に受領を確認し、インシデント対応ケースを通じて対応を開始します。そして、高度なツールと専門知識を活用し、ログ記録機能が限られている環境であっても、アカウント全体のパターンを分析します。この連携により、次のことが実現します。 ブリッジコール (ビデオ会議) によるリアルタイムのコラボレーション 高度なアーティファクト分析とパターン認識 調査と封じ込めのための技術的なガイダンス セキュリティポスチャを改善するための推奨事項 図 6: AWS SIRE との連携 図 6 は、セルフマネージドのケースとしてリゾルバーを Self に設定した場合の、アカウントでの表示例です。 シナリオに戻ると、複数のアカウントで十分なログ記録が有効になっておらず、調査に利用できるデータが限られていることが判明します。AWS SIRE は専門的なツールを通じて追加のインサイトを提供できますが、セキュリティの可視性の確保、コンプライアンス要件への対応、徹底したインシデント調査のためには、アカウント全体で包括的なログ記録を維持することが引き続き重要です。AWS SIRE の機能は適切なログ記録の実践を補完するものであり、それに代わるものではありません。AWS SIRE は通常はお客様から見えないパターンやアクティビティを把握できるため、この機能はインシデントの範囲を理解するのに役立ちます。 コラボレーションは、AWS SIRE が独自のツールを使用して環境を分析し、手元のログで確認できる範囲を超えて異常なパターンを探すところから始まります。AWS SIRE はインシデント対応ケースを通じて、次の方法でインシデントの範囲を把握できるよう支援します。 調査結果を共有する 追加の調査の方向性を提案する 他の環境で見られた同様の EC2 インスタンス作成パターンを示す分析を共有する AWS SIRE はインシデント対応ケースを使用してブリッジコールを設定し、AWS SIRE のチームとお客様のチームが集まってリアルタイムでコラボレーションできるようにします。この通話では、AWS SIRE がアーティファクトとサービスデータについて進行中の分析結果を共有し、何が起きたのか、なぜ起きたのか、今後同様の問題をどう防ぐのかを理解できるよう支援します。また、今後のセキュリティポスチャの改善に向けて、アカウント全体に適切なログ記録を実装するためのガイダンスも提供します。 インテリジェントなタグ付けによるインシデントの管理 AWS SIRE が分析を開始すると、お客様のチームはインシデントケース ID を使用して、リアルタイムでリソースにタグを付けていきます。この体系的なタグ付けは、アカウント全体で不審な EC2 インスタンスを追跡して管理するうえで非常に重要です。タグを使用することで、調査全体を通じて影響を受けたリソースを明確に記録しながら、隔離ポリシーを迅速に実装し、コストを追跡できます。 チームが採用したタグベースのアプローチは、影響を受けたリソースを追跡し、隔離ポリシーを実装するのに役立ちます。インシデントケース ID のタグを使用してインシデントに関連するリソースをすばやく特定し、対象を絞ったアクセス制御と封じ込め対策を適用しました。また、タグはインシデントに関連するコストの追跡にも役立つため、財務チームはイベントによる財務上の影響を正確に把握できます。 AWS Security Incident Response サービスと連携して作業を進めるなかで、インシデントケース ID をプライマリタグキーとして使用すると (図 7 を参照)、影響を受けたアカウント全体でリソースを一貫した方法で相関付けられることがわかりました。調査が必要な特定のリソースを AWS SIRE にすばやく伝えられるため、AWS SIRE と連携する際に特に役立ちます。封じ込め後も、これらのタグはインシデント後の分析を支え、インシデントから得た知見に基づいて対象を絞ったセキュリティコントロールを実装するのに引き続き役立ちます。 図 7: インシデントタグ Systems Manager との統合による自動封じ込めのオプション AWS SIRE と協力してインシデントの範囲を把握する一方で、Systems Manager を使用して脅威を自動的に封じ込めることもできます。チームは必要な CloudFormation StackSets を事前に組織全体へデプロイしているため、Systems Manager を通じて Amazon EC2 の封じ込めアクションを実行できます。 セットアッププロセスでは、特定の IAM ロールと Systems Manager の設定を含む CloudFormation StackSets をアカウント全体にデプロイする必要がありました。このインフラストラクチャにより、AWS Security Incident Response サービスはお客様に代わって封じ込めアクションを実行できます。これらのアクションは、元に戻す ( undo ) 機能を使う場合と同様に、必要に応じて取り消せるため、システムを以前の状態に復元できます。 事前にデプロイした CloudFormation StackSets を通じて承認されていれば、AWS Security Incident Response サービスは Systems Manager に封じ込め対策の実装を要求できます。封じ込めアクションを実行するには、お客様による明示的な承認と、事前に設定された適切な IAM アクセス許可が必要です。このサービスは、タグが付けられた不審なインスタンスのセキュリティグループとネットワークアクセスを変更してインスタンスを隔離すると同時に、フォレンジック分析に使用する証拠の完全性を維持できるよう、インスタンスの状態を保持します。 封じ込めプロセスは、次の 3 つのステップで行われます。 隔離 : 侵害されたインスタンスをセキュリティグループから削除する 保全 : 影響を受けたシステムのバックアップコピー (スナップショット) を作成する 調査 : Systems Manager を使用してシステム情報を収集する これらのアクションは必要に応じて元に戻すことができるため、正当なワークロードに対する封じ込めの判断にも柔軟に対応できます。 自動化機能により、複数のインスタンスにわたる封じ込め手順が効率化され、影響を受けたリソースの封じ込めにかかる時間を短縮できます。このサービスは各アクションの詳細なログをインシデント対応ケースに記録するため、チームは封じ込め作業の状況を明確に把握できます。 この対応機能と AWS SIRE からのガイダンスを組み合わせることで、インシデントの拡大を数時間ではなく数分で封じ込めることができます。Systems Manager との統合により、調査用の証拠を保全しながら、封じ込めアクションを確実に実装できます (図 8 を参照)。 図 8: 封じ込めアクション用の Systems Manager ドキュメント 解決と教訓 インシデントが解決に向かうにつれて、チームは体系的なプロセスに沿って、封じ込めの確認、脅威の緩和、サービスの復旧を進めます。AWS Security Incident Response のケースを通じて AWS SIRE と連携しながら、影響を受けたリソースを保護し、通常の運用を安全に再開できるよう、構造化されたアプローチを実践します。直ちに実施する解決アクションは、主に次の 3 つのカテゴリに分類されます。 Systems Manager による検証を通じた封じ込めの確認 セキュリティグループの変更が適用されていることを検証する 影響を受けたインスタンスのネットワーク隔離を確認する 自動封じ込めアクションが成功したことを検証する Systems Manager のログで封じ込めアクションの完了を確認する 影響を受けたリソース全体で脅威が緩和されたことの検証 GuardDuty の検出結果を分析し、新たな不審なアクティビティがないことを確認する タグ付けされたリソースを調べ、完全に封じ込められていることを確認する 不正アクセスの試みが停止していることを検証する 永続化メカニズムが削除されていることを確認する 不正な IAM アクセスが残っていないかを確認する サービスの復旧とアクセス制御の正常化 検証済みのベースラインに基づいて、正当なワークロードのアクセスを復元する 更新されたセキュリティグループ設定を実装する 影響を受けた IAM 認証情報とアクセスキーをリセットする クリーンであることが検証されたリソースについて、通常のネットワーク接続を再確立する インシデント後のステータスを反映するようにリソースタグを更新する 文書化とレポート作成 インシデントが解決に至ると、AWS Security Incident Response サービスは包括的なインシデントタイムラインを作成します。このドキュメントによってレポート作成プロセスが迅速化され、経営幹部、規制当局、サイバー保険会社向けに必要なレポートを、すべてインシデント対応ケース内からすばやく作成できます。 インシデント対応ケースには、GuardDuty 拡張脅威検出が初期段階の脅威のシーケンスを特定した時点から始まる、イベントの完全なタイムラインが記録されます。不審な EC2 インスタンスの作成が検出された瞬間から、観測された MITRE ATT&amp;CK® の戦術、Systems Manager との統合を通じて実装された封じ込めアクション、そして最終的に効果が確認された解決手順に至るまで、インシデント対応の各ステップが文書化されます。 長期的な改善: このインシデント後の共同レビュープロセスを通じて、チームは次の取り組みを行います。 AWS SIRE の推奨事項に基づいて、ログ記録を強化する 同様のインシデントを防ぐためにセキュリティコントロールを更新する 教訓に基づいてインシデント対応プロセスを改善する 対象を絞った改善によってセキュリティポスチャを強化する まとめ この例では、AWS Security Incident Response サービスが、自動化された検出、トリアージ、封じ込め、アクセス管理、連携した対応の機能によって、セキュリティ運用をどのように強化できるかを紹介しました。このサービスは AWS Security Hub や Amazon GuardDuty と統合されているため、セキュリティイベントを効率的に処理できます。さらに、オプションで AWS SIRE にエスカレーションすれば、貴重な専門知識と専門的なツールを活用でき、インシデント対応ライフサイクルのあらゆる段階を加速し、セキュリティポスチャを強化するのに役立ちます。 AWS Security Incident Response サービスは、包括的なセキュリティ運用戦略の重要な要素として、次のような測定可能なメリットをもたらします。 自動化された相関付けと機械学習により、誤検知を最小限に抑えながら優先度の高いセキュリティリスクを特定する継続的な脅威モニタリング 自動検出と連携した対応によるインシデント対応時間の短縮 AWS SIRE との直接的なコラボレーションによる調査機能の強化 効率的かつ迅速な封じ込め レポート作成要件への迅速な対応を支援する、包括的なインシデントの記録と監査証跡 インシデントあたり最大 58% のコスト削減 セキュリティインシデントへの備え、対応、復旧をより迅速かつ効率的に行うには、今すぐ AWS Security Incident Response のページにアクセスするか、AWS アカウントチームに連絡してディスカッションの日程を調整してください。 その他のリソース セキュリティインシデント対応能力をさらに向上させるために、チームで活用できるその他の AWS リソースを紹介します。 イベント発生前 AWS Customer Playbook Framework : セキュリティイベントから得られた AWS SIRE の教訓を活用した、一般公開されている対応フレームワーク Assisted Log Enabler : Amazon VPC フローログ、AWS CloudTrail、Amazon Elastic Kubernetes Service の監査ログと Authenticator ログ、Amazon Route 53 Resolver クエリログ、Amazon S3 サーバーアクセスログ、Elastic Load Balancing ログなどのログの有効化を支援するツール イベント発生中 Athena Security Analytics Bootstrap : Amazon Athena をすばやくセットアップし、S3 バケットにアーカイブされた AWS サービスログを調査したいお客様向けのツール イベント発生前または発生後 AWS CIRT announces the release of five publicly available workshops &nbsp; Jason Hurst Jason は、AWS CIRT の Senior Incident Responder 兼 Knowledge Manager です。人材の育成に情熱を注いでおり、地元の技術系カレッジで非常勤講師も務めています。余暇には 3 匹の愛犬と過ごすのを楽しんでいます。 Christopher Rae Christopher は AWS の Principal Worldwide Security Specialist として、AWS セキュリティソリューションの導入を加速し、拡大するためのグローバルなビジネス開発戦略の策定と実行を推進しています。サイバーセキュリティと新興テクノロジーの融合に情熱を注いでおり、戦略的リーダーシップを担う役職で、メディア、エンターテインメント、通信業界の世界中のお客様にセキュリティ製品とサービスを提供してきた 20 年以上の経験があります。 Nooms Charania Nooms は AWS Global Services Security の Sr. PMT – ES です。イェール大学で MBA を取得しており、USC でエンジニアリングのバックグラウンドを培いました。テクニカルプロダクトマネジメントを専門としており、MBA プログラム在学中に AWS でインターンを経験しました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 9 月 23 日に公開された AWS Blog “ Optimize security operations with AWS Security Incident Response ” を翻訳したものです。 2026 年 7 月 6 日 : 現在の機能を反映するために、この記事を更新しました。 セキュリティ脅威には迅速な対応が求められます。そこで AWS Security Incident Response は、セキュリティポスチャをすぐに強化できる保護を提供します。この包括的なソリューションは、自動化されたトリアージと評価ロジックをセキュリティ境界のメタデータと組み合わせて重大な問題を特定し、必要に応じて人間の専門家の知見をシームレスに取り入れます。Security Incident Response を Amazon GuardDuty および AWS Security Hub と統合し、一元的なセキュリティ環境を構築すると、組織は AWS のセキュリティインシデント対応の専門家に 24 時間 365 日アクセスできるようになります。迅速な検出、専門家による分析、効率的な脅威の封じ込めを実現でき、そのすべてを 1 つの直感的なコンソールで管理できます。AWS Security Incident Response は AWS エンタープライズサポート と AWS Unified Operations に含まれています。AWS Unified Operations は、組織が AWS を大規模に、効率的かつ安全に導入、運用するのに役立ちます。 この記事では、Security Incident Response を有効にして概念実証 (POC) を実施し、セキュリティ機能を短期間で強化しながら、すぐに効果を得る方法を説明します。具体的には、サービスの機能、POC の成功基準の設定、構成の定義、デプロイの準備、サービスの有効化、初日からの効果の最適化について紹介します。これらを通じて、インシデント対応ライフサイクル全体で組織が自信を持って対応できるようになり、復旧時間の短縮にもつながります。 Security Incident Response の機能を理解する AWS Security Incident Response サービスは、効率化された 4 段階のプロセスを通じて、包括的な脅威検出と対応機能を提供します。まず、GuardDuty のセキュリティ検出結果と、AWS Security Hub Cloud Security Posture Management (CSPM) と統合された一部のサードパーティ製ツールからの検出結果を取り込みます。次に、お客様のメタデータと脅威インテリジェンスを使用してこれらの検出結果を自動的にトリアージし、異常な動作や疑わしいアクティビティを特定します。潜在的な脅威が検出されると、Security Incident Response チームの対応担当者がカスタマーポータルを通じてケースをプロアクティブに調査し、実際の脅威か誤検知かを判断します。脅威が確認された場合は、直ちに対処できるよう、サービスが検出結果をエスカレーションします。一方、誤検知の場合は、自動トリアージシステムと GuardDuty および Security Hub の抑制ルールが更新され、検出精度が継続的に向上します。 最小限の前提条件で包括的な保護を実現 Security Incident Response は、 脅威検出とインシデント対応 (TDIR) システムに加え、CrowdStrike、Lacework、Trend Micro、SentinelOne、Palo Alto Networks – Prisma Cloud Compute、Wiz (Toxic Combinations) などのサードパーティ製セキュリティサービスともシームレスに統合し、強力なセキュリティ機能を提供します。このソリューションは、GuardDuty の検出結果を取り込み、Security Hub CSPM を通じて外部プロバイダーと統合しながら、計画やコミュニケーションから解決まで、エンドツーエンドのインシデント管理を担う統合コマンドセンターとして機能します。サードパーティとの統合に必要なのは検出結果の取り込みだけで、Security Hub CSPM の全機能は必要ありません (セキュリティ標準、コントロール、コンプライアンスチェックは不要です)。検出結果は毎月最初の 10,000 件まで無料で、それ以降は 1 件あたり 0.00003 USD です (例えば、610,000 件の場合は月額約 18 USD)。詳細については、「 Security Hub CSPM の料金 」を参照してください。 安全なケース管理と変更不可能なアクティビティタイムラインにより、可視性が向上し、AWS で実績のあるツールと人員を活用できるようになります。これにより、セキュリティオペレーションセンター (SOC) とインシデント対応 (IR) チームが補強され、セキュリティ運用が大幅に強化されます。 AWS のセキュリティインシデント対応担当者は、調査と復旧の際にお客様側のインシデント対応担当者と協力して作業するため、貴重なリソースを他の優先事項に充てることができます。このサービスは、プロアクティブなモニタリングと対応機能によって継続的な価値を提供します。GuardDuty と Security Hub の検出結果を使用して環境を常時モニタリングし、サービスによる自動化、トリアージ、分析がバックグラウンドで着実に行われるため、本当にセキュリティ上の懸念がある場合にのみアラートが送信されます。常に注意を払っていなくても、潜在的なインシデントの発生時にすぐに効果を発揮します。 使用開始は簡単です。 唯一の前提条件 は、 AWS Organizations を有効にし、メンバーアカウントを含む基本的な組織単位 (OU) 構造を Organizations で確立しておくことです。この基盤は、Security Incident Response のデプロイを可能にするだけでなく、組織全体で堅牢な TDIR 戦略を実装するための土台にもなります。 成功基準を決定する 成功基準を設定すると、POC の成果をビジネス目標に照らして評価できます。基準の例は次のとおりです。 インシデント対応チームを指定する: インシデント対応を担当する社内のチームメンバーと外部の担当者を特定し、文書化します。「 AWS Well-Architected セキュリティの柱 」で強調されているように、担当者をあらかじめ指名しておくと、セキュリティインシデント発生時のトリアージと対応にかかる時間を短縮できます。 正式なインシデント対応フレームワークを策定する: 詳細なプレイブックと定期的な机上演習のプロトコルを含む、包括的なインシデント対応計画を策定します。AWS は、プレイブックのリファレンスライブラリを GitHub で提供しています。 机上演習を実施する: 実際の危機が発生する前に、定期的なシミュレーションの実施を検討してください。シミュレーションによってインシデント対応計画をテストしてギャップを特定し、セキュリティチーム全体で実践的な対応力を身に付けることができます。さまざまな種類の 机上演習 については、AWS が情報を提供しています。 既存のサードパーティのセキュリティプロバイダーを特定する: Security Hub と統合されており、Security Incident Response にデータを提供できるサードパーティのセキュリティプロバイダーを特定します。AWS パートナーが提供する検出結果については、「 検出と分析 」を参照してください。 GuardDuty を実装する: ベストプラクティスに従って GuardDuty を設定し、重要なサービス全体で脅威をモニタリング、検出します。GuardDuty のベストプラクティスは、AWS が「 AWS Security Services Best Practices for GuardDuty 」で公開しています。 期間や組織固有の制約を考慮したうえで目標が現実的かどうか、成功基準を見直してください。例えば、組織にデプロイされている AWS サービスの設定を完全に管理できますか？実装とテストに時間を割ける担当者を確保できますか？関係するステークホルダーがサービスを評価するのに、この時期は適していますか？ Security Incident Response の構成を定義する 成功基準とタイムラインを設定したら、ベストプラクティスとして Security Incident Response の構成を定義します。重要な決定事項には次のようなものがあります。 委任管理者アカウントを選択する: Security Incident Response の委任管理者 (DA) として機能するアカウントを決めます。このアカウントと選択した AWS リージョンで、Security Incident Response のサービスとポータルがホストされます。 AWS Security Reference Architecture (AWS SRA) では、専用のセキュリティツールアカウントを使用することを推奨しています。DA を確定する前に、 考慮事項と推奨事項 に関するドキュメントを確認してください。 アカウントの範囲を定義する: Security Incident Response は組織レベルのサービスとして位置付けられています。組織内のすべてのリージョンにあるすべてのアカウントが、単一のサブスクリプションで保護の対象となります。アカウントを追加または削除すると、それに応じてサービスの対象範囲が自動的に調整されるため、AWS 環境全体を漏れなく保護できます。 検出結果のソースを設定する: 組織のニーズに応じて、取り込むセキュリティ検出結果を決定します。このサービスは、組織全体の GuardDuty の検出結果と、サードパーティパートナーから提供される一部の種類の Security Hub 検出結果を自動的に取り込みます。セキュリティポスチャとインシデント対応機能にとって最も価値のある GuardDuty の保護プランと Security Hub の検出結果を評価してください。 エスカレーションフレームワークを策定する: セルフマネージドのケース、AWS がサポートするケース、プロアクティブなケースといったケースタイプごとに、明確なエスカレーションのしきい値を設定します。また、重大度、影響、必要なリソースに基づいて、ケース送信の要否とケースタイプを決定する権限を誰が持つかを定義します。 分析戦略を実装する: ネイティブの AWS 分析ツール ( Amazon Athena 、 Amazon OpenSearch Service 、 Amazon Detective など) を使用するか、既存のセキュリティ情報およびイベント管理 (SIEM) ソリューションと統合するかを決定します。これらの機能により、コンテキストデータとより深いインサイトを活用して、インシデント対応を強化できます。 デプロイの準備をする 成功基準と Security Incident Response の構成を決定したら、ステークホルダー、目指す状態、期間を明確にします。次の項目を完了して、デプロイに備えます。 プロジェクト計画とタイムラインを作成する: 明確な成功基準、プロジェクトの対象範囲、主要なマイルストーン、現実的な実装タイムラインを含むプロジェクト計画を策定します。推奨されるタイムラインは次のとおりです。 有効化前: GuardDuty と、必要に応じて Security Hub のサードパーティ統合を設定し、リソース計画を立てる 0 日目 – サービスを有効にする 1 週目 – リアクティブなセキュリティインシデント対応ケースを作成する 2 週目 – IT サービスマネジメント (ITSM) ツールに接続する 3 週目 – 机上演習を実施する 4 週目 – サービスから提供されるレポートを確認する ステークホルダーを特定する: CISO、情報セキュリティチーム、SOC 担当者、インシデント対応チーム、セキュリティエンジニア、財務、法務、コンプライアンス、外部のマネージドセキュリティサービスプロバイダー (MSSP)、事業部門の代表者を特定します。 RACI マトリックスを作成する: インシデント対応ライフサイクル全体の役割と責任を定義した詳細な RACI チャートを作成し、説明責任と適切なコミュニケーションチャネルを確保します。 管理アカウントのアクセスを設定する: 管理アクセスを委任するための承認を取得します。詳細については、「 委任 Security Incident Response 管理者アカウントの指定に必要なアクセス許可 」を参照してください。 IAM ロールとアクセス許可を設定する: AWS Identity and Access Management (IAM) ロールを使用して、RACI チャートに沿ったロールベースのアクセス制御を実装します。AWS マネージドポリシーを使用して、ケース管理、エスカレーション、読み取り専用などのロールを用意します。詳細については、「 AWS マネージドポリシー 」を参照してください。 Security Incident Response を有効にする 準備が整ったら、サービスを有効にします。 管理アカウントで Security Incident Response にアクセスする 組織の管理アカウントで AWS マネジメントコンソールに移動し、コンソールの検索バーで Security Incident Response を検索します。 [サインアップ] を選択します。 [委任管理者アカウントを使用 – 推奨] が選択されていることを確認します。委任管理者のアカウント番号を [アカウント ID] フィールドに入力し、 [次へ] を選択します。 手順 3 で設定した委任管理者アカウントにサインインし、 Security Incident Response を検索して、 [サインアップ] を選択します。 委任管理者アカウントでセットアップを完了する メンバーシップの詳細を定義します。 [リージョンの選択] でホームリージョンを選択します。 [メンバーシップ名] に、組織の命名規則に従った適切な名前を入力します。 [メンバーシップの連絡先] で、 [プライマリ連絡先] と [セカンダリ連絡先] の情報を入力します。 組織のタグ付け戦略に従って [メンバーシップタグ] を追加します。 [次へ] を選択します。 アクセス許可を設定します。 [By choosing this option…] (このオプションを選択すると…) で始まるオプションを選択し、 [次へ] を選択します。 サービスのアクセス許可を確認し、 [次へ] を選択します。 メンバーシップの設定と詳細を確認し、 [サインアップ] を選択します。 注: 詳細な手順は、 YouTube のセットアップ動画 で確認できます。 多くの組織では、IR とセキュリティ脅威管理のためのプロセスやアプリケーションスイートが既に確立されています。こうした既存の環境に対応できるよう、AWS は一般的な ITSM およびケース管理アプリケーションとの統合を開発しました。 AWS Security Incident Response は、Jira および ServiceNow との双方向の統合 (ケースの更新が双方向に同期されます) と、 Amazon EventBridge を介した Slack および PagerDuty とのイベント駆動型の統合に対応しています。対応する統合は今後も追加される予定です。AWS では、セットアップ手順を詳しく説明したガイドを GitHub で提供しています。 訳注: 2026 年 10 月時点のユーザーガイドでは、Slack も Jira や ServiceNow と同様に、ケースの更新を双方向で同期する統合として案内されています。詳細は「 ステップ 4: 既存のツールと統合する 」を参照してください。 初日から価値を最大化する サービスを有効にするとすぐに、Security Incident Response は GuardDuty の検出結果の取り込みを開始します。セキュリティパートナーとの連携を設定している場合は、Security Hub CSPM の検出結果も取り込まれます。検出結果は決定論的な評価ロジックによって自動的にトリアージ、モニタリングされます。そして、組織固有のメタデータとセキュリティ境界に基づいて、優先度の高い脅威が Security Incident Response のコマンドセンターにエスカレーションされ、直ちに調査されます。組織は最初から 24 時間 365 日の保護を受けられますが、以下の推奨事項に沿って最適化を行うと、ビジネス固有のリスクとコンプライアンス要件に合わせてカスタマイズされた保護を実現できます。その結果、脅威検出の精度が大幅に向上し、誤検知が減り、対応時間が短縮され、全体的なセキュリティポスチャが強化されます。 Security Incident Response の価値をすぐに最大限引き出すために、初日から リアクティブ な機能を活用することをお勧めします。チームが疑わしいアクティビティを確認した場合や、専門家による調査が必要な場合は、サービスポータルから AWS がサポートするケースを作成し、AWS のセキュリティインシデント対応担当者に直接支援を依頼できます。これらのセキュリティの専門家はチームの能力を効果的に補い、専門知識とガイダンスを提供して、潜在的なセキュリティ上の懸念を迅速に把握、封じ込め、修復できるよう支援します。AWS のセキュリティインシデント対応をオンデマンドで利用できるため、平均解決時間を短縮し、潜在的な影響を最小限に抑えられます。また、社内リソースだけでは対応しきれない複雑なセキュリティシナリオでも、専門家のサポートを確実に受けられます。 リアクティブなサポートへの問い合わせ例を次に示します。 環境内で、さまざまな API コールを実行している疑わしい IP アドレスを確認しました。調査を支援していただけますか？ 2 日前に新しいアカウントが作成されたことが、 Amazon EventBridge ルールおよびエンドポイント検出と対応 (EDR) の統合から通知されました。影響範囲の特定と作成者の調査を支援していただけますか？どのように作成されたのでしょうか？ AWS Identity and Access Management (IAM) ユーザーがクロスリージョンの API コールを実行し、使用していないリージョンでリソースを作成しています。 EDR ソリューションが本番ウェブサイトで異常な動作を検出しました。侵害の可能性があります。 EDR が疑わしいウェブシェルのアップロードとアクティビティを検出しました。調査と隔離を支援してください。 あるユーザーが、自身の権限レベルを超える不正な API アクティビティを実行しました。権限昇格の特定を支援してください。 AWS WAF と Amazon Elastic Compute Cloud (Amazon EC2) インスタンスのセキュリティログの分析を支援してください。侵害の痕跡や疑わしいパターンはありますか？ 次のステップ AWS Security Incident Response の採用を決めて POC をデプロイする場合は、次の対応をお勧めします。 GuardDuty を設定してデプロイし、管理アカウントとメンバーアカウント、重要なサービス、ワークロード全体で、包括的かつ適切な保護範囲を維持します。 サードパーティ製セキュリティツール (CrowdStrike、Lacework、Trend Micro など) が Security Hub と適切に統合されていることを確認します。 セキュリティインシデント対応ツールの変更について、組織内の関連チームに周知します。 まとめ この記事では、AWS Security Incident Response の POC を計画、実装する方法を紹介しました。成功基準の定義、Security Incident Response の構成、Security Incident Response がビジネスニーズを満たしているかどうかの検証といったフェーズに沿って、その進め方を説明しました。 このガイドは、お客様が Security Incident Response の POC を成功させるのに役立ちます。現在提供されている機能の導入を検討する際に、その価値と考慮すべき要素を評価するための指針となります。 その他のリソース AWS Security Incident Response – はじめに Security Hub を介したセキュリティツール統合の設定 Amazon EventBridge を使用した Security Incident Response イベントの管理 Amazon GuardDuty のベストプラクティス AWS Security Hub のベストプラクティス AWS セキュリティインシデント対応ガイド (ベストプラクティス) AWS Managed Services のオファリング AWS Security Incident Response ブログ : インシデント対応ライフサイクルの加速に向けたお客様のジャーニー この記事に関するご質問は、 AWS サポートにお問い合わせ ください。 Kyle Shields Kyle は、AWS で脅威検出とインシデント対応を専門とする Security Specialist Solutions Architect です。現在は、AWS を利用するエンタープライズのお客様が AWS Security Incident Response を導入、運用し、セキュリティポスチャを向上できるよう支援することに注力しています。 Matt Meck Matt は、AI とサイバーセキュリティの分野で 10 年の技術経験を持つ WW Security Specialist で、そのうち 3 年間は AWS で検出と対応の領域に携わっています。ニューヨークを拠点とするアウトドア好きで、サッカーやスキーを楽しんだり、次に登る山を探したりして過ごしています。 Pauly Longani Pauly は Enterprise Support Lead として、お客様と協力しながらクラウドの導入を推進し、ビジネス成果の創出を加速しています。クラウドソリューションを活用した複雑なビジネス課題の解決に深い専門知識を持ち、お客様の立場に立った支援に情熱を注いでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

Kiro の ファイル読み取りツールと検索ツール の説明に、 ハーネス の動作について事実と異なる主張をする一文がありました。この一文は数百のセッションで 61,742 回モデルに届いていました。何の役にも立っておらず、誰かがチケットを起票することもまずなかったでしょう。こうした問題は見つけるのが難しく、修正の良し悪しを判断するのも同じくらい難しいものです。たとえば私たちは、より多くのタスクに合格し、使用トークンも少ない修正をあやうくリリースするところでした。結果をホストごとに分けてみると、改善のほぼすべてが、エージェントがいつもはまり込むループからたまたま抜け出した 1 回の実行によるものだとわかったのです。そのホストを除くと、その修正は遅く、コストが高く、精度も下がっていました。自分の修正を自分で採点するループなら、これをリリースしていたでしょう。 図 1: 平均では改善に見えた修正を、ホスト別に分けた結果 私たちは、AI コーディングエージェントである Kiro を、Kiro 自身の実行結果から改善するための社内トレーシングシステムを構築しました。社内で kiro-trace と呼んでいるこのシステムは、実行結果を読んで Kiro が失敗している箇所や無駄な労力を使っている箇所を見つけ、変更を提案し、その変更を退けるために作られたチェックをくぐり抜けた場合にだけ変更を残します。これらのチェックは、先ほどの例のように勝ちに見えて実際には運にすぎなかった結果を捕まえるためのものでもあります。変更を提案するのはモデルでも構いませんが、受け入れるか退けるかは決定的なコードで判断します。 最初の 1 週間で、kiro-trace は Kiro に 8 件のプルリクエストを出しました。7 件がマージされ、1 件は無関係な理由でクローズされ、コードレビューで差し戻されたものはありませんでした。7 件はいずれも Kiro のプロンプトやツール、つまりツールの説明、引数のチェック、応答の振る舞いを変更するものでした。どれも私たちが計測していた特定のパターンを対象にしており、どれもそのパターンを改善しました。いくつかはこの記事の後半で結果とともに紹介します。残りは、ユーザーに見えるエラーとして表面化したことはなく、指摘するチケットもありませんでした。人が見つけることもできたでしょうが、それには誰にも時間がないほど大量の実行結果を読む必要がありました。これが、Kiro が自己改善を続ける仕組みです。 以下の数値は Amazon 社内での Kiro の利用から得たもので、どの数値も本番環境での推定値ではなく社内実験での差分です。関連記事の Continuous Prompt Evaluation では、人が書いたプロンプトの変更を LLM ジャッジとライブ A/B テストでどう評価しているかを紹介しています。この記事はその続きとして、実行軌跡 (trajectory) の自動マイニング、変更の生成、ハーネスの自己改善を扱います。 自己改善が難しい理由 先月、Kiro のコアモジュールには 141 件のバグ修正コミットが入りました。1 日 5 件近くになり、しかもこれは人が気づいて修正する時間を取れた失敗だけの数です。最も厄介な問題は、きれいなバグ報告の形では現れないことがほとんどです。エージェントがエラーからどう回復するか、ツールをどの順序で使うか、長いコンテキストをどう保持するかの中に潜んでいて、何千もの実際の実行を読み通して初めて気づきます。この記事の冒頭のツール説明の一文は、その種の問題の一例です。 そのため、やるべきことは、Kiro が失敗したり無駄な労力を使ったりしている箇所を見つけ、他の箇所で退行を起こさずに改善するよう Kiro を変更することです。これはバグ修正よりも範囲が広く、誤解を招くツールの説明、形式上の理由で拒否されるツール呼び出し、無駄な呼び出しやトークン、エラー後の不十分な回復、もう役に立たなくなった指示まで含みます。これらを見つけるために何千もの実行を人手で読むことは誰にもできないので、この作業は自動化する必要があります。わかりやすい近道は、エージェントに最初から最後まで自分自身を改善させることですが、多くの自己改善ループがつまずくのはまさにそこです。自分の修正を自分で採点するループは、その場しのぎの局所的な対処をリリースして先へ進んでしまいます。これを正しく行うには、kiro-trace は 4 つの問題を同時に解く必要があります。1) 修正する価値のある失敗を見つける、2) その原因を狙った変更を書く、3) ベンチマークに合わせ込まず汎用的な解決策に保つ、4) 変更によって結果が改善したことを証明する、の 4 つです。自己採点ループは 4 番目を飛ばしており、それがなければ 1 から 3 にやる価値があったのかを知る手段がありません。 図 2: 素朴な自己採点ループ 図のループは、各変更を狙った問題に対してしかチェックしないため、新しい変更が以前の変更で直したものを壊しても、ループは気づきません。これは、ループの外で退行をチェックするものが何もないときに起こります。kiro-trace では、候補は Kiro がすでに合格しているタスクでも実行され、最終候補はベンチマーク全体で変更を加えていない対照群と比較され、プルリクエストはマージ前に通常のコードレビューも通ります。 kiro-trace の仕組み 次の図は、ループの 1 回分の流れを示しています。左側から、ベンチマークと、人が承認したライブトラフィック上の不満という証拠が入ってきます。ループは失敗を読み、診断し、変更するレバーを 1 つ選び、同じ Kiro で変更をオフにした場合とオンにした場合を実行します。その後、3 段階のゲート (スクリーニング、退行チェック、確認) が判定します。合格した変更は人がマージするためのプルリクエストになり、退けられた変更は診断に戻ります。 図 3: kiro-trace のループ 私たちは常に 3 つの役割を分けています。変更を書く者と、それが機能したかを判断する者が同じだと、変更を受け入れてしまいがちだからです。これは私たち自身の失敗から学んだことでもあります。比較結果を人手で判定していたとき、同じ実行を 3 通りに読んでしまったことがあり、それが現在判定をコードに置いている理由です。Kiro は改善される側のエージェントです。ループは変更を提案して適用します。ゲートは普通のコードで、変更を残すかどうかを判定します。この 3 つとは別に、最終的なマージの判断は人が行います。以下は、それぞれの部分を作る中で学んだことです。 ベンチマーク全体ではなく、失敗に対して反復する 毎回ベンチマーク全体を実行するのは時間もコストもかかりますし、タスクは互いに置き換えのきくものではありません。タイムアウトするもの、実質的には長いコンテキストのテストになっているもの、エージェントではなく評価ハーネスが原因で失敗するものもあります。そこでループは、各タスクについてすでに知っていること、つまり失敗の種類、コスト、そもそも本当の信号になっているかどうかを使って、無駄なものを含めずに失敗の種類を網羅する小さなセットを組み立てます。ループはその小さなセットで反復するので、速く低コストです。ベンチマーク全体は、候補が小さなセットで合格した後、最後に一度だけ実行します。変更を加えた実行を、変更を加えていない対照群の実行と全体で比較し、小さなセットでは勝っても全体では勝てない変更はリリースしません。 レビュアーを Kiro 自身の履歴に基づかせる 汎用的な LLM ジャッジは、どんな実行でも読んで修正を提案できますが、あなたのエージェントループや推論レイヤーのことは知りません。kiro-trace のレビュアーは Kiro の実際のコードレビューのコメントや開発者の議論を読んでいるので、このチームが指摘するであろうことを指摘します。レビュアーが検討するアイデアは証拠から来ています。Kiro があるタスクに失敗すると、ループは同じタスクを、同じ入力と予算で、参照エージェントの一団に実行させます。参照エージェントとは、Kiro の実行と比較するための、他の高性能なモデルやエージェントです。Kiro が失敗したところで参照エージェントのどれかが成功すれば、その差は、ループが修正に変えられる具体的な振る舞いになります。これとは別の調査ステップでは、論文から公開コード、同じ問題を他のエージェントがどう解いているかまで、外部の取り組みから汎用的な手法を取り込みます。それらのコードをコピーすることはありません。各候補は、診断した失敗と引用した証拠を記録するので、どの修正もその根拠までたどれます。最近のモデルはすでに多くのことを知っているので、既定ではルールを追加する前に何かを削除することを試みます。 モデルの手が届かないチェックを通じて、差分で判定する 修正を数回実行して平均を見るだけでは、一貫した結果は得られません。先ほどの例のように、外れ値 1 つで結果が大きく振れるからです。そこで変更は、最も安価なものから順に段階的に厳しくなる一連のチェックにかけられ、ほとんどの候補は高価なチェックに進む前に落ちます。通常の A/B テストとは異なり、私たちはスコアではなく差分を計測し、毎回対照群を再実行します。そのため、報告される改善はその変更による寄与であり、新しいモデルならどのみち出していたであろう結果ではありません。また、変更は定めたマージンに照らして退行していないことを示す必要があります。サンプルが少ないと、検出力の弱い検定は既定では何も有意なものを見つけませんが、実際の害を持ち込むことはあり得るからです。最後に、汚染チェックで、エージェントが自分で解くのではなく、タスクのソースやテストを取得するなどネットワークを使ってタスクの答えを調べた合格を除外します。 図 4: 3 段階のゲート 修正の例 弱い候補は早い段階でふるい落とされるので、人のレビュアーに届く変更は、たいてい意味のあるものです。以下にいくつか紹介します。数値はいずれも社内実験での差分です。 すべてのファイル読み取りと検索に付いていた、ハーネスの動作に関する誤った主張。 モデルは 445 サンプルの中でこれを 61,742 回目にしていましたが、何にも使われていなかったので削除しました。 存在しないツールを呼び出すようモデルに指示していたガイダンス。 削除しました。 冗長なファイルの再読み込みを約 83% 削減。 変更されていないファイルを読み直さないようにしました。 厳しすぎる、または説明が不十分なツールの契約 2 件を修正。 サンプリングした 80 セッションで、読み取りツールのスキーマによる拒否 205 件と、 サブエージェント のオーケストレーションでの拒否 167 件を解消しました。 型に厳密なツール入力が、形式上の理由で失敗しなくなった。 モデルがブール値を生のブール値ではなく文字列の “true” として返すと、呼び出しが拒否されて作業が止まっていました。現在はそうした値をリトライ時に補正するので、意図の正しい呼び出しは通ります。 検索のおよそ 8 回に 1 回を失敗させていた、表に出ないファイル検索のバグ。 仕様の誤りによりエラーなしで空の結果が返り、エージェントは検索しても何も見つけられませんでした。修正済みです。 過剰な委任を根本から削減。 単純な直接編集にもサブエージェントを起動させていた一律の委任指示を削除し、役に立つ場面での委任は残しました。 より厳格な参照エージェントを一団に加えたことで、探していなかったものが見つかりました。その参照エージェントの読み取りの 13〜17% を失敗させていた相対パスのバグが、私たちがリリースしているモデルでは 1.6% しか現れていなかったのです。より寛容なモデルが、仕様の欠陥をエラーなしで吸収していました。仕様を修正すれば、同じ契約を共有するすべてのモデルの助けになります。その修正は現在レビュー中です。 最も大きな変更はまだリリースしておらず、チームでレビュー中です。積極的に削除を進めた結果、ループはより小さなツールとプロンプトの構成を作り上げ、Terminal-Bench 2.1 で pass@1 (最初の試行で解けたタスクの割合) が 77.5% に対して 82.4% となり、トークンコストはおよそ 3 分の 1 でした。まだリリースしていないのは、すべての Kiro ユーザーの既定のツールとプロンプトが変わるためで、これはベンチマークの判断というより製品の判断だからです。チームは、より小さな構成を既定にするかどうか、そして削除したツールのうちどれをタスクで必要なときだけ戻すかを検討しています。 kiro-trace はどのようにコンパクションの保持率を 0.82 から 0.92 に上げたか ここまでの修正は小さく、それぞれ独立したものでした。 コンパクション は、ループが 1 つの問題に診断からリリースまで取り組む様子がわかるので、最初から最後まで順を追って見ていく価値があります。コンパクションとは、長い会話がコンテキストの上限に達したときに Kiro が会話を要約し、新しいインスタンスが作業を続けられるようにする仕組みです。次の図は、修正をどう選んだかを示しています。11 個の要約プロンプトの候補 (Kiro から 2 個、外部の取り組みから 5 個、私たち独自のもの 4 個) を、新しいエージェントが要約だけから作業を続けられるかという観点で総当たりで比較しました。 図 5: コンパクション用の 11 個の候補プロンプト 診断する コンパクションの後、Kiro が現在のタスクを放棄して、ずっと前のタスクを自信満々に再開してしまうことがありました。以前の設計では、過去のユーザーメッセージを新しい順に並べた生のダンプをすべての要約の末尾に付け加えていました。そのため要約は最も古い質問で終わり、その直後に「上の要約から再開する」という合図が来ていました。きっかけとなったメッセージが「うん、それやって」のような短いものだった場合、そのメッセージのコンテキストは要約されて消えている一方で、古いスレッドは一字一句残っていたため、エージェントはその了承を別の依頼に結び付けてしまっていました。 計測する kiro-trace は、実際にコンパクションが発生した社内の実際の会話から、最大約 150 万トークンまでの 4 つのサイズ帯でベンチマークを作りました。要約は、それをもとに誰かが作業を引き継げるかどうかで評価しました。各候補の要約だけを他に何も与えずに新しいモデルに渡し、作業を続けられたかを採点したのです。スコアは、要約が行動に移せる内容になっているか、ファイルパスが含まれているか、以前の決定事項が書かれているか、話の流れがつながっているかの 4 点を対象にしました。私たちはこのスコアを保持率 (retention) と呼んでいます。作業を続けるために必要なものがコンパクション後にどれだけ残っているかを、0 から 1 の尺度で表したものです。 外部の取り組みを参考にする kiro-trace は、本番運用されているさまざまなエージェントや公開されている引き継ぎの手法がどのようにコンパクションしているかを読み、それぞれをプロンプトとして組み直しました。全部で 11 個になり、そのうち 5 個は私たち自身のコード以外から来たものです。中身は多岐にわたり、複数のセクションからなる長いテンプレートもあれば、簡潔な固定テンプレートもあり、状況・行動・結果の形で語るナラティブもあれば、いつコンパクションするかを決めるステップもありました。 レバーを見つけてリリースする 修正は、コンパクションをまたいで引き継ぐコンテキストを減らすことでした。以前の Kiro は要約に加えて古いユーザーメッセージの生のリストを残しており、エージェントを誤ったタスクに戻していたのはそのリストだったので、並べ替えるだけでは足りませんでした。外部のプロンプトからは比較対象とすべき設計の幅がわかりましたが、リストをなくすというアイデアは、失敗に対する私たち自身の診断から生まれたものです。修正ではそのリストを削除しました。現在のコンパクションは、簡潔な固定テンプレートで書かれサイズに上限のある短い要約と、直近のターンを残します。そして、どのタスクも名指ししない固定の再開の合図で終わります。1 つのセッションでは複数のタスクが進行中のことがあり、そのうち 1 つを推測することが誤った結び付けの原因だったからです。保持率は 0.82 から 0.92 に上がり、この修正はリリースされました。 ループはすべての候補について同じ記録を残します。診断した失敗、使った証拠と外部の手法、変更した 1 点、計測した結果です。どの部分もタスクの答えそのものには触れません。 ループ自体をどう改善し続けているか kiro-trace は Kiro と並行して、ループ自体も改善し続けています。最初は私たち自身のこれまでの研究とコードから引き出したチェックから始まり、その後は失敗から育ってきました。新しいチェックはどれも、ループかチームが一度何らかの具体的な形でだまされたことがあるから存在しており、その多くは Kiro のバグではなく、私たちの計測方法の誤りでした。 あるケースでは、正しい修正の出力が採点器に届いていなかったため、0/5 と採点されました。別のケースでは、タスクのセットアップがエージェントに自分の誤りを元に戻す手段を与えており、それが本物のバグを隠していました。また、古いチェックアウトのせいで、前日に上流で修正済みだったものに対してプルリクエストを出してしまったこともあります。こうした一つひとつが、ループのコードのチェックになりました。 確認済みの修正はそれぞれ、その実行に関する決定的なアサーションを恒久的な退行テストスイートにも追加します。そのため、一度直した失敗が検出されずに再発することはありません。現在、これらのチェックは 1 つのチームから生まれたものです。次のステップは、Amazon がすでに対価を払って得た教訓である、解決済みのインシデントやチケットをもとにチェックを作ることです。そうすることで、お客様はより信頼性の高いエージェントと、より良い開発者体験を得られます。 まとめ kiro-trace は、Kiro 自身の実行の中から問題を見つけ、変更を 1 つずつ提案し、決定的なチェックとその後の人のレビュアーが受け入れた場合にだけ変更を残します。1 週間で 7 件の修正がマージされ、コンパクションの取り組みでは保持率が 0.82 から 0.92 に上がりました。 得られた教訓 提案する者と判定する者を分けること。受け入れと却下は、モデルの手が届かないコードに置きます。 差分で判定し、毎回対照群を再実行すること。新しいモデルだけでもスコアは動くからです。 「有意な害がない」ことは害がないことと同じではなく、小さな害は変更を重ねるうちにすぐに積み重なります。マージンに照らして検定します。 確認済みの修正はすべて、失敗したメカニズムに対する恒久的な退行チェックにすること。そうすれば、その 1 つの結果だけでなく、より広い範囲をカバーできます。 追加する前に削除を試すこと。最も安全な改善は削除であることが多く、モデルが良くなるほどその傾向は強まります。 Kiro のユーザーにとっては、無駄な呼び出しが減り、委任がより慎重になり、長い会話の中で Kiro が自分のしていたことをよりよく把握できるようになるということです。kiro-trace による変更は、それを退けるために作られたチェックを備えたゲートを通過し、その後に人のコードレビューを経るまで、ユーザーに届くことはありません。私たちはエージェントの実験を、まず何を退けたかで評価します。ほとんどの候補はゲートを通過できず、通過したものこそが開発者体験を意味のある形で改善できる変更です。 Kiro は今すぐ お試しいただけます 。 この記事は Kiro ブログの How Kiro fixes itself, and how we keep the fixes honest を翻訳したものです。

はじめに AWS DevOps Agent の調査において、最初の課金対象クエリを実行する前に、どれくらいの費用がかかるかを確認の上、利用するかどうかを判断できます。Investigation Cost Guardrail スキルは、 AWS DevOps Agent にコスト意識をもたらし、調査の開始前にどこまで調べるかをチームが把握・制御できるようにします。 本記事では、オープンソースの AWS DevOps Agent スキルである Investigation Cost Guardrail を紹介します。このスキルは、Amazon CloudWatch、AWS X-Ray、Amazon Athena、Amazon DynamoDB、Amazon S3、AWS CloudTrail といった設定済みの AWS サービスや、サードパーティーツール、エージェント自身のネイティブツールをまたいでエージェントが実行するオペレーションを分類します。そのうえで、見積もり時点における対象リージョンの最新料金を取得します。本記事では、仕組みを説明し、具体的なシナリオを示しながら、自律型 AI にとってコスト意識がセキュリティガードレールと同じくらい重要になりつつある理由を解説します。 DevOps の考え方は、開発と運用の間にあるサイロを取り除くことです。AWS DevOps Agent も同じ原則を体現しています。アプリケーションに関する知識と運用の専門知識の隔たりを埋め、両方の領域を横断してデバッグできる、チームのもう一人の SRE のように機能します。DevOps の考え方が文化とプラクティスをもたらすのに対し、エージェントは自律的な実行をもたらします。 「You build it, you run it（作った人が運用する）」が説明責任を意味していたのに対し、AWS DevOps Agent が目指すのは、大規模環境における持続可能性です。チームの専門知識を 24 時間 365 日利用できるように拡張することで、システムが成長し、単一のチームだけでは監視しきれなくなっても、このオーナーシップモデルを維持できるようになります。 本記事のシナリオとコストの数値はあくまで例です。実際のコストと結果は、リージョン、データ量、現在の AWS 料金によって異なります。 安心して任せるための原則：場数で培われるコスト感覚 あるアクションにどれくらいの費用がかかるかを見積もることは、クラウドで身につけるのが最も難しい感覚の一つです。広範なクエリやテーブル全体のスキャンから学び、実行前にスコープを絞ることが自然にできるようになるまで、時間をかけて身につけていくものです。 AWS DevOps Agent は、シニア SRE が持つ自律性と高度な調査能力をもたらします。このガードレールを使うことで、エージェントは初日から同じコスト意識を備え、実行する各アクションに一貫して適用します。経験豊富なエンジニアが本能的に実践するのと同じ規律で、実行前にスコープとコストを見積もります。 AI ガードレールを取り巻く状況 AI ガードレールとは、AI システムが安全かつ責任を持って、定義された境界内で動作し続けるための安全装置です。AI モデルがどのように出力を生成し、アクションを実行するかを統制するポリシー、技術的な制御、監視の仕組みが含まれます。 ガードレールに関する議論の多くは、コンテンツの安全性、プロンプトインジェクションの防止、意図しない情報開示に焦点を当てています。これらは重要ですが、AI エージェントが「考える」段階から「行動する」段階に移った瞬間、もう一つの側面が極めて重要になります。それは、アクションを実行する前に、そのアクションのコストを把握することです。 従来のソフトウェアのコストは決定論的です。API コールのコストは、呼び出す前にわかります。一方、自律型エージェントは、どの API を呼び出すか、何回呼び出すか、どのスコープを対象にするかを動的に判断します。このスキルにより、こうした動的なコスト構造を事前に可視化し、調整できるようになります。これにより、コストは調査において明示的に考慮される判断材料になります。 AI エージェントの責任共有モデル AWS DevOps Agent では、責任共有モデルを自律型エージェントにまで拡張できます。 AWS DevOps Agent は、調査機能と、それを統制するためのエージェント指示やスキルなどの制御手段を提供します。 利用者はガードレールを設定し、しきい値を決め、エージェントが動作する境界を定義します。 実際の運用で定着するガードレールには、次の 3 つの共通点があります。 必要に応じて有効・無効を切り替えられる（オプトインまたはオプトアウト） 理解するための専門知識が不要 介入時に明確なガイダンスを提供する これが、このガードレールの設計思想です。クラウド料金の専門家にならなくても、コストの透明性を得られます。 AWS DevOps Agent スキルとは コストガードレールの詳細に入る前に、スキルとは何か、そしてエージェントインストラクションとどう違うのかを理解しておくと役立ちます。 スキルは、調査手順と運用ナレッジをまとめた再利用可能なパッケージです。現在のタスクに関連する場合、エージェントによってオンデマンドで読み込まれます。これにより、AWS DevOps Agent は汎用アシスタントから、利用者のインフラストラクチャに精通したスペシャリストへと変わります。 最もシンプルな形では、スキルは SKILL.md とオプションの参照ファイルを含むディレクトリです。 SKILL.md ファイルには、次の内容が含まれます。 フロントマター：名前と説明 エージェントが調査中に従う段階的なインストラクション description フィールドは非常に重要です。エージェントはこのフィールドを使って、そのスキルを読み込むかどうかを判断します。調査が始まると、エージェントは利用可能なすべてのスキルの説明を読み、関連するものを選択します。複数のスキルを同時に読み込むこともできます。 スキルとインストラクション：スーパーパワーと基本命令 AWS DevOps Agent には、運用ナレッジを注入するための 2 つの仕組みがあります。 &nbsp; スキル エージェントインストラクション（AGENTS.md） 読み込まれるタイミング オンデマンド（エージェントが説明と現在のタスクを照合） 常時（無条件、すべてのセッション） コンテンツ形式 Markdown、または補助ファイルを含む ZIP バンドル Markdown のみ、補助ファイルなし 適用範囲 特定のイベントタイプに特化 セッションをまたいで適用されるグローバルポリシー 例えるなら 必要なときにエージェントが発動するスーパーパワー エージェントが常に従う基本命令 ユースケース 調査手順、トラブルシューティングのプレイブック セキュリティポリシー、コーディング標準、組織のガイドライン エージェントインストラクションは、すべてのセッションで無条件にエージェントのコンテキストへ注入されるシステムプロンプトです。常に適用しなければならない常設ポリシーには、インストラクションを使用します。 スキルは、関連するときにだけオンデマンドで読み込まれるスーパーパワーです。参照ファイル、メトリクステーブル、複数ステップの手順を含めることができ、必要のないセッションに読み込むと無駄になるような、深く専門的な能力を表現します。 重要な違いは、インストラクションがエージェントにどのように振る舞うかを教えるのに対し、スキルは特定の問題をどのように調査するかを教える点です。 ソリューション概要：調査コストガードレールのワークフロー 次の図は、調査におけるコストガードレールの位置を示しています。エージェントが調査対象リソースを特定した後、課金対象クエリを実行する前という、可能な限り早い段階でワークフローに介入します。 図 1：AWS DevOps Agent における Investigation Cost Guardrail スキルの仕組み 仕組み：4 層アーキテクチャ 各 AWS サービスの各操作について課金対象かどうかをハードコードするのではなく、このスキルは上の図 1 に示した 4 層アーキテクチャを使用します。これらの層は連携して、レジストリに登録されていないサービスやエージェント自身のネイティブツールも含め、AWS サービス全体の操作を分類します。 Layer 0：ネイティブツールの分類 エージェント自身の各ツールには、課金対象か非課金対象かが明示されています。PromQL（ get_prometheus_metrics ）、 use_splunk とその他のサードパーティー統合、shell、サブエージェントの起動はすべて分類されます。 use_aws もこれらと同様ですが、後続のレイヤーでさらに詳細に分類されます。 Layer 1：ヒューリスティックルール 動詞に基づく分類は、レジストリに記載されていないサービスも含め、サービスを横断して機能します。Describe、List、Get、Lookup、Check、Validate、Tag、Untag はメタデータを返すもので、通常はデータスキャンの料金が発生しません。Query、Scan、Execute、Invoke、Insights などの動詞はデータを処理またはスキャンするため、課金対象として扱われます。多数のページにわたるページネーションを伴う広範な List や Describe の呼び出しには、注意フラグが付けられます。 Layer 2：既知の有料操作レジストリ 有料操作について、レジストリは、正確な計算式と、料金を取得するために使用する AWS Price List API のフィルターを保持しています。レジストリ自体は料金を保持しません。 Amazon CloudWatch （Logs Insights、GetMetricData、GetInsightRuleReport、Live Tail、スキャンされた PromQL サンプルを含む）、 AWS X-Ray 、 Amazon Athena 、 Amazon DynamoDB 、 Amazon S3 のリクエストが対象です。運用担当者は独自のエントリーでレジストリを拡張できます。 Layer 3：自己学習型のレスポンス検証 操作の実行後、スキルは BytesScanned 、 ConsumedCapacity 、 TracesProcessedCount など、課金対象の使用量を示すフィールドがレスポンスに含まれていないかを確認します。以前は未分類だった操作がこれらのフィールドのいずれかを返した場合、スキルは調査の残りの期間、その操作を課金対象として分類します。これにより、調査が進むにつれてカバレッジが向上します。 これらのレイヤーが連携することで、レジストリに記載されていないサービスの操作も含め、ほとんどの操作を動詞に基づいて分類できるように設計されています。レスポンス検証は、ルールが見落とした操作を検出するのに役立ちます。 リージョンごとのライブ料金 料金は AWS リージョンによって異なるため、基準料金を保持せず、見積もり時に AWS Price List API を使用して、ワークロードのリージョンの料金をリアルタイムで取得します。 リージョンはリソース ARN から取得されます。 各料金は pricing:GetProducts で検索され、ワークロードのリージョンを使って一致する料金が選択されます。 その結果、ワークロードが実行されるリージョンの現在の定価に基づくコスト見積もりが得られます。 クロスリージョンへの対応 対象リージョンが Agent Space のリージョンと異なる場合、スキルはデータ転送コストを追加します。特定の送信元から送信先までの経路に対応する料金をリアルタイムで取得し、経路ごとにキャッシュします。リージョン間の料金は地域によって大きく異なるため、一律の料金を仮定せず、その経路に対応する正確な料金を検索します。 判定ゲート 計画された呼び出しの分類、料金の取得、予算との照合が完了すると、ガードレールは次の 3 つの方法のいずれかで判定します。番号は、上の図 1 に示した結果に対応します。 Proceed（続行） ：見積もりが残りの予算内に収まっています。呼び出しは中断なく実行され、調査タイムラインにはステップごとの見積もりと累計額の両方が記録されます。 Warn（警告） ：呼び出しは予算内ですが、非効率の兆候が見られます。たとえば、広範な PromQL クエリ、単一サービスに対する 200 回以上の呼び出し、リージョン間の転送などです。ガードレールは呼び出しの実行を許可しつつ、時間枠の短縮、ラベルフィルター、ステップ間隔の拡大など、コスト効率の高い代替案を添えます。 Halt（停止） ：見積もりが残りの予算を超える場合、時間枠が指定されずにスキャンが要求された場合、またはライブ料金検索で料金を取得できなかった場合、呼び出しは実行されません。ガードレールは最悪ケースの見積もりを提示し、データをスキャンする前に指示を求めて一時停止します。 ガードレールが停止した場合は、必ず次に進むための方法を提案します。 正確なタイムスタンプ、またはより短い時間枠を指定する 特定の 1 つのサービスまたはロググループを対象にする 既知のエラーメッセージを指定する。これにより、エージェントは Logs Insights クエリの代わりに、GB 単位のスキャン料金が発生しない FilterLogEvents API で検索できる リージョン間の転送料金を避けるため、クエリを同一リージョンのソースに限定する シナリオ例 次のシナリオは、同じ決済ワークロードに対する 3 つのリクエストを示しています。いずれもエンジニアが DevOps Agent コンソールに入力したものです。課金対象の呼び出しを実行する前に、ガードレールは必ずライブ料金を取得し、コストを見積もり、調査ごとの予算 $10.00 と照合します。異なるのは結果だけです。見積もりは定価に基づいており、AWS 無料利用枠の適用分は含まれません。 シナリオ A：対象を絞り、時間枠を指定したリクエスト（続行） SRE は次のように依頼します。 「今日の 13:57～14:27 UTC に us-east-1 の payments-prod-alb で発生した 5xx エラーを調査してください」 30 分の時間枠が指定されているため、スキルは Amazon CloudWatch Logs Insights のスキャン量を算出できます。スキャン量は 1.34 GB で、ライブ料金は $0.005/GB なので、コストは $0.0067 です。$10.00 の予算内なので、クエリは実行され、調査が続行されます。 図 2：最初の課金対象呼び出し前にライブ料金、スキャン見積もり、予算チェックが実施され、その後、実際のコストを検証。実際のコストはリージョン、データ量、現在の料金によって異なります。 シナリオ B：1 か月分のデータを対象とする広範なリクエスト（停止して確認） クラウドアーキテクトは次のように依頼します。 「9 月全体の payments-api のすべての 5xx エラーと DynamoDB のスロットリングを相関分析してください」 スキャン対象は 2,673 GB、コストは $13.37 になるため、エージェントは開始前に停止し、料金付きの選択肢を提示します。追加の $3.37 を承認する、対象期間を 7 日間（$3.74）、24 時間（$0.54）、またはインシデントの時間枠（$0.007）に短縮する、データスキャン料金のないメトリクス相関を使用する、あるいはここで終了する、という選択肢です。この時点では、データは一切スキャンされていません。 図 3：エージェントは予算超過時に停止し、エンジニアが続行するための選択肢を料金付きで提示。実際のコストはリージョン、データ量、現在の料金によって異なります。 シナリオ C：有料スキャンを行わないよう指示したリクエスト（スキャン料金のない API に切り替え） DevOps エンジニアは次のように依頼します。 「02:45～03:15 UTC に payments-worker が payments-events-dlq へイベントを送信している理由を調べてください。今回は有料のスキャンを一切実行しないでください」 2 つの有料呼び出しについて料金が算出されます。ワーカーのロググループに対する Amazon CloudWatch Logs Insights クエリ（38.37 GB、$0.19）と、12 個のメトリクスを取得する GetMetricData バッチ（$0.004）です。どちらも予算内ですが、エンジニアが有料スキャンを除外したため、エージェントはデータスキャン料金のない代替手段に切り替えます。エラーが既知の文字列であるため FilterLogEvents を使用し、GetMetricData の代わりに、メトリクスを 1 つずつ取得する GetMetricStatistics を使用します。後者は AWS 無料利用枠の CloudWatch API リクエスト数に計上されます。その結果、checkout-api の新しいリリースによってイベントスキーマが変更されたことが判明しました。 図 4：予算内でもエンジニアの指示に従ってスキップし、Logs Insights クエリと GetMetricData バッチの代わりとなる、データスキャン料金のない呼び出しを表示。 より広いパターン：トークン予算からアクション予算へ このガードレールは、従量課金 API を呼び出す自律型 AI エージェントの設計パターンを示しています。エージェントは行動する前に、その行動にどれくらいの費用がかかるかを把握できます。 これは、AI エージェントの経済性を、トークン予算（推論のコスト）からアクション予算（実行のコスト）へと捉え直すものです。エージェントがツールへアクセスできる場合、真の価値が生まれるのは、エージェントが実行する下流のアクションです。その価値を事前に可視化することで、意図的かつ利用者が承認した予算へと変えることができます。 クラウドアーキテクトや SRE は、何年もかけてこの感覚を身につけます。コストガードレールにより、エージェントは初日からこの感覚を備え、一貫して適用します。午前 3 時のインシデント対応を含め、プレッシャーのかかる状況でも、この規律を維持できるように設計されています。 技術的な実装 このスキルは、コアエージェントを変更することなく、エージェントの既存のスキル階層へ組み込まれます。各調査の前に、次の手順で事前チェックとして実行されます。 エージェントによる探索結果（クエリを実行する予定のロググループ、メトリクス、トレース）を読み取る 計画された各操作を 4 つのレイヤーで分類する AWS Price List API からリージョンごとのライブ料金を取得する コストの完全な内訳とともに、構造化された判定（続行または一時停止）を返す 一時停止する場合は、スコープを絞るための具体的なガイダンスを提供する AWS DevOps Agent は、すべてのセッションに権限のガードレールを適用します。常時適用されるポリシーであるエージェントインストラクションと、オペレーターに明示的な承認を求めるダイレクテッドアクションを組み合わせることで、利用者が定義した境界内でエージェントを運用し続けることができます。 開始方法 Investigation Cost Guardrail は、AWS の GitHub 組織にあるオープンソースリポジトリ aws/tools-for-devops-agent で公開されており、AWS DevOps Agent サービスチームが管理しています。このリポジトリには、インポートしたり独自にカスタマイズしたりできる、コミュニティ作成のスキル、カスタムエージェント、MCP サーバーが含まれています。 前提条件 少なくとも 1 つの AWS アカウントが接続された AWS DevOps Agent の Agent Space Agent Space が引き受ける IAM ロールを更新する権限 手順 1：IAM 権限を付与する このスキルは、見積もり時に AWS Price List Query API を使用してすべての料金を取得します。接続されている各アカウントで、Agent Space が引き受ける IAM ロールに、次のポリシーをアタッチします。権限の詳細については、スキルの README にある Required IAM permissions を参照してください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "ResolveLivePricing", "Effect": "Allow", "Action": "pricing:GetProducts", "Resource": "*" } ] } 手順 2：スキルをインストールする 次の 2 つの方法のいずれかで、スキルを Agent Space に追加します。 オプション A：GitHub 統合（チームに推奨） ： aws/tools-for-devops-agent をフォークするか、 skills/investigation-cost-guardrail/ ディレクトリを自分で管理するリポジトリにコピーし、Agent Space の GitHub 統合を通じてインポートします。これにより、スキルをバージョン管理下に置き、コミットを固定し、プルリクエストで SKILL.md の変更をレビューし、独自の検索パターンで references/pricing-reference.md を拡張できます。 オプション B：直接アップロード ：リポジトリからスキルを .zip としてダウンロードし、Agent Space コンソールでユーザー定義スキルとしてアップロードします。アーカイブでは、スキルディレクトリのルートに SKILL.md を置き、その隣に references/ フォルダーを配置する必要があります。 investigation-cost-guardrail/ ├── SKILL.md └── references/ └── pricing-reference.md 手順 3：スペースレベルの指示を追加する スキルは、説明とのマッチングに基づいてオンデマンドで読み込まれます。各調査でコストガードレールが読み込まれるようにするためには、Agent Space のインストラクションに次の内容を追加します。 “Before executing any tool call that interacts with AWS or third-party services, ALWAYS consult the cost guardrail skill to estimate cost and check budget. Never skip cost evaluation” 日本語訳：「AWS またはサードパーティーサービスとやり取りするツール呼び出しを実行する前に、コストの見積もりと予算の確認のため、必ずコストガードレールスキルを参照してください。コスト評価を決して省略しないでください」 これは、前述した 2 つの仕組みを組み合わせたものです。指示は常設命令であり、スキルはその命令によって呼び出される能力です。 手順 4：環境に合わせてしきい値を調整する このスキルには、調査ごとに $10.00 という保守的なデフォルト予算が設定されています。Agent Space の設定に自然言語の指示を追加するか、 SKILL.md ファイルを直接編集することで上書きできます。たとえば、「調査ごとの予算を $25.00 にしてください」と指定します。 スキルファイルを編集せずに、既知の有料操作レジストリを拡張したり、特定の操作に対する制御を強化したりすることもできます。 opensearch:Search を、1,000 リクエストあたり $0.01 の有料操作として扱う Athena クエリを実行する前に必ず承認を求める 手順 5：検証する ガードレールが有効であることを確認するため、2 つの調査を実行します。 最初に、データ量の多いロググループに対して時間枠を指定せず、たとえば「order-service のエラーを調査してください」という調査を開始します。エージェントは logs:StartQuery を実行する前に停止し、ロググループに保持されている全データ量から算出した最悪ケースの見積もりを提示し、時間枠または既知のエラー文字列を求めるはずです。 次に、時間枠を限定して繰り返します。「今日の 14:00～14:30 UTC に order-service で発生したエラーを調査してください」と入力します。調査タイムラインには、最初の課金対象呼び出しの前に予算ステータスブロックが表示され、各料金には、その料金がどのリージョン向けに取得されたかが明記され、調査が続行されるはずです。 COST CHECK Budget: $10.00 | Spent: $0.00000 | Next: 1 × logs:StartQuery (6.4 GB × $0.005/GB) → $0.03200 | Projected: $0.03200 WITHIN BUDGET Proceeding 最初の調査が一時停止せずに進んだ場合は、手順 3 のスペースレベルの指示が存在することを確認してください。2 つ目の調査が料金取得エラーで停止した場合は、 pricing:GetProducts のアクセス許可とツールポリシーにおける us-east-1 の許可を再確認してください。 クリーンアップ ガードレールと、それを支える設定を削除するには、セットアップ手順を元に戻します。 手順 3 で追加したスペースレベルの指示を Agent Space の指示から削除する Agent Space が引き受ける IAM ロールから、 pricing:GetProducts のインラインポリシー（および追加した読み取り専用のサイジングポリシー）を削除する Agent Space から Investigation Cost Guardrail スキルを削除する まとめ AWS DevOps Agent は自律的なイベント対応を実現します。その自律性にコスト意識を加えることで、チームは運用成熟度の次の段階へ進むことができます。つまり、利用者が定義した透明性のある予算内でインシデントを迅速に解決できます。 Investigation Cost Guardrail は、経験豊富なエンジニアが本能的に理解している原則、すなわち実行前にコストを評価するという原則を適用します。サービスを横断して操作を分類し、AWS Price List API からリージョンごとの現在の料金を取得して、調査コストを透明性があり、利用者が管理できる予算へと変えます。エージェントの速度を低下させるものではありません。エージェントにコスト判断力を与えるものです。 開始するには、GitHub の tools-for-devops-agent から Investigation Cost Guardrail スキルをクローンし、AWS DevOps Agent の設定に追加して、調査にコストを意識した事前チェックを導入してください。 新しいコスト分類や料金パターンについてアイデアがありますか。このガードレールは自由に拡張できます。 investigation-cost-guardrail をフォークし、チームが最も頻繁に実行する操作を追加して、独自の料金モデルを参照するようにしてください。構築したものを共有するには、Issue を作成するか、プルリクエストを送信してください。 Ines Attia Ines は AWS のテクニカルアカウントマネージャーです。エンタープライズのお客様と協力し、スケーラブルでレジリエントかつ Well-Architected なワークロードを設計しています。クラウドアーキテクチャに関する専門知識を生かし、オブザーバビリティと AIOps を運用上の優秀性の向上に適用し、技術上の選択をビジネス成果へ結び付けています。 Tipu Qureshi Tipu は AWS のシニアプリンシパルエンジニアで、DevSecOps 向けエージェンティック AI システムのフルスタック設計と実装を率いています。最先端の AI モデル、専門スキル、MCP ツールを活用する自律型エージェントを構築し、クラウド運用、開発者ワークフロー、カスタマーサポートを変革しています。15 年以上にわたり、運用上の優秀性への情熱を持って、多様な分散システムを大規模に設計、運用、構築してきました。 本ブログは、2026 年 10 月 6 日に公開された「 Control investigation costs before they start with AWS DevOps Agent 」の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。

本ブログは 2026 年 9 月 3 日に公開された AWS Blog “ Set up OpenAI ChatGPT Codex with LiteLLM on Amazon ECS and Amazon Bedrock ” を翻訳したものです。 OpenAI ChatGPT Codex と LiteLLM を組み合わせることで、生成 AI コーディングエージェントに対してエンタープライズ向けの一元的な制御を実現できます。これらのエージェントは、開発者によるリポジトリの理解、コードの記述、テストの実行、複数のステップからなるエンジニアリングタスクの完了を支援します。組織が個人による試験的な利用から、管理体制のもとでの導入へと移行するにつれて、チームにはモデルへのアクセスを制御し、使用量の帰属先を明確にするための一貫した方法が必要になります。また、予算とレート制限を適用し、モデルアクセス経路を監視する必要もあります。 OpenAI Codex (Codex) は、タスクループを開発者のワークステーション上で実行します。ローカルファイルを読み取り、ローカルのサンドボックスと承認設定の範囲内で、承認済みのツールを実行します。その場合でも、モデル推論は、お客様の AWS アカウント内のインフラストラクチャを経由するようにルーティングできます。 この記事では、お客様が運用する LiteLLM ゲートウェイを Amazon Elastic Container Service (Amazon ECS) にデプロイする手順を説明します。ゲートウェイを Amazon Bedrock 上の OpenAI モデルに接続し、ゲートウェイの Responses API を使用するように Codex を設定する方法を紹介します。また、セマンティックな継続 (semantic continuation)、ストリーミング、関数呼び出し (function calling) を検証する方法も紹介します。最後に、AWS IAM Identity Center による直接アクセスや、Portkey のようなマネージドゲートウェイの方が適しているケースについて説明します。 完全な実装は guidance-codex リポジトリ で公開されています。この記事で主に取り上げる構成については、「 LiteLLM on AWS quickstart 」の手順に従ってください。 ソリューションの概要 次のアーキテクチャでは、Codex と Amazon Bedrock の間に LiteLLM を配置します。LiteLLM は、モデル認証、ルーティング、予算、レート制限、ゲートウェイテレメトリを共通で管理するコントロールポイントになります。ローカルのタスクとツール実行のループは、引き続き Codex が担当します。 次の図は、開発者のワークステーションからゲートウェイを経由して Amazon Bedrock に到達し、再び戻ってくるまでのエンドツーエンドのリクエストフローを示しています。番号付きの 5 つのステップで、1 回のモデルターンがインフラストラクチャをどのように通過するかを確認してください。 図 1: Codex はモデルリクエストを LiteLLM 経由で送信し、ローカルのツール実行は引き続き開発者のワークステーション上で行われます リクエストフローは次の 5 つのステップで進みます。 Codex は、現在のタスクコンテキストと利用可能なツール定義を、ゲートウェイの /v1/responses エンドポイントに送信します。 Application Load Balancer と AWS WAF がネットワーク層とウェブ層の制御を適用したうえで、AWS Fargate 上の LiteLLM にリクエストを転送します。 LiteLLM は呼び出し元を認証し、設定されたモデルと利用量ポリシーを確認したうえで、ECS タスクロールを使用して Amazon Bedrock 上の承認済みモデルを呼び出します。 Amazon Bedrock は、テキストまたは関数呼び出しを LiteLLM 経由で返します。 モデルがツールの実行を要求した場合、Codex はサンドボックスと承認ポリシーの範囲内でそのツールをローカルで実行します。Codex は次の Responses リクエストでツールの実行結果を LiteLLM 経由で送信し、ループが続きます。 リファレンスデプロイでは、次のサービスも使用します。 LiteLLM の状態、使用状況、予算データを保存する Amazon Relational Database Service (Amazon RDS) for PostgreSQL ゲートウェイとスコープ付きキーのシークレットを保存する AWS Secrets Manager と、それらのシークレットを暗号化する AWS Key Management Service (AWS KMS) Amazon CloudWatch のログ、CloudWatch Container Insights、アラーム、デプロイのヘルス監視 イミュータブルなゲートウェイイメージを格納する Amazon Elastic Container Registry (Amazon ECR) オプションで利用できる AWS WAF のマネージド保護と、送信元 IP に基づくレート制限 この役割分担が重要です。ゲートウェイに AWS アカウント内の汎用シェルが与えられるわけではなく、Codex のローカル承認を置き換えるものでもありません。ゲートウェイが制御するのは、個々のモデルターンです。 このパターンで LiteLLM を使用する理由 LiteLLM は、API 互換のエンドポイントを通じて、モデルルーティング、仮想キー、予算、レート制限、使用状況テレメトリを提供するオープンソースの AI ゲートウェイです。このパターンでは、お客様が自身の AWS アカウント内で LiteLLM とそれを支えるインフラストラクチャを運用します。 ネイティブの AWS アイデンティティ、AWS Identity and Access Management (IAM) ポリシー、AWS CloudTrail のログでお客様の要件を満たせる場合は、Amazon Bedrock への直接アクセスが最もシンプルな選択肢です。開発者、チーム、モデルプロバイダーをまたいで一貫した追加の制御がシステムチームに必要な場合に、ゲートウェイが役立ちます。 次のような要件がある場合、お客様が自ら運用する選択肢として LiteLLM が有効です。 承認済みのモデルエイリアスのみを許可する ユーザー単位またはチーム単位のスコープ付きゲートウェイキーを発行する 厳格な予算上限と、1 分あたりのリクエスト数または 1 分あたりのトークン数の制限を適用する ルーティングとフォールバックのポリシーを一元化する アップストリームのモデルが共有の ECS タスクロールを使用する場合でも、ゲートウェイレベルでアイデンティティを保持する ゲートウェイ、データベース、ネットワーク、ログ、アップグレードプロセスを自身の AWS アカウント内で運用する 主なトレードオフは運用責任です。ゲートウェイの可用性、データベースのライフサイクル、バージョンのアップグレード、インシデント対応、キャパシティプランニングは、お客様のチームが担います。 Amazon ECS に Codex 用の LiteLLM ゲートウェイをデプロイする このセクションでは、LiteLLM ゲートウェイをデプロイして Amazon Bedrock に接続し、ゲートウェイ経由でリクエストを送信するように Codex を設定する手順を説明します。 前提条件 このウォークスルーには、次のものが必要です。 AWS アカウントと、仮想プライベートクラウド (VPC)、Amazon ECS、Elastic Load Balancing、Amazon RDS、Amazon ECR、AWS WAF、IAM、AWS KMS、Secrets Manager、CloudWatch の各リソースを作成する権限 デプロイ先の AWS リージョンにおける、Amazon Bedrock 上の選択した OpenAI モデルへのアクセス 認証済みプロファイルを設定した AWS コマンドラインインターフェイス (AWS CLI) バージョン 2 Buildx を含む Docker Codex CLI Python 3 HTTPS でデプロイする場合は、パブリックな Amazon Route 53 ホストゾーン、または同じリージョン内の既存の AWS Certificate Manager (ACM) 証明書 このウォークスルーは、米国東部 (バージニア北部) リージョン (us-east-1) で、ゲートウェイエイリアス openai.gpt-5.5 を使用して検証しました。このエイリアスは、LiteLLM の設定で bedrock_mantle/openai.gpt-5.5 にマッピングされています。利用できるモデルはアカウントとリージョンによって異なります。 コストに関する注意: このソリューションでは、Application Load Balancer、Fargate タスク、Amazon RDS、AWS WAF、ログ、モデル推論など、課金対象のリソースが作成されます。サンプルの VPC でもネットワーク料金が発生する場合があります。ご利用のリージョンの最新料金を確認し、ウォークスルーの完了後は「クリーンアップ」セクションの手順に従ってください。 Amazon ECS に LiteLLM をデプロイする リポジトリをクローンし、ローカルのデプロイ環境ファイルを作成します。 git clone https://github.com/openai-on-aws/guidance-codex.git cd guidance-codex git checkout feat/enterprise-gateway-readiness cp deployment/litellm/.env.deploy.example \ deployment/litellm/.env.deploy 実際の .env.deploy ファイルは Git の追跡対象外です。使用する AWS プロファイル、リージョン、送信元 CIDR、DNS または証明書の値を設定します。次の抜粋は、本番環境を想定した設定例です。 AWS_PROFILE=your-profile AWS_REGION=us-east-1 BEDROCK_REGION=us-east-1 ENABLE_TLS=true GATEWAY_DOMAIN_NAME=codex-gateway.example.com ROUTE53_HOSTED_ZONE_ID=Z0123456789EXAMPLE ALB_CERTIFICATE_ARN= ALLOWED_CIDR=203.0.113.10/32 ENABLE_WAF=true DB_MULTI_AZ=true DESIRED_COUNT=2 MIN_TASK_COUNT=2 MAX_TASK_COUNT=10 ALB_CERTIFICATE_ARN を ROUTE53_HOSTED_ZONE_ID の代わりに設定すると、既存の証明書を使用できます。お客様のランディングゾーンにデプロイする場合は、本番デプロイガイドの説明に従って、既存の VPC と、パブリック、プライベートアプリケーション、プライベートデータベースの各サブネットを個別に指定します。 読み取り専用の事前チェック (プリフライト) を実行します。 make litellm-check # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh check 事前チェックでは、AWS CLI v2、AWS アイデンティティ、Docker、イミュータブルなイメージ参照、リージョンの一貫性、CIDR の制限、TLS の入力値、ローカルドキュメントのリンクを検証します。cfn-lint が利用可能な場合は、AWS CloudFormation の構文も検証します。 レビュー済みの LiteLLM イメージをビルドし、Amazon ECR にプッシュします。 CONFIRM_AWS_WRITE=1 make litellm-build # Direct helper invocation used by Make: # CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh build ビルドでは、ダイジェストで固定された LiteLLM ベースイメージを使用し、生成された ECR ダイジェストを Git の追跡対象外のローカル状態ファイルに記録します。CloudFormation には、変更可能なイメージタグではなく、イミュータブルなダイジェストが渡されます。内部的には、ヘルパーがイミュータブルな Amazon ECR リポジトリを作成または再利用し、Amazon ECR にサインインして docker buildx build --push を実行したうえで、プッシュされたイメージのダイジェストを取得します。 CloudFormation 変更セットを、実行せずに作成します。 make litellm-plan # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh plan このコマンドは、ネットワークまたはゲートウェイのテンプレートに対して aws cloudformation deploy --no-execute-changeset を呼び出します。レビュー可能な変更セットが作成されますが、実行はされません。 変更セットをレビューしてから、デプロイします。 CONFIRM_AWS_WRITE=1 make litellm-deploy make litellm-status # Direct helper invocations used by Make: # CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh deploy # deployment/scripts/litellm-stack.sh status deploy ヘルパーは、ネットワークスタック、続いて LiteLLM ゲートウェイスタックに対して aws cloudformation deploy を実行します。status ヘルパーは aws cloudformation describe-stacks を実行し、スタックの状態と出力を表示します。 ECS サービスでは、デプロイサーキットブレーカーによるロールバックと Application Load Balancer のヘルスチェックを使用します。リファレンステンプレートでは、ターゲット追跡によるオートスケーリング、ログとデータの暗号化、RDS のバックアップ、ALB アクセスログ、運用アラームも設定されます。 お客様の環境では、 ENABLE_TLS=true を維持し、信頼できる DNS 名と ACM 証明書を使用したうえで、Application Load Balancer へのアクセスを承認済みの社内ネットワークまたは VPN の CIDR に制限してください。ECS タスクと Amazon RDS はプライベートサブネットに配置します。ECS タスクのポート 4000 や PostgreSQL のポート 5432 をパブリックに公開しないでください。 スコープ付きのゲートウェイアイデンティティを作成する LiteLLM のマスターキーを開発者に配布しないでください。代わりに、Git の追跡対象外のデプロイファイルで、ユーザーまたはチームのアイデンティティとポリシーを設定します。 CODEX_API_SECRET_ID=codex-litellm-gateway/alice-key CODEX_KEY_ALIAS=alice@example.com CODEX_KEY_USER_ID=alice@example.com CODEX_KEY_MODELS=gpt-5.5 CODEX_KEY_MAX_BUDGET=50 CODEX_KEY_BUDGET_DURATION=30d CODEX_KEY_TPM_LIMIT=100000 CODEX_KEY_RPM_LIMIT=1000 キーをプロビジョニングします。 CONFIRM_AWS_WRITE=1 make litellm-provision-key # Direct helper invocation used by Make: # CONFIRM_AWS_WRITE=1 deployment/scripts/litellm-stack.sh provision-key ヘルパーは子プロセス内でマスター認証情報を取得し、設定されたモデル、予算、レートのポリシーを指定して LiteLLM の /key/generate API を呼び出します。そのうえで、生成されたキーを AWS KMS で暗号化された Secrets Manager シークレットに直接書き込みます。どちらの認証情報も、コマンド引数に含めたり、ターミナルに出力したりすることはありません。 エンタープライズ規模で展開する場合は、各開発者のプロファイルに、割り当てられたスコープ付きキーのシークレットのみを読み取り、スタックの KMS キーで復号する権限を付与します。チームや環境ごとに、個別のシークレットパスと IAM ポリシーを使用してください。 Codex を設定する プロバイダーブロックを生成します。 make litellm-codex-config # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh codex-config ヘルパーは、デプロイされたゲートウェイのエンドポイントを CloudFormation から読み取り、次の Codex プロバイダー設定を出力します。ユーザー設定に自動で書き込むことはありません。 出力内容を、ユーザーレベルの ~/.codex/ config.toml に追加します。プロバイダーと認証の設定は、ユーザーレベルの設定に記述する必要があります。プロジェクトローカルの .codex/ config.toml ファイルに記述しても、Codex はこれらの設定を無視します。 生成される設定は次のような形式です。 model = "gpt-5.5" model_provider = "litellm-gateway" web_search = "disabled" [model_providers.litellm-gateway] name = "LiteLLM Gateway" base_url = "https://codex-gateway.example.com/v1" wire_api = "responses" [model_providers.litellm-gateway.auth] command = "/absolute/path/to/python3" args = [ "/absolute/path/to/deployment/scripts/aws-secret-auth.py", "--aws-cli", "/absolute/path/to/aws", "--region", "us-east-1", "--secret-id", "codex-litellm-gateway/alice-key", "--field", "LITELLM_API_KEY", "--profile", "developer-profile", "print-token" ] timeout_ms = 30000 refresh_interval_ms = 300000 Codex は標準入力なしで認証コマンドを実行し、その標準出力からベアラートークンを読み取ります。ヘルパーは名前付きの AWS プロファイルを使用して最新のシークレットを取得するため、トークンが config.toml に保存されることはありません。 LiteLLM の管理 UI の [Models + Endpoints] には、開発者が利用できる安定したエイリアスと、各エイリアスからアップストリームの Amazon Bedrock モデルへのマッピングが表示されます。これにより、開発者が Codex の設定をプロバイダー固有のモデル ID に直接結び付けるのではなく、ゲートウェイエイリアスを参照していることを、画面上ですばやく確認できます。 次の図は、2 つのモデルエイリアスが設定された [Models + Endpoints] ページを示しています。Codex の設定に進む前に、このリストにゲートウェイエイリアスが表示されていることを確認してください。 図 2: モデル管理ビューには、gpt-5.4 と gpt-5.5 のエイリアスと、それぞれの Amazon Bedrock Mantle へのマッピングが表示されます LiteLLM 経由で Codex をテストする 新しい対話型の Codex セッションを開始し、 /status を使用して、 litellm-gateway がプロバイダーとして選択されていることを確認します。再現可能な非対話型のテストとして、まず最小限のスモークリクエストを実行します。 codex exec --sandbox read-only --ephemeral \ "Reply with exactly LITELLM_GATEWAY_OK and no other text." コマンドが正常に終了し、 LITELLM_GATEWAY_OK が出力されれば成功です。次に、モデル推論とローカルツールの両方が必要なタスクで、エージェントループを動かしてみます。 codex exec --sandbox read-only --ephemeral \ "Read README.md with shell tools and summarize the deployment architecture. Do not modify files." Codex は、タスクとツール定義を LiteLLM 経由で送信します。モデルがファイルの読み取りを要求すると、Codex はそのコマンドをローカルで実行し、同じゲートウェイを通じてツールの実行結果を返します。 LiteLLM の管理 UI で [Logs] を開き、 [Request Logs] を選択して、テストを実施した時間帯で絞り込みます。次の点を確認します。 リクエストのステータスが Success であること キーエイリアスによって、ウォークスルー専用のキーまたは開発者のキーが識別されていること モデルが想定どおり Amazon Bedrock のモデルにマッピングされていること トークン数、リクエストの所要時間、コストが記録されていること Codex が後続の Responses リクエストでツールの実行結果を送信するため、ツールを使用するタスクで複数の行が作成されていること LiteLLM に行が記録される前に 403 レスポンスが返される場合、原因の多くはアップストリームのネットワークまたは AWS WAF によるブロックです。 401 レスポンスは、ゲートウェイの認証情報がないか、無効であることを示します。スクリーンショットには、プロンプト、レスポンス、生のキー、完全なリクエスト ID、実在する従業員を特定できる情報を掲載しないでください。 次の図は、複数の Codex リクエストがゲートウェイを正常に通過した後の LiteLLM の [Request Logs] ページを示しています。このページで、リクエストが Amazon Bedrock に到達していることを確認し、ステータスコードを手がかりにエラーのトラブルシューティングを行います。 図 3: リクエストログには、codex-walkthrough キーエイリアスに帰属する成功した Codex の各ターンが、モデル、コスト、所要時間、最初のトークンが返されるまでの時間とともに表示されます Responses API のコントラクトを検証する テキストプロンプトに正常な応答が返っても、エージェントワークフローとの互換性が証明されたことにはなりません。Codex は、基本的なチャット補完のレスポンスだけでなく、より多くの機能に依存しているためです。リポジトリに含まれている厳格なプローブを実行します。 make litellm-validate # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh validate ヘルパーはスコープ付きキーを取得して子プロセスの環境に渡し、デプロイされたゲートウェイに対して deployment/scripts/ validate-responses-contract.py を実行します。 プローブでは、次の項目を検証します。 Responses オブジェクトの必須フィールドと出力の形式 previous_response_id を使用したセマンティックな継続 完了状態の最終レスポンスを含む Server-Sent Events のストリーミング 呼び出し ID を伴う関数ツールの強制呼び出し 継続テストでは、最初のレスポンスに一意のテストマーカーを記録し、後続のレスポンスでそのマーカーを参照できることを検証します。これにより、 previous_response_id を構文上は受け付けるものの、前のレスポンスの状態を保持しないゲートウェイを検出できます。 実際のデプロイ環境は、コントラクト全体の検証に合格しました。CloudFormation は正常に完了し、ECS サービスは必要なタスク数に到達し、デプロイのロールアウトも完了しました。また、ALB のターゲットは正常で、暗号化された PostgreSQL データベースは利用可能かつパブリックにアクセスできない状態でした。 次の図は、実際のウォークスルースタックから取得したエンドツーエンドのデプロイ検証ダッシュボードを示しています。全体の合否ステータスと、インフラストラクチャのヘルス、API コントラクトへの準拠、データ層の設定、セキュリティポスチャを確認する 4 つの詳細パネルに注目してください。 図 4: 検証出力により、AWS のデプロイが正常であることと、Codex が必要とする Responses API の動作を確認できます 検証スクリプトは互換性を確認するためのゲートであり、負荷テストではありません。本番環境に移行する前に、エージェントセッションの同時実行、長時間のストリーム、リクエストのキャンセル、キーの失効、障害からの復旧、想定されるピークトラフィックについてもテストしてください。 エンタープライズ利用に向けて LiteLLM の運用を整備する codex exec とコントラクトテストが成功したことで、Codex がゲートウェイを使用できることは確認できましたが、互換性は出発点にすぎません。開発者のオンボーディングを始める前に、ゲートウェイでモデルアクセスをどのように制御し、使用量の帰属先を明確にし、利用量ポリシーを適用し、各モデルリクエストの運用記録を残すかを定義します。 まず、開発者が使用できるモデルの範囲を決めます。組織が承認したモデルに対してのみ安定したゲートウェイエイリアスを公開し、各アップストリームのマッピングを deployment/litellm/ litellm_config.yaml で固定します。ゲートウェイイメージを再ビルドし、同じ Amazon ECR ダイジェストを各環境に順次昇格させます。これにより、開発者は安定したエイリアスを使い続けることができ、その背後にある Amazon Bedrock モデルはシステムチームが管理し続けられます。 すべてのリクエストの帰属を明確にできれば、モデルポリシーはより効果を発揮します。LiteLLM のマスターキーを配布する代わりに、ユーザー、チーム、ワークロードごとに個別のスコープ付きキーを発行します。アップストリームのリクエストで Amazon Bedrock から見えるのは LiteLLM の ECS タスクロールであるため、リクエスト元のアイデンティティを、スコープ付きキー、LiteLLM のレコード、エクスポートされたテレメトリに引き継ぎます。これにより、ゲートウェイで開発者やチームへの帰属を維持でき、認証情報を記録することなく、リクエスト ID を AWS サービスのログと関連付けられます。 同じスコープ付きアイデンティティで、利用量ポリシーも適用できます。キーをプロビジョニングする際に、 CODEX_KEY_MAX_BUDGET 、 CODEX_KEY_BUDGET_DURATION 、 CODEX_KEY_TPM_LIMIT 、 CODEX_KEY_RPM_LIMIT を設定します。検証専用の一時的なアイデンティティで設定済みのしきい値を意図的に超え、LiteLLM が次のリクエストを拒否することを確かめて、これらの制御を検証します。こうすることで、設定が受け入れられたことを確認するだけでなく、ポリシーそのものが機能するかをテストできます。 ゲートウェイを運用するには、リクエスト経路全体を可視化することも必要です。AWS インフラストラクチャのシグナルからはサービスが正常かどうかがわかり、LiteLLM のレコードからは誰がどのモデルを使用し、リクエストがどれだけのキャパシティや予算を消費したかがわかります。ECS の必要タスク数と実行中タスク数、デプロイのロールバック、Application Load Balancer のターゲットのヘルスとレイテンシー、Amazon RDS のヘルス、LiteLLM のリクエスト数と拒否数、トークン使用量、支出、シークレットへのアクセス、IAM の変更、AWS WAF によるブロックをモニタリングします。 開発者のオンボーディングを始める前に、プロンプトとレスポンスをログに記録してよいかどうかを決めておきます。このコンテンツは機密性の高いお客様のデータを含む可能性があるものとして扱い、それに応じて秘匿化、暗号化、アクセス制御、保持期間を定義します。本番環境のデプロイでは、コンテンツのフィルタリング、拒否トピックの検出、グラウンディングチェックのために、モデルアクセス経路で Amazon Bedrock Guardrails を有効にすることを推奨します。ゲートウェイレベルの制御 (予算、レート制限、ルーティング) は、モデルレイヤーで適用される責任ある AI のセーフガードを補完するものであり、その代わりになるものではありません。 次の図は LiteLLM の [Usage] ページを示しています。このページでは、ゲートウェイを使用するすべての開発者のリクエストとトークンのメトリクスが集計されます。予算やレート制限を調整する前に、このビューで導入状況をモニタリングし、コストの異常を特定し、ユーザーや期間ごとにトラフィックを切り分けます。 図 5: 使用状況ダッシュボードでは、選択した検証期間について、モデル単位のリクエスト、トークン、支出、成功率を可視化できます 図 5 の検証期間には、成功したトラフィックと失敗したリクエストの両方が含まれており、ダッシュボードで通常のアクティビティとエラーの両方を確認できることがわかります。Codex は後続の Responses リクエストでローカルツールの実行結果をモデルに返すため、ツールを使用するタスクではリクエストログに複数の行が記録されることがあります。このように、実行の境界は運用データにも表れます。LiteLLM はモデルリクエストを制御して記録し、Codex は開発者のワークステーション上でツールを実行します。 2 つの代替アクセス経路を検討する このウォークスルーで LiteLLM を主に取り上げたのは、ゲートウェイによる追加の制御をわかりやすく示せるためです。ただし、すべてのお客様に最適というわけではありません。 IAM Identity Center による直接アクセス AWS ネイティブのアイデンティティと監査の制御で十分な場合は、組み込みの amazon-bedrock Codex プロバイダーを使用します。 model_provider = "amazon-bedrock" model = "openai.gpt-5.5" [model_providers.amazon-bedrock.aws] profile = "codex-bedrock" region = "us-east-1" 開発者は、名前付きの IAM Identity Center プロファイルでサインインします。 aws sso login --profile codex-bedrock この経路では、ゲートウェイ、データベース、およびそれらに関連する運用が不要になります。開発者の AWS セッションのアイデンティティは AWS CloudTrail のログに残りますが、ゲートウェイレベルで一元管理する厳格な予算上限やルーティングポリシーは追加されません。 リポジトリの「 IAM Identity Center quickstart 」には、分離されたグループとアクセス許可セットの作成、そのグループの AWS アカウントへの割り当て、クライアント設定の出力、サインインしたプロファイルによる Amazon Bedrock へのアクセス検証を行うための CloudFormation とヘルパーコマンドが含まれています。ゲートウェイを追加する前に、まずこの直接アクセス経路をベースラインとして使用してください。 Portkey によるマネージドアクセスまたはハイブリッドアクセス LiteLLM のリファレンススタックを自ら運用することなく、マネージドのコントロールプレーン、一元化されたルーティングとポリシー、またはサポートが提供されるハイブリッドデータプレーンを利用したい場合は、Portkey が役立ちます。 Codex を Portkey 経由で評価するには、Portkey のワークスペースキー、Amazon Bedrock Model Catalog プロバイダー、Responses ワイヤプロトコルを設定します。 model_provider = "portkey" model = "@bedrock-validation/&lt;approved-model-id&gt;" [model_providers.portkey] name = "Portkey" base_url = "https://api.portkey.ai/v1" env_key = "PORTKEY_API_KEY" wire_api = "responses" 本番環境に昇格させる前に、同じ厳格な Responses プローブを実行します。特に、 previous_response_id によるセマンティックな継続、ストリーミング、関数呼び出し、Amazon Bedrock への正確なルート、IAM ロールと外部 ID の設計を検証してください。製品ドキュメントや認証レスポンスだけでは、意図したモデル経路が Codex のコントラクト全体を満たしている根拠にはなりません。 ゲートウェイ全体を自身の AWS アカウントで運用することよりも、マネージドまたはハイブリッドの運用モデルを重視する場合は、Portkey を選択します。アーキテクチャを決定する際には、ベンダーのライセンス、データの取り扱い、リージョンごとの提供状況、障害モード、サポート範囲も確認してください。 クリーンアップ CloudFormation によって削除されるリソースと保持されるリソースをプレビューします。 make litellm-cleanup-plan # Direct helper invocation used by Make: # deployment/scripts/litellm-stack.sh cleanup-plan このコマンドはスタックを読み取り、何も削除せずに、各リソースが削除されるか保持されるかを一覧表示します。 正確なスタック名を確認したうえで、ゲートウェイを削除します。 CONFIRM_STACK_DELETE=codex-litellm-gateway \ make litellm-cleanup # Direct helper invocation used by Make: # CONFIRM_STACK_DELETE=codex-litellm-gateway \ # deployment/scripts/litellm-stack.sh cleanup ヘルパーは Amazon RDS の削除保護を確認し、 aws cloudformation delete-stack を呼び出して、ゲートウェイスタックの削除が完了するまで待機します。 共有されていないサンプルのネットワークスタックも削除する場合は、オプトインしたうえで個別に確認します。 CONFIRM_STACK_DELETE=codex-litellm-gateway \ DELETE_NETWORKING=1 \ CONFIRM_NETWORKING_DELETE=codex-networking \ make litellm-cleanup # Direct helper invocation used by Make: # CONFIRM_STACK_DELETE=codex-litellm-gateway \ # DELETE_NETWORKING=1 \ # CONFIRM_NETWORKING_DELETE=codex-networking \ # deployment/scripts/litellm-stack.sh cleanup これにより、ゲートウェイスタックに続いて、サンプルのネットワークスタックも削除されます。共有ネットワークにはこのオプションを使用しないでください。 リファレンススタックは Amazon RDS の最終スナップショットを作成し、KMS キー、Secrets Manager のシークレット、CloudWatch のロググループ、ALB のアクセスログ用バケットを保持します。ECR イメージと、プロビジョニングしたスコープ付きキーのシークレットも、スタック削除の対象外です。データ保持ポリシーに従って、保持されたリソースを確認し、削除してください。 まとめ Codex を LiteLLM 経由でルーティングすると、Codex がローカルでタスクとツールを実行する方式を維持しながら、お客様が運用するコントロールポイントで、モデルの選択、スコープ付きアイデンティティ、予算、レート制限、テレメトリを管理できます。本番環境への移行で重要な判断基準は、ゲートウェイがテキストを返せるかどうかではありません。エージェントワークフローに必要な Responses の動作をゲートウェイが維持できるかどうか、そしてシステムチームが追加されたインフラストラクチャを確実に運用できるかどうかです。 AWS ネイティブの制御で要件を満たせる場合は、IAM Identity Center による直接アクセスから始めてください。お客様が運用するゲートウェイのポリシーが運用負荷に見合う場合は、LiteLLM を追加します。マネージドまたはハイブリッドの運用モデルの方が組織に適している場合は Portkey を評価してください。いずれの経路でも、同じコントラクトテストを適用してください。 関連リソース Guidance for Codex on AWS の実装 Amazon Bedrock での OpenAI Amazon Bedrock ドキュメント LiteLLM on AWS quickstart IAM Identity Center quickstart Portkey evaluation quickstart 本番デプロイのガイダンス Codex のカスタムモデルプロバイダー Amazon Bedrock で Codex を使用する方法 AWS Fargate 上の Amazon ECS AWS IAM Identity Center ドキュメント LiteLLM プロキシのドキュメント Portkey の Codex 統合 AWS Pricing Calculator 著者について Nick McCarthy Nick は Amazon Bedrock チームの Senior Generative AI Specialist Solutions Architect で、Amazon Bedrock 上の OpenAI モデルと Codex を専門としています。ヘルスケア、金融、スポーツ、通信、エネルギーなど、幅広い業界の AWS のお客様と協力し、AI と機械学習を活用してビジネス成果の創出を加速できるよう支援してきました。 Sunil Bemarkar Sunil は Amazon Web Services の Sr.&nbsp;Partner Solutions Architect – Gen AI です。大規模言語モデル (LLM) プロバイダーと協力し、お客様が AWS で生成 AI を導入して運用できるよう支援しています。 Sudeesh Sasidharan Sudeesh 氏は OpenAI の Member of Go-to-Market Staff で、OpenAI API と Codex を専門としています。Amazon Bedrock に関して AWS と協力し、組織が OpenAI のフロンティアモデルを導入およびデプロイできるよう支援する活動も行っています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。