If you're writing code (or infrastructure-as-code), keeping things tidy is essential. Today, we focused on moving beyond a single, crowded file and structuring our project like a pro!

Imagine trying to find a single recipe in a cookbook where all the ingredients, instructions, cooking times, and nutritional facts for every dish were mashed together on one giant page. That's what a single-file Terraform project can feel like!

In professional practice, we use a structured file layout to make our infrastructure code readable, maintainable, and efficient—just like organizing your kitchen cabinets so you can find the spices quickly!

Why We Split Files (The Non-Tech Analogy)

We started with everything in one file (main.tf). To improve, we separated different logical parts of the configuration into their own dedicated files.

🛠️ The Hands-On Separation Process

In the video, we took our project from a single file to a clean, multi-file structure:

1. Backend Configuration: Moved the backend "s3" { ... } block into a new file: backend.tf. (Remember, this must be inside the terraform { ... } block!).

2. Provider Definition: Extracted the AWS provider configuration to providers.tf.

3. Input Variables: Moved all variable "..." { ... } definitions into variables.tf.

4. Local Values: Moved the locals { ... } block into locals.tf.

5. Outputs: Moved the output "..." { ... } definitions into outputs.tf.

This leaves our original main.tf file much cleaner, containing only the resource blocks that define what we're actually building (like resource "aws_s3_bucket" "..." { ... }).

🛑 Best Practice: Using .gitignore

A crucial best practice for version control (like Git/GitHub) is using a .gitignore file.

• Why? Terraform creates local files like:

  • .terraform/ folder: Contains provider plugins and metadata.

  • *.tfstate* files: Contains the current state of your infrastructure.

• The Problem: These are temporary, large, or contain sensitive information that should not be uploaded to a public repository like GitHub.

• The Solution: We added entries to .gitignore to ensure these files (and the sensitive terraform.tfvars file) are ignored when committing to Git!

🚀 Advanced Project Structure (The Next Level)

For larger companies and complex infrastructure, even the structure we created today isn't enough. We touched upon two advanced concepts we'll explore later:

1. Environment-Based Separation: Creating separate folders/configurations for different deployment environments like dev (development), staging (testing), and prod (production).

2. Using Modules: Breaking down large configuration into reusable, self-contained units (like a "Networking" module or a "Compute" module). This prevents repetition and makes your code truly scalable.

💡 Key Takeaway:

Good file structure in Terraform is a cornerstone of professional infrastructure-as-code. It helps you, your team, and future you understand the project quickly, making changes safer and more predictable!

TL / DR :- Just follow these visual representation

                ┌───────────────────────────┐
                │     Terraform Project     │
                └──────────────┬────────────┘
                               │
     ┌─────────────────────────┼───────────────────────────┐
     │                         │                           │
┌────────────┐         ┌──────────────┐           ┌────────────────┐
│ providers.tf│         │ backend.tf   │           │ variables.tf   │
└──────┬──────┘         └──────┬──────┘           └──────┬─────────┘
       │                        │                         │
       ▼                        ▼                         ▼
 AWS provider setup      Remote state config       Input variable definitions


     ┌─────────────────────────┼───────────────────────────┐
     │                         │                           │
┌────────────┐         ┌──────────────┐           ┌────────────────┐
│  locals.tf │         │  main.tf      │           │  outputs.tf    │
└──────┬──────┘         └──────┬──────┘           └──────┬─────────┘
       │                        │                         │
       ▼                        ▼                         ▼
 Reusable values         Actual resources           Values shown after
  (shortcuts)               (S3, EC2, etc.)            apply completes


         ┌───────────────────────────────────────────┐
         │              .gitignore                   │
         └──────────────────┬────────────────────────┘
                            ▼
            Ignores .terraform/, tfstate*, tfvars
           (Sensitive + auto-generated files)

➡️ Keep the Learning Momentum Going!

You've been doing great learning in public! Make sure to complete the task for Day 6 in the GitHub repository and submit your progress.

Next up: Day 7 where we dive into Type Constraints in Terraform variables.

If you enjoyed this write-up, follow along on my journey and connect with me!

Hashtags:

#Terraform #AWS #DevOps #InfrastructureAsCode #IaC #CloudComputing #PJDevOps #TerraformBestPractices #30DaysOfTerraform

• Connect with me on LinkedIn: Priyanshu Gupta on LinkedIn

• Check out my code on GitHub: priyanshuprafful's GitHub

• Join the discussion on Telegram: Priyanshu's Telegram

