Cutting RDS Costs: A Practical Playbook for DBAs

The three levers that move an RDS bill the most are rightsizing compute to actual demand, converting oversized gp2 volumes to gp3, and covering steady-state usage with Reserved Instances or Database Savings Plans. Together, these three fixes typically account for the bulk of the savings teams find in a real audit, before anyone touches application code. Third-party audits regularly turn up 25% to 40% run-rate reductions without a single line of code changing.

Here’s what to do in the next 72 hours, in order:

Pull 14 days of CloudWatch CPU, memory, and connection metrics for every RDS instance and look at p95, not the average.
Flag every gp2 volume over 100 GB. That’s almost always cheaper on gp3.
Identify non-production instances running 24/7 and stop them outside business hours.
Run AWS Compute Optimizer and Trusted Advisor and export both reports. Don’t act yet, just collect.
Calculate your steady-state dollars-per-hour baseline across the fleet. You’ll need this number before you buy any reservation.

Pro Tip: Never buy a Reserved Instance or Database Savings Plan before rightsizing. Locking in a three-year commitment on an oversized instance just makes the waste permanent instead of monthly.

Key Takeaways

RDS cost optimization works best when you rightsize before you commit, convert oversized gp2 storage to gp3, and layer reservations only on top of a cleaned-up baseline.

Point	Details
Measure before acting	Pull 14 days of CloudWatch and Performance Insights data and analyze p95/p99, not averages.
Rightsize compute first	Downsize instances with sustained CPU under 35% at p95, validating memory and connections too.
Convert storage to gp3	Move gp2 volumes over 100 GB to gp3 to decouple IOPS from volume size.
Layer commitments last	Cover 65–80% of your rightsized baseline with Reserved Instances or Database Savings Plans.
Automate scheduling and governance	Use Instance Scheduler for non-prod and enforce tagging so waste doesn’t quietly regrow.
Escalate when complexity is high	A free RDS cost audit from IT-Magic fits mixed-engine or large estates that need an external baseline.

How RDS Billing Breaks Down And What Drives Your Bill
What Metrics And Tools Reveal Hidden RDS Waste?
How Do You Rightsize RDS Instances Safely?
Reserved Instances Vs Database Savings Plans: Which Saves More?
When Does Aurora Serverless Or I/O-Optimized Save Money?
Which Storage Type Cuts RDS Costs Fastest?
How Backup Retention Affects Your RDS Storage Bill
Cutting Costs Through Connection Pooling And Query Tuning
How Scheduling Non-Production Instances Cuts Costs
What Governance Policies Keep RDS Costs Low Long-Term?
When Should You Bring In A Cost Optimization Partner?
A Priority Sequence For DBAs And FinOps Teams
Get A Free Audit Of Your RDS Spend
Key AWS Resources For RDS Cost Optimization
Sources
FAQ

How RDS Billing Breaks Down And What Drives Your Bill

Amazon RDS doesn’t bill you one number. It bills you seven or eight, and they interact in ways that trip up even experienced teams. Instance-hours (compute) usually get the most attention because they’re the biggest line item on a receipt, but storage, IOPS, backups, data transfer, and licensing premiums often hide more waste per dollar spent fixing them.

RDS pricing is built from distinct meters that don’t move independently. Change your storage type and you change your IOPS bill. Add a read replica and you add both compute and cross-AZ transfer charges. Switch from License Included SQL Server to a smaller instance class and you cut compute and licensing at once, since SQL Server licensing scales with vCPU count.

Cost Component	What Drives It	Common Waste Pattern
Instance-hours (compute)	Instance class, family, hours running	Oversized instances running 24/7 for spiky workloads
Storage (GB-month)	Allocated storage, storage type	Over-provisioned gp2 volumes never resized down
Provisioned IOPS	io1/io2 IOPS setting	IOPS sized for peak, never revisited after launch
Backup and snapshot storage	Retention window, manual snapshots	Manual snapshots left indefinitely, long retention
Data transfer	Cross-AZ, cross-region traffic	Multi-AZ writes and read replicas in far regions
Licensing (LI vs BYOL)	Engine, edition, instance size	License Included on oversized SQL Server/Oracle instances
Multi-AZ multiplier	Standby replica compute and storage	Multi-AZ enabled for non-critical dev/test databases

A few heuristics hold up across most fleets:

