An Elastic IP Is Not a Failover Plan: Four Patterns That Actually Fail Over

The difference between an elastic IP and a dynamic IP is not permanence — it is ownership of the failure. A dynamic public IP belongs to an instance and dies with it; an elastic IP belongs to your account and survives it. And the second misunderstanding is the expensive one: an elastic IP is not a failover plan. Failover is four verbs — detect, decide, remap, verify — and the elastic IP is only the third verb, one atomic operation. Buy one expecting high availability and you will own a perfectly static address pointing at a dead server, which is worse than a dynamic IP, because it fails with total confidence.

The redefinition the argument depends on: "dynamic" and "elastic" are not two kinds of address, they are two kinds of lease. A dynamic, auto-assigned public IP is rented to the instance at boot and returned to the provider's pool the moment the instance is stopped, destroyed, or rebuilt — and everything external that remembered the address, from DNS records to customer allowlists to monitoring probes, silently rots the instant that lease ends. An elastic IP — AWS's name for it; DigitalOcean calls it a reserved IP, Hetzner and Vultr call it a floating IP — is allocated to your account and stays allocated until you release it, and it can be re-associated from one instance to another in seconds, with no cache anywhere on the internet entitled to remember the old binding. The operational question is therefore never "which address type should I choose" but "who is allowed to move the address, how fast can it move, and what decides when it moves".

What follows is the working model: the real difference between the two address types, and which lifecycle each is bound to; the one thing an elastic IP buys you and the three things it does not; what the major providers charge for these addresses as of October 2026, and the exact conditions under which each charge applies; the four failover patterns that actually work, each written as ordered steps; the RTO comparison that maps your availability requirement onto a pattern; the five ways these patterns fail in production; and the FAQ answers to the questions people actually type.

Elastic IP vs Dynamic IP: The Difference Is Which Lifecycle the Address Is Bound To

The direct answer: a dynamic IP is bound to the instance lifecycle — it exists exactly as long as the instance's lease does — while an elastic IP is bound to the account lifecycle, existing until you explicitly release it, which is why only one of the two can point at a second machine after the first machine dies.

An auto-assigned public address appears at instance boot and disappears at stop or destroy. There is no notice, no grace period, and no way to get the same address back on most providers. The address was never yours; it was a property of the lease, and when the lease ends, the property reverts. Everything downstream that cached the address — a customer's firewall rule, a partner's allowlist, a monitoring dashboard, a hard-coded integration in someone else's codebase — is now pointing at a stranger's future server.

An elastic address inverts the ownership. As of October 2026, AWS's documentation states it plainly: a disassociated Elastic IP "remains allocated to your account until you explicitly release it." The address is a resource in your account, like a disk, with its own lifecycle, its own price tag, and — critically — its own move operation. That move operation is the entire subject of this article, because it is the only failure-related thing an elastic IP actually does.

Here is the conclusion before the table: the two address types differ in ownership, in survival, and in movability — and the row that decides your architecture is the last one, because movability is the property failover is made of.

When a Dynamic IP Is the Right Answer

The direct answer: a dynamic IP is the right answer exactly when nothing outside your control is allowed to remember the address — services fronted by a load balancer or reached only through a hostname with a sane TTL, egress-only workers, and short-lived machines can run on auto-assigned addresses with zero operational loss.

Three cases cover most of the legitimate uses. First, instances behind a load balancer: the public entrypoint is the balancer's address, and the instance's own address is plumbing that nobody external ever learns. Second, egress-only workloads — crawlers, batch jobs, build runners — where the address matters only in reverse-DNS reputation terms, and where the whole instance is disposable by design. Third, anything short-lived: a CI runner that lives forty minutes has no business owning a permanent address.

The failure mode of dynamic-IP architectures is never the address; it is the memory. Some party you do not control — a customer's firewall, an upstream API's allowlist, a monitoring service configured by IP — remembered the address, and nobody wrote that fact down. Teams running on dynamic IPs for years usually discover the dependency during the first migration, when the new address works everywhere except that one customer's office. If your only entrypoint is a hostname whose TTL you control, a dynamic IP is a non-problem. The moment an external party is allowed to remember the address, you need an account-owned address — and the cheapest time to learn which situation you are in is before the incident, not during it.

