Quotas & limits

This page describes quotas and request limits for Cloud Storage.

Buckets

  • There is a per-project rate limit to bucket creation and deletion of approximately 1 operation every 2 seconds, so plan on fewer buckets and more objects in most cases. For example, a common design choice is to use one bucket per user of your project. However, if you're designing a system that adds many users per second, then design for many users in one bucket (with appropriate permissions) so that the bucket creation rate limit doesn't become a bottleneck.

  • Highly available applications should not depend on bucket creation or deletion in the critical path of their application. Bucket names are part of a centralized and global namespace: any dependency on this namespace creates a single point of failure for your application. Due to this and the 1 operation per 2-second limit mentioned above, the recommended practice for highly available services on Cloud Storage is to pre-create all the buckets necessary.

  • There is an update limit on each bucket of once per second, so rapid updates to a single bucket (for example, changing the CORS configuration) won’t scale.

  • There is a limit of 100 members holding legacy IAM roles per bucket. Examples of members include individual users, groups, and domains. See IAM identities.

  • For buckets with Pub/Sub notifications:

    • The bucket can have up to 100 total notification configurations.

    • The bucket can have up to 10 notification configurations set to trigger for a specific event.

    • Each notification configuration can have up to 10 custom attributes.

Objects

  • There is a maximum size limit of 5 TB for individual objects stored in Cloud Storage.

    • The maximum size of a single upload request is also 5 TB. For uploads that would take a long time over your connection, consider using resumable uploads in order to recover from intermediate failures. See Resumable uploads for more information.

  • There is an update limit on each object of once per second, so rapid writes to a single object won’t scale. For more information, see Object immutability in Key Terms.

  • There is no limit to writes across multiple objects, which include uploading, updating, and deleting objects. Buckets initially support roughly 1000 writes per second and then scale as needed.

  • There is no limit to reads of an object. Buckets initially support roughly 5000 object reads per second and then scale as needed.

  • Performance is much better for publicly cacheable objects. If you have an object being used to control many clients and thus want to disable caching to provide the latest data:

    • Consider instead setting the object's Cache-Control metadata to public with max-age of 15-60 seconds. Most applications can tolerate a minute of spread, and the cache hit rate will improve performance drastically.

    • Proxy data transfers through a Google App Engine application located in the same location as your bucket.

    • Use Cache-Control: no-cache for an object to indicate that the object must not be cached for subsequent requests in edge-caches.

    For more information about Cache-Control directives, see RFC 7234: Cache-Control.

  • There is a limit of 100 access control list entries (ACLs) per object. Members can be individual users, groups, or domains. See ACL scopes.

  • For object composition:

    • Up to 32 objects can be composed in a single composition request.

    • While there is no limit to the number of components that make up a composite object, the componentCount metadata associated with a composite object saturates at 2,147,483,647.

    • Composite objects are subject to the overall 5 TB size limit for objects stored in Cloud Storage.

XML API requests

  • When sending requests through the XML API, there is a limit on the combined size of the request URL and HTTP headers of 16 KB.

  • When listing resources with the XML API, there is a limit of 1000 items that get returned.

HMAC keys for service accounts

  • There is a limit of 5 HMAC keys per service account. Deleted keys do not count towards this limit.

Bandwidth monitoring

Cloud Storage provides bandwidth monitoring for you to track the in-region read bandwidth usage of your project's buckets. Bandwidth monitoring is aggregated by region and tracks usage for the last 30 days. Bandwidth monitoring is not available for multi-regions.

In order to be tracked by bandwidth monitoring:

  • The usage must be by Google Cloud resources other than Cloud Storage buckets.

  • If the bucket is located in a region, the usage must be by resources located in the same region.

  • If the bucket is located in a dual-region, the usage must be by resources located in either of the regions that makes up the dual-region.

  • The usage must be either from the JSON API GET Object method or the XML API GET Object method.

To view bandwidth monitoring:

Open Cloud Storage bandwidth monitoring