EIP to HAVIP
A HAVIP is a private IP resource. It lives inside a subnet, and on its own it is reachable only from within the VPC — which is exactly what many HA designs want. To make the highly available service reachable from the internet, you bind an Elastic IP (EIP) to the HAVIP.
These are two separate, independently usable capabilities:
HAVIP alone — a private floating IP. Internal HA, reachable only inside the VPC.
HAVIP + EIP — the same private floating IP, now also fronted by a public address. Internet-facing HA.
A HAVIP is not born with public access and does not need it. Bind an EIP only when the service genuinely faces the internet.
Keep It Private, or Add an EIP
Stay private when the HA endpoint is consumed only by other resources in the VPC — no EIP needed:
Internal load balancer. A self-built LVS tier serving an HA virtual service to backends in the same VPC.
Internal Kubernetes endpoint. A control-plane or Service VIP that must stay on the private network.
Database / stateful-service VIP. A primary/replica pair that application servers reach over a stable private address.
Add an EIP when the service must be reachable from the internet:
Self-built public load balancer. Your own LVS or HAProxy tier accepting traffic from public clients.
Public-facing HA gateway or proxy. An internet-facing API gateway or edge proxy you run as an active/standby pair.
The division of labor is always the same: the HAVIP provides failover; the EIP provides public reachability. Layering them gives you an internet-facing endpoint that survives instance failure.
How the EIP and HAVIP Work Together
The EIP is bound to the HAVIP — to its virtual IP — not to any one instance's vNIC. That single fact is what makes the combination failover-safe, and it governs traffic in both directions.
Inbound — internet to the current holder
A public client sends traffic to the EIP.
The EIP forwards it to the HAVIP's private virtual IP.
From there it follows the normal HAVIP path — it reaches whichever instance currently holds the HAVIP.
On failover the holder changes and the network re-points the HAVIP (see How a HAVIP Works). The EIP binding does not change — it points at the HAVIP, not at an instance — so the public address is unaffected.
Outbound — the HAVIP is the public identity
The binding also governs traffic the HA service originates. When the instance holding the HAVIP reaches the internet through this EIP, the packet is sourced from the HAVIP — its private source address is the HAVIP's IP, not the instance's own private IP, and on the internet it appears as the EIP.
The practical consequence: the HA pair presents one stable public identity in both directions. Inbound and outbound traffic both ride the same EIP, and that identity does not change when the holder fails over. For a public gateway or proxy — where the remote side may pin firewall rules or allow-lists to your address — this is what you want.
Rules for the Binding
Same region
The EIP must be in the same region as the HAVIP.
EIP must be free
The EIP has to be available — not already bound to another resource — at bind time.
One EIP per HAVIP
A HAVIP is fronted by a single EIP.
Bind to the HAVIP
The EIP attaches to the HAVIP itself, not to one instance's vNIC.
!!! warning "Bind the EIP to the HAVIP, not to one instance" To get failover-safe public access, the EIP must be bound to the HAVIP. If you instead bind an EIP directly to one instance's vNIC, that EIP is pinned to that instance — when it fails, the public address fails with it, and the HAVIP failover underneath buys you nothing on the public path. The EIP and the HAVIP must move as one unit, and they do so only when the EIP is bound to the HAVIP.
What's Next
Use Cases — public and private deployment patterns, end to end.
Last updated