Recently, Amazon Aurora Serverless V2 was released by AWS. In an earlier piece, I outlined the distinctions between Aurora Serverless V1 and V2. However, I’m going to guide you through the process of setting up an Aurora Serverless V2 Postgres database in this post.
We will guide you through each step using the AWS interface for your benefit. You’ll have a fully serverless database prepared for your subsequent project by the conclusion of this lesson. Remember that you may also configure your database using CloudFormation or the CDK (Cloud Development Kit). But I believe using the AWS Console is the most excellent method to understand a new AWS service or functionality.
I want to remind you that Aurora Serverless V2 is not accessible before we get started. The database can only be scaled down to the absolute minimum. 5 ACUs, even while not in use. Use of.5 ACUs will cost you around USD 44 per month or 6 cents per hour (as will be done in this post).
Therefore, let’s begin.
1 – Open the Wizard by going to the AWS RDS Console.
Go to the AWS RDS (Relational Database Service) console first thing. You may achieve this by putting RDS into the AWS search box or looking for it in the AWS services section for databases. You ought to arrive at the RDS landing page, which is seen below.
On the left navigation pane, select the Databases option. Then, on the right side of your screen, click the orange Create Database icon. The screenshot below shows the procedure.
- The wizard will start when you select Create Database; we’ll cover it in more detail below. Here is a picture of the procedure.
- The database wizard is launched after navigating to the RDS area.
- Creation and configuration of the Aurora Serverless v2 database
- Weill chooses and set up our Aurora Serverless V2 Database. before deploying itThe wizard’s first few choices are seen in the screenshot below.
- Setting up our Serverless V2 Cluster for Aurora.
- Many alternatives are available, so let me go through the most important ones with you.
- The first step is to choose Standard Create. By default, Easy Create chooses several settings that will cost you money.
Next, choose Amazon Aurora as your Engine Type. Below that, choose either the Postgres or MySQL-compatible version.
We must now choose our engine version. Several MySQL and Postgres versions are currently compatible with Aurora Serverless V2. This covers Postgres versions 13.6, 13.7, and 14.3. 14.3 is an option for this workout.
For development and testing. Multi-az installations and replication will be disabled by default in the wizard.
DB Cluster Identifiers such as name, master username, and master password must now be chosen. Choose a memorable password and give the cluster a name that has meaning.
ACUs and instance configuration
In the dropdown option under “Instance Configuration,” choose “Serverless V2” as the instance class to use. Additionally, the minimum and maximum ACUs, or Aurora Capacity Units, must be filled out. The scaling unit of Aurora Serverless is the ACU.
The Aurora service totally manages how ACUs scale up or down. The intention is for your Aurora database to scale automatically between the minimum and maximum ACUs that you designate. Keep in mind that we are discussing VERTICAL scaling here. This implies that when ACUs increase, your database server’s processing power will also increase. Read replicas and replace autoscaling to allow for horizontal scaling, adding new database nodes. Later, more on that.
Shouldn’t I always set the minimum ACU to 0.5 (the lowest value)? You could ask. Why would I choose a higher setting?
Here are a few crucial explanations:
- When the load grows, the scaling rate decreases and the lower ACUs are.
- By planning beforehand, you can scale to the appropriate minimum during times of high traffic.
- The amount of RAM required by your task is more than what the matching ACU instance offers.
- The AWS manual provides some excellent guidance on selecting the ideal minimum ACUs.
Let’s choose a minimum of for our exercise.
Accessibility and Robustness
Aurora is told to build a standby duplicate of your database in an alternative availability zone when you enable multi-AZ deployments. Recall that AZs, or availability zones, are “one or more distinct data centers in an AWS Region with redundant power, networking, and connectivity. Customers may operate production databases and applications that are more fault tolerant, highly available, and scalable thanks to AZs than from a single data center.
Redundancy is simple to create since every node in an Aurora Serverless V2 database shares the same storage volume.
When your primary database (often the writer node) goes down, Aurora will immediately switch to the replica and make it the new primary. AWS refers to a failure event as a primary node failure. Your database will begin throwing exceptions for read and write queries in the multi-az situation. Typically, it takes less than 60 seconds to restore the database. Having a read replica in a separate Availability Azone is analogous to this.
Keep in mind that all of this only applies if Multi-AZ Deployments are enabled.
When Multi-AZ Deployments are deactivated, and there is a primary database outage, Aurora responds by establishing the database again in the same AZ. With one exception, operations during this period will fail. The service will be reinstated when the new instance is established. Up to 10 minutes may pass during this.
- Enabling Multi-AZ Deployments primarily increases availability by reducing the time it takes to fail over to a backup node.
- The main drawback is the cost of having the second node in a separate availability zone.
- I’ll take the lead on Multi-AZ Deployments for this exercise, as this is merely a demo.
We’ll be using the Default VPC for this demo. Here, we’ll modify the Public Access option to Enable, as seen below.
enabling public access in the Connectivity section to enable internet access for the database
Be aware that opening up a database to the public is not something you would do in a circumstance where it would be used in production. Your database should have restricted access in a production environment and ideally be located in a private network.
You may leave all other connection section settings alone.
Authentication of Databases
IAM or Kerberos access can be configured in your database in addition to password authentication. It’s clever to provide IAM users access to your database without requiring them to create a database account. An alternate authentication method is Kerberos.
- Check out this link for a great article on the principles of IAM.
- You may click Create Database at the bottom right after leaving the other options alone.
- Your Cluster and Database Instance will start creating as you are taken to the RDS home page, as seen below.
- Our writer instance and Aurora Serverless v2 cluster are being set up.
- The setup process might occasionally take up to 10 minutes, and if replicas or Multi-AZ deployments are enabled, it can take much
- longer. Take a coffee break now if you can.
You should observe the Status changing to Available soon after. Then we may attempt to connect to our instance.
You should take note of the database cluster’s endpoint before we proceed, though. To achieve this, click on your cluster and navigate the Connectivity and Security section’s Endpoints subsection. An example is shown in the screenshot below.