Transactional, high-write workloads are usually compute and IOPS dominated. Rightsizing and gp3/io2 tuning matter most here.
Analytic or reporting replicas tend to be storage and data-transfer heavy. Watch cross-AZ reads closely.
Dev/test environments are almost always compute-dominated by pure waste. They run at full price around the clock for a fraction of the actual usage.

What Metrics And Tools Reveal Hidden RDS Waste?

You can’t optimize what you haven’t measured, and RDS gives you more visibility than most teams actually use. The signals that matter most: CPU at p95 and p99 (never the average, which hides spikes and masks oversizing), freeable memory trending toward zero, database connection counts against your max_connections ceiling, BilledReadIOPS and BilledWriteIOPS, storage growth rate, and replication lag on read replicas.

Several AWS tools each answer a different question:

CloudWatch and Enhanced Monitoring give you the raw time-series data on CPU, memory, IOPS, and connections at up to 1-second granularity.
Performance Insights shows you which queries and wait events are actually consuming your database load, which matters when CPU looks high but you’re not sure why.
AWS Compute Optimizer analyzes your utilization history and recommends specific instance-type changes, including storage and I/O recommendations for Aurora clusters.
Trusted Advisor flags idle DB instances, underutilized instances, and idle connections directly, and its checks can point to instances worth stopping outright.
Cost Explorer and Cost and Usage Reports (CUR) break down spend by resource, tag, and usage type so you can see exactly which database is driving which charge.
Cost Anomaly Detection catches spend spikes automatically, which matters more than it sounds once you have more than a handful of instances.

Running a real audit means combining these. AWS’s own guidance on optimizing RDS costs points to Trusted Advisor, Compute Optimizer, and Cost Explorer working together, since stopping idle non-production instances outside business hours alone can cut related spend by up to 70%.

A 14-day audit checklist: export CUR data by resource tag, pull Trusted Advisor’s cost-optimization checks, run Compute Optimizer against every instance older than 30 days, and cross-reference CloudWatch p95 CPU against instance class. For ongoing detection, a nightly Lambda job that checks connection counts and CPU against thresholds, then posts flagged instances to a Slack channel, catches drift before it becomes a habit.

Pro Tip: Set Cost Anomaly Detection at the RDS service level, not just the account level. A single misconfigured Multi-AZ failover test can spike your bill for days before anyone notices at the account view.

How Do You Rightsize RDS Instances Safely?

Rightsizing is the highest-leverage, lowest-risk move in the entire playbook, and most teams do it wrong by looking at average CPU instead of the percentiles that actually reveal risk. A database that averages 20% CPU but spikes to 90% every afternoon during batch jobs is not a downsizing candidate, even though the average screams “oversized.”

The methodology that actually works:

Collect 14 to 30 days of CloudWatch and Performance Insights metrics, not a snapshot from one Tuesday afternoon.
Analyze p95 and p99 CPU, not the average. Sustained CPU under 35% at p95 often signals a safe one or two class downsize.
Check freeable memory and connection counts alongside CPU. A CPU-light instance that’s memory-starved isn’t a downsizing candidate either.
Map the safe downsize target against your workload’s actual burst pattern before committing to a change.

Instance family choice matters as much as size. Burstable T-family instances work well for genuinely intermittent workloads, dev environments, and small production databases with low, spiky CPU demand, but they can surprise you with CPU credit exhaustion charges under sustained load. General-purpose M-family instances suit balanced transactional workloads. Memory-optimized R-family instances fit large working sets and heavy query caching. Graviton-based instances (the mXg and rXg families) deliver a real price-performance jump: expect roughly 15% to 30% better price-performance depending on which generation you’re migrating from.

Before you flip a production database to a new instance class or CPU architecture, validate with a load test against a snapshot restore, confirm the application driver and any native extensions support the target architecture, and schedule the swap in a maintenance window with a tested failback plan. Graviton migrations in particular need this discipline. The performance gain is real, but a handful of legacy drivers and extensions still lag on ARM support.

Pro Tip: Rightsize before you reserve. If you buy a three-year Reserved Instance on an oversized r6g.2xlarge and then rightsize to r6g.xlarge a month later, you’re stuck paying for capacity you no longer use.

Reserved Instances Vs Database Savings Plans: Which Saves More?

