LoginSignup
13
18

More than 1 year has passed since last update.

@rihib(rihib)

AWS S3 + CloudFront + 独自ドメインを使った静的サイトの作成方法をめちゃくちゃ詳しく解説する

Last updated at Posted at 2022-11-06

はじめに

独自ドメインを取得し、AWS S3 + CloudFrontを使って静的サイトを作成していきます。
この記事には以下の内容が含まれます。

  • REST APIエンドポイントを用いて、AWS S3 + CloudFrontを使って静的サイトを作成する方法
    • 各設定項目についての詳細な説明
  • 独自ドメイン（Google Domains）を導入する方法
  • DNSSECの設定方法
  • DNSレコードについての説明

独自ドメインを取得する

ドメインを取得するのは何でも構いませんが、この記事ではGoogle Domainsを使用します。各レジストラの指示に従って欲しいドメインを購入してください。

独自ドメインをAWSに追加する

  1. Route53のダッシュボードに移動し、「ホストゾーン」をクリックします。
    スクリーンショット 2022-11-05 23.37.18.png
  2. 「ホストゾーンの作成」をクリックします。
    スクリーンショット 2022-11-05 23.38.38.png
  3. 「ドメイン名」を入力し、「パブリックホストゾーン」を選択し、「ホストゾーンの作成」をクリックします。
    スクリーンショット 2022-11-05 23.40.06.png
  4. ホストゾーンの一覧ページに飛ぶので、「レコード」の「タイプ」が「NS」の行の「値/トラフィックのルーティング先」の列に表示されている値（ネームサーバー）はあとで使うので確認できる状態にしておきます。
    • メモを取る必要はなくて、ブラウザ上でタブを消さないでいればそれで大丈夫です。
  5. Google Domainsにアクセスし、「マイドメイン」を開いて、使用するドメインの「管理」をクリックします。
    スクリーンショット 2022-11-05 23.43.15.png
  6. 「DNS」にアクセスし、「カスタムネームサーバー」タブを選択して、「ネームサーバー」に前述したAWSのホストゾーン一覧のページに表示されているネームサーバーを全て入力して保存します。
    • 一応ネームサーバー名の最後のドットも含めてGoogle Domainsの方にコピペしよう。こういう記事があるので。ただ保存後は最後のドットが消えた状態で表示されるので果たして意味があるのかはわからない。だけどつけて悪いことは起こらないのでつけとくのがいいかも。
      スクリーンショット 2022-11-05 23.45.03.png
  7. ネームサーバーを保存後、上に表示される「これらの設定に切り替える」をクリックする。そうすると２枚目の画像のようになる。
    スクリーンショット 2022-11-05 23.56.06.png
    スクリーンショット 2022-11-05 23.56.33.png
  8. AWSに戻り、リージョンを「バージニア北部（us-east-1）」に変更する。
    • CloudFrontからはバージニア北部にある証明書（後述）しか利用できないため。
  9. AWS Certificate Manager（ACM）のダッシュボードにアクセスし、「証明書をリクエスト」をクリック
    スクリーンショット 2022-11-06 0.03.15.png
  10. 「パブリック証明書をリクエスト」を選択し、「次へ」をクリックします
    スクリーンショット 2022-11-06 0.04.20.png
  11. 「完全修飾ドメイン名」にドメイン名とワイルドカード証明書用のドメイン名を入力し、「検証方法」は「DNS検証」を選択して、「リクエスト」をクリックします。
    • ワイルドカード証明書についてが参考になります。これで全てのサブドメインに対して有効な証明書を発行できますが、注意点として複数階層のサブドメイン（auth.www.example.comなど）に対しては有効ではありません。その場合は１階層上のサブドメイン（www.example.comなど）に対する証明書を別途発行する必要があります。
      スクリーンショット 2022-11-06 0.06.57.png
  12. 証明書の一覧ページに遷移するので、作成した証明書IDをクリックします。
  13. 証明書の詳細ページに行ったら、「Route53でレコードを作成」をクリックします。
  14. ページ遷移後、対象の２つのドメインが選択されているのを確認したら、「レコードを作成」をクリックします。
  15. 再度証明書の詳細ページに遷移するので、１分ほど待ってページをリロードするとステータスが「発行済み」になります。
  16. AWSのリージョンを「東京（ap-northeast-1）」に戻しておきましょう。

DNSSECを有効にする

