Skip to main content

Command Palette

Search for a command to run...

Sad Servers AWS

EBS Volume Automation

Published
3 min read
P

As a associate system administrator I worked on Redhat Linux servers, including user management, permissions, services, and performance monitoring Automated routine administrative tasks using Bash scripting and cron jobs, reducing manual effort by ~30% I am aws certified sysops administrator and Google Certified Cloud Engineer. Determined to transition my career into cloud architect /Cloud Support role

Managing cloud infrastructure requires a blend of sharp Linux skills and AWS automation expertise. This article walks through solving a common operational hurdle: identifying specific EBS volumes within a massive dataset and automating that process for long-term governance.

The Scenario: Finding the Needle in the Cloud Stack

As a Cloud Support Engineer, I often deal with large-scale environments where manual tracking is impossible. The challenge begins with an inventory export: aws ec2 describe-volumes > aws-volumes.json.

Our goal is to find a specific volume with these exact characteristics:

  • Type: gp3

  • Creation Date: Before September 30, 2025

  • Size: < 64 GB

  • IOPS: < 1500

  • Throughput: > 300 MiB/s

Step 1: The Fast Linux Fix (jq)

If you have root access and need a quick answer, jq is your best friend:

Bash

cat aws-volumes.json | jq -r '.Volumes[] | 
  select(.VolumeType == "gp3" and 
         (.CreateTime | fromdateiso8601 < ("2025-09-30T00:00:00Z" | fromdateiso8601)) and 
         (.Size < 64) and 
         (.Iops < 1500) and 
         (.Throughput > 300)) | 
  .VolumeId'

Step 2: Automating with AWS Lambda & Python

To move from manual troubleshooting to system reliability improvements , we can automate this using Python and AWS Lambda.

+1

By leveraging the Boto3 library, the function scans live infrastructure. This is more robust than parsing static JSON because it enables real-time monitoring of production systems.

Why SNS for Notifications?

Integrating Amazon SNS is the most suited choice for this auditor for several reasons:

  • Asynchronous Alerting: You receive a "push" notification (Email/SMS) without needing to monitor logs manually.

  • Decoupling: The logic stays in Lambda, while SNS handles the delivery, ensuring high availability.

  • Scalability: Multiple stakeholders can subscribe to the same audit alerts.


Step 3: Infrastructure as Code (Terraform)

To ensure repeatable deployments , we use Terraform to deploy the auditor.

+1

The Python Auditor (auditor.py)

Python

import boto3
import os
from datetime import datetime

def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    sns = boto3.client('sns')
    topic_arn = os.environ['SNS_TOPIC_ARN']
    cutoff_date = datetime(2025, 9, 30)

    volumes = ec2.describe_volumes()['Volumes']
    found = [vol['VolumeId'] for vol in volumes if 
             vol['VolumeType'] == 'gp3' and 
             vol['CreateTime'].replace(tzinfo=None) < cutoff_date and
             vol['Size'] < 64 and vol.get('Iops', 0) < 1500 and 
             vol.get('Throughput', 0) > 300]

    if found:
        sns.publish(TopicArn=topic_arn, Subject="EBS Audit Alert", 
                    Message=f"Non-compliant volumes: {', '.join(found)}")

The Terraform Module

Terraform

module "ebs_auditor" {
  source = "./modules/lambda_auditor"
}

# Inside the module:
resource "aws_sns_topic" "ebs_alerts" {
  name = "ebs-audit-alerts"
}

resource "aws_lambda_function" "auditor" {
  filename      = "scripts/auditor.zip"
  function_name = "EBS_Performance_Auditor"
  role          = aws_iam_role.lambda_exec.arn
  handler       = "auditor.lambda_handler"
  runtime       = "python3.9"

  environment {
    variables = { SNS_TOPIC_ARN = aws_sns_topic.ebs_alerts.arn }
  }
}

Conclusion

By combining Linux administration , AWS operations , and IaC, we transform a manual "Sad Server" challenge into a professional, automated governance tool.