Build secure application networks with VPC Lattice, Amazon ECS, and AWS Lambda


In this post, we’ll explore how to publish and consume services running on Amazon Elastic Container Service (Amazon ECS) and AWS Lambda, as Amazon VPC Lattice services. For an introduction to Amazon VPC Lattice, please read the documentation here.

One main reason customer experience a lower velocity of innovation, is the complexity they deal with while trying to ensure that their applications can communicate in a simple and secure way. Amazon VPC Lattice is a powerful application networking service that removes this complexity, and gives developers a simpler user experience to share their application and connect with dependencies without having to setup any of the underlying network connectivity across Amazon Virtual Private Clouds (Amazon VPCs), AWS accounts, and even overlapping IP addressing. It handles both application layer load balancing and network connectivity, so that developers can focus on their applications, instead of infrastructure.

Solution overview

High-level solution architecture representing how to build secure application networks using VPC Lattice, Amazon ECS, and AWS Lambda

Figure 1: High-level solution architecture

While most AWS compute options include native integration with Amazon VPC Lattice, Amazon ECS requires an Amazon Elastic Load Balancing (ELB), either an Application Load Balancer (ALB) or Network Load Balancer (NLB), to frontend Amazon ECS services. For this walkthrough, we use an ALB to connect Amazon ECS service to an Amazon VPC Lattice Service Network. You can also associate a second ALB and listener to an Amazon VPC Lattice service to perform safe Amazon ECS deployments, such as blue/green or canary testing.

In this post, we use a sample retail store application to demonstrate how you can easily connect applications deployed on Amazon ECS and AWS Lambda using Amazon VPC Lattice, but you could also integrate services with other types of AWS compute. Original source code of this application can be found at this repository.

High level application overview of the retail store application.

Figure 2: Application overview

The application has three main components:

  1. Retail Storefront serves the HTML user interface (UI) and aggregates calls to the backend Application Programming Interfaces (APIs) for the internet-based users.
  2. Checkout service provides an API for storing customer data during the checkout process.
  3. Orders service provides an API for storing order information.

Retail storefront application is running on Amazon ECS and is exposed to internet users via public ALB. Checkout service is running on Amazon ECS, and Orders service is running on AWS Lambda. Both are published as Amazon VPC Lattice services and accessible with in the Amazon VPC Lattice service network.

All of these services utilize HTTPS and custom domain names to communicate with each other. So, Secure Sockets Layer (SSL) Certificates issued to custom domain name, are installed on Amazon VPC Lattice service listeners, public, and private ALB resources. Note: when exposing HTTPS Amazon ECS services via Amazon VPC Lattice, you have to use same SSL Certificate on both private ALB and Amazon VPC Lattice listener. Refer HTTPS listeners for VPC Lattice services for more details.



You will need the following for this walkthrough:

Step 1: Access the AWS CloudShell and install the prerequisites

  • AWS CloudShell is a browser-based shell, you can quickly run scripts with the AWS CLI, The AWS CloudShell icon appears in AWS Regions where it is available.
  • Navigate to the Cloud Shell or choose the terminal icon on the right-hand upper portion, as shown in Figure 3.

AWS Console to launch CloudShell

Figure 3: AWS Console

  • Install dependencies
npm install -g -f aws-cdk@2.87.0
  • Ensure AWS CLI is configured properly:
    • Access the AWS CloudShell from required region or configure AWS CLI using aws configure for desired AWS_REGION
    • Ensure the role being used from AWS CLI has the permissions required for resources being created by AWS Cloud Development Kit (AWS CDK)

Step 2: Deploy the solution using AWS CDK

git clone
  • Navigate to the repository
cd connect-ecs-lambda-workloads-using-amazon-vpc-lattice
  • To work with the AWS CDK, you must have an AWS account and credentials and have installed Node.js and the AWS CDK Toolkit. You also need TypeScript itself (version 3.8 or later). If you don’t already have it, then you can install it using npm.
sudo npm install -g typescript
  • Install dependencies and build
npm install
  • Update the below lines with your own values in ./bin/scripts/
export AWS_REGION="us-west-2"
export HOSTZONE_ID=<<Your_Route53_HostedzoneId>>
  • Test the build
  • Deploy the application, which takes about 5 minutes to complete.
  • Once the deployment has completed successfully, you’ll see output similar to the following:
synthesis time: 12.69s

✨ Deployment time: 284.82s

LatticeEcsLambdaBlogStack.uisvcuiURLCAED6E74 =
LatticeEcsLambdaBlogStack.orderslambdastackordersURL085B6DBD =
LatticeEcsLambdaBlogStack.checkoutsvccheckoutURL1D72AA08 =

Step 3: Navigate to the AWS Console and review the deployed resources

Retail store frontend service

The following resources are created by the AWS CDK for the store frontend service:

  • An Amazon VPC
  • Public and private subnets
  • Network Address Translation (NAT) gateway
  • Amazon ECS cluster
  • ALB
  • UI Amazon ECS service

Retail store frontend application architecture overview

Figure 4: Retail Store Frontend overview

When the tasks and services are in the RUNNING state, your Amazon UI Amazon ECS cluster looks like the following examples:

Retail store frontend Amazon ECS Service

Figure 5: Retail store frontend Amazon ECS service

Checkout service

The following resources are created by the AWS CDK for the checkout service:

  • An Amazon VPC
  • Public and Private subnets
  • NAT gateway
  • Amazon ECS cluster
  • ALB
  • Checkout Amazon ECS service

High level architecture of Checkout service

Figure 6: Checkout service overview

Checkout service is exposed through a private ALB, so that it is reachable only from Amazon VPC Lattice service network.

When the tasks and services are in the RUNNING state, your Amazon Checkout ECS cluster looks like the following example:

Checkout Amazon ECS service

Figure 7: Checkout Amazon ECS service

Orders service

Order service is running using AWS Lambda with Python 3.10 runtime:

Orders AWS Lambda function

Figure 8: Orders AWS Lambda function

Step 4: Configure the connectivity between services

  • We are running Store front UI and checkout services in separate VPCs. The orders service is running as AWS Lambda. All VPCs have been deployed with Classless Inter-Domain Routing (CIDR), which demonstrates Amazon VPC Lattice’s ability to cater for overlapping IP address ranges without needing any networking constructs. For the purpose of this post, all resources were deployed in a single AWS account; however, in practice these could be spread across multiple accounts and shared using AWS Resource Access Manager (AWS RAM).
  • Amazon VPC Lattice simplifies service-to-service communications between applications across VPCs without the need for transit gateway or VPC peering.
  • Review Amazon VPC Lattice in the AWS Management Console under VPC -> VPC Lattice, where you can see the Amazon VPC Lattice service networks, services, and target groups.

Overview of Amazon VPC Lattice service network

Figure 9: Amazon VPC Lattice service network overview

Amazon VPC Lattice service network console

Figure 10: Amazon VPC Lattice service network console

Amazon VPC Lattice services console

Figure 11: Amazon VPC Lattice services

Amazon VPC Lattice target groups

Figure 12: Amazon VPC Lattice target groups

  • You can find the Retail store frontend endpoint in AWS CloudFormation Console, similar to the following:

AWS CloudFormation stack outputs

Figure 13: AWS CloudFormation stack outputs

  • Let’s take a look at this instance of the application just deployed:

Retail store application

Figure 14: Retail store application

This demonstrates UI service is calling the Checkout and Orders services via the Amazon VPC Lattice service network, even though they are running in different VPCs. The following figure gives a visual representation of various constructs involved in Amazon VPC Lattice service configuration.

Amazon VPC Lattice service network overview

Figure 15: Amazon VPC Lattice service network overview

Cleaning up

To avoid incurring any additional costs, destroy all the infrastructure that you provisioned in relation to the solution described in this post.



In this post, we showed you how you can utilize Amazon VPC Lattice to connect services running across Amazon ECS and AWS Lambda. We used custom domain names for easy service discovery and SSL certificates to implement end-to-end encryption. You can extend this solution to implement AWS IAM-based authorization policies among the Amazon VPC Lattice services and perform canary- or blue/green-style safe deployments.

Call to action

We encourage you to try this walkthrough to connect services running on Amazon ECS and AWS Lambda using Amazon VPC Lattice. Visit the Amazon VPC Lattice product page, documentation, and pricing page for additional information.

Ashok Srirama

Ashok Srirama

Ashok is a Sr. Containers Specialist Solutions Architect at Amazon Web Services, based in Washington Crossing, PA. He specializes in serverless applications, containers, and architecting distributed systems. When he’s not spending time with his family, he enjoys watching cricket, and driving.

Hemanth AVS

Hemanth AVS

Hemanth is a Sr. Containers Specialist Solutions Architect at AWS. He helps customers modernize their applications and build application platforms using AWS container services. He is passionate about cloud and cloud native technologies.

Satish Katpally

Satish Katpally

Satish is a Principal Specialist for networking services at AWS. He is a patent holder with technical and business experience in cloud IaaS/PaaS/SaaS, SDN, SD-WAN, data center networking, containers/Kubernetes, IoT, data analytics, and NFV. He holds B.E and M.S degrees in computer science and engineering, and an MBA with high distinction and a Zell Scholar award from the University of Michigan.

Tim Dormer

Tim Dormer

Tim is a Sr. Specialist Application Networking Solutions Architect at AWS, who has been helping customers deploy networks at scale for over twenty years. based in Northern California who enjoys hiking, and traveling, with his family.