Reserved Instances vs Savings Plans: Cut Your AWS Bill in 2026

Every founder I work with has the same reaction when they open their AWS billing console for the first time after crossing ₹2 lakh a month: a mix of pride and panic. Pride because the business is scaling. Panic because they realise they've been paying full on-demand rates for compute that's been running 24x7 for the last eight months. That's money you'll never get back.

Here's a number that surprises most people. On a typical steady-state workload, a well-structured AWS commitment can cut your compute bill by 40 to 72 percent compared to on-demand pricing. For an SMB in Pune or Bengaluru spending ₹3 lakh a month on EC2 and RDS, that's the difference between ₹36 lakh and roughly ₹15 lakh a year. Real money that could fund two more engineers or your next product launch.

But there's a catch, and it's the reason this post exists. AWS gives you two very different ways to lock in those discounts, and picking the wrong one can leave you stuck paying for capacity you don't use. This is the practical breakdown of AWS reserved instances vs savings plans for Indian businesses in 2026: what each actually commits you to, when each wins, a real worked example with rupee figures, and a checklist so you don't over-commit as your spend grows.

Key Takeaways

• Savings Plans are more flexible and now cover the majority of SMB use cases. Reserved Instances still win in narrow scenarios like Redis-heavy ElastiCache or when you need capacity reservation guarantees.
• Never commit to more than 60-70% of your baseline usage. The rest should stay on-demand or Spot so you keep breathing room as workloads shift.
• Compute Savings Plans give roughly 66% off and apply across EC2, Fargate, and Lambda regardless of region, instance family, or OS. EC2 Instance Savings Plans go up to ~72% but lock you to a family and region.
• Pay attention to the term and payment option. 1-year No Upfront preserves cash flow; 3-year All Upfront gives the deepest discount but ties up capital and GST input timing.
• Audit before you buy. Use Cost Explorer's recommendation engine and at least 30 days of usage data before signing any commitment.
• Get an independent review if you're unsure. A short IT consulting engagement often pays for itself many times over on commitment decisions.

What's the difference between Reserved Instances and Savings Plans?

Both are commitment discounts. You promise AWS a certain amount of usage over one or three years, and in exchange they charge you a lot less than the on-demand sticker price. The difference is what you're committing to.

With Reserved Instances (RIs), you commit to a specific instance configuration. For EC2 that historically meant a particular instance type, region, tenancy, and operating system. Standard RIs are the most rigid but give the biggest RI discount. Convertible RIs let you swap configurations later but at a smaller discount. RIs still exist for RDS, ElastiCache, Redshift, OpenSearch, and DynamoDB.

With Savings Plans, you commit to spending a fixed amount of money per hour (measured in dollars, e.g. $2/hour) rather than to a specific machine. AWS then automatically applies your discount to whatever eligible compute you're running. There are two flavours:

• Compute Savings Plans — the flexible one. Apply across EC2, AWS Fargate, and Lambda, across any region, instance family, size, OS, or tenancy. Discount up to about 66%.
• EC2 Instance Savings Plans — locked to a specific instance family in a specific region (say m6i in Mumbai), but flexible on size and OS within that. Discount up to about 72%.

The mental model I give clients: Savings Plans are a discount on your spend; Reserved Instances are a discount on a specific resource. That single distinction drives 90% of the right decision.

A quick note on capacity reservations

One thing Savings Plans do not give you is a guarantee that capacity will be available in your Availability Zone. Standard RIs, when scoped to a specific AZ, do provide a capacity reservation. If you run workloads in a constrained region and absolutely must be able to launch a specific instance during a demand spike (think a fintech during month-end settlement in the ap-south-1 Mumbai region), that capacity guarantee matters. For most SMBs it doesn't, and the flexibility of Savings Plans wins.

How much can an Indian SMB actually save? A worked example

Let me walk through a real pattern I've seen repeatedly. A 40-person logistics-tech company in Gurgaon runs a tracking platform on AWS. Their monthly on-demand bill breaks down roughly like this:

