By default, Cloud Run services have a maximum of 100 instances. You can increase this number to the maximum allowed for your region. The maximum limit for each region is also impacted by the CPU and memory configuration for your Cloud Run service. Specifically, the maximum number of instances available for your service is the minimum of each of the following:
- regional quota baseline divided by the requested multiple of 1 CPU
- regional quota baseline divided by the requested multiple of 2GB memory
For example, a baseline quota of 1000 instances with either 4GB memory or 2 CPU will get an effective limit of 500.
You can see the baseline per-region quota for your region in the quotas page in the console.
How to increase baseline regional quota
If you need a greater maximum number of instances for your region your Cloud Run service is deployed to, you can request a quota increase.
Best practices for setting maximum instances
The following section describes the best practices for configuring maximum instance limits for your services.
Optimal maximum instance value for event-driven services
Event driven services, such as functions, can experience sporadic traffic spikes based on incoming events. To determine an optimal maximum instance value for these services, you need to consider factors such as, service invocation time, expected average invocation, peak invocation frequency, and fault tolerance for invocation failures.
A good rule of thumb is to start with a maximum instances value of 3, then monitor for invocation failures and adjust the maximum instances value upward as necessary.
Handle requests when all instances are busy
Under normal circumstances, your service scales up by creating new instances to handle incoming traffic load. But when you have set a maximum instances limit, you might encounter a scenario where there are insufficient instances to meet incoming traffic load.
In that scenario, Cloud Run attempts to serve a new inbound request for up to 30 seconds:
- If an instance finishes processing its request during this time period, it might start to process the new inbound request.
- If no instance becomes available, the request will fail.
Cloud Run automatically saves events destined for event-driven services until capacity is available.
Maximum instance limits that exceed Cloud Run's scaling ability
When you specify a maximum instances limit, you are specifying an upper limit. Setting a large limit does not mean that your service will scale up to the specified number of instances. It only means that the number of instances that co-exist at any point in time shouldn't exceed the limit.
Further, setting a maximum instances limit might affect the scaling strategies that Cloud Run uses to meet your traffic demand. In general, Cloud Run will prioritize honoring your specified limit rather than scaling up and potentially exceeding your limit.
Handle traffic spikes
In some cases, such as rapid traffic surges, Cloud Run might, for a short period of time, create more instances than the specified maximum instances limit. If your service can't tolerate this temporary behavior, you might want to factor in a safety margin and set a lower maximum instances value than your service can tolerate.
Deployments
When you deploy a new revision, Cloud Run migrates traffic from the earlier revision to the new one. Because maximum instance limits are set for each revision independently, you might temporarily exceed the specified limit during the period after deployment.
For example, a service might have a maximum instances limit of 5. Under normal circumstances, the service scales up to 5 instances as it handles requests. When you deploy a new revision, the new revision has its own max instances limit of 5.
Requests that are already being handled by the previous revision aren't interrupted when you deploy a new revision. Instead, these requests continue to make progress. New inbound requests will be handled by the newly-deployed revision of your service.
Thus, the service in the previous example might have up to 10 total instances (5 for each revision) during the period after deploying the new revision. The amount of time required for instances of the previous revision to terminate depends on the time required for those instances to finish handling any active requests. This is an additional factor to take into account when selecting an appropriate max instances limit.