Since you are using a "Cloud-Native" setup (developing on the cloud, for the cloud), I have highlighted this as a pro-move in the blog post.

Here is the complete Markdown draft for your Hashnode article. You can copy-paste this directly into the Hashnode editor.

Day 1: Ditching "ClickOps" & Building a Cloud-Native Terraform Setup on AWS

👋 Introduction: The "It Works on My Machine" Problem

We’ve all been there. You spend 2 hours manually clicking through the AWS Console to set up a 3-tier architecture (Web, App, DB). It works perfectly. Then, your manager asks you to replicate it for the "QA" environment.

Suddenly, you are spending another 2 hours clicking buttons, hoping you don't miss a single checkbox. If you do, you end up with Configuration Drift—where your Dev environment works, but QA fails.

Today, I officially started the AWS Terraform 30-Day Series by Piyush Sachdeva to solve exactly this problem. The goal? To stop "ClickOps" and start treating infrastructure as software.

🛠️ My "Cloud-Native" Lab Setup

Most tutorials suggest running Terraform on your local Windows/Mac laptop. However, in a real enterprise environment, you often work from a jump server or a CI/CD runner.

To simulate a real-world scenario, I decided to build a Cloud-Native Development Environment.

1. The Workstation (EC2 + RHEL 9)

Instead of my local machine, I launched an AWS EC2 instance running Red Hat Enterprise Linux 9 (RHEL 9). This serves as my dedicated workstation.

• Why RHEL? It’s the industry standard for enterprise Linux environments.

• Why EC2? It keeps my development environment consistent, regardless of which computer I access it from.

2. Security Best Practice (IAM Roles vs. Keys)

This is the most critical part of my setup.

• The Anti-Pattern: Storing AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in local files or environment variables. This is a security risk.

• My Approach: I created an IAM Role with Administrator Access and attached it directly to my EC2 instance.

• The Result: Terraform automatically fetches temporary credentials from the EC2 Instance Metadata Service. No hardcoded secrets! 🔒

⚙️ Installing Terraform on RHEL 9

Since I am using RHEL 9, the installation process is slightly different from Ubuntu/Debian. Here are the commands I used to get up and running:

Bash

# 1. Install yum-utils to manage repositories
sudo yum install -y yum-utils

# 2. Add the official HashiCorp Linux repository
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo

# 3. Install Terraform
sudo yum -y install terraform

# 4. Verify installation
terraform -version

Result: Terraform v1.5.x on linux_amd64

🔄 The Terraform Workflow (Lifecycle)

We learned that Terraform doesn't just "run" scripts; it follows a strict lifecycle to ensure safety.

Here is a visual representation of how the workflow interacts with the AWS API:

Code snippet

sequenceDiagram
    participant User as 👨‍💻 DevOps Engineer
    participant TF as 🟣 Terraform CLI
    participant State as 📄 State File
    participant AWS as ☁️ AWS Cloud

    User->>TF: terraform init
    TF->>TF: Downloads AWS Provider Plugins

    User->>TF: terraform plan
    TF->>State: Reads current state
    TF->>AWS: Refreshes infrastructure data
    TF->>User: 📝 Shows "Dry Run" (Proposed Changes)

    User->>TF: terraform apply
    TF->>AWS: 🚀 Calls APIs to Create/Update Resources
    AWS-->>TF: Resource IDs & Details
    TF->>State: Updates State File

The 4 Main Commands

1. terraform init: The "boot up" command. It looks at your configuration and downloads the specific provider plugins (like AWS) needed to talk to the cloud.

2. terraform plan: The "sanity check." It compares what you want (your code) vs. what currently exists (in AWS) and tells you exactly what it will do. Always run this!

3. terraform apply: The "do it" command. This actually makes the API calls to create resources like VPCs or EC2 instances.

4. terraform destroy: The "cleanup" command. Since I am learning, I run this at the end of the day to ensure I don't get a surprise bill from AWS. 💸

🚀 Next Steps

Today was about laying the foundation. I have my RHEL 9 server ready, my VS Code connected via Remote-SSH, and my GitHub repo initialized.

Tomorrow, we dive into Providers and understanding how Terraform actually talks to different clouds without getting confused.

🔗 Repository: https://github.com/priyanshuprafful/AWS-Terraform-

🎥 Series: [AWS Terraform 30 Day Series by Piyush Sachdeva]

Day 1 Video link

Are you learning Terraform too? Let me know in the comments if you prefer running it locally or on a cloud instance like me! 👇

#Terraform, #AWS, #DevOps, #RHEL, #InfrastructureAsCode