> ## Documentation Index
> Fetch the complete documentation index at: https://docs.uselayerup.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Native VPC Deployment Paradigm
> The foundational deployment model: Layerup AI Agents run entirely within your private cloud network boundary, procured via cloud marketplace, isolated by construction from all external infrastructure.
# 1 — Native VPC deployment paradigm — network isolation, marketplace procurement & data residency.
This section establishes the foundational deployment model — demonstrating definitively that Layerup AI Agents operate entirely within your network boundaries, rather than as an external SaaS service calling back to Layerup-controlled infrastructure. This is the section your Enterprise Architecture and Network Security teams should review first.
***
## 1.1 Sovereign tenancy — what it means architecturally
The central design principle of the Layerup AI Agents is **sovereign tenancy**. Your organization does not share compute, memory, network space, or data storage with any other Layerup customer. The agent is provisioned exclusively within your own cloud account and executed within your own Virtual Private Cloud (VPC) on AWS, or Virtual Network (VNet) on Azure.
This model is fundamentally different from traditional AI-as-a-Service products, where an enterprise sends application data to a third-party API endpoint hosted outside its network:
| dimension | traditional AI-as-a-Service | Layerup AI Agents |
| ----------------- | ------------------------------------- | ------------------------------------------------ |
| Compute location | Vendor's cloud account | Your cloud account |
| Data residency | Vendor's infrastructure | Your VPC / VNet |
| Inference routing | Vendor's model endpoints | Amazon Bedrock / Azure OpenAI within your tenant |
| Security controls | Vendor-managed | Your IAM, your guardrails, your encryption keys |
| Audit logs | Vendor's logging system | Your CloudWatch / Azure Monitor |
| Network boundary | Public API call egresses your network | No egress; VPC Endpoints only |
| Procurement | Direct vendor contract | AWS Marketplace or Azure Marketplace |
***
## 1.2 Marketplace procurement — enterprise-grade supply chain
Your organization acquires the Layerup AI Agent container artifacts through the cloud marketplace of your preferred provider. This is the recommended procurement path for enterprise customers who wish to maintain strict vendor security reviews and draw down on existing cloud spending commitments.
### 1.2.1 AWS Marketplace
AWS launched a dedicated category for AI Agents and Tools within AWS Marketplace in mid-2025. Through this channel:
* The Layerup agent is listed as a container-based product. Your procurement team subscribes to the listing directly within your AWS account.
* The signed Docker container image is delivered securely into your own Amazon Elastic Container Registry (ECR) — a private registry within your AWS account that Layerup cannot access after delivery.
* Any spend on the Layerup agent via AWS Marketplace draws down on your existing AWS Enterprise Discount Program (EDP) commitment, consolidating vendor spend within the cloud relationship already in place.
* The entire procurement transaction occurs within the AWS console, ensuring your standard vendor onboarding, contract, and security review workflows apply.
### 1.2.2 Azure Marketplace
For Azure environments, an equivalent path exists via the Azure Marketplace:
* The agent is listed as a Container App offer or a Managed Application, delivered directly into your Azure Container Registry (ACR).
* Marketplace spend draws down on your Microsoft Azure Consumption Commitment (MACC), maintaining consolidated cloud economics.
* The Azure Marketplace listing includes full Software Bill of Materials (SBOM) disclosure for your security review team — available before subscription.
***
## 1.3 VPC isolation and network boundary architecture
Once the container image is delivered into your private registry, all subsequent infrastructure lives inside your private network. The following describes the AWS deployment network topology; Azure and GCP equivalents are structurally identical.
| network component | description |
| ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **VPC** | The agent container runs exclusively within your dedicated AWS Virtual Private Cloud. The VPC is not shared with any external party. |
| **Private Subnets** | The agent's compute instances (ECS Tasks or Bedrock AgentCore microVMs) are provisioned within private subnets — subnets that have no direct route to the public internet. |
| **No Internet Gateway Route** | Private subnets used by the agent do not have a route to an Internet Gateway. Outbound public internet access is architecturally blocked at the routing level. |
| **NAT Gateway (Optional)** | If the agent configuration requires access to approved external data feeds (e.g., a licensed pharmacy claims data API), this traffic is routed through a NAT Gateway with strict egress security group rules. All endpoints must be explicitly whitelisted. |
| **VPC Endpoints** | Communication between the agent container and AWS managed services (Amazon Bedrock, S3, ECR, CloudWatch) occurs via private VPC Endpoints, ensuring no traffic traverses the public internet even for AWS internal service calls. |
| **Security Groups** | The agent's security group permits no inbound traffic from outside your VPC. Outbound rules are restricted to specific ports and destinations required for agent operation. |
```mermaid theme={null}
flowchart TB
subgraph vpc ["Your VPC — Private Subnets Only"]
subgraph compute ["Agent Compute Layer"]
AGT[Agent Container
Bedrock AgentCore microVM
or ECS Fargate Task]
end
subgraph endpoints ["VPC Endpoints — Private Traffic Only"]
EP_BDR[Bedrock VPC Endpoint]
EP_S3[S3 VPC Endpoint]
EP_ECR[ECR VPC Endpoint]
EP_CWL[CloudWatch VPC Endpoint]
EP_SQS[SQS VPC Endpoint]
end
subgraph storage ["Your Storage Layer"]
S3IN[S3 Input Bucket]
S3OUT[S3 Output Bucket]
CWL[CloudWatch Logs]
end
SG[Security Group
No inbound · Restricted outbound]
end
ECR[ECR Private Registry
Your AWS Account] -->|image pull via VPC endpoint| AGT
AGT -->|doc retrieval| EP_S3 --> S3IN
AGT -->|inference call| EP_BDR
AGT -->|output write| EP_S3 --> S3OUT
AGT -->|audit logs| EP_CWL --> CWL
AGT -->|queue receive| EP_SQS
SG -. governs .-> AGT
IGW[Internet Gateway] -. no route from private subnet .-> AGT
LAYERUP[Layerup Infrastructure] -. no access .-> vpc
classDef boundary fill:#fafafa,stroke:#111,stroke-width:1.5px,color:#111;
classDef store fill:#f4f4f2,stroke:#111,color:#111;
classDef blocked fill:#fff,stroke:#aaa,stroke-dasharray:4 4,color:#888;
class vpc,compute,endpoints,storage boundary;
class S3IN,S3OUT,CWL store;
class IGW,LAYERUP blocked;
```
*Fig. A1.1 — Network isolation topology. All agent traffic flows through private VPC Endpoints. The Internet Gateway has no route from the agent's private subnets. Layerup has no network path into the VPC after image delivery.*
***
## 1.4 Zero-egress data residency — layered enforcement
Data residency is enforced at multiple independent layers, not a single policy:
All ingested documents (PDFs, medical records, financial statements) are stored in your Amazon S3 buckets or Azure Blob Storage, encrypted with your customer-managed KMS or Key Vault keys. Layerup holds no access credentials to these buckets at any time.
The agent invokes foundation models through Amazon Bedrock (AWS) or Azure OpenAI (Azure). Both services process data within your cloud tenant under your data processing agreements. Data is not used to train shared models. No inference request or response is routed through Layerup's infrastructure.
The agent's reasoning chain, intermediate state, and working memory are session-isolated within the AgentCore microVM or ECS task. They are not persisted beyond the session unless your team explicitly configures persistence to your own designated data store.
All final outputs (underwriting decision JSON, confidence scores, flagged inconsistencies, evidence citations) are written to your internal systems of record and your own logging infrastructure (CloudWatch or Azure Monitor). No output copy is sent to Layerup.
The zero-egress guarantee extends to telemetry. The agent emits operational metrics and structured audit logs exclusively to your CloudWatch or Azure Monitor infrastructure. Layerup does not receive, aggregate, or process any telemetry from your production environment.
***
## 1.5 Holistic end-to-end architecture
The network isolation diagram in §1.3 shows the agent's internal VPC topology. This section shows the full picture: how your users or systems initiate work, how the agent processes it, and how structured output reaches your systems of record. Two deployment patterns exist depending on whether the [companion dashboard](/agents/deployment/dashboard) is deployed.
***
### Pattern A — with companion dashboard
In this pattern, your underwriting team accesses the agent through a browser-based interface. Cases are submitted manually via the dashboard. No integration with your existing policy admin system is required at go-live. This is the recommended starting point for teams that want to begin using the agent immediately while downstream integration work is in progress.
```mermaid theme={null}
flowchart TD
subgraph user ["User Access"]
UW[Underwriter Browser]
VPN[Corporate VPN\nor AWS Client VPN]
end
subgraph access ["Access Layer — Your VPC"]
ALB[Internal ALB\nPrivate — no public DNS]
end
subgraph vpc ["Your VPC — Private Subnets"]
DASH[Dashboard Container\nCase submission + output review]
AGT[Agent Container\nBedrock AgentCore Runtime]
subgraph storage ["Your Storage Layer"]
S3IN[S3 Input Bucket]
S3OUT[S3 Output Bucket]
SQS1[SQS Intake Queue]
SQS2[SQS Completion Queue]
CWL[CloudWatch Logs]
end
subgraph inference ["Inference Layer"]
BDR[Bedrock VPC Endpoint]
GRL[Bedrock Guardrails]
end
end
subgraph sor ["Your Systems of Record"]
PA[Policy Admin System]
end
UW --> VPN --> ALB --> DASH
DASH -->|"upload docs"| S3IN
DASH -->|"submit case"| SQS1
SQS1 -->|"trigger"| AGT
AGT -->|"retrieve docs"| S3IN
AGT -->|"inference"| BDR
BDR <--> GRL
AGT -->|"write output"| S3OUT
AGT -->|"completion event"| SQS2
AGT -->|"audit logs"| CWL
DASH -->|"read output"| S3OUT
SQS2 -.->|"optional: notify downstream"| PA
classDef boundary fill:#fafafa,stroke:#111,stroke-width:1.5px,color:#111;
classDef store fill:#f4f4f2,stroke:#111,color:#111;
classDef blocked fill:#fff,stroke:#aaa,stroke-dasharray:4 4,color:#888;
class vpc,storage,inference,access,user boundary;
class S3IN,S3OUT,SQS1,SQS2,CWL store;
```
*Fig. A1.2 — Holistic architecture with companion dashboard. The dashboard and agent containers both run in the same private subnet. The only user-facing entry point is the Internal ALB, reachable via VPN. The policy admin system notification (dashed) is optional — dashboards can operate as a standalone review interface without any downstream system connection.*
***
### Pattern B — without dashboard (system-integrated)
In this pattern, the agent is invisible to end users. Your existing workflow system — policy admin, workbench, or intake platform — triggers the agent automatically when a new case is submitted. Output is written back to S3 and your system consumes it via the SQS completion queue or a polling mechanism. No dashboard container is deployed.
```mermaid theme={null}
flowchart TD
subgraph source ["Your Intake System"]
SUB[New Business Submission\nor Case Event]
WS[Workflow System\nPolicy Admin · Workbench · DMS]
end
subgraph vpc ["Your VPC — Private Subnets"]
AGT[Agent Container\nBedrock AgentCore Runtime]
subgraph storage ["Your Storage Layer"]
S3IN[S3 Input Bucket]
S3OUT[S3 Output Bucket]
SQS1[SQS Intake Queue]
SQS2[SQS Completion Queue]
CWL[CloudWatch Logs]
end
subgraph inference ["Inference Layer"]
BDR[Bedrock VPC Endpoint]
GRL[Bedrock Guardrails]
end
end
subgraph sor ["Your Systems of Record"]
PA[Policy Admin System]
CRM[CRM · DMS]
end
SUB --> WS
WS -->|"stage docs"| S3IN
WS -->|"enqueue case"| SQS1
SQS1 -->|"trigger"| AGT
AGT -->|"retrieve docs"| S3IN
AGT -->|"inference"| BDR
BDR <--> GRL
AGT -->|"write output JSON"| S3OUT
AGT -->|"completion event"| SQS2
AGT -->|"audit logs"| CWL
SQS2 -->|"case ready — consume output"| PA & CRM
classDef boundary fill:#fafafa,stroke:#111,stroke-width:1.5px,color:#111;
classDef store fill:#f4f4f2,stroke:#111,color:#111;
class vpc,storage,inference,source boundary;
class S3IN,S3OUT,SQS1,SQS2,CWL store;
```
*Fig. A1.3 — Holistic architecture without dashboard. Your workflow system enqueues work and consumes output. The agent runs entirely in the background — no user-facing component is required. This is the target state for fully integrated production deployments.*
***
Both patterns share the same agent container, the same VPC boundary, the same Bedrock inference path, and the same audit trail. The only structural difference is whether a dashboard container is deployed and whether users interact with the agent directly or through your existing systems. See [Staged Integration Patterns](/agents/data/pipeline#staged-integration-patterns) for a roadmap on moving from Pattern A to Pattern B progressively.