Object Storage

Object storage organizes data into objects rather than disk blocks or a traditional file-system hierarchy. Each object contains the data itself, associated metadata, and a key that identifies it within a bucket or container. Applications typically upload, retrieve, list, and delete objects through HTTP-based APIs, software development kits, or command-line tools. The storage provider manages the underlying storage infrastructure.

Object keys can resemble file paths, such as images/products/item123.jpg, but separators generally represent key prefixes rather than actual directories. Some services offer hierarchical namespace options, so engineers should check the behavior of the selected service. Metadata can describe properties such as content type, while tags can support classification, access policies, or lifecycle management where supported.

Typical cloud uses include storing user uploads, distributing media, retaining backups, collecting logs, and building data lakes. For example, an application can store product images in object storage and keep their keys in a relational database. A content delivery network can cache those images close to users. An analytics platform can query structured files stored as objects without first loading every file into a database.

For foundational certification questions, distinguish object storage from block and file storage. Object storage is usually the appropriate choice for large collections of independently accessed files, backup archives, and static content. Block storage provides disk-like volumes for workloads such as operating systems and transactional databases. File storage provides shared file-system access, commonly through protocols such as NFS or SMB. An object-storage bucket is not inherently a mounted disk or a POSIX-compatible shared file system.

Objects are generally uploaded or replaced as units rather than modified through arbitrary in-place writes. Some services support specialized append or partial-write operations, but these are not portable assumptions. Applications requiring frequent small updates, file locking, or very low-latency random disk access usually need block storage, file storage, or a database instead. Object storage can hold database backups without being suitable as the database's live disk.

Storage classes allow engineers to trade access speed and retrieval flexibility for lower storage costs. Frequently accessed data belongs in an appropriate online class, while older backups may move to archival classes through lifecycle policies. Some archival classes require a restore operation before reading data. Calculate total cost using stored capacity, request volume, retrieval charges, minimum storage durations, and network transfer—not capacity pricing alone.

Durability, availability, and recoverability are separate concerns. Redundant storage protects against infrastructure failures, but it does not automatically protect against authorized deletion or application mistakes. Versioning, retention controls, replication, and tested recovery procedures address different risks. Access should normally remain private, with narrowly scoped permissions and encryption configured as required. Object storage does not mean public storage, and it does not imply eventual consistency: consistency guarantees depend on the service and operation. Static website assets are a common use, but object storage alone does not execute server-side application code.