AWS NoSQL databases
AWS Relational Databases
*** PLEASE NOTE *** This course has been replaced with two new courses: Database Fundamentals for AWS - Part 1 of 2 and Database Fundamentals - Part 2 of 2.
This course will provide you with an introduction to the cloud database services offered by AWS. In this course, we will first explore the fundamentals of cloud databases, outline the cloud databases provided by AWS before exploring how to get started selecting and using the AWS Database Services.
This course suits anyone interested in learning more about the database services offered by AWS.
The course is an introductory level course so there are no specific database skills or experiences required as a pre-requisite. Having a basic understanding of cloud computing will help you gain the most from this course. I recommend completing “What is cloud computing?” first if you are new to cloud computing.
On completing this course you will have an understanding of the different types of database services available to you within the AWS cloud platform. You will be able to recognize and explain the various database services offered by AWS, and be able to identify and select which database service might suit a specific use case or requirement.
First, we learn to recognize and explain the basics of a cloud database service.
We then learn to recognize and explain the differences between non-relational and relational databases before taking a high-level pass over the family of AWS database services available.
We then dive in the Non Relational Databases - Amazon DynamoDB - Amazon Elasticache - and Amazon Neptune exploring use cases for when we might want to use a non-relational database service.
Next, we dive into amazon RDS - the AWS Relational Database Service, exploring the database services provided by RDS. We then examine the services and their various use cases in the context of a scenario.
The Basics - What is a Cloud Database?
Overview of the AWS Database Services
AWS Non Relational Databases
- Amazon DynamoDB
- Amazon Elasticache
- Amazon Neptune
AWS Relational Database Service
- The RDS Service
- MySQL for RDS
- Microsoft SQL Server for RDS
- Oracle for RDS
- MariaDB for RDS
- PostGresSQL for RDS
- Amazon Aurora for RDS
If you have thoughts or suggestions for this course, please contact Cloud Academy at email@example.com.
22-01-2020: Added note about Amazon Elasticache being used as a cache in front of Amazon RDS services
For additional training on the topics covered in this course, please take a look at the following Cloud Academy content:
Congratulations, that brings us to the conclusion of our database fundamentals course. So let's quickly review the things that we covered so they're fresh in our minds. So you remember we looked first at DynamoDB, a perfect candidate if you need a simple, fast, and scalable document or key store. If you want a non-relational NoSQL database, DynamoDB should be a first point of choice. It's schema free and it's a service that can be run locally as well as in cloud infrastructure. Next we looked at Amazon ElastiCache which is a perfect solution if you need to implement a cache or within scalable infrastructure. Amazon ElastiCache is a service that can help you reduce read load on your persistent data store by acting as a cache between either your application, your front-end or your database.
The Redis engine provides a lot of functionality. The Memcached service provides a simple cache service that's easy to set up and manage. Remember, it's not designed as a persistent data store. Amazon Neptune is a great way to manage complex graphs and charts. And if you need a purpose-built graph database engine, Amazon Neptune is a perfect solution. Again, it's not designed as an object store or an RDBMS system. It does provide ASIB compliance and provides immediate consistency if you need it. It does allow you to encrypt your data at rest and in transit. Then we looked at our relational databases and remember they are provided within the RDS service which is the Amazon Relational Database service. First we looked at MySQL and it's a great, simple, commonly used relational database engine. You often find it very easy to find developers who can work on it because MySQL is a very popular database and it certainly is a good choice if you're looking at starting a cloud-based project or you're migrating off an existing infrastructure. So it's not ideal if you have a lot of stored proprietary functions or procedures. So it's not as rich as some of the other RDBMS services. Then we looked at Microsoft SQL Server running on RDS. And as a corporate standard, it provides an excellent use case, being able to start a version of Microsoft SQL Server or a pay-per-use model. It's a powerful database engine and it provides you with a variety of licensing options and configurations within the RDS service. It's certainly not ideal if you need to store a variety of different data types. So if we're looking at storing a lot of images and videos, then we're probably better off looking at the non-relational DynamoDB service for that.
If you don't need a lot of transactional power, then Microsoft SQL Server may not be a good match. It does have an in-built graph engine. And of course the benefit is that we can change or scale our machine size or metrics up and down very easily in RDS so we can make the machine way more powerful, add more memory, do vertical scaling on demand or the click of a button. Those changes generally are applied during a maintenance window with Microsoft SQL Server. MariaDB we looked at which is a fantastic non-proprietary database platform. And if you need to support master master or master slave replications then MariaDB does that. Probably it hasn't quite the same advanced features as are supported by MySQL Amazon Aurora for example. However, it does provide a very good option for starting a new database project and it has very good ingrained roles and flexibility around roles. If you're running Oracle in RDS, this is a fantastic opportunity to use the power of an integrated Oracle database or the pay-per-use model.
So if you're bringing your own license even better, but if you just need to stand up Oracle to run a project or a pilot where you're looking at increasing your availability or reliability in your infrastructure, this is a fantastic way of using such a powerful tool on a pay-per-use model. It puts a lot of different interactions so SAP, JD Edwards for example. You really need to ask yourself if you need the power of the Oracle database. Even though it's a pay-per-use model so it's gonna be cheaper, do you actually need all of that processing power? It certainly suits situations where you have a lot of transactional information to process. You have complex joins. And if you have proprietary code written in PL/SQL or you have any functions that need to be ported or maintained across a variety of machines, then Oracle and RDS is a great solution. Then we looked at PostgreSQL for RDS and PostgreSQL is a cheap, open source, and powerful database that can meet most compliance requirements so it suits a lot of use cases certainly around PHI and HIPAA Compliance. And it certainly is a great solution if you want to get off of proprietary database platform into an open source platform so that you have more flexibility and perhaps less cost. It's only real limitations is that it doesn't currently support in-memory processing which most of the other RDBMS services do, but not that that's in any way a limitation to what you can do with PostgreSQL. It's a fantastic relational database. Okay, then we looked at Amazon Aurora which of course is a cloud native build of MySQL, done by Amazon so it runs extremely efficiently in the Amazon infrastructure. It's got the very fastest possible failover that I think you can get from any relational database. It's durable, effective. We are using a cluster service for the actual data storage component. It makes it very, very reliable.
It supports more programming languages than any other database that I can see. And they're underlying storage by replication is done by default which just gives you a very, very stable platform to build on. The only times you might not want to look at Amazon Aurora would be if you are running a multi-cloud strategy and perhaps you do want to be less bound to the proprietor's infrastructure as possible, then maybe Amazon Aurora wouldn't be such a good match. But for the performance and the cost, it's just the best thing out there in my view. Okay, well done for completing the course. And if you are interested in reading more about any of the processing engines, then we have more detailed courses and labs and I'll put those labs in the notes for this course. Okay, all right, if you have any questions or you have any feedback, please send it to firstname.lastname@example.org. Thanks for your attention.
For more information on the database services covered in this course, please see the following:
About the Author
Head of Content
Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe. His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.