What is cloud storage?

Storage categories are distinguished by how they are addressed and shared:

• Block - volumes attached to a compute instance, read and written like a local disk.
• File - hierarchical and shared, so several machines can mount the same tree.
• Object - buckets addressed over HTTP, with versioning and lifecycle rules, suited to backups, media and unstructured data.
• Archival tiers - slower storage for data that is rarely read but must be retained.
• Transient space - scratch attached to a workload and expected to disappear with it.

Choosing between them is a question about access patterns rather than about quality: transactional state wants block, shared working sets want file, bulk objects want object storage, and a wrong choice shows up as either wasted money or a rewrite later. The decision is usually made once and early, because moving data between shapes is a migration rather than a setting - attached volumes behave like disks, a shared file tree suits groups that must read one directory at once, and object storage asks callers to speak HTTP while versioning whatever they write.

Placement matters as much as the shape. Data held in one region costs more to reach from another, and an application that reads across regions discovers that fact in latency well before it appears on a bill - which is why region is treated as part of an application's design rather than as a dropdown during setup.

Providers replicate data across drives and failure domains and publish what their designs are intended to survive. Two separate questions hide behind the word safe: whether the system keeps the data when hardware fails, which is durability, and whether you can still reach it, which is availability.

Neither question covers accidental deletion, a leaked credential or a corrupt write, because redundancy does not protect against the data being overwritten or removed deliberately. Versions, retention rules and a copy outside the account remain decisions the tenant makes - and they are worth making before the first workload lands.

Cost follows a similar pattern. Storage that is inexpensive to keep is rarely the fastest to read, so a retention rule written for compliance can become a fetch problem for whatever has to pull from it later. Reading the tiering terms next to the durability statement is dull work, and it is where the unpleasant surprises usually live.

Storage is bought alongside infrastructure, and the two are usually evaluated together: the volume has to be attachable, in the right region, at a rate that fits the workload. Transfer is the third leg - moving data out costs money in most arrangements, which is why data gravity is a real constraint on architecture rather than a figure of speech.

The same reasoning applies when the wider category is in view. Cloud computing as a whole is evaluated on how its parts compose, and storage is the part that is hardest to move once placed.

On VirtEngine, storage reaches the market as a listing with its terms on the surface: capacity class, region, access characteristics and retention policy, published by the provider rather than quoted privately. The tenant funds an escrow account when ordering that capacity, so the provider sees committed budget before reserving space for it.

What is stored is then measured over time and reported as signed usage records; the tenant can dispute a reading before it becomes a payment. Validated line items draw down escrow after the dispute window, and balance left at the end of the lease returns to the tenant. The category index is storage listings on the market.