Skip to content
  • Independent cloud account marketplace
  • Options and USD prices shown before checkout
  • Support available before and after ordering
Provider Guides

Google Cloud Explained: Projects, Compute, Data, and AI Services

How Google Cloud is organised: projects, folders, and the organization resource, billing accounts and credits, Cloud IAM roles, regions and zones, and the compute, data, and AI services teams use most.

Google Cloud organises everything around the project, and understanding that one idea makes the rest of the platform fall into place. This guide explains the resource hierarchy, how billing accounts attach to projects, how Cloud IAM grants access, how regions and zones work, and which compute, data, and AI services most teams use. It closes with practical notes on budgets, quotas, and acceptable use.

Projects, folders, and the organization resource

Every Google Cloud resource belongs to a project. A project has a human-readable name, a globally unique project ID, and a numeric project number. APIs are enabled per project, service accounts are created per project, and quotas are counted per project. Deleting a project schedules everything inside it for removal, which makes projects a clean boundary for experiments, environments, and clients.

Above projects sit folders and the organization resource. The organization is the root node and is tied to a Google Workspace or Cloud Identity domain. Folders group projects by team or department. Policies set at the organization or folder level are inherited downwards, so an administrator can enforce rules once rather than per project. Projects created by an individual Google account have no organization parent.

Organization
Root of the hierarchy, linked to a Workspace or Cloud Identity domain
Folder
Optional grouping of projects with inherited policies
Project
Container for resources, APIs, service accounts, and quotas
Billing account
Payment profile linked to one or more projects

Billing accounts, credits, and budgets

Billing is separate from the resource hierarchy. A Cloud Billing account holds the payment method and receives the invoice. A project must be linked to an active billing account before it can use paid services, and one billing account can pay for many projects. Unlinking a project stops paid usage in it.

Google offers new customers a free trial with promotional credit and a set of always-free usage limits on selected services. The amount, the eligibility rules, and the trial length are set by Google and change over time. During the trial the billing account is in a restricted mode; upgrading it to a full pay-as-you-go account removes that restriction and allows usage beyond the credit. Any remaining credit is consumed first once the account is upgraded, within its validity window.

Budgets are configured on the billing account. A budget tracks actual or forecast spend against a threshold and sends email or Pub/Sub notifications at percentages you choose. A budget alerts you; it does not stop spending unless you wire the notification to an automated action. The official guide to managing billing accounts is on the Google Cloud billing documentation.

Identity and access with Cloud IAM

Cloud IAM answers who can do what on which resource. A principal (a user, group, service account, or domain) is bound to a role on a resource. Roles come in three kinds: basic roles (Owner, Editor, Viewer) that are broad and best avoided in production, predefined roles curated per service, and custom roles you assemble from individual permissions. Because bindings inherit down the hierarchy, a role granted at the folder level applies to every project inside it.

Service accounts are identities for workloads rather than people. A Compute Engine instance or a Cloud Run service runs as a service account, and that account’s roles decide what the code can reach. Prefer attaching service accounts to resources over downloading JSON key files, since keys are long-lived credentials that must be rotated and protected.

Regions, zones, and global resources

Google Cloud infrastructure is divided into regions, and each region contains multiple zones. A zone is the deployment area for zonal resources such as a Compute Engine VM or a persistent disk. Regional resources, such as a regional managed instance group or a Cloud SQL instance with high availability, are spread across zones in one region. Some services are multi-regional or global: a Cloud Storage bucket can be placed in a multi-region, and a VPC network is a global resource whose subnets are regional.

That global VPC is a real difference from other clouds. Instances in different regions can talk over private addresses inside one network without peering, and a single global external load balancer can front backends in several regions using anycast IP addresses. When choosing a region, weigh latency to your users, data residency rules, price differences between regions, and the availability of specific machine types or GPUs, which is not uniform.

Core services: compute, data, and AI

Category Services Notes
Compute Compute Engine, Google Kubernetes Engine, Cloud Run, App Engine VMs with predefined and custom machine types; managed Kubernetes with Autopilot mode; container-based serverless; a long-standing PaaS
Storage Cloud Storage, Persistent Disk, Hyperdisk, Filestore Object storage with Standard, Nearline, Coldline, and Archive classes; block storage for VMs; managed NFS
Databases Cloud SQL, AlloyDB, Spanner, Firestore, Bigtable, Memorystore Managed MySQL, PostgreSQL, and SQL Server; a PostgreSQL-compatible engine; globally consistent SQL; document and wide-column NoSQL; caching
Analytics BigQuery, Dataflow, Pub/Sub, Dataproc Serverless data warehouse; stream and batch processing; messaging; managed Spark and Hadoop
AI Vertex AI, Gemini models, Vision and Speech APIs Model training and deployment platform; foundation models through the Vertex AI API; pretrained APIs for common tasks
Networking and operations VPC, Cloud Load Balancing, Cloud CDN, Cloud DNS, Cloud Monitoring, Cloud Logging Global networking plus observability that is enabled by default for most services

BigQuery and Vertex AI are the two services that most often bring teams to Google Cloud. BigQuery separates storage from compute and bills queries by data scanned or by reserved slots. Vertex AI gives access to Google’s Gemini models and to third-party models through Model Garden, with quotas expressed per model and per region. Documentation for every service listed here is at cloud.google.com/docs.

Quotas, typical workloads, and practical considerations

Quotas limit resource usage per project, and often per region within a project. Examples include the number of CPUs in a region, the number of external IP addresses, and requests per minute to an API. The Quotas page under IAM and Admin shows current usage and lets you request increases, which Google reviews. New projects on freshly upgraded billing accounts usually start with lower limits than established ones.

Typical workloads include containerised applications on GKE or Cloud Run, analytics pipelines that land data in BigQuery, and AI products built on Vertex AI. Startups often pair Google Cloud with Google Workspace so that identity, email, and cloud administration share one domain.

  1. Set a budget with alerts on the billing account before you enable paid APIs.
  2. Give each environment its own project so quotas, IAM, and costs stay separated.
  3. Enable only the APIs you need; each enabled API expands the project’s attack surface and quota footprint.
  4. Read the Google Cloud Acceptable Use Policy and service terms. Cryptocurrency mining on trial credit, unsolicited email, and abusive traffic all breach the terms and lead to project suspension.
  5. Export audit logs and billing data to BigQuery early so you have history when questions come up.

Where to go next

Account listings with pay-as-you-go billing, prepaid balances, or larger credit amounts are on the Buy Google Cloud Accounts product page. If you want a Workspace domain to anchor an organization resource and business email, see Buy Google Workspace Account.

Related reading in the Cloud Library:

Browse the full Cloud Library, or read the AWS vs Google Cloud comparison.

More from the Cloud Library

Telegram