Skip to content

S3 & Glacier


General Info

Object storage


Feature Description
  • Buckets are global (no region or account ID in their ARN)
  • Automatically replicated within a region
Data Consistency
  • PUT to new object = read-after-write consistency
  • PUT to existing object = eventual consistency
  • DELETE object = eventual consistency
MFA Delete
  • Applies to deleting objects, not buckets
  • Only the root account can enable MFA Delete
  • The bucket owner, root account, and all authorized IAM users of a bucket are allowed to enable versioning
  • Once enabled, it is not possible to disable or turn off versioning (it can only be suspended)
S3 Transfer Acceleration Speeds up transfers to S3
  • S3 Per-prefix performance
    • PUT/POST/COPY/DELETE: 3500/sec
    • GET/HEAD: 5500/sec
  • S3 Latency performance: 100-200ms for first-byte-out


Use Case Naming Example
Direct bucket access bucket name after FQDN (path-style)
Website hosting bucket name part of FQDN (virtual-hosted-style)

Storage Classes

Class Description Availability Durability
S3 Standard Frequently accessed data 99.99 11 9s
S3 Intelligent-Tiering
  • Transitions objects between S3 Standard and S3-IA, depending on how often an object is accessed
  • Monitoring and automation charges
99.99 11 9s
S3 Standard-IA
  • Infrequently accessed data (same performance)
  • Stored for at least 30days
  • Charges all objects as if they are at least 128 KB in size
99.9 11 9s
S3 One Zone-IA
  • Reduced Redundancy Storage
  • Lower durability for derived data that can be replaced
99.5 11 9s
  • Long term archives
  • Retrieve time of several hours (3-5)
  • Issue RESTORE command → 5h later the object is copied into S3 RRS (original remains in Glacier)
99.99 11 9s
Glacier Deep Archive 12-48 hours latency 99.99 11 9s

Access Control

The account (not user) that creates objects/buckets owns them, even if the bucket is hosted by a different account


Context Description
User needs to have permission Using identity policies (or user is the root of an account)
For bucket operations: bucket needs to have permission
  • User in a different account → just bucket policy/ACL
  • User in the same account → both bucket policy/ACL and identity policy
For object operations: User has to have permission (or be root)
  • Bucket policy/ACL has to not deny
  • Object ACL (or bucket policy) has to allow

Grant Access

Option Description
IAM Policies
  • Can only grant users within your AWS account
  • Legacy: bucket and object resource-based policy
  • If you need to define object-specific permissions you must use ACLs
  • Default ACL grants the owner account full control
  • List of grants, each grant gives a grantee (an AWS account or predefined group, NOT specific users) a permission
  • Grantee groups:
    • Authenticated Users = any AWS user
    • All Users = include anonymous
    • Log Delivery = S3 audit logs
  • Permissions: READ, WRITE (only applies to buckets - allows overwriting and deleting objects), FULL CONTROL (all of the above)
S3 Bucket policies
  • Recommended: Bucket resource-based policy
  • Permissions are applied at the bucket-level (no object-level granularity)
  • Resource needs to end in "/*"
  • Policies can be attached to: users, groups, S3 buckets
  • Differences with IAM:
    • Associated with bucket, no IAM principal
    • Explicit reference to IAM principal, which can belong to different account (allows to define cross-account access without setting up IAM roles)
Query String Auth
  • Can use query params to provide request info, including auth info
  • This part of URL (named PRE-SIGNED URL) share objects through URLs
  • Specified by policy keys
  • Options
    • Request time (DATE Condition)
    • If over SSL (BOOLEAN Condition)
    • Client IP (IP Condition)
    • Client app (STRING Condition)
<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="">
        <ID>*** Owner-Canonical-User-ID ***</ID>
            <Grantee xmlns:xsi=""
                     xsi:type="Canonical User">
                <ID>*** Owner-Canonical-User-ID ***</ID>
// Allows full read permissions to anonymous users
    "Statement": [
            "Principal": "*",

Policy Precedence

  1. Decisions ALWAYS default to DENY
    • If no method specifies an ALLOW —> DENY by default
  3. Only if no method specify a DENY && 1+ methods specify an ALLOW —> ALLOW
  4. S3 bucket policies has precedence over IAM policy
  • Example
    • IAM policy grants access to an object
    • S3 bucket policy denies access to that object
    • No S3 ACL
    • —> access denied (S3 bucket policy win)
  • Example
    • 1 bucket policy deny all ops to all users (EXPLICIT DENY)
    • 1 bucket policy allowing one specific user to upload


Server Side

SSE-S3 AWS S3-managed Keys
  • AWS handles key management/protection
  • Each object is encrypted with unique key
  • Object key encrypted with master key
SSE-KMS AWS KMS-managed Keys
  • AWS handles key management/protection but you manage the keys
  • Separate permissions for using the master key
  • Provides auditing
SSE-C Customer-provided Keys
  • AWS only performs encryption/decryption of the object
  • You send the plaintext encryption key in the request
DSSE-KMS Dual-layer encryption with keys stored in KMS
  • Applies two layers of encryption to objects when they are uploaded to an S3 bucket

Client Side

CSE-KMS AWS KMS-managed Customer Master Key
CSE-C Client-side Master Key


  • CloudTrail by default records bucket-level actions
  • Can enable CloudTrail logging of object-level actions by setting that property on a bucket in S3 (can choose read/write)
  • Server access logging: separate audit log, configured per-bucket, that stores events in a bucket

Specific Setups

Force TLS
Add bucket policy
    "Version": "2012-10-17",
    "Statement": [
            "Sid": "AllowRequests",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::your-s3-bucket/*"
            "Sid": "ForceSSLRequests",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::your-s3-bucket/*",
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
Pre-signed URLs
  • Give temporarily access to a specific object (since by default buckets are private)
  • Anyone who has access to a pre-signed URL will have access to the object
  • The illustrated guide to S3 pre-signed URLs
  • Must provide
    • Security credentials (must have the right permissions to access the S3 object)
    • Bucket name
    • Object key
    • Expiration (default 3600s, can be up to 7d)
$ aws s3 presign s3://<bucket>/file.txt --expires-in 300
Block Public Access

Applied to specific buckets, or all buckets in an account

BlockPublicAcls Can't create new public bucket or object ACLs
IgnorePublicAcls Existing (and new) public ACLs are ignored
BlockPublicPolicy Can't create public bucket policies
RestrictPublicBuckets Blocks all anonymous and cross-account access to a bucket
Cross region replication
  • Replicates objects from one region to another in an asynchronous fashion
  • Features
    • You can replicate objects from a source bucket to only one destination
    • After S3 replicates an object, the object cannot be replicated again
    • Enabling cross-region replication does not copy existing objects by default → need to manually copy existing objects
    • Uses SSL by default (no need for policy)
  • Conditions
    • Versioning must be enabled in both source and destination
    • The replication role gives all the necessary permissions to replicate and access the objects on the source bucket
    • If the destination bucket is owned by a different AWS account, the account owner of the destination must grant the required permission to store the replicated objects
      • It is also possible to change object ownership during replication to the destination bucket
    • If the owner of the source bucket does not have permissions on the stored objects, the read and read_acp permissions should be granted (via ACL)
    • Bucket owner must have permissions to access objects (ACLs) to perform the replication
  • What replicated
    • New objects created after the replication is activated
      • Old objects will not be replicated unless they are changed after the replication was activated
    • Unencrypted objects
    • Objects encrypted using SSE-S3 and SSE-KMS (no SSE-C)
    • Object metadata, ACL updates, existing tags, and lock retention information
    • Only object in the source bucket for which the bucket owner has permission to read objects and read ACLs
    • If you perform a delete operation to mark the object as deleted, this marker will be replicated
  • Not replicated
    • Objects created before the CRR was enabled
    • Objects created with SSE-C, or customer-provided encryption keys
    • Objects deleted through a delete operation with a version ID specified (particular object version) → prevents malicious deletion of data


Use cases

  • Files stored as Archives, Archives stored in Vaults
  • Data Retrieval requires job initiation then getting the output from the job


Data Storage
  • Automatically encrypts data (AES-256)
  • Regular data integrity checks
  • Only your account can access data
  • Can use IAM to specify which users within the account have rights to operate on a given Vault
  • Stores data <40TB
  • Each assigned a unique ID
  • Automatically encrypted
  • Immutable (after creation can't be modified)
  • Container for Archives (can store infinite number)
  • Max 1000 Vaults per region
Vault Lock Policies
  • A vault access policy that can be locked to prevent changes to it
    • configure and enforce compliance controls for individual Glacier Vaults (~ IAM policy)
  • Use cases
    • configure WORM (write once read many) archives
    • create data retention policies
  • 2 steps to configure
    • initiate the lock by attaching a vault lock policy to the vault (sets the lock to an "in-progress" state)
    • you then have 24h to validate the lock policy
    • once validated, lock policies are immutable