PW
Back to home

Amazon S3

Jul 25, 2026

AWS

Amazon S3: Buckets, Objects, Versioning, Replication, and Storage Classes

Amazon S3 is one of the most important services in AWS because it solves a very common problem: storing files in the cloud. S3 means Simple Storage Service, and the idea is simple. You upload data as objects, keep those objects inside buckets, and let AWS handle the storage infrastructure for you. Many websites, applications, backup systems, data lakes, and AWS services use S3 in the background because it can scale without you managing servers.

If you are learning AWS as a developer, S3 is not just a place to upload images or documents. It is also used for static website hosting, application assets, backups, analytics data, software delivery, disaster recovery, and archive storage. So when we talk about S3, we are really talking about a storage foundation that many cloud systems depend on.

What Amazon S3 Is Used For

S3 is object storage. That means it is made for storing files, not for running operating systems like EC2 instance storage, and not for relational database tables like RDS. You can store almost any kind of file: images, videos, logs, backups, reports, frontend build files, exported data, or large datasets for analytics.

Common S3 use cases are backup and storage, disaster recovery, archive, hybrid cloud storage, application hosting, media hosting, data lakes, big data analytics, software delivery, and static websites. For example, a company may store years of historical data in S3 Glacier for archive, while another company may store analytics data in S3 and run queries on top of it later. The service is flexible because the same basic storage model can support many different workloads.

Buckets Are Where Objects Live

In S3, files are called objects, and objects are stored inside buckets. A bucket is like a top-level container for your data. S3 may look like one global service in the AWS console, but buckets are created in a specific AWS Region. That means when you create a bucket, you still choose where the data should live geographically.

Bucket names also matter because they must follow strict rules. A bucket name needs to be unique based on the namespace model being used, and it must use lowercase letters or numbers at the start. You cannot use uppercase letters or underscores, the name cannot look like an IP address, it must not start with xn--, and it must not end with -s3alias. This is one of those small AWS details that can block you during setup if you do not know it earlier.

Example bucket names:

my-app-prod-assets
dev-backup-files-2026
company-data-lake-us-east-1

Bad bucket names:

My_App_Bucket
192.168.1.1
xn--mybucket
mybucket-s3alias

Objects and Keys

Every file in S3 is an object, and every object has a key. The key is the full path of the object inside the bucket. For example, if you upload a file to s3://my-bucket/images/logo.png, the bucket is my-bucket, and the key is images/logo.png.

This is important because S3 does not really have folders like your local computer has folders. The console shows folders to make the UI easier, but behind the scenes S3 is storing object keys that contain slashes. So images/logo.png is not a real folder plus file in the traditional sense. It is one object with a key that looks like a path.

Example S3 paths:

s3://my-bucket/my-file.txt
s3://my-bucket/uploads/profile/avatar.png
s3://my-bucket/logs/2026/07/25/app.log

An object also has more than just content. It can have metadata, tags, and a version ID if versioning is enabled. Metadata is key-value information about the object. Tags are also key-value pairs and are useful for lifecycle rules, cost tracking, and security decisions. The object body is the actual file content.

Object Size and Multipart Upload

S3 supports very large objects. The maximum object size is 50 TB. But there is an important rule: if you upload an object larger than 5 GB, you must use multipart upload. Multipart upload breaks a large file into smaller parts, uploads those parts, and then S3 combines them into one object.

This matters because large uploads can fail because of network issues. If you upload one huge file as a single request and the connection breaks near the end, you may need to start again. Multipart upload makes large uploads more reliable because failed parts can be retried without uploading the whole object again.

S3 Security Basics

S3 security can come from user-based permissions or resource-based permissions. User-based permissions usually mean IAM policies attached to a user, group, or role. Resource-based permissions usually mean bucket policies or access control lists. ACLs can be disabled and are less commonly preferred today, while bucket policies are still very important.

The access decision is simple in principle. An IAM principal can access an S3 object if the IAM policy allows it or the resource policy allows it, and there is no explicit deny. Explicit deny always wins. This is why S3 permission issues can be confusing at first. You may have one policy allowing access, but another policy denying it.

A bucket policy is written in JSON. It defines the effect, action, resource, and principal. You can use bucket policies to grant public access, force encryption at upload, or grant access to another AWS account.

Example bucket policy shape:

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

This kind of policy allows public read access to objects in the bucket. That can be useful for static websites, but it is dangerous for private data. If the bucket should never be public, keep Block Public Access enabled. AWS created Block Public Access settings to help prevent accidental data leaks, and they can be applied at the bucket level or account level.

IAM Roles for Application Access

If an EC2 instance needs to read or write files in S3, the better approach is to use an IAM role. Do not hardcode AWS access keys inside the application. Attach an IAM role to the EC2 instance, give that role the required S3 permissions, and let AWS provide temporary credentials automatically.

This makes the application safer and easier to operate. If the instance needs read-only access, give it only read permissions. If it needs to upload logs, give it only the upload permissions it needs. This follows least privilege, meaning the application should have enough permission to do its job, but not more than that.

Static Website Hosting with S3

S3 can host static websites. A static website means HTML, CSS, JavaScript, images, and other frontend files that do not require a backend server inside S3. For example, a React or Vue app can be built into static files and uploaded to an S3 bucket.

The website URL depends on the region and usually looks like this:

<http://bucket-name.s3-website-aws-region.amazonaws.com>
<http://bucket-name.s3-website.aws-region.amazonaws.com>

If you enable static website hosting and still get 403 Forbidden, the common issue is permissions. The bucket policy must allow public reads for the website files, unless you are using another private access pattern. Static website hosting is useful, but you need to be careful because public websites and private buckets are different security models.

Versioning Protects Your Objects

S3 versioning lets you keep multiple versions of the same object. It is enabled at the bucket level. If you upload my-file.docx, then upload another file with the same key, S3 does not simply replace the old version permanently. It stores a new version.

Versioning is a best practice because it protects against accidental overwrites and unintended deletes. If someone uploads the wrong file, you can roll back to a previous version. If someone deletes an object, you may be able to restore it depending on the versioning behavior and delete marker.

There are two important notes. First, files that existed before versioning was enabled have a version ID of null. Second, suspending versioning does not delete previous versions. It only stops creating new versions in the same way going forward.

Replication: CRR and SRR

S3 replication copies objects from one bucket to another. There are two main types: Cross-Region Replication and Same-Region Replication. Cross-Region Replication copies objects to a bucket in another AWS Region. Same-Region Replication copies objects to another bucket in the same Region.

Replication requires versioning on both the source and destination buckets. The copying is asynchronous, so it does not always happen instantly. You also need to give S3 the correct IAM permissions so it can replicate objects for you.

CRR is useful for compliance, lower latency access in another region, and replication across accounts. SRR is useful for log aggregation, live replication between production and test accounts, or keeping a second copy of data in the same region for operational reasons.

There are a few replication details that are easy to miss. After you enable replication, only new objects are replicated by default. If you want to replicate existing objects, you can use S3 Batch Replication. Delete marker replication is optional, but deleting a specific version by version ID is not replicated. Also, replication does not chain. If bucket one replicates to bucket two, and bucket two replicates to bucket three, objects created in bucket one do not automatically continue to bucket three.

S3 Storage Classes

S3 has different storage classes because not all data is used in the same way. Some data is accessed every day. Some data is kept only for backup. Some data is archived for years and rarely opened. If you store all data in the same class, you may pay more than needed.

S3 Standard is the general-purpose storage class. It is used for frequently accessed data and gives low latency and high throughput. It is a good fit for content distribution, mobile applications, gaming applications, and big data analytics where data needs to be available quickly.

S3 Standard-Infrequent Access is for data that is accessed less often but still needs rapid access when required. It costs less than S3 Standard for storage, but retrieval has a cost. It is commonly used for backups and disaster recovery.

S3 One Zone-Infrequent Access stores data in a single Availability Zone. It still has high durability inside that AZ, but if the AZ is destroyed, the data can be lost. This class makes sense for secondary backup copies or data you can recreate.

S3 Glacier storage classes are for archive and backup. Glacier Instant Retrieval gives millisecond retrieval for archive data accessed around once a quarter. Glacier Flexible Retrieval supports expedited, standard, and bulk retrieval times. Glacier Deep Archive is for long-term storage where waiting 12 to 48 hours for retrieval is acceptable.

S3 Intelligent-Tiering automatically moves objects between access tiers based on usage. It has a small monitoring and auto-tiering fee, but there are no retrieval charges. This is useful when you do not know the access pattern of the data in advance.

Durability vs Availability

Durability and availability are not the same thing. Durability means how safely your objects are stored over time. S3 is designed for 99.999999999% durability, also called eleven nines, across multiple Availability Zones for most storage classes. In simple words, S3 is designed so object loss is extremely rare.

Availability means how easily the service can serve your data when you request it. Availability depends on the storage class. For example, S3 Standard has 99.99% availability, while S3 Standard-IA has 99.9%, and S3 One Zone-IA has 99.5%. So durability is about not losing data, and availability is about being able to access it when needed.

Best Practices

  • Enable versioning for important buckets so accidental overwrites and deletes are easier to recover from.
  • Keep Block Public Access enabled unless the bucket is intentionally public, like a static website bucket.
  • Use IAM roles for applications instead of hardcoding AWS credentials.
  • Choose storage classes based on access patterns, not just the lowest storage price.
  • Use multipart upload for large files, especially anything above 5 GB.
  • Use replication when compliance, regional access, or account separation requires another copy.
  • Use object tags for lifecycle, security, and cost organization.

Common Pitfalls

  • Treating S3 folders like real directories. S3 stores objects with keys, and slashes are only part of the key name.
  • Making a bucket public by accident. Public access should be intentional, reviewed, and limited to the correct objects.
  • Forgetting that bucket names have strict naming rules.
  • Uploading large files without multipart upload.
  • Enabling replication and expecting old objects to copy automatically.
  • Thinking replication chains from bucket one to bucket two to bucket three automatically.
  • Choosing Glacier Deep Archive for data that the application may need quickly.
  • Confusing durability with availability.

Quick Summary

Amazon S3 is AWS object storage. You create buckets, upload objects, and access those objects by their keys. Buckets are region-based, object keys act like full paths, and security is controlled through IAM policies, bucket policies, ACLs, encryption, and public access settings. S3 can host static websites, protect files with versioning, copy objects with replication, and reduce cost with different storage classes. If you understand buckets, objects, permissions, versioning, replication, and storage classes, then S3 becomes much easier to use in real projects.