What an Elastic IP Actually Buys You: One Atomic, Cache-Free Operation

The direct answer: the entire value of an elastic IP is that moving it is a single control-plane operation that completes in seconds and that no resolver, browser, or intermediary cache anywhere is entitled to remember — the remap is atomic and immediate, bounded only by how fast you detect the failure and decide to act.

Contrast that with every DNS-based alternative. A record change is bounded by the TTL you set while healthy: flip an A record with a 14400-second TTL and you have a four-hour recovery window that no amount of urgency shortens, because the caches holding the old answer are machines you do not control. An elastic address has no such residue. The moment the provider's control plane completes the re-association, every new connection in the world routes to the new instance. That is the whole trick, and it is a genuinely different category of operation from anything DNS can offer.

AWS's own documentation, as of October 2026, describes the mechanism's purpose almost apologetically: you can "mask the failure of an instance or software by rapidly remapping the address" to another instance in your account. Rapidly — not automatically, not intelligently. The word "elastic" was never a promise of availability; it is a promise of removability. The recovery-time arithmetic makes the division of labor explicit: total RTO equals detection time, plus decision time, plus remap time, plus verification time. The elastic IP collapses the third term to seconds. Your monitoring, your runbook, and your standby own the other three terms, and they are where the real engineering lives.

One boundary condition deserves its own sentence: remapping the address kills every existing TCP connection. New connections follow the address instantly, which makes the operation nearly free for HTTP request/response traffic, but genuinely disruptive for long-lived connections — WebSockets, database sessions, SSH tunnels. Clients that reconnect gracefully treat a remap as a hiccup; clients that hold a socket for hours treat it as an outage. Design for reconnection either way.

The Three Things an Elastic IP Does Not Do

The direct answer: an elastic IP does not detect failure, does not distribute traffic, and does not cross provider boundaries — it is a remap primitive, not a health check, not a load balancer, and not a region-independent identity, and every one of those gaps has to be closed by something else in your architecture.

1. It is not a health check. An elastic address will point at a dead machine indefinitely, with perfect stability, forever. Detection is a monitoring system's job; if you have no external probe, the address is failover theater.
2. It is not a load balancer. All traffic goes to exactly one instance at a time. An elastic IP gives you active-standby at best; it cannot spread load, cannot give you a pool, and cannot scale anything. Scaling out is a load balancer's job.
3. It is not portable. The boundaries are strict and provider-specific as of October 2026: AWS Elastic IPs are usable in one Region only and cannot move to another Region; DigitalOcean reserved IPs remap within a single datacenter; Hetzner floating IPs move within one network zone. An elastic address anchors you inside one provider footprint, and crossing that line — cross-region or cross-provider failover — requires DNS, which means the TTL discipline you thought you had escaped comes back.

The region lock has a second consequence that is latency, not availability: when your failover target is a second region, the choice of which region is decided by where your users are, not just by where your provider has capacity. A standby that fails over beautifully but adds 250 ms to every request from your primary market has converted an outage into a degradation — which is a legitimate outcome, but only if you chose it deliberately. Region selection for user reach is its own discipline; for teams whose users concentrate in East and Southeast Asia, the calculus behind using a Hong Kong VPS to reach China and Southeast Asian markets covers the latency half of that decision.

What Elastic Addresses Cost, as of October 2026

The direct answer: as of October 2026, AWS charges $0.005 per hour for every public IPv4 address whether in use or idle, DigitalOcean's reserved IPv4 is free while assigned to a Droplet but $5.00 per month when unassigned, and Hetzner bills its floating IPv4 at €3.00 per month by the hour regardless of attachment — three opposite philosophies pricing the same scarcity.

Here is the conclusion to read before the table: the differences between providers are in the conditions, not the amounts — whether the address is charged while attached, while idle, or both is what turns a $0.50 line item into a $36 surprise on a fleet that hoards addresses "just in case."

