Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Ringkasan grup endpoint jaringan tanpa server

Grup endpoint jaringan (NEG) menentukan grup endpoint backend untuk load balancer. NEG serverless adalah backend yang mengarah ke resource Cloud Run, App Engine, Cloud Run Functions, atau Gateway API.

NEG serverless dapat merepresentasikan salah satu hal berikut:

Resource Cloud Run atau sekelompok resource.
Fungsi atau grup fungsi Cloud Run (sebelumnya Cloud Run Functions generasi ke-2).
Fungsi atau grup fungsi Cloud Run (generasi ke-1)
Aplikasi lingkungan standar App Engine atau lingkungan fleksibel App Engine, layanan tertentu dalam aplikasi, versi tertentu dari aplikasi, atau grup layanan.
Gateway API yang menyediakan akses ke layanan Anda melalui REST API yang konsisten di semua layanan, terlepas dari implementasi layanan. Kemampuan ini berada dalam Pratinjau.

Load balancer yang didukung

Tabel berikut mencantumkan produk serverless yang didukung oleh setiap Load Balancer Aplikasi. NEG serverless tidak didukung oleh Load Balancer Jaringan proxy dan Load Balancer Jaringan passthrough.

Jenis NEG serverless	Load Balancer Aplikasi
Jenis NEG serverless	Internal regional	Internal lintas region	Eksternal global	Klasik	Eksternal regional
Cloud Run Mendukung Cloud Run dan Cloud Run Functions (generasi ke-2)
App Engine
Cloud Functions Mendukung Cloud Run Functions (generasi ke-1), sebelumnya dikenal sebagai Cloud Functions generasi ke-1

Kasus penggunaan

Saat load balancer diaktifkan untuk aplikasi serverless, Anda dapat melakukan hal berikut:

Konfigurasi aplikasi serverless untuk menyalurkan dari alamat IP IPv4 khusus yang tidak digunakan bersama dengan layanan lain.
Memetakan satu URL ke beberapa fungsi atau layanan serverless yang disajikan di domain yang sama. Dalam dokumen ini, lihat Masker URL.
Bagikan ruang URL dengan platform komputasi Google Cloud lainnya. Dengan menggunakan beberapa layanan backend, satu load balancer dapat mengirim traffic ke beberapa jenis backend. Load balancer memilih layanan backend yang benar berdasarkan host atau jalur URL permintaan.
Gunakan kembali sertifikat SSL dan kunci pribadi yang sama dengan yang Anda gunakan untuk Compute Engine, Google Kubernetes Engine, dan Cloud Storage. Dengan menggunakan kembali sertifikat yang sama, Anda tidak perlu mengelola sertifikat terpisah untuk aplikasi serverless.

Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik

Menyiapkan Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik memungkinkan aplikasi serverless Anda berintegrasi dengan layanan cloud yang ada. Anda dapat melakukan hal berikut:

Lindungi layanan Anda dengan Google Cloud Armor, produk keamanan WAF dan pertahanan DDoS di edge yang tersedia untuk semua layanan yang diakses melalui Load Balancer Aplikasi eksternal. Ada beberapa batasan yang terkait dengan kemampuan ini, terutama untuk Cloud Run dan App Engine.
Aktifkan layanan Anda untuk mengoptimalkan pengiriman menggunakan Cloud CDN. Cloud CDN meng-cache konten di lokasi yang dekat dengan pengguna Anda. Cloud CDN menyediakan kemampuan seperti invalidasi cache dan URL bertanda tangan Cloud CDN.
Menggunakan infrastruktur Edge Google untuk menghentikan koneksi HTTP(S) pengguna lebih dekat ke pengguna, sehingga mengurangi latensi.

Untuk mempelajari cara mengonfigurasi load balancer dengan backend komputasi serverless, lihat dokumentasi berikut:

Mengintegrasikan Load Balancer Aplikasi eksternal dengan Gateway API memungkinkan backend serverless Anda memanfaatkan semua fitur yang disediakan oleh Cloud Load Balancing. Untuk mengetahui informasi selengkapnya, lihat Load Balancer Aplikasi Eksternal untuk Gateway API. Untuk mengonfigurasi Load Balancer Aplikasi eksternal guna merutekan traffic ke Gateway API, lihat Mulai menggunakan Load Balancer Aplikasi eksternal untuk Gateway API. Kemampuan ini berada dalam Pratinjau.

Load Balancer Aplikasi eksternal regional

