Eon、マルチクラウド調査基盤を一元化

Eonによると、同社のエンジニアリングチームは、AWS、GCP、Azureをまたぐインシデント調査で、ツールごとの認証情報とローカルで動かすModel Context Protocol（MCP、AIツール間の接続規約）プロセスを、認証付きのAmazon Bedrock AgentCore Gatewayに一本化しました。AWSがEonのロエイ・ザビダと共同執筆した記事によると、この本番環境は100人以上の開発者と自律型サイト信頼性エンジニアリング（SRE）エージェントに対応します。導入時間は2日から約2分に短縮され、開発者が使うローカルMCPプロセスは10個からゼロになったとEonは報告しています。

同社のエンジニアは、複数のクラウドや運用システムをまたいで障害を調べます。たとえばKubernetesのポッドが停止した場合、コンテナログ、Grafanaの指標、GitHubのプルリクエスト、クラウド事業者の稼働状況を1回のセッションで確認することがあります。Eonは認証情報を集約し、ローカルで稼働するMCPサーバーをなくし、人とエージェントの権限を分けることを目指しました。また、VPCピアリングやアカウントごとのAWS PrivateLinkを使わずにAWSアカウントを接続する必要がありました。ClaudeベースのSREエージェントには、人間とは異なる権限で調査ツールにアクセスさせる必要もありました。

Eonは独自の認証機能を備えたリバースプロキシと、Amazon Bedrock AgentCore Gatewayを比較しました。独自プロキシでは、プロトコル変換、セッション管理、認可の構築と保守が必要になるため、同社はAgentCore Gatewayを選びました。AWSによると、このサービスは管理型のID連携、Cedar（アクセス権を定義するポリシー言語）による認可、ローカルMCPサーバーをリモートのHTTPエンドポイントに変換するRuntimeホスティングを提供します。導入環境ではAgentCore Gateway、Policy、Runtime、Identityを使用します。開発者は1つのMCP URLに接続し、エージェントも別のIDを使って同じゲートウェイに接続します。

社内のシングルサインオンはAmazon Cognitoを介して連携し、人間の利用者にはJSON Web Token（JWT、認証情報を安全に伝えるトークン）が発行されます。エージェントはクライアント認証情報で認証します。Cedarポリシーは、どの主体がどのツールを呼び出せるかを定めます。承認済みの人間のグループには読み取り権限を付与し、本番環境のツールは読み取り専用とします。書き込み操作は指定されたIDに限り、プルリクエストやチケットへのコメントなど、影響の小さい作業に限定します。本番環境へのアクセスは承認を経て必要な時だけ付与され、監査対象になります。ポリシーの変更は、レビューを受けるGitHubのプルリクエストで管理されます。

AgentCore Gatewayは、別のAWSアカウントにあるRuntimeへ、アカウント間IAMロールを引き受けて接続します。Eonによると、これによりVPCピアリング、ルートテーブルの管理、PrivateLinkエンドポイントの費用、セキュリティグループの調整が不要になりました。新しいアカウントの設定は、数日かかる手順から、数分で適用できる1つのIAM信頼ポリシーに変わりました。大半の接続先はIAMを使うRuntimeで構成しています。利用可能なツールを絞り込む場合や認証情報を変換する場合は、リモートMCPサーバーをRuntimeで包みます。

調査時、ゲートウェイは数十の接続先からツール一覧を集約し、数百のツールを含む応答を返します。開発者が決済サービスの過去1時間のエラー率上昇を尋ねると、IDEのエージェントがGrafanaへの問い合わせを選び、ゲートウェイがCedarポリシーに照らして要求を確認します。RuntimeはAgentCore Identityの保管庫にあるサービス認証情報を使って問い合わせを実行します。その後、エージェントは別のRuntimeを介してKubernetesの状態や関連するGitHubのプルリクエストも確認できます。

100人以上の開発者への展開と約1万件のセッション運用で、ポリシーのサイズとクライアント互換性の問題が明らかになりました。事前索引化されたツールのスキーマがCedarポリシーのサイズに加算されるため、ツール一覧の大きな接続先では、EonはDYNAMIC方式を使います。この方式では、要求に応じてゲートウェイがツール一覧を取得し、ポリシーのサイズを増やしません。一方、そうした接続先では意味検索を利用できません。利用者ごとのOAuthと、同意確認に必要な事前索引化スキーマを使う小規模な接続先では、DEFAULT方式を維持しています。Claude Code、Cursor、Codexはクロスサイトリクエストフォージェリ対策としてOAuthのstateパラメーターを求めますが、AgentCoreはセッションURIとの結び付けを使います。Eonは両者の違いを変換するAmazon API Gatewayの中継機能を構築し、開発者ごとに大きなツール一覧を絞るRuntimeラッパーも作りました。

Eonによると、開発者ごとに必要な認証情報セットは、シングルサインオン1回を除いてゼロになりました。以前はシステムごとに別の認証情報が必要でした。アカウント間ネットワーク設定も、アカウントごとのVPCピアリングから、IAMを使う方式でゼロになりました。ゲートウェイは約1万件のセッションを処理し、数十の接続先にある数百のツールを1つのURLから利用できるようにしています。Eonは、社内エージェントがゲートウェイを通じてより多くの情報にアクセスでき、調査の精度向上と時間短縮に最も貢献していると説明しています。同社は、さらに検討を進めています。

