Overview of Amazon Aurora Serverless
Amazon Aurora Serverless is an on-demand, auto-scaling configuration for Amazon Aurora database service.
If you are familiar with Amazon Aurora service, you know you Aurora is a fully managed service and you don’t need to specify the storage capacity, and the service automatically scales to your needs. However, you still need to specify the compute capacity needs – not only the instance class, but also you would need to add and remove DB instances as your workload increases and decreases. Amazon Aurora Serverless addresses that part of compute needs automatically (along with automatically handling the storage part). You would not have to specify compute capacity needs either when you go with Aurora Serverless. Of course there are servers behind the scene (just like Lambda has EC2s behind the scene) – it’s just that you don’t have to worry about managing it.
Key Points for Aurora Serverless
- Aurora Serverless is not a separate database service. It’s rather a configuration variation of Aurora database service.
- You do not specify DB instance info. Rather you have to specify Aurora Capacity Units (ACUs) – see details below. This is what you charged for.
- Aurora Serverless service will automatically handle database start up, shut down and scaling per your application’s needs
- Use Cases – Unpredictable and variable workloads, Infrequently-used applications, Development and Test workloads,
Aurora Capacity Unit (ACU)
ACU is a combination of processing and memory capacity. Think of it this way – for Aurora Service you had to specify the DB Instance class that would define how much of compute power, memory and I/O capacity are you getting. In this case you instead specify a range of that capacity in terms of minimum and maximum ACU.
Here’s a snapshot of what you would see when you are creating an Aurora Serverless Database service:
Drop-down option of Maximum has same set of choices as the the drop-down option of Minimum:
It shows how increasing ACU corresponds to increasing RAM (and likely increasing compute capacity as well – which is not obvious from the visible selection).
Architecture of Aurora Serverless
Under the hood, the way Aurora Serverless works is something like this:
Image courtesy of AWS
Key components of this architecture:
- Proxy servers (also called Proxy fleet) – this layer handles the traffic from (and back to) application.
- This layer is responsible for figuring out which DB Instance to communicate with.
- This layer also holds the request (from application) when a DB Instance is just coming up to start serving (this period may be up to 30 seconds, if it’s a fresh start of the instance from zero capacity)
- This layer is highly available – with proxy servers spread across multiple AZs
- DB Instance(s) – this layer contains the actual DB Instances that execute the database operations. This layer has two components:
- Active DB instances that are serving your applications.
- Warm pool of Aurora instances – this is a group of DB Instances that Aurora Serverless keeps up and running to avoid server start-up time. Despite having warm pool of instances, preparing it for your purpose may still take up to 30 seconds
- Monitoring Service – this service is responsible for monitoring the capacity loads of DB instances, and thus triggering scale up / down of instances
- Storage Volume – this is same as the standard Aurora Service
Data API
This is a unique feature of Aurora Serverless service. This enables you to access your Aurora Serverless DB cluster using the build-in Data API.
Key features of Data API:
- Using this API, you can access Aurora Serverless with web services based applications, including AWS Lambda, AWS AppSync, and AWS Cloud9.
- Data API doesn’t require a persistent connection to the DB cluster. Instead, it provides a secure HTTP endpoint and integration with AWS SDKs.
- It uses database credentials stored in AWS Secrets Manager, thus eliminating the need to pass credentials in the API calls.
- All calls to the Data API are synchronous.
Note: Data API is available only for select versions of MySQL and PostgreSQL.
Pricing
- You are charged a flat rate per second of ACU usage, with minimum of 5 minutes of usage each time the database is activated.
- Storage and I/O prices are the same for provisioned and Serverless configurations.
External Resources