DNSSECはキャッシュポイズニング攻撃やDNSスプーフィングなどを防ぐためのDNSのセキュリティ設定です。今まではGoogle DomainsがDNSSECの設定を自動でしてくれていましたが、AWSのネームサーバーを使うように変更したので、DNSSECの設定を再度行わなければなりません。以下のようにして設定します。

  1. Route53のダッシュボードにアクセスし、「ホストゾーン」を開き、ドメイン名をクリックします。
    スクリーンショット 2022-11-06 13.54.43.png
  2. 「DNSSEC署名」タブを開き、「DNSSEC署名を有効化する」をクリックします。
    スクリーンショット 2022-11-06 13.56.58.png
  3. 以下のように設定して、「KSKを作成して署名を有効化する」をクリックします。
    • KSKを作成すると月$1の費用がかかります。
    • 「KSK名の指定」には任意の名前を入力します。
    • 「AWS KMSのカスタマー管理のCMK」は、「カスタマー管理のCMKの作成」を選択します。
    • 「カスタマー管理のCMKの作成」には、任意のキーのエイリアス（名前）を入力します。
      スクリーンショット 2022-11-06 14.06.18.png
  4. 遷移先のページで「DSレコードを作成するための情報を表示」をクリックします。
    スクリーンショット 2022-11-06 14.23.52.png
  5. 表示されたページ上の「別のドメインレジストラ」を開き、「キーのタグ」「ダイジェストアルゴリズム」「ダイジェストアルゴリズムのタイプ」「ダイジェスト」「署名アルゴリズム」「署名アルゴリズムのタイプ」の値があることを確認します。
  6. 先ほどと同じようにGoogle Domainsの「DNS」ページを開き、「DNSSEC」の「レコードを管理する」をクリックします。
    スクリーンショット 2022-11-06 14.38.27.png
  7. 以下の値を入力し、「保存」をクリックします。
    • 「キータグ」には先ほどAWS上で確認した「キーのタグ」を入力します。
    • 「アルゴリズム」には、「署名アルゴリズムのタイプ」の番号のものを選択し、念のため選択したアルゴリズム名と「署名アルゴリズム」の値が一致するか確認します。
    • 「ダイジェスト タイプ」には、「ダイジェストアルゴリズムのタイプ」の番号のものを選択し、念のため選択したダイジェストタイプ名と「ダイジェストアルゴリズム」の値が一致するか確認します。
    • 「ダイジェスト」には、先ほど確認した「ダイジェスト」の値を入力します。

Google Workspaceのメールを使えるようにする

もしGoogle Workspaceを使用している場合、カスタムネームサーバーを使用するように変更すると、そのままではメールが届かなくなってしまいます。メールが届くようにするには、MXレコードをAWS Route53のホストゾーンに追加する必要があります。以下にその手順を示します。

  1. Google Domainsの「DNS」ページにアクセスし、「デフォルトのネームサーバー」のタブを開き、「ネームサーバー」のMXレコードの「データ」の部分をコピーします。
    スクリーンショット 2022-11-10 15.49.47.png
  2. AWSのRoute53のダッシュボードにアクセスし、「ホストゾーン」に行き、「ドメイン名」をクリックします。
    スクリーンショット 2022-11-10 15.54.14.png
  3. 「レコード」タブを開き、「レコードを作成」をクリックします。
    スクリーンショット 2022-11-10 15.56.08.png
  4. 「レコードタイプ」で「MX」を選択し、「値」にGoogle Domainsにてコピーした「データ」の値を貼り付けし、「TTL」は3600秒（1時間）を選択、「ルーティングポリシー」は「シンプルルーティング」を選択し、「レコードを作成」をクリックします。
    スクリーンショット 2022-11-10 15.58.15.png
  5. Google Workspace で Gmail を使用できるようにするの「設定ツールを開く」という青いボタンを押し、「Gmailが有効になりました」という表示がされたらOK。「テストメールを送信」を押してテストしてみる
    スクリーンショット 2022-11-10 16.03.11.png
    スクリーンショット 2022-11-10 16.04.06.png

S3 + CloudFrontを使用して静的サイトを作成

構成の種類

CloudFrontとS3で静的サイトを作成する場合、ウェブサイトエンドポイントを使う方法とREST APIエンドポイントを使う方法の２通りの構成方法があるようです。それぞれについては以下の記事が参考になります。

この記事で以下のように述べられているように、今回はREST APIエンドポイントを使った構成方法で作成します。

