Enterprise database spend will exceed £100 billion globally in 2026, yet 60% of organisations still overpay by running workloads on the wrong platform. The three-way choice between AWS RDS, Amazon Aurora, and self-managed databases on EC2 creates a £200,000-£2 million annual cost variance for typical enterprise deployments, and most platform architects make this decision using outdated assumptions from 2020.
Netflix just migrated their entire platform to Aurora PostgreSQL, achieving 75% latency reduction and 28% cost savings. Samsung serves 1.1 billion users on Aurora with 44% lower costs than their previous Oracle deployment. DraftKings processes 1 million database operations per minute across 200+ Aurora clusters. These aren’t edge cases, they’re the new baseline for production database economics in 2026.
Traditional thinking positions Aurora as the “expensive premium option” whilst RDS offers “good enough managed services” and EC2 provides “maximum control at minimum cost”. This framework breaks down completely above 10TB database size, for workloads requiring sub-30-second failover, or when I/O costs exceed 25% of total database spend. Understanding the actual breakpoints between these platforms determines whether your database costs £150,000 or £600,000 annually at enterprise scale.
Aurora’s distributed storage architecture changes database economics fundamentally
Amazon Aurora separates compute from storage in ways that eliminate the traditional cost-doubling required for high availability. Data replicates automatically six ways across three Availability Zones in 10GB segments distributed into protection groups that tolerate losing two copies without affecting write availability. This design delivers resilience comparable to RDS Multi-AZ without running duplicate database instances.

