Untitled

Everyone knows Redshift on-demand pricing is brutal, and everyone knows reserved nodes fix that. What rarely gets said out loud: Redshift reservations are some of the least forgiving commitments AWS sells. No size flexibility, no convertible option, no marketplace to offload one you don't need. Before you sign up for three years, that's worth sitting with.

Start with the node type, not the discount

Redshift has three node families in play right now. RG is Graviton-powered and the one AWS now recommends for new builds up to 2.4x faster than RA3 with 30% lower price per vCPU, plus a built-in engine for querying Iceberg tables in S3 without Redshift Spectrum's per-terabyte scan fees.

RA3 is still fully supported for reservations. Compute and storage are billed separately here, so your bill has two moving parts even after you reserve.

DC2 is legacy at this point local SSD storage, recommended only under 1TB compressed, and reserved node support is thinner than the other two.

If you're on RA3 and weighing a 3-year commitment, run the RG migration math first. Locking into RA3 pricing before checking whether RG is the better long-term fit is an easy way to overpay.

The part that makes Redshift different

Compare this to RDS, where a reserved instance flexes across sizes within a family. Redshift has none of that:

No size flexibility: a reservation for ra3.4xlarge covers only ra3.4xlarge. Nothing else.

No convertible class: once you commit to a node type, you're locked to it for the term.

No resale market: Redshift reservations are explicitly excluded from the AWS Reserved Instance Marketplace. A stranded reservation just sits there costing money.

Stack those three together and a wrong purchase isn't a rounding error, it's tens of thousands of dollars committed to a configuration you no longer use, with no way out before the term ends.

What actually protects you here

The payment math (No Upfront, Partial Upfront, All Upfront) matters less than getting the node type and size right in the first place. A few things worth doing before you buy anything:

Watch CPU, disk I/O, and query queue depth for at least 30-60 days, ideally including a peak period.

If this is your first Redshift reservation, start with 1-year No Upfront. The gap between 1-year and 3-year savings is real but modest, a few points while the cost of the wrong 3-year bet is not.

Separately model Concurrency Scaling. Reserved nodes don't cover it, and it bills at on-demand rates once you exceed the daily free credit.

If you're managing reservations across RDS as well as Redshift, the sizing and payment-option logic carries over closely; this RDS Reserved Instances breakdown walks through the engine-by-engine version of the same decision. And if spend-based commitments feel like a better fit than locking into a specific node type, AWS Database Savings Plans are worth understanding as the more flexible alternative for parts of your database footprint.

Where the buyback guarantee changes the calculus

Given there's no marketplace and no convertible option, the standard advice is "buy conservatively and eat the risk." Usage.ai's Insured Flex Reserved Nodes take a different approach: if a reservation gets stranded, cluster resized, migrated, or shut down the unused commitment gets bought back as real cashback. That removes the main reason teams under-commit on Redshift in the first place.

If you want to see what your own cluster's reservation math looks like before committing to anything, the savings calculator is a fast way to check.

The full breakdown node families, payment option math, and the complete purchase sequence is in the original guide.

Microsoft just posted $75 billion in Azure revenue. Meanwhile your finance team wants to know why your bill keeps climbing 20% a quarter with zero user growth to show for it.

It's not you. Azure runs on thousands of SKUs, each with its own regional pricing, tiers, and commitment rules. Microsoft's docs explain what things cost. Almost nothing explains why you're overpaying, or how to stop.

Why Azure is its own special kind of hard

Azure shares AWS's complexity, then adds its own layer on top. Reserved VM Instances lock you into a specific VM series and region move from East US to West US, or swap series, and that reservation stops paying off.

Savings Plans trade some of that discount for flexibility: commit to a fixed hourly spend and it floats across regions and VM families. Reservations save more (up to 72%) if your setup never changes. Savings Plans save a bit less (up to 65%) but survive migrations. Most teams, unsure which to pick, end up choosing neither and just eat pay-as-you-go pricing.

Then there's Hybrid Benefit. If you're sitting on Windows Server or SQL Server licenses with Software Assurance, stacking that benefit with Reserved Instances can get you to 80% off. Figuring out which licenses qualify and staying compliant, though, is basically a part-time job.

Where the money actually leaks

Five services eat most Azure budgets:

Virtual Machines (40–60% of spend): Reserved Instances cut costs up to 72% on 3-year terms, but most workloads don't stay stable that long. Spot VMs save up to 90% for fault-tolerant jobs, with 30-second eviction notice.

Azure SQL Database (15–25%): Reserved capacity saves up to 33%, or up to 80% stacked with Hybrid Benefit. Reserve based on a growth guess and you're either paying for unused capacity or scrambling for more.

Storage Accounts (10–15%): Hot, cool, cold, and archive tiers each carry different access costs and minimum retention windows. Move data between tiers carelessly and transaction fees can wipe out the storage savings.

AKS (10–20%): AKS itself is free; the VMs underneath aren't. Clusters routinely run full-size VMs 24/7 for workloads that only spike during business hours.

App Services and Functions (5–15%): A Premium v3 P1 plan runs $400/month whether it serves 10 requests or 10 million. Running one plan per app multiplies that waste fast.

The commitment paradox

Here's the trap: the deepest Azure discounts require 1- or 3-year commitments, but nobody can predict their infrastructure three years out. So teams either overcommit and get stuck, or stay on pay-as-you-go and quietly overpay every month.

This is the exact problem Usage.ai's Insured Commitments were built around, they purchase optimized reservations and Savings Plans on your behalf, and if usage patterns shift, buy back what's unused in cash. You get the commitment-level discount without carrying the commitment-level risk.

Mistakes worth avoiding

A few patterns show up constantly:

Moving 10TB from Hot to Cool tier and getting surprised by transaction fees that eat the savings

Over-reserving SQL Database capacity, which can't be exchanged or refunded, 50–60% coverage is the safer starting point

Running ten apps on ten separate App Service plans instead of consolidating onto two or three

Missing egress charges ($0.087/GB after the first 5GB) on a misconfigured backup job

Buying reservations without checking Hybrid Benefit eligibility first, and leaving free savings on the table

The connection itself takes about five minutes: create an account, confirm a few Azure permissions, and paste in a couple of IDs from the Azure Portal. From there, the scope and configuration of your commitments matters as much as whether you buy them at all, a poorly scoped Savings Plan can sit underutilized in one subscription while the rest of your org pays full price.

Companies going through this analysis typically find 30–50% in monthly savings they didn't know were sitting there. On a $150K/month Azure bill, that's $45K–$60K a month, found in minutes rather than months of spreadsheet work.

You can read the full breakdown, including the exact setup steps, here.

Ask anyone running infrastructure across AWS, Azure, and GCP what their least favorite part of the job is, and "reconciling three different cloud bills" comes up fast. Each provider prices things its own way, and that mismatch quietly turns cost management into a much bigger job than it looks like on paper.

Why Three Clouds Never Add Up Cleanly

AWS leans on granular metering plus commitment discounts like Savings Plans and Reserved Instances. Azure sticks to Reserved VM Instances, which are more rigid. GCP uses Committed Use Discounts with a spend-based twist. Two workloads that look identical on paper can behave completely differently once you factor in how each cloud actually bills for them.

That mismatch shows up everywhere: billing files that don't match, tags and labels that don't align, and teams working off different versions of "what we're spending." Add in ownership split across engineering, finance, and ops, and you get a lot of people looking at the same spend and reaching different conclusions.

The Real Reason Multi-Cloud Teams Overspend

It's not a lack of understanding. Most teams know commitments can save 20–70% on compute and databases. The real blocker is risk perception, nobody wants to be the person who over-committed and got stuck paying for capacity nobody used. So teams default to on-demand pricing far more than they need to, and that caution compounds across three clouds instead of one.

Data latency makes it worse. Native cloud recommendations often refresh every few days, sometimes longer. By the time a signal shows up, the window to act on it may already be gone. If you're weighing term length on the AWS side, this breakdown of 1-year vs. 3-year commitments is a useful starting point before you commit to anything long-term.

What Actually Works

A few practices show up consistently in teams that get multi-cloud spend under control:

Normalize billing data into one taxonomy, so EC2, Azure VMs, and GCE all roll up as "compute" instead of three separate stories

Rightsize the instances and VM sizes that make up the bulk of spend usually 20–30 resource types drive 70–80% of the bill

