www.domain.comAWS EC2 Nginx インスタンスによってサポートされる AWS ロードバランサーに解決される があります。
www.domain.com:8888AWS バックエンド Web アプリケーションへのプロキシ。
www.domain.com:443次の例外を除き、EC2 のディスクから静的 HTML を提供します:
/app/EC2上で実行されている動的バックエンドアプリケーションへのプロキシパス- 404 応答は、カスタム エラー ページ用に同じ動的バックエンド EC2 にプロキシされます。
目的: ドメイン下の S3 ストレージから静的 HTML を直接提供できるようにするwww.domain.com(現在、S3 静的ファイルを Nginx サーバーのディスクに同期しています)。
検討されたオプション:
フェイルオーバー オリジン グループを備えた Cloudfront は、ポート 443 のトラフィックを適切に処理します。ただし、
www.domain.comCloudfront に関連付けると、明らかに何もリッスンしなくなりますwww.domain.com:8888。リスナーを提供するロードバランサーがあれば、
www.domain.comポート 443 と 8888 の動的トラフィックを処理できます。しかし、S3 をロードバランサーのターゲット グループとして設定する方法は明らかではありません。S3 の VPC エンドポイントを使用すれば可能になると思います。しかし、これで 404 フェイルオーバーを処理できるでしょうか? (参照: https://aws.amazon.com/blogs/networking-and-content-delivery/hosting-internal-https-static-websites-with-alb-s3-and-privatelink/ )www.domain.com:8888トラフィックを に移動するプロジェクトに着手しalt.domain.com:443、オプション 1 を使用します。ただし、 へのリンクを保持したい限り、www.domain.com:8888の宛先として cloudfront を使用することはできないと思いますwww.domain.com。フロントエンド Nginx プロキシがあり、8888 トラフィックをロードバランサーに、443 トラフィックを CloudFront にプロキシします。これにより、クライアント トラフィックがプロキシ経由で CloudFront に到達するため、CloudFront を使用する利点の多くが打ち消されます。さらに、Amazon ACM の外部で Lets Encrypt を介して SSL 終了を処理する必要があります。
オプション 3 は最もクリーンなオプションのように思えますが、迅速かつ簡単には実行できません。そのため、代替案を探しています。
他に検討すべき選択肢はありますか?