Route53以外で取ったドメインで、静的サイトをS3でホスティングしたい。

AWS S3で静的サイトを公開したい。加えて、

公開するサイトは当然SSL接続。

ドメインはGoogleDomainsでまとめて管理したい。

メールアドレスもGoogleで同時に取って、メールサービスは本家GoogleWSで使いたい。

AWSでのお手軽ウェブサイト公開方法として、S3で静的ホスティングというやり方が知られています。ただ、これだけだとあんまり実用的じゃないんですよね。

S3にindex.htmlを頭にした素材をポイと置いて、静的ホスティングを設定する。ここまではいいんですよ。そこから「◯◯のためには別の××ってAWSサービスも使おう」という話になり、ググると独特な文体の公式のガイドラインが出てくるんだけど、頼んでもいないさらに別のAWSサービスを使う前提で書いてあったりして。出来の悪いRPGをやってる気分になってくる。
「S3でのサイト公開するって簡単だって聞いてたんだけど…大人しくお○前○ットコム使っとけば良かったのでは…」となった際の攻略情報が少なかったので、今回、実際のドメインを使って、一通り、納品できる状態まで構築する流れをまとめておきます。

やること

一歩ずつ組み立てていきます。
まず S3 にindex.htmlと、配下にcssを設置し、サイトとして公開します。
こうして公開したサイトにはhttps://s3.console.aws.amazon.com/s3/buckets/XXXX/XXXXX/index.htmlといったURLが割り振られます。(https接続はS3のホスティング機能がやってくれてます。)このURLを好きなドメインに設定するには、 Route53 を使用します。
Route53はDNS構築を含めたルーティングを司る司令塔のようなサービスです（AWS用語でいう"フルマネージドサービス"）。あとで詳しく説明しますが、DNSの設定は仕組みを理解できれば簡単です。ネームサーバー (以下NS)の レコード を書き換えることで、目的のドメインのサーバーの場所を指定します。今回、Route53でのこの作業を何度か行います。また、Route53ではwww付きURLのリダイレクト設定も行います。
Route53の主要機能の一つとしてドメインの取得を行えますが、今回はあえてここではドメインを取りません。
というのも、Route53とは別のドメインサービス（今回でいえば GoolgeDomains 、基本はどこの レジストラ でも大丈夫なはずです)でドメインを取得し、その親ドメインを変更せず、AWSで使用したいケースがあるからです。とりわけ、Google Domainsの利用価値は、メールサービスを含めた統合アプリケーションサービスであることです。 GoogleWorkspace 側から見れば Google Workspaceのメールを含めて他サービスは使い続けながら、ウェブサイトだけAWSで運用したいわけです。こうした構成は、GoogleDomainsとRoute53の各NSを設定することで可能です。今回はGoogleDomainsのNSでAWSを指定し、一方のRoute53ではメールのルーティングに関してはGoogleのメールサーバーに投げ返すように設定します。

Route53でS3バケットに独自ドメインを設定すると、https接続が効かなくなります。公開したサイトを(再度)https接続できるようにするには、 AWS Certificate Manager(ACM) での証明書の発行と、 Amazon CloudFront(CloudFront) の設定が必要になります。CloudFrontには、ACMで作った証明書を設置すると同時に、httpsに絞るルーティングと、403/404エラーの処理を担ってもらいます。なおCloudFrontの本来の機能は、世界中のAWSリージョンに配置されている Edge location と呼ぶサーバーにコンテンツを分散して持たせ、トラフィック性能を向上することにあります。

以下の表の順番で構築していきます。章立ては下の目次を見てください。1章と2章はGoogleDomainsとS3での、各々の独立した設定ですので、表では互いの項目にハイフンを入れています。

章	使うサービス	サイトをHTTPS化	サイトを独自ドメインで公開	ドメインメールのGメールでの使用
1	GoogleDomains(GD)	-	-	○
2	S3	○	×	-
3~4	GD,S3,Route53	×	○	○
5~7	GD,S3,Route53,CloudFront,ACM	○	○	○

