S3’s automatic optimization strategy that reduces costs even if you don’t know access patterns

When first learning S3 on AWS, one usually starts with S3 Standard. This is because it’s the most common, offers good performance, high availability, and is, above all, easy to understand. However, when moving into a real operational environment, the story changes slightly. Data that initially seemed like it would be frequently accessed might hardly be read a few weeks later, and conversely, data that was thought to be primarily for storage might suddenly be frequently read again due to analysis tasks or customer requests.

This is when the dilemma begins.

“Should I keep this data in Standard?”

“Can I move it to Standard-IA after 30 days?”

“If I send it to Glacier, costs will decrease, but what if I need to read it immediately later?”

“If I apply a lifecycle policy at the folder level, it applies equally to all objects, but what if the access patterns differ for each object?”

The storage class that reduces these concerns is S3 Intelligent-Tiering. As its name suggests, S3 monitors the access patterns of objects and automatically moves them to appropriate internal tiers based on access frequency. Users don’t have to manually decide for each object, “This is frequently accessed data,” “This data won’t be accessed much after 30 days,” or “This data is mostly for archival after 90 days.”

To summarize in one sentence:

S3 Intelligent-Tiering is a storage class that monitors object usage frequency at the object level and automatically optimizes costs for data with unpredictable access patterns.

S3 Standard is like “documents always kept on your desk.” You can view them immediately anytime, but keeping all documents on your desk incurs high space costs.

Standard-IA is similar to “documents placed in a cabinet next to your desk.” Storage costs are slightly reduced, but there might be costs when retrieving them.

Glacier Flexible Retrieval or Deep Archive is closer to “documents sent to a warehouse.” Storage costs are very low, but it takes time to retrieve them.

Intelligent-Tiering can be seen as a “manager who automatically moves documents to the desk, cabinet, or nearby storage based on their usage frequency.” Frequently viewed documents are kept on the desk, documents not viewed for a while are moved to the cabinet, and old documents are moved to a cheaper storage location. But if suddenly needed again, they are brought back to the desk.

Reasons why S3 storage class selection is difficult

S3 offers various storage classes. S3 Standard is suitable for frequently accessed data, while Standard-IA or One Zone-IA can be considered for data that is not frequently accessed but needs to be read quickly when necessary. For strong archival purposes, options like Glacier Instant Retrieval, Glacier Flexible Retrieval, and Glacier Deep Archive are available.

The problem is that it’s difficult for humans to accurately predict future access patterns of data.

For example, consider image files for a web service. Immediately after upload, users view them frequently. However, over time, most images are rarely accessed. Yet, some images might be displayed in search results, reused on event pages, or read again due to customer inquiries. Keeping all images in Standard is expensive, and moving all images quickly to IA or Glacier can cause issues with retrieval costs or restoration delays when they need to be read later.

Log data is similar. Application logs, security logs, and analytics logs might be frequently queried for the first few days or weeks. After incident analysis or security investigations are complete, access frequency drops sharply. However, there’s a possibility they might be queried again months later for auditing, forensics, compliance, or customer issue resolution.

Data lakes are also similar. Some partitions are used daily for analytical queries, while others are rarely read. Even within the same bucket and prefix, access frequency can vary per object.

In such environments, achieving perfect optimization with Lifecycle policies alone is not easy. Lifecycle is powerful but fundamentally rule-based. It’s set up like “move to Standard-IA after 30 days of creation,” or “move to Glacier after 90 days.” It moves data based on conditions like object age, prefix, or tags, rather than actual access.

Intelligent-Tiering, on the other hand, judges based on “was it actually accessed?” rather than “has time passed?” This difference is crucial.

Reasons why Intelligent-Tiering is a popular choice

1. Can start without knowing access patterns

The biggest advantage of S3 Intelligent-Tiering is that you don’t need to know access patterns. Operators don’t have to predict the usage patterns of every object. It’s especially useful for data with changing or unpredictable access patterns, such as new services, data lakes, user-uploaded content, backup data, and analytical data.

S3 Standard is a safe choice but can be expensive long-term. Standard-IA has lower storage costs but incurs retrieval fees when reading. Glacier family is cheaper but requires considering restoration time or minimum storage duration. Intelligent-Tiering reduces the burden of these choices.

