Designing and planning a cloud solution architecture

Turning requirements into a design

Business requirements

• Business use case and strategy decide the shape: a company that wants to grow into new markets needs elasticity and global reach, one that wants to leave a data centre by a lease date needs a migration plan with a deadline.
• Functional requirements say what the system does (ingest claims, recommend products). Non-functional requirements say how well: availability, latency, throughput, durability, security, compliance, cost, operability. Exam trap: the answer that satisfies the function but ignores a stated non-functional requirement (for example, 99.9% availability, or data staying in the EU).
• Success measures: tie every goal to a KPI (conversion rate, order-to-ship time, p95 latency), an ROI or total cost of ownership figure, and a metric you can actually collect. A design that cannot be measured cannot show success.
• Trade-offs: cost against availability, latency against consistency, speed of delivery against optimal design, build against buy. Pick the option that meets the stated requirement at the lowest cost and operational effort. Over-engineering (multi-region active-active for a 99.9% target) is as wrong as under-engineering.
• Business continuity plan: what must keep running, for how long, and who does what. It produces the RTO and RPO targets that drive the DR design.
• Cost optimization as a design input: decide early between CapEx-style commitments (committed use discounts) and pay-as-you-go, and design for scale to zero where traffic is spiky.

Workload disposition

For each application decide what to do with it:

Integration patterns with external systems

• Asynchronous messaging: Pub/Sub decouples producers and consumers and absorbs spikes. Use it between systems owned by different teams or companies.
• API-based: expose and protect partner interfaces with Apigee (or API Gateway for simple cases); Cloud Endpoints is older.
• File-based: SFTP and batch ETL remain common. Land files in Cloud Storage (Storage Transfer Service for scheduled pulls), process with Dataflow or Cloud Run jobs, and orchestrate with Cloud Composer or Workflows.
• Change data capture: Datastream streams database changes into BigQuery or Cloud Storage.
• Event-driven: Eventarc routes events to Cloud Run and Run functions.
• Private connectivity to partners: Private Service Connect, VPN or Interconnect, never public IPs when a private path exists.

Moving data

Rule of thumb: if the link can move the data in a couple of weeks, use online transfer. If it would take months, use Transfer Appliance.

Technical requirements

The Well-Architected Framework

The exam guide names the pillars: operational excellence, security (privacy and compliance), reliability, cost optimization, performance optimization, and sustainability as a cross-cutting concern (regions with low carbon footprint, right-sizing, serverless). Questions use the pillars as tie-breakers. A recommendation such as “automate everything”, “design for failure”, “least privilege” and “measure and right-size” is usually the intended answer.

Availability and fail-over

• Zone is a failure domain inside a region. Regional resources (regional MIGs, regional GKE clusters, regional Cloud SQL HA, regional Persistent Disk) survive a zone loss. Multi-region services (Spanner multi-region, multi-region Cloud Storage and BigQuery, global load balancing) survive a region loss.
• Compute Engine: regional managed instance groups with autohealing (health check) and autoscaling, behind a load balancer. Live migration keeps VMs running through host maintenance.
• GKE: regional clusters spread control plane and nodes across three zones. Use Pod disruption budgets, readiness probes, and multi-cluster Gateway or Multi Cluster Services for cross-cluster fail-over.
• Cloud SQL HA uses a standby in another zone of the same region with automatic fail-over (a few minutes). Cross-region replicas are for read scaling and manual DR promotion. AlloyDB has regional HA and cross-region replicas. Spanner gives 99.99% (regional) or 99.999% (multi-region) availability. Bigtable replicates across clusters with app profiles for routing.
• Load balancing is where fail-over happens: global external Application Load Balancer health-checks backends in multiple regions and steers users to the closest healthy one.
• 99.9% availability is about 8.8 hours a year of downtime; 99.99% is about 53 minutes. Composite availability is the product of the tiers in series, so a design with many serial dependencies is less available than its weakest part.

Disaster recovery

Pick the cheapest pattern that meets the stated RTO (time to recover) and RPO (data you may lose). RPO near zero needs synchronous or very low-lag replication (Spanner multi-region, Cloud Storage dual or multi-region with turbo replication, AlloyDB cross-region). Always test the plan.

Scalability, flexibility, performance

• Scale out (more instances) beats scale up for resilience. Autoscalers: MIG (CPU, load balancing capacity, Cloud Monitoring metrics, schedules), GKE (HPA, VPA, cluster autoscaler or Autopilot, node auto-provisioning), Cloud Run (concurrency-driven, scale to zero).
• Latency: put content near users with Cloud CDN, use Premium Tier network for global traffic over Google’s backbone, cache with Memorystore, place compute near the data, and use read replicas.
• Flexibility of resources: custom machine types, resizeable disks, committed use discounts that are flexible (spend based) rather than tied to one shape, and managed services that scale without re-architecture.

Backup and recovery

• Cloud SQL automated backups plus point-in-time recovery (needs binary logging or WAL). Spanner backups and PITR, Bigtable backups, Firestore scheduled backups, Filestore backups, Persistent Disk snapshots (incremental) and the Backup and DR Service for VMs, databases and file systems with immutable vaults.
• Cloud Storage: object versioning, soft delete, Bucket Lock / retention policies for WORM requirements, dual or multi-region for durability across regions.
• Ransomware or accidental deletion are covered by immutable or separate-project backups, not by replication, because replication copies the damage.

Gemini Cloud Assist

An AI assistant inside the console that helps design and troubleshoot: it can propose architectures, generate Terraform and gcloud commands, explain errors, and analyse logs and metrics for root cause. Treat it as a helper for design and operations, not as a replacement for the decisions you must justify.

Network design