個人的には「まずはREST APIを使うパターンで設計し、インデックスドキュメントなどの機能が必要で構成をシンプルにまとめたい場合にのみ静的ウェブサイトホスティングを使う」のが良いのかな、と、いまのことろ考えています。

1. S3のバケットを作成する

  1. S3のダッシュボードに行き、「バケットを作成」をクリックします。
    スクリーンショット 2022-11-01 16.04.39.png

  2. 作成画面にて、以下のように設定を行います。

    一般的な設定

    スクリーンショット 2022-11-01 17.25.29.png

    バケット名

    任意の名前を入力します。

    AWSリージョン

    主にアクセスされるであろう場所と地理的に一番近いリージョンを設定することが望ましいです。

    既存のバケットから設定をコピー

    既にバケットを作成していて、そのバケットの設定をコピーしてきたい時に使います。やりたければ「バケットを選択する」をクリックして設定をコピーしたいバケットを指定します。ここでは使いません。

    オブジェクト所有者

    スクリーンショット 2022-11-01 17.27.55.png

    原則「ACL無効」を選択すべきようです。S3のアクセス制御は原則としてポリシーを使って行うべきで、ACL（アクセスコントロールリスト）を使って行うべきではないようです（以下の記事を参照）。

    S3のアクセスコントロールリスト(ACL)の基礎を学ぼう

    何が嬉しい？S3 Object ACL無効化 - 聞いた後、速攻で忘れていい知識をお届けします -

    このバケットのブロックパブリックアクセス設定

    スクリーンショット 2022-11-01 17.29.08.png

    「パブリックアクセスをすべてブロック」を選択します。含まれている項目を見るとわかるように「パブリックアクセスをすべてブロック」を選択するとACLを使ったアクセスも全て拒否してくれます。こうすることでACLに誤った設定をしてしまい気づかないうちにバケットやその中身のオブジェクトが全世界から自由にアクセス可能になっていたなんて事態を防ぐことができます。前述したように基本的にACLを使ってアクセス制御することはないので事故をなくすためにも「パブリックアクセスをすべてブロック」を選択しときましょう。

    加えて今回のREST APIエンドポイントを使った構成の場合、S3へのアクセスはCloudFrontからのみに限定される（前述した『CloudFrontとS3で作成する静的サイト構成の私的まとめ』に構成図が載ってます）のでそもそもパブリックアクセスは必要ありません。

    バケットのバージョニング

    スクリーンショット 2022-11-01 17.29.54.png

    まずバケットのバージョニングとは何かということから説明しましょう。例えばdog.jpgという犬の画像がバケットに入っているとします。これを誰かがdog.jpgという画像名はそのままで、猫の画像に変更してしまいました。このとき、バージョニングを有効にしていると、たとえdog.jpgが猫の画像に変更されたとしても前のバージョンのdog.jpg（つまり犬の画像）は古いバージョンとして残ります。バージョニングを無効にしている場合はdog.jpgが猫の画像に変更されてしまったら元の犬の画像は無くなってしまいます。

    削除の場合も同様です。たとえdog.jpgを削除したとしても削除フラグという印をdog.jpgにつけて削除扱いにするだけで実際にはdog.jpgは削除されません（これを論理削除と言います）。そのため、バージョニングを有効にしておくと、間違ってバケット内のオブジェクトに変更や削除を行ったとしても前のバージョンが保持されているので復元が簡単になるということです。

    ただ、注意点としては変更しても前のバージョンが保持されたり、削除しても削除扱いにするだけで実際には削除しないため、意図せずファイル容量が増えてその分コストがかかってしまうといったことが考えられます。個人で使用する分にはそれほど問題にはならないでしょうから、ここでは「有効にする」を選択します（その方が勉強になるので）。より詳しく知りたい人は以下の記事が参考になります。

    絵で見て 3分でおさらいする Amazon S3 のバージョニングとライフサイクル

    タグ

    スクリーンショット 2022-11-01 17.57.35.png

    このバケットにタグをつけることで後でAWS全体でコスト等を可視化したり、検索することが容易になります。今の段階では必要ないと思うので、後になって使用するAWSのサービスが増えてどこでコストがかかってるのか知る必要が出てきた時につければいいでしょう。なのでここでは何もタグはつけません。

    デフォルトの暗号化

    スクリーンショット 2022-11-01 17.58.04.png

    これは、バケットにオブジェクトを保存する際に暗号化をするかどうかの設定です。暗号化することのメリットとしては、第三者がS3のオブジェクトに直接アクセスしたとしても暗号化されているので情報が流出しづらくなります。デメリットとしては、暗号化は重い処理なので、その分、パフォーマンスが落ちます。

    S3デフォルト暗号化によるパフォーマンスを検証してみた

    暗号化する場合は、暗号化に使用するキーが２種類あるので選択する必要があります。それぞれの違いと使い分けについては以下の記事が参考になります。

    SSE-S3とSSE-KMSの違いを知る

    今回はバケット内のオブジェクトは静的サイト上で公開するわけなので、特に暗号化するメリットはありません。よってここでは「無効にする」を選択します。

    詳細設定

    スクリーンショット 2022-11-01 18.07.27.png

    「オブジェクトロック」を有効にするとたとえrootユーザーであってもバケット内のオブジェクトを変更したり、削除することができなくなります（有効にすると自動的に「バケットのバージョニング」も有効になります）。これは法律等によって必要な時にのみ使うもので、通常であれば使う必要は全くありません。なので「無効にする」を選択しましょう。詳しくは以下の記事が参考になります。

    Amazon S3のオブジェクトロック機能についてあらためて調べてみた

  3. 上記の設定が終わったら「バケットを作成」をクリックします。
    スクリーンショット 2022-11-01 18.07.18.png

  4. 作成後はバケットの一覧ページに行くと思うので、先ほど作成したバケットの名前をクリックします。
    スクリーンショット 2022-11-01 18.13.10.png

  5. バケットの詳細画面に行きます。ここでバケットの設定を確認したり、変更することができます。

    • 「プロパティ」タブの「静的ウェブサイトホスティング」項目で「静的ウェブサイトホスティング」が「無効」になっていることを確認します
    • 「アクセス許可」タブの「ブロックパブリックアクセス」項目で「パブリックアクセスをすべてブロック」が「オン」になっていることを確認します
      スクリーンショット 2022-11-01 18.16.13.png

  6. ローカルにて以下の内容のindex.htmlを作成します

    <!DOCTYPE html>
