AWS: Amazon Aurora

Aurora Read Replicas

Up to 15 Aurora Replicas can be distributed across the Availability Zones

• DB cluster volume is made up of multiple copies of the data for the DB cluster
• The data in the cluster volume is represented as a single, logical volume to the primary instance and to Aurora Replicas in the DB cluster

Due to this cluster volumes architecture, Aurora Replicas can return the same data for query results with minimal replica lag

• Usually much less than 100 milliseconds after the primary instance has written an update.
• Because the cluster volume is shared among all instances, to additional work is required to replicate a copy of the data for each aurora replica.

In contrast to Amazon RDS MySQL, Read Replicas must replay, on a single thread, all write operations from the master DB instance to their local data store.

• This affects the ability of the Read Replica to support large volumes of reads.

Auto Scaling with Aurora Replicas

Aurora Auto Scaling dynamically adjusts the number of Aurora Replicas provisioned for an Aurora DB cluster using single master replication.

Aurora Auto Scaling enables Aurora DB clusters to handle sudden increase in connectivity or workload.

• When the connectivity or workload decreases, Aurora Auto Scaling removes unnecessary Aurora Replicas so that no change will be incured for unused provisioned DB instances.

Define and apply a scaling policy to an Aurora DB cluster. The scaling policy defines the minimum and maximum number of Aurora Replicas that Aurora Auto Scaling can manage.

• Based on the policy, Aurora Auto Scaling adjusts the number of Aurora Replicas up or down in response to actual workloads, determined by using Amazon Cloud Watch metrics and target values.
• Aurora Auto Scaling is available for both Aurora MySQL and Aurora PostgreSQL.
• Although Aurora Auto Scaling manages Aurora Replicas, the Aurora DB cluster must start with at least one Aurora Replica.

Amazon Aurora-Primary Fail over

If the primary DB instance of a DB cluster fails, Aurora automatically fails over to a new primary DB instance.

• It does so by either promoting an existing Aurora Replica to a new primary DB instance OR creating a new primary DB instance.

During a failover, the reader endpoint might direct connections to the new primary DB instance of a DB cluster for a short time after an Aurora Replica is promoted to the new primary DB instance.

If the primary instance fails, an Aurora Replica is promoted to the primary instance.

• There is brief interruption during which read and write requests to the primary instance fail with an exception, and the Aurora Replica are rebooted.

If your Aurora DB cluster doesn't include any Aurora Replicas then your DB cluster will be unavailable for the duration it takes your DB instance to recover from the failure event.

• Promoting an Aurora Replica is much faster than recreating the primary instance.
• For high availability scenarios, AWS recommends creating one or more Aurora Replicas of the same DB instance class as the primary instance and in different Availability Zones for your DB cluster.

Amazon Aurora-Failover, Cluster Endpoint, and DNS

Rebooting the primary instance of an Amazon Aurora DB cluster also automatically reboots the Aurora Replicas for that DB cluster, in order to re-establish an entry point that guarantees read/write consistency across the DB cluster.

The physical IP address pointed to by the cluster endpoint changes when the fail over mechanism promotes a new DB instance to be the read write primary instance for the cluster.

Amazon Aurora-Storage and Reliability

Aurora’s distributed and storage architecture is an important factor in performance, scalability and reliability for Aurora clusters.

• Aurora data is stored in solid state drives.

Aurora maintains multiple (at least 2) copies of your data three availability zones, in a single AWS region.

• This makes Aurora cluster volume highly durable and hence, the change of losing data as a result of a disk failure is greatly minimized.

This replication also ensures that your database is more available during a failover.

• It does so because the data copies already exist in the other Availability Zones and continue to serve data requests to the DB instances in your DB cluster.
• The amount of replication is independent of DB instances in your cluster.

This Aurora shared storage architecture makes:

• Adding and Removing DB instance becomes quicker since there is no need for Aurora to copy data to the new DB instance.
• Removing a DB instance from a cluster without removing any of the underlying data from the cluster.

Amazon Aurora- Storage and Reliability

Aurora cluster volumes automatically grow as the amount of data in your database increases.

An Aurora cluster volume can grow to a maximum size of 64 tebibytes

• Table size is limited to the size of the cluster volume, so it can be upto 64 TiB

Customers are only charged for the space used in an Aurora cluster volume.

When Aurora data is removed, such as by dropping a table or partition, the overall allocated space remains the same.

• The free space is reused automatically when data volume increases in the future.

Amazon Aurora_ High Availability

In an Aurora cluster single master replication when creating reader instances across Availability Zones, Amazon RDS automatically provisions and maintains them synchronously.

Amazon Aurora -Security

Security for Amazon Aurora is managed in different levels:

• IAM is used to control who can perform Amazon RDS management actions on Aurora DB clusters and DB instances.

Aurora DB cluster must be created in an Amazon Virtual Private Cloud (VPC)

• An Amazon VPC endpoint for Amazon Aurora is a logical entity within a VPC that allows connectivity only to Amazon Aurora.
• The Amazon VPC routes intra VPC requests to Amazon Aurora and routes responses back to the VPC through the vpc endpoint.

To control which devices and Amazon EC2 instances can open connections to the endpoint and port of the DB instance for Aurora DB cluster in a VPC, a VPC security group is used.

Amazon Aurora-Encryption

SSL can be used from the client application to encrypt a connection to a DB cluster running Aurora MySQL or Aurora PostgreSQL.

Encrypt Amazon Aurora DB clusters and snapshots at rest by enabling the encryption option for Aurora DB clusters.

• Data that is encrypted at rest includes the underlying storage for DB clusters, its automated backups, Read Replicas and snapshots.
• Database clients need not to be modified to use encryption.

Amazon Aurora encrypted DB clusters use the industry standard AES256 encryption algorithm.

You can’t convert an unencrypted DB cluster to an encrypted one.

• You can, however, restore an unencrypted Aurora DB cluster snapshot to an encrypted Aurora DB cluster.

To do this specify a KMS encryption key when you restore from the unencrypted DB cluster snapshot.

• DB clusters that are encrypted cant be modified to disable encryption.

As of now, an encrypted Aurora Replica cant be created from an unencrypted Aurora DB cluster and

• An unencrypted Aurora Replica cant be created from an encrypted Aurora DB cluster.

Amazon Aurora Global Data Base

An Aurora global database consists of one primary AWS Region where data is mastered, and one read-only, secondary AWS Region.

• The Aurora cluster in the primary AWS Region performs both read and write operations.
• The cluster in the secondary region enables low-latency reads
• The secondary cluster can be scaled up independently by adding one or more (up to 16) Aurora Replicas to serve read only workloads.

Aurora replicates data to the secondary AWS Region with typical latency of under a second.

• An Aurora global database uses dedicated infrastructure to replicate your data, leaving database resources available entirely to serve application workloads.

If you have an existing Aurora cluster, you can take a snapshot and restore it to a new Aurora global database.

You can manually activate the failover mechanism if a cluster in a different AWS Region is a better choice to be primary cluster.

Amazon Aurora with other AWS Services

You can use Aurora MySQL DB native function or stored to invoke Lambda functions.

Loading data into a table from text files in an Amazon S3 bucket is available for Amazon Aurora MySQL.

It is possible to query data from an Amazon Arora MySQL DB cluster and save it directly into text files stored in an Amazon S3 bucket.

• This functionality can be used to skip bringing the data down to the client first, and then copying it from the client to Amazon S3.

Amazon Aurora MySQL Replication- Across AWS Regions

An Amazon Aurora MySQL DB cluster can be created as a Read Replica in a different AWS Region than the source DB cluster:

This approach can:

• Improve your disaster recovery capabilities,
• Allows for scaling read operations into an AWS Region that is closer to your users and
• Can make it easier to migrate from one AWS Region to another.

You can create Read Replicas of both encrypted and unencrypted DB clusters.

• The Read Replica must be encrypted if the source DB cluster is encrypted

For each source DB cluster, you can have up to five cross region DB clusters that are Read Replicas.

When creating the Read Replica, Amazon RDS takes a snapshot of the source cluster and transfers the snapshot to the Read Replica region.

In a cross-region scenario, there is more lag time between the source DB cluster and the Read Replica due to the longer network channels between regions.

You can promote an Aurora MySQL Read Replica to a standalone DB cluster.

• When you promote an Aurora MySQL Read Replica, its DB instances are rebooted before they become available.
• The promotion process can take several minutes or longer to complete, depending on the size of the Read Replica.

Typically, you promote an Aurora Read Replica to a standalone DB cluster as a data recovery scheme if the source DB cluster fails.

Amazon RDS MySQL DB to Aurora MySQL Replication

Since Amazon Aurora MySQL is compatible with RDS MySQL,

• Replication between a RDS MySQL database and an Amazon MySQL DB cluster can be achieved,

This requires InnoDB engine

AWS recommends that the RDS MySQL database run MySQL version 5.5 or later.

You can set up replication such that the Aurora MySQL DB cluster is the replication master or the replica.

• You can replicate with:

An Amazon RDS MySQL DB instance,

A MySQL database external to Amazon RDS, or

Another Aurora MySQL DB cluster.

• You can also replicate with an Amazon RDS MySQL DB instance or Aurora MySQL DB cluster in another AWS Region.
• When you are performing replication across AWS regions, ensure that your DB clusters and DB instances are publicly accessible.

This means Aurora MySQL DB clusters must be part of a public subnet in your VPC.

• In addition to Aurora Replicas in Aurora PostgreSQL cluster, you can setup replication between an Amazon RDS PostgreSQL DB instance as the master and an Aurora PostgreSQL DB cluster.
• You do by creating an Aurora Read Replica of an Amazon RDS PostgreSQL DB instance.

Amazon Aurora-Automatic Backup and Manual Snapshots

Aurora backs up your cluster volume automatically and retains restore data for the length of the backup retention period.

Aurora backups are continuous and incremental so you can quickly restore to any point within the backup retention period.

• Recover your data to any given time during the retention period by creating a new Aurora DB cluster from the backup data that Aurora retains.

No performance impact or interruption of database service as backup data is being written.

Manual snapshots of the data can also be created for cluster volume to retain a backup retention period. A new DB cluster cab be created from these snapshots.

Amazon Aurora- Sharing DB Cluster Snapshots

Using Amazon RDS, a manual DB cluster snapshot can be shared in the following ways:

• Whether the shared snapshot is encrypted, or unencrypted, authorized AWS accounts can copy the snapshot.
• Whether encrypted or unencrypted authorized AWS accounts can directly restore a DB cluster from the snapshot instead of taking a copy of it and restoring from that.

To share an automated DB cluster snapshot, create a manual DB cluster snapshot by copying the automated snapshot and then share that copy.

You can share a manual snapshot with up to 20 other AWS accounts.

An encrypted manual snapshot can be shared as public, it will be available to all AWS accounts.

DB cluster snapshot that have been encrypted “at rest” can be shared,

• The account this is shared with need to be given access (by sharing) the KMS encryption key used to encrypt the snapshot.

Amazon Aurora- Backtrack

Backtracking “rewinds” the DB cluster to the time specified.

Backtracking provides the following advantages over traditional backup and restore:

• You can easily undo mistakes, if you mistakenly perform a destructive action, you can backtrack the DB cluster to a time before the destructive action with minimal interruption of service.
• You can backtrack a DB cluster quickly
• Unlike restoring the DB cluster to a point in time, Back tracking a DB cluster doesn't require a new DB cluster and rewinds the DB cluster in minutes.
• It allows for exploring earlier data changes.

DB cluster can be backtracked back and forth in time to help determine when a particular data change occurred.

Amazon Aurora Server less- What it is

It is an on demand, auto scaling configuration for Amazon Aurora.

Aurora Serverless provides a relatively simple, cost effective operation for infrequent, or unpredictable workloads.

It can provide this because it automatically starts up, scales compute capacity to match your application’s usage and shuts down when its not in use.

A non-Server less DB cluster for Aurora is calls a provisioned DB cluster.

Aurora Server less clusters and provisioned clusters both have the same kind of high capacity, distributed and highly available storage volume.

You can connect to Aurora server less cluster using the TLS/SSL protocol.

Amazon Aurora Server less-How it works

With Aurora serverless, creating a database endpoint without specifying the DB instance class size can be done.

Set the minimum and maximum capacity in terms of Aurora Capacity Units

• Each ACU is a combination of processing and memory capacity

Database storage automatcally scales from 10 GiB TO 64 TiB

With Aurora Serverless, the database endpoint connects to a proxy fleet that routes the workload to a fleet of resources that are automatically scaled.

• Because of the proxy fleet, connections are continuous as Aurora Serverless scales the resources automatically based on the minimum and maximum capacity specifications.

Database client application dont need to change to use the proxy fleet.

• Aurora serverless manages the connections automatically.
• Scaling is rapid because it uses a pool of “warm” resources that are always ready to service requests.
• Storage and compute are seperate such that it cans cale down to zero compute processing and charge will be only for storage.
• Aurora serverless manages the warm pool of resources in an AWS Region to minimize scaling time.
• When new resources are added to the Aurora DB cluster, Aurora Serverless uses the proxy fleet to switch active client connection to the new resources.
• At any specific time, charges are only for the ACUs that are being used.
• It scales to zero capacity when there are no connections for a 5 minute period actively used in your Aurora DB cluster.

Amazon Aurora Serverless — Failover

Currently the DB isntance in an Aurora Serverless DB cluster is created in a single Availability Zone.

If either the DB instance or the AZ becomes unavailable, Aurora re-creates the DB instance in a different AZ.

• This referred to as automatic multi AZ failover.

This failover mechanism takes longer time than in an Aurora provisioned cluster

• The reason why the Aurora Serverless failover time is currently undefined is because it depends on demand and capacity availability in other AZs within the given AWS Region.

Amazon Aurora Serverless — Snapshots

You can create an Aurora Serverless cluster when restoring from snapshot of an Aurora provisioned DB cluster

You can take a snapshot of the Aurora Serverless DB cluster

The cluster volume for an Aurora Serverless cluster is always encrypted

• You can choose the encryption key, but not turn off encryption

To copy or share a snapshot of an Aurora Serverless cluster you encrypt the snapshot using your own KMS Key.

Thankyou,

Bharathi.