公開2026.07.25更新2026.09.30 Google Cloud

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

Cloud Load Balancingは、Googleのグローバルなフロントエンドインフラ上で動く、Google Cloudのフルマネージドな負荷分散サービスです。この記事では、アプリケーションロードバランサ・プロキシネットワークロードバランサ・パススルーネットワークロードバランサという3つの種類の違いを公式ドキュメントに当たりながら整理し、外部/内部・グローバル/リージョンというデプロイモードの選び分けを示します。さらに、転送ルールからバックエンドまでの構成要素、Cloud RunやGKE・Cloud Storageといったバックエンドの取り方、gcloudコマンドでCloud Runを背後に置くグローバル外部ロードバランサを組む手順、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）を選びます。料金は転送ルールの時間課金と、処理したデータ量に応じたデータ処理料金で決まり、公式の料金ページの米国表示では最初の5つの転送ルールで1時間0.025ドル、データ処理は1GiBあたり0.008ドルです（2026年9月時点）。構築そのものはgcloudの7コマンドで終わるので、後半の手順をそのまま手元のプロジェクトで試せます。どれを選ぶかで到達範囲・機能・費用が変わるため、判断軸の章を自社のワークロードへ当てはめてください。ロードバランサそのものの仕組みや振り分け方式の一般論は、ロードバランサーの仕組みと種類を解説した記事にまとめています。

Cloud Load Balancingとは何か：GFE上の仕組みと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万クエリ/秒を超えるトラフィックにも耐える点が強みです。種類とモードの全体像はCloud Load Balancingの概要ページに一覧があり、2026年9月24日の更新時点でアプリケーション・プロキシネットワーク・パススルーネットワークの3系統に整理されています。負荷分散で可用性を引き上げる考え方そのものは、可用性の設計を解説した記事で整理した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・ICMPv6も扱う第4層のパススルー型で、パケットを終端せずそのまま転送します。パススルーネットワークロードバランサの概要には、バックエンドVMが受け取るパケットの送信元・宛先IPとポートが変更されないと明記されており、クライアントの送信元IPアドレスがバックエンドまで保たれます。IP保持や非TCPプロトコルが要る要件では、このパススルー型が起点になるでしょう。

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

プロキシ型ではバックエンドから見た接続元がロードバランサになるため、アプリ側でクライアントIPを知るにはヘッダを読みます。外部アプリケーションロードバランサの概要によると、ロードバランサはX-Forwarded-Forヘッダへ「クライアントのIP」と「転送ルールのIP」の2つをカンマ区切りで末尾に追記します。アクセス制御やログでクライアントIPを扱うなら、この末尾から2番目の値を読む実装にしておくのが安全です。

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

種類を選んだら、次はデプロイモードを決めます。軸は「外部か内部か」と「グローバルかリージョンか」です。外部はインターネットからのトラフィックをVPCへ入れる用途、内部は同じVPCネットワーク内やVPN・Interconnectで繋いだクライアントからのトラフィックを分散する用途です。ALBとプロキシNLBは、グローバル外部（プレミアムティア必須）・リージョン外部・リージョン内部・クロスリージョン内部を選べます。パススルーNLBはリージョン外部と内部（内部は常にリージョン）が基本で、複数リージョンのバックエンドへ分散するグローバル外部は概要ページ上でプレビュー表記です（2026年9月時点）。複数リージョンへ利用者が散らばるサービスはグローバルやクロスリージョン、規制やデータ所在で地域を固定したいならリージョンを選ぶ、という判断になります。リージョン外部ALBやリージョン内部ALBを使う場合は、Envoyプロキシ用のプロキシ専用サブネットをリージョンごとに1つ用意する必要がある点も、ネットワーク設計の段階で織り込んでおきます。

クラシックALBとグローバル外部ALB（EXTERNAL_MANAGED）の違い

外部ALBには、従来の「クラシック」と、現行の「グローバル外部」という2つの系統が並存しています。gcloudで作るときの見分け方は--load-balancing-schemeの値で、クラシックがEXTERNAL、グローバル外部がEXTERNAL_MANAGEDです。クラシックはプレミアムティアではグローバル、スタンダードティアでは単一リージョンのバックエンドにしか振れません。ロードバランサの選び方のページでは、グローバル外部ALBでしか使えない新機能を得るために、既存のEXTERNALリソースをEXTERNAL_MANAGEDへ移行するよう推奨しています。作成後にモードは編集できないため、新規構築は最初からEXTERNAL_MANAGEDで作り、既存のクラシックは移行計画を別に立てるのが筋です。

Cloud Load Balancingの構成要素とバックエンドの取り方を理解する

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

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

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

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内でまとめられます。なおリージョンのインターネットNEGはCloud NATゲートウェイを伴うため、NAT側の時間課金とデータ転送料金が別に乗る点に注意してください。

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

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

gcloudでCloud RunをバックエンドにグローバルALBを構築する手順

ここからは手を動かします。題材は、既存のCloud RunサービスをサーバーレスNEGでグローバル外部ALBの背後に置き、Google管理のSSL証明書でHTTPSを受ける最小構成です。コマンドはサーバーレスNEGでグローバル外部ALBを設定する公式手順に沿っており、Cloud Runサービスはasia-northeast1（東京）にデプロイ済みという前提で書き換えています。大文字の値は自分の環境の名前に置き換えてください。

IPアドレスを予約しサーバーレスNEGとバックエンドサービスを作る

最初に外部IPアドレスをグローバルで予約し、Cloud RunサービスをまとめるサーバーレスNEGを作ります。続けてEXTERNAL_MANAGEDのバックエンドサービスを作成し、NEGをバックエンドとして追加する流れです。サーバーレスNEGはヘルスチェックを使わないため、この段階でヘルスチェックの作成は要りません。

# 1. 外部IPv4アドレスをグローバルで予約する（プレミアムティア）
gcloud compute addresses create lb-ip \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

# 予約したIPを確認する（DNSのAレコードに登録する値）
gcloud compute addresses describe lb-ip --global --format="get(address)"

# 2. Cloud RunサービスをまとめるサーバーレスNEGを作る
gcloud compute network-endpoint-groups create run-neg \
    --region=asia-northeast1 \
    --network-endpoint-type=serverless \
    --cloud-run-service=CLOUD_RUN_SERVICE_NAME

# 3. バックエンドサービスを作成し、NEGを追加する
gcloud compute backend-services create run-backend \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --global

gcloud compute backend-services add-backend run-backend \
    --global \
    --network-endpoint-group=run-neg \
    --network-endpoint-group-region=asia-northeast1

URLマップ・Google管理証明書・HTTPSプロキシ・転送ルールをつなぐ

次にURLマップで既定の振り先をバックエンドサービスへ向け、Google管理のSSL証明書を作ります。HTTPSのターゲットプロキシに証明書とURLマップを結び、最後に443番ポートの転送ルールで予約済みIPと紐付ければ構築は完了です。転送ルールにも--load-balancing-scheme=EXTERNAL_MANAGEDを付け忘れないようにします。付け忘れるとクラシック側のスキームとして扱われ、バックエンドサービスと噛み合わずエラーになるためです。

# 4. URLマップ（既定の振り先をrun-backendにする）
gcloud compute url-maps create run-url-map \
    --default-service=run-backend

# 5. Google管理のSSL証明書（ドメインは自分のものに置き換える）
gcloud compute ssl-certificates create run-cert \
    --domains=app.example.com \
    --global

# 6. HTTPSターゲットプロキシ
gcloud compute target-https-proxies create run-https-proxy \
    --ssl-certificates=run-cert \
    --url-map=run-url-map

# 7. 転送ルール（443番で予約IPと紐付ける）
gcloud compute forwarding-rules create run-https-rule \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --network-tier=PREMIUM \
    --address=lb-ip \
    --target-https-proxy=run-https-proxy \
    --global \
    --ports=443

