🔐 Amazon Route 53 プライベートホストゾーン

VPC内部専用のプライベートDNSで、安全でシンプルな名前解決を実現

💡 まず最初に結論!

🔒 プライベートホストゾーンとは?

VPC内部でのみ使用できるプライベートなDNS。インターネットからはアクセス不可で、VPC内のリソースだけが名前解決できる。

📍 いつ使う?

内部システム間の通信でIPアドレスではなくドメイン名を使いたいとき。セキュリティと運用性が大幅に向上!

🔗 複数VPCで共有可能

1つのプライベートホストゾーンを複数のVPCに関連付けて、共通の内部DNSとして利用可能。

🔀 スプリットビューDNS

同じドメイン名で内部と外部で異なるIPアドレスを返すことが可能。柔軟なDNS設計を実現。

📖 たとえ話で理解しよう!「会社の内線電話帳」

🏢 会社のオフィス

大きな会社には2種類の電話帳があります...

📞 外部公開の代表番号
会社のWebサイトに載っている電話番号。誰でも見れる。
🔐 社内専用の内線電話帳
社員だけが使える内線番号一覧。外部の人には見せない機密情報。
🏗️ オフィスビル
社員だけが入れる建物。内線電話は建物内でのみ使用可能。

☁️ AWSの世界

Route 53も同じ仕組みを提供します...

🌍 パブリックホストゾーン
インターネットに公開されるDNS。世界中の誰でもドメイン名を解決できる。
🔒 プライベートホストゾーン
VPC内部専用のDNS。関連付けられたVPC内からのみ名前解決可能。
🔲 VPC
AWS内の隔離されたネットワーク空間。プライベートホストゾーンはここでのみ有効。

💡 ポイント

「田中さんの内線番号は?」と社内で聞けば「1234」と教えてもらえますが、 社外の人が同じ質問をしても答えてもらえません。

プライベートホストゾーンも同様に、「db.internal.example.com」というドメイン名は VPC内のEC2インスタンスからは解決できますが、インターネットからは絶対に解決できません。 これがセキュリティの要です!

🎨 パブリック vs プライベート ホストゾーン

🌍 パブリックホストゾーン

🌐 インターネットユーザー 世界中のどこからでも
🔍 Route 53 パブリックDNS www.example.com → 203.0.113.10
🖥️ パブリックIPを持つリソース ALB / CloudFront / EC2

🔐 プライベートホストゾーン

🏠 VPC内のリソース EC2 / Lambda / ECS
🔒 Route 53 プライベートDNS db.internal.example.com → 10.0.1.50
💾 プライベートIPのリソース RDS / ElastiCache / 内部EC2

🔀 スプリットビューDNS(スプリットホライズンDNS)

同じドメイン名でも、アクセス元によって異なるIPアドレスを返す魔法の仕組み!

🌍
パブリックホストゾーン
example.com
A app.example.com → 203.0.113.10
CNAME www → app.example.com

← インターネットからのアクセスはパブリックIPへ

🎯 同じドメイン名
example.com
🔐
プライベートホストゾーン
example.com
A app.example.com → 10.0.1.100
A db.example.com → 10.0.2.50

← 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)の社員だけが、内線電話帳を使えます!

🔧 技術的な動作イメージ

🔐 プライベートホストゾーン: internal.myapp.com
db.internal.myapp.com → 10.0.1.50
api.internal.myapp.com → 10.0.2.100
⬇️ 関連付け ⬇️
🏭
VPC-A(関連付け済)
10.0.0.0/16
✅ EC2から
db.internal... が
解決できる!
🧪
VPC-B(関連付け済)
10.1.0.0/16
✅ EC2から
db.internal... が
解決できる!
💻
VPC-C(未関連付け)
10.2.0.0/16
❌ EC2から
db.internal... は
解決不可!

💡 なぜ関連付けが必要?

🔒

セキュリティ

必要なVPCだけにDNS情報を公開。不要なネットワークからのアクセスを防止。

🧪

環境分離

開発・ステージング・本番環境で異なるDNS設定を使い分け可能。

🔄

柔軟性

後から関連付けの追加・削除が可能。運用中の変更も簡単。

📊 複数VPCでの共有イメージ

🏭
Production VPC
10.0.0.0/16
✅ 関連付け済み
🧪
Staging VPC
10.1.0.0/16
✅ 関連付け済み
💻
Development VPC
10.2.0.0/16
✅ 関連付け済み
🔐 プライベート
ホストゾーン
internal.myapp.com

