AWS RDS, Aurora, ElastiCache
AWS RDS
Relational database service. It is a managed database service and provide you with databases that uses SQL as the query language and AWS manages it for you.
Database that you can create is Postgres, MySQL, MariaDB, Oracle, Microsoft SQL Server, and AWS Aurora (AWS's proprietary database).
Why RDS over Database on EC2
Well RDS is managed for you so you don't have to deploy them yourself with an EC2 instance. There is automatic continuous backup and restoration capability.
Monitoring dashboard is provided, have read replicas for improved read performance. Multi AZ setup for disaster recovery, and maintenance windows for upgrades.
You can scale vertically by increasing the size and horizontally by increasing the number of instances. The storage is backed by EBS (gp2 or io1).
However, you can't SSH into the underlying EC2 instance can only interact with the database via a database client.
Storage auto scaling
When you first provision your RDS you will specify the initial capacity, and with this feature RDS will detect when you are running out of database storage and scales it automatically.
You will have to set a Maximum storage threshold (the maximum limit that you are willing storage auto scaling to allocate at max for you).
Then it will automatically modify the size of the storage if the amount of free space is < 10%, and the low-storage last at least 5 minutes, and 6 hours has passed since last modification.
This feature is good if you can't predict the amount of storage you will be taking up.
Read replicas
Read replicas is used for read scalability.
Your application will communicate with a RDS database instance and most of the time it is read requests, lots of them actually. Your database might be overwhelmed by those requests and therefore you can set up read replica, which is a copy of the main database instance but can only take read requests. They cannot take write operations since they are a replication of the original.
Read replicas can be setup in the same AZ, cross AZ, or even cross region.
The way that the replicas sync up the data is via asynchronous synchronization meaning that the reads will eventually become consistent. The replicas will catch up when there is free time, which means if your application reads from the replicas there is a possibility that it is reading old data, but it will eventually be synced up with the latest changes.
Replicas can be promoted to its own database giving it the capability of writing.
Use cases for read replicas
The good use cases for that is for example if you are going to run some analytics on the production database instances. If you are going to query directly into the production database it might overload it since the production application is using it as well.
What you should do is that you make a replica of the production database then your analytic application can query into the replica instead of the prod database that way the production application will not be slowed down/affected.
Network cost
Normally there is a network cost when data goes from one AZ to another, but are exceptions depending on the services for example ALB for cross zone load balancing.
For RDS read replicas within the same region, you don't have to pay cross AZ network fee. For example, you set up your main RDS database instance in us-east-1a, but you set up your read replica in us-east-1b, normally because the asynchronous synchronization require data to cross AZ, in this case you don't have to pay the fee if it is in the same region.
However, if your replica is in another region for example instead of us-east-1b it is eu-west-1b, then it will cost you network fee.
Multi AZ
This is for disaster recovery mainly.
You have your application that talks to the main database instance like usual, then you set up another RDS DB as a standby in another AZ and data is going to be replicated SYNCHRONOUSLY, meaning every write on the master database will be also pushed to the standby instance as well.
Then with multi AZ database set up you will get one DNS name which behind it has two instances of RDS database, one that's the master and the other as standby, if the master database failed due to AZ failure, the DNS name will automatically switch over to the standby instance.
This increases overall availability, and this is completely transparent to the application because they just need to talk to the DNS name that it is fronted with.
This is not for scaling since the standby instance is just for backup. You can also set up your read replica as multi AZ for disaster recovery that is possible this is possible.
From single AZ to multi AZ
To change it from single AZ to multi AZ there is no need to stop the database. Just need to modify it.
In the background, a snapshot of the original database will be taken and a new database instance will be restore from the snapshot. Then there will be synchronization established between the two database for multi AZ setup.