SOURCE // LABS

Building an OpenAI-Compatible Gateway for AWS Bedrock

Building an OpenAI-Compatible Gateway for AWS Bedrock

The request that kicked this off was simple enough: developers wanted an AI coding assistant in their editors. The constraints, however, were where it got interesting. There could be no AWS credentials on local laptops, no third-party SaaS that would trigger a lengthy data-handling compliance review, and the platform admin had to be able to answer "who spent what" when the bill arrived.

While AWS Bedrock solved the backend issues—providing top-tier models and keeping data strictly within our AWS account—the mismatch lay in the frontend. Bedrock uses its own API and authenticates via AWS SigV4. Conversely, the tools developers actually use—such as Cursor, Continue.dev, aider, and a massive chunk of the LangChain ecosystem—all speak the OpenAI API format (POST /v1/chat/completions with a Bearer token). To bridge these two worlds, a translation layer is mandatory.

The naive solution is to mint individual IAM users for every developer to sign requests locally. This is a severe security anti-pattern, leaving AWS credentials scattered across multiple machines with no per-user throttling or central control. A better approach is building a small API Gateway that speaks OpenAI on the front, translates to Bedrock's Converse API on the back, and manages auth, rate limiting, audit logging, and cost tracking centrally with just one IAM role on the gateway.

This solution has been running reliably in production for a team of developers. While off-the-shelf tools like LiteLLM Proxy and AWS's sample bedrock-access-gateway exist, a custom 80-line translation layer was chosen. This custom setup allows auth to tie directly into our internal identity system and outputs audit logs tailored to our existing tooling, allowing for precise per-developer cost tracking.

[AgentUpdate Depth Analysis] In the fast-evolving AI Agent ecosystem, the Model Gateway is transitioning from a utility to a critical control plane. As frameworks lean towards decopuling agent logic from LLM providers—highly accelerated by the emergence of MCP (Model Context Protocol)—gateways act as the essential bridge. The custom gateway presented here does more than syntax translation; it functions as a policy enforcement point for cost guardrails, security compliance, and potentially dynamic routing across multiple LLMs. While enterprise platforms like #LiteLLM offer broad feature sets, a lightweight, self-built gateway gives enterprise engineering teams absolute sovereignty over their data and telemetry, serving as a robust foundation for secure and scalable Agent architectures.