How to benchmark IO Throughput, Storage Capacity, and Latency per S3 Storage Class?

For modeling S3 performance characteristics across storage classes, here's what you should know:

IO Throughput S3 provides baseline performance of at least 3,500 PUT/COPY/POST/DELETE requests per second and 5,500 GET/HEAD requests per second per prefix. These are minimum guaranteed thresholds, not hard caps. There's no explicit per-bucket throughput limit, and you can scale horizontally by using multiple prefixes. For example, with 10 prefixes, you could theoretically achieve up to 55,000 read requests per second.

The request rate capabilities are generally consistent across S3 Standard, Standard-IA, and Intelligent-Tiering storage classes. However, for Glacier storage classes, throughput is inherently limited by the retrieval model, which involves a restoration process rather than direct access.

Latency Latency varies significantly by storage class:

• S3 Standard, Standard-IA, and Intelligent-Tiering: Millisecond access times for both reads and writes
• S3 Glacier Flexible Retrieval: Minutes to hours for retrieval (depending on the retrieval option selected)
• S3 Glacier Deep Archive: Hours for retrieval

There are no published specific millisecond latency benchmarks per storage class, as actual performance depends on many factors including object size, network conditions, and client configuration.

Storage Capacity S3 is designed for virtually unlimited storage capacity across all storage classes. Performance is not directly tied to total stored data volume. However, object size can impact performance:

• Small objects (KB range): Higher overhead per object, may benefit from batching
• Large objects (GB range): Can benefit from multipart uploads and byte-range fetches

Monitoring and Benchmarking To establish your own benchmarks:

1. Use CloudWatch metrics to track actual usage patterns (GetRequests, PutRequests)
2. Monitor for HTTP 503 (Slow Down) errors, which indicate you're approaching throughput limits
3. Track latency metrics to identify performance degradation
4. Consider network throughput, CPU, and DRAM requirements when optimizing

When modeling performance, it's important to understand that S3 scaling happens gradually, not instantaneously. During scaling periods, you may encounter HTTP 503 errors which typically dissipate once scaling is complete.

For performance-sensitive applications, consider:

• Implementing retry logic with exponential backoff
• Distributing objects across multiple prefixes
• Using Amazon CloudFront or S3 Transfer Acceleration
• Placing EC2 instances in the same AWS Region as your S3 bucket to reduce latency
  Sources
  How to model or determine IO throughput (requests/sec) capacity for S3 buckets? | AWS re:Post
  Performance guidelines for Amazon S3 - Amazon Simple Storage Service

With Amazon S3 applications can easily achieve thousands of transactions per second in request performance when uploading and retrieving storage from Amazon S3. 3,500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD requests per second per partitioned Amazon S3 prefix.

Also, if you increase your requests gradually, Amazon S3 automatically scales to handle the increased request rate. [+] Best practices design patterns: optimizing Amazon S3 performance: https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html

If you target the different prefixes, you can scale up as follows: s3://bucket/ ---> 3500 PUT s3://bucket/common-prefix/ ---> 3500 PUT s3://bucket/common-prefix/1/ ---> 3500 PUT s3://bucket/common-prefix/2/ ---> 3500 PUT s3://bucket/common-prefix/3/ ---> 3500 PUT

In total, you will be able to send 17,500 PUT request per second.

Are there published or recommended baseline capacities or thresholds per storage class? -- The TPS limits are for s3 operations and not for a specific storage class. https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html

For latency, is there a general expectation per class (e.g., Standard = low, Glacier = high) that can be quantified? Amazon S3 offers a range of other storage classes for the objects that you store. Not based on performance. [+] https://aws.amazon.com/s3/storage-classes/#topic-0 [+] https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-class-intro.html

Can throughput vary significantly between storage classes, or is it mostly influenced by prefix parallelism regardless of storage class? Vary per prefix not storage class.

Are there AWS-recommended performance benchmarks or metrics that modelers and architects can use for performance modeling use cases? Few references: [+] Performance guidelines for Amazon S3: https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-guidelines.html [+] Performance design patterns for Amazon S3: https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-design-patterns.html

Any documentation links or CloudWatch metric suggestions are also appreciated. You can enable the Cloud Watch Request metrics and Monitor Amazon S3 requests to quickly identify and act on operational issues. When enabled, request metrics are reported for all object operations. By default, these 1-minute metrics are available at the Amazon S3 bucket level. You can also define a filter for the metrics using a shared prefix, object tag, or access point. [+] Monitoring metrics with Amazon CloudWatch: https://docs.aws.amazon.com/AmazonS3/latest/userguide/cloudwatch-monitoring.html