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 can be configured with a single read/write master instance - and multiple read replicas. A single master instance can be configured with up to 15 read replicas when using Aurora. Replication of data is performed asynchronously in milliseconds - fast enough to give the impression that replication is happening synchronously.
Read Replicas share the same underlying storage layer connected to the master.
Read replicas can be deployed in different availability zones within the same VPC or if required can be launched as cross region replicas. Read replicas allow you increase the overall read throughput while also offloading database reads from the master instance - allowing the master to focus on serving writes. In the event of the master instance going down, any one of the read replicas can be promoted to take over the role of being master.
Each read replica can be tagged with a label indicating priority in terms of which one gets promoted to the role of master in the event of the master going down. The master can be rebooted in 60 or less seconds.
This type of cluster supports being stopped and started manually in its entirety - that is when you stop and start a cluster, all underlying compute instances are either stopped or started. When stopped the cluster remains stopped for up to 7 days, after which it will automatically restart itself.
Daily backups are automatically performed with a default retention period of 1 day and for which can be adjusted up to a maximum retention period of 35 days. You have the capability of specifying a window of time in which backups are automatically taken. Additionally, on-demand manual snapshots can be performed on the database at any time. Manual snapshots are stored indefinitely until you explicitly choose to delete them. Restores are performed into a new database.
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.