Amazon S3 was one of AWS’s very first services, launched back in 2006, and it’s arguably the one that’s aged the best. Nearly two decades later, S3 now stores more than 400 trillion objects and sits underneath more than a million data lakes running on AWS. If you’re learning cloud computing, S3 is close to unavoidable: it’s the default place data lands, whether that’s a static website’s images, a data lake feeding a machine learning pipeline, or a simple application backup.

This tutorial covers everything you need to start using S3 confidently: core concepts, storage classes, creating and managing buckets, security and permissions, and a genuinely important 2026 change to how bucket naming works that catches even experienced AWS users off guard if they learned S3 a few years ago. No prior AWS experience required, though basic cloud computing familiarity will help the concepts click faster.

What Is Amazon S3?

Amazon S3 (Simple Storage Service) is AWS’s object storage service, designed to store and retrieve any amount of data, from a single small file to exabytes of data, with high durability and availability. Unlike a traditional file system with folders and directories, S3 stores data as “objects” inside flat containers called “buckets,” a structure that scales far more easily than a hierarchical file system once you’re dealing with massive amounts of data.

S3 is built for 99.999999999% durability, commonly written as “11 nines,” meaning the odds of losing an object stored in S3 are vanishingly small, achieved by automatically storing redundant copies of your data across multiple physical facilities. This durability, combined with pay-as-you-go pricing and effectively unlimited scalability, is why S3 has become the default storage layer behind such a wide range of AWS-based architectures.

Key S3 Concepts: Buckets, Objects, and Keys

A few terms come up constantly in S3, and getting comfortable with them early makes everything else in this guide easier to follow.

Buckets are the top-level containers that hold your data, similar in spirit to a top-level folder, though S3’s actual internal structure is flatter than that folder analogy suggests. Each bucket is created within a specific AWS region and, as of 2026, uses an updated naming system covered in detail later in this guide.

Objects are the individual files you store in S3: images, videos, documents, backups, log files, or anything else. Each object consists of the actual data, a unique key (its name and effective “path” within the bucket), and metadata describing the object.

Keys are the unique identifiers for objects within a bucket, functioning like a file path (for example, images/2026/photo.jpg), even though S3 doesn’t have true nested folders the way a traditional file system does. The console displays keys with slashes as if they were folders, purely for visual organization, but underneath, S3 treats the entire key as a single flat string.

Prefixes are the portion of a key before the last slash, commonly used to organize and filter objects that share a common “folder-like” grouping, and relevant when setting up permissions or lifecycle rules scoped to a specific subset of objects rather than an entire bucket.

S3 Storage Classes Explained

Not all data needs the same level of availability or access speed, and S3’s storage classes let you match your storage choice to how you actually access that data, which directly affects cost.

S3 Standard is the default, general-purpose storage class, offering low latency and high throughput for frequently accessed data, and the right starting point for most beginners and most everyday use cases.

S3 Intelligent-Tiering automatically moves objects between access tiers based on actual usage patterns, shifting data to lower-cost tiers after periods of inactivity (commonly 30, 90, and 180 days) without requiring you to manually predict and manage access patterns yourself.

S3 Standard-IA (Infrequent Access) and S3 One Zone-IA offer lower storage costs for data you access less often but still need available quickly when you do need it, with One Zone-IA storing data in a single Availability Zone rather than replicating across multiple zones, at a correspondingly lower price and lower resilience.

S3 Express One Zone is the newest, highest-performance storage class, purpose-built for latency-sensitive workloads like machine learning training and interactive analytics. It delivers data access speeds up to 10 times faster than S3 Standard, with request costs up to 80% lower, using a dedicated bucket type called a “directory bucket” that can handle up to 2 million requests per second. It integrates directly with services like SageMaker, Athena, EMR, and Glue, and as of 2026 has expanded to 15 AWS regions.

S3 Glacier Instant Retrieval, Glacier Flexible Retrieval, and Glacier Deep Archive cover long-term archival storage at progressively lower costs, trading retrieval speed for storage price, with Glacier Deep Archive being the cheapest option, suited for data you need to retain for compliance reasons but essentially never expect to access.

For a beginner just getting started, S3 Standard is the right default until you have a specific reason (cost optimization for infrequently accessed data, or extreme latency requirements) to reach for one of the more specialized classes.

Creating Your First S3 Bucket (Step-by-Step)

Here’s a practical walkthrough for creating a bucket and uploading your first object through the AWS Management Console.

1. Sign in to the AWS Console and navigate to S3 under the Storage section of the services menu.
2. Click “Create bucket” to open the bucket configuration wizard.
3. Choose a bucket name. As of 2026, this works differently than it used to, covered in detail in the next section.
4. Select an AWS region for your bucket. Choose one close to where most of your users or applications will access the data, since this affects latency.
5. Configure Block Public Access settings. By default, all four public access blocking options are enabled, which is the right choice unless you have a specific, deliberate reason to make bucket contents publicly accessible, like hosting a static website.
6. Enable or leave versioning disabled, depending on whether you want S3 to retain every version of an object as it changes over time, covered in more detail later in this guide.
7. Review and create the bucket.
8. Upload your first object by opening the newly created bucket and selecting “Upload,” then choosing a file from your computer.

Once uploaded, your object is immediately available (subject to whatever permissions you’ve configured), and you can view its properties, including its unique object URL, storage class, and metadata, directly from the console.

Uploading, Downloading, and Managing Objects

Beyond the console, S3 objects are commonly managed through the AWS CLI, which is generally faster for repetitive tasks and essential for automation.

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

# Upload an entire folder recursively
aws s3 cp my-folder/ s3://my-bucket-name/my-folder/ --recursive

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

# List objects in a bucket
aws s3 ls s3://my-bucket-name/

# Sync a local folder with a bucket, uploading only new or changed files
aws s3 sync my-folder/ s3://my-bucket-name/my-folder/

The sync command is particularly useful for ongoing workflows, since it only transfers files that are new or have changed, rather than re-uploading everything every time, which saves both time and unnecessary data transfer cost on larger folders.

S3 Bucket Naming in 2026: The Account Namespace Change

This is genuinely important if you’re learning S3 from slightly older tutorials or documentation, since it changes a rule that had been true since S3 launched in 2006.

For nearly two decades, every S3 general-purpose bucket name had to be globally unique across all AWS accounts worldwide, meaning if someone else had already claimed a bucket name like my-data, you simply couldn’t use it, regardless of which account or region you were working in. As of March 2026, AWS introduced account-level namespaces for general-purpose buckets, meaning bucket names now only need to be unique within your own AWS account, not globally across every AWS customer on the planet.

This is a genuinely welcome change for anyone who’s previously run into the frustration of a simple, logical bucket name already being taken by an unrelated AWS customer somewhere else in the world. It also simplifies Infrastructure as Code practices, since you can now use predictable, consistent bucket names across different accounts (like separate development and production environments) without needing to append random suffixes just to guarantee global uniqueness.

If you’re working with an older tutorial that emphasizes elaborate bucket-naming strategies specifically to avoid global name collisions, that specific concern is considerably less pressing in 2026 than it used to be, though bucket names still need to follow standard formatting rules: lowercase letters, numbers, hyphens, and periods, between 3 and 63 characters.

S3 Permissions and Security

Getting S3 permissions right matters enormously, since misconfigured bucket permissions have been behind a meaningful share of real-world data breaches over the years, generally not because of a flaw in S3 itself, but because of buckets accidentally left publicly accessible.

Block Public Access settings, enabled by default on new buckets, prevent public access even if an individual bucket policy or object permission would otherwise allow it, functioning as an important safety net against accidental misconfiguration. Disabling these settings should be a deliberate, specific decision, never a default habit.

Bucket policies are JSON documents attached to a bucket, defining who can perform which actions (read, write, delete) under what conditions, and are the standard way to grant access to specific AWS accounts, IAM roles, or, in deliberate cases, the public.

IAM policies attached to specific users or roles control what those identities can do across AWS, including S3, offering more granular, identity-centered control compared to a bucket policy’s resource-centered approach. Most real-world setups combine both: IAM policies controlling what your applications and team members can do, and bucket policies controlling cross-account access or specific resource-level rules.

Pre-signed URLs solve a common practical problem: granting temporary access to a private object without making the entire bucket public. A pre-signed URL includes a cryptographic signature and expiration time, letting anyone with that specific link access (or upload) a specific object for a limited window, without needing AWS credentials of their own.

# Generate a pre-signed URL valid for 1 hour (3600 seconds)
aws s3 presign s3://my-bucket-name/private-file.pdf --expires-in 3600

This pattern shows up constantly in real applications: letting a user download a report they generated, or upload a profile picture directly to S3 from a browser, without your application server needing to sit in the middle of every file transfer. It’s one of the more practically useful S3 features once you move beyond basic bucket setup, and it’s worth understanding even as a beginner, since it solves a problem (“share this one file securely, temporarily”) that comes up in nearly every real project involving user-generated content.

Encryption should generally be enabled for anything beyond casual experimentation. S3 supports server-side encryption by default for new buckets, and you can also configure client-side encryption or use AWS Key Management Service (KMS) for more granular control over encryption keys.

S3 Versioning and Lifecycle Policies

Versioning, once enabled on a bucket, retains every version of an object as it’s overwritten or deleted, rather than the default behavior of simply replacing or removing data permanently. This is genuinely valuable protection against accidental deletion or overwrite, at the cost of additional storage for every retained version, which is worth factoring into your cost planning before enabling it broadly across large, frequently updated buckets.

Lifecycle policies automate the transition of objects between storage classes, or their deletion, based on rules you define. A common pattern: keep objects in S3 Standard for 30 days, transition them to S3 Standard-IA for the next 60 days, then move them to Glacier for long-term archival, and finally delete them entirely after a defined retention period, all handled automatically without manual intervention once the policy is configured.

Combining versioning with a lifecycle policy that expires old versions after a defined period is a common, sensible pattern: you get protection against accidental data loss, without indefinitely accumulating storage costs from every historical version of every object.

Cross-Region Replication and Data Durability

Beyond versioning, S3 offers Cross-Region Replication (CRR) and Same-Region Replication (SRR), both automatically copying objects from a source bucket to a destination bucket, either in a different region or within the same one.

Cross-Region Replication is commonly used for compliance requirements that mandate data residency in specific geographic locations, disaster recovery planning, and reducing latency for users accessing data from a distant region by maintaining a local copy closer to them. Same-Region Replication is more often used for aggregating logs from multiple buckets into one central location, or maintaining a separate copy within the same region for account-isolation or backup purposes.

It’s worth distinguishing replication from S3’s already extreme baseline durability. Standard S3 storage classes already replicate data across multiple Availability Zones within a single region automatically, as part of the “11 nines” durability guarantee covered earlier. Cross-Region Replication is an additional, deliberate layer on top of that baseline, specifically for scenarios where an entire region becoming unavailable, an extremely rare event, would still be an unacceptable risk for your specific use case.

S3 for Static Website Hosting

S3 can host a static website (HTML, CSS, JavaScript, and associated assets) directly, without needing a separate web server, making it a popular, low-cost option for simple websites, documentation sites, and single-page applications.

Setting this up involves enabling the “Static website hosting” property on a bucket, specifying an index document (typically index.html) and optionally an error document, and configuring the bucket’s permissions to allow public read access specifically for the website content, since visitors need to be able to load the site without authentication. This is one of the legitimate, deliberate cases where disabling some of the default Block Public Access settings makes sense, since the entire point is public accessibility.

