Bedrock Errors

This page covers common Amazon Bedrock Amazon Bedrock
Amazon Bedrock — a fully managed service for accessing foundation models (embedding and LLM) via a unified API. errors you may encounter when running the ingest or query Lambda Lambda
AWS Lambda — serverless compute. This project uses two functions: ingest (RSS → embed → store) and query (search → answer). functions. Each section shows what the error looks like in CloudWatch, explains the root causes, and provides step-by-step resolution.

AccessDeniedException

This is the most common Bedrock error. It means the calling identity is not authorized to invoke the requested model.

What you see in CloudWatch

botocore.exceptions.ClientError: An error occurred (AccessDeniedException)
when calling the InvokeModel operation: You don't have access to the model
with the specified model ID.

Root causes

Cause	Details
Model access not enabled	The Titan Embeddings V2 Titan Embeddings V2 Amazon Titan Embeddings V2 (amazon.titan-embed-text-v2:0) — converts text into 1024-dimensional vectors for similarity search. or LLM has not been enabled in the Bedrock console for your account and region.
IAM policy missing bedrock:InvokeModel	The Lambda execution role does not include the bedrock:InvokeModel action for the model ARN.
Wrong region	The Lambda is deployed in a region where the model is not available or not enabled.
Inference profile Inference profile A Bedrock cross-region inference profile that routes requests to the nearest available region. Used for the LLM (au.anthropic.claude-sonnet-4-5-20250929-v1:0). not available	Cross-region inference profiles require model access enabled in ALL regions the profile routes to.

Step-by-step resolution

1. Check model access in Bedrock console:

aws bedrock list-foundation-models \
  --query "modelSummaries[?modelId=='amazon.titan-embed-text-v2:0'].modelId" \
  --output text

If the model appears but you still get access errors, enable it explicitly:

• Open the Bedrock console → Model access → Enable specific models
• Select Titan Embeddings V2 and the LLM you are using
• Wait for status to change to Access granted

2. Verify the IAM policy:

aws iam get-role-policy \
  --role-name your-ingest-lambda-role \
  --policy-name your-policy-name \
  --query "PolicyDocument.Statement[?Action=='bedrock:InvokeModel'].Resource"

Confirm the resource ARN matches the model ID exactly:

arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-embed-text-v2:0

3. Check the region:

aws bedrock list-foundation-models --region us-east-1 \
  --query "modelSummaries[?modelId=='amazon.titan-embed-text-v2:0'].modelId"

If empty, the model is not available in that region. Redeploy to a supported region.

4. For inference profiles, enable in all routed regions:

aws bedrock get-inference-profile \
  --inference-profile-identifier "your-profile-arn" \
  --query "models[].modelArn"

Enable access in each region listed.

Verify the fix

Invoke the Lambda manually and confirm a successful response:

aws lambda invoke \
  --function-name your-ingest-function \
  --payload '{}' \
  --cli-binary-format raw-in-base64-out \
  output.json && cat output.json

A 200 response with no error key confirms the fix worked.

ThrottlingException

Bedrock Bedrock
Amazon Bedrock — a fully managed service for accessing foundation models (embedding and LLM) via a unified API. enforces per-model, per-account rate limits (tokens per minute and requests per minute).

What you see in CloudWatch

botocore.exceptions.ClientError: An error occurred (ThrottlingException)
when calling the InvokeModel operation: Too many requests, please wait
before trying again.

Root causes

Cause	Details
Burst during batch ingest	Ingesting many documents at once exceeds the default requests-per-minute quota for Titan V2 Titan V2 Amazon Titan Embeddings V2 — the Bedrock foundation model used to generate 1024-dimensional text embeddings. .
Account-level quota too low	Default Bedrock quotas are conservative for new accounts (e.g., 100 RPM for embedding models).
Concurrent Lambda invocations	Multiple concurrent ingest Lambdas all hitting Bedrock simultaneously.

Built-in retry behavior

The ingest Lambda includes exponential backoff with jitter — up to 6 retry attempts. Most transient throttling resolves within retries.

Note

If you see ThrottlingException in logs but the function completes successfully, the retries handled it. Only investigate if the function returns an error or times out.

Step-by-step resolution

1. Check CloudWatch metrics for throttling:

