4 AWS tips I wish I had known sooner

If you haven't read it yet, I invite you to check out my article on the AWS services I use the most on a daily basis, published a few weeks ago, right here.

Over the years, and by running into new challenges when hosting my projects, I've gotten into the habit of noting down the tips that sometimes saved my life (or at least many hours), and today I've decided to share them with you.

#1 - Free storage

If you're like me, and using AWS's Free Tier is your national sport, I know you won't turn down a few free Gigs of storage.

Because yes, when you spin up an EC2 instance (T2.micro) eligible for the free tier, Amazon encourages you to leave the default configuration and launch the instance with a single click.

But if you take the time to look at the storage tab, you'll see that the default volume size is 8GB, whereas you can go up to 30GB while remaining eligible for the free tier. It's a gift!

#2 - More RAM for the same price

It's not uncommon for an installation inside a Micro EC2 instance to be interrupted due to a lack of RAM, especially when going through NPM, because yes, 1GB of RAM to run the system plus an installation that sometimes takes up several GB of storage is just too little.

The solution is simply to use part of the 22GB of storage you just gained with the previous tip and turn it into a swap file.

A swap file is a file that extends the memory usable by the operating system. Its performance is necessarily lower than "real" RAM, and I don't recommend relying on it to allow a program to run robustly, but for the duration of an installation, it saves you from having to pay for a more powerful instance!

Here's a simple tutorial for setting up a swap file on linux: https://linuxize.com/post/create-a-linux-swap-file/

#3 - One IP to rule them all

When you use the url (or IP) provided by EC2 for your instance, you might think you're safe from trouble in case the instance restarts... well, not at all.

If your instance crashes for any reason, it will be restarted, yes, but under a different IP (and therefore a different url), generated by AWS.

The (free) solution is therefore to assign a fixed IP (available in the EC2 menu) to your instance once you're done configuring it. That way, no more issues with an inaccessible instance after an unexpected restart!

#4 - The bucket or the url, that is the question

One of my favorite features on AWS is static site hosting using AWS S3 + Cloudfront.

However, it sometimes happens that the hosted site is perfectly accessible on the first visit, but you run into an error from your bucket (indicating that the resource doesn't exist) when you refresh the page.

The solution is very simple: you just need to NOT link your bucket to your Cloudfront origin by clicking on the bucket name in the dropdown list, but rather copy-paste the url provided by S3 when enabling static hosting on the bucket.