Key Networking Takeaways from AWS re:Invent 2019

Modernization, a key theme from AWS re:Invent 2019, is also a theme across our customer base. When we look at one example from this year's re:Invent conference, serverless technologies, organizations benefit from this by reducing the operational complexity of building, running and managing modern applications.

Why networking professionals should be interested

A key announcement from Andy Jassy's keynote was Amazon EKS on AWS Fargate. You may have skipped over this announcement since this may not mean a lot for the network engineer, but for those who know a bit about Kubernetes, it's significant. 

Since AWS Fargate is a serverless service, you can run Kubernetes on AWS without spending the bulk of your time patching, scaling or securing a cluster of EC2 instances. I mention this because I believe customers will think less about application fault tolerance or availability and focus more on innovation and development of new applications. In short, the AWS platform takes care of this for you.

When we talk about cloud networking, we also need to think about modernization. In many cases, networking is an afterthought when organizations migrate to or expand within the cloud. But, we need to move networking to the forefront and continuously review data patterns, existing architectures and best practices than align with an organizations business goals. 

Data, workloads and services are moving constantly and becoming more distributed. It's important the network team is aligned with other teams (DevOps, security, cloud, compute and virtualization, etc.), in addition to the different business units within the organization so they understand the 'WHY' of a particular decision or function. 

In this article, we'll review some of the key networking announcements from AWS re:Invent 2019 and why they are important. There were many announcements at AWS reinvent 2019 within networking and content delivery. Some of the key trends I've observed over the past month from both Microsoft Ignite and AWS re:Invent are around the edge (or "bringing the cloud closer to you"), building out or expanding global networks and security in cloud networking. 

Let's begin by talking about "bringing the cloud closer to you."

AWS Outposts networking (infrastructure and services on-premises)

Applications are evolving quickly and have changed significantly over time. There is a lot of innovation happening in compute, storage, memory, security and I/O acceleration. As presented in depth at AWS re:Invent 2019, the AWS Nitro System is a great example of this next-gen platform. 

As a result of these innovations, we are starting to see network latency become a bottleneck. As the next generation of applications come online we will start seeing very low latency requirements. There are many ways to address this, but one way is to bring the same AWS designed infrastructure in AWS data centers on-premises. This is AWS Outposts. 

Let's talk about the networking elements of this new service. 

High-level LAN connectivity in AWS Outposts

Let's start with a simple design of an AWS region with VPCs and public and private subnets. What AWS is doing is taking that VPC and extending it on-premises. So if AWS Outposts sits on-premises, that VPC now runs in that Outposts. 

When we think about subnets in a Region, it's tied to an Availability Zone (AZ). An EC2 is running in the AZ via the subnet. Same with Outposts. Subnet is also an Outpost construct, so you can deploy an EC2 instance inside the subnets on the Outposts itself. Route tables, security groups and NACLs are still the same — the VPC is simply expanded to on-premises.

From a network communications perspective, instances can still talk to each other in an Outpost since they are in same VPC. Communication in some cases will stay inside Outposts via the local route. But since they are all part of same VPC (see high level design example), they can communicate with things inside the Region as well via the local route. 

But, you can set a default route via the IGW and go out to public internet or public services. You also have the ability to connect to the Transit Gateway (TGW), VPC Endpoint, etc. Remember a Transit Gateway sits within a Region, so from an Outpost you have connectivity to that Transit Gateway. A key thing to remember is an Outpost relies on connectivity to the parent AWS Region.

One of main use cases of Outposts is low latency to on-premises workloads. If you have on-premises workloads, you want to be able to communicate with those efficiently and with ease. This local access is achieved via a new construct called a Local Gateway (LGW). 

The LGW sits inside the Outpost and will attach to the VPCs in the Outpost. Therefore you don't have to go back to the region and back over Direct Connect. You can use a customer owned IP on the LGW to allow connectivity into the local network. On the LGW, the customer would assign an IP range (say a /26 or larger) to AWS and AWS will allocate that to LGW in form of pool. You can then allocate Elastic IPs at the LGW to instances in the Outpost. 

High-level WAN connectivity

What about WAN connectivity in Outposts? In short, this is from the AWS Region to a customer on-premises location where AWS Outposts lives. Again, an Outpost relies on connectivity to the parent AWS Region. Outposts are not designed for disconnected operations or environments with limited to no connectivity. Therefore, it's recommended that customers have highly available networking connections back to their AWS Region.

You can connect in multiple ways. Most likely you will connect your customer edge router via a Direct Connect over the WAN using a Public Virtual Interface (VIF). Alternatively you could connect via the public internet if you didn't want to have a public VIF. But once connectivity is setup, a Service Link is built back to the Outpost service. The Service Link provides access to the AWS control plane so AWS can manage the Outpost. This also gives AWS access to the VPC data plane which allows for instances to appear as if they sit inside a VPC within a region.

