翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
プライベート接続のトラブルシューティング
このページでは、 プライベートにホストされたツールへの接続 for AWS DevOps Agent の作成時または使用時に発生する可能性がある一般的な問題とその解決方法について説明します。各セクションでは、症状、最も可能性の高い原因、およびその修正手順について説明します。
プライベート接続の仕組みの概要については、「」を参照してくださいプライベートにホストされたツールへの接続。
DNS ホストアドレスが解決しない、またはトラフィックが間違った場所に到達する
症状
ホストアドレスの DNS 名を使用してプライベート接続を作成しましたが、接続がサービスに到達できません。これは、ターゲットサービスがセルフホスト GitLab インスタンス、内部 Application Load Balancer (ALB)、またはホスト名が VPC 内にのみ存在する MCP サーバーである場合に最もよく発生します。
DNS 解決に失敗しても、DNS に言及するメッセージは生成されません。代わりに、機能プロバイダーを登録または使用すると、一般的な到達可能性またはプロバイダーエラーとして表示されます。たとえば、Could not complete request to provider.、Unable to connect to the MCP server at <endpoint>. The connection was interrupted.、または などの認証エラーが表示される場合があります。メッセージが Authentication with provider failed. DNS を指さないため、次のチェックを使用して原因を確認します。
原因
デフォルトでは、プライベート接続はパブリック DNS () を使用してホストアドレスを解決しますdnsResolution: PUBLIC。ホスト名にプライベートホストゾーン、Amazon Route 53 Resolver ルール、またはオンプレミス DNS サーバーにのみレコードがある場合、パブリック解決は失敗し、接続はサービスに到達しません。
DNS が原因であることを確認する方法
ホストアドレスが VPC 内でのみ解決されるかどうかを確認します。同じ VPC 内の Amazon EC2 インスタンスまたは AWS CloudShell セッションから、 を実行します
nslookup <your-host-address>。パブリック DNS からではなくそこで解決され、プライベート接続が を使用する場合dnsResolution: PUBLIC、DNS 解決が原因です。名前の代わりに IP アドレスを使用してテストします。DNS 名の代わりにホストアドレスにターゲットのプライベート IP アドレス (またはロードバランサー IP) を使用するプライベート接続を一時的に作成します。接続がサービスに到達した場合、以前の障害はネットワークパスやサービス自体ではなく DNS 解決でした。
解決策
ホスト名が VPC 内でのみ解決される場合は、接続の作成時に DNS 解決モードを VPC 内 (
IN_VPC) に設定します。このモードでは、ホストアドレスは VPC コンテキスト内から解決されるため、プライベート専用ホスト名は正しく解決されます。「プライベート接続を作成する」を参照してください。DNS 解決モードは作成時に選択され、指定したホストアドレスに適用されます。作成後にサービスマネージドリソースゲートウェイが DNS を解決する方法を変更することはできないため、事前に正しいモードを選択してください。間違ったモードを選択した場合は、接続を削除し、正しいモードで再作成します。
ホストアドレスに (DNS 名ではなく) IP アドレスを指定した場合、DNS 解決モードは効果がなく、トラフィックはその IP に直接送信されます。
セットアップ
IN_VPCに を使用できない場合は、代わりにホストアドレスをターゲットのプライベート IP アドレス、またはパブリックに解決可能だがプライベート IP に転送されるロードバランサーの DNS 名にポイントできます。
接続が「作成に失敗しました」でスタックしています
症状
プライベート接続を作成すると、コンソールにステータスが接続失敗と表示されます ( のステータスdescribe-private-connectionが返されますCREATE_FAILED)。レスポンスには多くの場合、失敗の詳細な理由が含まれていないため、対処するエラーメッセージが表示されません。
原因
作成が失敗した場合、ほとんどの場合、サービスエラーではなく、リクエストまたは VPC の設定の問題が原因です。詳細な障害理由が常に表示されるわけではないため、エラーメッセージが表示されなくても、次のチェックリストを確認してください。
解決策
以下を順番に検証します。
ポート範囲は有効な形式を使用します。各ポート範囲を単一のポート ( など
443) または異なる開始ポートと終了ポートを持つ真の範囲 ( など) として指定します8080-8090。開始と終了が同じ (例:443-443) である「範囲」は拒否されます。最大 11 個のポート範囲を指定できます。サブネットには使用可能な IP アドレスがあります。リソースゲートウェイは、指定したサブネットに Elastic Network Interface (ENIs) をプロビジョニングします。これらのサブネットを使い果たすと、作成は失敗します。空きアドレス空間があるサブネットを選択します。
サブネットはサポートされているアベイラビリティーゾーンにあります。Amazon VPC Lattice は、すべてのアベイラビリティーゾーンをサポートしているわけではありません。以下を実行し、「プライベート接続の作成」に記載されているサポートされていないゾーンと比較します。
aws ec2 describe-subnets \ --subnet-ids <your-subnet-ids> \ --query 'Subnets[*].[SubnetId,AvailabilityZoneId]'
Amazon VPC Lattice サービスクォータに達していません。Amazon VPC Lattice クォータ、特にリソースゲートウェイの制限に対してアカウントを確認します。
IAM ポリシーまたは SCP がサービスにリンクされたロールをブロックしていません。サービスマネージドリソースゲートウェイは、サービスにリンクされたロールを介して作成されます。組織に Amazon VPC Lattice または Amazon EC2 API アクションを制限するサービスコントロールポリシー (SCPs) がある場合は、サービスにリンクされたロールがこれらのリソースを作成することを許可していることを確認してください。
これらの項目をすべて検証した後も接続が失敗し続ける場合は、 AWS サポートにお問い合わせください。
接続はアクティブですが、到達可能性エラーで機能登録が失敗する
症状
プライベート接続はアクティブ状態になりますが、それを使用する機能プロバイダー (MCP サーバーなど) を登録すると、登録は失敗します。MCP サーバーの場合、エラーメッセージは到達可能性チェックが失敗した方法を示しています。次のいずれかが表示されます。
The MCP server at '<endpoint>' timed out while initializing the session.(同様のバリアントはリソースの一覧表示を指します)Unable to connect to the MCP server at <endpoint>. The connection was interrupted. Verify the server is running and accessible, then try again.Unable to access tools from the MCP server at '<endpoint>' ...Could not complete request to provider.( として表示される場合もありますAPI error: 504)
原因
Active に到達するプライベート接続は、VPC へのネットワークパスが確立されていることを確認します。ターゲットサービスが予想されるアドレスとポートで応答していることは確認されません。機能プロバイダーを登録すると、 AWS DevOps Agent はエンドポイントが到達可能で応答していることを検証します。ここで、ターゲットの設定ミスが表示されます。メッセージは、失敗したレイヤーを示します。
タイムアウトメッセージは、接続がリッスンサービスに到達しなかったことを意味します。ほとんどの場合、ホストアドレス、ポート、または DNS 解決が正しくないか、セキュリティグループがトラフィックをブロックしています。
接続が中断されたメッセージは、通常、TLS ハンドシェイクの失敗またはサービスが接続を閉じることによって、接続がリセットまたは削除されたことを意味します。
ツールにアクセスできないメッセージは、エンドポイントがリクエストに応答したが拒否したことを意味します。これは通常、ネットワークの問題ではなく、認可またはプロバイダー側のエラーです。
プロバイダーメッセージへのリクエストを完了できませんでした。これは、プライベート接続を介してエンドポイントへのリクエストを完了できなかった一般的な問題です。以下の解決ステップを確認します。
解決策
タスクやインスタンスの IP ではなく、ロードバランサーの DNS をポイントします。頻繁な原因は、設定したポート ( など
8100) で TLS を終了するロードバランサーではなく、アプリケーションポート ( など) のコンテナタスクまたはインスタンス IP に解決される DNS レコードまたはホストアドレスです443。ホストアドレスが、ターゲットポートで実際に HTTPS を提供するエンドポイントに解決されることを確認します。サービスが設定されたポートで HTTPS を提供していることを確認します。ターゲットは、接続のポート範囲に含まれるポートで、最小 TLS バージョン 1.2 の HTTPS を提供する必要があります。
セキュリティグループのルールを双方向で確認します。リソースゲートウェイ ENIs にアタッチされたセキュリティグループがターゲットポートでのアウトバウンドトラフィックを許可し、サービスのセキュリティグループがそのポートでのインバウンドトラフィックを許可していることを確認します。VPC CIDR 範囲内の Amazon VPC Lattice データプレーン IPs からトラフィックが到着します。セキュリティグループ参照 (ENI セキュリティグループをソースとして許可) を使用するか、VPC CIDR からのインバウンドを許可できます。「プライベート接続のファイアウォールルールの設定」を参照してください。
プライベート CA の証明書チェーン全体を検証します。プライベート認証機関がサービスの TLS 証明書を発行した場合は、接続の作成時に PEM エンコードされた証明書チェーン全体を指定します。リーフ証明書を最初に配置し、次に中間、次にルートを配置します。チェーンが不完全な場合、ネットワークパスが上であっても TLS ハンドシェイクは失敗します。
ターゲットが実行されていることを確認します。登録を完了する前に、サービスが稼働していて、予想されるポートで接続を受け入れていることを確認してください。
OAuth トークン交換に到達できません
症状
プライベート接続を介して OAuth ベースの MCP サーバー機能プロバイダー (クライアント認証情報または 3LO) を登録しましたが、MCP サーバーエンドポイントに到達可能であってもトークン交換は失敗します。
原因
OAuth ベースの機能プロバイダーの場合、 AWS DevOps Agent はターゲット URL (MCP サーバーエンドポイント) と交換 URL (OAuth トークン交換エンドポイント) の 2 つのエンドポイントを呼び出します。単一のプライベート接続を選択すると、両方のエンドポイントに適用されます。2 つのエンドポイントが異なるネットワークパスを介してのみ到達可能な場合、1 つのプライベート接続を両方にルーティングすることはできません。
解決策
両方のエンドポイントが同じパス経由で到達可能な場合は、プライベート接続のホストアドレスが MCP サーバーエンドポイントとトークン交換エンドポイントの両方にルーティングできることを確認します。
エンドポイントで異なるネットワークパスが必要な場合は、単一の ではなくエンドポイントごとのフィールドを使用します
privateConnectionName。targetUrlPrivateConnectionNameMCP サーバーエンドポイントとトークン交換エンドポイントexchangeUrlPrivateConnectionNameに を設定します。1 つだけ設定した場合、もう 1 つのエンドポイントはパブリックインターネット経由で到達し、他のプライベート接続にはフォールバックしません。エンドポイントごとの名前を同じリクエストprivateConnectionNameで と組み合わせることはできません。「Routing the endpoint and the OAuth token exchange through different private connections」を参照してください。
リソースゲートウェイまたは ENIs、接続を削除した後も残ります。
症状
マネージドリソースゲートウェイとその ENIsされることを想定していましたが、VPC に表示されます。これにより、ENI 料金が発生し、 などのクリーンな VPC に依存するオペレーションがブロックされる可能性がありますterraform destroy。
原因
マネージドリソースゲートウェイと ENIsは、 AWS DevOps エージェントを介してプライベート接続を削除する場合にのみ削除されます。それらが残る最も一般的な理由は、実際には呼び出DeletePrivateConnectionされなかったか、AWSAIDevOpsManagedタグがマネージドリソースから削除されたため、削除を続行できないことです。
重要
AWS DevOps エージェントは、管理するリソース (リソースゲートウェイとその ENIs) に でタグ付けしますAWSAIDevOpsManaged。サービスにリンクされたロールは、このタグを持つリソースでのみ動作するため、AWSAIDevOpsManagedタグ を削除または変更しないでください。タグがない場合、 DeletePrivateConnectionはリソースをクリーンアップできず、削除は失敗します。
解決策
AWS DevOps エージェントを介して接続を削除します。コンソール (機能プロバイダー > プライベート接続 > アクション > 削除) または CLI を使用します。
aws devops-agent delete-private-connection \ --name my-mcp-tool-connection
AWS DevOps Agent が VPC からマネージドリソースゲートウェイと ENIs を削除するDELETE_IN_PROGRESSと、ステータスは に変わります。
削除に失敗した場合は、
AWSAIDevOpsManagedタグがまだ存在することを確認します。タグがリソースゲートウェイまたはその ENIs から削除された場合は、そのタグをそれらのリソースに再適用し、削除を再度実行します。マネージドリソースゲートウェイを直接削除しないでください。リソースゲートウェイはアカウント内で読み取り専用であり、 AWS DevOps Agent によって完全に管理されているため、Amazon VPC Lattice を通じて自分で削除することはできません。プライベート接続を削除すると、削除がトリガーされます。
プライベート接続を削除し、 タグが存在し、削除が完了した後もリソースゲートウェイまたは ENIs がまだ残っている場合は、 AWS サポートに連絡してリソースを調整します。
ヘルプのリクエスト
問題に関連するセクションを操作し、問題が解決しない場合は、 AWS サポートにお問い合わせください。サポートがネットワークパスを調査できるように、プライベート接続名、現在のステータス、 AWS リージョン、ターゲットホストアドレスとポートを含めます。