Monitor Your Amazon Bedrock Quotas

Set up CloudWatch alarms to catch Bedrock quota limits before throttling hits.

Introduction

30 Second Summary

Imagine driving a car with no fuel gauge. You have no idea how much is left until the engine sputters and dies. That is exactly what happens when you run AI workloads on a cloud service without understanding your usage limits.

In this project, you will explore how Amazon Bedrock quotas work, discover a hidden multiplier that makes your usage burn faster than you think, and set up automated monitoring so you never get throttled by surprise.

What You'll Build

You will have a complete quota monitoring setup in your AWS account where a CloudWatch alarm proactively alerts you before your Bedrock usage hits the ceiling, so you can scale up capacity instead of scrambling after requests start failing.

By the end of this project, you'll have:

A clear picture of your exact per-model token limits across both Bedrock endpoints, viewable in seconds from the Service Quotas console.
A working CloudWatch alarm that fires at 80% quota usage, giving you time to react before throttling hits your workloads.
A complete understanding of the burndown multiplier that causes 100 output tokens to consume 500 to 1,500 tokens of your actual quota, plus knowledge of how to request more capacity when you need it.
Secret Mission: Build a multi-metric CloudWatch dashboard combining token usage, throttle counts, and quota consumption into a single operational view.

Are there any prerequisites?

You need an AWS account with Amazon Bedrock model access already enabled for at least one Claude model. If you have not yet enabled model access in Bedrock, do that before starting this project.

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to build and why it matters. This step is your moment to commit to the goal before any hands-on work begins.

Explore Your Bedrock Quotas in Service Quotas

Every Amazon Bedrock model you call has a hard limit on how many tokens it processes per minute. If you exceed that limit, your requests get throttled with a 429 response and your application stops working.

The problem is that most people have no idea what their per-model limits actually are. In this step, you will find your exact quota values inside the Service Quotas console so you can manage them instead of being surprised by them.

In this step, get ready to:

Find your per-model TPM, RPM, and TPD quotas for the bedrock-runtime endpoint.
View the bedrock-mantle endpoint quotas and compare the two endpoint structures.
Identify which quotas are adjustable and understand how service tiers share quota.

Open Service Quotas and find your bedrock-runtime quotas

AWS Service Quotas is the central console where you view and manage the limits on every AWS service in your account.

Sign in to the AWS Management Console.
In the top search bar, type Service Quotas and select the Service Quotas service from the results.
In the left navigation pane, click AWS services.
In the search field, type Amazon Bedrock and select it from the list.

You should now see a list of all Bedrock quotas for your account in the current region.

Scroll through the list or use the search field to find these three key quotas for a Claude model (such as Claude Sonnet or Claude Opus):
Note down the applied quota values shown for your account. These are your actual enforced limits.

What are these three quotas?

On-demand InvokeModel tokens per minute (TPM) is the total number of tokens (input + output combined) your account can process in a single minute for that model. Cross-Region InvokeModel tokens per minute is the same limit but for cross-region inference routing.

Model invocation max tokens per day (TPD) caps total daily consumption. By default, TPD equals TPM multiplied by 1,440 (the number of minutes in a day).

Your values may be lower than the AWS default

If your account is new or lightly used, the applied quota value may be less than the AWS default. This is normal. You will learn how to request increases in a later step.

Don't see Amazon Bedrock in the list?

Service Quotas are region-specific. Make sure your console is set to a region where you have Bedrock model access enabled (check the region dropdown in the top-right corner). If you still do not see Bedrock, confirm that you have model access enabled in the Amazon Bedrock console under Model access.

Help me find Amazon Bedrock in Service Quotas.

View bedrock-mantle endpoint quotas

Amazon Bedrock has two separate inference endpoints, each with its own quota structure. You just viewed the bedrock-runtime quotas. Now you will look at the bedrock-mantle endpoint.

On the same Amazon Bedrock quotas page in Service Quotas, clear the search field.
Type Bedrock Mantle in the search field.
Find the two bedrock-mantle quotas:
Note down the values for a Claude model. For example, Claude Opus 4.7 defaults to 20,000,000 input TPM and 4,000,000 output TPM, though your values may differ.

