Deploying and implementing networking resources

Study guide for Associate Cloud Engineer, Unit 3 · 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. Deploying and implementing networking resources. Considerations include:

1. Creating a VPC with subnets (e.g., custom mode VPC, Shared VPC)
2. Creating ingress and egress firewall rules and policies (e.g., IP subnets, network tags, service accounts)
3. Peering external networks (e.g., Cloud VPN, VPC Network Peering)

Deploying and implementing networking resources

Build the network, filter its traffic, then join it to other networks

Build — a custom mode VPC network, its regional subnets, and Shared VPC when many projects need one network. Filter — ingress and egress firewall rules, targeted by tag or by service account, and the policies above them. Join — VPC Network Peering to another VPC network, Cloud VPN to a network outside Google Cloud.

Unit 2 planned the network: which load balancer, where each resource lives, which tier its traffic takes. This topic builds it, and the guide lists three things to build. First, a virtual private cloud, or VPC, network with subnets — in custom mode, and as a Shared VPC when many projects need to use one network. Second, the ingress and egress firewall rules and policies that decide what traffic reaches or leaves each virtual machine, or VM, identified by internet protocol, or IP, ranges, by network tags, or by service accounts. Third, peering with other networks: VPC Network Peering to join two VPC networks, and Cloud VPN — a virtual private network — to join a network outside Google Cloud. Each has a command an engineer runs, and each has one fact the exam leans on. For the subnets it is scope; for the firewall it is priority and the implied rules; for peering it is that peering is not transitive. We will build in that order, because every later step needs the network the first step creates.

Creating a VPC network with subnets

Custom mode: create the network, then each subnet in its region

• Custom mode suits most production use cases; plan it in advance
• The network is global; each subnet is regional, with its own IP range
• A VM needs a subnet in its zone's parent region
• Auto mode adds a subnet per region; converting to custom is one-way

Worked example (synthetic). A team creates prod-net in custom mode and one subnet in us-central1. A colleague's VM in europe-west1-b fails to attach: the network is global, but it has no subnet in that VM's region yet.

Start with the network itself. Google's advice is direct: production networks should be planned in advance, and custom mode virtual private cloud, or VPC, networks are better suited for most production use cases. Custom mode is two steps, and the exam checks that you know both. For custom mode VPC networks, create a network, then create the subnets that you want within a region. The first command is gcloud compute networks create with the subnet mode flag set to custom; the second is gcloud compute networks subnets create, naming the network, a primary range, and a region. The region matters because of scope. VPC networks, including their associated routes and firewall rules, are global resources, while subnets are regional resources with internet protocol, or IP, address ranges associated with them. A virtual machine, or VM, therefore needs a subnet in the right place: if you select a network for the VM, you must select one that contains a subnet in the selected zone's parent region. Auto mode is the other choice — when you create an auto mode VPC network, one subnet is created in each Google Cloud region — and you can later convert it to custom mode, but conversion from auto to custom mode is a one-way process.

Two commands for a custom mode network

The network has no region; the subnet must name one

Figure. Two gcloud commands in order. First, gcloud compute networks create with subnet mode set to custom creates the global network with no subnets. Second, gcloud compute networks subnets create names the network, a primary range and a region, and is repeated for every region that will host resources.

Worked example (synthetic). An engineer scripts a new network for two regions. The script needs one networks create command and two subnets create commands — one per region — before any VM can be placed.

Here are the two commands as Google documents them. The first creates the network: gcloud compute networks create, the network's name, and subnet mode set to custom, with the dynamic routing mode and maximum transmission unit as optional settings. Notice what it does not take: a region. The network is a global resource. The second creates a subnet: gcloud compute networks subnets create, the subnet's name, the network it belongs to, its primary range, and a region — because subnets are regional. That asymmetry is the whole practical lesson. In custom mode, a region has no subnet until you create one there, so a deployment into a new region starts with another subnets create command, not with the virtual machine.

Shared VPC: one network, many projects

The host project owns the network; service projects use its subnets

Worked example (synthetic). A company's finance and web teams each have a project, and security must own every firewall rule. The network lives in one host project; both team projects are attached as service projects and create VMs in its subnets.

