Appendix C: Create custom route tables - Serverless Transit Network Orchestrator

Appendix C: Create custom route tables

The Serverless Transit Network Orchestrator (STNO) creates the following default transit gateway route tables: Flat, Isolated, Infrastructure, and On-premises. Each route table and suggested propagations include a policy for common use cases.

  • Flat: VPCs associated with the Flat policy can reach other VPCs associated with the Flat, Shared Services, or Hybrid policies. The Flat policy enables a VPC to have connectivity to many other VPCs.

  • Isolated: VPCs associated with the Isolated policy can only reach VPCs with the Shared Services and Hybrid policies. VPCs in the Isolated policy cannot use AWS Transit Gateway to connect to other VPCs in the Isolated policy. This policy is for VPCs that do not communicate with each other.

  • Infrastructure: VPCs associated with Shared Services can reach other VPCs associated with the Isolated, Flat, or Hybrid policies. The Infrastructure policy is used for VPCs that many other VPCs may rely on, such as shared authentication, shared tooling, or orchestration tools.

  • On-premises: This route table is used for connecting to on-premises through either VPN or AWS Direct Connect. Associate your On-premises connections to the On-premises route table.

Policy Types Associate with (route table name) Propagate to (list of route table names)
Flat (East-West) Flat Flat, On-premises, Infrastructure
Isolated (North-South) Isolated On-premises, Infrastructure
SharedServices Infrastructure Flat, On-premises, Isolated
Hybrid On-premises Flat, Infrastructure, Isolated

In this implementation guide, a policy is defined by both an association to a single transit gateway route table, and the transit gateway route table propagation. To implement these concepts, both the association and propagation must be tagged on each spoke VPC according to the intended design because the policies below are not centrally managed. Inconsistent tagging can create drift between the desired policy and what is configured. You can use the ApprovalRequired tag on route tables that need manual control. By default, Serverless Transit Network Orchestrator is set up for automatic approval, but you can change this tag to set up manual approval. For more information, refer to Appendix E.

Custom route tables

If the default policies do not meet your requirements, you can create your own transit gateway route table configurations. For example, if you need a policy that allows developers to create VPCs that do not have access to sensitive resources in the Isolated or Infrastructure route tables, you can create a new Development policy by creating a new transit gateway route table that propagates to the Flat, On-premises, and unique route tables. Those route tables would also propagate to the new Development route table. For instructions on how to set up a custom route table, refer to Create a Custom Route Table and Attachment.

Alternatively, if you do not need the provided Flat policy, you can modify the existing Flat policy to meet your custom requirements. Disable propagation to the Infrastructure route table and remove the Flat propagation from the Infrastructure route table.


You do not need a separate route table for each VPC to achieve segmentation. Segmentation is accomplished by controlling the propagation. For example, an Isolated route table does not propagate to itself and, as a result, nothing associated with an Isolated route table is able to reach other Isolated resources through the transit gateway.

The administrator can create new transit gateway route tables in the AWS Virtual Private Cloud console in the hub account. The combination of route tables and propagation provided with the transit gateway allows for a wide variety of connection policies.

Create a custom route table and attachment

Use the following sample table and steps as a guide for setting your routing policies. For this example, you implement a Development policy and route table.

Policy Types Associate with (route table name) Propagate to (list of route table names)
Flat (East-West) Flat Flat, On-premises, Infrastructure, Development
Isolated (North-South) Isolated On-premises, Infrastructure
SharedServices Infrastructure Flat, On-premises, Isolated
Hybrid On-premises Flat, Infrastructure, Isolated, Development
Development Development Development, Flat, Hybrid
  1. In the hub account, sign in to the Amazon Virtual Private Cloud console.

  2. In the navigation pane, choose Transit Gateway Route Tables.

  3. Choose Create Transit Gateway Route Table.

  4. For Name tag, enter a name for the route table. For this example, enter Development.

  5. For Transit Gateway ID, select the appropriate transit gateway.

  6. Choose Create Transit Gateway Route Table.

    You will receive a confirmation message.

  7. Select Close.

  8. Optional: If you want changes to this route table to be manually approved:

    1. Select the newly created route table from the list.

    2. Choose the Tags tab.

    3. Choose Add/Edit tags and then choose Create Tag.

    4. In the Key field, enter ApprovalRequired and in the Value field, enter Yes.

    5. Choose Save.

After the new route table is created, determine the access model. For two transit gateway attachments to communicate, each of their associated route tables must have each other’s routes.

First, determine where your new route table should propagate routes, defined by the other transit gateway route tables. For example, should the Infrastructure route table be propagated from your new route table?

Next, check that the other route tables are reciprocating the propagation for two-way communication. For example, you may want to propagate Infrastructure, Flat, and Hybrid route table to your new route table.


If your custom route table requires access to VPCs that have already been attached, you must change the Propagate-to tag for each spoke VPC to include your new route table.

To associate a new VPC to this route table:

  1. Tag the new VPC with the Associate-with key and reference the new route table name in the value.

    For example, Associate-with: <ExampleRouteTable>

  2. Tag the new VPC with the Propagate-to key and reference the route tables you want to propagate to from the previous step.

    For example, Propagate-to: Infrastructure, Flat, Hybrid

  3. Tag one subnet in each Availability Zone.

    For example, Attach-to-tgw: <leave blank>


    If you configured manual approval, you may need to sign in to the Transit Network Management web interface to approve the change. If that is the case, you will receive an email with the request that will contain the link to the Transit Network Management web interface.

To confirm the attachment, you can look for attachments on the transit gateway in the VPC management console, in the Transit Network Management interface, or in the state machine history.

For more information about transit gateway route tables, refer to Amazon Virtual Private Cloud.