Cloud Architecture Assessment: Building a Universal Framework

Introduction: Why Vendor Frameworks Are Not Enough

When a CTO, Lead Architect, or FinOps manager initiates a Cloud Architecture Assessment, they are usually trying to solve a specific problem: cloud bills are out of control, the infrastructure fails under load, or the company is preparing for an M&A technical due diligence. They do not need a theoretical dictionary; they need an actionable audit process to find root causes and implement solutions.

The standard industry approach is to use vendor-provided methodologies like the AWS Well-Architected Framework or Google Cloud Architecture Framework. While these are solid starting points, they have a fundamental flaw: vendor bias.

Vendor frameworks are designed to keep you inside their ecosystem. If you have a scaling issue on AWS, the AWS framework will likely suggest implementing another AWS service. A universal framework, on the other hand, evaluates your architecture against core engineering principles, performance metrics, and cost efficiency, regardless of the cloud provider.

This guide introduces a universal assessment framework. We will break down the cloud infrastructure into logical layers, identify the root causes of common failures, analyze anti-patterns, and provide real-world case studies for each level.

Part 1. Cost and Resource Level (FinOps & Compute)

FinOps is not just about cutting costs; it is about paying exactly for what you consume and maximizing the business value of every dollar spent on infrastructure. The assessment always starts here because infrastructure inefficiencies directly impact the company’s financial runway.

Methodology Comparison: AWS vs. Google Cloud (GCP)

Understanding how different clouds bill for resources is critical for an accurate assessment. Evaluating a GCP environment with an AWS mindset will lead to false conclusions.

Feature / Model	AWS Approach	Google Cloud (GCP) Approach	Assessment Focus
Compute Discounts	Reserved Instances (RIs) & Savings Plans (requires manual commitment and upfront planning).	Sustained Use Discounts (automatic) & Committed Use Discounts (CUD).	Check if the team manually monitors and adjusts commitments based on actual usage.
Data Warehouse (DWH)	Redshift / Athena (often billed by node hours or data scanned per query).	BigQuery (On-demand by bytes processed OR Capacity pricing via Slots).	Evaluate if the DWH pricing model matches the current workload (predictable vs. ad-hoc queries).
Spot Instances	Spot Instances (prices fluctuate based on market demand).	Spot VMs (formerly Preemptible VMs, fixed discount up to 90%).	Verify if stateless, fault-tolerant workloads are properly utilizing spot instances.

Standard Errors and Root Causes

Error: The “Lift and Shift” Migration (Rehosting).

The team moves an existing on-premise application to the cloud by exactly copying the server configurations. A 32-core physical server becomes a 32-core cloud virtual machine (VM).

Root Cause:

Treating the cloud as a traditional remote data center. The team lacks cloud-native design experience or is forced to migrate under unrealistic deadlines. As a result, the application cannot scale horizontally, and the company pays for peak capacity 24/7, even when the system is idle.

Anti-patterns to Detect

During the assessment, look for these specific FinOps anti-patterns:

1. Zombie Resources and Unattached Disks: Cloud environments are dynamic. VMs get deleted, but their attached storage blocks (EBS in AWS, Persistent Disks in GCP) or static IP addresses often remain behind, accumulating monthly charges.
2. Overprovisioning (Sizing for Peak): Allocating CPU and RAM based on maximum possible load rather than average load.
3. Missing Lifecycle Policies: Object storage (S3/GCS) containing old backups or application logs that are never moved to cheaper cold storage (Glacier/Archive) or deleted.

Practical Assessment Step:

You can identify zombie resources using basic CLI commands. For example, to find all unattached disks in GCP that are silently draining the budget:

Bash

# GCP: Find disks that are not in use by any instance
gcloud compute disks list --filter="-users:*" --format="table(name, zone, sizeGb, type)"

Bash

# AWS: Find available (unattached) EBS volumes
aws ec2 describe-volumes --filters Name=status,Values=available --query "Volumes[*].{ID:VolumeId,Size:Size,Type:VolumeType}" --output table

