Study guide
2.4 Cloud Storage Architectures & Performance
CompTIA Cloud+ Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Cloud Architecture Fundamentals
1.1 Cloud Service Models & Shared Responsibility 1.2 Cloud Deployment Models & Multi-Cloud Strategies 1.3 High Availability, Resiliency & Redundancy 1.4 Disaster Recovery & Business Continuity 1.5 Evolving Cloud Technologies: AI/ML Services, IoT & Edge Computing
2 Chapter 2: Cloud Compute & Storage Architecture
2.1 Virtualization & Hypervisor Architectures 2.2 Containerization & Microservices Architecture 2.3 Container Orchestration & Kubernetes Architecture 2.4 Cloud Storage Architectures & Performance
3 Chapter 3: Cloud Networking Architecture
3.1 Virtual Private Clouds & Subnetting Architecture 3.2 Hybrid & Multi-Cloud Connectivity 3.3 DNS, Load Balancing & Traffic Routing 3.4 Cloud Network Security Architecture
4 Chapter 4: Workload Assessment & Migration Planning
4.1 Cloud Migration Strategies (The 6/7 Rs) 4.2 Pre-Migration Workload Assessment & Sizing 4.3 Data & Database Migration Methods 4.4 Migration Execution, Cutover & Post-Migration Validation
5 Chapter 5: Infrastructure as Code & Provisioning
5.1 Infrastructure as Code Fundamentals & State Management 5.2 IaC Tooling & Template Authoring 5.3 Provisioning Automation & Image Management 5.4 Deployment Strategies & Release Patterns
6 Chapter 6: Cloud Operations & Lifecycle Management
6.1 Resource Lifecycle & Patch Management 6.2 Cloud Scaling Strategies & Elasticity 6.3 Cloud Cost Management & Optimization (FinOps) 6.4 Capacity Planning & Service Quotas
7 Chapter 7: Cloud Backup, Recovery & Business Continuity Operations
7.1 Backup Strategies, Storage Media & Retention Policies 7.2 Immutable Backups, Vault Locking & Ransomware Defense 7.3 Point-in-Time Recovery & Data Integrity Validation 7.4 High Availability Failover Drills & Chaos Engineering
8 Chapter 8: Cloud Security Controls & Identity and Access Management
8.1 Identity & Access Management, RBAC & ABAC 8.2 Identity Federation, SSO & Directory Integration 8.3 Multi-Factor Authentication, PAM & Machine Identities 8.4 Secrets Management & Cryptographic Credential Hygiene
9 Chapter 9: Data Protection, Vulnerability & Compliance
9.1 Data Encryption, Key Management & Confidential Computing 9.2 Vulnerability Management, Posture Assessment & CWPP 9.3 Container, Workload & Runtime Security 9.4 Cloud Compliance Frameworks & Governance Auditing
10 Chapter 10: DevOps Fundamentals & CI/CD Pipelines
10.1 Version Control Systems & Branching Strategies 10.2 Continuous Integration & Automated Testing Pipelines 10.3 Continuous Delivery, Deployment Automation & GitOps 10.4 Configuration Management & Systems Integration
11 Chapter 11: Cloud Observability & Monitoring
11.1 The Three Pillars of Observability: Metrics, Logs & Traces 11.2 Cloud Monitoring Architecture, Alerting & SLOs 11.3 Centralized Log Aggregation, SIEM & Log Analytics
12 Chapter 12: Troubleshooting Cloud Architecture & Deployments
12.1 Structured Cloud Troubleshooting Methodology 12.2 Troubleshooting Compute, Container & Storage Failures 12.3 Troubleshooting Provisioning, IaC & Automation Failures
13 Chapter 13: Troubleshooting Cloud Networking & Security
13.1 Troubleshooting Cloud Network Connectivity & Routing 13.2 Troubleshooting IAM, Permissions & Encryption 13.3 Troubleshooting Disaster Recovery & Performance Degradation
2.4 Cloud Storage Architectures & Performance
Key Takeaways Explain This Topic AI
Cloud storage is classified into four fundamental architectures: Object Storage (flat RESTful, immutable, infinitely scalable), Block Storage (raw volumes, low latency, formatted with OS filesystems), File Storage (hierarchical shared POSIX/SMB filesystems), and Ephemeral / Instance Storage (high-performance non-persistent local NVMe SSDs).
Storage performance is governed by the relationship between IOPS, Throughput (MB/s), and Latency (ms), where Throughput equals (IOPS × Block Size) ÷ 1024.
Automated lifecycle management policies transition objects across access tiers (Hot, Cool/Infrequent, Cold/Archive, Deep Archive) to optimize costs, but premature deletions trigger minimum billing duration penalties.
Enterprise SAN (Fibre Channel, iSCSI) and NAS (NFS, SMB/CIFS) architectures translate to cloud managed services, hybrid storage gateways, and protocol-specific endpoints.
Data protection requires combining Server-Side Encryption (SSE-S3, SSE-KMS, envelope encryption) with application-consistent snapshots (VSS/quiescing) and cross-region replication to prevent ransomware data loss.
Last updated: August 2026
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
Technical Dimension Object Storage Block Storage File Storage Ephemeral / Instance Store
Cloud Offerings AWS S3, Azure Blob, Google Cloud Storage (GCS) AWS EBS, Azure Managed Disk, GCP Persistent Disk AWS EFS / FSx, Azure Files, GCP Cloud Filestore AWS EC2 Instance Store, Azure Temp Disk, GCP Local SSD
Access Method / Protocol REST API (HTTP/HTTPS GET, PUT, DELETE, LIST) Block protocols (iSCSI, NVMe-oF, SCSI) Network file sharing (NFS v3/v4.1, SMB 3.0 / CIFS) Direct PCIe / NVMe bus bus controller
Data Structure Flat address space; Buckets + Objects + Keys Raw 512-byte or 4KB sectors / blocks Hierarchical directory tree, folders, and files Raw local SSD block device
Mutability Immutable (Must overwrite entire object) Read/Write Mutable (Update individual bytes/blocks) Read/Write Mutable (Standard file append/locks) Read/Write Mutable (Volatile/Temporary)
Latency Profile High latency (tens to hundreds of ms) Ultra-low latency (sub-millisecond to single-digit ms) Moderate latency (single-digit to tens of ms) Extreme low latency (microsecond scale)
Max Capacity Virtually infinite (exabytes scale) Terabytes (up to 64 TB per volume) Petabytes scale with elastic expansion Limited by physical server chassis (e.g., 30 TB)
Multi-Compute Concurrency Millions of concurrent HTTP clients Single instance attach (or limited multi-attach) Hundreds of concurrent compute instances Strictly tied to single physical host server
Ideal Workloads Media assets, backups, big data lakes, archives Relational databases (SQL, Oracle), OS boot disks Shared app storage, WordPress media, user homes DB scratchpads, Redis caches, temp buffers
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 Throughput (MB/s) = IOPS × Block Size (KB) 1024 \text{Throughput (MB/s)} = \frac{\text{IOPS} \times \text{Block Size (KB)}}{1024} Throughput (MB/s) = 1024 IOPS × Block Size (KB) IOPS = Throughput (MB/s) × 1024 Block Size (KB) \text{IOPS} = \frac{\text{Throughput (MB/s)} \times 1024}{\text{Block Size (KB)}} IOPS = Block Size (KB) Throughput (MB/s) × 1024 +-----------------------------------------------------------------------------+
- | 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:
Example 1: Small Block OLTP Database:
Workload: PostgreSQL processing 10,000 IOPS with an 8 KB database page block size.
Throughput Requirement: 10000 × 8 1024 = 78.125 MB/s \frac{10000 \times 8}{1024} = 78.125\text{ MB/s} 1024 10000 × 8 = 78.125 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.
Example 2: Large Block Video Streaming:
Workload: Video processing pipeline reading 256 KB chunks at 500 MB/s.
IOPS Requirement: 500 × 1024 256 = 2 , 000 IOPS \frac{500 \times 1024}{256} = 2,000\text{ IOPS} 256 500 × 1024 = 2 , 000 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)
Cloud Tier Category AWS Volume Type Azure Equivalent Target Workload & Performance Profile
General Purpose SSD gp3 / gp2 Standard SSD / Premium SSD v1 Baseline balance of cost/performance. gp3 provides 3,000 baseline IOPS and 125 MB/s throughput independent of volume size.
Provisioned IOPS SSD io2 Block Express / io1 Ultra Disk / Premium SSD v2 Mission-critical relational databases, SAP HANA. Delivers up to 256,000 IOPS and 4,000 MB/s with sub-millisecond latency.
Throughput Optimized HDD st1 Standard HDD (High Throughput) Big data, data warehouses, log processing. High sequential throughput (up to 500 MB/s), but very low random IOPS (max 500 IOPS).
Cold HDD sc1 Standard HDD Infrequently accessed sequential workloads, large data archives requiring low cost per gigabyte.
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:
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.
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.
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 | |
- | +-------------------------------+ +-----------------------------+ |
- +-----------------------------------------------------------------------------+
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.
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.