Aurora Serverless – notes


Serverless is the trendy word of 2018 and everything is serverless or wannabe serverless. Aurora is no exception, and it is also reaching towards serverless. Aurora serverless introduced actually last Re:Invent and the preview phase lasted for half a year. Since summer it has been generally available.

Under the hood

Launching Aurora as ‘Serverless’ is no more difficult than launching Aurora to be a ‘traditional’ SQL database. Only a few clicks and Aurora serverless is ready to rock. The most interesting feature is the automatic scaling.  One can set minimum and maximum limits in terms of ACU. Minimum is 2 ACU and scaling steps includes always even amount of ACUs (2,4,6, on). In addition it is possible to go full serverless in terms of scaling to allow 0 ACU if there is no traffic to the database. For budget perspective that sounds great, as the costs can be pressed down during the idle times.  For the budget calculations it is good to remember that even though the price is per ACU, there are always min 2 (or 0 if sleeping). The price for 2 ACUs is slightly greater than smallest ‘traditional’ Aurora, so if the use scenario requires cheap and always on database, maybe Aurora Serverless is not the answer.

And that leads us to the wake-up time of the sleeping database. It seems to be 25s or a bit less for the first request to get the response. Of course after that the database is fast and there is no delays between queries and responses. If that is something that cannot be live with, one can define a long idle time (24h max) before database goes to sleep and maybe some crons to keep the database awake… But Aurora Serverless documentation indicates that it might be excellent fit for development databases as there are typically no red flags for the waking-up delays.

However, it is possible to use CloudWatch Metrics for Aurora Serverless and query whether the database is sleeping or not. Then this information can be used in the application in some novel way, for example hiding the waking up phase from the user…

CLI command example:

$> aws cloudwatch get-metric-statistics --metric-name ServerlessDatabaseCapacity --start-time 2018-09-19T12:19:00Z --end-time 2018-09-19T12:20:00Z --period 60 --namespace AWS/RDS --statistics Maximum --dimensions Name=DBClusterIdentifier,Value=<name> --region <region>

Another difference between Aurora Serverless and traditional Aurora is the amount of cluster endpoints; aurora serverless has only one. There is no dedicated endpoints for writer and reader(s). That indicates automatic scaling to affect also writer instead of only to the amount of readers. However, the performance of such scaling is not yet a widely available. Furthermore, the comparison to Aurora Multi-Master would be highly interesting. Nevertheless, Aurora Serverless is highly interesting product and will be widely used as it will takes away the database scaling from the user. Administrative tasks will be somewhat relieved.


Application Load Balancer & new actions


Application Load Balancer received upgrade last summer as redirect and fixed responses were introduced as new actions.  Therefore, action possibilities contains at the moment Forward, Authenticate (HTTPS listener only), Redirect, and Fixed responses. These two latest actions enable some simplifications to the environment.


I find the Redirect very useful and a real word example is HTTP to HTTPS redirect. HTTP requests don’t need to reach the webserver anymore for HTTP -> HTTPS redirect as the magic happens at the load balancer. Apache/NGINX can be configured to listen only one traffic port as all traffic will be routed through that port. For setting HTTP-> HTTPS redirect up at the ALB, it is only required to select HTTP Listener and a new rule; first the Condition (either Path or Host) and then Redirect Action and type 443 in to the console. The result is that all HTTP requests are redirected to HTTPS.

Figure 1. Redirect as a new action.

Fixed responses

The trend is to move some of the activities away from webserver to the load balancer and utilizing a fixed response is one. For example, certain HTTP error codes can be handled on the load balancer level. Clearly some benefits, but I see that the Redirect will be somewhat more widely used.

Even though these new features will make life somewhat easier, there is one feature that still remains on my wish list. Support for the Application controlled session cookies.