Find Out What the Bill Is Actually Paying For Before You Start Cutting

We will not give you a percentage before looking, and anyone who does is quoting a brochure rather than your account. What we can say is where the savings usually sit: environments running out of hours, resources nobody has used in months, storage that never moved to a cheaper tier, and machines sized for traffic that never arrived. Some accounts are already tight and the honest finding is that there is little to take. The assessment tells you the number for your account, with the risk against each item.

Not if performance is measured on both sides of every change, which is the whole discipline. We record response times, throughput, error rates and resource use across a representative period, including your busiest day, before anything is altered. Changes to production are made in planned windows with a way back agreed in advance, and the metrics are watched afterwards. Where a change does affect performance, we reverse it and say so. The failures in this work come from resizing on a hunch.

With tagging, which nobody enjoys and everything else depends on. Until each resource carries a service, an environment and an owner, a cost review is guesswork, and the first question about any resource is what it is for. Tagging usually takes a week and immediately reveals the easy items: environments belonging to finished projects, disks attached to nothing and duplicated backups. After that the order is idle resources, schedules, storage tiers, right-sizing and finally commitments.

Probably, but not yet and not for everything. Committing before right-sizing locks in the oversized machines you were about to fix, which is the most common expensive mistake in this work. The sequence that works is to right-size first, watch the settled usage for a while, then commit on the baseline that genuinely runs all year and deliberately leave the variable portion on demand. Full coverage looks efficient on a spreadsheet and hurts the moment your architecture changes.

Usually because the servers were copied rather than redesigned. A physical machine sized for peak load, replicated as an instance of the same size running every hour of the year, costs more than the hardware did, because you were previously paying for capacity once and are now renting it continuously. The cloud pays back when capacity follows demand: scheduled environments, autoscaling, managed services sized to actual load and storage that ages into cheaper tiers. That is a design change, and it is where the real reduction lives.

Only after someone confirms what each one is, which is why we never do it from a script. The list goes to the people who own those services, with what it is attached to and when it was last touched. Anything unexplained stays. Where there is doubt, resources are stopped rather than deleted for a period, so recovery is quick if something turns out to matter. Retention rules are then set so the same accumulation does not start again the following year.

Yours, always. We are added with the access needed and nothing more, starting with read-only for the assessment and gaining change permissions only for the implementation. The savings land on your bill directly, you keep the relationship with the provider, and you keep any commitments we recommend. Arrangements where a vendor resells you cloud capacity through their own account make it very hard to leave and very hard to verify what you are paying for.

They are the line that surprises people most, because they do not appear in a resource list and nobody remembers agreeing to them. Traffic leaving the cloud, traffic between availability zones, gateway charges and backups copied to another region all accumulate quietly. The usual fixes are a content delivery network in front of public assets, keeping chatty components in the same zone, compressing what crosses boundaries, and checking whether cross-region replication is genuinely required or was switched on because it sounded prudent.

By making it somebody’s job once a month, with tooling behind them. Budgets per environment with alerts, anomaly detection so a runaway resource is caught in days rather than at month-end, tagging rules that reject untagged resources, and expiry tags on anything created for a temporary purpose. Beyond the tooling, the habit that matters is a short monthly look at what changed and why. Accounts that are reviewed stay reasonable. Accounts nobody looks at drift back within a year.

The assessment is a fixed piece of work, priced from the size and complexity of the account: how many services, how many environments, how much is tagged already and whether the architecture is documented. Implementation is quoted separately once the findings are known, because the effort depends on which items you choose to act on. We do not work on a share of savings, since it creates an incentive to cut deeper than is wise and to claim credit for reductions that would have happened anyway.

Yes, and the method is the same on all three: attribute the spend, measure real usage, remove what is idle, schedule what is not needed around the clock, tier the storage, right-size, then commit. What differs is the vocabulary and the specific tools, such as savings plans against committed use discounts, and how each provider charges for transfer and managed services. We also work with smaller providers, and with businesses running a mix, which usually needs the tagging discipline more than a single-provider account does.

Occasionally that is the right answer and we will say so. A steady workload with predictable load, no need for elasticity and a team able to look after hardware can be cheaper on rented dedicated servers. But the comparison has to be honest: hardware replacement, redundancy, backups, network, security patching and the people to do all of it, against a cloud bill that has actually been optimised first. Most businesses that raise this have an unoptimised bill rather than a cloud problem, and the review settles the question either way.

Enough to know what spare capacity you genuinely have, over a period that includes a bad day. Processor and memory use at peak rather than on average, since averages hide the hour that matters. Disk input and output, and queue depth. Network transfer in and out. Application response times and error rates. Cost per environment and, where it makes sense, cost per order or per tenant. Two weeks is usually a fair window, but if your business has a season, measure through it or wait for it, because a recommendation made in a quiet month will fail in your busy one.