Cloud Cost Engineering and Open Source FinOps
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.
Cutting the data transfer bill: a playbook for the invisible line
Data transfer is billed per GB with no resource to point at, which is why it is the hardest line to attribute and the easiest to ignore. Here is how to find the flows, rank them, and cut them, with the per GB rates that matter.
Reducing logging and observability spend without going blind
Observability spend grows with traffic, with services, and with every new dashboard, and it is often the second largest line after compute. Here is how to cut it 40 to 70 percent while keeping the signal you actually use.
Consolidating underused Kubernetes clusters to cut fixed cost
Every cluster carries a fixed overhead before a single pod runs: control plane, system nodes, load balancers, and monitoring agents. Running eight clusters at 15 percent utilisation is expensive in a specific, measurable way.
Deleting unused load balancers and IP addresses: a small line that adds up
A load balancer with no targets and a public IP with no association each cost a few dollars to tens of dollars a month. Individually trivial, collectively thousands. Here is how to find them, verify they are dead, and remove them safely.
Tuning autoscaling for cost: the settings that waste the most money
Autoscaling is sold as a cost control and often operates as a cost floor. Minimum counts set for comfort, thresholds that never trigger, and cooldowns that hold capacity long after demand fell all quietly set a bill you never chose.
Reducing marketplace and licensing spend on your cloud bill
Third party software bought through a cloud marketplace lands on the same invoice as compute but obeys different rules. It is rarely audited, often over-licensed, and frequently the largest line nobody in engineering owns.
Cloud cost cleanup before a funding round or audit
Due diligence looks at gross margin, unit economics, and whether infrastructure spend scales with revenue. A cost cleanup before the process starts changes the numbers investors see. Here is what to fix and in what order.
The bill spike emergency runbook: stopping the bleed in one hour
When spend triples overnight, the priority is stopping the burn, not understanding it. Here is an hour by hour runbook: contain first, diagnose second, then decide what to reverse and what to keep.
Graviton4 vs Graviton3 cost and performance: is the upgrade worth it
Graviton4 instances (R8g, M8g, C8g) deliver meaningfully more performance per core than Graviton3, at a similar or slightly higher hourly price. Whether the newer generation is cheaper for your workload depends on how well it converts extra performance into fewer or smaller instances. Here is the comparison.
EC2 compute-optimized vs general-purpose cost: C-family or M-family
The C-family (compute-optimized) gives more CPU per dollar with less memory, while the M-family (general-purpose) balances CPU and memory at a higher price. Picking the wrong one wastes money on RAM you do not use or forces oversizing to get enough CPU. Here is how to choose on cost.
EC2 memory-optimized instances cost: when the R-family pays off
The R-family (memory-optimized) packs 8 GB of memory per vCPU, costing more per hour than general-purpose but far less than oversizing an M-instance to reach the memory. For in-memory databases, caches, and analytics, it is the cheapest way to buy RAM. Here is when it pays off.
EC2 Auto Scaling cost optimization: paying for load, not for peak
An Auto Scaling group can save money by matching capacity to demand, or waste it by scaling on the wrong metric, holding too much warm capacity, or never scaling down. Here is how to tune an ASG so you pay for the load you have, not the peak you fear.
Lambda vs EC2 cost breakeven: when serverless stops being cheaper
Lambda is cheap for spiky, low-utilization workloads and expensive for steady, high-utilization ones, where an EC2 instance running full-time wins. The breakeven depends on request volume, duration, and how busy the compute would be. Here is how to find the crossover.
Fargate Spot cost savings: cutting container bills up to 70 percent
Fargate Spot runs your ECS tasks on spare capacity for up to about 70 percent less than regular Fargate, at the cost of possible interruption. For fault-tolerant, stateless, and batch workloads it is one of the biggest container savings available. Here is how it works and when to use it.
Combining Spot and Savings Plans: the layered compute discount strategy
Spot and Savings Plans are not either-or: the cheapest fleets layer them, committing to a steady baseline with Savings Plans and filling the elastic and interruptible portion with Spot. Here is how to combine them without wasting a commitment on capacity Spot should cover.
Idle EC2 cost elimination: finding and stopping instances doing nothing
Idle EC2 instances, running at single-digit CPU with no real traffic, are one of the most common and avoidable cloud costs. Finding and stopping them, or scheduling them off, often cuts a compute bill by 20 to 40 percent. Here is how to hunt idle compute down.
EC2 hibernate vs stop cost: which saves more on idle instances
Stopping an EC2 instance halts compute charges but keeps EBS billing; hibernating preserves memory to disk for fast resume but stores that memory on EBS, adding cost. For part-time workloads, knowing which to use and what still bills is worth real money. Here is the comparison.
Scheduled scaling for dev environments: turning off nights and weekends
Development, test, and staging environments rarely need to run outside business hours, yet many run 24/7. Scheduling them off nights and weekends cuts their cost by roughly 65 to 75 percent with no loss of function. Here is how to do it and what it saves.
Lambda cost per million invocations: a worked pricing breakdown
Lambda cost per million invocations depends on two levers, the flat per-request fee and the per-GB-second duration charge, and the duration part usually dominates. Working through real numbers shows exactly where the cost goes and which lever to pull. Here is the breakdown.
Savings Plans coverage and utilization: sizing commitments without waste
Two numbers decide whether Savings Plans save money or waste it: coverage (how much of your usage the commitment covers) and utilization (how much of the commitment you actually use). Over-commit and utilization drops; under-commit and coverage is low. Here is how to balance them.
EC2 purchase options compared: on-demand, Spot, Savings Plans, Reserved
EC2 offers four ways to pay, on-demand, Spot, Savings Plans, and Reserved Instances, each with a different discount, commitment, and risk profile. Using the right one for each part of a workload is worth 50 to 80 percent off the naive on-demand bill. Here is the full comparison.
App Runner vs Fargate cost: managed simplicity or container control
App Runner and Fargate both run containers without managing servers, but they price and scale differently. App Runner bundles more of the operational layer at a per-resource rate, while Fargate gives finer control and can scale to zero more cheaply. Here is the cost comparison.
T-family unlimited mode cost: when burstable CPU credits bill extra
Burstable T-family instances earn CPU credits when idle and spend them when busy, but under sustained load they exhaust credits and either throttle or, in unlimited mode, charge extra. Understanding when unlimited mode saves money and when it silently inflates the bill is worth knowing. Here is how it works.
ECS capacity providers cost: mixing Spot, on-demand, and scaling
ECS capacity providers decide where your tasks run and in what mix, and that decision drives the cost of an ECS cluster. Splitting between on-demand and Spot, tuning target capacity, and choosing Fargate versus EC2 providers can cut container spend substantially. Here is how they work on cost.