Version id of object in amazon s3 is unique to file, bucket or S3

amazon s3amazon-web-services

The doc says

If you enable versioning for a bucket, Amazon S3 automatically generates a unique version ID for the object being stored

When versioning is enabled for a bucket, can I say version id returned is unique for all the files in the bucket ?

I could not get enough details from their docs. Have I missed anything ?

My concern is Amazon says that

There is no limit to the number of objects that can be stored in a bucket and no difference in performance whether you use many buckets or just a few

But the version id's length is 32.

Length of version id is 32

So it can generate up to 2^32 id's i.e 4,29,49,67,296, right ? So is that a limitation on number of objects that can be created in a bucket ?

Thanks in advance.

Best Answer

Technically speaking, it appears they might be longer, in the future:

Unique version IDs are randomly generated, Unicode, UTF-8 encoded, URL-ready, opaque strings that are at most 1024 bytes long

http://docs.aws.amazon.com/AmazonS3/latest/dev/ObjectVersioning.html

However, there doesn't seem to be an explicit statement as to the scope of these identifiers.

The bucket versioning documentation (now) includes this statement:

When you enable versioning for a bucket, all objects added to it will have a unique version ID.

Assuming this is correct as written, the version ID is scoped to the bucket... but I am still skeptical. S3 sometimes performs index partition splits on buckets for performance reasons, and unique version ID maintenance across partitions seems somewhat unlikely. It really depends on what the information in a version ID actually means, if it means anything at all. It's opaque, so for all we know, it could be random.

In the strictest sense from an application's perspective, they are only unique to the individual object, because if objects are created in an unversioned bucket, and versioning is later enabled on the bucket, every object that existed when versioning was enabled has the same version id, which is the literal string null when you are interacting with the REST API.

In any event, though, a version ID isn't meaningful in the absence of the acconpanying key, because you can't fetch an object by version id alone -- only by key + version id.

Taken together, the appropriate course of action would seem to be to work with the assumption that version ids are scoped to, and only meaningful at, the object key level.

Related Topic