aws cloudfront / route53を取得してドメイン名を解決できません
SSLを使用してクラウドフロントディストリビューションをセットアップしました。パブリックで静的なウェブサイトとしてセットアップされているs3バケットを指しています。 HTTPSを強制したいので、HTTPをHTTPSにリダイレクトするオプションを選択しました。
example.comを使用して、エイリアスタイプであるAレコードとAAAAレコードの両方を持つようにroute53をセットアップし、クラウドフロントドメイン名に解決します。これを行うと、「ホストゾーンID」が自動的に表示され、Amazonがクラウドフロントドメインを認識していることが示されました。
ブラウザでクラウドフロントエンドポイントにアクセスしてウェブサイトを表示できますが、example.com（HTTPSなし、wwwなし）に直接アクセスすると、次のように表示されます。
403ERRORリクエストを実行できませんでした。要求の形式が正しくありません。 cloudfront（CloudFront）リクエストIDによって生成：xDCmX7k8EFGGLAfjgpJcJ7AD-_mRfdBseTsqEP2aXfSWQ5S2mTMwuA ==
ただし、https://example.comを試してみると、空白のページが表示されます。
example.comとwww.example.comの両方をcloudfrontcnamesフィールドに入力しようとしましたが、何も実行されなかったため、現在それらを削除しています。
両方が必要になりますexample.comおよびwww.example.com CloudFrontCNAMEs設定で。しかし、これらを追加した後、テストするまでどのくらい待ちましたか？変更が行われた後、CloudFrontはすべてのエッジロケーションに再デプロイする必要があり、これには時間がかかる場合があります。
ディストリビューションのリストでステータスを確認できます。「デプロイ中」と表示されている場合は、待つ必要があります。多くの場合、約15分ですが、場合によっては最大1時間かかることもあります。
変更をデプロイした後、サーバーから最新のものを要求していることを確認するために、ブラウザーのキャッシュをクリアする必要もあります（おそらくシークレットウィンドウで試してください）。 301リダイレクト（CloudFrontがHTTPからHTTPSにリダイレクトするために使用するもの）は「永続的」と見なされ、ブラウザーはこれをキャッシュしている可能性が高く、CloudFrontに再度要求することはありません。
テストを行うときに確認する最も簡単な方法は、多くの場合、curlを使用することです。
curl --head --location http://example.com
curl --head --location http://www.example.com
curl --head --location https://example.com
curl --head --location https://www.example.com
これらのそれぞれについて、httpからhttpsアドレスへの301リダイレクト、およびhttpsアドレスでの200OKなどの応答を取得する必要があります。
理想的には..実際には、www（またはwwwがメインドメインの場合はネイキッドドメイン）用に別のCloudFrontディストリビューションをセットアップし、単純なリダイレクトのあるバケットをポイントして、全員がそのアドレスに到達するようにする必要がありますあなたが好む。
ただし、覚えておくべき主なことは、ディストリビューションに変更を加えた後、...waitです。 100を超えるエッジロケーション 展開先があります。