What Is Amazon S3? Beginner Guide to AWS Object Storage

Simple explanation

S3 is object storage. That means you store complete, discrete files called objects, and retrieve them by name. It is not a hard drive, not a mounted filesystem, and not a traditional database. You cannot open an object and change one line inside it. To update a file, you overwrite the entire object.

This constraint is also what makes S3 highly scalable. No file locks, no consistency bottlenecks, no seek operations. S3 handles millions of simultaneous reads and writes without the coordination overhead that a filesystem requires.

How Amazon S3 works

Understanding six core concepts gives you a working mental model of S3.

Buckets are the top-level containers. Each bucket lives in one AWS region and has a globally unique name across all AWS accounts worldwide. You cannot move a bucket to a different region after creation.

Objects are the files stored inside buckets. An object holds a value (the file’s bytes), a key, and metadata. Objects can range from 0 bytes to 5 terabytes. See S3 Buckets Explained: Names, Regions, and Structure for the full breakdown of how bucket naming and object keys work.

Keys are the unique identifier for each object within a bucket. A key like reports/2025/january.pdf looks like a folder path, but S3 has no real folders. The key is just a string. The slashes are cosmetic; the console uses them to simulate a directory tree, but they have no special meaning to the storage layer.

Regions determine where your data physically lives. Data does not leave a region unless you explicitly configure replication. Choose a region close to your users or your compute resources to minimise latency and avoid inter-region transfer costs.

Metadata is a set of key-value pairs attached to each object. Some metadata is system-managed (content type, content length, ETag). You can also add custom metadata at upload time.

Storage classes control the price-versus-availability trade-off for each object. S3 Standard is the default. S3 Standard-IA (Infrequent Access) and the Glacier tiers cost less per GB but are designed for data you access rarely. See S3 Storage Classes: Choosing the Right Tier for a full comparison.

Versioning keeps every version of an object in a bucket instead of overwriting it. This protects against accidental deletions and overwrites. S3 Versioning: Protecting Objects from Accidental Deletion covers how this works and how to manage the storage costs it adds.

Access happens over HTTP/HTTPS via the AWS API, not through a mounted drive or a POSIX interface. When you upload or download an object, you are making an API call. This is why S3 is unsuitable for workloads that need low-latency random reads, appends, or filesystem semantics.

Why teams use S3

Static website hosting. An S3 bucket can serve HTML, CSS, and JavaScript files directly to browsers. Pair it with CloudFront for HTTPS, custom domains, and global caching. This is a common, low-cost way to host documentation sites, marketing pages, and single-page apps.

Application file uploads. When a user uploads an avatar or a PDF to your app, you store it in S3 rather than on the server’s local disk. Your servers stay stateless: files survive server restarts, replacements, and scaling events.

Backups. RDS automated backups, EC2 AMI snapshots, and on-premises backup tools all write to S3. The built-in redundancy makes it reliable long-term storage for recovery scenarios.

Data lakes and analytics. S3 is the foundation of AWS data pipelines. Services like AWS Glue, Amazon Athena, and Amazon EMR read directly from S3. You can store raw logs, processed records, and query results in the same bucket hierarchy, then query it in place without loading data into a separate database.

CDN origin for CloudFront. CloudFront distributions use S3 buckets as their origin. CloudFront caches content at edge locations worldwide while S3 holds the source files. Requests hit the edge cache rather than reaching S3 directly.

Log aggregation. AWS services (CloudTrail, ALB access logs, VPC Flow Logs) write their logs directly to S3 buckets you specify. Centralising logs in S3 makes them easy to archive, search with Athena, or forward to a SIEM.

When to use S3

S3 is a good fit when:

• You need to store files accessed over HTTP by users, services, or pipelines.
• Objects are written once and read many times (or rarely).
• You need effectively unlimited storage without provisioning capacity in advance.
• Files are large and accessed as complete units: documents, images, videos, archives.
• You need built-in durability across multiple Availability Zones without managing replication yourself.
• Cost efficiency matters and access patterns are predictable enough to use lifecycle policies to move data to cheaper tiers over time.

When not to use S3

• You need low-latency block storage. Database engines (MySQL, PostgreSQL) need consistent sub-millisecond disk I/O. Use EBS, not S3.
• Your application needs a POSIX filesystem. If code uses open(), seek(), flock(), or appends to files, it needs EBS or EFS. S3 has no concept of file handles or byte-range writes.
• Multiple instances need simultaneous write access to the same files. S3 does not support concurrent writers coordinating on the same object. Use EFS for shared filesystem workloads across EC2 instances.
• You need to update part of a file. S3 only supports whole-object replacement. If your workload appends log lines to a growing file, S3 is the wrong tool.

For a side-by-side comparison of all AWS storage options (including RDS, DynamoDB, and Glacier), see Choosing the Right AWS Storage Service for Your Use Case.

S3 vs EBS vs EFS

These three services are the most common sources of confusion for AWS beginners. They solve different problems.

Decision rules:

• Choose S3 when you are storing objects accessed over HTTP and you do not need filesystem semantics.
• Choose EBS when you need a persistent disk attached to one EC2 instance: for the OS, a database engine, or any workload requiring low-latency block I/O.
• Choose EFS when multiple EC2 instances need to read and write the same files at the same time using standard POSIX filesystem operations.

EBS works like a hard drive physically attached to one server. EFS works like a network drive that many servers can mount at once. S3 is none of these. It is a remote object store accessible via API from anywhere, including outside AWS.

Security and access model

S3 is private by default. Every new bucket blocks all public access, and every object inside it is private unless you explicitly grant access. This is the correct starting point for any workload.

Access to S3 is controlled by two mechanisms that work together:

• IAM policies grant specific AWS users, roles, or services permission to perform S3 actions. This is the identity-based approach: you define what a principal can do.
• Bucket policies are resource-based policies attached directly to a bucket. They can grant or deny access from specific accounts, roles, or IP ranges. A bucket policy can allow cross-account access that an IAM policy alone cannot achieve.

Understanding when to use each is a common source of confusion. S3 IAM Policies vs Bucket Policies: Which to Use walks through the decision logic clearly.

For cases where you need to give temporary access to a private object (for example, a download link that expires in 15 minutes), use S3 Signed URLs: Temporary Access to Private Objects instead of making the object or bucket public.

For the full picture of hardening your S3 setup (Block Public Access settings, server-side encryption, access logging, and Object Lock), see S3 Security Best Practices: Protecting Your Buckets.

Durability and availability

S3 Standard is designed for 99.999999999% durability (11 nines). In practice, AWS automatically stores copies of every object across at least three Availability Zones in the chosen region. Data loss due to hardware failure is essentially eliminated.

Availability is separate from durability. S3 Standard guarantees 99.99% availability: roughly 52 minutes of potential unavailability per year. Storage classes with lower per-GB costs, such as Standard-IA or Glacier Instant Retrieval, have lower availability SLAs in exchange for reduced storage pricing.

Getting started

The fastest way to confirm S3 is working in your AWS account is to list your buckets:

aws s3 ls

To upload a file to an existing bucket:

aws s3 cp myfile.txt s3://my-bucket-name/myfile.txt

For a full walkthrough of copying files, syncing directories, and using multipart uploads, see Uploading Files to S3 with the AWS CLI.