Join our Newsletter — 33% off our NHI Course

How do you stop AWS EBS and RDS snapshots from being shared publicly?

Restrict snapshot sharing so only approved AWS accounts can use it, and review existing snapshot permissions for public access. For EBS and RDS, a publicly shared snapshot can expose data at rest to anyone who can copy it into their own environment. Keep an inventory of shared snapshots and alert on permission changes.

How snapshot sharing turns into a data exposure problem

AWS snapshot sharing is not just an admin convenience, it is an access-control decision that can change who can copy and inspect data you thought was private. For EBS and RDS, the practical risk is that a snapshot with overly broad or public permissions can be duplicated into another account and examined outside your intended trust boundary.

That means the question is less about whether the snapshot is “stored safely” and more about whether its sharing policy is still constrained to approved AWS accounts. The control objective is to keep the snapshot itself from becoming a reusable data export path.

What to check before you assume a snapshot is private

Start with the current resource permissions on both EBS and RDS snapshots, because the default state can be misleading once sharing has been modified. Review whether any snapshot is shared with all users, with broad account sets, or with accounts that no longer need access.

Keep an inventory of snapshots that are intentionally shared, and make sure each one has a named business or operational owner. If you cannot tie a shared snapshot to an active need, treat that as a cleanup item rather than a harmless leftover.

For AWS environments with many accounts, the key check is not only the snapshot ACL itself but also whether your account governance process can detect when a new share is added. A snapshot that becomes public for even a short time can still be copied during that window.

How to prevent accidental public sharing and reduce blast radius

Use the narrowest sharing pattern available: only approved AWS accounts, only for a defined purpose, and only for as long as the recipient needs the copy. Where possible, prefer controlled distribution of encrypted copies rather than broad sharing of the original snapshot.

Build a review step into change management so snapshot sharing changes are visible before they reach production. If you already use a cloud guardrail program, align snapshot-sharing checks with the same policy review used for other public exposure paths such as storage access, security groups, and snapshot-like backups.

Automated detection helps most when it is tied to ownership. A permission change without an alert is easy to miss, so alert on new public sharing, changes to allowed recipients, and sudden growth in the number of shared snapshots.

Risk and Threat Considerations

Publicly shared snapshots can expose data at rest to anyone who can copy the snapshot into their own environment, which turns a backup or recovery object into a direct disclosure path. The problem is especially material when the snapshot contains databases, application secrets, or other sensitive records that were assumed to be protected by account boundaries.

Failure mechanism: A snapshot is shared too broadly, copied into an unauthorized account, and then inspected or restored outside the intended control plane, bypassing the original environment’s access restrictions.

Impact: Confidential data can be exposed, copied, and reused, and the organisation may lose visibility into where the data was duplicated or how long the exposure persisted.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CSA Cloud Controls Matrix, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework Control / Reference Relevance
CSA Cloud Controls Matrix IAM — Identity and Access Management Snapshot sharing is an access-control decision over cloud resources.
Recommendation — Restrict snapshot access to approved accounts and review sharing permissions regularly.
NIST CSF 2.0 PR.AA-05 — Identity Management, Authentication and Access Control Controls who can access shared cloud snapshots and under what permissions.
Recommendation — Limit snapshot sharing to authorized accounts and monitor permission changes.
ISO/IEC 27001:2022 A.5.15 — Access control Public snapshot sharing is an access-control weakness over sensitive data copies.
Recommendation — Apply access-control policy to shared snapshots and revoke unnecessary public access.
NIST SP 800-53 Rev 5 AC-3 — Access Enforcement Snapshot permissions must enforce who can copy or use the resource.
Recommendation — Enforce least-privilege sharing on snapshots and block public access paths.
CIS Controls v8 CIS-3 — Data Protection Shared snapshots can expose sensitive data and need inventory plus control.
Recommendation — Inventory snapshots and remove any public or unnecessary sharing.

Practitioner Guidance

What to prioritise: Review every snapshot sharing exception before you spend time on general hardening. The highest-value work is to identify any snapshot that is public or broadly shared, then confirm whether that access is still required.

What to verify: Confirm that your inventory includes both EBS and RDS snapshots, not just one service. Also verify that alerts fire on permission changes, because stale inventories without change detection miss the moment exposure is introduced.

Common mistake: Treating snapshots as passive backups instead of distributable copies of real data. If the snapshot can be copied, the permissions around it matter as much as the permissions on the source system.

Practitioner takeaway: The safest posture is not “no sharing,” it is “explicit, time-bounded, account-scoped sharing with continuous review,” because snapshot permissions are a data-exposure control, not just a backup setting.