Guide to Operating Isolated AI Agents on AWS EKS: NetworkPolicy, Warm Pool, and gVisor Performance Analysis

Enabling NetworkPolicy and Controlling DNS Paths

The default NetworkPolicy for Agent Sandbox requires enableNetworkPolicy: "true" in the VPC CNI to function correctly. Before enabling this, connections to the metadata service (IMDS) and the Kubernetes API were not blocked even if policy objects existed. After enabling, private and link-local ranges are blocked, but Egress to the internet is allowed, so additional controls such as destination allowlists or AWS Network Firewall are necessary to prevent data exfiltration.

The default template hardcodes DNS to Google (8.8.8.8) and Cloudflare (1.1.1.1), but in AWS environments, you must configure a custom networkPolicy and dnsPolicy: None to route through Route 53 Resolver so that DNS Firewall and query logging are applied. If using VPC endpoints, private IP paths may be blocked by Egress rules, so you must explicitly open port 443 on the relevant subnets if AWS API calls are required.

Minimizing Startup Latency with Warm Pool

Using a Warm Pool dramatically reduces the time from SandboxClaim creation to Ready compared to Cold Start. Measurements show that gVisor Cold Start has a median of 2,046.6ms, whereas using a Warm Pool reduces this to 57.2ms, making it approximately 35.8 times faster. runc also improves from a Cold Start of 1,822.0ms to 53.3ms with a Warm Pool, effectively eliminating performance differences between runtimes in a Warm Pool environment.

If concurrent requests exceed the Warm Pool size, startup delays may occur due to the IP reuse cooldown period in VPC CNI (IP_COOLDOWN_PERIOD, default 30 seconds). To prevent this, increase the IP allocation unit using Prefix Delegation or secure spare IPs with WARM_IP_TARGET, and configure the Warm Pool size based on peak concurrent requests rather than the average.

gVisor Isolation Costs and State Preservation Strategies

The performance cost of gVisor is proportional to the number of system calls. Pure CPU computation shows no difference from runc, but file operations and process creation are 4.7 to 6.5 times slower. Memory usage is also higher, with 57 Mi for gVisor compared to 43 Mi for runc based on kubelet metrics, and approximately 120 MiB based on host RSS, requiring consideration of scheduler overhead.

For idle state management of agent sessions, operatingMode: Suspended can be used, but data is lost upon resumption if emptyDir is used. To preserve the working directory, you must attach an EBS gp3 PVC via volumeClaimTemplates, and due to Availability Zone (AZ) constraints of EBS volumes, resumed Pods can only be scheduled on gVisor nodes in the same AZ as the volume.

Agent Integration and router Security Hardening

When integrating Amazon Bedrock Claude models with sandboxes, role separation is established at the credential layer, not the network layer. ServiceAccount tokens are not mounted in the sandbox, and IMDS hop limits block access to node credentials, preventing the sandbox from directly calling the Bedrock API. To block this at the network layer as well, restrict Egress destinations or use an egress proxy.

The default authorization mode for sandbox-router is allow-all, so even when TokenReview mode is enabled, SDK v1.0.5 does not send authentication headers, requiring manual header addition. Additionally, kubectl port-forward bypasses NetworkPolicy, so to restrict router access, control pods/portforward permissions via RBAC and ensure internal cluster agents use Direct connections.