Much like physical networks, VPCs have Routing Tables. They are used to forward traffic from one instance to another instance within the same network, across sub-networks, and between GCP zones without requiring an external IP address
VPC Firewalls and routing tables are built in and don't have to provisioned or managed
VPCs provide a globally distributed firewall that can be used to control access to instances for both incoming and outgoing traffic
One can define firewall rules in terms of metadata tags on Compute Engine instances. For example, one can tag all web servers with the name "web" and write a firewall rule saying that traffic on ports 80 or 443 is allowed into all VMs with the "web" tag no matter what their IP address happens to be
VPCs like any other GCP resources belong to GCP Projects. If a company has several GCP Projects and the VPCs need to talk to each other, then that can be achieved using VPC Peering
One can also leverage a Shared VPC to control who and what in one Project can interact with a VPC in another Project through the use of IAM policies
Cloud Load Balancing is a fully distributed and managed software-defined load balancer service for all traffic (HTTP and HTTPS, other TCP and SSL traffic, and UDP traffic) coming in to the auto-scaled VMs
With Cloud Load Balancing, a single anycast IP frontends all the backend instances in regions around the world. It provides cross-region load balancing, including automatic multi-region failover (if backends become unhealthy)
Cloud Load Balancing reacts quickly to changes in users, traffic, backend health, network conditions, and other related conditions
Use HTTPS Load Balancer for cross regional load balancing of a web application
For Secure Sockets Layer traffic that is *NOT* HTTP, use the Global SSL Proxy Load Balancer
For other TCP traffic that does not use Secure Sockets Layer, use the Global TCP Proxy Load Balancer
The Global SSL Proxy Load Balancer and Global TCP Proxy Load Balancer proxy services only work for specific port numbers in the TCP protocol
To load balance UDP traffic or traffic on any port number (across GCP regions) with the Regional Load Balancer
To load balance traffic inside your project (between the presentation layer and the business logic layer of your application), use the Internal Load Balancer. It accepts traffic on a GCP internal IP address and load balances it across Compute Engine VMs
Internal Load Balancer has Regional scope
The following is a side-by-side comparison of the various Load Balancing options in GCP:
DNS is what translates internet host names to addresses. Google has a highly developed DNS infrastructure with the IP 8.8.8.8 and makes it available so that everybody can take advantage of it
GCP offers Cloud DNS to help the world find the internet host names and addresses of applications you build in GCP. It is a managed DNS service running on the same infrastructure as Google. It has low latency and high availability and it is a cost-effective way to make your applications and services available to your users
The DNS information you publish is served from redundant locations around the world. Cloud DNS is also programmable
Google has a global system of edge caches. You can use Google Cloud CDN to accelerate content delivery from your application. Your customers will experience lower network latency
Once you've set up HTTPS Load Balancing, simply enable Cloud CDN with a single checkbox
Lots of GCP customers want to interconnect their other networks to their Google VPCs, such as on-premises networks or their networks in other clouds. They can start with a Virtual Private Network connection over the internet using the IPSEC protocol. To make that dynamic, they use a GCP feature called Cloud Router. Cloud Router lets your other networks and your Google VPC exchange route information over the VPN using the Border Gateway Protocol. For instance, if you add a new subnet to your Google VPC, your on-premises network will automatically get routes to it
Some customers don't want to use the internet either because of security concerns or because they need more reliable bandwidth. In those cases, they can consider peering with Google using Direct Peering. Peering here means putting a router in the same public data center as a Google point of presence and exchanging traffic. Google has more than 100 points of presence across the world
One downside of peering though is that it isn't covered by a Google service level agreement
Customers who want the highest uptimes for their interconnection with Google should use Dedicated Interconnect, in which customers get one or more direct private connections to Google. If these connections have topologies that meet Google's specifications, they can be covered by up to a 99.99 percent SLA. These connections can be backed up by a VPN for even greater reliability
The following is a comparison of the various Interconnect options in GCP:
