Forem: Bhaskara teja Bulusu

Day-15: VPC Peering using AWS Terraform

Bhaskara teja Bulusu — Thu, 11 Dec 2025 18:15:22 +0000

Day 15: VPC Peering with Terraform

Introduction

Today, we're diving into one of the most powerful networking concepts in AWS: VPC Peering. This tutorial will guide you through creating a complete, production-ready setup that connects two VPCs across different AWS regions, enabling seamless communication between resources in geographically distributed environments.

What is VPC Peering?

VPC Peering is a networking connection between two Virtual Private Clouds that enables you to route traffic between them using private IP addresses. When implemented across regions, it becomes an invaluable tool for:

Disaster Recovery: Distribute workloads across regions for high availability
Low Latency Access: Route traffic directly between regions without internet gateways
Data Replication: Securely replicate data between regional databases
Global Applications: Build truly global applications with regional presence

Architecture Overview

Our infrastructure will consist of:

Primary VPC in us-east-1 (10.0.0.0/16)
Secondary VPC in us-west-1 (10.1.0.0/16)
EC2 instances in both VPCs running Apache web servers
Bi-directional VPC peering connection
Security groups configured for cross-region communication
Complete networking stack (subnets, route tables, internet gateways)

Step 1: Multi-Region Provider Configuration

The foundation of multi-region deployment lies in configuring multiple AWS provider aliases:

terraform {
  required_providers {
    aws = {
        version = "~>6.0"
    }
  }
}

provider "aws" {
  alias = "primary"
  region = "us-east-1"
}

provider "aws" {
  alias = "secondary"
  region = "us-west-1"
}

Key Takeaway: Using provider aliases allows you to manage resources in multiple regions from a single Terraform configuration. Each resource references its target region using the provider argument.

Step 2: Defining Variables

We define our network configuration using variables for flexibility:

variable "primary_region" {
    type = string
    default = "us-east-1"
}

variable "secondary_region" {
    type = string
    default = "us-west-1"
}

variable "primary_vpc_cidr" {
    type = string
    default = "10.0.0.0/16"
}

variable "secondary_vpc_cidr" {
    type = string
    default = "10.1.0.0/16"
}

variable "primary_sn_cidr" {
    type = string
    default = "10.0.14.0/24"
}

variable "secondary_sn_cidr" {
    type = string
    default = "10.1.12.0/24"
}

Pro Tip: Non-overlapping CIDR blocks are crucial for VPC peering. Our primary (10.0.x.x) and secondary (10.1.x.x) ranges ensure no conflicts.

Step 3: Data Sources for Dynamic Configuration

We use data sources to fetch the latest Ubuntu AMIs and available availability zones:

data "aws_availability_zones" "primary" {
    provider = aws.primary
    state = "available"
}

data "aws_availability_zones" "secondary" {
    provider = aws.secondary
    state = "available"
}

data "aws_ami" "primary_ami" {
    provider = aws.primary
    most_recent = true
    owners = [ "amazon" ]

    filter {
      name = "name"
      values = [ "ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*" ]
    }
}

data "aws_ami" "secondary_ami" {
    provider = aws.secondary
    most_recent = true
    owners = [ "amazon" ]

    filter {
      name = "name"
      values = [ "ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*" ]
    }
}

Why Data Sources? Instead of hardcoding AMI IDs (which vary by region), we dynamically query for the latest Ubuntu 22.04 image in each region.

Step 4: Creating VPCs in Multiple Regions

// Primary VPC
resource "aws_vpc" "primary_vpc" {
  provider   = aws.primary
  cidr_block = var.primary_vpc_cidr

  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "VPC"
    type = "Primary"
  }
}

// Secondary VPC
resource "aws_vpc" "secondary_vpc" {
  provider         = aws.secondary
  cidr_block       = var.secondary_vpc_cidr
  instance_tenancy = "default"

  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "VPC"
    type = "Secondary"
  }
}

Important: Both VPCs have DNS support enabled, which is essential for resources within the VPC to resolve domain names.

Step 5: Network Infrastructure

Subnets

// Subnet in Primary VPC
resource "aws_subnet" "primary_sn" {
  provider                = aws.primary
  vpc_id                  = aws_vpc.primary_vpc.id
  cidr_block              = var.primary_sn_cidr
  map_public_ip_on_launch = true
  availability_zone       = data.aws_availability_zones.primary.names[0]

  tags = {
    Name = "Primary subnet"
  }
}

// Subnet in Secondary VPC
resource "aws_subnet" "secondary_sn" {
  provider                = aws.secondary
  vpc_id                  = aws_vpc.secondary_vpc.id
  cidr_block              = var.secondary_sn_cidr
  map_public_ip_on_launch = true
  availability_zone       = data.aws_availability_zones.secondary.names[0]

  tags = {
    Name = "Secondary subnet"
  }
}

Internet Gateways

// IGW for primary VPC
resource "aws_internet_gateway" "primary_igw" {
  provider = aws.primary
  vpc_id   = aws_vpc.primary_vpc.id

  tags = {
    Name = "Primary IGW"
  }
}

// IGW for secondary VPC
resource "aws_internet_gateway" "secondary_igw" {
  provider = aws.secondary
  vpc_id   = aws_vpc.secondary_vpc.id

  tags = {
    Name = "Secondary IGW"
  }
}

Route Tables

// Route table for primary VPC
resource "aws_route_table" "primary_rt" {
  provider = aws.primary
  vpc_id   = aws_vpc.primary_vpc.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.primary_igw.id
  }

  tags = {
    Name = "Primary VPC Route Table"
  }
}

// Route table for secondary VPC
resource "aws_route_table" "secondary_rt" {
  provider = aws.secondary
  vpc_id   = aws_vpc.secondary_vpc.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.secondary_igw.id
  }

  tags = {
    Name = "Secondary VPC Route Table"
  }
}

Step 6: The Heart of It - VPC Peering

This is where the magic happens! Creating a cross-region VPC peering connection involves two steps:

1. Creating the Peering Connection (Requester)

resource "aws_vpc_peering_connection" "primary_to_secondary" {
  provider    = aws.primary
  vpc_id      = aws_vpc.primary_vpc.id
  peer_vpc_id = aws_vpc.secondary_vpc.id
  peer_region = var.secondary_region
  auto_accept = false

  tags = {
    Name = "Primary to secondary peering"
    Side = "Requestor"
  }
}

2. Accepting the Peering Connection (Acceptor)

resource "aws_vpc_peering_connection_accepter" "secondary_vpc_accepter" {
  provider                  = aws.secondary
  vpc_peering_connection_id = aws_vpc_peering_connection.primary_to_secondary.id
  auto_accept               = true

  tags = {
    Side = "Accepter"
  }
}

Critical Note: For cross-region peering, you must set auto_accept = false on the requester and use the aws_vpc_peering_connection_accepter resource in the target region.

3. Updating Route Tables

// Route from primary to secondary
resource "aws_route" "primary_to_secondary" {
  provider                  = aws.primary
  route_table_id            = aws_route_table.primary_rt.id
  destination_cidr_block    = aws_vpc.secondary_vpc.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.primary_to_secondary.id

  depends_on = [aws_vpc_peering_connection_accepter.secondary_vpc_accepter]
}

// Route from secondary to primary
resource "aws_route" "secondary_to_primary" {
  provider                  = aws.secondary
  route_table_id            = aws_route_table.secondary_rt.id
  destination_cidr_block    = aws_vpc.primary_vpc.cidr_block
  vpc_peering_connection_id = aws_vpc_peering_connection.primary_to_secondary.id

  depends_on = [aws_vpc_peering_connection_accepter.secondary_vpc_accepter]
}

Essential: The depends_on ensures routes are only created after the peering connection is accepted.

Step 7: Security Groups for Cross-Region Traffic

Security groups control the traffic flow between our regions:

// Primary VPC Security Group
resource "aws_security_group" "primary_sg" {
  provider = aws.primary
  vpc_id   = aws_vpc.primary_vpc.id

  ingress {
    description = "SSH from anywhere"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "Allow traffic from secondary vpc"
    from_port   = 0
    to_port     = 65535
    protocol    = "tcp"
    cidr_blocks = [var.primary_vpc_cidr]
  }

  ingress {
    description = "allow icmp from secondary vpc"
    from_port   = -1
    to_port     = -1
    cidr_blocks = [var.secondary_vpc_cidr]
    protocol    = "icmp"
  }

  egress {
    description = "allow all outbound traffic"
    from_port   = 0
    to_port     = 0
    cidr_blocks = ["0.0.0.0/0"]
    protocol    = "-1"
  }

  tags = {
    Name = "Primary SG"
  }
}

// Secondary VPC Security Group
resource "aws_security_group" "secondary_sg" {
  provider = aws.secondary
  vpc_id = aws_vpc.secondary_vpc.id

  ingress {
    description = "allow ssh from anywhere"
    from_port = 22
    to_port = 22
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "allow all traffic from primary vpc"
    from_port = 0
    to_port = 65535
    protocol = "tcp"
    cidr_blocks = [var.primary_vpc_cidr]
  }

  ingress {
    description = "allow ICMP from primary"
    from_port = -1
    to_port = -1
    protocol = "icmp"
    cidr_blocks = [var.primary_vpc_cidr]
  }

  egress {
    description = "allow all outbound traffic"
    from_port = 0
    to_port = 0
    protocol = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Security Best Practice: Notice how we allow ICMP (ping) between VPCs for connectivity testing and all TCP traffic between the VPC CIDR ranges.

Step 8: EC2 Instances with User Data

Local Values for User Data

locals {
  primary_user_data = <<-EOF
    #!/bin/bash
    # Update packages
    apt-get update -y

    # Install Apache
    apt-get install apache2 -y

    # Start Apache
    systemctl start apache2
    systemctl enable apache2

    # Create a sample HTML page
    echo "<h1>Hello from Terraform EC2 Local Variable!</h1>" > /var/www/html/index.html
  EOF

   secondary_user_data = <<-EOF
    #!/bin/bash
    # Update packages
    apt-get update -y

    # Install Apache
    apt-get install apache2 -y

    # Start Apache
    systemctl start apache2
    systemctl enable apache2

    # Create a sample HTML page
    echo "<h1>Hello from Terraform EC2 Local Variable!</h1>" > /var/www/html/index.html
  EOF
}

EC2 Instances

// EC2 instance in primary region
resource "aws_instance" "primary_instance" {
  provider      = aws.primary
  ami           = data.aws_ami.primary_ami.id
  instance_type = "t3.micro"
  count         = 1
  subnet_id     = aws_subnet.primary_sn.id
  key_name      = var.primary_key_pair
  security_groups = [ aws_security_group.primary_sg.id ]

  user_data = local.primary_user_data

  tags = {
    Name = "Primary Instance"
  }
}

// EC2 instance in secondary region
resource "aws_instance" "secondary_instance" {
  provider      = aws.secondary
  ami           = data.aws_ami.secondary_ami.id
  count         = 1
  instance_type = "t3.micro"
  key_name      = var.secondary_key_pair
  subnet_id     = aws_subnet.secondary_sn.id
  security_groups = [aws_security_group.secondary_sg.id]

  user_data = local.secondary_user_data

  tags = {
    Name = "Secondary Instance"
  }
}

Deployment Steps

1. Initialize Terraform

terraform init

This downloads the AWS provider and initializes the backend.

2. Review the Execution Plan

terraform plan

This shows you exactly what resources Terraform will create across both regions.

3. Apply the Configuration

terraform apply

Type yes when prompted. Terraform will create approximately 20+ resources across two AWS regions!

4. Verify the Deployment

After successful deployment, you can:

Test connectivity via SSH: Connect to instances in both regions
Test VPC peering: Ping the private IP of one instance from the other
Test web server: Access Apache on both instances via their public IPs

Testing Cross-Region Connectivity

Once deployed, SSH into the primary instance and try pinging the secondary instance's private IP:

# From primary instance
ping <secondary-instance-private-ip>

You should see successful responses, proving the VPC peering is working!

To avoid ongoing charges, destroy the infrastructure when done:

terraform destroy

Conclusion

Congratulations! You've successfully built a multi-region infrastructure with VPC peering using Terraform. This architecture pattern is foundational for enterprise-grade AWS deployments requiring high availability, disaster recovery, and global reach.

The power of Infrastructure as Code truly shines when managing complex, multi-region setups like this. What would take hours of manual clicking in the AWS console is now reproducible, version-controlled, and automated!

Next Steps

Experiment with adding more subnets and availability zones
Implement Transit Gateway for hub-and-spoke topology
Add VPC Flow Logs for network monitoring
Configure AWS PrivateLink for service-to-service communication
Implement cross-region load balancing

@piyushsachdeva

https://youtu.be/WGt000THDmQ?si=mBJ36uPnPvBAISii

Day-14: Project - Deploying a Static website using Terraform

Bhaskara teja Bulusu — Tue, 09 Dec 2025 08:39:49 +0000

Project - Deploy a Static Website with AWS S3 and CloudFront using Terraform

Objective

Deploy a static website using AWS S3 for storage and CloudFront for content delivery.

Architecture Diagram

Prerequisites

Basic knowledge of Terraform
AWS account with necessary permissions
Terraform installed on your local machine
AWS CLI configured with your credentials

Steps

Set Up Your Terraform Configuration
- Create a new directory for your project and navigate into it.
- Create a main.tf file to define your Terraform configuration.
Define the AWS Provider

    provider "aws" {
      region = "us-east-1" # Change to your preferred region
    }

Create variables.tf

    variable "bucket_name" {
      description = "The name of the S3 bucket to create"
      type        = string
    }

Create an S3 Bucket

    resource "aws_s3_bucket" "static_website" {
      bucket = var.bucket_name     # Change to a unique bucket name

    }

Make the Bucket Private make the bucket private by blocking all public access

    // Block all public access to the S3 bucket.

  resource "aws_s3_bucket_public_access_block" "block_public_access" {

      bucket = aws_s3_bucket.static_website.id

      block_public_acls = true
      block_public_policy = true
      ignore_public_acls = true
      restrict_public_buckets = true
  }

Create a Bucket Policy to Allow Access from CloudFront



    // main.tf
    // Add bucket policy to allow access from another CloudFront 
resource "aws_s3_bucket_policy" "allow_access_from_another_account" {
  bucket = aws_s3_bucket.static_bucket.id // implicit dependency on S3 bucket

depends_on = [aws_s3_bucket_public_access_block.block_public_access]
  policy = local.s3_bucket_policy
}

// locals.tf
// local variables
locals {
    s3_bucket_policy = templatefile(var.bucket_policy_file, {
        bucket_arn = aws_s3_bucket.static_bucket.arn,
        cloudfront_arn = aws_cloudfront_distribution.s3_distribution.arn
    })
}

//variables.tf
// Read bucket policy from json file
variable "bucket_policy_file" {
  description = "The file name that contains the bucket policy in JSON format"
  type        = string
  default = "bucket_policy.json.tmpl"
}

// bucket_policy.json.tmpl
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontService",
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudfront.amazonaws.com"
      },
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "${bucket_arn}/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "${cloudfront_arn}"
        }
      }
    }
  ]
}

Upload Static Website Files
- Create a folder named www in your project directory and add your static website files (e.g., index.html, styles.css).
- Use the aws_s3_object resource to upload these files to the S3 bucket.


// Add files to the S3 bucket
resource "aws_s3_object" "static_files" {
    bucket = aws_s3_bucket.static_bucket.id
    for_each = fileset("${path.module}/www","**")
    key = each.value
    source = "${path.module}/www/${each.value}"

    etag = filemd5("${path.module}/www/${each.value}")

    content_type = lookup({
        html = "text/html",
        css  = "text/css",
        js   = "application/javascript",
        png  = "image/png",
        jpg  = "image/jpeg",
        jpeg = "image/jpeg",
        gif  = "image/gif",
        svg  = "image/svg+xml"
    }, split(".", each.value)[length(split(".", each.value)) - 1], "application/octet-stream")
}

Create Origin Access Identity for CloudFront

It is an IAM to the resource (example: s3 bucket) where it provides access control to specific origin.
OAC is related to cloudfront which blocks direct access to the content in s3 bucket ensuring that all the requests are made through designated cloudfront CDN.


// origin access control for CloudFront
resource "aws_cloudfront_origin_access_control" "cloudfront_oac" {
  name                              = "CloudFront-OAC"
  description                       = "OAC for accessing S3 bucket"
  origin_access_control_origin_type = "s3"
  signing_behavior                  = "always"
  signing_protocol                  = "sigv4"
}

Create a CloudFront Distribution In this step, we will create a cloudfront distribution to serve the content from the S3 bucket.


// create CloudFront distribution
resource "aws_cloudfront_distribution" "s3_distribution" {
  origin {
    domain_name              = aws_s3_bucket.static_bucket.bucket_regional_domain_name
    origin_access_control_id = aws_cloudfront_origin_access_control.cloudfront_oac.id
    origin_id                = var.s3_origin_id
  }

  enabled             = true
  is_ipv6_enabled     = true
  comment             = "Some comment"
  default_root_object = "index.html"  // specify the default root object (home page)


  default_cache_behavior {
    allowed_methods  = ["GET", "HEAD"]  // specify allowed methods from users
    cached_methods   = ["GET", "HEAD"]  // specify cached methods
    target_origin_id = var.s3_origin_id // reference to origin id

    forwarded_values {
      query_string = false // do not forward query strings

      cookies {
        forward = "none" // do not forward cookies
      }
    }

    viewer_protocol_policy = "redirect-to-https" // enforce HTTPS
    min_ttl                = 0
    default_ttl            = 3600
    max_ttl                = 86400
  }

  price_class = "PriceClass_200"  // use price class 200 for cost optimization

  restrictions {
    geo_restriction {
      restriction_type = "none"  // allow access from all geographic locations
    }
  }
  viewer_certificate {
    cloudfront_default_certificate = true  // use default CloudFront certificate for HTTPS
  }
}

// variables.tf

variable "s3_origin_id" {
  default = "S3-StaticWebsiteOrigin"
}

Output the CloudFront Domain Name

    output "cloudfront_domain_name" {
      description = "The domain name of the CloudFront distribution"
      value       = aws_cloudfront_distribution.s3_distribution.domain_name
    }

Initialize and Apply Terraform Configuration
- Run terraform init to initialize the Terraform configuration.
- Run terraform apply to create the resources. Review the plan and confirm the apply.
- After the apply is complete, note the CloudFront domain name from the output.
Access Your Static Website
- Open a web browser and navigate to the CloudFront domain name to see your static website in action.
- It will automatically redirect to HTTPS.

Conclusion

This mini project demonstrated how to deploy a static website using AWS S3 and CloudFront with Terraform. You can further enhance this setup by adding custom domains using Route 53, SSL certificates using AWS Certificate Manager (ACM), and additional security measures as needed.

Terminal Output:

Static Website Accessed via CloudFront:

Congratulations! You have successfully deployed a static website using AWS S3 and CloudFront with Terraform.

@piyushsachdeva

Day-13: Data sources in Terraform

Bhaskara teja Bulusu — Sun, 07 Dec 2025 18:43:11 +0000

What are Data Sources?
Data source in terraform refers to a way to read existing resources instead of creating new ones. Data sources lookup and use the data from things that already exist in your cloud or other services. This is useful when you want to reference information about resources that are not managed by your terraform configuration.

example: You can use data sources to fetch information about existing VPCs, subnets, AMIs, security groups, etc.

syntax:

data "data_source_type" "data_source_name" {
  # Configuration arguments
}

Filters:
Filters are used in data sources to narrow down the results based on specific criteria. They help you to find the exact resource you are looking for by applying conditions just like search queries.

syntax:

filter {
  name   = "filter_name"
  values = ["value1", "value2"]
}

Task : Use Data Sources in Terraform AWS Provider to fetch existing resources information.

Creating an EC2 instance by fetching the AMI ID using Data Source and Subnet ID using Data Source

// main.tf

# Fetch the latest Ubuntu AMI
data "aws_ami" "ubuntu" {
  most_recent = true

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }

  owners = ["amazon"] // Canonical
}

# Fetch existing VPC by Name tag
data "aws_vpc" "selected" {
  filter {
    name   = "tag:Name"
    values = ["shared-primary-vpc"]
  }
}

# Fetch existing Subnet by Name tag within the selected VPC
data "aws_subnet" "selected" {
  filter {
    name   = "tag:Name"
    values = ["shared-primary-subnet"]
  }
    vpc_id = data.aws_vpc.selected.id
}

# Create an EC2 instance using the fetched AMI and Subnet
resource "aws_instance" "example" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t2.micro"
  subnet_id     = data.aws_subnet.selected.id

  tags = {
    Name = "day-13-instance"
  }
}
---

Output:


// outputs.tf
output "instance_id" {
  value = aws_instance.example.id
}
output "instance_public_ip" {
  value = aws_instance.example.public_ip
}

Now, the terraform configuration uses data sources to fetch the latest Ubuntu AMI and existing subnet information to create an EC2 instance.

@piyushsachdeva

Day-12: AWS Terraform Functions

Bhaskara teja Bulusu — Fri, 05 Dec 2025 17:48:06 +0000

Advanced Functions in Terraform:

Building upon the foundational functions covered in Day 11, today we explore more specialized functions that enhance Terraform's capability to handle complex data transformations, validations, and operations. These functions are essential for creating robust, production-ready infrastructure as code.

Types of Advanced Functions:

Numeric Functions:
Numeric functions are used to perform mathematical operations and manipulate numeric values. These functions allow you to perform calculations, absolute value operations, statistical operations, and other numeric transformations.

Examples: abs(), ceil(), floor(), max(), min(), sum(), sqrt()

Validation Functions:
Validation functions are used to validate input values and ensure they meet specific criteria. These functions help enforce data integrity and prevent configuration errors by checking conditions and formats.

Examples: can(), regex(), length(), startswith(), endswith(), contains()

Date/Time Functions:
Date and time functions are used to manipulate and format date and time values. These functions allow you to perform operations such as parsing, formatting, timestamping, and calculating time differences.

Examples: formatdate(), timeadd(), timestamp(), timecmp()

File Functions:
File functions are used to read, manipulate, and check file contents and properties. These functions allow you to read files, check file existence, work with file paths, and perform other file-related operations.

Examples: file(), fileexists(), dirname(), basename(), jsondecode(), jsonencode()

Examples from DAY-12:

1. Numeric Functions - Cost Analysis and Management

Absolute Values and Statistical Operations:

// variables.tf
variable "monthly_cost" {
  description = "The estimated monthly cost"
  type        = list(number)
  default     = [-100.5, 200.75, 300.0]
}

// main.tf
locals {
    // Convert negative costs to absolute values
    absolute_monthly_cost = [for cost in var.monthly_cost : abs(cost)]

    // Find maximum cost using max() function
    maximum_monthly_cost = max(local.absolute_monthly_cost...)

    // Calculate total cost using sum() function
    total_monthly_cost = sum(local.absolute_monthly_cost)
}

// outputs.tf
output "absolute_monthly_cost" {
    value       = local.absolute_monthly_cost
    description = "The absolute values of the estimated monthly costs"
}

output "maximum_monthly_cost" {
    value       = local.maximum_monthly_cost
    description = "The maximum estimated monthly cost"
}

output "total_monthly_cost" {
    value       = local.total_monthly_cost
    description = "The total estimated monthly cost"
}

2. Validation Functions - Input Validation and Quality Control

Regex Validation and Length Checking:

// variables.tf
variable "instance_type" {
  description = "The type of instance to use"
  type        = string
  default     = "t2.micro"

  validation {
    condition = can(regex("^t[2-3]\\." , var.instance_type))
    error_message = "instance type must start with 't2.' or 't3.'"
  }

  validation {
    condition = length(var.instance_type) > 2 && length(var.instance_type) < 20
    error_message = "length of instance type must be between 2 and 20 characters"
  }
}

variable "backup_file_name" {
    description = "The name of the backup file"
    type        = string
    default     = "bucket_backup"

    validation {
      condition = endswith(var.backup_file_name, "_backup")
      error_message = "backup file must end with '_backup'"
    }
}

// main.tf
locals {
    instance_type = var.instance_type
    backup_file_name = var.backup_file_name
}

// outputs.tf
output "instance_type" {
    value       = local.instance_type
    description = "The type of instance being used"
}

output "backup_file_name" {
  value = local.backup_file_name
}

3. Date/Time Functions - Timestamp Management

Current Timestamp and Date Formatting:

// main.tf
locals {
    // Get current timestamp
    current_time = timestamp()

    // Format timestamp to YYYY-MM-DD format
    formatted_time = formatdate("YYYY-MM-DD", local.current_time)

    // Create timestamped bucket name
    bucket_name_with_timestamp = "bhaskaratejabulusu-s3-bucket-${local.formatted_time}"
}

// outputs.tf
output "bucket_name_with_timestamp" {
    value       = local.bucket_name_with_timestamp
    description = "The S3 bucket name appended with the current timestamp"
}

4. File Functions - Configuration File Management

File Existence Checking and JSON Processing:

// main.tf
locals {
    // Check if config file exists
    config_file_exists = fileexists("./config.json")

    // Conditionally load file content based on existence
    file_config = local.config_file_exists ? jsondecode(file("./config.json")) : { }

    // Get directory name from file path
    directory_name_of_file = dirname("./config.json")

    // Read specific value from JSON file
    username = jsondecode(file("./config.json")).username
}

// Create JSON file from variable data
resource "local_file" "my_json_file" {
  content = jsonencode(var.my_data)
  filename = "my_data.json"
}

// variables.tf
variable "my_data" {
  type = map(any)
  default = {
    name = "bhaskara"
    age  = 30
    is_active = true
  }
}

// outputs.tf
output "file_config" {
    value       = local.file_config
    description = "The configuration loaded from config.json file"
}

output "directory_name_of_file" {
    value       = local.directory_name_of_file
    description = "The directory name of the config.json file"
}

output "username" {
    value       = local.username
    description = "The username from the config file or default"
}

5. Collection Functions with Type Conversion - Region Management

Set Operations and List Concatenation:

// variables.tf
variable "default_regions" {
  type    = list(string)
  default = ["us-east-1", "us-west-2", "us-east-1"]
}

variable "new_regions" {
  type = list(string)
  default = ["eu-west-1", "ap-south-1", "sa-east-1"]
}

// main.tf
locals {
    // Combine regions and remove duplicates using toset()
    combined_regions = toset(concat(var.default_regions, var.new_regions))
}

// outputs.tf
output "regions" {
    value       = local.combined_regions
    description = "The combined unique regions from default and new regions"
}

Best Practices:

Always validate inputs using validation blocks with appropriate functions
Handle file existence gracefully using fileexists() before reading files
Use appropriate numeric functions for calculations to avoid precision issues
Format timestamps consistently across your infrastructure
Combine functions effectively to create robust data transformation pipelines

@piyushsachdeva

Day-11: AWS Terraform Functions

Bhaskara teja Bulusu — Thu, 04 Dec 2025 17:56:18 +0000

Functions in Terraform

Functions:
A function is a predefined operation that takes one or more input values (arguments) and returns a single output value. Functions are used to perform common tasks, manipulate data, and transform values within Terraform configurations.
functions increse the reusability and modularity of Terraform code, making it easier to manage and maintain infrastructure as code.

In terraform, we cannot create our own functions but we can use the built-in functions provided by terraform.

Types of Functions in Terraform:

Validation Functions:
Validation functions are used to validate input values and ensure they meet specific criteria. These functions help enforce
data integrity and prevent configuration errors.

Examples: can(), contains(), length(), regex(), alltrue(), anytrue()

String Functions:
String functions are used to manipulate and transform string values. These functions allow you to perform operations such as concatenation, substring extraction, and case conversion.

Examples: concat(), join(), lower(), upper(), replace(), split(), trimspace()

Numeric Functions:
Numeric functions are used to perform mathematical operations and manipulate numeric values. These functions allow you to perform calculations, rounding, and other numeric transformations.

Examples: abs(), ceil(), floor(), max(), min(), round(), sqrt()

Collection Functions:
Collection functions are used to manipulate and transform collections such as lists, maps, and sets. These functions allow you to perform operations such as filtering, mapping, and aggregating values within collections.

Examples: length(), contains(), distinct(), flatten(), join(), lookup(), merge(), slice()

Type Conversion Functions:
Type conversion functions are used to convert values from one data type to another. These functions allow you to change the type of a value to ensure compatibility with other operations or functions.

Examples: tostring(), tonumber(), tolist(), tomap(), toset()

Date and Time Functions:
Date and time functions are used to manipulate and format date and time values. These functions allow you to perform operations such as parsing, formatting, and calculating time differences.

Examples: formatdate(), timeadd(), timestamp(), timecmp()

Lookup Functions:
Lookup functions are used to retrieve values from maps or other data structures based on specified keys. These functions allow you to access specific values within complex data structures.

Examples: lookup(), element(), index()

Validation Functions:
Validation functions are used to validate input values and ensure they meet specific criteria. These functions help enforce data integrity and prevent configuration errors.

Examples: can(), contains(), length(), regex(), alltrue(), anytrue()

File Functions:
File functions are used to read and manipulate file contents. These functions allow you to read files, encode/decode file contents, and perform other file-related operations.

Examples: file(), filebase64(), filesha256(), templatefile()

Examples:

Transform "Project ALPHA Resource" → "project-alpha-resource"

// variables.tf
variable "project_name" {
    default = "Project ALPHA Resource"

}

// main.tf
locals {
    formatted_name = lower(replace(var.project_name, " ", "-"))
}

//outputs.tf
output "formatted_name" {
    value = local.formatted_name
}

Resource Tagging - Merge default and environment tags

// variables.tf

variable "org_tags" {
  type = map(string)
  default = {
    "org" = "haschicorp"
    "project" = "automation"
  }
}

variable "default_tags" {
    type = map(string)
    default = {
      "env" = "dev"
      "name" = "env_tags"
    }

}

// main.tf
locals{
      tags = merge(var.default_tags, var.org_tags)
}
 // outputs.tf
output "merged_tags" {
    value = local.tags
}

Sanitize bucket names for AWS compliance

// variables.tf
variable "inconsistent_bucket_name" {
    type = string
    default = "My.Project_ALPHA.Bucket."

}

// main.tf
locals {
    sanitized_bucket_name = lower(replace(replace(trimspace(var.inconsistent_bucket_name), "_", "-"), ".", "-"))
}

// outputs.tf
output "sanitized_bucket_name" {
    value = local.sanitized_bucket_name
}

Security Group Ports - Transform "80,443,8080" into security group rules

// variables.tf
variable "allowed_ports" {
    type = string
    default = "80,443,8080"

}

// main.tf

  port_list = (split(",",var.ports))

  sg_rules = [ for port in local.port_list :
    {
        name = "port-${port}"
        port = tonumber(port)
    }

   ]

// outputs.tf
output "sg_rules" {
    value = local.sg_rules
}

Environment Lookup - Select instance size by environment

// variables.tf
variable "environment" {
    type = string
    default = "development"

}

variable "env_instances" {
    type = map(string)
    default = {
      "dev" = "t2.medium"
      "stage" = "t2.small"  
      "prod" = "t2.large"
    }

}

// main.tf
locals {
    instance_size = lookup(var.env_instances, var.environment, "t2.micro")
}

// outputs.tf
output "instance_size" {
    value = local.instance_size
}

@piyushsachdeva

Day-10: Conditional expressions, Dynamic blocks, Splat expressions in terraform

Bhaskara teja Bulusu — Wed, 03 Dec 2025 16:08:21 +0000

Conditional Expressions:
Conditional expressions in Terraform allow you to choose between two values based on a condition. The syntax is condition ? true_value : false_value. This is useful for setting resource attributes based on variable values or other conditions.

chose instances based on the environment (dev/prod)
enable monitoring based on the configurations
select different AMIs based on region

example:

// main.tf
resource "aws_instance" "instance" {
    ami = "ami-0fa3fe0fa7920f68e"
    region = "us-east-1"
    instance_type = var.environment == "dev" ? "t3.micro" : "t3.small"
    count = var.instance_count

    tags = var.tags  
}

// variables.tf
variable "environment" {
    type = string
    default = "dev"
}

Splat Expressions:
Splat expressions allow you to extract multiple values from a list of objects. The syntax is resource_type.resource_name[*].attribute. This is useful for retrieving attributes from multiple instances of a resource.

example:

// main.tf
resource "aws_instance" "instance" {
    ami = "ami-0fa3fe0fa7920f68e"
    region = "us-east-1"
    instance_type = var.environment == "dev" ? "t3.micro" : "t3.small"
    count = var.instance_count

    tags = var.tags  
}

// splat expression example in Terraform
output "instance_ids" {
    value = aws_instance.instance[*].id
}

Dynamic Blocks:
Dynamic blocks in Terraform allow you to generate multiple nested blocks within a resource based on a list or map variable. The syntax is dynamic "block_name" { for_each = var.list_variable ... }. This is useful for creating multiple similar configurations without duplicating code.

example:

// variables.tf

# ingress values
variable "ingress_values" {
  type = list(object({
    from_port   = number
    to_port     = number
    protocol    = string
    cidr_blocks = list(string)
  }))

  default = [
    {
      from_port   = 80
      to_port     = 80
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    },
    {
      from_port   = 443
      to_port     = 443
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }
  ]
}



// main.tf

// Dynamic block example in Terraform
resource "aws_security_group" "security_group" {
    name = "sg"

    dynamic "ingress" {
        for_each = var.ingress_values
      content {
        from_port   = ingress.value.from_port
        to_port     = ingress.value.to_port
        protocol    = ingress.value.protocol
        cidr_blocks = ingress.value.cidr_blocks
      }
    }

      egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

}

So, by using conditional expressions, splat expressions, and dynamic blocks, you can create more flexible, reusable, and maintainable Terraform configurations.

@piyushsachdeva

Day-09: Lifecycle management rules in terraform

Bhaskara teja Bulusu — Wed, 03 Dec 2025 04:21:12 +0000

Lifecycle rules:
In terraform lifecycle rules are the ones that actually controls how the resource is created/updated/destroyed.

improve security
Better maintenance of resources
control over the resources

There are 6 rules to manage the lifecycle

ignore_changes
prevent_destroy
replace_triggered_by
create_before_destroy
precondition
postcondition

1. Create before destroy:
If there is any change in the resource, this rule ensures that the resource with updated changes is created and then the old resource will be destroyed

This reduces the downtime while making changes (Zero-downtime deployment)

example:
create an instance before destroying

// main.tf
// Create before destroy to avoid downtime
resource "aws_instance" "instance" {
    ami = "ami-0f64121fa59598bf7"
    instance_type = "t3.micro"
    region = tolist(var.allowed_region)[0]

    tags = var.tags

    lifecycle {
      create_before_destroy = true
    }

}

2. Prevent destroy:
This rule prevents the resource from being destroyed accidentally.
example:
prevent destroy for s3 bucket

// main.tf
// prevent destroy to avoid accidental deletion
resource "aws_s3_bucket" "bucket" {
    bucket = "${var.username}-bucket-${var.environment}-day-09"

    lifecycle {
      prevent_destroy = true
    }

}

3. Ignore changes:
This rule ignores the changes made to the resource outside terraform.
example:
ignore changes to tags

// main.tf
// Ignore changes to tags
resource "aws_instance" "instance" {
    ami = "ami-0f64121fa59598bf7"
    instance_type = "t3.micro"
    region = tolist(var.allowed_region)[0]

    tags = var.tags

    lifecycle {
      ignore_changes = [tags]
    }

}

4. Replace triggered by:
This rule replaces the resource when there is a change in the specified attribute.
example:
replace resource when there is a change in instance_type

// main.tf
// Replace instance when there is a change in instance_type
resource "aws_instance" "instance" {
    ami = "ami-0f64121fa59598bf7"
    instance_type = "t3.micro"
    region = tolist(var.allowed_region)[0]

    tags = var.tags

    lifecycle {
      replace_triggered_by = [instance_type]
    }

}

5. Precondition:
This rule checks the condition before creating/updating the resource.
example:

// main.tf
// Precondition to check instance type
resource "aws_instance" "instance" {
    ami = "ami-0f64121fa59598bf7"
    instance_type = "t3.micro"
    region = tolist(var.allowed_region)[0]

    tags = var.tags

    lifecycle {
      precondition {
        condition     = var.instance_type == "t3.micro"
        error_message = "Instance type must be t3.micro"
      }
    }

}

6. Postcondition:
This rule checks the condition after creating/updating the resource.
example:

// main.tf
// Postcondition to check instance state
resource "aws_instance" "instance" {
    ami = "ami-0f64121fa59598bf7"
    instance_type = "t3.micro"
    region = tolist(var.allowed_region)[0]

    tags = var.tags

    lifecycle {
      postcondition {
        condition     = aws_instance.instance.instance_state == "running"
        error_message = "Instance is not in running state"
      }
    }

}

Best practices:

Use lifecycle rules to manage resources effectively.
Always test the lifecycle rules in a non-production environment before applying them to production.
Document the lifecycle rules used in the terraform code for better understanding and maintenance.
Regularly review and update the lifecycle rules as per the changing requirements and best practices.
Be cautious while using ignore_changes - it can hide important changes.
Use create_before_destroy for critical resources to avoid downtime.

@piyushsachdeva

Day-08: Meta Arguments in terraform

Bhaskara teja Bulusu — Tue, 02 Dec 2025 06:04:40 +0000

Meta arguments

In terraform, the meta arguments are classified into 5 types

depends_on
count
for_each
provider
lifecycle

count:
An argument used to create multiple resources with numeric indexing.
Usually, this is the length of the list.

used for iterating over a list

example code:

// variables.tf
variable "bucket_count_list" {
    type = list(string)
    default = [ "bhaskaratejabulusu-bucket-day-08-list-1", 
                    "bhaskaratejabulusu-bucket-day-08-list-2" ]
}

// main.tf
resource "aws_s3_bucket" "bucket1" {
    count = length(var.bucket_count_list)
    bucket = var.bucket_count_list[count.index] // iterates over a list 
                                                   from 0 to [count-1]

}

for_each
An argument in terraform to create multiple resources with map/sets

iterates over values / key-value pairs
used in maps and sets

to use for_each the datatype must be either map or a set

example for set and map:

// variables.tf

// set
variable "bucket_count_set" {
    type = set(string)
    default = [ "bhaskaratejabulusu-bucket-day-08-set-1", 
                    "bhaskaratejabulusu-bucket-day-08-set-2" ]

}

// map
variable "bucket_count_map" {
    type =  map(string)
    default = {
        "bucket1" = "bhaskaratejabulusu-bucket-day-08-map-1",
        "bucket2" = "bhaskaratejabulusu-bucket-day-08-map-2"
    }

}


// main.tf

// using set
resource "aws_s3_bucket" "bucket2" {
    for_each = var.bucket_count_set
    bucket = each.value // iterates over the set using a for loop 
                             internally and retrieves every value

}

// using map
resource "aws_s3_bucket" "bucket3" {
    for_each = var.bucket_count_map
    bucket = each.value

}

depends_on
An argument used to explicitly specify that a resource or module must be created or updated after one or more other resources or modules. It establishes a manual dependency, ensuring the correct order of operations, even when there’s no direct reference between the resources.

example:

// main.tf
resource "aws_s3_bucket" "bucket1" {
    count = length(var.bucket_count_list)
    bucket = var.bucket_count_list[count.index]

}

resource "aws_s3_bucket" "bucket2" {
    for_each = var.bucket_count_set
    bucket = each.value

    depends_on = [ aws_s3_bucket.bucket1 ]

}

In the above code, the bucket2 is dependent on bucket1 so terraform will wait for bucket1 to be created and then bucket2 will be created ensuring the correct order.

@piyushsachdeva

Day-07: AWS Terraform Type constraints

Bhaskara teja Bulusu — Mon, 01 Dec 2025 17:23:13 +0000

Terraform Variable Type Constraint Tasks

The variables in terraform are classified into two types

Based on Purpose
Based on value (Type Constraints)

The Type constraints are again classified into three types

Primitive --> String, Number, Bool
Complex --> List, Set, Tuple, Map, Object
Null and Any

Let's see one by one

String:
Combination of characters is known as a string. in terraform the string is enclosed between quotes
example:

environment - "development"

example code:

Objective: Use the simple string type variables to set the AWS Provider configuration and apply a basic naming convention.

// variables.tf

variable "environment" {
    type = string
    description = "The environment for the resources"
    default = "dev"
}

// main.tf
resource "aws_s3_bucket" "bucket" {
  bucket = "${local.bucket_name}-bucket-${var.environment}"
  region = var.region

  tags = {
    Name        = "My S3 bucket"
    Environment = var.environment
  }
}

Number:
The number type constraint in terrraform is just a simple numeric value.
example:
count=1

example code:

Objective: Use the number constraint to define the desired quantity of a resource using Terraform’s count argument.



// variables.tf
variable "instance_count" {
    type = number
    description = "Number of EC2 instances to create"
    default = 1
}

//main.tf
resource "aws_instance" "ec2_instance" {
  ami = "ami-0fa3fe0fa7920f68e"
  count = var.instance_count

}

Boolean:
The boolean constraint in terraform is defined as the value which is either true or false
example:
monitoring = true

example code:
Objective: Use bool variables to control binary configuration settings (true/false flags) for AWS resources.

// variables.tf
variable "monitoring_enabled" {
    type = bool
    default = true
}

variable "associate_public_ip" {
    type = bool
    default = true
}

// main.tf

# Create an ec2 instance
resource "aws_instance" "ec2_instance" {
  ami = "ami-0fa3fe0fa7920f68e"
  count = var.instance_count
  monitoring = var.config.monitoring
  associate_public_ip_address = var.associate_public_ip

}

List:
The list in terraform is an ordered collection of elements of same type

duplicates are allowed
elements in list are accessed using index example: regions = ["us-east-1","us-west-1","eu-west-1"]

example code:
Objective: Use a list(string) to define multiple, ordered values of the same type for sequential use.

// variables.tf
# CIDR block
variable "cidr_block" {
    type = list(string)
    default = [ "10.0.0.0/8", "192.168.0.0/16", "172.16.0.0/12" ]
}

# Allowed VM Types
variable "allowed_vm_types" {
    type = list(string)
    default = [ "t2.micro", "t2.small", "t3.micro", "t3.small" ]
}

// main.tf

# Create an ec2 instance
resource "aws_instance" "ec2_instance" {
  ami = "ami-0fa3fe0fa7920f68e"
  instance_type = var.allowed_vm_types[2]
  count = var.instance_count
  monitoring = var.config.monitoring
  associate_public_ip_address = var.associate_public_ip


  tags = var.tags
}


# Create a VPC
resource "aws_vpc" "myvpc" {
  cidr_block = var.cidr_block[1]

  tags = {
    Name = "Default VPC"
  }
}

Set:
A set in terraform is an unordered collection of unique elements of same type.

duplicate values are not allowed
should be accessed using values (no index)
tolist(): method that converts a set to list

example:
[ "us-east-1", "us-west-2", "eu-west-1" ]

example code:

Objective: Use a set(string) to define a collection of unique, unordered values, typically for validation purposes.

// variables.tf
# Allowed regions
variable "allowed_region" {
    type = set(string)
    default = [ "us-east-1", "us-west-2", "eu-west-1" ]

}

// providers.tf
provider "aws" {
  region = var.config.region
}

Map:
Map in terraform is the collection of key-value pairs.

accessed using keys

example code:
Objective: Use a map(string) to pass dynamic key-value pairs, primarily for resource metadata and cost allocation.

// variables.tf
# tags variable
variable "tags" {
    type = map(string)
    default = {
        Environment = "dev", 
        Name = "dev-Instance", 
        created_by = "terraform"
    }
}

//main.tf
resource "aws_instance" "ec2_instance" {
  ami = "ami-0fa3fe0fa7920f68e"

  tags = var.tags // using map
}

Tuple:
Tuple is an ordered collection of elements where each element can be of different type

accessed through index

example code:
Objective: Use a tuple to enforce a rigid structure where the position and type of elements are strictly defined.

// variables.tf
# Ingress values
variable "ingress_values" {
    type = tuple([ number, string, number ])
    default = [ 443, "tcp", 443 ]

}

//main.tf
# Create Security Group to allow TLS traffic

resource "aws_security_group" "allow_tls" {
  name        = "allow_tls"
  description = "Allow TLS inbound traffic and all outbound traffic"
  vpc_id      = aws_vpc.myvpc.id

  tags = {
    Name = "allow_tls"
  }
}

