> ## Documentation Index
> Fetch the complete documentation index at: https://midplane.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Connect Amazon RDS or Aurora to your AI agent
> Point an AI agent at RDS or Aurora Postgres through Midplane — network reachability, TLS with the RDS CA, and choosing the right endpoint.
RDS is the case where *where Midplane runs* matters most. A managed Postgres inside a private VPC is unreachable from anything outside it by design — which is usually the point. This page covers both answers: making an RDS instance reachable from Midplane Cloud, and running Midplane inside the VPC when it shouldn't be.
Once connected, your agent reaches RDS only through Midplane: every statement is parsed, checked against [policy](/docs/policies/overview), and written to the [audit trail](/docs/concepts/audit-trail) before it runs.
## Pick where Midplane runs
Midplane Cloud connects over the public internet, so this path fits an instance that **already has a public endpoint** — commonly a dev or staging instance. It requires all of:
* **Publicly accessible** set to **Yes** on the instance (**Connectivity & security** in the RDS console).
* The instance's subnets are **public** — a route table with a route to an internet gateway.
* A **security group** inbound rule allowing TCP on your database port.
**Don't open a security group to `0.0.0.0/0` to make this work.** Midplane Cloud doesn't publish a fixed egress IP range, so there's no narrower CIDR that would admit Midplane and nothing else — exposing the instance to every address on the internet is the only rule that would work, and it isn't worth it for a database you care about.
For an instance that isn't already public, use the self-host tab. It's the supported answer, and the database stays where it is.
A private instance isn't blocked at save time, since the connection string is only shape-checked. It fails when an agent first queries, and **Test connection** reports `Could not connect. Check the host, port, and that the database accepts connections from the internet.`
Run Midplane on a host inside the VPC — EC2, ECS, or EKS — and the instance stays private. Nothing about the network changes: Midplane reaches the RDS endpoint over the same private DNS name your application already uses, and the security group rule names Midplane's security group rather than a public CIDR.
You get the same engine, policy model, dashboard, and audit trail as Cloud. See [deploy](/docs/self-host/deploy) for the setup, and [operations](/docs/self-host/operations) for running it.
This is the right shape when your compliance posture says the database is never publicly routable — the boundary you already have stays intact, and the agent's access sits inside it.
If running Midplane yourself isn't workable for your team, email [support@midplane.ai](mailto:support@midplane.ai) and tell us about your setup — see [connect your database](/docs/connect/overview#a-host-midplane-can-reach).
## Use the right endpoint
RDS and Aurora hand you more than one hostname, and the choice is a safety control in its own right.
| Endpoint | When to use it |
| ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Aurora reader endpoint** | An agent that only reads. The reader physically rejects writes, so a policy gap alone isn't enough to modify anything. |
| **RDS read replica** | Same idea outside Aurora — give the agent the replica's own endpoint. |
| Instance or cluster writer endpoint | Only when the agent genuinely needs to write. |
Pointing an analysis agent at a reader is the cheapest safety win available here: [table access](/docs/concepts/table-access) is your policy ceiling, and the replica is a second, physical floor underneath it.
## Create a least-privilege role
Don't use the master user — it holds `rds_superuser`, and Midplane operates on top of whatever privileges the connection carries. Connect as the master user once, then:
```sql theme={null}
CREATE ROLE midplane LOGIN PASSWORD 'a-strong-password';
GRANT CONNECT ON DATABASE app TO midplane;
GRANT USAGE ON SCHEMA public TO midplane;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO midplane;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO midplane;
```
**IAM database authentication doesn't fit.** IAM auth issues a token that expires after 15 minutes, and Midplane stores one encrypted connection string per database. Use password authentication for the Midplane role, and rotate it from the [credential pane](/docs/cloud/projects#rotate-a-database-credential) when you need to.
## TLS
Check `rds.force_ssl` in your parameter group. Set to `1`, RDS rejects any connection that isn't encrypted — so a connection string without `sslmode` will fail at connect time rather than silently downgrade.
```
postgres://midplane:PASSWORD@mydb.abc123.eu-central-1.rds.amazonaws.com:5432/app?sslmode=require
```
`sslmode=require` encrypts without verifying the certificate (libpq semantics, since engine `0.15.0`). To verify against Amazon's CA, download the [global RDS trust bundle](https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem) and point at it:
```
...?sslmode=verify-full&sslrootcert=/path/to/global-bundle.pem
```
On Cloud there's no filesystem to place that bundle on, so `sslmode=require` is the practical setting there; self-host can mount it and use `verify-full`. See [connecting to your Postgres](/docs/resources/troubleshooting#connecting-to-your-postgres) for the failure modes.
## Next steps
Run Midplane inside your own VPC.
Grant the reads and writes your agent actually needs.