Getting Started with Amazon Bedrock: Models, Regions, and Quotas
What Amazon Bedrock includes, how to enable model access, why region choice and cross region inference profiles matter, how RPM and TPM quotas work, and how to make a first Converse API call safely.
Amazon Bedrock is the AWS service for calling foundation models through an API instead of hosting them on your own GPUs. One set of credentials and one SDK reach models from Amazon, Anthropic, Meta, Mistral AI, Cohere, and other providers, billed per token on the same AWS invoice as everything else. Getting a first request through involves three things that trip up new accounts: enabling model access, picking a region where the model you want is actually served, and understanding the per model quotas that cap how fast you can call it. This guide walks through each, then covers the API, cost, and logging basics.
What Bedrock is and what it includes
Bedrock has two halves. The control plane, reached through the console and the bedrock API, is where you manage model access, custom models, guardrails, knowledge bases, and agents. The runtime, reached through the bedrock-runtime API, is where inference happens: you send a prompt or a conversation and receive a completion, either as one response or as a stream of tokens. Around inference AWS layers optional services: Guardrails for content filtering and topic control, Knowledge Bases for retrieval augmented generation over your own documents, Agents for multi step tool use, batch inference for large offline jobs, and model customisation for fine tuning where a model supports it.
You do not need any of the optional layers to start. A first project needs an IAM identity with invoke permission, model access in one region, and a few lines of SDK code.
Enabling model access
Models are not callable until access is enabled in the account, and access is tracked per region. The Model access page in the Bedrock console lists every model available in the selected region with its current status. For many models access is granted automatically on first use; for some model providers, Anthropic among them, AWS asks for a one time use case form describing the company and the intended application before the first invocation. The console shows which models need that step, and the request is reviewed by AWS rather than granted instantly, so submit it before the day you plan to build.
Some models are unavailable in certain regions for licensing reasons, and third party model terms are accepted at the point of enabling access. Read those terms, because they bind your use of the model in addition to the AWS acceptable use policy.
Regions and cross region inference
Not every model is served in every region, and the newest models typically appear first in a small set of US regions. The model ID you pass to the API is region specific, and the runtime endpoint you call is in one region, so a request for a model that is not served there fails with a validation error rather than being routed elsewhere. Check the supported regions table for each model in the Bedrock documentation before choosing where to deploy the application that calls it.
Cross region inference profiles change this picture. An inference profile is an identifier that spans several regions in one geography, such as the United States, Europe, or Asia Pacific, and Bedrock routes each request to whichever of those regions has capacity. Using a profile gives higher effective throughput and better resilience than a single region, and some newer models are only offered through profiles. The trade off is that your data may be processed in any region within the profile’s geography, which matters for data residency reviews.
Quotas: requests and tokens per minute
Bedrock throttles on two meters per model per region: requests per minute, usually abbreviated RPM, and tokens per minute, abbreviated TPM. Some models also carry a tokens per day quota. The values differ by model and by account, and they appear in the Service Quotas console under Amazon Bedrock. When either limit is reached the runtime returns a throttling exception, and the SDK’s built in retry with backoff handles short bursts but not sustained overload.
- Requests per minute (RPM)
- Caps how many invocations a model accepts per minute in a region
- Tokens per minute (TPM)
- Caps the combined input and output tokens processed per minute
- Where to see them
- Service Quotas console, filtered to Amazon Bedrock, per region
- How to raise them
- Request an increase in Service Quotas or through an AWS Support case, with a description of the workload
- Reserved capacity
- Provisioned Throughput purchases dedicated model units for a term, separate from on demand quotas
New accounts often start with lower quotas than the documented defaults, and increases are reviewed against account history and the use case you describe. Ask early, ask for what the workload needs rather than the maximum, and design the application to queue or degrade gracefully when throttled. The Cloud Library guide to cloud service quotas covers the general request process.
Making the first call
Create an IAM role or user with a policy that allows the InvokeModel and InvokeModelWithResponseStream actions on the specific model ARNs you intend to use, rather than on all of Bedrock. Applications running on EC2, Lambda, or ECS should use an attached role so no access key exists to leak; a developer laptop should use an SSO profile. Then use the Converse API from the AWS SDK for your language. Converse takes a list of messages and optional system prompt, tool definitions, and inference parameters in one format that works across model families, so switching models is a change of ID rather than a rewrite. The older InvokeModel API passes each provider’s native request body and is still needed for a few model specific features.
Use the streaming variant for anything a person watches, so the first tokens appear quickly. Set a maximum output token count on every request, keep prompts in version control, and log the model ID with each request so behaviour changes can be traced to a model update.
Cost, logging, and hygiene
On demand pricing charges per input token and per output token at rates set by each model provider, so the cheapest way to cut a bill is shorter prompts and a smaller model for simple tasks. Batch inference processes large jobs asynchronously at a lower rate, and Provisioned Throughput trades a fixed hourly commitment for reserved capacity. Set an AWS Budget that covers Bedrock before the first production traffic, and use application inference profiles with cost allocation tags when several teams share one account.
Model invocation logging is off by default. Turning it on sends request and response bodies to CloudWatch Logs or S3, which is valuable for debugging and audit and also means prompts containing customer data are now stored; set retention and access controls accordingly. CloudTrail records the management API calls regardless. Combine both with Guardrails on user facing applications so that prompt injection and disallowed topics are filtered before they reach the model or the user.
Where to go next
Bedrock runs inside an ordinary AWS account. The marketplace lists AWS accounts in several variant groups, including the Bedrock Enabled labels described above, with every variant name and price stated on the product page.
For the wider platform Bedrock sits in, read AWS explained. If you decide to run models on your own hardware instead, cloud GPUs for AI workloads compares the options, and API keys and secrets management covers protecting the credentials that call Bedrock. The Cloud Library hub lists every developer workflow guide.