Planning and configuring network resources

Study guide for Associate Cloud Engineer, Unit 2 · Topic 3. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks, quoted. Planning and configuring network resources. Considerations include:

1. Load balancing
2. Availability of resource locations in a network
3. Network Service Tiers

Planning and configuring network resources

Three decisions: which load balancer, where things live, which tier

Load balancing — pick the type from the traffic, then external or internal, then global or regional. Resource locations — every resource is global, regional or zonal, and that scope decides what it can attach to. Network Service Tiers — Premium or Standard, set per project and overridable per resource.

The guide gives this topic three short considerations — load balancing, availability of resource locations in a network, and Network Service Tiers — and no more detail than that. For an Associate Cloud Engineer each of them is a decision you make while building something. For load balancing, the decision is which of Google's load balancer types fits the traffic, and then whether it faces the internet or stays internal, and whether its backends sit in one region or several. For resource locations, it is knowing that every Compute Engine resource is global, regional or zonal, because that scope decides what a resource can be attached to and what a single failure can take down. And for Network Service Tiers, it is choosing between Premium and Standard, knowing that a project has a default and a resource can override it. We take them in that order, and the last slide gives you the three questions to ask in a scenario.

Load balancing: what it does, and the three choices

Type from the traffic, then external or internal, then scope

• A load balancer spreads user traffic across instances of your application
• Layer 7 routes on request attributes; Layer 4 on network and transport data
• External: clients on the internet. Internal: clients inside Google Cloud
• Global: backends in several regions. Regional: backends in one

Worked example (synthetic). A retailer's storefront serves HTTPS to shoppers worldwide from backends in two regions. That is Layer 7, external and global — three answers, one load balancer type.

Start with what a load balancer is for. In Google's words, a load balancer distributes user traffic across multiple instances of your applications, and by spreading the load it reduces the risk that your applications experience performance issues. Cloud Load Balancing is a fully distributed, software-defined, managed service — not an instance or device you run — and for global load balancers a single anycast internet protocol, or IP, address is the frontend for all of your backend instances in regions around the world. Choosing one comes down to three questions. First, the layer. Layer 7 load balancing adds request routing decisions based on attributes such as the hypertext transfer protocol, or HTTP, header and the uniform resource identifier; Layer 4 directs traffic on network and transport data. Google's summary is that you choose an Application Load Balancer for HTTP or HTTPS traffic at Layer 7, and a Network Load Balancer at Layer 4 — the proxy kind for transport layer security, or TLS, offloading, the passthrough kind for protocols such as the user datagram protocol, or UDP. Second, external or internal: an external load balancer when clients reach the application from the internet, an internal one when the clients are inside Google Cloud. Third, scope: a global load balancer supports backends in multiple regions, a regional one supports backends in a single region — and even a regional load balancer is globally accessible, because its IP address sits in one region but can be reached from anywhere.

The three load balancer types

What each does to the connection, and when Google says to pick it

Worked example (synthetic). A multiplayer game server speaks UDP and bans cheaters by their source IP. Only one row keeps both: the passthrough Network Load Balancer.

Here are the three types side by side, and the column that separates them is the connection. Proxy load balancers terminate incoming client connections at the load balancer and then open new connections from the load balancer to the backends — every Application Load Balancer and every proxy Network Load Balancer works that way. Passthrough load balancers do not terminate client connections, so the backend sees the original packets. Google's selection guidance follows from that. Choose an Application Load Balancer when you need a flexible feature set for applications with hypertext transfer protocol (HTTP) or HTTPS traffic. Choose a proxy Network Load Balancer to implement transmission control protocol, or TCP, proxy load balancing to backends in one or more regions. And choose a passthrough Network Load Balancer to preserve client source internet protocol (IP) addresses, avoid the overhead of proxies, and support additional protocols like the user datagram protocol, encapsulating security payload and the internet control message protocol — UDP, ESP and ICMP. When a scenario mentions keeping the client's original address, or a protocol that is not TCP, the proxy types are already out.

Choosing a load balancer, as three questions

Global is only on offer when the load balancer is external

Figure: A decision flow. HTTP or HTTPS traffic leads to an Application Load Balancer; otherwise, needing the client source IP or UDP, ESP or ICMP leads to a passthrough Network Load Balancer, and the rest to a proxy Network Load Balancer. For the proxy types, internet clients with backends in many regions lead to a global external load balancer, internal clients with backends in many regions to a cross-region internal load balancer, and backends in one region or a requirement to keep TLS in one region to a regional load balancer.

Worked example (synthetic). An internal reporting service has clients inside the company's network and backends in two regions. The flow ends at cross-region internal — not global, which is external only.