Dengan menggunakan Load Balancer Aplikasi eksternal regional, Anda dapat menjalankan workload dengan persyaratan peraturan atau kepatuhan di backend Cloud Run atau Cloud Run Functions (generasi ke-2). Misalnya, jika Anda mengharuskan konfigurasi jaringan dan penghentian traffic aplikasi berada di region tertentu, Load Balancer Aplikasi eksternal regional sering kali menjadi opsi yang lebih disukai untuk mematuhi kontrol wilayah hukum yang diperlukan.

Untuk mempelajari cara mengonfigurasi Load Balancer Aplikasi eksternal regional dengan backend komputasi serverless, lihat Menyiapkan Load Balancer Aplikasi eksternal regional dengan Cloud Run.

Load Balancer Aplikasi internal regional dan Load Balancer Aplikasi internal lintas region

Jika Load Balancer Aplikasi internal dikonfigurasi dengan backend Cloud Run atau Cloud Run Functions (generasi ke-2), Anda dapat melakukan hal berikut:

Aktifkan fitur pengelolaan traffic lanjutan seperti injeksi kesalahan, penulisan ulang header, pengalihan, pemisahan traffic, dan lainnya, untuk layanan Cloud Run dan Cloud Run Functions (generasi ke-2).
Migrasikan layanan lama dengan lancar dari Compute Engine, GKE, atau infrastruktur lokal, ke Cloud Run dan Cloud Run Functions (generasi ke-2) untuk memanfaatkan pemisahan traffic berbasis bobot guna mengalihkan traffic secara bertahap ke Cloud Run tanpa downtime.
Lindungi layanan Cloud Run dan Cloud Run Functions (generasi ke-2) dengan Kontrol Layanan VPC.
Buat satu titik ingress internal yang menerapkan kebijakan untuk layanan Anda yang berjalan di Cloud Run, Cloud Run Functions (generasi ke-2), Compute Engine, dan GKE.

Untuk mempelajari cara mengonfigurasi Load Balancer Aplikasi internal regional dengan backend komputasi serverless, lihat Menyiapkan Load Balancer Aplikasi internal regional dengan Cloud Run.

Bagian lain di halaman ini membahas cara menggunakan NEG serverless dengan Load Balancer Aplikasi Anda. Untuk mengetahui informasi selengkapnya tentang jenis NEG lainnya, lihat Ringkasan grup endpoint jaringan.

Jenis endpoint

NEG serverless tidak memiliki endpoint jaringan seperti port atau alamat IP. NEG serverless hanya dapat mengarah ke resource Cloud Run, App Engine, Gateway API, atau Cloud Run Functions yang ada di region yang sama dengan NEG.

Saat membuat NEG serverless, Anda menentukan nama domain yang sepenuhnya memenuhi syarat (FQDN) dari resource Cloud Run, App Engine, Gateway API, atau Cloud Run Functions. Endpoint berjenis SERVERLESS. Jenis endpoint lainnya tidak didukung di NEG serverless.

NEG serverless tidak boleh memiliki lebih dari satu endpoint. Endpoint mengarah ke aplikasi serverless atau masker URL. Load balancer berfungsi sebagai frontend untuk aplikasi komputasi serverless dan memproksi traffic ke endpoint yang ditentukan. Namun, jika layanan backend berisi beberapa NEG serverless di region yang berbeda, load balancer akan mengirimkan traffic ke NEG di region terdekat untuk meminimalkan latensi permintaan.

Tingkat jaringan

Untuk Load Balancer Aplikasi eksternal global, Anda dapat menggunakan NEG serverless di load balancer menggunakan Network Service Tiers Standar atau Premium. Paket Premium hanya diperlukan jika Anda ingin menyiapkan NEG serverless di beberapa region.

Load Balancer Aplikasi eksternal regional selalu menggunakan Paket Standar.

Load Balancer Aplikasi internal lintas region dan Load Balancer Aplikasi internal regional selalu menggunakan tingkat Premium.

Komponen load balancing

Load balancer yang menggunakan backend NEG serverless memerlukan konfigurasi khusus hanya untuk layanan backend. Konfigurasi frontend sama dengan load balancer Google Cloud berbasis proxy lainnya. Selain itu, Load Balancer Aplikasi internal memerlukan subnet khusus proxy untuk menjalankan proxy Envoy atas nama Anda.

Diagram berikut menunjukkan contoh deployment NEG serverless.

Eksternal global

Diagram ini menunjukkan cara NEG serverless cocok dengan arsitektur Load Balancer Aplikasi eksternal global.

