Introduction to Vault Replication

Vault replication enables high availability and disaster recovery for your secret management platform. By leveraging Vault’s DR (Disaster Recovery) and Performance replication modes, you can synchronize policies, secrets, and leases across multiple clusters—ensuring seamless failover and consistent access in multi-region deployments.

Understanding Vault Replication

Enterprises often distribute infrastructure across regions or data centers to maintain uptime. Vault, as the central secrets store, must follow the same architecture. Replication in HashiCorp Vault Enterprise (including HCP Vault) follows a leader-follower model:

• The primary cluster is the system of record.
• One or more secondary clusters receive asynchronous updates over mutual TLS.

Replication ensures:

• Global policy management: write policies once on primary, propagate automatically to all replicas.
• Consistent secrets: applications in any region read the same credentials and settings.
• Failover readiness: secondary clusters stand ready to assume primary duties if needed.

Vault Enterprise supports two replication modes:

1. Performance Replication
2. Disaster Recovery (DR) Replication

We’ll start with Performance replication before diving into DR replication details.

Performance Replication

Performance replication extends Vault to multiple data centers for low-latency reads. It replicates all configurations, policies, and secrets from the primary to one or more performance secondary clusters. Key characteristics:

• Primary cluster: serves all reads and writes.
• Performance secondary: serves local reads; forwards writes to primary.
• Tokens & leases: not replicated—clients must re-authenticate after failover.

Disaster Recovery (DR) Replication

DR replication creates a warm-standby cluster that includes tokens and leases. It mirrors policies, auth methods, secret engines, and all dynamic data. This mode is ideal for planned or unplanned primary outages:

• DR secondary: passive; does not serve client reads/writes until promotion.
• Tokens & leases: fully replicated—clients continue using existing credentials after failover.

Performance vs. DR Replication: Feature Comparison

Deep Dive: DR Cluster Behavior and Promotion

A DR secondary remains in standby until you invoke the promotion API. Until then:

• Most API endpoints are disabled (including root token generation).
• Any client request returns a “path is disabled” error.

Upon promotion:

1. The DR cluster becomes the new primary.
2. All replicated data, tokens, and leases become active.
3. Client applications resume without re-authentication.

Links and References

• Vault Replication Overview
• Vault Enterprise Licensing
• HCP Vault
• HashiCorp Vault Documentation