Partner Certification Academy

Professional Cloud Architect

pls-academy-pca-student-slides-1-2301
 The information in this presentation is classified:

Google confidential & proprietary

⚠ This presentation is shared with you under NDA.

● Do not record or take screenshots of this presentation.

● Do not share or otherwise distribute the information in this

presentation with anyone inside or outside of your organization.

Thank you!
Source Materials
Google Cloud Skills Boost for Partners
Some of this program's content has been sourced from the ● Preparing for the Professional Cloud Architect Journey
following resources: ● Essential Google Cloud Infrastructure: Foundation
● Essential Google Cloud Infrastructure: Core Services
● Google Cloud certification site
● Elastic Google Cloud Infrastructure: Scaling and
● Google Cloud documentation
Automation
● Google Cloud console
● Getting Started with Google Kubernetes Engine
● Google Cloud courses and workshops
● Google Cloud white papers ● Reliable Google Cloud Infrastructure: Design and
Process
● Google Cloud Blog
● Google Cloud YouTube channel ● Logging, Monitoring and Observability in Google Cloud
● Google Cloud samples
● Google codelabs
● Google Cloud partner-exclusive resources
● Identity Management Technical Deep Dive
● Access Management Technical Deep Dive
This material is shared with you under the terms of your
● Cloud Foundations: Cost Control Technical Deep Dive
Google Cloud Partner Non-Disclosure Agreement. [PSO Y22]
● Cloud Foundations: Networking Technical Deep Dive |
PSO | Y21
● GCP Networking Portfolio overview - LATAM (slides) |
Partners | Pre-Sales | Y20

Other sources used in the preparation of these materials

Innovating with Data and Google Cloud
Managing Security in Google Cloud
Application Development with Cloud Run
Tech Refresh Professional Cloud Architect
Architecting with Google Kubernetes Engine: Foundations
Session logistics

● When you have a question, please:

○ Click the Raise hand button in Google Meet.
○ Or add your question to the Q&A section of Google Meet.
○ Please note that answers may be deferred until the end of the session.

● These slides are available in the Student Lecture section of your Qwiklabs classroom.

● The session is not recorded.

● Google Meet does not have persistent chat.

○ If you get disconnected, you will lose the chat history.
○ Please copy any important URLs to a local text file as they appear in the chat.
Path to Service Excellence

Certification Advanced Solutions Training Delivery Readiness Index

Certification is just one step on your professional journey. Google Cloud also offers
our partners access to advanced solutions training, and a new quality-focused
program called Delivery Readiness Index (DRI) to help you achieve service
excellence with your customers.
Benchmark your skills with DRI

Assess: Partner Proficiency and Delivery Capability

Benchmark Partner individuals, project teams and practices GCP capabilities

Analyze: Individual Partner Consultants’ GCP Readiness

Showcase Partner individuals GCP knowledge, skills, and experience

Advise: Google Assurance for Partner Delivery

Packaged offerings to bridge specific capability gaps

Action: Tailored L&D Plan for Account Based Enablement

Personalized learning & development recommendations per
individual consultant

DRI helps to benchmark partner proficiency and capability at any point during
the customer journey however should be used primarily as a lead measure to
predict and prepare for partner delivery success.

DRI assesses and analyzes Partner Consultant GCP proficiency by creating a

DRI Profile inclusive of their GCP knowledge, skills, and experience.

With the DRI insights, we can prescriptively advise the partner project team on
the ground and bridge niche capability gaps.

DRI also takes action. For partner consultants, DRI generates a tailored L&D
plan that prescribes personalized learning, training, and skill development to
build GCP proficiency.
Google Cloud Skills Boost for Partners

https://partner.cloudskillsboost.google/

● On-demand course content

● Hands-on labs

● Skill Badges

● FREE to Google Cloud Partners!

 Create a login using your company email.
Your organization must verify your
● Resources for Google Cloud partner organizations: request prior to granting you access.
○ Recent announcements
○ Solutions/role-based training
○ Live/pre-recorded webinars on various topics
■ Partner Advantage Live Webinars

● Complements the certification self-study material

presented on Google Cloud Skills Boost for Partners

● Helpful Links:
○ Getting started on Partner Advantage
○ Join Partner Advantage
○ Get help accessing Partner Advantage

https://www.partneradvantage.goog

The getting started link:

https://support.google.com/googlecloud/topic/9198654#zippy=

Note the top section, “Getting Started & User Guides” and two key documents →
Direct Partners to this if they need to enroll into Partner Advantage
1. Logging in to the Partner Advantage Portal - Quick Reference Guide
2. Enrolling in the Partner Advantage Program - Quick Reference Guide

Some context on enrolling in PA:

Access to Partner Portal is given in 2 ways
● Partner Admin Led: Partner Administrator at Partner Company can set up
users
● User Led: User can go through Self Registration
○ https://www.partneradvantage.goog/GCPPRM/s/partneradvantageport
allogin?language=en_US
○ Or directly to the User Registration Form,
https://www.partneradvantage.goog/GCPPRM/s/partnerselfregistration
?language=en_US

Please Note
● After a user self-registers, they receive an email that essentially states:
○ “Hi {Partner Name}, you are one step away from joining the Google
Cloud Partner Advantage Community. Please click to continue with the
 ○ user registration process. See you in the cloud, The Partner Advantage
Team
● Once registered, they can access limited content until their Partner
Administrator approves the user
● Their Partner Administrator also receive an email notifying them that a
member of their organization has registered themselves on their organization’s
Google Cloud Partner Advantage account.
○ It also states that this user has limited access to the portal
○ They are provided instructions on how to review and provision the
appropriate access for the user that has registered
● Once their admin approves the user, they receive an email that states:
○ Hi {User Name}, Your Partner Administrator has updated your access
to the Google Cloud Partner Advantage portal. You have been granted
edit access to additional account information on the portal on behalf of
your organization to help build your business. For additional access
needs, please work with your Partner Administrator. See you in the
cloud, The Partner Advantage Team

The net takeaway is, on the Support Page (the first link on this slide) Google Cloud
Partner Advantage Support, there’s a section “Issue accessing Partner Advantage
Portal? Click here for troubleshooting steps”
● The source of their issue can be related to the different items shown
● Additionally, there’s a Partner Administrator / Partner Adminstrator Team at
their partner organization that has to approve their access.. Until that step is
completed, they will have access issues/limitation. They will need to identify
who this person or team is at their organization
Program issues or concerns?

● Problems with accessing Cloud Skills Boost for Partners

○ partner-training@google.com

● Problems with a lab (locked out, etc.)

○ support@qwiklabs.com

● Problems with accessing Partner Advantage

○ https://support.google.com/googlecloud/topic/9198654
 01
Today’s
Program Overview

02 Accessing Course Content

agenda 03 Begin module 1 technical content review

01
Program Overview
Partner Certification Academy
● Google Cloud is working with our partners to provide a differentiated learning
experience - Partner Certification Academy (PCA)

● Goal: Help you prepare for Google Cloud certification exams

○ Sessions are a review of some of the key concepts
■ These are not training sessions - that’s the purpose of the
on-demand content
■ These sessions cover topics that may appear on the exam
● But not actual exam questions

● Depending on the certification track chosen, the program consist of

○ On-demand learning
○ Mentor led Workshops
○ Hands-on labs
○ A voucher for the exam
 Google Cloud Certifications
Foundational Associate Professional
No hands-on Recommended 6+ Recommended 3+ years industry experience & 1 year hands-on experience with
experience with GC months hands-on GC
is required experience with GC

Professional Cloud Professional Cloud Professional Data Professional

DevOps Engineer Architect Engineer Machine Learning
Cloud Digital Associate Cloud
Engineer
Leader Engineer

Professional Cloud Professional Cloud Professional Cloud Professional Cloud

Developer Network Engineer Security Engineer Database
Engineer

More information: https://cloud.google.com/certification#certification_paths

Professional Cloud Architect (PCA)

https://cloud.google.com/certification/cloud-architect

What is a PCA supposed to know/do?

Professional Cloud Architect Certification Page

https://cloud.google.com/certification/cloud-architect

Professional Cloud Architect Exam Guide

https://cloud.google.com/certification/guides/professional-cloud-architect/

Professional Cloud Architect Sample Questions

https://docs.google.com/forms/d/e/1FAIpQLSdvf8Xq6m0kvyIoysdr8WZYCG32WHEN
StftiHTSdtW4ad2-0w/viewform

Google Cloud Adoption Framework + Whitepaper

https://cloud.google.com/adoption-framework
https://services.google.com/fh/files/misc/google_cloud_adoption_framework_whitepap
er.pdf
 Accessing Partner

02
Certification
Academy Content
Learning Path - Partner Certification Academy Website
Go to: https://rsvp.withgoogle.com/events/partner-learning/google-cloud-certifications

