Air-Gapped AI for Fintech and Regulated Finance

Key Takeaways

• Air-gapped AI for regulated fintech means private subnets with zero internet egress — every model call, every AWS service API, every container image pull must stay inside the VPC boundary from day one
• The two deployment patterns are Amazon Bedrock via VPC interface endpoint (fast to production, managed) and self-hosted open-weight models on EKS (full control, no per-token costs) — most regulated finance teams start with Bedrock
• The build requires 10+ VPC interface endpoints, a private container registry, a VPC-internal CI/CD runner, and compliant audit logging — standard tooling does not work and must be replaced before any application code deploys
• Prodinit delivered a full production air-gapped EKS stack for a regulated financial services AI platform in 4 weeks: zero internet egress confirmed, Bedrock and Transcribe via VPC endpoints, five data services live on day 28

Standard AI development assumes internet connectivity at every layer: container images pull from public registries, model inference calls traverse the internet to a provider's API, observability tools send telemetry to third-party clouds. In regulated financial services, each of those assumptions is a compliance failure waiting to be discovered. Model inference data that leaves your VPC perimeter without explicit data-handling agreements creates audit exposure. A self-hosted GitHub Actions runner that calls docker pull against a public registry cannot reach it from private subnets. A CI/CD pipeline that works perfectly in development fails on first deploy into a zero-egress environment.

Air-gapped AI for fintech is not a feature flag you set at the end of a build. It is a constraint that determines every infrastructure and tooling decision from the first week. Teams that treat it as an add-on discover the gaps — missing VPC endpoints, container images that have not been mirrored, CI/CD runners that cannot reach the EKS API — at runtime, not during planning.

Air-gapped AI for fintech means deploying LLM infrastructure inside a private VPC with zero internet egress — model inference via Bedrock VPC endpoints or self-hosted models on EKS, container images from private ECR, CI/CD running on a VPC-internal runner, and every data service on private subnets. The build takes 4–5 weeks when the team has done it before; it takes significantly longer when they are learning the constraint under a delivery deadline.

What "Air-Gapped AI" Actually Means in Regulated Finance

For regulated financial services, the air-gap requirement is driven by a combination of regulatory frameworks and internal security policy. SOC 2 Type II requires demonstrable data flow controls — auditors ask where model inference data goes, whether it leaves your network boundary, and what agreements cover any third-party processors. FCA and SEC guidance around model risk management creates additional pressure to keep inference within your controlled perimeter, particularly for models that touch client data. Internal security policy often goes further: private subnets with no internet gateway route at all, enforced at the VPC level.

The compliance problem with standard LLM API calls (OpenAI, Anthropic, Azure OpenAI via public endpoint) is not that they are insecure — it is that inference data leaves your network boundary and enters a third party's infrastructure. Even with a signed data processing agreement, the data lineage question becomes complex: where was the prompt processed, under what logging policy, and what is the audit trail for that processing? In a zero-egress VPC, these questions have straightforward answers because the data never left.

The two architectures that satisfy a zero-egress LLM constraint:

Amazon Bedrock via VPC interface endpoint. Bedrock serves Claude, Llama, Mistral, Titan, and other foundation models through a VPC interface endpoint — your API calls route through the AWS network directly to the Bedrock control plane, never touching the public internet. All AWS service calls stay inside the AWS network and are subject to your existing AWS BAA if applicable. This is the fast path to production: no GPU infra to provision, managed model serving, and model access within the same AWS account and region as your other services.

Self-hosted open-weight models on EKS. Llama 3.3, Qwen2.5, Mistral, or DeepSeek deployed on GPU instances inside your VPC using vLLM, Ollama, or NVIDIA NIM. Model weights pre-loaded from a private S3 bucket (via S3 gateway endpoint, no internet path). Full control over the model, no per-token API costs, and absolute data isolation — inference runs on hardware you control in your account. The trade-off: GPU infrastructure to provision and operate, model updates are manual.

For most regulated fintech first deployments, Bedrock via VPC endpoint is the correct starting point. It eliminates the GPU infrastructure problem while satisfying the zero-egress constraint. Self-hosted becomes the right call when model choice requirements exceed Bedrock's catalogue or when per-token cost at scale justifies the infrastructure overhead.

What Air-Gapped AI Infrastructure Requires

Five layers must be resolved before any application code can deploy into a zero-egress environment. Missing any one of them causes runtime failures, not compile-time failures — the environment appears configured until you try to use the missing component.

Layer 1: Network isolation. Multi-AZ VPC with private subnets and no internet gateway. The internet gateway removal is the non-negotiable enforcement of zero egress — any NAT gateway or internet gateway creates a potential egress path. Route tables on private subnets must have no default route to a NAT gateway. Confirm with VPC flow logs.

