This is definitely a useful feature (even more powerful when combined with route53); and $44 a year per IP address isn't too shabby either. I'm curious if this is a way to try to stay ahead of Azure's plans to try to corner hosting with their Web Sites feature (eg http://blog.ntotten.com/2012/06/08/three-more-things-about-w... )...
I read that link and I'm wondering what I'm missing?
This looks like some attempt by Microsoft to compete with low-end shared hosting, right? Amazon has never been in that market, and has never shown any interest in heading that way.
Additionally, it isn't clear why anyone would choose Azure for that if they were building a website from scratch.
The only compelling use-case seems to be people who have a .NET website they need hosting for (.NET hosting doesn't seem as competitive as other environments). Yes, Azure does support other environments, but there isn't anything particularly compelling about Microsoft's offering for anything except .NET. If you add in a reserved instance even the pricing isn't very good.
Using ELB to achieve this means they are doing SSL termination on the ELB itself which means the request is no longer encrypted within heroku, unless of course they are using another cert for the connection between ELB->dynos.
But if the instances also live on ec2 (which they do in the heroku case), you would still run into the issue of needing separate instances to terminate SSL on for each SSL enabled site (with the 1 IP limit). It would seem much more economical for them to terminate at the ELB level and only pay for an ELB per customer.
I guess alternatively you could leverage the funky port forwarding hack on elb and put each ssl site on a different backend port. but that just seems like a mess.
One issue I have with VPC is that instances don't get public IPs by default like public cloud instances do. Instead you have to attach EIPs, which has extra complexity (esp. taking care to deallocate them if you don't care about persistence), and you're limited to only 5 EIPs by default. I know you can request to increase the limit, but I have no idea what the approval process is like, and it seems completely silly when you can get as many public IPs as you want by launching multiple public cloud instances.
(If you're curious, my architecture requires hosts outside of AWS to connect directly to EC2 instances. Using a NAT box inside VPC would likely introduce a bottleneck. I don't need multiple IPs per instance, but I just wanted to provide some feedback as to why VPC with an Internet Gateway feels inferior to public cloud EC2 for me. Thanks!)
The main reason I can think of is the single point of failure in regards to a NAT instance. With the only other alternative being giving EIPs to every host that needs internet access. I would like to see a more robust solution and HA for the NAT instance. Especially if you're doing any kind of heavy proxying, couldnt you max out the NAT instance's uplink at some point? Anyone have ideas?
My scenario was load testing, to generate 1M outgoing connections we need 17 IP aliases, aliasing doesn't work on EC2, so we had to spawn 17 instances just for this.
I didn't tried elastic IPs for this, not sure it will work for outgoing connections.
