🦄 Modernizing Wild Rydes with modern technologies

How I rebuilt the classic AWS Wild Rydes serverless app with Terraform, GitHub Actions, S3 + CloudFront, OIDC, and a modern Vite frontend — no console required.

title: 🦄 Modernizing Wild Rydes with modern technologies published: true description: How I rebuilt the classic AWS Wild Rydes serverless app with Terraform, GitHub Actions, S3 + CloudFront, OIDC, and a modern Vite frontend — no console required. tags: aws, terraform, serverless, devops

Wild Rydes was an old project used by AWS hands-on labs to show how to deploy a serverless application using its services. It consists of a Uber-like application where you would request rides by UNICORNS (🦄). In the following article I will guide you in how I implemented this project using modern technologies like Terraform, Github Actions and OpenID Connect.

The original stack consisted of Cognito for adding an authentication layer, Amplify for deploying the application, Lambda and DynamoDB for the business logic of the app, CodeCommit as a repository and IAM for adding roles and permissions for the interaction between services. You would have to configure all these services manually and at the end you would want to remove them to avoid charges. The core project was using plain HTML/CSS and jQuery for the frontend.

The new Stack at Glance

The original stack relied on Amplify for deployment and CodeCommit as a repository. I wanted more control over the infrastructure and a better CI/CD experience, so I replaced Amplify with S3 + CloudFront to deliver the app, moved to GitHub to take advantage of Actions, and added Terraform to manage all the resources. Cognito, API Gateway, Lambda and DynamoDB stayed.

Updating the frontend

The project was using HTML/CSS and jQuery. I wanted to use modern technology for delivering the frontend, so I chose Vite for bundling. It allowed me to use multiple commands to manage the app like vite build for generating a bundle with optimized assets.I found that multiple CSS statements needed to be changed and the map library used in the app for picking a ride was outdated, so I migrated to a modern one. After a couple of hours of troubleshooting, the frontend was ready.

Vite also allowed me to use environment files (.env) for credentials like Cognito's keys and API Gateway's endpoint, which solved the hardcoded credentials problem from the original project. This provides better security for the project or If I want to implement multiple environments.

Creating infrastructure using Terraform

The original labs would guide you to use the AWS Console for creating resources. I wanted to use Terraform for creating those resources instead, so every change was tracked, repeatable, and easy to tear down. I made a little change in the project — instead of using Amplify, I was going to use S3 + CloudFront to deliver the app. I made this decision because I wanted to use another approach for building serverless apps. You could keep using Amplifly.

S3 as Backend for Terraform

A good practice in Terraform is creating a backend to store your Terraform state. A state file stores the attributes and resources created by Terraform, allowing it to understand what exists in your infrastructure and what changes need to be made during updates. Storing it remotely meant the state was safe, shared, and not sitting on my local machine.

This is a sensitive matter, so precautions had to be taken. Recent updates to Terraform introduced the option to use an S3 bucket to safeguard the Terraform state. A good practice for an S3 bucket is to enable versioning for keeping track of changes to object content, server-side encryption to provide another layer of security, and also disable public access.

Ditching stored credentials with OIDC

I created a workflow in GitHub Actions to perform deployment to S3 and invalidate the cache in CloudFront. I started by creating AWS access keys so S3 and CloudFront commands would authenticate, but before writing this article I found a different approach that consisted in using OpenID Connect. This allowed access to AWS resources without storing AWS credentials as secrets — instead, the workflow requested a short-lived OIDC token from GitHub and presented it to IAM as a temporary role.

[EDIT]: I forgot to add the github repository. In case you want to reproduce it here is the link: https://github.com/cferreirasuazo/wildrydes-aws