AWS RDS Public Access: Finding and Eliminating Exposed Databases

Publicly accessible RDS instances appear in security reports more often than any other database finding. The pattern is consistent: a developer needs to connect to a database from their laptop, the quickest solution is enabling public accessibility, and the "temporary" configuration becomes permanent once the immediate problem is solved. Security groups often restrict access to specific IPs (the developer's home IP, the office range), but the fundamental problem remains — the database is reachable from the public internet and only a security group stands between it and the world.

Security groups are effective controls, but they're more fragile than VPC network isolation. A security group rule can be accidentally modified, overly permissive rules can accumulate, and the security group isn't subject to the same network-level visibility as VPC-private resources. Removing public access entirely is a more robust security posture.

Why Databases End Up Publicly Accessible

There are three common paths to inadvertent public RDS access:

Developer convenience: The most common. Direct database access from development workstations requires either a VPN, a bastion host, or public accessibility. Without a VPN or bastion already in place, enabling public access is the path of least resistance.

Legacy configuration: A database originally created when public access was the standard approach, before the team implemented VPC architecture. The database works, nobody has had a reason to change the configuration, and the exposure continues.

Misconfigured automation: Infrastructure-as-Code that was written without awareness of the public_accessible parameter, or that explicitly sets it to true for development databases without distinguishing production versus development.

Finding Publicly Accessible RDS Instances

Check all accounts and regions for publicly accessible databases:

aws rds describe-db-instances   --query 'DBInstances[?PubliclyAccessible==`true`].[DBInstanceIdentifier,DBInstanceClass,Engine,Endpoint.Address,MultiAZ]'   --output table

For comprehensive coverage across an AWS Organization, use AWS Security Hub with the rds-instance-public-access-check finding, which aggregates results across all accounts and regions in a single view. Alternatively, use AWS Config aggregators to query the Config rule compliance across the organization.

Supplement the RDS check with Aurora clusters, which have separate accessibility settings from individual DB instances:

aws rds describe-db-clusters   --query 'DBClusters[?[DBClusterMembers[?IsClusterWriter==`true`]]]'   --output table

Remediation: Disabling Public Access

Disabling public access is a low-risk change for most databases, but requires verifying that existing connectivity isn't disrupted:

Step 1: Identify all connection sources. Query your database audit logs or CloudWatch metrics for recent client connections. Identify source IPs. Determine whether any connections come from outside your VPC (external IPs that aren't your office or VPN).

Step 2: Establish alternative access for external connections. For developer access: set up AWS Client VPN or configure AWS Session Manager port forwarding through a bastion. For BI tools connecting from the internet: configure VPN integration or use a cloud connector that supports VPC-private database connections.

Step 3: Modify the instance to disable public access.

aws rds modify-db-instance   --db-instance-identifier your-database-name   --no-publicly-accessible   --apply-immediately

The --apply-immediately flag makes the change without waiting for the next maintenance window. The DNS name for the database remains the same — the change only affects whether the DNS resolves to a public IP or a VPC-private IP.

Step 4: Verify connectivity. Test application connectivity through all expected paths. Test that developer access through the new VPN or bastion works. Confirm that direct public internet connections to the old endpoint fail (the DNS will resolve to a private IP, and the connection will time out for external callers).

AWS Session Manager Port Forwarding: Developer Access Without VPN

For development access, AWS Systems Manager Session Manager port forwarding provides a lightweight alternative to a full VPN setup. A developer with the SSM CLI plugin can forward a local port to the RDS endpoint through a bastion or jump host in the VPC:

aws ssm start-session   --target i-0123456789abcdef0   --document-name AWS-StartPortForwardingSessionToRemoteHost   --parameters '{"host":["database.cluster-abc.us-east-1.rds.amazonaws.com"],"portNumber":["5432"],"localPortNumber":["5432"]}'

The developer connects their database client to localhost:5432, and Session Manager forwards the traffic to the RDS endpoint through the EC2 instance. No SSH required, no long-lived credentials, full IAM-controlled access.

Preventing Recurrence with AWS Config

After remediating public access, prevent recurrence with continuous monitoring. AWS Config rule rds-instance-public-access-check evaluates all RDS instances and flags any with public access enabled. Configure automatic remediation to disable public access automatically when detected, or configure alerting to notify your security team within minutes of a public RDS instance being created or modified.

Related Reading

• RDS security — comprehensive RDS hardening beyond public access
• Security groups audit — reviewing the security groups protecting publicly accessible databases
• Essential AWS Config rules — compliance monitoring for RDS configuration
• VPC security monitoring — network-level monitoring that complements database access controls

FAQ

What's the difference between the RDS endpoint being publicly accessible vs. being accessible from the internet?

These are the same thing. A publicly accessible RDS endpoint resolves to a public IP address, meaning it can receive connection attempts from the internet. Even if security group rules restrict which source IPs can complete the connection, the database endpoint is reachable for TCP connection attempts from any IP on the internet — including brute force and vulnerability scanners. Disabling public accessibility removes the public IP entirely, making the endpoint unreachable from outside the VPC even if security groups were misconfigured.

Does disabling public access require a database restart?

Disabling public accessibility requires a reboot to take effect and the DNS to be updated. The reboot is brief (typically 1-5 minutes for most RDS engine types). For production databases, schedule this change during a maintenance window and monitor for application connectivity issues post-reboot. Multi-AZ deployments perform an automatic failover during the modification, further reducing downtime.

Our BI tool connects from the internet — what options do we have?

Modern BI tools generally support VPN-tunneled connections, bastion-hop configurations, or AWS PrivateLink integrations. Looker, Tableau, and PowerBI all support connecting through VPNs or SSH tunnels. Cloud-native BI services like Amazon QuickSight have native VPC integration that can reach private RDS endpoints directly. Evaluate your BI tool's connection options — most support private database access for the same reasons you want private databases.