Setup

The Autoclass feature automatically transitions objects in your bucket toappropriatestorage classes based on each object's access pattern. Thefeature moves data that isn't accessed to colder storage classes to reducestorage cost and moves data that is accessed to Standard storage to optimizefuture accesses. Autoclass simplifies and automates cost saving for yourCloud 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 adifferent storage class is specified in the request.

  • The bucket itself always has itsdefault storage class set toStandard storage, and requests that attempt to change this propertyto a storage class other than Standard storage fail.

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

• Most objectstransition to progressively colder storage classes ifthey're not accessed.

  • By default, theterminal storage class for Autoclass isNearline storage, which means objects transition to Nearline storageand remain in that storage class until they're accessed. Optionally, youcan configure Autoclass so that the terminal storage class isArchive storage.

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

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

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

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

• When a soft-deleted object isrestored, the resulting object begins inStandard storage, regardless of the storage class of the soft-deletedobject.

Pricing

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

Cloud Storage pricing for Autoclass-enabled buckets has thefollowing exceptions:

• Amanagement 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 nooperation charge when Autoclass transitions an object toa colder storage class.
• There is no Class A operation charge when Autoclass transitions an object fromNearline storage to Standard storage.
• When Autoclass transitions an object from Coldline storage orArchive storage to Standard storage or Nearline storage, eachtransition incurs a Class A operation charge.

Autoclass for existing buckets

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

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

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

  • All objects in the bucket, exceptsoft-deleted objects, transitionto Standard storage.

    Note: The storage class reported for individual objects might notimmediately show Standard storage after Autoclass is enabled. Thisdelay has no effect on the Autoclass pricing for such objects or on thestart of their 30-day period.

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

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

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

  • Each object remains stored in whichever storage class it has at the timeAutoclass is disabled. You can subsequentlychange an object's storage class as you would for non-Autoclassbuckets.
  • 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 toNearline storage, objects in Archive storage and Coldline storageat the time of your change transition to Nearline storage.

  • If you change the terminal storage class from Nearline storage toArchive storage, objects in Nearline storage at the time of yourchange are treated as if they just transitioned to Nearline storage. Asa result, such objects need another 60 days of no access before theytransition to Coldline storage.

Should you use Autoclass?

When enabled, Autoclass reduces the amount of data management you need to do andeliminates certain charges that apply for other buckets. Autoclass is a usefulfeature 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 fitsinto theuse cases of specific storage classes. For example, say yourbucket has two use cases: some data is accessed weekly while some data is backupdata that is never meant to be accessed. In this scenario, Autoclass isn'trecommended if you know which objects fall into each of those use cases.

Autoclass is also not recommended if other Google Cloud services regularlyread data from the bucket. For example, Autoclass isn't recommended if you useSensitive Data Protection to scan the content of your bucket.

Transition behavior

Once Autoclass is enabled, objects at least 128 KiB in size transition betweenstorage 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 isaccessed using theget object method. Other types of methods, such ascopy object andrewrite object, don't update the last accessedtimestamp.

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

If the bucket is configured to use Archive storage as the terminal storageclass, 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 inNearline 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 inNearline storage and 275 days in Coldline storage.

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

Once an object becomes eligible to transition between storage classes,Cloud Storage performs the transition asynchronously, so there can bea lag between when an object is eligible for transition and when the transitionactually occurs.

• During this period, the object continues to be billed using itspre-transition storage class, except in the case of transitions toStandard storage that occur as a result of enabling Autoclass.

Object transitions when relocating buckets

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

Autoclass uses access patterns to determine when to transition objects to colderstorage classes. Duringfinal synchronization of the bucket relocationprocess, Autoclass is paused and objects aren't transitioned to colder storageclasses. 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 theycan be transitioned to a colder class like Nearline storage. When anobject in the Standard storage class is moved during the relocation, it'streated as if it has been accessed. If an object was close to becomingeligible for transition to Nearline storage before the move, therelocation resets the object's eligibility for transition. The objectmust remain in the destination bucket for another 30-day period beforeit 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, orArchive storage storage classes does not count as accessing them. As aresult, the no-access period for these objects isn't affected.

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

  • If an object was scheduled to transition to a colder storage class suchas from Nearline storage to Coldline storage, the relocation processwon't interfere with the schedule. The transition proceeds as plannedafter the relocation is finished.

Restrictions

• A bucket cannot have both Autoclass enabled and either of the followingin aObject Lifecycle Management configuration:

  • A rule that uses theSetStorageClass action.
  • A rule that uses thematchesStorageClass condition.

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

• Becauseobject composition requires the source objects and the composedobject to all use the same storage class, composing an object in an Autoclassbucket fails unless all source objects are stored as Standard storage at thetime of the composition request.

Monitoring storage class usage and transitions

The followingstorage metrics are available in Monitoringto track storage class transitions:

• autoclass/transition_operation_count: The number of storage classtransitions initiated by Autoclass, excluding transitions that occurred aspart of enabling Autoclass.

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

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

Important: Objects in Standard storage are reported asREGIONAL if they arestored in a region and asMULTI-REGIONAL otherwise.

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

Additionally, you can monitor the number of bytes stored in each storage classover time for your Autoclass-enabled buckets by going to the bucket'sConfiguration tab in the Google Cloud console and clickingSee Performance.

What's next

• Enable Autoclass.
• Learn aboutObject Lifecycle Management.