What a Cloud Architecture Assessment Should Include

If you're evaluating whether to commission a cloud architecture assessment, or checking whether the one you already paid for was any good, it helps to know what a thorough review actually covers. A lot of "assessments" on the market are a single call and a slide deck. Here's what should be in a real one.

1. Current-state architecture review

Before anyone can recommend changes, they need an accurate picture of what exists today: compute, networking, identity and access, data stores, and how they connect. This should be documented, not just discussed verbally — a diagram and an inventory you can hand to a new hire or an auditor. If the assessment skips this step, everything downstream is guesswork.

2. Cost posture, not just a cost report

Most cloud bills have waste in them: idle resources, oversized instances, storage in the wrong tier, data transfer patterns nobody designed on purpose. A good assessment doesn't just show you the bill — it explains why the spend looks the way it does and which changes actually move the number, versus which ones save a rounding error while adding operational risk.

3. Reliability and failure-mode analysis

What happens when a region has a bad day? When a dependency times out? When someone fat-fingers a config change? An assessment should identify single points of failure and describe the blast radius of the failures that are actually likely for your workload — not a generic checklist copied from a vendor whitepaper.

4. Security and access review

This doesn't need to be a full penetration test, but it should cover the basics that actually get exploited in practice: overly broad IAM permissions, public resources that shouldn't be public, unencrypted data in transit or at rest where it matters, and secrets management. The output should be a prioritized list, not a wall of severity-tagged findings with no guidance on what to fix first.

5. A risk register, ranked

Findings without prioritization aren't actionable. A useful risk register ranks issues by likelihood and impact, not just by how technically interesting they are. This is what lets a non-technical stakeholder look at the list and understand what needs budget and attention this quarter versus next year.

6. A roadmap with sequencing

The deliverable should end with a plan, not just a list of problems. Which fixes are prerequisites for others? What can run in parallel? What requires downtime or a maintenance window? A roadmap that ignores dependencies between fixes will get reordered by reality anyway — better to sequence it correctly up front.

7. Rough effort and cost estimates

You don't need a fully costed project plan at the assessment stage, but you do need enough information to prioritize: is this a two-day fix or a two-month migration? Assessments that stop at "you should fix this" without any sense of effort leave you unable to plan.

8. An executive summary a non-engineer can act on

If the only audience for the report is the engineering team that already knows most of the findings, the assessment hasn't done its job. A short summary that a CTO, a board member, or a procurement reviewer can read in five minutes and understand the priorities is part of the deliverable, not an afterthought.

What this looks like in practice

Our Cloud Foundations engagement is built around this checklist: a discovery workshop, an architecture and posture review, a written findings report with a prioritized roadmap, and a follow-up call to walk through it. If you want to see the exact report structure, it's on the Services page.

If you're comparing assessments, ask the provider directly which of the eight items above are actually in scope. It's a fast way to tell a real review from a sales pitch with extra steps.