Aurora vs RDS: When to Choose Amazon Aurora (Architecture and Cost)

Choosing between Amazon Aurora and standard RDS isn’t straightforward. Aurora promises 5x MySQL and 3x PostgreSQL performance, automatic storage scaling to 128TB, and 99.99% availability. But it comes with additional complexity and cost that can surprise teams unfamiliar with its I/O pricing model.

The decision comes down to workload characteristics, operational requirements, and cost constraints. For a production MySQL or PostgreSQL workload that needs high availability or more than five read replicas, Aurora Standard is the sensible default. Switch to I/O-Optimized once I/O passes roughly a quarter of the bill, and stay on RDS when the engine is something else, or when the workload is small, predictable, and budget-bound.

What is Amazon Aurora?#

Amazon Aurora is a cloud-native relational database engine compatible with MySQL and PostgreSQL. Unlike standard RDS which runs vanilla databases on cloud infrastructure, Aurora was built from scratch to leverage distributed cloud architecture.

Key Architectural Differences:

• Storage Separation: Compute (database instances) separated from storage (distributed layer)
• Automatic Scaling: Storage grows from 10GB to 128TB in 10GB increments, no downtime
• Built-in Replication: 6 copies of data across 3 Availability Zones by default
• Limited Engine Support: Only MySQL and PostgreSQL (Aurora doesn’t support other engines)

Where Aurora Sits Among AWS Database Services#

Aurora is one of many AWS database services, each designed for a specific access pattern.

Relational Databases (SQL)#

Service	Engines	Best For
Amazon RDS	MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2	Standard relational workloads, broad engine compatibility
Amazon Aurora	MySQL, PostgreSQL only	High availability, read-heavy workloads, cloud-native features
Amazon Redshift	PostgreSQL-based	Data warehousing, analytics, OLAP workloads

NoSQL Databases#

Service	Type	Best For
Amazon DynamoDB	Key-value, Document	Serverless apps, gaming, IoT, single-digit millisecond latency
Amazon DocumentDB	Document (MongoDB-compatible)	MongoDB workloads, JSON document storage
Amazon Keyspaces	Wide-column (Cassandra-compatible)	Cassandra migrations, time-series data
Amazon Neptune	Graph	Social networks, fraud detection, knowledge graphs
Amazon Timestream	Time-series	IoT metrics, DevOps monitoring, application telemetry

In-Memory and Caching#

Service	Type	Best For
Amazon ElastiCache	Redis, Memcached	Caching, session storage, real-time analytics
Amazon MemoryDB	Redis-compatible	Durable in-memory database, microsecond reads

Specialized Services#

Service	Purpose
Amazon QLDB	Immutable ledger, audit trails, cryptographic verification
Amazon OpenSearch	Full-text search, log analytics, application monitoring

When NOT to Choose Aurora#

• Need SQL Server, Oracle, or Db2? → Use RDS (Aurora doesn’t support these)
• Need document storage with MongoDB compatibility? → Use DocumentDB
• Need key-value with single-digit ms latency at scale? → Use DynamoDB
• Need data warehousing/analytics? → Use Redshift
• Need graph relationships? → Use Neptune
• Need time-series data? → Use Timestream

Aurora’s Distributed Storage Architecture#

Aurora’s storage layer uses Protection Groups - 10GB segments replicated six ways across three availability zones. This design enables fast recovery and high availability without the overhead of traditional replication.

Quorum-Based Writes: Aurora requires 4 out of 6 acknowledgments for writes to commit. This means it can tolerate losing an entire availability zone plus one additional copy without affecting write availability.

Redo Log Architecture: Aurora only sends redo logs to storage, not full data pages. This reduces write amplification significantly compared to traditional databases that write full pages plus transaction logs.

Self-Healing Storage: The storage layer automatically detects and repairs disk failures, typically recovering a 10GB segment in under one minute without any manual intervention.

Aurora vs RDS: Technical Comparison#

