プライベートDNS有効は「自動内線電話帳」。AWSが自動でRoute 53プライベートホストゾーンを作成し、標準エンドポイント名をVPCエンドポイントのプライベートIPに解決する。
プライベートDNS無効は「手動内線電話帳」。自分でRoute 53プライベートホストゾーンを作成し、複数VPCで共有可能な柔軟なDNS構成を実現できる。
重要な制限：自動作成されるプライベートホストゾーンはVPCエンドポイントが存在するVPC内でのみ機能。他VPCやオンプレミスからは参照不可。
試験頻出：複数VPC構成やハイブリッド構成では、プライベートDNSを無効にして手動ホストゾーン＋PHZ関連付けで柔軟に制御するパターンが問われる。
VPCエンドポイントのDNS動作を、オフィスビルの内線電話システムに例えて理解しましょう。AWSサービスへのアクセスは「外部の取引先に電話をかける」ようなものです。
💡 基本イメージ：ビル（VPC）の中から、外部の銀行（S3）や郵便局（SQS）などに電話をかけたいとします。普通なら公衆電話回線（インターネット）を使いますが、VPCエンドポイントはビル内に専用の直通回線窓口を設置して、公衆回線を使わずに直接つなげる仕組みです。
| AWS概念 | ビル内線電話のたとえ | 解説 |
|---|---|---|
| VPC | 🏢オフィスビル | あなたの会社のネットワーク空間そのもの |
| EC2インスタンス | 👤ビル内の社員 | 電話をかける人（サービスを利用する側） |
| AWSサービス (S3, SQS等) |
🏧外部の取引先 （銀行・郵便局） |
電話をかける相手先 |
| VPCエンドポイント (Interface型) |
📞ビル内の直通電話 （専用窓口） |
公衆回線を使わず直接つながる内線 |
| プライベートDNS （有効時） |
📗管理者が自動更新する 内線電話帳 |
「銀行の代表番号→内線番号」を自動登録 |
| プライベートDNS （無効時） |
📝自分で作る 内線電話帳 |
手動で番号対応を設定、複数ビルで共有可能 |
| Route 53 プライベート ホストゾーン |
📚内線電話帳の 本体 |
名前→番号の変換辞書（DNSレコード集） |
| ENI （プライベートIP） |
📱直通電話の 内線番号 |
実際に接続するための番号（IPアドレス） |
ポイント：プライベートDNS有効は「ビル管理者が電話帳を自動管理」、無効は「テナント自身が電話帳を手動管理」と覚えましょう。自動は便利ですが、そのビル内でしか使えないという制限があります。
プライベートDNSが有効な場合、AWSが自動でRoute 53プライベートホストゾーン(PHZ)を作成し、標準エンドポイント名をENIのプライベートIPに解決します。
プライベートDNSが無効の場合、AWS管理のPHZは作成されません。代わりに手動でPHZを作成し、複数のVPCに関連付けることで柔軟なDNS構成を実現できます。
2つのモードの違いを整理します。それぞれの特性を理解して、要件に合った選択をしましょう。
sqs.us-east-1.amazonaws.com のような標準名がそのままプライベートIPに解決される
enableDnsSupportとenableDnsHostnamesがtrueである必要がある
vpce-xxx.sqs.us-east-1.vpce.amazonaws.com で直接アクセス可能
| 比較項目 | 有効（自動モード） | 無効（手動モード） |
|---|---|---|
| Route 53 PHZ | AWSが自動作成・管理 | 利用者が手動で作成 |
| DNS名 | 標準エンドポイント名で解決 | エンドポイント固有DNS名 or 手動設定 |
| 適用範囲 | 同一VPC内のみ | 複数VPC・オンプレミスに拡張可能 |
| 運用コスト | 低い（自動管理） | やや高い（手動設定・維持） |
| 柔軟性 | 限定的 | 高い（カスタムDNS設定可能） |
| 推奨ユースケース | 単一VPC・シンプル構成 | マルチVPC・ハイブリッド構成 |
| 前提条件 | enableDnsSupport=true enableDnsHostnames=true |
特になし |
EC2インスタンスが sqs.us-east-1.amazonaws.com を解決しようとする。たとえ話では「社員が銀行の代表番号を電話帳で調べる」。
VPCのDNSリゾルバー（AmazonProvidedDNS）が、AWSが自動作成したプライベートホストゾーンを参照。パブリックDNSではなくPHZが優先される。
VPCエンドポイントのENIに割り当てられたプライベートIPアドレス（例：10.0.1.50）が返される。「電話帳で内線番号が見つかる」。
EC2はプライベートIPを使ってVPCエンドポイント経由でSQSに接続。トラフィックはインターネットを経由せず、AWSバックボーンネットワークのみを通る。
vpce-0abc123.sqs.us-east-1.vpce.amazonaws.com を直接指定。SDK/CLI設定で --endpoint-url パラメータを変更する必要あり。
Route 53で sqs.us-east-1.amazonaws.com のプライベートホストゾーンを手動作成し、エイリアスレコードでVPCエンドポイントのDNS名を指定。複数VPCに関連付け可能。
オンプレミスDNSサーバーからRoute 53 Resolverインバウンドエンドポイントに条件付きフォワーディングを設定し、オンプレからもVPCエンドポイント経由でAWSサービスにアクセス。
実務では複数VPCやオンプレミス連携のケースが多く、プライベートDNSの有効/無効の選択が重要になります。
プライベートDNS有効が最適。自動PHZで設定不要、コード変更なしで即利用可能。最もシンプルな構成。
プライベートDNS無効＋手動PHZ推奨。Hub VPCにエンドポイントを集約し、手動PHZを全Spoke VPCに関連付けることで一元管理。
プライベートDNS無効＋Route 53 Resolver推奨。オンプレDNSからResolverインバウンドエンドポイントへ転送し、手動PHZで名前解決。
よくある落とし穴：プライベートDNSを有効にしたまま、他VPCからTransit Gatewayで接続しても、自動作成PHZは他VPCに関連付けられないため、名前解決が失敗します。マルチVPC構成では必ず手動PHZ方式に切り替えましょう。
VPCエンドポイントのDNS動作を最大限に活かすために、以下の4つの戦略を柱としたアーキテクチャ設計が重要です。ビル内線電話のたとえでいえば、「本社・支社すべてのビルで、同じ電話帳を使い、同じ番号で取引先につながり、しかもすべて内線のまま」という理想の通信環境を実現する方法です。
sqs.us-east-1.amazonaws.com という標準DNS名でVPCエンドポイントにアクセス
4つの戦略がどのように組み合わさって、スケーラブルなプライベート通信基盤を構成するかを図解します。
VPCエンドポイント作成時に --no-private-dns-enabled を指定。既存エンドポイントは modify-vpc-endpoint で変更可能。無効化後は必ず手動PHZを作成し、エイリアスレコードでENIのDNS名を設定する。
Route 53で sqs.us-east-1.amazonaws.com のPHZを作成し、Aレコード（エイリアス）でVPCエンドポイントのDNSエントリを指定。このPHZをHub VPC＋全Spoke VPCに associate-vpc-with-hosted-zone で関連付ける。
VPCエンドポイント経由でAWSサービスに接続すると、通信はAWSバックボーンネットワークのみを通過。NAT GatewayやIGWが不要になり、データ処理料金の削減＋遅延改善＋セキュリティ向上を同時に達成する。
Route 53 Resolverインバウンドエンドポイントを作成し、オンプレDNSサーバーに条件付きフォワーダー（amazonaws.com → Resolver IP）を設定。Direct Connect/VPN経由でオンプレからもプライベートアクセスが可能になる。
なぜ4つを同時に実装するのか？：いずれか1つだけでは不完全です。戦略1（無効化）で柔軟性を確保し、戦略2（統一DNS）でアプリケーション透過性を維持し、戦略3（完全プライベート通信）でセキュリティ・コストを最適化し、戦略4（オンプレ統合）でハイブリッド環境にも対応する。この4つが揃って初めて、エンタープライズレベルのプライベート通信基盤が完成します。
# プライベートDNS有効（デフォルト）でVPCエンドポイント作成 aws ec2 create-vpc-endpoint \ --vpc-id vpc-0abc123def456 \ --service-name com.amazonaws.us-east-1.sqs \ --vpc-endpoint-type Interface \ --subnet-ids subnet-aaa111 subnet-bbb222 \ --security-group-ids sg-0123456789 \ --private-dns-enabled # プライベートDNS無効で作成（マルチVPC構成向け） aws ec2 create-vpc-endpoint \ --vpc-id vpc-0abc123def456 \ --service-name com.amazonaws.us-east-1.sqs \ --vpc-endpoint-type Interface \ --subnet-ids subnet-aaa111 subnet-bbb222 \ --security-group-ids sg-0123456789 \ --no-private-dns-enabled
AWSTemplateFormatVersion: '2010-09-09' Resources: SQSEndpoint: Type: AWS::EC2::VPCEndpoint Properties: VpcId: !Ref MyVPC ServiceName: !Sub com.amazonaws.\${AWS::Region}.sqs VpcEndpointType: Interface SubnetIds: - !Ref PrivateSubnet1 - !Ref PrivateSubnet2 SecurityGroupIds: - !Ref EndpointSG # trueで有効、falseで無効 PrivateDnsEnabled: false
resource "aws_vpc_endpoint" "sqs" { vpc_id = aws_vpc.main.id service_name = "com.amazonaws.us-east-1.sqs" vpc_endpoint_type = "Interface" subnet_ids = [ aws_subnet.private_a.id, aws_subnet.private_b.id ] security_group_ids = [aws_security_group.endpoint.id] # マルチVPC構成ではfalseに設定 private_dns_enabled = false }
# 1. 手動でプライベートホストゾーン作成 aws route53 create-hosted-zone \ --name sqs.us-east-1.amazonaws.com \ --vpc VPCRegion=us-east-1,VPCId=vpc-hub123 \ --caller-reference sqs-phz-\$(date +%s) \ --hosted-zone-config PrivateZone=true # 2. Spoke VPCにも関連付け aws route53 associate-vpc-with-hosted-zone \ --hosted-zone-id Z0123456ABCDEF \ --vpc VPCRegion=us-east-1,VPCId=vpc-spoke-a aws route53 associate-vpc-with-hosted-zone \ --hosted-zone-id Z0123456ABCDEF \ --vpc VPCRegion=us-east-1,VPCId=vpc-spoke-b # 3. エイリアスレコード作成 aws route53 change-resource-record-sets \ --hosted-zone-id Z0123456ABCDEF \ --change-batch '{ "Changes": [{ "Action": "CREATE", "ResourceRecordSet": { "Name": "sqs.us-east-1.amazonaws.com", "Type": "A", "AliasTarget": { "HostedZoneId": "Z1HUB2JCJCWAQQ", "DNSName": "vpce-0abc.sqs.us-east-1.vpce.amazonaws.com", "EvaluateTargetHealth": true } } }] }'
Resources: SQSPrivateHostedZone: Type: AWS::Route53::HostedZone Properties: Name: sqs.us-east-1.amazonaws.com VPCs: - VPCId: !Ref HubVPC VPCRegion: !Ref AWS::Region - VPCId: !Ref SpokeVPCA VPCRegion: !Ref AWS::Region SQSAliasRecord: Type: AWS::Route53::RecordSet Properties: HostedZoneId: !Ref SQSPrivateHostedZone Name: sqs.us-east-1.amazonaws.com Type: A AliasTarget: HostedZoneId: !GetAtt SQSEndpoint.DnsEntries.0.HostedZoneId DNSName: !GetAtt SQSEndpoint.DnsEntries.0.DnsName EvaluateTargetHealth: true
resource "aws_route53_zone" "sqs_phz" { name = "sqs.us-east-1.amazonaws.com" # Hub VPCに関連付け vpc { vpc_id = aws_vpc.hub.id } } # Spoke VPCにも関連付け resource "aws_route53_zone_association" "spoke_a" { zone_id = aws_route53_zone.sqs_phz.id vpc_id = aws_vpc.spoke_a.id } # エイリアスレコード作成 resource "aws_route53_record" "sqs_alias" { zone_id = aws_route53_zone.sqs_phz.id name = "sqs.us-east-1.amazonaws.com" type = "A" alias { name = aws_vpc_endpoint.sqs.dns_entry[0].dns_name zone_id = aws_vpc_endpoint.sqs.dns_entry[0].hosted_zone_id evaluate_target_health = true } }
enableDnsSupportとenableDnsHostnamesを事前にtrueに設定確認
原因：VPCのDNS設定が無効になっている
enableDnsSupport と enableDnsHostnames を共にtrueに設定してから再実行。aws ec2 modify-vpc-attribute --vpc-id vpc-xxx --enable-dns-support '{"Value":true}'aws ec2 modify-vpc-attribute --vpc-id vpc-xxx --enable-dns-hostnames '{"Value":true}'
原因：プライベートDNS有効の自動PHZは同一VPC内限定。他VPCからは名前解決がパブリックIPに向かう。
原因：VPCエンドポイントのENIに付与されたセキュリティグループのインバウンドルールが不足
aws ec2 authorize-security-group-ingress --group-id sg-xxx --protocol tcp --port 443 --source-group sg-app
原因：プライベートDNS有効にしていない、またはPHZの関連付けが正しくない
aws ec2 describe-vpc-endpoints で PrivateDnsEnabled の状態を確認。手動PHZ使用時はRoute 53でレコードの存在とVPC関連付けを確認。
原因：オンプレDNSからRoute 53 Resolverへの条件付きフォワーディングが未設定
sqs.us-east-1.amazonaws.com）をResolverのIPに転送する条件付きフォワーディングルールを追加。
🚨 試験の引っかけパターン：「プライベートDNS有効にすれば全VPCで使える」という選択肢は不正解。自動PHZの適用範囲はエンドポイント所在VPCのみ。複数VPC構成では手動PHZ方式が必要。
はい、既存のVPCエンドポイントのプライベートDNS設定は変更可能です。aws ec2 modify-vpc-endpoint --vpc-endpoint-id vpce-xxx --private-dns-enabled（有効化）または --no-private-dns-enabled（無効化）で切り替えられます。ただし、切り替え時にDNSキャッシュのTTL期間中は古い解決結果が残る場合があるため注意してください。
Gateway型エンドポイントにはプライベートDNS設定はありません。Gateway型はルートテーブルにプレフィックスリストを追加する方式で、DNS解決の仕組みが根本的に異なります。S3やDynamoDBでInterface型エンドポイントを使いたい場合は、別途Interface型として作成し、プライベートDNS設定を行います。
Route 53の仕様として、VPCに関連付けられたプライベートホストゾーンはパブリックDNSよりも優先されます。そのため、プライベートDNS有効時の自動PHZも、手動作成PHZも、パブリックDNS（インターネット上のDNSレコード）より先に参照されます。同一ドメインで自動PHZと手動PHZが競合する場合、動作が不安定になるため避けるべきです。
Interface型VPCエンドポイントを作成すると、標準のサービスエンドポイント名とは別に、vpce-0abc123.sqs.us-east-1.vpce.amazonaws.com のようなエンドポイント固有のDNS名が発行されます。これはプライベートDNSの有効/無効に関係なく常に利用可能で、直接このDNS名をSDKの--endpoint-urlに指定することもできます。
はい、Route 53プライベートホストゾーンは異なるリージョンのVPCにも関連付け可能です。ただし、VPCエンドポイント自体はリージョン内リソースのため、クロスリージョンのDNS解決はできても、実際のトラフィックはエンドポイントが存在するリージョン内のVPCからのみ流せます。リージョン間のルーティング設計に注意してください。
vpce-xxx.service.region.vpce.amazonaws.com 形式のDNS名。PHZ設定に依存せず直接使用可能。自動PHZ作成 → 標準名でプライベートIP解決 → 同一VPC限定 → コード変更不要 → 単一VPC向け
手動PHZ or 固有DNS名 → 複数VPC共有可 → ハイブリッド対応 → 柔軟なDNS制御 → マルチVPC向け
enableDnsSupport = true
enableDnsHostnames = true
SG: TCP 443 インバウンド許可
サブネット: 複数AZ配置推奨
「複数VPCで共有」→ 手動PHZ
「オンプレから」→ Resolver
「コード変更なし」→ 有効
「Hub集約」→ TGW + 無効
① 戦略的無効化 → 制限解除
② 統一DNS名前空間 → コード変更ゼロ
③ 完全プライベート通信 → 安全＋低コスト
④ 既存インフラ統合 → Resolver + TGW
DNS無効 + 手動PHZ + Resolver Inbound + DX/VPN + TGW Hub&Spoke = オンプレ＋全VPCからプライベートアクセス完成
Created by SSuzuki1063
AWS SAP Learning Resources