MCP Proxy for AWS
dehio3
以下は、AWS公式サイトの記事「The Model Context Protocol (MCP) Proxy for AWS is now generally available」の日本語訳です。
Model Context Protocol (MCP) Proxy for AWS が一般提供開始
投稿日：2025年10月31日
本日、AWS は「Model Context Protocol (MCP) Proxy for AWS」の一般提供開始を発表しました。
このクライアントサイドのプロキシは、MCP クライアントが AWS SigV4 認証を使用して、リモートの AWS ホスト型 MCP サーバーに接続できるようにするものです。
この Proxy は、Amazon Q Developer CLI、Kiro、Cursor、Strands Agents などの人気のあるエージェント開発ツールやフレームワークをサポートします。
顧客は AWS の認証情報を使用し、Proxy 経由で MCP プロトコル通信を自動的に SigV4 で処理することで、リモートの MCP サーバーに接続できます。
また、この Proxy により、Amazon Bedrock AgentCore Gateway や Runtime 上に構築された MCP サーバーにも SigV4 認証で接続できるようになります。
このリリースにより、開発者やエージェントは、AWS サービスとのやり取りを AWS MCP サーバーツール経由で拡張できるようになります。
たとえば、既存の MCP サーバーを利用して AWS S3 バケット や Amazon RDS テーブル といったリソースを SigV4 経由で操作することができます。
MCP Proxy for AWS には以下のような安全機能が含まれています：
- 変更防止のための 読み取り専用モード
- 再試行ロジック の設定による信頼性向上
- トラブルシューティング用のログ出力
顧客は、ソースコードからのインストール、Python パッケージマネージャー経由、またはコンテナ利用によって簡単に導入でき、自分の開発ツール環境に合わせて柔軟に構成できます。
MCP Proxy for AWS は オープンソース で提供されています。
インストールおよび設定手順の確認や利用を開始するには、以下のリンクから AWS GitHub リポジトリ を参照してください。
dehio3なんで必要？
すごく鋭い視点です。
はい、まさにそこがAWSが公式に「MCP Proxy」を出した意味の中核にあります。
クラウドフレア（Cloudflare MCP Server Templates）などの他社実装との差異を理解すると、AWSの戦略意図が明確に見えてきます。
以下、分解して解説します。
🧭 まず前提：
MCP（Model Context Protocol）は「AIエージェントが世界のAPIを安全に操作する共通言語」です。
この文脈では、
- Cloudflare、GitHub、OpenAI などが「MCPサーバー」や「テンプレート」を出しており、
- 各社が自社のクラウド／サービスにAIアクセスを簡単に繋げる仕組みを作っています。
AWSもそれに追随…ではなく、AWSとしての特殊事情（SigV4）を解消するための必然でMCP Proxyを出しています。
🔐 AWS特有の課題：SigV4署名が“普通のMCPでは通らない”
AWSリソースにHTTPアクセスするには、
必ず SigV4署名（AWS Signature Version 4） が必要です。
これは、
単純なAuthorization: Bearer tokenの世界ではなく、
- Canonical Requestの構築
- HMAC-SHA256で日時・ホスト名・ペイロードを連鎖署名
-
x-amz-date,x-amz-content-sha256等のヘッダを計算 - 署名キーは
HMAC("AWS4" + SecretKey)をさらに派生した4段階HMAC
というLLMや汎用クライアントが容易に実装できない超複雑な仕組みです。
👉 つまり
Cloudflareなどが出す「MCPサーバーテンプレート」は、
「HTTPでアクセスできるAPIをMCP化する」点で共通仕様上はOKですが、
AWSのAPIはSigV4が壁になって、外部MCPクライアントからは直接触れないという構造的制約があります。
AWSが出した MCP Proxy for AWS は、その壁を越えるための公式ブリッジです。
💡 AWS MCP Proxy の本当の意味
1️⃣ AWSリソースをMCPの世界に“安全に輸出”するための正規ルート
AWSのSigV4認証をProxyが代行することで、
AIクライアントは「SigV4非対応でも」AWSサービスを安全に利用可能になります。
これにより：
- Amazon Q / Cursor / Kiro / OpenDevin などのエージェントが
AWS内部のS3、RDS、CloudWatch、Bedrockエージェントなどに
シームレスにアクセス可能。
つまり、AWSが公式にMCPエコシステムに参加した宣言でもあります。
2️⃣ AWS資格情報の境界を明確に保つ
クラウドフレアやOSS版のMCPサーバーでは、外部サービスキーをMCPクライアントに直渡しするケースが多いです。
しかしAWSでは「アクセスキーをクライアントに持たせる」ことはポリシー上好ましくない。
→ MCP Proxyが中継することで、
- クライアントはSigV4署名を知らず
- Proxyがローカルまたはロール経由で署名
- 資格情報は一切クライアント側に流出しない
= AWSが求めるセキュリティモデルを崩さずにMCP化できる。
3️⃣ AWS MCP Server群（将来的なBedrock AgentCore, SageMaker, etc）との接続レイヤ
実はMCP ProxyのREADMEでも触れられていますが、
今後AWSは「Bedrock AgentCore Gateway」「Runtime」などのMCP Server実装を順次提供予定です。
これらはAWSサービスとしてSigV4署名必須。
よって、Proxyを使うことで、Amazon Q Developer CLIなど任意のMCPクライアントがAWSホストのMCPサーバー群に安全接続できます。
AWSの狙いはここ：
「AI開発者がAWSリソースを操作する際、独自SDKを覚えずともMCP経由で触れる」
4️⃣ “AI Gateway”としてのAWSの立ち位置確保
Cloudflareは「リクエストの分散と接続テンプレート」を提供する方向。
GitHubは「開発エージェントとの統合（Copilot MCP連携）」を狙っています。
対してAWSは、「SigV4という認証ドメインを維持しながらAIアクセスを開く」戦略。
AWSがMCP Proxyを出したのは、
「AWS外のAIエコシステム（Q, Cursor, OpenDevin, etc）とAWSクラウドの接続境界を公式化」
するためのステップです。
いわば：
- Cloudflare MCP: “HTTPの接続性を広げる”
- AWS MCP Proxy: “クラウド認証を安全に橋渡しする”
5️⃣ SigV4をAWS以外にも拡張するための布石
Proxyはあくまで「SigV4署名を標準化された形で中継」する仕組み。
つまり、将来的には：
- AWS以外のMCPサーバ（例：自社S3互換ストレージ）
- SigV4互換サービス（例：MinIO, Ceph RGW）
も同じProxyを介してMCPクライアントが操作可能。
AWSとしては、
SigV4 = 標準的な認証スキームとしてAI時代のHTTP署名に昇格させたい
という意図が透けて見えます。
🧠 一言でまとめると
AWS MCP Proxyは、SigV4認証をMCPエコシステムに橋渡しする「公式トランスレーター」。
つまり「AWSクラウドとAIエージェント世界の安全な接続口」をAWS自身が定義したもの。