Google Cloud Well-Architected Review: [Workload name]
Review workbook for one workload running on Google Cloud, organised on the six pillars of the Google Cloud Well-Architected Framework (Operational excellence; Security, privacy, and compliance; Reliability; Cost optimization; Performance optimization; Sustainability) and its cross-pillar perspectives (AI and ML; Financial services), as published on Google Cloud documentation (framework page last updated 13 October 2026). For each pillar it records the core principles, original review questions mapped to those principles, current state, evidence and a rating. It also covers the framework's system design principles, the selected perspectives, pillar trade-offs, a risk register (high and medium risk), an improvement plan and a dated re-review baseline. Replace every [bracketed] value and every row marked Example.
Document control
| Field | Value |
|---|
| Document ID | [GCR-ANALYTICS-2026-01] |
| Workload | [Customer analytics platform] |
| Organization, folder and projects | [org: example.com, folder: analytics-prod, projects: ana-prod-app, ana-prod-data] |
| Regions and zones | [europe-west1 primary (three zones), europe-west4 recovery] |
| Review type | [Initial / Periodic / Pre-launch / After major incident / Perspective deep dive] |
| Perspectives applied | [AI and ML, Financial services, none] |
| Framework pages checked on | YYYY-MM-DD |
| Review date | YYYY-MM-DD |
| Version | [0.1] |
| Status | [Draft / In review / Approved] |
| Owner (workload owner) | [@workload-owner] |
| Lead reviewer | [@lead-reviewer] |
| Approvers/reviewers | [@engineering-manager], [@security-lead], [@platform-lead], [@finops-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Next review | YYYY-MM-DD |
Approvals
| Role | Name | Decision | Date |
|---|
| Workload owner | [@name] | [Accepted plan / Changes requested] | YYYY-MM-DD |
| Lead reviewer (cloud architect) | [@name] | [Decision] | YYYY-MM-DD |
| Security and privacy representative | [@name] | [Decision] | YYYY-MM-DD |
| Platform team (foundation owner) | [@name] | [Decision] | YYYY-MM-DD |
| FinOps representative | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | Pre-review questionnaire filled by the workload team |
| 0.2 | YYYY-MM-DD | [@name] | Example: Ratings after review session; 4 High, 10 Medium; baseline B-001 recorded |
| 1.0 | YYYY-MM-DD | [@name] | Example: Improvement plan approved |
| 1.1 | YYYY-MM-DD | [@name] | Example: Re-review; 1 High, 5 Medium; baseline B-002 recorded |
Contents
1. Review scope and method
1.1 Scope
| In scope | Out of scope |
|---|
| Example: Ingestion on Pub/Sub and Dataflow, BigQuery datasets, Cloud Run APIs, Vertex AI scoring endpoint, CI/CD with Cloud Build | Shared VPC host project, Cloud Interconnect and organisation policies (platform team, reviewed against the Landing zone design, architecture/landing-zone-design) |
| Example: Development and staging projects where they affect release safety | Cloud Identity and workforce identity federation configuration |
| [Item] | [Item] |
1.2 Method
- The workload team fills sections 2 and 3 and pre-fills sections 4 to 11 with links to evidence (Active Assist recommendations, Security Command Center findings, Cloud Monitoring dashboards, billing export, Carbon Footprint report).
- The lead reviewer runs a session of [half a day] with the workload owner, an operating engineer, security and privacy, the platform team and FinOps.
- Each question gets a current state, evidence and a rating. High and Medium findings go to section 12 and actions to section 13.
- The reviewer records a dated baseline (section 14). The next cycle compares against it.
1.3 Rating scale and identifiers
| Rating | Meaning | Expected response |
|---|
| High risk | Gap that can plausibly cause serious customer, financial, security, privacy or compliance impact within 12 months | Action this quarter, or signed acceptance |
| Medium risk | Gap that raises impact or effort but is unlikely to cause a severe event alone | Action within two quarters |
| None | Practice in place with evidence | No action |
| Not applicable | Does not apply, with a stated reason | Reason recorded |
Questions use GCR-[pillar]-NN (SYS for system design, OPS, SEC, REL, COST, PERF, SUS) and GCR-AIML-NN or GCR-FS-NN for perspectives. The column "Core principle" names the Google principle the question tests. Findings use FND-NNN, actions ACT-NNN, acceptances RA-NNN and baselines B-NNN.
2. Workload definition
2.1 Business context
| Item | Value |
|---|
| Purpose | Example: Ingests customer events, builds daily segments and serves a real-time propensity score to the marketing site |
| Users and consumers | Example: 60 analysts, 3 downstream applications, 5 million scored requests per day |
| Business criticality | Example: High for scoring API (revenue-affecting), medium for batch segments |
| Regulatory and privacy context | Example: Personal data of EU customers; consent signals must be honoured; financial promotion rules |
| Resource hierarchy | Example: Organisation, environment folders, one project per layer, Shared VPC |
| Change frequency | Example: Daily deploys for APIs, weekly for pipelines |
| Architecture link | [Data platform architecture, architecture/data-platform-architecture] |
2.2 User journeys and targets
| Journey ID | Journey | Target (SLO) | Error budget policy | RTO | RPO |
|---|
| UJ-01 (Example) | Website requests a propensity score | 99.9% of requests under 200 ms over 28 days | Freeze feature releases when 75% consumed | 30 minutes | Not applicable (stateless) |
| UJ-02 (Example) | Analyst queries yesterday's segments by 08:00 | 99% of days | Postmortem on any miss | 4 hours | 1 hour |
| UJ-03 (Example) | Events visible in BigQuery within 10 minutes | 99.5% of minutes | Page on-call when burn rate exceeds 10x | 2 hours | 5 minutes |
| [UJ-NN] | [Journey] | [SLO] | [Policy] | [RTO] | [RPO] |
Keep the full SLO definitions in the SLO document (dev/slo-doc).
2.3 Architecture summary
| Layer | Services and configuration |
|---|
| Ingress | Example: Global external Application Load Balancer, Cloud Armor policy |
| Compute | Example: Cloud Run services (regional), Dataflow streaming job |
| Data | Example: Pub/Sub, BigQuery (multi-region EU dataset), Cloud Storage with lifecycle rules, Memorystore |
| AI and ML | Example: Vertex AI online prediction endpoint, model registry |
| Identity and security | Example: Service accounts per service, Workload Identity Federation for CI, Secret Manager, Cloud KMS, VPC Service Controls perimeter |
| Observability | Example: Cloud Monitoring, Cloud Logging with log buckets per environment, Cloud Trace |
3. Framework, perspectives and tools
3.1 Framework structure
The Google Cloud Well-Architected Framework consists of system design principles, six pillars and cross-pillar perspectives. Each pillar is organised as a set of core principles with recommendations. A perspective gives a cross-pillar view for a technology or industry. On 13 October 2026 Google added per-pillar agent skills (named google-cloud-waf- plus the pillar, hosted in the google/skills repository) that contain assessment questions and a validation checklist.
| Element | Name | Page last updated |
|---|
| Pillar | Operational excellence | [YYYY-MM-DD] |
| Pillar | Security, privacy, and compliance | [YYYY-MM-DD] |
| Pillar | Reliability | [YYYY-MM-DD] |
| Pillar | Cost optimization | [YYYY-MM-DD] |
| Pillar | Performance optimization | [YYYY-MM-DD] |
| Pillar | Sustainability | [YYYY-MM-DD] |
| Perspective | AI and ML | [YYYY-MM-DD] |
| Perspective | Financial services | [YYYY-MM-DD] |
3.2 Perspective selection
| Perspective | Apply? | Reason |
|---|
| AI and ML | [Yes / No] | Example: Yes: scoring endpoint serves a trained model |
| Financial services | [Yes / No] | Example: No: not a regulated financial entity |
3.3 Tools and evidence sources
| Source | Use in this review | Status |
|---|
| Well-Architected Framework agent skills | Assessment questions and validation checklist per pillar, run by an AI agent against the design | [Used / Not used, date] |
| Active Assist recommendations (Recommender) | Resource-level cost, security, performance and reliability recommendations | [Export date] |
| Security Command Center | Misconfigurations, vulnerabilities and threat findings | [Tier, findings count] |
| Cloud Monitoring, Logging and Trace | SLO compliance, alert history, latency evidence | [Dashboard link] |
| Cloud Billing export to BigQuery | Cost allocation by label and project | [Dataset] |
| Carbon Footprint | Emissions by project, region and service | [Report period] |
| Policy Intelligence and organisation policies | Evidence for inherited guardrails and IAM recommendations | [Report] |
4. System design principles
| ID | Question | Core principle | Current state | Evidence | Rating |
|---|
| GCR-SYS-01 | Can the team change a component (schema, service, region) without coordinated changes across the system, and is change tested continuously? | Design for change | [State] | [Evidence] | [Rating] |
| GCR-SYS-02 | Is the architecture documented with current diagrams and decision records that a new engineer can use? | Document your architecture | [State] | ADR (architecture/adr-full) | [Rating] |
| GCR-SYS-03 | Are fully managed services used where they meet requirements, and is each self-managed component justified? | Simplify your design and use fully managed services | [State] | [Evidence] | [Rating] |
| GCR-SYS-04 | Are components decoupled through APIs, queues or events, so that one can fail or scale without the others? | Decouple your architecture | [State] | [Evidence] | [Rating] |
| GCR-SYS-05 | Is state kept in managed stores so that compute instances can be replaced and scaled freely? | Use a stateless architecture | [State] | [Evidence] | [Rating] |
5. Operational excellence
5.1 Core principles
| Google core principle | What the reviewer looks for |
|---|
| Ensure operational readiness and performance using CloudOps | SLOs, monitoring, runbooks and capacity plans in place before launch and kept current |
| Manage incidents and problems | Clear roles and escalation, fast detection, blameless postmortems and problem tracking |
| Manage and optimize cloud resources | Resources labelled, owned, right-sized and governed through the resource hierarchy |
| Automate and manage change | Infrastructure and configuration as code, CI/CD with progressive rollout and rollback |
| Continuously improve and innovate | Regular reviews of operational metrics, experiments and adoption of new capabilities |
5.2 Review questions
| ID | Question | Core principle | Current state | Evidence | Rating |
|---|
| GCR-OPS-01 | Does every user journey in section 2.2 have an SLO in Cloud Monitoring, with burn-rate alerts? | Ensure operational readiness and performance using CloudOps | Example: SLOs documented, not configured | Monitoring console | Medium |
| GCR-OPS-02 | Are capacity needs, quotas and reservations planned for known peaks, including future reservations where capacity is scarce? | Ensure operational readiness and performance using CloudOps | [State] | Capacity plan (ops/capacity-plan) | [Rating] |
| GCR-OPS-03 | Does each alert route to an owner and link to a tested runbook? | Ensure operational readiness and performance using CloudOps | [State] | Runbook (dev/runbook) | [Rating] |
| GCR-OPS-04 | Is there an incident process with roles, severity levels and communication, and are postmortems written and their actions tracked? | Manage incidents and problems | [State] | Postmortem (dev/postmortem) | [Rating] |
| GCR-OPS-05 | Are all resources labelled for owner, environment and cost centre, and placed in the right folder and project? | Manage and optimize cloud resources | [State] | [Evidence] | [Rating] |
| GCR-OPS-06 | Is infrastructure defined as code (Terraform or Config Connector) and applied only by pipeline? | Automate and manage change | [State] | [Evidence] | [Rating] |
| GCR-OPS-07 | Do releases use progressive rollout (Cloud Run traffic splitting, canary, feature flags) with automated rollback? | Automate and manage change | [State] | Deployment runbook (ops/deployment-runbook) | [Rating] |
| GCR-OPS-08 | Are operational metrics (toil, alert volume, change failure rate) reviewed and used to plan improvements? | Continuously improve and innovate | [State] | [Evidence] | [Rating] |
6. Security, privacy, and compliance
6.1 Core principles
| Google core principle | What the reviewer looks for |
|---|
| Implement security by design | Security requirements and secure defaults set at design time, using secure foundations and blueprints |
| Implement zero trust | Every request authenticated and authorised; segmentation and exfiltration controls; no implicit network trust |
| Implement shift-left security | Security checks in code, IaC and pipelines; policy as code; supply chain integrity |
| Implement preemptive cyber defense | Threat intelligence, vulnerability management and hunting that act before an attack lands |
| Use AI securely and responsibly | AI systems protected against misuse, with governance, data controls and transparency |
| Use AI for security | AI-assisted detection, investigation and response used where it adds value under human oversight |
| Meet regulatory, compliance, and privacy needs | Obligations mapped to controls, data residency and sovereignty addressed, privacy built into data flows |
6.2 Review questions
| ID | Question | Core principle | Current state | Evidence | Rating |
|---|
| GCR-SEC-01 | Was a threat model produced at design time, and do projects start from a hardened foundation with organisation policies? | Implement security by design | [State] | Threat model (security/threat-model) | [Rating] |
| GCR-SEC-02 | Does each service run as its own service account with least privilege, and is CI authenticated by Workload Identity Federation instead of keys? | Implement zero trust | Example: Two downloaded service account keys in CI | IAM recommender, key inventory | High |
| GCR-SEC-03 | Are sensitive services inside a VPC Service Controls perimeter, with egress firewall rules that block unexpected destinations? | Implement zero trust | [State] | [Evidence] | [Rating] |
| GCR-SEC-04 | Do pipelines scan code, dependencies, containers and IaC, and is deployment restricted to verified artefacts? | Implement shift-left security | [State] | [Evidence] | [Rating] |
| GCR-SEC-05 | Are vulnerability and threat findings from Security Command Center triaged within defined times, with owners? | Implement preemptive cyber defense | [State] | [Evidence] | [Rating] |
| GCR-SEC-06 | Are model endpoints, training data and prompts protected (access control, input and output screening, data lineage)? | Use AI securely and responsibly | [State] | [Evidence] | [Rating] |
| GCR-SEC-07 | Where AI-assisted security tooling is used, are its outputs reviewed by a person before containment actions? | Use AI for security | [State] | [Evidence] | [Rating] |
| GCR-SEC-08 | Are data classified, encrypted with keys managed to the required level (Google-managed, Cloud KMS, external), and is personal data minimised? | Meet regulatory, compliance, and privacy needs | [State] | [Evidence] | [Rating] |
| GCR-SEC-09 | Are data location and residency constraints enforced by policy, and documented for auditors? | Meet regulatory, compliance, and privacy needs | [State] | Data residency assessment (compliance/data-residency-sovereignty-assessment) | [Rating] |
| GCR-SEC-10 | Are Cloud Audit Logs (including data access logs where needed) retained, protected and monitored? | Meet regulatory, compliance, and privacy needs | [State] | [Evidence] | [Rating] |
Record privacy threats in the Privacy threat model (security/privacy-threat-model) and controls in the Security architecture (security/security-architecture).
7. Reliability
7.1 Core principles
| Google core principle | What the reviewer looks for |
|---|
| Define reliability based on user-experience goals | Reliability measured at the user journey, not at component level |
| Set realistic targets for reliability | SLOs and error budgets that match business need and dependency limits |
| Build highly available systems through resource redundancy | Zonal and regional redundancy chosen per journey, with failure domains understood |
| Take advantage of horizontal scalability | Scale-out designs and autoscaling instead of larger single instances |
| Detect potential failures by using observability | Metrics, logs and traces that reveal problems before users report them |
| Design for graceful degradation | Load shedding, fallbacks and reduced functionality instead of total failure |
| Perform testing for recovery from failures | Regular failover and fault injection tests |
| Perform testing for recovery from data loss | Restores tested against RPO and RTO |
| Conduct thorough postmortems | Blameless analysis with tracked actions after every significant incident |
7.2 Review questions
| ID | Question | Core principle | Current state | Evidence | Rating |
|---|
| GCR-REL-01 | Are SLIs measured where users experience the service (load balancer or client), not only on backends? | Define reliability based on user-experience goals | [State] | [Evidence] | [Rating] |
| GCR-REL-02 | Are SLO targets consistent with the availability of the services and dependencies used, with an error budget policy that is enforced? | Set realistic targets for reliability | [State] | [Evidence] | [Rating] |
| GCR-REL-03 | Is each component deployed across zones, and is regional failure handled where the journey target requires it? | Build highly available systems through resource redundancy | Example: Memorystore instance is zonal (basic tier) | Resource configuration | High |
| GCR-REL-04 | Do services autoscale horizontally on meaningful signals, with tested limits and quotas? | Take advantage of horizontal scalability | [State] | [Evidence] | [Rating] |
| GCR-REL-05 | Do alerts detect user-impacting symptoms early, including burn-rate and dependency health? | Detect potential failures by using observability | [State] | Observability specification (ops/observability-spec) | [Rating] |
| GCR-REL-06 | When a dependency fails or load spikes, does the service shed load or serve degraded results instead of failing? | Design for graceful degradation | [State] | [Evidence] | [Rating] |
| GCR-REL-07 | Are zone and region failover tests run on a schedule, with results recorded? | Perform testing for recovery from failures | [State] | Chaos experiment (ops/chaos-experiment) | [Rating] |
| GCR-REL-08 | Are backups and BigQuery time travel or snapshots tested by restoring, within RTO and RPO? | Perform testing for recovery from data loss | [State] | Backup and restore procedure (ops/backup-restore-procedure) | [Rating] |
| GCR-REL-09 | Is the disaster recovery plan documented and exercised end to end within the past 12 months? | Perform testing for recovery from failures | [State] | Disaster recovery plan (ops/disaster-recovery-plan) | [Rating] |
| GCR-REL-10 | Is a blameless postmortem written for every incident above a severity threshold, with actions closed? | Conduct thorough postmortems | [State] | Postmortem (dev/postmortem) | [Rating] |
8. Cost optimization
8.1 Core principles
| Google core principle | What the reviewer looks for |
|---|
| Align cloud spending with business value | Spend tied to outcomes, with unit economics such as cost per scored request |
| Foster a culture of cost awareness | Engineers see and own cost; budgets and alerts reach the people who can act |
| Optimize resource usage | Right-sizing, autoscaling, the right pricing models and removal of idle resources |
| Optimize continuously | A regular FinOps cadence that revisits architecture and commitments |
8.2 Review questions
| ID | Question | Core principle | Current state | Evidence | Rating |
|---|
| GCR-COST-01 | Is a unit cost (for example cost per 1,000 scored requests or per daily segment build) calculated and trended against revenue or business volume? | Align cloud spending with business value | [State] | [Evidence] | [Rating] |
| GCR-COST-02 | Is billing exported to BigQuery and attributed by labels and projects, with less than an agreed share unallocated? | Foster a culture of cost awareness | [State] | [Evidence] | [Rating] |
| GCR-COST-03 | Are budgets and alerts set per project, sent to owners, with anomaly review? | Foster a culture of cost awareness | [State] | [Evidence] | [Rating] |
| GCR-COST-04 | Are compute and database resources right-sized from utilisation, and idle resources removed on a schedule? | Optimize resource usage | [State] | Active Assist export | [Rating] |
| GCR-COST-05 | Are committed use discounts and BigQuery editions or reservations chosen from measured steady usage, and is Spot capacity used for interruptible work? | Optimize resource usage | Example: On-demand BigQuery pricing; scans 1.4 PB per month | Billing export | Medium |
| GCR-COST-06 | Are BigQuery tables partitioned and clustered, and are queries limited by maximum bytes billed where suitable? | Optimize resource usage | [State] | [Evidence] | [Rating] |
| GCR-COST-07 | Is there a monthly cost review with engineering and finance that produces tracked actions? | Optimize continuously | [State] | FinOps cost review (ops/finops-cost-review) | [Rating] |
9. Performance optimization
9.1 Core principles
| Google core principle | What the reviewer looks for |
|---|
| Plan resource allocation | Performance requirements defined and resources selected and sized from them |
| Take advantage of elasticity | Autoscaling and serverless options that follow demand |
| Promote modular design | Components that can be scaled and optimised independently |
| Continuously monitor and improve performance | Performance metrics, profiling, load tests and a backlog of improvements |
9.2 Review questions
| ID | Question | Core principle | Current state | Evidence | Rating |
|---|
| GCR-PERF-01 | Are latency and throughput requirements written per journey, and were machine types, tiers and regions chosen from them? | Plan resource allocation | [State] | [Evidence] | [Rating] |
| GCR-PERF-02 | Are accelerators and specialised machine families used only where benchmarks justify them? | Plan resource allocation | [State] | [Evidence] | [Rating] |
| GCR-PERF-03 | Do services scale on demand (Cloud Run concurrency, managed instance group autoscaling, Dataflow autoscaling), with minimum instances set for latency-sensitive paths? | Take advantage of elasticity | [State] | [Evidence] | [Rating] |
| GCR-PERF-04 | Can each component be scaled or replaced without redesigning the others? | Promote modular design | [State] | [Evidence] | [Rating] |
| GCR-PERF-05 | Is caching used at the right layers (Cloud CDN, Memorystore, BigQuery BI Engine) with measured hit rates? | Promote modular design | [State] | [Evidence] | [Rating] |
| GCR-PERF-06 | Are load tests and profiling (Cloud Profiler, Cloud Trace) run before major releases, with results compared to a baseline? | Continuously monitor and improve performance | Example: No load test since launch | None | Medium |
| GCR-PERF-07 | Is there a backlog of performance improvements reviewed on a schedule? | Continuously monitor and improve performance | [State] | [Evidence] | [Rating] |
10. Sustainability
10.1 Core principles
| Google core principle | What the reviewer looks for |
|---|
| Use regions that consume low-carbon energy | Region choice that considers carbon-free energy data alongside latency, residency and cost |
| Optimize AI and ML workloads for energy efficiency | Efficient models, hardware and training and serving schedules |
| Optimize resource usage for sustainability | High utilisation, autoscaling and removal of idle resources |
| Develop energy-efficient software | Efficient code paths, batching and avoidance of needless work |
| Optimize data and storage for sustainability | Lifecycle rules, deletion of unused data and efficient formats |
| Continuously measure and improve sustainability | Carbon Footprint data reviewed with targets and owners |
| Promote a culture of sustainability | Awareness, training and sustainability included in design reviews |
| Align sustainability practices with industry guidelines | Reference to recognised standards and reporting frameworks |
10.2 Review questions
| ID | Question | Core principle | Current state | Evidence | Rating |
|---|
| GCR-SUS-01 | Was carbon-free energy information considered when choosing regions, with the decision recorded? | Use regions that consume low-carbon energy | [State] | [Evidence] | [Rating] |
| GCR-SUS-02 | Are model size, hardware and retraining frequency justified by measured quality gains? | Optimize AI and ML workloads for energy efficiency | [State] | [Evidence] | [Rating] |
| GCR-SUS-03 | Is average utilisation of provisioned resources tracked and raised where low? | Optimize resource usage for sustainability | [State] | [Evidence] | [Rating] |
| GCR-SUS-04 | Are inefficient code paths and unnecessary processing (polling, full reloads) removed? | Develop energy-efficient software | [State] | [Evidence] | [Rating] |
| GCR-SUS-05 | Do storage buckets and datasets have lifecycle and expiry rules matching retention needs? | Optimize data and storage for sustainability | [State] | [Evidence] | [Rating] |
| GCR-SUS-06 | Is Carbon Footprint data exported, baselined and reviewed with a target? | Continuously measure and improve sustainability | Example: Not exported | None | Medium |
| GCR-SUS-07 | Does the design review template include a sustainability check? | Promote a culture of sustainability | [State] | Sustainability assessment (architecture/sustainability-architecture-assessment) | [Rating] |
| GCR-SUS-08 | Is the measurement method aligned with a recognised guideline (for example the Software Carbon Intensity specification, ISO/IEC 21031:2024)? | Align sustainability practices with industry guidelines | [State] | [Evidence] | [Rating] |
11. Cross-pillar perspectives
11.1 AI and ML perspective
The AI and ML perspective gives AI-specific recommendations for five pillars: operational excellence, security, reliability, cost optimization and performance optimization.
| ID | Pillar view | Question | Current state | Evidence | Rating |
|---|
| GCR-AIML-01 | Operational excellence | Are models versioned in a registry, deployed by pipeline and monitored for skew and drift with retraining triggers? | [State] | [Evidence] | [Rating] |
| GCR-AIML-02 | Security | Are training data, features and model artefacts protected, and are prediction inputs and outputs screened for misuse? | [State] | [Evidence] | [Rating] |
| GCR-AIML-03 | Reliability | Can the serving endpoint survive a zone loss and fall back to a simpler model or cached score? | Example: No fallback; endpoint errors return HTTP 500 to the website | Incident report | High |
| GCR-AIML-04 | Cost optimization | Are training and batch prediction run on Spot or scheduled capacity, and is serving right-sized? | [State] | [Evidence] | [Rating] |
| GCR-AIML-05 | Performance optimization | Are serving latency, accelerator use and batch sizes measured and tuned against the journey target? | [State] | [Evidence] | [Rating] |
| GCR-AIML-06 | Security | Are model decisions explainable to the degree regulation or policy requires, with methods documented? | [State] | [Evidence] | [Rating] |
11.2 Financial services perspective
The financial services perspective gives recommendations for the same five pillars, framed by regulatory, risk and resilience expectations on banks, insurers, payment providers and capital markets firms.
| ID | Pillar view | Question | Current state | Evidence | Rating |
|---|
| GCR-FS-01 | Reliability | Is operational resilience (important business services, impact tolerances, scenario testing) mapped to the workload and reported to the risk function? | [State] | [Evidence] | [Rating] |
| GCR-FS-02 | Security | Are encryption key control, access transparency and audit evidence sufficient for supervisory review? | [State] | [Evidence] | [Rating] |
| GCR-FS-03 | Operational excellence | Is the cloud provider recorded in the ICT third-party register with exit and concentration considerations? | [State] | [Evidence] | [Rating] |
| GCR-FS-04 | Cost optimization | Are committed use discounts managed centrally and shared across projects, with allocation to business lines? | [State] | [Evidence] | [Rating] |
| GCR-FS-05 | Performance optimization | Do latency-critical flows (payments, trading) have measured end-to-end targets and capacity buffers for market peaks? | [State] | [Evidence] | [Rating] |
12. Risk register and trade-offs
12.1 Findings
| Finding ID | Question | Pillar or perspective | Risk | Finding | Business impact | Response |
|---|
| FND-001 (Example) | GCR-SEC-02 | Security, privacy, and compliance | High | Service account keys stored in CI | Key leak gives write access to production data | ACT-001 |
| FND-002 (Example) | GCR-REL-03 | Reliability | High | Zonal Memorystore on the scoring path | Zone loss breaks UJ-01 | ACT-002 |
| FND-003 (Example) | GCR-AIML-03 | AI and ML | High | No fallback for model endpoint | Website errors during model outages | ACT-003 |
| FND-004 (Example) | GCR-OPS-01 | Operational excellence | Medium | SLOs not configured in monitoring | Error budget cannot steer releases | ACT-004 |
| FND-005 (Example) | GCR-COST-05 | Cost optimization | Medium | On-demand BigQuery at high scan volume | Avoidable spend | ACT-005 |
| FND-006 (Example) | GCR-PERF-06 | Performance optimization | Medium | No load test since launch | Peak failures undetected | ACT-006 |
| FND-007 (Example) | GCR-SUS-06 | Sustainability | Medium | No carbon baseline | Goal cannot be tracked | RA-001 |
| [FND-NNN] | [GCR-ID] | [Pillar] | [High / Medium] | [Finding] | [Impact] | [ACT-NNN / RA-NNN] |
The Example rows show a subset; the completed register lists every question rated High or Medium in the sections above.
12.2 Summary by pillar
| Pillar or perspective | High | Medium | None | Not applicable |
|---|
| System design principles | [n] | [n] | [n] | [n] |
| Operational excellence | [n] | [n] | [n] | [n] |
| Security, privacy, and compliance | [n] | [n] | [n] | [n] |
| Reliability | [n] | [n] | [n] | [n] |
| Cost optimization | [n] | [n] | [n] | [n] |
| Performance optimization | [n] | [n] | [n] | [n] |
| Sustainability | [n] | [n] | [n] | [n] |
| Perspectives | [n] | [n] | [n] | [n] |
| Total | [n] | [n] | [n] | [n] |
12.3 Trade-off decisions
| Decision | Pillar favoured | Pillar affected | Rationale | Decided by |
|---|
| Example: Keep europe-west1 although another EU region has a higher carbon-free energy share | Reliability, performance (existing data and latency) | Sustainability | Migration risk outweighs benefit this year; revisit at next review | [@workload-owner] |
| Example: Minimum instances on Cloud Run scoring service | Performance optimization (cold start) | Cost optimization | UJ-01 latency target needs warm instances | [@tech-lead] |
| [Decision] | [Pillar] | [Pillar] | [Rationale] | [@name] |
Escalate long-lived risks to the Risk register (compliance/risk-register).
13. Improvement plan
13.1 Action backlog
| Action ID | Finding | Action | Owner | Effort | Target date | Acceptance criterion | Status |
|---|
| ACT-001 (Example) | FND-001 | Replace keys with Workload Identity Federation; enforce the organisation policy that blocks key creation | [@platform-eng] | S | YYYY-MM-DD | No user-managed keys in workload projects | [Open] |
| ACT-002 (Example) | FND-002 | Move cache to a highly available tier across zones | [@dev-lead] | S | YYYY-MM-DD | Zone drill keeps UJ-01 within SLO | [Open] |
| ACT-003 (Example) | FND-003 | Add fallback to a rules-based score with circuit breaker | [@ml-lead] | M | YYYY-MM-DD | Endpoint outage drill returns fallback scores, no HTTP 500 | [Open] |
| ACT-004 (Example) | FND-004 | Configure SLOs and burn-rate alerts for UJ-01 to UJ-03 | [@sre-lead] | S | YYYY-MM-DD | Alerts fire in a synthetic burn test | [Open] |
| ACT-005 (Example) | FND-005 | Evaluate BigQuery editions with reservations; partition top 10 tables | [@data-lead] | M | YYYY-MM-DD | Monthly scan cost reduced by the agreed target | [Open] |
| ACT-006 (Example) | FND-006 | Add a load test stage to the pipeline for the scoring API | [@qa-lead] | M | YYYY-MM-DD | Release blocked when p99 exceeds target | [Open] |
| [ACT-NNN] | [FND-NNN] | [Action] | [@owner] | [S / M / L] | YYYY-MM-DD | [Criterion] | [Status] |
13.2 Responsibilities
| Activity | Workload owner | Lead reviewer | Workload team | Platform team | Security and privacy | FinOps |
|---|
| Approve scope and perspectives | A | R | C | C | C | C |
| Provide evidence | A | C | R | R | R | R |
| Rate and record findings | C | A/R | C | C | C | C |
| Prioritise and fund actions | A/R | C | C | C | C | C |
| Implement workload actions | A | I | R | C | C | C |
| Implement foundation actions | C | I | C | A/R | C | I |
| Record baseline and report | A | R | C | I | I | I |
R = responsible, A = accountable, C = consulted, I = informed.
14. Re-review baseline
14.1 Baseline record
| Baseline ID | Date | Framework pages dated | Perspectives | High open | Medium open | Notes |
|---|
| B-001 (Example) | YYYY-MM-DD | [Framework 2026-10-13] | AI and ML | 4 | 10 | Initial review |
| B-002 (Example) | YYYY-MM-DD | [Date] | AI and ML | 1 | 5 | ACT-001 to ACT-004 closed |
| [B-NNN] | YYYY-MM-DD | [Date] | [Perspectives] | [n] | [n] | [Notes] |
14.2 Re-review triggers
- The scheduled interval is reached ([every 6 months for high criticality, 12 months for others]).
- A major change: new region, new data store, new AI model class, move between Cloud Run, GKE and Compute Engine.
- A Severity 1 incident, a missed SLO quarter or a failed recovery test.
- A significant update to a pillar or perspective listed on the framework's "What's new" page.
- A change in regulation, contract or residency requirement.
15. Risk acceptance and sign-off
15.1 Accepted risks
| Acceptance ID | Finding | Reason | Compensating control | Accepted by | Expiry |
|---|
| RA-001 (Example) | FND-007 | Organisation-wide carbon reporting is planned for next quarter | Right-sizing actions reduce footprint meanwhile | [@workload-owner] | YYYY-MM-DD |
| [RA-NNN] | [FND-NNN] | [Reason] | [Control] | [@name] | YYYY-MM-DD |
15.2 Review conclusion
| Item | Value |
|---|
| Overall conclusion | [Ready for production / Ready with conditions / Not ready] |
| Conditions | [Each linked to an action] |
| Go-live link | [Go-live readiness review, project/go-live-readiness-review, if pre-launch] |
| Next review date | YYYY-MM-DD |
16. Glossary and references
16.1 Glossary
| Term | Meaning in this document |
|---|
| Pillar | One of the six areas of the Google Cloud Well-Architected Framework |
| Core principle | One of the principles that organise the recommendations within a pillar |
| Perspective | A cross-pillar view for a technology or industry (AI and ML, Financial services) |
| User journey | A path a user takes through the service, used to define SLIs and SLOs |
| SLI, SLO, error budget | Service level indicator, service level objective and the allowed unreliability under the objective |
| Resource hierarchy | Organisation, folders and projects that carry policies and billing |
| VPC Service Controls | Perimeters that limit data movement between Google Cloud services and networks |
16.2 References
| Reference | Version or date | Use |
|---|
| Google Cloud Well-Architected Framework, docs.cloud.google.com/architecture/framework | Last updated 2026-10-13 | Pillars, perspectives, system design principles |
| Pillar overview pages (six pillars) | Last updated 2026-10-13 | Core principles in sections 5 to 10 |
| AI and ML perspective | Overview page 2024-10-11; pillar sub-pages updated 2025 to 2026 (latest 2026-09-11, per What's new) | Section 11.1 |
| Financial services perspective | Last updated 2025-07-28 | Section 11.2 |
| Well-Architected Framework "What's new" page | Checked 2026-10-23 | Change tracking, agent skills (13 October 2026) |
| Related templates | Current | Cloud architecture review (architecture/cloud-architecture-review), AWS Well-Architected review (architecture/aws-well-architected-review), Azure Well-Architected review (architecture/azure-well-architected-review), GenAI Well-Architected review (architecture/genai-well-architected-review) |
Standard and licence note
Structure aligned with the system design principles, six pillars, core principles and cross-pillar perspectives of the Google Cloud Well-Architected Framework as published on Google Cloud documentation and checked on 23 October 2026. Pillar, principle and perspective names are used for mapping only. The review questions, ratings, guidance and examples are original text written for this collection and do not reproduce Google's recommendation wording or its agent skill checklists. Check the current official pages before each review; Google updates pillars and perspectives frequently and lists changes on the framework's "What's new" page. Google Cloud and the products named are trademarks of their owners; this template is not affiliated with or endorsed by them. Template licence: MIT.