Real Case Study: Kubernetes (GKE) vs. Cloud Run TCO

Context: A mid-sized SaaS company ran a set of stateless microservices on a Kubernetes cluster (GKE). Their monthly compute bill was heavily inflated.

Assessment Findings:

The team chose Kubernetes because it is an industry standard, not because their architecture required it.

1. Overhead: They were paying for the Kubernetes control plane and running multiple nodes to ensure high availability, even though their traffic was low during the night.
2. Resource Waste: The CPU utilization of the nodes rarely exceeded 20%.

Solution & TCO Optimization:

Since the microservices were stateless HTTP containers, the workload was migrated to Google Cloud Run (a fully managed serverless compute platform).

• Result: Cloud Run scales to zero when there is no traffic. The company stopped paying for idle node capacity and cluster management overhead. The compute bill dropped by 65%, and the DevOps team spent zero hours on node patching and cluster upgrades.

Section 1 Takeaways for the Assessor

• Do not trust the dashboard: Always check billing exports (e.g., BigQuery billing export) to find hidden costs.
• Question the architecture, not just the bill: High costs are usually a symptom of poor architectural choices (like choosing Kubernetes for simple stateless APIs), not just high vendor prices.
• Establish tags/labels: If resources are not strictly labeled by project, team, or environment, FinOps is impossible. Enforcing a strict tagging policy is the first corrective action.

Part 2. Infrastructure as Code (IaC) and Automation (CI/CD)

Evaluating a cloud environment without assessing how it is provisioned is a critical mistake. If the infrastructure is built manually via the web console (“ClickOps”), it is impossible to scale, audit, or recover from a disaster reliably. A proper assessment treats Infrastructure as Code (IaC) — usually Terraform — as the absolute source of truth.

Methodology Comparison: Cloud Hierarchy and IaC Structure

How a cloud provider organizes its resources fundamentally dictates how your Terraform repositories should be structured. Applying an AWS Terraform structure to a GCP environment will lead to massive permission and isolation issues.

Feature	AWS Approach	Google Cloud (GCP) Approach	Assessment Focus
Resource Isolation	AWS Organizations (Multi-Account Strategy). Complete hard boundaries between accounts.	Resource Manager (Organization > Folders > Projects). Hierarchical and inherited.	Ensure Terraform state boundaries align with the cloud’s isolation boundaries (e.g., separate state per GCP Project/AWS Account).
State Storage	S3 Bucket + DynamoDB for state locking.	Google Cloud Storage (GCS) with native built-in state locking.	Verify that remote backends are encrypted, versioned, and have strict access controls.
Service Identity	IAM Roles (assumed by services).	Service Accounts (acting as identities).	Check if CI/CD pipelines use temporary credentials (OIDC) instead of static keys.

Standard Errors and Root Causes

Error: Configuration Drift (State Drift).

The Terraform code in the Git repository no longer matches the actual resources running in the cloud. When a developer runs terraform plan, it wants to destroy or recreate critical databases.

Root Cause:

A lack of strict IAM policies enforcing GitOps. Administrators or developers retain “Editor” or “Owner” permissions in the cloud console, allowing them to manually patch resources during incidents. Once a manual change is made, the IaC state is broken. The root cause is a broken CI/CD culture, not a Terraform bug.

Anti-patterns to Detect

When auditing IaC, look for these dangerous patterns:

1. The Monolithic State File: Putting the entire infrastructure (VPC, databases, Kubernetes clusters, DNS) into a single main.tf file and a single state. If someone makes a typo in a DNS record, a failed terraform apply could lock or destroy the database.
2. Hardcoded Secrets: Storing database passwords or API keys in plaintext inside Terraform files instead of using Secret Manager (GCP) or AWS Secrets Manager.
3. Local State Execution: Engineers running terraform apply from their local laptops instead of a centralized CI/CD runner. This leads to conflicting states and untracked changes.

