What is Amazon RDS?

Amazon RDS (Relational Database Service) is a managed service for running a traditional SQL database in the cloud. Instead of installing MySQL or PostgreSQL on a server yourself, you ask AWS for a database and AWS handles the boring, error-prone parts: provisioning the server, installing and patching the database engine, taking backups, and replacing failed hardware. You still write the same SQL and connect with the same drivers — you just stop being the person who gets paged at 3am because the disk filled up.

Managed database vs. a database you run yourself

A relational database stores data in tables with rows and columns and uses SQL (Structured Query Language) to query it. You can run one of these two ways on AWS.

The first way is “do it yourself”: you launch an EC2 instance (a virtual server) and install the database software on it. You own every layer — the operating system (OS), the database engine, the backups, the security updates, the failover plan. Total control, total responsibility.

The second way is RDS. AWS owns the layers below your data, and you own the data and your schema. Here is who does what.

Layer	DB on EC2 (self-managed)	Amazon RDS (managed)
Your tables, queries, schema	You	You
Database engine install & version upgrades	You	AWS (you click a button)
OS patching	You	AWS
Automated backups & point-in-time restore	You build it	AWS, built in
Hardware failure / failover	You design it	AWS, optional Multi-AZ
OS / root shell access	You have it	You do NOT

The trade is simple: RDS takes away a huge amount of operational work, but in exchange it takes away your root login and your ability to install anything you want on the box.

When to use RDS (and when not to)

Use RDS when you want a standard relational database (a typical web app, an API backend, a reporting database) and you would rather build features than babysit servers. This is the right default for almost everyone.

Do not use plain RDS when you genuinely need OS-level (sudo/root) access, a database extension that AWS does not allow, a kernel tweak, or a database version AWS has not certified. In those cases your fallbacks are RDS Custom (RDS that grants you OS and database-admin access for Oracle and SQL Server) or going fully self-managed on EC2. More on that gotcha below.

Supported engines

RDS runs several engines. You pick one when you create the instance; you cannot change it later (you migrate instead).

Engine	Good fit for	Notes
PostgreSQL	New apps, rich SQL, extensions	Very popular default; strong feature set
MySQL	Web apps, broad ecosystem	Familiar, widely supported
MariaDB	MySQL-compatible workloads	Community fork of MySQL
Oracle	Existing Oracle estates	License-included or bring-your-own-license
SQL Server	.NET / Microsoft shops	Multiple editions
Amazon Aurora	High-performance MySQL/Postgres	AWS-built, MySQL- and PostgreSQL-compatible; covered on its own page

If your app already speaks one of these, RDS is usually a near drop-in replacement — change the connection string (the endpoint) and you are done.

Creating an RDS instance

You can create a database in the console or with the AWS Command Line Interface (CLI), the tool that lets you run AWS actions from a terminal.

Console steps:

Open the RDS console and choose Databases > Create database.
Pick Standard create, then choose an engine (e.g. PostgreSQL).
Choose a template: Production, Dev/Test, or Free tier.
Set the DB instance identifier (a name like my-app-db), the master username, and a password.
Choose an instance class (the server size, e.g. db.t3.micro) and storage.
Pick the VPC (your private network) and whether the database is publicly reachable. Keep it private unless you have a strong reason.
Click Create database and wait a few minutes for status to become Available.

Equivalent AWS CLI:

aws rds create-db-instance \
  --db-instance-identifier my-app-db \
  --db-instance-class db.t3.micro \
  --engine postgres \
  --master-username appadmin \
  --master-user-password 'ChangeMe-Str0ng!' \
  --allocated-storage 20 \
  --vpc-security-group-ids sg-0a1b2c3d \
  --db-subnet-group-name my-db-subnets \
  --no-publicly-accessible \
  --backup-retention-period 7

Output:

{
    "DBInstance": {
        "DBInstanceIdentifier": "my-app-db",
        "DBInstanceClass": "db.t3.micro",
        "Engine": "postgres",
        "DBInstanceStatus": "creating",
        "MasterUsername": "appadmin",
        "AllocatedStorage": 20,
        "BackupRetentionPeriod": 7,
        "MultiAZ": false
    }
}

Once it is available, get the endpoint (the hostname your app connects to):

aws rds describe-db-instances \
  --db-instance-identifier my-app-db \
  --query "DBInstances[0].Endpoint.Address" \
  --output text

Output:

my-app-db.abcd1234efgh.us-east-1.rds.amazonaws.com

Cost note: A db.t3.micro with 20 GB of storage is a few dollars a month and may fall under the Free Tier for your first 12 months. But turning on Multi-AZ (a standby copy in another data center for high availability) roughly doubles the instance cost, and read replicas each cost as much as another instance. Right-size before you scale out.

The gotcha: you give up root and some extensions

This is the part tutorials skip. With RDS, AWS keeps the OS locked down, so:

You cannot SSH into the database server or run sudo. There is no shell.
You get a master user, but it is not a true database superuser — it is a powerful-but-limited role. Some commands that need full superuser rights will be denied.
You can only use extensions AWS has approved for that engine and version. If your app depends on a custom or niche PostgreSQL extension that is not on the supported list, you cannot install it.
You can only run engine versions AWS supports. Brand-new or very old versions may not be available.

Warning: Before migrating to RDS, list every extension your database uses and confirm each one is on the supported-extensions list for your engine and version. Discovering an unsupported extension after you have moved is a painful surprise.

If any of those limits is a dealbreaker, you have two escape hatches. RDS Custom gives you OS and database-admin access while AWS still helps with backups and HA — currently for Oracle and SQL Server. If you need full control over any engine, a database on EC2 is the honest answer: you run it yourself, root and all, and accept the operational work that comes with it.

Best practices

Keep the database private (no public access); let only your application’s security group reach it on the database port.
Turn on automated backups with a retention period that matches your recovery needs (7 days is a sensible start).
Use Multi-AZ for anything production so a single data center failure does not take you down.
Store the master password in AWS Secrets Manager, not in code or environment files; better still, enable IAM database authentication where supported.
Audit your extensions and engine version against the RDS supported list before migrating, not after.
Right-size the instance class and enable storage autoscaling so you do not over-provision or run out of disk.