How to deploy SaaS in a customer VPC: implementation approaches and tradeoffs

Deploying SaaS in a customer VPC involves running vendor-operated software or exposing vendor services privately within a customer's own cloud environment. On AWS, common approaches include AWS PrivateLink, in-VPC or BYOC (Bring Your Own Cloud) deployment, and AWS VPC Lattice. Each suits different requirements around data isolation, networking, and operational complexity. The right approach depends on the customer's compliance framework, security policy, and infrastructure requirements.

For SaaS vendors, supporting customer VPC deployments is increasingly a requirement during enterprise procurement. The implementation, however, is where much of the complexity lies. "Deploy in our VPC" can mean different things to different customers, and the approach that satisfies one customer's requirements may not satisfy another's.

This guide covers what deploying SaaS in a customer VPC involves, the main implementation approaches on AWS, how they differ architecturally, what it takes to operate them at scale, and how vendors approach automating the infrastructure.

For background on deployment models, compliance drivers, and why enterprise customers require this, see our overview of SaaS deployment in customer environments.

When a customer says "we need this deployed in our VPC," the first thing worth clarifying is what they mean. Some customers need their data to stay within their own cloud boundary. Others need private network connectivity to a vendor service without traversing the public internet. These are different requirements, and they map to different implementation approaches.

The phrase is used to describe at least two architecturally distinct models that are frequently conflated. Understanding which model a customer is asking for is the prerequisite to choosing the right implementation approach.

The vendor's application continues to run in the vendor's account. A private network path is established so the customer's VPC can reach the vendor's service without going over the public internet. The customer's traffic stays within the cloud provider's network, but data processing still happens in the vendor's environment.

The vendor deploys and operates application components, such as containers, databases, or services, directly inside the customer's cloud account. Data processing happens within the customer's environment during normal operation. The vendor manages these components remotely through a control plane in their own account.

The distinction between these two models is worth establishing early because they address different requirements. If a customer's compliance requirement is that data must not leave their cloud environment, service exposure approaches like PrivateLink may not be sufficient, depending on how the application processes data. If the requirement is private network connectivity without public internet exposure, PrivateLink is often simpler to implement and operate.

The approaches below are among those most commonly used on AWS. Other patterns exist, including VPC peering, Transit Gateway architectures, and custom cross-account networking configurations, each with their own tradeoffs. This guide focuses on three that are purpose-built for SaaS use cases:

AWS PrivateLink is a highly available, scalable technology that enables private connectivity between VPCs and services without requiring an internet gateway, NAT device, public IP address, or VPN connection. For SaaS use cases, it allows a vendor to expose their service to a customer's VPC over the AWS network.

On the vendor side, the application typically runs behind a Network Load Balancer (NLB) in the vendor's VPC. The vendor creates a VPC endpoint service and associates it with the NLB, then grants specific customer AWS accounts permission to connect.

On the customer side, an interface VPC endpoint is created in the customer's VPC, provisioning Elastic Network Interfaces (ENIs) with private IP addresses drawn from the customer's subnet. Traffic flows through these ENIs over the AWS network. The vendor can require manual approval for each connection request, and private DNS can be configured for consistent hostname access within the customer's VPC.

Suited for: customers that require private network connectivity to a vendor service without data traversing the public internet, where the requirement is network-level isolation rather than compute or data isolation.

Tradeoffs:

• The vendor's application runs in the vendor's account. Data is processed in the vendor's environment, not the customer's. This does not satisfy requirements that mandate compute or data stays within the customer's cloud boundary.
• PrivateLink is AWS-specific and does not extend natively to GCP or Azure customer environments.
• When exposing a service to multiple tenants through a shared NLB, tenant routing and isolation require careful design. A pooled NLB across tenants introduces cross-tenancy considerations that need to be addressed at the application or network policy layer.
• Interface endpoints are accessible from within the customer's VPC and from connected networks such as Site-to-Site VPN or Direct Connect, but not directly from the public internet without additional tooling.

In-VPC deployment, also referred to as BYOC (Bring Your Own Cloud), means the vendor deploys and operates application components directly inside the customer's cloud account. The vendor's control plane, which handles CI/CD, configuration management, monitoring, and update delivery, stays in the vendor's account and connects to the customer's environment through a secure cross-account mechanism.

On AWS this typically uses IAM cross-account roles with least-privilege permissions. The equivalent on GCP is cross-project service accounts; on Azure it is managed identities. The vendor's control plane uses these mechanisms to provision resources, push deployments, and read operational telemetry without storing credentials in the customer's environment. Data processed by the application does not leave the customer's environment during normal operation.

Suited for: customers whose compliance framework or security policy requires that application compute and data remain within their own cloud boundary. Common for HIPAA, FedRAMP, and air-gapped use cases where service exposure approaches do not satisfy the isolation requirement.

Tradeoffs:

• The vendor must provision and manage infrastructure in each customer's cloud account separately. This becomes difficult to scale without automation.
• Each customer environment is a separate operational surface: provisioning, updates, observability, and incident response each need to be managed across account boundaries.
• The customer takes on some responsibility for the underlying cloud infrastructure, including network configuration, IAM, and the managed Kubernetes service if one is used.
• This approach can work across AWS, GCP, Azure, and on-premises Kubernetes environments, which suits customers on different cloud providers.

Amazon VPC Lattice is a fully managed application networking service that connects services and resources across multiple VPCs and accounts within a service network. For SaaS use cases, vendors create a VPC Lattice service in their account and share it with customer accounts using AWS Resource Access Manager (RAM). The customer associates the shared service with their VPC Lattice service network and applies auth policies to control which of their services can communicate with it.

