Having www.example.com go to example.com如果您不关心它实际上是重定向，则可以使用 DNS 中的 CNAME 来完成。如果您需要重定向，可以将其添加到下面的 Apache 配置中。这个答案的要点是详细说明如何修改 Elastic Beanstalk 上的 Apache 配置（因为正确执行此操作并不是很简单）。
此答案假设您已在负载均衡器安全组中启用 https，将 SSL 证书添加到负载均衡器，将 443 添加到负载均衡器转发的端口，并使用 Route 53 将您的域名指向 Elastic Beanstalk 环境（或等效 DNS 服务）。
亚马逊Linux 2
大多数基于 AWS Linux 版本 2 的平台都可以选择 Apache 作为代理主机。这可以通过转到“配置”>“软件”> 来完成
“容器选项”并将“代理服务器”设置为“Apache”，或将以下内容添加到您的其中一项.config文件在.ebextensions:
option_settings:
aws:elasticbeanstalk:environment:proxy:
ProxyServer: apache
在 AWS Linux 2 上，仅通过将文件添加到代码库来配置 Apache.plaform/httpd/conf.d/，它们将被添加到服务器的 Apache 配置中。您不能再通过编辑 Apache 文件.ebextensions.
要使用 Apache 执行 HTTP 到 HTTPS 重定向，请添加名为的配置文件.platform/httpd/conf.d/ssl_rewrite.conf到您的代码库（相关 AWS 文档 https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/platforms-linux-extend.html）包含以下内容：
RewriteEngine On
<If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</If>
请注意，nginx 可以通过类似的方式进行配置，即添加.conf文件至.platform/nginx/conf.d/（尽管该文件的内容显然会有所不同）。
亚马逊 Linux 1
您需要做的就是将以下内容添加到您的其中之一.config文件在.ebextensions你的项目目录 http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/ebextensions.html:
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 to an <If>块允许它在外部正常工作<VirtualHost>块，允许我们放入独立的 Apache 配置文件。请注意，CentOS 上的标准 Apache 设置（包括 ElasticBeanstalk 上的设置）包括所有匹配的文件/etc/httpd/conf.d/*.conf，它与我们存储该文件的文件路径匹配。
The -n '%{HTTP:X-Forwarded-Proto}'如果您不在负载均衡器后面，则部分条件会阻止它重定向，从而允许您在具有负载均衡器和 https 的生产环境与单实例且没有 https 的临时环境之间共享配置。如果您在所有环境中使用负载均衡器和 https，则没有必要这样做，但拥有它也没什么坏处。
我见过的糟糕的解决方案
我见过很多针对这个问题的糟糕解决方案，值得通过它们来理解为什么这个解决方案是必要的。
-
使用云前端：有些人建议在 Elastic Beanstalk 前面使用非缓存 Cloudfront 设置来执行 HTTP 到 HTTPS 的重定向。这增加了一个不太合适的全新服务（从而增加了复杂性）（Cloudfront 是一个 CDN；它不是在固有动态内容上强制使用 HTTPS 的正确工具）。 Apache 配置是此问题的正常解决方案，而 Elastic Beanstalk 使用 Apache，因此我们应该采用这种方式。
-
通过 SSH 连接到服务器并...：这与 Elastic Beanstalk 的观点完全相反，并且存在很多问题。通过自动缩放创建的任何新实例都不会具有修改后的配置。任何克隆的环境都不会具有该配置。任何数量的合理的环境更改都会消除配置。这真是个坏主意。
-
使用新文件覆盖 Apache 配置：这已经进入了正确的解决方案领域，但如果 Elastic Beanstalk 更改了服务器设置的各个方面（他们很可能会这样做），那么您将面临维护噩梦。另请参阅下一项中的问题。
-
动态编辑 Apache 配置文件以添加几行：这是一个不错的主意。这样做的问题是，如果 Elastic Beanstalk 更改了默认 Apache 配置文件的名称，该文件将无法工作，并且该文件可能会在您最意想不到的时候被覆盖：https://forums.aws.amazon.com/thread.jspa?threadID=163369 https://forums.aws.amazon.com/thread.jspa?threadID=163369