Notice the structural difference. The bedrock-runtime endpoint combines input and output tokens into a single TPM quota. The bedrock-mantle endpoint separates them into two distinct quotas.

Why does the split matter?

Because bedrock-mantle separates input from output, it does not apply a burndown multiplier to output tokens. The bedrock-runtime endpoint does apply burndown (which you will discover in Step 3). This means the same model can behave very differently depending on which endpoint you call.

Traffic to the two endpoints is tracked against completely separate quotas, even when calling the same underlying model.

Check which quotas are adjustable and understand service tiers

Not every Bedrock quota can be increased. Before you ever need more capacity, you should know which limits are flexible and which are fixed.

Clear the search field so you see the full list of Amazon Bedrock quotas again.
Look at the Adjustable column. Quotas marked Yes can be increased through a request. Quotas marked No are fixed by AWS.
Click on one of your adjustable Claude model quotas (such as Cross-Region InvokeModel tokens per minute) to open its details page.
Review the details page. Note the quota description, the applied quota value, the AWS default value, and the quota ARN.

How do service tiers share this quota?

Your on-demand quota for a model is shared across the priority, default, and flex service tiers. This means all three tiers draw from the same token pool. Only reserved tier capacity is separate from your on-demand quota.

If you are running workloads at multiple priority levels, they all compete for the same TPM limit unless you purchase reserved capacity.

Before you move on, think about this: based on what you have seen, can you state your account's specific TPM limit for at least one Claude model? Can you explain the structural difference between the two endpoints?

You should be able to say something like: "My On-demand InvokeModel tokens per minute for Claude Sonnet is X. The bedrock-runtime endpoint combines input and output into one TPM number, while bedrock-mantle separates them into independent input and output quotas."

Seeing 'Not available' for some quota values?

Some quotas display "Not available" for the applied quota value if your account has not used that model yet. This is normal for newly enabled models. The AWS default value still shows you the theoretical limit.

Why do some of my Bedrock quotas show 'Not available'?

You now have a clear picture of your account's Bedrock limits. Next up, you will make some actual Bedrock API calls and watch the token consumption flow into CloudWatch in real time.

Make Bedrock Calls and Watch Token Metrics in CloudWatch

You now know your exact quota numbers from Service Quotas. Numbers on a page only matter when you can see how your actual API calls consume them.

In this step, you'll make real Amazon Bedrock calls and trace the token consumption they generate in CloudWatch. This connects the abstract quota limits to observable, live metrics.

In this step, get ready to:

Send prompts to a Claude model in the Bedrock Chat playground and note the token counts.
Find your token consumption metrics in the CloudWatch console.
Calculate your raw quota usage percentage.

Send prompts in the Bedrock Chat playground

To generate token metrics that CloudWatch can pick up, you need to make actual API calls to a Bedrock model. The Chat playground is the fastest way to do this without writing any code.

Open the Amazon Bedrock console at https://console.aws.amazon.com/bedrock.
In the left navigation pane, expand Playgrounds and select Chat.
Click Select model at the top of the chat area.
Choose Anthropic as the provider, then select a Claude model you have access to (the same model whose quota you noted in Step 1).
Click Apply.

Now send 2-3 prompts that generate substantial responses so CloudWatch has meaningful data to display.

Type the following prompt into the chat box and press Enter:
Write a 200-word summary of how cloud computing works.
Wait for the model to respond fully.
Send a second prompt: Explain the difference between IaaS, PaaS, and SaaS with examples for each.
Send a third prompt: Describe three security best practices for cloud deployments.

After each response, the playground displays token usage information below the response. Note down the input token count and output token count for each prompt.

What should I see?

Each response shows a token breakdown. You'll typically see 15-30 input tokens per prompt and 150-300 output tokens per response. Write these numbers down. You'll compare them against your CloudWatch metrics shortly.

Not seeing a Claude model in the model list?

Your account needs model access enabled for the Claude model. In the Bedrock console left navigation, look for Model access under Bedrock configurations. Confirm that the Claude model shows Access granted. If not, click Modify model access and enable the model.

help me enable access to a Claude model in Amazon Bedrock

