In case if you are looking at the Cloud Technologies as an architect, having a deep understanding about ‘Cloud Networking and its services’ is very important irrespective of the CSPs like GCP, AWS or Azure or any other.
As it’s a key component and skill-set to gain thorough knowledge, I thought of drafting out my own learnings.
I’ve been primarily focusing on GCP and all of its services from an architectural point of view and with this blog I’m sharing my views with wider audience about ‘VPC Networks in GCP’.
Keep a note that these are NOT ‘the expert notes’ but I believe it gives a good overview of most of the GCP VPC Networking related topics. Before starting to read further, I strongly recommend that the reader *must* at least have a fundamental understanding about the Networking Concepts like Subnets, IP ranges, CIDR, Firewall Rules etc. If thats something you already know, then spot on….but if not, apologies. Please spend sometime on those fundamental concepts before moving ahead.
Loads to cover here….Let’s get going……
What is it ? — It is a Software-defined network [SDN] which provides a networking <connecting/accessing> functionality between & among the GCP resources like GCE, GKE and GAE [flexible] etc.,
Note — GAE Standard environment instances do not run inside the VPC network, so VPC firewall rules do not apply to them
In a traditional VPCs, the scope of the VPCs and Subnets is ‘Regional’ and this is true for AWS and Azure as well but In GCP VPCs, the VPCs are ‘Global’ in scope where as Subnets are ‘Regional’ and they can span across multiple zones within the same region
This is the fundamental difference what GCP is offering compared to other CSPs. Of course, it brings it’s own advantages and cautions to be mindful
Each VPC network consists of one or more IP range partitions referred to as Subnets. A Network must have at least one subnet before you can start using it in reality.
GCP offers 2 types of VPC Networks depending on the way the subnets are created.
- Auto-mode — This is the default network provided by the GCP when you create a project. This mode creates one subnet from each region automatically without any intervention and this is NOT at all recommended in Production like environments due to Security related complications. ‘Cloud Security’ is a massive area to explore, we’ll keep that out of context here but a minimal mention as applicable. As and when new regions get added to Google Cloud, new subnets in those regions are added in this mode automatically. The user need to be very cautious about this option if they prefer and must take all precautions required
- Custom-mode — Nothing gets created automatically, I mean the subnet. This leads to a great control to the end-user over it’s subnets and IP ranges. The user can decide which subnets in which regions can be used by mentioning the IP ranges that he/she specifies
The user can switch a VPC Network mode from ‘Auto-mode’ to ‘Custom-mode’ but not vice-versa. Once it’s a custom-mode VPC, it cannot be changed back to the auto-mode — keep in mind!
Default Network
If you’ve not disabled it, each new project kicks-off with a default network which is nothing but ‘Auto-mode’ VPC network. It brings several advantages to the customer like having subnets in each region automatically and also IP ranges of the subnets do not overlap with others. But as mentioned before, use has to be mindful of what he/she is after. If you are looking for a better control over the subnets and IP ranges, ‘default network’ is not at all recommended.
Google recommends to opt for ‘Custom-mode’ for production networks
Now, let’s explore different VPC Networking options available in GCP for different scenarios
VPC Network Peering
This allows private connectivity <through internal IP address> across two VPC networks regardless of whether they belong to the same project or the same organisation
Traffic stays within the Google’s network
If you’ve organisations with several network admin domains and you are looking for communication among them using the internal IP addresses — then it is the best option
Consider one on-premises connection between your GCP VPC and on-premises network and you want to share this with other VPC networks — You can achieve by having GCP VPC networks peer with your VPC network <known as transit network in this case>. The diagram illustrates the same
We’ve 3 VPC networks. network-b is peered with network-a and network-c. network-b acting as the ‘transit network’ and they can communicate with the on-premises network through the VPN tunnel but keep in mind, network-a and network-c will not be able to communicate to each other directly but the communication has to go through network-b only i.e., transitive peering NOT allowed in case of VPC Peering connection
Shared VPC
It allows an organisation to connect resources from multiple projects to a common VPC network and enables them to communicate using internal IPs securely
In the above example, you can see that we’ve one host project and two service projects. Service Projects A and B have their own independent access to their specific subnets
Consider a scenario where you’ve your on-premises network and also some resources in the GCP, how do you connect them and use ? — That’s where GCP provides 2 options
- Cloud VPN
- Cloud Interconnect
Cloud VPN
Connects on-premises networks security through an IPSec VPN tunnel to VPC or two VPCs in GCP. Traffic is encrypted and travels between the two networks over the public internet.
Where the use case is for low-volume data connections, this option is well suitable
- Encrypted by one gateway and decrypted by the other
- Site-to-site VPN only <no site to client — i.e., If you are using your own laptop or computer from home, this option doesn’t work>
- Can be used in conjunction with Private Google Access <RFC 1918>
- Supports up to 3 Gbps per tunnel <8 tunnels max>
- Static or dynamic routing <using Cloud Router>
- Support for IKEv1 or IKEv2 using shared secret
In simple context, HA [High Availability] VPN provides a 99.99% SLA with two interfaces and two external IP address whereas Classic VPN provided a 99.9% SLA — purposefully not going detailed in to this topic. But the bottom line difference is the SLA between the two. How they accomplish that ‘SLA’ is a very detailed concept and you can refer cloud.google.com for more detailed study
Cloud Interconnect
This option overcomes the speed limitations of the ‘Cloud VPN’ and also the traffic does not traverse through the public internet. This is a physical connection between Google’s network and on-premises network
Cloud Interconnect provides low latency and high availability which brings a good reliable transfer of data between on-premises and GCP VPC networks. Also, internal IP addresses can be directly accessible from both networks
Cloud Interconnect offers two options for extending on-premises network:
- Dedicated Interconnect — Provides a direct physical connection between on-premises and Google’s network. Offers speeds like 10Gbps link <up to 8> or 100 Gbps link <2>
- Partner Interconnect — Provides a connectivity between on-premises and VPC networks through a supported service provider. Offers speeds from 50Mbps and up to 10Gbps
I know, we’ve too many options to consider for networking and it’s a bit overwhelming to understand and finalise what to pick. But, if you really understand the context for each of these options, it is very crystal clear to pick one for each scenario. The below segregation will help you in that direction :)
Private Google Access
Consider a scenario where you would like to allow the instances to have only internal IP address but those instances should be able to access certain APIs outside and services within GCP — Do we’ve any solution till now ? Can we achieve that requirement with any of the above mentioned options ? No, for now But
That’s what ‘Private Google Access’ provides. It enables the instances who have only internal IP address <No external IP addresses> to reach the external IP addresses of Google APIs and services.
- Can be enabled / disabled this feature via subnet settings <subnet level>
- It has no effect on instances that have external IP addresses and you know why ? ;)
- At the time of writing this blog, these services don’t have it enabled are — App Engine Memcache, Filestore and Memorystore
The above overall information about VPC Networks might look a bit heavy & over whelming as well — which is true. To make our life simple to some extent, we do have a decision tree below which helps in making the choice easy — nJoy!
VPC Best Practices
That’s all for now. If you feel the content is heavy, Have patience and re-read for better understanding. Go through the references I mentioned below, that might help too…… — Thanks for taking time to read!
Summing up about GCP VPC Networking in one blog is not that easy but I tried to limit the content to give quick overview. I recommend to go through official references for more detailed understanding as given below
References:
- cloud.google.com
- googlecloudplatform on youtube and search for ‘VPC Networking’..…loads of content to watch for you
