Jayanth Katta | Technology, Life, Health & Learning

There’s something powerful about watching two completely separate networks start talking to each other… quietly, privately, without the internet even noticing. Today’s build was exactly that. I created two VPCs in different AWS regions and connected them using VPC peering, allowing EC2 instances to communicate using private IP addresses. Architecture Here is the architecture I implemented: Simple Flow User → SSH → EC2 (Primary VPC) → Private Network → EC2 (Secondary VPC) What I Built I created: Two VPCs in different regions One public subnet in each VPC Internet gateways for both VPCs Route tables with peering routes VPC peering connection (cross region) Two EC2 instances with Apache installed Security groups allowing SSH, ICMP, and TCP Step 1: Initialize Terraform I started by initializing Terraform. terraform init Terminal showing Terraform has been successfully initialized Step 2: Review Execution Plan terraform plan This step shows everything Terraform is going to create. Plan outp...

Today I worked on my first mini project in my AWS Terraform journey. The goal was to deploy a static website using S3 and CloudFront. Instead of manually creating resources in AWS, I used Terraform to automate the entire setup. Architecture User requests first hit CloudFront. CloudFront securely fetches content from a private S3 bucket using Origin Access Control and delivers it globally. User → CloudFront → Private S3 Bucket Project Setup I organized my Terraform code into multiple files for clarity. Variables, provider configuration, and main resources are separated. S3 Bucket The S3 bucket stores the website files. Public access is completely blocked. This ensures that the bucket is not exposed directly to the internet. Uploading Files Terraform automatically uploads all files from the local www folder. This includes index.html, style.css, and script.js. I used a loop with fileset to avoid writing multiple resource blocks. CloudFront Distribution CloudFront acts ...

Today’s learning felt like a shift from “building everything” to working intelligently with what already exists . Until now, most of my Terraform work was about creating infrastructure. But in real-world cloud environments, things are rarely that simple. Networks, security layers, and shared resources are often already in place, managed by different teams. This is where Terraform data sources come in. What Are Terraform Data Sources Terraform data sources allow us to read existing infrastructure instead of creating it. A simple way to think about it: Resources → Create and manage infrastructure Data Sources → Read and reference existing infrastructure This distinction is small in syntax, but huge in real-world usage. Scenario for This Demo In this lab, I simulated a real-world setup: A shared VPC already exists A shared subnet already exists My job is to launch an EC2 instance inside that network The key rule: I should NOT recreate the VPC or subnet I sho...

Today I continued my Terraform journey by working with advanced built-in functions. Day 11 focused on transforming values for resources. Day 12 focused on validating inputs, handling files, securing data, and preparing values before they are used. The biggest realization today was: Not everything in Terraform creates AWS resources. Some parts only process data. Understanding the Flow Terraform works in layers: terraform.tfvars → locals.tf → main.tf → outputs.tf Inputs come from terraform.tfvars Functions process data in locals.tf Resources are created in main.tf Results are displayed using outputs.tf Some assignments only use the first 3 steps and never reach AWS . What I Learned Backup Validation I used endswith() in variable validation. This prevents invalid values before Terraform even runs a plan. This happens before any AWS resource is created. validation error when backup name is wrong Sensitive Data I marked outputs as sensitive = true . This...