Google Cloud Platform: what Australian teams need to know

Google Cloud Platform is a data- and container-first cloud platform well suited to organisations prioritising analytics, machine learning, and Kubernetes workloads. Built on the same global infrastructure that powers Google Search and YouTube, it offers 150+ products spanning compute, storage, networking, databases, and AI, with BigQuery and Vertex AI as its most technically differentiated services. For Australian teams evaluating cloud providers, GCP’s strengths in serverless analytics and managed Kubernetes make it a compelling choice, particularly where data engineering and AI are strategic priorities.

Immediate considerations for Australian organisations:

Strengths:

• BigQuery’s serverless data-warehouse model eliminates cluster management and scales to petabyte workloads without pre-provisioning

• Vertex AI and Gemini Enterprise provide a managed end-to-end ML platform with agentic AI capabilities built in.

• Google Kubernetes Engine (GKE) is widely regarded as the most mature managed Kubernetes service available

• Australian regions (Sydney and Melbourne) support data residency requirements and low-latency deployments

• $300 in free credit for new accounts lowers the barrier to piloting workloads

Considerations:

• The breadth of GCP’s product catalogue introduces SKU complexity; selective adoption is advisable

• The local partner ecosystem is smaller than AWS or Azure in Australia, which can affect support options for complex enterprise rollouts

• Some enterprise software integrations (particularly Microsoft-stack workloads) are more native on Azure

• Cost management requires deliberate governance; unconstrained egress and API usage can accumulate quickly

Table of Contents

• How GCP’s core services are organised

• Why GCP leads on data analytics and AI

• GKE, serverless compute, and developer tooling

• Security, identity, and compliance for Australian organisations

• GCP regions, zones, and networking in Australia

• How GCP pricing works and what drives costs in Australia

• Migration tools, Anthos, and hybrid strategies

• Which organisations benefit most from GCP

• GCP vs AWS vs Azure: a decision-focused comparison

• How to get started with GCP from Australia

• When to engage a partner for GCP adoption

• Key takeaways

• GCP’s data-first model rewards deliberate architecture choices

• SST Cloud’s GCP services for Australian organisations

• Useful resources and documentation

How GCP’s core services are organised

Google Cloud groups its services into logical categories, each addressing a distinct layer of a cloud architecture. GCP’s evolution from a handful of infrastructure products to a catalogue spanning AI, developer tooling, and managed databases means most organisations will only need a subset of what is available. The table below maps each category to its core purpose, representative products, and the workloads they typically serve.

A few products deserve particular attention because they appear across multiple architecture patterns:

• Cloud IAM governs who can do what across every GCP resource; getting the policy structure right early prevents costly remediation later

• VPC provides the network foundation for all compute and database services; subnet design affects both security posture and inter-region latency

• Pub/Sub decouples producers and consumers in event-driven architectures and feeds real-time data into BigQuery and Dataflow pipelines

• Anthos extends GCP’s Kubernetes management plane to on-premises and other cloud environments, making it the centrepiece of any hybrid strategy

Given the scale of GCP’s SKU catalogue, the practical advice is to start with the products that directly address your highest-priority workload and expand deliberately.

Why GCP leads on data analytics and AI

GCP is frequently chosen for large-scale analytics and AI because BigQuery’s serverless data-warehouse model and Vertex AI’s managed ML platform remove most of the infrastructure overhead that slows data teams down. That combination is not accidental; it reflects Google’s internal architecture for processing search, advertising, and YouTube data at scale, now exposed as managed services.

BigQuery: serverless analytics at scale

BigQuery separates storage from compute, meaning you pay for the data you store and the queries you run, not for a cluster that sits idle between jobs. Its columnar storage format compresses data efficiently and accelerates analytical queries across billions of rows. Cloud Storage integrates directly with BigQuery, so raw data landed in object storage can be queried in place via external tables or loaded into native tables for higher performance. That storage-to-warehouse flow is the foundation of most GCP data lake architectures.

Vertex AI and Gemini Enterprise

Vertex AI provides a unified platform for the full ML lifecycle: data preparation, model training, hyperparameter tuning, model registry, and online or batch inference. It connects natively to BigQuery for feature engineering and to Cloud Storage for training data and model artefacts. Gemini Enterprise extends this with agentic AI capabilities, meaning teams can build AI agents that act inside business workflows rather than simply returning a model output. For organisations moving from static ML models to operational AI, that distinction matters in planning terms.

Compliance and governance note: Organisations building AI systems on Vertex AI should review Google’s AI usage policies and align with the NIST AI Risk Management Framework for responsible deployment practices.

Pro Tip: Before committing to BigQuery as your primary warehouse, assess whether your workloads are predominantly analytical (aggregations, scans, joins across large datasets) or transactional (high-frequency point reads and writes). BigQuery excels at the former; Cloud SQL or Cloud Spanner are better fits for the latter. Running a representative query set against a sample dataset in BigQuery’s free tier is the fastest way to validate the fit.

Organisational implications

Realising GCP’s data and AI advantages requires investment in specific skills: data engineers who understand BigQuery’s pricing model (on-demand versus capacity-based slots), MLEs familiar with Vertex AI pipelines, and data governance practitioners who can enforce column-level security and data lineage. The cost profile also shifts: BigQuery charges per terabyte scanned on the on-demand model, so poorly written queries against large tables can generate unexpected spend. Slot-based pricing (flat-rate reservations) suits teams with predictable, high-volume query loads. Understanding that trade-off before you migrate your data estate is worth the time.

For teams looking to move beyond isolated ML models toward agentic AI systems that operate across enterprise data sources, GCP’s integrated stack provides a credible path, provided the underlying data architecture is sound.

GKE, serverless compute, and developer tooling

GCP is container-first in a meaningful sense: Google invented Kubernetes, and GKE remains the most feature-complete managed Kubernetes service available. Cloud Run and Cloud Functions extend that container-first philosophy into serverless territory, giving teams a spectrum of options from full cluster control to zero-infrastructure function execution.

GKE: managed Kubernetes for production workloads

GKE handles control-plane management, node upgrades, and auto-scaling, leaving teams to focus on workload configuration rather than cluster operations. It supports Autopilot mode, which abstracts node management entirely and bills per pod resource request, and Standard mode, which gives operators full control over node pools. For organisations running containerised microservices at scale, GKE’s integration with Cloud Load Balancing, Artifact Registry, and Cloud Build creates a coherent production platform.

Cloud Run and Cloud Functions

Cloud Run executes containerised workloads without managing nodes or pods; you deploy a container image and GCP handles scaling from zero to thousands of instances. It suits stateless HTTP services, API backends, and event-driven processing. Cloud Functions goes further toward abstraction, running individual functions triggered by HTTP, Pub/Sub messages, or Cloud Storage events. The trade-off is straightforward: Cloud Run gives you more control over the runtime environment; Cloud Functions minimises operational surface at the cost of flexibility.

Developer tooling that accelerates delivery:

• Cloud Build provides managed CI/CD pipelines that trigger on source commits, build container images, and push to Artifact Registry

• Artifact Registry stores and manages container images and language packages (npm, Maven, Python) with integrated vulnerability scanning

• Cloud Code is an IDE plugin for VS Code and IntelliJ that provides Kubernetes and Cloud Run development workflows locally

• Cloud Shell gives browser-based access to a pre-configured Linux environment with the gcloud CLI, kubectl, and Terraform installed

• Infrastructure as Code patterns using Terraform or Google’s own Config Connector allow teams to version-control GCP resource definitions alongside application code

Pro Tip: If your team is migrating from on-premises workloads to containers, start with Cloud Run for stateless services before committing to GKE. Cloud Run’s operational simplicity lets teams learn container packaging and deployment patterns without the cognitive load of Kubernetes cluster management. Introduce GKE when workloads require persistent storage, custom networking, or cluster-level policies that Cloud Run cannot accommodate.

The landing zone and CI/CD patterns that apply to AWS environments translate directly to GCP: a well-structured project hierarchy, federated identity for CI/CD pipelines (using Workload Identity Federation rather than long-lived service account keys), and automated policy enforcement through Organisation Policies.

Security, identity, and compliance for Australian organisations

Cloud IAM, VPC Service Controls, and Cloud Security Command Center form the foundation of GCP’s security posture. For Australian organisations, the additional considerations are data residency, alignment with frameworks such as IRAP (Information Security Registered Assessors Program), and the practical mechanics of encryption key management.

Identity and access management

Cloud IAM enforces who can perform which actions on which resources. GCP’s Resource Manager hierarchy — organisation, folders, projects — maps directly to IAM policy inheritance: a policy set at the organisation level propagates down unless explicitly overridden. This makes the hierarchy design a security decision, not just an administrative one. Workload Identity Federation allows CI/CD pipelines and external services to authenticate using short-lived tokens rather than service account keys, which is the recommended pattern for production environments.