The architectural difference manifests in failover performance. Aurora achieves under 30 seconds for most scenarios, often 7-10 seconds in production benchmarks, compared to 60-120 seconds for traditional RDS Multi-AZ deployments. For applications processing financial transactions or serving real-time user requests, this 90-second difference translates directly to revenue impact and user experience.
Samsung Electronics validated Aurora’s capabilities during their migration of Samsung Account services supporting 1.1 billion users globally. The platform now handles 80,000+ requests per second across regions whilst achieving 90% of queries completing under 60 milliseconds. More significantly, Samsung realised 44% reduction in monthly operational costs compared to their Oracle deployment whilst improving performance. The migration eliminated hardware procurement cycles, database licensing complexity, and the operational overhead of managing high availability infrastructure.
Netflix’s consolidation onto Aurora PostgreSQL demonstrated performance improvements at the extreme end of scale. Their Spinnaker deployment platform saw 50% latency reduction from 67.57ms to 41.70ms. The policy engine achieved 75% latency reduction from 26.72ms to 6.51ms. These improvements came alongside 28% lower database costs compared to self-managed PostgreSQL on EC2, reversing the conventional wisdom that managed services cost more than DIY approaches.
Aurora’s I/O-Optimized configuration fundamentally alters the cost equation for transaction-heavy workloads. Standard Aurora charges £0.15 per million I/O requests (approximately $0.20), which can exceed storage and compute costs for OLTP applications. I/O-Optimized eliminates this per-request charge in exchange for 30% higher instance costs and 2.25x storage pricing (£0.17/GB-month versus £0.08/GB-month). AWS recommends the switch when I/O exceeds 25% of total Aurora spend. Organisations with write-heavy workloads report 40% total cost reduction after moving to I/O-Optimized, transforming Aurora from “expensive” to cost-effective versus RDS.
Aurora Serverless v2 extends the economic advantages to variable workloads. The platform scales from 0.5 to 256 Aurora Capacity Units in 0.5 ACU increments within milliseconds, matching actual demand rather than provisioning for peak load. The minimum monthly cost runs approximately £35 (0.5 ACU × 730 hours × £0.095), making it genuinely cost-effective for development environments. Production implementations at companies like KOHO demonstrate 40-50% savings versus provisioned instances for workloads with predictable daily or weekly traffic patterns. The August 2025 performance improvements delivered up to 30% better throughput, and the recent scale-to-zero capability reduces costs further for intermittent workloads.
RDS pricing advantages persist for predictable workloads under 5TB
RDS remains the financially rational choice for databases under 5TB with steady traffic patterns and standard availability requirements. A typical enterprise workload running on db.r7g.2xlarge instances (8 vCPU, 64GB RAM) with 500GB storage in Multi-AZ configuration costs approximately £1,200 monthly on RDS PostgreSQL versus £1,400 on Aurora provisioned instances. The difference compounds with Reserved Instance commitments delivering up to 60% savings on RDS compared to on-demand pricing.
Current UK region (eu-west-2) pricing for memory-optimised instances illustrates the cost structure as of January 2026. A db.r7g.2xlarge runs £0.79 per hour on-demand (approximately $1.01), dropping to £0.58 hourly with 1-year Reserved Instances or £0.41 with 3-year commitments. Multi-AZ deployment doubles these costs. Read replicas bill at the same instance rate. For organisations running predictable workloads where capacity planning is straightforward, these savings accumulate significantly over multi-year deployments.
The Extended Support pricing introduces new cost considerations for organisations running older database versions. PostgreSQL 12 and earlier MySQL versions incur £0.08-£0.16 per vCPU-hour beyond community end-of-life dates. An 8-vCPU instance adds approximately £0.32/hour (£233 monthly) for Extended Support, creating pressure to maintain current versions or accept the premium for stability. This particularly affects financial services organisations where application certification cycles lag database version releases.
Blue/Green deployments now reduce upgrade risk dramatically, addressing a historical RDS weakness. Switchover times achieve under 5 seconds using AWS’s Advanced JDBC Driver (under 1 minute with standard drivers), enabling major version upgrades and parameter changes without meaningful downtime. The feature creates a complete staging environment with continuous replication, allowing validation before cutover. For enterprises managing quarterly maintenance windows, Blue/Green deployments eliminate the traditional tension between stability and staying current on security patches.
RDS performance capabilities have improved substantially with Multi-AZ DB Clusters using engine-native replication with two readable standbys. Failover completes in under 35 seconds with zero data loss, significantly faster than traditional Multi-AZ’s 60-120 second window. RDS Proxy reduces these times further by eliminating DNS propagation delays that affect application reconnection. The combination positions RDS Multi-AZ as a credible alternative to Aurora for workloads where sub-30-second failover isn’t critical.
The FinOps Evolution framework we explored previously applies directly to database platform selection. Moving from reactive cost management to strategic value creation requires understanding not just infrastructure costs but operational overhead, risk exposure, and opportunity costs. RDS delivers predictable monthly bills; Aurora delivers operational efficiency that reduces DBA time by 40-60% according to AWS customer studies.
EC2 self-managed databases serve specific compliance and licensing requirements
Self-managed databases on EC2 cost 45-55% less for raw infrastructure, but this comparison ignores operational overhead that typically exceeds infrastructure savings. A db.r7g.2xlarge equivalent on EC2 runs £0.34 per hour versus £0.79 for RDS, suggesting dramatic savings. Reality includes managing patching schedules, backup scripts, high availability configuration, monitoring infrastructure, and failover automation that RDS handles automatically.
The legitimate use cases for EC2-based databases centre on three scenarios that justify the operational complexity. First, Oracle RAC deployments where clustered high availability requires specific licensing arrangements that managed services don’t support. FlashGrid and similar tools have reduced Oracle RAC deployment from weeks to hours, but organisations must factor DBA time for ongoing operations.
Second, compliance requirements demanding specific OS-level configurations, audit controls, or encryption implementations not available in managed services. Financial services organisations subject to PRA supervisory statement SS2/21 sometimes require particular hardening configurations or logging capabilities that necessitate OS-level access. Healthcare providers handling NHS patient data under specific security frameworks may face similar constraints, though NHS Digital’s own AWS adoption suggests most requirements are satisfiable with managed services.
Third, exotic database engines or versions unsupported by RDS. Organisations running Cassandra, MongoDB, or specialised time-series databases must manage their own infrastructure. Legacy applications requiring PostgreSQL 9.6 or MySQL 5.5 beyond Extended Support periods may also necessitate EC2 deployment, though this typically indicates broader application modernisation needs.
The operational overhead calculation for EC2 databases includes hardware provisioning, OS patching, database patching, backup scripting, monitoring configuration, failover automation, capacity planning, and performance tuning that consume 1-2 full-time DBA resources for moderate complexity deployments. At £80,000-£120,000 annual cost per DBA, the infrastructure savings evaporate quickly unless database count and complexity justify dedicated operations teams.
Real enterprise outcomes quantify managed services advantages
Company Name & Industry: DraftKings, Online Sports Betting and Fantasy Sports
Scale Context: 200+ Aurora MySQL databases processing 1 million operations per minute, serving millions of concurrent users during major sporting events
Challenge: Previous database platform exhibited 30-second replication lag and couldn’t handle traffic spikes during major events without performance degradation Solution Implemented: Migrated to Amazon Aurora MySQL with optimised cluster configuration, leveraging Aurora’s automatic read scaling and sub-second replication Measurable Outcomes:
- Replication lag reduced from 30 seconds to 10-30 milliseconds
- Average write latency of 6ms with sub-millisecond reads
- Sustained 50% higher than normal traffic during Super Bowl 2024 with zero performance impact
- 200+ databases consolidated onto managed Aurora platform
Company Name & Industry: Dow Jones, Financial Information and Media
Scale Context: 12+ TB data warehouse serving 3,000+ requests per second at peak, supporting real-time financial market data with 3-4x traffic spikes during major events Challenge: Managing 200 on-premises servers running SQL Server with complex licensing, hardware refresh cycles, and estimated months-long migration timeline Solution Implemented: Migrated to Aurora PostgreSQL Global Database with 1 writer and 11 readers across 2 US regions, completed database cutover in single 8-hour maintenance window
Measurable Outcomes:
- Reduced 200 on-premises servers to simplified global cluster
- Database migration completed in 8 hours versus months estimated
- Handles 3,000+ requests per second with 3-4x traffic spike capability
- Eliminated hardware procurement cycles and SQL Server licensing costs
Company Name & Industry: Panasonic Avionics, In-Flight Entertainment Systems
Scale Context: Serving 2.7 billion passengers annually across 15,000+ in-flight entertainment deployments globally
Challenge: High operational costs for database infrastructure supporting mission-critical systems requiring extreme reliability in challenging environments
Solution Implemented: Migrated to Amazon Aurora MySQL, consolidating disparate database systems onto managed cloud platform
Measurable Outcomes:
- 80% reduction in database costs
- 87% reduction in infrastructure costs
- 78% reduction in storage costs
- Improved reliability for systems operating in challenging connectivity environments
Capital One completed an 8-year transformation to full cloud-native operations, closing 8 on-premises data centres whilst shifting from quarterly releases to multiple deployments per day. Environment provisioning dropped from 3 months to minutes. The migration to AWS managed database services played a central role in this transformation, eliminating hardware procurement delays and database administration overhead that previously constrained development velocity.
The consistent pattern across these implementations shows 40-80% cost reductions when migrating from legacy databases to Aurora, alongside substantial performance improvements. The cost savings derive not just from infrastructure efficiency but from operational simplification that reduces DBA headcount requirements and eliminates procurement cycles.
Total cost of ownership calculations favour Aurora above 10TB for I/O-intensive workloads
Gartner positioned AWS as a Leader in the Magic Quadrant for Cloud Database Management Systems for the ninth consecutive year (2024), with the highest score for Ability to Execute. A Forrester Total Economic Impact study found 243% ROI, £6 million net present value, and payback under 6 months for organisations migrating to AWS managed database services from on-premises deployments.
AWS’s published TCO metrics claim Aurora delivers 42% lower total cost of ownership compared to on-premises alternatives with 6-month payback and 434% three-year ROI. These figures assume eliminating hardware procurement cycles, data centre facilities costs, OS and database licensing, administrative overhead, and traditional high availability infrastructure that often doubles deployment costs. For organisations running Oracle or SQL Server with active Software Assurance, the licensing economics alone can justify migration.
The breakeven analysis between Aurora and RDS depends primarily on database size and I/O patterns. Under 5TB with predictable I/O, RDS typically costs 15-25% less than Aurora provisioned instances. Between 5-10TB with moderate I/O, costs converge and Aurora’s operational advantages become decisive. Above 10TB with high I/O, Aurora I/O-Optimized frequently costs less than RDS with Multi-AZ whilst delivering superior performance and faster failover. For variable workloads with clear daily or weekly patterns, Aurora Serverless v2 can cost 40-50% less than provisioned instances whilst eliminating capacity planning overhead.

The economics of cross-region disaster recovery differ dramatically between platforms. Aurora Global Database provides up to 5 secondary regions with storage-level replication achieving RPO under 1 second and RTO under 1 minute. This architecture eliminates the logical replication lag that affects RDS cross-region read replicas, which typically maintain 5-30 second lag depending on transaction volume and network conditions. For applications requiring global distribution with local read performance, Aurora Global Database’s write forwarding capability allows applications in secondary regions to transparently forward writes to the primary region whilst maintaining local read latency.
Our analysis of AWS backup strategies explored how Aurora’s continuous backup architecture eliminates the traditional tension between backup frequency and I/O impact. Aurora takes continuous incremental backups to S3 without suspending database operations, whilst RDS takes daily snapshots from the standby instance in Multi-AZ configurations. Both services offer point-in-time recovery to any second within the retention period (1-35 days configurable), but Aurora’s approach provides more granular recovery capabilities for critical applications.
Disaster recovery capabilities differ fundamentally between options
Aurora Global Database architecture provides measurably better disaster recovery capabilities than traditional RDS cross-region replication. Storage-based replication achieves RPO under 1 second versus 5-30 second lag for logical replication. RTO targets under 1 minute for cross-region failover compare favourably to DNS propagation delays and application reconnection times that affect RDS read replica promotion.

