「AWS MCP が壊れる」典型とブラウザ単体との差

ブラウザで console.aws.amazon.com を開く場合、macOS／Windows のシステムプロキシを尊重しやすく、サインインのリダイレクトも同じ経路に乗りがちです。IDE の拡張・言語サーバ・タスクランナーは、親プロセスの環境変数、コンテナ／WSL／リモート SSH、サンドボックスによってプロキシ設定が途切れる場面が珍しくありません。AWS MCP Server や周辺 SDK が同一プロファイルの Amazon Bedrock を叩くときも、ブラウザで完走した OAuth トークンと、CLI／拡張が直接呼ぶ SigV4 付き HTTPS は別 TCP コネクションです。Clash が TUN でカーネルから覆う場合と、単に mixed-port に環境変数で向けるだけの場合では、出口の一貫性がまったく違います。

まず Clash のライブ接続で、失敗ウィンドウの数十秒だけ SNI と選択ポリシーを並べてください。signin.aws.amazon.com 周辺だけ赤字なのか、bedrock-runtime.*.amazonaws.com だけ遅いのか、ドキュメント用に見える静的ホストだけ落ちるのかをメモすると、認証・コンソール・API・CDN のどれが経路だけ割れているかがはっきりします。クラウド側の恒久障害を疑う前に、この階層分けのほうがコストが低いことが多く、チーム内の再現ログ共有にも向きます。

Agent Toolkit for AWS のようなスタックは、公開ドキュメントやインストールガイドに沿ってホストが増減します。特定のバージョン名やプレビュー URL をここで断定しないのは、読者の実ログが最優先だからです。AWS 公式ドキュメント と自分の 接続ログを突き合わせ、増えた名前をルールへ足してください（仕様確認用であり、接続の合法性は利用者の責任です）。

ℹ 観測のコツ：問題が出ている IDE 統合ターミナルから短いウィンドウだけ計測し、成功している別シェルと環境変数の差分を並べます。ALL_PROXY と NO_PROXY にローカル例外が紛れていないか、企業 PAC が IDE 子プロセスにだけ効いていないかも合わせて見ます。サインインは成功した直後にだけ Bedrock が失敗するなら、リージョン設定・プロファイル・ロールチェーンは AWS 側ドキュメントを正にし、ネット以外の要因も切り分けます。

踏むレイヤー：OAuth・コンソール・Bedrock API・STS・静的 CDN

実運用でまとめやすい層は次のとおりです。(1) アカウントと認可——signin.aws.amazon.com をはじめとするログインフロー、組織により増える IdP 連携ホスト。実装とリージョンで名前は変わるため、自分のログを正にします。(2) コンソールとガイド——console.aws.amazon.com、設定画面やチュートリアル内の読み込み。(3) データプレーン API——多くの Bedrock 呼び出しは bedrock-runtime.*.amazonaws.com、制御プレーンは別サブドメインになることがあります。(4) 横断サービス——sts.*.amazonaws.com など、仮定クレデンシャル取得が挟まると「モデル API だけ」ではなく手前で長い待ちに見えます。(5) 静的 CDN——スクリプトやアセット、クイックスタートの参照先。ここが誤遮蔽や直結のボトルネックだと、画面は中途半端に出るのに裏の API だけタイムアウトと誤解されやすいです。

「API だけタイムアウト」は層 (3) が別出口にいる典型ですが、(1)(2)(4)(5) のどれかが先に詰まっていると、(3) に到達する前に長いスピンに見えます。逆に (3) だけ通っていても、デバイス認可やトークン交換が (1) で止まれば完了しません。ひとつの安定した出口を AWS 開発者向けの束に割り当て、必要なら DOMAIN 行で絞り込むと読みやすいです。

YAML での概念的な束ね方（例）

ポリシー名は自分の構成に置き換えてください。断片は出発点であり、丸写しではありません。増えた名前はログで足し、範囲が広すぎると無関係な課金リソースまで巻き込みます。

