How to perform an IT infrastructure assessment
across AWS, Azure, and Google Cloud

Most cloud assessments I have reviewed start with some bias already in place. Sometimes the enterprise has already chosen a vendor. Sometimes existing commercial relationships influence the direction. Sometimes the assessment is used to validate a decision that was made before the assessment began.

This article tries to do something different.

This article is not a cloud sales pitch. It does not try to prove that one public cloud is better than another. AWS, Azure, and Google Cloud are all capable platforms. The purpose of this article is to explain how an enterprise should assess cloud infrastructure decisions calmly, practically, and responsibly.

The framework covers ten assessment dimensions. It includes checklists, scoring models, architecture decision points, and the mistakes that enterprises commonly make. It is written for enterprise architects, cloud architects, infrastructure managers, and anyone responsible for making cloud infrastructure decisions that will need to hold up over five to ten years.

The Cloud Infrastructure Assessment Lifecycle

Before moving through each assessment dimension, it helps to understand the overall flow. An assessment is not a point-in-time activity. It is a structured lifecycle that begins before any cloud decision is made and continues long after go-live.

Each stage produces a specific output. Discovery produces an asset inventory and dependency map. Classification produces a workload register with cloud suitability ratings. Fitment analysis produces a shortlist of candidate platforms. The multi-dimension assessment is the core of this article. Target architecture and migration roadmap follow from the findings. Operating model design and exit strategy review are the two stages most commonly deferred — and most expensive to retrofit.

1. Cost Assessment

Cloud cost is not a billing problem. It is an architecture problem. The majority of cloud overspend comes from decisions made during design — not from engineers leaving resources running by accident. Oversized compute, incorrect storage tiers, data transfer patterns that were never modelled, and reserved capacity bought for workloads subsequently retired: these are architecture failures dressed up as finance problems.

A cost assessment must go further than running a cloud pricing calculator. It must examine total cost of ownership across a realistic three-year horizon, including migration cost, re-skilling cost, tooling cost, support contract cost, and egress cost — the last of which is consistently underestimated.

What to assess

FinOps governance note

Cloud cost governance — commonly called FinOps — needs to be designed before migration begins, not added after the first surprise bill arrives. This means establishing a cost allocation taxonomy, assigning financial accountability at the workload level, and agreeing on a review cadence. Without this, cloud cost becomes a shared pool that no one owns and everyone underestimates.

2. Security Assessment

All three public clouds provide a capable security foundation. The shared responsibility model is well understood. The failure point in enterprise cloud security is almost never the cloud provider — it is the decisions made about identity, network boundaries, data classification, and key management during the design and migration phase.

Identity and access model

Identity is the perimeter in cloud. The question is not whether your cloud environment has a firewall — it is whether every access path is governed by identity, whether that identity model is integrated with your enterprise directory, and whether privilege is constrained by design rather than enforced by process.

Network connectivity and DNS

Cloud network design requires explicit decisions about connectivity to on-premises, inter-region routing, DNS resolution, and private endpoint usage. Enterprises that rely on public endpoints for internal workloads because it was "easier at the time" consistently accumulate network-level security debt that is expensive to fix later.

Data residency

Data residency is a compliance and legal requirement, not a preference. It must be assessed before region selection, not after. For enterprises operating across the EU, Middle East, India, and Southeast Asia, this typically means explicit verification that data processing, backup, and disaster recovery do not cross residency boundaries — including in managed services where replication behaviour may not be obvious from the service documentation.

3. Scalability Assessment

Scalability is one of the most frequently overstated arguments for cloud adoption. Cloud does scale elastically — but only if workloads are designed to take advantage of it. An application with a monolithic architecture, a shared database, and no horizontal scaling capability will not benefit from cloud elasticity. It will simply run on more expensive infrastructure.

A scalability assessment must be honest about the application architecture, not just the infrastructure. The key questions are: what scales horizontally today, what requires vertical scaling, and what has hard limits imposed by the application design that infrastructure decisions cannot solve?

Architecture decision point

Before investing in cloud scalability design, establish whether the application tier or the data tier is the binding constraint. In many enterprise workloads, the database is the binding constraint rather than the compute tier. Cloud auto-scaling of the application tier delivers limited value if the database cannot scale accordingly. This decision — whether to re-architect the data tier before migrating — must be made before migration, not discovered after it.

4. Reliability and Disaster Recovery Assessment

Cloud availability SLAs are frequently misread. A 99.9% monthly uptime SLA for a single compute instance means approximately 43 minutes of permitted downtime per month — before the enterprise's own application failures, dependency failures, and deployment errors are factored in. Composite reliability — the reliability of the end-to-end workload — is always lower than the SLA of any single component.

Reliability and DR design must start from the business requirement: what is the acceptable recovery time objective (RTO) and recovery point objective (RPO) for each workload? Then it must work backwards to the infrastructure design required to meet that target.

Backup and restore testing

Backup without verified restore is not a backup. It is a false sense of security. In complex technology environments, the failure is often that the restore process has not been tested under realistic conditions. Backup and restore testing must be a scheduled, documented operational activity — not a one-time proof-of-concept at project launch.

5. Accessibility and Ease of Operations

An operationally manageable cloud environment is one that your team can actually run — not one that looks elegant in a presentation. Operational complexity is a risk. The more tooling, the more specialised the skills required, and the more configuration required to keep things running, the higher the operational risk when things go wrong — which they will.

Observability and logging

Observability must be designed in, not added after an incident. The three pillars — metrics, logs, and traces — need to be captured, retained, correlated, and accessible. For multi-cloud environments, this typically means a centralised observability platform that aggregates data from all three clouds rather than three separate native monitoring tools.

Cloud landing zone readiness

A landing zone is the pre-built, governed account or subscription structure into which workloads are deployed. It includes network topology, identity federation, logging configuration, policy enforcement, and security baseline — all established before any production workload is migrated. Enterprises that skip landing zone design spend months retroactively applying controls to environments that were never designed for them.

6. Adaptability and Future Readiness

Adaptability does not mean using the latest services. It means building an environment that can absorb change — regulatory change, workload change, organisational change, and technology change — without requiring a full rearchitecture every two years.

The enterprise architectures that age well tend to share two things. First, they separate the infrastructure layer from the application layer cleanly, so one can change independently of the other. Second, they do not build deep dependencies on proprietary managed services until those services have been proven necessary — because proprietary services are the fastest path to lock-in.

Architecture decision point

Evaluate proprietary services carefully. Using a cloud provider's proprietary messaging queue, proprietary container orchestration, or proprietary ML pipeline may accelerate the first delivery. It also means that if you need to move — for cost, compliance, or commercial reasons — the migration effort scales with the depth of that dependency. Open standards, open-source tooling, and abstraction layers preserve optionality.

7. Cloud Operating Model

The cloud operating model is the most consistently underdeveloped aspect of enterprise cloud adoption. Technology decisions receive months of attention. The operating model — who owns what, how changes are managed, how costs are governed, how incidents are handled — is often addressed in the final weeks of a programme and never quite finished.

An operating model covers four things: ownership (who is accountable for each component), process (how changes, incidents, costs, and compliance are managed), tooling (what platforms support operations at scale), and people (what skills are needed and where they will come from).

Skills and support model

Cloud skills gaps are real. The gap is not usually in knowledge of a cloud portal — it is in understanding distributed systems behaviour, infrastructure as code, security design, and cost governance. Skills assessment must be honest and must lead to a concrete plan: training, hiring, or a managed service arrangement, with a realistic timeline.

Change management

Cloud environments change rapidly. New services are released weekly. Existing service capabilities are updated. Deprecations occur. Without a structured change management process — that covers both the cloud provider's service changes and your own infrastructure changes — drift accumulates and environments become difficult to reason about.

8. Governance and Compliance

Governance in cloud is not a one-time audit. It is a continuous control environment. The difference between on-premises governance and cloud governance is that in cloud, infrastructure can be provisioned in minutes by anyone with the right IAM permissions. Without policy-as-code guardrails at the platform level, governance becomes a retrospective activity — finding problems after they have occurred rather than preventing them.

Risk register

Every cloud programme should maintain an active risk register — not a document produced for a governance forum and then filed. A living register that captures the specific technical, operational, compliance, and commercial risks of the cloud environment, with assigned owners, agreed mitigations, and review dates. The risks that matter most in cloud are often undramatic: cost overrun, data residency breach, identity misconfiguration, and the gradual loss of operational knowledge as teams change.

Decision log

Architectural decisions made during a cloud programme are frequently lost. The person who made a specific networking choice, chose a particular managed service, or accepted a particular compliance trade-off moves on. Their successor inherits the outcome but not the reasoning. A decision log — even a simple one — captures the context, the alternatives considered, and the reason a decision was made. It is one of the most underused tools in enterprise architecture.

9. Skills and Support Model Assessment

This section is often treated as a human resources concern. It is an architecture concern. The support model — whether operations are managed in-house, outsourced, or run through a managed cloud service — determines what architecture complexity is sustainable. An architecture that requires deep specialisation in three cloud platforms to operate is not fit for an internal team of six engineers. The architecture must match the operational capability.

10. Exit Strategy and Vendor Lock-In Control

An exit strategy is not a plan to leave. It is a control mechanism. Enterprises that have thought through how they would leave a cloud provider — and have made architecture decisions that keep that option viable — are in a fundamentally stronger commercial and operational position than those who have not. The ability to leave, even if you never use it, improves the terms on which you stay.

Vendor lock-in is not inherently bad. Using a managed Kubernetes service, a managed relational database, or a managed message queue reduces operational overhead. The question is not whether to use managed services — it is whether you understand the portability cost if you need to move, and whether that cost is acceptable given the operational benefit you are receiving.

Assessment Scoring Model

The following scoring model can be applied to each of the ten assessment dimensions. It is deliberately simple. The purpose of a scoring model is to surface gaps and create a conversation — not to produce a precise numerical output that obscures judgement.

Multi-Cloud Assessment: Where Each Platform Differs

The table below is not a vendor comparison designed to declare a winner. It reflects observable differences in how the three platforms approach specific dimensions. Enterprises will weight these differently depending on their workload profile, existing investments, regulatory environment, and operational model. No single platform is universally stronger across all dimensions for all enterprises. Each dimension should be validated against your specific context.

Mistakes Enterprises Commonly Make

When Not to Move a Workload to Cloud

A responsible assessment should also identify workloads that should not move immediately. Cloud is not automatically better for every system. Some workloads may be better retained, retired, replaced, or modernised before migration.

Architect's takeaway: A good cloud assessment does not only approve migrations. It also protects the enterprise from moving the wrong workload at the wrong time.

Conclusion

A cloud infrastructure assessment is not a document produced to justify a decision that was already made. It is a structured discipline for making decisions that will hold up under scrutiny, over time, at scale, and under cost pressure. The ten dimensions in this framework are not exhaustive — but they cover the areas where most enterprise cloud programmes run into serious difficulty.

The platform you choose matters less than the discipline with which you design, govern, and operate your environment. AWS, Azure, and Google Cloud are all capable of running enterprise workloads at scale. The failures that surface after go-live are rarely platform failures. They are design failures, governance failures, and operating model failures — decisions made quickly under project pressure that become expensive to undo.

Assess before you commit. Govern from day one. Build with portability in mind, even when you do not expect to use it. Test your restore procedures before you need them. Design your operating model with the same care you give to your network topology. Keep a risk register that is alive, not archived. And treat exit strategy not as a failure plan, but as evidence of architectural maturity.

Simple infrastructure thinking. Calm architecture. Practical decisions. No unnecessary complexity.