Core Concepts & Features
Storage and Reliability
- Self-Healing Storage: Aurora's storage is fault-tolerant and self-healing. Data is striped across hundreds of volumes.
- High Durability: It maintains six copies of your data across three Availability Zones (AZs). It is designed to transparently handle the loss of up to two copies of data without affecting write availability and up to three copies without affecting read availability.
- Automatic Backups: Continuous backups to Amazon S3 with no performance impact. Point-in-time recovery is supported.
- Storage Auto-Scaling: The storage volume automatically grows in increments of 10 GB as needed, up to 128 TiB, without requiring you to provision storage in advance.
Performance and Scalability
- High Throughput: Delivers up to five times the throughput of standard MySQL and up to three times the throughput of standard PostgreSQL running on the same hardware.
- Low-Latency Read Replicas: Supports up to 15 low-latency read replicas, which share the same underlying storage as the primary instance, resulting in minimal replica lag (often single-digit milliseconds).
- Push-Button Compute Scaling: You can scale the CPU and memory resources powering your cluster up or down by changing the DB instance class.
Security
- Network Isolation: Runs in Amazon VPC, allowing you to isolate your database in your own virtual network.
- Encryption at Rest: Data is encrypted at rest using AWS Key Management Service (KMS). This includes the underlying storage for database clusters, automated backups, snapshots, and replicas.
- Encryption in Transit: Supports SSL/TLS to encrypt data in transit.
- IAM Database Authentication: Allows you to manage database access using IAM users and roles instead of traditional passwords.
Aurora Architecture & Components
An Aurora deployment consists of a DB cluster which contains one or more DB instances and a cluster volume that manages the data for those instances.
Aurora Cluster Endpoints
Aurora provides several endpoints to abstract connections and simplify routing.
-
Cluster Endpoint (Writer Endpoint):
- Connects to the primary (writer) DB instance in the cluster.
- This is the only instance that can perform write operations (DDL, DML).
- It provides failover support. If the primary instance fails, the endpoint automatically redirects to the newly promoted primary.
-
Reader Endpoint:
- Provides load-balancing for read-only connections across all available Aurora Replicas in the cluster.
- Ideal for distributing read-intensive workloads.
-
Custom Endpoint:
- An endpoint for a user-defined subset of DB instances.
- Useful for directing specific workloads to specific instances. For example, you can create a custom endpoint for replicas with higher capacity to serve analytics or reporting queries, while another endpoint directs transactional queries to other replicas.
-
Instance Endpoint:
- Connects to a specific DB instance within the cluster.
- Typically used for diagnostics, tuning, or specific administrative tasks where you need to connect to a particular instance regardless of its role (primary or replica).
Aurora Replicas vs. MySQL/PostgreSQL Replicas
Feature | Amazon Aurora Replicas | Standard MySQL/PostgreSQL Replicas |
---|---|---|
Number of Replicas | Up to 15 | Up to 5 (MySQL), Varies (PostgreSQL) |
Replication Type | Asynchronous (milliseconds lag) | Asynchronous (can be seconds of lag) |
Performance Impact on Primary | Low | High |
Failover Target | Yes (no data loss) | Yes (potential for data loss) |
Automated Failover | Yes | No (manual promotion) |
Support for User-Defined Delay | No | Yes |
Support for Different Schema | No (share the same storage volume) | Yes |
Key Aurora Capabilities
Aurora Serverless
- An on-demand, auto-scaling configuration for Aurora.
- Automatically starts up, shuts down, and scales capacity up or down based on your application's needs.
- Ideal for infrequent, intermittent, or unpredictable workloads. You pay on a per-second basis for the database capacity you use when the database is active.
Aurora Global Database
- Spans multiple AWS Regions to provide low-latency global reads and disaster recovery.
- A single Aurora database can have dedicated read-only replicas in up to five secondary AWS Regions.
- Enables fast failover (typically less than a minute) to a secondary region in a disaster scenario.
Aurora Backtrack
- Allows you to "rewind" the DB cluster to a specific point in time, without restoring data from a backup.
- It's extremely fast (takes minutes) and is useful for recovering from user errors, such as dropping the wrong table or deleting the wrong row.
- Note: Backtrack is not a replacement for backups and snapshots.
Parallel Query (Aurora MySQL)
- An optimization that parallelizes the I/O and computation involved in processing data-intensive analytical queries.
- It pushes query processing down to the Aurora storage layer, reducing network traffic and speeding up queries.
Scaling Your Cluster
- Instance Scaling: Scale compute resources vertically by changing the DB instance class of the instances in your cluster (e.g., from
db.r6g.large
todb.r6g.xlarge
). - Read Scaling: Scale read throughput horizontally by adding more Aurora Replicas to your DB cluster. Connections can be distributed across replicas using the reader endpoint.
Security
IAM Database Authentication
- Instead of using a password, you can request a temporary authentication token generated by IAM.
- This token is used to connect to the DB cluster.
- Centralizes access management through IAM and avoids hardcoding database credentials in application code.
Advanced Auditing (Aurora MySQL)
- Provides robust capabilities to audit database activity, helping with compliance and security analysis.
- You can configure it to log events like connections, queries, and DDL statements by setting specific DB cluster parameters.
Sources