A relational database is a system that stores data in tables made of rows and columns, the way a spreadsheet does, and lets you connect related tables together (a “customers” table linked to an “orders” table, for example). Software like MySQL, PostgreSQL, and Microsoft SQL Server are relational database engines — the actual programs that store and retrieve this data.

Running one of these engines yourself means installing the software on a server, patching security holes every month, configuring backups, watching disk space, and being the person who gets paged at 3 a.m. when the server crashes. Amazon RDS is Amazon’s managed service that runs these same database engines for you, on servers Amazon owns and maintains, while you keep full control of your actual data and how you query it.

RDS currently supports several engines: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server, and Amazon’s own cloud-native engine, Amazon Aurora (which is compatible with MySQL and PostgreSQL but rebuilt internally for cloud performance). Choosing an engine is like choosing a car brand for your ride-hailing trip — the destination-planning skill (SQL) mostly carries over, but each engine has its own quirks.

When you launch an RDS database, AWS assembles a small ecosystem of connected parts. Understanding each piece individually makes the whole system far less mysterious.

flowchart TB
    A[Application Servers] -->|SQL over TCP| B[RDS Endpoint - DNS Name]
    B --> C[Primary DB Instance]
    C --> D[(Primary EBS Storage)]
    C -.Synchronous Replication.-> E[Standby Instance - Other AZ]
    E --> F[(Standby EBS Storage)]
    C --> G[Read Replica 1]
    C --> H[Read Replica 2]
    I[Security Group] --- C
    J[Parameter Group] --- C
    K[VPC Subnet Group] --- C
        

Notice something important in the diagram: your application never talks to a specific server by its IP address. It always talks to the endpoint, a DNS name like mydb.abc123xyz.us-east-1.rds.amazonaws.com. This single design decision is what allows RDS to swap the actual server underneath during a failure without your application code ever knowing.

Behind the scenes, when you click “Create Database” in the AWS console, a chain of automated events fires off. AWS selects a physical host machine in the Availability Zone you chose, attaches network-backed storage volumes to it, installs and configures your chosen database engine version, applies your parameter group settings, and finally opens the network port defined by your security group. All of this typically finishes in a few minutes.

Once running, a background management agent on each RDS host continuously reports health signals — CPU load, storage usage, replication lag — back to the RDS control plane. This is the same control plane that decides when to apply patches, when to take automated backups, and when a failover is needed.

Importantly, AWS engineers do not get direct shell access to the operating system running your database instance in the standard RDS model. This is a deliberate security boundary: you get the benefits of managed patching without exposing your data to broader operational access. If you need OS-level access for licensing or custom agents, that is the specific use case for RDS Custom, covered later in this guide.

On the query side, the data flow for a single request looks like this: your application resolves the endpoint’s DNS name, opens a TCP connection to the resolved instance, sends a SQL statement, the engine parses and executes it against the storage volume, and returns rows back over the same connection. Every one of the millions of queries a busy application sends per day follows this exact same path.

The central trade-off is control versus convenience. Self-managed databases give you full access to every configuration knob and the operating system itself, at the cost of doing all the operational work yourself. RDS trades some of that low-level control for a dramatic reduction in day-to-day maintenance, which is exactly why it fits the vast majority of business applications that need a reliable database without a dedicated database administration team.

RDS offers two distinct scaling directions, and beginners often confuse them. Vertical scaling means moving to a bigger instance class — more CPU cores and more memory — which helps when a single workload is CPU- or memory-bound. Horizontal scaling for reads means adding read replicas, copies of your primary database that stay in sync and can serve read-only queries, spreading read traffic across multiple machines.

Storage scaling is largely automatic today through Storage Auto Scaling, which grows your volume when free space drops below a threshold, avoiding the classic beginner mistake of a database that silently stops accepting writes because the disk filled up overnight. For connection-heavy applications — think a serverless function fleet that opens thousands of short-lived connections — RDS Proxy sits between your application and the database, pooling and reusing connections so the database engine itself is not overwhelmed simply by connection churn.

A Multi-AZ deployment keeps a synchronously replicated standby copy of your database running in a separate Availability Zone — effectively a different physical data center within the same region. Every write to the primary is confirmed on the standby before being acknowledged as successful, so the two copies never drift apart.

sequenceDiagram
    participant App as Application
    participant DNS as RDS Endpoint DNS
    participant Primary as Primary Instance AZ A
    participant Standby as Standby Instance AZ B
    App->>DNS: Connect using endpoint address
    DNS->>Primary: Route active traffic
    Primary-->>Standby: Synchronous replication of every write
    Note over Primary: Primary instance fails
    DNS->>Standby: DNS record automatically updated
    Standby-->>App: Now serving as new primary
        

If the primary instance fails — a hardware fault, an Availability Zone power event, or even a planned maintenance restart — RDS automatically promotes the standby to primary and updates the DNS endpoint to point at it, typically within under a minute. Your application experiences this as a brief connection drop and reconnect, not a multi-hour outage.

Amazon Aurora extends this idea further with storage that is automatically replicated six ways across three Availability Zones at the storage layer itself, which is one reason Aurora can achieve faster failover and higher durability guarantees than traditional Multi-AZ RDS engines.

Security on RDS operates in layers. At the network layer, your database instance lives inside a Virtual Private Cloud (VPC) and is typically placed in private subnets with no direct route to the public internet. A security group then acts as a stateful firewall, allowing traffic only from specific sources, such as your application servers.

At the data layer, RDS supports encryption at rest using AWS Key Management Service (KMS), encrypting the underlying storage, snapshots, and automated backups transparently. For data moving over the network, RDS supports encryption in transit using SSL/TLS certificates, protecting queries and results from interception.

Amazon CloudWatch automatically collects standard metrics from every RDS instance — CPU utilization, free storage space, read and write IOPS, and database connection counts — at no extra configuration cost. These metrics are the first place to look when something feels slow.

For deeper visibility, Enhanced Monitoring reports operating-system-level metrics (like per-process CPU and memory) at intervals as frequent as one second, while Performance Insights visualizes exactly which SQL queries are consuming the most database load, ranked by wait time — invaluable for tracking down a single slow query hiding among thousands of fast ones.

Database engine logs (error logs, slow query logs, audit logs) can also be exported directly to CloudWatch Logs, letting teams search and set alerts on log content the same way they would for application logs.

RDS offers several deployment shapes depending on availability and control requirements. A Single-AZ deployment is the simplest and cheapest, suited to development and testing. A Multi-AZ deployment adds the standby replica discussed earlier for production resilience. Multi-AZ with two readable standbys (available for some engines) allows both standby copies to serve read traffic instead of sitting idle.

Cross-region read replicas extend a copy of your database to an entirely different AWS region, useful for disaster recovery or serving read traffic closer to geographically distant users. For workloads with special licensing or customization needs, RDS Custom provides limited OS and engine-level access while retaining much of the automation RDS is known for.

On the cost side, On-Demand pricing charges by the hour with no commitment, while Reserved Instances offer significant discounts in exchange for a one- or three-year commitment — a common pattern once a workload’s baseline capacity is well understood.

A few recurring patterns show up again and again in well-run RDS deployments. Read/write splitting directs write queries to the primary and read queries to replicas, often through a lightweight routing layer in the application. Connection pooling via RDS Proxy smooths out connection spikes from serverless or highly concurrent applications. Blue/green deployments let teams create a fully synchronized staging environment, test an upgrade safely, and switch over with minimal downtime.