In the previous post we walked through migrating a flat Terraform project to modules and used moved blocks to shift existing state to the new addresses without destroying anything. This post uses that same project for an exploration of common situation: what if those resources had never been managed by Terraform at all?
This post covers both Lambdas in the system: the subscribe Lambda that handles subscribe, confirm, and unsubscribe flows, and the poller that runs daily to email confirmed subscribers when a new post goes out.
With the CI pipeline handling authentication and execution, the Terraform itself can stay focused on what it actually needs to build. This post walks through every resource - what it is, how it connects to the rest of the system, and a few design decisions worth explaining.
Getting Terraform to run in CI without storing AWS credentials anywhere is one of those things that sounds complicated until you understand the pattern. This post covers how GitLab authenticates to AWS using OIDC, and how the CI pipeline is structured to plan on any branch and apply only on main.
I wanted a way for readers to get notified when a new post drops. I looked at the SaaS options Mailchimp, ConvertKit, Buttondown, and they all work fine. But I'd be handing subscriber data to a third party and paying for a service I could build myself. So, I built it. This is the first in a series of posts covering how it works.
Keep the coffee flowing