Three philosophies, one scarcity. AWS's 2024 change made address hoarding a line item: their published example prices six in-use addresses plus four idle EIPs at $36.00 for the month, which is deliberately punitive arithmetic for "we keep a few spare IPs just in case." DigitalOcean's free-while-assigned rule is the opposite design: an address that is doing work costs nothing, an address sitting in a drawer costs $5.00. Hetzner splits the difference by billing every hour of existence but pricing the floating tier high enough (€3.00 versus €0.50 for a server-bound primary IPv4) to make floating addresses a deliberate purchase rather than a reflex. IPv4 exhaustion is also why an entire product category exists below all of this — VPS plans that share one IPv4 across many tenants through NAT, a trade-off with its own failure modes, covered in depth in this detailed guide to NAT VPS as a cost-effective hosting solution.

Pattern 1 — EIP Remap: One Region, Two Instances

The direct answer: run two instances in one region — an active and a warm standby — with an external health check on the active and a rehearsed remap procedure, so that when the check fires you remap the elastic address to the standby and recover in seconds plus your detection time, with no DNS change and no cache anywhere.

The sequence, from architecture to verified recovery:

1. Build the standby in the same region but a different availability zone, running the same stack, patched on the same schedule as the active. Warm, not cold: a standby that has to be provisioned during the incident is not a standby, it is a wish.
2. Put the elastic address on the active instance, and make DNS point at the elastic address — never at any instance-native address. Every external dependency, every allowlist, every monitor learns the elastic address and only the elastic address.
3. Run an external health check against the elastic address, with the path, interval, and failure thresholds decided in advance. CPU saturation is a perfectly good trigger signal if your failure mode is load-driven — and if reading it reliably matters to your runbook, this comprehensive guide to checking CPU usage in Linux covers the tools and the interpretation.
4. On trigger, verify the standby is healthy before remapping — a probe against the standby directly, not through the elastic address. Failing over to a dead standby converts an outage into a worse outage with a longer diagnosis.
5. Remap through the provider's API or console. The operation itself completes in seconds; this is the term the elastic IP collapses.
6. Verify end to end from outside — one real request through the elastic address, one real transaction — and only then declare recovery. Expect existing connections to have died at the remap; clients that reconnect will barely notice.

Two production caveats. If you automate the remap, make the automation idempotent and give it a dead-man's switch, because a script that remaps on every transient blip will flap your traffic between two half-healthy machines; most teams start with alert-triggered manual remap and automate only after the runbook is boring. And remember that the remap API is itself regional on most providers — during a full regional control-plane event, the address may be healthy while the ability to move it is not, which is exactly the gap patterns 2 and 4 exist to close.

Pattern 2 — DNS Failover: The Only Pattern That Crosses Providers

The direct answer: point a low-TTL A record at the active server and flip the record to the standby on confirmed failure — it is the only pattern that works across providers, regions, and continents, and its recovery time is bounded below by the TTL you set while healthy, so all of the discipline is front-loaded.

The sequence:

1. While healthy, set the A record's TTL to 60 seconds. If it currently sits at a registrar default of 14400, lower it one full old-TTL cycle before you consider yourself protected — the caches holding the old long-lived answer must drain before the short one protects you.
2. Monitor the active server from at least two independent vantage points, and require agreement between them before flipping, to avoid remapping the world because one monitor lost its own network path.
3. On confirmed failure, flip the A record to the standby's address. Do not lower the TTL and flip in the same sitting — that is the classic double-change mistake; the TTL must already be low.
4. The worst-case recovery window is the old TTL plus a minute of local cache residue; with a 60-second TTL you are looking at roughly one to two minutes of exposure for the median user.
5. Flip back only after the primary is verified healthy, and treat the flip-back with the same suspicion as the flip: the most common self-inflicted outage in DNS failover is the confident early failback.