Drawn as a flow, the choice has a trap in the last step. The first two questions pick the type: hypertext transfer protocol (HTTP) or HTTPS traffic means an Application Load Balancer; otherwise, needing the client's source address or a protocol like user datagram protocol (UDP) means passthrough, and anything else is a proxy Network Load Balancer. The third question is scope, and here Google's wording matters: only external load balancers are available as global load balancers. For internal load balancers with backends in multiple regions, you choose the cross-region load balancer instead. And you choose a regional load balancer when you need backends in one region only, when you require only IPv4 termination, or when you have jurisdictional compliance requirements for traffic to stay in a particular region. That last reason deserves a second look: global load balancers terminate transport layer security, or TLS, in locations distributed around the world to minimize latency, so a rule that TLS must end inside one region rules the global options out. One more thing the flow cannot show: the resilience of the whole application depends not only on the load balancer's scope but also on the redundancy of the backend services behind it.

Availability of resource locations in a network

Global, regional or zonal: scope decides what a resource can reach

• Global: VPC networks with their routes and firewall rules; images
• Regional: subnets and regional static external IP addresses
• Zonal: VM instances and zonal persistent disks
• Spread across zones, and regions, for failure independence

Worked example (synthetic). An engineer creates a VM in us-central1-a and a zonal disk in us-central1-b, then cannot attach the disk. Nothing is broken; zonal resources only attach within one zone.

The second consideration is where resources can live and what that means for what can reach them. Regions are independent geographic areas that consist of zones, and a zone's name carries its region — the fully qualified name for zone a in region us-central1 is us-central1-a. Google's rule is that all Compute Engine resources are either global, regional or zonal in scope. Images are global; regional static internet protocol (IP) addresses are regional; persistent disks can be either regional or zonal. Scope decides access. Regional resources are accessible only to resources within the same region, and zonal resources only within the same zone — so to attach a zonal persistent disk to an instance, both must be in the same zone, and to assign a static IP address to an instance, the instance must be in the same region as the address. The network itself follows the same pattern: virtual private cloud, or VPC, networks — with their associated routes and firewall rules — are global resources, while subnets are regional, so an instance can use any subnet in the region that contains its zone. Scope is also your availability tool. Putting resources in different zones reduces the risk of one infrastructure outage affecting them all, and different regions give an even higher degree of failure independence — which is why Google recommends deploying fault-tolerant applications across multiple zones and multiple regions.

Scope, resource by resource

What each scope lets a resource reach

Worked example (synthetic). A team reserves a regional static IP in europe-west1 for a VM it then creates in us-east1. The assignment fails — the address is regional, so the VM must be in its region.

This table is the one to have memorized before the exam, because scenario items test it by describing an attachment that fails. At the top are the global resources: virtual private cloud networks, including their associated routes and firewall rules, are global; images are global, so instances in different zones can use the same image; and global static external internet protocol (IP) addresses are a global resource used for global load balancers. In the middle are regional resources: subnets, and regional static external IP addresses, which are accessible only to resources within the same region. At the bottom are zonal resources — the instance itself and a zonal persistent disk — accessible only within the same zone. Read any 'why did this fail' question against the table: a disk and an instance in different zones, or an address and an instance in different regions, is the whole answer.

Zonal, regional and global, in one picture

The disk shares its VM's zone; the global front end is in no region

Figure. Users reach a global external Application Load Balancer, drawn outside any region, through one anycast IP address. It sends traffic to backend VMs in three zones of region us-central1; each zone holds a VM and its zonal disk, while the subnet and static external IP address are regional. The callout notes that a disk must share its VM's zone and that the load balancer belongs to no region.

Worked example (synthetic). An architect adds a second zone of VMs behind the load balancer so one zone's outage does not stop the service. That changes nothing about the front end, which was never in a zone.

Now the three scopes in one picture. Inside the region are three zones, and inside each zone a backend virtual machine, or VM, with its zonal disk — zonal resources that can only be used by other resources in the same zone. The region box holds what is regional: the subnet, which any instance in the region's zones can use, and a regional static external internet protocol (IP) address. Outside the region, on the left, is the global external Application Load Balancer. With Cloud Load Balancing, a single anycast IP address is the frontend for backend instances in regions around the world, so the front end belongs to no zone and no region. The picture explains the availability advice too. Putting backends in different zones reduces the risk that one infrastructure outage affects them all at once, and the load balancer can keep sending users to whichever backends remain healthy.

Auto mode and custom mode VPC networks

Who decides which regions have a subnet

Figure. Two cards. Auto mode: one subnet per region is created automatically, and new projects start with a default auto mode network. Custom mode: no subnets are created automatically, so you add them in the regions you use. A band beneath notes that in both modes the network is global and each subnet is regional.

Worked example (synthetic). An engineer creates a custom mode network, then tries to create a VM in asia-east1 and finds no subnet to attach it to. Custom mode created none; one must be added in that region first.

