In The Works – Amazon Aurora Serverless

When you create an Aurora Database Instance, you choose the desired instance size and have the option to increase read throughput using read replicas. If your processing needs or your query rate changes you have the option to modify the instance size or to alter the number of read replicas as needed. This model works really well in an environment where the workload is predictable, with bounds on the request rate and processing requirement.

In some cases the workloads can be intermittent and/or unpredictable, with bursts of requests that might span just a few minutes or hours per day or per week. Flash sales, infrequent or one-time events, online gaming, reporting workloads (hourly or daily), dev/test, and brand-new applications all fit the bill. Arranging to have just the right amount of capacity can be a lot work; paying for it on steady-state basis might not be sensible.

Get Ready for Amazon Aurora Serverless
Today we are launching a preview (sign up now) of Amazon Aurora Serverless. Designed for workloads that are highly variable and subject to rapid change, this new configuration allows you to pay for the database resources you use, on a second-by-second basis.

This serverless model builds on the clean separation of processing and storage that’s an intrinsic part of the Aurora architecture (read Design Considerations for High-Throughput Cloud-Native Relational Databases to learn more). Instead of choosing your database instance size up front, you create an endpoint, set the desired minimum and maximum capacity if you like, and issue queries to the endpoint. The endpoint is a simple proxy that routes your queries to a rapidly scaled fleet of database resources. This allows your connections to remain intact even as scaling operations take place behind the scenes. Scaling is rapid, with new resources coming online within 5 seconds. Here’s how it all fits together:

Serverless: A lesson learned. The hard way.

The actual cost is now $206 and over $1000 forecasted, it makes me think twice about using pay-per-use services in the future. One little mistake can cost a lot of money, the budget notifications were very late so there was very little I could do against it.

Right now I’m continuously refreshing the billing page on Amazon, hoping it wont go any higher – I probably wont be sleeping much tonight.

I’m not saying serverless is bad, but you should be very careful with it. Keep an eye on your logs, test everything again and again. Set up a budget alarm, even though I still ended up with $206 costs, it could have been much much worse without one.

 

.. This is probably the most stupid thing I ever did. One missing return; ended up costing me $206.