How to cut AWS costs without risking uptime

Every cloud cost conversation we walk into has the same shape. Finance brings a chart of AWS spend climbing every quarter. Engineering brings a list of reasons every line item is load-bearing. And everyone in the room remembers the time somebody deleted an "unused" resource and took a production service down with it. So nobody touches anything, the bill compounds, and the same meeting reconvenes next quarter around a bigger number.

We cut cloud bills for a living — most recently 38% off a payments platform's monthly AWS spend in 90 days, with zero customer-facing incidents — and every engagement teaches the same lesson: uptime risk does not come from spending less. It comes from cutting in the wrong order. This article is the order. What to measure before you change anything, the four levers that produce most of the savings, the guardrails that make those savings permanent, and the systems you should leave alone.

Measure first: you cannot cut what you cannot attribute

The first two weeks of cost work should contain no infrastructure changes at all. Export the Cost and Usage Report — the full resource-level CUR, not the console summaries — into Athena, where you can query every dollar down to the resource ID. Cost Explorer tells you what you spent. The CUR tells you what spent it, which is the question that matters.

Attribution fails without tags, so tagging comes first. Enforce a minimal standard — team, service, environment — through AWS Config rules rather than a wiki page, and measure coverage by dollars tagged, not resources tagged. You do not need every resource labeled; you need to know which team owns each expensive one. On a recent engagement with a payments platform, fewer than half of all resources carried usable tags when we arrived — the full story is in the cost optimization case study. Until that was fixed, finance could see the total but not a single cause.

Once the CUR is queryable, the first question to ask it is where the unattributed money goes:

-- Untagged spend by service, last 30 days, against the CUR in Athena
SELECT line_item_product_code AS service,
       SUM(line_item_unblended_cost) AS untagged_cost
FROM cur_report
WHERE resource_tags_user_team IS NULL
  AND line_item_usage_start_date >= date_add('day', -30, current_date)
GROUP BY 1
ORDER BY 2 DESC
LIMIT 10;

The deliverable from this phase is a ranked backlog: every savings opportunity with an estimated monthly value, an effort score, and a risk note. That document is what lets leadership approve cost work line by line instead of on faith. It is also what stops engineers from starting with the most interesting problem instead of the most valuable one — a failure mode we have watched eat entire quarters.

The four levers that move the bill

Four levers produce the large majority of the savings in almost any environment. The order below is deliberate: it is sequenced by reversibility, so the changes you make first are the ones you can undo fastest.

A cost cut you cannot roll back is not an optimization. It is a bet.

Right-size compute, then let Karpenter hold the line

Kubernetes resource requests are usually set during an incident and never revisited, which is how clusters across the industry end up idling at 20-something percent utilization while autoscalers buy more nodes. Run the Vertical Pod Autoscaler in recommendation mode for two weeks, set requests from observed usage plus sensible headroom, and only then replace static node groups with Karpenter so the cluster scales with demand instead of with fear. Right-sizing goes first because it is the most reversible change on this list — the old requests are one git revert away — and because every lever after it works better on a cluster that reflects reality.

Move interruptible work to spot, with checkpointing

Spot capacity is the same hardware at up to 90% off on-demand, and the price is a two-minute interruption notice. That trade is excellent for work that can stop and resume — batch jobs, report generation, CI runners, settlement processing — and unacceptable for everything else. The engineering that makes it safe is checkpointing: persist progress so an interruption costs minutes of recompute, not a rerun of the nightly batch. Keep spot away from the request path, from quorum-based databases, and from anything whose failure a customer would notice before you do.

Put storage on a lifecycle

Storage is where waste hides longest, because nothing pages when it grows. S3 buckets keep every object forever by default; give each bucket a lifecycle policy that moves cold data to infrequent access and Glacier tiers and expires what nobody will read again, starting with logs. Then sweep the mechanical debris: snapshots outliving their retention reason, unattached EBS volumes, elastic IPs billing for nothing. None of it is glamorous, and on mature accounts the storage line quietly rivals compute.

Make non-production environments ephemeral

Development and staging environments routinely run around the clock to serve engineers who work eight hours a day, five days a week. Make them ephemeral: built from Terraform on demand, destroyed every night, recreated in minutes the next morning. The savings are immediate, and the side effect is worth as much — an environment you can destroy nightly is an environment you can rebuild after a disaster, which means this lever quietly audits your infrastructure-as-code hygiene while it cuts the bill.

Guardrails: make cheap the default, not the exception

The most common outcome of cost work is that it works, everyone celebrates, and the bill is back within a year — because the optimization was a project, and the waste is a process. Savings persist only if the cheap path becomes the default path.

Three guardrails do most of that work. First, package the right-sized configurations as versioned Terraform modules — the paved road every new service starts from — so savings compound instead of eroding as the platform grows. Second, put cost in front of the engineers who create it: per-team dashboards with budget alerts wired into the channels they already read, cost displayed next to latency and error rate so it reads as an engineering signal rather than a finance complaint. Third, give leadership one unit metric — cost per 1,000 transactions, cost per active customer — because total spend rises with growth and tells you nothing, while unit cost is the honest number. Six months after the engagement linked above, spend was still within 4% of the post-optimization baseline, and the client's own platform team was operating every one of these loops without us.

The systems you should leave alone

Knowing where not to optimize is half of what keeps availability at four nines while the bill drops.

Compliance scope is the clearest case. In a PCI DSS environment, moving a workload can redraw the scope boundary, and a failed audit or a widened assessment costs more than a year of the savings that caused it. Inside scope, optimize conservatively: route every change through the existing change-control process, keep the boundary fixed, and accept that some inefficiency is the price of a clean audit. The same logic applies to HIPAA-covered infrastructure and anything your regulator has opinions about.

Leave alone, too, the system with no rollback story — the stateful service one engineer understands, running on instances nobody has dared reboot in years. That is not a cost problem; it is a continuity problem wearing a cost problem's clothes, and the knowledge gap has to close before any optimization is safe. And skip the long tail entirely: an opportunity worth $200 a month does not justify engineering time at any seniority level.

Occasionally the honest finding is that a system is expensive because it is badly built, and the fix is a rebuild rather than a tuning pass. That is a build-budget decision with its own economics — we wrote about how to price one in what custom software development costs in 2026.

The sequence to run this quarter

Compressed to a quarter, the playbook looks like this: two weeks of measurement producing the ranked backlog; the mechanical, reversible wins next — right-sizing and ephemeral environments — while trust builds; then spot migration and storage lifecycles; guardrails shipped alongside the changes they protect, not afterward; commitments signed last, once the new shape of the infrastructure is stable. Availability is watched at every step, and anything inside a compliance boundary moves through change control or does not move.

None of this is exotic. It is measurement, sequencing, and the discipline to make savings a property of the platform rather than a one-time heroic effort. If you would rather run it with a team that has done this under PCI-grade constraints, that is our cloud & DevOps engineering practice — the audit is fixed-price, and the ranked backlog it produces is yours whether or not we implement a line of it.