This repository implements a solution to automate Amazon VPC Lattice associations - both VPC and VPC Lattice service - within the same or cross AWS Accounts. The solution focuses in the use of tags in the VPC, VPC Lattice service network, and VPC Lattice service - or and/or AWS RAM share names when working in multi-Account environments - to map resources between each other and create the corresponding associations. The following automations are supported by this solution - in all of the, the tag key stage is the one required to automate the corresponding action:

• VPC Lattice VPC and/or service associations anytime the VPC/service's tag is updated.
• Sharing VPC Lattice service network and/or service with allowed AWS Accounts anytime the VPC Lattice service's tag is updated.
• Accept shared VPC Lattice service network and/or service (from allowed AWS Accounts) every minute, and associate them to the corresponding VPC, service, or service network.

In the section Automations you have a deeper explanation of each automation. All of them are based on the use of Amazon EventBridge to detect changes in the AWS network resources, and AWS Lambda to perform the corresponding actions.

This solution is based on a single AWS CloudFormation file (solution.yaml) that builds the following resources:

• Custom resource that stores all the Python functions as ZIP files in an Amazon S3 bucket - to build the different Lambda functions.
• Depending the automation to build, EventBridge rules and Lambda functions will be deployed.

The following inputs will determine which automations are built:

In the section VPC Lattice common architectures you will find some examples of multi-Account environments and which specific automations to build in each Account (inputs to include in each CloudFormation deployment) to have the desired functionality.

In this automation, the EventBridge rule will obtain changes in VPC tags. Once the tag stage is created/updated/removed from any of the VPCs in the Account, the following actions will be automated by a Lambda function:

• Scan all the VPC Lattice service networks in the Account (either owned or shared) and determine which ones share the same stage.
  • For service networks owned by the same Account, the tag stage will be checked.
  • For service networks shared via RAM, the RAM share name will be checked. This name should be similar to the key of the VPC tag stage.
• Given a VPC can only be associated with one service network, if several ones are scanned, the one to be associated will be selected randomly (service networks owned by the same AWS Account will be preferred).
• Updating the stage tag will remove the current association (if exists), and create a new one - if any service network with the same stage tag/RAM share name exits.
• Removing the stage tag will remove the association.

In this automation, the EventBridge rule will obtain changes in VPC Lattice service tags. Once the tag stage is created/updated/removed from any of the services in the Account, the following actions will be automated by a Lambda function:

• Scan all the VPC Lattice service networks in the Account (either owned or shared) and determine which ones share the same stage.
  • For service networks owned by the same Account, the tag stage will be checked.
  • For service networks shared via RAM, the RAM share name will be checked. This name should be similar to the key of the VPC tag stage.
• As a VPC Lattice service can be associated with multiple service networks, the association will be created with all the service networks scanned.
• Several stages are also supported: the tag stage will require the use of the symbol + to separate the different stages - for example prod+test.
• Updating the stage tag will remove the current association (if exists), and create a new one - if any service network with the same stage tag/RAM share name exits.
• Removing the stage tag will remove the association.
• An AWS Systems Manager Parameter is used to store the latest set of stages that are associated with a specific service.

In this automation, the EventBridge rule will obtain changes in VPC Lattice service or service network tags. You can define a list of AWS Account and stages allowed for the resource share - as an extra step of control. Once the tag stage is created/updated/removed from any of the resources in the Account, the following actions will be automated by a Lambda function:

• If the stage tag configured is part of the allowed stages, the tagged resource (VPC Lattice service or service network) is shared using RAM to those AWS Accounts configured in the allowed Accounts list.
• The name of the RAM share will be the value of the stage tag, so the stage information is shared between Accounts.
• Update the stage tag will remove the current RAM share (if exits), and create a new one - if the new stage value is allowed.
• Removing the stage tag will remove the RAM share.

For this automation, two EventBridge scheduler is used to invoke two Lambda functions every 1 - 2 minutes to perform the automations. You can change the periodicity of the schedulers by updating the solution.yaml file.

• One of the Lambda functions will check if there's any VPC Lattice service associated with the AWS Account, to accept the RAM share (if the sender Account is allowlisted). Once the resource has been accepted, it will check RAM share's name and map it to any VPC Lattice service network with the same stage tag value.
• The other Lambda function cleans associations of unshared VPC Lattice services. Given the association will still be in-place even if the resource's share has been removed, the function will check which VPC Lattice service associations belong to VPC Lattice services that are no longer available in the AWS Account, and it will remove them.

In this model, the VPC Lattice service networks are owned by a central AWS Account, which is the one in charge of controlling how the associations are built. The automation to build in each AWS Account is the following one:

• Consumer AWS Accounts - these Accounts will simply create VPC Lattice VPC associations to shared service networks.

• Central AWS Account - the central AWS Account will be in charge of sharing the VPC Lattice service networks (with allowed Accounts), and alternatively create VPC Lattice service associations if VPC Lattice services where shared with it.

• Provider AWS Accounts - these Accounts will share their VPC Lattice services with the central Account, plus also creating VPC Lattice service associations if VPC Lattice service networks were shared with them (from the Central Account).

• Consumer & Provider AWS Account - it can happen than a Spoke Account is both consuming services from VPC Lattice (VPC association) and creating VPC Lattice services (service association).

In this model, the VPC Lattice service networks are owned by the spoke AWS Accounts that want to consume VPC Lattice services (each Spoke will have its own service network). Depending the role of the AWS Account, the automation to build will be the following one:

• Consumer AWS Accounts - these Accounts will simply create VPC Lattice service associations to shared VPC Lattice services. In addition, they can automate VPC associations if those were not created when the VPC and VPC Lattice service network were built.

• Provider AWS Accounts - these Accounts will share their VPC Lattice services with the consumer AWS Accounts.

• Consumer & Provider AWS Account - it can happen than an Account is both consuming services from VPC Lattice (VPC association) and creating VPC Lattice services (service association).