DEV Community: Harshil Thummar

🛡️ Enforcing Auto Logout for Idle Bash Sessions on Ubuntu

Harshil Thummar — Mon, 25 Aug 2025 12:35:23 +0000

Idle shell sessions pose a significant risk on shared or multi-user systems. Unattended terminals can become an easy target for unauthorized access or accidental command execution. Fortunately, with a simple configuration tweak, you can automatically log out users after a defined period of inactivity — adding an extra layer of security to your Ubuntu system.

In this guide, we’ll walk through how to enforce automatic logout in Bash by setting the (TMOUT) environment variable—and crucially, how to make sure users cannot override it.

Objectives

To configure Ubuntu systems running the Bash shell to automatically log out idle sessions after a specified time and prevent users from disabling or modifying this behavior.

Environment

Operating System: Ubuntu (also applies to most Linux systems using Bash)
User Privileges: Root or sudo access required
Shell: Bash (/bin/bash)

Implementation

Step 1: Edit the Global Bash Configuration
We’ll begin by setting a global TMOUT value in /etc/bash.bashrc, which applies to all interactive non-login Bash shells.

Open the file in a text editor with elevated privileges:

sudo nano /etc/bash.bashrc

Scroll to the bottom and add the following lines:

# Enforce TMOUT for all users readonly TMOUT=300 # 5 minutes export TMOUT

Pro Tip: For testing, you can use TMOUT=20 for a quicker timeout.

Save and exit:

Press Ctrl + O, then Enter to save

Press Ctrl + X to close the editor

Step 2: Apply the Configuration

To apply the new settings, simply open a new terminal window or run:

source /etc/bash.bashrc

Step 3: Verify the Setting

Confirm the TMOUT Value:

echo $TMOUT

Expected output:

300

Try to Override:

Attempt to change the value:

export TMOUT=100

Expected output:

bash: TMOUT: readonly variable

This confirms that the setting is enforced and protected from user tampering.

Step 4: Test the Auto Logout

Open a new terminal window.
Leave it idle—don’t touch the keyboard or mouse.
After 300 seconds (or 20 seconds, if you’re testing), you should see a message like:

timed out waiting for input: auto-logout
logout

Additional Notes

This method enforces the timeout in interactive non-login shells (e.g., terminals launched from a GUI).

To enforce the same behavior in login shells (such as SSH sessions), add the same lines to /etc/profile.

Be aware: users with sudo or root access can still edit these files. For high-security environments, consider more advanced restrictions like mandatory access controls (e.g., SELinux or AppArmor).

Final Thoughts

Security isn’t just about firewalls and permissions—it’s also about reducing surface area. Auto-logout is a small but powerful way to tighten system access control and reduce the risk of unauthorized activity. Whether you’re managing a multi-user lab, a development server, or your personal workstation, enabling (TMOUT) is a no-brainer.

Thanks for reading! If you found this guide helpful, feel free to share or leave a comment below.

Amazon Elastic Kubernetes Service (AWS EKS) Auto Mode

Harshil Thummar — Mon, 25 Aug 2025 12:26:44 +0000

AWS announced during AWS re:Invent 2024, introducing a significant advancement in Kubernetes cluster management, targeting simplicity and scalability, named AWS EKS Auto Mode. This feature focuses on reducing the operational overhead traditionally associated with Kubernetes cluster lifecycle management, such as provisioning, scaling, and upgrading.

What is AWS EKS Auto Mode?

This mode automates key management tasks related to Kubernetes node groups, making it easier for users to operate their Kubernetes workloads without needing to manage each aspect of the infrastructure manually. The goal is to help users save time and reduce operational complexity by automating certain aspects of cluster management.

AWS EKS Auto Mode is designed for teams aiming to focus on their application workloads rather than infrastructure management. When using Auto Mode, EKS abstracts the complexities of managing the Kubernetes control plane and automatically provisions a fully managed environment. This allows users to deploy containerized applications without worrying about the underlying Kubernetes configuration or node setup. This can be enabled in any EKS cluster (1.29) and above with no additional charges.

AWS EKS Auto Mode streamlines the operation of your Amazon EKS clusters by automating key infrastructure components such as compute, nodes, auto-scaling, load balancing, storage, networking, etc. Enabling EKS Auto Mode further reduces the tasks to manage your EKS clusters. Click here for more detail: https://docs.aws.amazon.com/eks/latest/userguide/automode.html

So, in EKS Control Plane, AWS will configure, manage, and secure the AWS infrastructure in EKS clusters that your applications need to run. Basically, AWS EKS Auto Mode is now available in all AWS regions except China.

Features:

Automated Node Scaling: EKS automatically adjusts the number of worker nodes in your node groups based on the resource requirements of your Kubernetes workloads (pods).
Managed Node Groups: EKS takes care of node provisioning, configuration, and lifecycle management (including updates and patches). You don’t need to manually configure individual EC2 instances for your worker nodes.
Seamless Integration with EC2 Auto Scaling: EKS Managed Node Groups are backed by EC2 Auto Scaling Groups (ASG), which automatically adjust the number of EC2 instances in the group based on the workload demands, with settings for minimum, maximum, and desired node counts.
Flexibility in Instance Types: You can configure your EKS node groups to use multiple EC2 instance types (e.g., t3.medium, m5.large, etc.), enabling cost optimization by choosing the best instances for different workloads. EKS also allows you to use Spot Instances in your node groups, which can help reduce costs by leveraging unused EC2 capacity.
Enhanced Security with IAM Roles: EKS provides built-in support for associating IAM roles with your nodes. This allows nodes to securely access AWS resources (such as S3, DynamoDB, etc.) and Kubernetes services with fine-grained access control.
Simplified Cost Management: By using Auto Scaling and Spot Instances, you can optimize your costs based on demand. The ability to select the right instance type for different workloads can help you strike a balance between performance and cost.

Important Links & References:

Streamline Kubernetes cluster management with new Amazon EKS Auto Mode:

https://aws.amazon.com/blogs/aws/streamline-kubernetes-cluster-management-with-new-amazon-eks-auto-mode/?trk=d57158fd-77e3-423f-9e1e-005fd2a64d89&sc_channel=el

Checkout all EKS Auto mode features on AWS doc:

https://aws.amazon.com/about-aws/whats-new/2024/12/amazon-eks-auto-mode/

To learn more about how EKS Auto Mode can accelerate your time to deploy workloads to production, click here for more detail:

https://aws-experience.com/emea/smb/events/series/simplifying-kubernetes-operations-with-amazon-eks-auto-mode

AWS Security Group Change Monitoring with Slack Alerts

Harshil Thummar — Mon, 25 Aug 2025 12:21:34 +0000

This project is designed to monitor AWS Security Group changes and send Slack alerts when changes are detected. It uses AWS CloudTrail logs to track security group changes and Python to process these logs. The Python script runs as a systemd service on an EC2 instance.

Objectives

Monitor AWS Security Group changes.
Send Slack notifications when changes are detected.
Run a Python script as a systemd service on an EC2 instance.
Able to run automatically for changes using CloudTrail logs.

Implementation Steps

Enable CloudTrail

-- Sign in to the AWS Management Console.
-- Go to the CloudTrail service.
-- Create or use an existing trail.

The trail must track Management Events (not just data events).
Ensure “Read/Write events” includes Write-only or All.
Enable the trial for all regions (recommended).

-- Save the trail.

CloudTrail is required for tracking security group changes such as AuthorizeSecurityGroupIngress, RevokeSecurityGroupEgress, etc.

Prepare the EC2 Instance

-- Launch an Ubuntu EC2 instance (or any Linux-based instance).
-- Ensure the instance has internet access (for Slack webhook).
-- Update system packages:

sudo apt update && sudo apt install -y python3-pip
-- Install Python libraries from requirements.txt:

pip install -r requirements.txt

-- Also, do not forget to create your AWS profile using the access key and secret key in your server.
-- Python boto3 library will automatically detect the profile to scan the aws account based on the configured profile.

Create IAM Role

-- Go to IAM > Roles.
-- Click Create Role.
-- Select EC2 as the trusted entity type.
-- Attach the following custom policy to the role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeSecurityGroups",
        "cloudtrail:LookupEvents"
      ],
      "Resource": "*"
    }
  ]
}

-- Name the role: SecurityGroupMonitorRole.
-- Attach this role to your EC2 instance.

