Getting Started With Cloud Architecture Due Diligence

"If the codebase is clean but the cloud bill is growing faster than the user base, is the architecture actually scalable or just expensive?"

The answer is almost always the latter. In a technical acquisition, a codebase can be refactored and a team can be hired, but a fundamentally flawed cloud architecture represents a structural liability that erodes EBITDA long after the deal closes. Cloud architecture due diligence is the process of verifying that a target's infrastructure is a scalable asset rather than a mounting operational tax. It requires moving beyond the high-level architecture diagrams provided in a data room to inspect the actual runtime telemetry, cost patterns, and security configurations.

Is the cloud spend aligned with business growth?

When reviewing the financial health of a cloud estate, the primary indicator of technical maturity is the unit economics. An acquirer must determine if the cost per customer or cost per transaction is stable, decreasing, or escalating as the system scales. If cloud expenses are rising disproportionately to revenue, this signals architectural inefficiencies such as overprovisioning or "lift-and-shift" migrations where legacy on-premises patterns were moved to the cloud without re-architecting.

The presence of a FinOps practice is a key differentiator here. A company that lacks granular cost visibility, treating the monthly AWS or Azure bill as a single, opaque line item, is a high-risk target. Mature organisations use cost allocation tags to assign spend to specific products or teams, allowing them to identify exactly which service is driving a cost spike. According to Vaultinum, poor cloud cost management is a window into a company's broader operational inefficiency and signals a lack of discipline in how they manage resources.

Does the architecture have hidden single points of failure?

Architecture diagrams in a deal room are often aspirational; they describe how the system is intended to work, not how it actually behaves under stress. Due diligence must surface the delta between the diagram and the deployment. The goal is to identify "blast radii": the extent of the impact if a single component, availability zone, or region fails.

A common failure in growth-stage companies is the "flat" architecture, where production and staging environments share resources or reside within a single cloud account. This lacks the necessary security and operational boundaries to prevent a staging error from taking down the live product. Furthermore, the resilience of the data tier must be interrogated. While a company may claim "high availability", the reality often reveals a primary database with a passive standby that has never been tested for a successful failover.

Reliability is best assessed through the incident record rather than the design document. When Cyberonix evaluates a product, they prioritise the depth of post-mortems and the recurrence of root causes over the claims made in marketing materials. If the same architectural bottleneck causes an outage every quarter, the system is fragile.

Is the security posture based on evidence or logos?

Many targets will provide SOC 2 or ISO 27001 certifications as proof of security. While these are necessary, they are point-in-time snapshots and often cover a limited scope. A rigorous cloud architecture due diligence process treats a certification logo as a starting point, not a finding. The actual posture is found in the configuration of the Identity and Access Management (IAM) policies and the visibility of the network perimeter.

The most material risks usually reside in the "low-hanging fruit" of cloud misconfiguration. This includes publicly accessible S3 buckets, shared root credentials, or a lack of Multi-Factor Authentication (MFA) on administrative accounts. Beyond these, the auditor should look for the implementation of the principle of least privilege. If every developer has AdministratorAccess in production, the risk of an accidental or malicious catastrophic event is unacceptably high.

Infrastructure-as-Code (IaC) provides the best evidence of security discipline. When infrastructure is deployed via Terraform or CloudFormation, the security guardrails are versioned and auditable. Manual changes made via the cloud console, known as "click-ops", create configuration drift that makes the environment impossible to secure consistently.

Can the operational model support the projected growth?

Operational maturity is the bridge between a working product and a scalable business. The diligence process must ask how the software is delivered and maintained. A company relying on manual deployments via SSH is a significant liability; such processes are error-prone and cannot scale with a growing engineering team.

The assessment should cover the following operational dimensions:

• CI/CD Pipeline: Is there a fully automated path from code commit to production, or is there a "manual gate" that creates a bottleneck?
• Observability: Does the team have proactive alerting based on Service Level Objectives (SLOs), or do they find out about outages from customer complaints?
• Disaster Recovery (DR): Is there a documented RTO (Recovery Time Objective) and RPO (Recovery Point Objective) that has been validated through a real-world simulation?
• Dependency Concentration: Is the product overly dependent on a single third-party API or managed service that creates an existential risk if that vendor changes their pricing or terms?
• Technical Debt: To what extent is the current architecture "holding together" via temporary patches that will require a total rewrite once the user base doubles?

The operational state of the cloud is a primary component of a broader Technical Due Diligence process, as it directly impacts the cost of maintaining the asset post-acquisition.

How do we validate these findings without breaking the system?

The challenge of cloud diligence is gaining enough access to verify claims without introducing risk to the live environment. The most effective method is requesting read-only access to the cloud accounts or utilizing automated discovery tools. Tools like Hava can generate interactive architecture diagrams based on the actual state of the cloud, removing the need to rely on outdated manual documentation.

By comparing the automated discovery against the provided documentation, an auditor can quickly spot discrepancies. If the documentation shows a multi-region deployment but the automated map shows everything in us-east-1, the target's representations are inaccurate. This discrepancy often reveals a deeper pattern of technical debt or a lack of internal oversight.

One common risk in these environments is the absence of a structured multi-account strategy. When production and staging share a single account, the risk of accidental resource deletion or privilege escalation increases. A mature target employs a landing zone approach with segregated accounts for identity, logging, and distinct environments.

Ultimately, cloud architecture is not a static asset but a living system.

The findings of the diligence process should inform the valuation and the "100-day plan" following the acquisition. If the architecture is inefficient, the opportunity for post-close value creation lies in the optimisation of these costs and the hardening of the operational framework.

Sources

• Optimizing Cloud Costs: a key factor in Tech Due Diligence: analyses how cloud spend and FinOps maturity indicate operational efficiency.
• Software & Cloud Due Diligence Consulting: discusses the importance of auditing runtime telemetry and incident records over design documents.
• Due Diligence - Digital Marketplace: outlines the scope of IT systems assessments including architecture and scalability.