Is that good enough in your point of view?
Thanks
[0] https://www.rsync.net/resources/howto/snapshots.html (not affiliated, just a happy customer)
[1] https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versio... (ditto)
For targeted - it often doesn't because often your AWS keys are on the system doing the back up and have permissions to delete items etc.
Of course, this is why S3 allows you to set and object lock rule (ie, 30 days is plenty) that means even you (or your computer) can't go and delete those online backups.
That's because a targeted attack with a ransomware could gain access to your servers and wait 30 days while silently encrypting your backups until the 30th day, when the attackers could just complete the attack encrypting the rest of the files and showing the message.
So my recommendation for extremely critical data would be: 1) Test whole data thoroughly at least once during the object lock period. 2) Setup an automatic task that retrieves X random data every day (or the longest period of time you can afford to lose it) and perform checks with checksums or other methods. If something is corrupt and/or encrypted you will realize before it is too late.
Just a reminder - snapshots at rsync.net are immutable.[1]
Even if Mallory gains access to all of your access credentials, she cannot delete/change the snapshots in your rsync.net account.
For cloud, I use a time4vps storage server. I rsync some data and use borg for more sensitive stuff.