Hello and welcome. In this lesson, we'll be talking about networking in Google Cloud. The exam guide calls out three networking topics, specifically: creating an auto-mode VPC with subnets, creating ingress and egress firewall rules for AVPC, and setting up a domain using Cloud DNS. Virtual private clouds are global resources with regional subnets. Each subnet has its own non-overlapping IP address range from which resources can obtain an IP address. There are two options for configuring subnets: custom mode and auto mode. A custom mode VPC allows us to manually define each subnet's IP address range and region. In contrast, auto mode VPCs will automatically define a subnet for each region.

If you look at the default network, notice the mode is set to auto and each region specifies a CIDR range which roughly allows about 4,000 IP addresses per subnet if my Googling is correct. And yes, if a new region is brought into existence it, too, will automatically get a new subnet. So when would you use custom verse auto? Auto mode is great for initial development. It's also useful in production if you need to ensure that every region has a subnet. However, for production systems we should really try our best to value specificity, which means rather than using all of the defaults, we should make a concerted effort to understand exactly what our system requires and where practical ensure that we're building just that. So, that said, custom mode networks are recommended for production systems. They should be carefully thought out and implemented with purpose. If your system needs just two subnets with roughly 200 IP addresses in two different regions, just create that. After all, you can expand a subnet as needed without downtime.

When planning out your IP address ranges, just keep in mind that there are four reserved IP addresses for each subnet. Creating either type of VPC is roughly equivalent. The subnet mode flag accepts either custom or auto. Again, custom mode expects that we're going to specify the CIDR range and region for every subnet that we require. And auto just fills that out for us.

Ah, networking, all of those ones and zeroes flying through the air, dancing along the wires and bouncing between devices. Be honest, do you know what the data on your network looks like? What connections exist? What services are running on the different devices? Are these different devices protected by a firewall or are they just exposed to the network? Once we have a network and a networked device we immediately have an attack vector and something to attack. Within minutes of connecting a new device to the public Internet, it'll start being probed and potentially attacked. Firewalls provide a layer of protection by allowing us to limit incoming and outgoing traffic. JCP supports both ingress and egress rules and those are just 15th-century words for incoming and outgoing. 

Let's run through VPC firewalls. VPC networks implement a firewall by creating firewall rules. A firewall rule is a global resource that is associated with a specific network. Rules allow us to control the traffic flow to and from network resources. Rules fall into two categories: ingress and egress. Imagine all incoming traffic is blocked and you wanna be able to connect to an instance on port 80 for web traffic. You could create an ingress rule that allows traffic from the Internet to the instance on TCP port 80. Simple enough, right? We can specify the IP address of the instance as the target. We can set the source as 0.0.0.0/0, which is the IPv4 CIDR notation for the entire Internet because it encompasses all of the IP addresses. We set the protocol to TCP and the port to 80 and the action to allow. However, now we have two rules that seem to contradict each other, and this is what the priority setting helps with. The priority determines which rule is matched in these circumstances. Priority goes from low to high. The smaller the priority number, the higher its priority. 

Okay, so now we have a valid ingress rule that will allow web traffic to the specified IP address. Using IP address or CIDR range is really useful though it's not very dynamic. Firewall rules provide multiple ways of defining the resources for which a rule applies. In addition to using an IP address or range, we can also specify instances based on network tags or by service account. Using network tags allows a rule to apply to any instance that has that network tag applied, which allows us to manage firewall settings dynamically using these tags. Any instance with a network tag applied will automatically have the same rule. Service accounts are similar in that we can have rules applied to instances that are running under a specific service account. The traffic source field is similar to the destination in that we can use IP address range, network tags, and service accounts. 

So with ingress rules, we specify zero or more rules that can either allow or deny traffic to one or more networked resources from one or more networked resources on specific protocols and ports. Egress rules are similar except that the target is the traffic source, defining which of our networked resources will have this outgoing rule applied. The egress target can use the IP address range, network tags, and service accounts. The destination specifies the IP address range for the rule. For egress traffic, the only destination option is to use CIDR notation. It doesn't work with network tags or service accounts. 

All right, let's pivot to Cloud DNS. Cloud DNS provides both public and private zones. Public zones are available to the Internet. Private zones are limited to a specific network. Public zones behave the same way as they do with any other DNS providers, allowing us to create record sets as needed and we manage that with Cloud DNS. In order to make use of private zones, Compute Engine instances must use the metadata server as the DNS server. Some of the public images are already configured to do that. However, if yours is not pre-configured then you're going to have to configure that for yourself if you wanna make use of private DNS. With a private zone, we can specify just about any domain we need because it's not externally available. So that allows us a lot of flexibility, especially if we need to mirror an on-prem private DNS configuration. The creation process is fairly simple. After creating a zone, we can add record sets and that's about it. If you're familiar with basic DNS concepts then Cloud DNS is going to be very familiar to you. 

All right, that is going to wrap up this lesson. Thank you so much for watching and I will see you in another lesson.