Forem: Dulanjana Lakmal

Amazon EKS to Deprecate AL2 AMIs: How to Migrate with eksctl

Dulanjana Lakmal — Tue, 23 Sep 2025 11:48:33 +0000

Amazon Elastic Kubernetes Service (EKS) has announced a major change:

After November 26, 2025, Amazon EKS will no longer publish EKS-optimized Amazon Linux 2 (AL2) AMIs.
Kubernetes 1.32 will be the final version with AL2 AMI support.
From Kubernetes 1.33 onwards, EKS will only release Amazon Linux 2023 (AL2023) and Bottlerocket based AMIs.

This means that organizations running EKS clusters with AL2 worker nodes must migrate before upgrading beyond Kubernetes 1.32.

Why is Amazon EKS Ending AL2 AMIs?

Amazon Linux 2 has been the default for many workloads on AWS for years. However, AWS is now moving towards more modern operating systems:

Amazon Linux 2023 (AL2023): Successor to AL2, providing long-term support, predictable release cycles, and better security patching.
Bottlerocket: A container-optimized OS with an immutable root filesystem and reduced attack surface.

Both offer:

Improved security posture (predictable updates, hardened defaults).
Performance optimizations for cloud-native workloads.
Future-proofing for Kubernetes versions beyond 1.32.

What Does This Mean for EKS Users?

If your clusters run Amazon Linux 2 node groups, you can continue using them up to Kubernetes 1.32.
When you plan to upgrade to Kubernetes 1.33 or later, you must migrate your nodes to AL2023 or Bottlerocket.
After Nov 26, 2025, there will be no new AL2 AMIs or security patches, even if you stay on older Kubernetes versions.

Migration Strategy with eksctl

The good news: you don’t need to rebuild your cluster. With eksctl, you can replace node groups or upgrade them in place while keeping your control plane and workloads intact.

🔹 Option 1: Create a New AL2023 Node Group

You can add a new node group running AL2023 alongside your existing AL2 group.

eksctl create nodegroup \
  --cluster my-cluster \
  --name al2023-ng \
  --node-type t3.medium \
  --nodes 3 \
  --nodes-min 2 \
  --nodes-max 5 \
  --managed \
  --ami-family AmazonLinux2023

Then:

Drain old nodes:

   kubectl drain <old-node-name> --ignore-daemonsets --delete-local-data

Delete old node group once workloads are migrated:

   eksctl delete nodegroup --cluster my-cluster --name al2-ng

🔹 Option 2: Update Existing Node Group to AL2023

If you want to upgrade in place:

cluster.yaml (snippet):

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-cluster
  region: ap-southeast-1

nodeGroups:
  - name: al2023-ng
    instanceType: t3.medium
    desiredCapacity: 3
    amiFamily: AmazonLinux2023

Apply the upgrade:

eksctl upgrade nodegroup --config-file=cluster.yaml --name=al2023-ng

This will cordon, drain, and replace nodes with AL2023-based ones.

🔹 Option 3: Move to Bottlerocket

For security-focused or container-only workloads, Bottlerocket is a strong choice:

eksctl create nodegroup \
  --cluster my-cluster \
  --name bottlerocket-ng \
  --node-type t3.medium \
  --nodes 3 \
  --nodes-min 2 \
  --nodes-max 5 \
  --managed \
  --ami-family Bottlerocket

Verifying Migration

After migration, confirm that nodes are running the new OS:

kubectl get nodes -o wide
kubectl describe node <node-name> | grep "OS Image"

Expected outputs:

AL2023: Amazon Linux 2023
Bottlerocket: Bottlerocket OS

Best Practices

Test first in staging before production.
Use rolling upgrades: never drain all nodes at once.
Automate configs: keep cluster.yaml under version control for repeatable upgrades.
Monitor workloads: watch CloudWatch and Kubernetes metrics after migration.

Final Thoughts

Amazon EKS ending support for AL2 AMIs is a big change — but also a chance to modernize.

