Compute and Storage Resource Planning is the process of sizing your cloud servers (compute) and disk space (storage) to match exactly what your applications need, without wasting money or leaving users waiting. It matters for CV0-004 because half the exam scenarios ask you to calculate or recommend the right amount of CPU, RAM, and storage for a given business requirement, and you need to know the trade-offs between performance and cost.
Jump to a section
A simple way to picture Compute and Storage Resource Planning
When you plan a kitchen renovation, you first decide what meals you will cook (the workload), then you pick the stove and oven (compute) and the fridge and pantry (storage) to match those meals. If you cook big roasts every Sunday, you need a large oven and extra fridge space. If you only make sandwiches, a microwave and a mini-fridge suffice. Over-allocating means you waste money on appliances you never use and counter space you never fill. Under-allocating means you cannot cook the Christmas turkey or store leftovers.
Similarly, in cloud computing, you must first forecast your application workloads: how many users, how much data, and how fast it grows. Then you choose virtual machines (the compute) with the right CPU and RAM, and storage volumes (the storage) with the right capacity and speed. The cause-and-effect relationship is simple: workload demand drives compute and storage choices. Get it right and you save money and keep users happy. Get it wrong and you either pay for idle resources or face slow applications and angry customers.
In cloud computing, everything runs on servers inside massive data centres owned by providers like Amazon Web Services, Microsoft Azure, or Google Cloud. These servers are not physical machines you can touch; they are virtual machines (VMs) — software-based computers that act like real ones. Compute refers to the processing power of these VMs: the number of virtual CPUs (vCPUs) and the amount of RAM (memory). Storage refers to the space where you keep files, databases, and backups: hard drives or solid-state drives (SSDs) that hold data even when the VM is turned off.
Resource planning means choosing the right combination of compute and storage before you deploy an application. Why does this matter? Because cloud services are pay-as-you-go. If you pick a VM with 16 vCPUs and 64 GB of RAM but your app only needs 2 vCPUs and 8 GB, you waste money every month. If you pick too little, your app slows down, users get frustrated, and you lose business. The goal is to find the sweet spot.
First, you need to understand workload profiles. A workload is any application or process running on a VM. Workloads fall into three broad types:
CPU-bound: these workloads do a lot of calculations, like video encoding, scientific simulations, or financial modelling. They need many vCPUs.
Memory-bound: these workloads hold large datasets in RAM to process quickly, like in-memory databases or analytics tools. They need large amounts of RAM.
I/O-bound: these workloads read and write lots of data to disk, like file servers or database transaction logs. They need fast storage (SSDs) and high input/output operations per second (IOPS).
Storage itself has several characteristics you must plan for. Capacity is the raw size, measured in gigabytes (GB) or terabytes (TB). Performance is measured by IOPS and throughput (the amount of data transferred per second). For example, an SSD might offer 10,000 IOPS while a traditional hard disk (HDD) offers only 200 IOPS. Redundancy is how many copies of your data the cloud provider keeps. If a disk fails, redundant storage automatically switches to another copy so you lose nothing. Common redundancy models include:
Raid 0: stripes data across multiple disks for speed but offers no redundancy.
Raid 1: mirrors data across two disks — if one fails, the other still has the data.
Raid 5: distributes data and parity across multiple disks, balancing performance and redundancy.
Raid 10: combines mirroring and striping for both performance and redundancy.
You also need to consider scalability. Scalability is the ability to increase or decrease resources as demand changes. Vertical scaling means upgrading a single VM with more vCPUs or RAM. Horizontal scaling means adding more VMs and distributing the workload among them. Most modern applications are designed to scale horizontally because it offers better resilience — if one VM fails, the others keep running.
Elasticity is the ability to automatically adjust resources in real time based on demand. For instance, an e-commerce site might use an auto-scaling group that adds VMs during a flash sale and removes them when traffic slows. This avoids paying for idle capacity during quiet periods.
Another critical concept is resource utilisation. This is the percentage of your allocated compute and storage that you actually use. If you consistently use only 20% of your CPU, you are over-provisioned. You should aim for around 70-80% utilisation to balance performance headroom with cost efficiency. Cloud providers offer monitoring tools like Amazon CloudWatch or Azure Monitor to track utilisation over time.
Finally, you must consider cost models. Most providers offer three purchasing options for compute:
On-demand: pay by the hour or second with no upfront commitment. Flexible but most expensive for long-running workloads.
Reserved instances: commit to 1 or 3 years in exchange for a significant discount (up to 70%). Best for predictable, steady workloads.
Spot instances: bid on unused capacity at a steep discount, but the provider can reclaim the VM at any moment. Ideal for fault-tolerant batch jobs like data processing.
For storage, you typically pay per gigabyte stored per month, plus costs for data transfer and IOPS. Some storage tiers are cheaper but slower (like Amazon S3 Glacier for archive backups) or more expensive but faster (like Amazon EBS Provisioned IOPS for databases).
Planning also involves understanding Service-Level Agreements (SLAs). An SLA is a contract that guarantees a certain level of availability, usually measured as a percentage like 99.9% (three nines) or 99.99% (four nines). Higher SLA percentages require more redundant and geographically distributed resources, which cost more. If you need 99.999% uptime (five nines), you need resources across multiple data centres or regions.
In summary, compute and storage resource planning is about matching server power and disk space to application requirements, optimising for cost, performance, and reliability. The exam will ask you to make these calculations and trade-offs based on realistic scenario descriptions.
Analyse the workload
Identify the application's resource demands: number of users, data size, growth rate, and whether it is CPU, memory, or I/O intensive. This step determines the baseline requirements for compute and storage.
Define performance and availability targets
Set the required IOPS, throughput, uptime (SLA), and redundancy level. For example, a critical database may need 10,000 IOPS and 99.99% availability, meaning replicas across two availability zones.
Select compute resources
Choose a VM instance type and family that matches the workload profile. General-purpose instances balance CPU and RAM; compute-optimised instances suit batch processing; memory-optimised instances suit databases. Decide between on-demand, reserved, or spot pricing based on workload predictability.
Design storage architecture
Allocate storage volumes for operating system, data, and backups. Pick the right storage tier (SSD, HDD, object storage) and configure redundancy (RAID levels, replication across zones). Plan for future growth by leaving headroom or using auto-scaling policies for storage.
Implement scaling and monitoring
Set up auto-scaling groups to add or remove compute nodes based on metrics like CPU utilisation or request count. Configure cloud monitoring dashboards to track utilisation, cost, and performance. This allows continuous optimisation after deployment.
Review and iterate
After deployment, analyse monitoring data. If utilisation is consistently low, downsize instances or switch to reserved instances to save cost. If performance is below target, upgrade storage tiers or increase compute capacity. Iteration is normal and expected.
You work as a junior cloud administrator for a mid-sized retail company called ShopNow. The company runs an e-commerce website that sells clothing. Currently, the website runs on a single physical server in the office basement, but after repeated outages during sales events, the CEO decides to migrate to the public cloud.
Your first task is to plan compute and storage for the new cloud environment. You start by gathering requirements from the development team:
The web application is written in Python and runs on a Linux web server.
The database is MySQL and stores product details, customer orders, and inventory.
Daily traffic is about 5,000 visitors, but during holiday sales it spikes to 50,000 visitors. Traffic patterns are predictable.
The development team wants the application to handle the spike without manual intervention.
The database currently uses 200 GB of stored data and grows by 5 GB per month.
The company has a budget of $2,000 per month for cloud resources.
You begin by calculating compute needs. Based on testing the application on-premise, each visitor session uses about 0.5 vCPU and 1 GB of RAM. For 5,000 visitors spread over 12 hours, you estimate a baseline of 2 vCPUs and 4 GB of RAM. For the spike of 50,000 visitors, you need 10 vCPUs and 20 GB of RAM. You decide to use an auto-scaling group that starts with two small VMs (2 vCPU, 4 GB each) and scales up to five medium VMs (4 vCPU, 8 GB each) during peak times.
For storage, you need several types:
Boot volumes for each VM: 30 GB each using general-purpose SSDs.
Database storage: 200 GB plus future growth, using a high-IOPS SSD to handle multiple database transactions per second.
File storage for product images: 500 GB stored in object storage (like Amazon S3) because images are read frequently but rarely modified.
Backup storage: 1 TB in a cheap, cold storage tier for monthly snapshots.
You also need to decide redundancy. The database is critical, so you choose a managed database service that automatically replicates data across two availability zones (separate data centres within a region). The web VMs are stateless (they do not store user data locally), so you do not need redundancy for them — if one fails, the auto-scaling group launches a new one.
Next, you calculate costs. Using the cloud provider's pricing calculator, you estimate:
On-demand VMs for baseline: $80 per month.
Reserved instance discount for baseline VMs (1-year commitment): saves 40%, so $48 per month.
Auto-scaling peak VMs (used 6 hours per day for 10 days per month): $30 per month.
Database storage with high IOPS: $150 per month.
Object storage for images: $35 per month.
Backup cold storage: $10 per month.
Data transfer out to users: $50 per month.
Total baseline: approximately $323 per month, well within budget. You present the plan to your manager, including a diagram showing the architecture: a load balancer at the front, an auto-scaling group of web VMs behind it, and a managed database in the back. The plan is approved.
Over the next month, you monitor resource utilisation using cloud dashboards. You notice CPU usage never exceeds 30% on baseline VMs. You adjust by downgrading to smaller instances, saving another $15 per month. This iterative refinement is the essence of compute and storage resource planning in practice: start with educated estimates, deploy, monitor, and adjust.
The CV0-004 exam tests compute and storage resource planning in several distinct ways. You will see scenario-based multiple-choice questions that describe a business requirement and ask you to select the most appropriate compute or storage configuration. Here is exactly what they test:
Scenarios you will face:
A company migrates an e-commerce application to the cloud. You must pick a VM with the right vCPU and RAM for the application tier.
A database needs a certain number of IOPS. You choose between SSD, HDD, or provisioned IOPS storage tiers.
A batch processing job runs once per week. You decide whether to use on-demand, reserved, or spot instances.
An application must be highly available. You select the number of availability zones or regions.
A company has a fixed budget. You determine the most cost-efficient way to meet performance requirements.
Trap patterns that frequently appear:
Trap 1: The scenario describes high CPU usage, but the answer options focus on storage speed. The correct answer is to choose a VM with more vCPUs, not a faster disk.
Trap 2: The exam gives a low-budget constraint but also mentions high availability. Many candidates pick the cheapest option (single VM, no redundancy) and fail because they miss the availability requirement. The correct answer is to use two smaller VMs across availability zones, even if it costs slightly more.
Trap 3: Questions about elasticity and auto-scaling. The trap is linking auto-scaling to vertical scaling (upgrading a VM) when horizontal scaling (adding more VMs) is the correct approach.
Trap 4: Storage performance. They might ask for high throughput (lots of data per second) but the options offer high IOPS (many small reads/writes). Throughput is different from IOPS. The correct answer depends on the workload description: sequential reads need throughput; random reads need IOPS.
Trap 5: Reserved instances for unpredictable workloads. They give a discount option, but if the workload spikes unpredictably, on-demand or spot instances are better.
Concepts to memorise verbatim:
The difference between vertical scaling and horizontal scaling: vertical changes the size of a single resource; horizontal changes the number of resources.
The three purchasing models: on-demand, reserved, and spot. Know when to use each.
Storage tiers: hot (frequent access, higher cost), cool (infrequent access, lower cost), cold (archival, lowest cost).
IOPS vs throughput: IOPS is input/output operations per second (for small random reads); throughput is megabytes per second (for large sequential reads).
SLA percentages and what they imply: 99.9% = about 8.76 hours downtime per year; 99.99% = about 52 minutes per year; 99.999% = about 5 minutes per year.
The default redundancy options for compute (availability sets or availability zones) and for storage (locally redundant vs geo-redundant).
Question formats you will see:
Direct calculation: 'An application needs 8 GB of RAM per user and supports 100 concurrent users. How much RAM should the VM have?' The answer is 800 GB, but they include a trap answer that multiplies the numbers incorrectly (e.g., 8 + 100 = 108).
Best practice selection: 'A company runs a stateless web application that experiences unpredictable traffic spikes. What is the most cost-effective scaling method?' Answer: horizontal auto-scaling.
Comparative selection: 'Which storage option provides the highest IOPS?' Answer: provisioned IOPS SSD.
The exam expects you to understand trade-offs, not just definitions. For every answer, justify why the other options are wrong. Practise by reading scenario questions and eliminating options that do not match the budget, performance, or availability constraints.
Resource planning starts with analysing workload requirements: CPU-bound, memory-bound, or I/O-bound, and then matching them to the right instance type and storage tier.
Vertical scaling changes the capacity of a single resource; horizontal scaling adds more resources and spreads the workload — the latter is almost always better for availability and cost flexibility.
On-demand instances are ideal for short-term or unpredictable workloads; reserved instances suit steady-state workloads; spot instances work for fault-tolerant batch processes at the lowest cost.
Storage performance is measured in IOPS for random small reads/writes and in throughput for sequential large reads/writes — never confuse the two in exam scenarios.
An SLA guarantee of 99.9% allows roughly 8.76 hours of downtime per year, while 99.99% allows about 52 minutes — know these numbers to determine redundancy needs.
Auto-scaling groups combined with load balancers are the standard pattern for achieving elasticity in stateless applications, allowing you to match compute capacity exactly to real-time demand.
These come up on the exam all the time. Here's how to tell them apart.
Vertical Scaling
Increases the size of a single VM (more vCPUs, more RAM).
Requires downtime or reboot to apply changes in most cases.
Best for monolithic applications that cannot run on multiple servers.
Horizontal Scaling
Adds more VMs to the pool and distributes the workload.
No downtime needed; new instances are provisioned on the fly.
Best for stateless, distributed applications like web servers.
SSD Storage
Uses flash memory; very fast IOPS (10,000+).
Higher cost per gigabyte.
Ideal for databases, high-transaction applications, and OS boot volumes.
HDD Storage
Uses spinning magnetic disks; lower IOPS (200-500).
Lower cost per gigabyte.
Ideal for archival data, backups, and sequential large file reads.
On-Demand Instances
Pay per hour or second with no upfront commitment.
Full flexibility to change instance type or stop anytime.
Highest per-unit cost; best for short-term or variable workloads.
Reserved Instances
Commit to 1 or 3 years for a significant discount (up to 70%).
Less flexibility; penalties if you stop early or change instance family.
Best for steady-state, always-on workloads like production databases.
Provisioned IOPS Storage
You specify a guaranteed IOPS level (e.g., 20,000 IOPS).
Highest cost; designed for latency-sensitive workloads (e.g., OLTP databases).
Consistent performance even under high sustained load.
General-Purpose SSD
Offers a baseline IOPS with occasional burst capability.
Lower cost; suitable for most standard workloads (e.g., web servers).
Performance might throttle if baseline is exceeded for too long.
Hot Storage Tier
Optimised for frequent data access (multiple times per day).
Higher storage cost but minimal retrieval fees.
Best for active data: product catalogues, current transaction logs.
Cold Storage Tier
Optimised for data accessed infrequently (once a quarter or less).
Low storage cost but higher retrieval fees and longer retrieval times.
Best for backups, compliance archives, and old logs.
Mistake
Cloud resources are infinite and I never have to plan — I can just add more later.
Correct
Cloud resources are effectively unlimited, but if you do not plan, you overspend. Without planning, you choose oversized instances and waste money, or you choose undersized instances and cause performance issues until you add more. Planning ensures you start with the right size and only scale when needed.
Newcomers hear 'elasticity' and assume they can ignore initial sizing entirely. This misconception arises from ads that highlight flexibility but rarely mention the cost implications of poor initial choices.
Mistake
More vCPUs always mean better performance.
Correct
More vCPUs improve performance only if the workload is designed to use multiple cores in parallel. Many older applications are single-threaded, meaning they run on only one core. Adding more vCPUs for such workloads does nothing but increase cost.
People equate 'more powerful' with 'more CPUs' because that is how it works in physical computers for most consumer tasks. In cloud computing, software architecture matters more than raw core count.
Mistake
All SSDs are the same — I just pick the cheapest one.
Correct
SSDs come in different performance tiers: general-purpose (GP2/GP3), provisioned IOPS (IO1/IO2), and throughput-optimised (ST1). Each has different price points and performance characteristics. Choosing the wrong type for a database that needs high IOPS will cause slow transactions.
In consumer laptops, there is usually only one SSD type. Beginners do not realise that cloud providers offer specialised storage tiers to match specific workloads.
Mistake
Reserved instances are always cheaper than on-demand, so I should buy them for everything.
Correct
Reserved instances are cheaper only for steady, predictable workloads that run 24/7 for at least one year. For variable workloads, on-demand or spot instances are more cost-effective. Also, reserved instances lock you into a specific instance family and region, reducing flexibility.
The marketing message 'save up to 70%' sounds irresistible, but beginners miss the fine print about commitment length and workload predictability. They assume savings apply universally.
Mistake
If my VM runs at 90% CPU utilisation, it is optimised — that is efficient.
Correct
While 90% utilisation shows you are not wasting capacity, it also leaves very little headroom for unexpected traffic spikes. Best practice is 70-80% utilisation for production workloads, with auto-scaling to handle bursts. Sustained 90% utilisation increases latency and risks application crashes.
People confuse utilisation with efficiency. In cloud computing, you need a buffer for spikes; running at 90% is risky. This misconception comes from on-premise where you try to maximise utilisation because hardware is fixed.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Compute refers to the processing power of virtual machines — the CPUs and RAM that run your applications. Storage refers to the disk space where data is saved permanently, like a hard drive or SSD but accessed over the network.
Start by profiling your application: measure how many users it serves, what each user session consumes in CPU and RAM, and what the peak load looks like. Multiply the per-user consumption by the expected concurrent users, then add a buffer of 20-30% for spikes.
IOPS stands for input/output operations per second. It measures how many read or write operations the storage device can handle per second. Databases need high IOPS to process many small transactions quickly; video files need high throughput instead.
No. Reserved instances save money only for workloads that run continuously for 1-3 years. For unpredictable or short-lived workloads, on-demand or spot instances are more cost-effective because you do not pay for idle time.
A 99.9% SLA allows a maximum of about 8.76 hours of downtime per year. 99.99% allows about 52 minutes per year. Higher SLA percentages require more redundant infrastructure and cost more.
If your application is single-threaded or cannot be distributed across multiple servers, you must scale vertically (larger VM). For stateless web applications that can run on multiple servers, horizontal scaling (more VMs) is better for availability and cost.
You've finished Compute and Storage Resource Planning. Continue through the CV0-004 study guide to build a complete picture of the exam.
Done with this chapter?