I have surprisingly little in the way of jotted notes about RDS thus far. Like EC2, it's very "does what it says on the tin": you create an RDS instance, you choose your database engine... and that's preeetty much it.
Random jottings on RDS
- Uses a an EC2 instance under the hood (eg a db.t2.micro), but it's special in that you can't log in to it
- you can seed yourdb with the initial database name if you need to.
- You need to turn on backups if you want any kind of replication to take place. Related to which:
- Backups are fully automated (unlike manual snapshots)
- Manual snapshot: (rds instance) > Actions create snapshot...
- There are read replicas (asynchronous replication) and they can be anywhere (any AZ, region etc). Goto (rds instance) > Actions > create read replica...
Moving RDS instances between VPCs: Maybe just.. don't.
Finnickier than I'd have thought. I expected to be just able to modify the instance and change the network settings to use my VPC and desired private subnet.
I couldn't select a subnet corresponding to my VPC though. This article might be helpful. In my case:
- My AZ's were a total mismatch (I remember letting AWS pick the AZs for my subnets lol)
- RDS requires the subnet it's in to have 2 different AZs... so I had to go back and create an extra subnet in a different AZ before I could move my RDS instance into my VPC.
The following didn't work, but gives you an idea of what's going on under the hood
Following the article I linked to, I tried this:
That should work...
Unless like me, you still have a mismatched AZ kicking around somewhere (for me, it seemed to be the RDS instance itself).
Update 2020-06-08 They've literally just updated the RDS creation page. It now clearly states that you can't be muffing about with the target VPC after you've created your instance. Honestly I just scrapped my DB and recreated it, targeting the right VPC, the db subnet group I'd created in the steps above, and the correct security group..
The data store ecosystem
Redshift: best for OLAP:
- advanced features like compression, distributed query loads, etc. You should read up on it.
- own security key management
- Aurora DB: serverless; pay per-invocation
- Dynamo DB: the AWS noSQL solution
- Elasticache: memory-based, so faster than disk-based fetches. Uses Memcached (simple) or Redos (advanced) under the hood.