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 isn't 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.

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.

  • By default, the terminal storage class for Autoclass is Nearline storage, which means objects transition to Nearline storage and remain in that storage class until they're accessed. Optionally, you can configure Autoclass so that the terminal storage class is Archive storage.

  • Objects smaller than 128 KiB don't transition to colder storage classes. Instead, they are permanently stored in Standard storage. Only object data, not object metadata, is considered when determining whether the object is smaller than 128 KiB.

  • Soft-deleted objects retain their existing storage classes until the end of their retention duration.

• 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 a soft-deleted object is restored, the resulting object begins in Standard storage, regardless of the storage class of the soft-deleted object.

Pricing

All storage and operation charges for objects managed by Autoclass are billed using Autoclass-specific SKUs.

Cloud Storage pricing for Autoclass-enabled buckets has the following exceptions:

• A management fee and enablement charge apply when using Autoclass.
• Retrieval fees are not charged except as part of enablement charges.
• Early deletion fees are not charged except as part of enablement charges.
• All operations are charged at the Standard storage rate.
• There is no operation charge when Autoclass transitions an object to a colder storage class.
• There is no Class A operation charge when Autoclass transitions an object from Nearline storage to Standard storage.
• When Autoclass transitions an object from Coldline storage or Archive storage to Standard storage or Nearline storage, each transition incurs a Class A operation charge.

Autoclass for existing buckets

Autoclass configurations can be enabled, disabled, or modified for an existing bucket.

• Changes to the Autoclass configuration can take up to one day to go into effect, and Cloud Storage might continue to perform actions based on the earlier configuration during this time.

• When you enable Autoclass on an existing bucket, the following occurs:

  • All objects in the bucket, except soft-deleted objects, transition to Standard storage.

    Note: The storage class reported for individual objects might not immediately show Standard storage after Autoclass is enabled. This delay has no effect on the Autoclass pricing for such objects or on the start of their 30-day period.

  • Objects already in Standard storage at the time you enable Autoclass are treated as if they just transitioned to Standard storage. As a result, such objects need another 30 days of no access before they are eligible to transition to Nearline storage.

  • There is a one-time Autoclass enablement charge. For more information, see Autoclass charges.

• When you disable Autoclass on an existing bucket, the following occurs:

  • Each object remains stored in whichever storage class it has at the time Autoclass is disabled. You can subsequently change an object's storage class as you would for non-Autoclass buckets.
  • The Autoclass pricing structure no longer applies.
  • Autoclass cannot be re-enabled on the bucket until one day has elapsed. Attempts to do so fail.

• When you change the terminal storage class in your Autoclass configuration, the following occurs:

  • If you change the terminal storage class from Archive storage to Nearline storage, objects in Archive storage and Coldline storage at the time of your change transition to Nearline storage.

  • If you change the terminal storage class from Nearline storage to Archive storage, objects in Nearline storage at the time of your change are treated as if they just transitioned to Nearline storage. As a result, such objects need another 60 days of no access before they transition to Coldline storage.

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 isn't 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 isn't 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 isn't recommended if you use Sensitive Data Protection to scan the content of your bucket.

Transition behavior

Once 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.

Note: An object's last access timestamp is only updated when an object is accessed using the get object method. Other types of methods, such as copy object and rewrite object, don't update the last accessed timestamp.

If the bucket is configured to use Nearline storage as the terminal storage class, Autoclass only changes the state of an object stored in Nearline storage if that object is accessed.

If the bucket is configured to use Archive storage as the terminal storage class, objects continue to transition to colder storage classes as follows:

• 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 billed using its pre-transition storage class, except in the case of transitions to Standard storage that occur as a result of enabling Autoclass.

Object transitions when relocating buckets

This section describes how Autoclass manages object transitions during the bucket relocation process.

Autoclass uses access patterns to determine when to transition objects to colder storage classes. During final synchronization of the bucket relocation process, Autoclass is paused and objects aren't transitioned to colder storage classes. After final synchronization is complete, Autoclass resumes.

• Objects in a Standard storage class are handled as follows:

  • Standard storage class objects have a 30-day no-access period before they can be transitioned to a colder class like Nearline storage. When an object in the Standard storage class is moved during the relocation, it's treated as if it has been accessed. If an object was close to becoming eligible for transition to Nearline storage before the move, the relocation resets the object's eligibility for transition. The object must remain in the destination bucket for another 30-day period before it can transition to a colder storage class.

• Objects in a storage class other than Standard storage are handled as follows:

  • Relocating objects in Nearline storage, Coldline storage, or Archive storage storage classes does not count as accessing them. As a result, the no-access period for these objects isn't affected.

  • When relocating a bucket, if you frequently access objects in buckets in a storage class other than Standard storage, such as Nearline storage, Coldline storage, or Archive storage, the objects don't automatically transition to a warmer storage class. For example, the objects don't automatically transition from Archive storage to Coldline storage or from Coldline storage to a Standard storage, even if the objects are frequently accessed. This behavior prevents automatic storage class transitions during relocation.

  • If an object was scheduled to transition to a colder storage class such as from Nearline storage to Coldline storage, the relocation process won't interfere with the schedule. The transition proceeds as planned after the relocation is finished.

Restrictions

• A bucket cannot have both Autoclass enabled and either of the following in a Object Lifecycle Management configuration:

  • A rule that uses the SetStorageClass action.
  • A rule that uses the matchesStorageClass condition.

  Requests that would cause a bucket to have both Autoclass enabled and one of these Object Lifecycle Management rules fail.

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

Monitoring storage class usage and transitions

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

• autoclass/transition_operation_count: The number of storage class transitions initiated by Autoclass, excluding transitions that occurred as part of enabling Autoclass.

• autoclass/transitioned_bytes_count: The total number of bytes transitioned by Autoclass, excluding bytes transitioned as part of enabling Autoclass.

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

Important: Objects in Standard storage are reported as REGIONAL if they are stored in a region and as MULTI-REGIONAL otherwise.

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

Additionally, you can monitor the number of bytes stored in each storage class over time for your Autoclass-enabled buckets by going to the bucket's Configuration tab in the Google Cloud console and clicking See Performance.

What's next

• Enable Autoclass.
• Learn about Object Lifecycle Management.