What "cost optimization" really means

People often read cost optimization as "spend less." That's part of it, but not all of it. A business that cuts its AWS bill in half and then watches its app slow down during a big sale hasn't saved anything. It has only moved the cost somewhere else, usually to lost customers.

A better way to think about it: pay only for what you actually use, and pay the lowest fair price for it. That gives you two levers to pull.

• Usage is how much you run. Fewer servers, smaller servers, less storage, fewer hours switched on.

• Rate is the price you pay for each unit. Discounts for committing ahead of time, cheaper server types, cheaper storage classes.

Nearly every idea in this guide pulls one of those two levers. Keep them in mind and the rest becomes much easier to follow.

How AWS charges you: the four pricing models

AWS sells the same computing power in different ways, a bit like an airline selling the same seat at different prices. Book at the last minute with free cancellation and you pay the most. Book months ahead with no refunds and it's much cheaper. Take a standby seat and it's cheapest of all, but you might get bumped.

1. On-Demand: pay as you go

On-Demand is the default. You start a server, AWS charges you for the time it runs, and you stop paying when you shut it down. There's no contract and nothing to pay upfront.

Main features

• Billing by the second for many Linux servers (with a 60-second minimum), and by the hour for some others.

• You can start, stop, or resize at any time.

• It has the highest hourly price of all the options.

Best for: new products where you have no idea what traffic will look like, short projects, test environments, and jobs that run for a few hours and then disappear.

2. Savings Plans: a discount for a spending promise

With a Savings Plan, you promise AWS you'll spend a fixed amount per hour, say $10 an hour, for one or three years. Everything you use up to that amount is charged at a lower rate. Anything above it is charged at normal On-Demand prices.

The key detail is that you commit to dollars per hour, not to one specific server. That makes Savings Plans much easier to live with than the older reservation model. There are four types:

• Compute Savings Plans give up to 66% off. They apply to EC2, Fargate, and Lambda, in any region, on any server family. This is the most flexible type.

• EC2 Instance Savings Plans give up to 72% off, but they're tied to one server family in one region. You can still change the size within that family.

• Database Savings Plans arrived in December 2025. They offer up to 35% off on a one-year term with no upfront payment, and cover Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Neptune, and a few other database services. The discount stays with you if you switch database engines or regions.

• SageMaker Savings Plans cover machine learning work on Amazon SageMaker.

Best for: the steady part of your usage. Your main website, core APIs, and internal systems that run all day, every day.

3. Reserved Instances: the older commitment model

Reserved Instances (RIs) came before Savings Plans. You commit to a specific server type in a specific region for one or three years, and on EC2 you can get up to 72% off.

For EC2, most businesses now prefer Savings Plans because they bend more easily. RIs still matter, though. They're how you get discounts on services like Amazon Redshift and OpenSearch, and a three-year RDS reservation can still beat the 35% ceiling of the new Database Savings Plans. The trade-off is that the RI locks you to one database type and region.

Main features

• Standard RIs give the biggest discount, and you can resell unused ones on the Reserved Instance Marketplace.

• Convertible RIs give a smaller discount but let you swap to a different server type later.

• You can pay all upfront, partly upfront, or nothing upfront. More upfront means a slightly bigger discount.

Best for: databases and data warehouses that you're confident will look the same for years.

4. Spot Instances: very cheap, but AWS can take them back

Spot Instances are AWS's spare capacity, sold at up to 90% off the On-Demand price. The catch is that AWS can reclaim them whenever it needs that capacity, and you get only a two-minute warning.

Works well for

• Batch jobs such as report generation, image resizing, or video processing.

• Machine learning training that saves its progress regularly, so it can pick up where it left off.

• Web servers that don't store anything locally, mixed in with On-Demand servers in the same group.

Not a good fit for: a single database server, or anything that loses important work if it stops without warning.

How the pricing models differ

The four models are really trade-offs between price and freedom. Four things separate them.

Commitment. On-Demand asks for nothing. Spot asks for nothing either, but it can vanish at any time. Savings Plans and Reserved Instances ask you to commit for one or three years, and you pay for that commitment whether you use it or not.

Flexibility. Compute Savings Plans follow your usage across regions and server types. EC2 Instance Savings Plans and Standard RIs are much narrower. If your team moves to a newer server family, a narrow commitment can end up covering nothing at all while you keep paying for it. Engineers call this a "stranded" commitment.

Type of risk. With commitments, the risk is financial: you might pay for capacity you no longer need. With Spot, the risk is technical: your server might disappear halfway through a task. With On-Demand, the only risk is paying more than you had to.

Who does the work. On-Demand needs almost no planning. Commitments need someone to watch usage and renew or adjust them on time. Spot needs engineering effort so the app can survive interruptions.

Most well-run accounts mix all of them: commitments for the steady base, Spot for flexible background work, and On-Demand for unpredictable peaks.

Pricing models compared at a glance

Numbers worth knowing

A few figures from Flexera's 2026 State of the Cloud Report, which surveyed 753 cloud decision-makers, show why this topic keeps coming up in budget meetings:

•     Estimated wasted cloud spend rose to 29%, the first increase after five years of decline.

•     85% of organizations say managing cloud spend is a top challenge.

•     63% now have an established FinOps team (people whose job is to manage cloud costs).

•     83% run active enterprise workloads on AWS, slightly ahead of Azure at 79%.

•     Generative AI became the third most used public cloud service, used by 58% of organizations, up from 50%.

Cloud isn't a bad deal. But the bill needs someone paying attention, and AI workloads, which bill in hard-to-predict bursts, have made that harder.

The AWS tools that show you where the money goes

Each of these AWS tools answers a different question, and each has a blind spot.

AWS cost optimization strategies for businesses that work in practice

Here are the AWS cost optimization strategies for businesses that tend to save the most with the least drama. They're roughly in the order you should try them.

Rightsize first, commit second

Rightsizing means matching a server's size to what it really needs. It's very common to find servers averaging 10% to 15% CPU because someone picked a large size "to be safe" two years ago and nobody looked again.

Do this before buying any Savings Plans. If you commit first and shrink later, you've locked in a discount on capacity you no longer use.

Here's a simple example. A company runs eight m6i.2xlarge servers for its API, averaging 12% CPU and peaking near 35%. Moving to m6i.xlarge, with half the power, roughly halves the hourly cost. Peaks now reach about 70%, which still leaves room. Only then does it make sense to size a Savings Plan.

Switch off what nobody uses at night

A week has 168 hours. A development team might use its test environment for 50 of them. If those servers run only during working hours, you cut about 70% of their cost without touching production.

AWS has a ready-made Instance Scheduler for this, or your team can set up a simple scheduled rule. One thing to watch: a stopped RDS database starts itself again automatically after seven days, so a scheduler needs to handle that.

Try Graviton processors

Graviton is AWS's own processor, based on ARM chip design. AWS says it offers up to 40% better price-performance than comparable x86 servers. For managed services like RDS and Lambda, switching is often just a setting. Your own code may need rebuilding for ARM, so test on a few servers first.

Clean up storage

• Move EBS volumes from gp2 to gp3. gp3 costs about 20% less per GB, and you can switch without downtime.

• Delete unattached EBS volumes. They keep billing even after the server they belonged to is gone.

• Remove old snapshots and machine images that no one will ever restore.

• Add S3 lifecycle rules that move old files to cheaper classes, like Infrequent Access or Glacier. For data with unknown access patterns, S3 Intelligent-Tiering moves files for you.

• Set a retention period on CloudWatch Logs. By default, logs are kept forever.

• Add a lifecycle rule that clears incomplete multipart uploads in S3. These hidden pieces take up paid space.

Watch data transfer

Data transfer is the line on the bill that confuses people most. Data coming into AWS is generally free. Data going out to the internet costs money after the first 100 GB each month. Data moving between Availability Zones inside a region is charged too.

