Scope: three AWS pages, the S3 User Guide sections "Working with archived objects" and "Restoring an archived object" and the Amazon S3 pricing page, checked October 7, 2026 (06:07 to 06:08 KST). Your bucket, Region, storage class, object sizes, lifecycle rules, account and bill are UNKNOWN to us. We have not run a restore, opened a console, executed a command or seen any invoice for this article. AWS served us the pricing page in its Korean locale, so its wording below is our English paraphrase, not a quotation.
Short answer: An object in S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive is not readable until you request a restore and wait for a temporary copy. That copy is what you read, and it is what expires. The archived object keeps its storage class the whole time, so while the copy exists you pay for both the archived object and the temporary copy. Two cases are different. S3 Glacier Instant Retrieval objects "are not archived" and the class "does not require a restore operation." The S3 Intelligent-Tiering Archive Access and Deep Archive Access tiers do need a restore request, but the object "moves back into the Frequent Access tier" instead of getting a temporary copy, and those restores don’t accept a Days value or carry an expiration date.
Which class are you actually looking at?
AWS lists four storage classes or tiers whose objects are archived and "not accessible in real time": S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive, S3 Intelligent-Tiering Archive Access and S3 Intelligent-Tiering Deep Archive Access. The rows below keep the exceptions inside the table so you don’t apply the Glacier temporary-copy model to a class that doesn’t use it.
| Class or tier | Restore request needed? | What a restore gives you | Days / expiry model | Cost caution (no rates quoted) |
|---|---|---|---|---|
| S3 Glacier Flexible Retrieval | Yes | A temporary copy in the bucket; "the object’s storage class remains the same" | You set a number of days; S3 "deletes the restored object copy" after that duration | Both the archived object and the temporary copy are billed; retrieval is charged as part of the restore request; AWS’s pricing page says Bulk retrievals and requests for this class are free, which doesn’t make the storage free |
| S3 Glacier Deep Archive | Yes | A temporary copy; storage class remains the same | Same Days and expiry model | Both copies billed; retrieval charged as part of the restore request |
| S3 Glacier Instant Retrieval | No | Not archived: "real-time access with millisecond retrieval latency" | Not applicable | AWS’s pricing page lists a retrieval charge when a GET request fetches an object from this class |
| S3 Intelligent-Tiering Archive Access / Deep Archive Access | Yes | The object "moves back into the Frequent Access tier" | Restore requests "don’t accept the Days value" and the objects "don’t have expiration dates" | "no retrieval charges for Standard or Bulk retrievals" when restoring from S3 Intelligent-Tiering |
Retrieval options also differ by class. AWS names Expedited, Standard and Bulk, and says Expedited is "only available for S3 Glacier Flexible Retrieval and S3 Intelligent-Tiering Archive Access." How long a restore takes "depends on which archive storage class or storage tier you use and which retrieval option you specify." This guide doesn’t promise a completion time for any of them.
Your pre-restore worksheet
Fill in the middle column from your own account before you submit anything. Leave a cell UNKNOWN until you have checked it, and never enter 0 for a charge you haven’t confirmed. This is a blank sheet, not an invoice or a price list.
| Line | Your value | How to fill it / what not to assume |
|---|---|---|
| Exact storage class (and version ID, if the bucket is versioned) | UNKNOWN | Read it from the object, not from the bucket name or a folder name. Glacier Instant Retrieval needs no restore; Intelligent-Tiering tiers move instead of copying |
| Region | UNKNOWN | Record it before you look up any rate; this sheet quotes none |
| Retrieval option (Expedited / Standard / Bulk) | UNKNOWN | Expedited exists only for Flexible Retrieval and Intelligent-Tiering Archive Access |
| Bytes and object count | UNKNOWN | AWS’s pricing page bills requests by request count and storage per GB; estimate both from your own inventory |
| Days you need the copy readable | UNKNOWN | Glacier classes only; Intelligent-Tiering restores don’t take Days |
| Actual expiry returned after completion | UNKNOWN | Read it from the restore status, not from your request (see the expiry section) |
| Archived-object storage (continues during the restore) | UNKNOWN | Billed at the Flexible Retrieval or Deep Archive rate on AWS’s pricing page; no figure here |
| Temporary-copy storage | UNKNOWN | AWS’s pricing page says the temporary copy is billed at the S3 Standard storage rate for the duration you chose |
| Restore request and retrieval charges | UNKNOWN | Depends on class and retrieval option; a free Bulk line for Flexible Retrieval is one line, not the bill |
| GET and other requests after the restore | UNKNOWN | A repeat restore request on an already-restored object is billed as a GET request |
| Data transfer out and other applicable charges | UNKNOWN | AWS lists transfer, data management, replication and transform/query charges as separate cost components |
What a restore actually does, in order
This is the sequence AWS documents, not instructions to run against a production bucket. Run nothing until the worksheet above is filled in.
- Confirm the class first. If the object is in S3 Glacier Instant Retrieval, stop: there is nothing to restore. If it is in an Intelligent-Tiering archive tier, you still request a restore and wait for the tier move, but the Days, expiry and permanent-copy steps below don’t apply to it.
- Decide whether the paid request is worth it. For Flexible Retrieval and Deep Archive, the restore request is where retrieval is charged, and the temporary copy adds a second storage line for as long as it exists.
- Wait for an actual completed status. AWS says you "must initiate the restore request and wait until a temporary copy of the object is available." Submitting the request is not the same as having the copy.
- Read the copy within the expiry that AWS returns. AWS keeps the temporary copy "only for the specified duration," then "deletes the restored object copy." If you need it longer, AWS says you can modify the expiration period by reissuing a restore request, and the new period is counted "relative to the current time."
- If you need durable warm access, that is a separate step. The restore doesn’t change the class. See the permanent-access section below.
How the expiry date is calculated
AWS calculates the expiry by "adding the number of days specified in the restoration request to the time when the requested restoration is completed," then rounds "to the next day at midnight Universal Coordinated Time (UTC)." AWS’s own example: a copy created on October 15, 2012 at 10:30 AM UTC with a 3-day period expires on October 19, 2012 at 00:00 UTC. The practical point is that the clock starts at completion, not at your request, so plan around the date the service reports rather than one you computed in advance.
Two things the expiry rule does not say. It doesn’t delete the archived object; it deletes the restored copy. And it says nothing about whether the archived object survives your own lifecycle rules or delete operations. Those are separate risks, and a restore doesn’t protect against them.
Permanent access needs a separate copy
AWS is direct about this: "If you want a permanent copy of the object, restore the object, and then create a copy of it in your Amazon S3 bucket." It adds that "Copying restored objects isn’t supported in the Amazon S3 console," and points to the AWS CLI, the AWS SDKs or the REST API for that copy. "Unless you make a copy and change its storage class, the object will still be stored in the S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive storage classes."
So the permanent-access decision has its own cost line (a second object in whatever class you copy it to) and its own permission question. We haven’t run that copy and can’t tell you whether your account allows it. If you go that route, use the authorised CLI, SDK or API path you already have, and confirm the result on the copied object, not on the restored one.
FAQ
Does restoring an object change its storage class? No. For Flexible Retrieval and Deep Archive, "When a temporary copy of the restored object is created, the object’s storage class remains the same," and a HeadObject or GetObject request still reports the Glacier class. Intelligent-Tiering is the exception: the object moves to the Frequent Access tier.
Does the expiry delete the original object? No. The expiry deletes the restored copy. Whether the archived object stays depends on your lifecycle rules and delete actions, which the expiry rule doesn’t cover.
Why are there two storage charges? Because both copies exist. AWS says "you pay for both the archived object and the copy that you restored temporarily," and its pricing page says the temporary copy is billed at the S3 Standard storage rate for the chosen duration while the archive keeps its own rate.
Does every Glacier class need a restore? No. S3 Glacier Instant Retrieval "does not require a restore operation." Flexible Retrieval and Deep Archive do.
How do I check the real status and expiry? AWS says you can check "the status of a restore request or the expiration date by using the Amazon S3 console, Amazon S3 Event Notifications, the AWS CLI, or the Amazon S3 REST API." In the console, the object page shows "Restoration in progress" or "Restoration complete," plus a "Restoration expiry date" for Glacier classes. Event Notifications can send the s3:ObjectRestore:Completed event, and the HeadObject operation returns whether the restore is ongoing and, if applicable, the expiry date.
Next step
Fill in the worksheet from your own bucket before you submit a paid restore request. Facts checked October 7, 2026 against the S3 User Guide pages Working with archived objects and Restoring an archived object, and the Amazon S3 pricing page. AWS can change these pages and its rates, so re-check them and the current rates that apply to you before you rely on this guide. Nothing here is a test result, a guarantee of recovery or a statement about your permissions.