This is one of the coolest uses of Amazon’s ELB I’ve seen yet. Check out James Elwood’s article.
You may know that you can’t serve more than one SSL-enabled domain on a single EC2 instance. Okay, you can but only via a wildcard certificate (limited) or a multi-domain certificate (hard to maintain). So you really can’t do it properly. Serving multiple SSL domains is one of the main use cases behind the popular request to support multiple IP addresses per instance.
Why can’t you do it “normally”?
The reason why it doesn’t work is this: The HTTPS protocol encrypts the HTTP request, including the Host: header within. This header identifies what actual domain is being requested - and therefore what SSL certificate to use to authenticate the request. But without knowing what domain is being requested, there’s no way to choose the correct SSL certificate! So web servers can only use one SSL certificate.
If you have multiple IP addresses then you can serve different SSL domains from different IP addresses. The VirtualHost directive in Apache (or similar mechanisms in other web servers) can look at the target IP address in the TCP packets - not in the HTTP Host: header - to figure out which IP address is being requested, and therefore which domain’s SSL certificate to use.
But without multiple IP addresses on an EC2 instance, you’re stuck serving only a single SSL-enabled domain from each EC2 instance.
How can you?
Really, read James’ article. He explains it very nicely.
How much does it cost?
Much less than two EC2 instances, that’s for sure. According to the EC2 pricing charts, ELB costs:
- $0.025 per Elastic Load Balancer-hour (or partial hour) ($0.028 in us-west-1 and eu-west-1)
- $0.008 per GB of data processed by an Elastic Load Balancer
The smallest per-hour cost you can get in EC2 is for the m1.small instance, at $0.085 ($0.095 in us-west-1 and eu-west-1).
Using the ELB-for-multiple-SSL-sites trick saves you 75% of the cost of using separate instances.
Thanks, James!
Comments
Eric —
Then again
a) the bandwidth is cheaper and b) t1.micro instances definitely have less load capacity than an ELB instance c) No redundancy at that price.
shlomo —
Indeed. Running your application on four t1.micro instances is still cheaper than using a single m1.small. But only certain types of applications are OK on t1.micros because of the CPU throttling.
Eric —
To be clear, I meant specifically that you would use t1.micros to host your own load balancer. The application would presumably be hosted on some more powerful instance.
shlomo —
Ah, yes, thanks for setting me straight. Running a software load balancer on your own t1.micro might seem inexpensive as compared to ELB, but it has its caveats.
If you are debating whether to manage your own load balancer (DIY - do it yourself) vs. using ELB then you need to consider: a) whether you will actually require the elasticity ELB provides - that is, whether your load can be expected to have much static range or dynamic range (to borrow vocabulary from photography) b) your cost of labor for the operational skills required (troubleshoot problems, fix ’em, roll out the updates, etc.) c) the technical debt incurred by using a homegrown (read: error-prone) system as opposed to a more mature offering with a record of reliability d) the relative cost of the computing resources for each solution.
In most places in the US and EU, item (b) tends to tip the scale overwhelmingly away from DIY. In most companies where agility is a priority, item (c) also tips the scale away from DIY.
Sounds like material for another article.
Rafael Barbolo —
Shlomo Swidler —
Using multiple ELBs to support SSL for multiple domains is not “very expensive.” It’s the cost of the extra ELB-hours (because you’re likely already using en ELB in front of the web servers anyway). Can you explain what you mean?
Eric —
Shlomo Swidler —
Eric —
Rafael Barbolo —
It’s difficult to explain to our clients that they have to pay much more for hosting the SSL than to acquiring it.
Shlomo Swidler —
If I were AWS I’d add support for this use case to Route53.
Rafael Barbolo —
KJ —
Shlomo Swidler —
Thanks for the pointer.
Klaus Preisler —
From a tech perspective this makes all the sense in the world. But from a operations perspective, why do I need to worry about that? What people are actually asking for is how to have a concept of doing operations like adding and removing instances on multiple ELB’s.
Kudos for an awesome service Klaus
Shlomo Swidler —
Comments on James’ original article are unfortunately closed. In James’ comment dated July 15 2010, he shows that the CLI can be used to add instances to multiple ELBs. The same tools can be used to remove instances from multiple ELBs.
Arlington Albertson —
While this is a great trick, there is actually an easier and, IMO, better option. I don’t remember exactly when they introduced it, but ELB’s can terminate SSL/HTTPS now. The method I use is to have the listeners accept the 443/HTTPS traffic and respond with a cert that I have uploaded. They then forward requests back to the webserver on port 80. Then you can use your normal rewrite/redirection rules to split traffic based on domain, etc…
This works fantastically and removes any CPU load from the webserver for having to support the encryption/decryption process of SSL certs.
A bonus method is you can do the same thing with CloudFront (for free to boot! not counting CF prices) and have an even better outcome as you further reduce your network load.
-AA
Shlomo Swidler —
AWS added support for ELB SSL termination in October 2010. But the underlying problem of hosting multiple SSL domains on a single instance still requires one of the following:
Jim Freeman —
Shlomo Swidler —
Yes. But you would need to manage each instance’s membership in the ELBs yourself, as ASGs are built to work nicely only with one ELB.
Arlington Albertson —
When you hit upwards of 40 of them, then you definitely can start to have issues as you have contending healthchecks and validations of instance registration with the ELB, but 40 was functional. AWS themselves recommend no more than about 24~, but I’ve successfully been able to squeeze 40 out of them without too much trouble. When I tried 80, that was a different story, you could almost never keep healthy instances, learned the hard way.
Incidentally, now that CloudFront has released SNI support, which gives you free SSL cert support (unless you need to support legacy windows XP/IE clients), I find that to be far more sustainable and useful as I then only have multiple ELBs for distribution of ELB capacity (a quick and dirty trick to help get around the burst scaling problem ELBs inherently have) and run everything[EVERYTHING] through CloudFront.
NOTE: The cloudfront trick works best if you have lots and lots of traffic so that you can negotiate a custom price with your account rep. However, in general, the costs for CloudFront data are cheaper than EC2 transfer. This has the side benefit of reducing load on the ec2 instances as well because you are opening less TCP connections; also you are then running on AWS owned infrastructure and data pipes all the way to the edge.
Shlomo Swidler —
Jeff —
Shlomo Swidler —
Thanks for pointing that out. I edited the post to point to the version of James’ article from the Internet Archive.
Alex Sroussi —
For our case, we do not have to handle 2 or 3 different certificates and domains, but hundreds. Obviously, creating a separate ELB for each one isn’t an option at 18$ each one. Multiple domain certificates using AWS Certificates helps, but a SSL certificate cannot be edited so I cannot add new domains to existing certificates. Renewing certificates isn’t a good option too operation wide, because it requires revalidating each domain (by clients), and if I merge 2 ELBs, clients also need to change their DNS to the new ELB (it’s their domain, not in my Route53).
The best option definitely would have been to enable multiple SSL endpoints in a same ELB. Still looking for the best solution
Kevin Farley —
This was great, except, it was still coming down to a cost of about $5 / mo per domain because of the limits of IP’s on instances and the associated instance costs. Worked, but not ideal by any stretch.
The good news is that Poodle finally killed SSL, and so now that we’re all on TLS which by extension forced older browsers to upgrade to remain compatible, we now have universal support for SNI. In other words, unlimited Certificates on a single IP.
In the mean time, HAProxy 1.5 now supports SSL Termination directly, so no need for apache routing anymore, and we also now have “Letsencrypt” which can issue free validated certificates automatically. Voila, small EC2 instances, single IP’s, auto installation of certs, and universal encrypted support for all clients on a single, or redundant pair, of LB’s!
Ramesh —