Use Cases
The overview named LVS, keepalived pairs, and Kubernetes. This chapter lays out the deployments that come up most often — each end to end.
The HAVIP part is the same every time, so it is worth stating once: create one HAVIP in the subnet your instances share, then point your failover software at its address. There is no attach step. Each section below focuses on the software-specific configuration around that.
Scenario 1 — Kernel Load Balancer (LVS) Director Pair
What you're doing: You run LVS — the kernel's IPVS load balancer — as your own load-balancing tier. Two director instances share one service VIP; the active director spreads incoming connections across a pool of real servers. If the active director fails, the standby must take the VIP and keep the virtual service running.
How to lay it out:
Create a HAVIP in the directors' subnet. This address is the LVS service VIP — what clients connect to.
Run keepalived on both directors. Its VRRP instance tracks the HAVIP; keepalived's
virtual_serverblock carries the IPVS configuration, so the director that holds the VIP is also the one programming IPVS.Put the real servers in the same VPC and pick an IPVS forwarding mode (DR, NAT, or tunnel) exactly as you would on-prem — the HAVIP governs which director is active, nothing about the real-server path.
For an internet-facing LVS, bind an EIP to the HAVIP. For an internal LVS — backends calling a shared virtual service — leave it private.
!!! note "Two layers, kept separate" The HAVIP gives you director failover; IPVS gives you the spread across real servers. They are independent — do not expect the HAVIP to balance anything, and do not expect IPVS to survive a director loss on its own.
Scenario 2 — Database Primary/Standby Failover
What you're doing: You run a database — PostgreSQL, MySQL — as a primary with one or more replicas. Applications must connect to a single, stable address that always points at the current primary. A cluster manager (Patroni, repmgr, MHA, Orchestrator) promotes a replica when the primary dies; the address has to follow that promotion.
How to lay it out:
Create a HAVIP in the database subnet. Point every application connection string at it — never at an individual database instance.
Run keepalived (or your cluster manager's own VIP hook) on each database instance.
Bind VIP ownership to the primary role, not to instance liveness: the instance that is primary holds the HAVIP; replicas keep it released. The cleanest wiring is to let the cluster manager's promotion callback raise/lower the keepalived state.
On failover, the cluster manager promotes a replica and that instance claims the HAVIP. Applications reconnect to the same address and land on the new primary.
Keep it private — application servers are inside the VPC.
!!! warning "Fence the old primary before the VIP moves" A database VIP must never be held by two instances at once — that is split-brain with writes. Drive VIP ownership from the cluster manager's promotion decision and make sure the demoted primary releases the address (or is fenced) before the new one takes it. VRRP priority alone is not a fencing mechanism.
Scenario 3 — Reverse-Proxy / API-Gateway Pair
What you're doing: You run a pair of reverse proxies or API gateways — HAProxy, Nginx, Envoy — in front of your backends. Because they are stateless, either instance can serve all traffic; you want one entry-point address and an instant takeover when one dies.
How to lay it out:
Create a HAVIP in the proxy subnet — this is the single entry-point address.
Run keepalived on both proxy instances, all pointing VRRP at the HAVIP.
Health-check the proxy process or its listening port, so a hung proxy on a still-running instance releases the VIP instead of blackholing traffic.
Internet-facing? Bind an EIP to the HAVIP. Internal-only (clients are other VPC services)? Leave it private.
!!! note "Active/standby, not active/active" A HAVIP delivers traffic to one instance at a time, so this pattern is active/standby — the standby proxy is idle until failover. Because the proxies are stateless, preemption is usually harmless: letting a recovered instance reclaim the VIP costs nothing. If you need both proxies serving at once, that is a job for a Load Balancer or for two HAVIPs split by DNS.
Scenario 4 — Self-Built Gateway Appliance (NAT / Firewall)
What you're doing: You run your own NAT gateway, firewall, or routing appliance as a pair of instances. Other instances in the VPC use the appliance as their default gateway or next hop. The gateway address must survive an appliance failure, or every instance behind it loses connectivity at once.
How to lay it out:
Create a HAVIP in the subnet whose instances route through the appliance. This HAVIP is the next-hop address.
Point the protected instances' default route (or the relevant route entries) at the HAVIP.
Run keepalived on both appliance instances. The holder owns the HAVIP and does the NAT / forwarding; on failover the standby takes the gateway address.
Enable IP forwarding on both appliances and keep their firewall / NAT rule sets identical — either one may be the holder.
!!! warning "The HAVIP moves the address, not the connection state" NAT translations and firewall connection-tracking entries live on the instance, not in the HAVIP. After a failover the new holder starts with an empty state table, so established flows may reset unless your appliance replicates state itself (for example with conntrackd). The HAVIP guarantees the address survives; surviving connections is your software's job.
Scenario 5 — Kubernetes Control-Plane and Service VIPs
What you're doing: Kubernetes needs stable VIPs in two places: a single API-server endpoint shared across the control-plane nodes, and LoadBalancer-type Service addresses exposed on the VPC network.
How to lay it out:
Control-plane endpoint. Create a HAVIP in the control-plane nodes' subnet and use it as the cluster's
controlPlaneEndpoint. Run kube-vip (or keepalived) on the control-plane nodes; the node holding the HAVIP serves API-server traffic, and the VIP moves on node failure.Service addresses. For an L2-mode setup — MetalLB in L2 mode, or kube-vip in ARP mode — the mechanism announces a Service IP with gratuitous ARP from whichever node currently hosts it. Allocate one HAVIP per Service IP you want to expose; the subnet's broadcast/multicast support is exactly what lets those ARP announcements take effect.
Expose a Service publicly by binding an EIP to its HAVIP; keep cluster-internal endpoints private.
!!! note "One HAVIP per distinct VIP" The control-plane endpoint and each LoadBalancer Service are separate addresses with separate failover — give each its own HAVIP. Do not try to multiplex several roles onto one.
Last updated