The guide's second example is Shared VPC — one virtual private cloud network shared across projects — and it solves a specific problem: many projects, one network, central control. When you use Shared VPC, you designate a project as a host project and attach one or more other service projects to it, and eligible resources from those service projects can use subnets in the Shared VPC network. The value is the split of duties. Shared VPC lets organization administrators delegate administrative responsibilities, such as creating and managing instances, to Service Project Admins while keeping centralized control over subnets, routes and firewalls — Service Project Admins are only given the ability to create and manage instances that use the network. The roles are real ones: the Shared VPC Admin holds Compute Shared VPC Admin, granted at the organization or folder. Two limits come up on the exam. Participating host and service projects cannot belong to different organizations. And the host project matters more than any other, because the accidental deletion of a host project would lead to outages in all service projects attached to it.

Provisioning Shared VPC, in order

Enable the host first; only then can projects attach

Figure: A four-step flow: the Shared VPC Admin role is granted; the admin enables the host project with gcloud compute shared-vpc enable; the admin attaches a service project with gcloud compute shared-vpc associated-projects add; then Service Project Admins create VMs in the shared subnets.

Worked example (synthetic). An engineer tries to attach the web team's project before the platform project is a host. The attach step has nothing to attach to — enabling the host comes first.

Provisioning Shared VPC, the shared virtual private cloud network, has an order, and Google states the first constraint plainly: a Shared VPC Admin must first enable a project as a host project. The command is gcloud compute shared-vpc enable, followed by the host project's ID. Only then does attaching make sense: gcloud compute shared-vpc associated-projects add, the service project's ID, and the host project flag naming the host. After that, Service Project Admins create instances in the service project that use the shared subnets. The order is the point of the figure. An exam item that attaches before enabling, or that has a Service Project Admin create a subnet, has broken it.

Creating ingress and egress firewall rules

One direction, one priority, one target — and the implied rules

• Each rule is ingress or egress, never both; rules are stateful
• Lowest priority number wins; the range is 0 to 65535, default 1000
• No matching rule: ingress is denied, egress is allowed
• Start from deny, and allow only the traffic you need

Worked example (synthetic). A new VM in a custom mode network cannot be reached on port 22 although nothing blocks it. Nothing needs to: with no ingress rule, the implied deny ingress rule applies.

Virtual private cloud, or VPC, firewall rules apply to a given project and network, and every rule answers four questions. Direction: each firewall rule applies to incoming, ingress, or outgoing, egress, connections, not both. State: VPC firewall rules are stateful, so when a connection is allowed in either direction, return traffic matching that connection is also allowed — you never write a rule for the reply. Priority: only the highest priority rule, which means the lowest priority number, whose other components match the traffic is applied, and conflicting rules with lower priorities are ignored; the number is an integer from 0 to 65535, with a default of 1000. And what happens when nothing matches. Google's worked example gives both halves: a virtual machine, or VM, with no ingress rule has the implied deny ingress rule block all incoming traffic, and a VM with no egress rule has the implied allow egress rule let it send traffic to any destination. The default network is the exception people trip on — it is pre-populated with rules that allow incoming connections, and a custom network you create is not. Google's own best practice follows from all of this: block all traffic by default and only allow the specific traffic you need.

Two rules, one target, and which one wins

Priority 50 beats priority 1000 for the traffic both match

Figure. Two gcloud compute firewall-rules create commands that both target VMs tagged webserver. The first denies all ingress TCP from anywhere at priority 1000. The second allows ingress TCP port 80 from 10.240.10.0/24 at priority 50. Because 50 is the lower number, port 80 from that subnet is allowed and all other TCP is denied.

Worked example (synthetic). An engineer adds an allow rule at priority 2000 and wonders why port 80 is still blocked. The deny at 1000 is the lower number, so it wins for the traffic both rules match.

Google's own example shows priority doing its work. Both rules target the same virtual machines — those carrying the network tag webserver. The first is a deny: ingress, all of the transmission control protocol, or TCP, from any source, at priority 1000. The second is an allow: ingress, TCP port 80, only from the range 10.240.10.0/24, at priority 50. For a TCP connection to port 80 from that subnet, both rules match, and the one with the lower number applies — so it is allowed. Every other TCP connection matches only the deny. Read the flags as the four questions from the last slide: action, direction, the rules and the source ranges, the priority, and the target. The classic mistake runs the other way: an engineer adds an allow rule with a higher number than an existing deny, and the deny keeps winning.

