Overview

AWS Aurora is a managed relational database service offered by Amazon Web Services, designed for high-performance and high-availability use cases. Launched in 2014, Aurora aims to combine the speed and availability of commercial databases with the simplicity and cost-effectiveness of open-source databases AWS Aurora homepage. It is compatible with both MySQL and PostgreSQL, allowing existing applications to migrate with minimal code changes Aurora Overview documentation.

Aurora's architecture separates computational processing from storage. The storage layer is a distributed, fault-tolerant, self-healing system that automatically scales up to 128 TB per database instance Aurora storage architecture details. This design contributes to its claimed performance advantages, with AWS stating up to five times the throughput of standard MySQL and up to three times the throughput of standard PostgreSQL running on comparable hardware AWS Aurora performance claims. The service automatically replicates data across three Availability Zones (AZs) in a region, maintaining six copies of data to enhance durability and availability.

Aurora is well-suited for applications requiring high transaction rates, low latency, and continuous operation. This includes e-commerce platforms, SaaS applications, gaming backends, and analytical workloads where data consistency and rapid query responses are critical. Developers and technical buyers often consider Aurora when migrating from self-managed MySQL or PostgreSQL databases, or from proprietary commercial databases, seeking a managed service that reduces operational overhead while delivering performance.

One of Aurora's distinguishing features is its support for up to 15 read replicas, which can be distributed across multiple Availability Zones. These replicas share the same underlying storage volume as the primary instance, which means replication lag is typically in milliseconds Aurora replication documentation. This capability is beneficial for scaling read-heavy applications and offloading analytical queries without impacting the performance of write operations on the primary instance. Furthermore, Aurora Serverless v2 provides on-demand, auto-scaling capacity, automatically adjusting database resources based on application demand, which can lead to cost savings for intermittent or unpredictable workloads Aurora Serverless v2 details.

While Aurora offers significant advantages in performance and scalability, it is important to note that it is a proprietary AWS service. This can lead to vendor lock-in concerns for some organizations, a common consideration when evaluating managed cloud services versus self-hosted open-source solutions like a standard PostgreSQL deployment PostgreSQL official website. However, its compatibility with MySQL and PostgreSQL application interfaces can mitigate some migration complexities if a move to another platform is required in the future.

Key features

  • MySQL and PostgreSQL Compatibility: Supports applications written for MySQL 5.6, 5.7, 8.0 and PostgreSQL 10, 11, 12, 13, 14, 15, and 16, allowing for migration with minimal application changes Aurora compatibility information.
  • High Performance: Engineered for high throughput, with claims of up to 5x the performance of standard MySQL and 3x the performance of standard PostgreSQL on comparable hardware AWS Aurora performance claims.
  • Scalable Storage: Storage automatically scales from 10 GB up to 128 TB in 10 GB increments, without downtime or performance impact Aurora storage scaling.
  • Fault Tolerance and High Availability: Data is replicated six ways across three Availability Zones, with automatic failover and self-healing storage. Provides continuous backups to S3 Aurora reliability features.
  • Aurora Serverless v2: On-demand, auto-scaling configuration that automatically adjusts database capacity based on application load, billed per second for Aurora Capacity Units (ACUs) Aurora Serverless v2 overview.
  • Up to 15 Read Replicas: Supports high-performance read scaling with low-latency replicas that share the same underlying storage as the primary instance Aurora read replicas documentation.
  • Backtrack: Allows restoring a database to any point in time within the retention period (up to 35 days) without needing to restore from a backup, using a continuous undo log Aurora Backtrack explanation.
  • Global Database: Designed for globally distributed applications, allowing a single Aurora database to span multiple AWS regions with fast cross-region replication Aurora Global Database documentation.
  • Security: Supports encryption at rest using AWS Key Management Service (KMS) and encryption in transit using SSL/TLS. Integrates with AWS IAM for access control and Amazon VPC for network isolation Aurora security features.

Pricing

AWS Aurora pricing is structured based on several components, including instance type, storage consumption, I/O operations, and data transfer. Aurora Serverless v2 introduces a different billing model based on Aurora Capacity Units (ACUs) consumed per second, along with I/O and storage. The information below is generalized as of May 2026; specific rates vary by AWS region and instance class. For the most current pricing, refer to the official AWS Aurora pricing page AWS Aurora pricing details.

