Menu
Cloud and DevOps
Not just the bill. The deploys nobody wants to run on a Friday, the instance nobody can turn off because nobody knows what it does, and the environment that only one person can rebuild.
What you get
A written review of cloud spend against usage, deployment pipeline health, and reliability risk. With findings ranked by what they cost you per month in money or in engineering time.
Findings ranked by what each costs per month, in money or engineering time. Structure shown with example values.
| Checked | Example finding | Rating |
|---|---|---|
| Idle or oversized instances | $1,840 / monthCritical | Critical |
| Unattached storage volumes | $310 / monthHigh | High |
| Environments with no owner | 2 foundHigh | High |
| Reserved instance coverage | 11% of eligible spendMedium | Medium |
| Median deploy duration | 38 minutesHigh | High |
| Deploy steps requiring a human | 6 of 14High | High |
| Estate reproducible from code | ~40%Critical | Critical |
plus the ranked remediation list with effort against saving
Example values shown. Your report contains findings from your own environment.
Idle and oversized instances, unattached storage, forgotten environments, and egress you are paying for without knowing why. Ranked by monthly cost so the list is actionable rather than exhaustive.
How long a deploy takes, how often it fails, and how much of it needs a human. Slow, manual deploys are a reliability problem, not just an inconvenience. They push teams toward batching risky changes together.
What breaks if one instance, one region, or one person is unavailable. Including the environments that exist only in someone’s memory and have never been rebuilt from code.
How much of your estate is actually reproducible from a repository versus configured by hand. This is usually the gap between a bad afternoon and a bad quarter.
Read-only access is enough for the whole review, and it is what we would ask for even if you offered more. On AWS that means a role with a billing and read-only policy attached; the equivalents exist on Azure and GCP. We also want read access to your infrastructure repository and to the CI configuration, because pipeline health is a large part of the picture and cannot be inferred from the console. We do not need production write access at any point, and a review that modifies the system it is measuring is not a review. If your security process requires an agreement before access is granted, that is normal and we will work to it. It usually adds a few days rather than a few weeks.
Often more useful, because the findings land with someone who can act on them immediately. An internal engineer usually knows where the problems are but lacks either the time to document them or the external weight to get them prioritised against feature work. A written review with costs attached tends to unblock that conversation. It is also genuinely common for the review to confirm your engineer has it right, in which case you have independent evidence for a budget request rather than a difference of opinion. What we would not do is hand you a list designed to make your existing team look bad. The deliverable is a work list, and it is theirs to own.
This page covers one specific engagement. The service page has the complete scope, process and technology list.