I am currently implementing S3, with correct error handling for edge cases. Its been about a month and I have almost the whole API surface done, with some gaps (you actually need a broader surface eg some IAM, KMS encrytion needs a persistence layer so only done sse-c so far). Close to the point where you could drop it in as a local emulation tool, its a sub 9MB binary (Rust).
Literally as I write this the AI code review said "suspended-bucket current-version selection is still wrong when the numbered version and the newer null version land in the same millisecond." - thats the level of detail you have to deal with.
Actually no, because they actually have to worry about their millions of customer deployments not randomly breaking every other week. So, they are generally very good about not breaking compatibility unless they have a really good reason to. And when they do, they typically give people years of time to deal with any backwards compatibility breaking changes. Because otherwise they are dealing with lots of support overhead and angry customers. That and the multiple independently developed s3 compatible clients or alternatives make this probably the easiest thing to simulate in the AWS universe as it is probably the most widely used thing in AWS.
Not really, the main thing they could change is the order in which errors are checked when there are multiple errors, but even a lot of that is not likely to change, eg html based stuff comes first. There are actual reasons for a lot of the subtleties, plus they have to have a stable contract for all the success cases as people rely on it. And its not hard to update, I have 800 or so tests against AWS that run in a few minutes.
Literally as I write this the AI code review said "suspended-bucket current-version selection is still wrong when the numbered version and the newer null version land in the same millisecond." - thats the level of detail you have to deal with.