Set commitment coverage targets per cloud based on actual workload stability, not a blanket percentage. Azure's cost structure in particular rewards a more cautious approach than AWS does

Put guardrails in place; required tags, budget alerts, anomaly detection so drift gets caught early instead of at the end of the month

None of this is exotic. It's just consistency applied across three systems that were never built to talk to each other.

Where Automation Actually Helps

This is the part that's genuinely hard to do by hand: forecasting workload behavior across three clouds accurately enough to commit with confidence, every time. Usage.ai's approach is to refresh usage analysis daily instead of relying on native recommendations that can be a week old, then handle the actual purchasing once a team approves it.

The two features worth knowing about if you're evaluating this space: Flex Commitments, which give SP/RI-style discounts without the long lock-in, and cashback protection, which pays out if a commitment ends up underutilized instead of just eating the loss. If you want a quick gut-check on where your own AWS spend stands, the free savings calculator is a fast way to see it.

Multi-cloud isn't going away, and neither is the pricing chaos that comes with it. Normalizing your data and building a cloud-specific commitment strategy won't make the three clouds speak the same language, but it'll stop the mismatch from costing you money every month. You can read the full breakdown in the original guide.

Every GCP bill review starts the same way: rightsize the VMs, kill the idle instances, clean up old storage, set some budget alerts. It's the checklist everyone recommends. It works for a while. Then usage scales, and the bill keeps climbing anyway. You're not doing anything wrong. You've just hit the ceiling of what that checklist was ever built to fix.

Why the Checklist Stops Working

Rightsizing and autoscaling are the first things teams reach for low risk, quick wins. But they only remove excess capacity. Once your environment matures and workloads are already reasonably sized, there's nothing left to trim. These techniques change how much you consume, not how much each unit costs. That gap is easy to miss until spend keeps rising in a clean environment. (This is also the core problem across clouds, not just GCP see this multi-cloud breakdown of how AWS, Azure, and GCP all hit the same wall differently.)

Idle resource cleanup has the same shape. Shutting down forgotten dev environments and orphaned disks feels productive, and it is once. But in most production-heavy GCP setups, the bulk of the bill comes from things that have to run continuously. You can't clean your way out of always-on spend. (The AWS side of this how to actually find idle and underutilized resources follows the same detection logic if you're multi-cloud.)

Storage tiering helps too, but it's usually a smaller, more predictable slice of the bill than compute, and it plateaus fast.

The Part Nobody Wants to Touch: Discounts

