Skip to main content

Storage

Cloud providers offer three primary storage abstractions: object storage, block storage, and network file storage. Because each model exposes a fundamentally different interface, consistency model, and performance profile, choosing the appropriate storage architecture is one of the most critical decisions for application performance and infrastructure cost.

Selecting the right storage tier requires evaluating how application software interacts with data: whether systems need low-latency random access to raw disk sectors, shared concurrent filesystem mounts across multiple servers, or distributed, web-native file retrieval over HTTP.

Object storage​

manages unstructured data as distinct files—called objects—within a flat, non-hierarchical namespace called a . Rather than relying on traditional POSIX directory trees, each object is assigned a unique alphanumeric key that can mimic a file path (such as media/2026/report.pdf). Objects are read, written, and deleted in their entirety through standard RESTful HTTP/HTTPS requests.

Because object storage decouples data persistence from running compute instances, storage capacity scales virtually without limits. Providers split data across multiple independent storage nodes and availability zones using advanced erasure coding, achieving eleven nines (99.999999999%) of annual durability by default. Object storage is the most cost-effective storage tier per gigabyte, making it the ideal home for user-uploaded media, application log archives, database backups, analytics data lakes, and static website hosting.

The defining architectural constraint of object storage is immutability: objects cannot be modified in place. Updating a single byte requires overwriting and uploading the entire object. Consequently, object storage cannot host active database transaction logs or random-access filesystems, though it serves as the ultimate destination for point-in-time database backups.

Block storage​

exposes raw, unformatted storage volumes across a dedicated storage network to a single virtual machine instance. To the guest operating system, a block volume behaves indistinguishably from a physical hard drive or solid-state disk: the kernel formats the volume with a native filesystem (such as ext4, XFS, or NTFS) and performs granular, sector-level reads and writes.

Because block storage delivers predictable, single-digit millisecond latency and high provisioned IOPS, it provides the storage foundation for operating system boot drives and relational or NoSQL database clusters. Unlike object stores, block volumes are provisioned for a fixed capacity and performance tier, accruing charges for the entire reserved size regardless of how much data is written.

Block volumes are inherently zonal: a volume resides in one specific availability zone and can only attach to instances within that same zone. Long-term durability and disaster recovery rely on —point-in-time, incremental block-level copies that the provider automatically captures and stores in multi-zone object storage.

In addition to network-attached block volumes, many virtual machine types offer ephemeral local NVMe drives. While these local disks maximize read/write throughput and minimize latency by bypassing the storage network, their data is lost when an instance stops or undergoes hardware maintenance. Ephemeral disks are ideal for buffer pools, compilation caches, and scratch files, but should never store non-replicated primary state.

File storage​

provides managed network filesystems that hundreds of compute instances and container pods can mount simultaneously over standard protocols like NFS or SMB. This model preserves familiar POSIX directory hierarchies, file permissions, and file-locking mechanics across distributed fleets.

Network file storage is indispensable for applications requiring concurrent filesystem access: enterprise content management systems, shared application code repositories, and legacy monoliths designed around shared network directories. However, managed file storage carries a significant cost premium per gigabyte compared to object storage and exhibits higher latency on small-file operations than direct block volumes. For modern greenfield applications, designing components to communicate directly with object storage via signed HTTP links is generally preferable to maintaining shared network filesystems.

CharacteristicObject StorageBlock StorageNetwork File Storage
Interface protocolRESTful HTTP/HTTPS API (GET, PUT, DELETE)Block-level storage protocol (NVMe, iSCSI)Network filesystem protocol (NFSv4, SMB)
Attachment modelDetached; globally accessible via network APIAttached to a single virtual machine instanceMounted concurrently by multiple instances
In-place byte modificationNo; modifications require full object overwriteYes; granular random read and write access to sectorsYes; file-level random byte manipulation and POSIX locks
Default fault toleranceMulti-zone redundancy (typically 99.999999999% durability)Zonal; protected against single hardware failureTier-dependent (zonal or regional replication)
Primary workloadsUnstructured media, database backups, logs, static web assetsOperating system boot drives, relational database storageContent management systems, shared directories, legacy applications

Tiers and lifecycle​

Object storage providers offer multiple storage classes tailored to data access frequency. Hot storage tiers charge standard rates for data retention while providing low-latency retrieval at minimal per-request cost. In contrast, cool and archive tiers drastically reduce monthly per-gigabyte storage rates while imposing higher access fees, minimum retention periods, and potential retrieval delays ranging from minutes to hours.

To prevent unconstrained data growth, organizations implement automated configurations. A lifecycle policy transitions objects between storage tiers based on age or access patterns—for example, moving application logs to an infrequent-access tier after 30 days, shifting them to an immutable archive tier after 90 days, and permanently expiring them after one year. Without lifecycle policies, storage accounts steadily expand over time, accumulating significant unnecessary costs for unread historical data.

Access​