Short term: AL2 remains usable until Kubernetes 1.32.
Long term: Migrate to AL2023 (closest successor) or Bottlerocket (security-focused OS).

By starting your migration early and using eksctl to manage node group upgrades, you can ensure a smooth transition before the November 2025 cutoff.

Setting Up Modular Capability Plugins (MCP) with Amazon Q on Arch Linux

Dulanjana Lakmal — Wed, 14 May 2025 22:01:55 +0000

Hello everyone!
Today I'm writing about one of the most viral topics in the developer world right now: Modular Capability Plugins (MCP).

What are MCPs?
MCPs (Modular Capability Plugins) are specialized extensions that enhance AI assistants like Amazon Q with specific capabilities. Think of MCPs as "super-powered tool belts" for AI assistants - they give these assistants specialized knowledge and abilities to perform specific tasks far better than they could with general training alone.

We can think like this if Amazon Q is like a smartphone out of the box, MCPs are like specialized apps you install to transform it from a general-purpose device into a professional-grade tool for specific tasks. Just as you might install Photoshop for image editing or Final Cut Pro for video production, MCPs add specialized capabilities to your AI assistant.

My Experience with Amazon Q MCPs
For the past month, I've been using Amazon Q Chat service for my day-to-day DevOps and CloudOps tasks. It's been an incredibly helpful tool that streamlines my workflow. Since I'm running Arch Linux on my personal laptop, I decided to set up several specialized MCPs to enhance my productivity.

The Challenge
As a cloud engineer, I frequently encounter several time-consuming tasks:

AWS architecture diagrams have always been a critical but manual and time-consuming task for developers and cloud architects
Searching through AWS documentation efficiently can be challenging
Following Terraform best practices and security-first development workflows requires constant reference checking

The Solution: Custom MCPs
To address these challenges, I've set up the following MCPs:

awslabs.aws-diagram-mcp-server *- For generating AWS architecture diagrams automatically
**awslabs.aws-documentation-mcp-server *- For searching AWS documentation using the official AWS search API, getting content recommendations, and converting documentation to markdown format
**awslabs.terraform-mcp-server - For AWS Terraform best practices, security-first development workflows, Checkov integration, AWS provider documentation, AWS-IA GenAI modules, and Terraform workflow execution

Setup Guide for Arch Linux Prerequisites
Before beginning, make sure you have:

Python 3.10
python-uv (Python packaging tool)
AWS CLI configured locally with an AWS Builder ID for accessing Amazon Q
GraphViz installed (https://www.graphviz.org/)

Installation Steps

Install Amazon Q on Arch Linux

curl --proto '=https' --tlsv1.2 -sSf "https://desktop-release.q.us-east-1.amazonaws.com/latest/q-x86_64-linux.zip" -o "q.zip"
unzip q.zip
./q/install.sh

After installation, you should see an "amazonq" folder under your .aws folder.

Create an MCP configuration file:

vim ~/.aws/amazonq/mcp.json

Add the following content to configure all three MCP servers:

{
  "mcpServers": {
    "awslabs.terraform-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.terraform-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": []
    },
   "awslabs.aws-documentation-mcp-server": {
        "command": "uvx",
        "args": ["awslabs.aws-documentation-mcp-server@latest"],
        "env": {
          "FASTMCP_LOG_LEVEL": "ERROR"
        },
        "disabled": false,
        "autoApprove": []
    },
   "awslabs.aws-diagram-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.aws-diagram-mcp-server"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "autoApprove": [],
      "disabled": false
    }
  }
}

Note: If you don't need all three MCPs, you can remove the ones you don't want from your mcp.json file.

Using Your MCPs

Open Amazon Q - you should see it initializing the MCP servers
Enter /tools in the chat to check what tools you have access to via Amazon Q MCPs

If you encounter any issues, double-check your Python version, the uv package installation, and that GraphViz is properly installed

Testing Your Setup
To verify everything is working correctly, try a sample prompt like:

generate an aws architecture diagram for sample s3 bucket with cloudfront for hosting static website

