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:

  1. 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.
  2. This new VPC Lattice service is then associated with one or more new or existing VPC Lattice service networks.
  3. 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:

  1. Automating VPC Lattice service-to-service network associations.
  2. Automating VPC-to-VPC Lattice service network associations.
  3. Automating VPC Lattice service associations across accounts through AWS RAM.

Use case 1: Automating VPC Lattice service-to-service network associations

Figure one shows three VPC’s in a single AWS account in a single AWS region. There is a single VPC Lattice service created from an application in VPC one. VPCs two and three are consumer VPCs “gamma” and “prod” respectively. The “gamma” consumer VPC is associated with the “gamma” VPC Lattice service network called “gamma” while the “prod” consumer VPC is associated to the “prod” VPC Lattice service network. When the tag is updated a tag change event is sent to Amazon Event Bridge which triggers a tag change rule which in turn initiates an AWS Lambda function. This AWS Lambda function will read the “stage” value and establish a VPC Lattice service to VPC Lattice service network association corresponding to the tag value. In figure one the VPC Lattice service is associated to the “gamma” VPC Lattice service network.

Figure 1. VPC Lattice service tagged “stage=gamma” associated to VPC Lattice service network tagged “stage=gamma”

Figure two builds on figure one where the “stage” tag on the VPC Lattice service has been updated to “prod”. The tag change event triggers an AWS Lambda function via Amazon EventBridge which removes the VPC Lattice service to “gamma” VPC Lattice service network association and creates a new association from VPC Lattice service to the “prod” VPC Lattice service network.

Figure 2. VPC Lattice service tag changed to “stage=prod”, disassociated from VPC service network tagged “stage=gamma”, and associated to VPC Lattice service network tagged “stage=prod”

Figure three builds on figure one and two but this time the VPC Lattice service has tags “stage = gamma” and “stage = prod” which creates two simultaneous associations from the VPC Lattice service to the both “gamma” and “prod” VPC Lattice service networks allowing both consumer VPCs to access the VPC Lattice service.

Figure 3. VPC Lattice service with tags “stage=gamma” and “stage=prod” simultaneously associated to VPC Lattice service networks tagged with “stage=gamma” or “stage=prod”

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:

  1. Delete the initial VPC Lattice service to service network association.
  2. 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

  1. Shares their VPC Lattice service networks tagged “stage = gamma”, and “stage = prod” to certain accounts or an entire organization using AWS RAM.
  2. 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

  1. 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.
  2. The tagged VPC Lattice service is automatically associated to the VPC Lattice service network tagged with “stage = gamma”.
  3. Service Owner changes the tag on their VPC Lattice service to “stage = prod”, as shown in Figure 2.
  4. 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”.
  5. The Service Owner deletes the stage tag on their service.
  6. The association to the VPC Lattice service network tagged with “stage = prod” is automatically deleted.
  7. 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

Figure four is a new diagram which has three VPC’s in a single AWS account in a single AWS region. This time we have two applications, “gamma” and “prod”, in their respective VPC’s. The applications are published as VPC Lattice services “gamma” and “prod” are associated with VPC Lattice service networks with tags “stage = gamma” and “stage = prod” respectively. There is a single consumer VPC. When a tag “stage = gamma” is attached to consumer VPC an API event is sent to AWS CloudTrail which creates a change event to Amazon EventBridge that invokes a tag change rule and an AWS Lambda function with the VCP Owner role. The AWS Lambda function creates a consumer VPC to VPC Lattice service network association based in the stage tag value. The diagram shows a consumer VPC to the VPC Lattice service network tagged with “stage = gamma” association.

Figure 4. VPC-to-VPC Lattice service network tagged “stage=gamma” association created

Figure five builds on figure four where a VPC tag “stage” value has been changed on the consumer VPC from “gamma” to “prod” which has triggered a change event, dissociating the consumer VPC from the VPC Lattice service network tagged with “stage = gamma” and creating a new VPC to VPC Lattice service network association to the service network tagged with “stage = prod” VPC Lattice service network.

Figure 5. VPC disassociated from VPC Lattice service network tagged “stage=gamma”, and new associated to VPC Lattice service network tagged “stage=prod”

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:

  1. Deletes then initial VPC-to-VPC Lattice service network association.
  2. 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

  1. Shares their VPC Lattice service networks with tag values “stage = gamma”, and “stage = prod”, to certain accounts or an entire organization using AWS RAM.
  2. 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

  1. 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.
  2. The tagged VPC is automatically associated with the VPC Lattice service network tagged “stage = gamma”.
  3. VPC Owner changes the tag on their VPC Lattice service to “stage = prod”, as shown in Figure 5.
  4. 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”.
  5. VPC Owner deletes the stage tag on their VPC.
  6. 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

Figure six shows two VPCs each in their own AWS accounts. A provider VPC in a provider AWS account and a consumer VPC in a consumer AWS account. The consumer VPC is associated to the consumer VPC Lattice service network. Both VPCs are in the same AWS region. The provider VPC has a service from which a VPC Lattice service has been created. When this service is tagged with “stage = gamma” a tag change event is sent to Amazon EventBridge which triggers a tag change rule that triggers an AWS Lambda function which creates a “gamma” VPC Lattice service RAM share based on the tag. An Amazon EventBridge scheduler in the consumer account polls RAM for shared and unshared services from the Service Owner and creates or remove VPC Lattice service to VPC Lattice service network associations.

Figure 6. Automated sharing of VPC Lattice service tagged “stage=gamma” across accounts

Figure seven builds on figure six, the tag on the VPC Lattice service in the provider account is changed from “stage = gamma” to “stage = prod” the “gamma” RAM share is removed and a new RAM share is created called “prod”. In the consumer account Amazon EventBridge polls RAM and deletes the “gamma” VPC Lattice service to VPC Lattice service network association and creates and new VPC Lattice service to VPC Lattice service network association for “prod”.

Figure 7. Update sharing of VPC Lattice service tagged “stage=gamma” to service tagged “stage=prod” across accounts

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:

  1. Removes the AWS RAM resource share and deletes the existing VPC Lattice service association.
  2. 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

  1. 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.
  2. The tagged service is automatically shared to the Network Admin with a Resource Share called “gamma”.
  3. Service Owner changes the tag on their service to “stage=prod”, as shown in Figure 7.
  4. The “gamma” resource share is automatically deleted and a new one is created, called “prod”.
  5. Service Owner deletes the stage tag on their service.
  6. The “prod” share is automatically deleted.

2. Network Admin

  1. May share service networks with VPC Owners, or may be the VPC Owner themselves. Does not share service networks with Service Owners.
  2. 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.
  3. 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.
  4. 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: