Introduction & HA Overview
Aurora Single Master
Aurora Multi Master
The course is part of these learning paths
Interested in learning about Amazon Aurora?
Amazon Aurora is a next generation cloud native relational database, providing unrivalled performance and availability features!!
This course explores the various configuration options and techniques that you can use to create highly available Amazon Aurora databases. It starts off by looking at the high availability options available within Amazon Aurora, before diving deeper into more specific features, such as single and multi master setups, read replicas, and how Aurora can be provisioned serverless. Each new topic is accompanied by a real-world demonstration to help you better understand the concepts presented within the course.
For any feedback or questions relating to this course, please contact us as firstname.lastname@example.org.
- Understand how to provision and configure Amazon Aurora in a manner that ensures it is highly available and able to serve all read and write requests.
This course is intended for those responsible for architecting Aurora database setups, with an emphasis on high availability.
To get the most from this course, you should be familiar with basic SQL database concepts. If required, consider taking our "Database Fundamentals for AWS" course first.
The following GitHub repository is referenced within this course:
Aurora Serverless is an elastic solution that autoscales the compute layer based on application demand, and only bills you when it's in use. Aurora Serverless ideally suited towards applications which exhibit variable workloads and/or have infrequent data accessing and modification needs.
When provisioning an Aurora Serverless database - you no longer need to plan and allocate instance sizes. Instead, you simply configure lower and upper limits for capacity. Capacity is measured in ACUs - which stands for Aurora Capacity Units. You have the ability to set upper and lower limits for capacity.
Aurora will continually adjust and optimize capacity based on incoming demand - and will stay within the limits specified.
The underlying compute instances are automatically started and stopped based on current demand. Instances can be cold booted in a matter of seconds.
In terms of high availability - the service is underpinned by the same fault-tolerant, self-healing storage layer. There is nothing to configure beyond the capacity settings which if required can be manually tuned.
The service will auto adjust the compute layer and capacity automatically behind the scenes to ensure that the database is available and has the necessary capacity when required. If the traffic starts to drop off it will begin scaling down, and if enabled, actually shut down the compute entirely when there's no demand for it. When the compute is turned off, you only end up paying for the storage capacity used.
Since Aurora Serverless by design takes care of automatically scaling out to meet peak demand, there is no option nor need to add in read replicas.
An Aurora Serverless database is configured with a single connection endpoint which makes sense - given that it is designed to be serverless - this endpoint is obviously used for both read and writes.
Another interesting option when considering how to connect and execute queries against an Aurora Serverless database is the Web Service Data API feature - available only on Aurora Serverless databases. This opt in feature enables an HTTP web service interface into the database meaning you can execute and run queries against the database without the need for a JDBC driver nor connection - hence why this feature is often termed connectionless. The Web Service Data API makes implementing Lambda functions which need to perform data lookups and or mutations within an Aurora serverless database a breeze. Another benefit when using this feature is that the AWS CLI has been updated to allow you to execute queries through it from the command line.
Aurora Serverless performs a continuous automatic backup of the database with a default retention period of 1 day - which can be manually increased to a maximum retention period of 35 days. This style of backup gives you the capability of restoring to a point in time within the currently configured backup retention period. Restores are performed to a new serverless database cluster.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, GCP, Azure), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, GCP, and Kubernetes (CKA, CKAD, CKS).