Targeting by network tag or by service account

Tags are easy to change; service accounts give strict control

Worked example (synthetic). A payments team fears a developer could tag any VM as payments and open it to card traffic. Targeting the rule at the payments service account instead means only VMs running as that account are reached.

Most rules do not apply to every virtual machine in the network; they pick targets, and the guide names two ways. A rule with target network tags applies only to instances whose network interface has a tag matching one of the rule's target tags. A rule with target service accounts applies only to instances that use a matching service account. The difference is who can change membership. A network tag is an arbitrary attribute, and one or more tags can be associated with an instance by any identity and access management, or IAM, principal who has permission to edit it. A service account is harder to move: changing the service account associated with an instance requires that you stop and restart it. So Google's guidance is that if you need strict control over how firewall rules are applied, use target service accounts rather than target network tags. One restriction to remember: network tags and service accounts cannot be used in the same firewall rule.

Firewall policies above the rules

Group rules into one object, and attach it higher up

Worked example (synthetic). Security must block a known-bad range across forty projects, including projects created next month. One hierarchical firewall policy on the organization does it once.

The guide says rules and policies, and the policies sit above the individual rules. Hierarchical firewall policies let you group rules into a policy object that can apply to many virtual private cloud, or VPC, networks in one or more projects, and you can associate them with an entire organization or individual folders. Global network firewall policies group rules into an object that applies to all regions of one VPC network, and regional network firewall policies to a specific region of it. VPC firewall rules, the ones on the previous slides, apply to a given project and network. Google's best practice ties the levels together: use hierarchical firewall policy rules to block traffic that should never be allowed at an organization or folder level, and leave project-level rules to allow what each workload needs.

Peering external networks

VPC Network Peering for VPC networks; Cloud VPN for everything else

• VPC Network Peering joins two VPC networks — any projects or organizations
• It needs a peering configuration on BOTH sides, and no overlapping ranges
• Cloud VPN extends a peer network into your VPC network over IPsec
• HA VPN: two interfaces, two external IP addresses, BGP through Cloud Router

Worked example (synthetic). A partner's VPC network in another organization, and the company's own data center, both need private access to one VPC network. The partner is peered; the data center connects over HA VPN.

The third consideration is joining your network to others, and the guide names two tools for two different situations. When the other network is also a virtual private cloud, or VPC, network, use VPC Network Peering: it connects two VPC networks so that resources in each can communicate, and the networks can be in the same project, different projects of the same organization, or even different organizations. It has three conditions worth memorizing. It takes both sides: the networks are connected only after each network has a peering configuration that references the other. Ranges must not collide: at the time of peering, Google Cloud checks for subnets with overlapping IP ranges, and if they exist the peering fails — which is also why you cannot peer two auto mode VPC networks. And the networks stay administratively separate. When the other network is outside Google Cloud, use Cloud VPN, a virtual private network, which securely extends your peer network to your VPC network through an encrypted internet protocol security, IPsec, connection. The high availability version, HA VPN, gets two external IP addresses, one for each interface, and is built with a pair of tunnels and border gateway protocol, or BGP, sessions, managed by a Cloud Router. Cloud VPN is not an internet exit, though: it cannot route traffic to the public internet.

HA VPN to on-premises, peering between VPC networks

Peering joins pairs of networks; it does not chain them

Figure. An on-premises network with a peer VPN gateway connects over HA VPN, two tunnels with BGP sessions, to an HA VPN gateway and Cloud Router in a VPC network named shared-services. Two further VPC networks, team-a and team-b, are each joined to shared-services by VPC Network Peering. The callout notes that peering is not transitive, so team-a and team-b do not reach each other through shared-services.

Worked example (synthetic). Team A asks why its VMs cannot reach Team B's, when both peer with the shared-services network. The answer is on the figure: two separate peerings do not make a path between them.

