A snapshot marked public can be restored by anyone with an AWS account, in any region, at any time. Nothing is exploited, nothing appears in your access logs, and the copy they take is complete. It is one of the few exposures where the data leaves your control entirely while every security control you operate continues working exactly as designed.
How sharing gets switched on
Usually for a reason that made sense at the time. An engineer shares an image with a partner account so they can run the same appliance, and public is quicker than looking up the account number. A team publishes a machine image to help a community project, without realising the image was built from a running production host. Automation copies snapshots between accounts and the permission set gets applied broadly to make the pipeline work. Each of these creates a permanent copy outside your boundary, and deregistering an image later does not delete the underlying snapshot that carries the data.
What ends up inside an image
More than the operating system. Machine images built from a live server carry the state of that server at the moment it was captured: shell history, private keys in a user’s home directory, application configuration with database passwords, cached credentials, log files and sometimes a copy of the data itself. Testers examining a shared image mount it and read through exactly those locations, and the process takes minutes. This is why an image built by hand from a working system is a very different object from one built by a pipeline from a clean base.
“Run the query that lists snapshots restorable by all, in every region, not just the ones you use. Attackers scan across every region because it costs them nothing, and the forgotten one is always in eu-west-2 or somewhere a team spun up for a proof of concept in 2022. I have found production database snapshots that way more than once.”
William Fieldhouse, Director, Aardwolf Security Ltd
Settings that stop it happening again
Turn on the account-level block for public snapshot sharing, which prevents the setting being applied at all rather than reporting it afterwards. Encrypt volumes with a customer managed key, since encrypted snapshots cannot be shared publicly and cross-account sharing then requires deliberate key permissions as well. Add a service control policy denying the sharing actions outside a small set of roles. Then review existing cross-account shares, because an account number added for a supplier in 2021 is still a valid recipient today whether or not the relationship continues.
Finding what is already exposed
Audit rather than assume, and do it across every region and account. List snapshots and images with their permissions, check which have public or cross-account access, and match each against a business reason and an owner. Where a snapshot holds personal data, an unexplained public share is a matter for your data protection lead as well as your security team, since the Information Commissioner’s Office expects you to be able to describe what happened and when. AWS cloud penetration testing servicesinclude this in an account review, and cloud configuration scanningbetween reviews catches the setting within a day of somebody applying it.
Frequently asked questions about snapshot exposure
These questions come up whenever a cloud account review begins.
Does deleting the image remove the risk?
Only if you also delete the snapshots behind it. Deregistering an image leaves the storage in place, and anyone who noted the identifier can still restore from it while the permission remains.
Can you tell whether somebody copied it?
Generally no, which is the difficult part. Access to a public snapshot happens in the other account, so your logs show nothing. That absence of evidence is why prevention matters more here than detection.
