Amazon Bedrock

You have decided your application needs a foundation model. Now come the questions nobody enjoys: which GPU instances, how many, in which Region, who patches them, what happens at 3 a.m. when traffic triples, and how you swap in a better model six months from now without rebuilding everything.

Amazon Bedrock exists so you never answer those questions. AWS defines it as "a fully managed service that provides secure, enterprise-grade access to high-performing foundation models from leading AI companies, enabling you to build and scale generative AI applications."

Read that as a list of things you no longer do. No servers to size. No model weights to download. No inference stack to operate. You send a request to an API endpoint and get generated text back, and the capacity underneath it is somebody else's problem.

One API, many models

Bedrock supports over 100 foundation models from providers including Amazon, Anthropic, DeepSeek, MiniMax, Moonshot AI, and OpenAI. That catalog is worth noticing, but the catalog is not the point. The point is what sits in front of it.

Every one of those models is reached through the same service. In practice you call the Converse API, name a model ID, and pass your messages:

import boto3

client = boto3.client('bedrock-runtime', region_name='us-east-1')
response = client.converse(
    modelId='anthropic.claude-opus-4-7',
    messages=[
        {'role': 'user', 'content': [{'text': 'Summarize this support ticket.'}]}
    ]
)

Now change modelId to an Amazon Nova model. Nothing else in that call changes. Your authentication, your SDK, your error handling, your logging, and your IAM policies all keep working.

Compare that to the alternative. Without Bedrock, each provider means a separate account, a separate API key stored somewhere, a separate SDK with its own request shape, a separate bill, and a separate security review. Adding a second model provider is a project. On Bedrock it is a string.

This is the reason the model-selection lesson could call model choice reversible. That reversibility is not a general property of generative AI. It is a property of building behind an abstraction layer, and Bedrock is that layer.

One honest limit: the call is portable, the behavior is not. A prompt tuned for one model does not produce identical output on another, and models differ in context window, maximum output length, and which inference parameters they accept. Bedrock makes the switch cheap. It does not make revalidation unnecessary.

What Bedrock adds around the model

A raw model call is not an application. Between "the model responds" and "the feature ships" sit a set of problems every team hits, and Bedrock ships managed answers to most of them.

Knowledge Bases handle retrieval augmented generation. AWS describes the purpose directly: RAG "uses information from data sources to improve the relevancy and accuracy of generated responses," and with Knowledge Bases "you can integrate proprietary information into your generative-AI applications." Point it at your data, and it manages ingestion, chunking, embedding, storage, and retrieval, then returns responses with citations so an answer can be traced back to its source. A Managed Knowledge Base lets AWS run that whole pipeline; a customer-managed one lets you bring your own vector store, such as Amazon OpenSearch Serverless, Amazon Aurora, or Amazon Neptune, and control the ingestion and indexing yourself.

Guardrails are the safety layer. They provide "configurable safeguards to help you build safe generative AI applications," and they come as six policy types:

Two details about Guardrails are worth holding. They evaluate both the input prompt and the model completion, not just one side. And they can run without a model at all: the ApplyGuardrail API screens content on its own, so you can check text before it enters your pipeline.

Model customization covers three methods. Supervised fine-tuning trains on labeled input-output examples. Reinforcement fine-tuning learns from reward functions you define instead of labeled pairs. Distillation transfers knowledge from a large teacher model to a smaller, faster, cheaper student model. Domain 3 covers when each one is the right call.

Evaluations score models on your own data, either programmatically, with a judge model, or with human reviewers. You met these in the model-selection lesson.

AgentCore turns a model into an agent that plans and acts. That is a topic of its own, and the next lesson picks it up.

The pattern across all of these is the same: each one is a problem you would otherwise solve with your own infrastructure, offered instead as a configuration.

The data question, answered concretely

Every organization asks a version of this: if we send customer text to a third party's model, what does that third party get to see?

For Bedrock, AWS answers it structurally rather than with a promise. In each Region where Bedrock is available, there is one model deployment account per model provider. Those accounts are owned and operated by the Bedrock service team. When a provider delivers a model, AWS performs a deep copy of the provider's inference and training software into those accounts. And then the sentence that matters: "Because the model providers don't have access to those accounts, they don't have access to Amazon Bedrock logs or to customer prompts and completions."

So calling a third-party model on Bedrock is not the same as calling that provider's own API. Your prompt goes to an AWS-operated account, not to the provider. The provider supplied the model; they do not receive the traffic.

On top of that you get the usual AWS controls: encryption with AWS KMS, private connectivity through Amazon VPC and AWS PrivateLink so requests never traverse the public internet, IAM for who may invoke which model, and CloudTrail for the audit record.

This is the single most useful fact in the lesson for a scenario question. When a stem mentions a regulated industry, a data residency rule, or a security review that must approve the vendor, the deployment account isolation is what the answer is built on.

Where Bedrock stops

Bedrock is a good default, and a default is not a universal answer. It serves and customizes models that already exist. Three situations sit outside it.

You want to train a model from scratch, on your own architecture, with your own training loop. Bedrock has no entry point for that.

You need a model that is not in the catalog, or full control over the serving environment, such as a specific inference container, a specific instance type, or deployment inside your own VPC on hardware you chose.

You are doing classical machine learning rather than generative AI. A fraud detection model over tabular transaction data is a gradient-boosted tree, not a foundation model, and Bedrock has nothing to offer it.

Each of those points at the same service, which is the subject of the next lesson.

Exam tips

• Bedrock is the fully managed, serverless path to foundation models. Scenario words such as "no infrastructure to manage," "fastest path to production," or "we do not want to run GPUs" point here.
• One API across many providers is the differentiator to remember. Any question about switching models cheaply, or comparing models without rewriting an application, is testing this.
• Match the capability to the problem: proprietary data in answers means Knowledge Bases; blocking harmful or off-topic content means Guardrails; detecting an ungrounded answer means contextual grounding checks specifically.
• Guardrails evaluate input and output, and ApplyGuardrail works without invoking a model. Options claiming guardrails are output-only are wrong.
• "Train a model from scratch" is the phrase that takes Bedrock off the table. So does "we need full control of the serving container."
• Provider isolation via model deployment accounts is the answer to any question about whether model providers see your prompts. They do not.
• A customized model requires Provisioned Throughput to serve. Remember the pairing; the cost lesson explains why it stings.

The idea to carry forward is that Bedrock trades control for speed, and that trade is usually the right one. The next lesson is about the cases where it is not, and about the service that sits directly underneath.