Notes from the team building C3X. Cost estimation for Terraform, the economics of cloud infrastructure, and how to ship FinOps tooling without a SaaS gate.
A tagging policy nobody enforces is a spreadsheet, not a control. Policy as code rejects untagged resources before they deploy, so allocation stays near 100 percent instead of drifting. Here is how to build it.
Untagged resources are the reason your cost allocation never reaches 100 percent. Finding them systematically, by account and service, turns an unattributable slice of the bill into owned, actionable spend. Here is the method.
Chargeback moves real cloud cost onto each team's budget, which changes behavior far more than a report ever will. But it only works if the data is trusted. Here is how to implement it without a revolt.
In a multi-tenant SaaS, the blended cloud bill hides that some tenants cost 50 times more than others to serve. Measuring cost per tenant exposes unprofitable accounts and bad pricing. Here is how to build the metric.
Dividing your infrastructure cost by request volume gives a single number that exposes inefficient endpoints, bad caching, and creeping bloat. Here is how to compute cost per request and use it to drive optimization.
A cloud budget is only useful if you compare it to actuals continuously and react to variance. Monthly budget-versus-actual tracking turns a static number into a control loop. Here is how to run it.
When the cloud bill jumps, the question is always the same: what changed? A disciplined root-cause method, slice by dimension, isolate the delta, tie it to a change, turns a scary spike into a fixable line. Here is the playbook.
A rightsizing sprint saves money once; a rightsizing program saves it continuously. The difference is process: recommendations, ownership, safe rollout, and measurement. Here is how to stand up a program that sticks.
Unattached disks, unassociated IPs, empty load balancers, and stale snapshots bill continuously while delivering nothing. A systematic cleanup finds and removes them safely. Here is the guide, resource by resource.
Networking, observability, support fees, and volume discounts belong to everyone and no one. How you split them decides whether showback is fair or a fight. Here are the common methods and when each fits.
Cost stays out of control when it is finance's problem, not engineering's. Real accountability puts cost data where engineers work and ties it to the decisions they own. Here is how to build it without slowing teams down.
The most expensive cost decisions are made in architecture, not operations, and they are hard to undo later. Adding a cost lens to design reviews catches the costly pattern before a line of code is written. Here is how.
Forecasting cloud spend ranges from a simple run-rate extrapolation to a driver-based model tied to business metrics. Each trades effort for accuracy. Here is how the methods compare and when to use each.
How you structure AWS accounts and organizational units decides how clearly you can see and control cost. A good multi-account layout gives allocation for free; a flat single account fights you forever. Here is how to design it.
The AWS Cost and Usage Report is the most detailed billing data AWS produces, but it is raw and huge. Turning it into queryable, allocated cost data is a pipeline worth building. Here is the architecture.
GCP's billing export streams detailed cost data straight into BigQuery, making SQL your cost analysis tool. It is powerful and easy to start, but the queries themselves can get expensive. Here is how to use it well.
A shared Kubernetes cluster arrives as one bill for many teams, and the node cost hides who used what. Showback by team, driven by resource requests and namespaces, makes the shared cost fair and visible. Here is how.
A managed Kafka service removes the operational burden but charges a premium; self-hosting on your own instances is cheaper per unit but demands real operational effort. Which wins depends on scale and how much of a platform team you have. Here is the comparison with numbers.
Running Elasticsearch or OpenSearch yourself on plain instances is cheaper per unit than a managed search service, but the service handles the hard parts. Which is cheaper depends on cluster size and your operational appetite. Here is the breakdown with numbers.
Running Postgres or MySQL yourself on EC2 is cheaper per hour than RDS, but RDS handles backups, failover, and patching. The premium is real, and so is the operational burden it removes. Here is when self-hosting a database pays off, with numbers.
Running Redis yourself on an EC2 instance is roughly half the price of ElastiCache, but ElastiCache handles failover, patching, and backups. For a cache, the trade-off is different than for a database. Here is when self-hosting Redis makes sense, with numbers.
Managed Airflow (MWAA or Cloud Composer) removes the operational burden of running schedulers and workers, but charges a flat environment fee on top of compute. Self-hosting on your own cluster is cheaper per unit but adds real ops. Here is when each wins, with numbers.
On-demand, reserved instances, savings plans, and spot are four ways to pay for the same EC2 capacity, with discounts from zero to around 90 percent and very different commitments. Which mix is cheapest depends on how predictable and interruptible your workload is. Here is the side-by-side.
Colocation means you own the servers and rent space, power, and cooling in a data center; cloud means you rent capacity by the hour with no hardware. The cost curves cross at a predictable point tied to utilization and scale. Here is when each wins, with numbers.