Common network designs

1. Common network designs

Let's use what we have learned so far and look at common network designs. Now, 'common' is a fairly relative term. While I could spend all day talking about network designs, I have picked a handful of designs that best relate to this module. Let's start by looking at availability. If your application needs increased availability, you can place two virtual machines into multiple zones, but within the same subnetwork as shown on this slide. Using a single subnetwork allows you to create a firewall rule against the subnetwork, 10.2.0.0/16. Therefore, by allocating VMs on a single subnet to separate zones, you get improved availability without additional security complexity. A regional managed instance group contains instances from multiple zones across the same region, which provides increased availability. Next, let's look at globalization. In the previous design we placed resources in different zones in a single region, which provides isolation for many types of infrastructure, hardware, and software failures. Putting resources in different regions as shown on this slide provides an even higher degree of failure independence. This allows you to design robust systems with resources spread across different failure domains. When using a global load balancer, like the external Application Load Balancer, you can route traffic to the region that is closest to the user. This can result in better latency for users and lower network traffic costs for your project. We'll explore both managed instance groups and load balancers later in the course series. Now, as a general security best practice, I recommend only assigning internal IP addresses to your VM instances whenever possible. Cloud NAT is Google's managed network address translation service. It lets you provision your application instances without public IP addresses, while also allowing them to access the internet in a controlled and efficient manner. This means your private instances can access the internet for updates, patching, configuration management, and more. In this diagram, Cloud NAT enables two private instances to access an update server on the Internet, which is referred to as outbound NAT. However, Cloud NAT does not Implement inbound NAT. In other words, hosts outside your VPC network cannot directly access any of the private instances behind the Cloud NAT gateway. This helps you keep your VPC networks isolated and secure. Similarly, you should enable Private Google Access to allow VM instances that only have internal IP addresses to reach the external IP addresses of Google APIs and services. For example, if your private VM instance needs to access a Cloud Storage bucket, you need to enable Private Google Access. You enable Private Google Access on a subnet-by-subnet basis. As you can see in this diagram, subnet-a has Private Google Access enabled and subnet-b has it disabled. This allows VM A1 to access Google APIs and services, even though it has no external IP address. Private Google Access has no effect on instances that have external IP addresses, That's why VMs A2 and B2 can access Google APIs and services. The only VM that can't access those APIs and services is VM B1. This VM has no public IP address and it is in a subnet where Google Private Access is disabled.

2. Let's practice!

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.