News

Cheaper storage space from 2025-02-01

Costs for object storage are taken from your account balance once a day shortly after midnight (in the local time zone of Zurich). These costs are made up of three components, namely number of API requests (CHF 0.005 per 1000 requests), outbound network traffic (CHF 0.02 per GB, inbound traffic is free of charge), and storage space used (here, an average value is worked out over the day).

The storage space component usually makes up the largest proportion of the overall costs. From 2025-02-01, storage space used will only cost CHF 0.001 per GB and day, which is 66% less than previously. This will make our object storage even more attractive, e.g. for off-site backups of your important data. The three cost components will continue to be calculated individually and precisely, then added together and only rounded up to whole Centimes in a final step, before being taken from your credit.

Insight into technical details

At cloudscale, we rely on Ceph for our storage clusters: you can access its S3-compatible HTTPS-API directly on *.objects.rma|lpg.cloudscale.ch, e.g. for uploading and downloading objects. As we could not, however, use Ceph features for billing, we developed our own microservice, which is called "rgw-metrics". rgw-metrics collects usage data from our Ceph storage clusters, thus allowing exact, usage-based billing, on the one hand, and the display of current and past usage data in our cloud control panel and via the API, on the other.

rgw-metrics runs independently of the software providing the control panel and API and saves the collected usage data as a time series dataset. We recently carried out a rgw-metrics rewrite: in addition to switching from Flask to Django, which we also use elsewhere, we have now implemented a containerized setup. A further important aim of this change is enhanced efficiency. Further insights into rgw-metrics are available from Julian in our engineering blog.

Useful object storage features

In the most basic case, you create a bucket and then use one of the numerous S3-compatible tools to upload and download objects and to delete them again at the end. However, our object storage is also suitable for demanding setups, given that Ceph supports a wealth of S3 features such as ACLs, versioning and policies for individual access rights.

Example 1: Additional read-only access to your bucket

To set up read-only access to your bucket (e.g. "my-bucket") for a person or application, create an additional objects user via the control panel or API and make note of the displayed user ID (e.g. "11111111...88888888"). Then create a file as follows and save it locally, e.g. under policy.json:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam:::user/1111111122222222333333334444444455555555666666667777777788888888"},
    "Action": ["s3:ListBucket","s3:GetObject"],
    "Resource": [
      "arn:aws:s3:::my-bucket",
      "arn:aws:s3:::my-bucket/*"
    ]
  }]
}

Now add this policy to your bucket by means of e.g. the s3cmd tool:

s3cmd setpolicy policy.json s3://my-bucket

The additional objects user can now use their own credentials (access key and secret key) to list and read the objects in "my-bucket", but cannot change or delete them.

Example 2: Configuring CORS headers

You can make objects publicly accessible, e.g. by means of:

s3cmd --acl-public setacl s3://my-bucket/my-font.woff2

The object is then directly available (without access key and secret key authentication) at https://my-bucket.objects.lpg.cloudscale.ch/my-font.woff2.

However, when integrating it into a website – e.g. https://www.example.com – the browser may not load the file due to the same-origin policy. In this case, help is available in the form of CORS (cross-origin resource sharing) headers that you configure on your bucket. To do this, create a file as follows and save it locally, e.g. under cors.xml:

<CORSConfiguration>
  <CORSRule>
    <AllowedOrigin>https://www.example.com</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
  </CORSRule>
</CORSConfiguration>

Then transfer this configuration to your bucket by means of e.g. s3cmd:

s3cmd setcors cors.xml s3://my-bucket

When visiting https://www.example.com the browser will access https://my-bucket.objects.lpg.cloudscale.ch/my-font.woff2 in a "preflight" request and send the HTTP header

Origin: https://www.example.com

in the request. If the sent URL matches the one configured on the bucket, the object storage adds the headers

access-control-allow-origin: https://www.example.com
access-control-allow-methods: GET

to its response, thus signalling to the browser that the file may be loaded in the context of this website.

Our object storage covers the most varied use cases, ranging from filing your off-site backups, to serving as a storage backend for your applications, and to sharing files. From 2025-02-01 you will also benefit from significantly cheaper storage space. What more could one ask for?

"Object-oriented" in the best possible sense,
Your cloudscale team