Managing networking resources

Study guide for Associate Cloud Engineer, Unit 4 · Topic 5. 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. Managing networking resources. Considerations include:

1. Adding a subnet to an existing VPC
2. Expanding a subnet to have more IP addresses
3. Reserving static external or internal IP addresses
4. Working with Cloud DNS and Cloud NAT

Managing networking resources

Day two for a network: grow it, pin its addresses, name it, let it out

Grow — add a subnet to a network that already exists, or expand a subnet that is running short of addresses. Pin — reserve static external and internal IP addresses, promote an ephemeral one, and release what you no longer use. Name and let out — Cloud DNS zones and records, and Cloud NAT for outbound traffic from VMs with no external address.

Unit 3 built the network. This topic manages it once it is running, and the guide lists four things to manage. Adding a subnet to an existing virtual private cloud, or VPC, network. Expanding a subnet so that it has more internet protocol, or IP, addresses. Reserving static external or internal IP addresses. And working with two managed services: Cloud DNS, Google's domain name system service, and Cloud NAT, its network address translation service. Each is a day-two change to something already carrying traffic, and each has one rule the exam leans on. A new subnet's range must not overlap another subnet in the network or in a peered network. An expansion can only grow, and it cannot be undone. A reserved address stays reserved until you release it, even after the resource that used it is gone. And Cloud NAT carries outbound connections and their replies, but never lets an unsolicited connection in. We take them in the guide's order.

Adding a subnet to an existing VPC

A running network takes new subnets — each in the region you name

• Once a network exists, you can add subnets to it, one region per subnet
• The range can't overlap another subnet in the network or in a peered one
• Auto mode networks accept manual subnets, with ranges outside 10.128.0.0/9
• Every primary IPv4 range has four unusable addresses

Worked example (synthetic). A team's custom mode network prod-net serves only us-central1, and a new service must run in asia-south1. The fix is one more subnets create in asia-south1 — not a new network, and not a bigger subnet in us-central1.

The first consideration is growing a network by adding a subnet, and Google's wording makes it routine: after you have created the network, you can add subnets to it. The command is the one that built the network's first subnet — gcloud compute networks subnets create, naming the subnet, the network it joins, its primary range and its region — because subnets are regional resources with internet protocol, or IP, address ranges associated with them. The network itself has no region; virtual private cloud, or VPC, networks are global resources, so reaching a new region means a new subnet there, never a new network. The range is where additions go wrong. You can't create primary and secondary ranges for subnets that overlap with any allocated range, any primary or secondary range of another subnet in the same network, or any IPv4 ranges of subnets in peered networks — and Google Cloud prevents the creation in those cases rather than letting it through. Auto mode networks add a condition of their own: in addition to the automatically created subnets, you can add more subnets manually in regions that you choose, by using IP ranges outside of 10.128.0.0/9. And size the range knowing that there are four unusable IP addresses in every primary IPv4 subnet range.

What a new subnet's range must stay clear of

Google Cloud refuses an overlapping subnet instead of creating it

Worked example (synthetic). An engineer copies 10.10.0.0/20 from a partner's network, which is peered with this one, into a new subnet. The request is refused: it overlaps a subnet range in a peered network.

This table is the range check the exam asks about, read from the new subnet's point of view. If the new range overlaps a primary or secondary range of another subnet in the same network, Google Cloud prevents the creation. The same is true across a peering: overlapping any IPv4 range of a subnet in a peered network is refused, so a range that looks free inside one virtual private cloud, or VPC, network can still collide with a network it is joined to. Allocated ranges are off limits in the same way. Auto mode networks add the fourth row: you can add manual subnets to them, but only with internet protocol, or IP, ranges outside of 10.128.0.0/9 — the block the automatic subnets are carved from. The last row is the good news for planning: a subnet can grow sideways later, because you can add secondary IPv4 ranges to subnets, or remove any secondary range as long as no resources are using addresses in it. When an exam item says a subnet creation failed, look for the overlap first.

Expanding a subnet to have more IP addresses

A smaller prefix length means a bigger range — and it can't be undone

• Expand the primary range by setting a smaller prefix length
• It can be expanded, but never replaced or shrunk — the change is permanent
• Automatically created auto mode subnets expand no further than /16
• Subnets used only for load balancer proxies can't be expanded
• Expand conservatively; you can always expand again later

Worked example (synthetic). A /24 subnet in us-east1 is nearly full. The engineer expands it to /22, not /16: four times the addresses now, and room to grow again later — because nothing that is expanded can be taken back.

