So now you are doing AWS Hands-on and would like to create and attach a security group to your ec2 instance where you can login only from YOUR IP. How is that achieved?

Its simple now

Begin with writing a Bash script to read your current IP and lets call it "my-ip.sh”

#!/bin/bash

# Fetch the public IP address using an external service
ip_address=$(curl -s https://api.ipify.org)

# Output the public IP address
echo "{\"ip\": \"${ip_address}\"}"

Don’t forget to make it an executable file

$ chmod +x my-ip.sh

Next lets write simple Terraform code where we create a VPC and add Security Groups with one ingress rule of type SSH and the source to be my IP.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0.0"
    }
  }
}

provider "aws" {
  region  = var.region
  profile = var.profile
}

provider "local" {}

Let’s add variables too

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

variable "profile" {
  type    = string
  default = "default"
}

Now adding the data file

data "aws_caller_identity" "current" {}

data "aws_region" "current" {}

data "aws_vpc" "get_vpc_id" {
  filter {
    name   = "tag:Name"
    values = ["ANW-VPC"]
  }
  depends_on = [aws_vpc.hands_on_VPC]
}

data "external" "my_ip" {
  program = ["bash", "${path.module}/my-ip.sh"]
}

Now creating a very simple VPC

resource "aws_vpc" "hands_on_VPC" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "ANW-VPC"
  }
}

Time to create Security Groups of both default and a custom one with my ip as one ingress rule

resource "aws_default_security_group" "default" {
  vpc_id = data.aws_vpc.get_vpc_id.id
  ingress {
    protocol  = -1
    self      = true
    from_port = 0
    to_port   = 0
  }

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

resource "aws_security_group" "sg-ssh" {
  vpc_id = data.aws_vpc.get_vpc_id.id
  name   = "new"
  tags = {
    Name = "new"
  }
}

resource "aws_vpc_security_group_ingress_rule" "ssh" {
  ip_protocol       = "tcp"
  to_port           = 22
  from_port         = 22
  cidr_ipv4         = "${data.external.my_ip.result["ip"]}/32"
  security_group_id = aws_security_group.sg-ssh.id
}

Since the Security Group requires a proper CIDR notation, we use

"${data.external.my_ip.result["ip"]}/32"

And thats the end of it……. Try it and let me know

Ans : Ever changing AMI id of EC2 instances and the constant need to change them in the Terraform template.

There is a fix for this too.

All that needs to be done is get the "latest" AMI dynamically into your code base.

data "aws_ami" "amazon-linux-2" {
  most_recent = true

  filter {
    name   = "owner-alias"
    values = ["amazon"]
  }

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64*"]
  }
}

resource "aws_instance" "amzn2_linux_instance" {
  ami           = data.aws_ami.amazon-linux-2.id
  instance_type = "t2.micro"
}

Data Source is used to query and select the latest AMI. Let me explain the parameters here

• most_recent - Returns the most recent AMI, if there are more than one result

• filter1 - name is "owner-alias" is "amazon". As Amazon is the owner of Amazon2 Linux owner

• filter2 - "name" is the variable for the Amazon AMI name.

Pass these filtered values to "aws_instance" resource and you will have created your ec2 instance without having to hard code the ami.

Note: The AMI will be pulled from the default region 
configured using aws configure or by explicitly 
mentioning them in your providers.tf file

You can find more of them at https://www.hashicorp.com/blog/hashicorp-terraform-supports-amazon-linux-2

I will be following this by ways to dynamically bring other Operating Systems AMI.

Well, in the words of ChatGPT this is why hard coding considered a bad practice

Hard coding is considered a bad practice in software development for several reasons:

1. Lack of Flexibility: Hard coding refers to embedding specific values or configurations directly into the code, without using variables or configurable options. This approach makes it difficult to modify or adapt the code to different scenarios or requirements. Any changes to the hardcoded values require modifying the source code itself, which can be time-consuming and error-prone. It limits the code's flexibility and makes it less maintainable.

