TCP#101: Your AWS bill is lying to you
The real problem is two layers deeper than the invoice.
You can also read my newsletters from the Substack mobile app and be notified when a new issue is available.
Your AWS bill is up 30% quarter over quarter. The first call goes to FinOps.
They run Cost Explorer. Flag unused EC2 instances, orphaned snapshots, and over-provisioned RDS clusters. Set budgets. Send reports.
The bill keeps climbing.
Most engineering leaders misread the AWS cloud cost problem they are actually facing. They see a spending problem. They reach for a cost tool. The bill is not the problem. It is a symptom. What it points at sits two layers deeper: cloud resource ownership.
NOBODY OWNS THE SPIKE
You open Cost Explorer. The numbers do not add up.
EC2 costs are up across six accounts. S3 storage doubled. Data transfer charges appeared from services nobody can name. You ask which team owns the resources driving the spike.
Silence.
Tags are inconsistent. The account structure does not map to any org chart. Costs are real. Owners are not.
COST HYGIENE IS NOT COST MANAGEMENT
The reflex is to fix the spending.
Rightsize instances. Set budget alerts. Implement S3 lifecycle policies. Turn off what is unused. These actions are not wrong. They are aimed at the wrong layer.
FinOps produces a dashboard. Leadership gets a weekly cost report. Engineers get Slack alerts when a resource exceeds the threshold. Costs dip, then creep back up two months later. New resources appear untagged. New services are being spun up in accounts that were supposed to be off-limits.
The cycle repeats.
This is cost hygiene. It is not cloud cost management. The gap between those two things is ownership.
RESOURCES OUTLIVE THEIR OWNERS
Rising cloud costs are a forcing function. They expose what was always true about your infrastructure: nobody owns it with enough cloud cost accountability to keep it predictable.
In most engineering organizations, cloud resources are created by whoever needs them, when they need them, with whatever access they have. Tagging is optional. Account structure reflects history, not design.
Cloud resource ownership is assumed but never formalized. The developer who provisioned that cluster moved to a different team six months ago. The resource stayed. The ownership did not transfer.
When costs rise, you are not seeing a new problem. You are seeing the accumulated weight of all ownership gaps on your platform. Every resource has no accountable owner. Every account with no cost center mapping. Every service with no team responsible for its AWS footprint.
The tell is in the conversation after the cost alert fires. If your first question is “what is this resource,” your second question should not be “can we delete it.” It should be “why did we not already know.”
The answer to that second question is organizational. Not technical.
ONE QUESTION EXPOSES THE REAL PROBLEM
Before you touch a cost optimization tool or kick off a rightsizing exercise, ask one question:
For every resource in every account, can you name the owning team, who is accountable for its cost, and which product or business function it maps to?
If answering that requires querying three different systems, cross-referencing a spreadsheet, and making assumptions, you do not have a spending problem. You have an AWS cloud cost ownership problem.
Run a secondary diagnostic. Pull your tagging compliance rate. Not the tags that exist. The tags that are enforced. If any team deploys untagged resources without an automated block or remediation triggering, cloud resource ownership is optional in your platform. Optional ownership produces unpredictable costs.
FOUR MOVES TO MAKE OWNERSHIP MANDATORY
The fix is not a FinOps tool. It is an ownership model, enforced at the infrastructure layer.
Four moves.
One: Enforce three mandatory tags on every AWS resource. Owner team. Service or product. Environment. Not suggestions. Enforced at deploy time via an AWS tagging strategy built into your CI/CD pipeline. AWS Config rules or OPA policies block untagged resources from provisioning. Resources that drift post-creation trigger automated remediation. No exceptions.
Two: align your AWS account structure for cost control. Accounts are not just security boundaries. They are cloud cost accountability boundaries. When a team owns an account, they are responsible for the bill. Cost Explorer data becomes meaningful because it maps to a real team. Monthly cost reviews are no longer abstract reports. They become conversations with accountable owners.
Three: build a lightweight ownership registry. One YAML file per service, committed to your central platform repo. It contains the owning team, the primary AWS account, the on-call rotation, and the estimated monthly cost baseline. Update it as part of service onboarding. It becomes your source of truth the next time costs spike and nobody knows where to look.
Four: run a quarterly orphan audit. Every resource with no matching registry entry is a liability. Automated Lambda functions query the AWS API for untagged or unregistered resources. Results route to the platform team for triage. Orphans surface before they compound.
None of this requires new tooling. It requires a decision: cloud resource ownership is mandatory, not aspirational.
When you build that into your platform design, cost trends become readable. Spikes have named owners. Anomalies surface in context. Budget conversations happen between accountable parties, not between engineers and dashboards.
The teams that get cloud cost management right do not spend less. They know who owns what. That precision is the only foundation on which cloud cost accountability works.
If you are running a cost-optimization sprint right now and do not have a clear answer to who owns this, pause the sprint. First, fix the AWS cloud cost ownership model. Everything else builds on it.
P.S. This article is part of a deeper series on AWS cloud cost ownership. Paid readers get the full implementation kit.
Whenever you’re ready, there are 2 ways I can help you:
Free guides and helpful resources: https://thecloudplaybook.gumroad.com/
Get certified as an AWS AI Practitioner in 2026. Sign up today to elevate your cloud skills. (link)
That’s it for today!
Did you enjoy this newsletter issue?
Share with your friends, colleagues, and your favorite social media platform.
Until next week — Amrut
Get in touch
You can find me on LinkedIn or X.
If you would like to request a topic to read, please feel free to contact me directly via LinkedIn or X.