Cloud Cost Optimization and FinOps: A Practical Guide for 2026

Flexera's 2026 State of the Cloud report asked 753 organizations how much of their cloud infrastructure spend they thought was wasted. The average answer was 29%, two points higher than the year before and the first increase in five years. Flexera links the rise to AI workloads, which are expensive, bursty, and new enough that few teams have cost controls around them yet.

Self-reported numbers like that are soft. The useful part is where the waste comes from, because it is rarely one big mistake. It is hundreds of small line items that each look too minor to chase: a $3.65 monthly charge for a public IP, a NAT gateway billing per gigabyte, a snapshot policy nobody turned off. This guide goes through those line items with real prices, then covers how to size commitments and how to set up FinOps so the savings do not drift back within a year.

Prices below are AWS us-east-1 list prices as of September 2026 unless stated otherwise. Azure and Google Cloud have close equivalents for almost everything here.

Where the money actually leaks

Charges that run whether or not anything is using them

These are the easiest savings because removing them carries no performance risk.

Public IPv4 addresses. Since February 1, 2024, AWS charges $0.005 per hour for every public IPv4 address, attached or not. That is about $3.65 a month per address. An account with 200 addresses spread across EC2 instances, load balancers, and NAT gateways pays roughly $730 a month for them. The free Public IP Insights view in VPC IP Address Manager lists every one, and many workloads only need private addresses behind a load balancer.

Unattached EBS volumes and old snapshots. When an instance is terminated, its volumes survive unless "delete on termination" was set. Snapshots taken by backup policies keep accumulating after the source is gone. Both bill monthly with no owner watching.

Idle load balancers. An Application Load Balancer with no healthy targets still bills its hourly rate, plus the public IPs it holds.

Old engine versions. This one catches mature teams. Amazon EKS clusters on a Kubernetes version past standard support move to extended support at $0.60 per cluster-hour instead of $0.10, which is about $4,380 a year in extra fees per cluster. RDS databases on engine versions past end of standard support pick up an extended support charge per vCPU-hour on top of the instance price. Upgrading is engineering work, but the bill makes the business case.

Paying for more than the workload uses

Oversized instances. A service on an m5.4xlarge (16 vCPUs, 64 GB) that peaks at 3 vCPUs and 8 GB is paying for roughly four times the capacity it needs. Right-size from at least 14 days of CPU and memory data, not from CPU alone, and aim for a peak around 60 to 70% so spikes do not cause throttling. AWS Compute Optimizer does this analysis for free, although memory metrics require the CloudWatch agent.

gp2 volumes. gp3 costs $0.08 per GB-month against $0.10 for gp2, and it includes a baseline of 3,000 IOPS and 125 MB/s regardless of size. The migration is an online modification with no downtime. On 50,000 GB of gp2, that is about $1,000 a month saved for a few hours of work.

x86 where ARM would do. AWS markets Graviton instances as offering up to 40% better price performance than comparable x86 instances. Interpreted languages, containers, and most managed databases move over with little effort. Anything with compiled x86-only dependencies needs testing first.

Network charges nobody budgets for

Data transfer is where bills surprise people, because it scales with traffic rather than with the resources anyone provisioned.

A NAT gateway costs $0.045 per hour plus $0.045 per GB processed. Private subnets that pull container images, logs, or backups from S3 through a NAT gateway pay that per-GB fee on every byte. A VPC gateway endpoint for S3 or DynamoDB is free and takes that traffic off the NAT gateway. A workload moving 20 TB a month to S3 through NAT pays about $900 a month in processing fees that the endpoint removes.

Internet egress starts at $0.09 per GB after the first 100 GB a month. Serving static assets through CloudFront usually costs less per GB than serving them straight from EC2 or S3, and it cuts origin load as well.

Storage lifecycle mistakes

S3 Standard costs $0.023 per GB-month. Standard-IA is $0.0125, Glacier Instant Retrieval is $0.004, and Glacier Deep Archive is $0.00099. Lifecycle rules that move old data down those tiers save real money on large, cold datasets.

The catch is minimums. Standard-IA bills each object as at least 128 KB and for at least 30 days. Glacier Instant Retrieval has a 90-day minimum and Deep Archive 180 days. Every transition is also a billed request. A bucket full of millions of 10 KB log files can cost more after a lifecycle rule moves it to IA than before. For small objects or unpredictable access, S3 Intelligent-Tiering is usually the safer choice.

Commitments: how much to buy

On-demand pricing for a database that runs all year is the most expensive way to pay for it. Commitments fix that, but overbuying just moves the waste from one line of the bill to another.

AWS offers three main options:

The maximum discounts need a three-year, all-upfront term. One-year, no-upfront terms are much smaller, so check the rate for your own mix before building a business case.

The break-even rule

A commitment is a promise to pay for a fixed amount of usage whether you use it or not. If the discount is d, the commitment beats on-demand only when you use more than 1 − d of it. At a 30% discount you must use at least 70% of what you committed to. At 50%, the bar drops to 50%.

A worked illustration, assuming a 30% discount (your actual rate depends on instance family, region, term, and payment option):

• Over the last 90 days, compute spend never fell below $30 an hour at on-demand rates, averaged $42, and peaked at $70.
• Committing to cover the $30 floor costs $21 an hour. That saves $9 an hour, or about $78,800 a year, with almost no risk of unused commitment.
• Committing to cover the $42 average saves more when usage is at or above average. But if a migration or a quiet quarter drops usage to $30 for three months, the extra $12 of commitment is only partly used during that period and some of the savings disappear.

That is why most FinOps teams start by covering the observed floor, then add smaller commitments in layers every quarter as usage data accumulates. Staggered purchases also mean commitments expire at different times, so you are never forced to renew everything at once.

Spot for anything that can be interrupted

Spot capacity costs up to 90% less than on-demand. AWS gives a two-minute warning before reclaiming it; Google Cloud and Azure give about 30 seconds. CI runners, batch processing, data pipelines with checkpoints, and stateless workers behind a queue handle that fine. Spread requests across several instance types and Availability Zones so one capacity crunch does not take out the whole fleet.

Running FinOps so the savings stick

A one-off cleanup is easy to undo. New projects launch, someone doubles a node group for a load test, and a year later the bill is back where it started. FinOps is the operating model meant to stop that.

The FinOps Foundation describes a repeating cycle of three phases. In Inform, everyone who spends money can see what they spend. In Optimize, teams act on it. In Operate, cost checks become part of normal engineering work. The framework is organized into domains such as understanding usage and cost, quantifying business value, and optimizing usage and cost, but in practice most programs start with the same four pieces.

1. Cost data everyone trusts. Enforce tags for owner, environment, cost center, and application through AWS Service Control Policies or tag policies, Azure Policy, or GCP organization policies, so untagged resources cannot be created. Tag coverage is the first metric worth reporting. If you run more than one cloud, look at FOCUS, the FinOps Foundation's open billing format. AWS, Microsoft, Google Cloud, and Oracle Cloud all publish FOCUS-formatted exports, and version 1.4 was ratified in June 2026 with new fields for comparing commitments across providers.

2. Named owners. Every account, project, or Kubernetes namespace needs a person responsible for its spend. Shared Kubernetes clusters are the hard case because one node runs pods for many teams. Tools such as OpenCost, a CNCF project, or Kubecost split node costs by the CPU and memory each namespace requests.

3. Unit metrics. Total spend going up is fine if the business is growing faster. Track cost per customer, per transaction, or per thousand API calls next to the total. When a team can show its cost per transaction fell while its bill rose, that is a success, and the review meeting should treat it as one.

4. A cadence. Weekly anomaly alerts, a monthly review with engineering leads, and a quarterly commitment decision. AWS Cost Anomaly Detection is free and catches the misconfigured autoscaler before the monthly invoice does.

Guardrails that do not break production

Automated cleanup is where FinOps programs cause outages. A script that deletes "idle" volumes after 14 days will eventually delete the disk behind a monthly batch job or a database kept for compliance. Some rules that prevent that:

• Run any deletion policy in report-only mode for a full month before letting it act.
• Snapshot volumes before deleting them, and expire the snapshot later.
• Exempt anything tagged as production or holding regulated data, and require a human approval for those.
• Prefer stopping over terminating for the first pass. A stopped instance that nobody asks about for 30 days is a safe delete.

Cloud Custodian (another CNCF project) handles these rules as code across AWS, Azure, and GCP. Cloud cost governance covers budgets, approval flows, and policy design in more depth.

Put cost in front of engineers before they deploy

Tools such as Infracost read Terraform changes in a pull request and comment with the monthly cost difference. An engineer who sees "+$2,340/month" on a PR usually asks whether they need that instance size. It is the cheapest control on this list because it acts before the resource exists.

Tooling: start native, add platforms when you outgrow them

The native consoles (AWS Cost Explorer, Azure Cost Management, Google Cloud Billing reports) are free and enough for a single-cloud company that is still getting tagging right. Third-party platforms earn their fee when you run several clouds, need Kubernetes allocation, or want commitment management done for you. The market has consolidated: IBM owns both Apptio Cloudability and Kubecost, and Flexera bought the Spot portfolio from NetApp in 2025. Check the ownership and roadmap of anything you are about to sign a multi-year contract for.

Cloud spend increasingly sits next to SaaS spend in the same finance review. SaaS spend management applies the same ownership ideas to subscriptions.

A first 90 days

1. Weeks 1 to 2. Pull the last three months of bills by service and account. Measure tag coverage. List unattached volumes, idle load balancers, public IPv4 count, gp2 volumes, and clusters or databases on extended support.
2. Weeks 3 to 4. Remove the idle items after owner confirmation, migrate gp2 to gp3, add S3 gateway endpoints, and schedule non-production environments to stop outside working hours.
3. Weeks 5 to 8. Right-size the 20 largest instances by cost using Compute Optimizer and memory data. Turn on anomaly detection.
4. Weeks 9 to 12. With 90 days of cleaner data, buy a first Compute Savings Plan sized to the usage floor. Set up the monthly review and publish one unit metric per product team.

Teams moving workloads into the cloud should read cloud migration cost savings before sizing anything, because migrated servers are usually over-provisioned from day one. If you run on more than one provider, the multi-cloud strategy guide covers when splitting workloads saves money and when egress fees cancel it out. For keeping billing data clean enough to allocate, see cloud data governance best practices.

This article is for informational purposes only and is not professional IT, financial, or architecture advice. Cloud prices change and vary by region; check your provider's current pricing pages before making purchase decisions.