Forem: Hasan Ashab

Don’t Learn DevOps Before Understanding Web Development

Hasan Ashab — Thu, 16 Oct 2025 01:29:43 +0000

When people ask me how to start learning DevOps or Cloud, I always say the same thing:

“First, build a simple three-tier web app — even if it’s just a Hello World.”

And they usually look confused.
“Why? I want to be a DevOps engineer, not a web developer.”

I get it — I said the same thing once.

How I Started

I began my career as a backend-focused web developer.
I spent my days writing APIs, debugging weird server errors, and figuring out why that one endpoint suddenly returned 500 after deploying.

Eventually, I moved into DevOps and Cloud Engineering — and that’s when I realized how much my development background saved me.

Because here’s the truth:
You can become a DevOps engineer without learning web development — but you’ll never be an impactful one until you understand why things are built the way they are.

The “Why” Behind the Tools

A lot of new DevOps learners jump straight into Kubernetes, Docker, Terraform, or AWS.
They follow the roadmaps, memorize commands, spin up clusters — and then hit a wall.

Because when something breaks, they have no clue whether it’s an app problem, a config issue, or an architectural flaw.
They know how to deploy, but not what they’re actually deploying.

That’s what I call the “tooler trap” — knowing tools, but not the system.

A Simple 3-Tier App Can Teach You Everything

You don’t need to build a full SaaS to understand the ecosystem.
Just develop a 3-tier Hello World app:

Frontend: even a static page with a button
Backend: a small API that returns “Hello, world”
Database: maybe a single table or record

Then deploy it.
Host the backend somewhere, connect it to the DB, expose an endpoint, and open it in a browser.

That process alone will teach you how data flows, where bottlenecks form, and why infrastructure matters.
Once you see that flow end-to-end, every DevOps concept — CI/CD, load balancing, monitoring, scaling — starts making sense, not just noise.

Real DevOps Is About Solving Problems, Not Running Pipelines

A “tooler” can build a Jenkins pipeline or deploy to AWS.
A real DevOps engineer can look at a system and ask,

“Why is this deployment taking 8 minutes?”
“Why is our API timing out?”
“Why does our architecture break under load?”

Those questions can’t be answered without understanding the application layer.
If you’ve never built or debugged a web app, you’ll miss the reasoning behind every DevOps decision.

DevOps is not about using tools — it’s about solving the pain developers face every day.
And you can’t fix pain you’ve never felt.

My Advice

If you’re new and aiming for DevOps or Cloud:

Yes, learn the tools. But first, build something that uses them.
Yes, you can skip web dev — but then you’ll miss the “why” that makes DevOps meaningful.
Start small. A simple 3-tier Hello World will teach you more than any crash course on Terraform or Kubernetes ever could.

Because once you understand why developers struggle, every automation you create will have purpose — not just pipelines.

Final Thoughts

DevOps isn’t just a stack of tools; it’s a mindset built on understanding how software works, from code to customer.
You don’t have to become a full-stack developer — but you should at least experience the stack once.

Otherwise, you’ll always stay a tooler, not an engineer — busy setting up systems that solve no real problems.

And that’s not DevOps. That’s just decoration.

📬 Contact

If you’d like to connect, collaborate, or discuss DevOps, feel free to reach out:

Website: hasan-ashab
LinkedIn: linkedin.com/in/hasan-ashab

Creating a CLI Tool with Node.js

Hasan Ashab — Mon, 06 Oct 2025 01:07:03 +0000

Command-line tools might not have fancy interfaces, but they’re some of the most powerful and time-saving tools a developer can build. From simple automation scripts to complex developer utilities, CLIs (Command Line Interfaces) are at the heart of how modern developers work.

In this post, we’ll walk through how to build a robust CLI with Node.js, and we’ll take a close look at SamerArtisan — a Laravel Artisan–inspired framework that brings structure, elegance, and TypeScript support to CLI development.

Why Build a CLI Tool?

Think about how often you type git, npm, or docker in your terminal. CLI tools let us control complex systems quickly, script them easily, and automate repetitive tasks.

Here’s why developers love CLIs:

⚙️ Automation-friendly – Easily scriptable and perfect for CI/CD.
💡 Lightweight – No need for a GUI, ideal for servers and terminals.
🧩 Composable – Can be chained with other tools using pipes and redirects.
⚡ Fast – Interacts directly with the system, no browser overhead.

In short: CLIs make developers faster.

The Node.js CLI Ecosystem

Node.js has become a favorite for building CLI tools, thanks to its simplicity and cross-platform nature. The most common library for this is Commander.js, which handles command parsing, flags, and options well.

But as your tool grows, Commander.js can start to feel repetitive — lots of boilerplate, little structure. That’s where SamerArtisan comes in.

Inspired by Laravel’s “Artisan” console, SamerArtisan gives Node.js CLIs a framework-like experience — complete with classes, structure, interactivity, and first-class TypeScript support.

Commander.js vs SamerArtisan — Which Should You Use?

🧱 Commander.js: The Classic Choice

Commander.js is perfect when you need:

A simple CLI with a few commands.
A quick prototype or internal tool.
Minimal dependencies and maximum control.

Example:

const { Command } = require('commander');
const program = new Command();

program
  .name('my-cli')
  .description('CLI for simple greetings')
  .version('0.8.0');

program
  .command('greet')
  .description('Greet someone')
  .argument('<name>', 'person to greet')
  .option('-u, --uppercase', 'uppercase the greeting')
  .action((name, options) => {
    const greeting = `Hello ${name}!`;
    console.log(options.uppercase ? greeting.toUpperCase() : greeting);
  });

program.parse();

Straightforward — but not very scalable.

💎 SamerArtisan: Structure with Style

SamerArtisan shines when your CLI needs more than a few commands. It gives you:

Organized command classes and inheritance.
Interactive prompts, progress bars, and tables.
TypeScript support for safety and autocompletion.
A Laravel-like experience for developers.
A scalable foundation for large tools.

Example:

const { SamerArtisan, Command } = require("samer-artisan");

class GreetCommand extends Command {
  signature = "greet {name} {--uppercase}";
  description = "Greet someone";

  handle() {
    const name = this.argument('name');
    const uppercase = this.option('uppercase');
    const greeting = `Hello ${name}!`;
    this.info(uppercase ? greeting.toUpperCase() : greeting);
  }
}

SamerArtisan.add(new GreetCommand());
SamerArtisan.parse();

Cleaner, more readable, and ready to scale.

Getting Started with SamerArtisan

Let’s build a simple project management CLI that initializes projects and manages tasks.

Step 1: Install

npm install samer-artisan

Step 2: Set Up Your CLI Entry File

// cli.js
const { SamerArtisan } = require("samer-artisan");

SamerArtisan
  .projectName("ProjectManager")
  .root(__dirname)
  .load("commands")
  .parse();

Step 3: Create a Command

You can generate a command class automatically:

node cli.js make:command InitProject

This gives you a clean template:

// commands/InitProject.js
const { Command } = require("samer-artisan");

class InitProject extends Command {
 /**
  * The name and signature of the console command.
  */
  signature = `project:init 
        { a: First arg }
        { b }
        { c*: Third arg }
        { --dog : First opt }`;

 /**
  * The console command description.
  */
  description = "command description";

 /**
  * Execute the command
  */
  handle() {
    this.info("InitProject command works!");
  }
}

module.exports = InitProject;

Features That Make SamerArtisan Special

1. Interactive Prompts

SamerArtisan makes user input effortless:

const name = await this.ask('Project name?');
const apiKey = await this.secret('Enter your API key:');
const framework = await this.choice('Choose framework:', ['React', 'Vue', 'Svelte']);

2. Beautiful Output

this.info('✅ All systems operational');
this.warn('⚠️  Some warnings detected');
this.error('❌ Critical issues found');

this.table(
  ['Service', 'Status', 'Uptime'],
  [
    ['Database', '✅ Running', '99.9%'],
    ['API', '⚠️ Slow', '98.1%'],
    ['Cache', '❌ Down', '0%'],
  ]
);

3. TypeScript Support

Type-safe arguments and options right out of the box:

class TypedCommand extends Command<{name: string}, {force: boolean}> {
  signature = "run {name} {--force}";
  handle() {
    const name = this.argument('name');
    const force = this.option('force');
  }
}

4. Easy Organization

SamerArtisan
  .load(['commands/project', 'commands/database'])
  .parse();

Best Practices for CLI Design

✅ Make It Scriptable and Interactive

if (!this.option('yes')) {
  const confirm = await this.confirm('Proceed with deployment?');
  if (!confirm) return;
}

⚠️ Handle Errors Gracefully

try {
  // logic
} catch (e) {
  this.error(`Error: ${e.message}`);
}

🧭 Document Everything

SamerArtisan can generate help text directly from your command signatures — no extra effort needed.

