Cloud Infrastructure Assessment: The Enterprise Guide

Every cloud transformation starts with the same uncomfortable realisation: nobody knows exactly what's running where. The architecture diagrams are 18 months out of date. The cost allocation is approximate. The security posture is "we think it's fine." And the compliance status is "we passed the last audit."

A cloud infrastructure assessment is the disciplined process of establishing ground truth before making decisions. It's not glamorous. But it's the difference between a cloud strategy based on reality and one based on assumptions.

What a Cloud Infrastructure Assessment Covers

A comprehensive assessment has six domains. Skipping any of them leaves blind spots that will cause problems later:

1. Architecture Discovery

Map what actually exists — not what the design documents say exists:

• Compute inventory — every VM, container, serverless function, and managed service. Include sizing, utilisation, and ownership.
• Network topology — VPCs, subnets, peering connections, VPNs, load balancers, CDNs. Document the actual traffic flows, not just the intended ones.
• Data stores — every database, object store, file share, and cache. Include data volumes, growth rates, and backup status.
• Dependencies — service-to-service dependencies, external API dependencies, shared infrastructure dependencies. This is where complexity hides.
• Shadow IT — services running outside the sanctioned architecture. Cloud accounts that IT doesn't manage. SaaS tools with enterprise data. They're there. Find them.

2. Security Posture

Evaluate the actual security state, not the intended one:

• Identity and access — who has access to what? Are permissions least-privilege or accumulated over years of "just give them admin"? How many service accounts exist? Are they rotated?
• Network security — security groups, NACLs, WAF rules. Are they following zero-trust principles or is everything in a flat network?
• Encryption — data at rest, data in transit, key management. Is it consistent across all services or patchy?
• Vulnerability management — patching cadence, image scanning, dependency updates. How old are the oldest unpatched systems?
• Incident readiness — logging, monitoring, alerting, runbooks. If something goes wrong at 3 AM, what happens?

3. Cost Analysis

Understand where money goes and where it's wasted:

• Current spend breakdown — by service, by team, by environment (dev/staging/prod). Most organisations can't do this accurately.
• Waste identification — unused resources, oversized instances, unattached storage, idle load balancers. Typical waste: 25-35% of cloud spend.
• Reserved capacity analysis — are you using reserved instances/savings plans optimally? Undercommitting wastes money. Overcommitting creates lock-in.
• Cost trajectory — at current growth rates, what will the bill be in 12 months? 24 months? Is it sustainable?
• Optimisation opportunities — right-sizing, scheduling (turn off dev environments at night), spot/preemptible usage, architecture changes that reduce cost.

4. Compliance Mapping

Evaluate regulatory compliance across the infrastructure:

• Data classification — where is sensitive data stored? Is it classified? Are storage locations compliant with data residency requirements?
• Regulatory framework mapping — which regulations apply (GDPR, DORA, NIS2, AI Act, industry-specific)? Which infrastructure components are in scope?
• Control coverage — for each applicable regulation, which required controls are implemented? Which are missing? Which are partially implemented?
• Audit readiness — can you demonstrate compliance to an auditor today? What evidence is available? What gaps exist?

5. Operational Maturity

Assess how well the infrastructure is operated:

• Automation level — what percentage of infrastructure is managed as code? What's still manual? What's "we click in the console"?
• Deployment practices — CI/CD maturity, deployment frequency, rollback capability, testing coverage
• Monitoring and alerting — coverage, alert quality (signal vs. noise), on-call processes, incident response times
• Documentation — is the infrastructure documented? Is the documentation current? Can a new team member understand the architecture from documentation alone?
• Disaster recovery — backup coverage, RTO/RPO definitions, recovery testing frequency. When did you last test a full recovery?

6. AI Readiness (If Applicable)

If AI deployment is planned, assess infrastructure readiness:

• GPU availability — is GPU compute available in your cloud environment? In the right regions?
• Data pipeline maturity — can you move data from source to model training/inference efficiently and securely?
• MLOps readiness — model registry, experiment tracking, deployment pipelines, monitoring for ML-specific metrics
• Kubernetes maturity — if container orchestration is planned for AI workloads, what's the current Kubernetes state?

The Assessment Process

What You Get

A well-executed assessment delivers:

• Current state documentation — accurate architecture diagrams, inventory, and dependency maps
• Risk register — identified risks ranked by likelihood and impact, with mitigation recommendations
• Cost optimisation plan — specific actions with estimated savings (typically 20-40% of current spend)
• Compliance gap analysis — mapping of regulatory requirements to current controls, with remediation priorities
• Modernisation roadmap — phased plan for improvements, with dependencies and resource requirements
• Quick wins — things you can fix this week that deliver immediate value (security misconfigurations, cost waste, monitoring gaps)

Common Findings

After conducting dozens of assessments, these appear in nearly every one:

• 25-35% cost waste — oversized instances, unused resources, suboptimal pricing models
• Overly permissive IAM — admin access granted broadly, service accounts with excessive permissions, stale credentials
• Inconsistent encryption — some services encrypted, some not. Key management varies by team.
• Manual operational processes — deployments that require SSH access, configuration changes done in consoles, documentation in someone's head
• Monitoring gaps — infrastructure metrics exist but application and business metrics don't. Alerting is noisy with low signal.
• Backup assumptions — "we're backed up" but recovery has never been tested. RTO/RPO undefined for most services.

The assessment isn't the end — it's the beginning. It gives you the ground truth needed to make informed decisions about modernisation, migration, or optimisation. Without it, you're navigating in the dark. With it, you have a map.