Click
Click here Professional
Cloud
Architect
Needed for
Exam
Voucher
Needed for
Exam
Voucher
Accessing PDF copies of workshop slide decks
Go to Click “Join” to create
googlecloud.qwiklabs.com a new account
Creating an account

Important: Enter your work

email address

Click “Create account”. Wait

a moment and the screen will
refresh.
 Click on the In Progress box
Shown two tabs:
● Labs
● Lecture Notes

Click the
purple box
Downloading the lecture notes Click the
download icon to
Select the download the
Lecture PDF
Notes tab

Select a
Student
Guide Book

Issues? Email: partner-training@google.com

Your Responsibilities
Welco
Workshop Day: Meet for the cohort’s weekly
me●
workshops (optional)
● During the week: Review material covered in
the week’s workshop, complete any course(s) as
needed, perform hands-on labs, review
additional suggested material.
● Any time: Reach out to your Mentor with
questions

Important: You must allocate time between each weekly session to study and familiarize yourself with any
prerequisite knowledge that will be covered in the workshops. You will not pass the exam if you don’t put in
the work.
 Experienced with AWS or Azure?
Welco
me
Speed your learning journey with:
● Google Cloud Fundamentals for Azure Professionals
● Google Cloud Fundamentals for AWS Professionals
● Compare AWS and Azure services to Google Cloud

Google Cloud Fundamentals for Azure Professionals

https://googlecourses.qwiklabs.com/course_templates/67

Google Cloud Fundamentals for AWS Professionals

https://googlecourses.qwiklabs.com/course_templates/38

Compare AWS and Azure services to Google Cloud

https://googlecourses.qwiklabs.com/course_templates/38
Additional learning resources
Welco
me
● The Cloud Girl
○ https://github.com/priyankavergadia/GCPSketchnote
● Developer Cheat Sheet
○ https://googlecloudcheatsheet.withgoogle.com/
● Google Cloud product list
○ https://cloud.google.com/terms/services
● 21 products explained in under 2 minutes
○ https://cloud.google.com/blog/topics/inside-google-cloud/21-google-clo
ud-tools-each-explained-under-2-minutes
 1. Validate access to Cloud Skills Boost for Partners

2. Un-enroll and re-enroll in the Professional Cloud Architect learning path (if
applicable)

This week’s 3. Review the exam guide to assess your own level of expertise and readiness
recommend
4. Familiarize yourself with exam Sample Questions
activities
5. Complete Module 1 content

a. Google Cloud Fundamentals - Core Infrastructure

b. Essential Google Cloud Infrastructure: Foundation

6. Begin Module 2 course (or review the content):

a. Course: Essential Google Cloud Infrastructure: Core Services

 03 Review of Course
Content

We will be reviewing different content every week.

Topics in this module
○ Machine Learning APIs
○ VPC Network
Vertex AI AutoML Cloud Cloud Cloud
■ Subnets Natural Language API Translation API Vision API

■ Firewall rules
○ Compute Engine
Virtual Private
Speech-to-Text Text-to-Speech Video Intelligence
■ Machine types API
Cloud

■ Pricing
■ Images Cloud Firewall
Cloud Routes Cloud NAT Compute Engine
Rules
■ Storage options
■ Snapshots
■ Migration Migrate for
Filestore Persistent Disk Persistent Disk Migrate to Containers
Snapshot Compute Engine
Machine learning APIs…
 Google Cloud machine learning spectrum
Vertex AI: Custom Training Vertex AI: Auto ML Pre-trained ML models (many more are available)
(via ML frameworks)
your training data + Google’s training data + Google’s models
your training data + your Google’s models
model

Vision API Speech-to- Text-to- Cloud Talent

Text API Speech API Solution API

TensorFlow Cloud TPUs

Vision
Video Intelligence
Natural language Cloud Cloud Natural Video Recommendations
Translation Translation API Language API Intelligence API
scikit-learn BigQuery ML API
Data tables

Customization Ease of Use

Build your own models Train Google’s state-of-the-art models Call Google’s APIs

Scikit-learn: machine learning in Python: https://scikit-learn.org/stable/

TensorFlow: end-to-end ML platform: https://www.tensorflow.org/
Cloud TPUs: Tensor Processing Units (TPUs) are Google's custom-developed
application-specific integrated circuits (ASICs) used to accelerate machine learning
workloads. Cloud TPUs allow you to access TPUs from Compute Engine, Google
Kubernetes Engine and AI Platform.https://cloud.google.com/tpu/docs
BigQuery ML: BigQuery ML lets you create and execute machine learning models in
BigQuery using standard SQL queries
https://cloud.google.com/bigquery-ml/docs/introduction

Different options exist when it comes to leveraging machine learning. Advanced

users, who want more control over the building and training of ML models, will use
tools that offer the levels of flexibility they are looking for. This would involve
developing custom models through an ML library like TensorFlow, that’s supported on
Cloud ML Engine, which is now a part of AI Platform. This option works for data
scientists with the skills and the need to create a TensorFlow model.

But increasingly, you don’t have to do that. Google makes the power of ML available
to you even if you have a limited knowledge of ML. You can use AutoML to build on
Google's ML capabilities to create your own custom ML models that are tailored to
specific business needs, and then integrate those models into applications and web
sites.
Alternatively, Google has a range of pre-trained ML models that are ready for
immediate use within applications in ways that the respective APIs are designed to
support. Such pretrained models are excellent ways to replace user input with ML.
 Proprietary + Confidential - DO NOT share outside of your Google Cloud partner organization

Vertex AI is Google’s comprehensive AI platform

● Contains ML tools needed to create, train, manage and
deploy machine learning models
● Includes tools for data scientists such as
○ Managed JupyterLab notebooks
○ Integration with widely used open source
frameworks such as TensorFlow, PyTorch, and
scikit-learn
● Also includes tools for non-data scientists
○ Contains pre-trained APIs for vision, video, natural
language, and more
○ Customer can add their own data to the models for
further customization

Vertex AI
https://cloud.google.com/vertex-ai
 Google Cloud machine learning spectrum
Vertex AI: Custom Training Vertex AI: Auto ML Pre-trained ML models (many more are available)
(via ML frameworks)
your training data + Google’s training data + Google’s models
your training data + your Google’s models
model

Vision API Speech-to- Text-to- Cloud Talent

Text API Speech API Solution API

TensorFlow Cloud TPUs

Vision
Video Intelligence
Natural language Cloud Cloud Natural Video Recommendations
Translation Translation API Language API Intelligence API
scikit-learn BigQuery ML API
Data tables

Customization Ease of Use

Build your own models Train Google’s state-of-the-art models Call Google’s APIs

BigQuery ML
discussed next

We will discuss BigQuery ML briefly next.

 Proprietary + Confidential - DO NOT share outside of your Google Cloud partner organization

BigQuery ML makes AI super easy

Train and deploy ML models in SQL

Execute ML workflows without

moving data from BigQuery

Automate common ML tasks

Built-in infrastructure management,

security & compliance

What is BigQuery ML?

https://cloud.google.com/bigquery-ml/docs/introduction

Without needing to move your data out of BigQuery, with BigQuery ML, you can train
and deploy machine learning models directly using SQL. That means you've got data
storage, data analytics, and machine learning all within BigQuery.
 Proprietary + Confidential - DO NOT share outside of your Google Cloud partner organization

BigQuery ML makes AI super easy

Train and deploy ML models in SQL

Execute ML workflows without

moving data from BigQuery

Automate common ML tasks

Built-in infrastructure management,

security & compliance
 Proprietary + Confidential - DO NOT share outside of your Google Cloud partner organization

BigQuery ML makes AI super easy

Train and deploy ML models in SQL

Execute ML workflows without

moving data from BigQuery

Automate common ML tasks

Built-in infrastructure management,

security & compliance
 Proprietary + Confidential - DO NOT share outside of your Google Cloud partner organization

BigQuery ML makes AI super easy

Train and deploy ML models in SQL

Execute ML workflows without

moving data from BigQuery

Automate common ML tasks

Built-in infrastructure management,

security & compliance
 Google Cloud machine learning spectrum
Vertex AI: Custom Training Vertex AI: Auto ML Pre-trained ML models (many more are available)
(via ML frameworks)
your training data + Google’s training data + Google’s models
your training data + your Google’s models
model

Vision API Speech-to- Text-to- Cloud Talent

Text API Speech API Solution API

TensorFlow Cloud TPUs

Vision
Video Intelligence
Natural language Cloud Cloud Natural Video Recommendations
Translation Translation API Language API Intelligence API
scikit-learn BigQuery ML API
Data tables

Customization Ease of Use

Build your own models Train Google’s state-of-the-art models Call Google’s APIs

Pre-trained ML models
discussed next
Use the Vision API to understand image content

Detect and label Extract text Identify entities

https://cloud.google.com/vision