Drawn out, the two tools make one estate. On the left, the data center connects to the shared-services virtual private cloud, or VPC, network over high availability virtual private network, HA VPN: a pair of tunnels and border gateway protocol, or BGP, sessions, landing on an HA VPN gateway with a Cloud Router. On the right, two team networks each peer with shared-services. The figure exists for one sentence of Google's documentation: VPC Network Peering does not provide transitive routing. Team A is peered with shared-services, and Team B is peered with shared-services, but Team A and Team B are not peered with each other, so they cannot talk through the middle. If they must, they need their own peering. Where peering does connect two networks, it costs nothing in quality — peering traffic has the same latency, throughput and availability as traffic within the same VPC network. There is deliberately no firewall box on this path: firewall rules are enforced at every instance, not at a hop.

Which connection, and which kind of Cloud VPN

Match the other network, then the capacity it needs

Worked example (synthetic). A retailer trialling a migration needs a quick private link from its data center. Cloud VPN fits now; if the move succeeds and traffic grows, Interconnect is the step up.

This table is the choice as the exam poses it. If the other side is a virtual private cloud, or VPC, network, peering is the direct answer — though you can also connect two VPC networks together by connecting two Cloud VPN instances. If the other side is outside Google Cloud, it is a virtual private network, and there are two kinds. The high availability version, HA VPN, gets two external internet protocol, or IP, addresses, one for each of its interfaces, and routes dynamically with border gateway protocol, or BGP. In contrast, Classic VPN gateways have a single interface, a single external IP address, and support tunnels that use static routing. Google's product guide says when Cloud VPN fits at all: if you need a lower cost solution, have lower bandwidth needs, or are experimenting with migrating your workloads to Google Cloud. If you need an enterprise-grade connection with higher throughput, you can choose Dedicated Interconnect or Partner Interconnect instead.

Creating a peering, and an HA VPN gateway

A peering is ACTIVE only once both sides have created it

Figure. Two command panels. VPC Network Peering: gcloud compute networks peerings create with the network, peer project and peer network, run once in each network; after the second side, the state is ACTIVE in both. HA VPN: gcloud compute vpn-gateways create with the network and region, followed by a peer VPN gateway resource, a Cloud Router, a pair of tunnels and BGP sessions.

Worked example (synthetic). An engineer creates a peering from net-a to net-b and reports it done, but traffic does not flow. Nobody has created the matching configuration in net-b yet, so it is not ACTIVE.

Two commands close the topic. For virtual private cloud, or VPC, Network Peering, the command is gcloud compute networks peerings create, with a peering name, your network, the peer project and the peer network. The exam's favourite detail is that one run is not enough: your network and the other network are connected only after each network has a peering configuration that references the other, and when the second side is created the peering state changes to ACTIVE in both networks. For high availability virtual private network, or HA VPN, the first command is gcloud compute vpn-gateways create, naming the network and region. Google's setup then continues through a peer VPN gateway resource, a pair of tunnels, and border gateway protocol, or BGP, sessions, with a Cloud Router — new, or an existing one — managing the routes. A gateway with no tunnels carries nothing, just as a peering with one side carries nothing.

What this topic actually tests

Three questions to ask of any networking scenario

Is there a subnet in that region? The network is global; subnets are regional, and custom mode creates none for you. Which rule wins? Lowest priority number; with no rule, ingress is denied and egress allowed. What kind of network is on the other side? A VPC network is peered — both sides, no overlap, not transitive; anything else connects over Cloud VPN.

Close on three questions, one per objective. When a virtual machine will not deploy or cannot attach, ask whether its region has a subnet: the virtual private cloud, or VPC, network is global, subnets are regional, and a custom mode network has no subnet in a region until you create one. When traffic is blocked or allowed unexpectedly, ask which rule wins: only the matching rule with the lowest priority number applies, and with no rule at all, ingress is denied and egress is allowed. When two networks must talk, ask what the other network is. A VPC network is peered, with a configuration on both sides, no overlapping ranges, and no transitive routing through a third network. Anything outside Google Cloud connects over Cloud VPN, a virtual private network. Unit 4 manages what this topic built, and every one of these facts comes back there.

Official sources for this topic

• Associate Cloud Engineer exam guide — Section 3
• Create and manage VPC networks
• VPC networks
• Subnets
• VPC firewall rules
• VPC Network Peering
• Use VPC Network Peering
• Cloud VPN overview
• Create an HA VPN gateway to a peer VPN gateway
• Shared VPC
• Provision Shared VPC
• Use VPC firewall rules
• Firewall policies
• Choosing a Network Connectivity product