In this post, we explore how you can use AWS PrivateLink support for Virtual Private Cloud (VPC) resources to facilitate private, secure, and efficient connectivity to shared resources across VPC and account boundaries, as well as from on-premises environments. We also review common use cases and implementation best practices for implementing this new AWS PrivateLink capability specific to SaaS providers and their clients.

AWS PrivateLink allows AWS Partners to securely expose their Software-as-a-Service (SaaS) offerings to thousands of customer AWS accounts, ensuring secure and private connectivity. While AWS PrivateLink VPC endpoints serve most SaaS connectivity needs, some use cases require direct connectivity to shared resources without a load balancer. To address these scenarios, AWS extended PrivateLink capabilities by introducing connectivity support for VPC resources. This allows you to configure direct and secure connectivity to shared resources, without requiring additional Elastic Load Balancing infrastructure. You can access VPC resources using AWS PrivateLink VPC endpoints and Amazon VPC Lattice. Both options provide you with integrated cross-account capabilities for VPC resource.

Prerequisites

We assume you are familiar with the AWS networking concepts and services, such as Amazon Virtual Private Clouds (VPCs), AWS PrivateLink, VPC endpoints, Amazon VPC Lattice, VPC peering and AWS Direct Connect. We won’t focus on defining these services, but we do outline their capabilities and how you can use them to configure the new AWS PrivateLink support for VPC resources. We recommend to review the detailed post on Building SaaS Services for AWS Customers with PrivateLink and Connecting Saas services within a VPC Lattice service network for detailed on how to leverage AWS PrivateLink and Amazon VPC Lattice for SaaS applications.

AWS PrivateLink support for VPC resources

Private connectivity for VPC resources is designed to provide secure and unidirectional connectivity to individual resources across VPC and account boundaries, and on-premises infrastructure. Resource owners who need to share a specific resource privately with a different account can now configure this connectivity without using a load balancer. This can be useful if the resource that you are sharing is a datastore (for example, single database node or a cluster of database nodes), or a cluster of resources not suitable for a load-balanced architecture. AWS PrivateLink support for VPC resources leverages private IPs to communicate between the client and resource, and allows you to granularly control which resources in your VPC are exposed to the resource consumer.

Launch partners

We are excited to be working with several of our ISV partners who are incorporating this capability into their solutions.

• Grafana Labs: How to query private network data without an agent using AWS and Grafana Cloud
• Palo Alto Networks: Announcing Palo Alto Networks Cloud NGFW Integration with AWS PrivateLink – resource VPC endpoint
• ClickHouse: ClickPipes supports cross-VPC resource access on AWS!
• Neo4j: AWS PrivateLink and VPC Lattice Improve Cross-Account Resource Sharing for Neo4j
• DataStax: Securely Connecting to Astra DB with AWS
• Starburst: How Starburst secures your data in flight with AWS
• Informatica: Informatica Announces Broad Innovation Agenda for Analytics and GenAI Solutions, Built on AWS
• Redis: AWS VPC endpoints on Redis Cloud

How it works

The following components allow you to set up AWS PrivateLink and Amazon VPC Lattice support for accessing VPC resources:

• Resource Gateway: A new VPC construct that provides a point of traffic ingress into the resource owner VPC for accessing shared resources.
• Resource Configuration: Allows you to specify the resources you want to share. You can create a single resource configuration specifying one resource, or you can create a group resource configuration that contains a collection of child resource configurations. You can associate multiple resource configurations with a single resource gateway in a VPC. A resource configuration can be shared with other accounts within or outside of your AWS Organization using AWS Resource Access Manager (AWS RAM).
• Resource Endpoint: A new type of VPC endpoint that resource consumer can use to access shared resources.
• VPC Lattice Service Network: A logical grouping mechanism that simplifies how you can enable connectivity across VPCs or accounts and apply common security policies for service-to-service communication. You can create a service network in an account and share it with accounts within or outside of your AWS Organization using AWS RAM.
• Service Network Endpoint and VPC association: The VPC Lattice service network VPC endpoint allows resource consumers to connect their VPC to a VPC Lattice service network. For connectivity to a service network, you can also use service network VPC associations. We detail best practices for choosing your connectivity option in the following “Things to know” section of this post.