Aspect	RDS (MySQL/PostgreSQL)	Aurora
Storage	EBS volumes attached to instances	Distributed storage layer (6 copies, 3 AZs)
Storage Scaling	Manual, requires downtime	Automatic, up to 128TB, no downtime
Replication	Binary/streaming (5 replicas max)	Log-based, shared storage (15 replicas max)
Replica Lag	Can be seconds to minutes	Typically milliseconds
Write Method	Full page writes + double-write buffer	Redo log only
Failover Time	1-2 minutes (DNS-based)	30-120 seconds, faster with AWS drivers
HA SLA	99.95% (Multi-AZ)	99.99%
Backup Impact	I/O pause during snapshot	Continuous, no performance impact

Write Performance Characteristics#

Aurora’s redo-log-only approach reduces the number of I/O operations for writes. Traditional databases write:

1. Data page to storage
2. Transaction log to storage
3. Data page to double-write buffer (MySQL)

Aurora writes only the redo log entry. The storage layer applies these changes asynchronously, reducing write amplification from 5-7x to approximately 1x for many workloads.

When to Choose Aurora vs RDS#

Choose Aurora When:#

• High availability matters: a 99.99% uptime SLA against Multi-AZ RDS’s 99.95%, sub-minute failover, and a business that genuinely can’t absorb a 1-2 minute database outage.
• Read-heavy services that need more than five read replicas, or replication lag in the low milliseconds because read traffic significantly outweighs writes, draw real value from Aurora’s shared storage layer.
• Storage growth that’s hard to forecast removes a maintenance ticket: teams that don’t want to manage provisioning, that expect unpredictable spikes, or that want to avoid over-provisioning storage costs get automatic scaling instead.
• Multi-region reads or failover are required. Cross-region replication with sub-second lag, fast disaster recovery, and global read distribution are what Aurora Global Database exists for.
• Daily traffic that moves 10x, or non-production environments that shouldn’t cost anything when nobody’s using them, is what Serverless v2’s auto-scaling and scale-to-zero handle.

Choose RDS When:#

RDS fits cost-sensitive projects best: a predictable, low-to-moderate workload where the Aurora premium isn’t justified and I/O patterns stay well under the threshold that triggers high Aurora costs. It also covers broader engine requirements, SQL Server, Oracle, MariaDB, or Db2, or an application already tied to a non-Aurora-compatible engine. For single-AZ development or testing environments, basic backup and restore is enough and nothing advanced is needed. Low I/O workloads (predictable patterns under 1 billion requests/month) run well on standard storage and IOPS provisioning, without Aurora’s I/O cost trap.

Decision Framework#

Quick Reference:

• Orange (RDS): Best for non-MySQL/PostgreSQL engines or budget-constrained low-I/O workloads
• Blue (Aurora Standard): Where most production MySQL/PostgreSQL workloads land
• Purple (Aurora I/O-Optimized): When I/O costs exceed 25% of your Aurora bill

Cost Analysis and the I/O Trap#

Aurora’s pricing has three components: compute, storage, and I/O. The I/O component often surprises teams making their first migration.

Pricing Breakdown#

Aurora Standard:

• Instance: Same price as equivalent RDS instance type
• Storage: $0.10/GB-month (pay for what you use)
• I/O: $0.20 per million requests
• Backups: First backup free (cluster storage size), additional at $0.021/GB-month

Aurora I/O-Optimized (introduced 2023):

• Instance: 30% more expensive than Standard
• Storage: $0.225/GB-month (2.25x Standard)
• I/O: $0 (included)
• Backups: Same as Standard

The I/O Cost Trap Explained#

Many teams estimate Aurora costs using instance and storage pricing, then get surprised by I/O charges. A production workload can easily generate 50-100 billion I/O requests per month.

Example Calculation:

interface AuroraConfig {
  instanceType: string;
  storageGB: number;
  monthlyIORequests: number;
}

interface CostBreakdown {
  compute: number;
  storage: number;
  io: number;
  total: number;
}

function calculateAuroraCost(
  config: AuroraConfig,
  optimized: boolean = false
): CostBreakdown {
  // Example pricing for us-east-1
  const instancePricing: Record<string, number> = {
    'db.r6g.2xlarge': optimized ? 0.806 : 0.62, // per hour
  };

  const storagePricing = optimized ? 0.225 : 0.10; // per GB-month
  const ioPricing = optimized ? 0 : 0.20; // per million requests

  const hoursPerMonth = 730;

  const computeCost = instancePricing[config.instanceType] * hoursPerMonth;
  const storageCost = config.storageGB * storagePricing;
  const ioCost = optimized ? 0 : (config.monthlyIORequests / 1_000_000) * ioPricing;

  return {
    compute: computeCost,
    storage: storageCost,
    io: ioCost,
    total: computeCost + storageCost + ioCost
  };
}