The second consideration is the subnet that has run short of addresses, and Google gives it one command and several warnings. The mechanism: you can expand the primary IPv4 range of an existing subnet by modifying its subnet mask, setting the prefix length to a smaller number — a slash twenty-two holds more internet protocol, or IP, addresses than a slash twenty-four. The command is gcloud compute networks subnets expand-ip-range, with the subnet, its region and the new prefix length. Now the warnings, because this is a one-way door. After you create a subnet, its primary range can be expanded but not replaced or shrunk. Expanding it cannot be undone, and you cannot shrink it afterwards. That is why Google's advice is to expand primary ranges conservatively — you can always expand them again. Two subnets have limits of their own: when expanding an automatically created subnet in an auto mode network, the broadest prefix you can use is slash sixteen; and you can't expand subnets that are used exclusively for load balancer proxies at all. Finally, the change is not instant — expanding a primary range can take several minutes to complete.

The checks that come before an expansion

An expansion is permanent, so every check comes first

Figure: A flow of checks before expanding a subnet. If the subnet is used only for load balancer proxies, it cannot be expanded. If it was created automatically in an auto mode network, the broadest prefix is /16. Either way, check the address space of connected networks, run expand-ip-range growing only as far as needed, and then update configurations that assume the old range.

Worked example (synthetic). Before expanding web-subnet to /20, the engineer checks the partner network it is peered with — the larger range would collide with a subnet there — and settles on /21.

Because an expansion is permanent, Google's guidance puts the thinking before the command, and this figure orders it. First, is the subnet one used exclusively for load balancer proxies? Those can't be expanded at all. Second, was it created automatically in an auto mode network? Then the broadest prefix you can use is slash sixteen. Third, and easiest to forget: consider the IPv4 address space in any networks to which your virtual private cloud, or VPC, network is or will be connected before you expand — a range that grows into a peered or on-premises network's space creates exactly the overlap Objective 1 warned about. Only then run expand-ip-range, and grow only as far as you need. The last box is the follow-up. If you expand a primary range, you might need to modify other configurations that are assuming it, and Google names one: if a Google Kubernetes Engine, or GKE, cluster uses the subnet, you must add the expanded internet protocol, or IP, range to the control plane authorized networks list.

Reserving static external or internal IP addresses

Reserved means yours until you release it — whether or not it is used

• A static external address stays fixed until you decide to release it
• Reserve a new one, or promote the ephemeral address a VM already has
• Regional for VMs and regional load balancers; global only for global ones
• Static internal addresses come from a subnet's range and are regional
• Deleting the resource doesn't release the address — you do

Worked example (synthetic). A VM's ephemeral external address is already on a partner's allow list. The engineer promotes it to static rather than reserving a new one: the address, and the allow list, survive the VM being rebuilt.

The third consideration is pinning addresses so they stop changing. A static external internet protocol, or IP, address is a resource that reserves an IP address for use by other resources in your project, and a reserved address remains fixed and available for your customers and services until you decide to release it. There are two ways to get one: you can reserve new external IP addresses, or promote existing ephemeral external IP addresses — promotion keeps the address a resource already has, so it remains reserved even after that resource is deleted. Only one resource at a time can use a static external address, and scope matters: reserve a regional address for a virtual machine, or VM, or for a regional load balancer, because global IP addresses can be used only with global load balancers. Internal addresses work the same way inside the network. Static internal IP addresses let you reserve internal addresses from the range configured in a subnet and assign them to resources as needed; they are regional, restricted to the region where they are reserved. Two consequences follow from reserving. Deleting a resource does not automatically release a static internal IP address — you must release it manually. And a reserved external address you keep but do not assign is charged at a higher rate than addresses that are in use, so release what you no longer need.

Static external against static internal

One command family, two pools, and different rules for each

Worked example (synthetic). A database VM keeps 10.20.0.15 across rebuilds because the address is a static internal reservation in its subnet; the web tier's global load balancer keeps one global external address.

Side by side, the two kinds differ in the ways the exam probes. Where the address comes from: static external addresses are reserved from Google's pool of external internet protocol, or IP, addresses; static internal ones from the IP range configured in a subnet, which is why you must create a virtual private cloud, or VPC, network with a subnet before you can reserve one. Scope: external addresses are regional, or global when they front a global load balancer; internal addresses are regional, restricted to the region where they are reserved. When the resource is deleted, both stay reserved — the property that lets you always use the same IP address for the same resource even if you delete and re-create it. And an idle reservation is not free of consequences: an unassigned external address is charged at a higher rate than addresses in use, and the number of static internal addresses you can reserve cannot exceed your project's quota.

Reserve, promote, release

One command reserves every kind; its flags decide which

Figure. Five gcloud commands. Reserve a regional external address with gcloud compute addresses create and --region; a global external address with --global for global load balancers; a static internal address with --region, --subnet and --addresses; promote an ephemeral external address with --addresses and the region; and release an address with gcloud compute addresses delete.

Worked example (synthetic). An engineer tidies a project: gcloud compute addresses delete releases three reservations no VM uses. The console refuses one of them because it is still in use; the CLI would not have refused it.

Every reservation on this slide is the same command, gcloud compute addresses create, and the flags decide what it reserves. With a region flag it reserves a regional external address. With the global flag and an IP version, a global one — for global load balancers only. With a region, a subnet and an addresses flag, it reserves a static internal internet protocol, or IP, address, which must be within the subnet's primary IP range; leave the address out and one is allocated from the subnet automatically. Promotion uses the same command again: provide the ephemeral address in the addresses flag, with its region or the global flag, and promoting does not cause Google Cloud to drop packets sent to the virtual machine, or VM. Releasing is deleting the address resource with gcloud compute addresses delete. Two cautions there. In the console you can release a static address only if no other resource is using it; from the command line you can release it either way. And once released, you might not get the same address back, because someone else might already have reserved it.

Working with Cloud DNS and Cloud NAT

One service names your resources; the other lets private VMs out

• Cloud DNS: public zones for the internet, private zones for chosen VPCs
• A new public zone serves once the registrar points to its name servers
• Cloud NAT gives VMs without external IPs outbound access only
• A NAT gateway lives on a Cloud Router, in the subnets' region
• Unsolicited inbound connections are never allowed through

Worked example (synthetic). A company's internal services resolve db.corp.internal through a private zone, and the same VMs — which have no external IP addresses — download security updates through Cloud NAT. Nothing on the internet can open a connection to them.

The fourth consideration pairs two managed services, and the exam treats them as a pair because both answer the question how does a private network talk to the world. Cloud DNS, the domain name system service, lets you publish your zones and records without the burden of managing your own DNS servers and software. It offers two kinds of zone: a public zone is visible to the public internet, while a private zone is visible only from one or more virtual private cloud, or VPC, networks that you specify. With Shared VPC, a private zone is created in the host project and the shared networks are added to its authorized networks. A public zone is not live on creation; you must update your domain's name servers to use Cloud DNS before its records are published. Cloud NAT, the network address translation service, handles the other direction. Public NAT lets resources that don't have external internet protocol, or IP, addresses reach destinations on the internet. You configure it by creating a Cloud NAT gateway in the region of the subnets that need it, on a Cloud Router that holds its configuration. And it is outbound only: it doesn't permit unsolicited inbound requests from the internet, even if firewall rules would otherwise permit them.

A zone, then its records

Public or private is one flag; the networks list makes it private

Figure. Three gcloud commands and a note. A public zone is created with gcloud dns managed-zones create and --visibility=public; a private zone adds --networks with the list of VPC networks and --visibility=private; a record set is created with gcloud dns record-sets create, giving the data, TTL, type and zone. A new zone starts with default NS and SOA records, which should be left as Cloud DNS set them, with the registrar pointed at its name servers.

Worked example (synthetic). An engineer creates a public zone for example.com, adds an A record for the web server's address, and waits — the name still does not resolve until the registrar is updated to Cloud DNS's name servers.

Cloud DNS, the domain name system service, is a zone and then its records, and both are one command each. A public zone is gcloud dns managed-zones create with a name, a description, the DNS name it answers for, and the visibility flag set to public. A private zone adds one flag and changes another: the networks flag lists the virtual private cloud, or VPC, networks allowed to query it, and the visibility is private. Records are record sets: gcloud dns record-sets create, with the record's name, its data, its time to live, or TTL, its type and the zone — an internet protocol, or IP, address in the format of four numbers needs an A record. When a zone is created, default name server, or NS, and start of authority, or SOA, records are created for you, and Google is specific about them: do not change the name of your zone's NS record, or the list of name servers Cloud DNS selects. Point your registrar at those servers instead. Two operational facts close the service. The TTL, which is specified in seconds, controls how long resolvers cache a record, so a change is not seen everywhere at once. And deleting a zone permanently removes its records — they cannot be recovered.

What Cloud NAT does, and what it does not

Outbound connections go out, their replies come back — nothing else

Worked example (synthetic). A team gives one VM an external IP address for testing and is surprised its traffic no longer uses the NAT addresses. The external IP on the interface takes precedence over Public NAT.

Cloud NAT, the network address translation service, is easiest to reason about as six answers. Which virtual machines, or VMs, use it: those without an external internet protocol, or IP, address, because an external IP address on an interface always takes precedence and performs one-to-one NAT without using Public NAT. Which traffic: outbound connections, with translation for established inbound response packets only. Unsolicited inbound connections: never, even if firewall rules would otherwise permit them. Where it lives: each gateway is associated with a single virtual private cloud, or VPC, network, region and Cloud Router. What it is not: a box packets travel through. Cloud NAT doesn't rely on proxy VMs; the gateway allocates a set of external IP addresses and source ports to each VM that uses it. And firewall rules still apply first: when the gateway provides NAT for a VM's interface, applicable egress firewall rules are evaluated for that interface before NAT.

