---
title: "Backend Egress"
description: "Compare Static IPs, Secure Compute, and PrivateLink. Pick the right model for Saturday and configure it."
canonical_url: "https://vercel.com/academy/optimize-your-vercel-account/backend-egress"
md_url: "https://vercel.com/academy/optimize-your-vercel-account/backend-egress.md"
docset_id: "vercel-academy"
doc_version: "1.0"
last_updated: "2026-07-22T06:33:26.016Z"
content_type: "lesson"
course: "optimize-your-vercel-account"
course_title: "Optimize Your Vercel Account"
prerequisites:  []
---

<agent-instructions>
Vercel Academy — structured learning, not reference docs.
Lessons are sequenced.
Adapt commands to the human's actual environment (OS, package manager, shell, editor) — detect from project context or ask, don't assume.
The lesson shows one path; if the human's project diverges, adapt concepts to their setup.
Preserve the learning goal over literal steps.
Quizzes are pedagogical — engage, don't spoil.
Quiz answers are included for your reference.
</agent-instructions>

# Backend Egress

# Backend Egress

\*\*Note: Plan tier\*\*

Static IPs are Pro+. Secure Compute and PrivateLink are Enterprise. This lesson includes a Pro feature inside the Enterprise section because it pairs naturally with the other two.

Saturday's stock-check endpoint talks to a fictional warehouse. In our app it's a `setTimeout`, but in a real deployment that's a real database, a real ERP, a real partner inventory service. That backend probably has an opinion about who's allowed to call it. The opinion usually arrives as an IP allowlist: "we only accept connections from these specific addresses."

By default, Vercel functions egress from a wide pool of dynamic IPs. That's fine for calling public APIs. It's a problem the moment your backend gets stricter. You have three options for fixing that, and which one fits depends on how much isolation and dedicated networking you actually need.

This lesson is more decision-making than configuration. We'll compare the three models, then configure whichever one is right for Saturday.

\*\*Note: What is backend egress?\*\*

The outbound traffic your functions send to databases, APIs, and other
backends. By default it leaves Vercel from a changing pool of IPs. The three
features in this lesson control which addresses it leaves from and what
network it travels through.

## Outcome

You've picked one of Static IPs, Secure Compute, or PrivateLink for Saturday based on its actual needs, and you've configured it (or made an informed decision not to).

## The three options

| Option             | Tier              | Cost model                                               | Isolation                             | When to use                                                                                                            |
| ------------------ | ----------------- | -------------------------------------------------------- | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Static IPs**     | Pro+              | Flat monthly fee per project, plus Private Data Transfer | Shared VPC, subnet-level isolation    | Backend just wants stable IPs to allowlist. You don't need VPC peering or dedicated networking.                        |
| **Secure Compute** | Enterprise        | Custom pricing                                           | Dedicated VPC, full network isolation | Backend requires VPC peering, regulatory isolation, or you want a private subnet that's truly yours.                   |
| **PrivateLink**    | Enterprise (beta) | Not finalized                                            | Direct connection to one AWS endpoint | You have one specific AWS resource (a database, a service) and want a dedicated private connection without a full VPC. |

The decision flow:

```
Does the backend require VPC peering or dedicated networking?
├── Yes  →  Secure Compute
└── No
    │
    Does the backend live on AWS and you only need one connection?
    ├── Yes  →  PrivateLink (when GA)
    └── No   →  Static IPs
```

For Saturday, the realistic answer is Static IPs. The fictional warehouse is a third-party API that wants an allowlist. We don't need a private VPC; we need a few stable IPs to give them.

## Hands-on exercise 6.4

The configuration is short. The decision and the coordination with your backend team take longer.

**Requirements:**

1. Read the three options above. Match Saturday's hypothetical warehouse situation to one of them. For this lesson, assume **Static IPs** (the warehouse just wants stable IPs).
2. Open Saturday > Settings > Networking (older dashboards label this tab Connectivity)
3. Enable **Static IPs**. Vercel assigns a pair of static IPs for each region your functions run in, drawn from a shared VPC.
4. Copy the assigned IPs and send them to whoever maintains your backend's allowlist. (For Saturday, that's an exercise of imagination.)
5. (If on Enterprise) Take a moment to read the **Secure Compute** documentation linked from the same page. If you ever need to migrate from Static IPs to Secure Compute, the steps live there. The migration isn't transparent, your egress IPs change.

**Implementation hints:**

- Static IPs is billed per project. If you have ten projects and only two need static egress, enable it on those two; the other eight save the cost.
- Bandwidth through the static IP path is metered as Private Data Transfer (separate from regular Fast Origin Transfer). It's a different SKU and tends to be more expensive per GB.
- Static IPs are all-or-nothing per project. Once enabled, every outbound call your functions make routes through the static path and meters as Private Data Transfer, including calls to public APIs that never asked for an allowlist. If only one or two routes need static egress, the standard move is to split those routes into a small separate project and enable Static IPs there, so the rest of your traffic stays on the default path.
- There's a separate **Use Static IPs for builds** toggle, off by default. Leave it off unless your build itself has to reach an allowlisted backend. Dependency installs and build-time data fetching through the static path meter as Private Data Transfer too.
- Secure Compute, when you're on it, comes with a setup call. Vercel walks you through VPC peering setup with AWS. It is not a self-serve UI for most teams. Budget a few days for the configuration.
- PrivateLink is in private beta as of writing, and the pricing isn't finalized. If your use case is "one AWS database," it's worth a conversation with your Vercel account team.

## Try It

Once Static IPs is enabled, deploy Saturday. Then send a request from one of the API routes that needs the egress:

```ts
// In a route handler or function:
const res = await fetch('https://backend.example/inventory', {
  headers: { 'X-Tenant': 'saturday' }
});
```

On the backend side, the request should arrive from one of the IPs Vercel assigned to your project (visible under Settings > Networking). If the backend isn't yours, you'll need them to confirm receipt; if it is, you can see the source IP in your access logs.

For Saturday specifically, since the warehouse is fictional, the proof is the configuration screen itself:

```
Settings > Networking
  Static IPs:    Enabled
  Egress IPs:    198.51.100.10
                 198.51.100.11
  Private Data Transfer:  [usage metric]
```

## Done-When

- [ ] You've read the three options and can articulate when each applies
- [ ] Saturday has the appropriate egress model enabled (or you've documented why none is needed)
- [ ] The assigned static IPs (if any) are documented somewhere your backend team can see them
- [ ] You understand the cost model for your chosen option

## Troubleshooting

**My backend still rejects calls after I added the static IPs.**

The backend team might not have actually applied the allowlist yet, or the change is propagating. Have them verify the rule is live and that the IPs are in it exactly as Vercel reports them. Watch for the trailing `/32` if their allowlist uses CIDR notation.

**Static IPs are enabled but the backend sees different source IPs.**

Check where the call is actually coming from. Function traffic routes through the static IPs automatically, but middleware runs at the edge and doesn't, and build-time traffic only uses the static path if you've turned on the builds toggle. If the call in question lives in middleware, move it into a route handler.

**Secure Compute setup is taking longer than expected.**

It's normal. VPC peering involves coordination on both sides (your AWS account and Vercel's). Budget a week from initial call to fully operational, including testing. If you need faster, Static IPs is the bridge while Secure Compute is being set up.

## Solution

For Saturday, the chosen configuration:

```
Settings > Networking
  Static IPs:   Enabled
  Egress IPs:   [one IP pair per configured region]
  Project:      saturday
```

Documentation note in your repo, somewhere a backend team can find it:

```md
## Saturday backend connectivity
- Egress: Static IPs (Vercel Pro+)
- IPs: 198.51.100.10, 198.51.100.11
- Last updated: 2026-05-27
- Allowlist contact: <backend team email>
```

If your project graduates from Static IPs to Secure Compute (it's bigger, more revenue, more sensitive), the migration is real work but the conceptual difference is small: you're moving from a shared subnet to a dedicated VPC. The mental model is the same.

Up next: the last lesson in the course. Managed firewall rulesets, the rules you get for free with Enterprise that catch attack patterns you'd otherwise have to write yourself.


---

[Full course index](/academy/llms.txt) · [Sitemap](/academy/sitemap.md)