aws cloudwatch get-metric-statistics \
  --namespace AWS/Bedrock \
  --metric-name Invocations \
  --dimensions Name=ModelId,Value=amazon.titan-embed-text-v2:0 \
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 300 \
  --statistics Sum

2. Check current quota:

aws service-quotas get-service-quota \
  --service-code bedrock \
  --quota-code L-EXAMPLE12345 \
  --query "Quota.Value"

Tip

Find the exact quota code in the Service Quotas console under Amazon Bedrock → Titan Embeddings V2 model invocations.

3. Request a quota increase:

aws service-quotas request-service-quota-increase \
  --service-code bedrock \
  --quota-code L-EXAMPLE12345 \
  --desired-value 500

4. Reduce concurrency (temporary mitigation):

Lower the Lambda reserved concurrency to limit parallel Bedrock calls:

aws lambda put-function-concurrency \
  --function-name your-ingest-function \
  --reserved-concurrent-executions 2

Verify the fix

After a quota increase takes effect (usually within minutes), trigger another ingest and confirm no ThrottlingException appears in CloudWatch Logs:

aws logs filter-log-events \
  --log-group-name /aws/lambda/your-ingest-function \
  --start-time $(date -u -d '5 minutes ago' +%s)000 \
  --filter-pattern "ThrottlingException"

An empty result means throttling is resolved.

ValidationException

Bedrock returns this when the request body does not meet the model’s input requirements.

What you see in CloudWatch

botocore.exceptions.ClientError: An error occurred (ValidationException)
when calling the InvokeModel operation: Malformed input request: expected
maxTokens to be integer, got null

Or for embedding input issues:

botocore.exceptions.ClientError: An error occurred (ValidationException)
when calling the InvokeModel operation: 1 validation error detected: Value
at 'body.inputText' failed to satisfy constraint: Member must not be null

Root causes

Cause	Details
Empty input text	An empty string or None was passed as inputText to the embedding model.
Text exceeds token limit	Titan Embeddings V2 supports up to 8,192 tokens per input. Very long documents without truncation will fail.
Malformed request body	Missing required fields, wrong data types, or invalid JSON in the InvokeModel body.

Step-by-step resolution

1. Check for empty inputs:

Review the ingest Lambda logs for the document that failed. Look for empty content after HTML stripping:

aws logs filter-log-events \
  --log-group-name /aws/lambda/your-ingest-function \
  --filter-pattern "ValidationException" \
  --limit 5

2. Verify text length:

Titan Embeddings V2 Titan Embeddings V2
Amazon Titan Embeddings V2 — the Bedrock foundation model used to generate 1024-dimensional text embeddings. accepts up to 8,192 tokens (roughly 30,000 characters of English text). The ingest function truncates content before embedding. If you see this error, confirm the truncation logic is working:

aws logs filter-log-events \
  --log-group-name /aws/lambda/your-ingest-function \
  --filter-pattern "inputText" \
  --limit 3

3. Validate the request body format:

The correct format for Titan Embeddings V2:

{
  "inputText": "Your text here",
  "dimensions": 1024,
  "normalize": true
}

Ensure inputText is a non-empty string, dimensions is an integer, and normalize is a boolean.

Caution

If an RSS feed item has no content (only a title), the ingest function may pass an empty string to the embedding model. The code should skip items with empty body text.

Verify the fix

Trigger a test ingest and confirm embeddings are generated without errors:

aws lambda invoke \
  --function-name your-ingest-function \
  --payload '{"source": "test"}' \
  --cli-binary-format raw-in-base64-out \
  output.json && cat output.json

ModelNotReadyException

This occurs when you have just enabled a model in Bedrock but it is not yet available for inference.

What you see in CloudWatch

botocore.exceptions.ClientError: An error occurred (ModelNotReadyException)
when calling the InvokeModel operation: The model is not ready to serve
inference requests. Please wait and try again.

Root causes

Cause	Details
Model just enabled	After enabling model access, there is a provisioning delay (typically 5–10 minutes).
Deployed too quickly after enabling	Running terraform apply immediately after enabling model access may hit this window.

Step-by-step resolution

1. Wait 10 minutes after enabling model access before invoking.

2. Check model access status:

aws bedrock get-foundation-model-availability \
  --model-id amazon.titan-embed-text-v2:0

