How does Vault auto-unseal work with AWS KMS and Transit, and what are recovery keys?

Think of a bank vault with two possible lock systems. The traditional lock requires three bank officers to each insert their key at the same time (Shamir's unseal keys). The modern lock uses an electronic reader connected to a central security office that opens automatically when the vault door is closed (auto-unseal via KMS). If the security office network goes down, the vault stays locked even though the vault itself is fine. Recovery keys in the modern system let officers generate a new electronic badge, but they cannot manually turn the old mechanical lock.

Vault stores all data encrypted with a root encryption key, which is itself encrypted (wrapped) by the unseal mechanism. In the default Shamir mode, the root key is split into shares, and you need a threshold of shares to put the key back together and unseal Vault. This is secure but operationally painful: every Vault restart, upgrade, or node replacement needs someone to provide unseal shares. Auto-unseal fixes this by having an external system do the key unwrapping automatically.

With AWS KMS auto-unseal, you configure Vault with a KMS key ARN. During initialization, Vault generates its root encryption key and wraps it using an AWS KMS Encrypt API call. The wrapped key is saved in Vault's storage backend. On startup, Vault calls KMS Decrypt to unwrap the root key, completing the unseal without anyone having to type anything. The IAM role on the Vault server must have kms:Encrypt and kms:Decrypt permissions for the specified KMS key. Transit auto-unseal works the same way but uses another Vault cluster's Transit secrets engine as the key wrapping service, creating a trust chain between two Vault clusters. When you initialize Vault with auto-unseal enabled, it generates recovery keys (using Shamir splitting) instead of unseal keys. These recovery keys can generate root tokens and start rekey operations, but they cannot perform the unseal operation itself.

At production scale, auto-unseal is essentially required for any automated deployment, Kubernetes-based Vault setup, or auto-scaling group. Without it, a pod restart or node replacement creates a sealed Vault that blocks all secret access until operators show up with unseal shares. You need to make sure the KMS is highly available, consider cross-region KMS replication for DR, lock down IAM policies to least privilege, and monitor CloudTrail for KMS Decrypt calls. For Transit auto-unseal, the upstream Vault cluster becomes a hard dependency: if it goes down, the downstream cluster cannot unseal.

The gotcha that catches people is the migration path between seal types. Moving from Shamir to auto-unseal, or between two different KMS providers, requires a seal migration that rewraps the root key. During migration, Vault must restart with both old and new seal configurations, and the old unseal or recovery keys must be provided. If the old keys are lost or the old KMS key is deleted before migration finishes, the Vault data is gone forever. Document your seal configurations, keep old KMS keys until migration is confirmed, and always test the migration in staging before touching production.