Content Domain 3: Cloud Technology and Services

Task Statement 3.4: Identify AWS database services

Let's get started with the fourth task statement covering AWS database services. I want to again mention fundamentals for this exam. You should understand what a database is and how it works. Let's start with Amazon RDS, which is a Database as a Service. Amazon RDS provides managed database instances. AWS handles the management, and you get access to a managed database instance that provides lots of benefits and performance enhancements. We do not have to manage the physical hardware, the operating system and more. RDS supports MySQL, MariaDB, PostgreSQL, Oracle, and Microsoft SQL Server and Amazon Aurora. You can pick which database engine works with your application requirements. And Amazon RDS databases comes in different types, sizes, and families, just like Amazon EC2 instances. RDS instances can be in one Availability Zone or in multiple Availability Zones. For an RDS instance, you allocate storage for that instance to use, so it is dedicated storage for that database instance. And access to and for your database instances are controlled through security groups. Amazon RDS instances in a single Availability Zone can be vulnerable to a failure in that single Availability Zone because the instance and the storage are in a single Availability Zone. But you can choose a multi-AZ configuration that will allocate secondary hardware in a different Availability Zone. This second database instance is called the standby replica instance. RDS uses synchronous replication from the primary and the standby instance. You can also configure an RDS read replica that provides two main benefits, performance benefits and availability benefits. A read replica is a read-only replica of your RDS database instance, and read replica are for read operations, and that data is replicated asynchronously. Synchronous replication is completed in multi-AZs, and the data is written to the primary instance and replicated to the standby read replica at that same time. On the exam, if you see asynchronous, think read replicas, and synchronous replication would be the choice for any question with a multi-AZ environment or scenario. Another relational database service is Amazon Aurora, but it does have quite a few differences and improvements over Amazon RDS. First, the Aurora architecture is very different from Amazon RDS. Amazon Aurora uses the base architecture of a cluster, and it is compatible with MySQL and PostgreSQL engines. It is a cluster made up of a single primary instance and then zero or more read replicas. This may seem the same as Amazon RDS, but Aurora read replicas can provide the benefits of reads and also the benefits of multi-AZ. They can be used to improve availability and read operations on your cluster. Second, Aurora storage is different from RDS because Aurora does not use the local storage for the compute. It actually uses a shared cluster volume, which provides faster provisioning, improved availability, and better performance. Aurora Serverless is a service of Aurora and provides a version of the Amazon Aurora database product where you do not have to provision or manage the database instances. Aurora Serverless works a bit differently architecturally too. Aurora Serverless provides the same shared cluster storage, so you get, again, six copies of your data across three Availability Zones. But you do not provision your cluster the same way. For Aurora Serverless, you use an ACUs, which is Aurora capacity units. The Aurora ACUs provides a certain amount of compute and a corresponding amount of memory. For an Aurora Serverless cluster, you can choose a minimum ACU and a maximum ACU, and then your Aurora Serverless cluster will scale between that minimum and maximum value and will add and remove the capacity in your cluster based on your load. A really cool feature of Aurora Serverless is that the ACU can even go down to zero and then can even be paused after a period of inactivity. This is a great cost savings because when your cluster is paused, you're only paying for the storage that you're using. Aurora global databases are a feature of Aurora provisioned clusters which allow data to be replicated globally, providing significant recovery point objective and recovery time objective improvements for business continuity and disaster recovery planning. Additionally, global databases can provide performance improvements for customers with that data being located closer to them and in a read-only form. Replication occurs at the storage layer and is generally less than 1 second between all AWS Regions. Let's move on and talk about the non-relational databases that AWS offers. Do you know which AWS service that is? Amazon DynamoDB is a NoSQL Database as a Service product, and it is a public service and sits in the AWS Public Zone. AWS manages DynamoDB for you. You do not need to manage any servers or infrastructure, and DynamoDB can handle simple key-value data or structure data. DynamoDB also supports scaling options using provisioned capacity with manual controls or use an on-demand mode which handles that scaling for you. DynamoDB is highly resilient across multiple Availability Zones in a Region, or you can configure a global table to add global resilience, but that will be an extra cost. Let's also cover in-memory-based databases. Up first is Amazon ElastiCache, which is a managed in-memory cache for performance improvements for reads. It supports two different popular caching engines, Redis and memcacheD. So if you see a question with memcacheD or Redis, your answer is probably ElastiCache. It is designed to store reads and deliver those results from in-memory caching and improves performance. So instead of consulting the database each time for reads, you can cache results and then deliver those results quicker. ElastiCache can also be used to store user session states. And we mentioned sessions in the first domain under scaling and high availability. But you can store the user's session states using ElastiCache, and it can be used as a performance-enhancing tool or used with fault-tolerant architectures. Let's also talk about Amazon DynamoDB Accelerator or DAX because ElastiCache can also be used with DynamoDB, but AWS created DAX to be used specifically with DynamoDB. Amazon DynamoDB is designed to be a low-maintenance and high-performing database that provides access to your data in milliseconds. But there are edge locations that need this data faster, like microseconds, and also for high-read sessions, and DAX provides an in-memory cache for DynamoDB. Here's a quick exam tip. DAX is designed for latency-sensitive and high-read workload. You may see a question asking what is the best caching product to use with DynamoDB? And the answer is DAX. DAX is not great for applications that need strongly consistent reads. DAX is more for eventually consistent reads. Before we move on and talk about database migration tools, let's also cover Amazon Redshift. Redshift is a petabyte-scale data warehousing solution from AWS. It is a column-based database engine for analytic workloads. Most RDS databases are used for OLTP, which is online transaction processing. But Redshift is designed for OLAP, which is online analytical processing, and it is not the type of database where you update individual records. Redshift is used for data warehousing analytics, and everything is stored in columns. And column-based databases are great at queries because all that data is in the columns. Row-based databases are great for transaction-type processing, and column-based databases are great for analytics. Redshift is based on PostgreSQL, but it is an online analytical processing. Redshift is not used for online transactional processing. Redshift uses a cluster architecture and unloads and uploads data to S3. It can also accept data from DynamoDB, the Database Migration Service and other databases, and Amazon Kinesis too. And to go along with Amazon S3, we can use Redshift Spectrum to perform queries directly against S3. Here's another exam tip with keywords. Know that Redshift is a data warehouse used for analytical and summarization transactions and can also scale to almost any workload needed, and it is a petabyte-scale database. For the exam, you should also know what AWS database migration tools are available to help you migrate your applications to AWS. AWS offers the AWS Snow Family of services to migrate large amounts of data in and out of AWS. The AWS Snowcone, Snowball, and Snowmobile are a collection of physical devices that help you migrate large amounts of data into and out of the cloud without depending on networks. This helps you apply the wide variety of AWS services for analytics, file systems, and archives to your data. Here is a question. Which AWS Snow Family service would you use to move terabytes to petabytes of data into AWS using appliances that have storage and compute capabilities? AWS Snowball Edge is a data migration and edge computing device that comes in two options, Snowball Edge Storage Optimized and Snowball Edge Compute Optimized. AWS Snowcone is only for 8 terabytes, and AWS Snowmobile is for petabytes to exabytes of data. Snowball Edge supports specific Amazon EC2 instance types as well as AWS Lambda functions, so customers may develop and test in AWS and then deploy applications on devices in remote locations to collect, pre-process, and return that data. Common use cases include data migration, data transport, image collation, IoT sensor stream capture, and machine learning. Another migration service is the AWS Database Migration Service, or DMS, which is a managed service capable of both data migration and schema conversion. Traditionally, a database migration is done by either a backup and restore. You have to stop all input and output operations on your database, take the backup and then do a restore, and then update your applications to the new database endpoint. And this will require a full outage during your migration. You can use replication and configure the replication instance between the source and target database. Then allow replication to replicate all existing data, and then migrate any new transactions too. And this usually has very little downtime. You simply update the application to point to the new endpoint. But this replication process is very admin intensive, and it is difficult to set up right. So AWS offers DMS that handles this overhead and configuration for you. You create a replication instance and define a source endpoint and a target endpoint with any authentication that may be required. And all that data is migrated from the source to the target, and operations continue on that source database until you decide to migrate it all to the target. AWS also provides the AWS Schema Conversion Tool to help transform between different database engines for your migration. DMS is great for scaling your resources up or down with little downtime, or migrating databases from on premises or from AWS to on premises, and also other cloud platforms. And the Schema Conversion Tool allows us to move data between different database engines. Before we wrap up, let's also talk about AWS DataSync. AWS DataSync makes it simple and fast to move large amounts of data online between on-premises storage and Amazon S3, Amazon EFS, or Amazon FSx for Windows File Server. Manual tasks related to data transfers can slow down migrations and burden your IT operations. DataSync automatically handles many of these tasks, including scripting copy jobs, scheduling and monitoring transfers, validating data and optimizing network utilization, and can transfer hundreds of terabytes and millions of files at speeds up to 10 times faster than open-source tools, over the internet, or AWS Direct Connect links. You can use DataSync to migrate active datasets or archives to AWS, transfer data to the cloud for timely analysis and processing, or replicate data to AWS for business continuity. With the database services, a major area of focus will be being able to differentiate between which services fit specific scenarios. This involves both comparing services like Amazon RDS, Amazon DynamoDB, and Amazon Redshift to each other, as well as comparing them to managing your own database on EC2 instances. Here are some questions to consider. What advantages do you get from utilizing the managed service? How does the managed services differ from that of a database engine installed on an instance when it comes to customability, management, and performance? What are the limitations of each style of database? Understand how these services will fit into your own builds, or hypothetical builds, and what role each could play. There is no one-size-fits-all solution. The managed services within AWS are varied, so when considering them, it is important to look at not only the variety of managed services that exist, but also at the varying levels of management they provide. In the same way that Amazon DynamoDB and Amazon RDS vary in how they are managed, it is also different when looking at Amazon EKS, AWS Fargate, and so many others. Evaluate where the benefits lie, how you can use them in conjunction with each other in an architecture, what they complement or replace, and how topics like availability, failover, and data consistency come into play. The features and customization options of each database service will be very useful in matching your requirements in different scenarios and use cases. Let's get started with the fifth task statement and talk all about AWS network services.