A pipeline writes 200 million objects a day and the security review requires per-object encryption with a managed key service. Roughly how many calls to that service does the naive design make, what does it cost, and what changes the answer by two orders of magnitude?

The assumptions, stated

Naive per-object envelope encryption generates a fresh data key per object: one call to the key service for every write, and one decrypt call for every read of an object whose key is not already in hand. Assume reads are twice writes. Managed key services charge per request in the region of a few dollars per million requests, and enforce per-account request quotas in the low tens of thousands per second for cryptographic operations. Treat both as 2024-era orders of magnitude and check current pricing before quoting them.

The arithmetic

• Writes: 200 million calls a day, which is roughly 2300 calls per second averaged, and with a typical peak-to-average ratio of 3 to 5 it is 7000 to 12000 per second at peak.
• Reads: another 400 million a day, so the total is around 600 million calls a day, roughly 7000 per second average and 20000 to 35000 at peak.
• Cost: at a few dollars per million requests, 600 million a day is several hundred thousand dollars a year in key-service requests alone, carrying no data and doing no work beyond wrapping 32 bytes.
• Quota: the peak figure is at or above the default account limits, so the pipeline throttles, retries, and amplifies its own load.

The number, and what changes it

Roughly 600 million calls a day, a six-figure annual bill, and a throttling problem. Data key caching changes it by two orders of magnitude. Generate one data key, use it to encrypt many objects, and call the key service again only when a cache limit is reached. With a key reused across 1000 objects, calls fall to about 600000 a day and the cost to the low thousands.

The dominant term in the estimate is therefore not object count or price; it is the reuse factor, which is a policy decision: how many objects and how many bytes may share a data key, and for how long.

What the number rules in and out

It rules out per-object keys at this volume unless there is a specific requirement for them, such as per-tenant cryptographic isolation where the blast radius of one key is contractually bounded. It rules in caching with explicit limits on messages per key, bytes per key and key age, and it forces a decision the review should have asked for: what exactly is the key boundary meant to isolate?

The trade-off being made

Reuse widens blast radius. One compromised cached data key exposes every object encrypted under it, so the reuse factor is a direct dial between cost and exposure. A sensible default is a few thousand objects or a few hundred megabytes per key with a lifetime of minutes, tightened to per-tenant keys where the isolation has to be provable.

Caching also means plaintext data keys live in process memory for their lifetime, which is a real change to the threat model and the reason key lifetimes are measured in minutes rather than days.

When per-object keys are the right answer

When the requirement is per-record cryptographic deletion, or per-tenant isolation that must survive a compromise of another tenant's key. Then the cost is the requirement, and the design question becomes how to lower the object rate hitting the key service, usually by encrypting at a coarser granularity such as per tenant per day.

When not to use envelope encryption at all

If the realistic threat is a lost disk or a stray snapshot, volume-level encryption with a single managed key meets it at zero request cost, and the envelope design buys nothing but a bill. The escalation to envelope encryption is justified by a caller-level authorisation requirement or a per-tenant isolation requirement, not by the general idea that more encryption is better.