S3 & CloudFront

• S3 is where most AWS data actually lives — logs, backups, static assets, Terraform state and the frontend of modern apps.
• CloudFront is the standard way to serve that content fast and cheaply to a global audience.
• Versioning and lifecycle rules turn plain storage into a backup and retention system.
• Static sites and media served via CloudFront reduce origin load and egress cost.
• Object storage versus block storage (EBS) is a core distinction every interview covers.

S3 is the central archive: every book lives on a shelf identified by a catalog number (the key), and the library never loses a copy. CloudFront is the neighborhood branch: popular books are copied to branches near you so you grab them instantly instead of waiting for the courier from the central archive. Updates flow to branches, and old editions are kept per versioning.

• You create a bucket in a region with a globally unique name; objects are stored with a key, and both appear in the object's URL.
• Data is redundantly written across availability zones within the region to provide 11 nines of durability.
• Bucket policies and IAM policies control who can read or write; server-side encryption protects data at rest.
• CloudFront sits in front of the bucket: the first request fetches from the origin and caches it at an edge location, keyed by the cache policy.
• Subsequent requests anywhere in the region hit the edge — cutting latency and offloading the origin — until you invalidate the cache after a deploy.

• Host the build output of a frontend (Vite, Next.js static export) in S3 behind CloudFront.
• Store application and access logs in S3 with a lifecycle policy that ages them to Glacier and deletes after N years.
• Enable versioning on critical buckets so accidental overwrites and deletes are recoverable.
• Serve videos and images from CloudFront with signed URLs for private content.
• Use S3 for Terraform state, database backups and CI artifacts — the de facto storage layer of DevOps.

• Bucket names are globally unique and use only lowercase letters, numbers, dots and hyphens.
• Default to versioning enabled and lifecycle rules from day one — you cannot add history after data is gone.
• Block public access on buckets unless a website needs it; prefer CloudFront and signed URLs.
• Use prefixes like logs/app/2026/08/ so listing and lifecycle policies stay cheap.
• Turn on server-side encryption and S3 access logging for auditability.

• Making a bucket public for one file and accidentally exposing every object in it.
• Forgetting that S3 is eventually consistent for some operations — a just-written object may briefly not appear in a list.
• Serving an S3 static site without CloudFront and paying per-request egress from the origin region.
• Storing unencrypted customer data in a default bucket with no versioning.
• Using one bucket for everything, then struggling to attach permissions per team.

• Check the exact error code: NoSuchBucket, NoSuchKey, AccessDenied and 403 all mean different fixes.
• Test with curl -I to see status and cache headers; x-cache tells you edge versus origin.
• Verify the key path — S3 keys are case-sensitive and the object may sit under a prefix you missed.
• Use aws s3 ls s3://bucket/prefix/ to confirm the object actually exists before debugging permissions.
• For 403 on public reads, check both the bucket policy and the Block Public Access settings.