Amazon RDSAuthorCloudBrum editorial teamLast reviewed29 Oct 2026Reading time~12 minLevelBeginner to advanced

• Six engines, one way to run themPostgreSQL, MySQL, MariaDB, Oracle, SQL Server and Db2 all run on RDS. The console and the API look the same whatever you choose, so a team can move between engines without learning a new control panel.
• Multi-AZ for failoverA Multi-AZ DB instance keeps a synchronous standby in another Availability Zone and switches to it if the primary fails. A Multi-AZ DB cluster (MySQL and PostgreSQL) has two readable standbys, and usually fails over faster.
• Read replicasCopy data to replicas that serve read-only queries, in the same Region or another one. A replica can be promoted to a standalone database, which makes it useful for scaling reads and for disaster recovery.
• Backups and point-in-time restoreAutomated backups and transaction logs let you restore to nearly any second in the retention period (1 to 35 days). Manual snapshots stay until you delete them.
• Storage that growsgp3 or Provisioned IOPS volumes, with optional autoscaling up to a limit you set. Storage can grow without downtime, but it can’t shrink.
• Encryption and IAM sign-inEncrypt storage with a KMS key, force TLS for connections, let RDS keep the admin password in Secrets Manager, and sign in with short-lived IAM tokens instead of stored passwords on MySQL, MariaDB and PostgreSQL.
• Blue/Green deploymentsBuild a staging copy of the live database, upgrade or change it there, and switch over when it’s ready. It’s the safer way to do major version upgrades.
• Monitoring built inCloudWatch metrics come for free, Enhanced Monitoring adds operating system detail, and AWS is folding Performance Insights into CloudWatch Database Insights for query-level analysis.

DB instance

One database server: an engine, an instance class and storage. Everything you pay for hangs off this.

Instance class

The size of the machine, written like db.m7g.large. Prefixes tell you the family: t is burstable, m is general purpose, r is memory optimised, and a g means AWS Graviton.

Multi-AZ DB instance

A primary plus one standby in another Availability Zone. The standby takes no queries. Failover swaps the DNS name to it.

Multi-AZ DB cluster

A writer plus two readable standbys in three zones, for MySQL and PostgreSQL. You get reader and writer endpoints.

Read replica

An asynchronous copy for read traffic. It lags a little behind the source, and can be promoted.

Subnet group

The set of subnets (in at least two Availability Zones) where RDS is allowed to place your instance.

Parameter group

A named set of engine settings, such as max_connections or rds.force_ssl. Some changes apply only after a reboot.

Automated backup

A daily snapshot plus continuous transaction logs, kept for the retention period you set (1 to 35 days, and 0 turns them off).

Snapshot

A manual backup that stays until you delete it. You can copy it to another Region or share it with another account.

Point-in-time restore

Creates a new instance from the backups, at a time you choose. It never overwrites the original.

Maintenance window

A weekly slot when RDS may apply patches or changes that need a restart.

RDS Proxy

A managed connection pool in front of the database. It keeps connections open, which helps apps with many short-lived connections, such as Lambda.

Blue/Green deployment

A synchronised staging copy (green) of your production database (blue) that you can change, test and then switch to.

Endpoint

The DNS name your application connects to. After a failover it points at the new primary, so don’t use IP addresses.

Create a PostgreSQL database in the AWS console

1. Pick the Region and plan the networkChoose a Region near your users (Mumbai or Hyderabad for India). Make sure the VPC has private subnets in at least two Availability Zones, and create a DB subnet group from them.
2. Choose Standard createOpen RDS, then Create database, and use Standard create so you see every setting. The easy-create option picks defaults you may not want, including how the database is reached.
3. Choose the engine and the versionPick PostgreSQL (or MySQL) and a recent major version that’s still in standard support. Older versions cost extra after support ends. Use the Production template when you want Multi-AZ preselected.
4. Set the availabilityFor anything real, choose a Multi-AZ DB instance, or a Multi-AZ DB cluster if you want readable standbys. Single-AZ is fine for development, and it halves the instance cost.
5. Let RDS manage the admin passwordChoose Managed in AWS Secrets Manager. You’ll fetch the password from there when you need it, and RDS can rotate it.
6. Pick the size and the storageStart with a general purpose m or a burstable t class, gp3 storage, and storage autoscaling with a maximum you can live with. Resize later from the measurements.
7. Keep it privateChoose your VPC and the subnet group, set Public access to No, and attach a security group that allows port 5432 only from your application’s security group.
8. Set backups and protectionChoose a backup retention of 7 to 35 days, a backup window outside your busy hours, encryption with the default or a KMS key, and turn on Deletion protection.
9. Connect and checkConnect from an app server in the VPC with TLS on, create an application user with only the rights it needs, and look at the CloudWatch graphs. Then test a restore before you rely on the backups.

• Pick the instance class from measurements: CPU, memory and the buffer cache hit ratio. Memory-heavy databases usually want an r class, and small steady ones do well on m.
• Choose gp3 storage and set IOPS and throughput on their own when you need more, or Provisioned IOPS (io2) for demanding, latency-sensitive workloads.
• Use RDS Proxy or a pooler when thousands of short-lived connections hit the database, for example from Lambda functions.
• Send reads to replicas and keep writes on the primary, and watch replica lag so you don’t serve stale data by surprise.
• Find slow queries with Database Insights or pg_stat_statements, add the right indexes, and check query plans before throwing hardware at the problem.
• Keep transactions short and avoid long-running idle transactions, which hold locks and prevent cleanup.
• Set parameter groups deliberately (connections, memory, logging) instead of living with defaults, and apply them in a test first.
• Run the application in the same Region and Availability Zone as the primary where you can, since every cross-zone call adds latency and a small charge.

FinOps is the habit of managing cloud spend together with engineering. These are the FinOps checks that matter most for Amazon RDS.

• Use Single-AZ for development and test, and keep Multi-AZ for production. It’s the biggest single lever on the instance bill.
• Right-size from the CloudWatch graphs. A database that idles at 10% CPU can drop a size.
• Use Graviton instance classes (g in the name), which are usually cheaper for the same performance, if your engine and extensions support them.
• Buy Reserved Instances for databases you know will run for a year or more. Note that they don’t cover Extended Support charges.
• Stop non-production instances you aren’t using. A stopped instance isn’t billed for instance hours, but RDS starts it again after seven days, and storage keeps billing.
• Set a backup retention that matches your recovery needs. Automated backup storage up to the size of the database is free, and beyond that you pay.
• Delete old manual snapshots and unused read replicas, and copy snapshots across Regions only for data that needs it.
• Upgrade engines before standard support ends. Extended Support is billed per vCPU-hour on top of the normal price.
• Choose gp3 over older gp2 so you can buy IOPS separately from size, and don’t over-provision storage you’ll never fill.
• Tag instances by team and project, and set a budget alert for RDS.

• Place instances in private subnets with Public access off, and allow the database port only from the security groups of the applications that need it.
• Encrypt storage with KMS when you create the instance, since you can’t just switch it on later, and encrypt snapshots too.
• Require TLS (rds.force_ssl on PostgreSQL, require_secure_transport on MySQL) and verify the server certificate with the current RDS CA bundle.
• Let RDS manage the master password in Secrets Manager, and keep the master user out of application code.
• Use IAM database authentication on engines that support it, so connections use 15-minute tokens instead of stored passwords.
• Give each application its own database user with only the privileges it needs, and revoke public rights on schemas you care about.
• Turn on deletion protection and keep final snapshots, and copy important snapshots to a separate account.
• Export database logs to CloudWatch Logs, record API activity in CloudTrail, and alert on failed logins and parameter changes.
• Use AWS Config and Security Hub rules to catch public instances, unencrypted storage and missing backups.
• Limit who can modify, delete or share instances and snapshots with IAM policies and, in a larger setup, service control policies.

AWS CloudTrail shows who created, changed or deleted instances, AWS Config keeps configuration history and the rules above, AWS Backup can add central backup policies and cross-account copies, and AWS Artifact holds compliance reports. The split is the usual one: AWS runs the hardware, the engine patching and the failover machinery, while you answer for the data, the schema, user access, network exposure and your recovery testing.

• Right-size the instance. An oversized database burns electricity all day for headroom it never uses.
• Use Graviton-based classes where your engine supports them. They do more work per watt.
• Stop or delete development databases at the end of the day or the project, rather than leaving them idle.
• Keep fewer copies: remove forgotten replicas and old snapshots that nobody will restore.
• Cache and index well, so queries read less data and the same hardware does more.
• Choose a Region with a cleaner grid for workloads that aren’t tied to a place, as far as data rules allow.
• The AWS Customer Carbon Footprint Tool estimates emissions for an account. Check what it includes for RDS before you quote a figure from it.

Purchase options

What you actually pay for

• Instance hours by class, engine and licence, doubled for Multi-AZ
• Storage by type and size, with IOPS and throughput beyond the baseline
• Backup storage above the free allowance, plus manual snapshots and cross-Region copies
• Data sent out to the internet or copied to another Region
• RDS Proxy, Enhanced Monitoring, Database Insights and Extended Support when you use them

A private PostgreSQL database for an orders application: Multi-AZ, encrypted, 14 days of backups, no public address, the admin password kept in Secrets Manager and IAM sign-in turned on. The CLI and Terraform tabs build it, add a read replica and show a point-in-time restore. The Python and C# tabs connect with a 15-minute IAM token over verified TLS and place an order in a transaction. Replace the subnet group, security group, user and Region with your own. A Multi-AZ instance bills from the moment it starts, so delete the test database when you’re done.

# Placeholders: replace the subnet group and the security group with ones in your own VPC.
REGION=ap-south-1
SG=sg-0123456789abcdef0

# A private, Multi-AZ, encrypted PostgreSQL instance. RDS creates and stores the admin password in Secrets Manager.
aws rds create-db-instance --region $REGION \
  --db-instance-identifier orders-db \
  --engine postgres --engine-version 16 \
  --db-instance-class db.m7g.large \
  --storage-type gp3 --allocated-storage 100 --max-allocated-storage 500 \
  --storage-encrypted \
  --multi-az \
  --db-subnet-group-name orders-private \
  --vpc-security-group-ids $SG \
  --no-publicly-accessible \
  --master-username orders_admin --manage-master-user-password \
  --enable-iam-database-authentication \
  --backup-retention-period 14 --preferred-backup-window 21:00-21:30 \
  --copy-tags-to-snapshot --deletion-protection \
  --tags Key=owner,Value=orders-team

aws rds wait db-instance-available --region $REGION --db-instance-identifier orders-db

# A read replica for reporting queries
aws rds create-db-instance-read-replica --region $REGION \
  --db-instance-identifier orders-db-replica \
  --source-db-instance-identifier orders-db \
  --db-instance-class db.m7g.large \
  --no-publicly-accessible

# Practise the restore: a new instance from the backups, at the latest restorable moment
aws rds restore-db-instance-to-point-in-time --region $REGION \
  --source-db-instance-identifier orders-db \
  --target-db-instance-identifier orders-db-restore-test \
  --use-latest-restorable-time \
  --no-publicly-accessible --no-deletion-protection

# Clean up the test copy (the original has deletion protection on)
aws rds delete-db-instance --region $REGION --db-instance-identifier orders-db-restore-test --skip-final-snapshot

# Assumes the AWS provider version 5 or later, an existing VPC with private subnets, and the application's security group
variable "private_subnet_ids" { type = list(string) }
variable "vpc_id"             { type = string }
variable "app_sg_id"          { type = string }

resource "aws_db_subnet_group" "orders" {
  name       = "orders-private"
  subnet_ids = var.private_subnet_ids
}

resource "aws_security_group" "db" {
  name   = "orders-db"
  vpc_id = var.vpc_id

  # PostgreSQL, only from the application's security group
  ingress {
    from_port       = 5432
    to_port         = 5432
    protocol        = "tcp"
    security_groups = [var.app_sg_id]
  }
}

resource "aws_db_parameter_group" "orders" {
  name   = "orders-postgres16"
  family = "postgres16"

  parameter {
    name  = "rds.force_ssl"
    value = "1"
  }
  parameter {
    name  = "log_min_duration_statement"
    value = "500"   # log queries slower than half a second
  }
}

resource "aws_db_instance" "orders" {
  identifier     = "orders-db"
  engine         = "postgres"
  engine_version = "16"
  instance_class = "db.m7g.large"

  storage_type          = "gp3"
  allocated_storage     = 100
  max_allocated_storage = 500
  storage_encrypted     = true

  multi_az               = true
  db_subnet_group_name   = aws_db_subnet_group.orders.name
  vpc_security_group_ids = [aws_security_group.db.id]
  publicly_accessible    = false
  parameter_group_name   = aws_db_parameter_group.orders.name

  username                            = "orders_admin"
  manage_master_user_password         = true     # RDS keeps it in Secrets Manager
  iam_database_authentication_enabled = true

  backup_retention_period   = 14
  backup_window             = "21:00-21:30"
  copy_tags_to_snapshot     = true
  deletion_protection       = true
  skip_final_snapshot       = false
  final_snapshot_identifier = "orders-db-final"

  auto_minor_version_upgrade      = true
  enabled_cloudwatch_logs_exports = ["postgresql"]

  tags = { owner = "orders-team" }
}