Layer 2: VPC interface endpoints for every AWS service. Any AWS service your workloads call must have a VPC interface endpoint provisioned, or the call will fail silently or with a network timeout. At minimum: ECR API, ECR Docker (separate endpoint), Secrets Manager, Systems Manager (SSM), CloudWatch Logs, STS (required for IRSA pod identity), and ELB (required for ALB controller). Add Bedrock, Transcribe, S3 gateway endpoint, and DynamoDB gateway endpoint if your application uses them. The most common deployment failure in zero-egress environments is a missing VPC endpoint discovered at first pod startup.

Layer 3: Private container registry. Every container image — including third-party Kubernetes controllers — must be mirrored into a private Amazon ECR repository before the cluster bootstraps. The cluster cannot pull from Docker Hub, public ECR, or any external registry. If a controller image is not in private ECR when the cluster starts, the pod will fail with ImagePullBackOff and the entire cluster will be in a degraded state. Mirror the AWS Load Balancer Controller, cluster-autoscaler, External Secrets Operator, and every other dependency before provisioning the cluster.

Layer 4: VPC-internal CI/CD. Standard CI/CD runners (GitHub Actions hosted runners, GitLab shared runners) run on internet-connected infrastructure and cannot reach a private EKS API endpoint. The solution is a self-hosted GitHub Actions runner deployed as a pod inside the VPC, or AWS CodePipeline with a VPC-connected build agent. Deployments execute via kubectl and Helm through AWS Systems Manager Session Manager — no inbound ports need to be opened.

Layer 5: Compliant audit trail. CloudWatch Logs for all cluster and application activity, S3 access logging for every object operation, and a per-model-call audit record for every Bedrock or self-hosted inference call. SOC 2 and most financial compliance frameworks require demonstrable audit trails for model access — "we kept logs" is not sufficient; the log schema must be queryable for specific model calls tied to specific users or requests.

Client's Air-Gapped EKS in 4 Weeks for a Regulated Fintech

A regulated financial services AI platform came to Prodinit with a hard requirement: private subnets with zero internet egress. Their platform — a Next.js dashboard, Python FastAPI backend, and mobile API — needed to run on Amazon EKS without any internet connectivity. Standard deployment tooling did not work. Every component had to be rebuilt for VPC-internal operation.

Prodinit delivered the complete air-gapped production infrastructure in 4 weeks across five parallel workstreams: networking and VPC endpoints, compute and EKS cluster configuration, CI/CD pipeline rebuild, security controls, and AI service integrations.

What was built:

• Multi-AZ VPC with 10+ VPC interface endpoints covering ECR, Secrets Manager, Bedrock, Amazon Transcribe, STS, CloudWatch, ELB, and SSM
• Private EKS cluster with managed node groups in private subnets; all controller images pre-mirrored to private ECR before cluster bootstrap
• Self-hosted GitHub Actions runner deployed inside the VPC; deployments via kubectl and Helm through SSM Session Manager with zero open inbound ports
• RDS PostgreSQL with pgvector, DynamoDB, ElastiCache Redis — all on private subnets, no public endpoints
• Amazon Bedrock and Transcribe via VPC endpoints — IAM roles scoped to specific model ARNs
• AWS Secrets Manager with External Secrets Operator, AWS WAF, ACM TLS termination, and CloudWatch Container Insights all live on day 28

What the client's CTO said: "Prodinit delivered a production-grade, fully air-gapped EKS environment in four weeks. The infrastructure was solid from day one, and our team was independently deploying new services before the engagement even ended."

The full architecture — network topology, VPC endpoint list, CI/CD configuration, and AI service integration — is documented in the air-gapped EKS fintech case study. For the zero-egress model serving layer specifically, the air-gapped LLM deployment guide covers the Bedrock VPC endpoint configuration, self-hosted model weight pre-loading, and the endpoint gap diagnosis process for missing VPC endpoints.

Why Regulated Finance AI Needs an Air-Gapped Specialist

The failure mode of a generalist team deploying into a zero-egress environment is predictable: the build progresses normally in development (which has internet access), the first deployment to the VPC-isolated environment fails with networking errors, and the team spends days diagnosing missing VPC endpoints and un-mirrored container images under deadline pressure.

The diagnosis is not difficult once you have done it before. Missing a Secrets Manager VPC endpoint causes pods to fail at startup with a connection refused error that looks like an application bug. A container image that was not pre-mirrored causes an ImagePullBackOff that looks like a registry permissions issue. An ELB endpoint that was not provisioned causes the AWS Load Balancer Controller to fail silently and all ingress to stop working. Each of these is a known failure mode with a known fix — but discovering them in production is expensive.

Prodinit's 4-week delivery on the client's engagement was possible because the infrastructure was designed around the zero-egress constraint from day one: all five workstreams ran in parallel inside the VPC boundary, no "adapt for air-gap later" phase existed, and every controller image was pre-mirrored before the cluster was provisioned. The 10+ VPC endpoints were defined in Terraform before any application code was discussed. That front-loading is the difference between a 4-week delivery and a 12-week one.