Component Description Pricing Model (General)
DB Instances Compute capacity for database operations. Per hour, based on instance class (e.g., db.r6g.large) and region. On-demand, reserved instances, or savings plans available.
Aurora Serverless v2 ACUs On-demand compute capacity for Serverless v2. Per second, based on Aurora Capacity Units (ACUs) consumed. Each ACU is a combination of processing and memory.
Storage Data stored in the Aurora cluster volume. Per GB-month. Automatically scales, so you pay only for what you use.
I/O Operations Read and write operations to the database storage. Per million I/O requests. This is distinct from traditional database I/O, as Aurora's storage architecture handles I/O differently.
Backup Storage Automated backups and manual snapshots beyond the free backup retention period. Per GB-month. Free up to 100% of your database size for a specified retention period.
Data Transfer Data transferred in and out of Aurora, especially cross-region or to the public internet. Per GB, varies by direction and destination. Data transfer within the same AWS region between Aurora and EC2 is typically free.

Common integrations

Alternatives

  • Google Cloud SQL: A fully managed relational database service supporting MySQL, PostgreSQL, and SQL Server, offering similar managed benefits in the Google Cloud ecosystem.
  • Azure Database for MySQL: A fully managed MySQL database service provided by Microsoft Azure, offering high availability and scalability.
  • PostgreSQL: The open-source relational database system itself, which can be self-hosted on various cloud VMs or on-premises, offering full control but requiring more operational management.
  • Amazon RDS: AWS's broader managed relational database service, offering standard MySQL, PostgreSQL, Oracle, SQL Server, and MariaDB engines without Aurora's unique storage architecture.
  • Google Cloud Spanner: A globally distributed, strongly consistent database service built for massive scale, combining relational semantics with non-relational horizontal scalability.

Getting started

To connect to an AWS Aurora MySQL-compatible database using Python, you would typically use the pymysql or mysql-connector-python library. First, ensure you have the necessary library installed:

pip install pymysql

Then, you can use the following Python code snippet to establish a connection and execute a simple query. Replace placeholder values like YOUR_AURORA_ENDPOINT, YOUR_AURORA_USERNAME, YOUR_AURORA_PASSWORD, and YOUR_AURORA_DB_NAME with your actual Aurora cluster details, which can be found in the AWS RDS console.

import pymysql.cursors

def connect_to_aurora():
    try:
        connection = pymysql.connect(host='YOUR_AURORA_ENDPOINT',
                                     user='YOUR_AURORA_USERNAME',
                                     password='YOUR_AURORA_PASSWORD',
                                     database='YOUR_AURORA_DB_NAME',
                                     cursorclass=pymysql.cursors.DictCursor)
        print("Successfully connected to Aurora!")

        with connection.cursor() as cursor:
            # Create a sample table if it doesn't exist
            create_table_sql = """
            CREATE TABLE IF NOT EXISTS users (
                id INT AUTO_INCREMENT PRIMARY KEY,
                name VARCHAR(255) NOT NULL,
                email VARCHAR(255) UNIQUE NOT NULL
            );
            """
            cursor.execute(create_table_sql)
            print("Table 'users' checked/created.")

            # Insert a new user
            insert_sql = "INSERT INTO users (name, email) VALUES (%s, %s)"
            cursor.execute(insert_sql, ('Jane Doe', '[email protected]'))
            connection.commit()
            print("Inserted a new user.")

            # Select all users
            select_sql = "SELECT id, name, email FROM users"
            cursor.execute(select_sql)
            result = cursor.fetchall()
            print("\nAll Users:")
            for row in result:
                print(row)

    except pymysql.Error as e:
        print(f"Error connecting to Aurora: {e}")
    finally:
        if 'connection' in locals() and connection.open:
            connection.close()
            print("Connection closed.")

if __name__ == "__main__":
    connect_to_aurora()

Before running this code, ensure your Aurora security group allows inbound connections from the IP address or security group where your application is running Aurora security group configuration. Also, confirm that the database user has the necessary permissions to create tables and insert data.