AWS re:Invent 2019: A Networking Perspective

By Derek Baltazar and Travis Greenstreet, 2nd Watch

AWS re:Invent 2019 has come and gone, leaving the collective masses to sort through the product news. According to AWS, it released 77 products, features and services over five days. Many of the announcements were in the ML space (20 total), followed by news on compute (16), analytics (6), networking and content delivery (5).

AWS principal solutions architect Matt Lehwess kicked-off his presentation on VPC design and new capabilities for Amazon VPC with a poignant note: “Networking is really what underpins everything we do in AWS. All the services rely on networking.” This statement strikes a chord. Over the last couple of years, our customers have been accelerating their use of VPCs, and in 2018, Amazon VPCs were the number one AWS service used by our customers. Networking isn’t the sexiest part of AWS, but it provides the foundation that brings all the other services together. So, here’s our take on the most important networking-related announcements at re:Invent 2019.

AWS Transit Gateway Inter-Region Peering (Multi-Region)

One exciting feature announcement in the networking space is Inter-Region Peering for AWS Transit Gateway. This feature allows the ability to establish peering connections between transit gateways in different AWS regions. Previously, connectivity between two transit gateways could only be done through a transit VPC, which included the overhead of running your own networking devices. Inter-Region peering for AWS Transit Gateway enables you to remove the transit VPC and connect transit Gateways directly.

The solution uses a new static attachment type called a Transit Gateway Peering Attachment that, once created, requires an acceptance or rejection from the accepter transit gateway. In the future, AWS will likely allow dynamic attachments, so they advise you to create unique ASNs for each transit gateway. The solution also uses encrypted VPC peering across the AWS backbone. Currently, Transit Gateway inter-region peering support is available for gateways in U.S. East (Virginia), U.S. East (Ohio), U.S. West (Oregon), EU (Ireland) and EU (Frankfurt), with support for other regions coming soon. You also can’t peer transit gateways in the same region.

On the surface, the ability to connect two transit gateways is just an incremental feature addition, but when you start to think of the different use cases and the follow-on announcement of multi-region transit gateway peering and accelerated VPN solutions, the options for architecture really open up. This effectively enables you to create a private and highly-performant global network on top of AWS.

AWS Transit Gateway Network Manager

This new feature is used to centrally monitor your global network across AWS and on-premise. The transit gateway network manager simplifies the operational complexity of managing networks across regions and remote locations. It’s a dashboard approach to provide a simpler overview of your resources that may be spread over several regions and accounts. To use it, you create a global network within the tool, which is an object in the AWS Transit Gateway Network Manager service that represents your private global network in AWS. It includes your AWS transit gateway hubs, their attachments, and on-premises devices, sites and links. Once the global network is created, you extend the configuration by adding in transit gateways, information about your on-premises devices, sites, links and the site-to-site VPN connections. It includes a nice geographic world map view to visualize VPNs (if they’re up/down impaired) or transit gateway peering connections.

There’s also a nice topology feature that shows VPCs, VPNs, direct connect gateways and AWS transit gateway-AWS transit gateway peering for all registered gateways. It provides an easier way to understand your entire global infrastructure from a single view.

Another key feature is the integration with SD-WAN providers like Cisco, Aviatrix and others. Many of these solutions will integrate with AWS Transit Gateway Network Manager, automate the branch-cloud connectivity and provide end-to-end monitoring of the global network from a single dashboard. It’s something we look forward to exploring with these SD-WAN providers in the future.

AWS Local Zones

AWS Local Zones in an interesting new service that addresses challenges we’ve encountered with customers. Although listed under compute and not networking and content delivery on the re:Invent 2019 announcement list, Local Zones is a powerful new feature with networking at its core.

Latency tolerance for applications stacks running in a hybrid scenario (i.e. app servers in AWS, database on-premises) is a standard conversation when planning a migration. Historically, those conversations would be predicated on their proximity to an AWS region. Depending on requirements, customers in Portland, Oregon, may have the option to run a hybrid application stack, where those in Southern California may have been excluded. The announcement of Local Zones (initially just in Los Angeles) opens up those options to markets that were not previously available.

Local Zones are interesting in that they only have a subset of the services available in a standard region. Local Zones are organized as a “child” of a parent region, notably the Los Angeles Local Zone is a child of the Oregon region. API communication is done through Oregon, and even the name of the LA Local Zone maps to Oregon (Oregon AZ1= us-west-2a, Los Angeles AZ1 = us-west-2-lax-1a). Organizationally, it’s easiest to think of them as remote availability zones of existing regions.

As of December 2019, only a limited amount of services are available, including EC2, EBS, FSx, ALB, VPC and single-zone RDS. Pricing seems to be roughly 20 percent higher than in the parent region. Given that this is the first local zone, we don’t know whether this will always be true or if it depends on location. One would assume that Los Angeles would be a higher-cost location whether it was a local zone or full region.

About The Authors

Derek Baltazar is a Managing Consultant at 2nd Watch and Travis Greenstreet is a Principal Architect at 2nd Watch.