DEV Community: Mahesh Upreti

Automating MFA in an Amazon EC2 Instance: Mastering Secure Access

Mahesh Upreti — Sun, 22 Mar 2026 07:14:48 +0000

Automating MFA in an Amazon EC2 instance adds a critical security layer to protect your infrastructure.

By configuring MFA for SSH access, you're ensuring that access requires more than just a private key or password. Users must also present a time-based one-time password (TOTP) generated by an MFA device, such as Google Authenticator or Authy. This means that even if an attacker obtains an SSH key, they cannot access the instance without the MFA token. MFA setup on an EC2 instance helps safeguard your system from unauthorized access and significantly reduces the risk of remote attacks.

In addition to MFA, SELinux (Security-Enhanced Linux) may be enabled on your Amazon Linux instance. This tutorial works if your EC2 instance doesn't have SELinux enabled, too. SELinux is a security mechanism that provides an additional layer of protection for the system by enforcing security policies that govern how processes interact with each other and the system’s files. But automating MFA in an Amazon EC2 instance with SELinux enabled requires ensuring that the necessary security contexts and policies are properly configured to allow the MFA process to work alongside SELinux's protections.

In this guide, we will walk through the following steps:

Setting up MFA on the EC2 instance for SSH login.
Ensure SELinux is properly configured to not interfere with the MFA process.
Testing the MFA-enabled SSH login to ensure that access is secure and compliant with both MFA and SELinux policies.

Key Components for MFA Setup in EC2 instance

An Amazon EC2 Instance running an Amazon Linux (or compatible version) with SELinux enabled.
Virtual MFA device (such as Google Authenticator or Authy).
SSH access is configured for the EC2 instance.
Sudo privileges on the EC2 instance to modify configurations.
The system has SELinux enabled and configured to permit the necessary changes required for implementing MFA.

Why You Need SELinux and MFA?

MFA: Protects against unauthorized access by requiring users to provide not only their SSH key but also a time-sensitive code from a registered MFA device.
SELinux: SELinux adds a security layer by actively controlling processes and access to files through strict security policies. To enable MFA on your EC2 instance, you must configure SELinux to allow the necessary modifications and ensure it doesn't block authentication-related operations.

By the end of this guide, you'll have successfully automated MFA in an Amazon EC2 for SSH access to your Amazon Linux instance, with SELinux configured to support the changes without breaking the system’s security context. This will significantly enhance your instance's overall security, making unauthorized access much more difficult.

Step 1: Installing Google Authenticator on the EC2 Instance

First, SSH into your EC2 instance. Once connected, switch to the root user (or use sudo for administrative tasks) and install the necessary software packages.

Install Google Authenticator and QRencode: Run the following commands to install the Google Authenticator PAM module and qrencode (for generating QR codes):

sudo dnf install google-authenticator qrencode -y

Initialize Google Authenticator: To enable MFA in AWS EC2, run the google-authenticator command for the user for whom you want to enable MFA (e.g., ec2-user). This command will generate a secret key and provide a QR code to scan with the Google Authenticator app.

google-authenticator -s ~/.ssh/google_authenticator

When you set up Google Authenticator on your EC2 instance, the system prompts you with several configuration questions to customize how MFA (Multi-Factor Authentication) operates. These prompts allow you to fine-tune the behavior of the authentication process—helping you strike the right balance between strong security and user convenience. Below is a detailed breakdown of each option and what it means:

Do you want authentication tokens to be time-based?

Prompt: Do you want authentication tokens to be time-based? (y/n)

Google Authenticator and most MFA apps use time-based tokens by default. These tokens expire after a short period, usually 30 seconds, and then generate a new token for the next time window. This time-based approach ensures that even if someone intercepts a token, they cannot reuse it later. Therefore, choosing Yes (y) to enable time-based tokens is recommended because it provides stronger security. Regular rotation of tokens reduces the risk of reuse or interception.

The system displays a QR code for you to scan or lets you manually enter the secret key into your authentication app. You add your account name and enable the time-based option. You must securely store the secret key, verification codes, and scratch codes generated during this process in case you lose access to the app. Remember that you can use each scratch code only once. Instead of entering the key manually, you will scan the QR code.
Next, you'll be prompted with several questions to configure MFA:

a. Do you want me to update your "/home/ec2-user/.ssh/.google_authenticator" file? (y/n)
When you configure Google Authenticator for Multi-Factor Authentication (MFA) on your EC2 instance, one of the prompts you will encounter is:
Do you want me to update your "/home/ec2-user/.ssh/.google_authenticator" file (y/n)?