The last piece of resource location is how a network gets its subnets, and Google offers two modes. When an auto mode VPC network is created, one subnet from each region is automatically created within it — and unless an organizational policy prohibits it, new projects start with exactly such a default network, with one subnet in each region. When a custom mode VPC network is created, no subnets are automatically created; you add a subnet in each region you intend to use. In both modes the geometry is the same: the virtual private cloud, or VPC, network is global and each subnet is regional. So the practical consequence of custom mode is the one the worked example shows — a virtual machine (VM) cannot be placed in a region until you have given that region a subnet.

Network Service Tiers

Premium optimizes for performance; Standard optimizes for cost

• Premium: traffic on Google's premium backbone
• Standard: traffic over regular ISP networks, a low-cost alternative
• The tier affects the path internet traffic takes to reach a resource
• Global external load balancers are Premium Tier only

Worked example (synthetic). A batch-download service with no latency target serves files from one region. Standard Tier fits; a global external Application Load Balancer in front of it would not be allowed in Standard.

The third consideration is Network Service Tiers, and Google states the trade in two sentences: Premium Tier delivers traffic on Google's premium backbone, while Standard Tier uses regular internet service provider, or ISP, networks; use Premium Tier to optimize for performance, and Standard Tier to optimize for cost. The load balancing guidance says the same thing as a rule of thumb — choose Premium for high performance and low latency, and Standard as a low-cost alternative for applications without strict latency or performance requirements. Be precise about what the tier changes. For a regional external internet protocol (IP) address, the tier only affects the path that traffic from the internet takes to reach the resource; traffic between virtual machine instances, in the same or different regions, stays on Google's network whichever tier you use. Standard Tier is available to resources that use regional external IP addresses in every region. The catch for load balancing is that some services are only available in Premium Tier — in particular, the global external Application Load Balancer and the global external proxy Network Load Balancer can only be configured in Premium.

Premium against Standard

Same resources, a different road in from the internet

Worked example (synthetic). A candidate says Standard Tier makes VM-to-VM traffic between regions cross the public internet. The last row says otherwise — the tier governs the internet-facing path only.

Side by side, the difference is narrower than candidates expect. The tiers differ on the path from the internet — Google's premium backbone against regular internet service provider networks — and so on what they optimize: performance and low latency for Premium, cost for Standard. They differ on the global external load balancers, which exist only in Premium Tier. Both offer regional external internet protocol (IP) addresses; Standard Tier is available for them in all regions. And they do not differ at all on traffic between virtual machine instances, which Google designs to stay on its own network in the same or different regions whichever tier you use. When an exam item claims Standard Tier changes internal traffic, the last row is the answer.

Setting the tier: project default, resource override

The resource's own tier always wins

Figure. Three stacked cards. The project default applies to new eligible resources that name no tier, defaults to Premium, and is set with gcloud compute project-info update and the default-network-tier flag. A tier set on a resource, such as with gcloud compute addresses create and the network-tier flag, always takes precedence. Changing the project default later leaves existing resources on their tier.

Worked example (synthetic). A project's default is switched to Standard on Monday. Friday's existing external IPs stay Premium; a new address created with no tier on Tuesday is Standard; one created with the network-tier flag set to PREMIUM is Premium.

The hands-on part of the tiers is where the setting lives. A project has a default network tier, and this tier is used by newly created eligible resources in the project unless you specify a tier for the resources themselves. You set it with the command on the first card, gcloud compute project-info update with the default network tier flag, replacing the placeholder with PREMIUM or STANDARD — and if you never set it, the default is PREMIUM. The second card is the override: the network tier you specify for a resource always takes precedence over the project default, as when you create a regional address with the network tier flag set to STANDARD. The third card is the one exam items like to test. Changing the default network tier for a project does not change the tier of any existing resource; it only changes the tier of new resources created without one.

What this topic actually tests

Three questions to ask of any network scenario

What traffic, from where, to how many regions? — that names the load balancer, and global is external only. What scope is each resource? — a zonal disk needs its VM's zone, a regional IP its VM's region. Which tier, set where? — Premium for performance, Standard for cost; the resource's tier beats the project default, and global external load balancers need Premium.

Close on three questions to ask of any networking scenario. First: what traffic, from where, to how many regions? hypertext transfer protocol (HTTP) or HTTPS means an Application Load Balancer, a need for the client's source address or a protocol like user datagram protocol (UDP) means passthrough, and remember that only external load balancers can be global — internal traffic to several regions needs the cross-region load balancer. Second: what is the scope of each resource? A zonal disk attaches only to an instance in its zone, a regional static internet protocol (IP) only to an instance in its region, and the virtual private cloud network with its firewall rules is global. Third: which tier, and set where? Premium Tier for performance, Standard for cost; a tier set on a resource always beats the project default, changing the default leaves existing resources alone, and the global external load balancers exist only in Premium. The next topics in Unit 3 deploy these same resources, so every one of these rules comes back as a command.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 2
• Global, regional, and zonal resources — Compute Engine
• Cloud Load Balancing overview
• Regions and zones — Compute Engine
• VPC networks
• Network Service Tiers overview
• Choose a load balancer
• Configure network tiers