Illustrative rules fragment — verify against your logs

rules:
  - DOMAIN-SUFFIX,amazonaws.com,AWS_DEV_STABLE
  - DOMAIN-SUFFIX,aws.amazon.com,AWS_DEV_STABLE
  - DOMAIN,signin.aws.amazon.com,AWS_DEV_STABLE
  - DOMAIN,console.aws.amazon.com,AWS_DEV_STABLE
  - MATCH,YOUR_FALLBACK_POLICY

DOMAIN-SUFFIX,amazonaws.com は多数のエンドポイントをまとめますが、開始時はログに出た bedrock-runtime.* や sts.* を DOMAIN 中心にしてから徐々に拡張する運用が安全です。リストの並べ替えと更新の型は ルール分流のベストプラクティス を参照してください。許可されていないサービスへの迂回には使わないでください。

DOMAIN-SUFFIX とルール順：MATCH より上で揃える

Clash は一行目から順に評価し、最初に当たった行で出口が決まります。広告ブロック用ルールや大きな拒否リスト、広すぎる GEOIP が amazonaws.com を先に片付けていたり、CDN を誤って直結／拒否していたりすると、ブラウザだけ別プロファイルで結果だけ見えている状態になります。開発者向けブロックセットを入れているプロファイルほど、この誤遮蔽を疑う価値があります。

「昨日まで AWS MCP が動いた」なら、(a) ルールプロバイダの自動更新で順序が変わった、(b) 更新取得自体がプロキシループで詰まり古いリストのまま、(c) サブスクリプション更新後にノード品質だけが劣化——の三通りを順に見ます。購読とノード保守 と タイムアウトと TLS の読み方 をセットにすると切り分けが速くなります。

システムプロキシ／TUN／HTTPS_PROXY の取りこぼし

開発者環境では、ブラウザ用に Clash のシステムプロキシをオンにしている一方、IDE 統合ターミナルだけ HTTPS_PROXY を設定していなかった、WSL／Docker だけ別ブリッジにいる——といったパターンが珍しくありません。Docker／ターミナル向け記事 の構成と突き合わせ、すべてのプロセスが同じ Clash アップストリームに到達できるかを確認してください。

TUN はPOSIX 環境への注入漏れを減らす一方、企業 VPN やホスト側の複数 NIC と競合することがあります。TUN の深掘り を読み、「システムプロキシに切り替えるとだけ直る」のか、「TUN が必要なのか」を短時間で A/B します。両方を同時に誤って二重に載せないよう注意してください。

GitHub 上の MCP サーバ実装をローカルで動かす場合、取得元の github.com／objects.githubusercontent.com と AWS 本体で出口が割れると、依存取得だけ止まったように見えます。GitHub まわりの分流 も辞書程度に参照し、ログに出たホストを足してください。

DNS・fake-ip が原因の「名前は返るが止まる」

fake-ip を使っていると、アプリには合成アドレスが返り実解決は後段になります。このとき DOMAIN 規則と DNS の順序理解が食い違うと、名前解決は一瞬でも TCP が進まず API タイムアウト にしか見えません。IDE 統合ターミナルはブラウザよりキャッシュ層が薄く、結果としてログに残るほうが素直です。

社内ネットワークで分割 DNS を使っていると、公開向けとは別のアドレスに誘導され、認証だけ失敗することがあります。IT の案内がある場合は順守しつつ、「家のクリーンな回線では再現しない」事実だけでも切り分け材料になります。一般的な確認は FAQ も参照してください。

Notion と AWS（S3 等）を同期するときの分流 はコラボレーション・ストレージ寄りの観測点が中心です。本稿は AWS MCP Server／Agent Toolkit for AWS と Bedrock を IDE から叩くときの認可連鎖と API／CDNに焦点を当て、検索意図も「同期ツール」ではなく「ローカル／IDE のエージェント」に寄せています。JetBrains Central や Cursor のログイン と同じく「開発者 UI のタイムアウト」 family ですが、名前空間が AWS 固有です。自分のスタックに合った記事だけを精読し、他は参照に割り切ると安全です。

