Python 2.7은 지원이 종료되었으며 2026년 1월 31일에 지원 중단됩니다. 지원 중단 후에는 조직에서 이전에 조직 정책을 사용하여 레거시 런타임의 배포를 다시 사용 설정한 경우에도 Python 2.7 애플리케이션을 배포할 수 없습니다. 기존 Python 2.7 애플리케이션은 지원 중단 날짜 이후에도 계속 실행되고 트래픽을 수신합니다. 지원되는 최신 Python 버전으로 마이그레이션하는 것이 좋습니다.
Compute Engine 가상 머신(VM) 및 Cloud Tasks와 같은 내부 소스에서 발생한 트래픽
앱이 다른 네트워킹 서비스 또는 제품을 사용하도록 구성된 경우 App Engine 방화벽과 다른 제품의 방화벽 또는 보안 설정에서 수신되는 트래픽을 제어할 규칙을 만들어야 할 수 있습니다. 이 가이드에서는 App Engine 방화벽의 일반적인 동작과 특수한 사용 사례에 대해 자세히 설명합니다.
App Engine 방화벽 규칙
Google Cloud 콘솔, Google Cloud CLI 또는 Admin API로 지정된 IP 범위를 허용하거나 차단하는 규칙을 설정하여 App Engine 방화벽 규칙을 구성할 수 있습니다.
기본적으로는 규칙과 일치하지 않는 모든 요청이 앱에 액세스할 수 있습니다. 특정 규칙과 일치하지 않는 요청을 모두 차단해야 하는 경우(기본적으로 허용되는 내부 서비스의 요청은 제외) default 규칙의 작업을 deny로 변경합니다.
방화벽 기능
App Engine 표준 환경에서 App Engine 방화벽은 특정 내부 트래픽이 방화벽을 우회하도록 허용할 수 있습니다. 즉, default 규칙을 deny로 설정하면 App Engine 표준 환경을 대상으로 하는 특정 서비스의 요청이 차단되지 않습니다. 이는 앱 자체 구성에서 요청되거나 동일한 앱에서 전송되는 모든 유형의 트래픽입니다. 이러한 방식으로 방화벽 규칙을 우회하는 요청은 다음과 같습니다.
사용 사례에 따라 App Engine 방화벽 규칙을 구성할 때 다음과 같은 추가 안내가 적용될 수 있습니다.
App Engine 표준 또는 가변형 환경으로 전송되는 새로 생성되거나 업데이트된 App Engine 크론 작업의 요청은 0.1.0.2에서 가져옵니다. 이전 gcloud 버전(326.0.0 이전)에서 생성된 크론 작업의 경우 0.1.0.1에서 크론 요청이 발생합니다. App Engine Cron Service의 요청을 식별하는 방법에 대한 자세한 내용은 크론 요청 유효성 검사를 참조하세요.
앱이 Cloud Load Balancing과 상호작용하거나 VPC 네트워크에 연결되어 있는 경우, 아래의 다른 제품 또는 서비스와 상호작용 섹션을 참조하세요.
App Engine 표준 예시
표준 환경에서 실행되는 앱에는 frontend_service 및 backend_service의 두 가지 서비스가 있습니다. frontend_service는 Cloud Tasks를 App Engine HTTP와 함께 사용하여 backend_service에 메시지를 보냅니다. default 방화벽 규칙은 deny로 구성된 경우에도 Cloud Tasks 요청을 허용하므로 Cloud Tasks에 대한 방화벽 규칙을 만들 필요가 없습니다.
하지만 앱에 대한 액세스를 제한하고 Cloud Tasks 요청을 명시적으로 차단하려면 IP 범위 0.1.0.2/32에 대한 deny 방화벽 규칙을 만드세요.
App Engine 가변형 예시
가변형 환경에서 실행되는 앱에는 frontend_service 및 backend_service의 두 가지 서비스가 있으며 기본적으로 트래픽을 거부하도록 구성된 방화벽이 있습니다. frontend_service는 Cloud Tasks를 App Engine HTTP와 함께 사용하여 backend_service에 메시지를 보냅니다. default 방화벽 규칙은 Cloud Tasks 요청을 거부하므로 0.1.0.2/32에 대한 allow 방화벽 규칙을 만들어야 합니다.
부하 분산기는 App Engine 방화벽 규칙을 간섭하거나 상호작용하지 않습니다. App Engine 규칙은 서버리스 NEG가 트래픽을 App Engine으로 전송할 때까지 평가되지 않습니다.
앱이 부하 분산기(및 사용하는 경우 VPC)에서 전송되는 요청만 수신하도록 인그레스 제어를 사용하는 것이 좋습니다. 그렇지 않으면 사용자가 앱의 App Engine URL을 사용하여 부하 분산기를 통해 전달되는 부하 분산기, Cloud Armor 보안 정책, SSL 인증서, 비공개 키를 우회할 수 있습니다.
[[["이해하기 쉬움","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)"],[[["\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."]]
