サービス間の安全な内部通信を実現する新機能
Vercel は、サービス間通信を簡素化しセキュリティを強化する「Service Bindings」機能を導入し、内部ネットワーク経由での自動 TLS 認証とルーティングを実現した。
キーポイント
Service Bindings の仕組み
サービス間でバインディングを宣言すると、Vercel が自動的に環境変数を注入し、コード側は通常の URL 呼び出しを行うだけで内部通信が可能になる。
セキュリティと複雑性の排除
リクエストがパブリックルートを迂回して Vercel の内部ネットワークを経由するため、手動での TLS 設定や認証管理が不要になり、サービス分離が保たれる。
観測可能性と課金体系
サービス間呼び出しは可視化され、CDN リクエストとは異なる「Service Requests」として課金される仕組みが導入された。
影響分析・編集コメントを表示
影響分析
この機能は、Vercel 上で構築されるマイクロサービスやサーバーレスアーキテクチャの複雑さを劇的に低減し、開発者がインフラの詳細（TLS、認証、ルーティング）を意識せずにアプリケーションロジックに集中できる環境を提供します。特に、セキュリティ要件が高い内部通信において、設定ミスを防ぐ効果と運用コストの削減が期待されます。
編集コメント
クラウドネイティブ開発において、サービス間の通信設定は常にボトルネックとなりがちですが、Vercel のこのアプローチはそれを自動化・抽象化する良い例です。
Service Bindings を使用すると、同じデプロイメント内にある別の Vercel サービスを安全に呼び出すことが容易になります。
あるサービスが他のサービスのバインディング（binding）を宣言すると、Vercel は自動的に設定された環境変数を注入します。つまり、ユーザーコードは通常通りその URL を取得できますが、内部の書き換え、ルーティング、認証、TLS 管理は Vercel が裏側で処理します。
これにより、Next.js フロントエンドが FastAPI バックエンドを呼び出すような、Vercel 上のマルチサービスアプリケーションが可能になります。同時に、サービスの分離性を維持し、ルーティング設定の簡素化も実現できます：
上記の例では、my_frontend は BACKEND_INTERNAL_URL に対して fetch() リクエストを送信することで、my_backend サービスに到達できるようになります。
FastAPI 側では、my_backend が通常のルート（route）を公開しています：
仕組みの内部
この URL はパブリックアドレスではなく、Vercel の内部を指しています。コードがこれを取得すると、リクエストは Vercel の内部ネットワークを経由して、デプロイメントへの他のすべてのリクエストと同じルーティング層へ到達し、そこからターゲットサービスへ転送されます。パブリックルートテーブルには決して到達せず、Vercel が TLS 信頼関係を自動的に設定するため、証明書設定なしで通常の HTTPS fetch が機能します。
サービスは、rewrite ルートによる公開またはバインディングによる非公開のいずれかで明示的に公開されない限り、到達不可能です。
観測性（Observability）
サービス間呼び出しも観測性ツールに表示されるため、どのバインドされたサービスが呼び出され、リクエストにどれほどの時間がかかったかを確認できます：
料金プラン
サービス間呼び出しは、Service Requests および Fast Origin Transfer として課金されます。CDN Requests や Fast Data Transfer としての課金は行われません。現在の料率については、サービスの価格および制限に関するページをご覧ください。
詳細はこちら
バインディングの宣言方法や完全なリファレンスを確認するには、バインディングドキュメントをお読みください。
続きを読む
原文を表示
Service Bindings make it easy for one Vercel service to securely call another within the same deployment.
When a service declares a binding for another service, Vercel automatically injects the configured environment variable. That means user code can fetch that URL normally, while Vercel handles the internal rewrite, routing, authentication, and TLS behind the scenes.
This enables multi-service applications on Vercel, like a Next.js frontend calling a FastAPI backend, while preserving service isolation and keeping routing configuration simple:
In the example above, my_frontend will be able to reach the my_backend service by making a fetch() request to BACKEND_INTERNAL_URL.
On the FastAPI side, my_backend exposes a normal route:
Under the hood
That URL points inside Vercel, not at a public address. When your code fetches it, the request travels over Vercel's internal network to the same routing layer that handles every other request to your deployment, which sends it to the target service. It never hits the public route table, and Vercel sets up the TLS trust for you, so a plain HTTPS fetch works with no certificate config.
A service is only reachable if you expose it, either publicly with a rewrite route or privately with a binding.
Observability
Service-to-service calls also appear in observability, so you can see which bound service was called and how long the request took:
Pricing
Service-to-service calls are billed as Service Requests and Fast Origin Transfer. They are not billed as CDN Requests or Fast Data Transfer. See services pricing and limits for current rates.
Learn more
Read the bindings documentation to declare bindings and see the full reference.
Read more
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み