Autoclass

Setup

The Autoclass feature automatically transitions objects in your bucket to appropriate storage classes based on each object's access pattern. The feature moves data that is not accessed to colder storage classes to reduce storage cost and moves data that is accessed to Standard storage to optimize future accesses. Autoclass simplifies and automates cost saving for your Cloud Storage data. When enabled on a bucket, there are no early deletion charges, no retrieval charges, and no charges for storage class transitions.

Overview

When enabled, Autoclass manages all aspects of storage classes for a bucket:

  • All objects added to the bucket begin in Standard storage, even if a different storage class is specified in the request.

    • The bucket itself always has its default storage class set to Standard storage, and requests that attempt to change this property to a storage class other than Standard storage fail.

    • If you attempt to change the storage class of an object manually during a rewrite or copy operation, the overall operation succeeds. However, the storage class change is ignored, and the object is always set to Standard storage.

  • Most objects transition to progressively colder storage classes if they're not accessed.

    • Objects smaller than 128 KiB do not transition to colder storage classes. Instead, they are permanently stored in Standard storage and are not subject to the Autoclass Management fee. Only object data, not object metadata, is considered when determining whether the object is smaller than 128 KiB.

  • When an object's data is read, the object transitions to Standard storage if it's not already stored in Standard storage.

    • Reading or editing an object's metadata does not cause the object to transition to Standard storage.

When you disable Autoclass, the following occurs:

  • Each object remains stored in whichever storage class it had at the time Autoclass was disabled. You can subsequently change an object's storage class as you would for non-Autoclass buckets.

  • The Autoclass pricing structure no longer applies.

Pricing

Cloud Storage pricing remains the same for Autoclass-enabled buckets, with the following exceptions:

Note that operation and networking charges are determined by the storage class of an object at the time it's requested, not the storage class the object subsequently transitions to.

Should you use Autoclass?

When enabled, Autoclass reduces the amount of data management you need to do and eliminates certain charges that apply for other buckets. Autoclass is a useful feature to enable for the following general access patterns:

  • Your data has a variety of access frequencies.
  • The access patterns for your data are unknown or unpredictable.

However, Autoclass is not recommended if the majority of your bucket's data fits into the use cases of specific storage classes. For example, say your bucket has two use cases: some data is accessed weekly while some data is backup data that is never meant to be accessed. In this scenario, Autoclass is not recommended if you know which objects fall into each of those use cases.

Autoclass is also not recommended if other Google Cloud services regularly read data from the bucket. For example, Autoclass is not recommended if you use Sensitive Data Protection to scan the content of your bucket.

Transition behavior

When Autoclass is enabled, objects at least 128 KiB in size transition between storage classes as follows:

  • If an object's data is accessed, the object transitions to Standard storage.

  • Any object that isn't accessed for 30 days transitions to Nearline storage.

  • Any object that isn't accessed for 90 days transitions to Coldline storage. Such objects spent at least 30 days in Standard storage and 60 days in Nearline storage.

  • Any object that isn't accessed for 365 days transitions to Archive storage. Such objects spent at least 30 days in Standard storage, 60 days in Nearline storage and 275 days in Coldline storage.

  • Autoclass only changes the state of an object stored in Archive storage if that object is accessed.

Once an object becomes eligible to transition between storage classes, Cloud Storage performs the transition asynchronously, so there can be a lag between when an object is eligible for transition and when the transition actually occurs. During this period, the object continues to be charged at the rate of its pre-transition storage class.

Restrictions

  • Currently, Autoclass must be enabled at bucket creation time. Existing buckets can only disable the feature, not enable it.

  • A bucket cannot have both Autoclass enabled and use the SetStorageClass action in an Object Lifecycle Management rule. Requests that would cause both to be set on a bucket fail.

  • Because object composition requires the source objects and the composed object to all use the same storage class, composing an object fails unless all source objects are stored as Standard storage at the time of the composition request.

Auditing with Cloud Monitoring

The following storage metrics are available in Monitoring to track storage class transitions:

Optionally, both metrics can be grouped by the source or destination storage class involved in transitions.

For a guide to tracking metrics with Monitoring, see Create charts with Metrics Explorer.

What's next