Transit Gateway in the Cloud

Ever wondered how to allow multiple applications that are on separate networks to use the same Shared Resources?

Networking in cloud computing can be complex. The cloud lets us create applications faster and in a more durable fashion without worrying about configuring infrastructure too much with services like AWS Lambda with Api Gateway for serverless architecture or Elastic Beanstalk for Paas and AWS Batch for containers. 

It is as simple as uploading our code and AWS creates the servers behind the scenes for us. 

When deploying many applications in AWS there is a lot of added value to separate them logically, use dedicated VPC for each application. 

When deploying an application to AWS we would like to create several environments for dev and production, once again separated logically to VPC's. This method allows us to protect our production environment from accidents and limit access to it so the production will stay available and keep profiting for us.

This is great but, proper networking will be creating subnets both public and private with network components such as Internet Gateways and NAT Gateways, Elastic ip's and more. Yes, it will be great because our network will be strong and highly available but also expensive. For example, NAT Gateway pricing is based per  instance, data processed by the NAT Gateway and the data transfer.  

So, what can we do? And why do we even want this NAT Gateway?

NAT Gateways allows us to access the internet from instances in private subnets. Without it we either use:

• instances in public subnets (which is not so great for security reasons) 
• VPC endpoints to access AWS resources outside our VPC for example, a DynamoDB table or S3 bucket.
• Not go out to the public internet.

These options are not optimal, but there is a solution. We can set up a management VPC that will hold all of our shared assets such as NAT Gateways and let all VPC's in this region use it.

What does a  A Management VPC Look like?

This kind of a VPC will hold all of our shared resources, like Active Directory Instances, Antivirus Orchestrators and more. We will use it as a centralized location to manage and control all of our applications in the cloud, all the VPC will connect to it using a private connection such as peering or VPN. An example can be seen in the following figures:

So, we just need to put a route in the route table for the Management VPC?

No, sadly it won't work. We do need to configure routing but this is not the way. There is an option to connect VPC's securely using VPC peering but it won't work. When using VPC Peering Traffic must either originate or terminate from a network interface in the VPC.

We need to use a Transit Gateway!

Transit Gateway is a network component that allows us to transfer data between VPCs and On-premises networks.

Traffic Gateway has a few concepts such as:

• Attachments - VPCs, Direct connect, Peering to another TGW, VPN Connection

• Transit gateway Maximum Transmission Unit (MTU) - the largest packet size allowed to pass in the connection.

• Transit gateway route table  - route table that includes dynamic and static routes that decide the next hop based on the destination IP address of the packet

• Associations - Each attachment is associated with exactly one route table. Each route table can be associated with zero to many attachments

• Route propagation -  A VPC, VPN connection, or Direct Connect gateway can dynamically propagate routes to a transit gateway route table. With a Connect attachment, the routes are propagated to a transit gateway route table by default.

In the following example you can see an example of 3 VPCs sharing one NAT Gateway for outbound internet access. VPC A and VPC B are both isolated and can’t be accessed from the outside world. 

Transit Gateway pricing is based on hourly charge per attachment and for the amount of traffic processed on the transit gateway.

About the routing, we will need to add the following Route Tables:

• Application VPCc needs to have in the private subnet route to 0.0.0.0/0 to the Transit Gateway

• The Egress or Management VPC needs to have two Route Tables:
• Private Subnets that will point 0.0.0.0/0 to a NAT Gateway

• Public  Subnets that will point 0.0.0.0/0 to a IGW Gateway

Here is an example of that:

What are the other use cases of Transit Gateway?

We can use  the Transit Gateway as centralized router, Network Hub, As a substitute of peering connection and more, all these use cases will direct traffic from our management vpc that users connect to via VPN to our resources in the isolated VPCs:

Not sure if you need a Transit Gateway?

You can depend on Cloudride for experienced help in cloud migration and workflow modernization. We specialize in public and private cloud migration and cost and performance optimization. Contact us here