Cloud Data Storage Architectures
Storage types map to the service model
A question gives you a leaked backup, a public bucket, or a database breach and asks for the control. The fastest path to the right answer is to place the storage in its service model first, because the model decides what storage primitives exist and who secures them. CCSP organizes cloud storage into three tiers that follow IaaS, PaaS, and SaaS[1], and each tier exposes different storage types.
What each model exposes
- IaaS gives you raw storage building blocks. Volume storage behaves like a disk attached to a virtual machine, and object storage holds whole objects you reach by API over the network. IaaS also surfaces the lower-level forms the exam names directly: raw (direct device or LUN access) and ephemeral (instance-local disk that lives only as long as the VM).
- PaaS gives you managed data services instead of disks. The exam splits these into structured storage (managed relational and NoSQL databases, which enforce a schema) and unstructured storage (the managed blob or bucket area the platform hands your application). You configure the data and its access; the provider runs the engine, patching, and replication.
- SaaS gives you no storage primitives at all. You get content storage and information storage inside the application (the documents, records, and fields the app stores for you) plus ephemeral storage in the user's browser or device. You cannot mount a volume or set a bucket policy; your controls are classification, sharing settings, and identity.
Why the model decides the control
The service model is also the responsibility line. In IaaS you own encryption of the volume and the object, the access policy on the bucket, and sanitization of a deleted disk. In PaaS the provider secures the storage engine, but you still own the keys, the classification, and who can read the data. In SaaS the provider owns nearly all of the storage stack, so a storage problem you can act on is almost always a sharing or identity problem, not a disk problem. This is why "what storage type, in which model?" is the first question to answer: it tells you which control even exists for you to apply.
IaaS storage: volume, object, raw, ephemeral
IaaS is where the exam tests storage primitives in detail, because you, not the provider, configure them. Four types matter, and they share one mental model: each is a way to hold bytes, and they differ in how the bytes are addressed and how long they live.
Volume (block) storage
Volume storage presents a fixed-size block device that attaches to one virtual machine and is formatted with a filesystem, exactly like a physical disk. It is the home for boot drives, filesystems, and self-managed databases that need low-latency random read-write. Vendor examples are Amazon EBS[2], Azure managed disks, and Google Cloud persistent disks. You secure it with full-disk encryption at rest, you back it up with snapshots (point-in-time copies), and you must remember that a snapshot is a full copy of the data with its own access controls. A volume is normally attached to a single instance at a time, so its blast radius is that instance, but a detached or deleted volume can leave data remanence: recoverable blocks until the space is overwritten or cryptographically erased.
Object storage
Object storage keeps each file as a self-contained object (the data plus metadata plus a unique key) in a flat namespace, reached by an HTTP API rather than mounted as a disk. It scales effectively without limit and is the natural home for backups, static assets, logs, and data lakes. Vendor examples are Amazon S3[3], Azure Blob Storage, and Google Cloud Storage. Because it is addressable over the internet, its defining risk is the misconfigured access policy: a bucket left readable to anyone is the most common cause of cloud data exposure. Object storage is encrypted at rest with provider-managed or customer-managed keys, and because objects are immutable you change one by writing a new version, not editing in place.
Raw and ephemeral
Raw storage is direct access to the underlying device or LUN (logical unit number) with no filesystem layer the cloud manages for you; it gives the most control and the most responsibility, and it exposes the disk at the lowest level. Ephemeral storage is instance-local disk, RAM, and cache that exists only while the VM runs; AWS calls it an instance store, and it is wiped when the instance stops, terminates, or migrates to new hardware. Ephemeral storage is fast and free of network latency, which makes it ideal for caches, scratch space, and temporary files, but it must never hold the only copy of data you need to keep. The single most testable contrast in this section: a volume persists independently of the instance; ephemeral storage does not.
PaaS and SaaS storage: structured, unstructured, content
Higher up the stack the provider runs the storage engine, so the exam shifts from disk mechanics to data shape and shared responsibility. The rule to carry up: as you move IaaS to PaaS to SaaS, you stop managing storage primitives and start managing only the data and its access.
PaaS: structured and unstructured
PaaS storage splits by whether the data has a schema.
- Structured storage is a managed database that enforces a defined schema and answers queries: managed relational engines (Amazon RDS, Azure SQL Database, Cloud SQL) and managed NoSQL stores (Amazon DynamoDB, Azure Cosmos DB). The provider patches and replicates the engine; you own the schema, the data classification, the encryption keys, and the credentials. Structured data is the easiest to discover and label because its shape is known in advance.
- Unstructured storage is the managed blob or bucket area the platform gives your application for files that have no schema: images, documents, logs, and media. It is the PaaS-managed cousin of IaaS object storage. Because the content is opaque, you cannot assume its sensitivity; it has to be scanned and classified after it lands, which is why data discovery is harder here than for structured stores.
Many real datasets are semi-structured: they have tags or markers (JSON, XML) but no rigid table schema, and they sit between the two for discovery and classification purposes.
SaaS: content and information storage
In SaaS the provider stores your data inside the application as content storage (the files and objects users upload and share) and information storage (the structured records and fields the app maintains, often in a database you never see). You have no volume to encrypt and no bucket policy to set, so your storage controls collapse to three levers: classify what goes in, control sharing and access through the app's own permissions and an identity layer, and watch for shadow data, copies and exports that leave the platform's visibility. The defining SaaS storage risk is therefore over-sharing and unseen copies, not a misconfigured disk, because the disk is the provider's.
Threats per storage type and exam patterns
The blueprint pairs storage types with threats, so the highest-value skill is naming the signature threat for each type and the control that answers it. Threats are testable per type, not in the abstract.
The threat-to-control map
- Object storage: misconfigured access policy. A public-readable bucket is the classic cloud breach. The control is least-privilege access policy, blocking public access at the account level, and encryption at rest. The trap is reaching for network controls; the exposure is an identity and policy failure, not a firewall gap.
- Block/volume storage: data remanence. Deleted volumes and old snapshots can leave recoverable data. The control is cryptographic erasure (destroying the key so the ciphertext is unrecoverable, per NIST SP 800-88 media sanitization[4]) plus snapshot access control. In a multi-tenant cloud you cannot physically shred a shared disk, so crypto-shredding is the cloud-correct answer.
- Structured storage (databases): injection and over-broad credentials. SQL/NoSQL injection and credentials that grant more than the app needs are the database threats. The controls are parameterized queries, least-privilege database accounts, encryption in transit, and secrets management for credentials.
- Unstructured/object uploads: unscanned, unclassified data. Files arrive without known sensitivity. The control is post-ingest data discovery and classification, plus malware scanning, before the data is trusted.
- Ephemeral storage: silent data loss and leftover secrets. Treating instance-local storage as durable loses data on stop; leaving secrets in it risks exposure on reuse. The control is to keep durable data off ephemeral storage and to avoid persisting secrets there.
- SaaS content storage: over-sharing and shadow data. Links shared too widely and exported copies escape the provider's controls. The levers are sharing-policy enforcement, identity, and DLP, since you have no disk to lock down.
Recognizing the question
The stem usually describes the data's home, then asks for the threat or the fix. "Customer data was readable by anonymous users on the internet" points to an object-store policy failure, and the answer is to remove public access and apply least privilege, not to add a network ACL. "After deleting a volume, the data was recovered from the underlying storage" points to data remanence, and the cloud-correct fix is cryptographic erasure rather than physical destruction. "An attacker read other customers' records through the application's search box" points to injection against a structured store, and the fix is input validation and least-privilege database access. Match the threat to the storage type the stem names, and the distractor that applies a control from a different storage type falls away.
Storage types by service model and what threatens each
| Service model | Storage types exposed | Vendor examples | Signature threats |
|---|---|---|---|
| IaaS | Volume (block) and object storage; raw and ephemeral instance storage | EBS / Azure managed disks / GCP persistent disks (block); S3 / Azure Blob / Cloud Storage (object) | Public buckets and weak encryption (object); data remanence and uncontrolled snapshots (block); loss of scratch state (ephemeral) |
| PaaS | Structured (managed databases) and unstructured (managed blob / bucket) | Managed RDS/SQL and DynamoDB/Cosmos (structured); platform blob stores (unstructured) | Injection and over-broad DB credentials (structured); unscanned, unclassified uploads (unstructured) |
| SaaS | Content and information storage in the application; ephemeral client storage | Document/record stores inside the SaaS app; browser/device cache (ephemeral) | Over-sharing and shadow data the customer cannot see; data left in client cache |
Decision tree
Sharp facts the exam loves — give these one last read before exam day.
Cheat sheet
Sharp facts the exam loves — scan these before test day.
- Classify cloud storage by service model first
Cloud storage types follow the service model, and that is what decides which control is yours: IaaS exposes volume and object storage (plus raw and ephemeral), PaaS exposes structured and unstructured storage, and SaaS exposes content and information storage in the application. Place the storage in IaaS, PaaS, or SaaS before reasoning about a fix, because the model tells you whether you even own a disk-level lever or only data and access.
- Volume storage is block storage attached to one instance
Volume (block) storage presents a fixed-size disk to a single virtual machine, formatted with a filesystem, and is the home for boot drives, filesystems, and self-managed databases that need low-latency random read-write. Vendor examples are Amazon EBS, Azure managed disks, and Google Cloud persistent disks. It persists independently of the instance's run state, so stopping the VM does not lose it, unlike ephemeral storage.
Trap Putting a transactional database on object storage; object storage handles whole-object writes over an API, not the in-place random read-write a database filesystem needs.
- Object storage is API-reached and internet-addressable
Object storage keeps each file as a self-contained object (data plus metadata plus a unique key) in a flat namespace reached by an HTTP API, not a mounted disk, and it scales effectively without limit. Vendor examples are Amazon S3, Azure Blob Storage, and Google Cloud Storage. It is the natural home for backups, static content, logs, and data lakes, and because objects are immutable you change one by writing a new version rather than editing in place.
Trap Treating an object store like a low-latency filesystem; it is reached by API for whole objects and is wrong for random in-place updates.
- A public bucket is the signature object-storage threat
The most common cloud data exposure is an object store left readable to anyone by a misconfigured access policy. The control is least-privilege access policy and blocking public access at the account level, plus encryption at rest. This is an identity-and-policy failure, not a network failure, so the fix lives in the bucket policy and access settings, not a firewall.
Trap Reaching for a network ACL or firewall to fix a public bucket; the exposure is a permissions misconfiguration, so the answer is least-privilege access policy and blocking public access.
- Block-volume deletion risks data remanence
Deleted volumes and old snapshots can leave recoverable blocks behind, which is the data remanence threat for block storage. In a shared multi-tenant cloud you cannot physically destroy a disk, so the cloud-correct sanitization is cryptographic erasure: destroy the encryption key so the ciphertext is unrecoverable, following NIST SP 800-88 media-sanitization guidance. Snapshots are full copies with their own access controls, so they need the same protection as the source volume.
Trap Specifying physical media destruction (degaussing or shredding) to sanitize a cloud volume; you do not own the shared hardware, so cryptographic erasure is the applicable method.
- Ephemeral storage is wiped when the instance stops
Ephemeral (instance-local) storage is disk, RAM, and cache that exists only while the VM runs and is erased when the instance stops, terminates, or migrates to new hardware. AWS calls it an instance store. It is fast and free of network latency, which suits caches, scratch space, and temporary files, but it must never hold the only copy of data you need to keep. The testable contrast: a volume persists independently of the instance; ephemeral storage does not.
Trap Storing the only copy of durable data on instance-local storage; a stop, terminate, or host migration wipes it, so durable data belongs on block or object storage.
- Raw storage is unmanaged device or LUN access
Raw storage is direct access to the underlying device or logical unit number (LUN) with no filesystem the cloud manages for you. It gives the most control and the most responsibility, and it exposes the disk at the lowest level, so low-level tampering and the burden of all higher-layer protections fall to you. The exam names it alongside long-term and ephemeral as a way data can be held, distinct from the managed volume and object services.
- Match the persistence horizon: long-term, ephemeral, raw
Beyond the service model, the blueprint classifies storage by how long data lives and how it is held: long-term storage retains data for archival and compliance windows and so carries retention, deletion, and encryption-at-rest duties; ephemeral storage holds transient state that is fine to lose; raw storage is direct unmanaged device access. Each horizon changes the dominant threat, so map the data's lifetime to the tier before choosing controls.
- PaaS structured storage is a managed database with a schema
Structured storage in PaaS is a managed database that enforces a defined schema and answers queries, covering managed relational engines (Amazon RDS, Azure SQL Database, Cloud SQL) and managed NoSQL stores (Amazon DynamoDB, Azure Cosmos DB). The provider patches and replicates the engine; you still own the schema, the data classification, the encryption keys, and the credentials. Its known shape makes structured data the easiest to discover and label.
- Database storage is threatened by injection and over-broad credentials
The signature threats to structured (database) storage are SQL or NoSQL injection and credentials that grant more than the application needs. The controls are parameterized queries, least-privilege database accounts, encryption in transit, and secrets management for the credentials. An attacker reading other tenants' records through an application input points to injection against the database, fixed by input validation and least privilege, not by a storage-encryption change.
Trap Answering a search-box data-leak with encryption at rest; the breach is injection against a structured store, so the fix is parameterized queries and least-privilege accounts.
- PaaS unstructured storage holds schemaless files
Unstructured storage in PaaS is the managed blob or bucket the platform gives your application for files with no schema: images, documents, logs, and media. It is the PaaS-managed cousin of IaaS object storage. Because the content is opaque, you cannot assume its sensitivity, so it must be scanned and classified after it lands, which makes data discovery harder than for structured stores.
- Semi-structured data sits between structured and unstructured
Many real datasets are semi-structured: they carry tags or markers such as JSON or XML but no rigid table schema. For discovery and classification they fall between structured storage (known schema, easy to label) and unstructured storage (opaque, must be scanned), so treat them as needing markup-aware discovery rather than assuming either extreme.
- SaaS gives content and information storage, no disk control
In SaaS the provider stores your data inside the application as content storage (the files and objects users upload and share) and information storage (the structured records and fields the app maintains). You have no volume to encrypt and no bucket policy to set, so disk-level controls are the provider's, and your storage levers collapse to classification, sharing and access settings, and identity.
Trap Assuming you can set disk encryption or a storage policy in SaaS; those are the provider's, and your controls are classification, sharing settings, and identity.
- SaaS content storage is threatened by over-sharing and shadow data
The defining SaaS storage risk is over-sharing (links or permissions opened too widely) and shadow data, the exported or copied data that leaves the platform's visibility, rather than a misconfigured disk that you do not own. The levers are sharing-policy enforcement, identity, and data loss prevention, since you cannot lock down the underlying storage.
- The storage model is the responsibility line
Which storage type you have also fixes who secures it: in IaaS you own encryption, access policy, and sanitization of volumes and objects; in PaaS the provider secures the storage engine while you keep the keys, classification, and access; in SaaS the provider owns nearly the whole storage stack and your only actionable storage problems are sharing and identity. This is why the exam asks 'which storage type, in which model' before it asks for a control.
- Each storage type carries one signature threat to bind a control to
Threats are testable per storage type, not in the abstract: object storage fails through public access policies, block storage through data remanence, structured databases through injection, unstructured uploads through unscanned and unclassified data, ephemeral storage through silent data loss, and SaaS content through over-sharing. Pick the control from the type the question names rather than applying one blanket measure, because the distractor usually offers a control that fits a different storage type.
Trap Applying one blanket control to every storage type; the exam binds a specific threat to each type, so a control that fits a different type is the wrong answer.
- Reed-Solomon erasure coding RS(n,k) needs any k fragments to rebuild and tolerates n-k failures
Reed-Solomon erasure coding splits data into k data fragments plus parity for n total fragments. Any k of the n fragments reconstruct the original, so the system survives up to n-k simultaneous node failures (e.g., RS(14,10) tolerates 4). Compared with replication, erasure coding delivers equivalent fault tolerance at far lower storage overhead (roughly 50% vs 200% for three-way replication), which is why it suits large, rarely accessed archival datasets.
Trap Treating erasure coding as confidentiality — it provides durability and availability only; protecting fragments from a compromised CSP still requires encrypting the data first.
5 questions test this
- A cloud security architect is evaluating data protection techniques for sensitive financial data stored across multiple cloud service…
- A cloud architect is designing a storage system that must survive the loss of multiple storage nodes while minimizing storage overhead. The…
- During a cloud security assessment, an auditor discovers the organization uses a data dispersion system with Reed-Solomon erasure coding…
- A cloud data security architect must design a storage solution that provides both high availability and protection against unauthorized…
- An organization is migrating a large archival dataset to cloud storage and must choose between data replication and erasure coding. The…
- A snapshot inherits its source volume's encryption key; changing it requires an encrypted copy
A snapshot of an encrypted block volume inherits the source's encryption state and uses the same KMS key by default, and volumes restored from it stay encrypted. To encrypt a snapshot taken from a previously unencrypted volume, or to share one cross-account, create a copy specifying encryption (and a key whose policy grants the partner account access) — you cannot change an existing snapshot's encryption in place.
Trap Assuming enabling encryption-by-default retroactively encrypts old snapshots — it applies only to new volumes and copies; existing unencrypted snapshots must be copied with encryption specified.
3 questions test this
- When creating a snapshot of an encrypted block storage volume in a cloud environment, which statement BEST describes the encryption…
- An organization wants to share an encrypted block storage snapshot with a partner organization in a different cloud account. The partner…
- An organization has enabled encryption by default for all new block storage volumes in their cloud environment. A security analyst…