Cloud / Amazon S3 Glacier Interview questions

Amazon S3 Glacier is a family of archival storage classes inside Amazon S3, built for data you must keep for years but rarely read. You pay far less per GB-month than S3 Standard, and in return you accept retrieval fees, minimum storage durations and, for two of the classes, a wait before the data can be read.

The family has three members: Glacier Instant Retrieval, Glacier Flexible Retrieval and Glacier Deep Archive. Objects stay in your normal buckets, so the same S3 APIs, IAM policies, encryption settings and lifecycle rules apply.

Don't mix it up with the older standalone Amazon Glacier service (vaults and archives). That service still exists, but it has its own API and is not what people usually mean today.

There are three, and they differ mainly in how fast you can read the data and how long you must keep it.

Notice that GLACIER in the API means Flexible Retrieval. That value predates the rename, so it was never changed. Choose a class based on how often and how urgently you will read the data.

S3 Glacier Instant Retrieval is the archive class for data that is touched roughly once a quarter but must come back in milliseconds when someone asks. It delivers the same latency and throughput as S3 Standard, and a normal GET works with no restore request.

The trade-offs are a 90-day minimum storage duration, a 128 KB minimum billable object size and a per-GB retrieval fee. It is designed for 99.9% availability and stores data across at least three Availability Zones.

Typical fits are medical images, news and media archives, and user-generated content that is old but still occasionally opened.

S3 Glacier Flexible Retrieval (formerly just S3 Glacier) is for archive data accessed once or twice a year and retrieved asynchronously. An object in this class cannot be read directly. You submit a restore request, and S3 creates a temporary copy that lives for the number of days you choose.

It offers three retrieval tiers:

• Expedited - typically 1-5 minutes
• Standard - typically 3-5 hours
• Bulk - typically 5-12 hours, with no per-GB retrieval charge

Other things to remember: a 90-day minimum storage duration and about 40 KB of metadata overhead per object.

S3 Glacier Deep Archive is the lowest-cost storage class in S3, roughly $1 per TB-month in us-east-1 (check the pricing page for current numbers). It targets data read less than once a year, such as regulatory records, scientific datasets and replacements for tape libraries.

Retrieval is asynchronous with two tiers: Standard (within about 12 hours) and Bulk (within about 48 hours). There is no Expedited tier.

Objects carry a 180-day minimum storage duration and about 40 KB of per-object overhead. Durability is 99.999999999%, with data stored across at least three Availability Zones.

The right class depends on how the data will be read later:

• Regulatory and compliance records - Deep Archive, often with S3 Object Lock for write-once protection.
• Backups and disaster-recovery copies - Flexible Retrieval, when a few hours of restore time is acceptable.
• Media and medical image archives - Instant Retrieval, because users still expect an image to open at once.
• Tape replacement - Deep Archive or Flexible Retrieval through Tape Gateway.
• Old logs and raw datasets - kept for audits or model reproducibility, moved there by lifecycle rules.

If something is read daily or weekly, Glacier is the wrong place; retrieval fees will erase the storage savings.

All three classes are designed for 99.999999999% (11 nines) durability and store data redundantly across a minimum of three Availability Zones.

Durability protects against hardware loss, not against your own mistakes. If someone deletes or overwrites an object, it is gone unless you also use versioning, Object Lock or replication.

Availability and durability answer different questions. Availability is whether a request succeeds right now; durability is whether the data still exists years later. A 99.9% design tolerates slightly more brief errors than a 99.99% one, so clients should retry with exponential backoff.

You choose the tier in the GlacierJobParameters of the restore request. The faster the tier, the more you pay per GB, so use Bulk whenever the deadline allows.

You are billed for the tier you request, not for how long it actually took. S3 normally meets the stated windows, but they are targets rather than guarantees, so don't build a hard SLA around exact minutes. Deep Archive offers only the Standard and Bulk equivalents.

Each class bills a minimum number of days: 90 for Instant and Flexible Retrieval, 180 for Deep Archive. If you delete, overwrite or transition an object out before that point, S3 charges the prorated storage for the remaining days.

Example: you put an object in Deep Archive and delete it after 30 days. You are billed for the remaining 150 days, at the time of deletion. Moving it to another class through a lifecycle rule triggers the same charge.

The clock starts when the object lands in that class, and an overwrite counts as a delete. A rule that moves an object into Instant Retrieval at day 30 and on to Deep Archive at day 60 pays the early-deletion portion for the first class.

A vault is the container for archives in the original standalone Amazon Glacier service. It has a name unique within your account and Region, an ARN, and optional settings: a vault access policy, a vault lock policy and SNS notifications for completed jobs.

You can create up to 1,000 vaults per Region per account. Data in a vault does not appear in the S3 console; you reach it through the Glacier API, CLI or SDKs.

AWS now steers new workloads toward the S3 Glacier storage classes, but vaults remain for existing archives.

An archive is the basic storage unit in a vault: a file, backup or any binary blob up to 40 TB. A single request can upload up to 4 GB; beyond that you use multipart upload.

Archives are immutable and identified by a system-generated archive ID, not by a name you choose. You can add a description of up to 1,024 bytes.

To change an archive, upload a new one and delete the old. Keep your own index (archive ID to original file name), because the vault inventory is the only listing and it lags.

The limits differ between the two Glacier flavours.

In practice, very large archives make restores awkward, because a restore brings back the whole object. Splitting data into sensible bundles is usually wiser than hitting the ceiling.

For anything above 5 GB you must use multipart upload. The AWS CLI does this automatically for aws s3 cp once a file passes the multipart threshold (8 MB by default), so you rarely script it by hand.

Vault Lock is a compliance control for the standalone Glacier service. You attach a vault lock policy, for example denying deletion of any archive younger than 365 days, and once the lock is completed that policy can never be changed or removed. It supports write-once-read-many requirements such as SEC 17a-4.

The process has two steps:

1. initiate-vault-lock returns a lock ID and puts the policy in an InProgress state for 24 hours, so you can test it.
2. complete-vault-lock with that lock ID makes it permanent. If you do nothing in 24 hours, or call abort, the lock is discarded.

This is separate from S3 Object Lock, which does the same job for S3 buckets.

Provisioned capacity guarantees that your Expedited retrievals from Glacier Flexible Retrieval can be served when you need them. Each unit ensures at least three expedited retrievals every five minutes and up to 150 MB/s of throughput, and is billed per month.

Without it, Expedited requests are on-demand and can be rejected during rare periods of high demand with an InsufficientCapacityException. Buy units only if minute-level access is a real requirement, such as an emergency restore runbook.

Provisioned capacity has no effect on Standard or Bulk retrievals. If an Expedited request fails with InsufficientCapacityException, you can retry later or fall back to the Standard tier, which takes hours instead of minutes.

Storage per GB-month is only part of the bill. Watch for:

• Retrieval fees per GB, which vary by class and tier.
• Request fees for uploads, lifecycle transitions and restore requests, charged per 1,000.
• Early deletion charges when objects leave before the minimum duration.
• Per-object overhead of 40 KB in Flexible Retrieval and Deep Archive (32 KB at the archive rate, 8 KB at the Standard rate).
• Temporary copy storage in S3 Standard while a restored object is available.
• Data transfer out to the internet, and monthly charges for provisioned capacity units.

Every new object in S3, including the Glacier classes, is encrypted at rest by default with SSE-S3 (AES-256). You can choose SSE-KMS or DSSE-KMS instead for key-level audit and control. Data in transit uses TLS. The standalone vault service always encrypts archives server-side with AES-256.

One practical warning: if you pick SSE-KMS for a ten-year archive, the KMS key must stay enabled for ten years. Disabling or deleting it makes the data unreadable, no matter what class it sits in.

