Cost Optimization as a discipline

Tweet

15 Feb 2026

Are you seeing AWS costs spike again and again, even after cleanup efforts? Read this.

A common scenario

A team deleted some unused resources (old RDS manual snapshots or some RDS restored for a specific recovery task).

The AWS bill drops.

Three months later, same cost line item quietly grows again.

The symptom

Many teams treat Cost Optimization as a spreadsheet problem. Many tools act like spreadsheets with steroids, but they still treat cost as a number problem.

Cost Optimization is not a spreadsheet problem. It is a discipline problem.

How the symptom manifests

This is a very common flow present in a lot of teams:

• An AWS bill causes panic.
• Meetings have place about the subject.
• Run cost explorer.
• Delete a few resources, adjust the infrastructure.
• Celebrate the win while observe the drop.
• Months latter, panic returns.

Sounds familiar? Keep reading.

Cost Optimization as discipline

Treating Cost Optimization as a discipline means:

• Define an owner, a person. You can have a team behind Cost Optimization, but at the end, a person must own the team and the all initiative.
• Tag everything. The tagging strategy is subject for a separated post, but know the tags will allow to associate projects, workloads and other owners with costs.
• Capacity review cadence, by having regular follow up meetings (e.g., weekly, monthly, or per sprint), where teams analyze optimizations made, new optimizations for existing identified problems and new findings.
• Explicit performance vs cost tradeoff. There will be optimizable costs that won’t be optimized because of some valid reasons. You may have an oversized RDS because of the risk of new users interacting with the system with no previous notice. Multi AZ RDS can be another example, because if you don’t have it and needing more than a couple of minutes to restore a database could cost you more than the cost of having the multi AZ (reputation, fines, etc).
• Commitment strategy aligned with volatility. This is about aligning your discount commitments (Saving Plans or Reserved instances) with workiload predictability. Stable workloads justify commitments, while volatile ones don’t. That is an strategic decision, not an afterthought.
• Architectural simplicity. Some workloads won’t need a full specialized EKS (Kubernetes clusters). Others will. Some customers won’t need a dedicated RDS. Others will. Identify the proper architecture for each case. Also you’ll need to compare this simplification effort agains the costs of mantaining it. Some short teams will prefer to pay a little more on infrastructure costs if they are easier to mantain and that’s fine. The important thing is to make it explicit.

Tools won’t fix this

There are a lot of amazing tools for cost management. The problem is that we expect those tools to help us with the discipline but they don’t do that:

• Cost explorer doesn’t create discipline.
• Budgets doesn’t create ownership.
• Third-party dashboards don’t fix culture.

Tools are tools. The discipline is in our roof. Is a structural problem.

Last words

Cost Optimization is not a monthly cleanup task. It needs to be thought of an operating model. Do you have an owner for your costs management? Does that owner slots in its agenda for this responsability? Start with that.

Thanks for reading.

Tweet