Checkpoints
Create a virtual machine in the us-east1-b zone
/ 5
Create a virtual machine in the us-central1-c zone
/ 5
Create a custom network
/ 5
Create a subnet in us-central1 region for the custom network
/ 3
Create a subnet in europe-west1 region for the custom network
/ 3
Create instances in different subnetworks of the custom network
/ 4
Customize Network Topology with Subnetworks
GSP020
Overview
In this lab, you'll learn the Compute Engine Subnetwork model. Subnetwork allows you to create your own network topology as you would in your own on-premise datacenter, so that you can assign specific IP address ranges to groups of machines.
What you'll learn
-
Differences between legacy network model and subnetwork.
-
Learn about regional subnetwork.
-
Setup custom subnetworks.
Setup and requirements
Before you click the Start Lab button
Read these instructions. Labs are timed and you cannot pause them. The timer, which starts when you click Start Lab, shows how long Google Cloud resources will be made available to you.
This hands-on lab lets you do the lab activities yourself in a real cloud environment, not in a simulation or demo environment. It does so by giving you new, temporary credentials that you use to sign in and access Google Cloud for the duration of the lab.
To complete this lab, you need:
- Access to a standard internet browser (Chrome browser recommended).
- Time to complete the lab---remember, once you start, you cannot pause a lab.
How to start your lab and sign in to the Google Cloud Console
-
Click the Start Lab button. If you need to pay for the lab, a pop-up opens for you to select your payment method. On the left is the Lab Details panel with the following:
- The Open Google Console button
- Time remaining
- The temporary credentials that you must use for this lab
- Other information, if needed, to step through this lab
-
Click Open Google Console. The lab spins up resources, and then opens another tab that shows the Sign in page.
Tip: Arrange the tabs in separate windows, side-by-side.
Note: If you see the Choose an account dialog, click Use Another Account. -
If necessary, copy the Username from the Lab Details panel and paste it into the Sign in dialog. Click Next.
-
Copy the Password from the Lab Details panel and paste it into the Welcome dialog. Click Next.
Important: You must use the credentials from the left panel. Do not use your Google Cloud Skills Boost credentials. Note: Using your own Google Cloud account for this lab may incur extra charges. -
Click through the subsequent pages:
- Accept the terms and conditions.
- Do not add recovery options or two-factor authentication (because this is a temporary account).
- Do not sign up for free trials.
After a few moments, the Cloud Console opens in this tab.
Activate Cloud Shell
Cloud Shell is a virtual machine that is loaded with development tools. It offers a persistent 5GB home directory and runs on the Google Cloud. Cloud Shell provides command-line access to your Google Cloud resources.
- Click Activate Cloud Shell
at the top of the Google Cloud console.
When you are connected, you are already authenticated, and the project is set to your PROJECT_ID. The output contains a line that declares the PROJECT_ID for this session:
gcloud is the command-line tool for Google Cloud. It comes pre-installed on Cloud Shell and supports tab-completion.
-
(Optional) You can list the active account name with this command:
-
Click Authorize.
-
Your output should now look like this:
Output:
-
(Optional) You can list the project ID with this command:
Output:
Example output:
gcloud, in Google Cloud, refer to the gcloud CLI overview guide.
-
Finally, using Cloud Shell, set the default zone and project configuration:
You can pick and choose different zones, too. Learn more about zones in the Regions & Zones documentation.
gcloud on your own machine, the config settings would've been persisted across sessions. But in Cloud Shell, you will need to set this for every new session / reconnection.
Legacy network
Traditionally in Compute Engine, you define a single network IPv4 prefix range for all the virtual machine instances attached to that network, and that network spans all Cloud Platform regions.
Each instance within a network is assigned an IPv4 address from a global network IPv4 range. Instance IP addresses are not grouped by region or zone. One IP address might appear in one region, and its neighbor might be in a different region. Any given range of IPs can be spread across all regions, and the IP addresses of instances created within a region are not necessarily contiguous.
For example, if you have virtual machine instances in two Google Cloud regions, and different zones, each of the instance will be assigned an IP address from the global pool, like this:
As a result, in the legacy network mode, you won't be able to group your instances into different logical subnetworks like you do in your on-premise networks.
Compute Engine now supports creating your own subnetworks, and it's turned on by default for new projects. Read on to learn more.
Task 1. Regional subnetworks
You can let Google Kubernetes Engine automatically create and manage subnetworks based on region. It can automatically assign a subnetwork IP prefix range to each region in your network. The instances created in a zone in a specific region in your network get assigned an IP allocated from the regional subnetwork range. This is the default mode for any new Google Cloud projects.
You can see your current network setup two ways, from the Cloud Console, or from command line.
- From the Cloud Console, click on the Navigation menu (
) on the top left of the screen:
-
Then navigate to VPC network > VPC networks.
-
In the VPC Networks page, select the tab Subnets in Current Project.
You will see that your project is already configured with automatic regional subnetworks, and there are different subnetworks created for each of the regions:
You can get the same information from the console.
-
In Cloud Shell, list existing networks:
Output:
This shows the default network with the automatic regional subnetwork mode.
-
To see the actual subnetwork ranges, run:
Output:
-
Now, create two different virtual machines, each in a different region:
Output:
Test completed task
Click Check my progress to verify your performed task. If you have completed the task successfully you will be granted with an assessment score.
-
Then run:
Output:
Test completed task
Click Check my progress to verify your performed task. If you have completed the task successfully you will be granted with an assessment score.
-
Run the following to check their IP addresses - they should belong to the same subnetwork range for the respective region that the zone belongs to:
Output:
Task 2. Custom subnetworks
Custom Subnetworks allows you to manually define subnetwork IP range for each region in your network. There can be zero, one, or several subnetwork IP ranges created per region for a network. In order to create an instance in a zone, you must have previously created at least one subnetwork in that region. At instance creation time, you will need to specify the subnetwork in the region that the instance IP should be allocated from.
-
Create a new network topology that supports custom subnetworks:
Output:
Test completed task
Click Check my progress to verify your performed task. If you have completed the task successfully you will be granted with an assessment score.
-
Next, create a custom subnet in the
us-central1region:
Output:
Test completed task
Click Check my progress to verify your performed task. If you have completed the task successfully you will be granted with an assessment score.
-
Next, create a custom subnet in the
europe-west1region:
Output:
Test completed task
Click Check my progress to verify your performed task. If you have completed the task successfully you will be granted with an assessment score.
-
You can then list all of your subnetworks:
Output:
-
Then you can create instances in the different subnetworks:
Output:
-
And another one:
Output:
Test completed task
Click Check my progress to verify your performed task. If you have completed the task successfully you will be granted with an assessment score.
Isolating subnetworks
In the automatic regional network, all virtual machine instances within a network can communicate with each other, because it automatically created firewall rules to open communication between the different regional networks. However, custom subnetworks do not have default firewall rules, so an instance in one custom subnetwork cannot reach an instance in another custom subnetwork.
To allow inter-subnetwork communication, you'll need to create firewall rules. We won't have time to go through this in this lab. But you can learn more about this advanced topic in the Subnetwork documentation.
Task 3. Test your understanding
Below are multiple-choice questions to reinforce your understanding of this lab's concepts. Answer them to the best of your abilities.
Congratulations!
You now know the basics of the default network topology as well as the ability to create your own network topology on Google Cloud! You learned:
-
The differences between legacy network model and subnetwork.
-
About regional subnetwork.
-
How to set up custom subnetworks.
Take your next lab
Try out another lab, like Application Performance Management (APM) with Stackdriver, or Orchestrating the Cloud with Kubernetes
Next steps / Learn more
Learn more about Subnetwork in the Subnetwork documentation.
Google Cloud training and certification
...helps you make the most of Google Cloud technologies. Our classes include technical skills and best practices to help you get up to speed quickly and continue your learning journey. We offer fundamental to advanced level training, with on-demand, live, and virtual options to suit your busy schedule. Certifications help you validate and prove your skill and expertise in Google Cloud technologies.
Manual Last Updated January 16, 2023
Lab Last Tested January 16, 2023
Copyright 2023 Google LLC All rights reserved. Google and the Google logo are trademarks of Google LLC. All other company and product names may be trademarks of the respective companies with which they are associated.