AWS Database Cost Strategy Guide: Engines, Commitments, and EDP Levers

Across the engagements our advisory team has audited, AWS database spend averages 18 to 32 percent of total AWS run-rate at enterprises, and it is the category where engine choice, commitment posture, and contract negotiation interact most aggressively. A poorly structured database estate routinely costs two to three times what a well-structured one does for the same workload. This pillar walks through the cost architecture of every major AWS database service, the commitment and pricing levers that bend each one, and how to scope databases into your EDP private pricing tier conversation so the savings stick across the contract term.

Why AWS database cost is structurally hard to control

Database cost on AWS has four distinct cost vectors that compound: compute (the instance or capacity unit the database runs on), storage (allocated, provisioned IOPS, or consumed), I/O (data transfer, request counts, backups), and licence (engine and feature). Most enterprises optimise one or two and lose the savings on the others. The high-leverage moves cut all four simultaneously, which requires architecture decisions to be made with pricing visibility, not in isolation.

The second structural problem is that database engines are sticky. Once you have shipped production traffic against Aurora MySQL, the cost to migrate to vanilla RDS MySQL or DynamoDB is large enough that the optimisation conversation collapses into a commitment-and-discount conversation. The earlier you do the engine cost analysis, the more options you have. By year three of an engine choice, the only real lever is the commercial one.

The eight database services that account for almost all enterprise spend

The pricing structure differs enough between these services that the same workload can vary by an order of magnitude in cost depending on which one it lives on. The cost analyses below progress from highest-volume to most specialised.

Amazon RDS cost architecture

RDS bills four meters: instance-hours, allocated storage (gp3 or io2), I/O for provisioned IOPS volumes, and automated backup storage above the free allocation. For SQL Server and Oracle, a fifth meter applies: the BYOL versus License Included decision, which can double the instance hour rate. See RDS pricing optimization for the full per-engine cost breakdown.

The highest-leverage RDS moves at enterprise scale:

• Reserved Instance coverage on stable workloads. 1-year no-upfront RIs deliver 30 to 35 percent off on-demand; 3-year all-upfront 60+ percent. Coverage targets of 65 to 80 percent of steady-state RDS spend are normal for mature estates.
• Multi-AZ rationalisation. Multi-AZ doubles the compute and storage cost. Non-production environments rarely need it; many production read-replica setups give you the resilience without the duplication.
• gp3 over gp2 and io2. gp3 separates storage capacity from IOPS pricing, almost always cheaper than gp2 above a few hundred GB. io2 is only justified for workloads requiring more than 64,000 IOPS sustained.
• Right-sizing on instance class. Default db.m5 or db.r5 sizing for workloads that would fit on db.t4g burstable can cut 40 to 60 percent immediately.
• Graviton migration. db.m6g / db.r6g / db.t4g instances deliver 15 to 20 percent better price-performance versus Intel equivalents for most PostgreSQL and MySQL workloads.

Aurora cost architecture and the I/O question

Aurora bills instance-hours plus a storage-consumed model (you pay for the GB Aurora actually stores, not the allocated volume), plus a per-request I/O charge of $0.20 per million requests in standard configuration, plus backup storage. Aurora I/O-Optimized pricing was introduced in 2023 specifically because the per-request I/O charge made write-heavy workloads economically unattractive on Aurora.

The Aurora cost decision tree:

• Read-heavy, modest I/O. Standard Aurora pricing is usually optimal. Lower instance costs than RDS, faster failover, better read-replica scaling.
• Write-heavy or I/O-intensive. Aurora I/O-Optimized eliminates the per-request I/O charge in exchange for a 30 percent higher instance hour rate and storage rate. The break-even is roughly 25 percent of compute spend being I/O cost in standard Aurora.
• Spiky, low-utilisation workloads. Aurora Serverless v2 scales ACUs (Aurora Capacity Units) up and down, attractive for development environments and unpredictable production traffic. Watch ACU sizing carefully; oversized minimums burn money on idle.

