gcp-cloud-architect

What this skill does

# GCP Cloud Architect

End-to-end GCP-specific architecture: service selection, Google Cloud Architecture Framework assessment, identity and networking patterns, cost optimization, operational defaults. Provider-specific complement to our generic `senior-cloud-architect` skill — that one covers cross-cloud patterns; this one knows when to pick Spanner over Cloud SQL, how Workload Identity Federation differs from Service Account keys, and the right Cloud Run vs GKE call.

---

## When to use this skill

| Situation | Skill applies |
|-----------|---------------|
| Designing a GCP architecture from scratch | Yes — start with **compute decision tree** |
| Reviewing an existing GCP architecture | Yes — run **CAF assessment** via `scripts/gcp_caf_scorer.py` |
| Validating a Terraform / Deployment Manager plan | Yes — `scripts/gcp_architecture_validator.py` |
| Estimating GCP cost for a workload | Yes — `scripts/gcp_cost_estimator.py` |
| Picking between GKE / Cloud Run / Functions / Cloud Run Jobs | Yes — see **compute decision tree** |
| Setting up IAM / Workload Identity correctly | Yes — see **identity reference** |
| Designing multi-region / multi-zone resilience | Yes — see **reliability reference** |
| Picking Cloud SQL vs Spanner vs Firestore vs BigQuery | Yes — see **data store decision tree** |
| Going to production without CAF review | Don't — run the CAF scorer first |

---

## Compute decision tree

GCP gives you many compute paths; picking the wrong one wastes money and operational burden.

```
Stateless HTTP service?
├── Need full control over OS / sidecar / custom runtime?
│   └── → GKE (Autopilot for managed; Standard for full control)
├── Container-packaged service, want zero infra?
│   ├── Auto-scale to zero acceptable? Per-request billing?
│   │   └── → Cloud Run (Service)
│   └── Long-running container (always-warm)?
│       └── → Cloud Run with min-instances OR GKE Autopilot
├── Function-style, event-driven?
│   └── → Cloud Functions (2nd gen, runs on Cloud Run under the hood)
├── Batch / job processing?
│   ├── Containers, finite duration?
│   │   └── → Cloud Run Jobs
│   ├── Large-scale batch (HPC)?
│   │   └── → Batch (compute engine pool) OR Dataflow (for data)
└── Long-running stateful processes / legacy?
    └── → Compute Engine VMs (MIGs for groups)

Stateful service (DBs you self-manage)?
├── → Generally prefer managed: Cloud SQL, Spanner, Firestore, BigQuery
└── Or VM + your own DB (rarely the right call)

ML inference?
├── Realtime, GPU?
│   └── → GKE (GPU node pools) OR Vertex AI online endpoints
└── Batch?
    └── → Vertex AI batch prediction OR Dataflow pipelines

Static frontend?
└── → Firebase Hosting OR Cloud Storage + Cloud CDN

API gateway?
├── In-VPC, internal-only?
│   └── → Internal HTTP(S) Load Balancer
├── Global edge, custom routing, WAF?
│   └── → External HTTP(S) Load Balancer + Cloud Armor
├── API management (rate limit, dev portal, monetization)?
│   └── → Apigee
```

See [references/gcp-services-reference.md](references/gcp-services-reference.md) for service-by-service depth: tiers, SLAs, limits, when to upgrade.

---

## Data store decision tree