Find your token metrics in CloudWatch

Every Bedrock call automatically publishes token metrics to CloudWatch under the AWS/Bedrock namespace. You don't need to configure anything for this to happen.

Open the CloudWatch console at https://console.aws.amazon.com/cloudwatch/.
In the left navigation pane, choose Metrics, then All metrics.
In the search field at the top of the All metrics tab, type Bedrock and press Enter.
Select the AWS/Bedrock namespace from the results.
Select the By Model ID dimension grouping.
Find the row for your Claude model's ModelId and check the boxes next to InputTokenCount and OutputTokenCount.

Now adjust the time range so your recent calls are visible.

In the time range controls at the top of the graph area, select 1h (1 hour).
Click the Period dropdown on the Graphed metrics tab below the graph and set it to 1 Minute.

You should see data points on the graph corresponding to the prompts you just sent. The spikes represent the token counts from your playground calls.

What do these metrics represent?

InputTokenCount counts the tokens in your prompt. OutputTokenCount counts the tokens the model generated in its response. Both metrics are filtered by the ModelId dimension, which means you see data only for the specific model you called.

These metrics are published automatically by the bedrock-runtime endpoint. No additional configuration or logging is needed.

Not seeing any data points?

Metrics can take 2-3 minutes to appear in CloudWatch after your Bedrock calls. Refresh the graph if you don't see data immediately. Also confirm you are in the same AWS region where you made your playground calls.

help me find my Bedrock token metrics in CloudWatch

Calculate your raw quota usage

With your metrics visible, you can now estimate how much of your TPM quota a single minute of activity used. This gives you a baseline for understanding quota headroom.

Add up the InputTokenCount and OutputTokenCount values from the highest data point on your graph (the minute with the most activity).
Divide that sum by your TPM quota value from Step 1 and multiply by 100 to get a percentage.

What should this calculation tell me?

With 2-3 playground prompts, your raw token sum is likely under 1,000 tokens total. If your TPM quota is 100,000 or more, you're using less than 1% of your quota based on raw tokens alone.

This feels reassuring. You have tons of headroom, right? Hold that thought. In the next step, you'll discover why this simple calculation is dangerously misleading.

Before you move on, think about this: if your raw token usage is barely 1% of your quota, is there any scenario where you could get throttled?

Your Bedrock calls are now flowing into CloudWatch as real, measurable metrics. Next up, you'll discover a hidden multiplier that makes your actual quota consumption much higher than the raw tokens suggest.

Discover the Burndown Multiplier Trap

Your calculation in Step 2 showed you were comfortably within your TPM quota. Raw token counts suggested your usage was nowhere near the ceiling.

There is one more metric to check. CloudWatch tracks a metric called EstimatedTPMQuotaUsage that shows what Amazon Bedrock actually counts against your quota internally. Let's compare it to your raw calculation and see if the numbers agree.

In this step, get ready to:

Compare EstimatedTPMQuotaUsage to your raw token sum from Step 2.
Calculate the real quota consumption using the burndown formula.
Understand the max_tokens reservation system that temporarily blocks concurrency.

Find the EstimatedTPMQuotaUsage metric

You already have InputTokenCount and OutputTokenCount displayed in CloudWatch from the last step. Now you will add the metric that reveals how Bedrock actually accounts for your usage.

Before you look at it, think about this: do you expect EstimatedTPMQuotaUsage to match your raw token sum (input + output) from Step 2, or will it be different?

In the CloudWatch metrics view, click All metrics at the top if you navigated away.
Search for EstimatedTPMQuotaUsage in the search bar within the AWS/Bedrock namespace.
Select the EstimatedTPMQuotaUsage metric filtered by the same ModelId dimension you used in Step 2.
Keep the 1-hour time range with a 1-minute period so it aligns with your earlier metrics.
Compare the EstimatedTPMQuotaUsage value to the raw token sum you calculated in Step 2 (your InputTokenCount + OutputTokenCount).

Notice the gap. EstimatedTPMQuotaUsage is significantly higher than your raw token sum. Your "safely within quota" conclusion from Step 2 was wrong.

Why is EstimatedTPMQuotaUsage higher?

