Proposal: Static Websites

[brettstack]

SAM should provide a way to easily create static websites hosted on S3 and CloudFront. The purpose of this Issue is to gather requirements from the community to ensure we address primary use-cases.

Requirements:

1. Create an S3 Bucket configured with WebsiteConfiguration
   1. Option for enabling S3 redirect configuration for clean SPA routes
   2. Allow specifying CodeUri which points to the assets directory to upload to S3.
      1. Currently, Lambda Functions get uploaded to an existing S3 Bucket prior to SAM transformation, whereas the S3 bucket for websites will be created within the stack. One option is to upload to an existing S3 Bucket (the same one used for Lambda and APIs) and have a CloudFormation Custom Resource for copying to the Website S3 bucket.
      2. The same Custom Resource could be used for deployments (invalidate CloudFront cache)
      3. CodeUri should be optional to allow users to handle UI deployments external to SAM.
      4. We may decide to punt the CodeUri/Deployment story as a follow-up so that we can deliver the infrastructure story first.
2. Create a CloudFront distribution to provide caching, edge nodes, custom domain support, etc.
   1. CloudFront distribution should provide opinionated defaults, but all properties should be configurable by end user
3. Allow for specifying a custom domain name
   1. Route53 configuration
   2. ACM Certificate (optionally pass in your own)
   3. Support for redirecting non-www to www

Please describe your use case and let us know how SAM could make it easier for you to create websites.

[Nr18]

This would be very helpful currently i have already done this by using CodePipeline, CodeBuild and CFN resources with CustomResources as followed:

• CodeBuild packages the web application and is used as OutputArtifacts
• The template deploys with a SourceBucketName & SourceObjectKey parameter that points to the OutputArtifact
• The templates create a bunch of resources like S3, CloudFront & Cognito stuff
• Custom resource accept variable like: IdentityPoolId, UserPoolId, UserPoolWebClientId, AppSyncEndpoint, CloudFrontDistributionId
• Custom resource will
  • Download the and Unzip
  • Merge/override configuration options based on the passed variable
  • Compare the "local" files with the one on S3, if there are files on S3 that are not in the local copy mark it as "toBeRemoved"
  • Upload all files except the index.html
  • Upload index.html (index.html references to specific versions are uploaded in the previous step)
  • Invalidate core files: (index.html, settings.js, etc)
  • Remove the "toBeRemoved" files

These steps are used by web applications that are build for Aurelia or Angular they have a build system that point to a specific version in the index.html file: /app.[SOME_HASH].bundle.js.

[brysontyrrell]

Ideally, for me, I'd like SAM to handle the bucket content and not any of the configuration. This has use cases past just static web content.

Something fairly simple such as:

AWSTemplateFormatVersion: 2010-09-09
Transform: AWS::Serverless-2016-10-31

Resources:
  WebBucket:
    Type: AWS::S3:Bucket

  WebBucketContent:
    Type: AWS::Serverless::BucketContent
    Properties:
      BucketName: !Ref WebBucket
      ContentUri: ./path/to/content/dir
      SyncOptions: # Optional: Default behavior is to sync the Bucket's content with the artifact exactly
        - IgnoreExisting # Do not overwrite existing files in the Bucket
        - Preserve # Do not delete files in the Bucket not in the artifact

During the package process the ContentUri location would be zipped up and uploaded to the S3 Bucket SAM is sending artifacts to and the value replaced with the S3 URI - identically to how Lambda packages are handled.

Then during deployment the custom CloudFormation resource can pull in that content artifact and perform the appropriate sync operation with the target bucket.

[bjornadolfsson]

+1

[rmmeans]

I like the spirit behind this idea! A very common task that many orgs have to do frequently and there are multiple steps involved.

I would suggest one more feature to add to your list:

• Custom Header Injection
  The ability to automatically setup a L@E function on the CDN that can add headers to the response from the S3 origin prior to being cached. This is a pretty common task now for static sites and one that AWS has blogged about in the past for a lambda@edge use case: https://aws.amazon.com/blogs/networking-and-content-delivery/adding-http-security-headers-using-lambdaedge-and-amazon-cloudfront/

[brettstack]

These are great. Thanks for the input so far!

[kadrach]

I think a CloudFront OAI is preferrable to using a WebsiteConfiguration on an S3 bucket.

[benkehoe]

I'd like CodeUri to be able to be either a list, overlaying multiple directories into the same space, or a map, with the keys being prefixes.

I'm on board with @brysontyrrell that web hosting is less important to me than just deployment of objects.

[faermanj]

Every single page webapp and static generators could benefit (Angular, React, Ember, Jekyll, ... )

[Nr18]

One of the things that i have ran into is that i needed to set the ContentType to text/html and so on else CloudFront will force download the file from S3.

@brettstack do you have a general idea how this feature will work in SAM and what we can do to help out?

[brettstack]

@Nr18 I have a general idea as I've done this setup before. This repo by Eric Hammond is similar to what we have in mind https://github.com/alestic/aws-git-backed-static-website.

There was also the recently released Amplify Console https://aws.amazon.com/about-aws/whats-new/2018/11/announcing-aws-amplify-console/ so we want to consider this as an option, e.g you can set Provider to "AmplifyConsole" to use that, or leave it blank to default to having SAM create all the necessary resources for you (S3, CloudFront, Route53, etc.) if you want more control.

We're still gathering feedback and customer requirements, but I will tell you that this is one feature I'm particularly excited about and will check back in when I have an RFC.

[AlexHarper]

Would this be applicable to static content for dynamic websites?
I recently ported our registration system to a "razor pages" (lightweight dotnet core) project running as a lambda. We're trialing this at the moment as it potentially provides a much simpler way of deploying some of our sites, but serving assets (images, fonts, pdfs) via lambda is a bit wasteful. It would be great if there was an in built way to split the hosting of dynamic content and static content.