// Example: High I/O workload
const highIOWorkload: AuroraConfig = {
  instanceType: 'db.r6g.2xlarge',
  storageGB: 2000,
  monthlyIORequests: 50_000_000_000, // 50 billion I/O requests
};

const standardCost = calculateAuroraCost(highIOWorkload, false);
const optimizedCost = calculateAuroraCost(highIOWorkload, true);

console.log('Aurora Standard:', standardCost);
// { compute: 452.6, storage: 200, io: 10000, total: 10652.6 }

console.log('Aurora I/O-Optimized:', optimizedCost);
// { compute: 588.38, storage: 450, io: 0, total: 1038.38 }

// Rule of thumb: Switch to I/O-Optimized when I/O > 25% of total cost
const ioPercentage = (standardCost.io / standardCost.total) * 100;
console.log(`I/O is ${ioPercentage.toFixed(1)}% of total cost`);
// I/O is 93.9% of total cost - definitely use I/O-Optimized!

Cost Optimization Strategies#

1. Monitor I/O Metrics from Day One Track VolumeReadIOPs and VolumeWriteIOPs in CloudWatch immediately after migration. These metrics report measured consumption, so they replace the guesswork in your cost model.

2. Increase Buffer Cache Larger instances with more memory reduce I/O by improving cache hit ratios. Sometimes paying for a larger instance saves money on I/O costs.

3. Query Optimization Reduce unnecessary I/O through better indexing, query optimization, and avoiding full table scans.

4. Switch to I/O-Optimized Strategically When I/O costs exceed 25% of total Aurora bill, I/O-Optimized almost always costs less. Use AWS Compute Optimizer to get specific recommendations.

5. Serverless v2 for Variable Workloads For development and staging, Serverless v2 with a 0 ACU minimum (November 2024 feature) drops the compute charge to zero during idle hours. Storage and backups keep billing, and I/O still counts under Standard, so the idle cost shrinks rather than disappears. The pricing example further down compares compute only and lands about 77% below an equivalent provisioned instance.

Aurora Serverless v2#

Aurora Serverless v2 addresses the scaling limitations of traditional provisioned instances with automatic capacity adjustment based on actual load.

Key Features (2024/2025 Updates)#

• Instant Scaling to 256 ACUs (October 2024): Previously limited to 128 ACUs
• Scale to 0 ACUs (November 2024): Previously minimum was 0.5 ACU
• Fine-Grained Scaling: Adjusts in 0.5 ACU increments
• Full Feature Support: Works with Global Database, Performance Insights, and all Aurora features

1 ACU = approximately 2GB of memory + proportional CPU and network bandwidth

Serverless v2 Configuration#

import * as rds from 'aws-cdk-lib/aws-rds';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

const serverlessCluster = new rds.DatabaseCluster(this, 'ServerlessCluster', {
  engine: rds.DatabaseClusterEngine.auroraPostgres({
    version: rds.AuroraPostgresEngineVersion.VER_16_1,
  }),
  vpc,
  writer: rds.ClusterInstance.serverlessV2('writer', {
    autoMinorVersionUpgrade: true,
  }),
  readers: [
    rds.ClusterInstance.serverlessV2('reader1', {
      scaleWithWriter: true, // Reader scales with writer
    }),
  ],
  serverlessV2MinCapacity: 0, // Scale to zero (Nov 2024 feature)
  serverlessV2MaxCapacity: 256, // Up to 256 ACUs (Oct 2024 feature)
});

// Note: 0 ACU minimum requires PostgreSQL 13.15+, 14.12+, 15.7+, 16.3+
// or MySQL 3.08+

Use Cases for Serverless v2#

1. Variable/Unpredictable Workloads E-commerce during flash sales, seasonal applications, or marketing campaign traffic spikes.

2. Development and Staging Environments Scale to 0 when not in use. A development database used 8 hours/day, 5 days/week saves about 77% on compute costs.

