paulserban.eu

Writing Edition

Paul Serban

Writing, snippets & book notes

Vol. 2026

AWS RDS Fundamentals: Architecture, Patterns, and Pitfalls Every Engineer Should Know

A practical guide to how Amazon RDS actually works under the hood, and the decisions that separate resilient OLTP systems from fragile ones

Introduction

Amazon RDS is one of the most widely adopted managed database services in cloud computing, and also one of the most misunderstood. Engineers reach for it constantly for OLTP (online transaction processing) workloads - the everyday reads and writes behind web applications, order systems, user accounts, and anything else that needs consistent, transactional access to relational data - but many teams treat it as a black box that "just handles the database part." That framing causes real problems, because RDS is not a fully abstracted database-as-a-service in the way something like DynamoDB is. It is, at its core, a managed wrapper around Amazon EC2 compute and Amazon EBS storage, and every operational characteristic of EC2 and EBS - instance types, storage throughput, failover behavior, network limits - still applies to the database sitting on top of them.

This article is written for engineers and technical leads who already know what a relational database is and want a clear, accurate picture of how RDS is actually built, so they can make good decisions about instance sizing, storage configuration, high availability, and read scaling instead of guessing. We'll walk through the underlying architecture, work through practical examples using the AWS SDK, and spend real time on the anti-patterns that quietly cause outages and cost overruns - because RDS is forgiving enough to work by default, and unforgiving enough to fail expensively when its underlying compute-and-storage model is ignored.

Context: Why RDS Exists and What Problem It Actually Solves

Before RDS existed in its current form, running a production relational database meant provisioning your own server (or EC2 instance), installing the database engine, configuring replication by hand, writing your own backup scripts, and building your own failover automation. None of that work is specific to your application - it's the same undifferentiated operational burden regardless of whether you're running an e-commerce platform or a logistics system. RDS's core value proposition is taking that operational layer - patching, backups, failover orchestration, monitoring integration - and making it a managed, API-driven service, while still giving you a real, unmodified relational database engine underneath: MySQL, PostgreSQL, MariaDB, Oracle, or SQL Server (Amazon Aurora is a related but architecturally distinct service, with its own storage layer, and is often discussed alongside RDS but is not the same underlying system).

The OLTP framing in the subject matters because it sets expectations for what RDS is good at and what it isn't. OLTP workloads are characterized by many small, fast, transactional operations - inserting a row, updating a balance, looking up a record by primary key - as opposed to OLAP (online analytical processing) workloads, which run large aggregate queries across huge datasets for reporting and analytics. RDS engines are general-purpose relational databases tuned for transactional consistency and moderate query complexity, not for scanning billions of rows for a quarterly report. Teams that push heavy analytical workloads onto an RDS instance meant to serve live application traffic are solving the wrong problem with the wrong tool, and it usually shows up first as degraded latency on the transactional queries that actually matter to end users.

The architectural detail that trips up the most engineers, and the one explicitly called out in this article's brief, is that an RDS instance is not a serverless abstraction - it runs on an actual EC2 instance whose class and size you choose at launch time, and its data lives on Amazon EBS volumes, the same block storage product backing ordinary EC2 servers. This means the performance ceiling of your database is directly a function of the same two levers you'd tune for any EC2-based system: compute (vCPU, memory, network bandwidth tied to instance class) and storage (EBS volume type, provisioned IOPS, throughput). Once that clicks, most of RDS's operational behavior - why resizing an instance requires a reboot in many configurations, why storage autoscaling exists, why some instance classes support more IOPS than others - stops being a surprise and starts being a design input.

Core Architecture: Instances, Storage, and Multiple Databases per Instance

An RDS DB instance is the fundamental unit you provision - it corresponds to one running database engine process (or, for SQL Server and Oracle in certain licensing models, one engine installation) backed by one EC2 instance and one primary EBS volume (or a small set of volumes, depending on engine and configuration). Instance classes follow the same families used elsewhere in EC2: general-purpose classes (like the db.m family) for balanced workloads, memory-optimized classes (like db.r and db.x families) for workloads with large working sets or heavy caching needs, and burstable classes (db.t family) for development, staging, or genuinely low, spiky traffic. Choosing wrong in either direction has a direct cost: undersizing produces CPU credit exhaustion on burstable classes or memory pressure that shows up as slow query plans and excessive disk I/O for temp operations, while oversizing simply wastes budget on capacity the workload never touches.

