AWS Bedrock Error: Bedrock Works Locally but Fails in Lambda

#aws#bedrock#devops#cloud

A diagnostic guide for resolving AWS Bedrock invocation failures that occur **only when code runs inside AWS Lambda.

Problem

AWS Bedrock invocation works when run:

• Locally
• From EC2
• From ECS
• From a public subnet

…but fails when the same code runs in AWS Lambda.

Typical symptoms:

• No clear Bedrock service error
• Requests time out or silently fail
• IAM permissions appear correct
• Model access is enabled
• Retries do not help
• Inference never begins

---

Clarifying the Issue

This is not a Bedrock service issue.

This is usually not an IAM issue.

This failure occurs because Lambda’s runtime environment is different from local execution, especially when:

• Lambda is attached to a VPC
• Network egress is restricted
• The execution role differs from local credentials
• The SDK/runtime version differs from local tooling

The most common root cause is network reachability.

---

Why It Matters

This failure pattern is common when:

• Code is tested locally before deployment
• Lambda functions are attached to a VPC “just in case”
• NAT gateways are removed for cost reasons
• Engineers assume Lambda has implicit AWS service access
• Debugging focuses on IAM while the failure is network-level

Lambda behaves differently once placed inside a VPC.

That difference is often invisible until runtime.

---

Key Terms

• AWS Lambda – Serverless compute service
• Execution role – IAM role assumed by Lambda at runtime
• Private subnet – Subnet without direct internet access
• NAT gateway – Enables outbound internet access
• VPC endpoint (PrivateLink) – Private connectivity to AWS services
• Bedrock Runtime – The API endpoint used for inference calls

---

Steps at a Glance

1. Confirm whether Lambda is attached to a VPC
2. Verify outbound network access
3. Check execution role permissions
4. Validate SDK and runtime versions
5. Retest Bedrock invocation

---

Detailed Steps

1. Confirm Lambda VPC Attachment

Check the Lambda configuration:

• Lambda → Configuration → VPC
• If subnets are defined, the function runs inside a VPC

Important behavior:

Attaching Lambda to a VPC removes default internet access.

If the function runs in private subnets, it must explicitly regain outbound access.

---

2. Verify Network Egress

Lambda in a VPC must have one of the following:

Option A: NAT Gateway

• NAT gateway exists in a public subnet
• Private subnet route table includes:

  0.0.0.0/0 → nat-xxxxxxxx

This restores outbound HTTPS access.

Option B: VPC Endpoint (Recommended)

• VPC endpoint for Amazon Bedrock Runtime
• Endpoint associated with Lambda subnets
• Security groups allow HTTPS (TCP 443)

This is the preferred enterprise solution.

Without NAT or an endpoint, the Bedrock request never leaves the subnet.

---

3. Check the Execution Role

Local execution often uses:

• Developer credentials
• Admin roles
• Broad permissions

Lambda uses:

• Its execution role
• Only the permissions explicitly attached

Confirm the role includes:

• bedrock:InvokeModel
• Access to the specific model
• No explicit denies from SCPs or permission boundaries

IAM may look correct locally while failing in Lambda.

---

4. Validate SDK and Runtime Versions

Common mismatch:

• Local machine uses a newer AWS SDK
• Lambda runtime uses an older version

Confirm:

• AWS SDK supports Bedrock Runtime
• Lambda runtime matches tested versions
• No deprecated SDK calls are used

Outdated SDKs can fail silently or throw misleading errors.

---

5. Retest the Invocation

After correcting:

• Network egress
• Role permissions
• SDK/runtime alignment

Retry the Bedrock call.

If invocation succeeds, the failure was caused by Lambda environment constraints, not Bedrock itself.

---

Pro Tips

• Lambda without a VPC has outbound internet by default
• Lambda with a VPC does not
• NAT is a fast fix; VPC endpoints are the scalable solution
• Most “Lambda vs local” failures are network-related
• Bedrock does not run inside your VPC

---

Conclusion

When AWS Bedrock works locally but fails in Lambda, the cause is almost always environmental.

Specifically:

• Lambda VPC attachment
• Missing outbound network access
• Execution role differences
• SDK/runtime mismatches

Fix connectivity first.

Then verify permissions.

Once Lambda can reach Bedrock, inference works normally.

---

Aaron Rose is a software engineer and technology writer at tech-reader.blog and the author of Think Like a Genius.