えぇーー！？繋がってるーーー！！！ ― ACMとCloudFrontとRoute 53で独自ドメインをHTTPSにするまで

https://bun-bou.com で、このブログが表示されるようになりました。鍵マークも付いています。

前回はドメインを買っただけで終わっていたので、今回はそれを実際に使えるようにした回です。

先に白状しておくと、半分くらい分からないままポチポチしていたら繋がりました。 なので前半は「やったこと」、後半は「あれは何だったのか」を調べ直した記録になります。

やることは3つだけだった

身構えていたわりに、作業は3つでした。

ACM で証明書を作る
CloudFront に独自ドメインと証明書を設定する
Route 53 で、ドメインをCloudFrontに向ける

順番も、この通りでないと進めません。証明書が無いとCloudFrontの設定で選べないし、CloudFrontの設定が無いとRoute 53から向ける先がない。

1. ACMで証明書を作る（分からないままポチポチ）

ACM（AWS Certificate Manager）を開いて、証明書をリクエストします。

パブリック証明書を選ぶ
ドメイン名に bun-bou.com を入力
検証方法は DNS検証 を選ぶ
リクエスト

これだけです。これだけなので、逆に不安になりました。

証明書というからには、何かファイルをダウンロードして、どこかに置くのだと思っていたんです。でも何も落ちてこない。画面には「保留中の検証」と出ているだけで、発行されたのかどうかも分かりませんでした。

ACMは us-east-1（バージニア北部）で作る

CloudFrontで使う証明書は、このリージョンで発行したものしか選べません。東京リージョンで作ると、あとでCloudFrontの画面に候補として出てこなくて悩むことになります。前回の記事から気にしていた点だったので、ここは間違えずに済みました。

あのポチポチは何だったのか

繋がってから調べ直して、ようやく腑に落ちました。

証明書というのは、「このドメインは確かにあなたのものです」と第三者が保証するもの、らしいです。であれば、発行する側（ACM）は「本当にこの人が持ち主か」を確かめないといけません。

その確認方法が、さっき選んだ DNS検証 でした。理屈はこうです。

そのドメインのDNSにレコードを置ける人は、そのドメインの持ち主に決まっている。

ACMのDNS検証。レコードを置けるか＝ドメインの持ち主か、という確認

ACMが「この名前で、この値のレコードを置いてください」と指定してきて、画面の**「Route 53でレコードを作成」ボタン**を押すと、それが自動で置かれます。ACMがそれを見つけた時点で、検証は完了。

つまり、よく分からずに押していたあのボタンが、持ち主であることの証明そのものでした。 何も落ちてこなかったのは、証明書がAWSの中に保管されて、CloudFrontから参照される形だからです。自分でファイルを触る場面がない。

補足

自分でサーバを立ててHTTPSにする場合は、証明書のファイルをサーバに置く作業が出てきます。ACMとCloudFrontの組み合わせだと、そこが丸ごと省かれるようです。楽な代わりに、何が起きているのか見えにくい。

2. CloudFrontに独自ドメインを設定

次はCloudFront側です。ディストリビューションの設定を開いて、

代替ドメイン名（CNAME） に bun-bou.com を追加
カスタムSSL証明書 の欄で、証明書を選ぶ

ここで「あれ？」となりました。証明書の欄を開いたら、さっき作ったものが、もう候補として出てきたんです。

発行されたかどうか分からないまま進んでいたので、拍子抜けしました。この時点で、1の作業はちゃんと終わっていたわけです。

ここが1の答え合わせになる

証明書がこの欄に出てくれば、発行まで終わっている証拠です。逆に出てこないなら、リージョンが us-east-1 でないか、検証がまだ終わっていないか、のどちらかを疑えばいい。心配なら、先にこの画面を開いてみるのが早いと思います。

3. Route 53でCloudFrontに向ける

最後にRoute 53です。ホストゾーンを開いて、レコードを作成します。

レコードタイプ：A
エイリアス をオンにする
「AWSサービスへのエイリアス」→ CloudFront
該当するディストリビューションを選ぶ

ここでも引っかかりました。IPアドレスを1文字も打っていない。

Aレコードは「名前とIPアドレスを結びつけるもの」と理解していたので、IPを聞かれないのが不思議でした。

これも後から調べて分かったのですが、CloudFrontは世界中に配信拠点があって、IPアドレスが1つに決まりません。 そこでAWSにはエイリアスという仕組みがあって、「このAWSサービスを見て」と指しておくと、実際のIPアドレスはAWS側が解決してくれるそうです。

だから選ぶのはIPではなく、サービスとディストリビューション。ドロップダウンから選ぶだけで終わりました。

補足

ついでに知ったのですが、エイリアスレコードへの問い合わせには料金がかかりません。普通のレコードは問い合わせの数で課金されるので、AWSのサービスに向けるならエイリアスのほうが得、ということのようです。

Aレコード以外にも、いろいろあった

レコードを作る画面で気になったのが、タイプの選択肢の多さです。A以外にもずらっと並んでいて、何がなんだか分かりませんでした。

これも調べたので、分かったぶんだけ書いておきます。

種類	ざっくり何をするもの	今回の使い方
`A`	名前 → IPアドレス（IPv4）	CloudFrontへのエイリアスに使った
`AAAA`	名前 → IPアドレス（IPv6）	使っていない。IPv6にも対応するなら、同じように作る
`CNAME`	名前 → 別の名前	ACMの検証用に、自動で作られていた
`NS`	このドメインをどのDNSサーバが管理しているか	ドメインを買った時点で作られている
`SOA`	ゾーンそのものの基本情報	同上
`MX`	メールの届け先サーバ	独自ドメインでメールを使うなら必要
`TXT`	自由なテキスト	サイトの所有確認などに使うらしい

ホストゾーンを開いたときに最初から入っていた NS と SOA は、購入した時点でAWSが作っていたものでした。今回自分の操作で増えたのは2つだけです。

ACMの検証用に自動で作られた CNAME
CloudFrontに向けた A（エイリアス）

TXT は、この先Search Consoleにサイトを登録するときに触ることになりそうです。そのとき改めて書きます。

えーーーー繋がってるーーーー

設定が終わって、ブラウザで https://bun-bou.com を開いてみたら、

表示されました。

鍵マークも付いています。すんなり繋がりすぎて、逆に「本当にこれでいいのか？」と少し疑ったくらいです。

完成した構成。前の記事で点線だった部分が、全部つながりました

前回の記事で点線で描いていた部分が、全部つながりました。ブラウザから見ると、名前を引いて、CloudFrontが証明書つきで配信して、中身はS3にある。資格の勉強で図だけ見ていた構成が、自分のURLで動いています。

いちばん身構えていたACMが、いちばんあっけなかった。理解が追いつく前に終わってしまったという感じで、今回は後から調べ直す時間のほうが長かったです。ただ、その調べ直しでようやく腑に落ちたので、順番としては悪くなかったと思っています。

この先やること

Astro側の設定を新しいURLに直す — サイトマップやRSS、OGPのURLが古いままなので
www をどうするか — 今は bun-bou.com だけ。www.bun-bou.com でも来られるようにするかは考え中
SEO対応 — Search Consoleに登録して、サイトマップを送るところから

とりあえず、人に見せられるURLになりました。