A cloud audit is worth what you do with it the following Monday. The most thorough report is useless if it ranks an exposed access key alongside a missing tag on a volume. A well-run audit, on the other hand, fits in a few pages: what puts your business at risk, what costs you money without serving anything, what will not survive an outage, and in which order to deal with all of it.
This post sets out what you should get out of a cloud audit run against the Well-Architected framework, and the questions to ask to find out whether the one on offer will keep that promise.
What a Well-Architected audit looks at
The Well-Architected framework is the reading grid cloud providers publish for judging an architecture. We apply it across five axes: security, reliability, performance, cost and operational excellence. The value of the framework is not its checklist, which anyone can read. It is that it forces each axis to be judged against the other four: a platform that is secure but oversized, or cheap but without a tested recovery plan, is still a risk.
In practice the review covers your real environment, not a self-assessment questionnaire:
- accounts, identities and permissions, including the service accounts that pile up project after project;
- network exposure, especially the kind left over from a test phase and never closed;
- backups, and above all the evidence that they have already been restored;
- resource sizing, compared with measured consumption;
- billing, line by line, environment by environment;
- how the platform is built and changed: what is described in code, what was created by hand, what could not be rebuilt.
How it runs
A serious audit does not tie up your teams for weeks. Ours runs in three stages.
Collection. A tooled inventory of the environment: resources, configurations, access, backups, consumption. Read-only access covers most of it; that access is logged and revoked at the end of the engagement. On your side, one scoping meeting is enough.
Analysis. The inventory is checked against the provider's best practices, then against your actual constraints. This is the step that separates an audit from a generated report: a gap is only a problem if it has a consequence in your context, and an honest auditor says so when it does not.
Debrief. A written report, presented live to your teams, with time to discuss its conclusions. The whole thing takes from a few days to a few weeks depending on platform size.
What you receive
The deliverable comes down to four things. If one is missing, ask for it.
The list of gaps, ranked. Every finding carries a severity that reflects your business, not only the rule that was broken.
An effort estimate. For each gap, what fixing it takes: an hour of configuration, a week of work, a project to schedule. That is what separates immediate fixes from structural work.
The cost of doing nothing. An end-of-support version or a backup that has never been restored costs nothing until something happens. The report should say what leaving the point untreated costs, in exposure or in money, so the priority can be defended in front of leadership.
A path. The actions in order, with what your teams can do, what needs reinforcement, and what can wait. The report is yours: you can carry it out with your teams, with us, or hand it to another provider.
What an audit does not do
A cloud audit is not a compliance audit: it does not certify that you meet a standard, it measures how effective and robust your platform is. Nor is it a security audit alone, which covers only one of the five axes. And it is not a penetration test: it reads configurations, it does not attack your production.
It does not replace the decision either. The audit gives you data; the trade-off between a security project and a saving on the bill remains your leadership's call.
Signs an audit will not be worth your time
- The conclusion is known before the review. An audit that always recommends a full rebuild, or always recommends the provider's own service, teaches you nothing.
- The recommendations are generic. A list copied from the provider's documentation gives itself away by naming none of your resources.
- No figures. A finding with no effort estimate and no cost of inaction does not support a decision.
- Write access requested up front. Reading a platform only takes read access.
What comes next
Three follow-ups are possible, and all of them are legitimate. Your teams carry out the plan, and the audit has served as a roadmap. The plan reveals a migration or a rebuild to run, and the cloud migration then builds on the inventory already done. Or the platform needs day-to-day operation, and the audit becomes the starting baseline of a managed service.
Our audit is free and comes with no commitment. It is tied to no operations contract, which is what lets you read its conclusions without suspicion.