AWS Aurora Summary
This week I’m exploring Aurora as an alternative to RDS for work. Here I will be outlining my takeaways from reading over some of the official Aurora documentation.
Overview
Aurora’s front page features several advantages over traditional relational database, which include:
- Automatic storage scaling (up to 128 Tb)
- Automate clustering and replication
- Allows up to 15 read-replicas in single-master mode.
- Can migrate from RDS to Aurora via snapshot backup restore.
Topics
Below is a summary of the topics described in the Aurora docs insofar as it is relevant to my own needs.
Clustering
- Multi-master replication is also available
- Replication does not have to be in different AZs
Additional Relevant Aurora Features
- RDS Proxy
- Dedicated db connection pooling. Potentially useful?
- Aurora Serverless
- Autoscaling without clusters (?)
- Data API for Serverless
- Pairs with Aurora Serverless, can do SQL queries via https.
Endpoints
AWS Aurora operates via the use of endpoints. Endpoints delegate db connections to a pre-established cluster of db instances.
Two endpoints are provided out of the gate:
- Cluster/Writer endpoint
- Used for write-specific operations
- Specifically uses the master db instance.
- Reader endpoint
- Specifically uses read-replica db instances.
- Handles load-balancing automatically
- Custom endpoints
- Instance endpoints
- Connect to a specific db instance to perform a query
- Primarily used for debugging and performance tuning.
Custom Endpoints
DB instances can be pre-made, and placed into pre-specified clusters that map to custom endpoints. These clusters do not have to be mutually exclusive, and are particularly handy for dedicating queries based on capacity requirements. For example, intensive queries such as reporting or importing and exporting can be delegated to a custom endpoint that contains high-power ec2 db instances.
Limitations
Currently, the ec2 instances available for use with Aurora are:
- db.r4, db.r5 (these support any version of postgres (?))
- t3.large (postgres version > 10.6)
- t3.medium (postgres version > 10.7)
Documentation mentions the availability of m-sized instances as well (ie m5, m4s, etc).
Storage
All db instances connect to a shared volume that grows and shrinks with the size of your data. This means deleting data is a means of directly reducing cost (not sure by how much).
Security
Both traditional database login / permissions and IAM-backed login can be used to connect to db.
Pricing
Aurora db instances appear to be about ~15% more expensive than RDS db instances with regard to on-demand cost.
RDS and Aurora offer “Reserved Instances” which are priced at a discount to on-demand instance prices at the cost of committing up-front to a 1 or 3 year reservation period.
Important considerations here are the fact that a 3 year commitment to a particular instance type may be obviated down-the-road with tech advancements. Also, one should have a good idea of the performance demands of their system before committing to a specific type of / number of instances.
If these things are known however, reserved instances can offer anywhere between 30%-70% price-improvement over on-demand, with the maximum discount achieved under the condition that:
- The Reserved Instance is paid for entirely up-front.
- The Reserved Instance is never used.
Reserved instances cost exactly the same as on-demand instances when in use, so if one knows exactly what instances they may need for spikes in use up-front, 1-year commitments can offer substantial price improvements.
