Ref: https://learn.cantrill.io/courses/1820301/lectures/41301419
Amazon Relational Database Service (RDS) - Key Concepts
- 🔧 Provides AWS-managed DB servers (called RDS instances)
- Similar to on-premises DB servers, but with important benefits:
- đź‘ŤÂ No need to manage HW, OS nor installation
- đź‘ŤÂ Maintenance of the DB engine mostly managed by AWS
- đź‘ŤÂ Integration with other AWS products
- đź‘ŽÂ No OS-level access nor access via SSH (because it's an AWS-managed service)
- 💡 RDS Custom: a variant of RDS where you DO have some more low-level access
- In general, though, assume RDS does not provide this low-level access
- ‼️ NOT a DBaaS (DB-as-a-Service)!! It is a DBSERVERaaS (DBServer-as-a-Service)!
- DBaaS = You pay for a DB
- With RDS you pay for a DB server/instance (where you can host multiple DBs)
- 💡 RDS is loosely based on EC2, RDS and EC2 instances share a lot of characteristics
- Supported DB Engines:
- FOSS (free & open source SW): MySQL, MariaDB, PostgreSQL
- Commercial DBs: Oracle, MS SQL Server → licensing implications
- ‼️ Amazon Aurora is a different product!
- Aurora is a custom DB engine & product created and designed entirely by AWS, with compatibility with some of the above engines
- Aurora has differences/improvements in many RDS features → Keep them separated
RDS - Architecture
- RDS runs within a VPC in a specific region
- An RDS instance operates in a subnet of the VPC
- Normal VPC access conditions apply
- Access to RDS instances in private VPCs: VPN, Direct Connect (DX), VPC peering…
- RDS instances in public VPCs can potentially be given public IP addresses to be accessed from public internet… but really frowned upon from a security perspective!
- RDS instances can be accessed with DNS CNAMEs
- An RDS instance can host multiple DBs
- DB subnet group = (conceptually) list of VPC subnets where RDS can deploy 1+ instances
- Can contain subnets from different AZs where the VPC is deployed
- A DB subnet group must always be chosen when launching an RDS instance
- âť—Doesn't matter if RDS instance is HA or not!
- Can be used by many RDS instances
- All instances with the same DB subnet group will use the same defined subnets
- Splitting DBs into many different subnets requires multiple DB subnet groups
- Best practice: one DB subnet group per single RDS deployment
- 💡 Adrian's preference → gives best overall flexibility
- Deployment
- RDS picks subnet(s) at random unless you indicate a specific preference
- If Multi-AZ mode is enabled, one subnet for a primary instance and another for a standby, both in different AZs
- Multi-AZ mode: if enabled, RDS instances are in different AZs
- Primary and standby each deployed to different AZs
- Primary and standby each have their own dedicated EBS storage
- âť—Â Different to how Aurora handles storage!
- Synchronous replication from primary to standby (Data replicated as soon as received)
- Backups happen from the standby instance → no negative performance impact
- Backups (EBS Snapshots) to AWS-managed S3 bucket (not visible in console)
- S3 data replicated across multiple AZs in the region (data safe from AZ failures)
- 0+ Read Replicas
- Asynchronous replication
- Same or cross region
- Use cases:
- scaling read load
- adding layers of resilience (allows recovering in a different region)
RDS - Billing