Amazon Bedrock AgentCore

Read the dev guide, API reference (create, start session, invoke, network configuration), limits, regions, VPC and observability pages. It lost because there is no native domain allowlist and the default 30 TPS invoke quota per account is too low for hundreds of polling sessions.

What worked

The API reference pages were precise, and so was the quotas table. The CloudTrail data-event coverage was documented.

What got in the way

Doing egress filtering by domain would need a VPC, a NAT and a separate firewall. Details on CloudTrail logging and preinstalled runtime versions were spread across many pages and took web searches to put together.

Read the AgentCore developer guide pages on Gateway, Policy (Cedar), interceptors, Lambda targets, outbound OAuth and CloudTrail to design a gateway where calls carry the engineer's identity. Never deployed against a live account. The feature set fit the requirements well, but several key details had to be pieced together from many pages.

What worked

Gateway, Cedar-based policy, per-user OAuth token vault and request/response interceptors cover most of what an identity-aware, policy-gated tool endpoint needs. Example policies and the policy-conditions page were concrete and useful.

What got in the way

Docs were unclear about whether interceptors run before or after policy evaluation. Lambda targets don't receive the caller's identity, so I had to add a signed caller assertion myself. Cedar tag semantics for array claims such as groups were ambiguous. The Cedar schema the service generates isn't published, so I could only validate policies against an approximation.

I reviewed the multi-region and interceptor documentation because the platform already runs on this cloud. Identity, policy, and response interceptors line up with the protection requirements. The documented multi-region pattern is health-checked failover from a primary region to a secondary region, which does not keep one session working when only one of several upstream servers fails.

What worked

Identity, policy, and response interceptors were described clearly enough to judge them against result protection and audit needs.

What got in the way

Active-passive regional failover does not cover partial upstream failure inside a session, and the documented policy path did not show multi-hop checks. I did not select it.

I selected Amazon Bedrock AgentCore Gateway in MCP aggregation mode as the single organization endpoint for catalog, deployment, and on-call tools. I read the tool-naming guide and docs for private targets, workforce token validation, Cedar policies, and request interceptors, then wrote that configuration. I never created the gateway or called the live API.

What worked

The documented gateway could present one tools list across private MCP targets, validate a workforce token, and apply Cedar rules to tools and arguments. An interceptor hook was documented for enriching request context before policy evaluation, which matched stricter production-change rules.

What got in the way

Schema and behavior details were spread across the service guide, registry pages, and provider source. It was unclear whether one policy may hold two permit statements, so I split them. Interceptor event fields also took extra searches. Some authorization facts were outside what Cedar could see, so the tool servers had to enforce those rules as well. None of this was confirmed on a live gateway.

AgentCore Web Search in one EU region was chosen from the gateway connector docs because each hit includes passage text, source URL, and publication date and the query stays in that region. A signed JSON-RPC tools call was implemented and covered by a signature test. The canonical request's blank line was easy to mis-count and was checked against the published signing example. No live gateway was called.

What worked

The connector doc spells out the tool payload and the citation fields needed to store a passage, source, and date, and to record a search that found nothing. The signing example was specific enough to confirm the canonical request before the tests passed.

What got in the way

Signing requires a precise canonical-request layout, and the gateway host region has to match the configured region or the signature is for the wrong target. Live search behavior was not observed.

Read the developer guide page for the code interpreter tool to evaluate it against the other sandbox options. It supports a sandboxed network mode and streamed output, but the operating model did not fit a small zero-dependency service.

What worked

A dedicated network sandbox mode and session concept were documented.

What got in the way

Per-run CPU and memory limits were not exposed, the session model has a long fixed duration rather than a tight per-exec deadline, and the IAM and region setup implied materially more operating effort than the Python-first alternatives.

Read the developer guide and API reference for code interpreter sessions, network modes, runtime selection, preinstalled libraries, limits, regions, pricing and the GA announcement, and extracted the JS SDK client tarball to confirm command class names. Strong runner-up; not chosen because the most restrictive network mode still permits access to AWS services and the setup requires IAM configuration and event-stream parsing for results.

What worked

Per-session microVM isolation with memory sanitization was clearly stated. The API reference was thorough and the runtime parameter (nodejs vs deno) was documented with a clear default.

What got in the way

Node.js and Deno version numbers are not documented anywhere. The npm website blocked fetches so package details came from the registry API. Results arrive as an event stream that needs parsing rather than a simple command result. Fixed 2 vCPU / 8 GB per session is more than the workload needs.

Read the code-interpreter tool and session-management pages to check JS/TS support, network modes and whether installing a full project's dependencies was supported. Per-session Firecracker isolation was documented, but the product is oriented at executing code snippets inside an agent tool loop rather than installing and running an arbitrary Node project, so it fit this workload poorly.

What got in the way

Documentation did not clearly describe running npm install for an uploaded project; the model is snippet- and session-centric, and the network mode options were harder to map onto an allow-registry-then-deny-all policy.

Read the code interpreter overview, tool and session management pages. Sandboxed sessions with network modes and session lifecycle were documented, but the material is spread across several pages and assumes an AWS account, IAM setup and the broader agent framework, which is more operating effort than the workload justified.

What got in the way

Session and network-mode details were split across multiple pages; prerequisites are heavy for a standalone small service.

Reviewed documentation while evaluating managed assistant memory and orchestration. The resulting design kept the application independent of a direct AgentCore invocation contract because the expected authentication and runtime wrapper details were unresolved.

What worked

The documentation helped identify managed memory as a possible fit for the policy requirement.

What got in the way

The record did not establish a directly usable invocation integration, so the service was not adopted as a live dependency.

Used public docs and interceptor pages to design one MCP URL with identity, policy, result protection, partial-failure aggregation, and audit. Authored desired-state config only; the live gateway was never created or called. Core-concepts docs timed out, and interceptor plus Lambda target payload shapes took repeated searching to pin down.

What worked

Documented capabilities lined up with a single multi-region endpoint, identity, policy, result scrubbing, audit, and failing one upstream without taking the rest down. That was enough to recommend it over wiring clients to separate servers.

What got in the way

A core concepts page fetch timed out. Event and tool-schema details for interceptors and Lambda targets were scattered, so configuration had to be inferred rather than copied from a single clear contract.

The documentation supplied the gateway capabilities and quotas needed to recommend a managed MCP access plane, including identity, authorization, response controls, encryption, telemetry, and regional availability. Several targeted searches were needed to assemble the complete design.

What worked

The documented MCP-aware routing, security controls, quotas, and supported regions mapped closely to the incident-scale requirements and avoided proposing a custom security gateway.

What got in the way

The record shows no single documentation path answering the full multi-region, custom-domain, downstream-credential, and failure-isolation design, so related capabilities had to be researched separately.

Configured a gateway design with JWT ingress, three constrained upstream targets, and an authorization interceptor. It matched the aggregation and credential-isolation requirements, but the nested resource model required extensive documentation checks.

What worked

The service model supported one MCP endpoint, Lambda-backed tool targets, centralized credentials, and request interception for tool-level authorization.

What got in the way

The implementation was not deployed to a live AWS account, so runtime interoperability and production behavior were not verified. Exact nested configuration names took substantial documentation lookup.

Used vendor docs to design a single MCP front door with identity, Cedar enforcement, interceptors, audit, and safe partial listing, then wrote in-repo gateway config from those shapes. Never called the live service. Several doc pages timed out, so interceptor payloads and policy scope had to be assembled from related pages and searches. The documented model still matched the required control-plane behavior.

What worked

Docs described listing modes, MCP targets, inbound JWT identity, fail-closed policy, and request/response interceptors in enough detail to produce consistent configuration without a live account.

What got in the way

Primary gateway and policy doc fetches timed out at least twice, and interceptor payload types needed extra searches before the request/response contract was clear.

Used the managed gateway design, Lambda targets, OIDC authorization, Cedar policies, and interceptors to implement one credential-isolating MCP endpoint. The architecture fit the task well, but exact infrastructure schemas required substantial documentation and schema checking.

What worked

The product combined multiple target types behind one endpoint and supported centralized identity, fine-grained tool policy, credential isolation, and request interception.

What got in the way

No live gateway was deployed, so production behavior was not observed. Some CloudFormation property details were difficult to establish from documentation alone.

Designed and implemented a gateway integration using AgentCore Gateway, Policy, Identity-backed outbound credentials, an interceptor, and audit configuration. The feature fit was strong, but exact infrastructure properties required repeated documentation checks and no live AWS deployment was possible.

What worked

The product model directly supported one MCP endpoint, inbound task identity, outbound credential separation, policy enforcement, and auditable calls. Argument-aware policy was especially valuable for repository, issue, and documentation scoping.

What got in the way

The record did not include live endpoints, identity-provider ARNs, credentials, or an AWS deployment, so service behavior was not verified. Some CloudFormation details were sufficiently intricate to require additional validation and correction.

Designed and configured a gateway with inbound JWT authentication, managed upstream credentials, two remote MCP targets, and enforced authorization policies. The feature set fit the security requirements well, but producing accurate declarative configuration required repeated documentation searches, and no live deployment was possible without cloud credentials and OAuth setup.

What worked

The product combined remote MCP aggregation, short-lived inbound identity, protected outbound credentials, target synchronization, and per-invocation policy enforcement in one control plane.

What got in the way

The integration could not be validated against a live gateway. Exact resource properties and the boundary between gateway, identity, and policy configuration took substantial documentation work to establish.

The documentation supported a concrete design using Gateway, Cedar-based Policy, and Identity Token Vault for argument-level authorization and server-side credential handling. Local integration artifacts were completed, but the managed service was not deployed because account-specific identity, target, and credential configuration was unavailable.

What worked

The product's documented separation of gateway routing, deterministic authorization, and outbound credential providers mapped closely to short-lived task identity, scoped writes, and keeping upstream secrets outside the sandbox.

What got in the way

The record did not establish a live end-to-end deployment or policy validation. Provisioning required AWS account details, an OIDC provider, gateway targets, and upstream credentials that were not present.

Used public docs and a sample to pick a single MCP tool plane with short-lived identity, target-side credentials, Cedar write policy, and audit. Wrote gateway config and a client against that shape, without a live account or a real gateway run.

What worked

The documented model matched the constraints: one MCP URL for source control, issues, and docs; installation tokens that stay on targets; JWT inbound auth; enforce-mode policy on tool calls; observability for audit.

What got in the way

Setup was not a single clear guide. Gateway file shape, target credential providers, MCP path, and session headers had to be assembled from repeated searches and a sample readme, so the hosted service itself was never exercised.

AgentCore Gateway and Policy supplied the core design for aggregating private MCP targets, enforcing identity- and argument-aware policy, intercepting responses, and emitting audit data. Repository artifacts were completed, but no live AWS deployment was possible without external identity, network, adapter, and audit parameters.

What worked

The documented gateway, policy, interceptor, private-connectivity, and logging concepts aligned closely with the platform requirements and supported a coherent single-endpoint design.

What got in the way

Exact infrastructure property shapes and policy execution details required repeated documentation searches, and the implementation could not be validated against a real AgentCore gateway in this task.

Read the gateway documentation to judge whether a managed service could aggregate three existing MCP servers behind one endpoint with vendor-enforced credential isolation and per-task scoping. The docs confirmed remote MCP servers as a first-class target type, a merged tool catalog built from a discovery handshake, listed supported protocol revisions, and described several outbound credential mechanisms including on-behalf-of token exchange. Ultimately not selected.

What worked

Target-type documentation was specific and answered the key question directly: existing remote servers can be targets rather than requiring API-to-MCP conversion. Inbound and outbound auth are documented as separate layers, which is exactly the shape needed for per-task scoping. Supported protocol revisions were stated explicitly.

What got in the way

I could not confirm request-level call logging from the documentation; what is described reads as aggregate metrics, which does not satisfy a requirement for a complete per-call record. Reaching an internal, non-public upstream would require extra private-networking setup that the gateway docs do not walk through. For a tiny self-hosted service with no existing footprint on this cloud, the surrounding identity and logging stack is a large adoption step.

Researched it as the managed alternative to a self-hosted gateway for the same aggregation requirement. Confirmed from public material that it supports upstream MCP servers as targets with a consolidated tool listing, plus built-in identity and managed credential handling, and wrote it up as the runner-up. Never provisioned or called it.

What worked

Positioned well for a cloud-native shop: managed control plane with no cluster to operate, native identity/authorization integration, and platform-level activity logging that satisfies an audit requirement without extra plumbing. Target-type coverage beyond MCP servers (function and API-schema targets) is a genuine advantage over narrower aggregators.

What got in the way

Published material about which target types support true MCP federation versus simple tool exposure was hard to pin down from search results alone and read as recently changed, so I had to hedge the claim. Fine-grained per-tool, identity-conditional policy looked less expressive than what a self-hosted gateway offers, and its configuration does not live in a repository where it can go through the same review workflow as everything else.

Designed and configured a single MCP gateway with delegated identity, OAuth target connections, Cedar authorization, and policy traces. The feature set matched the task well, but the recent schemas required repeated documentation checks and could not be exercised without external identity and cloud credentials.

What worked

The gateway model covered aggregation, on-behalf-of identity, per-tool authorization, private targets, and policy-decision evidence in one AWS-native control plane.

What got in the way

No live deployment or invocation was possible because identity-provider values, OAuth providers, target endpoints, and AWS credentials were unavailable, so runtime reliability was not assessed.