How to Create an Amazon Aurora PostgreSQL Serverless v2 Cluster in AWS: Complete Step-by-Step Guide

Amazon Aurora PostgreSQL can look intimidating because the AWS creation page contains many options. This guide explains the important settings one by one and shows how to create a secure, private Aurora PostgreSQL Serverless v2 cluster for a generic application running inside an AWS VPC.

What you will build Application or Lambda → Security Group → Aurora PostgreSQL Serverless v2 → Secrets Manager → SSM Parameter Store

What is Amazon Aurora?#

Amazon Aurora is a fully managed relational database service from AWS that is compatible with PostgreSQL and MySQL. You do not install PostgreSQL manually on top of Aurora. During cluster creation, you select the PostgreSQL-compatible engine and AWS provisions the database engine, distributed storage, endpoints, backups, replication, patching, monitoring, and failover capabilities.

Prerequisites#

• An AWS account with permission to create RDS/Aurora, Secrets Manager, SSM Parameter Store, security groups, subnet groups, and related networking resources.
• A VPC with at least two private subnets in different Availability Zones.
• A DB subnet group containing those subnets.
• An application, Lambda, ECS, EKS, or EC2 security group that will be allowed to connect to PostgreSQL on port 5432.
• A naming convention for the cluster, database, security group, secret, and SSM parameters.
• A clear cost limit for development and production environments.

Step 1: Open the Aurora and RDS console#

Open Aurora and RDS → Databases → Create database .

Step 2: Select the database engine#

Under Engine options , choose Aurora (PostgreSQL Compatible) .

Why: This creates an Aurora cluster that uses the PostgreSQL protocol and works with PostgreSQL-compatible drivers and administration tools.

Step 3: Choose the database creation method#

Select Full configuration .

Why: Full configuration allows you to control the VPC, subnet group, security groups, credentials, Serverless v2 capacity, backups, monitoring, encryption, maintenance, and availability settings.

Step 4: Select a template#

• Dev/Test: appropriate for learning, proof-of-concept, and development environments.
• Production: enables defaults that favor availability, durability, and monitoring, but can increase cost.

For a lab or development environment, choose Dev/Test .

Step 5: Choose the cluster scalability type#

• Provisioned: uses fixed-size database instances that run continuously.
• Aurora Serverless v2: automatically scales compute capacity within a minimum and maximum ACU range.
• Limitless Database: intended for specialized, very large horizontally scaled workloads.

For a variable development workload, choose Aurora Serverless and configure Serverless v2 capacity limits later in the form.

Step 6: Select the engine version#

Select the exact Aurora PostgreSQL version required by your application and supported in your AWS Region. Engine versions change over time, so confirm compatibility with application drivers, required extensions, and organizational standards.

Step 7: Enter the cluster identifier#

Use a clear, environment-specific name such as:

The cluster identifier is the AWS resource name. It is separate from the PostgreSQL database name used by the application.

Step 8: Configure master credentials#

Choose a master username such as:

For credential management, select Managed in AWS Secrets Manager .

Why: AWS generates and stores the master password securely, avoiding passwords in templates, source code, shell history, tickets, or documentation.

The default Secrets Manager KMS key is suitable for many environments. Use a customer-managed KMS key only when your security policy requires dedicated key control, key rotation, or cross-account access.

Step 9: Additional authentication#

• Password authentication: enabled by default and suitable for normal PostgreSQL clients.
• IAM database authentication: enable only when the application is designed to generate temporary IAM database tokens.
• Kerberos authentication: enable only for environments integrated with Microsoft Active Directory.

Step 10: Choose the storage configuration#

• Aurora Standard: usually better for development and moderate I/O workloads.
• Aurora I/O-Optimized: better for I/O-heavy workloads where I/O charges are a large portion of the overall database cost.

For a small development environment, Aurora Standard is normally the best starting point.

Step 11: Availability and durability#

• Create an Aurora Replica: improves availability and failover, but increases cost.
• Do not create a replica: reduces cost and may be acceptable for non-critical development workloads.

For production, use at least one reader in another Availability Zone unless your architecture has a documented exception.

Step 12: Configure connectivity#

Compute resource#

Select Don't connect to an EC2 compute resource when the application will connect through Lambda, ECS, EKS, or manually configured networking.

Network type#

Select IPv4 unless the environment specifically requires IPv6 or dual-stack networking.

VPC#

Select the same VPC used by the application. The VPC cannot be changed after database creation, so verify it carefully.

DB subnet group#

Select a DB subnet group containing private subnets across at least two Availability Zones. Aurora uses the DB subnet group to determine where database resources may be placed.

Public access#

Select No .

Why: Databases should normally remain private. Applications inside the VPC connect through private DNS and security group rules. Administrative access can be provided through SSM port forwarding, a VPN, Direct Connect, or another approved private-access method.

VPC security group#

Create a dedicated database security group, for example:

Add an inbound rule:

Do not allow PostgreSQL from 0.0.0.0/0 . If the application security group has restricted outbound traffic, add an outbound rule from the application security group to the Aurora security group on TCP 5432.

Step 13: Certificate authority and TLS#

Keep the current default RDS certificate authority unless your organization requires a specific CA. Aurora supports TLS. Applications can enforce encrypted connections with: