Recently, we reworked our web frontend infrastructure to separate our corporate website from the Silentale web application. The main goal was to make sure we don’t have to involve our operations resources (a.k.a … me ) too much when we update our corporate web site …

This involved setting up a few new virtual hosts and names:

• http://silentale.com and https://silentale.com for static web pages
• https://my.silentale.com for the application (that’s where you are logging in now, dear beta users !)
• https://api.silentale.com for the firefox extension and all the future nifty stuff that we are preparing for our users’ christmas

My original idea was to use virtual servers, and have the web servers running from the same host. I had prepared all the necessary valid certificates and DNS configuration, the configuration for nginx was ready and working, but I had forgot one little problem with SSL and virtual hosts: as the server tries to retrieve which virtual server should respond to the request by reading the value of the Host: request header, the SSL connection must have already been established, therefore a proper certificate must have been presented to the client, and nginx cannot decide which one to send (as it can’t read the Host: header) !

Ok, i’m dumb, and I shouldn’t forget you can’t host serveral SSL servers with different names from the same IP address unless you buy one of these expensive wildcard certificates (buying certificates is as close to extortion as to ‘renew’ a domain name or trying to use one of these “limited unlimited 3G+” offers, but that will be the subject of another post …)

Listening to different ports ?

I could have decided to make the servers listen to different ports, but

• our platform is getting more and more complex, and we’d rather avoid doing that sort of things
• we don’t want to confuse our users (and especially the new beta users who have to get a very good impression of our service) with TCP ports that could be filtered on their end …

Off to elastic IP ?

Amazon web services provide a very useful tool for web servers which they call Elastic IP. You reserve a static, public IP address in their subnet, and you can seamlessly attach it to any instance. You can switch it from instance to instance, and in a matter of seconds, the new server will be reachable on this address, without you having to update DNS record or incur any downtime to your users. Very cool stuff when upgrading or migrating !

So my problem could have been solved if i could assign multiple elastic IPs to the same EC2 instance, and make each of my SSL servers listen on each one of them … unfortunately, you just can’t do that . An EC2 instance gets an address on a RFC1918 subnet, and that’s the only one you can see from it. In order to be able to connect to it, amazon creates some sort of reverse NAT between the outside world and your instance (i’d like to know how they handle that in their border routers. It must be really interesting and challenging to operate )

Several instances …

So, in our case, the only proper solution is to start 3 instances when we could have used only one . This is really fustrating and unfortunate … If you came across the same problem on AWS and have found a better solution, i’d be very happy to hear about it.

If someone from Amazon reads me, this feature isn’t critical, but it prevents any kind of mutualization on your cloud. I don’t think it is part of your core business, but it may represent a significant share of it in the future (low cost hosters, etc …)