Setting Amazon S3 ACLs Programatically

I recently wrote a simple Python script for setting Amazon S3 ACLs. You might find it useful.

Usage:

setS3acl.py -a $AWS_ACCESS_KEY -s $AWS_SECURE_KEY -b "myBucket" -f myfile.txt -o $OWNER_AWS_ID "$USR1_AWS_ID:FULL_CONTROL" "$USR2_AWS_ID:READ"

Options

-a - your AWS access key
-s - your AWS secure access key
-b - AWS bucket name (no s3:// nor any other slashes)
-f - file name (no s3:// nor bucket prefixes, just the filename)
-o file owner (AWS ID)

Parameters:

[AWS_ID:FULL_CONTROL|READ|WRITE]

You'll need to use the AWS IDs to identify the user (the long and ugly Amazon account identifiers - e.g. a382d287d4d58222758254ddebac103f70e6f5b).

There are two Python files that you'll need:

* setS3acl.py
* S3.py

Look at the URL to find out where I store the scripts ($0.15 / GB / month) ;-)

Enjoy!

Cloud Transparency

Radovan wrote a comment on Werner's article about cloud transparency. I agree that operators need monitoring and developers want to optimize their apps. However I don't understand how these needs relate to (location) transparency. I think that this is rather about functionality (e.g. OOTB performance and right management tools) that the cloud offers.

I see a little schizophrenia in the AWS messaging. "We (AWS) want developers to play with all nuts and bolts, optimize, monitor, and trace at the network packet level. And when the code jumps into our queuing, simple db, payment or whatever other high-level service then forget all transparency, close your eyes and cross your fingers." :-)

I think that different developers have different needs in terms of the right transparency level. IMO AWS is heavily used by web developers. I believe that particularly web developers will lean towards higher transparency, packaged high-level services and easy deployment.

Radovan, what do you think about the Google AppEngine?