Network security

VPC Service Controls create a security perimeter around GCP services, preventing data exfiltration even if an IAM policy is misconfigured. Private Service Connect allows services inside a VPC to reach GCP APIs without traversing the public internet. For Australian government and regulated-industry workloads, combining VPC Service Controls with organisation-level policies that restrict resource creation to Australian regions provides a defensible data residency posture.

Compliance trust signals to request from a GCP partner or vendor

When evaluating GCP deployments for regulated workloads, request evidence of the following: ISO 27001 certification for the relevant GCP services, SOC 2 Type II reports, data residency configuration confirming storage in Australian regions, Cloud KMS key management policies (including Customer-Managed Encryption Keys where required), audit logging enabled via Cloud Audit Logs with Access Transparency, and IRAP assessment status for government workloads. Google publishes compliance reports through its Compliance Reports Manager.

Operational security checklist for Australian teams:

• Apply least-privilege IAM roles; avoid primitive roles (Owner, Editor) in production projects

• Use organisation policies to restrict resource creation to australia-southeast1 and australia-southeast2

• Enable Cloud Audit Logs (Admin Activity, Data Access) across all projects from day one

• Configure VPC Service Controls perimeters around BigQuery, Cloud Storage, and other data services

• Use Customer-Managed Encryption Keys (CMEK) via Cloud KMS for workloads with data sovereignty requirements

• Review Google’s Compliance Reports Manager for current ISO 27001, SOC 2, and IRAP documentation before procurement sign-off

GCP regions, zones, and networking in Australia

GCP operates two regions in Australia: australia-southeast1 (Sydney) and australia-southeast2 (Melbourne). Each region contains multiple zones, which are physically separate data centres within the same geographic area. Deploying across two zones within a single region provides resilience against zone-level failures; deploying across both Australian regions provides resilience against region-level events and supports active-active or active-passive disaster recovery patterns.

Networking services relevant to Australian deployments:

• VPC: GCP’s VPC is global by default, meaning a single VPC can span both Australian regions and all other GCP regions without requiring VPC peering between regions. Subnets are regional.

• Cloud Interconnect: Dedicated Interconnect provides a private, high-bandwidth connection from your on-premises network to GCP, bypassing the public internet. Partner Interconnect is available through local Australian carriers for lower-bandwidth requirements.

• Network Service Tiers: Premium Tier routes all traffic over Google’s private backbone, reducing latency and packet loss for latency-sensitive applications. Standard Tier is cheaper but routes egress traffic over the public internet.

For most Australian enterprise deployments, the recommended starting point is australia-southeast1 as the primary region with australia-southeast2 as the disaster recovery target, using Cloud Storage’s AUSTRALIA multi-region configuration for object storage to maintain data residency within the country.

How GCP pricing works and what drives costs in Australia

GCP pricing is product-by-product, with the primary cost drivers being compute hours, storage volume and class, network egress, and API call volume. New accounts receive $300 in free credit valid for 90 days, which is sufficient to run meaningful pilots across Compute Engine, Cloud Run, BigQuery, and Cloud Storage without committing budget.

Free tier and free trial

Beyond the $300 trial credit, GCP maintains always-free tiers for several services: one f1-micro Compute Engine instance per month in select regions, 5 GB of Cloud Storage in the US region, 10 GB of BigQuery storage and 1 TB of query processing per month, and limited Cloud Functions invocations. The always-free tiers are US-region-specific for most services, so Australian-region workloads will incur costs once the trial credit is exhausted.

Key cost drivers

• Compute Engine: billed per second after the first minute; machine type (vCPU and memory), sustained use discounts, and committed use discounts (1-year or 3-year) are the primary levers

• Cloud Storage: charged on storage volume, storage class (Standard, Nearline, Coldline, Archive), and retrieval operations; lifecycle policies that automatically transition objects to colder classes are one of the most effective cost controls available

• BigQuery: on-demand pricing charges per terabyte of data scanned; capacity pricing (slot reservations) suits predictable, high-volume workloads

• Network egress: data leaving GCP to the internet or to other cloud providers incurs egress charges; inter-region egress within GCP also applies

• API usage: Vertex AI, Document AI, and other managed AI services charge per API call or per compute hour consumed during training and inference

