Aurora Serverless for MySQL 5.6 — Generally Available

Aurora Serverless

Last week, Randall Hunt from AWS gave us some great news — Serverless Aurora is now generally available! Announced last year at re:Invent, Aurora Serverless is an on-demand, auto-scaling, and of course, serverless, version of Amazon’s wildly popular managed database platform.

With auto-scaling built in, Aurora Serverless should prove to be invaluable for workloads with spiky or unpredictable bursts of traffic, or idle databases with infrequent traffic that need to scale up quickly without warning. This is huge, let’s dive in!

Where’s my database?

“Serverless” is a term coming up more and more often these days. AWS defines Serverless computing as a means to allow “… you to build and run applications and services without thinking about servers.” Note here that we’re not implying that the servers don’t exist, just that you don’t have to manage them, and that the hardware layer is ultimately transparent to the end-user.

We can generally infer the term “serverless” to simply mean “someone else’s servers”, and the truest expression of the shared responsibility model. Let AWS worry about the hardware, you worry about your applications. That being said, AWS does allow us a glance behind the curtain at the infrastructure powering the new platform.

Source: AWS

When you launch an Aurora Serverless database, AWS is, in the background:

• Creating an Aurora storage volume (backed by the famously good Aurora storage platform we all know and love, crazy scalable, super fast and replicated across multiple AZs)
• Creating an endpoint in your VPC for the application (this is just like the standard RDS endpoint that we’ve been using for years)
• Building a Network Load Balancer (NLB) behind the endpoint (transparent to you and the end-user, this is where the “serverless” comes in)
• Configuring multi-tenant request routers to route database traffic to the underlying instances (this is the auto scaling secret sauce)
• Provisioning the initial minimum instance capacity (configured at launch)

Thus the “serverless” architecture is actually an NLB and an auto-scaling Aurora group hosted by AWS and all that’s visible to you in your account is the RDS endpoint, and an RDS cluster.

There are some paradigm shifts that come along with this model though, and a few functional limitations with the new platform. Mainly, Aurora Serverless isn’t priced or scaled the same way as traditional RDS instances. With the introduction of this platform, AWS created a new pricing model exclusive to Aurora Serverless called “Aurora capacity unit”.

Defined at launch, you are required to configure a minimum and maximum capacity unit (similar to the minimum and maximum instance counts in an EC2 Auto Scaling Group). The instance will start at the minimum setting and scale as high as the maximum when under load (you can also scale it manually in increments, think “Desired Instance Count” from EC2 Auto Scaling Groups).

There’s also a hidden gem in this menu. Look closely at the bottom half of that screenshot: “Pause compute capacity after consecutive minutes of inactivity”. This is an extremely powerful option which allows us to spin down the database compute resources to nothing when idle. No more deleting sandbox resources to save on spend. Your Aurora Serverless instances will effectively be “powered off” when inactive and you will only be charged for the consumed storage. This will have huge impacts for development workloads, or workloads that often sit idle for extended periods of time. Don’t leave the lights on if you’re not at home!

Let’s talk limitations and differences. First, there’s no CloudFormation support yet. Traditionally Aurora has been an area of heavy focus for AWS development so I’m hoping we see some updates there soon. At launch, only MySQL 5.6 is supported. If serverless tracks with Aurora’s original release cycles, we should expect to see broader MySQL support next, followed by PostgreSQL at a later date. Also, at launch there is no support for point in time restores, only full snapshot restores. Only port 3306 is supported, there’s no option to change this at launch. The ability to stop or start instances is missing right now (which may not be a big deal given the idle CPU spin down feature mentioned above), as well as replication to standard Aurora instances.

Great, when do I use it?

Aurora Serverless is a simple platform to create an easy to manage, simple to scale, full featured Aurora database. Use it when you:

• Have an unpredictable workload that needs to scale
• Have development workloads that often sit idle

Given some of the limitations of the platform at launch, avoid Aurora Serverless if:

• Your workload is MySQL 5.7, or PostgreSQL
• You need fine tuning with read replicas
• You require fine grained backups with point in time recoveries

Overall, Aurora Serverless is a fantastic addition to the portfolio. I anticipate wide adoption of this specifically for development or ephemeral workloads which can often sit idle, especially if AWS can fold in MySQL 5.7 and PostgreSQL support in the coming months.

Read more in the official AWS blog post: https://aws.amazon.com/blogs/aws/aurora-serverless-ga/