Databases on AWS

There are two types of backups for AWS: Automated Backups and Database Snapshots.

Whenever you restore either an Automatic Backup or a manual Snapshot, the restored version of the database will be a new RDS instance with a new DNS endpoint.

Encryption at rest is supported for all database types. Encryption is done using the AWS Key Management Service (KMS). 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 already existing DB instance is not supported. To use Amazon RDS encryption for an existing database, you must first create a snapshot, make a copy of that snapshot and encrypt the copy.

Multi-AZ allows you to have an exact copy of your production database in another Availability Zone. AWS handles the replication for you, so when your production database is written to, this write will automatically synchronized to the stand by database.

In the event of planned database maintenance, DB instance failure, or an Availability Zone failure, Amazon RDS will automatically failover to the standby so that database operations can resume quickly without administrative intervention (the DNS will automatically point to the new database).

Multi-AZ is for disaster recovery only. It is not primarily used for improving performance. For performance improvement, you need 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 replicas primarily for very read-heavy database workloads.

Note that this is currently not available for SQL Server and Oracle.

• Read Replica is used for scaling, not for DR!
• You must have automatic backups turned on in order to deploy a read replica.
• You can have up to 5 read replica copies of any database.
• You can have read replicas of read replicas (but watch out for latency.)
• Each read replica will have its own DNS end point.
• You can have read replicas that have Multi-AZ.
• You can create read replicas of Multi-AZ source databases.
• Read replicas can be promoted to be their own database. This breaks the replication.
• You can have a read replica in a second region.

Can be Single Node or Multi-Node. Single node will be 160GB. Multi-Node has a Leader Node which manages client connections and receives queries and Compute Nodes which store data and perform queries and computations. Redshift allows up to 128 compute nodes.

Instead of storing data as a series of rows, Amazon Redshift organizes the data by column. Unlike row-based systems, which are ideal for transaction processing, column-based systems are idea for data warehousing and analytics, where queries often involve aggregates performed over large data sets. Since only the columns involved in the queries are processed and columnar data is stored sequentially on the storage media, column-based systems require far fewer I/Os, greatly improving query performance.

Columnar data stores can also be compressed much more than row-based data stores because similar data is stored sequentially on disk. Amazon Redshift employs multiple compression techniques and can often achieve significant compression relative to traditional relational data stores. In addition, Amazon Redshift doesn't require indexes or materialized views and so uses less space than traditional relational database systems. When loading data into an empty table, Amazon Redshift automatically samples your data and selects the most appropriate compression scheme.

Amazon Redshift automatically distributes data and query loads across all nodes. Amazon Redshift makes it easy to add nodes to your data warehouse and enables you to maintain fast query performance as your data warehouse grows.

• Encrypted in transit using SSL.
• Encrypted at rest using AES-256 encryption.
• By default Redshift takes care of key management (you can manage your own keys if you want).

Start with 10GB, scales in 10GB increments to 64TB (this is Storage Autoscaling). Compute resources can scale up to 32vCPUs and 244GB of memory.

Aurora maintains two copies of your data in each availability zone, with a minimum of three availability zones. This is six copies of your data!

Aurora is designed to transparently handle the loss of up to two copies of data without affecting database write availability and up to three copies without affecting read availability.

Aurora storage is also self-healing. Data blocks and disks are continuously scanned for errors and repaired automatically.

Two types of replicas are available: Aurora Replicas (up to 15) and MySQL Read Replicas (up to 5).