A practical cost scenario: A team running a nightly BigQuery analytics job that scans 500 GB of data on the on-demand model would incur approximately US$2.50 per run at the published rate of US$5 per TB scanned (prices vary by region and are subject to change; verify current rates on the GCP pricing calculator). Switching to slot reservations at 100 slots would cost a flat monthly fee regardless of query volume, which becomes cost-effective once daily query volume exceeds a predictable threshold.

Australian procurement considerations:

• GCP invoices in USD by default; Australian organisations should account for currency conversion and GST in budget planning

• Reseller arrangements through local Google Cloud partners can provide AUD invoicing and consolidated billing

• Committed use discounts require upfront commitment; align these with budget cycles and workload forecasts before signing

Migration tools, Anthos, and hybrid strategies

Migration to GCP is a continuum. Lift-and-shift (rehosting) moves workloads with minimal change and is the fastest path to the cloud; replatforming makes targeted adjustments to use managed services; refactoring re-architects applications around cloud-native patterns. The right pattern depends on business goals, timeline, and the technical debt embedded in existing systems. Treating migration as business transformation, not just infrastructure relocation, consistently produces better outcomes.

Core migration tools

1. Migrate for Compute Engine: automates the replication and cutover of on-premises or other-cloud VMs to Compute Engine, with continuous replication to minimise downtime during cutover

2. Transfer Appliance: a physical hardware appliance for offline data transfer when network bandwidth makes online transfer impractical; suited to petabyte-scale data migrations

3. Cloud Dataflow and Storage Transfer Service: managed services for online data migration from on-premises storage, AWS S3, or Azure Blob Storage into Cloud Storage or BigQuery

4. Database Migration Service: handles schema conversion and continuous replication for MySQL, PostgreSQL, and SQL Server migrations to Cloud SQL or AlloyDB

Anthos for hybrid and multi-cloud

Anthos extends GCP’s Kubernetes management plane to on-premises clusters and workloads running on other cloud providers. It provides a consistent policy enforcement layer (using Config Sync and Policy Controller), unified observability, and a single control plane for managing containerised workloads regardless of where they run. Anthos fits organisations that cannot move all workloads to GCP due to regulatory constraints, existing contracts, or latency requirements, but want consistent Kubernetes operations and security policy across environments.

Migration readiness checklist:

1. Inventory all workloads: document dependencies, data volumes, and compliance requirements before selecting a migration pattern

2. Assess network connectivity: determine whether Cloud Interconnect is required for the migration phase and ongoing operations

3. Define the target architecture: decide which workloads will lift-and-shift versus replatform versus refactor before starting

4. Establish the Resource Manager hierarchy: set up organisation, folders, and projects with billing accounts before migrating any workload

5. Configure identity federation: connect your existing identity provider (Azure AD, Okta, or similar) to Cloud IAM before migrating users and service accounts

6. Set budget alerts: configure billing budgets and alerts in the GCP Console before any workload goes live

Pro Tip: The most common migration trap is replicating on-premises network topology verbatim into VPCs — creating dozens of subnets, firewall rules, and peering connections that mirror legacy network segments. GCP’s global VPC model does not require that complexity. Start with published migration patterns and the gcloud CLI for automation, and design the VPC to match your security and routing requirements, not your existing network diagram.

Understanding why cloud migration projects fail before they begin is as important as the technical execution; organisational alignment and clear ownership of the migration programme are prerequisites for a successful cutover.

Which organisations benefit most from GCP

GCP fits organisations where large-scale analytics, ML and AI, containerised microservices, or global network performance are strategic priorities. It is not the default choice for every workload, and understanding where it excels helps teams make a well-grounded platform decision.

Common use cases where GCP delivers clear value:

• Analytics and BI on BigQuery: organisations processing large volumes of structured or semi-structured data for reporting, dashboarding (via Looker), or ad-hoc analysis

• ML training and inference: teams building and operationalising machine learning models, particularly where Vertex AI’s managed pipelines reduce MLOps overhead

• Containerised SaaS products: software companies building multi-tenant SaaS on Kubernetes, where GKE’s maturity and Cloud Run’s simplicity accelerate delivery

• Streaming data pipelines: architectures that ingest real-time event data via Pub/Sub and process it through Dataflow into BigQuery or Cloud Storage

• Agentic AI applications: organisations building AI agents that operate across enterprise data sources, using Vertex AI and Gemini Enterprise as the underlying platform

• High-performance compute for scientific workloads: research institutions and engineering teams running batch HPC jobs on Compute Engine with GPU or TPU accelerators

• Global consumer applications: products requiring low-latency delivery to users across multiple continents, leveraging Google’s Premium Network Tier and global load balancing