パスで振り分けたい場合は、4のURLマップにgcloud compute url-maps add-path-matcherでパスマッチャーを足し、/api/*を別のバックエンドサービスへ向けます。転送ルールを増やさずに1つの外部IPへ系統を集約できるので、後述する転送ルールの時間課金を抑える手段にもなります。

証明書がACTIVEになるまで待ちcurlで疎通と送信元IPを確かめる

Google管理証明書は、ドメインのDNSのAレコード（IPv6も使うならAAAAレコード）がロードバランサのIPを指していないと発行されません。Google管理SSL証明書のドキュメントでは、発行までに最大60分、DNS伝播を含めると最大72時間かかる場合があるとされています。DNSをCloud DNSで管理しているなら、Cloud DNSの仕組みを解説した記事の手順でAレコードを追加しておくと待ち時間を読みやすくなります。

# 証明書の状態を確認する（PROVISIONING → ACTIVE になれば発行済み）
gcloud compute ssl-certificates describe run-cert \
    --global \
    --format="get(managed.status, managed.domainStatus)"

# ACTIVEになったらHTTPSで疎通を確かめる
curl -sI https://app.example.com/

# Cloud Run側でX-Forwarded-Forを出力するようにしておくと、
# 「クライアントIP,転送ルールのIP」の形でヘッダが届くことを確認できる

ステータスがFAILED_NOT_VISIBLEのまま進まないときは、DNSがまだ別のIPを向いているか、伝播が終わっていないケースがほとんどです。疎通できたら、Cloud Runのサービス設定でingressを「内部およびCloud Load Balancing」に絞り、run.appのURLへの直接アクセスを閉じておくと、Cloud ArmorやCDNを前段に重ねたときに迂回されません。

Cloud Load Balancingの料金体系と月額を見積もるコスト設計

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

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

料金は主に2要素で構成されます。1つ目は転送ルールに対する時間課金で、VPCネットワークの料金ページの米国表示では、最初の5つの転送ルールまでは合計で1時間0.025ドル、6つ目以降は1つにつき1時間0.01ドルが加わります（2026年9月時点）。グローバル転送ルールにはデータ処理料金が付かず、データ処理はトラフィックを処理したリージョン側で課金される仕組みです。2つ目はロードバランサが処理したデータ量に応じたデータ処理料金で、米国（Iowa）表示ではインバウンドとアウトバウンドがそれぞれ1GiBあたり0.008ドルです。アウトバウンド側は料金変更のお知らせのとおり2022年10月1日からポートフォリオ全体に適用され、単価はリージョンにより1GBあたり0.008〜0.012ドル系と案内されています。東京（asia-northeast1）の単価は料金ページのリージョン切り替えで表示されるため、見積もり時点の値を必ず確認してください。

課金要素	対象	抑える打ち手
転送ルール	最初の5つまで0.025ドル/時	URLマップで外部IPを集約
データ処理	入出力とも0.008ドル/GiB〜	CDNでキャッシュし処理量削減
ネットワークティア	Premium/Standardの経路差	系統ごとにティアを使い分け
証明書の鍵種別	RSA-3072/4096の接続数	RSA-2048かECDSAを使う

具体的な数字に置くと、転送ルール1本を1か月（730時間）動かすと0.025ドル×730時間で約18.25ドル、入出力それぞれ1TiB（1,024GiB）を処理すると米国単価でおよそ8.19ドルずつが加わります。前章の構成なら月30ドル台が出発点になり、ここに下りのデータ転送料金やCloud Runの利用料が乗る形です。見落としやすいのは証明書の鍵種別で、Cloud Load Balancingのリリースノートには、RSA-3072とRSA-4096の自己管理証明書を使うと100万接続あたり0.45ドルが追加され、RSA-2048やECDSA P-256/P-384には接続課金がないと記載されています。金額は改定で動くため、最終的な見積もりは公式の料金ページと料金計算ツールで時点の単価を取り直してください。

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

費用を左右するのは、ティアとデプロイモードの選び方、そして無駄なデータ処理の有無です。グローバルな低レイテンシが要らない社内向け系統をスタンダードティアへ寄せるだけでも経路コストは下がります。静的コンテンツの配信は前段にCloud CDNを重ねるのが定石で、キャッシュから返したオブジェクトはロードバランサを通らないため、データ処理課金の対象量そのものが減ります。Cloud Armorで遮断したリクエストも同じくロードバランサを通過しないと料金ページに書かれており、不要なボットトラフィックが多いサービスでは防御とコスト削減を兼ねられるでしょう。転送ルールは要件ごとに乱立させず、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で冗長化の必要がない小規模構成や、トラフィックが常に小さく分散の意味が薄い用途です。この場合はロードバランサを挟まず、必要になった時点で導入するほうが構成も課金も軽くなります。Cloud Runだけで完結し独自ドメインも不要なら、run.appのURLをそのまま使う方法も選択肢の一つです。ワークロードの中心が他クラウドにあるなら、そのクラウドのロードバランサ（AWSのELB、AzureのLoad Balancer/Application Gateway）へ寄せるのが筋で、AWS側の種類の違いはALBとELBの違いを整理した記事が比較の起点になります。VMの中で細かい振り分けロジックを自前で持ちたい、あるいはマルチクラウドで同じ設定を使い回したいなら、HAProxyの仕組みと設定を解説した記事のようなソフトウェアロードバランサを内側に置く構成も候補です。はまりやすい失敗は3つあります。1つはHTTPアプリにパススルーNLBを選び、パスルーティングやSSL終端ができず作り直す構成です。2つ目は送信元IPで認可するアプリにプロキシ型（ALB/プロキシNLB）を選び、X-Forwarded-Forを読む実装をしないまま全リクエストがロードバランサのIPに見えて認可が壊れる構成。3つ目は新規構築をクラシック（EXTERNAL）で作ってしまい、後からモードを変えられず作り直しになる構成です。プロトコルと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と単一のロードバランサでマルチリージョン配信を組める点です。どちらを使うかは、ワークロードを載せるクラウドに合わせて選びます。

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

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

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

料金は主に、稼働中の転送ルールに対する時間課金と、ロードバランサが処理したデータ量に応じたデータ処理料金で構成されます。米国表示では最初の5つの転送ルールまで1時間0.025ドル、データ処理は入出力とも1GiBあたり0.008ドルで、リージョンによって単価が上がります（2026年9月時点）。転送ルール1本と入出力各1TiBなら月30ドル台が目安です。自己管理証明書でRSA-3072/4096を使うと接続数課金が加わるため、見積もりは公式の料金ページと料金計算ツールで時点の単価を確認してください。

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

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