Organisations can deploy 1 primary region plus up to 5 secondary regions with up to 90 reader instances total across the global cluster. Samsung leverages this architecture to serve their 1.1 billion Samsung Account users with localised read performance whilst maintaining data consistency globally. The write forwarding capability introduced in recent Aurora versions allows applications in secondary regions to send writes transparently to the primary region, simplifying application architecture for globally distributed systems.
RDS Multi-AZ DB Cluster using engine-native replication with 2 readable standbys achieves under 35 seconds failover with zero data loss. This represents significant improvement over traditional Multi-AZ’s 60-120 second window and positions RDS as credible for workloads where sub-30-second failover isn’t critical. RDS Proxy reduces effective failover times by maintaining connection pools that survive database instance changes, eliminating the DNS propagation and application reconnection delays that typically extend downtime beyond the database failover period.
For EC2 deployments, disaster recovery requires manual implementation of replication, failover scripts, and monitoring infrastructure. Patroni for PostgreSQL or similar clustering tools can achieve comparable results but demand significant DBA expertise and ongoing maintenance. Organisations running Oracle RAC gain clustering capabilities inherent in the platform, but configuration complexity and ongoing management overhead typically require dedicated database teams.
The backup and recovery capabilities are essentially equivalent between RDS and Aurora: both offer continuous automated backups with point-in-time recovery to any second within the retention period. Aurora’s continuous incremental approach to S3 operates without I/O suspension, whilst RDS takes daily snapshots from the standby instance in Multi-AZ configurations. Both platforms support manual snapshots for long-term retention and cross-region snapshot copy for geographic backup distribution.
UK enterprises face specific compliance and pricing considerations
UK region (eu-west-2 London) pricing runs approximately 10-20% higher than US East (N. Virginia), reflecting data centre operations costs and local market conditions. The region provides 3 Availability Zones with 682 EC2 instance types available as of January 2026. Data residency within UK borders is guaranteed when selecting eu-west-2, satisfying GDPR Article 44 requirements and UK Data Protection Act 2018 obligations for organisations processing UK citizen data.
Monzo Bank demonstrates the operational efficiency possible with AWS managed services, serving over 4 million customers with just 8 people on their infrastructure and reliability team. The challenger bank runs entirely on AWS, leveraging RDS and Aurora alongside other managed services to maintain regulatory compliance whilst scaling rapidly. The FCA’s 2015 guidelines for off-premises cloud services, combined with the FCA’s own AWS contract, established the regulatory precedent that subsequent challenger banks have followed. Starling Bank built their mobile-only platform on AWS from inception, joining Faster Payments as the 13th member in 2018.
NHS adoption is accelerating through the Cloud Centre of Excellence promoting cloud best practices across the health service. NHS Digital migrated the e-Referral Service handling 18 million referrals annually and the NHS 111 Directory of Services to AWS managed database platforms. The NHS England Skills Accelerator provides free AWS training for NHS employees across England, Wales, and Scotland, addressing the skills gap that previously impeded cloud adoption. These migrations demonstrate that healthcare data handling requirements under NHS Digital’s Data Security and Protection Toolkit are satisfiable with AWS managed services.
FCA guidance (FG 16/5) requires risk assessment before cloud outsourcing, effective access to data for regulators and auditors, and documented exit plans. The guidance doesn’t prohibit cloud services but demands appropriate due diligence and ongoing oversight. PRA supervisory statement SS2/21 implements EBA Guidelines on outsourcing and third-party risk management, effective since March 2022. The Critical Third Party regime published November 2024 adds expectations for cloud providers serving financial services but explicitly doesn’t replace firm accountability for risk management.
The UK-US Data Bridge effective October 2023 simplifies transatlantic transfers for organisations using Data Privacy Framework-certified US entities, though financial services organisations may need alternative mechanisms under FCA requirements. Post-Brexit UK-EU transfers remain straightforward following the EU adequacy decision of June 2021, though organisations should monitor ongoing adequacy review processes. For database deployments, selecting eu-west-2 as the primary region with cross-region disaster recovery to eu-west-1 (Ireland) maintains all data processing within regions covered by UK GDPR.
The Cloud Computing for Business Leaders guide we developed previously addresses the strategic considerations that CTOs and CIOs face when evaluating managed database services. The shift from capital expenditure to operational expenditure models affects not just budgeting but procurement processes, vendor management, and risk frameworks that boards scrutinise.
A decision framework for enterprise database platform selection
The optimal choice depends on five primary factors: database scale, availability requirements, operational capacity, compliance constraints, and cost predictability tolerance.

