Introduction

This topic is easy to misunderstand because the phrase "RDS outside VPC" is not quite accurate in modern AWS. RDS databases live in a VPC, but they may expose a public endpoint. The real question is whether a Lambda function that is not attached to your VPC can connect to that database safely and reliably.

The Networking Rule That Matters

A Lambda function that is not configured for your VPC can reach public internet endpoints. It cannot reach private IP addresses inside your VPC. That means:

• private RDS endpoint: not reachable from a non-VPC Lambda
• publicly accessible RDS endpoint: reachable over the internet path

So the answer is "yes, but only if the database is publicly accessible." The more important follow-up is that this is usually not the design you want.

Why Public RDS Access Is Usually a Bad Trade

If your Lambda is outside the VPC, the database security group cannot simply allow traffic from the Lambda's security group, because the function is not in that VPC. You end up opening the database to broader network ranges, relying more heavily on credentials and TLS, and making the attack surface larger than necessary.

For that reason, the common production design is:

1. place the RDS instance on private subnets
2. attach the Lambda function to the same VPC
3. allow database traffic by security group reference
4. store credentials in AWS Secrets Manager

That keeps the database off the public internet and makes the network path much easier to reason about.

When a Non-VPC Lambda Can Work

A non-VPC Lambda can connect if all of these are true:

• the RDS instance is marked publicly accessible
• the route tables and network ACLs allow traffic
• the database security group allows inbound traffic on the DB port
• the Lambda code uses the public endpoint

Here is a simple Python example using PostgreSQL:

1import os
2import psycopg
3
4
5def handler(event, context):
6    conn = psycopg.connect(
7        host=os.environ["DB_HOST"],
8        port=5432,
9        dbname=os.environ["DB_NAME"],
10        user=os.environ["DB_USER"],
11        password=os.environ["DB_PASSWORD"],
12        sslmode="require",
13    )
14
15    with conn.cursor() as cur:
16        cur.execute("select current_database()")
17        row = cur.fetchone()
18
19    conn.close()
20    return {"database": row[0]}

This works only if DB_HOST points to the public RDS endpoint and the network controls allow the connection.

The Private Option Is Better

If the database should stay private, move the Lambda into the VPC instead of moving the database out to the internet. A VPC-connected Lambda can connect to a private RDS instance using internal addresses and security groups.

That design has one important consequence: once Lambda is attached to private subnets, it no longer gets default outbound internet access. If the function also needs to call public APIs, you usually need a NAT gateway or another controlled egress path.

In practice, the architecture often becomes:

• Lambda in private subnets
• RDS in private subnets
• security group rule from Lambda to RDS
• Secrets Manager for credentials
• optional RDS Proxy for connection management

Use RDS Proxy When Connections Matter

Connection storms are common with Lambda because many invocations may start in parallel. Even if the network path is correct, opening too many direct database connections can overwhelm the instance.

RDS Proxy sits between Lambda and the database, pools connections, and reduces load on the DB. It is especially useful for spiky workloads and smaller database classes.

That does not replace VPC design, but it often makes the Lambda-to-RDS pattern much more stable.

Common Pitfalls

• Treating "publicly accessible" as equivalent to "good for production." It only means the endpoint is reachable.
• Expecting a Lambda outside the VPC to connect to a private RDS endpoint.
• Opening the database security group too broadly because Lambda is not inside the VPC.
• Forgetting that VPC-connected Lambda loses default internet egress unless you add a NAT path.
• Ignoring connection limits and then blaming the network when the real issue is too many concurrent DB sessions.

Summary

• RDS is still inside a VPC; the real distinction is private endpoint versus public endpoint.
• A Lambda outside your VPC can reach only a publicly accessible RDS endpoint.
• The safer design is usually to attach Lambda to the VPC and keep RDS private.
• Use security groups, Secrets Manager, and TLS instead of exposing the database broadly.
• Consider RDS Proxy when Lambda concurrency creates too many database connections.