Encryption doesn't change how a restore works for the caller, but with SSE-KMS the caller also needs kms:Decrypt on the key. Test that in a restore drill, not during an audit.

A vault inventory is the list of archives currently in a vault: archive IDs, creation dates, sizes, descriptions and checksums. Glacier refreshes it about once a day, so recent uploads or deletes may not show yet.

You can't list a vault in real time. You start an inventory-retrieval job, wait (typically 3-5 hours), then download the JSON or CSV output, which stays available for at least 24 hours. For buckets in the S3 classes, the equivalent is S3 Inventory.

Save the output somewhere permanent, such as S3 or a database, because the job result is only available for a limited time after it completes.

Retrieval policies are an account-level, per-Region setting in the standalone Glacier service that stops retrievals from running up the bill. There are three options:

• Free Tier Only - requests that would exceed your free retrieval allowance are rejected.
• Max Retrieval Rate - you cap retrieval throughput in GB per hour; requests that would push past the cap are rejected.
• No Retrieval Limit - nothing is blocked, so cost control is up to you.

A rejected request fails with an error rather than queueing, so a strict policy can surprise an urgent restore. Review the policy before you need it, and check the current Glacier documentation for how it interacts with each retrieval tier.

S3 Intelligent-Tiering moves objects between tiers automatically based on access. Three tiers are always active: Frequent, Infrequent (30 days without access) and Archive Instant Access (90 days).

Two further tiers are optional and must be enabled in a configuration: Archive Access (objects untouched for 90 to 730 days; restore in roughly 3-5 hours) and Deep Archive Access (180 to 730 days; restore within about 12 hours). Objects in these two need a RestoreObject call before reading.

There are no retrieval fees; you pay a small per-object monitoring and automation fee instead.

Both are archival classes that need a restore request before reading. Deep Archive trades speed for the lowest price in S3.

Prices change, so confirm them on the pricing page. The structural differences above are what interviewers care about.

Both return data in milliseconds, so the choice is purely about access frequency and cost shape.

As a rule of thumb: the less often you read, the more the cheaper storage of Instant Retrieval outweighs its higher retrieval fee.

The shape of the cost is the point: Instant Retrieval's storage is roughly two-thirds cheaper, but its per-GB retrieval fee is about three times higher (check current pricing). Both bill objects under 128 KB as 128 KB, so tiny files hurt in either class.

The storage classes are the recommended path for new workloads because you manage archives with the same tools as the rest of S3. Vaults mostly remain for older systems.

Restoring is asynchronous. You ask S3 to rebuild a readable copy, then come back later.

sequenceDiagram
  participant C as Client
  participant S as S3
  participant G as Archive tier
  C->>S: RestoreObject (Days, Tier)
  S-->>C: 202 Accepted
  S->>G: Retrieve data
  G-->>S: Data ready
  S-->>C: Event: ObjectRestore:Completed
  C->>S: HEAD (x-amz-restore)
  C->>S: GET object
  Note over S: After Days, temp copy removed
  S-->>C: Event: ObjectRestore:Delete

1. Submit RestoreObject with the tier and the number of days.
2. S3 returns 202 Accepted and starts the retrieval; time depends on the tier.
3. A temporary copy appears next to the archived original, billed as S3 Standard.
4. You GET the object normally while the copy exists.
5. When the days run out the copy is deleted; the archived original was never touched.

The request can come from the console, CLI or SDK; only the Days and Tier fields matter. A running restore can be sped up, and a finished one extended, which is covered in the question on repeated restore requests.

The object is in Glacier Flexible Retrieval or Deep Archive (or an Intelligent-Tiering archive tier) and has not been restored. S3 refuses the read with a 403 InvalidObjectState error, because the bytes are not online.

Fix it in this order:

1. Run head-object and look at StorageClass and the Restore field.
2. Issue a RestoreObject request.
3. Wait until ongoing-request turns false, then read the object.

CopyObject on an unrestored archived object fails with the same error. Glacier Instant Retrieval never causes it, since those objects are readable at once.

In an application, catch this error, check the storage class and start a restore instead of failing silently. A common pattern is a thin service that tells the user the file is being retrieved, then waits for the restore-completed event.

Lifecycle rules move data only down a waterfall from warmer to colder classes. They never move it back up:

flowchart LR
  A["S3 Standard"] --> B[Standard-IA]
  B --> C[Intelligent-Tiering]
  C --> D["One Zone-IA"]
  D --> E["Glacier Instant Retrieval"]
  E --> F["Glacier Flexible Retrieval"]
  F --> G["Glacier Deep Archive"]

You may skip steps, for example Standard straight to Deep Archive. Three rules to remember: nothing transitions back to Standard, an object in Flexible Retrieval can only move on to Deep Archive, and Deep Archive is the end of the line. Moving to Standard-IA or One Zone-IA also requires the object to be at least 30 days old, while the Glacier classes have no such wait.

Create a lifecycle configuration with Transitions entries. This one moves logs to Instant Retrieval after 30 days, Deep Archive after 180, and deletes them after seven years:

{
  "Rules": [{
    "ID": "archive-logs",
    "Status": "Enabled",
    "Filter": { "Prefix": "logs/" },
    "Transitions": [
      { "Days": 30,  "StorageClass": "GLACIER_IR" },
      { "Days": 180, "StorageClass": "DEEP_ARCHIVE" }
    ],
    "Expiration": { "Days": 2555 }
  }]
}

aws s3api put-bucket-lifecycle-configuration --bucket my-bucket --lifecycle-configuration file://lifecycle.json

Days count from object creation. Transitions only go downward; lifecycle can't pull data back to Standard. By default, objects smaller than 128 KB are not transitioned unless you set a size filter. Each transition is a billable request.

A rule can also filter by tag or object size, so you can archive only objects tagged retention=long.

Each object carries about 40 KB of overhead: 32 KB billed at the archive rate for index data and 8 KB billed at the S3 Standard rate for the name and metadata. A 2 KB log file is therefore billed like a 42 KB object.

Example: 10 million objects of 5 KB hold only about 50 GB of real data, yet carry roughly 400 GB of overhead. On top of that, every object adds its own transition request fee and, later, its own restore request.

The fix is to bundle small files into larger tar, zip or Parquet objects before archiving. Instant Retrieval takes a different approach: it bills small objects as 128 KB instead.

Early deletion charges appear whenever an object leaves a class before its minimum (90 or 180 days). Avoiding them is mostly about rule design:

• Set Expiration later than the minimum duration of the class the object landed in. Expiring logs at 90 days after moving them to Deep Archive wastes 90 days of billed storage.
• Don't archive data that gets rewritten. Each overwrite deletes the old object, and with versioning that noncurrent version still counts.
• Don't chain transitions too tightly, such as Instant Retrieval at day 30 and Flexible at day 60.
• If the lifetime is uncertain, keep the data in Standard-IA or Intelligent-Tiering until you know.

Cost Explorer shows the damage under usage types containing EarlyDelete.

Use S3 Batch Operations with the Restore objects operation (S3InitiateRestoreObject) instead of looping over single requests.

1. Build a manifest: an S3 Inventory report or a CSV of bucket and key pairs.
2. Create a Batch Operations job and choose the restore operation, with the number of days and the tier (Bulk if you can wait).
3. Give the job an IAM role with s3:RestoreObject on the bucket.
4. Add a completion report location so you can see which keys succeeded.
5. Run it, then watch restore events or the completion report.

Batch Operations only starts the restores. The data is readable when each individual restore completes, which can be hours later.

Turn on S3 Event Notifications (or EventBridge) for the restore events:

• s3:ObjectRestore:Post - a restore was initiated
• s3:ObjectRestore:Completed - the temporary copy is ready
• s3:ObjectRestore:Delete - the temporary copy expired

Targets can be SNS, SQS, Lambda or EventBridge. A common pattern is a Lambda function triggered by Completed that copies the object to a processing bucket before the temporary copy expires. Polling head-object works too, but it is wasteful for large batches.

An EventBridge rule for the completed event looks like this:

{
  "source": ["aws.s3"],
  "detail-type": ["Object Restore Completed"],
  "detail": { "bucket": { "name": ["my-archive-bucket"] } }
}

EventBridge is the better choice when several consumers need the same event. The notification says the copy is ready, not how long it stays; it expires after the Days you requested, so process it promptly.

A restore gives you only a temporary copy. To move the object back to a readable class for good, copy it onto itself with a new storage class once the restore is complete:

aws s3 cp s3://my-archive-bucket/logs/2019.tar s3://my-archive-bucket/logs/2019.tar --storage-class STANDARD

With versioning on, this creates a new version. Two follow-ups matter: the new object starts a fresh minimum-duration clock, and an existing lifecycle rule may archive it again, so adjust or exclude it with a tag. For many objects, use Batch Operations with a Copy action.

If you only need to read the object once, don't copy it at all. Download it within the Days window and let the temporary copy expire. Copying back to Standard adds a request fee and starts billing Standard storage for as long as the object stays there.

Pick Deep Archive when all of these hold: the data is read less than once a year, a wait of 12-48 hours is acceptable, and you will keep it for at least 180 days. Typical cases are seven-to-ten-year financial or healthcare retention and tape replacement.

Stay on Flexible Retrieval when you may need data in minutes (Expedited), when reads happen once or twice a year, or when retention is short and the 180-day minimum would add charges.

The storage saving is about 70%, but Deep Archive's retrieval fees make it a poor choice if you restore large volumes often.

Choose Instant Retrieval when the data is old but users or applications still expect an immediate answer. There is no restore step, so no workflow for asynchronous retrieval, no event handling and no temporary copy to track.

It fits unpredictable, occasional reads, such as an image archive or customer documents opened a few times a quarter. Flexible Retrieval costs a little less to store and has cheaper retrievals, but only wins if you can truly afford the wait and the extra restore plumbing.

The deciding factor is often volume, not speed. Flexible Retrieval has a free Bulk tier and a cheap Standard tier, so restoring large volumes can cost less than Instant Retrieval's per-GB fee. Ask how much you will actually read, and how often.

Use lifecycle when age predicts access. Use Intelligent-Tiering when it doesn't. If you enable the Archive Access tiers, remember that applications will start hitting restore delays on objects that went cold.

Example: application logs older than 30 days are almost never read, so a lifecycle rule to Glacier is cheaper. A shared data lake where teams revive old datasets at random suits Intelligent-Tiering, because its automatic tiers never need a restore.

Object Lock is a bucket feature, so it works the same in any storage class, including Deep Archive. It needs versioning and gives write-once-read-many protection per object version:

• Governance mode - users with special permission can override.
• Compliance mode - nobody, including the root user, can shorten or remove retention.
• Legal hold - no retention date; stays until someone with permission removes it.

Compliance mode plus Deep Archive gives you a cheap, immutable store. A lock blocks deletion and overwriting of that version, but never blocks restores or reads.

Two practical details: a legal hold can freeze a single object version for an investigation without touching its retention date, and you can set a default retention on the bucket so uploads never end up unprotected by accident.

The lock policy is stronger: a deny in it cannot be overridden by any later access policy edit.

