AWS Aurora–RDS

Prior to Aurora, Amazon was offering the databases of other vendors (Microsoft, Oracle…) as part of their Database as a Service – RDS.   These database engines , though cloud-friendly, were not designed to take advantage of elastic cloud constructs in a native manner. 

Part of the issue with RDS in the past was the single tenant architecture – it was difficult to stack databases or database instances onto a single RDS instance. This meant that even if you had two really small SQL Server databases – that could easily co-exist on a single SQL Server instance, RDS was not designed to co-host those two on a single tenant.  Aurora claims to be built on a service-oriented and multi-tenant architecture, offering performance and availability comparable to leading databases – but at a fraction of the price (open source model pricing).  

At some point, Amazon decided to develop it’s own commercial-grade database engine. This was named Aurora.

Aurora – Processing Power and Such

• Processing Power – Scalable up to 32 virtual CPUs (vCPUs) and 244 GB RAM.
• Read/Write Capabilities – Reads  – 30 million / minute ; Writes – 6 million / minute
• Storage Scalability – Storage Layers built to leverage cloud storage and network resources.
• Storage Speed – SSD based virtualized storage layer designed for DB workloads.
• Software resources designed to avoid common DB Table locking and I/O waits

Pricing

For the actual DB engine license, there isn’t any separate pricing. All costs are bundled into the instance hosting – which is essentially, on demand, db instances.

On-Demand Instances let you pay for your database by the hour with no long-term commitments or upfront fees.

Fault Tolerance in Aurora

Fault Tolerance Built In – Data is spread out across multiple AZs (Availability Zones) – this lets you distribute read operations across multiple instances.  Amazon lets customers add up to 15 replicas to their databases in order to achieve higher levels of availability.  Aurora uses the RDS Multi-AZ service to manage the replication operations and to automatically failover a databases should the primary instance go down, regardless of the zone where the database resides.

Security in Aurora

   For security purposes, each database runs in an Amazon Virtual Private Cloud (VPC), which RDS automatically creates when the database is first configured. The VPC isolates the database in a virtual network that users can connect to via their organization’s encrypted IPsec virtual private networks (VPNs). Amazon can also encrypt data both in-transit and at-rest, which includes data written to the Aurora storage as well as Amazon A3 backups. Aurora is also integrated with the ASW Identity and Access Management service for controlling access to Aurora resources and data.

Database Workloads

Each Aurora database is tightly integrated with an SSD-based virtualized storage layer designed specifically for database workloads. The storage is fault-tolerant and self-healing. The service automatically repairs disk failures, all in the background, without disrupting database availability. When subscribers first provision their Aurora databases, they start with only 10 GB of storage. Aurora then automatically scales up storage in 10-GB increments on an as-needed basis, up to 64 TB (or to the defined maximum, if less than 64 TB).

Aurora divides data into 10-GB segments stored on multiple disks and replicates each segment across three Availability Zones (AZs), with two copies in each zone. With this system, Aurora can handle the loss of up to two copies of data without impacting database write capabilities and up to three copies without impacting read capabilities. The service continuously scans the disks for errors and replaces the disks automatically if any are found.

Amazon also automatically backs up the data in a way that does not impact performance.

Maintenance using the AWS Dashboard (Management Console)

1. Most operations can be achieved with a few clicks in the AWS Management Console.
2. Amazon also plans to add management support via new APIs, the AWS Command Line Interface, and AWS CloudFormation templates.
3. In theory, users should be able to get an Aurora instance up and running within minutes.  From there, they can manage the instance through the console and view over 20 operational metrics about compute, memory, and storage resources as well as details about the active connections, query throughput, and cache hit ratio.

Where Can I  Learn More ?

http://www.anuj.com/scientific-consulting/reusable-application-framework