Hybrid Cloud Networking

30/11/18, by Dario Ferrer

VPC stands for Virtual Private Cloud, it is a term widely used these days when referring to Cloud networking, but, what it actually is? What are the differences between different Cloud providers VPCs? How do I connect my existing networks to the VPCs and how do I connect Clouds between themselves? Let’s answer all those questions.

AWS VPC

In AWS, a VPC (virtual private cloud) is a virtual network in which you deploy resources such as EC2 virtual instances, RDS databases, Lambda functions, etc.

It represents a layer 2 network, you have to provide a private CIDR Classless Inter Domain Routing ip block range to create a VPC. An AWS VPC is scoped to only one AWS Region, that means you can have two or more datacenters, known as AZs (Availability Zones) per VPC. Each AZ can have one or more subnets (contained within the VPC CIDR) but you cannot have a subnet extending to more than a single AZ. If you want a bigger network, with more than one region on it, then you have to create many VPCs and interconnect them.

AWS VPC Peering

AWS provides an easy to use feature called VPC Peering, this basically connects TWO VPCs together so that they can see each others’ routes and hence can route traffic to each other as if they were physically connected by a router. You have to be careful in how to peer VPCs when more than 2 VPCs are to be connected. For example, having 3 VPCs A, B, and C , if you peer A with B, and then you peer B with C, then A can’t see C and C can’t see A. You can however peer also C and A as well, having a full closed circle, this way of peering VPCs tends to lead to complex unmanageable high number of peerings if we have many VPCs to interconnect.

AWS VPN

Another popular way of connect VPCs is by using VPN technologies. AWS provide its own IpSec VPN native solution, it is compatible with most of the popular firewall and routing appliances as well as between the VPCs themselves. There are many ways of doing VPNs in AWS, including dedicated optic fiber connections to many co-location datacenters in many cities around the world using AWS Direct Connect.

By using VPNs, you have a very granular control on what and how you connect in a more traditional way of networking, you can implement back-up routes and BGP. You can also publish routes from remote VPCs or on premises datacenters, private VPN network ranges, etc, just like how you would connect any other private network to your corporate one.

Google VPC

In Google Computing Platform, a VPC is a more abstract concept, it is simply a label that you will use to identify some subnets that you will create. There is no need to define a CIDR block to create a VPC. A VPC is composed of one or many subnets, unlike in AWS, a VPC is global, you don’t need many VPCs to connect resources in many regions. Subnets are also more flexible than AWS ones as they are scoped to a region, that means you don’t have to create multiple subnets if you are using multiple AZs (datacenters). These 2 key factors simplify the networking design greatly in GCP compared to AWS.

Google VPC Peering

As well as in AWS, and in a similar manner you can peer (connect) VPCs, but unlike in AWS, this is not a popular choice mainly because it is just normally not needed. A single application will have a single network topology connected worldwide within a single VPC.

Shared VPC

There is a great feature of the Google network that not many people know and it is one of the most awesome networking products in the Cloud in my opinion. A shared VPC is a single VPC that is shared between two or more GCP projects. GCP projects are the counterpart of AWS accounts. This means that you can have resources created, managed, billed, etc from a project A and resources created from a project B living in the same network and being able to speak to each other with no further connectivity required, no VPN, no peering. Again, it is a big plus to have simple network designs in order to reduce error rates and moving parts in our app.

Google VPN

Some AWS connecting features such as Direct Connect are really powerful and awesome, but Google is the winner when speaking about connecting your VPC with your on-premises or co-location datacenters. In GCP you also have native VPN connections that you can use straight away with most of well known commercial networking appliances an you can also configure BGP in such VPN solutions. You can also connect directly your network into your Google VPC by using Google interconnect either using a dedicated connection (99.99% uptime SLA) or by using Partner Interconnect which uses your already existing network providers to provide an enterprise level connection.

What about VPN to interconnect VPCs?

You always can connect your VPCs using VPN and BGP, but it would make little sense since there is no need to have many VPCs. Because Google VPCs are global, a single VPC with as many (already routed) subnets as needed will be all that you need to have full connectivity in your infrastructure, even across multiple projects.

But I also have AWS VPCs, can I connect to them from my Google VPC?

Absolutely, this is in fact a very good idea and a recommended thing to do. Having all these fantastic network features in both major cloud providers we can (and we should) connect them and work in both of them having the best of each one. It can be a matter of distributing resources between providers to avoid the vendor lock-in. It can be just that some resources are more mature in one provider than the other. And this does not extend only to AWS and GCP, we can easily connect several cloud providers and on premises networks using the same tools.

And those little things?

There are many features out of the scope of this post that we could speak about such as flow logs, internal dns, VPC endpoints, etc. But the differences between those minor features are minimal between AWS and Google and way too technical to be described here.

Transit VPC

A transit VPC is a centralised network that we dedicate to connect other VPCs and any non-cloud network that our corporation operates. At the beginning of the Cloud era, it was very popular to connect the cloud VPCs into an on-premises or co-location big network appliance as centralised control point. These days it is preferred to move such network management point to the Cloud as well, taking advantage of managed network tools and Serverless technologies.

In my opinion, Google cloud may be a bit less feature rich than AWS, but it has better network. My preferred choice of having a Hybrid Cloud Transit VPC would be Google with no doubt. An AWS Transit VPC can also be a good option, specially if most or all of our resources are already in AWS or if we already have an AWS Direct Connect solution in place.

30/11/18 Hybrid Cloud Networking, by Dario Ferrer