Create the Python Script

-- Create the script ‘sg-monitoring.py’ that checks for security group changes using CloudTrail logs and sends Slack alerts.
-- Note: 🔁 You can include “while True:” to run continuously every 5 minutes at the end of the code.
-- If you’re creating the service in systemd (GONNA PERFORM THE 5th STEP), kindly ignore adding the “while true:” at the end of the code.
-- IMPORTANT: Create your slack channel and generate the ‘Webhook’ for the same and mention it in the script.

import boto3
import json
import hashlib
import os
import requests
import pytz
from datetime import datetime, timedelta

#Slack
WEBHOOK_URL = '<WEBHOOK_URL>'

# File to track and store the last state of security group
HASH_FILE = '/home/ubuntu/sg_snapshot.hash'

# AWS settings
REGION = '<REGION>'

def get_security_groups():
    session = boto3.Session()  # Removed profile_name
    ec2 = session.client('ec2', region_name=REGION)
    response = ec2.describe_security_groups()

    # Extract only relevant rule information
    filtered_sgs = []
    for sg in response['SecurityGroups']:
        filtered_sgs.append({
            'GroupId': sg['GroupId'],
            'GroupName': sg['GroupName'],
            'IpPermissions': sg.get('IpPermissions', []),
            'IpPermissionsEgress': sg.get('IpPermissionsEgress', [])
        })

    # Sort keys to make hash consistent
    sg_data = json.dumps(filtered_sgs, sort_keys=True)
    return sg_data

def get_hash(data):
    return hashlib.md5(data.encode('utf-8')).hexdigest()

def get_recent_sg_events():
    session = boto3.Session()  # Removed profile_name
    cloudtrail = session.client('cloudtrail', region_name=REGION)

    now = datetime.utcnow()
    start_time = now - timedelta(minutes=10)  # Check last 10 minutes of activity

    event_names = [
        'AuthorizeSecurityGroupIngress',
        'RevokeSecurityGroupIngress',
        'AuthorizeSecurityGroupEgress',
        'RevokeSecurityGroupEgress',
        'UpdateSecurityGroupRuleDescriptionsIngress',
        'UpdateSecurityGroupRuleDescriptionsEgress',
        'ModifySecurityGroupRules'
    ]

    events = []
    for event_name in event_names:
        response = cloudtrail.lookup_events(
            LookupAttributes=[{'AttributeKey': 'EventName', 'AttributeValue': event_name}],
            StartTime=start_time,
            EndTime=now,
            MaxResults=5
        )
        for event in response['Events']:
            evt = json.loads(event['CloudTrailEvent'])
            user = evt.get('userIdentity', {}).get('arn', 'Unknown')
            ip = evt.get('sourceIPAddress', 'Unknown')
            changes = evt.get('requestParameters', {})
            events.append({
                'eventName': event_name,
                'user': user,
                'ip': ip,
                'changes': changes,
                'time': event['EventTime'].strftime('%Y-%m-%d %H:%M:%S UTC')
            })
    return events

def send_alert(message):
    payload = {"text": message}  # Slack expects "text" instead of "content"
    headers = {'Content-Type': 'application/json'}
    response = requests.post(WEBHOOK_URL, data=json.dumps(payload), headers=headers)
    print(f"Notification sent to Slack: {response.status_code} - {response.text}")