読者対象

・ウェブサイトを独自ドメインで設置したい方
・とりわけS3でホスティングしたい方
・AWSに触れたことはあるけど、Reute53,CloudFront,AWS Certificate Managerのいずれかはまだ触ったことがない方
・DNSの仕組みを一回は聞いたことがあるけど、レコードをいじったことはない方

どれか当てはまる方には、役に立つかもしれません。
少し長いですが、張り切ってやっていきましょう。

目次

0.DNSの仕組みと今回作るシステムの構成

1.Google Domainsでドメインを取得

1-1. 好きなドメインを購入する

1-2. [オプション]Google Workspaceでadmin@~などのメアドを作成する

2.S3の設置

2-1. sample-program用のバケットを作成する

　2-1-1. バケットを作成する

　2-1-2. ブロックパブリックアクセス設定を設定する

　2-1-3. オブジェクトをアップロードする

　2-1-4. 静的ウェブサイトホスティングを有効にする

　2-1-5. バケットポリシーを編集する

2-2. www用のバケットを作成・リダイレクト設定する

3.Route53の設定

3-1. ホストゾーンを作成する

3-2. S3でホストされているウェブサイトのサブドメインに対してAレコードを作成する

3-3. www付きのアクセスを受けるAレコードを作成する

3-4. [オプション]メールのDNSを設定する

　3-4-1. MXレコードを設定する

　3-4-2. TXTレコードを設定する

4.GoogleDomainsでDNS設定

4-1. DNS > カスタムネームサーバー　でRoute53のNSのアドレス4つを入力する

4-2. DNS設定画面上部の「これらの設定に切り替える」をクリックする

4-3. 待つ

5.CloudFrontでSSL接続設定

5-1. Cloud Frontでディストリビューションを作成する

5-2. パブリック証明書をAWS Certificate Managerで発行してCloudFrontに設定する

5-3. 403/404の処理を設定する

6.Route53のCloudFrontとの接続設定

6-1. AレコードでCloudFrontのディストリビューションドメイン名を指定

6-2. wwwのAレコードを再編集

7.S3のCloudFrontとの接続設定

7-1. S3のバケットポリシーを設定する

0. DNSの仕組みと今回作るシステムの構成

DNSの仕組み

今回のシステムを作るにあたり、DNSの仕組みを理解できているとできていないでは、難易度が大きく変わってきます。遠回りに聞こえるかもしれませんが、DNSの仕組みからまずはおさらいしましょう。

IPアドレスとは、インターネット上の住所に当たるものです。そしてIPアドレスに、人間が読みやすいためのラベルをつけたものがドメインです。

ユーザーが目的のIPに辿り着くには、割り振られたドメインを誰が持っているかを記録して、誰かがそれを尋ねてきたら返答するという仕組みも必要です。これを行う仕組みが、DNS(Domain Name System)です。DNSでドメインからIPアドレスを特定する流れを名前解決と呼びます。

DNSサーバーにはデータが直接置いてあるわけではありません。データの置き場所のIPアドレスとドメインを紐付ける対応表が載っています。
すなわちDNSとは、アクセスするユーザーがドメイン名で指し示したデータサーバーまで辿り着く（名前解決する）ための、IPアドレスとドメインの対応表が記載されたDNSサーバーのネットワークが実現しているシステムです。DNSサーバーの中に書いてある対応表は、 レコード といいます。

IPアドレスもドメインも、インターネット上で一意である必要があります。すなわちドメインが機能するには、重複がないように管理する仕組みが必要です。

重複しないために少数のDNSサーバーで管理してしまうと、そこにみんながアクセスしてパンクしてしまいます。ここをうまいこと分散できる仕組みこそ、インターネットが拡張できた理由の一つです。アドレスの一意性とシステムの拡張性/可用性を両立させる仕組みをもう少し細かく解説します。一意性を担保しているのは論理的な階層構造で、拡張性/可用性を担保しているのが物理的なネットワーク構造です。

