AWS built so the second year costs less than the first.
Anyone can get a workload running on AWS. The difficulty is the estate two years later: the account structure, the bill, the blast radius and whether a new team can ship safely on Tuesday without asking permission from three people.
The bill is the symptom. The account structure is the cause.
Most AWS estates we are asked to look at grew one workload at a time. Everything shares an account, network boundaries follow no rule, tagging was optional, and the environments differ in ways nobody has written down. The monthly bill is the part that gets noticed, but the expensive problem is that change has become slow and frightening.
One account, one blast radius
Production and experiments share a boundary. A permission broad enough to be convenient is broad enough to be dangerous, and everyone knows it.
Cost with no owner
Untagged resources, idle capacity, oversized instances chosen once under deadline, and storage classes nobody has revisited since the workload changed shape.
Environments that differ quietly
Staging is not production with less traffic; it is a different system. So the tests pass and the release still fails.
The parts of AWS that decide whether the next two years go well.
Landing zone & accounts
Organisation structure, account separation, guardrails as service control policies, identity through IAM Identity Center, and a baseline every new account inherits automatically.
Serverless & containers
Lambda, ECS and EKS chosen on merit rather than fashion, with the operational cost of each made explicit before the decision rather than after it.
Data platform
S3 as the substrate, Glue and Athena for the analytical layer, Aurora or DynamoDB where the access pattern earns it, and lifecycle policies that keep storage from compounding.
Bedrock & AI workloads
Model access, routing, cost attribution and guardrails as shared platform capability rather than per-team improvisation.
LLM platformCost engineering
Right-sizing, Savings Plans and Reserved Instances modelled against real usage, storage tiering, and per-team showback so the people who create cost can see it.
Resilience & operations
Recovery objectives agreed with the business and then tested, multi-AZ where it is warranted, backup and restore actually rehearsed, and alerting that wakes someone only when it should.
Assess, fix what is load-bearing, then hand it over.
Assess
Two weeks. Account structure, security posture, cost breakdown, resilience and delivery pipeline, against the Well-Architected pillars and against what your business actually needs.
Prioritise
A short list ordered by risk and by payback, with the things that are fine left alone. We are not interested in rebuilding what works.
Deliver
Terraform or CDK in your repositories, changes shipped in small reviewable pieces, with your engineers in the pull requests rather than watching from outside.
Hand over
Runbooks, diagrams that match reality, cost dashboards and a named owner. If you would rather we stayed to run it, that is a separate conversation, not the default.
Cloud work rarely arrives on its own.
Questions we get asked
Do you work with our existing AWS partner or reseller?▼
Yes, routinely. Billing and licensing arrangements are usually best left where they are; we work on the engineering. Where a reseller's recommendation and ours differ, we will say so plainly and show the reasoning.
Is this a lift-and-shift or a rebuild?▼
Whichever the workload deserves, decided per workload rather than as a programme-wide religion. Some things should move as they are, some should be modernised, and some should be switched off. The assessment says which is which and what each is worth.
Can you reduce our bill without changing the architecture?▼
Usually some of it — right-sizing, storage tiering, commitment plans and idle resources tend to be worth a meaningful percentage on their own. The larger savings generally need an architectural change, and we will be clear about which is which so you can decide.
Do you use Terraform or CDK?▼
Both. If you have an existing standard we adopt it, because a second convention is worse than an imperfect first one. On a greenfield estate with no preference we usually propose Terraform, and we will explain why for your case.
Will our engineers be able to maintain it?▼
That is the point. We work in your repositories, in review with your team, and the handover includes the runbooks and the reasoning. If a design can only be maintained by us, it is the wrong design.
One free hour. No pitch, no obligation.
Bring the problem you are stuck on — an integration that keeps breaking, a cloud bill nobody can explain, an AI project that is all demo and no product, or a platform you are about to invest in. You will leave with a straight answer and a written summary, whether or not you ever work with us.
- Architecture and integration review
- AI feasibility — what will actually work, and what will not
- AWS, Azure and Google Cloud cost and design
- Business process audit and ISO readiness
- Technical due diligence before you invest or acquire