AWS Relational Database Service (RDS) normally contain very sensitive organizational data thus requiring the need for security.

AWS provides security of RDS data in the following ways:

• At-rest encryption:
  • RDS databases and read replicas can be encrypted using AWS KMS, but must be defined at build time
  • The main (read/write) RDS database needs to be encrypted inorder for the read replicas to be encrypted.
  • To encrypt after RDS creation, you need to take RDS snapshot and restore to new encrypted RDS.

• In-flight encryption:
  • TLS by default, using AWS TLS root certificates on the client side.
• IAM Authentication:
  • Creation of IAM roles for access to RDS database instead of username and password.
• Security Groups:
  • Controls the network access to your RDS or Aurora databases.
• No SSH available except on Custom RDS builds.
• Audit logs can be enabled and sending audit logs to CloudWatch for additional retention periods

AWS Relational Database Service (RDS) backups ensure that your data is recoverable and able to be replicated in a separate RDS datastore.

The characteristics of RDS Backups include:

• Automatic Backups:
  • Daily full backup of the database (taken during the backup window)
  • Transaction logs are backed-up by RDS every 5 minutes
  • Ability to resore to any point in time (from oldest backup to 5 minutes ago)
  • 1 to 35 days of retention, set retention to 0 disables automatic backups.
• Manual DB Snapshots
  • Manually triggered by the administer.
  • Retention of backup taken manually are as long as you want.
• Reduce cost of stopped RDS backups by taking snapshot of RDS, deleting the RDS, and restoring the the snapshot to new RDS when it is needed again.

Aurora backups have slightly different characteristics:

• Automatic backups
  • 1 to 35 days (cannot be disabled)
  • Point-in-time recovery at any point in backup timeframe.
• Manual DB Snapshots
  • Manually triggered by the administer.
  • Retention of backup taken manually are as long as you want.

Restore RDS and Aurora options:

• Restoring a RDS / Aurora backup or a snapshot creates a new database.
• Restoring MySQL RDS database from S3
  • Create a backup of your on-premises database
  • Store it on Amazon S3 (object storage)
  • Restore the backup file onto a new RDS instance running MySQL
• Restoring MySQL Aurora cluster from S3
  • Create a backup of your on-premises database using Percona XtraBackup
  • Store the backup file on Amazon S3
  • Restore the backup file onto a new Aurora cluster running MySQL

Aurora Database Cloning

• Create a new Aurora DB Cluster from an existing one.
• Faster than snapshot and restore
• Uses copy-on-write protocal
  • initially, the new DB cluster uses the same data volume as the original DB cluser (fast and efficient – no copying is needed)
  • When updates are made to the new DB cluster data, then additional storage is allocated and data is copied to be separated.
• Very fast and cost-effective
• Useful to create test or development database from production database without impacting production database.

AWS Aurora RDS is the proprietary Amazon RDBMS system fully compatible with MySQL and PostgreSQL.  This document will demonstrate the build of Aurora RDS servers in the AWS environment.

1.   Logon to AWS as an IAM user at URL:  https://signin.aws.amazon.com/

2.   From the Home Console type RDS in the search bar, select the star next to RDS, and select RDS.   NOTE:  The name of the Console has changed over time, but the key wording is RDS.

3.   On the left hand menu bar select Databases.

4.   Currently we have no RDS databases created and thus none are listed.   Click Create database on the right hand side of the screen.

5.   Select standard creation and for this example we will create a Aurora (postgreSQL) database.

6.   Select the Engine Version you desire and Dev/Test

7.   Enter the DB identifier, master user name, Self Managed and password

8.   Enter Aurora Standard for Cluster storage.

 9.   Instance configuration select the standard configuration.

10.   Under VPC select the standard and note the VPC selected. As well as the DB subnet.  Select Yes for public accessible.

11.  Accept the rest of the defaults and select Create Database

12.  This completes build of Aurora RDS database service on AWS.

AWS Relational Database Service (RDS) Custom gives you all the automation of RDS and access to the underlying database and OS.

RDS Custom you can perform the following tasks:

• Configure underlying OS settings.
• Install Patches.
• Enable native features.
• Access underlying EC2 Instance using SSH and SSM Session Manager.
• Only available for Oracle and Microsoft SQL Server.

NOTE: While using RDS Custom, it is important De-active Automation Mode to prevent overriding of you customized changes.

RDS vs RDS Custom

• RDS: manages entire database and OS by AWS.
• RDS Custom: full admin access to the underlying OS and database.

AWS Amazon Aurora is a database engine developed by Amazon and offered as a service by AWS. Aurora has the following characteristics:

1. Aurora is a proprietary technology of AWS and is not open source.
2. Fully compatible with Postgres and MySQL, all drivers for these database engines will work with Aurora.
3. Aurora is “AWS cloud optimized” and it is claimed that you can achievet 5x faster than MySQL and 3x faster than Postgres.
4. Aurora automatically grows in 10GB chunks up to 128TB
5. Aurora can have 15 replicas and replication is after than other RDSs
6. Failover in Aurora is instantaneous and is High Availability native.
7. Aurora cost more than other RDS by 20%, but it is more efficient.
8. Automatic fail-over
9. Backup and Recovery
10. Isolation and security
11. Industry compliance
12. Push-button scaling
13. Automatic patching with zero downtime
14. Advanced Monitoring
15. Routine Maintenance.

Aurora High Availability and Read Scaling

1. 6 copies of you data across 3 AZ
a. 4 copies out of 6 needed for writes.
b. 3 copies out of 6 needed for reads.
c. Provides self healing by way of peer to peer replication.
d. Storage is striped across 100s of volumns.
2. One Aurora Instance takes the writes and is the master copy.
3. If Master fails the failover is less than 30 seconds.
4. Master + 15 Read Replicas and any of the Read Replicas can be promoted to Master.
5. Read Replicas support Cross Region Replication

Aurora DB Cluster

1. Applications are given a Writer Endpoint which points to the Instance which currently is the Master.
a. This Writer Endpoint will redirect traffic to new Master if it changes.
2. Application are given a Reader Endpoint which connects to read replica copies through load balancing
a. This Reader Endpoint will remove instance that is promoted to Master

AWS Relational Database Service (RDS) console is normally used to create RDS services, however they can be deployed via the CLI, CloudShell or even from an EC2 Instance.   This article will cover the creation of an AWS RDS using the console.

1.   Logon to AWS as an IAM user at URL:  https://signin.aws.amazon.com/

2.   From the Home Console type RDS in the search bar, select the star next to RDS, and select RDS.   NOTE:  The name of the Console has changed over time, but the key wording is RDS.

3.   On the left hand menu bar select Databases.

4.   Currently we have no RDS databases created and thus none are listed.   Click Create database on the right hand side of the screen.

5.   Select standard creation and for this example we will create a MySQL database.

6.   Select MySQL Community and the Engine Version you desire.

7.   Under templates, select the Free tier option.

8.   Under Availability and durability, we have only one option in free tier, but you can see the other options available would be for Multi-AZ and Read-Replicate.

 9.   Under DB Instance Identifier place the name of you database, Name for the Master User, select Self Managed, and enter a password for the Master user.

10.   Accept standard for Instance Configuration and  Storage.

11.   Under Connectivity, select EC2 compute resources and select one of your existing EC2 Instances.    NOTE:  We are doing this to provide a tunnel into the RDS system for administration via CLI or SSH. Accept the IPv4.

12.   Under VPC security group, select the security groups for applications and EC2 Instances you desire to have access to the RDS Services.

 13.   Under Database authentication select Password and IAM database authentication.  Under Monitoring select Database Insights.

14.   Select Create database, to build your RDS MySQL database.

 15.   Your new RDS database will appear in the database listing with configrmation.

16.   This completes build of MySQL RDS database service on AWS.

Read Replicas allow us to scale our read operations in AWS RDS.

They have the following characteristics:

  1. You can have up to 15 Read Replicas

  2. They can be within same AZ, Cross AZ, or Cross Region

  3. Replication is Async from R/W database so they eventually are consistent

  4. The Read Replica can be promoted to become its own database

  5. Application must update the connection string to use Read Replicas.

  6. Read Replicas can be setup as Multi AZ for Disaster Recovery, but it will not have SYNC updates, so can loss data.

  7. Use Case for Read Replicas: Moving Reporting and Analytics off read/write database.

======================

Networking Cost associated with Read Replica:

  1. Network costs are incurred when data goes from one AZ to another normally.

  2. Read Replica traffic within the same Region and different AZ are not charged a network fee.

  3. Read Replica traffic in different Regions and different AZ are charged a network fee.

======================

RDS Multi AZ is normally used for disaster Recovery and they have the following characteristics:

  1. You have an RDS Standby database in one AZ with the RDS Master database in another AZ.

  2. The RDS Master sends SYNC replication to the Standby RDS, the writes to standby RDS must be completed before transaction on Master is complete.

  3. One connection to RDS DNS name with automatic app failover to standby.

  4. This failover increases the overall availability of the RDS.

  5. Failover occurs during loss of AZ, loss of network, loss of instance, or loss of storage.

  6. No manual changes to application is required during failover.

  7. This is not used for scaling of any type.

======================

Moving RDS from Single AZ to Multi AZ

  1. Zero down operation, never loss use of the RDS database.

  2. Only need to click “modify” for the database and select multi-AZ.

  3. Internally, the following occurs:

    a. Snap shot is taken of the Master database.

    b. New database creased from snapshot in a new AZ

    c. Synchronization is established between the two databases.

Scaling Policies allow you to set parameter for the scaling groups in and out operations. Typical things you would place scaling policies on are: CPUUtilization and RequestCountPerTarget. Policies have a cool-down period for both in and out scaling with a default of 300seconds or 5 minutes. The ASG will add or remove one instance at a time and evaluate if further increase or decrease is necessary. Using standard AMI allows your cool-down period to be reduced because you will see the effects of adding or removing instances quicker.

==================================================

1.  Logon to AWS as an IAM user at URL:  https://signin.aws.amazon.com/

2.  From the Home Console type EC2 in the search bar, select the star next to EC2, and select EC2

3.  On the left hand menu bar select Auto Scaling Groups.

4.  Select the ASG you wish to create a policy for and scroll down to Automatic scaling.  Under Under here you can setup three different types:

• •.Dynamic scaling policies – based on percentage of use of CPU, Connects,etc 
• •.Predictive scaling policies – based on EventWatch alerts. 
• •.Scheduled actions  – based on times ie working hours or work days. 

Dynamic scaling policies:

5.  Predictive scaling policies:

6.   Scheduled Actions:

7.  Select Select metric button and chose the metric that best fits.