• EC2 for the core application: ₹1,80,000/month (a steady cluster of m6i.large and m6i.xlarge running 24x7)
• RDS PostgreSQL for the primary database: ₹70,000/month
• ElastiCache Redis for session and route caching: ₹35,000/month
• Fargate for batch jobs and a few microservices: ₹40,000/month
• Data transfer, S3, CloudWatch, and misc: ₹45,000/month

Total on-demand: about ₹3,70,000/month, or ₹44.4 lakh a year. Data transfer and storage don't qualify for these commitments, so we set aside ₹45K and focus on the ₹3.25 lakh of committable compute and database spend.

Here's how we structured it after 45 days of usage analysis:

1. Baseline vs burst split. Their EC2 usage never dropped below the equivalent of about ₹1.3 lakh/month even at 3am. That's the true baseline. The rest fluctuated with delivery volume.
2. Compute Savings Plan for EC2 + Fargate. We committed a 1-year No Upfront Compute Savings Plan sized to that ₹1.3 lakh baseline. At roughly 54% effective savings for No Upfront over on-demand, that portion dropped to about ₹60,000/month. Because it's a Compute plan, it also soaks up their Fargate baseline automatically.
3. RDS Reserved Instance. The database runs constantly and won't change instance type for at least a year. A 1-year All Upfront RDS RI cut that ₹70,000 to roughly ₹42,000/month equivalent.
4. ElastiCache Reserved Node. Redis is steady too. A 1-year reserved node brought ₹35,000 down to about ₹22,000/month.
5. Left the burst capacity on-demand. Roughly ₹90,000 of EC2/Fargate stayed on-demand so peak festival-season delivery volume never hit a wall.

New effective monthly compute + database cost: about ₹2,14,000 versus ₹3,25,000. That's a saving of roughly ₹1.1 lakh a month, or ₹13.3 lakh over the year, without touching a single line of application code. The whole exercise took about a week of analysis and a few hours to execute.

Pro Tip: Don't buy a Savings Plan sized to your current total spend. Buy to your lowest sustained usage over the last 30-60 days. AWS bills any commitment you don't use, so a plan sized to peak means you're paying for hours where your servers were half-idle. Under-commit slightly and expand later. You can always buy a second plan; you can't cancel a Savings Plan.

Reserved Instances vs Savings Plans: side-by-side comparison

This is the table I put in front of decision-makers. Print it, stick it next to your Cost Explorer tab.

Criteria	Compute Savings Plan	EC2 Instance Savings Plan	Standard RI	Convertible RI
Max discount vs on-demand	~66%	~72%	~72%	~66%
Flexibility across services	EC2, Fargate, Lambda	EC2 only	Depends on service (EC2/RDS/etc.)	EC2 only
Change instance family	Yes, automatic	No (family locked)	No	Yes, via exchange
Change region	Yes, automatic	No (region locked)	No (region scoped)	Via exchange
Capacity reservation	No	No	Yes (if AZ-scoped)	Yes (if AZ-scoped)
Can sell on Marketplace	No	No	Yes	No
Best for	Mixed, evolving workloads	Stable EC2 family in one region	Non-EC2 services (RDS, Redis)	Long-term but uncertain configs

The headline takeaway: for EC2, Fargate, and Lambda, Savings Plans have essentially replaced RIs for most buyers because you keep the discount even when you resize or migrate instances. RIs remain relevant mainly for RDS, ElastiCache, Redshift, and OpenSearch, where Savings Plans don't apply at all.

When should you choose Reserved Instances over Savings Plans?

Savings Plans are the sensible default for compute, but there are specific situations where RIs still make sense. Choose Reserved Instances when:

• You're committing to non-compute services. RDS, ElastiCache, Redshift, OpenSearch, and DynamoDB don't participate in Savings Plans. RIs (or reserved nodes/capacity) are your only commitment discount for these.
• You need a guaranteed capacity reservation in a specific Availability Zone. This is the one thing Savings Plans genuinely cannot do.
• You want the option to sell unused commitment. Standard RIs can be listed on the AWS Reserved Instance Marketplace. If you're worried about a workload winding down, a sellable Standard RI gives you an exit that a Savings Plan doesn't.
• Your instance configuration is truly fixed for the whole term. If you know the exact family, region, and OS won't change, a Standard RI's slightly deeper predictability can suit compliance-heavy setups.

For everything else, especially teams still refining architecture or planning a cloud migration, the flexibility of a Compute Savings Plan protects you from committing to a machine you'll outgrow in six months.

Common Mistake: Buying a 3-year All Upfront Standard RI for a startup that's still finding product-market fit. I've seen a Noida SaaS company lock ₹18 lakh into a 3-year EC2 RI, then re-architect to containers four months later. The RI kept billing for a machine family they no longer used, and because it was a Standard RI they could only recover part of it on the Marketplace at a discount. Match the term to your certainty, not your optimism.

How do term length and payment options affect your AWS bill and cash flow?

Both RIs and Savings Plans offer three payment options and two terms. This choice is as much a finance decision as a technical one, so loop in whoever manages your books.

• No Upfront — you pay monthly, no lump sum. Smallest discount, best for cash-flow-conscious SMBs. Great for a first commitment.
• Partial Upfront — pay part now, part monthly. Middle ground.
• All Upfront — pay the entire term at once. Deepest discount, typically a few extra percentage points over No Upfront.

On the India-specific side, remember that AWS India bills in INR through Amazon Web Services India Private Limited, and your invoices carry 18% GST. If you're GST-registered, that's input tax credit you can claim, but the timing matters for All Upfront purchases. A ₹18 lakh All Upfront commitment means an ₹18 lakh outflow plus GST now, with the input credit flowing through in that period. Talk to your CA before a large upfront so your working capital and ITC claims line up.

My default recommendation for most first-time committers: 1-year, No Upfront. You give up a few percent of discount versus 3-year All Upfront, but you keep cash free and you're not locked in while your architecture matures. Move to 3-year terms only for the rock-solid parts of your stack, like a database that's been stable for a year.

Step-by-step: how to buy the right commitment without over-committing

Here's the process I run for clients. You can brief your DevOps partner with this or do it yourself if you have console access.

1. Collect at least 30 days of usage. Open AWS Cost Explorer and set the granularity to daily. Filter by service. You're looking for the floor of your usage, not the average.
2. Separate committable from non-committable spend. Data transfer, S3, and CloudWatch don't qualify. Set them aside so you don't accidentally size a plan against them.
3. Identify your true baseline. The lowest sustained level over the period. That's your safe commitment ceiling. Then commit to only 60-70% of it on your first purchase.
4. Run the recommendation engine. Cost Explorer has a Savings Plans recommendations page and an RI recommendations page. Use the 30-day lookback with the No Upfront, 1-year filter as your starting point, then compare.
5. Split by service. Compute Savings Plan for EC2/Fargate/Lambda. Reserved nodes/instances for RDS and ElastiCache. Don't try to cover everything with one instrument.
6. Decide term and payment. 1-year No Upfront for anything uncertain. 3-year for genuinely stable core infrastructure only.
7. Purchase and tag. Buy the commitment, then set a calendar reminder for two weeks before expiry so you can review and renew instead of silently dropping back to on-demand.
8. Set up a monthly utilisation check. Cost Explorer shows Savings Plan and RI utilisation. If utilisation drops below ~90%, you over-committed and should size your next purchase down.

If your team is stretched thin, this is exactly the kind of work our cloud managed services team handles as an ongoing optimisation retainer. Sometimes the smarter question isn't the commitment model at all but whether you should be running this in-house; our post on the cloud skills gap in India and what SMBs should hire vs outsource unpacks that trade-off.