Bedrock applies a burndown multiplier to output tokens. Each output token consumes more than one token of your TPM quota. This is the trap that catches most Bedrock users off guard.

The EstimatedTPMQuotaUsage metric accounts for this burndown multiplier. It is an approximation and does not reflect the reservation-based token consumption that drives throttling decisions, but it gives you a much more realistic picture than raw token counts.

Don't see EstimatedTPMQuotaUsage?

Make sure you are searching within the AWS/Bedrock namespace, not a custom namespace. Also confirm your time range covers the period when you made Bedrock calls in Step 2. The metric only appears after you have made at least one inference call.

Help me find the EstimatedTPMQuotaUsage metric in CloudWatch for my Bedrock model.

Calculate the real quota consumption

Now that you can see the gap, let's understand exactly where it comes from. Bedrock uses a formula that multiplies output tokens by a model-specific burndown rate.

The actual quota consumption formula is:

InputTokenCount + CacheWriteInputTokens + (OutputTokenCount x burndown rate)

What are the burndown rates per model?

Claude 4.7 and below: 5x (1 output token consumes 5 tokens from your quota).
Claude Sonnet 5: 10x (1 output token consumes 10 tokens from your quota).
Claude 4.8: 15x (1 output token consumes 15 tokens from your quota).
All other models: 1:1 (1 output token consumes 1 token from your quota).

Token burndown rates apply only to models available on the bedrock-runtime endpoint. Models exclusively on bedrock-mantle have separate input and output TPM quotas, so burndown does not apply there.

Look at the token counts from your Step 2 playground calls. Note your InputTokenCount and OutputTokenCount values.
Apply the formula using the burndown rate for the Claude model you used. For example, if you generated 100 output tokens on a Claude 4.7 model: 100 x 5 = 500 tokens burned from your TPM quota for output alone.
Add your InputTokenCount and any CacheWriteInputTokens to get your total actual quota consumption per request.
Divide your total actual consumption by your TPM quota from Step 1 to calculate the real percentage of quota you are using per request.

Compare this new percentage to your Step 2 calculation. You are consuming significantly more quota than raw tokens suggested.

Why does this matter in practice?

A single request generating 200 output tokens on Claude 4.8 burns 3,000 tokens of your TPM quota (200 x 15). If your quota is 100,000 TPM, that one request consumed 3% of your entire per-minute allocation. Scale that to multiple concurrent requests and you can hit your ceiling fast.

This is exactly why people get throttled unexpectedly. They monitor raw token output and think they have plenty of headroom.

What about CacheReadInputTokens?

Cached read tokens are charged at a reduced rate and do not count toward your TPM quota. Only CacheWriteInputTokens add to your quota consumption.

Understand the max_tokens reservation

The burndown multiplier is not the only quota surprise. There is a second mechanism that can block your requests even when your actual usage is low.

At the start of each request, Bedrock reserves quota based on the worst-case scenario. The reservation formula is:

InputTokenCount + CacheWriteInputTokens + max_tokens

What does the max_tokens reservation mean?

When Bedrock receives your request, it immediately deducts the full max_tokens value from your available quota. It does not wait to see how many tokens are actually generated. If this reservation exceeds your remaining quota, the request is throttled with a 429 response before any generation begins.

After the request completes, Bedrock adjusts the reservation to reflect actual output. But during the request, that full max_tokens amount is blocked. This means a high max_tokens setting temporarily prevents other concurrent requests from proceeding, even if you only generate a short response.

Keep max_tokens tight

If you are hitting TPM quotas earlier than expected, try reducing max_tokens to better approximate the size of your completions. Setting max_tokens to 4,096 when your responses are typically 200 tokens wastes reservation headroom and limits concurrency.

Think of it this way: the burndown multiplier inflates your final bill, and the max_tokens reservation temporarily locks up more quota than you actually need. Both mechanisms push you toward your ceiling faster than raw counts predict.

Verify the burndown trap

Switch back to your CloudWatch graph and confirm EstimatedTPMQuotaUsage is visibly higher than the sum of your InputTokenCount and OutputTokenCount data points.
Confirm you can explain this: 100 output tokens on a Claude 4.7 model actually burns 500 tokens of your TPM quota due to the 5x burndown multiplier.