VPC Ingress Routing

Common questions we hear from our customers is around integrating existing security solutions into the cloud and if we have lessons learned that they can consider for their architecture. WWT offers entire workshops around cloud security, next-gen firewall platforms, automation and security architecture, therefore I won't dive into that here. But, this announcement makes the integration simpler and reduces latency if customers choose this path.

With Amazon VPC Ingress Routing, customers can now associate route tables with the internet gateway and virtual private gateway, and redirect incoming and outgoing Amazon Virtual Private Cloud (Amazon VPC) traffic through virtual appliances in their VPC. In addition, customers can segment Amazon VPC traffic based on individual workloads and route this traffic through different virtual appliances, thereby creating fine grained network and security policies for each workload. 

This can be achieved using virtual appliances or custom virtual network functions for specialized network and security features. For example, you can deploy a virtual appliance to protect traffic traversing an Internet Gateway (IGW) to and from the Internet, in addition to traffic traversing a VPN Gateway (VGW) to and from a remote VPN peer. 

AWS Transit Gateway Multicast

AWS brings to market the first native Multicast solution in the public cloud. 

Multicast, often used in media distribution, video conferencing and the stock exchange, has been difficult and costly to deploy in the cloud. It could be done, but there was no easy way of doing it the past which required, in many cases, hardware. 

This native support allows customers to easily build and deploy Multicast applications. Because of the native capability within AWS, customers can also easily monitor, manage and scale Multicast configurations up and down to hundreds of receivers, controlled via an API. This takes advantage of the elasticity, scalability, reliability and other benefits offered by AWS.

In terms of the technical details, what this capability allows customers to do is route Multicast traffic within and between VPC attachments to a Transit Gateway. The Transit Gateway is in simple terms, a cloud router. Multicast is enabled on the Transit Gateway. 

In turn, you will create a transit gateway multicast domain which allows multicast traffic to be sent to group members over VPC attachments. One note: Multicast routing is not supported over AWS Direct Connect, AWS Site-to-Site VPN and peering attachments.

Security is also top of mind with AWS Transit Gateway Multicast. With AWS, leveraging security groups and APIs, you can control and lock down who is able to subscribe. For example, using the action "RegisterTransitGatewayMulticastGroupMembers" you can register members (network interfaces) with the Transit Gateway Multicast group. A member is a network interface associated with a supported EC2 instance that receives multicast traffic. After you add the members, you can use 'SearchTransitGatewayMulticastGroups' to verify that the members were added to the transit gateway multicast group.

AWS Transit Gateway VPC Inter-region peering

Transit Gateway VPC Inter-region peering was an important announcement at AWS re:Invent, as many of our customers are building or expanding their cloud presence into multiple regions. We are starting to see more customers migrate to Transit Gateway (TGW) and while building a scalable TGW within a single Region is great, the expansion of applications and data into multiple regions make this capability a necessity.

In our Cloud Networking Workshop, we discuss best practices and different ways to connect to Regions, between geopolitical Regions and to the overall global network architecture. AWS Transit Gateway VPC Inter-region peering makes it easy to connect Regions together and improve scalability. Prior to Transit Gateway VPC Inter-region peering, you could connect and build VPC peers which doesn't scale well in large organizations. With this new capability, traffic is now carried over the AWS backbone at the same time traffic is also encrypted and anonymized.

Let's walk through a few use cases and data patterns with Transit Gateway VPC Inter-region peering. 

• Example 1: Say you have a VPC in Region US East (Ohio). The resources in US East are now able to communicate with any instance attached to the VPC in US West (Oregon).
• Example 2: An instance in US East (Ohio) VPC can also talk to an instance on-premises on the other side of a Direct Connect in US West.
• Example 3: An instance on the other side of the VPN in US East (Ohio) can communicate with an instance on the other side of a Direct Connect in US West.

All of these example flows use an optimal path across the AWS backbone. 

AWS Accelerated Site-to-Site VPN

Building on the current version of Site-to-Site VPN, AWS introduced a more secure and predictable VPN experience from branch locations. Customers have been asking for and need the best connectivity to AWS. Many have VPN as their primary mechanism into AWS from the branch and a Direct Connect connection is simply not cost effective. 

AWS Accelerated Site-to-Site VPN provides an improved connectivity experience to AWS via Global Accelerator. Using this new approach, the path from the branch to AWS is optimized, resulting in fewer hops through the public network, better performance and lower latency. 

To summarize how this works, a branch location will connect to the AWS Transit Gateway, but instead of a longer path through the internet to a Region, the Global Accelerator will route to the nearest AWS Edge location. The remote branch or site is likely closer to an Edge location within a nearby city. Traffic will still travel on the local ISP network, but first to an Edge location then onto the AWS backbone to the Transit Gateway. This changes performance significantly. 

AWS states they have seen a 30 percent reduction in jitter and latency in some cases. Remember, there are 210 Edge locations today and growing. 

SD-WAN integration with AWS

This new integration allows customers to automate and better manage their existing SD-WAN solution (Cisco, Aruba, Silverpeak, Aviatrix) with AWS Transit Gateway. 

In general, SD-WAN integration into AWS isn't new with some of these vendors. Cisco, for example, has delivered Cloud OnRamp for IaaS with AWS, SD-WAN virtual appliances on AWS Marketplace and enterprise branch connectivity to AWS in the past. But, Cisco has now extended this integration to better manage and automate connectivity between branch offices and the AWS Cloud via the AWS Transit Gateway. 

Instead of a slow manual process, making changes in minutes with automation is a key improvement from what was possible in the past. In addition, customers can apply network segmentation and security policies to cloud traffic flows, allowing for more consistent network and security rules. 

What this also means, from an architecture perspective, is that customers no longer need transit VPC architectures where they terminate multiple VPN connections from vEdge cloud virtual routers in an SD-WAN VPC to a Virtual Private Gateway (VGW) in each spoke VPC. This is another reason why Transit Gateway is important in modern architectures. Spoke VPCs are connected directly to the Transit Gateway using VPC attachments. As a result customers can do the following:

• terminate Site-to-Site (S2S) VPN connection from branch to vEdge cloud virtual routers in SD-WAN VPC;
• use VPN attachment to connect vEdge cloud virtual routers to AWS Transit Gateway; and
• the branch can directly connect to AWS Transit Gateway using VPN attachment (terminate S2S VPN connection from branch directly on AWS Transit Gateway).

In each case, customers leverage AWS Transit Gateway as a central part of the design. This in turn enables connectivity between SD-WAN branches through the AWS backbone or where branches need connectivity into AWS workloads. 

Through this seamless integration, cloud-first enterprises can now create a single global view of cloud and network resources and centrally monitor and manage connectivity from branch and remote locations to cloud resources, wherever they reside.

AWS Transit Gateway Network Manager

Now, let's look further beyond automation and where another key integration point has occurred between SD-WAN vendors and AWS. Being able to view and monitor the global network within AWS and on-premises networks is an important next step along this journey. Announced at AWS re:Invent 2019, you can now visualize and monitor the health of your VPCs, Transit Gateways, Direct Connect and VPN connections to branch locations and on-premises networks. 

An example of this management integration is Silverpeak, a global SD-WAN partner, who has also expanded its collaboration with AWS. Silverpeak has integrated the Unity EdgeConnect SD-WAN edge platform with the new AWS Transit Gateway Network Manager. This integration provides a solution that enables enterprises to manage and monitor connectivity between AWS and their branch locations from a single console within AWS. This means customers can obtain a better view of their global network telemetry and events from on-premises EdgeConnect deployments to network infrastructure in AWS.

AWS Transit Gateway Network Manager is a new capability in AWS that provides a single global view of your private network. As mentioned in the Silverpeak example, other vendors (such as Cisco) provide similar integration, allowing customers to view their on-premises resources. 

A customer can login to the Transit Gateway Network Manager and define their resources as devices, sites and links. Once defined, automated actions (using Lambda functions) can be generated based on specific events occurring within the network. For example, what if a VPN connection is established? You could trigger a Lambda function to make a routing configuration in a different region. This in turn reduces the amount of time, number of tools and consoles to manage and monitor AWS and on-premises networks. 

The key point here is to think about new and innovative ways to simply the operations of the network within your organization. The Transit Gateway Network Manager is just the beginning and has a lot of improvements to make, but the information collected today will expand and improve in the future based on discussions with the SD-WAN vendors and AWS. 

Finally, I wanted to end with another automation tool that can help with managing your AWS Transit Gateway. The Serverless Transit Network Orchestrator adds automation to Transit Gateway by providing the tools required to automate the procees of setting up and managing transit networks in distributed AWS envirinments. This is done via a web insterface designed to control, audit and approve network changes. In addition, this new Orchestrator can be customized to meet customer specific use cases and workflows.

In summary, many features, capabilities and new services within networking were announced at AWS re:Invent 2019. It's clear our industry is changing, and I believe this is an exciting time to be in networking.

WWT understands this well and have built hands-on labs, workshops, reference architectures and assessments to help our customers with their edge and cloud networking strategies. We invite you to learn more about our approach and see the latest technologies in action in our Advanced Technology Center. Register on our digital platform to explore related articles, case studies and hands-on labs. We'll show you how the right cloud networking solution can, quickly and cost-effectively, make a difference.