2.4 Cloud Storage Architectures & Performance

Cloud Storage Architectures & Performance

Storage architecture is one of the most critical pillars of cloud engineering. Choosing the incorrect storage modality or miscalculating I/O performance metrics can lead to application bottlenecks, runaway cloud bills, or catastrophic data loss during disaster recovery scenarios.

For the CompTIA Cloud+ (CV0-004) exam, cloud professionals must be able to evaluate, provision, and troubleshoot the four primary cloud storage types—Object Storage, Block Storage, File Storage, and Ephemeral Storage—while optimizing for throughput, IOPS, latency, tiering lifecycles, and encryption compliance.

---

1. Cloud Storage Modalities: Object, Block, File, and Ephemeral

+-----------------------------------------------------------------------------+
|                     THE FOUR CLOUD STORAGE PARADIGMS                        |
|                                                                             |
|   OBJECT STORAGE (S3 / Blob / GCS)          BLOCK STORAGE (EBS / Managed)   |
|   +-------------------------------+         +-----------------------------+ |
|   | - Flat namespace (Buckets)    |         | - Raw unformatted blocks    | |
|   | - REST API (HTTP GET/PUT/DEL) |         | - Formatted with ext4, XFS  | |
|   | - Immutable; Custom metadata  |         | - Ultra-low latency (<1 ms) | |
|   | - Near-infinite scalability   |         | - Single VM attach (RWO)    | |
|   +-------------------------------+         +-----------------------------+ |
|                                                                             |
|   FILE STORAGE (EFS / Azure Files)          EPHEMERAL (Instance Store)      |
|   +-------------------------------+         +-----------------------------+ |
|   | - Hierarchical folder tree    |         | - Physically attached NVMe  | |
|   | - POSIX / NFS v4 / SMB 3.0    |         | - Millions of IOPS          | |
|   | - Multi-instance concurrent   |         | - NON-PERSISTENT (Erased on | |
|   | - Shared CMS, home dirs, apps |         |   stop or hardware failure) | |
|   +-------------------------------+         +-----------------------------+ |
+-----------------------------------------------------------------------------+

Comprehensive Storage Modality Comparison Matrix

---

2. Storage Performance Engineering: IOPS, Throughput & Latency Math

Storage performance is governed by three interdependent metrics: IOPS, Block Size, and Throughput.

The Fundamental Storage Equation

$\text{Throughput (MB/s)} = \frac{\text{IOPS} \times \text{Block Size (KB)}}{1024}$

$\text{IOPS} = \frac{\text{Throughput (MB/s)} \times 1024}{\text{Block Size (KB)}}$

+-----------------------------------------------------------------------------+
|                      STORAGE PERFORMANCE METRIC MATRIX                      |
|                                                                             |
|   IOPS (Input/Output Operations Per Second)                                 |
|   - Measures the frequency of discrete read/write transactions per second.  |
|   - Dominates Transactional / OLTP workloads (MySQL, PostgreSQL, Oracle).  |
|   - Characterized by small, random block sizes (4 KB, 8 KB, 16 KB).         |
|                                                                             |
|   THROUGHPUT (MegaBytes / GigaBytes per Second)                             |
|   - Measures the total volume of raw data transferred per second.           |
|   - Dominates Streaming, Big Data Analytics (Hadoop/Spark), Backups, ETL.  |
|   - Characterized by large, sequential block sizes (64 KB, 256 KB, 1024 KB).|
|                                                                             |
|   LATENCY (Milliseconds / Microseconds)                                     |
|   - Measures the round-trip time between I/O submission and completion.     |
|   - Sub-millisecond latency is mandatory for financial and caching systems.|
+-----------------------------------------------------------------------------+

Real-World Architectural Calculation Examples:

1. Example 1: Small Block OLTP Database:
   • Workload: PostgreSQL processing 10,000 IOPS with an 8 KB database page block size.
   • Throughput Requirement: $\frac{10000 \times 8}{1024} = 78.125\text{ MB/s}$.
   • Sizing Takeaway: A high-IOPS volume tier (like AWS gp3 or io2) is required. Even though throughput is modest (78 MB/s), standard throughput-optimized HDD storage cannot deliver 10,000 random IOPS.
2. Example 2: Large Block Video Streaming:
   • Workload: Video processing pipeline reading 256 KB chunks at 500 MB/s.
   • IOPS Requirement: $\frac{500 \times 1024}{256} = 2,000\text{ IOPS}$.
   • Sizing Takeaway: Despite the low IOPS count (2,000), the massive throughput demands high-bandwidth storage pipes (or Throughput Optimized HDD st1 / provisioned gp3 throughput).

---

3. Solid-State Drives (SSDs) vs. Hard Disk Drives (HDDs) & Cloud Volume Tiers

Cloud block storage volumes are provisioned from either Solid-State Drive (SSD) or Hard Disk Drive (HDD) underlying physical arrays.

Cloud Block Storage Volume Tiers (AWS / Azure / GCP Analogs)

[!WARNING] Boot Volume Restriction: HDD volume types (such as AWS st1 and sc1) cannot be used as operating system boot volumes. OS boot sequences generate intense random I/O during kernel and daemon initialization, requiring SSD-backed volumes (gp3 / Premium SSD).

---

4. Storage Tiering, Lifecycle Management & Retention Policies

Cloud object storage platforms provide automated tiering mechanisms to transition data between distinct storage classes as access frequency declines over time, optimizing total cost of ownership (TCO).

+-----------------------------------------------------------------------------+
|                   OBJECT STORAGE LIFECYCLE TIERING FLOW                     |
|                                                                             |
|   [CREATION / ACTIVE INGESTION]                                             |
|   +---------------------------------------------------------------------+   |
|   | S3 STANDARD / HOT TIER                                              |   |
|   | - High availability, immediate ms access, lowest request cost       |   |
|   | - Highest storage cost ($0.023/GB/mo)                               |   |
|   +---------------------------------------------------------------------+   |
|                                     | (After 30 Days of Inactivity)         |
|                                     v                                       |
|   +---------------------------------------------------------------------+   |
|   | S3 STANDARD-IA / COOL TIER                                          |   |
|   | - Millisecond access, lower storage cost ($0.0125/GB/mo)            |   |
|   | - Data retrieval fees apply; 30-day minimum billing retention       |   |
|   +---------------------------------------------------------------------+   |
|                                     | (After 90 Days of Inactivity)         |
|                                     v                                       |
|   +---------------------------------------------------------------------+   |
|   | S3 GLACIER FLEXIBLE / COLD ARCHIVE                                  |   |
|   | - Very low storage cost ($0.0036/GB/mo); 90-day minimum retention   |   |
|   | - Retrieval Time: Expedited (1-5 min), Std (3-5 hr), Bulk (5-12 hr) |   |
|   +---------------------------------------------------------------------+   |
|                                     | (After 180-365 Days)                  |
|                                     v                                       |
|   +---------------------------------------------------------------------+   |
|   | S3 GLACIER DEEP ARCHIVE / FROZEN                                    |   |
|   | - Lowest cloud storage cost ($0.00099/GB/mo); 180-day min retention |   |
|   | - Retrieval Time: Standard (12 hours), Bulk (48 hours)              |   |
|   +---------------------------------------------------------------------+   |
|                                     | (After 2,555 Days / 7 Years)          |
|                                     v                                       |
|   +---------------------------------------------------------------------+   |
|   | PERMANENT EXPIRATION / AUTOMATED DELETION                           |   |
|   +---------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------+

Critical Lifecycle Caveats & Exam Traps:

1. Minimum Storage Duration Penalties: If an object is transitioned to S3 Standard-IA (30-day minimum) and deleted on Day 10, the cloud provider bills for the remaining 20 days. If transitioned to Glacier Deep Archive (180-day minimum) and overwritten on Day 30, early deletion fees are charged for 150 days.
2. Retrieval Fees: While Archive and Cool tiers offer ultra-low storage fees, data retrieval fees are assessed per gigabyte read. Moving data that is frequently accessed into cold archive tiers results in massive unexpected cloud charges.
3. Intelligent / Auto-Tiering: Uses machine learning monitoring to dynamically shift objects between frequent, infrequent, and archive access tiers without retrieval fees or operational lifecycle rules.

---

5. Enterprise Protocols: SAN, NAS, iSCSI, NFS & SMB/CIFS in Cloud

Traditional on-premises data center storage architectures map directly to cloud storage implementations.

+-----------------------------------------------------------------------------+
|                     STORAGE AREA NETWORK VS. NAS IN CLOUD                   |
|                                                                             |
|   STORAGE AREA NETWORK (SAN)                 NETWORK ATTACHED STORAGE (NAS) |
|   +--------------------------------+         +----------------------------+ |
|   | - Block-level storage fabric   |         | - File-level shared storage| |
|   | - Protocols: iSCSI, FC, FCoE   |         | - Protocols: NFS, SMB/CIFS | |
|   | - Appears as RAW local disk    |         | - Appears as network share | |
|   | - Cloud Analog: AWS EBS        |         | - Cloud Analog: AWS EFS    |
|   +--------------------------------+         +----------------------------+ |
+-----------------------------------------------------------------------------+

Protocol Breakdown:

• iSCSI (Internet Small Computer Systems Interface): Encapsulates SCSI storage commands inside standard IP/Ethernet packets (port 3260). Allows servers to access remote block storage arrays across standard network infrastructure without dedicated Fibre Channel switches.
• NFS (Network File System): Open distributed file protocol primarily used by Linux/UNIX systems (NFS v3 stateless over UDP/TCP; NFS v4 stateful over TCP port 2049 with ACLs and strong security).
• SMB (Server Message Block) / CIFS (Common Internet File System): Client-server file sharing protocol utilized predominantly by Microsoft Windows environments (SMB 2.1/3.0 over TCP port 445), supporting Active Directory authentication and file locking.
• Cloud Storage Gateways (Hybrid Integration): Virtual appliances (e.g., AWS Storage Gateway, Azure File Sync) deployed on-premises that bridge local SAN/NAS protocols (iSCSI, SMB, NFS) to cloud object storage (S3/Blob), offering local low-latency caching while persisting master datasets in the cloud.

---

6. Storage Security, Encryption Hierarchy & Snapshot Management

Encryption at Rest Architecture

Data encryption at rest is mandatory under enterprise compliance frameworks (PCI DSS, HIPAA, SOC 2, ISO 27001).

+-----------------------------------------------------------------------------+
|                      ENVELOPE ENCRYPTION ARCHITECTURE                       |
|                                                                             |
|   1. Key Management Service (KMS / Cloud HSM) generates:                    |
|      - Master Key (Customer Managed Key - CMK / Key Encryption Key - KEK)   |
|                                                                             |
|   2. KMS generates unique Plaintext Data Encryption Key (DEK) & Encrypted DEK|
|                                                                             |
|   3. Storage Engine uses Plaintext DEK to encrypt raw customer data blocks  |
|                                                                             |
|   4. Plaintext DEK is wiped from RAM; Encrypted DEK stored with ciphertext  |
+-----------------------------------------------------------------------------+

• Server-Side Encryption (SSE) Models:
  • SSE-S3 / Provider-Managed Keys: The cloud provider manages all encryption keys and rotation transparently.
  • SSE-KMS / Customer-Managed Keys (CMK): Keys are generated and governed inside a centralized Key Management Service (AWS KMS, Azure Key Vault, Google Cloud KMS), providing audit logging, automatic annual key rotation, and granular IAM access policies.
  • SSE-C / Customer-Provided Keys: The client provides the encryption key in the HTTP request header; the cloud provider encrypts the data in memory and immediately purges the key.
• Client-Side Encryption: The customer encrypts the data locally before sending it over the network to the cloud provider, guaranteeing that the cloud provider never possesses the keys or plaintext data.

Snapshot Consistency: Crash-Consistent vs. Application-Consistent

+-----------------------------------------------------------------------------+
|                   CRASH-CONSISTENT VS. APPLICATION-CONSISTENT               |
|                                                                             |
|   CRASH-CONSISTENT SNAPSHOT                 APPLICATION-CONSISTENT SNAPSHOT |
|   +-------------------------------+         +-----------------------------+ |
|   | - Instant point-in-time image |         | - Coordinates with VSS / OS | |
|   | - Equivalent to sudden power  |         | - Flushes in-flight memory  | |
|   |   cut to server               |         |   buffers to disk           | |
|   | - Disk buffers in RAM are     |         | - Quiesces database engine  | |
|   |   LOST                        |         | - Zero data loss or log     | |
|   | - Requires DB crash recovery  |         |   corruption upon restore   | |
|   +-------------------------------+         +-----------------------------+ |
+-----------------------------------------------------------------------------+

1. Crash-Consistent Snapshots: Captures data at an exact microsecond on disk. Does not flush memory caches or pause application writes. When restored, the OS boots as if recovering from a sudden power failure, relying on filesystem journals and database WAL logs to recover.
2. Application-Consistent Snapshots: Interfaces with the operating system and running database software (using Microsoft Volume Shadow Copy Service - VSS or Linux fsfreeze and database pre-freeze scripts) to flush all memory buffers to disk, pause I/O (quiescing), capture the snapshot, and resume I/O. Mandatory for production enterprise databases (SQL Server, Oracle, Exchange).

---

7. CompTIA Cloud+ Exam Tips & Storage Troubleshooting

• Ephemeral Data Loss Scenario: If a cloud virtual machine running on an instance with an Instance Store is stopped (deallocated) via the cloud console or API, all data on the instance store SSD is permanently destroyed. (Data persists through OS-level reboots, but stopping/terminating deallocates the physical host).
• IOPS Starvation Bottleneck: If a database experiences high disk queue depth and increased read latency while CPU and network bandwidth remain low, the block storage volume has hit its provisioned IOPS limit. Remediate by upgrading to a higher IOPS tier (e.g., gp3 with provisioned IOPS or io2).
• Snapshot Replication for Disaster Recovery: Cloud snapshots are region-specific by default. To fulfill Disaster Recovery (DR) requirements with low Recovery Point Objectives (RPO), configure automated cross-region snapshot copy policies to duplicate delta blocks to a secondary cloud region.