Once your fleet is rightsized, purchase commitments are where the next big chunk of savings lives, and getting the order wrong is the single most common mistake teams make. Reserved Instances lock in a specific instance family, size, and region in exchange for the deepest discounts, often 30% to 60% off on-demand pricing depending on term and payment option. Database Savings Plans trade a little discount depth for real flexibility. They apply automatically across instance families and sizes as long as you maintain a consistent hourly spend commitment, which matters if you’re planning a Graviton migration or expect your instance mix to shift.

A fleet that’s finished rightsizing but still growing or migrating instance families should lean toward Database Savings Plans. A fleet that’s stable and unlikely to change shape for the next year or three should lean toward Reserved Instances for the deeper discount.

Building a commitment ladder works better than an all-or-nothing purchase:

Measure your steady-state dollars-per-hour baseline across the rightsized fleet, ignoring burst capacity.
Commit 65% to 80% of that baseline to Reserved Instances or Savings Plans.
Leave the remaining 20% to 35% on-demand to absorb legitimate variability without over-committing.
Layer in a mix of 1-year and 3-year terms so you’re not locked into a single horizon as your fleet evolves.

A rough example: if your rightsized fleet runs a steady $10/hour in on-demand spend, committing $7 to $8 of that hourly rate to a 3-year Reserved Instance or Database Savings Plan can realistically cut that portion of the bill by a third to more than half, depending on payment option, while the remaining $2 to $3 stays flexible for spikes. Layering Reserved Instances for baseline coverage with Database Savings Plans for flexibility is the pattern that holds up best across mixed fleets.

When Does Aurora Serverless Or I/O-Optimized Save Money?

Aurora gives you two levers that provisioned RDS doesn’t: Serverless v2 for variable workloads and I/O-Optimized storage for I/O-heavy clusters. Picking the right one, or the right combination, depends entirely on your traffic shape and where your dollars are actually going today.

Aurora Serverless v2 scales capacity in fine-grained increments in near real time and bills for what you actually consume. For workloads with genuine, unpredictable variability, Serverless v2 can cut costs by up to 90% compared to running a provisioned instance sized for peak load around the clock. Aurora I/O-Optimized takes a different approach: it bundles I/O charges into the storage price instead of billing per operation, which pays off when I/O already represents a large share of your Aurora spend.

Option	Best-Fit Workload	Cost Impact	Operational Effort
Aurora Serverless v2	Highly variable, spiky, or unpredictable traffic	Up to 90% savings vs. always-on provisioned capacity	Low; scaling is automatic
Provisioned Aurora with reservations	Steady-state, predictable transactional load	30–60% off on-demand with RIs/Savings Plans	Moderate; requires commitment planning
Aurora Standard storage	Low I/O relative to compute/storage spend	Baseline pricing, pay per I/O operation	Low
Aurora I/O-Optimized	I/O represents 25%+ of total cluster spend	Up to ~40% total savings in I/O-heavy clusters	Low; one-time storage type switch

Finding the tipping point isn’t guesswork. AWS documents a worked example using CloudWatch metrics to calculate monthly I/O and storage usage, then compare Standard against I/O-Optimized pricing directly. One published sample cluster running on r6g.large instances saw a substantial reduction in monthly cost after switching. Rather than estimating by hand, Compute Optimizer and Cost Optimization Hub now surface I/O-Optimized recommendations automatically with quantified savings estimates, which removes most of the guesswork from the decision.

Pull your cluster’s monthly I/O and storage usage from CloudWatch.
Compare the calculated Standard cost against the I/O-Optimized rate for the same usage.
If I/O exceeds roughly a quarter of total cluster spend, I/O-Optimized almost always wins.

For cross-region disaster recovery, a headless cluster pattern (an Aurora Global Database secondary region with no active read replica instance attached) lets you replicate data without paying for idle compute sitting in a region you hope never to use.

Pro Tip: Run the CloudWatch-based I/O-Optimized calculation quarterly, not once. Workload I/O intensity shifts as your application evolves, and a cluster that didn’t qualify last year might cross the threshold now.

Which Storage Type Cuts RDS Costs Fastest?

Storage decisions are often the fastest win in the entire playbook because they require no downtime beyond a maintenance window and no application changes. The gp2-to-gp3 conversion alone regularly shows up as the first item on a real audit checklist.

gp2 ties your IOPS directly to volume size, which means small volumes are IOPS-starved and large volumes pay for IOPS you never asked for. gp3 decouples the two: you get a baseline 3,000 IOPS and 125 MB/s throughput regardless of size, and you pay separately if you need more. The breakpoint favoring gp3 is generally volumes larger than about 100 GB, where gp2’s bundled IOPS scaling starts costing more than gp3’s flat baseline plus targeted provisioning.

For workloads that genuinely need sustained high IOPS beyond what gp3’s provisioned tier offers, io2 and io2 Block Express deliver higher ceilings and better durability guarantees, but they cost more per IOPS. Size provisioned IOPS to your measured p95 demand from CloudWatch, not to a guess made at launch time three years ago.

Migrating oversized or misconfigured volumes doesn’t require downtime if you plan it right:

Take a snapshot of the current volume during a low-traffic window.
Restore the snapshot as a new instance with the target storage type and size.
Validate performance against production traffic patterns before cutting over.
Enable storage autoscaling on the new volume so you stop guessing at provisioning size manually.

Beyond storage type, you can reduce billed IOPS directly by cutting the I/O your database actually generates. Adding a caching layer in front of read-heavy queries, tuning queries to avoid full-table scans, and reducing unnecessary synchronous writes all lower your BilledReadIOPS and BilledWriteIOPS line items without touching your storage configuration at all.

Pro Tip: Check your storage autoscaling maximum after every gp3 migration. Teams frequently forget to raise the ceiling, then get paged when the database hits a storage-full error during a legitimate growth spurt.

How Backup Retention Affects Your RDS Storage Bill

Automated backups are free up to 100% of your allocated storage, and that’s exactly why teams stop paying attention to them, right up until manual snapshots and extended retention windows start showing up as a real line item. Charges begin once your backup storage exceeds that free allowance, once you accumulate manual snapshots (which never expire on their own), and whenever you copy snapshots across regions for disaster recovery.

A sane retention policy looks something like this: automated backup retention of 7 to 14 days for most production workloads, adjusted upward only when a specific compliance requirement demands longer. Manual snapshots should carry an explicit expiration date the moment they’re created, not an implicit “someone will clean this up eventually.” Anything you need to retain long-term for audit or compliance purposes belongs in S3 or Glacier, not as a live RDS snapshot racking up storage charges every month.

Automating this removes the human error factor entirely:

Set up AWS Backup with lifecycle policies that automatically transition snapshots to cold storage after a defined window.
Export snapshots you need to keep for years to S3, where storage costs a fraction of live snapshot storage.
Run a monthly cleanup script that flags manual snapshots older than your policy threshold for review and deletion.

Pro Tip: Tag every manual snapshot with a creator name and expiration date at creation time. Untagged snapshots from a departed engineer are the single most common source of “mystery” backup charges we see in cost reviews.

Cutting Costs Through Connection Pooling And Query Tuning

Application-level changes rarely get credit in cost optimization conversations, but they directly reduce the database load that drives both instance sizing and IOPS provisioning. Fewer, better-managed connections and fewer wasted queries mean you can run a smaller instance and provision less I/O for the same application performance.

RDS Proxy sits between your application and the database, pooling and multiplexing connections so a burst of application-layer connections doesn’t translate into a burst of actual database connections. It adds a small per-ACU overhead cost, but that cost is often smaller than the cost of an instance upgrade you’d otherwise need to handle connection storms during traffic spikes, particularly for serverless or Lambda-based applications that open and close connections rapidly.

Query and schema tuning delivers savings that compound over time:

Add indexes to eliminate full-table scans on your highest-frequency queries.
Review your buffer cache hit ratio and increase memory allocation only if the ratio is genuinely low, not by default.
Batch writes where the application logic allows it instead of issuing many small synchronous writes.

To confirm any of this actually worked, measure before and after:

Record BilledReadIOPS and BilledWriteIOPS for two weeks before making changes.
Record buffer cache hit ratio over the same window.
Implement pooling or query changes, then measure both metrics again after two weeks of stable traffic.

Pro Tip: Deploy RDS Proxy to a single non-critical read replica first. Connection pooling behavior varies by driver, and you want to catch compatibility issues before they hit your primary write instance.

How Scheduling Non-Production Instances Cuts Costs

Development and staging databases running 24/7 at full price for roughly 40 hours a week of actual use is one of the most common and most fixable sources of RDS waste in any organization. A database that only needs to be up during business hours, Monday through Friday, is burning money the other 128 hours of the week for nothing.

Stopping non-production instances outside business hours can cut related spend by up to 70%, and the implementation is genuinely simple once you tag your fleet correctly.

Tag every non-production instance with an environment label (dev, staging, QA) and an owning team.
Deploy the AWS Instance Scheduler solution, or a Lambda function triggered by EventBridge, to stop and start instances on a defined schedule.
Set the schedule to match your team’s actual working hours, including time zone, rather than a generic 9-to-5 default.
Exclude any instances that CI pipelines or automated tests depend on outside business hours, or adjust their schedule separately.

A few things to plan for: a stopped RDS instance still bills for storage, so you won’t zero out the cost entirely, just the compute portion. RDS also automatically restarts a stopped instance after seven days if you haven’t started it manually, so long weekends need a scheduled restart to avoid a surprise. And if your CI pipeline depends on a database being available at 2 AM for an automated test run, either exclude that instance from the schedule or adjust the schedule to match, since boot time adds a few minutes of delay your pipeline needs to account for.

Pro Tip: Snapshot any instance you’re about to decommission rather than schedule for stop/start indefinitely. If a database hasn’t been touched in 30 days, it’s usually cheaper to delete it and keep a final snapshot than to keep stopping and starting it forever.

What Governance Policies Keep RDS Costs Low Long-Term?

Every tactic in this guide works once. What keeps costs low permanently is a governance process that catches drift before it becomes the new normal, because fleets left unmanaged for six months quietly regrow the same waste you just cleaned up.

Tagging is the foundation everything else depends on. Enforce required tags at resource creation: environment, owning team, cost center, and application name at minimum. Without consistent tagging, Cost Explorer and CUR reports can’t attribute spend to the people who can actually act on it, which means nobody owns the fix when a database starts running hot.

Utilization thresholds turn detection into automated action instead of a report nobody reads:

Policy Trigger	Threshold	Automated Action
Sustained low CPU	Below 30% for 14 days	Flag as rightsizing candidate, notify owner
No active connections	30+ days with zero connections	Notify owner, snapshot, then stop instance
Storage nearing capacity	Above 90% allocated storage	Alert for gp3 conversion or storage increase review
Manual snapshot age	Older than 90 days, untagged	Flag for deletion review in monthly cleanup

A monthly FinOps cadence keeps this from becoming a one-time project: review Reserved Instance and Savings Plan coverage against your current fleet, audit for idle instances flagged by Trusted Advisor, clean up expired manual snapshots, and check Cost Anomaly Detection alerts from the past 30 days. Teams building out custom dashboards for this cadence sometimes turn to partners like Let’s Build My App to wire Cost Explorer and CUR data into a QuickSight or internal reporting layer that the whole team actually checks. For a broader look at how this fits into overall cloud spend management, AWS cloud cost optimization strategies cover the FinOps process end to end.

Pro Tip: Assign a named owner to every automated policy action, not just the instance itself. A rightsizing candidate flagged to a distribution list gets ignored. One flagged to a specific engineer gets fixed within a sprint.

When Should You Bring In A Cost Optimization Partner?

Most of this playbook is genuinely doable in-house with a competent DBA and a few days of focused work. The calculus changes once your estate crosses a certain size or complexity, and recognizing that threshold early saves months of slow bleed.

A few practical signals that it’s time to bring in outside help: more than a handful of instances running above $300 a month each, a mixed-engine estate where SQL Server or Oracle licensing complicates every rightsizing decision, or a planned cross-region disaster recovery redesign that touches Multi-AZ, read replica placement, and data transfer costs all at once. Complexity compounds fast in mixed environments, and a team spread thin on day-to-day operations often can’t dedicate the focused audit time these situations need.

The instances that cost the most to leave misconfigured are rarely the ones anyone’s watching closely. It’s the mixed-engine SQL Server fleet nobody’s touched since the original migration, still running License Included on an oversized instance class three years later, that quietly accounts for the biggest line item on the bill.

What a real engagement should deliver: a full resource inventory with utilization data, a rightsizing plan backed by actual percentile analysis, a reservation and Savings Plan strategy matched to the rightsized baseline, and a concrete migration plan for gp2-to-gp3 conversions or Graviton moves where they make sense. If you’re evaluating SQL Server specifically, detailed pricing and optimization guidance for SQL Server on RDS is worth reviewing before any engagement, since licensing decisions there drive a disproportionate share of total cost.

Pro Tip: Ask any prospective partner for their audit methodology before signing anything. A credible engagement starts with 14 to 30 days of real utilization data, not a one-hour call and a generic recommendation deck.

A Priority Sequence For DBAs And FinOps Teams

