Day Two Cloud 089: AWS Networking Updates

The call is coming from inside the house! Our most recent episode of Day Two Cloud features Nick Matthews, who works for AWS on their VPC team. That means Nick has in depth and insider knowledge on what is going on with AWS networking these days. We really nerd out about all things networking, and I’m not gonna lie, some of the topics went over my head. Fortunately, Ethan is taller than me and was able to catch those things and wrestle them to the ground. What were these confusing things? So glad you asked!

When it comes to networking, I never really went beyond datacenter networking with basic routing and switching. If we’re talking VLANs and static routing, then I’m all good. Once we get into more advanced concepts like BGP, spanning tree, and WAN communication, then I’m out of my depth. Networking is something I’ve always struggled with. The CCNP is the first technical exam I ever failed, and I never went back to try again! There’s also a longer story about how Ned is not an acceptable nickname for Edward in the Prometric database, but I digress.

Nick and Ethan chatted about networking as it relates to BGP, using Geneve tunneling, and route reflectors. I have a vague idea of what those are, but not so much how they work. To that end, Ethan and I are planning a show, or what might be a series of shows, about networking for cloud architects. The first topic we are going to cover is BGP – Border Gateway Protocol. And we’re not going to try and cover everything about BGP, just the basics and how they might apply to a cloud architect’s life.

There was plenty in the conversation I could grok, especially as we got into the Transit Gateway and the new Gateway Load Balancer. The Transit Gateway was developed to simplify the process of peering 10s or 100s of VPCs together in a hub and spoke type architecture. Since AWS does not allow for transitive routing, the Transit Gateway can sit between VPCs and do the routing for you. What does all that mean? Imagine a basic three VPC deployment. Let’s say you want traffic from VPC A to travel to VPC B and VPC C. You would create a peering relationship between A and B and another between A and C. Can VPC B now talk to C across the two peering connections? No, it cannot. AWS does not allow for transitive routing, where VPC A would be functioning as the transitive bridge.

You can get around this limitation by creating a peering relationship between VPC B and C. But, as your AWS real estate scales, the number of peering relationships required for a full mesh increases rapidly.

VPCs Connections
3 3
4 6
5 10
10 45
100 4,950

The general formula is n(n-1)/2, where n is the number of VPCs. Managing those connections obviously becomes quite a chore, and if you want to connect those VPCs to a VPN or another region? Boy howdy, things get harder. The Transit Gateway (TGW) is meant to make this much simpler. You create a Transit Gateway connection from each VPC to the TGW, and then enable routing between the connected VPCs. You can also terminate a VPN or Direct Connect connection on the TGW, and you can create a peering connection between two TGWs. Smaller deployments might never need the Transit Gateway, but as you get to bigger environments, the TGW is a game changer.

We also talked about the Gateway Load Balancer (GLB), which is intended to solve the bring-your-own-firewall challenge. Let’s say you have ten VPCs and you want to provide a unified firewall service for all of them. What options were available to you? Well, you could deploy the firewall in each VPC and configure host-based routing (huge pain). You could try and set up a transit VPC and deploy the firewalls there, along with adding the necessary routing for each VPC (also huge pain). And… that was it. The introduction of the GLB allows you to configure a GLB endpoint on each VPC and send traffic to a set of firewalls or other virtual network appliances for inspection and processing. Personally, I’m not a big fan of centralizing traffic processing in that way. I think a distributed approach makes more sense for a cloud context, but I understand that approach doesn’t work for every organization. The GLB provides a solution that customers were pining for, and Amazon is customer obsessed after all.

All in all, I really enjoyed this episode and it was cool to get an inside look at what is going on with networking at AWS. I think I’d like to do a similar show about Azure and maybe even GCP. Does that sounds interesting to you? If so, let me know on Twitter or LinkedIn, or drop a comment down below!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.