Wasabi Cloud Storage – the quick introduction to cheap yet powerful S3 implementation

Here we are again. There was a lot of hype after we published the post about using Wasabi services as a data layer for the Nextcloud (or ownCloud) collaboration platform, so I promised to elaborate a little bit more about this case. And because here, at NubiSoft, all of us keep our promises regarding scope, dates, and quality (!), I am writing this post to fulfill the promise I made. Before we will dive deep (that is before we publish the second part of post “Private file sharing using NextCloud with Wasabi S3 – a good dropbox replacement”), here I would like to share my point of view regarding Wasabi services, what probably help you clearly understand how Wasabi fits this case.

Background

Before we start it would be worth recalling what exactly the S3 (a.k.a. Simple Storage Service) is. The concept of S3 was started by Amazon in 2006. Simple Storage Service is a service offered by Amazon Web Services (AWS) that provides object storage through a web service interface. Amazon S3 uses the same scalable storage infrastructure that… blah, blah, blah. WAIT! If you read this post you probably know very well what S3 is. If not, you can read this here and if it is still not enough, here.

From our side, we can only confirm, that S3 by Amazon is powerful, brilliant, flexible … We used it, we have loved it, we are still using it now, but it costs adequate to its feature richness. And what if for certain applications you just need not these features or you are implementing software for a client with a limited budget? In such a case, you can turn toward some of the AWS S3 competitors, and among them, you can find Wasabi services, with its very clear business strategy – be simple, be reliable, be affordable. And in our opinion, they are fulfilling their strategy deadly effectively (at least in areas we had a chance to verify them).

Interfaces

This implies that S3 is not a block file system service, but a system for storing objects to which we cannot receive streaming access and which cannot be accessed randomly – there is no implementation of the file descriptor indicating the current reading position. You simply read the file in full or save it in full. It is an indivisible object. You also cannot modify the part of the file. If you need to, you delete the old file and upload the new one. We have to remember all of the above, even if we use some kind of facade exposing S3 as a block filesystem – the know implementation for Linux systems is e.g. s3fs-fuse letting you mount S3 as a directory. Deciding to use it, you fall into caching issues, efficiency problems, etc. We have tested this approach, and in some scenarios, it is justified, however.

Wasabi services give you two interfaces to interact with your objects. First, is the GUI.

A have to admit that their web app edging somewhere between aesthetic and ascetic. But to be understood well – I rate it very well and I like it very much. Of course, it has some limitations but resulting from the browser apps, not from the implementation – it doesn’t make sense to perform heavy bulk operations or upload and download big files. When performing such operations, you will be advised that this could be done more effectively using dedicated client applications.

The second interface is the S3 API. This API is developed by the AWS, and is constantly updated, along with the improvement of their services in terms of functionality. But the core remained unchanged for years. Also, other S3 providers are basing on it, so presently when someone talks about S3 not necessarily mind AWS at all. These other S3 providers often adapt the S3 interface for their specific needs what results in a wast proliferation of implementations. So dedicated applications, during configuration, often present the list of specific providers, after choosing the S3 interface. There are plenty of apps, and one of them is presented at the below screenshot.

Security

In terms of defining access to objects stored by users, we have one root account. Root represents the given organization and is charged monthly for Wasabi services. The root can add other user accounts and define their policies. For example, he may create and assign buckets specific to a given user, so other users cannot have access to them. This way we are able to set up completely separate environments for each of the users, or quite contrary, we can set up one shared environment for a whole team. Here we have the whole arsenal of the RBAC concept, i.e. users, groups and roles that can be assigned different types of permissions.

Policies can be defined using JSON document, just as we doing it at the AWS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

Each user is able to issue (and revoke) their API keys what gives additional flexibility in security management. These keys are of course the preferred way to give access client application to users buckets.

Data retention

For each of the buckets, we can define a separate data retention policy. First is versioning, which means that when we replace the given file, the older version will be preserved anyway.

Whenever we are in the bucket preview mode we can toggle on and off the displaying of the older versions of files. When we toggle it on, we are able to delete the selected version of a given file, because versions behave exactly like files itself.

The second policy is so-called compliance. Turning on this policy for a bucket we are unable to delete the given file until expire its protection period.

We can even define option deleting the given file after expiring its protection period.

As we see these two retention options are quite powerful, however, as for me, one common scenario is unaddressed. I mean situations when files that are documents have their life cycle and are sometimes modified. I would like to be able to enable the option of automatically removing previous versions after a defined period. Otherwise, files that are being modified often will consume a lot of space, and even using “Delete after retention” option will not remove the historical versions – this has to be done completely manually.

Additionally, similarly like in the AWS, we can log all the operations done on buckets. This is done as a file log stored in the given bucket.

Pricing

This is the most insane part of this post. For the 1 TB of data stored in the Wasabi Services, we are charged $6 per month. Theoretically, the amount is calculated not per terabytes but per gigabytes, but the minimum amount you will have to pay monthly is still $6. Worth noting here that we are billed only for the volume of stored data, and no additional fees are collected for data transfer – this is not the case comparing to other big cloud services providers. The exact and up-to-date price listing can be found here.

But to not look at everything through rose-tinted glasses, we have to pay attention to one detail. When you delete data, the minimum period after the data is considered as deleted is three months. This means that if you delete data that was stored half a year, you will stop being charged for them today, but if you delete data that you upload a minute ago, you still be charged for them for the next three months.
This fact limits, of course, some of the concepts of usage for Wasabi services, but there are still others that fit Wasabi perfectly.

And which S3 service provider did you choose? And why him?

Another view angles

1. This is not an affiliated article and we don’t have any money from it.
2. When you choose an S3 service provider, first think about your requirements. Articles like this can only be a clue, but don’t treat them as revealed truths.
3. After all, we are still loving the AWS S3 …