This should trigger the diagram MCP to create a visualization of the architecture. It should produce an output similar to the one below:

This is the end of my post. Thank you for reading through it. If you liked it, please consider sharing it with your colleagues for better reach.

Managing Multiple Bitbucket Repositories with Terraform: A Deep Dive into terraform-bitbucket-multi-repo-manager

Dulanjana Lakmal — Mon, 14 Oct 2024 16:15:48 +0000

Introduction

In the fast-paced world of software development, efficiently managing multiple repositories is crucial. This article introduces terraform-bitbucket-multi-repo-manager, a powerful Terraform configuration that streamlines the process of creating and managing multiple Bitbucket repositories. We'll explore how this tool can save time, reduce errors, and improve consistency in your development workflow.

The Motivation: A Real-World Problem

Over the past few days, our team faced a significant challenge. We experienced a surge in the number of Bitbucket repositories we needed to create and manage. Each new repository required the same set of repetitive tasks:

Creating the repository
Configuring environment variables
Setting up deployment variables

This manual, repetitive process was not only time-consuming but also prone to errors. We realized we needed a more efficient, automated solution.

The Solution: Terraform to the Rescue

To address this challenge, we developed a Terraform module: terraform-bitbucket-multi-repo-manager. This module automates the entire process of repository creation and configuration.
Before we dive into the details, we want to give a big shout-out to Ilia Lazebnik (DrFaust92) for his excellent Bitbucket Terraform provider. Without his work, our solution wouldn't have been possible. Thank you, Ilia!

What terraform-bitbucket-multi-repo-manager Offers

Our Terraform configuration addresses the challenges of managing multiple repositories by automating several key processes:

Automated Repository Creation: Create multiple repositories with a single Terraform apply.
Consistent Configuration: Ensure all repositories adhere to your organization's standards.
Variable Management: Easily set and manage repository and deployment variables.
Deployment Configuration: Set up deployment environments for each repository.

Benefits and Use Cases

DevOps Efficiency: Automate the creation of new repositories for new projects or services, saving hours of manual work.
Consistency: Ensure all repositories follow the same structure and have the necessary variables and deployments set up, reducing configuration errors.
Scalability: Easily manage tens or hundreds of repositories without manual intervention, perfect for growing teams and projects. Compliance: Enforce organization-wide policies and configurations across all repositories.
Version Control: Keep your infrastructure as code, allowing for easy tracking of changes and rollbacks if necessary.

Getting Started

To use terraform-bitbucket-multi-repo-manager:

Clone the repository:

git clone https://github.com/lakmal-ya/terraform-bitbucket-multi-repo-manager.git

Configure your Bitbucket credentials and desired repository structure in terraform.tfvars_sample

Run following to initialize the Terraform working directory

terraform init

Run following to see the planned changes

terraform plan

Run following to create or update your Bitbucket repositories

terraform apply

Conclusion

terraform-bitbucket-multi-repo-manager was born out of a real need in our development workflow. It showcases the power of Infrastructure as Code in solving practical, day-to-day challenges in managing complex, multi-repository setups. By automating the creation and configuration of Bitbucket repositories, it allows development teams to focus on what matters: writing great code.

Whether you're managing a handful of repositories or hundreds, this Terraform configuration can significantly streamline your workflow and ensure consistency across your organization. It's a testament to how the right tools and some automation can transform a tedious, error-prone process into a smooth, efficient operation.

As we embrace DevOps practices and cloud-native development, tools like terraform-bitbucket-multi-repo-manager will become increasingly valuable. We'd like to encourage you to try it out, contribute to the project, and adapt it to your organization's needs.
Remember, the goal of DevOps is not just to automate tasks, but to improve collaboration, increase efficiency, and deliver better software faster. With terraform-bitbucket-multi-repo-manager, you're taking a significant step in that direction.

If you found this guide helpful, give it a clap! 👏
Don't forget to follow me for more insightful content on Linux, AWS best practices, cloud security, and technology updates! 🚀

