AWS CSA
  • Introduction
  • 1. AWS Overview
    • 1.1 AWS global Infrastructure
    • 1.2 Networking and Content Delivery
    • 1.3 Computing
    • 1.4 Storage
    • 1.5 Databases
    • 1.6 Migration Services
    • 1.7 Analytics
    • 1.8 Security and Identity
    • 1.9 Management Tools
    • 1.10 Application Services
    • 1.11 Developer Tools
    • 1.12 Mobile Services
    • 1.13 Desktop and App Streaming
    • 1.14 Artificial Intelligence
    • 1.15 Messaging
  • 2. IAM - Identity Access Management
    • 2.1 IAM Introduction
    • 2.2 IAM Labs
    • 2.3 Create a billing alart
    • 2.4 IAM Conclusion
  • 3. S3 - Simple Storage Service
    • 3.1 S3 Introduction
    • 3.2 S3 Labs
    • 3.3 Version Control Labs
    • 3.4 Cross Region Replication
    • 3.5 Life Cycle Management
    • 3.6 CloudFront
    • 3.7 CloudFront Labs
    • 3.8 S3 Security and Encryption
    • 3.9 Storage Gateway
    • 3.10 Snowball
    • 3.11 Snowball Labs
    • 3.12 S3 Transfer Acceleration
    • 3.13 Create a static web page using S3
    • 3.14 Storage Summary
  • 4. EC2 - Elastic Compute Cloud
    • 4.1 EC2 Introduction I
    • 4.2 EC2 Introduction II
    • 4.3 EC2 Lab 1
    • 4.4 EC2 Lab 2
    • 4.5 Security Groups Lab
    • 4.6 Upgrade EBS Volume Types - Lab1
    • 4.7 Upgrade EBS Volume Types - Lab2
    • 4.8 RAID, Volumes & Snapshots
    • 4.9 Create An AMI - Lab
    • 4.10 AMI's EBS Root Volumes vs. Instance Store
    • 4.11 Elastic Load Balancer & Health Check - Lab
    • 4.12 CloudWatch EC2 - Lab
    • 4.13 The AWS Command Line & EC2
    • 4.14 Using IAM Roles with EC2
    • 4.15 S3 CLI & Regions
    • 4.16 Using Bootstrap Scripts
    • 4.17 EC2 Instance Metadata
    • 4.18 Launch Configurations & Auto Scaling Groups
    • 4.19 EC2 Placement Groups - Exam Must Know
    • 4.20 Elastic File System (EFS) Lab
    • 4.21 Lambda Concepts
    • 4.22 Build A Serverless Webpage Using API Gateway & Lambda
    • 4.23 Use Polly to Pass Your Exam - Lab of a Serverless Application
    • 4.24 Use Polly to Pass Your Exam - Lab of a Serverless Application
    • 4.25 EC2 - Summary & Exam Tips
  • 5. Route53
    • 5.1 DNS 101
    • 5.2 Route53 - Register A Domain Name - Lab
    • 5.3 Setup Our EC2 Instances - Lab
    • 5.4 Routing Policies - Lab
  • 6. Databases on AWS
    • 6.1 Databases 101
    • 6.2 Launching an RDS Instance - Lab
    • 6.3 RDS - Backups, Multi-AZ & Read Replicas
    • 6.4 DynamoDB
    • 6.5 Redshift
    • 6.6 ElastiCache
    • 6.7 Aurora
    • 6.8 Database Summary
  • 7. VPC
    • 7.1 VPC Overview
    • 7.2 VPC Lab - Part 1
    • 7.3 VPC Lab - Part 2
    • 7.4 NAT Instances & NAT Gateways
    • 7.5 Network Access Control Lists vs. Security Groups
    • 7.6 Load Balancers & Custom VPCs
    • 7.7 VPC Flow Logs
    • 7.8 NATs vs. Bastions
    • 7.9 VPC End Points
    • 7.10 VPC Clean Up
    • 7.11 VPC Summary
  • 8. Application Services
    • 8.1 SQS - Simple Queue Service
    • 8.2 SWF - Simple Workflow Service
    • 8.3 SNS - Simple Notification Service
    • 8.4 Elastic Transcoder
    • 8.5 API Gateway
    • 8.6 Kinesis 101
    • 8.7 Kinesis Streams Lab
    • 8.8 Application Services Summary
  • 9. White Paper Reviews
    • 9.1 Overview of AWS
    • 9.2 Overview of Security Processes - Part 1
    • 9.3 Overview of Security Processes - Part 2
    • 9.4 Risk & Compliance Whitepaper
    • 9.5 Storage Options in the Cloud Whitepaper
    • 9.6 Architecting For The Cloud Best Practices Whitepaper
  • 10. Well Architected Framework
    • 10.1 Introduction of Well Architected Framework
    • 10.2 Pillar One - Security
    • 10.3 Pillar Two - Reliability
    • 10.4 Pillar Three - Performance
    • 10.5 Pillar Four - Cost Optimization
    • 10.6 Pillar Five - Operational Excellence
    • 10.7 Well Architected Framework - Summary
  • 11. Additional Exam Tips
    • 11.1 Exam Tips Based On Student Feedback
    • 11.2 Consolidated Billing
    • 11.3 AWS Organizations - Lab
    • 11.4 Cross Accounts Access
    • 11.5 Resource Groups & Tagging
    • 11.6 VPC Peering & ClassicLink
    • 11.7 Direct Connect
    • 11.8 Security Token Service
    • 11.9 Active Directory Integration
    • 11.10 Workspaces
    • 11.11 ECS - Part 1 - What is Docker
    • 11.12 ECS - Part 2 - What is ECS
    • 11.13 CloudFormation - A Brief Introduction
    • 11.14 Step Functions - A Brief Introduction
  • 12. Practice Tests Questions Summary
    • 12.1 Whizlabs - Free Test
    • 12.2 Whizlabs - Diagnosis Test
    • 12.3 Whizlabs - Practice Test I
    • 12.4 Whizlabs - Practice Test II
    • 12.5 Whizlabs - Practice Test III
    • 12.6 Whizlabs - Practice Test IV
    • 12.7 Whizlabs - Practice Test V
    • 12.8 Whizlabs - Practice Test VI
    • 12.9 Whizlabs - Practice Test VII
    • 12.10 Whizlabs - Section Tests - Part 1
    • 12.11 Whizlabs - Section Tests - Part 2
    • 12.12 Udemy - Final Quiz
  • 13. The Real World - Creating a fault tolerant Word Press Site
    • 13.1 Getting Setup
Powered by GitBook
On this page
  • Backups
  • Encryption
  • Steps of backups and encryption:
  • Multi-AZ (High Availability)
  • Read Replicas
  • Steps of Read Replicas
  • DynamoDB vs. RDS

Was this helpful?

  1. 6. Databases on AWS

6.3 RDS - Backups, Multi-AZ & Read Replicas

Backups

There are two different types of backups for AWS RDS. Automated backups and Database snapshots.

  • Automated backups.

    • It allows you to recover your database to any point in time within a "retention period". Retention period can be between 1 and 35 days. By default, when you create a RDS database, it is 7 days retention period is selected. Automated backups will take a full daily snapshot and will also store transaction logs throughout the day. When you do a recovery, AWS will first choose the most recent daily backup, and then apply transaction logs relevant to that day. This allows you to do a point in time recovery down to a second, within the retention period. So you can at most go back 35 days. You can say I want to recover my database to Friday afternoon at 2:35 pm and 45 seconds. This automated backup is built in RDS so you don't need to worry about this and you just need to turn on automated backups.

    • Automated backups are enabled by default. The backup data is stored in S3 and you get free storage space equal to the size of your database. So if you have an RDS instance of 10GB, you will get 10GB worth of storage.

    • Backups are taken within a defined window. During the backup window, storage IO may be suspended while your data is being backed up and you may experience elevated latency. The best practice is to choose a backup window when your database is not being utilized very heavily.

  • Snapshots

    • DB snapshots are done manually (i.e. they are user initiated). They are stored even after you delete the original RDS instance, unlike automated backups. The automated backups will be automatically deleted if you delete the RDS instance, but it will prompt you to do a final database backup which can restore as well.

  • For both of automated backups and database snapshots, whenever you restore either an automated backup or a manual snapshot, the restore version of the database is always a new RDS instance with a new DNS end point.

Encryption

Encryption at rest is supported for MySQL, Oracle, SQL Server, PostgreSQL & MariaDB. Encryption is done using the AWS key Management Service (KMS) service. Once your RDS instance is encrypted the data stored at rest in the underlying storage is encrypted, as are its automated backups, read replicas, and snapshots.

At the present time, encrypting an existing DB instance is not supported. To use Amazon RDS encryption for an existing database, create a new DB instance with encryption enabled and migrate your data into it.