def format_event_summary(events):
    if not events:
        return ":warning: No recent changes to security groups detected."

    lines = [":mag: *Details are as below:*\n"]

    # Define IST timezone
    IST = pytz.timezone('Asia/Kolkata')

    for evt in events:
        changes = evt.get('changes', {})
        event_name = evt['eventName']

        # Convert UTC time to IST
        event_time_utc = evt['time']
        event_time_utc = datetime.strptime(event_time_utc, "%Y-%m-%d %H:%M:%S UTC")
        event_time_ist = event_time_utc.replace(tzinfo=pytz.utc).astimezone(IST)
        formatted_time = event_time_ist.strftime("%Y-%m-%d %H:%M:%S IST")

        # ✅ Updated Event Type Handling
        if event_name == 'ModifySecurityGroupRules':
            emoji = ":wrench:"  # 🔧 Rule modified
            action = "Rule Modified"
        elif event_name.startswith('Authorize') or event_name.startswith('Update'):
            emoji = ":white_check_mark:"  # ✅ Rule added/updated
            action = "Rule Added/Updated"
        elif event_name.startswith('Revoke'):
            emoji = ":x:"  # ❌ Rule deleted
            action = "Rule Removed"
        else:
            emoji = ":grey_question:"
            action = event_name

        lines.append(f"{emoji} **{action}** at `{formatted_time}`")
        lines.append(f"  - User: `{evt.get('user', 'Unknown')}`")
        lines.append(f"  - IP: `{evt.get('ip', 'Unknown')}`")

        # ModifySecurityGroupRules structure is different
        if event_name == 'ModifySecurityGroupRules':
            modify_req = changes.get('ModifySecurityGroupRulesRequest', {})
            group_id = modify_req.get('GroupId', 'Unknown')
            lines.append(f"  - Group ID: `{group_id}`")

            rule = modify_req.get('SecurityGroupRule', {}).get('SecurityGroupRule', {})
            proto = rule.get('IpProtocol', 'any')
            from_port = rule.get('FromPort', 'all')
            to_port = rule.get('ToPort', 'all')
            cidr = rule.get('CidrIpv4', 'N/A')
            desc = rule.get('Description', '—')

            lines.append(f"    - Protocol: `{proto}` | Ports: `{from_port}` - `{to_port}`")
            lines.append(f"    - CIDR: `{cidr}` | Desc: _{desc}_")

        else:
            group_id = changes.get('groupId', 'Unknown')
            lines.append(f"  - Group ID: `{group_id}`")

            ip_permissions = changes.get('ipPermissions', {}).get('items', [])
            if ip_permissions:
                for perm in ip_permissions:
                    proto = perm.get('ipProtocol', 'any')
                    from_port = perm.get('fromPort', 'all')
                    to_port = perm.get('toPort', 'all')
                    lines.append(f"    - Protocol: `{proto}` | Ports: `{from_port}` - `{to_port}`")

                    for ip_range in perm.get('ipRanges', {}).get('items', []):
                        cidr = ip_range.get('cidrIp', 'N/A')
                        desc = ip_range.get('description', '—')
                        lines.append(f"      - CIDR: `{cidr}` | Desc: _{desc}_")
            else:
                lines.append("    - No IP permissions found.")

        lines.append("\n")  # Spacing between entries

    # Add a separator line at the end for easy differentiation
    lines.append("\n" + "="*40 + "\n")  # 40 dashes for separation

    return "\n".join(lines)

def main():
    sg_data = get_security_groups()
    current_hash = get_hash(sg_data)

    if os.path.exists(HASH_FILE):
        with open(HASH_FILE, 'r') as f:
            old_hash = f.read().strip()
    else:
        old_hash = None

    if old_hash != current_hash:
        print("Security Group change detected. Checking CloudTrail for events...")
        events = get_recent_sg_events()

        if events:
            event_summary = format_event_summary(events)
            send_alert(f"⚠️  AWS Security Group Change Detected!\n\n{event_summary}")
        else:
            print("Hash changed, but no CloudTrail events found. Skipping alert.")

        # ✅ Always update hash to avoid duplicate alerts
        with open(HASH_FILE, 'w') as f:
            f.write(current_hash)
    else:
        print("No changes in Security Groups.")

if __name__ == "__main__":
    main()
if __name__ == "__main__":
    while True:
        main()
        time.sleep(300)

Create systemd Service

-- Create file:

sudo nano /etc/systemd/system/sg-monitoring.service

#Please take care of the given paths. 
[Unit]
Description=AWS Security Group Monitoring Service
After=network.target

[Service]
User=ubuntu
Group=ubuntu
WorkingDirectory=/home/ubuntu/sg-monitoring
Environment="PATH=/home/ubuntu/sg-monitoring/sg-venv/bin"
ExecStart=/home/ubuntu/sg-monitoring/sg-venv/bin/python /home/ubuntu/sg-monitoring/sg-monitoring.py

[Install]
WantedBy=multi-user.target

NOTE: If you’re not using ‘while True’ in the script, then you must create a ‘.timer’ file in systemd to run the service continuously.

-- Once you create the service file, run the commands given below.

