After you use CopyObject to convert the storage class of objects, the storage usage of the original storage class does not decrease. This topic explains why this happens and how to resolve it.
Symptom
After you convert the storage class of objects by calling CopyObject, you notice the following:
The storage usage of the destination storage class increases as expected.
The storage usage of the source storage class remains the same. It does not decrease.
Cause
CopyObject works by creating a new object in the destination storage class. It does not remove the original object. After the copy operation completes, both the source object and the destination object exist, and both count toward your storage usage.
In a versioned bucket, this behavior also applies when you copy an object to the same key. CopyObject creates a new current version in the destination storage class, while the previous version persists as a noncurrent version in the original storage class. The noncurrent version continues to incur storage charges until you explicitly delete it or a lifecycle rule removes it.
The following table summarizes the conditions under which this issue occurs:
| Bucket versioning state | Source and destination object names | Result |
|---|---|---|
| Versioning not enabled | Different names | Source object remains. Storage usage of the source storage class is unchanged. |
| Versioning enabled | Same or different names | Source object (or its previous version) remains. Storage usage of the source storage class is unchanged. |
When versioning is not enabled and you copy an object to the same name, the new object overwrites the original, so storage usage of the source class decreases as expected. In all other cases, the original object persists.
Solutions
Use one of the following methods to convert the storage class of objects so that the storage usage of the source storage class decreases.
Method 1: Use a lifecycle rule
Configure a lifecycle rule to convert the storage class of objects. Lifecycle rules perform in-place storage class transitions. The original object is replaced rather than copied, so the storage usage of the source storage class decreases automatically.
This is the recommended method when you need to convert objects in bulk or on a recurring schedule.
Method 2: Use CopyObject and delete the source object
Call CopyObject to convert the storage class, and then manually delete the source object to free up the storage usage of the source storage class. The steps depend on whether versioning is enabled:
| Scenario | Action required |
|---|---|
| Unversioned bucket, same object name | No additional action is needed. The new object overwrites the source object, and storage usage of the source storage class decreases. |
| Unversioned bucket, different object name | After the copy completes, delete the source object manually. |
| Versioned bucket (same or different object name) | After the copy completes, delete the source object manually. If the source and destination names are the same, you must delete the noncurrent version (the previous version of the object) to reduce storage usage of the source storage class. |
If the storage class of the source objects or the specified version of the objects is Infrequent Access (IA), Archive, Cold Archive, or Deep Cold Archive, and you delete the objects before their minimum storage duration ends, you are charged extra fees. For more information, see How am I charged for objects whose storage duration is less than the minimum storage duration?
After the source objects or the specified version of the objects are deleted, they cannot be restored. Exercise caution when you perform this operation.