Numbers to Know

Capacity numbers help reject impossible designs and choose something worth testing. A disk's provisioned IOPS, a server's network baseline and an application's measured requests/s answer different questions. Treating them as interchangeable produces confident estimates with no connection to the bottleneck.

Specifications checked: 2026-11-08. Every workload below is a planning assumption; none is a benchmark result. The local examples need Python 3.11+ with no additional packages. Download the complete capacity lab, extract it, and run python3 capacity.py and python3 -m unittest -v test_capacity.py from its directory. AWS commands are optional inspection templates requiring AWS CLI v2, appropriate read permissions and explicit resource values. No cloud account is needed for the lab.

Read the unit before the headline

Label a number before using it: a named model's capability, a published service limit, a sustained baseline or temporary burst, a measurement under stated conditions, or an assumed design budget. A vCPU allocation does not predict requests/s, and a quota increase does not remove a hot key.

Use decimal units for network rates and binary units when specified for memory or storage: 1 Gbit/s is 125 MB/s before protocol overhead; 125 MiB/s is 131.072 MB/s. A vCPU is not universally a physical core. Inspect architecture and threads/core; CPU seconds/request means processor time consumed, including parallel CPU work, rather than elapsed request time.

For storage, operations and bytes impose separate bounds. Assuming uniform I/O sizes, this calculation takes the tightest of the volume's operation limit, volume bandwidth and an explicitly supplied instance bandwidth budget:

def io_ceiling(iops, block_kib, volume_mib_s, instance_mib_s):
    return min(iops,
               volume_mib_s * 1024 / block_kib,
               instance_mib_s * 1024 / block_kib)

assert io_ceiling(3000, 16, 125, 1000) == 3000
assert io_ceiling(3000, 256, 125, 1000) == 500
assert io_ceiling(3000, 256, 125, 100) == 400
# 16-KiB I/O: 46.875 MiB/s. 256-KiB I/O: bandwidth binds first.

The 1,000 and 100 MiB/s instance budgets here are assumed inputs. This is an upper bound: queue depth, synchronization, filesystem overhead and actual device latency may prevent reaching it. Database operations also cause varying numbers of physical I/Os; 500 storage IOPS does not mean 500 SQL queries/s. Storage explains the interfaces and database models; here the useful skill is matching quantities with their units.

A dated reference card

These selected capabilities give estimates scale without inventing universal RAM, SSD or network latencies. The models are examples, not claims about the newest or largest available hardware.

Fargate Linux supports ARM64 and X86_64, while Windows requires X86_64. Availability still needs checking for the chosen Region, AZ and platform. In particular, the ARM64 guide excludes the stable AZ ID use1-az3; account-specific AZ names are not portable identifiers. Validate container images, native dependencies and database extensions for the selected architecture.

The lab checks gp3's size and performance ratios, including accepting 160 GiB/80,000 IOPS/2,000 MiB/s and rejecting the same IOPS at 159 GiB. A valid volume combination still needs a suitable attachment and location. Do not transfer EC2 gp3 limits directly to RDS.

Three workloads worth testing

Derive demand before naming a configuration. All three candidates assume us-east-1, one backing operation for each cache miss or write, and a CPU target of 50%. Requests/user/day count requests reaching the application after any CDN. Read hits below describe an application cache. Response bytes exclude headers, retries and replication. The next lesson, Back-of-the-Envelope Calculations, develops demand estimation in more depth.

This executable calculation shows why replica counts belong in the budget. The B candidate has four 4-vCPU tasks, two in each AZ:

peak_rps = 100_000 * 50 / 86_400 * 8
backing_reads_s = peak_rps * .90 * (1 - .90)
writes_s = peak_rps * .10
cpu_seconds_s = peak_rps * .008
vcpu_budget = cpu_seconds_s / .50
surviving_vcpu = (4 - 2) * 4
assert round(vcpu_budget, 2) == 7.41
assert round(cpu_seconds_s / surviving_vcpu * 100, 1) == 46.3
# Cold cache raises B's backing reads from 41.7/s to 416.7/s.

