はじめに
AWSのセキュリティ向上やセキュリティ要件の達成において、VPCエンドポイント（Interface型 / AWS PrivateLink）の導入は欠かせません。しかし実務では、「エンドポイントを作成したのにパブリックIP経由で通信しようとしてしまう」「名前解決が正常に動作せず通信がタイムアウトする」といったトラブルが多発します。本記事では、インフラ実務で役立つ、VPCエンドポイントにおける名前解決の仕組み、トラブルシューティング方法、および正しい構築手順をステップバイステップで解説します。
前提知識/必要な理由
VPCエンドポイント（Interface型）を利用して、VPC内部からインターネットを経由せずにAWSサービス（S3、EC2、SSMなど）へ安全にアクセスするには、「プライベートDNS（Private DNS）」機能が鍵となります。
この機能が有効になっていない場合、AWSのサービス名（例：ssm.ap-northeast-1.amazonaws.com）の問い合わせに対してパブリックIPアドレスが返されてしまいます。結果として、インターネット接続を持たないプライベートサブネット内のリソースからは、AWSサービスへの通信が完全に遮断されてしまいます。これを防ぐために、VPC内部で正しい名前解決が行われるように設計・設定する必要があります。
具体的な設定手順・設計方法
ここでは、実務でよく利用される「SSM（Systems Manager）エンドポイント」を例に、名前解決を正しく行うための設定手順を解説します。
ステップ1：VPCのDNS設定の有効化
VPCエンドポイントのプライベートDNSを使用するには、対象のVPCで以下の2つの属性が必ず「有効（true）」になっている必要があります。
- enableDnsHostnames（DNSホスト名）
- enableDnsSupport（DNS解決）
AWS CLIを使用して、これらの設定状態の確認および有効化を行います。AWS CLIが未インストールの場合は、あらかじめインストールしておいてください。
# VPCの設定状況を確認
aws ec2 describe-vpc-attribute --vpc-id vpc-xxxxxx --attribute enableDnsHostnames
aws ec2 describe-vpc-attribute --vpc-id vpc-xxxxxx --attribute enableDnsSupport
# 有効化されていない場合は、以下のコマンドで有効化を実行
aws ec2 modify-vpc-attribute --vpc-id vpc-xxxxxx --enable-dns-hostnames '{"Value": true}'
aws ec2 modify-vpc-attribute --vpc-id vpc-xxxxxx --enable-dns-support '{"Value": true}'ステップ2：インターフェース型VPCエンドポイントの作成と設定
次に、VPCエンドポイントを作成します。この際、--private-dns-enabled オプションを指定して、プライベートDNSを有効化することが最も重要なポイントです。
aws ec2 create-vpc-endpoint \
--vpc-id vpc-xxxxxx \
--vpc-endpoint-type Interface \
--service-name com.amazonaws.ap-northeast-1.ssm \
--subnet-ids subnet-aaaaaa subnet-bbbbbb \
--security-group-ids sg-cccccc \
--private-dns-enabledステップ3：検証用クライアント（EC2）でのDNS解決確認
設定が正しく反映されているかを検証するため、VPC内のプライベートサブネットにあるEC2インスタンス（Linux環境）から名前解決をテストします。
名前解決の確認には dig コマンドを使用しますが、標準のAmazon Linux 2023やAmazon Linux 2などにはデフォルトでインストールされていない場合があります。そのため、事前にDNS検証ツールが含まれる bind-utils パッケージを導入します。
# Amazon Linux 2023 / Amazon Linux 2 でのDNS検証ツール導入手順
sudo dnf install -y bind-utils # AL2023の場合（AL2の場合は sudo yum install -y bind-utils）
# SSMエンドポイントに対する名前解決を実行
dig ssm.ap-northeast-1.amazonaws.comコマンド実行後、出力されたレコード（ANSWER SECTION）を確認します。以下のように、VPCのプライベートIPアドレス（例：10.0.x.x）が返ってくれば、プライベートDNSが正しく機能しています。
;; ANSWER SECTION:
ssm.ap-northeast-1.amazonaws.com. 60 IN A 10.0.1.50
ssm.ap-northeast-1.amazonaws.com. 60 IN A 10.0.2.50実務での注意点
- セキュリティグループの受信ルール設計：
VPCエンドポイントに付与したセキュリティグループ（例：sg-cccccc）では、アクセス元となるEC2が所属するセキュリティグループまたはCIDRから、「HTTPSポート（443）」の受信（インバウンド）を必ず許可してください。名前解決が正しくできても、このセキュリティグループの設定漏れにより通信がタイムアウトするケースが非常に多く見られます。 - 複数VPCやオンプレミス連携時の名前解決：
VPCエンドポイントのプライベートDNSは、そのエンドポイントが作成されたVPC内のRoute 53 Resolver（.2アドレス）でのみ有効です。Transit Gatewayなどで接続された別のVPCや、オンプレミス環境からこのエンドポイントを経由させたい場合は、Route 53 Resolverの「インバウンドエンドポイント」を設計・構築し、DNSクエリを適切にフォワーディングする必要があります。
まとめ
VPCエンドポイントを導入したにもかかわらず通信が失敗する場合、まずはVPC自体の「DNSホスト名/解決」の設定確認、次にエンドポイント作成時の「プライベートDNSの有効化」の有無を確認するのがトラブルシューティングの王道です。実務に臨む際は、事前に bind-utils などの検証用パッケージを導入しておき、スピーディーに dig 検証を行える体制を整えておきましょう。