Amazon S3に保存しているオブジェクトでストレージクラスが以下のクラスの場合、すぐにはアクセスすることができません。
- S3 Glacier Flexible Retrieval
- S3 Glacier Deep Archive
- S3 Intelligent-Tiering Archive
- S3 Intelligent-Tiering Deep Archive
そのため、上記のストレージクラスのオブジェクトにアクセスするには、復元リクエストを実行する必要があります。
わたしは復元リクエストを実行すれば、下記のようにストレージクラスが変更されるものと考えていました。
【復元前のストレージクラス】
- S3 Glacier Deep Archive
↓
【復元後のストレージクラス】
- S3 Standard
実際にはストレージクラスは変更されないため、わたしは何日間か定期的に"aws s3api head-object"コマンドを打ち続けるのでした。
今回の記事では、Amazon S3のアーカイブされたオブジェクトの復元で私が勘違いしていたことを紹介します。
Amazon S3の復元リクエスト確認で詰まった話
■なにが起きた?
先日、結合テスト手順を作成するにあたり、ストレージクラスが「Glacier Deep Archive」のS3オブジェクトを復元・取得する検証を行っていました。
テスト用のS3バケットにダミーファイルを、ストレージクラス「Glacier Deep Archive」としてアップロードし、復元コマンドを実行。
数時間後にオブジェクトのステータスを確認したところ、ストレージクラスが依然として「DEEP_ARCHIVE」のままでした。
そのとき私は、「Glacier Deep Archive からの復元は時間がかかると聞いたことがあるな」と思い出し、特に深く考えずそのまま放置してしまいました。
翌日、さらにその翌日と何日か経ってから再度ステータスを確認してみても、やはりストレージクラスは「Glacier Deep Archive」のままです。
さすがにおかしいと感じ、ここでようやく 公式ドキュメントを確認することにしました。
■S3復元リクエスト仕様
AWS 公式ドキュメントにあるAmazon S3の「アーカイブされたオブジェクトの復元」を読んでみると、
指定された期間 (日数) の間、オブジェクトの一時コピーを S3 バケットに復元する必要があります。オブジェクトの永続的なコピーが必要な場合は、オブジェクトを復元して、Amazon S3 バケット内にそのオブジェクトのコピーを作成します。
復元したオブジェクトのコピーは Amazon S3 コンソールではサポートされていません。このタイプのコピー操作には、AWS Command Line Interface (AWS CLI)、AWS SDK、または REST API を使用します。
コピーを作成してストレージクラスを変更しない限り、オブジェクトは S3 Glacier Flexible Retrieval または S3 Glacier Deep Archive ストレージクラスに保存されます。
どうやら復元リクエストはストレージクラスをSTANDARDに変更する処理ではないようです。
実際には、Glacier Deep Archiveに保管されているオブジェクトに対し、一定期間だけ通常オブジェクトと同様に取得できる状態を作る仕組みです。
復元されたかどうかを確認するには、"head-object"コマンドを使用して、"Restore"が"ongoing-request=\"false\"となっていれば復元完了です。
【期待される出力 (復元中)】
{
"Restore": "ongoing-request=\"true\"",
"LastModified": "2020-06-16T21:55:22+00:00",
"ContentLength": 405,
"ETag": "\"b662d79adeb7c8d787ea7eafb9ef6207\"",
"VersionId": "wbYaE2vtOV0iIBXrOqGAJt3fP1cHB8Wi",
"ContentType": "binary/octet-stream",
"ServerSideEncryption": "AES256",
"Metadata": {},
"StorageClass": "GLACIER"
}
【期待される出力 (復元完了)】
{
"Restore": "ongoing-request=\"false\", expiry-date=\"Wed, 12 Aug 2020 00:00:00 GMT\"",
"LastModified": "2020-06-16T21:55:22+00:00",
"ContentLength": 405,
"ETag": "\"b662d79adeb7c8d787ea7eafb9ef6207\"",
"VersionId": "wbYaE2vtOV0iIBXrOqGAJt3fP1cHB8Wi",
"ContentType": "binary/octet-stream",
"ServerSideEncryption": "AES256",
"Metadata": {},
"StorageClass": "GLACIER"
}
私は上記のアーカイブされたオブジェクトの復元の仕組みを理解していなかったため、時間を無駄にしてしまいました。
■動作確認
それでは、アーカイブされたオブジェクトの復元を試してみます。
まずはアーカイブされたオブジェクトのステータスを確認します。
aws s3api head-object --bucket amzn-s3-demo-bucket --key dir1/example.obj
【実行結果】
C:\Users\csnp0001>aws s3api head-object --bucket saito-awsclitest-bucket --key test-folder/test-file.txt
{
"AcceptRanges": "bytes",
"Expiration": "expiry-date=\"Thu, 12 Feb 2026 00:00:00 GMT\", rule-id=\"CPI-Default-LC-Policy\"",
"LastModified": "2026-01-11T02:41:42+00:00",
"ContentLength": 0,
"ETag": "\"d41d8cd98f00b204e9800998ecf8427e\"",
"ContentType": "text/plain",
"ServerSideEncryption": "AES256",
"Metadata": {},
"StorageClass": "DEEP_ARCHIVE"
}
"StorageClass"が"DEEP_ARCHIVE"で、復元リクエスト前のため"Restore"キーがないですね。
復元コマンドを実行します。
aws s3api restore-object --bucket saito-awsclitest-bucket --key test-folder/test-file.txt --restore-request Days=7,GlacierJobParameters={"Tier"="Standard"}
【実行結果】
C:\Users\csnp0001>aws s3api restore-object --bucket saito-awsclitest-bucket --key test-folder/test-file.txt --restore-request Days=7,GlacierJobParameters={"Tier"="Standard"}
C:\Users\csnp0001>
※注意 ——————————————
Windowsの場合、ドキュメントにある以下のコマンドを実行するとエラーが起きる場合があるそうです。
aws s3api restore-object --bucket amzn-s3-demo-bucket --key dir1/example.obj --restore-request '{"Days":25,"GlacierJobParameters":{"Tier":"Standard"}}'
【実行結果】
# エラー
C:\Users\csnp0001>aws s3api restore-object --bucket saito-awsclitest-bucket --key test-folder/test-file.txt --restore-request '{"Days":7,"GlacierJobParameters":{"Tier":"Standard"}}'
Error parsing parameter '--restore-request': Expected: '=', received: ''' for input:
'{Days:7,GlacierJobParameters:{Tier:Standard}}'
^
——————————————
復元コマンド実行後に、オブジェクトのステータスを確認してみます。
【実行結果】
C:\Users\csnp0001>aws s3api head-object --bucket saito-awsclitest-bucket --key test-folder/test-file.txt
{
"AcceptRanges": "bytes",
"Expiration": "expiry-date=\"Thu, 12 Feb 2026 00:00:00 GMT\", rule-id=\"CPI-Default-LC-Policy\"",
"Restore": "ongoing-request=\"true\"",
"LastModified": "2026-01-11T02:41:42+00:00",
"ContentLength": 0,
"ETag": "\"d41d8cd98f00b204e9800998ecf8427e\"",
"ContentType": "text/plain",
"ServerSideEncryption": "AES256",
"Metadata": {},
"StorageClass": "DEEP_ARCHIVE"
}
さきほどまでなかった"Restore"キーが存在し、"復元中"を示す"ongoing-request=\"true\""が返ってきていますね。
完了まで数時間かかるので、待ちます。
—— 翌日 ——
再度、オブジェクトのステータスを確認してみます。
【実行結果】
C:\Users\csnp0001>aws s3api head-object --bucket saito-awsclitest-bucket --key test-folder/test-file.txt
{
"AcceptRanges": "bytes",
"Expiration": "expiry-date=\"Thu, 12 Feb 2026 00:00:00 GMT\", rule-id=\"CPI-Default-LC-Policy\"",
"Restore": "ongoing-request=\"false\", expiry-date=\"Sun, 25 Jan 2026 00:00:00 GMT\"",
"LastModified": "2026-01-11T02:41:42+00:00",
"ContentLength": 0,
"ETag": "\"d41d8cd98f00b204e9800998ecf8427e\"",
"ContentType": "text/plain",
"ServerSideEncryption": "AES256",
"Metadata": {},
"StorageClass": "DEEP_ARCHIVE"
}
"復元完了"を示す"ongoing-request=\"false\"が返ってきました。
また、"Restore"キーの値に"expiry-date"と書かれており、復元を指定した"7日"後の日付が出力されていますね。
今回の検証は以上です。
まとめ
Amazon S3には、コストを抑えるために複数のストレージクラスが用意されています。
その中でも「Glacier Deep Archive」は、日常的にアクセスしないオブジェクトを長期間保管する用途に適したストレージクラスです。
一方で、Glacier Deep Archiveに保管されたオブジェクトへアクセスするには、事前に復元(restore)リクエストを実行する必要があり、即時に取得できるわけではありません。
また、復元リクエストはストレージクラスを変更するものではなく、一定期間のみオブジェクトを読み出し可能な状態にする仕組みである点に注意が必要です。
今回、実際に復元リクエストを実行して検証したことで、"StorageClass"の表示や復元ステータスの確認方法など、ドキュメントだけでは気づきにくい仕様を把握することができました。
運用では頻繁に発生するケースではありませんが、いざという場面で慌てないためにも、事前に理解しておくことが重要だと感じました。
参考リンク:AWS公式ドキュメント
↓ほかの協栄情報メンバーのAmazon S3についての記事を公開しています。ぜひ参考にしてみてください。
■KMSキー暗号化バケットでのS3レプリケーション設定の解決方法(齊藤弘樹)
■Amazon S3のオブジェクトのストレージクラスを知りたかっただけなのに、、、(齊藤弘樹)

