💡 まず最初に結論!
🔒 プライベートホストゾーンとは?
VPC内部でのみ使用できるプライベートなDNS。インターネットからはアクセス不可で、VPC内のリソースだけが名前解決できる。
📍 いつ使う?
内部システム間の通信でIPアドレスではなくドメイン名を使いたいとき。セキュリティと運用性が大幅に向上!
🔗 複数VPCで共有可能
1つのプライベートホストゾーンを複数のVPCに関連付けて、共通の内部DNSとして利用可能。
🔀 スプリットビューDNS
同じドメイン名で内部と外部で異なるIPアドレスを返すことが可能。柔軟なDNS設計を実現。
📖 たとえ話で理解しよう!「会社の内線電話帳」
🏢 会社のオフィス
大きな会社には2種類の電話帳があります...
会社のWebサイトに載っている電話番号。誰でも見れる。
社員だけが使える内線番号一覧。外部の人には見せない機密情報。
社員だけが入れる建物。内線電話は建物内でのみ使用可能。
☁️ AWSの世界
Route 53も同じ仕組みを提供します...
インターネットに公開されるDNS。世界中の誰でもドメイン名を解決できる。
VPC内部専用のDNS。関連付けられたVPC内からのみ名前解決可能。
AWS内の隔離されたネットワーク空間。プライベートホストゾーンはここでのみ有効。
💡 ポイント
「田中さんの内線番号は?」と社内で聞けば「1234」と教えてもらえますが、
社外の人が同じ質問をしても答えてもらえません。
プライベートホストゾーンも同様に、「db.internal.example.com」というドメイン名は
VPC内のEC2インスタンスからは解決できますが、インターネットからは絶対に解決できません。
これがセキュリティの要です!
🎨 パブリック vs プライベート ホストゾーン
🌍 パブリックホストゾーン
🔐 プライベートホストゾーン
🔀 スプリットビューDNS(スプリットホライズンDNS)
同じドメイン名でも、アクセス元によって異なるIPアドレスを返す魔法の仕組み!
← インターネットからのアクセスはパブリックIPへ
example.com
← VPC内からのアクセスはプライベートIPへ
🎭 スプリットビューDNSのメリット
- ✅ VPC内のリソース同士はプライベートネットワーク経由で通信(低レイテンシー、セキュア)
- ✅ 外部ユーザーは同じドメイン名でパブリックエンドポイントにアクセス
- ✅ アプリケーションのコード変更不要(同じドメイン名を使用)
🎯 主なユースケース
データベースへの内部接続
RDSやAuroraへの接続時にIPアドレスではなく覚えやすいドメイン名を使用。フェイルオーバー時も自動で新しいインスタンスを指す。
db-primary.internal.myapp.com → 10.0.1.50
db-replica.internal.myapp.com → 10.0.1.51
マイクロサービス間通信
サービス間の通信でサービスディスカバリとして活用。サービスが移動してもDNSレコードを更新するだけ。
auth-service.internal.myapp.com
payment-service.internal.myapp.com
ハイブリッド環境の名前解決
オンプレミスとAWS間でシームレスな名前解決。Route 53 Resolverと組み合わせて双方向のDNS解決を実現。
オンプレミス → aws-app.corp.local
AWS → onprem-db.corp.local
VPCエンドポイントの簡素化
VPCエンドポイントの長いDNS名にわかりやすいエイリアスを設定。S3やDynamoDBへのアクセスを簡素化。
s3.internal.myapp.com →
vpce-xxx.s3.region.vpce.amazonaws.com
マルチVPC環境
1つのプライベートホストゾーンを複数VPCで共有。中央集権的なDNS管理でマルチアカウント環境を簡素化。
開発VPC + 本番VPC で同じ
shared.internal.company.com を共有
環境分離とテスト
本番/ステージング/開発環境ごとに異なるプライベートホストゾーンを使用。同じアプリ設定で異なる環境をテスト。
api.dev.internal.com → 開発DB
api.prod.internal.com → 本番DB
🔗 VPCとの関連付け
❓ そもそも「関連付け」とは?
「このプライベートホストゾーンのDNSを、どのVPCで使えるようにするか」を設定することです。
関連付けされたVPC内のリソースだけが、そのプライベートホストゾーンのDNSレコードを名前解決できます。
📖 たとえ話:「内線電話帳をどのビルに配布するか」
👆 配布されたビル(関連付けされたVPC)の社員だけが、内線電話帳を使えます!
🔧 技術的な動作イメージ
解決できる!
解決できる!
解決不可!
💡 なぜ関連付けが必要?
セキュリティ
必要なVPCだけにDNS情報を公開。不要なネットワークからのアクセスを防止。
環境分離
開発・ステージング・本番環境で異なるDNS設定を使い分け可能。
柔軟性
後から関連付けの追加・削除が可能。運用中の変更も簡単。
📊 複数VPCでの共有イメージ
ホストゾーン internal.myapp.com
📍 同一リージョン内
同じリージョン内のVPCであれば、簡単に関連付けが可能。コンソールから数クリックで完了。
🌍 クロスリージョン
異なるリージョンのVPCとも関連付け可能!グローバルなプライベートDNSを構築できる。
👥 クロスアカウント
別のAWSアカウントのVPCとも関連付け可能。マルチアカウント環境での一元管理に最適。
⚙️ 関連付けのCLIコマンド例
🎯 一貫したDNS解決とFQDN
複数VPCで共通のドメイン名を使い、すべてのリソースに統一された命名規則でアクセス!
❓ 「一貫したDNS解決」と「FQDN」とは?
📛 FQDN(完全修飾ドメイン名)
Fully Qualified Domain Nameの略。
省略なしの完全なドメイン名のこと。
🔄 一貫したDNS解決
どのVPCからでも同じドメイン名で同じリソースにアクセスできること。
📖 たとえ話:「会社のメールアドレス」
💡 「tanaka@mycompany.com」と言えば、
どの部署(VPC)からでも同じ人(リソース)に繋がる!
🔧 技術的な動作イメージ
で接続可能!
で接続可能!
で接続可能!
🎯 どのVPCからでも「db.aws.example.com」で同じデータベース(10.0.1.50)にアクセス可能!
⚖️ IPアドレス直接指定 vs FQDN
IPアドレス直接指定
- IPアドレスを覚えにくい
- IPが変わったら全部修正が必要
- どれがどのサーバーか分かりにくい
FQDN(ドメイン名)を使用
- 分かりやすい名前!
- IPが変わってもDNSレコードだけ更新
- 何のサーバーか一目瞭然
📝 用語まとめ
| 用語 | 意味 | 例 |
|---|---|---|
| サフィックス | ドメイン名の末尾部分(共通の接尾辞) | aws.example.com |
| FQDN | 完全修飾ドメイン名(省略なしの完全な名前) | db.aws.example.com |
| 一貫したDNS解決 | どのVPCからでも同じ名前で同じリソースにアクセス | VPC-A/B/C → 同じ結果 |
| DNSレコード | ドメイン名とIPアドレスの対応表のエントリ | A / CNAME / ALIAS |
💡 ポイントまとめ
- 1️⃣ 共通のサフィックス(aws.example.com) = 会社のメールドメイン「@mycompany.com」のようなもの
- 2️⃣ 各リソースのDNSレコード = 社員名簿の各エントリ(田中さん、鈴木さん...)
- 3️⃣ FQDN = 「tanaka@mycompany.com」のように、完全な名前でリソースを特定
- 4️⃣ 一貫したDNS解決 = どの部署(VPC)からでも同じ名前で同じ人(リソース)に繋がる
⚙️ 設定手順
プライベートホストゾーンの作成
Route 53コンソールで「ホストゾーンの作成」を選択し、タイプを「プライベートホストゾーン」に設定。
VPCとの関連付け
作成したホストゾーンに、名前解決を行いたいVPCを関連付けます。
DNSレコードの作成
内部リソースを指すAレコードやCNAMEレコードを作成します。
DNS解決の確認
VPC内のEC2インスタンスから名前解決ができることを確認します。
✨ ベストプラクティス
✅ 推奨事項
- 内部用ドメインには
.internalや.localを使用 - 適切なTTL値を設定(推奨: 60-300秒)
- ヘルスチェックを併用してフェイルオーバーを実装
- CloudWatchでDNSクエリをモニタリング
- 複数VPCで共有する場合はRAM(Resource Access Manager)を活用
- DNSSEC署名の有効化を検討
❌ 避けるべきこと
- 実在するパブリックドメインと同じ名前は使わない
- TTLを極端に短く設定しない(DNSサーバー負荷増)
- プライベートIPをパブリックホストゾーンに登録しない
- VPCのDNS設定(enableDnsHostnames)を無効にしない
- クロスアカウント関連付けで過度なアクセス許可を与えない
💰 料金体系
ホストゾーン
(26以降は$0.10/月)
DNSクエリ
DNSクエリ課金
VPC関連付け
追加料金なし
※ 料金は東京リージョン(ap-northeast-1)の参考価格です。最新の料金はAWS公式ページをご確認ください。
❓ よくある質問(FAQ)
プライベートホストゾーンはインターネットから見えますか?
+プライベートホストゾーンのDNSレコードは、関連付けられたVPC内のリソースからのみ解決できます。 インターネット上のDNSサーバーには一切公開されないため、セキュリティ面で安全です。 これは「会社の内線電話帳が社外の人には見えない」のと同じ原理です。
1つのVPCに複数のプライベートホストゾーンを関連付けられますか?
+1つのVPCに複数のプライベートホストゾーンを関連付けることができます。 例えば
app.internal.com と db.internal.com の両方を
同じVPCに関連付けて、異なるサービス用のDNSゾーンを分けて管理できます。
異なるリージョンのVPCと関連付けできますか?
+プライベートホストゾーンは任意のリージョンのVPCと関連付けできます。 これにより、グローバルに展開されたアプリケーションでも一元的なプライベートDNS管理が実現できます。 ただし、VPCピアリングやTransit Gatewayなどのネットワーク接続は別途必要です。
DNSの変更はどのくらいで反映されますか?
+Route 53のプライベートホストゾーンは変更がほぼリアルタイムで反映されます。 ただし、クライアント側のDNSキャッシュがある場合は、TTL(Time To Live)の 時間が経過するまで古い情報が使われることがあります。 緊急の切り替えが必要な場合は、あらかじめTTLを短く設定しておくことをお勧めします。
VPCのDNS設定で何か必要ですか?
+enableDnsSupport: VPC内でDNS解決を有効化(デフォルトで有効)enableDnsHostnames: VPC内のインスタンスにDNSホスト名を割り当て(デフォルトでは無効の場合あり)
📝 まとめ
プライベートホストゾーンは、VPC内部のリソースに対して安全でシンプルな名前解決を提供する強力な機能です。
セキュリティ
VPC外部からはアクセス不可。内部DNSを安全に管理。
柔軟な接続
複数VPC、クロスリージョン、クロスアカウントに対応。
スプリットビュー
同じドメインで内外の通信を最適化。
コスト効率
月額$0.50〜の低コストで高機能なDNS管理。