Cloud costs grow quietly. At first nobody notices, then the invoice becomes an agenda item. I find the places where your budget leaks away, put a number on effort and risk for every measure, and implement them. If it does not save measurably, I do not do it.
The analysis is a self-contained one to two week engagement with a written report. Implementation afterwards is time and materials, or fixed price for clearly bounded packages.
Remote from Germany. Straight with me, no agency in between.
AWS makes it easy to create resources and hard to find them again. A proof of concept from two years ago is still running. A staging environment runs through the night and the weekend. A database cluster was sized for a peak that never came.
The uncomfortable part: cost is an architecture symptom. Adjusting instance sizes saves once. Understanding why an architecture is expensive saves permanently. Cross-AZ traffic, NAT gateway throughput, unbounded log ingestion. The most expensive line items are rarely where you would look for them.
Typical symptomsI work from the Cost & Usage Report, not the console summary page. Costs get broken down by service, environment, team and workload. By the end you know which euro goes where, which is the precondition for every decision after that.
Compute and databases sized for actual load rather than the load someone expected three years ago. Non-production environments run only when someone needs them. Unglamorous, and usually the fastest double-digit percentage available.
Savings Plans and Reserved Instances are both a lever and a trap. I calculate from your actual baseline consumption, recommend term and coverage deliberately conservatively, and set up monitoring that warns before they expire.
S3 lifecycle rules, Intelligent-Tiering, clearing out orphaned snapshots and EBS volumes. Plus the invisible line items: cross-AZ traffic, NAT gateways, log retention. This is where the money sits that never shows up in an instance list.
A tagging model enforced in Terraform, budgets with per-team alerts, and a monthly report that works without me. Cost optimization is not an exercise, it is a habit.
Every measure gets a number, before and after. What cannot be measured does not get recommended.
Monthly bill, account structure, biggest pain points. After that you know whether an analysis is worth it.
Evaluating CUR and usage data. The result: a list of measures with potential, effort and risk for each.
Everything that needs no architecture change goes first: rightsizing, scheduling, storage lifecycle, commitments.
Then the items that require touching the architecture, each with the maths done up front on whether it pays.
Every line maps to a team, an environment and a workload. Conversations about cost become conversations about priorities.
Quick wins first, architecture changes after. Every measure with a measured before and after instead of estimated potential.
Budget alerts and anomaly detection flag deviations as they happen, not on the fifth of the following month.
It depends on maturity. In setups that have never been reviewed systematically, double-digit percentages are usually available without touching the architecture: rightsizing, switching off non-production environments, storage lifecycle, sensible commitments. I give you a defensible number after the analysis, based on your data rather than an industry average.
No, that is the constraint. Every measure is checked against load profile and latency budget, changes to production compute go through staging and get measured after rollout. Where a saving would cost availability or latency it does not get recommended. It gets presented as a deliberate decision with numbers attached.
For a typical set of accounts, one to two weeks to the prioritize list of measures. The first quick wins can often be implemented during the analysis, because they need neither an architecture change nor a deployment.
Not to get started. The Cost & Usage Report plus Athena provides everything a defensible analysis needs. A tool becomes worthwhile when many teams are meant to carry their own cost responsibility permanently. That is a follow-on decision, not a starting point.
On request, as a small recurring engagement: monthly report, review of anomalies and commitments. The normal case, though, is that I set up governance and reporting so your team runs it without me.
The infrastructure behind AI systems that actually ship: MCP servers, controlled tool access, LLM integration with real permissions and cost control.
Learn moreReplacing manual workflows with real systems: wired into the software you already run, with permissions and an audit log instead of a chain of tools.
Learn moreFrom your own data centre or another cloud onto AWS, with a cost model before the move and a rollback path for every step.
Learn moreModernizing grown systems step by step: strangler fig instead of a rewrite, operations untouched, every step reversible.
Learn moreBackends for SaaS and platforms that hold under real load: Go and PHP 8, event-driven, with tenant isolation and recovery designed in.
Learn more