Block storage exposes a sequence of addressable blocks rather than a collection of named files or objects. An operating system sees a block device, such as a virtual disk, and can partition it, create a filesystem, and mount it for applications. Some applications, including certain databases, can also access block devices directly. The storage service manages the underlying capacity, while the operating system or application manages how data is organized within the device.
This model differs from file storage, which exposes files and directories through a filesystem protocol, and object storage, which exposes objects through an API. A file saved on a block volume gets its filename, directory path, and permissions from the filesystem above the block layer. Block storage does not inherently provide a shared directory tree or an object API.
Cloud block storage commonly takes two forms: persistent volumes accessed over a network and local disks associated with a compute host. Persistent volumes can have a lifecycle independent of a virtual machine. Local storage typically provides temporary capacity whose contents depend on the continued availability and lifecycle of that host or instance. Neither the term block storage nor the underlying use of SSDs guarantees persistence.
On AWS, Amazon Elastic Block Store, or Amazon EBS, provides persistent block volumes for Amazon EC2 instances. An EBS volume is created in an Availability Zone and attaches to instances in that same zone. Its data survives an instance stop and start, but termination behavior depends on the volume's delete-on-termination setting. Root EBS volumes are commonly configured for deletion when the instance terminates, so engineers must check configuration rather than assume every EBS volume is retained.
Amazon EC2 instance store provides block storage on disks physically attached to the host running the instance. It is useful for caches, scratch data, and intermediate processing results that can be recreated. Data generally survives a reboot, but it is lost when an instance is stopped, hibernated, or terminated, or when the underlying disk fails. Important data must therefore be stored or replicated elsewhere.
Performance depends on latency, input/output operations per second, throughput, request size, and workload access patterns. A transactional database may need fast random reads and writes, while a batch job scanning large datasets may prioritize throughput. Volume limits, instance limits, and network capacity can all constrain performance. Provisioning more capacity does not universally increase speed, and unused provisioned capacity can still incur charges.
Block volumes are generally used by one host at a time. Some services support attachment to multiple hosts, but safe concurrent writes require a compatible clustered filesystem or application-level coordination. Simply mounting the same ordinary filesystem on several machines can corrupt data. Applications needing a shared file hierarchy may be better served by managed file storage.
Persistence is also not a substitute for backup. Accidental deletion, filesystem corruption, and application errors can affect a persistent volume. Use snapshots or backups, coordinate them with application writes when consistency matters, and test restoration. For exam questions, distinguish persistent disk requirements from disposable local storage requirements: a database volume and a rebuildable processing cache usually need different lifecycle guarantees.