Databases on AWS: Amazon Aurora V1 to V2 upgrades
As we already mentioned in our last post about relational databases, AWS Aurora is a high-performance, scalable, monitored, and easy-to-use cloud service that is fully managed and compatible with MySQL and PostgreSQL.
Below we present the improvements to this service, which allow database management to be much more optimal and resilient.
If you found this post interesting, we invite you to download our free Ebook «How to migrate to Amazon Web Services?
Amazon Aurora V1 to V2 Improvements
Among the constant improvements that AWS makes to its service, it introduced a new Amazon Aurora modality with different improvements and differences depending on the use case, Aurora Serverless V2 It is a serverless mode that allows scaling to hundreds of thousands of transactions in a fraction of a second. 
.
Furthermore, it supports a wide range of workloads, from testing environments or applications with infrequent workloads to applications that require high scalability and availability , and is compatible with other Aurora features.
1. Scalability
Aurora Serverless V1: scales automatically, but cannot do so while there are connections to the database to scale; you have to wait until there are no ongoing transactions or configure the database to scale independently.
Aurora Serverless V2: In contrast, version 2 offers improvements in scalability; instances automatically scale in milliseconds based on application load, whether up or down.
2. Failover and read replicas
Aurora V1: An Aurora Serverless V1 cluster functions as a single read/write instance without read replicas. In case of failure, a new master will be created, but during this time it will not have a database.
Aurora V2: An Aurora Serverless cluster has full failover and read replica capabilities for regularly provisioned Aurora clusters. If the master fails, one of the read replicas acts as a dynamic spare, minimizing application disruption.
3. Clusters
Aurora V1 clusters are completely separate from normal provisioned databases and cannot be natively mixed.
Aurora V2 , on the other hand, allows you to use a combination of provisioned database instances and serverless database instances in the same cluster , enabling you to generate burst capacity in your traditional database clusters.
4. Data API
With Serverless V1 we had a “ Data API ” that exposed the serverless database through a simple HTTP endpoint and granted access to the endpoint with IAM permissions.
However, Serverless V2 does not have a data API , making it more difficult to use with Lambda functions.
5. Zero scaling
Aurora V1 can scale down to 0 ACU and automatically scale when requests are made.
Aurora V2 instances do not allow scaling down to 0 but up to 0.5 ACU and only scale up to 256 GB of RAM and not 768 GB of RAM.
6. Multi AZ
One of the limitations customers encountered with Aurora V1 was the lack of Multi-A-Z availability. To address this, Multi-AZ clusters have been integrated into Aurora version 2, allowing the distribution of database instances across multiple Availability Zones . Configuring a Multi-AZ cluster helps ensure business continuity.
In conclusion, Aurora V1 is a recommended option for infrequent, intermittent, or unpredictable workloads, such as low-use applications, while Aurora V2 is more focused on database workloads, from development and testing environments to the most demanding mission-critical business applications.
At Apser, we have experts to help you with your cloud migration process through a customized roadmap. Contact us ; we'd love to learn about your project.
