Cloud Cost & FinOps

Cost is a design axis

Cost is a design axis, not an afterthought you hand to finance. FinOps is the practice of making engineering, finance, and product jointly own cloud spend, and it runs as a continuous loop of three pillars:

  Inform   -> tag/allocate: know who spends what, per team/service/feature
  Optimize -> rightsize, kill idle, buy commitments, use spot
  Operate  -> governance: budgets, alerts, anomaly detection, accountability

Inform first

You cannot optimize what you cannot see. Enforce a tagging/labeling policy (team, service, environment, cost-center) so the bill maps to owners; untagged resources are the black hole where waste hides. Build a showback/chargeback view so each team sees its own spend.

Optimize compute

• Rightsizing: most instances are provisioned for a peak that rarely comes. Size to P90/P95 utilization over a representative window, not to a static "just in case" ceiling and not to the max (which one spike inflates). Automate it; manual rightsizing rots.
• Spot/preemptible instances (60-90% cheaper) for fault-tolerant work: batch jobs, CI, stateless workers, ML training with checkpointing. Not for a stateful primary that cannot tolerate a 2-minute eviction.
• Commitments: savings plans or reserved instances for your steady-state baseline (the load that is always on), on-demand/spot for the spiky top.
• Autoscaling and scale-to-zero: scale with load, and scale non-prod and bursty services to zero when idle. A dev cluster running 24/7 for a 9-to-5 team is ~70% waste.

Kubernetes cost is opaque

The cloud bill shows you nodes (EC2 instances), but you run many apps per node, so the bill cannot tell you that the recommendations service costs $8k/mo while payments costs $2k/mo. You fix visibility with OpenCost or Kubecost, which allocate node cost down to namespace/pod/label using each workload's requests and actual usage. That only works if workloads are consistently labeled (team, service), which loops back to Inform. Then you find the real K8s waste: over-requested resources (a pod requesting 4 CPU and using 0.3 pins capacity nobody uses) and low bin-packing (nodes half-empty because requests are inflated). Rightsize requests to P90/P95 usage and let the cluster autoscaler consolidate.

Data and egress are the sneaky levers

Data-transfer/egress charges are easy to ignore and brutal at scale: inter-AZ traffic (keep chatty services zone-aligned), cross-region replication, and internet egress (a CDN both speeds delivery and cuts origin egress). Storage tiering: move cold objects from hot storage to infrequent-access/archive tiers (S3 Intelligent-Tiering/Glacier). Warehouse query cost: a single unpartitioned full-table scan in BigQuery/Snowflake can cost more than a server; partition, cluster, and cache. And the current top concern is AI/GPU spend: GPUs are expensive and often idle between jobs, so batch and bin-pack inference, use spot for training with checkpointing, and right-size the model to the task.

Interview nuance: never cut cost by cutting reliability blindly. Deleting a standby replica or a multi-AZ setup saves money until the outage costs 10x the savings. Frame every cut as "reduce waste (idle, over-provisioned, untiered) while preserving the reliability the SLO requires."

Recap: run FinOps as Inform (tag/allocate) -> Optimize (rightsize to P90/P95, spot for fault-tolerant work, commitments for baseline, scale-to-zero) -> Operate (budgets, anomaly detection); fix opaque Kubernetes cost with OpenCost/Kubecost plus consistent labels and rightsized requests; and do not ignore egress/inter-AZ transfer, storage tiering, warehouse scans, and GPU spend.