See Aurora vs RDS cost comparison for the engine-by-engine breakdown.

DynamoDB cost architecture

DynamoDB is the most pricing-sensitive AWS database in two ways. First, the on-demand versus provisioned capacity decision can swing cost by 5 to 10x at scale. Second, table design (partition key cardinality, GSI count, projection strategy, item size) determines whether your read and write capacity costs grow linearly or exponentially with traffic.

The headline pricing levers:

• On-demand to provisioned with auto-scaling. On-demand is roughly 7x the cost of provisioned at sustained utilisation. The right strategy is on-demand for low-volume tables and traffic-unpredictable workloads, provisioned with auto-scaling for everything at scale.
• Reserved capacity. 1- and 3-year reserved capacity commits on provisioned WCU/RCU deliver an additional 50 to 75 percent off the provisioned rate. Covered in detail in DynamoDB reserved capacity.
• GSI hygiene. Each global secondary index incurs its own WCU/RCU cost. Audit GSI usage in CloudWatch; unused or low-value GSIs routinely account for 20 to 40 percent of DynamoDB spend.
• Item size and request count. A 4 KB read consumes 1 RCU; a 4 KB write consumes 1 WCU. Item compaction, projection trimming, and request batching all reduce capacity consumption.
• DynamoDB Standard-IA storage class. For tables where data is rarely accessed, Standard-IA cuts storage cost by 60 percent at the expense of higher read/write request fees.

See DynamoDB pricing strategy for the full optimisation playbook.

Redshift cost architecture

Redshift cost depends primarily on cluster sizing (RA3 node count or RPU configuration in Serverless) plus managed storage and the spectrum / data lake federation charges. Idle clusters and over-provisioned BI workloads are the most common waste patterns.

The cost-shaping moves:

• RA3 reserved nodes on steady-state warehouses. 1-year reserved RA3 nodes cut 30 percent; 3-year all-upfront 60+ percent. Apply only to clusters that genuinely run 24/7 at stable size.
• Redshift Serverless for ad-hoc or bursty BI workloads. Pay-per-RPU eliminates idle cluster cost but can be more expensive at sustained utilisation. Model both before committing.
• Pause-and-resume on dev / QA clusters. Most enterprises run non-production warehouses 24/7 by default. Pausing nights and weekends cuts non-production Redshift cost by 65 to 75 percent.
• Spectrum and Lake Formation cost integration. Federated queries to S3 data scan charges can rival cluster cost; manage with partition pruning and Parquet conversion.

See Redshift pricing negotiation and Redshift Serverless pricing for the cluster strategy detail.

ElastiCache and MemoryDB cost architecture

In-memory data stores on AWS bill instance-hours (ElastiCache) or node-hours plus storage and data-written (MemoryDB). The optimisation surface is small but high-leverage: right-sizing, replica strategy, and reserved-instance coverage.

• Right-size aggressively. ElastiCache nodes are routinely oversized; the cache hit ratio rarely justifies the next tier up.
• Multi-AZ for the right workloads only. Single-AZ ElastiCache with a documented restore SLA is acceptable for cache-only workloads. Multi-AZ doubles cost.
• Reserved nodes. 1- and 3-year reserved-node commits deliver 30 to 60 percent savings on steady cache fleets.
• MemoryDB versus ElastiCache. MemoryDB is the durable Redis offering and costs roughly 2x ElastiCache. Justify on durability requirement, not feature inertia.

Where engine choice silently inflates cost

Engine choice is the most expensive decision in the database stack and the hardest to revisit. The three patterns we see most often:

1. Aurora chosen for workloads that would be cheaper on vanilla RDS. Aurora is excellent for read-replica scaling, fast failover, and PostgreSQL-compatibility features RDS lacks. For straightforward MySQL/Postgres workloads with modest traffic, RDS is 30 to 45 percent cheaper.
2. DynamoDB chosen for relational workloads. The marketing pull toward DynamoDB has produced poorly-shaped key-value designs that cost far more than the equivalent RDS table would.
3. SQL Server or Oracle inherited from on-prem migrations. Licence-included SQL Server can be 2 to 4x the cost of PostgreSQL on RDS for equivalent capacity. Migration is expensive but pays back inside 18 months at any meaningful scale. See our Oracle to AWS migration guidance for the migration economics.

