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!
{ 2 trackbacks }
{ 4 comments… read them below or add one }
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.
@Eric,
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.
Shlomo,
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.
@Eric,
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.