Modernizing SaaS Solutions for Data Sovereignty with Agentic AI: Architecture Patterns for ISVs

Independent Software Vendors (ISVs) with established SaaS products face a pivotal modernization decision. While enterprise customers demand intelligent automation through AI agents, they still require complete control over their data. For ISVs already serving regulated industries, the challenge isn’t building a new product, but it’s evolving existing SaaS architecture to incorporate autonomous AI agents while preserving the data sovereignty guarantees, that customers depend on.

Existing SaaS architecture processes data through defined, predictable and auditable APIs. Traditional data sovereignty relies on tenant isolation, data residency and geographic controls, encryption with customer-managed keys, and audit logging. Agentic AI disrupts this: autonomous agents access customer data across systems to reason and act, creating a larger attack surface, unpredictable data access patterns, and audit trails that struggle to track agent reasoning. For regulated industries, this introduces compliance risks that traditional architectures avoid.

At AWS, we’ve worked with ISVs modernizing their SaaS platforms to incorporate agentic AI. Through these engagements, three architecture patterns have been identified – each a distinct modernization path depending on where ISVs are today and how much data control their customers require.

The Data Sovereignty challenge in the age of agentic AI

Enterprise customers particularly in healthcare, financial services, and government apply heightened due diligence to ISV-controlled multi-tenant architectures, requiring:

• Data residency guarantees to meet regulatory requirements
• Complete audit trails showing exactly where data is processed and stored
• Revocable access allowing them to terminate provider access instantly
• Compliance alignment with industry-specific frameworks like HIPAA, PCI-DSS, FedRAMP and EU Cloud Services Scheme (EUCS)
• AI data access transparency to understand how autonomous agents access and process their data

These requirements form the data sovereignty mandate ISVs must address. The solution lies in hybrid architectures that separate data planes from control planes, giving customers control where they need it while maintaining centralized operations where possible.

Common architecture foundation

All three patterns share a core set of AWS services and design principles. Understanding this shared foundation helps ISVs focus on what’s truly different between patterns:

• Amazon Bedrock AgentCore serves as the agent runtime across all patterns, providing framework-agnostic execution supporting Strands, LangGraph, CrewAI, and custom SDKs, session-level isolation using Firecracker microVMs, built-in observability capturing agent reasoning and tool invocations, AgentCore Identity for agent-level authentication with tenant-scoped credentials, and consumption-based pricing that charges only for active processing.
• Model Context Protocol (MCP) provides the standardized data access layer. MCP clients run with ISV AI agents while MCP servers deploy in customer accounts, exposing data securely. This separation is fundamental to data sovereignty as agents invoke tools and access context through MCP without requiring direct access to customer storage systems.
• AWS PrivateLink ensures all cross-account agent-to-MCP communication remains private, never traversing the public internet. This applies across all three patterns.
• AWS Identity and Access Management (IAM) enforces least-privilege access through cross-account roles, trust policies, and time-limited sessions for all agent-to-customer interactions.
• Amazon CloudWatch provides integrated observability per-tenant such as token usage, costs, latencies, reasoning traces, and error patterns for debugging non-deterministic agent behavior.

What differs across patterns is where compute runs, who operates it, and how customers are isolated.

Three architecture patterns for Agentic AI and Data Sovereignty

Each pattern addresses the sovereignty requirements differently. Pattern 1 solves data residency and audit trails while maintaining ISV operational control. Pattern 2 delivers all five including revocable access and full AI transparency for customers who need complete autonomy. Pattern 3 prioritizes compliance alignment through tenant isolation at scale.

Pattern 1: Dedicated Compute in ISV Account with Customer Data Residency

Tagline: ‘Customer data residency, ISV compute’

Dedicated compute infrastructure runs in the ISV account; strict data residency remains in the customer’s account. AI agents access customer data exclusively through MCP servers deployed in the customer account. To prevent data exfiltration, all ISV and customer accounts should be deployed within the same AWS Region, and AWS CloudTrail logging combined with VPC Flow Logs provides an auditable trail of all cross-account data access. Customers retain ownership with transparent audit trails showing exactly what data agents accessed, when, and why.

What’s unique to Pattern 1:

• Use AWS CloudFormation StackSets—authored and maintained by the ISV—for consistent MCP server deployment across customer accounts
• ISV defines MCP tool definitions (resources and tools exposed); customers approve which tools are enabled via IAM trust policies
• Tenant isolation patterns authenticate agents to individual customer MCP servers
• AgentCore observability integrated with Amazon CloudWatch provides centralized cross-account monitoring from the ISV’s operational view

Supporting Research: According to Getmonetizely and BuilderLab, AI-first SaaS companies report 50-60% gross margins due to variable inference costs. This pattern works well for enterprise-focused ISVs targeting 50-500 customers with data residency as the primary buying criteria, delivering gross margins in the 50-65% range due to operational overhead from per-customer MCP management.

When to use: Start here to validate product-market fit with enterprise customers who require data residency guarantees but don’t need complete infrastructure control.

Figure 1: Architecture diagram for Pattern 1 showing dedicated compute in the ISV account with MCP servers providing data access to the customer account via PrivateLink.

Pattern 2: Customer-Managed Infrastructure with AgentCore/EKS

Tagline: ‘Customer infrastructure, Customer control’

Both storage and compute are deployed entirely within the customer’s AWS account. The ISV provides agent frameworks, deployment templates, and operational guidance; but the customer owns and operates the runtime environment with complete control over guardrails, prompt caching, and security policies.

