What Is a Floating IP / Failover IP, and When Is It Needed in Cloud Infrastructure

A Floating IP or Failover IP is an IP address that can be moved quickly from one instance to another without changing the external entry point seen by clients.

In practice, this is useful where a service needs to remain reachable at the same address even after a failure, during maintenance, or after being moved to another node.

Most often, this kind of IP is used when you need to:

• Quickly switch a service to a standby instance
• Keep the same public address
• Avoid touching DNS, allowlists, and external integrations during a move
• Simplify failover in a small or medium-sized infrastructure

At the same time, a Floating IP does not make a system truly highly available on its own. It does not balance traffic, fix application problems, or replace a proper high-availability architecture.

That is why it is best understood as a convenient network-level failover mechanism for switching the entry point, not as a universal solution for every resilience problem.

Floating IP and Failover IP: What They Actually Are

In cloud infrastructure, a Floating IP or Failover IP usually means a public IP address that can be detached quickly from one instance and attached to another.

That is its key characteristic.

It is not just “another external IP,” but an address that can be used as a portable entry point for a service.

Put simply, it works like a company phone number that is not permanently tied to one employee. The client calls the same number, but inside the company the call can now be answered by someone else. In the cloud, the logic is similar: the external address stays the same, while the backend node behind it can change.

Here is a short comparison so it is easier not to confuse a Floating IP with a regular static public address:

That is why a Floating IP should be understood not as a separate “type of Internet,” but as a network mechanism that helps keep the same external address even when the service itself moves to another node.

It is also easy to get confused by terminology here. Different providers may use different names for a very similar idea: Floating IP, Failover IP, Additional IP, Elastic IP, or something else. But the practical meaning is usually the same: you have a public address that should not remain permanently nailed to one virtual machine.

How This Kind of IP Differs from a Regular Static Address

A static IP is an address that does not change on its own, unlike a dynamic one. If that address is also reachable from the outside, it becomes a stable external entry point for the service.

A Floating IP is meant for a different scenario. What matters here is not only that the address stays stable, but that it can also be detached quickly from one resource and attached to another. In other words, a static IP answers the question, “Will the address remain constant?” A Floating IP answers a different one: “Can we move that address quickly to another instance without changing the external entry point?”

In practice, this is especially useful in cloud environments for failover, maintenance, and service migration between nodes. But there is one important nuance to keep in mind: a Floating IP can usually be reassigned freely only within the network, availability zone, or region where the provider allows it. Across different cloud regions, this model usually does not work directly.

How a “Moving” IP Works in the Cloud

The core idea behind a Floating IP is fairly simple: the external IP address stays the same, while the resource behind it can change.

As long as the service is operating normally, that IP is attached to the primary instance, network interface, or node. If something happens to the primary resource — a failure, maintenance event, or migration — the address can be reassigned quickly to another instance.

From the outside, this often looks almost invisible. The client still connects to the same IP, but the backend responding behind that address is now a different node.

Put simply, the model looks like this:

• Before: Floating IP → primary node
• A failure or migration happens: the IP is detached
• After: Floating IP → standby node

That is the real value of this approach: what changes is not the address the client uses, but the internal endpoint standing behind that address.

Here is a simple table to make the mechanics explicit:

What matters, however, is not to overestimate this mechanism. A Floating IP helps preserve the external entry point quickly, but it does not by itself guarantee that the standby node is actually ready to receive traffic.

If the application is not running on the second machine, the data is not synchronized, or the network logic has not been prepared correctly, simply moving the IP will not solve the problem.

In theory, it sounds simple: the IP moves, and the service keeps running. But the value of this model becomes most visible not in abstract definitions, but in ordinary operational scenarios. The next logical step is to look at a few practical examples where a Floating IP truly proves useful.

A Small Website Running on Two Virtual Machines

Imagine a company website running on one VM, with a standby machine nearby configured in the same way.

As long as everything remains stable, the Floating IP points to the primary server. If the primary node fails, the team — or an automation workflow — reassigns that same IP to the standby instance.

For the visitor, the site still opens at the same address. There is no need to wait for DNS propagation or look for a new endpoint. From the outside, the only thing that changes is which server is answering the request.

A VPN Gateway or Bastion Host

Now take a more infrastructure-oriented scenario: a VPN gateway or a bastion host used by administrators.

