AWS Builder Center

Builder Center

Networking Patterns for ISVs Distributing AI Agent Tools via Amazon Bedrock AgentCore Gateway

This post presents two architecture patterns for ISVs that host AI agent tools (MCP servers) and need to securely distribute them to multiple customer tenants across AWS accounts. Pattern A covers an ISV-hosted centralized gateway with Cedar-based per-tenant isolation. Pattern B covers a customer-owned gateway consuming ISV tools cross-account via VPC Lattice and AWS RAM — with no Transit Gateway or VPC peering required.

Mariusz Ilnicki

Introduction

The Problem Space

Independent Software Vendors (ISVs) building AI-powered tools—MCP servers, REST APIs, specialized agent capabilities—face a fundamental distribution challenge: how to securely expose these tools to multiple customer tenants, each operating in their own AWS account, without traversing the public internet and while maintaining strict tenant isolation.
SaaS providers building AI-powered applications on Amazon Bedrock AgentCore often need to serve multiple tenants with distinct security requirements from a shared infrastructure. Some tenants require cross-account access from their own AWS accounts, while others mandate that traffic stays within their VPC boundaries  Secure multi-tenant AI agents with Amazon Bedrock AgentCore resource-based policies .

Why AgentCore Gateway

Amazon Bedrock AgentCore Gateway is a fully managed AI gateway that provides a single, secure entry point for agentic traffic—connecting agents to tools, to other agents, and to large language models  Amazon Bedrock AgentCore Gateway . AgentCore Gateway natively connects to MCP servers with no protocol translation needed. When you add an MCP server as a target, AgentCore Gateway automatically discovers available tools by fetching the latest tool definitions from your target endpoints  Private connectivity patterns for Amazon Bedrock AgentCore Gateway Targets .
Enterprise customers are deploying thousands of MCP tools served through a unified AgentCore Gateway, using this single gateway to access tools from different teams, organizations, consumer AI applications, and AI agents, each with their corresponding access permissions  Apply fine-grained access control with Bedrock AgentCore Gateway interceptors .

The Multi-Tenant Challenge

SaaS providers building multi-tenant agentic applications must address architectural challenges including tenant isolation, tenant identity, tenant observability, data isolation, cost attribution, and noisy neighbor mitigation  Building multi-tenant agents with Amazon Bedrock AgentCore . This blog presents two architecture patterns that address these challenges at the networking layer.

Target Audience

This post is for:
  • ISV platform architects who host AI agent tools (MCP servers, REST APIs) and want to securely distribute them to enterprise customers
  • Cloud network engineers responsible for designing cross-account private connectivity
  • SaaS builders implementing multi-tenant AI agent platforms

What You'll Learn

In this post, we walk through two architecture patterns for ISVs distributing AI agent tools:
  • Pattern A: ISV hosts AgentCore Gateway centrally — tenants invoke cross-account via PrivateLink
  • Pattern B: Customers own their gateway — ISV shares MCP server targets cross-account via VPC Lattice and AWS RAM
For each pattern, we provide step-by-step implementation with CLI commands, architecture diagrams, a security best practices section, and operational guidance for production deployments.


Architecture Patterns

Pattern A: ISV Hosts AgentCore Gateway Centrally

Overview: The ISV creates and owns the AgentCore Gateway in their AWS account. Customer tenants invoke the ISV's gateway from their own accounts. The ISV's MCP servers run in the ISV's VPC behind the gateway with private connectivity.
When to use: The ISV wants to maintain full operational control of the gateway, tools are co-located with the gateway in the ISV's infrastructure, and the ISV manages all tool registrations and versioning centrally.
Figure 1: Pattern A architecture — ISV hosts AgentCore Gateway centrally

