re:Invent 2025 - Modernize containers for AI agents using AgentCore Gateway

Many organizations have invested years building reliable, containerized business logic on Kubernetes. The challenge today is not rebuilding those systems, but connecting them to AI agents without duplicating code or introducing new operational burden. Writing new Model Context Protocol (MCP) server wrappers for hundreds of microservices would consume an entire engineering team for a full year. In this post, we'll walk through how Roland Barcia, AWS Worldwide Director for Specialist Technology and Architecture, and Carlos Santana, AWS Senior Specialist Solutions Architect for Containers, demonstrated a better path at re:Invent 2025 session CNS422. Using Amazon Bedrock AgentCore Gateway, they showed how platform engineers can expose existing REST APIs as MCP tools in minutes, using OpenAPI specifications that most teams already maintain.

Converting existing APIs into agent tools

The demo scenario centered on a home insurance company with three microservices running on Amazon Elastic Kubernetes Service (Amazon EKS): an appointments service, a customer and claims service, and a technician scheduling service. Each already had a Swagger/OpenAPI specification published through a standard API documentation endpoint. The problem was practical: an AI agent needed to call these services, but nobody wanted to build, containerize, deploy, and operate three separate MCP servers in addition to the services that already existed.

AgentCore Gateway solves this by accepting an OpenAPI specification file stored in Amazon S3 and automatically generating MCP-compatible tool endpoints from it. Carlos walked through a Python setup script using the Boto3 SDK, which fetches each microservice's JSON spec, injects the server URL (a field required by the gateway but frequently absent from auto-generated Swagger files), uploads the enriched spec to S3, and calls the gateway API to register each target. Three microservices became three gateway targets, each surfaced as a callable MCP tool, with no MCP server code written at all.

One gateway instance supports multiple targets, so the architecture scales as your microservice estate grows. Teams can add new services by uploading a spec and registering a new target rather than deploying additional server processes. The gateway also supports semantic search across registered tools, which becomes meaningful when you have dozens or hundreds of tools and need the agent to find the right one without being explicitly told which to call.

Securing agent access with AgentCore Identity

Exposing internal APIs to an AI agent creates an authorization challenge: only the intended agent should be able to call those tools, and credential management should not become a manual handoff between teams. Carlos demonstrated how AgentCore Identity addresses this through integration with Amazon Cognito.

The setup script creates a Cognito user pool, configures a resource server with read and write scopes, stores the client secret in AWS Secrets Manager, and registers an identity provider with AgentCore Identity. When the AI agent makes a request, AgentCore Identity handles the machine-to-machine (M2M) token exchange with Cognito on the agent's behalf. The agent code never holds the client secret directly. Instead, a Python decorator pattern in the agent code calls the Identity SDK to fetch a refreshed access token before each gateway request, following the security practice of short-lived credentials without requiring the developer to manage that logic manually.

The inbound connection to the agent itself is also protected. The chat UI communicates with AgentCore Runtime using an API key stored in Secrets Manager. This layered approach means credentials are centrally managed and rotatable, and the only configuration exchanged between the platform team and the agent team is a gateway URL and an identity provider name stored as parameters in AWS Systems Manager Parameter Store.

The agent developer experience

Roland's side of the demo reflected how the pattern is designed to look from an agent developer's perspective: minimal infrastructure knowledge required. The agent code retrieves its configuration from SSM Parameter Store, initializes an MCP client pointed at the gateway URL using the streamable HTTP transport, requests the list of available tools, and passes them to a Strands Agents SDK agent. The model powering inference was Claude Haiku 4.5 from Anthropic, accessed through Amazon Bedrock.

The agent is deployed to AgentCore Runtime, a serverless execution environment that handles observability, session management, and scaling without the developer managing containers directly. The agent is also wrapped as an Agent-to-Agent (A2A) server, meaning future orchestration scenarios where another agent calls this one are already supported by the current deployment. The chat UI was built with Gradio and deployed to Amazon Elastic Container Service (Amazon ECS) with AWS Fargate, though Roland ran it locally for the demo.

The live demo illustrated the full call path. A user reported that a refrigerator had flooded the kitchen after an overly enthusiastic salsa dancing incident. The agent identified the user's policy, filed an urgent claim marked as high priority, and scheduled a technician appointment, with each step calling a different microservice through the gateway. No step required the user to specify which API to call. The agent reasoned across multiple tool calls, guided by the system prompt and the tool descriptions pulled from the OpenAPI specs.

Key takeaways

This session makes a practical case that the path from containerized microservices to agentic capabilities does not require rebuilding your APIs or your team structure. If your team maintains OpenAPI specifications for existing REST APIs, AgentCore Gateway can convert them into MCP tools through a straightforward automation script. AgentCore Identity removes the need to distribute credentials manually between infrastructure and application teams. AgentCore Runtime gives agent developers a serverless target that handles operational concerns without requiring Kubernetes knowledge.

The division of responsibilities shown in the demo is worth adopting as a pattern. Platform engineers own the EKS cluster, the OpenAPI specs, the gateway configuration, and the identity setup. Agent developers receive a gateway URL, an identity provider name, and the freedom to focus on agent logic and prompt engineering. That clean interface between roles is what makes this approach practical to scale across a large microservice estate.

Watch the full session recording: https://youtu.be/6autfsn1fy8