How to deploy HashiCorp Vault with Terraform on AWS

Secrets drive infrastructure, automation, and application workflows, making them more challenging to manage securely as systems scale. HashiCorp Vault provides a unified, identity-aware platform for storing and brokering sensitive data. Yet manually deploying Vault introduces risks, including:

• Configuration drift
• Inconsistent environments
• Operational overhead

Terraform removes these challenges by letting you declare Vault's infrastructure, network access, bootstrap logic, and integrations as code, giving teams a repeatable and auditable deployment model.

Vault's lifecycle begins with initialization and unsealing, after which it can accept requests. To ensure security best practices when deploying Vault, consider implementing security scanning tools in your Terraform workflow.

A high-availability Vault cluster requires a storage backend. HashiCorp's built-in integrated Raft storage is a production-grade backend that supports replication without relying on external systems. Terraform complements this architecture with a consistent provisioning pipeline. Remote state storage, such as S3, is recommended for collaboration and state locking to ensure that infrastructure definitions remain consistent across environments.

This guide provides a walkthrough for deploying a Vault cluster powered by EC2 instances, integrated Raft storage, and AWS KMS auto-unseal. It emphasizes the interplay between Terraform and Vault, showing not just how to configure resources but why each step matters for operational reliability and security.

What is HashiCorp Vault?

HashiCorp Vault is a secrets lifecycle management system that secures credentials, tokens, certificates, and encryption keys. It enables teams to do the following:

• Centralize sensitive information
• Generate short-lived secrets
• Enforce granular access policies
• Provide encryption as a service

Furthermore, Vault's strengths include the following:

• Generating dynamic credentials for databases or cloud services
• Enforcing policies through its ACL system
• Supporting extensive authentication options, ranging from tokens to cloud identity providers

Vault fits naturally into multi-environment and multi-cloud architectures because it abstracts secret distribution behind an API rather than pushing static credentials into workloads. For a comprehensive approach to secrets management in GitOps workflows, you can also explore alternative secrets management patterns to ensure your workflow complies with your corporate policies while best serving your developers.

While HashiCorp offers a hosted version through HCP Vault, many organizations deploy Vault on AWS to meet infrastructure control and compliance requirements, or to support hybrid-cloud strategies. With Terraform, these deployments become standardized, reviewable, and reproducible, opening a range of opportunities, including developer service.

What you need before deployment

AWS requirements

You need an AWS account with permissions to create EC2 instances, VPCs and subnets, security groups, IAM roles, and KMS keys. A dedicated VPC or isolated subnets are recommended to separate Vault from general application workloads. When managing complex AWS deployments, you may need to work with multiple IAM roles across different environments.

Terraform setup

Install Terraform locally or use Terraform Cloud or CI/CD pipelines. Configure the AWS provider, then authenticate using environment variables, shared configuration files, or IAM roles.

Using an S3 backend for Terraform's remote state ensures state consistency and concurrency safety. Read our blog about setting up S3 backends with DynamoDB locking for Terraform state management.

Storage backend selection

Vault supports several storage backends, but its integrated Raft storage offers a simple, scalable path for high availability.

Auto-unseal mechanism

Set Vault must auto-unseal on startup, and AWS KMS automates this process by performing cryptographic operations with AWS-managed keys.

With these prerequisites in place, you can begin implementing the Terraform code that deploys a complete Vault cluster.

How to deploy HashiCorp Vault with Terraform on AWS

The following steps describe a three-node Vault cluster using integrated Raft storage, AWS KMS auto-unseal, and EC2 instances in an autoscaling group.

Step 1: Providers and remote state

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }

  backend "s3" {
    bucket = "your-state-bucket"
    key    = "vault/terraform.tfstate"
    region = "us-east-1"
  }
}

provider "aws" {
  region = "us-east-1"
}

Remote state ensures consistent deployments across engineers and CI workflows. If you need to migrate from a different backend or change your state configuration, consult this guide on state migration.

Step 2: Networking and security

Vault exposes TCP ports 8200 for API traffic and 8201 for Raft cluster communication. Restrict these ports to trusted CIDR ranges.

resource "aws_security_group" "vault" {
  name        = "vault-sg"
  description = "Vault security group"
  vpc_id      = aws_vpc.main.id

  ingress {
    from_port   = 8200
    to_port     = 8200
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"]
  }

  ingress {
    from_port   = 8201
    to_port     = 8201
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"]
  }

  egress {
    from_port = 0
    to_port   = 0
    protocol  = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

For comprehensive security practices in your infrastructure code, including automated secret detection and policy-as-code, consider implementing shift-left security principles.

Step 3: AWS KMS auto-unseal

Vault uses this key to decrypt its master key, enabling automatic unseal workflows. When deploying Vault in production, you'll also need to consider state encryption and secrets management in your CI/CD pipeline as an additional layer of protection.

resource "aws_kms_key" "vault_auto_unseal" {
  description             = "KMS key for Vault auto-unseal"
  deletion_window_in_days = 30
  enable_key_rotation     = true
}

Step 4: EC2 nodes and bootstrap script

A launch template provisions Vault binaries, writes the Vault configuration file, and enables the systemd service.

resource "aws_launch_template" "vault" {
  name_prefix   = "vault-"
  image_id      = data.aws_ami.amazon_linux.id
  instance_type = "t3.medium"

  user_data = base64encode(
    templatefile("${path.module}/vault-bootstrap.sh", {
      kms_key_id = aws_kms_key.vault_auto_unseal.arn
    })
  )
}

Here's a simplified Vault configuration:

seal "awskms" {
  region     = "us-east-1"
  kms_key_id = "REPLACE_ME"
}

storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-node-1"
}

listener "tcp" {
  address     = "0.0.0.0:8200"
  tls_disable = 1
}

Vault often stores database application secrets. Read our blog on how to deploy and secure database infrastructure, such as PostgreSQL, with Terraform.

Step 5: Autoscaling group for high availability

Distributing nodes across availability zones provides resiliency from instance and zone failures. For production deployments, consider adding a load balancer to distribute traffic across your Vault nodes.

resource "aws_autoscaling_group" "vault" {
  desired_capacity    = 3
  max_size            = 3
  min_size            = 3
  vpc_zone_identifier = [
    aws_subnet.public_a.id,
    aws_subnet.public_b.id
  ]

  launch_template {
    id      = aws_launch_template.vault.id
    version = "$Latest"
  }
}

As your infrastructure grows, organizing your Terraform code effectively becomes critical for managing complex deployments such as multi-region Vault clusters.

Step 6: Initialize and unseal Vault

Run:

vault operator init

After initialization, Vault will automatically unseal thanks to the AWS KMS seal configuration.

Alternative cloud providers and secret-management tools

Terraform enables consistent Vault deployments beyond AWS.

Google Cloud Platform

GCP supports auto-unseal using Google Cloud KMS. Vault can run directly on Compute Engine instances or GKE clusters.

Microsoft Azure

Azure Key Vault can perform unseal operations through the Azure Key Vault seal method. Terraform's AzureRM provider enables VM or VM scale set deployments matching the AWS architecture.

Monitoring and Observability

Once your Vault cluster is deployed, implementing proper monitoring is essential. Check out our blog post on deploying monitoring solutions like Grafana with Terraform for comprehensive visibility into your cloud and hybrid infrastructure.

Alternative secret-management tools

AWS Secrets Manager, CyberArk, and Doppler offer credential management, but they differ from Vault's dynamic secrets, leasing, and policy-driven access system. When cloud and SRE teams require multi-cloud consistency, short-lived secrets, and robust authentication, Vault remains a top choice.

Conclusion

Deploying HashiCorp Vault with Terraform on AWS provides teams with a repeatable, secure approach to managing infrastructure secrets. Terraform provides the following for teams operating Vault across environments:

• Consistency
• Version control
• Automation

These features, plus Vault's flexibility, Raft integration, and automated unseal mechanisms, enable enterprises to deliver secure credential management at scale.

For teams looking to adopt GitOps practices for their Vault deployment and other infrastructure, implementing a GitOps workflow with Terraform ensures version control, peer review, and automated deployments.