前回の記事では、Astroで作った dist/ をS3に置いて、CloudFrontから静的サイトとして配信する流れをまとめました。 まだそこまで進んでいない場合は、先にAstroブログをAWSで公開してみる！S3とCloudFrontで静的サイトを配信する流れから読むとつながりやすいです。

その前段の「Astroで記事を書いてbuildする流れ」は、Astroでブログを作ってみる！記事を書くまでの流れを初心者向けに解説にまとめています。

今回は、S3とCloudFrontで表示できるようになったブログに、独自ドメインとHTTPSを設定する回です。 CloudFrontのURLではなく、https://example.com のような自分のドメインで開けるようにしていきます。

このブログ「あれこれびより」では、正規URLを https://arekore-biyori.com にしています。 ただし、この記事ではAWSアカウント固有の値は出さず、説明には example.com などのダミー値を使います。

今回やること

今回のゴールは、前回作ったCloudFront配信のサイトを、独自ドメイン + HTTPSで開けるようにすることです。

ざっくり言うと、こういう流れです。

ユーザー
  ↓
https://example.com
  ↓
Route 53
  ↓
CloudFront
  ↓
S3

そしてHTTPSに必要な証明書は、ACMで用意してCloudFrontに設定します。

ACM
  ↓ HTTPSに必要な証明書
CloudFront

ここで初心者が混乱しやすいのが、「Route 53とACMとCloudFrontって、それぞれ何してるの？」というところです。 私も最初は、全部が独自ドメイン担当に見えていましたw

でも役割を分けると、だいぶ見通しがよくなります。

  • Route 53: ドメインをどこへ向けるか案内する
  • ACM: HTTPSに使う証明書を用意する
  • CloudFront: 実際にサイトを配信する入口になる
  • S3: HTMLやCSSなどの静的ファイルを保存する

今回は、この役割分担を押さえながら進めます。

前回までの構成

前回までで、構成はだいたいここまで来ています。

Astro
  ↓ npm run build
dist/
  ↓
Amazon S3
  ↓
Amazon CloudFront
  ↓
CloudFrontのURLで表示

CloudFrontを作ると、CloudFront側のドメイン名が用意されます。 たとえば、説明用に書くなら dxxxxxxxxxxxxx.cloudfront.net のようなURLですね。

このURLでもサイトは表示できます。 ただ、ブログとして公開するなら、やっぱり自分のドメインで見せたいところです。 「あれこれびより」なら arekore-biyori.com のような形っすね。

独自ドメインにすると何が変わる？

独自ドメインにすると、読者がアクセスするURLが分かりやすくなります。

変更前: https://dxxxxxxxxxxxxx.cloudfront.net
変更後: https://example.com

CloudFrontのURLは、配信用の機械的なURLという感じです。 一方で独自ドメインは、ブログ名やサイト名に合わせられます。

独自ドメインにするメリットは、こんな感じです。

  • URLを覚えやすい
  • サイトとしての見た目が自然になる
  • SNSや検索結果で出したときに分かりやすい
  • 将来サービス構成を変えても、URLを維持しやすい

ただし、ドメインを使うにはDNS設定が必要です。 そこで出てくるのがRoute 53です。

Route 53って何？

Route 53は、AWSのDNSサービスです。

DNSは、ドメイン名を実際の接続先へ案内する仕組みです。 かなりざっくり言うと、「example.com にアクセスしたら、どこへ行けばいいの？」を教える役割ですね。

example.com を開きたい
  ↓
DNSに問い合わせる
  ↓
CloudFrontへ行けばいいよ、と案内される

このブログでは、Route 53を使って独自ドメインをCloudFrontへ向ける構成にしています。

Route 53はドメイン登録にも使えますが、この記事では主に「DNSとしてCloudFrontへ向ける」部分を見ます。 ドメインをどこで取得するかは人によって違うので、そこは自分の管理方法に合わせればOKです。

Hosted Zoneって何？

Route 53でDNSを管理するときに出てくるのがHosted Zoneです。

Hosted Zoneは、そのドメインのDNSレコードをまとめて管理する場所です。 たとえば example.com のHosted Zoneには、example.com や www.example.com をどこへ向けるか、という情報を置きます。

Hosted Zone: example.com
  ├─ example.com → CloudFront
  ├─ www.example.com → CloudFront
  └─ 検証用CNAME → ACM

最初は「Hosted Zoneって何か別のサーバー？」と思うかもしれませんが、そうではありません。 DNSの設定表みたいなもの、と考えると分かりやすいです。

ACMって何？

ACMはAWS Certificate Managerの略です。 HTTPSで使うTLS証明書（一般にSSL証明書と呼ばれることもあります）を管理するAWSサービスです。

HTTPSでサイトを表示すると、ブラウザのアドレスバーに鍵マークが出ますよね。 あれは、通信が暗号化されていて、証明書によってドメインの正当性を確認できる状態です。

CloudFrontで https://example.com を使うには、CloudFrontに「このドメイン用の証明書」を設定する必要があります。 その証明書をACMで用意します。

なぜHTTPSに証明書が必要なの？

HTTPSでは、ブラウザとサイトの間の通信を暗号化します。 ただ暗号化するだけではなく、「このサイトは本当に example.com として扱ってよいのか」も確認します。

そこで証明書が必要になります。

証明書なしで独自ドメインのHTTPSを設定しようとすると、ブラウザ側で警告が出たり、CloudFront側で設定できなかったりします。 なので、独自ドメイン + HTTPSでは、ドメインと証明書はセットで考えるとよいです。

ACMで証明書を発行する

ACMでは、証明書に含めたいドメイン名を指定して証明書をリクエストします。

たとえばルートドメインだけ使うなら、こうです。

example.com

www も使いたいなら、次のように追加します。

example.com
www.example.com

将来的にサブドメインをいろいろ使いたい場合は、ワイルドカード証明書を検討することもあります。

example.com
*.example.com

ここで大事なのは、*.example.com は blog.example.com や www.example.com のような1階層のサブドメインをカバーするものだという点です。 AWSのCloudFrontドキュメントでも、*.example.com は example.com そのものや、marketing.product.example.com のような別階層はカバーしない例が示されています。 参考: Use custom URLs by adding alternate domain names (CNAMEs)

このブログでは、arekore-biyori.com と *.arekore-biyori.com を対象にしたACM証明書を使っています。 ただ、ルートドメインだけで運用するなら、必ずワイルドカードを入れなければいけないわけではありません。

ACMのDNS検証をする

ACMで証明書をリクエストすると、「本当にそのドメインを管理しているの？」を確認する必要があります。 この確認方法の1つがDNS検証です。

DNS検証では、ACMが検証用のCNAMEレコードを出してくれます。 それをRoute 53のHosted Zoneへ追加します。 参考: AWS Certificate Manager DNS validation

説明用のダミー値で書くと、こんな感じです。

Name:  _example.example.com
Type:  CNAME
Value: _validation.acm-validations.aws

実際にはもっと長いランダムな値になります。 ここはAWSアカウントや証明書に紐づく値なので、記事やスクリーンショットでそのまま公開しないほうがよいです。

Route 53でDNSを管理している場合は、ACM側からRoute 53へ検証用レコードを作る流れを使えることがあります。 細かい画面位置は変わる可能性があるので、「ACMの検証用CNAMEをRoute 53に追加する」と覚えるくらいで大丈夫です。

なぜCloudFrontの証明書はバージニア北部なの？

ここ、けっこう混乱ポイントです。

東京リージョン ap-northeast-1 でS3やほかのAWSリソースを触っていると、「証明書も東京で作ればいいのでは？」と思いますよね。 私も最初はそう思いました。

ただし、CloudFrontでACM証明書を使う場合は、AWS公式ドキュメント上、ACM証明書を us-east-1、つまり米国東部・バージニア北部リージョンでリクエストする必要があります。 参考: Configure alternate domain names and HTTPS

これはCloudFrontの仕様として覚えておくのがよいです。 細かい内部事情を無理に推測するより、初心者のうちは次のように整理すると安全です。

東京リージョン ap-northeast-1
  → S3やLambdaなど、ブログ周辺のリソースで使うことがある

バージニア北部 us-east-1
  → CloudFrontで使うACM証明書を作る場所

「なんで証明書だけアメリカなの？w」となりますが、CloudFront用証明書は us-east-1 と覚えておけば、かなり迷いにくくなります。

CloudFrontに独自ドメインを設定する

証明書が発行できたら、CloudFront側に独自ドメインを設定します。

CloudFrontでは、独自ドメインのことをAlternate domain name、またはCNAMEと呼びます。 ここに example.com を追加します。

このとき、CloudFrontにはそのドメインをカバーする有効なTLS証明書を設定する必要があります。 つまり、次の2つがセットです。

Alternate domain name: example.com
ACM certificate: example.com を含む証明書

CloudFrontは「このDistributionで example.com を受けていいのか」を、証明書も使って確認します。 なので、ドメインだけ追加して証明書が合っていないと、うまく設定できません。

今回は既存のCloudFront Distributionへ、独自ドメインとACM証明書を追加するイメージです。 前回作ったS3 OriginやOACの考え方は、そのまま使います。

Route 53からCloudFrontへ接続する

CloudFront側で example.com を受けられるようにしたら、次はRoute 53からCloudFrontへ向けます。

Route 53のHosted Zoneに、CloudFrontへ向けるレコードを作ります。 このブログでは、ルートドメインに対してA AliasとAAAA AliasをCloudFrontへ向ける構成にしています。

example.com A Alias    → CloudFront
example.com AAAA Alias → CloudFront

