Amazon Aurora Reviews

Aurora is great for situations where databases require autoscaling and need high availability. For example, high traffic websites running on an autoscaling compute layer can benefit by being connected to a datastore that can scale along with them. Also any scenario that requires fault tolerance can benefit greatly from Aurora. Knowing that your DB can heal itself (to the best of its ability) can give developers and engineers confidence that their application will handle adverse scenarios in the event of failure conditions. Given the premium of running DBs with Aurora, I would not recommend using it for development environments. Given that Aurora is compatible with most common DB software, development environments can use cheaper, smaller RDS instances. When it comes time for deploying into a production environment, no changes would be needed.

AWS has been top notch in providing support for Aurora and RDS as a whole. For the most part, there is rarely ever a need to request support for our database deployments. The only interactions I can think of off hand are asking for increases in the number of instances we can deploy.

It's not obvious to plan database capacity for a year out, so I usually avoid buying reserved instances. However, the ability to buy “Reserved ACUs” would be something interesting concept. That way you could prepay for hours of capacity at a discounted rate. If your load is stable but peaks at certain times, go for an Aurora Serverless, it will be way cheaper than reserved instances.

I never had issues with Aurora that forced me to deal with support. It has been stable and reliable so far, at least in my experience and my team's.

The support as a whole cannot be applied to just Aurora, but I must say that the response to our tickets from the AWS side was a bit anemic. Despite that, there is plenty of documentation and forum articles that should make anybody self-serviced. Again, let me stress this out - the product (in either MySQL or Postgres form) was used by many people and thus now well understood, explained and there are plenty of books and other material available. This is not the case that we encountered with NoSQL.

Amazon Aurora is best suited for creating complex, highly available and commercial databases, in a very straightforward way. The database size should be medium to large because only then will you be able to justify the extra cost incurred for using Amazon Aurora. Another aspect is that if you are already using AWS and most of your applications and services are on the cloud, then it makes sense to use Amazon Aurora since it fits in the Amazon ecosystem really well.

Variable read load. Being able to autoscale your DB is amazing. Operationally, not worrying about failover is also amazing. Outside of Aurora/RDS, Postgres failover is always a big pain. Even on plain RDS, there's some concern with data loss in a failover.

We've hit a number of known bugs and have to wait for a minor release to get them fixed. We've also hit some reproducible bugs and we're met with a lot of resistance from support as we shared them.

Amazon Aurora is an ideal and industry-leading storage subsystem that allows you to manage costs utilizing the data but also accessing the data with incredible speed. The database engine seems to really leverage the benefits of Amazon's distributed storage and scaling of that storage. Aurora eliminated numerous manual processes and reduces operational overhead in processing & replication. Depending on how often and quickly you need access to those databases will determine if this is a fit for your organization. If you need constant hot storage and access full time this is not ideal. If you can tolerate the process of a query than this is highly effective.

For workloads that already use, or plan on using, MySQL or PostgreSQL, Aurora is our new go-to favorite deployment option for projects on AWS. The best use cases for Aurora will be substantial workloads that are well-suited to the simple scaling controls (both from an instance type perspective, as well as storage perspective), and will benefit from Aurora's simple, very low latency read replicas. Aurora is extremely fault tolerant and has improved self-healing ability.

Many places where Aurora is well suited:

• If you are trying to build a serverless backend.
• Amazon hosted relational database service (RDS). So we do not have to manage the database maintenance.
• Backup and archival can be done to AWS S3, which is very convenient.
• It provides high performance and scalability.
• It's very secure. You could use AWS Key management service (KMS) to encrypt and store data on AWS Aurora.

It works very well with mySQL and can supplement it very nicely with much faster performance and its ability to scale up as well as replicate data across multiple clusters. In addition it is very well suited for large workloads of an enterprise that is looking to get up and running quickly on a managed RDBMS service without worrying about licenses/provisioning and the like.

When already using a relational database, either MySQL or PostgreSQL, the change to Amazon Aurora should be very straightforward. The main benefits you get are cost efficiency and ease with regards to the storage, as it scales with you, and managing clusters including failovers are made very straightforward for you.

If you are looking for a database which can scale up and down quickly with demand, Aurora may not be the best fit. However, there is now an Amazon Aurora Serverless service which attempts to address this requirement. I do not have any experience with it, so cannot comment further - but it is possible it will fit your use-case.

Amazon Aurora should be considered for those who need a fast and reliable cloud database service. It includes the main features of a MySQL database, using the latest trends in architectural principals. It ensures out-of-the-box fault-tolerance and high scalability. It is also very important for those who don’t want to worry about features and security updates. As the price is higher than a standard MySQL for instance, it should only be considered for higher applications where performance and scalability is really important.

Amazon Aurora Serverless is great for micro-services and serverless. If DynamoDB's pricing structure and management appeal to you, but you want a RDBMS, consider Amazon Aurora Serverless. If you have a microservices architecture and are apprehensive about the cost of one-RDS-instance-per-service for every test cluster, consider Amazon Aurora Serverless. Aurora MySQL lacks many features you'd expect from PostgreSQL; the absence of these features may be more tolerable for OLTP use-cases than OLAP use-cases.

Amazon Aurora (as is MySQL) is better suited for light to medium applications considering it still has some performance limitations from MySQL. I would not recommend it for enterprise level use without a carefully constructed backend system (code and database). My company's current backend architecture was not mapped out very well and this leads to performance problems that even Amazon Aurora has not been able to completely sort (although it has been a huge help).

Another area where I am finding it beginning to lack is for use in data warehousing. The more rows added, the less performant I'm finding the data warehouse. Although to be fair, Amazon has another product (Redshift) that we are looking to migrate data warehouses into.