AWS S3 Configuration Best Practice: Enable Bucket Versioning for Data Recovery

We’ve previously written about how using checklists can avoid cloud storage configuration errors, which is a useful practice for improving data protection. When you think of data protection, you probably think about preventing unauthorized access and exposure, but data protection also includes preventing and recovering from the accidental deletion and overwrite of data.

A major AWS S3 configuration error is not enabling bucket versioning; without it, organizations may not be able to recover accidently deleted objects and data. AWS S3 is designed for greater than 99% availability and greater than 99% durability of objects across multiple availability zones, so data recovery strategies should focus more on accidental deletion.

Bucket versioning is a method for storing multiple versions of an object in the same bucket, enabling organizations to save and restore any version of any object stored in its buckets. Once bucket versioning is enabled, Amazon stores all versions of an object with a unique identifier, even if it receives multiple write requests simultaneously. If an organization deletes an object, Amazon inserts a delete marker, instead of permanently deleting the object. If an organization overwrites an object, that new object becomes the new version. In either case, an organization can easily revert to a previous version of these deleted and overwritten objects.

By default, buckets are unversioned. Once versioning is enabled it cannot return to the unversioned state, but it can be suspended. Once enabled, versioning applies to all objects in the bucket, and once suspended it continues to store previously versioned objects, but does not add any new versions.

Configuring an unversioned bucket requires changing the default versioning sub-resource, which stores an empty versioning configuration, which appears as:

<VersioningConfiguration xmlns="">

Enabling bucket versioning requires updating the versioning configuration, as follows:

<VersioningConfiguration xmlns="">

Suspending bucket versioning requires changing the versioning configuration, as follows:

<VersioningConfiguration xmlns="">

Bucket versioning can also be configured through the AWS S3 console by editing the properties of a bucket.

Once bucket versioning is enabled, organizations can add an additional layer of security by requiring multi-factor authentication (MFA) before an object can be deleted. Organizations can also leverage an object lock to prevent objects from being overwritten, in case data needs to be preserved indefinitely. The only reason an organization may want to consider whether or not to enable bucket versioning is that there are storage costs associated with each object stored, but organizations can manage these costs by managing their storage lifecycle.

Avoid Common Configuration Errors with OPSWAT

When it comes to common configuration errors, such as enabling bucket versioning, organizations should use checklists to ensure they are implementing best practices. Automating this process with technology can help to avoid time-consuming and expensive manual errors.

MetaDefender for Secure Storage enhances its cloud storage security solution with an integrated security checklist, so that cybersecurity professionals can ensure their organization’s cloud storage is not misconfigured as it is provisioned which includes the development and production stages of cloud storage.

Enabling bucket versioning is a major checklist item in MetaDefender for Secure Storage, but it isn’t the only one. In future blogs, we will be exploring other major configuration errors for protecting data at rest, including server-side encryption, and bucket access logging.

Contact an OPSWAT cybersecurity expert to learn more.

Read the previous blog in this series:

Sign up for Blog updates
Get information and insight from the leaders in advanced threat prevention.