In this demo, we'll first create an Amazon RDS MySQL database, set it up as a multi-AZ DB cluster for better availability, and then connect to it using AWS Cloud Shell.
Head over to the RDS console to start creating your new database. We will see two options, standard create and easy create. Standard create gives full control. Easy create automatically selects recommended settings. Let's stick with standard create to explore all available configuration options.
Next up, engines options. Remember, a database engine is the software that manages and manipulates data within the database. It determines how it stores, retrieves, and processes data. Let's go with MySQL, which is a widely adopted database engine with strong community support.
Now when it comes to the engine version for MySQL, the available versions are listed here. Let's go over the versions that support the multi-AZ DB cluster and Amazon RDS optimized rights, which boost write throughput by up to two times and are suited for high-speed data writing workloads.
We'll now choose a template based on my use case. The available options are production, dev/test, and free tier. Let's go with the dev test template so we can set up a simple database for learning and experimentation.

Now let's look at availability and durability. In this section, we will choose the deployment options based on our requirements for availability and performance. The multi-AZ DB cluster deployment creates a primary instance with two standby instances in different availability zones. This deployment ensures high availability by automatically switching to a standby if the primary fails. It also provides 99.5% uptime in previous read capacity, reduces write latency, and provides separate endpoints for reading and writing data to optimize performance.
The single AZ-DB instance deployment uses just one instance for both read and write operations, so it's a simpler setup but without the redundancy or performance improvements of a multi-AZ configuration. And the single AZ DB instance provides one endpoint for both read and write operations, making it the most basic and cost-effective option.
We'll go over the multi-AZ DB cluster deployment configuration for high availability and better performance. Here we can enter a unique name for a database or keep the default. The credentials section allows us to set the master username and manage database credentials for secure access to the RDS instance. For the master username, we'll keep the default value admin which we'll use later to connect to the database.
Now in credentials management you have two options, managed in AWS secrets manager where AWS will generate and securely manage your password, rotating and storing it for you. This is the most secure option, all self-managed, where you can create your own password or let RDS generate it for you, but you'll need to handle its life cycle yourself.
For the encryption key, we can use the default AWS secrets manager key or create your own. When using the default key, AWS handles key rotation and access control. Let's stick with the default settings.
So, the DB instance class section is where we can select the instance type based on our workload requirements. Standard classes offer a balanced choice for most use cases. It offers a mix of compute, memory and networking resources. Memory optimized classes are ideal for workloads that require more memory relative to CPU, such as applications with large data sets, and burstable classes are best for development and testing environments where the database has variable workloads that don't require constant high performance. Again, we can also choose to show instance classes that support Amazon RDS optimized rights.
Now let's talk about storage. Here we have several options.
GP3 is a cost-effective option that supports a broad range of database workloads, while IO1 and IO2 is ideal for high demand workloads and offers very fast and consistent performance. Let's go with GP3 for its performance and flexibility at a cost-effective price. For allocated storage, we can choose how much storage we want for our database.
Next, you will see the provisioned IOPS and Storage throughput options. Let me quickly explain what they are. Provisioned IOPS refers to the number of read/write operations your database can perform per second, while storage throughput is the speed at which data is read from or written to the storage. These options are unavailable when using GP3 because GP3 provides these features automatically.
In additional storage configuration, we normally could enable Storage Alter scaling, which automatically increases storage when it reaches a threshold. However, this option is unavailable in a multi-AZ DB cluster setup because storage scaling is manually managed across multiple availability zones.
Now in the connectivity section, we can configure how the database connects to other resources. We can choose to set up a connection to an EC2 instance, which is useful. The database needs to work with an application on EC2 within the same network. If we choose not to, we can also manually configure the connection later.
Next, we can choose the VPC that defines the virtual network for a database. The default VPC comes with preconfigured settings, including subnets and availability zones. However, if we use a custom VPC, we can achieve better isolation and granular security controls by defining specific network settings like IP ranges, subnets and routing. Also, after our database is created, we can't change its VPC.
When it comes to subnets, we can choose a subnet group that defines which subnets and IP ranges our database can use within the selected VPC. For most setups we can use the default VPC subnet group which is pre-configured with subnets across multiple availability zones for high availability.
For public access, we can choose wherever external resources can connect to a database. If we select yes, RDS assigns a public IP allowing external resources like our local machine and resources inside the VPC to connect. If we select no, RDS does not assign a public IP, restricting access to resources within the VPC.
Let's go with enabling public access so we can connect to the database from outside the VPC, such as from a local machine. Now for VPC security groups, we can choose one or more security groups, define which resources can access our database. By default, the default security group is selected, which allows basic access within the VPC. This means any resource within the same VPC can connect to the database without additional configuration.
In the Database port section, we specify the port for database connections. For MySQL,l the default is 3306. If a different port is used, you must update your applications connection string, which is the text your application uses to connect to the database and includes the database's host name for username and password.
Next, we can choose the authentication method for our database. Password authentication is the most common and straightforward method for managing user access. For added security, we can also use password and IAM authentication, which allows us to manage access through AWS IAM users and roles.

