Why Vault HA needs a load balancer — and the design decisions that matter

A three-node Vault cluster can survive a node failure, but that does not automatically give applications a highly available endpoint. The active Vault node can change during maintenance, upgrades, restarts, network failures or leader election. Applications should not need to know which physical node is active at any point in time.

That is where the load balancer fits. It gives clients one stable Vault address while the cluster is free to move leadership between nodes behind it.

The important part is that Vault is not a normal stateless web farm. There is one active node, standby nodes participate in the HA cluster, and Vault has its own request-forwarding path between servers. A good load-balancer design works with that model rather than trying to replace it.

The role of the load balancer

Publish one stable DNS name or VIP for Vault clients.
Accept client API traffic and forward it to healthy Vault servers.
Remove nodes that are sealed, unavailable or otherwise unsuitable for client traffic.
Stay out of Vault's server-to-server cluster communication.

The load balancer is the stable front door. Vault still owns leader election, Raft replication and request forwarding inside the cluster.

Target architecture

Clients use the load-balanced address. Vault nodes use their own direct cluster_addr values for Raft, replication and request forwarding.

What happens when a request hits a standby?

With request forwarding enabled, a standby does not need the load balancer to find the active node for every request. The client connects through the load balancer, the selected Vault node terminates TLS, and if the request requires the active node, Vault forwards it internally over the cluster connection.

The client connects to the Vault load-balancer endpoint.
The load balancer selects a healthy Vault node on the API port.
The selected Vault node terminates the client TLS session.
If it is active, it processes the request.
If it is standby, Vault forwards the request to the active node over port 8201.
The response is returned through the node that originally received the client request.

Important distinction. The client load balancer handles port 8200. Vault's internal forwarding, Raft and replication traffic uses port 8201 and must travel directly between Vault nodes.

Layer 4 with TLS passthrough is the cleanest design

HashiCorp's validated VM design recommends a TCP-based Layer 4 load balancer with TLS passthrough. The load balancer forwards the encrypted TCP stream to Vault and Vault terminates TLS.

Client
  → HTTPS
Load balancer
  → encrypted TCP stream
Vault node :8200
  → TLS terminates here

End-to-end encryption. Secrets and tokens are never plaintext on the load-balancer tier.
One TLS policy. The Vault listener remains the security boundary for the Vault API.
Less certificate duplication. The load balancer does not need the Vault private key merely to proxy traffic.
Simpler troubleshooting. The TLS handshake seen by the client is the handshake with Vault.

Certificate design with TLS passthrough

Because Vault terminates TLS, the certificate presented by every Vault node must be valid for the hostname clients use. If clients connect to https://vault.example.com, that name should be present in the SAN of the listener certificate used by every Vault node.

Name	Purpose	Certificate consideration
`vault.example.com`	Client-facing load-balanced endpoint	Include in the Vault listener certificate SAN.
`vault-01.example.com`	Direct node administration	Include if direct node TLS access is required.
Node `cluster_addr`	Vault server-to-server traffic	Must be directly routable between Vault nodes; do not point it at the LB.

Health checks are where most designs diverge

Vault exposes /v1/sys/health, which returns different status codes depending on node state.

Default code	Vault state	Routing meaning
200	Initialized, unsealed, active	Healthy active leader.
429	Unsealed ordinary standby	Healthy HA member, but not active.
472	DR secondary	Treat according to the DR endpoint design.
473	Performance standby	Can serve qualifying reads locally in Enterprise.
474	Standby cannot connect to active	Do not treat as a healthy HA member.
501	Not initialized	Remove from service.
503	Sealed	Remove from service.
530	Removed from cluster	Remove from service.

TCP health check or HTTPS health check?

Check	Strength	Limitation
TCP 8200	Simple and widely supported.	A listening port does not prove that Vault is unsealed and HA-healthy.
HTTPS /v1/sys/health	Understands Vault state.	The LB must support HTTPS probing while preserving TLS passthrough for client traffic.

HashiCorp's validated design prefers a load balancer that can combine TLS passthrough with an HTTPS health check.

Which nodes should remain in the pool?

Healthy HA members

This pattern lets Vault's request-forwarding model do its job. An ordinary standby returns 429 by default. If the load balancer only accepts 200, the health API can map standby state to the active code:

/v1/sys/health?standbyok=true

For Enterprise performance standbys:

/v1/sys/health?perfstandbyok=true

If both ordinary and performance standbys are intentionally eligible and the monitor expects only 200, use the appropriate health parameters for both node types.

Active only

A stricter monitor can mark only the active node as healthy. This eliminates the standby-to-active forwarding hop, but it is a design choice rather than a Vault requirement.