The .google_authenticator file stores your secret key, OTP settings, and scratch codes crucial for MFA setup and recovery.

b. Do you want to disallow multiple uses of the same authentication token?
Prompt: Do you want to disallow multiple uses of the same authentication token? (y/n)

If you choose Yes (y), each authentication token will only be valid for a single login attempt. This ensures that once you use a token to log in successfully, it becomes invalid and cannot be reused—even if someone tries to enter the same token again. Disallowing multiple uses of the same token provides an additional layer of security. In case a malicious actor intercepts a token during transmission, they won't be able to reuse it for another login attempt, even if they manage to access the server or your session. Recommendation: Yes (y) is recommended because it prevents the token from being reused by attackers, which is a useful security measure. It forces attackers to generate a new token for each login attempt, reducing the chances of successful brute-force attacks.

c. Do you want to increase the time window for valid tokens (default is 1:30 min)?
Prompt: Do you want to increase the time window for valid tokens (default is 1:30 min)? (y/n)

This option allows you to extend the time window in which a generated authentication token is valid. By default, Google Authenticator tokens are valid for 30 seconds (the "1:30 min" refers to the 1 minute 30 seconds time window, which includes the current 30-second token and the previous and next 30-second tokens to accommodate any time skew between the client and server). Increasing the time window (e.g., to 4 minutes) could be helpful if you're experiencing issues with time synchronization between the client (your phone or device) and the server, especially if you are in a region with unstable or variable network conditions. However, the downside is that extending the window makes it easier for attackers to guess the token, as they have more time to try to authenticate.

Recommendation: Choosing No (n) is generally the best option. The default 1-minute and 30-second window typically offers a solid balance between security and usability. You should only consider extending this time window if you're experiencing issues with clock drift or synchronization delays between your MFA device and the server.

d. Do you want to enable rate-limiting for login attempts?
Prompt: Do you want to enable rate-limiting for login attempts? (y/n)

Rate-limiting helps prevent brute-force attacks by limiting the number of login attempts a user can make within a specific time frame. If enabled, the system will allow only a certain number of authentication attempts (e.g., 3 attempts) within a defined period (e.g., 30 seconds). After this limit is reached, further attempts will be blocked temporarily. Recommendation: Yes (y) is the recommended option. Enabling rate-limiting is a simple but effective way to reduce the chances of a successful brute-force attack. If an attacker tries to guess the token by repeatedly entering incorrect values, the system will block them after a few failed attempts, making it much harder for them to break into the system. These configuration options are all about finding the balance between security and usability. By opting for the recommended settings, you will significantly improve the security of your EC2 instance while minimizing the risk of unauthorized access via brute force or token reuse. After these options, the tool will display a QR code in your terminal. You can scan this code with the Google Authenticator app or manually enter the provided secret key.

Restore the SELinux context for the new configuration: Since we have SELinux enabled, we need to restore the proper security context for the .google_authenticator file:

restorecon -Rv ~/.ssh/

Step 2: Configure PAM (Pluggable Authentication Module) for automating MFA in an Amazon EC2

The next step is to modify the PAM configuration to enable Google Authenticator for SSH logins. We’ll update the PAM configuration file (/etc/pam.d/sshd) to require Google Authenticator's second-factor authentication.

Edit the PAM configuration file: Open the PAM configuration file for SSH (/etc/pam.d/sshd) with a text editor:

sudo nano /etc/pam.d/sshd

Add the following line at the bottom of the file to enable Google Authenticator for MFA:

auth required pam_google_authenticator.so secret=/home/${USER}/.ssh/google_authenticator auth required pam_permit.so
(This is a single-line command.)

Alternatively, if you want to allow some users to bypass MFA, you can add the nullok option to the end of the line:

auth required pam_google_authenticator.so secret=/home/${USER}/.ssh/google_authenticator nullok auth required pam_permit.so
(This is a single-line command)

Note: nullok will allow users who haven't set up MFA to log in without a second-factor prompt.

Comment out the password authentication line: In the same file (/etc/pam.d/sshd), find the line that references password-auth and comment it out to ensure only SSH key-based authentication and MFA are required:

#auth substack password-auth

Step 3: Update SSH Configuration to Require MFA
Next, we need to update the SSH server configuration (/etc/ssh/sshd_config) to require both an SSH key and a verification code.

Edit the SSH configuration file: Open the SSH configuration file with a text editor:

sudo nano /etc/ssh/sshd_config
Make the following changes:

Disable the interactive keyboard authentication: Comment out the line:

#KbdInteractiveAuthentication yes KbdInteractiveAuthentication yes
Enable Challenge-Response Authentication: Uncomment or add the following line:

ChallengeResponseAuthentication yes
Enable the Authentication Methods: Add this line at the bottom of the file:

AuthenticationMethods publickey,keyboard-interactive
Restart the SSH service: After saving the changes, restart the SSH service for the changes to take effect:

sudo systemctl restart sshd.service

Step 4: Test the Automating MFA in an Amazon EC2 Instance

To confirm MFA is working correctly, open a new terminal and attempt to SSH into your EC2 instance. After entering your SSH key passphrase (if required), the system prompts you to provide a verification code from your Google Authenticator app. When you enter the correct code, the system grants access, confirming that MFA is properly set up.

Example prompt:

Verification code:
Enter the code shown in your Google Authenticator app. If the code is correct, the system logs you in successfully. If you fail to authenticate, check that your system time syncs accurately, because Google Authenticator uses time-based one-time passwords (TOTP), and even small time differences cause login problems.

Step 5: Force Users to Set Up Google Authenticator on First Login

Create a script to prompt users to set up Google Authenticator if they haven’t configured MFA during their first login. This will be our final step in automating MFA in an Amazon EC2 instance.

Create a script to enforce MFA setup: Create a new file in the /etc/profile.d/ directory:

sudo nano /etc/profile.d/mfa.sh
Paste the following script into the file:

if [ ! -e ~/.ssh/google_authenticator ] && [ "$USER" != "root" ]; 

then google-authenticator -s ~/.ssh/google_authenticator 

restorecon -Rv ~/.ssh/ 

echo "Save the generated emergency scratch codes and use the secret key or scan the QR code to register your device for multifactor authentication." 

echo "Login again using your SSH key pair and the generated One-Time Password on your registered device." 

echo "logout" 

fi

Set the correct permissions for the script: Set the script file’s permissions to make it readable for all users:

sudo chmod o+r /etc/profile.d/mfa.sh
Update PAM configuration: Update the PAM configuration for SSH (/etc/pam.d/sshd) to run the MFA setup script on user login:

auth required pam_google_authenticator.so secret=/home/${USER}/.ssh/google_authenticator nullok

(This is a single-line command)

Remove nullok After MFA Setup

Once all users have configured MFA, you can remove the nullok option from the PAM configuration file to ensure that users must use MFA for all future logins.

Edit the PAM configuration again: sudo nano /etc/pam.d/sshd

