Use this cloud app capacity planning worksheet to turn expected traffic, storage, and workload behavior into a practical starting point for infrastructure sizing. It includes repeatable formulas for compute, memory, database connections, bandwidth, queues, caches, and safety headroom, so you can recalculate requirements before a launch, campaign, feature release, or monthly review.
Overview
Capacity planning is the process of estimating how much infrastructure an application needs under normal and increased usage. It is not a one-time exercise and it is not an attempt to predict usage perfectly. The goal is to make assumptions visible, test them against observed data, and define the conditions that should trigger a scaling decision.
A useful plan covers more than server size. A web application may be limited by CPU, memory, database connections, storage, network bandwidth, a queue, a third-party API, or a provider quota. A deployment that appears comfortable at the application layer can still fail if the database connection pool is exhausted or a background queue grows faster than workers can process it.
Use the worksheet below for a first estimate, then replace assumptions with measurements from logs, metrics, load tests, and production usage. If you are choosing between deployment models, compare the operational trade-offs in Serverless Functions vs Containers. For ongoing visibility, see the guide to application monitoring tools.
How to estimate
Start with a planning horizon, such as the next launch, quarter, or expected growth milestone. Create a low, expected, and peak scenario instead of relying on a single number. Then calculate each resource separately.
- Estimate traffic. Record expected requests per second (RPS), peak RPS, active users, and the percentage of traffic that reaches dynamic application code. Cached or static requests may have a different resource profile from authenticated requests.
- Measure work per request. Identify average and high-percentile response time, CPU time, memory use, database queries, outbound calls, and response size. A request that performs several database operations may require more capacity than a simple page request even at the same RPS.
- Translate traffic into capacity. A basic starting formula is:
required application instances = peak requests per second / sustainable requests per second per instance. Round up, then add headroom rather than operating at the measured limit. - Check dependencies. Repeat the exercise for the database, cache, queue, object storage, search service, and external APIs. The smallest practical limit often determines the effective capacity of the whole system.
- Validate with a test. Use a representative workload and monitor latency, errors, CPU, memory, database saturation, queue depth, and connection usage. A capacity estimate becomes more useful when it includes the conditions under which it was measured.
For a simple worksheet, use these columns: resource, current usage, expected peak, measured limit, headroom target, planned capacity, and scale trigger. Keep the calculation in a shared document or version-controlled repository so assumptions can be reviewed alongside application changes.
Inputs and assumptions
Traffic and concurrency
Record average requests per second, peak requests per second, requests per user action, and the expected duration of a session or long-running operation. Concurrent users are not the same as requests per second: a user may be idle, make several requests quickly, or hold a connection open. For real-time features, separately count concurrent connections and messages per second.
Compute and memory
Measure CPU and memory for representative requests rather than assigning capacity from user count alone. A practical estimate is:
planned compute = measured peak compute / target utilization
The target utilization should leave room for bursts, deployment activity, uneven traffic, and background work. Choose a margin deliberately and record it as an assumption; the right value depends on workload variability, scaling speed, and the consequences of saturation.
Database and connection limits
List database operations per request, average query duration, read-to-write ratio, storage size, index growth, and maximum connections. Estimate connections from application instances and pool settings, not just from active users:
potential connections = application instances × connections per instance
Leave capacity for administrative access, migrations, monitoring, and other services. Review slow queries and lock behavior during testing because a database can become constrained before its storage is full.
Storage, bandwidth, queues, and caches
- Storage: estimate current data, daily growth, upload volume, generated files, backups, retention, and temporary files. Include metadata and replication or backup requirements where applicable.
- Bandwidth: calculate requests per second multiplied by average response size, then add uploads, downloads, internal transfers, and protocol overhead.
- Queues: track jobs per second, average processing time, worker throughput, maximum acceptable delay, and retry volume. A queue is under pressure when arrival rate repeatedly exceeds processing rate.
- Cache: estimate the size of hot data, item expiration, eviction behavior, and the effect of a cache miss on the database. A cache can reduce database work but also create a burst when many items expire together.
Check provider-specific quotas, instance specifications, managed-service limits, and pricing units before committing to an architecture. These values change, so treat them as inputs to verify rather than permanent facts.
Worked examples
Assume a small SaaS application expects 20 requests per second during its busiest normal period and has measured a sustainable rate of 8 requests per second per application instance under a representative test. The minimum estimate is:
20 / 8 = 2.5
Round up to three instances before applying the chosen headroom policy. If a launch scenario is expected to reach 40 requests per second, repeat the calculation rather than doubling every resource automatically. The workload may scale unevenly: web requests could double while database writes rise more slowly, or an expensive reporting endpoint could dominate CPU.
For storage, suppose the application adds 12 GB of user uploads and generated files each month. A 12-month planning horizon gives a simple growth estimate of:
12 GB × 12 months = 144 GB
Add the current dataset, temporary workspace, retention requirements, and any backup or replication allowance. If users can upload unusually large files, include a peak-day scenario rather than using only the monthly average.
For a background email queue, assume 30 jobs arrive per minute during a campaign and one worker processes 10 jobs per minute. Three workers match the arrival rate mathematically, but that leaves no room for retries, pauses, or uneven processing time. The plan should either add workers, reduce job duration, schedule the campaign in stages, or define a queue-depth alert and an acceptable delay.
These examples are planning illustrations, not universal sizing rules. Validate each result with your application’s own workload. If a release does not behave as expected, keep a rollback procedure ready; the cloud app rollback runbook provides a related checklist.
When to recalculate
Revisit the worksheet whenever an input changes materially. The most useful checkpoints are before a public launch, paid campaign, seasonal event, major feature release, database migration, pricing change, or infrastructure move. Recalculate after a sustained change in active users, request volume, response size, storage growth, or background-job volume.
Also review the plan after an incident or unexpected latency increase. Ask which resource reached its limit first, whether the measured limit still reflects the current code, and whether the scaling trigger acted early enough. Update the worksheet when provider quotas, instance specifications, managed-service limits, or pricing units change. Do not copy old capacity assumptions into a new environment without checking them.
As a practical monthly routine:
- Export recent peak and average metrics for traffic, latency, errors, CPU, memory, connections, storage, bandwidth, and queue depth.
- Compare actual values with the low, expected, and peak scenarios.
- Run a focused load test after major code or database changes.
- Record the next scaling trigger, owner, and action in the worksheet.
- Recheck provider limits and cost inputs before approving a capacity increase.
Capacity planning works best as a living part of the build-and-deploy workflow. Keep the assumptions close to monitoring and release documentation, and use measured behavior to replace estimates over time.
