CCSP Cloud Data Storage Architectures: Storage Types and Their Threats

CCSP sub-domain 2.2 names five storage types, and each is defined by how data is addressed and how long it lives. Knowing those two properties lets you place any workload and predict its main threat.

Volume, ephemeral and raw storage are block devices: software sees a disk and updates it in place. Object and archive storage are reached through an API and stored whole. That split decides most selection questions, because a database engine needs a block device and a fleet of web servers needs a shared store that none of them owns.

Volume storage is a virtual disk that the provider attaches to an instance; the guest operating system partitions and formats it, and the data survives when the instance is stopped or replaced, unless the volume is set to be deleted with the instance (some providers set this by default for boot volumes, so check it before relying on a volume outliving its instance). It is the right home for anything that needs low-latency, in-place updates and must persist, such as a self-managed database.

Three properties matter for security and recovery:

• A volume usually lives in one zone. A standard (zonal) volume can be attached only to instances in that zone and is unavailable if the zone fails; some providers also offer zone-redundant or regional disks that replicate synchronously across zones, at a higher price. For a zonal volume, recovery means creating a new volume from a snapshot, which the provider keeps in storage that survives the loss of a zone.
• A snapshot is a point-in-time copy of the whole volume. Providers often store snapshots incrementally (only changed blocks since the last one) to save space, but every snapshot restores to the full volume. Snapshot frequency sets the recovery point objective (RPO): hourly snapshots can meet a one-hour RPO, daily ones cannot.
• A snapshot of a running system is crash-consistent. It copies the blocks on disk at that instant, not what the application still holds in memory. A restored database therefore behaves as if the power had been cut: it runs crash recovery and the last uncommitted or unflushed writes are gone. For an application-consistent copy, flush and briefly freeze writes, or use the engine's own backup tooling, before the snapshot.

The recovery design follows from the objectives: the RPO sets how often snapshots run, and the recovery time objective (RTO) decides whether a restore is fast enough or whether data must already be replicated in a second zone, which costs more.

Object storage keeps each piece of data as a complete object, together with its metadata, in a flat namespace (a bucket or container) and addresses it by a unique key through an API. Nothing is mounted as a disk, which is why it suits millions of unstructured files that many clients fetch over HTTPS.

The trade-off is that objects are replaced whole: a change means writing a new object (or version), not editing a few bytes inside it. That makes object storage a poor fit for database files that a self-managed engine rewrites many times a second; those belong on a volume. The deciding factor is the access model: whole-object writes through an API, not block-level updates in place.

Object storage features that recur in this topic:

• Versioning keeps the previous version of an object whenever it is overwritten or deleted. In a versioned bucket, a simple delete does not remove the data: in Amazon S3 it adds a delete marker, and in Azure Blob Storage the current version becomes a previous version. Either way, earlier versions stay stored and retrievable until they are removed explicitly or a lifecycle rule expires them.
• Lifecycle rules move objects between tiers or expire them (and their old versions) on a schedule.
• Storage tiers (standard, infrequent access, archive) trade price per gigabyte against retrieval speed and charges.
• Access policies and signed links control who may read objects (see the exposure threats below).

Ephemeral storage is disk that belongs to the physical host running the instance. It is fast and comes with the instance, but by default its contents are discarded when the instance stops or is terminated, including when an autoscaling group scales in. Use it only for data that is disposable or can be regenerated: request-time temporary files, caches, intermediate batch files. Anything that must outlive the instance, such as user uploads, belongs in object or volume storage. Ephemeral disks also raise a residual-data concern: on a shared host, the customer cannot see how the provider wipes freed blocks. The general answer is encryption under a key the customer controls and that never leaves the instance: when the key is discarded, whatever remains on the host's disk is ciphertext. That relies on the customer's own control rather than on assurances about the provider's wiping process.

Raw storage means a SAN logical unit (LUN) presented directly to a virtual machine, called raw device mapping, instead of a virtual disk file that the hypervisor manages on a datastore. It is used for clustering and for software in the guest that must talk to the array, and in pass-through (physical) mode the guest addresses the device directly. Two consequences follow:

• Isolation moves to the storage fabric. Datastore permissions protect virtual disk files, which raw mapping does not use. What stops another server from reaching the LUN is correct SAN zoning (which hosts can see which array ports) and LUN masking on the array (which hosts are presented which devices). A mistake can present the whole device to the wrong host.
• In pass-through mode, hypervisor controls stop applying. Hypervisor snapshot-based VM backups and hypervisor-level VM disk encryption operate on virtual disks. A pass-through (physical-mode) LUN is outside both (a virtual-compatibility-mode mapping can still be snapshotted by the hypervisor), so backup and encryption must be applied where the data is actually handled: on the array (array snapshots, array or self-encrypting drive encryption) or inside the guest.

Long-term storage keeps data for years at the lowest price per gigabyte and high durability, in exchange for slower or costlier retrieval. Many archive tiers (for example S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive and Azure Archive, which must be rehydrated first) delay retrieval for hours; others, such as Google Cloud Storage Archive or S3 Glacier Instant Retrieval, return data at once but charge more per retrieval. It fits data that is rarely read, such as records an organisation must keep for the better part of a decade.

Two design constraints apply:

• Retrieval time must fit the RTO. If the chosen archive tier needs most of a working day to return data, an RTO measured in a couple of hours cannot be met however often backups run (frequency affects the RPO, not the RTO), and an instant-retrieval archive tier that meets the RTO still bills every retrieval. Tiering by age resolves the conflict: the copies most likely to be restored stay where retrieval is fast, and a lifecycle rule moves the rest to cheaper storage as they age.
• Archive tiers carry minimum storage durations. Data deleted before the minimum is still billed for the full period. Data that is kept only for weeks is usually cheaper in a non-archive tier with a lifecycle rule that deletes it on time, even when it is rarely read, because an early delete from an archive tier still pays for the whole minimum. This trap holds for every archive class, including the instant-retrieval ones.

The CCSP body of knowledge describes storage differently in each service model, and the customer's storage controls shrink as the model moves up the stack.

Two consequences follow. First, controls tied to the infrastructure do not survive a move up the stack. Anything the customer installed in a guest operating system or attached to its own disks has nowhere to run once the provider operates the compute and storage underneath, because the customer can no longer reach them. The equivalent control in PaaS is a setting the service itself exposes; for key control, that is the service's customer-managed key option for encryption at rest. Second, in SaaS the customer still owns the data and its access decisions. For SaaS content storage, an anonymous link carries no identity, however it is protected or monitored, so if each access must be attributed to a person, external sharing has to require the recipient to authenticate as a named user the organisation has allowed in.

Pick storage from two questions: does the data need to outlive the compute that writes it, and how is it accessed (in-place block updates, whole objects over an API, or rare reads from an archive tier)?

• Disposable or regenerable, needs fast local access at low cost: ephemeral.
• Persistent, updated in place by one instance (a database engine, a boot disk): volume.
• Persistent, shared across a changing fleet or served over HTTPS (uploads, images, media, backups): object.
• Kept for years, rarely read, retrieval can wait: long-term (archive).
• Software in the guest must address the array device itself: raw.

Real architectures combine several of these. A batch analytics cluster, for example, might stage intermediate shuffle files on local scratch disk (ephemeral, because a rerun regenerates them), read its input datasets from and write finished reports to a bucket (object, because nodes come and go), keep a metadata catalogue on a persistent disk (volume) and move each year's raw inputs into an archive tier once they are no longer queried. Test each mapping against the two questions: anything that must outlive a node cannot sit on its local disk, and anything read on demand cannot wait on a slow archive retrieval.

The most common storage threat in cloud is not a broken disk but data reached through a legitimate access path that was opened too widely. The CCSP body of knowledge lists threats to storage including unauthorised access and use, unauthorised provisioning (storage created outside approved processes, the shadow-IT bucket nobody secures or tracks), data leakage, liability from regulatory non-compliance, jurisdictional issues (copies stored where another country's law applies), denial of service, corruption, modification and destruction, theft or loss of media, malware and ransomware, and improper treatment at end of life. Three exposure paths recur:

• Permissive object policies. When many teams create buckets, the preventive control is an account-wide (or organisation-wide) public-access block that the platform enforces above every bucket policy. Detective and advisory controls find or discourage a bad policy after it exists; only a control enforced at the platform stops it from taking effect.
• Long-lived signed links. A signed (pre-signed) link is a bearer credential: anyone holding it gets the signer's access until it expires, including the signer's permission to decrypt server-side-encrypted objects. If accounts and network restrictions are not options, generate links on request with an expiry of minutes, not days.
• Snapshot and image sharing. A snapshot restores to the entire volume as it was at snapshot time: every file, log, credential and leftover block, not only the data someone meant to share. Sharing one with another account is an exfiltration path that bypasses alerts on data reads and network egress, because no data is read or sent out through the instance. A public-sharing block stops public snapshots but not sharing with one named account; preventing that needs an organisation policy that denies sharing outside the organisation.

Destruction and ransomware with privileged credentials. An attacker with stolen administrative credentials can delete or encrypt both the data and any backups the same credentials control. Versions, replica buckets in another region and snapshots kept in the same account all fall with that account. A recoverable copy must be immutable and held in a separate account or trust boundary with different administrators. Write-once retention usually comes in two modes:

If backups must survive compromise of the highest privileges, the fix is the mode (compliance), not a longer period.

Residual data (remanence). Data can survive what looks like deletion: blocks freed by one tenant could be readable by the next if the provider does not clear them before reallocation; a versioned bucket keeps earlier versions behind a delete marker; and a snapshot captures the volume's blocks, so files deleted before the snapshot can be recovered from it with forensic tools. So the safe source for any snapshot that leaves your control is a volume that only ever held the data you mean to hand over, never a trimmed-down copy of a disk that once held more. (Sanitisation methods and crypto-shredding are taught in the retention and deletion lesson, sub-domain 2.7.)

Data location. Every stored copy counts for data residency: geo-redundant replicas, backups, and the copies a content delivery network keeps in its edge caches. A residency review therefore lists every place the provider may write a copy, including replication targets, backup locations and edge caches, and confines each one: replication pairs kept inside the permitted jurisdiction, and CDN edge locations restricted to it (or regulated content excluded from caching).

Integrity and availability. Replication protects against the loss of a device, zone or region, but it faithfully copies every valid write, including corruption from a faulty release or a script that truncates or scrambles records. Recovering from a logical error needs a point-in-time copy from before the damage: object versioning (with a lifecycle rule that expires old versions to control cost) or snapshots taken often enough to meet the RPO and kept long enough to reach back before the corruption.

Provider-side transparent encryption at rest, with a key the provider manages, mainly protects against physical media being stolen, lost or disposed of without sanitisation: a drive taken from the data centre yields only ciphertext. It does not stop access through any valid path, because the storage layer decrypts automatically for every authorised request.

• Root on an instance reads an attached encrypted volume in plaintext, since the volume is decrypted for the instance it is attached to.
• A leaked application access key, a bucket made public by mistake, or a long-lived signed link all return decrypted data.
• Ransomware on an authorised instance can still encrypt or overwrite the data.

This is why encryption at rest is a baseline, not a substitute for access controls, sharing restrictions and immutable backups. Key management choices (customer-managed keys, HSMs, bring-your-own-key) and other data security technologies are covered in sub-domain 2.3.