⚠ コンプライアンス：サービス規約や法的制限、アクセス許可されていない環境での利用を前提にした迂回は説明対象ではありません。職場のセキュリティ方針に従ってください。

許可環境でのチェックリスト

  1. この MCP／SDK と Clash で AWS に接続することが契約およびポリシー上許されているか確認した。
  2. 失敗ウィンドウの接続ログから、サインイン・コンソール・bedrock-runtime／sts 等・静的 CDN に分類してホスト名を列挙した。
  3. それらが広域ブロックリストより上の行へ載っていることを確認した。
  4. ブラウザと IDE 子プロセスで HTTPS_PROXY／TUN／システムプロキシの差を A/B した。
  5. fake-ip 利用時は nameserver と DOMAIN 規則の整合を読み直した。
  6. 購読とルール更新がループせず成功することをログで確認した。
  7. 問題が残るときだけノード総入れ替えやリージョン／クォータ確認に進んだ。

メモだけで済ませず、設定ファイルの変更点を短文で残すと数日後の自分が助かります。チームで展開する場合も同様で、レビュアが「どのサフィックスをいつ足したか」を追えると再現切り分けが速くなります。

よくある質問

簡単な質疑を並べました。FAQPage の構造化データは <head> にあります。

ブラウザの AWS コンソールは開くのに、IDE の AWS MCP だけ止まりますがなぜですか。

ブラウザはシステムプロキシを尊重しやすく、拡張や言語サーバは環境変数やカーネル捕捉に依存しがちです。signin・console・bedrock-runtime 等のホストが別出口に割れると、片方だけタイムアウトに見えます。

Notion と AWS の同期向け記事と何が違いますか。

既稿はノートとオブジェクトストレージの横断が主で、本稿は AWS MCP Server／ツールキットと Bedrock API を IDE から叩くときの認証連鎖と CDN 分流を深掘りします。ルールの骨格は重なっても、切り分けの着眼点が異なります。

amazonaws.com をまとめて DOMAIN-SUFFIX すると危ないですか。

範囲が広すぎると無関係なワークロードまで同じ出口になります。ログに基づき DOMAIN から始め、増えたサフィックスを徐々に拡張するのが安全です。

静的 CDN は DIRECT の方が速いですか。

地域や ISP で差があります。静的ホストだけ止まるなら Bedrock API と同じ出口へ寄せ、DNS と証明書の整合を優先すると再現しにくいことが多いです。

まとめ

AWS MCP Server 周辺は単一ホストとの会話というより、OAuth／IdP・マネジメントコンソール・リージョン付き *.amazonaws.com の API・静的 CDN の短い連鎖です。MATCH まで届いているか、認証とデータプレーンと CDN が同じ出口か、DNS がルール設計と同じ視点か——この三通りを押さえると、リージョン障害やクォータを疑うより先に体感が変わることがあります。2026 年もエンドポイントは増減するため、黒箱の単一プリセットよりログを読んで増分更新するモデルのほうが持続します。

一部の単一チャネル VPN やブランド固定クライアントは、どの名前が増えたか観測しづらく、開発者が IDE で待たされる原因を特定しにくい面があります。Clash はドメインベースでルールプロバイダを差し替えやすく、上流リストが不透明でも自分で順序と例外を足せます。この透明性があるからこそ、許可環境でのセルフサービスにも向きます。

Clash V.CORE はその設計語彙に沿って UI とログを並べやすく、「aws.amazon.com 系のどのフェーズが詰まっているか」を短いセッションで切り分けやすいです。黒箱より出口とログが追える構成に寄せると、同僚との再現議論も早くなります。Clash を無料ダウンロードし、自分のワークステーションだけで検証するところから始めてください。サインインだけ別経路だった、という発見はすぐログに現れます。