ドメイン管理の最上位団体はICANN(アイキャン)という組織です。ICANNにより、トップレベルドメインの種類が定められています。馴染み深い .jp や.uk など国別のトップレベルドメインの他にも、.comや .appなど、トップレベルドメインは沢山あります。こうしたトップレベルドメインはICANNが割り振った会社(レジストリ）が管理しています。例えば.comはVeriSignという会社が、.appはGoogle Registryという会社が管理しています。
管理者は、代理店(レジストラ)を通じ、割り振られたドメインをサーバーレベルドメインの粒度で分割販売します。今回、sample-program.com　というドメインをGoogleDomainsで買うのですが、この場合はGoogleDomainsがVeriSignと契約して代理販売している sample-program.com　というサーバーレベルドメインを、私が買うということです。買ったドメインは、移管しない限り、引き続きGoogleDomainsのサービスで管理できます。このように、アドレス空間を小分けして、それぞれを各々のDNSサーバーで管理する仕組みとなっています。

DNSサーバーには、大きく分けて、「そのドメインの情報ならこのIPが確かだぜ」という 権威DNSサーバー　と、クライアントから名前解決要求を受けると権威サーバーに聞き込みを行い、その結果をクライアントへ返す、 キャッシュDNSサーバー の2種類があります。

キャッシュDNSサーバーは、その名の通り、聞き込みを行うことで取得したレコードを貯めます。キャッシュDNSサーバーが持つレコードは、一時的なもので、新しいDNS情報を取り込んで更新していく性質があります。対して権威DNSサーバーにある対応表はドメイン管理者が直接管理でき、設定するとその情報が世界のDNSに伝わります。

権威サーバーのレコードをカスタムすることで、ドメインとIPアドレスの対応を書き換えることができ、好きなネットワーク構成を作ることができるわけです。

今回のシステムの構成図

最初に4章までで作るのは、以下のような構成のシステムです。

ここまでに使う主なサービスは、GoogleDomains,S3,そしてRoute53です。
GoogleDomainsではドメインを取得します。この記事では、Googleが代理店販売している「.com」アドレスのうち「sample-program.com」を取得します。
次に、S3に素材を配置します。Route53でAWS側のNSのレコードを書き換えることでS3を指定します。そして、AWS側のアドレスを、GoogleDomainsでGoogleのNSのレコードに記述します。
ここまでの設定で、Googleの管理するドメインでS3の素材を指定することができています。
名前解決は次の図の流れになります。

5~6章では以下の構成にしていきます。

CloudFrontとACMが追加されていますね。

少し脱線します。ACMですが、米国バージニア州のリージョンでのみ提供しているサービスです。CloudFrontはそれに合わせてバージニア州のリージョンを使う必要があります。S3は好きなリージョンで立てて大丈夫です。知らないと引っかかるポイントの一つです。以降、「最初に書いとけよ」と思った話には　ひっかけポイント を付けておきます。

CloudFrontは世界中のリージョンに分散配置したEdge locationにデータをキャッシュしておき、最適なルーティングを実現する仕組みです。
リージョンを含めた状況をより正確に描くと、下の構成図になります。

1. GoogleDomainsでドメインを取得

1-1. 好きなドメインを購入する

Google Domainsでドメインを購入します。今回は「sample-program.com」を購入しました。

購入すると、DNS>デフォルトネームサーバー で、ドメインを管理する4つの権威NSのドメインが確認できます。

ここの情報はまた後で使います。

1-2. [オプション]Google Workspaceでadmin@~などのメアドを作成する

次に、このドメインでメアドを取得します。
「goolgleを利用したオンラインサービスの設定」>「Workspaceを入手」に進みます。
バックアップ用のメールは別ドメインのメアドを入れてください。

ちなみに今回作成するadmin@のメールアドレスは、そのドメインの管理者が保有しているべき管理者アドレスです。管理者アドレスにはadmin@のほか
administrator@
hostmaster@
postmaster@
webmaster@
が定められています。この規則はRFCという、インターネットの自主ガイドラインに記載されているもので、EUがGDPRでも準拠している、世界共通ルールです。2018年に施行されたGDPRの影響でWhois情報を見てもメールアドレスが隠されるケースが増えたのですが、この5つのアドレスは管理用アドレスとして、特に非公開にしなくて良いことになっています。

バックアップ用で設定したメアドに届く仮パスワードでログインし、パスワードを設定します。
設定後、Gmailの受信箱が表示されればOKですね。

2. S3の設置

AWSのアカウントは作成している前提で進めます。また、以降の全ての操作はAWSマネジメントコンソール上で行います。

2-1. sample-program.com用のバケットを作成する

今回、S3内には2つのバケットを作成します。一つはHTMLファイルをはじめ、データを置くバケットです。もう一つはwww.sample-program.comへのアクセスを受けるためのバケットです。一つ作ると勝手がわかると思いますので、www用はさらっと解説します。

2-1-1. バケットを作成する

ひっかけポイント
バケット名を、ドメインと合わせる必要があります。
ここできちんと合わせておかないと、後々、バケットを作り直すことになります。

2-1-2. ブロックパブリックアクセス設定を設定する

赤いビックリマークが付いていて怖いですが、チェックします。

他はデフォルトの設定で、「バケットを作成」をクリックします。

2-1-3. オブジェクトをアップロードする

今回は1枚のHTMLファイル、index.htmlと、style.cssを入れたcssというフォルダをアップロードします。

2-1-4. 静的ウェブサイトホスティングを有効にする

プロパティの一番下の「静的ウェブサイトホスティングを有効にする」を開きます。
ここでインデックスドキュメントを設定します。今回はindex.htmlです。

2-1-5. バケットポリシーを編集する

バケットポリシーの右にある「編集」をクリックします。するとポリシーを記述するエディタのような画面が開きます。

最初に以下のような記述になっています。

以下のように書き換えます

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "Statement1",
			"Principal": "*",
			"Effect": "Allow",
			"Action": "s3:GetObject",
			"Resource": "arn:aws:s3:::sample-program.com/*"
		}
	]
}

