Amazon RDS

What RDS is

RDS runs a standard SQL engine — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, or Aurora — as a DB instance inside a VPC. AWS handles the host underneath: patching, backups, storage provisioning, and, if you turn it on, Multi-AZ failover. You still get a normal SQL endpoint, so the same client tools and drivers you’d use against a self-managed database work here. What you don’t get is OS-level access to the box — that’s a separate, narrower product called RDS Custom. It’s the default choice when an application needs real relational structure rather than a key-value or document model.

Because an RDS instance lives inside a subnet’s IP space in a VPC, Design Beaver models it as VPC-resident and validates as you draw which services can reach it and what each connection has to be set up to be correct.

When to use RDS (and when not to)

Reach for RDS when you need real SQL — joins, transactions, foreign keys — and you want automated backups, patching, and optional failover without managing the database host yourself. It’s the right call when the app already speaks a standard engine’s wire protocol and migrating off it isn’t practical, and when a production workload needs high availability through a Multi-AZ deployment.

Don’t reach for it when the workload is extremely high, unpredictable request-rate traffic that suits DynamoDB’s scaling model better. It’s also the wrong tool when you need direct OS-level access to the database host — that’s RDS Custom or a self-managed EC2 database, not standard RDS — or when you’re doing simple key-value lookups with no relational structure, where a managed NoSQL store is usually simpler and cheaper.

Variants: the engine, not the instance size

The real choice with RDS is the database engine, not the instance class. Open-source engines, commercial engines, and AWS’s own Aurora each change what you get and what you pay.

RDS pricing

You pay per DB-instance-hour, plus storage, optional provisioned IOPS, backup storage beyond the free allotment, and data transfer — and the engine you pick moves the number more than the instance size does.

How RDS connects to other services

RDS is a target, not an initiator — EC2 and Lambda connect into it. What matters on each of those edges is the requirement that makes it actually work: same-VPC placement, a security-group-scoped inbound rule on the DB port, and — for Lambda — a proxy in front. Design Beaver models each connection so it knows what belongs on it.

• ←EC2

  An EC2 instance (e.g. running an app server) connects to RDS as its application database — the canonical two-tier web app pattern

• ←Lambda

  A Lambda function connects to RDS as its application database, typically for a serverless API backed by a relational store

• ←ECS

  A containerized application running as an ECS task (on Fargate or EC2) connects to RDS as its relational database — the container equivalent of the EC2 app-tier-plus-managed-database pattern

• ←App Runner

  An AWS App Runner service connects to a private RDS database as its data layer, reaching it over the VPC through an App Runner VPC connector

• ←RDS Proxy

  RDS Proxy maintains a warm pool of connections to this DB instance and routes client queries through it, smoothing bursty connection churn from serverless/autoscaling clients and speeding failover

What RDS can’t connect to

Some edges look reasonable on a canvas but aren’t real AWS integrations — a database isn’t a CloudFront origin, a Route 53 target, or an ALB backend. Design Beaver flags them instead of letting you draw a diagram that can’t be built.

• ✕S3

  RDS does not connect out to S3 as an architectural edge — there's no native direct integration in that direction. Data movement between them (e.g. Aurora's S3 import/export or MySQL's S3 integration for loading/saving data) is an engine feature invoked by SQL/API calls, not a drawable connection.

• ✕CloudFront

  CloudFront is an HTTP(S) edge cache/CDN in front of an origin — it has no direct database client relationship; RDS is never a CloudFront origin.

• ✕Route 53

  Not a valid DNS alias target and not something a domain resolves to directly — Route 53 points browsers at HTTP(S) origins like CloudFront, S3, ALB, or API Gateway, never at a database instance.

• ✕DynamoDB

  Peer database services, not architecturally wired to each other — an application may use both, but there's no native direct connection between an RDS instance and a DynamoDB table.

• ✕Application Load Balancer

  ALB is a layer-7 HTTP(S) load balancer that routes to registered targets over HTTP(S) — it has no database wire protocol client relationship and never has an RDS instance as a backend target. The EC2 tier behind the ALB connects to RDS, not the ALB itself.

Anti-patterns Design Beaver catches

These are the RDS mistakes that pass a diagram review but break under load or expose the database — the ones the validation engine flags as you draw.

Gotchas that bite in production

• Multi-AZ is not a read-scaling feature. A Multi-AZ DB instance deployment has one standby that exists purely for failover — it does not serve read traffic. Read replicas are the separate mechanism for read scaling. Don’t conflate the two. (A Multi-AZ DB cluster deployment, the newer two-standby variant, can serve reads from its standbys, but that’s a distinct configuration.)
• Lambda → RDS without RDS Proxy is a known failure mode. Lambda can scale to hundreds or thousands of concurrent execution environments in seconds, each holding its own connection. RDS has a fixed connection limit, so a spike can exhaust it and throw connection errors across the whole application. RDS Proxy sits between Lambda and RDS, pooling a much smaller number of real connections, and it preserves app-side connections through a Multi-AZ failover.
• EC2 → RDS deliberately skips RDS Proxy. An EC2 app server holds a small, steady pool of long-lived connections rather than opening a new one per invocation, so it doesn’t hit the same connection-exhaustion problem. If you see EC2 → RDS with no proxy in front, that’s the expected shape, not a missing piece.
• Use security groups, not raw CIDR blocks, to allow app-tier access. The RDS security group’s inbound rule should reference the EC2 or Lambda security group directly rather than an IP range — that’s what keeps the rule working as instances are replaced.
• A DB subnet group needs subnets in at least two Availability Zones, even for a Single-AZ deployment. That’s what lets you convert to Multi-AZ later without rebuilding the subnet group.

Further reading

• Official AWS documentation
• Why we built a validation engine