AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。
This is a guest post co-written with Roei Zavida from Eon. Independent software vendors (ISVs) building AI-powered products need to connect agents and humans to dozens of operational tools across clouds, each with different authentication models, network boundaries, and access policies. When those tools span AWS, GCP, and Azure simultaneously, the integration surface multiplies. This post describes how Eon used Amazon Bedrock AgentCore, a platform to build, connect, and optimize agents at scale, with any framework or model. Eon used it to replace per-tool credentials and local Model Context Protocol (MCP) processes with a single authenticated gateway. The result gives developers and autonomous agents unified access to investigation tooling across three clouds. New engineers now reach all their investigation tools in about two minutes instead of the two days it previously took to configure credentials and local MCP servers. About Eon Eon provides the Autonomous Data Foundation for the AI era. The platform discovers and classifies cloud resources across AWS, Azure, and GCP. It provides continuous deduplicated backup that reduces storage costs by up to 50 percent in Eon’s internal measurements. It also detects ransomware and rogue-agent damage and delivers live grounded context for AI agents. All of this runs from a single read-only AWS Identity and Access Management (IAM) role, storing data in Apache Parquet and Apache Iceberg formats. Founded by former AWS engineers, Eon runs its software as a service (SaaS) infrastructure on AWS. The challenge Eon’s internal engineering team investigates production incidents across multiple clouds and dozens of operational systems. A crashed Kubernetes pod requires checking container logs, Grafana metrics, the deployment’s GitHub pull request (PR), and cloud-provider health status within the same session. Eon needed to address several key requirements: Credential consolidation — Each new tool added another integration to configure, secure, and rotate, which got harder to keep consistent as the toolset grew. Eliminate local MCP processes — Each developer ran several MCP servers locally, which was hard to standardize and keep current. Identity separation — Engineers accessed each system with role-based permissions, but there was no single place to decide which tools each person or agent could call. Cross-account access without networking overhead — Hosting MCP servers across multiple AWS accounts required virtual private cloud (VPC) peering or AWS PrivateLink per account, multiplying operational cost and setup time. Developer onboarding — New engineers spent roughly 2 days configuring credentials and local MCP servers before investigating their first incident. Agent access — Eon’s autonomous site reliability engineering (SRE) agent (running Claude on Amazon Bedrock) needed the same tool access as humans, but with different permissions. Growing engineering headcount combined with a fast-expanding set of AI tools and MCPs made maintaining credentials and local MCP servers increasingly costly. This pushed Eon toward a centralized solution. Approaches considered Before building on AgentCore, Eon evaluated alternatives: Option 1: Centralized proxy with custom auth Every harness had its own proxy configuration with all the targets. A single reverse proxy aggregating all tools, with a custom authentication layer. This handled credential consolidation but only supported remote MCP and required building and maintaining tool protocol translation, session management, and authorization logic from scratch. The implementation and maintenance burden was significant. Option 2: Amazon Bedrock AgentCore Gateway Amazon Bedrock AgentCore Gateway, a capability of Amazon Bedrock AgentCore, is a managed gateway with built-in identity federation, Cedar-based authorization policies, and Runtime hosting that converts local MCP servers to remote HTTP endpoints. This addressed all requirements without custom infrastructure. Eon chose Option 2 because it provided identity separation, cross-account connectivity, and policy enforcement as managed capabilities rather than code they would need to build and maintain. These were the only two options on the table. Solution overview Eon deployed the full Amazon Bedrock AgentCore stack: AgentCore Gateway, Policy in Amazon Bedrock AgentCore, AgentCore Runtime, and AgentCore Identity, all capabilities of Amazon Bedrock AgentCore. The following diagram shows how client requests flow through the authentication layer to a single gateway. The gateway routes authorized tool calls to targets hosted on AgentCore Runtimes across multiple AWS accounts. Figure 1: Eon’s centralized gateway architecture on Amazon Bedrock AgentCore The architecture has five layers: Clients Developers using Claude Code, Cursor, or OpenAI Codex connect to a single MCP URL. An autonomous SRE agent running Claude on Amazon Bedrock connects to the same gateway with a different identity. Identity plane Corporate single sign-on (SSO) federates through Amazon Cognito, which mints the JSON Web Token (JWT) and hands it to the gateway. Amazon API Gateway sits in front as the OAuth entry point for humans, proxying the MCP session. Agents authenticate with Cognito client_credentials grants directly against the gateway. One gateway, least-privilege access A single AgentCore MCP Gateway serves as the company-wide front door. Cedar policies in ENFORCE mode control which principals can invoke which tools. Read operations are available to selected groups, not every authenticated user. Write operations are limited to low-impact collaboration actions, such as commenting on a PR or ticket, and production tools are read-only. Policy in Amazon Bedrock AgentCore Cedar policies map each principal to permitted tools. Write operations are limited to low-impact collaboration actions, such as commenting on a PR or ticket, and production tools are read-only. The gateway evaluates every tools/call request against Cedar before forwarding to the target. Targets Dozens of target MCP servers exposing hundreds of tools on the one gateway, served by AgentCore Runtimes distributed across multiple AWS accounts. Each Runtime converts local stdio-based MCP servers into Streamable HTTP endpoints accessible through the gateway. A developer opens their integrated development environment (IDE), configures one MCP URL, authenticates through corporate SSO, and the gateway aggregates hundreds of tools into a single tools/list response. No local setup and no per-tool tokens. Identity and access separation The core security decision was enforcing read and write boundaries through Cedar policy at the gateway level. Single gateway, policy-enforced separation: The gateway accepts both JWT tokens (humans through corporate SSO and Cognito) and client_credentials tokens (agents). Cedar policies determine what each principal can do. Humans in approved groups get read access. Write operations require explicit Cedar permits granted only to specific agent identities. Cedar reinforces per-tool granularity: // Agent "sre-bot" can add comments on GitHub PRs permit( principal == Agent::"sre-bot", action == Action::"tools/call", resource == Tool::"github_add_pr_comment" ); // No human principal can invoke mutation tools forbid( principal in Group::"humans", action == Action::"tools/call", resource in ResourceGroup::"write-tools" ); Cedar policies are managed as code through GitHub PRs with review comments, giving the team version control and audit trail on every permission change. Within the gateway, Cedar policies scope tool access by SSO group, and groups map to job role. Engineers have access to development and testing environments by default. Production access follows Eon’s security and compliance controls: it is read-only, granted just-in-time through an approval process, and audited. A new team member’s group is scoped the same way, by role rather than by which service they happen to own. Because every agent action is checked against Cedar in ENFORCE mode and scoped to a least-privilege tool set, the autonomous agent operates within safe, bounded limits. It can only invoke the specific tools its identity is explicitly permitted to call. “Before, our internal agent couldn’t reach the same investigation tools developers used. After, it uses the same Gateway with its own identity and a tighter tool set.” — Roei Zavida, Senior DevOps Engineer, Eon Cross-account connectivity Eon runs Runtimes across multiple AWS accounts, organized by environment or service boundary. AgentCore Gateway reaches each Runtime through IAM cross-account role assumption. The Runtime in Account B trusts the AgentCore Gateway execution role in Account A through a standard IAM trust policy. What this eliminated: VPC peering configuration and route table management across multiple AWS accounts. PrivateLink endpoint costs per account. Security group coordination between accounts. Days of setup per new account (replaced by one IAM trust policy, deployable in minutes). Target attachment patterns: Depending on each tool’s authentication and hosting model, Eon uses two primary attachment patterns. The following table summarizes when to use each pattern and gives an example. Pattern When to use Example Runtime + IAM Tool needs a cloud hop through IAM credentials Grafana queries, Kubernetes API calls Runtime wrapping remote MCP Tool surface needs filtering or credential translation Linear Most targets use Runtime + IAM. Eon only wraps a remote MCP to shrink its catalog or slot in a credential the gateway cannot otherwise supply. Investigation session flow The following flow traces a developer investigating a production incident: Authentication. The developer opens Claude Code (or Cursor/Codex) and connects to the gateway MCP URL. The IDE initiates OAuth through corporate SSO. Cognito issues a JWT carrying the developer’s identity and group memberships. Tool discovery. The gateway aggregates tools/list from dozens of connected targets and returns a unified manifest of hundreds of tools to the IDE. The developer sees all available investigation tools in one list. Tool invocation. The developer asks: “Show me the error rate spike for the payments service in the last hour.” The IDE’s agent selects the Grafana query tool and sends a tools/call request. Policy evaluation. The gateway evaluates the request against Cedar. The developer’s group membership grants access to the Grafana tool. The request passes. Runtime execution. The gateway forwards the request to the Runtime hosting the Grafana MCP server (running in a separate AWS account). The Runtime authenticates to Grafana using a service credential stored in the AgentCore Identity vault, executes the query, and returns results. Cross-tool correlation. The agent follows up by checking the Kubernetes deployment status and the related GitHub PR, each routed to different Runtimes. The developer sees correlated results without switching tools or re-authenticating. Lessons learned at scale Deploying to 100+ developers and approximately 10,000 sessions surfaced production challenges: Managing Cedar policy size Every tool schema that the gateway pre-indexes contributes to Cedar policy size. With dozens of targets exposing extensive tool manifests, Eon’s policy grew toward the size quota. The fix: DYNAMIC listing mode for high-tool-count targets. In DYNAMIC mode, the gateway forwards tools/list calls to the MCP server at request time instead of pre-indexing schemas, adding zero bytes to the policy. The trade-off is that semantic tool search is unavailable for DYNAMIC targets. Eon runs a hybrid configuration: DEFAULT mode for targets requiring per-user OAuth (smaller tool counts, need pre-indexed schemas for the consent flow) and DYNAMIC mode for large-catalog targets. OAuth session binding for standard MCP [truncated for AI cost control]