<html lang="ja">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Document</title>
</head>
<body>
    <h1>Hello, World!</h1>
</body>
</html>

  7. バケットの詳細画面にて「オブジェクト」タブを開き、先ほど作成したindex.htmlをドラッグ＆ドロップします
    スクリーンショット 2022-11-05 15.54.44.png

  8. アップロード画面に行くので、「アップロード」をクリックします
    スクリーンショット 2022-11-05 15.56.01.png

2. CloudFrontを作成する

2-1. 「セキュリティ」の設定を行う

  1. CloudFrontのダッシュボードに行き、「オリジンアクセス」をクリックします
    スクリーンショット 2022-11-05 16.08.36.png
  2. 「コントロール設定」タブの「コントロール設定を作成」をクリックします
  3. 「名前」に任意の名前を入力し、「設定」は「署名リクエスト」を選択し（「認証ヘッダーを上書きしない」は選択しません）、「作成」をクリックします
    • Amazon S3 オリジンへのアクセスの制限に書いてあるように、OACはユーザーがオリジンであるS3のコンテンツに直接アクセスしたり、意図しないCloudFrontディストリビューションを介してコンテンツにアクセスすることを防ぎ、ユーザーが指定されたCloudFrontディストリビューションを介してのみバケット内のコンテンツにアクセスできるように制御するものです。

