Does Amazon S3 support symlinks?

Question

I have an object which I would like to address using different keys without actually copying the object itself, like a symlink in Linux. Does Amazon S3 provide such a thing?

Answer 1

Symlinks no, but same object to multiple keys, maybe.

Please refer to Rodrigo's answer at Amazon S3 - Multiple keys to one object

If you're using the website serving on S3, you can do it via header x-amz-website-redirect-location

If you're not using the website serving, you can create your custom header (x-amz-meta-KeyAlias) and handle it manually.

Answer 2

I had a similar question and needed a solution, which I describe below. While S3 does not support symlinks, you can do this in a way with the following:

echo "https://s3.amazonaws.com/my.bucket.name/path/to/a/targetfile" > file
aws s3 cp file s3://my.bucket.name/file
wget $(curl https://s3.amazonaws.com/my.bucket.name/file)

What this is actually doing is getting the contents of the file, which is really just a pointer to the target file, then passing that to wget (curl can also be used to redirect to a file instead of wget).

This is really just a work around though as its not a true symlink but rather a creative solution to simulate symlinks.

Answer 3

S3 does not support the notion of a symlink, where one object key is treated as an alias for a different object key. (You've probably heard this before: S3 is not a filesystem. It's an object store).

If you are using the static web site hosting feature, there is a partial emulation of this capability, with object-level redirects:

http://docs.aws.amazon.com/AmazonS3/latest/dev/how-to-page-redirect.html

This causes requests for "object-a" to be greeted with a 301 Moved Permanently response, with the URL for "object-b" in the Location: header, which serves a similar purpose, but is of course still quite different. It only works if the request arrives at the website endpoint (not the REST endpoint).

If you use a reverse proxy (haproxy, nginx, etc.) in EC2 to handle incoming requests and forward them to the bucket, then of course you have the option at the proxy layer of rewriting the request URL before forwarding to S3, so you could translate the incoming request path to whatever you needed to present to S3. How practical this is depends on your application and motivation, but this is one of the strategies I use to modify where, in a particular bucket, an object appears, compared to where it is actually stored, allowing me to rewrite paths based on other attributes in the request.