Object Storage Storage Tiers

The Standard tier is the primary, default storage tier used for Object Storage service data. The Standard storage tier is "hot" storage used for data that you need to access quickly, immediately, and frequently. Data accessibility and performance justifies a higher price to store data in the Standard tier.

You choose a default storage tier (Standard or Archive) when you create a bucket. When set at bucket creation, you cannot change the default storage tier for a bucket. When you upload objects to a bucket, the objects are automatically assigned the default storage tier of the bucket (Standard). You can, however, change the storage tier of an object to either Infrequent Access or Archive.

Standard storage tier buckets can contain a mix of objects with different storage tier assignments. An object remains in the Standard bucket, even if the object is archived, restored, or its tier assignment is changed.

When you choose a Standard default storage tier during bucket creation, you can also enable Auto-Tiering. Auto-Tiering helps you reduce storage costs by automatically moving objects between the Standard and Infrequent Access storage tiers based on data access patterns. See Auto-Tiering for details.

Some primary use cases for the Standard storage tier include the following:

• Content repository for accessible scalable data, images, logs, and video
• Repository for accessible backups
• Data repository for Hadoop/big data. Provides a scalable storage platform to store large datasets and operate seamlessly on those datasets. The HDFS Connector for Object Storage provides connectivity to various big data analytic engines like Apache Spark and MapReduce. This connectivity enables the analytics engines to work directly with data stored in Object Storage. For more information, see Object Storage Hadoop Support.

The Infrequent Access tier is "cool" storage used for data that you access infrequently, but that must be available immediately when needed. Storage costs are less than Standard.

If you're uploading an object to a Standard default storage tier bucket, you can explicitly assign the object to the lower-cost Infrequent Access storage tier.

The Infrequent Access tier has a minimum storage retention period and data retrieval fees:

• The minimum storage retention period for the Infrequent Access tier is 31 days. If you delete or overwrite objects in the Infrequent Access tier before the retention requirements are met, you are charged the prorated cost of storing the data for the full 31 days.
• When you need to access objects stored in this tier, you are charged a per GiB data retrieval fee.

Some primary use cases for the Infrequent Access storage tier include the following:

• Backups of on-premises data

• Repository for rarely accessed backups

• Storage for data replicated or copied from another region

The Archive tier is the primary, default storage tier used for Archive Storage service data. The Archive storage tier is "cold" storage used for data seldom or rarely access, but that must be retained and preserved for long periods of time.

You choose a default storage tier (Standard or Archive) when you create a bucket. When set at bucket creation, you cannot change the default storage tier for a bucket. When you upload objects to a bucket in an Archive tier, the objects are automatically assigned the default storage tier of the bucket (Archive).

Archive storage tier buckets can only contain objects with an Archive storage tier assignment. Archive buckets do not contain a mix of objects with different storage tier assignments. An object remains in the Archive bucket, even if the object is restored.

Objects in the Archive tier must be restored before they are available for access. The cost efficiency of the Archive tier offsets the lead time required to access the data. However, the Archive tier has a minimum storage retention period and some additional storage fees:

• The minimum storage retention period for the Archive tier is 90 days. If you delete or overwrite objects in the Archive tier before the retention requirements are met, you are charged the prorated cost of storing the data for the full 90 days.
• When you restore objects, you are returning those objects to the Standard tier for access. You are billed for the Standard class tier while the restored objects reside in that tier.

Some primary use cases for the Archive storage tier include the following:

• Compliance and audit mandates
• Retroactive log data analysis to determine usage pattern or to debug problems
• Historical or rarely accessed content repository data
• Application-generated data requiring archival for future analysis or legal purposes

Auto-Tiering monitors data access patterns and helps you reduce storage costs by automatically moving objects larger than 1 MiB out of the Standard tier into the more cost-effective Infrequent Access tier. Auto-Tiering is enabled at the bucket-level and monitors the data access patterns of all objects in the bucket. You can enable Auto-Tiering for any Standard storage tier bucket at creation time. You can also enable Auto-Tiering at any time after bucket creation.

After you enable Auto-Tiering, objects remain in the Standard tier until they meet the minimum access and storage requirements required for movement eligibility to Infrequent Access. If Object Storage moved objects to Infrequent Access that are later accessed more frequently, we automatically move the objects back to the Standard tier without incurring any retrieval and prorated storage fees.

Because you incur no retrieval or prorated storage fees, enabling Auto-Tiering is particularly cost-effective for the following use cases:

• New application data storage that has no established access patterns
• Data storage that has changing access patterns

Now that you have some understanding of storage tiers and how they work, here are some links to the tasks related to storage tiers:

• Creating a bucket, specifying the default storage tier, and optionally enabling Auto-Tiering
  • Using the Console
  • Using the CLI
  • Using the API
• Uploading and specifying the storage tier for an object
  • Using the Console
  • Using the CLI
  • Using the API