はじめに 今回作るもの 検証環境 手順 1. AgentCore CLIのインストール 2. プロジェクト作成 3. エージェントコードの作成 4. Dockerfileの作成 5. ローカルテスト 6. デプロイ 7. 呼び出しと動作確認 8. Observability（トレース確認） 9. Gateway でジオコーディングAPIを接続 @tool と Gateway の使い分け Bedrock Agents との比較 ハマったポイント CodeZipデプロイの初期化タイムアウト Containerデプロイでのトレース設定 まとめ はじめに こんにちは、アプリケーションサービス本部ディベ…

本記事は  2026 年 3 月 30 日に公開された ” Introducing CloudWatch Metrics for AWS Direct Connect Virtual Interface BGP Health and Prefix Count ” を翻訳したものです。 本日、 AWS Direct Connect は Amazon CloudWatch における 仮想インターフェイス（VIF）に関する3 つの新しいメトリクス VirtualInterfaceBgpStatus 、 VirtualInterfaceBgpPrefixesAccepted 、 VirtualInterfaceBgpPrefixesAdvertised のサポートを発表しました。これらのメトリクスにより、API を手動でポーリングしたりコンソールを確認したりすることなく、CloudWatch から直接 Border Gateway Protocol（BGP）セッションの正常性とプレフィックス数を把握できるようになります。本ブログでは、新しいメトリクスの概要、ユースケース、および修復アクションをトリガーするアラームの設定方法について説明します。CloudWatch で利用可能な Direct Connect メトリクスの完全なリストについては、 Direct Connect ユーザーガイドの Amazon CloudWatch によるモニタリング を参照してください。 VIF BGP ステータスおよびプレフィックス数メトリクスの提供前 この機能が提供される前は、Direct Connect の CloudWatch メトリクスは物理接続の正常性とトラフィックスループットのみをカバーしていました。BGP セッションステータス、オンプレミスルーターから受け入れたプレフィックス数、AWS からの経路広報、サイレントな経路の消失といった BGP レベルのテレメトリについては、Direct Connect API をポーリングしたり、独自の Lambda 関数を作成したり、またはオンプレミスのネットワーク管理ツールに頼る必要がありました。 Monitor BGP status on AWS Direct Connect VIFs and track prefix count advertised over transit VIF の記事では、そのようなアプローチの一例が紹介されています。今回の新しい CloudWatch メトリクスにより、そうした複雑さは不要となり、プレフィックス数のモニタリングはトランジット VIF に限定されなくなりました。 新しいメトリクスの概要 3 つの新しい CloudWatch メトリクスは、プライベート仮想インターフェイス、パブリック仮想インターフェイス、トランジット仮想インターフェイスの 3 種類すべての VIF タイプで利用できます。 図 1 は、オンプレミスネットワークが 3 種類の仮想インターフェイスを通じて AWS リソースに接続する様子を示すマルチリージョン Direct Connect アーキテクチャです。この図では、企業のデータセンターからDirect Connect を使用して AWS リージョン（us-east-1 および us-west-2）に接続する構成を示しています。プライベート仮想インターフェイスは、単一の VPC に直接接続するか、 Direct Connect ゲートウェイ を介して異なる AWS リージョンの複数の VPC に接続し、プライベートリソースへのアクセスを提供します。トランジット仮想インターフェイスは AWS Transit Gateway への接続を可能にし、単一の仮想インターフェイスを通じて異なる AWS リージョンの複数の VPC にアクセスできます。パブリック仮想インターフェイスは、パブリックインターネットを経由することなく、 Amazon S3 、 Amazon Kinesis 、 Amazon SQS 、 Amazon SNS などの AWS パブリックサービスエンドポイントへのアクセスを提供します。 また、このアーキテクチャでは各仮想インターフェイスのタイプに対して今回の CloudWatch メトリクスで導入された新しい BGP モニタリング機能も紹介しています。この図は、これらのメトリクスが CloudWatch に収集され、さらに CloudWatch ダッシュボードの作成や CloudWatch アラームの生成、Amazon SNS 経由での通知に活用することで、Direct Connect インフラストラクチャ全体にわたる包括的なモニタリングとアラートを実現する方法を示しています。 図 1: 3 種類すべての Direct Connect 仮想インターフェイスのタイプに対応した 3 つの新しい CloudWatch BGP メトリクス VirtualInterfaceBgpStatus このメトリクスは、仮想インターフェイス上の BGP セッションの現在の状態を示します。値が 1 の場合は BGP セッションが確立されていることを示し、値が 0 の場合は切断されていることを示します。このメトリクスに CloudWatch アラームを設定することで、BGP セッションが切断された際に通知を受け取ることができ、DescribeVirtualInterfaces API のポーリングや Direct Connect コンソールの確認が不要になります。 VirtualInterfaceBgpPrefixesAccepted このメトリクスは、仮想インターフェイスを介してオンプレミスのネットワークから受け取った BGP プレフィックスの数を示します。Direct Connect では、 BGP セッションごとにプレフィックス数の上限が設定されており、この上限は仮想インターフェイスのタイプによって異なります。上限を超えると、BGP セッションはアイドル状態となり、セッションステータスがダウンになります。VIF タイプごとの経路数の上限の現在のクォータ値については、 Direct Connect のクォータ ページを参照してください。 VirtualInterfaceBgpPrefixesAccepted をモニタリングすることで、当該の上限を下回るしきい値で CloudWatch アラームを事前に設定しておき、上限に近づく前に早めに通知を受け取ることができます。また、このメトリクスは予期しない経路の消失を検知するのにも役立ちます。たとえば、オンプレミス側でルーティングポリシーの変更が行われ、AWS への経路広報が停止した場合などです。 VirtualInterfaceBgpPrefixesAdvertised このメトリクスは、仮想インターフェイスを介して AWS からオンプレミスネットワークに広報された BGP プレフィックスの数を示します。プレフィックス数の上限はアウトバウンドの経路広報にも適用され、仮想インターフェイスのタイプによって異なります。 VirtualInterfaceBgpPrefixesAdvertised メトリクスを追跡することで、AWS が想定通りの経路を広報していることを確認し、意図しない変更を検出できます。たとえば、経路集約やポリシー変更により経路が予期せず消失された場合などです。 ユースケース Direct Connect の 3 つの新しい CloudWatch メトリクスは、主に 2 つの運用ニーズに対応します。 BGP セッションの正常性のモニタリング VirtualInterfaceBgpStatus メトリクスに対して CloudWatch アラームを直接作成できるようになりました。Lambda 関数や API ポーリングは不要です。メトリクスの値が 0 に変化すると、CloudWatch がアラームを発報 し、Amazon Simple Notification Service（ Amazon SNS ）を通じて通知を受け取ることができます。これにより、BGP セッションのステータス変化に関連するトラフィック障害について、運用の複雑さと平均検出時間（MTTD）の両方を削減できます。 BGP プレフィックス数の変更のモニタリングと診断 VirtualInterfaceBgpPrefixesAccepted と VirtualInterfaceBgpPrefixesAdvertised メトリクスをモニタリングすることで、該当のプレフィックス数の上限を下回るしきい値に CloudWatch アラームを設定しておき、BGP セッションに影響が及ぶ前に早期に通知を受け取ることができます。 プレフィックス数の上限超過の防止だけでなく、これらのメトリクスは BGP セッションが維持されたままでもトラフィックに影響を与える経路変化の検知と診断にも役立ちます。BGP セッション自体は維持されているものの、経路がサイレントに消失される場合があります。たとえば、ルーティングポリシーの変更によって、オンプレミス側が特定のプレフィックスの経路広報を除外したり、意図しない変更により AWS 側から広報されるはずのプレフィックスが外部に広報されなくなった場合です。このような状況では、 VirtualInterfaceBgpStatus は 1 のままですが、影響を受けたプレフィックス宛てのトラフィックは流れなくなります。BGP ステータスとあわせて受信・広報プレフィックス数のメトリクスをモニタリングすることで、いずれかの方向での急激な減少を検出し、トラフィックへの影響と紐づけることで、根本原因の特定にかかる時間を短縮できます。 マルチリージョン構成やディザスタリカバリ (DR) 構成において、2 つの Direct Connect ロケーションが 2 つのリージョンに対してアクティブ/パッシブまたはアクティブ/アクティブの BGP 構成で接続されている場合、これらのメトリクスを使うことで、両方のパスが想定どおりのルートテーブルを双方向で保持していることを確認できます。スタンバイパスが想定されるプレフィックスの一部しか受信または広報していない場合、フェイルオーバーパスに問題があることを示しています。各仮想インターフェイスの両方のプレフィックスメトリクスに CloudWatch アラームを設定しておくことで、DR イベントや計画されたメンテナンスウィンドウの前に、この状態を事前に検知できます。 CloudWatch ダッシュボードでの BGP メトリクスのモニタリング 3 つの BGP メトリクスすべてを 1 つの CloudWatch ダッシュボードにまとめることで、仮想インターフェイス全体の BGP セッションの正常性とプレフィックス数を統合的に把握できます。図 2 は、 VirtualInterfaceBgpStatus 、 VirtualInterfaceBgpPrefixesAccepted 、 VirtualInterfaceBgpPrefixesAdvertised をまとめて表示したダッシュボードの例です。 図 2: AWS Direct Connect 仮想インターフェイスの BGP セッションステータスとプレフィックス数を表示する CloudWatch ダッシュボード BGP モニタリングのための CloudWatch アラームの設定 以下の手順では、BGP セッションの障害を検出するために VirtualInterfaceBgpStatus メトリクスに CloudWatch アラームを作成する方法を説明します。 前提条件 アクティブな Direct Connect 仮想インターフェイスを持つ AWS アカウント CloudWatch アラームおよび SNS トピックを作成するための権限 BGP ステータスアラームの作成 CloudWatch コンソールを開き、ナビゲーションペインで アラーム を選択し、 アラームの作成 を選択します。 メトリクスの選択 を選択します。 検索ボックスに VirtualInterfaceBgpStatus と入力し、対象の仮想インターフェイス ID のメトリクスを選択して、 メトリクスの選択 を選択します。 統計 で 最小 を選択し、 期間 を 5 分に設定します。 条件 で、しきい値タイプを 静的 に設定し、 より低い を選択して、BGP セッションがダウンした際にアラームが発報されるよう しきい値に 1 を入力します。 次へ を選択し、アラートを受け取るための Amazon SNS 通知アクションを設定します。 次へ を選択し、アラームの名前を入力し、 次へ を選択し、 アラームの作成 を選択します。 図 3: VirtualInterfaceBgpStatus メトリクスの CloudWatch アラーム プレフィックス数アラームの作成 前述の手順のステップ 1〜2 を繰り返します。 メトリクス名を検索し、対象の仮想インターフェイスのメトリクスを選択します。 VirtualInterfaceBgpPrefixesAccepted は、AWS がオンプレミスネットワークから受け入れたプレフィックス数をモニタリングします。 VirtualInterfaceBgpPrefixesAdvertised は、AWS がオンプレミスネットワークに広報したプレフィックス数をモニタリングします。 統計 で 最大 を選択し、 期間 を 5 分に設定します。 条件 で、しきい値タイプを 静的 に設定し、比較演算子を選択して、しきい値を入力します。 プレフィックス数がしきい値を超えた場合にアラームを発報するには 以上 を選択します。たとえば、受信または広報プレフィックス数が適用されるプレフィックス上限に近づいたことを検出する場合です。 プレフィックス数がしきい値を下回った場合にアラームを発報するには 以下 を選択します。たとえば、受信または広報プレフィックス数が想定される最小値を下回り、経路の消失が発生した可能性を検出する場合です。 次へ を選択し、アラートを受け取るための SNS 通知アクションを設定します。 次へ を選択し、アラームの名前を入力し、 次へ を選択し、 アラームの作成 を選択します。 クリーンアップ テスト目的で CloudWatch アラームを作成した場合は、不要な課金を避けるために削除してください。料金の詳細については、 Amazon CloudWatch の料金ページ を参照してください。 CloudWatch コンソールを開きます。 ナビゲーションペインで アラーム を選択します。 作成したアラームを選択し、 アクション から 削除 を選択します。 考慮事項 メトリクスデータは、Direct Connect が利用可能なすべての AWS リージョンで利用できます。メトリクスは、Direct Connect ロケーションが紐づいているリージョンと同じリージョンの CloudWatch に公開されます。サポートされているロケーションの最新リストについては、 Direct Connect のロケーション ページを参照してください。 Direct Connect リソースに対する、すべての CloudWatch メトリクスは、追加費用なしで提供されます。 3 つの BGP メトリクスすべてを CloudWatch ダッシュボードにまとめることで、すべての仮想インターフェイスにわたる BGP セッションの正常性と経路数を一元的に把握することを推奨します。 メトリクスの値は 5 分ごとに更新されます。CloudWatch メトリクスは収集時点の BGP セッション状態を取得するため、収集間隔の間に発生して回復した BGP セッションのフラッピングはメトリクスに反映されない場合があります。BGP ステータスメトリクスは継続的に監視することで、セッションの安定性の傾向を追跡してください。 マルチリージョンまたはディザスタリカバリ (DR) アーキテクチャでは、各仮想インターフェイスに対して個別に CloudWatch アラームを作成することを推奨します。プライマリパスとスタンバイパスの間でプレフィックス数に大きな差がある場合、スタンバイ側の経路情報が不完全または正常に機能していない可能性があります。 まとめ Direct Connect 仮想インターフェイス向けの新しい CloudWatch メトリクス VirtualInterfaceBgpStatus 、 VirtualInterfaceBgpPrefixesAccepted 、 VirtualInterfaceBgpPrefixesAdvertised により、BGP セッションの正常性とプレフィックス数をネイティブに可視化できるようになりました。BGP の障害検出や経路変更のモニタリングに、独自の Lambda 関数や API ポーリングは不要になりました。これらのメトリクスに CloudWatch アラームを設定することで、BGP の問題の検出時間を短縮し、プレフィックス数の上限超過による BGP セッションの切断を防止し、ハイブリッドネットワークが想定通りに動作していることを確認できます。Direct Connectと CloudWatch の詳細については、以下を参照してください。 AWS Direct Connect のユーザガイド Amazon CloudWatch のユーザガイド （訳者注：原文は 2026 年 4 月 13 日にメトリクスの公開リージョンに関する記述が更新されており、本翻訳は更新後の内容に基づいています） 翻訳は Technical Account Manager の豊山が担当しました。原文は こちら です。

はじめに 今回作るもの アーキテクチャ 前提条件 Bedrock Agents の仕組み 全体の流れ アクショングループとは 処理の流れ 手順 1. Lambda関数の作成 Lambda単体テスト 2. Bedrock Agent の作成 モデルと指示文の設定 アクショングループの追加 3. Lambda のリソースベースポリシー設定 4. テスト 5. エイリアス作成とAPIからの呼び出し 必要なIDの確認 Python（boto3）での呼び出し まとめ はじめに こんにちは、アプリケーションサービス本部ディベロップメントサービス3課の北出です。 最近、AIエージェントという言葉をよく耳にす…