Property	Healthy HA members	Active only
Vault request forwarding	Used when standby receives a request.	Usually avoided for client requests.
Pool size	Multiple nodes can remain eligible.	Normally one node.
Health logic	Must recognize valid standby states.	Usually expects active status only.
Operational model	Vault discovers the leader internally.	LB monitor tracks leader state.

Performance standbys change the performance story

Vault Enterprise performance standbys can process many read-only requests locally. Requests that require a storage write are forwarded to the active node. With the right edition and health-check configuration, the load balancer can therefore contribute to read scaling as well as availability.

Do not assume every standby scales reads. Ordinary HA standbys and Enterprise performance standbys are different roles. Confirm the feature entitlement and actual node state before designing for horizontal read scaling.

The ports are simple — but the boundaries matter

Source	Destination	Port	Purpose	Through LB?
Clients	Load balancer	443 or 8200/TCP	Vault API endpoint	Yes
Load balancer	Vault nodes	8200/TCP	Vault API traffic	Yes
Vault node	Vault node	8201/TCP	Raft, replication and request forwarding	No
Vault node	Vault node	8200/TCP	Cluster bootstrap / API operations where required	No

api_addr and cluster_addr are not interchangeable

api_addr is the API address Vault advertises for client redirection and some API behavior.
cluster_addr is the per-node address Vault advertises to other Vault servers for forwarding and cluster communication.

The cluster_addr must identify the individual Vault node and be directly reachable from its peers. It should not resolve to the load balancer.

For api_addr, HashiCorp distinguishes between clients that can directly reach individual nodes and environments where the load balancer is the only reachable address. Node-specific API addresses are preferable where direct access is possible because fallback client redirection can otherwise loop back through the load balancer. In normal modern HA operation, request forwarding should be the primary behavior.

What happens during leader failure?

The current active Vault node becomes unavailable.
Raft elects a new active node from the remaining eligible members.
Standbys update their forwarding connection to the new leader.
The load balancer health state converges as probes run.
Applications continue using the same Vault DNS name or VIP.

There can still be a short period of retries while election and health detection converge. HA means the service recovers automatically; it does not guarantee that every in-flight request survives a node failure.

The load balancer must not become the new single point of failure

A three-node Vault cluster behind one non-redundant load-balancer instance still has a single point of failure. The client endpoint itself should therefore use the HA mechanism provided by the chosen platform.

Failure scenarios worth testing

Test	Expected result
Stop the active Vault node	A standby becomes active; clients keep the same endpoint.
Seal one standby	The health monitor removes or avoids the sealed node.
Break 8201 connectivity for one standby	The node becomes HA-unhealthy and should not remain eligible.
Restart a standby	It rejoins and becomes eligible after Vault and the monitor consider it healthy.
Fail one LB component	The Vault service endpoint remains available through the redundant LB path.
Rotate the Vault listener certificate	Clients still validate the load-balanced hostname on every node.

Validation checklist

DNS: the Vault service name resolves to the intended load-balanced endpoint.
TLS: every Vault node presents a certificate valid for the client-facing hostname.
Backend path: the LB can reach every Vault node on 8200/TCP.
Cluster path: every Vault node can reach every peer directly on 8201/TCP.
Health monitor: active, standby, sealed and HA-unhealthy states produce the expected behavior.
Failover: losing or stepping down the active node does not require changing client configuration.
LB resilience: loss of one LB component does not remove the Vault service endpoint.

Common design mistakes

Hardcoding applications to a Vault node. Leadership changes then become application outages.
Load-balancing port 8201. Cluster traffic must be direct node to node.
Terminating TLS without a clear reason. Passthrough keeps Vault secrets encrypted to the Vault listener.
Using only a TCP probe and assuming Vault is healthy. A listening socket does not prove Vault is unsealed and connected to HA.
Treating 429 as an application error. On /sys/health, it is the default code for an ordinary unsealed standby.
Assuming every standby is a performance standby. Confirm the edition, entitlement and node state.
Making the LB a SPOF. Vault HA is incomplete if its only client endpoint is not resilient.

Design recommendation

Use a Layer 4 TCP load balancer.
Use TLS passthrough so Vault terminates client TLS.
Use HTTPS health checks against /v1/sys/health when the platform supports them alongside passthrough.
Decide explicitly whether valid standbys remain in the pool or whether only the active node is eligible.
Keep 8201 direct between Vault nodes.
Make the load-balanced endpoint itself highly available.

The load balancer should make Vault easier for clients to consume, not make the cluster more complicated. One stable endpoint, end-to-end TLS, state-aware health checks and direct server-to-server clustering are the design principles that matter.