RDS is AWS managed relational db service. Database will run in EC2 instance within your VPC/Subnet but you can’t SSH or have root access
16 TB is limit for MySQL as of 2018 April. So if you have an existing 10 TB MySql that you want to migrate to AWS RDS, and expect that it will double in one year, go for AWS Aurora (common exam question) as its compatible with MySQL and supports up to 64 TB db size.
Amazon Aurora offer an integrated cache that is managed within the database engine and has built-in write-through capabilities. When the underlying data changes on the database table, the database updates its cache automatically
You can use AWS Elasticache with AWS RDS but you need to customize your code (Eg. EC2 web app calling RDS to get resultset and calling Elasticache API to cache the resultset and later retrieve the result set from elasticache as opposed to RDS)
Two types of backups are supported
Enabled by default
Backup data is stored in S3 (you get free S3 storage allowance equal to the size of your RDS db)
Daily snapshots + transaction logs
AB’s let you recover at any point of time within a retention period
Retention period can be set as 1 day to 35 days
Backups are taken at a specified window of time
During the backup time the latency may be higher than normal so choose a backup window time which is least in demand for your services
Deleted automatically when you delete RDS inst.
Snapshots are manual
Initiated by the admins
Unlike automatic backups, the snapshots are available even after you deleted your RDS instances
When you restore a snapshot it will create a new RDS instance with a new endpoint.
You can encrypt your Amazon RDS instances and snapshots at rest by enabling the encryption option for your Amazon RDS DB instance.
Amazon RDS encrypted instances use the industry standard AES-256 encryption algorithm to encrypt your data on the server’s EBS that hosts your Amazon RDS instance.
Once your data is encrypted, Amazon RDS handles authentication of access and decryption of your data transparently with a minimal impact on performance. You don’t need to modify your database client applications to use encryption.
Encryption at rest is done thru AWS KMS
supported for MySQL, Oracle, MariaDb, SQL Server and PostGreSQL
Existing un-encrypted db can’t be encrypted. You need create a new encrypted RDS instance and migrate to it
All storage, snapshots, automatic backups, read replicas will be encrypted as well if source is encrypted
Multi AZ deployment for high availability
Synchronously replicated in another AZ
Automatic fail over (dns endpoint remains same. No need to point to the secondary db)
Disaster Recovery (DR) purpose only (Resilient pillar). Not for performance. Use read replicas instead for scalability and performance enhancements.
They are different from multi Availability Zone deployment
Asynchronous replication (NOT Synchronous)
Replica lag will be there (time taken to sync once master is modified)
Creates exact copy of master db
If multi AZ is enabled, then RR uses secondary db to create the initial snapshot thus avoiding 1 min slowdown time which would otherwise happen
Read replicas have separate end points which can be directly used by EC2 instances running applications (connection strings)
Read replicas can have read replicas (Double replica lag)
MySQL, Maria Db and PostgreSQL support 5 Read Replicas. Aurora supports upto 15 read replicas.
RRs can be a different region/AZ for MySQL
RRs can be promoted to be master dbs. Once promoted, the RR link will be lost and the promoted instance will act as an independent master db
RRs are Read only. Can’t write to RRs
Scaling up (Better CPU/Memory/Instance Type) is a manual process unlike in DynamoDB where scaling can take place with push button
Recovery Point Objective (RPO) and Recovery Time Objective (RTO)
Commonly used in disaster recovery strategy, RPO is the amount of data loss measured in time (Eg: Last 10 min of data is lost)
RTO is the amount of time needed to restore a business process to its service level. (Eg. Took 2.5 hours to bring production up and running after disaster)