Four Things You Didn’t Know About Amazon Aurora

We hear this question a lot: What’s up with Amazon Aurora? When determining the best managed database service for your organization, there are multiple factors to consider – and a common thread running through them all is how much control you need. Amazon is throwing a lot of weight behind its Aurora DBaaS offering, but – depending on your requirements and priorities – choosing to run a database such as MariaDB on Amazon EC2 or a different, non-Amazon service, may be a better fit for you. Here are four things you probably didn’t know about Amazon Aurora.

An aging, outdated database

Amazon Aurora 2.x uses an old version of MySQL 5.7. Aurora 2.0.1 was released in February 2018, using MySQL 5.7.12, itself released in April 2016. Aurora 2.x still uses an old version of MySQL 5.7. However, Amazon no longer publishes the maintenance version it uses. This should come as no surprise. There have been over a dozen MySQL maintenance releases since 5.7.12. How many of the bugfixes contained within them has Amazon backported? 17… out of hundreds.

• Aurora 2.02.0: Bug #22833364
• Aurora 2.02.3: Bugs #24929748, #26867509, #22843444, #25080442
• Aurora 2.03.0: Bugs #24929748, #26867509, #22843444, #25080442
• Aurora 2.03.3: Bugs #25361251, #26734162, #27460607, #22343910, #23074801, #25287633
• Aurora 2.04.0: Bug #26225783
• Aurora 2.04.2: Bug #24829050

If you could choose a new database, would you choose one released over three years ago, one that is missing three years of bug fixes, security patches, improvements and new features?

Required downtime and interruption

Aurora requires downtime for maintenance. While some maintenance is optional, and can be deferred indefinitely, other maintenance such as security and reliability patches are not only required, but result in downtime during a random 30-minute maintenance window. Further, database upgrades (i.e., database engine updates) result in 20-30 seconds of downtime because they are performed on every database instance within a cluster at the same time.  MariaDB Platform, on the other hand, supports rolling upgrades with graceful switchovers, allowing DBAs to perform zero-downtime maintenance on demand. Beyond maintenance and upgrades, Aurora can take up to two minutes to perform an automatic failover, resulting in more downtime. Further, automatic failover results in lost connections, sessions and in-flight transactions. MariaDB Platform, unlike Aurora, supports multi-master clustering to eliminate downtime due to an unexpected failure. In addition, MariaDB Platform supports connection migration, session restore and transaction replay to ensure unexpected failures do not impact applications.

Lack of enterprise security

Aurora lacks many of the enterprise security features expected from modern databases, including a database firewall, dynamic data masking, roles, key rotation and TLS 1.3. Aurora supports the Amazon Key Management Service, but it does not support key rotation for a database instance. Rather, a key alias can be used to change the key for new database instances. As such, even if a new key is added, existing database instances will continue to encrypt and decrypt data using the old key. MariaDB Platform supports key rotation, and when a new key is added, it can automatically re-encrypt the data using the new key – allowing the old key to be discarded. Aurora lacks the powerful database firewall and dynamic database masking features available in MariaDB Platform, and because Aurora is based on an old version of MySQL, it lacks roles as well. Further, it is limited to TLS 1.0, 1.1 and 1.2.

The least common denominator

Aurora provides users with a bare-bones database created using a cookie-cutter template intended to meet the least common denominator. While MariaDB Platform can scale out reads, writes and storage with transparent sharding via the Spider storage engine, or benefit from write- and space-optimized storage on SSDs via the MyRocks storage engine (developed by Facebook), Aurora has neither. It is limited to the InnoDB storage engine. Then there is distributed, columnar storage and massively parallel processing with MariaDB ColumnStore. It is yet another storage engine not available in Aurora. While Amazon would suggest using Aurora for transactional processing and Redshift for analytics, both can be done with MariaDB Platform – enabling hybrid transactional/analytical processing (HTAP). Beyond workload-optimized storage engines, there are many features available in MariaDB Platform that cannot be found in Aurora, including Oracle Database compatibility (i.e., PL/SQL), temporal tables, point-in-time rollback, streaming change-data-capture, an Apache Kafka producer, transparent read/write splitting, check constraints, default value expressions, common table expressions, set operators, window functions, user-defined functions (scalar, aggregate and window), sequences and more. Amazon’s own experience with Aurora illustrates the importance of the considerations above. Shortly after moving some of their databases to Aurora, Amazon experienced widespread outages and other database problems during Prime Day 2018. As Prime Day 2019 approaches, we wish Amazon the best of luck!