This is where most teams stall. Google offers Sustained Use Discounts (automatic, no risk, capped) and Committed Use Discounts (deeper savings, but you're locked into a fixed usage level for 1–3 years).

CUDs are where the real money is and the real risk. Fall short of your committed usage and you're still paying for it. So teams do the rational thing: they under-commit, leaving savings on the table specifically to avoid being wrong.

That's not a technical problem. It's a forecasting and risk-tolerance problem, and the standard best-practices list has basically nothing to say about it.

So What Actually Scales?

Once the easy wins are gone, optimization stops being about configuration and starts being about how pricing decisions get made and revisited. A few things separate teams that keep saving from teams that plateau:

They re-evaluate commitment coverage constantly, not once a quarter

They separate who approves the commitment from who eats the risk if it's wrong otherwise everyone defaults to caution

They optimize for effective blended rate, not just total spend, since that number compounds in a way one-time cleanup never does

This tracks with a related look at why cloud cost management keeps failing even after teams have decent visibility and tooling, the gap isn't insight, it's turning insight into decisions that hold up as usage shifts.

It's part of why tools like Usage.ai exist. Its Flex-Commit Program automates commitment coverage across AWS, Azure, and GCP while offering cashback if a commitment goes underutilized, so teams aren't stuck choosing between "save more" and "sleep at night."

Best-practices checklists get you to baseline efficiency. Baseline efficiency isn't a cost strategy. Teams that keep saving as they scale are the ones treating pricing as an ongoing decision, not a box to check once. Full breakdown, including the risk-management mechanics, here.

The math nobody wants to run

If your company spends $5 million a year on cloud infrastructure, there's a strong chance $1.25–$1.75 million of it is wasted. Not because anyone's being careless, it's structural. Resources default to on-demand pricing, commitments feel risky without good usage data, and quarterly reviews let coverage gaps quietly pile up.

Public cloud spend grew 21.5% in 2025 (Gartner), yet 85% of organizations still call managing cloud spend their top challenge (Flexera 2026). Traditional optimization efforts take six to nine months to roll out by which point a lot of money has already leaked out the side.

Here's the condensed version of what actually moves the needle, broken into three layers.

Layer 1: Visibility (5–10% savings)

You can't fix what you can't see. The first move is identifying which services drive 70–80% of spend usually compute, then databases, then storage or Kubernetes.

A few non-negotiables here:

Tagging compliance above 90%, automated at provisioning time, or it degrades within a quarter

Tracking on-demand exposure specifically, not just total spend if 40–50% of baseline compute runs on-demand, you're overpaying even if utilization looks fine

Unit economics (cost per order, per API call, per inference) to connect spend to business outcomes

Anomaly alerts with an actual owner attached, since unowned alerts are just noise

Layer 2: Waste reduction (10–20% savings)

This is the layer most engineering teams already do, and the one where people mistakenly think they're "fully optimized." It covers idle and zombie resources, rightsizing based on sustained utilization rather than peak traffic, Kubernetes bin-packing efficiency, and scheduling non-prod environments for business hours instead of running them 24/7.

It also covers the stuff that's easy to ignore until it isn't: snapshot retention, storage lifecycle tiering, and cross-region data transfer. A single AI/ML training job moving data between regions without private networking can erase a month of commitment savings in egress charges alone.

Waste reduction has a ceiling, though. Once the obvious stuff is gone, gains shrink fast.

Layer 3: Commitment and coverage (30–50% savings)

This is where the real leverage lives, and it's not about deleting anything it's about how you buy. Every cloud bill has a predictable baseline: steady-state compute, databases, core workloads. Run that baseline on on-demand pricing and you're overpaying by design.

The practical version:

Model baseline usage from 60–90 days of sustained minimums, not monthly averages

Target 70–80% commitment coverage for stable compute full 100% is rarely the right call

Layer commitments across compute, databases, caching, and data warehousing, not just EC2/VMs

Reassess coverage whenever architecture changes (instance family migrations, region expansion, Kubernetes adoption)

Automate the analysis AWS's own Savings Plan recommendations refresh every 72+ hours, and a daily cadence instead can mean $6–12K/day saved on a $5M+ bill that would otherwise sit on-demand

Lock-in hesitation is a big part of why teams under-commit. Traditional Savings Plans and RIs require 1- or 3-year terms, which makes fast-moving teams nervous about committing past 40–50% coverage. Flex-style commitment structures with buyback guarantees exist specifically to remove that hesitation and let coverage move toward the 70–80% range where the real savings actually show up.

The cost of waiting

On a $5M cloud environment with a conservative 15% structural gap, the overpayment compounds fast: roughly $62K by month one, $186K by month three, $375K by month six. That's the cost of treating commitment review as a quarterly task instead of a daily one.

The full breakdown of all 20 practices, the commitment instrument comparisons, and the savings math is over on Usage.ai: 20 Cloud Cost Optimization Best Practices (2026).

Ever notice your user count creep up 20% while your AWS bill jumps 60%? That gap is the whole story, and most teams never measure it because "cloud spend" gets treated as one big number instead of a cost per thing you actually deliver.

The metric hiding inside your bill

That "thing" is cloud unit economics: how much infrastructure it costs to deliver one unit of value, whether that's a user, an API call, a transaction, or a batch job. Say a SaaS company spends $200,000 a month and serves 500,000 active users, that's $0.40 per user. Track that number over time and you find out fast whether your systems are getting leaner as they grow, or quietly getting worse.

Which unit actually matters for you

The right unit depends on what you're building:

SaaS platforms usually track cost per active user

API platforms and dev tools track cost per request

Fintech and e-commerce systems track cost per transaction, since margins are tight enough that inefficiency eats profit fast

Data platforms and ML pipelines track cost per workload or job

AI products increasingly track cost per inference

Most mature teams don't pick just one. They watch a few of these together to get the full efficiency picture.

Why this beats staring at a total spend dashboard

A flat spend number can look "fine" while hiding real problems. Unit economics catches what dashboards miss: bloated microservices, redundant database calls, or compute that's just sitting there unused. It also gives engineering and finance a shared language, instead of arguing about an abstract bill, you're both looking at cost per user or cost per request and asking the same question: is this getting better or worse as we scale?

Doing the math

The formula is simple: total infrastructure cost ÷ total units delivered. An API platform spending $120,000 a month on 80 million requests is paying $0.0015 per request. Scale that to 160 million requests on $150,000, and the cost per request drops to roughly $0.00094 that's the kind of efficiency gain you can actually point to.

Getting there takes four steps: pick your unit, attribute the right slice of cloud spend to the workload that produces it (tagging and billing APIs do the heavy lifting here), pull usage numbers from the same billing period, then divide. Do this consistently and you can track whether architecture changes or pricing shifts are actually helping.

Discover practical strategies to solve cloud cost optimization challenges at scale → Read here 

What actually moves this number

A handful of factors drive unit economics in practice. Architecture matters a lot, chatty microservices and inefficient queries quietly inflate compute and networking costs. So does utilization: instances running at 20–40% CPU while you pay for 100% capacity is one of the most common ways teams bleed money. Scaling patterns play a role too, since workloads with unpredictable spikes often end up leaning on the most expensive pricing model, on-demand. And commitment coverage, how much of your usage runs on discounted Reserved Instances or Savings Plans versus on-demand can swing cost per unit dramatically on its own.

Build a stronger cloud financial strategy by understanding both cost optimization and cost management → Read here

Practical moves that help

If you want the number to move in the right direction: rightsize and bin-pack to push utilization up, benchmark instance families instead of defaulting to whatever you picked two years ago, cut unnecessary service-to-service chatter, tune autoscaling around real signals like queue depth instead of static CPU thresholds, and lean harder into commitment-based pricing for predictable workloads. Then keep measuring, cost per request or cost per user is the only way to confirm an optimization actually worked instead of just feeling like it did.

It's worth separating this from plain cost optimization, which is about cutting waste idle resources, oversized instances, better pricing. Unit economics is the efficiency lens on top of that: not "how much do we spend" but "how much does it cost to deliver one unit of value, and is that number shrinking as we grow." The two work best together. Optimization clears out the waste; unit economics tells you whether you're actually scaling well once the waste is gone.

One thing that consistently moves the needle here is commitment coverage, since on-demand-only environments tend to have the worst unit economics by default. If you're curious how this plays out for your own environment, the full breakdown goes deeper into the calculations and best practices.

You enabled Multi-AZ on your RDS SQL Server instance. The console said yes, your tickets said done, and your infrastructure-as-code looks clean. Then the bill arrived.

This is a breakdown of what RDS SQL Server Multi-AZ actually costs, why it behaves differently from every other RDS engine, and the constraint that quietly eliminates the most common cost-saving trick in the RDS playbook.

What You're Actually Paying For

When you enable Multi-AZ on an RDS SQL Server instance, AWS provisions a synchronous standby replica in a different Availability Zone. Both instances primary and standby bill at the Multi-AZ hourly rate. That rate is listed separately on the AWS pricing page; it's not simply double the Single-AZ rate, but it is a consolidated charge that covers compute, Windows OS, SQL Server license (under License Included), and RDS management for both instances.

One common misconception: the standby doesn't require additional SQL Server licenses. Under the License Included model, AWS's license covers both instances. Under BYOL (Bring Your Own License with Software Assurance), Microsoft's License Mobility rules cover the passive standby under the same agreement. No second license. The Multi-AZ hourly rate is higher because you're running two instances, that's an AWS infrastructure charge, not an extra Microsoft licensing cost.

Cross-AZ data transfer for replication is also free. AWS doesn't charge for the synchronous traffic between primary and standby.

The Constraint Nobody Warns You About

Here's where SQL Server Multi-AZ diverges from every other RDS engine: you cannot stop a Multi-AZ SQL Server instance.

For MySQL, PostgreSQL, MariaDB you can stop the instance on Friday evening and restart Monday morning. Five days of compute charges gone. For SQL Server in Multi-AZ, that option is greyed out in the console. AWS's official documentation is explicit about this limitation.

If you want to pause compute billing, you have to remove Multi-AZ first (by modifying the instance to Single-AZ), then stop it. Re-enabling Multi-AZ later requires going through the same modification process again, and the conversion briefly exposes the database to single-AZ risk.

The practical consequence: any staging, QA, or dev environment running Multi-AZ SQL Server is billing 24/7 at the Multi-AZ rate continuously. The nightly shutdown strategy that works everywhere else doesn't apply here. The correct optimization for non-production environments isn't a scheduling script. It's removing Multi-AZ entirely.

Write I/O Doubles and That Adds Up

Every write operation in a Multi-AZ deployment generates I/O on both the primary and the standby, because replication is synchronous. AWS's documentation is direct about this: write I/O usage doubles.

For workloads using gp3 storage within the 3,000 IOPS baseline, this is often invisible. But for high-write databases running io2 storage or provisioned IOPS above the gp3 baseline, that doubling is a real cost multiplier. Storage itself also effectively doubles both the primary and standby to maintain separate synchronized volumes.

Edition Determines the Replication Technology

RDS automatically selects the Multi-AZ replication method based on your SQL Server edition. Standard Edition uses Database Mirroring (DBM), which provides synchronous replication and automatic failover but limits the standby to a passive role. Enterprise Edition uses Always On Availability Groups (AGs), which additionally supports in-memory optimization. Web Edition since November 2025 supports Multi-AZ via block-level storage replication, which replicates everything at the storage layer including server-level objects and configurations. Express Edition doesn't support Multi-AZ at all.

None of these standbys can serve read queries. Failover-only, across all editions.

Explore RDS Reserved Instance discounts across all supported database engines → Read here 

Reserved Instances Have to Match Exactly

A Multi-AZ RI does not cover a Single-AZ instance, and a Single-AZ RI does not cover a Multi-AZ instance. If you enable Multi-AZ on a production instance that's covered by a Single-AZ RI, that RI stops matching. The instance reverts to On-Demand billing while the RI sits unused.

SQL Server also has no size flexibility on RIs unlike MySQL or PostgreSQL, where an RI can cover smaller instances in the same family. A db.r7i.xlarge SQL Server Standard Edition LI RI covers exactly that configuration and nothing else.

The Non-Production Math

The single highest-ROI action for most SQL Server environments isn't purchasing RIs, it's auditing which Multi-AZ instances are actually in production. Every staging or dev instance running Multi-AZ is paying a premium for availability guarantees that nobody is relying on, and that cannot be reduced by stopping the instance.

Remove Multi-AZ from non-production. Then purchase Multi-AZ RIs for the production fleet.

For a deeper look at exactly what your Multi-AZ setup costs compared to Single-AZ and where the RI math lands for your specific instance class and edition the full breakdown is at usage.ai.

You're running workloads on AWS and a non-trivial chunk of your bill is On-Demand EC2 instances you know will keep running for the next two years. That's the exact problem Reserved Instances were built for.

Here's what RIs actually are, how the pricing works, and where most teams go wrong.

RIs Are a Billing Discount, Not a Server Reservation

This is the most common misconception. When you purchase a Reserved Instance, you are not provisioning a physical server or guaranteeing capacity. You are buying a billing discount that AWS automatically applies whenever your running On-Demand instances match the parameters you committed to instance type, region, operating system, tenancy.

If your account runs a matching instance, the discount kicks in automatically. If no matching instance is running, you still pay the RI fee. That's why utilization monitoring matters so much once you hold a portfolio of RIs.

The savings can be substantial. A 3-year All Upfront Standard RI cuts the hourly rate by up to 72% compared to On-Demand. On an m5.large, that's the difference between $0.096/hr On-Demand and $0.034/hr on a 3-year commitment.

Standard vs Convertible: The Decision That Shapes Your Flexibility

AWS offers two main RI types, and choosing between them is the most important call in your RI strategy.

Standard RIs lock in the instance family, OS, and tenancy for the full term. You can modify the size within the same family or change the Availability Zone, but core attributes are fixed. The upside: the highest available discount up to 72% on 3-year All Upfront. You can also sell unused Standard RIs on the AWS Reserved Instance Marketplace if your needs change.

Convertible RIs trade a portion of that discount (up to 66% on 3-year All Upfront) for genuine flexibility. You can exchange them for a different instance family, OS, region, or tenancy at any point during the term. The exchange rule is one-directional: the new RI must be of equal or greater value. You can upgrade, but you cannot downgrade.

Convertible RIs cannot be sold on the Marketplace, so if flexibility is important, you get it through exchanges rather than exits.

Practical rule of thumb: stable workloads with no planned architectural changes belong on Standard. If you anticipate instance generation upgrades or OS migrations over a 3-year horizon, Convertible gives you room to move without abandoning the commitment.

How Term Length and Payment Options Interact

RI pricing has two dimensions: term length (1-year or 3-year) and payment option (No Upfront, Partial Upfront, All Upfront). All Upfront delivers the lowest effective hourly rate. Whether it makes sense depends on your cost of capital, if RI savings exceed what that cash earns elsewhere, paying upfront wins.

A 1-year term lets you reassess annually and carries lower commitment risk. The discount is smaller, roughly 40% for Standard All Upfront versus 72% on a 3-year term. Given that AWS releases new instance generations every two to three years, many teams pair 3-year terms with Convertible RIs rather than Standard, preserving the ability to swap instance families mid-term while still capturing the deeper discount.

Compare On-Demand, Reserved, and Spot Instances to determine which AWS pricing model fits your workloads → Read here 

RIs Extend Beyond EC2

The RI model applies to Amazon RDS, Amazon ElastiCache, Amazon Redshift, and Amazon OpenSearch same structure: 1-year or 3-year terms, multiple payment options, meaningful discounts over On-Demand.

For a db.m5.large running PostgreSQL, a 3-year All Upfront RI drops the effective hourly rate from $0.192 to $0.083, a 57% reduction. Database workloads tend to be among the most stable in any environment, making them strong RI candidates that are often overlooked in favor of EC2.

Compare AWS Savings Plans and Reserved Instances to choose the right commitment strategy → Read here 

Where Most Teams Go Wrong

The most common mistake is buying RIs to cover average or peak usage rather than the consistent floor. Analyze at least 90 days of historical usage and identify the minimum On-Demand level that almost never dips that floor is your RI candidate. Variable usage above the floor belongs in Savings Plans, On-Demand, or Spot.

Two other patterns that quietly generate waste: letting all RIs expire in the same month (creating a gap and a stressful all-at-once renewal), and skipping cross-account sharing. Within an AWS Organizations setup, RIs purchased in any member account automatically apply their discount across the entire organization by default. Centralizing RI purchasing in a payer account means every business unit benefits without manual allocation.

Learn when each AWS instance purchasing option delivers the best balance of cost and flexibility → Read here 

Savings Plans vs Reserved Instances

AWS introduced Savings Plans in 2019 as a more flexible complement. Instead of committing to a specific instance type, Savings Plans commit to a consistent dollar spend per hour, applying discounts across any EC2 instance regardless of region, family, or OS and covering Fargate and Lambda too.

The two aren't mutually exclusive. Most mature AWS environments use both: Savings Plans for broad baseline coverage, Standard RIs for the highest-savings stable workloads. A common pattern is Compute Savings Plans covering 60–70% of baseline EC2 spend and Standard RIs covering another 20–30%.

If you want to see how the numbers look for your own environment, Usage.ai's AWS Savings Calculator maps out where committed pricing applies and what the projected savings are.

For the full breakdown including the complete pricing tables, RI Marketplace mechanics, cross-account portfolio strategy, and a comparison of every AWS discount option in one place the original guide is here: AWS Reserved Instances: Complete Guide to Pricing, Types & Savings

You're running SQL Database, PostgreSQL, MySQL, and Cosmos DB across Azure. Your cloud bill is growing. And someone on your team just found out Microsoft launched a new discount model for database workloads in March 2026.

Here's what Azure Database Savings Plans actually are, what they save you, and where they silently cost you money.

Evaluate AWS Database Savings Plans to improve database cost efficiency and planning → Read here 

The Basic Idea

Instead of reserving specific database instances (like Reserved Instances require), you commit to a fixed dollar-per-hour spend. Say $10/hour, that's $87,600/year. Azure then applies discounts automatically to eligible database compute usage across SQL Database, SQL Managed Instance, PostgreSQL, MySQL, and Cosmos DB, up to that hourly cap.

The flexibility is real. If you migrate from SQL Database to PostgreSQL mid-year, the discount follows the usage. You're not locked to a specific service, region, or tier.

The risk is equally real. Azure bills you the full $10/hour whether your eligible database compute usage is $10/hour or $6/hour. No refunds. No auto-adjustment.

What Actually Gets Discounted

Not all Azure database costs qualify. Savings Plans apply to compute only, not storage, networking, backup costs, or long-term retention.

Discount ranges by service:

Azure SQL Database Serverless: 30–35%

Azure SQL Managed Instance: 15–30%

Azure Database for PostgreSQL / MySQL: 18–32%

Cosmos DB (provisioned throughput only): 20–35%

SQL Server on Azure VMs: 0% it consumes your commitment at full rates with no discount

That "up to 35%" headline applies specifically to SQL Database Serverless. Most production workloads run on vCore General Purpose or Business Critical tiers, where discounts land between 12–18%.

Serverless Cosmos DB is also excluded only provisioned throughput (RU/s) qualifies.

Compare AWS Savings Plans and Reserved Instances to choose the right commitment strategy → Read here 

The Storage Blind Spot That Burns Teams

This is where most commitment mistakes happen. A typical Azure SQL Database deployment breaks down roughly 60–70% compute and 30–40% storage.

If you're spending $50,000/month total and commit based on total spend ($68/hour), you've overcommitted by roughly 100%. The correct baseline is compute-only: around $34/hour.

The rule: Before sizing any commitment, filter Azure Cost Management to "Compute" meter categories for 60 days. Never commit against your full database invoice.

Savings Plans vs. Reserved Instances

These are two different tools for different situations.

Reserved Instances go deeper up to 72% on a 3-year SQL Managed Instance vs. 35% max on a 1-year Savings Plan. But they're locked to a specific service, region, and tier. One migration and you've potentially wasted a 3-year commitment.

Savings Plans top out at 35% but float across services, regions, and tiers automatically.

The right answer for most organizations is both. Reserve the stable, long-running production core with Reserved Instances. Cover dynamic, multi-service, or evolving workloads with a Savings Plan. Azure applies Reserved Instance discounts first, then the Savings Plan covers remaining eligible usage.

The Utilization Problem Microsoft Doesn't Advertise

Azure Advisor gives you commitment recommendations. But purchasing is entirely manual, monitoring is entirely manual, and there are no automatic alerts when your utilization drops.

If you commit $20/hour in January and complete a database consolidation in April that drops usage to $14/hour, Azure won't tell you. You'll discover the waste at your next quarterly review after paying for months of unused commitment.

There's a trade-in option (Azure applies prorated credit from the original plan toward a new one), but it restarts the 12-month clock. Trade in 6 months into a plan and you've now committed for 18 months total.

The gap between when usage shifts and when your team notices is where the real money goes.

Key Takeaways

Azure Database Savings Plans launched March 18, 2026 with discounts up to 35% across SQL Database, PostgreSQL, MySQL, and Cosmos DB

Commit to a fixed $/hour amount; Azure discounts eligible compute usage up to that cap automatically

Storage, networking, and backup costs are excluded, always size commitments on compute-only spend

Savings Plans beat Reserved Instances on flexibility; Reserved Instances win on discount depth (up to 72%)

No auto-purchase, no utilization alerts, no continuous re-optimization, the operational burden stays with your team

Underutilization means paying full price for discounts you aren't receiving; there are no refunds

Full breakdown of discount rates, purchase steps, multi-service utilization examples, and when to use each commitment type: Azure Database Savings Plans: Pricing, Coverage & Trade-offs

You set up an RDS cross-region read replica, check the bill, and immediately start Googling why your data transfer cost is so high. Spoiler: it probably isn't. You've just been looking at the wrong line item.

A cross-region read replica is a running database instance in a separate AWS region that stays in sync with your primary via continuous replication. It serves distributed read traffic, acts as a fast DR target, and makes zero-downtime regional migrations possible. The cost has two parts — and most teams obsess over the smaller one.

Compute Dominates. Transfer Doesn't.

Every cross-region replica costs whatever that instance class costs in the destination region. A db.r8g.xlarge in EU West (Ireland) is $350/month in compute regardless of replication volume. On top of that, AWS charges $0.02/GB for replication traffic crossing the regional boundary.

Here's what that means in practice:

At 1 GB/day of writes, annual data transfer: $7.20: that's 0.17% of compute

At 10 GB/day: $72/year: still just 1.7% of compute

At 100 GB/day: $720/year: now 17% of compute

At 500 GB/day: $3,600/year: data transfer finally becomes a material cost driver

For the vast majority of production databases writing under 100 GB per day, the transfer charge is a rounding error. Reserved instances on the compute (29-66% savings depending on term) are almost always the higher-ROI optimization.

Three Reasons to Run One

Disaster recovery with low RTO. When your source region goes down, you promote the replica to standalone primary in roughly 5-15 minutes. Replication lag under normal conditions is 1-5 seconds, so your RPO is similarly tight. For a db.r8g.xlarge at 10 GB/day writes, the monthly cost is about $414, your DR insurance premium. Compare that to one hour of production downtime.

Low-latency reads for distributed users. Users in Europe hitting a US East primary see 80-120ms read latency. A replica in EU West brings that to 5-20ms. Worth it if reads are user-facing and latency-sensitive. Not worth it if a caching layer solves the same problem at a fraction of the cost.

Cross-region migration. Sync a replica in the target region, promote it during a short maintenance window, update connection strings. The initial sync transfer is a one-time charge at $0.02/GB. After migration, terminate the old primary.

Engine Support Isn't Universal

MySQL, MariaDB, and PostgreSQL all support cross-region read replicas. Oracle does with some edition constraints. The one that surprises teams at architecture review: SQL Server Standard and Enterprise do not support cross-region replicas at all. Only SQL Server Express supports it, capped at 10 GB. If you're planning cross-region DR for an RDS SQL Server SE or EE workload, you need a different approach entirely.

Aurora MySQL also works differently, using Aurora Global Database, not standard RDS replica mechanics.

Understand how AWS Database Savings Plans work and what DB teams should evaluate before committing → Read here 

Reserved Instances Apply Here Too

Cross-region replicas are regular RDS instances in the destination region, fully eligible for the same RI discounts as any other instance. The reservation must be purchased in the destination region, matching engine, instance family, and Single-AZ deployment type.

Teams routinely reserve their primaries and forget the replicas, leaving full on-demand rates on infrastructure running for years as permanent DR. A 3-year All Upfront RI on a db.r8g.xlarge MySQL replica saves roughly $192/month — $6,912 over the term.

Full RI strategy for your RDS fleet: Usage.ai RDS Reserved Instances Guide

After Promotion: Don't Forget the Old Primary

Promotion takes a few minutes. Replication stops, the transfer charge stops, and you have a new standalone primary. What doesn't stop: your original primary in the source region keeps running and billing until you explicitly terminate it. Once the original region recovers, you either re-establish replication with roles reversed or shut down the old instance. Leaving both running at on-demand rates is a quiet budget leak that persists for months.

What's the cross-region replica cost mistake you've seen most in the wild? The "forgot to terminate the old primary after failover" story seems to come up constantly.

Your DynamoDB Table Is Quietly Charging You for Data You No Longer Need

Every session token that expired last Tuesday. Every audit log entry from six months ago. Every cache row that outlived its usefulness by weeks. If you have not enabled DynamoDB TTL, all of that data is still sitting in your table and you are paying $0.25 per GB per month for the privilege.

DynamoDB Time to Live (TTL) is a native feature that automatically deletes items once their expiration timestamp passes. The deletion consumes zero write capacity units and costs nothing. AWS uses internal backend capacity for TTL deletions, entirely separate from your provisioned or on-demand throughput.

The Storage Savings Add Up Fast

Every GB of expired data that TTL removes saves you $0.25/month on Standard-class storage, or $0.10/month on Standard-IA. That sounds modest until you factor in Point-In-Time Recovery (PITR).

PITR charges $0.20 per GB-month based on your table's current size. When TTL shrinks your table, your PITR bill shrinks with it. Combined, the effective saving is $0.45 per GB-month for tables with PITR enabled, nearly double the headline storage figure.

At 500 GB of expired data removed per month, that works out to $2,700/year. From a feature that takes minutes to configure once and requires zero maintenance afterward.

The Hidden Cost of Doing It Manually

If you skip TTL and delete items yourself via BatchWriteItem, you pay 1 WRU per KB per item. For 10 million expired 1 KB items per month, that is $12.50/month in write costs on on-demand capacity, on top of the engineering time to build and maintain the cleanup script.

TTL eliminates both costs: the write cost and the operational overhead.

The 48-Hour Window: What to Watch

TTL does not delete items the instant they expire. The background process typically runs within 48 hours of the expiration timestamp. During that window, expired items still appear in Query and Scan results, and still count toward your table's storage size.

Two practical fixes:

Add a filter expression to your reads: exclude items where your TTL attribute is less than or equal to the current Unix epoch timestamp. This keeps stale data out of your results.

If you are using Lambda with DynamoDB Streams, add an event source mapping filter to exclude TTL DELETE events (filter on eventName: INSERT, MODIFY). Otherwise, every expired item triggers a Lambda invocation you probably do not need.

Understand what’s included in the DynamoDB Free Tier and how to maximize always-free usage → Read here 

Where TTL Delivers the Most Impact

Session stores are the obvious win. A session table with 1 million daily active users and 1-hour TTLs can stay under 4 GB instead of growing indefinitely. Without TTL, it compounds every month.

Audit log tables are the less obvious one. A logging table adding 15 GB/month of 1 KB events with a 30-day retention requirement stabilizes at around 15–16 GB with TTL enabled. Without it, after six months the table holds 90 GB costing $22.50/month versus $4.00/month.

One-time token tables password resets, email verification codes also benefit. These typically accumulate forever without TTL, even though the tokens themselves expire in minutes.

Explore the pricing model behind Contributor Insights and its impact on DynamoDB costs → Read here 

One Pitfall Worth Calling Out

The single most common TTL implementation error: writing the expiration timestamp in milliseconds instead of seconds. DynamoDB requires a Unix epoch in seconds. If your application writes 1714000000000 instead of 1714000000, DynamoDB reads that value as a timestamp thousands of years in the future and never deletes the item. Your table grows indefinitely.

Double-check your timestamp units before enabling TTL on a production table.

For the full breakdown including the TTL + Standard-IA combined savings calculation, the Streams archival pattern for compliance use cases, and the complete implementation checklist the original article is here: DynamoDB TTL: Free Automatic Item Deletion to Reduce Storage Cost

Your RDS Bill Has Five Line Items. Most Teams Only Watch One.

You open AWS Cost Explorer, find the RDS section, and see a number. You assume that's the instance cost plus storage. For a lot of teams, that's where the analysis stops and that's where the overpaying quietly begins.

RDS actually bills across five separate dimensions: instance compute, storage, I/O above the gp3 baseline, backup storage beyond the free tier, and Extended Support if you're running an end-of-life engine version. Miss any one of these and your estimate is wrong before you've even finished building it.

Explore engine-by-engine RI pricing to optimize long-term database savings → Read here 

Engine Choice Is the Biggest Variable

MySQL is the cost-efficient baseline. No licensing premium, full gp3 support, and access to every RDS feature. MySQL 8.0 is the current LTS version, run it and you pay zero Extended Support charges.

PostgreSQL runs at a very similar rate to MySQL for most instance classes. The r8g and m7g families are often priced identically between the two engines. A db.r8g.xlarge PostgreSQL Single-AZ costs roughly $0.480/hr on-demand. The capabilities are broader, better JSON support, richer extension ecosystem but the bill is almost the same as MySQL at equivalent compute.

SQL Server is a different category entirely. RDS for SQL Server is License Included only there's no bring-your-own-license option. AWS bundles the Microsoft license into the hourly rate, and you pay it regardless. SQL Server Standard Edition on a db.r8g.xlarge runs approximately $1.224/hr on-demand, compared to around $0.478/hr for MySQL at the same size. That's a license premium of roughly $550/month on a single instance and it scales linearly with instance size.

SQL Server Enterprise costs 2 to 3 times Standard, and is only worth it if your workload specifically requires Always On availability groups, columnstore indexes, or advanced analytics. Most production workloads run Standard.

Learn how to maximize RDS Reserved Instance savings with engine-specific commitments → Read here 

The Formula Most Guides Skip

The correct monthly cost calculation for any RDS instance looks like this:

Compute: your hourly rate × 730 hours. Multi-AZ doubles this because AWS provisions and bills a second instance as the standby.

Storage: GB provisioned × $0.115/month for gp3. This applies to every instance primary, standby, and each read replica separately.

Backup: the first 100% of your provisioned storage size in backup is free. Everything beyond that costs roughly $0.095/GB-month.

Extended Support (if applicable): vCPUs × $0.200/hr × 730 hours on top of your instance rate, not discounted by Reserved Instances.

For a PostgreSQL db.r8g.xlarge Multi-AZ with 500 GB gp3 and two read replicas, the on-demand compute alone runs about $1,574/month before you apply any RI discounts. With 1-year No Upfront Reserved Instances on all three instances, that drops to approximately $1,168/month, an annual saving of around $4,870.

Extended Support: The Multiplier Nobody Budgets For

If you're still running MySQL 5.7 or PostgreSQL 11, your bill changed on March 1, 2026. Both versions entered Year 3 Extended Support, which carries a $0.200/vCPU-hr surcharge — double the Year 1–2 rate.

For a 4-vCPU instance, that's $584/month in Extended Support charges added on top of the standard instance rate. Reserved Instances do not offset this. A team that committed to a 3-year RI on a MySQL 5.7 instance is paying RI-discounted compute plus full-rate Extended Support, and they can't exit the reservation.

The fix is straightforward: upgrade to MySQL 8.0 or PostgreSQL 16 before the Extended Support charges compound further.

Compare RDS and Aurora TCO to see when Aurora’s storage model becomes more cost-effective → Read here 

RI Discounts by Engine

Reserved Instances cut the compute portion of your bill by 29% on a 1-year No Upfront term, up to around 51% on a 3-year All Upfront for MySQL and PostgreSQL. SQL Server License Included saves 25% on a 1-year term and around 41% on 3-year slightly less, because the base rate already reflects licensing.

One constraint worth knowing: No Upfront payment is only available for 1-year terms. Three-year commitments require Partial Upfront or All Upfront.

If you want a faster read on where your RDS bill stands against what it should be, Usage.ai's savings calculator runs the full cost stack compute, storage, Extended Support flags, and RI coverage gaps in under a minute.

FULL BREAKDOWN AT: USAGE.AI

There's a line item on AWS bills that a lot of teams add without thinking twice: RDS Proxy. It shows up quietly at $21.90/month here, $43.80/month there and unless someone actively audits it, it just stays.

The question worth asking is whether it's actually earning its keep.

What RDS Proxy Does (and What It Costs)

RDS Proxy sits between your application and your RDS or Aurora database. Instead of your app opening a fresh connection for every request, the proxy maintains a pool of persistent connections to the database and reuses them. Fewer connection open/close cycles, lower database CPU overhead, faster failover.

The cost: $0.015 per vCPU-hour of the underlying database instance, charged on top of what the instance itself costs. There's a minimum of 2 vCPUs per proxy, so the floor is $21.90/month regardless of how small the database is.

A 4-vCPU instance adds $43.80/month in proxy cost. An 8-vCPU instance adds $87.60/month. The proxy scales directly with your instance size which matters when you're thinking about whether to add it or keep it.

Where It's Genuinely Essential

Lambda-heavy serverless architectures. This is the scenario where RDS Proxy stops being optional. Lambda can scale to thousands of concurrent executions simultaneously. Without a proxy, each execution tries to open its own database connection. Most RDS instances hit their connection limit (500–2,000 depending on RAM) very quickly under Lambda-scale traffic, causing connection failures and application errors.

RDS Proxy solves this cleanly: all Lambda executions connect to the proxy, which funnels them into a much smaller pool of database connections. A function scaling to 10,000 concurrent executions might only present 50–200 connections to the actual database. At $21.90–$43.80/month for a small-to-medium instance, the cost of one production outage caused by connection exhaustion almost always exceeds the annual proxy bill.

Applications with short-lived connections. Older PHP apps, certain Ruby on Rails configurations, serverless microservices workloads that open and close a database connection per request rather than maintaining a persistent pool. Without the proxy, hundreds of connection cycles per second consume significant database resources. The proxy absorbs that churn.

Faster failover. RDS Proxy reduces Multi-AZ failover time by up to 66% for RDS and Aurora. For SQL Server Multi-AZ, the improvement reaches up to 83%. Standard failover takes 60–120 seconds. With the proxy preserving application-layer connections and routing transparently to the new primary, the visible outage window drops to under 20 seconds for RDS, under 10 seconds for Aurora. For teams with SLAs tied to database availability, that improvement alone can justify the cost.

Compliance-sensitive credential management. RDS Proxy integrates natively with AWS Secrets Manager and IAM authentication. Credentials never appear in application code. Secret rotation happens transparently without application restarts. For environments where SOC 2, HIPAA, or PCI-DSS require audited credential handling, the proxy often eliminates a significant amount of custom implementation work.

Explore RDS Serverless architecture, pricing, and deployment considerations in 2026 → Read here 

Where It Doesn't Earn Back Its Cost

Traditional apps with existing connection pools. Java Spring with HikariCP, Django with connection pooling middleware, .NET connection pooling, these already maintain a stable, bounded set of database connections. A 5-server app with 20 connections per server maintains 100 connections regardless of traffic. The proxy would multiplex those 100 connections into… roughly 100 connections. No pooling benefit, just an extra network hop on every query and an additional monthly charge.

Oracle users. RDS Proxy doesn't support Oracle. Full stop, it's not an option for that workload.

SQL Server 2022. Also unsupported. SQL Server 2014 through 2019 are covered; 2022 is not.

The pin mode trap. RDS Proxy has two operating modes: multiplexing (the useful pooling mode) and pin mode (a one-to-one fallback that provides no pooling benefit). Pin mode activates when the application uses SET statements that change session state, creates temporary tables, uses user-defined locks, or leaves cursors open. An application that spends most of its time in pin mode is paying for a proxy that isn't actually pooling. The CloudWatch metric to check is Proxied SQL statements that caused pinning, if it's consistently high relative to total connections, the proxy isn't delivering the benefit you're paying for.

The Self-Managed Alternative

For PostgreSQL specifically, PgBouncer is the open-source comparison. A proper high-availability PgBouncer setup two small EC2 instances plus a load balancer runs roughly $47/month regardless of database size. At a 2-vCPU instance, the economics are close and RDS Proxy's managed nature makes it competitive. At an 8-vCPU instance, the proxy costs $87.60/month versus $47/month for PgBouncer HA.

The tradeoff is operational: PgBouncer requires setup (around 8 hours), ongoing maintenance (1–2 hours/month), and incident response if it fails. At $100/hr in engineering cost, 2 hours/month of PgBouncer maintenance runs $200/month more than the proxy saving at larger instance sizes. Teams with dedicated infrastructure capacity across many databases can compound PgBouncer's cost advantage. Teams without that capacity often find the proxy pays for itself in avoided operational burden.

Understand how Amazon Aurora DSQL pricing works and what drives overall database costs → Read here 

One Optimization Worth Noting

Because RDS Proxy pricing is a direct function of your instance's vCPU count, right-sizing the database reduces both costs simultaneously. A db.r8g.2xlarge running at 30% average CPU is a strong candidate for downsizing to a db.r8g.xlarge. That move cuts the instance cost and drops the proxy from $87.60/month to $43.80/month as a side effect.

Right-size the database first, then decide on the proxy. Adding a proxy to an oversized instance compounds the waste.

Learn how to choose the right RDS Reserved Instance term and payment option → Read here 

The full breakdown complete cost scenarios, detailed break-even analysis across instance sizes, and a step-by-step decision framework is in the original guide: RDS Proxy Pricing: Connection Pooling Cost vs Performance Benefit

If you spun up an ElastiCache Serverless cache, skipped the engine selection screen, and landed on Redis OSS you're paying more than you need to. Not a little more. A lot more. And the fix takes about two minutes.

Here's what's actually happening with ElastiCache Serverless pricing, and what to do about it.

How Serverless Billing Actually Works

ElastiCache Serverless charges on two dimensions: ECPUs consumed and GB-hours of data stored. That's it no node types, no cluster sizing, no reserved capacity planning.

An ECPU (ElastiCache Processing Unit) represents one kilobyte of data transferred per cache operation. A GET returning 3.2 KB costs 3.2 ECPUs. A SET writing 0.5 KB costs 0.5 ECPUs. Simple GET/SET workloads scale linearly with data transferred. Complex operations, ZADD on large sorted sets, LRANGE returning big lists, Lua scripts consume proportionally more ECPUs on top of the data transfer base.

The ECPU rate is approximately $0.0034 per 1,000 ECPUs. Storage runs approximately $0.125 per GB-hour. Those numbers look small. They add up fast at scale, and the minimum storage floors are where most teams get surprised.

The Engine Choice That Changes Everything

Here's the thing most teams miss at cache creation: the engine you pick doesn't just affect features, it determines your floor cost.

Redis OSS Serverless has a 1 GB minimum metered storage. Even if your cache holds barely anything, you're billed for 1 GB continuously. At $0.125/GB-hr, that's roughly $91/month in storage alone before a single request fires.

Valkey Serverless has a 100 MB minimum. Same math, 15x smaller floor: about $6/month.

Valkey is also 33% cheaper on ECPU and storage rates across the board. It's an open-source, Redis-compatible key-value store backed by the Linux Foundation; same commands, same protocols, same client libraries. Drop-in replacement. AWS launched it for ElastiCache in October 2024 and recommends it for all new deployments.

The floor difference alone is striking at team scale. Ten dev and staging caches at minimum storage: Redis OSS = $910/month, Valkey = $60/month. That's an $850/month difference with zero application changes just engine selection.

Evaluate node-based ElastiCache discounts before committing to reserved capacity → Read here 

When Serverless Makes Sense (and When It Doesn't)

The ECPU model is genuinely good for certain workloads and genuinely expensive for others.

Serverless is the right call when:

Traffic is bursty or unpredictable, with significant peak-to-average variance

You're running dev, staging, or test caches that sit idle most of the time

You're launching a new production cache with unknown traffic patterns and want to skip capacity planning

Node-based clusters beat Serverless when:

Throughput is high and consistent, you pay per ECPU per request rather than a flat hourly node rate, and the math flips against Serverless at sustained high volume

You need Global Datastore for multi-region replication (not available with Serverless)

A useful mental model: if your cache sees a 10x or higher peak-to-average ratio, Serverless saves you money by not forcing you to provision for peak 24/7. If your cache runs at near-constant high throughput, a provisioned node with a Reserved Node discount will be cheaper.

Identify unnecessary cloud spend in under 60 seconds. Try the Calculator → 

Discounts for Serverless: No Reserved Nodes, But There's a Path

Reserved Nodes don't apply to Serverless, that's a node-based cluster feature only. The discount mechanism for Serverless is Database Savings Plans, which AWS lists as one of three pricing options for ElastiCache. A 1-year DSP commitment delivers up to 30% savings on Serverless usage.

For a $500/month Serverless cache, that's $150/month back — $1,800/year on a no-upfront 1-year commitment.

The strategy: pull 30–60 days of CloudWatch ECPU and storage data, identify the consistent floor of your hourly Serverless spend, and commit that amount via DSP. You keep full flexibility above the floor and lock in the discount on the predictable portion.

See how AWS Database Savings Plans help reduce database infrastructure costs → Read here 

The Fastest Win Available Right Now

If you're running Redis OSS Serverless today and haven't migrated to Valkey: create a new Valkey Serverless cache, point your application at the new endpoint, delete the old cache. Cost drops 33% on ECPUs and storage immediately, and the minimum floor drops from $91/month to $6/month.

For near-empty or lightly loaded caches, dev environments, staging, anything that isn't a high-traffic production cache this is the highest-ROI optimization available with the least effort.

For the full breakdown including worked cost examples and the Serverless vs node-based decision framework, the complete guide is at Usage.ai.

New York, USA — June 16, 2026 — Usage.ai, a cloud cost optimization platform specializing in automated AWS commitment management, has announced full automation support for AWS Database Savings Plans (DSP) across all 10 AWS managed database services currently eligible under the program. The announcement follows AWS's March 2026 expansion of DSP eligibility to include OpenSearch Service and Neptune Analytics.

Usage.ai customers can now automate the complete DSP lifecycle, spend analysis, commitment sizing, purchase, utilization monitoring, and cashback on underutilized commitments for every service covered under AWS Database Savings Plans.

What the Announcement Covers

Usage.ai's Database Savings Plans automation is now live across:

Amazon RDS: Gen 7+ provisioned instances (db.r7, db.r8g, db.m7, db.m7g families)

Amazon Aurora: Gen 7+ provisioned instances, Aurora Serverless v2, and Aurora DSQL

Amazon DynamoDB: on-demand throughput (up to 18% savings) and provisioned capacity (up to 12% savings)

Amazon ElastiCache: Valkey engine only, covering Gen 7+ provisioned clusters and ElastiCache Serverless for Valkey

Amazon DocumentDB: Gen 7+ provisioned instances and DocumentDB Serverless

Amazon Neptune: Gen 7+ provisioned instances, Neptune Serverless, and Neptune Analytics (added by AWS on March 5, 2026)

Amazon Keyspaces: on-demand throughput (up to 18% savings) and provisioned throughput (up to 12% savings); DSP is the only commitment discount path for this service, as no Reserved Instances are available

Amazon Timestream: Timestream for InfluxDB instances

Amazon OpenSearch Service: Serverless and Gen 7+ provisioned instances (added by AWS on March 5, 2026)

AWS Database Migration Service (DMS): Gen 7+ replication instances and DMS Serverless

How Usage.ai Handles the Full DSP Lifecycle

Purchasing a Database Savings Plan at the right commitment level requires knowing the consistent floor of eligible hourly spend, the amount eligible database costs never drop below across all hours. Over-committing results in paying for capacity that goes unused; under-committing leaves savings unrealized. Managing this across 10 services with different eligibility rules is operationally expensive to do manually.

Usage.ai automates the process in five stages:

Analysis: The platform pulls Cost and Usage Report (CUR) data and identifies DSP-eligible spend across all 10 services, separating it from RI-eligible spend to avoid double-counting.

Commitment sizing: Usage.ai calculates the consistent hourly floor spend on DSP-eligible usage across the prior 60 days to determine the correct commitment level.

Purchase: The DSP commitment is purchased through billing-layer access and activates immediately.

Monitoring: DSP utilization is monitored on a 24-hour refresh cycle, compared to AWS Cost Explorer's 72-hour-plus refresh window.

Cashback on underutilization: If a DSP commitment becomes underutilized due to decommissioning, migration, or downsizing, Usage.ai provides cashback on the unused committed amount. This applies to DSP commitments on the same terms as Savings Plans and Reserved Instances across the rest of the platform.

Usage.ai's fee structure is a percentage of realized savings only.

Recommended Order of Operations

Usage.ai advises teams to follow a specific sequence before purchasing DSP commitments:

Right-size instances based on actual CPU and memory utilization.

Migrate to current-generation instances: Gen 7+ for RDS and Aurora; Valkey engine for ElastiCache, since older-generation instances remain ineligible for DSP and continue to require Reserved Instances.

Evaluate storage configuration, particularly for Aurora and DocumentDB where the choice between Standard and I/O-Optimized storage carries meaningfully different cost implications depending on actual I/O consumption.

Purchase DSP commitments on the confirmed, right-sized, current-generation spend floor.

Teams that purchase DSP before completing these steps lock in commitments on oversized or ineligible infrastructure, discounting a spend level higher than necessary.

Key Facts About AWS Database Savings Plans

Term: 1-year only (no 3-year option)

Payment: No Upfront only (no All Upfront or Partial Upfront options, unlike Compute Savings Plans)

Maximum savings: Up to 35% for serverless workloads (Aurora Serverless v2, Neptune Serverless, DocumentDB Serverless, ElastiCache for Valkey Serverless); up to 20% for most provisioned workloads; up to 18% for on-demand throughput workloads (DynamoDB, Keyspaces); up to 12% for DynamoDB and Keyspaces provisioned capacity

Application order: DSP applies after Reserved Instances in the discount waterfall and cannot be combined with RIs or reserved capacity on the same workload in the same billing hour

DynamoDB note: DSP cannot be combined with DynamoDB reserved capacity on the same table

ElastiCache note: Only the Valkey engine is covered; standard Redis OSS and Memcached continue to require Reserved Nodes

Leadership Perspective

Kaveh Khorram, CEO of Usage.ai, framed the broader context: "FinOps started with EC2. It matured into Savings Plans and Reserved Instances across compute. The next phase is database and it's more complex because the eligibility rules, the instance families, and the discount waterfall all behave differently across 10 services. The teams that get this right balance engineering judgment with financial discipline, and that balance is where cloud economics are won or lost."

Additional Resources

As AWS continues to expand Database Savings Plans eligibility, teams managing database workloads at scale will need to account for service-specific eligibility rules, instance generation requirements, and the correct sequencing of commitments alongside existing Reserved Instances. Full coverage details, discount rates, and service-specific eligibility information are available in the AWS Database Savings Plans: Complete Guide for 2026. Teams can review their DSP-eligible spend at usage.ai/savings-calculator. The complete announcement is at usage.ai/news.

About Usage.ai

Your UK Cloud Bill Is Expensive for Reasons Most Tools Don't Address

Cloud spend in the UK isn't just costly, it's costly in ways other markets don't face. AWS pricing in eu-west-2 (London) runs 10–15% above equivalent US-East-1 rates. UK GDPR creates data residency preferences that keep workloads in UK regions. FCA-regulated firms have third-party oversight documentation requirements that can delay any new tool deployment by weeks.

Most cloud cost tools were built for US buyers. The ten below are assessed specifically against what matters in UK environments: UK GDPR compliance, FCA PS21/3 obligations, and the commitment coverage gap that leaves significant savings uncaptured.

The Coverage Gap Worth Knowing About

The FinOps Foundation's 2025 State of FinOps report puts UK enterprise commitment coverage at 50–60% on eligible workloads below the 65–75% benchmark for leading FinOps organizations. For a UK enterprise on a £2M/year AWS eu-west-2 bill, that gap represents £100,000–200,000/year in on-demand charges paid for workloads that could be running on Reserved Instances or Savings Plans.

The 10 Tools, Ranked

1. Usage.ai: The only tri-cloud platform with autonomous commitment purchasing across AWS eu-west-2, Azure UK South, and GCP europe-west2 simultaneously. Real cashback guarantee (not vendor credits). Billing-layer-only access means it never touches personal data, satisfying UK GDPR under the Data Protection Act 2018 and keeping FCA PS21/3 third-party documentation minimal. Best for UK enterprises at £500K+ across multiple clouds.

2. ProsperOps (now Flexera): Strong autonomous AWS commitment engine, but AWS-only and underutilization protection is credits rather than cash. Pricing has grown more complex since the January 2026 Flexera acquisition.

3. Zesty: Dynamically adjusts Reserved Instance positions in real time, useful for UK retailers and media companies with seasonal demand spikes. AWS-only; no Azure UK South coverage.

4. Harness Cloud Cost Management: Attributes spend to CI/CD deployments across all three clouds. Surfaces commitment recommendations but doesn't execute them, every purchase is still manual.

5. CloudHealth by Broadcom: Large UK enterprise installed base for multi-cloud governance. Commitment purchasing is fully manual, and Broadcom's acquisition has slowed development and pushed up licensing costs.

6. AWS Cost Explorer: Free baseline for eu-west-2. Recommendations refresh on a 72-hour cycle, all purchases are manual, AWS-only. Correct starting point for sub-£500K/year AWS spend.

7. Azure Cost Management + Billing: Free native tool for Azure UK South and UK West with solid existing Microsoft regulatory documentation. Azure-only, manual Reservation purchases throughout.

8. Flexera One: Broad technology spend management covering cloud, SAM, and ITAM. Relevant for large UK enterprises managing Microsoft EA licensing. Contracts start at £35,000+; implementation takes 3–6 months.

9. CloudZero: Best-in-class unit economics: cost per customer, per feature, per deployment across all three clouds. No autonomous commitment purchasing. Best paired with a tool that handles that side of things.

10. Apptio Cloudability (IBM): Deep executive reporting widely used in UK financial services for PRA/FCA audit documentation. No autonomous commitment execution; best where governance reporting is the primary goal.

The Compliance Point Most Reviews Skip

Two things make UK tool selection different from the US equivalent.

UK GDPR: Any tool accessing running EC2 instances or Azure VMs in a UK environment creates a personal data processing obligation, triggering a Data Processing Agreement and potentially a Data Transfer Impact Assessment adding 4–8 weeks of legal review. Billing-layer-only tools (AWS CUR, Azure Cost Management APIs, GCP Billing Export) don't touch personal data, so none of that applies.

FCA PS21/3 (fully in force since 31 March 2025): Tools with infrastructure access may need to be mapped into your firm's operational resilience documentation under important business services. Billing-layer-only tools sit outside that scope.

Worth asking any vendor to confirm in writing: billing-layer-only access, no personal data processed, no DPIA required, no important business service mapping needed under PS21/3.

For the full breakdown with specific pricing figures and FCA PS21/3 guidance, the complete post is at Usage.ai — Best Cloud Cost Optimization Tools in the UK (2026).

Your AWS bill might have a quiet, avoidable tax buried in it and it's called the T2 instance family.

T2 instances aren't discontinued. AWS still sells them. But T3 costs approximately 10% less at every equivalent size, runs on the modern AWS Nitro hypervisor, delivers better network throughput, and holds a much larger CPU credit bank. There's no technical or financial reason to choose T2 for new workloads, and there may be a good reason to migrate what you already have.

The Actual Cost Difference

The on-demand gap is consistent across every size: t2.micro runs $8.47/month versus $7.59/month for t3.micro. A t2.large is $67.74/month compared to $60.74/month for t3.large. At t2.2xlarge it's $270.98/month versus $242.94/month for t3.2xlarge. The 10% reduction holds from the smallest size to the largest.

Beyond price, T3 runs on the AWS Nitro hypervisor (T2 uses the older Xen hypervisor), supports up to 5 Gbps network bandwidth (versus T2's 1 Gbps), and gives your instance a CPU credit bank that holds 7 days of earned credits, compared to just 24 hours on T2.

The T3 Billing Trap You Need to Know About

T3 runs in Unlimited CPU credit mode by default. That's great for performance, the instance never throttles when you burst above baseline. But if your workload consistently runs above baseline CPU, you get charged $0.05 per vCPU-hour of excess credit consumed.

Here's what that looks like in practice: a t3.medium has a 20% CPU baseline. If your web server regularly runs at 60% CPU, the excess is 0.8 vCPU-hours per hour. At $0.05/vCPU-hr, that's $29.20/month in CPU credit charges, on top of the $30.37 on-demand rate. Your actual cost becomes nearly double the listed price.

The fix: if your workload sustains high CPU continuously, either switch to a non-burstable instance family (m-series, c-series) or configure T3 to Standard mode to avoid the overage charges. After migrating, watch the CPUSurplusCreditsCharged CloudWatch metric for the first 30 days.

There's Also a T3a — 10% Cheaper Than T3

AWS offers a T3a variant powered by AMD EPYC 7000 processors. T3a costs approximately 10% less than T3, making it roughly 20% cheaper than T2 at equivalent sizes.

The trade-offs are minor for most workloads: no AVX-512 support, AMD processor instead of Intel (matters if your software is licensed per Intel processor). For general web serving, application backends, and development environments, T3a is the cheapest burstable option available. On a fleet of 50 t3.medium-equivalent instances, choosing T3a over T3 saves approximately $152/month - $1,824/year for the same compute capacity.

When to Actually Choose T2

Honestly, the list is short.

You need Free Tier eligibility and your AWS account was created before T3 was added to Free Tier

Your application has a hard dependency on the Xen hypervisor (extremely rare)

You specifically want Standard CPU credit mode for cost predictability and prefer not to configure it manually on T3

In every other situation, T3 or T3a is the better choice.

The Migration Takes Under 5 Minutes

Stop the instance. Change the instance type via the EC2 console (Actions → Instance Settings → Change Instance Type) or via CLI. Start the instance. That's it, no application changes required. For larger fleets, AWS Systems Manager can automate the change across multiple instances at once.

Once you've migrated to T3, layering a Compute Savings Plan compounds the savings further, the Savings Plan discount applies to the already-cheaper T3 base rate. Platforms like Usage.ai surface this upgrade opportunity before recommending any commitment purchase, specifically to avoid locking in a Savings Plan on the wrong (more expensive) base rate.

The full breakdown; pricing by size, the CPU credit math, and when T3a beats T3 is at usage.ai/blogs/ec2-t2-vs-t3.