Claude Platform on AWS is Anthropic-operated: the models run on Anthropic-managed infrastructure while AWS provides authentication, IAM-based access control, and billing through AWS Marketplace. That split matters for capacity planning, because rate limits and quotas are managed by Anthropic — not by AWS Service Quotas, the console page where AWS-native teams instinctively look. There is nothing to raise in the AWS console; the quota conversation happens with Anthropic.
The Start tier, and why you don't leave it automatically
The platform uses the same rate-limit schedule as the first-party Claude API, where limits are defined per usage tier (Start, Build, Scale, Custom) and enforced per model as requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM). On the first-party API, organizations move up tiers automatically over time as usage grows. On Claude Platform on AWS, the documentation is explicit: new organizations start on the Start tier and there is no automatic tier movement. To raise limits, you contact Anthropic.
For reference, the documented Start-tier Messages API limits look like this:
| Model class | RPM | ITPM | OTPM |
|---|---|---|---|
| Opus 4.x / Sonnet 5 / Sonnet 4.x / Haiku 4.5 | 1,000 | 2,000,000 | 400,000 |
| Claude Fable 5 | 1,000 | 500,000 | 100,000 |
Those are generous numbers for pilots and mid-size production workloads, but a high-throughput system that would have grown into Build or Scale limits organically on the first-party API will instead hit a hard ceiling here. Plan the Anthropic conversation before launch, not during the incident.
Other quota tooling that is absent
Two adjacent controls from the first-party Console are also unavailable on Claude Platform on AWS: spend limits (rely on AWS billing controls instead) and per-workspace rate-limit configuration. The programmatic Usage and Cost API endpoints are not available either — usage and cost data live on the Usage and Cost pages of the Claude Console, which for this platform is accessed through AWS IAM federation. The Console's Usage page does show rate-limit telemetry, including counts of rate-limited requests and hourly peak ITPM, which is how you establish whether you are approaching the Start-tier ceiling.
Stretching the tier you have
Before requesting an increase, check how much of the Start tier you are actually using effectively:
Prompt caching multiplies ITPM. ITPM accounting is cache-aware on most models: uncached input tokens and cache writes count, cache reads do not. A workload with a high cache hit rate can process several times its nominal ITPM in total input — the cache-read exclusion article works the numbers.
OTPM counts real output only. The max_tokens value does not factor into OTPM, so setting it generously has no rate-limit cost.
The capacity pool is separate. Claude Platform on AWS draws on a different capacity pool from both the first-party API and Amazon Bedrock, and Anthropic documents that workloads can run on multiple platforms and fail over between them. For burst capacity beyond a fixed tier, a multi-platform failover design is a legitimate lever — see the Platform-on-AWS vs Bedrock decision guide.
Handling the 429s themselves works as on the first-party API: the platform uses the same rate-limit schedule and exposes the Claude API surface directly, the response names the exceeded limit, and the official SDKs — including the platform's AnthropicAWS client — retry retryable errors with exponential backoff automatically. What changes on this platform is not the error handling but the escalation path when backoff is no longer enough.
Where to go next
For the platform's overall architecture, authentication, and feature parity, read the Claude Platform on AWS deep dive; for day-to-day quota monitoring, quota management on Claude Platform on AWS.