```
Relational?
├── Standard OLTP, regional or multi-zone?
│   └── → Cloud SQL (MySQL / PostgreSQL / SQL Server)
├── Global, strong consistency, horizontal scale?
│   └── → Cloud Spanner (regional or multi-region)
├── Multi-region with high concurrency, fault-tolerant?
│   └── → Cloud Spanner (true multi-region active-active)

Document / NoSQL?
├── Mobile/web client-direct, real-time updates?
│   └── → Firestore (Native mode)
├── Schemaless, low-latency, regional or multi-region?
│   └── → Firestore OR Datastore (legacy Datastore Mode of Firestore)
├── Wide-column at massive scale, < 10ms reads?
│   └── → Bigtable

Key-value cache?
└── → Memorystore (Redis or Memcached)

Object storage?
└── → Cloud Storage (pick Standard / Nearline / Coldline / Archive)

Time-series / metrics?
├── Operational (Stackdriver-style)?
│   └── → Cloud Monitoring (built-in metric store)
├── Application time series?
│   └── → Bigtable OR BigQuery (depending on cardinality/query pattern)

Search?
├── Full-text on app data?
│   └── → Vertex AI Search OR self-managed Elasticsearch on GKE
└── Vector search for ML?
    └── → Vertex AI Vector Search OR pgvector on Cloud SQL OR Bigtable with vectors

Data warehouse?
└── → BigQuery (the answer to "should we use a warehouse?" on GCP)

Analytical OLAP?
└── → BigQuery (serverless) OR BigQuery + BigQuery BI Engine

Stream processing?
└── → Dataflow (Apache Beam) OR Pub/Sub + Dataflow
```

---

## Networking patterns

### Three core building blocks

| Component | What it does | When |
|-----------|--------------|------|
| **VPC** | L3 isolation; private IP space; global by default in GCP | Every non-trivial GCP deployment |
| **Private Service Connect (PSC)** | Brings managed services into your VPC privately | Default for production access to managed services |
| **Cloud Interconnect / VPN** | On-prem connectivity (Interconnect is dedicated; VPN is over internet) | Hybrid setups |

### Load balancers

| LB | When |
|----|------|
| **Global External HTTP(S) Load Balancer** | Global anycast; Cloud Armor; CDN; serverless backends |
| **Regional External HTTP(S) LB** | Regional only; cheaper for non-global workloads |
| **Internal HTTP(S) LB** | Internal services; supports serverless backends |
| **TCP/UDP Network LB** | L4 load balancing; lower cost; for non-HTTP workloads |
| **Internal TCP/UDP LB** | Internal L4 |

### Common networking patterns

| Pattern | What | When |
|---------|------|------|
| **Shared VPC** | Central host project owns VPC; service projects attach their resources | Enterprise / multi-team |
| **VPC peering** | Connect two VPCs (transitive routing not supported) | Multi-project organizations |
| **Private Service Connect** | Consumer endpoint in your VPC → producer service | Default for managed services |
| **Cloud Armor + global LB** | DDoS protection + WAF rules at the edge | Public-facing apps |
| **Hub-and-spoke via Network Connectivity Center** | Centralized routing for multi-VPC orgs | Large orgs |

---

## Identity patterns

### IAM, Service Accounts, Workload Identity Federation

| Concept | Use |
|---------|-----|
| **Cloud IAM** | Role-based access control for users, groups, service accounts |
| **Service Account (SA)** | Identity for an app or workload |
| **Service Account Key** | Static credential for SA — avoid in modern setups |
| **Workload Identity Federation** | Federated identity; on-prem / other-cloud workloads get GCP access without keys |
| **Workload Identity (GKE)** | K8s service accounts mapped to GCP SAs; no key mounting in pods |
| **Application Default Credentials (ADC)** | Standard library for auth; uses ambient credentials |

### Choosing identity

```
Workload running on GCP that calls other GCP services?
├── On GKE → GKE Workload Identity (KSA → GSA)
├── On Cloud Run / Functions → service identity (built-in)
├── On Compute Engine → instance service account
└── In a CI/CD pipeline outside GCP → Workload Identity Federation (no keys)

Workload outside GCP needing GCP access?
├── From AWS / Azure / OIDC provider → Workload Identity Federation
└── Last resort → Service Account key (rotate frequently)

User-facing auth?
└── Identity Platform (GCP's auth-as-a-service; or Firebase Auth for client-direct)
```

### Least-privilege IAM

GCP supports three forms:
- **Predefined roles** (e.g., `roles/storage.objectViewer`) — preferred
- **Custom roles** at organization or project — when predefined doesn't fit
- **Basic roles** (`owner`, `editor`, `viewer`) — too broad; avoid in production

Bind roles at the most specific scope:
- Resource → preferred
- Project → standard for project-scoped apps
- Folder → for organizational sub-tree
- Organization → only org-wide admins

---

## Google Cloud Architecture Framework (CAF)

GCP's framework has five pillars (same naming families as Azure/AWS but with Google fla