Floating IPs and Failover on Developer Clouds

The Address Has to Outlive the Server

A server dies. You have a second one, already configured, already holding a copy of the data. The only thing standing between you and a two minute outage is that the world knows your service by an address which belongs to the machine that just stopped responding.

Changing DNS is the obvious move and the slow one, because resolvers and clients cache records for as long as the time to live allows, and some ignore it entirely. Rebuilding the dead server takes longer still.

A floating address solves this at the network layer. It is an IP address that belongs to your account rather than to any particular instance, and you can move it from one instance to another with an API call. The clients never learn anything; the packets simply start arriving somewhere else.

This article covers what those addresses are called at each provider, how to move one correctly, how to automate the move, and, just as importantly, which failures a floating address does not solve.

What You Are Actually Reserving

Ordinarily a public address is allocated when an instance is created and returned when it is destroyed. A reserved or floating address breaks that coupling: the provider allocates it to your account, you attach it to an instance, and detaching it does not release it.

Two implementation styles exist, and knowing which one you have determines how much work failover takes.

In the routed style, the provider routes the address to whichever instance currently holds the assignment. The guest operating system needs no configuration at all. DigitalOcean reserved addresses work this way, using a separate anchor address on the instance interface to carry the traffic.

In the configured style, the provider routes the address to the instance but the guest must also add it to a network interface, typically with a netplan entry or an ip addr add command. Hetzner floating addresses work this way. The extra step is easy to forget, and the symptom is an address that is assigned in the control panel while nothing responds on it.

Either way, the address is bound to a location. A floating address lives in one region, and often one zone, so it is a tool for surviving the loss of an instance rather than the loss of a data center.

The Same Feature, Seven Names

Read your provider's page before designing around it, because the details differ in ways that matter. The Hetzner floating IP documentation spells out the in-guest configuration, and the DigitalOcean reserved IP documentation describes the anchor address model.

Charging models differ too. Most providers charge nothing while the address is attached to a running instance and charge a small amount while it sits idle, which discourages hoarding addresses. Check before reserving a dozen.

Moving the Address by Hand, Then by Script

Do it manually once so you know the sequence and can time it. On Hetzner the move is hcloud floating-ip assign 12345 web2 followed by bringing the address up on the new host; on DigitalOcean it is doctl compute reserved-ip-action assign 203.0.113.10 <droplet-id>. Both complete in seconds.

Three details decide whether the failover is clean.

The service must already be running on the standby. If the application starts only when the address arrives, you have added startup time to your outage. Run it continuously and let the address decide who receives traffic.

The application must bind to all addresses. A process bound explicitly to the old primary address will not answer on the floating one. Bind to the wildcard address, or add the floating address to the interface before the service starts.

Existing connections do not survive. The move is not a handover; open TCP sessions to the failed host are gone. Clients must reconnect, which is fine for HTTP and worth testing for anything long lived.

Automating the Failover

On a traditional network, two servers negotiate ownership of a shared address with VRRP, usually through keepalived, and the takeover happens without anyone calling an API. Cloud networks generally do not forward the multicast and gratuitous ARP that this relies on, so the classic recipe does not work unmodified.

The adapted pattern is well established. Run keepalived on both nodes in unicast mode so the peers exchange heartbeats over the private network directly. Configure a health check script that tests the actual service rather than the machine. When a node becomes master, its notify script calls the provider API to assign the floating address to itself, and where required brings the address up on the interface.

Three rules keep this from causing more outages than it prevents:

• Check the service, not the host. A machine that pings while the application returns errors should fail over. A health endpoint that touches the real dependencies is the right test.
• Require several consecutive failures. A single missed check during a network blip should not move anything. Failing over and back repeatedly is worse than a short outage.
• Store the API token narrowly. The credential on each node needs permission to reassign one address and nothing else. The secrets guide covers where it belongs.

Run the peer heartbeat over the private network described in the private networking article, so a public network problem does not convince each node that the other has died.

What a Floating Address Does Not Give You

It does not replicate your data. If the standby has a stale database, failover moves your users onto stale data very efficiently. The replication design is the hard part and the address is the easy part.

It does not prevent split brain. Two nodes that cannot see each other may both decide they are primary. Only one will hold the address, which limits the damage for inbound traffic, but both may still be writing to storage or sending outbound requests. Serious setups add fencing, so a node that loses the election is stopped rather than trusted.

It does not distribute load. One instance holds the address at a time. If you want traffic spread across several healthy backends, that is a load balancer, and the load balancer article covers the difference.

It does not survive a regional failure, since the address is tied to one location. Cross-region failover means DNS with a short time to live, an anycast service, or a global load balancer.

Within those limits it is an excellent tool, and the reason it stays popular on developer clouds is that two modest servers plus one reserved address gives real resilience for far less than a managed balancer. Providers where this pattern is well trodden include Hetzner and Vultr, both of which expose the assignment through a straightforward API; the Hetzner and Vultr comparison covers how else they differ.

Checklist Before You Rely On It

• Confirm whether your provider routes the address automatically or expects the guest to configure it, and build the difference into your image.
• Publish DNS records pointing at the floating address only, so failover never waits for a cache to expire.
• Keep the standby running the service continuously, bound to all addresses.
• Automate with unicast keepalived plus a notify script that calls the provider API, and health check the service rather than the host.
• Run the heartbeat over the private network, require several consecutive failures, and scope the API token to one action.
• Solve replication and fencing separately, and rehearse the whole failover before you need it.