Key Design Decisions
  1. Gateway authentication: The ISV configures  CUSTOM_JWT  authorizer type on the gateway, with the ISV's identity provider (or Amazon Cognito) issuing per-tenant tokens. AgentCore Gateway operationalizes RFC 8693 token exchange without requiring agent-side implementation, enabling consistent audit trails and tenant onboarding through configuration alone  Implement on-behalf-of token exchange for multi-tenant agents with Amazon Bedrock AgentCore Gateway .
  1. Private connectivity to MCP servers: AgentCore Gateway supports connecting to self-hosted MCP servers running inside your VPC using private endpoints powered by Amazon VPC Lattice  Configure Amazon Bedrock AgentCore Gateway VPC Egress for Gateway Targets .
  1. Per-tenant authorization via Cedar: AgentCore Gateway uses Cedar-based policy interceptors that evaluate each request against a principal, action, and resource to provide fine-grained per-tenant authorization at the tool level  Secure AI agents with Policy and Lambda interceptors in Amazon Bedrock AgentCore gateway . All actions are denied by default—if no policies match a request, Cedar returns DENY  Understanding Cedar policies .
  1. Customer-side PrivateLink: Tenants create the  com.amazonaws.region.bedrock-agentcore.gateway  interface VPC endpoint in their VPC so that  InvokeGateway  calls never traverse the internet  Use interface VPC endpoints (AWS PrivateLink) .
Resource-Based Policy for Tenant Isolation
The ISV attaches a resource-based policy to the gateway restricting invocation to specific tenant accounts:
JSON
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowTenantAOnly",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<tenant-A-account>:root"
            },
            "Action": "bedrock-agentcore:InvokeGateway",
            "Resource": "arn:aws:bedrock-agentcore:us-east-1:<isv-account>:gateway/<gateway-id>",
            "Condition": {
                "StringEquals": {
                    "aws:SourceVpc": "vpc-tenant-a-12345"
                }
            }
        }
    ]
}

Resource-based policies in AgentCore allow you to control which principals can invoke and manage your resources, currently supported for Runtime, Gateway, and Memory  Resource-based policies for Amazon Bedrock AgentCore .


Pattern B: Customer Owns Gateway, ISV Shares MCP Targets Cross-Account

Overview: Each customer creates their own AgentCore Gateway in their account. The ISV hosts MCP servers in the ISV's VPC and exposes them cross-account using self-managed VPC Lattice resource configurations shared via AWS RAM. The customer's gateway connects to the ISV's MCP server through the shared resource configuration.
When to use: Customers require full ownership and governance over the gateway (regulated industries), customers want to combine the ISV's tools with their own private tools on a single gateway, or customers need to apply their own Cedar policies and interceptors.
Figure 2: Pattern B architecture — Customer owns gateway, ISV shares MCP targets cross-account

Key Design Decisions
  1. Self-managed VPC Lattice is required: Cross-account private connectivity requires the self-managed Lattice resources option. Managed VPC resources does not support cross-account scenarios  Connect to private resources in your VPC using VPC Lattice .
  1. Self-managed Lattice enables direct cross-account connectivity via AWS RAM without requiring VPC peering or Transit Gateways  Connect to private resources in your VPC using VPC Lattice .
  1. Preventing transitive sharing: The ISV specifies that their resource configuration cannot be added to service networks that are shareable between accounts, preventing uncontrolled access propagation  Resource configuration for VPC resources .
  1. Customer maintains full gateway governance: The customer sees exactly which services are connected to which domains, who has access, and can revoke connections at a granular level  Connect to private resources in your VPC using VPC Lattice .
Pattern B Comparison Table
Dimension
Pattern A (ISV-Hosted Gateway)
Pattern B (Customer-Owned Gateway)
Gateway ownership
ISV
Customer
Tenant isolation
Resource-based policy + Cedar
Network-level (separate gateways)
ISV operational burden
Higher (manages all tenants)
Lower (only manages MCP servers)
Customer flexibility
Limited to ISV's policy config
Full—can mix ISV + internal tools
Cross-account mechanism
PrivateLink endpoint to AgentCore
VPC Lattice resource config via RAM
Regulatory fit
Good for managed SaaS
Better for regulated enterprises


Step-by-Step Implementation Guidance

Pattern A Implementation: ISV-Hosted Gateway

Step 1: Create the AgentCore Gateway
Use the  CreateGateway  API specifying a name, protocol type ( MCP ), IAM role, and authorizer type ( CUSTOM_JWT  for OAuth or  AWS_IAM  for SigV4). The role grants the gateway permission to access AWS services. For multi-tenant ISV deployments, configure a  CUSTOM_JWT  authorizer pointing to your identity provider's OIDC discovery URL so each tenant receives scoped tokens. See the  create-gateway CLI reference  for the full parameter schema.
Step 2: Configure the Gateway Service Role Trust Policy
The gateway service role must trust the AgentCore service, scoped with  aws:SourceAccount  and  aws:SourceArn  conditions to prevent confused deputy attacks  Set up permissions for AgentCore Gateway .
JSON
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "bedrock-agentcore.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "<isv-account-id>"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:bedrock-agentcore:us-east-1:<isv-account-id>:gateway/isv-multi-tenant-gateway-*"
                }
            }
        }
    ]
}

Step 3: Add a Private MCP Server Target (Managed VPC Mode)
For the simplest deployment where MCP servers are in the same account:
Bash
aws bedrock-agentcore-control create-gateway-target \
  --gateway-identifier "isv-multi-tenant-gateway" \
  --name "isv-crm-tools-target" \
  --target-configuration '{
    "mcp": {
      "mcpServer": {
        "endpoint": "https://crm-tools.isv.internal/mcp"
      }
    }
  }' \
  --private-endpoint '{
    "managedVpcResource": {
      "vpcIdentifier": "vpc-0abc123def456",
      "subnetIds": ["subnet-0abc123", "subnet-0def456"],
      "endpointIpAddressType": "IPV4",
      "securityGroupIds": ["sg-mcp-egress-001"]
    }
  }'

With managed VPC resources, you provide your VPC, subnet, and optional security group information. AgentCore handles the creation and lifecycle management of the VPC Lattice resource gateway and resource configuration on your behalf  Connect to private resources in your VPC using VPC Lattice .
Step 4: Attach Resource-Based Policy for Tenant Access
Bash
aws bedrock-agentcore-control put-gateway-resource-policy \
  --gateway-identifier "isv-multi-tenant-gateway" \
  --policy '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "AllowTenantA",
        "Effect": "Allow",
        "Principal": {"AWS": "arn:aws:iam::111111111111:root"},
        "Action": "bedrock-agentcore:InvokeGateway",
        "Resource": "*",
        "Condition": {"StringEquals": {"aws:SourceVpc": "vpc-tenantA"}}
      },
      {
        "Sid": "AllowTenantB",
        "Effect": "Allow",
        "Principal": {"AWS": "arn:aws:iam::222222222222:root"},
        "Action": "bedrock-agentcore:InvokeGateway",
        "Resource": "*",
        "Condition": {"StringEquals": {"aws:SourceVpc": "vpc-tenantB"}}
      }
    ]
  }'

Step 5: Configure Cedar Policy for Per-Tenant Tool Scoping
Create a Cedar policy that restricts which tools each tenant can invoke:
cedar
// Allow Tenant A to use CRM tools only
permit(
  principal == AgentCore::Principal::"tenant-a-principal-id",
  action == AgentCore::Action::"InvokeTool",
  resource in AgentCore::ToolGroup::"crm-tools"
);

Note: Entity types above are illustrative — refer to your gateway's Cedar schema for exact types. The docs use  AgentCore::OAuthUser  for OAuth principals. Each tenant gets their own permit policy; all other tool access is denied by default.
The Gateway intercepts every agent-to-tool request and evaluates it against your Cedar policies before the tool is ever invoked. Because policy evaluation occurs at the gateway layer—outside the agent's code and outside the model's reasoning—it provides a deterministic enforcement boundary that cannot be bypassed by prompt manipulation  Secure AI agents with Policy and Lambda interceptors in Amazon Bedrock AgentCore gateway .
Step 6: Tenant Creates PrivateLink Endpoint (Tenant-Side)
Each tenant creates an interface VPC endpoint for service  com.amazonaws.<region>.bedrock-agentcore.gateway  in their VPC with private DNS enabled. This ensures all  InvokeGateway  calls route through the private network path. If you enable private DNS, tenants can call AgentCore using the default Regional DNS name with no application changes  Use interface VPC endpoints (AWS PrivateLink) .


Pattern B Implementation: Customer-Owned Gateway with Shared MCP Targets

Step 1: ISV Creates Resource Gateway in Their VPC
Bash
aws vpc-lattice create-resource-gateway \
  --name isv-mcp-resource-gateway \
  --vpc-identifier vpc-isv-mcp-servers \
  --subnet-ids subnet-isv-az1 subnet-isv-az2 \
  --security-group-ids sg-isv-mcp-egress \
  --ip-address-type IPV4

