What is object storage vs block vs file in AWS - S3/EBS/EFS in plain terms

Object, block, and file storage are three different ways of handing your data to a computer, and on AWS they map to three specific services: Amazon S3 (object), Amazon EBS (block), and Amazon EFS (file). The short version: S3 stores whole files as "objects" you fetch by name over the web and is built for things like photos, backups, and logs; EBS is a virtual hard drive that bolts onto one EC2 server and is built for things like databases and boot disks; EFS is a shared folder that many servers can open at the same time. Here's the part almost nobody tells you until it costs them a Saturday: Amazon S3 cannot open a file and change three bytes in the middle of it. It can only ever replace the entire object. That single fact is the reason half the "why won't my app write to S3" questions on the internet exist, and it's the cleanest way to actually understand what object storage is.

What "storage" actually means once you're not buying a physical hard drive

Jake had never once, in fifteen years of running his phone shop, thought about "types" of storage. A hard drive was a hard drive. Then he moved his repair-ticket database and his customer photo archive to AWS in the same week, on the advice of a forum post that just said "use S3 for everything," and both broke in different, confusing ways.

Here's the plain-English version of the three shapes data can take. An object is a complete, self-contained file plus a label and some descriptive information (called metadata — this just means "data about the data," like a file's size, the date it was uploaded, or a custom tag you attach yourself). You don't edit an object; you replace it. A block is a raw, low-level chunk of storage — think of a hard drive sliced into thousands of numbered pieces — that an operating system or database can read from and write to at almost any point, byte by byte, the way you'd erase and rewrite a single word on a page without retyping the whole page. A file, in the traditional sense, lives inside a hierarchy of folders and subfolders that a proper file system understands, with permissions, timestamps, and the expectation that more than one program (or more than one computer) might open it at once.

Object storage skips the folder hierarchy and the byte-level editing. Block storage skips the "many computers at once" part. File storage tries to give you both a hierarchy and safe simultaneous access, at the cost of being slower and more expensive than a single dedicated hard drive. None of the three is "better" in the abstract. Each one is a trade someone at AWS made on purpose, and the trade only looks wrong if you point it at the wrong job.

Object storage: what Amazon S3 actually is

Amazon S3 stands for Simple Storage Service, and AWS's own description of it is "an object storage service." Every file you put into S3 lives inside a bucket, which is just a uniquely named container — think of it as the name of the warehouse, not a folder inside it. Every file itself is called an object, and every object has a key, which is the object's full name, including anything that looks like a folder path (so photos/puppy.jpg is a key, but S3 doesn't actually have a folder called "photos" behind the scenes — it just has one flat list of objects whose names happen to contain slashes).

You reach an object over the internet with a plain web address. AWS's own example is a bucket called amzn-s3-demo-bucket in the US West (Oregon) Region, where an object named photos/puppy.jpg is fetched at https://amzn-s3-demo-bucket.s3.us-west-2.amazonaws.com/photos/puppy.jpg. That's the whole idea of object storage in one sentence: everything is an address you ask for over HTTP, the same protocol your web browser already speaks, rather than a device your operating system has to physically mount.

Why you can't "edit" an S3 object

This is the counterintuitive reveal from the top of this post, and it's worth slowing down on because it explains almost every S3-related complaint you'll ever read. S3's operations are fundamentally: put a whole object in, get a whole object out, or delete a whole object. There's no operation that means "open this object and change the 400th byte." If you want to change one line inside a 2 GB log file sitting in S3, the only real option is to download the whole thing, change the line locally, and upload the entire 2 GB object back — there's no partial-write shortcut, because object storage was never built to offer one.

That's not a bug AWS forgot to fix. It's the trade that makes S3 able to durably store your object across multiple facilities, hand it to a thousand people downloading it simultaneously, and charge you a fraction of a cent per gigabyte per month for the privilege. Removing the "edit in place" feature is exactly what makes the other features possible. A block-storage volume, by contrast, is built almost entirely around allowing that in-place edit — which is why a database goes on EBS and a video archive goes on S3, not the other way around.

What S3 is genuinely good at

Amazon describes S3 as ideal for data lakes, mobile applications, backup and restore, archival, IoT devices, machine learning, AI, and analytics. In plainer terms: anything where a file gets written once (or occasionally replaced wholesale) and then read many times by many different consumers — a website's images, a nightly database backup, a folder of invoices customers download, training data for a machine learning model — is exactly what S3 was designed around. The total amount of data and the total number of objects you can store in a single account are effectively unlimited; AWS's own FAQ describes it as unlimited in both dimensions.

S3 also comes with a set of storage classes — essentially different pricing and durability tiers for the same object storage — so that data you rarely touch can sit somewhere cheaper without you moving it manually. The main ones are S3 Standard (frequent access), Standard-Infrequent Access and One Zone-Infrequent Access (cheaper, for things you access rarely but still need quickly when you do), S3 Intelligent-Tiering (which watches your access pattern and moves objects between tiers automatically), and the Glacier family (Glacier Instant Retrieval, Glacier Flexible Retrieval, and Glacier Deep Archive) for long-term archives where retrieval can take minutes to hours instead of being instant. You set a lifecycle rule once — a policy that says "move anything older than 90 days to Glacier" — and S3 handles the rest without you touching the object again.

Block storage: what Amazon EBS actually is

Amazon Elastic Block Store gives you "scalable, durable, high-performance block storage that is designed to be used with Amazon EC2," in AWS's own words. An EBS volume is a durable, block-level storage device you attach to an EC2 instance — once it's attached, your operating system treats it exactly like a physical hard drive plugged into the machine. You can format it, partition it, install an operating system on it, or point a database at it, and the database can seek to any position in the file and rewrite just that piece, the thing S3 can't do.

The word "block" refers to how the data is organized underneath: the volume is chopped into fixed-size chunks, and the operating system's file system (things like NTFS on Windows or ext4/XFS on Linux) is the layer that turns those raw blocks into something that looks like files and folders to you. EBS itself has no idea what a "file" is — that concept is entirely provided by whatever operating system is sitting on top of the volume. That's a genuinely useful mental model: EBS is the hard drive, your OS is the thing that organizes that hard drive into files.

One volume, one instance — with a narrow exception

An EBS volume and the EC2 instance it's attached to must live in the same Availability Zone (AZ) — one of the isolated physical data-center locations that make up an AWS Region. By default, a given EBS volume attaches to exactly one instance at a time, which is precisely why it's a poor fit for "several servers editing the same drive" jobs. There is one narrow exception worth knowing: EBS Multi-Attach, which is supported only on Provisioned IOPS SSD volumes (the io1 and io2 types) and lets a single volume attach to up to 16 Nitro-based EC2 instances in the same Availability Zone at once, each with full read and write access. But Multi-Attach doesn't turn EBS into a shared file system on its own — AWS's own guidance is that you still need a clustered file system to keep the data consistent, because ordinary file systems like XFS and EXT4 were never designed to be safely written to by more than one server simultaneously. Multi-Attach is a niche, advanced feature for applications built specifically to coordinate concurrent writers themselves; for the everyday "many servers, one shared folder" problem, EFS is almost always the right tool, not Multi-Attach.

EBS volume types, in plain terms

AWS's volume types split into two families: solid-state drive (SSD)-backed volumes for transactional workloads that need consistent low latency, and hard-disk drive (HDD)-backed volumes for large sequential jobs where total throughput matters more than the speed of any one operation.

Durability differs by type too: io2 Block Express is built for 99.999% durability with an annual failure rate around 0.001%, while the other volume types sit at 99.8%–99.9% durability. That's not a knock against the cheaper types — it just means EBS on its own is not your backup strategy, at any tier. AWS's own guidance is to pair EBS with regular snapshots (point-in-time copies of a volume, stored durably in S3 behind the scenes) precisely because a single volume, however durable, is still one thing living in one Availability Zone.

File storage: what Amazon EFS actually is

Amazon Elastic File System provides "simple, scalable file storage for use with Amazon EC2, Linux, and Mac instances in the AWS Cloud," according to AWS's own documentation, and it grows and shrinks automatically as you add and remove files — you never provision a fixed size the way you do with an EBS volume. EFS speaks NFS (Network File System), a long-established protocol that lets many separate computers mount and use the same file system at once, each seeing the identical set of folders and files in real time.

Where EBS gives one server a private hard drive, EFS gives many servers a shared filing cabinet. A single EFS file system can be mounted by thousands of EC2 instances, containers, or on-premises servers simultaneously — every one of them reading and writing the same files, seeing each other's changes immediately, the same way two people in an office both have access to the same shared network drive.

Where EFS earns its keep

Because EFS provides "a file system interface, file system access semantics such as strong consistency, and file locking," on top of storage shared across many clients, it's the natural home for anything a whole fleet of servers needs to agree on at once: a content management system where every web server in a load-balanced group needs to see the same uploaded images the instant they're added; shared code or configuration that a group of build servers all reference; home directories for a group of Linux users who might log into any of several machines. Amazon's own EFS documentation lists containers, serverless functions, big data analytics, and stateful workloads that need shared storage across Amazon ECS, Amazon EKS, AWS Fargate, and AWS Lambda as core use cases.

EFS also has its own storage classes for cost control: EFS Standard for regularly accessed files, EFS Standard-Infrequent Access for files opened less often, and an EFS Archive class for data touched only a handful of times a year — with lifecycle management that can automatically age files down to a cheaper tier after a set number of days (7, 14, 30, 60, or 90) without you doing anything by hand, and move them back up if they suddenly get accessed again.

Where EFS falls short

EFS has real limits worth knowing before you commit to it. It's built for Linux and Mac EC2 instances — Windows EC2 instances are not supported as EFS clients, because Windows doesn't use the NFS protocol the way Linux does. It also isn't a boot volume: you can't put a system drive on EFS, because instance boot storage is a block-storage job, handled by EBS. And because every read and write travels over the network to a shared file system rather than to a locally attached disk, EFS's per-operation latency is higher than a local EBS volume's — it's the right trade when the value is in the sharing, and the wrong trade when the value is in raw single-server speed.

S3 vs. EBS vs. EFS, side by side

Reading three separate service pages and holding all of it in your head at once is genuinely hard, so here's the comparison in one place. Treat this as the cheat sheet you come back to, not the whole story — the sections above and below fill in the "why" behind every row.

The four-question decision framework

"Ethan, just tell me which one," Jake said, after his second failed attempt to run a shop-inventory database on S3. "I don't want a philosophy lesson, I want an answer."

"Fine," Ethan said. "Answer these four questions in order, and stop at the first one that fits. Most people overthink this because they read all three service pages before asking the one question that actually decides it."

1. Does more than one server need to write to this data at the same time? If yes, and it's a normal shared-folder kind of need (not a specialized clustered database), go straight to EFS. If no, move to question 2.
2. Does the thing need to open a file and change part of it in place — a database, a boot disk, an actively-written log a single process appends to? If yes, that's EBS, attached to the one instance that owns it. If no, move to question 3.
3. Is it a complete file that gets written once (or replaced wholesale occasionally) and then read many times, by people or programs that don't all live on the same server? If yes, that's S3.
4. Still not sure? Default to S3 for anything that's fundamentally "a file I want to keep and fetch later," because it's the cheapest of the three per gigabyte and the easiest to migrate away from later if you're wrong.

Jake's inventory database needed question 2 — one server, constantly rewriting small pieces of a growing file. That's EBS. His customer photo archive needed question 3 — complete images, written once, downloaded by customers and staff from anywhere. That's S3. Neither needed EFS at all, which is common: plenty of small-to-medium setups never touch EFS because they don't have the "many servers, one shared folder" problem it solves.

The mistakes that actually cost people money and time

Mounting S3 as if it were a drive letter

There are third-party tools (and a Windows-friendly S3 file gateway option AWS offers through S3 Files, which surfaces S3 objects as a file system for certain compute services) that make an S3 bucket look like a mounted drive. That convenience layer is doing real translation work behind the scenes, and it comes with a specific gotcha: if a file was stored using one of S3's "asynchronous" storage classes — Glacier Flexible Retrieval or Glacier Deep Archive — trying to open it through that file-system view returns an input/output error, because those tiers aren't designed for instant, on-demand reads. You have to explicitly restore the object with an S3 API call first. If you've ever seen a mounted S3 folder throw a mysterious I/O error on one specific old file and work fine on everything else, that's almost always the cause.

Assuming EBS Multi-Attach solves "shared storage"

Multi-Attach sounds, from the name alone, like the answer to "I need two servers to share a drive." It's supported only on the Provisioned IOPS io1 and io2 volume types, capped at 16 Nitro-based instances in a single Availability Zone, and — critically — AWS's own guidance says you need a clustered file system layered on top to keep the data consistent, because ordinary file systems weren't built to be written by multiple servers at once. In practice, Multi-Attach is aimed at specialized applications engineered from the ground up to manage that coordination themselves. If what you actually want is "several ordinary web or app servers, one shared folder, no special engineering," that's EFS's whole job, and it will save you a very confusing debugging session.

Putting a database on EFS "because it's shared and that sounds safer"

Shared doesn't mean faster, and a database wants low, consistent per-operation latency more than it wants shareability. Because every read and write on EFS crosses the network to reach the file system, it typically carries higher per-operation latency than a locally attached EBS volume performing the same operation. That's a fine trade for shared web content; it's usually the wrong trade for the query engine underneath a busy database.

Treating an EBS snapshot as a full backup strategy on day one

Snapshots are genuinely good — they're point-in-time copies of a volume, and AWS stores them durably behind the scenes. But a snapshot you never took doesn't exist, and a "delete on termination" setting left at its default can wipe the volume it was protecting at the exact moment someone tears down an instance to save money. The mistake isn't using EBS; it's assuming durability at the volume level means you don't also need a deliberate backup schedule.

What each one actually costs you, in plain terms

None of these three bill you the same way, and mixing up the billing model is its own source of surprise invoices. S3 charges primarily per gigabyte stored per month, plus small per-request and data-transfer charges, and the price drops automatically as you move colder data into cheaper storage classes — it's the model built for "I don't know exactly how much I'll store, and it mostly just sits there." EBS charges per gigabyte provisioned, whether you use that space or not, and for Provisioned IOPS volumes you also pay separately for the IOPS you request — meaning an oversized, underused volume quietly costs you every month whether a single byte of it is touched. EFS charges per gigabyte actually stored (there's no fixed volume size to over-provision), plus a throughput charge that depends on which throughput mode you choose, which is why AWS's own comparisons routinely describe S3 as the cheapest option for storage alone, with EBS and EFS priced around the performance and sharing guarantees they add on top.

Why real applications almost always use all three at once

Picking "the one AWS storage type" is a false choice most projects never actually face. Take a small e-commerce site: the operating system and the product database sit on an EBS volume attached to the app server, because that's where in-place, low-latency edits matter. Product photos and customer invoices — files that get written once and downloaded many times, by many different people — live in S3, served up either directly or through a content delivery layer. And if the shop grows to a small fleet of app servers behind a load balancer, the uploaded images or shared configuration those servers all need to see identically go on EFS, so every server in the fleet reflects the same files the instant one of them writes a change.

Even EBS and S3 quietly depend on each other in a way that surprises people the first time they notice it: an EBS snapshot — the backup mechanism for a block volume — is stored durably behind the scenes in a way that leans on S3's durability model, even though you never interact with it as an S3 bucket yourself. The three services aren't really competitors; they're layers that hand off to each other depending on what the data needs to do at that moment.

What to do if you picked wrong

Nobody gets this right every time on the first try, and the good news is none of the three mistakes above require starting over from scratch. Here's the honest, cheapest-first order of operations for each direction.

1. Data on EBS that should really be shared across servers: copy the files off the volume and onto a new EFS file system (a straightforward file copy works, since EFS mounts and behaves like a normal Linux file system), then repoint every server that needs it at the EFS mount instead of the old single-server volume.
2. Files on S3 that a database actually needs to edit in place: download the object once onto an EBS volume attached to the instance that will run the database, and let the database own that file going forward — S3 was never going to support the in-place edits the database needs, no matter how the data got there.
3. A single-server workload on EFS that's paying a latency tax it doesn't need: if truly nothing else ever needs to touch that data, moving it back to a plain EBS volume on the one server that uses it removes the network hop and the sharing overhead you're not benefiting from.

In every direction, the migration itself is usually a straightforward copy operation — the hard part was never moving the bytes, it was noticing the mismatch in the first place. That's exactly what this post is for.

Moving data at scale without hand-copying files

Once you're moving more than a handful of files, doing it by hand stops making sense, and each service has its own native way to automate that work without writing custom scripts from scratch. For S3, the AWS Command Line Interface gives you commands like aws s3 cp for a single file and aws s3 sync for an entire folder, which only copies files that changed since the last run instead of re-uploading everything, and both commands automatically switch over to the multipart upload mechanism once a file crosses the size threshold where a single PUT request would fail. For EBS, the automation angle is less about moving files and more about protecting them: Amazon Data Lifecycle Manager lets you set a policy that takes EBS snapshots on a schedule and deletes old ones automatically, so backups happen whether or not anyone remembers to run them by hand.

For EFS, and for moving large amounts of data between on-premises storage and AWS in general, AWS DataSync is the purpose-built option. It connects to on-premises NFS shares, SMB shares, or self-managed object storage through a deployed software agent, copies the data to Amazon S3, Amazon EFS, or Amazon FSx for Windows File Server, and handles scheduling, encryption, and data-integrity validation on its own — AWS describes it as capable of speeds up to ten times faster than typical open-source copy tools, in part because it uses a purpose-built network protocol rather than a generic file-copy utility. DataSync also works between two AWS storage services directly, not just to and from on-premises systems, which makes it a reasonable option even for a large, one-time EBS-to-EFS or S3-to-EFS migration if you'd rather not script it yourself.

The practical takeaway: don't reach for a random third-party sync utility as your first move. Between the CLI's built-in sync commands, Data Lifecycle Manager for snapshots, and DataSync for larger or hybrid transfers, AWS has already built a native automation path for the three most common "move data on a schedule" problems, and starting there avoids a whole category of home-grown scripts that quietly break the first time someone changes a folder structure.

Windows, containers, serverless, and hybrid setups

Windows EC2 instances can use EBS exactly like Linux instances can, but they cannot mount EFS at all — EFS's file-sharing model is built around NFS, which isn't a first-class citizen in Windows the way it is in Linux and macOS. Windows-based shared-storage needs on AWS are typically solved with a different service (Amazon FSx, which comes in flavors built for Windows file servers and other specific file systems) rather than EFS — worth knowing so you don't spend an afternoon troubleshooting a mount command that was never going to work on that operating system.

Container and serverless platforms change the picture slightly. Amazon EFS integrates directly with Amazon ECS, Amazon EKS, AWS Fargate, and AWS Lambda, letting containers and functions that come and go constantly still share persistent, stateful storage — something a per-instance EBS volume can't offer, since a container doesn't have a fixed, permanent "instance" to attach a block volume to in the same way. If your workload is moving toward containers or serverless and needs to keep data between runs, that's a strong signal toward EFS (for shared files) or S3 (for objects), and away from EBS.

