3 Amazon Aurora in Practice

Aurora cluster architecture

Amazon Aurora is a managed relational database engine in Amazon RDS. Its MySQL-compatible and PostgreSQL-compatible editions use familiar SQL, drivers, and tools while adding an AWS-designed storage and cluster architecture.

An Aurora DB cluster combines a cluster volume with database instances. The writer instance handles reads and writes; optional reader instances handle read-only work and can become the writer after a failure. Cluster instances share storage rather than each maintaining a separate full database copy.

Endpoints and availability layers

Aurora replicates storage across six storage nodes in three Availability Zones (AZs) within one Region. This storage-level resilience protects the data, while reader instances provide ready compute capacity for reads and potential failover. These are distinct parts of the cluster's availability design.

Use the cluster (writer) endpoint for writes. It follows the current writer after failover. Use the reader endpoint for read-only connections; it distributes connections among available readers. Endpoint redirection does not preserve every existing database session, so applications should reconnect and retry appropriately after connection errors.

Compatibility and migration

Choose either Aurora MySQL-Compatible or Aurora PostgreSQL-Compatible. Existing applications can often connect with their usual database drivers and need few changes, and AWS supports migration paths from standard RDS for MySQL or PostgreSQL. Compatibility is substantial, but it does not guarantee that every engine feature, extension, version, or behavior matches the corresponding open-source engine.

Before migration, test the schema and queries, required extensions, parameter settings, drivers, and application assumptions against the specific Aurora version you plan to use. Aurora versions have their own release cycles, and feature support can vary by Region. Check supported versions, feature differences, and regional availability before committing to a migration.

Scaling compute, reads, and storage

Aurora can scale in several ways, depending on the workload and cluster configuration:

• Compute: In a provisioned cluster, select an instance size for the writer and readers. Changing instance size is a vertical scaling option.

• Read throughput: Add reader instances and send read-only connections through the reader endpoint. A cluster can have up to 15 Aurora Replicas. This scales reads, not writes; the writer remains responsible for database changes.

• Variable compute demand: Aurora Serverless v2 adjusts the capacity of each serverless writer or reader within a configured range. It can suit workloads with variable demand, but capacity limits and feature requirements still need planning.

• Storage: The cluster volume grows as data grows without pre-provisioning a fixed volume size. Maximum capacity depends on engine version, so verify the limit for the version selected.

Failover and cross-Region recovery

Multi-AZ storage helps protect cluster data, but a production cluster also needs suitable compute failover capacity. Place reader instances in different AZs so Aurora can promote a reader if the writer becomes unavailable. Aurora then redirects the writer endpoint to the promoted instance, and client applications should be designed to re-establish connections. A cluster with no reader has less ready failover capacity. Plan backups as part of the cluster's recovery arrangements.

For recovery from a Region-wide disruption, consider Aurora Global Database. It maintains secondary clusters in other Regions for low-latency local reads and disaster recovery. Cross-Region replication is asynchronous, making it a different protection layer from in-Region storage replication. Set recovery objectives and test the promotion and application-reconnection process rather than assuming a secondary Region becomes active automatically.

Choosing Aurora or standard RDS

Aurora and standard Amazon RDS are both managed relational database options. Aurora is part of Amazon RDS, but it is a distinct database engine and cluster architecture—not simply a setting that makes every RDS engine faster.

Aurora may be preferable when its shared cluster storage, multiple low-latency readers, Aurora Serverless, or Aurora-specific cross-Region capabilities suit the workload enough to justify its pricing and operational choices. Benchmark with your own data and queries: actual performance depends on workload and design, so published throughput comparisons are not guarantees.

Standard RDS may be preferable when you need an engine Aurora does not provide, such as MariaDB, Oracle, SQL Server, or Db2, or when a standard MySQL or PostgreSQL deployment meets your needs more simply or cost-effectively. Compare total costs, including instances, storage, I/O, backups, and cross-Region requirements; do not choose Aurora on performance claims alone.

For example, an application with familiar PostgreSQL queries, sharp traffic peaks, and many read-only requests could evaluate Aurora PostgreSQL with Serverless v2 capacity and reader instances. A small, steady PostgreSQL application that does not need those capabilities may be better served by standard RDS for PostgreSQL. Test compatibility, failover behavior, and cost before committing to either option.