What’s unique to Pattern 2:

• Recommended: Deploy AgentCore Runtime within the customer’s own account—providing built-in session isolation, guardrails, and prompt safety within the customer’s trust boundary
• Alternative: For customers requiring custom networking, GPU allocation, or container-level security policies, Amazon EKS offers a self-managed option. This model is proven at scale. For example, Databricks uses this same architecture, deploying its Data Intelligence Platform while all compute runs in the customer’s AWS account
• ISV provides AWS CloudFormation templates and operational runbooks; customers with AI/ML teams can heavily customize agent logic while those without expertise use pre-built templates
• Observability is fully customer-managed using AgentCore Observability, CloudWatch and AWS X-Ray; ISV accesses logs only through customer-granted permissions, ensuring audit compliance.

Supporting Research: According to Herod CPA’s analysis, regulated SaaS firms operate at 60-75% gross margins, lower than traditional SaaS due to compliance costs. Pattern 2 suits premium tiers where customers justify higher costs through complete workload isolation. Getmonetizely research shows healthcare SaaS providers command 30-50% pricing premiums over horizontal solutions.

When to use: Reserve for customers requiring complete infrastructure ownership such as defense and intelligence workloads, critical infrastructure operators, pharmaceutical R&D with proprietary IP, or jurisdictions with strict data localization mandates. AgentCore supports PHI, PCI-DSS, and FedRAMP natively; Pattern 2 is for those who additionally need full runtime control or air-gapped deployments.

Figure 2: Architecture diagram for Pattern 2 showing AgentCore and EKS deployed entirely within the customer’s AWS account.

Pattern 3: Multi-Tenant Shared SaaS with Centralized Compute & Customer Managed Data

Tagline: ‘ISV shared compute, Customer data residency’

Multiple customers share the same AgentCore infrastructure and agent logic centrally, but each customer’s data remains isolated through MCP servers in their own account. All agent-to-MCP communication is confined to a single AWS Region using PrivateLink endpoints, ensuring data in transit never leaves the customer’s designated geography. This multi-tenant agent model is documented in the AWS Prescriptive Guidance for building multi-tenant architectures for agentic AI, which describes the “Agent as a Service” pattern.

Pattern 3 is the operational sweet spot sharing compute across customers dramatically reduces per-customer overhead while maintaining data sovereignty through MCP servers.

What’s unique to Pattern 3:

• Multi-tenant isolation using tenant-scoped IAM policies and request routing within shared AgentCore infrastructure
• Lightweight MCP servers (AWS Lambda functions or small containers) in customer accounts minimize per-tenant deployment overhead
• Amazon EventBridge enables event-driven communication between ISV and customer accounts at scale
• AWS Organizations provides multi-account governance and management
• Tenant-aware observability tracks per-tenant token usage, costs, and MCP invocations across all customers from a single operational pane via AgentCore Observability integrated with Amazon CloudWatch

Supporting Research: According to Fiscallion.io and NStar Finance, best-in-class SaaS reaches 85%+ margins at scale. Pattern 3 delivers 60-70%, lower due to MCP overhead but significantly higher than Patterns 1 and 2. Ideal for ISVs targeting hundreds or thousands of customers with consumption-based pricing.

When to use: Transition here once the product-market fit is validated and ready to scale. Use for standard tier while offering Pattern 1 or 2 for enterprise customers with premium compliance requirements.

Figure 3: Architecture diagram for Pattern 3 showing pooled multi-tenant compute in the ISV account with per-tenant MCP server isolation in customer accounts.

Architectural best practices

Regardless of pattern, these practices ensure success:

• Network isolation: AWS PrivateLink for all cross-account communication such as agent-to-MCP-server traffic never traverses the public internet.
• Geographic data isolation: Deploy all ISV and customer resources within the same AWS Region to ensure data residency compliance. Use AWS Config rules to enforce regional boundaries and prevent cross-region data transfer.
• Security first: Least-privilege IAM policies, AWS CloudTrail logging, and AgentCore’s Firecracker microVM session isolation, where each agent invocation runs in a dedicated, short-lived microVM with its own kernel, memory, and network namespace. This ensures that no tenant’s data or reasoning state is accessible to another.
• MCP standardization: Framework-agnostic, standardized tool discovery and invocation provides future-proof architecture as MCP adoption grows across the industry.
• Comprehensive observability: Complete reasoning traces, per-tenant metrics, and error patterns are critical given the non-deterministic nature of AI agents.
• Transparent operations: Shared dashboards, status pages, and detailed audit logs earn customer trust, especially in regulated industries where transparency about agent data access is essential.
• Cost optimization: AWS Cost Explorer and AWS Budgets track per-customer costs; AgentCore’s consumption-based pricing ensures payment only for active agent processing, not idle infrastructure.

Getting started: Begin with Pattern 1 to validate the enterprise value proposition. Deploy on Amazon Bedrock AgentCore to eliminate infrastructure management overhead. Introduce Pattern 3 to scale for cost-conscious customers and Pattern 2 for premium compliance-focused segments.

Ready to modernize your SaaS solution?

Reach out to your AWS account team to engage with the AWS SaaS & Agentic Apps Technical Field Community for additional resources, reference architectures, AgentCore hands-on build workshop and expert guidance. Learn how AWS programs, tools, and expertise drive ISV growth and discover the support available to accelerate your path to market. For deeper insights on agentic cloud modernization, see Accelerating Modernization with AWS MCPs and Kiro.