Explore the powerful features of Aurora Serverless V2 for MySQL in this informative blog series. Learn about read-only scaling, parameter support, and cost performance. Compare costs between Provisioned Aurora and Aurora Serverless V2. Discover key takeaways for optimizing your MySQL deployment on the cloud. Read now!

1. Read-only Scaling
   1. Failover replicas
   2. Independent replicas
2. Parameters support
   1. Cluster-Level Parameter Groups
   2. Instance-Level Parameter Groups
3. Cost performance
   1. Aurora Serverless instance cost
   2. Aurora data cost
   3. Additional charges
4. Cost Comparison
   1. Provisioned Aurora
   2. Aurora Serverless V2
5. Key Takeaways

In this third installment of our blog series on Aurora Serverless V2 for MySQL, we will delve into some exciting features this powerful database service offers. In the previous blogs, we covered topics such as launching Serverless V2, vertical scaling, and data migration to Aurora Serverless V2.

Today, we will explore three key areas: read-only scaling, parameter support, and cost performance. Throughout this blog, we’ll provide valuable insights and tips to help you make informed decisions and maximize the benefits of Aurora Serverless V2 for MySQL. So, join us on this journey as we explore the powerful capabilities of Aurora Serverless V2 and empower you to optimize your MySQL deployment on the cloud. Let’s get started!

Read-only Scaling

Read-only scaling in Aurora ServerlessV2 allows you to handle higher read workloads by creating up to 15 read replicas simultaneously. You can create read replicas during the initial launch by selecting the appropriate option in the launch wizard.

Additionally, you can add read replicas to your cluster after launching the first instance.

There are two types of read replicas based on their priority:

Failover replicas

These replicas, created with tier 0 and tier 1 priorities, function as fail-over replicas. They automatically scale with the writer instance and act as hot standby replicas.

Independent replicas

Replicas created with tier 2 to 15 priorities are known as independent replicas. They can scale based on their individual load, providing scalability according to their specific needs.

The reader endpoint of Aurora ServerlessV2 comes with a highly available ‘RO’ (read-only) endpoint. It balances the read requests across the available read replicas using a round-robin algorithm.

If you have multiple readers in your cluster, it is recommended to choose “Failover Priority” as tier 0 or 1.

Make any other necessary changes according to your preference and click “create read replica” to add the replica to your cluster.

Parameters support

In Aurora Serverless V2, parameter support allows you to configure settings for your database. The parameter group and cluster parameter group used in provisioned Aurora 8 versions can also be shared and used in Aurora Serverless V2. This ensures compatibility and ease of configuration when transitioning between the two versions.

Cluster-Level Parameter Groups

Cluster-level parameter groups are applied to the entire Aurora Serverless V2 cluster, meaning they affect all nodes within the cluster. When creating a cluster, you have the option to specify a cluster-level parameter group to use. You can also customize and modify the attached parameter group according to your specific requirements.

Instance-Level Parameter Groups

Instance-level parameter groups allow you to configure settings that specifically impact the behavior of individual instances. With instance-level parameter groups, you can create your own parameter group and modify only the parameters that are allowed to be changed. This enables you to fine-tune the settings for each instance based on your needs.

Cost performance

Cost performance is an important aspect to consider when using Aurora Serverless V2. Unlike some serverless services where you pay only for the number of requests or calls made, Aurora ServerlessV2 operates differently. Here, you are billed based on the minimum ACU (Aurora Capacity Unit) capacity you have procured, regardless of whether it is actively used or not. You should take into account three primary cost factors:

Aurora Serverless instance cost

The cost is determined by the capacity consumed, which can vary based on the load pattern and the minimum and maximum scaling units you have defined.

Aurora data cost

You are billed on a monthly basis per GB of data stored. The cost is influenced by data growth and IO (Input/Output) usage, which is billed in per million request increments.

Additional charges

Certain features, such as backtrack, Global databases, Snapshot export, and data transfers, may incur additional charges.

It’s important to be mindful of these cost factors and consider them when planning your Aurora Serverless V2 deployment.

Cost Comparison

Let’s compare the costs between Provisioned Aurora and Aurora Serverless V2, assuming a constant memory of 128GB (since the CPU allocation for Serverless V2 is unknown).

Provisioned Aurora

Instance type: r5.4xlarge (128GB RAM & 16 Cores)

With Provisioned Aurora, 100% of the capacity is always available for use. The cost for the above instance is $1927.20.

Calculation:

1 instance x $2.64 USD hourly x (100 / 100 Utilized/Month) x 730 hours in a month = $1927.20

Aurora Serverless V2

Capacity: 64 ACUs (to match 128GB RAM)

Serverless V2 claims to provide a 90% cost saving compared to other options, but this is only when running in the minimum capacity mode.

Serverless V2 costs $0.18 per ACU per hour, which is twice the cost of Serverless V1 ($0.09 per ACU hour). The cost for 128GB RAM with Serverless V2 is $8,409.60.

Calculation:

64 ACUs per hour x 730 hours in a month x $0.18 = $8,409.60

The comparison shows that Aurora Serverless V2 is approximately 4.3 times more expensive than the regular Aurora.

Based on these cost considerations, it’s important to weigh the benefits and costs of each option when making a decision.

Key Takeaways

• Aurora Serverless V2 is ideal for workloads that experience spikes in usage and where it’s difficult to predict the application workload.
• It offers on-the-fly vertical scaling, allowing the database to adapt to changing demands in real time.
• With Aurora Serverless V2, you can avoid extensive planned downtime when scaling your database.
• However, it’s important to note that the cost of using Aurora Serverless V2 tends to be on the higher side compared to other options.

If you enjoyed reading this blog post, we encourage you to explore more articles on our website. Our collection covers a wide range of topics, including database consulting, support, and various tech-related subjects. You’ll discover valuable insights, tips, and information that can benefit your business or career. Take a look and find something that piques your interest!

Check out our recent blog on Exploring Aurora serverlessV2 for MySQL Part 2 – Migration

If you require expert assistance with your database management, we are here to help. Our team of experienced professionals specializes in providing tailored solutions to meet your specific needs. Whether it’s ensuring data security, optimizing performance, or maintaining high availability, we have the expertise to streamline your operations. Contact us today to learn more about how we can maximize the value of your MySQL Performance and Operations and provide you with peace of mind.