Let’s start with the Vision API. There are three major components that all roll up into
this REST API, and behind-the-scenes each of these are powered by many ML
models and years of research.

The first is detecting what an image is and classifying it. The Vision API picks out the
dominant entity, for example a car or a cat, within an image from a broad set of object
categories. This allows you to easily detect broad sets of objects in your images.
Facial detection can detect when a face appears in photos, along with associated
facial features such as eye, nose and mouth placement, and likelihood of over 8
attributes like joy and sorrow. Facial recognition however, isn’t supported and Google
doesn’t store facial detection information on any Google server. You can use the API
to easily build metadata on your image catalog, enabling new scenarios like image
based searches or recommendations.

Next, are images with text, like scanned documents or signs. The Vision API uses
optical character recognition, or OCR, to extract the text of a wide range of languages
into a selectable, searchable format.

Lastly is a bit of intuition from the web and uses the power of Google Image Search.
Does the image contain entities we know, like the Eiffel tower or a famous person?
Landmark detection allows you to identify popular natural and manmade structures,
along with the associated latitude and longitude of the landmark, and logo detection
allows you to identify product logos within an image.

You can build metadata on your image catalog, extract text, moderate offensive
content, or enable new marketing scenarios through image sentiment analysis. You
can also analyze images uploaded in the request or integrate with an image storage
on Cloud Storage.
Derive insights from unstructured text with the Cloud
Natural Language API

https://cloud.google.com/natural-language

The Cloud Natural Language API offers a variety of natural language understanding
technologies. It can do syntax analysis, breaking down sentences into tokens, identify
the nouns, verbs, adjectives, and other parts of speech, and figuring out the
relationships among the words.

It can also do entity recognition, in other words, it can parse text and flag mentions of
people, organizations, locations, events, products and media.

Sentiment analysis allows you to understand customer opinions to find actionable

product and UX insights.
Dynamically translate between languages using the
Cloud Translation API

https://cloud.google.com/translate

The Cloud Translation API provides a simple programmatic interface for translating an
arbitrary string into any supported language. The Cloud Translation API is highly
responsive, so websites and applications can integrate with the API for fast, dynamic
translation of source text from the source language to a target language, for example
from French to English. Language detection is also available in cases where the
source language is unknown.
Make your media more discoverable with the
Video Intelligence API

https://cloud.google.com/video-intelligence

