EonがAmazon Bedrock AgentCore上のMCP Gatewayでマルチクラウド調査を構築した方法

これはEonのRoei Zavida氏と共に執筆したゲスト投稿です。

AI搭載製品を構築する独立系ソフトウェアベンダー(ISV)は、クラウド全体にわたる数十の運用ツールに、エージェントと人間を接続する必要があります。それぞれ異なる認証モデル、ネットワーク境界、アクセスポリシーを持つこれらのツールがAWS、GCP、Azureに同時にまたがると、統合対象の領域は何倍にも拡大します。

この記事では、あらゆるフレームワークやモデルに対応し、大規模にエージェントを構築、接続、最適化するプラットフォームであるAmazon Bedrock AgentCoreをEonがどのように使用したかを説明します。Eonはこれを使って、ツールごとの認証情報とローカルのModel Context Protocol(MCP)プロセスを、単一の認証済みゲートウェイに置き換えました。その結果、開発者と自律エージェントが3つのクラウドにまたがる調査ツールへ統一的にアクセスできるようになりました。新しいエンジニアは現在、認証情報とローカルMCPサーバーの設定に以前は2日かかっていたところ、約2分ですべての調査ツールにアクセスできるようになりました。

Eonについて

EonはAI時代のためのAutonomous Data Foundationを提供しています。同社のプラットフォームは、AWS、Azure、GCPにまたがるクラウドリソースを検出および分類します。Eonの社内測定において、ストレージコストを最大50パーセント削減する継続的な重複排除バックアップを提供します。さらに、ランサムウェアや不正エージェントによる被害を検出し、AIエージェント向けのライブでグラウンディングされたコンテキストを提供します。これらはすべて単一の読み取り専用AWS Identity and Access Management(IAM)ロールから実行され、データはApache ParquetおよびApache Iceberg形式で保存されます。元AWSエンジニアによって設立されたEonは、そのソフトウェア as a Service(SaaS)インフラストラクチャをAWS上で運用しています。

課題

Eonの社内エンジニアリングチームは、複数のクラウドと数十の運用システムにまたがる本番インシデントを調査します。クラッシュしたKubernetesポッドの調査には、同じセッション内でコンテナログ、Grafanaメトリクス、デプロイのGitHubプルリクエスト(PR)、クラウドプロバイダーのヘルスステータスを確認する必要があります。

Eonはいくつかの重要な要件に対応する必要がありました:

• 認証情報の統合 — 新しいツールを追加するたびに、設定、保護、ローテーションが必要な統合がもう1つ増え、ツールセットが拡大するにつれて一貫性を維持することが困難になりました。
• ローカルMCPプロセスの廃止 — 各開発者がローカルで複数のMCPサーバーを実行しており、標準化と最新状態の維持が困難でした。
• IDの分離 — エンジニアはロールベースの権限で各システムにアクセスしていましたが、誰が、あるいはどのエージェントがどのツールを呼び出せるかを判断する単一の場所がありませんでした。
• ネットワーキングのオーバーヘッドなしでのクロスアカウントアクセス — 複数のAWSアカウントにわたってMCPサーバーをホストするには、アカウントごとにVirtual Private Cloud(VPC)ピアリングまたはAWS PrivateLinkが必要で、運用コストとセットアップ時間が増大していました。
• 開発者のオンボーディング — 新しいエンジニアは、最初のインシデントを調査できるようになるまでに、認証情報とローカルMCPサーバーの設定におよそ2日を費やしていました。
• エージェントアクセス — Eonの自律型サイト信頼性エンジニアリング(SRE)エージェント(Amazon Bedrock上のClaudeを実行)は、人間と同じツールアクセスを必要としましたが、権限は異なるものでした。

エンジニアリング人員の増加と、急速に拡大するAIツールおよびMCPのセットにより、認証情報とローカルMCPサーバーの維持はますます高コストになりました。これがEonを集中型ソリューションへと後押ししました。

検討されたアプローチ

AgentCore上に構築する前に、Eonは代替案を評価しました:

オプション1: カスタム認証による集中型プロキシ

すべてのハーネスには、すべてのターゲットを含む独自のプロキシ設定がありました。すべてのツールを集約する単一のリバースプロキシと、カスタム認証レイヤーによる構成です。これにより認証情報の統合は実現しましたが、リモートMCPのみをサポートし、ツールプロトコル変換、セッション管理、認可ロジックをゼロから構築して維持する必要がありました。実装と保守の負担は相当なものでした。

