AWSAWS Certified Generative AI Developer - Professional2026-102.2 Implement model deployment strategies
Join model paths through explicit contracts
Completed by the knowledge check
Learning objective
Combine managed Bedrock APIs and separately hosted FMs in hybrid architectures.
Core idea
A hybrid architecture gives one application access to more than one serving boundary. You might use Amazon Bedrock for a managed conversational model and Amazon SageMaker AI for a separately hosted specialist foundation model. The value comes from assigning each stage to an eligible model path, not from making every path look identical.
Keep the application’s task contract stable while preserving the provider-specific invocation contract. Model routing configuration belongs to 1.2.3, and bounded failover belongs to 1.2.5. Here, the decision is how to compose managed and separately hosted inference without hiding differences that change correctness or operations.
“Hybrid” does not require a model call to be a fallback. Two models can perform different stages of one workflow, or serve different classes of request. Each call must have a purpose, an authorized input, and an output that the next stage can use.
How it works
Identify the actual inference resource
For Bedrock, distinguish the API operation from the resource it invokes. InvokeModel.modelId can identify a base model, an inference profile, a provisioned resource, a Marketplace endpoint, or an imported model. A Bedrock runtime request is therefore not proof that you are consuming a base model on demand. Record the resource identifier alongside the selected operation.
Converse provides a consistent message interface for Bedrock models that support messages. It also accepts model-specific inference parameters. That consistency does not extend automatically to an arbitrary hosted container. If a model does not support the required message or feature contract, a shared adapter cannot make the feature available.
A SageMaker AI call through InvokeEndpoint uses EndpointName, sends Body, and supplies ContentType and Accept as needed by the serving container. Calls use AWS Signature Version 4, and endpoints are account-scoped rather than public anonymous model URLs. The container’s schema, not the Bedrock message schema, defines the bytes it accepts.
Keep this resource mapping explicit. A route record might contain an application capability, a provider path, a resource identifier, and a validated serializer. Treat those as application design fields, not AWS-defined parameter names. See 1.3.6 through 1.3.8 for the detailed message and serialization contracts.
Reach specialist models through Bedrock APIs
Amazon Bedrock Marketplace combines a SageMaker AI-managed endpoint with a Bedrock invocation interface. Subscribe to a model, deploy it to that endpoint, and invoke a compatible model through InvokeModel or Converse, passing the Marketplace endpoint’s ID or ARN as modelId. Check the Marketplace model-compatibility list; API and feature support are not universal. Compatible models can integrate with Bedrock Agents, Knowledge Bases, and Guardrails.
Custom Model Import is another Bedrock path for eligible model artifacts. Submit CreateModelImportJob, obtain the imported model’s ARN, and use it as InvokeModel.modelId. Import and Marketplace deployment are different resources; neither requires your application to use a separate InvokeEndpoint call. Check import architecture and Region support before choosing that route.
Keep authorization attached to each path
Bedrock requires bedrock:InvokeModel for InvokeModel and Converse. Streaming access requires the corresponding bedrock:InvokeModelWithResponseStream permission. Authorize the intended resources, rather than assuming that an execution role permitted to call one model can call every model path.
A SageMaker endpoint called directly through InvokeEndpoint has its own authenticated invocation boundary. A caller that succeeds against Bedrock can still fail against SageMaker because its target, credentials, or allowed endpoint differs. Verify both paths using the deployed caller identity before considering a hybrid route ready.
Separately hosted does not imply that data can be sent there without another decision. Assign the allowed input categories to each route, and make the application check that decision before serialization. Passing an unauthorized document to a specialist model and then filtering its output is too late. Retrieval permissions and evidence filtering are covered in 1.4.6 and 1.5.11.
Make stage outputs inspectable
Do not forward one model’s prose blindly into another model’s instruction field. Define what the first stage produces: for example, a category from an application-defined list, a structured extraction, or a proposed answer accompanied by evidence. Validate that result before using it to choose a resource or construct another request.
For a Bedrock conversational stage, assemble messages and system with explicit ownership of instructions. For a SageMaker stage called directly, encode the validated task in the container’s Body format. An internal representation can preserve task meaning across both; it should not pretend that all native parameters or response fields are equivalent.
Preserve enough provenance to explain the composed result. Record the application request identifier, each invoked resource, the deployed model or container release, the stage outcome, and the validated handoff. These are application records. Do not imply that either invocation API automatically provides a cross-provider workflow trace.
Operate the separately hosted deployment
A SageMaker container you deploy and call directly is a release artifact with a serving contract. See 2.2.5 for model readiness, resource capacity, and the container and health-check requirements.
These requirements remain yours to satisfy when Bedrock handles another stage. A successful managed-model invocation does not establish that the specialist container has loaded, that its output schema is compatible, or that it has enough capacity. Monitor and test the paths separately, then evaluate the whole workflow.
Customization does not always require a separately hosted endpoint. Bedrock documents Provisioned Throughput and custom-model deployments for on-demand inference as ways to use custom models. Check the applicable model support before choosing a hosting boundary solely because the model is customized. Deployment mode and throughput sizing are covered in 2.2.1, 2.2.2, and 2.2.5.
Key distinctions and trade-offs
Composition versus substitution: Composition gives stages different responsibilities. Substitution changes the model serving one responsibility. A specialist extraction model is not automatically a valid replacement for a general conversational model.
Common task contract versus common wire format: Your application can standardize validated inputs and outcomes. Converse.messages and a container-specific InvokeEndpoint.Body still require distinct serializers and decoders.
Bedrock interface versus direct endpoint invocation: Marketplace exposes compatible SageMaker AI-managed models through Bedrock APIs. A SageMaker endpoint you call directly uses its container contract through InvokeEndpoint. Identify the actual resource and interface before assigning responsibilities.
A second path can add a needed capability, but it also adds release coordination, additional latency, and another failure boundary. Require evidence that the extra stage improves the end-to-end result. Do not add a model call merely to make the architecture appear more sophisticated.
Architecture / decision scenario
A technical-support application uses a Bedrock conversational model to draft explanations. A separately hosted domain model extracts equipment fault categories through a SageMaker endpoint. The domain model accepts an approved JSON schema and returns a bounded category set; it is not approved to answer general support questions.
The application validates the equipment input, invokes InvokeEndpoint with the correct ContentType, and rejects malformed extraction results. It then supplies the validated category and authorized supporting evidence to the Bedrock stage through Converse. The application records both resources and the handoff under one request identifier.
The Bedrock stage receives only an extraction result the application has validated.
If the specialist container reports it cannot serve, the application does not replace extraction with an unvalidated Bedrock answer. It applies the task’s defined degraded outcome or the bounded fallback policy from 1.2.5. The team evaluates specialist accuracy, explanation quality, and complete response time together before accepting the hybrid design.
If another specialist model must integrate with Bedrock Agents and Guardrails, the team checks Marketplace compatibility and deploys the eligible model through that path. It does not assume a direct endpoint invocation supplies those integrations. For eligible owned artifacts, it evaluates Custom Model Import separately.
Common exam traps
- Assuming a common adapter makes every model support the same features.
- Treating every Bedrock runtime request as base-model on-demand inference.
- Sending Bedrock message JSON directly to an arbitrary SageMaker container.
- Assuming authorization for one inference path covers the other.
- Using generated prose as trusted routing configuration or instructions.
- Assuming all customized models require separately hosted serving.
- Assuming a SageMaker-hosted model can only be reached through
InvokeEndpoint.
What to remember
- Name each stage’s responsibility and actual inference resource.
- Preserve native invocation, authorization, and output contracts.
- Validate a stage’s result before another stage consumes it.
- Release and observe each serving boundary independently.
- Accept hybrid complexity only when it improves the complete task.
Knowledge check
A support application calls a Bedrock model through Converse and a SageMaker specialist directly through InvokeEndpoint. To share code, the team sends the same Converse messages JSON as the endpoint’s Body, and the container rejects every request. What fixes the specialist call?
Converse with the SageMaker endpoint’s name as modelIdmessages JSON and set ContentType to application/jsonBody schemamessages JSON and drop the fields the container rejectsContentType header does not change the body’s schema, and a directly deployed endpoint is not a Bedrock modelId .A SageMaker specialist extracts an equipment fault category, and a Bedrock model then drafts the customer explanation from it. The specialist returns a category outside the approved set, with a missing evidence field. What should the application do?
A specialist model from Bedrock Marketplace must work with Bedrock Guardrails and Agents. The model appears on the Marketplace compatibility list. Which deployment gives the application that integration?
modelIdInvokeEndpointInvokeEndpointInvokeModel or Converse with the endpoint ID or ARN, and can integrate with Agents, Knowledge Bases, and Guardrails. Calling an endpoint directly uses its container contract and does not bring those Bedrock integrations.A hybrid workflow’s deployed role calls its Bedrock model successfully, but its InvokeEndpoint call to the SageMaker specialist fails with an authorization error. What should the team do?
bedrock:InvokeModel on the SageMaker endpoint’s ARN to the role