※Resourceのファイル名はご自身の環境で適宜読み替えてください。
ここまでの設定で、S3に設置した素材にブラウザからアクセスできます。先ほど設置したバケットのURLは http://sample-program.com.s3-website-ap-northeast-1.amazonaws.com ですね(プロパティ > 静的ウェブサイトホスティングの一番下のところで確認できます)。

2-6. www用のバケットを作成・リダイレクト設定する

www.sample-program.comというもう一つのバケットを作成します。
www無しが好まれる時代ですが、www付きもキャッチできなければいけません。
S3でwww付きのドメインのバケットを作成し、S3の機能で先ほどのsample-program.comへリダイレクトします。


パブリックアクセスブロックの設定は先ほどと同様です。ただしバケット作成後に少し異なる設定をします。
プロパティ　＞　静的ウェブサイトホスティング　の「編集」をクリックします。
静的ウェブサイトホスティングを有効にし、その下のオブジェクトのリクエストをリダイレクトする　をチェックします。

するとホスト名の入力欄が表示されますので、本体のS3内のエンドポイントsample-program.comを入力します。

プロトコルはなしで良いです。

変更の保存をクリックします。

最後に、バケットポリシーを、sample-program.comのバケットと同じ要領で変更します。Resourceのファイル名にはwww.を付けてください。

3. Route53の設定

次はいよいよRoute53で独自ドメインを付与します。

3-1. ホストゾーンを作成する

Route53のコンソールを開き、「DNS管理」の下の「ホストゾーン」をクリックします。

「ホストゾーンの作成」をクリックします。

ひっかけポイント　
S3でバケット名をドメインと揃えたのと同じく、ホストゾーンもドメインと揃えます。
ホストゾーンの作成をクリックします。

するとこのような画面になるかと思います。レコードが並んでいますね。初めて見ると面食らうかもしれませんが、意味がわかれば非常にシンプルです。

