Object Storage Service:S3 API on OSS: supported operations and limitations

Compatible S3 API operations

The following table describes the bucket, object, and multipart API operations in S3 that are compatible with OSS.

Differences between OSS and S3

The following section describes the differences between OSS and S3:

• Request style

  Amazon S3 supports two request addressing styles: virtual-hosted and path-style. Virtual-hosted style requests use the bucket name as a subdomain in the endpoint, while path-style requests place the bucket name in the URL path. For security reasons, OSS supports only the virtual-hosted style. Therefore, after being migrated from S3 to OSS, all client applications and S3-compatible tools must be configured to use virtual-hosted style requests. Failure to do so will result in access being denied.

• Definitions of access control lists (ACLs)

  The definition of ACL is different in OSS and S3. The following table describes the differences.

  Level	Permission	S3	OSS
  Bucket	READ	The permissions to list buckets.	If no object permissions are configured for an object in a bucket, you can perform only read operations on the object.
  	WRITE	The permissions to write or overwrite objects in a bucket.	If the object that you want to write does not exist in the specified bucket, the object is created in the bucket. If the object that you want to write exists in the specified bucket and no permissions are configured for the existing object, the existing object can be overwritten. Use InitiateMultipartUpload to upload objects.
  	READ_ACP	The permissions to read the ACL of a bucket.	Only the bucket owner and authorized RAM users have the permissions to read the ACL of a bucket.
  	WRITE_ACP	The permissions to configure the ACL of a bucket.	Only the bucket owner and authorized RAM users have the permissions to configure the ACL of a bucket.
  Object	READ	The permissions to read an object.	The permissions to read an object.
  	WRITE	N/A	The permissions to overwrite an object.
  	READ_ACP	The permissions to read the ACL of an object.	Only the bucket owner and authorized RAM users have the permissions to read the ACL of an object.
  	WRITE_ACP	The permissions to configure the ACL of an object.	Only the bucket owner and authorized RAM users have the permissions to configure the ACL of an object.

  Important

  OSS supports only the following ACL modes in S3: private, public-read, and public-read-write.

• Storage class

  The storage classes of OSS and S3 do not have a one-to-one correspondence (OSS provides 5 storage classes, whereas S3 provides 7 major storage classes), and they differ in capabilities such as minimum storage duration and access method. You can convert the storage class of OSS objects based on your requirements. The main mappings and differences are as follows:

  OSS storage class	Corresponding S3 storage class	Key differences
  Standard	STANDARD	Minimum storage duration: Neither OSS nor S3 has a requirement. Access method: Both support real-time access.
  Infrequent Access	STANDARD_IA ONEZONE_IA	Mapping: OSS zone-redundant IA corresponds to STANDARD_IA, and locally redundant IA corresponds to ONEZONE_IA. Minimum storage duration: 30 days for both. Access method: Both support real-time access and charge data retrieval fees.
  Archive	GLACIER_IR GLACIER (Flexible)	Minimum storage duration: 60 days for OSS and 90 days for S3. Access method: OSS requires a restore operation (about 1 minute), or you can enable real-time access to Archive objects; S3 GLACIER_IR provides millisecond-level real-time access, whereas GLACIER (Flexible) requires a Restore operation (Expedited: 1–5 minutes, Standard: 3–5 hours, Bulk: 5–12 hours).
  Cold Archive	DEEP_ARCHIVE	Minimum storage duration: 180 days for both. Access method: Both require a restore operation. OSS restore: high-priority about 1 hour, standard 2–5 hours, batch 5–12 hours; among S3 storage classes, only GLACIER (Flexible) reaches this restore duration, whereas DEEP_ARCHIVE requires Standard ≤12 hours (Batch 9–12 hours) and Bulk ≤48 hours.
  Deep Cold Archive	No corresponding storage class	A storage class unique to OSS for extremely cold data. AWS has no storage class colder than DEEP_ARCHIVE (no corresponding S3 storage class). Minimum storage duration: 180 days for OSS (no corresponding S3 storage class). Access method: OSS requires a restore operation, high-priority about 12 hours, standard about 48 hours (among S3 storage classes, only DEEP_ARCHIVE reaches this restore duration).

  Note

  In addition, S3 provides a dedicated INTELLIGENT_TIERING storage class that automatically moves objects between multiple access tiers based on access frequency. OSS does not provide a dedicated intelligent-tiering storage class; you can achieve similar automatic tiering by using lifecycle rules.

  If real-time access to Archive objects is not enabled for a bucket, you must first restore the Archive objects in the bucket before you can access them. OSS ignores the duration of the restored state configured for objects in S3 API operations. By default, the restored state lasts for one day and can be extended up to seven days. Then, the object enters the frozen state.

• ETag

  • If objects are uploaded by using the PUT method, the ETag of an OSS object and the ETag of an Amazon S3 object have different case sensitivities. The ETag of an OSS object is in uppercase letters, and the ETag of an Amazon S3 object is in lowercase letters. If your client uses ETag to validate content, configure your client to ignore the case sensitivity to prevent errors.

  • If objects are uploaded by using the multipart upload method, OSS calculates ETag values by using a different method from that of S3.