オプション2: Amazon Bedrock AgentCore Gateway

Amazon Bedrock AgentCore Gatewayは、Amazon Bedrock AgentCoreの機能の1つで、組み込みのIDフェデレーション、Cedarベースの認可ポリシー、ローカルMCPサーバーをリモートHTTPエンドポイントに変換するRuntimeホスティングを備えたマネージドゲートウェイです。これにより、カスタムインフラストラクチャなしですべての要件に対応できました。

Eonがオプション2を選択したのは、ID分離、クロスアカウント接続、ポリシー適用を、構築・維持が必要なコードではなくマネージド機能として提供していたためです。検討対象はこの2つのオプションだけでした。

ソリューション概要

Eonは、Amazon Bedrock AgentCore のフルスタック、すなわち AgentCore Gateway、Amazon Bedrock AgentCore の Policy、AgentCore Runtime、AgentCore Identity(いずれも Amazon Bedrock AgentCore の機能)をデプロイしました。次の図は、クライアントリクエストが認証レイヤーを通じて単一のゲートウェイへどのように流れるかを示しています。ゲートウェイは、認可されたツール呼び出しを、複数の AWS アカウントにまたがる AgentCore Runtime 上でホストされているターゲットにルーティングします。

図 1: Amazon Bedrock AgentCore 上の Eon の集中型ゲートウェイアーキテクチャ

このアーキテクチャは5つのレイヤーで構成されています:

クライアント

Claude Code、Cursor、または OpenAI Codex を使用する開発者は、単一の MCP URL に接続します。Amazon Bedrock 上の Claude を実行する自律型 SRE エージェントは、異なる ID で同じゲートウェイに接続します。

アイデンティティプレーン

企業のシングルサインオン（SSO）はAmazon Cognitoを通じてフェデレーションされ、JSON Web Token（JWT）を生成してゲートウェイに渡します。Amazon API Gatewayが手前のOAuthエントリーポイントとして人間の要求を受け付け、MCPセッションをプロキシします。エージェントはCognitoで認証し、 client_credentials ゲートウェイに対して直接グラントを行います。

1つのゲートウェイ、最小権限アクセス

単一のAgentCore MCPゲートウェイが全社共通のフロントドアとして機能します。ENFORCEモードのCedarポリシーが、どのプリンシパルがどのツールを呼び出せるかを制御します。読み取り操作は選択されたグループにのみ許可され、認証済みの全ユーザーには開放されていません。書き込み操作は、PRやチケットへのコメントなど低影響のコラボレーション操作に限定され、本番ツールは読み取り専用です。

Amazon Bedrock AgentCoreにおけるポリシー

Cedarポリシーは各プリンシパルを許可されたツールにマッピングします。書き込み操作は、PRやチケットへのコメントなど低影響のコラボレーション操作に限定され、本番ツールは読み取り専用です。ゲートウェイはすべての tools/call リクエストを、ターゲットへ転送する前にCedarに対して評価します。

ターゲット

1つのゲートウェイ上で、数百のツールを公開する多数のターゲットMCPサーバーが、複数のAWSアカウントに分散したAgentCore Runtimeによって提供されています。各Runtimeは、ローカルのstdioベースのMCPサーバーを、ゲートウェイ経由でアクセス可能なStreamable HTTPエンドポイントに変換します。

開発者は統合開発環境（IDE）を開き、1つのMCP URLを設定し、企業SSOを通じて認証すると、ゲートウェイが数百のツールを単一の tools/list レスポンスに集約します。ローカルセットアップもツールごとのトークンも不要です。

アイデンティティとアクセスの分離

中核となるセキュリティ上の決定は、ゲートウェイレベルでCedarポリシーを通じて読み取りと書き込みの境界を強制することでした。

単一ゲートウェイ、ポリシーによる強制分離：

ゲートウェイは、JWTトークン（企業SSOとCognito経由の人間）と client_credentials トークン（エージェント）の両方を受け付けます。各プリンシパルが何を行えるかはCedarポリシーが決定します。承認されたグループの人間には読み取りアクセスが付与されます。書き込み操作には、特定のエージェントアイデンティティにのみ付与された明示的なCedar許可が必要です。

Cedarによるツール単位の細粒度化の強化：