Storage buckets are private by default across all major cloud platforms; exposing data publicly requires an explicit administrative override. Misconfigured bucket policies remain one of the most frequent vectors for accidental data exposure in cloud environments.

Sharing an object with someone outside

Preserve private bucket permissions by generating temporary presigned URLs for external access.

  1. Maintain default private access controls and enable public access blocking on the object bucket.
  2. Generate a cryptographically signed URL with a short, specific expiration time for the requested object.
  3. Transmit the presigned URL directly to the authorized recipient or client application.
  4. Allow the signed URL to expire naturally without loosening underlying bucket policies.

Presigned URLs contain cryptographic signatures derived from your IAM credentials, allowing client browsers or third-party services to perform secure, direct uploads or downloads against private buckets without routing data through intermediary application servers.

Terms introduced​

  • Object storage: files stored whole in a flat namespace and read over HTTP, with no machine attached.
  • Bucket: the container that holds objects and carries the access rules.
  • Snapshot: a point-in-time copy of a block volume, stored in object storage.
  • File storage: a shared filesystem many machines mount at once.
  • Lifecycle rule: a schedule that moves objects to a colder tier or deletes them by age.

How providers do it

Core storage primitives—object storage, block storage, and network file systems—operate under similar design patterns across the major clouds. However, providers diverge in resource hierarchy models, access control scoping, and automated tiering mechanisms.

ConceptAWSAzureGoogle Cloud
Object storageAmazon S3Azure Blob StorageGoogle Cloud Storage
Object containerBucketContainer (inside a Storage Account)Bucket
Persistent block storageElastic Block Store (EBS)Azure Managed DisksPersistent Disk, Hyperdisk
Ephemeral local diskEC2 Instance StoreTemporary DiskLocal SSD
Managed network file storageAmazon EFS; Amazon FSxAzure FilesGoogle Cloud Filestore
Archival cold tiersStandard-IA, Glacier Flexible/Deep ArchiveCool, Cold, Archive access tiersNearline, Coldline, Archive storage classes
Automated access-pattern tieringS3 Intelligent-TieringLifecycle management policies based on last-accessCloud Storage Autoclass
Automated lifecycle policiesS3 Lifecycle RulesAzure Blob Lifecycle ManagementObject Lifecycle Management
Time-limited signed URLsS3 Presigned URLShared Access Signature (SAS) tokenCloud Storage Signed URL
Persistent disk snapshotAmazon EBS snapshotAzure Disk snapshotPersistent Disk snapshot
Global public access blockingS3 Block Public AccessDisable anonymous access on Storage AccountPublic Access Prevention

Every product name and technical mapping above is confirmed against provider documentation. Specific data retrieval fees and minimum retention durations are detailed in the provider tabs below.

A vital governance distinction exists in Azure's storage hierarchy:

  • In AWS S3 and Google Cloud Storage, buckets are top-level resources where access controls, public blocking policies, and replication settings are configured independently per bucket.
  • In Azure Blob Storage, blobs reside inside containers, which reside inside an Azure Storage Account. Critical security and infrastructure configurations—including geographic redundancy and public anonymous access restrictions—are enforced at the parent storage account level. Hosting multiple disparate workloads in a single storage account forces all containers to share the same security posture.

What this maps to: Amazon S3 for object storage. EBS for block storage and Amazon EFS for file storage. S3 is the oldest AWS service, and most of the others read from it or write to it.

ConceptOn AWSStatus
Object storageS3. Bucket names are globally unique across all accountsconfirmed
TiersS3 Standard, Standard-IA (infrequent access), Glacier Instant Retrieval, Glacier Flexible Retrieval, Glacier Deep Archive. Intelligent-Tiering moves objects between tiers by access pattern for a monitoring feeconfirmed
Lifecycle ruleS3 Lifecycle configuration on the bucket, by prefix or tagconfirmed
Signed linkA presigned URL, valid for a period you set when signingconfirmed
Keeping buckets privateS3 Block Public Access, on by default for new buckets and settable at the account levelconfirmed
Block storageEBS volumes, one instance, one AZconfirmed
SnapshotEBS snapshot, stored in S3, incremental after the firstconfirmed
File storageEFS, mounted by NFS from many instances across AZs. FSx for Windows, Lustre, NetApp ONTAP, and OpenZFS filesystemsconfirmed
DurabilityS3 stores objects across at least three AZs in the region by default, except the One Zone classesconfirmed

Their vocabulary

Standard termTheir term
Object keyKey
Colder tierStorage class
Signed linkPresigned URL

Where to look

S3 Storage Lens reports size and cost by bucket and class. To check whether Block Public Access is on, open the bucket's Permissions tab.

Last verified: never.

Check your understanding

0 of 4 answered

  1. Which kind of storage needs no machine running for the data to exist and be readable?
  2. What does a lifecycle rule on a bucket do?
  3. Why is object storage the wrong place for a database's live files and the right place for its backups?
  4. A customer needs to download one report from a private bucket. What is the right way to give it to them?