VPC Lattice auth policies use IAM resource policies, allowing fine-grained control over which principals in the customer's account can invoke the vendor's service, down to specific paths or actions. VPC Lattice also supports on-premises access via a VPC endpoint powered by AWS PrivateLink, for customers connecting over Direct Connect or VPN.

Suited for: multi-account microservices architectures where the SaaS product is one service among several in the customer's environment, and fine-grained IAM-based service-to-service access control is a requirement.

Tradeoffs:

• Like PrivateLink, the vendor's application runs in the vendor's account. The customer's data is sent to the vendor's environment for processing.
• VPC Lattice is AWS-specific.
• Transitive sharing is not supported through AWS RAM. The vendor must share the service directly with each customer account. A customer account cannot re-share the vendor's service with another account.
• Auth policies are not supported on resource configurations within a service network, only on services. This is worth checking against your specific architecture requirements.

The table below summarises some of the key differences across the three SaaS deployment approaches covered in this guide:

PrivateLink and VPC Lattice address private network connectivity to vendor-hosted services. In-VPC deployment addresses compute and data isolation within the customer's environment. These address different requirements, and one approach cannot generally substitute for another when the customer's requirement is specific about where data is processed.

If in-VPC deployment is the right approach, the operational challenge scales with the number of customer environments. Supporting one is a project. Supporting ten or more without automation is a significant engineering commitment.

Some of the key things that need to be built and operated for each customer environment include:

• Environment provisioning: in most modern implementations, each customer environment uses a Kubernetes cluster on the customer's cloud provider (EKS on AWS, GKE on GCP, AKS on Azure), VPC configuration, networking setup, and cloud provider roles for cross-account access. Done manually, this can take several weeks per customer, depending on the environment's complexity and the customer's internal security review process.
• Cross-account access management: the vendor's control plane needs a persistent, secure connection to each customer environment using least-privilege cloud provider mechanisms, maintained across all customer environments without storing credentials.
• CI/CD across multiple environments: the delivery pipeline needs to support targeting specific customer environments, progressive rollouts, and rollback on failure. Some customers require a change approval step before any update is applied to their environment.
• Configuration management: each customer environment may have variations such as custom domains, feature flag states, or regional configurations. A configuration layer that applies per-customer overrides without forking the application codebase is needed.
• Observability without data access: operational telemetry, such as CPU usage, memory, and error rates, needs to be collected from each customer environment without reading application-level data. This typically involves separation at the logging and metrics layer.
• Onboarding: provisioning a new customer environment, completing security configuration, networking setup, and testing can take several weeks without automation. The timeline varies depending on the customer's environment complexity and internal approval processes.

A common approach uses Infrastructure as Code tooling, such as Terraform, Pulumi, or AWS CDK, to define the customer environment template once and provision it repeatably across customer accounts. Kubernetes provides a consistent runtime layer across AWS EKS, GCP GKE, and Azure AKS. GitOps pipelines, using tools such as Argo CD or Flux, handle deployment delivery to multiple target environments from a single source of truth.

Building this system involves significant upfront engineering investment, including designing and maintaining a control plane, building the multi-environment CI/CD pipeline, handling cross-account connectivity, and building the configuration management layer, among other things. For many SaaS vendors, this infrastructure sits outside their core product.

Northflank provides a control plane for deploying and managing your application inside your customers' cloud environments across AWS, GCP, Azure, Oracle, and on-premises infrastructure from a single interface, so vendors do not have to build that infrastructure themselves.

Vendors define their application once using Northflank's templates, and Northflank handles provisioning, CI/CD, monitoring, and update delivery across customer environments. Each customer deployment runs on dedicated infrastructure with namespace-level separation, mTLS, encrypted secrets, and network policies applied by default.

For more on how the control plane and data plane separate across account boundaries, Northflank's BYOC guide covers the underlying architecture in detail.

No. With AWS PrivateLink, the vendor's application continues to run in the vendor's account. PrivateLink establishes a private network path so the customer's VPC can reach the vendor's service without going over the public internet. The customer's data is sent to the vendor's environment for processing. In-VPC deployment runs the vendor's application components inside the customer's own cloud account so that data processing happens within the customer's environment during normal operation.

PrivateLink provides private network connectivity to a vendor-hosted service. In-VPC deployment provisions vendor-operated application components inside the customer's cloud account. The key difference is where data is processed. PrivateLink keeps the application in the vendor's environment. In-VPC deployment keeps the application and data within the customer's environment during normal operation. The right choice depends on whether the customer's requirement is network-level isolation or compute and data isolation.

It can, provided the vendor's application is containerised. Kubernetes is the most common runtime layer for this, with AWS EKS, GCP GKE, and Azure AKS providing managed Kubernetes in the customer's environment. Cross-account access mechanisms differ per cloud provider: IAM roles on AWS, service accounts on GCP, and managed identities on Azure.

On AWS, the vendor's control plane assumes an IAM role in the customer's account using cross-account role assumption. The customer creates the role and grants the vendor's account permission to assume it, with permissions scoped to what the control plane needs. On GCP, cross-project service accounts work similarly. On Azure, managed identities are used. In these cases, no long-lived credentials need to be stored or shared.

Amazon VPC Lattice is a fully managed application networking service that connects services and resources across multiple VPCs and accounts within a service network. Unlike PrivateLink, which exposes service endpoints over the AWS network, VPC Lattice supports more complex multi-service architectures with fine-grained IAM-based auth policies at the service and service network level. Both keep the vendor's application in the vendor's account. VPC Lattice is well suited to multi-account microservices architectures where service-to-service access control across accounts is a primary requirement.