How to Create an Amazon RDS Database Step by Step: PostgreSQL and MySQL Setup Guide

Amazon Relational Database Service (Amazon RDS) is a managed service for running relational databases without manually installing, patching, backing up, and maintaining the underlying database server. You still control the database engine, instance size, storage, networking, security, backups, monitoring, and application connectivity.

Recommended production design: Place the RDS database in private subnets, disable public access, allow traffic only from approved application security groups, enable encryption and backups, and use Session Manager rather than exposing database ports to the internet.

This guide explains how to create an Amazon RDS database using PostgreSQL or MySQL, test the connection, troubleshoot common problems, and prepare the database for Amazon RDS Proxy .

What Is an Amazon RDS DB Instance?#

An RDS DB instance is an isolated managed database environment. AWS provides an endpoint and port that applications and standard database clients use to connect. Unlike a normal EC2 server, standard RDS does not provide operating-system or SSH access. Database administration is performed through SQL tools, the RDS console, AWS CLI, APIs, parameter groups, and option groups.

Supported Database Engines#

Amazon RDS supports several relational database engines, including:

• PostgreSQL
• MySQL
• MariaDB
• Microsoft SQL Server
• Oracle Database
• IBM Db2

Amazon Aurora is a separate AWS-compatible database family that supports MySQL-compatible and PostgreSQL-compatible editions. This article focuses mainly on standard RDS PostgreSQL and MySQL because their setup pattern is widely used.

Amazon RDS Setup Architecture#

Before Creating the Database#

Decide the following before opening the RDS console:

• AWS Region: Normally the same Region as the application to reduce latency.
• Database engine: PostgreSQL or MySQL based on application compatibility and team expertise.
• Environment: Development, test, staging or production.
• Availability: Single-AZ for low-cost non-production workloads or Multi-AZ for production resilience.
• Networking: VPC, private subnets, DB subnet group and security groups.
• Capacity: Instance class, storage size, storage type and autoscaling.
• Security: Encryption, authentication, credential management and network restrictions.
• Operations: Backup retention, maintenance window, monitoring, logging and deletion protection.

Step 1: Prepare the VPC and Private Subnets#

A secure production database should normally use private subnets. The VPC should contain subnets in at least two Availability Zones so that RDS can place database resources appropriately and support high-availability configurations.

Recommended VPC Layout#

The database subnets should not have a route that directly exposes the database to an internet gateway. RDS itself does not usually need outbound internet access for normal database operation.

Step 2: Create a DB Subnet Group#

1. Open the Amazon RDS console .
2. Choose Subnet groups .
3. Select Create DB subnet group .
4. Enter a name such as production-db-subnet-group .
5. Select the application VPC.
6. Add private database subnets from at least two Availability Zones.
7. Create the subnet group.

Common mistake: Selecting only one subnet or multiple subnets from the same Availability Zone can prevent the subnet group from meeting RDS requirements.

Step 3: Create the Database Security Group#

Create a dedicated security group for the database, for example rds-production-sg .

PostgreSQL Rule#

MySQL Rule#

Use a security-group reference rather than a wide CIDR range whenever possible. Do not allow port 5432 or 3306 from 0.0.0.0/0 .

Step 4: Open the Create Database Wizard#

1. Sign in to the AWS Management Console.
2. Open Amazon RDS .
3. Confirm that the correct AWS Region is selected.
4. Choose Databases .
5. Select Create database .
6. Choose Standard create .

Standard create is recommended for learning and production because it exposes the important networking, security, availability, backup, monitoring, and maintenance settings. Easy create uses more defaults and provides less control during creation.

Step 5: Choose the Database Engine#

Select PostgreSQL or MySQL and choose an engine version supported in your Region. For production, choose a version supported by your application, drivers, extensions, migration tools, and organizational lifecycle policy. Avoid selecting an old version merely because an existing tutorial uses it.

PostgreSQL Is Commonly Chosen For#

• Advanced SQL features and strong standards support.
• JSON and relational workloads.
• Extensions and geospatial use cases.
• Applications already built for PostgreSQL.

MySQL Is Commonly Chosen For#

• Web applications and common content platforms.
• Applications already using MySQL-compatible drivers.
• Teams with existing MySQL operational experience.

Step 6: Choose a Template#

The available templates can vary based on the account and selected engine. Typical choices include production, development/test, and a free-tier or sandbox option where eligible.

• Production: Enables or recommends settings suitable for availability and durability.
• Development/Test: Uses lower-cost defaults but should still be secured.
• Free tier or Sandbox: Useful for learning when available, but eligibility and charges depend on the account.

Step 7: Configure Availability and Durability#

For production, use a Multi-AZ deployment when the workload requires high availability. Multi-AZ maintains a standby in another Availability Zone and supports automatic failover. It is not primarily a read-scaling solution.

Step 8: Configure Database Settings#

• DB instance identifier: Use a descriptive name such as orders-prod-postgres .
• Master username: Use a controlled administrative username. Avoid application use of the master account.
• Credential management: Prefer managed credentials in AWS Secrets Manager where the selected workflow supports it.
• Initial database name: Examples include orders , inventory , or applicationdb .

Security practice: Create a separate least-privileged database user for the application after provisioning. Do not place the master username and password directly in source code, container images, Git repositories, or CI/CD YAML.

Step 9: Select the DB Instance Class#

The instance class determines CPU, memory, networking capacity and maximum practical connection handling. Available classes depend on the engine, version and Region.

• Burstable classes: Suitable for development and light workloads with variable usage.
• General-purpose classes: Balanced compute and memory for many production applications.
• Memory-optimized classes: Suitable for memory-heavy databases, large caches and demanding workloads.

Do not select the smallest class automatically for production. Review workload memory, active connections, query patterns, CPU, storage throughput, failover requirements and expected growth.

Step 10: Configure Storage#

Select an SSD storage type suitable for the workload. General-purpose SSD is a common starting point, while provisioned IOPS can be appropriate for workloads requiring predictable I/O performance.

• Set the initial allocated storage.
• Enable storage autoscaling where appropriate.
• Set a sensible maximum storage threshold.
• Review provisioned IOPS and throughput options if displayed.
• Enable storage encryption using an AWS KMS key.

Storage encryption generally protects database storage, automated backups, read replicas and snapshots associated with the encrypted instance. Plan the KMS key carefully because encryption choices can affect snapshot sharing, restore procedures and cross-account operations.

Step 11: Configure Connectivity#

In the Connectivity section, configure:

• Compute resource: Connect automatically to an EC2 resource when appropriate, or choose not to connect automatically for manual control.
• VPC: Select the VPC used by the application.
• DB subnet group: Select the private DB subnet group created earlier.
• Public access: Select No for normal production use.
• VPC security group: Select the dedicated database security group.
• Availability Zone: Allow AWS to choose unless there is a specific architecture requirement.
• Port: PostgreSQL normally uses 5432; MySQL normally uses 3306.

Should Public Access Be Enabled?#

For production, the recommended answer is normally No . Public access is not required for an application running inside the same VPC or connected network. Administrators can use AWS Systems Manager Session Manager port forwarding through a managed EC2 instance instead of exposing the database publicly.