Aliyun Object Storage Service vs. AWS S3

I recently had a conversation about multi-cloud strategy and Aliyun OSS. It is, indeed, very similar to Amazon’s Simple Storage Service.

If you work with DevOps- and Infrastructure-as-a-Code based environments, where you provision different domains (development, stagin, testing, prodcution and so on) as well as application versions on-the-fly, there are few differences to keep in mind.

In a nutshell — for simple operations, S3 and Aliyun OSS will match seamlessly for your apps, but orchestration and environment creation operations like setting bucket ACL-s, and so on, will differ.

Good news is at least for those organizations that standardized on Terraform from HashiCorp, — there is a provider capturing all these differences:

By the way, let me share a great picture from one of the best hard-covers I purchased over last several years, — Metamorpolis by outstanding Tim Franco (hope he wouldn’t object):

Metamorpolis by Tim Franco

I had chance to play around with Aliyun OSS using its free tier. The ecosystem is quite developed, for example:

Node.JS client:

…or the one for Ruby:

…and even one for Go (the one that the Terraform Provider uses)

However, if you plant to migrate from AWS to Aliyun, to port your in-house object client code, or just wondering what’s the state of thing, be prepared to find out that:

  • Although Aliyun OSS is very similar to S3 from object commands perspective — the article Function Mapping Between OSS API and S3 API has more details how close are they, but
  • …OSS and AWS Canonicalized headers differ, that will impact the hash message authentication code called Signature for Client’s requests.

Take a look at Aliyun’s API Reference of OSS. On Page 3, or on its online version, you’ll find reference to computing Request Signature the following way:

"Authorization: OSS “ + Access Key Id + “:” + Signature
Signature = base64(hmac-sha1(AccessKeySecret,
VERB + “\n”
+ CONTENT-MD5 + “\n”
+ CONTENT-TYPE + “\n”
+ DATE + “\n”
+ CanonicalizedOSSHeaders
+ CanonicalizedResource))

There’s a note that it has to be UTF-8 separately within the document.

Compare it with Amazon S3’s Signature, from API Reference , — it looks almost identical:

Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature;
Signature = Base64( HMAC-SHA1( YourSecretAccessKeyID, UTF-8-Encoding-Of( StringToSign ) ) );
StringToSign = HTTP-Verb + "\n"
+ Content-MD5 + "\n"
+ Content-Type + "\n"
+ Date + "\n"
+ CanonicalizedAmzHeaders
+ CanonicalizedResource;

The difference is that CanonicalizedOSSHeaders and CanonicalizedResource in OSS aren’t matched AWS’s CanonicalizedAmzHeadersand CanonicalizedResource

In Aliyun OSS

  • The CanonicalizedOSSHeaders indicates an assembly of HTTP headers whose prefixes are x-oss
  • The CanonicalizedResource indicates the OSS resource that the user wants to access

An example of x-oss header that sets bucket permission to public-read from PUT Bucket ACL:

PUT /?acl HTTP/1.1
x-oss-acl: public-read
Host: oss-example.oss-cn-hangzhou.aliyuncs.com
Date: Fri, 24 Feb 2012 03:21:12 GMT
Authorization: OSS qn6qrrqxo2oawuk53otfjbyc:KU5h8YMUC78M30dXqf3JxrTZHiA=

Or, another one x-oss-server-side-encryption or x-oss-object-acl that specify the server-side encryption algorithm when the OSS creates an object via PUT Object

So if if you consider re-developing or porting a particular S3-capable in-house or open-source client for DevOps pipeline to support Aliyun OSS, that must set up something as simple as ACL-s on buckets, this may be a concern for the sprint planning phase.

Most of the other CRUD parts would remain almost compatible.