Day 17: AWS Storage Core — S3 and EBS
Days 15-16 covered networking. Today we move into storage — starting with the two foundational storage services almost everything else builds on: S3 and EBS. They solve fundamentally different problems, and knowing which one fits which use case is one of the most practical things to get right early.
Amazon S3 (Simple Storage Service)
S3 is used to store files — and in AWS, a consistent naming pattern shows up across a lot of services: it starts with "Simple" and ends with "Service" (Simple Notification Service, Simple Email Service, Simple Queue Service all follow the same pattern). S3 can store any kind of flat file, and with it you can upload, download, and access files — but you can't execute anything inside S3. You can't install an OS, run a database, or run executables there. S3 is serverless, much like Google Drive — there's no server for you to manage, patch, or scale; AWS handles high availability, performance, and scalability for it entirely.
The structure maps cleanly to a familiar mental model: a bucket is a container of objects — think of it like a folder. An object is a file. And the key is the object's name — including its full path, like docs/report.pdf. Buckets are Regional, meaning a bucket created in Mumbai lives in Mumbai, and bucket names have to be globally unique across all of AWS, not just your account.
S3 is object-based storage — this is the key distinction from EBS, which is block-based. You're storing and retrieving whole files by key, not managing raw disk blocks.
Static website hosting is a genuinely common real-world use of S3: if you have a static website — meaning no server-side processing, just HTML/CSS/JS files — S3 supports hosting it directly. Create a bucket, upload your HTML files, enable static website hosting, and you're done. No need to worry about HA, performance, or scalability, because S3 handles all of that for you the same way it does for any other object stored there.
A few things worth knowing beyond the fundamentals:
- Storage classes let you trade off cost against retrieval speed and availability. S3 Standard is for frequently accessed data; S3 Standard-IA (Infrequent Access) is cheaper for data you don't touch often but still need quickly when you do; S3 Intelligent-Tiering automatically moves objects between tiers based on actual access patterns, which is useful when you don't know your access pattern in advance. (Glacier, for archival, gets its own dedicated post shortly.)
- Versioning keeps multiple versions of an object in the same bucket, so an accidental overwrite or delete isn't permanent — you can always roll back to a previous version.
- Lifecycle policies automate moving objects between storage classes, or deleting them entirely, based on age — for example, automatically shifting logs to a cheaper tier after 30 days and deleting them after a year.
- Encryption is available both server-side (S3 manages the keys, or you use KMS-managed keys for more control) and via HTTPS in transit.
- Bucket policies and IAM policies both control access to S3, but at different levels — a bucket policy is attached directly to the bucket and can grant or deny access to anyone (including other accounts), while an IAM policy is attached to a user or role and defines what that identity can do.
- Presigned URLs let you grant temporary, time-limited access to a private object without making the whole bucket public — useful for things like letting a user download a file they paid for.
- Large uploads use multipart upload, splitting a big file into parts that upload in parallel and get reassembled — much more resilient than uploading a huge file in one shot.
Amazon EBS (Elastic Block Storage)
Where S3 stores files as objects, EBS gives you raw block storage — the AWS equivalent of a hard disk. In fact, the simplest way to think about it: hard disk = volume = EBS volume.
When you launch an EC2 instance, it automatically gets a default volume called the root volume, which contains the operating system. Windows instances get a 30GB root volume by default; Linux instances get 8-10GB. An EC2 instance can only ever have one root volume, but you can attach multiple additional volumes to it for extra storage.
Creating and managing volumes follows a specific lifecycle: if you want a volume, you create it and then attach it to an instance; if you want to remove it, you detach it first and then delete it — you can't delete a volume while it's still attached. Volumes need to be pre-provisioned — you decide the size upfront (say 50GB or 100GB), up to a maximum of 16TB per volume.
A detail that trips a lot of people up: volume size can be increased on the fly, with zero downtime and no need to stop the instance — but it can never be decreased. If you over-provisioned and want a smaller volume, your only option is to create a new, smaller one and migrate the data over, then delete the old one.
Availability Zone matters a lot here. Both an EC2 instance and its volumes live in a specific Availability Zone, and a volume can only attach to an instance in the same AZ — you can't attach a volume from AZ 1a to an instance running in AZ 1b. One volume also can't be shared across multiple instances at the same time; it's a one-to-one relationship (this is different from EFS, which we'll cover in an upcoming post, and which is specifically built for sharing storage across instances).
Device naming conventions: the root volume is typically mounted as /dev/sda1 (or /dev/xvda on some instance types), while additional volumes get names like /dev/sdb, /dev/sdf, /dev/sdg, and so on.
Can you detach the root volume while the instance is running? No — because it holds the operating system the instance is actively running on. You'd need to stop the instance first, then detach it (though this is rarely something you'd actually want to do). Additional volumes, on the other hand, can technically be detached while the instance is running, though it's not generally recommended without properly unmounting the filesystem first to avoid data corruption.
A couple of things worth knowing beyond the class notes:
- EBS offers different volume types for different performance needs: gp3/gp2 are general-purpose SSD (the default choice for most workloads), io1/io2 are provisioned-IOPS SSD for high-performance, latency-sensitive workloads like large databases, and st1/sc1 are lower-cost HDD options for throughput-heavy or infrequently accessed workloads.
- Snapshots are point-in-time, incremental backups of a volume, stored in S3 behind the scenes. Only the changed blocks since the last snapshot are actually saved, which keeps them fast and cost-efficient — and you can create a new volume from a snapshot at any time, including in a different Availability Zone.
S3 vs EBS — the core distinction
| S3 | EBS | |
|---|---|---|
| Storage type | Object-based | Block-based |
| Attached to | Nothing — accessed independently | A specific EC2 instance |
| Scope | Regional, accessible from anywhere | Regional, tied to one AZ |
| Can be shared across instances? | Yes, inherently | No, one-to-one only |
| Typical use | Files, static assets, backups, website hosting | The "hard disk" behind a running instance |
Quick Recap Questions
- What's the actual difference between object-based storage and block-based storage?
- Why can't you attach an EBS volume to an instance in a different Availability Zone?
- Can you decrease an EBS volume's size? What's your only real option if you over-provisioned?
- What is a bucket, an object, and a key, in S3 terms?
- Why can't a single EBS volume be shared across multiple EC2 instances the way an S3 bucket effectively can be accessed by many things at once?
Where to read & follow
- Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
- GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
- LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/
Coming up next
| Day | Topic | Services |
|---|---|---|
| 18 | Storage — Extended | EFS, Snow Family, Glacier, Storage Gateway |
Top comments (0)