This time around, let’s automate the steps I manually performed last time (as much as the S3 APIs allow CLI interaction, which is sadly not much).
Install the AWS CLI (command line interface)
Follow the instructions for your operating system from here:
Run the following commands
Create a new bucket (CLI)
Note: “mikecanuckbucket” is the bucket I’m creating.
aws s3 mb s3://mikecanuckbucket
Which returns the following output:
Configure the static website (CLI)
aws s3 website s3://mikecanuckbucket --index-document index.html
Which returns nothing if it succeeds.
Set bucket-level permissions (Console)
You have to use the console for this one (or at least, I couldn’t find a CLI command to interact with bucket-level permissions). This time around I tried the bucket policy approach, and used this policy example as my template:
- Load the AWS S3 console
- select your bucket
- click the Properties button
- expand the Permissions section
- click the Add bucket policy button
- Paste the bucket policy you’ve constructed – in my example, I simply substituted “mikecanuckbucket” for “examplebucket” from the example
- Click Save
Note: the bucket policy is immediately applied.
Upload a web page (CLI)
Note: “helloworld.html” is the example file I’m uploading to my bucket.
aws s3 cp helloworld.html s3://mikecanuckbucket
Set file-level permissions (Console)
Hah! If you used the bucket policy like me, this won’t actually be necessary. One convenient advantage of this inconvenience.
If you didn’t, then you’ll have to configure file-level permissions like I did in the last post.
Retrieve the page link (Console)
- Select the new file in your new bucket
- Click the Properties button
- Click (or copy) the URL listed as Link
I’m disappointed that the S3 team hasn’t made it possible to eliminate the manual (Console) steps in an operation like this. I must be missing something, or perhaps the AWS shell is where all incomplete features will be added in the future?
I happened to notice a git issue asking whether aws-shell or SAWS was the future, and according to the most active developer in both, it appears to be aws-shell. Presumably this project is being actively developed then (though after a year and a half, it’s still labelled “The aws-shell is currently in developer preview” – and the vast majority of commits are from a year ago). However, it’s sad to see some pretty significant issues have remained open over a year – that’s a project that sounds like it’s on life support, not fully staffed. Or maybe the AWS APIs are still just that incomplete?
It’s also discouraging to see it mention that “The aws-shell accepts the same commands as the AWS CLI, except you don’t need to provide the aws prefix”. This implies that it’s simply relying on the AWS CLI to implement additional commands, rather that implement themselves. And certainly my cursory inspection of the autocomplete commands bears this out (no new options to the base s3 command palette). [That’s understandable – it’s painful as a development organization to duplicate functionality that’s ostensibly being supported already by one branch of the org.]
Still, it is disappointing to see that at this point in the maturity lifecycle of AWS, there are still this many discontinuities to create such a disjoint experience. My experience with the official tutorials is similar – some are great, some are frankly terrible botched efforts, and I would’ve expected better from The Leader in Cloud. [Hell, for that matter, some capabilities themselves such as CodeDeploy are still a botched mess, at least as far as how difficult it was for me to succeed EVEN WITH a set of interdependent – admittedly poorly-written – tutorials.]