AWS学习笔记——Chapter8 Databases on AWS

前注：
学习书籍<AWS Certified Solutions Architect Associate All-in-One Exam Guide (Exam SAA-C01)>时记录的笔记。
由于是全英文书籍，所以笔记记录大部分为英文。

Databases on AWS

1. Understanding the Amazon Relational Database Service

(1) 7 RDBMS engines

Aurora MySQL, Aurora PostgreSQL, Oracle, SQL Server, MySQL, PostgreSQL, MariaDB

(2) Scenario 1: Hosting the database in your data center on-premises

Take care of everything

(3) Scenario 2: Hosting the database on Amazon EC2 Servers

You take care of the stuff on the left, AWS takes care of the stuff on the right.

(4) Scenario 3: Hosting the database using Amazon RDS

You just need to focus on application optimization.

(5) Benefits by running your database on RDS

· No infrastructure management

· Instant provisioning

· Scaling

· Cost effective

· Application compatibility

· Highly available

· Security

2. Hosting a Database in Amazon EC2 vs Amazon RDS

RDS is a managed service. It takes a lot of burden off your hands, but you also don’t get access to the database host operating system, you have limited ability to modify the configuration that is normally managed on the host operating system, and generally you get no access to functions that rely on the configuration from the host operating system.

All of your storage on RDS is also managed. There are storage limits of 16TB with MySQL, SQL server, Maria DB, PostgreSQL and Oracle, and 64TB with Aurora.

(1) You should choose RDS if

· You want to focus on tasks that bring value to your business

· You don’t want to manage the database

· You want to focus on high-level tuning tasks and schema optimization

· You lack in-house expertise to manage databases

· You want push-button multi-AZ replication

· You want automated backup and recovery

(2) You should choose EC2 if

· You need full control over the database instances

· You need operating system access

· You need full control over backups, replication and clustering

· Your RDBMS engine features and options are not available in Amazon RDS

· You size and performance needs exceed the Amazon RDS offering

3. High Availability on Amazon RDS

Amazon RDS supports high availability (HA) architectures.

(1) Simplest Architecture: Single-AZ Deployment

The scenarios may live with downtime: some sort of proof of concept, deploy development environments, or deploy noncritical nonproduction environments.

Launch the Amazon RDS instance in a single AZ, with this you get a single RDS instance inside a VPC with the necessary attached storage.

(2) High Availability: Multiple AZs

The scenarios that must deploy the database in a multi-AZ architecture: run a mission-critical database, want to have an architecture where you can’t afford to lose data, have a tight recovery point objective, or can’t afford much downtime.

In a multi-AZ architecture, you can choose which AZ you want your primary database instance (/master database instance) to be in.

RDS will then choose to have a standby instance and storage in another AZ of the AWS region that you are operating in.

The standby instance will be of the same type, the same configuration and size as your primary instance.

The master database handles all the traffic, the standby database doesn’t remain open when it acts as a standby database, so you can’t direct the traffic to the primary and standby databases at the same time.

In the multi-AZ architecture, the application connects to the database server using a DNS endpoint that is mapped to the master and standby instances, so you don’t have to repoint or change anything from the application side.

4. Scaling on Amazon RDS

(1) Changing the instance type

The simplest way to scale up or down is to change the instance type.

You can change from one class of instance to another class of move up and down between the same classes of instance.

Apply the change immediately: could be some downtime since it is changed.

Don’t apply the change immediately: the change will be scheduled to occur during the preferred maintenance window.

RDS is not integrated with Auto Scaling, but you can achieve this by writing a Lambda function. You can also automate the scale-up of the instance based on certain events (may be using a combination of Lambda, CloudWatch and SNS).

(2) Read Replica

A read replica is a read-only of your master database that is kept in sync with your master database.

You can have up to 15 read replicas in RDS depending on the RDBMS engine.

Benefits:

· Can offload read-only traffic to the read replica and let the master database run critical transaction-related queries.

· If you have users from different locations, you can create a read replica in a different region and serve the read-only traffic via the read replica.

· The read replica can also be promoted to a master database when the master database
goes down.

Configuration:

· Master-standby configuration

The replication of data is always synchronous, no data loss when the standby is promoted to master.

· Master and read replica configuration

The replication is asynchronous, could be some data loss when a read replica is promoted to master.

· Master, standby and read replica configuration

The cases that you can’t afford data loss and need read replicas.

Regions:

· An intra-region allows you to create additional read replicas within the same AWS region, but in the same or different availability zones from your master database. Supported by MySQL, MariaDB, PostgreSQL, Aurora MySQL and Aurora PostgreSQL.

· Cross-regional replication allows you to deploy the read replica into an AWS region that is different from the region that your master is located in. Supported by MySQL, MariaDB, PostgreSQL, Aurora MySQL and Aurora PostgreSQL.

Notes:

CurrentlybRDS doesn’t support read replicas for Oracle and SQL Server. You can achieve this by using Oracle Golden Gate or some of the AWS partner products such as Attunity and SnapLogic to replicate data between two RDS instances of Oracle or SQL Server.

5. Security on Amazon RDS

(1) Amazon VPC and Amazon RDS

It is recommended that you create the database in the private subnet.

Multiple ways of connecting the database runs in VPC:

· Create a VPN connection from your corporate data center into the VPC.

· Use Direct Connect to link your data center to an AWS region.

· Peer two different VPCs together, allowing applications in one VPC to access your database in your VPC.

· Grant public access to your database by attaching an Internet Gateway to your VPC.

· Use route table that you attach to each of the subnets in your VPC to control the routing of your VPC.

Can create security groups within RDS and control the flow of traffic.

This gives you the flexibility to have a multitier architecture where you grant connections only from the parts of the tier that actually need to access the database.