And if you enjoyed this information and feel like supporting my virtual endeavours, consider buying me a ☕️ coffee! Your support keeps the bytes flowing. Cheers! ☕️😊 Buy Me a Coffee.

Securing Linux Filesystems: Best Practices for DevOps Security

Dulanjana Lakmal — Tue, 03 Sep 2024 14:17:26 +0000

As Linux file systems are a fundamental element in maintaining system integrity in this fast-changing world of DevOps and cloud computing, it is necessary to ensure that they are well-secured. Therefore, the article looks into best practices that DevOps persons can apply to fortify their Linux file systems’ security to guarantee data safety and continuity of operations.

1. Introduction to Linux Filesystem Security

Linux filesystems form the backbone of data storage and management in most DevOps environments. Securing these filesystems is crucial to protect sensitive information, maintain system stability, and prevent unauthorized access. A comprehensive security strategy involves multiple layers of protection, from basic file permissions to advanced encryption techniques.

2. Implementing Proper File Permissions and Ownership

The foundation of Linux filesystem security lies in its permission model:

Use the principle of least privilege: Grant only the minimum necessary permissions.
Regularly audit and update file permissions using commands like chmod and chown.
Implement umask settings to control default permissions for new files and directories.

Example:

# Set restrictive permissions on a sensitive file
chmod 600 /path/to/sensitive_file

# Change ownership to a specific user and group
chown user:group /path/to/directory

3. Using Access Control Lists (ACLs) for Fine-Grained Control

When standard permissions are not enough, ACLs provide more granular control:

Use setfacl and getfacl to manage ACLs.
ACLs allow you to set permissions for specific users or groups without changing the base permissions.

Example:

# Grant read access to a specific user
setfacl -m u:username:r /path/to/file

# View ACLs on a file
getfacl /path/to/file

4. Securing Mount Points and Partitions

Properly configuring mount points and partitions enhances security:

Use the noexec, nosuid, and nodev mount options where appropriate.
Separate sensitive directories into different partitions.
Implement disk quotas to prevent resource exhaustion attacks.

Example in /etc/fstab:

/dev/sda2 /tmp ext4 defaults,noexec,nosuid,nodev 0 0

5. Encrypting Sensitive Data and Filesystems

Encryption adds a crucial layer of protection:

Use LUKS (Linux Unified Key Setup) for full-disk encryption.
Implement eCryptfs or EncFS for directory-level encryption.
Consider using dm-crypt for block device encryption.

Example:

# Create an encrypted container
cryptsetup luksFormat /dev/sdb1

# Open the encrypted container
cryptsetup luksOpen /dev/sdb1 secret_data

6. Regular Security Audits and Monitoring

Continuous monitoring is essential for maintaining security:

Use tools like Auditd to monitor filesystem changes.
Implement intrusion detection systems (IDS) like AIDE or Tripwire.
Regularly scan for vulnerabilities using tools like Lynis.

Example:

# Set up a basic audit rule
auditctl -w /etc/passwd -p wa -k passwd_changes

7. Backup and Recovery Strategies

A robust backup strategy is crucial for data protection and disaster recovery:

Implement regular, automated backups using tools like rsync or Bacula.
Store backups in secure, off-site locations.
Regularly test recovery procedures to ensure data integrity.

Example rsync backup:

rsync -avz --delete /source/directory/ user@remote:/backup/directory/

8. DevOps-Specific Considerations for Filesystem Security

In a DevOps context, additional considerations include:

Implement Infrastructure as Code (IaC) to manage and version control filesystem configurations.
Use containerization technologies like Docker to isolate applications and their filesystems.
Employ secrets management tools to handle sensitive data securely.

9. Automated Security Checks in CI/CD Pipelines

Integrate security checks into your CI/CD pipelines:

Use tools like CIS-CAT or OpenSCAP to automate compliance checks.
Implement pre-commit hooks to catch security issues before they enter the codebase.
Regularly scan Docker images and containers for vulnerabilities.

Example GitLab CI/CD job:

security_scan:
  stage: test
  script:
    - lynis audit system
    - docker scan my-image:latest

10. Conclusion and Best Practices Summary

Securing Linux filesystems in a DevOps environment requires a multi-faceted approach:

Implement and regularly review file permissions and ACLs.
Use encryption for sensitive data and filesystems.
Secure mount points and partitions with appropriate options.
Conduct regular security audits and monitoring.
Maintain robust backup and recovery strategies.
Integrate security checks into CI/CD pipelines.
Stay informed about the latest security threats and best practices.

By following these best practices, DevOps teams can significantly enhance the security of their Linux filesystems, protecting valuable data and maintaining system integrity in an increasingly complex and threat-prone digital landscape.

If you found this guide helpful, give it a clap! 👏
Don't forget to follow me for more insightful content on Linux, AWS best practices, cloud security, and technology updates! 🚀

And if you enjoyed this information and feel like supporting my virtual endeavours, consider buying me a ☕️ coffee! Your support keeps the bytes flowing. Cheers! ☕️😊 Buy Me a Coffee.

Automating EC2 Instances Start/Stop with Terraform, Lambda, and Python

Dulanjana Lakmal — Sun, 28 May 2023 14:16:36 +0000

AWS Lambda is a serverless computing service provided by Amazon Web Services (AWS). It allows you to run your code without provisioning or managing servers. With Lambda, you can execute your code in response to events, such as changes to data in an S3 bucket, updates to a DynamoDB table, or even an HTTP request.

One common use case of AWS Lambda is automating the start and stop of Amazon EC2 instances. EC2 instances are virtual servers in the cloud that provide computing resources for various applications. By automating the start and stop process, you can optimize costs by running instances only when they are needed.

Here’s how the process works:

You write your code logic, such as the code snippet you provided earlier, to perform actions like retrieving instance IDs, checking their state, and starting or stopping them.
You package your code and dependencies into a deployment package, typically a ZIP file.
You create an AWS Lambda function and upload the deployment package to it.
You configure the Lambda function’s trigger to determine when it should execute. For example, you can schedule the function to run at specific times using CloudWatch Events or trigger it manually through API Gateway.
When the Lambda function is triggered, it executes the code within the lambda_handler function.
The code interacts with the AWS SDKs to communicate with the EC2 service, retrieve instance information, and perform the start or stop actions on the instances.
The results of the Lambda function’s execution, such as success or error messages, are logged and can be monitored using CloudWatch Logs.
AWS Lambda is a serverless computing service provided by Amazon Web Services (AWS). It allows you to run your code without provisioning or managing servers. With Lambda, you can execute your code in response to events, such as changes to data in an S3 bucket, updates to a DynamoDB table, or even an HTTP request.

Here’s how the process works:

You write your code logic, such as the code snippet you provided earlier, to perform actions like retrieving instance IDs, checking their state, and starting or stopping them.
You package your code and dependencies into a deployment package, typically a ZIP file.
You create an AWS Lambda function and upload the deployment package to it.
You configure the Lambda function’s trigger to determine when it should execute. For example, you can schedule the function to run at specific times using CloudWatch Events or trigger it manually through API Gateway.
When the Lambda function is triggered, it executes the code within the lambda_handler function.
The code interacts with the AWS SDKs to communicate with the EC2 service, retrieve instance information, and perform the start or stop actions on the instances.
The results of the Lambda function’s execution, such as success or error messages, are logged and can be monitored using CloudWatch Logs.
By leveraging AWS Lambda, you can automate the start and stop process, eliminating the need for manual intervention. This helps optimize costs by running instances only when necessary, such as during business hours or during specific time periods.

It’s worth mentioning that AWS Lambda offers many other capabilities beyond EC2 instance management. It supports various programming languages, provides scalability and fault tolerance out of the box, and integrates with other AWS services for building serverless applications.

I hope this provides you with a good understanding of AWS Lambda and its usage in automating the start and stop of EC2 instances.

import boto3
import os
import json

