1

I'm setting up server that will host multiple SSL domains across a wide range of load balanced EC2 instances and being a programmer who really sucks at network/infrastructure stuff I had some questions:

I'm assuming that by using ELB I only have to setup HTTPs one time under the ELB and install the certificate there and not on the actual instances?

For SSL, do I still need separate IP addresses for each site when using ELB or does the communication from ELB to the instance run over HTTP?

What's the best way to point the websites to the elb? CNAME record to the amazon ELB instance name?

Should I be using a loadbalancer for this, am I on the right track here?

I am completely open to any other suggestions/help on this issue.

Thank you for your help.

FAtBalloon
  • 279
  • 1
  • 4
  • 12
  • http://stackoverflow.com/questions/27521758/multiple-domain-names-attached-to-same-load-balancer-as-alias-records – Shatiz Aug 12 '15 at 01:17

2 Answers2

1

You are on the right track.

ELBs can be SSL termination proxies. In this scenario you set up HTTPS one time on the ELB and install the certificate there and not on the instances.

Traditionally for SSL you needed the web server name to match the CN in the cert. This hasn't been the case for a while now. See http://en.wikipedia.org/wiki/Secure_Sockets_Layer#Support_for_name-based_virtual_servers So no, in no case do you need, including ELB terminated SSL, separate IP addresses for each site.

You can configure the ELB to terminate SSL and speak HTTP to the instances.

It is Amazon's strong recommendation that your website CNAMEs to the ELB instance name (or names, multi-AZ ELBs return 1 name per AZ). The IP addresses can change, especially if you ELB is very E due to traffic spikes.

I would also look into "DNS Failover for Elastic Load Balancing" if you ELBs are going to be multi-AZ.

I strongly recommend you read Amazon's documentation on ELBs http://aws.amazon.com/elasticloadbalancing/ . All these questions are answered--and more!--are answered there and there are best practices. This will be better than gaining a piecemeal understanding through Serverfault questions. (Certainly if you want clarification on the docs SF may be a good place to ask a question.)

Mark Wagner
  • 18,019
  • 2
  • 32
  • 47
  • Mark, thank you so much for the insightful answer. Question for you about the CNAME to ELB. I saw that you can create a CNAME for your www.mydomain.com and then create an Alias 'A' record in Route 53 for mydomain.com. So what if I'm not using Route 53 for DNS? Do I just create a CNAME and not worry about the 'A' record? Or how should I handle this since you can only typically point an A record to an IP address? – FAtBalloon Mar 28 '14 at 14:57
  • If you're not using Route 53 for DNS, you basically can't use SSL ELBs for your naked domain. You'll have to handle it some other way, typically by serving a 301 redirect from `http://example.com/` to `https://www.example.com/`. – Mike Scott Jul 23 '15 at 17:12
0

It appears that ELBs can only handle a single certificate.

If you are using a wildcard certificate, and all domains are covered by the wildcard, or if you are using a multi-domain certificate (also called UCC certificate), that can also be used.

Otherwise, if you have multiple certificates for multiple domains, your options are:

Certificates on ELBs, one ELB per certificate

Under this scenario, each certificate gets its own ELB. The ELBs still point to the same instances. You install the certificate on the ELB and it handles SSL termination.

Pros: much easier when certificates are revoked/replaced/updated. Also frees instances from managing SSL connections. Theoretically it is also more secure, since most likely the ELBs are going to be less open to potential vulnerabilities.

Cons: more expensive (one ELB per certificate instead of just one ELB). Autoscaling may be unpredictable, with an autoscaling group associated with one ELB potentially making different decisions than an autoscaling group associated with another ELB.

Certificates on Instances

Have the ELB pass through the SSL request rather than terminating it. You install all the certificates you need on each instance and set them up to listen to port 443 and handle secure connections.

Pros: probably slightly cheaper even with the increased load from SSL processing. More control over what is going on with your instances.

Cons: Really time consuming to update certificates when they are revoked/updated/created. You have to add certificate deployment to your deployment process. If your instances launch from AMIs and the certificates are stored on the AMI, you have to generate a new AMI with those certificates and terminate the instances with invalid certificates. If you have only a couple of instances, replacing the certificates manually on each instance using rsync or scp is an option but a pretty ugly one.

Community
  • 1
Jordan Reiter
  • 1,290
  • 4
  • 20
  • 40