How to Connect to a Private Amazon RDS Instance Securely

Simple explanation

• An RDS instance in a private subnet has no internet-facing route. Nothing on the internet can reach it directly, regardless of passwords. That is the goal.
• Application servers on EC2 or ECS in the same VPC connect directly over private IP. No tunnel, no proxy needed. Just a security group rule.
• Developers on a laptop use Session Manager port forwarding. It creates an encrypted tunnel through an EC2 instance in the VPC, with no SSH keys, no open inbound ports, and no bastion host to maintain.
• Lambda functions and serverless workloads benefit from RDS Proxy, which pools database connections so hundreds of concurrent Lambda invocations do not exhaust the connection limit.
• Always enforce TLS. Traffic inside a VPC is not encrypted at the application layer by default. TLS protects credentials and query data in transit.
• Store credentials in Secrets Manager or use IAM database authentication. Hardcoded passwords in environment variables are a common source of leaks.

How secure RDS connectivity works

When you create an RDS instance, it gets a DNS endpoint like mydb.xxxx.eu-west-2.rds.amazonaws.com. That hostname resolves to a private IP address inside your VPC. If the instance lives in a private subnet with no internet gateway route, that address is only reachable from inside the VPC.

Four things control who can connect:

Private subnet placement means the database has no internet-facing route. Even if someone knows the endpoint hostname, it does not resolve to a reachable address from the public internet. See Subnets in AWS: Public, Private, and Isolated for how subnet types differ.

Security groups act as a stateful firewall attached to the RDS instance. A security group rule on the RDS instance should allow inbound traffic on the database port (5432 for PostgreSQL, 3306 for MySQL) only from the security group attached to your application servers. Not from a CIDR range. Not from the internet. This is called a security group reference: when a server joins the application security group, it automatically gains database access. When it leaves, access is revoked.

TLS/SSL encrypts the connection between the client and the database. TLS is the modern successor to SSL; you will see both terms used, but new connections use TLS. Without it, credentials and query results travel in plaintext across your network.

Authentication controls who is allowed in after the network permits the connection. This is either a database username and password, or short-lived IAM tokens generated on demand.

Which access pattern should you choose?

Direct connection from EC2 or ECS in the same VPC#

The simplest pattern and the right default for application traffic. Your EC2 instance or ECS task runs in the same VPC as RDS. Add one security group rule that allows the application tier’s security group to reach the database port. No tunnels, no proxies, no extra components.

# Allow the application security group to connect to RDS on port 5432 (PostgreSQL)
aws ec2 authorize-security-group-ingress \
  --group-id sg-rds-id \
  --protocol tcp \
  --port 5432 \
  --source-group sg-app-tier-id

The RDS endpoint resolves to a private IP within the VPC. Your application connects using the standard hostname with no special routing needed:

psql -h mydb.xxxx.eu-west-2.rds.amazonaws.com -U dbadmin -d myappdb

For MySQL, the port changes to 3306; the pattern is identical. See Running MySQL on Amazon RDS or PostgreSQL on Amazon RDS for full setup guides.

Session Manager port forwarding from your laptop#

AWS Systems Manager Session Manager lets you forward a local port to the RDS endpoint through an EC2 instance in your VPC. No SSH keys, no bastion host, no inbound security group rules needed.

Requirements: an EC2 instance in the same VPC as RDS with the SSM agent installed, an IAM instance profile that includes AmazonSSMManagedInstanceCore, and your IAM user or role having ssm:StartSession permission.

# Start a port forwarding session through the EC2 instance to the RDS endpoint
aws ssm start-session \
  --target i-0abc1234def56789 \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{
    "host": ["mydb.xxxx.eu-west-2.rds.amazonaws.com"],
    "portNumber": ["5432"],
    "localPortNumber": ["5433"]
  }'

# In a second terminal, connect via localhost
psql -h localhost -p 5433 -U dbadmin -d myappdb

Session start and end events are recorded in AWS CloudTrail, giving you an auditable record of who initiated each session. The content of your queries is not captured.

Bastion host / SSH tunnel#

A bastion host (also called a jump box) is a small EC2 instance in a public subnet. Developers SSH into it and from there can reach private resources inside the VPC. For local database access, you create an SSH tunnel from your laptop through the bastion:

# Tunnel local port 5433 through the bastion to the RDS endpoint on port 5432
ssh -L 5433:mydb.xxxx.eu-west-2.rds.amazonaws.com:5432 \
    -i ~/.ssh/my-keypair.pem \
    ec2-user@bastion-public-ip \
    -N

# Connect via the local tunnel
psql -h localhost -p 5433 -U dbadmin -d myappdb

The RDS security group needs an inbound rule from the bastion’s security group. Not from your IP directly.

RDS Proxy#

RDS Proxy is a managed connection pooler that sits between your application and the RDS instance. Applications connect to the proxy endpoint; the proxy maintains a pool of persistent database connections and multiplexes application connections across them.

RDS Proxy is most valuable when:

• Lambda functions open a new database connection on every invocation. With high concurrency, this exhausts the RDS connection limit fast. Proxy multiplexes hundreds of Lambda connections over a small pool of database connections.
• Workloads have sudden connection spikes that the database cannot absorb gracefully.
• Multi-AZ failover transparency matters. Applications reconnect to the proxy endpoint, and the proxy reroutes to the new primary without the application needing to handle reconnection logic.

# Connect to the proxy endpoint instead of the RDS endpoint directly
psql -h myapp-proxy.proxy-xxxx.eu-west-2.rds.amazonaws.com \
     -U dbadmin -d myappdb

For serverless VPC access patterns, RDS Proxy is often the right default when Lambda functions need database access.

On-prem or corporate network access via VPN or Direct Connect#

If your team connects from a corporate network or on-premises data centre, you can extend a private network path to AWS using AWS Site-to-Site VPN or AWS Direct Connect. Both give you private routing to the RDS endpoint without exposing it to the internet.

Once in place, traffic flows between your on-premises network and the VPC over the private connection. The RDS security group needs an inbound rule from the CIDR range of your on-premises network.

When to use each option

App server on EC2 or ECS in the same VPC. Use direct private connection with a security group reference. Nothing else needed.

Developer laptop. Use Session Manager port forwarding. No SSH keys, no exposed instance, and session events are auditable in CloudTrail.

Legacy admin workflows where Session Manager is unavailable. Use a bastion host with an SSH tunnel. Restrict the bastion’s inbound rules to known IP ranges and keep it patched.

Lambda or other serverless workloads. Add RDS Proxy in front of the RDS instance. Lambda’s concurrency model creates many short-lived connections; Proxy ensures these do not exhaust the database connection limit.

On-premises or corporate network access. Set up Site-to-Site VPN or Direct Connect and route to the RDS endpoint over the private VPC path.

Session Manager vs bastion host

For teams that have not already invested in bastion infrastructure, Session Manager is the better default in almost every case.

RDS Proxy vs direct connections

For EC2 or ECS applications with a fixed number of long-running instances, direct connections with application-level pooling are simpler and sufficient. RDS Proxy solves a specific problem: connection exhaustion from serverless or highly concurrent workloads.

Enforce SSL/TLS

TLS encrypts the connection between your client and the database. Even inside a VPC, this matters: it protects credentials and query data from other services with network visibility, and satisfies compliance requirements that mandate encryption in transit.

Download the RDS certificate bundle and configure your database client to require TLS with full certificate verification:

# Download the global RDS certificate bundle
curl -o /etc/ssl/certs/rds-global-bundle.pem \
  https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

# PostgreSQL: enforce TLS with certificate verification
psql "host=mydb.xxxx.eu-west-2.rds.amazonaws.com \
      sslmode=verify-full \
      sslrootcert=/etc/ssl/certs/rds-global-bundle.pem \
      user=dbadmin dbname=myappdb"

# MySQL: enforce TLS with certificate verification
mysql --ssl-ca=/etc/ssl/certs/rds-global-bundle.pem \
      --ssl-verify-server-cert \
      -h mydb.xxxx.eu-west-2.rds.amazonaws.com \
      -u admin -p

Client-side settings alone are not enough. Enforce TLS at the database level so non-SSL connections are rejected outright, not just discouraged:

• PostgreSQL: Set rds.force_ssl=1 in the RDS parameter group.
• MySQL: Set require_secure_transport=ON in the RDS parameter group.

Secrets Manager vs IAM database authentication

Both approaches avoid storing a static database password in application code. They solve the problem differently.

AWS Secrets Manager stores the database username and password as a managed secret. Your application retrieves the secret at startup using the AWS SDK. Secrets Manager can rotate the secret automatically on a schedule, updating the database password without requiring a deployment. This works with any language and any database user. It is the easier default for most teams.

IAM database authentication replaces the password entirely. Your application calls the AWS API to generate a short-lived auth token (valid for 15 minutes) and uses it as the password when connecting. There is no stored credential to leak. This works with MySQL and PostgreSQL on RDS.

# Enable IAM authentication on the RDS instance
aws rds modify-db-instance \
  --db-instance-identifier myapp-postgres-prod \
  --enable-iam-database-authentication \
  --apply-immediately

# Generate a short-lived auth token
TOKEN=$(aws rds generate-db-auth-token \
  --hostname mydb.xxxx.eu-west-2.rds.amazonaws.com \
  --port 5432 \
  --region eu-west-2 \
  --username iam_app_user)

# Connect using the token as the password (TLS is required for IAM auth)
PGPASSWORD=$TOKEN psql \
  "host=mydb.xxxx.eu-west-2.rds.amazonaws.com \
   user=iam_app_user dbname=myappdb \
   sslmode=verify-full \
   sslrootcert=/etc/ssl/certs/rds-global-bundle.pem"

For IAM roles attached to EC2 instances or ECS tasks, IAM database authentication integrates cleanly. The instance profile provides the credentials to generate the token with no stored secret to manage or rotate.

Which to choose: start with Secrets Manager if you want automatic rotation and broad compatibility. Add IAM database authentication when you want to eliminate stored credentials entirely, particularly for EC2 or ECS workloads with IAM instance profiles. See Rotating Secrets in AWS for how automatic rotation works in practice.