A rollout should earn additional authority. Connecting every business API before proving identity propagation, tenant isolation, and retry safety creates a large inventory of unresolved risks behind one convenient endpoint.
Expand AgentCore Gateway by proven capability and bounded failure domain. Choose a target pattern, demonstrate its security and operating behavior, then add tenants and consequential tools through explicit gates.
This final article combines the series’ order lookup and refund examples into a deployment approach. The result is an acceptance process for an AWS-hosted platform, not a universal reference architecture. Target support, prices, quotas, and regional capabilities remain deployment-specific inputs.
Table of contents
Open Table of contents
Choose targets from an integration contract
Gateway’s MCP target types include Lambda, API Gateway REST APIs, OpenAPI, Smithy, and MCP servers. HTTP targets can route directly to Runtime agents and passthrough endpoints, with different behavior from MCP aggregation. HTTP targets do not inherit semantic tool search or capability synchronization. Source: Core concepts for Amazon Bedrock AgentCore Gateway.
Start with the backend contract you need rather than the target type that is easiest to register. A small adapter can be preferable to importing an entire API when the agent only needs a bounded business command.
| Candidate pattern | Useful starting point | Required integration proof |
|---|---|---|
| Lambda | A small curated command adapter | Event/context contract and invocation permissions |
| API Gateway | Existing managed REST operations | Supported API configuration and outbound auth |
| OpenAPI | Selected REST endpoints | Translation, supported schema, identity propagation |
| Smithy | Existing modeled service operations | Operation support and execution-role scope |
| MCP server | Existing curated tool surface | Capability synchronization, auth, and outputs |
| HTTP passthrough or Runtime | Direct HTTP/agent routing | Protocol, policy coverage, session and auth behavior |
This table is a design aid, not a declaration that every authentication or private networking combination is supported. Preserve a per-target evidence record: endpoint, schema digest, credential mechanism, tenant-context path, network route, timeout behavior, and direct-access restrictions.
Read the target-specific documentation and test the intended configuration in the destination account and Region. Do not infer HTTP passthrough enforcement from MCP-tool tests, or Runtime behavior from Lambda behavior.
Solve private ingress and private egress separately
An AgentCore VPC endpoint supports private client access to Gateway APIs through PrivateLink. That is the ingress problem. Gateway-to-target private egress has separate target-specific configuration. Source: Configure Amazon Bedrock AgentCore Runtime and tools for VPC; Configure Amazon Bedrock AgentCore Gateway VPC Egress for Gateway Targets.
Figure 1. Separate network paths: private ingress does not configure or prove private target egress.
AWS documents managed and self-managed VPC Lattice configurations for supported private endpoints. Their ownership, cross-account arrangements, and charging models differ. Source: Connect to private resources in your VPC using VPC Lattice.
Choose managed connectivity when its supported scope fits the environment. Choose a self-managed arrangement when the required ownership and account topology justify the additional resources and operational work. Verify those choices instead of assuming that “private” identifies one standard architecture.
Test DNS resolution, TLS validation, routing, security groups, credential acquisition, and backend authorization separately. Successful TCP connectivity cannot establish that the backend received trusted tenant context. A valid outbound service credential cannot establish that a private route was used.
Document dependencies beyond the tool endpoint, including identity providers, key discovery, secrets access, and telemetry. An otherwise private design may fail when an identity dependency requires an unplanned route.
Confirm per-target auth, private certificate support, cross-account behavior, supported subnets, and regional availability. Use the component-specific documentation alongside Supported AWS Regions; an AgentCore regional endpoint does not prove every desired feature combination is available.
Choose a tenant deployment model deliberately
Compare shared, cohort, and dedicated Gateway deployments by configuration scope, operating cost, and change risk. None removes backend tenant enforcement.
A shared Gateway minimizes repeated deployment work and presents a common tool surface. It also concentrates target changes and policy mistakes. It is suitable only if trusted identity propagation, per-tenant authorization, and consumption accounting remain explicit.
Cohort Gateways group tenants by a meaningful operational boundary: regulatory requirements, target mix, release cadence, or traffic profile. Cohorts reduce the scope of a configuration mistake while retaining some shared operation. Avoid arbitrary grouping that adds deployments without simplifying an actual constraint.
Dedicated Gateways provide narrower configuration scope and can simplify tenant-specific change control. They multiply configuration management, drift checks, evidence collection, and lifecycle work. A dedicated Gateway with shared backend credentials and unscoped queries still has a tenant isolation problem.
Figure 2. Recommended model selection balances change scope against operational duplication.
Document who provisions tenants, rotates credentials, removes obsolete targets, and verifies deletion. Test onboarding and offboarding repeatedly. A model that works for the first customer may become unmanageable if every tenant requires undocumented manual policy edits.
Choose the smallest number of deployment variants that satisfies real constraints. Keep exceptions visible in the registry rather than hiding them in environment-specific scripts.
Budget by operations rather than conversations
The AWS pricing page lists the following rates (last checked 21 October 2026):
| Meter | Published rate normalized for planning |
|---|---|
| Gateway API invocations | $5 per million |
| Search API | $25 per million |
| Policy authorization | $25 per million requests |
| Tool indexing | $0.02 per 100 tools per month |
| Egress to customer-owned VPCs | $0.006 per GB in commercial AWS Regions |
Source: Amazon Bedrock AgentCore Pricing.
Recheck rates, billing definitions, applicable Region, discounts, and additional services before approving a budget. The table is a dated planning reference, not an account-specific quote.
Measure billable operations rather than multiplying a conversation count by an assumed fixed fee. A task can trigger discovery, searches, several invocations, retries, status polling, and policy evaluations. Persistent clients may also generate maintenance traffic.
A first-pass model is invocation volume times its rate, plus search volume times its rate, plus authorization volume times its rate, plus indexing and measured network usage. Determine how those meters overlap from current billing definitions; do not assume that every protocol request produces the same set of charges.
A worked example for the order platform: 2,000 operators, 15 completed tasks each per working day, 22 days a month. Assume each task lists tools once, runs one search, and makes four tool calls, each authorized once by Policy; 40 indexed tools; 300 GB to private targets.
| Meter | Monthly volume | Monthly cost |
|---|---|---|
| Gateway invocations (1 list + 4 calls per task) | 3,300,000 | $16.50 |
| Search | 660,000 | $16.50 |
| Policy authorizations (4 per task) | 2,640,000 | $66.00 |
| Tool indexing (40 tools) | — | $0.01 |
| Private egress | 300 GB | $1.80 |
| Gateway layer | 660,000 tasks | $100.81 |
That is about $0.00015 per completed task. Two observations matter more than the total. Policy authorization is the largest line, so a retry storm costs more in authorizations than in invocations. And 660,000 searches over 8-hour working days average about 63 per minute, well above the default quota of 25 search-based calls per minute. At this scale, cache tool lists in the client and search only when the catalogue is large, or plan the quota increase. Whether discovery-time authorization is billed is not stated on the pricing page; measure it.
Add model inference, backend execution, storage, private connectivity resources, and observability separately. Avoid double-counting networking where one charging mechanism already includes a component. Record which costs are direct measurements and which remain estimates.
Track cost per completed business task alongside success, denial, and retry rates. A cheaper conversation that fails repeatedly is not an improvement. Large outputs, frequent searches, and aggressive job polling deserve attention before optimization of low-volume control calls.
Test the quota envelope you actually share
The AWS quota page lists these defaults (last checked 21 October 2026):
| Constraint | Documented default |
|---|---|
| Targets per Gateway | 100 |
| Tool-call/list/search payload | 6 MB |
| Tool-call/list rate | 200 TPS at Gateway and account levels |
| Tool-call/list concurrent connections | 5,000 at Gateway and account levels |
| Search-based tool-call rate | 25 transactions per minute |
Source: Quotas for Amazon Bedrock AgentCore.
Confirm the exact operation scope, effective account quotas, adjustability, regional constraints, and approved increases. The quota page’s “search-based tool-call” wording must be mapped to your actual search usage; do not reinterpret it as a universal per-tenant allowance.
More Gateways do not automatically provide more account-level capacity. Load-test the intended tenant model against both scopes, along with backend and identity dependencies.
Measure sustained throughput, bursts, latency distribution, payload sizes, throttling, and connection lifetime. Long-lived connections and slow tools can exhaust concurrency before request rate reaches its ceiling. Include discovery storms after client restarts and synchronized polling after jobs are queued.
Use bounded retries with backoff and jitter, but do not retry consequential writes under a new operation identity. Verify that client behavior under throttling does not amplify traffic or duplicate effects.
Capacity headroom should reflect the business recovery objective. A design that barely supports steady traffic may fail during backlog recovery or a tenant onboarding surge.
Expand through acceptance gates
Use four stages with named owners and evidence-based exit criteria. Keep the first stages isolated from consequential production effects.
Figure 3. Recommended expansion depends on tested guarantees and measured cost, not target count.
Stage one: isolated integration. Prove target compatibility, identity propagation, schema translation, and private routing. Run cross-tenant and direct-access tests. Validate candidate policy and observe it in LOG_ONLY within a safely bounded environment before enabling enforcement.
Stage two: read-only pilot. Admit a small tenant cohort. Verify output minimization, cache isolation, object access, latency, and cost attribution. Keep synthetic negative tests running; ordinary users may never exercise the forbidden paths you need to prove.
Stage three: bounded consequential writes. Require exact-intent approval, tenant-scoped idempotency, concurrent retry tests, and reconciliation of ambiguous external outcomes. Rehearse targeted Cedar forbid plus backend containment with the Gateway enforcing.
Stage four: cohort expansion. Increase traffic and tenant count only after account-level capacity, operating ownership, drift detection, and per-task cost meet agreed criteria. Review the same evidence after material target, schema, or identity changes.
For each stage, define a stop condition and restoration procedure. Disabling a tool, pausing new jobs, and reconciling in-flight operations are different actions. Rollback must account for already-committed business effects; reverting infrastructure cannot undo a refund.
What this means in practice
A credible rollout package contains a target support matrix, two independently tested network paths, a justified tenant model, operation-based cost measurements, confirmed quotas, and recorded acceptance results.
Take one lookup and one refund command through that package before importing more APIs. Require evidence that another tenant’s valid identifiers are rejected, duplicate execution is controlled, approval cannot be forged, and containment stops new effects.
Gateway then has a clear role: shared tool access controls with explicit operating boundaries. The application retains the guarantees that make those tools safe to use in a real business.