Configuring Amazon S3 Versioning
  • 3 Minutes to read
  • Dark
  • PDF

Configuring Amazon S3 Versioning

  • Dark
  • PDF

Article summary

Amazon S3 Versioning is a version control feature for S3 that enables you to revert to older versions of an S3 object, which helps provide protection against accidental or malicious deletion such as from a ransomware attack.

Versioning keeps multiple versions of an object in the same bucket. When you enable it on a bucket, Amazon S3 automatically adds a unique version ID to every object stored in the bucket. At that point, a simple DELETE action does not permanently delete an object version; it merely associates a delete marker with the object. You can then use the versioning features to retrieve the deleted object or an earlier version of the object if needed. If you want to permanently delete an object version, you must specify its version ID in your DELETE request.

You can define a bucket policy to grant permissions and ensure that only users with the necessary permissions will be able to permanently delete an object from a previous version.


Bucket policy can be attached to your bucket on creation, or at any time afterwards.

When a bucket policy is defined for the bucket along with a lifecycle rule to change the bucket storage class, as described in Using AWS S3 Intelligent-Tiering For Storage, the policy is transferred to the new storage class.

To set up versioning:

  1. From your Amazon Web Services account, sign-in to the AWS Management Console and select Services.
  2. Under Storage select S3.
  3. Click the CTERA Portal bucket from the S3 buckets list and then select the Properties tab to check that Versioning is enabled.
    The properties for the bucket are displayed.
  4. Under Bucket Versioning click Edit and then chose Enable.
  5. Click Save changes.

When Versioning is enabled, you are paying for multiple versions of the same document, which you will want to remove in line with the CTERA Portal retention policy.

To set a bucket policy to safeguard versions against ransomware attacks:

  1. From your Amazon Web Services account, click the CTERA Portal bucket from the S3 buckets list and then select the Permissions tab.
    The permissions details for the bucket are displayed.
  2. Scroll to Bucket policy and click Edit.
  3. Paste the following policy document into the Bucket policy area:
        "Version": "2012-10-17",
        "Statement": [
                "Sid": "DenyDeletePreviousVersions",
                "Effect": "Deny",
                "Principal": "*",
                "Action": "s3:DeleteObjectVersion",
                "Resource": "arn:aws:s3:::<bucketname>/*",
                "Condition": {
                    "Null": {
                        "s3:VersionId": "true"
    where bucketname is the name of the bucket.

    With this policy, previous versions can only be deleted by removing the policy, by an administrator with the necessary permissions. After a ransomware attack, a previous version can be restored in place of the current version that is no longer accessible after a ransomware attack.
  4. Click Save changes.

To Enable MFA delete:
You can only enable MFA delete via AWS CLI or REST API. The bucket owner, the AWS account that created the bucket (root account), and all authorized users can enable versioning. However, only the bucket owner (root account) can enable MFA delete.

For details about how to configure MFA delete, see

To set up versioning and to allow deleting files after a fixed number of days:


The following procedure does not protect the versions from ransomware attacks

  1. From your Amazon Web Services account, click the CTERA Portal bucket from the S3 buckets list and then select the Management tab.
    The management details for the bucket are displayed.
  2. Click Create lifecycle rule.
    The Create lifecycle rule page is displayed.
  3. Enter a name for the rule and chose Apply to all objects in the bucket.
  4. Check the acknowledgment that is displayed.
  5. Under Lifecycle rule actions check Permanently delete noncurrent versions of objects and Delete expired delete markers or incomplete multiple uploads.
    The page changes to display Permanently delete noncurrent versions of objects and Delete expired object delete markers or incomplete multipart uploads sections.
  6. Specify the number of days in Days after objects become noncurrent, after which the noncurrent versions of objects are permanently deleted.
    CTERA recommends that you retain versioned objects for the same number of days that the metadata of deleted objects is retained by the CTERA Portal (the default is 30 days).
  7. Check Delete expired object delete markers.
  8. Review the details of the rule and if satisfied, click Create rule.
    Lifecycle rules run once a day at midnight UTC.

    The first time the rule runs, it can take up to 48 hours.

Was this article helpful?