2-2. ディストリビューションの作成

  1. 「ディストリビューション」に行き、「ディストリビューションを作成」をクリックする。

  2. 以下のように「オリジン」の設定をします。

    • 「オリジンドメイン」は作成したS3のドメインを選択
    • 「オリジンパス」は入力しない
      • オリジンのパスが参考になります
      • もちろんパスを追加したければ任意のパスを入力してください
    • 「名前」は自動で入力された内容のままにするか任意の名前を入力
    • 「S3 バケットアクセス」は「Origin access control settings」を選択
    • 「Origin access control」は先ほど作成したコントロール設定を選択
    • 「オリジンシールドを有効にする」は「いいえ」を選択
      • 「オリジンシールドを有効にする」はキャッシュのヒット率を高めてくれたりして、可用性を高めるのに役立ちますが、料金がかかるので、そこまでアクセス数の見込めない個人サイトであれば「いいえ」を選択するのがいいかなと思います。

    スクリーンショット 2022-11-05 16.28.00.png

  3. 「デフォルトのキャッシュビヘイビア」の設定をする

    • 「パスパターン」はそのままにします。
      • 「パスパターン」は、キャッシュを行うリクエストのURIパスのパターン
    • 「オブジェクトを自動的に圧縮」は「Yes」を選択する
      • 圧縮ファイルの供給によると、「Yes」を選択すると、ユーザーにコンテンツを配信する際に、CloudFrontはコンテンツを圧縮してユーザーに送ってくれるので、サイトの表示時間が速くなる可能性がある。
      • また、CloudFront のデータ転送コストは供給されたデータの総量に基づくため、圧縮オブジェクトを処理する方が、非圧縮オブジェクトを供給するよりもコストが安くなる可能性がある
    • 「ビューワープロトコルポリシー」は「Redirect HTTP to HTTPS」を選択する
      • ビューワーと CloudFront 間の通信で HTTPS を必須にするが参考になります。
      • 「HTTP and HTTPS」を選択した場合、ユーザーはHTTPとFTTPSのどちらを使ってもCloudFrontからコンテンツを取得できますが、わざわざREST APIエンドポイントを使ったメリットがなくなるのでやめときましょう。
      • 逆に「HTTPS only」を選択した場合、ユーザーがHTTPでCloudFrontにリクエストを送ると403が返ってきますので、HTTPSで通信しないとユーザーはコンテンツを閲覧できません。
      • 「Redirect HTTP to HTTPS」を選択した場合、ユーザーがHTTPでCloudFrontにリクエストを送るとHTTPSにリダイレクトするので、ユーザーは強制的にHTTPS通信することになります。この方法だとHTTPでリクエストされた場合、HTTPSにリダイレクトされるので二重の料金がかかってしまいますが、たとえHTTPで通信してしまってもエラーになることはないので、「HTTPS only」に比べてUXを下げずに済みます。なので「HTTPS only」と「Redirect HTTP to HTTPS」のどちらを選ぶかは好みですが、今回は「Redirect HTTP to HTTPS」を選びました。
    • 「許可される HTTP メソッド」は「GET, HEAD」を選択します
    • 「ビューワーのアクセスを制限する」は、プライベートコンテンツとして限定公開したいわけでなければ「No」を選択します。
      スクリーンショット 2022-11-06 11.56.18.png
    • 「キャッシュキーとオリジンリクエスト」は「Cache policy and origin request policy」を選択し、「キャッシュポリシー」には「CachingOptimized」を選択します。「オリジンリクエストポリシー」はお任せします。
      • キャッシュについては自分の理解が追いついてないので、後日アップデートできたらと思います。
    • 「追加設定」の「スムーズストリーミング」は「No」を選択します。
      • ディストリビューションを作成または更新する場合に指定する値によると、Microsoft Smooth Streaming 形式のメディアファイルを配信するが、IIS サーバーがない場合はYesを、Microsoft Smooth Streaming 形式のメディアファイルを配信するためのオリジンとして使用する Microsoft IIS サーバーがある場合、または Smooth Streaming メディアファイルを配信しない場合は、Noを選択すると言っているので、今回は「No」を選択します。スムーズストリーミングについてより詳しく知りたい人はスムーズ ストリーミング 入門が参考になります。
    • 「フィールドレベル暗号化」はそのままにします。
      • 選択できない状態になっているはずです。この項目は「ビューワープロトコルポリシー」にて「HTTPS only」を選択し、「許可されたHTTPメソッド」で「GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE」を選択しないと選択できるようになりません。フィールドレベル暗号化とはユーザーがPOSTリクエストでデータをアップロードする際にCloudFrontが公開鍵を用いて暗号化し、秘密鍵を持つアプリケーションコンポーネントのみが復号できるようにすることでデータをずっと保護した状態にします。なので常にHTTPS通信を使用し、POSTとPUTリクエストを利用できる状態にしないと「フィールドレベル暗号化」を有効化できないのです。
    • 「リアルタイムログを有効にする」は「No」を選択します。
      • これを有効にするとCloudFrontがデータを受信してから数秒以内にディストリビューションが受信したリクエストに関する情報が取得できるようになります。リアルタイムログは、Amazon Kinesis Data Streams で選択したデータストリームに配信されます。今回は必要ないので「No」を選択します。

    スクリーンショット 2022-11-05 20.59.52.png

  4. 「関数の関連付け」

  5. 「設定」

    • 「料金クラス」は「すべてのエッジロケーションを使用する」を選択します。
      • その分高くなるので、心配なら「北米、欧州、アジア、中東、アフリカを使用」を選択してもいいと思います。私はそこまでアクセスされないならあまり関係ないかなと（憶測）思って、せっかくCloudFront使うならと「すべてのエッジロケーションを使用する」にしました。
    • 「AWS WAF ウェブ ACL」は何も選択しません。
      • WAFを使っている場合は選択すればいいと思います。
    • 「代替ドメイン名 (CNAME)」に使用したドメイン名を入力します。
    • 「カスタムSSL証明書」は前に作成したものを選択します。もし表示されない場合は証明書をバージニア北部以外のリージョンで作ってしまったのかもしれません。「レガシークライアントサポート」はオフのままで、「セキュリティポリシー」は推奨されているものを選択します。
    • 「サポートされているHTTPバージョン」は「HTTP/3」も含め全部有効にしましょう。せっかくワンクリックで有効にできて料金も変わらずにHTTP/3を利用できるのに使わない手はないです。
      • ただ既存のサービスがある場合は影響が出る場合があるのでもう少し調べたほうがいいです。これとか
    • 「デフォルトルートオブジェクト」は例えばユーザーがhttps://example.com/とリクエストしてきた時にどのコンテンツを返すかということです。設定しないとhttps://example.com/とリクエストしてきた時にディストリビューション内のコンテンツが公開されちゃいます。無難に前に作成したindex.htmlとかを入力すればいいんじゃないでしょうか。注意点として/は含められません。オブジェクト名だけで大丈夫です。詳しくはドキュメントに書いてあります。
    • 「標準ログ記録」は「オン」でも「オフ」でもどっちでもいいです。「オン」にするとCloudFrontがオブジェクトに対するリクエストの情報をログに記録して、そのログファイルをS3バケットに保存してくれます。ログ出力自体に料金はかからないですが、ログファイルはS3に保存されるのでその分は課金されます。僕はログ見るの好きなので「オン」にします。「オン」にするとログを保存するバケットを選択する必要がありますが、ログ保存用のバケットに関しては別途作ったほうがいいです。ログを見られるのはセキュリティ上あまりよろしくないので。ログ用のバケットを作成する際は基本的にはこの記事で作成した設定通りでいいのですが、「オブジェクト所有者」のところだけ「ACL有効」を選択してください。そうしないとCloudFrontがログを保存できなくなるようです。ログが保存できない場合は 「ディストリビューションを作成」をクリック時にエラーが出て作成されません。逆に言えば問題なく作成された場合はログ保存は問題なくできることがわかります。詳しくはドキュメントを見てください。
    • 「ログのプレフィックス」は任意のプレフィックスを入力します。ちなみに見やすくなるので末尾に/をつけたほうがいいとドキュメントでは書かれています。
    • 「cookieのログ作成」は「オフ」にします。ドキュメントでは、S3はCookieを処理しないので、ディストリビューションにEC2や他のカスタムオリジンが含まれていない限り、基本的に「オフ」にすることがいいと書かれています。
    • 「IPv6 を有効にする」は「オン」にします。ドキュメントを読む限り、今までの設定でIPv6が有効になるかどうかはちょっと怪しいですが、有効にしたところで害はないのでとりま有効にしときます。

  6. 「ディストリビューションを作成」をクリック

  7. 遷移先のページで下記のようなポップアップが表示されるので、「ポリシーをコピー」をクリック後、「S3バケットの権限に移動してポリシーを更新する」をクリックします。
    スクリーンショット 2022-11-06 1.14.33.png

  8. 「バケットポリシー」にて「編集」を押し、先ほどコピーしたポリシーを貼り付けて保存します。

    • コピーしたポリシーにはS3からオブジェクトを読み取る権限（s3:GetObject）しかついてないので、もしS3へのオブジェクトのアップロードを行いたい場合はポリシーにs3:PutObjectを追加する必要があります。
      スクリーンショット 2022-11-06 1.15.58.png

