S3 Intelligent-Tiering: eligibility, archive tiers, and cost checks

S3 Intelligent-Tiering is an Amazon S3 storage class that moves eligible objects between access tiers as usage changes. It can reduce storage charges for data that becomes less active, but the result depends on object sizes, object count and how long data stays in each tier.

The first decision is whether your application must read every object immediately. The three automatic tiers retain immediate access. The optional Archive Access and Deep Archive Access tiers require a restore before an object can be read. This guide separates those choices, calculates a regional cost example and shows a narrowly scoped archive configuration.

Understand the five access tiers

An object starts in Frequent Access when it enters Intelligent-Tiering. Its storage-class value remains INTELLIGENT_TIERING as it moves between tiers. The AWS access-tier reference explains the automatic progression:

Tier	When it applies	Read access
Frequent Access	Newly entered or accessed data	Immediate
Infrequent Access	30 consecutive days without access	Immediate
Archive Instant Access	90 consecutive days without access	Immediate
Archive Access, optional	Configured inactivity threshold of 90–730 days	Restore required
Deep Archive Access, optional	Configured inactivity threshold of 180–730 days	Restore required

Do not confuse Archive Instant Access with Archive Access. Enabling Archive Access at 90 days bypasses Archive Instant Access. The Tiering API definition specifies the optional thresholds; choose them from the recovery time your application can accept.

These are tiers inside one AWS storage class. Our Amazon cloud storage guide covers the broader choice among S3, EBS, EFS and FSx. S3 API compatibility alone does not establish that another provider implements AWS Intelligent-Tiering.

Check eligibility and access patterns first

Objects smaller than 128 KB can use the class, but they remain in Frequent Access and incur no monitoring charge. Intelligent-Tiering has no minimum storage duration. These rules differ from the minimum billable sizes and durations of other classes; the S3 FAQ covers those distinctions.

Review both bytes and object counts. A collection of large exports and millions of tiny application files can have similar total storage but different tiering economics. Separate the small-object population before estimating monitoring costs.

Inactivity is about operations on the object, not its creation date alone. Reading an object with GET can bring it back to Frequent Access; HEAD and listing operations do not themselves tier it up. Copy and replication operations can also matter. Check the operation list in the AWS access-tier reference when a scheduled job appears to keep data active.

For an application that cannot tolerate a restore delay, start with the automatic tiers. Optional archiving belongs in a separate decision with a named owner for restoration, a recovery deadline and a tested way for the application to wait or report that data is unavailable.

Calculate storage and monitoring together

The following public USD rates are for US East (N. Virginia), us-east-1, checked on November 9, 2026 against the AWS regional price list, published November 4. The Frequent Access and Standard rates shown use the first 50 TB pricing band. AWS labels its binary storage billing unit GB; the example uses 1,000 GiB, or 1,000 × 2³⁰ bytes.

Charge	Rate
Frequent Access / S3 Standard	$0.023 per GB-month
Infrequent Access	$0.0125 per GB-month
Archive Instant Access	$0.004 per GB-month
Optional Archive Access	$0.0036 per GB-month
Optional Deep Archive Access	$0.00099 per GB-month
Monitoring and automation	$0.0025 per 1,000 eligible objects per month

Consider a hypothetical mature dataset: 1,000 GiB across 100,000 objects, all at least 128 KB. Assume its measured average occupancy over a full month is 20% Frequent Access, 30% Infrequent Access and 50% Archive Instant Access. Optional archive tiers are off.

Component	Calculation	Monthly cost
Frequent Access	200 × $0.023	$4.60
Infrequent Access	300 × $0.0125	$3.75
Archive Instant Access	500 × $0.004	$2.00
Monitoring	100,000 ÷ 1,000 × $0.0025	$0.25
Total of these components	$10.35 + $0.25	$10.60

The same 1,000 GiB in S3 Standard would cost $23 for storage, a $12.40 difference in this scenario. That is a calculation, not an observed bill or a first-month forecast. Newly entered data starts in Frequent Access. If the entire dataset stays there for a full month, storage plus monitoring would be $23.25.

Add migration requests, ordinary requests, data transfer, encryption-key charges and any reporting services used. The S3 pricing page distinguishes entry charges from movement between Intelligent-Tiering tiers. Optional archived objects also carry 8 KB of metadata billed at Standard rates and 32 KB at the corresponding archive rate. Those optional-tier costs are outside this example.

Move data into the class before configuring optional archives