Steps of backups and encryption:

  • Go to the RDS dashboard and select Instances and select the MySQL database we created in last lecture.

  • Click Instance Actions -> Take Snapshot. This will take a snapshot manually.

  • Go to RDS dashboard and select Snapshots. You can see there are lots of snapshots, some of them are automated backups, some of them are manual snapshots. You can do a point in time recovery for any of these snapshots.

  • You can select a snapshot, and click restore snapshot. When you restore a snapshot it does create a new database, so you have to give it a new DB instance identifier. For now, just set Multi-AZ to No, set Availability Zone to No Preference, and set Publicly Accessible to Yes, and leave other things as default. Click Restore.

  • Go to Instances, there will be two DB instance. One is the old one, it is being backed up, and the other one is being created. Select the being backed up one, and click Instance Actions -> Restore to Point in Time, so that you can configure a specific point of time to restore if you want.

  • Thus, you can do a full snapshot restoration, or you can do a point of time restoration.

  • Go to Snapshots, you can select a snapshot and copy it. This will copy this snapshot to another Region. If you want scale up your database, you can take a manual snapshot for it, and then restore this snapshot, and you can choose another DB instance class so that scale up your database.

  • You cannot restore a encrypted copy from a snapshot if the original database instance of this snapshot is not encrypted. You need to create a new RDS instance which is encrypted. Go to launch a new DB instance, select MySQL and Production one. Select Multi-AZ to be Yes, and select the DB instance class and give it a identifier, username and password and then click next. Then set the Enable Encryption to be Yes. Then it will give a Master Key, and that key is stored using KMS. This is how you encrypt a RDS database instance.

Multi-AZ (High Availability)

What is multi-AZ?

In the event of planned database maintenance, DB instance failure, or an AZ failure, Amazon RDS will automatically failover to the standby so that database operations can resume quickly without down time and administrative intervention.

Amazon RDS automatically performs a failover in the event of any of the following:

  • Loss of availability in primary AZ

  • Loss of network connectivity to primary

  • Compute unit failure on primary

  • Storage failure on primary

When failing over, Amazon RDS simply flips the canonical name record (CNAME) for your DB instance to point at the standby, which is in turn promoted to become the new primary. Failovers typically complete within one to two minutes.

Note: when operations such as DB instance scaling or system upgrades like OS patching are initiated for multi-AZ deployments, for enhanced availability, they are applied first on the standby prior to an automatic failover. As a result, your availability impact is limited only to the time required for automatic failover to complete. Amazon RDS multi-AZ deployments do not failover automatically in response to database operations such as long running queries, deadlocks or database corruption errors.

Multi-AZ is for HA and Disaster Recovery only. It is not primarily used for improving performance. For performance improvement you need Read Replicas.

Multi-AZ databases are available for SQL Server, Oracle, MySQL, PostgreSQL and MariaDB.

Amazon RDS provides high availability and failover support for DB instances using Multi-AZ deployments. Amazon RDS uses several different technologies to provide failover support. Multi-AZ deployments for Oracle, PostgreSQL, MySQL, and MariaDB DB instances use Amazon's failover technology. SQL Server DB instances use SQL Server mirroring. Amazon Aurora instances stores copies of the data in a DB cluster across multiple Availability Zones in a single AWS Region, regardless of whether the instances in the DB cluster span multiple Availability Zones.

Read Replicas

What is Read Replicas?

Read Replicas allow you to have a read only copy of your production database. This is achieved by using Asynchronous replication from the primary RDS instance to the read replica. You use read replica's primarily for very read-heavy database workloads. (You could also use In-memory cache).

Read Replica Database supports MySQL Server, PostgreSQL, and MariaDB.

Read Replica Tips:

  • It is used for scaling, not DR (disaster recovery).

  • Must have automatic backups turned on in order to deploy a read replica

  • You can have up to 5 read replicas copies of any databases.

  • You can have read replicas of read replicas (but watch out for latency, it is asynchronized replication)

  • Each read replica will have its own DNS end point.

  • You cannot have Read Replicas that have Multi-AZ.

  • You can create Read Replica's of multi-AZ source database however.

  • Read Replicas can be promoted to be their own databases. This breaks the replication. So in this way you can write to it, because you can only read from Read Replicas, you cannot write to it.

  • Read Replica in a second region for MySQL and MariaDB. Not for PostgreSQL.

Steps of Read Replicas

  • Go to select a DB instance. Go to Instance Actions and click Create Read Replicas.

DynamoDB vs. RDS

DynamoDB offers "push button" (automatic) scaling, meaning that you can scale your database on the fly, without any downtime.

RDS is not easy and you usually have to use a bigger instance size or to add a read replica. This needs to be done manually.

Previous6.2 Launching an RDS Instance - LabNext6.4 DynamoDB

Last updated 5 years ago

Was this helpful?

Multi-AZ allows you to have an exact copy of your production database in another Availability Zone (select the Production plan when you create your DB instance, Dev/Test plan will not support Multi-AZ and Provisioned IOPS Storage). AWS handles the replication for you, so when your production database is written to, this write will automatically be synchronized to the stand by database.