Overview
In the AWS cloud, data security is a shared responsibility, and misconfigurations remain a leading cause of data breaches. One of the most critical yet easily overlooked issues is the public exposure of Amazon Relational Database Service (RDS) snapshots. These snapshots are point-in-time backups of your databases, essential for disaster recovery and development. However, a simple misconfiguration can make an entire database backup publicly available.
When an RDS snapshot is set to “Public,” it grants any authenticated AWS user worldwide the permission to copy the snapshot into their own account. From there, they can restore it as a fully functional database, gaining unrestricted access to all its contents. This type of exposure bypasses network-level security like firewalls and security groups, creating a direct path to your organization’s most sensitive information.
This risk is not theoretical; it represents a significant vulnerability that can lead to total data compromise. For FinOps and cloud governance teams, understanding and preventing this misconfiguration is crucial for protecting the business from severe financial, reputational, and operational consequences.
Why It Matters for FinOps
The business impact of a public RDS snapshot extends far beyond a technical security flaw. From a FinOps perspective, it introduces significant and unbudgeted risk that can derail financial planning and operational stability. Non-compliance with data protection regulations like GDPR, HIPAA, or PCI-DSS can result in millions of dollars in fines.
Beyond direct financial penalties, the reputational damage from a publicly disclosed data breach can erode customer trust and market value. A single incident can lead to customer churn and a loss of competitive advantage if intellectual property is stolen. The operational drag is also immense, requiring costly incident response efforts, forensic analysis, and mandatory breach notifications, diverting engineering resources from value-generating activities. Proactive governance to prevent this issue is far more cost-effective than reactive cleanup.
What Counts as “Idle” in This Article
In this article, we are focusing on a specific type of misconfigured resource: an RDS snapshot with its visibility attribute set to “Public.” This is different from a live, “publicly accessible” database instance that has a public IP address. A public snapshot is a backup file that is not actively serving traffic but is improperly configured to allow global access for copying and restoration.
Signals that a snapshot is in this risky state are not based on performance metrics like CPU or memory usage. Instead, the key indicator is a permission setting that grants access to the “all” group in AWS. This configuration effectively turns a critical backup asset into a liability, making the complete dataset available to any threat actor who discovers it. A core principle of cloud governance is ensuring that resources, whether active or backups, adhere to the principle of least privilege.
Common Scenarios
Scenario 1: Accidental Data Sharing
Engineers or developers needing to share a database backup with a contractor or another internal team may mistakenly set the snapshot visibility to “Public.” They often confuse this global setting with the correct method of sharing a snapshot directly with a specific, trusted 12-digit AWS Account ID. This simple user error can inadvertently expose the entire dataset.
Scenario 2: Legacy Migration Remnants
Older AWS environments may contain manual snapshots created years ago for a one-time migration or testing purpose. These snapshots often lack encryption, which is a prerequisite for public sharing. If they were made public temporarily and never reverted to private, they remain a hidden and forgotten security risk, waiting to be discovered.
Scenario 3: Shadow IT for Analytics
Data science or analytics teams often need access to production data for building models. To bypass complex IAM policies or cross-account data sharing procedures, a team member might briefly make a snapshot public to quickly transfer it to a separate research account. This “temporary” workaround is frequently forgotten, leaving the snapshot permanently exposed.
Risks and Trade-offs
The primary risk of a public RDS snapshot is the complete and irreversible loss of data confidentiality. Once a threat actor copies the snapshot, the data is out of your control. This includes customer PII, financial records, application secrets, and proprietary business logic. There is no trade-off that justifies this level of exposure.
Some teams may argue that making snapshots public is a fast way to move data, but the security risk far outweighs any perceived convenience. The “don’t break prod” mentality must extend to production data, regardless of where it resides. A backup is a copy of production, and its exposure can be just as damaging as a breach of the live database itself. Secure, audited methods for data sharing are always the correct approach.
Recommended Guardrails
To prevent public RDS snapshots, organizations must implement a multi-layered governance strategy. This moves beyond simply fixing individual instances and focuses on creating a secure-by-default environment.
Start by establishing a strict policy that prohibits public RDS snapshots under any circumstances. Enforce this with tagging standards that assign clear ownership and a data classification level to every snapshot. All data sharing activities should go through a formal approval flow.
Use automated alerting to notify security and FinOps teams the moment a public snapshot is detected. Implement budgets and cost allocation practices that make teams accountable for the resources they manage, including the security posture of their backups. The most effective technical guardrail is to enforce encryption-at-rest for all RDS instances, as AWS natively prevents encrypted snapshots from being shared publicly.
Provider Notes
AWS
To manage this risk within AWS, it’s essential to leverage the platform’s native security and governance services. All database instances should be configured using Amazon RDS with encryption enabled via AWS Key Management Service (KMS). This is a critical preventative control, as AWS blocks encrypted snapshots from being made public.
For proactive enforcement, use AWS Organizations to deploy Service Control Policies (SCPs) that explicitly deny the rds:ModifyDBSnapshotAttribute action when the permission is set to “Public.” This creates a hard limit that even account administrators cannot bypass. To continuously monitor your environment, use AWS Config rules like rds-snapshots-public-prohibited to detect and even auto-remediate any non-compliant snapshots that appear.
Binadox Operational Playbook
Binadox Insight: Enforcing encryption-at-rest for all RDS databases is the single most effective technical guardrail against public snapshot exposure. Because AWS prevents encrypted snapshots from being shared publicly, this control eliminates the possibility of this specific misconfiguration at the source.
Binadox Checklist:
- Audit all existing RDS snapshots across all regions to identify any with public permissions.
- Implement a mandatory policy requiring encryption-at-rest for all new RDS instances.
- Deploy an AWS Organizations SCP to block the
rds:ModifyDBSnapshotAttributeaction for public sharing. - Establish a formal, secure process for sharing snapshots using specific AWS Account IDs.
- Set up automated alerts using AWS Config or a third-party tool to immediately flag newly public snapshots.
- Review and delete old, unnecessary snapshots to reduce the overall attack surface.
Binadox KPIs to Track:
- Number of public RDS snapshots detected per week/month.
- Mean-Time-To-Remediation (MTTR) for public snapshot alerts.
- Percentage of RDS instances configured with encryption-at-rest.
- Number of exceptions granted for cross-account snapshot sharing policies.
Binadox Common Pitfalls:
- Confusing a “publicly accessible” database instance with a “public” snapshot; they are distinct risks.
- Forgetting to revert permissions after a “temporary” public share for data transfer.
- Lacking a centralized inventory of snapshots, leading to forgotten and unmonitored legacy assets.
- Failing to audit both manual and automated snapshots for public exposure.
Conclusion
Securing RDS snapshots is a foundational element of a robust AWS security and governance program. A public snapshot is not just a minor misconfiguration; it is a critical vulnerability that exposes an organization’s most valuable data to the entire world.
By adopting a proactive stance—enforcing encryption, implementing preventative guardrails with AWS Organizations, and continuously monitoring with AWS Config—FinOps and engineering teams can effectively eliminate this risk. This protects the organization from severe financial and reputational harm while fostering a culture of security by design.
7-day free trial