Real-World Example: Database Migrations

Here’s what a realistic command might look like:

class MigrateCommand extends Command {
  signature = `migrate 
    {--rollback : Rollback last migration}
    {--steps=1 : Steps to rollback}
    {--seed : Run seeders after migration}`;
  description = "Run database migrations";

  async handle() {
    const rollback = this.option('rollback');
    const steps = parseInt(this.option('steps') || '1');
    const seed = this.option('seed');

    if (rollback) return this.runRollback(steps);
    await this.runMigrations();
    if (seed) await this.runSeeders();
  }
}

Readable, structured, and clean — exactly how a CLI should feel.

When to Choose SamerArtisan

Use SamerArtisan if you’re building:

A complex CLI with multiple commands or subcommands.
A team tool that benefits from consistent structure.
A TypeScript project where safety matters.
A long-term project that will evolve over time.

Stick with Commander.js for:

Quick scripts or small utilities.
Projects with strict dependency policies.
One-off tools where setup speed matters.

Final Thoughts

Building a CLI tool is about more than just parsing commands — it’s about creating a smooth experience for both humans and scripts.

Commander.js is ideal for small tools and prototypes.
SamerArtisan shines in structured, scalable, developer-focused projects.

At the end of the day, the “best” CLI framework is the one that fits your use case. Start simple, grow smart, and build tools that make developers’ lives easier — because the best CLI is the one people actually use.

Why You Should Use AWS Backup Instead of Custom Lambda Solutions

Hasan Ashab — Sun, 05 Oct 2025 05:42:50 +0000

Stop reinventing the wheel.
Here's why AWS Backup is the superior choice over custom Lambda functions for EC2 backups — and how to migrate your existing solution in minutes.

The Problem with Custom Solutions

I used to think building custom backup solutions was the way to go. Lambda functions, EventBridge rules, custom IAM policies, S3 logging buckets — it felt like I was in control of every aspect of my backup strategy.

But here's what I learned the hard way: you're reinventing a wheel that AWS has already perfected.

After migrating from a custom Lambda-based backup solution to AWS Backup, I realized I had been:

Writing hundreds of lines of code that AWS already maintains
Managing complex IAM policies when service-linked roles exist
Building monitoring and alerting that's built into AWS Backup
Debugging custom logic instead of focusing on business value

Today, I'll show you why AWS Backup is superior and how to migrate your existing custom solution in under 30 minutes.

Why AWS Backup Wins

Let me break down why AWS Backup is objectively better than custom Lambda solutions:

Zero Code Maintenance

Custom Lambda: 200+ lines of Python code to maintain, debug, and update
AWS Backup: Zero lines of code. It's a managed service.

Enterprise Features Out of the Box

Cross-region replication: Built-in, no custom logic needed
Point-in-time recovery: Supported natively
Compliance reporting: Built into the console
Backup verification: Automatic integrity checks

Better Security

Service-linked roles: AWS manages permissions automatically
Encryption: KMS integration with no custom key management
Audit trails: CloudTrail integration by default

Superior Monitoring

Built-in dashboards: No custom CloudWatch setup needed
Native alerting: SNS integration without custom Lambda triggers
Job status tracking: Real-time backup job monitoring

Migration Guide

If you're currently using a custom Lambda solution, here's how to migrate to AWS Backup:

Before: Custom Lambda Architecture

EventBridge → Lambda Function → EC2 API calls → S3 Logging

200+ lines of Python code
Custom IAM policies
Manual error handling
Custom monitoring setup

After: AWS Backup Architecture

AWS Backup Plan → Backup Vault → Encrypted Recovery Points

Zero lines of code
Service-linked roles
Built-in error handling
Native monitoring

The New Architecture

AWS Backup simplifies everything:

Backup Plan: Defines schedule and retention rules
Backup Vault: Secure, encrypted storage for recovery points
Backup Selection: Tag-based resource targeting
Service Role: AWS-managed permissions

That's it. Four components instead of a dozen.

Implementation

Here's the complete Terraform configuration for AWS Backup. Compare this to the 300+ lines needed for a custom Lambda solution:

# IAM role for AWS Backup
resource "aws_iam_role" "backup_role" {
  name = "aws-backup-service-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = { Service = "backup.amazonaws.com" }
    }]
  })
}

# Attach AWS managed policies
resource "aws_iam_role_policy_attachment" "backup_policy" {
  role       = aws_iam_role.backup_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup"
}

# Backup vault with encryption
resource "aws_backup_vault" "main" {
  name        = "primary-backup-vault"
  kms_key_arn = aws_kms_key.backup.arn
}

# Backup plan with lifecycle rules
resource "aws_backup_plan" "main" {
  name = "daily-backup-plan"

  rule {
    rule_name         = "daily_backup_rule"
    target_vault_name = aws_backup_vault.main.name
    schedule          = "cron(0 2 * * ? *)"  # 2 AM daily

    lifecycle {
      delete_after = 7  # 7 day retention
    }
  }
}

# Backup selection - which resources to backup
resource "aws_backup_selection" "ec2_backup" {
  iam_role_arn = aws_iam_role.backup_role.arn
  name         = "ec2-backup-selection"
  plan_id      = aws_backup_plan.main.id

  selection_tag {
    type  = "STRINGEQUALS"
    key   = "BackupPlan"
    value = "daily-backup"
  }

  resources = ["*"]
}

That's it. 50 lines of Terraform vs 300+ lines for a custom solution.

Check the source code here.

Benefits Comparison

Let me show you the concrete benefits of switching:

Feature	Custom Lambda	AWS Backup
Code Maintenance	200+ lines of Python	0 lines
IAM Complexity	Custom policies, 50+ lines	Service-linked roles
Error Handling	Manual try/catch blocks	Built-in retry logic
Monitoring	Custom CloudWatch setup	Native dashboards
Cross-region	Complex custom logic	One checkbox
Compliance	Manual reporting	Built-in compliance reports
Point-in-time Recovery	Not supported	Native support
Backup Verification	Manual testing	Automatic integrity checks

Cost Analysis

Custom Lambda Solution Monthly Costs:

Lambda execution: ~$2-5
EventBridge: ~$1
S3 storage for logs: ~$1-3
CloudWatch logs: ~$1-2
Total: $5-11/month

AWS Backup Solution Monthly Costs:

Backup storage: Same as EBS snapshots
AWS Backup service: $0.50 per backup job
Total: ~$2-4/month

AWS Backup is actually cheaper because it eliminates Lambda execution costs and reduces operational overhead.

Migration Steps

Ready to migrate? Here's your step-by-step guide:

1. Update Your Tags

Change your EC2 instance tags from:

Backup = "true"

To:

BackupPlan = "daily-backup"

2. Deploy AWS Backup Resources

Use the Terraform configuration above to create:

Backup vault with KMS encryption
Backup plan with your schedule
Backup selection targeting your tagged resources
Service-linked IAM role

3. Test the Migration

Deploy the AWS Backup resources
Wait for the first scheduled backup
Verify recovery points in the AWS Backup console
Test a restore operation

Real-World Results

After migrating to AWS Backup, here's what I experienced:

Operational Benefits:

✅ Zero code maintenance (was spending 2-3 hours/month debugging Lambda issues)
✅ Built-in monitoring eliminated custom CloudWatch setup
✅ Automatic retry logic reduced backup failures by 90%
✅ Cross-region replication setup took 5 minutes vs. days of custom development

Cost Savings:

✅ 40% reduction in monthly backup costs
✅ Eliminated Lambda execution charges
✅ Reduced CloudWatch log storage costs
✅ No more S3 storage for custom backup logs

Security Improvements:

✅ Service-linked roles eliminated custom IAM policy maintenance
✅ Built-in encryption with customer-managed KMS keys
✅ Automatic compliance reporting for audits

Contact

Have questions about this setup? Found a bug in the code? Drop a comment below

or reach out:

Website: hasan-ashab
LinkedIn: linkedin.com/in/hasan-ashab

Never Miss a Downtime: AWS Website Uptime Monitor with Terraform

Hasan Ashab — Sat, 04 Oct 2025 04:18:13 +0000

Stop wondering if your website is down.
Here's how to build a complete uptime monitoring system with real-time dashboard using AWS Lambda, DynamoDB, React, and Terraform — get instant alerts when your site goes down.

Picture this:

Your website goes down at 2 AM. Your customers can't access your service, but you're peacefully sleeping, completely unaware. By morning, you've lost customers, revenue, and trust. Sound familiar?

Today, I'll show you how to build a comprehensive website monitoring system that never sleeps. By the end of this guide, you'll have:

Real-time uptime monitoring with customizable checks
Beautiful dashboard showing response times and availability
Instant email alerts when your site goes down
Historical data and monthly uptime reports
All running serverlessly for pennies per month

