AWS Certified CloudOps Engineer - Associate (SOA-C03) #11 Domain 4-2 ネットワーキング — Route 53·CloudFront·配信運用

読了 5分

#10 で VPC 内部の接続を押さえたなら、この記事はユーザーに届く経路である DNS (Route 53) とコンテンツ配信 (CloudFront) を扱います。#5 で可用性の観点から Route 53 のフェイルオーバーを見たなら、ここではレコード・ルーティング・キャッシュの運用の詳細を整理します。

Route 53: DNS 運用 #

レコード種類 #

レコード役割
A / AAAAドメイン → IPv4 / IPv6
CNAMEドメイン → 別のドメイン (ルートドメインには不可)
AliasAWS リソース (ELB·CloudFront·S3) → 無料、ルートドメイン可

核心となる落とし穴は CNAME はルートドメイン (zone apex、例: example.com) には使えない という点です。ルートドメインを ELB や CloudFront に接続するには Alias レコードを使う必要があります。Alias は Route 53 専用でクエリ費用がなく、ターゲットの IP 変更を自動で追跡します。「ルートドメインを ALB に接続」の答えが Alias です。

ルーティングポリシー #

#5 で見たポリシーを運用用途で改めて整理します。

ポリシー用途
Simple単一リソース
Failover主・副の切り替え (ヘルスチェックベース)
Weighted加重分散 (段階的デプロイ·カナリア)
Latency最も速いリージョンへ
Geolocationユーザー位置別に異なる応答 (規制·ローカライズ)
Geoproximity位置 + バイアスでトラフィックを移動
Multivalue複数の正常な IP を返す

運用シナリオのマッピングが試験ポイントです。段階的デプロイ·A/B は Weighted、地域規制·コンテンツのローカライズ は Geolocation、最低遅延 は Latency です。

ヘルスチェック #

Route 53 のヘルスチェックはエンドポイントを定期的に点検し、異常なら DNS 応答から除外 します。Failover の前提であり、他のヘルスチェック結果を束ねる 計算型 (calculated) ヘルスチェック もあります。DNS キャッシュ (TTL) のため切り替えは即座ではないので、速い切り替えが必要なら TTL を下げます

CloudFront: コンテンツ配信 (CDN) #

CloudFront は世界中のエッジロケーションにコンテンツをキャッシュし、遅延を減らしオリジンの負荷を軽減 します。

概念説明
Origin原本。S3、ALB、任意の HTTP サーバー
Behaviorパスパターン別のキャッシュ·転送ルール
Cache Policy何をキャッシュキーにするか (ヘッダー·クエリ·クッキー)
TTLキャッシュ保持時間

キャッシュ運用ポイント #

  • 静的コンテンツ (画像·JS·CSS) は長くキャッシュ、動的コンテンツ は短く、またはキャッシュしない
  • デプロイ後に古いコンテンツが残るなら 無効化 (invalidation) で強制更新。ただし無効化の乱発は費用がかかるので バージョン付きファイル名 (例: app.v2.js) がより推奨されます
  • オリジンの負荷を減らす目的なら キャッシュヒット率 (hit ratio) を上げるポリシー設定

「デプロイしたのにユーザーに古いファイルが見える」の答えは無効化またはバージョン付きファイル名、「オリジンの負荷が高い」はキャッシュポリシーでヒット率を上げることです。

S3 オリジンのセキュリティ: OAC #

S3 をオリジンとして使うとき、ユーザーが S3 URL で 直接アクセスするのを防ぎ CloudFront のみを経由させる には OAC (Origin Access Control) を使います (過去の OAI の後継)。S3 バケットは非公開にして CloudFront にのみ読み取りを許可します。「S3 コンテンツを CloudFront のみでアクセスさせろ」の答えが OAC です。

ACM: TLS 証明書 #

HTTPS のための証明書を 無料で発行·自動更新 します。運用ポイントが 2 つ定番です。

  • CloudFront に付ける証明書は必ず us-east-1 (バージニア北部) で発行 する必要があります。他のリージョンの証明書は CloudFront に付けられません。
  • ALB に付ける証明書は ALB と同じリージョン で発行します。
  • ACM 発行の証明書は 自動更新 されますが、DNS 検証レコードが維持される必要があります。

「CloudFront に ACM 証明書が付かない」の答えは、ほぼ常に リージョンが us-east-1 でないため です。

配信トラブルシューティング #

症状点検
古いコンテンツが見える無効化·キャッシュ TTL·バージョン付きファイル名
HTTPS が動かないACM リージョン (CloudFront は us-east-1)、証明書ドメインの一致
S3 への直接アクセスが開いているOAC + バケット非公開
特定地域だけ遅いエッジ·ルーティングポリシー (Latency)
フェイルオーバーが遅いDNS TTL を下げる

試験での出題パターン #

  • ルートドメインを ELB·CloudFront に接続 → Alias レコード
  • 段階的デプロイ·カナリア → Weighted ルーティング
  • 地域規制·ローカライズ → Geolocation ルーティング
  • デプロイ後に古いファイルが見える → 無効化 / バージョン付きファイル名
  • S3 を CloudFront のみでアクセス → OAC + バケット非公開
  • CloudFront の HTTPS 証明書 → ACM を us-east-1 で発行
  • 速い DNS フェイルオーバー → TTL を下げる + ヘルスチェック

よくある落とし穴 #

1) ルートドメインに CNAME を使う #

zone apex には CNAME が使えません。Alias が正解です。

2) CloudFront 証明書を別のリージョンで発行 #

CloudFront 用 ACM は 必ず us-east-1 です。最も頻繁に出る落とし穴です。

3) 無効化を常時デプロイ手段として使う #

無効化は費用がかかり、即座でもありません。バージョン付きファイル名 がより推奨されます。

4) S3 静的ホスティングと CloudFront OAC の混同 #

OAC で非公開 S3 を使う場合、S3 静的ウェブサイトホスティングのエンドポイントではなく REST エンドポイント をオリジンとして使います。

まとめ #

この記事で押さえたこと:

  • Route 53 Alias でルートドメインを AWS リソースに接続 (CNAME は apex 不可、無料)
  • ルーティングポリシー: Weighted (段階的)·Geolocation (規制·ローカライズ)·Latency (最低遅延)·Failover (ヘルスチェック)
  • CloudFront で遅延·オリジン負荷を低減。古いコンテンツは 無効化/バージョン付きファイル名、ヒット率でオリジンを保護
  • OAC で S3 を CloudFront 専用アクセスに。バケットは非公開
  • ACM は CloudFront 用が us-east-1、ALB 用は同じリージョン。自動更新

次: Domain 5-1 IAM と Organizations #

ネットワーキングドメインを終えました。最後のドメインは セキュリティとコンプライアンス です。

#12 Domain 5-1 セキュリティ: IAM·Organizations·マルチアカウント運用 では、IAM 権限運用、認証情報レポートと Access Analyzer、MFA の強制、AWS Organizations と SCP、そしてマルチアカウントガバナンスまで運用の観点で整理します。

X