[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[],[],null,["# External Application Load Balancer use cases\n\nThe external Application Load Balancers address many use cases. This page provides some\nhigh-level examples.\n\nThree-tier web services\n-----------------------\n\nYou can use an external Application Load Balancer to support traditional\nthree-tier web services. The following example shows how you can use three types\nof Google Cloud load balancers to scale three tiers. At each tier, the\nload balancer type depends on your traffic type:\n\n- **Web tier:** Traffic enters from the internet and is load balanced by using\n an [external Application Load Balancer](/load-balancing/docs/https).\n\n- **Application tier:** The application tier is scaled by using a regional\n internal Application Load Balancer.\n\n- **Database tier:** The database tier is scaled by using an\n [internal passthrough Network Load Balancer](/load-balancing/docs/internal).\n\nThe diagram shows how traffic moves through the tiers:\n\n1. An external Application Load Balancer (the subject of this overview) distributes traffic from the internet to a set of web frontend instance groups in various regions.\n2. These web frontends send the HTTP(S) traffic to a set of regional, internal Application Load Balancers. For the external Application Load Balancer to forward traffic to an internal Application Load Balancer, the external Application Load Balancer must have backend instances with web server software (such as Netscaler or NGINX) configured to forward the traffic to the frontend of the internal Application Load Balancer.\n3. The internal Application Load Balancers distribute the traffic to middleware instance groups.\n4. These middleware instance groups send the traffic to internal passthrough Network Load Balancers, which load balance the traffic to data storage clusters.\n\n[](/static/load-balancing/images/ilb-l7-tiers.svg) Layer 7-based routing for internal tiers in a multitier app (click to enlarge).\n\nMulti-region load balancing\n---------------------------\n\nWhen you configure an external Application Load Balancer in Premium Tier, it uses a global\nexternal IP address and can intelligently route requests from users to the\nclosest backend instance group or NEG, based on proximity. For example, if you\nset up instance groups in North America, Europe, and Asia, and attach them to a\nload balancer's backend service, user requests around the world are\nautomatically sent to the VMs closest to the users, assuming the\nVMs pass health checks and have enough capacity (defined by the balancing mode).\nIf the closest VMs are all unhealthy, or if the closest instance group is at\ncapacity and another instance group is not at capacity, the load balancer\nautomatically sends requests to the next closest region with capacity.\n\nIn Premium Tier, the external Application Load Balancer provides\nmulti-region load balancing, using multiple backend services,\neach with backend instance groups or NEGs in multiple regions.\n[](/static/load-balancing/images/https-load-balancer-diagram.svg) Representation of multiregion load balancing (click to enlarge).\n\nWorkloads with jurisdictional compliance\n----------------------------------------\n\nSome workloads with regulatory or compliance requirements require that network\nconfigurations and traffic termination reside in a specific region. For these\nworkloads, a regional external Application Load Balancer is often the preferred\noption to provide the jurisdictional controls these workloads require.\n\nAdvanced traffic management\n---------------------------\n\nWith global external Application Load Balancers and regional external Application Load Balancers, you can add\nadvanced traffic management capabilities that give you fine-grained control over\nhow traffic is handled. These capabilities help you to meet your availability\nand performance objectives. One of the benefits of using\nexternal Application Load Balancers for these use cases is that you can update how\ntraffic is managed without needing to modify your application code.\n\nFor more details, see the following:\n\n- [Traffic management\n overview for global external Application Load Balancer](/load-balancing/docs/https/traffic-management-global).\n- [Traffic management\n overview for regional external Application Load Balancer](/load-balancing/docs/https/traffic-management-regional).\n\nLoad balancing with request routing\n-----------------------------------\n\nThe external Application Load Balancer supports request routing by using URL maps\nto select a backend service based on the requested host name, request path, or\nboth. For example, you can use a set of instance groups or NEGs to handle your\nvideo content and another set to handle everything else.\n\nYou can also use external Application Load Balancers with [Cloud Storage](/storage)\n[buckets](/storage/docs/json_api/v1/buckets). After you have your load balancer\nset up, you can [add Cloud Storage\nbuckets](/load-balancing/docs/https/ext-load-balancer-backend-buckets) to\nit.\n\nFor more information, see [URL map\nconcepts](/load-balancing/docs/url-map-concepts).\n\nLoad balancing for GKE applications\n-----------------------------------\n\nThere are two ways to deploy external Application Load Balancers for GKE clusters:\n\n- **[GKE Gateway\n controller](/kubernetes-engine/docs/concepts/gateway-api).** Supported by the global external Application Load Balancer and the classic Application Load Balancer. For setup instructions, see [Deploying\n gateways](/kubernetes-engine/docs/how-to/deploying-gateways).\n- **[GKE Ingress\n controller](/kubernetes-engine/docs/concepts/ingress-xlb).** Supported by the classic Application Load Balancer and the regional external Application Load Balancer. For setup instructions, see [Configuring Ingress for\n external Application Load Balancers](/kubernetes-engine/docs/how-to/load-balance-ingress).\n\nLoad balancing for Cloud Run, Cloud Run functions, and App Engine applications\n------------------------------------------------------------------------------\n\nYou can use a global external Application Load Balancer as the frontend for your\nCloud Run, Cloud Run functions, and\nApp Engine applications. To set this up, you use a serverless NEG for\nthe load balancer's backend.\n\nThis diagram shows how a serverless NEG fits into the external Application Load Balancer\nmodel.\n[](/static/load-balancing/images/lb-serverless-simple-ext-https.svg) HTTPS load balancing for serverless apps (click to enlarge).\n\nRelated documentation:\n\n- [Serverless NEGs overview](/load-balancing/docs/negs/serverless-neg-concepts)\n- [Setting up an external Application Load Balancer with\n Cloud Run, Cloud Run functions, or\n App Engine](/load-balancing/docs/https/setting-up-https-serverless)\n\nProxying traffic to external backends with internet connectivity\n----------------------------------------------------------------\n\nCloud Load Balancing supports proxying traffic to external backends\noutside Google Cloud. You can use this type of deployment when you want to serve\ncontent from an external backend, but you want your Google Cloud load\nbalancer to be the frontend. The load balancer proxies traffic to your external\nendpoint by using Google's highly reliable backbone network for most of its\njourney, and only hands off to the public internet close to the destination.\n[](/static/load-balancing/images/internet-neg-sample-arch.svg) Internet network endpoint groups in load balancing (click to enlarge).\n\nRelated documentation:\n\n- [Set up a global external Application Load Balancer with an internet\n NEG](/load-balancing/docs/https/setup-global-ext-https-external-backend)\n- [Set up a classic Application Load Balancer with an internet\n NEG](/load-balancing/docs/https/setting-up-https-external-backend-internet-neg)\n\nLoad balancing with hybrid connectivity\n---------------------------------------\n\nCloud Load Balancing supports load-balancing traffic to endpoints that extend\nbeyond Google Cloud, such as on-premises data centers and other public clouds\nthat you can use [hybrid connectivity](/hybrid-connectivity) to reach.\n\nThe following diagram demonstrates a hybrid deployment with a\nglobal external Application Load Balancer.\n[](/static/load-balancing/images/ext-https-hybrid.svg) Hybrid connectivity with an external Application Load Balancer (click to enlarge).\n\nRelated documentation:\n\n- [Hybrid connectivity NEGs overview](/load-balancing/docs/negs/hybrid-neg-concepts)\n- [Setting up an external Application Load Balancer with on-premises or other cloud\n backends](/load-balancing/docs/https/setting-up-ext-https-hybrid)\n\nLoad balancing with Private Service Connect\n-------------------------------------------\n\nYou can use a global external Application Load Balancer to access services that are\npublished using Private Service Connect.\n\nFor more information, see\n[About Private Service Connect backends](/vpc/docs/private-service-connect-backends)."]]