Setting an archive configuration does not convert Standard objects into Intelligent-Tiering. AWS documents two entry paths: select Intelligent-Tiering for new uploads, or use Lifecycle to transition eligible existing objects. Follow the setup instructions for the chosen path.

For existing objects, review the whole Lifecycle policy before editing it. Current Lifecycle transition rules exclude objects under 128 KB by default; older configurations can retain different behavior. A size override does not make those objects eligible for Intelligent-Tiering’s automatic movement. Our S3 Lifecycle guide covers transitions, versions and expiration.

Choose a small prefix for the first rollout. Record its object sizes, versions, current class and existing rules. Keep an estimate of entry costs and compare later bills against the same population, so deletion or data growth does not masquerade as a tiering saving.

Scope an optional archive configuration

The following example applies only to keys beginning tiering-lab/ in an existing general purpose test bucket. It selects Archive Access after 180 days without access and Deep Archive Access after 365 days. These are example choices, not universal retention settings. Directory buckets do not support this operation.

Save this as archive-config.json:

{
  "Id": "tiering-lab-archive",
  "Filter": {
    "Prefix": "tiering-lab/"
  },
  "Status": "Enabled",
  "Tierings": [
    {
      "Days": 180,
      "AccessTier": "ARCHIVE_ACCESS"
    },
    {
      "Days": 365,
      "AccessTier": "DEEP_ARCHIVE_ACCESS"
    }
  ]
}

The configuration schema defines the ID, status, filter and tier list. Before applying it, inspect existing configurations and choose an unused ID; PUT can replace the configuration with that ID. Replace the example bucket, owner account, profile and Region with the intended test environment.

aws s3api put-bucket-intelligent-tiering-configuration --bucket amzn-s3-demo-tiering --expected-bucket-owner 111122223333 --profile tiering-lab --region us-east-1 --id tiering-lab-archive --intelligent-tiering-configuration file://archive-config.json

The PUT command requires s3:PutIntelligentTieringConfiguration. The expected-owner check protects against targeting a bucket owned by a different account. It does not replace scoped IAM permissions. Read the configuration back:

aws s3api get-bucket-intelligent-tiering-configuration --bucket amzn-s3-demo-tiering --expected-bucket-owner 111122223333 --profile tiering-lab --region us-east-1 --id tiering-lab-archive

Compare the returned ID, prefix, status and both thresholds using the GET command. A matching response proves configuration storage, not that any object has moved. The automatic tiering intervals cannot be demonstrated in a short setup session.

Inspect the tier and plan restoration

For a known test object, inspect metadata:

aws s3api head-object --bucket amzn-s3-demo-tiering --expected-bucket-owner 111122223333 --profile tiering-lab --region us-east-1 --key tiering-lab/sample.bin --query "{storageClass:StorageClass,archiveStatus:ArchiveStatus,restore:Restore}"

HeadObject returns archive-status and restore information when applicable. A missing ArchiveStatus does not distinguish Frequent Access, Infrequent Access and Archive Instant Access. For a population report, enable the Intelligent-Tiering access-tier field in S3 Inventory; treat the report as a dated snapshot.

For an object confirmed in an optional archive tier, save an empty JSON object as restore-request.json:

{}

aws s3api restore-object --bucket amzn-s3-demo-tiering --expected-bucket-owner 111122223333 --profile tiering-lab --region us-east-1 --key tiering-lab/sample.bin --restore-request file://restore-request.json

This follows AWS’s Intelligent-Tiering restore example. Do not add Days: restoration moves the object back to Frequent Access rather than creating a temporary readable copy with that lifetime. The default retrieval choice is Standard. For a noncurrent object, target the intended version ID.

Repeat HEAD to monitor restoration, then verify a successful read. An accepted request is not a completed restore. AWS describes Standard retrievals as typically 3–5 hours for Archive Access and within 12 hours for Deep Archive Access; these are not application recovery guarantees. Standard and Bulk retrievals are free in Intelligent-Tiering; Expedited retrieval is a charged option where available.

Decide from the measured result

Compare storage plus monitoring before and after the pilot, using the same object population and a meaningful observation period. Recheck objects that stayed hot, objects that never qualified, restore delays and application errors. Keep optional archive access off where the recovery requirement has not been demonstrated.

For this guide, we checked the regional rate arithmetic and validated the example request shapes locally. We did not send requests to an AWS account, observe tier transitions or test restoration. The examples are ready for a scoped test; they are not evidence of a successful production rollout.