resource "aws_vpc_security_group_ingress_rule" "allow_tls_ipv4" {
  security_group_id = aws_security_group.allow_tls.id
  cidr_ipv4         = var.cidr_block[1]
  from_port         = var.ingress_values[0]
  ip_protocol       = var.ingress_values[1]
  to_port           = var.ingress_values[2]
  description       = "Allow TLS inbound traffic from specific CIDR block"
}

Object:
Object is a collection of named attributes, where each attribute has a defined type.

accessed via dot notation

example code:
Objective: Use an object to group multiple configuration values of different types under a single variable, improving code organization.

// variables.tf
variable "config" {
    type = object({
      region = string
      monitoring = bool
      instance_count = number
    })
    default = {
      region = "us-east-1"
      monitoring = true
      instance_count = 1
    }
}

// main.tf
resource "aws_instance" "ec2_instance" {
  ami = "ami-0fa3fe0fa7920f68e"
  count = var.config.instance_count
  monitoring = var.config.monitoring
  region = var.config.region
}

In this way we use the type constraints in different use cases.

@piyushsachdeva

Day-06: AWS Terraform Project Structure Best practices

Bhaskara teja Bulusu — Sat, 29 Nov 2025 17:58:07 +0000

File Structure
Keeping everything such as variables, locals, providers, backend, outputs, resources related code in one file isn't a best practice and becomes an overhead as infrastructure grows and unmanageable.

There is a standard structure that needs to be followed by every DevOps engineer which is essential for scalability and maintainability and one of the recommended project structure is:

project-root/
├── backend.tf # Backend configuration
├── provider.tf # Provider configurations
├── variables.tf # Input variable definitions
├── locals.tf # Local value definitions
├── main.tf # Main resource definitions
├── vpc.tf # VPC-related resources
├── security.tf # Security groups, NACLs
├── compute.tf # EC2, Auto Scaling, etc.
├── storage.tf # S3, EBS, EFS resources
├── database.tf # RDS, DynamoDB resources
├── outputs.tf # Output definitions
├── terraform.tfvars # Variable values
└── README.md # Documentation

Terraform File Loading

Terraform loads all the files with .tf extension in the current directory
Terraform loads the files in lexicographical order (Alphabetical)
File names doesn't affect any code inside them
The above file structure is just an example and recommended by Hashicorp and this varies from organization and their use case
Another approach is to separate the files based on the environments or based on the resources as well

File organization principles

Separation of concerns
Logical Grouping
Consistent naming
Modular Approach
Documentation

Best practices

Consistent naming of file names
Split the files based on functionality
Size management - keep files manageable (<500 lines)
Documentation
Logical Grouping

A well organized structure not only improves readability but also streamlines collaboration and long term maintenance

@piyushsachdeva

Day-05: Terraform variables in AWS

Bhaskara teja Bulusu — Fri, 28 Nov 2025 15:39:40 +0000

Why do we need variables ?
To use the specific value repeatedly such as environment, tag names, bucket names etc., instead of writing the same value everywhere we just store them and use when needed which increases reusability in the code.

Variables
Variables are classified into two types

Based on purpose
Based on Value

Based on Purpose

Input
Output
Local

Based on value

Primitive --> String, number, bool
Complex --> list, tuple, set, map, object
ANY and NULL

Input Variables
variables which are used in the code when needed
Syntax:

variable "variable_name"{

     default = "dev"
     type = string  //this is not mandatory. if you don't mention the type of the variable, the terraform will autodetect and use ANY type
}

# Accessing the Variable
var.variable_name
${} // for concatenation of string

#Example:
Name = "${var.variable_name} - Bucket"

Local variables
variables declared in the locals block and accessed anywhere in the code
Syntax:

locals{
   env = "value"
   bucket_name="value"
}

#Accessing locals
local.local_variable_name

Output Variable
the variable which gives output once the resource has been provisioned and the output variables are generally printed on the console
Syntax:

output "variable_name"{
    value = value // Value of the variable you want as output
    description = "description_about_the_output_variable"
}

Ways to declare variables
we can declare variables in many ways:

Using the default
Environment variables export TF_VAR_variable_name="variable_value"
using terraform.tfvars file variable = "variable_value"
using terraform.tfvars.json file (similar to terraform.tfvars file but in json format)
*auto.tfvars (or) *.auto.tfvars.json files
ANY -var in CLI terraform plan -var="variable=variable_value"
ANY -var-file (variable files)

# In variables.tfvars
variable "variable_name"{
   default = "variable_value"
}

# Use this file in command line
terraform plan -var-file=variables.tfvars

Commands

terraform output  #show all outputs
terraform output variable_name      # show the output of specific variable
terraform output -json       #show the outputs in json format

# Clean up 
unset TF_VAR_variable_name

In this way we create variables in different ways.

@piyushsachdeva

Day-04: Terraform state file management using S3 Bucket

Bhaskara teja Bulusu — Thu, 27 Nov 2025 13:40:24 +0000

How terraform updates Infrastructure ?

When we run the terraform apply command, some files are created such as terraform.tfstate, terraform.tfstate.backup and terraform compares desired state with the actual state and provision the resources and update the infrastructure accordingly.

Desired state: The infrastructure we wish to create
Actual state: The current infrastructure we are having

State file management
In the terraform.tfstate, terraform.tfstate.backup files, sensitive information such as account Id's and resource names are present and in addition to that, modifying these files makes the state files corrupted. So, we shouldn't store in the production server or locally. To overcome this we store the state files in the remote backend instead of storing directly in the server

Storing the state files in the remote backend such as AWS S3 secures and stores separately which is easy to manage.

State file Best practices:

Store file to Remote backend
Don't update/delete the files
State locking --> a process which locks the file making the file inaccessible for others
Isolation of state file --> separate state files for different environments
Regular backup

Code for storing state files in the Remote backend (S3 Bucket)

terraform {
  backend "s3" {
    bucket = "bhaskaratejabulusu-state-files-day04"
    key = "dev/terraform.tfstate"
    region = "us-east-1"
    encrypt = true
    use_lockfile = true

  }
}

Make sure that the remote backend in this case S3 bucket is already created/available before running the terraform commands.
Usually this is done by CI/CD pipeline before terraform provisions resources

Security in S3 bucket:

S3 versioning enable
IAM minimal to S3
S3 Bucket Policy
Encryption (Server Side Encryption)
Access Logging

terraform state list
You can use the above command to list resources in state

@piyushsachdeva