Adrian Cantrill’s SAA-C02 course, 50 minutes: Aurora Serverless
Today I learned about Aurora serverless. The explanation given is that Aurora Serverless is to serverless what Fargate is to ECS. It provides a version of the Aurora database product where you don’t need to statically provision database instances of a certain size, or worry about managing those database instances. It is moving more in the direction of a database as a service product. It removes one more piece of admin overhead, the admin overhead of managing individual database instances. Introducing Aurora Serverless, we now need to refer to standard deployments of Aurora as ‘Aurora provisioned’, vs. ‘Aurora serverless’, the topic we are looking at in this post.
With Aurora Serverless, you don’t need to provision resources in the same way that you did with Aurora provisioned. You still create a cluster, but Aurora serverless uses the concept of ACUs: Aurora Capacity Units. Capacity units represent a certain amount of compute, and a corresponding amount of memory. For a cluster you can set minimum and maximum values, and Aurora serverless will scale between those values, adding or removing capacity based on the load placed on the cluster. It can even go down to zero and be paused, meaning that you’re only billed for the storage that the cluster consumes. Billing is based on the values that you use on a per-second basis, and Aurora Serverless provides the same levels of resilience that you’re used to with Aurora provisioned. So you get cluster storage that’s replicated across six nodes across multiple availability zones.
Some of the high level benefits of Aurora Serverless: it’s much simpler, it removes much of the complexity of managing database instances and capacity. It’s easier to scale; it seamlessly scales the compute and memory capacity of ACUs as needed with no disruption to client connections. It’s also cost-effective. When you use Aurora serverless, you only pay for the database resources you consume on a per-second basis, unlike with Aurora provisioned, where you have to provision database resources in advance, and you’re charged for the resources they consume, whether you’re utilizing them or not.
The architecture of Aurora serverless has many similarities with the architecture of Aurora provisioned, but it also has crucial differences. The Aurora cluster architecture still exists, but it’s in the form of an Aurora Serverless cluster. This has the same cluster architecture that Aurora provisioned uses. In the Aurora serverless cluster, instead of using provisioned servers, there are ACUs, Aurora Capacity Units. These capacity units are allocated from a warm pool of Aurora Capacity Units, which are managed by AWS. The ACUs are stateless, they’re shared across many AWS customers, and they have no local storage. They can be allocated to your Aurora serverless cluster rapidly when required. Once the ACUs are allocated to an Aurora serverless structure they have access to the cluster storage in the same way that a provisioned Aurora Instance will have access to the storage in a provisioned Aurora cluster. It’s the same thing, the difference being that the ACUs are allocated from a shared pool managed by AWS.
If the load on an Aurora serverless cluster increases beyond the capacity units which are being used, and assume the maximum capacity setting the cluster allows, then more ACUs will be allocated to the cluster. Once the compute resources which represents this new potentially bigger ACU is active, any old resources representing unused capacity can be deallocated from your Aurora Serverless cluster. Because of the ACU architecture, because the number of ACUs are dynamically increased and decreased based on load, the way that connections are managed within an Aurora Serverless cluster has to be slightly more complex versus a provisioned cluster. In an Aurora Serverless cluster we have a shared proxy fleet, which is managed by AWS. This happens transparently to you as a user of an Aurora Serverless cluster, but if the user interacts with the cluster via an application, it actually goes via this proxy fleet. Any of the proxy fleet instances can be used, and they will broker a connection between the application and the Aurora Capacity Units. This means that because the client application is never directly connecting it to the compute resource that provides an ACU, it means that the scaling can be fluid, and it can scale in and out without causing any disruptions to applications while it’s occurring, because you’re not directly connecting with an ACU, you’re connecting via an instance in this proxy fleet. The proxy fleet is managed by AWS on your behalf. The only thing you need to worry about for an Aurora serverless cluster is picking the minmum and maximum values for the ACU, and you’re only billed for the maximum amount of ACU that you’re using at a particular point in time, as well as the cost of storage. So that makes Aurora serverless really flexible for certain types of use cases.
Here are some examples of types of applications, which really suit Aurora serverless, the first is infrequently used applications. Another use case is New applications, where Aurora Serverless will auto-scale based on incoming load. It’s also really good for variable workloads, where again, Aurora Serverless will scale in and out based on demand, along with applications that have unpredictable workload. Another use case is for development and test databases, where Aurora Serverless and be set to pause itself during periods of no load, where you would then only be billed for storage. It is also good for multi-tenant applications.