def lambda_handler(event, context):
    try:
        tags = os.environ["Tags_json"]
        dictionary = json.loads(tags) # Convert str to Dictionary using Json
        print(dictionary)
        print(type(dictionary))

        ec2 = boto3.client('ec2')

        instance_ids = [] # Placeholder for instance ids

        for (key, value) in dictionary.items():
            print(f'Key: {key}')
            print(f'Value: {value}')

            NextToken = '' # Placeholder for NextToken

            # Describe instances with the specified tag key, value, and stopped state
            response = ec2.describe_instances(
                Filters=[
                    {'Name': 'tag-key', 'Values': [key]},
                    {'Name': 'tag-value', 'Values': [value]},
                    {'Name': 'instance-state-name', 'Values': ['stopped']}
                ],
                MaxResults=20
            )
            print(f'EC2 InstanceIds Response: {response}')

            # This loop fetches all the instance ids using pagination with NextToken
            while True:
                for reservation in response['Reservations']:
                    for instance in reservation['Instances']:
                        instance_ids.append(instance['InstanceId'])
                        print(f'Number of instances: {len(instance_ids)}')
                        print(f'InstanceIds : {instance_ids}')

                # If NextToken is present, it retrieves the next set of instances
                if 'NextToken' in response:
                    print("Testing NextToken")
                    response = ec2.describe_instances(
                        Filters=[
                            {'Name': 'tag-key', 'Values': [key]},
                            {'Name': 'tag-value', 'Values': [value]},
                            {'Name': 'instance-state-name', 'Values': ['stopped']}
                        ],
                        NextToken=response['NextToken']
                    )
                    print(f'Response: {response}')
                    print(f'NextToken: {NextToken}')
                else:
                    break

        if instance_ids:
            # Start the instances
            ec2.start_instances(InstanceIds=instance_ids)
            print("EC2 instances started: {}".format(instance_ids))
        else:
            print("No EC2 instances matching the filter.")

    except Exception as e:
        print("An error occurred:", str(e))

The code snippet you provided is designed to be used within an AWS Lambda function. When executed, the code performs the following actions:

It imports the necessary libraries: boto3 for interacting with AWS services, os for accessing environment variables, and json for working with JSON data.
The lambda_handler function is the entry point for the Lambda function. It takes in two parameters: event and context. These parameters provide information about the triggering event and the execution context.
Inside the lambda_handler, the code retrieves the environment variable Tags_json using os.environ. This variable is expected to contain a JSON string representing a dictionary of tags.
The code then uses json.loads to convert the JSON string into a dictionary. This dictionary represents the tags and their corresponding values that will be used to filter the EC2 instances.
The code initializes the ec2 client from boto3 to interact with the EC2 service.
A list instance_ids is created as a placeholder for storing the IDs of instances that match the specified tags and are in a stopped state.
The code iterates over the key-value pairs in the dictionary using a for loop. For each pair, it performs the following actions:
Prints the key and value.
Sets the NextToken variable to an empty string as a placeholder.
Calls ec2.describe_instances with filters based on the tag key, tag value, and instance state (stopped). This retrieves information about the instances that match the filters.
Prints the response and the number of instances found.
Checks if a NextToken is present in the response. If so, it retrieves the next set of instances by making another describe_instances call with the NextToken parameter. This process continues until all instances have been retrieved.

If instance_ids is not empty, it means there are instances that match the filters. The code calls ec2.start_instances with the InstanceIds parameter set to the list of instance IDs. This starts the instances.
If instance_ids is empty, it means there are no instances that match the filters.
Any exceptions that occur during the execution are caught by the except block, and the error message is printed.

When you deploy this code as an AWS Lambda function, you can configure it to be triggered based on specific events, such as a schedule or manual invocation. Once triggered, the function will execute and perform the desired actions of starting the EC2 instances based on the specified tags and their current state.

To make it more convenient for you, I have created Terraform code that sets up the infrastructure required for the stop/start Lambda function. You can find the code in the following Git repository:

