Why AWS Is So Expensive (And Why It Is Almost Never About AWS)

If you are reading this, the AWS bill has probably come up in a conversation it did not used to come up in. A board meeting. A CFO question. A budget review that landed harder than expected.

The instinct is to look at AWS. The pricing, the markup, the lock-in.

Worth being direct about this. AWS pricing is publicly listed. It is broadly competitive with the other hyperscalers. The unit economics of running compute, storage, and network at scale are not the reason your bill is what it is.

The reason is something else, and it is usually uncomfortable to name.

Cloud cost is not a technology problem. It is a process problem.

Most engineering organisations have well-defined processes for performance, reliability, security, and code quality. Cost rarely has the same. There is no design review for spend. No allocation model that makes a team accountable for the resources it created. No estimation step before infrastructure is provisioned. No periodic re-evaluation of resources after they exist.

The bill is the sum of every decision made inside that gap.

Worth walking through where the gap most often shows up.

1. Costs are not visible at the resource level

Open the AWS console. Look at EC2. There is no cost column. Look at RDS. No cost column. Look at ECS. No cost column.

The Cost Explorer view, which is what most engineering organisations default to, aggregates at the service and account level. EC2 in production: £X. RDS in staging: £Y. That granularity is useful for a finance team. It is not actionable for an engineering team trying to understand which workload is driving the number.

Resource-level cost data does exist. It lives in the Cost and Usage Report (CUR) or, increasingly, in the FOCUS export. Both have to be explicitly enabled and shipped to S3. Most organisations either have not turned them on, or have turned them on without building the analysis layer that makes them useful.

The downstream effect of this is structural. Without resource-level visibility, every conversation about cost happens at the wrong altitude. Leadership asks why the bill went up. The platform team answers at the service level because that is the granularity they have. The conversation ends without anyone able to point at a specific resource, workload, or pattern.

You cannot manage what you cannot see, and the default AWS experience is built around not seeing it.

2. Costs are not estimated before resources exist

In most organisations, cloud resources are provisioned without a cost figure attached to the decision.

Infrastructure-as-code changes are reviewed for correctness, security, and operational risk. They are rarely reviewed for cost. The PR is approved. The resource is created. The first time anyone sees the price is in the following month’s bill, by which point the resource is in production and removing it is no longer a code review conversation. It is a project.

This is the inverse of how every other constrained resource is handled. Latency has budgets, defined up front, debated in design docs. Memory has budgets, enforced in tests. Security has thresholds, enforced in pipelines. Cost rarely has any of those, which means it accumulates in the only place it can: in production, retroactively, as a number that has to be explained.

The absence of an estimation step is one of the largest single drivers of unexplained cost growth, and it is the one most easily ignored because there is no event that makes it visible. Nothing alerts when the loop is missing. The bill simply grows.

3. Resources are sized once and not revisited

The default cycle for a cloud resource is: provisioned at the start of a project, sized for projected load, rarely re-evaluated.

There are good reasons for this. Engineering teams are measured on delivery, not on cost optimisation. Re-evaluating a resource that is “working fine” looks like a distraction from the roadmap. The cost of leaving it oversized is invisible. The cost of breaking production by undersizing it is not.

The result, observed across most environments, is that resources sized two or three years ago are still running at the same shape today, against workload patterns that have changed significantly. Utilisation drifts down. Instance families evolve. New compute classes appear. None of this surfaces as a problem until somebody goes looking.

The compounding factor: rightsizing is the step that has to happen before any commitment-based discount (Reserved Instances, Savings Plans). Locking in a three-year commitment on an oversized fleet is one of the few cloud cost decisions that is genuinely irreversible. It is also one of the most common, because the commitment is positioned as a saving and the rightsizing step that should precede it is skipped.

4. Non-production environments run at production cost

Almost every organisation has a version of this problem, and almost none have an established process for handling it.

Staging, UAT, development, QA. These environments are typically stood up by replicating the production infrastructure pattern. The instance shapes carry over. The availability configuration carries over. The redundancy carries over. The runtime hours carry over.

What does not carry over is the justification. Production runs that way because it has an SLA, because it serves real traffic, because it cannot afford downtime. Non-production environments do not. They serve a small number of engineers for a portion of the working day, with no external commitment, and yet they often run at 80-95% of production cost.

This is rarely the result of an explicit decision. It is the result of no decision. The environments were stood up at the moment the project needed them, and revisiting the operating model was rarely defined as anyone’s job. In most organisations, no team owns the operating model for non-production environments. So the model defaults to “the same as production,” and stays there.

In our engagements, this category is consistently where the largest single finding lands. Not because of a sub-optimal decision. Because the process for revisiting the environment was not in place.

5. Cost is not allocated, so nobody owns the number

This is the process gap that makes every other gap harder to close.

Without resource-level allocation, no team owns any portion of the bill. The conversation goes: the CFO asks the CTO why AWS is up. The CTO asks the VP Engineering. The VP Engineering asks the Head of Platform. The Head of Platform pulls Cost Explorer, sees that EC2 went up, and reports back that EC2 went up. Nobody can attribute the increase to a team, a product, or a feature, because the data to do so is not in place.

The principle of allocation is straightforward. Every resource should be attributable to an owner, an environment, and a business line. The execution is harder than it sounds. Allocation schemes drift. New accounts get created outside the standard. Resources created by automation skip the tagging path. Eighteen months of partial enforcement produces an allocation dataset that looks complete in the dashboard but is unreliable in practice.

Until allocation is genuinely in place, the cost conversation cannot move. Leadership is stuck asking generic questions because the data only supports generic answers. Once allocation is in place, the question shifts from “why is AWS expensive” to “which workload is up, by how much, owned by which team, and why.” That is the conversation engineering can act on. The first is not.

6. Architecture decisions outlive their justification

The deepest layer of cost sits in the architecture itself.

A choice of compute model, a choice of egress path, a choice of how services communicate, a choice of where to cache and where not to. These decisions are made early in a system’s life, often correctly for the context at the time, and they shape the cost curve for everything that follows.

Architectures are rarely re-evaluated against their cost shape. Engineering teams revisit architecture when something breaks, when scale demands it, or when a major migration forces it. Revisiting it because the cost shape no longer fits the workload is a category of work that almost no organisation has a process for.

The result is environments where the underlying cost shape is set by decisions made years ago, in conditions that no longer apply, and which nobody has been asked to look at since. Identifying which of those decisions is now the dominant driver of spend, in this specific environment, at this specific magnitude, is the highest-leverage and least-performed work in cloud cost management.

The honest summary

AWS is not expensive because of AWS.

AWS is expensive because most organisations have:

• No resource-level visibility into where the spend lands
• No estimation step before resources are provisioned
• No re-evaluation cycle for resources that already exist
• No operating model for non-production environments
• No allocation, so no team owns any number
• No review process for architectural decisions that drive the cost curve

Each of these is a process problem, not a technology problem. None of them are solved by a dashboard, because the absence of process is the gap the dashboard cannot fill on its own.

This is also why it is fixable. Process problems respond to process changes. The question is who owns the work, and most engineering organisations do not have anyone whose job description includes it.

How Koritsu Approaches This

Koritsu is an engineering-grade FinOps service. The platform exists, and it does real work, but the platform is not the offer. The offer is a team of engineers who go into your environment and run the processes that are missing.

The way most engagements start is a Savings Opportunity report on a success fee model.

No upfront cost. No subscription commitment. Read-only IAM access, tightly scoped. Our team and Kori, our AI FinOps analyst, go through the environment resource by resource, identify where the process gaps are showing up, and deliver a report against your actual billing data. Three months of platform access are included for free during the engagement.

If we find savings and they are realised, we take a percentage of what shows up in the bill in the first two months. If we do not, you pay nothing.

Find out if AWS is really the expensive part.

We look at your environment resource by resource, in the context of how your business actually runs. The workload patterns. The traffic profile. The teams behind each service. The optimisation opportunities we surface are ones you can act on without compromising what production needs to do.

Read-only access, tightly scoped. Three months of platform included. Success fee on what is realised in the bill.

Start with a Savings Opportunity report