Overview
In any cloud environment, databases are a prime target for malicious actors. Amazon Relational Database Service (RDS) simplifies database management on AWS, but securing the data and network configuration remains a critical responsibility. A foundational, yet frequently overlooked, security control is the configuration of the database listening port.
By default, database engines use well-known, standard ports—such as 3306 for MySQL or 5432 for PostgreSQL. While convenient for initial setup, these default settings create a predictable target for automated vulnerability scanners and botnets that constantly scour the internet for exposed services.
Leaving these ports unchanged exposes your organization to a continuous barrage of unauthorized connection attempts, increasing the risk of brute-force attacks and creating unnecessary operational noise. Implementing a policy to use non-standard ports is a simple but powerful step in hardening your AWS environment, reducing your attack surface, and improving your overall security posture.
Why It Matters for FinOps
This configuration issue extends beyond pure security; it has direct implications for FinOps governance and cloud cost efficiency. Exposing default ports, even within a VPC, introduces tangible costs and operational drag.
The constant stream of automated connection attempts from scanners generates significant log data, which can increase storage and processing costs. More critically, these attacks can consume valuable CPU and network resources on the database instance, potentially degrading performance for legitimate applications or even leading to a denial-of-service event.
From a governance perspective, failing to address this basic hardening measure can result in failed compliance audits for frameworks like PCI-DSS and HIPAA, which mandate changing vendor-supplied defaults. The cost of emergency remediation during an audit is always higher than proactive management. Furthermore, the constant "security noise" leads to alert fatigue, making it harder for engineering teams to identify and respond to genuine threats, thereby wasting valuable operational cycles.
What Counts as “Idle” in This Article
In this article, we define the risk not as an "idle resource" in the traditional sense of unused capacity, but as an unnecessary and wasteful exposure. The configuration "waste" is the acceptance of a predictable attack vector that consumes resources and increases risk without providing any business value.
Any AWS RDS instance configured to listen on its standard, IANA-assigned default port is considered a high-risk configuration. This includes, but is not limited to:
- MySQL / MariaDB / Aurora MySQL: Port 3306
- PostgreSQL / Aurora PostgreSQL: Port 5432
- Microsoft SQL Server: Port 1433
- Oracle: Port 1521
Identifying these instances is the first step toward eliminating this source of operational friction and security vulnerability.
Common Scenarios
Scenario 1
A development team quickly launches a new RDS instance for a project in a public subnet to simplify initial connectivity. By leaving the port on its default setting, the database is discoverable by internet-wide scanners within minutes, immediately exposing it to automated brute-force attacks before any application code is even deployed.
Scenario 2
An application’s RDS instance is correctly placed in a private VPC subnet. However, an attacker compromises a web server in a public subnet within the same VPC. The attacker then performs an internal network scan, quickly locating the database by searching for the default PostgreSQL port 5432. This allows for lateral movement and accelerates the internal attack.
Scenario miscellaneous
A legacy application with a hardcoded connection string uses an RDS instance with a default port. The organization assumes it is safe because it’s "internal," but this configuration becomes a significant liability during compliance audits or in the event of an internal security breach, demonstrating a lack of defense-in-depth.
Risks and Trade-offs
The primary argument against changing default ports is the operational effort required. It involves coordinating changes across application connection strings, infrastructure-as-code templates, and security group rules. The fear of "breaking production" can lead to inertia, where teams accept the risk to avoid potential downtime.
However, this is a false economy. The trade-off is between a planned, one-time maintenance event versus an ongoing, indefinite security risk. While changing a port requires careful planning and testing, the process is straightforward and significantly mitigates the risk of brute-force attacks, resource exhaustion from scanners, and compliance violations. It is a fundamental part of a defense-in-depth strategy, where multiple layers of security work together to protect critical assets.
Recommended Guardrails
To manage this risk proactively, FinOps and cloud governance teams should establish clear guardrails.
Start by creating a corporate policy that prohibits the deployment of new RDS instances with default ports. Use tagging standards to assign clear ownership for every database, simplifying communication and accountability during remediation efforts.
Implement automated detection and alerting using services like AWS Config to flag non-compliant instances as soon as they are created. This allows for immediate correction before the resource is integrated into a production workflow. For any exceptions, establish a formal approval process that requires clear business justification and documented risk acceptance from the asset owner.
Provider Notes
AWS
AWS provides all the necessary tools to manage and secure your Amazon RDS instances effectively. The database port can be changed by modifying the DB instance settings in the AWS Management Console or via the API. This action typically requires a database restart, so it should be scheduled during a maintenance window.
Access to the new port must be explicitly allowed in the associated VPC Security Groups. As a best practice, these rules should be as restrictive as possible, only allowing traffic from specific application servers. For automated governance, you can use AWS Config to deploy a managed or custom rule that continuously checks for RDS instances using default ports. To further enhance security, consider implementing IAM Database Authentication to eliminate long-lived static database passwords entirely.
Binadox Operational Playbook
Binadox Insight: Changing the default database port is a high-leverage security action. It acts as a filter, removing your critical data assets from the "low-hanging fruit" category targeted by automated attackers and significantly reducing security log noise.
Binadox Checklist:
- Audit your entire AWS environment to identify all RDS instances using default ports.
- Map all application and user dependencies for each non-compliant instance.
- Schedule a coordinated maintenance window to update the RDS port and all client connection strings.
- Modify the instance’s security group to allow traffic on the new port and remove the rule for the old one.
- Deploy an automated AWS Config rule to detect and alert on future non-compliant deployments.
- After the change, thoroughly test and verify application connectivity and functionality.
Binadox KPIs to Track:
- Percentage of RDS instances compliant with the non-default port policy.
- Mean Time to Remediate (MTTR) for newly detected non-compliant instances.
- Reduction in failed login attempts recorded in database logs.
- Number of audit findings related to insecure default configurations.
Binadox Common Pitfalls:
- Forgetting to update a single client’s connection string, causing an application outage.
- Updating the RDS port but failing to modify the security group rules, blocking all legitimate traffic.
- Treating port obfuscation as a complete security solution rather than one layer of defense.
- Lacking a clear ownership and communication plan, leading to confusion during remediation.
Conclusion
Moving away from default AWS RDS ports is not just a security checklist item; it is a core tenet of responsible cloud management and FinOps governance. This simple change reduces risk, cuts operational waste by eliminating security noise, and strengthens your compliance posture.
Begin by auditing your existing RDS fleet to understand your current exposure. From there, develop a clear remediation plan for existing instances and implement automated guardrails to ensure all future databases are deployed securely from the start. This proactive approach will build a more resilient and efficient cloud infrastructure.
7-day free trial