本記事は  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 の豊山が担当しました。原文は こちら です。

こんにちは、SHIFT インフラサービスグループのAKです。 今回は、Python の開発で広く使われてきたパッケージ管理ツールである pip をあらためて見直し、uv への切り替えを検討した際の背景と検証内容をご紹介します。きっかけは、2026年3月末に発生した、axios のサプライチェーン攻撃でした。

本記事は、シリーズ「AWS における AI エージェント対応のデータ基盤」の第 2 回です。 第 1 回 では、AI エージェントが組織の本番データに対して正しく動くために必要な 3 要素（認可・ビジネスデータカタログ・ドメイン知識）を紹介し、認可が効いている様子をデモで示しました。本記事では、3 要素のうち認可に焦点を当て、AI エージェント経由のデータアクセスに Amazon SageMaker Catalog のアクセス制御を透過的に効かせる実装パターンを解説します。 サンプルリポジトリ: aws-samples/sample-sagemaker-agentic-analyst aws-samples sample-sagemaker-agentic-analyst A demo application that demonstrates how fine-grained access controls configured in SageMaker Unified Studio are transparently enforced on data access through AI agents. AI エージェントにアクセス制御を効かせる 3 つの壁 AI エージェントにデータアクセスを任せるとき、守るべき原則があります。エージェントは独自の認可ロジックを持たず、ユーザーが SageMaker Catalog で付与されている権限を、エージェント経由でもそのまま透過的に利用させることです（SageMaker Catalog は Amazon DataZone の上に構築されており、権限設定は DataZone API で操作します）。エージェント内に独自の認可ロジックを作ると、既存のガバナンスと二重管理になり、整合性を保つのが難しくなるからです。 この原則を実現しようとすると、素直な実装ではたどり着けない 3 つの壁があります。これらは本記事で解説する設計上の工夫によって越えられます。 壁 1: コンピュートリソース自体のロールで権限を取得すると、全ユーザーが同一権限になる。 AI エージェントのツールは AWS Lambda 、 AWS Fargate 、 Amazon EC2 など何らかのコンピュートリソース上で実行されます。そのコンピュートリソース自体のロール（たとえば Lambda の実行ロール）で DataZone の GetEnvironmentCredentials API を呼ぶと、返ってくるのはそのロール自身のメンバーシップに基づくプロジェクトロールです。どのユーザーがリクエストしても同じ認証情報が返るため、ユーザー個別のアクセス制御を効かせるには工夫が必要です。 壁 2: SAML フェデレーション経由のトークンには、IdP 側のグループ情報が乗らない。 AWS IAM Identity Center （以下 IdC）と、たとえば Amazon Cognito を SAML フェデレーションで連携する構成では、IdC 側のグループ情報が Cognito のトークンに自動的には含まれません。「データコンシューマーには athena_query を許可し、ドメイン管理者には cloudtrail_query のみ許可する」といったツール単位の認可を IdC のグループベースで行うには、グループ情報をトークンに載せる工夫が必要です。 壁 3: 設定時と実行時で関与するサービスが異なり、認可の全体像を把握する必要がある。 SageMaker Catalog の裏側では複数のサービスが連携しています。設定時に使うサービスと、クエリ実行時に評価されるサービスが異なるため、全体像を把握しないと正しい実装にたどり着けません。 本記事では、サンプルリポジトリ sample-sagemaker-agentic-analyst がこれらの壁をどう越えているかを解説します。 サービスの役割分担を整理する 本記事で扱うサービスの関係を先に整理します。 Amazon SageMaker Catalog は、データと AI の発見・ガバナンス・コラボレーションを担うサービスで、Amazon DataZone の上に構築されています。データの Publish/Subscribe やアクセス権の設定は SageMaker Catalog（および Amazon SageMaker Unified Studio の UI）で行いますが、実際のクエリ実行時に行・列レベルのアクセス制御を評価するのは AWS Lake Formation です。S3 上のファイルに対するアクセス制御は Amazon S3 Access Grants が担います。 つまり、SageMaker Catalog で「誰がどのデータを見てよいか」を 設定 し、Lake Formation と S3 Access Grants が 実行時 にその設定を評価する、という役割分担です。 重要な原則として、DataZone はクエリ実行パスに入りません。後述する認証情報変換フローでは DataZone API（ RedeemAccessToken / GetEnvironmentCredentials ）を呼びますが、これは AgentCore Gateway に接続された Lambda（以下 Tool Lambda）が プロジェクトロールの認証情報を取得する ための前段であり、Athena クエリや S3 オブジェクト取得そのものには DataZone は介在しません。クエリ実行時の認可評価は Lake Formation と S3 Access Grants が担います。この「認証情報取得の経路」と「データアクセスの経路」の分離を理解しておくと、以降のフローが読みやすくなります。 認証情報変換フロー: 5 つのステップ 壁 1 と壁 3 に対応するため、本サンプルでは 5 つのステップで認証情報を変換します。ブラウザでサインインしたユーザーの Cognito トークンから出発し、最終的にそのユーザーの権限が反映された SageMaker プロジェクトロールの一時認証情報を Tool Lambda の手元に届けます（下図）。 Step 1: ブラウザから AgentCore Runtime へ ブラウザ上の React アプリが、 Amazon Bedrock AgentCore Runtime のエンドポイントに HTTPS リクエストを送ります。このリクエストには 2 つのトークンが乗っています。 Authorization: Bearer <Cognito Access Token> — Runtime の Cognito Authorizer が検証します カスタムヘッダー X-Amzn-Bedrock-AgentCore-Runtime-Custom-Cognito-Id-Token: <Cognito ID Token> — 次のステップで使います Cognito Access Token と Cognito ID Token はどちらも Amazon Cognito が発行する JSON Web Token（JWT）ですが、役割が異なります。Access Token は「このリクエストは正当なユーザーから来たか」を Runtime と Gateway が判定するために使います。ID Token はユーザーのアイデンティティ情報（メールアドレスなど）を含んでおり、次のステップで IdC のユーザーと突き合わせるために使います。 Step 2: chat-agent が Cognito ID Token を IdC Access Token に引き換える Amazon Bedrock AgentCore Runtime はエージェントプロセスをホストするマネージドサービスです。呼び出し主体はその上で動くユーザーコード（本サンプルでは chat-agent ）であり、Runtime サービス自身がトークン変換を自動で行うわけではありません。 chat-agent が IdC の CreateTokenWithIAM API を呼びます。 const tokenRes = await new SSOOIDCClient({ region }).send( new CreateTokenWithIAMCommand({ clientId: idcApplicationArn, grantType: 'urn:ietf:params:oauth:grant-type:jwt-bearer', assertion: cognitoIdToken, }), ); const idcAccessToken = tokenRes.accessToken; jwt-bearer grant で Cognito ID Token を渡すと、IdC はそのクレームから IdC ユーザーを特定し、IdC Access Token を返します。 ここで 2 つの補足があります。 Cognito JWT と IdC Access Token は別物です。 発行者が違い（Cognito vs IdC）、形式も違います（JWT vs 不透明トークン）。Cognito JWT は Cognito 連携アプリでしか通用しませんが、IdC Access Token は IdC の Trusted Identity Propagation（TIP） に対応した AWS サービスで通用します。TIP は、IdC ユーザーのアイデンティティを IAM ロールの STS セッションに identity context として伝播させる仕組みです。DataZone は TIP 対応サービスの 1 つで、 RedeemAccessToken はその入口に位置します。 CreateTokenWithIAM と RedeemAccessToken は、このトークンの世界をまたぐブリッジの役割を果たします。 ただし本サンプルでは、TIP の identity-enhanced session をそのままデータ層まで持ち込んで Lake Formation や S3 Access Grants に評価させる構成は採っていません。SageMaker Catalog の Publish/Subscribe モデルが プロジェクトロール に行・列・オブジェクトレベルの権限を付与する設計になっているため、IdC ユーザーのアイデンティティは RedeemAccessToken → GetEnvironmentCredentials を経由してプロジェクトロールへ引き換えられ、以降のデータアクセスはプロジェクトロールの権限で評価されます。TIP の役割はこの引き換えの前段に限定され、本記事の焦点もそこにあります。 CreateTokenWithIAM には jti 制約があります。 JWT には jti （JWT ID）という一意識別子のクレームがあり、IdC は jwt-bearer grant で受け取った JWT の jti を記録します。同じ jti の JWT が再度送られると拒否されるため、同一の Cognito ID Token で CreateTokenWithIAM を 2 回呼ぶことはできません。このため、chat-agent で 1 リクエストあたり 1 回だけ実行し、得られた IdC Access Token を x-idc-access-token カスタムヘッダーで AgentCore Gateway 経由で全 Tool Lambda に伝播する設計になっています。 なお、 CreateTokenWithIAM を呼ぶための IAM アクション名は sso-oauth:CreateTokenWithIAM です。SDK クライアントは SSOOIDCClient を使いますが、IAM ポリシー側のサービス名は sso-oauth になります。また、IdC の OAuth Customer Managed Application に datazone:domain:access スコープを事前に登録しておく必要があります。 Step 3: Tool Lambda が IdC Access Token を DomainExecutionRole の認証情報に引き換える Tool Lambda が Amazon DataZone の RedeemAccessToken エンドポイントに HTTP POST を投げます。 const redeemRes = await fetch( `https://datazone.${region}.api.aws/sso/redeem-token`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ domainId, accessToken: idcAccessToken }), }, ); const { credentials: domainExecRoleCreds } = await redeemRes.json(); RedeemAccessToken は AWS SDK に含まれていません。 公開ドキュメントでは Athena JDBC ドライバ経由の利用例（ Analyze subscribed data via JDBC ）が示されていますが、サーバーサイドアプリからの直接呼び出しは生の HTTP リクエストで行う必要があります。このため、エンドポイント URL も通常の DataZone SDK が使う datazone.{region}.amazonaws.com ではなく datazone.{region}.api.aws を指定します。 この API には 2 つの特徴があります。SigV4 署名が不要であること（認証は IdC Access Token 自体が行う）、そして jti 制約がないため並列の Tool 呼び出しで複数の Lambda が同じ IdC Access Token を使っても問題ないことです。 返ってくるのは DomainExecutionRole の一時認証情報（ accessKeyId / secretAccessKey / sessionToken / expiration ）です。DomainExecutionRole は SageMaker Unified Studio ドメインに紐付く IAM ロールで、この認証情報には IdC ユーザーのアイデンティティが紐付いています 。内部的には、 RedeemAccessToken が DomainExecutionRole を assume する際に、Step 2 で触れた TIP の仕組みにより STS セッションに IdC ユーザーの identity context が埋め込まれます。これが次のステップで効いてきます。 Step 4: Tool Lambda が DomainExecutionRole の認証情報でプロジェクトロールを取得する Tool Lambda が Amazon DataZone SDK を DomainExecutionRole の認証情報で 初期化し、 GetEnvironmentCredentials を呼びます。 const envCreds = await new DataZoneClient({ region, credentials: domainExecRoleCreds, }).send( new GetEnvironmentCredentialsCommand({ domainIdentifier: domainId, environmentIdentifier: environmentId, }), ); Amazon DataZone は呼び出し元の STS セッションから identity context を取り出し、IdC ユーザーを特定します。そのユーザーがプロジェクトのメンバーであれば、プロジェクトロールの一時認証情報を返します。メンバーでなければ拒否されます。 ここが本サンプルの核心です。DomainExecutionRole の認証情報で呼ぶからこそ、 ユーザー本人のメンバーシップ で認可が評価されます。もし Lambda 実行ロールで直接 GetEnvironmentCredentials を呼んでいたら、Lambda 実行ロール自身のメンバーシップで判定されてしまい、ユーザーごとの権限差が消えます。 Step 5: プロジェクトロールで Athena / S3 を呼び出す Tool Lambda が Athena や S3 のクライアントを プロジェクトロールの認証情報で 初期化し、クエリやオブジェクト取得を実行します。 const athena = new AthenaClient({ region, credentials: { accessKeyId: envCreds.accessKeyId, secretAccessKey: envCreds.secretAccessKey, sessionToken: envCreds.sessionToken, }, }); Athena がクエリを実行すると、Lake Formation がプロジェクトロールの権限に基づいて行・列レベルのフィルタリングを透過的に適用します。ユーザーの権限の範囲内にある行と列だけが結果として返り、範囲外の情報は応答に含まれません。 ステップのまとめ Step 主体 API 入力 出力 1 ブラウザ → Runtime POST /invocations — Cognito Access Token + ID Token（Runtime に到達） 2 chat-agent → IdC CreateTokenWithIAM Cognito ID Token IdC Access Token 3 Tool Lambda → DataZone RedeemAccessToken IdC Access Token DomainExecutionRole 認証情報 4 Tool Lambda → DataZone GetEnvironmentCredentials DomainExecutionRole 認証情報 プロジェクトロール認証情報 5 Tool Lambda → Athena/S3 StartQueryExecution / GetObject 等 プロジェクトロール認証情報 クエリ結果 / オブジェクト Step 5 の S3 アクセスは Publisher と Subscriber で経路が分かれます。後述の「Publisher と Subscriber で異なる S3 アクセス方式」で詳述します。 この設計では、 Lambda 実行ロールはデータアクセスに一切使いません 。権限判定はすべてユーザーに紐付いた認証情報で行われます。 Policy in AgentCore によるツール単位認可 認証情報変換フローはデータアクセスの認可を扱いますが、「どのユーザーがどのツールを呼べるか」という別軸の認可も必要です。AgentCore の認可モデルは、 Inbound（ユーザー → AI エージェントへの入口） と Outbound（AI エージェント → ツールへの出口） の 2 軸で整理されます。Inbound は AgentCore Runtime の JWT Authorizer が Cognito Access Token を検証して「この呼び出し元はエージェントを呼んでよいか」を判定します。Outbound はツール単位の認可で、本サンプルでは AgentCore Gateway の Policy in AgentCore で実現しています（下図）。 グループ情報の埋め込み 壁 2 で述べた通り、IdC と Cognito を SAML フェデレーションで連携する構成では、IdC 側のグループ情報は Cognito トークンに自動的には含まれません。本サンプルでは、 Amazon Cognito の Pre token generation Lambda trigger の V2 イベントを使い、Cognito Access Token に cedar_groups カスタムクレームを埋め込みます。値は |data-producers|security-auditors| のようにパイプ区切りの文字列です。 Cedar ポリシーによる評価 Policy in AgentCore では、Cedar 言語で記述されたポリシーを policy engine に登録し、それを AgentCore Gateway に関連付けます。Gateway にリクエストが到達すると、policy engine が Cognito Access Token の cedar_groups クレームを読み取り、Cedar ポリシーで評価します。Gateway はリクエスト時点で JWT のクレームを AgentCore::OAuthUser エンティティのタグとして Entity Store に格納するため、ポリシー上は principal.getTag("cedar_groups") のようにタグとして参照します。「JWT では cedar_groups クレーム、Cedar ポリシーでは cedar_groups タグ」という名前の対応関係です。 permit( principal is AgentCore::OAuthUser, action, resource == AgentCore::Gateway::"<gateway-arn>" ) when { principal.hasTag("cedar_groups") && principal.getTag("cedar_groups") like "*|security-auditors|*" && (action == AgentCore::Action::"cloudtrail-query___cloudtrail_query") }; このポリシーは「 security-auditors グループに属するユーザーだけが cloudtrail_query ツールを呼べる」ことを宣言しています。アクション名の cloudtrail-query___cloudtrail_query は、AgentCore Gateway が MCP ツール定義から自動生成する命名で、 ターゲット名（ cloudtrail-query ） ___ ツール名（ cloudtrail_query ） の形を取ります。 Cedar の policy engine は default-deny （明示的に許可されない限り拒否）で動作します。上記の 1 本のポリシーだけでは security-auditors 向けの 1 ツールしか許可されていないため、他のユーザー・他のツールはすべて拒否されます。同様のポリシーを複数定義することで、たとえばデータコンシューマーには athena_query と s3_read のみを許可し、データプロデューサーにはカタログ管理ツールも許可する、といった職務分離を実現できます。 Policy in AgentCore によるツール単位認可と、認証情報変換フローによるデータアクセス認可は独立した 2 つの軸です。Gateway で「このユーザーはこのツールを呼んでよいか」を判定し、Tool Lambda で「このユーザーはこのデータを見てよいか」を判定します。 Publisher と Subscriber で異なる S3 アクセス方式 非構造化データ（S3 上のファイル）へのアクセスは、プロジェクトの役割によって経路が異なります。Amazon S3 Access Grants は、S3 の prefix / bucket / object 単位で IAM プリンシパルやディレクトリユーザーに READ/WRITE/READWRITE 権限を付与する仕組みで、 GetDataAccess API で当該対象への一時認証情報を取得してから S3 API を呼ぶ形で利用します。SageMaker Catalog の Publish/Subscribe は、この Grant を Subscriber のプロジェクトロールに対してのみ自動作成する 設計です。Publisher 側のプロジェクトロールには明示的な Grant が作られず、Publisher は別のパス（IAM ポリシーによる直接アクセス）でバケットを読みます。これが Publisher/Subscriber で経路が分かれる理由です。 Publisher（プロジェクトがバケットを所有する場合）: プロジェクトロールの認証情報で直接 S3:GetObject を呼びます。アクセス権は、プロジェクトロールに付与された IAM インラインポリシー（プロジェクト配下のプレフィックスに限定）によって許可されます。Publisher プロジェクトロール自身への明示的な S3 Access Grants の Grant は存在しないため、 GetDataAccess は失敗します。 Subscriber（別プロジェクト経由で購読する場合）: SageMaker Unified Studio の Publish/Subscribe が Subscriber ロールに対して IAM タイプの Grant を自動作成します。Tool Lambda はまず S3Control:GetDataAccess で一時認証情報を取得し、その認証情報で S3:GetObject を呼びます。 判断ロジックは、コネクションの accessRole の有無とプロジェクトの所有関係で決まります。プロジェクトレベルのコネクションで accessRole があれば S3 Access Grants 経由、なければ直接アクセスです。 まとめと次のアクション 本記事では、AI エージェント経由のデータアクセスに SageMaker Catalog のアクセス制御を透過的に効かせる実装パターンを解説しました。 設定時と実行時の役割分担 を整理し、SageMaker Catalog / DataZone が設定を担い、Lake Formation / S3 Access Grants が実行時に認可を評価する構造を明確にする 認証情報変換フロー （ CreateTokenWithIAM → RedeemAccessToken → GetEnvironmentCredentials ）で、ユーザーに紐付いたプロジェクトロールの認証情報を Tool Lambda に届ける Policy in AgentCore で、ツール単位の認可をデータアクセス認可とは独立した軸で制御する Lambda 実行ロールはデータアクセスに一切使わず、権限判定はすべてユーザーに紐付いた認証情報で行われます。これにより、SageMaker Catalog で設定された行・列・オブジェクトレベルのアクセス権は、AI エージェント経由でも透過的に適用されます。 第 1 回 で紹介した拡張性（ゼロショット時系列予測のオンデマンド実行）も、本記事で解説した認可の仕組みに支えられています。アクセス制御されたデータを、追加の認証設計なしで Amazon SageMaker AI の推論エンドポイントに流し込めるのは、プロジェクトロールの認証情報が Tool Lambda の手元まで届いているからです。サンプルリポジトリの apps/gateway-tools/time-series-forecast/ と design/data-access-control.md で実装の詳細を確認できます。 高野 賢司 AWS のシニアソリューションアーキテクトとして、東海以西の製造業のお客様を中心に支援しています。Infrastructure as Code や AI 駆動開発を中心とした開発者ツールのエキスパートでもあり、 Kiro によって広がったソフトウェア開発の世界を楽しんでいます。