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”
+ 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
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.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.