An architectural evolution for networking in the public cloud

The shared service architecture for DevOps

In 2006, AWS started its IaaS with EC2 Classic. At that time, there was not much networking to do: an EC2 instance either has a public IP address or in this one 10.0.0.0/8 network.

In 2009, AWS introduced Virtual Private Cloud (VPC). Now days you cannot launch an EC2 instance without specifying which region, VPC and subnet this instance will be deployed on. You can think of an VPC as a virtual datacenter, it’s got routing, subnetting, Internet gateway, NAT gateway and other capabilities. While it takes years to build a physical datacenter, it takes minutes to build a VPC with everything in it. That’s how convenient public cloud has become with VPC being the basic building block.

AWS first became popular with developers and cloud born companies. To run their production in AWS, the DevOps folks figured out how to build isolation by separating production account from development account and testing/QA accounts. That led to multiple accounts. Multiple accounts led to multiple VPCs.

To manage instances in multiple VPCs for patching, updating and scanning, a hub and spoke network architecture, often called shared service architecture emerged. With a shared service VPC or management VPC that hosts DevOps tools, the shared service VPC connects to other spoke VPCs where workload EC2 instances run. This architecture serves well the operations in the cloud.

Enterprise Transit VPC Network

Enterprises with on-prem datacenters have a different connectivity requirement when adopting to AWS.

In the beginning, an enterprise may be dabbling AWS with a few VPCs each connecting to on-prem. As deployment starts to scale, building many connections to on-prem network becomes difficult to manage. AWS Global Transit VPC solution automated the hybrid secure network connectivity for larger scale number of VPCs that need to connect back to on-prem and to each other.

What’s wrong with Transit VPC Network

While Transit VPC solution does a great job in solving the automation problem of connectivity, it falls short for enterprise cloud operation.

Because enterprise cloud operation team consists of DevOps folks and networking engineers each with different skill set and network requirements. Here are a few issues with Transit VPC solution.

· Skill set. Transit VPC requires in depth expertise in Cisco CSR, BGP, IPSEC and VRF. DevOps and less experienced network engineers find it challenging to operate and manage such a network.

· No isolation between VPCs. Transit VPC automatically builds a full mesh connectivity between VPCs, even if VPCs are owned by different business units. The lack of isolation breaks enterprise security posture.

· Double egress charge for spoke VPC to spoke VPC Traffic. For spoke VPC to spoke VPC communication, traffic is being charged twice, once leaving the spoke VPC and once leaving the Transit VPC.

· Transit VPC is the performance bottleneck for all traffic. Since spoke to on-prem and spoke to spoke traffic all go through the Transit VPC, Transit VPC CSR becomes the performance bottleneck.

Introducing the Services Architecture for modern enterprise CloudOps.

What enterprise cloud operations team need is to decouple the transport architecture from the service architecture, so that each architecture level — and the technical team that handles it — can work optimally within a hybrid cloud environment.

The result is an architectural diagram as shown below.

This services architecture decouples the transport network architecture and the service network architecture, creating a “line” separating the two.

The transport network, which connects with on-premises datacenter is managed by the network team, serves the requirements of connecting spoke virtual private clouds (VPCs) to on-premises resources. Only traffic traveling to and from the on-premises resources goes through the transit VPC. In the transport architecture, networking team is responsible for determining the type of connectivity, private Direct Connect or Internet based IPSEC, actual implementation and operation.

The service network serves the requirements of DevOps teams. A shared service hub VPC connects to spoke VPCs to provide Ops teams with tools, updates, and patches without going through the transit hub VPC. For a scenario such as disaster recovery (DR), the service network can connect any two spoke VPCs on demand, without going through the transit hub.

The services architecture is run by a central controller, requiring no border gateway protocol (BGP) in the cloud. In this approach, BGP is used for connecting between transit VPCs and on-premises routers; the cloud teams do not need to use BGP at all. Instead, with a central controller, routing in the services architecture part is policy driven and software defined.

The Benefits of the Services architecture for Enterprise CloudOps

Decoupling the networking transport and service architectures offers several benefits for organizations implementing hybrid cloud or multi-cloud environments.

Internally, the Services architecture reduces friction between the network and DevOps teams. Network teams can focus on circuits and direct connections for the hybrid connectivity, while cloud teams can manage the cloud networking without learning the proprietary knowledge of Cisco CSR and in depth networking expertise.

From a technical perspective, the service architecture encompasses the transport and service architecture layers to form a new, consolidated architecture. This new architecture make it simple to add new VPCs where the growth is.

The Aviatrix Services architecture:

· Aligns teams and skills. Align with the DevOps architecture through shared service VPCs and spoke VPCs and improves self-sufficiency and agility.

· Provides isolation by default. No inter VPC connectivity unless specified by policy.

· Reduces egress charges. Inter VPCs traffic in service architecture part has half the egress charge comparing to Transit VPC.

· No single performance bottleneck. Inter VPC traffic does not go through Transit VPC.

· Aligns with data replication. Inter VPC traffic is direct and requires no extra hop.

· Improves visibility and troubleshooting capability across hybrid and multi-cloud environments.

In summary, the modern services architecture is much more suitable for enterprise CloudOps team to operation their growing cloud network environment.

To learn more about making networking simple, secure, and automated in even the most complex cloud environments, visit the Aviatrix website.