セットアップ
CloudFront で使用しようとしている webs/wix などのウェブサイト管理システムがあります。次のドメインとサブドメインがあります。
- ourdomain: メインのウェブサイト
- admin.ourdomain: https 経由で利用できるすべてのウェブサイトの管理インターフェイス
- images.ourdomain: S3 バケット
- router.ourdomain: 以下を参照
- [customersomething].ourdomain: 無料ユーザー用のサブドメイン
- [customersomething.com]: プレミアム顧客用のドメイン
このシステムは、ほとんどのドメインが router.ourdomain に CNAME され (さまざまなドメイン レジストラなどを持つお客様にとってこれが最も簡単な方法であるため)、router.ourdomain が ELB に A エイリアスされ、EC2 上の PHP が HTTP_HOST 値に基づいてサイトを処理し、イメージが S3 から取得されるという仕組みで動作します。
私たちの計画
そして今、私たちはこれらすべてを CloudFront の背後に置きたいと思っています。ほとんどのことは些細なことです。S3 を CF の背後に置くのは簡単でした。すべての ourdomain/*.(js|css) を asset.ourdomain サブドメインを介して CF の背後に置くのは簡単でした。*.images.ourdomain を使用してサブドメイン間でシャーディングし、クライアント側のロード時間などを削減できるのは喜ばしいことです。CF パラメータに "*.ourdomain" を入れることで、動的な PHP フリー サイトを含むすべての *.ourdomain を CF の背後に置くことさえできます。
問題
しかし、私たちが理解できないことの 1 つは、カスタム ドメインを持つ動的に作成されたすべての PHP サイトを CF の背後に配置する方法です。念のため、これらは router.ourdomain に CNAME されます。各ドメインを CF パラメータに配置することはオプションではありません。何万ものドメイン名を処理でき、それぞれを手動で構成せずに処理する必要があるためです。
そこで、私たちの考えは、router.ourdomain を代替ドメイン名として CF 構成に追加し、route 53 で router.ourdomain を CF にポイントし、CF を ELB をオリジンとしてポイントすることでした。その結果、毎回「エラー リクエストを満たすことができませんでした。不正なリクエストです。cloudfront (CloudFront) によって生成されました」というメッセージが表示される良い方法であることがわかりました。実際はすべてではない時間として、www.ourdomain は正常に動作します (router.ourdomain に CNAME されます) が、他のすべてのサブドメインでは上記のエラーが発生します (*.ourdomain は router.ourdomain に CNAME されますが、www ともちろん router を除いて、router.ourdomain に 1 つずつ CNAME されるサブドメインでも同じです)。そのため、現時点では、これをどのように解決すればよいのかまったくわからないだけでなく、www では機能するのに他のすべてでは機能しないのはなぜか、またはその逆なのかも理解していません。
ご意見やアイデアがあればぜひお聞かせください。
答え1
念のため：これらはrouter.ourdomainにCNAMEされます
はい、その通りです。それについては次の通りです。
それは問題ではありません。
はい、CloudFront は代替ホスト名を CNAME と呼びます。はい、CNAME DNS レコードは、特定のサイトのトラフィックを CloudFront にルーティングする一般的な方法です。ただし、ホスト名を CloudFront ディストリビューションを指す CNAME として構成しても、Cloudfront や HTTP 全般の動作には関係ありません。
ブラウザが Web サーバーに接続する場合、DNS から IP アドレスを検索します。パスに CNAME がある場合、その情報は破棄されます。ブラウザが気にするのは、「どの IP アドレスに接続するか」だけです。
たとえば、www.example.org が webfarm.example.com への CNAME だったとします。ブラウザは www.example.org を検索し、最終的に webfarm.example.com の IP アドレスを取得します。
答えが手元にあると、ブラウザは Web サーバーへの接続を確立し、リクエストを送信します。
GET / HTTP/1.1
Host: www.example.com
ブラウザから送信された http リクエストのヘッダーHost:には、アドレス バーに表示されるホスト名が含まれます。CNAME 情報は完全に利用できず、ブラウザにも Web サーバーにも不明です。
では、CNAME はリクエスト解析やレイヤー 7 ルーティングにどのように関係するのでしょうか? 関係ありません。CNAME ターゲットは、接続する IP アドレスを見つけるためのパスとしてのみ使用されます。
Cloudfront でこれらの IP アドレスを使用しているのは、あなたのディストリビューションだけではありません。他にも何百、何千ものディストリビューションがあります。それはヘッダーに帰着しますHost:。
「CNAME」（代替ホスト名）のリストは、CloudFrontが受信Host:ヘッダーで一致させて、リクエストが属するホスト名であるかどうかを判断するためのホスト名のセットです。あなたのHost:ディストリビューション。これは、ブラウザが送信する可能性のあるヘッダーのリストです。Host:ヘッダーがディストリビューションで構成された値と一致するまで、そのリクエストに関連付けられたディストリビューションは不明で未定義です。
受信ヘッダーをどのディストリビューションとも一致させられない場合、Cloudfront はどのような処理を行いますかHost:?
HTTP/1.1 400 Bad Request
したがって、表示される動作は予想どおりで、正しいものです。ワイルドカードは、代替ホスト名の設定行の左端の要素のみを構成している限り、CloudFront 設定で機能します。ただし、これは DNS とは何の関係もありません。
他の顧客所有のドメイン名をディストリビューションに乗せたい場合は、CloudFront でそれらのドメイン名を設定せざるを得ません。
ただし、手動ではなく API を介してプログラムで変更することもできます。
詳細は、Amazon CloudFront のドキュメントを参照してください。
ディストリビューションごとにこのようなエイリアスが 100 個までという制限がありますが、AWS サポートにフォームを送信することで、エイリアス数の増加をリクエストできます。ただし、実際には、これらを複数のディストリビューションに分割した方がよいでしょう。ホスト ヘッダーをオリジン サーバーに転送している場合 (オリジン サーバーが違いを認識できるようにするには、この操作を行う必要があります)、CloudFront は、リクエスト エスダー内の 1 つのホストで指定されたパスのオブジェクトをキャッシュせず、同じディストリビューションであっても、別のホストのキャッシュされた応答として返します。これは不可能です。リクエスト内の重要なパラメータが、あるリクエストから別のリクエストに変更されているためです。