For hybrid setups — on-premises servers that also need access to AWS storage — EFS supports mounting from on-premises servers over a network connection back to AWS, and S3 is reachable from anywhere with internet access and the right credentials, so both extend naturally outside AWS's own data centers. EBS does not extend on-premises at all; it's fundamentally tied to an EC2 instance running inside AWS.

The numbers worth double-checking before you build around them

Cloud storage limits move more often than people expect, and a good chunk of the confusion out there is simply old information that hasn't been corrected yet. Three worth flagging specifically: S3's single-object maximum jumped from 5 TB to 50 TB in December 2025 — if you're reading a comparison chart (including some still floating around) that says 5 TB, it predates that change. EBS's Provisioned IOPS io2 Block Express line supports up to 64 TiB per volume and is built for 99.999% durability, well above the 99.8%–99.9% range of the other EBS volume types — a meaningful gap if you're choosing a volume type for something mission-critical. And EFS Multi-Attach-style sharing across a large fleet has no fixed size ceiling you configure yourself; it scales to petabytes automatically, which is worth remembering the first time you're tempted to "pre-plan capacity" for it the way you would with an EBS volume.

Frequently asked questions

What's the simplest way to remember the difference between object, block, and file storage?

Object storage (S3) is a warehouse you fetch complete, labeled boxes from over the internet. Block storage (EBS) is a private hard drive bolted onto one computer, editable byte by byte. File storage (EFS) is a shared filing cabinet several computers can open and edit at once. If you only remember one distinction, remember this: only block and file storage let you edit part of a file in place — object storage always replaces the whole thing.

Can I use S3 like a normal hard drive on my computer?

Not natively, but there are tools and gateway options that make an S3 bucket appear as a mounted drive or file system, including AWS's own S3 Files feature for certain compute services. Underneath, it's still object storage being translated to look file-like — full replace-the-object operations dressed up as file edits — which is why files stored in the cold Glacier storage classes throw an I/O error if you try to open them this way without restoring them first.

Can I run a database directly on S3?

No, not as the database's active storage. A database engine needs to seek to a specific point in a file and rewrite just that piece, repeatedly, at low latency — an operation object storage doesn't offer, since S3 can only replace an entire object at a time. Databases belong on EBS (single server) or, for certain managed database services, on storage those services provision behind the scenes; S3 is the right place for the database's backups, not its live data files.

Why can't I attach one EBS volume to two EC2 instances at once?

By default, an EBS volume is designed to be attached to a single instance at a time, which is exactly what makes it fast and predictable for that one instance's use — there's no coordination overhead from other servers competing for the same disk. If you genuinely need shared access, EFS is built for that job; EBS Multi-Attach is a narrow, specialized exception, not a general substitute for EFS.

Is EBS Multi-Attach the same as sharing a drive between computers?

Not quite. Multi-Attach lets up to 16 Nitro-based EC2 instances in the same Availability Zone attach to a single Provisioned IOPS (io1 or io2) volume with full read and write access, but AWS's own guidance says you still need a clustered file system on top to keep the data consistent — an ordinary file system like XFS or EXT4 isn't built to be safely written by multiple servers at once. For everyday shared-folder needs, EFS handles that coordination for you; Multi-Attach is aimed at specialized applications engineered to manage it themselves.

What's the actual maximum size of a single S3 object?

50 TB, as of a change AWS announced on December 2, 2025 — up from the previous 5 TB limit. Separately, the largest object you can upload in a single PUT request (without using multipart upload) is still 5 GB; anything bigger needs the multipart upload feature, which breaks the upload into parts and reassembles them on S3's side.

What's the maximum size of an EBS volume?

It depends on the volume type. The Provisioned IOPS io2 Block Express volumes support up to 64 TiB. Other current volume types have their own, generally smaller, maximum sizes, and Outposts (AWS hardware deployed in your own data center) has its own separate limits — for example, gp3 volumes on Outposts support sizes up to 16 TiB. If you need more space than a single volume's cap, most operating systems let you combine multiple volumes, though that adds its own complexity worth weighing against just choosing a larger-capacity volume type.

