Patterns for connecting Vault to Amazon RDS using Amazon VPC Lattice

This is part 1 of a three-part series that highlights how Amazon VPC Lattice can help you achieve private connectivity from Vault self-managed (refers to Vault Enterprise or Vault Community Edition) or HCP Vault Dedicated to resources like Amazon RDS without direct connections to the RDS VPC via VPC peering or AWS Transit Gateway. This post will give you background, patterns, and example architectures before diving into Vault edition-specific tutorials in parts 2 and 3:

• Part 1: Patterns for connecting Vault to Amazon RDS using Amazon VPC Lattice
• Part 2: Connecting Vault to Amazon RDS using Amazon VPC Lattice
• Part 3: Connecting HCP Vault Dedicated to Amazon RDS privately using Amazon VPC Lattice

»Vault connections

HashiCorp Vault provides secure, centralized storage for sensitive information with access control and audit logging capabilities. The database secrets engine, a core component of Vault, generates dynamic, short-lived database credentials on demand. This eliminates the need for static credentials, enables automatic password rotation, and reduces security risks through time-based leases. For the database secrets engine to function, Vault requires a network connection to the database instances it manages, presenting a challenge when those databases reside in isolated VPCs.

»Traditional approaches: Peering and transit gateway

Prior to the release of Amazon VPC Lattice, private network connectivity to resources like RDS databases would be achieved via connecting consumer VPCs to RDS VPCs using VPC peering or Transit Gateway. This creates a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses. This ensures that traffic going to the databases does not go over the internet. However in some cases, in addition to keeping the database VPC private, you might want to keep the database VPC isolated without connections to other VPCs.

»Why VPC Lattice?

Amazon VPC Lattice allows private connectivity only to resources that you specify instead of the entire VPC. VPC Lattice is a fully managed application networking service that helps you simplify network connectivity, security, and monitoring for service-to-service communication needs. It also has broad support for the most common types of services and protocols, such as HTTP and HTTPS, gRPC, TLS, and TCP.

In this blog, we will explore various ways we can leverage VPC Lattice features to connect Vault self-managed and HCP Vault Dedicated to RDS while ensuring the VPC hosting RDS, referred to as the Provider VPC, remains isolated from all other VPCs. This means that the provider VPCs will not be connected to other VPCs via VPC peering or Transit Gateway.

»Vault self-managed patterns

»Before VPC Lattice

Prior to VPC Lattice, connecting Vault to RDS instances in separate VPCs typically relied on VPC peering or Transit Gateway. These methods establish network connectivity between entire VPCs, allowing Vault to communicate with the RDS database over private IP addresses.

Security controls such as security groups, route table configurations, and network ACLs were used to limit access to only the necessary RDS ports and IP ranges. While functional, this approach created a full network link between VPCs, potentially exposing more resources than just the RDS instance.

One significant challenge with these connectivity methods emerged when organizations had provider VPCs with overlapping CIDR ranges. In such scenarios, VPC peering couldn't be established due to IP conflict issues, creating architectural constraints.

Furthermore, even with proper security configurations, VPC peering and Transit Gateway create a connection between entire VPCs even though the requirement could be to connect to a specific service.

»With VPC Lattice

Altogether there are 3 ways that we can use VPC Lattice to achieve private connectivity from Vault to RDS. All 3 methods enable precise resource-level connectivity rather than network-level integration. Vault can communicate with the specific RDS instance without gaining access to any other resources in the provider VPC.

In addition, VPC Lattice supports environments with overlapping CIDR ranges between VPCs. Since traffic flows through the service network abstraction layer rather than direct VPC routing, IP address conflicts between VPCs become irrelevant.

»Pattern 1: Lattice service network endpoint

The first method uses the Lattice service network endpoint to connect the consumer VPC to the Lattice service network. Using this method requires the creation of only one endpoint in the consumer VPC. Security groups can be added to this endpoint to restrict network access to the Lattice service network. In terms of pricing, service network endpoints are available at no additional cost. Refer to the VPC Lattice Pricing page for more information.

With Amazon VPC Lattice, we can establish a direct and secure connection between Vault and an RDS instance without the broad connectivity of VPC peering or Transit Gateway. The process involves several targeted components that create a service-focused connection:

