--- title: How to choose the right Vercel networking option description: Decide whether your project needs a networking option at all, then choose between Static IPs, AWS PrivateLink, Secure Compute, and Bring Your Own Cloud. url: "https://vercel.com/kb/guide/how-to-choose-the-right-vercel-networking-option" published: 2026-10-08 last_updated: 2026-10-08 authors: William Armstrong install_vercel_plugin: npx plugins add vercel/vercel-plugin --- By default, Vercel Functions and builds send outbound traffic from a shared, rotating set of IP addresses. That's fine for most backends, and it becomes a question only when a backend enforces where traffic comes from or requires a private path. Vercel covers those cases with networking options that range from a stable egress IP pair to compute running in your own AWS account. The right choice starts with confirming you need one at all. In this guide, you'll learn how to: - Decide whether you need a networking option at all, or whether default protections and identity-based auth like OIDC federation already cover you - Match your backend to Static IPs, AWS PrivateLink, Secure Compute, or Bring Your Own Cloud - Compare what each option costs, which plan it requires, and what it does not do ## Do you need a networking option at all Most projects don't. Before you evaluate any option, confirm that you have a real network requirement rather than something credentials or default protections already cover. Run the checks below in order, and continue to the next section only if a genuine network rule survives all of them. ### What already protects you by default Your deployments have baseline protection without any networking add-on. Vercel routes traffic over its global network, and you control who can reach a deployment with inbound tools, not outbound networking: - [Deployment Protection](https://vercel.com/docs/deployment-protection) to restrict access to your deployments - Custom rules and IP blocking in the Vercel WAF - [Trusted IPs](https://vercel.com/docs/deployment-protection/methods-to-protect-deployments/trusted-ips) to limit access by address, on Enterprise None of the networking options in this guide change inbound access. If your goal is to control who reaches your deployment, these inbound tools are the answer, and you can stop here. ### When identity-based auth removes the need If your backend wants proof of identity and you were reaching for an IP allowlist only to secure the connection, you may not need a networking option at all. [Vercel OIDC federation](https://vercel.com/docs/oidc) issues short-lived tokens signed by Vercel's OIDC identity provider. AWS, Google Cloud, and Azure exchange them for short-lived credentials, which removes long-lived secrets from your environment variables. It's available on all plans, including the [AWS integration](https://vercel.com/docs/oidc/aws). When the real requirement is credential security rather than a network rule, identity-based auth can cover it on its own. ### An IP allowlist is not authentication A request from an allowlisted address is still an unauthenticated request until you prove who's making it. Whatever you decide below, keep a username and password, an auth key, or OIDC credentials on top of any network control you add. The IPs alone aren't enough. For the longer discussion of why there's no fixed IP by default, and when a fixed IP is the right tool versus identity-based auth, see [Can I get a fixed IP address for my Vercel deployments?](https://vercel.com/kb/guide/can-i-get-a-fixed-ip-address). ### When you do need one You have a real network requirement when your backend enforces a rule you can't satisfy with credentials or inbound controls. That rule looks like one of these: - The backend only accepts connections from a known source IP, so you need a stable address to add to its allowlist. - The backend lives in a private network you can reach only over a private link, such as VPC peering. - A compliance or data-residency mandate requires compute to run inside your own cloud account. If one of these describes your situation, continue to the next section to choose an option. If none do, you likely don't need one. ## Which option do you need Find the row whose **Best for** column describes your situation, then confirm the network model and plan work for you. The networking docs overview groups Static IPs, Secure Compute, and Bring Your Own Cloud as the three networking options. AWS PrivateLink ships as part of Advanced Networking, and this guide includes it because it answers the same outbound decision. | Option | Best for | What it adds | Network model | | ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------ | | [**Static IPs**](https://vercel.com/docs/networking/static-ips) | Teams that need IP allowlisting without infrastructure changes | A stable, dedicated egress surface you can allowlist | Multi-tenant compute, shared VPC with subnet-level isolation | | [**AWS PrivateLink**](https://vercel.com/docs/networking/privatelink) | Reaching an AWS-hosted service behind a PrivateLink endpoint service | Private connectivity to AWS services with no public internet exposure | Shared VPC, dedicated endpoint per connection | | [**Secure Compute**](https://vercel.com/docs/networking/secure-compute) | Teams that need a private VPC, dedicated networks, or regulatory isolation | A network perimeter isolated from every other customer, with VPC peering | Single-tenant, dedicated VPC | | [**Bring Your Own Cloud**](https://vercel.com/docs/networking#bring-your-own-cloud) | Compliance or data-residency mandates that require workloads in your cloud | A network and compute boundary you own end to end | Compute runs in your own AWS account | If you're matching a specific backend, an IP-allowlist-only service on any cloud or on-premises, such as Amazon RDS, Google Cloud SQL, Azure SQL, MongoDB Atlas, Auth0, PayPal, or Stripe, points to Static IPs. An AWS service that publishes a PrivateLink endpoint service, such as RDS, Aurora, Neon, Redshift, Snowflake, MongoDB Atlas, Confluent, S3, DynamoDB, or a service behind a Network Load Balancer, points to AWS PrivateLink. A backend in a private VPC that needs VPC peering or a site-to-site VPN points to Secure Compute. Some services, including MongoDB Atlas and Snowflake, accept both allowlisted public traffic and PrivateLink connections, so either option can work for them. A few tie-breakers: - **Static IPs cover public connectivity.** Choose it when the backend accepts public traffic and only needs to know the source address. - **AWS PrivateLink only works for services that published an AWS PrivateLink endpoint service.** If your target is on-premises, on another cloud, or on AWS but not exposed through PrivateLink, use Static IPs with allowlisting or Secure Compute with VPC peering. - **Secure Compute covers private networks.** Choose it when you need to peer into your own AWS VPC, terminate a VPN to Azure, Google Cloud, or on-premises, or satisfy a regulatory requirement for a dedicated network perimeter. If a project uses both Secure Compute and Static IPs, Static IPs are ignored. - **Bring Your Own Cloud is a larger commitment.** Your functions run inside your own AWS account while Vercel orchestrates routing and invocation. Because it moves infrastructure outside Vercel's managed boundary, plan for a substantial setup project and ongoing ownership of your AWS account's service quotas, scaling headroom, and account health. Scope it with Vercel sales or your account team. For more, see the [Vercel networking overview](https://vercel.com/docs/networking). ## Static IPs Static IPs route your function and build traffic through a stable egress IP pair so your backend can allowlist a known source. Each configured region has its own static IP pair, so pick regions close to your backend to reduce latency. You can configure up to three regions per project. The service runs on a shared VPC for a small group of customers with subnet-level isolation and a managed NAT gateway. Traffic is egress only. Build traffic is off by default and is opted in per project. When builds are included, both build and function traffic route through the static IPs and count as Private Data Transfer. This setting applies to every environment in the project, so you can't route one environment differently from another. For the current setup steps, see [how to allowlist a deployment's IP address](https://vercel.com/kb/guide/how-to-allowlist-deployment-ip-address) and the [Static IPs getting started guide](https://vercel.com/docs/networking/static-ips/getting-started). ## AWS PrivateLink AWS PrivateLink connects your Vercel deployments to AWS-hosted backends over a private connection, without the public internet. It requires **Advanced Networking**. Vercel provisions a dedicated VPC endpoint in your team's shared network across two Availability Zones supported by the target service, and assigns a dedicated IAM role the provider can allowlist as a principal. Alternatively, the service can accept all principals. Function and build traffic both route through the endpoint, and the connection stays pending until the provider approves it. Each connection is provisioned in a single region, so multi-region access needs one connection per region, though the endpoint service itself can live in a different AWS region when the provider allows cross-region access. The endpoint service must be available in at least two Availability Zones that overlap with Vercel's network in that region or provisioning fails. A connection can optionally use Private DNS so your deployments resolve the provider's own private hostnames. Assigning a connection to a project applies to every environment in that project. The underlying VPC is shared, so if you need full network isolation, use Secure Compute instead. For the current setup steps, see the [AWS PrivateLink documentation](https://vercel.com/docs/networking/privatelink). ## Secure Compute Secure Compute places your functions in a dedicated, single-tenant private network inside a VPC, with its own static IP pair and NAT gateway. Each network lives in a single region you choose, and you can create multiple networks, optionally specifying a CIDR block and Availability Zones for each. Self-service creation isn't available to every Enterprise team, so contact your account team if you don't have it. Each project environment uses one active network, with an optional passive network in another region for failover and the option to include builds. Secure Compute connects to your own infrastructure two ways. VPC peering links to your AWS VPC, where the CIDR blocks must not overlap, and supports up to 50 peering connections per network and up to 100 projects per network. A site-to-site VPN terminated on the Secure Compute network reaches Azure, Google Cloud, and on-premises. Secure Compute applies to Vercel Functions on Node.js, Ruby, Go, and Python. Even with IP filtering in place, keep a username and password or an auth key on top, because the IPs alone aren't enough. For the current setup steps, see the [Secure Compute documentation](https://vercel.com/docs/networking/secure-compute). ## Cost and plan comparison Pricing and plan availability differ for each option. For Static IPs, Private Data Transfer is billed at regional rates, so check the [regional pricing documentation](https://vercel.com/docs/pricing/regional-pricing) for the rate in your regions. Secure Compute and AWS PrivateLink use their own published rates, shown below. | Option | Plans | Pricing | Data transfer | | -------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Static IPs | Pro and Enterprise | $100 per project per month on Pro. The docs don't publish a separate Enterprise rate. | Private Data Transfer at regional rates on all Static IPs traffic, including build traffic when builds are enabled | | AWS PrivateLink | Pro and Enterprise, as part of Advanced Networking | The first connection is included with Advanced Networking. Each additional connection costs $30 per month, per the [AWS PrivateLink changelog](https://vercel.com/changelog/aws-privatelink-is-now-available-on-pro-and-enterprise). | $0.04 per GB of PrivateLink data transfer, per the same changelog | | Secure Compute | Enterprise add-on | Arranged with your account team | Private Data Transfer at $0.15/GB, charged only for traffic that leaves the private network over the public internet. Traffic sent over VPC peering doesn't incur data transfer charges | | Bring Your Own Cloud | Enterprise | Contact sales. | Discuss with sales. | ## What each option does not do Every option here solves outbound connectivity. None of them changes how inbound traffic reaches your deployment, and each carries exclusions worth planning around before you commit. - **None of these control inbound traffic.** Static IPs, AWS PrivateLink, and Secure Compute govern egress from your deployment. Vercel doesn't offer a fixed inbound IP, and inbound requests don't route through the Static IP service. To control who can reach your deployment, use [Deployment Protection](https://vercel.com/docs/deployment-protection), custom rules and IP blocking in the Vercel WAF, or [Trusted IPs](https://vercel.com/docs/deployment-protection/methods-to-protect-deployments/trusted-ips) on Enterprise. - **Runtime exclusions.** Static IPs, AWS PrivateLink, and Secure Compute don't apply to Routing Middleware. Secure Compute supports Vercel Functions on Node.js, Ruby, Go, and Python, and doesn't support the Edge Runtime or Routing Middleware. Traffic from those runtimes won't use the networking option you configure. - **Beta feature limits.** Static IPs and Secure Compute don't support the extended max duration beta, the large functions beta, or the container images beta. If you depend on one of those betas, plan around this before you commit. - **PrivateLink interface-only and scope limits.** AWS PrivateLink supports interface endpoints only, which includes AWS services like S3 and DynamoDB that publish interface endpoint services. Gateway Endpoints, Gateway Load Balancer Endpoints, and Resource Endpoints aren't supported. Each connection exists in a single AWS region, so multi-region access needs one connection per region, and every connection applies to all environments in the project. - **None of these authenticate requests.** An allowlisted IP or a private path controls where traffic comes from, not who's sending it. Keep credentials, an auth key, or OIDC on top of the network control. ## Next steps - Read the [Vercel networking overview](https://vercel.com/docs/networking) to compare the networking options in one place. - If your requirement is credential security rather than a network rule, set up [Vercel OIDC federation](https://vercel.com/docs/oidc) and its [AWS integration](https://vercel.com/docs/oidc/aws). - Follow [how to allowlist a deployment's IP address](https://vercel.com/kb/guide/how-to-allowlist-deployment-ip-address) to set up Static IPs end to end. - Review the [Static IPs documentation](https://vercel.com/docs/networking/static-ips), the [AWS PrivateLink documentation](https://vercel.com/docs/networking/privatelink), and the [Secure Compute documentation](https://vercel.com/docs/networking/secure-compute) for the option you chose. - For the full background on fixed IPs, inbound controls, and troubleshooting, see [Can I get a fixed IP address for my Vercel deployments?](https://vercel.com/kb/guide/can-i-get-a-fixed-ip-address).