1. 16
  1.  

  2. 6

    Pretty normal stuff, uploading the generated static content to S3 and making it publicly accessible via CloudFront. The tutorial also discusses configuring your domain and setting up Travis (or other CI) for automated deployments. Good stuff!

    1. 5

      Great guide! One small note; you should use AWS credentials associated with an IAM role that has the least privileges required to get the job done. In this case, using creds from an IAM role that could only write to the particular S3 bucket and invalidate the specific CloudFront domain would be most secure.

      1. 4

        This is correct – although right now there is a bug with IAM cloudfront rules, which means you must have full cloudfront access to do even a simple invalidation :(

      2. 4

        Why encrypt-at-rest the contents of a static website where every file is ACL’d for public read? “Unguessable URLs to static resources” is a pretty rare use-case.

        The cache invalidation of /* will get expensive quickly for non-trivial sites, since you pay for every path invalidation past 1000 in a month, and for patterns, you pay for each path matched. It’s fair to leave resolution as an exercise to the reader, but that’s an expensive warning to omit. Suggest pointing at using git diff-tree to find what has changed since the last push, and only emitting invalidations for those paths.

        Otherwise, it’s a nice walk-through of the basic concepts. A little jarring in the assumed skill level the moment it says to use IAM to create a reduced privilege user: folks who can create IAM users and policies without hand-holding are unlikely to need this level of guidance on an S3 static website deploy. But who am I to speak, when I went through this process a little while back I scratched my head for a while figuring out the differences between S3 as a CloudFront backend and the S3 website interface as a CloudFront backend.

        1. 7

          The cache invalidation of /* will get expensive quickly for non-trivial sites, since you pay for every path invalidation past 1000 in a month, and for patterns, you pay for each path matched.

          Incorrect.

          http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html#PayingForInvalidation

          The first 1,000 invalidation paths that you submit per month are free; you pay for each invalidation path over 1,000 in a month. An invalidation path can be for a single object (such as /images/logo.jpg) or for multiple objects (such as /images/*). A path that includes the * wildcard counts as one path even if it causes CloudFront to invalidate thousands of objects.

          This was a misunderstanding I once had as well - AWS pricing can be a handful…

          1. 5

            Thank you. I swear that text has changed and that when I last looked at it, it said the opposite. But hey, I’ll take the cheaper simpler solution.

            1. 4

              This bothered me enough that I’ve used web.archive.org to check older versions of the documentation; it used to say:

              For the purposes of invalidation pricing, an object invalidation request is defined as a single Path element object. For more information about the Path element, see Invalidating Objects and Displaying Information about Invalidations.

              where that see link was to a section higher in the page and Path/path was only really used in the page for individual object paths being matched by an invalidation.

              So it’s good that they’ve improved the documentation and changed it because the old text explicitly “clarified” such that it read as paying per invalidated object.

              So you (owen) and I had the same misunderstanding because that’s what it said.