What should I see?

Your CloudWatch graph should show EstimatedTPMQuotaUsage sitting noticeably above your raw token metrics. The exact difference depends on your model's burndown rate and how many output tokens your playground calls generated.

You now understand the real math behind Bedrock quota consumption. Knowing the burndown multiplier exists is only half the battle. Next, you will create a CloudWatch alarm that fires before you actually hit your quota ceiling.

Create a CloudWatch Alarm for Quota Usage

You now know that quota burns much faster than raw token counts suggest. A single response from a Claude 4.7 model consumes 5x more quota than its output token count implies.

Without automated monitoring, you will only discover you are approaching your limit when requests start getting 429 throttled responses. In this step, you will create a CloudWatch alarm that fires before you hit your quota ceiling, giving you time to react.

In this step, get ready to:

Create a CloudWatch alarm on the EstimatedTPMQuotaUsage metric.
Set a threshold at 80% of your TPM quota.
Configure SNS email notifications for the alarm.

Select the metric and start the alarm wizard

CloudWatch alarms watch a single metric and trigger an action when that metric crosses a threshold. You need to point the alarm at EstimatedTPMQuotaUsage for your Claude model so it watches the number that actually reflects burndown.

In the CloudWatch console, choose Alarms in the navigation pane, then choose All alarms.
Click Create alarm.
Click Select metric.
In the search box, type EstimatedTPMQuotaUsage and press Enter.
Select the row that matches your Claude model's ModelId dimension (the same model you used in the previous steps).
Select the check box next to the metric, then click Select metric.

The Specify metric and conditions page appears, showing a graph of the metric.

Under Statistic, choose Sum.
Under Period, choose 1 minute.

Why Sum and 1 minute?

Your TPM quota is measured per minute. Setting the statistic to Sum and the period to 1 minute means each data point represents the total estimated tokens consumed in that minute. This maps directly to the quota enforcement window.

Set the alarm condition at 80% of your quota

You need a threshold that fires early enough to give you time to react, but not so low that it triggers constantly. Industry practice and AWS documentation recommend 80% as the sweet spot.

Under Conditions, for Threshold type, choose Static.
For the comparison, choose Greater than threshold.
In the threshold value field, enter 80% of the TPM quota you recorded in Step 1. For example, if your quota is 100,000 TPM, enter 80000.
Click Additional configuration.
For Datapoints to alarm, set both values to 1 out of 1. This means a single breach triggers the alarm immediately.
Click Next.

Why 80% and not 90%?

AWS recommends an 80% threshold because the burndown multiplier makes quota consumption spiky. A batch of concurrent requests can jump from 60% to 95% in a single minute. At 80% you get the warning before the spike crosses 100%.

You should now see the Configure actions page where you set up notifications.

Configure notifications and create the alarm

An alarm that nobody sees is useless. You will connect your alarm to SNS (Simple Notification Service) so it sends you an email whenever the threshold is crossed.

Under Notification, confirm the alarm state trigger is set to In alarm.
Select Create new topic.
Enter a topic name such as Bedrock-Quota-Alerts.
Enter your email address in the Email endpoints field.
Click Create topic.
Click Next.

What is SNS?

Amazon SNS is a messaging service that pushes notifications to subscribers. When CloudWatch detects that your metric crosses the threshold, it publishes a message to your SNS topic. SNS then forwards that message to every subscriber (in this case, your email address).

On the Name and description page, enter the alarm name: Bedrock-Claude-TPM-80pct.
Click Next.
Under Preview and create, review your settings: metric is EstimatedTPMQuotaUsage, statistic is Sum, period is 1 minute, threshold is your 80% value.
Click Create alarm.

Now confirm your SNS email subscription so you can actually receive alerts.

Open your email inbox and look for a message from AWS Notifications.
Click Confirm subscription in the email. A browser tab opens confirming your subscription is active.

Don't see the confirmation email?

Check your spam or junk folder. AWS confirmation emails sometimes land there.
Make sure you entered the correct email address when creating the topic. If not, delete the SNS topic and re-create it during a new alarm setup.
Wait 2-3 minutes. Delivery can be slightly delayed depending on your email provider.

