AWS Static IP – How to Assign a Static IP Address for Outgoing Traffic from AWS Autoscaling Group

amazon-elastic-ipamazon-vpcamazon-web-servicesautoscalingelastic-beanstalk

I'm going to have a number of EC2 instances in an Elastic Beanstalk autoscaling group in a default subnet in a VPC. The app on these EC2 instances needs to connect to a third party service who uses an IP address whitelist to allow access. So I need one or more static IP addresses that I can give to this service provider so they can be added to the whitelist. My understanding is that the only way to get a static IP is to get an Elastic IP address. And I can only associate the Elastic IP with one EC2 instance at a time – I can't associate it with my whole subnet or internet gateway (is this correct?). So do I need an Elastic IP for each EC2 instance, so each instance can be separately whitelisted? How would that work if the autoscaling adds another instance? Should I have one EC2 instance with an Elastic IP, and route all the outgoing traffic via that instance? If so, does that instance need to be solely for this purpose or can it be one of the instances that's running my app?

Best Answer

You need a NAT. This configuration is commonly used to support private subnets in VPC, there's quite a detailed guide here. Once your VPC is configured to use the NAT instance all the outbound traffic will be attributed to the EIP of the NAT instance.

If so, does that instance need to be solely for this purpose or can it be one of the instances that's running my app?

Technically you probably could, but it's not a good idea:

  • It's good security to have roles isolated.
  • You want your application servers to have similar or identical load profiles. If one instance has an extra 10% load because of the NAT then you'll have to scale up prematurely when you hit the limits of that instance. This will get worse as the NAT gets busier as more instances get added to your cluster.
  • You want your application servers to be identical and ephemeral so you can tear them down and/or replace them whenever there's an issue or you need to scale. Having one application server which is different to the rest would be a major headache.

You might be able to get away with it if your instances are containerised but it's still probably not a great idea.

Also keep in mind that your NAT instance could be a single point of failure, so you may want to think about redundancy.

Related Topic