Typical split: the lock policy carries the non-negotiable rule, while the access policy covers day-to-day permissions for backup operators. An explicit deny in either one wins. A lock policy that blocks deletion of archives younger than a year looks like this:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "deny-early-delete",
    "Principal": "*",
    "Effect": "Deny",
    "Action": "glacier:DeleteArchive",
    "Resource": "arn:aws:glacier:us-east-1:111122223333:vaults/compliance-vault",
    "Condition": { "NumericLessThan": { "glacier:ArchiveAgeInDays": "365" } }
  }]
}

Test it with real delete attempts during the 24-hour InProgress window, since a mistake is permanent after completion.

Lifecycle rules treat each version separately. Transitions apply to the current version, and NoncurrentVersionTransitions apply to older versions, counted from the moment they became noncurrent. Each version has its own minimum duration and its own 40 KB overhead.

Restores are also per version: you pass a versionId to RestoreObject, otherwise S3 restores the current one.

The common trap is overwrite-heavy data. Every overwrite creates a noncurrent version that keeps costing archive storage until you add NoncurrentVersionExpiration (optionally with NewerNoncurrentVersions to keep a few).

A rule for old versions looks like this:

{
  "Rules": [{
    "ID": "old-versions",
    "Status": "Enabled",
    "Filter": { "Prefix": "" },
    "NoncurrentVersionTransitions": [{ "NoncurrentDays": 30, "StorageClass": "GLACIER" }],
    "NoncurrentVersionExpiration": { "NoncurrentDays": 400 }
  }]
}

Expiring at 400 days keeps each version in Flexible Retrieval well past its 90-day minimum, so no early-deletion charge applies.

• Use Bulk whenever the deadline allows; Flexible Retrieval Bulk has no per-GB fee.
• Right-size your archives. A restore returns the whole object, so a 200 GB tarball restored to read one file costs 200 GB of retrieval.
• Set sensible Days. Too short and you re-restore; too long and you pay Standard storage for the temporary copy.
• Avoid Expedited unless it is a true emergency, and skip provisioned capacity otherwise.
• Batch restores with S3 Batch Operations and an inventory-driven manifest, so you only restore what you listed.
• Use Instant Retrieval for data that is read unpredictably; no restore means no restore request fees.

Run restores in the same Region as the consumer so you don't add transfer charges.

Lifecycle design matters too. Archiving after 180 days of silence instead of 30 cuts how often you restore. A restore that happens once is cheap; a restore that happens weekly means the data went cold too early.

1. Break the bill down. In Cost Explorer or the Cost and Usage Report, group by usage type and look for EarlyDelete, retrieval and request lines.
2. Check S3 Storage Lens for object counts and average size per class; millions of tiny archived objects point to overhead and request fees.
3. Review lifecycle rules for churn, such as short expirations after a transition or data rewritten daily.
4. Look at restore activity through CloudTrail data events or S3 server access logs: who restored what, and with which tier.
5. Check for Expedited use and any provisioned capacity units that were bought and forgot about.

Once you find the cause, put a Budgets alert on the specific usage type so it doesn't surprise you again.

Record one month of normal charges as a baseline so spikes stand out. A frequent culprit is a backup job that rewrites 'archived' objects daily, producing early-deletion and request charges that dwarf the storage line.

In the vault service, retrieval is a job, not a read:

sequenceDiagram
  participant A as Application
  participant G as Glacier vault
  participant N as SNS topic
  A->>G: InitiateJob (archive-retrieval, tier, archive ID)
  G-->>A: Job ID
  G->>N: Job completed notification
  A->>G: DescribeJob (optional polling)
  A->>G: GetJobOutput (optional byte range)
  G-->>A: Archive data + tree hash

Expedited takes about 1-5 minutes, Standard 3-5 hours and Bulk 5-12 hours. Job output stays available for at least 24 hours after completion. You can retrieve a megabyte-aligned range of an archive instead of the entire thing, and verify the returned tree hash.

