If your network architecture includes multiple route tables in your Amazon Virtual Private Cloud (VPC) and you’ve been looking for an automated solution for synchronizing route target updates across route tables, check out the AWS Sync Routes project. Or, if you just want to explore a ready‑to‑deploy, serverless infrastructure as code project, then the AWS Sync Routes project can help here, too.

This project was built with the AWS Amplify framework because it provided an intuitive way to organize the AWS CloudFormation templates and other code. The Amplify CLI also provides a standardized way for teams to deploy and manage the lifecycle in a few simple commands. If you’d like to get hands‑on right away, the documentation includes details on the prerequisites and how to get started.

Example data flow of the web request to the route synchronization
Figure 1: Example data flow of the web request to the route synchronization.

How it works

Once AWS Sync Routes is deployed, all of the components are visible in the AWS Console, but the solution is idle until triggered via a web request to a regional Amazon API Gateway REST API instance, for example by a monitoring event action or a polling client (such as aws-sync-routes-client.sh).

The web request must include an API token that is used for a simple, single request authentication mechanism as well as request throttling. Also, a request validation model is used for enforcing strict, first‑tier input validation of the request body. If the request passes the initial validation, API Gateway then executes the AWS Lambda function with an AWS Identity and Access Management (IAM) policy that grants the least privilege necessary for completing the request.

The Lambda function then retrieves the main/default route table for the VPC via the identifiers supplied in the URI path, and if valid then selects the route via the IPv4 CIDR block included in the request body. The matched route is validated to ensure that it is in an active state in the main route table, that it has an elastic network interface (ENI) target, and that it is neither a local route nor a propagated route. If all tests pass, the route is either added or updated (if necessary) in the custom route table(s) asynchronously, and a change notification is published to the Amazon Simple Notification Service (SNS) topic, which you can subscribe to if you want to receive alerts.

Altogether, the solution generally takes one to three seconds to execute. In one customer success story to date, this was used to synchronize 26 production routes across four custom route tables (104 concurrent route synchronizations) within four seconds. This met the customer’s requirement of completing all route synchronizations prior to timeout of a mission critical application at 15 seconds, and allowed them to complete a critical maintenance window.

This solution is intentionally simple and achieves the desired outcome, but if you want to modify any of the functionality, you absolutely can. Empowering you to customize the solution to best meet your needs was one reason for releasing the project as open source. Some ideas that have been discussed and implemented by various customers include: using a private API Gateway instance instead of a regional, augmenting the authentication process, and integrating AWS Web Application Firewall (WAF) to filter undesirable requests.

Next steps to consider

 

from AWS Open Source Blog: https://aws.amazon.com/blogs/opensource/sync-routes-across-route-tables-with-aws-sync-routes-a-serverless-open-source-project/