Amazon Aurora

Definition

Amazon Aurora is AWS’s cloud-native relational engine, compatible with MySQL and PostgreSQL wire protocols. Storage is distributed across six copies in three AZs with quorum writes; compute (DB instances) attaches to shared storage volumes that auto-scale from 10 GB to 128 TB without pre-provisioning. Aurora delivers higher throughput than standard RDS on the same instance classes, up to 15 low-latency read replicas, and failover often under 30 seconds because replicas attach to the same storage substrate.

Aurora Serverless v2 scales ACUs (Aurora Capacity Units) in fine increments with per-second billing — ideal for variable or multi-tenant SaaS loads. Aurora Global Database replicates to secondary regions with typical sub-second lag for global read scaling and cross-region DR. Aurora integrates with Bedrock and SageMaker via SQL functions for in-database inference on rows without exporting data.

When to use it

• High-throughput OLTP where standard RDS CPU or IOPS ceilings show up in Performance Insights first.
• Applications needing fast failover, many read replicas, or Global Database for international users.
• Variable workloads (dev/test, SaaS tenants) that benefit from Serverless v2 scaling without over-provisioned instances.
• Teams already on MySQL/PostgreSQL who can accept minor compatibility testing for Aurora-specific behaviors.

When not to use it

• Tiny dev databases where db.t4g.micro RDS is cheaper — Aurora has a higher floor cost.
• Heavy analytics scanning — offload to Redshift zero-ETL, Aurora parallel query helps OLTP-ish reports but not warehouse SLAs.
• Global active-active writes across regions — Aurora Global Database has a single write region; see Aurora DSQL for multi-region OLTP.

Tips

• Mix provisioned writer + Serverless v2 readers in the same cluster for cost-efficient read scaling on bursty reporting queries.
• Use Aurora I/O-Optimized when I/O charges exceed ~25% of Aurora spend — math depends on workload; AWS provides calculator inputs in console.
• Enable Backtrack (MySQL-compatible) only when you understand storage implications — not a free undo button.
• Call ML via aws_bedrock_invoke_model() for row-local enrichment, but cap concurrency — inference from SQL can starve OLTP connections.
• Run a compatibility suite (ORM migrations, locking tests, replication slots) before cutover — Aurora is compatible, not identical.

Gotchas

• Serious: Assuming drop-in compatibility without tests — replication slots, pg_logical, and some MySQL isolation nuances differ and break cutover weekends.
• Serious: Serverless v0 confusion — Serverless v2 is fundamentally different (instant scale, shared cluster); do not port v1 assumptions.
• Regular: Reader endpoint load balancing is connection-level, not query-aware — long-running reports on readers can skew load unless you pin endpoints.
• Regular: Global Database failover is manual or scripted — sub-minute RTO requires runbooks, not just checkbox enablement.
• Regular: Aurora storage grows automatically but deleted data compacts slowly — watch VolumeBytesUsed vs logical database size during churn-heavy migrations.

Official references

• Aurora Global Database — RPO/RTO and failover mechanics.
• Aurora PostgreSQL differences — compatibility notes vs community PostgreSQL.

Related FactualMinds content

• Amazon RDS — managed relational baseline
• Aurora DSQL — multi-region distributed SQL
• AWS RDS Consulting
• AWS Data Analytics
• Cloud Compliance Services