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:
terraform-provider - Terraform for Alibaba Cloud, Support ECS, Block Storage, SLB, VPC, Nat Gateway, RDS, ESS, OSS etc.github.com
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):
I had chance to play around with Aliyun OSS using its free tier. The ecosystem is quite developed, for example:
…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.
"Authorization: OSS “ + Access Key Id + “:” + Signature
Signature = base64(hmac-sha1(AccessKeySecret,
VERB + “\n”
+ CONTENT-MD5 + “\n”
+ CONTENT-TYPE + “\n”
+ DATE + “\n”
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"
The difference is that
CanonicalizedResource in OSS aren’t matched AWS’s
In Aliyun OSS
CanonicalizedOSSHeadersindicates an assembly of HTTP headers whose prefixes are
CanonicalizedResourceindicates 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
Date: Fri, 24 Feb 2012 03:21:12 GMT
Authorization: OSS qn6qrrqxo2oawuk53otfjbyc:KU5h8YMUC78M30dXqf3JxrTZHiA=
Or, another one
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.