Initially, data is stored in the Frequent Access tier, and if there’s no access for a certain period, it automatically moves to a cheaper internal tier. If accessed again later, it moves back up to the Frequent Access tier. Operators don’t have to make detailed judgments about “when to move it.”

2. Judges at the object level

The core of Intelligent-Tiering is object-level optimization.

If Lifecycle policies are set at the prefix level, objects within the same folder move similarly. However, in reality, even if they are in the same path, some objects are frequently read, while others are rarely. Intelligent-Tiering individually monitors the access patterns of each object.

For example, let’s say you have the following data:

images/2026/01/a.jpg is accessed daily
images/2026/01/b.jpg has no access for 40 days
images/2026/01/c.jpg has no access for 100 days

Even if these three objects are in the same prefix, Intelligent-Tiering does not treat them identically. Frequently accessed objects remain in the Frequent Access tier, objects not accessed for more than 30 days move to the Infrequent Access tier, and objects not accessed for more than 90 days move to the Archive Instant Access tier.

This structure is very advantageous for cost optimization. It’s because S3 judges based on access status for each object, rather than humans making blanket judgments at the folder level.

3. Frequent, Infrequent, Archive Instant can be used without performance degradation

Intelligent-Tiering’s automatic tiers can be broadly understood as three types:

Frequent Access tier
Infrequent Access tier
Archive Instant Access tier

These three tiers are automatically managed and provide low latency and high throughput. This means that even if data moves to the Infrequent Access tier or Archive Instant Access tier, the application does not need to make a restoration request first. It can be read directly with a standard GET request.

This is a major difference from Glacier Flexible Retrieval or Glacier Deep Archive. Glacier Flexible Retrieval or Deep Archive have lower costs but are not for immediate reading. Objects must first be restored, and restoration time must be considered. In contrast, Intelligent-Tiering’s Archive Instant Access tier is, as its name suggests, an archive-like tier that is immediately accessible.

Therefore, Intelligent-Tiering is well-suited for “data where you want to reduce costs but might need to read it suddenly.”

4. No retrieval fees

Storage classes like Standard-IA, One Zone-IA, and Glacier Instant Retrieval have lower storage costs but may incur retrieval fees when reading data. Therefore, if access frequency is higher than expected, retrieval costs might outweigh storage cost savings.

Intelligent-Tiering does not incur retrieval fees even after moving between internal tiers. Even if an object in the Infrequent Access tier or Archive Instant Access tier is read, no standard retrieval fees are charged. Furthermore, there are no separate tiering fees when tiers move within Intelligent-Tiering.

Of course, general cost factors such as S3 request costs, data transfer costs, and PUT/COPY/Lifecycle transition costs must be considered separately. However, the absence of the burden of “retrieval fees every time I read from IA” is a significant advantage of Intelligent-Tiering.

5. Low burden of minimum storage duration

Standard-IA and One Zone-IA require considering minimum storage duration. Glacier family also has minimum storage durations. Deleting too early or moving to another storage class can incur costs for the remaining period.

Intelligent-Tiering has no minimum storage duration burden in its typical automatic tier operation. This is especially useful for services with uncertain data lifespans. For user-uploaded files whose deletion time is unknown, or analytical data whose retention period varies depending on project circumstances, a structure without a minimum storage duration is convenient for operations.

How does Intelligent-Tiering monitor and decide?

To understand how Intelligent-Tiering works, you need to distinguish between “storage class” and “internal access tier.”

The storage class of an object is S3 Intelligent-Tiering. Even if an object moves to the Infrequent Access tier after 30 days or to the Archive Instant Access tier after 90 days, the storage class itself, as seen by the user, does not change to Standard-IA or Glacier Instant Retrieval.

That is, the object remains in the Intelligent-Tiering storage class, and only its internal access tier changes.

Basic Flow

When an object is stored in S3 Intelligent-Tiering, it initially starts in the Frequent Access tier. S3 then monitors the object’s access patterns.

If there is no access for a certain period, it moves as follows:


Condition	Movement Result
Object upload or immediate transition	Frequent Access tier
30 consecutive days of no access	Infrequent Access tier
90 consecutive days of no access	Archive Instant Access tier
Accessed again from Infrequent or Archive Instant state	Automatically returns to Frequent Access tier

This flow can be expressed in pseudocode as follows:

객체가 S3 Intelligent-Tiering에 저장됨
  → Frequent Access tier에서 시작

객체 크기가 128KB 미만이면
  → 자동 티어링 대상 아님
  → 감시하지 않음
  → 감시 및 자동화 요금 없음
  → Frequent Access tier 요금으로 유지

객체 크기가 128KB 이상이면
  → S3가 객체 단위 접근 패턴 감시

30일 연속 접근 없음
  → Infrequent Access tier로 이동

90일 연속 접근 없음
  → Archive Instant Access tier로 이동

Infrequent Access 또는 Archive Instant Access 상태에서 객체 접근 발생
  → Frequent Access tier로 자동 이동

The important criterion here is “period of continuous non-access.” It doesn’t simply move automatically after 30 days from object creation; it judges based on the period of non-access.

What actions are considered ‘access’?

S3 does not treat all API calls as ‘access’ equally when determining tier movement for Intelligent-Tiering. Operations that involve actually reading or writing object data are considered access.

For example, the following operations are generally considered to have accessed an object:

Download object from console
Copy object from console
GetObject
PutObject
CopyObject
UploadPartCopy
RestoreObject
CompleteMultipartUpload
Replication by S3 Batch Replication

On the other hand, the following operations are not considered access that would move an object to the Frequent Access tier:

HeadObject
GetObjectTagging
PutObjectTagging
ListObjects
ListObjectsV2
ListObjectVersions
UpdateObjectEncryption

This distinction is important in practice. For example, if merely listing objects or checking metadata caused all objects to return to the Frequent Access tier, cost optimization would be difficult. Therefore, S3 distinguishes between actual data access and management operations.

Actions that actually read or write file content are considered access,

Management operations like simple list queries or tag queries are not considered access.

What happens if optional archive tiers are enabled?

Intelligent-Tiering fundamentally provides three automatic tiers.

Frequent Access tier
Infrequent Access tier
Archive Instant Access tier

Up to this point, these are immediately accessible tiers. However, if you want lower costs and don’t need to read data immediately, you can additionally enable optional archive tiers.

The optional archive tiers are as follows:

Archive Access tier
Deep Archive Access tier

The Archive Access tier can be used for objects that have not been accessed for at least 90 days, and the Deep Archive Access tier for objects not accessed for at least 180 days. These periods can be adjusted to be longer depending on the settings.

However, these two tiers are not for immediate access. If an object enters the Archive Access or Deep Archive Access tier, it must be restored via RestoreObject before it can be read. Therefore, if your application requires immediate file reading, you should use these cautiously.

To summarize:


Category	Immediate Access Possible	Description
Frequent Access	Yes	Default tier
Infrequent Access	Yes	Automatically moves after 30 days of no access
Archive Instant Access	Yes	Automatically moves after 90 days of no access
Archive Access	Restoration required	Optional activation, restoration in minutes to hours
Deep Archive Access	Restoration required	Optional activation, for long-term storage

In an operational environment, rather than unconditionally enabling Archive Access and Deep Archive Access, you should decide based on how the data is used. Especially for data that requires immediate access, such as user downloads, web service images, or data targeted by analytical queries, using only the basic three tiers might be safer.

How are monitoring fees calculated?

Intelligent-Tiering monitors object access patterns and performs automatic movement, so there is a monthly monitoring and automation fee. Based on US East, N. Virginia, the monitoring and automation fee is $0.0025 per 1,000 objects per month.

Converted by object count, it’s as follows:


Object Count	Monthly Monitoring and Automation Fee
1,000 objects	0.0025 dollars
100,000 objects	0.25 dollars
1,000,000 objects	2.50 dollars
10,000,000 objects	25.00 dollars
100,000,000 objects	250.00 dollars

This cost alone seems very small. However, if the number of objects grows to hundreds of millions or more, it can become a non-negligible cost. Especially in structures with a very large number of small objects like log files, thumbnails, or IoT event fragments, this must be calculated.

However, objects smaller than 128KB are not subject to automatic tiering, nor are monitoring and automation fees charged for them. While these small objects can be stored in Intelligent-Tiering, they always remain at the Frequent Access tier rate.