Team skills that accelerate success:

Organisations with existing data engineering capability (Python, SQL, Apache Beam or Spark) adapt quickly to BigQuery and Dataflow. Platform engineering teams familiar with Kubernetes and Helm charts find GKE’s tooling intuitive. The steeper learning curve tends to be in GCP’s IAM and Resource Manager model, which differs meaningfully from AWS and Azure in its inheritance and policy structure. Investing in that understanding early, through unified data and intelligence approaches, pays dividends across every subsequent workload.

GCP vs AWS vs Azure: a decision-focused comparison

GCP’s strongest differentiators are its AI and data capabilities and its network infrastructure. AWS leads on breadth of services and ecosystem maturity; Azure leads on Microsoft-stack integration and enterprise identity. The right choice depends on workload profile, existing technology investments, and team skills.

When to choose GCP: Select GCP when analytics and ML are central to your product or operations, when your team is building containerised applications and wants the most mature managed Kubernetes service, or when you are building agentic AI applications and want a tightly integrated platform from data ingestion through to model deployment. If your primary workloads are Windows Server, SQL Server, or .NET applications with Active Directory integration, Azure is likely the more natural fit. If you need the broadest service catalogue and the largest local partner network, AWS is the safer default.

Choosing a cloud provider is ultimately about architectural philosophy alignment. GCP rewards teams that embrace its data-centric, container-native model; organisations that treat it as a generic IaaS provider will underutilise its strengths.

How to get started with GCP from Australia

1. Create a GCP account and claim the free trial credit. Sign up at cloud.google.com, verify a payment method, and the $300 credit is applied automatically. Set a billing budget alert immediately so you receive a notification before the credit is exhausted.

2. Set up the Resource Manager hierarchy before creating any workload resources. Create an organisation node (requires a Google Workspace or Cloud Identity domain), define folders to represent business units or environments (production, non-production), and create projects within those folders. Billing accounts attach at the project level. Getting this structure right from the start avoids the painful restructuring that comes from creating resources directly under a root project.

3. Run a scoped pilot project. Choose one workload that represents your highest-priority use case: a BigQuery analytics pipeline, a Cloud Run API, or a GKE cluster for a containerised service. Use the official quickstart guides in the GCP documentation and Cloud Shell to deploy without local tooling setup.

4. Configure IAM and organisation policies for the pilot. Apply least-privilege roles, enable Cloud Audit Logs, and set an organisation policy restricting resource creation to Australian regions. This establishes security habits before workloads carry production data.

5. Explore training resources. Google Cloud Skills Boost (formerly Qwiklabs) provides hands-on labs with temporary GCP environments; no local account setup is required. Coursera’s Google Cloud Professional Certificate programmes cover architecture, data engineering, and security. For formal recognition, the Google Cloud Associate Cloud Engineer certification is the recommended starting point for practitioners new to the platform.

6. Select a support plan for production workloads. GCP offers Basic (free, documentation and community), Developer, Production, and Enhanced support tiers. Production support provides 24/7 access to technical support engineers and is the minimum recommended tier for workloads with business-critical SLAs.

7. Engage a local partner for complex deployments. For migrations involving regulated data, enterprise security requirements, or significant data engineering scope, engaging a certified Google Cloud partner with Australian presence reduces delivery risk and accelerates time to value. Verify the partner’s Google Cloud specialisations and ask for references from comparable Australian engagements.

When to engage a partner for GCP adoption

Engaging a specialist partner makes the most sense when the project involves complex data migration, enterprise security and compliance requirements, or when in-house capacity for platform engineering is limited. The cost of a poorly structured GCP deployment — in rework, security remediation, and operational overhead — consistently exceeds the cost of getting expert input at the design stage.

Engagement scopes SST Cloud offers for GCP adoption:

• Cloud strategy and architecture: defining the target state architecture, service selection, and migration sequencing before any infrastructure is provisioned

• Cloud migration: executing lift-and-shift, replatforming, and refactoring migrations using Migrate for Compute Engine, Database Migration Service, and cloud-native IaC patterns

• Platform engineering: designing and building GKE clusters, CI/CD pipelines, Artifact Registry workflows, and developer platform tooling

• Managed cloud services: ongoing operational management of GCP environments, including cost optimisation, security monitoring, and incident response

• Data and AI engineering: building BigQuery data warehouses, Vertex AI ML pipelines, and agentic AI systems on GCP’s data stack

• Application modernisation: re-architecting legacy applications to run on Cloud Run, GKE, or serverless patterns

SST Cloud has delivered cloud transformation outcomes for organisations across multiple industries, including workloads requiring data residency compliance and enterprise-grade security posture.

Pro Tip: When selecting a GCP partner, verify three things: their active Google Cloud specialisations (particularly in the area most relevant to your workload — Infrastructure, Data Analytics, or Machine Learning), their experience with Australian compliance requirements (IRAP, ISO 27001, Privacy Act obligations), and whether their engagement model includes knowledge transfer so your internal team builds capability alongside the delivery. A partner who delivers without transferring knowledge creates dependency rather than capability.

Key takeaways

GCP is the strongest cloud platform for organisations where BigQuery analytics, Vertex AI machine learning, and GKE container workloads are strategic priorities, with two Australian regions supporting data residency and low-latency deployments.

GCP’s data-first model rewards deliberate architecture choices

The conventional wisdom in cloud adoption is that you pick a provider, migrate your workloads, and optimise later. GCP challenges that sequence. Its pricing model, particularly BigQuery’s per-terabyte query charges and Cloud Storage’s tiered classes, means that architectural decisions made during migration directly determine your cost profile for years. Teams that treat GCP as a generic IaaS layer and move workloads without re-architecting around managed services typically find themselves paying more and getting less than the platform is capable of delivering.

What is often underestimated is how much GCP’s strength in AI and data depends on the quality of the underlying data architecture. Vertex AI and Gemini Enterprise are genuinely capable platforms, but they amplify good data engineering and expose poor data engineering with equal efficiency. Organisations that invest in a well-structured BigQuery data model, clear data governance policies, and automated pipeline tooling before deploying ML workloads consistently see faster time to value from the AI layer. Those that skip that foundation find themselves debugging data quality issues at the model layer, which is a slow and expensive place to discover them.

The agentic AI direction Google is pursuing with Gemini Enterprise is worth taking seriously as a planning consideration, not just a marketing claim. Building AI agents that act inside business workflows requires clean, accessible, well-governed data. That is a data engineering problem before it is an AI problem, and GCP’s integrated stack from Cloud Storage through BigQuery to Vertex AI is designed to support exactly that progression.

SST Cloud’s GCP services for Australian organisations

For Australian organisations ready to move beyond evaluation and into production, SST Cloud provides the full spectrum of cloud transformation services needed to deploy GCP effectively: cloud strategy and architecture, migration execution, platform engineering, and ongoing managed operations. The difference between a GCP deployment that delivers measurable business outcomes and one that accumulates technical debt is almost always in the design and governance decisions made in the first few weeks.

SST Cloud’s data and AI engineering practice covers BigQuery warehouse design, Vertex AI pipeline development, and agentic AI implementations on GCP’s integrated stack. For organisations building AI capabilities on top of fragmented or legacy data systems, SST Cloud also offers structured data unification engagements that establish the foundation before the AI layer is introduced. Whether your starting point is a greenfield GCP pilot, a migration from on-premises infrastructure, or a modernisation of an existing cloud environment, SST Cloud offers a structured assessment to scope the work and identify the highest-value starting point. Contact SST Cloud to book a cloud readiness assessment.

Useful resources and documentation

Official Google Cloud product documentation and quickstarts:

• Google Cloud products overview — full catalogue of GCP services with links to product documentation and quickstarts

• Google Cloud homepage and free trial — start here to claim the $300 free trial credit and access the Cloud Console

• Cloud Storage documentation and pricing — product reference for object storage, including storage classes and lifecycle policy configuration

• Cloud Storage pricing — detailed pricing for Nearline, Coldline, Archive classes and egress rates

• GCP terms and services (Resource Manager and Gemini references) — covers Resource Manager hierarchy guidance and Gemini Enterprise service terms

• Google Cloud documentation portal — architecture guides, migration patterns, and the gcloud CLI reference

GCP service catalogue reference:

• GCP services catalogue — third-party catalogue of GCP SKUs useful for understanding the full scope of available services

SST Cloud resources:

• SST Cloud insights and thought leadership — articles on cloud architecture, data engineering, AI, and platform engineering from the SST Cloud team

• Why cloud migration projects fail before they begin — practical guidance on the organisational and planning pitfalls that derail migrations

• Building agentic AI systems on enterprise data — how to move from static ML models to operational AI agents on platforms like GCP

Recommended

• Building a Secure AWS Landing Zone - My Framer Site