The best part? It takes about 30 minutes to set up and monitors your site 24/7.

Why This Solution Works

Before diving into the code, let's understand why this serverless approach beats traditional monitoring services:

Cost-Effective: Monitor multiple websites for under $5/month. No expensive SaaS subscriptions.
Customizable: Full control over what gets monitored and how alerts are sent.
Real-Time: Dashboard updates every minute with live data and beautiful charts.
Scalable: Monitor 1 website or 100 - the system scales automatically.
Reliable: Built on AWS managed services with 99.99% uptime SLA.

The Architecture (Simple Yet Powerful)

Our monitoring system has six main components working together:

EventBridge: Triggers uptime checks every 5 minutes (or your preferred interval)
Monitoring Lambda: Performs HTTP checks and validates responses
DynamoDB: Stores all monitoring data and metrics
API Lambda: Serves dashboard data through REST endpoints
React Dashboard: Beautiful real-time UI with charts and metrics
SNS: Sends email alerts for downtime events

Here's the flow:

EventBridge (Every 5min) → Monitor Lambda → Check Website → Store Results → DynamoDB
                                                                              ↓
React Dashboard ← API Lambda ← DynamoDB ← SNS Alerts (if check fails)

Clean, simple, and bulletproof.

What You'll Need

Before we start, make sure you have:

AWS CLI configured with appropriate permissions
Terraform installed (version 1.0 or later)
Node.js 22+ and npm
Basic familiarity with React and AWS services
About 30 minutes of your time

Don't worry if you're new to some of these - I'll guide you through everything.

Step 1: Project Structure

Let's organize our project for maximum clarity and reusability:

website-uptime-monitor/
├── infra/                          # Terraform infrastructure
│   ├── main.tf                     # Main configuration
│   ├── variables.tf                # Input variables
│   ├── envs/
│   │   └── prod.tfvars            # Production config
│   └── modules/
│       ├── uptime_monitor/         # Monitoring infrastructure
│       └── dashboard/              # Dashboard infrastructure
├── dashboard/
│   ├── backend/                    # Lambda API functions
│   │   └── functions/
│   │       ├── get.mjs            # Metrics endpoint
│   │       ├── list.mjs           # All data endpoint
│   │       └── create.mjs         # Recent pings endpoint
│   └── frontend/                   # React dashboard
│       ├── src/
│       │   ├── App.js             # Main dashboard component
│       │   └── index.css          # Styling
│       └── package.json
└── .github/workflows/              # CI/CD pipelines
    ├── backend-cicd.yaml
    └── frontend-cicd.yaml

You can either clone the complete project from GitHub or create the structure manually:

Option 1: Clone the complete project (recommended):

git clone https://github.com/HasanAshab/aws-website-uptime-monitor.git
cd aws-website-uptime-monitor

Option 2: Create the structure manually:

mkdir website-uptime-monitor
cd website-uptime-monitor
mkdir -p infra/{modules/{uptime_monitor,dashboard},envs}
mkdir -p dashboard/{backend/functions,frontend/src}
mkdir -p .github/workflows

Step 2: The Monitoring Lambda (The Watchdog)

The monitoring Lambda is the heart of our system. It performs HTTP checks, validates responses, and stores results.

Here's what our monitoring function does:

export async function handler(event, context) {
  // 1. Fetch the target website URL from environment
  // 2. Perform HTTP request with timeout
  // 3. Validate status code and response body
  // 4. Measure response time
  // 5. Store results in DynamoDB
  // 6. Send SNS alert if any check fails
}

The function checks for:

HTTP Status Code: Ensures it matches expected value (usually 200)
Response Body: Validates that specific text is present
Response Time: Measures and stores response time in milliseconds
Connection Issues: Catches timeouts and network errors

Full monitoring Lambda code available in the repository

Step 3: Dashboard API (Serving the Data)

Our dashboard needs three API endpoints to display comprehensive monitoring data:

Metrics Endpoint (`get.mjs`)

// GET /metrics - Returns monthly aggregated data
export const handler = async (event) => {
  const metrics = {
    uptime: 99.5,                    // Percentage uptime this month
    invalidStatusCount: 2,           // Number of failed status checks
    avgResponseTime: 245,            // Average response time in ms
    totalChecks: 1440,              // Total checks performed
    successfulChecks: 1438,          // Successful checks
    failedChecks: 2,                 // Failed checks
    lastUpdated: new Date().toISOString()
  };

  return {
    statusCode: 200,
    headers: corsHeaders,
    body: JSON.stringify(metrics)
  };
};

Recent Pings Endpoint (`create.mjs`)

// GET /recent-pings - Returns last 30 minutes of data
export const handler = async (event) => {
  // Filter DynamoDB data for last 30 minutes
  // Return detailed ping results with timestamps
};

All Data Endpoint (`list.mjs`)

// GET /uptime-data - Returns all monitoring data
export const handler = async (event) => {
  // Scan entire DynamoDB table
  // Return all historical data
};

These endpoints power our dashboard with real-time data and historical trends.

Step 4: React Dashboard (Beautiful Real-Time UI)

Our React dashboard provides a beautiful, responsive interface for monitoring your website:

Key Features:

Monthly Metrics Cards: Uptime percentage, failed checks, average response time
Real-Time Chart: Response time visualization for the last 30 minutes
Recent Pings Table: Detailed list of recent monitoring attempts
Auto-Refresh: Updates every 60 seconds automatically
Responsive Design: Works perfectly on desktop, tablet, and mobile

Main Dashboard Component (`App.js`):

function App() {
  const [metrics, setMetrics] = useState(null);
  const [recentPings, setRecentPings] = useState([]);
  const [chartData, setChartData] = useState([]);

  // Auto-refresh every 60 seconds
  useEffect(() => {
    fetchData();
    const interval = setInterval(fetchData, 60000);
    return () => clearInterval(interval);
  }, []);

  const fetchData = async () => {
    // Fetch from our API endpoints
    // Update state with fresh data
  };

  return (
    <div className="dashboard">
      <MetricsCards metrics={metrics} />
      <ResponseTimeChart data={chartData} />
      <RecentPingsTable pings={recentPings} />
    </div>
  );
}

The dashboard uses:

Recharts for beautiful, responsive charts
Framer Motion for smooth animations
React Icons for consistent iconography
Custom CSS with modern gradients and glassmorphism effects

Step 5: Terraform Infrastructure

Now let's tie everything together with Terraform. Our infrastructure is modular and reusable:

Main Configuration (`infra/main.tf`):

# DynamoDB table for storing monitoring data
module "dynamodb_table" {
  source  = "terraform-aws-modules/dynamodb-table/aws"
  version = "5.1.0"

  name         = "${local.project_name}-dynamodb-${var.environment}"
  hash_key     = "id"
  billing_mode = var.db_billing_mode

  attributes = [
    {
      name = "id"
      type = "S"
    }
  ]
}

# Uptime monitoring system
module "uptime_monitor" {
  source = "./modules/uptime_monitor"

  environment = var.environment
  name_prefix = local.project_name

  website_url         = var.target_website_url
  ping_schedule       = var.uptime_ping_schedule
  assertions          = var.uptime_assertions
  subscriber_email    = var.uptime_alert_subscriber_email
  dynamodb_table_name = module.dynamodb_table.dynamodb_table_id
}

# Dashboard (API + Frontend)
module "dashboard" {
  source = "./modules/dashboard"

  environment = var.environment
  name_prefix = local.project_name

  backend_src_root    = "${path.root}/../dashboard/backend"
  dynamodb_table_name = module.dynamodb_table.dynamodb_table_id
}

Configuration Variables (`infra/variables.tf`):

variable "target_website_url" {
  description = "URL of the website to monitor"
  type        = string
  default     = "https://example.com/"
}

variable "uptime_ping_schedule" {
  description = "EventBridge cron expression for monitoring frequency"
  type        = string
  default     = "cron(*/5 * * * ? *)"  # Every 5 minutes
}

variable "uptime_assertions" {
  description = "Monitoring assertions"
  default = {
    status_code          = 200
    body_includes        = "Welcome"
    max_response_time_ms = 1000
  }
}

variable "uptime_alert_subscriber_email" {
  description = "Email address for downtime alerts"
  type        = string
}

Environment Configuration (`infra/envs/prod.tfvars`):

environment                   = "prod"
aws_region                   = "us-west-2"
target_website_url           = "https://your-website.com"
uptime_alert_subscriber_email = "alerts@your-domain.com"
uptime_ping_schedule         = "cron(*/5 * * * ? *)"

uptime_assertions = {
  status_code          = 200
  body_includes        = "Your Site Title"
  max_response_time_ms = 2000
}

Step 6: Deployment

Now let's deploy our complete monitoring system:

Deploy Infrastructure:

cd infra
terraform init
terraform workspace new prod
terraform plan -var-file=envs/prod.tfvars
terraform apply -var-file=envs/prod.tfvars

Deploy Frontend:

cd dashboard/frontend
npm install
npm run build

# Upload to S3 bucket (created by Terraform)
aws s3 sync build/ s3://your-dashboard-bucket --delete

Terraform will create:

✅ DynamoDB table for monitoring data
✅ Lambda functions for monitoring and API
✅ EventBridge rule for scheduled checks
✅ SNS topic for email alerts
✅ S3 bucket and CloudFront for dashboard hosting
✅ API Gateway for dashboard endpoints

Step 7: Test Your Monitoring System

Don't wait for your site to go down to test the system! Here's how to verify everything works:

Trigger Manual Check:

aws lambda invoke \
  --function-name your-monitor-function \
  --payload '{}' \
  response.json

Check Monitoring Logs:

Go to CloudWatch → Log groups
Find /aws/lambda/your-monitor-function
Check the latest log stream for monitoring results

Verify Data Storage:

Go to DynamoDB → Tables → your-monitoring-table
Click "Explore table items"
Verify monitoring records are being created

Test Dashboard:

Get your dashboard URL from Terraform output:

   terraform output dashboard_url

Open the URL in your browser
Verify you see:
- Monthly metrics cards
- Response time chart
- Recent pings table
- Auto-refresh functionality

Test Alerts:

Temporarily change your website URL to a non-existent domain:

terraform apply -var="target_website_url=https://non-existent-site.com" -var-file=envs/prod.tfvars

You should receive an email alert within 5 minutes.

Monitoring and Alerts

Your monitoring system is now active! Here's how to keep it running smoothly:

Email Alert Configuration

The system automatically sends alerts for:

Website Down: HTTP errors, timeouts, connection failures
Slow Response: Response time exceeds your threshold
Content Changes: Expected text not found in response body
Status Code Issues: Unexpected HTTP status codes

Dashboard Features

Your dashboard provides:

Real-Time Metrics: Current month uptime percentage
Response Time Trends: Visual chart of performance over time
Failure Analysis: Count and details of failed checks
Historical Data: Complete monitoring history

Cost Monitoring

Monitor your AWS costs:

# Check monthly costs for monitoring services
aws ce get-cost-and-usage \
  --time-period Start=2025-01-01,End=2025-02-01 \
  --granularity MONTHLY \
  --metrics BlendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

Expected monthly costs:

Lambda: $0.20 (for ~8,640 invocations/month)
DynamoDB: $1.25 (for ~250,000 read/write units)
CloudFront: $0.50 (for dashboard hosting)
SNS: $0.50 (for email alerts)
Total: ~$2.45/month

Troubleshooting Common Issues

Lambda Timeout Errors:

Increase timeout in Terraform configuration
Check if target website is responding slowly
Verify network connectivity from Lambda

Dashboard Not Loading:

Check CloudFront distribution status
Verify S3 bucket has correct files
Check API Gateway endpoints are working

No Email Alerts:

Confirm SNS subscription in AWS console
Check spam folder for confirmation email
Verify email address in Terraform variables

Missing Data in Dashboard:

Check DynamoDB table has monitoring records
Verify Lambda function is being triggered by EventBridge
Check API Lambda functions have correct DynamoDB permissions

High Response Times:

Check if your website is actually slow
Verify Lambda is in same region as your website
Consider adjusting response time thresholds

Advanced Features

Once your basic monitoring is working, consider these enhancements:

Multi-Website Monitoring:

# Monitor multiple websites
variable "websites" {
  default = {
    "main-site" = {
      url = "https://your-main-site.com"
      expected_text = "Welcome"
    }
    "api-endpoint" = {
      url = "https://api.your-site.com/health"
      expected_text = "OK"
    }
  }
}

Slack Integration:

Replace SNS email with Slack webhooks for team notifications.

Custom Metrics:

Add CloudWatch custom metrics for advanced monitoring and alerting.

Multi-Region Monitoring:

Deploy monitoring Lambda in multiple regions for global perspective.

What's Next?

You now have a production-ready website monitoring system! Here are some ideas for further enhancement:

Mobile App: Build a React Native app for monitoring on-the-go
Advanced Analytics: Add trend analysis and predictive alerts
Integration APIs: Connect with PagerDuty, Slack, or Microsoft Teams
SLA Reporting: Generate monthly uptime reports for stakeholders
Performance Budgets: Set and track performance goals over time

Wrapping Up

Building a comprehensive website monitoring system doesn't have to break the bank or require complex infrastructure. With AWS serverless services, React, and Terraform, you can create a robust monitoring solution that:

Monitors 24/7: Never miss downtime again
Costs Under $5/month: Fraction of commercial monitoring services
Provides Beautiful Dashboard: Real-time insights with professional UI
Scales Automatically: Handle traffic spikes without configuration
Sends Instant Alerts: Know about issues before your customers do

Key Benefits:

Set up once, monitor forever
Complete visibility into website performance
Professional-grade monitoring at startup prices
Full control over monitoring logic and alerts
Beautiful dashboard your team will actually use

Remember: You can't fix what you can't see.

Your website is your business's front door. Make sure you know when it's closed, how fast it opens, and whether visitors can find what they're looking for.

Now go forth and monitor with confidence!

Contact

Questions about this monitoring setup? Found an issue with the implementation? Want to share your monitoring success story?

Reach out:

Website: hasan-ashab
LinkedIn: linkedin.com/in/hasan-ashab

Happy monitoring! 🚀

Automate EC2 Backups on AWS with Lambda, EventBridge, and Terraform

Hasan Ashab — Thu, 02 Oct 2025 00:32:07 +0000

Stop losing sleep over manual backups.
Here is how to set up fully automated, cost-effective EC2 backups using AWS Lambda, EventBridge, and Terraform — no manual snapshots required.

Picture this:

It's 3 AM, your production server crashes, and you realize your last backup was... when exactly? We've all been there. Manual backups are like flossing – everyone knows they should do it, but somehow it never happens consistently.

Today, I'll show you how to build a completely automated EC2 backup system. By the end of this guide, you'll have a system that:

Backs up your EC2 instances every night automatically
Cleans up old snapshots to save costs
Logs everything for audit trails
Requires zero maintenance once deployed

The best part? It costs pennies to run and takes about 15 minutes to set up.

Why This Approach Works

Before we dive in, let's talk about why this serverless approach beats traditional backup solutions:

Cost-Effective: You only pay for what you use. No expensive backup software licenses or dedicated servers.
Reliable: AWS manages the infrastructure. No more "backup server is down" emergencies.
Scalable: Works whether you have 5 instances or 500. The system scales automatically.
Auditable: Every backup operation is logged and tracked.

The Architecture (Keep It Simple)

Our backup system has four main components:

EventBridge: Acts like a cron job, triggering backups daily
Lambda Function: The workhorse that creates and manages snapshots
EC2 Tags: Simple way to mark which instances need backing up
S3 Bucket: Stores backup logs for auditing

Here's how they work together:

EventBridge (Daily) → Lambda → Find Tagged EC2s → Create Snapshots → Log to S3

No complex orchestration, no fragile dependencies. Just simple, reliable automation.

What You'll Need

Before we start, make sure you have:

AWS CLI configured
Terraform installed (version 1.0 or later)
Basic familiarity with AWS services
About 15 minutes of your time

Don't worry if you're new to some of these tools – I'll walk you through everything.

Step 1: Project Structure

Let's start by creating our project structure. This keeps everything organized and makes the code reusable:

ec2-backup-automation/
├── main.tf                    # Main Terraform configuration
├── variables.tf               # Input variables
├── terraform.tfvars          # Your specific values
├── lambda/
│   └── lambda_function.py    # Backup logic
└── templates/
    └── lambda_policy.json    # IAM permissions

You can either clone the complete project or create the structure manually:

Option 1: Clone the complete project (recommended):

git clone https://github.com/HasanAshab/aws-ec2-backup-lambda.git
cd ec2-backup-automation

Option 2: Create the structure manually:

mkdir ec2-backup-automation
cd ec2-backup-automation
mkdir lambda templates

Step 2: The Lambda Function (The Heart of the System)

The Lambda function is where the magic happens. It finds EC2 instances tagged for backup, creates snapshots, and cleans up old ones.

Create lambda/lambda_function.py:

# Main Lambda handler
def lambda_handler(event, context):
    create_backups()
    cleanup_old_snapshots()
    save_logs_to_s3()

Full code available here

Step 3: IAM Permissions (Security Done Right)

Our Lambda needs specific permissions to do its job. Create templates/lambda_policy.json:

