Amazon Aurora is a proprietary, fully managed relational database service from AWS, designed for high performance and availability, compatible with MySQL and PostgreSQL. It is built specifically for the AWS cloud, claiming superior performance compared to standard MySQL and PostgreSQL on RDS, without application code changes. (source_page: 1, 5)
Amazon Aurora is a cloud-optimized relational database service designed for demanding workloads.
Amazon Aurora is a proprietary, fully managed relational database service from AWS, designed for high performance and availability. It is compatible with MySQL and PostgreSQL. Aurora is not open-source, unlike MySQL or PostgreSQL. It is built specifically for the AWS cloud.
Aurora claims superior performance compared to standard MySQL and PostgreSQL on RDS. It offers up to 5x performance of MySQL on RDS and over 3x performance of PostgreSQL on RDS. These performance improvements are achieved without application code changes.
Technical Specs: Up to 5x performance of MySQL on RDS; Over 3x performance of PostgreSQL on RDS
Amazon Aurora provides high performance, especially for read-heavy workloads, storage autoscaling, and increased replica limits. It is designed natively for resilience, offering instantaneous failover and high availability. It facilitates ease of migration due to its compatibility with existing applications, drivers, and tools.
Aurora is suitable for mission-critical applications requiring enterprise-grade performance. It is also well-suited for enterprise applications, Software as a Service (SaaS) applications, and web and mobile gaming applications that demand high throughput and low latency.
Aurora is a fully managed relational database service (from Amazon RDS), meaning AWS handles all the underlying infrastructure management. This simplifies database management by automating tasks such as patching, backups, high availability, and scaling.
Aurora's architecture is designed for high durability, fault tolerance, and cloud-native capabilities.
An Amazon Aurora database cluster comprises one or more database instances for compute and a shared storage layer known as the Cluster Volume, which manages data for these instances. The compute and storage layers are loosely coupled, allowing them to scale independently.
The storage layer maintains six copies of data across three Availability Zones (AZs). For write operations, acknowledgment from four out of six storage nodes is required. For read/repair operations, a quorum of three out of six read nodes is required. This fault tolerance enables the system to sustain the loss of an entire AZ and continue operating. The storage layer is self-healing, featuring peer-to-peer replication and automatic healing of failed disks. The shared storage volume is responsible for logging and data storage, is backed by Amazon S3, and performs continuous backups to S3.
Technical Specs: Maintains six copies of data across three Availability Zones (AZs); Write Operation Requirement: Acknowledgment from four out of six storage nodes; Read/Repair Operation Requirement: A quorum of three out of six read nodes; Can sustain the loss of an entire AZ
The primary instance handles all read and write operations. It performs all data modifications to the cluster volume and is responsible for SQL transactions and caching within the compute layer.
Up to 15 Aurora Replicas can be created in addition to the single primary DB instance, for scaling read capacity. These replicas are spread across multiple AZs and can be promoted to primary in case of failure. Failover is fast, capable of taking less than 30 seconds, and failover priority can be assigned to them. These low-latency read replicas share the same underlying cluster storage volume, providing high performance for read-heavy workloads.
Technical Specs: Up to 15 Aurora Replicas; Failover can take less than 30 seconds
The Aurora architecture is designed to guarantee high durability, fault tolerance, cloud-native capability, and inbuilt resilience.
Aurora enhances read scalability and availability through its advanced replica features and integrated autoscaling.
Aurora supports up to 15 replicas, which is significantly more compared to 5 in standard RDS. The replication lag is typically under 10 milliseconds, making it significantly faster than traditional MySQL replication.
Technical Specs: Up to 15 replicas (compared to 5 in standard RDS); Typically under 10 milliseconds replication lag
Aurora provides a single reader endpoint for all read replicas, allowing applications to connect without needing to manage individual replica endpoints. A separate writer endpoint is provided for write operations.
Aurora automatically adjusts the number of replicas based on workload, integrating seamlessly with Amazon CloudWatch. You can configure scaling policies by setting target metrics like Average CPU utilization (RDS reader.CPUUtilization) or Average database connections (RDS reader.DatabaseConnections). These policies specify minimum and maximum numbers of replicas and a threshold value. When metrics exceed the threshold, new replicas are provisioned and join the reader endpoint (scale-up). When metrics fall below the threshold, unneeded replicas created by autoscaling are terminated (scale-in).
Technical Specs: CloudWatch metric names: RDS reader.CPUUtilization or RDS reader.DatabaseConnections
Aurora autoscaling only removes replicas it created, not manually added ones or those added via infrastructure-as-code. New replicas added by autoscaling match the instance class of the primary instance.
Autoscaling provides cost-efficiency by paying only for needed capacity, seamless scalability to maintain responsiveness during traffic spikes, and improved availability by distributing read traffic and enabling faster failover.
Custom endpoints allow for advanced workload segregation within an Aurora cluster.
Custom endpoints address scenarios where different query priorities or resource needs exist within a single database cluster, preventing resource-intensive queries from impacting core application performance.
The core concept behind custom endpoints is workload segregation. They allow routing connections to a specific, user-defined subset of instances within an Aurora cluster.
An example use case is separating heavy analytical/reporting queries from high-volume transactional queries for a web application. This could involve one custom endpoint for web application read queries and another for Business Intelligence (BI) or reporting queries, potentially routing to larger replicas.
Custom endpoints can be created for read operations, write operations, or a combination. They enable performance optimization by allowing the use of different instance sizes for different custom endpoints to efficiently allocate resources.
Aurora also provides default endpoints: a Reader Endpoint that handles simple load balancing across all read replicas, and a Writer/Cluster Endpoint used for write operations (INSERT, UPDATE, DELETE).
Aurora offers advanced configurations for serverless, global, and multi-master setups.
Aurora Serverless V2 is an on-demand, autoscaling configuration of Amazon Aurora that automatically starts, scales, and shuts down database capacity based on application needs. It eliminates the need for manual database instance management and capacity planning, especially for unpredictable workloads. It uses Aurora Capacity Units (ACU) which are a blend of CPU, memory, and networking. V2 scales in increments as small as 0.5 ACUs, with approximately 2 GB of RAM per ACU. It can scale from 0 ACU to 256 ACUs. For inactivity, it can scale down to 0 ACUs, pausing the database and stopping compute billing, resuming automatically on new connection. Billing is charged per second of use.
Technical Specs: Scaling Range (V2): Configurable from 0 ACU to 256 ACUs; Scaling Granularity (V2): Increments as small as 0.5 ACUs; Approximately 2 GB of RAM per ACU; Billed per second of use
Aurora Serverless V2 uses a warm pool of ACUs managed by AWS, allocating them based on workload and configured min/max ACU settings. It supports creating a single Aurora cluster with a mix of provisioned and serverless v2 instances (e.g., provisioned writer for steady production, serverless v2 read replicas for spiky read traffic). It also offers a Data API for database interaction over HTTPS, suitable for serverless applications like AWS Lambda, handling connection pooling. It supports Multi-AZ deployments for high availability and Aurora Global Database for disaster recovery. Serverless v2 replicas can automatically scale up to match writer capacity during failover.
Aurora Serverless V2 is ideal for intermittent workloads (such as internal analytics dashboards and websites with seasonal traffic), development & test environments (offering cost reduction by pausing instances when not in use), and SaaS & Multi-tenant Applications (providing cost-effective per-tenant databases that scale independently).
Aurora Global Database is a single Aurora database spanning multiple AWS regions, designed for global applications to provide low-latency local reads and disaster recovery. It consists of one primary cluster in one region and up to 10 read-only secondary clusters in other regions, supporting both Aurora Serverless v2 and Provisioned clusters. All writes occur in the primary region. Data replication to secondary regions is at the storage layer, with latency typically less than 1 second. All nodes (primary and secondary) support local reads.
Technical Specs: Up to 10 read-only secondary clusters; Replication latency typically less than 1 second
Read Replica Write Forwarding allows a secondary region cluster to accept writes. The secondary cluster forwards the write to the primary cluster, which then replicates the update back to all secondary clusters. For disaster recovery, in case of a full region outage, a secondary region can be promoted to primary (unmanaged failover) with RPO typically < 1 second and RTO typically < 1 minute. Global Database Switchover is an automated, graceful process for planned events to switch primary/secondary roles without data loss.
Technical Specs: Unmanaged Failover RPO typically < 1 second, RTO typically < 1 minute
Aurora Multi-Master is a single-region solution providing multiple read/write instances within the same Aurora cluster across different Availability Zones. All instances in the cluster can accept writes, unlike traditional primary/replica setups. If one instance fails, others continue serving write requests immediately, providing extremely high availability for write operations. This feature is supported for older MySQL-compatible Aurora versions and is not available for all workloads or in all AWS regions.
Aurora provides robust data protection through continuous backups, point-in-time recovery, and efficient cloning capabilities.
Aurora supports all default RDS backup and restore capabilities, offering more advanced features. It creates cluster-level backups, in contrast to standard RDS which provides instance-level backups. It enables continuous data backups with a user-defined retention period of up to 35 days, ensuring data is always protected without impacting database performance or availability.
Technical Specs: Continuous data backups with a user-defined retention period (up to 35 days)
Backtrack functionality allows rewinding the database to any point in time within a configured period (up to 72 hours) without relying on traditional backups, minimizing data loss from user errors.
Technical Specs: Up to 72 hours configured period
Aurora database cloning creates a complete, ready-to-use copy of an existing Aurora database cluster in minutes, regardless of database size. This is significantly faster and more cost-efficient than traditional snapshot and restore due to Aurora’s decoupled storage architecture. The new clone cluster shares the exact same underlying distributed storage volume as the original source cluster, incurring no additional storage cost initially as no data is copied at the moment of cloning. It uses a Copy on Write protocol: when data is modified in either the source or the clone, a new copy of that page is created for the modifying cluster. Source and clone clusters become completely independent after cloning.
Cloning is ideal for creating development or testing environments, conducting load testing or performance benchmarking without impacting production, and for developers to get a clone of production data for debugging without exposing or corrupting production data.
Aurora supports various methods for migrating existing databases to its environment and converting from other RDS engines.
On-premises backup files (.bak, .sql) cannot be directly restored to RDS/Aurora using a simple restore command. Primary migration methods include Logical Migration (offline) and Assisted Migration (online) using AWS Database Migration Service (DMS).
This method involves exporting data from the on-premises database to a logical dump file (e.g., using mysqldump for MySQL), uploading the dump file to Amazon S3, creating a target RDS/Aurora database instance compatible with the source engine, and then restoring data from the S3 file using a client tool (e.g., MySQL client from an EC2 instance in the same VPC). It is suitable for smaller databases and planned migrations with acceptable downtime.
This method enables online migration with no downtime. It involves creating an AWS DMS replication instance, creating target endpoints (Aurora/RDS cluster), configuring source (on-premises database) and target endpoints in DMS, and then creating and running a migration task. DMS performs a full load and optionally replicates ongoing changes (Change Data Capture - CDC) to keep databases in sync. Optional security involves configuring VPN connection or Direct Connect for secure channels. Once replication is complete, applications are pointed to the new AWS database via a cutover.
To convert an RDS MySQL or PostgreSQL database to Aurora, it can be done directly using a read replica; no data migration is needed.
Implementing robust security practices and managing costs are crucial for Aurora deployments.
For network security, production databases (RDS/Aurora) should always be placed in a private subnet within your VPC, with database security groups used to filter access, allowing connections only from application servers. Network ACLs (NACLs) can be used as an additional stateless security layer at the subnet level. For encryption at rest, AWS Key Management Service (KMS) is used and must be enabled when creating a production database. If database encryption is enabled, snapshots, backups, and read replicas are automatically encrypted. Encryption in transit is achieved using SSL/TLS certificates to secure connections between applications and the database endpoint.
Deletion protection is a crucial safety feature to prevent accidental deletion of production databases. It must be explicitly disabled before the instance can be deleted.
Amazon Aurora is approximately 20% more expensive than standard RDS, but often more cost-efficient overall due to performance and reduced maintenance. Aurora instances do not offer a free tier. For predictable usage over 1 or 3 years, purchasing RDS Reserved Instances can significantly reduce costs. Aurora Serverless V2 is billed per second of use.
Technical Specs: Approximately 20% more expensive than RDS
Glossary
Aurora Capacity Unit (ACU)
A unit used in Aurora Serverless V2, representing a blend of CPU, memory, and networking capacity.
Backtrack
A feature that rewinds an Aurora database to any point in time within a configured period without relying on traditional backups, minimizing data loss from user errors.
Copy on Write
A protocol used in Aurora cloning where modifications in either the source or clone cluster cause a new copy of a data page to be created, ensuring independence.
Custom Endpoint
Allows routing connections to a specific, user-defined subset of instances within an Aurora cluster for workload segregation.
Global Database Switchover
An automated, graceful process to switch primary/secondary roles in an Aurora Global Database for planned events without data loss.
Read Replica Write Forwarding
A feature in Aurora Global Database that allows a secondary region cluster to accept writes, which are forwarded to the primary cluster and then replicated.