{"componentChunkName":"component---src-templates-blog-post-js","path":"/serverless-website-sam-aws-part-2/","result":{"data":{"site":{"siteMetadata":{"title":"Fabrizio Fortunato","author":"Fabrizio Fortunato","siteUrl":"https://izifortune.com"}},"markdownRemark":{"id":"9d30df88-9952-5c49-a61d-801e94757f59","excerpt":"In one of my previous articles Build a serverless website with SAM on AWS,\nI’ve explained how we can start creating a serverless website and what are the…","html":"

In one of my previous articles Build a serverless website with SAM on AWS,\nI’ve explained how we can start creating a serverless website and what are the\nadvantages of adopting a serverless architecture. Through sam-cli and\nCloudformation templates we created an S3 bucket and a Cloudfront\ndistribution. Now we will extend the previous architecture adding more\nfunctionality to our serverless website

\n

In this article, we will explore how to create path rewrites (mod rewrites) and\nsecurity headers using Lambda at the Edge (L@E). We will finish then attaching a\ncustom domain name and taking care of assets caching to improve the performance of\nour serverless website.

\n

Rewrites

\n

Following the previous article, we have our website infrastructure at this point\nand its deployed in AWS. Cloudfront is acting as a web server for your website\nand forwards the requests to the origin following the behaviours declared\nbefore. When navigating to HTML pages a classical webserver applies a series of\nrewrites to the request before fetching the necessary resources. A good\nexample is mod_rewrite for Apache, in fact, we never request the homepage of a\nwebsite using a full resource location such as\nwww.izifortune.com/index.html but\nrather using a shorter format like www.izifortune.com. Cloudfront provides\nsome basic functionalities using DefaultRootObject: index.html attribute,\nwhich will point to a root index.html when we are not specifying any path in the\nURL.

\n

Once we start supporting multiple pages on our website, using\nDefaultRootObject is not enough, to rewrite all the possible paths. A custom\nsolution is needed that can mimic a behaviour similar to mod_rewrite.

\n

\n \n \n \n \n

\n

We can use Lambda at the Edge (L@E) to\nimplement our custom business logic between Cloudfront and the origin, in our\ncase S3 Bucket. L@E is a functionality of Cloudfront that lets you run our\ncode on the edge. An edge is a Cloudfront Regional\nCache. You can use\ndifferent runtimes but mainly you are restricted to use node or python for the\nfunctions and you can see a full list of requirements and restrictions for L@E\nhere.\nIn the article, we will be using node runtime for the example functions.

\n

The rewrite functionality can be then implemented with the following code:

\n
'use strict'; exports.lambdaHandler = async (event) => {\n\n  // Extract the request from the CloudFront event that is sent to\n  Lambda@Edge const request = event.Records[0].cf.request;\n\n  // Extract the URI from the request const olduri = request.uri;\n\n  // Match any '/' that occurs at the end of a URI. Replace it with a\n  default index const newuri = olduri.replace(/\\/$/, '\\/index.html');\n\n  // Replace the received URI with the URI that includes the index page\n  request.uri = newuri;\n\n  // Return to CloudFront return request;\n};
\n

Save the lambda at the edge code using the following structure: rewrite/app.js\nand then add the lambda as a resource, together with the necessary role, inside\nthe template.yaml

\n
    ... \nResources:\n    ... \n    \n  LambdaEdgeFunctionRole:\n    Type: \"AWS::IAM::Role\"\n    Properties:\n      Path: '/'\n      ManagedPolicyArns:\n        - \"arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole\"\n      AssumeRolePolicyDocument:\n        Version: \"2012-10-17\"\n        Statement:\n          -\n            Sid: \"AllowLambdaServiceToAssumeRole\"\n            Effect: \"Allow\"\n            Action: \n              - \"sts:AssumeRole\"\n            Principal:\n              Service: \n                - \"lambda.amazonaws.com\"\n                - \"edgelambda.amazonaws.com\"\n\n  RewriteLambda:\n    Type: AWS::Serverless::Function\n    Properties:\n      CodeUri: rewrite/\n      Description: 'Serverless rewrite lambda'\n      Handler: app.lambdaHandler\n      Runtime: nodejs12.x\n      MemorySize: 128\n      Timeout: 1\n      Role: !GetAtt LambdaEdgeFunctionRole.Arn\n      AutoPublishAlias: live\n    ...
\n

We now need to attach the function to Cloudfront, so that it will be possible to\nintercept the requests and rewrite to the relevant resources. A L@E can be\nattached at different points in a request flow:

\n

\n \n \n \n \n

\n

The hooks provided by Cloudfront are divided into Viewer and Origin and then\ndivided once more by request and response:

\n\n

If you want to read more about how to use the hooks you can visit the page\nCustomzing Content at the Edge.\nIn our example, we will attach the L@E to an Origin Request.

\n
...\n  WebsiteCloudfrontDistribution:\n    Type: \"AWS::CloudFront::Distribution\"\n    Properties:\n      DistributionConfig:\n        Aliases:\n            - <ADD YOU ALIASES HERE>\n        Comment: \"Cloudfront distribution for serverless website\"\n        ViewerCertificate:\n          AcmCertificateArn: <CERT HERE>\n          MinimumProtocolVersion: TLSv1.1_2016\n          SslSupportMethod: sni-only\n        DefaultRootObject: \"index.html\"\n        Enabled: true\n        HttpVersion: http2\n        Origins:\n          - Id: s3-website\n            DomainName: !GetAtt Bucket.DomainName\n            S3OriginConfig: \n              OriginAccessIdentity: \n                Fn::Sub: 'origin-access-identity/cloudfront/${CloudFrontOriginAccessIdentity}'\n        DefaultCacheBehavior:\n          Compress: 'true'\n          AllowedMethods:\n            - GET\n            - HEAD\n            - OPTIONS\n          ForwardedValues:\n            QueryString: false\n          TargetOriginId: s3-website\n          ViewerProtocolPolicy : redirect-to-https\n          LambdaFunctionAssociations:\n            - EventType: origin-request\n              LambdaFunctionARN: !Ref RewriteLambda.Version
\n

Noticed that we can only attach a specific Version of the function in\nCloudfront. Using the attribute AutoPublishAlias:live in the lambda\ndefinition SAM takes care of publishing and giving us the latest version.

\n

We can start testing out the lambda packaging and deploying it with SAM. Since\nwe will need a package and deploy multiple times we can create scripts to avoid\nrepeating long commands:

\n
# package.sh sam package --output-template-file packaged.yaml --s3-bucket\n<YOURSWEBSITE.COM>-sam\n\n# deploy.sh sam deploy --template-file packaged.yaml --stack-name\n<yourwebsite> --capabilities CAPABILITY_IAM --region us-east-1\",
\n

And then proceed to invoke the commands:

\n
sh package.sh && sh deploy.sh
\n

Security headers

\n

While developing a website it is important to consider also security for the\nwebsite itself and our users. Today’s standards include having your website\nusing HTTPS protocol which you can achieve by attaching a valid certificate to\nCloudfront distribution which we will see later when looking to add a domain. A\nsometimes overlooked practice which can boost the security of your website is\nusing correct security headers. A full list of headers can be found in the\nOWASP Secure Headers\nProject.\nHTTP headers can be used to restrict modern browsers from running\nvulnerabilities.

\n

Attaching headers to a response is the job a web server but in our case, we\ndon’t have any. That’s where a L@E can help us out. Using the Viewer Response\nhook, which triggers before Cloudfront return the response we can add the\nadditional security headers to the response.

\n

\n \n \n \n \n

\n

The function below contains all the necessary logic:

\n
exports.lambdaHandler = async (event) => {\n  const { Records: [{ cf: { response } }] } = event;\n\n  if(response.headers['content-type'] && response.headers['content-type'][0].value.indexOf('text/html') < 0 ||\n    response.headers['location']) {\n    return response;\n  }\n\n  response.headers = {\n    ...response.headers,\n    ['strict-transport-security']: [{key: 'Strict-Transport-Security', value: 'max-age=63072000; includeSubdomains'}],\n    ['x-content-type-options']: [{key: 'X-Content-Type-Options', value: 'nosniff'}],\n    ['x-frame-options']: [{key: 'X-Frame-Options', value: 'SAMEORIGIN'}],\n    ['x-xss-protection']: [{key: 'X-XSS-Protection', value: '1; mode=block'}],\n    ['referrer-policy']: [{key: 'Referrer-Policy', value: 'same-origin'}],\n  };\n  return response;\n};
\n

Similar to the previous L@E that we created for rewrites we need now to create a\nResource and attach the L@E to our Cloudfront distribution.

\n
..\n  WebsiteCloudfrontDistribution:\n    Type: \"AWS::CloudFront::Distribution\"\n    Properties:\n      DistributionConfig:\n        Aliases:\n            - <ADD YOU ALIASES HERE>\n        Comment: \"Cloudfront distribution for serverless website\"\n        ViewerCertificate:\n          AcmCertificateArn: <CERT HERE>\n          MinimumProtocolVersion: TLSv1.1_2016\n          SslSupportMethod: sni-only\n        DefaultRootObject: \"index.html\"\n        Enabled: true\n        HttpVersion: http2\n        Origins:\n          - Id: s3-website\n            DomainName: !GetAtt Bucket.DomainName\n            S3OriginConfig: \n              OriginAccessIdentity: \n                Fn::Sub: 'origin-access-identity/cloudfront/${CloudFrontOriginAccessIdentity}'\n        DefaultCacheBehavior:\n          Compress: 'true'\n          AllowedMethods:\n            - GET\n            - HEAD\n            - OPTIONS\n          ForwardedValues:\n            QueryString: false\n          TargetOriginId: s3-website\n          ViewerProtocolPolicy : redirect-to-https\n          LambdaFunctionAssociations:\n            - EventType: origin-request\n              LambdaFunctionARN: !Ref RewriteLambda.Version\n            - EventType: viewer-response\n              LambdaFunctionARN: !Ref SecureHeadersLambda.Version
\n

We have to package and build our SAM application once again:

\n
sh package.sh && sh deploy.sh
\n

Caching

\n

A proper caching strategy is essential for any website no matter the number of\nvisits per day. Defining caching for your assets can really make the difference\nfor your users, which they will save bandwidth and improve performance. A\nrequest in fact doesn’t need to be fetched from the origin every time.\nCloudfront honour the Cache-Control header of a response and it will keep the\nrequested asset in a regional cache until the cache duration\nexpires.\nMoreover, it can reduce the load to our servers, or in our case our bill, since\nwe are paying every request that arrives at the S3 Bucket. If you want to read\nmore about Cache-Control header I can’t recommend enough the article from\n@csswizardry Cache-Control for\nCivilians.

\n

While Cloudfront allows to overrides the Cache-Control headers through a\nbehaviour, I normally recommend setting a Cache-Control header on an object\nbase level rather than through a behaviour. This way you don’t need to manage\nmultiple behaviours on different objects.

\n

Cloudfront can read the object metadata, specifically the Cache-Control\nmetadata that is set in an S3 asset and will use it as Cache-Control header\nfor the response.

\n

Depending on the assets that you are uploading you can have a different\nCache-Control associate to them.

\n
aws s3 sync public/ s3://<YOURSWEBSITE.COM> --cache-control \"public, max-age=604800, must-revalidate\" --acl \"public-read\" --exclude \"*\" --include \"*.html\" --include \"*.xml\" --include \"sw.js\" --include \"robots.txt\" --include \"favicon.ico\" --include \"manifest.webmanifest\" --include \"idb-keyval-iife.min.js\"\n\naws s3 sync public/ s3://<YOURSWEBSITE.COM> --exclude \"*.html\" --exclude \"*.xml\" --exclude \"sw.js\" --exclude \"robots.txt\" --exclude \"favicon.ico\" --exclude \"manifest.webmanifest\" --exclude \"idb-keyval-iife.min.js\" --cache-control \"public,max-age=31536000,immutable\" --acl \"public-read\"
\n

We are caching here the HTML pages for 7 days and all the other assets instead\nfor 1 year.

\n

Domain name

\n

Now that the basic resources are defined I want to have a closer look at how to\nlink your domain name to a serverless infrastructure. I will take advantage of\nAWS Route 53 to generate the necessary RecordSet and Certificate Manager\nto create an SSL certificate. If you don’t have your domain registered in AWS\nyou simply need to change the Nameservers to point to your public hosted zone\nwhich you will create.

\n

There is one manual step which I’m keeping outside of the final template, the\nSSL certificate creation. The certificate needs to be validated through email or\nDNS for the domains specified and it will fail to create the Cloudfront\ndistribution if it is not verified. For this reason, you can simply go to\nhttps://console.aws.amazon.com/acm/home?region=us-east-1#/\nand register a new certificate. Make sure the region is N.Virginia because\nCloudfront will only accept certificates from that region. If you want to\nserve your website using www remember to include it also inside the list of\nthe accepted domains.

\n

\n \n