Ending Complexity: How AWS VPC Lattice Simplifies Service-to-Service Communication
The Hands-On Guide to Seamless Service Connectivity in Multi-Account and Multi-VPC Environments.
Hi everyone!
In this article, we’ll dive deep into AWS VPC Lattice, the solution AWS designed to radically simplify service-to-service communication.
Our focus goes beyond theory. We’ll break down Lattice, showing how it works in practice and what happens behind the scenes when you implement it.
This service makes it easier for applications and services running across different VPCs and/or accounts to communicate, without the need to manually configure complex networks. It handles connectivity, security, and monitoring in an integrated way. In short, VPC Lattice is built to simplify complex connectivity across thousands of services in multiple VPCs and accounts!
This post is for the AWS networking folks and the dev teams alike. By the end, you’ll have all the info needed to dive deep into VPC Lattice!
Dividing this post into 6 steps for complete understanding by the end of the reading:
- What is AWS VPC Lattice?
- Advantages of using VPC Lattice
- Most common use cases
- An short Overview
- Let’s do a hands-on demo
5.1) Communication Model with Transit Gateway
5.2) Communication Model with VPC Lattice - Conclusion
1) What is AWS VPC Lattice?
So AWS just rolled out this thing called VPC Lattice. The whole point is to make that internal chatter between all your apps and microservices (what they call “east-west traffic”) way simpler and, most importantly, way safer.
The big idea with Lattice is to use a zero trust security model. Basically, it stops caring where something is sitting in your network and starts focusing on strong authentication. Every single request has to be checked and approved using super-detailed permission policies. (That's the idea!)
All About That Internal Traffic
Lattice focuses purely on “east-west” communication, think server talking to server inside your own cloud environment. It’s different from “north-south” traffic, which is your external stuff, like customers hitting your public APIs or general internet traffic going in and out. This is strictly horizontal connectivity.
Cutting Down the Networking Hassle
You can use Lattice across one AWS account or several, and the main goal is just cutting down on how much manual network configuration you have to do.
Setting up app-to-app connectivity used to mean messing around with routing tables, VPC Peering, PrivateLink, and Transit Gateway. Honestly, it was a pain, lots of back-and-forth between the dev teams (who just want stuff running fast) and the networking folks (who need things secure and structured).
The Modern Way
VPC Lattice is a much smoother option. It gives specific tools tailored for those different teams, making network orchestration simpler and offering solid benefits over the old school methods. You get faster setup times and a much tougher, modern security setup based on those authorization policies.
2) Advantages of using VPC Lattice
2.1) Zero-trust authorization with IAM is supported (Every request is verified, even if it originates inside the same VPC)
2.2) Using Network Abstraction, the AWS VPC Lattice does not use IP addresses or Elastic Network Interfaces (ENIs) directly within your VPC because it abstracts the traditional network and operates as a service layer, focused on logical (through DNS-based discovery) and secure connectivity between services, without relying on the VPC’s underlying network infrastructure, and without overlapping IP ranges and CIDR blocks.
2.3) No proxy, service mesh, or container sidecars are required due that IAM-based authentication and authorization replaces the need for proxy-based security enforcement, and all routing, discovery, and policy enforcement are handled natively by Lattice, without external mesh logic.
2.4) AWS VPC Lattice greatly simplifies observability by providing centralized logging and auditing of traffic between services, natively integrated with CloudWatch and CloudTrail, enabling monitoring of both activities and the identities responsible for executing them
2.5) AWS VPC Lattice includes fully managed load balancing by AWS, supporting rule-based HTTP request routing and gradual traffic distribution between service versions, simplifying operations without the need to configure additional load balancers.
3) Most common use cases
- Enables services across different VPCs and accounts to communicate securely and consistently, without relying on VPC Peering or Transit Gateway, adding flexibility and granularity to the communication process.
- Applications running on EC2, ECS, EKS, and Lambda benefit from HTTP/GRPC routing, IAM-based authentication, and managed load balancing, simplifying architectures while shifting scalability responsibilities to the service itself.
- Companies running large numbers of microservices can securely, scalably, and simply expose their APIs to different teams within the organization. AWS VPC Lattice enable APIs to all AWS Organizations, with custom DNS, IAM-based authentication, and managed load balancing, ensuring efficient service-to-service communication while automatically handling scalability.
4) An Short Overview
Before we roll up our sleeves, let’s go over some key concepts about AWS VPC Lattice.
4.1) Lattice Service / Service Types
The VPC Lattice offers 4 types of services.
- Lambda Functions
- Application load Balancer (internal)
- EC2 Instances
- Fargate / ECS / EKS and All Features that use IP
It's a logical unit within VPC Lattice that represents a resource or application published in the Service Network. It can be a Load Balancer, an EC2 instance, a service in ECS/EKS, or even a DNS/IP endpoint.
By creating a Lattice Service, you are essentially saying: "This is the service I want to make available for consumption within the Service Network."
4.2) Lattice Service Network
It's the logical domain within VPC Lattice that connects services and consumers across different VPCs and accounts. It acts as a shared network space where services can be published and discovered, enabling secure and controlled communication between applications.
By associating VPCs, Endpoints and services, you are essentially saying: ‘These are the services and clients that should interact within this network.’
4.3) Lattice Target Group
It's the backend component that directs traffic from a Lattice Service to its actual target (Lambda, EC2, containers, etc). It ensures requests are routed and balanced across these targets, providing scalability and availability for the application. (Visible only for service usage)
4.4) Lattice Resource Gateway e Resource Configuration
I will explain both together, as I believe it will be more didactic.
The Lattice Resource Gateway and the Lattice Resource Configuration work together to allow private resources in a VPC to be securely accessed through VPC Lattice. The Resource Gateway is the "physical infrastructure" within the VPC, acting as the entry point that receives external traffic and forwards it into the network. The Resource Configuration, on the other hand, is the "logical definition" that identifies which resource will be exposed and how it can be accessed, specifying IPs, DNS, ports, and protocols. Together, they ensure that traffic reaches the correct destination, combining the role of a "door" (Gateway) with that of an "identity badge" (Configuration).
4.5) Lattice Resource Configuration
It connects the Lattice Resource Gateway to the actual resource within the VPC, specifying the destination (such as a Load Balancer, EC2 instance, ECS/EKS service, IP, or DNS). It ensures that traffic received through the Service Network or PrivateLink Endpoints is correctly routed to the published resource, enabling secure and controlled communication between the consumer and target resource without the need for peering or complex configurations.”
4.6) Association Types
AWS VPC Lattice allows 5 basic types of associations:
- VPC Association — Association from VPC to Lattice Service Network;
- Endpoint Association (Service Network)— Association from Service Network Endpoint to Lattice Service Network;
- Resource Configuration Association — Association from Lattice Service Network to Lattice Resource Configuration;
- Endpoint Association (Resource) — Association from Resource Endpoint to Lattice Resource Configuration
- Service Association — Association from Lattice Service Network to the Lattice Service
4.4) Security Policies
Amazon VPC Lattice works with two types of authentication policies:
• Service Network Policy (applied at the service network level).
• Service Policy (applied at the individual service level).
Both are IAM-style policy documents that define who can access what through VPC Lattice.
These policies provide an excellent opportunity to strengthen service defenses by enabling granular access controls. Although optional, requests in all IAM scenarios must be signed, as a result, the default access behavior is Deny. Therefore, if you want to allow requests, you must explicitly define an authorization policy.
The IAM principal must be granted the appropriate VPC Lattice permissions (such as vpc-lattice:Invoke), and any request must carry a valid signature that matches both the service scope (vpc-lattice-svcs) and the intended AWS region.
Later on, you’ll see this in action as I test the service execution first with a more restrictive policy, and then with a more permissive one.
5) Let’s do a hands-on demo
For this hands-on, my plan is to start by presenting a simple architecture without VPC Lattice. Then, we’ll run the same application in an environment that uses VPC Lattice, so you can clearly see the difference.
Using the diagram we introduced earlier, the one we’re already familiar with, we’ll move forward with a few adjustments to illustrate the changes.
5.1) Communication Model with Transit Gateway
Here we follow a standard network architecture, where the consuming application at source “A” running on an EC2 instance, makes a request to an Application Load Balancer at destination “B” In this example, the Load Balancer triggers a Lambda function, although it could also invoke other interfaces, out lab will focus on Lambda.
Components Used
Transit Gateway: A Transit Gateway is provisioned to enable secure connectivity between the Consumer VPC "A" and VPC "B".
VPC attachments: The APPs from VPC "A" and VPC "B" must be associated with the Transit Gateway Route table, and it's possible with this Association.
TGW Routing Tables: these routing tables are has the rules of communication that each VPC could do.
Internal Application Load Balancer (ALB): the service used as a single way to Access the Target resource.
Lambda: A serverless computacional resource that will be used as our target execution.
In our hands-on, I won’t be creating three accounts. Instead, I’ll set up two VPCs, “A” and “B” within my project account, and that will be enough to demonstrate the functionalities we discussed earlier.
5.1.1) Let's create the VPC environment!
I’ve started creating VPC “A” and VPC “B,” as shown in the diagram below. For both, I used the creation wizard and implemented the following resources:
- No IPv6 CIDR block
- 2 subnets privadas em AZs diferentes
- No public subnets
- One Internet Gateway. (Only VPC-A)
- One Nat Gateway (Only VPC-A)
- DNS options (All Enable : DNS hostnames and DNS resolution)
List of VPCs created
VPC-B details: Subnets and Route Tables
VPC-A details: Subnets, Route Tables, Nat Gateway and Internet Gateway
Notice that when I created VPC-A, I added a NAT Gateway and an Internet Gateway to the setup. This was necessary during my tests, as I installed packages and validated connectivity with the internet using ping. In your case, you won’t need to do the same.
5.1.2) Transit Gateway and its configurations
Right after creating the Transit Gateway, simulating the action that would normally be performed in the Network account , I carried out the following steps:
• Created the VPC Attachments for VPCs A and B.
• Adjusted the VPC route table to communicate with the Transit Gateway using CIDR 0.0.0.0/0, enabling the traffic flow between the VPC and our hub.
• Created two Transit Gateway route tables, one for each VPC, and associated them with their respective attachments.
• Enabled communication between the VPCs by configuring route propagation from one to the other.
Below, you can see the route table of VPC A propagating communication with the attachment of VPC B.
Below, you can see the route table of VPC B propagating communication with the attachment of VPC A.
Note:
Once your Transit Gateway is configured, don’t forget to update your VPC route table to direct your network traffic to the Transit Gateway we just set up.
It’s a very common mistake to forget this step.
5.1.3) A quick communication test between environments
To validate communication between the two VPCs, I created two simple EC2 instances with a permissive Security Group allowing all traffic (just to enable the test without “secondary barriers”). From VPC A, I performed a ping to the EC2 instance in VPC B, and then from the EC2 in VPC B, I pinged the EC2 in VPC A.
Ping from EC2-A to EC2-B (10.100.128.206 → 10.110.132.75)
Ping from EC2-B to EC2-A (10.110.132.75 → 10.100.128.206)
Now that we know communication is working, we’ll move on to setting up the environment for VPC B.
5.1.4) Setting up the Destination Environment (VPC-B)
Now it’s time to create the resources for the “Destination” VPC-B. So far, we’ve already set up the EC2 instance in VPC-A and established the communication flow between the VPCs using the Transit Gateway from our fictitious Network account.
We’ll start by creating a simple Lambda function that simply returns a success message, as shown below.
Remember:
When creating the Lambda, it must be associated with VPC-B!
import json
def lambda_handler(event, context):
return {
'statusCode': 200,
'body': json.dumps('Hello, I have just executed my lambda \n')
}Next, we’ll create the AWS Application Load Balancer and configure its Target Group to invoke the AWS Lambda function.
Get José Carlos Carvalheira’s stories in your inbox
Join Medium for free to get updates from this writer.
We’ll begin by setting up the Target Group first.
Next, we’ll create the Application Load Balancer (ALB), where the listener will invoke our Lambda function via HTTP (port 80).
5.1.5) Now it’s time to run the Application Load Balancer.
We’ll execute our Lambda function through the front-facing ALB.
Using the “ec2-A” instance, when you run the command (curl + your ALB DNS), you will see the response from your Lambda execution!
curl <your-ALB-DNS>
Nice!! Our Lab with Transit Gateway finished successfully!
If an error occurs:
It’s possible that you may have forgotten one of the following steps:
• Create route propagation between the VPCs within the Transit Gateway route tables.
• Adjust the route table used by your VPC-A; it must include a rule sending traffic from your VPC to the Transit Gateway.
• Review your VPC configurations, as you may have missed setting them up correctly.
In the next section, I'll show you how this Architecture could be designed using VPC Lattice.
5.2) Communication Model with VPC Lattice
Here we’ll continue with a network architecture based on the AWS VPC Lattice service. This fully managed service simplifies connectivity, security, and monitoring between applications and services.
We’ll use the same communication scenario as used before, however adapted to leverage AWS VPC Lattice.
Important Note
In section 4 of that post, I presented 5 ways to create Associations, and you can create some combinations to use VPC Lattice. However, in this post I will show all communication flowing through VPC Association and Service Association!
I’ll cover the other ways of using VPC Lattice in future posts with different scenarios, just to make things more fun for us. Oops… more interactive!
So, what will we change to make the scenario that previously used Transit Gateway work solely with AWS VPC Lattice?
Now the fun begins!!!
5.2.1) Cleaning Up the environment
We’ll start by cleaning up the resources used in the previous lab with Transit Gateway, and keep only those that will be required for the second lab, which will use VPC Lattice.
- Delete the association and delegation in each Transit Gateway (TGW) route table
- Delete the Transit Gateway (TGW) route tables
- Delete the VPC Attachments
- Delete the Transit Gateway
- Delete the "VPC route table route" that points the route to the previously transit gateway deleted. (it's now on blackrole status)
- Delete the EC2 Instance Connect Endpoint related to "VPC-B"
- Delete the EC2 Instance "ec2-B"
- Delete the Application Load Balancer and Target Group created to be used in VPC-B side.
- Delete the Nat Gateway (if you created one)
- Delete the Internet Gateway (if you created one)
Important Note
• Do not delete the VPC-A and B
• Do not delete the AWS Lambda function, as it will be reused soom.
• Do not delete the EC2 Instance Endpoint from VPC-A, you will need it.
• Do not delete the EC2 "ec2-A", as it will be used during the second lab.
5.2.2) Creating the Lattice Target Group
Now that our environment is ready, start by creating a Lattice Target Group. This Target Group will be used by the “Lattice service” to define the destination of the request that will be routed through a Listener (remember, this is the B-side of our architecture).
Your service routes requests to the targets in a target group and performs health checks on the targets.
I started creating the Target Group filling the name "lattice-lab2-tg" and Event Structure version “v2”
Just select the Lambda Function that we've already used during the last Lab with Transit Gateway, and finish the Target Group creation.
Once created, it will be ready to be used during the setup of the Lattice Service.
5.2.3) Creating the Lattice Service
We'll continue building the structure of side B in our architecture, where we will create the Lattice Service. This service will act as the logical representation of the Lambda execution that will run within VPC-B.
Let's continue by creating it.
Step 1) Creating the Lattice Service
Enter the name of your Lattice Service, and for the Domain Configuration, allow VPC Lattice to generate it dynamically, since in this lab we are not using a custom domain.
Next, configure Service access with an "AWS IAM" Auth Policy, and select the policy based on the "Allow only Authenticated access" template.
You will notice that the generated statement includes a condition that prevents anonymous principals.
For this lab, since we are not using a Multi-Account environment, we are not sharing the resources created through Resource Access Manager (RAM). In this case, leave the field empty and go on creating the Lattice Service.
Step 2) Defining the routing (Our Lambda)
In this step, we will configure the internal load balancing of the Lattice Service, which is managed by AWS and ensures security and scalability when needed.
Set up the Listener on port 80 (HTTP protocol) and proceed with the registration.
When configuring the action to be applied to the Listener, choose the “Forward to target group” option and select the Lattice Target Group created at the beginning of the lab, pointing to our Lambda function. Then, click Next to proceed with the registration.
Step 3) Service Network Association
In the section for associating a Lattice Service Network, leave the field empty, since this resource has not yet been created. We will perform this association later.
Next , review the informations, and press the button “Create VPC Lattice service”
After creating the Lattice Service, an internal load balancer managed by AWS will route the requests to our Lambda function.
With this, we complete the creation of the Lattice Service resource.
5.2.4) Creating a Lattice Service Network (Network Account)
As you may have noticed, the Lattice Service Network is the core of VPC Lattice, since it organizes and connects services distributed across different VPCs and accounts in a simplified way.
The process of creating a VPC Lattice Service Network requires a few steps, as shown below:
Create >> Associate >> Define Auth Policies >> Share
We will now proceed with the creation of the "Service Network", as shown in the image below, by entering the name of our Service Network and associating it with the "Lattice Service" created earlier.
Next, the Lattice Service Network also allows associations with one or more Resource Configurations. However, in this lab we will not be using this feature, so we will leave the field empty.
In VPC Associations, according to the defined architecture, we will associate VPC-A, which will be the source of the Lambda request, along with the Security Group created for this VPC. Additionally, enable the DNS name option (I usually keep it checked with preference for all domains, but you can adjust according to your own preferences and needs).
Next, configure Network access with an AWS IAM Auth Policy, and select the policy based on the Allow only Authenticated access template.
You will notice that the generated statement includes a condition that denies anonymous principals.
Now comes an important part of the configuration. In our lab, we are restricting the Service Network sharing. However, for those using a Multi-Account infrastructure, you should select the “Allow sharing” option, which enables the association with Resource Access Manager (RAM).
After completing this step, finalize the creation of the Service Network while leaving the rest of the form unchanged.
After creating the "Lattice Service Network", you will be able to validate its associations, sharing settings, and other configurations.
Below, you can see the two associations we created, highlighted in green, and the associations that will not be part of this lab, marked in red.
With this, we have completed the creation of the Lattice Service Network resource.
5.2.5) Before-Test Tasks
Please… Pay attention to the following detail: if you are implementing a real-world scenario using different accounts, access policies must be configured to enable communication between accounts. In this case, the source account needs permission from the destination account to make the call.
For our POC, the setup allows the EC2 instance to use a very simple policy, since we are running resources within the same account.
Attach the new Role to your ec2-A instance, as it will be through this role that we execute the DNS address generated for our Lattice Service.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "vpc-lattice-svcs:Invoke",
"Resource": "<domain lattice service>/*"
}
]
}IAM Role associated to EC2 instance "ec2-A", as depicted bellow.
If you bypass this step, your EC2 instance "ec2-A" will not be able to invoke the Lattice Service, and you'll receive this message bellow.
With this, we are ready to start the tests!
5.2.6) Testing the VPC Lattice
We will now proceed with two tests, aiming not only to demonstrate the functionality of VPC Lattice but also to highlight the security that a well-structured "Auth Policy" can provide to your services.
Both "Auth Policies" were configured to deny anonymous access. In this first test, the expectation is that we will not be able to access the Lambda function, receiving an exception error!
With the current configuration, we will log into the EC2 “ec2-a” instance in VPC-A (Source / Consumer) and run the following command: (curl + Domain name of Lattice Service)
curl service-lab-0e5f2248d7c9a2574.7d67968.vpc-lattice-svcs.us-east-1.on.awsTip:
The Domain Name of the Lattice Service is available on the details page of the resource we created earlier.
Running the command:
Notice that in this first test we received the “AccessDeniedException” error, which prevents the use of anonymous users.
Just like this “Auth Policy”, many others can be applied to your Lattice infrastructure, addressing different requirements, as shown on the AWS reference site (click here).
To enable our test, since we are not using authentication, we will slightly loosen the permissions by restricting only to use the “vpc-lattice-svcs:Invoke” action.
To do this, edit the "Lattice Service Network" and "Lattice Services resources", go to the "Access settings" section, and replace the Auth Policy with the one described below.
{
"Version": "2008-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "vpc-lattice-svcs:Invoke",
"Resource": "*"
}
]
}The image below shows how the "Lattice Network Service" edit screen will look.
The image below shows how the "Lattice Service" edit screen will look.
We will now proceed with the test again. Log into the EC2 “ec2-a” instance in VPC-A (Source / Consumer) and run the following command: (curl + Domain name of Lattice Service)
Tip:
Wait a short while before executing this action, since changes of this kind in AWS VPC Lattice need to be propagated and applied across the service’s distributed infrastructure. If you try to test immediately after adjusting the Auth Policies, you may still encounter the same error as before.For safety, I waited about 2 minutes — a perfect opportunity to grab a coffee!
Notice that this time our source service (Side A) successfully executed the destination service (Side B) using only the power of VPC Lattice!
The Network topic is truly fascinating, don’t you think?
6. Conclusion
Throughout this post, we have seen that Amazon VPC Lattice is not just another networking tool, but a true orchestrator of communication between services. It simplifies what once required complex architectures, multiple peerings, and manual configurations, delivering a seamless and secure experience for multi‑VPC and multi‑account environments.
With Lattice, it became clear that a simple Lambda execution between different services is no longer a challenge, but rather a native, scalable, and observable capability where security and governance go hand in hand.
The most impressive aspect is the network abstraction performed by the VPC Lattice Service Network, enabling services located in overlapping networks to communicate without issues.
Even though this post was a bit long, we only explored a small portion of VPC Lattice’s potential. Much more can be achieved by adopting this approach, paving the way for a more agile, resilient infrastructure prepared for the modern challenges of the cloud.
I hope this was helpful. Follow me and share this post.
See you next time!
