6.1 Bedrock Core Concepts, Model Access, and Managed FM Choice

Bedrock as the managed foundation model layer

Amazon Bedrock is a fully managed AWS service for building generative AI applications with foundation models. It gives teams a single managed place to access model providers, test prompts, run inference, customize models where supported, connect private data through Knowledge Bases, automate workflows through Agents, apply Guardrails, and evaluate model behavior. The practitioner-level point is not to memorize every model. It is to recognize Bedrock when the organization wants managed FM capabilities without standing up GPU infrastructure or building a full model platform.

A useful mental model is that Bedrock sits between business applications and foundation models. The application sends prompts, documents, messages, images, or other supported inputs to Bedrock runtime APIs such as Converse or InvokeModel. Bedrock routes the request to the selected model or inference profile and returns the response. The team still owns the application design, data permissions, user experience, risk review, and monitoring decisions.

Model access is a real deployment dependency. AWS documentation now describes default access to many Bedrock foundation models when the right AWS Marketplace permissions are present, while some third-party providers can still require first-use agreement steps or use-case details. Administrators can also restrict access with IAM policies and organization Service Control Policies. In a scenario, do not assume the model is unavailable because it has not been trained by your company. Also do not assume every user may call every model in every Region.

Model selection should begin with the task. A short customer-service response, a long legal summary, an image generation workflow, a multimodal document-understanding flow, and an embedding pipeline may need different models. Larger models often produce stronger reasoning or language quality, but they can cost more and respond more slowly. Smaller models can be appropriate for classification, extraction, routing, and high-volume internal tools when the prompt and evaluation show acceptable quality.

Bedrock does not remove responsibility for prompt design. A model can be powerful and still fail if the prompt lacks role, task, context, format, constraints, examples, or grounding. A responsible team creates a prompt template, tests expected and adversarial cases, defines refusal behavior, and logs enough metadata to investigate issues. The non-builder approving the solution should ask what success metric will prove that the selected model is good enough for the business workflow.

Distinguish Bedrock from SageMaker AI. Bedrock is the usual managed choice for teams that want to consume or customize foundation models, build RAG, use agents, or add guardrails without managing training and hosting infrastructure. SageMaker AI is more appropriate when the team needs deeper control over custom model development, training, feature engineering, ML pipelines, notebooks, experiments, or model hosting choices. The AIF-C01 target candidate does not need to implement those pipelines, but should recognize the service boundary.

A conservative Bedrock adoption path starts small. Pick one bounded workflow, such as drafting support replies from approved articles or summarizing call notes. Select two or three candidate models, use the same evaluation prompts, compare quality and latency, add guardrails for sensitive data and unsafe content, and run a human review pilot. Then estimate token usage, peak concurrency, retrieval needs, and support process changes before expanding.

Checklist for approving a Bedrock use case:

• The task tolerates probabilistic outputs or includes human review where accuracy risk is high.
• Required data sources, retention rules, and privacy constraints are known before prompts are designed.
• The model shortlist is based on modality, quality, latency, cost, Region support, and terms of use.
• IAM permissions, SCPs, and AWS Marketplace requirements are checked before rollout.
• Evaluation prompts represent real work, edge cases, and unacceptable answers.
• Monitoring, logging, guardrails, and fallback behavior are defined before production use.

Skill Builder practice should be hands-on but bounded. Open the Bedrock console in a permitted training or sandbox account, review the model catalog, compare playground responses for the same prompt, and notice which settings change output length and style. Then ask what would need to change before this prompt could be used in a real customer-facing workflow. That habit turns model demos into operational judgment.