Infrastructure requirements: platform, data residency, ZDR and capacity

1.Choosing the platform from the customer's cloud

Infrastructure requirements usually start with where the customer already runs. If a company has AWS billing, IAM and CloudTrail auditing in place, it will want Claude on that cloud, not a new vendor relationship. Each platform bills through its own cloud and plugs into that cloud's identity and audit tools.

The two AWS rows look alike but have different operators, and that matters for compliance. Bedrock is AWS-operated. Claude Platform on AWS is Anthropic-operated and runs on AWS. Google Cloud is Google-operated, and Microsoft Foundry is Anthropic-operated on Azure. The operator decides whose retention and residency controls apply: on Bedrock and Google Cloud, the cloud provider is the data processor, so Anthropic's own controls described below don't apply there.

Sources12

2.Data residency: where inference runs and where data rests

A requirement like "inference must run in the United States" maps to two independent settings. Inference geo controls where model inference runs. You set it per request with the inference_geo parameter or as a workspace default. Workspace geo controls where data is stored at rest and where endpoint processing such as code execution happens. You choose it when you create a workspace and can't change it later. Currently "us" is the only workspace geo, and inference_geo accepts only "us" or "global", which is the default.

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
     ? ="us",
    messages=[
        {"role": "user", "content": "Summarize the key points of this document."}
    ],
)

Leaving the parameter in every request's code is not enough if a regulator needs the rule enforced. At the workspace level, allowed_inference_geos rejects any request that asks for a geo outside the list, and default_inference_geo applies when a request leaves the parameter out. Set both to "us" and every key in the workspace is held to US inference. You can confirm where a given request ran from its usage object:

{
  "usage": {
    "input_tokens": 25,
    "output_tokens": 150,
    "inference_geo": "us"
  }
}

US residency affects model choice and budget. inference_geo works only on Claude 4.6 and later models. On Haiku 4.5, the parameter returns a 400 error, so a US-only requirement removes it from the candidates. On supported models, US-only inference costs 1.1x the standard rate. That multiplier applies on the Claude API and Claude Platform on AWS. Bedrock and Google Cloud have their own regional pricing. Rate limits are shared across all geos, so moving traffic to "us" does not give you extra capacity.

Sources3

3.Zero Data Retention: what it covers and what breaks it

Zero Data Retention (ZDR) is the answer when a requirement says the vendor must not keep prompts or outputs. Without ZDR, the API deletes inputs and outputs within 30 days. With it, customer data isn't stored at rest once the API response is returned. ZDR is a contractual arrangement, not a request flag. It is enabled per organization, and a new organization under the same account doesn't inherit it.

ZDR has two exceptions. First, even under ZDR, Anthropic may keep data where the law requires it. If automated trust and safety systems flag a chat or session, inputs and outputs may be kept for up to 2 years. Second, ZDR covers only eligible features, and an ineligible feature isn't blocked. If a request uses one, that data falls outside the arrangement without any error.

For an architect, the rule is to design the solution around stateless Messages API calls and leave out stateful features. A ZDR customer also loses some cost options. The Batch API's 50% discount, for example, requires asynchronous storage. ZDR also limits model choice, through a designation called Covered Models. A Covered Model is one for which Anthropic requires limited data retention and review as part of its safety work, so it can't run under zero retention. Claude Fable 5.1 is one. Unless Anthropic has expressly authorized it for your organization, a request to a Covered Model from a zero-retention workspace fails with the error "In order to access this model, your organization or Workspace must have data retention enabled." The fix is to turn on 30-day data retention for a workspace, which an organization Admin or Owner can do under the workspace's Privacy controls in the Console; it applies to that workspace only and isn't retroactive. Check whether a model is Covered before promising ZDR alongside it. Finally, ZDR applies only where Anthropic is the data processor. It is available on the Claude API and, on request, on Claude Platform on AWS. On Bedrock and Google Cloud, use that provider's retention controls.

Sources245

4.Sizing capacity: rate limits, spend limits and Priority Tier

Expected volume is also a requirement, and it maps to limits that apply to the whole organization. Messages API rate limits are measured in requests per minute (RPM), input tokens per minute (ITPM) and output tokens per minute (OTPM). Each model has its own limits. Going over any of them returns a 429 with a retry-after header. Most current models allow 1,000 RPM, 2,000,000 ITPM and 400,000 OTPM. Claude Fable 5.x allows only 500,000 ITPM and 100,000 OTPM, so a high-throughput requirement can rule it out even when it would win on quality.

Two details change the sizing calculation. First, prompt caching lets you reuse repeated content, such as system instructions, tool definitions and large documents, across requests. The part of a request served from that cache is reported as cache_read_input_tokens, and for most models those cache reads don't count toward ITPM. With a 2,000,000 ITPM limit and an 80% cache hit rate, you can process about 10,000,000 input tokens per minute. Second, max_tokens doesn't count toward OTPM; only tokens actually generated do. One thing doesn't change: every limit is a ceiling, not a promise of capacity.

Limits and spend caps both come from the organization's usage tier. Anthropic places an organization on a tier automatically, based on usage history and account standing, and the organization can move to a higher tier over time as it uses the API. New organizations and those with little history may start in an Evaluation tier with limits below the standard ones, which rise automatically as history builds. The Console's Rate limits page shows your tier and current limits, and higher limits can be requested.

Spend caps fail differently from rate limits. When an organization reaches its tier's cap, usage pauses until 00:00 UTC on the first day of the next month. Requests return a 429 with error code enforced_spend_limit_reached and no retry-after header, so automatic retries keep failing. A spend limit you set yourself below the cap returns HTTP 400 instead. Budget the tier to cover peak months, not average months.

For a requirement of guaranteed throughput, use Priority Tier. It is available only with a capacity commitment: input and output tokens per minute, a term of 1, 3, 6 or 12 months, and a specific model version. Priority requests are served ahead of all other traffic, Priority Tier targets 99.5% uptime, and requests beyond the commitment fall back to standard tier. It isn't offered on Claude Fable 5.1, Opus 5.5, Opus 5, Sonnet 5.5 or Sonnet 5. A requirement for both guaranteed throughput and one of those models is a conflict you have to resolve, either by changing the model or by relaxing the guarantee.

Sources678

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Under ZDR, Anthropic never retains anything from the customer's traffic.Why is that wrong?

   Data may still be kept where the law requires it, or for up to 2 years if trust and safety systems flag it. Ineligible features such as the Batch API also keep data under their own policies.

   Covered in Zero Data Retention: what it covers and what breaks it

2. 2.Your tier's published rate limits guarantee that much capacity.Why is that wrong?

   Rate limits are ceilings. Prioritized capacity requires a Priority Tier commitment.

   Covered in Sizing capacity: rate limits, spend limits and Priority Tier

3. 3.Setting inference_geo to "us" adds US capacity alongside global capacity.Why is that wrong?

   Rate limits are shared across all geos, so US-only traffic counts against the same limits.

   Covered in Data residency: where inference runs and where data rests

Practise it for real

Verify that a request runs on US-only inference and see what happens on an unsupported model

1. 1.Send a Messages API request to claude-opus-5-5 with inference_geo="us"

   Why: The per-request parameter is the most direct way to meet a US inference requirement

   You should see: A normal response

2. 2.Print response.usage.inference_geo

   Why: The usage object records where inference actually ran, which gives you evidence for an audit

   You should see: The value "us"

3. 3.Repeat the request with model claude-haiku-4-5 and the same inference_geo

   Why: Shows that a residency requirement can remove a model from the candidates

   You should see: A 400 error, because Haiku 4.5 predates Claude 4.6