📍 同一リージョン内

同じリージョン内のVPCであれば、簡単に関連付けが可能。コンソールから数クリックで完了。

🌍 クロスリージョン

異なるリージョンのVPCとも関連付け可能!グローバルなプライベートDNSを構築できる。

👥 クロスアカウント

別のAWSアカウントのVPCとも関連付け可能。マルチアカウント環境での一元管理に最適。

⚙️ 関連付けのCLIコマンド例

# VPCをプライベートホストゾーンに関連付け aws route53 associate-vpc-with-hosted-zone \ --hosted-zone-id Z1234567890ABC \ --vpc VPCRegion=ap-northeast-1,VPCId=vpc-aaaaaaaa # これでVPC内のEC2から「db.internal.myapp.com」が # 名前解決できるようになる!

🎯 一貫したDNS解決とFQDN

複数VPCで共通のドメイン名を使い、すべてのリソースに統一された命名規則でアクセス!

「一貫したDNS解決」と「FQDN」とは?

📛 FQDN(完全修飾ドメイン名)

Fully Qualified Domain Nameの略。
省略なしの完全なドメイン名のこと。

例: db.aws.example.com

🔄 一貫したDNS解決

どのVPCからでも同じドメイン名で同じリソースにアクセスできること。

VPC-AでもVPC-Bでも同じ結果

📖 たとえ話:「会社のメールアドレス」

🏢 会社全体で共通のメールドメイン
社員名簿: @mycompany.com
👤
田中さん
tanaka@mycompany.com
→ 内線1234
👤
鈴木さん
suzuki@mycompany.com
→ 内線5678
👤
佐藤さん
sato@mycompany.com
→ 内線9012

💡 「tanaka@mycompany.com」と言えば、
どの部署(VPC)からでも同じ人(リソース)に繋がる!

🔧 技術的な動作イメージ

🔐 プライベートホストゾーン: aws.example.com
(共通のサフィックス = 会社のドメイン)
📋 DNSレコード一覧(各リソースのエントリ)
db.aws.example.com
10.0.1.50 (RDS)
api.aws.example.com
10.0.2.100 (APIサーバー)
cache.aws.example.com
10.0.3.25 (ElastiCache)
web.aws.example.com
10.0.4.10 (Webサーバー)
⬇️ 関連付け ⬇️
🏭
VPC-A(本番)
✅ db.aws.example.com
で接続可能!
🧪
VPC-B(開発)
✅ db.aws.example.com
で接続可能!
🔍
VPC-C(検証)
✅ db.aws.example.com
で接続可能!

🎯 どのVPCからでも「db.aws.example.com」で同じデータベース(10.0.1.50)にアクセス可能!

⚖️ IPアドレス直接指定 vs FQDN

IPアドレス直接指定

# 設定ファイル
database_host = "10.0.1.50"
api_host = "10.0.2.100"
cache_host = "10.0.3.25"
  • IPアドレスを覚えにくい
  • IPが変わったら全部修正が必要
  • どれがどのサーバーか分かりにくい

FQDN(ドメイン名)を使用

# 設定ファイル
database_host = "db.aws.example.com"
api_host = "api.aws.example.com"
cache_host = "cache.aws.example.com"
  • 分かりやすい名前!
  • 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)からでも同じ名前で同じ人(リソース)に繋がる

⚙️ 設定手順

🖥️ マネジメントコンソール 💻 AWS CLI
1

プライベートホストゾーンの作成

Route 53コンソールで「ホストゾーンの作成」を選択し、タイプを「プライベートホストゾーン」に設定。

# AWS CLIでの作成 aws route53 create-hosted-zone \ --name internal.myapp.com \ --vpc VPCRegion=ap-northeast-1,VPCId=vpc-xxxxxxxx \ --caller-reference $(date +%s) \ --hosted-zone-config PrivateZone=true
2

VPCとの関連付け

作成したホストゾーンに、名前解決を行いたいVPCを関連付けます。

# 追加のVPCを関連付け aws route53 associate-vpc-with-hosted-zone \ --hosted-zone-id Z1234567890ABC \ --vpc VPCRegion=ap-northeast-1,VPCId=vpc-yyyyyyyy
3

DNSレコードの作成

内部リソースを指すAレコードやCNAMEレコードを作成します。

