Skip to lesson

AWSAWS Certified Generative AI Developer - Professional2026-102.4 Implement FM API integrations

Connect compute through explicit invocation contracts

Completed by the knowledge check

Learning objective

Invoke Amazon Bedrock with Converse or InvokeModel using AWS SDKs from supported compute environments.

Core idea

A Bedrock integration joins three contracts: the application’s request and result, the model’s inference interface, and the compute environment’s access to AWS. Choosing an SDK operation solves only the middle contract. A valid payload still fails if the workload has no usable credentials, targets the wrong resource, or cannot reach the service endpoint.

Use Converse for a consistent message interface across models that support it. Use InvokeModel when you need the selected model’s native request and response format. Keep the choice behind an application adapter so callers receive the same application result without knowing every provider field. See 1.2.3 for model-routing configuration and 1.3.6–1.3.7 for detailed payload construction.

The SDK provides service clients and credential resolution. Your integration still owns model eligibility, application authorization, inference deadlines, and acceptance of the generated result.

How it works

Select the runtime operation

Create a Bedrock Runtime client, named bedrock-runtime in Boto3. The Converse request identifies the target through modelId and supplies conversation content through messages. Use system for supported system instructions, inferenceConfig for common inference controls, and additionalModelRequestFields for supported model-specific controls. A consistent interface does not make every content block or control supported by every model.

The following Python example illustrates the boundary without embedding credentials:

import boto3

runtime = boto3.client("bedrock-runtime", region_name="REGION")
response = runtime.converse(
    modelId="MODEL_ID",
    messages=[{"role": "user", "content": [{"text": "INPUT_TEXT"}]}],
    inferenceConfig={"maxTokens": 256},
)

Replace REGION with the chosen AWS Region, MODEL_ID with a supported model or inference-profile identifier, and INPUT_TEXT with the validated application input. The output budget of 256 tokens is an example, not a recommended universal setting. The call returns a Converse response whose output.message, stopReason, and usage require interpretation before the application returns a result.

InvokeModel takes modelId, a model-native JSON body, and contentType, which must be application/json. The accept parameter identifies the desired response MIME type and defaults to application/json. Its response contains body and contentType; decode and validate them using the selected model’s response contract. A Converse messages object is not automatically a valid native payload.

Do not assume InvokeModel means stateless application behavior or that Converse stores your conversation. Your application supplies the history it needs. The difference is the inference interface. InvokeModel also supports model tasks such as image generation and embeddings; the applicable native body depends on the target. See 1.3.9 for conversation history and token budgets.

Resolve credentials for the workload

AWS SDKs use a credential provider chain, stopping when they find usable credentials. Standardized providers renew expiring credentials, but provider support and chain order vary by SDK. Prefer the environment’s workload identity over credentials passed directly into application code. Explicit credentials can override the identity you intended the workload to use.

The following environments have different identity mechanisms:

  • Lambda: The function’s execution role grants access to AWS resources, and Lambda assumes that role when invoking the function. Give it the permissions required by the selected runtime operation.
  • Amazon ECS or Amazon EKS: Use an ECS task IAM role or Amazon EKS Pod Identity to supply workload credentials through the SDK container credential provider. ECS sets AWS_CONTAINER_CREDENTIALS_RELATIVE_URI; EKS Pod Identity sets AWS_CONTAINER_CREDENTIALS_FULL_URI and AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE. Configure these workload identities rather than placing static keys in the image.
  • Amazon EC2: An instance profile supplies temporary role credentials through the instance metadata service and the SDK’s IMDS credential provider.
  • Development or external compute: Use an SDK-supported provider such as IAM Identity Center, assume-role credentials, or an approved process provider. Verify that the deployed SDK supports the chosen provider.

These identities authenticate the workload. They do not prove that an end user may submit a particular document or select a particular model. Apply that application decision before invoking Bedrock.

Target and authorize the inference resource

Both Converse and InvokeModel require the IAM action bedrock:InvokeModel. Allowing bedrock:Converse alone does not authorize the call. The IAM policy examples name bedrock:Converse and bedrock:ConverseStream only as optional extra actions in an explicit deny. Restrict access to the inference resources the workload needs. The API documentation also states that denying all inference on a target requires denying both bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream, covering the corresponding Converse operations.

Configure the SDK client’s Region explicitly or through its supported Region configuration. Treat modelId as a resource selection, not merely a descriptive model name: supported targets include foundation-model identifiers and inference-profile identifiers. Region configuration, target support, and authorization must agree. See 1.2.1 and 1.2.4 for capability and processing-location checks.

For private runtime access from compute in a VPC, use an interface VPC endpoint (AWS PrivateLink) with service name com.amazonaws.REGION.bedrock-runtime, replacing REGION with the AWS Region; the com.amazonaws.REGION.bedrock endpoint serves the separate control-plane API.

Key distinctions and trade-offs

Portable interface versus portable behavior: Converse reduces request-shape differences. It does not guarantee equal quality, supported modalities, or parameter semantics across models. Test the adapter against each approved target.

Workload credentials versus end-user authorization: An execution role enables the backend to call Bedrock. The backend must still enforce the caller’s application permissions before using that role.

Service success versus application success: A successful response can stop at max_tokens, request tool_use, or report guardrail_intervened. Read stopReason and inspect the output contract instead of equating HTTP success with a finished answer. See 2.4.3 for response validation.

Native interfaces expose model-specific features directly, but require additional serializers and decoders. Converse simplifies shared conversational integration, while model-specific controls can still require targeted adapter logic.

Architecture / decision scenario

A support service runs short requests in Lambda and document-processing workers in ECS. Both return the same application result: answer text, completion status, and token usage. Neither caller chooses an arbitrary Bedrock target.

The Lambda execution role and the ECS task role each receive scoped bedrock:InvokeModel access. Their SDK clients use the approved Region and resolve temporary credentials through their respective environments. The application checks document access before building a model request.

The conversational path uses Converse and converts output.message, stopReason, and usage into the application result. A separate model-native path uses InvokeModel, sets contentType, and decodes body with its model-specific adapter. If deployment changes the target, the team tests both serialization and completion handling. Moving the same code to EC2 requires an instance profile and runtime endpoint reachability, using the Bedrock Runtime interface endpoint for private VPC access; it does not require rewriting the public API around a different model payload.

Common exam traps

  • Granting bedrock:Converse instead of the documented bedrock:InvokeModel permission.
  • Passing a Converse payload unchanged to a native model interface.
  • Assuming all Converse models support the same modalities and controls.
  • Embedding static keys because compute is containerized or outside Lambda.
  • Treating workload IAM permissions as end-user authorization.
  • Returning generated content without checking its completion reason.

What to remember

Choose the operation from the required inference contract, then connect it to a correctly configured Runtime client, workload identity, and approved target. Preserve one application result across compute environments, and validate the model response before declaring the request complete.

Knowledge check

References