In this section, you’ll attach the common development VPC to the transit gateway and update the VPC’s route table to route on-premises network traffic to the transit gateway.
Attaching team development VPC does not require resource sharing: The team development VPC is created and managed in the same
network-prod AWS account in which your transit gateway was created. Consequently, you do not need to share the transit gateway resource in order to attach the common team development VPC to your transit gateway. However, since your other VPCs will reside in separate AWS accounts, you will need to enable resource sharing and share the transit gateway in order to attach those VPCs. You will enable resource sharing of your transit gateway in another section.
Create a VPC attachment to your transit gateway for your common team development VPC.
Management consoleassociated with the
Transit Gateway Attachmentsin the left navigation panel
Create Transit Gateway Attachment
||Select your transit gateway|
||For example, use the same name as the VPC resource:
||only check if you are using IP v6 - otherwise, leave unchecked|
||Select the common team development VPC|
||Select all of the private subnets in the VPC|
In this step, you’ll update the route table for each of the private subnets in the
dev-infra-shared VPC to add an entry to route traffic destined to your on-premises network to the transit gateway.
||Specify the CIDR range of your on-premises network|
||Select your transit gateway. For example,
Routing internet bound traffic to on-premises: If you choose to route all internet bound traffic back through your on-premises network, you can add another route for
0.0.0.0/0 in your route tables. You can use this approach as a temporary measure to direct all internet bound traffic through your existing on-premises network security services. Once you establish those services in your AWS environment, you can update the routing configuration as appropriate.