Now let's look at the monitoring tools for the database. Database insights comes in two modes. Advanced mode offers fleet level monitoring, allowing us to track performance across multiple databases. It retains 15 to 24 months of performance history and includes additional features like integration with Cloud Watch application signals.
Standard mode also provides fleet level monitoring but only retains seven days of performance history and laxed advanced features. However, performance insights is still enabled, which helps visualize database load.
Here is a default KMS key used for encrypting our database. This key protects the encryption keys that secure our database volume. Now, let's enable enhanced monitoring which provides more detailed operating system level metrics like CPU usage by different processes or threads with updates every 60 seconds. We can also export logs to Cloud Watch logs so we can monitor important database activities in real time.
Finally, let's take a look at backups. Enable automated backups is checked already, which creates a point in time snapshot of our database. We can also set how long the automated backups will be kept, with options ranging from 1 to 35 days. And the backup window allows us to choose a daily time range for RDS to take automated backups. Again, encryption is enabled by default for Amazon RDS.
So both the database and backups are encrypted by the default AWS RDS KMS key.
And finally, as another security measure, we can also enable deletion protection, which protects the database from being accidentally deleted. Now let's go ahead and click create database, and while the setup begins, let me explain what we're seeing here. So the multi-AZ DB cluster called Database 1 includes three instances. The Writer instance is the primary database instance responsible for handling write operations. The two Reader instances are replicas of the writer instance and handle read queries.
These reader instances are in different availability zones to ensure high availability and fault tolerance. This is a good setup and follows best practices as a distributed database across multiple availability zones, so if one fails the database can continue operating.
Once the database creation finishes, which may take up to 20 minutes, we will then connect to the database. We can do this using AWS Cloud Shell which is a browser-based terminal that comes with the MySQL client pre-installed. Now the MySQL client is a command line tool that lets us interact with our MySQL database, run queries, and manage data. But first we need to get the endpoint of the database which is the network address that allows our MySQL client or application to connect to and interact with the database.
Let's select our multi-AZ DB cluster and find the endpoint. In the connectivity and security tab, there are endpoints for both the writer and reader instances. For most use cases, we should copy the writer instance endpoint as it handles both read and write operations.
We'll now use this in our MySQL client in Cloud Shell to connect to our database. Open Cloud Shell and in the terminal type the following command and paste the endpoint just like this.

When prompted to enter the password for the admin user, go to the Secrets Manager service and select the secret created for the RDS cluster. Retrieve the password and copy the secret value. Now paste this value into the Cloud Shell prompt.
Congratulations, you're now connected to RDS MySQL database where you now can run SQL queries and interact with your database using the MySQL client. Now don't forget to delete the database when you're done to avoid any ongoing charges.

​Demo: Creating an Amazon RDS MySQL Database With Multi-AZ DB Cluster​

About

Demo: Creating an Amazon RDS MySQL Database With Multi-AZ DB Cluster