Eonによると、同社のエンジニアリングチームは、AWS、GCP、Azureをまたぐインシデント調査で、ツールごとの認証情報とローカルで動かすModel Context Protocol（MCP、AIツール間の接続規約）プロセスを、認証付きのAmazon Bedrock AgentCore Gatewayに一本化しました。AWSがEonのロエイ・ザビダと共同執筆した記事によると、この本番環境は100人以上の開発者と自律型サイト信頼性エンジニアリング（SRE）エージェントに対応します。導入時間は2日から約2分に短縮され、開発者が使うローカルMCPプロセスは10個からゼロになったとEonは報告しています。

同社のエンジニアは、複数のクラウドや運用システムをまたいで障害を調べます。たとえばKubernetesのポッドが停止した場合、コンテナログ、Grafanaの指標、GitHubのプルリクエスト、クラウド事業者の稼働状況を1回のセッションで確認することがあります。Eonは認証情報を集約し、ローカルで稼働するMCPサーバーをなくし、人とエージェントの権限を分けることを目指しました。また、VPCピアリングやアカウントごとのAWS PrivateLinkを使わずにAWSアカウントを接続する必要がありました。ClaudeベースのSREエージェントには、人間とは異なる権限で調査ツールにアクセスさせる必要もありました。

Eonは独自の認証機能を備えたリバースプロキシと、Amazon Bedrock AgentCore Gatewayを比較しました。独自プロキシでは、プロトコル変換、セッション管理、認可の構築と保守が必要になるため、同社はAgentCore Gatewayを選びました。AWSによると、このサービスは管理型のID連携、Cedar（アクセス権を定義するポリシー言語）による認可、ローカルMCPサーバーをリモートのHTTPエンドポイントに変換するRuntimeホスティングを提供します。導入環境ではAgentCore Gateway、Policy、Runtime、Identityを使用します。開発者は1つのMCP URLに接続し、エージェントも別のIDを使って同じゲートウェイに接続します。

社内のシングルサインオンはAmazon Cognitoを介して連携し、人間の利用者にはJSON Web Token（JWT、認証情報を安全に伝えるトークン）が発行されます。エージェントはクライアント認証情報で認証します。Cedarポリシーは、どの主体がどのツールを呼び出せるかを定めます。承認済みの人間のグループには読み取り権限を付与し、本番環境のツールは読み取り専用とします。書き込み操作は指定されたIDに限り、プルリクエストやチケットへのコメントなど、影響の小さい作業に限定します。本番環境へのアクセスは承認を経て必要な時だけ付与され、監査対象になります。ポリシーの変更は、レビューを受けるGitHubのプルリクエストで管理されます。

AgentCore Gatewayは、別のAWSアカウントにあるRuntimeへ、アカウント間IAMロールを引き受けて接続します。Eonによると、これによりVPCピアリング、ルートテーブルの管理、PrivateLinkエンドポイントの費用、セキュリティグループの調整が不要になりました。新しいアカウントの設定は、数日かかる手順から、数分で適用できる1つのIAM信頼ポリシーに変わりました。大半の接続先はIAMを使うRuntimeで構成しています。利用可能なツールを絞り込む場合や認証情報を変換する場合は、リモートMCPサーバーをRuntimeで包みます。

調査時、ゲートウェイは数十の接続先からツール一覧を集約し、数百のツールを含む応答を返します。開発者が決済サービスの過去1時間のエラー率上昇を尋ねると、IDEのエージェントがGrafanaへの問い合わせを選び、ゲートウェイがCedarポリシーに照らして要求を確認します。RuntimeはAgentCore Identityの保管庫にあるサービス認証情報を使って問い合わせを実行します。その後、エージェントは別のRuntimeを介してKubernetesの状態や関連するGitHubのプルリクエストも確認できます。

100人以上の開発者への展開と約1万件のセッション運用で、ポリシーのサイズとクライアント互換性の問題が明らかになりました。事前索引化されたツールのスキーマがCedarポリシーのサイズに加算されるため、ツール一覧の大きな接続先では、EonはDYNAMIC方式を使います。この方式では、要求に応じてゲートウェイがツール一覧を取得し、ポリシーのサイズを増やしません。一方、そうした接続先では意味検索を利用できません。利用者ごとのOAuthと、同意確認に必要な事前索引化スキーマを使う小規模な接続先では、DEFAULT方式を維持しています。Claude Code、Cursor、Codexはクロスサイトリクエストフォージェリ対策としてOAuthのstateパラメーターを求めますが、AgentCoreはセッションURIとの結び付けを使います。Eonは両者の違いを変換するAmazon API Gatewayの中継機能を構築し、開発者ごとに大きなツール一覧を絞るRuntimeラッパーも作りました。

Eonによると、開発者ごとに必要な認証情報セットは、シングルサインオン1回を除いてゼロになりました。以前はシステムごとに別の認証情報が必要でした。アカウント間ネットワーク設定も、アカウントごとのVPCピアリングから、IAMを使う方式でゼロになりました。ゲートウェイは約1万件のセッションを処理し、数十の接続先にある数百のツールを1つのURLから利用できるようにしています。Eonは、社内エージェントがゲートウェイを通じてより多くの情報にアクセスでき、調査の精度向上と時間短縮に最も貢献していると説明しています。同社は、さらに検討を進めています。