Tổng quan & Khái niệm cốt lõiOverview & Core Concepts

Part of the Cloud knowledge base — GCP deep dive. Complements DevOps Roadmap.

Overview

Google Cloud Platform (GCP) is Google’s public cloud, running on the same infrastructure that powers Google Search, Gmail, YouTube, and Maps. For a DevOps engineer arriving from AWS or Azure, the two biggest mental shifts are that GCP treats many core services as global rather than regional, and that everything you create lives inside a strict resource hierarchy (Organization → Folders → Projects → resources) that is the single anchor point for IAM, billing, and policy.

This page is the map of the territory: how Google’s physical network is laid out, how the logical hierarchy works, how you pay, how you access things, and where the shared-responsibility line sits. The IAM and Networking pages go deep on the two topics you will touch every single day.

Fundamentals

Global infrastructure: regions, zones, and edge

GCP is built from three physical tiers:

Key facts:

• A region has 3 or more zones. Zones are the unit of failure isolation — a zonal outage should not take down other zones. Spread instances across zones for high availability; spread across regions for disaster recovery and data residency.
• Zones inside a region are connected by low-latency, high-bandwidth links (typically sub-millisecond round-trips), so multi-zone architectures are cheap and fast — synchronous replication across zones is practical.
• Google runs a private global backbone network. With Premium Tier networking (the default), traffic enters/exits at the edge POP closest to the user and rides Google’s backbone the whole way. Standard Tier hands traffic to the public internet at the source region — cheaper but slower and less reliable.

AWS ↔ GCP equivalents (naming):

The resource hierarchy

Everything you create in GCP lives in a tree. This tree is not cosmetic — IAM policies and Organization Policies are inherited down it, and billing rolls up it.

Organization  (your company, tied to a Cloud Identity / Workspace domain)
└── Folder  (e.g. "Engineering")
    └── Folder  (e.g. "Team-Payments")
        └── Project  (e.g. "payments-prod")
            └── Resources  (VMs, buckets, GKE clusters, Pub/Sub topics…)

• Organization node — the root. Created automatically when you associate a Google Workspace or Cloud Identity account. Owns default org policies and the top-level IAM policy. There is exactly one per domain.
• Folders — optional grouping layer for departments, teams, or environments. Folders can nest (up to 10 levels deep). This is the natural place to apply IAM and org policies that should cascade to many projects.
• Projects — the fundamental unit. Every resource belongs to exactly one project. A project is the boundary for billing, enabled APIs, quotas, and IAM. A project has three identifiers:
  • Project ID — globally unique, user-chosen, immutable (e.g. payments-prod-4821).
  • Project number — globally unique, Google-assigned integer.
  • Project name — a mutable display label.
• Resources — the actual things (a VM, a bucket, a topic). They inherit the effective IAM policy of their project.

Projects & billing accounts

Billing is decoupled from the hierarchy: a Billing Account is a separate object that projects are linked to.

• One billing account can pay for many projects; a project links to exactly one billing account at a time.
• Billing accounts are owned at the Organization level and have their own IAM roles (roles/billing.admin, roles/billing.user).
• Use labels (env=prod, team=payments, cost-center=1234) on resources plus billing export to BigQuery for granular cost analysis and showback.
• Set budgets and alerts per billing account or per project — alerts fire on actual or forecasted spend, and can trigger Pub/Sub for automated responses.

Key Concepts

Global vs regional vs zonal resources

Knowing a resource’s scope tells you its failure domain and how you reference it.

Practical implication: a VPC is global, but its subnets are regional. You create one VPC and add a subnet per region as needed — very different from AWS, where a VPC is bound to one region and cross-region connectivity needs peering.

Shared responsibility (and shared fate)

Google secures the cloud; you secure what you put in it. The line moves with the service model:

IAM, data classification, and access management are always yours, regardless of service. Google also publishes a Shared Fate model — going beyond the line by providing secure defaults, blueprints (e.g. the security foundations blueprint), and guardrails so the paved path is the secure path.

Google Cloud Architecture Framework

Google’s equivalent of the AWS Well-Architected Framework. Six pillars to evaluate any design against:

1. Operational excellence — automation, observability, incident response.
2. Security, privacy & compliance — least privilege, defense in depth.
3. Reliability — SLOs, redundancy across zones/regions, graceful degradation.
4. Cost optimization — right-sizing, discounts, lifecycle policies.
5. Performance optimization — appropriate resources, caching, global reach.
6. Sustainability — carbon-aware region selection.

Ways to access GCP

Basic gcloud setup:

gcloud auth login                        # user credentials
gcloud config set project payments-prod  # default project for commands
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a

# Named configurations let you switch contexts (prod / dev)
gcloud config configurations create prod
gcloud config configurations activate prod
gcloud config configurations list

Pricing fundamentals

GCP’s pricing is known for granular, automatic discounts:

• Per-second billing — Compute Engine, GKE, and Dataproc bill by the second (with a 1-minute minimum). No rounding up to the hour.
• Sustained-use discounts (SUD) — automatic discounts on Compute Engine when a VM (of certain families) runs for a large fraction of the month (up to ~30% off for full-month usage). No commitment, no action needed.
• Committed-use discounts (CUD) — commit to 1 or 3 years of usage for ~37–70% off. Two flavors: resource-based (specific vCPU/RAM in a region) and spend-based (a dollar amount per hour, e.g. for Cloud Run / GKE Autopilot).
• Preemptible / Spot VMs — deeply discounted (60–91% off) VMs Google can reclaim with 30 seconds’ notice. Spot is the newer model with no 24-hour cap. Ideal for fault-tolerant batch, CI, and rendering.
• Free tier — a set of always-free resources (e.g. 1 e2-micro VM/month in select US regions, 5 GB Cloud Storage, generous Cloud Functions invocations) plus a $300 / 90-day free trial credit for new accounts.

Estimate before you build with the Google Cloud Pricing Calculator.

Organization Policies (intro)

Distinct from IAM. IAM controls who can do what; the Organization Policy Service controls what is allowed to exist and how, as guardrails set at org/folder/project level and inherited down.

Common constraints:

• compute.vmExternalIpAccess — restrict which VMs may have public IPs.
• iam.disableServiceAccountKeyCreation — block long-lived SA keys.
• gcp.resourceLocations — restrict resource creation to approved regions.
• compute.requireOsLogin — enforce OS Login for SSH.
• iam.allowedPolicyMemberDomains (domain-restricted sharing) — block sharing outside your org.

These are enforced even against Project Owners, which makes them a strong compliance control. See the IAM page for details.

Best Practices

1. Model your hierarchy before scaling. Use folders per department and separate projects per environment (app-dev, app-staging, app-prod). Apply IAM and org policy high in the tree so it cascades — far easier than retrofitting later.
2. One workload/environment per project. Projects are the blast radius for IAM, quotas, and billing. Isolating them limits the damage of a mistake or compromise and makes cost attribution trivial.
3. Never use the org-level Owner role for daily work. Reserve it for break-glass; grant least-privilege predefined roles instead (see IAM page).
4. Turn on org policies from day one. At minimum disable SA key creation, restrict external IPs, and pin resourceLocations to your compliance regions — cheap guardrails that prevent expensive mistakes.
5. Label everything. Enforce env, team, and cost-center labels; you cannot do meaningful cost or security analysis without them.
6. Export billing to BigQuery and set budgets with alerts. Detect runaway spend early; build showback/chargeback dashboards from the export.
7. Use committed-use discounts for steady baseline load and let sustained-use discounts cover the rest — then add Spot VMs for elastic/batch capacity.
8. Prefer Spot VMs for anything fault-tolerant (CI runners, batch, dev). The savings are large and the reclaim risk is manageable with retries and MIGs.
9. Choose regions deliberately for latency, data residency/compliance, cost (prices vary by region), and carbon footprint — not just “the default”.
10. Design for zone failure by default. Spread across ≥2 zones; use regional managed instance groups and regional persistent disks for stateful services.
11. Manage infrastructure as code (Terraform + Config Connector). Console clicks don’t scale, aren’t reviewable, and drift silently.
12. Use named gcloud configurations (or separate service accounts) to keep prod and non-prod contexts firmly separated and avoid “wrong project” accidents.
13. Adopt the Architecture Framework as a review checklist for every non-trivial design; it catches reliability and cost gaps before launch.
14. Enable Cloud Asset Inventory and Security Command Center to keep a continuous, queryable record of what exists and its security posture.
15. Use a dedicated, locked-down “seed”/bootstrap project for org-level automation (Terraform state, org policies) so foundational config is not tangled with workloads.

References

• Google Cloud documentation home
• Geography and regions
• Resource hierarchy
• Global, regional, and zonal resources
• Shared responsibility and shared fate
• Google Cloud Architecture Framework
• gcloud CLI overview
• Compute Engine pricing (SUD/CUD)
• Committed use discounts
• Spot VMs
• Free tier
• Pricing calculator
• Organization Policy Service
• Cloud Foundation Fabric (reference blueprints)