# レコードセットの作成(JSON形式) aws route53 change-resource-record-sets \ --hosted-zone-id Z1234567890ABC \ --change-batch '{ "Changes": [{ "Action": "CREATE", "ResourceRecordSet": { "Name": "db.internal.myapp.com", "Type": "A", "TTL": 300, "ResourceRecords": [{"Value": "10.0.1.50"}] } }] }'
4

DNS解決の確認

VPC内のEC2インスタンスから名前解決ができることを確認します。

# EC2インスタンス内でテスト nslookup db.internal.myapp.com # または dig コマンドで詳細確認 dig db.internal.myapp.com # 期待する結果 ;; ANSWER SECTION: db.internal.myapp.com. 300 IN A 10.0.1.50

✨ ベストプラクティス

✅ 推奨事項

  • 内部用ドメインには .internal.local を使用
  • 適切なTTL値を設定(推奨: 60-300秒)
  • ヘルスチェックを併用してフェイルオーバーを実装
  • CloudWatchでDNSクエリをモニタリング
  • 複数VPCで共有する場合はRAM(Resource Access Manager)を活用
  • DNSSEC署名の有効化を検討

❌ 避けるべきこと

  • 実在するパブリックドメインと同じ名前は使わない
  • TTLを極端に短く設定しない(DNSサーバー負荷増)
  • プライベートIPをパブリックホストゾーンに登録しない
  • VPCのDNS設定(enableDnsHostnames)を無効にしない
  • クロスアカウント関連付けで過度なアクセス許可を与えない

💰 料金体系

📋

ホストゾーン

$0.50/月
最初の25ホストゾーンまで
(26以降は$0.10/月)
🔍

DNSクエリ

$0.40/100万クエリ
プライベートホストゾーンへの
DNSクエリ課金
🔗

VPC関連付け

無料
VPCの関連付け自体には
追加料金なし

※ 料金は東京リージョン(ap-northeast-1)の参考価格です。最新の料金はAWS公式ページをご確認ください。

❓ よくある質問(FAQ)

🤔

プライベートホストゾーンはインターネットから見えますか?

+
いいえ、絶対に見えません。

プライベートホストゾーンのDNSレコードは、関連付けられたVPC内のリソースからのみ解決できます。 インターネット上のDNSサーバーには一切公開されないため、セキュリティ面で安全です。 これは「会社の内線電話帳が社外の人には見えない」のと同じ原理です。
🔗

1つのVPCに複数のプライベートホストゾーンを関連付けられますか?

+
はい、可能です!

1つのVPCに複数のプライベートホストゾーンを関連付けることができます。 例えば app.internal.comdb.internal.com の両方を 同じVPCに関連付けて、異なるサービス用のDNSゾーンを分けて管理できます。
🌍

異なるリージョンのVPCと関連付けできますか?

+
はい、クロスリージョンの関連付けが可能です!

プライベートホストゾーンは任意のリージョンのVPCと関連付けできます。 これにより、グローバルに展開されたアプリケーションでも一元的なプライベートDNS管理が実現できます。 ただし、VPCピアリングやTransit Gatewayなどのネットワーク接続は別途必要です。

DNSの変更はどのくらいで反映されますか?

+
通常は数秒〜1分以内に反映されます。

Route 53のプライベートホストゾーンは変更がほぼリアルタイムで反映されます。 ただし、クライアント側のDNSキャッシュがある場合は、TTL(Time To Live)の 時間が経過するまで古い情報が使われることがあります。 緊急の切り替えが必要な場合は、あらかじめTTLを短く設定しておくことをお勧めします。
🔧

VPCのDNS設定で何か必要ですか?

+
はい、2つの設定を有効にする必要があります。

  • enableDnsSupport: VPC内でDNS解決を有効化(デフォルトで有効)
  • enableDnsHostnames: VPC内のインスタンスにDNSホスト名を割り当て(デフォルトでは無効の場合あり)
これらが無効だとプライベートホストゾーンが機能しないので、必ず確認してください。

📝 まとめ

プライベートホストゾーンは、VPC内部のリソースに対して安全でシンプルな名前解決を提供する強力な機能です。

🔒

セキュリティ

VPC外部からはアクセス不可。内部DNSを安全に管理。

🔗

柔軟な接続

複数VPC、クロスリージョン、クロスアカウントに対応。

🔀

スプリットビュー

同じドメインで内外の通信を最適化。

💰

コスト効率

月額$0.50〜の低コストで高機能なDNS管理。

Created by SSuzuki1063

AWS SAP Learning Resources