Amazon Aurora

Amazon Aurora is a fully managed relational database engine offered by AWS as part of Amazon RDS. It is designed to provide the performance and availability of high-end commercial databases (like Oracle or SQL Server) at a fraction of the cost, while being compatible with MySQL and PostgreSQL. The core problem it solves is the trade-off between performance, durability, and cost in traditional database solutions. Standard MySQL or PostgreSQL deployments on EC2 require significant manual effort for replication, backups, and failover. Even managed RDS for MySQL/PostgreSQL uses a shared storage model that can become a bottleneck. Aurora reimagines the storage layer entirely.

Aurora separates the compute (database engine) from the storage (distributed volume). The storage layer is a virtualized, SSD-backed volume that is automatically replicated across three Availability Zones (AZs) within a single AWS Region. Each AZ contains two copies of the data, for a total of six copies. This 6-way replication ensures that data is durable even if an entire AZ fails. The storage volume auto-scales from 10 GB up to 128 TB, with no downtime. Write operations are sent to all six storage nodes, and the system commits the transaction only after a quorum of four nodes acknowledges the write. This quorum-based approach allows Aurora to tolerate the loss of up to two copies without affecting write availability, and up to three copies without losing data.

The compute layer consists of one primary instance (handles reads and writes) and up to 15 Aurora Replicas (read-only). Aurora Replicas share the same storage volume, so there is no replication lag (unlike standard MySQL replication). The primary writes to the storage, and replicas read from the same storage with minimal latency. If the primary fails, Aurora automatically promotes one of the replicas to primary in less than 30 seconds, with no data loss. This failover is faster than standard RDS Multi-AZ because the storage is already shared.

Aurora offers two main editions: Aurora MySQL (compatible with MySQL 5.7, 8.0) and Aurora PostgreSQL (compatible with PostgreSQL 11, 12, 13, 14, 15). Both support the same features but have slight differences in limits and extensions. Aurora also offers Aurora Serverless v2 (auto-scaling compute capacity) and Aurora Global Database (cross-region replication with fast failover).

Pricing: You pay for: - Compute: per hour for the DB instance (e.g., db.r6g.large, db.r6g.xlarge). - Storage: per GB-month for the allocated storage (I/O is included in Aurora, unlike standard RDS where you pay for I/O separately). Aurora's storage billing is based on the high-water mark (the maximum storage used during the month). - Data transfer: out to internet or cross-region.

Aurora Serverless v2 charges per Aurora Capacity Unit (ACU) per second, scaling from 0.5 ACU to 128 ACU. It can scale to zero when idle (if using Aurora Serverless v1, but v2 scales to zero only with some configurations).

On-premises databases require purchasing hardware, setting up replication, managing backups, and handling failover manually. Aurora automates all of this. Compared to standard RDS MySQL/PostgreSQL, Aurora offers: - Higher performance: up to 5x faster than MySQL and 3x faster than PostgreSQL on the same hardware. - Better durability: 6 copies across 3 AZs vs RDS's 2 copies (single AZ or Multi-AZ with synchronous replication to one standby). - Faster failover: less than 30 seconds vs 1-2 minutes for RDS Multi-AZ. - Auto-scaling storage: up to 128 TB vs 16 TB for RDS MySQL.

However, Aurora is more expensive per hour than RDS for the same instance size. Use Aurora when you need high performance, high availability, and low maintenance. Use standard RDS for simpler workloads where cost is a primary concern.

The exam expects you to know that Aurora is a relational database (not NoSQL), that it is MySQL/PostgreSQL compatible, and that it provides higher performance and availability than standard RDS. Also know that Aurora Global Database allows cross-region replication with a typical RPO of 1 second and RTO of 1 minute.

To create an Aurora MySQL cluster using the AWS CLI:

aws rds create-db-cluster \
    --db-cluster-identifier myauroracluster \
    --engine aurora-mysql \
    --engine-version 8.0.mysql_aurora.3.02.0 \
    --master-username admin \
    --master-user-password password123 \
    --db-subnet-group-name mydbsubnetgroup \
    --vpc-security-group-ids sg-12345678

Then create a primary instance:

aws rds create-db-instance \
    --db-instance-identifier myaurorains1 \
    --db-cluster-identifier myauroracluster \
    --engine aurora-mysql \
    --db-instance-class db.r6g.large

To add an Aurora Replica:

aws rds create-db-instance \
    --db-instance-identifier myaurorareplica1 \
    --db-cluster-identifier myauroracluster \
    --engine aurora-mysql \
    --db-instance-class db.r6g.large \
    --promotion-tier 1

Aurora is a high-performance, highly available relational database service that is fully managed, MySQL/PostgreSQL compatible, and uses a distributed storage architecture with 6-way replication across 3 AZs. It offers fast failover, auto-scaling storage, and up to 15 read replicas. For the exam, focus on its compatibility, durability, performance advantages over standard RDS, and the specific features like Aurora Replicas, Serverless, and Global Database.

An online retailer runs a MySQL-based e-commerce platform on AWS. They previously used a single RDS MySQL instance with Multi-AZ for failover. However, during Black Friday, the database became a bottleneck due to high read traffic (product catalog queries, order lookups). They migrated to Aurora MySQL. The primary instance handles writes (orders, inventory updates), and they added 5 Aurora Replicas to distribute read traffic. The replicas are in different AZs, ensuring that even if one AZ fails, the application can still serve reads. During a recent AZ outage, the primary failed, and Aurora promoted a replica to primary in under 30 seconds. The application experienced only a brief pause, and no data was lost. The retailer now pays for compute (6 instances) and storage (auto-scales), but the cost is justified by zero downtime during peak sales. Misconfiguration: if they had set all replicas to the same failover priority, the promotion order would be arbitrary, but still works. A common mistake is not enabling Performance Insights, making it hard to identify slow queries.

A SaaS company provides a project management tool that experiences unpredictable usage spikes. They chose Aurora Serverless v2 for its ability to scale compute from 0.5 ACU to 64 ACU based on demand. During off-peak hours, the database scales down to 0.5 ACU, saving costs. When a customer runs a large report, the ACUs scale up automatically in seconds. The company uses Aurora Global Database to replicate data to a secondary region for disaster recovery. They set up a secondary cluster in us-west-2 (primary is in us-east-1). If the primary region fails, they can promote the secondary to primary with an RTO of about 1 minute. Misconfiguration: they initially set the minimum ACU too high (16 ACU), leading to unnecessary costs. After adjusting to 0.5 ACU, costs dropped 70%. Also, they forgot to enable backtrack, which would allow them to undo accidental data changes without restoring from backup.

A financial institution needs a highly durable database with cross-region replication for compliance. They use Aurora PostgreSQL with Global Database. The primary cluster is in eu-west-1 (Ireland), and they have a secondary cluster in eu-central-1 (Frankfurt) for disaster recovery. They also use AWS Backup to manage backups across regions. The storage is 6-way replicated, meeting their durability requirement of 99.999999% (11 nines). They set backup retention to 35 days and take daily manual snapshots for archival. During a compliance audit, they demonstrated that data is encrypted at rest using AWS KMS and in transit using TLS. A common pitfall: they initially used standard RDS PostgreSQL, but the failover time of 2 minutes was too slow for their SLA. Switching to Aurora reduced failover to under 30 seconds. They also learned that Aurora Global Database replication is asynchronous, so there is a small RPO (typically < 1 second), which is acceptable for their use case.