Aurora Serverless recently moved out of beta and into “generally available” (GA) status. It was announced at last year’s AWS re:Invent conference and builds upon Amazon Aurora by offering a serverless option. It’s an on-demand, auto-scaling relational database that automatically starts up, shuts down, and scales up or down based on demand. You no longer have to overprovision database servers in order to ensure enough capacity, and you pay only for what you use. With less infrastructure to manage, you’re able to spend more time focusing on your application.
Some History
Amazon’s Relational Database Service (RDS) came on the scene in 2009 and provided a managed relational database service that eventually included automatic backups, high availability across availability zones (AZs), vertical scaling, read replicas, encryption at rest, built-in monitoring, and support for Oracle, SQL Server, MySQL, PostgreSQL, and MariaDB.
Come 2014, Amazon released its own database engine known as Aurora, which is MySQL-compatible and now includes a PostgreSQL variant. It is up to 5x faster than MySQL and 3x faster than PostgreSQL at 1/10 the cost of alternative commercial databases. One neat feature of Aurora is that storage doesn’t have to be allocated, it simply scales up to 64 TB as you store more and more in your database. It comes with some additional features as well including continuous backup, enhanced monitoring metrics, and the ability to use the standby as a read replica.
Now in 2018, to go along with Aurora Serverless, Amazon has expanded upon this by offering a configuration option that eliminates the concept of an “instance” and allows you to look at your database from a higher level of abstraction, while benefiting from auto scaling and an optional feature to automatically shut down the database when inactive to save on cost and conversely restart when connected to once again.
Use Cases
There are two main use cases for Aurora Serverless:
- Unpredictable/variable workloads where usage fluctuates a lot or is not yet known (new applications).
- Periodic/cyclical workloads such as development databases that aren’t used very often, reporting applications that are only used when needed, low traffic internal websites, or other applications that are dormant a lot.
When Not to Use
If your workload doesn’t have a lot of spikes and you know exactly what to expect, then you should probably stick to a traditional provisioned Aurora cluster for now. Auto scaling does have a small performance impact and there are some additional features unavailable at this point for Aurora Serverless that you may want to have access to (described further below).
Additionally, there are some pricing considerations you’ll want to take into account. For example, reserved instances are not available, and that will affect how much you’re paying each month if you’re used to benefiting from those discounts. With provisioned instances you also have the option of using smaller sizes such as the db.t2.small which has 2 GB of memory as opposed to the minimum allowed with Aurora Serverless (4 GB). You can keep costs down if you don’t need a lot, but in some cases you’ll actually save money by using Aurora Serverless if you require high availability. I recommend using the Simple Monthly Calculator to estimate your costs.
Getting Started
When you go to RDS in the AWS console and choose Aurora, you’ll now see two options for “capacity type.” Choose “Serverless.”
Next, you’ll choose the minimum and maximum Aurora capacity units (ACUs) within which the database will scale:
Each unit corresponds to 2 GB of memory and with more ACUs comes increased compute and network resources as well. You can choose between 2 and 256 ACUs. You also have the option of pausing the database when it’s not being used for a certain amount of time. You can specify a time between 5 minutes and 24 hours.
Some Details
- Connections are maintained during scaling events; if you receive a surge of traffic and the database starts scaling up from 2 to 4 ACUs, your existing database connections will be unaffected.
- Scaling rules are created automatically based on CPU, connections, and available memory. The database will scale up when CPU is greater than 70% or less than 90% of connections are being used. It will scale down when CPU is less than 30% and less than 40% of connections are used.
- Cooldown periods exist during which the database will wait before scaling again (3 minutes for scaling up and 15 minutes for scaling down).
- If you’re using buffer caches for increased performance, these are preserved after scaling events. In cases where the database is scaling down and there’s not enough memory to contain these caches, the older items will be discarded.
Scaling Points
Scaling points are points in time when it’s safe to scale. Your database might not be able to scale if there are long-running queries or transactions in progress or if temporary tables or table locks are in use. In these situations, Aurora will try to scale 5 times and then cancel the operation. Should you run into this, you can always manually scale the database and you have the option of forcing connections closed if needed.
Pricing
So far as pricing, you’re charged for Aurora Capacity Units (ACUs), the amount of storage you’re using, and I/O. Note that you pay per-second for ACUs and only when the database is active (not paused). There’s also a a minimum of 5 minutes each time the database resumes.
Monitoring
A new CloudWatch metric is available—ServerlessDatabaseCapacity—which shows how many ACUs you’re using:
Scaling events are also listed in a log in the console.
The Fine Print
As I dug into the service, I found some limitations that exist at this point in time, some of which I’ll capture here:
- There’s a cold startup time of about 20-25 seconds when a database resumes. You’ll want to watch out for application timeouts and make sure they can survive these events.
- Databases are only accessible from within a VPC (no public IP address option).
- Supported regions are limited to: N. Virginia, Ohio, Oregon, Ireland, and Tokyo.
- Aurora Serverless is available only with MySQL 5.6 (no PostgreSQL support).
- Other miscellaneous limitations exist and are related to customizing the MySQL port, a limited number of custom parameter groups, SSL, Lambda triggers, IAM authentication, cross-region read replicas, and more.
Conclusion
Aurora Serverless is a truly impressive technology. It finally brings relational databases to the serverless repertoire and greatly simplifies things while helping you save on cost. As with all AWS services, there are many other features and capabilities on the roadmap and I’m excited to see how it evolves.