sudo chmod 644 /etc/systemd/system/sg-monitoring.service
sudo systemctl daemon-reload
sudo systemctl enable sg-monitoring.service
sudo systemctl start sg-monitoring.service
sudo systemctl status sg-monitoring.service

Create systemd Timer for Service

-- Create file:

sudo nano /etc/systemd/system/sg-monitoring.timer

[Unit]
Description=AWS Security Group Monitoring Timer
Requires=sg-monitoring.service

[Timer]
OnBootSec=60
OnUnitActiveSec=60
Unit=sg-monitoring.service
Persistent=true

[Install]
WantedBy=timers.target

-- Once you create the service file, run the commands given below.

sudo chmod 644 /etc/systemd/system/sg-monitoring.timer
sudo systemctl daemon-reload
sudo systemctl enable sg-monitoring.timer
sudo systemctl start sg-monitoring.timer
sudo systemctl status sg-monitoring.timer

-- Verify Timer Schedule

systemctl list-timers

-- Now you can modify the security group and run the script. You will be able to get alert notifications in the Slack channel.

python3 sg-monitoring.py

Understanding AWS Global Accelerator: How It Routes Traffic Through a Private Network for Faster Performance

Harshil Thummar — Tue, 06 May 2025 05:56:37 +0000

In today's world of highly distributed applications, performance, reliability, and low latency are critical for providing a seamless user experience. For businesses operating globally, ensuring that their applications are fast and responsive no matter where their users are located is a major challenge. This is where AWS Global Accelerator comes into play.

In this article, we'll explore how AWS Global Accelerator works, specifically how it routes traffic through AWS's private global network and how it helps you deliver faster and more reliable experiences for your users, even when they are located far from your application's origin.

What is AWS Global Accelerator?

AWS Global Accelerator is a service that improves the availability and performance of your global applications by routing traffic through AWS's vast network of edge locations. It works by directing user traffic to the optimal endpoint, typically based on the lowest latency, best network health, and other performance factors.

Unlike traditional load balancers, which only distribute traffic within a specific region, AWS Global Accelerator is designed to operate on a global scale, ensuring that requests are routed to the best-performing AWS region or endpoint.

The Role of Edge Locations and AWS's Private Network

A key feature of AWS Global Accelerator is its use of AWS edge locations - the same infrastructure that powers AWS CloudFront, AWS's Content Delivery Network (CDN). These edge locations are spread across the globe, allowing users from virtually any location to access applications with minimal latency.

When a user makes a request, the traffic doesn't just travel over the public internet to your origin server. Instead, AWS Global Accelerator leverages AWS's private global network to route the traffic. This private network is faster, more reliable, and more secure than the public internet, significantly improving performance and reducing the chances of packet loss or other network issues.

How Global Accelerator Routes Traffic

Let's consider a scenario to better understand how this routing works:

Your EC2 Instance is in Mumbai: Suppose you have an EC2 instance running in the Mumbai region (ap-south-1).
A User is in US-East-1: A user in US-East-1 (N. Virginia) wants to access your application hosted on the Mumbai-based EC2 instance.

Without AWS Global Accelerator, the request from the user would have to traverse the public internet, which could involve multiple ISPs, resulting in higher latency, potential packet loss, and unpredictable network conditions.

However, with Global Accelerator, things work a bit differently:

Request Sent to Edge Location: The user's request first travels to the nearest AWS edge location, which is likely located somewhere in the United States. This minimizes the time it takes for the request to reach the AWS network.
Routing Through AWS's Private Network: Once the request arrives at the edge location, AWS Global Accelerator routes it over the private global network to your EC2 instance in Mumbai. This private network is far more optimized and reliable than public internet routing, meaning that the request is less likely to encounter network congestion or delays.
Optimal Path Selection: AWS Global Accelerator is constantly monitoring the health and performance of different AWS regions. If, for any reason, your Mumbai-based EC2 instance experiences issues (like high latency or downtime), Global Accelerator can dynamically reroute traffic to another healthy region (e.g., Singapore or the US-East region), ensuring that your application remains available with minimal disruption.
Response Sent Back to User: Once the EC2 instance processes the user's request, the response is sent back to the nearest edge location, which then returns the response to the user with the lowest possible latency.

