RDS

Solution Architect Associate

Developer Associate

Security Specialty

  • SQL Server, Oracle, MySQL, PostgreSQL, Aurora, MariaDB are the types of RDBMS that are supported
  • Non relational dbs - DynamoDB
  • OLTP vs OLAP
    • OLTP: Online Transaction Processing
      • Typically pulls up a row of data or something by ID
    • OLAP: Online Analytics Processing
      • Used for data warehousing. For example, calculate net profit for regions of the world. Pulls in large number of records and performs some calculations
  • Data warehousing: Redshift
  • Elasticache is a web service that makes it easy to deploy an in-memory cache in the cloud. Supports memcached and Redis. Very fast due to in-memory cache
    • Store long lived data that rarely changes here for fast performance
    • Use when production database is under a lot of load, you can use this to reduce DB server load for data that rarely changes.
  • You’re never given a public IPv4 address for RDS instances, AWS manages this. You only get the DNS entry
  • Be sure to add inbound traffic on port 3306 for MySQL for the security group that the RDS instance is in to the security group of your EC2 instance (likely on exam). Without this, your EC2 instance won’t be able to talk to your RDS instance
  • You can connect to all databases via username/password. For MySQL and PostgreSQL, you can also setup IAM authentication (know this)

Backups, Multi-AZ & Read Replicas

  • Know the difference between Multi-AZ and Read Replica, this will be on the exam!!
  • Two types of backups: Automated Backups and Database Snapshots
    • Automated backups
      • allows you to recover your database to any point in time within a retention period. AWS will take a full daily snapshot and will also backup transaction logs throughout the day (every 5 minutes)
      • Retention period window is between 1 and 35 days. Automated backups are enabled by default, by default is 7 days
      • If you delete the RDS instance tied to Automated Backups, the backups will be automatically deleted
      • Backups are taken within a defined window. During this window, IO may be suspended and you may experience some elevated latency. You can define the backup window
    • Snapshots
      • User initiated, and fully managed by you. They are stored even after you delete the RDS instance.
      • When you restore, you’ll get a new RDS instance with a new DNS entry
  • Encryption at rest is supported in all of the RDS options
    • Once your RDS is encrypted, the data stored at rest as well as the backups, read replicas and snapshots are also encrypted
    • At the present time, encryption on an existing DB instance isn’t supported. You have to create a snapshot, then create a copy of the snapshot as an encrypted snapshot, then create a new instance from the encrpyted snapshot. (likely on exam!!)
  • Multi-AZ
    • Changes made to an RDS instance in one region will be synchronously replicated to an RDS instance in another region.
    • You get a single DNS name associated with the master and the standby databases. Failover is automatic.
    • This should only be used for disaster recovery. (this will likely be on the exam)
    • If you lose the primary DB, AWS will detect this and automatically update the DNS endpoint of your RDS instance to point to the secondary during disaster.
    • Available for SQL Server, Oracle, MySQL, PostreSQL, MariaDB. Aurora this is on by default.
  • For performance improvement, you’ll want to use Read Replicas instead of Multi-AZ
    • You can have 5 read replicas per production database by default
    • When you write to your main database, those writes will be replicated to the read replicas asynchronously, and automatically
    • Generally, most traffic to a database is read-based on the internet
    • Then, when you setup your reads, you read from the read replicas
      • You can also have read replicas of read replicas if you’d like
    • Allow you to have a read only copy of your production database, use these for read heavy scenarios
    • Currently not available for SQL Server and Oracle. Only for MySQL, PostgreSQL, MariaDB and Aurora
    • Used for scaling, not for disaster recovery (on exam)
    • You must have automatic backups turned on to use read replicas
    • Each read replica will have its own DNS end point
    • You can create a read replica for a multi-AZ database as well
    • Read replicas can be promoted to become their own databases, but this will break replication.
  • When replicating data from primary RDS to secondary RDS instance, there is no charge (likely on exam)
  • You can change a database from single AZ to multi-AZ. This is a zero downtime operation (know this for exam)

Aurora

  • MySQL and PostgreSQL compatable, relational database engine developed by Amazon
  • Very low price, highly available and performance
  • Scaling
    • You start with a 10GB database. Storage auto-scales in 10GB increments up to 64 TB
    • Compute resources can also scale up to 32 CPUs and up to 244GB of memory
    • Maintains 2 copies of your database in each AZ with a minimum of 3 AZs, effecively giving you 6 copies of your DB
    • Designed to handle up to 2 failures
  • 2 types of replicas available
    • Aurora replicas - seperate databases, up to 15 allowed. You need to create one of these if you want auto failover if you lose your primary
    • MySQL Read Replicas - up to 5
    • Difference, if you lose your primary Aurora database failover will go over to an Aurora replica automatically. Will not fail over to MySQL Read Replica
  • Not covered in Free Tier at all
  • Aurora is only available in certain regions
  • Automatically creates 6 copies of your data across 3 AZs
    • 4 out of 6 needed for writes
    • 3 out of 6 needed for reads
    • Self healing with peer to peer replication
    • Storage is striped across 100s of volumes
  • You can only write to the master database, but Aurora provides you with a writer endpoint that points to the master. If there is failover, Aurora automatically moves the writer endpoint
  • Aurora also provides you with a single reader endpoint, and performs automatic load balancing across the read replicas for you. Load balancing happens at the connection level, not the statement level (know this)
  • Also supports a serverless option, allowing Aurora to automatically scale database capacity based upon database load (super cool)
  • Allows you to create a policy to auto-scale read replicas based upon various metrics
  • Now also supports an ability to add regions to the database cluster, essentially having a global Aurora cluster
< Previous: Elasticache Next: Developer Tools >