The Evolution of Networking in the AWS Public Cloud

In the beginning, AWS public cloud started with EC2 Classic, touting basic IaaS. Networking was simple since you could only launch an EC2 instance with either a public IP or in a private IP space (10.0.0.0/8).

In 2009, AWS introduced the VPC (Virtual Private Cloud) and a revolution began. The virtual cloud transformed from the simple model of its beginnings into the application-defined data center we have today. Now, when launching an EC2 instance, you’re required to define region, VPC, subnet, routing tables, Internet gateways, and security groups to have basic functionality. Throughout its evolution, AWS has completely redefined the data center and cloud landscape. It takes just a few minutes to build a VPC, a stark contrast to the long-timelines and high costs of building a traditional data center. Due to convenience and elasticity, AWS public cloud and its components have become the de-facto building blocks for just about every businesses, from startup to large enterprise.

Another renegade was gaining in popularity in parallel to the VPC revolution, the DevOps movement. DevOps folks figured out that you can quickly build isolated environments, segmenting production, QA, and development networks. As a result, companies began to accumulate numerous AWS accounts, each with countless VPCs that had to be managed.

Growing Up In AWS Public Cloud

For most firms, the evolution of AWS networking usually starts with accessing the AWS Console directly. Administrators upload a handful of files and documents to S3, then spin up resources to act upon those workloads. It doesn’t take long to accumulate multiple accounts and multiple VPCs. Before you know it, networking has intertwined itself into the infrastructure that needs to be expanded. Of course, migrations are possible, but what’s the best way to move the data reliably and securely?

Your AWS evolution has reached a new level, its time to decide whether, and how, to utilize VPN or Direct Connect.

Most organizations opt for VPN first. The setup is quick, but what you gain in deployment speed, you lose in a lack of reliability and elasticity. Direct Connect is certainly an option, but you’re burdened with concrete-like elasticity and legacy telco install timeframes of months, sometimes years.

As you evolve into multiple connections, you’re faced with a new conundrum, how to effectively manage them.

Enter the Transit Network

With a transit network, you can set up one or more VPN or Direct Connect links from the data center to an AWS transit VPC, then configure the other spoke VPCs to tunnel through. This topology solves the connectivity problem, but it comes saddled with a myriad of significant issues:

• Skill Sets: Deploying and managing transit VPCs required in-depth expertise in Cisco CRS, BGP, IPSec, and VRF. Companies utilizing DevOps typically don’t have network engineers at the ready to dedicate to these challenging tasks.
• Isolation Between VPCs: Inherent lack of network isolation runs counter to most enterprise security models.
• Doubled Egress Charges for VPC-to-VPC and VPC-to-Data Center Traffic: Since data exits the spoke VPC, then travels through the transit VPC, you incur a second, identical egress charge.
• Transit Bottleneck: Since all traffic must flow through the transit VPC, the transit CRS becomes a bottleneck.

Step It Up: Services Architecture

By utilizing one transit VPC and one shared service VPC and separation of the service architecture from the transport, you can simplify some points of contention:

• Decoupling Skill Sets: DevOps provides the share tools and update/patch without going through the hub, while the network team handles the type of connectivity and setup/management of the transit. Both sets of skills are still required with this model, the DevOps team doesn’t need to understand networking (BGP), but the protocols are still in place and managed by the networking team. However, this configuration is complex, since two teams must manage network connectivity.
• Reduced Egress Charges, Sort Of: With the full mesh network in place, you’re avoiding double charges from spoke-to-spoke, but the entire endeavor was meant to gain connectivity to the data center. Those charges will still exist, and the network team will likely look toward Direct Connect to reduce costs. Going with Direct Connect is highly dependent on telco contracts when it comes to cost reduction, and it adds significantly more complexity in the form of more MPLS connections, more equipment, and more network resources to manage all of it.

Unfortunately, isolation is still an issue unless you create a VPN to each spoke, but this adds significant complexity and requires more resources to manage. At the same time, bottleneck issues still exist. While it’s possible to have multiple connections, they come with added complexity and management overhead as well.

Welcome to the Future of Cloud Networking

NetFoundry makes it easy to instantly spin up highly secure, performant, edge-to-cloud networks to AWS over the Internet using our web-based orchestration tools and APIs. These AppWANs abstract the network in the same way that containers and virtual machines abstract applications from underlying compute infrastructure, eliminating the need for private circuits, proprietary hardware, and restrictive telco solutions. Application teams can easily configure and operate AppWANs, which act as one-to-many discrete application-specific microsegments. Each AppWAN is a selected subset of endpoints associated to an application with which, authorized endpoints are allowed to exclusively communicate, creating a zero trust relationship.

The components within NetFoundry’s orchestration console were designed to make building and augmenting AppWANs that connect to AWS public cloud easy and seamless. AWS connected AppWANs make legacy applications cloud-portable with a layered security architecture that isolates and protects data flows through data stream fragmentation (aggregation and disaggregation) and military-grade encryption. The result is a private, dark, software-defined perimeter, protecting the company and its assets from edge-to-edge.

NetFoundry can operate in parallel with Direct Connect or as an alternative, depending on the needs of the business. The inherent instant-on agility of AppWANs means that administrators can quickly spin up ephemeral, cloud-native application and context-specific networks to AWS with global reach over the Internet that are as secure and performant as MPLS connections, without bandwidth constraints or long installation lead times.

Unlike VPNs, AppWANs automatically adapt to network conditions and route traffic via multiple high performing, encrypted streams across the internet. For example, the platform may encapsulate TCP in the inherently more performant UDP, resulting in connections that dramatically outperform traditional single-path VPNs in terms of throughput and latency. Furthermore, NetFoundry is cloud-native, eliminating the need for hardware or backhaul of VPN tunnels to a data center. The application specificity of AppWANs make zero trust, software defined perimeters simple, extending the security of the WAN to endpoints, regardless of location or connection type. Managing AppWANs is far simpler than managing point-to-point VPN connections, since AppWANs are inherently multipoint-to-multipoint, driven by service access, context, and identity.