AWS DMS: Database Migration Service Guide for MySQL and PostgreSQL

At 2:47 AM on a Tuesday, a Series C fintech's lead engineer opened a Slack incident channel: their primary RDS PostgreSQL 14 instance had just failed, and the read replica had not yet been promoted. Twenty-two minutes later, after frantic manual intervention, writes were back. The post-mortem revealed the real cost: not just 22 minutes of downtime, but $340,000 in delayed payment processing, a compliance flag from their banking partner, and a mandatory architectural review. Their PostgreSQL instance was on a single-AZ RDS deployment with a manually managed standby. Three weeks later, they were on Amazon Aurora PostgreSQL. The next failure — a host replacement triggered by AWS six months later — lasted 28 seconds. Their on-call engineer slept through it.

This post covers what makes Aurora PostgreSQL architecturally different from standard RDS PostgreSQL, which features matter in production, how to configure it correctly, and when Aurora's complexity and cost premium are genuinely justified.

Background: Why Aurora Exists

Amazon RDS PostgreSQL is managed PostgreSQL running on a conventional architecture: a primary EC2 instance writes to EBS storage, and a standby replica is kept in sync via streaming WAL replication. This model works well, but it has a fundamental constraint: the I/O path runs through a single host, and storage is tied to a single EBS volume per instance. Network I/O between compute and storage, EBS throughput limits, and the latency of WAL replication to a standby all compound at scale.

Aurora was Amazon's answer to these constraints. It decouples compute from storage entirely, replacing the EBS-backed model with a purpose-built, distributed storage service. From a PostgreSQL client's perspective, the database speaks standard PostgreSQL wire protocol and accepts standard SQL. Under the hood, almost everything about how writes reach durable storage is different.

Aurora Architecture: How the Storage Layer Works

Six-Way Replication Across Three AZs

When a write is committed on Aurora, the primary instance does not write to a local disk. Instead, it sends log records to Aurora's distributed storage fleet. That fleet writes the data to six storage nodes — two in each of three Availability Zones — and acknowledges the write to the primary once four out of six nodes confirm receipt. This means Aurora can survive the simultaneous loss of an entire AZ plus one additional storage node and still complete writes without data loss.

The storage layer is also self-healing. Storage nodes continuously gossip with each other. If a node detects that a peer is behind, it requests the missing log segments and repairs itself in the background. The primary instance never needs to re-send the data; the storage fleet handles its own consistency. This is a fundamentally different durability model than streaming WAL replication, where the primary must retransmit to a replica that fell behind.

Write Path: No Local I/O

On standard PostgreSQL, a write follows this path: WAL write to disk on the primary → fsync → WAL shipped to replica → replica applies WAL → replica fsyncs. On Aurora, the primary writes log records to the distributed storage layer and receives the quorum acknowledgment. There is no local WAL fsync on the primary. The primary does not maintain a local data directory in the traditional sense — it reads pages on demand from the storage layer and caches them in shared_buffers.

This architecture has a concrete performance implication: Aurora write latency is lower than equivalent RDS PostgreSQL at high I/O rates because the write I/O path is entirely network-based to a purpose-optimized storage fleet, not bottlenecked by a single EBS volume's IOPS limit.

Storage Autoscaling

Aurora storage grows automatically in 10 GB increments, up to 128 TiB. There is no need to provision storage capacity in advance or modify the instance to resize the volume. Storage is billed per GB consumed (not allocated), which means a database that uses 40 GB pays for 40 GB — not the 500 GB you might pre-provision on RDS to avoid a resize operation during peak traffic.

Aurora Reader Endpoints

An Aurora cluster exposes two built-in endpoints: a writer endpoint (always routes to the primary) and a reader endpoint (load-balances across all available Aurora Replicas). Aurora Replicas receive page updates from the shared storage layer with typical replica lag of single-digit milliseconds — significantly lower than streaming WAL replication on standard RDS, where replica lag depends on WAL volume and network throughput.

Reader Replicas on Aurora can be promoted to primary in approximately 30 seconds. During promotion, the new primary simply starts accepting writes to the same shared storage volume — it does not need to replay a backlog of WAL, because all replicas are already reading from the same storage layer. This is the architectural basis for Aurora's fast failover.

Key Features Worth Understanding

Aurora Global Database

Aurora Global Database adds a second level of replication: from the primary AWS region to one or more secondary regions. The secondary region receives storage-level redo log updates, bypassing the compute layer entirely. Typical replication lag is under one second even to geographically distant regions.

Common use cases: active-passive disaster recovery with sub-second RPO, compliance requirements mandating cross-region data residency, and serving low-latency reads to users in a second continent. In a failover scenario, the secondary region can be promoted to primary in under a minute.

-- Check replication lag across Global Database instances
-- Run on the primary cluster
SELECT
    server_id,
    session_id,
    aws_region,
    durable_lsn,
    highest_lsn_rcvd,
    feedback_epoch,
    log_delay_duration
FROM aurora_global_db_instance_status();

Aurora Serverless v2

Aurora Serverless v2 replaces the fixed instance class model with Aurora Capacity Units (ACUs). One ACU provides approximately 2 GB of memory and proportional CPU. You set a minimum and maximum ACU range, and Aurora scales the compute tier within that range within seconds in response to load.

