||According to Amazon, Aurora offers five times the performance of a standard deployment of a MySQL instance.
||The performance of RDS is good.
||The Amazon Aurora database engine is designed to be compatible with MySQL 5.6
||Supports MySQL versions 5.1, 5.5, and 5.6.
||Supports only InnoDB. Tables from other storage engines are automatically converted to InnoDB.
||Supports InnoDB, MyISAM and many others
|Availability according to region
||Amazon Aurora is currently available in the US West (Oregon), US East (N. Virginia), and EU (Ireland) AWS regions.
||Available in all AWS regions
|Simulation for crash testing
||Simulation of node, disk, or read replica failure for testing/HA using queries
||No support for simulating crashes for testing purpose using queries
||Supports highly concurrent workloads.
||Supports normal workloads.
||Amazon Aurora storage is fault-tolerant, self-healing, transparently handling the loss of up to two copies of data without affecting database write availability and up to three copies without affecting read availability. Amazon Aurora automatically maintains 6 copies of your data across 3 Availability Zones and will automatically attempt to recover your database in a healthy AZ with no data loss. The minimum storage is 10GB. Based on your database usage, your Amazon Aurora storage will automatically grow, up to 64 TB, in 10GB increments with no impact to database performance.
||There is no automatic growth of storage.
||Amazon Aurora uses SSL (AES-256) to secure data in transit. Encryption for data at rest will be available in a future release.
||Amazon RDS encryption uses AWS Key Management Service (KMS) to let you create and manage the keys used to encrypt your data.
||Amazon Aurora supports two kinds of replicas.
1. Amazon Aurora Replicas share the same underlying volume as the primary instance. There can be maximum of 15 Aurora replicas.
2. MySQL Read Replicas based on MySQL’s binlog-based replication engine. In MySQL Read Replicas, data from your primary instance is replayed on your replica as transactions.
|It support only read replica. There can be maximum of 5 read replica
||The minimum instance of Aurora start from db.r3.large. Hence, it is costlier than RDS for MySQL. With Amazon Aurora you pay only for the storage that you use.
||RDS MySQL is cost effective, especially as it is currently available on lower-spec VMs. With MySQL RDS, you pay for the storage that is attached to your VMs whether you are using it or not.
|Backup and its impact on DB performance
||Amazon Aurora backups are automatic, incremental and continuous and have no impact on database performance.
||Amazon RDS automatically performs a full daily snapshot of your data (during your preferred backup window) and captures transaction logs (as updates to your DB Instance are made). During the backup window, storage I/O may be suspended while your data is being backed up and you may experience elevated latency. This I/O suspension typically lasts for the duration of the snapshot.
|Failure Detection and Correction/Resilience
||Aurora can detect a database failure and recover in less than a minute, without the need to rebuild (or “warm”) the database caches that are needed to speed response times. In the case of a permanent failure, Aurora can automatically failover to a replica without losing any data.
||Failovers, as defined by the interval between the detection of the failure on the primary and the resumption of transactions on the standby, typically complete within one to two minutes.
||Crash recovery is very fast as compared to RDS for MySQL. Amazon Aurora does not need to replay the redo log from the last database checkpoint (typically 5 minutes) and confirm that all changes have been applied, before making the database available for operations.
||Crash recovery is slow as compared to Aurora. It has to replay the redo log since last check point, which is single threaded in MySQL.
|Replication/Multi AZ Failover
||Unplanned failover takes place within minutes. Failover to a replica, if you maintain multiple instances, is almost immediate and automatic, since all replicas use the same logging and storage layers.
||Unplanned failover typically completes within one or two minutes and is not automatic in case of read replica.
||Aurora supports incremental backups.
||No support for incremental backups
||Aurora also isolates the database buffer cache from the database process, allowing the cache to survive a database restart.
||The buffer cache and database share the same process so cache will not be flushed to disk if you restart the instance.
||There is negligible lag between updating the primary instance and reading the data back from a read replica since they are sharing same storage. Almost 400x TIMES lowered read replica lag over MySQL.
||Replication lag will be high as compared to Aurora replica.
|Read Replicas with a different storage engine than the master instance
||MySQL (non-RDS) read replicas that replicate with an Aurora DB cluster can only use InnoDB.
||Read replicas can use both MyISAM and InnoDB.
|Database engine parameters
||Some parameters apply to the entire Aurora DB cluster and are managed by DB cluster parameter groups. Other parameters apply to each individual DB instance in a DB cluster and are managed by DB parameter groups.
||Parameters apply to each individual DB instance or Read Replica and are managed by DB parameter groups.