2. Code Duplication: Hard coding often leads to code duplication, where the same values or configurations are repeated multiple times in different parts of the codebase. This violates the DRY (Don't Repeat Yourself) principle, which promotes reusability and maintainability. Code duplication increases the chances of inconsistencies and bugs, as any modifications or updates must be made in multiple places.

3. Reduced Readability: Hardcoded values are typically represented as literal values directly in the code, which can make the code more difficult to read and understand. When the purpose or meaning of a particular value is not evident from the code itself, it requires additional effort to comprehend the code's behavior. Using variables or constants with meaningful names improves code readability and makes it easier for developers to understand the intent.

4. Maintenance Challenges: Hardcoding values makes code maintenance more challenging. When a change is needed, such as updating a configuration or modifying a value, it often requires modifying the code and recompiling the application. This process can be cumbersome, especially in larger projects or when the code is distributed across multiple systems. It is preferable to have configurations stored separately, allowing changes to be made without modifying the source code.

5. Testing and Debugging Issues: Hardcoding values can introduce difficulties in testing and debugging. For testing purposes, it is often necessary to simulate different scenarios or inputs. Hardcoded values can make it harder to vary inputs or configure the system for different test cases. Additionally, if an error occurs related to a hardcoded value, identifying and fixing the problem becomes more complicated.

6. Lack of Scalability: Hardcoded values are typically tied to specific contexts or environments. When the code needs to be scaled to handle larger data sets, increased load, or different configurations, hardcoding becomes a significant obstacle. Flexible and configurable code is essential for building scalable applications that can adapt to changing requirements.

Overall, hard coding limits flexibility, reusability, readability, maintainability, and scalability of the codebase. It is considered a bad practice because it makes code more rigid, error-prone, and difficult to maintain and evolve over time. Instead, it is recommended to use variables, constants, configuration files, or other techniques to decouple values from the code and make it more adaptable and maintainable.

So what do we do? Do we have a solution for this in Terraform?

The answer is "YES".

Instead of passing hard-coded AWS Resource names, there is a way to generate a random string and then pass on the same to the variables.

Using "random provider"

As a person who loves their pets, I am drawn towards using the provider "random_pet"

[Please add your own provider section for this]

1. provider

2. Generate Random parameter: The variable "length" here is - The length (in words) of the pet name. In the below example "length = 2" is the 2 complete words separated by "_".

# ******************************************************
#                    Random Generation
# ******************************************************
resource "random_pet" "name" {
  length  = 2
}

locals {
  prefix = "random-${random_pet.name.id}"
}

1. S3 bucket

# ******************************************************
#                    S3 Bucket
# ******************************************************

resource "aws_s3_bucket" "demo-s3" {
  bucket = "${local.prefix}-s3"
}

1. Lamda function with IAM Role

2.  # ******************************************************
    #                    Lambda functions
    # ******************************************************
   
    data "archive_file" "lambda_zip" {
      type        = "zip"
      source_dir  = "lambda"
      output_path = "lambda.zip"
    }
   
    resource "aws_lambda_function" "lambda" {
      filename         = data.archive_file.lambda_zip.output_path
      function_name    = "${local.prefix}-lambda"
      role             = aws_iam_role.iam_for_lambda.arn
      handler          = "lambda.lambda_handler"
      source_code_hash = data.archive_file.lambda_zip.output_base64sha256
      runtime          = "python3.9"
      timeout          = 900
    }
   
    # ******************************************************
    #                    IAM Role - Lambda
    # ******************************************************
   
    data "aws_iam_policy_document" "assume_role" {
      statement {
        effect = "Allow"
   
        principals {
          type        = "Service"
          identifiers = ["lambda.amazonaws.com"]
        }
   
        actions = ["sts:AssumeRole"]
      }
    }
   
    resource "aws_iam_role" "iam_for_lambda" {
      name               = "${local.prefix}-iam-lambda"
      assume_role_policy = data.aws_iam_policy_document.assume_role.json
    }
   

   5. Now lets see before hand what would my "pet" name before we see the name in the AWS Resources.

# ***************************************************
#                    Output
# ***************************************************

output "s3_bucket" {
  value = aws_s3_bucket.demo-s3.bucket
}

Well the pet name is

Let's check them out in the AWS Console

S3 Bucket

IAM Role

Lambda function

As you can see that the pet name "chief-hound" (with length = 2 ) has been added to the names of S3, IAM and Lambda Resources.

The word "random" can be switched with the name that is needed in the project. For eg. Application name.

All you have to do is add the resource code and use the format mentioned in the sections below to run plan/apply or destroy.

# providers.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "4.60.0"
    }
  }
}

provider "aws" {
  region  = var.region
  profile = var.profile
}

# variables.tf
variable "region" {}
variable "profile" {}

variable "ec2-role-name" {}

# iam.tf
resource "aws_iam_role" "ec2-iam-role" {
    name = "my-ec2-iam-role"
    assume_role_policy = jsonencode({
        Version = "2012-10-17"
        Statement = [
            {
                Action = "sts:AssumeRole"
                Effect = "Allow"
                Sid = ""
                Principal = {
                    Service = "ec2.amazonaws.com"
                }
            }
        ]
    })  
}

# target_iam.tfvars
profile = "aws-terraform"
region  = "us-east-1"

ec2-role-name = "my-ec2-iam-role"

Syntax:

$ terraform apply -var-file <file>.tfvars -target="<AWS_Terraform_Resource_name>.<Resource>" --auto-approve

Example:

$ terraform apply -var-file target_iam.tfvars -target="aws_iam_role.ec2-iam-role" --auto-approve

Any resource can be selectively destroyed provided it does not have any dependencies or the related dependencies are also deleted.

$ terraform destroy -var-file target_iam.tfvars -target="aws_iam_role.ec2-iam-role" --auto-approve

NOTE: It is not recommended to use -target for routine operations, since this can lead to undetected configuration drift and confusion about how the true state of resources relates to configuration.

Ref: https://developer.hashicorp.com/terraform/cli/commands/plan

Bringing the first in the series is adding multiple email ID subscriptions to our SNS Topic.

While you all know the Terraform Basics, I would not go into much detail on them. I have structured the code in a parameterized manner and would be following the same pattern in all my posts.

# providers.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "4.60.0"
    }
  }
}

provider "aws" {
  region  = var.region
  profile = var.profile
}

# variables.tf
variable "region" {}
variable "profile" {}

variable "sns-topic" {}
variable "sns-topic-subscription" {}

# locals.tf
locals {
  emails = ["emailid1@email.com","emailid2@email.com","emailid3@email.com"]
}

# sns.tf
resource "aws_sns_topic" "sns_topic" {
  name = var.sns-topic
}

resource "aws_sns_topic_subscription" "sns_topic_subscription" {
  count = length(local.emails)
  topic_arn = aws_sns_topic.sns_topic.arn
  protocol  = "email"
  endpoint = local.emails[count.index]
}

# sns.tfvars
sns-topic              = "sns-test-topic"
sns-topic-subscription = "sns-test-subscription"

profile = "aws-terraform"
region  = "us-east-1"

The same can be achieved without the use of locals.tf as well. Then we use the "for_each" functionality and pass the values to it and then refer to the "value" in the endpoint section.

resource "aws_sns_topic_subscription" "sns_topic_subscription" {
  for_each = toset(["emailid1@email.com","emailid2@email.com","emailid3@email.com"])
  topic_arn = aws_sns_topic.sns_topic.arn
  protocol  = "email"
  endpoint = each.value
}

And as you already know the drill... Run the Terraform template

$ terraform init
$ terraform plan
$ terraform apply -var-file sns.tfvars --auto-approve
$ terraform destroy -var-file sns.tfvars --auto-approve

Prerequisite:

1. Ensure AWS CLI is installed and configured. Installation: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

   Configuration: (I have configured using "Short-term credentials" format) https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html

2. Ensure Terraform is installed

   https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli