J Cole Morrison wrote an excellent guide into AWS IAM policies. It’s super useful for anyone who have tried implementing IAM policies and failed (or even barely succeeded).
What is an AWS IAM Policy?
A set of rules that, under the correct
conditions, define what
actions the policy
principal or holder can take to specified AWS
That still sounds a bit stiff. How about:
Who can do what to which resources. When do we care?
There we go. Let’s break down the simple statement even more…
Compared to all the AWS documentation one has to dive through, this one is a giant time saver!
“S3 static site with SSL and automatic deploys using Travis” is a goldmine of all those simple technologies tied into a single knot for an impressive result. It has a bit of everything:
- Jekyll – simple, blog-aware, static sites engine, for managing content.
- GitHub – for version control of the site’s content and for triggering the deployment chain.
- Travis CI – for testing changes, building and deploying a new version.
- Amazon S3 – simple, cheap, web-enabled storage of static content.
- Amazon CloudFront – simple, cheap, geographically-distributed content delivery network (CDN).
- Amazon Route 53 – simple and cheap DNS hosting and domain management.
- Amazon IAM – identity and access management for the Amazon Web Services (AWS).
- Let’s Encrypt – free SSL/TLS certificate provider.
When put altogether, these bits allow one to have a fast (static content combined with HTTP 2 and top-level networking) and cheap (Jekyll, GitHub, Travis and Let’s Encrypt are free, with the rest of the services costing a few cents here and there) static website, with SSL and HTTP 2.
This is a classic example of how accessible and available is modern technology, if (and only if) you know what you are doing.