1. Create a VPC Lattice resource gateway in the provider VPC where the RDS instance resides. This gateway acts as an entry point specifically for the RDS resource. We then define a resource configuration that specifies the RDS instance ARN and resource gateway.
2. Associate this resource configuration with a VPC Lattice service network.
3. For illustration, the diagram above uses the Lattice service network endpoint to connect the consumer VPC to the Lattice service network. When you use the Lattice service network endpoint method, this allows Vault to connect to the RDS instance using its original DNS names if the endpoint has private DNS enabled. This endpoint allows Vault to access the RDS instance through the service network without any direct VPC connectivity between the two environments.

»Pattern 2: Resource endpoints

Another method would be to create a resource endpoint for each resource configuration. This method is useful if you want to configure a unique security group for each resource endpoint. However, compared to the first method, there will be more endpoints to manage in the consumer VPC. In addition, sufficient IP addresses must be present in the VPC for these endpoints. Furthermore, there is also a cost-per-resource endpoint. Refer to the Private Link Pricing page for more information.

»Pattern 3: Lattice service network VPC association

The final method is to associate the Lattice service network with the consumer VPC. The advantage of this method is that no private IPs are consumed within the VPC. Instead, connectivity is enabled using non-routable public IPs. For more information refer to this Amazon documentation on the types of service networks.

A trade-off of using this approach is that connecting to the RDS instance would use a different DNS name that is generated by Lattice. In terms of pricing, service network VPC associations are available at no additional cost. Refer to the VPC Lattice Pricing page for more information.

»HCP Vault Dedicated patterns

»Before VPC Lattice

Similar to Vault self-managed, connecting HCP Vault Dedicated to RDS instances in separate VPCs typically relied on VPC peering or Transit Gateway between the provider VPCs and the HashiCorp Virtual Network (HVN). This has the same set of concerns such as overlapping CIDR ranges and how VPC peering or Transit Gateway creates a connection between entire VPCs even though the requirement could be to connect to a specific service.

»With VPC Lattice

For Vault Dedicated there are 2 ways that we can use VPC Lattice to achieve private connectivity from Vault to RDS. Similar to the patterns for Vault self-managed, these patterns do not require peering to the provider VPC and can account for overlapping CIDR ranges between VPCs.

»Pattern 1: Lattice service network endpoint

The first method uses the Lattice service network endpoint to connect the consumer VPC to the Lattice service network. This is similar to pattern 1 for Vault self-managed. However, a key difference is that the Lattice service network endpoint resides in its own endpoint VPC since we cannot create VPC endpoints in the HVN. Security groups can be added to this endpoint to restrict network access to the Lattice service network from only the HVN CIDR block.

With Amazon VPC Lattice, we can establish a secure connection between Vault and an RDS instance without the broad connectivity of VPC peering or Transit Gateway in a hub and spoke topology. The process involves the following components:

1. Create a VPC Lattice resource gateway in the provider VPC where the RDS instance resides. This gateway acts as an entry point specifically for the RDS resource. We then define a resource configuration that specifies the RDS instance ARN and resource gateway.
2. Associate this resource configuration with a VPC Lattice service network.
3. For illustration, the diagram above uses the Lattice service network endpoint to connect the endpoint VPC to the Lattice service network. This Lattice service network endpoint has a unique DNS entry for every resource configuration associated with the Lattice service network.
4. The endpoint VPC is connected to HVN via VPC peering. This allows HCP Vault Dedicated to connect to the Lattice service network endpoint using the endpoint’s unique domain name per resource configuration.
5. With this pattern, the endpoint VPC and the HVN are not connected to the provider VPCs directly via VPC peering or Transit Gateway connections. VPC Lattice allows you to connect the specific RDS instances to its consumer instead of connecting the entire provider VPC. This is one of the 2 possible patterns.

»Pattern 2: Resource endpoint

The second pattern would be to create a resource endpoint for each resource configuration. Similar to pattern 1, the endpoints would be created in an endpoint VPC This method is useful if you want to configure a unique security group for each resource endpoint. However, compared to the first method, there will be more endpoints to manage in the endpoint VPC. In addition, sufficient IP addresses must be present in the VPC for these endpoints.

»Get started

In this blog, we covered the various patterns on how to use Amazon VPC Lattice to connect Vault to RDS instances privately without needing VPC peering or Transit Gateway to connect the RDS VPC to other VPCs. Check out parts 2 and 3 to learn how you can apply these patterns when we leverage Vault’s database secrets engine to generate dynamic credentials for RDS access into an isolated VPC that does not have connections to other VPCs.

• Part 2: Connecting Vault to Amazon RDS using Amazon VPC Lattice
• Part 3: Connecting HCP Vault Dedicated to Amazon RDS privately using Amazon VPC Lattice