• VPC networks are global; subnets are regional. Custom mode is the production default (auto mode creates a subnet in every region with fixed ranges that can collide on-premises).
• Shared VPC: a host project owns the network; service projects use its subnets. Central network team, delegated app teams. Best for one organization with separation of duties.
• VPC Network Peering: private connection between two VPCs, not transitive, no overlapping ranges. Use for a handful of networks. For many networks, hub and spoke or transit use Network Connectivity Center, or publish a service with Private Service Connect (PSC), which needs no range coordination and is one-directional (consumer connects to producer).
• Private Google Access reaches Google APIs from VMs without external IPs; Cloud NAT gives those VMs outbound internet; PSC endpoints for Google APIs give a private IP for the APIs, which on-premises hosts can reach through hybrid links.
• Firewalls: VPC firewall rules (stateful, targeted by tag or service account), network firewall policies and hierarchical firewall policies set at organization or folder level.
• Routing: dynamic routing mode (regional or global) controls which regions learn on-premises routes from Cloud Router BGP.

Load balancer selection

Container networking

GKE uses VPC-native clusters (alias IP ranges for pods and services). Plan secondary ranges generously. Use Dataplane V2 (eBPF, built-in network policy), Gateway API for ingress and multi-cluster traffic, private clusters (nodes without external IPs, control plane reachable by authorised networks or PSC), and Cloud Service Mesh for mTLS and traffic management across clusters.

On-premises and multicloud integration

Pick VPN for fast, low-cost or backup connectivity, Interconnect for high volume and consistent performance. For 99.99% with Interconnect you need redundant connections in two metros; for 99.9%, two connections in one metro. Use VPN as backup for a single Interconnect. Hybrid compute: GKE Enterprise (Anthos) and Google Distributed Cloud run consistent Kubernetes on premises, which suits the Altostrat requirement for Kubernetes both on-premises and in the cloud, managed centrally with fleets and Config Sync.

Storage and database choice

Decision table

Traps: Cloud SQL does not scale writes horizontally and is regional. Spanner is the answer when the scenario needs relational plus global scale plus strong consistency. Bigtable is not relational and has no secondary indexes. BigQuery is not for low-latency transactional work.

Cloud Storage classes

Autoclass moves objects between classes automatically by access pattern (good when access is unpredictable, as for a growing media library). Object Lifecycle Management moves or deletes by age or conditions. Location type: regional (cheapest, low latency), dual-region (two chosen regions; default replication targets 1 hour RPO, turbo replication targets 15 minutes), multi-region (US, EU or ASIA, geo-redundant). Latency-sensitive compute should sit in the same region as the bucket.

Compute choice

Compute Engine options: custom machine types (exact vCPU and memory when predefined shapes waste money), Spot VMs (60 to 91% cheaper, can be reclaimed any time with a 30 second notice, no maximum run time, for fault-tolerant batch, CI, rendering), sole-tenant nodes (licensing and isolation), Confidential VMs (memory encryption), accelerator-optimized machines (GPUs such as A3, G2; TPUs for large ML), memory-optimized (M series for SAP HANA), compute-optimized (C series, H3 for HPC). Discounts: sustained use discounts are automatic on eligible machine types; committed use discounts (1 or 3 years, resource-based or flexible spend-based) for steady baselines; Spot for the rest.

Data processing

Google Cloud AI and ML solutions

• Gemini models (text, image, audio, video, code) are served through the Agent Platform (Vertex AI) and the Gemini API. Pick a smaller, faster model (Flash tiers) for cost and latency, a larger model (Pro tier) for harder reasoning.
• Agent Builder builds search, conversational and agent applications grounded in your own data (RAG), with connectors, and Vertex AI Search for enterprise search and Discovery AI (Search for commerce) for product discovery.
• Model Garden is the catalog of Google, partner and open models you can deploy or call.
• AI Hypercomputer is Google’s integrated stack of hardware (GPUs, TPUs), storage, networking and software for training and serving large models.
• Grounding and RAG reduce hallucination; tuning adapts a model; evaluation checks quality; human-in-the-loop review fits risky output such as generated catalogue content.
• Prebuilt APIs (Vision, Speech-to-Text, Text-to-Speech, Translation, Natural Language, Video Intelligence, Document AI) beat a custom model whenever the task is standard.

Migration plan

A migration plan names inventory, dependencies, target design, order, testing, cutover and rollback.

1. Assess: Migration Center discovers assets, shows dependencies, estimates cost and recommends target services.
2. Plan: group servers into waves by dependency, size the network (an Interconnect or VPN before the first wave), decide landing zone (resource hierarchy, IAM, networking, logging).
3. Migrate: VMs with Migrate to Virtual Machines (replicate while the source runs, test clones, cut over), databases with DMS, data with Storage Transfer Service or Transfer Appliance, containers with Migrate to Containers.
4. Validate: functional, performance and load tests on the target, then run a pilot.
5. Cut over and optimise: DNS switch, rollback ready, then right-size.

Also consider:

• Dependencies that prevent moving a single server (shared database, latency-sensitive link). Move them together or keep a stretched network.
• Licensing: bring your own licence to sole-tenant nodes, or pay for Windows and SQL Server licences included in the VM price. Licence-driven choices change cost. BYOL needs sole tenancy for some products.
• Financial impact: double running costs during parallel run, egress, committed use planning, retiring the data centre lease. Compare TCO, not only compute price.

Future improvements

Design so that new capability can be adopted without a rewrite: managed services with API compatibility, infrastructure as code, decoupled components, regular reviews of new features (for example a switch from self-managed to AlloyDB, or from batch to streaming). Expect business needs to change: new regions, new regulation, acquisitions. Cloud-first means choosing managed and cloud-native by default, and justifying exceptions.

The case studies

The current exam draws on four case studies. Know each one’s constraints.