For anything beyond a simple static site, pairing S3 with CloudFront (AWS’s content delivery network) is standard practice, improving load times globally through edge caching and enabling HTTPS, which S3’s website hosting endpoint doesn’t support directly on its own.

S3 Pricing: How Costs Actually Add Up

S3 pricing has several components, and understanding all of them avoids the common surprise of an unexpectedly high bill despite seemingly modest storage usage.

Storage cost is billed per GB per month and varies by storage class, generally the most intuitive and predictable part of your S3 bill. Request costs are billed per API call (uploads, downloads, listing objects), and can add up meaningfully for applications making a very high volume of small requests, which is part of why S3 Express One Zone’s dramatically lower request costs matter so much for high-throughput workloads specifically. Data transfer costs apply primarily to data leaving AWS (to the internet or to a different AWS region), while data transferred within the same region, or into S3, is generally free or minimal.

A practical beginner habit: set up AWS Budgets with alerts early, and periodically review S3 usage through Cost Explorer, since it’s easy to accumulate forgotten objects or an overly broad versioning setup that quietly grows your storage costs over time without an obvious single cause.

What’s New in S3 for 2026: Tables, Vectors, and Express One Zone

S3 has evolved considerably beyond simple object storage, and a few 2026-specific developments are worth understanding even as a beginner, since they reflect where the service is heading.

S3 Tables, generally available since late 2024 and increasingly adopted through 2026, introduced a new bucket type purpose-built for Apache Iceberg tables, the open table format widely used in modern data lake architectures. S3 Tables delivers meaningfully faster query performance and higher transaction throughput for Iceberg tables compared to a self-managed setup, while automatically handling maintenance tasks like compaction and snapshot management that would otherwise require manual operational work.

S3 Vectors is a newer addition providing native vector storage and query capability directly within S3, aimed squarely at the growing demand for storing and searching AI embeddings without needing a fully separate, dedicated vector database for every use case.

S3 Express One Zone’s continued expansion reflects how central low-latency storage has become for AI training and inference workloads specifically. Pricing for Express One Zone saw significant reductions in early 2026, with storage costs cut by roughly 31% and GET request costs reduced by as much as 85% in some analyses, a clear signal that AWS is actively pushing adoption of this storage class for exactly the latency-sensitive AI and analytics workloads it was built for.

The broader pattern across all of these additions: S3 in 2026 is being actively repositioned as foundational infrastructure for AI and large-scale analytics workloads, not just a general-purpose file storage service, which is worth keeping in mind if your own career or projects are heading in an AI-adjacent direction.

Common S3 Beginner Mistakes

Leaving a bucket publicly accessible unintentionally. This remains one of the most consequential mistakes possible in S3, and Block Public Access being enabled by default exists specifically to prevent it. Never disable these settings without a specific, deliberate reason.

Choosing the wrong storage class and overpaying as a result. Storing rarely accessed data in S3 Standard, when S3 Intelligent-Tiering or Standard-IA would cost meaningfully less for the same access pattern, is a common and easily avoidable source of higher-than-necessary bills.

Enabling versioning without a lifecycle policy to manage it. Versioning without expiration rules can cause storage costs to grow indefinitely as old versions accumulate silently in the background, well beyond what most projects actually intend.

Forgetting that S3 doesn’t have true folders. The console’s folder-like display is a visual convenience over a genuinely flat key structure. This distinction matters when writing code that lists or filters objects by prefix, since the underlying behavior doesn’t always match the folder mental model beginners bring from a traditional file system.

Not enabling encryption for sensitive data. While S3 encrypts new buckets by default, it’s worth explicitly verifying your encryption configuration, particularly for buckets containing anything sensitive, rather than assuming a safe default without checking.

Common Real-World S3 Use Cases

S3’s flexibility means it shows up across an enormous range of applications: data lakes and analytics, often paired with services like Athena, EMR, and Glue for querying and processing data directly in place; backup and disaster recovery, given S3’s extreme durability and low storage costs for infrequently accessed data; static website and content hosting, particularly for simple sites and media assets served through CloudFront; application data storage, for user uploads, generated reports, and application logs; and AI and machine learning workflows, where S3 increasingly serves as the foundational storage layer for training data, model artifacts, and, through S3 Vectors and S3 Tables, structured data feeding directly into modern AI pipelines.

