Jaap Haagmans The all-round IT guy


VPC now supports EIP management on instance launch

Before, it was impossible to specify whether you wanted to use a public (or elastic) IP address when launching an instance in a VPC subnet. That was one of the main reasons I've been unable to create resilient NAT instances without relying on other instances. Either you use a default VPC (I never do) and always have an EIP assigned, or you have a custom VPC and no EIP assigned.

NAT instances are very important in nearly all my setups. But when one fails, the chain of events that follows always depends on other instances. That means that when a NAT instance in AZ 1a fails, the NAT instance in AZ 1b takes over by changing the route table. It also changes the route table for AZ 1a, making the formerly public subnet a private subnet which routes through AZ 1b. When the NAT instance in AZ 1a relaunches through auto scaling, it requests an EIP, attaches it, then changes the route table for AZ 1a back to a public subnet and it will stand on its own feet again. It works, but on failure, the NAT instance in AZ 1b suddenly becomes a single point of failure until someone manually restores service. I've had problems with this setup on some occasions, so I was eagerly waiting for Amazon to come up with a way to simplify this process.

A few days ago, Amazon announced that it now supports EIP management on instance launch. That means that when launching an instance through the console, you can choose whether you want to assign an EIP. They also announced that they're working to support this for the auto scaling service and that's what I've been waiting for. It means that I can relaunch my NAT instance automatically through auto scaling (with a --min-size and --max-size of 1), attach an EIP and change the route table, without relying on a second instance.

Tagged as: , Leave a comment
Comments (0) Trackbacks (0)

No comments yet.

Leave a comment

No trackbacks yet.