1行目にある、タイプ「NS」は、ネームサーバーですね。「レコード名」カラムにあるこのドメインを管理するネームサーバーが記述されています。
2行目のタイプ「SOA」は、このドメインの管理者に関する情報を記載しています。

詳しい意味は公式のこちらのページや、「Route53 レコード　タイプ」などでググって出てくるサイトで確認してください。
Amazon Route 53 がパブリックホストゾーンに作成する NS レコードと SOA レコード

ここにレコードを追加していきます。

3-2. S3でホストされているウェブサイトのサブドメインに対してAレコードを作成する

最初に追加するレコードはタイプAです。これは、IPv4のアドレスとドメインを結びつけるレコードです。
sample-program.comに来たアクセスを、先ほど作成したS3のアドレスに繋げます。

「レコードを作成」をクリックします。

レコード名はそのまま空欄、上の赤枠で囲んだチェックを押します。

S3ウェブサイトエンドポイントへのエイリアスを選択します。

リージョンを間違いなく選べていれば、S3バケットが表示されると思います。リージョンが間違っていないのに表示されないとすると、S3あるいはRoute 53でのバケット/ホストゾーン名を間違えている可能性があります。

ルーティングポリシーはシンプルルーティングでOKです。

次に、www.sample-program.com でのアクセスを先ほど作成したS3のwww付きの方のバケットに流すレコードを作成します。

3-3. www付きのアクセスを受けるAレコードを作成する

同じ手順で、Aレコードを作成します。

レコードはこんな感じに並ぶと思います。

ひっかけポイント　
ここで鋭い方は、「Route53で受けたwww.sample-program.com宛のルーティングをRoute53の中でsample-program.comにAレコードで流せばいいじゃん？それならS3で新しくバケット作る必要なかったじゃん？と気づくと思います。

実は、この構成でも動きます。ただ、後々に、CloudFrontを使う段階で、www.付きのドメインに対応するS3バケットが無いと困ってしまうんです。CloudFrontでは、カスタムドメイン名を設定する際に、ドメインに対応するS3バケットを紐づける必要があります。

つまり、S3での静的ホスティングでHTTPS接続とwww有り/無しドメインを両立するには、www用のバケットを特に用意する必要があるわけです。

3-4. [オプション]メールのDNSを設定する

本3-4節はオプションです。GoogleWorkspaceでメールアドレスを持っている場合の設定になります。
この後の4章でGoogleDomainsで、Googleの権威NSのレコードをいじります。sample-program.comへのアクセスがAWSに来るのですが、その際にメールもAWSに来てしまいます。ですのでRoute53で、メール宛のドメインを再度Googleに投げ返す必要があります。

　3-4-1. MXレコードを設定する

Route53で、レコードを追加します。タイプはMXです。
GoogleDomainsで「デフォルトのネームサーバー」の中の「GoogleWorkspace」を確認します。

この中のタイプMXのレコードのデータ欄を、そっくり、Route53で追加するレコードの「情報」欄へコピーします。レコード名は空欄で良いです。

　3-4-2. TXTレコードを設定する

同じ要領で、google._domainkeyというレコード名にRSA鍵が情報欄に入るTXTレコードと、レコード名空欄で情報欄に"v=spf1 include:_spf.google.com ~all"が入るTXTレコードを作ります。SPFレコードも作ってもいいです。
ここまで全部作ると下のようなレコードになります。

4.GoogleDomainsでDNS設定

今の状態では、sample-program.comへのアクセスはGoogleDomainに行っています。GoogleのNSのレコードを設定することで、ドメインでアクセスできるようになります。

4-1. DNS > カスタムネームサーバー　でRoute53のNSのアドレス4つを入力する

GoogleDomainsのDNS設定から、カスタムネームサーバーを開きます。

ここに、Route53で確認できるNSタイプのレコードの情報を1こずつ入力します。

4-2. DNS設定画面上部の「これらの設定に切り替える」をクリックする

