Keeping an AI App Affordable: Estimating and Controlling Amazon Bedrock Costs
Learn how to estimate and control Amazon Bedrock costs. Build a cost estimate, set up AWS Budgets alerts, tag usage with application inference profiles, watch spend in Cost Explorer, and use six habits that keep bills predictable.
Series: Amazon Bedrock (13 articles)
- …
- 7Keeping an AI App Affordable: Estimating and Controlling Amazon Bedrock Costs This article
Estimate the bill before launch, set alerts so nothing surprises you, tag your usage, and use the habits that keep costs steady.
Almost nobody is shocked by what one model call costs. They're shocked by what ten thousand calls cost, or by a prompt that quietly doubled in size, or by a test loop someone left running overnight.
The good news is that Bedrock costs are predictable once you know where they come from. In this article we'll estimate a bill before launch, set up budget alerts, tag usage so you can see where money goes, and go through the habits that keep spending under control.
[Add a sentence or two here about a time a cloud or AI bill surprised you, or what made you want to get ahead of costs.]
What you need
- The setup from the earlier articles: Python, boto3 and working Bedrock credentials
- Access to the AWS Billing and Cost Management console. In an organisation, you may need someone to grant it.
- A current copy of the Amazon Bedrock pricing page
Prices, discounts and features change often. Every number in this article is for illustration only, so use the real figures from the pricing page.
Step 1: Understand what you're paying for
For most apps, the bill is built from a few pieces.
Model inference. This is the main cost. You can pay in a few ways:
- On-demand: you pay per token, for what you send in and what comes back. Output tokens usually cost more than input tokens. It suits low or unpredictable volume.
- Batch: for jobs that don't need an instant answer, batch processing can be cheaper per token. Check the current pricing page for which models support it and what the discount is.
- Provisioned throughput: you commit to reserved capacity for steady, high-volume use.
Other pieces. Features you add have their own charges: guardrails, knowledge bases and their vector stores, fine-tuning and storage. Each one is worth a look on the pricing page before you switch it on.
If you read the tokens article on our Medium publication, this will sound familiar. Tokens are the meter that's always running.
Step 2: Estimate before you launch
You need four numbers: how many calls you expect, the average input tokens, the average output tokens, and the prices. From a few test runs, Bedrock already tells you the token counts in each response, so you don't have to guess.
Here's a small estimator:
Python
def estimate(calls_per_day, avg_input_tokens, avg_output_tokens,price_in_per_million, price_out_per_million, days=30):per_call = (avg_input_tokens / 1e6 * price_in_per_million+ avg_output_tokens / 1e6 * price_out_per_million)return per_call, per_call * calls_per_day * days# Illustrative numbers only. Use real prices from the pricing page.per_call, monthly = estimate(calls_per_day=2000,avg_input_tokens=1500,avg_output_tokens=400,price_in_per_million=1.0,price_out_per_million=5.0,)print(f"Per call: ${per_call:.4f}, per month: ${monthly:,.2f}")
With those made-up numbers, one call costs $0.0035 and a month comes to about $210. Now change one input and see what happens. Double the input size and the monthly figure moves immediately. It's a useful way to see which lever matters most for your app.
A tip: don't just estimate the typical case. Run it again with your heaviest realistic usage, and add a margin for retries, testing and growth.
Step 3: Set a budget with alerts
An estimate is a guess. A budget tells you when reality is drifting from it.
- Open the AWS Billing and Cost Management console and choose Budgets.
- Choose Create budget and select a cost budget.
- Set it to monthly, and enter an amount that matches what you're comfortable with.
- Add alerts at several thresholds, for example 50%, 80% and 100% of the budget. If the option is there, add one based on the forecasted spend too, which can warn you before you've actually crossed the line.
- Add the email addresses that should be notified, and save.
Remember that a budget alerts you. By default it doesn't stop anything from running. If you want automatic action, look at budget actions, and think carefully about what you'd want stopped.
Set this up before you start experimenting. It takes five minutes and it's the cheapest insurance in this article.
Step 4: Tag your usage so you can see where money goes
Once an app has more than one feature, "Bedrock cost" as a single line isn't much use. You want to know which application, team or environment is spending.
Bedrock supports this with application inference profiles. An application inference profile references a specific model and carries cost allocation tags. You then use the profile's ARN in place of the model ID in your calls, and the tags flow through to your cost reports.
Create one with the
bedrock client:Python
import boto3bedrock = boto3.client("bedrock", region_name="us-east-1")profile = bedrock.create_inference_profile(inferenceProfileName="support-assistant-prod",modelSource={"copyFrom": "YOUR_MODEL_OR_PROFILE_ARN"},tags=[{"key": "Application", "value": "SupportAssistant"},{"key": "Environment", "value": "Production"},],)print(profile["inferenceProfileArn"])
Then pass that ARN as the
modelId in your Converse calls, exactly as you did with the model ID before.There's one more step that people miss. In the Billing and Cost Management console, open Cost allocation tags and activate the tags you used. Tags only show up in cost reports after activation, and they aren't applied retroactively to earlier usage. So do this before your real traffic starts.
Each profile is tied to one model, so you'll create one per model and use case you want to track.
Step 5: Watch it in Cost Explorer
After a day or two of usage, open Cost Explorer and filter by the Amazon Bedrock service, then group or filter by your tags. You'll see spending by application and environment, and a trend line that tells you whether you're on track.
A habit worth building: look at it weekly for the first month. Patterns show up quickly.
Step 6: Turn on anomaly detection
Budgets tell you about the total. AWS Cost Anomaly Detection looks for unusual jumps, such as a sudden spike from a looping job. Set up a monitor for your account or for tagged usage, and add an alert subscription so the right people get an email when something odd happens.
If you do only one thing from this list in a hurry, the budget in Step 3 is it. This one is a close second.
Step 7: Log your own token numbers
The bill arrives later. Your app can see usage immediately. Log the token counts from each response, along with which feature made the call.
Python
import logginglogger = logging.getLogger("bedrock-usage")def log_usage(response, feature):usage = response["usage"]logger.info("feature=%s input_tokens=%d output_tokens=%d",feature, usage["inputTokens"], usage["outputTokens"],)
Now if a prompt grows, you'll see it in your logs the day it happens, not on next month's invoice.
Six habits that keep costs down
- Trim your prompts. Long instructions and repeated context are charged on every single call. Review prompt templates and cut what the model doesn't need.
- Cap the output. Set a sensible
maxTokensand ask for the length you actually need.
- Choose the smallest model that does the job. Use your own comparison tests, as in the model comparison article, rather than defaulting to the biggest model.
- Reuse repeated context. If you send the same long prefix on many calls, look at whether prompt caching is available for your model. It can lower the cost and latency of repeated prefixes.
- Batch what isn't urgent. Nightly summaries and bulk classification don't need instant answers.
- Watch loops and retries. Agents and retry logic can multiply calls without anyone noticing. Put limits on both.
Mistakes to avoid
- Estimating only the average case. Plan for your busiest day.
- Forgetting to activate cost allocation tags. Unactivated tags don't appear in your reports.
- Leaving test resources running. Vector stores and provisioned capacity can charge while idle.
- Treating a budget as a safety switch. It's an alarm unless you've set up actions.
- Never looking. The reports only help if someone reads them.
My results
[Add your own numbers here if you'd like: your estimate, what you actually spent in the first week or month, and one change that made a noticeable difference. Real figures are far more convincing than any rule of thumb.]
What you have now
An estimate before launch, a budget with alerts, tagged usage you can break down, anomaly detection, and your own token logs. That's a solid set of defences against bill shock.
Next in the series we'll look at how to see what your app is doing, with logs and traces you can trust.
Pricing, discounts, features and console steps change often. Check the current Amazon Bedrock pricing page and AWS documentation before you follow any step here.
Series: Amazon Bedrock (13 articles)
- …
- 7Keeping an AI App Affordable: Estimating and Controlling Amazon Bedrock Costs This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article