The EDP layer: how databases negotiate

Database spend is one of the cleanest categories to scope into an AWS EDP negotiation because the AWS deal desk has visibility into your forecasted commit and can model the price impact of additional discount on your database SKUs. The negotiable elements:

• RDS, Aurora, Redshift instance pricing. Standard EDP tier discounts apply (typically 5 to 20 percent depending on commit level). Above $250K monthly database spend, custom SKU-level discounts become available.
• DynamoDB private pricing. For sustained DynamoDB spend above $50K/month, custom per-request or per-WCU/RCU pricing is regularly negotiated. The break-even versus reserved capacity should be modelled both ways.
• Backup storage pricing. Automated backup storage above the free allocation is a frequently-overlooked negotiable item, particularly at multi-petabyte scale.
• License-included SQL Server. AWS will discount LI SQL Server pricing 10 to 30 percent on multi-year commitments above $500K annual SQL Server spend. Frequently the route of least resistance for shops blocked from BYOL by Microsoft licensing posture.
• Cross-region replica pricing. Data transfer for cross-region Aurora replicas and DynamoDB Global Tables is a separately-negotiable line at scale.

Migration and consolidation as a cost lever

Two structural moves compound the line-item optimisations above:

• Account-level consolidation. Splitting database workloads across many AWS accounts fragments your reserved-instance pool and your EDP drawdown. Consolidating database accounts under an Organization with consolidated billing recovers RI/SP cross-account flexibility.
• Engine consolidation. Enterprises with sprawling estates often run six or eight database engines for historical reasons. Targeted migration to two or three engines reduces licensing exposure, operational headcount, and EDP fragmentation.

See database migration cost planning for the migration economics.

The audit framework

The audit our team runs against every new database estate, in order:

1. Inventory by engine and account. Quantify spend by service, account, region, and engine. Identify the top 20 instances by spend.
2. Right-sizing review. CloudWatch CPU, memory, IOPS, and connection-count metrics for the top instances. Flag anything running under 35 percent sustained CPU.
3. Commitment coverage analysis. RI and Savings Plan coverage by engine, by region. Identify uncovered steady-state workloads.
4. Storage and backup audit. gp2/gp3 distribution, snapshot retention, cross-region copy charges.
5. Multi-AZ rationalisation. Multi-AZ status by environment; flag anything in non-production.
6. License model audit (SQL Server, Oracle). BYOL versus LI versus alternative engine.
7. DynamoDB and Redshift architectural review. Capacity mode, GSI usage, reserved capacity coverage, pause/resume policy.
8. EDP scoping recommendation. Quantify negotiable database spend, model discount tier improvement, build the EDP negotiation case.

Action checklist

1. Pull a 90-day cost report grouped by AWS database service. Identify your top three services by spend; that is where 80 percent of the savings lives.
2. Audit RI/Savings Plan coverage by database SKU. Anything below 65 percent coverage on steady-state workloads is leaving money on the table.
3. Review every Multi-AZ deployment in non-production. The savings are immediate.
4. For DynamoDB, classify every table as on-demand or provisioned with rationale.
5. For SQL Server / Oracle, model BYOL versus LI versus migration to PostgreSQL.
6. Scope database spend explicitly in your next EDP negotiation conversation. Pull benchmarked discount data into the negotiation.
7. Contact our advisory team for a database cost audit benchmarked against $2.4B+ of reviewed AWS spend.

Database cost on AWS is the category where customer-side optimisation, architectural rework, and contract negotiation must move together. Buyers who execute all three across an EDP cycle routinely cut 35 to 50 percent on database run-rate; buyers who optimise in isolation cap out around 15 percent. See our EDP negotiation guide for how the database scope rolls into the broader contract.