How to Continue Learning

S3 is foundational enough that understanding it well makes a large share of other AWS services easier to learn, since so many of them either store data in S3 directly or expect it as an input or output location.

If you haven’t already, our broader AWS tutorial is a good next step for understanding how S3 fits alongside other core services like EC2, Lambda, and IAM. Since cost surprises are one of the most common frustrations for AWS beginners, our complete guide to AWS pricing goes deeper into cost optimization strategies across services, including S3 storage class selection and lifecycle policy design. And if you’re still deciding how S3 and broader cloud storage concepts fit into your overall cloud strategy, our guide to cloud computing types is useful supporting context. For the most authoritative, always-current reference as AWS continues shipping new S3 features, Amazon’s own S3 documentation is worth bookmarking directly.

FAQs About Amazon S3

Is Amazon S3 free to use? S3 offers a free tier for new AWS accounts, providing 5GB of S3 Standard storage along with a limited number of free requests for 12 months. Beyond those limits, S3 is billed based on storage class, request volume, and data transfer.

What is the difference between S3 and EBS? S3 is object storage, designed for storing files accessed over the network through an API, well suited for unstructured data at massive scale. EBS (Elastic Block Store) is block storage that attaches directly to a single EC2 instance, functioning like a virtual hard drive for that specific server, and isn’t designed for the same kind of broad, multi-application access S3 provides.

Do I still need to worry about bucket name collisions in 2026? Much less than before. As of March 2026, general-purpose bucket names only need to be unique within your own AWS account rather than globally across every AWS customer, though names still need to follow standard formatting rules.

How durable is data stored in S3? S3 is designed for 99.999999999% durability, commonly described as “11 nines,” achieved by automatically storing redundant copies of your data across multiple physical facilities within a region for most storage classes.

What is S3 Express One Zone, and when should I use it? It’s S3’s highest-performance storage class, offering up to 10 times faster data access and significantly lower request costs than S3 Standard, purpose-built for latency-sensitive workloads like machine learning training and interactive analytics, using a single Availability Zone rather than the multi-zone replication of standard S3 classes.

Can S3 host a fully dynamic website with a backend? Not on its own. S3 can host static content directly (HTML, CSS, JavaScript, images), but dynamic, server-side functionality requires pairing it with a compute service like EC2, Lambda, or a container-based backend to handle logic that static files alone can’t provide.

What is a pre-signed URL, and why would I use one? A pre-signed URL grants temporary, time-limited access to a specific private object without making the whole bucket public or requiring the recipient to have AWS credentials. It’s commonly used for letting users download a specific file or upload content directly to S3 from an application, without exposing broader bucket access.

Should I enable Cross-Region Replication for every bucket? No, it’s generally reserved for specific needs like regulatory data residency requirements, disaster recovery planning, or reducing latency for geographically distant users. Standard S3 storage classes already replicate data across multiple Availability Zones within a region by default, which is sufficient durability for most everyday use cases without the added cost and complexity of cross-region replication.

Conclusion

S3’s staying power comes from getting the fundamentals right from the very beginning: simple, flat object storage, extreme durability, and pricing that scales down as naturally as it scales up. The concepts covered in this guide, buckets, objects, storage classes, and permissions, remain the foundation whether you’re storing a handful of personal files or building a petabyte-scale data lake feeding a machine learning pipeline.

The fastest way to make this knowledge stick is the same advice that applies to any new AWS service: create a free-tier-eligible bucket, upload and manage a few real objects, experiment with a lifecycle policy, and get comfortable with the permissions model before you’re relying on it for anything that actually matters. Reading about S3 only gets you so far compared to spending even an hour actually working through the console and CLI yourself.