TL;DR - AWS RDS has no built-in browser GUI for running queries or managing data. - The traditional workaround — a bastion host with SSH tunnels — costs $8-30/month and takes 30+ minutes to configure. - DBEverywhere gives you a full AWS RDS GUI (phpMyAdmin or Adminer) in your browser by adding a single static IP to your RDS security group. - Works with MySQL RDS, Aurora MySQL, Aurora PostgreSQL, MariaDB RDS, and PostgreSQL RDS. - No software to install, no VPN, no EC2 instance to maintain.

Table of Contents

• The Missing Piece in AWS RDS
• How Teams Currently Access RDS (And Why It Hurts)
• What You Actually Need: A Browser-Based RDS Database Management Tool
• Step-by-Step: Connect to RDS from Your Browser in 3 Minutes
• MySQL RDS and Aurora: What Works and What to Watch For
• Comparison: Bastion Host vs. Session Manager vs. DBEverywhere
• FAQ
• Conclusion

How to Connect to AWS RDS from Any Browser

If you have ever needed to quickly check a row in production, debug a failed migration, or export a table from AWS RDS, you know the frustration. AWS gives you a managed database with automated backups, multi-AZ failover, and point-in-time recovery, but no AWS RDS GUI to actually look at your data from a browser. The AWS Console lets you create, configure, and monitor RDS instances. It does not let you run SELECT * FROM users WHERE email = 'jane@example.com'.

That gap sends thousands of developers down a rabbit hole of bastion hosts, SSH tunnels, VPN configurations, and desktop clients. All of it just to run a query.

This guide covers why that access gap exists, what the traditional workarounds cost in time and money, and how to connect to RDS from any browser in under three minutes using DBEverywhere, a hosted phpMyAdmin and Adminer gateway with a static IP built for exactly this problem.

The Missing Piece in AWS RDS

AWS RDS is one of the most popular managed database services in the world. AWS reports that hundreds of thousands of active customers use RDS across MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server engines. Aurora alone handles over 100 million transactions per second for some of the largest web applications on the planet.

Yet none of these engines ship with a built-in AWS RDS web interface. There is no "Query Editor" tab in the RDS Console where you can write SQL and see results. (AWS did launch RDS Query Editor for Aurora Serverless v1, but it was deprecated along with Aurora Serverless v1 itself, and it never supported standard RDS instances.)

This means that if you want to interact with your data, you need an external tool and a network path to reach your database. And because RDS best practices dictate placing your instance in a private subnet with no public accessibility, building that network path is where the complexity lives.

How Teams Currently Access RDS (And Why It Hurts)

There are three common approaches, each with significant trade-offs.

Option 1: Bastion Host with SSH Tunnel

The most widespread pattern. You launch a small EC2 instance (the bastion) in a public subnet within the same VPC as your RDS instance. You SSH into the bastion, then tunnel your local database client's connection through it.

What this involves:

1. Launch an EC2 instance (t3.micro or t3.small — $8.35 to $16.70/month in us-east-1).
2. Configure a security group for the bastion allowing inbound SSH (port 22) from your IP.
3. Configure the RDS security group to allow inbound traffic on port 3306 (MySQL) or 5432 (PostgreSQL) from the bastion's security group.
4. Manage SSH key pairs for every developer who needs access.
5. Keep the bastion patched and updated (it is a publicly accessible EC2 instance, after all).
6. Run an SSH tunnel command locally every time you want to connect:

ssh -i ~/.ssh/bastion-key.pem -L 3306:my-rds-instance.abc123.us-east-1.rds.amazonaws.com:3306 ec2-user@bastion-public-ip

1. Open MySQL Workbench, DBeaver, or TablePlus pointed at localhost:3306.

For a single developer working from one machine, this is manageable. For a team of five or ten, it becomes a key management headache. Someone always has a stale IP in the security group, or their SSH key got rotated, or they are on a coffee shop Wi-Fi and the tunnel drops every ten minutes.

Estimated setup time: 30-60 minutes for the initial configuration. 2-5 minutes per connection thereafter.

Option 2: AWS Systems Manager Session Manager

Session Manager lets you start a shell session on an EC2 instance without opening inbound SSH ports. Combined with aws ssm start-session --document-name AWS-StartPortForwardingSessionToRemoteHost, you can tunnel to RDS without a traditional bastion.

What this involves:

1. An EC2 instance (or Fargate task) with the SSM agent running in the same VPC as RDS.
2. IAM roles and policies granting ssm:StartSession and related permissions.
3. The AWS CLI installed and configured locally with valid credentials.
4. The Session Manager plugin installed on every developer's machine.
5. A port forwarding command:

