네트워크 엔드포인트 그룹(NEG)은 부하 분산기의 백엔드 엔드포인트 그룹을 지정합니다. 서버리스 NEG는 Cloud Run, App Engine, API 게이트웨이와 같은 Google에서 호스팅되는 서버리스 백엔드를 가리키는 백엔드입니다.
API 게이트웨이의 서버리스 NEG 백엔드는 다음을 제공할 수 있습니다.
API 게이트웨이 인스턴스
동일한 API 구성을 사용하는 게이트웨이 그룹
다음 그림은 Cloud Load Balancing 모델에서 서버리스 NEG를 사용하는 방법을 보여줍니다.
이전 예에서 설명한 것처럼 백엔드 서비스는 여러 서버리스 NEG로 관리될 수 있습니다. 각 서버리스 NEG는 단일 API 게이트웨이 인스턴스를 포함하거나 URL 마스크를 사용해서 여러 게이트웨이를 가리킬 수 있습니다. 백엔드 서비스로 작동하는 모든 NEG가 부하 분산에 사용되기 때문에 기능적으로 동일한 게이트웨이 배포를 지원합니다. 예를 들어 모든 NEG는 서로 다른 리전에 있는 각 게이트웨이에 배포된 것과 동일한 API 구성을 갖습니다. 백엔드 서비스에 여러 NEG가 포함된 경우 부하 분산기가 이러한 NEG 간에 트래픽을 분산하여 요청 지연 시간을 최소화합니다.
서버리스 NEG 및 API 게이트웨이에 대한 제한사항
API 게이트웨이에 대해 Cloud Load Balancing을 통합하기 위해 서버리스 NEG를 사용하는 경우에는 몇 가지 제한사항을 고려해야 합니다. 특히 다음 항목에 주의해야 합니다.
서버리스 NEG는 IP 주소 또는 포트와 같이 연결된 네트워크 엔드포인트를 가질 수 없습니다.
서버리스 NEG는 NEG가 생성된 동일 리전에 있는 API 게이트웨이 인스턴스에만 연결될 수 있습니다.
서버리스 NEG는 서버리스 NEG 백엔드를 사용하여 부하분산기와 동일한 프로젝트에 생성된 API 게이트웨이 인스턴스에만 연결될 수 있습니다.
API 게이트웨이는 인그레스 제어 설정을 지원하지 않습니다. 따라서 서비스로 생성된 게이트웨이 URL을 통해 API 게이트웨이에 대해 액세스를 사용 중지하고 부하 분산기로 모든 트래픽이 처리되도록 할 수 있는 방법이 없습니다.
일반적으로 서버리스 NEG 및 백엔드 서비스와 관련된 제한사항에 대한 자세한 내용은 제한사항을 참조하세요.
백엔드 서비스 구성의 서버리스 NEG에 대한 제한사항
백엔드 서비스는 Cloud Load Balancing이 트래픽을 분산하는 방법을 정의합니다. 백엔드 서비스 구성에는 백엔드에 연결하는 데 사용되는 프로토콜, 다양한 배포 및 세션 설정, 상태 확인, 제한 시간 등의 다양한 값 집합이 포함됩니다. API 게이트웨이에 대해 백엔드 서비스로 사용되는 서버리스 NEG의 경우 이러한 설정을 통해 부하 분산기의 작동 방식을 세밀하게 제어할 수 있습니다.
백엔드 서비스의 리소스 정의는 부하 분산 설계에 다음과 같은 영향을 줍니다.
동일한 백엔드 서비스에서 서버리스 NEG를 다른 유형의 NEG와 함께 사용할 수 없습니다. 예를 들어 동일한 백엔드 서비스에서 GKE 클러스터 및 API 게이트웨이 인스턴스로 라우팅할 수 없습니다.
백엔드 서비스에 조합된 모든 서버리스 NEG는 동일한 유형의 백엔드를 사용해야 합니다. 즉, API 게이트웨이 서버리스 NEG는 다른 API 게이트웨이 서버리스 NEG와만 조합할 수 있고, App Engine 서버리스 NEG는 App Engine 서버리스 NEG와만 조합할 수 있습니다.
백엔드 서비스에는 리전당 서버리스 NEG 하나만 포함될 수 있습니다.
서버리스 NEG로 라우팅되는 백엔드 서비스 구성을 정의할 때는 다음과 같은 필드 제한사항이 적용됩니다.
balancingMode를 지정할 수 없습니다.
healthCheck 필드는 비어 있어야 하고 지정할 수 없습니다.
포트를 지정할 수 없습니다.
HTTP 및 HTTPS 프로토콜만 지원됩니다.
utilization 또는 connection 관련 필드에 지정된 값은 지원되지 않습니다.
[[["이해하기 쉬움","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-03(UTC)"],[[["\u003cp\u003eAPI Gateway can integrate with Global external Application Load Balancer or Classic Application Load Balancer through serverless Network Endpoint Groups (NEGs) to leverage Cloud Load Balancing features.\u003c/p\u003e\n"],["\u003cp\u003eServerless NEGs for API Gateway can represent either a single API Gateway instance or a group of gateways sharing the same API configuration, enabling load balancing between functionally equivalent deployments.\u003c/p\u003e\n"],["\u003cp\u003eThere are several limitations to serverless NEGs for API Gateway, including restrictions on network endpoints, regional scope, and project constraints, along with an inability to disable direct access to API Gateways.\u003c/p\u003e\n"],["\u003cp\u003eBackend services that use serverless NEGs have specific configuration limitations, such as not being able to mix different types of NEGs, and restrictions on \u003ccode\u003ebalancingMode\u003c/code\u003e, \u003ccode\u003ehealthCheck\u003c/code\u003e, ports, protocols, \u003ccode\u003eutilization\u003c/code\u003e, or \u003ccode\u003econnection\u003c/code\u003e-related field settings.\u003c/p\u003e\n"],["\u003cp\u003eDespite the limitations, backend service configurations allow for the integration of Identity-Aware Proxy, Cloud CDN, and Cloud Armor with API Gateway through serverless NEGs.\u003c/p\u003e\n"]]],[],null,["# Load balancing for API Gateway\n==============================\n\n|\n| **Preview**\n|\n|\n| This product or feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA products and features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\n\nThe integration of [Global external Application Load Balancer](/load-balancing/docs/https) and [Classic Application Load Balancer](/load-balancing/docs/https) support for API Gateway enables your serverless backends to take advantage of all the features provided by Cloud Load Balancing. By combining API Gateway with a global external Application Load Balancer or classic Application Load Balancer using a [serverless Network Endpoint Group (serverless NEG)](/load-balancing/docs/negs), you can:\n\n- Host gateways with custom branded domains\n- Configure TLS for gateways using certificates issued by a preferred certificate authority\n- Create a common entry point for a gateway routing to multiple backends\n- Deploy gateways in multiple geographic regions for high availability without managing URLs for each region\n- Protect gateways with [Cloud Armor](/armor/docs)\n- Improve gateway response time by leveraging [Cloud CDN](/cdn/docs)\n\nUsing a serverless NEG for API Gateway\n--------------------------------------\n\nA [network endpoint group (NEG)](/load-balancing/docs/negs) specifies a group of backend endpoints for a load balancer. A *serverless NEG* is a backend that points to a Google-hosted serverless backend like [Cloud Run](/run/docs), [App Engine](/appengine/docs), or API Gateway.\nA serverless NEG backend for API Gateway can represent:\n\n- An API Gateway instance\n- A group of gateways configured with the same API config\n\nThe following figure shows how serverless NEGs can be used in the Cloud Load Balancing model:\n\nAs illustrated in an earlier example, a backend service can be managed by several serverless NEGs. Each serverless NEG can contain a single API Gateway instance or use a [URL mask](/load-balancing/docs/negs/serverless-neg-concepts#url_masks) to point to multiple gateways. Because all NEGs acting as a backend service are used for load balancing, they should represent functionally equivalent gateway deployments. For example, all NEGs should have the same API config deployed to each gateway in different regions. If a backend service contains several NEGs, the load balancer will balance traffic between these NEGs while minimizing request latency.\n\nLimitations on serverless NEGs and API Gateway\n----------------------------------------------\n\nA few limitations should be considered when using serverless NEGs to integrate Cloud Load Balancing for API Gateway. Most notably:\n\n- Serverless NEGs cannot have any [Network Endpoints](/compute/docs/reference/rest/v1/networkEndpointGroups/attachNetworkEndpoints), such as IP addresses or ports, attached.\n- Serverless NEGs can only point to API Gateway instances residing in the same region where the NEG is created.\n- Serverless NEGs can only point to API Gateway instances created in the same project as the load balancer using the Serverless NEG backend.\n- API Gateway doesn't support Ingress control settings. As a result, there is no way to disable access to your API Gateway using a service-generated gateway URL and ensure that all traffic is handled by the load balancer.\n\nFor more information on restrictions pertaining to serverless NEGs and backend services generally, see [Limitations](/load-balancing/docs/negs/serverless-neg-concepts#limitations).\n\nLimitations on serverless NEGs in backend service configurations\n----------------------------------------------------------------\n\nA [backend service](/compute/docs/reference/rest/v1/backendServices) defines how Cloud Load Balancing distributes traffic. The backend service configuration contains a set of values, such as the protocol used to connect to backends, various distribution and session settings, health checks, and timeouts. For serverless NEGs used as a backend service for API Gateway, these settings provide fine-grained control over how your load balancer behaves.\n\nThe resource definition of a backend service has the following implications for your load balancing design:\n\n- Serverless NEGs cannot be used with other types of NEGs in the same backend service. For example, you cannot route to a GKE cluster and an API Gateway instance from the same backend service.\n- All serverless NEGs combined in a backend service must use the same type of backend. This means API Gateway serverless NEGs can only be combined with other API Gateway serverless NEGs, App Engine serverless NEGs can only be combined with App Engine serverless NEGs.\n- A backend service may only contain one Serverless NEG per region.\n\nWhen defining a backend service configuration that routes to a serverless NEG, the following field limitations apply:\n\n- The `balancingMode` cannot be specified\n- The `healthCheck` field must be empty and cannot be specified\n- Ports cannot be specified\n- Only HTTP and HTTPS protocols are supported.\n- Values specified in `utilization` or `connection`-related fields are not supported.\n\nThe `IAP`, `cdnPolicy`, and `securityPolicy` fields in the backend service configuration are valid for serverless NEGs. These fields can be used to set up [Identity-Aware Proxy](/iap/docs), [Cloud CDN](/cdn/docs), and [Cloud Armor](/armor/docs) respectively with your API Gateway service.\n\nWhat's next?\n------------\n\n- Configure a load balancer with [Getting started with global external Application Load Balancer for API Gateway](/api-gateway/docs/gateway-serverless-neg)\n\n- Walk through [Creating multi-region deployments](/api-gateway/docs/multi-region-deployment) for API Gateway\n\n- Learn more about [Using custom domains](/api-gateway/docs/using-custom-domains)"]]