Setup and configure the AWS transit gateway (TGW) in the org-sagebase-transit account. It will act as the "hub" of our hub and spoke architecture to manage network traffic to our VPCs.
There are many possible design patterns for a TGW. Our TGW is configured in a fully isolated network pattern similar to this diagram.
Notes:
- The Transit VPC is named "unionstationvpc".
- We use the AWS client VPN instead of a direct connect.
AWS enforces a specific workflow when setting up the Transit Gateway in a hub and spoke architecture.
- Setup the transit gateway in the central/hub account.
- Create a transit gateway route table in the hub account.
- Share the transit gateway in the hub account (VPC settings).
- Share the transit gateway to spoke accounts with the Resource Access Manager.
- Accept invitations from spoke account in the Resource Access Manager.
Note: We have enabled auto accept invitations in our AWS organization account which means that invitations are automatically accepted when TGW is shared to any AWS account that is part of the Sage organizations account.
If the account is NOT in the organization then you must manually accept the sharing invitation:
- Login to spoke account with admin user/role
- Accept the sharing invitation in the Resource Access Manager -> Shared with me -> Resource Shares -> accept the invitation
- Create attachments to the transit gateway hub from spoke accounts.
- Add ("Associate") spoke TGW attachments to the hub transit gateway route table.
We have setup automation for the above workflow using org-formation
The Hub VPC, unionstationvpc, is already setup and only need to be done once.
Once the TGW hub is deployed we only need to connect additional VPCs in spoke accounts
to the hub.
Spokes may be connected to the hub with the following workflow:
Create a PR in this repo with the following changes to _tasks.yaml:
- If it doesn't already exist, add a spoke account to
TransitGateway.Parameters.Principalsparameter. This is used to share the TGW to spoke accounts. - Add a new entry to the
TransitGatewayRoutes.TemplatingContext.TgwSpokesdictionary. This is used to setup routes from unionstation VPC to VPCs in spoke accounts. - Add a new entry to the
Mappingsdictionary. This is used to setup the TGW attachments and routes in spoke accounts. - Add the account info to either TransitGatewaySpokeA, TransitGatewaySpokeB or create a new custom
spoke resource. Each
TransitGatewaySpokeA.DefaultOrganizationBinding.Accountentry corresponds to a VPC. For example if there are two VPCs in AccountZZ then you need to add a Mapping forTgwSpokesAandTgwSpokesBthen add AccountZZ to bothTransitGatewaySpokeAandTransitGatewaySpokeB - Have the PR reviewed and merge PR
Once merged and deployed the TGW routes will be updated to route traffic from the hub VPC to the spoke VPC.
Note: It is recommended to only add one VPC at a time which means you should split up your PRs to add one spoke VPC per PR.
Workflow to test routes:
- Provision a private EC2 in
unionstationvpc - Create a security group to allow
ICMPingress traffic. - Apply security group to EC2
- Repeate provision EC2 steps in the spoke account.
You should be able to ping the EC2 in spoke VPC from the EC2 in the unionstationvpc and vice versa.
You should NOT be able to ping an EC2 in one spoke VPC to an EC2 in another spoke VPC.
Contributions are welcome.
Requirements:
- Install pre-commit app
- Clone this repo
- Run
pre-commit installto install the git hook.
As a pre-deployment step we syntatically validate our sceptre and cloudformation yaml files with pre-commit.
Please install pre-commit, once installed the file validations will
automatically run on every commit. Alternatively you can manually
execute the validations by running pre-commit run --all-files.
Please install pre-commit, once installed the file validations will
automatically run on every commit.
- We use the AWS SSM to store secrets for this project. Sceptre retrieves the secrets using a sceptre ssm resolver and passes them to the cloudformation stack on deployment.