Amazon Aurora is a fully managed relational database engine available through Amazon Relational Database Service (Amazon RDS). It supports MySQL- and PostgreSQL-compatible editions and uses an AWS-designed distributed storage architecture.
Aurora separates database compute from storage. A cluster normally contains one writer DB instance, optional reader DB instances, and a shared cluster volume distributed across multiple Availability Zones.
This design gives Aurora several capabilities that differ from those of standard RDS for MySQL and RDS for PostgreSQL deployments, including shared storage, up to 15 reader instances, automated failover, Aurora serverless capacity, and multi-Region replication through Aurora Global Database.
This guide explains how Aurora works, where it differs from other RDS database engines, and what to consider before deploying it.
TL;DR
- Amazon Aurora is a MySQL-compatible or PostgreSQL-compatible database engine managed through Amazon RDS.
- A standard Aurora cluster has one writer and can have up to 15 readers.
- Aurora stores six copies of the cluster data across three Availability Zones.
- The storage volume expands automatically and can reach 128 TiB or 256 TiB, depending on the database engine and version.
- Aurora serverless automatically adjusts database compute capacity using Aurora Capacity Units.
- Aurora Global Database supports one primary Region and up to 10 read-only secondary Regions.
- Production clusters should normally include at least one reader in another Availability Zone so Aurora has a DB instance available for failover.
What Is Amazon Aurora?
Amazon Aurora is an AWS-managed relational database engine compatible with MySQL and PostgreSQL.
Aurora compatibility means that applications can generally use familiar MySQL or PostgreSQL drivers, SQL syntax and administration tools. Compatibility does not mean that Aurora behaves identically to every community MySQL or PostgreSQL release. Some extensions, storage engine features, parameters, and administrative functions are unsupported or behave differently.
Application and schema compatibility should therefore be tested before migrating a production database.
Aurora is part of Amazon RDS. The practical comparison is usually between:
- Aurora MySQL and RDS for MySQL
- Aurora PostgreSQL and RDS for PostgreSQL
- Aurora provisioned and Aurora serverless
- A regional Aurora cluster and Aurora Global Database
How an Aurora Cluster Works
A conventional Aurora DB cluster contains three main components.
Writer DB Instance
The writer accepts read and write operations. SQL statements such as INSERT, UPDATE, DELETE The writer must ultimately process data-definition commands and transactions that modify data.
A standard Aurora cluster has one active writer.
Aurora Replicas
Aurora Replicas are read-only DB instances attached to the same cluster volume as the writer. A cluster can contain up to 15 readers.
Readers serve two main purposes:
- They provide additional compute capacity for read-heavy workloads.
- They act as failover targets if the writer becomes unavailable.
The writer and readers use separate compute resources, caches, and database processes. They access the same distributed Aurora storage volume, rather than maintaining full, independent disk copies, as with conventional database replicas.
Cluster Volume
The cluster volume is a shared, distributed storage system used by every DB instance in the cluster.
Aurora maintains six copies of the data across three Availability Zones. The storage system detects and repairs failed storage segments using healthy copies elsewhere in the cluster volume.
Storage protection exists independently of the number of DB instances. Even a writer-only cluster receives the distributed storage architecture. Compute high availability still requires another DB instance that Aurora can promote.
Storage Scaling and Maximum Capacity
Aurora storage expands automatically as the amount of data in the cluster volume grows. You do not provision a fixed amount of general-purpose or provisioned-IOPS storage when creating a standard Aurora cluster.
The maximum cluster volume depends on the engine version:
- Supported recent Aurora MySQL and Aurora PostgreSQL versions can scale to 256 TiB.
- Earlier supported versions generally have a maximum cluster volume of 128 TiB.
Storage does not automatically shrink when data is deleted. Database maintenance, temporary data, and historical versions of records can also affect the billed volume size.
Check the limit for the exact Aurora engine version before planning a large database migration.
Aurora Standard and Aurora I/O-Optimized
Aurora provides two cluster storage configurations.
Aurora Standard
Aurora Standard charges separately for:
- DB instance compute
- Database storage
- Read and write I/O requests
- Backup storage beyond the included allowance
- Data transfer and other optional services
This configuration usually suits databases with moderate I/O activity.
Aurora I/O-Optimized
Aurora I/O-Optimized does not charge separately for read and write I/O operations. Its compute and storage rates differ from Aurora Standard.
AWS recommends evaluating I/O-Optimized when I/O charges account for at least 25% of the total Aurora database cost.
Review real billing and workload data before changing configurations. A database with low I/O activity can cost more on I/O-Optimized, while an I/O-intensive database may gain more predictable costs.
Aurora High Availability
Aurora protects storage and compute through separate mechanisms.
The shared storage layer replicates data across three Availability Zones. Database compute becomes highly available when the cluster contains a reader in another Availability Zone.
If the writer fails, Aurora can promote an eligible reader and update the cluster endpoint to direct connections to the new writer.
A writer-only cluster does not have an existing reader to promote. Aurora must create or restart compute capacity before service can resume, which typically results in a longer interruption.
For a production deployment:
- Create at least one Aurora Replica.
- Place the reader in a different Availability Zone from the writer.
- Configure appropriate failover priority tiers.
- Use the cluster endpoint rather than an instance hostname for writes.
- Implement connection retries in the application.
- Avoid excessive DNS caching.
- Test failover before placing the database into production.
AWS database drivers and Amazon RDS Proxy can reduce application recovery time by detecting topology changes and routing connections to the new writer more quickly than applications that rely solely on DNS refreshes.
Understanding Aurora Endpoints
Aurora provides several endpoint types for different connection patterns.
Writer Endpoint
The cluster endpoint, commonly called the writer endpoint, connects to the current writer DB instance.
Applications should use this endpoint for read/write sessions. Following a failover, AWS updates the endpoint’s DNS record to point to the newly promoted writer.
Reader Endpoint
The reader endpoint distributes new connections across available Aurora Replicas.
It balances connections rather than individual SQL statements. A persistent connection continues using the reader selected when that connection was opened.
When a cluster has no reader instances, the reader endpoint can direct connections to the writer. Applications should not treat the existence of a reader endpoint as proof that dedicated read capacity has been configured.
Instance Endpoints
Every writer and reader has its own instance endpoint.
Instance endpoints are useful for administration, troubleshooting, and workloads that need to target a specific DB instance. General application traffic should normally use the writer or reader endpoint to track topology changes.
Custom Endpoints
Custom endpoints allow selected readers to be grouped behind a separate endpoint.
For example, a cluster could use:
- General-purpose readers behind the built-in reader endpoint
- Larger instances behind an analytics endpoint
- A dedicated reader for reporting or administrative queries
Custom endpoints provide workload separation, although they do not enforce database permissions or resource limits.
Aurora Read Scaling
Aurora readers add compute capacity for SELECT workloads. They are useful for web applications, reporting services, API read traffic, and other workloads where reads can be separated from writes.
Reader scaling does not increase the write capacity of the standard Aurora writer. Write throughput remains constrained by the writer, database design, transaction behavior, and the storage system’s capabilities.
Aurora Auto Scaling can add or remove readers based on metrics such as average CPU utilization or average database connections. Applications must connect through the reader endpoint or otherwise discover newly created readers before they can use the additional capacity.
Auto Scaling removes only the readers that it created. Manually created readers remain in the cluster until they are explicitly modified or deleted.
Aurora Replica Lag and Read Consistency
Aurora readers typically remain close to the writer because they access the same distributed cluster volume. Replication lag can still occur while a reader applies database changes and updates its in-memory state.
This matters when an application writes a record and immediately attempts to read it from a reader.
Applications that require read-after-write consistency can:
- Send consistency-sensitive reads to the writer.
- Keep the user session on the writer for a short period after a write.
- Add application-level retry logic.
- Monitor replica lag and remove unhealthy readers from use.
- Design workflows that tolerate eventual consistency.
Do not assume that every query sent to the reader endpoint will immediately see the latest committed write.
What Is Aurora Serverless?
AWS now uses the name Aurora Serverless for the architecture formerly known as Aurora Serverless v2.
Aurora Serverless v1 reached end of life on 31 March 2025. Older descriptions involving a proxy fleet, warm capacity pools, and complete cluster scaling describe the retired v1 architecture and should not be used for current deployments.
Aurora Serverless uses DB instances with the db.serverless instance class. Each serverless instance adjusts its compute and memory capacity within the cluster’s configured range.
Capacity is measured in Aurora Capacity Units, or ACUs. One ACU represents approximately 2 GiB of memory with corresponding CPU and networking resources.
Depending on the engine version, Aurora serverless supports:
- A minimum capacity as low as 0 ACUs
- A maximum capacity of 256 ACUs
- Capacity settings in 0.5-ACU increments
- Serverless writers
- Multiple serverless readers
- Mixed clusters containing serverless and provisioned instances
Availability and capacity limits can vary by Region and database version.
Scaling to Zero
Supported Aurora versions can set the minimum capacity to zero.
When no qualifying user connections remain for the configured period, the serverless DB instance can pause. A new connection causes it to resume.
Automatic pausing can reduce compute costs for development, testing, and intermittent internal applications. Resuming takes time, so scaling to zero is generally unsuitable for systems that require consistently low connection latency or strict availability objectives.
When Aurora Serverless Is Useful
Aurora Serverless can suit:
- Development and test databases
- Applications with large or unpredictable traffic changes
- Multi-tenant services with variable demand
- Databases where manual instance resizing is undesirable
- Workloads that can benefit from independently scaling readers
A provisioned instance can remain more predictable for a stable, continuously busy workload—Benchmark both configurations against the application’s latency, connection, and cost requirements.
What Is Aurora Global Database?
Aurora Global Database extends an Aurora deployment across AWS Regions.
A global database contains:
- One primary AWS Region with a writable Aurora cluster
- Up to 10 secondary AWS Regions containing read-only clusters
Applications send writes to the primary Region. Secondary Regions can serve local read traffic and provide disaster-recovery capacity.
The Aurora Global Database writer endpoint follows the current primary cluster after a supported switchover or failover. This reduces the need to maintain an application-specific list of regional writer endpoints.
Planned Switchover
A switchover moves the primary role to a secondary Region while all participating clusters are healthy.
Aurora synchronizes the selected secondary before changing roles, enabling a planned switchover that provides a recovery point objective of zero.
Common uses include disaster-recovery testing, regional maintenance and controlled movement of the write workload.
Unplanned Failover
A managed failover promotes a secondary Region following an outage affecting the primary Region.
Transactions that had not reached the selected secondary before the outage can be lost. The achievable recovery point, therefore, depends on the cross-Region replication lag at the time of the failure.
Applications must also be able to reconnect, refresh DNS information, and reach the network and supporting services in the new primary Region.
Global Database provides an important part of a disaster-recovery design. It does not automatically make the complete application multi-Region.
Current Aurora MySQL Version Families
Aurora MySQL version numbering has changed over time.
The main compatibility families are:
- Aurora MySQL version 1: MySQL 5.6-compatible and end of life
- Aurora MySQL version 2: MySQL 5.7-compatible
- Aurora MySQL version 3: MySQL 8.0-compatible
- Aurora MySQL version 8.4: MySQL 8.4-compatible
Aurora MySQL version 2 has passed standard support and may incur Amazon RDS Extended Support charges where it remains available.
Select a version according to:
- AWS Region availability
- Standard-support and extended-support dates
- Application compatibility
- Authentication plugin support
- Parameter changes
- Removed or changed MySQL features
- Upgrade paths from the source database
Avoid selecting an old version solely because it appears compatible with an existing application. Test the application against a currently supported target release.
Aurora PostgreSQL Versions
Aurora PostgreSQL versions follow the PostgreSQL major-version family with AWS-specific patches and release schedules.
Before choosing a version, check:
- Whether it is available in the intended AWS Region
- Its Aurora end-of-standard-support date
- Extension compatibility
- Logical replication requirements
- Parameter differences
- Available instance classes
- Support for Aurora serverless or Global Database
- The supported upgrade path from the current database
PostgreSQL applications that depend on superuser access, operating system access, or unsupported extensions may require modification before migration.
Backtrack for Aurora MySQL
Aurora Backtrack allows an Aurora MySQL cluster to be moved to an earlier consistent point without restoring a separate cluster from a snapshot.
The maximum backtrack window is 72 hours.
Important limitations include:
- Backtrack must be enabled when creating the cluster or restoring it from a snapshot.
- It affects the entire cluster.
- It cannot restore a single table independently.
- Open connections are closed during the operation.
- Uncommitted work is discarded.
- Backtracking can interfere with binlog replicas and blue/green deployments.
- It is an Aurora MySQL feature, not a general Aurora PostgreSQL capability.
Backtrack is useful for rapid recovery from some logical errors. Automated backups and snapshots remain necessary for longer retention and independent recovery copies.
Backups and Point-in-Time Recovery
Aurora continuously and incrementally backs up the cluster volume to Amazon S3.
The automated backup retention period can be configured from 1 to 35 days. Point-in-time recovery can restore the database to a selected recoverable time within that retention period.
Automated backups are separate from manual DB cluster snapshots. Manual snapshots remain available until they are explicitly deleted.
For production databases:
- Set a retention period that meets the recovery policy.
- Create manual snapshots before high-risk changes.
- Consider AWS Backup for centralized backup policy management.
- Test restores regularly.
- Protect snapshots with appropriate IAM and AWS KMS controls.
- Enable deletion protection where accidental deletion presents a material risk.
A backup policy is only proven when the organization can successfully restore the database and reconnect the application.
Monitoring Aurora
Aurora publishes instance and cluster metrics to Amazon CloudWatch.
Important areas to monitor include:
- CPU utilisation
- Freeable memory
- Database connections
- Commit latency
- Read and write latency
- Replica lag
- Deadlocks
- Transaction age
- Storage consumption
- Serverless capacity
- Global Database replication lag
- Failover and maintenance events
CloudWatch Database Insights is the current AWS console experience for fleet-level database monitoring, DB load, wait events and query analysis.
The Performance Insights console experience reaches end of life on 31 July 2026 and will redirect users to Database Insights. AWS states that the Performance Insights API will continue operating.
Configure CloudWatch alarms and event notifications rather than relying on occasional manual console inspections.
Creating an Aurora Cluster in the AWS Console
The exact options depend on the AWS Region, engine, and selected version. The following process covers the main decisions.
Step 1: Open Amazon RDS
Sign in to the AWS Management Console, open Amazon RDS, choose Databases, and select Create database.
Use Standard create when you need control over networking, encryption, availability, monitoring,g and backup settings.
Step 2: Select the Aurora Engine
Choose either:
- Amazon Aurora MySQL-Compatible Edition
- Amazon Aurora PostgreSQL-Compatible Edition
Confirm that the application supports the selected engine and major version.
Step 3: Choose the Engine Version
Select a supported engine version that matches the migration and lifecycle plan.
Review the version’s:
- Standard-support dates
- Upgrade path
- Regional availability
- Serverless support
- Global Database support
- Instance-class support
- Known compatibility differences
For a production migration, test the exact minor version rather than testing only the major-version family.
Step 4: Choose Provisioned or Serverless Capacity
For provisioned Aurora, select an appropriate DB instance class for the writer and readers.
For Aurora serverless, configure the minimum and maximum ACU values. Consider memory requirements, connection limits, and scaling behavior when setting the range.
A low minimum can save money while increasing the likelihood that the database will need to scale during a sudden traffic increase.
Step 5: Configure the Cluster Identifier and Credentials
Enter a unique DB cluster identifier and master username.
Store credentials in AWS Secrets Manager rather than embedding passwords in application configuration, deployment files, or source code.
Where supported by the application, consider using an IAM database for short-lived authentication tokens.
Step 6: Configure Availability
For production, create at least one reader in another Availability Zone.
A reader provides both read capacity and an available failover target. Additional readers can be added later or managed through Aurora Auto Scaling.
Review the promotion tiers for readers with different instance sizes or serving specialized workloads.
Step 7: Configure Networking
Place the cluster in an appropriate VPC and DB subnet group.
Production databases should normally use private subnets and should not be publicly accessible.
Configure the database security group to permit traffic only from approved application security groups, administration networks, or controlled connectivity services.
Avoid rules that expose the MySQL port 3306 or PostgreSQL port 5432 to the entire internet.
Step 8: Choose the Storage Configuration
Select either:
- Aurora Standard
- Aurora I/O-Optimized
Use expected I/O activity and cost modeling to make this decision. The storage configuration can be changed later, subject to AWS switching restrictions and possible restart behavior for some instance types.
Step 9: Configure Encryption and Authentication
Configure encryption at rest using an AWS KMS key appropriate for the organization’s access and recovery requirements.
Require encrypted client connections using TLS. Review certificate rotation procedures and ensure database clients trust the current Amazon RDS certificate authority.
Enable IAM database authentication only where the application and connection pattern suit token-based authentication.
Step 10: Configure Backups and Protection
Set:
- Automated backup retention
- Preferred backup window
- Preferred maintenance window
- Deletion protection
- Snapshot tag copying
- Minor-version upgrade preferences
Enable Backtrack during creation only when deploying a supported Aurora MySQL version and when the operational benefits justify the additional cost and limitations.
Step 11: Configure Monitoring and Logs
Use CloudWatch Database Insights and Enhanced Monitoring according to the workload’s observability requirements.
Export useful database logs to CloudWatch Logs. Depending on the engine, these can include:
- Error logs
- General logs
- Slow-query logs
- PostgreSQL logs
- Upgrade logs
- IAM authentication logs
Log collection can create additional CloudWatch charges, so configure retention policies.
Step 12: Create and Validate the Cluster
Choose Create database and wait for the writer and any readers to reach the Available state.
After creation:
- Record the writer and reader endpoints.
- Confirm security-group access.
- Connect using TLS.
- Create application-specific database users.
- Avoid using the master account for routine application access.
- Test backup creation and restoration.
- Perform a controlled failover test.
- Confirm that the application reconnects to the new writer.
- Create CloudWatch alarms and event notifications.
The cluster should not be considered production-ready until connectivity, recovery, and failover have been tested.
Migrating RDS for MySQL to Aurora MySQL
A compatible RDS for MySQL instance can serve as the source for an Aurora read replica migration.
The general process is:
- Check engine and feature compatibility.
- Create an Aurora read replica from the RDS for MySQL source.
- Allow the initial snapshot copy and binlog replication to complete.
- Test the Aurora cluster while replication continues.
- Stop or control writes to the source.
- Wait for replication lag to reach zero.
- Promote the Aurora read replica.
- Redirect the application to the Aurora writer endpoint.
- Validate data and application behavior.
- Temporarily retain the source per the rollback plan.
Some older RDS for MySQL releases cannot be migrated directly to recent Aurora MySQL versions. Tables that use unsupported storage engines or compressed row formats may also require conversion.
Migrating RDS for PostgreSQL to Aurora PostgreSQL
AWS supports creating an Aurora PostgreSQL read replica from a compatible RDS for PostgreSQL instance.
This migration option requires:
- The source and target to be in the same AWS account
- The source and target to be in the same AWS Region
- A compatible Aurora PostgreSQL version
- The same PostgreSQL major-version family, with an appropriate target minor version
Snapshot migration is another option where a longer interruption is acceptable.
Check extension support, roles, privileges, logical replication objects, and parameter differences before cutover.
Migrating from On-Premises or Another Cloud
Available migration methods include:
mysqldumpand restorepg_dumpand restore- Percona XtraBackup for supported Aurora MySQL migration paths
- Native MySQL replication
- PostgreSQL logical replication
- AWS Database Migration Service
- AWS Schema Conversion Tool for heterogeneous migrations
A dump and restore normally involves an outage or a period during which writes must be controlled.
AWS DMS can perform an initial full load followed by change data capture, reducing the final cutover window. DMS does not remove the need to validate schema objects, indexes, users, permissions, sequences, stored code,e and application compatibility.
Migrations from Oracle, SQL Server, MariaDB, or other engines may require schema and application conversions. Aurora’s MySQL and PostgreSQL compatibility does not make those migrations automatic.
Aurora-to-Aurora Replication and Copying
Choose the mechanism according to the objective.
Aurora Global Database
Use Global Database for managed multi-Region read scaling and disaster recovery.
Aurora Cloning
Use Aurora cloning to create a fast copy-on-write cluster in the same Region. Clones are useful for testing, development, and validating database changes without immediately copying every storage page.
Snapshot Restore
Use a snapshot to create an independent cluster. Snapshots can also be copied across Regions and accounts when encryption and permissions are configured correctly.
Native Replication
Aurora MySQL can use binlog replication between supported clusters and external MySQL-compatible databases.
Native replication requires more operational management than Aurora’s built-in replication features and can experience significant lag during heavy workloads.
Aurora Versus RDS for MySQL or PostgreSQL
Aurora is worth evaluating when the workload requires:
- Multiple low-lag read replicas
- Fast reader creation
- Shared distributed storage
- Managed cross-Region replication
- Automatic compute scaling
- High read throughput
- Rapid failover to an existing reader
- Storage capacity beyond standard RDS instance limits
- Aurora-specific features such as Backtrack or cloning
Standard RDS for MySQL or PostgreSQL may be more appropriate when:
- The workload is small and predictable.
- Cost is more important than large-scale read capacity.
- The application requires a feature unavailable in Aurora.
- A standard Multi-AZ RDS deployment meets the availability target.
- The team wants closer behavior to the community database engine.
- The database has no requirement for Aurora-specific scaling or global features.
Aurora should be selected through performance testing, compatibility assessment, and cost modeling.
Important Aurora Limitations
Aurora solves many database infrastructure problems, although it does not remove the need for database engineering.
Keep the following constraints in mind:
- A standard Aurora cluster has one writer.
- Readers scale read workloads, not normal write workloads.
- Reader lag can affect read-after-write behavior.
- Failover interrupts some connections.
- Applications still require reconnect and retry logic.
- MySQL and PostgreSQL compatibility is not identical to the community engines.
- Database design and inefficient queries can still create bottlenecks.
- Cross-Region failover can involve a non-zero recovery point.
- I/O charges can become significant on Aurora Standard.
- Serverless scaling does not correct poor indexing or unbounded connection growth.
- Multi-Region database replication does not automatically replicate every application dependency.
Run a representative proof of concept before moving a critical production workload.
Final Thoughts
Amazon Aurora combines managed MySQL or PostgreSQL compatibility with a distributed storage system, reader-based scaling, automated failover and optional multi-Region replication.
Its strongest use cases involve applications that need high availability, substantial read capacity, flexible compute scaling or a managed regional disaster-recovery architecture.
A reliable production deployment still requires careful engine-version selection, private networking, encryption, backup testing, monitoring and application-level reconnect logic. At least one reader in another Availability Zone should normally be included when high availability is a requirement.
Aurora can provide a strong database platform when its architecture matches the workload. Compatibility testing, performance benchmarking, and cost analysis should guide the final decision.
Leave a Reply