aws ssm start-session \
  --target i-0abc123def456 \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"host":["my-rds-instance.abc123.us-east-1.rds.amazonaws.com"],"portNumber":["3306"],"localPortNumber":["3306"]}'

1. A local database client pointed at localhost:3306.

This eliminates the need for SSH keys and inbound port 22, which is a meaningful security improvement. But it still requires a running EC2 instance, local tooling on every machine, and a desktop database client. It is not something you can use from an iPad, a Chromebook, or a colleague's laptop.

Estimated setup time: 45-90 minutes for IAM policies, instance configuration, and local plugin installation. 1-3 minutes per connection.

Option 3: Make RDS Publicly Accessible

You can flip the "Publicly Accessible" toggle in the RDS Console and add your IP to the security group. Simple and fast, but AWS explicitly recommends against this for production databases. A misconfigured security group on a public RDS instance is one of the most common causes of database breaches on AWS.

Estimated setup time: 5 minutes. Estimated time until your security team files a finding: also 5 minutes.

All three approaches share a common limitation: they assume every person who needs database access has a properly configured local development environment. That is not always true, and it is never convenient.

Looking for a faster way to query your RDS data? DBEverywhere gives you phpMyAdmin and Adminer in your browser with a static IP you can whitelist in your security group. Start a free session.

What You Actually Need: A Browser-Based RDS Database Management Tool

The ideal RDS database management tool for day-to-day operations would have these properties:

• Runs in a browser. No software to install. Works from any device.
• Has a static IP. You add one IP to your RDS security group and every authorized user can connect through it.
• Supports familiar interfaces. phpMyAdmin for MySQL/MariaDB. Adminer for PostgreSQL and other engines. Tools your team already knows.
• Does not require a VPN, bastion host, or local CLI tools.
• Handles authentication per session. You enter your RDS credentials when you connect. Nothing is stored unless you choose to save it.

This is what DBEverywhere provides. It is a hosted gateway that runs phpMyAdmin and Adminer on infrastructure with a fixed IP address. You whitelist that IP in your AWS security group, open your browser, enter your RDS endpoint and credentials, and you are querying data within seconds.

No EC2 instance to maintain. No SSH keys to distribute. No desktop client to keep updated.

Step-by-Step: Connect to RDS from Your Browser in 3 Minutes

Here is the full walkthrough. You will need your RDS endpoint (available in the AWS Console under RDS > Databases > your instance > Connectivity & security) and your database credentials.

Step 1: Get DBEverywhere's Static IP

Go to dbeverywhere.com/connect. The static IP address is displayed on the connection page. Copy it. (It is also listed on the IP Whitelisting page for reference.)

Step 2: Add the IP to Your RDS Security Group

1. Open the AWS Console and navigate to RDS > Databases.
2. Click your database instance.
3. Under Connectivity & security, find the VPC security groups link and click it. This opens the EC2 security group console.
4. Select the security group attached to your RDS instance.
5. Click Edit inbound rules.
6. Click Add rule and enter:
7. Type: Custom TCP (or MySQL/Aurora if using the default port)
8. Port range: 3306 for MySQL/MariaDB/Aurora MySQL, or 5432 for PostgreSQL/Aurora PostgreSQL
9. Source: Custom, then paste DBEverywhere's static IP with a /32 suffix (e.g., 203.0.113.42/32)
10. Description: DBEverywhere gateway
11. Click Save rules.

AWS security groups support up to 60 inbound rules per group by default (adjustable via quota request). One rule for DBEverywhere's IP uses a single slot.

Important: Your RDS instance must be reachable from the internet for this to work. If your instance is in a private subnet with no internet gateway or NAT route, you will need to either move it to a public subnet (with "Publicly Accessible" set to Yes) or use DBEverywhere's SSH tunnel feature (paid tier) to connect through a jump host that does have access. The security group rule alone is not enough if there is no network route.

Step 3: Connect via DBEverywhere

1. Go to dbeverywhere.com/connect.
2. Select your database engine (MySQL, MariaDB, or PostgreSQL).
3. Enter your RDS endpoint. It looks like: my-instance.abc123xyz.us-east-1.rds.amazonaws.com
4. Enter your port (3306 or 5432).
5. Enter your database username and password.
6. Click Connect.

You are now in phpMyAdmin (for MySQL/MariaDB) or Adminer (for PostgreSQL) with full access to browse tables, run queries, export data, and manage schema, all from your browser.

Total time: About 2-3 minutes, most of it spent in the AWS Console adding the security group rule.

On the free tier, you get 5 sessions per month with a 20-minute timeout. Need longer sessions and saved connections? The paid plan is $5/month with 8-hour timeouts and unlimited sessions.

