Loading summary
Transcript21 lines
- [00:00]
A
Welcome to aws bytes episode 137 where we're going to dive into one of AWS's more powerful services, Transit Gateway. Networking in the cloud can feel like a bit of a tangled web of connections. With VPC peering, VPNs and Direct Connect all weaven together into a complex mesh. Transit Gateway aims to simplify all of this, providing a centralized hub designed to streamline connectivity and make network management a whole lot easier. It in this episode we're going to break down exactly what Transit Gateway is, how it works, and why it's a game changer for organizations of all sizes. Whether you're managing a few VPCs or scaling to hundreds, Transit Gateway is built to handle the challenge. Plus we're going to explore some real world use cases that give you a feel for how Transit Gateway can help you. My name is Owen and today I'm joined for the first time by David Lyneham. Let's get started. AWS Bytes is brought to you by four Theorem. Sometimes AWS is overwhelming and you might need someone to provide clear guidance in the fog of cloud offerings. That someone is 4 theorem. So check out 4theorem@4theorem.com now. Very welcome Dave.
- [01:15]
B
Thanks Paul.
- [01:17]
A
Glad you could join us. Can you help set the scene? I know you're a bit of a closet Transit Gateway expert, so first of all, maybe we could just start with the topic of VPCs.
- [01:26]
B
Yeah, sure. So a VPC or a virtual private cloud is an isolated network environment where you can define and manage an IP range or a CIDR block. And this CIDR block forms the base for creating subnets where you can assign the IP address to service components within a vpc. So typically in a VPC you'll have like a couple of different types of subnets. You have a public subnet where you host your public instances such as public EC2 instances, load balancers, and maybe a NAT gateway. You'll also have like private subnets which are instances that are not directly accessible from the Internet, but they'll be able to connect out through to the Internet using a NAT gateway. And we'll also have isolated subnets which are basically have no inbound or outbound connectivity. So subnets are associated with route tables that define how interfaces in the network can route traffic to the Internet and other networks. By default you can only route within the VPC CIDR block.
- [02:19]
A
So VPC is pretty much self contained by default then. So if you're going to scale and if you've got any kind of complexity or you need systems to talk to each other, you're going to think about routing or routing outside of the VPC, like other VPCs or even networks outside of AWS. So how is that typically done?
- [02:37]
B
Yeah, so we need to connect to VPCs. The default approach is traditionally to create a VPC peering relationship. To set up a peering connection, one VPC acts the requester and the second VPC acts as the acceptor. The acceptor must accept the peering connection. You can then add route table entries in one VPC to route traffic to the other VPC and route the traffic backwards in the second vpc. When you have limited requirements, this can be a very useful and cost effective solution. But there are quite a few limitations. Firstly, you cannot use peering to route to the Internet or through nat gateways or VPNs in another VPC. You cannot do transitive peering either, which is what we'll get onto in a few minutes. So, for example, you can. If you're in VPC A and you want to send traffic to VPC C and VPC A and VPC B are peered and VPC B and VPCC are peered, you can't send traffic from A all the way through B to C. So it can become quite complex as well. If you have like multiple peerings. Like, you know, so it's, it's quite easy if you have two VPCs, but if you have many more, it gets very cumbersome to manage all those VPC peerings. The reason these connections I mentioned, transitive peerings are not possible. There's kind of a small rule of thumb that I like to use. But a packet coming into a vpc, if the destination for that packet is outside of the vpc, the VPC will drop that packet. So I think that's a good rule to kind of keep in mind when we're kind of talking about transit gateways. So what we mean by a transitive network is that where traffic in one VPC is going beyond a second VPC to a Tor vpc. So going through two autonomous networks before transit gateway, it was possible to implement transitive connections by creating a gateway with an EC2 hosted VPN software product in a transitive VPC and peering each PVPC with this transitive VPC VPN acts as the destination and forwards the packet to the true destination in another VPC. As well as having to pay for the EC2 instance, the VPN software and the total cost of ownership of managing all this. There is also a fair amount of complexity and management overhead with the VPC peering to Support network resilience. You also would need to deploy the architecture across multiple availability zones and implement redundant connections. This is typically referred to as a hub and spoke architecture where the transit VPC in the hub and the connected VPCs are spokes.
- [05:06]
A
I can understand why people were looking for a better solution because it is very. It seems like it's quite complex, a lot of moving parts, a lot of maintenance and yeah, not something that you'd really warm to now. These days when you have an AWS organization with multiple networks, there are lots of cases where you've got VPCs spread across all those accounts and networks and you might need to connect them together. So it's typical to need routing through a centralized account maybe or to access on premises networks. You also have to think about VPNs like site to site VPNs or client VPNs and then you have to think about like just east west routing as they call it, like between services or applications. So let's get into transit gateway then. How does transit gateway help?
- [05:54]
B
Yeah, sure. So as we mentioned there about the transit vpc, the transit gateway is basically a managed hub and spoke network. It takes the management of the hub and spoke architecture off your hands. So you really only need to worry about routing the traffic or directing the traffic where you want it to go. So it provides a centralized hub for connections between multiple VPCs and IT scales to thousands of VPCs by extending through other transit gateways. It's forced connections to on prem through direct connect and VPN and it's highly available across multi azs in a region. You can peer transit gateways in multiple different regions together as well. And you can also do very, very fine grained routing and isolating networks and stuff like that. And it also works across accounts. So it's very good for like if you have a large organization, you might have AWS organizations enable, you might have many, many accounts. You might segregate your business workloads by account and then you could join together where it makes sense using a transit gateway.
- [06:56]
A
That sounds pretty good. What are the main components then? What does even a simple setup look like if you're just getting started?
- [07:01]
B
Yeah, sure. So the main component of the transit gateway is the attachment. If you Want to attach VPCs to your transit gateway, you create an attachment for that particular VPC. You can also attach VPNs. You can also attach direct connects to attach to your on prem networks. You can also peer attachments which is connecting to another transit gateway to chain your transit gateway connections. When you create the attachment. You also pick what subnets you want the attachments to be joined in. And once you have all your networks attached, you need to think about routing. Transit gateway has its own route tables which are separate to the VPC and subnet route tables. The transit gateway route table is a powerful thing. It lets you control how traffic can flow between attachments. Attachments and route tables are the first two building blocks. The two other important concepts to be aware of are associations and propagation. So association, every attachment will have an association with the route table, but you can also create lots of route tables for fine grained control and segmentation propagation. If you want a VPC to be routed through a transit gateway, you can propagate its CIDR block to the transit gate to the transit gateway route tables, which is essentially using BGP under the hood. And it allows the transit gateway to learn about routes that attached VPC knows about. With these four building blocks you can create some very powerful scenarios. Let's imagine we have three AWS accounts and each one of those accounts has a vpc. So let's say VPC, A VPC B, vpcc. What we could do is we can create a transit gateway and let's say we had another account which was even a network account. We can actually share the transit gateway with those three accounts. So we can have like a centralized management of the transit gateway and each one of those accounts can then attach their VPC to that transit gateway and the routing of that transit gateway traffic can be managed inside the networking account. So that would allow traffic inside VPCA to send traffic to VPCC or VPC B and likewise and vice versa with the other two VPCs via the attachments. Yeah, one other point I suppose like sort of I mentioned there about the transit gateway being shared. So you would use AWS RAM or Resource Access Manager to share the VPC with the other particular account. So it's a really nice feature because you're able to centralize that ownership of the routing in a, in a network managed account. And then you don't have to worry about like your, your business domains or your business accounts having to create transit gateways or attach transit gateways. They just, they just use the transit gateway that's managed by the AWS organization. Moving on from that, then the VPCs could add in in their private subnets. If they want to send traffic from the service and components in the private subnets, they would route traffic to the target of the transit gateway itself. So any traffic that is not for their local VPC they will send it to the transit gateway. The transit gateway will pick up that routing and it'll send it to the appropriate VPC which arrived in at its destination.
- [10:16]
A
I think that's a good point because you have like the transit gateway routing tables which are separate and that you can use them for all sorts of advanced segmentation or just like be very permissive if you want. But then you still need to have your subnet route tables as well and you need to say okay, well which you might have a catch. All that says 0000 goes to the transit gateway. Right. And then Internet Internet might go through it. Or it could be a specific cidr blockers even more specific.
- [10:43]
B
Yeah, yeah.
- [10:45]
A
Another thing I was involved in recently was a project where we wanted to have a multi account setup with vpcs for application traffic. So these are essentially web applications and other things, even databases where end users wanted access but it had to be secure and should and could not be on public Internet. So what we were actually asked to do was look into a VPN setup and we've done quite a lot of AWS client VPN which is generally pretty straightforward to set up. You know, you can do certificate based or integrated into identity provider, but this kind of VPN can terminate on your networking account just like you described there. And you can associate it then with the transit vpc. So this kind of VPC in the network account and that's also attached to the transit gateway. We talk a lot about segmentation sometimes when we're talking about transit gateway. I think we've mentioned it there a few times. So one thing we wanted here was that VPN users could be able to access these applications. But the applications, you don't want them to be able to route between each other, they should be segmented from each other. They're isolated domains. They shouldn't talk to each other except through maybe an event bus or something. So you want to avoid that kind of direct traffic. The way you can do that is by setting up two transit gateway route tables. One's associated with the transit VPC attachment and it lets you route through to those domain accounts, say application accounts and another is associated with each of those domains VPC and different root table. So let's call that the applications root table. So then the domains can propagate their cidrs to the transit VPC root table and the transit VPC propagates its CIDR range to the applications root table. And then they can both talk to each other. But the routing is segmented then so that client VPN connections can route to the applications, the applications can route back out to the vpn, but the domain accounts cannot route to each other. And like you said as well, you still need to make sure you add those subnet route tables from the transit VPC to the destination CIDR through the transit gateway, so the VPN clients can reach the application. So you always need to think about the root tables for the transit gateway and subnet route tables. And it might be more complicated, it might sound more complicated than it is, but it's just one of those things, Right? You just have to try it a few times, make the mistakes. And then the concepts, I think are pretty powerful and replicable. Then you know, it's not as advanced as it might seem.
- [13:13]
B
Yeah.
- [13:13]
A
Any other use cases we should cover before we.
- [13:16]
B
Yeah, there's a couple of interesting ones there I've come across. So similar to what you just mentioned there, there's kind of a network isolation for compliance reasons, such as pci, I've come across where networks are in scope for holding, like credit card details. For examp, using a transit gate is very good idea for restricting what networks can get into that data, because you have to under compliance, you have to. Any connected networks are always audited. Being able to show and being able to restrict what networks can actually get to the PCI data means you're reducing the scope of what's inside of an audit. So it's quite good for that. You can also turn on like transit gateway flow logs as well and be able to show that, monitor that data going in and out. The other kind of one I've come across is security services. So quite often security services are quite expensive and you kind of deploy them in maybe a security account. And what you'd like to do is have like, maybe all your traffic go through these security services. But obviously you don't want to deploy them in every single account. So what you would do is you would basically reduce your ingress and your egress to a single account. And what you do is route the traffic coming in and out of your AWS accounts through the security services and in a thing called a middle box. So it's basically intercepting the traffic, sending it off to the security service, pulling it back. So things like AWS firewall and those kind of things would quite often be used there. And you can use the transit gateway then to direct all that traffic, make sure that all that traffic goes back through that security service. There's lots of good patterns for these kind of things using the transit Gateway.
- [15:07]
A
When we're talking about the benefits of this kind of stuff, we should also talk about pricing and limits. Anything interesting to talk about there? How does it stack up price wise?
- [15:16]
B
Yeah, so like you're paying, you're paying basically on two parameters. Essentially you're paying based on the number of attachments you have or the hourly rate for those attachments and the data you're processing. Typically it's about 2 cents per gigabyte or transfer data per month. And for the attachments then you're paying in about. It's roughly about 5 cents per hour in many regions. So that's about 3650 per month. But the reality is you're not going to be peering but one vpc, you're going to be peering with at least two. So at a very minimum you're going to be talking about $73 a month to peer 2 VPCs. Traffic between peer VPCs in the same region is billed as if they were AZ to Azure data, While traffic between VPCs in different regions are billed as if the data have been sent out to the Internet. So it's a little bit more expensive.
- [16:05]
A
What about limits then? Is there any capacity issues you might need to think about?
- [16:11]
B
Yeah, there's one of the. I suppose the benefits of a transit gateway is very scalable. So we can have five transit gateways per account, which is a soft limit and you get AWS to increase that you do wish. So each transit gateway can have up to 20 route tables. Okay. And we can have in those route tables a total of 10,000 routes. So that's quite a lot of routing already. And each transit gateway can have 5,000 attachments. That's quite a bit. It might be worth noting as well that you can't really get around this by using pending attachments, by not accepting them. So there is a limit of like 10 pending attachments. So you can't be smart and try to get 10,000 of them in a pending state and move on like. So if we were to kind of compare the transit gateway with the VPN tunnel, we get a huge increase in throughput there across the network. So we're getting about 100 gigabits per VPC attachment per AZ, whereas if we're looking at the VPN tunnel, we're only about 1.25 gigabits per second. So if you're looking for speed, the transit gate was probably the way to go.
- [17:22]
A
Okay, okay, I think that last one is important then. So the bandwidth is per VPC attachment per az. So as you scale out, you just get more bandwidth really. So that's pretty cool. Okay, thanks Minnie and Dave. Just to wrap up then we should probably point I think there's an example on the AWS documentation for Transit Gateway which I think is one of the best pieces of AWS documentation I've come across because it talks about how, you know, a fairly advanced topic like this works but it's not very long and most of it is just giving example scenarios like the ones we talked about today but others as well and I just think it's whoever was involved in that deserves yeah some praise because that's it's really worthwhile. Check it out, it'll be in the show notes. Yeah if anyone out there has any other use cases for Transit Gateway that we missed, do let us know in the comments below. Thanks for joining us. Cheers Dave. See you again in another one and we'll catch you all in the next episode.