Choose Aurora when databases exceed 10TB or are projected to reach this scale within 24 months. The platform handles sub-30-second failover requirements that affect user experience for customer-facing applications. Read scaling demands exceeding 5 replicas indicate Aurora’s architecture advantage over RDS read replica limits. I/O-intensive workloads where I/O costs exceed 25% of total database spend justify Aurora I/O-Optimized configuration. Global distribution requirements with sub-second replication across regions leverage Aurora Global Database capabilities. Limited DBA resources make Aurora’s operational simplicity worthwhile despite higher per-instance costs.
Choose RDS when databases remain under 5TB with predictable growth trajectories. Standard Multi-AZ resilience providing 60-120 second failover meets application availability requirements. Workloads exhibit predictable I/O patterns that don’t trigger unpredictable I/O billing. Cost predictability takes priority over optimal efficiency in budget planning. Development and staging environments where Aurora’s free tier offering provides cost advantages for non-production workloads.
Choose EC2 self-managed databases when Oracle RAC or SQL Server Always On with specific licensing arrangements are mandatory. Compliance requirements demand OS-level controls, custom encryption implementations, or audit logging capabilities unavailable in managed services. Exotic database engines or versions unsupported by RDS are necessary for legacy application support. Strong DBA expertise exists in-house and infrastructure cost minimisation justifies operational overhead. Multi-database consolidation onto shared infrastructure provides economies of scale that offset management complexity.
The decision framework should also consider migration complexity and risk. Aurora’s MySQL and PostgreSQL compatibility enables relatively straightforward migrations from open-source databases, whilst commercial database migrations from Oracle or SQL Server introduce schema conversion complexity that AWS Schema Conversion Tool can partially automate. Organisations running multiple database platforms should prioritise standardisation benefits alongside technical capabilities.
Strategic recommendations for 2026 database platform decisions
Aurora’s technical advantages now translate directly to measurable business outcomes validated by enterprise deployments. Samsung’s 44% cost reduction whilst serving 1.1 billion users, Netflix’s 75% latency improvement across their platform, and DraftKings’ million-operations-per-minute throughput demonstrate Aurora’s capabilities at extreme scale. The 99.99% availability SLA versus RDS’s 99.95% provides measurably better resilience for mission-critical applications where downtime directly affects revenue.
For organisations processing financial transactions, healthcare data, or serving global users, Aurora Global Database’s sub-second RPO eliminates the traditional tension between performance and disaster recovery. The Limitless Database feature announced in 2024 extends Aurora PostgreSQL to millions of write transactions per second for organisations hitting single-cluster limits, though this capability remains in preview as of January 2026.
RDS remains the rational choice for moderate-scale workloads where cost predictability matters more than optimal performance characteristics. The platform’s maturity and operational stability suit organisations with traditional change management processes and quarterly release cycles. The gap is closing as Aurora Serverless v2 becomes more cost-effective for variable workloads, but RDS maintains advantages for steady-state applications with well-understood capacity requirements.
EC2-based databases should be reserved for genuine technical requirements rather than cost optimisation, as operational overhead typically exceeds infrastructure savings except at very large scale with dedicated operations teams. Specific licensing requirements for Oracle RAC, compliance configurations demanding OS-level access, or unsupported database engines justify the complexity. Infrastructure cost minimisation alone rarely justifies the operational burden unless strong DBA expertise exists and database standardisation enables economies of scale.
UK enterprises benefit from proven adoption patterns at Monzo, Starling Bank, and NHS organisations, with clear regulatory guidance from FCA and PRA on cloud outsourcing. The approximately 15% premium for eu-west-2 over US regions is offset by data residency certainty and reduced cross-border transfer complexity under GDPR and UK data protection law. For financial services firms, the FCA’s own AWS adoption provides regulatory air cover that reduces compliance risk perception.
The database platform decision directly affects application architecture patterns, operational procedures, and skills requirements that persist for years after initial deployment. Organisations should evaluate not just current requirements but anticipated growth, regulatory changes, and skills availability when making this strategic choice.
Useful Links
- Amazon Aurora Pricing – Official AWS Aurora pricing documentation including I/O-Optimized configurations and Serverless v2 pricing
- Amazon RDS Pricing – Complete RDS pricing for all database engines, Reserved Instances, and Extended Support costs
- AWS Database Migration Service – Migration planning and execution tools for moving databases to AWS managed services
- Aurora Global Database Documentation – Technical implementation guide for cross-region Aurora deployments
- RDS Blue/Green Deployments – Guide to zero-downtime database updates and major version upgrades
- AWS Well-Architected Framework – Reliability Pillar – Best practices for database resilience and disaster recovery
- AWS Compliance Programs – Certifications and compliance frameworks supported by AWS including PCI-DSS, HIPAA, SOC 2
- Aurora Serverless v2 Best Practices – AWS blog post on optimising Aurora Serverless v2 for cost and performance