{
  "Version": "2008-10-17",
  "Id": "PolicyForEC2AutoBackupLambda",
  "Statement": [
    {
      "Sid": "AllowLogging",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Sid": "AllowEC2Actions",
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeVolumes",
        "ec2:CreateSnapshot",
        "ec2:DescribeSnapshots",
        "ec2:DeleteSnapshot",
        "ec2:CreateTags"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowPutS3",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject"
      ],
      "Resource": "${log_bucket_arn}/*"
    }
  ]
}

This follows the principle of least privilege – the Lambda can only do what it needs to do, nothing more.

Step 4: Terraform Configuration

Now let's tie everything together with Terraform. Create variables.tf:

# ...
variable "backup_schedule" {
  description = "EventBridge cron expression for backup schedule"
  type        = string
  default     = "cron(0 2 * * ? *)"  # 2 AM UTC daily
}

variable "retention_days" {
  description = "Number of days to retain snapshots"
  type        = number
  default     = 7
}

Now create main.tf. I'll break this down into logical sections so it's easier to understand:

S3 Bucket for Logs

Next, we'll create an S3 bucket to store our backup logs:

module "log_bucket" {
  source  = "terraform-aws-modules/s3-bucket/aws"
  version = "5.5.0"

  bucket = "${local.project_name}-log-${var.environment}"
  force_destroy = true
}

This creates a simple S3 bucket where our Lambda function will store detailed backup reports. The force_destroy = true allows Terraform to delete the bucket even if it contains files (useful for testing).

Lambda Function

Now for the heart of our system - the Lambda function:

module "lambda_function" {
  source  = "terraform-aws-modules/lambda/aws"
  version = "8.1.0"

  function_name = "${local.project_name}-backup-${var.environment}"
  source_path = "${path.module}/lambda/lambda_function.py"
  handler = "lambda_function.lambda_handler"
  runtime = "python3.12"

  attach_policy_json = true
  policy_json = templatefile("${path.module}/templates/lambda_policy.json", {
    log_bucket_arn = module.log_bucket.s3_bucket_arn
  })

  allowed_triggers = {
    eventbridge = {
      service    = "events"
      source_arn = module.eventbridge.eventbridge_rule_arns["crons"]
    }
  }

  create_current_version_allowed_triggers = false
  artifacts_dir = "${path.root}/.terraform/lambda-builds/"

  environment_variables = {
    ENVIRONMENT    = var.environment
    LOG_BUCKET = module.log_bucket.s3_bucket_id
    RETENTION_DAYS = var.retention_days
  }
}

This creates our Lambda function with:

Source code: Points to our Python file
IAM permissions: Uses the policy template we created
EventBridge trigger: Allows EventBridge to invoke the function
Environment variables: Passes configuration to our Python code

EventBridge Scheduler

Finally, let's set up the scheduler that triggers our backups:

module "eventbridge" {
  source = "terraform-aws-modules/eventbridge/aws"

  create_bus = false
  rules = {
    crons = {
      description         = "Daily EC2 backup"
      schedule_expression = var.backup_schedule
    }
  }
  targets = {
    crons = [
      {
        name = "ec2-backup-lambda"
        arn  = module.lambda_function.lambda_function_arn
      }
    ]
  }
}

This creates an EventBridge rule that:

Runs on schedule: Uses the cron expression from our variables
Targets our Lambda: Automatically invokes our backup function
Uses default event bus: No need for a custom event bus

Example EC2 Instances (Optional)

For testing purposes, let's also create some sample EC2 instances:

# Get default VPC and subnets for our test instances
data "aws_vpc" "default" {
  default = true
}

data "aws_subnets" "default" {
  filter {
    name   = "vpc-id"
    values = [data.aws_vpc.default.id]
  }
}

# Create test instances - some will be backed up, some won't
module "ec2_instance" {
  source  = "terraform-aws-modules/ec2-instance/aws"
  for_each = {
    "1" = "true"   # This instance will be backed up
    "2" = "true"   # This instance will be backed up
    "3" = "false"  # This instance will NOT be backed up
  }

  name = "instance-${each.key}"
  instance_type = "t3.micro"
  subnet_id = data.aws_subnets.default.ids[0]
  monitoring = false

  tags = {
    Backup = each.value  # This is the magic tag!
  }
}

This creates three test instances in your default VPC. Two are tagged for backup (Backup=true) and one isn't (Backup=false). This lets you see the system in action without affecting your existing instances.

Step 5: Deployment

Now deploy everything:

# Initialize Terraform
terraform init

# Review what will be created
terraform plan

# Deploy the infrastructure
terraform apply

Terraform will show you exactly what it's going to create. Type yes when you're ready to proceed.

Step 6: Test Your Backup System

Don't wait until disaster strikes to test your backups! Here's how to verify everything works:

Trigger a manual backup:

aws lambda invoke --function-name my-backup-fn response.json

Check the logs:

Go to CloudWatch → Log groups
Find /aws/lambda/my-backup-fn
Check the latest log stream

Verify snapshots were created:

Go to EC2 → Snapshots
Look for snapshots tagged with CreatedBy=automated-backup

Check S3 logs:

Go to S3 → your backup logs bucket
Look in the backup-logs/ folder for detailed reports

Monitoring and Maintenance

Your backup system is now running, but here are some tips to keep it healthy:

Set Up Alerts

Create a CloudWatch alarm to notify you if backups fail:

resource "aws_cloudwatch_metric_alarm" "backup_failures" {
  alarm_name          = "${local.project_name}-backup-failures"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "1"
  metric_name         = "Errors"
  namespace           = "AWS/Lambda"
  period              = "300"
  statistic           = "Sum"
  threshold           = "0"
  alarm_description   = "This metric monitors lambda errors"
  alarm_actions       = [aws_sns_topic.alerts.arn]

  dimensions = {
    FunctionName = module.lambda_function.lambda_function_name
  }
}

Cost Optimization

Monitor your snapshot costs and adjust retention as needed:

# Check snapshot costs
aws ce get-cost-and-usage \
  --time-period Start=2025-01-01,End=2026-01-31 \
  --granularity MONTHLY \
  --metrics BlendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

Regular Testing

Schedule monthly restore tests to ensure your backups actually work:

Create a test instance from a snapshot
Verify the instance boots and data is intact
Document the restore process

Troubleshooting Common Issues

Lambda timeout errors:

Increase the timeout in your Terraform configuration
Consider splitting large backup jobs across multiple Lambda invocations

Permission denied errors:

Check the IAM policy in templates/lambda_policy.json
Ensure your AWS credentials have sufficient permissions

Snapshots not being created:

Verify instances are tagged correctly (Backup=true)
Check CloudWatch logs for specific error messages
Ensure instances are in the same region as your Lambda

EventBridge not triggering:

Verify the cron expression is correct
Check that the Lambda permission allows EventBridge to invoke it

What's Next?

You now have a production-ready EC2 backup system! Here are some enhancements you might consider:

Multi-region backups: Copy snapshots to another region for disaster recovery
Slack notifications: Get notified when backups complete or fail
Backup verification: Automatically test that snapshots are restorable

Wrapping Up

Building automated backups doesn't have to be complicated. With Lambda, EventBridge, and Terraform, you can create a robust, cost-effective backup system in under an hour.

The key benefits of this approach:

Set it and forget it: Once deployed, it runs automatically
Cost-effective: Pay only for what you use
Scalable: Works for 5 instances or 500
Auditable: Complete logs of every backup operation
Reliable: Built on AWS managed services

Remember: Manual backups fail; automated backups succeed.

Your future self (and your boss) will thank you when that inevitable "we need to restore from backup" moment arrives, and you can confidently say: "No problem, we have automated backups running every night."

Now go tag those instances and sleep better knowing your data is protected!

Contact

Have questions about this setup? Found a bug in the code? Drop a comment below

or reach out:

Website: hasan-ashab
LinkedIn: linkedin.com/in/hasan-ashab

2048 in the Cloud: DevOps with AWS & ArgoCD

Hasan Ashab — Sun, 28 Sep 2025 05:27:27 +0000

Overengineering a simple game to practice real-world DevOps skills

TL;DR

Yes, I know — nobody needs Kubernetes, Terraform, and ArgoCD to run 2048. It's overkill. But that's exactly why I did it. By deploying a simple static game with enterprise-grade tools, I could focus purely on DevOps patterns without being distracted by app complexity.

This project turned the classic 2048 game into a cloud-native demo running on AWS with:

Docker + ECR for containerization
Kubernetes on EKS for orchestration
GitHub Actions for CI/CD
ArgoCD for GitOps deployments
Terraform for infrastructure as code

🔗 Source code on GitHub

Why 2048?

The game itself is trivial — just static HTML/JS. But that's the point. By stripping away complicated backend logic, You will be free to practice:

Building a full pipeline from scratch
Managing cloud infra with Terraform
Deploying to Kubernetes
Setting up GitOps with ArgoCD

