Don't Let Bedrock Throttle You: Tracking Per-Account Quotas Before It's Too Late
Article covers how to automatically track per-model Tokens Per Minute (TPM) and Requests Per Minute (RPM) Bedrock quotas
The Hidden Problem: Every Account Has Its Own Limits
Amazon Bedrock enforces Tokens Per Minute (TPM) and Requests Per Minute (RPM) quotas at the individual account and region level. These aren't global numbers you can look up once — they're specific to each account, often differ from documentation defaults (especially after quota increases), and vary by region.
When your organization runs Bedrock workloads across multiple accounts and regions, you're flying blind:
- There's no native cross-account view of which models are approaching their throttling limits
- Each account may have different quotas for the same model (one account got an increase, another didn't)
- By the time you hit a
ThrottlingException, it's already too late — requests are being dropped
This creates a real operational risk. A model that was comfortably within limits last week can start throttling today because a new feature increased token volume, a batch job kicked in, or traffic simply grew.
Why 70–75% Is Your Action Threshold
Waiting until you're at 90% utilization leaves almost no time to react. At that point, throttling is seconds away and your options are limited to "hope traffic drops."
Setting alerts at 70–75% utilization gives you a meaningful window to take action:
At 70% (Warning)
- Start planning capacity expansion
- Review whether traffic patterns are trending up or if this is a temporary spike
- Identify which regions have headroom for overflow
At 75% (Action Required)
- Request a quota increase through Service Quotas (can take hours to days)
- Spin up a cross-region inference profile to effectively double capacity (cross-region profiles route across multiple regions, giving you 2x the effective quota)
- Shift traffic to an alternate region where the same model has available capacity
- Enable a fallback model with similar capabilities
The key insight: all of these mitigation steps take time. Quota increases aren't instant. Deploying new inference profiles requires testing. Re-routing traffic needs configuration changes. You need that 70–75% early warning to execute these steps before users experience failures.
The Solution: Centralized Multi-Account Quota Monitoring
I built Bedrock Limits Tracker — a solution that continuously monitors Bedrock quota utilization across all your accounts and regions, publishing everything to a single CloudWatch dashboard with real-time alerting.
How It Works
The architecture uses a hub-and-spoke model:
- Reads actual per-account quotas from the Service Quotas API in each spoke account — not documentation defaults, but the real numbers including any increases you've been granted
- Reads live usage from CloudWatch
AWS/Bedrockmetrics (Invocations, InputTokenCount, OutputTokenCount) - Computes utilization percentage —
usage / effective_quota × 100— with automatic 2x multiplier for cross-region inference profiles that route across multiple regions - Publishes to a centralized dashboard with Red/Amber/Green status per model
- Triggers CloudWatch Alarms when utilization crosses your configured threshold
Status Indicators at a Glance
| Status | Condition | What To Do |
|---|---|---|
| 🔴 RED | > 90% | Throttling imminent — activate fallback immediately |
| 🟠 AMBER | > 70% | Take action — provision capacity or shift traffic |
| 🟢 GREEN | ≤ 70% | Healthy — no action needed |
| 🔵 NOT_USED | 0% | No recent invocations |
Real-Time + Periodic: Two Layers of Visibility
The dashboard provides two complementary views:
- Metrics Insights charts update every 60 seconds natively — you see traffic spikes as they happen, with no Lambda in the loop
- Per-account utilization tables update on your configured schedule (default: every 60 minutes) showing peak usage, quota limits, and percentage utilization per model
This means you get immediate visibility into traffic patterns (is this a spike or sustained growth?) alongside the computed utilization percentages that drive alerting.
Deployment: No Management Account Required
A key design decision: this solution does not require the AWS Organizations management/payer account. It uses:
- SELF_MANAGED StackSets — no Organizations API needed
- Explicit account IDs — no org-wide trust required
- OAM (CloudWatch Observability Access Manager) — for free cross-account metric sharing
You can deploy the monitoring hub in any account — a dedicated observability account, the payer, or any linked account that the spoke roles trust.
Runtime Architecture
At runtime, the Lambda in the monitoring account assumes a role in each spoke account to read quotas and compute utilization. Meanwhile, OAM Links continuously stream native Bedrock metrics to the monitoring account for free — these power the real-time Metrics Insights charts.
What Gets Deployed
In the monitoring account:
- OAM Sink (receives metrics from spoke accounts)
- Lambda function (quota collector + dashboard publisher)
- CloudWatch Dashboard with Metrics Insights queries
- CloudWatch Alarms → SNS → Email notifications
- S3 bucket for quota caching (24-hour TTL)
In each spoke account:
- OAM Link (shares AWS/Bedrock metrics to the sink — free)
- IAM Role (allows the monitoring Lambda to read quotas and usage)
The Alerting Pipeline
When utilization crosses your threshold:
- Lambda computes
usage / quota × 100for each model in each account/region - Publishes custom CloudWatch metrics with the utilization percentage
- CloudWatch Alarm evaluates the metric against your configured threshold
- Alarm triggers → SNS notification → Email to your team
You configure the threshold at deploy time (default: 80%, but I recommend 75% for production workloads):
1
2
3
4
5
6
7
8
aws cloudformation deploy \
--template-file monitoring-account.yaml \
--stack-name bedrock-limits-tracker \
--parameter-overrides \
"AlarmThresholdPercent=75" \
"NotificationEmail=platform-team@company.com" \
"ExecutionFrequencyMinutes=5"
...For critical workloads, set
ExecutionFrequencyMinutes=5 to detect utilization spikes within 5 minutes.Cross-Region Inference: Your Built-In Safety Valve
One powerful mitigation when approaching limits: cross-region inference profiles. These are Bedrock's SYSTEM_DEFINED profiles that automatically route requests across multiple regions.
The solution accounts for this — cross-region profiles get a 2x effective quota in the calculations because they distribute load across regions. This means:
- If a single-region model shows 80% utilization, switching to a cross-region profile immediately halves your effective utilization
- The dashboard shows both profile types so you can see where cross-region routing is already active
- You can proactively create cross-region profiles for models trending toward their limits
Scaling
The Lambda processes accounts and regions in parallel (10 threads by default):
| Scale | Execution Time | Fits 1-min schedule? |
|---|---|---|
| 3 accounts × 2 regions | ~18s | ✅ |
| 20 accounts × 2 regions | ~12s | ✅ |
| 100 accounts × 2 regions | ~60s | ✅ |
| 100 accounts × 5 regions | ~150s | Use 3-min schedule |
For large organizations (100+ accounts), increase Lambda memory to 512MB+ for faster thread execution.
Key Takeaways
- Bedrock quotas are per-account, per-region, and per-model — there's no native way to see them all in one place
- Alert at 70–75%, not 90% — you need time to provision capacity, request quota increases, or shift traffic
- Cross-region inference profiles are your fastest mitigation — they effectively double available capacity
- The solution is free to try — OAM metric sharing is free, and the only ongoing costs are custom CloudWatch metrics and alarms
- No management account required — deploy from any account using SELF_MANAGED StackSets
The full source code, CloudFormation templates, and Terraform alternative are available in the repository. Deploy in under 10 minutes and stop getting surprised by Bedrock throttling.
https://github.com/vogd/BedrockLimitTracker
https://github.com/vogd/BedrockLimitTracker
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article