Object Storage quotas and limits
Quotas
Quotas are account-level limits placed on usage for Object Storage. Each quota is listed below along with the default values for each endpoint type.
Per endpoint quotas
| Quota | E0 Legacy | E1 Legacy | E2 Standard | E3 Standard |
|---|---|---|---|---|
| Default storage capacity per account, per endpoint | 5 TB | 100 TB | 100 TB | 500 TB |
| Default number of objects per account, per endpoint | 50 M | 100 M | 100 M | 500 M |
| Default number of buckets per account, per endpoint | 1,000 | 1,000 | 1,000 | 1,000 |
| Default ingress throughput per account, per endpoint | 2 Gbps | 2 Gbps | 10 Gbps | 10 Gbps |
| Default egress throughput per account, per endpoint | 2 Gbps | 2 Gbps | 10 Gbps | 10 Gbps |
Please refer to Best practices for high-throughput applications for more information on how to scale applications and how rate limiting is enforced.
Per account quotas
| Quota | E0 Legacy | E1 Legacy | E2 Standard | E3 Standard |
|---|---|---|---|---|
| Default number of access keys per account | 100 | 100 | 100 | 100 |
| Default number of buckets per limited access key | 25 | 25 | 25 | 25 |
View quotas and request an increase
You can view your current quotas and usage in Cloud Manager, the CLI, and the API. See the Quotas guide for Cloud Manager instructions. To increase your quotas above their default values, submit a request through a support ticket.
Limits
Per endpoint limits
The following table lists the limits for each endpoint type on Object Storage. Unlike account-level quotas, these product limits cannot be increased.
| Limit | E0 Legacy | E1 Legacy | E2 Standard | E3 Standard |
|---|---|---|---|---|
| Per bucket performance | ||||
| Maximum capacity per bucket | 1 TB | 1 PB | 1 PB | 5 PB |
| Maximum number of objects per bucket | 50 million | 1 billion | 1 billion | 10 billion |
| Connection limits | ||||
| Connections per bucket | <per bucket rate limit | <per bucket rate limit | <per bucket rate limit | 2,000 |
| Connections per account, per endpoint | 750 | 750 | 2,000 | 2,000 |
| Performance limits | ||||
| Maximum number of Requests Per Second (RPS), per bucket | 750 | <=2,000 | <=5,000 | 20,000 |
| Maximum Lifecycle Policy Deletes Per Second, per bucket (see Note 1) | 75 | 75 | 100 | 300 |
Note: Lifecycle Policy deletes execute over a 24 hour period. The Lifecycle delete rate per second, per bucket, is the maximum rate that can be expected over a 24 hour period.
Multi-part upload limits
The maximum size of a single upload is 5 GB. You can use multi-part uploads to upload an object that exceeds this limit. Both s3cmd and Cyberduck will do this for you automatically as part of the upload process.
| Maximum Object Size | 5 TiB |
| Maximum number of parts per upload | 10,000 |
| Part numbers | 1 to 10,000 (inclusive) |
| Part size | 5 MiB to 5 GiB. There is no minimum size limit on the last part of your multipart upload. |
| Maximum number of parts returned for a list parts request | 1000 |
| Maximum number of multipart uploads returned in a list multipart uploads request | 1000 |
Per bucket rate limiting
Per bucket rate limits
Bucket rate limits specify the maximum Requests Per Second (RPS) for an endpoint. The rate limits for E0 and E1 endpoints are calculated differently than the E2 and E3 endpoints.
- For E0 and E1 endpoints all operations count towards one rate limit for the bucket.
- For E2 and E3 endpoints there are separate rate limits for each operation.
| Operation | E0/E1 Default Rate Limits | E2/E3 Default Rate Limits | E2 Maximum Rate Limits | E3 Maximum Rate Limits |
|---|---|---|---|---|
| GET, HEAD operations for object | 750 RPS This limit is a maximum rate for all operations combined, per bucket. In addition, there is a maximum of 100 RPS for all delete operations as a subset of the total rate limit for the bucket. |
2,000 RPS | 5,000 RPS | 20,000 RPS |
| PUT operations for objects including mult-part uploads | 500 RPS | 1,000 RPS | 2,000 RPS | |
| LIST operations for objects | 100 RPS | 200 RPS | 400 RPS | |
| DELETE | 200 RPS | 200 RPS | 400 RPS | |
| All other operations including ACL and POLICY | 400 RPS | 800 RPS | 1,000 RPS |
*Contact support for any per bucket rate limit increase requests.
Optimizing your application to avoid rate limiting
The rate limit for the number of RPS applies to a bucket and is evaluated against each bucket once per second. If the duration of any request is greater than one second, any open requests will count against the rate limit in the next one second window.
For example, assume there are 750 requests for a single bucket with a duration of two seconds each. All of the requests that do not complete within the first second will count against the rate limit in the next second. With a rate limit of 750 RPS for the bucket, no additional requests can be processed within the two second window until the first 750 requests complete. Any requests that are rate limited will receive a 503 response.
To help avoid rate limiting you can structure your data across multiple buckets, each of which will have its own rate limit.
Rate limiting headers
These headers apply directly to the per bucket rate limits. The Object Storage E2 and E3 endpoints support the following rate limit headers as defined in the IETF draft specification.
x-ratelimit-limit - Indicates the number of requests allowed in the current time window.
x-ratelimit-remaining - Indicates the number of requests remaining in the current time window.
x-ratelimit-reset - Indicates the time, as a relative number of seconds, until the current time window resets.
Examples
x-ratelimit-limit: 2000, 2000;w=1
This indicates a maximum of 2000 requests per second (RPS). The w=1 suggests a 1-second window.x-ratelimit-remaining: 1926
After making some requests within the current 1-second window, there are still 1926 requests left before hitting the limit.x-ratelimit-reset: 1
The current rate limit window will reset in 1 second. After this second passes, the counter will return to the full capacity (2000 requests).
Updated 18 days ago