Skip to main content
In this lesson we examine a common integration pattern: connecting an LLM-enabled application (Amazon Bedrock + Agents) to external REST APIs without building the full orchestration and error-handling layer yourself. What you’ll learn:
  • The integration challenge when agents are not used.
  • How Bedrock Agents provide a managed API abstraction and where Lambda fits.
  • A concise Lambda example that the agent can invoke to call a REST API.
  • The practical benefits of using this pattern in production.
Let’s start with the problem. When your application needs to use a foundation model and also call an external API, you typically must write orchestration code that:
  • Understands user intent.
  • Selects the correct API endpoint.
  • Extracts parameter values (IDs, names).
  • Calls the API with appropriate authorization.
  • Parses the response and feeds it back to the model or UI.
All of this is doable, but it increases code complexity, multiplies surface area for bugs, and makes maintenance harder as you scale integrations.
A slide titled "Problem: Without Agents, REST API Integration Means Extra Code" showing five connected steps (Understand; Pick endpoint; Extract values; Call API; Feed back) and a banner that says this increases code complexity, with an Amazon Bedrock logo at the bottom.
Solution: Bedrock Agents + Lambda-based API abstraction Bedrock Agents can call external tools by invoking an AWS Lambda. In this pattern:
  • The agent decides which tool/action to run (based on an OpenAPI/Swagger description you provide).
  • The Lambda implements the integration: authentication, validation, transformation, retries, and response shaping.
  • The agent receives a simplified, safe result and continues the conversation or returns the final answer to the user.
Below is a simple, production-minded Lambda handler the agent can invoke. The agent passes parameters in the event payload (for example, parameters.orderId). The Lambda validates input, calls the external REST API, handles errors, and returns a compact result to the agent.
Key point: the agent discovers available actions (methods and parameters) through an OpenAPI (Swagger) schema you supply when defining the agent. That schema gives the agent a catalog of methods to choose from, while Lambdas implement the concrete interactions. Reference: OpenAPI Initiative Workflow (step-by-step)
  1. End user submits a request to your Bedrock-powered application.
  2. Your application calls the Bedrock Agent Runtime with a selected agent.
  3. The agent interprets user intent and determines whether a tool/action is required.
  4. If needed, the agent selects an action within an action group and invokes the bound Lambda function.
  5. Bedrock invokes the Lambda; the Lambda calls the external REST API and receives a response.
  6. The Lambda returns a formatted, safe result back to the agent.
  7. The agent composes the final response and returns it to the end user.
A workflow diagram titled "Workflow" showing a seven-step REST + Lambda pattern. It traces a user request through an agent (interpret intent, select API), Bedrock invoking a Lambda, the Lambda calling a REST API and returning data, and the agent responding to the user.
Why place Lambda between the agent and the external API? Putting Lambda in the middle provides clear operational and security benefits:
  • Validation: short-circuit bad requests early and return actionable errors.
  • Mapping & transformation: map user-friendly terms to API parameters, normalize units, or translate schema differences.
  • Authentication: centralize secrets and token refresh logic in Lambda (don’t bake credentials into the agent).
  • Error handling & retries: implement backoff and classify transient vs permanent errors.
  • Response shaping & data protection: redact or summarize PII before returning data to the agent.
A diagram titled "Workflow: Why Not Let the Agent Call the REST API Directly?" showing an Agent connecting to an AWS Lambda which forwards to an External API. Below the Lambda is a vertical list of validation steps (inputs, mapping user-friendly values to API parameters, handle authentication, catch errors, format the response).
Benefits at a glance
Use an OpenAPI schema to teach the agent the available endpoints, parameter types, and required fields. This allows the agent to pick the right action automatically. See the OpenAPI Initiative for authoring guidelines.
Never hard-code secrets in your Lambda. Use environment variables combined with AWS Secrets Manager or IAM roles. Ensure Lambdas have the minimum required permissions.
Getting started: action groups and bindings
  • Define action groups for each logical integration (e.g., Orders API, Inventory API).
  • Provide an OpenAPI schema describing the API surface for the agent to use.
  • Bind each action to a Lambda ARN when creating the agent so the agent can invoke the action at runtime.
  • Keep Lambda functions focused: validation, auth, transformation, call external API, and return a minimal, safe payload.
Further reading and references
  • Amazon Bedrock documentation (start with the Agent Runtime and action groups).
  • OpenAPI Initiative — design and publish consistent API schemas.
  • AWS Lambda best practices (security, retries, and timeouts).
By combining Bedrock Agents (action discovery via OpenAPI) with small Lambda executors, you get a manageable, secure, and testable pattern for letting LLM agents interact with the real world via REST APIs.

Watch Video