Amazon Aurora is a relational database engine provided by Amazon Web Services (AWS), which is fully compatible with the open source MySQL and PostgreSQL databases. This means that code, applications, and drivers used by existing MySQL or PostgreSQL databases can be used in Aurora without changes. However, Aurora is a proprietary system and is not actually based on either open source database engine.
You can manage an Aurora database via Amazon Relational Database Service (RDS). In this case, RDS will handle provisioning, patching, backup, restore, and other tasks. However, RDS is not serverless, meaning that you still need to manually provision a computer instance for your database.
Aurora Serverless is an on-demand version of Amazon Aurora with auto-scaling capabilities. With Aurora Serverless, administrators don’t manage database instances at all. The database is managed as one instance that grows or shrinks according to requirements. You configure the required computing capacity via Aurora Capacity Units (ACUs), which are a combination of virtual CPUs and memory. Aurora Serverless lets you define minimum and maximum ACUs, and automatically scales compute capacity up or down within those limits.
In this article
There are several considerations when choosing a relational database engine:
You should certainly consider Aurora Serverless, especially for non-production environments and applications with low or irregular traffic. However, evaluating the limitations, benefits, and costs compared to RDS is important to make the right choice for your organization.
Amazon Aurora Serverless v2 was released in April 2022. In the original Aurora v1, the query layer was provisioned manually. Users could choose an instance size for the database and instances for secondary read replicas, but after the initial deployment, the database would not scale automatically. In addition, Aurora v1 did not have multi-region replication.
Amazon Aurora Serverless v2 was designed to provide full autoscaling. It can monitor usage and automatically adapt database capacity to actual application loads. This means that as an application’s loads grow, the database grows seamlessly to provide additional capacity without manual configuration. If loads suddenly decrease, for example in applications with spikes in demand, the database scales down to conserve costs.
Autoscaling is limited to vertical scalability (increasing and decreasing instance size), but v2 also introduces support for horizontal scaling.
The new capabilities introduced in v2 can be summarized as follows:
The cost of Aurora Serverless v2 appears expensive, and while it is possible to save costs on your database for peak loads, it is not a cost-effective option for everyone.
Comparing Aurora Serverless v2 to v1
The price of Aurora capacity units (ACUs) in v2 ($0.12/hr) is twice that of those in v1 ACUs ($0.06/hr). Another major difference is that v2 has incremental ACUs, while v1 has instance doubling—for example, v2 allows you to scale to nine ACUs, whereas v1 only offers eight or 16. Still, 16 v1 ACUs will be cheaper than nine v2 ACUs ($0.96 compared to $1.08).
Another difference is the time to scale down—v1 usually takes several minutes. Given that you pay for capacity per second, this extra time means paying for extra capacity. Thus, v2 is more cost-effective for spiky, inconsistent workloads but can be expensive for consistently high traffic.
Aurora v2 is more granular and offers savings compared to provisioned (i.e., always on) capacity. For example, running an Aurora v1 db.r5.4xlarge instance at $2.32 per hour will amount to $1,094.40 per month per instance. Still, you’d need to provision more instances to accommodate spikes—thus, it would cost over $2000 per month to support peak capacity.
How v2 ACUs save money
Aurora v2 doesn’t require this redundancy so that you can provision a single cluster. You’d need 64 ACUs to offer the same capacity as the db.r5.4xlarge instance. Running at full capacity would be expensive ($5,529.60 per month), but you won’t run at full capacity most of the time.
On a typical day, you’ll run at peak capacity (100%) for two hours, moderate capacity (50%) for ten hours, and low capacity (10%) for twelve hours. The pricing calculation for one day would be as follows:
(64 x 2 x 1 + 64 x 9 x 0.4 + 64 x 12 x 0.1) x $0.12 = $52.224 per day.
That’s $1566.72 per month, significantly cheaper than the $2,188.80 per month for the same capacity in v1. In short, the savingscome from reducing over-provisioning.
Multi-region replication
Aurora Serverless v2 supports Global Database for data recovery from any region. You can run DR clusters in other regions with half an ACU. v2 also lets you scale across multiple regions as needed. However, Amazon charges fees for data transfers.
Aurora Serverless v2, database connections are managed via Amazon Relational Database Service Proxy, a database proxy for Amazon RDS. It is a highly available, fully managed service that helps secure applications and makes them more scalable and resilient.
Applications with a modern, serverless architecture often have many open connections to a database server. Some applications open and close these connections frequently and use up the database compute resources and memory.
Amazon RDS Proxy enables applications to share database connections to improve their scalability and efficiency. RDS Proxy facilitates the management of database access privileges, credentials, and authentication, integrating with AWS services like Identity and Access Management (IAM) and Secrets Manager.
You can enable Amazon RDS Proxy for most applications without code changes. There is no need to configure or manage more infrastructure.
Some experts argue that the switch from a Data API to RDS Proxy has major disadvantages. Aurora Serverless is often accessed by Lambda functions, which can scale up very quickly. If thousands of Lambda functions suddenly start hitting an Aurora database, they can overwhelm it.
In Aurora Serverless v1, Lambda functions would access a Data API, which would transparently create connections to the Aurora database, while managing connection pooling.
The Aurora Serverless v2, with the switch to the RDS Proxy, there are two possible downsides:
