Cloud Concepts

Seven ideas explain most of what you see on the first day. Each is expanded on a later page, linked here.

Billing is attached to projects through a billing account, and most services are metered per second or per request rather than per hour (for example Compute Engine VMs are billed per second after a minimum). Budgets alert but do not cap spend. See Cost Management and Billing.

Cloud computing is the on-demand delivery of compute, storage, networking, databases, software and analytics over the internet with pay-as-you-go pricing, instead of buying servers and operating a data center. You call an API or click in a console, and a provider such as Google Cloud hands you capacity within minutes and bills for what you use. Virtualization — carving one physical host into many virtual machines — is a technology the cloud is built on, not the cloud itself: the cloud adds self-service provisioning, elastic scaling, metered billing and a provider that owns and operates the physical layer.

You interact with Google Cloud in four ways, and the rest of the section uses all of them:

Providers describe the benefits in similar terms. Each maps to concrete behaviour you will meet later:

Two ideas recur in those benefits. Scalability is the ability to add capacity: vertically ("scaling up", a bigger machine, with a ceiling and usually a restart) or horizontally ("scaling out", more instances behind a load balancer). Elasticity is the automated form of horizontal scaling, where capacity follows demand in both directions. High availability comes from redundancy across zones; it is measured in practice by the recovery time objective (RTO) and recovery point objective (RPO) you actually achieve in an incident.

Each step toward SaaS trades control for lower operational effort. The boundary is a continuum rather than five boxes: GKE Standard, GKE Autopilot, Cloud Run and BigQuery each sit at a different point. Which compute service to start with is the subject of Choosing a Compute Service.

Choosing a model comes down to compliance and data-residency requirements, latency to users or machinery, existing investment in hardware, and the skills available to operate each environment.

Google describes security as a shared responsibility. Google is responsible for security of the cloud: the facilities, the hardware, the global network and the software layer that virtualizes them. The customer is responsible for security in the cloud: everything they put on top and how they configure it. What moves with the service type is the line in between, and it moves along the same continuum as the service models above.

Data, identity and access configuration stay with the customer in every model, including SaaS. Misconfigured identity or a publicly readable bucket is a customer-side failure that no provider-side investment can offset; see Identity and Access and Cloud Storage Security and Static Sites.

Google also uses the term shared fate. Shared responsibility divides the duties and stops there; shared fate adds that Google helps you succeed on your side of the line, with secure blueprints and landing-zone guidance, defaults that are secure out of the box (for example the secure-by-default organization policies applied to organizations created since 2024-05-03) and governance tools. It is a statement of intent about product design rather than a change to who is accountable for configuration, so treat it as a reason to adopt the defaults rather than as a transfer of responsibility. Organization policies and the tools that detect misconfiguration are in Governance, Security and Compliance.

Running your own data center is capital expenditure (CapEx): large upfront purchases, depreciated over years and sized for a peak that may not arrive. Cloud consumption is operating expenditure (OpEx): a variable cost that follows usage, with nothing to buy upfront and nothing to dispose of. Google Cloud bills most services per second or per request, per gigabyte stored or per query, and a deleted resource stops accruing charges (apart from items kept after deletion, such as retained backups, soft-deleted objects and secret versions, which are billed until they expire or are removed).

Related cost concepts:

Current prices change, so this section never quotes them; use the dated official pricing pages and the Pricing Calculator. Cost drivers, budgets, labels and billing export are in Cost Management and Billing.

The Well-Architected Framework, part of the Google Cloud Architecture Center, describes recommendations for designing and operating workloads. It has a foundational system design category and six pillars:

Cross-pillar perspectives add guidance for specific domains such as AI and machine learning workloads. Use the pillars as a review checklist for each Bookshelf service you build in later pages: for example reliability points to regional resources and health-checked instance groups, while cost optimization points to scaling to zero and labelling resources.

The Google Cloud Adoption Framework helps an organisation assess where it stands and plan its move to the cloud. It is organised around four themes — Learn (skills and knowledge), Lead (leadership support and cross-team collaboration), Scale (using cloud services efficiently and automating operations) and Secure (protecting the environment) — and three maturity phases: tactical, strategic and transformational. Where Well-Architected reviews one workload, the Adoption Framework looks at the organisation. Landing-zone design — the folder and project structure and baseline policies that result from the Lead and Secure themes — starts in Resource Hierarchy and Projects.

Google documentation repeatedly returns to a handful of patterns; they recur in this section.

The running scenario, Bookshelf (a static front end, a catalog-api, an orders-api and a notifier worker that sends confirmation emails), combines several of these.