Cloud storage comes in three shapes. Block storage is a raw disk for one machine, where operating systems and databases live. File storage is a shared drive that many machines mount at once. Object storage is an API you hand whole files to and get back by name, and it scales without any real limit. For the same 100 GB, object storage costs roughly a tenth of file storage. Default to object storage for app data, and reach for the other two only when you have a specific reason.
College pass-outs and brand-new IT hires who keep hearing the words bucket, volume, and mount and want them to finally click. No prior cloud background needed. If you have used a USB drive and a shared college folder, you already have the intuition.
Three words trip up almost every fresher in their first cloud week: object, block, and file storage. They sound like one idea said three ways. They are not, and picking the wrong one can mean paying ten times more than you needed to, or building something that quietly falls over the moment a second server needs the same data.
Here is the everyday version. Block storage is the hard drive bolted inside one computer. File storage is the shared network drive your college lab had, the one everyone mapped as the Z drive. Object storage is closer to a coat check at a big event: you hand over your coat, you get a numbered ticket, and you neither know nor care which hook it hangs on. You keep the ticket. When you want the coat back, you show the ticket and it appears. That ticket is the only thing that matters.
We will walk through all three, then spend most of our time on object storage, because it is the one you will touch most often and the one that behaves least like the storage you already know.
Block storage: the disk you already understand
Block storage is the closest thing to the drive inside your laptop. The provider hands you a blank volume, you attach it to a virtual machine, you format it with a filesystem, and from then on it behaves like a normal disk. On AWS this is EBS, on Azure it is Managed Disks, on Google Cloud it is Persistent Disk. The data is split into fixed-size chunks called blocks, and the system can read or write any single block on its own, which is what makes it fast for the small, random reads and writes a database does all day.
The catch that surprises freshers: a block volume usually attaches to exactly one machine at a time. You cannot casually share one volume across ten web servers. It is a private disk, not a shared folder. A common general-purpose volume, AWS gp3, costs about $0.08 per GB per month and includes a baseline of 3,000 IOPS and 125 MB/s of throughput before you pay extra for more speed.
What it is good at
Anything that needs a real filesystem and fast in-place edits. Your virtual machine boots from a block volume. Databases live on block volumes because they constantly rewrite small pieces of large files. If you can picture an application opening a file and changing byte number 4,000 without rewriting the whole thing, that application wants block storage.
You terminate an EC2 instance to stop paying, and next month the bill still shows a storage charge. The block volume that was attached did not die with the instance. If its delete-on-termination flag was off, or you had detached the volume earlier, it keeps sitting there at about $0.08 per GB per month doing nothing. A forgotten 500 GB volume is $40 every month for an empty disk. When you clean up, always look for unattached volumes, not just running machines.
File storage: the shared drive in the cloud
File storage is the cloud version of that Z drive. It keeps a familiar tree of folders and files, with names, timestamps, and permissions, and it can be mounted by many machines at the same time using the same protocols that office file servers have used for years (NFS and SMB). On AWS this is EFS, on Azure it is Azure Files, on Google Cloud it is Filestore. Ten web servers can all mount the same EFS share and read the same uploads folder.
That sharing is the whole point, and it is also why file storage is the priciest of the three. EFS Standard runs about $0.30 per GB per month, well over ten times the cost of object storage for the same gigabyte.
Here is where I disagree with a lot of beginner tutorials. They reach for file storage by default because a shared drive feels familiar and safe. I think that is usually the wrong instinct. Most cloud-native apps do not actually need a shared mounted filesystem, and you are paying a steep premium for a convenience you may not use. Treat file storage as the option you justify, not the one you assume. If you are lifting an old application that expects a mounted drive, file storage earns its place. If you are building something new, start with object storage and only move when you hit a genuine wall.
Object storage: the one you will use most
Object storage is the odd one out, and the one worth slowing down on. You do not attach it or mount it. You talk to it over an HTTP API. You create a container called a bucket, then you put objects into it. Each object is three things together: a key (its name), the data (the bytes themselves), and metadata (size, type, date, and any tags you add). To read it back, you ask for it by key. The big three are Amazon S3, Azure Blob Storage, and Google Cloud Storage. Standard storage sits around $0.023 per GB per month on S3 and Azure Hot, and $0.020 on Google Cloud Standard.
The key is the whole trick
When you open a bucket in the console you will see what look like folders. They are an illusion. A key such as photos/2026/cat.jpg is not a file sitting three folders deep. It is one long name that happens to contain slashes. There is no real folder to rename, no directory tree underneath. This flat design is exactly why object storage scales to billions of objects without slowing down: there is no folder structure to walk through. Once that clicks, a lot of confusing behaviour stops being confusing.
Why you cannot boot or run a database on it
Object storage treats each object as a single unit. You fetch the whole thing or you replace the whole thing. You do not edit byte 4,000 of a 2 GB object in place, the way a database needs to. That single design choice is why operating systems and databases stay on block storage and why object storage is perfect for files that are written once and read many times: photos, videos, backups, log archives, software builds, and the static files of a website.
When would you choose object storage over block storage?
A strong answer names the access pattern, not just the price. Say: object storage suits large, unstructured data that is written once and read many times and reached over an API, such as images, backups, and static website files, and it scales almost without limit. Block storage suits data that one machine needs to read and write quickly in place, such as an operating system disk or a database. Then land the point that shows real understanding: you cannot boot a machine from object storage or run a transactional database on it, because objects are replaced whole rather than edited in place. That last line is what separates someone who memorised a definition from someone who gets it.
| Question | Block | File | Object |
|---|---|---|---|
| How you reach it | Attach as a disk | Mount as a drive | API call by name |
| Shared by many machines | No, usually one | Yes | Yes |
| Edit part of a file | Yes | Yes | No, replace whole object |
| Scales to petabytes easily | No | Limited | Yes |
| Typical use | OS disk, database | Shared app files | Backups, media, static sites |
| Rough cost per 100 GB / month | about $8 (gp3) | about $30 (EFS) | about $2.30 (S3 Standard) |
What it actually costs
Numbers make the difference real. Take the same 100 GB of data and store it for one month in a US region, in each of the three models, at standard rates.
Object storage (S3 Standard): 100 x $0.023 = $2.30
Block storage (EBS gp3): 100 x $0.08 = $8.00
File storage (EFS Standard): 100 x $0.30 = $30.00
Same data, a thirteenfold gap between cheapest and dearest. This is why your default choice matters. One more thing freshers miss: object storage also charges tiny fees per request (a few cents per 10,000 reads or writes) and, more importantly, for data you transfer out of the cloud. That outbound transfer, called egress, is the single most common reason a storage bill comes in higher than the per-GB number suggested.
Storage tiers and the early-deletion trap
Object storage gets cheaper if you tell the provider you will not read the data often. These levels are called tiers. The hot or standard tier is for data used regularly. Cooler tiers cost less to store but more to read, and they get slower to retrieve as you go down. The coldest archive tiers store a gigabyte for a fraction of a cent, but reading the data back can take minutes to hours and costs noticeably more per request.
| Tier | Azure Blob | Google Cloud | Minimum stay |
|---|---|---|---|
| Hot / Standard | $0.023 | $0.020 | none |
| Cool / Nearline | $0.013 | $0.010 | 30 days |
| Cold / Coldline | $0.004 | $0.004 | 90 days |
| Archive | $0.0009 | $0.0012 | 180 to 365 days |
The trap hides in that last column. Cool and archive tiers have a minimum storage period. Put an object in a 90-day tier and delete it after 10 days, and you still pay for all 90. People move data to cold tiers to save money, churn through it quickly, and end up paying early-deletion fees that wipe out the saving. Tiers reward data you genuinely leave alone, not data you keep poking. Most providers can move objects between tiers automatically based on age, which is safer than guessing by hand.
On day one nobody will ask you to design a storage system. But you will be told to put backups in a bucket, attach a disk to a server, or figure out why last month cost more than expected. Knowing which of the three models you are looking at, and that a detached volume still bills and a cold object has a minimum stay, is exactly the kind of practical detail that makes a new hire trusted with real tasks early. It also keeps you from being the person who accidentally triples a bill.
On any provider free tier, create an object storage bucket (S3, Azure Blob, or Google Cloud Storage), then upload a small image from your laptop. Now try opening the object URL in a browser. On a fresh bucket you will almost certainly get a 403 Access Denied page, because new buckets block public access by default. That error does not mean your upload failed. It succeeded; the bucket is simply private, which is the safe default. To check your file is really there, view it from inside the console or generate a time-limited link (a presigned URL). Doing this once teaches you more about object storage permissions than any diagram, and it is a story you can tell in an interview.
FAQ
Is cloud object storage the same as Google Drive or Dropbox?
Not quite. Drive and Dropbox are finished consumer products for syncing files, and they are built on top of object storage underneath. Object storage like S3 is the raw building block you reach by API and use inside your own applications. Think ingredient versus finished dish.
What happens to my files if I stop paying?
They do not stay forever. Providers suspend the account, then after a grace period the data is deleted. If you are closing an account or a project, download or move anything you care about first. Nothing here is a long-term safe deposit box you can forget about.
Can I run a database on object storage?
Not as the live database. Databases need fast in-place edits, so they run on block storage. You can and should keep database backups and exports in object storage, and some analytics tools can query data files sitting in a bucket, but the running database itself stays on a block volume.
Why is my storage bill higher than the per-GB price suggested?
Three usual suspects: per-request charges, data transferred out of the cloud (egress), and early-deletion fees on cold tiers. Egress is the big one. Storing data is cheap; moving a lot of it out across the internet is where surprises live.
Which type is cheapest?
Per gigabyte, object storage wins clearly, and archive tiers go lower still. But cheapest to store is not cheapest overall. If you read the data constantly or pull a lot of it out, request and egress costs can change the picture. Match the tier to how often you actually touch the data.
The one thing to remember
If you keep only one rule from all this, keep this: object storage is your default for application data, block storage is for the disk a single machine needs, and file storage is for the rare case where many machines must share a real mounted filesystem. Get that reflex right and most cloud storage decisions answer themselves, including the expensive ones. The big providers split storage the same way, so the words you learned here carry across AWS, Azure, and Google Cloud with only the brand names changing.
Pick a provider free tier this week and make one bucket. Upload a file, hit the 403, fix it with a presigned link. That fifteen minutes will teach you more than re-reading any guide.
Want the virtualization side of the same story? The companion VMware for Beginners series covers how storage looks from inside a data center.
References
About The Author
DrJha