AWS DevOps Pro Certification Blog Post Series: Databases

This is part of the blog post series: AWS DevOps Pro Certification

Caveat emptor

Using AWS costs money, some of these services may not be part of the AWS Free Tier. You can keep costs down by tearing down anything you've created whilst learning, but it's still possible to run up a hefty bill so pay attention to the instances you setup!

I'm very lucky to be able to use my employer's AWS account. You should ask your place of work if a similar arrangement can be made as part of your study.

Velocius quam asparagi conquantur

The format of the blog posts is liable to change as I try to refine my mental model of each domain, so be sure to revisit the blog posts on a regular basis.


Amazon RDS is a managed service for Relational Database engines Service (RDS). AWS supports the following engines:

Amazon DynamoDB is a proprietary NoSQL database service offered by Amazon.


Managed services for database engines like all managed service remove key concerns:

These concerns often affect the ability to provide a database server that is fault-tolerant, highly available and has a contingency for disaster recovery.

N.B. there's a caveat around storage scaling that it won't be applicable to SQL Server instances. The details can be found in the SQL Server FAQs: Why can’t I scale my storage?.

To understand the difference between Amazon RDS and Amazon DynamoDB, I've provided the following examples:

Relational database engines (sometimes referred to as RDBMS) are tabular in natural, you can think of it visually as a spreadsheet with fields as the column headers and the rows being a single record of data. The term "relational" comes from the ability to link tables through a foreign key, an example of this might be a list of developers and their favourite foods. The link would be a column in the developers table called food_id, which would reference the column called id in the food table.

developer(s) table


food(s) table


If you were to delete nuts (id: 2) from the food table you would trigger an error warning there were dependencies in the developer table.

The key takeaway from this example is to remember Relational Databases store records tabularly in rows.

NoSQL database engines are a bit of a catch-all, but in essence, if you don't store your data tabularly you're probably a NoSQL database engine. Amazon DynamoDB is a Key/Value pair and Document store. Key/Value store allows you to store data like a Hash (associative array/dictionary), you provide a key and the value is returned, you may have used one without knowing as they're often referred to as cache servers i.e. Redis. Document stores allow you to data in a structured way common formats are XML and JSON, often these are the database engines most people associate with NoSQL i.e. CouchDB and MongoDB.


Amazon Aurora provides a compatible engine that is 3x faster than PostgreSQL and 5x faster than MySQL. In terms of cost-effectiveness, you need to compare the other RDS engines as a multi-AZ deployment and memory optimised instances.

Things that set it apart from the other RDS offerings in terms of this domain are:

Amazon RDS can be part of your disaster recovery strategy by keeping replicas of your production Oracle or SQL Server database servers.

Amazon DynamoDB requires a lot more consideration to make use of its features that make it relevant to this domain. Choosing the wrong scheme for partition keys can see your database starved of I/O.

Things to consider:

Further reading:


Amazon Aurora requires you to choose your engine compatibility i.e. MySQL or PostgreSQL after which you define:

The AWS CLI features a cli walkthrough of how to provision a table, store an item, perform a query. It should be noted that as a rule of thumb you would probably use the [AWS SDK][aws_sdk] to store and retrieve data from DynamoDB.

API and CLI features and verbs

Amazon RDS


Verbs (CRUD)


Not my best work will see if I can optimise this list.

Amazon DynamoDB


Verbs (CRUD)


AWS DevOps Pro Certification Blog Post Series