3. 独自ドメインとCloudFrontディストリビューションを紐づける

  1. Route53のダッシュボードに行き、「ホストゾーン」にアクセスし、前に作成したホストゾーンのドメイン名をクリックします。
    スクリーンショット 2022-11-06 12.10.37.png
  2. 「レコードを作成」をクリックします。
  3. 以下のように設定して、「レコード作成」をクリックします。
    • ２枚目の画像のような画面が表示される人は「クイック作成へ切り替える」を選択します。どちらの画面で設定しても変わらないですが、クイック作成の方が設定項目がまとまって表示されているので設定しやすいです。
    • 「レコード名」は自分の使用したいサブドメインを入力してください。サブドメインを使いたくない場合は空白にします。
    • 「レコードタイプ」は「A」を選択します。
    • 「エイリアス」はオンにします。
    • 「トラフィックのルーティング先」は「CloudFrontディストリビューションへのエイリアス」を選択します。
    • 「ディストリビューションを選択」は先ほど作成したCloudFrontのディストリビューションを選択します。
    • 「ルーティングポリシー」は「シンプルルーティング」を選択します。
  4. 一応、IPv6も使えるようになっているので、IPv6用のレコードも作成しましょう。先ほどと同じ要領で、「レコードタイプ」だけ「AAAA」にして新規レコードを作成します。