A detail that surprises engineers coming from a single-tenant mental model is that one DB instance can, and usually does, host multiple independently created databases (in MySQL and MariaDB terms) or multiple databases within a single instance (in PostgreSQL, where the equivalent grouping concept is a bit different, since PostgreSQL databases within one instance are more isolated from each other than schemas are). This matters for two practical reasons: it means a single instance can serve several application services or environments without provisioning entirely separate infrastructure, and it means the instance's compute and storage capacity - the EC2 and EBS resources underneath - are shared across every database sitting on that instance. A noisy-neighbor problem between two databases on the same RDS instance is a real, self-inflicted risk if teams aren't deliberate about instance boundaries between workloads with genuinely different performance profiles or blast-radius requirements.

Deep Technical Explanation: High Availability, Read Scaling, and Storage Behavior

RDS's headline reliability feature is Multi-AZ deployment, and it's worth understanding precisely what it does rather than treating it as a magic checkbox. In a Multi-AZ configuration, RDS provisions a standby replica in a different Availability Zone and keeps it synchronized via synchronous, physical-level replication - not application-level query replication. If the primary instance fails, becomes unreachable, or undergoes maintenance, RDS automatically fails over to the standby by updating the DNS endpoint your application already connects to, typically completing within roughly one to two minutes depending on engine and workload state. Critically, the standby in a classic Multi-AZ setup is not readable - it exists purely for failover, which is a common point of confusion for engineers who assume Multi-AZ also gives them read scaling for free. It does not; that's a separate feature.

Read replicas solve the read-scaling problem instead, and they work on a fundamentally different mechanism: asynchronous, engine-native replication (binlog replication for MySQL/MariaDB, for example). You can create one or more read replicas of a DB instance, point read-heavy portions of your application traffic at them, and offload query load from the primary. Because replication is asynchronous, replicas can lag behind the primary under heavy write load or replica-side query load - a fact that matters enormously for any code path that writes data and then immediately reads it back, since a naive "write then read from replica" pattern can read stale or missing data. Read replicas can also be promoted to standalone instances, which is a common disaster-recovery and cross-region resilience pattern, and in supported engine/region combinations, replicas can even be created across AWS regions for geographic read distribution or DR purposes.

Storage behavior follows directly from the EBS foundation described earlier. RDS storage comes in a few types mirroring EBS volume types - General Purpose SSD (gp2/gp3) for balanced cost and performance, and Provisioned IOPS SSD (io1/io2) for consistently high-throughput, latency-sensitive workloads - and each carries its own IOPS and throughput ceiling, partly determined by the volume type and size, and partly gated by what the chosen instance class can actually drive through its network-attached storage path. RDS also supports storage autoscaling, which automatically grows the underlying volume when free space drops below a configured threshold, removing one of the more painful manual operational tasks (running out of disk space on a production database) at the cost of needing to actively monitor storage growth trends rather than assuming autoscaling alone is a substitute for capacity planning.

Practical Implementation Examples

Provisioning and inspecting RDS resources programmatically is common enough - via Infrastructure as Code, operational tooling, or CI/CD pipelines - that it's worth seeing what that looks like in practice rather than only through the console. The example below uses boto3, the AWS SDK for Python, to provision a Multi-AZ PostgreSQL instance with sensible defaults for a production OLTP workload, then to check its status before an application deployment proceeds - a pattern common in deployment pipelines that need to confirm database readiness before rolling out application code that depends on it.

import boto3
from botocore.exceptions import ClientError

rds = boto3.client("rds", region_name="us-east-1")

def create_production_instance():
    try:
        response = rds.create_db_instance(
            DBInstanceIdentifier="orders-service-prod",
            DBInstanceClass="db.r6g.large",       # memory-optimized, ARM Graviton
            Engine="postgres",
            EngineVersion="16.3",
            MasterUsername="app_admin",
            ManageMasterUserPassword=True,          # delegate secret to Secrets Manager
            AllocatedStorage=100,
            StorageType="gp3",
            Iops=6000,
            MultiAZ=True,
            BackupRetentionPeriod=7,
            DeletionProtection=True,
            VpcSecurityGroupIds=["sg-0123456789abcdef0"],
            DBSubnetGroupName="orders-service-private-subnets",
            EnableCloudwatchLogsExports=["postgresql", "upgrade"],
            StorageEncrypted=True,
        )
        return response["DBInstance"]["DBInstanceIdentifier"]
    except ClientError as err:
        raise RuntimeError(f"Failed to create RDS instance: {err}") from err


