Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We've had our NAT server fail 3 times thus far - once due to an issue with it's EIP and twice due to it's host being CPU bound. While I understand these things happen, we can't afford to keep taking the outages. How can we implement a redundant, resilient NAT solution for our VPC? For example, is it possible to utilize multiple NAT servers?

My VPC (Amazon Virtual Private Cloud) consists of 2 subnets, 1 public and 1 private. Instances in the private subnet route through a NAT server in the public subnet. From what I've read, you can only have 1 NAT server per VPC.

share|improve this question

Given your updated question you are presumably using the official Amazon Linux AMIs configured to run as NAT instances ('ami-vpc-nat') and setup according to NAT Instances? This is obviously not required, but provides a sound baseline to achieve the desired stability of course. Regarding your question:

Fortunately AWS has recently announced Elastic Network Interfaces in the Virtual Private Cloud, which allows you to Create a Low Budget High Availability Solution (please refer to the Elastic Network Interfaces user guide for details):

If one of your instances [...] fails, its network interface can be attached to a replacement or hot standby instance pre-configured for the same role in order to rapidly recover the service. For example, you can use an ENI as your primary or secondary network interface to a critical service such as a database instance or a NAT instance. If the instance fails, you (or more likely, the code running on your behalf) can attach the ENI to a hot standby instance. Because the interface maintains its private IP address, elastic IP address, and MAC address, network traffic will begin flowing to the standby instance as soon as you attach the ENI to the replacement instance. [...] [emphasis mine].

So you should be able to achieve your goal with a modest amount of automation code - depending on how much you value redundancy/resiliency you have two options:

share|improve this answer
Setting up an Auto Scaling Policy unfortunately doesn't work in this case. It is not possible to attach a pool of EIPs to an auto scaling group, so in case of a failure the newly spun up instance won't be able to connect to the internet. This also means that the NAT instance can't connect to the AWS API to obtain an EIP. Disabling the source/dest check is also not available (yet?) for auto scaling groups. – sborsje Jan 25 '13 at 11:30
@sborsje - thanks much for your insight (a significant oversight of mine indeed), I've updated the post accordingly. – Steffen Opel Jan 25 '13 at 11:48

Your questions is too vague and too broad. You need to provide more information about your set up, what it does and what you're trying to achieve.

But it looks like what you're looking for is load balancing. Take a look at haproxy:

share|improve this answer
Thanks for the reply, I've updated my question with info regarding my set up. – cjs226 Jan 26 '12 at 22:11

You can have multiple NATs per VPC. You can configure your VPC route table to point the 0/0 route to the network interface of the NAT server. if that NAT instance takes a dive, you can detach that network interface from the instance and attach it to a hot standby NAT instance. That will get you up and running again with only a small blip in traffic.

ELB won't help you with what you're trying to do.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.