おわりに

最後に設定したドメインにブラウザを使ってアクセスしてみましょう。以下のように表示されたらOKです。
スクリーンショット 2022-11-06 12.29.45.png

【おまけ】 DNSレコードについて

名前解決とは

DNS（Domain Name System）は、普段目にするドメインネーム（www.example.comなど）をIPアドレスに変換する（これを名前解決という）を行うシステムのことです。名前解決はネームサーバー（DNSサーバー）によって行われます。ネームサーバーにドメインネームとIPアドレスが紐づいた情報が登録されています。

完全修飾ドメイン（FQDN）とは

実はいつも見ているURL（www.example.comなど）は完全修飾ドメイン（FQDN）と呼ばれるもので、ドメイン名（example.comなど）とホスト名（wwwなど）から構成されます。FQDNにはそれぞれIPアドレスが割り当てられています。違うサブドメイン同士で同じIPアドレスを付けることも可能です。例えばwww.example.comとexample.comに同じIPアドレスが割り当てられている場合は、どちらのURLをリクエストしても同じリソースが表示されます。

FQDNとは省略されていないドメインという意味なので、例えばホスト名のないドメイン（example.comなど）であってもIPアドレスが割り当てられている場合はFQDNです。逆にホスト名のないドメイン（example.comなど）にIPアドレスが割り当てられておらず、ホスト名のあるドメイン（www.example.comなど）にのみIPアドレスが割り当てられている場合は、ホスト名のないドメイン（example.comなど）はそれ自体は存在しないドメインなので、省略されたドメインと見做され、FQDNとは呼びません。ただ狭義には、ルートドメインまで記されてないと（www.example.com.など）FQDNではないという意見もあります。

DNSレコードタイプについて

Route53の「ホストゾーン」にアクセスし、ホストゾーンのドメイン名をクリックすると、「レコード」タブにレコード情報が表示されていると思います。この記事の通りに進めていた場合、5つのレコードが存在しているはずです。レコードには様々なタイプがあります。「タイプ」列を見ると、それぞれ「A」、「AAAA」、「NS」、「SOA」、「CNAME」と表示されていると思います。

Aレコードは、IPｖ4において、ホスト名とグローバルIPアドレスの紐づけを定義するレコードです。このレコードをもとにクライアント側はFQDNに紐づくIPアドレスを取得し、名前解決します。CloudFrontは固定IPアドレスを持たないので、値にはグローバルIPアドレスではなく、CloudFrontが指定されています。その時に応じて、グローバルIPアドレスをAWS側でよしなに指定してくれるということです。

AAAAレコードは、AレコードのIPv6版です。IPv6において、ホスト名とグローバルIPアドレスの紐づけを定義します。

NSレコードは、このドメインのゾーン情報を管理するネームサーバーが載っているレコードです。例えばクライアント側がwww.example.comにアクセスしたい場合、comのネームサーバーに問い合わせを行うと、comのネームサーバーはexample.comのネームサーバーのIPアドレスを返します。example.comのネームサーバーはwww.example.comのAレコードをもとにwww.example.comのIPアドレスを返してくれます。

SOAレコードは、ネームサーバーの管理者のメールアドレスなどの情報を持ちます。IETFによって定義されているレコードで必須です。

CNAMEレコードは、IPアドレスに別名をつけるレコードです。この記事とかわかりやすいです。

13
18
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
13
18