A resource gateway acts as the private entry point into the ISV's VPC. When created, it provisions one ENI per subnet that you specify, each sitting inside your VPC  Configuring Amazon Bedrock AgentCore Gateway for secure access to private resources .
Step 2: ISV Creates Resource Configuration
Bash
aws vpc-lattice create-resource-configuration \
  --name isv-crm-tools-config \
  --type SINGLE \
  --resource-gateway-identifier <resource-gateway-arn> \
  --resource-configuration-definition '{
    "dnsResource": {
      "domain": "crm-tools.isv.internal",
      "ipAddressType": "IPV4"
    }
  }' \
  --port-ranges "443" \
  --allow-association-to-shareable-service-network false

A resource configuration defines the specific resource AgentCore Gateway is allowed to reach, identified by a domain name or IP address. Rather than granting access to your entire VPC, it scopes connectivity to a single endpoint  Configuring Amazon Bedrock AgentCore Gateway for secure access to private resources .
Critical: Set  allow-association-to-shareable-service-network  to  false  to prevent transitive sharing.
Step 3: ISV Shares Resource Configuration via AWS RAM
Bash
aws ram create-resource-share \
  --name "isv-crm-tools-for-tenantA" \
  --resource-arns "arn:aws:vpc-lattice:us-east-1:<isv-account>:resourceconfiguration/rcfg-abc123" \
  --principals "111111111111" \
  --tags key=TenantId,value=tenant-a

Resource configurations are integrated with AWS RAM. You can share your resource configuration with another account, and clients in that account can then privately access the resource  Resource configuration for VPC resources .
Step 4: Customer Creates Their Own Gateway (Tenant-Side)
The customer creates their own gateway using  create-gateway  with  AWS_IAM  authorizer type (or their preferred auth method). They own full governance over this resource.
Step 5: Customer Adds ISV MCP Target Using Shared Resource Configuration
The customer references the ISV's shared resource configuration in their gateway target:
Bash
aws bedrock-agentcore-control create-gateway-target \
  --gateway-identifier "tenant-a-agent-gateway" \
  --name "isv-crm-tools" \
  --target-configuration '{
    "mcp": {
      "mcpServer": {
        "endpoint": "https://crm-tools.isv.internal/mcp"
      }
    }
  }' \
  --private-endpoint '{
    "selfManagedLatticeResource": {
      "resourceConfigurationIdentifier": "arn:aws:vpc-lattice:us-east-1:<isv-account>:resourceconfiguration/rcfg-abc123"
    }
  }'

Step 6: Customer Adds Their Own Private Targets
The customer can add their own internal MCP servers to the same gateway using managed VPC mode (same  create-gateway-target  API with  managedVpcResource  instead of  selfManagedLatticeResource ). This is the key advantage of Pattern B — customers combine ISV tools with internal tools on a single gateway.


Network Traffic Flow Deep-Dive

End-to-End Path (Pattern A)

  1. Tenant agent calls  InvokeGateway  → traffic hits the AgentCore Gateway PrivateLink endpoint in the tenant's VPC
  1. AgentCore Gateway authenticates the JWT, evaluates Cedar policies
  1. AgentCore Gateway resolves the VPC Lattice-generated DNS name for the target
  1. Traffic enters the ISV's VPC through the Resource Gateway ENI in the specified subnet, governed by security group rules
  1. Request arrives at the MCP server (via NLB or directly)
AgentCore Gateway initiates the request and routes it to the Resource Gateway inside your VPC. The Resource Gateway forwards traffic through an ENI provisioned in your subnet  Configuring Amazon Bedrock AgentCore Gateway for secure access to private resources .

TLS Requirement

VPC egress requires your target endpoint to have a publicly trusted TLS certificate. If your private resource uses a certificate from a private CA, the recommended workaround is to place an internal ALB with a public ACM certificate in front of your resource  Connect to private resources in your VPC using VPC Lattice .
For MCP servers on EKS, Route 53 private hosted zones resolve the domain to an internal NLB. The NLB terminates TLS on port 443 using an ACM public certificate, then forwards the request to the appropriate backend pods  Configuring Amazon Bedrock AgentCore Gateway for secure access to private resources .


Security Best Practices

Defense-in-Depth Layering

