The new AWS Default VPC and Auto-Scaling: A very good match

The new Default VPC

A few months ago, Amazon introduced the new Default VPC concept, basically aiming to bring the powerful features of VPC to all EC2 users.  

As a quick digest, Amazon creates a default VPC for each region in your account. Any server that you launch into that region (unless you state otherwise) will be launched within that default VPC and automatically get a public IP on top of the usual private IP that typical VPC servers receive (and this is the main difference from non default VPCs).

You can read more about default VPCs here

And don't forget to check if your AWS account supports the new style default VPCs  (only available in regions into which you have done no activity).

Problems with Old Style VPCs and Auto-Scaling

Now you most probably have read about this but in certain situations it was not easy to deploy auto-scaling for your servers.

The typical situation that we have seen at Cloudways:

  • A customer (i.e. web store) needs auto-scaling to adapt to peaks in traffic (basically the raison d'etre of auto-scaling).
  • Their web server farm need to initiate outgoing connections for some reason (i.e. to a payment provider or to a third party service).  
  • For security reasons, they want (or the third party service imposes) to filter IPs to access the service.  

Now this is not something completely out of the ordinary and a requirement we have seen quite a few times.  

So which are the problems with old style VPCs and these specs: 

  • For a server in an old style VPC to have direct access to the internet, you need to map an EIP (Elastic IP) to it.
  • Otherwise, if you don't want/can't assign an EIP, you need to define a NAT device that will act as a gateway to the Internet and make it the default gateway of your server.
  • Additionally there is no easy/automatic way to assign an EIP to instances launched via auto-scale process.  

So, all in all, the only real solution for the not so strange user case above was to setup a NAT device, make this NAT device the default gateway for all the auto-scaled web servers in the farm and share the IP of this NAT device with the third party service provider.  

Not very good as you are introducing a single point of failure in the form of a NAT device and also the NAT device itself can be a bottleneck depending on the amount of traffic it needs to deal with.  

How New Default VPCs Can Help Us

So, as I said above, each new instance launched within a default VPC is AUTOMATICALLY paired with a public IP and this applies too to auto-scaled instances.

This means that we don't have any problem if our web instances are starting outgoing connections, they can do it right away as they have a public IP paired to them. Goodbye NAT device, single point of failure and bottleneck:

As for the IP filtering issue, agreeing that the solution is not too elegant or extremely secure, the only approach we have found is providing third parties that ask for it with the full range of public IPS for the AWS region we have deployed our instances into. You can find a list with the blocks of public IPs for each AWS region here.

This may be too open for some usages and then the only real alternative is to use a NAT device as explained above and provide High Availability for it if a single point of failure is something you can't afford.  

Surely, we can wait for AWS to add functionality to the auto-scaling service to automatically assign EIPs to new instances launched within the auto-scaling group, but I fear this is something that will never happen.  

Let me know if you have any questions/comments.