The cost of this pattern is a standing one: a 60-second TTL multiplies your authoritative query volume relative to a day-long TTL, in exchange for a minutes-bounded RTO. On records that front an active-standby pair, that trade is almost always worth it. And note that this pattern composes with pattern 1 rather than competing with it: elastic remap inside a region, DNS failover across providers, each layer covering the other's blind spot.

Pattern 3 — VRRP and keepalived: Sub-Second, One Subnet, No Cloud API

The direct answer: two machines on the same Layer-2 subnet share a virtual IP that moves in one to three seconds when the master stops announcing it — the fastest failover that exists without an anycast network, and on public clouds it is usually confined to private subnets because the provider's public network will not forward VRRP's gratuitous ARP.

The sequence:

1. Install keepalived on both nodes and define the virtual IP with a MASTER priority on the active node and a lower BACKUP priority on the standby.
2. Add a track_script that checks the application — not just the machine — so the virtual IP moves when your process is wedged even though the kernel is fine.
3. Set the advert interval low (sub-second intervals give sub-second detection) and test the failover by killing the health-checked process, not by rebooting the machine; the process-death case is the one that actually happens.
4. Remember the topology requirement: VRRP moves an address by announcing it at Layer 2, which means both nodes must share a broadcast domain. On most public clouds that is only true on private subnets — run the pair on a private network behind a NAT gateway or load balancer, or on bare metal.

The strength and the weakness are the same property: everything is local. Nothing crosses a provider boundary, nothing depends on a control-plane API, and nothing is bounded by a DNS TTL — but nothing survives the subnet either. A failure that takes out the broadcast domain takes out the pattern, which is why VRRP pairs are usually the innermost layer of a design that also has one of the other patterns above it.

Pattern 4 — Managed Load Balancer: Rent the Detection Instead of Building It

The direct answer: put a managed load balancer in front of two or more instances with health checks, and the public address never moves at all — the pool changes — which converts failover from an operation you run into a configuration you maintain.

The sequence:

1. Register both instances as targets behind the balancer, in different availability zones if the product supports it.
2. Configure the health check against a path that exercises the real dependency chain, with an interval and an unhealthy threshold you have actually timed — recovery latency is interval times threshold, plus connection draining, and it should be a number you can quote.
3. Make your application honest about readiness: return success on the health path only when the instance can actually serve, so the balancer's decision is as good as your application's self-knowledge.
4. Test by killing one target's health path in production hours — if the balancer does not shift traffic within your computed window, the configuration is wrong and you want to learn that on a Tuesday, not during an outage.

This is the pattern most stateless web services should actually adopt, because it is the only one where detection is somebody else's maintained, monitored, continuously improved component — you are renting the hardest verb. Its cost is the balancer's hourly rate and the constraint that it only helps traffic that can be balanced: a single-node database, a stateful game server, or a queue worker with local state cannot be fronted by an HTTP health-check pool, and those workloads belong to patterns 1 through 3.

Choosing by RTO: The Table That Decides

The direct answer: pick the pattern by the recovery time your service actually requires and the blast radius you can tolerate — VRRP buys sub-seconds inside one subnet, EIP remap buys seconds inside one region, DNS failover buys minutes anywhere on earth, and a managed load balancer buys a health-check interval's worth of recovery without you owning detection at all.

The conclusion before the table: every row trades scope for speed — the tighter the blast radius a pattern survives, the faster it is, and the moment you need to survive a boundary crossing, you are paying in TTL.

One cost line deserves attention before anyone builds pattern 1: the standby is what makes failover a habit instead of an aspiration, because a second always-on machine in a second availability zone is a permanent bill for an instance that serves no traffic until the worst day of your quarter. That economics only works when the per-unit cost of a warm machine is low, which is exactly what the lightweight instance tier was built for — SurferCloud's ULightHost line ships a dedicated static IPv4 on every plan, with the 1-vCPU, 2GB RAM, 40GB NVMe entry configuration at $2.9 per month as of October 2026 (renewing at $7.5 per month), which prices a warm standby and its static address at roughly ten cents a day. The current offer for that line is on the ULightHost promo page, and the pattern's discipline is provider-neutral: remap-based failover does not care where the standby lives, only that it is warm, patched, and rehearsed.

