Much like physical networks, VPCs have routing tables. These are used to forward traffic from one instance to another instance within the same network. Even across sub-networks and even between GCP zones without requiring an external IP address. VPCs routing tables are built in, you don't have to provision or manage a router. Another thing you don't have to provision or manage for GCP, a firewall instance. VPCs give you a global distributed firewall. You can control to restrict access to instances, both incoming and outgoing traffic. You can define firewall rules in terms of metadata tags on Compute Engine instances, which is really convenient. For example, you can tag all your web servers with say, "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. Remember, I mentioned that VPCs belong to GCP projects. But what if your company has several GCP projects and the VPCs need to talk to each other? Don't worry, that's totally doable and manageable. If you simply want to establish a peering relationship between two VPCs so that they can exchange traffic, that's what VPC Peering does. On the other hand, if you want to use the full power of IAM to control who and what in one project can interact with a VPC in another, that's what Shared VPC is for. A few slides back, we talked about how virtual machines can auto-scale to respond to changing load. But how do your customers get to your application when it might be provided by four VMs one moment and 40 VMs at another? Cloud Load Balancing is the answer. Cloud Load Balancing is a fully distributed, software-defined managed service for all your traffic. And because the load balancers don't run in VMs you have to manage, you don't have to worry about scaling or managing them. You can put Cloud Load Balancing in front of all your traffic - HTTP and HTTPS, other TCP and SSL traffic, and UDP traffic too. With Cloud Load Balancing, a single anycast IP frontends all your backend instances in regions around the world. It provides cross-region load balancing, including automatic multi-region failover, which gently moves traffic in fractions if backends become unhealthy. Cloud Load Balancing reacts quickly to changes in users, traffic, backend health, network conditions, and other related conditions. And what if you anticipate a huge spike in demand? Say, your online game is going to be a hit. Do you need to file a support ticket to warn Google of the incoming load? No. No so-called pre-warning is required. If you need cross regional load balancing for a web application, use HTTPS load balancing. For Secure Sockets Layer traffic that is not HTTP, use the global SSL proxy load balancer. If it's other TCP traffic that does not use Secure Sockets Layer, use the global TCP proxy load balancer. Those two proxy services only work for specific port numbers, and they only work for TCP. If you want to load balance UDP traffic or traffic on any port number, you can still load balance across a GCP region with the regional load balancer. Finally, what all those services have in common is that they're intended for traffic coming into the Google network from the internet. But what if you want to load balance traffic inside your project? Say, between the presentation layer and the business logic layer of your application? For that, use the internal load balancer. It accepts traffic on a GCP internal IP address and load balances it across Compute Engine VMs. One of the most famous Google services that people don't pay for is 8.8.8.8, which provides a public domain name service to the world. DNS is what translates internet host names to addresses. And as you would imagine, Google has a highly developed DNS infrastructure. It makes 8.8.8.8 available so that everybody can take advantage of it. But what about the internet host names and addresses of applications you build in GCP? GCP offers Cloud DNS to help the world find them. It's a managed DNS service running on the same infrastructure as Google. It has low latency and high availability and it's 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. You can publish and manage millions of DNS zones and records using the GCP console, the command line interface or the API. Google has a global system of edge caches. You can use this system to accelerate content delivery in your application using Google Cloud CDN. Your customers will experience lower network latency. The origins of your content will experience reduced load and you can save money too. Once you've set up HTTPS load balancing, simply enable Cloud CDN with a single checkbox. There are lots of other CDNs out there of course. What if you're already using one? Chances are, your CDN is a part of GCPs, CDN interconnect partner program and you can continue to use it. 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. There are many good choices. Many customers 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. But some customers don't want to use the internet, either because of security concerns or because they need more reliable bandwidth. They can consider peering with Google using Direct Peering. Peering 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 around the world. Customers who aren't already in a point of presence can contract with a partner in the carrier peering program to get connected. 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.
