Amazon Bedrock Overview: Foundation Models on AWS

One API in front of many foundation models

Amazon Bedrock is a managed AWS service that exposes foundation models from several vendors behind a single API. You do not provision servers, attach accelerators or manage a serving runtime. You call an endpoint, name a model, and receive a response.

The service sits in the same account, region and permission structure as the rest of AWS. That is the main reason teams already on the platform reach for it: identity, logging, networking and billing all work the way they already do, so adding generative features does not mean adding a new vendor relationship.

Bedrock is a serving and orchestration layer, not a model of its own. Amazon publishes its own model families through it, and so do several independent model providers, with each one keeping its own terms and its own regional availability.

The catalog and how a model becomes callable

Bedrock presents a catalog of models grouped by provider and by modality: text, chat, embeddings, and image generation among them. Amazon's own families appear alongside models from independent labs, and the mix changes as vendors publish new versions.

A model in the catalog is not automatically callable. Access is granted per model within a region through the model access page in the console, where an account administrator enables the ones the team intends to use. Some vendors attach their own end user license terms, which are presented at that point and must be accepted by someone with authority to do so.

This is ordinary account administration, and it is worth doing deliberately rather than enabling everything. Enabling only what you use keeps the catalog readable, keeps invocation logs meaningful, and makes an IAM policy that names specific model identifiers much easier to write.

Invoking a model

Two API shapes matter in practice. The older invocation calls pass a request body whose structure is defined by each model vendor, which means switching vendors changes your payload format. The Converse API normalizes that: one message structure, one set of inference parameters, and one response shape across supported text models.

Both shapes have a streaming variant, which returns tokens as they are produced instead of waiting for the full response. For anything user facing, streaming is the difference between an interface that feels alive and one that appears frozen.

Calls are signed with standard AWS credentials, so the same role assumption and credential chain your other AWS SDK calls use applies here. There is no separate API key to distribute, which removes an entire category of secret handling problems described in managing API keys and secrets.

Knowledge Bases and retrieval

Most useful applications need the model to answer from your documents rather than from general knowledge. Bedrock Knowledge Bases packages that pattern: you point it at a data source, it chunks and embeds the content, writes the vectors to a supported store, and then handles retrieval at query time.

The vector store is a choice you make. Supported options include Amazon OpenSearch Serverless, Aurora PostgreSQL with the pgvector extension, and several third party managed stores. Each has different operational characteristics, which is the subject of vector databases in the cloud.

Two API calls cover the common cases. One retrieves matching passages so your own code can do what it likes with them. The other retrieves and generates in a single step, returning an answer with citations back to the source documents. The second is faster to ship; the first gives you control over prompt construction.

Agents, Guardrails and evaluation

Three further components sit on top of the invocation layer.

Agents let a model call tools you define, backed by Lambda functions or OpenAPI schemas, and carry state across a multi step task. The service manages the orchestration loop, so you describe the actions rather than writing the loop yourself.

Guardrails apply configurable policies to prompts and responses independently of the model: topic restrictions, content filters, sensitive information handling and word filters. Because a guardrail is a separate resource, one policy can be attached across several applications and updated in one place.

Model evaluation supports comparing candidates on your own prompts, either through automatic scoring or through a human review workflow. It is the sober answer to picking a model by vibes, and it is worth running before any migration between model versions.

On demand, provisioned and batch

Bedrock offers more than one way to buy capacity, and the choice shapes both your bill and your failure modes.

On demand usage is governed by service quotas expressed in requests and tokens per minute, per model, per region. Hitting them produces throttling rather than errors in your logic, and the handling patterns are set out in rate limits and quotas for cloud AI APIs.

Custom models, produced by fine tuning a supported base model on your own data, are served through Provisioned Throughput rather than on demand. That is a real budget consideration, not a technicality, and it should be priced into any plan that assumes fine tuning.

Permissions, logging and network placement

Bedrock is governed by IAM like any other AWS service. Policies can scope down to specific model identifiers and specific actions, so a team that should only call one embedding model can be given exactly that. The least privilege patterns in cloud IAM fundamentals apply without modification.

Management operations land in AWS CloudTrail. Invocation logging is configured separately and writes prompts and responses to Amazon S3 or Amazon CloudWatch Logs, which is how you build an audit trail of what was actually asked. Treat that destination as sensitive, because it now contains whatever your users typed.

For private networking, interface VPC endpoints keep traffic to the service off the public internet. Customer managed KMS keys can encrypt custom model artifacts and related resources. AWS states in its documentation that prompts and outputs are not used to train the underlying base models, and that position is worth reading directly rather than through summaries.

Because all of this hangs off a standard AWS account, the organizational layout in AWS account structure and multi account design determines who can turn models on. Access begins with the account itself, which is what an AWS account from the marketplace provides.

Questions teams ask before adopting Bedrock