Understanding Amazon Aurora Serverless Pricing
You'll learn what Amazon Aurora Serverless pricing is and how to determine if it's the right choice for you.
You'll learn what Amazon Aurora Serverless pricing is and how to determine if it's the right choice for you.
When you look at a standard serverless architecture, it's probably using DynamoDB for its database. But what if your data requires a SQL database, and you want to take advantage of managed services? That's precisely where Aurora Serverless fits in.
In this post, we'll learn what Aurora Serverless v1 and v2 are, and we'll take a look at their differences. Next, you'll learn how AWS charges for their use, and what situations they work best in. Finally, you'll see a few ways to optimize their cost.
Amazon Aurora is the AWS solution for running Postgres and MySQL databases in a cloud-friendly way. Even though they look like a standard database when interacting with them, the data storage layer has been changed to support high reliability, availability, and scale.
Aurora is a battle-tested solution, but you still have to manage some aspects of it, like scaling. Amazon had a first pass at managing that for you with Aurora Serverless v1. An Aurora Serverless v1 instance scales your Aurora database up and down to match its current load. When the instance isn't used, it scales itself to zero.
If you tried to lift and shift an Aurora database over to a serverless instance, your application would likely be littered with ridiculous queries that ran for a long time.
The problem with those big queries is that they block Serverless v1 instances from scaling. This could cause the database to run out of resources with which to complete the query, but it couldn't scale up before the query completed. It could be a mess.
The problem with those big queries is that they block Serverless v1 instances from scaling
Aurora Serverless v1 can easily get blocked from scaling since it can only scale when it's in a particular state called a scaling point. It can also only scale in increments of 2x. So if your serverless DB is set to two capacity units, it will scale up to four units as its next step.
Aurora Serverless v2 changes this scaling paradigm. It makes much more frequent, smaller scaling adjustments. It doesn't interrupt any ongoing operations when scaling, so it doesn't have to look for a scaling point before increasing capacity.
Serverless is all about pay-for-use billing. But pay-for-use can get complicated when talking about a database cluster, since there are several ways to define "use." The main things you need to consider are compute capacity, storage capacity, and moving data. Currently, both the MySQL and PostgreSQL versions of Aurora have the same cost, but that may change in the future. Please refer to the Aurora pricing page for up-to-date pricing information.
Aurora Serverless automatically scales its compute capacity using a special unit called an Aurora Capacity Unit, or ACU. An ACU corresponds to 2 GB of RAM allocated to a database instance.
When creating your cluster, you specify the minimum and maximum number of ACUs you want it to scale between. You can also configure your clusters to scale to zero ACUs after a certain period of inactivity.
Aurora automatically provisions storage for your database and scales it up and down as needed. As a result, you don't have to specify how much storage your database will need up front. It also means you won't have to migrate to a new database instance when you run out of space.
Aurora charges for storage based on the GB/month unit. This unit considers the amount of storage and how long the storage is used.
Assuming you don't delete anything from your database, if you have 1 GB at the start of the month, you'll be charged 1 GB/month to store it. Adding another 1 GB of data on the 15th will cost an additional 0.5 GB/month to store. Your final bill will be 1.5 GB/month for that month. If you don't add any more data during the next month, you'll be charged 2 GB/month to store the same data.
Aurora also charges based on the number of database page reads and writes. The price for a write operation does have a minor condition, since it's actually per write up to 4KB in size. For example, you'll be charged for two write operations if you have a write operation that stores 5KB in your database.
This last fee applies to any AWS service that you use. It's free when you transfer data into an AWS service from the internet. That makes complete sense, since AWS wants to make onboarding as cheap as possible.
But AWS charges you to transfer data from Aurora to other AWS regions at a set price per target region. AWS charges a higher fee per GB when you transfer data to the internet, but it decreases as you transfer more data.
Now you know how Aurora charges for serverless instances. How do you determine if they're the right choice? We get some hints on the Amazon Aurora FAQ page in the section "What is Amazon Aurora Serverless?"
The answer to the question is all about how you're managing database capacity. Aurora Serverless does cost more than an on-demand instance if you're running it constantly. You have to decide if you'll save enough money to offset the difference when the instance is scaled down. Keeping this in mind, there are a couple of types of workloads that Aurora Serverless is perfect for.
When you create a new project, you may have no idea how much capacity you actually need. This is a great time to use an Aurora Serverless instance. You can start running against it and monitor it for a few months before deciding how much capacity to provision.
When you create a new project, you may have no idea how much capacity you actually need
Another great use case for a serverless instance is intermittent workloads. Maybe you run batch processing once a day, or there are one or two hours where traffic to your site is busy. If you're using a serverless instance, it can scale up quickly to meet the demand for those short periods of time and then scale back down when the demand diminishes.
Serverless instances are perfect for testing environments. The low, inconsistent demand for a development or staging environment is an ideal use case. You can also set up your instance to pause so you don't have to pay for any compute resources while no one is working with it.
The essential step to cost optimization is to ensure you're using Aurora Serverless for the right workload. Below are some more tips for optimizing your costs.
If you need to store multiple databases, split them out over multiple clusters. Doing this allows each cluster to scale independently based on the demand for its specific database.
If you're using Aurora Serverless v1, you need to avoid scale-blocking operations. These keep your instance locked in a state where it doesn't have enough capacity, but it can't scale up to meet demand. There are a few things to keep in mind so your instance can easily scale up and down. You can get more details from this AWS article on best practices.
Keep your queries and transactions simple. They should complete quickly, since long-running transactions degrade performance and block serverless instances from scaling.
Avoid temporary tables and table locks because they block scaling. Clean up any temporary tables or locks once you no longer need them.
Aurora Serverless v2 does scale a lot better than v1. But it's also currently 2x the price of v1. So if your workload doesn't need to scale up or down instantly, and you can avoid scale-blocking operations, you can easily cut your bill in half by using Serverless v1 instances.
Avoid temporary tables and table locks because they block scaling
As with any managed service, you need to consider the trade-offs. For example, if you're running a production workload on Aurora Serverless that never scales down, you may be paying a premium for a feature you aren't using.
For example, imagine if your instance is constantly scaled to 4 ACUs. As I'm writing this, the current pricing for a single Aurora Serverless v2 ACU in the US East region is $0.12 per hour. So that means you'll be paying $0.48 per hour to run that workload.
If you were to run that same workload on an on-demand instance, you could choose the db.t4g.large instance type to get an equivalent 8 GB of RAM. That instance would cost you $0.146 per hour. That's about a 70% discount. You can save even more if you create a reserved instance, where you'll pay only $0.115 per hour. That bumps your savings up to 76%!
In short, if you know your workload and it's consistent, you can reduce your bill a lot by provisioning a reserved instance.
In this post, you've seen how to determine if Aurora Serverless is the right choice for your project. You've also seen a few ways to keep costs down and take full advantage of Aurora Serverless's auto-scaling abilities. Taking your own needs into consideration, you should now be able to make an informed decision as to whether Aurora Serverless will benefit your projects and operations.
If you'd like to get some more context into where your AWS costs are going, Cloudthread has a product that gives each of your development teams insights into their cost efficiency.
