Amazon Bedrock: How Teams Use Foundation Models on AWS
An overview of Amazon Bedrock covering the model catalog, common build patterns, model access and quotas, pricing options and data handling on AWS.
Amazon Bedrock is a fully managed AWS service that gives you API access to foundation models from Amazon and several other AI companies, without provisioning GPUs or hosting models yourself. This overview explains what Amazon Bedrock includes, the common patterns teams build with it, and how access, quotas, pricing and data handling work.
What Amazon Bedrock is, in one paragraph #
Bedrock sits between your application and a catalog of large language models and other generative models. You send a request (a prompt, a conversation, an image, or a document) to a model ID through the Bedrock API, and you get a response back. AWS runs the infrastructure; you manage IAM permissions, choose models, and pay for usage. Because it is an AWS service, it plugs into IAM, CloudWatch, CloudTrail, VPC endpoints and the rest of your AWS environment.
The model catalog includes Amazon’s own models (such as the Amazon Nova family and Titan embeddings) alongside models from providers such as Anthropic, Meta, Mistral AI, Cohere, AI21 Labs, Stability AI and others. Availability varies by Region and changes as models are added or retired, so the Bedrock console’s model catalog is the authoritative list for your account.
Four patterns teams commonly build #
1. Direct text generation and chat
The simplest use is calling a model to draft, summarize, classify or extract information from text. The Converse API provides a consistent request and response format across many chat-capable models, which makes it easier to switch or compare models without rewriting your integration. The lower-level InvokeModel API accepts each model’s native request format when you need model-specific parameters.
2. Retrieval-augmented generation over your own documents
Foundation models do not know your internal documentation, contracts or product catalog. Knowledge Bases for Amazon Bedrock handles the retrieval-augmented generation (RAG) pipeline: it ingests data from sources such as S3, splits it into chunks, creates embeddings, stores them in a vector store you choose, and retrieves relevant passages at query time so the model can ground its answer. Responses can include citations back to source documents.
3. Agents that call tools and APIs
Amazon Bedrock Agents lets a model plan multi-step tasks and call actions you define, typically backed by Lambda functions or API schemas, and consult knowledge bases along the way. AWS has also introduced Amazon Bedrock AgentCore, a set of services for running and operating agents built with various frameworks, covering areas such as runtime, memory, identity and observability. Tool use is also available directly through the Converse API if you prefer to orchestrate the loop in your own code.
4. Batch processing and offline jobs
When you need to process a large set of documents and do not need an immediate response, batch inference lets you submit prompts in a file stored in S3 and collect results later. For supported models, batch pricing is typically lower than on-demand requests, which suits jobs such as tagging a content archive or generating product descriptions overnight.
The supporting building blocks #
- Guardrails for Amazon Bedrock: configurable policies that filter harmful content, block denied topics, redact personally identifiable information and check responses for grounding against source material. Guardrails can be applied to model calls and to agents.
- Model evaluation: tools for comparing models on your own prompts using automatic metrics, human reviewers or a model acting as a judge.
- Customization: fine-tuning, continued pre-training and distillation for supported models, producing a private custom model in your account. Running a custom model generally requires Provisioned Throughput or another supported deployment option, so check the pricing before you start.
- Prompt management and Flows: store versioned prompts and chain prompts, knowledge bases and functions into workflows.
- Cross-Region inference: inference profiles that route requests across multiple Regions to handle traffic bursts, with data processed in the Regions defined by the profile.
Model access and quotas: the official process #
This is where many first attempts stall, so it is worth understanding before you write code.
Model access
Access to models is managed in the Bedrock console. Depending on the model, the Region and current AWS policy, a serverless model may be available to your account once your IAM permissions allow it, or it may require you to request or enable access on the Model access page first. Some providers ask you to submit brief use-case details before first use, and some models are sold through AWS Marketplace with their own terms. Administrators can restrict which models people are allowed to call using IAM policies and, in AWS Organizations, service control policies.
Quotas
Every model has default quotas per Region, typically expressed as requests per minute and tokens per minute, along with limits for features such as batch jobs and knowledge bases. New accounts often start with lower defaults. You can view current values in the Service Quotas console under Amazon Bedrock.
Your application should also handle throttling gracefully. The AWS SDKs retry throttled requests with backoff by default, and you can add your own queueing for bursty workloads.
How Bedrock pricing works #
Bedrock pricing depends on the model and the way you consume it. Exact rates change often and differ by provider, so use the official Amazon Bedrock pricing page for current figures.
| Option | How you pay | Typical fit |
|---|---|---|
| On-demand | Per input and output token for text models; per image or per unit for others | Prototypes, variable traffic, most production apps |
| Batch | Per token at a batch rate for supported models | Large offline jobs without real-time needs |
| Provisioned Throughput | Hourly charge for reserved model units, with optional term commitments | Predictable high volume, and custom models |
Related features carry their own charges: Guardrails are billed per text unit processed, Knowledge Bases incur embedding costs plus whatever vector store you use (for example Amazon OpenSearch Serverless or Aurora PostgreSQL), and agent calls consume model tokens on every reasoning step. Output tokens usually cost more than input tokens, so verbose responses and long conversation histories drive cost. For budgeting mechanics, see how AWS billing, budgets and alerts work.
Security and data handling #
According to AWS documentation, Bedrock does not use your prompts and completions to train AWS models and does not share them with third-party model providers. Data is encrypted in transit and at rest, and you can use AWS KMS customer managed keys for supported resources such as custom models and knowledge bases.
A few practical steps strengthen a Bedrock deployment:
- Grant
bedrock:InvokeModeland related actions only to the roles that need them, scoped to specific model ARNs where possible. - Use VPC interface endpoints (AWS PrivateLink) so application traffic to Bedrock does not traverse the public internet.
- Enable model invocation logging to CloudWatch Logs or S3 if you need an audit trail of prompts and responses, and protect those logs as sensitive data.
- Rely on CloudTrail for a record of who called which Bedrock APIs.
Our cloud account security checklist covers the account-level controls that should be in place before you expose any AI feature to users.
Getting started checklist #
- Use an AWS account created through the official sign-up, with MFA on the root user and a budget alert configured.
- Pick a Region where the models you want are listed in the Bedrock console.
- Confirm or request model access through the console, completing any provider use-case details it asks for.
- Check default quotas in Service Quotas and request increases through the official process if your expected traffic needs them.
- Try prompts in the console playground, then call the Converse API from an AWS SDK using an IAM role.
- Add Guardrails, logging and cost alerts before opening the feature to real users.
The Amazon Bedrock documentation includes the user guide, API reference and model-specific parameters. For context on the wider platform, see our explanation of AWS core services and the AWS overview.
Frequently asked questions #
Do I need machine learning expertise to use Amazon Bedrock?
No. Basic use is an API call from an AWS SDK. Skills in prompt design, evaluation and data preparation help a great deal, but you do not need to train or host models to get started.
Why am I getting an access denied error when calling a model?
Check three things: that your IAM role allows the Bedrock action for that model, that model access is enabled for your account in the Region you are calling, and that no service control policy blocks it. The model ID or inference profile must also be valid in that Region.
How do I raise my Bedrock tokens-per-minute limit?
Open the Service Quotas console, find Amazon Bedrock, and request an increase for the relevant model quota, or open an AWS Support case. For consistent high throughput, consider Provisioned Throughput.
Can I use Bedrock models outside AWS?
You call Bedrock over a public HTTPS API, so applications hosted anywhere can use it with valid AWS credentials. Keeping the application on AWS makes it easier to use IAM roles and private VPC endpoints instead of long-lived keys.