We focus on the use cases where SaaS providers and their customers can leverage these components. For a detailed walkthrough example of the steps involved in setting up connectivity for VPC resources, please review Jeff Barr’s blog post on this topic and AWS PrivateLink documentation.

VPC resources benefits

AWS PrivateLink and VPC Lattice support for VPC resources provide the following key benefits for both the resource owner as well as the resource consumer:

A resource consumer can:

• Privately access VPC resources without the need for internet connectivity: Resource consumer can access the shared resources without using internet connectivity (for example, internet gateway or NAT gateway), across VPCs, accounts and on-premises environments.
• Maintain consumer-initiated access: Connectivity is unidirectional, and can be initiated only from resource consumer’s VPC.
• Easily connect to resources that have overlapping IPv4 addresses: With AWS PrivateLink and VPC Lattice support for accessing VPC resources, the client and resources can have overlapping IP addresses.
• Support different IP version capabilities: Client access to VPC resources can be configured with both IPv4 and IPv6, enabling different IP version capabilities between the resource consumer and resource owner.
• Simplify access from on-premises clients: Resource consumer can access resources in another VPC from on-premises nodes over AWS Direct Connect, or AWS Site-to-site VPN.
• Establish one-to-many access: If a resource owner shares a group of resources by using group resource configuration, the resource consumer can access the resources through a single VPC endpoint.

A resource owner can share access to VPC resources, and:

• Control access by selectively configuring and sharing specific VPC resources: A resource owner can share specific resources from their VPCs, and allow consumers to only access those resources. Other resources in the resource owner’s VPC are not exposed to consumers.
• Use a load balancer only when required: Resource owners don’t need to configure load balancers to share resources with consumers.
• Share resources that are deployed on-premises: Resource owner can share resources that are in their on-premises data center, by leveraging Direct Connect/VPN connection.
• Allow access to multiple resources through the same resource gateway: Resource owners can associate multiple resources with a single resource gateway. Resources don’t need to be in the same VPC as the resource gateway. However, the VPC that contains the resource gateway must have IP reachability to the resources in the associated resource configurations.
• Monitor access patterns and gain deep visibility into application communication flows: Resource owners can monitor who is accessing the shared resources, see how many bytes, connections, etc. they are sending to the resource.

VPC resources use cases for SaaS providers

1. SaaS provider accessing data stores in their customer’s VPC or on-premises environments

SaaS providers often require access to resources within their customers’ VPCs or on-premises environments to enable serverless offerings and integrate with customers’ data and systems. With AWS PrivateLink support for VPC resources, customers (resource owners) can deploy a resource gateway in their own AWS accounts and selectively share specific resources with their SaaS partners. This allows SaaS providers to access the required customer resources without the need for a customer-managed Network Load Balancer (NLB), streamlining the integration process for both entities.

On the SaaS provider (resource consumer) side, connectivity to this shared resource can be set up using one of the 3 options:

1. Using a service network endpoint
2. Using an AWS PrivateLink resource endpoint
3. Using a VPC association to a service network

Option a: Figure 1 shows how a SaaS provider (resource consumer) can access VPC resources shared by a customer (resource owner), using a service network endpoint. In this option, the service network endpoint connects the resource consumer VPC to their VPC Lattice service network. The resource consumer can create multiple service network endpoints in their VPC. Each service network endpoint allows access to a different service network.

By leveraging multiple service networks, a SaaS provider can logically separate the resources shared with them by different customers. However, it is also possible to use a single service network to access multiple shared resources.

Figure 1 : SaaS provider accessing resource via service network endpoint connected to a VPC Lattice service network

Option b: Figure 2 shows how a SaaS provider (resource consumer) can access resources shared by a customer (resource owner) by leveraging AWS PrivateLink resource endpoints. In this option, the resource endpoint connects directly to the resource owner’s resource gateway. It is possible to have multiple resource endpoints within a single resource consumer VPC. Each resource endpoint provides connectivity to a single resource configuration.

Figure 2: SaaS provider accessing resource via resource endpoint