GitHub Repository: EC2-Instances-Start-Stop-with-Terraform-Lambda

The Terraform code in this repository will help you create the necessary resources, including the Lambda function, IAM roles, and any other dependencies required for automating the start and stop of EC2 instances.

Feel free to explore the repository and utilize the Terraform code to set up the environment for your use case.

Terraform list of object validation

Dulanjana Lakmal — Fri, 24 Feb 2023 17:36:18 +0000

Introduction for Terraform

Terraform is an open-source infrastructure as code (IaC) tool developed by HashiCorp. It allows users to define and provision infrastructure resources such as virtual machines, storage accounts, and networking components in a declarative way using a high-level configuration language.

With Terraform, infrastructure can be described in code, allowing for version control, collaboration, and automation. Terraform also supports a wide range of cloud providers, including Amazon Web Services, Microsoft Azure, Google Cloud Platform, and others, as well as on-premises solutions.

Terraform uses a state file to keep track of the current state of the infrastructure, which can be used to plan, apply, and manage changes to the infrastructure over time. This makes it easier to manage and maintain complex infrastructure environments, and allows for easier scaling and modification of infrastructure as needed.

What is list of object?

In Terraform, a list of objects is a data structure that allows you to define a list of maps, where each map represents an object with a set of key-value pairs. This data structure is often used to represent a collection of similar resources or configurations that need to be created in a single block of code.

Here’s an example of a list of objects in Terraform, which represents a collection of virtual machines to be created:

virtual_machines = [  { 
  name = "vm-1"   
  size = "Standard_DS2_v2"  
  image = "UbuntuServer:16.04.0-LTS"  },
{ 
  name = "vm-2"
  size = "Standard_DS1_v2"
  image = "UbuntuServer:18.04-LTS"  },
{    
  name = "vm-3"
  size = "Standard_DS3_v2"
  image = "WindowsServer:2016-Datacenter"
  }]

In this example, virtual_machines is a list of maps, where each map represents a virtual machine configuration with name, size, and image attributes. This list can then be used in Terraform to create multiple virtual machines with a single module or resource block.

Now is validation part of this

variable "virtual_machines" {
  description = "virtual_machines"
  type        = list(object({
    name  = string
    size  = string
    image = string
  }))
  default     = []
  validation {
    condition     = can(regex("^(Standard_DS3_v2|Standard_DS1_v2)$", var.virtual_machines[0].size))
    error_message = "Invalid input, options: \"Standard_DS3_v2\",\"Standard_DS1_v2\"."
  }
}

This is an example of a Terraform variable definition for a list of objects called virtual_machines. Let's break it down:

description: This is an optional field that allows you to add a description of the variable for documentation purposes.
type: This defines the type of the variable, which in this case is a list of objects. The objects have three attributes, name, size, and image, each of which is a string.
default: This sets the default value for the variable, which in this case is an empty list.
validation: This allows you to add a validation condition to the variable. In this example, the condition argument uses the regex function to check that the size attribute of the first object in the list matches either "Standard_DS3_v2" or "Standard_DS1_v2". If the condition is not met, the error_message argument is used to generate an error message.
var.virtual_machines[0].size is an expression that refers to the size attribute of the first object in the virtual_machines list.
In Terraform, the var prefix is used to reference a variable value. In this case, var.virtual_machines refers to the value of the virtual_machines variable, which is a list of objects.
[0] is used to access the first object in the list. Since Terraform uses zero-based indexing, [0] refers to the first element of the list.
Finally, .size is used to access the size attribute of the first object in the list.
Overall, var.virtual_machines[0].size is used in the validation condition to check the size attribute of the first object in the list against the regular expression ^(Standard_DS3_v2|Standard_DS1_v2)$. If the size does not match either of these values, the validation condition will fail and an error message will be generated.

This variable definition is useful when you want to define a list of virtual machines with specific sizes and ensure that only the correct sizes are used. The validation argument helps to catch errors early by generating an error message if an invalid size is specified.