By definition, any really effective backup (off site, offline) can't simply be modified instantly when you click a button in a web UI. The reason it takes months for backups to clear out your deleted data is that's how long it takes for the entire backup to be discarded and replaced by a new backup that reflects your deletions.

While the data is likely inaccessible forever in this case, the reason the company can't just say it's been deleted is if they actually do need to restore one of these backups, the data you deleted will come back.

You can delete user data from backups much more quickly than that:

* Encrypt each user's data to a user-specific key

* Keep the key in hot replicated storage

* When you get a deletion request, delete the key

You still need to back up the keys? How does this solve anything?

Backups aren't just about replication/redundancy, they also protect you from bugs and other sources of corrupted data.

You can back up the keys in ways where it's very easy to purge them: no tapes, easy to recall and edit.

The fact that backups can't be accessed and modified easily for a long period of time is a feature, not a bug, regardless of the actual mechanism of implementation (like tapes). That's what stops e.g. ransomware from affecting backups in addition to the primary storage.

A backup that can be edited to delete data like an encryption key instantly when the user tells it do is also a backup that can be easily lost or corrupted.

That's a reasonable reason for my data to be on their servers. However, what validates that they actually do it?

The only way in my mind to grant your wish would be if you owned the storage of your credentials. Otherwise you're just moving trust to another entity. I'm not an expert.

Either way that clause showed a hint accountability from Amazon that I haven't seen too often. Not that I've spent much time comparing ToS either.