この回答は、ロード バランサー セキュリティ グループですでに https を有効にし、ロード バランサーに SSL 証明書を追加し、ポート 80 と 443 の両方がロード バランサーによって転送され、Route 53 を使用して Elastic Beanstalk 環境でドメイン名を指定していることを前提としています。 (または同等の DNS サービス)。
オプション 1: Apache でリダイレクトを行う
これは、Apache を使用する Elastic Beanstalk 環境にいる場合にのみ可能です (AWS Linux 2 ベースのデプロイは、Apache を使用するように設定できます)。Docker ベースの展開では機能しない場合があります。
アマゾン Linux 2
ほとんどの AWS Linux バージョン 2 ベースのプラットフォームには、プロキシ ホストとして Apache を選択するオプションがあります。これを行うには、[構成] > [ソフトウェア] > [コンテナー オプション] に移動し、[プロキシ サーバー] を [Apache] に設定するか.config、.ebextensions.
option_settings:
aws:elasticbeanstalk:environment:proxy:
ProxyServer: apache
.platform/httpd/conf.d/ssl_rewrite.confそれが完了したら、コードベース (関連する AWS docs ) に名前が付けられた構成ファイルを次の内容で追加します。
RewriteEngine On
<If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</If>
アマゾン リナックス 1
プロジェクト.configのディレクトリにあるファイルの.ebextensions1 つに以下を追加するだけです。
files:
"/etc/httpd/conf.d/ssl_rewrite.conf":
mode: "000644"
owner: root
group: root
content: |
RewriteEngine On
<If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</If>
説明
これは、Elastic Beanstalk の外部ではやや単純です。通常、次のような Apache 書き換えルールを追加します。
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
または、この場合のように、ロード バランサーの背後にある場合:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
ただし、これらの構成は<VirtualHost>ブロック内でのみ機能します。をブロックに変更するRewriteCondと、<If>ブロックの外で適切に動作するよう<VirtualHost>になり、スタンドアロンの Apache 構成ファイルに入れることができます。CentOS での標準の Apache セットアップ (ElasticBeanstalk でのセットアップを含む)/etc/httpd/conf.d/*.confには、このファイルを保存するファイル パスに一致するすべてのファイルが含まれることに注意してください。
条件の-n '%{HTTP:X-Forwarded-Proto}'一部により、ロード バランサーの背後にいない場合にリダイレクトが防止され、ロード バランサーと https を使用する運用環境と、単一インスタンスであり https を持たないステージング環境の間で構成を共有できます。すべての環境でロード バランサーと https を使用している場合、これは必要ありませんが、使用しても問題はありません。
オプション 2: ALB でリダイレクトを行う
これは、Application Load Balancer を使用している場合にのみ可能です。Amazon には、その方法についての説明があります: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/configuring-https-httpredirect.html
プロジェクト.configのディレクトリにあるファイルの.ebextensions1 つに以下を追加して、http リスナーをリダイレクトに置き換えるだけです。
Resources:
AWSEBV2LoadBalancerListener:
Type: AWS::ElasticLoadBalancingV2::Listener
Properties:
LoadBalancerArn:
Ref: AWSEBV2LoadBalancer
Port: 80
Protocol: HTTP
DefaultActions:
- Type: redirect
RedirectConfig:
Host: "#{host}"
Path: "/#{path}"
Port: "443"
Protocol: "HTTPS"
Query: "#{query}"
StatusCode: "HTTP_301"
私が見た悪い解決策
私はこの問題に対する悪い解決策をたくさん見てきましたが、なぜこの解決策が必要なのかを理解するためにそれらを一通り調べる価値があります。
Cloudfront を使用する: Elastic Beanstalk の前にキャッシュされていない Cloudfront セットアップを使用して、HTTP から HTTPS へのリダイレクトを行うことを提案する人もいます。これにより、まったく適切ではないまったく新しいサービスが追加されます (したがって、複雑さが増します) (Cloudfront は CDN です。本質的に動的なコンテンツに HTTPS を強制するための適切なツールではありません)。Apache config はこの問題に対する通常の解決策であり、Elastic Beanstalk は Apache を使用するため、それを使用する必要があります。
サーバーに SSH 接続して...:これは、Elastic Beanstalk の点とは完全に対照的であり、非常に多くの問題があります。自動スケーリングによって作成された新しいインスタンスには、変更された構成はありません。複製された環境には構成がありません。合理的な一連の環境変更が何度でも行われると、構成が消去されます。これはとても悪い考えです。
新しいファイルで Apache 構成を上書きします。これは適切な解決策の領域に入りつつありますが、Elastic Beanstalk がサーバーのセットアップの側面を変更した場合 (彼らは非常によく行う可能性があります)、メンテナンスの悪夢が残ります。次の項目の問題も参照してください。
Apache 構成ファイルを動的に編集して、数行を追加します。これは適切なアイデアです。これに関する問題は、Elastic Beanstalk がデフォルトの Apache 構成ファイルの名前を変更した場合に機能しないことと、このファイルが予期しないときに上書きされる可能性があることです: https://forums.aws.amazon.com/thread .jspa?threadID=163369