Published 2021-09-23 - Listen on your favourite podcast player
In this episode Eoin and Luciano talk about static websites. What are the main requisites for a static website, where to host them and how to do it in AWS. Finally we touch on some common gotchas and tools that can make it easier for you to deploy static websites on AWS (spoiler: Amplify!).
In this episode we mentioned the following resources:
Eoin: Hello and welcome to another episode of AWS Bites, the weekly show where we answer questions about AWS in about five minutes. My name is Eoin and I am joined by Luciano. Today's question is how do you deploy a static website on AWS? So Luciano, what do you think? First of all, when you want to deploy a static website, what are your requirements or must-haves?
Luciano: Yeah, that's actually a very good first point to try to answer to. To me, when you deploy a static website, the first thing that you need is definitely the storage. Like where do you store the static assets? Then of course there is an element you need to make them available through HTTP and HTTPS. So all the certificates and domains, and even better if you have something like a CDN, which will do global distribution so you have very quick access for users all around the world. So those for me are the main requirements that you should have for a static website. I guess this is an interesting topic because it's not very common in my opinion to do this in AWS. Like I've seen a lot of people use a bunch of other services. What do you think? Would you use AWS? Would you use other services?
Eoin: Yeah, it definitely depends. I've done it in AWS quite a lot, but to be honest, if I just wanted to deploy a static website and it didn't really matter what cloud service I had to use, I'd probably just for the sake of speed and efficiency, go with something that is more specialized in that area like Netlify, Frisell, Cloudflare, some of these options because the developer experience and the time to deployment is generally a lot faster. There's a lot less detail you have to think about. But on the other hand, if you've already got AWS infrastructure, you've got deployment pipelines and you're already set up to use identity and access management and cloud formation, all of that great stuff you get with AWS, then it probably makes sense to think, okay, I can manage all of this static website infrastructure in the same way. What do you think?
Luciano: Yeah, no, fair enough. I wouldn't use it for instance, for open source projects. I wouldn't use AWS. I generally use a combination of GitHub pages, maybe with Cloudflare on front of it. But yeah, when it's more corporate environment, I get it that it makes a lot more sense to stick to AWS because you have everything more managed and you can give access to everyone working in the team more easily. So definitely I agree with you on that. So let's try to see what are the options in AWS. Like what would you do if you have to set up a website, would you use S3, would you use something else?
Eoin: Yeah, we've got a reference project called Slic-Starter where we actually have a static website as part of that serverless application suite. The way that we do that typically is with you put your assets into an S3 bucket. So you create a bucket for your website. All of the HTML, JavaScript, CSS, your images get synchronized to that bucket. In front of that, you've got a CloudFront distribution so that it's globally distributed. The access times around the world should be fast. And then we'd integrate it with the AWS certificate manager for HTTPS certificates and also route 53 for your DNS. And that's generally the basic recipe for a kind of modern website infrastructure on AWS. Am I missing anything there?
Luciano: I don't think so, but there is quite a bit of setup, right? So I don't know if there is any common gotcha that you can share. Like to me, I've been beaten in the past by caching invalidation because it's just tricky to get it right. Especially the first time, doesn't really matter. You just publish and it works. When you want to do an upgrade, change a few things on the website and they don't really show up immediately on the website. So that's when it gets tricky and you realize you did something wrong. Did it happen to you?
Eoin: Yeah, it's true. CloudFront has a bit of a bad reputation for the time it takes to synchronize to all the edge locations as well. So you really have to understand that it will take time. It could be five to 10 minutes. I think these days typically to synchronize out your edges and then you have to understand how invalidation works. So that's definitely true. As with all AWS services, you're given a toolkit of resources that you can assemble to build something really great, but you still have to have a reasonable amount of knowledge. So you just have to be prepared to invest a bit of time. I know that AWS Amplify is there to kind of make this easier as well. It's not something I use very frequently. I typically use the Amplify SDK rather than the CLI. Have you heard good things, Luciano, about what the Amplify CLI can do for users starting with this kind of thing for the first time?
Luciano: Yeah, I haven't had the chance to use it myself yet, but few people have recommended it as a much simpler and faster way to deploy static websites to AWS. And especially there are a bunch of additional bits and pieces. Like if you are building a single page application type of website, they make your life easier. For instance, if you want to call Lambdas on the backend because you want to build something more dynamic. So I think you also have an additional layer on top of just plain static websites when you use Amplify. But again, I still have to try it, so I'm not going to spend more time talking about it because I might say something stupid.
Eoin: Fair enough. I mean, there's lots of... As with AWS and everything, there's always many, many ways to do any given task and to achieve a goal. So I know you've got alternatives that have been there for a while, like Elastic Beanstalk, I think is quite popular with agencies deploying websites. You've got LightSail, which is designed for, I suppose, users who just want a simple developer experience. And then you can also deploy your own, right? You can deploy containers with a load balancer. I'm sure you've done that in the past one or two times Luciano.
Luciano: Oh yeah, for sure. I even did it once in a Lambda, which is I think a little bit extreme because of course we have all sorts of limitations that come with the Lambda runtime. But I think for small websites, like maybe you are building a form where we are collecting just few information, that can work quite well. In the Lambda, you can have serving the HTML and the few assets you need and also the backend logic to collect the information for the form. So yeah, maybe it's not by the book how you should do that, but if you're working on a small enough project, that can also be an option.
Eoin: Great. Well, I think what we can do is certainly put some links to everything we've talked about today, some of the services, resources in the description and the show notes. And otherwise that's all for today. So thank you for listening. Let us know what you think in the comments. If you have any further questions, let us know what you'd like us to talk about too. Follow us and subscribe and otherwise we'll see you in the next episode.