icon/copy-url

favicon-32x32

logo-2x

IT Consulting | Outsourcing | Vietnam

**TL;DR:** Six strategies that deliver real savings: right-sizing (20-40% compute savings, low risk), Savings Plans (30-72% discount for commitment), auto-scaling (20-60% for variable workloads), Spot instances (60-90% for fault-tolerant workloads), storage tiering (40-80% on S3), and serverless economics (varies by workload pattern). Start with right-sizing and Savings Plans. They're low effort, high impact, and deliver 30-50% savings for most teams.

---

In [Part 1](https://innomizetech.com/blog/12-hidden-aws-costs-what-most-teams-miss-on-their-aws-bill), we covered the hidden costs that silently drain your budget. Knowing where money leaks is useful. Knowing how to stop the leaks is better.

Not all optimization strategies deliver equal results. Some save 5%. Others save 50%.

After years of optimizing client AWS spend, these are the six strategies that consistently deliver results.

## 1. Right-sizing: the highest-ROI optimization

Right-sizing means matching instance sizes to actual workload requirements. It sounds straightforward, and it is. That's also why it's often the most effective optimization strategy.

Most teams over-provision. They pick m5.xlarge "to be safe" when m5.large would handle the load fine. The difference: roughly **$140/month per instance**.

We typically see **20-40% reductions** in compute costs from right-sizing alone. The risk is minimal since instance resizing is reversible.

### How to right-size

Start by baselining current utilization. Use [CloudWatch metrics](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html): CPU, memory, network. Look at P95 values, not averages. Averages hide the spikes that matter. Give yourself at least two weeks of data before making decisions.

**Identify candidates** by looking for instances consistently below 40% CPU utilization. Check memory usage below 50%. Look at network throughput well below instance limits.

**Test before committing.** Resize in non-production first. Monitor for a week before touching production.

> AWS Compute Optimizer provides free right-sizing recommendations. Start there before building custom analysis.

Here's a simple decision framework:

| Current Utilization | Action |
|---------------------|--------|
| <20% sustained | Consider downsizing by 2 tiers |
| 20-40% sustained | Consider downsizing by 1 tier |
| 40-70% sustained | Probably correctly sized |
| >70% sustained | Consider upsizing or scaling out |

### What we see in audits

Teams copy infrastructure templates between projects without reviewing instance families. In one recent audit, we found 12 RDS instances still running on db.t3, an instance family released in 2018.

The problem isn't just outdated hardware. Older instance families have discount limitations:

| Instance Family | Reserved Instance | DB Savings Plan |
|-----------------|-------------------|-----------------|
| db.t3 | ✓ | ✗ |
| db.t4g | ✗ | ✗ |
| db.r7g | ✓ | ✓ |

That t4g family, released in 2021 with better performance, has zero discount options. AWS announced RI support for t4g years ago, but it remains unavailable as of early 2026.

The counterintuitive result: for 24/7 dev environments, staying on db.t3 with Reserved Instance can be cheaper than upgrading to db.t4g at on-demand rates.

**Action:** Audit instance families annually. Right-sizing isn't just about capacity; it's about discount eligibility.

## 2. Savings Plans vs Reserved Instances: the commitment decision

Committing to usage in exchange for discounted rates can save **30-72%** on compute costs. The question is which commitment model to use.

### The 2025 reality

[Reserved Instances](https://aws.amazon.com/ec2/pricing/reserved-instances/) are being replaced by [Savings Plans](https://aws.amazon.com/savingsplans/) for most use cases. Unless you have specific requirements, Savings Plans are usually the better choice.

The tradeoffs look like this:

| Factor | Reserved Instances | Savings Plans |
|--------|-------------------|---------------|
| Flexibility | Locked to instance type and region | Applies across instance families |
| Coverage | EC2 only | EC2, Fargate, Lambda |
| Management | Complex (exchanges, modifications) | Simple (automatic application) |
| Discount depth | Slightly higher (1-3%) | Slightly lower but more flexible |

**Choose Savings Plans** when you're not certain exactly which instances you'll run, when you use multiple compute services (EC2 plus Fargate plus Lambda), or when you want to set-and-forget.

**Choose Reserved Instances** when you have stable, predictable workloads locked to specific instance types, when the extra 1-3% discount matters at your scale, or when you have dedicated RI management capability.

### Commitment levels

How much to commit depends on your risk tolerance:

*Conservative:* Cover 50% of your baseline usage with 1-year Savings Plans. This leaves room for workload changes while still capturing 15-36% savings.

*Moderate:* Cover 70% of baseline with 1-year commitments, 30% with 3-year. Balances savings against flexibility.

*Aggressive:* Cover 80%+ with 3-year commitments. Maximum savings, minimum flexibility. Only appropriate when you have high confidence in future usage.

> Over-committing is worse than under-committing. Unused reservations have zero salvage value. When in doubt, commit to less.

### The instance sprawl trap

One client had 12 different RDS instance types across projects: db.t3.medium, db.r5.large, db.m5.xlarge, and more. They couldn't commit to Savings Plans without risking underutilization. The variety was too high to establish a reliable baseline per type.

The solution was to standardize on 3 instance types instead of 12. Now they can purchase Savings Plans covering 70% of baseline, resulting in 30% RDS cost reduction.

Standardization enables commitment. Commitment enables discounts.

## 3. Auto-scaling: pay only for what you use

Savings potential: **20-60%** for variable workloads.

### The common mistake

Teams provision for peak and run at peak 24/7. If your peak requires 10 instances but average load needs 4, you're wasting **60% of your compute spend** during off-peak hours.

The solution: scale down when demand drops, scale up when it rises.

### Scaling patterns

[Target Tracking](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) is the simplest. Set a target like "keep average CPU at 60%" and AWS handles the rest. Best for most web applications.

[Step Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-simple-step.html) gives more control. Define explicit rules: "Add 2 instances when CPU exceeds 80%." Best for applications with known scaling characteristics.

[Scheduled Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-scheduled-scaling.html) handles predictable patterns. Scale up at 9am, down at 6pm. Best for Dev/Test environments or workloads with consistent daily patterns.

[Predictive Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-predictive-scaling.html) uses ML to scale proactively, eliminating warm-up lag. Best for consistent patterns that target tracking struggles to anticipate.

### Implementation checklist

Before deploying auto-scaling:

- Enable detailed monitoring (1-minute metrics instead of 5-minute)
- Set appropriate cooldown periods to avoid thrashing
- Configure health checks to remove unhealthy instances
- Test scaling policies under load before production deployment
- Set maximum capacity limits to prevent runaway costs

## 4. Spot Instances: 60-90% savings for fault-tolerant workloads

[Spot Instances](https://aws.amazon.com/ec2/spot/) use spare AWS capacity at steep discounts. The tradeoff: instances can be reclaimed with 2-minute notice when AWS needs the capacity back.

Savings: **60-90%** compared to on-demand.

### Good candidates for Spot

Batch processing and data pipelines work well. So do CI/CD build runners. Development and testing environments are natural fits. Stateless web servers behind load balancers can use Spot if you have enough instances that losing one doesn't hurt. Big data processing with EMR or Spark handles interruptions gracefully.

### Poor candidates for Spot

Databases and stateful applications shouldn't run on Spot. Single-instance workloads with no redundancy can't tolerate interruptions. Any application that can't restart cleanly should avoid Spot.

### Spot strategies

*Diversification* reduces interruption risk. Use multiple instance types (m5.large, m5a.large, m5n.large) across multiple availability zones.

*[Spot Fleet](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-fleet.html)* lets you define capacity needs and let AWS choose the best instances. Automatically replaces interrupted instances. Best for large-scale batch processing.

*Spot with on-demand fallback* runs Spot when available, falls back to on-demand when not. Best for production workloads that can tolerate some Spot usage.

### How we use Spot on EKS

Our approach balances cost with reliability:

**Dev environments:** 100% Spot instances, scale to zero during non-working hours. A scheduled action at 7pm scales the node group to zero. At 8am, it scales back up. On weekends, node count drops to zero. This results in near-zero costs outside working hours.

**Staging environments:** Mix of on-demand (30%) and Spot (70%). The on-demand baseline handles interruptions; Spot handles burst capacity.

**Production workloads:** On-demand for stateful services, Spot for stateless workers. The key is workload classification, not a blanket policy.

The combination of Spot instances and scale-to-zero can cut dev environment costs by 80-90%.

**Check historical Spot pricing** before committing. Prices vary widely by instance type and region:

```
aws ec2 describe-spot-price-history --instance-types m5.large --product-descriptions "Linux/UNIX"
```

## 5. Storage tiering: right storage for right data

Storage tiering means moving data to cheaper storage classes based on access patterns. The savings potential ranges from **40-80%** depending on your data characteristics.

### S3 storage classes

S3 offers multiple storage classes at different price points:

| Class | Use Case | Cost (US East) |
|-------|----------|----------------|
| Standard | Frequently accessed data | **$0.023/GB** ([see Pricing](https://aws.amazon.com/s3/pricing/)) |
| Intelligent-Tiering | Unknown access patterns | $0.023/GB + monitoring fee |
| Standard-IA | Infrequent access (30+ days) | **$0.0125/GB** |
| Glacier Instant Retrieval | Archive with instant access | **$0.004/GB** |
| Glacier Flexible Retrieval | Archive (minutes to hours) | $0.0036/GB |
| Glacier Deep Archive | Long-term archive (12+ hours) | **$0.00099/GB** |

The price difference between Standard and Deep Archive is **23x**. That matters for large datasets.

### Lifecycle policies

[S3 Lifecycle policies](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) automate transitions based on object age. A typical policy might move objects to Standard-IA after 30 days, to Glacier Instant Retrieval after 90 days, and to Deep Archive after a year.

Set up policies once and let them run. Transitions happen automatically.

### EBS optimization

EBS volume types have different cost-performance characteristics:

| Volume Type | Use Case | When to Consider |
|-------------|----------|------------------|
| gp3 | General purpose | Default choice for most workloads |
| gp2 | Legacy | Migrate to gp3 (same price, better performance) |
| io2 | High IOPS | Only for databases needing >16K IOPS |
| st1 | Throughput-optimized | Large sequential workloads |
| sc1 | Cold storage | Infrequently accessed data |

**Quick win:** Migrate all gp2 volumes to gp3. Same price, 20% more baseline IOPS, configurable throughput. There's no reason to stay on gp2.

## 6. Serverless economics: when it saves money (and when it doesn't)

Serverless can cut costs 50-80% for the right workloads. It can also double or triple costs for the wrong ones. Understanding which is which matters.

### When serverless saves money

Sporadic workloads benefit from serverless pricing. APIs with under 1 million requests per month pay almost nothing on Lambda. You're not paying for idle capacity.

Variable traffic patterns fit well. If your traffic swings 10x or more between peak and trough, paying per-invocation aligns costs with actual usage.

Event-driven processing (S3 events, SQS messages, and similar triggers) naturally fits the serverless model.

Development environments save money on Lambda. You pay nothing when nobody's working. With containers, you pay for running instances 24/7 whether anyone uses them or not.

### Our default architecture decision

At INNOMIZE, serverless is our default starting point for new systems. It's cheapest to start and operate, even when it may not be cheapest at scale.

Across projects we've built with Lambda, API Gateway, and DynamoDB, the pattern holds: computation costs are typically the smallest line item. What dominates?

- Data transfer (API Gateway egress, DynamoDB streams)
- Storage (S3, DynamoDB capacity)
- Third-party integrations (not AWS at all)

For a typical API serving 1M requests/month, Lambda compute costs roughly $0.20. The API Gateway costs more. The engineering time to manage containers would cost far more.

| Cost Factor | Serverless | Containers |
|-------------|------------|------------|
| Compute (1M req/mo) | ~$0.20 | ~$50-100 (always-on) |
| Operational overhead | Near-zero | 2-4 hrs/month |
| Scaling complexity | Automatic | Manual or configured |

The break-even point exists: around 50% sustained utilization, containers become competitive. But most of our workloads never hit that threshold.

**When we choose containers:** Workloads requiring persistent connections (WebSockets), CPU-intensive processing exceeding Lambda's 15-minute limit, or existing systems not worth migrating.

### When serverless costs more

Steady high-volume workloads often cost more on Lambda. Once you exceed roughly 50% utilization, dedicated capacity becomes cheaper.

Long-running processes hit [Lambda's 15-minute limit](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html). If your process needs to run longer, you need containers.

Memory-intensive workloads pay Lambda's memory-based pricing even when CPU is the actual constraint.

### The Lambda Managed Instances option

[Lambda Managed Instances](https://aws.amazon.com/blogs/compute/introducing-lambda-managed-instances/), announced at re:Invent 2025, changes the calculation. It eliminates cold starts and qualifies for EC2 Savings Plans (up to 72% discount). We wrote a [detailed analysis of this update](https://innomizetech.com/blog/aws-lambda-s-biggest-update-in-years-what-it-means-for-your-architecture).

The break-even point: at roughly 50% utilization, Lambda Managed Instances becomes competitive with traditional Lambda Standard for predictable workloads.

### Decision matrix

| Workload Pattern | Recommendation |
|------------------|----------------|
| Sporadic, unpredictable | Lambda Standard |
| Steady, predictable, latency-sensitive | Lambda Managed Instances |
| Steady, high-volume, cost-sensitive | ECS Fargate or EC2 |
| Complex, long-running | ECS or EKS |

## Prioritizing optimizations

Not all optimizations deserve equal effort.

| Strategy | Effort | Savings Potential | Risk |
|----------|--------|-------------------|------|
| Right-sizing | Low | 20-40% | Low |
| Savings Plans | Low | 30-72% | Medium (commitment) |
| Auto-scaling | Medium | 20-60% | Low |
| Spot Instances | Medium | 60-90% | Medium (interruptions) |
| Storage Tiering | Low | 40-80% | Low |
| Serverless Migration | High | Varies | Medium |

**Start here:** Right-sizing and Savings Plans. Low effort, high impact, low risk. These two strategies alone often deliver **30-50% savings**.

**Next:** Storage tiering and auto-scaling. Moderate effort with 20-60% potential savings.

**Then:** Spot instances for appropriate workloads. High savings but requires workload analysis.

**Finally:** Consider serverless migration for specific workloads that fit the model well.

## What comes next

Strategies are useless without execution. In Part 3, we give you a step-by-step audit playbook, the exact process we use when we help clients optimize their AWS costs.

The playbook covers preparation, discovery, analysis, prioritization, and monitoring. Follow it quarterly and cost optimization becomes routine.

This article is part of our AWS Cost Optimization series. Need help implementing these strategies? [Contact us](https://innomizetech.com/contact) for a free initial assessment.


AWS Cost Optimization: 6 Proven Strategies for 2026

Similar articles