Cloud Developer Tips

Use ELB to Serve Multiple SSL Domains on One EC2 Instance

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!

30 replies on “Use ELB to Serve Multiple SSL Domains on One EC2 Instance”

[…] easier for me to manage a single host and domain, especially since the move to EC2, considering you can’t host multiple SSL sites on a single IP address without ELB which seems like […]

Ahh but now that there are t1.micro instances costing $0.02/hour ($0.013 broken out over a year with a reservation!), this comes back into question again!

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.


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.


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.


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.

The ideal case would be to have ONE single machine/load balancer hosting multiple SSL certificates. Unfortunately, it’s not the case. It turns out to be very expensive to support SSL for multiple domains using AWS. And that’s sad.

@Rafael Barbolo,

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?

It is “very expensive” because all of those ELB hours are required in the first place. If one could simply bind two sets of public addresses to one ELB, you’d be able to host many SSL certs for minimal (or no) additional cost.

I guess it depends on your business model. I can certainly imagine that if there were a way to associate infinite IP addresses with one ELB for free, some people might find a reason to associate hundreds (or even thousands). That would certainly cost a pretty penny when sold as one-IP-per-ELB.

The cost of an IPv4 address is about 1 USD/month in most hosting companies. The cost of an ELB machine is about 20 USD/month. As Eric said, it could be cheaper if attaching EIP to ELB was achievable.

It’s difficult to explain to our clients that they have to pay much more for hosting the SSL than to acquiring it.

Thanks for the article James,

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 Preisler,

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.

Hey Shlomo,

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.


I’ve found that ASG’s handle several ELBs quite well, up to a certain limit.

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.

I guess AWS Certificates will help solve the issue now. So easy and cheap to create multi domain certificates.

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

I’ve struggled with this for a long time, and we’ve used the multiple eni method on an instance running HAProxy and Apache as the SSL terminator. HAProxy receives all front end traffic, then routes port 80 traffic to the ASG over 8080, and routes 443 traffic to Apache on another local port, which terminates the SSL, and then continues on to 8080.

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!

Leave a Reply

Your email address will not be published.