Infrastructure cost is an operational signal. A cluster may be cheap per idle hour and expensive under autoscaling, retained snapshots, log ingestion, or cross-region transfer. Cost allocation labels and budget alerts make a service's recurring spend visible, but they do not tell a team which resource can safely be removed. Capacity must still meet release surge, peak demand, and recovery objectives.
Make this comfortable
Cloud cost and capacity: assign an owner to each recurring resource
Operational decision
For a media-processing service, label compute, storage, and telemetry resources with the service and owning team. Review daily cost beside queue age, throughput, request latency, and failed work. A sudden spend increase may be an expected load spike, a retry loop, or an orphaned test environment. The YAML sample is an internal budget record, not a cloud-provider API. Set a response owner and an escalation threshold. Before shrinking a worker group, load-test the new capacity and confirm that old messages can clear within the agreed window. Before reducing log retention, verify incident and audit requirements. Model standby capacity as an intentional recovery expense; deleting it to meet a monthly target can invalidate the stated RTO.
service: media-processing
owner: media-platform
monthlyBudgetUnits: 7400
reviewWhenDailyUnitsAbove: 310
track:
- worker-compute
- queue-storage
- trace-ingest
- standby-capacity
keepRecoveryCapacity: trueCost and verification
Frequent cost reports and fine-grained labels create monitoring work, but make waste and ownership visible. Autoscaling saves idle compute while increasing bills at peak and sometimes multiplying downstream connections. Deleting an unused test namespace can be low risk; cutting a production replica without measurement is not. The numbers in the sample are invented budget units, not currency or advice. Report savings alongside reliability signals so the team can see whether a cost cut shifted expense into incidents or user delays.
Common Mistakes
- Do not cut recovery headroom without updating the recovery objective.
- Do not interpret every cost spike as waste.
- Do not leave recurring resources without a named owner.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- Capacity and load tests: identify the next bottleneck
- Horizontal autoscaling: choose a signal tied to demand
- Multi-region failover: define write ownership before moving traffic
Advanced follow-up
- Shared cluster cost: reconcile service allocation with the provider bill
- Compute commitments: separate billing coverage from machine availability
- Cost alerts: account for billing delay before a runaway resource spreads
Object storage follow-up
Platform operating-contract follow-up
devops
operations