🧩 Google Cloud Services: A Map for People Who Know Linux

How Google Cloud is organized (organization, folders, projects, resources), the services you meet first, a translation list from Linux ideas to Google Cloud ones, and what keeps billing after you stop

How Google Cloud is organized

The documentation gives the hierarchy as Organization → Folders → Projects → Resources:

• Organization: the root, for a company. Policies and access set here apply to everything below.
• Folders: optional groups, for departments or teams.
• Project: the fundamental organizing entity. You need one to use services, to manage APIs and to enable billing.
• Resources: the VMs, buckets, disks and databases inside a project.

Every resource has exactly one parent, and access policies are inherited downward: a role given on a folder applies to every project in it.

The project is your unit of work

Compared with the other clouds, the project does a lot at once:

• It is the container for cleanup. Delete a project, and everything in it goes (with 30 days to restore it). That is the Google Cloud version of deleting an Azure resource group, and much more final than closing one resource at a time.
• It is where services are switched on. Most services need their API enabled in the project before you can use them. gcloud services enable compute.googleapis.com turns on Compute Engine, for instance. A first-day error such as "API has not been used in project ... before or it is disabled" means exactly this. (From the documentation, not run here.)
• It is the billing link. A project is attached to one billing account, and billable services stop if billing is disabled.
• It is a quota boundary. Limits apply per project (and per region).
• It carries labels. Key-value tags you put on resources (env=test) and use in billing reports and budgets.

Make one project per experiment, with a clear ID, and delete the project when you finish. That one habit prevents most surprises.

IAM: who may do what

Covered on the account page: principals (Google accounts, groups, service accounts) get roles on a resource, and policies are inherited down the hierarchy. The rules to remember: avoid the basic roles (Owner, Editor, Viewer) in production, use predefined roles, and give programs a service account attached to the VM instead of a downloaded key.

Ways to work

• The console (console.cloud.google.com), Cloud Shell (a terminal in it), the gcloud CLI, and the client libraries.
• Terraform and Deployment Manager-style tools when you want to rebuild the same thing again.

The first services you will meet

Compute

• Compute Engine. Virtual machines. You choose a machine type (such as the small e2-micro), an image (Debian, Ubuntu, Windows and others), a zone and a boot disk. The free GCP VM guide walks through one.
• Cloud Run. Run a container image and pay for the time it handles requests: no server to look after.
• Google Kubernetes Engine (GKE). Managed Kubernetes (compare the Kubernetes node access tutorial).
• App Engine and Cloud Functions (now part of the Cloud Run family of products): older and smaller-scale ways to run code without servers.

Storage

• Cloud Storage. Objects in buckets, with globally unique names, and a choice of a single region, a dual-region or a multi-region. The closest thing to an S3 bucket.
• Persistent Disk. The disks of VMs: zonal, and in the same zone as the VM.
• Filestore. A managed shared file system mounted over NFS. Compare the NFS page, where we built the same idea ourselves.

Networking

• VPC network. Your private network. It is global, and its subnets are regional: one network can span the world.
• Firewall rules. Allow and deny rules for the VPC, applied to VMs by network tags or service accounts. The same job as pf or iptables. Traffic in is denied by default.
• External IP addresses. Ephemeral or static. A static one is a regional resource and can be billed.
• Cloud Load Balancing, Cloud DNS, Cloud NAT (outbound access for machines without public addresses) and Cloud VPN (compare the WireGuard page for a tunnel you build yourself).

Identity and secrets

• IAM, service accounts, Secret Manager (keep passwords out of files) and Cloud KMS (encryption keys).

Data

• Cloud SQL (managed MySQL, PostgreSQL and SQL Server), Firestore, Spanner and BigQuery (analytics, multi-regional).

Watching and cost

• Cloud Monitoring and Cloud Logging (the idea of the monitoring page as a service), Cloud Audit Logs (who did what), Billing reports and budgets.

Linux idea, Google Cloud idea

• sudo and file permissions → IAM roles on a project
• Users in /etc/passwd → Google accounts and groups
• A password or key in a config file → a service account on the VM, Secret Manager
• A disk and /etc/fstab → Persistent Disk (one VM) or Filestore (shared, NFS)
• iptables, nftables, pf → VPC firewall rules
• nginx as a reverse proxy → Cloud Load Balancing
• /var/log and syslog → Cloud Logging
• Cron → Cloud Scheduler with Cloud Run (from the documentation, not run here)
• Backups with rsync or zfs send → disk snapshots and Cloud Storage
• /etc/hosts and DNS servers → Cloud DNS
• SSH key login stays SSH key login: Compute Engine can manage keys for you, and the console has a browser SSH button, as the free VM guide shows

What costs money while it sits there

From Google's Compute Engine documentation, and in line with the free GCP VM guide:

• A stopped VM stops costing for compute (the vCPUs and memory), but you keep paying for its disks, the boot disk and any data disks, and for static external and internal IP addresses. Google's own warning: stopping does not remove the charges for attached resources, so detach and delete the disks and IPs you do not need.
• An ephemeral external IP is released when the VM stops, and a different one is assigned on restart. A static one stays attached.
• Suspend keeps the memory state as well, and delete removes the instance for good (its disks too, unless you made snapshots).
• External IPv4 addresses are billed by the hour. Check Google's network pricing page for the current rate: the number changes, and I did not rely on a figure here.
• Load balancers, Cloud NAT, VPN and managed databases bill for existing, whether or not you send traffic (check each pricing page).
• Traffic leaving Google Cloud, and some traffic between regions and zones, is billed.
• During the free trial, the $300 pays for it, but the resources stop when the trial ends (see the account page). On the free tier, only one e2-micro in three regions is covered.

The cleanup rule: one project per experiment, and delete the project.

A first small path (from the documentation, not run here)

A tidy first experiment that needs no VM: a project, a bucket, a file, and then everything removed. It needs a signed-in gcloud and a billing account.

gcloud projects create my-lab-4821 --name="My lab"
gcloud config set project my-lab-4821
gcloud billing projects link my-lab-4821 --billing-account=BILLING_ACCOUNT_ID
gcloud storage buckets create gs://my-lab-4821-bucket --location=us-central1
echo "hello from gcp" > hello.txt
gcloud storage cp hello.txt gs://my-lab-4821-bucket/
gcloud storage ls gs://my-lab-4821-bucket/
gcloud projects delete my-lab-4821

• projects create makes the project with an ID you choose: lowercase, unique across all of Google Cloud, and permanent.
• billing projects link attaches it to a billing account (find the ID in the console under Billing, or with gcloud billing accounts list).
• The bucket name must be globally unique, and --location decides where it lives.
• projects delete removes everything in the project at once, and you have 30 days to restore it.

Then check the billing reports the next day, and the account page covers budget alerts.

What this page did not cover

Organizations and folder design, Shared VPC, Cloud Build and deployment pipelines, the AI and analytics products, hybrid networking with Interconnect, and every service not named above. Google's documentation covers each of them in depth.

The cheat sheet

• Hierarchy: organization, folders, project, resources. One parent each. Access flows downward.
• Project: the container, the cleanup unit (30-day restore), the billing link, the place where APIs are enabled, and a quota boundary. One per experiment.
• First services: Compute Engine, Cloud Run, Cloud Storage, Persistent Disk and Filestore, a VPC with firewall rules, IAM and service accounts, Cloud SQL, Monitoring and Logging.
• Linux to Google Cloud: sudo is IAM, fstab is Persistent Disk or Filestore, pf is firewall rules, syslog is Cloud Logging, secrets in files are service accounts and Secret Manager.
• Billing traps: disks and static IPs after a stop, external IPv4 by the hour, load balancers, NAT, VPN and databases, trial ending, traffic out.
• Tidy experiment: gcloud projects create ID, gcloud config set project ID, create things, gcloud projects delete ID.

← Google Cloud Regions and Zones: Zonal, Regional and Global Things · ↑ All tutorials