Eksternal regional

Diagram ini menunjukkan cara NEG serverless cocok dengan arsitektur Load Balancer Aplikasi eksternal regional.

Internal Regional

Diagram ini menunjukkan cara NEG tanpa server sesuai dengan model Load Balancer Aplikasi internal regional.

Lintas region

Diagram ini menunjukkan cara NEG serverless cocok dengan model Load Balancer Aplikasi internal lintas region.

Komponen frontend

Tidak diperlukan konfigurasi frontend khusus untuk load balancing dengan backend NEG serverless. Aturan penerusan digunakan untuk merutekan traffic berdasarkan alamat IP, port, dan protokol ke proxy target. Kemudian, proxy target akan menghentikan koneksi dari klien.

Peta URL digunakan oleh Load Balancer Aplikasi untuk menyiapkan perutean permintaan berbasis URL ke layanan backend yang sesuai.

Untuk mengetahui detail selengkapnya tentang setiap komponen ini, lihat bagian arsitektur dalam ringkasan load balancer tertentu:

Layanan backend

Layanan backend memberikan informasi konfigurasi ke load balancer. Load balancer menggunakan informasi dalam layanan backend untuk mengarahkan traffic masuk ke satu atau beberapa backend yang terpasang. NEG serverless dapat digunakan sebagai backend untuk load balancer tertentu.

Batasan berikut berlaku bergantung pada jenis load balancer:

Layanan backend global yang digunakan oleh Load Balancer Aplikasi eksternal global dapat memiliki beberapa NEG serverless yang terpasang, tetapi hanya satu NEG serverless per region.
Layanan backend regional yang digunakan oleh Load Balancer Aplikasi internal regional dan Load Balancer Aplikasi eksternal regional hanya dapat memiliki satu NEG serverless yang terpasang.
Layanan backend global yang digunakan oleh Load Balancer Aplikasi internal lintas region hanya dapat memiliki resource Cloud Run dan Cloud Run Functions (generasi ke-2) yang terpasang padanya.

Setiap NEG serverless dapat mengarah ke salah satu dari berikut ini:

FQDN untuk satu resource
Masker URL yang mengarah ke beberapa resource yang ditayangkan di domain yang sama

Masker URL adalah template skema URL yang memberi tahu backend NEG serverless cara memetakan permintaan pengguna ke layanan yang benar. Masker URL berguna jika Anda menggunakan domain kustom untuk aplikasi serverless dan memiliki beberapa layanan yang ditayangkan di domain yang sama. Alih-alih membuat NEG serverless terpisah untuk setiap resource, Anda dapat membuat NEG dengan mask URL generik untuk domain kustom. Untuk mengetahui informasi dan contoh selengkapnya, lihat Masker URL.

Untuk batasan tambahan saat menambahkan NEG serverless sebagai backend, lihat Batasan.

Deteksi pencilan untuk NEG serverless

Deteksi pencilan adalah konfigurasi opsional yang dapat diaktifkan di layanan backend global yang memiliki NEG serverless yang terpasang. Analisis deteksi pencilan hanya tersedia untuk Load Balancer Aplikasi internal lintas-region, Load Balancer Aplikasi eksternal global, dan bukan untuk Load Balancer Aplikasi klasik. Analisis deteksi outlier mengidentifikasi NEG serverless yang tidak responsif berdasarkan pola respons HTTP-nya, dan mengurangi tingkat error dengan merutekan sebagian besar permintaan baru dari resource yang tidak responsif ke resource yang responsif. Untuk mempelajari cara kerja algoritma deteksi pencilan dan memahami batasannya, lihat contoh berikut.

Asumsikan ada layanan backend dengan dua NEG serverless yang terpasang padanya—satu di region REGION_A dan satu lagi di region REGION_B. Jika NEG serverless yang berfungsi sebagai backend untuk Load Balancer Aplikasi eksternal global di region REGION_A tidak responsif, deteksi pencilan akan mengidentifikasi NEG serverless sebagai tidak responsif. Berdasarkan analisis deteksi pencilan, beberapa permintaan baru kemudian dikirim ke NEG serverless di region REGION_B.

Berdasarkan jenis error server yang terjadi, Anda dapat menggunakan salah satu metode deteksi pencilan berikut untuk mengaktifkan deteksi pencilan:

Error 5xx berturut-turut. Kode status HTTP seri 5xx memenuhi syarat sebagai error.
Error gateway berturut-turut. Hanya kode status HTTP 502, 503, dan 504 yang memenuhi syarat sebagai error.

