Setting up HTTPS with Amazon AWS for dummies

Question

I run an Amazon AWS setup for a web page I host. It uses a single EC2 instance, and works fine over HTTP. But recently I have a need to also offer up HTTPS. And this is where I'm totally confused. The EC2 instance is running Apache, PHP, and MySQL on a Linux

I somewhat get (in the abstract) how HTTPS works in the non-AWS world. (I've never done it.) But I gather that isn't the best way to do it with AWS, which seems to involve setting up something in the Certificate Manager and then hooking up an Elastic Load Balancer to it. I'm kind of at a loss.

I've created a certificate successfully in the Certificate Manager. I set up a ELB with a "target" group that seemed to be right, and hooked it up to the certificate. When I try to add https:// in front of my host, it says the server refuses to connect. When I go into the ELB itself and access the URL it gives me for the ELB, I get an Error 503 Service Temporarily Available.

I think I may just not be understanding this right, and the AWS/HTTPS posts on here all seem to assume you know what you're trying to accomplish. Could someone just lay it out for me how these things (the certificate, the ELB, the EC2 instance, and Apache) are all meant to be linked together? Thank you.

Answer 1

Firstly, don't feel as if you have to go down the Amazon Certificate Manager (ACM)/Load Balancer route. It is a good solution, but it is designed for situations where you have a few servers behind load balancers, rather than a single stand alone instance.

Another potentially cheaper option could be to use Cloudfront in front of your site, with an ACM certificate, or use Lets Encrypt on the instances itself.

That said, you asked about LBs, so here we go:

If you are new to load balancers in AWS, you first must understand there are two types: ELB and ALB.

ELB (Elastic Load Balancer) are the old 'classic style' load balancer, which basically relays the connection through the balancer, without doing any fancy logic. You throw it in front of any number of instances, and you go through to a random server in the pool.

ALB (Application Load Balancer) are a little more complicated, in that they can do some application logic routing. When using ALB you define Target Groups, as well as routing rules, which mean you can send traffic to different sets of instances depending on the requesting path. ALB can be used in a similar way to ELB, and AWS appears to be pushing their use.

Regardless of which type of LB you use, you are still putting a balancer in front of the instance, which relays traffic to the source machines.

HTTPS/SSL complicates things a little bit when talking about AWS LB, as they are configured in slightly different ways.

If you are using ELB, the listeners tab in the AWS interface lets you configure the port mapping. This is where you map 'what people request' to 'where is it coming from'. In this case, you would probably want 80 -> 80, and 443 -> 80. As you want to listen for both http and https, but only connect to http on the server, as it doesn't have https. For a more advanced and secure configuration you could install an self signed certificate on the server to encrypt the connection end to end, and then use 443 -> 443.

If you are using ALB, the listeners tab will again map 'what people request' to 'where it is coming from', but instead of just mapping ports, it maps to 'Target Groups'. In most situations, the effect will be the same as ELB, you are piping both port 80 and 443, to a single target group.

The ALB interface basically pulls out part of the ELB interface on to it's own page, but both ELB and ALB try to achieve the same thing here, defining instances/targets and health checks. Unless you have valid targets and health checks you will get 503 errors.

With ELB you define which 'instances' to look at. The instance tab will show the 'Status', which is basically whether the ELB will route traffic to it or not. This should be 'InService', on at least one instance, or you get 503. If you get any other status, try waiting a few minutes for it to settle down, if it doesn't update to InService, you have something wrong with your instances, or you haven't configured a valid health check.

With ALB, Targets are defined in the same way. The main difference is that you define the port you want to connect to your instances on, in addition to which instances you want to connect to. The most common way to configure this, is to point at the instances on port 80, as this is what most webservers are running on, although like in the ELB case, to enhance security, you might want to use HTTPS on the instances using self signed certs to keep everything encrypted end to end.

Similar to with ELB, your most important bit of information here is the target status, in this instance, you want to see 'healthy'. If you don't see this, wait a little while, or investigate your health checks.

Both ALB and ELB, rely on Health checks to know if they should route traffic to your instances. This is usually somewhat simple. Most people will configure health checks to point at a fairly simple page, something on your website, or the root of your site that is very quick to load, as AWS will hit it multiple times a minute. An instance will only get forwarded traffic, if it passes the health checks. The default is to hit the root of the website. Tweaking these options to best match your site is important. I will often set the healthy threadshold to minimum, to get my servers serving traffic as quick as possible, and reduce the polling interval to something quicker.

Answer 2

If you run a single ec2 instance there is IMHO no need to use ELB. If you want to use ELB follow this guide.

If you want to directly connect to your ec2 instance without ELB setup https on your Apache like this:

LoadModule ssl_module modules/mod_ssl.so

Listen 443
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    SSLCertificateFile "/path/to/www.example.com.cert"
    SSLCertificateKeyFile "/path/to/www.example.com.key"
</VirtualHost>

Take a look at the documentation for detailed instructions.

Most likely you have eitherconfigured https wrong on the ELB side or you are trying to connect to your instance over https with the IP of the instance not the ip of the ELB.