Skip to Content

Amazon Aurora Serverless V2 Setup Tutorial with Postgres

Posted on October 28, 2022 by

Categories: AWS


This article lets you discover how to create and customise an Amazon Aurora Serverless V2 Postgres database.

Recently, Amazon Aurora Serverless V2 was released by AWS. In an earlier article, I outlined the distinctions between Aurora Serverless V1 and V2. However, I will walk you through setting up an Aurora Serverless V2 Postgres database in this article.

We will walk you through each step using the AWS console for your benefit. You’ll have a fully serverless database prepared for your subsequent project by the end of this tutorial. Remember that you can also configure your database using CloudFormation or the CDK (Cloud Development Kit). But I firmly believe that using the AWS Console is the best way to learn a new AWS service or feature.

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.

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 sets 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 over the most important ones with you now.
  • The first step is to choose Standard Create. By default, Easy Create chooses several settings that will cost you money.

Engine Specifics

Next, choose Amazon Aurora as your Engine Type. Below that, choose either the Postgres or MySQL-compatible edition.

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 menu under “Instance Configuration,” select “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 significant than what the matching ACU instance offers.
  • The AWS manual provides some excellent guidance on selecting the ideal minimum ACUs.

Accessibility and Robustness

You can decide how to make your databases more accessible and resilient in this area. Multi-AZ Deployments, a feature, are used to do this.

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 centres in an AWS Region with redundant power, networking, and connectivity. Customers can operate production databases and applications that are more fault tolerant, highly available, and scalable thanks to AZs than from a single data centre.

Redundancy is simple to create because 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 after the new instance is created. 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 utilising the Default VPC for this demo. Here, we’ll modify the Public Access setting to Enable, as shown 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 can leave all other connectivity 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 can click Create Database at the bottom right after leaving the other settings alone.
  • Your Cluster and Database Instance will start creating as you are taken to the RDS home page, as shown 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 even longer. Take a coffee break now if you can.
  • You should observe the Status changing to Available soon after. Then we can 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.