Perhatikan bahwa meskipun setelah mengaktifkan deteksi pencilan, Anda mungkin akan melihat beberapa permintaan dikirim ke resource yang tidak sehat dan dengan demikian menampilkan error 5XX kepada klien. Hal ini karena hasil algoritma deteksi pencilan (pengeluaran endpoint dari kumpulan load balancing dan pengembaliannya ke kumpulan) dijalankan secara independen oleh setiap instance proxy load balancer. Pada umumnya, lebih dari satu instance proxy menangani traffic yang diterima oleh layanan backend. Oleh karena itu, ada kemungkinan bahwa endpoint yang tidak responsif terdeteksi dan dikeluarkan hanya oleh beberapa proxy, dan saat hal ini terjadi, proxy lain dapat terus mengirim permintaan ke endpoint yang sama yang tidak responsif.

Untuk mengurangi rasio error lebih lanjut, Anda dapat mengonfigurasi parameter deteksi pencilan yang lebih agresif. Sebaiknya konfigurasikan nilai yang lebih tinggi untuk nilai minimum pengeluaran (outlierDetection.baseEjectionTime). Misalnya, pengujian kami menunjukkan bahwa menetapkan outlierDetection.baseEjectionTime ke 180 detik dengan QPS berkelanjutan yang lebih tinggi dari 100 menghasilkan tingkat error yang diamati kurang dari 5%. Untuk mempelajari lebih lanjut API deteksi pencilan, lihat outlierDetection dalam dokumentasi API layanan backend global.

Kolom outlierDetection berikut tidak didukung saat layanan backend memiliki NEG serverless yang terpasang:

outlierDetection.enforcingSuccessRate
outlierDetection.successRateMinimumHosts
outlierDetection.successRateRequestVolume
outlierDetection.successRateStdevFactor

Untuk mempelajari cara mengonfigurasi deteksi pencilan, lihat Menyiapkan Load Balancer Aplikasi eksternal global dengan backend serverless: Mengaktifkan deteksi pencilan.

Masker URL

Backend NEG serverless dapat mengarah ke satu resource Cloud Run (atau App Engine atau Cloud Run Functions jika berlaku), atau masker URL yang mengarah ke beberapa resource. Masker URL adalah template skema URL Anda. NEG serverless menggunakan template ini untuk memetakan permintaan ke resource yang sesuai.

Masker URL adalah fitur opsional yang mempermudah konfigurasi NEG serverless saat aplikasi serverless Anda terdiri dari beberapa resource Cloud Run, Cloud Run Functions, atau App Engine. NEG serverless yang digunakan dengan Load Balancer Aplikasi internal hanya dapat menggunakan mask URL yang mengarah ke layanan Cloud Run atau Cloud Run Functions (generasi ke-2).

Masker URL berguna jika aplikasi serverless Anda dipetakan ke domain kustom, bukan alamat default yang disediakan Google Cloud . Dengan domain kustom seperti example.com, Anda dapat memiliki beberapa resource yang di-deploy ke subdomain atau jalur yang berbeda di domain yang sama. Dalam kasus seperti ini, daripada membuat backend NEG serverless terpisah untuk setiap resource, Anda dapat membuat satu NEG serverless dengan mask URL generik untuk domain kustom (misalnya, example.com/<service>). NEG mengekstrak nama layanan dari URL permintaan.

Ilustrasi berikut menunjukkan Load Balancer Aplikasi eksternal dengan satu layanan backend dan NEG serverless yang menggunakan mask URL untuk memetakan permintaan pengguna ke layanan yang berbeda.

Mendistribusikan traffic ke aplikasi serverless. — Menggunakan masker URL untuk mendistribusikan traffic ke berbagai layanan (klik untuk memperbesar).

Masker URL berfungsi paling baik jika resource aplikasi Anda menggunakan skema URL yang dapat diprediksi. Keuntungan menggunakan mask URL, bukan peta URL, adalah Anda tidak perlu membuat NEG serverless terpisah untuk layanan login dan search. Anda juga tidak perlu mengubah konfigurasi load balancer setiap kali menambahkan resource baru ke aplikasi.

Batasan

NEG tanpa server tidak dapat memiliki endpoint jaringan seperti alamat IP atau port.
NEG serverless hanya dapat mengarah ke resource serverless yang berada di region yang sama dengan tempat NEG dibuat.
Untuk load balancer yang menggunakan backend NEG Serverless, NEG serverless harus dibuat di project yang sama dengan resource Cloud Run, App Engine, Gateway API, atau Cloud Run Functions yang ditunjuk oleh NEG. Anda mungkin melihat permintaan gagal jika menghubungkan layanan yang tidak berada dalam project yang sama dengan NEG serverless.
Kecuali jika Anda telah mengonfigurasi Service Health Cloud Run atau mengaktifkan deteksi anomali, load balancer yang dikonfigurasi dengan NEG serverless tidak dapat mendeteksi apakah resource yang mendasarinya berfungsi seperti yang diharapkan. Artinya, meskipun resource Anda menampilkan error, load balancer akan terus mengarahkan traffic ke resource tersebut. Pastikan untuk menguji versi baru aset Anda secara menyeluruh sebelum merutekan traffic pengguna ke versi tersebut.

Untuk mengotomatiskan failover traffic dari NEG serverless yang tidak responsif, Anda dapat menggunakan metode berikut pada load balancer global dan lintas region:
- Deteksi pencilan: Didukung di Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi internal lintas region untuk mengidentifikasi NEG serverless yang tidak responsif berdasarkan pola respons HTTP.
- Service Health Cloud Run: Didukung di Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi internal lintas region yang dikonfigurasi dengan backend NEG serverless.
Google Cloud console. Anda hanya dapat membuat NEG serverless saat membuat atau mengedit load balancer menggunakan halaman Load balancing di Google Cloud konsol. Meskipun Anda tidak dapat membuat atau mengedit NEG serverless di halaman Grup endpoint jaringan, Anda dapat menggunakan halaman ini untuk melihat daftar semua NEG serverless di project Anda.

Batasan pada layanan backend

Batasan berikut berlaku untuk layanan backend yang memiliki backend NEG serverless:

Layanan backend global yang digunakan oleh Load Balancer Aplikasi eksternal global hanya dapat memiliki satu NEG serverless per region. Untuk menggabungkan beberapa NEG serverless dalam satu layanan backend, semua NEG harus merepresentasikan deployment yang setara secara fungsional di region yang berbeda. Misalnya, NEG dapat mengarah ke resource Cloud Run, App Engine, atau Cloud Run Functions yang sama yang di-deploy di berbagai region.
Layanan backend global yang digunakan oleh Load Balancer Aplikasi internal lintas region hanya dapat memiliki satu resource Cloud Run atau Cloud Run Functions (generasi ke-2) yang terpasang.
Layanan backend regional hanya dapat memiliki satu NEG serverless yang terpasang padanya.
Referensi layanan lintas project dalam deployment VPC Bersama didukung dengan konfigurasi yang berisi NEG serverless. Untuk menggunakan fitur ini, Anda membuat komponen frontend load balancer (alamat IP, aturan penerusan, proxy target, dan peta URL) dalam project yang berbeda dengan komponen backend load balancer (layanan backend dan NEG tanpa server). Perhatikan bahwa layanan backend, NEG serverless terkait, dan resource serverless pendukung (Cloud Run, App Engine, Gateway API, atau fungsi Cloud Run), harus selalu dibuat dalam project yang sama.
Setelan waktu tunggu layanan backend tidak berlaku untuk layanan backend dengan backend NEG serverless. Mencoba mengubah properti resource.timeoutSec layanan backend akan menghasilkan error berikut: Timeout sec is not supported for a backend service with Serverless network endpoint groups.
Untuk layanan backend dengan backend NEG serverless, waktu tunggu defaultnya adalah 60 menit. Waktu tunggu ini tidak dapat dikonfigurasi. Jika aplikasi Anda memerlukan koneksi yang berjalan lama, konfigurasikan klien Anda untuk mencoba ulang permintaan jika gagal.
Semua NEG serverless yang digabungkan dalam layanan backend juga harus menggunakan jenis backend yang sama. Artinya, NEG serverless Cloud Run hanya dapat digabungkan dengan NEG serverless Cloud Run lainnya, dan NEG serverless App Engine hanya dapat digabungkan dengan NEG serverless App Engine.
Anda tidak dapat mencampur NEG serverless dengan jenis NEG lainnya dalam layanan backend yang sama. Misalnya, Anda tidak dapat merutekan ke cluster GKE dan layanan Cloud Run dari layanan backend yang sama.
Saat menyiapkan layanan backend yang merutekan ke NEG serverless, kolom tertentu dibatasi:
- Anda tidak dapat menentukan mode balancing. Artinya, nilai RATE,UTILIZATION, dan CONNECTION tidak memengaruhi distribusi traffic load balancer.
- Health check tidak didukung untuk backend serverless. Oleh karena itu, layanan backend yang berisi backend NEG serverless tidak dapat dikonfigurasi dengan health check. Namun, Anda dapat mengaktifkan deteksi anomali secara opsional untuk mengidentifikasi resource serverless yang tidak responsif dan merutekan permintaan baru ke resource serverless yang responsif.
Anda tidak dapat menggunakan perintah gcloud compute backend-services edit untuk mengubah layanan backend dengan backend NEG serverless. Sebagai solusinya, gunakan perintah gcloud compute backend-services update.

Batasan tambahan berlaku bergantung pada jenis load balancer dan backend serverless.

Batasan pada Load Balancer Aplikasi internal regional dan Load Balancer Aplikasi eksternal regional

NEG serverless yang digunakan dengan Load Balancer Aplikasi internal regional atau Load Balancer Aplikasi eksternal regional hanya dapat mengarah ke resource Cloud Run atau Cloud Run Functions (generasi ke-2).
Untuk project yang menggunakan NEG serverless, batas kueri per detik (QPS) adalah 5.000 QPS per project untuk traffic yang dikirim ke NEG serverless yang dikonfigurasi dengan Load Balancer Aplikasi eksternal regional atau Load Balancer Aplikasi internal regional. Batas ini digabungkan di semua Load Balancer Aplikasi eksternal regional dan Load Balancer Aplikasi internal regional dalam project. Ini bukan batas per load balancer.

Batasan pada Load Balancer Aplikasi internal lintas region

NEG serverless yang digunakan dengan Load Balancer Aplikasi internal lintas region hanya dapat mengarah ke resource Cloud Run atau Cloud Run Functions (generasi ke-2).

Batasan dengan Load Balancer Aplikasi eksternal global

Bagian ini mencantumkan batasan yang akan Anda temui saat mengonfigurasi NEG serverless dengan Load Balancer Aplikasi eksternal global.

Batasan dengan Cloud Run

Load Balancer Aplikasi eksternal dengan NEG serverless tidak mendukung penayangan Knative.
Load Balancer Aplikasi eksternal tidak mendukung autentikasi permintaan pengguna akhir ke resource Cloud Run. Namun, Anda dapat menggunakan IAP untuk mengautentikasi pengguna dalam organisasi Anda. Jika ingin mengaktifkan IAP, Anda harus ingat bahwa IAP dan Cloud CDN tidak kompatibel satu sama lain. Keduanya tidak dapat diaktifkan di layanan backend yang sama.

Batasan App Engine

Load balancing multi-region tidak didukung dengan App Engine. Hal ini karena App Engine memerlukan 1 region per project.
Jika menggunakan IAP, Anda harus menggunakan client ID OAuth yang sama untuk semua layanan App Engine yang terkait dengan satu load balancer.
Hanya satu kebijakan IAP yang diizinkan di jalur permintaan. Misalnya, jika Anda telah menetapkan kebijakan IAP di layanan backend, Anda tidak boleh menetapkan kebijakan IAP lain di aplikasi App Engine.
Load Balancer Aplikasi eksternal global dengan backend lingkungan fleksibel App Engine dan backend lingkungan standar App Engine tidak mendukung referensi layanan lintas project.

Sebaiknya gunakan kontrol masuk sehingga aplikasi Anda hanya menerima permintaan yang dikirim dari load balancer (dan VPC jika Anda menggunakannya). Jika tidak, pengguna dapat menggunakan URL App Engine aplikasi Anda untuk mengabaikan load balancer, kebijakan keamanan Cloud Armor, sertifikat SSL, dan kunci pribadi yang diteruskan melalui load balancer.

Batasan Gateway API

Untuk mengetahui informasi selengkapnya, lihat Batasan pada NEG serverless dan Gateway API.

Batasan fitur pengelolaan traffic

Fitur pengelolaan traffic lanjutan seperti kebijakan lokalitas load balancing dan afinitas sesi tidak didukung dengan backend NEG serverless.
Menentukan afinitas sesi pada layanan backend dengan backend NEG serverless tidak akan berfungsi. Sebagai solusi untuk Cloud Run, gunakan fitur afinitas sesi khususnya.

Harga

Untuk mengetahui informasi harga, lihat Harga jaringan: Cloud Load Balancing.