For a range retrieval, the range must be megabyte-aligned (starting on a 1 MB boundary and ending on one, or at the archive's end), so you only retrieve the bytes you need. Large outputs can be downloaded through several GetJobOutput calls with Range headers, each verified with its own tree hash.

For archives beyond a single request (4 GB), or for resilience on large files, use multipart upload:

1. InitiateMultipartUpload with a part size and receive an upload ID.
2. UploadPart for each part with a content range and checksums; parts can run in parallel and be retried alone.
3. CompleteMultipartUpload with the total archive size and the tree hash of the whole archive.
4. Glacier returns the archive ID.

Part size must be 1 MB multiplied by a power of two, up to 4 GB, and an upload can have at most 10,000 parts, which gives the 40 TB ceiling. The AWS CLI and SDK high-level helpers do the splitting and hashing for you.

If a part fails, only that part is re-sent. Use AbortMultipartUpload on failed attempts so they don't linger, and ListMultipartUploads to find unfinished ones.

A tree hash is the checksum Glacier uses to verify data integrity. You split the data into 1 MB chunks, compute a SHA-256 of each, then repeatedly hash pairs of hashes together until a single root hash remains.

flowchart TD
  A["Chunk 1 hash"] --> E["Pair hash 1-2"]
  B["Chunk 2 hash"] --> E
  C["Chunk 3 hash"] --> F["Pair hash 3-4"]
  D["Chunk 4 hash"] --> F
  E --> R["Root tree hash"]
  F --> R

You send it with uploads, and Glacier recomputes it and rejects a mismatch. Because it is built from small blocks, each part or range can be verified on its own, which a single whole-file digest can't do.

If a level has an odd number of nodes, the last hash is promoted unchanged to the next level. The root hash is what you pass at upload; if Glacier computes a different root, the upload is rejected. The SDKs and CLI compute it for you, but custom upload clients must implement it.

Layer the controls so that nobody, including admins, can quietly destroy or lose the data:

flowchart LR
  A["Source system"] --> B["Primary bucket: versioning + Object Lock Compliance"]
  B --> C["Deep Archive storage class"]
  B --> D["Replication to second Region or account"]
  B --> E["SSE-KMS key with protected policy"]
  B --> F["CloudTrail data events + S3 Inventory"]

• Object Lock in Compliance mode with a retention period that matches the regulation.
• Deep Archive, written directly or via lifecycle, for the lowest cost.
• Replication to another Region or account for resilience against account compromise.
• A KMS key that is never scheduled for deletion during the retention period.
• Audit trail: CloudTrail data events and periodic S3 Inventory reports.
• A tested restore runbook using Batch Operations.

Test the whole path at least yearly: restore a sample, verify its checksum, and confirm the KMS key policy still lets the restore role decrypt.

Create an S3 replication rule (CRR) and set the destination storage class to DEEP_ARCHIVE, GLACIER or GLACIER_IR. Replication needs versioning on both buckets and an IAM role that S3 can assume.

A rule replicates only new objects. For data that already exists, run S3 Batch Replication.

Because replication copies content, check the current S3 documentation for how objects already sitting in an archive class at the source behave. The safest design is to replicate at write time, then let lifecycle archive the source later.

Replicas keep their metadata and tags, and each replica is a new object, so its minimum-duration clock starts when replication happens. Replicating to a bucket in a separate account adds protection against account compromise. Replication Time Control is optional and rarely worth paying for with archive data.

Tape Gateway, part of AWS Storage Gateway, presents an iSCSI virtual tape library to your existing backup software such as Veeam or Veritas, so no application changes are needed.

Active virtual tapes are stored in S3. When the software ejects a tape, the gateway moves it to the archive, which is backed by S3 Glacier Flexible Retrieval or Glacier Deep Archive depending on the tape pool you choose.

To read an archived tape you retrieve it back into the library: roughly 3-5 hours from Flexible Retrieval, about 12 hours from Deep Archive.

Recently written tapes behave like ordinary cloud storage until ejected, so recent restores are fast. Pick the tape pool when you create a tape, so decide up front which tapes belong in Deep Archive. The draw is cost: you replace tape hardware, couriers and off-site vaulting with per-GB storage.

It depends on the state of the first request:

• Restore still in progress, same tier: S3 returns 409 RestoreAlreadyInProgress.
• Restore in progress, faster tier: the request upgrades the speed, for example Bulk to Standard.
• Restore already finished: a new request with a larger Days value extends the expiry of the temporary copy.

So repeating the call is safe; it won't create a second copy or a double charge for the same retrieval.

To keep a copy alive while a team is still working, re-issue the request with a longer Days value:

aws s3api restore-object --bucket my-archive-bucket --key logs/2019.tar --restore-request '{"Days":14,"GlacierJobParameters":{"Tier":"Standard"}}'

Ask for a faster tier in the same call if you need it sooner than the original request promised.

Call head-object and read the Restore field, returned in the x-amz-restore header:

aws s3api head-object --bucket my-archive-bucket --key logs/2019.tar

• ongoing-request="true" - restore is still running.
• ongoing-request="false", expiry-date="..." - the temporary copy is ready until that date.
• No Restore field - nothing was requested, or the copy has expired.

The same response shows StorageClass, which is how you confirm the object is archived in the first place.

In scripts, poll every few minutes. Standard and Bulk restores take hours, so polling every few seconds just burns API calls. Better still, skip polling and react to ObjectRestore:Completed events.

A classic failure is a copy expiring while a long download is still running, so check the expiry date before starting a large transfer.

Restores cost real money, so gate the s3:RestoreObject permission. One pattern is a bucket policy that denies it to everyone except an archive-admin role:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyRestoreExceptArchiveAdmins",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:RestoreObject",
    "Resource": "arn:aws:s3:::my-archive-bucket/*",
    "Condition": { "StringNotLike": {
      "aws:PrincipalArn": "arn:aws:iam::111122223333:role/ArchiveAdmin" } }
  }]
}