The one that surprises many teams is the NAT Gateway. Private servers that download updates or call outside services through a NAT Gateway pay a processing fee on every gigabyte, on top of an hourly charge. If most of that traffic is headed to S3 or DynamoDB, a VPC gateway endpoint sends it there directly, and those gateway endpoints are free.

Look for small charges that add up

Some costs look tiny on their own and only hurt at scale.

• Public IPv4 addresses. Since February 2024, AWS charges $0.005 per hour for each one, about $3.60 a month. Fifty forgotten addresses come to roughly $180 a month.

• RDS Extended Support. If you keep running a database engine version after its standard support ends, AWS adds an extra hourly fee based on the database size. Planning upgrades on time avoids it.

Use serverless where traffic is low or spiky

Lambda, Fargate, Aurora Serverless v2, and DynamoDB on-demand charge for what you use rather than for servers sitting ready. An internal tool used two hours a day is a good candidate. For high, steady traffic, though, a well-sized server with a Savings Plan often costs less, so compare both with real numbers.

Buy commitments in layers

Instead of one large purchase, buy smaller Savings Plans every month or quarter. They then expire at different times, giving you regular chances to adjust.

AWS cost optimization best practices in 2026: what has changed

The basics above have worked for years. A few things are new, and they shape AWS cost optimization best practices in 2026.

AI workloads need their own budget

Generative AI is billed differently from normal servers. Amazon Bedrock charges per token, which is roughly per piece of text sent in and out. GPU servers charge by the hour whether or not they're busy. Both can grow fast and quietly.

• Give AI features their own budget and alerts, separate from the rest of the account.

• Use smaller, cheaper models for simple jobs like sorting support tickets or short summaries. Save the large models for work that needs them.

• Use batch processing for jobs that don't need an instant answer. Bedrock's batch mode is priced lower than real-time calls for supported models.

• Use prompt caching when many requests repeat the same long instructions or documents.

• Log token use per feature, so you know which part of your product is driving the cost.

Database discounts work differently now

Before Database Savings Plans, database discounts meant buying a reservation for each engine in each region. Now you can make one spending commitment across many database services. This is useful if you're planning to move from, say, RDS for PostgreSQL to Aurora. For a database that won't change for three years, a Reserved Instance may still give a bigger discount.

Measure cost per unit, not just the total

A growing bill isn't always bad news. If your AWS cost went up 20% while orders went up 50%, you're doing better. Tracking cost per order or per active user tells you whether spending is healthy.

Guardrails over manual reviews

Monthly reviews catch problems late. More teams now set rules that stop problems early: blocking very large or GPU server types in development accounts, requiring tags before resources can be created, and setting maximum sizes on auto scaling groups. Following AWS cost optimization best practices in 2026 mostly means building these habits into the system instead of relying on people to remember.

The messy part: data gaps, conflicting signals, and exceptions

Most cost guides stop at the tips. In real accounts, the harder part is knowing what to trust and when to act. This is where good intentions often go wrong.

Data gaps: when the bill doesn't tell the whole story

Billing data is not live. Cost Explorer and anomaly detection work on data that can be several hours to a day old. A bug that starts on a Friday night can run most of the weekend before any cost alert fires.

A few other gaps catch teams out:

• Tags don't work backwards. Cost allocation tags show up in billing only from the day you activate them. Last quarter's untagged spending stays untagged.

• Some costs can't be tagged cleanly. Support fees, some data transfer, and shared NAT Gateways don't belong to one team. Agree early on how to split them, for example by each team's share of usage.

• Credits hide the real cost. Startup or promotional credits make the bill look small. Look at costs before credits so you know what you'll pay once they run out.

• Upfront payments create fake spikes. An upfront RI payment shows as one large charge in one month unless you view "amortized" cost, which spreads it across the term.

For fast-moving risks, don't wait for billing data. Set CloudWatch alarms on usage metrics like Lambda invocations, number of running servers, or GPU hours. These update within minutes.

Conflicting signals: when tools and people disagree

Data doesn't know your business. Here are common clashes and how to sort them out.

A good rule: treat every recommendation as a question, not an instruction. The tool supplies the numbers, and the person who owns the system supplies the context. You need both before changing anything in production.

