Every AWS team has a reflex for quota problems: open the Service Quotas console and file an increase. On Claude Platform on AWS that reflex leads nowhere. Although the platform sits behind an AWS gateway and IAM, rate limits and quotas are managed by Anthropic. AWS handles who may call; Anthropic decides how much.
How the limits are structured
Claude rate limits are measured per model class in three dimensions: requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM). Enforcement uses a token-bucket algorithm — capacity refills continuously rather than resetting on minute boundaries — and exceeding any dimension returns an HTTP 429 with a retry-after header. The specific numbers depend on your organization's usage tier; check your Console's Limits page for your actual values rather than relying on published defaults.
One detail that materially changes capacity math: for most Claude models, ITPM is cache-aware — only uncached input tokens count, and cache_read_input_tokens are excluded. A workload with a long cached system prompt consumes far less of its ITPM budget than raw request sizes suggest, which makes prompt caching a quota tool, not just a cost tool. Also note that rate limits are shared across inference geographies: us and global requests draw from the same pool.
Tiers and how to get more
New Claude Platform on AWS organizations start on the Start tier, the entry level, and — unlike first-party organizations, which can move up automatically over time — they do not change tiers automatically. If launch traffic needs more than Start-tier limits, that is a conversation to start with Anthropic before launch, not a ticket to file during the incident.
Your organization's tier and current limits are visible in the Claude Console, which you reach through AWS Console federation ("Open Claude Console", requiring the aws-external-anthropic:AssumeConsole IAM action). The Console's Usage, Cost, and Limits pages read organization metadata directly from Anthropic. The Limits page offers a rate-limit increase request path; raising limits for this platform ultimately goes through Anthropic, so for substantial increases contact your Anthropic representative with a concrete traffic model — target RPM and tokens per minute per model, expected growth, and dates.
Designing headroom into your traffic model
Measure in the platform's units. "Requests per second" is not enough; token volume is usually the binding constraint. Estimate input tokens per request (the count_tokens endpoint helps — see below), output tokens per request, and peak-minute request counts. Multiply out to peak RPM, ITPM (uncached), and OTPM per model.
Leave real margin. Size limits against your peak minute, not your average, and keep meaningful headroom above the forecast peak — traffic models are always wrong in the exciting direction. If your observed peak regularly exceeds a comfortable fraction of your limit, start the increase conversation then, while it's still boring.
Smooth what you can. Interactive traffic must be served on demand, but background work — evaluations, enrichment, reprocessing — can be paced. Queue it, cap its concurrency, and let it soak up whatever headroom interactive traffic leaves. Anthropic's Message Batches API is available on this platform and is the natural home for anything that tolerates asynchronous completion.
Degrade deliberately. Decide in advance what happens at the limit: which traffic gets shed, which gets queued, and whether high-priority traffic fails over. Claude Platform on AWS uses a separate capacity pool from both the first-party API and Amazon Bedrock, and workloads can run on multiple platforms and fail over between them — worth designing in if you have strict availability targets.
Respect the signals. Honor retry-after on 429s and treat sustained 429s as a capacity-planning alarm, not an error to retry harder. Also remember quotas and usage roll up per workspace, so a noisy experiment in a production workspace competes with production traffic — separate them.
Where to go next
Pair this with error codes and retries for the runtime half, multi-workspace strategy for isolation, and token counting for building the traffic model.