The order matters more than most guides admit. Measure first, using real CloudWatch and Performance Insights data over at least two weeks. Rightsize second, based on p95 and p99 percentiles rather than averages that hide the spikes that actually matter. Fix storage third, converting oversized gp2 volumes to gp3 and sizing provisioned IOPS to measured demand rather than a launch-day guess. Commit fourth, once the fleet is stable and you know your real steady-state baseline. Automate last, building scheduling and governance policies that keep the whole system from drifting back into waste over the following year.

Skipping steps is where teams lose money they didn’t need to lose. The single most expensive mistake in this entire sequence is buying a long-term Reserved Instance before rightsizing, since a three-year commitment on an oversized instance simply locks in the waste you were trying to eliminate.

If your team doesn’t have the bandwidth to run a proper 14-day audit against a large or mixed-engine fleet, an external baseline from a free RDS cost optimization audit can shortcut months of internal analysis into a single focused engagement.

Get A Free Audit Of Your RDS Spend

IT-Magic runs a free 5-day RDS cost audit that hands you exactly what this article describes: a rightsizing plan built from real percentile data, a gp2-to-gp3 storage review, and a Reserved Instance or Database Savings Plan proposal matched to your actual baseline, not a guess.

Deliverables include a full resource inventory, the rightsizing list broken down by instance, the commitment strategy, and a scoped migration plan for any gp3 or Graviton moves worth making. For teams that want ongoing management after the initial cleanup, IT-Magic also offers fixed-price migration projects and monthly DevOps-as-a-Service retainers that keep governance and monitoring running long after the audit ends.

If your RDS bill has crept up without a clear explanation, start with the free audit and get a rightsizing plan and reservation proposal in writing before you commit to anything.

Key AWS Resources For RDS Cost Optimization

AWS Compute Optimizer — analyzes utilization history and recommends instance, storage, and Aurora I/O-Optimized changes with estimated savings.
AWS Trusted Advisor — flags idle, underutilized, and overutilized RDS instances; deeper cost-optimization checks require a Business or Enterprise support plan.
Amazon CloudWatch and Performance Insights — the raw metrics layer behind every rightsizing and IOPS decision in this guide.
AWS Cost Explorer and Cost and Usage Reports (CUR) — break down spend by resource, tag, and usage type for governance reporting.
AWS Backup — manages snapshot lifecycle policies and automates the move to cold storage for long-term retention.
Aurora documentation on Serverless v2 and I/O-Optimized — the source for capacity scaling behavior and storage pricing tiers referenced throughout this guide.

Compute Optimizer’s recommendation quality depends on its lookback period, so give it at least 14 days of data before trusting its output, and note that some Trusted Advisor cost checks are only available on Business and Enterprise support plans.

Sources

FAQ

Why Is My RDS Bill So High?

Most unexpectedly high RDS bills come from oversized instances running around the clock, gp2 storage volumes that outgrew their original sizing, and Multi-AZ or read replica configurations left running in non-production environments. Cross-region data transfer and unmanaged manual snapshots are the quieter culprits that rarely show up until someone actually audits the CUR data.

What Are The Four Pillars Of Cost Optimization?

AWS’s Cost Optimization pillar within the Well-Architected Framework generally centers on rightsizing resources to actual demand, adopting flexible and elastic pricing models like Reserved Instances and Savings Plans, matching supply to demand through automation, and continuously measuring and monitoring spend against usage.

How Much Does RDS Cost Per Month?

There’s no single monthly figure, since RDS pricing depends on instance class, storage type and size, IOPS, backup retention, region, and engine licensing. A small db.t3.micro instance can run under $15 a month, while a large Multi-AZ SQL Server deployment can run into the thousands.

Which AWS RDS Engine Is The Cheapest?

Open-source engines like PostgreSQL and MySQL are generally the cheapest to run on RDS because they carry no licensing premium, unlike License Included SQL Server or Oracle deployments. Aurora PostgreSQL and Aurora MySQL add Aurora-specific pricing on top but can still cost less overall than a comparably sized commercial-engine deployment once licensing is factored in.

When Should I Switch To Aurora I/O-Optimized?

Switch when I/O charges represent roughly a quarter or more of your total Aurora cluster spend, which you can confirm using a CloudWatch-based calculation comparing Standard and I/O-Optimized pricing for your actual usage. Compute Optimizer and Cost Optimization Hub can also generate this recommendation automatically with an estimated savings figure.