FinOps

AWS Cost Optimization and Reliability Trade-offs

Attribute spend, remove idle waste, and treat unused production capacity as a named reliability choice—not an automatic saving.

Todor ShopovPublished 2026-10-124 min readFinOps

Cost without context is a spreadsheet, not a decision

Cloud bills move because of idle resources, oversized compute, data transfer, forgotten environments, and reliability choices that look like waste in a monthly report. Rightsizing a production replica that exists to survive a zone loss is not optimization. It is a change to recovery.

This guide uses a hypothetical tagged AWS account. It does not claim savings percentages, client results, or current list prices. Treat unit prices as assumptions you replace with your invoice.

Attribution first

If you cannot answer “who owns this and which environment is it,” you cannot safely turn it off. Consistent tags—owner, service, environment—or an account-per-environment layout make Cost Explorer useful. Untagged shared NAT gateways and logging buckets become political arguments.

# Educational default tags. Values are examples, not a real organization.
provider "aws" {
  region = "eu-west-1"

  default_tags {
    tags = {
      owner       = "platform"
      service     = "example-api"
      environment = "staging"
    }
  }
}

Separate development waste from production headroom before anyone proposes a reservation.

Remove idle and forgotten first

Safer first cuts in many accounts:

Unattached EBS volumes and unused snapshots past the retention you actually need.
Idle load balancers and unused Elastic IPs.
Development clusters that stay at production size all weekend.
NAT gateways serving almost no traffic, or three NATs where one pair would meet the stated availability goal.

These still need owners. Deleting a “idle” volume that was last week’s backup is an incident.

Rightsizing needs a peak-load story

Average CPU of 15% can be correct if the service absorbs a daily spike, a deploy surge, or a zone loss. Measure the constraint you care about: request latency, queue depth, or failover, not only daily average CPU.

# Illustrative arithmetic—not an invoice.
# monthly ≈ hours × unit_price × count
# Replace unit_price with a number from your bill.
# Compare current_count versus a candidate that still meets peak + surge.

Document why leftover capacity exists. “We might need it” is not a reason. “We keep two AZ replicas because RTO does not allow a cold restore” is.

Autoscaling and commitments are different levers

Autoscaling helps variable demand after you set a minimum that still covers warmup, rolling updates, and the first minute of a spike. Scale-to-zero can meet a budget and miss the SLO on the first request.

Commitments (Reserved Instances, Savings Plans, Azure reservations) reduce unit price on a stable baseline. Buying a one-year term on an instance family you are about to leave creates a new constraint. Prefer commitments after the shape is understood, not as a substitute for deleting idle development.

Spot or Spot-like capacity is cheaper and interruptible. It needs a drain story. It is a poor default for a single-replica stateful store.

Architecture often beats instance size

NAT hours, cross-AZ bytes, public egress, and unused multi-AZ flags can dominate a small VM’s price. Private endpoints reduce internet egress for some AWS APIs and add hourly charges. Neither is universally cheaper—volume decides.

A single-AZ database is cheaper until the zone fails. Label multi-AZ, extra replicas, and warm caches as reliability spend so a later cost review does not “find savings” by deleting them.

Security and automation

Billing data is sensitive. Separate who can view invoices from who can destroy infrastructure. Cost-cleanup automation that can delete production data stores without a review gate is a reliability defect.

Orphaned resources are also orphaned attack surface. A forgotten load balancer with an old certificate is both spend and exposure.