3. Multi-Tenant SaaS Per-tenant databases with independent scaling. Each tenant’s database scales based on their actual usage.

4. Infrequent Batch Jobs Data processing that runs daily or weekly. Scale to minimum between runs.

Pricing Example#

// Serverless v2 pricing (us-east-1)
const acuPricePerHour = 0.12; // PostgreSQL

// Example: Dev environment
// Used 8 hours/day, 5 days/week at average 2 ACUs
// Scales to 0 ACUs when not in use

const monthlyHoursActive = 8 * 5 * 4.33; // ~173 hours/month
const avgACUs = 2;

const serverlessV2Cost = monthlyHoursActive * avgACUs * acuPricePerHour;
// = 173 * 2 * 0.12 = $41.52/month

// Equivalent provisioned instance (db.r6g.large = 2 ACUs equivalent)
const provisionedCost = 730 * 0.246; // $179.58/month

const savings = ((provisionedCost - serverlessV2Cost) / provisionedCost) * 100;
// = 76.9% savings

Migration from RDS to Aurora#

Migration Methods#

1. Aurora Read Replica (Recommended - Minimal Downtime)

This method creates an Aurora read replica from your existing RDS instance, then promotes it to a standalone cluster.

# Step 1: Create Aurora Read Replica from RDS MySQL instance
aws rds create-db-instance-read-replica \
    --db-instance-identifier myapp-aurora-replica \
    --source-db-instance-identifier myapp-rds-mysql \
    --db-instance-class db.r6g.2xlarge \
    --engine aurora-mysql

# Step 2: Monitor replication lag
aws cloudwatch get-metric-statistics \
    --namespace AWS/RDS \
    --metric-name AuroraReplicaLag \
    --dimensions Name=DBInstanceIdentifier,Value=myapp-aurora-replica \
    --start-time 2025-11-29T00:00:00Z \
    --end-time 2025-11-29T01:00:00Z \
    --period 60 \
    --statistics Average

# Step 3: Promote Aurora replica when lag approaches zero
aws rds promote-read-replica-db-cluster \
    --db-cluster-identifier myapp-aurora-cluster

Downtime: 15-30 minutes during promotion and application cutover

2. Snapshot Migration

Restore an RDS snapshot as an Aurora cluster. Faster for large databases but requires downtime during cutover.

aws rds restore-db-cluster-from-snapshot \
    --db-cluster-identifier myapp-aurora \
    --snapshot-identifier myapp-rds-snapshot \
    --engine aurora-postgresql \
    --engine-version 16.1

Downtime: Full duration of snapshot restore plus testing time

3. AWS DMS (Database Migration Service)

Most flexible but most complex. Good for cross-account, cross-VPC, or when converting encrypted/unencrypted databases.

4. pg_dump/mysqldump

Simple but slow. Only practical for databases under 500GB.

Pre-Migration Checklist#

• Verify Aurora supports your RDS engine version
• Estimate I/O costs using CloudWatch metrics
• Test application with Aurora in staging environment
• Plan connection pooling strategy (consider RDS Proxy)
• Document rollback procedure
• Disable auto minor version upgrades on RDS
• Schedule migration during low-traffic period
• Prepare monitoring and alerting for new Aurora cluster

Global Database for Multi-Region#

Aurora Global Database provides cross-region replication with sub-second lag, enabling global read distribution and fast disaster recovery.

Architecture#

• 1 Primary Region: Accepts read and write traffic
• Up to 10 Secondary Regions: Read-only (increased from 5 in May 2025)
• Typical Replication Lag: Less than 1 second
• Dedicated Infrastructure: Replication doesn’t use public internet

Global Database Setup#

import * as rds from 'aws-cdk-lib/aws-rds';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

// Primary region (us-east-1)
const primaryCluster = new rds.DatabaseCluster(this, 'PrimaryCluster', {
  engine: rds.DatabaseClusterEngine.auroraPostgres({
    version: rds.AuroraPostgresEngineVersion.VER_16_1,
  }),
  vpc: primaryVpc,
  writer: rds.ClusterInstance.provisioned('writer', {
    instanceType: ec2.InstanceType.of(ec2.InstanceClass.R6G, ec2.InstanceSize.XLARGE2),
  }),
});