def wait_for_available(db_identifier: str, timeout_seconds: int = 900):
    waiter = rds.get_waiter("db_instance_available")
    waiter.wait(
        DBInstanceIdentifier=db_identifier,
        WaiterConfig={"Delay": 15, "MaxAttempts": timeout_seconds // 15},
    )
    description = rds.describe_db_instances(DBInstanceIdentifier=db_identifier)
    instance = description["DBInstances"][0]
    return {
        "status": instance["DBInstanceStatus"],
        "endpoint": instance["Endpoint"]["Address"],
        "multi_az": instance["MultiAZ"],
    }

Note the use of ManageMasterUserPassword=True, which delegates credential storage to AWS Secrets Manager rather than requiring the caller to pass a plaintext password - this is the current recommended approach for new RDS instances and removes an entire category of credential-leakage risk from provisioning code. The StorageEncrypted=True and DeletionProtection=True flags are similarly non-negotiable defaults for anything touching production data; both are cheap to set at creation time and expensive to retrofit later (encryption in particular cannot be enabled on an existing unencrypted instance without a snapshot-and-restore cycle).

The second example shows a Node.js/TypeScript Lambda function connecting through RDS Proxy, a managed connection-pooling layer that sits between application code and the database instance. This pattern matters specifically for serverless or highly concurrent compute, where each Lambda invocation opening a direct database connection can quickly exhaust the instance's maximum connection limit under load - a very common production incident in serverless architectures backed by RDS.

import { Client } from "pg";
import { Signer } from "@aws-sdk/rds-signer";

const signer = new Signer({
  region: "us-east-1",
  hostname: process.env.RDS_PROXY_ENDPOINT!, // proxy endpoint, not the instance endpoint
  port: 5432,
  username: "app_admin",
});

export async function handler(event: { orderId: string }) {
  const token = await signer.getAuthToken();

  const client = new Client({
    host: process.env.RDS_PROXY_ENDPOINT,
    port: 5432,
    user: "app_admin",
    password: token, // IAM-generated token, not a static password
    database: "orders",
    ssl: { rejectUnauthorized: true },
  });

  await client.connect();
  try {
    const result = await client.query(
      "SELECT id, status, total_cents FROM orders WHERE id = $1",
      [event.orderId]
    );
    return result.rows[0] ?? null;
  } finally {
    await client.end(); // proxy pools the underlying connection; this doesn't tear down the real DB connection
  }
}

Connecting through the proxy endpoint rather than the instance endpoint, combined with IAM database authentication instead of a static password, is the pattern AWS documents for exactly this Lambda-to-RDS scenario, and it addresses two problems simultaneously: connection exhaustion under concurrent invocations, and long-lived static credentials sitting in environment variables or Secrets Manager that would otherwise need manual rotation.

Anti-Patterns and Pitfalls

The single most common RDS anti-pattern is treating storage and instance sizing as an afterthought instead of a deliberate, revisited decision. Teams frequently pick a db.t3.medium for a proof of concept, ship it to production unchanged, and then wonder why the database throttles under real traffic - because burstable instance classes accumulate CPU credits during idle periods and spend them under load, and a sustained traffic increase will exhaust those credits and fall back to baseline performance at exactly the worst moment. Similarly, provisioning gp2 storage without accounting for its IOPS-scales-with-volume-size behavior, or under-provisioning io1/io2 IOPS relative to actual query patterns, produces a database that looks fine in staging and falls over in production the first time a batch job or reporting query runs concurrently with normal traffic.

A second widespread pitfall is assuming Multi-AZ eliminates the need for read replicas, or the reverse - assuming read replicas provide the failover protection Multi-AZ provides. These are different tools solving different problems, and conflating them leads to architectures that are either paying for standby capacity with no read-scaling benefit, or architectures that have no automated failover at all because someone assumed the read replica setup already covered high availability. A related mistake is routing read traffic to a replica without any tolerance for replication lag in the application logic - a checkout flow that writes an order and immediately reads it back from a lagging replica to render a confirmation page is a textbook case of a consistency bug introduced purely by infrastructure topology, not application logic.

A third and often expensive anti-pattern is using RDS as a direct target for OLAP-style analytical queries against a live OLTP instance, exactly the confusion the "Context" section above warned against. Nightly batch jobs, ad hoc analyst queries, or BI tool connections pointed straight at a production RDS instance compete for the same CPU, memory, and I/O budget as live application traffic, and because RDS instances share compute and storage the way any EC2/EBS pair does, there's no magic isolation between "the analytics query" and "the checkout request" running at the same moment. The fix is almost always to route analytical workloads to a read replica dedicated to that purpose, a data warehouse fed by CDC or ETL, or a service purpose-built for OLAP, rather than accepting periodic latency spikes on the primary as an unavoidable cost of doing business.

Finally, many teams underinvest in testing failover itself. Multi-AZ automatic failover is a real AWS-managed capability, but application code still needs to handle a DNS-level endpoint change gracefully - connection pools that don't detect a stale connection after failover, or database drivers configured with aggressive connection reuse and no retry logic, can turn an automated one-to-two-minute RDS failover into a much longer application-level outage. RDS supports a reboot-db-instance call with a force-failover option specifically so teams can exercise this path deliberately in a lower environment, and skipping that exercise is a common reason failovers go worse than expected the first time they happen for real.

Best Practices

Start instance and storage sizing from actual measured workload characteristics rather than defaults, and revisit that sizing on a recurring cadence rather than treating the initial choice as permanent. CloudWatch metrics for CPU utilization, FreeableMemory, ReadIOPS/WriteIOPS, and DiskQueueDepth are the practical signals for whether an instance class and storage configuration still fit the workload, and Performance Insights (a feature available on most RDS engines) gives query-level visibility into what's actually consuming database time, which is far more actionable than instance-level metrics alone when diagnosing a specific slow query.

Separate high-availability concerns from read-scaling concerns explicitly in your architecture, and document which one each piece of infrastructure is for. Enable Multi-AZ for any workload where downtime has a real cost, use read replicas deliberately for read-heavy paths that can tolerate eventual consistency, and make sure the application layer is written with replication lag as an explicit, handled case rather than an implicit assumption of immediate consistency.

Automate credential and encryption hygiene at creation time rather than retrofitting it later. Enabling storage encryption, using ManageMasterUserPassword or an equivalent Secrets Manager integration, and enforcing IAM database authentication for machine-to-machine access (particularly from Lambda or containerized workloads, as shown in the RDS Proxy example) all cost nothing to set up correctly from the start and are disproportionately expensive to add after the fact, since encryption specifically requires a full snapshot-and-restore migration to change on an existing instance.

Analogies and Mental Models

The most useful mental model for RDS is an apartment building with a managed superintendent. You still choose the unit size (the instance class), and the building's plumbing and electrical capacity (the EBS volume's IOPS and throughput) still determine how much your unit can actually handle day to day - the superintendent (AWS's management layer) doesn't change those physical constraints, they just handle the maintenance, security patrols, and emergency response (patching, backups, failover) so you don't have to hire your own building staff. Engineers who forget they still chose a unit size are the ones surprised when the plumbing can't keep up with a party they didn't plan for - the equivalent of a traffic spike hitting undersized storage IOPS.

Multi-AZ versus read replicas is best understood through a backup generator versus a second staffed location analogy. A backup generator (Multi-AZ standby) sits idle, doing nothing useful day to day, existing purely so that if the main power fails, the building switches over automatically with minimal disruption - it doesn't help you serve more customers on a normal day. A second staffed location (a read replica) is actively open and taking some of the foot traffic off the main location, which helps with load, but if you close the main location, the second location doesn't automatically become the primary one without someone deciding to promote it and redirecting everyone there. Conflating the two - expecting the generator to serve customers, or expecting the second location to kick in automatically as the new primary during an outage - is exactly the confusion that shows up repeatedly in real RDS architectures.

The 80/20 Insight

A small number of decisions account for most of the operational outcomes teams experience with RDS, and they're worth internalizing even if nothing else in this article sticks. First: remember at all times that RDS is EC2 plus EBS with a management layer on top, which means instance class and storage type are real, consequential engineering decisions, not defaults to accept and forget. Second: Multi-AZ and read replicas solve different problems - availability and read scaling, respectively - and most architectural confusion about RDS traces back to conflating the two or assuming one implies the other.

Third: replication, whichever kind, is either synchronous-but-not-readable (Multi-AZ standby) or readable-but-asynchronous (replicas), and there is no free option that is both instantly consistent and independently readable - application code has to be written with one of those trade-offs explicitly in mind. Getting these three ideas right up front resolves the majority of the sizing mistakes, availability gaps, and consistency bugs that show up in RDS-backed systems in production.

Key Takeaways

For engineers who want to apply this immediately, the following five actions cover most of the ground discussed above:

Conclusion

RDS earns its popularity honestly - it removes a large amount of genuinely undifferentiated operational work from running a relational database in production, and for the overwhelming majority of OLTP workloads, it's the right default choice over self-managed database servers. But "managed" does not mean "abstracted away," and the engineers who get the most reliable, cost-effective results from RDS are the ones who keep the underlying EC2-and-EBS reality in view: instance class determines compute ceiling, EBS volume type and provisioned IOPS determine storage ceiling, and every higher-level feature - Multi-AZ, read replicas, storage autoscaling - is built on top of that foundation rather than replacing it.

The pitfalls covered here - undersized burstable instances, conflating availability with read scaling, routing analytical load onto a transactional primary, and skipping failover testing - are not exotic failure modes. They're the ordinary, recurring ways teams misuse a well-designed service by not fully understanding what it's actually built from. Treating instance sizing, storage configuration, and the specific guarantees of Multi-AZ versus read replicas as deliberate architectural decisions, rather than defaults to accept once and forget, is what separates RDS deployments that quietly hold up under real production load from the ones that generate a 2 a.m. page the first time traffic genuinely spikes.

References

Resources