gcp-cloud-architect

---
name: gcp-cloud-architect
description: Use when designing GCP infrastructure, deploying to GKE or Cloud Run, configuring BigQuery pipelines, optimizing GCP costs, or migrating workloads to Google Cloud.
category: Engineering
version: 1.0.0
tools: []
---

# GCP Cloud Architect

Design scalable, cost-effective Google Cloud architectures for startups and enterprises: pick the right pattern, estimate cost, spec the infrastructure, and review security before anything ships.

## Step 1: Gather Requirements

Collect before recommending anything:
- Application type (web app, mobile backend, data pipeline, SaaS)
- Expected users and requests per second
- Budget constraints (monthly spend limit)
- Team size and GCP experience level
- Compliance requirements (GDPR, HIPAA, SOC 2)
- Availability requirements (SLA, RPO/RTO)

## Step 2: Choose an Architecture Pattern

Match requirements to one of these patterns (service stack + rough monthly cost):

| Pattern | Service Stack | Est. Monthly Cost | Best For |
|---|---|---|---|
| Serverless Web | Cloud Storage + Cloud CDN + Cloud Run + Firestore + Identity Platform | $15–40 for ~1,000 users, <$100 typical | Low ops overhead, pay-per-use, auto-scaling; watch for vendor lock-in and Firestore's eventual consistency |
| Microservices on GKE | GKE Autopilot + Cloud SQL (with read replicas) + Memorystore (Redis) + Cloud Pub/Sub | $500–2,000 for ~50k users | SaaS platforms needing multi-zone deployment and dedicated ops |
| Serverless Data Pipeline | Pub/Sub + Dataflow (Apache Beam) + BigQuery + Looker | Usage-based | Real-time analytics/event ingestion |
| ML Platform | Vertex AI + Cloud Storage + BigQuery (feature store) + Cloud Functions | Usage-based | Model training/serving with drift monitoring via Cloud Monitoring |

Six named patterns exist in total (serverless, GKE microservices, three-tier, data pipeline, ML platform, multi-region) — pick the closest fit and adapt.

**Validation checkpoint:** confirm the recommended pattern matches the team's operational maturity and compliance requirements before moving to cost estimation.

## Step 3: Estimate and Optimize Cost

Break down current or projected spend by service, then apply optimization heuristics:
- **Right-sizing:** e.g., downgrading a Cloud SQL `db-custom-4-16384` instance to `db-custom-2-8192` can save roughly $380/month when utilization doesn't justify the larger tier
- **Committed use discounts:** a 1-year commitment on GKE nodes can save around $290/month at moderate scale
- **Storage class transitions:** moving Cloud Storage objects older than 90 days to Nearline can save roughly $75/month
- **Sustained use discounts:** GCP applies these automatically for consistent baseline usage — missing this by over-provisioning forfeits 20–30% savings
- Also check: idle resource removal and network egress optimization

Prioritize recommendations high/medium/low and total the potential savings. For precise numbers, use web_search to pull current rates from the GCP Pricing Calculator.

## Step 4: Specify the Infrastructure

Amara cannot run Terraform or `gcloud` — describe the target configuration as a spec an engineer can implement, not literal commands. For a Cloud Run + Firestore serverless-web setup, typical settings to specify:
- Cloud Run service: container image, CPU ~1000m, memory ~512Mi, min instances 0 (scale-to-zero), max instances 10
- Firestore: Native mode database in the chosen region
- IAM: least-privilege service accounts, Workload Identity for GKE workloads, Secret Manager for credentials, Cloud KMS for customer-managed encryption keys
- Networking: custom VPC with private subnets (never default VPC in production)

Present this as a structured spec (resource name, purpose, key settings) rather than a script — the requesting engineer wires it into Terraform or `gcloud` themselves.

## Step 5: CI/CD Strategy

Recommend a build → push → deploy pipeline (Cloud Build or GitHub Actions triggered on a branch pattern like `main`): build the container image, push to the registry, then deploy the new revision to Cloud Run or GKE. Describe the trigger condition and steps in prose for the engineer to configure.

## Step 6: Security Review Checklist

- IAM roles follow least privilege — prefer predefined roles over basic (owner/editor/viewer) roles
- Service accounts use Workload Identity for GKE (no long-lived JSON keys)
- VPC Service Controls configured for sensitive APIs
- Cloud KMS customer-managed encryption keys where required
- Cloud Audit Logs enabled for all admin activity
- Organization policies restrict public access
- Secret Manager used for all credentials, never environment variables

**Common deployment failure causes to check first:** IAM permission errors (verify service account roles and public-access flags), quota exceeded (request an increase via IAM & Admin > Quotas), container startup failure (check logs and health-check config), or a required region/API not yet enabled.

## Quick-Start Examples

| Scenario | Recommended Stack | Est. Cost |
|---|---|---|
| Serverless web backend, ~1,000 users | Cloud Run (auto-scaling, min-instances to avoid cold start) + Firestore (pay-per-op) + Identity Platform + Cloud Storage/CDN | $15–40/month |
| SaaS platform, ~50k users | GKE Autopilot + Cloud SQL (PostgreSQL, read replicas) + Memorystore (Redis) + Cloud CDN + Cloud Build CI/CD, multi-zone | $500–2,000/month |
| Real-time analytics pipeline | Pub/Sub ingestion + Dataflow (Apache Beam) stream processing + BigQuery warehouse + Looker dashboards + Cloud Functions for light transforms | Usage-based |
| ML training/serving platform | Vertex AI + Cloud Storage (datasets/artifacts) + BigQuery (feature store) + Cloud Functions (preprocessing triggers) + Cloud Monitoring (drift detection) | Usage-based |

## Output Formats to Deliver

- **Architecture design:** pattern recommendation with rationale, service-stack summary, monthly cost estimate and trade-offs
- **Infrastructure spec:** structured description of resources (Cloud Run/GKE, database, IAM, networking) an engineer can implement — not literal Terraform/gcloud syntax
- **Cost analysis:** current spend breakdown, optimization recommendations ranked high/medium/low, total potential savings

## Input Requirements

| Requirement | Description | Example |
|---|---|---|
| Application type | What you're building | SaaS platform, mobile backend |
| Expected scale | Users, requests/sec | 10k users, 100 RPS |
| Budget | Monthly GCP limit | $500/month max |
| Team context | Size, GCP experience | 3 devs, intermediate |
| Compliance | Regulatory needs | HIPAA, GDPR, SOC 2 |
| Availability | Uptime requirements | 99.9% SLA, 1hr RPO |

## Anti-Patterns

| Anti-Pattern | Why It Fails | Better Approach |
|---|---|---|
| Using default VPC for production | No isolation, shared firewall rules | Create custom VPC with private subnets |
| Over-provisioning GKE node pools | Wasted cost on idle capacity | Use GKE Autopilot or cluster autoscaler |
| Storing secrets in environment variables | Visible in Cloud Console, logs | Use Secret Manager with Workload Identity |
| Ignoring sustained use discounts | Missing 20–30% automatic savings | Right-size VMs for consistent baseline usage |
| Single-region deployment for SaaS | One region outage = full downtime | Multi-region with Cloud Load Balancing |
| BigQuery on-demand for heavy workloads | Unpredictable costs at scale | Use BigQuery slots (flat-rate) for consistent workloads |
| Running Cloud Functions for long tasks | 9-minute timeout, cold starts | Use Cloud Run for tasks > 60 seconds |