Object integrity isn’t part of the S3 SLA. I assume that is mostly because object integrity is something AWS can’t know about per se.
You could unknowingly upload a corrupted file, for example. By the time you discover that, there may not be a clear record of operations on that object. (Yes, you can record S3 data plane events but that’s not the point.)
Only the customer would know if their data is intact, and only the customer can ensure that.
The best S3 (or any storage system) can do is say “this is exactly what was uploaded”.
And you can overwrite files in S3 with the appropriate privileges. S3 will do what you ask if you have the proper credentials.
Otherwise, S3 is designed to be self-healing with erasure encoding and storing copies in at least two data centers per region.
Yes but my point stands. If AWS added S3 data integrity to the SLA then it’s now made that commitment contractually. If you add checksum data the checksums would (logically) be required and also be in scope of the SLA. If there was a mismatch between them and the file functioned it would be impossible to sanely adjudicate who is responsible for the discrepancy, or what the nature of that discrepancy might be if no other copies of the file exist.
AWS probably doesn’t want those risks and ambiguities.
