S3Guard: Operational Issues
There are various issues and limitations that you must consider when working with S3Guard.
The following operational issues have been identified while testing S3Guard.
Third-party S3-compatible object stores
Third-party object stores which reimplement the AWS S3 protocol are usually "consistent". As such, there is no need to use S3Guard. Consult the object store's supplier as to its consistency model.
S3Guard Security Aspects
The DynamoDB table needs to be writeable by all users/services using S3Guard. If a single DynamoDB table is used to store metadata about multiple buckets, then clients with access to the table will be able to read the metadata about objects in any bucket to which their read access restricted via AWS permissions.
The standard S3 Bucket and Object Access permissions do not provide any restriction on accessing the S3Guard index data. As this is only the Hadoop file status data of object name, type, size and timestamp, the actual object data and any tags attached to the object are still protected by AWS permissions. However, directory and filenames will be visible.
Limitations of S3Guard
The key limitation of S3Guard is that it only provides consistent file and directory listings. It does not address update and delete consistency of the data. It is only consistent with respect to changes made by client applications using the S3A connector with S3Guard enabled and the same DynamoDB table. Changes which are made by other applications are only eventually consistent from the perspective of S3A clients.
S3Guard will track the etag of uploaded files, and, on a versioned S3 bucket, the S3 version ID of an uploaded file. These will be used when opening files, so as to detect and possibly react to changes.