MySQL RDS and Aurora: What Works and What to Watch For

DBEverywhere works with all MySQL-compatible RDS engines, but there are a few details worth noting.

Standard MySQL RDS (5.7 and 8.0)

Full compatibility with phpMyAdmin. All standard operations work: browsing, querying, importing, exporting, user management, and schema changes. The RDS master user has most privileges but cannot SUPER or SHUTDOWN, which is standard for RDS and does not affect phpMyAdmin usage.

Aurora MySQL (MySQL 5.7-compatible and 8.0-compatible)

Aurora endpoints work the same way as standard RDS endpoints in phpMyAdmin. If you are using Aurora with read replicas, you can connect to the reader endpoint for read-only access or the cluster endpoint for read-write. Both work with DBEverywhere.

Aurora MySQL clusters have two default ports: 3306 for the primary and the same for readers. If your cluster uses a custom port, enter that instead.

Aurora PostgreSQL and Standard PostgreSQL RDS

Use Adminer instead of phpMyAdmin. The connection flow is identical: enter the endpoint, port 5432, credentials, and connect. Adminer supports PostgreSQL's schema system, functions, and sequences.

MariaDB RDS

phpMyAdmin works natively with MariaDB. No differences from the MySQL flow.

A Note on SSL

RDS instances use SSL/TLS by default. DBEverywhere connects to your database over SSL when the server supports it, which all RDS instances do. You do not need to download or configure the RDS CA certificate bundle yourself; the gateway handles this.

Comparison: Bastion Host vs. Session Manager vs. DBEverywhere

The bastion approach trades ongoing operational overhead for full control. Session Manager eliminates SSH keys but adds IAM complexity and still requires local tooling. DBEverywhere trades control for simplicity: you do not manage any infrastructure, but you are trusting a third-party gateway with your database credentials for the duration of the session.

For teams that want zero-maintenance access to RDS for ad-hoc queries, debugging, and data exports, the browser-based approach removes the most friction.

FAQ

Can I use DBEverywhere with an RDS instance in a private subnet?

Only if there is a network route from the public internet to your instance. If your RDS is in a fully private subnet with no internet gateway, you have two options: (1) use DBEverywhere's SSH tunnel feature (paid tier) to connect through a jump host that has VPC access, or (2) modify your VPC networking to allow inbound traffic on the database port from DBEverywhere's IP. Option 1 is easier and does not require changing your VPC architecture. See our SSH tunnel guide for details.

Is it safe to whitelist a third-party IP in my RDS security group?

The security model is the same as whitelisting any static IP, such as your office network or a CI/CD server. The IP alone does not grant access; a valid database username and password are still required. DBEverywhere does not store your credentials unless you explicitly opt in to saved connections on the paid tier. All sessions use HTTPS for the browser connection and SSL/TLS for the database connection. For more details, see our security page.

Does this work with Aurora Serverless v2?

Yes. Aurora Serverless v2 uses standard Aurora endpoints and supports security group rules the same way as provisioned Aurora. You can whitelist DBEverywhere's IP and connect via phpMyAdmin (MySQL-compatible) or Adminer (PostgreSQL-compatible).

What about Multi-AZ deployments? Do I need to whitelist multiple IPs?

No. Multi-AZ RDS uses a single DNS endpoint that automatically points to the active instance. Your security group is attached at the instance level and applies regardless of which AZ the primary is running in. You whitelist DBEverywhere's one IP once and it works through failovers.

Are there query or export size limits?

DBEverywhere uses standard phpMyAdmin and Adminer, so the practical limits are determined by your session timeout and browser memory. On the free tier, sessions last 20 minutes. On the paid tier, sessions last up to 8 hours. For large exports (multi-GB), a dedicated tool like mysqldump over an SSH tunnel is more appropriate. For day-to-day queries and exports of tables up to a few hundred thousand rows, the browser interface works well.

Conclusion

AWS RDS solves the hard problems of database operations: backups, replication, failover, patching. But it leaves a gap where day-to-day data access should be. There is no built-in AWS RDS GUI for the most common task developers and operators actually need: looking at their data and running queries.

The traditional solutions (bastion hosts, Session Manager, desktop clients) all work, but they impose setup costs, maintenance burden, and device requirements that do not match how teams actually work today. You should not need to spend 45 minutes configuring IAM policies and installing CLI plugins just to check whether a migration ran correctly.

DBEverywhere fills that gap. Add one static IP to your security group, open your browser, and connect. phpMyAdmin and Adminer handle the rest. It works with MySQL RDS, Aurora MySQL, Aurora PostgreSQL, MariaDB RDS, and PostgreSQL RDS.

Try it free — 5 sessions per month, no credit card required.