{"id":1467,"date":"2020-06-26T00:14:36","date_gmt":"2020-06-25T22:14:36","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=1467"},"modified":"2021-03-24T12:08:50","modified_gmt":"2021-03-24T11:08:50","slug":"hosting-a-static-site-on-aws-is-cloudfront-always-the-right-choice","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/hosting-a-static-site-on-aws-is-cloudfront-always-the-right-choice\/","title":{"rendered":"Hosting a static site on AWS: is CloudFront always the right choice?"},"content":{"rendered":"

Introduction<\/span><\/h2>\n

Binomial services CloudFront<\/strong> and S3<\/strong> are nowadays part of consolidated practices for many companies that have the necessity of hosting a static website (or part of it) while keeping its costs low without sacrificing security standards<\/strong> (eg: SSL termination on proprietary domain). But is this the only way pursuable? Are there any other means by which we can achieve the same result by also solving other necessities? This article tries to give an answer to that!<\/span><\/p>\n

Problem<\/span><\/h2>\n

Imagine you have to handle the following need: your company’s frontend team requests testing a freshly developed feature on a production-like infrastructure to show and verify that the result is somewhat the one expected for the release. In particular, it would like to have a different domain name for every feature developed in order to avoid path related inconsistencies.<\/span><\/p>\n

Even without some calculator at hand to predict costs of managed traffic, it is crystal clear that maintaining different CloudFront distributions for every feature and every frontend project can lead to useless complications from an AWS account\u2019s management perspective. It is worth mentioning that it\u2019s currently impossible to create two different origins from the main path and link them to two distinct domains within the same CloudFront distribution without incurring in a possible redirect that would lead to path problems mentioned above.\u00a0<\/span><\/p>\n

Solution<\/span><\/h2>\n

At first, we must notice that these deploys have an effimere nature. This means that a relatively short time of creation and removal for these infrastructural elements must be respected. To reach this goal it’s useful to share the same resources between more than one interlocutors to minimize overhead.\u00a0\u00a0<\/span><\/p>\n

The proposed solution is made thanks to the following infrastructural elements:<\/span><\/p>\n