S3 Eventual Consistency: части файла теряются при PUT с перезаписью

Да, мог. Согласованность в конечном счете означает, что следующий GET объекта может возвращать или не возвращать результаты последнего PUT, когда объект был перезаписан.

Включите управление версиями корзины, и вы сможете легко определить, что происходит в этих событиях, фиксируя и регистрируя идентификатор версии объекта каждый раз, когда вы загружаете или скачиваете его.

Если версия, которую вы загрузили последней, отличается от той, которую вы загружаете впоследствии, это признак возможной согласованности, вызывающей проблему.

С другой стороны, если вы активно управляете своей загрузкой, специально запрашивая последнюю версию, используя ее последний известный идентификатор версии (который вам нужно будет захватить, когда вы PUT объект, и сохранить где-то, что предлагает строго согласованное чтение, например DynamoDB или RDS), то вы всегда можете явно запросить последнюю версию при ее загрузке.

Явные запросы для конкретной версии объекта решают проблему, потому что они не имеют ограничений согласованности — данная, указанная версия объекта либо существует, либо нет. Проблема согласованности связана с неявным получением «последней» версии объекта. Если конкретная реплика индекса, которая обслуживает ваш запрос, еще не узнала о последней версии, она будет обслуживать предыдущую версию.

Это верно независимо от того, включено управление версиями или нет, потому что перезапись объекта на самом деле не является перезаписью, даже в неверсионной корзине. Это операция хранения + обновления индекса для нового места внутреннего хранилища + очистки старого места хранения. Это не задокументировано, но атомарная перезапись и модель согласованности диктуют, что это обязательно должно иметь место.