The team already has one well-known public address, and that address is documented in runbooks, embedded in scripts, and configured in client settings. If the VPN or bastion node needs to be restarted, replaced, or taken out of service urgently, it is much more convenient to keep the same IP than to distribute a new address to every user.

In this kind of setup, a Floating IP makes it possible to preserve the external connection point while quickly moving the service itself to another instance.

EU Cloud Infrastructure You Control

Run production workloads on dedicated resources across EU data centres. Transparent pricing, no hidden costs. Full control over compute, storage, and networking.

Explore Infrastructure

Predictable Virtual Machines for Production

Dedicated vCPUs, consistent performance, no noisy neighbours. Deploy and scale VMs in minutes. Full root access, fixed pricing.

View VM Plans

Up to €22,000 to Migrate Your Workloads

Cut OPEX when migrating to EU infrastructure. Get migration support, cost assessment, and infrastructure credits with no upfront commitment.

Apply for Bonus

Kubernetes with Full Control

Deploy production-ready clusters with control over node configuration, storage, and networking. Predictable costs and direct access to infrastructure.

Deploy Cluster

An External Integration with IP Allowlists

Another common case is an integration where a partner or external service accepts traffic only from a pre-approved IP address.

For example, you may be working with a payment gateway, a B2B API, or a corporate system in which your address has already been added to an allowlist. If the external IP suddenly changes during a service migration, that stops being a minor network detail and becomes a real outage.

This is where a Floating IP becomes especially useful: it allows you to keep the same external address even after moving the service to another node. For the partner on the outside, nothing changes — the approved IP remains the same, while the infrastructure behind it may already be different.

Where a Floating IP Is Genuinely Useful

A Floating IP is usually needed not “for the cloud in general,” but for a very specific purpose: to preserve one stable external entry point even when the node, route, or active instance behind it changes inside the infrastructure.

That is exactly why this mechanism is valued not for the simple fact that it provides a public IP, but for the ability to get through failures, maintenance events, and migrations more smoothly and with less networking disruption.

In practice, this becomes especially clear in several common scenarios:

The main point the table highlights is this: a Floating IP is useful where what matters is not merely “Internet access,” but the stability of the external address while the internal role of the nodes changes.

When Fast Node Switching Matters

The first and most obvious use case is failover in an active-passive setup.

One node serves the traffic, while the second waits on standby. If the primary instance fails, the IP is moved to the standby node. This does not make the system magically indestructible, but it does reduce switchover time noticeably and eliminates the need to change the address on the client side.

A second common scenario is moving a service without changing its public endpoint.

For example, the team may need to replace a VM, move a workload to another host, refresh the environment, or rebuild part of the infrastructure. If the external IP remains the same throughout that process, the migration becomes much calmer: there is no need to urgently rewrite DNS records, update client configurations, or notify partners about a new address.

When a Stable External Entry Point Matters

There is another group of scenarios where the priority is no longer failover itself, but the stability of the public address.

This is especially convenient for a bastion host, VPN gateway, internal API, small self-hosted ingress, or any other service that users and systems are already accustomed to reaching through one known address. In that kind of setup, a Floating IP provides predictability: from the outside, the address stays the same even if the instance behind it has already changed.

This is particularly visible in IP allowlist-based integrations.

In many B2B scenarios, partner systems, payment services, corporate APIs, or administrative panels accept connections only from pre-approved addresses. If the service moves and the IP changes, the problem is no longer just convenience — it becomes an availability issue. A Floating IP reduces that dependency: the backend can be rebuilt without breaking the trusted external address.

That is exactly why a Floating IP tends to fit especially well in small or mid-sized infrastructures where the need is for clear and straightforward switching mechanics rather than a full-scale balancing and orchestration design.

But here too, it is important not to swing to the opposite extreme. If the system already has several active backend nodes, more complex health-check logic, balancing across multiple paths, and continuous traffic distribution, then one Floating IP may turn out to be too blunt an instrument.

What a Floating IP Does Not Solve on Its Own

This is exactly the point where a Floating IP is easy to overestimate.

It does help preserve the external address quickly and redirect traffic to another node. But by itself, that kind of IP does not turn the infrastructure into a full high-availability design.

Put simply, a Floating IP switches the entry point — it does not remove the service’s internal weaknesses.

If the standby node is not prepared, the application is not running there, the data is not synchronized, or its configuration differs from the primary machine, simply moving the IP will not save the situation. From the outside, the address stays the same, but the service itself may still fail, return errors, or never come up properly.

This matters even more for stateful workloads.

If the service is not just a web proxy or bastion host, but something like a database, a queue, an internal API with local state, or an application tied to a specific disk and local session, failover becomes more complicated. In that kind of setup, it is not enough to move the IP to another instance — you also need to ensure that the standby node is genuinely ready to continue operating without losing logic or data.

There is another limitation as well: a Floating IP does not distribute load.

It works well in a model where, at any given moment, one active node receives traffic while another sits in reserve. But if the service needs several backend nodes running simultaneously, plus health checks, request distribution, TLS termination, or flexible routing, then one “moving” IP is no longer enough.

Here is a short comparison:

The main point the table shows is simple: a Floating IP solves the network side of the switchover, but it does not solve the full architectural problem on its own.

Alternatives: Load Balancer, DNS Failover, or Managed HA

If a service needs to run across several backend nodes at the same time, it usually makes more sense to look toward a Load Balancer.

That is the right choice when traffic needs not merely to be moved from one instance to another, but continuously distributed across multiple nodes. This is already a different task: not “which node is active right now,” but “how do we serve the workload through several servers at once?”

DNS failover follows a different logic.

It can be useful when traffic needs to be switched between sites or endpoints at a higher level, but there is a trade-off: the behavior depends on TTL, caching, and how quickly clients notice the updated record. That is why DNS failover is not always the best tool when the goal is to preserve the same ingress path as quickly as possible without extra uncertainty.

Managed HA and provider-native high-availability services are usually chosen where the team does not want to assemble the full mechanism manually.

If the project needs built-in health checks, automatic failover, well-designed orchestration, and less hand-built logic around the standby path, then a ready-made managed solution is often more practical than a self-assembled model built around a Floating IP and custom scripts.

That is exactly why a Floating IP works best in clear and relatively compact scenarios: where you need one stable address, one active node, one standby node, and the switchover logic itself remains manageable.

But if the infrastructure is already moving toward active-active operation, more complex balancing, clustering, and continuous scaling, then a “moving” IP usually becomes only one part of the design — no longer the main tool at its center.

Conclusion

A Floating IP or Failover IP is not a universal “high-availability button,” but a convenient network mechanism that helps preserve the same external address during a failure, a migration, or the replacement of a node.

It works best where the infrastructure needs a simple and understandable switching model: one public endpoint, one active node, one standby node, and minimal external reconfiguration.

But if the service already needs load balancing, several simultaneously active backends, more sophisticated health checks, and a full HA design, then a Floating IP quickly stops being enough on its own. In those cases, it remains a useful tool — but no longer a complete solution to the whole problem.

FAQ

Are a Floating IP and a static IP the same thing?

Not quite. A static IP is simply an address that does not change on its own. A Floating IP may also remain stable from the outside, but its key difference is this: it can be moved quickly from one instance to another while preserving the same external entry point.

Can a Floating IP be used for a bastion host or a VPN gateway?

Yes. That is one of the clearest use cases. It allows the team to keep the same connection address even if the node itself has to be replaced or switched over to a standby instance.

Does a Floating IP replace a Load Balancer?

No. A Floating IP is good for switching between nodes, but not for continuously distributing traffic across several backends.

Will a Floating IP help if a partner allows my service only from one approved IP?

Yes — that is exactly where it is especially useful. You can move the service between nodes without changing the external address that has already been added to the allowlist.

Can a Floating IP be considered a cheap way to achieve high availability?

It is better described as a relatively inexpensive way to simplify entry-point failover, not as a complete HA solution. If the standby node is not ready, the data is not synchronized, or the application does not handle failover properly, one IP address will not solve the problem.

Is a Floating IP suitable for stateful services such as a database?

On its own, only with limitations. The IP can be moved quickly, but for a stateful service that is not enough: you also need proper replication, data consistency, and a clear failover model.

Sources

1. OpenStack Docs — Configure access and security for instances

2. AWS Documentation — Elastic IP addresses

3. AWS Documentation — Associate Elastic IP addresses with resources in your VPC

4. OVHcloud Docs — Concepts - Additional IP or Floating IP