// Agent "sre-bot" can add comments on GitHub PRs
permit(
    principal == Agent::"sre-bot",
    action == Action::"tools/call",
    resource == Tool::"github_add_pr_comment"
);

// No human principal can invoke mutation tools
forbid(
    principal in Group::"humans",
    action == Action::"tools/call",
    resource in ResourceGroup::"write-tools"
);

CedarポリシーはGitHub PRによるコードとして管理され、レビューコメントが付くため、チームはすべての権限変更に対してバージョン管理と監査証跡を得られます。

ゲートウェイ内では、CedarポリシーがSSOグループごとにツールアクセスをスコープ化し、グループは職務ロールにマッピングされます。エンジニアはデフォルトで開発環境とテスト環境にアクセスできます。本番環境へのアクセスはEonのセキュリティおよびコンプライアンス管理に従い、読み取り専用であり、承認プロセスを通じてジャストインタイムで付与され、監査されます。新規メンバーのグループも、そのメンバーがたまたま担当するサービスではなく、ロールに基づいて同じようにスコープ化されます。すべてのエージェントアクションがENFORCEモードのCedarに対して検証され、最小権限のツールセットにスコープされるため、自律エージェントは安全で境界付けられた範囲内で動作します。エージェントは、そのアイデンティティが明示的に呼び出しを許可された特定のツールしか実行できません。

「以前は、社内エージェントが開発者が使うのと同じ調査ツールにアクセスできませんでした。導入後は、独自のアイデンティティとより厳格なツールセットで同じゲートウェイを利用しています。」

— Eon シニアDevOpsエンジニア Roei Zavida

クロスアカウント接続

Eonは複数のAWSアカウントにわたってRuntimeを実行しており、環境やサービス境界ごとに整理されています。AgentCore Gatewayは、IAMクロスアカウントロールの引き受けを通じて各Runtimeに到達します。アカウントBのRuntimeは、標準的なIAM信頼ポリシーを通じてアカウントAのAgentCore Gateway実行ロールを信頼します。

これにより廃止されたもの：

• 複数のAWSアカウントにわたるVPCピアリング設定とルートテーブル管理。
• アカウントごとのPrivateLinkエンドポイントコスト。
• アカウント間のセキュリティグループの調整。
• 新規アカウントごとに数日かかっていたセットアップ（1つのIAM信頼ポリシーに置き換わり、数分でデプロイ可能）。

ターゲットアタッチパターン：

各ツールの認証およびホスティングモデルに応じて、Eonは2つの主要なアタッチパターンを使用しています。次の表は、各パターンをいつ使用するかをまとめ、例を示しています。

ほとんどのターゲットはRuntime + IAMを使用します。EonがリモートMCPをラップするのは、カタログを縮小するため、またはゲートウェイが他の方法では供給できないクレデンシャルを差し込むためだけです。

調査セッションのフロー

以下のフローは、開発者が本番インシデントを調査する様子を追ったものです:

1. 認証。 開発者はClaude Code(またはCursor/Codex)を開き、ゲートウェイのMCP URLに接続します。IDEは企業SSOを通じてOAuthを開始します。Cognitoは開発者のアイデンティティとグループメンバーシップを含むJWTを発行します。
2. ツールの検出。 ゲートウェイは数十の接続されたターゲットから`tools/list`を集約し、数百のツールの統一マニフェストをIDEに返します。開発者は利用可能なすべての調査ツールを1つのリストで確認できます。
3. ツールの呼び出し。 開発者は「直近1時間のpaymentsサービスのエラーレート急増を見せて」と尋ねます。IDEのエージェントはGrafanaクエリツールを選択し、`tools/call`リクエストを送信します。
4. ポリシー評価。 ゲートウェイはCedarに対してリクエストを評価します。開発者のグループメンバーシップによりGrafanaツールへのアクセスが許可されます。リクエストは通過します。
5. Runtimeでの実行。 ゲートウェイはリクエストをGrafana MCPサーバーをホストするRuntime(別のAWSアカウントで実行)に転送します。RuntimeはAgentCore Identityボールトに保存されたサービスクレデンシャルを使用してGrafanaへの認証を行い、クエリを実行して結果を返します。
6. ツール間の相関分析。 エージェントは続いてKubernetesデプロイ状況と関連するGitHub PRを確認します。それぞれ異なるRuntimeにルーティングされます。開発者はツールを切り替えたり再認証したりすることなく、相関付けられた結果を確認できます。

