Region ID
The REGION_ID is an abbreviated code that Google assigns
based on the region you select when you create your app. The code does not
correspond to a country or province, even though some region IDs may appear
similar to commonly used country and province codes. Including
REGION_ID.r in App Engine URLs is optional for
existing apps and will soon be required for all new apps.
To ensure a smooth transition, we are slowly updating App Engine to use region IDs. If we haven't updated your Google Cloud project yet, you won't see a region ID for your app. Since the ID is optional for existing apps, you don't need to update URLs or make other changes once the region ID is available for your existing apps.
Learn more about region IDs.
An App Engine app is made up of a single application resource that consists of one or more services. Each service can be configured to use different runtimes and to operate with different performance settings. Within each service, you deploy versions of that service. Each version then runs within one or more instances, depending on how much traffic you configured it to handle.
Components of an application
Your App Engine app is created under your Google Cloud project when you create an application resource. The App Engine application is a top-level container that includes the service, version, and instance resources that make up your app. When you create your App Engine app, all your resources are created in the region that you choose, including your app code along with a collection of settings, credentials, and your app's metadata.
Each App Engine application includes at least one service, the default
service, which can hold many versions, depending on your app's billing status.
For more information, see Limits below.
The following diagram illustrates the hierarchy of an App Engine app running with multiple services. In this diagram, the app has two services that contain multiple versions, and two of those versions are actively running on multiple instances:
Other Google Cloud services, for example Datastore, are shared across your App Engine app. For more information, see Structuring web services.
Services
Use services in App Engine to factor your large apps into logical components that can securely share App Engine features and communicate with one another. Generally, your App Engine services behave like microservices. Therefore, you can run your whole app in a single service or you can design and deploy multiple services to run as a set of microservices.
For example, an app that handles your customer requests might include separate services that each handle different tasks, such as:
- API requests from mobile devices
- Internal, administration-type requests
- Backend processing such as billing pipelines and data analysis
Each service in App Engine consists of the source code from your app and the corresponding App Engine configuration files. The set of files that you deploy to a service represent a single version of that service and each time that you deploy to that service, you are creating additional versions within that same service.
Versions
Having multiple versions of your app within each service allows you to quickly switch between different versions of that app for rollbacks, testing, or other temporary events. You can route traffic to one or more specific versions of your app by migrating or splitting traffic.
Instances
The versions within your services run on one or more instances. By default, App Engine scales your app to match the load. Your apps will scale up the number of instances that are running to provide consistent performance, or scale down to minimize idle instances and reduces costs. For more information about instances, see How Instances are Managed.
Application requests
Each of your app's services and each of the versions within those services must have a unique name. You can then use those unique names to target and route traffic to specific resources using URLs, for example:
https://VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
Incoming user requests are routed to the services or versions that are configured to handle traffic. You can also target and route requests to specific services and versions. For more information, see Handling Requests.
Logging application requests
When your application handles a request, it can also write its own logging
messages to stdout and
stderr. For details about your app's logs, see Writing Application
Logs.
Limits
The maximum number of services and versions that you can deploy depends on your app's pricing:| Limit | Free app | Paid app |
|---|---|---|
| Maximum services per app | 5 | 105 |
| Maximum versions per app | 15 | 210 |
There is also a limit to the number of instances for each service with basic or manual scaling:
| Maximum instances per manual/basic scaling version | ||
|---|---|---|
| Free app | Paid app US | Paid app EU |
| 20 | 25 (200 for us-central) |
25 |