Sad Servers AWS
EBS Volume Automation
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:
gp3Creation 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.