Serverless v2 is not the same as the original Aurora Serverless v1, which had multi-second scale-up latency and could not support read replicas or Global Database. Serverless v2 supports all standard Aurora features including reader endpoints, Global Database, and Aurora Parallel Query.

# Example Aurora Serverless v2 scaling range via AWS CLI
aws rds modify-db-cluster \
  --db-cluster-identifier my-aurora-cluster \
  --serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=64 \
  --apply-immediately

Aurora Parallel Query

Aurora Parallel Query pushes analytical query processing down to the storage layer, allowing the storage nodes to filter and aggregate data before returning results to the compute tier. For large sequential scans — common in reporting workloads — Parallel Query can reduce query time by 100x on datasets that do not fit in shared_buffers. It is enabled per-session or per-query through the aurora_parallel_query parameter.

-- Enable Parallel Query for a session
SET aurora_parallel_query = ON;

-- Verify it is being used in a query plan
EXPLAIN SELECT region, SUM(order_total)
FROM orders
WHERE order_date >= '2025-01-01'
GROUP BY region;
-- Look for "Parallel query (4 columns) Pushed down" in the plan output

Configuration Best Practices

Parameter Groups: Aurora-Specific Settings

Aurora uses a two-level parameter group system: cluster parameter groups (applied to all instances in the cluster) and instance parameter groups (applied per instance). Aurora-specific parameters only appear in Aurora parameter groups and are not available on standard RDS PostgreSQL.

# Key Aurora PostgreSQL cluster parameter group settings

# Enable Parallel Query (set to 1 to allow it; still requires SET per-session)
aurora_parallel_query = 1

# Control the maximum number of log records sent per write I/O operation
# Default is fine for most workloads; tune only under AWS guidance
aurora_wal_milliseconds = 200

# Enable Aurora machine learning integration (if using Bedrock/SageMaker)
aws_default_comprehend_role = arn:aws:iam::123456789:role/AuroraMLRole

Connection Pooling with RDS Proxy

Aurora PostgreSQL connections are expensive to establish — each connection creates a backend process. For serverless applications, Lambda functions, or microservices that open many short-lived connections, RDS Proxy sits between the application and Aurora and multiplexes client connections to a smaller pool of backend connections. This prevents the connection storm problem that is common when Lambda functions scale from zero to hundreds of concurrent executions.

# RDS Proxy typical configuration via AWS console or CloudFormation
# Target: Aurora PostgreSQL cluster endpoint
# Idle client connection timeout: 1800 seconds
# Connection borrow timeout: 120 seconds
# Max connections percent: 100  (proxy manages the pool; set per workload)
# InitQuery: SET search_path = myapp, public;

Monitoring Aurora-Specific Activity

Aurora adds views that expose cluster-level information not available in standard PostgreSQL system catalogs.

-- Enhanced activity view (includes Aurora replication state)
SELECT
    pid,
    usename,
    application_name,
    client_addr,
    state,
    wait_event_type,
    wait_event,
    query_start,
    now() - query_start AS query_age,
    LEFT(query, 120) AS query_preview
FROM aurora_stat_activity()
WHERE state != 'idle'
ORDER BY query_start;

-- Storage-level I/O statistics per table
SELECT
    relname,
    heap_blks_read,
    heap_blks_hit,
    ROUND(100.0 * heap_blks_hit / NULLIF(heap_blks_hit + heap_blks_read, 0), 2) AS cache_hit_pct
FROM pg_statio_user_tables
ORDER BY heap_blks_read DESC
LIMIT 20;

Backup and Point-in-Time Recovery

Aurora continuously backs up to S3 at the storage layer. There is no I/O penalty for enabling automated backups, unlike RDS PostgreSQL where a backup window can cause measurable I/O contention. The default backup retention is 1 day; increase it to 7–35 days for production workloads that need extended PITR windows.

# Restore Aurora cluster to a point in time (AWS CLI)
aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier prod-aurora-cluster \
  --db-cluster-identifier prod-aurora-restored-20260120 \
  --restore-to-time 2026-01-20T03:00:00Z \
  --restore-type full-copy \
  --vpc-security-group-ids sg-0abc123def456 \
  --db-subnet-group-name aurora-subnet-group

Aurora vs RDS PostgreSQL vs Self-Managed EC2

The right deployment option depends on your team's operational capacity, traffic patterns, budget, and availability requirements. Here is an honest comparison:

Key Takeaways

Working with JusDB on Aurora PostgreSQL

JusDB manages Aurora PostgreSQL for engineering teams that need production-grade reliability without the operational overhead of owning the cluster themselves. Our DBAs handle initial cluster design, parameter group tuning, Aurora Serverless v2 capacity planning, Global Database setup, RDS Proxy configuration, and 24/7 incident response — so your team ships features instead of spending weekends reading Aurora runbooks.

We have helped fintech teams migrate from multi-minute RDS failovers to sub-30-second Aurora promotions, configured Parallel Query for analytics workloads that were saturating read replicas, and designed Global Database topologies that meet cross-region RPO requirements for SOC 2 Type II compliance reviews.

Explore JusDB PostgreSQL Services →  |  Talk to a DBA about Aurora PostgreSQL

Related reading:

• Aurora MySQL vs RDS MySQL in 2026: Architecture, Cost, and When to Choose Each
• PostgreSQL Point-in-Time Recovery (PITR): How It Works and How to Test It
• AWS RDS PostgreSQL Cost Optimization: Reserved Instances, Storage Tuning, and Right-Sizing