Why You Don't Need to Replicate Your EC2 Instances

One of the key advantages of using AWS Global Accelerator is that it eliminates the need to replicate your EC2 instances across multiple regions or edge locations.

Even though the user is located far from your origin server (in this case, in the US while your EC2 instance is in Mumbai), Global Accelerator still improves performance by routing the traffic through the AWS global network. This reduces latency, as traffic is handled by AWS's high-performance network instead of going through the public internet.

Because Global Accelerator uses intelligent routing based on factors like health and performance, it can automatically route traffic to the best available region without you needing to worry about managing multiple copies of your infrastructure.

Benefits of AWS Global Accelerator

Here are some of the key benefits of using AWS Global Accelerator:

Improved Performance: By leveraging AWS's global network, Global Accelerator can reduce latency and improve throughput for your global users.
Increased Availability: If one endpoint or region experiences issues, Global Accelerator can automatically reroute traffic to healthy regions, ensuring that your application remains available and responsive.
Simplified Architecture: You don't need to replicate resources like EC2 instances across multiple regions. Global Accelerator takes care of intelligent routing, so you can focus on building your application rather than managing complex infrastructure.
Global Reach: No matter where your users are located - in North America, Europe, Asia, or anywhere else - AWS Global Accelerator ensures they get the best performance when accessing your application.

Real-World Use Cases for Global Accelerator

E-Commerce Platforms: If you run an e-commerce site that serves users globally, you need to ensure that customers can browse products, make purchases, and complete transactions quickly, regardless of where they are located. AWS Global Accelerator can help ensure that product pages load faster and transactions are processed with minimal delay.
Gaming Applications: Online multiplayer games require low-latency connections for real-time interactions. With AWS Global Accelerator, you can ensure that players around the world connect to game servers with the least amount of delay, making for a smoother gaming experience.
Media Streaming: Streaming services that deliver video and audio content to a global audience rely on low-latency connections to provide buffer-free streaming experiences. AWS Global Accelerator can optimize routing for users across different regions to ensure consistent media delivery.

Conclusion

AWS Global Accelerator is an invaluable tool for businesses looking to optimize the performance, availability, and reliability of their global applications. By leveraging AWS's private global network and edge locations, it helps ensure that users anywhere in the world can access your application with lower latency and higher availability - without the need for complex replication of infrastructure.

Whether you're serving customers on a global scale or need to ensure that your applications are always available and responsive, AWS Global Accelerator is a powerful solution that helps take your applications to the next level.

How to Receive Phone Call 📞 Alerts Using AWS CloudWatch, Lambda & Twilio

Harshil Thummar — Tue, 29 Apr 2025 13:12:31 +0000

Imagine this: Your EC2 instance's CPU is suddenly spiking, but you miss the CloudWatch email alert buried under dozens of other notifications. What if, instead, your phone rings with a voice message warning you of the spike?

Welcome to a hands-on guide where we'll combine AWS Lambda, CloudWatch, and Twilio to send real-time phone call alerts whenever your EC2 instance breaches a certain threshold - no more missed alerts.

🔧 What You'll Build

By the end of this tutorial, you'll have a serverless system that:

Detects high CPU usage using CloudWatch
Sends an SNS notification
Triggers an AWS Lambda function
Uses Twilio to make a real phone call with a custom alert message

Let's jump right in!

📦 Step 1: Create the Lambda Function

Head over to the AWS Lambda Console and follow these steps:

Click "Create function."
Choose "Author from scratch."
Name it something like CallOnHighCPU
Runtime: Python 3.9 (or higher)
Click "Create function."

📞 Step 2: Package Twilio with Your Lambda Code

AWS Lambda doesn't include third-party packages by default. Let's package the Twilio SDK:

👉 On your local machine, run:

mkdir lambda_twilio && cd lambda_twilio
pip install twilio -t .
zip -r9 ../lambda_function.zip .

Now, add your Lambda function code.
Create a file called lambda_function.py inside lambda_twilio/:

import json
import os
from twilio.rest import Client

TWILIO_ACCOUNT_SID = os.environ['TWILIO_ACCOUNT_SID']
TWILIO_AUTH_TOKEN = os.environ['TWILIO_AUTH_TOKEN']
TWILIO_PHONE_NUMBER = os.environ['TWILIO_PHONE_NUMBER']
YOUR_PHONE_NUMBER = os.environ['YOUR_PHONE_NUMBER']

