Skip to content

Instantly share code, notes, and snippets.

@brijesh-deb

brijesh-deb/AWS_S3_Notes.md Secret

Last active February 4, 2019 05:58
Show Gist options
  • Save brijesh-deb/e92b7fb5bbb46eec9b97bf2bd0ddc469 to your computer and use it in GitHub Desktop.
Save brijesh-deb/e92b7fb5bbb46eec9b97bf2bd0ddc469 to your computer and use it in GitHub Desktop.
Download ZIP
#AWS #S3 #notes
Raw
AWS_S3_Notes.md

1. S3 Server Access Log

  • Server access logging provides detailed records for the requests that are made to a bucket.
  • Each access log record provides details about a single access request, such as the requester, bucket name, request time, request action, response status, and an error code, if relevant.
  • By default, logging is disabled. When logging is enabled, logs are saved to a target bucket in the same AWS Region as the source bucket.
  • Setup
    • S3 Console > Select bucket (source) > Properties
    • Enable Server access logging
    • Mention Target bucket [ existing bucket in same Region to store the log files]
    • S3 Console > Select target bucket > Permissions > Access Control List>
    • Select S3 log delivery group
  • S3 uses a special Log Delivery account, called the Log Delivery group, to write access logs. Grant Log Delivery group write permission on the bucket where you want the access logs saved. We refer to this bucket as the target bucket.
  • Server access log records are delivered on a best effort basis.
  • Most log records are delivered within a few hours of the time that they are recorded, but they can be delivered more frequently.
  • The completeness and timeliness of server logging is not guaranteed. The log record for a particular request might be delivered long after the request was actually processed, or it might not be delivered at all. AWS uses best effort server log delivery.

2. Object Versioning

  • Versioning is turned on at bucket level
  • Buckets can be in one of three states: unversioned (the default), versioning-enabled, or versioning-suspended. Once you version-enable a bucket, it can never return to an unversioned state. You can, however, suspend versioning on that bucket.
  • Regardless of whether you have enabled versioning, each object in your bucket has a version ID. If you have not enabled versioning, Amazon S3 sets the value of the version ID to null.
  • When you enable versioning on a bucket, objects already stored in the bucket are unchanged. The version IDs (null), contents, and permissions remain the same.
  • Version-enabled bucket
    • When you PUT an object in a versioning-enabled bucket, the noncurrent version is not overwritten. When a new version of photo.gif is PUT into a bucket that already contains an object with the same name, the original object (ID = 111111) remains in the bucket, Amazon S3 generates a new version ID (121212), and adds the newer version to the bucket.
    • When you DELETE an object, all versions remain in the bucket and Amazon S3 inserts a delete marker.
    • The delete marker becomes the current version of the object. By default, GET requests retrieve the most recently stored version. Performing a simple GET Object request when the current version is a delete marker returns a 404 Not Found error.
    • You can, however, GET a noncurrent version of an object by specifying its version ID.
    • You can permanently delete an object by specifying the version you want to delete. Only the owner of an Amazon S3 bucket can permanently delete a version.
    • To delete a delete marker, you must specify its version ID in a DELETE Object versionId request.
    • If you use a DELETE request to delete a delete marker (without specifying the version ID of the delete marker), Amazon S3 does not delete the delete marker, but instead, inserts another delete marker.
    • In a versioning-enabled bucket, this new delete marker would have a unique version ID. So, it's possible to have multiple delete markers of the same object in one bucket.
    • If you have an object expiration lifecycle policy in your non-versioned bucket and you want to maintain the same permanent delete behavior when you enable versioning, you must add a noncurrent expiration policy. The noncurrent expiration lifecycle policy will manage the deletes of the noncurrent object versions in the version-enabled bucket.
    • Restoring Previous Versions
      • Copy a previous version of the object into the same bucket
      • Permanently delete the current version of the object
  • Version-suspended buckets
    • Once you suspend versioning on a bucket, Amazon S3 automatically adds a null version ID to every subsequent object stored thereafter (using PUT, POST, or COPY) in that bucket.
    • If a null version is already in the bucket and you add another object with the same key, the added object overwrites the original null version
    • A GET Object request returns the current version of an object whether you've enabled versioning on a bucket or not.
    • If versioning is suspended, a DELETE request:
      • Can only remove an object whose version ID is null
      • Doesn't remove anything if there isn't a null version of the object in the bucket.
      • Inserts a delete marker into the bucket.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment