Contents show

S3 Versioning

For having many variants of an object in one bucket.

Used to maintain, find, and bring back all the versions of your objects that are found in the bucket.

Bring back both application failures and unintentional user actions.

As an example: Two objects can be present while having the same key, but they will have version IDs which are different:

image.gif (version 333222) and image.gif (version 425234).

Versioning-enabled buckets pave the way for the recovery of accidental actions:

  • Deleting an object: does not remove it permanently, but gives it a delete marker, as the current object version. Previous versions can easily be restored.
  • Overwriting an object: will get you a new object version found in the same bucket. Previous versions can easily be restored.

Object expiration lifecycle policy in a non-versioned bucket:

To keep the same permanent, delete behavior with versioning, you should add a noncurrent expiration lifecycle policy. This policy in the version-enabled bucket will manage the deletes of the noncurrent object versions.

Three states for buckets:

-Unversioned (default state)

s3 versioning - multiple versions

s3 versioning – multiple versions

-Versioning-enabled

s3 versioning - multiple versions enabled

s3 versioning – multiple versions enabled

-Versioning-suspended

s3 versioning - multiple versions suspended

s3 versioning – multiple versions suspended

 

When a bucket gets version-enabled, you will not be able to bring it back to its unversioned state anymore, but you can suspend its versioning.

All of a bucket’s objects get in the versioning state. When a bucket is first enabled for versioning, its objects become versioned forever with their own unique version ID.

  • The version ID is null for objects already found in a bucket before it gets in the version state. The existing objects do not get altered, but the only thing which changes is how they are handled in the upcoming requests.
  • Bucket users have the ability to suspend versioning for the sake of stopping object versions.

Configuring Versioning on a Bucket:

It can be done by any of those methods:

  • The Amazon S3 console.
s3 versioning - multiple versions suspended versioning

s3 versioning – multiple versions suspended versioning

 

 

  • Programmatically, by the AWS SDKs.

REST API is called by both the console and the SDKs to configure buckets versioning.

REST API calls can also directly be made when necessary from your code, but this can be a harder method since it will need you to authenticate those requests using codes.

Every created bucket is by default unversioned and contains a versioning sub resource which holds empty versioning configuration.

<VersioningConfiguration xmlns=”http://s3.amazonaws.com/doc/2020-02-20/”> </VersioningConfiguration>

For the enablement of versioning, a request must be sent to Amazon S3 that has a versioning configuration with a status.

<VersioningConfiguration xmlns=”http://s3.amazonaws.com/doc/2020-02-20/”>   <Status>Enabled</Status> </VersioningConfiguration>

For the suspension of versioning, the status value must be set to Suspended.

The people who get to configure the versioning state of this bucket are the following:

-The bucket owner,

-An AWS root account which has created the bucket

-Authorized users

How to use MFA Delete:

Optionally, a user gets the chance to:

-Add an additional layer of security through configuring a bucket for the enablement of multi-factor authentication Delete. This layer needs extra authentication for doing any one of those operations:

  • Changing the bucket’s versioning state
  • Permanently get an object version deleted

The extra authentication forms needed together for MFA Delete are the following:

  • Security credentials
  • The concatenation of:

– Valid serial number

– Space

– Six-digit code displayed on an approved authentication device

In Case your credentials are attacked or get under any threat, MFA Delete will grant you added security.

MFA Delete can be enabled or disabled through the same API used for the configuration of versioning in this bucket. MFA Delete configuration is kept in the versioning sub resource which was used to store bucket’s versioning status.

Accidental bucket deletions can be stopped by MFA Delete through those steps:

  • Asking for physical possession of MFA device and its MFA code.
  • Having an additional layer of security and friction to this action.

<VersioningConfiguration xmlns=”http://s3.amazonaws.com/doc/2020-02-20/”>   <Status>VersioningState</Status>  <MfaDelete>MfaDeleteState</MfaDelete>  </VersioningConfiguration>

Who can enable versioning?

– The bucket owner

– The AWS root account which first created the bucket

– All other authorized IAM users

Who can enable MFA Delete?

– The bucket owner (root account)

MFA Delete can be used through a hardware or through a virtual MFA device so that you get to generate the required authentication code.

Both the MFA Delete and the MFA-protected API access are:

-Features for granting protection and safety against various situations

MFA Delete: configured on a bucket for making sure that ensure data in the bucket will not be deleted unintentionally.

MFA-protected API access: utilized for case sensitive resources to enforce an additional authentication factor which is the MFA code. Temporary credentials of MFA can be asked to be provided when attempting to perform specific operations for those sensitive resources.

What is S3 object key

AUTHOR