The same model produces these candidate configurations:

For all three, include a replicated cache with at least the stated usable working-set capacity after AZ loss; choose its topology from measured entry overhead, replication behavior and failover needs. These are candidate budgets, not provisioned deployments. A/B assume an orderable supported PostgreSQL version. Their standby provides availability, not extra read throughput; failover interrupts connections. Database memory also serves the engine, connections and maintenance, so a hot set fitting on paper needs measurement.

C assumes whole items ≤1 KiB, including attribute names, eventual nontransactional reads, no secondary indexes and well-distributed keys. Its 8-KiB response includes application-generated content; it does not imply an 8-KiB stored item. Its demand is about 156.25 read units/s and 694.44 write units/s. A 1,025-byte item doubles write units; a 4,097-byte item doubles eventual read units compared with a ≤4-KiB item. DynamoDB's documentation uses binary “KB.” Aggregate response bandwidth is about 455 Mbit/s before overhead.

CPU is only one admission test. Assume B allows 100 live requests/task, 2 MiB extra memory/request and 2,048 MiB baseline process memory. That totals 2,248 MiB within an 8,192-MiB task budget; caches, sidecars and allocator peaks still need accounting. Separately, an assumed database connection budget of 100 with 20 reserved permits four pools of 20, but a rollout surge to six tasks exceeds it:

available_connections = 100 - 20
assert 4 * 20 <= available_connections
assert 6 * 20 > available_connections
# Reduce pool sizes, bound rollout concurrency, or add a measured pooling layer.

The fixture rejects invalid inputs and tests cold cache, one-AZ loss, item rounding, memory exhaustion and rollout pool overflow. Its CPU calculation assumes balanced traffic and unchanged CPU cost. Losing an AZ can change cache hits and database work, so these replica counts alone do not establish availability.

Inspect the candidate, then measure it

The optional inspect-aws.sh contains read-only EC2, RDS, ECS and quota inspections. Set the Region and resource identifiers explicitly. For example, this command checks a model's actual published processor, network and EBS fields rather than treating “up to” as a baseline:

aws ec2 describe-instance-types --region us-east-1 \
  --instance-types m7g.large m7g.xlarge m8g.48xlarge \
  --query 'InstanceTypes[].{Type:InstanceType,vCPU:VCpuInfo.DefaultVCpus,Cores:VCpuInfo.DefaultCores,Threads:VCpuInfo.DefaultThreadsPerCore,MiB:MemoryInfo.SizeInMiB,Network:NetworkInfo.NetworkCards,EBS:EbsInfo.EbsOptimizedInfo}'

Inspect RDS orderability for the exact engine version/class; an empty result invalidates that choice. Check task definition CPU/memory/architecture and ECS service deployment platform separately. Quotas describe account permissions to scale, not capacity already running. These commands were checked against CLI documentation and syntax-checked; no account inspection was performed for this lesson.

For each candidate, test peak load, cold cache, a sustained soak and one-AZ loss in an isolated environment. An example acceptance budget is p95 ≤150 ms, p99 ≤300 ms and errors <0.1%; these are chosen goals. Record instance/task, architecture, runtime, endpoint mix, payload, cache hit rate, working set, concurrency, disk block size/queue depth, warmup, duration and sample count. Report offered/completed requests/s, failures and timeouts, endpoint p50/p95/p99, CPU seconds/request, RSS, database waits and storage latency. Never average percentiles or omit failed requests.

Run beyond a short burst window, and ensure the load generator is not saturated. Network/EBS allowances, connection waits and queue growth can explain poor tail latency despite spare CPU. T-family alternatives also require CPU-credit mode and surplus-charge analysis. Start with a falsifiable prediction—“B's cold cache saturates database storage”—then inspect waits, IOPS and latency to see whether it survives the test. Revise the candidate using that evidence.