Where Cloud NAT sits, and where it does not

The gateway configures the path; the packets never visit it

Figure: A flow chart. A VM with no external IP address sends an outbound connection into the VPC network, where translation is applied by its software-defined networking, and on to an internet destination; only the established reply comes back. The Cloud Router, as control plane, holds the Cloud NAT gateway configuration, which configures the network — drawn with dotted lines because no packet passes through either. An unsolicited inbound connection is refused.

Worked example (synthetic). An engineer plans to scale up the Cloud Router because NAT traffic doubled. Nothing to scale: the router and gateway hold configuration, and no packet passes through them.

This figure is drawn to correct the picture most people bring from other clouds, where a NAT box sits on the path and every packet crosses it. In Google Cloud the solid lines are the only packet path: the virtual machine, or VM, opens an outbound connection, the virtual private cloud, or VPC, network translates it, and the reply comes back. Google says exactly where the translation happens: Cloud NAT configures the Andromeda software that powers your VPC network so that it provides source network address translation, or NAT, for resources. The dotted lines are the control plane. You configure a NAT gateway on a Cloud Router, which holds the configuration parameters you specify, and Google is explicit that the Cloud NAT gateway and the Cloud Router aren't involved in the data plane, so packets don't pass through either one. Even the router's usual job is absent here — although the gateway is managed by a Cloud Router, Public NAT doesn't use or depend on the border gateway protocol, or BGP. The last arrow is the rule the exam repeats: an unsolicited inbound connection is refused.

A router, then a NAT gateway on it

Automatic addresses by default; reserved static ones for an allow list

Figure. Three gcloud commands. First, gcloud compute routers create makes a Cloud Router in the network and region. Second, gcloud compute routers nats create makes the NAT gateway for all subnet ranges with automatically allocated external addresses, the default. Alternatively, the gateway takes --nat-external-ip-pool with reserved static external addresses. A note warns that changing manually allocated NAT addresses immediately closes existing connections.

Worked example (synthetic). A bank's partner accepts calls only from two known addresses. The engineer reserves two static external addresses and passes them in --nat-external-ip-pool, and the partner allows exactly those two.

Setting up Cloud NAT, the network address translation service, is two commands, and Google's own example shows both. First a Cloud Router: gcloud compute routers create, with the network and region. Then the gateway on it: gcloud compute routers nats create, naming the router, with all subnet internet protocol, or IP, ranges and automatically allocated external addresses — a configuration that enables NAT for all IPv4 subnet ranges in the region. Automatic is the default; by default, Public NAT uses automatic NAT IP address allocation. The exam's favourite variation replaces that last flag. When a destination service might only allow connections from known external IP addresses, manual allocation lets you confidently share a set of common external source addresses with that party. The flag is nat external IP pool, and its values are the static reserved external IP addresses you want to use — which is where Objective 3's reservations come back. Manual allocation has one sharp edge: if you change the addresses used for Cloud NAT, all connections on the previously allocated ones immediately close.

What this topic actually tests

Four day-two changes, and the rule behind each

Adding a subnet? Name the region; keep the range clear of other subnets, peered networks and — in auto mode — 10.128.0.0/9. Expanding? A smaller prefix length; never shrunk, never undone — expand conservatively. Reserving? Regional unless it fronts a global load balancer; deleting the resource doesn't release it. DNS and NAT? Private zones list their networks; public zones need the registrar's name servers; Cloud NAT lets out outbound connections and their replies, and nothing else in.

Close on the four rules, one per consideration. Adding a subnet: the virtual private cloud, or VPC, network is global and the subnet is regional, so name the region, and keep the range clear of every other subnet in the network, of subnets in peered networks, and — in an auto mode network — of 10.128.0.0/9. Expanding a subnet: set a smaller prefix length, and remember that the change can never be shrunk or undone, which is why Google says to expand conservatively and check connected networks first. Reserving an address: regional for virtual machines and regional load balancers, global only for global load balancers, and a reservation outlives the resource that used it until you release it. And the two services: a private zone in Cloud DNS, the domain name system service, lists the networks that may see it, a public zone serves only once the registrar points at its name servers, and Cloud NAT, the network address translation service, carries outbound connections and their replies while refusing anything unsolicited — with the Cloud Router and gateway as configuration, never as a hop. Those four rules answer most of this topic's scenarios.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 4
• Create and manage VPC networks
• Subnets
• VPC networks
• Reserve a static external IP address
• Reserve a static internal IP address
• Cloud DNS overview
• Quickstart: Set up DNS records for a domain name with Cloud DNS
• Cloud NAT overview
• Public NAT
• Create, modify, and delete zones
• Add, modify, and delete records
• Example Cloud NAT setup with Compute Engine
• Set up and manage network address translation with Cloud NAT