Option c: The third option for the resource consumer is to create a service network VPC association to access the shared resources in the service network from their entire VPC, without creating any VPC endpoint separately. When using this option, only one service network can be associated to a consumer VPC. The service network VPC association doesn’t use IP addresses from the VPC CIDR, simplifying IP management and optimizing IP utilization. Figure 3 shows an architecture example for this option.

Figure 3 : SaaS provider accessing resource via a service network VPC association where the resource consumer VPC is associated directly with a VPC Lattice service network

2. Customer accessing their clusters that are managed by SaaS provider in the provider accounts or on-premises. 

With private connectivity for VPC resources, SaaS providers can host individual resources or a group of resources on behalf of customers within the provider’s own AWS accounts. SaaS providers can then expose those resources to the customer through a VPC endpoint in the consumer’s account. This allows customers to access the SaaS-managed resources without the need for networking configurations that may provide broader network access than needed, such as VPC peering, site-to-site VPN, or the public internet. By leveraging VPC endpoints for resources, SaaS providers can significantly reduce the management overhead for their customers. This removes the need for resource consumers to set up and maintain underlying connectivity mechanisms, between VPCs in different accounts, or on-premises environments. SaaS providers also have the flexibility to share resources that are hosted on-premises, leveraging existing hybrid connectivity (AWS Direct Connect or VPN).

In this use case, a SaaS provider (resource owner) hosts managed resources such databases, instances, clusters, or on-premises resources. A customer (resource consumer) can connect to the shared resources using one of the 3 options available to the resource consumer:

1. Using a service network endpoint
2. Using an AWS PrivateLink resource endpoint
3. Using a service network VPC association.

Figure 4 illustrates the 3 different options a customer (resource consumer) can use to connect to managed resources hosted by a SaaS provider (resource owner).

Figure 4: Customer accessing their resources that are managed and hosted by SaaS provider

3. Customer accessing SaaS service and SaaS provider accessing customer resource

This use case leverages both PrivateLink interface endpoints and private connectivity to VPC resources together to enable secure communication between the customer and SaaS provider. This approach allows SaaS providers to ensure customers can reach their SaaS service privately, while also enabling SaaS providers to privately access resources within the customer’s VPC. For SaaS provider’s access to customer resources, you can choose from any of the 3 options available to the resource consumer, which are also discussed in the other two use cases. For simplicity, we are only showing an example of the resource endpoint option. Figure 5 illustrates customer and SaaS provider utilizing both interface endpoints and resource endpoints and enabling private, pointed and unidirectional connectivity in each direction.

Figure 5: Customer and SaaS provider using both interface and resource endpoints together

Things to know

• At least one Availability Zone of the VPC endpoint and the resource gateway have to overlap.
• When creating a resource configuration to specify the resources to be shared, you can use the IP address of the resource or the publicly resolvable domain name (DNS hostname) of the resource. For certain resource types such as Amazon Relational Database Service (Amazon RDS), you can optionally specify the resource using Amazon Resource Names (ARNs).
• A resource configuration can be one of three types – single, group, or child. A single resource configuration is used to specify one resource. A group resource configuration is used to specify a collection of child resource configurations, with each child resource configuration containing a single resource.
• Resource gateway does not automatically provide any load balancing capability. If there is a use case to add load balancing to resources behind resource gateway, consider adding an NLB/ALB and specifying its domain name in the resource configuration.
• Review pricing for VPC endpoints and pricing for VPC Lattice.
• See default quotas for VPC endpoints and default quotas for VPC Lattice.

Conclusion

In this post, we explored how you can use AWS PrivateLink support for Virtual Private Cloud (VPC) resources to facilitate private, secure and efficient connectivity to shared resources across VPC and account boundaries, as well as from on-premises environments. We also reviewed common use cases and implementation best practices for implementing this new AWS PrivateLink capability specific to SaaS providers and their clients. By leveraging AWS PrivateLink support for VPC resources, SaaS providers and their clients can enable selective resource sharing without providing broad network access to each other. To learn more about this new capability, visit AWS PrivateLink documentation.

An update was made on December 9, 2024: Additional referenced launch partner articles were added. 

About the authors