AWS / Advanced: reliability, security, and governance / Lesson 16

Performance, capacity, and unit cost

Choose efficient service and data patterns from measured bottlenecks while protecting latency, correctness, and financial boundaries.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain the assumptions, responsibilities, and trade-offs of performance, capacity, and unit cost.
Interpret both examples and distinguish declared intent from verified evidence.
Diagnose the listed failures and justify the worked decisions without using a real AWS account, credential, or service.

Define useful work before benchmarking

Performance needs a workload, input distribution, correctness rule, and observation window. Requests per second alone can hide long-tail latency, retries, data errors, or a failing customer cohort. Identify where time is spent: connection acquisition, network, initialization, CPU, storage, locks, or queues. Service instance names and marketing throughput are not measurements of this application. The first synthetic record names an end-to-end target and separates server work from waiting. No benchmark or load test is executed. Use approved representative evidence before changing a cloud service, storage mode, or expensive purchasing commitment.

yaml Synthetic performance decision record

journey: synthetic-booking-read
measurement: end-to-end-latency-distribution
correctness: authorized-current-enough-response
known_wait: separately-measured-dependency-time
optimization_hypothesis: remove-repeated-approved-work
financial_scope: no-current-price-assumption

The record defines questions and no measured production result. Freshness and authorization constrain any cache or storage optimization.

Match data access to the service contract

Relational transactions, object storage, key-value access, search, and caching solve different problems. RDS query design and indexing differ from DynamoDB key and access-pattern design; moving to a managed or on-demand mode does not eliminate data-model responsibility. Confirm consistency, transaction scope, partition or hot-key behavior, quotas, and current capacity modes for the chosen service. A cache changes freshness, authorization, and memory or storage assumptions. Do not put user-specific responses under a shared public cache key. A faster read is not a valid optimization when it exposes another tenant’s data or returns an incorrect business state.

Account for concurrency and queueing

Under a stable measured boundary, arrival rate multiplied by average time can help interpret average work present. The second simulation uses fixed fictional values and does not determine a safe worker count. Bursts, tail behavior, dependency contention, cold starts, and scaling delay remain separate questions. More parallelism can increase lock contention, database connections, or upstream throttling. Apply bounded admission, time budgets, and explicit overload behavior before unbounded scale-out. Service quotas and provider capacity constrain the plan, while retry policies can amplify apparent demand and unit cost without producing more useful operations.

python Harmless concurrency arithmetic

fictional_arrivals_per_second = 100
fictional_average_seconds = 0.2
print(fictional_arrivals_per_second * fictional_average_seconds)
print("stable average model; not a capacity or cost guarantee")

Expected output

20.0
stable average model; not a capacity or cost guarantee

The model has average work present twenty under its fictional stable assumptions. It does not establish a maximum, tail latency, safe connection pool, or AWS service price.

Use cost per useful outcome carefully

Include compute, storage, requests, transfer, network paths, telemetry, redundancy, backup, and shared allocation under a declared accounting scope. Cost per successful operation can worsen when failures rise even if spending stays flat. Current AWS prices, discounts, agreements, taxes, and promotional terms are not modeled in this course. Rightsizing, storage-class changes, caching, and commitments each carry correctness or recovery risks. A cheaper retention policy can violate recovery needs, and removing idle headroom can make a failure or rollout impossible. Evaluate efficiency against reliability, security, and data obligations rather than the smallest headline price.

Run controlled decisions, not uncontrolled experiments

A proposed optimization should name hypothesis, affected contract, expected benefit, measurement, stop condition, and rollback or forward-repair path. Compare equivalent workloads and include setup, initialization, variability, and failure behavior. Verify correctness independently of timing. Actual provider benchmarking and financial review require explicit authorization and bounded environments; none occur here. The offline arithmetic contacts no endpoint, reads no bill, and creates no resource. Keep the simpler design when evidence shows little benefit or when new invalidation, coordination, and recovery rules create more risk than the improvement justifies.

Common errors and fixes

A cache mixes users or tenants

Why it happens: Authorization scope was absent from cache design.
How to fix it: Use reviewed keys, access, freshness, and invalidation contracts.
Prevent it next time: Test cross-user exclusion and stale-state behavior.

More concurrency worsens latency

Why it happens: The bottleneck is a shared dependency or contention.
How to fix it: Measure and bound downstream demand.
Prevent it next time: Separate waiting and useful execution metrics.

Cheaper resources weaken recovery

Why it happens: Efficiency review omitted reliability and data constraints.
How to fix it: Restore required safeguards and reassess unit economics.
Prevent it next time: Link optimization approval to SLO and recovery evidence.

Check your understanding

1. At a stable 200 operations per second and average 0.15 seconds inside the boundary, what average work is present?

Show worked solution

The average is thirty operations in that same boundary. It is not a safe maximum or proof of burst tolerance. Confirm units and stable flow and examine tail latency, resource contention, and dependencies before using it in a capacity decision.

2. Spending is unchanged but useful successful operations halve. What happens to unit cost?