Getting Started with Google Cloud: A Practical Introduction

Google Cloud sits third in infrastructure market share behind AWS and Azure, with a meaningful and growing position in data, analytics and machine learning workloads in particular.

If your background is AWS or Azure, some of GCP will feel like a renamed version of what you already know, and some of it is genuinely built on different assumptions. The differences are where the useful learning is, so this guide leads with those rather than with a service list.

How GCP organises things

Every platform needs a way to group resources and attach billing and access to them. AWS uses accounts under organisations. Azure uses subscriptions under management groups. GCP uses projects.

A project is the fundamental container. Every VM, database, bucket and enabled API belongs to one. Each has a unique ID, a display name, and a billing account attached to it.

The useful mental model is a folder that also owns billing and access control. Organisations can hold very large numbers of them.

Organisations sit above projects. If you use GCP with a Workspace or Cloud Identity domain you get an organisation node automatically, and inside it you can group projects into folders, which is how most teams separate environments or business units.

The wrinkle if you are coming from Azure: a project is both the organisational container and the billing boundary. Azure keeps those as separate concerns, with resource groups organising and subscriptions billing. Expect to redraw your mental diagram rather than translate it directly.

Compute, storage and networking

Compute Engine

Compute Engine is the VM service, and the workflow will be familiar. Pick a machine type, choose an image, launch the instance.

Two things are distinctive. GCP offers custom machine types, letting you set the CPU and memory ratio directly rather than choosing from a fixed ladder of sizes. And sustained use discounts apply automatically once an instance has run for a decent portion of the month, with no commitment or reservation involved.

Pricing changes often enough that any figure printed here would be wrong before long, so check the current calculator rather than trusting a number in an article. The structural point is that GCP discounts steady usage by default, where AWS and Azure generally ask you to commit in advance for the equivalent saving.

The provisioning workflow itself is close enough between providers that practising it once carries over. Creating your first virtual machine on Azure covers the same decisions you will make in Compute Engine.

Cloud Storage

Cloud Storage is the object store, equivalent to S3 or Azure Blob Storage. You create buckets, put objects in them, and reach them over APIs or URLs.

The distinguishing feature is the storage class system. Standard for active data, then Nearline, Coldline and Archive for progressively colder data, each cheaper to store and more expensive to retrieve, and each carrying a minimum storage duration. Deleting a Coldline object after a week still bills you for the minimum period, which is the detail that catches people out.

Lifecycle rules move objects between classes automatically as they age, in the same way as S3 lifecycle policies or Azure blob tiering. If you have not set up tiering before, managing storage with object replication and lifecycle management teaches the pattern.

VPC, and the difference that actually matters

This is the one to pay attention to. A GCP VPC is global. Create one and it spans every region. Subnets are regional rather than zonal.

In AWS and Azure, VPCs and virtual networks are regional constructs, and connecting workloads across regions means peering or gateways that you set up deliberately. In GCP, instances in different regions can already reach each other over internal addresses within the same VPC.

That single design decision changes how multi region architecture looks. Things that require explicit connectivity work elsewhere are simply the default here, and habits carried over from AWS or Azure will lead you to build peering you do not need.

The underlying concepts, address planning, subnetting, routing and firewall rules, are the same everywhere. If those are new, build a virtual network and subnets once and the GCP model becomes a variation rather than a new subject.

Serverless: two options, not one

Cloud Functions is the direct analogue of Lambda or Azure Functions. Event driven, scales automatically, billed per invocation, with support for the usual language set. If you have worked through a first Lambda function or a serverless API on Azure Functions, the trigger model maps over cleanly.

Cloud Run sits between functions and managed containers. You hand it a container image and it scales from zero based on traffic. You still do not manage servers, but you get a custom runtime, longer execution limits and more control over the environment.

The practical guidance: reach for Cloud Functions when the unit of work is a single event handler, and Cloud Run when you already have a container or need behaviour a function cannot express.

IAM, familiar with a twist

GCP IAM uses the same three ideas as everyone else: identities, roles and policies. The binding model is where it diverges.

Rather than attaching a policy to a user, you bind a role to a member at a level of the hierarchy. A binding reads as "this identity holds this role on this project, folder or organisation", and it inherits downward. Permissions therefore accumulate from wherever they were granted above.

Roles come in three kinds. Basic roles, meaning owner, editor and viewer, are broad and worth avoiding outside experiments. Predefined roles are service specific and fine grained, and are what you should normally use. Custom roles exist for when nothing predefined fits.

If least privilege as a discipline is new to you, our AWS IAM explainer covers the reasoning in a way that applies regardless of provider.

Certifications worth considering

Google's ladder maps closely onto the others. Cloud Digital Leader is the foundational, non technical entry point, comparable to AZ-900 or AWS Cloud Practitioner. Associate Cloud Engineer is the hands on operations credential, sitting where AZ-104 and the AWS Solutions Architect Associate sit. Professional Cloud Architect is the advanced design credential.

Our certification prep covers the Google track with per domain scoring, and readiness scoring explains how to tell when you are actually prepared rather than merely finished studying.

What to build first

The fastest way in, if you already know another cloud, is to rebuild something you have already built. The comparison does most of the teaching.

• Launch a Compute Engine instance and notice what the console asks you that Azure or AWS did not.
• Create a bucket with a lifecycle rule and watch how class transitions are expressed.
• Deploy a Cloud Function, then deploy the same logic to Cloud Run, and pay attention to which one felt like less work and why.

The free tier is generous enough to do all of this without spending anything, including a small always free instance in selected regions, a few gigabytes of storage, and a monthly allowance of function invocations. Check the current limits before you plan around them, since the specifics move.