Therefore, when looking at costs, you need to consider “object count” along with “total capacity.” This is a common mistake in S3 cost optimization. Storing 10TB with 100,000 objects is completely different from storing 10TB with 1 billion objects from a monitoring fee perspective.

Are Lifecycle and Intelligent-Tiering in competition?

Lifecycle policies and Intelligent-Tiering are not competing features but rather serve different purposes.

Lifecycle is policy-based automation. For example, it applies clear rules like “objects under logs/ prefix move to Standard-IA after 30 days, then to Glacier Deep Archive after 90 days.” If you already know the data’s lifespan and access patterns, Lifecycle can be simpler and cheaper.

Intelligent-Tiering, on the other hand, is observation-based automation. S3 monitors object-specific access patterns and automatically moves them to cheaper tiers if there’s no access. It’s advantageous when access patterns are uncertain or vary per object.

Comparing the two:


Category	Lifecycle	Intelligent-Tiering
Criterion	Days since creation, prefix, tags, etc.	Object-specific access patterns
Advantage	Strong for predictable data	Strong for unpredictable data
Disadvantage	Can move regardless of actual access	Monitoring and automation fees exist
Suitable examples	Logs, backups, data for regulatory long-term retention	Data lakes, user uploads, new service data
Operation method	Human designs rules	S3 automatically judges per object

If access patterns are clear, design Lifecycle,

If access patterns are uncertain, consider Intelligent-Tiering.

In what situations should Intelligent-Tiering be chosen?

User-uploaded data for new services

In new services, it’s difficult to predict how often data will be read. User-uploaded images, documents, videos, and attachments are often accessed frequently initially, but access frequency tends to decrease over time. However, some content might regain popularity later or be viewed due to customer inquiries.

In such cases, sending them to Standard-IA or Glacier from the start is burdensome. Using Intelligent-Tiering allows initial fast access like Standard, and then only objects with reduced access are automatically moved to cheaper tiers.

Data lakes and analytical data

Data lakes contain a mix of various data. Some data is used daily for analytical queries, while other data remains only as historical records. Access frequency can vary by partition, date, customer, or service.

If you try to classify all data accurately with Lifecycle alone, the rules become complex. Intelligent-Tiering monitors access patterns at the object level, making it well-suited for environments with diverse access frequencies like data lakes.

Security logs and audit data

Security logs are frequently queried immediately after an incident, but rarely thereafter. However, they might be needed again later for compliance or breach investigations. That is, they are close to “data that is rarely viewed normally, but needs immediate access when necessary.”

In such cases, Intelligent-Tiering, which allows immediate access even when automatically moved to Archive Instant Access, can be useful. However, if optional Archive Access or Deep Archive Access is enabled, restoration time is required, so security monitoring or incident response requirements should be checked first.

Migration data with unknown access patterns

Intelligent-Tiering can also be a good starting point when migrating large amounts of data from on-premises to S3. This is because the access patterns of existing file servers or NAS are often unknown.

Blindly keeping everything in Standard is expensive, and blindly sending everything to Glacier can cause business interruptions later. Setting Intelligent-Tiering as the default allows automatic cost reduction by observing actual access patterns.

When should Intelligent-Tiering be avoided?

Intelligent-Tiering is not always the optimal solution.

If data is always frequently read

If all objects are consistently read frequently, the advantages of Intelligent-Tiering are not significant. Objects are likely to remain in the Frequent Access tier. In this case, you might pay similar storage costs to S3 Standard plus additional monitoring fees.

For always hot data like core static assets of a web service, frequently read model files, or often referenced configuration files, Standard might be simpler.

If access patterns are clear

For example, if the lifecycle is clear, such as “this log is frequently viewed for 7 days, rarely viewed after 30 days, and deleted after 1 year,” Lifecycle might be more suitable.

If data can be moved according to fixed rules, there might be no need to use Intelligent-Tiering and pay monitoring fees.

If there are too many very small objects

Objects smaller than 128KB can be stored in Intelligent-Tiering but are not subject to automatic tiering. Monitoring fees are not charged, but they always remain at the Frequent Access tier rate. This means Intelligent-Tiering does not automatically significantly reduce costs for a large number of small objects.

