Meningkatkan waktu respons gateway dengan memanfaatkan Cloud CDN
Menggunakan NEG tanpa server untuk API Gateway
Grup endpoint jaringan (NEG) menentukan grup endpoint backend untuk load balancer. NEG serverless adalah backend yang mengarah ke backend serverless yang dihosting Google seperti Cloud Run, App Engine, atau API Gateway.
Backend NEG tanpa server untuk API Gateway dapat merepresentasikan:
Instance API Gateway
Grup gateway yang dikonfigurasi dengan konfigurasi API yang sama
Gambar berikut menunjukkan cara penggunaan NEG serverless dalam model Cloud Load Balancing:
Seperti yang diilustrasikan dalam contoh sebelumnya, layanan backend dapat dikelola oleh beberapa NEG tanpa server. Setiap NEG tanpa server dapat berisi satu instance API Gateway atau menggunakan masker URL untuk mengarah ke beberapa gateway. Karena semua NEG yang bertindak sebagai layanan backend digunakan untuk load balancing, NEG tersebut harus merepresentasikan deployment gateway yang setara secara fungsional. Misalnya, semua NEG harus memiliki konfigurasi API yang sama yang di-deploy ke setiap gateway di berbagai region. Jika layanan backend berisi beberapa NEG, load balancer akan menyeimbangkan traffic di antara NEG ini sekaligus meminimalkan latensi permintaan.
Batasan pada NEG tanpa server dan API Gateway
Beberapa batasan harus dipertimbangkan saat menggunakan NEG serverless untuk mengintegrasikan Cloud Load Balancing untuk API Gateway. Terutama:
NEG tanpa server tidak dapat memiliki Endpoint Jaringan, seperti alamat IP atau port, yang terpasang.
NEG tanpa server hanya dapat mengarah ke instance API Gateway yang berada di region yang sama dengan tempat NEG dibuat.
NEG Tanpa Server hanya dapat mengarah ke instance API Gateway yang dibuat dalam project yang sama dengan load balancer menggunakan backend NEG Tanpa Server.
API Gateway tidak mendukung setelan kontrol Ingress. Akibatnya, tidak ada cara untuk menonaktifkan akses ke API Gateway Anda menggunakan URL gateway yang dibuat layanan dan memastikan bahwa semua traffic ditangani oleh load balancer.
Untuk mengetahui informasi selengkapnya tentang batasan terkait NEG serverless dan layanan backend secara umum, lihat Batasan.
Batasan pada NEG serverless dalam konfigurasi layanan backend
Layanan backend menentukan cara Cloud Load Balancing mendistribusikan traffic. Konfigurasi layanan backend berisi serangkaian nilai, seperti protokol yang digunakan untuk terhubung ke backend, berbagai setelan distribusi dan sesi, health check, dan waktu tunggu. Untuk NEG serverless yang digunakan sebagai layanan backend untuk API Gateway, setelan ini memberikan kontrol terperinci atas perilaku load balancer Anda.
Definisi resource layanan backend memiliki implikasi berikut untuk desain load balancing Anda:
NEG Tanpa server tidak dapat digunakan dengan jenis NEG lainnya dalam layanan backend yang sama. Misalnya, Anda tidak dapat merutekan ke cluster GKE dan instance API Gateway dari layanan backend yang sama.
Semua NEG tanpa server yang digabungkan dalam layanan backend harus menggunakan jenis backend yang sama. Artinya, NEG tanpa server API Gateway hanya dapat digabungkan dengan NEG tanpa server API Gateway lainnya, NEG tanpa server App Engine hanya dapat digabungkan dengan NEG tanpa server App Engine.
Layanan backend hanya dapat berisi satu NEG Serverless per region.
Saat menentukan konfigurasi layanan backend yang merutekan ke NEG serverless, batasan kolom berikut berlaku:
balancingMode tidak dapat ditentukan
Kolom healthCheck harus kosong dan tidak boleh ditentukan
Port tidak dapat ditentukan
Hanya protokol HTTP dan HTTPS yang didukung.
Nilai yang ditentukan di kolom terkait utilization atau connection tidak didukung.
Kolom IAP, cdnPolicy, dan securityPolicy dalam konfigurasi layanan backend valid untuk NEG serverless. Kolom ini dapat digunakan untuk menyiapkan Identity-Aware Proxy, Cloud CDN, dan Cloud Armor masing-masing dengan layanan API Gateway Anda.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)"]]