Remove nullok from the line that includes pam_google_[authenticator.so](<http://authenticator.so/>): auth required pam_google_authenticator.so secret=/home/${USER}/.ssh/google_authenticator

Save and exit.

Final Thoughts

By following these steps, you’ve successfully automated Multi-Factor Authentication (MFA) on your Amazon EC2 instance running an Amazon Linux 2023. This setup enhances security by requiring users to authenticate with both an SSH key and a time-based OTP generated by the Google Authenticator app.

Additionally, by configuring SELinux properly, you maintain strict security policies without interfering with MFA functionality. Enforcing MFA setup on a user's first login ensures that every individual accessing your EC2 instance is protected with an extra layer of authentication, further strengthening your instance’s overall security posture.

If you like scripts or any other automation tasks, feel free to reach out to me at maheshupretiofficial@gmail.com. I am open for collaboration and projects.

RepoChat 🚀 — Explore and talk with any repository effortlessly.

Mahesh Upreti — Sat, 07 Feb 2026 16:15:20 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

Every developer knows the power of the GitHub Copilot CLI for explaining commands and fixing local errors. But what if that same intelligence could understand the entire remotely located project architecture?

RepoChat is a command-line tool that acts as a high-performance bridge between your local system and remote repositories. With the GitHub Copilot CLI at its core, it converts the CLI into a global codebase intelligence tool, providing actionable insights across projects.

🔥 Key Highlights (Driven by Copilot CLI)
🔍 Repository-Wide Intelligence: RepoChat breaks the "active file" barrier. It indexes the entire repo so the Copilot CLI can answer questions about cross-module logic and architecture.
🧠 Intelligent Code Translation: Need a Python service converted to a Node.js middleware? RepoChat leverages Copilot CLI's deep language understanding to translate complex logic while maintaining project-wide context.
💾 Zero-Trust Security: No API keys, no third-party LLM dashboards. By using the official gh copilot extension, user data and credentials remain entirely within the trusted GitHub ecosystem.

Demo

My repository link: https://github.com/mahupreti/repochat/tree/master

If GitHub Copilot is already installed on your system, you can install the package using the command pip install git+https://github.com/mahupreti/repochat.git and start using the RepoChat command-line tool right away.

If GitHub Copilot is not installed, you can use the Dockerfile provided below or set up on your machine and follow a few step-by-step commands to set up and run RepoChat manually.

FROM python:3.11-slim

# System deps
RUN apt-get update && apt-get install -y \
    git \
    wget \
    curl \
    && rm -rf /var/lib/apt/lists/*

# Install GitHub CLI
RUN mkdir -p /etc/apt/keyrings \
 && wget -qO /etc/apt/keyrings/githubcli-archive-keyring.gpg https://cli.github.com/packages/githubcli-archive-keyring.gpg \
 && echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" \
    > /etc/apt/sources.list.d/github-cli.list \
 && apt-get update \
 && apt-get install -y gh

# Install Copilot CLI
RUN gh extension install github/gh-copilot

# Install your repo
RUN pip install git+https://github.com/mahupreti/repochat.git

WORKDIR /workspace
CMD ["/bin/bash"]

docker build -t repochat .

docker run -it --rm repochat

# 1. Log in to GitHub
gh auth login

# 2. Initialize Copilot (Downloads the CLI - Press 'Esc' after download)
gh copilot

# 3. (Optional) Install the package directly from the repository
pip install git+https://github.com/mahupreti/repochat.git

(Now you are ready to index and chat!)
I am running inside the container for test purposes.

In the same way, you can ask additional questions about the code repository and request operations such as code changes, refactoring, or improvements.

My Experience with GitHub Copilot CLI

Building RepoChat was an exploration of what I call "Modular AI." Instead of building a custom RAG backend from scratch, I treated the GitHub Copilot CLI as a secure, high-utility Intelligence API.

⚡ Frictionless Power
Integrating gh copilot was remarkably simple. It allowed me to focus 100% of my energy on the retrieval logic, knowing that the "answering" part was handled by the best code-focused model in the world.

🔒 The Trust Factor
In an era of AI privacy concerns, the Copilot CLI is a standout. Users already trust gh auth. By piggybacking on this, RepoChat becomes a tool that even the most security-conscious developers can adopt immediately.

💡 The Takeaway
The GitHub Copilot CLI is more than just a tool; it's an Enabler. It provides a standardized platform for developers to build specialized, highly intelligent tools without the traditional overhead of AI development. RepoChat is my vision of that future.

Team Submission: Mahesh Upreti ( Solo )

The Corporate Comedian: Turning LinkedIn into LaughIn.

Mahesh Upreti — Sun, 26 Jan 2025 16:18:57 +0000

This is a submission for the Agent.ai Challenge: Assembly of Agents (See Details)

What I Built

I have built an agent to make people laugh. The agent is a corporate comedian who is also a demotivational speaker. The agent generates three different meme items to make you roll on the floor. First, it generates the Roast material for you based on the LinkedIn profile you pass. Then it will create the meme for you. Finally, the demotivational mentor rises and gives you the best unhelpful life advice based on your profile.

Why did I build this Agent?

As we all know, LinkedIn is a platform for sharing professional insights, Job searching, connecting like-minded people and having corporate talks. But, deep down we all know we also need some fun in this platform. From the corporate world, I would love to see a roast of all those people, including myself. Based on their profile, I would love to share what roast we can bring to them. When they post helpful advice on the platform, I would like to provide some unhelpful life advice based on their profile and activities on LinkedIn and make them giggle on their own.

I would love to see people using it solely for entertainment purposes. This agent will generate roasts, memes and some unhelpful advice each time so they won't get bored and will use it for their entertainment purpose.

Demo

https://agent.ai/agent/the-corporate-comedian

Agent.ai Experience

This was my first time creating AI Agents, and I was truly fascinated by what AI can do. I first tried different actions and created different things. Then, I thought of creating something fun. I started taking some actions seriously and started creating agent flow. I also explored some other agents and found that I can invoke other agents from my agent. So, I created my LinkedIn roasting agent and invoked another agent to generate memes and unhelpful advice in life.

Since it was my first attempt, I faced some challenges, particularly when it came to handling the actions and ensuring smooth communication between them. It was a bit tricky initially, but with time and some playing with the actions, I figured it out and successfully created my agent. It was a rewarding experience. Thanks to the agents.ai Team!

One disadvantage while invoking other agents was that overall my agent generating output took a long time.

Team Member: Mahesh Upreti (Solo)

What's Inside? Find your Perfect Search

Mahesh Upreti — Sat, 25 Jan 2025 04:22:30 +0000

This is a submission for the Agent.ai Challenge: Productivity-Pro Agent (See Details)

What I Built

I built an agent designed to make searching through long-form content—like websites, videos, podcasts, or documents—quick and effortless. Its main goal is to save time and boost productivity by helping users find exactly what they’re looking for within lengthy content, without the hassle of manually going through it. It’s like having a smart assistant that tells you if the information you need is there, so you can focus on what matters most!

How it works?

When you start the agent, you'll start with a choice: Article format or Video format. Once you've picked it, the agent will kindly ask for the URL you want to explore. After you share the link, the magic begins:

"What do you want to search for?"

Here’s where you shine! Ask about anything you think might be in the URL. If the agent finds something related to your query, it will present the results in a precise, easy-to-read format. But if the agent can’t find what you’re looking for and senses you’re eager to dig deeper, it will suggest its partner agent for a little extra help!

Why Did I Build This Agent?

It's not always the same but sometimes I waste a lot of my time watching long-form content for some specific time. So, the idea for this agent came from my own experience of wasting a lot of time on long-form content. As a DevSecOps engineer, I often watch lengthy DevOps tutorials, AWS re:Invent videos and other long videos from product launches. But there are days when I don’t have the time or patience to sit through these long videos, and I want to know if the specific topic I’m looking for is covered. That’s when I thought, “What if I had a way to quickly check if the content I need is there?” With that idea in mind, I created this agent, "What's Inside," to help save time and make content searching smarter and more efficient.

I have in mind people using it to make their daily life easy by saving some amount of time. There will be no need to watch long-form full content or read any research papers and documents to only know if the specific portion is there or not.

Demo

What's Inside: https://agent.ai/agent/whats-inside

Video Link

Agent.ai Experience

This was my second time creating AI Agents, and I was truly fascinated by what AI can do. Using the tools at agents.ai, I was able to build an AI agent with surprising ease. My experience with the Builder and AI Agents was great overall. I especially loved the variety of Actions provided in the Builder. That said, I’d love to see even more Actions available in the future.

Team Member: Mahesh Upreti

The FOMO Factory: You won't miss a beat!

Mahesh Upreti — Sun, 06 Oct 2024 14:14:20 +0000

This is a submission for the The Pinata Challenge

What I Built

Events are constantly occurring in our local area, yet my friends often overlook them. To address this, I created "The FOMO Factory." As the name implies, no one will miss out on what's happening nearby. Users can upload various file types, including images and videos, to this web application, along with the location where the event is happening. User will provide the location using Map feature in the web app and then upload the image or the video of the happening event. Then, the user can view the events happening in town in their phone in the real-time and visit the event without missing them. This project utilizes Pinata’s Files API for smooth file storage and retrieval on the IPFS network.

Key Features:

Media Upload: Users can upload images and videos for events, enriching the event experience to notify friends in real-time.
Event Display: All events are showcased with their details and media, along with geographical locations displayed on an interactive map.
IPFS Integration: Seamless storage and retrieval of media files using the Pinata API ensure security and permanence.
Responsive Design: The application is optimized for both desktop and mobile devices, ensuring accessibility for all users.

Demo

The website is hosted on render platform using free instance. So, at first, it may take few seconds to load due to inactivity.

Website Demo Link

My Code

mahupreti / event-sharing-application-with-pinata

This simple project was submission to Pinata Challenge on dev.to

The FOMO Factory

Description

Events are constantly occurring in our local area, yet my friends often overlook them. To address this, I created "The FOMO Factory." As the name implies, no one will miss out on what's happening nearby. Users can upload various file types, including images and videos, to this web application, along with the location where the event is happening. User will provide the location using Map feature in the web app and then upload the image or the video of the happening event. Then, the nearby user around 10 miles will get this notification on their phone in the realtime and visit the event without missing them. This project utilizes Pinata’s Files API for smooth file storage and retrieval on the IPFS network.

Pinata cloud IPFS is used to store all the images and videos uploaded by the user. Users are then able to share…

View on GitHub

More Details

Pinata proved invaluable for enabling users to upload images along with their event locations, ensuring that others stay informed. While some friends may receive location details, they often miss the excitement of what’s happening. By allowing users to upload images and videos, they can share a glimpse of local events. The Pinata API facilitated seamless integration for storing all this data, using CIDs to later view and showcase events.

Additionally, we recognized that once an event concludes, its relevance diminishes over time. For instance, an event lasting three days may not feel relatable after a week. To address this, we utilized the Pinata API to unpin images after seven days, ensuring that outdated content is automatically removed. The gateway URL provided by Pinata also served as a handy CDN, allowing users to easily share links directly with friends, which I have integrated into the website.

I am a solo participant.

AI Chatbot for the personalized feedback and recommendations

Mahesh Upreti — Sun, 23 Jun 2024 03:47:42 +0000

This is a submission for Twilio Challenge v24.06.12

What I Built

I have built a chatbot system using Twilio WhatsApp API and the Gemini API key. The user can ask for any feedback and they will get proper feedback and recommendations through WhatsApp.

Demo

The demo can be seen after running the repo https://github.com/mahupreti/twilio-gemini-whatsapp-bot/tree/master
I have included the screenshots

Twilio and AI

Twilio has so many products in its list that we can integrate API with third-party API and then build something better out of it. In my case, I connected the Gemini API with the Twilio WhatsApp API. Now we don't have to go to the AI official website. Also, the best feature of adding the third-party AI API from WhatsApp is that we can even upload an image or PDF in WhatsApp and generate insights from it.

Additional Prize Categories

I guess my project falls under the Impactful Innovators.

Team Member: Mahesh Upreti

Thanks for participating!

Gift of Terraform (CDKTF): Building Automated Load Balancer Health Monitoring with CloudWatch Alarms and SNS

Mahesh Upreti — Mon, 12 Feb 2024 16:49:42 +0000

We often prefer to engage with familiar elements in our surroundings. What if I told you that you can utilize your preferred programming language to provision resources from various service providers?

Cloud Development Kit for Terraform (CDKTF) enables some of the popular programming languages to define and deploy infrastructure. You can check out this installation guide for cdktf https://developer.hashicorp.com/terraform/tutorials/cdktf/cdktf-install.

To begin with, create a new directory,
mkdir send_alarm cd send_alarm

Inside the directory, run cdktf init, specifying the template for your preferred language and Terraform's AWS provider. We will not be using terraform cloud so you can leave that for now.

cdktf init --template="python" --providers="aws@~>4.0" (check the latest version in official terraform documentation)

Note: You will be provided information to activate the virtual environment.
Open the main.py file and copy and paste the below code.



 #!/usr/bin/env python

 from constructs import Construct
 from cdktf import TerraformStack, App, Token

 from imports.aws.provider import AwsProvider
 from imports.aws.cloudwatch_metric_alarm import CloudwatchMetricAlarm
 from imports.aws.sns_topic import SnsTopic
 from imports.aws.data_aws_lb_target_group import DataAwsLbTargetGroup
 from imports.aws.data_aws_lb import DataAwsLb
 from imports.aws.sns_topic_subscription import SnsTopicSubscription

 class MyStack(TerraformStack):
     def __init__(self, scope: Construct, name: str, config: dict):
         super().__init__(scope, name)
         AwsProvider(self, "aws", region="us-east-1", profile=your-credential-profile-name)
         for load_balancer in config["load_balancers"]:
             print(load_balancer) #used for debugging purpose
             lb = DataAwsLb(self, "load_balancer" + "_" + load_balancer["name"],
                            name=load_balancer["load_balancer_name"]
                            )

             lb_tg = DataAwsLbTargetGroup(self, "load_balancer_tg_name" + "_" + load_balancer["name"],
                                          name=load_balancer["load_balancer_tg_name"]
                                          )

             sns = SnsTopic(self, "sns_topic_name" + "_" + load_balancer["name"],
                            name=load_balancer["name"] + "_" + "topic"
                            )

             for email in load_balancer["email_list"]:
                 SnsTopicSubscription(self, "terraform-sns-topic_subscription" + "_" + load_balancer["name"] + email,
                                      protocol="email",
                                      topic_arn=sns.arn,
                                      endpoint=email,
                                      )

             CloudwatchMetricAlarm(self, "alb-healthy-hosts" + "_" + load_balancer["name"],
                                   alarm_actions=[sns.arn],
                                   alarm_description="Number of unhealthy nodes in Target Group",
                                   alarm_name=load_balancer["alarm_name"],
                                   comparison_operator="GreaterThanOrEqualToThreshold",
                                   dimensions={
                                       "LoadBalancer": lb.arn_suffix,
                                       "TargetGroup": lb_tg.arn_suffix
                                   },
                                   evaluation_periods=1,
                                   metric_name="UnHealthyHostCount",
                                   namespace="AWS/ApplicationELB",
                                   # ok_actions=[sns.arn],
                                   period=60,
                                   statistic="SampleCount",
                                   threshold=1
                                   )
 app = App()
 MyStack(app, "MyStack", config={
     "load_balancers": [
         {
             "name": "test-fulfillment1",
             "region": "us-east-1",
             "load_balancer_name": "lb-test-fulfillment",
             "load_balancer_tg_name": "lb-test-fulfillment-tg01",
             "alarm_name": "test-fulfillment-alarm",
             "email_list": ["mygmail1@gmail.com", "mygmail2@gmail.com"]
         },
         {
             "name": "test-fulfillment2",
             "region": "us-east-1",
             "load_balancer_name": "lb-test-fulfillment2",
             "load_balancer_tg_name": "test-fulfillment2-tg01",
             "alarm_name": "test-fulfillment2-alarm",
             "email_list": ["mygmail121@gmail.com"]
         },
     ]
 })
 app.synth()

Ahhhhhh!!!!!!! The code is so long.....
Wait This code may be lengthy, but we'll break down each component thoroughly to understand its functionality.

#!/usr/bin/env python from constructs import Construct from cdktf import App, NamedRemoteWorkspace, TerraformStack, TerraformOutput, RemoteBackend

In CDKTF (Cloud Development Kit for Terraform), the line from constructs import Construct is used to import the Construct class from the constructs module.

The Construct class is a fundamental class in CDKTF that represents a building block of your infrastructure. It serves as the base class for all other constructs and provides common functionality for creating, manipulating, and organizing resources in your CDKTF program.

By importing Construct, you can utilize the functionality provided by this class to create and manage your infrastructure components in CDKTF.

In CDKTF (Cloud Development Kit for Terraform), the line from cdktf import TerraformStack, App, and Token is used to import specific classes and objects from the cdktf module.

TerraformStack is a class that represents a CDKTF stack, which is a collection of infrastructure resources defined and managed together. It provides methods and properties for defining and deploying your Terraform-based infrastructure.
App is a class that represents a CDKTF application. It serves as the entry point for your CDKTF program and is responsible for initializing and executing the stack(s) defined in your program. A token is an object that represents a CDKTF token. Tokens are used in CDKTF to represent references to resources and properties within the constructs. They provide a way to express dependencies and relationships between different parts of your infrastructure.

By importing these classes and objects, you can use them in your CDKTF program to define and manage your infrastructure stacks, create CDKTF applications, and work with tokens for resource references and dependencies.
from imports.aws.cloudwatch_metric_alarm import CloudwatchMetricAlarm from imports.aws.sns_topic import SnsTopic from imports.aws.data_aws_lb_target_group import DataAwsLbTargetGroup from imports.aws.data_aws_lb import DataAwsLb from imports.aws.sns_topic_subscription import SnsTopicSubscription

Each line is for importing the specific resources and data modules from the imports.aws module.

class MyStack(TerraformStack): def __init__(self, scope: Construct, name: str, config: dict): super().__init__(scope, name) AwsProvider(self, "aws", region="us-east-1", profile=your-credential-profile-name)

The code provided defines a class named MyStack that extends the TerraformStack class.

The MyStack class is defined with three parameters in its constructor: scope, name, and config. scope represents the construct scope, name is the name of the stack, and config is a dictionary that can be used to pass additional configuration parameters.

The super().init(scope, name) line calls the constructor of the parent class TerraformStack with the provided scope and name arguments. This ensures that the base TerraformStack class is properly initialized.

The AwsProvider class is instantiated with the line AwsProvider(self, "aws", region="us-east-1"). This creates an AWS provider resource within the stack. The self-argument refers to the current instance of the MyStack class. The string "aws" is the provider's name, and region="us-east-1" specifies the AWS region to use.

You might have configured credentials inside the .aws/credentials file and your profile might be default which is generally in most of the cases.

Now let me describe the portion below before moving on.

app = App() MyStack(app, "MyStack", config={ "load_balancers": [ { "name": "loadbalancer1", "region": "us-east-1", "load_balancer_name": "lb-loadbalancer-1", "load_balancer_tg_name": "lb-loadbalancer-tg01", "alarm_name": "loadbalancer-1-alarm", "email_list": ["test1@gmail.com", "test2@gmail.com"] }, { "name": "loadbalancer2", "region": "us-east-1", "load_balancer_name": "lb-loadbalancer-2", "load_balancer_tg_name": "lb-loadbalancer-tg02", "alarm_name": "loadbalancer-2-alarm", "email_list": ["test1@gmail.com"] }, ] }) app.synth()

The code provided creates an instance of the App class and initializes a MyStack stack within it.

MyStack(app, "MyStack", config={...}) creates an instance of the MyStack class within the app. It takes three arguments: app (the App instance), "MyStack" (the name of the stack), and config (a dictionary that contains configuration details for the stack).

app.synth() synthesizes the CDKTF app and generates the Terraform configuration files based on the defined stack and resources.

for load_balancer in config["load_balancers"]: print(load_balancer) #used for debugging purpose lb = DataAwsLb(self, "load_balancer" + "_" + load_balancer["name"], name=load_balancer["load_balancer_name"] ) lb_tg = DataAwsLbTargetGroup(self, "load_balancer_tg_name" + "_" + load_balancer["name"], name=load_balancer["load_balancer_tg_name"] ) sns = SnsTopic(self, "sns_topic_name" + "_" + load_balancer["name"], name=load_balancer["name"] + "_" + "topic" ) for email in load_balancer["email_list"]: SnsTopicSubscription(self, "terraform-sns-topic_subscription" + "_" + load_balancer["name"] + email, protocol="email", topic_arn=sns.arn, endpoint=email, ) CloudwatchMetricAlarm(self, "alb-healthy-hosts" + "_" + load_balancer["name"], alarm_actions=[sns.arn], alarm_description="Number of unhealthy nodes in Target Group", alarm_name=load_balancer["alarm_name"], comparison_operator="GreaterThanOrEqualToThreshold", dimensions={ "LoadBalancer": lb.arn_suffix, "TargetGroup": lb_tg.arn_suffix }, evaluation_periods=1, metric_name="UnHealthyHostCount", namespace="AWS/ApplicationELB", # ok_actions=[sns.arn], period=60, statistic="SampleCount", threshold=1 )

The code provided iterates over the list of load balancer configurations in the config["load_balancers"] list and creates corresponding resources for each load balancer. Here's an explanation of what the code does:

The for load_balancer in config["load_balancers"] loop iterates over each load balancer configuration in the config["load_balancers"] list. Inside the loop, the code prints the load_balancer dictionary, which represents the current load balancer configuration.
The DataAwsLb class is instantiated with the line lb = DataAwsLb(self, "load_balancer" + "_" + load_balancer["name"], name=load_balancer["load_balancer_name"]). This creates a data source for an existing Application Load Balancer (ALB) with the specified name.
The DataAwsLbTargetGroup class is instantiated with the line lb_tg = DataAwsLbTargetGroup(self, "load_balancer_tg_name" + "_" + load_balancer["name"], name=load_balancer["load_balancer_tg_name"]). This creates a data source for an existing ALB target group with the specified name.
The SnsTopic class is instantiated with the line sns = SnsTopic(self, "sns_topic_name" + "" + load_balancer["name"], name=load_balancer["name"] + "" + "topic"). This creates an Amazon SNS topic resource with the specified name. Inside a nested loop, the code iterates over the load_balancer["email_list"] list and creates a SnsTopicSubscription for each email address. This sets up email subscriptions to the SNS topic for receiving notifications
(Will be talking more about the SNS topic and other SNS features in upcoming blog posts).
The CloudwatchMetricAlarm class is instantiated with the line CloudwatchMetricAlarm(self, "alb-healthy-hosts" + "_" + load_balancer["name"], ...). This creates a CloudWatch metric alarm resource with the specified configurations such as alarm actions, alarm description, alarm name, comparison operator, dimensions, evaluation periods, metric name, namespace, period, statistic, and threshold
(Will be talking about the cloud watch alarm and other features in upcoming blog posts).

Note: One thing is that you have to manually subscribe for the topic clicking on your email inbox.

To deploy the code , run:
cdktf deploy your_stack_name

By executing this code, you will create multiple resources, an SNS topic, SNS topic subscriptions, and CloudWatch metric alarms based on the provided load balancer configurations.

Excellent! This marks the conclusion of our comprehensive blog post detailing the process of setting up CloudWatch metric alarms through an SNS topic to notify when the load balancer is identified as unhealthy.