In environments with a very large number of small objects, data structure improvements such as object merging, compression, partitioning, or log format improvement might be more important.

If optional Deep Archive is enabled when immediate access is required

Intelligent-Tiering’s default automatic tier, Archive Instant Access, allows immediate access. However, optional Archive Access and Deep Archive Access require a restoration process. If an application needs to read objects immediately and Deep Archive Access is enabled, a situation resembling an outage might occur.

Therefore, optional archive tiers should only be applied to “data where restoration delays are truly acceptable” for safety.

Practical Application Examples

To store newly uploaded objects in Intelligent-Tiering, you can specify the storage class in the PUT request.

aws s3api put-object 
  --bucket my-bucket-name 
  --key uploads/sample.jpg 
  --body ./sample.jpg 
  --storage-class INTELLIGENT_TIERING

You can also change the storage class by copying existing objects to Intelligent-Tiering.

aws s3api copy-object 
  --bucket my-bucket-name 
  --copy-source my-bucket-name/uploads/sample.jpg 
  --key uploads/sample.jpg 
  --storage-class INTELLIGENT_TIERING 
  --metadata-directive COPY

You can also apply Intelligent-Tiering transition using a Lifecycle policy for a specific prefix in a bucket. For example, to transition objects under uploads/ to Intelligent-Tiering 0 days after creation, you can use a policy like this:

{
  "Rules": [
    {
      "ID": "transition-to-intelligent-tiering",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "uploads/"
      },
      "Transitions": [
        {
          "Days": 0,
          "StorageClass": "INTELLIGENT_TIERING"
        }
      ]
    }
  ]
}

Application can be done as follows:

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

In practice, it’s better to divide by prefix or tag rather than applying unconditionally to the entire bucket. For example, user-uploaded files to Intelligent-Tiering, static web resources to Standard, and clear long-term retention logs to Glacier Deep Archive via Lifecycle.

Simple Checklist for Cost Assessment

Before applying Intelligent-Tiering, it’s good to ask the following questions:

Can you accurately predict the access patterns of this data?
Does the access frequency vary significantly per object?
Is there a possibility that it might be read again suddenly later?
Are unpredictable retrieval fees a concern?
Is the number of objects excessively large, leading to high monitoring fees?
Are most objects smaller than 128KB?
Can you tolerate restoration delays if optional Archive Access or Deep Archive Access is enabled?
Can this data be handled more simply and cheaply with Lifecycle?

If you answer “I don’t know the access patterns well,” “Usage frequency varies per object,” “There’s a possibility it might be read again,” or “It’s difficult for operators to adjust policies every time” to many of these questions, then Intelligent-Tiering is likely a good option.

Conversely, if patterns are clear, such as “always read frequently,” “definitely not read after exactly 90 days,” or “stored for 1 year then deleted,” then Standard or Lifecycle-based transitions might be more suitable.

Conclusion: Intelligent-Tiering is a design that acknowledges the unknown

The most dangerous thing in cloud cost optimization is false certainty. You might think, “I won’t look at this data in the future,” but it might actually be frequently read, or you might think, “This data will always be needed,” but no one looks at it for months.

S3 Intelligent-Tiering is a storage class designed on the premise of such uncertainty. Instead of humans predicting all access patterns, S3 monitors access status at the object level and automatically moves them to appropriate tiers.

Therefore, Intelligent-Tiering is not just a “cheap storage class.” More accurately, it’s an “automatic cost optimization strategy for data with unpredictable access patterns.”

It’s good to summarize it like this:

If access patterns are clear, design Lifecycle.
If access patterns are uncertain, consider Intelligent-Tiering.
If immediate access is required, use only the basic automatic tiers.
If it’s for long-term storage and restoration delays are acceptable, consider optional Archive / Deep Archive.
Always check the object count and the proportion of objects smaller than 128KB.

The key to S3 cost optimization is not simply choosing the cheapest storage class. It’s about reducing overall costs by considering data access methods, restoration requirements, request costs, and operational complexity. From that perspective, S3 Intelligent-Tiering is a very practical option that allows “operators not to have to accurately predict the future.”

Why is S3 Intelligent-Tiering a popular choice?