An easy guide to cross-account resource access with VPC Lattice

As organizations grow, many are migrating from large, monolithic applications to a microservices architecture. Each service is often owned by a different team, and these teams prefer to run their services in their own dedicated Virtual Private Clouds (VPCs). This gives them freedom, enhances security, and allows them to manage their resources without impacting others. With this approach, the application can eventually escalate to look like the one shown below.

This creates a new challenge: how do you get all these services, now isolated in dozens of different VPCs, to communicate with each other securely and efficiently?

To solve this connectivity problem, network teams naturally reached for tools like VPC Peering or AWS Transit Gateway. But managing a microservices setup with these tools can be difficult. You find yourself lost in a complex mesh of VPC peering connections, trying to debug why the services can’t talk to each other. Or perhaps you’ve spent weeks planning IP address ranges to avoid CIDR overlaps as more teams launch their own VPC.

VPC peering is great for simple one-to-one connections, but it doesn’t scale. As you add more VPCs, you end up with a messy web of connections that’s difficult to manage. Transit Gateway solved this by creating a central hub, but it still operates at the network layer, layer 3. This means you’re still responsible for managing route tables, network ACLs, and IP address ranges.

So, why is VPC Lattice a massive upgrade?

Simply put, VPC Lattice works at the application layer, layer 7. It completely abstracts away the underlying network. Instead of thinking about IP addresses and routing, you start thinking in terms of services and policies. It offers these benefits:

• No more IP management: Forget about CIDR overlaps. Services connect by name, not by IP address.

• No more complex routing: VPC Lattice handles the routing automatically. You just define which services can talk to each other.

• Developer-friendly: Developers can connect their applications across accounts and VPCs without needing to become network engineers.

VPC Lattice fundamentally shifts how we build and connect applications in the cloud. In this newsletter, we’ll explore VPC’s core concepts and how they work together.

Inside the VPC Lattice#

For clarity, we can break down the connection workflow into three distinct parts: the service side, the resource side, and the VPC Lattice layer.

Service side (defining and publishing services)#

First, you have the foundation–the Service Network. Think of this as a logical boundary for your application, a private, members-only club for your services. It acts as a central hub where you can manage security, access, and observability for an entire collection of services, regardless of which VPC or AWS account they live in.

Next, you have the members of the club: the Services themselves. In VPC Lattice:

• A service is a logical pointer to your application, whether it’s an API, a back-end process, or a website.

• All of the services in your VPC Lattice are registered in a centralized repository called a Service Directory.

• Each service has one or more Listeners, which act as the front door, defining the protocol, like HTTP/HTTPS, and the port number it accepts traffic on.

Once a request arrives at a listener, it’s intelligently routed to a Target Group. These target groups are the collections of actual compute resources running your code, for example, EC2 instances, Lambda functions, or containers. This is also where you can leverage powerful features like Weighted Targets to safely roll out new versions by sending a small fraction of traffic to them first, perfecting your canary deployments.

Between the listener and the target group, VPC Lattice applies RulesVPC Lattice offers authentication policies, which are rules that determine who can access your service and how they prove their identity. These policies work alongside authorization policies to secure communication between services and clients. . Rules define how requests are routed, for example, based on URL paths, HTTP headers, or request methods. They let you set up flexible routing policies, such as sending /api/* requests to one target group and /images/* to another.

VPC Lattice layer (managing associations and traffic flow)#

So, how do your applications in VPCs join this club and find each other?

VPC Lattice provides two distinct ways for a VPC to connect to a service network, giving you flexibility in your network architecture.

• VPC association: A VPC association is the most straightforward method of associating a VPC with a service network. You essentially plug in the entire VPC, allowing all its resources within the VPC to access the service network. VPC Lattice automatically creates network interfaces in the subnets.

• VPC endpoint: To address this constraint, the VPC Lattice allows us to connect multiple service networks to a VPC through a VPC endpoint of type service network. To allow your VPC to access a VPC Lattice service network, you create a service-network endpoint (a type of VPC endpoint). This provision attaches ENIs to the selected subnets in your VPC, routing traffic to services and resources within the service network via these dedicated gateways. This design centralizes traffic for easier inspection and logging, and enables controlled access using DNS-based discovery. Each endpoint supports access to exactly one service network. To connect to multiple service networks, simply deploy additional endpoints.

And how do individual VPC resources get exposed through the service network?

A VPC resource is any backend in your VPC, including EC2, DB, Lambda, IP, DNS, etc, that can be consumed across accounts and VPCs using the Lattice service network.

We can associate VPC resources with a service network through a resource configuration to allow a specific resource to connect to the service. A resource configuration defines a resource or a group of resources that you want to expose to clients in VPCs or accounts.

The key component here is the resource gateway. A resource gateway acts as the bridge between your compute resources in a VPC and the service network, managing traffic routing between your workloads and the Lattice service network.

How to connect the building blocks #

Putting these pieces together is straightforward. Here’s the high-level process of how a network engineer can set up infrastructure to connect a service to a resource in a VPC using VPC Lattice:

1. Create a service: First, you define your application in VPC Lattice. This involves creating a service and pointing it to your target groups of resources, for example, your EC2 instances or Lambda functions that will handle the requests.

2. Create a service network: Next, you establish the logical boundary by creating a service network. This will group your services under a central policy and provide a single discovery endpoint. You then associate your new service with this network.

3. Associate VPCs: Now, you connect your existing infrastructure. You must associate the service network with both the consumer VPCs, where the clients are, and the producer VPCs, where the services run.

4. Configure authentication: Finally, you lock it down. Set your IAM policies on the service network and individual services to define exactly who and what is allowed to access them.

And that’s it. With these steps, your services can now talk to each other securely across account and VPC boundaries without needing VPC peering, NAT gateways, or complex routing.

Cross-account connections with AWS RAM#

One of VPC Lattice’s most powerful features is how it natively handles connectivity across different AWS accounts. This is important for modern cloud architectures, where different teams manage their services in separate, isolated accounts.

VPC Lattice achieves this by integrating directly with AWS Resource Access Manager (RAM). RAM is a service that allows you to securely share your AWS resources with other AWS accounts or within your AWS Organization.

The process is simple and secure:

1. Create and share: A central networking or administrative account creates the VPC Lattice service network and uses AWS RAM to create a resource share.

2. Invite consumers: The owner of the service network invites other AWS accounts to access the share. This is like sharing a Google Doc with specific people; you maintain ownership and control over who has access.

3. Accept and connect: The consumer accounts receive an invitation. Once they accept, the shared service network appears in their VPC Lattice console as if it were their own resource. They can then associate their VPCs and services with this shared network.

This allows services in an application team’s account to securely communicate with services in a database team’s account without any VPC peering, Transit Gateways, or complex route table management.

Is VPC Lattice only for a microservices architecture?#

VPC Lattice is a versatile tool that can solve networking challenges for a variety of application architectures. Here are a few examples:

Imagine your organization has a central authentication, logging, or payment processing service that many different applications need to use. Instead of setting up complex network connections from every application’s VPC to the shared service’s VPC, you can simply expose the shared service through VPC Lattice. This provides a single, secure, and discoverable endpoint for all other teams to connect to, simplifying both development and security governance.

Furthermore, it simplifies hybrid cloud and on-premises connectivity. VPC Lattice can extend its simplified networking to your on-premises data centers. By connecting your on-prem network to AWS via Direct Connect or VPN, you can register on-premises applications as targets in a VPC Lattice target group. This allows your cloud-native services in AWS to securely communicate with a legacy database or monolithic application running in your data center as if it were part of the same logical network.

VPC Lattice pricing#

Amazon VPC Lattice features a straightforward, consumer-focused pricing model designed to encourage collaboration. Service producers pay no charges for creating or sharing their services. All costs fall on the consumer side and are based on what is used:

1. An hourly fee of about $0.02–$0.04 applies to each service associated with the service network.

2. Monthly charge for the requests processed if they exceed the free tier limit.

3. Standard usage fees for data processing ($/GB).

This pay-as-you-go structure ensures that costs scale directly with consumption.

What’s next?#

This is just one piece of the powerful world of AWS Networking. If you’re excited to continue your journey, we highly recommend exploring these foundational services that provide the context for why a service like VPC Lattice is so revolutionary.

1. Understanding Networking Services in AWS—From Zero to Hero: In this Cloud Lab, you’ll become proficient in network services by creating a VPC, security groups, and load balancers.

2. Accessing AWS Services over AWS PrivateLink Using VPC Endpoints: In this Cloud Lab, you’ll deploy a back-end server and a front-end application in two different VPCs, allowing them to communicate using AWS PrivateLink.

3. Connecting Multiple VPCs Using Transit Gateway: In this Cloud Lab, you’ll learn how to connect multiple VPCs using AWS Transit Gateway, deploy a React app across VPCs, create instances, and efficiently route traffic.

By exploring these services, you’ll gain a comprehensive understanding of the challenges that VPC Lattice was designed to solve.

Ready for a challenge?#

Put your skills to the test by designing a secure Multi-tier VPC for web applications. This is a real-world scenario that mirrors what network engineers build in production.