Представьте это так:
Когда вы переносите объект из S3 в класс хранилища Glacier, S3 сохраняет объект в Glacier ... используя учетную запись AWS, принадлежащую S3.
Те объекты в S3, которые используют класс хранилища GLACIER, находятся не в «ваших» хранилищах Glacier, а в хранилищах, принадлежащих S3.
Это согласуется с внешними наблюдениями:
Вы не можете увидеть эти объекты S3 в хранилищах из консоли Glacier.
Вам не нужно предоставлять S3 какие-либо разрешения IAM для доступа к Glacier (напротив, вы действительно должны предоставить S3 разрешение на публикацию уведомлений о событиях в SQS, SNS или Lambda)
Glacier не выставляет счет за объекты класса хранения Glacier, в отличие от S3.
В этом свете то, чего вы пытаетесь достичь, совершенно иное. Вы хотите сохранить некоторые архивы в вашем хранилище Glacier с помощью вашей политики, и этот контент в настоящее время просто «случайно» хранится в S3.
Решение - загрузка с S3 и последующая загрузка в Glacier.
Но это не обеспечивает целостность данных и не защищает от потери данных.
Целостность полезной нагрузки может быть гарантирована при загрузке в Glacier, поскольку алгоритм хеширования дерева эффективно предотвращает поврежденные загрузки.
Загрузка с S3, если объект не сохранен с помощью SSE-C, ETag - это хеш MD5 сохраненного объекта, если используется загрузка отдельных частей, или хеш MD5 в шестнадцатеричном коде объединенных двоично-кодированных хэшей MD5 частей, за которым следует - и количество частей. В идеале при загрузке на S3 лучше хранить хэш (например, sha256) в метаданных объекта, например x-amz-meta-content-sha256.
Защита от потери данных - да, здесь Glacier предлагает больше функций, но S3 не лишен возможности здесь: политики корзины с совпадающим действием DENY всегда переопределяют любое конфликтующее действие ALLOW, независимо от того, является ли оно в политике корзины или любой другой политике IAM (например, роли, пользователя).
person
Michael - sqlbot
schedule
24.01.2017