It's not about the game. It's about showing that if you can deploy 2048 this way, you can deploy any app this way.

What I Built

1. Containerized the Game

I packaged the 2048 codebase into a Docker image using nginx:alpine as a lightweight web server:

FROM nginx:alpine
COPY . /usr/share/nginx/html/
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

This was pushed to Amazon ECR, ready for Kubernetes.

2. Kubernetes Deployment on EKS

I wrote manifests for:

Deployment: 3 replicas for availability, with resource limits and probes.
Service: Type LoadBalancer to expose via AWS Load Balancer.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: game-2048
spec:
  replicas: 3
  selector:
    matchLabels:
      app: game-2048
  template:
    metadata:
      labels:
        app: game-2048
    spec:
      containers:
      - name: game-2048
        image: <ECR_REPO>/game-2048:latest
        ports:
        - containerPort: 80

3. CI/CD with GitHub Actions

A workflow handles:

Linting and basic tests
Building + pushing Docker image to ECR
Updating manifests

This keeps the pipeline automated from commit → container → deployment.

4. GitOps with ArgoCD

Instead of manually applying manifests, I set up ArgoCD on EKS. It watches the Git repo and automatically syncs changes, giving me:

Automated deployments
Rollback capabilities
A nice UI to visualize app state

5. Infrastructure with Terraform

Terraform provisions:

VPC + subnets
EKS cluster + node groups
ECR repository

This makes the whole setup reproducible in any AWS account.

Lessons Learned

GitOps feels powerful: Letting ArgoCD drive deployments keeps clusters in sync with Git.
IaC saves time: Rebuilding infra with Terraform is way easier than clicking through AWS console.
Overkill is okay for learning: Practicing with simple apps helps when stakes are low.
Docker + EKS + ArgoCD is a solid baseline stack for real-world apps.

What's Next

If I revisit this project, I'd like to:

Add monitoring (CloudWatch or Prometheus)
Use Fargate for serverless pods
Try spot instances for cost savings
Add Route53 + SSL for a proper domain

Final Thoughts

Running 2048 on AWS with Terraform, Kubernetes, and ArgoCD is complete overkill — and that's exactly the point. This project let me practice the same workflows companies use in production, but in a low-stakes, fun environment.

If you can take a tiny game and ship it with a full DevOps stack, you're already building the habits needed for larger, real-world systems.

📬 Contact

If you have any doubts, feel free to reach out and ask:

Website: hasan-ashab
LinkedIn: linkedin.com/in/hasan-ashab

From $820 to $92: How A Startup Cut Cloud Costs by 88%

Hasan Ashab — Thu, 25 Sep 2025 00:58:23 +0000

Last night my foreign cousin was sharing his startup story with me.

Things were going well — their product was gaining users, the team was excited… but then he mentioned the AWS cloud bill. What began as a few hundred dollars a month had suddenly ballooned into the thousands. For a small team, that’s brutal.

This isn’t rare. Startups (and small teams) often scale the product faster than they manage costs. The good news: most cloud-cost problems are straightforward to fix. Here’s a simple, non-overwhelming checklist that actually works.

1. Don’t Over-Engineer for Small Teams

A classic money trap is spinning up production-grade infrastructure for non-critical tasks. I’ve seen early-stage teams launch a full-blown EKS cluster just to run CI/CD pipelines. That’s like renting an office tower just to store sticky notes.

👉 Fix: For testing and pipelines, use Kind, Minikube, or even lightweight managed CI/CD tools. Keep Kubernetes clusters for production workloads — not for experimenting.

2. Right-Size Your Instances

My cousin had several servers idling at ~20% CPU — like renting a conference hall for one person.

👉 Fix: Move to smaller instance types, enable auto-scaling, and review sizing monthly. Don’t pay for unused headroom.

3. Implement Scheduling Tools

Think of this as flipping off the lights when you leave the office. Non-critical resources (like test databases or staging VMs) don’t need to run during nights and weekends.

👉 Fix: Use scheduling tools (like AWS Instance Scheduler, Azure Automation, or GCP Scheduler) to shut things down during off-hours.

4. Automate Non-Prod Shutdowns

Dev and staging environments don’t need to run 24/7. Yet many teams forget to turn them off.

👉 Fix: Schedule automatic stop/start (nights, weekends) or use ephemeral environments spun up by CI.

5. Use Discounted Options Wisely

Paying list price for everything is expensive. There are cheaper options if you plan a bit.

👉 Fix:

Reserved instances for predictable, long-running workloads.
Spot/preemptible instances for batch jobs, CI runs, or anything that can tolerate interruptions.

6. Cut Data Transfer (Egress) Costs

Cross-region traffic and uncontrolled log shipping can surprise you. My cousin’s service was shuttling logs between regions — huge egress fees.

👉 Fix: Co-locate services in the same region, use a CDN for static assets, compress or batch logs, and avoid unnecessary cross-region calls.

7. Cache, Cache, Cache

Serving the same data repeatedly from compute or the origin costs more than a cache.

👉 Fix: Add caching for frequently requested items (CDN, Redis, in-memory caches). It reduces compute and bandwidth.

8. Leverage Infrastructure as Code (IaC)

Manual provisioning often leads to forgotten, duplicate, or oversized resources. IaC keeps things clean and repeatable.

👉 Fix: Use Terraform, CloudFormation, or Pulumi to define infrastructure. This ensures resources are consistently right-sized and prevents accidental overspending.

9. Spot the “Zombie” Resources

Old test servers, forgotten storage buckets, and unused IPs quietly drain money.

👉 Fix: Do a weekly cleanup. If you can’t explain a resource in 60 seconds, stop it or tag it for deletion.

10. Set Budgets and Alerts (and Enforce Them)

The easiest prevention is a simple alert before things spiral. Too many teams treat budget alerts as optional.

👉 Fix: Configure cost alerts that notify the team and enforce escalation (Slack + email + owner). Treat alerts like production incidents.

🚀 Quick Results You Can Expect

Apply these fixes and you’ll usually see 20–50% savings within a month. My cousin implemented these and cut their monthly bill by nearly half — money that went straight into hiring and product improvements.

“Learn from others mistakes, not yours.”

Cloud cost control isn’t magic. It’s discipline. Do those and your cloud will stop eating your runway.

📬 Contact

If you have any doubts, feel free to reach out and ask:

Website: hasan-ashab
LinkedIn: linkedin.com/in/hasan-ashab

Deploying Containers on AWS: The One Guide You Need

Hasan Ashab — Mon, 22 Sep 2025 09:36:12 +0000

When I first started working with containers on AWS, I was overwhelmed. There were too many services—ECS, EKS, Lambda, App Runner, Lightsail—and each one came with its own pros and cons. The real struggle wasn’t running containers; it was deciding where to run them.

If you’ve ever felt the same, you’re not alone. That’s why I put together this guide. Think of it as a friendly map—helping you pick the right AWS service without drowning in documentation.

Step 1: Ask Yourself — Do You Need Kubernetes?

Kubernetes is powerful, but also complex. If you’re already using it or plan to, Amazon Elastic Kubernetes Service (EKS) is the natural choice.

Pros: Fully managed, highly scalable.
Cons: Setup isn’t beginner-friendly, and pricing is resource-based.

If Kubernetes isn’t part of your journey, no worries. AWS has plenty of other roads to explore.

Step 2: Serverless or Provisioned?

This is the big fork in the road.

If you want AWS to handle servers for you → go Serverless.
If you want full control over compute resources → go Provisioned.

The Serverless Path 🚀

Not sure if serverless is the right direction?
I wrote a separate guide on When to Go Serverless. that might help you decide.

The Provisioned Path ⚙️

If you prefer setting things up yourself:

Lightsail: Simplest UI, great for small projects.

Catch: You’re locked into AWS’s ecosystem.

ECS (Elastic Container Service): Managed orchestration without Kubernetes.

Best for: Teams that need scaling + orchestration but don’t want Kubernetes overhead.
Downside: Steep learning curve.

EC2: Old-school way—install Docker and manage everything yourself.

Best for: Absolute control freaks.
Downside: Frustrating setup and heavy maintenance.

A Visual Shortcut

Here’s a handy flowchart to guide your decision:

This chart sums up everything we just walked through—so you can quickly see which AWS service matches your needs.

Final Thoughts

There isn’t a single “best” way to run containers on AWS. The right choice depends on your priorities:

Ease of use? → Lightsail or App Runner.
Serverless-first mindset? → Lambda or Fargate.
Already love Kubernetes? → EKS.
Want to tinker with everything? → EC2.

The good news is, no matter which road you take, AWS has you covered. Start small, experiment, and you’ll soon find the perfect fit for your workloads.

📬 Contact

If you have any doubts (Cloud or DevOps), feel free to reach out:

Website: hasan-ashab
LinkedIn: linkedin.com/in/hasan-ashab

A Serverless Todo App on AWS with Terraform and GitHub Actions

Hasan Ashab — Sun, 21 Sep 2025 05:12:32 +0000

When I started this project, I didn’t want to just build another todo app. We’ve all seen those before. My goal was different: build something simple on the outside, but production-ready on the inside — something that shows what a DevOps engineer actually does.

That’s how this Serverless Todo App came to life. A lightweight frontend for users, but behind it sits a complete AWS setup: serverless compute, Infrastructure as Code, and automated CI/CD pipelines.

🌱 Why Serverless?

The choice was clear. For small apps (and honestly, for many startups too), serverless hits the sweet spot:

Perfect for apps with unpredictable traffic (like side projects, MVPs, or apps with spiky usage)
Scales up (and down to zero) automatically
Pay only for what you use (almost zero cost when idle)
High availability by default

Basically: if your customer base is uncertain or your workload isn’t steady, serverless is the go-to choice.

🏗️ The Architecture

I followed a classic three-tier approach — but all serverless:

Frontend

React app hosted in S3
CloudFront for fast, global delivery
OAC so no one can hit S3 directly

Backend

API Gateway to handle requests
Lambda functions for each CRUD operation
IAM roles with the bare minimum permissions

Database

DynamoDB table with id as hash key
Pay-per-request billing — no wasted capacity

Here’s a sketch of it all working together:

🔧 Infrastructure as Code with Terraform

Instead of clicking around the AWS console, everything is defined in Terraform. I broke it into modules:

frontend/ → S3 + CloudFront setup
backend/ → API Gateway + Lambda functions + IAM
dynamodb/ → Key-value table

This modular approach made it easy to spin up dev, staging, and prod environments. Just change a tfvars file, and Terraform does the rest.

⚙️ CI/CD Pipelines

The real DevOps flavor comes here. I used GitHub Actions to automate deployments:

Frontend pipeline → Build React app, push to S3, invalidate CloudFront
Backend pipeline → Package & deploy Lambda functions
Infra pipeline → Terraform plan/apply with drift detection

Production deployments always require manual approval — I wanted it to feel realistic, not reckless.

🔍 Monitoring & Security

A few non-negotiables I baked in:

CloudWatch metrics and alerts for errors and latency
Terraform drift detection (to catch sneaky manual console changes)
IAM least privilege for every Lambda
CloudFront enforcing HTTPS and hiding the S3 bucket

Nothing fancy, just the basics done right.

💸 Cost-Friendly by Default

Since it’s serverless:

Lambda only bills on execution
DynamoDB scales automatically
CloudFront caching reduces backend hits

In idle periods, the whole system costs almost nothing.

🛠️ What I Learned

Terraform modules are a lifesaver for reusability
Separate pipelines keep infra, backend, and frontend independent
Serverless debugging is trickier than traditional apps (logs are your best friend)
Cold starts exist, but caching and design can reduce the pain

🚀 Why This Project Matters

At first glance, it’s “just a todo app.” But under the hood, it’s a real-world DevOps case study:

Infrastructure as Code
Automated CI/CD
Secure, scalable, cost-efficient design
Production-ready practices like monitoring, drift detection, and multi-env setups

📂 Code & Repo

You can check out the full implementation here:
👉 Serverless Todo App on GitHub

Final Thought

I built this project to show that even something simple can demonstrate serious DevOps skills when designed with the right mindset.

📬 Contact

If you’d like to connect, collaborate, or discuss DevOps, feel free to reach out:

Website: hasan-ashab
GitHub: github.com/HasanAshab
LinkedIn: linkedin.com/in/hasan-ashab

Serverless: The Hype is Real. But Is It For You?

Hasan Ashab — Thu, 18 Sep 2025 09:26:12 +0000

A couple of months ago, A friend of mine told me how their team started a side project at a café. They were ambitious but strapped for time and resources. Someone suggested: “Why don’t we just go serverless?”

The room lit up. Serverless sounded magical — no servers to manage, instant scaling, and a pay-as-you-go model. It was like being promised a sports car with no gas bills. They jumped in.

And yes, the hype felt very real.

The Allure of Serverless

At first, it felt like cheating. With just a few lines of code and some clicks on AWS, they had a function running in the cloud. Requests came in, it responded instantly, and no one had to touch a single server.

That’s the beauty of serverless:

Auto-scaling — it grows with you.
Lower upfront cost — you pay only for execution time, not idle servers.
Speed — perfect for shipping features fast.
Event-driven magic — upload an image, and boom, a function resizes it automatically.

For small teams and startups, this is a dream. You can get an MVP live in days, not weeks.

Reality Check: The Caveats

But dreams have their fine print. As the project grew, cracks started to show.

Cold Starts: The first request after a function sat idle? Slow. Painfully slow. Imagine users waiting an extra second or two just because the function needed to “wake up.”
Vendor Lock-In: They built tightly around AWS Lambda. When they thought about moving parts of the system elsewhere, the cost of rewriting was overwhelming.
Debugging and Monitoring: Traditional logs and metrics didn’t tell the full story. Tracking errors across dozens of tiny functions was like chasing shadows.
Cost Pitfalls: While serverless seemed cheap in the beginning, their bill spiked once traffic became steady. The per-execution cost wasn’t built for heavy, consistent workloads.

The magic wasn’t gone — but it came with strings attached.

Who Really Wins With Serverless?

That journey taught them (and me, by hearing it) something simple: serverless isn’t bad. It’s just situational.

Great fit for:

Startups testing an idea without big infrastructure spend.
Apps with spiky traffic (events, notifications, seasonal demand).
Background tasks like image resizing, PDF generation, or chatbots.

Not ideal for:

Heavy, long-running jobs like video rendering.
Applications that demand ultra-low latency at all times.
Teams that want full control over networking, scaling policies, or cost optimization.

The Future: Not Just a Fad

Despite the struggles, serverless isn’t a passing trend. It’s evolving fast.

Cloudflare Workers and Vercel Edge Functions push compute even closer to users.
Serverless databases are emerging to solve the data bottleneck.
Hybrid approaches let you mix traditional servers with serverless functions.

For many companies, the future isn’t “all-in serverless” — it’s about using it where it shines, and avoiding it where it doesn’t.

Final Thought

Hearing their story made me rethink the “serverless hype.” It’s not just buzz — the power is real. But it also made me realize it’s not a one-size-fits-all solution.

So before you jump in, ask yourself: Is this the hammer I need, or am I just chasing the shine of something new?

📬 Contact

If you’d like to connect, collaborate, or discuss DevOps, feel free to reach out:

Website: hasan-ashab
GitHub: github.com/HasanAshab
LinkedIn: linkedin.com/in/hasan-ashab

From 1.2GB to 54MB: My Docker Image Went on a Diet

Hasan Ashab — Wed, 17 Sep 2025 01:28:02 +0000

When I first containerized my Node.js app, I felt pretty good about myself. I had a Dockerfile, I built it, and it worked.

Then I checked the size.

1.2GB. For a single Node.js service.

That’s when reality hit me. My image wasn’t lean—it was obese. It slowed down builds, bloated my CI/CD pipeline, took forever to push to the registry, and ate storage like there was no tomorrow.

So, I put my Docker image on a strict diet. After a few rounds of optimizations, it went from 1.2GB → 250MB → 54MB.

Here’s the story of how I cut the fat—and how you can too.

Step 1: The Heavyweight Start

Here’s what my original Dockerfile looked like:

FROM node:16

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

CMD ["node", "server.js"]

Looks innocent, right? But it had several problems:

node:16 is Debian-based and heavy (~350MB).
npm install installed everything—dev and production dependencies.
No .dockerignore, so logs, git history, and node_modules sneaked into the image.

The result? A 1.2GB monster that slowed everything down.

Step 2: Choosing a Leaner Base

The first fix was swapping node:16 for node:16-alpine.

FROM node:16-alpine

That one-line change cut my image down to ~250MB.

Lesson: Your base image choice can make or break your build.

⚠️ Caveat: Alpine uses musl instead of glibc. If your app has native modules (sharp, bcrypt, canvas), you may need extra packages.

Step 3: Multi-Stage Builds

My app uses TypeScript, so I had build tools sitting inside the final image. Big mistake. They added hundreds of MBs I didn’t need in production.

Enter multi-stage builds:

# Stage 1: Builder
FROM node:16-alpine AS builder

WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: Runtime
FROM node:16-alpine

WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY package*.json ./
RUN npm ci --only=production

CMD ["node", "dist/server.js"]

Now, the final image contains only:

Compiled JavaScript (dist/)
Production dependencies

No dev dependencies. No build cache. No clutter.

This dropped my image to ~120MB.

Step 4: Prune and Ignore Junk

Another culprit: files that had no business being in production.

I added a .dockerignore:

node_modules
npm-debug.log
Dockerfile
.dockerignore
.git
.gitignore
*.md
tests

And I cleaned up caches in the Dockerfile:

RUN npm ci --only=production \
    && npm cache clean --force \
    && rm -rf /tmp/*

End result: no accidental junk, no wasted MBs.

Step 5: Minimize Layers

At first, I had a Dockerfile with multiple RUN statements:

RUN apk add --no-cache python3
RUN npm ci --only=production
RUN npm cache clean --force

Each RUN adds a layer. I combined them into one:

RUN apk add --no-cache python3 \
    && npm ci --only=production \
    && npm cache clean --force

This small tweak shaved off ~15MB. Not huge, but every MB counts when you’re pulling images in production.

Step 6: Measuring and Iterating

The key to trimming images is measuring:

docker images
docker history <image>

With docker history, I saw exactly which layer was eating space and optimized from there.

Final Weight Check

Original: 1.2GB
After switching to Alpine: ~250MB
After multi-stage + pruning: 120MB
After .dockerignore + cleanup: 54MB 🎉

That’s a ~95% reduction. Pulls went from minutes to seconds, and CI/CD pipelines stopped crawling.

Lessons Learned

Pick the right base image – Defaults are rarely optimal.
Multi-stage builds are gold – Keep dev tools out of production.
Use .dockerignore religiously – Don’t ship junk.
Prune aggressively – Caches, logs, temp files… delete them.
Measure constantly – Know what’s eating space before fixing it.

Conclusion

Cutting Docker image size isn’t just about bragging rights—it’s about faster deploys, lower registry costs, and fewer headaches.

My Node.js image went on a diet and lost 1.1GB, and I’ll never go back to lazy Dockerfiles again.

If your containers are bloated, trust me: a few tweaks can make them featherweight.

So… is your Docker image on a healthy diet?

📬 Contact

If you’d like to connect, collaborate, or discuss DevOps, feel free to reach out:

Website: hasan-ashab
GitHub: github.com/HasanAshab
LinkedIn: linkedin.com/in/hasan-ashab

Productionizing AWS’s Retail Sample App with GitOps on EKS

Hasan Ashab — Tue, 16 Sep 2025 04:54:56 +0000

How I transformed AWS’s demo retail microservices application into a production-ready, cost-optimized platform using Terraform, GitHub Actions, ArgoCD, and EKS Auto Mode.

Background

The AWS Retail Sample App is a microservices-based demo designed to showcase cloud-native workloads. While it demonstrates architecture concepts, it’s not “production-ready” out of the box.

The objective of this project was to:

Take the AWS Retail Sample App (5 microservices)
Deploy it on Amazon EKS
Implement infrastructure as code, CI/CD, and GitOps
Ensure the setup was secure, observable, and cost-efficient

This case study documents the approach, challenges, and outcomes.

Architecture Overview

The final platform integrated:

Terraform for infrastructure as code
Amazon EKS Auto Mode to simplify compute management
GitHub Actions for CI/CD with intelligent change detection
ArgoCD for GitOps-driven continuous delivery
ECR as the private container registry
Ingress + Cert Manager for HTTPS traffic
Optional Prometheus/Grafana for observability

High-level workflow:

Developer → GitHub → GitHub Actions → ECR → ArgoCD → EKS

Implementation

1. Infrastructure as Code with Terraform

Deployed EKS with Auto Mode, eliminating the need to manage node groups.
Added random suffix strategy for unique cluster naming.
Provisioned add-ons (Ingress, Cert Manager, optional monitoring stack).

2. CI/CD with GitHub Actions

Implemented change detection to rebuild only modified services.
Built and pushed Docker images to private ECR.
Updated Helm values with new image tags.

3. GitOps with ArgoCD

Configured one ArgoCD application per service, avoiding a single umbrella chart.
Enabled automatic sync with Git as the source of truth.
Supported granular rollouts, service-level visibility, and independent rollbacks.

4. Security & Cost Controls

Enforced private ECR with scanning + encryption.
Applied IAM least-privilege policies for CI/CD and services.
Used single NAT gateway in dev and spot instance support for cost optimization.

Key Challenges and Solutions

Node Group Complexity → Solved with EKS Auto Mode for hands-free compute scaling.
Helm Chart Updates Overwriting Infra Images → Implemented targeted AWK script to update only app images.
GitOps Workflow Discipline → Enforced branch protections and structured Git flows.

Results

Deployment Speed:
- Infrastructure: 15–20 mins
- Application changes: 3–5 mins
- Single service update: 1–2 mins
Cost Efficiency:
- Auto Mode prevented over-provisioning
- Change detection reduced unnecessary builds
- Shared NAT + optional spot instances lowered non-prod expenses
Production Readiness:
- HTTPS ingress with auto certificates
- RBAC/IAM security enforcement
- Optional monitoring and alerting enabled

Lessons Learned

EKS Auto Mode dramatically reduces operational overhead.
Change detection in CI/CD is a simple but powerful optimization.
GitOps adds discipline and traceability but requires strict Git hygiene.
Security and observability should be built in from day one, not after incidents.

At a Glance

By productionizing the AWS Retail Sample App, this project demonstrates how a demo workload can be elevated into a secure, cost-optimized, and fully automated cloud-native platform.

The integration of Terraform, GitHub Actions, ArgoCD, and EKS Auto Mode provided:

Automated infrastructure provisioning
Intelligent CI/CD pipelines
GitOps-driven deployments
Security, monitoring, and cost controls

This approach can be adapted to any microservices-based workload seeking production readiness with efficient DevOps practices.

Check out the source code at GitHub for more details.

📬 Contact

If you’d like to connect, collaborate, or discuss DevOps, feel free to reach out:

Website: hasan-ashab
GitHub: github.com/HasanAshab
LinkedIn: linkedin.com/in/hasan-ashab

Forem: Hasan Ashab

Don’t Learn DevOps Before Understanding Web Development

How I Started

The “Why” Behind the Tools

A Simple 3-Tier App Can Teach You Everything

Real DevOps Is About Solving Problems, Not Running Pipelines

My Advice

Final Thoughts

📬 Contact

Creating a CLI Tool with Node.js

Why Build a CLI Tool?

The Node.js CLI Ecosystem

Commander.js vs SamerArtisan — Which Should You Use?

🧱 Commander.js: The Classic Choice

💎 SamerArtisan: Structure with Style

Getting Started with SamerArtisan

Step 1: Install

Step 2: Set Up Your CLI Entry File

Step 3: Create a Command

Features That Make SamerArtisan Special

1. Interactive Prompts

2. Beautiful Output

3. TypeScript Support

4. Easy Organization

Best Practices for CLI Design

✅ Make It Scriptable and Interactive

⚠️ Handle Errors Gracefully

🧭 Document Everything

Real-World Example: Database Migrations

When to Choose SamerArtisan

Final Thoughts

Why You Should Use AWS Backup Instead of Custom Lambda Solutions

Jump To:

The Problem with Custom Solutions

Why AWS Backup Wins

Zero Code Maintenance

Enterprise Features Out of the Box

Better Security

Superior Monitoring

Migration Guide

Before: Custom Lambda Architecture

After: AWS Backup Architecture

The New Architecture

Implementation

Benefits Comparison

Cost Analysis

Migration Steps

1. Update Your Tags

2. Deploy AWS Backup Resources

3. Test the Migration

Real-World Results

Contact

Never Miss a Downtime: AWS Website Uptime Monitor with Terraform

Jump To:

Picture this:

Why This Solution Works

The Architecture (Simple Yet Powerful)

What You'll Need

Step 1: Project Structure

Step 2: The Monitoring Lambda (The Watchdog)

Step 3: Dashboard API (Serving the Data)

Metrics Endpoint (get.mjs)

Recent Pings Endpoint (create.mjs)

All Data Endpoint (list.mjs)

Step 4: React Dashboard (Beautiful Real-Time UI)

Key Features:

Main Dashboard Component (App.js):

Step 5: Terraform Infrastructure

Main Configuration (infra/main.tf):

Configuration Variables (infra/variables.tf):

Environment Configuration (infra/envs/prod.tfvars):

Step 6: Deployment

Deploy Infrastructure:

Deploy Frontend:

Step 7: Test Your Monitoring System

Trigger Manual Check:

Check Monitoring Logs:

Verify Data Storage:

Test Dashboard:

Test Alerts:

Metrics Endpoint (`get.mjs`)

Recent Pings Endpoint (`create.mjs`)

All Data Endpoint (`list.mjs`)

Main Dashboard Component (`App.js`):

Main Configuration (`infra/main.tf`):

Configuration Variables (`infra/variables.tf`):

Environment Configuration (`infra/envs/prod.tfvars`):