How big can an EFS file system get?

There's no fixed cap you configure — EFS grows and shrinks automatically as you add and remove files, and AWS describes it as designed to scale to petabytes on demand without disrupting the applications using it. You're not choosing a size up front the way you do with an EBS volume; you're simply billed for what's actually stored.

Which one is cheapest?

For pure storage cost per gigabyte, S3 is generally the cheapest of the three, which is part of why it's the default for backups, media, and archives. EBS charges for the capacity you provision whether or not you use it all, and can add IOPS charges on top for Provisioned IOPS volume types. EFS charges for what you actually store plus a throughput charge that varies by mode. The real comparison, though, is which service can do the job at all — cost only matters among the options that actually work.

Can EFS be used with Windows instances?

No. EFS is built around the NFS protocol and is supported for Amazon EC2 Linux and Mac instances; Windows EC2 instances aren't supported as EFS clients. Windows-based shared file storage on AWS typically points instead toward Amazon FSx, which offers file systems built specifically for Windows environments.

Does EBS survive if I terminate my EC2 instance?

It depends on the "delete on termination" setting for that volume. By default, the root volume (the one with the operating system) is set to delete when its instance terminates, while additional non-root volumes are generally left behind unless configured otherwise. Always check this setting explicitly on any volume holding data you can't afford to lose, rather than assuming either behavior.

What happens to my data if I delete an S3 bucket?

An S3 bucket generally must be empty before it can be deleted through normal means, and once objects are genuinely deleted (and, if versioning is on, all their versions are removed), that data is gone — S3 doesn't keep a hidden backup of deleted objects unless you'd explicitly configured S3 Versioning or replicated the data elsewhere beforehand. Treat bucket and object deletion as permanent unless you know for certain versioning or a backup was in place.

Can I mount S3 like a folder?

You can make it look that way using certain tools or AWS's own S3 Files feature for supported compute services, which surfaces S3 objects as files with normal file permissions. But it's still object storage underneath — every "edit" is really a full object replacement, and objects sitting in Glacier's asynchronous tiers won't open through that view until you restore them first.

What is FSx and how is it different from EFS?

Amazon FSx is a family of fully managed file system services built on top of specific, established file system technologies — including a version built specifically for Windows file servers, which is the natural alternative when you need Windows-compatible shared file storage that EFS can't provide. Where EFS is AWS's own elastic NFS file system aimed mainly at Linux and Mac workloads, FSx lets you choose a file system technology matched to a specific need, including Windows compatibility, at the cost of being a different product with its own setup and pricing to learn.

Which one should I use for a WordPress site with multiple servers?

The database (MySQL or MariaDB) belongs on EBS, attached to whichever server runs it — that's the in-place-edit workload EBS is built for. The WordPress uploads folder, which every web server behind a load balancer needs to see identically the moment any one of them adds a file, belongs on EFS. Media files you're comfortable serving through a content delivery layer, rather than directly off a web server's local disk, can live on S3 instead, which is a common way larger WordPress sites cut hosting costs and improve delivery speed.

Can I switch from one storage type to another later?

Yes, and it's usually a straightforward copy operation rather than a rebuild. Moving data between EBS, EFS, and S3 as needs change is common, including with AWS's own native tools like the S3 CLI's sync command or AWS DataSync for larger transfers; the harder part is almost always noticing you picked the wrong one in the first place, not the technical work of moving the bytes once you have.

Revision note. Written September 2026, covering Amazon S3, Amazon EBS, and Amazon EFS as documented by AWS at this time. AWS updates storage limits, volume types, and pricing regularly, so it's worth a quick check of the current AWS documentation before locking in an architecture decision around any specific number here. If you've been going back and forth trying to figure out which one your project actually needs, that back-and-forth is normal — this is genuinely one of the more confusing corners of AWS until it clicks, and it does click. See you on next post