Help me troubleshoot my SNS subscription confirmation email not arriving.

Before you check your alarm, what state do you think it will be in? You are not currently sending enough traffic to trigger the threshold.

Return to the CloudWatch console and choose Alarms, then All alarms in the navigation pane.

Your alarm Bedrock-Claude-TPM-80pct appears in the list with state Insufficient data. This is expected. The alarm has no recent data points to evaluate because you are not generating sustained traffic right now.

Why Insufficient data and not OK?

CloudWatch shows Insufficient data when there are not enough metric data points in the evaluation period to make a determination. Once your Bedrock usage generates consistent data points, the alarm transitions to OK (below threshold) or ALARM (above threshold).

Your monitoring is now in place. If your Bedrock usage ever spikes toward your quota limit, you will get an email alert with time to spare. Next up, you will learn how to request more capacity when the alarm tells you it is time.

Request a Quota Increase

Your CloudWatch alarm will catch you approaching your quota ceiling. But when that alarm fires in a production workload, you need to know exactly how to get more capacity.

The quota increase process differs between the two Bedrock endpoints. AWS may also deny requests from accounts without existing usage. Understanding this workflow now saves you from scrambling when throttling hits.

In this step, get ready to:

Submit a quota increase request for your Claude model via Service Quotas.
Understand how the bedrock-mantle endpoint requires a different request process.
Verify your request status in Quota request history.

Submit a quota increase request for Cross-Region TPM

When you need more capacity on the bedrock-runtime endpoint, the smartest move is to request an increase for the Cross-Region quota first. AWS will then offer to increase your On-demand TPM and daily TPD limits as well.

Return to the Service Quotas console from earlier.
In the navigation pane, click AWS services.
Type Amazon Bedrock in the search box and select it from the list.
Find the quota named Cross-Region InvokeModel tokens per minute for your Claude model.
Select the quota from the list and click Request increase at account level.

What value should I request?

Enter a value modestly above your current quota. For example, if your current limit is 100,000 TPM, request 150,000. Smaller increases are usually automatically approved, while larger jumps are submitted to AWS Support for review.

In the Increase quota value field, enter a value modestly above your current quota (for example, 150000 if your current limit is 100,000).
Click Request.

Why request Cross-Region first?

For any model on bedrock-runtime, requesting an increase for Cross-Region InvokeModel tokens per minute prompts the AWS support team to offer increases on On-demand TPM and Model invocation max tokens per day as well. One request covers all three quotas.

Before requesting, verify that your model is not in a Legacy or Deprecated lifecycle status. Quota increases are not granted for models scheduled for retirement.

Don't see the Request increase button?

Check the Adjustable column for the quota. If it does not say Yes, that quota cannot be increased through Service Quotas. Also confirm you are looking at the correct quota for your specific Claude model.

Help me find the request increase button

Understand the bedrock-mantle difference

The process you just completed works for the bedrock-runtime endpoint. The bedrock-mantle endpoint uses a completely different path.

How do I increase bedrock-mantle quotas?

Quota increase requests for the bedrock-mantle endpoint are not processed through the Service Quotas console. Instead, you must submit a request through the AWS Support limit increase form.

When submitting, you need to specify four things:

The endpoint (bedrock-mantle).
The Region.
The model.
The quota name (input TPM or output TPM) and the value requested.

This is because bedrock-mantle separates input and output token quotas, so you must specify exactly which one you want increased.

Check your request status in Quota request history

Before you check, what status do you think your request will show? Will it be immediately approved, or will it take time?

In the Service Quotas navigation pane, click Quota request history.
Look for your Amazon Bedrock quota request in the Recent quota increase requests panel.

You should see your request listed with a status of Pending. This means the request is under review by AWS.

What do the status values mean?

Pending means the request is under review.
Case opened means Service Quotas has opened a support case to process it.
Approved means your increase is granted.
Rejected means it was denied. Contact AWS Support for more details.

Will my request be approved?

AWS prioritizes increase requests from accounts that are already consuming their existing quota allocation. Your request might be denied if you do not meet this condition.

If you are following this project on a new account with minimal Bedrock usage, your request may be denied. That is expected and does not affect what you have learned about the process.

Don't see your request in the history?

Make sure you are viewing the correct Region. Quota requests are Region-specific. If you submitted the request in us-east-1 but are now viewing a different Region, switch back using the Region selector in the top-right corner.

Help me find my quota request

You now know the full lifecycle of Bedrock quota management. Next up, take on the Secret Mission and build a multi-metric operations dashboard for complete Bedrock observability.

Secret mission

Build a Bedrock Operations Dashboard

You have a single alarm watching one metric. In production, you need a complete picture at a glance. Build a multi-metric CloudWatch dashboard that combines quota usage, throttle counts, token breakdowns, and latency into a single operational view.

Clean Up Your Resources

Decide whether to keep your resources running or delete them entirely. This project created only monitoring resources (alarms, dashboards, an SNS topic), so ongoing costs are minimal or zero if you are within free-tier limits.

Cost warning

CloudWatch alarms cost $0.10/month each beyond the first 10 (free tier). CloudWatch dashboards cost $3/month each beyond the first 3 (free tier). SNS email notifications are free for the first 1,000 per month.

If you are within free-tier limits for all three services, there is no ongoing cost. If you are not sure, delete the resources to avoid any charges.

Resources you used:

1 CloudWatch alarm (Bedrock-Claude-TPM-80pct).
1 SNS topic with email subscription.
1 quota increase request (informational, no cost).
1 CloudWatch dashboard (Bedrock-Quota-Operations, Secret Mission).

Keep everything running

No action needed. Choose this if you use Amazon Bedrock regularly and want ongoing quota monitoring.

The alarm will alert you when your quota usage approaches 80%.
The dashboard gives you a single-pane view of Bedrock operations.
The quota increase request will be processed by AWS. No further action needed on your part.

Pause - I'll come back to this later

Not applicable for this project. These are monitoring resources, not compute. They do not consume CPU or memory while idle.

If you want to stop alarm notifications without deleting anything, you can disable the alarm action temporarily.

Open the CloudWatch console and go to Alarms, then All alarms.
Select the checkbox next to your alarm, choose Actions, then Disable alarm actions.
The alarm still evaluates, but it will not send notifications until you re-enable actions.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each step below.

Delete the CloudWatch alarm:

Open the CloudWatch console.
In the navigation pane, choose Alarms, then All alarms.
Select the checkbox next to Bedrock-Claude-TPM-80pct, then choose Actions, Delete.
Choose Delete to confirm.

Delete the SNS topic:

Open the Amazon SNS console.
In the left navigation pane, choose Topics.
Select your topic, then choose Delete.
In the confirmation dialog, type delete me and choose Delete.

Delete the CloudWatch dashboard:

Return to the CloudWatch console.
In the navigation pane, choose Dashboards.
Select the checkbox next to Bedrock-Quota-Operations, then choose Delete.
Confirm the deletion when prompted.

Quota increase request:

If your request is still in Pending status and you want to withdraw it, contact AWS Support through the Support Center Console. There is no self-service cancel button in the Service Quotas console.
If the request was already approved, the increased quota remains on your account at no cost. There is nothing to delete.

Nice Work!

You just built a complete quota monitoring setup for Amazon Bedrock. You can now see exactly how your API calls consume capacity, catch the hidden burndown multiplier that surprises most users, and get alerted before throttling hits.

Here's what you learned:

Navigated Service Quotas to identify your exact per-model TPM limits across both the bedrock-runtime and bedrock-mantle endpoints, and discovered how the burndown multiplier makes output tokens consume 5-15x more quota than their raw count.
Connected Bedrock API calls to CloudWatch metrics and created a proactive alarm at 80% quota usage so you never get throttled without warning.
Submitted a quota increase request and learned how the process differs between endpoints: Service Quotas console for bedrock-runtime, AWS Support form for bedrock-mantle.
Secret Mission: Built a multi-metric CloudWatch dashboard combining token usage, throttle counts, and quota consumption into a single operational view.

Ready to quiz yourself?