4つのアドレスの入力と保存が終わったら、「これらの設定に切り替える」をクリックし、カスタムドメインを使います。

4-3. 待つ

DNSの設定が反映されるまで、数分から数十分かかります。待ちましょう。
しばらくすると、sample-program.comとwww.sample-program.comで、サイトが閲覧できるようになっているはずです。この後CloudFrontを追加したりして規模が大きくなってくると、DNSの変更後、しばらく経たないと反映されないということがあります。それを知らないと「公開したはずなのにアクセスできない！」と設定をまた変えたりして、さらにDNSを混乱させてしまいます。じっくり待つのが大事です。

5. CloudFrontでSSL接続設定

5~7章で、SSH接続をするための手順を行います。まずCloudFrontのディストリビューションの作成を行いますが、その手続きの中でACMで証明書を発行できます。

5-1. Cloud Frontでディストリビューションを作成する

CloudFrontコンソール画面からディストリビューションを作成をクリックします。

オリジナルドメインを選択します。ここでS3のバケットを選択しましょう。

オリジンパス - オプション　は空欄で良いです。

名前は適当に決めましょう。今回はsample-program.comと入れました。

S3 バケットアクセス　は「はい、OAI を使用します (バケットは CloudFront のみへのアクセスとなるように制限できます)」を選択します。
OAIは新しく作成します。

バケットポリシーは「はい、バケットポリシーを自動で更新します」を選択します。
これにより、先ほど作成したS3のガバガバポリシーに、最適な設定が追記されます（内容は後で確認します）。

カスタムヘッダーを追加 - オプション　は行いません。
オリジンシールドとその下の追加設定も、デフォルトでいきます。

次に、「デフォルトのキャッシュビヘイビア」項の設定です。
パスパターン　はそのまま
オブジェクトを自動的に圧縮　はYes
ビューワープロトコルポリシー は Redirect HTTP to HTTPS
許可された HTTP メソッド はGET, HEAD
ビューワーのアクセスを制限する　はNo
キャッシュキーとオリジンリクエスト はそのまま
関数の関連付け - オプション　は今回は選択しません。
AWS WAF ウェブ ACL - オプション は選択しません。

代替ドメイン名 (CNAME) - オプションに、ドメイン「sample-program.com」「www.sample-program.com」を入力します。

5-2-1. パブリック証明書をAWS Certificate Managerで発行する

証明書をリクエストをクリックします。
すると別タブでAWS Certificate Manager(ACM)の「パブリック証明書をリクエスト」画面に遷移します。

ドメイン名 にsample-program.comとwww.sample-program.comを追記します。

また、その下の検証方法を選択　ではDNS検証を選択します。

リクエスト後のサイトをリロードすると、今回リクエストした証明書が表示されていると思います。IDのリンクをクリックしてください。

5-2-2. Route53で発行されたCNAME値を設定する

ひっかけポイント　
ここで表示されるCNAME値2つを Route53 へ設定します。

レコードを作成をクリックします。
レコード名にはACMでのCNAME名 をコピペします。全文をコピーすると、末尾の.sample-program.comが被ってしまうと思うので、適宜修正を。
情報　にはCNAME値　をコピペします。

同様に、www用のCNAMEレコードも追加します。

ACMを確認してください。正しく設定できれば、証明書が通ります。

ACMを閉じ、CloudFrontへ戻ります。

カスタム SSL 証明書 - オプションで、今回作成した証明書を選択します。表示されていない場合は、右のボタンで更新してください。

レガシークライアントサポート - 月額 600 USD の比例配分された料金が適用されます。ほとんどのお客様はこれを必要としません。　はチェックを入れません。
セキュリティポリシー　と　サポートされている HTTP バージョン　はそのままで良いでしょう。
デフォルトルートオブジェクト - オプション　にはindex.htmlを入力します。

以上で基本設定は終了です。ディストリビューションを作成してください。

5-3. 403/404の処理を設定する

