AWS Consulting
AWS consulting at OMAV means workloads right-sized from measured utilisation rather than from a vendor calculator, with cost allocation owned by a named person. We do not resell AWS capacity, which is why the sizing advice usually points at less spend.
Right-sized from what is actually used
Cloud bills grow because nobody owns the difference between what was provisioned and what is used. Instances sized for a launch that never came, storage in the wrong class, environments running at weekends, and no tag structure that would let anyone attribute the spend to a team or a product.
The remedy is unglamorous: measure actual utilisation, right-size against it, put allocation tags in place, and give one named person a monthly variance review. That sequence recovers more money in most estates than any architectural change.
We do not resell AWS capacity. That matters because it removes the conflict of interest that makes most sizing advice point upward, and it is why our recommendations frequently reduce the bill.
What an AWS engagement covers
Six workstreams. The second one usually pays for the engagement.
Landing zone and accounts
Account structure, organisational units, guardrails and baseline security controls, so that new workloads land somewhere governed rather than wherever there was room.
Sizing from measured utilisation
CPU, memory, IOPS and network measured over a representative period, then instances and storage right-sized against the evidence rather than against a calculator estimate.
Cost governance
Allocation tags enforced, budgets and anomaly alerts configured, and a monthly variance review with a named owner — because unowned variance is how the bill drifts.
Reserved and savings commitments
Commitment purchases modelled against measured steady-state usage, with the arithmetic shown before anything is bought.
Backup, patching and monitoring baseline
A consistent baseline applied across accounts rather than configured per workload by whoever built it, including restore testing rather than backup configuration alone.
Well-Architected review
A structured review across reliability, security, cost, performance and operations, with findings evidenced from the account rather than asserted from a checklist.
How an AWS engagement runs
Measure
Utilisation collected across the estate over a representative period, so decisions rest on evidence rather than on what was provisioned.
Quantify the gap
The difference between provisioned and used quantified per workload, with the recoverable spend stated as a number.
Govern
Tags, budgets, anomaly alerts and a named owner for the monthly review put in place before the savings are realised, so they do not erode.
Right-size and commit
Instances and storage adjusted, then commitment purchases modelled against the corrected steady state rather than the old one.
Baseline and review
Backup, patching and monitoring standardised, restores tested, and a Well-Architected review completed with evidence.
Where cloud savings actually come from
Four levers, ordered by return relative to effort.
| Lever | Typical return | Effort | Risk |
|---|---|---|---|
| Turning off unused resources | High | Very low | Very low |
| Right-sizing from measured usage | High | Low | Low |
| Storage class and lifecycle | Moderate | Low | Low |
| Reserved and savings commitments | Moderate | Low | Locks in a baseline |
| Re-architecture | Variable | High | Moderate to high |
What we will be straight about
Not every saving is worth taking. Commitment purchases lock in a baseline, and buying them before right-sizing means committing to the wrong number for three years. We sequence deliberately for that reason, even though it delays the visible saving by a few weeks.
Re-architecture savings are also frequently overstated. Moving a workload to serverless or containers can reduce cost substantially, and it can also produce a system your team cannot operate. We quote those separately from the operational savings so each can be judged on its own merits.
- Measure utilisation before changing anything; provisioned size is not evidence.
- Put cost governance in place before realising savings, or they erode.
- Right-size before buying commitments, not after.
- We do not resell capacity, which is why the advice points at less spend.
Questions buyers ask about this
Can you reduce our AWS bill?
Usually, and we show the arithmetic before you commit. The reliable sources are unused resources, right-sizing from measured utilisation, storage class corrections and commitment purchases modelled against real steady state. Savings that require re-architecture are quoted separately, because they carry operational risk the others do not.
Do you resell AWS?
No. We have no margin on your consumption, which is precisely why the sizing advice tends to recommend less of it. Where a reseller relationship would genuinely benefit you commercially, we will say so, but we are not on the other side of that transaction.
What is a landing zone and do we need one?
It is the account structure, guardrails and baseline controls that new workloads land into. You need one once you have more than a handful of accounts or more than one team deploying, because without it every workload invents its own security and networking position and the estate becomes ungovernable.
How do you handle cost allocation?
Enforced allocation tags, budgets per owner, anomaly alerts, and a monthly variance review with one named person accountable. The technical part is straightforward. The part that determines whether it works is that someone owns the review, which is why we insist on naming them.
Do you provide ongoing managed support?
Yes, as a rolling engagement covering patching, monitoring, backup verification and the monthly cost review, under severity levels with a written support-versus-change boundary.
Marked up as FAQPage structured data, matching the visible text exactly.
Still not sure this is the right service?
Answer four questions and we will tell you which one fits — or that none of them do.
Tell us what you are trying to fix.
A short conversation about the objective, the constraints and the timing. If we are not the right fit, we will say so.