def lambda_handler(event, context):
    try:
        sns_message = event['Records'][0]['Sns']['Message']
        alarm_name = json.loads(sns_message).get("AlarmName", "Unknown Alert")
        metric_name = json.loads(sns_message).get("Trigger", {}).get("MetricName", "Unknown Metric")

        alert_message = f"Alert! {alarm_name} triggered due to high {metric_name} usage. Please check your server. Thanks!!"

        client = Client(TWILIO_ACCOUNT_SID, TWILIO_AUTH_TOKEN)

        twiml_response = f"""
        <Response>
            <Say voice="man" language="en-US">{alert_message}</Say>
        </Response>
        """

        call = client.calls.create(
            to=YOUR_PHONE_NUMBER,
            from_=TWILIO_PHONE_NUMBER,
            twiml=twiml_response
        )

        print(f"Call initiated with SID: {call.sid}")

        return {
            'statusCode': 200,
            'body': json.dumps(f'Call initiated for {alarm_name}')
        }

    except Exception as e:
        print(f"Error: {str(e)}")
        return {
            'statusCode': 500,
            'body': json.dumps(f"Error: {str(e)}")
        }

Then, add it to your ZIP:

zip -g ../lambda_function.zip lambda_function.py

This zip now contains:

Your Lambda code
The Twilio SDK

☁️ Step 3: Upload to Lambda

Back in the AWS Lambda Console:

Open your CallOnHighCPU function
Go to Code → Choose "Upload from" → "ZIP file"
Upload your lambda_function.zip
Click Deploy

🔐 Step 4: Set Environment Variables

Still in the Lambda console:

Go to Configuration → Environment Variables → Edit
Add:

TWILIO_ACCOUNT_SID       = <your Twilio SID>
TWILIO_AUTH_TOKEN        = <your Twilio token>
TWILIO_PHONE_NUMBER      = +1234567890
YOUR_PHONE_NUMBER        = +9876543210

Save changes.

✨ If you don't have a Twilio account, create one. You'll get $15 free credit for testing.

🧪 Step 5: Test the Lambda Function

Click "Test" and create a new event:
Test Event JSON (SNS format):

{
  "Records": [
    {
      "Sns": {
        "Message": "{\"AlarmName\":\"HighCPUUsage\",\"Trigger\":{\"MetricName\":\"CPUUtilization\"}}"
      }
    }
  ]
}

Run the test. Your phone should ring with the alert message. Magic!

📣 Step 6: Connect Lambda to SNS

Now, let's wire up SNS to trigger your function.

6.1: Create an SNS Topic

Go to SNS Console
Click Create Topic
Type: Standard
Name:HighCPUAlert
Click Create Topic

6.2: Create a Subscription

Open your HighCPUAlert topic
Click Create Subscription
Protocol: Lambda
Endpoint: Select your CallOnHighCPU Lambda
Click Create Subscription

📊 Step 7: Attach SNS to a CloudWatch Alarm

Go to CloudWatch → Alarms → Create Alarm
Choose EC2 → Per-Instance Metrics
Select CPUUtilization for your instance
Conditions:

Greater than 80%
For 2 periods of 5 minutes

In actions, choose SNS topic → HighCPUAlert
Click Create Alarm

🔥 Bonus: Trigger the Alarm with a CPU Spike

On your EC2 instance, simulate CPU load:

sudo apt install stress
stress --cpu 2 --timeout 120s

Within minutes, CloudWatch will detect the spike, SNS will publish a message, Lambda will be triggered, and… your phone will ring.

🎉 You're Done!

You've successfully built a voice-based monitoring system using AWS Lambda, CloudWatch, SNS, and Twilio.
This solution is

Real-time
Reliable
Easy to extend

Need to alert a team? Add multiple Twilio calls. Want Slack integration instead? Swap Twilio with a Slack webhook.

🙌 Final Thoughts

Email alerts are great, but voice alerts are immediate, hard to ignore, and potentially life-saving in production environments.

With just a few lines of code and some AWS configuration, you now have an automated voice call alert system that keeps your infrastructure healthy and your response time sharp.