大規模運用で得られた教訓

100人以上の開発者と約10,000セッションへの展開により、本番環境の課題が明らかになりました:

Cedarポリシーサイズの管理

ゲートウェイが事前にインデックス化するすべてのツールスキーマがCedarポリシーサイズに寄与します。広範なツールマニフェストを公開する数十のターゲットがあるため、Eonのポリシーはサイズクォータに近づいていきました。解決策は、ツール数の多いターゲットに対するDYNAMICリスティングモードです。DYNAMICモードでは、ゲートウェイはスキーマを事前にインデックス化する代わりに、リクエスト時に tools/list MCPサーバーへの呼び出しを転送するため、ポリシーにはゼロバイトしか追加されません。

トレードオフとして、DYNAMICターゲットではセマンティックツール検索が利用できません。Eonはハイブリッド構成を採用しています。ユーザーごとのOAuthが必要なターゲットにはDEFAULTモード(ツール数が少なく、同意フロー用に事前インデックス化されたスキーマが必要)を、大規模カタログのターゲットにはDYNAMICモードを使用します。

標準MCPクライアント向けのOAuthセッションバインディング

Claude Code、Cursor、Codexは、クロスサイトリクエストフォージェリ(CSRF)保護のためにOAuth state パラメータを期待します。AgentCoreはセッションURIバインディングを使用します。Eonは2つのプロトコル間を変換するAmazon API Gatewayシムを構築し、標準MCPクライアントが変更なしでOAuthフローを完了できるようにしました。

ツールサーフェスのフィルタリング

一部のMCPサーバーは数百のツールを公開しています。個々の開発者が必要とするのは、担当サービス用のサブセットだけです。EonはRuntimeレイヤーでツールマニフェストをフィルタリングするRuntimeラッパーを構築し、 tools/list レスポンスのノイズを減らし、無関係な操作が誤って呼び出されるのを防いでいます。このアプローチにより、これらのターゲットはDEFAULTモードのまま維持され、DYNAMICモードでは失われるセマンティック検索と埋め込み機能が保持されます。

結果

このシングルゲートウェイアーキテクチャは、Eonの社内エンジニアリングチームで数か月間本番環境で稼働しています。最も明確な成果は開発者のオンボーディングです。ツール一式へのアクセス設定は、認証情報やローカルMCPサーバーの設定に約2日かかっていたものが、約2分に短縮されました。新しいエンジニアは1つのゲートウェイURLに接続し、社内SSOで認証すると、自分のロールで許可されたツールをすぐに確認できます。

保存された時間の大部分は社内エージェントによるもので、ゲートウェイを通じてより多くのコンテキストにアクセスできるようになり、調査の精度が向上したためです。エンジニアは、ゲートウェイURLに接続するだけでよいため、以前AIツールのセットアップに費やしていた時間を節約できます。

Eonは、同じパターンを自社製品のAI機能に活かす方法を検討しています。

「AgentCoreにより、ツールごとのトークンやローカルMCPプロセスの代わりに、認証済みの単一のMCP Gatewayを利用できるようになりました。開発者と社内エージェントは、単一のURLからKubernetes、Grafana、GitHub、およびクラウドアカウントにアクセスできます。」

— Roei Zavida（Eon シニアDevOpsエンジニア）

まとめ

この記事では、Eonがツールごとの認証情報とローカルMCPプロセスを、単一のAmazon Bedrock AgentCore MCP Gatewayに置き換えた方法について説明しました。その結果、CedarベースのID分離、VPCピアリング不要のクロスアカウント接続、3つのクラウドにわたる100人以上の開発者と自律エージェントのための統合ツールアクセスが実現しました。このシングルゲートウェイアーキテクチャ、Cedarによる最小権限の強制、およびDEFAULTとDYNAMICのハイブリッドポリシーモードは、複数のクラウドにわたるツールにエージェントと開発者を接続するISVにとって再利用可能なパターンです。

Amazon Bedrock AgentCoreでの構築の詳細については、以下のリソースをご覧ください：

• Amazon Bedrock AgentCore Gatewayドキュメント.
• Amazon Bedrock AgentCore Runtimeドキュメント.
• Getting Started with Amazon Bedrock AgentCore Workshop.

著者について