Network in the cloud — Transit gateway
Last time I described how to create simple connectivities between networks created in Azure and AWS. This is fine for smaller environments or our pet projects, but what if we plan an expansion in the cloud? Maybe we are about to build a new landing zone? Or perhaps we should create a hybrid solution that will allow us to create a bridge between the public cloud and our on-premises infrastructure? To solve such challenges, we can utilize more advanced cloud-native services. Today I am going to put some light on one of such services, and to be precise, it will be about AWS Transit gateway. In further publications, I will write about other solutions.
What is a Transit gateway?
Transit gateway is a service available only in AWS, and its purpose is to provide an easily manageable networking hub, allowing the interconnection of our VPCs and on-premises networks. This service provides a regional virtual router that can route traffic between different networks. It is an answer to a question, what should you use when you need to allow communication between resources deployed in various environments.
Transit gateway can send traffic to different networks and network devices using so-called attachments, it can connect with:
- VPCs,
- SD-WAN solutions,
- Third-party NVA (Network Virtual Appliance),
- AWS Direct Connect gateway,
- Other Transit gateways (using peering or VPN connection).
Can you do this using a different toolset? Sure, you can for example create your own network hub. It is important to remember that in AWS there is no support for transitive VPC traffic — it is traffic between two VPCs through another VPC.
Of course, there are workarounds for such cases. One of them is the usage of VPN connectivity between spoke VPCs and hub VPC, but it is not trivial. You will need an EC2 instance with VPN software, establish all needed VPN tunnels, deliver HA mechanisms, and scale possibilities for such a solution.
So yes, you can do it a different way. But it is way simpler and more elastic to use the Transit gateway service. AWS will take care of HA and automatic scaling of solutions, to meet your needs.
How does the Transit gateway work?
Transit gateway is using the concept of attachments (which have some limitations, I will discuss them later on), if we want to interconnect two VPCs we need to:
- Create AWS Transit gateway,
- Create attachments for both VPCs,
- Take care of routing configuration, and traffic filtering on Security Groups and NACLs.
During the creation of the attachment, you attach it to a specific subnet in VPC. The attachment will create ENI (Elastic Network Interface) in each of chosen subnets — it will reserve an IP address in each subnet.
This is a good moment to step back and take a look at the best practices for the Transit gateway setup. AWS suggests the creation of a dedicated subnet for attachments, you may ask why? It is because, managing routing and NACLs in subnets where we have both our EC2 instances and TGW attachments quickly becomes complicated, problematic, and error-prone (especially if we want to give strict rules). It may lead to a state where changes and troubleshooting of network configuration are causing headaches. More about best practices you can find here.
Hybrid cloud
Lately, it becomes more and more common that a public cloud environment needs to be communicated with the traditional data center, on-premises locations, or private cloud. Such an environment is called a hybrid cloud. Connectivity with our on-premises can be done in multiple ways, depending on our needs. We can establish Site-to-Site VPN connectivity, or even create dedicated physical connectivity using Direct Connect. Maybe we do not necessarily need to interconnect whole networks, but just provide access to some services to our users, and Client-to-Site VPN will be enough or direct access from the internet to that service (with certain guardrails of course).
No matter what choice we will do (and it does not necessarily have to be a single one), the Transit gateway might be really useful to achieve this state as a central networking point of our network infrastructure, which will allow intercommunicating different nodes together.
Limitations
When we are working on the design of our infrastructure we should always remember about limitations of the services that we want to utilize. It is not different with Transit gateway, details are described in the documentation, but the few most important according to me are:
- Up to 5 instances of Transit gateway per account (soft limit — can be raised),
- up to 20 routing tables per TGW (soft limit — can be raised),
- up to 5 attachments per VPC (hard limit)
- up to 3 TGW per AWS Direct Connect Gateway (hard limit).
Of course, depending on the use case different quotas will be relevant for us, and fortunately, some of those can be raised, but it is worth requesting it upfront.
Costs
Like most services Transit gateway is not a free service, but pricing calculations are not that complicated, we pay for:
- 0,06$ for every attachment by the hour,
- 0,02$ per GB of data processed.
The above prices are examples from the Frankfurt (eu-central-1) region on the day of publication, full pricing details can be found here.
Below are a few scenarios that will help wrap your head around cost calculations.
Example 1. You created a TGW instance in the Central Europe region (Frankfurt) and attached to it a VPC. Then you make a route for traffic to different VPC through TGW. 1GB of data was sent from the EC2 instance between those two VPCs.
The hourly cost of AWS Transit gateway will be 0,12$ (you need two attachments, one in each VPC, and pricing for attachment is 0,06$/h). If TGW is shared between different AWS accounts, hourly costs are added to the account which owns the VPC with attachment.
Additionally, TGW processed 1GB of data originating from the EC2 instance. So it will be an additional 0,02$. Costs of data processing are added to the account which owns VPC from which traffic is originating.
Example 2. EC2 instance existing in VPC connected to Transit gateway in North Virginia region transferred 1GB of data through peering to second Transit gateway in Oregon. Traffic is addressed to another EC2 instance existing in VPC attached to the second TGW.
Costs related to data transfer will be 0,04$ — from which 0,02$ is the cost of data processing by TGW from North Virginia, and an additional 0,02$ is the cost of transferring data between regions (outgoing traffic).
In this scenario, the second TGW (in Oregon) will not generate any additional costs as you do not pay for traffic originating from TGW peering, also you do not pay for traffic coming from a different region (costs were already covered as outgoing traffic in North Virginia).
Summary
When I was writing this blog post, I was at a stage of preparation for the AWS Advanced Networking Speciality exam, where one of the major topics is Transit gateway. As I already passed this exam, I need to admit that this is definitively a service that you need to have a good understanding of, if you want to pass this exam. This text is giving a brief overview of the Transit gateway, but it is for sure not enough for the exam, and you should deep dive into the documentation to get a better understanding of it. From a networking perspective, I consider TGW as one of the most important services (especially in larger environments), and if you don’t use I already, maybe it is time to ask why?
Sources:
https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html
https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html
https://www.linkedin.com/pulse/aws-transit-gateway-use-dedicated-subnets-just-local-watson
https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html
https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-quotas.html
