Terraform Projects: Real Infrastructure, Real Skills
A collection of real-world Terraform projects. I built each one to solve a practical problem, not just to check off a skill. Here’s what you’ll find:
I started this repo to get hands-on with Terraform and cloud infrastructure. Each project is a real scenario I wanted to tackle, not just a demo. I ran into plenty of edge cases, and I learned a lot about how AWS and Azure behave in practice. Here’s a deeper look:
1. Postgres RDS Database with Automated Backups
I wanted a reusable module for AWS RDS. It spins up a Postgres instance, handles subnet groups, security, and tags. Input validation is baked in, so you can’t accidentally deploy to the wrong subnet or skip backups. Automated backups are set up by default. The module is ready to drop into any project.
One thing I learned: AWS RDS instances need to be in different availability zones. If you try to create them in the same AZ, you’ll get an error. I also spent time making sure the module validates user input, so you don’t end up with a broken setup. The module is flexible, but strict where it matters.
Tech: Terraform, AWS RDS, VPC, subnets, security groups, input validation
2. Site-to-Site VPN: AWS <-> Azure
This project sets up a full site-to-site VPN between AWS and Azure. It uses IPsec tunnels for secure traffic, with high availability (dual tunnels, dual gateways). Both clouds get their own networking configs, and the VPN lets private VMs talk to each other. I handled static and dynamic routing (BGP), and made sure failover works. The README has diagrams and real output from deployed resources.
Setting up a VPN between AWS and Azure isn’t as simple as following the docs. Azure doesn’t let you set a global location like AWS does, so you have to use variables or locals. I also had to deal with differences in how each cloud handles gateways and tunnels. Getting BGP to work for dynamic routing took some trial and error. I made sure the setup is resilient—if one tunnel drops, traffic switches over automatically.
The project includes screenshots and real output from deployed resources, so you can see what actually happens when you run it. I wanted to make the docs as clear as possible, since cross-cloud networking can get confusing fast.
Tech: Terraform, AWS, Azure, IPsec, BGP, VPC, Virtual Network Gateway, high availability
3. Multi-Environment Deployment: Dev, Staging, Production
I built a setup that uses Terraform workspaces to keep dev, staging, and production isolated. Each environment gets its own S3 buckets and state. The code stays DRY—one module, three environments. This makes CI/CD easier and keeps production safe from experiments. The README explains how to run it and what I learned about workspace management.
Managing multiple environments is a must for any real project. Terraform workspaces let you keep state separate, so you don’t accidentally overwrite production when testing in dev. I set up the project so each environment gets its own resources, and the naming makes it clear what belongs where. The docs cover how to use workspaces and tfvars files to keep things organized.
CI/CD is easier when your infrastructure code is DRY and parameterized. I learned that keeping everything in one module, and just swapping parameters, cuts down on mistakes and makes maintenance simpler.
Tech: Terraform, AWS S3, workspaces, CI/CD, state separation
Every project is documented, with comments and screenshots. I focus on practical details: input validation, high availability, and real deployment output. If you want to see how I approach infrastructure as code, this repo is a good place to start.
If you’re curious about the nitty-gritty, check out the READMEs and the code. I try to keep things honest—what works, what doesn’t, and what I had to fix along the way. Infrastructure is messy, but that’s where the real learning happens.