AWS PrivateLinkをVercelで使う:Pro・Enterprise向けの料金・設定・制限
VercelのPro・EnterpriseチームでAWS PrivateLinkが利用可能になりました。対応するAWSサービスへの接続の仕組み、Advanced Networkingの料金、設定手順、リージョンやDNSの制約、Static IPs・Secure Computeとの選び分けを具体的に解説します。

2026年9月1日、VercelはAdvanced Networkingを通じて、ProおよびEnterpriseチームにAWS PrivateLinkの提供を開始しました。Vercel Functionsとビルドから対応するAWSサービスまでをプライベート経路で接続できるため、トラフィックをパブリックインターネットに通す必要がありません。

Vercelで使うAWS PrivateLinkとは
PrivateLinkが変えるのは、Vercelプロジェクトとバックエンドを結ぶ経路です。バックエンドを移動する機能でも、認証を置き換える仕組みでも、利用者専用のクラウドをVercelが用意するサービスでもありません。
Vercelのネットワークから、公開済みのAWSサービスへ伸びる専用通路と考えると分かりやすいでしょう。VPCエンドポイントは、その通路への入口です。VPCはvirtual private cloudの略で、AWSにおける分離されたネットワーク境界を指します。2つのアベイラビリティーゾーンを使う場合、Vercelは対象サービスが対応する2つのゾーンにまたがってエンドポイントを配置します。
接続を作成すると、Vercelはチーム専用のエンドポイントをプロビジョニングします。配置先は、接続先サービスが対応する2つのアベイラビリティーゾーンです。さらにVercelは、そのチームにAWS IAMロールを割り当てます。これはサービス所有者が許可できるIDです。接続には、次の固定ホスト名も付与されます。
<service>.team_<team-id>.endpoints.vercel.com
デプロイ済みのFunctionsとビルドジョブは、このホスト名を使用します。対象サービスへのトラフィックはプライベートエンドポイントを通り、Vercelはその接続の転送量を記録します。
仕組みの要点はここにあります。アプリケーションが通信する相手は、従来どおりホスト名です。そのホスト名宛てのパケットをプライベート経路へ流すのは、ネットワーク側です。

AWS PrivateLinkで変わる公開範囲と料金
変わったのは、ネットワークへの露出です。Proチームでも、専用VPCへ移行することなく、対応するバックエンドへのトラフィックをパブリックインターネットから切り離せるようになりました。
接続先がRDS、Aurora、Neon、Redshift、Snowflake、MongoDB Atlas、Confluent、AWS Network Load Balancerの背後にある内部サービス、またはゲートウェイエンドポイント経由のS3やDynamoDBであれば、この機能が役立ちます。ただし、接続先がAWS PrivateLinkエンドポイントサービスを公開していることが前提です。公開されていなければ、接続先そのものがありません。
Advanced Networkingを導入するかどうかが決まれば、料金体系は明快です。最初のPrivateLink接続はAdvanced Networkingに含まれます。追加の接続ごとに月額$30、PrivateLinkを通過する転送量にはGBあたり$0.04が課金されます。
具体例として、2つのリージョン接続で合計500 GBを転送するとします。転送料は$20です。追加の接続に$30がかかるため、公表されているPrivateLinkの接続料と転送料は合計で月額$50になります。
今回のリリースにHobbyユーザーは含まれません。バックエンドがAWS外にあるチーム、PrivateLinkエンドポイントを公開していないチーム、またはパブリック通信を安全に受け入れられるチームにも、すぐに変化はありません。
要件に合うネットワーク構成を選ぶ
Vercelの各ネットワーク経路は、それぞれ異なる課題を解決します。
PrivateLinkは両者の中間に位置します。単一のサービスにプライベート経路を用意しますが、基盤となるVPCは共有のままです。要件が「シングルテナントのネットワーク」であればSecure Computeを選びます。「既知のIPアドレス」が必要なだけで、パブリック経路を許容できるなら、Static IPsで十分な場合があります。
すぐに活用できるのは誰か
AWSデータベースを使うSaaS創業者
アプリケーションをVercel Pro、データベースをRDSまたはAuroraで運用する創業者なら、プロジェクトをデータベースのエンドポイントサービスへ接続し、Vercel IAMロールを許可したうえで、アプリケーションのデータベースホストをVercel管理のホスト名へ切り替えられます。
得られる効果は限定的ですが明確です。既存のVercelデプロイフローを維持したまま、データベース通信をプライベート経路へ移せます。ネットワーク全体が分離されるわけではありませんが、セキュリティレビューを妨げていたパブリック経路を取り除ける可能性があります。
内部APIを公開するプラットフォームエンジニア
プラットフォームエンジニアは、内部サービスをAWS Network Load Balancerの背後に配置し、エンドポイントサービスを公開して、Vercelから提供されるIAMロールを許可リストに登録できます。これによりFunctionsは、パブリックAPIアドレスではなく固定ホスト名を通じて、そのサービスを呼び出せます。
境界部分の運用負担を減らせるのが利点です。サービス所有者が許可するのは単一のAWSプリンシパルだけで、サービスをパブリックインターネットに公開せずに済みます。
マネージドサービスを使うデータプロダクトチーム
Snowflake、MongoDB Atlas、Confluentを基盤にするデータプロダクトチームは、該当するAWS RegionでプロバイダーがPrivateLinkエンドポイントを提供していれば、それを利用できます。アプリケーションとビルドジョブは、同じプライベート接続を共有します。
Vercelのデプロイからデータサービスまでの経路を、より明快にできるのが利点です。ただし、この構成が成立するかどうかは、プロバイダー側のエンドポイント提供状況で決まります。
マルチリージョンでバックエンドを運用するチーム
複数のリージョンでユーザーの近くにバックエンドを配置する場合、AWS Regionごとに1つのPrivateLink接続が必要です。対応する各リージョンにサービスが存在するか、クロスリージョンPrivateLinkに対応していなければなりません。
すべての呼び出しを単一リージョンへ集約せずに、ネットワークへの露出を抑えられます。一方でコストも分かりやすく、リージョン接続を追加するたびに、転送料とは別に月額$30が加算されます。
AWS PrivateLinkの設定はネットワーク側の順序で進める
接続先が条件を満たすか確認する
サービス所有者またはプロバイダーから、AWSエンドポイントサービス名とRegionを入手します。そのサービスは、すべてのAWSプリンシパルを受け入れるか、Vercelがチームに付与するIAMロールを許可リストに登録できる必要があります。
Vercelのネットワーク機能を有効にする
プロジェクトを開き、Settings、Networking、Advanced Networking、AWS PrivateLinkの順に進みます。チームでAdvanced Networkingがまだ有効になっていなければ、ここで有効にします。
接続を作成する
New Connectionを選び、エンドポイントサービス名を入力して、対応するRegionを選択します。Private DNSを有効にするかどうかも決めます。
Vercelのホスト名を使う
アプリケーションのサービスホストに、Vercelが作成する固定の
endpoints.vercel.comホスト名を指定します。プロバイダーのプライベートホストゾーン名をVercelの共有ネットワークから名前解決できる前提では進めないでください。再デプロイして確認する
プロジェクトを再デプロイし、実行時のリクエストとビルド時のバックエンド向けリクエストが、どちらも接続を通じて成功することを確認します。
よくある落とし穴はDNSです。Vercelの共有ネットワーク上にあるインターフェイスエンドポイントからは、プロバイダーのプライベートホストゾーンを利用できません。AWSが生成したエンドポイント名やプロバイダーのパブリックホスト名ではなく、Vercel管理のホスト名を使います。
制約も押さえておく
各接続は1つのAWS Regionに存在します。プロジェクトへの割り当ては、そのプロジェクト内のすべての環境に適用されるため、同じプロジェクトで本番環境だけPrivateLinkを有効にし、プレビュー環境では無効にすることはできません。
Routing Middlewareも経路の対象外です。エッジで実行されるためです。対応するのはインターフェイスエンドポイントとゲートウェイエンドポイントだけで、Gateway Load Balancerエンドポイントとリソースエンドポイントには対応しません。
PrivateLinkが解決するのはネットワーク経路であり、アプリケーションの認可ではありません。データベースのパスワード、IAMポリシー、サービストークン、ユーザー権限は引き続き必要です。マネージドなプロバイダー認証情報を必要とするエージェントアプリには、Vercel Connectという別の認証レイヤーがあります。
導入すべきタイミング
ProまたはEnterpriseを利用しており、接続先がすでにAWS PrivateLinkエンドポイントを公開し、パブリックネットワーク経由の通信をなくすことで現実のセキュリティまたはコンプライアンス上の問題を解消できるなら、今週中に導入へ動くべきです。まずは対象サービスがあるAWS Regionで始め、リージョンを追加する前に、実行時とビルド時の両方の通信を確認します。
プロバイダーからエンドポイントサービス名を入手できない場合、同じプロジェクト内のプレビュー環境と本番環境で別々のネットワークルールが必要な場合、またはチームがAdvanced Networkingの料金を確認できていない場合は、導入を待つべきです。
バックエンド側の要件がIP許可リストだけで、パブリック経路を許容できるなら、代わりにStatic IPsを使います。専用VPCまたはVPCピアリングが要件ならSecure Computeを選びます。Hobbyチームと、AWS外のサービスを呼び出すチームは、今回のリリースによる影響を受けません。
2026年9月2日



