2026.07.25 インフラ

Cloud Load Balancingとは？Google Cloudの種類・料金・選び分けを実装者目線で解説【2026年版】

Cloud Load Balancingは、Googleのグローバルなフロントエンドインフラ上で動く、Google Cloudのフルマネージドな負荷分散サービスです。この記事では、アプリケーションロードバランサ・プロキシネットワークロードバランサ・パススルーネットワークロードバランサという3つの種類の違いを一次情報で整理し、外部/内部・グローバル/リージョンというデプロイモードの選び分けを示します。さらに、転送ルールからバックエンドまでの構成要素、Cloud RunやGKE・Cloud Storageといったバックエンドの取り方、Premium/Standardティアと転送ルール・データ処理の課金、そしてどの種類を選ぶべきかの判断軸まで、実装者が設計で迷う論点を具体的に言い切ります。

まとめ：Cloud Load Balancingの種類と選び分けの要点

Cloud Load Balancingは、単一のエニーキャストIPで受けたトラフィックを、Compute EngineやCloud Run・GKEといった複数のバックエンドへ振り分けるGoogle Cloudの負荷分散サービスです。Googleのフロントエンドインフラ（GFE）の上に構築されており、HTTP(S)からUDPまで幅広いプロトコルを、100万クエリ/秒を超える規模で裁けます。設計で最初に決めるのは種類で、Webアプリなら第7層のアプリケーションロードバランサ、単一TCPならプロキシネットワークロードバランサ、クライアントの送信元IPをそのまま保ちたいならパススルーネットワークロードバランサ、という三択になります。

種類が決まったら、外部か内部か、グローバルかリージョンか、というデプロイモードとネットワークサービスティア（Premium/Standard）を選びます。料金は転送ルールの時間課金と、処理したデータ量に応じたデータ処理料金で決まります。どれを選ぶかで到達範囲・機能・費用が変わるため、後半の判断軸を自社のワークロードへ当てはめてください。ロードバランサそのものの仕組みや振り分け方式の一般論は、ロードバランサーの仕組みと種類を解説した記事にまとめています。

Cloud Load Balancingの仕組みと3つの種類

Cloud Load Balancingを設計へ落とすには、まず「種類ごとに扱えるプロトコルと動作モデルが違う」という前提を押さえます。ここを取り違えると、要件に噛み合わない種類を選び、後からやり直す羽目になりやすいためです。

GoogleのGFE上で動くマネージド負荷分散サービスの全体像

Cloud Load Balancingは、Googleが世界中に持つフロントエンドインフラ（Google Front End）の上で動きます。利用者は単一のグローバルなエニーキャストIPへアクセスし、そのリクエストは最も近いGoogleのエッジで受けてから健全なバックエンドへ振り分けられる仕組みです。物理アプライアンスやプロキシVMを自前で立てる必要はなく、スケーリングやフェイルオーバーはサービス側に委ねられます。対応プロトコルはHTTP(S)・HTTP/2・gRPC・TCP・SSL・UDP・QUICと広く、規模としては100万クエリ/秒を超えるトラフィックにも耐える点が強みです。負荷分散で可用性を引き上げる考え方そのものは、可用性の設計を解説した記事で整理したSPOF排除やフェイルオーバーの延長線上にあります。

アプリケーションロードバランサとプロキシ/パススルーNLBの違い

種類は大きく3つです。1つ目のアプリケーションロードバランサ（ALB）は、HTTP/HTTPSを扱う第7層のプロキシ型で、URLパスやホスト名でルーティングでき、SSL終端やContent-based routingを行えます。2つ目のプロキシネットワークロードバランサは、TCPを扱う第4層のプロキシ型で、必要に応じてSSLオフロードを担い、HTTP以外のTCPアプリを分散したいときに選ぶ型です。3つ目のパススルーネットワークロードバランサは、TCP・UDPに加えESP・GRE・ICMPなども扱う第4層のパススルー型で、パケットを終端せずそのまま転送するため、クライアントの送信元IPアドレスがバックエンドまで保たれます。IP保持や非TCPプロトコルが要る要件では、このパススルー型が起点になります。

種類 層・プロトコル 動作と向く用途
アプリケーションロードバランサ L7・HTTP/HTTPS プロキシ型・パスやホストで振り分け
プロキシネットワークロードバランサ L4・TCP（SSL可） プロキシ型・HTTP以外のTCP分散
パススルーネットワークロードバランサ L4・TCP/UDP/ESP等 パススルー型・送信元IP保持

外部/内部とグローバル/リージョンというデプロイモードの選び分け

種類を選んだら、次はデプロイモードを決めます。軸は「外部か内部か」と「グローバルかリージョンか」です。外部はインターネットからのトラフィックをVPCへ入れる用途、内部は同じVPCネットワーク内やVPN・Interconnectで繋いだクライアントからのトラフィックを分散する用途です。ALBとプロキシNLBは、グローバル外部（プレミアムティア必須）・リージョン外部・リージョン内部・クロスリージョン内部を選べます。パススルーNLBは常にリージョン単位で、外部と内部を持つのが特徴です。複数リージョンへ利用者が散らばるサービスはグローバルやクロスリージョン、規制やデータ所在で地域を固定したいならリージョンを選ぶ、という判断になります。

Cloud Load Balancingの構成要素とバックエンドの取り方

Cloud Load Balancingは複数のリソースの組み合わせで成り立ちます。構成要素の役割を分けて理解しておくと、設定が散らからず、どこで振り分けやヘルスチェックを効かせるかが見えてきます。

転送ルールからターゲットプロキシ・バックエンドまでの構成要素

入口は転送ルール（forwarding rule）で、フロントエンドのIPアドレスとポート、プロトコルを定義します。ALBやプロキシNLBでは、転送ルールがターゲットプロキシを指し、URLマップがパスやホストに応じてバックエンドサービスへ振り分けます。バックエンドサービスは、分散方式・セッションアフィニティ・タイムアウトといった振る舞いと、実際の処理を担うバックエンド群を束ねる単位です。そして各バックエンドの生死はヘルスチェックが監視し、正常と判定されたバックエンドだけへトラフィックが流れます。パススルーNLBはプロキシを介さずバックエンドサービスへ直結する点が異なりますが、ヘルスチェックで健全なインスタンスへ振るという骨格は共通です。

Cloud Run・GKE・Cloud Storageなどのバックエンド

バックエンドには多様なリソースを据えられます。Compute Engineのマネージドインスタンスグループ、Cloud Storageのバックエンドバケット（静的コンテンツ配信）、Cloud RunやCloud Functions・App Engineを束ねるサーバーレスNEG、GKEのService/Ingress/Gateway、外部オリジンを指すインターネットNEG、オンプレや他クラウドへ繋ぐハイブリッドNEGなどです。たとえばコンテナで動くアプリなら、GKEの仕組みを解説した記事で触れたService/Ingressをバックエンドに据え、サーバーレス構成ならCloud Runを解説した記事のサーバーレスNEGを使います。外部ALBの前段では、静的配信を速めるCloud CDNや、WAF・DDoS防御を担うCloud Armorを重ねられ、配信・保護・分散をGoogle Cloud内でまとめられます。

ネットワークサービスティア（Premium/Standard）の選択

Cloud Load Balancingは、ネットワークサービスティアの選択でも到達経路と費用が変わります。プレミアムティアはGoogleのバックボーンを最後まで使い、グローバル外部のロードバランサでは必須です。スタンダードティアは公衆インターネット経由の区間を増やして費用を抑える選択肢で、リージョン外部やリージョン内部で選べますが、グローバル外部には対応しません。グローバルな低レイテンシ配信を狙うならプレミアム、単一リージョンでコストを絞りたいならスタンダード、という基準で選びます。ティアはリソース単位でも指定できるため、要件の異なる系統を混在させる構成も取れます。

Cloud Load Balancingの料金体系とコスト設計

Cloud Load Balancingのコストは、同じ構成でも課金要素の理解とデプロイモードの選び方で変わります。何にいくら掛かるのかを分解し、余分な転送ルールやデータ処理を削るのが起点です。

転送ルールの時間課金とアウトバウンドのデータ処理課金の考え方

料金は主に2要素で構成されます。1つ目は転送ルールに対する時間課金で、稼働している転送ルールの数と時間に応じて掛かる仕組みです。2つ目はロードバランサが処理したアウトバウンドのデータ処理料金で、2022年10月の改定以降、Cloud Load Balancingのポートフォリオ全体に対して1GBあたりおおむね0.008〜0.012ドル系（リージョン別・時点により変動）が適用されます。さらに2026年2月の改定で、ヘルスチェックプローバーからパススルーネットワークロードバランサへのトラフィックや、IPv6でリージョンをまたぐ転送などが料金表どおりに整理されます。金額は改定で動くため、見積もりは必ず公式の料金ページと料金計算ツールで時点の単価を確認してください。

課金要素 対象 抑える打ち手
転送ルール 稼働中の転送ルール数×時間 不要な転送ルールの統廃合
データ処理 処理したアウトバウンドのデータ量 CDNでキャッシュし不要トラフィック削減
ネットワークティア Premium/Standardの経路差 系統ごとにティアを使い分け

ネットワークサービスティアとデプロイモードでコストを抑える実務

費用を左右するのは、ティアとデプロイモードの選び方、そして無駄なデータ処理の有無です。グローバルな低レイテンシが要らない社内向け系統をスタンダードティアへ寄せるだけでも経路コストは下がります。静的コンテンツの配信は前段にCloud CDNを重ね、ロードバランサが処理するデータ量そのものを減らすとデータ処理課金が効いてくるのが実務です。転送ルールは要件ごとに乱立させず、URLマップのパスルーティングで1つの外部IPに集約できないかを先に検討します。実測はCloud MonitoringやCloud Loggingで系統別のトラフィックを可視化し、処理量の多い経路から見直すのが確実です。感覚で全系統をプレミアムに固定せず、要件に応じて振り分けるのがコスト管理の勘所になります。

どのCloud Load Balancingを選ぶべきかの判断ポイント

ここでは判断を言い切ります。種類やデプロイモードを誤ると、要件を満たせない、あるいは費用対効果を出せません。自社のワークロードのどこにどの種類を差し込むかを、条件付きで見極めてください。

Cloud Load Balancingの種類選定の判断軸と採用が効く条件

選定の第一軸はトラフィック種別です。HTTP/HTTPSのWebアプリやAPIならアプリケーションロードバランサを選び、パスやホスト単位のルーティング・SSL終端を任せます。HTTP以外の単一TCPアプリ（データベースプロキシや独自プロトコル）ならプロキシネットワークロードバランサ、TCPとUDPの混在やESP・ICMPを通す必要がある、あるいはクライアントの送信元IPをバックエンドで見たいならパススルーネットワークロードバランサです。第二軸は到達範囲で、複数リージョンへ利用者が散るサービスはグローバル外部（プレミアム）やクロスリージョン内部、地域を固定したいならリージョンを選びます。採用が効くのは、Google Cloud上でCompute EngineやCloud Run・GKEを複数バックエンドで動かし、可用性とスケールを上げたいケースです。こうしたGoogle Cloud上のインフラ構成を自社に取り入れるなら、AWS・Google Cloud・Azureに対応したクラウドインフラ構築の相談窓口で、負荷分散の種類選定やコスト見積もりを含めた構成の妥当性を相談するとよいでしょう。

Cloud Load Balancingを見送り他手段へ寄せる場面と失敗パターン

見送るべきなのは、バックエンドが単一VMで冗長化の必要がない小規模構成や、トラフィックが常に小さく分散の意味が薄い用途です。この場合はロードバランサを挟まず、必要になった時点で導入するほうが構成も課金も軽くなります。ワークロードの中心が他クラウドにあるなら、そのクラウドのロードバランサ（AWSのELB、AzureのLoad Balancer/Application Gateway）へ寄せるのが筋で、Cloud Load Balancingを無理に横断利用すると管理が煩雑になります。はまりやすい失敗は2つです。1つはHTTPアプリにパススルーNLBを選び、パスルーティングやSSL終端ができず作り直す構成、もう1つは送信元IPで認可するアプリにプロキシ型（ALB/プロキシNLB）を選び、全リクエストがロードバランサのIPに見えて認可が壊れる構成です。プロトコルとIP保持要件を最初に確定させる——この一点を守れば、Cloud Load Balancingの分散性能を安全に引き出せます。

よくある質問

Cloud Load Balancingの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

Cloud Load Balancingの種類はどう選べばよいですか？

まずトラフィック種別で分けます。HTTP/HTTPSのWebアプリやAPIはアプリケーションロードバランサ、HTTP以外の単一TCPアプリはプロキシネットワークロードバランサ、TCP/UDP混在やクライアントの送信元IPを保ちたい要件はパススルーネットワークロードバランサです。次に外部/内部と、グローバル/リージョンのデプロイモードを到達範囲と規制要件で決めます。プロトコルとIP保持の要否を最初に確定させると、種類の候補が一つに絞れます。

Cloud Load BalancingはAWSのELBと何が違いますか？

役割は同じ負荷分散ですが、別クラウドの製品です。AWSのELBがApplication Load BalancerとNetwork Load Balancerに分かれるのと同様、Cloud Load Balancingもアプリケーションロードバランサとネットワークロードバランサ（プロキシ/パススルー）に分かれます。大きな違いは、Cloud Load BalancingがグローバルなエニーキャストIPと単一のロードバランサでマルチリージョン配信を組める点です。どちらを使うかは、ワークロードを載せるクラウドに合わせて選びます。

グローバルとリージョンはどう使い分けますか？

利用者が複数リージョンへ散らばり、どこからでも近いエッジで受けて低レイテンシに配信したいならグローバル（またはクロスリージョン内部）を選びます。反対に、データ所在の規制で地域を固定したい、単一リージョンで完結する社内システムといった要件ならリージョンを選ぶのが基本です。グローバル外部はプレミアムティアが必須で、スタンダードティアはリージョン系のデプロイで選べる点も判断材料になります。

Cloud Load Balancingの料金はどう決まりますか？

料金は主に、稼働中の転送ルールに対する時間課金と、ロードバランサが処理したアウトバウンドのデータ量に応じたデータ処理料金で構成されます。データ処理は1GBあたりおおむね0.008〜0.012ドル系（地域別・時点で変動）です。2026年2月の改定でヘルスチェックからパススルーNLBへのトラフィックなどの課金が整理されるため、見積もりは公式の料金ページと料金計算ツールで時点の単価を確認してください。

Cloud CDNやCloud Armorとはどう組み合わせますか？

外部アプリケーションロードバランサの前段に、静的配信を速めるCloud CDNや、WAF・DDoS防御を担うCloud Armorを重ねられます。Cloud CDNはバックエンドでCDNを有効化するフラグとして動き、Cloud Armorはセキュリティポリシーとしてロードバランサへ紐付ける形です。配信・保護・分散をGoogle Cloud内でまとめられるため、外部サービスを別管理するより構成と課金の見通しが立ちやすくなります。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る