Route 53のAliasレコードは、AWSリソースへ向けるためのRoute 53独自の仕組みです。 AWS公式ドキュメントでも、AliasレコードはCloudFront DistributionなどのAWSリソースへトラフィックをルーティングでき、CNAMEと違ってzone apex、つまり example.com のようなルートドメインにも作れると説明されています。 参考: Choosing between alias and non-alias records

ルートドメインでブログを公開したい場合、このAliasがかなり便利です。 通常のCNAMEは example.com のようなzone apexには作れないため、Route 53を使うならAliasでCloudFrontへ向けるのが分かりやすいです。

AレコードとAAAAレコードって何？

AレコードはIPv4用のレコードです。 AAAAレコードはIPv6用のレコードです。

A    → IPv4
AAAA → IPv6

CloudFront DistributionでIPv6を有効にしている場合は、IPv4向けのA Aliasに加えて、IPv6向けのAAAA Aliasも作成します。 AWSのRoute 53ドキュメントでも、CloudFront DistributionでIPv6が有効な場合はAレコードとAAAAレコードの2つを作る流れになっています。

「あれこれびより」でもCloudFrontのIPv6を有効にしているので、A Alias / AAAA Aliasの両方をCloudFrontへ向けています。

HTTPSでブログを開いてみる

設定できたら、ブラウザで独自ドメインを開いて確認します。

https://example.com

確認するポイントはこのあたりです。

  • サイトが表示される
  • URLが独自ドメインになっている
  • HTTPSで開ける
  • 証明書エラーが出ない
  • CloudFront経由で配信されている

このブログの場合は、https://arekore-biyori.com が正規URLです。 www はcanonicalにはしていません。

DNSを設定したのにすぐ反映されない？

DNS設定を変えても、すぐにすべての環境で反映されるとは限りません。

Route 53側の設定、DNSのTTL、ブラウザやネットワーク側のキャッシュなどによって、少し時間がかかる場合があります。

なので、設定直後に開けなくても、すぐ「全部壊れた！」と決めつけなくて大丈夫です。 ただし、時間を置いても変わらない場合は、次のような点を見直します。

  • Route 53のHosted Zoneが正しいか
  • ドメインのネームサーバーがRoute 53を向いているか
  • ACM証明書が発行済みになっているか
  • CloudFrontにAlternate domain nameが設定されているか
  • CloudFrontに正しいACM証明書が設定されているか
  • A Alias / AAAA AliasがCloudFrontへ向いているか

ここは慌てると沼りやすいので、1つずつ見ていくのがよいです。

この時点で完成する構成

ここまでできると、構成はこんな感じになります。

読者
  ↓
https://example.com
  ↓
Route 53
  ↓
CloudFront + ACM証明書
  ↓
S3

S3は静的ファイルの置き場所。 CloudFrontは公開用の入口。 Route 53は独自ドメインをCloudFrontへ向けるDNS。 ACMはHTTPSに必要な証明書。

役割を分けると、だいぶ理解しやすくなりますね。

「あれこれびより」も、この考え方で https://arekore-biyori.com を正規URLとして使っています。

料金はどのくらい？

料金については、固定金額で断定しないほうがよいです。 AWSの料金は変更されることがありますし、ドメイン登録料金は .com や .jp などTLDによっても変わります。

ざっくり、次のようなところで料金が関係します。

  • ドメイン登録・更新料金
  • Route 53のHosted Zone
  • DNSクエリ
  • CloudFrontのデータ転送やリクエスト
  • S3の保存容量やリクエスト

今回のようにCloudFrontで使う通常のACMパブリック証明書（エクスポートしない証明書）は、ACM統合サービスで使う範囲では証明書自体の追加料金はかかりません。 ただし、ACMにはエクスポート可能なパブリック証明書やACME証明書など別料金の機能もありますし、ブログ全体ではRoute 53、ドメイン登録、CloudFront、S3などの料金が別に関係します。

実際に作る前に、AWS公式の料金ページで今の料金を確認しておくのがおすすめです。

まとめ

今回は、S3とCloudFrontで公開したAstroブログに、独自ドメインとHTTPSを設定する流れを整理しました。

ポイントはこのあたりです。

  • 独自ドメインを使うとURLが分かりやすくなる
  • Route 53はDNSとしてドメインをCloudFrontへ向ける
  • Hosted ZoneはDNSレコードを管理する場所
  • ACMはHTTPSに使う証明書を管理する
  • CloudFront用のACM証明書は us-east-1 で作る
  • CloudFrontにはAlternate domain nameとACM証明書を設定する
  • Route 53ではA Alias / AAAA AliasでCloudFrontへ向ける
  • DNS変更は反映に少し時間がかかる場合がある

これで、CloudFrontのURLではなく、https://example.com のような独自ドメインからAstroブログを開けるようになります。

ここまでできると、かなり「自分のブログを公開している」感が出てきますね。

ただ、記事を更新するたびにローカルで npm run build して、手動でS3へアップロードするのはちょっと面倒です。 次は、GitHubにpushした内容をGitHub Actionsでビルドし、AWSへ自動デプロイする流れもまとめていきたいです。