Practical Assessment Step:

To quickly assess the health of an IaC environment, check for drift. In a healthy environment, a plan against production should return zero changes.

Bash

# A healthy infrastructure should output: "No changes. Your infrastructure matches the configuration."
terraform plan -detailed-exitcode

Real Case Study: Refactoring a Monolithic State

Context: A rapidly growing startup managed their entire GCP infrastructure in a single Terraform state. Deployment times reached 20+ minutes, and engineers were afraid to deploy changes due to the risk of accidentally affecting the production database.

Assessment Findings:

The blast radius was too large. Development, Staging, and Production environments were mixed in the same repository folder.

Solution:

We designed a modular structure based on blast radius isolation. The monolith was split into independent layers: networking, data-layer, and app-layer, separated by environment (prod, stage, dev).

Instead of destroying and recreating resources (which would cause downtime), we used the terraform state mv command to migrate existing resources into the new, isolated state files.

• Result: CI/CD pipeline execution dropped to under 2 minutes. The development team could safely test application layer changes without any risk to the core VPC or BigQuery datasets.

Section 2 Takeaways for the Assessor

• Enforce OIDC: CI/CD runners (like GitHub Actions or GitLab CI) should never use static long-lived JSON/CSV keys. Always use Workload Identity Federation (OIDC) for temporary authentication.
• Blast Radius: Assess IaC by asking: “If a junior engineer merges a bad pull request, how much of the system goes down?”

Part 3. Data Architecture and Telemetry Pipelines

Data is the most expensive asset to move, store, and query. A poorly designed data architecture not only slows down decision-making but can literally bankrupt a project through exponential query costs. The assessment at this level focuses on ingestion, processing, and storage logic.

Methodology Comparison: DWH Paradigms

The architectural approach to Data Warehouses (DWH) differs drastically between cloud providers.

Feature	AWS Redshift	GCP BigQuery	Assessment Focus
Architecture	Cluster-based. Tightly coupled storage and compute (traditionally).	Serverless. Fully decoupled storage and compute.	Ensure the team understands they are managing slots/bytes (GCP) versus nodes (AWS).
Scaling	Scaling clusters takes minutes to hours (requires provisioning).	Scales instantly behind the scenes.	Verify if the architecture relies on real-time elasticity or predictable steady loads.
Cost Model	Pay for the cluster uptime, regardless of query volume.	Pay per TB of data scanned (On-demand) or per Compute capacity (Slots).	Check if query optimization is part of the engineering culture (crucial for BigQuery on-demand).

Standard Errors and Root Causes

Error: Exponentially growing DWH costs and dashboard timeouts.

A BI dashboard built on Data Studio (Looker) or Tableau takes 30 seconds to load and costs $10 every time a manager opens it.

Root Cause:

Treating analytical columnar databases (OLAP) like traditional relational databases (OLTP). Engineers write SELECT * queries or fail to implement partitioning and clustering. In BigQuery, if you don’t partition a 10TB table by date, querying a single day’s data will still scan (and charge for) the entire 10TB.

Anti-patterns to Detect

1. Direct Client-to-DWH Writes: Sending raw, unvalidated frontend telemetry directly to the data warehouse. This leads to schema pollution, dirty data, and high ingestion costs.
2. ETL instead of ELT in the Cloud: Processing massive datasets outside the DWH (e.g., pulling data to a Python script, transforming it, and pushing it back) instead of using the DWH’s native compute power (ELT) via tools like Dataform or dbt.
3. Lack of Data Lifecycle: Storing raw telemetry forever in active storage instead of moving historical data to cold storage or aggregating it.

Practical Assessment Step:

In BigQuery, you can audit the most expensive and inefficient queries over the past 30 days using the INFORMATION_SCHEMA:

SQL

-- Find queries scanning the most data (indicating lack of partitioning)
SELECT
  user_email,
  query,
  total_bytes_billed / (1024*1024*1024) AS gigabytes_billed,
  cache_hit