# A read replica for reporting
resource "aws_db_instance" "orders_replica" {
  identifier          = "orders-db-replica"
  replicate_source_db = aws_db_instance.orders.identifier
  instance_class      = "db.m7g.large"
  publicly_accessible = false
  storage_encrypted   = true
  skip_final_snapshot = true
}

# pip install boto3 "psycopg[binary]"
# Download the RDS certificate bundle once:  https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem
import time

import boto3
import psycopg

HOST = "orders-db.abcdefghij.ap-south-1.rds.amazonaws.com"
REGION = "ap-south-1"
DB_USER = "app_user"       # created in the database with:  CREATE USER app_user; GRANT rds_iam TO app_user;
DB_NAME = "orders"


def connect():
    """Open a verified TLS connection using a 15-minute IAM token as the password."""
    token = boto3.client("rds", region_name=REGION).generate_db_auth_token(
        DBHostname=HOST, Port=5432, DBUsername=DB_USER, Region=REGION)
    return psycopg.connect(
        host=HOST, port=5432, dbname=DB_NAME, user=DB_USER, password=token,
        sslmode="verify-full", sslrootcert="global-bundle.pem", connect_timeout=5)


def place_order(conn, customer_id, total_cents):
    """Insert one order inside a transaction and return its id."""
    with conn.transaction():
        row = conn.execute(
            "INSERT INTO orders (customer_id, total_cents) VALUES (%s, %s) RETURNING id",
            (customer_id, total_cents)).fetchone()
    return row[0]


def with_retry(action, attempts=3):
    """Retry on connection failures, which is what a Multi-AZ failover looks like to the app."""
    for attempt in range(1, attempts + 1):
        try:
            with connect() as conn:
                return action(conn)
        except psycopg.OperationalError:
            if attempt == attempts:
                raise
            time.sleep(2 * attempt)


if __name__ == "__main__":
    new_id = with_retry(lambda c: place_order(c, 42, 129900))
    print(f"Created order {new_id}")

// Program.cs: sign in with an IAM token over verified TLS and insert an order in a transaction
// NuGet packages: Npgsql, AWSSDK.RDS
using Amazon;
using Amazon.RDS.Util;
using Npgsql;

const string host = "orders-db.abcdefghij.ap-south-1.rds.amazonaws.com";
const string user = "app_user";   // CREATE USER app_user; GRANT rds_iam TO app_user;

// A token lasts 15 minutes, so create one just before opening the connection
var token = RDSAuthTokenGenerator.GenerateAuthToken(RegionEndpoint.APSouth1, host, 5432, user);

var builder = new NpgsqlConnectionStringBuilder
{
    Host = host,
    Port = 5432,
    Database = "orders",
    Username = user,
    Password = token,
    SslMode = SslMode.VerifyFull,
    RootCertificate = "global-bundle.pem",   // the RDS certificate bundle
    Timeout = 5
};

using var conn = new NpgsqlConnection(builder.ConnectionString);
conn.Open();

using var tx = conn.BeginTransaction();
try
{
    using var cmd = new NpgsqlCommand("INSERT INTO orders (customer_id, total_cents) VALUES (@c, @t) RETURNING id", conn, tx);
    cmd.Parameters.AddWithValue("c", 42L);
    cmd.Parameters.AddWithValue("t", 129900);
    var id = (long)cmd.ExecuteScalar()!;
    tx.Commit();
    Console.WriteLine($"Created order {id}");
}
catch
{
    tx.Rollback();   // leave nothing half-written
    throw;
}

Short walkthrough videos for this service are being prepared. They will appear here and load only when you press play. Until then, follow CloudBrum on YouTube for new videos.

If you need scale beyond a single writer, or want storage that scales on its own, look at Amazon Aurora, Azure SQL Hyperscale or AlloyDB, which are separate services. For key-value workloads a NoSQL database is the better fit, and for analytics a warehouse. Application servers that talk to RDS usually run on Amazon EC2 or AWS Lambda.