A robust multi-tenant ISV deployment implements security at every layer:
Layer
Mechanism
Purpose
Network
VPC PrivateLink endpoints
Keep all traffic off the public internet
Network
Security Groups on Resource Gateway
Restrict ENI traffic to specific ports/targets
Identity
OAuth/JWT or SigV4 authentication
Verify caller identity
Resource
Resource-based policies ( aws:SourceVpc ,  aws:PrincipalAccount )
Restrict which accounts/VPCs can invoke the gateway
Authorization
Cedar policy interceptors
Per-tool, per-tenant authorization decisions
Data
VPC Lattice resource configurations
Scope connectivity to specific endpoints only
Audit
CloudTrail cross-account events
Full audit trail for compliance

Best Practice 1: Enforce VPC-Only Deployment Organization-Wide

Use an SCP to require all runtimes and gateway targets deploy only with VPC connectivity:
JSON
{
    "Sid": "EnforceVPCRuntime",
    "Effect": "Deny",
    "Action": [
        "bedrock-agentcore:CreateAgentRuntime",
        "bedrock-agentcore:UpdateAgentRuntime",
        "bedrock-agentcore:CreateGatewayTarget",
        "bedrock-agentcore:UpdateGatewayTarget"
    ],
    "Resource": "*",
    "Condition": {
        "Null": {
            "bedrock-agentcore:subnets": "true",
            "bedrock-agentcore:securityGroups": "true"
        }
    }
}

AgentCore provides service-specific condition keys ( bedrock-agentcore:subnets ,  bedrock-agentcore:securityGroups ) for enforcing VPC network controls at the IAM policy level  Use IAM condition keys with AgentCore VPC settings .

Best Practice 2: Prevent Confused Deputy Attacks

Always scope the gateway service role trust policy with  aws:SourceArn  and  aws:SourceAccount :
AgentCore recommends using these global condition keys in resource policies to limit the permissions that AgentCore gives another service  Cross-service confused deputy prevention .

Best Practice 3: Disable Transitive Sharing on Resource Configurations

When sharing VPC Lattice resource configurations with tenant accounts, always disable transitive sharing to prevent uncontrolled access propagation through service network chains.

Best Practice 4: Use VPC Endpoint Policies on Tenant Side

Tenants should attach endpoint policies to their AgentCore PrivateLink endpoints restricting which gateway ARNs are reachable:
JSON
{
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "bedrock-agentcore:InvokeGateway",
            "Resource": "arn:aws:bedrock-agentcore:us-east-1:<isv-account>:gateway/<gateway-id>"
        }
    ]
}

Important: For OAuth-based requests to succeed through the VPC endpoint, the principal must be set to  *  in the endpoint policy  Use interface VPC endpoints (AWS PrivateLink) .

Best Practice 5: Leverage CloudTrail for Cross-Account Audit

All cross-account actions on shared VPC Lattice entities are recorded as cross-account events in AWS CloudTrail  Share your VPC Lattice entities . Configure centralized CloudTrail logging to maintain a complete audit trail across all tenant interactions.

Best Practice 6: Per-Tenant Security Group Isolation

Create separate security groups per resource gateway (one per tenant where required) to ensure each tenant's traffic can only reach their designated backend resources. Security groups on VPC Lattice resource gateways control outbound traffic from the gateway to backend resources  Resource gateways in VPC Lattice .


Operational Considerations

IP Address Planning

For Pattern B with many tenants, IP consumption must be factored into the ISV's network design:
  • Each resource gateway ENI receives 16 IPv4 addresses by default (configurable 1–62)
  • AWS recommends dedicated subnets with /24 or larger CIDR blocks for endpoint deployments

DNS Configuration

  • Use Route 53 private hosted zones for MCP server domain resolution within the ISV VPC

Supported Target Types

Plan your architecture knowing which target types support private endpoints:
  • ✅ MCP Server targets
  • ✅ OpenAPI targets (REST APIs with protocol translation)
  • ✅ API Gateway targets (via VPC Link)
  • ✅ Lambda targets (via Hyperplane ENI)

On-Premises and Multi-Cloud Extensions

For ISVs with MCP servers running on-premises or in other clouds:
  • Connect through AWS Direct Connect or AWS Site-to-Site VPN for on-premises resources
  • Connect through AWS Site-to-Site VPN or AWS Interconnect for multi-cloud resources
 Private connectivity patterns for Amazon Bedrock AgentCore Gateway Targets 


Cleanup

To avoid ongoing charges after testing these patterns:
Pattern A resources:
  • Delete gateway targets:  aws bedrock-agentcore-control delete-gateway-target 
  • Delete the gateway:  aws bedrock-agentcore-control delete-gateway 
  • Managed VPC Lattice resources (resource gateways, ENIs) are automatically cleaned up when the target is deleted
Pattern B resources:
  • Customer deletes their gateway and targets
  • ISV deletes the RAM resource share:  aws ram delete-resource-share 
  • ISV deletes the resource configuration:  aws vpc-lattice delete-resource-configuration 
  • ISV deletes the resource gateway:  aws vpc-lattice delete-resource-gateway 
Both patterns:
  • Remove VPC endpoints in tenant accounts
  • Delete associated security groups and IAM roles
  • Remove Cedar policies and resource-based policies


Conclusion and Next Steps

Pattern Selection Decision Tree

Choose Pattern A (ISV-hosted gateway) when:
  • You want to offer a fully managed SaaS experience
  • Tenants don't need to add their own private tools to the same gateway
  • You want centralized operational visibility across all tenants
  • Simpler tenant onboarding is a priority (just grant access via resource-based policy)
Choose Pattern B (customer-owned gateway) when:
  • Customers are in regulated industries requiring full infrastructure ownership
  • Customers want to combine your ISV tools with their own internal tools
  • Customers require their own Cedar policies, interceptors, and audit trails
  • Enterprise procurement requires the customer to own all networking resources

Combining Both Patterns (Tiered Approach)

A common ISV strategy is to offer both patterns based on customer tier:
  • Standard tier: Pattern A with shared gateway, per-tenant Cedar policies
  • Enterprise tier: Pattern B with cross-account resource sharing, dedicated resource configurations
This mirrors the Silo, Pool, and Bridge isolation patterns described for multi-tenant AgentCore architectures  Building multi-tenant agents with Amazon Bedrock AgentCore .

Next Steps for Implementation

  1. Start with a proof of concept using Pattern A with managed VPC mode—it requires no VPC Lattice IAM permissions or SCP changes  Connect to private resources in your VPC using VPC Lattice 
  1. Design your tenant identity model (OAuth claims, AWS IAM principals, or both)
  1. Author Cedar policies before onboarding tenants—default-deny means no access until explicit permits are written
  1. Plan CIDR allocation if you expect more than 10 tenants with Pattern B
  1. Implement CloudTrail centralized logging from day one for audit readiness
  1. Consider CDK constructs—AgentCore Gateway has L2 CDK constructs available for infrastructure-as-code deployments

Related Resources



Summary

Key Takeaways:
  1. Two complementary architecture patterns exist for ISVs distributing AI agent tools via AgentCore Gateway: Pattern A (ISV hosts the gateway centrally, tenants invoke cross-account) and Pattern B (customers own their own gateways, ISV shares MCP targets via VPC Lattice resource configurations through AWS RAM). The choice depends on who needs operational control and regulatory posture.
  1. VPC Lattice is the foundational networking layer for private connectivity in both patterns. Managed mode provides zero-config simplicity for same-account scenarios, while self-managed mode unlocks cross-account sharing without VPC peering or Transit Gateways—critical for Pattern B.
  1. Defense-in-depth tenant isolation is achieved by layering: PrivateLink endpoints (network path), resource-based policies ( aws:SourceVpc ,  aws:PrincipalAccount ), Cedar policy interceptors (per-tool authorization), security groups on resource gateways (traffic control), and AWS RAM anti-transitive-sharing flags (access boundary enforcement).
  1. Cedar-based policy enforcement provides deterministic, prompt-injection-immune authorization that evaluates every tool call before execution. Combined with OAuth token exchange, it enables ISVs to onboard new tenants through configuration alone without code changes.
  1. Operational planning is essential for scaled deployments: public TLS certificates are mandatory on all target endpoints, IP address planning must account for resource gateway ENI consumption (16 IPs default per ENI), DNS TTLs must be tuned for rolling deployments, and CloudTrail cross-account events should be centralized from day one.
  1. A tiered ISV strategy combining both patterns offers maximum flexibility—Pattern A for standard SaaS tenants (simpler, lower cost) and Pattern B for enterprise customers requiring full gateway ownership and regulatory compliance.
# amazon-bedrock-agentcore# amazon-vpc-lattice# networking# multi-tenant# ai-agents
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article