FROM
  `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND job_type = 'QUERY'
ORDER BY
  total_bytes_billed DESC
LIMIT 10;

Real Case Study: Server-Side Tracking and FinOps Optimization

Context: An e-commerce platform was sending gigabytes of raw user behavior events directly from client browsers to their backend, and then to BigQuery. Ad blockers were skewing the data, and BigQuery costs were skyrocketing due to constant unstructured inserts and heavy transformations.

Assessment Findings:

The pipeline lacked a validation layer. Marketing pixels were slowing down the website, and the data engineering team was spending 40% of their time cleaning dirty data in BigQuery.

Solution:

We implemented a Server-Side Google Tag Manager (sGTM) architecture deployed on Google Cloud Run.

1. Client devices now send a single data stream to the sGTM endpoint (first-party context).
2. Cloud Run acts as a validation and routing layer. It filters out bot traffic, strips PII (Personally Identifiable Information), and routes clean data to BigQuery.
3. Inside BigQuery, we implemented Dataform to manage SQL pipelines, creating partitioned and clustered tables for BI reporting.

• Result: Data accuracy improved by 25% (bypassing ad blockers via first-party domain). BigQuery processing costs dropped by 45% because transformations were running on pre-validated, partitioned data via Dataform, rather than raw messy logs.

Section 3 Takeaways for the Assessor

• Partitioning is not optional: Any table larger than 10GB must be partitioned (usually by time) and clustered.
• Validate at the edge: Never let untrusted client data touch the DWH directly. Use an intermediate layer (like Cloud Run + sGTM or Pub/Sub) to enforce schemas.

Part 4. Security and Access Management (Security & IAM)

In modern cloud architecture, the network is no longer the primary security perimeter; identity is. If your Identity and Access Management (IAM) is compromised, network firewalls will not protect your data. A professional assessment assumes that a breach is inevitable and evaluates how the architecture limits the “blast radius” of that breach.

Methodology Comparison: Identity vs. Resource Policies

AWS and GCP handle permissions differently. An architect migrating from one to the other often makes critical security errors by misunderstanding these core paradigms.

Feature	AWS Approach	Google Cloud (GCP) Approach	Assessment Focus
Core Paradigm	Identity-based. You attach JSON policies to IAM Users or Roles.	Resource-based. You bind Roles to Members (users/service accounts) at a specific resource level (Project, Folder, Bucket).	Verify if permissions are applied at the lowest possible level, not universally at the root account.
Machine Identity	IAM Roles (which EC2 or Lambda functions assume).	Service Accounts (treated as both an identity and a resource).	Check if compute resources run under default service accounts (a major security risk).
Network Boundaries	VPC Endpoints to keep traffic to cloud services internal.	VPC Service Controls (VPC SC) to build a secure perimeter around Google APIs.	Ensure internal data processing never travels over the public internet.

Standard Errors and Root Causes

Error: Cloud Ransomware or Crypto-mining incidents.

A company discovers a sudden $50,000 charge for maximum-capacity compute instances deployed in a remote region, or finds their cloud storage deleted and replaced with a ransom note.

Root Cause:

Developer convenience prioritized over security. To avoid “Access Denied” errors during rapid development, engineers assign broad primitive roles (like Owner or Editor in GCP, or AdministratorAccess in AWS) to CI/CD pipelines or application service accounts. Furthermore, they generate long-lived static JSON/CSV access keys and store them on local machines or in unencrypted Git repositories.

Anti-patterns to Detect

1. Use of Primitive Roles: Using roles like roles/editor for a microservice that only needs to read a specific BigQuery table.
2. Long-lived Access Keys: Having active Service Account JSON keys older than 90 days.
3. Public Database IPs: Assigning public IP addresses to database instances (Cloud SQL / RDS) and relying solely on username/password authentication instead of private VPC peering and IAM-based authentication.
4. Open Cloud Storage: S3 buckets or GCS buckets with allUsers or allAuthenticatedUsers read/write access.

Practical Assessment Step:

You can quickly audit a GCP project to find all active Service Account keys. If a key is user-managed and old, it is a high-security risk.

Bash

# GCP: List all service accounts and identify user-managed keys
gcloud iam service-accounts list --format="table(email, disabled)"

# To check keys for a specific service account:
gcloud iam service-accounts keys list \
    --iam-account=my-service-account@my-project.iam.gserviceaccount.com \
    --managed-by=user

Real Case Study: Implementing the Principle of Least Privilege (PoLP)

Context: A fintech startup was preparing for an ISO 27001 audit. Their backend consisted of 15 microservices running on Cloud Run, all using the exact same Default Compute Service Account, which had Editor permissions on the entire GCP project.

Assessment Findings:

If a single microservice was compromised via a vulnerability, the attacker would gain write access to the production databases, storage buckets, and networking configurations.

Solution:

We conducted an IAM audit and implemented Workload Identity and PoLP.

1. Created 15 dedicated Service Accounts (one for each microservice).
2. Used Terraform to map exact permissions. For example, the invoice-generator service was given only roles/storage.objectCreator for a specific GCS bucket and nothing else.
3. Deleted all static JSON keys and enforced temporary, short-lived OIDC tokens for the CI/CD pipeline deployments.

• Result: The blast radius was isolated. The startup passed the ISO 27001 audit with zero non-conformities regarding access control.

Part 5. Implementation of the Universal Framework (Synthesis)

Identifying errors is only 20% of an assessment. The remaining 80% is synthesizing those findings into an actionable, prioritized roadmap. A 100-page PDF report is useless if the engineering team does not know where to start.

This is how you apply the Universal Framework in practice.

The Scoring Matrix

For every area assessed across the four levels (FinOps, IaC, Data, Security), assign a strict severity score. Do not use complex numbering; use a simple traffic-light system based on business risk:

• Critical (Red): Active security vulnerabilities, massive cost bleeding (e.g., thousands of dollars wasted monthly), or extreme risk of data loss. Action required: Within 24-48 hours.
• Warning (Yellow): Architectural bottlenecks, IaC technical debt, unoptimized DWH queries. Action required: Next 1-2 Sprint cycles.
• Healthy (Green): Follows best practices. Document as a baseline.

The Prioritization Grid (Action Plan)

Once the scoring is done, plot the “Red” and “Yellow” items onto an Effort vs. Impact grid. This translates engineering problems into business language for management.

Priority Level	Category	Examples from the Framework	Action
Priority 1	High Impact, Low Effort (Quick Wins)	Deleting zombie disks; removing unused Owner IAM keys; enabling basic BigQuery caching.	Execute immediately. These build trust with stakeholders and instantly free up budget.
Priority 2	High Impact, High Effort (Strategic)	Refactoring monolithic Terraform state; migrating from Kubernetes to Cloud Run; rewriting DWH pipelines to ELT.	Plan as technical epics. Require dedicated engineering time and architecture design.
Priority 3	Low Impact, Low Effort (Housekeeping)	Applying strict tagging policies; updating minor Terraform provider versions.	Delegate. Add to standard weekly engineering tasks.
Priority 4	Low Impact, High Effort (Distractions)	Building complex multi-cloud failovers for non-critical internal apps.	Discard. Do not waste engineering resources on theoretical perfection.

How to Run the Assessment Workflow

If you are a CTO or Lead Architect using this framework for an internal audit, follow this strict sequence:

1. Phase 1: Passive Discovery (Days 1-2)
   • Do not ask developers how the system works; they will tell you how it is supposed to work. Look at the actual state.
   • Export billing data to BigQuery. Analyze the top 5 most expensive services.
   • Run read-only CLI scripts to export IAM policies and Terraform state outputs.
2. Phase 2: Gap Analysis (Days 3-5)
   • Compare the passive discovery data against the Anti-patterns listed in Parts 1-4.
   • Identify the root causes. Never document “Server is too expensive.” Document “Lift-and-shift architecture results in 80% idle compute capacity.”
3. Phase 3: The Roadmap (Day 6)
   • Compile the Scoring Matrix and Prioritization Grid.
   • Deliver the roadmap with calculated ROI (e.g., “Spending 40 hours to refactor this Terraform state will prevent X hours of downtime and save $Y per month”).

Conclusion

A Cloud Architecture Assessment is not a one-time event; it is a continuous engineering discipline. Vendor-specific frameworks are useful checklists, but a Universal Framework focuses on the fundamental physics of cloud computing: Cost (FinOps), Automation (IaC), Data Efficiency, and Identity Security.

By evaluating your infrastructure against these four pillars, finding root causes rather than symptoms, and prioritizing fixes based on business impact, you transform cloud infrastructure from an unpredictable expense into a manageable, scalable asset.

Appendix: Advanced Architectural Considerations

While the Universal Framework covers the primary pillars of cloud infrastructure, enterprise-grade architectures often require deep dives into specialized domains. During a comprehensive Cloud Architecture Assessment, auditors should also evaluate the following advanced edge cases and metrics.

1. Observability and SRE (Site Reliability Engineering)

An infrastructure is only as reliable as its monitoring system. We previously discussed data pipelines for business intelligence, but infrastructural telemetry is equally critical.

• The Assessment Gap: Teams often have monitoring tools (Datadog, Prometheus, Google Cloud Operations) installed, but lack actionable alerting. If a dashboard is red but no one receives a notification, the observability layer has failed.
• Key Metrics to Audit: Evaluate the system’s MTTD (Mean Time to Detect) and MTTR (Mean Time to Resolve).
• Anti-pattern: “Alert Fatigue.” Configuring alerts for CPU spikes (which are normal in auto-scaling environments) instead of alerting on SLIs (Service Level Indicators) like increased HTTP 500 error rates or elevated latency.

2. Disaster Recovery (DR) and Business Continuity

Assuming your cloud provider will never experience a region-wide outage is a critical business risk.

• The Assessment Gap: Many companies check the “Daily Database Backups” box and move on. However, a backup that has never been restored is just a hypothetical file.
• Key Metrics to Audit: Define and test RPO (Recovery Point Objective — how much data can the business afford to lose?) and RTO (Recovery Time Objective — how long can the system stay down?).
• Anti-pattern: “Schrödinger’s Backup.” Backups are taken regularly, but the team has never performed a dry-run restoration. When a disaster strikes, they discover the backups are corrupted or take 48 hours to restore.

3. The Multi-Cloud Trap and Egress Costs

While utilizing both AWS and GCP simultaneously sounds like a great strategy for avoiding vendor lock-in, it introduces massive network complexities.

• The Assessment Gap: In FinOps, compute and storage costs are visible, but network egress costs are often hidden killers. Cloud providers do not charge for data coming in (Ingress), but they charge heavily for data going out (Egress).
• Anti-pattern: A microservice hosted on AWS querying a BigQuery dataset on GCP thousands of times a minute across the public internet. This architecture will generate astronomical NAT Gateway and Egress fees.

4. Technical Nuance: Modern Compute Discount Models

In Part 1 (FinOps), we mentioned Sustained Use Discounts (SUD) in Google Cloud, which automatically apply discounts when a VM runs for a significant portion of the month.

• Architect’s Note: It is vital for an assessor to know that GCP has deprecated SUDs for its modern, cost-efficient machine families (like E2, T2D, and C3). To achieve optimal FinOps on modern GCP infrastructure, teams must proactively adopt Committed Use Discounts (CUDs). An auditor finding older N1 machines relying on SUDs should immediately recommend migrating to newer E2/C3 instances paired with a CUD strategy for better price-to-performance ratios.