Five Ways These Patterns Fail in Production

The direct answer: in production these patterns almost never fail at the remap itself — they fail around it, through untested standbys, closed firewalls, silently released addresses, TTLs left long until the incident, and split-brain — and every one of those failure modes is testable on a quiet Tuesday before it is load-bearing.

1. Failover to a dead standby. The standby nobody has booted in six months, whose disk is full, whose certificate expired in March, whose database migration never ran. Rehearse the failover monthly and the standby's decay becomes a calendar item instead of an incident post-mortem.
2. The address moved, the firewall did not. The standby's security group or host firewall blocks the traffic that now arrives for it, and users see a provider error page where your application should be. If users are reporting a blank or branded error screen during a failover, understanding whitelabel error page causes and solutions is how you tell "our failover misfired" apart from "our provider is down" — the two look identical from the browser until you check.
3. Side-effect address release. On AWS, as of October 2026, associating an Elastic IP with an instance that already has an auto-assigned public IP releases that public IP back to Amazon's pool permanently — it cannot be recovered or converted. Any customer who had allowlisted the instance-native address just lost their exception, with no event in your logs. Inventory which addresses the world remembers before you touch an association.
4. The TTL you never lowered. A DNS failover plan whose record sits at the registrar default of 14400 seconds is a four-hour RTO wearing a 60-second costume. The TTL is set while healthy or it protects nothing.
5. Split-brain. The remap fired while the old primary was degraded-but-alive, and now two machines both believe they own the traffic — or worse, both accept writes. Fence the old primary (or make the failover decision require explicit agreement) before this becomes a data-recovery engagement rather than an outage.

FAQ: The Questions People Actually Type

The direct answer to the section: these seven questions cover nearly all of the elastic-versus-dynamic confusion, answered in one or two sentences each, with the deciding condition named every time.

1. "What is the difference between an elastic IP and a dynamic IP?" A dynamic IP is leased to the instance and disappears when the instance stops or is destroyed; an elastic IP is allocated to your account, survives any instance's death, and can be re-associated to another instance in seconds. The difference is which lifecycle owns the address.
2. "Do I need an elastic IP for my VPS?" Only if something outside your control remembers the address — customer allowlists, hard-coded integrations, or DNS you cannot keep at a low TTL. If the only entrypoint is a hostname whose TTL you control and nothing allowlists the address, a dynamic IP is fine.
3. "Does an elastic IP give me high availability?" No. It gives you one fast operation inside a failover plan — the remap. Detection, decision, and verification are still yours to build, and an elastic address pointing at a dead server is perfectly stable forever.
4. "How long does an elastic IP failover take?" The remap itself completes in seconds; the realistic recovery time is your detection interval plus your decision latency plus those seconds. Teams that quote single-digit-minute failover times are quoting their monitoring, not their address.
5. "Can I move an elastic IP to another region?" No, on every major provider as of October 2026: AWS Elastic IPs are Region-bound, DigitalOcean reserved IPs are datacenter-bound, and Hetzner floating IPs are network-zone-bound. Crossing a region or provider boundary requires DNS failover and its TTL.
6. "Why am I being charged for an elastic IP that is attached and running?" Because AWS has charged for all public IPv4 addresses — attached or idle — at $0.005 per hour since February 2024; DigitalOcean charges $5.00 per month only for unassigned reserved IPs; Hetzner bills floating IPs at €3.00 per month by the hour of existence. The condition, not the amount, is what differs.
7. "Is a dynamic IP a security risk?" Not inherently — the risk is operational, not security: the address you lose may be reused by a stranger, and everything that remembered it now points at them. The security exposure comes from what other people's systems do with their stale memory of your address, not from the address changing.

The sentence to carry out of this article, if only one survives: an elastic IP is a verb, not a plan — it moves the address, and everything that matters around that movement, the detecting, the deciding, and the verifying, is architecture you either rehearsed or you did not.