This answer assumes you have already enabled https in the load balancer security group, added the SSL certificate to the load balancer, have both ports 80 and 443 being forwarded by the load balancer, and pointed your domain name at the Elastic Beanstalk environment with Route 53 (or equivalent DNS service).

Option 1: Do the redirect with Apache

This is only possible if you are on an Elastic Beanstalk environment that uses Apache. It may not work for a docker-based deployment.

Amazon Linux 2

Most AWS Linux version 2 based platforms have the option to pick Apache as your proxy host. This can be done by going to "Configuration" > "Software" >"Container Options" and setting "Proxy Server" to "Apache".

Having done that, add a configuration file named .platform/httpd/conf.d/ssl_rewrite.conf to your codebase (relevant AWS docs) with the following contents:

RewriteEngine On<If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]</If>

Amazon Linux 1

All you need to do is add the following to one of your .config files in the .ebextensions directory of your project:

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>

Explanation

This is moderately straight forward outside of Elastic Beanstalk. One usually adds an Apache rewrite rule like the following:

RewriteCond %{HTTPS} offRewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Or, if behind a load balancer, like we are in this case:

RewriteCond %{HTTP:X-Forwarded-Proto} !httpsRewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

However, these configurations only work within a <VirtualHost> block. Changing the RewriteCond to an <If> block allows it to work properly outside of a <VirtualHost> block, allowing us to put in in a standalone Apache config file. Note that standard Apache setup on CentOS (including the setup on ElasticBeanstalk) inculdes all files matching /etc/httpd/conf.d/*.conf, which matches the file path where we are storing this file.

The -n '%{HTTP:X-Forwarded-Proto}' part of the condition prevents it from redirecting if you are not behind a load balancer, allowing you to have shared configuration between a production evironment with a load balancer and https, and a staging environment that is single instance and does not have https. This is not necessary if you are using load balancers and https on all of your environments, but it doesn't hurt to have it.

Option 2: Do the redirect with the ALB

This is only possible if you are using an Application Load Balancer. Amazon has instructions for how to do that here: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/configuring-https-httpredirect.html

All you need to do is add the following to one of your .config files in the .ebextensions directory of your project to replace the http listener with a redirect:

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"

Bad solutions I have seen

I have seen a lot of bad solutions to this problem, and it is worth going through them to understand why this solution is necessary.

1. Use Cloudfront: Some people suggest using non-cached Cloudfront setup in front of Elastic Beanstalk to do the HTTP to HTTPS redirect. This adds a whole new service (thus adding complexity) that isn't exactly appropriate (Cloudfront is a CDN; it's not the right tool for forcing HTTPS on inherantly dynamic content). Apache config is the normal solution to this problem and Elastic Beanstalk uses Apache, so that's the way we should go.

2. SSH into the server and...: This is completely antithetical to the point of Elastic Beanstalk and has so many problems. Any new instances created by autoscaling won't have the modified configuration. Any cloned environments won't have the configuration. Any number of a reasonable set of environment changes will wipe out the configuration. This is just such a bad idea.

3. Overwrite the Apache config with a new file: This is getting into the right realm of solution but leaves you with a maintenance nightmare if Elastic Beanstalk changes aspects of the server setup (which they very well may do). Also see the problems in the next item.

4. Dynamically edit the Apache config file to add a few lines: This is a decent idea. The problems with this is that it won't work if Elastic Beanstalk ever changes the name of their default Apache config file, and that this file can get overwritten when you least expect: https://forums.aws.amazon.com/thread.jspa?threadID=163369

EDIT: While I love this answer, it is now very old. AWS has come up with new services (like Certificate Manager) that make part of this answer obsolete. Additionally, using the .ebextensions folder with Apache is a cleaner way to handle this redirect as explained above.

If you are hosting your website on S3, parts of this answer may still be useful to you.

This worked for me:

1. Upload the certificate to AWS using the aws console command. The command structure is:

   aws iam upload-server-certificate --server-certificate-name CERTIFICATE_NAME --certificate-body "file://PATH_TO_CERTIFICATE.crt" --private-key "file://YOUR_PRIVATE_KEY.pem" --certificate-chain "file://YOUR_CERTIFICATE_CHAIN.ca-bundle" --path /cloudfront/

2. In your Elastic Beanstalk application, go to Configuration -> Network Tier -> Load Balancing and click the gear icon.

3. Select Secure listener port as 443. Select Protocol as HTTPS. Select the CERTIFICATE_NAME from step 2 for SSL certificate ID. Save the configuration.

4. Go to your Console. Click EC2 Instances. Click Load Balancers. Click through the load balancers. Click Instances and scroll down to see the EC2 instances assigned to that load balancer. If the EC2 instance has the same name as your Application URL (or something close), take note of the DNS Name for the load balancer. It should be in the format awseb-e-...

5. Go back to your Console. Click CloudFront. Click Create Distribution. Select a Web distribution.

6. Set up the distribution. Set your Origin Domain Name to the load balancer DNS name you found in step 5. Set the Viewer Protocol Policy to Redirect HTTP to HTTPS. Set Forward Query Strings to Yes. Set Alternate Domain Names (CNAMEs) to the URL(s) you want to use for your application. Set SSL Certificate to the CERTIFICATE_NAME you uploaded in step 2. Create your distribution.

7. Click on your distribution name in CloudFront. Click Origins, select your origin, and click Edit. Ensure your Origin Protocol Policy is Match Viewer. Go back. Click Behaviors, select your origin, and click Edit. Change Forward Headers to Whitelist and add Host. Save.

Note: I wrote a longer guide as well.

With the new Application Load Balancers you can do this fairly trivially now...

Ensure you setup one of these at the time you setup an EB environment (still defaults to classic load balancer I believe). You could not change the type once the environment is created, so recreate it

Once this is done, go to your EC2 settings -> Load Balancers. Click on the load balancer you created for your EB environment. You must ensure that you have setup a HTTPS listener prior to this task so make sure you listen on HTTPS 443 with an SSL cert and forward traffic to your instances with HTTP on 80.

Then add a new listener which listens on HTTP and add a default action of "Redirect to:". Make sure you set HTTPS as the protocol, 443 as the port, "Original host, path, query" as the option and finally 301 as the HTTP response code.

Once this listener is added ensure that you update your EC2 Load Balancer security group to accept both HTTPS and HTTP connections, you will see small warning sign on the listener to remind you!

Chris