こんにちは、SREチームのシニアエンジニアです。
インフラの現場でWeb APIの設計やマイクロサービスのセキュアな通信基盤を構築していると、一度は必ずぶつかる壁があります。それが「AWS PrivateLink（Interface型VPCエンドポイント）」の内部挙動とSSL/TLS終端の仕様です。
「インターネットを経由せずにセキュアにAWSサービスや他社のSaaSへ接続できる」という謳い文句に惹かれて設定を進めたものの、いざcurlやアプリケーションコードから叩いてみると、なぜか証明書エラー（x509: certificate signed by unknown authorityなど）に悩まされたり、DNSの解決先が想定外のプライベートIPになって面食らったりする……。
今回は、パケットがVPCの境界をどのように駆け抜け、どこでSSL/TLSハンドシェイクが行われ、どのようにカプセル化されて宛先に届くのか。その内部挙動のリアルを、実務で役立つコードやデバッグのTIPSを交えながら徹底的に解説していきましょう。教科書には載っていない「現場の勘所」を掴んでいってください。
—
1. PrivateLink通信とSSL/TLS終端の基本仕様
まず、Interface型VPCエンドポイント（AWS PrivateLink）の本質を整理します。
PrivateLinkは、AWSのバックボーンネットワーク内に閉じた形で、VPC内のプライベートIPアドレスから指定したサービス（AWSマネージドサービスや、独自に構築したEndpoint Service）へ安全にアクセスするための仕組みです。
ここでよくある誤解が、「パケットがエンドポイントから宛先まで、ずっと暗号化されたままトンネリングされているのか？」という点です。答えは「No」です。
443番ポートとSSL/TLS終端のメカニズム
Interface型VPCエンドポイントは、VPC内のENI（Elastic Network Interface）としてデプロイされ、通常は TCP/443 でクライアントからのリクエストを受け付けます。
1. クライアント側の視点: アプリケーションは、宛先ドメイン（例: *.vpce-xxxx.s3.ap-northeast-1.vpce.amazonaws.com や、それらに紐づくカスタムDNS名）に対して、HTTPS（ポート443）でリクエストを送出します。この瞬間、クライアントはエンドポイントのENIが提示するSSL証明書を検証し、TLSハンドシェイクを完了させます。つまり、クライアントとVPCエンドポイントの間は厳密に暗号化（SSL/TLS終端）されます。
2. エンドポイントとサービス側の視点: VPCエンドポイントで一度復号（終端）されたトラフィックは、AWSの強固な内部バックボーンネットワークを経由して、宛先のサービスプロバイダー側へルーティングされます。このバックボーン区間はAWSの物理的な管理下にあるため、別のプロトコルや追加の暗号化レイヤー（あるいはサービス独自の通信プロトコル）で安全に運ばれます。
つまり、SSL/TLSの終端は「VPCエンドポイントのENI上」で行われるという点が極めて重要なポイントです。
—
2. DNSとパケットカプセル化の裏側
では、VPC内で名前解決を行い、パケットが流れるときに何が起きているのでしょうか。
プライベートホストゾーン（PHZ）とENIのプライベートIP
PrivateLinkを作成すると、AWSは自動的にVPCのデフォルトDNS（AmazonProvidedDNS）に対して、エンドポイント特有のDNSレコードを登録します。プライベートHosted Zone（PHZ）を有効にしている場合、対象のサービスのエンドポイント名（例: s3.ap-northeast-1.amazonaws.com）を引くと、インターネット側のパブリックIPではなく、VPC内に配置されたENIのプライベートIPアドレスが返されます。
ネットワーク仮想化（Hypervisor層）とカプセル化の挙動
クライアントインスタンスから返されたプライベートIPに向けて送出された TCP/443 のパケットは、VPCの仮想ルーターおよびハイパーバイザー層（AWSの基盤）でキャッチされます。
ここで、AWS特有のネットワーク仮想化技術（AWS Nitro Systemなど）によるパケットのカプセル化が発生します。
クライアントのENIから送出されたIPパケットは、AWSの内部ネットワーク用の外側ヘッダーでカプセル化（ENCAP）され、物理的なバックボーン上を宛先サービスのネットワークまで高速に転送されます。このとき、エンドポイントのENI自体が「プロキシ」のような振る舞いをし、クライアントの接続要求をバックボーン側のターゲットへ安全に中継しているのです。
—
3. 実務で直面する証明書検証とコード実装例
現場で最もトラブルになりやすいのが、「カスタムドメインを利用する場合」や「プライベートCA（ACM Private CA）を発行してエンドポイントサービスを自作した場合」の証明書検証エラーです。
クライアント（PythonやNode.js、あるいはcurl）からリクエストを送る際、エンドポイントが返すSSL証明書のCN（Common Name）やSAN（Subject Alternative Names）が、リクエストしているドメイン名と一致しているか、あるいは信頼されたルートCAから発行されているかが厳密にチェックされます。
以下に、Python（requests）およびJavaScript（Fetch API）、そしてデバッグ用のcurlコマンドでの実践的な実装例を示します。
パターンA: Python (requests) での安全な接続とカスタムCAの指定
自社製のEndpoint Serviceなどでプライベート証明書を使っている場合、信頼するCA証明書（PEMファイル）を明示的に指定する必要があります。
import requests
# エンドポイントのカスタムDNS名（またはエンドポイントのURL）
# ※ プライベートDNS名を使用する場合は、標準の証明書が有効なため verify=True で動作します
url = "https://my-custom-service.internal.net/api/v1/data"
# 自社製Private CAの証明書バンドルへのパス
ca_bundle_path = "/etc/ssl/certs/internal-corporate-root-ca.pem"
try:
# タイムアウトとCA証明書のパスを明示的に指定してリクエストを送信
response = requests.get(
url,
verify=ca_bundle_path, # ここでプライベートCAを信頼させる
timeout=5.0 # クラウド環境ではタイムアウトの設定が命綱です
)
# ステータスコードのチェック
response.raise_for_status()
print(f"通信成功！ ステータス: {response.status_code}")
print(f"レスポンスボディ: {response.json()}")
except requests.exceptions.SSLError as e:
print(f"SSL/TLSハンドシェイクまたは証明書検証でエラーが発生しました: {e}")
except requests.exceptions.RequestException as e:
print(f"ネットワーク層またはHTTP通信でエラーが発生しました: {e}")パターンB: デバッグの王様 curl による挙動確認
「証明書周りが怪しい」「名前解決が本当にプライベートIPを向いているか確かめたい」というときは、VERBOSEオプションとIP直指定を組み合わせた curl デバッグが最強の武器になります。
# 1. まず通常のHTTPSリクエストで証明書のチェーンとSSLのバージョンを確認する
curl -v https://vpce-0123456789abcdef0-99999999.s3.ap-northeast-1.vpce.amazonaws.com/healthcheck
# 2. 【現場のTips】ホスト名（SNI）を維持したまま、特定のプライベートIPに対して直接リクエストを飛ばす
# （DNSが正常に引けているかの切り分けに絶大な効果を発揮します）
curl -v --resolve my-service.internal.net:443:10.0.132.45 \
https://my-service.internal.net/healthcheck*解説:* --resolve オプションを使うと、DNSサーバーへの問い合わせをバイパスして、指定したホスト名とポート (my-service.internal.net:443) の通信を、特定のプライベートIP (10.0.132.45 = エンドポイントのENIのIP) に直接流し込むことができます。これにより、「証明書のSANにそのホスト名が含まれているか」「ENIまでパケットが届いてTLS終端できているか」を純粋に切り分けることができます。
—
4. トラブルシューティング：よくあるハマりどころとSREの知見
最後に、現場のSREとして数々の修羅場をくぐり抜けてきた中で得た、PrivateLink通信における代表的なトラブルシューティングの勘所を共有します。
1. セキュリティグループの「双方向」の穴あけ忘れ
- 症状: 接続タイムアウト (
Connection timed out) になる。 - 原因: エンドポイントのENIにアタッチされているセキュリティグループだけでなく、「接続元リソース（EC2やLambdaなど）のセキュリティグループ」、および「バックボーン側のターゲット（NLBやリソース側）」のセキュリティグループで、
TCP/443が双方向（あるいはインバウンド/アウトバウンド）で許可されているか確認する必要があります。特にNLBを挟む場合、NLB側のターゲットグループのセキュリティグループ設定漏れが非常によくあります。
2. プライベートDNS名が有効になっていない
- 症状: コード側でAWS公式のサービス名（例:
s3.region.amazonaws.com）を指定しているのに、パブリックIPへ向かってしまい、パケットがインターネットゲートウェイ（IGW）方向へ迷子になる。 - 原因: VPCエンドポイント作成時に「プライベートDNS名有効化（Enable private DNS name）」のチェックボックスを入れ忘れているケースです。AWSマネージドサービスの場合、ここを有効にしないとVPC内のデフォルトDNSがプライベートIPを返してくれません。後から有効化する場合は、VPCのエンドポイント設定からチェックを入れ直してください。
3. クロスカバレッジなルーティングとルートテーブル
- 症状: エンドポイントのENIが存在するサブネットと、クライアントが存在するサブネットのルーティングが隔離されている。
- 原因: Interface型エンドポイントは、各アベイラビリティゾーン（AZ）ごとにENIを配置します。クライアントがAZ-aにいるなら、AZ-aにあるエンドポイントENIへ綺麗にルーティングされる必要があります。マルチAZ環境では、すべての利用するAZにエンドポイントのENIをデプロイしておくのが、可用性とネットワークパスの最適化（クロスAZ転送量の削減）において鉄則です。
—
まとめ
AWS PrivateLinkとポート443を活用したSSL/TLS終端の仕組みは、一見すると複雑な魔法のように見えますが、その実態は「VPC内のENIがクライアントのTLSを一度終端し、AWSの屈強なバックボーンへ安全に荷物を載せ替える巧妙なプロキシ機構」です。
DNSの解決先、ENIのセキュリティグループ、そして証明書の検証フロー。これらパケットの旅路を頭の中に描きながら設計・実装を行えば、どんな難解なネットワークエラーも必ず論理的に解決へ導くことができます。
現場のインフラ運用やAPI設計において、今回の知見が皆さんのトラブルシューティングのスピードを加速させる一助となれば幸いです。セキュアで快適なクラウドネットワークライフを！
コメント