At low or uneven traffic you pay for capacity overnight and on weekends, so on-demand can be cheaper despite its higher per-token rate. Compare the hourly commitment against your measured token volume before signing a term. ### Bedrock default quotas and throttling limits A launch that exceeds the default limits **gets throttled, not billed more**. Each model has default limits on tokens and requests per minute, set per account and region, so request increases through Service Quotas before traffic arrives, since approval isn't instant.  ## Comparing Bedrock to OpenAI and Vertex AI Don't expect a lower per-token rate than a maker's own API; Bedrock's case rests on one bill and one set of controls across many model makers. The table compares the four on structure, which is stable. Per-token prices and discount percentages change often, so read each vendor's pricing page on the day you budget. | | Billing model | Batch discount | Committed capacity | Model providers | |---|---|---|---|---| | Bedrock | Metered per token | Offered on supported models | Provisioned throughput | Many makers | | OpenAI | Metered per token | Offered | Priority and scale options | OpenAI only | | Azure OpenAI | Metered per token | Offered | Provisioned throughput units | OpenAI models | | Vertex AI | Metered per token | Offered | Provisioned throughput | Google plus partner makers | All four meter tokens, so none has a subscription that caps your spend. The differences that move a bill are who supplies the models and how you reserve capacity. ### Bedrock vs direct provider APIs If you use one maker's models, the maker's own API is usually the simpler purchase. You get new models and features there first, and you carry no cloud-account layer between you and the meter. Bedrock earns its place when you need several makers behind one invoice, one set of IAM permissions and one guardrail configuration. Price the consolidation against the real alternative, which is several vendor contracts and several sets of keys to rotate. ### Bedrock vs Azure OpenAI and Google Vertex AI Azure OpenAI is the better fit when your estate already runs on Azure and your workload is OpenAI models. Vertex AI is the equivalent for Google Cloud, with Google's own models first and partner models beside them. Bedrock sits in the same position on AWS. The comparison therefore mostly reduces to which cloud already holds your data, identity and committed spend, since moving workloads costs more than a rate difference saves. ## Calling Bedrock models from Activepieces workflows Activepieces has 742 integrations, counted from its MIT-licensed open source monorepo, and you can call a Bedrock model from a no-code flow through an HTTP request or MCP step, which is where you can control the bill. Activepieces has its own pricing, separate from Bedrock's: Plus is $20 a month and Team is $200, so the two meters run side by side. ### Routing tasks to the cheapest adequate model Bedrock meters by tokens, so the unit to manage is the call, and a flow lets you decide per call which model receives it. A branch step can send short, repetitive work such as tagging a support email or extracting a date to a small, cheap model, and reserve the expensive model for drafting or reasoning. You pay the premium rate only on the branch that needs it, which is how a cheap-looking rate stops being the deciding number. A platform that resells you its own model has already made that routing decision and priced it before you open the product. Activepieces doesn't resell one: the Bedrock model you pick is called on your own provider key, so the tokens from that HTTP request step land on your AWS account at your rate, and you can reach it from Claude, ChatGPT, Cursor or any MCP client. The free plan is $0 with unlimited flows, and Bring-Your-Own-Key availability by tier is on the pricing page, so you can start for free with no flow constraints, but Bring-Your-Own-Key access depends on your tier. MoneyGram, Moneypenny, Alan and FundingSocieties run Activepieces in production.  Three habits keep the meter honest: 1. Cap input length before the call, with a text step that trims a long email thread or document to what the task needs. Input tokens are billed whether or not the model uses them. 2. Set a maximum output length in the request body, so a verbose answer can't run up output tokens, which usually cost more than input. 3. Write each call's model, token counts and timestamp to a Google Sheets row. Without that log, you learn which branch is expensive only when the invoice arrives. ### Sending model output to the apps you already use Once the model returns text, the flow passes it to the next step. The screenshot below shows the shape: a Calendly cancellation trigger feeds a Slack message step and a Gmail email step, so one event fans out to two destinations.  Swap the trigger for a new support ticket and the HTTP request to Bedrock for the middle step, and the same layout posts a summary to a Slack channel, emails a draft reply through Gmail, or appends a row to a sheet. That fan-out costs nothing extra on the Bedrock side, because the model is called once and its output is reused. The cost to watch on the Activepieces side is credits: the free plan includes 1,000 a month, and when they run out flows wait for the next day's credits, so size long chains against that allowance. ## Cutting a Bedrock bill: the first week checklist Metered pricing means the same discipline applies on Bedrock: measure what you are charged per input and output token, then change the model and the pricing mode only after you can see where the spend sits. The seven steps below run in that order, and each one makes the next one safer. 1. Set AWS Budgets alerts and cost allocation tags. 2. Pull Cost Explorer grouped by model. 3. Move non-urgent work to batch. 4. Test a smaller model on real prompts. 5. Enable prompt caching where the model supports it. 6. Review idle provisioned throughput. 7. Recheck the pricing page monthly. The first two steps change nothing in production, and the rest depend on them. ### Bedrock cost budgets, tags and alerts Create a budget with an alert threshold so a runaway loop reaches your inbox before it reaches the invoice. Tag each application or team, then activate those tags for cost allocation. Without tags, the bill is one line per service and nobody owns the number. Next, open Cost Explorer and group by model. This shows which model carries most of the token charges, which tells you where a switch pays off and where it's a rounding error. ### Midweek: model and mode changes Anything nobody is waiting on, such as nightly summaries or document backfills, is a candidate for batch, which Bedrock prices below on-demand for supported models. Then replay real prompts, not toy ones, against a smaller model. If quality holds on your own examples, the per-token difference applies to every call from then on. Where prompts repeat a long shared prefix, prompt caching lets you pay less for the repeated part. It only helps where the model supports it, so check before building around it. Finally, look at provisioned throughput. It bills for reserved capacity whether or not requests arrive, so an idle commitment costs the same as a busy one. Close the week by rechecking the pricing page, and put that check on the calendar monthly, because rates and model options change. ## Frequently asked questions Five questions come up after the pricing mechanics are clear, and the body doesn't settle them. Each answer below is short and names what to check, since rates change. ### Is there a free tier for Amazon Bedrock? Don't plan around one. Bedrock is metered, so the working assumption is that every input and output token is billed from the first request. Check the pricing page for any current promotional credits or trial offers on your account, and treat them as a bonus on top of your estimate, not a line in the budget. ### Do I pay extra for Anthropic or Meta models on Bedrock? You pay the per-token rate listed for that model, and it arrives on your AWS bill. There's no separate seat or license fee to add on top. Some models sold through AWS Marketplace can be billed differently, so confirm where the charge appears before you commit. The consequence is that your finance team may see the spend under AWS, not under a model maker's invoice. ### Is Bedrock cheaper than calling the model maker's API directly? Not as a rule. Compare the same model, the same pricing mode, and the same feature set on both sides, then multiply by your real monthly token volume. Bedrock can win when consolidated AWS billing or existing AWS commitments apply to the spend. It can lose when a feature you need is priced separately. The per-token rate alone doesn't settle it. ### When does provisioned throughput beat on-demand? When your traffic is steady and high enough that you would use the reserved capacity most of the time. Provisioned throughput is a commitment, so idle hours are still paid for. Spiky or unpredictable workloads usually cost less on-demand. Divide your expected tokens by the capacity you would reserve, and if utilization is low, stay on-demand. ### How do I estimate Bedrock costs before launching? Run a pilot with realistic prompts and measure average input and output tokens per request. Multiply by expected requests per month and by each rate, then add any add-ons you plan to enable, such as retrieval or guardrails. Build a low, expected and high case. The high case shows how much a traffic surge or a model swap would move the bill. ## Related reading - [Asana Automations: A Quick Guide for Modern Teams](https://www.activepieces.com/blog/asana-automations) - [GitLab Pricing in 2026: What Teams Pay](https://www.activepieces.com/blog/gitlab-pricing-in-2026-what-teams-pay) - [HeyGen Pricing for Creators, Marketers and Teams](https://www.activepieces.com/blog/heygen-pricing-for-creators-marketers-and-teams) ## References - [Tickerr](https://tickerr.ai/provider/aws-bedrock)Guardrails and Agents multiply calls per request, so a test that looks cheap on one prompt can cost far more per user action in production.