Managed Relational Databases with AWS RDS and Aurora
Understanding what RDS and Aurora can do for you, and best practices to use them
Managed Relational Databases with RDS and Aurora
In AWS there are two services that provide a managed installation of a relational database: Relational Database Service (RDS) and Aurora. Aurora is technically grouped under the list of available database engines for RDS, but its behavior is a bit different in some key areas, so it's worth considering it separately.
To understand what they do, imagine that you create an EC2 instance, install your favorite database engine (e.g. MySQL or Postgres), configure automated backups, set up monitoring tools, and so on. RDS and Aurora let you create in a few clicks an instance that's essentially like that, but everything is already set up for you. You still need to configure things that aren't part of the instance, like what VPC and subnet it's going to launch on, associated security groups, etc. But those work just like for EC2 instances.
RDS lets you use MySQL, MariaDB, Microsoft SQL, Oracle or PostgreSQL as a database engine. Aurora only supports MySQL up to 8.0 and Postgres up to 14.3 (those are not the latest versions of those engines). The reason is that Aurora doesn't actually use native MySQL or Postgres, but instead a rewrite of those engines made by AWS, which is fully compatible with the original MySQL and Postgres versions, but optimized to work better in AWS's infrastructure.
Benefits of Amazon Aurora over RDS
These are the ways in which Aurora works better than RDS, thanks to the optimizations performed by the AWS team:
In Aurora, read replicas also act as failover replicas
Aurora is better optimized to use EBS volumes, achieving better throughput on disk operations
With Aurora you don't need to provision storage capacity before using it, it's provisioned automatically and you only pay for what you actually consume. You can still configure EBS volume types and other parameters like IOPS.
You can use Aurora in serverless mode, allowing you to scale your database's compute capacity horizontally. It works similar to DynamoDB in Provisioned Mode, and it's approximately 3x more expensive than Aurora in serverful mode (without taking into account the reduction in unused capacity).
Aurora supports global databases, which are backed by two or more Aurora databases in different regions.
Best Practices for RDS and Aurora
If you're going to use Postgres or MySQL, prefer to use Aurora if possible.
Purchase Reserved Instances for your RDS or Aurora databases, to save up to 60% on database instance costs.
Keep in mind that in Aurora reserved instances are flexible (i.e. if you move to a larger instance size you still get benefited from the reservation)
Consider whether Aurora Serverless is a good fit for your use case
Always use Aurora Serverless v2, Serverless v1 is fading out
Remember that it's 3x more expensive. That means, it'll be cheaper if you're using less than 33% of your DB instance's capacity on average
You also get the benefit of scaling beyond your planned capacity with no preparation and no manual intervention
Keep in mind that it doesn't scale immediately, it may take a few minutes to detect the need to scale and increase capacity
If you have some read-heavy users or use cases (such as reporting), consider adding a read replica and performing read operations from the reader endpoint
If you need high availability, set up a failover replica in a different Availability Zone. Remember that in RDS read replicas and failover replicas are different concepts, while in Aurora replicas act both as read replicas and failover replicas at the same time.
Recommended tools for working with RDS or Aurora
If you're considering a relational database for an event-driven architecture, check out Debezium. It lets you stream changes to relational databases, and subscribe to change events.
Thank you for reading! See ya on the next issue.