Python 2.7 telah mencapai akhir dukungan
dan akan dihentikan penggunaannya
pada 31 Januari 2026. Setelah penghentian penggunaan, Anda tidak akan dapat men-deploy aplikasi Python 2.7, meskipun organisasi Anda sebelumnya menggunakan kebijakan organisasi untuk mengaktifkan kembali deployment runtime lama. Aplikasi Python 2.7 yang ada akan terus berjalan dan menerima traffic setelah
tanggal penghentiannya. Sebaiknya Anda bermigrasi ke versi Python terbaru yang didukung.
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Firewall menentukan traffic jaringan mana yang boleh diteruskan dan mana yang ditolak. Firewall dapat menerapkan traffic masuk (ingress), traffic keluar (egress), atau keduanya. Untuk App Engine, firewall App Engine hanya berlaku untuk traffic masuk yang dirutekan ke aplikasi atau layanan Anda.
Ringkasan
Firewall App Engine diperiksa untuk semua jenis permintaan ke aplikasi Anda, termasuk:
Traffic web reguler yang dirutekan ke alamat appspot.com atau domain kustom aplikasi.
Traffic dari sumber internal seperti virtual machine (VM) Compute Engine dan Cloud Tasks.
Jika aplikasi Anda dikonfigurasi untuk menggunakan produk atau layanan jaringan lainnya, Anda mungkin perlu membuat aturan untuk mengontrol traffic masuk di firewall App Engine dan setelan firewall atau keamanan produk lainnya. Panduan ini membahas perilaku umum firewall App Engine, dan detail tentang kasus penggunaan khusus tersebut.
Aturan firewall App Engine
Anda dapat mengonfigurasi aturan firewall App Engine menggunakan konsol Google Cloud , Google Cloud CLI, atau Admin API dengan menentukan aturan yang mengizinkan atau memblokir rentang IP tertentu.
Secara default, setiap permintaan yang tidak cocok dengan aturan diizinkan mengakses aplikasi Anda. Jika Anda perlu memblokir semua permintaan yang tidak cocok dengan aturan tertentu (tidak termasuk permintaan dari layanan internal yang diizinkan secara default), ubah tindakan aturan default menjadi deny.
Fitur firewall
Di lingkungan standar App Engine, firewall App Engine dapat mengizinkan traffic internal tertentu untuk mengabaikan firewall. Artinya, jika Anda menetapkan aturan default ke deny, permintaan dari layanan tertentu yang ditujukan untuk lingkungan standar App Engine tidak akan diblokir. Ini adalah semua jenis traffic yang diminta dalam konfigurasi aplikasi itu sendiri, atau dikirim dari aplikasi yang sama. Permintaan yang mengabaikan aturan firewall dengan cara ini mencakup:
Untuk aplikasi yang menggunakan lingkungan dan layanan standar App Engine yang dipaketkan dengan runtime generasi pertama, notifikasi dari Mail API lama juga mengabaikan firewall.
Mengizinkan permintaan masuk dari layanan Anda
Tabel berikut mencantumkan daftar rentang IP dan perilaku firewall App Engine untuk layanan umum. Rentang IP yang Anda gunakan bergantung pada dikirim tidaknya permintaan masuk ke versi yang berjalan di lingkungan standar atau lingkungan fleksibel App Engine.
Layanan
Rentang IP untuk permintaan yang dikirim ke lingkungan standar App Engine
Rentang IP untuk permintaan yang dikirim ke lingkungan fleksibel App Engine
Cloud Storage atau Blobstore
0.1.0.30/32
Tidak berlaku
Tugas Cloud Scheduler yang menggunakan tugas HTTP App Engine dan App Engine di Cloud Tasks (termasuk Task Queue App Engine)
0.1.0.2/32, mengabaikan aturan default firewall jika diatur untuk menolak
0.1.0.2/32
Cron App Engine
0.1.0.1/32 atau 0.1.0.2/32, mengabaikan aturan firewall default jika diatur untuk menolak
Bergantung pada kasus penggunaan Anda, petunjuk tambahan berikut mungkin berlaku saat mengonfigurasi aturan firewall App Engine:
Permintaan dari Cron job App Engine yang baru dibuat atau diperbarui yang dikirim ke lingkungan fleksibel atau standar App Engine berasal dari 0.1.0.2. Untuk Cron job yang dibuat dengan versi gcloud sebelumnya (sebelum versi 326.0.0), permintaan Cron akan berasal dari 0.1.0.1. Untuk mempelajari lebih lanjut cara mengidentifikasi permintaan dari layanan Cron App Engine, lihat Memvalidasi permintaan cron.
Aplikasi Anda yang berjalan di lingkungan standar memiliki dua layanan: frontend_service dan backend_service. frontend_service menggunakan Cloud Tasks dengan HTTP App Engine untuk mengirim pesan ke backend_service. Karena aturan firewall default mengizinkan permintaan Cloud Tasks meskipun dikonfigurasi ke deny, Anda tidak perlu membuat aturan firewall untuk Cloud Tasks.
Namun, jika ingin membatasi akses ke aplikasi Anda dan memblokir permintaan Cloud Tasks secara eksplisit, Anda perlu membuat aturan firewall deny untuk rentang IP 0.1.0.2/32.
Contoh fleksibel App Engine
Aplikasi Anda yang berjalan di lingkungan fleksibel memiliki dua layanan: frontend_service dan backend_service, serta mengonfigurasi firewall untuk menolak traffic secara default. frontend_service menggunakan Cloud Tasks dengan HTTP App Engine untuk mengirim pesan ke backend_service. Karena aturan firewall default menolak permintaan Cloud Tasks, Anda harus membuat aturan firewall allow untuk 0.1.0.2/32.
Load balancer tidak mengganggu atau berinteraksi dengan aturan firewall App Engine. Aturan firewall App Engine tidak dievaluasi hingga NEG serverless mengarahkan traffic ke App Engine.
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.
Firewall App Engine berada di belakang mekanisme yang meng-cache konten, misalnya proxy web dan browser. Ketika di-cache, konten tersebut akan ditayangkan secara publik dari URL tertentu hingga masa berlakunya habis dan dapat diakses bahkan setelah membuat aturan firewall baru.
Untuk mengetahui informasi tentang cara mengubah waktu habis masa berlaku default untuk konten statis atau mencegah konten statis di-cache, lihat Masa berlaku cache.
Untuk mencegah output konten dinamis dari kode aplikasi Anda di-cache, gunakan header respons HTTP Cache-Control dan Expires. Untuk mengetahui informasi selengkapnya tentang header HTTP ini, termasuk cara mengontrol cache, lihat Menghindari cache.
Langkah berikutnya
Ikuti petunjuknya di bagian Membuat Firewall untuk mempelajari cara mengonfigurasi aturan firewall App Engine.
[[["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-04 UTC."],[[["\u003cp\u003eThe App Engine firewall controls incoming traffic to your app, allowing or blocking requests based on specified IP ranges.\u003c/p\u003e\n"],["\u003cp\u003eBy default, requests not matching any defined rule are allowed, but this can be changed to deny access unless specifically allowed.\u003c/p\u003e\n"],["\u003cp\u003eCertain internal traffic, like warmup requests and Cloud Tasks, can bypass the firewall rules even when the default action is set to deny in the App Engine standard environment.\u003c/p\u003e\n"],["\u003cp\u003eWhen using Cloud Load Balancing, the App Engine firewall does not interact with the load balancer, and it is recommended to use ingress controls to ensure that requests only come through the load balancer.\u003c/p\u003e\n"],["\u003cp\u003eCached content may still be accessible publicly, even after new firewall rules are put in place, so control the cache behavior of static and dynamic content using Cache-Control and Expires headers.\u003c/p\u003e\n"]]],[],null,["# Understanding the App Engine firewall\n\nA **firewall** determines which network traffic is allowed to pass and which\ntraffic is rejected. Firewalls can apply to incoming traffic (ingress), outgoing\ntraffic (egress), or both. For App Engine, the App Engine firewall only\napplies to incoming traffic routed to your app or service.\n\nOverview\n--------\n\nThe App Engine firewall is checked for all types of\nrequests to your app, including:\n\n- Regular web traffic routed to the app's `appspot.com` address or custom domain.\n- Requests that arrive from [Cloud Load Balancing](/load-balancing).\n- Traffic from internal sources such as Compute Engine virtual machines (VMs) and Cloud Tasks.\n\nIn cases where your app is configured to use other networking services or\nproducts, you might need to create rules for controlling incoming traffic in\nboth the App Engine firewall and the firewall or security settings of other\nproducts. This guide covers the general behavior of the App Engine firewall,\nand details about those special use cases.\n\nApp Engine firewall rules\n-------------------------\n\nYou can [configure App Engine firewall rules](/appengine/docs/legacy/standard/python/creating-firewalls)\nusing the Google Cloud console, the Google Cloud CLI, or the Admin\nAPI by specifying rules that allow or block specified IP ranges.\n\nBy default, any request that does not match a rule is allowed access to your\napp. If you need to block all requests that do not match a specific rule\n(excluding requests from internal services allowed by default), change the\n`default` rule's action to `deny`.\n\n### Firewall feature\n\nIn the App Engine standard environment, the App Engine firewall can allow certain internal\ntraffic to bypass the firewall. This means that if you set the `default` rule to\n`deny`, requests from certain services destined for the App Engine standard environment do not\nget blocked. These are all types of traffic requested in the app's own\nconfiguration, or sent from the same app. Requests that bypass firewall rules in\nthis way include:\n\n- [Warmup requests](/appengine/docs/legacy/standard/python/configuring-warmup-requests)\n- Cloud Scheduler jobs using [App Engine HTTP](/scheduler/docs/creating#creating_jobs) (including [App Engine Cron](/appengine/docs/legacy/standard/python/config/cron)\n\n \u003cbr /\u003e\n\n - [App Engine tasks in Cloud Tasks](/tasks/docs/creating-appengine-tasks) (including App Engine Task Queues)\n\n For apps that use the App Engine standard environment and services bundled with the [first\n generation runtimes](/appengine/docs/standard/runtimes), notifications from the\n legacy Mail API also bypass the firewall.\n\n Allowing incoming requests from your services\n ---------------------------------------------\n\n The following table lists the IP ranges and App Engine firewall behavior for\n common services. The IP range you use depends on whether the incoming requests\n are delivered to a version that runs on the App Engine standard environment or\n flexible environment.\n\n Depending on your use case, these additional instructions might apply when\n configuring App Engine firewall rules:\n - Requests from newly created or updated App Engine Cron jobs sent to either the App Engine standard or flexible environment come from `0.1.0.2`. For Cron jobs created with older gcloud versions (earlier than 326.0.0), Cron requests will come from `0.1.0.1`. To learn more about how to identify requests from the App Engine Cron service, see [Validating cron requests](/appengine/docs/legacy/standard/python/scheduling-jobs-with-cron-yaml#validating_cron_requests).\n - If your app interacts with Cloud Load Balancing or is connected to a VPC network, see the [Interaction with other products or services](#interaction_with_other_products_or_services) section below.\n\n | **Caution:** Creating a rule for IP `0.0.0.0` will apply to **all** Compute Engine instances with Private Google Access enabled, not only the ones you own. Similarly, allowing requests from `0.1.0.40` will allow **any** App Engine app to make URL Fetch requests to your app.\n\n ### App Engine standard example\n\n Your app running in the standard environment has two services: `frontend_service`\n and `backend_service`. `frontend_service` uses Cloud Tasks with\n App Engine HTTP to send messages to `backend_service`. Since the `default`\n firewall rule allows Cloud Tasks requests even if configured to `deny`, you do not need to create\n a firewall rule for Cloud Tasks.\n\n However, if you wanted to restrict access to your app and explicitly block\n Cloud Tasks requests, you would create a `deny` firewall rule for IP range `0.1.0.2/32`.\n\n ### App Engine flexible example\n\n Your app running in the flexible environment has two services:\n `frontend_service` and `backend_service`, and has a firewall configured to deny\n traffic by default. `frontend_service` uses Cloud Tasks with\n App Engine HTTP to send messages to `backend_service`. Since the `default`\n firewall rule denies Cloud Tasks requests, you would need to create an\n `allow` firewall rule for `0.1.0.2/32`.\n\n Interaction with other products or services\n -------------------------------------------\n\n ### Cloud Load Balancing\n\n If you use [Cloud Load Balancing and serverless NEGs](/load-balancing/docs/negs/serverless-neg-concepts), note the following:\n - The load balancer does not interfere or interact with App Engine firewall rules. The App Engine firewall rules are not evaluated until a serverless NEG directs traffic to App Engine.\n\n \u003c!-- --\u003e\n\n - We recommend that you [use ingress controls](/appengine/docs/standard/application-security#ingress_controls)\n so that your app only receives requests sent from the load balancer\n (and the VPC if you use it). Otherwise, users can use your app's\n App Engine URL to bypass the load balancer, Cloud Armor\n security policies, SSL certificates, and private keys that are passed through\n the load balancer.\n\n - If your [ingress controls](/appengine/docs/legacy/standard/python/application-security#ingress_controls) are set to receive `internal-and-cloud-load-balancing` traffic, leave the default App Engine firewall rule as is (`allow`), and use [Google Cloud Armor web application firewall (WAF) rules](/armor/docs/rule-tuning).\n\n Preventing access to cached content\n -----------------------------------\n\n The App Engine firewall sits behind mechanisms that cache content, for example\n web proxies and browsers. When content is cached, that content is served\n publicly from the specific URL until it expires and can be accessed even after\n creating new firewall rules.\n For information about changing the default expiration time for static content or preventing static content from being cached, see [Cache expiration](/appengine/docs/legacy/standard/python/how-requests-are-handled#static_cache_expiration).\n\n \u003cbr /\u003e\n\n To prevent dynamic content output from your app's code from being cached, use\n the `Cache-Control` and `Expires` HTTP response headers. For more information about\n these HTTP headers, including how to control caching, see\n [Avoiding caching](https://wikipedia.org/wiki/List_of_HTTP_header_fields#Avoiding_caching).\n\n\n What's next\n -----------\n\n Follow the instructions in [Creating\n Firewalls](/appengine/docs/legacy/standard/python/creating-firewalls) to\n learn how to configure App Engine firewall rules."]]
