Enterprise + Sovereign AI

When should a company deploy AI in its own VPC?

Choose a VPC deployment when data must stay inside your cloud account, when network policy forbids external inference endpoints, when another system's data gravity makes cross-boundary calls expensive, or when procurement requires your own account for spend and control. Stay on a region-pinned shared endpoint when the driver is geography alone — the controls are similar and the operational burden is far lower.

Key facts

What it gives youInference inside your AWS, GCP, Azure or OCI network with your peering and KMS
Also availableBring-your-own-cloud, on-prem and air-gapped tiers for stricter needs
API contractOpenAI-compatible /v1 endpoints, unchanged by deployment tier
Identity and keysSSO/SCIM, RBAC and BYOK/HSM custody
AuditPer-request logs and key/admin events, exportable to SIEM
When shared is enoughRegion pinning satisfies geography-only requirements
Contractual frameTerms at /legal/terms and service commitments at /legal/sla
Compliance postureSOC 2 Type II and ISO 27001 readiness in progress (not yet certified)

TL;DR

  • VPC answers account-boundary and network-path questions, not geography ones.
  • If the driver is residency alone, region pinning is usually sufficient.
  • Data gravity and egress architecture often justify VPC more than policy.
  • Budget for operations: capacity, upgrades and support change under VPC.
  • Keep the API OpenAI-compatible so moving tiers is a config change.

How it works, step by step

  1. State the requirement: account boundary, network path, geography or procurement.
  2. Check whether region pinning already satisfies it before choosing VPC.
  3. Map network paths, peering and egress between your systems and the inference endpoint.
  4. Quantify data gravity: how much data would leave the boundary per workload.
  5. Confirm identity, key custody and audit integrate with your existing controls.
  6. Pilot one workload in the VPC and measure latency, cost and operational load.
  7. Decide the steady state, then plan the migration and rollback path.
1State therequirement:account boundary,2Check whetherregion pinningalready satisfies3Map network paths,peering and egressbetween your4Quantify datagravity: how muchdata would leave5Confirm identity,key custody andaudit integrate6Pilot one workloadin the VPC andmeasure latency,

Try it yourself

Open the private LLM cost estimator →

Signals that point to a VPC

  • Account boundary: security policy requires data and inference inside your cloud account, with egress restrictions.
  • Network path: only approved private routes may carry traffic; public endpoints are forbidden even when encrypted.
  • Data gravity: large datasets in your VPC would make cross-boundary calls slow or costly.
  • Procurement: spend must sit in your cloud agreement, or your vendor agreement requires self-hosting.
  • Blast radius: key management must integrate with your KMS so revocation is unilateral.

Notice what is absent: geography alone. If the requirement is "data must remain in the UAE", region pinning plus audit and BYOK usually satisfies it without a VPC project.

What changes operationally

A VPC is not just a checkbox in the dashboard. You take on capacity planning within your account, network architecture and peering, upgrade windows coordinated with your change process, and a support model that works through your own cloud boundary. In exchange you gain direct control over the data path, integration with your KMS and identity, and the ability to apply your own network policy to traffic that previously left the perimeter. Teams typically underestimate the change-management work rather than the technical deployment.

Comparing the options fairly

Put the options side by side for the same workload. Region-pinned shared endpoint: fastest to deploy, lowest operations, satisfies geography, weaker on account boundary. VPC: strong account boundary and key integration, moderate operations. On-prem: physical control for the strictest data classes, highest operations. Bring-your-own-cloud: managed control plane with inference in your account, useful when procurement requires your cloud consumption. Air-gapped: no external path at all, for classified workloads. Because Plugsky exposes the same OpenAI-compatible API across these tiers, the decision is reversible — you can pilot on one and move.

Making the decision stick

Write a short decision record: the requirement, the options considered, the tier chosen, the evidence and the review date. Run the pilot with production-like traffic and measure the things that change — latency, error paths, upgrade effort and cost — rather than assuming parity with the shared endpoint. Confirm identity, audit and key custody integrate with your existing tooling before scaling. Record pending items such as certification status — Plugsky documents SOC 2 Type II and ISO 27001 as readiness in progress — and reference /legal/terms and /legal/sla for contractual commitments. A decision record turns a one-time architecture debate into an auditable, revisitable choice.

Honest comparison

RequirementRegion-pinned sharedVPCOn-prem
GeographySatisfied by pinningSatisfied by region choiceSatisfied by facility
Account boundaryNot guaranteedYes — inside your accountYes — inside your network
Key integrationBYOK to regional KMSYour cloud KMS and IAMYour KMS or HSM
Network pathPublic endpoint with authPrivate routes and peeringFully internal
OperationsLowestModerateHighest
Time to deployHoursDays to weeksWeeks to months

Frequently asked questions

What does a VPC AI deployment actually change?

Inference and related processing run inside your own cloud account, using your networking, peering and KMS. The API contract stays the same, so application code does not change.

Is region pinning enough instead of a VPC?

If the requirement is geography alone, region pinning plus audit, BYOK and scoped keys usually suffices. VPC is for account-boundary, network-path or data-gravity requirements.

Which cloud providers are supported?

Plugsky documents VPC deployment into AWS, GCP, Azure and OCI environments, with your network, peering and keys.

How long does a VPC deployment take?

Typically days to weeks depending on network change approvals and security review. Start with one workload on a pilot boundary rather than migrating everything at once.

Does a VPC remove all subprocessors from our data path?

It removes external inference routing, but monitoring, support and control-plane components may remain. Review the deployment-specific subprocessor list and locations.

What stays with the provider in a VPC deployment?

Control-plane management, model updates and platform operations, subject to the enterprise agreement. You gain account-boundary control without taking on GPU operations.

How do we avoid lock-in?

Keep the OpenAI-compatible core as the contract and isolate provider-specific extensions. Moving between shared, VPC and on-prem tiers then becomes a configuration exercise.

What evidence should the decision produce?

A decision record with the requirement, options, chosen tier, pilot results, identity and key integration proof, and the review date — plus the signed terms and SLA at /legal/terms and /legal/sla.