Add s3:PutLifecycleConfiguration to your tightly controlled permissions as well, since lifecycle decides what gets archived. Log RestoreObject calls with CloudTrail data events and put a budget alarm on retrieval usage.

Service control policies can enforce the same deny across a whole AWS Organization, and permission boundaries stop developers from granting themselves the action later. Copying an archived object also requires it to be restored first, so gating s3:RestoreObject covers that path as well.

Design the archive unit before you upload. The recipe is aggregate, index, then archive:

1. Bundle files by time or prefix (for example one tar per day or per customer) so a typical restore needs only one bundle.
2. Keep a small index (in DynamoDB or a manifest) mapping each file to its bundle and byte offset.
3. After restoring a bundle, use a ranged GET to pull just the file you need.
4. Use the ObjectSizeGreaterThan lifecycle filter so tiny leftovers aren't transitioned and charged the overhead.

Aim for bundles in the tens of MB to a few GB: big enough to avoid the 40 KB overhead and request fees, small enough that restoring one doesn't cost a fortune.

For large sets, don't send millions of HEAD requests, which are billed per request. Rely on restore events or the Batch Operations completion report instead.

flowchart LR
  A["Inventory job"] --> B["Archive list"]
  B --> C["Retrieval jobs, Bulk tier"]
  C --> D["Verify tree hash"]
  D --> E["PutObject to S3 with target class"]
  E --> F["Validate counts and checksums"]
  F --> G["Delete archives and vault"]

There is no in-place conversion, so every archive is retrieved and written to S3. AWS publishes a solution built on Step Functions and Lambda that automates this at scale.

• Start with an inventory to get archive IDs and descriptions; use them to derive object keys.
• Use Bulk retrievals to keep fees low, and pace jobs to respect throughput limits.
• Validate the tree hash, then write directly into the target class such as DEEP_ARCHIVE.
• Delete the vault only after verifying counts and checksums; a vault must be empty (per its inventory) before it can be removed.