Route 53・CloudFront
AWSのDNSサービスであるRoute 53と、CDNサービスであるCloudFrontを理解し、IDサービスのドメイン管理・コンテンツ配信・HTTPS化を学びます。
所要時間
約40分
学べること
- DNSの基礎と名前解決の仕組み
- Route 53のホストゾーンとレコードタイプ
- ルーティングポリシーの使い分け
- ヘルスチェックとDNSフェイルオーバー
- CloudFrontによるCDN配信の仕組み
- ACMによるSSL/TLS証明書の管理
- IDサービスにおけるDNS・CDN設計
前提知識
- ネットワーキング基礎の知識
- AWS基礎の知識
- ロードバランシングの基本概念
目次
- DNS基礎の復習
- Route 53概要
- ルーティングポリシー
- ヘルスチェックとDNSフェイルオーバー
- Route 53 + ALB の構成パターン
- CloudFront概要
- CloudFrontディストリビューション
- CloudFront + S3 / ALB のオリジン構成
- ACM（AWS Certificate Manager）
- IDサービスでの活用
DNS基礎の復習
名前解決の流れ
ブラウザがドメイン名をIPアドレスに変換するまでの過程を確認します。
ユーザーが https://auth.example.com にアクセス
┌──────────┐ 1. auth.example.com は？ ┌──────────────────┐
│ │ ─────────────────────────────→ │ リゾルバ │
│ ブラウザ │ │ (キャッシュDNS) │
│ │ ←───────────────────────────── │ │
└──────────┘ 8. 203.0.113.10 です └───────┬──────────┘
│
2. ルートDNSに問い合わせ │
┌──────────────────────────────────────┘
│
▼
┌──────────────┐
│ ルートDNS │ 3. .com のDNSは ns1.tld.com です
│ サーバー │─────────────────────────────┐
└──────────────┘ │
▼
┌──────────────┐
5. example.com のDNSは │ TLD DNS │
ns-xxx.awsdns.com です ←────────── │ (.com担当) │
│ └──────────────┘
▼
┌──────────────────┐
│ 権威DNS │ 7. auth.example.com は
│ (Route 53) │ 203.0.113.10 です
│ ns-xxx.awsdns.com│
└──────────────────┘
DNSの主要概念
| 用語 | 説明 |
|---|---|
| ドメイン名 | 人が読める名前（例: auth.example.com） |
| ゾーン | ドメインの管理単位 |
| レコード | ドメイン名とIPアドレス等の対応関係 |
| TTL | キャッシュの有効期間（秒） |
| 権威DNSサーバー | そのゾーンの正式な回答を持つサーバー |
Route 53概要
Route 53は、AWSが提供するスケーラブルな権威DNSサービスです。名前の由来はDNSが使用するポート番号53です。
ホストゾーン
ホストゾーンは、ドメインのDNSレコードを管理するコンテナです。
┌─────────────────── ──────────────────────────────────────────┐
│ Route 53 ホストゾーン │
├───────────────────────────┬─────────────────────────────────┤
│ パブリックホストゾーン │ プライベートホストゾーン │
│ │ │
│ インターネットからの │ VPC内部からのDNS │
│ DNS問い合わせに応答 │ 問い合わせに応答 │
│ │ │
│ 例: │ 例: │
│ auth.example.com │ db.internal.example.com │
│ → ALBのIPアドレス │ → RDSのプライベートIP │
│ │ │
│ api.example.com │ cache.internal.example.com │
│ → CloudFrontドメイン │ → ElastiCacheエンドポイント │
│ │ │
│ ┌───────┐ │ ┌─────┐ │
│ │インター│ 問い合わせ │ │ VPC │ 問い合わせ │
│ │ネット │───→ │ │内部 │───→ │
│ └───────┘ │ └─────┘ │
└───────────────────────────┴─────────────────────────────────┘
レコードタイプ
| レコードタイプ | 用途 | 例 |
|---|---|---|
| A | ドメイン → IPv4アドレス | auth.example.com → 203.0.113.10 |
| AAAA | ドメイン → IPv6アドレス | auth.example.com → 2001:db8::1 |
| CNAME | ドメイン → 別のドメイン名 | www.example.com → example.com |
| ALIAS | ドメイン → AWSリソース | example.com → d111.cloudfront.net |
| MX | メールサーバー指定 | example.com → mail.example.com |
| TXT | テキスト情報 | ドメイン所有権の検証等 |
| NS | ネームサーバー指定 | ゾーンの委任先 |
| SOA | ゾーンの管理情報 | シリアル番号、TTL等 |
ALIASレコードとCNAMEの違い
CNAMEレコード:
・Zone Apexには使用不可（example.com に CNAME は設定できない）
・DNS問い合わせが2回必要（CNAME解決 → A解決）
・Route 53の課金対象
ALIASレコード（Route 53独自）:
・Zone Apexにも使用可能（example.com → ALB が設定可能）
・Route 53が内部でIPアドレスを直接返す
・AWSリソース宛は無料
・対象: ALB、CloudFront、S3、API Gateway 等
ルーティングポリシー
Route 53は、DNSクエリに対する応答方法を制御する複数のルーティングポリシーを提供します。
ポリシー比較表
| ポリシー | 用途 | ユースケース |
|---|---|---|
| シンプル | 単一リソースへのルーティング | 開発環境、単一サーバー |
| 加重（Weighted） | トラフィックの割合制御 | カナリアデプロイ、A/Bテスト |
| レイテンシー | 最低レイテンシーのリージョンへ | マルチリージョン構成 |
| フェイルオーバー | プライマリ/セカンダリ切り替え | DR構成、高可用性 |
| 地理的位置 | クライアントの所在地ベース | リージョン別コンテンツ |
| 地理的近接性 | 最も近いリソースへ | トラフィックの地理的分散 |
| 複数値回答 | 複数IPをランダムに返す | 簡易的な負荷分散 |
ルーティングポリシーの動作
シンプルルーティング:
auth.example.com → 1つのALB
加重ルーティング（カナリアデプロイ）:
auth.example.com ──┬── 90% → ALB（現行バージョン）
└── 10% → ALB（新バージョン）
レイテンシーベースルーティング:
auth.example.com ──┬── 東京のユーザー → ap-northeast-1 の ALB
├── 米国のユーザー → us-east-1 の ALB
└── 欧州のユーザー → eu-west-1 の ALB
フェイルオーバールーティング:
auth.example.com ──┬── Primary → ap-northeast-1 の ALB（正常時）
└── Secondary → us-west-2 の ALB（障害時）
ヘルスチェックとDNSフェイルオーバー
ヘルスチェックの種類
┌─────────────────────────────────────────────────────────────┐
│ Route 53 ヘルスチェック │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. エンドポイントヘルスチェック │
│ ┌──────────┐ HTTP/HTTPS/TCP ┌──────────┐ │
│ │ Route 53 │ ──────────────────→ │ エンド │ │
│ │ ヘルス │ ステータス確認 │ ポイント │ │
│ │ チェッカー│ ←────────────────── │ (ALB等) │ │
│ └──────────┘ 200 OK/失敗 └──────────┘ │
│ │
│ 2. 計算済みヘルスチェック │
│ 複数のヘルスチェック結果を組み合わせて判定 │
│ 例: 3つ中2つ以上が正常 → 正常と判定 │
│ │
│ 3. CloudWatch アラーム連携 │
│ CloudWatch アラームの状態をヘルスチェックとして使用 │
│ │
└─────────────────────────────────────────────────────────────┘
フェイルオーバー構成例
Route 53
フェイルオーバー
│
┌──────────────┴──────────────┐
│ │
┌────┴────┐ ┌─────┴────┐
│ Primary │ │Secondary │
│ (東京) │ │ (大阪) │
└────┬────┘ └─────┬────┘
│ │
┌────┴────┐ ┌─────┴────┐
│ ALB │ ヘルスチェック │ ALB │
│ │←────失敗時──────→│ │
└────┬────┘ 自動切替 └─────┬────┘
│ │
┌────┴────┐ ┌─────┴────┐
│ ECS │ │ ECS │
│ Cluster│ │ Cluster │
└─────────┘ └──────────┘
正常時: auth.example.com → 東京リージョンのALB
障害時: auth.example.com → 大阪リージョンのALB（自動切替）
Route 53 + ALB の構成パターン
基本構成
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌───── ─────┐
│ ユーザー │ ──→ │ Route 53 │ ──→ │ ALB │ ──→ │ ECS │
│ │ │ (DNS) │ │ (HTTPS) │ │ (idp) │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
設定例:
ホストゾーン: example.com
ALIASレコード: auth.example.com → ALBのDNS名
マルチリージョン構成
Route 53
(レイテンシーベース)
│
┌──────────────┼──────────────┐
│ │ │
┌────┴────┐ ┌─────┴────┐ ┌─────┴────┐
│ 東京 │ │ 米国東部 │ │ 欧州 │
│ ALB │ │ ALB │ │ ALB │
└────┬────┘ └─────┬────┘ └─────┬────┘
│ │ │
┌────┴────┐ ┌─── ──┴────┐ ┌─────┴────┐
│ ECS │ │ ECS │ │ ECS │
│ + Aurora│ │ + Aurora │ │ + Aurora │
│ (東京) │ │ (米国) │ │ (欧州) │
└─────────┘ └──────────┘ └──────────┘
CloudFront概要
CDNの仕組み
CloudFrontは、AWSのCDN（Content Delivery Network）サービスです。世界中のエッジロケーションにコンテンツをキャッシュし、ユーザーに近い場所から配 信します。
┌─────────────────────────────────────────────────────────────┐
│ CloudFront CDN の仕組み │
├─────────────────────────────────────────────────────────────┤
│ │
│ CDNなし: │
│ ┌─────┐ ┌─────────┐ │
│ │東京 │──── 遠い ────────────→│ 米国の │ │
│ │ユーザ│ │ オリジン│ │
│ └─────┘ └─────────┘ │
│ レイテンシー: 200ms │
│ │
│ CDNあり: │
│ ┌─────┐ 近い ┌─────────┐ ┌─────────┐ │
│ │東京 │──────────→│ 東京 │── 初回 →│ 米国の │ │
│ │ユーザ│ │ エッジ │← キャッシュ│ オリジン│ │
│ └─────┘ └─────────┘ └─────────┘ │
│ レイテンシー: 10ms（キャッシュヒット時） │
│ │
└─────────────────────────────────────────────────────────────┘
エッジロケーション
CloudFront のグローバルネットワーク:
┌──────────────────────────────────────────┐
│ エッジロケーション │
│ │
│ 北米: 約50箇所 欧州: 約30箇所 │
│ アジア: 約30箇所 南米: 約5箇所 │
│ 中東/アフリカ: 数箇所 │
│ │
│ リージョナルエッジキャッシュ: │
│ エッジとオリジン間の中間キャッシュ層 │
│ │
│ エッジ → リージョナル → オリジン │
│ (L1) (L2) (S3/ALB) │
└──────────────────────────────────────────┘
オリジンの種類
| オリジン | 用途 | 例 |
|---|---|---|
| S3バケット | 静的コンテンツ配信 | ログインページのHTML/CSS/JS |
| ALB | 動的コンテンツ配信 | API応答 |
| カスタムオリジン | 任意のHTTPサーバー | オンプレミスサーバー |
| MediaStore | メディア配信 | ストリーミング |
CloudFrontディストリビューション
ビヘイビア（Behavior）
ビヘイビアは、URLパスパターンに基づいてリクエストの処理方法を定義します。
CloudFront ディストリビューション
│
├── ビヘイビア 1: /static/*
│ ├── オリジン: S3バケット
│ ├── キャッシュ: 有効（TTL: 86400秒）
│ └── HTTPS: リダイレクト
│
├── ビヘイビア 2: /api/*
│ ├── オリジン: ALB
│ ├── キャッシュ: 無効（全リクエスト転送）
│ └── HTTPS: 必須
│
└── デフォルトビヘイビア: *
├── オリジン: S3バケット
├── キャッシュ: 有効（TTL: 3600秒）
└── HTTPS: リダイレクト
キャッシュポリシー
┌─────────────────────────────────────────────────────────────┐
│ キャッシュポリシー設定 │
├─────────────────────────────────────────────────────────────┤
│ │
│ キャッシュキー: │
│ ┌───────────────────────────────────────────┐ │
│ │ URL + ヘッダー + クエリ文字列 + Cookie │ │
│ │ の組み合わせでキャッシュを識別 │ │
│ └───────────────────────────────────────────┘ │
│ │
│ マネージドポリシー（推奨）: │
│ ・CachingOptimized : 静的コンテンツ向け │
│ ・CachingDisabled : 動的コンテンツ（API）向け │
│ ・CachingOptimizedFor │
│ UncompressedObjects : 非圧縮コンテンツ向け │
│ │
│ カスタムポリシー: │
│ ・TTL設定（Min/Max/Default） │
│ ・含めるヘッダー/クエリ文字列/Cookieの指定 │
│ │
└─────────────────────────────────────────────────────────────┘
| 設定項目 | 静的コンテンツ | 動的コンテンツ（API） |
|---|---|---|
| キャッシュ | 有効 | 無効 |
| TTL | 長め（24時間等） | 0（キャッシュしない） |
| ヘッダー転送 | 最小限 | Authorization等を転送 |
| Cookie転送 | なし | 必要なCookieを転送 |
| 圧縮 | 有効（gzip/br） | 状況による |
CloudFront + S3 / ALB のオリジン構成
典型的な構成パターン
┌─────────────────────────────────────────────────────────────────┐
│ CloudFront + S3 + ALB 構成 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ │
│ ユーザー ─────────→│ CloudFront │ │
│ │ (CDN) │ │
│ └──────┬───────┘ │
│ │ │
│ ┌──────────────┼──────────────┐ │
│ │ │ │ │
│ /static/* /api/* デフォルト │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌──────────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ S3バケット │ │ ALB │ │ S3バケット │ │
│ │ (静的資産) │ │ │ │ (SPA) │ │
│ │ │ │ │ │ │ │
│ │ HTML/CSS/JS │ └────┬─────┘ │ index.html │ │
│ │ 画像/フォント│ │ │ │ │
│ └──────────────┘ ┌────┴─────┐ └──────────────┘ │
│ │ ECS │ │
│ │ (idp) │ │
│ └──────────┘ │
│ │
└────────────── ───────────────────────────────────────────────────┘
OAC（Origin Access Control）によるS3保護
S3バケットへの直接アクセスを防ぎ、CloudFront経由のみに制限:
ユーザー ──→ CloudFront ──→ S3バケット ← 許可（OAC経由）
ユーザー ──────────────────→ S3バケット ← 拒否（直接アクセス）
S3バケットポリシー:
{
"Statement": [{
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EXXXX"
}
}
}]
}
ACM（AWS Certificate Manager）
ACMは、SSL/TLS証明書の発行、管理、自動更新を行うサービスです。
証明書の発行と検証
┌────────────────────────────── ───────────────────────────────┐
│ ACM 証明書発行フロー │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. 証明書リクエスト │
│ ACMコンソール/CLIで auth.example.com の証明書を申請 │
│ │
│ 2. ドメイン検証（2つの方法） │
│ │
│ DNS検証（推奨）: │
│ ┌─────────┐ CNAMEレコード ┌──────────┐ │
│ │ ACM │ ──追加依頼─ ───→ │ Route 53 │ │
│ │ │ ←──検証完了───── │ │ │
│ └─────────┘ └──────────┘ │
│ ※ Route 53使用時は自動でレコード追加可能 │
│ │
│ メール検証: │
│ ドメイン管理者メールアドレスに確認メール送信 │
│ │
│ 3. 証明書の使用 │
│ ALB、CloudFront、API Gateway 等に関連付け │
│ │
│ 4. 自動更新 │
│ DNS検証の場合、有効期限前に自動更新 │
│ ※ 手動操作不要 │
│ │
└─────────────────────────────────────────────────────────────┘
ACMの利用パターン
| 利用先 | リージョン要件 | 用途 |
|---|---|---|
| ALB | ALBと同じリージョン | HTTPS終端 |
| CloudFront | us-east-1（バージニア北部）必須 | CDNのHTTPS |
| API Gateway | API GWと同じリージョン | カスタムドメイン |
重要: CloudFrontで使用するACM証明書は
必ず us-east-1 リージョンで発行する必要がある
┌───────────┐ ┌────────────────┐
│ CloudFront│ ──参照──→ │ ACM証明書 │
│ (グローバル)│ │ (us-east-1のみ) │
└───────────┘ └────────────────┘
┌───────────┐ ┌────────────────┐
│ ALB │ ──参照──→ │ ACM証明書 │
│ (東京) │ │ (ap-northeast-1)│
└───────────┘ └────────────────┘
IDサービスでの活用
idp-serverのDNS設計
┌─────────────────────────────────────────────────────────────────┐
│ IDサービス DNS・CDN 構成 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ Route 53 ホストゾーン: example.com │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ パブリックレコード │ │
│ │ │ │
│ │ auth.example.com → ALB（認証エンドポイント） │ │
│ │ login.example.com → CloudFront（ログインUI） │ │
│ │ api.example.com → ALB（管理API） │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ プライベートレコード（VPC内部） │ │
│ │ │ │
│ │ db.internal.example.com → RDS/Auroraエンドポイント│ │
│ │ cache.internal.example.com→ ElastiCacheエンドポイント│ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ ACM証明書: │
│ ・*.example.com（ワイルドカード証明書） │
│ ・ALB用: ap-northeast-1 で発行 │
│ ・CloudFront用: us-east-1 で発行 │
│ │
└─────────────────────────────────────────────────────────────────┘
IDサービスにおけるCloudFrontの活用
CloudFrontの活用ポイント:
1. ログインページ（静的コンテンツ）の高速配信
- HTML/CSS/JSをエッジキャッシュ
- 世界中のユーザーに低レイテンシーで配信
2. APIエンドポイントの保護
- WAFとの統合でDDoS対策
- レート制限の適用
3. HTTPS強制
- HTTP → HTTPS リダイレクト
- TLS 1.2以上の強制
注意点:
- OAuthトークンエンドポイント（/token）はキャッシュしない
- 認可エンドポイント（/authorize）は状態を持つためキャッシュ不可
- .well-known/openid-configuration は短いTTLでキャッシュ可能
まとめ
| サービス | 役割 | IDサービスでの用途 |
|---|---|---|
| Route 53 | DNS管理 | ドメイン管理、フェイルオーバー |
| CloudFront | CDN | 静的コンテンツ配信、WAF統合 |
| ACM | 証明書管理 | HTTPS化、自動更新 |
重要なポイント:
- Route 53のALIASレコードはAWSリソースへのルーティングに最適
- ルーティングポリシーとヘルスチェックの組み合わせで高可用性を実現
- CloudFrontでは静的/動的コンテンツで異なるキャッシュ戦略を適用
- ACM証明書はCloudFront用は必ずus-east-1で発行する
次のステップ
- API Gateway: スロットリング、使用量プラン、WAFとの多層防御を学ぶ
- セキュリティサービス: KMS、WAF、Shield等のセキュリティ対策を学ぶ