Networking & Content Delivery
Automating large scale deployments with tags for Amazon VPC Lattice
Introduction
Since their introduction in 2010, tags have been helping Amazon Web Services (AWS) customers identify, organize, and manage their resources by adding referenceable key/value pairs. In this post, we explore how tags can be used to automate the addition and removal of Amazon VPC Lattice resource associations, and cross account resource shares using Amazon EventBridge, AWS Lambda, AWS CloudTrail, and AWS Resource Access Manager (AWS RAM). These methods can be used within a single AWS Organization or across multiple AWS Accounts, supporting multiple use cases such as vendor/client applications.
Amazon VPC Lattice is an application networking service that consistently connects, monitors, and secures communications between your services, helping to improve productivity so that your developers can focus on building features that matter to your business.
To gain the most from this post, you should have a foundational knowledge of VPC Lattice. For an introduction to VPC Lattice, you can read Build secure multi-account multi-VPC connectivity for your applications with Amazon VPC Lattice, and watch the VPC Lattice RAM demo video.
Concepts
Before going into how tags can be used to automate creation and deletion of VPC Lattice resource associations, let’s look at the manual process of configuring VPC Lattice:
- Create a VPC Lattice service for an existing application, service, or microservice, which could be running on any type of AWS compute: instances, containers, or serverless.
- This new VPC Lattice service is then associated with one or more new or existing VPC Lattice service networks.
- For clients to consume this VPC Lattice service, the client VPC must be associated with the VPC Lattice service network containing the required VPC Lattice service.
Note: VPC Lattice services can be associated with many VPC Lattice service networks, whereas VPCs can be associated to a single VPC Lattice service network. VPC Lattice service networks are often tailored to fit the requirements of one or more VPC’s with common connectivity requirements. More information can be found in the VPC Lattice user guide.
To share VPC Lattice resources with other AWS accounts we use AWS RAM with options for sharing either individual VPC Lattice services or entire VPC Lattice service networks, depending on your requirements.
- Shared VPC Lattice service network: both provider and consumer accounts can add and remove VPC Lattice service associations with shared VPC Lattice service networks.
- Centralized VPC Lattice service network: the provider account can share VPC Lattice services. The consumer account manages the shared VPC Lattice service to local VPC Lattice service network associations.
Solution overview
We will cover automating bulk association creation and deletion based on the stage name tagged to services and VPCs. This implementation can be modified to use any tag key/value pairs to fit many additional use-cases. For our automation requirements we will use three personas, each with their required permissions:
- Service Owner: responsible for managing the creation and deletion of VPC Lattice services, and sharing of individual VPC Lattice services through AWS RAM.
- VPC Owner: responsible for creating and deleting VPC to Lattice service network associations.
- Network Admin: responsible for creating and deleting VPC Lattice service network associations, and sharing those VPC Lattice service networks with other accounts using AWS RAM.
Note: tag key values are case-sensitive
We will focus on the following three use cases:
- Automating VPC Lattice service-to-service network associations.
- Automating VPC-to-VPC Lattice service network associations.
- Automating VPC Lattice service associations across accounts through AWS RAM.
Use case 1: Automating VPC Lattice service-to-service network associations
In this first use case, we cover how you can move a VPC Lattice service from one VPC Lattice service network association to a new VPC Lattice service network association. We will show you how to create an EventBridge rule looking for a tag called “stage” on the VPC Lattice service. When you change it, it will do the following:
- Delete the initial VPC Lattice service to service network association.
- Create a new VPC Lattice service to service network association based on the tag value. Note: only users or roles with the appropriate permissions should be able to change tags.
1. Network Admin
- Shares their VPC Lattice service networks tagged “stage = gamma”, and “stage = prod” to certain accounts or an entire organization using AWS RAM.
- Organization may be restricted to use only specific tag values for specific tag keys. You should also check the use of tags if your organization is using AWS IAM’s Attribute-based access control, (ABAC), such that they must create resources by including a key/value including a key equal to “stage”, with a value equal to “beta”, “gamma”, or “prod”.
2. Service Owner
- Creates a VPC Lattice service with tags, or adds tags to a VPC Lattice service with some specific key/value pair (e.g., stage = gamma), as shown in Figure 1.
- The tagged VPC Lattice service is automatically associated to the VPC Lattice service network tagged with “stage = gamma”.
- Service Owner changes the tag on their VPC Lattice service to “stage = prod”, as shown in Figure 2.
- The previous “stage = gamma” VPC Lattice service network association is deleted and a new one is automatically created for the VPC Lattice service network tagged with “stage = prod”.
- The Service Owner deletes the stage tag on their service.
- The association to the VPC Lattice service network tagged with “stage = prod” is automatically deleted.
- VPC Lattice service is tagged with both “stage = gamma” and “stage = prod”. VPC Lattice service-to-service network associations are automatically created for all VPC Lattice service networks tagged as “stage = gamma or prod”, as shown in Figure 3.
Use case 2: Automating VPC-to-VPC Lattice service network associations
In the previous use case, we showed you how to use a tag on the VPC Lattice service to move VPC Lattice service-to-service network association from one service network to another service network. In this use case, we automate moving the VPC-to-VPC Lattice service network association based on the VPC tag value. To do this, we must use AWS CloudTrail to identify the VPC tag value change, which is then sent to EventBridge. Next, EventBridge triggers a Lambda function which:
- Deletes then initial VPC-to-VPC Lattice service network association.
- Creates a new VPC-to-VPC Lattice service network association to the VPC Lattice service network specified by the VPC tag.
Note: The tag on both the VPC Lattice service network and VPC are used for the service network to VPC associations.
1. Network Admin
- Shares their VPC Lattice service networks with tag values “stage = gamma”, and “stage = prod”, to certain accounts or an entire organization using AWS RAM.
- Organization may be restricted to only use specific tag values for specific tag keys, and may be affected by AWS Identity and Access Management (IAM) attribute-based access control, (ABAC), such that they must create resources by including a key/value pair with the key equal to “stage”.
2. VPC Owner
- Creates a VPC Lattice service with tags, or adds tags to a VPC Lattice service with some specific key/value pair (e.g., stage = gamma), as shown in Figure 4.
- The tagged VPC is automatically associated with the VPC Lattice service network tagged “stage = gamma”.
- VPC Owner changes the tag on their VPC Lattice service to “stage = prod”, as shown in Figure 5.
- The existing VPC-to-VPC Lattice service network association is deleted and a new one is automatically created to the VPC Lattice service network tagged with “stage = prod”.
- VPC Owner deletes the stage tag on their VPC.
- The association to the VPC Lattice service network tagged “stage=prod” is automatically deleted.
Use case 3: Automating VPC Lattice service associations across accounts via AWS RAM
Using AWS RAM, you can share either individual VPC Lattice services or service networks with other AWS accounts. When a VPC Lattice resource share is deleted through AWS RAM, the association still exists, which you are required to remove. In this use case, we share an individual VPC Lattice service from the provider account to a consumer account based on its tag. When the tag is changed the automated process:
- Removes the AWS RAM resource share and deletes the existing VPC Lattice service association.
- Creates a new AWS RAM share and corresponding association. You can add accounts with which you would like to auto approve shares to an allow list. It’s also possible to build a notification and approval process using Amazon Simple Notification Service (Amazon SNS), which is outside the scope of this post, an example of an email approval process can be found here.
1. Service Owner
- Creates a service with tags, or adds tags to a service with some specific key/value pair (e.g., stage = gamma), as shown in Figure 6.
- The tagged service is automatically shared to the Network Admin with a Resource Share called “gamma”.
- Service Owner changes the tag on their service to “stage=prod”, as shown in Figure 7.
- The “gamma” resource share is automatically deleted and a new one is created, called “prod”.
- Service Owner deletes the stage tag on their service.
- The “prod” share is automatically deleted.
2. Network Admin
- May share service networks with VPC Owners, or may be the VPC Owner themselves. Does not share service networks with Service Owners.
- Upon receiving a resource share containing a service from a Service Owner, the shared service is automatically associated with its corresponding VPC Lattice service network.
- Upon deletion of a resource share containing a service from a Service Owner, the association between that unshared service and its corresponding service network is deleted.
- Auto acceptance can be enabled to support AWS RAM sharing between accounts in the same Organization.
Design
We have created four AWS CloudFormation stacks to support the aforementioned use-cases. The Network Admin may be the same account as the Service Owner or VPC Owner, or sharing their network cross-account. The Service Owner and VPC Owner may also be the same account.
Use case 1: Automating VPC Lattice service to service network associations
Service Owner stack
EventBridge Rule
- Invokes Service Owner Lambda Function
- Triggered by change in tags on VPC Lattice Services, such that the tag change contains “stage” key
Lambda Function
- Invoked by EventBridge Rule
- Creates and deletes service network service associations
Use case 2: Automating VPC-to-VPC Lattice service network associations
VPC Owner stack
CloudTrail
- Ingests API events from consumer VPC, and forwards “stage” key trigger event to EventBridge
EventBridge Rule
- Invokes Service Owner Lambda Function
- Triggered by change in tags on VPC Lattice Services, such that the tag change contains “stage” key
Lambda Function
- Invoked by EventBridge Rule
- Creates and deletes service network service associations
Use case 3: Automating VPC Lattice service associations across accounts through AWS RAM
Service Owner stack
EventBridge Rule
- Invokes VPC Owner Lambda Function
- Triggered by change in tags on VPCs, such that the tag change contains “stage” key
Lambda Function
- Invoked by EventBridge Rule
- Creates and deletes service network VPC associations
Network Admin stack
EventBridge Rule
- Invokes Service Owner Lambda Function
- Triggered by change in tags on VPC Lattice Services, such that the tag change contains “stage” key
Lambda Function
- Invoked by EventBridge Rule
- Creates and deletes service network service associations
Implementation examples
In this aws-samples repository, you will find a CloudFormation template deploying the different automations explained in this post. To test them in your AWS Account, clone the repository and deploy the YAML template found in the root folder, which asks you for the specific automation to build, and information about your environment (stages to define or AWS Accounts to interact). All the resources needed to deploy the automations (EventBridge rules/schedulers, Lambda functions, IAM roles, etc.) are deployed in the AWS Account and AWS Region where you are creating the CloudFormation stack.
For more information about each automation type, how it works, and which resources to create, look at the README file. In this file, you also find examples of multi-Account architectures with VPC Lattice and how to use the aws-samples repository to build the desired association automation. Note: in some examples, the CloudFormation template may need to be deployed in several AWS Accounts with different configurations.
Cleaning up
To clean-up the resources, simply delete the CloudFormation stack in any AWS Account and AWS Region where you have deployed the template. Note: an Amazon Simple Storage Service (Amazon S3) bucket is created with the rest of the resources, including ZIP files with the Lambda functions’ code; make sure you delete the bucket.
Conclusion
Managing associations can become challenging as your VPC Lattice deployments grow to hundreds of services. In this post, we have shown how tags can be used to simplify and automate the creation and deletion of VPC Lattice associations between service networks and VPCs or VPC Lattice services. This lets you manage your applications at scale. We created this code with the intention of it being flexible so you can adapt it to your use case. You could also make sure VPC Lattice resources are removed when an AWS RAM share is deleted, or provide access to a new service network to hundreds of VPC’s using AWS tag editor. Additional integration could include an email approval process through Amazon SNS (not shown in this post). We hope you found this post useful and can now use these ideas when building your applications.
A working demonstration of the solution can be found at The Routing Loop – Automated Network Creation With VPC Lattice and Tags
For more information refer to the following VPC Lattice resources: