You can imagine the instance that is behind from the equivalent “provisionned” instance size: 4GB RAM is probably a db.t3.medium with 2VCPU burstable, and 768 GB RAM a db.r5.24xlarge with 96 vCPU. It goes from 1 ACU (2GB) to 64 ACU (122GB) for the MySQL flavor. ![]() You can go from 2 ACU (4GB RAM) to 384 ACU (768GB RAM) for the PostgreSQL flavor. The values are in ACU – Amazon Capacity Unit – for which the console displays the memory only. Then you define the minimum and maximum instance size the auto-scaling can play with. You see the first limit here: PostgreSQL 10.7 is the only version available for serverless.Ībout the connectivity, you cannot have public access: the endpoint, which is actually a proxy, is in the VPC Version: Aurora PostgreSQL (compatible with PostgreSQL 10.7).Edition: Amazon Aurora with PostgreSQL compatibility.Finally, I started some heavy load and the instance resumed to maximum capacity (18:57). I’ve run some short activity (pgbench) and the instance scaled-up to the maximum capacity unit (18:45) and went down to zero (paused) after 5 minutes (18:50). And then scaled down to the minimum capacity unit (2 here) 5 minutes later (18:27). ![]() Then I connected and the instance was resumed (18:19) to its maximum capacity unit (4 here). When I’ve created the instance (15:55 – CloudWatch is GMT+2 but event log is UTC), it started with 0 capacity unit (18:03), which means that it was paused (you pay for storage only). I’ve written a blog post about serverless databases and here is an example of Amazon RDS Aurora PostgreSQL in serverless mode:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |