Overview of Amazon Relational Database Service (Amazon RDS)

Amazon Relational Database Service (RDS) is a managed database service allowing you to easily setup and operate any of the supported traditional Relational Databases (also called SQL Databases), in a highly scalable manner.

 

Amazon RDS supports following Databases:

  • Open Source Databases

MySQL

PostgreSQL

MariaDB

 

  • Commercial

SQL Server

Oracle

 

  • Amazon’s own Cloud Native RDS server

Aurora

 

Key Points for Amazon RDS

  • RDS is a fully managed service- RDS manages backups, software patching, automatic failure detection, and recovery.
  •  Administration
    • The service makes it easier for you to administer the database. The instances are pre-configured with parameters and settings pertaining to the selected RDS engine (MysQL, PostgreSQL, etc.).
    • AWS takes care of patching, with controls given to you over when and if your database instance is patched.
    • You do lose the access (or have restricted access) to certain system procedures and tables that considered system tables (meant for database engine level tuning)
  • RDS is highly scalable
    • You can scale CPU, memory, storage and IOPS individually to find a configuration that suits your database operational requirements.
    • Basic configuration of compute and memory is based on the DB instance class. Class types
      • Standard DB instance class – general purpose class meant for balanced compute, memory and network performance (db.m1, db.m3, db.m4, db.5)
      • Burstable Performance DB instance class  – provide a baseline performance level, with the ability to burst to higher CPU usage as needed (db.t2, db.t3)
      • Memory Optimized DB instance class – meant for memory intensive database applications (db.m2, db.r3, db.r4, db.r5, db.x1, db.x1e, db.z1d)
      • You can change the CPU and memory available to a DB instance by changing its DB instance class.
  • You can setup Amazon RDS in on-premise VMware environment.
  • Storage – RDS uses EBS volumes for database and log storage. RDS automatically stripes across multiple EBS volumes to enhance performance.
    • RDS offers three storage types
      • General Purpose SSD – cost-effective storage that can burst up to 3,000 IOPS for extended periods of time. Baseline performance is based on volume size
      • Provisioned IOPS – meant for I/O intensive workloads. Range is 1,000 to 80,000 IOPS for all RDS, except SQL Server (for which it’s 1,000 to 64,000 IOPS)
      • Magnetic – RDS supports magnetic storage for backward compatibility only, and is not recommended otherwise. It is limited to maximum of 3TiB, and 1,000 IOPS.
  • Enhanced Monitoring for RDS gives you detailed visibility into the health of your RDS instances. You must enable it to gain this level of details.
  • RDS Proxy is a fully managed proxy service that enables your applications to:
    • improve scalability by pooling and sharing database connections
    • improve availability by reducing database failover times by up to 66% and preserving application connections during failovers
    • improve security by optionally enforcing AWS IAM authentication to databases, and securely storing credentials in AWS Secrets Manager

 

Amazon RDS Architecture Points

 

Resilient and Highly-available Architecture

  • You can have a primary instance along with synchronous secondary instance, which can then be used to failover to (in case of issues)
  • In case of MySQL, MariaDB and PostgreSQL you can have read replicas, which can also increased read performance / scaling
  • RDS can be deployed in single AZ or on multiple AZs – the latter provides for high availability

 

Multi-AZ deployment

  • In a Multi-AZ deployment, RDS automatically provisions and maintains a synchronous Standby replica in a different AZ
    • This high-availability Standby replica is not meant for usage of read-traffic. For that purpose, you need to create Read Replicas
    • Standby replicas are different from Read-Replicas:
      • Read Replicas are are asynchronously replicated
      • Failover to Read Replicas require manual intervention, whereas failover to Standby Replicas is automatic
  • Multi-AZ deployments for MariaDB, MySQL, Oracle and PostgreSQL DB instances use Amazon’s failover technology, whereas SQL Server DB instances use SQL Server Database Mirroring (DBM) or Always On Availability Groups (AGs)

 

Failover Process

  • RDS automatically switches to a standby replica (in another AZ) when (planned or unplanned outage) causes the primary instance to become unavailable. Switch is triggered when one of the following happens:
    • AZ outage
    • Primary instance fails
    • Instance (server) type is changed
    • Software patching
    • Manual trigger – “Reboot with failover”
  • Failover times are typically 60-120 seconds, however other factors (such as lengthy recovery steps) can increase the failover time.

 

Read Replicas

  • For ready-heavy applications, you can create (up to 5) Read Replicas, to elastically scale out beyond the capacity constraints of single DB instance.
  • Once the read replica is created, the database updates (on source instance) are replicated to read replica instance using engine’s native asynchronous replication method.
    • Since it’s engine specific, the limitations of the engine’s native replication method applies, including the lag time for replication.
    • Synchronous replication is not supported for read replicas
  • Read replicas can be associated with Multi-AZ deployments to gain read scaling benefits in addition to the availability (provided by Multi-AZ architecture).
  • Automatic Backups must be enabled – that is, the value set to other than zero – to be able to create read replicas.
  • RDS (except RDS for SQL Server) supports cross-region read replicas.
  • For Aurora, RDS for MySQL and Maria DB support second-tier read replicas. That is – you can create a read replica from an existing first-tier read replica.
  • Read replicas are billed just like standard DB instance, at the same rates.

 

Backups

RDS provides two ways of backing up and restoring your database instance:

  • Automatic Backups
    • RDS automatic backup occurs daily, and create backups on S3.
      • You can specify retention period to be 0 to 35 days – specifying 0 (zero) disables the automatic backup. Default is 7 days.
      • You cannot set retention period to 0 if the DB instance is a source to a Read Replica.
    • RDS also captures transaction logs (for updates being made to DB instance)
    • When you initiate a point-in-time recovery, RDS makes use of automatic backup and the transaction logs (from the automatic backup time, and up to your specified time) to perform recovery
  • DB Snapshots
    • These are manual backups, explicitly initiated by you.
    • You can create Snapshots as frequently as you wish, and then later you can restore to that time of the backup.
    • The backups are kept (on S3) until you manually delete it.

 

  • For Multi-AZ deployments, automatic backups and DB Snapshots are simply taken from the standby to avoid I/O suspension on the primary.
  • Every time you perform a restore operation, a new DB instance is created with a new endpoint. You have you manually delete the old one, if needed.
  • Automatic backups are deleted when the DB instance is deleted. Only manually created DB Snapshots are retained after the DB Instance is deleted.

 

Security

  • RDS supports encryption at rest for all database engines, using keys you manage using AWS KMS.
    • On a database instance running with Amazon RDS encryption, data stored at rest in the underlying storage is encrypted, as are its automated backups, read replicas, and snapshots.
  • RDS supports SSL / TLS connections between an application and the database instance (all database engines)
  • For DB Instances in VPC, you will need to create / select a DB Subnet Group. RDS uses that DB Subnet Group and your preferred Availability Zone to select a subnet and an IP address within that subnet. RDS creates and associates an Elastic Network Interface to your DB Instance with that IP address.
  • All RDS database engines are HIPAA compliant

 

Limitations and Constraints on Amazon RDS

  • RDS has a maximum limit of 5 read replicas for a given source DB instance (MySQL, MariaDB, PostgreSQL, Oracle and SQL Server)
  • DB Instances limit
    • Total of 40 Amazon RDS DB instances. Of those 40, up to 10 can be Oracle or SQL Server DB instances under the “License Included” model. All 40 can be used for Amazon Aurora, MySQL, MariaDB, PostgreSQL and Oracle under the BYOL (Bring Your Own License) model. Note that RDS for SQL Server has a limit of up to 100 databases on a single DB instance. You can request additional instances by raising ticket.
  • Databases and Schemas per DB instance
    • RDS for Amazon Aurora: No limit imposed by software
    • RDS for MySQL: No limit imposed by software
    • RDS for MariaDB: No limit imposed by software
    • RDS for Oracle: 1 database per instance; no limit on number of Schemas per database imposed by software
    • RDS for SQL Server: Up to 100 databases per instance
    • RDS for PostgreSQL: No limit imposed by software

 

Pricing

Key components of how RDS instances are billed:

  • DB instance hours (per hour) – calculated based on running time. Even though rate is per hour, it is actually billed in one second increments, with a minimum of 10 minutes. Charge varies by DB instance class.
  • Storage (per GiB per month) – billed for the full capacity you have provisioned (irrespective of whether you use 100% of the capacity or 5%)
  • I/O requests (per 1 million requests per month) – meant only for magnetic storage, billed for total number of storage I/O requests
  • Provisioned IOPS (per IOPS per month) – meant only for Provisioned IOPS (SSD) storage, billed based on provisioned IOPS rate – regardless of the IOPS consumed
  • Backup storage (per GiB per month) – billed for storage used for automated backups and the database snapshots you have manually taken
  • Data transfer (per GB) – billed for data transfer in and out of your DB instance from or to the internet and other AWS Regions

Additionally pricing varies whether you use On-Demand DB Instances, or Reserved DB Instances

 

External Resources

 

 

Data Database