Tip

If you are deploying via Terraform for the first time, enable model access in the Bedrock console at least 10 minutes before running terraform apply. This avoids the Lambda bootstrapping against an unavailable model.

3. Retry the Lambda: The built-in retry logic will handle this if the delay is short. For longer delays, manually invoke after waiting:

aws lambda invoke \
  --function-name your-ingest-function \
  --payload '{}' \
  --cli-binary-format raw-in-base64-out \
  output.json

Verify the fix

A successful invocation with no ModelNotReadyException confirms the model is ready. Check that the function returns embedded vectors:

aws logs tail /aws/lambda/your-ingest-function --since 2m \
  | grep -i "successfully"

ServiceUnavailableException

A transient error indicating the Bedrock service itself is experiencing issues.

What you see in CloudWatch

botocore.exceptions.ClientError: An error occurred
(ServiceUnavailableException) when calling the InvokeModel operation:
The service is temporarily unavailable. Please try again later.

Root causes

Cause	Details
Bedrock service disruption	Temporary capacity issues in the Bedrock service. Typically resolves within minutes.
Regional capacity constraints	High demand in a specific region may cause brief unavailability.

Step-by-step resolution

1. Check AWS Health Dashboard:

Visit the AWS Health Dashboard to see if there is an active Bedrock incident in your region.

2. Wait and retry: The Lambda’s exponential backoff handles transient issues. If the function timed out, invoke it again after a few minutes:

aws lambda invoke \
  --function-name your-ingest-function \
  --payload '{}' \
  --cli-binary-format raw-in-base64-out \
  output.json

3. Check if the issue persists:

aws logs filter-log-events \
  --log-group-name /aws/lambda/your-ingest-function \
  --start-time $(date -u -d '30 minutes ago' +%s)000 \
  --filter-pattern "ServiceUnavailableException"

Note

If ServiceUnavailableException persists for more than 30 minutes and no AWS Health event is reported, open an AWS Support case.

Verify the fix

Once the service recovers, confirm by running a successful invocation. Check CloudWatch for clean executions:

aws logs tail /aws/lambda/your-ingest-function --since 5m \
  | grep -c "ERROR"

A count of 0 confirms normal operation.

ResourceNotFoundException

Bedrock cannot find the model or inference profile you specified.

What you see in CloudWatch

botocore.exceptions.ClientError: An error occurred
(ResourceNotFoundException) when calling the InvokeModel operation: Could
not resolve the foundation model from the provided model identifier.

Or for inference profiles:

botocore.exceptions.ClientError: An error occurred
(ResourceNotFoundException) when calling the InvokeModel operation: The
inference profile 'arn:aws:bedrock:us-east-1:123456789012:inference-profile/us.invalid.model' does not exist.

Root causes

Cause	Details
Wrong model ID	Typo in the model identifier (e.g., amazon.titan-embed-text-v2 instead of amazon.titan-embed-text-v2:0).
Inference profile does not exist	The ARN references a profile that was never created, was deleted, or is in a different account.
Model not available in region	Some models are only available in specific regions. Using a model ID in an unsupported region returns this error.

Step-by-step resolution

1. Verify the model ID:

aws bedrock list-foundation-models \
  --query "modelSummaries[?contains(modelId,'titan-embed')].modelId" \
  --output table

The correct embedding model ID is:

amazon.titan-embed-text-v2:0

Caution

The :0 version suffix is required. Omitting it causes a ResourceNotFoundException.

2. Verify inference profile exists:

aws bedrock list-inference-profiles \
  --query "inferenceProfileSummaries[].inferenceProfileArn" \
  --output table

3. Check your Terraform Terraform
   HashiCorp Terraform — infrastructure-as-code tool used to provision all AWS resources in this demo. variables:

Confirm the model IDs in your Terraform variables match exactly:

grep -r "model_id" terraform.tfvars

Expected values:

• Embedding: amazon.titan-embed-text-v2:0
• LLM inference profile: check the profile ARN in your account

Verify the fix

After correcting the model ID or profile ARN, redeploy and test:

terraform apply -auto-approve
aws lambda invoke \
  --function-name your-ingest-function \
  --payload '{}' \
  --cli-binary-format raw-in-base64-out \
  output.json && cat output.json

A successful response confirms the resource is found.