Extending an Amazon S3 Integration to Google Cloud Storage With the Interop API

Cloud storage services are a clear choice for ease of management and to incrementally scale costs with growth. Startups and enterprises alike look to “cloud” offerings first when choosing an object store for data. There are quite a few cloud storage services to choose from today. Check out our recent blog post to learn more about the differences between object storage and other cloud storage.

Google Cloud Storage offers a reasonably priced service, with clear reliability guarantees and uniquely cheap and fast lowest-tier storage. Amazon S3 was the first wildly popular cloud storage service; its API is now the de facto standard for object storage.

In fact, Google Cloud Storage (GCS) optionally offers access via an S3-compatible API. This makes it easy to switch backend storage from Amazon S3 to GCS. How easy? It’s as simple as swapping out a bucket URI!

Just kidding.

In principle, it should be that easy, but there are a few catches that may trip up developers, even those familiar with using S3 and Amazon’s boto3 library to access S3.

Getting Started With The S3-Interop API for GCS

To start the process, enable the Google Cloud Storage service in the Google Cloud console and create a project and bucket for testing. You can then enable the S3-interoperable API in the Interoperability tab within Project Settings. Google enables the S3-interoperability API on a per-user basis for each project. This means that you’ll want to ensure you have a unique credential or user account for each end-user or service if you want more meaningful access logs. While you’re in the interoperability settings, create an access key and save it locally for reference.

As the Interoperability settings page describes, the secret key lets you authorize requests with HMAC authentication. You can calculate the signatures for each request manually in your shell or REPL, or use a library.

The examples below use boto3, available from pypi.org, to access an Amazon S3 account. The library can be installed by running pip install boto3. You can save the example code below to a script or run it interactively from a Python or IPython REPL.

from boto3.session import Session
import boto3

ACCESS_KEY = "AWSSOKYOUROWNKEYGOESHERE"
SECRET_KEY = "DehVolK/oZQ7e5kh76+o5Yy75BTyrmqMQlXfEXOt"

session = Session(aws_access_key_id=ACCESS_KEY,
                  aws_secret_access_key=SECRET_KEY)

s3 = session.resource('s3')

bucket = s3.Bucket('yourbucket')

for f in bucket.objects.all():
        print(f.key)

We’ll modify the basic example above that retrieve objects from S3 to demonstrate some of the necessary conversion steps.

First, we’ll use the storage.googleapis.com endpoint. Google has other endpoints, but this is the one designated for S3-interoperability.

Next, Google Cloud Storage’s S3-interoperable API requires some special attention. It doesn’t accept encoding-type parameters, and some newer S3 methods are not available. boto3 relies on list_objects_v2 for many of its helper calls. You can dig into the botocorelibrary and inspect the event types it emits to flexibly handle construction, sending, and parsing of API calls.

from boto3.session import Session
from botocore.client import Config
from botocore.handlers import set_list_objects_encoding_type_url

import boto3

ACCESS_KEY = "GOOGOKYOUROWNKEYGOESHERE"
SECRET_KEY = "DehVolK/oZQ7e5dh76+o5Yy75BTyrmqMQlXfEXOt"
boto3.set_stream_logger('')

session = Session(aws_access_key_id=ACCESS_KEY,
                  aws_secret_access_key=SECRET_KEY,
                  region_name="US-CENTRAL1")

session.events.unregister('before-parameter-build.s3.ListObjects',
                          set_list_objects_encoding_type_url)

s3 = session.resource('s3', endpoint_url='https://storage.googleapis.com',
                      config=Config(signature_version='s3v4'))

bucket = s3.Bucket('yourbucket')

for f in bucket.objects.all():
        print(f.key)

# https://gist.github.com/gleicon/2b8acb9f9c0f22753eaac227ff997b34

Differences in Uploads

It turns out Google Cloud Storage has other differences as well.

It supports uploading objects in multiple parts, like S3’s multipart upload. However, it manages the lifecycle differently.

• S3’s multipart upload creates an entity that manages component objects, and supports lifecycle behaviors on that group.
• Google Cloud Storage allows you to upload individual objects, but does not help you manage the group.

When completing a multipart upload, S3 merges the objects into one, whereas GCS allows you to merge objects with a join-objects request, returning a new object with component objects concatenated. This doubles the storage used for the object(s) and requires you to write code to manage the lifecycle of component objects originally uploaded.

It is possible to simplify object storage integrations; the easiest way is to use a platform that unifies multiple storage integrations via a single API. This allows you to code once and use a unified API to normalize your requests while supporting Google Cloud or other storage APIs. 

Reach out and tell me how your integration goes.