// Create global database
const globalCluster = new rds.CfnGlobalCluster(this, 'GlobalCluster', {
  globalClusterIdentifier: 'myapp-global',
  sourceDbClusterIdentifier: primaryCluster.clusterArn,
  engine: 'aurora-postgresql',
  engineVersion: '16.1',
});

// Secondary region (eu-west-1) - deployed in separate stack
const secondaryCluster = new rds.DatabaseCluster(secondaryStack, 'SecondaryCluster', {
  engine: rds.DatabaseClusterEngine.auroraPostgres({
    version: rds.AuroraPostgresEngineVersion.VER_16_1,
  }),
  vpc: secondaryVpc,
  writer: rds.ClusterInstance.provisioned('writer', {
    instanceType: ec2.InstanceType.of(ec2.InstanceClass.R6G, ec2.InstanceSize.XLARGE2),
  }),
});

// Attach secondary to global database
new rds.CfnDBCluster(secondaryStack, 'SecondaryAttach', {
  globalClusterIdentifier: 'myapp-global',
  dbClusterIdentifier: secondaryCluster.clusterIdentifier,
});

Failover Capabilities#

Planned Switchover (Managed):

• Zero data loss
• Maintains cluster topology
• Use case: Regional rotation, compliance requirements

Unplanned Failover:

• Promotes secondary to primary in approximately 1 minute
• Potential data loss depends on replication lag at failure time
• RPO typically seconds, RTO approximately 1 minute

Cost Considerations#

Global Database adds cost in several areas, and it’s worth implementing only when business requirements genuinely need multi-region active-active reads or sub-minute regional failover:

• Cross-region data transfer charges
• Storage replicated to all regions
• Instance costs in each region
• I/O charges in each region (Standard) or increased instance costs (I/O-Optimized)

Connection Management with RDS Proxy#

Aurora’s fast failover capabilities work best when combined with intelligent connection management. RDS Proxy provides connection pooling and handles failover transparently.

import * as rds from 'aws-cdk-lib/aws-rds';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as cdk from 'aws-cdk-lib';

const proxy = new rds.DatabaseProxy(this, 'AuroraProxy', {
  proxyTarget: rds.ProxyTarget.fromCluster(auroraCluster),
  secrets: [auroraCluster.secret!],
  vpc,
  dbProxyName: 'myapp-aurora-proxy',
  // Connection pooling configuration
  maxConnectionsPercent: 90,
  maxIdleConnectionsPercent: 50,
  connectionBorrowTimeout: cdk.Duration.seconds(120),
  // Session pinning filters - avoid unnecessary pinning
  sessionPinningFilters: [
    rds.SessionPinningFilter.EXCLUDE_VARIABLE_SETS,
  ],
  requireTLS: true,
});

// Application connects to proxy endpoint instead of cluster endpoint
const proxyEndpoint = proxy.endpoint;

Benefits:

• Maintains connection pool across Lambda invocations
• Handles failover without application-level retry logic
• Reduces database connections by 90%+ for serverless workloads
• Enforces IAM authentication for additional security

When RDS Proxy is Essential:

• Serverless applications (Lambda functions)
• Applications with connection storms
• Microservices with many independent services
• Multi-tenant applications with per-tenant connection patterns

Where Aurora Deployments Break in Production#

1. DNS Caching Issues#

Applications that cache the database endpoint’s DNS too long fail to reconnect after a failover. A resolver TTL under 30 seconds, checked against a real failover test in staging, is what catches this before production does.

// Node.js DNS cache configuration
import dns from 'dns';
dns.setDefaultResultOrder('ipv4first');

// Use connection library that respects DNS TTL
import { Pool } from 'pg';
const pool = new Pool({
  host: process.env.DB_HOST,
  // Don't cache connections indefinitely
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 3000,
});

2. Wrong Instance Class Selection#

Production workloads over 40TB sometimes end up on t2/t3/t4g burstable instances, which hold up fine in development but can’t sustain the consistent performance production needs; r6g or r6i instance families are the safer choice there.

3. Replica Lag from CPU Credit Exhaustion#

T-instance read replicas run out of CPU credits, so replication lag climbs and the instances eventually restart. The CPUCreditBalance metric flags the exhaustion early; non-burstable instance types avoid the problem altogether on production read replicas.

