DevOpsAWSCloud

Amazon S3 Guide: Buckets, Storage Classes, Policies & Lifecycle

Master Amazon S3 — create buckets, configure storage classes, write bucket policies, enable versioning, set lifecycle rules, and host a static website. Complete SAA-C03 guide.

TT
Sarah Mitchell
6 min read
Amazon S3 Guide: Buckets, Storage Classes, Policies & Lifecycle

Amazon Simple Storage Service (S3) is the most versatile storage service in AWS. It stores objects — files of any type and size — in flat, infinitely scalable containers called buckets. S3 is used for everything: static websites, data lakes, application backups, ML training datasets, software deployment artefacts, and log archives.

Understanding S3 deeply — its storage classes, access controls, versioning, and lifecycle policies — is essential for both real-world AWS use and the SAA-C03 exam.


S3 Fundamentals

Buckets

A bucket is a container for objects (files). Key properties: bucket names are globally unique across all AWS accounts, buckets are created in a specific region, bucket names must be 3–63 characters (lowercase, no underscores), there's no limit on the number of objects in a bucket, and the maximum object size is 5 TB (objects >5 GB require multipart upload).

bash
# Create a bucket
aws s3 mb s3://my-unique-bucket-name-2026 --region us-east-1

# Upload a file
aws s3 cp myfile.txt s3://my-unique-bucket-name-2026/

# List bucket contents
aws s3 ls s3://my-unique-bucket-name-2026/

# Download a file
aws s3 cp s3://my-unique-bucket-name-2026/myfile.txt ./

Objects

An object consists of a Key (the full path/name), Value (the data), Metadata (system and optional user metadata), and Version ID (when versioning is enabled). S3 uses a flat namespace — there are no real folders. The / in a key is just a convention that the console renders as folders.


S3 Storage Classes

Storage classes let you trade cost for access speed and retrieval time. Choosing the right class saves significant money.

Storage ClassAvailabilityMin StorageRetrieval TimeUse Case
S3 Standard99.99%NoneMillisecondsFrequently accessed data
S3 Intelligent-Tiering99.9%NoneMillisecondsUnknown/changing access patterns
S3 Standard-IA99.9%30 daysMillisecondsInfrequent access, rapid retrieval
S3 One Zone-IA99.5%30 daysMillisecondsNon-critical infrequent access
S3 Glacier Instant99.9%90 daysMillisecondsArchives needing instant retrieval
S3 Glacier Flexible99.99%90 daysMinutes–hoursArchives, bulk retrieval OK
S3 Glacier Deep Archive99.99%180 days12–48 hoursLong-term compliance archives

Exam tip: Know the retrieval times and minimum storage durations. Deep Archive is the cheapest S3 storage. Standard-IA charges a retrieval fee on top of storage — not cost-effective for frequently accessed files.

S3 Intelligent-Tiering

Automatically moves objects between access tiers based on usage patterns. Objects not accessed for 30 days move to the Infrequent Access tier; for 90 days, to Archive Instant Access; for 180 days, to Archive. No retrieval fees. Ideal when you don't know or can't predict access patterns.


S3 Security

Block Public Access

S3 has an account-level and bucket-level Block Public Access setting that overrides all bucket policies and ACLs. Enabled by default on all new buckets since 2023. Don't disable it unless you explicitly need public access (static website hosting, public assets).

Bucket Policies

Resource-based JSON policies attached directly to a bucket:

json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-public-website/*"
    }
  ]
}

This policy allows public read access to all objects in the bucket — used for static website hosting. "Principal": "*" means anyone; use a specific AWS account ARN or IAM role ARN to restrict access.

Pre-Signed URLs

Generate a time-limited URL that grants temporary access to a private object:

bash
aws s3 presign s3://my-bucket/private-doc.pdf --expires-in 3600
# Returns a URL valid for 1 hour

Pre-signed URLs are useful for sharing private files with external users without making the bucket public.


S3 Versioning

When versioning is enabled, S3 keeps every version of every object:

bash
# Enable versioning
aws s3api put-bucket-versioning \
  --bucket my-bucket \
  --versioning-configuration Status=Enabled

Deleting an object adds a delete marker — the object isn't actually removed. You can restore a previous version or permanently delete a specific version. Versioning is a prerequisite for S3 Cross-Region Replication and MFA Delete.

MFA Delete

With MFA Delete enabled, permanently deleting a version or changing versioning status requires MFA authentication. Protects against accidental and malicious deletion.


S3 Lifecycle Rules

Lifecycle rules automate transitioning objects between storage classes and expiring (deleting) them:

json
{
  "Rules": [
    {
      "ID": "archive-old-logs",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" },
        { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 2555 }
    }
  ]
}

This rule takes logs from Standard → Standard-IA at day 30 → Glacier at day 90 → Deep Archive at day 365 → deleted at day 2555 (7 years). Lifecycle rules are essential for cost control — without them, data accumulates in expensive Standard storage indefinitely.


S3 Static Website Hosting

S3 can host a static website (HTML, CSS, JavaScript, images) without any server: enable static website hosting in bucket properties, set index.html as the index document, disable Block Public Access (for public websites), add a bucket policy allowing s3:GetObject to "Principal": "*", and access at http://<bucket-name>.s3-website-<region>.amazonaws.com.

For production static sites, combine S3 with CloudFront for HTTPS, custom domains, and global edge caching.

bash
# Sync a local website folder to S3
aws s3 sync ./website/ s3://my-website-bucket --delete

S3 Replication

Cross-Region Replication (CRR) automatically replicates objects to a bucket in a different region. Requires versioning enabled on source and destination. Use cases: disaster recovery, regulatory requirements, lower-latency access for users in a different region.

Same-Region Replication (SRR) replicates objects within the same region to a different bucket. Use cases: aggregating logs from multiple accounts, maintaining a test copy of production data.


Previous: Lesson 4 — Amazon EC2 | Next: Lesson 6 — AWS VPC & Networking


Part of the AWS Cloud Fundamentals course.

External references: