We audit and redesign AWS environments layer by layer: compute, data, network and foundation. Every change carries a number, cost per month or milliseconds of latency, and lands in your repository as infrastructure as code.
We always start with the assessment. Then we act where the return on investment is highest.
Rightsizing, Savings Plans, Graviton, Spot and tiered storage. A FinOps approach: every team sees what it spends and why.
Bottleneck diagnosis across compute, database and network. Autoscaling that responds to real demand and observability that explains every spike.
Multi-account landing zone, migration from a data centre or another cloud, and modernising monoliths towards containers or serverless when it pays off.
Infrastructure as code, deployment pipelines and shared on-call. Your team keeps the knowledge and the repository.
Typical savings per lever in accounts that have not been through a FinOps review. The assessment confirms which ones apply to you and in what order.
| Lever | Typical savings | Effort | Risk to production |
|---|---|---|---|
| Savings Plans and Reserved Instances on steady usage | 20 to 40 % of compute | Low | None |
| Rightsizing of EC2, RDS and EKS nodes | 15 to 30 % | Medium | Low, with load tests |
| Migration to Graviton | 10 to 20 % per instance | Medium | Low if the software is compatible |
| Spot for interruption-tolerant workloads | 50 to 70 % on those workloads | Medium | Medium, needs design |
| S3 Intelligent-Tiering and lifecycle rules | 30 to 60 % of storage | Low | None |
| Orphaned resources, snapshots, IPs and NAT | 3 to 8 % of the bill | Low | None |
| Data transfer and VPC endpoints | Variable, up to 15 % | Medium | Low |
Indicative ranges based on typical projects. The figures for your account are calculated in the assessment from your Cost and Usage Reports.
Closed phases with concrete deliverables. You can stop at any of them and keep the report.
Account inventory, cost per layer, Well-Architected review and prioritised performance bottlenecks.
Roadmap with estimated savings, effort and dependencies. Every action carries a number: cost per month or milliseconds.
Changes in Terraform or CDK, reviewed by your team and deployed environment by environment within agreed windows.
Monthly cost and performance review, shared on-call and training so your team can run it on its own.
Figures are illustrative examples from typical projects. They will be replaced with real cases with client authorisation.
Our own platform: three web applications, each with a frontend, an API and a MySQL database, running in production on AWS for less than a single managed database instance. Read the full case with the bill line by line.
Prices for eu-west-1 (Ireland) in September 2026, before taxes. All published cases.
Per closed project, at a fixed price after the assessment. We do not take a percentage of the savings, so we have no incentive to recommend commitments that do not suit you.
Not for the assessment. A read-only role with access to Cost Explorer and the CUR is enough. For execution, changes go through your pipeline with your team's review.
Yes, and that is what we aim for. We pair with your engineers and document every decision so operations stay in-house.
We work on AWS, Google Cloud, Azure and Oracle Cloud: Skyline (our infrastructure map), the security report and the cost estimate cover all four clouds (entire organisations on Google Cloud; full subscriptions or management groups on Azure; whole tenancies on Oracle Cloud). If you have a hybrid or multi-cloud environment, we assess it case by case.
The ten-day assessment tells you, with the plan to reduce it.
Tell us what your environment looks like and what worries you. Within 48 hours we will tell you whether we can help and what the first step would be.
What we have written about this, from projects we have run.
A cloud bill growing with revenue is fine. One growing faster is a business problem hiding inside an infrastructure report. Pick the unit, attribute the shared cost, and the conversation with the board changes.
Formatting and validation are free, static analysis is nearly free, policy on the plan is cheap, and real apply-and-destroy tests are expensive and slow. Spend accordingly, and know what each layer cannot catch.
The two failures are a module that wraps one resource and adds nothing, and a module that does everything and nobody dares change. A minimal interface, safe defaults and honest versioning are what separate them.