If you don’t know much about this API, watch this video
(https://www.youtube.com/watch?v=_IeS1m8r6SY), which is accessible from the site
above. It’s a nice overview of the capabilities.

The Video Intelligence API allows users to use Google video analysis technology as
part of their applications. The REST API enables users to annotate videos stored in
Cloud Storage with video and 1 frame-per-second contextual information. It helps you
identify key entities -- that is, nouns -- within your video, and when they occur. You
can use it to make video content searchable and discoverable.

The API supports the annotation of common video formats, including .MOV, .MPEG4,
.MP4, and .AVI.
Use the Speech-to-Text /Text-to-Speech APIs to
convert speech to text and vice versa

Text-to-Speech
Speech-to-Text

https://cloud.google.com/speech-to-text
https://cloud.google.com/text-to-speech

The Text-to-Speech API converts text into human-like speech in more than 180 voices
across more than 30 languages and variants. It applies research in speech synthesis
and Google's powerful neural networks to deliver high-fidelity audio. With this API, you
can create lifelike interactions with users that transform customer service, device
interaction, and other applications.

The Speech-to-Text API enables you to convert real-time streaming or prerecorded

audio to text. The API recognizes 120 languages and variants to support a global user
base. You can enable voice command-and-control, transcribe audio from call centers,
and so on.
 Google Cloud machine learning spectrum
Vertex AI: Custom Training Vertex AI: Auto ML Pre-trained ML models (many more are available)
(via ML frameworks)
your training data + Google’s training data + Google’s models
your training data + your Google’s models
model

Vision API Speech-to- Text-to- Cloud Talent

Text API Speech API Solution API

TensorFlow Cloud TPUs

Vision
Video Intelligence
Natural language Cloud Cloud Natural Video Recommendations
Translation Translation API Language API Intelligence API
scikit-learn BigQuery ML API
Data tables

Customization Ease of Use

Build your own models Train Google’s state-of-the-art models Call Google’s APIs

Auto ML discussed next

 Proprietary + Confidential - DO NOT share outside of your Google Cloud partner organization

Use AutoML to enhance Google’s pre-trained models

AutoML Natural Language AutoML Translation AutoML Video Intelligence

Reveal the structure and meaning Dynamically translate between Enable powerful content discovery
of text through machine learning. languages. and engaging video experiences.

AutoML Vision
Derive insights from images in
the cloud or at the edge.

AutoML
https://cloud.google.com/automl
VPC Network…
Google Cloud Network
PoPs and network

Start at this homepage: https://cloud.google.com/vpc/docs/overview

All the topics shown on the left contain good information.

What’s in a name? Understanding the Google Cloud network “edge”

https://cloud.google.com/blog/products/networking/understanding-google-cloud-netwo
rk-edge-points

According to some publicly available estimates, Google’s network carries as much as

40% of the world’s internet traffic every day. Google’s network is the largest network
of its kind on Earth. Google has invested billions of dollars over the years to build it.

It is designed to give customers the highest possible throughput and lowest possible
latencies for their applications.

The network interconnects at more than 90 Internet exchanges and more than 100
points of presence worldwide. When an Internet user sends traffic to a Google
resource, Google’s edge caching nodes respond to users requests from an Edge
Network location that will provide the lowest latency.
 VPC objects
Virtual
Private
● Projects ● IP addresses Cloud

● Networks
○ Internal, external, range
○ Default, auto mode,
● Virtual machines (VMs)
custom mode
● Subnetworks ● Routes

● Regions ● Firewall rules

● Zones

With Google Cloud, you can provision your Google Cloud resources, connect them to
each other, and isolate them from each other in a Virtual Private Cloud. You can also
define fine-grained networking policies within Google Cloud, and between Google
Cloud and on-premises or other public clouds. Essentially, VPC is a comprehensive
set of Google-managed networking objects, which we will explore in detail throughout
this module.

Here is a high-level overview of these objects:

● Projects are going to encompass every single service that you use, including
networks.
● Networks come in three different flavors: Default, auto mode, and custom
mode.
● Subnetworks allow you to divide or segregate your environment.
● Regions and zones represent Google’s data centers, and they provide
continuous data protection and high availability.
● VPC provides IP addresses for internal and external use, along with granular
IP address range selections.
As for virtual machines, in this module we will focus on configuring VM
instances from a networking perspective.
● We’ll also go over routes and firewall rules.
 VPC Network Concepts VPC Network is
Welco
A project can have
global

multiple VPC networks

me Project

Network (VPC) Regional Subnet,

Regional Subnet
e.g., europe-west1
e.g., us-central1
Region Region
Subnet is
created for a Zone a Zone b Zone c Zone a Zone b
region and
applies to all Subnet
192.168.0.0/16
zones Subnet
172.16.0.0/12
Subnet
Each subnet is 10.0.0.0/8
given CIDR IP
ranges used
for internal IPs
of VMs
Can have
additional ranges
for applications
running on VMs
Default Internet
Gateway

Nice set of Youtube videos:

https://bit.ly/34uBApk

Best practices and reference architectures for VPC design

https://cloud.google.com/architecture/best-practices-vpc-design

VPC networks
● Created within projects, which means there is no cross-project communication
by default. More on that soon.
● Global resources, for example: VM in US can communicate with a VM in
APAC
● Private RFC 1918 IP range
● Can be non RFC 1918 IP range

Subnets
● Are part of a VPC network
● Regional objects
● VMs which are zonal resources are allocated with an IP from a subnet in the
same region
● Do not provide network boundaries. VMs can communicate across subnets.
● However, default firewall rules deny traffic between VMs regardless of
subnets.
Subnet creation modes
Welco
me Default Auto Mode Custom Mode

● One subnet per region ● Default network ● Full control of subnets

● Default firewall rules ● Default /20 subnet per and IP ranges
● Experimentation region ● No default firewall rules
● Not good for ● Expandable up to /16 ● Expandable
production ● Default firewall rules ● Good for production
● Org policy to skip ● Isolated use cases ● Best Practice
(testing, PoCs)

Subnet creation mode

https://cloud.google.com/vpc/docs/vpc#subnet-ranges

Every project is provided with a default VPC network with preset subnets and firewall
rules. Specifically, a subnet is allocated for each region with non-overlapping CIDR
blocks and firewall rules that allow ingress traffic for ICMP, RDP, and SSH traffic from
anywhere, as well as ingress traffic from within the default network for all protocols
and ports.

In an auto mode network, one subnet from each region is automatically created within
it. The default network is actually an auto mode network. These automatically created
subnets use a set of predefined IP ranges with a /20 mask that can be expanded to
/16. All of these subnets fit within the 10.128.0.0/9 CIDR block. Therefore, as new
Google Cloud regions become available, new subnets in those regions are
automatically added to auto mode networks using an IP range from that block.

A custom mode network does not automatically create subnets. This type of network
provides you with complete control over its subnets and IP ranges. You decide which
subnets to create, in regions you choose, and using IP ranges you specify within the
RFC 1918 address space. These IP ranges cannot overlap between subnets of the
same network.

Now, you can convert an auto mode network to a custom mode network to take
advantage of the control that custom mode networks provide. However, this
conversion is one way, meaning that custom mode networks cannot be changed to
auto mode networks. So, carefully review the considerations for auto mode networks
to help you decide which type of network meets your needs.
VMs must have internal IP and can have external
IP addresses
Internet

Internal IP External IP
● Allocated from subnet range to ● Assigned from pool (ephemeral)
VMs by DHCP ● Alternatively, can reserve (static)
● Alternatively, can reserve (static) external IP address
internal IP address ● Bring Your Own IP address (BYOIP)

IP addresses
https://cloud.google.com/compute/docs/ip-addresses
 Proprietary + Confidential

A subnet can contain a secondary range of internal IP

addresses
● Useful when multiple services are running on a VM
and each needs its own IP address
● Also applies to GKE pods
VPC Network

VM IP: 10.1.0.2 Subnet:

Primary CIDR range 10.1.0.0/16
Secondary CIDR range 10.2.0.0/20
Container

VM alias IP range:
Routes automatically created for primary and alias IP
10.2.1.0/24
ranges for the subnet of the primary network
interface

Alias IP overview
https://cloud.google.com/vpc/docs/alias-ip
VMs can connect to multiple VPCs
Welco
● me
VMs have Multi-NIC support (8 max)
○ Each NIC must connect to a different VPC
network
○ Allows communication between VPCs using
private IPs
● Are other ways to accomplish private IP
communication between VPCs, such as
○ VPC Peering
○ VPN
○ These will be discussed later

Creating instances with multiple network interfaces

https://cloud.google.com/vpc/docs/create-use-multiple-interfaces
Networks isolate systems

● A and B can communicate over internal IPs even though they are in different regions.
● C and D must communicate over external IPs even though they are in the same region.

On this slide, we have an example of a project that contains 5 networks. All of these
networks span multiple regions across the world, as you can see on the right.

Each network contains separate virtual machines: A, B, C, and D. Because VMs A

and B are in the same network, network 1, they can communicate using their internal
IP addresses, even though they are in different regions. Essentially, your virtual
machines, even if they exist in different locations across the world, take advantage of
Google's global fiber network. Those virtual machines appear as though they're sitting
in the same rack when it comes to a network configuration protocol.

VMs C and D, however, are not in the same network. Therefore, by default, these
VMs must communicate using their external IP addresses, even though they are in
the same region. The traffic between VMs C and D isn’t actually touching the public
internet, but is going through the Google Edge routers. This has different billing and
security ramifications that we will explore later.
Routes map traffic to destination networks
●
Welco
Managed at the VPC level
●
●
me
Applies to traffic egressing a VM
Enables VMs on same network (VPC) to communicate via private IP
○ Only if it is allowed by a firewall rule
● Automatically created when a subnet is created
● Can manually create static/custom routes
○ Next hop can be: Instance IP or name, Cloud VPN, Internal TCP/UDP load balancer, default
internet gateway
● Routes can be selectively applied to
○ All instances, instances with specific network tags, instances with specific service accounts
● Internet access is enabled by a default route (priority=1000)
○ Applies to VMs with external IPs
○ No gateway or public component needed

Routes
https://cloud.google.com/vpc/docs/routes

There are 3 kinds of routes

Subnet routes
● System-generated. Added for each subnet.
● Allows routing between subnets.
● Non Removable and non overridable.
● Exchanged with VPC Peering, and by default through Cloud Router. More on
that in a later slide.
● The narrowest possible IP range, which means it cannot be overridden.

Static routes
● Considered a custom route
● Manually added by users
● Next hop can be: Instance IP or name, Cloud VPN, Internal TCP/UDP load
balancer, default internet gateway

Dynamic routes
● Considered a custom route
● Added by Cloud Router through a BGP session
● Next hop is alway the BGP peer
Unlike other cloud providers, internet access is enabled by a default route
(priority=1000). No gateway or public component is needed.
● It doesn’t mean all VM’s have internet access. an external IP on VM’s is
needed for public Internet access.
● Removable with caveats
○ A public internet route to destination of Google API’s is needed for
Private Google Access
○ Cloud CDN requires the default internet route
VPC Firewall rules protect your VM instances from
Welco
unapproved connections
me
● VPC network functions as a distributed firewall. ● Consist of:

● Firewall rules are applied to the network as a ○ Direction (ingress/egress)

whole ○ Action (allow/deny)

● Connections are allowed or denied at the ○ Source OR destination

instance level ○ ports/protocol, priority

● Firewall rules are stateful ● Implied rules:

○ deny all ingress
○ allow all egress
○ Have lowest priority

VPC Firewall rules

https://cloud.google.com/vpc/docs/firewalls

3 ways to configure robust firewall rules:

https://cloud.google.com/blog/products/gcp/three-ways-to-configure-robust-firewall-rul
es

Google Cloud firewall rules protect your virtual machine instances from unapproved
connections, both inbound and outbound, known as ingress and egress, respectively.
Essentially, every VPC network functions as a distributed firewall.

Google Cloud firewall rules provide effective protection and traffic control regardless
of the operating system your instances use. Google Cloud firewall rules are defined
for the VPC network as a whole, and since VPC networks can be global in Google
Cloud, firewall rules are also global.

Although firewall rules are applied to the network as a whole, connections are allowed
or denied at the instance level. You can think of the firewall as existing not only
between your instances and other networks, but between individual instances within
the same network.

Google Cloud firewall rules are stateful. This means that if a connection is allowed
between a source and a target or a target and a destination, all subsequent traffic in
either direction will be allowed. In other words, firewall rules allow bidirectional
communication once a session is established.
Also, if for some reason, all firewall rules in a network are deleted, there is still an
implied "Deny all" ingress rule and an implied "Allow all" egress rule for the network.
 Creating Firewall Rules
● When creating rules, specify
○ Source
■ Could be the internet (0.0.0.0/0 IP range)
■ Individual or ranges of IPv4 or IPv6
addresses
■ Could be VMs with specific network tags or
Will revisit the
last 2 after the service accounts
service ○ Target - Defines which VMs the rule applies to
account ■ All instances in the network
discussion ■ VMs with specific network tags
■ VM’s with service accounts
 All VPCs have implied firewall rules
Implied IPv4/IPv6 firewall rules are present in all VPC networks

● Implied allow egress rule

○ Lets any instance send traffic to any destination
● Implied deny ingress rule
○ Protects all instances by blocking incoming connections to them

● Override them with your own firewall rules (if desired)

Implied IPv4 firewall rules are present in all VPC networks, regardless of how the
networks are created, and whether they are auto mode or custom mode VPC
networks. The default network has the same implied rules.

● Implied IPv4 allow egress rule. An egress rule whose action is allow,
destination is 0.0.0.0/0, and priority is the lowest possible (65535) lets any
instance send traffic to any destination, except for traffic blocked by Google
Cloud.

● Implied IPv4 deny ingress rule. An ingress rule whose action is deny, source
is 0.0.0.0/0, and priority is the lowest possible (65535) protects all instances by
blocking incoming connections to them. A higher priority rule might allow
incoming access.

If IPv6 is enabled, the VPC network also has these two implied rules:

● Implied IPv6 allow egress rule. An egress rule whose action is allow,
destination is ::/0, and priority is the lowest possible (65535) lets any instance
send traffic to any destination, except for traffic blocked by Google Cloud. A
higher priority firewall rule may restrict outbound access. Internet access is
allowed if no other firewall rules deny outbound traffic and if the instance has
an external IP address.

● Implied IPv6 deny ingress rule. An ingress rule whose action is deny, source
 ● is ::/0, and priority is the lowest possible (65535) protects all instances by
blocking incoming connections to them. A higher priority rule might allow
incoming access.

The implied rules cannot be removed, but they have the lowest possible priorities.

For more information on implied rules check out the link in the speaker notes.
● Link: cloud.google.com/vpc/docs/firewalls#default_firewall_rules
 Default VPCs have additional allow rules

Rule Description

Allows ingress connections for all protocols and ports

default-allow-internal
among instances within the VPC network

default-allow-ssh Allows port 22 - secure shell (ssh) access

default-allow-rdp Allows port 3389 - remote desktop protocol (RDP) access

default-allow-icmp Allows ICMP traffic

In Google Cloud, all projects get a default VPC created automatically. In addition to
the implied rules, the default VPC network is pre-populated with firewall rules that
allow incoming, or ingress, traffic to instances.The first rule is default-allow-internal
which allows ingress connections for all protocols and ports among instances within
the VPC network. It effectively permits incoming connections to VM instances from
others in the same network.

The other three rules in the default network are default-allow-ssh, default-allow-rdp
and default-allow-icmp.These rules allow port 22 - secure shell (ssh), port 3389 -
remote desktop protocol (RDP), and ICMP traffic respectively, from any source IP
address to any instance in the VPC network.

All of these rules have the second-to-lowest priority of 65534.

As you may have noticed some of these rules can be a little dangerous. These rules
can (and should) be deleted or modified as necessary.
 Hierarchical firewall policies Hierarchical firewall policies
VPC firewall rules

Ingress from 1.1.1.10/24 priority 1

My-Org go to_next

Ingress tcp:80,443 priority 1 Ingress any:any priority 2

allow deny

Ingress any:any priority 2 my-folder1 my-folder2

deny

project_1 project_2 Ingress tcp:80,443,22 priority 1000

allow
Default ingress deny all
Default ingress deny all
Default egress allow all
vpc1 vpc2 Default egress allow all

Managing cloud firewalls at scale with new Hierarchical Firewall Policies

https://cloud.google.com/blog/products/identity-security/new-google-cloud-hierarchical
-firewall-policies

Hierarchical firewall policies let you create and enforce a consistent firewall policy
across your organization. You can assign hierarchical firewall policies to the
organization as a whole or to individual folders. These policies contain rules that can
explicitly deny or allow connections, as do Virtual Private Cloud (VPC) firewall rules.
In addition, hierarchical firewall policy rules can delegate evaluation to lower-level
policies or VPC network firewall rules with a goto_next action. Lower-level rules
cannot override a rule from a higher place in the resource hierarchy. This lets
organization-wide admins manage critical firewall rules in one place.

By default, all hierarchical firewall policy rules apply to all VMs in all projects under the
organization or folder where the policy is associated. However, you can restrict which
VMs get a given rule by specifying a target network or target service account. The
levels of the hierarchy at which firewall rules can now be applied are represented in
the diagram, shown here. The yellow boxes near the top represent hierarchical
firewall policies, while the blue boxes at the bottom represent VPC firewall rules.
Network pricing (subject to change)
Traffic type Price

Ingress No charge

Egress to the same zone (internal IP address) No charge

Egress to Google products (YouTube, Maps, Drive) No charge

Egress to a different Google Cloud service (within same region; exceptions) No charge

Egress between zones in the same region (per GB) $0.01

Egress to the same zone (external IP address, per GB) $0.01

Egress between regions within the US and Canada (per GB) $0.01

Egress between regions, not including traffic between US regions Varies by region

This table is from the Compute Engine documentation, and it lists the price of each
traffic type.

First of all, ingress or traffic coming into Google Cloud’s network is not charged,
unless there is a resource such as a load balancer that is processing ingress traffic.
Responses to requests count as egress and are charged.

The rest of this table lists egress or traffic leaving a virtual machine. Egress traffic to
the same zone is not charged, as long as that egress is through the internal IP
address of an instance. Also, egress traffic to Google products, like YouTube, Maps,
Drive, or traffic to a different Google Cloud service within the same region is not
charged for.

However, there is a charge for egress between zones in the same region, egress
within a zone if the traffic is through the external IP address of an instance, and
egress between regions.

As for the difference in egress traffic to the same zone, Compute Engine cannot
determine the zone of a virtual machine through the external IP address. Therefore,
this traffic is treated like egress between zones in the same region.
Also, there are some exceptions, and pricing can always change, so please refer to
the documentation page.
 Bring your own IP (BYOIP)

Bring your own IP (BYOIP) lets you provision and use your own public IPv4 addresses for
Google Cloud resources.

After the IP addresses are imported, Google Cloud manages them in the same way as
Google-provided IP addresses, with these exceptions:

● The IP addresses are available only to the customer who imported them
● There are no charges for idle or in-use IP addresses.

Bring your own IP

https://cloud.google.com/vpc/docs/bring-your-own-ip
Summary - VPC Networks
● One VPC Network must exist prior to creating a VM
○ When VMs are created, they must be assigned to a network
● A default network is created when the Compute Engine API is enabled
○ Contains a subnet for every region of Google Cloud
● Upon creation a VM is assigned an internal IP from the CIDR range assigned to the subnet in
which the VM was created
○ Can optionally be given a external IP address (ephemeral or status)
● VMs on same network communicate via internal IPs
● VMs in different networks must communicate via external IPs
○ Unless
■ VPC Peering is enabled (discussed later)
■ VMs have multiple NICs
● To prevent access to a machine from outside its network don't give it an external IP
Cloud NAT provides internet access to private instances

(NAT Gateway)

Cloud NAT overview

https://cloud.google.com/nat/docs/overview

As a general security best practice, we recommend using only assigning internal IP

addresses to your VM instances wherever 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.
Suggested lab: Multiple VPC Networks (if time allows)

Creates custom network,

firewall rules, VM instances
w/multiple network interfaces
(NIC)

https://partner.cloudskillsboost.google/catalog_lab/1031

https://partner.cloudskillsboost.google/catalog_lab/1031
 VPC peering
Welco
● VMs in different VPC networks cannot communicate over private IPs by default
me
● VPC Peering connects two VPC Networks
○ As long as there are no overlapping subnet IP ranges
○ Networks can be in the same project, different projects or different
organizations
● Traffic latency within a peering group is the same as if they were the same VPC
network

Network Network
Subnet Subnet
10.0.0.0/9 10.128.0.0/9

Subnet Subnet
192.168.0.128/25 192.168.0.0/25

VPC Network Peering overview:

https://cloud.google.com/vpc/docs/vpc-peering

Using VPC Network Peering:

https://cloud.google.com/vpc/docs/using-vpc-peering
VPC peering
Organization node Organization node
example.com SaaS.com

VPC Consumer Network VPC Producer Network

Consumer Instance Producer Instance

Consumer Admin Admin Producer
Network Admin Network Admin

Private IP
Project customer-prod Project service-prod

Client Serving Instance

Compute Engine Compute Engine

VPC Network Peering allows private RFC 1918 connectivity across two VPC
networks, regardless of whether they belong to the same project or the same
organization.

Now, remember that each VPC network will have firewall rules that define what traffic
is allowed or denied between the networks.

For example, in this diagram there are two organizations that represent a consumer
and a producer, respectively. Each organization has its own organization node, VPC
network, VM instances, Network Admin and Instance Admin. In order for VPC
Network Peering to be established successfully, the Producer Network Admin needs
to peer the Producer Network with the Consumer Network, and the Consumer
Network Admin needs to peer the Consumer Network with the Producer Network.
When both peering connections are created, the VPC Network Peering session
becomes Active and routes are exchanged This allows the VM instances to
communicate privately, using their internal IP addresses.

VPC Network Peering is a decentralized or distributed approach to multi-project

networking, because each VPC network may remain under the control of separate
administrator groups and maintains its own global firewall and routing tables.
Historically, such projects would consider external IP addresses or VPNs to facilitate
private communication between VPC networks. However, VPC Network Peering does
not incur the network latency, security, and cost drawbacks that are present when
using external IP addresses or VPNs.
VPC peering benefits
Welco
● me
Reduce latency
○ Connecting via private IPs will have lower latency than public IPs
● Reduce costs
○ Google Cloud charges egress bandwidth when using public IPs to communicate
○ Peering communication is via private IPs
● Improve Security
○ VMs may no longer require public access
 Suggested Lab (if time allows)

https://partner.cloudskillsboost.google/catalog_lab/935

Lab: VPC Network Peering

https://partner.cloudskillsboost.google/catalog_lab/935
Creating one VPC network for use by multiple
projects…
 A Shared VPC is created in one project, but can be
shared and used by other projects
Networking specialists Allows centralized control over network
● Create the VPC in the host project. configuration
● Shares the VPC with other service ● Network admins configure subnets,
projects. firewall rules, routes, etc.
● Remove network admin rights from
developers.
● Developers focus on machine creation
and configuration in the shared
network.
● Disable the creation of the default
network using an organizational policy.

Shared VPC overview

https://cloud.google.com/vpc/docs/shared-vpc

Shared VPC
allows an organization to connect resources from multiple projects to a common VPC
network so that they can communicate with each other securely and efficiently using
internal IPs from that network. When you use Shared VPC, you designate a project as
a host project and attach one or more other service projects to it. The VPC networks
in the host project are called Shared VPC networks. Eligible resources from service
projects can use subnets in the Shared VPC network. Eligible resources include
Compute Engine resources, GKE clusters, and App Engine flexible instances.

More details of eligible resources can be found here:

https://cloud.google.com/vpc/docs/shared-vpc#resources_that_can_be_attached_to_
shared_vpc_networks_from_a_service_project

Shared VPC lets organization administrators delegate administrative responsibilities,

such as creating and managing instances, to Service Project Admins while
maintaining centralized control over network resources like subnets, routes, and
firewalls. This model allows organizations to do the following:

1. Implement the security best practice of least privilege for network admin,
auditing, and access control. Shared VPC admins delegate admin tasks to
admins in the shared network without allowing service project admins to make
1. network-affecting changes. They can only create and manage instances that
use the shared VPC.
2. Apply and enforce consistent access control policies at the network level for
multiple service projects.
Shared VPC

In this diagram, the Shared VPC Admin configured the Web Application Project to be
a host project with subnet-level permissions. Doing so allowed the Shared VPC
Admin to selectively share subnets from the VPC network.

Next, the Shared VPC Admin attached the three service projects to the host project
and gave each project owner the Network User role for the corresponding subnets.
Each project owner then created VM instances from their service projects in the
shared subnets. By the way, billing for those VM instances is attributed to the project
where the resources are created, which are the service projects.

Shared VPC Admins have full control over the resources in the host project, including
administration of the shared VPC network. They can optionally delegate the Network
Admin and Security Admin roles for the host project. Overall, shared VPC is a
centralized approach to multi-project networking because security and network policy
occurs in a single designated VPC network.

For a demo on how to create VM instances in a Shared VPC network, please refer
here:
https://storage.googleapis.com/cloud-training/gcpnet/student/M3_Demo_SharedVPC.
mp4
 Shared VPC vs. VPC peering

Consideration Shared VPC VPC Network Peering

Across Organizations No Yes

Within Project No Yes

Network Administration Centralized Decentralized

Now, that we’ve talked about Shared VPC and VPC Network Peering, let’s compare
both of these configurations to help you decide which is appropriate for a given
situation.

If you want to configure private communication between VPC networks in different

organizations, you have to use VPC Network Peering. Shared VPC only works within
the same organization.

Somewhat similarly, if you want to configure private communication between VPC

networks in the same project, you have to use VPC Network Peering. This doesn’t
mean that the networks need to be in the same project, but they can be, as you will
explore in the upcoming lab. Shared VPC only works across projects.
Google Cloud VPC - Youtube Videos

Covers many of the same

topics mentioned here
today

Youtube videos covering VPC topics

https://bit.ly/34uBApk
Compute Engine…
Compute Engine
Welco
me
Virtual machines on Google’s infrastructure

● Predefined machine types: Pre-built and ready-to-go configurations

● Custom machine types: Create VMs with optimal amounts of vCPU (cores) and memory
(RAM), while balancing cost
● Spot machines and preemptible virtual machines: Reduce computing costs
● Confidential computing: Encrypt your most sensitive data while it’s being processed
● Rightsizing recommendations: Optimize resource utilization with automatic
recommendations
● Per second billing
Compute Engine Machine Types
Welco
me

Tip: More detail and use cases found here: https://cloud.google.com/compute#section-6

Choosing the right VM type

https://cloud.google.com/compute#section-6
TauWelcome
VMs - Scale-out Optimized Machine Types
Ideal for scale-out
workloads:

● Web servers
● Containerized
microservices
● Data-logging
processing
● Media transcoding
● Large-scale Java
applications

Tau VMs ideal for scale-out workloads including web servers, containerized
microservices, data-logging processing, media transcoding, and large-scale Java
applications.
Compute
WelcomeOptimized Machine Types
Memory Optimized Machine Types
Welcome
Accelerator
WelcomeOptimized Machine Types

CUDA:
Nvidia calls its parallel processing platform CUDA. CUDA Cores are the processing
units inside a GPU just like AMD’s Stream Processors.

CUDA is an abbreviation for Compute Unified Device Architecture. It is a name given

to the parallel processing platform and API which is used to access the Nvidia GPUs
instruction set directly.
 Welco
Custom Machine Types
me
● Specify number of vCPU cores
the memory
● Optimize resources
● Manage costs

A machine type specifies a particular collection of virtualized hardware resources

available to a VM instance, including the system memory size, vCPU count, and
maximum persistent disk capability.

Predefined machine types:

● Have a fixed collection of resources, are managed by Compute Engine and
are available in multiple different classes.
● Each class has a predefined ratio of GB of memory per vCPU

Custom machine types:

● These let you specify the number of vCPUs and the amount of memory for
your instance.
Shielded VMs offer verifiable integrity
VMs include a set of security controls that ensures your instances
haven't been compromised by boot- or kernel-level malware or rootkits.

Helps Protect Against:

● Remote Attacks
● Privilege escalation
● Malicious insiders
Includes
● Secure Boot – prevents boot- or kernel-level rootkits by only
allowing components signed by Google
● Integrity Monitoring – discover and act on changes in boot and
kernel components across restarts
● vTPM – exposed to host OS for applications to use to project
secrets, but also a requirement for Integrity Monitoring

Shielded VMs
 Confidential Computing w/Confidential VMs

● A breakthrough technology that encrypts

sensitive data while it’s being processed
○ Data is encrypted/decrypted only on
CPU chp
● No code changes needed to applications
○ Any existing workload can run as a
Confidential VM.
● Uses a Shielded VM to perform
computations
● Leverages AMD SEV powered by 2nd Gen
ADM EPYC processors

Confidential Computing

Google Cloud encrypts data at-rest and in-transit, but customer data must be
decrypted for processing. Confidential Computing is a breakthrough technology which
encrypts data in-use—while it is being processed. Confidential Computing
environments keep data encrypted in memory and elsewhere outside the central
processing unit (CPU).
Sole Tenant Nodes
● A physical Compute Engine server that is
dedicated to hosting only your project's VMs
● Use cases
○ Meet security or compliance requirements
with workloads that require physical isolation
from other workloads or VMs
○ Meet dedicated hardware requirements for
bring your own license (BYOL) scenarios that
require per-core or per-processor licenses

Sole Tenant Nodes

 Bare Metal Solution for Specialized Workloads
Provides hardware to run specialized workloads with low latency
Tool set to help onboard your
environment

Provision applications, relational

databases, operating systems and
services such as backups and
monitoring

Bare Metal

Bare Metal Solution overview

https://cloud.google.com/bare-metal/docs/bms-overview

With Bare Metal Solution, you can bring your specialized workloads to Google Cloud,
allowing you access and integrate with GCP services with minimal latency.
Bare Metal Solution is a managed solution that provides purpose-built HPE or Atos
bare-metal servers in regional extensions that are connected to Google Cloud by a
managed, high-performance connection with a low-latency network fabric.

With Bare Metal Solution, Google Cloud provides and manages the core
infrastructure, the network, the physical and network security, and hardware
monitoring capabilities in an environment from which you can access all of the Google
Cloud services. The core infrastructure includes secure, controlled-environment
facilities, and power.

The Bare Metal Solution also includes the provisioning and maintenance of the
custom, sole-tenancy hardware with local SAN, and smart hands support.

The network, which is managed by Google Cloud includes a low-latency Cloud

Interconnect connection into the customer Bare Metal Solution environment.
Bare Metal Solution: Enabling specialized workloads in Google Cloud (Nov 20,
2019)
https://cloud.google.com/blog/products/compute/bare-metal-solution-enabling-speciali
zed-workloads-in-google-cloud

This is why we’re excited to introduce Bare Metal Solution: to jumpstart the migration
of applications that have been holding back your cloud adoption.

Bare Metal Solution consists of all the infrastructure you need to run your specialized
workload such as Oracle Database close to Google Cloud. This infrastructure is
connected with a dedicated, low-latency and highly resilient interconnect, and
connects to all native Google Cloud services. Bare Metal Solution uses OEM
hardware that is certified to run multiple enterprise applications, most of which can be
migrated to this infrastructure with little or no change, minimizing the risk of migration
while simultaneously increasing its velocity.

Bare Metal Solution also comes with automation tools to help you onboard your
environment quickly—provisioning your applications, relational databases, configuring
popular operating systems and setting up services such as backups and monitoring.
The management interface will be familiar to your existing IT teams or systems
integrator, allowing you to leverage your investments in existing tools, processes and
personnel.
 VMware Engine: VMware-as-a-Service

Google Cloud VMware Engine

https://cloud.google.com/vmware-engine
Rightsizing recommendations
Welco
●
●
me
Help optimize the resource utilization of VMs
Generated automatically based on system
metrics gathered by the Cloud Monitoring
service over the previous 8 days.
● Suggests resizing instance's machine type to
more efficiently use the instance's resources.
○ Avoid paying for idle and oversized
resources
● Recommendations are free of charge.

Applying Machine Type Recommendations

https://cloud.google.com/compute/docs/instances/apply-machine-type-recommendati
ons-for-instances

● Compute Engine provides machine type recommendations to help you

optimize the resource utilization of your virtual machine (VM) instances.
● These recommendations are generated automatically based on system
metrics gathered by the Cloud Monitoring service over the previous 8 days.
● Use these recommendations to resize your instance's machine type to more
efficiently use the instance's resources. This feature is also known as
rightsizing recommendations.

Note: You might have valid reasons for running a particular instance at very low or
very high utilization. Machine type recommendations are suggestions to help you
more efficiently use your instances, but they might not be appropriate for every
situation.
 Preemptible and Spot VMs
● A highly discounted VM compared to the price of standard VMs
○ Discount of 60-91% discount
○ Availability depends on having excess compute capacity in a zone
■ May or may not have availability in a given zone at a given time
■ Will have to try another zone or wait for the resource to be available
● Compute Engine might stop preemptible/spot instances at any time due to system
events
○ Preemptible VMs - always stopped after they run for 24 hours.
■ May be stopped before the 24 hour time period
■ When restarted, the 24 hour clock resets
○ Spot VMs - stopped/deleted when Google needs the resource elsewhere
■ Spot VMs are the latest version of preemptible VMs
■ Can specify termination or deletion when creating the VM

Preemptible VM instances
https://cloud.google.com/compute/docs/instances/preemptible

Spot VMs
https://cloud.google.com/spot-vms
https://cloud.google.com/compute/docs/instances/spot
Preemptible/Spot VMs - additional details
● Offer the same machine types, options, and performance as regular compute instances
● Use cases
○ Stateless and scalable workloads that can be stopped and checkpointed in less
than 30 seconds, or is location and hardware flexible
● Provides no live migration or automatic restart during maintenance events
● Not covered by Service Level Agreement due to the preceding limitations,
● No free tier

Tip: Look through all the links in Top 5 use cases for Google Cloud Spot VMs explained + best
practices
Compute Engine Pricing
Welco
●
me
Based on per-second usage of:
○ Machine types
○ Persistent disks
○ Other resources you select for your VMs
● Estimate cost with with Google Cloud Pricing Calculator
● Manage Costs with:
○ Sustained use discounts
○ Committed Use Discounts (CUDs)
○ Preemptible VMs
○ Spot VMs

Pricing for Compute Engine is based on per-second usage of the machine types,
persistent disks, and other resources that you select for your virtual machines.
● You pay only for the compute time that you use.
● If you have a specific project in mind, use the pricing calculator to estimate
cost.

Sustained Use Discounts

https://cloud.google.com/compute/docs/sustained-use-discounts

Automatic discounts for running specific Compute Engine resources a significant

portion of the billing month. Sustained use discounts apply to the following resources:
● The vCPUs and memory for general-purpose custom and predefined machine
types
● The vCPUs and memory for compute-optimized machine types
● The vCPUs and memory for memory-optimized machine types
● The vCPUs and memory for sole-tenant nodes
● The 10% premium cost for sole-tenant nodes, even if the vCPUs and memory
in those nodes are covered by committed use discounts
● GPU devices

Committed Use Discounts

Compute Engine lets you purchase and renew committed use discounts in return for
deeply discounted prices for VM usage. These discounts are referred to as
resource-based committed use discounts.
● Committed use discounts are ideal for workloads with predictable resource
needs.
● When you purchase a committed use contract, you purchase Compute Engine
resources—such as vCPUs, memory, GPUs, local SSDs, and sole-tenant
nodes—at a discounted price in return for committing to paying for those
resources for 1 year or 3 years.

Premptible VMs

Preemptible VM instances are available at much lower price—a 60-91%

discount—compared to the price of standard VMs. However, Compute Engine might
stop (preempt) these instances if it needs to reclaim those resources for other tasks.
Preemptible instances are excess Compute Engine capacity, so their availability
varies with usage.

If your apps are fault-tolerant and can withstand possible instance preemptions, then
preemptible instances can reduce your Compute Engine costs significantly. For
example, batch processing jobs can run on preemptible instances. If some of those
instances stop during processing, the job slows but does not completely stop.
Preemptible instances complete your batch processing tasks without placing
additional workload on your existing instances and without requiring you to pay full
price for additional normal instances.

Spot VMs

Spot VMs are the latest version of preemptible VMs. To learn more about VMs in
general, read the Virtual machine instances documentation.

Compute Engine Pricing

https://cloud.google.com/compute/all-pricing
Compute Engine Images…
 Images
● Public base images*
○ Google, third-party vendors, and community; Premium images (p)
○ Linux
■ CentOS, CoreOS, Debian, RHEL(p), SUSE(p), Ubuntu, openSUSE, and
FreeBSD
○ Windows
■ Windows Server 2022(p), 2019(p), 2016(p), 2012-r2(p) and more
■ SQL Server pre-installed on Windows(p)
● Custom images
○ Create new image from VM: pre-configured and installed SW
○ Import from on-prem, workstation, or another cloud
○ Management features: image sharing, image family, deprecation

*Check the website for an updated list of public images

Images
https://cloud.google.com/compute/docs/images

You can select either a public or custom image.

You can choose from both Linux and Windows images. Some of these images are
premium images, as indicated in parentheses with a p. These images will have
per-second charges after a 1-minute minimum, with the exception of SQL Server
images, which are charged per minute after a 10-minute minimum. Premium image
prices vary with the machine type. However, these prices are global and do not vary
by region or zone.

You can also use custom images. For example, you can create and use a custom
image by pre-installing software that's been authorized for your particular
organization.

You also have the option of importing images from your on-premises or workstation,
or from another cloud provider. This is a no-cost service that is as simple as installing
an agent, and we highly recommend that you look at it. You can also share custom
images with anybody in your project or among other projects, too.
Compute Engine Storage Options…
 Compute Engine Data Storage
● Each VM has a boot persistent disk (PD) that contains the
operating system
○ Not best practice to place non-system data on the boot
disk
● When apps require additional storage space add one or
more additional storage options
○ Cloud Storage buckets: Affordable object storage
○ Additional persistent disk(s): Efficient, reliable block
storage.
○ Local SSD: High performance, transient, local block
storage.
○ Filestore: High performance file storage for Google
Cloud users.
 Compute Engine Data Storage
● Each VM has a boot persistent disk (PD) that
contains the operating system
○ Not best practice to place non-system data
on the boot disk
● When apps require additional storage space
add one or more additional storage options
○ Cloud Storage buckets: Affordable object
storage
○ Additional persistent disk(s): Efficient,
reliable block storage.
○ Local SSD: High performance, transient,
local block storage.
○ Filestore: High performance file storage for
Google Cloud users.
Next
discussion
 Persistent Disk

A Google Cloud block storage options cheat sheet

A Google Cloud block storage options cheat sheet

https://cloud.google.com/blog/topics/developers-practitioners/google-cloud-block-stor
age-options-cheat-sheet
Persistent Disk Types
● Standard persistent disks (pd-standard)
○ Standard hard disk drives (HDD)
● SSD persistent disks (pd-ssd)
○ Backed by solid-state drives
● Balanced persistent disks (pd-balanced)
○ Solid-state drives (SSD) that balance performance and cost
■ Faster than Standard, less expensive than SSD
● Extreme persistent disks (pd-extreme)
○ Solid-state drives designed for high-end database workloads
○ Provides high performance for both random access workloads and bulk throughput
○ Available for high performance machine types
Data written to
● Local SSD (ephemeral storage) Local SSDs is not
○ Always-encrypted local solid-state drive (SSD) guaranteed to
○ Multiple disks can be attached to a VM for a total of 9TB persist between VM
restarts

Link to disk types: https://cloud.google.com/compute/docs/disks#disk-types

Link to extreme disk:
https://cloud.google.com/compute/docs/disks/extreme-persistent-disk
Local ssd: https://cloud.google.com/compute/docs/disks/local-ssd

The first disk that we create is what we call a persistent disk. That means it's going to
be attached to the VM through the network interface. Even though it's persistent, it's
not physically attached to the machine. This separation of disk and compute allows
the disk to survive if the VM terminates. You can also perform snapshots of these
disks, which are incremental backups that we’ll discuss later.

The choice between HDD and SSD disks comes down to cost and performance. To
learn more about disk performance and how it scales with disk size, please refer to
the documentation page.

Another cool feature of persistent disks is that you can dynamically resize them, even
while they are running and attached to a VM.

You can also attach a disk in read-only mode to multiple VMs. This allows you to
share static data between multiple instances, which is cheaper than replicating your
data to unique disks for individual instances.
Zonal persistent disks offer efficient, reliable block storage. Regional persistent disks
provide active-active disk replication across two zones in the same region. Regional
persistent disks deliver durable storage that is synchronously replicated across zones
and are a great option for high-performance databases and enterprise applications
that also require high availability. When you configure a zonal or regional persistent
disk, you can select one of the following disk types.

● Standard persistent disks (pd-standard). These types of disks are back by

standard hard disk drives (HDD).
● Balanced persistent disks (pd-balanced). These types of disks are backed by
solid state drives (SSD). They are an alternative to SSD persistent disks that
balance performance and cost.
● SSD persistent disks (pd-ssd). These types of disks are backed by by solid
state drives (SSD).

By default, Compute Engine encrypts all data at rest. Google Cloud handles and
manages this encryption for you without any additional actions on your part. However,
if you wanted to control and manage this encryption yourself, you can either use
Cloud Key Management Service to create and manage key encryption keys (which is
known as customer-managed encryption keys) or create and manage your own key
encryption keys (known as customer-supplied encryption keys).
Adding disks to VMs with the Console

Must format
a blank disk
after creation

Formatting and mounting a non-boot disk on a Linux VM

https://cloud.google.com/compute/docs/disks/add-persistent-disk#format_and_mount
_linux

Formatting and mounting a non-boot disk on a Windows VM

https://cloud.google.com/compute/docs/disks/add-persistent-disk#format_and_mount
_windows
 Regional disks provide high availability

● Synchronously replicate of data between two zones in a region

● In the event of a zonal outage where VM instance becomes unavailable
○ Spin up a VM in the secondary zone and force attach the disk
■ Time to recover = time to create VM (several minutes) + time to force
attach disk (~1 minute)

gcloud compute instances attach-disk myvm2 \

--disk data-disk --disk-scope=regional \
--force-attach

High availability options using regional PDs

https://cloud.google.com/compute/docs/disks/high-availability-regional-persistent-disk
Summary: Persistent Disk Options
Network storage appearing as a block ● Disk resizing: even running and attached!
device ● Can be attached in read-only mode to
● Attached to a VM through the network multiple VMs
interface ● Local SSD available for fast caching
● Durable storage: can survive VM ● Zonal or Regional
terminate
● Encrypted by Google by default
● Bootable: you can attach to a VM and
○ Customers can do their own encryption
boot from it
using
● Snapshots: incremental backups
■ Customer managed encryption keys
● Performance: Scales with size
■ Customer supplied encryption keys
 Compute Engine Data Storage
● Each VM has a boot persistent disk (PD) that
contains the operating system
○ Not best practice to place non-system data
on the boot disk
● When apps require additional storage space
add one or more additional storage options
○ Cloud Storage buckets: Affordable object
storage
○ Additional persistent disk(s): Efficient,
reliable block storage.
○ Local SSD: High performance, transient,
local block storage.
○ Filestore: High performance file storage for
Google Cloud users.
Different Next
module discussion
 What is Filestore?
● Cloud-based managed file storage service for the Unix file system (POSIX)
● Provides native experience for standing up Network Attached Storage
(NAS) for Compute Engine and Kubernetes Engine
● High-performance, fully managed network attached storage
○ Mount as file shares on Compute Engine instances
○ Used to store and serve files such as documents, images, videos, audio
files, and other data
● Pay for what you use YouTube video:
● Capacity scales automatically scale based on demand https://www.youtube.
● Use cases: com/watch?v=CUwp
XqEitA0
○ Enterprise application migrations (SAP)
○ Media rendering where file shares are needed
○ Web content management

Filestore
https://cloud.google.com/filestore
Filestore use cases

Announcing Filestore Enterprise, for your most demanding apps (2021)

 Filestore example - SAP NetWeaver

SAP NetWeaver
application tier
requires shared files
across many VMs

SAP database tier on

Regional Disks for HA

Announcing Filestore Enterprise, for your most demanding apps (2021)

Announcing Filestore Enterprise, for your most demanding apps(2021)

https://cloud.google.com/blog/products/storage-data-transfer/google-cloud-announces
-filestore-enterprise-for-business-critical-apps

Note that this blog is from 2021, and the “public preview” items mentioned in the blog
are now generally available (GA)
Compute Engine Disk Snapshots
 Snapshots

● Are incremental backups of data from

persistent disks
○ No need to stop VM to take a snapshot
● Multiple copies are stored across multiple
locations automatically
○ Snapshots can be shared across
projects
● Create snapshot schedules to make backups
of disks on a predetermined schedule

Snapshots
https://cloud.google.com/compute/docs/disks/snapshots
https://cloud.google.com/compute/docs/disks/create-snapshots

Best practices for persistent disk snapshots

https://cloud.google.com/compute/docs/disks/snapshot-best-practices
Deleting Snapshots
● A deleted snapshot is immediately marked as
DELETED in the system.
○ Is deleted outright If no dependent
snapshots
● If dependant snapshots exist
○ Data required for restoring other
snapshots is moved into the next
snapshot
○ Data not required for restoring is deleted
○ The next snapshot no longer references
the snapshot marked for deletion, and
instead references the snapshot before it
Create a Snapshot

Select source
disk

Select location

gcloud compute snapshots create webserver

--source-disk ws-disk
--source-disk-region=us-central1
Snapshot storage
● Stored in Cloud Storage and have a choice of
○ Multi-regional location, such as Asia
■ Provides higher availability (99.95% SLA vs 99.9% for regional)
■ Potentially slower snapshot restoration performance
○ Regional location, such as asia-south1
■ Use for compliance, e.g., GDPR
■ Use when all resources created from the snapshot will be in the same region -
provides fastest restoration performance
● Network costs may be incurred when creating a disk from a snapshot
○ Multi-regional location storage
■ No network costs as long as the new persistent disk is created in one of the
regions of the multi-regional group
○ Regional storage
■ Will incur network costs if the new disk is created in another region
 Snapshot use cases

● Snapshots have many use cases

○ Can be used as source for a new disk
○ Can play a part in a disaster recovery plan
○ Can backup data
○ Can be used to move a VM to another zone/region
○ Can be used to migrate data from one disk type to another
● Examples are shown on the following slides
Example - using a snapshot to backup data

Snapshot Service
Compute Engine
Cloud
Storage

root data

Snapshots have many use cases. For example, they can be used to backup critical
data into a durable storage solution to meet application, availability, and recovery
requirements.
Example - create disk from snapshot

Options are:
blank disk, image
or snapshot

Snapshot name

Another use case is the ability to create a new disk from a snapshot. Afterwards, this
disk can be attached to a VM.
Example - using a snapshot migrate data between zones

Zone 1 Zone 2

Compute Engine Compute Engine

Snapshot

Snapshots can also be used to migrate data between zones. For example, you might
want to minimize latency by migrating data to a drive that can be attached to a VM in
another zone.
 Example - Transferring data to SSD to improve
performance

Compute Engine

PD HDD PD SSD
root

Snapshot Service

Another snapshot use case of transferring data to a different disk type. For example, if
you want to improve disk performance, you could use a snapshot to transfer data
from a standard HDD persistent disk to a SSD persistent disk.
Snapshots vs Images
Both can be used as the basis for a new VM
● Takes longer to spin up a VM from a snapshot (data needs to be restored) versus an image
(which is already in the state to be booted)

Snapshots Images

● Best for disk backups ● Best for infrastructure re-use

● Can be scheduled ○ Boot disk/data disk images for new VMs
● Good for the use cases mentioned ○ Managed Instance Group templates
on the prior slides require images (not snapshots)
● Lower storage cost than images ● Can be versioned and deprecated
● Can be created while VM is running
Migrating applications running on-premise to Google Cloud
 Migrate to Compute Engine Virtual Machines
● Migrate VMs to Google Cloud Compute Engine directly
from on-premise including support for customizations to
networking, disks, and more
○ Includes VMs running Microsoft Windows applications
such as SQL Server
● Some of the benefits include
○ Built-in testing makes it fast and easy to validate
before migration
○ Can replicate data from the source workload to the
destination without manual steps or interruptions to
the running workload
○ Provides usage-driven analytics to help you rightsize
destination instances and avoid cloud
over-provisioning

Migrate to Virtual Machines

https://cloud.google.com/migrate/virtual-machines

Migrating VMs with Migrate to Virtual Machines: Getting started

https://cloud.google.com/architecture/migrating-vms-migrate-for-compute-engin
e-getting-started
 Migrate to Containers
● Automated approach to migrate applications running in
VMs to
○ Google Kubernetes Engine
○ Cloud Run
○ Anthos clusters
● Just some of the benefits
○ Higher utilization and density of nodes, leveraging
automatic bin-packing and auto-scaling
capabilities of GKE
○ Reduced downtime by leveraging Kubernetes
features like self healing and dynamic scaling
○ Environment parity with improved visibility and
monitoring, makes finding and fixing problems less
toilsome

https://cloud.google.com/migrate/containers

Blog: Migrating apps to containers? Why Migrate to Containers is your best bet
https://cloud.google.com/blog/products/containers-kubernetes/how-migrate-for-anthos
-improves-vm-to-container-migration