11.2.3: Block Storage

Block storage operates at a lower level of abstraction, providing raw storage volumes to host operating systems, which then manage a file system on top of these volumes. A block storage service presents virtual disk blocks of a fixed size (e.g., 512 bytes or 4KB blocks) to the cloud compute instance, and the instance’s OS treats it like a physical disk drive. The cloud provider manages mapping these virtual blocks to physical storage and typically replicates them for durability, but from the perspective of the VM or application, it’s just a disk. Amazon’s Elastic Block Store (EBS), Azure Managed Disks, and Google Persistent Disks are classic cloud block storage offerings. They are often used as the root or data volumes attached to VMs and databases.

Block storage splits files into fixed-size chunks (blocks) and stores them with unique addresses (usually logical block addresses). Because blocks are uniformly sized and without metadata (metadata is handled by the file system layer above), block storage allows very fast, fine-grained access – an application can read or write to an individual block (say, update just 4KB of a 10GB database file) with low latency. This makes block storage ideal for transactional workloads and databases, which frequently update small pieces of data. Another advantage is that block storage volumes can often be mounted exclusively to one host at a time (though some providers allow multi-attach in certain scenarios), ensuring low-level control and consistent high performance. This exclusivity simplifies consistency since only one machine writes to the volume at once, analogous to a direct-attached disk.

Benefits and limitations: Block storage offers high I/O throughput and low latency – for example, databases or applications requiring thousands of IOPS (I/O operations per second) use block storage to meet performance requirements. It’s also very reliable; cloud block storage services usually replicate data across multiple drives and sometimes across Availability Zones for fault tolerance (AWS EBS volumes in a region are replicated in that AZ). Unlike object storage, block volumes can be modified in place – writing new data to a block updates that block directly, without creating a whole new object version. This is crucial for systems like relational databases. However, block storage lacks rich metadata or built-in search capability; the file system or database using the block volume must manage metadata and indexing itself. Also, block storage is typically more expensive per GB and doesn’t scale out infinitely under a single namespace – each volume has a size limit, and while you can have many volumes, they are distinct units attached to specific servers. Scaling capacity may require provisioning larger volumes or adding more volumes and distributing data across them (e.g., striping).

Use cases: The primary use cases for block storage in the cloud are database storage, VM boot and data volumes, and any application requiring low-latency random read/write access. For example, cloud databases (SQL or NoSQL) often run on block storage to achieve the required performance. A MySQL instance on AWS might use an EBS Provisioned IOPS volume to ensure consistent throughput for transaction processing. Enterprise applications like ERP or CRM systems may use block storage for their underlying data stores to guarantee speed and integrity. Container platforms can also use block storage to provide persistent volumes (e.g., Kubernetes provisioning a PersistentVolume on EBS for a stateful app). In summary, whenever an application needs disk-like performance with strong consistency on writes, block storage is the go-to solution in the cloud.

---