Infrastructure-as-Code (IaC) tools, like Terraform, have become essential for managing infrastructure in a scalable, repeatable, and automated way. Terraform helps engineers define, provision, and manage cloud resources across multiple providers. However, as infrastructure complexity grows, managing Terraform configurations becomes challenging. This is where Terragrunt—a thin wrapper for Terraform—comes into play. It enhances Terraform’s capabilities, making it easier to manage large-scale infrastructures efficiently.

In this blog, we will explore how to organize Terraform projects using Terragrunt, and how it solves common challenges with Terraform’s limitations such as managing backend configurations, large state files, and dependencies between multiple stacks.

In this guide, we’ll take you through building a segmented, secure SOHO (Small Office/Home Office) network using Ubiquiti UniFi hardware. The network will be tailored to isolate different types of traffic, set up VLANs for specific use cases, and apply strong firewall rules to protect sensitive data and infrastructure.

While the principles outlined here are generally applicable to most networks, this implementation is specifically designed for UniFi OS version 4.06 and Network Application version 8.4.62.

As Terraform projects grow in complexity, organizing your modules effectively becomes critical to maintaining clean, reusable, and scalable infrastructure code. How you choose to organize these modules can significantly impact collaboration, code reuse, and overall project maintainability. In this blog post, we will explore three primary approaches to organizing Terraform modules: using local modules, storing all modules in one remote repository, and distributing modules across multiple remote repositories. We’ll discuss the benefits and limitations of each approach, with practical examples to help you decide which strategy best suits your needs.

This blog post is a follow-up to our previous post, where we implemented tiered access to S3 data using presigned URLs.

In most production applications, CloudFront is used to serve static content to users. In this post, we will explore how to implement restricted access when serving content through CloudFront.

You can find the complete example here.

What is CloudFront?

In simple terms, CloudFront is a content delivery network (CDN) managed by AWS. A CDN is a network of servers deployed close to end users, serving as a caching layer to improve content delivery speed and reliability.

In this blog post, we will look at how to implement a multi-account deployment pipeline on AWS using GitHub Actions and Terraform.

We will assume that you have access to at least two AWS accounts: one to hold pipeline resources and one target account where resources will be deployed.

Architecture

We will use two accounts: a pipeline account and a target account. The target account is your dev/staging/prod account. Usually, there is more than one target account in a given pipeline, but we will use one for simplicity. The same approach can be extended to an arbitrary number of target accounts.

Managing access to your Amazon S3 data is crucial for ensuring security and efficiency in your cloud architecture. You typically have three options for managing access to S3 data for client applications: using Amazon CloudFront distribution, leveraging S3 presigned URLs, or routing through backend APIs.

In this blog post, we will delve into S3 presigned URLs as an effective method for implementing tiered access to your S3 data. We’ll discuss their benefits, limitations, and provide a straightforward example to illustrate their use.