Flow
- 1Requests reach the global anycast IP of the load balancer and are screened by Cloud Armor
- 2Cloud Armor → Application Load Balancer
- 3Application Load Balancer → Web tier VMs (balance)
- 3Application Load Balancer → Web tier VMs
- 4Web tier VMs → App tier VMs
- 4Web tier VMs → App tier VMs
- 5App tier VMs → Cloud SQL for PostgreSQL (SQL)
- 5App tier VMs → Cloud SQL for PostgreSQL
Well-Architected review Highly available three-tier web application · 2026-10-02 · mode full
Coverage audit
- Google Cloud Well-Architected Framework — 6 pillars, 174 recommendations, from the live documentation index, snapshot 2026-10-02 (0 days old).
- Assessed 174 recommendations: 13 with diagram evidence, 161 cannot be determined.
- Evidence sources: architecture diagram (services, boundaries, relationships).
- Corpus read from a committed snapshot of the live documentation index (not re-fetched during this review). Re-read it with `archify-gcp wa corpus --refresh`. Statuses reflect what the diagram and spec show. Process, configuration and runtime evidence are not observable here, so those recommendations are 'Cannot Determine' rather than guessed.
Executive summary
This Google Cloud Well-Architected Framework review of Highly available three-tier web application (standard criticality) assessed the architecture diagram only. 13 of 174 framework recommendations have diagram evidence; the rest are Cannot Determine because process, configuration and runtime evidence is not in the diagram. No risks are evidenced.
0Critical
0High
0Medium
0Low
4.6provisional maturity (1–5)
13 of 174 recommendations have diagram evidence (7%); among those, 10 implemented, 3 partial, 0 not implemented. Provisional: scores cover evidenced practices only.
Strengths. Edge protection present; Data stores are not reached directly from clients; Key management shown; Secrets / passwordless access shown; Workload spans multiple zones; Managed instance groups / autoscale shown; Observability shown; Edge delivery shown.
Architecture overview
The reviewed architecture is the Diagram tab (13 components, architecture diagram). Hover a finding to highlight the components involved.
Pillar scorecard
| Pillar | Score (1–5) | Evidenced recommendations | I · P · N · NA · CD | Strongest area | Main gap |
|---|---|---|---|---|---|
| Operational excellence | — | 2/25 (8%) | 2 0 0 0 23 | Observability shown | No gaps evidenced in the diagram |
| Security, privacy, and compliance | 3.8 provisional | 5/43 (11.6%) | 2 3 0 0 38 | Edge protection present | No gaps evidenced in the diagram |
| Reliability | 5.0 provisional | 3/35 (8.6%) | 3 0 0 0 32 | Workload spans multiple zones | No gaps evidenced in the diagram |
| Cost optimization | — | 0/26 (0%) | 0 0 0 0 26 | — | No gaps evidenced in the diagram |
| Performance optimization | 5.0 provisional | 3/16 (18.8%) | 3 0 0 0 13 | Edge delivery shown | No gaps evidenced in the diagram |
| Sustainability | — | 0/29 (0%) | 0 0 0 0 29 | — | No gaps evidenced in the diagram |
Score = 1 + 4 × (implemented + ½ partial) ÷ evidenced recommendations; shown only when ≥ 3 recommendations are evidenced. It reflects evidenced practices, not the whole pillar.
Framework questions
| ID | Question | Pillar | Status | Risk | Recs (evidenced) | Key evidence |
|---|---|---|---|---|---|---|
| OE-1 | Ensure operational readiness and performance using CloudOps | Operational excellence | Implemented | None | 5 (1) | Diagram: Observability shown. Nodes: mon, log. Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging, Cloud Trace and Managed Service for Promet |
| OE-2 | Manage incidents and problems | Operational excellence | Cannot Determine | Not Applicable | 5 (0) | — |
| OE-3 | Manage and optimize cloud resources | Operational excellence | Implemented | None | 5 (1) | Diagram: Managed instance groups / autoscale shown. Nodes: web_a, app_a, web_b, app_b. Run VMs in regional managed instance groups with autoscaling and autoheal |
| OE-4 | Automate and manage change | Operational excellence | Cannot Determine | Not Applicable | 5 (2) | Diagram: No infrastructure-as-code or CI/CD shown. Define infrastructure as code (Terraform / Infrastructure Manager or Config Connector) and deploy through Clo |
| OE-5 | Continuously improve and innovate | Operational excellence | Cannot Determine | Not Applicable | 5 (0) | — |
| SEC-1 | Implement security by design | Security, privacy, and compliance | Implemented | None | 4 (2) | Diagram: Edge protection present. Nodes: armor. Protect public entry points (Cloud Load Balancing, Apigee, API Gateway) with Cloud Armor security policies (WAF |
| SEC-2 | Implement zero trust | Security, privacy, and compliance | Partially Implemented | None | 3 (3) | Diagram: Edge protection present. Nodes: armor. Protect public entry points (Cloud Load Balancing, Apigee, API Gateway) with Cloud Armor security policies (WAF |
| SEC-3 | Implement shift-left security | Security, privacy, and compliance | Cannot Determine | Not Applicable | 6 (0) | — |
| SEC-4 | Implement preemptive cyber defense | Security, privacy, and compliance | Cannot Determine | Not Applicable | 5 (1) | Diagram: No threat detection or posture management shown. Enable Security Command Center for posture and threat detection, Cloud Audit Logs (Data Access where n |
| SEC-5 | Use AI securely and responsibly | Security, privacy, and compliance | Cannot Determine | Not Applicable | 10 (0) | — |
| SEC-6 | Use AI for security | Security, privacy, and compliance | Cannot Determine | Not Applicable | 5 (0) | — |
| SEC-7 | Meet regulatory, compliance, and privacy needs | Security, privacy, and compliance | Partially Implemented | None | 10 (1) | Diagram: No private access or VPC Service Controls shown for managed data services. Reach Google APIs and managed data services privately (Private Google Access |
| REL-1 | Define reliability based on user-experience goals | Reliability | Cannot Determine | Not Applicable | 2 (0) | — |
| REL-2 | Set realistic targets for reliability | Reliability | Cannot Determine | Not Applicable | 2 (0) | — |
| REL-3 | Build highly available systems through resource redundancy | Reliability | Implemented | None | 3 (1) | Diagram: Workload spans multiple zones. Deploy across at least two zones (regional managed instance groups, regional GKE clusters, Cloud SQL / AlloyDB high avai |
| REL-4 | Take advantage of horizontal scalability | Reliability | Implemented | None | 3 (1) | Diagram: Managed instance groups / autoscale shown. Nodes: web_a, app_a, web_b, app_b. Run VMs in regional managed instance groups with autoscaling and autoheal |
| REL-5 | Detect potential failures by using observability | Reliability | Implemented | None | 4 (1) | Diagram: Observability shown. Nodes: mon, log. Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging, Cloud Trace and Managed Service for Promet |
| REL-6 | Design for graceful degradation | Reliability | Cannot Determine | Not Applicable | 5 (1) | Diagram: No queue / event service shown between tiers. Decouple components with Pub/Sub, Cloud Tasks or Eventarc so spikes and downstream failures do not cascad |
| REL-7 | Perform testing for recovery from failures | Reliability | Cannot Determine | Not Applicable | 7 (0) | — |
| REL-8 | Perform testing for recovery from data loss | Reliability | Cannot Determine | Not Applicable | 5 (2) | Diagram: No backup or recovery capability shown. Define RPO/RTO and protect data with Backup and DR Service, automated backups and point-in-time recovery, snaps |
| REL-9 | Conduct thorough postmortems | Reliability | Cannot Determine | Not Applicable | 4 (0) | — |
| COST-1 | Align cloud spending with business value | Cost optimization | Cannot Determine | Not Applicable | 5 (0) | — |
| COST-2 | Foster a culture of cost awareness | Cost optimization | Cannot Determine | Not Applicable | 7 (3) | Diagram: No cost visibility shown. Label resources consistently, export billing data to BigQuery and set Cloud Billing budgets and alerts so spend maps to workl |
| COST-3 | Optimize resource usage | Cost optimization | Cannot Determine | Not Applicable | 8 (0) | — |
| COST-4 | Optimize continuously | Cost optimization | Cannot Determine | Not Applicable | 6 (0) | — |
| PERF-1 | Plan resource allocation | Performance optimization | Cannot Determine | Not Applicable | 3 (0) | — |
| PERF-2 | Take advantage of elasticity | Performance optimization | Implemented | None | 4 (1) | Diagram: Edge delivery shown. Nodes: cdnn. Serve cacheable content from Google's edge with Cloud CDN or Media CDN behind the global external Application Load Ba |
| PERF-3 | Promote modular design | Performance optimization | Implemented | None | 6 (2) | Diagram: No queue / event service shown between tiers. Decouple components with Pub/Sub, Cloud Tasks or Eventarc so spikes and downstream failures do not cascad |
| PERF-4 | Continuously monitor and improve performance | Performance optimization | Implemented | None | 3 (1) | Diagram: Observability shown. Nodes: mon, log. Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging, Cloud Trace and Managed Service for Promet |
| SUS-1 | Use regions that consume low-carbon energy | Sustainability | Cannot Determine | Not Applicable | 3 (2) | Diagram: Region choice is not tied to carbon intensity. Choose regions using Google's carbon-free energy (CFE%) data and grid carbon intensity when latency and |
| SUS-2 | Optimize AI and ML workloads for energy efficiency | Sustainability | Cannot Determine | Not Applicable | 4 (0) | — |
| SUS-3 | Optimize resource usage for sustainability | Sustainability | Cannot Determine | Not Applicable | 7 (2) | Diagram: No managed or serverless services shown. Prefer managed and serverless services with automatic scaling, schedule batch work for low-carbon periods and |
| SUS-4 | Develop energy-efficient software | Sustainability | Cannot Determine | Not Applicable | 4 (0) | — |
| SUS-5 | Optimize data and storage for sustainability | Sustainability | Cannot Determine | Not Applicable | 3 (0) | — |
| SUS-6 | Continuously measure and improve sustainability | Sustainability | Cannot Determine | Not Applicable | 4 (0) | — |
| SUS-7 | Promote a culture of sustainability | Sustainability | Cannot Determine | Not Applicable | 4 (0) | — |
Recommendation ledger 174 recommendations — nothing truncated
| ID | Pillar | Best practice | Status | Evidence |
|---|---|---|---|---|
| OE-1.1 | Operational excellence | Define SLOs and SLAs | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| OE-1.2 | Operational excellence | Implement comprehensive observability | Implemented | Diagram: Observability shown. Nodes: mon, log. Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging, Cloud Trace and Managed Service for Prometheus, define SLOs and alert on burn rate. |
| OE-1.3 | Operational excellence | Implement performance and load testing | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| OE-1.4 | Operational excellence | Plan and manage capacity | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| OE-1.5 | Operational excellence | Continuously monitor and optimize | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| OE-2.1 | Operational excellence | Establish clear incident response procedures | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| OE-2.2 | Operational excellence | Centralize incident management | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| OE-2.3 | Operational excellence | Conduct thorough post-incident reviews | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| OE-2.4 | Operational excellence | Maintain a knowledge base | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| OE-2.5 | Operational excellence | Automate incident response | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| OE-3.1 | Operational excellence | Right-size resources | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| OE-3.2 | Operational excellence | Use autoscaling | Implemented | Diagram: Managed instance groups / autoscale shown. Nodes: web_a, app_a, web_b, app_b. Run VMs in regional managed instance groups with autoscaling and autohealing (or use Cloud Run, GKE or App Engine) so capacity follows demand and failed instances are replaced. |
| OE-3.3 | Operational excellence | Leverage cost optimization strategies | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| OE-3.4 | Operational excellence | Track resource usage and costs | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| OE-3.5 | Operational excellence | Establish cost allocation and budgeting | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| OE-4.1 | Operational excellence | Adopt IaC | Cannot Determine | Diagram: No infrastructure-as-code or CI/CD shown. Define infrastructure as code (Terraform / Infrastructure Manager or Config Connector) and deploy through Cloud Build and Cloud Deploy with small, reversible changes and automated rollback. |
| OE-4.2 | Operational excellence | Implement version control | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| OE-4.3 | Operational excellence | Build CI/CD pipelines | Cannot Determine | Diagram: No infrastructure-as-code or CI/CD shown. Define infrastructure as code (Terraform / Infrastructure Manager or Config Connector) and deploy through Cloud Build and Cloud Deploy with small, reversible changes and automated rollback. |
| OE-4.4 | Operational excellence | Use configuration management tools | Cannot Determine | Not observable from the architecture diagram; needs IaC or configuration evidence. |
| OE-4.5 | Operational excellence | Automate testing | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| OE-5.1 | Operational excellence | Foster a culture of learning | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| OE-5.2 | Operational excellence | Conduct regular retrospectives | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| OE-5.3 | Operational excellence | Stay up-to-date with cloud technologies | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| OE-5.4 | Operational excellence | Actively seek and incorporate feedback | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| OE-5.5 | Operational excellence | Measure and track progress | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-1.1 | Security, privacy, and compliance | Choose system components that help to secure your workloads | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-1.2 | Security, privacy, and compliance | Build a layered security approach | Implemented | Diagram: Edge protection present. Nodes: armor. Protect public entry points (Cloud Load Balancing, Apigee, API Gateway) with Cloud Armor security policies (WAF rules, rate limiting, DDoS protection) and restrict backends to the load balancer. |
| SEC-1.3 | Security, privacy, and compliance | Use hardened and attested infrastructure and services | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-1.4 | Security, privacy, and compliance | Encrypt data at rest and in transit | Implemented | Diagram: Key management shown. Nodes: kms. Data is encrypted by default; use Cloud KMS customer-managed keys (CMEK, or Cloud HSM / EKM) where you need rotation, access policy or audit control, and enforce TLS in transit. |
| SEC-2.1 | Security, privacy, and compliance | Secure your network | Partially Implemented | Diagram: Edge protection present. Nodes: armor. Protect public entry points (Cloud Load Balancing, Apigee, API Gateway) with Cloud Armor security policies (WAF rules, rate limiting, DDoS protection) and restrict backends to the load balancer. Diagram: Data stores are not reached directly from clients. Least-privilege network placement for stateful services. Diagram: No private access or VPC Service Controls shown for managed data services. Reach Google APIs and managed data services privately (Private Google Access, Private Service Connect) and wrap sensitive projects in a VPC Service Controls perimeter to prevent exfiltration. Diagram shows Cloud Armor WAF, rate limiting; whether the segments follow trust boundaries is not observable. |
| SEC-2.2 | Security, privacy, and compliance | Verify every access attempt explicitly | Partially Implemented | Diagram: No identity / authentication service shown. Authenticate and authorize every request: Identity-Aware Proxy or Identity Platform for users, IAM with least privilege and dedicated service accounts (Workload Identity) for workloads. Diagram: Secrets / passwordless access shown. Nodes: kms. Store secrets in Secret Manager or, better, use IAM database authentication and service-account identities so no credentials are embedded. |
| SEC-2.3 | Security, privacy, and compliance | Monitor and maintain your network | Cannot Determine | Diagram: No threat detection or posture management shown. Enable Security Command Center for posture and threat detection, Cloud Audit Logs (Data Access where needed) and Cloud IDS, and route security logs to a central, access-restricted sink. |
| SEC-3.1 | Security, privacy, and compliance | Adopt preventive security controls | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-3.2 | Security, privacy, and compliance | Automate provisioning and management of cloud resources | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-3.3 | Security, privacy, and compliance | Automate secure application releases | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-3.4 | Security, privacy, and compliance | Ensure that application deployments follow approved processes | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| SEC-3.5 | Security, privacy, and compliance | Scan for known vulnerabilities before application deployment | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-3.6 | Security, privacy, and compliance | Monitor your application code for known vulnerabilities | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-4.1 | Security, privacy, and compliance | Integrate the functions of cyber defense | Cannot Determine | Diagram: No threat detection or posture management shown. Enable Security Command Center for posture and threat detection, Cloud Audit Logs (Data Access where needed) and Cloud IDS, and route security logs to a central, access-restricted sink. |
| SEC-4.2 | Security, privacy, and compliance | Use the Intelligence function in all aspects of cyber defense | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-4.3 | Security, privacy, and compliance | Understand and capitalize on your defender's advantage | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-4.4 | Security, privacy, and compliance | Validate and improve your defenses continuously | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| SEC-4.5 | Security, privacy, and compliance | Manage and coordinate cyber-defense efforts | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-5.1 | Security, privacy, and compliance | Define clear goals and requirements for AI usage | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| SEC-5.2 | Security, privacy, and compliance | Keep data secure and prevent loss or mishandling | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-5.3 | Security, privacy, and compliance | Keep AI pipelines secure and robust against tampering | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-5.4 | Security, privacy, and compliance | Deploy apps on secure systems using secure tools and artifacts | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-5.5 | Security, privacy, and compliance | Protect and monitor inputs | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-5.6 | Security, privacy, and compliance | Use fairness indicators | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-5.7 | Security, privacy, and compliance | Use Vertex Explainable AI | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-5.8 | Security, privacy, and compliance | Track data lineage | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-5.9 | Security, privacy, and compliance | Establish accountability | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-5.10 | Security, privacy, and compliance | Implement differential privacy | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-6.1 | Security, privacy, and compliance | Enhance threat detection and response with AI | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-6.2 | Security, privacy, and compliance | Simplify security for experts and non-experts | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-6.3 | Security, privacy, and compliance | Automate time-consuming security tasks with AI | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-6.4 | Security, privacy, and compliance | Incorporate AI into risk management and governance processes | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| SEC-6.5 | Security, privacy, and compliance | Implement secure development practices for AI systems | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-7.1 | Security, privacy, and compliance | Identify risks to your organization | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-7.2 | Security, privacy, and compliance | Mitigate your risks | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-7.3 | Security, privacy, and compliance | Assess your compliance needs | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-7.4 | Security, privacy, and compliance | Automate implementation of compliance requirements | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| SEC-7.5 | Security, privacy, and compliance | Monitor your compliance | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-7.6 | Security, privacy, and compliance | Manage your operational sovereignty | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-7.7 | Security, privacy, and compliance | Manage software sovereignty | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-7.8 | Security, privacy, and compliance | Control data residency | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-7.9 | Security, privacy, and compliance | Classify your confidential data | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SEC-7.10 | Security, privacy, and compliance | Lock down access to sensitive data | Partially Implemented | Diagram: No private access or VPC Service Controls shown for managed data services. Reach Google APIs and managed data services privately (Private Google Access, Private Service Connect) and wrap sensitive projects in a VPC Service Controls perimeter to prevent exfiltration. Diagram: Secrets / passwordless access shown. Nodes: kms. Store secrets in Secret Manager or, better, use IAM database authentication and service-account identities so no credentials are embedded. |
| REL-1.1 | Reliability | Measure user experience | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-1.2 | Reliability | Analyze user journeys | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-2.1 | Reliability | Accept some failure and prioritize components | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| REL-2.2 | Reliability | Balance reliability and cost | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-3.1 | Reliability | Identify failure domains and replicate services | Implemented | Diagram: Workload spans multiple zones. Deploy across at least two zones (regional managed instance groups, regional GKE clusters, Cloud SQL / AlloyDB high availability) and use multi-region or dual-region storage and databases where the SLO needs it. No on-premises or private-link connectivity is drawn. |
| REL-3.2 | Reliability | Detect and address issues promptly | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-3.3 | Reliability | Test failover scenarios | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-4.1 | Reliability | Use managed services | Implemented | Diagram: Managed instance groups / autoscale shown. Nodes: web_a, app_a, web_b, app_b. Run VMs in regional managed instance groups with autoscaling and autohealing (or use Cloud Run, GKE or App Engine) so capacity follows demand and failed instances are replaced. |
| REL-4.2 | Reliability | Promote modular design | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-4.3 | Reliability | Implement a stateless design | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-5.1 | Reliability | Gain comprehensive insights | Implemented | Diagram: Observability shown. Nodes: mon, log. Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging, Cloud Trace and Managed Service for Prometheus, define SLOs and alert on burn rate. |
| REL-5.2 | Reliability | Perform proactive troubleshooting | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-5.3 | Reliability | Optimize resource utilization | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-5.4 | Reliability | Prioritize alerts | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| REL-6.1 | Reliability | Implement throttling | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-6.2 | Reliability | Drop excess requests early | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-6.3 | Reliability | Handle partial errors and retries | Cannot Determine | Diagram: No queue / event service shown between tiers. Decouple components with Pub/Sub, Cloud Tasks or Eventarc so spikes and downstream failures do not cascade; add retries with exponential backoff, timeouts and load shedding. |
| REL-6.4 | Reliability | Test overload scenarios | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-6.5 | Reliability | Monitor traffic spikes | Cannot Determine | Not observable from the architecture diagram; needs IaC or configuration evidence. |
| REL-7.1 | Reliability | Define the testing objectives and scope | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-7.2 | Reliability | Prepare the environment for testing | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-7.3 | Reliability | Simulate failure scenarios | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-7.4 | Reliability | Monitor system behavior | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-7.5 | Reliability | Verify recovery against your RTO and RPO | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-7.6 | Reliability | Document and analyze results | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-7.7 | Reliability | Iterate and improve | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| REL-8.1 | Reliability | Verify backup consistency and test restoration processes | Cannot Determine | Diagram: No backup or recovery capability shown. Define RPO/RTO and protect data with Backup and DR Service, automated backups and point-in-time recovery, snapshots, object versioning and cross-region replicas, and test restores. |
| REL-8.2 | Reliability | Schedule regular and frequent backups | Cannot Determine | Diagram: No backup or recovery capability shown. Define RPO/RTO and protect data with Backup and DR Service, automated backups and point-in-time recovery, snapshots, object versioning and cross-region replicas, and test restores. |
| REL-8.3 | Reliability | Define and monitor RPO | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-8.4 | Reliability | Monitor backup health | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-8.5 | Reliability | Plan for scenarios beyond backup | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| REL-9.1 | Reliability | Conduct blameless postmortems | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-9.2 | Reliability | Make the postmortem report readable by all the intended audiences | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-9.3 | Reliability | Avoid complex or over-engineered solutions | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| REL-9.4 | Reliability | Share the postmortem as widely as possible | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-1.1 | Cost optimization | Prioritize managed services and serverless products | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| COST-1.2 | Cost optimization | Balance cost efficiency with business agility | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-1.3 | Cost optimization | Enable self-service optimization | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-1.4 | Cost optimization | Adopt and implement FinOps | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-1.5 | Cost optimization | Promote a value-driven and TCO-aware mindset | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-2.1 | Cost optimization | Provide organization-wide cost visibility | Cannot Determine | Diagram: No cost visibility shown. Label resources consistently, export billing data to BigQuery and set Cloud Billing budgets and alerts so spend maps to workloads and owners. |
| COST-2.2 | Cost optimization | Understand how cloud resources are billed | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-2.3 | Cost optimization | Understand resource-based cost optimization options | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-2.4 | Cost optimization | Understand discount-based cost optimization options | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-2.5 | Cost optimization | Incorporate cost estimates into architecture blueprints | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-2.6 | Cost optimization | Use a consistent and standard set of labels for all your resources | Cannot Determine | Diagram: No cost visibility shown. Label resources consistently, export billing data to BigQuery and set Cloud Billing budgets and alerts so spend maps to workloads and owners. |
| COST-2.7 | Cost optimization | Share cost reports with team members | Cannot Determine | Diagram: No cost visibility shown. Label resources consistently, export billing data to BigQuery and set Cloud Billing budgets and alerts so spend maps to workloads and owners. |
| COST-3.1 | Cost optimization | Choose environment-specific resources | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-3.2 | Cost optimization | Choose workload-specific resources | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-3.3 | Cost optimization | Select regions based on cost requirements | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| COST-3.4 | Cost optimization | Use built-in cost optimization options | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-3.5 | Cost optimization | Optimize resource sharing | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-3.6 | Cost optimization | Develop and maintain reference architectures | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-3.7 | Cost optimization | Enforce cost discipline by using organization policies | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-3.8 | Cost optimization | Estimate realistic budgets and set financial boundaries | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| COST-4.1 | Cost optimization | Focus on business-relevant metrics | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-4.2 | Cost optimization | Use observability for resource optimization | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-4.3 | Cost optimization | Balance troubleshooting needs with cost | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-4.4 | Cost optimization | Tailor data collection to roles and set role-specific retention policies | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| COST-4.5 | Cost optimization | Consider regulatory and compliance requirements | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| COST-4.6 | Cost optimization | Implement smart alerting | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| PERF-1.1 | Performance optimization | Configure and manage quotas | Cannot Determine | Not observable from the architecture diagram; needs IaC or configuration evidence. |
| PERF-1.2 | Performance optimization | Educate and promote awareness | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| PERF-1.3 | Performance optimization | Monitor performance metrics | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| PERF-2.1 | Performance optimization | Plan for peak load periods | Implemented | Diagram: Edge delivery shown. Nodes: cdnn. Serve cacheable content from Google's edge with Cloud CDN or Media CDN behind the global external Application Load Balancer to cut latency. Diagram: Caching shown. Nodes: redis. Add caching (Memorystore, Cloud CDN) or read replicas for read-heavy access, and choose the data store that fits the access pattern. |
| PERF-2.2 | Performance optimization | Use predictive scaling | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| PERF-2.3 | Performance optimization | Implement serverless architectures | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| PERF-2.4 | Performance optimization | Use Autopilot mode for Kubernetes | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| PERF-3.1 | Performance optimization | Design for loose coupling | Cannot Determine | Diagram: No queue / event service shown between tiers. Decouple components with Pub/Sub, Cloud Tasks or Eventarc so spikes and downstream failures do not cascade; add retries with exponential backoff, timeouts and load shedding. |
| PERF-3.2 | Performance optimization | Design for concurrency and parallelism | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| PERF-3.3 | Performance optimization | Balance modularity for flexible resource allocation | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| PERF-3.4 | Performance optimization | Use well-defined interfaces | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| PERF-3.5 | Performance optimization | Use stateless models | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| PERF-3.6 | Performance optimization | Choose complementary technologies | Implemented | Diagram: Caching shown. Nodes: redis. Add caching (Memorystore, Cloud CDN) or read replicas for read-heavy access, and choose the data store that fits the access pattern. |
| PERF-4.1 | Performance optimization | Define clear performance goals and metrics | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| PERF-4.2 | Performance optimization | Monitor performance | Implemented | Diagram: Observability shown. Nodes: mon, log. Collect metrics, logs and traces with Cloud Monitoring, Cloud Logging, Cloud Trace and Managed Service for Prometheus, define SLOs and alert on burn rate. |
| PERF-4.3 | Performance optimization | Incentivize continuous improvement | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| SUS-1.1 | Sustainability | Understand the carbon intensity of cloud regions | Cannot Determine | Diagram: Region choice is not tied to carbon intensity. Choose regions using Google's carbon-free energy (CFE%) data and grid carbon intensity when latency and data residency allow; use the Carbon Footprint report to track emissions. |
| SUS-1.2 | Sustainability | Incorporate CFE in your location-selection strategy | Cannot Determine | Diagram: Region choice is not tied to carbon intensity. Choose regions using Google's carbon-free energy (CFE%) data and grid carbon intensity when latency and data residency allow; use the Carbon Footprint report to track emissions. |
| SUS-1.3 | Sustainability | Use time-of-day scheduling | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-2.1 | Sustainability | Architect for energy efficiency by using TPUs | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-2.2 | Sustainability | Follow the 4Ms best practices for resource selection | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-2.3 | Sustainability | Optimize AI models and algorithms for training and inference | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| SUS-2.4 | Sustainability | Follow best practices for AI and ML operations | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-3.1 | Sustainability | Implement automated and dynamic scaling | Cannot Determine | Diagram: No managed or serverless services shown. Prefer managed and serverless services with automatic scaling, schedule batch work for low-carbon periods and right-size resources. |
| SUS-3.2 | Sustainability | Use scheduling and batches | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-3.3 | Sustainability | Match VM machine families to workload requirements | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| SUS-3.4 | Sustainability | Upgrade to the latest machine types | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-3.5 | Sustainability | Deploy containerized applications | Cannot Determine | Diagram: No managed or serverless services shown. Prefer managed and serverless services with automatic scaling, schedule batch work for low-carbon periods and right-size resources. |
| SUS-3.6 | Sustainability | Configure carbon-aware scheduling | Cannot Determine | Not observable from the architecture diagram; needs IaC or configuration evidence. |
| SUS-3.7 | Sustainability | Architect energy-efficient disaster recovery | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-4.1 | Sustainability | Minimize computational work | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-4.2 | Sustainability | Use efficient algorithms and data structures | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-4.3 | Sustainability | Optimize compute and data operations | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-4.4 | Sustainability | Implement frontend optimization | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-5.1 | Sustainability | Prioritize high-value data | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| SUS-5.2 | Sustainability | Optimize storage lifecycle management | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-5.3 | Sustainability | Optimize regionality and data movement | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-6.1 | Sustainability | Phase 1: Establish a baseline | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-6.2 | Sustainability | Phase 2: Identify carbon hotspots | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-6.3 | Sustainability | Phase 3: Implement targeted optimization | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-6.4 | Sustainability | Phase 4: Institutionalize your sustainability practices and reporting | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-7.1 | Sustainability | Provide business context and alignment with organizational goals | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| SUS-7.2 | Sustainability | Provide role-based sustainability training | Cannot Determine | Not observable from the architecture diagram; needs process or organizational evidence. |
| SUS-7.3 | Sustainability | Advocate for sustainability and recognize success | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
| SUS-7.4 | Sustainability | Incentivize sustainability efforts | Cannot Determine | Not observable from the architecture diagram; needs runtime or operational evidence. |
Findings
No gaps are evidenced in the diagram. That is not a clean bill of health: see the coverage audit for what could not be determined.
To confirm not drawn, so not counted as gaps
- No private access or VPC Service Controls shown for managed data services SEC-2.1, SEC-7.10 — Reach Google APIs and managed data services through Private Google Access or Private Service Connect and put sensitive projects inside a VPC Service Controls perimeter.
- No identity / authentication service shown SEC-2.2 — Authenticate and authorize every request: Identity-Aware Proxy or Identity Platform for users, least-privilege IAM roles and dedicated service accounts with Workload Identity for workloads.
- No threat detection or posture management shown SEC-2.3, SEC-4.1 — Enable Security Command Center (Premium where justified), Cloud Audit Logs including Data Access for sensitive services, and Cloud IDS; route security logs to a central, access-restricted sink.
- No backup or recovery capability shown REL-8.2, REL-8.1 — Protect data with Backup and DR Service or automated backups with point-in-time recovery, snapshots, object versioning and cross-region replicas, and test restores against your RPO/RTO.
- No queue / event service shown between tiers REL-6.3, PERF-3.1 — Decouple tiers with Pub/Sub, Cloud Tasks or Eventarc so traffic spikes and downstream failures do not cascade; add retries with exponential backoff, timeouts and load shedding.
- No infrastructure-as-code or CI/CD shown OE-4.1, OE-4.3 — Define infrastructure as code (Terraform / Infrastructure Manager or Config Connector) and deploy through Cloud Build and Cloud Deploy with small, reversible changes, environment promotion and automated rollback.
- No cost visibility shown COST-2.1, COST-2.6, COST-2.7 — Apply a consistent label scheme, export billing data to BigQuery and set Cloud Billing budgets with alert thresholds so spend maps to this workload and its owner.
- Region choice is not tied to carbon intensity SUS-1.1, SUS-1.2 — Compare candidate regions by carbon-free energy percentage and grid carbon intensity (Google Cloud region picker) and use the Carbon Footprint report to track emissions.
- No managed or serverless services shown SUS-3.1, SUS-3.5 — Prefer managed and serverless services with automatic scaling, schedule batch and non-urgent work for low-carbon periods and right-size what remains.
Eisenhower prioritization
Do First
None
Plan
None
Delegate
None
Defer
None
Next steps
- Add the missing process, configuration and runtime evidence to turn Cannot Determine practices into assessed ones.
- Re-run the review after changes, and when the architecture or documentation changes.
Impact × Likelihood matrix from the AWS well-architected-review skill, applied to the Google Cloud Well-Architected Framework (Severe+High = Critical; Severe+Medium/Low or Moderate+High = High; Moderate+Medium/Low or Minor+High = Medium; otherwise Low).