AWS VPC Integration & Deployment
Deploying Panovista inside an Amazon Web Services (AWS) environment guarantees that your Layer 7 Model Context Protocol (MCP) traffic never traverses the public internet. By leveraging AWS Virtual Private Clouds (VPCs) and AWS PrivateLink, enterprise engineering teams can establish a cryptographically isolated perimeter for all autonomous AI agents.
This playbook covers the architectural requirements for dropping the Panovista stateless proxy into your existing AWS infrastructure.
Network Isolation Strategy
Panovista is designed to run in a completely private subnet. It requires no inbound public internet access. The deployment architecture relies on standard AWS networking primitives to maintain absolute data sovereignty.
The Isolation Blueprint
- Isolated Subnet (MCP Tools): Hosts your internal MCP servers, Amazon RDS databases, and proprietary document stores. No Internet Gateway (IGW) attached.
- Private Subnet (Panovista): Hosts the Panovista proxy. This subnet controls the data loss prevention (DLP) execution and restricted egress routing.
- Public Subnet / API Gateway: Hosts the Application Load Balancer (ALB) or API Gateway if your AI agents are communicating from outside the VPC.
Security Group Configuration
Because Panovista operates statelessly at Layer 7, the network access control lists (NACLs) and Security Groups are exceptionally straightforward.
| Direction | Protocol | Port | Source / Destination | Purpose |
|---|---|---|---|---|
| Inbound | TCP | 4321 |
Internal ALB / App Subnet | Encrypted JSON-RPC 2.0 Ingress |
| Inbound | TCP | 8080 |
Internal App Subnet | Health Checks (/healthz) |
| Egress | TCP | 8000 |
Isolated Subnet | Raw MCP Tool Egress |
| Egress | TCP | 443 |
VPC Endpoint | AWS Bedrock / External LLM |
💡 IAM Least Privilege Note
The Panovista container requires zero AWS IAM permissions to operate its core inspection engine. You only need to attach an IAM Task Role if you are configuring Panovista to natively output its cryptographically signed audit logs directly to Amazon CloudWatch or an Amazon S3 Bucket.
AWS Bedrock & PrivateLink Integration
If your enterprise relies on Amazon Bedrock for foundation models (like Claude 3 or Llama 3), you can achieve a completely dark, air-gapped pipeline.
Instead of sending API calls over the public internet to reach Bedrock, provision an AWS VPC Interface Endpoint (PrivateLink) directly inside Panovista’s subnet.
{
"version": "1.0",
"policy_name": "aws_bedrock_dark_routing",
"egress_rules": [
{
"destination": "bedrock-runtime.us-east-1.amazonaws.com",
"routing": "vpc_endpoint",
"tls_verification": "strict",
"action": "allow"
}
],
"default_action": "drop_connection"
}
This ensures that egress traffic to AWS services remains entirely on the global AWS backbone.
Deployment Orchestration Options
Panovista’s lightweight, zero-state Go architecture (requiring < 20MB of operational memory) means it integrates seamlessly with AWS native orchestration tools:
- Amazon ECS (Fargate): The recommended path for most teams. Deploy Panovista as a sidecar container directly within your existing AI application task definitions. Fargate handles the underlying compute, while Panovista instantly secures the network boundary.
- Amazon EKS: For Kubernetes shops, Panovista deploys natively as a lightweight DaemonSet or a mutating admission webhook Pod sidecar.
- Amazon EC2: For legacy deployments or specialized hardware requirements, the Panovista Linux binary can run as a standalone service via
systemdalongside your core application stack.