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.

Auto Scaling Groups (ASG) allow you to have more EC2 Instances during times of high demand and less EC2 Instance (reduced cost) during times of less demand.   ASG scales up and down in real time as demand increases and decreases.  

ASG Characteristics:

    1. Scale out (add EC2 instances) as the workload increases.

    2. Scale in (removes EC2 instances) as the workload decreases.

    3. Can define minimum and maximum number of EC2 instances.

    4. Automatically registers new instances with load balancer.

    5. Starts new EC2 instance if original is unhealthy or terminated.

    6. ASG are free, but you pay when EC2 instances are running.

    7. ASG can terminate EC2 instances if ELB says they are unhealthy

Auto Scaling Group Attributes

    1. Launch Template (formally Launch Configurations) gives initial parameters of ASG

    1. AMI + Instance Type

   2. EC2 User Data

    3. EBS Volumes

    4. Security Groups

    5. SSH Key pair

    6. IAM Roles for EC2 Instances

    7. Network and subnet information

    8. Load Balancer Information

    2. Min Size, Max Size, and Initial Capacity

    3. Scaling Policies

    4. Scale ASG out/in based on CloudWatch alarms

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

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.  Click Create Auto Scaling group button.

5.  Enter a name for your ASG and click the Create a Launch template link

6.  Enter a template name and description.

7.  Under Application OS, select Quick Start, Amazon Linux.

8.  Under Instance type select t2.micro and under Key pair select any already existing pair for which you have the pem.

9.  Under Network settings select existing security group.

10.   Leave storage at 8GB and expand advance section and in user data at bottom, place startup instructions and click the Create launch template button.

11.  You will receive confirmation of success.

12.   Back at the ASG Creation page, select the template you just built and press Next button Note: you may have to hit the reset button.

13.   On the next page enter 1 for Maximum values and AZ where you want the new instances. And press Next.

 14,   At the Integrate with other services page, choose Attach to an existing load balancer and choose your load balancer, click Next

 15.  At the next pages accept the defaults and press Next.

16.   At the next pages accept the defaults and press Next.

17.   At the next pages accept the defaults and press Next.

18.   Review the configuration and press Create Auto Scaling group.

Connection Draining (CLB) or Deregistration Delay (ALB and NLB) is the time it takes to complete “in-flight requests” while an instance is de-registering or unhealthy. The load balancer will stop sending new requests to the EC2 instance in a de-registering state. This time EC2 Instance will complete current transaction while in draining state and when complete shutdown.