The Nostalgia: Deploying Snake Xenzia Game on S3 using Terraform

6 min readOct 18, 2023

Remember the good old days when mobile phones were just phones, and the most exciting thing they could do was play Snake? Ah, the nostalgia! It’s time for a trip down memory lane with a modern twist. In this blog, we’ll combine the charm of Snake Xenzia with the power of Amazon Web Services (AWS). Get ready for a delightful journey!

Github Repo Link.

Table of Contents —

∘ Pre-requisites
∘ Setting-up the playground
∘ Step 1 — Configure the AWS Provider & Remote State Backend
∘ Step 2: Create the AWS S3 Bucket
∘ Step 3: Configure the Website for the Bucket
∘ Step 4: Allow Public Access to the Bucket
∘ Step 5: Create an IAM Policy for Resource Access
∘ Step 6: Clone GitHub Repository and Upload to S3
∘ Step 7: Create an Alias Record for Website Subdomain
∘ Final Step : Running our code
∘ Clean-up the resources
∘ Conclusion

Pre-requisites

Before we get started, make sure you have the following:

An AWS account with appropriate permissions.
Terraform installed on your local machine.
A website domain
Basic knowledge of Terraform.
s3 bucket for state management (versioning and encryption enabled)
DynamoDB Table for state lock

Below is the architecture diagram of all the services we’re going to use for our project.

Setting-up the playground

First, we need to configure our DNS provider (GoDaddy in my case) with Amazon Route53, because we’ll be hosting the game on our website’s sub-domain.

Create a hosted zone in Amazon Route 53.

2. Now, we’ll add nameserver Route53 records to our DNS provider so that AWS Route53 has full control over routing capabilities of our domain.

Copy the nameservers (without the dot at the end).

Add these to DNS Nameservers. For GoDaddy (Go to DNS Management > Nameservers > Change Nameservers > Select “I’ll use my own nameservers” > Add all nameserver records from Route53 and Save)

Now, we’re ready to dive into writing our terraform code to host the nostalgic game on our subdomain (snake-xenzia.deepakworks.xyz).

Step 1 — Configure the AWS Provider & Remote State Backend

We begin by configuring the AWS provider in our Terraform code. This is where we specify the AWS region we want to use for our infrastructure. For this example, we’ll use a variable for the region, allowing flexibility.

Note — All the variables are mentioned at the end in variables.tf file

Using s3 as backend —

Terraform state files are crucial for managing infrastructure. They keep track of the current state of your resources and help Terraform understand what changes need to be made. When working with AWS, it’s a good practice to store your state files in a reliable and secure location. Amazon S3 is an ideal choice for this purpose. It should be defined in terraform.tf file.

Create a s3 bucket with versioning and encryption enabled.

Using DynamoDB for State Locks

Terraform state locks are a mechanism for preventing concurrent modifications to your state files. In essence, state locks ensure that only one entity at a time can make changes to the Terraform state.

To implement state locks in Terraform, one of the most effective methods is by using an AWS DynamoDB table. (LockID should be used as partition key). Here’s a snippet of Terraform configuration that sets up an S3 backend for state files with DynamoDB-based locks:

Step 2: Create the AWS S3 Bucket

Now, let’s create the AWS S3 bucket that will host our static website. We configure various settings for the bucket, such as enabling force destroy and adding tags.

Make sure your bucket name is same as your subdomain.
For example — If your domain is “example.com” and subdomain is “snake-xenzia”, then the fully qualified domain name (FQDN) will be — “snake-xenzia.example.com”. Hence, your bucket name should be same as FQDN. In my case, It’s “snake-xenzia.deepakworks.xyz”

Step 3: Configure the Website for the Bucket

To serve a static website from the S3 bucket, we need to configure the website settings. This includes specifying the index document, which is the default page when users access your website.

Step 4: Allow Public Access to the Bucket

For your website to be accessible to the public, we need to ensure that public access is allowed. We configure this by adjusting the settings of the S3 bucket.

Step 5: Create an IAM Policy for Resource Access

In the following steps, we’ll clone our GitHub repository and copy the contents to the S3 bucket. To allow this, we set up an IAM policy that permits access to our S3 resources. We define the policy document as follows:

Step 6: Clone GitHub Repository and Upload to S3

Now, we’re ready to clone our GitHub repository, copy its contents to our S3 bucket, and then clean up the local repository.

provisioner “local-exec” is used to execute the command on our local machine.

We should clean up the repo folder (git-code) after we have copied all the files to s3 bucket.

Step 7: Create an Alias Record for Website Subdomain

In the final step, we create an alias record in AWS Route 53 to map the website subdomain to our S3 bucket.

data block is used to get the information about our hosted zone we created in the setting-up section.

Variables and Outputs

To keep our code clean and reusable, we ensure that all our variables are stored in a separate file “variables.tf”.

We’ll output our website endpoint so that we can easily hit it in the browser and see our nostalgic game in action.

Final Step : Running our code

First, we need to initialize our terraform providers by running -

terraform init

Now, Let’s format and validate our code.

terraform fmt
terraform validate

Let’s check what resources we’re going to add in AWS by running —

terraform plan

Finally, the moment has arrived to apply our changes and witness the magic of Terraform in action.

terraform apply --auto-approve

Upon successfully executing this command, we’ll get the following output (our game’s website endpoint)

Now, let’s hit this endpoint into our browser to check if our game is live or not.

Game in browser using subdomain endpoint

Voilà! Our game is live, and now we can dive into it, just like we did during our childhood, spending hours aiming for the highest score.

Clean-up the resources

Be sure to tidy up all the resources deployed in this project to prevent unnecessary AWS charges. You can achieve this by executing the following command:

terraform destroy

Conclusion

And there you have it! We’ve combined the nostalgia of Snake Xenzia with the power of AWS. We’ve set up our gaming arena, configured access, and invited the world to play. So go ahead, relive those Snake Xenzia memories, and create your own cloud gaming adventures. Don’t forget to share your high scores in the comments section!

See you in the next one.

If you’ve discovered any value or gained insights from this blog, I would greatly appreciate it if you could show your appreciation by giving this story a clap.

Please feel free to reach out to me on LinkedIn with any questions, or you can drop them into the comment section below. I would be more than happy to assist you.

Follow for more :)