4. Connection Exhaustion#

Serverless applications can create thousands of short-lived connections that exhaust the database’s connection limit, and for Lambda specifically the fix is close to mandatory: RDS Proxy or application-side connection pooling.

5. Parallel Query Cost Spike#

Enabling parallel query increases I/O costs unexpectedly because it bypasses the buffer cache; VolumeReadIOPs is worth watching right after turning it on. I/O-Optimized absorbs the spike when parallel query is critical for the workload.

6. CloudFormation Data Loss Risk#

CloudFormation stack updates can recreate instances and potentially lose data in the process, which is why database resources need DeletionPolicy: Retain and change sets deserve a careful read before applying them.

7. Binary Logging Performance#

Large transactions (1M+ inserts) become very slow with binary logging enabled. Batch them into smaller transactions (10K-50K inserts), or disable binary logging if point-in-time recovery isn’t required.

Monitoring and Operations#

Key Metrics to Monitor#

Performance Metrics:

• CPUUtilization: Target less than 80% average
• DatabaseConnections: Monitor against max_connections setting
• BufferCacheHitRatio: Target greater than 95%
• AuroraReplicaLag: Target less than 100ms

I/O and Storage Metrics:

• VolumeReadIOPs, VolumeWriteIOPs: Watch for cost spikes
• VolumeBytesUsed: Tracks automatic storage growth
• DiskQueueDepth: Indicates I/O bottlenecks

Availability Metrics:

• FailoverLatency: Measure actual failover time
• DeadlockCount: Application design issues
• CommitLatency: Write performance

Operational Best Practices#

1. Enable Enhanced Monitoring Provides OS-level metrics (memory, CPU, disk I/O) at 1-second granularity. Critical for production troubleshooting.

2. Use Performance Insights Query-level analysis shows which queries consume resources. Free tier includes 7 days of retention.

3. Set CloudWatch Alarms Alert on key metrics before they become problems:

• CPU > 80% for 5 minutes
• Replica lag > 1 second
• Connections > 80% of max_connections
• BufferCacheHitRatio < 90%

4. Test Failover Quarterly Regular failover testing validates your actual RTO. Many teams discover DNS caching or connection pool issues only during production incidents.

5. Use AWS Compute Optimizer Provides rightsizing recommendations based on actual usage patterns. Can identify opportunities to switch to I/O-Optimized or downsize instances.

When Aurora Is Worth It#

The boundary runs along engine support, workload size, and I/O share. Production MySQL and PostgreSQL clusters that need sub-minute failover, more than five read replicas, or storage that grows without a maintenance window belong on Aurora Standard; once VolumeReadIOPs and VolumeWriteIOPs push I/O past a quarter of the bill, move to I/O-Optimized, and for environments that sit idle most of the week, Serverless v2 fits better than either.

Cross that boundary the other way when the engine has to be Oracle, SQL Server, MariaDB, or Db2, when the workload is small and predictable enough that provisioned RDS storage and IOPS already fit, or when a purpose-built service such as DynamoDB, Redshift, or Neptune matches the access pattern better than any relational engine. The 5x MySQL and 3x PostgreSQL figures are AWS’s own benchmarks.

The cheapest first step is a week of CloudWatch I/O data from the existing RDS instance. That number decides the pricing mode and, often, whether the migration is worth running at all.

References#

• What is Amazon Aurora? (opens in new tab) - Official overview of Aurora’s architecture, cluster model, and compatibility with MySQL and PostgreSQL
• Amazon Aurora Storage and Reliability (opens in new tab) - Detailed explanation of Aurora’s distributed storage layer and six-way replication across Availability Zones
• High Availability for Amazon Aurora (opens in new tab) - Aurora failover mechanisms, read replica promotion, and multi-AZ cluster behavior
• Amazon Aurora Product Page (opens in new tab) - Feature overview, pricing model options, and comparison with standard RDS
• Amazon Aurora DB Clusters (opens in new tab) - Primary and reader instance roles, endpoint types, and cluster volume management
• Amazon RDS Proxy Documentation (opens in new tab) - Connection pooling proxy for Aurora, essential for serverless and Lambda-based workloads