4.2 Cloud Data Storage Architectures (Domain 2.2)
Key Takeaways
- CCSP storage types include long-term, ephemeral, raw, object, and volume storage — each has different durability, access patterns, and threat profiles.
- Object storage is API-addressable, highly durable, and commonly misconfigured for public access; volume storage attaches as block devices to compute and inherits instance-compromise risk.
- Ephemeral storage vanishes with the instance lifecycle and must not be the sole home for durable secrets or regulated records; still sanitize and avoid sensitive residue.
- Long-term and archive classes trade retrieval latency/cost for retention economics; threats include incomplete deletion, weak access on 'cold' data, and ransomware against backups.
- Design by matching data lifecycle phase and classification to storage type, then apply type-specific threats: access control, encryption, immutability, network isolation, and lifecycle policies.
Cloud Data Storage Architectures
Domain 2.2 asks you to design and implement storage architectures — not merely list product names. The August 2026 outline highlights storage types such as long-term, ephemeral, raw, object, and volume, plus threats to each type. Vendor consoles brand these differently (block volumes, blob/object buckets, local instance disks, cold archive tiers, direct-attached or import/export raw media). CCSP expects vendor-neutral recognition of characteristics and risks.
Storage architecture is where lifecycle concepts become physical (or virtual) reality. Choosing object storage for unbounded unstructured content, volumes for databases, and long-term classes for compliance archives is a security decision as much as a cost decision — because threats follow the access model.
Shared Responsibility for Storage
| Layer | Typical CSP responsibility | Typical customer responsibility |
|---|---|---|
| Physical media, racks, facilities | Yes | No (except private/on-prem cloud) |
| Underlying storage fabric durability features | Yes (as marketed/SLA) | Validate SLA fit; design multi-region if needed |
| Hypervisor / storage service software | Yes | Patch/config only if customer-managed components exist |
| Encryption in transit to storage APIs | Often default TLS | Enforce TLS; disable weak endpoints |
| Encryption at rest & key custody | Provider-managed or customer-managed options | Choose CMK/HSM paths when required; protect keys |
| IAM policies, public access, network endpoints | Platform features | Customer configures — #1 breach class |
| Classification, lifecycle rules, logging | Features available | Customer defines and monitors |
Exam mantra: The provider keeps the disks spinning; you keep the data from being world-readable.
Storage Types Overview
| Type | Access model | Durability posture | Typical use |
|---|---|---|---|
| Volume storage | Block device attached to VM/container host | High when backed by networked durable volumes; depends on snapshot/replication design | OS disks, databases, transactional apps |
| Object storage | RESTful/API object + metadata | Extremely high via multi-AZ erasure coding/replication | Backups, content, data lakes, static assets |
| Long-term storage | Often object/archive APIs with retrieval delay | High; retrieval may be hours | Compliance archives, cold backups, rarely read datasets |
| Ephemeral storage | Local to instance/function lifecycle | Low — data lost on stop/terminate/recycle | Caches, scratch space, temp processing |
| Raw storage | Low-level or direct media / import-export / bare capacity | Variable | Bulk ingest, specialized appliances, migration pipelines |
File storage (managed NFS/SMB-style shares) appears in real architectures and may be tested as a hybrid of volume/network semantics; the outline’s explicit list is the five above — know those cold.
Volume Storage
Volume storage presents a block device (virtual hard disk) to a compute instance. The guest OS filesystems and databases sit on top. Volumes can be:
- Network-attached durable volumes that survive instance stop (typical cloud "EBS-like" pattern).
- Local NVMe/SSD that may be instance-bound (borderline ephemeral — check provider semantics).
Design notes
- Snapshots and clones create dispersed copies — encrypt snapshots and restrict share permissions.
- Multi-attach or shared-disk patterns need careful fencing to avoid corruption.
- Performance tiers (IOPS/throughput) affect availability under load (noisy neighbor or throttle) but security focuses on access and encryption.
Threats to volume storage
| Threat | Description | Mitigations |
|---|---|---|
| Unauthorized attach/snapshot | Stolen role creates snapshot or attaches volume to attacker instance | Strict IAM, deny public snapshot shares, organization policy guards |
| Instance compromise | Malware reads mounted filesystem | Hardening, EDR, least privilege OS accounts, encryption + key isolation |
| Snapshot sprawl | Forgotten snapshots hold old PHI | Lifecycle policies, inventory, tagging |
| Unencrypted volumes | Media theft or backend exposure residual risk | Default encryption, CMK for high sensitivity |
| Orphaned volumes | Detached disks still billed and readable by privileged admins | Automation to detect unattached volumes; delete or quarantine |
| Cross-account share abuse | Volume/snapshot shared to wrong account | Explicit allow-lists; monitor share events |
Exam tip: If the stem says "database on a VM," think volume threats (snapshot theft, attach-to-hostile-VM) more than public bucket policies — unless backups land in object storage.
Object Storage
Object storage manages discrete objects (blobs) addressed by keys within buckets/containers, with rich metadata and HTTP(S) APIs. It scales nearly without the filesystem limitations of volumes. Versioning, lifecycle transitions, event notifications, and strong durability make it the backbone of modern cloud data lakes and backup targets.
Design notes
- Flat namespace + prefixes replace deep directory ACLs — IAM and bucket policies are the perimeter.
- Versioning helps ransomware recovery but retains deleted-object versions until lifecycle cleans them.
- Object lock / immutability (WORM-style) supports legal retention and ransomware resilience.
- Static website hosting / public read features are convenience switches with severe risk if misused for private data.
Threats to object storage
| Threat | Description | Mitigations |
|---|---|---|
| Public access misconfiguration | Anonymous List/Get on sensitive prefixes | Block public access defaults, policy checks, continuous config audit |
| Over-permissive IAM | Wildcard principals or actions | Least privilege, condition keys (VPC endpoint, MFA delete) |
| Presigned URL abuse | Long-lived URLs leaked in logs/tickets | Short TTL, scope to object, monitor generation |
| Malicious object upload | Malware or poison data in inbound buckets | Malware scanning, content-type validation, separate unclean/clean buckets |
| Ransomware / mass delete | Destructive API calls | Versioning + object lock, MFA delete, separate backup account |
| Server-side request / SSRF to metadata | Apps fetch attacker-controlled object URLs | Egress control, validate URLs |
| Metadata leakage | Sensitive data in object names or tags | Naming standards, encryption of sensitive metadata where supported |
Object storage is the most frequently breached cloud storage class in exam scenarios because one policy statement can expose petabytes.
Long-Term Storage
Long-term storage (cold/archive classes, offline vaults, tape-gateway patterns) optimizes cost for data retained months to decades with infrequent access. Retrieval may require hours and rehydration fees. From a security view, "cold" does not mean "uninteresting to attackers" — archives hold crown-jewel historical data.
Design notes
- Align archive class with retention policies and legal hold (Domain 2.7 topics build here).
- Test restores; untested archives fail business continuity.
- Prefer encryption with keys under customer governance for regulated archives.
- Document who can initiate retrieval — retrieval is a high-value audit event.
Threats to long-term storage
| Threat | Description | Mitigations |
|---|---|---|
| Weak controls on "forgotten" data | Legacy buckets with broad access | Same IAM rigor as hot data; periodic access reviews |
| Incomplete destruction | Delete primary, leave archive | Unified lifecycle inventory across tiers |
| Ransomware targeting backups | Encrypt/delete backup vaults | Immutable vaults, separate accounts, dual control |
| Insider retrieval abuse | Quiet exfiltration via restore jobs | Alert on atypical restore volume/destination |
| Media/vendor residual risk | Offline media handling, third-party vaults | Chain of custody, contractual sanitization |
| Integrity decay | Bit rot or silent corruption over years | Checksums, periodic integrity verification |
Ephemeral Storage
Ephemeral storage is temporary capacity tied to the life of a compute unit: instance store, container writable layers, serverless /tmp, GPU local disks. When the instance stops, recycles, or scales in, data may be wiped or become unreachable. Developers love it for speed; security professionals fear secrets left in temp files and false assumptions of durability.
Design notes
- Use for caches, intermediate compute, non-authoritative scratch only.
- Redirect durable writes to volume/object stores explicitly.
- Prefer memory-backed secret injection over writing keys to local disk.
- Assume residual data may persist until provider reclaims media — encrypt sensitive temp data if unavoidable.
Threats to ephemeral storage
| Threat | Description | Mitigations |
|---|---|---|
| Sensitive residue | Tokens, PII in /tmp after crash | Avoid writing secrets; secure delete; disk encryption |
| Cross-tenant residual risk | Theoretical residual on reused hardware | Provider sanitization + customer encryption defense-in-depth |
| False durability | App "stores" records only on local disk | Architecture review; chaos terminate tests |
| Container breakout reading host paths | Shared mounts expose sibling data | Minimal mounts, user namespaces, separate nodes for sensitive workloads |
| Debug artifacts | Core dumps with secrets | Disable unprotected dumps; restrict permissions |
Raw Storage
Raw storage in CCSP discussion often means low-level capacity without higher-level object semantics — for example, bare LUNs, direct-attached storage patterns, bulk data import/export devices, or unformatted block capacity presented for customer formatting. It appears in migrations (snowball-style offline transfer conceptually), specialized high-performance workloads, and lift-and-shift of appliances that expect raw disks.
Design notes
- Customer may own more of the stack (partitioning, encryption software, multipathing).
- Physical or courier-based bulk transfer adds chain-of-custody threats.
- Label and inventory raw volumes carefully — easy to attach to the wrong host.
Threats to raw storage
| Threat | Description | Mitigations |
|---|---|---|
| Mis-attachment | Wrong LUN mapped to wrong tenant/host | Strict zoning/mapping, change control |
| Transit loss/theft (import/export) | Device seized in shipping | Encryption before ship, tamper evidence, dual control |
| Uninitialized sensitive residue | Previous data remnants | Crypto-erase, secure wipe procedures |
| Weaker API audit trails | Fewer high-level data events than object stores | Host-level logging, storage fabric logs |
| Privilege on storage fabric | Admin can clone raw devices silently | Segregation of duties, monitoring clone/mirror jobs |
Comparing Threats Across Types
| Threat theme | Volume | Object | Long-term | Ephemeral | Raw |
|---|---|---|---|---|---|
| Public anonymous access | Rare (if exposed via app) | Very common | Common if archive is object-backed | Low | Low |
| Snapshot/clone theft | High | Version/copy abuse | Restore abuse | N/A | Clone/mirror abuse |
| Lifecycle deletion gaps | Snapshot orphans | Version orphans | Archive leftovers | Auto-wipe on terminate | Media return gaps |
| Host compromise reads data | High | Via keys/creds | Via restore | High locally | High |
| Ransomware | Encrypt FS / delete snaps | Mass delete/overwrite | Destroy vaults | Limited | Encrypt LUN |
Architecture Patterns That Pass Exam Scrutiny
- Tiered storage with policy: Hot volumes/objects for Use phase; lifecycle transition to long-term for Archive; automated expire/destroy.
- Immutable backup pattern: Production account writes to backup account object lock vault; separate IAM boundaries.
- Ephemeral compute, durable data: Stateless instances; state only in managed databases/object stores.
- Private access paths: Storage endpoints reachable via private networking; block public internet where feasible.
- Encryption default + CMK for sensitive classes: Provider-managed keys for low sensitivity; customer-managed for regulated.
- Migration with raw/import devices: Encrypt payloads before device leaves source facility; verify hashes on ingest.
Worked multi-cloud example: An enterprise runs transactional databases on volume storage in Cloud A, lands analytics extracts in object storage, transitions year-old extracts to long-term archive, uses ephemeral disks for Spark executors, and performs initial bulk load via encrypted raw/offline transfer appliances. Threat reviews must not stop at the database volume — the object analytics bucket and archive vault are equal prize targets.
Selecting Storage Type: Decision Grid
| Question | Prefer |
|---|---|
| Need POSIX disk for DB/app installs? | Volume |
| Massive unstructured, API access, event-driven? | Object |
| Retain 7+ years, rare reads? | Long-term |
| Scratch space only for job runtime? | Ephemeral |
| Bulk offline migration or appliance disks? | Raw (with encryption) |
Common Traps
- Using ephemeral storage as the only copy of customer records.
- Treating archive tiers as "safe enough" with open IAM.
- Forgetting that volume snapshots often live in object-backed snapshot services — hybrid threat model.
- Equating durability SLAs with confidentiality.
- Assuming raw import devices are secure because they are "offline" without encrypting contents.
A development team stores session tokens and intermediate PII extracts only on a container’s local writable layer, with no external database write. Which storage type and risk pairing is most accurate?
Which threat is most characteristically associated with cloud object storage in CCSP scenarios?
An attacker with a stolen automation role creates a snapshot of a production database volume and shares it to an external account. Which storage type was primarily abused?
When designing long-term archive storage for regulated records, which control set best addresses typical threats?