View the finished product here!

View the code on GitHub.

Setup and Safety

This wasn't a mod per se, but there was a recommended "professional" approach for creating new AWS accounts. I set up a main / billing AWS account specifically for this project and then used AWS Organisations to create development and production accounts. My code would first be deployed to the dev account and once I was happy with how it looked and functioned, it would get promoted to production. One of the goals I had for the project was to avoid using access and secret keys. To achieve this, I set up Identity Centre and configured the AWS CLI on my local machine to use single sign-on. For authenticating my GitHub workflows, I created IAM OIDC Identity Providers in the development and production accounts, so I wouldn’t need to store AWS credentials as secrets.

My DNS configuration is a little complicated. My domain wasn't purchased from AWS, and I wanted to have a dedicated subdomain / child zone for my test environments. After some experimentation I settled on hosting my primary domain (patrickdrew.com) in Route 53 of my production account, then created a NS record pointed at a child domain (test.patrickdrew.com) hosted in R53 of the test account. I then updated the name servers for the primary domain with my DNS registrar.

This account setup is partially automated using the open-source tool, org-formation. When commencing the challenge, it didn’t occur to me I could have automated the Identity Centre and Route 53 pieces of the project as well, otherwise, I would have included them in my org-formation template.

Chunk 0: Certification Prep

Before starting the challenge, I'd achieved the AWS Solutions Architect - Associate, AWS Solutions Architect - Professional and the Red Hat Certified Systems Administrator certifications. After roughly twelve months grinding on the certificate mill I was a little burnt out from studying so I opted out of the Security Mod (achieving the AWS Security Specialty Certificate).

Chunk 1: Building the Front End

It had been a while since I'd done any front-end development, and I was looking forward to digging into some new technologies. I'd used Angular at work but had never stepped foot in the React world, so I implemented the resume using Next JS. Tailwind CSS was my choice for styling the site. For my first pass, I wrote the bulk of the markup in a single page, then iteratively broke out each section (work experience, certifications, projects etc.) into individual React components. This made using Tailwind's utility CSS classes much less repetitive. I then converted the front end to TypeScript. Data fetching from the back-end API was implemented with the SWR library, allowing the site to retrieve the latest visitor count without refreshing the page.

Chunk 2: Building The API

I collaborate with teams that are creating AWS lambdas using .NET but had never done it myself, so I chose to write the back end in C#. I stuck with using DynamoDB for the database since NoSQL technologies were new to me and I've worked with SQL Server / RDBMS for some time. The back-end lambda was implemented using ASP.NET Minimal APIs.

For the DevOps Mod, I set up CloudWatch Alarms for lambda throttling and API Gateway latency metrics. These alarms publish to an SNS topic. I created another lambda in C# that subscribes to the SNS topic and sends a notification to a Slack webhook. The text of the notification includes a delightful flame emoji, sparking joy whenever I receive a deluge of alerts via Slack as the site gets crushed by seemingly modest amounts of traffic (jk, the site gets zero traffic).

Chunk 3: Front End / Back End Integration

The developer mod for this chunk requires the API to count unique visitors rather than individual page hits. As recommended in the guide, I hashed the visitor's IP address to avoid storing personal identifying information in the database. I wanted to understand best practices for computing aggregates in Dynamo DB, so I created a Dynamo Stream and integrated it with a Lambda function. Each time a record representing a visitor was created or updated, the lambda would increment a record with unique visitor counts and total site visits for the current month. Using Dynamo's TTL feature, visitor records would be deleted at the end of the month, so the table is kept as compact as possible while retaining snapshots of the past months' visitor statistics.

WAF rules were outside the scope of my project's budget, so I went the quick and dirty route of enabling throttling and rate limiting on my API gateway for the security mod (but if this was a production web app for a paying client, I'd consider them essential). I'm going to be generous and give myself a 50% passing mark on this one.

Chunk 4: Automation / CI

The teams I support at work use the AWS CDK with C#, so I decided to do the same for the infrastructure as code piece of the challenge. When a pull request is opened against the main branch of my repository, a GitHub action will deploy a new instance of the stack in a test account. These preview environments get a unique URL, Dynamo DB table and other AWS resources required to run the site. Resource names are unique and prefixed with the pull request number, meaning multiple preview environments can exist side by side in the same account. If the pull request gets updated with the new code, the environment gets updated by automation. When the pull request is approved and merged into the repository's main branch, the code gets deployed into the production AWS account. When the pull request is closed (approved or denied), the preview environment gets destroyed by another GitHub Actions workflow.

The combined developer / security mod involved securing the software supply chain of the project. As part of this mod, I investigated signing my Lambda code. I was surprised to discover that CloudFormation / CDK did not have a native feature supporting this. To achieve the desired result, I needed to create a custom CDK resource that calls the AWS code signing API to create a signing job for my lambda code. I then used the S3 object written by the signing job as the code asset for my lambda function. This way I could sign my lambda for the backend API at deploy time and fail the deployment if the code isn't signed. I found it challenging to figure out how custom resources work in the CDK and was excited when I got it to work without resorting to a third-party package (which is just as well, because I couldn't find one for dotnet!).

Conclusion

It was fun working through the challenge and I was stretched by many of the mods. The project allowed me to apply the knowledge from my recent certifications, dabble in some new technologies and get reacquainted with some old ones. I found the experience worthwhile and would recommend it to both new and seasoned technologists alike.