Amazon Aurora: Amazons New

Relational Database Engine

Manish Dalwadi, Senior Product Manager
Anurag Gupta, Vice President

2015, Amazon Web Services, Inc. or its affiliates. All rights reserved

Current DB architectures are monolithic

SQL

Transactions
Caching
Logging

Multiple layers of
functionality all on a
single box

Current DB architectures are monolithic

Application

SQL

SQL

Transactions

Transactions

Caching

Caching

Logging

Logging

Even when you scale

it out, youre still
replicating the same
stack

Current DB architectures are monolithic

Application

SQL

SQL

Transactions

Transactions

Caching

Caching

Logging

Logging

Even when you scale

it out, youre still
replicating the same
stack

Current DB architectures are monolithic

Application

SQL

SQL

Transactions

Transactions

Caching

Caching

Logging

Logging

Storage

Even when you scale

it out, youre still
replicating the same
stack

This is a problem.
For cost. For flexibility. And for availability.

Reimagining the relational database

What if you were inventing the database today?

You wouldnt design it the way we did in 1970. At least not entirely.

Youd build something that can scale out, that is self-healing, and that
leverages existing AWS services.

Relational databases reimagined for the cloud

Speed and availability of high-end commercial databases

Simplicity and cost-effectiveness of open source databases

Drop-in compatibility with MySQL

Simple pay as you go pricing

Delivered as a managed service

A service-oriented architecture applied to the database

Data Plane

Moved the logging and storage layer

into a multi-tenant, scale-out
database-optimized storage service
Integrated with other AWS services
like Amazon EC2, Amazon VPC,
Amazon DynamoDB, Amazon SWF,
and Amazon Route 53 for control
plane operations

Control Plane

SQL
Transactions
Caching

Amazon
DynamoDB

Logging + Storage

Amazon SWF

Integrated with Amazon S3 for

continuous backup with
99.999999999% durability
Amazon S3

Amazon Route 53

Aurora preview

Sign up for preview access at:

https://aws.amazon.com/rds/aurora/preview

Now available in US West (Oregon) and EU (Ireland), in addition to US

East (N. Virginia)

Thousands of customers already invited to the limited preview

Now moving to unlimited preview; accepting all requests in 23 weeks

Full service launch in the coming months

Enterprise grade, open source pricing

vCPU

Mem

Hourly Price

db.r3.large

15.25

$0.29

db.r3.xlarge

30.5

$0.58

db.r3.2xlarge

61

$1.16

db.r3.4xlarge

16

122

$2.32

db.r3.8xlarge

32

244

$4.64

Storage consumed, up to 64 TB, is $0.10/GB-month

IOs consumed are billed at $0.20 per million I/O
Prices are for Virginia

Simple pricing

No licenses
No lock-in
Pay only for what you use

Discounts

44% with a 1-year RI

63% with a 3-year RI

Aurora Works with Your Existing Apps

Establishing our ecosystem

It is great to see Amazon Aurora remains MySQL compatible; MariaDB

connectors

work with Aurora seamlessly. Today, customers can take MariaDB Enterprise with
MariaDB MaxScale drivers and connect to Aurora, MariaDB, or MySQL without worrying about
compatibility. We look forward to working with the Aurora team in the future to further
accelerate innovation within the MySQL ecosystem. Roger Levy, VP Products, MariaDB

Business Intelligence

Data Integration

Query and Monitoring

SI and Consulting

Amazon Aurora Is Easy to Use

Simplify database management

Create a database in minutes

Automated patching

Push-button scale compute

Continuous backups to S3

Automatic failure detection and failover

Amazon RDS

Simplify storage management

Read replicas are available as failover targetsno data loss

Instantly create user snapshotsno performance impact

Continuous, incremental backups to S3

Automatic storage scaling up to 64 TBno performance or availability

impact

Automatic restriping, mirror repair, hot spot management, encryption

Simplify data security

Encryption to secure data at rest

AES-256; hardware accelerated

All blocks on disk and in Amazon S3 are encrypted
Key management via AWS KMS

Application

SQL
Transactions

SSL to secure data in transit

Caching

Network isolation via Amazon VPC by default

No direct access to nodes

Supports industry standard security and data protection

certifications

Storage

Amazon S3

Amazon Aurora Is Highly Available

Aurora storage

Highly available by default

6-way replication across 3 AZs

4 of 6 write quorum

AZ 1

AZ 2

Automatic fallback to
3 of 4 if an AZ is unavailable

3 of 6 read quorum

SQL
Transactions

SSD, scale-out, multi-tenant storage

Seamless storage scalability

Up to 64 TB database size
Only pay for what you use

Caching

Log-structured storage

Many small segments, each with

their own redo logs
Log pages used to generate data pages
Eliminates chatter between database and storage

Amazon S3

AZ 3

Consistent, low-latency writes

MySQL with standby
AZ 1
Primary
Instance

Amazon Aurora

AZ 2

AZ 1

AZ 2

Standby
Instance

Primary
Instance

Replica
Instance
async
4/6 quorum

PiTR

Amazon Elastic
Block Store (EBS)

EBS
Sequential
write

Sequential
write

EBS

EBS

mirror

mirror

Amazon S3

Improvements

Distributed
writes

Amazon S3

Type of writes

Consistencytolerance to outliers
Log records

Latency synchronous vs. asynchronous replication

Binlog
Data

Significantly more efficient use of network I/O

Double-write buffer
FRM files, metadata

AZ 3

Self-healing, fault-tolerant

Lose two copies or an AZ failure without read or write availability impact

Lose three copies without read availability impact

Automatic detection, replication, and repair

AZ 1

AZ 2

AZ 3

AZ 1

SQL

SQL

Transaction

Transaction

Caching

Caching

Read availability

AZ 2

AZ 3

Read and write availability

Instant crash recovery

Traditional databases

Amazon Aurora

Have to replay logs since the last

checkpoint

Underlying storage replays redo

records on demand as part of a
disk read

Single-threaded in MySQL;
requires a large number of disk
accesses
Crash at T requires

Parallel, distributed, asynchronous

a re-application of the
SQL in the redo log since
last checkpoint

Checkpointed Data

Crash at T0 will result in redo

logs being applied to each segment
on demand, in parallel, asynchronously

Redo Log
T0

T0

Survivable caches

We moved the cache out of

the database process
Cache remains warm in the
event of a database restart

Lets you resume fully loaded

operations much faster

Instant crash recovery +

survivable cache = quick and
easy recovery from DB failures

Caching process is outside the DB process

and remains warm across a database restart

SQL

SQL

SQL

Transactions

Transactions

Transactions

Caching

Caching

Caching

Multiple failover targetsno data loss

MySQL Replica

Aurora Master

70% Write

70% Write

30% Read

30% New Reads

30% Read

Data Volume

Data Volume

MySQL Master
70% Write

Single-threaded
binlog apply

MySQL read scaling

Replicas must replay logs
Replicas place additional load on master
Replica lag can grow indefinitely
Failover results in data loss

Page cache
invalidation

Aurora Replica
100% New
Reads

Shared Multi-AZ Storage

Simulate failures using SQL

To cause the failure of a component at the database node:

ALTER SYSTEM CRASH [{INSTANCE | DISPATCHER | NODE}]

To simulate the failure of disks:

ALTER SYSTEM SIMULATE percent_failure DISK failure_type IN
[DISK index | NODE index] FOR INTERVAL interval

To simulate the failure of networking:

ALTER SYSTEM SIMULATE percent_failure NETWORK failure_type
[TO {ALL | read_replica | availability_zone}] FOR INTERVAL interval

Amazon Aurora Is Fast

Write performance (console screenshot)

MySQL Sysbench

R3.8XL with 32 cores

and 244 GB RAM

4 client machines with

1,000 threads each

Read performance (console screenshot)

MySQL Sysbench

R3.8XL with 32 cores

and 244 GB RAM

Single client with

1,000 threads

Read replica lag (console screenshot)

Aurora Replica with 7.27 ms replica lag at 13.8 K updates/second

MySQL 5.6 on the same hardware has ~2 s lag at 2 K updates/second

Writes scale with table count

Tables

Amazon
Aurora

MySQL
I2.8XL
Local SSD

MySQL
I2.8XL
RAM Disk

RDS MySQL
30K IOPS
(Single AZ)

10

60,000

18,000

22,000

25,000

100

66,000

19,000

24,000

23,000

1,000

64,000

7,000

18,000

8,000

10,000

54,000

4,000

8,000

5,000

Thousands of Writes per Second

Write Performance and Table Count

70
60
50
40
30
20
10
10

Write-only workload
1,000 connections
Query cache (default on for Amazon Aurora, off for MySQL)

100
1,000
Number of Tables

Aurora

MySQL on I2.8XL
MySQL on I2.8XL with RAM Disk
RDS MySQL with 30,000 IOPS (Single AZ)

10,000

Better concurrency
Write Performance and Concurrency
120

50

Amazon
Aurora

40,000

RDS MySQL
30K IOPS
(Single AZ)

10,000

500

71,000

21,000

5,000

110,000

13,000

100

Thousands of Writes per Second

Connections

80

60

40

20

OLTP Workload
Variable connection count
250 tables
Query cache (default on for Amazon Aurora, off for MySQL)

50

Aurora

500
Concurrent Connections

5,000

RDS MySQL with 30,000 IOPS (Single AZ)

Caching improves performance

Performance with query cache on and off

Amazon
Aurora
With
Caching

RDS MySQL
30K IOPS
Without
Caching

RDS MySQL
30K IOPS
With
Caching

100/0

160,000

375,000

35,000

19,000

50/50

130,000

93,000

24,000

20,000

0/100

64,000

64,000

16,000

16,000

400

Thousands of Operations/Second

R/W Ratio

Amazon
Aurora
Without
Caching

350
300

250
200
150
100
50
100/0

OLTP workload
1,000 connections
250 tables
Query cache on/off tested

50/50
Read/Write Ratio

Aurora without Caching

Aurora with Caching
RDS MySQL;30,000 IOPS (Single AZ) - without caching
RDS MySQL;30,000 IOPS (Single AZ) - with caching

0/100

Replicas have up to 400 times less lag

Updates/
Second

Amazon
Aurora

RDS MySQL
30K IOPS
(Single AZ)

1,000

2.62 ms

0s

2,000

3.42 ms

1s

5,000

3.94 ms

60 s

10,000

5.38 ms

300 s

Read Replica Lag in Milliseconds

Read Replica Lag

350,000
300,000
250,000
200,000
150,000
100,000
50,000
2.6

Write workload
250 tables
Query cache on for Amazon Aurora, off for MySQL (best settings)

3.4

5.4

3.9

0
1,000

2,000

5,000

10,000

Updates per Second

Aurora

RDS MySQL;30,000 IOPS (Single AZ)

SAN FRANCISCO