DloudFrontでは403や404などのエラー処理を設定できます。
エラーページ＞カスタムエラーレスポンスを作成をクリックし、403を選んで作成してください。続いて404を作成してください。
エラーレスポンスをカスタマイズ　はいいえで良いでしょう。

以上でCloudFrontの設定は終了です。

6. Route53のCloudFrontとの接続設定

6-1. Aレコードを編集してCloudFrontのディストリビューションドメイン名を指定

Route53のAレコードの接続先をCloudFrontに変更します。
sample-program.comのAレコードを編集します。トラフィックのルーティング先でCloudFrontディストリビューションへのエイリアス を選択します。するとディストリビューションで作成したディストリビューションが選択欄に出てきますので選択します。

もし出てこない場合にはCloudFrontの ディストリビューション > 一般 から確認し、コピペしてください。

6-2. wwwのAレコードを編集

www.sample-program.comは、リダイレクト先に同ディストリビューションのsample-program.comを指定します。

最終的に、以下のようなレコードになるかと思います。

7. S3のCloudFrontとの接続設定

7-1. S3のバケットポリシーを設定する

S3でsample-program.comのバケットを開き、アクセス許可>バケットポリシーを開くと、5-1で行った操作で、ポリシーが変更されていることがわかります。

前のものの後に、CloudFrontからのアクセスを許可するポリシーが追記されていますね。
前に書いたものを削除してスッキリさせます。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E3AFA562X0U0AW"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::sample-program.com/*"
        }
    ]
}

これによりS3バケットへのアクセスをCloudFrontのみに制限できました。

同様に、wwwのバケットも開き、

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E3AFA562X0U0AW"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::www.sample-program.com/*"
        }
    ] 
}

を入力します。

終わりに

お疲れさまでした。
ここまでの作業でウェブサイトが表示されるかと思います。
また、http接続しようとするとhttpsにリダイレクトされることも確認できると思います。
メールのDNSを設定した方は、メールも確認しましょう。

もしサイトがうまく表示されていなかったら、まずは少し時間を置いてみましょう。それでもダメそうなら、以下を見直してください。
・S3バケットおよびCloudFrontで、インデックスファイルを正しく設定しているか。
・CloudFrontのレコード設定は正しく行われているか（特にCloudFrontとの連携は少しややこしいので、6-2のレコードの様子を参考にして、漏れがないか確認してください)。
・S3のバケットポリシーは適切か。
・GoogleDomainsでカスタムネームサーバーは有効になっているか。

また、CloudFrontの導入後、データ変更を早く反映したい場合は、CloudFrontのエッジサーバー上のキャッシュを削除するということが可能です。簡単ですのでググってみてください。

参考になったサイト

AWS公式：
【S3】
オリジンアクセスアイデンティティ (OAI) を使用して Amazon S3 コンテンツへのアクセスを制限する
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html#private-content-granting-permissions-to-oai

Amazon S3 バケットでホストされているウェブサイトへのトラフィックのルーティング
https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/RoutingToS3Bucket.html

【Route53】
親ドメインを移行しないで Amazon Route 53 を DNS サービスとして使用するサブドメインを作成する
https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html#CreateZoneNewSubdomain

【CloufFront】
CloudFront を使用して Amazon S3 バケット向けに HTTPS リクエストを提供するにはどうすればよいですか。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/cloudfront-https-requests-s3/

Google公式：
Google 経由で登録したドメインにウェブサイトを接続する
https://support.google.com/a/answer/7538152?hl=ja

ブログ
AWSでWebサイトをHTTPS化 全パターンを整理してみました
https://recipe.kc-cloud.jp/archives/11067

AWSでWebサイトをHTTPS化 その5：CloudFront(+証明書)→S3編
https://recipe.kc-cloud.jp/archives/11256

【AWS】S3+CloudFront+Route53+ACMでSSL化(https)した静的Webサイトを公開する
https://zenn.dev/wakkunn/articles/66a6e8372611dc#%E5%AE%9F%E8%A3%85%E6%89%8B%E9%A0%86