Real-time decisions: what happens while things are running

Some cost decisions happen every few minutes without anyone watching. Auto scaling adds and removes servers based on rules you set, so those rules directly shape your bill. If servers are removed too slowly after a spike, you pay for idle capacity. If they're added and removed too quickly, the system keeps flipping back and forth. Always set a maximum size. A cap is what stops a bug from launching 500 servers overnight.

Spot needs its own planning. AWS sends a two-minute notice before taking a Spot server back, and sometimes an earlier "rebalance" signal when the risk is rising. Apps that listen for these signals can hand off work in time, and spreading requests across several server types makes interruptions less likely.

AWS Budgets can also act automatically. When a limit is crossed, a budget action can apply a restrictive permission policy or stop specific EC2 or RDS servers. That works well in development accounts. In production, it's usually safer to alert a person than to shut things down automatically.

Exceptions: things you shouldn't "optimize"

Not everything that looks wasteful is waste. Leave these alone, or handle them carefully:

• Records you must keep by law, such as financial or health data. Move them to a cheaper storage class instead of deleting them.

• Disaster recovery standby systems. They look idle because they're meant to be idle until something breaks.

• Extra capacity before peak season, like a big sale or holiday rush.

• Software licensed by processor core, such as some Oracle or SQL Server setups. Changing server size can change what you owe in licences, sometimes by more than the AWS saving.

• Services where spare room is the point, such as payment or login systems that must stay fast under sudden load.

Mark these with a tag, such as cost-exception, along with a review date. That way the next person running a clean-up knows to skip them, and nobody forgets to check whether the exception still makes sense.

System behavior under load: how costs run away

The scariest AWS bills usually come from systems reacting badly under pressure, not from planned growth. A few patterns show up again and again.

Retry storms. A service slows down, so the apps calling it try again. Each retry is another request, another Lambda run, another log line. Costs go up at the exact moment the product stops working. Retries with growing wait times between them (called exponential backoff) prevent this.

Loops between services. A Lambda function writes a file to an S3 bucket, and that bucket triggers the same function again. AWS now detects and stops some of these loops automatically, but not every pattern, so triggers need careful design.

Log floods and cross-zone chatter. Debug logging left on during a traffic spike creates huge log volumes, and CloudWatch charges per gigabyte it takes in. Busy services talking across Availability Zones add transfer fees the same way.

Simple guardrails help with all of these: concurrency limits on Lambda, maximum sizes on auto scaling groups, retry limits, and alarms on usage metrics rather than only on cost.

A 30-day plan to get started

If you're wondering how businesses can reduce AWS infrastructure costs without a big project, this four-week plan is a sensible start.

Week 1: See what you're spending

• Open Cost Explorer and group costs by service and by account.

• Create a monthly budget with alerts at 80% and 100%.

• Turn on Cost Anomaly Detection.

• Pick three or four tags (such as team, environment, and project) and activate them for billing.

Week 2: Take the quick wins

• Delete unattached EBS volumes, old snapshots, and unused public IP addresses.

• Schedule development and test servers to stop outside working hours.

• Set log retention periods in CloudWatch.

Week 3: Fix the size of things

• Review Compute Optimizer suggestions with each system's owner.

• Move gp2 volumes to gp3 and add S3 lifecycle rules.

• Test Graviton on one non-critical service.

Week 4: Lock in lower rates

• Look at your usage after the changes and find your steady baseline.

• Buy a Compute Savings Plan covering part of that baseline, and review database commitments.

• Set a monthly 30-minute cost review on the calendar.

Final thoughts

Reducing your AWS bill isn't a one-time clean-up. It's a habit of knowing what you run, why, and what it costs. Start with visibility, clear the obvious waste, fix sizes, and only then commit to discounts.

If your team is short on time, a cloud or development partner can run a first review and set up the guardrails. Either way, the ideas here, from how businesses can reduce AWS infrastructure costs to the AWS cost optimization best practices in 2026, come down to the same thing: paying for what you use and paying a fair price for it.