Where commitments fit into a bigger cost strategy

Commitment discounts are the fastest lever, but they're one of several. Before or alongside them, look at:

• Right-sizing. Half the SMBs I audit are running instances two sizes larger than needed. No point reserving an m6i.2xlarge you should have downsized to an m6i.large.
• Spot Instances for fault-tolerant batch jobs and CI/CD runners. Up to 90% off on-demand, and they pair well with Savings Plans covering your baseline.
• Graviton (ARM) instances. AWS's own processors often give 20-40% better price-performance. Migrating to Graviton before committing means you commit to a cheaper baseline.
• Storage tiering. Move cold data to S3 Intelligent-Tiering or Glacier.

If you're a manufacturer or traditional business only now moving workloads to the cloud, sequence these correctly rather than reserving first. Our digital transformation playbook for Indian manufacturers covers that sequencing, and agencies weighing hosting models will find reseller hosting vs cloud for Indian agencies useful context.

Frequently asked questions

Can I cancel a Savings Plan if my usage drops?

No. Savings Plans cannot be cancelled or refunded once purchased, and they're not transferable. This is exactly why you size conservatively to your usage floor. If you need an exit option, a Standard Reserved Instance is the only commitment you can sell, on the AWS Reserved Instance Marketplace.

Do Savings Plans cover RDS and ElastiCache?

No. Savings Plans only apply to EC2, AWS Fargate, and Lambda. For RDS, ElastiCache, Redshift, and OpenSearch you need Reserved Instances or reserved nodes. That's why most SMBs end up using both instruments together.

Is a 1-year or 3-year commitment better for a growing startup?

Start with 1-year for almost everything. A 3-year term deepens the discount but locks you in while your architecture is likely to change. Reserve 3-year commitments for genuinely stable components like a production database that hasn't changed in a year.

How does GST work on AWS commitment purchases in India?

AWS India invoices in INR with 18% GST, and GST-registered businesses can claim input tax credit. For large All Upfront purchases, the full amount plus GST goes out at once, so coordinate the timing with your accountant to align your working capital and ITC claim in the right period.

What happens to my Savings Plan discount if I resize my instances?

With a Compute Savings Plan, the discount follows your spend automatically across families, sizes, regions, and even between EC2, Fargate, and Lambda. That's its biggest advantage over Reserved Instances, which are tied to a specific configuration.

How much AWS spend justifies buying a commitment?

If you have any workload running consistently 24x7 for more than a couple of months, even at ₹40,000-50,000/month, a commitment usually pays off. The steadier and more predictable the usage, the sooner the savings justify the lock-in.

Should I use a third-party tool or consultant for this?

Cost Explorer's native recommendations are good enough for a first purchase. Once your monthly spend crosses a few lakh or you're juggling multiple accounts, an independent review catches over-commitments and right-sizing wins that easily cover the fee. That's a common piece of our IT consulting work.

The bottom line

When you strip away the jargon, the AWS reserved instances vs savings plans decision comes down to two questions: Is this workload compute (EC2/Fargate/Lambda) or a managed service like RDS? and How certain am I about this configuration for the next year? Compute that might change gets a flexible Compute Savings Plan. Databases and caches get Reserved Instances. And you never commit more than about two-thirds of your usage floor, so growth never punishes you.

Done properly, an Indian SMB can knock 40 to 60 percent off its committable AWS bill in a single afternoon of work, without risk to reliability and without touching application code. That's not a marginal optimisation. On a ₹3 lakh monthly spend it's over ₹13 lakh a year back in the business.

If you'd like a second pair of eyes on your billing console before you commit, or you're planning a broader cloud migration and want the cost model designed right from day one, get in touch with the eDarpan team. You can also explore our full range of technology services, from custom software to Google Workspace and Microsoft 365 licensing, if you're rationalising your whole IT stack this year.

Image credit: People and perceptions of technology by renaissancechambara via flickr (BY 2.0), sourced through Openverse.