DEV Community: Dharm Pal

Architecting for Resiliency: Building a Multi-Region Disaster Recovery Setup on AWS

Dharm Pal — Fri, 09 Oct 2026 19:49:15 +0000

No matter how robust a single AWS availability zone or region is, enterprise production workloads require a bulletproof strategy for unexpected outages. For critical business applications, relying on a single geographic region is a significant risk.

With over 12 years in IT and 6+ years architecting scalable cloud solutions, I have designed several multi-region setups. In this post, I will share the architectural blueprints for a robust Active-Passive Disaster Recovery (DR) topology using Amazon Route 53, AWS Application Load Balancers (ALB), and Amazon RDS Cross-Region Read Replicas.

🏗️ The Multi-Region DR Architecture

We will set up our infrastructure across two distinct AWS regions:

Primary Region (e.g., us-east-1): Handles 100% of the live production traffic.
Secondary DR Region (e.g., us-west-2): Remains on standby, receives asynchronous database replication, and takes over immediately if the primary region goes offline.

[ Client Request ]
       │
       ▼
┌─────────────────────────┐
│  Amazon Route 53        │ ◄── (Failover Routing Policy via Health Checks)
└────┬───────────────┬────┘
     │               │
     │ (Active)      │ (Passive Standby)
     ▼               ▼
┌───────────────┐ ┌───────────────┐
│ Primary Region│ │  DR Region    │
│ (us-east-1)   │ │  (us-west-2)  │
│  ┌─────────`  │ │  ┌─────────┐  │
│  │   ALB   │  │ │  │   ALB   │  │
│  └────┬────┘  │ │  └────┬────┘  │
│       ▼       │ │       ▼       │
│  ┌─────────┐  │ │  ┌─────────┐  │
│  │ RDS Primary│ │  │RDS Replica │
│  └────┬────┘  │ │  └─────────┘  │
└───────┼───────┘ └───────────────┘
        │                 ▲
        └─(Asynchronous)──┘

🛠️ Step 1: Configuring Global Database Replication

To minimize your Recovery Point Objective (RPO), your data must reside safely in the secondary region before disaster strikes. For relational data, we leverage Amazon RDS cross-region replication.

Here is how you define the Primary database and its encrypted, cross-region counterpart:

# Primary Database in us-east-1
resource "aws_db_instance" "primary_db" {
  allocated_storage    = 50
  engine               = "postgres"
  engine_version       = "15.4"
  instance_class       = "db.r6g.xlarge"
  db_name              = "production_db"
  username             = "cloud_admin"
  password             = var.db_password
  backup_retention_period = 7
  multi_az             = true
  skip_final_snapshot  = false
}

# Cross-Region Read Replica in us-west-2
resource "aws_db_instance" "dr_replica" {
  provider            = aws.us-west-2
  replicate_source_db = aws_db_instance.primary_db.arn
  instance_class      = "db.r6g.xlarge"
  skip_final_snapshot = true
  storage_encrypted   = true
}

🚦 Step 2: Intelligent Routing with Route 53 DNS Failover

The heart of an automated Active-Passive setup is Amazon Route 53 Health Checks. Route 53 continuously probes the primary public-facing Application Load Balancer. If it detects a failure, it dynamically shifts DNS records to point to the DR region.

# Route 53 Health Check for the Primary Load Balancer
resource "aws_route53_health_check" "primary_health" {
  fqdn              = aws_lb.primary_alb.dns_name
  port              = 443
  type              = "HTTPS"
  resource_path     = "/healthz"
  failure_threshold = 3
  request_interval  = 30
}

# Primary DNS Record (Active)
resource "aws_route53_record" "primary_dns" {
  zone_id = var.hosted_zone_id
  name    = "app.myenterprise.com"
  type    = "A"

  failover_routing_policy {
    type = "PRIMARY"
  }

  set_identifier = "primary-active"
  health_check_id = aws_route53_health_check.primary_health.id

  alias {
    name                   = aws_lb.primary_alb.dns_name
    zone_id                = aws_lb.primary_alb.zone_id
    evaluate_target_health = true
  }
}

# Secondary DNS Record (Passive Standby)
resource "aws_route53_record" "secondary_dns" {
  zone_id = var.hosted_zone_id
  name    = "app.myenterprise.com"
  type    = "A"

  failover_routing_policy {
    type = "SECONDARY"
  }

  set_identifier = "secondary-passive"

  alias {
    name                   = aws_lb.dr_alb.dns_name
    zone_id                = aws_lb.dr_alb.zone_id
    evaluate_target_health = true
  }
}

💡 Crucial Operational Metrics: RTO vs. RPO

When presenting a Disaster Recovery plan to enterprise stakeholders, you must explicitly define your core operational boundaries:

Recovery Point Objective (RPO): The maximum targeted duration during which data might be lost due to a major incident. By using asynchronous RDS replication, our RPO is typically under a few minutes.
Recovery Time Objective (RTO): The duration of time within which a business process must be restored. In this setup, our RTO is governed by the Route 53 TTL and health check thresholds (typically under 2 to 3 minutes for automated DNS redirection).

🚀 Conclusion

Building a cross-region architecture requires careful planning around data serialization and DNS propagation times. However, the operational peace of mind it gives your enterprise organization is unmatched.

How does your organization handle business continuity? Do you use an Active-Passive standby, or are you utilizing a fully hot Active-Active global topology? Let's discuss in the comments below!

Infrastructure as Code: Deploying AWS Cost Optimization Engines with Terraform

Dharm Pal — Fri, 09 Oct 2026 19:40:54 +0000

In my previous post, we looked at a Python script designed to automatically clean up idle EBS volumes. However, manually deploying that script, configuring IAM roles, and setting up EventBridge schedules via the AWS Management Console doesn't scale for production.

To achieve true enterprise operational efficiency, everything must be managed as Infrastructure as Code (IaC).

With over 12 years in IT and 6+ years managing scalable AWS infrastructure, I always recommend automating cloud governance architectures from day one. In this article, I will share the complete production-ready Terraform templates to package and deploy our serverless cost optimization engine.

📁 Project Directory Structure

To keep our infrastructure configurations maintainable, we will break our codebase into standard Terraform modules:

aws-cost-optimizer/
├── main.tf        # Core Lambda & EventBridge infrastructure
├── iam.tf         # Strict IAM roles and least-privilege policies
├── variables.tf   # Customizable deployment variables
└── src/
    └── lambda_function.py  # Our optimization script from post #1

🛠️ 1. Defining Variables (`variables.tf`)

First, we establish our variables. This enables different environment setups (like Dev vs. Production) to utilize custom time frames for resource checks.

variable "aws_region" {
  type        = string
  default     = "us-east-1"
  description = "The target AWS region for deployment"
}

variable "retention_days" {
  type        = number
  default     = 7
  description = "Number of days an EBS volume must be idle before deletion"
}

🔒 2. Strict IAM Security Guardrails (`iam.tf`)

As an AWS Certified Solutions Architect, I cannot stress enough the importance of the Principle of Least Privilege. Our Lambda execution role should only have permissions to scan and delete what it absolutely needs.

# Create the IAM Role for Lambda Execution
resource "aws_iam_role" "lambda_cost_optimizer_role" {
  name = "lambda-cost-optimizer-execution-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action    = "sts:AssumeRole"
      Effect    = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
    }]
  })
}

# Attach Strict Least-Privilege Custom Policies
resource "aws_iam_role_policy" "lambda_ec2_policy" {
  name = "lambda-cost-optimizer-ec2-policy"
  role = aws_iam_role.lambda_cost_optimizer_role.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = [
          "ec2:DescribeVolumes",
          "ec2:CreateSnapshot",
          "ec2:DeleteVolume"
        ]
        Resource = "*"
      },
      {
        Effect   = "Allow"
        Action   = [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents"
        ]
        Resource = "arn:aws:logs:*:*:*"
      }
    ]
  })
}

🏗️ 3. Main Automation & Scheduling Engine (`main.tf`)

This file handles packaging the Python script on the fly, creating the Lambda resource, and setting up the weekly EventBridge cron scheduler.

provider "aws" {
  region = var.aws_region
}

# Automatically package the Lambda source directory into a ZIP archive
data "archive_file" "lambda_zip" {
  type        = "zip"
  source_dir  = "${path.module}/src"
  output_path = "${path.module}/lambda_function.zip"
}

# Deploy the Lambda Resource
resource "aws_lambda_function" "cost_optimizer" {
  filename         = data.archive_file.lambda_zip.output_path
  function_name    = "ebs-cost-optimizer-engine"
  role             = aws_iam_role.lambda_cost_optimizer_role.arn
  handler          = "lambda_function.lambda_handler"
  runtime          = "python3.11"
  source_code_hash = data.archive_file.lambda_zip.output_base64sha256
  timeout          = 60

  environment {
    variables = {
      RETENTION_DAYS = var.retention_days
    }
  }
}

# Setup the EventBridge Cron Trigger (Every Friday at 6:00 PM UTC)
resource "aws_cloudwatch_event_rule" "weekly_trigger" {
  name                = "ebs-cleanup-weekly-schedule"
  description         = "Triggers cost optimization engine at the end of the work week"
  schedule_expression = "cron(0 18 ? * FRI *)"
}

# Link EventBridge to Lambda
resource "aws_cloudwatch_event_target" "trigger_lambda" {
  rule      = aws_cloudwatch_event_rule.weekly_trigger.name
  target_id = "TriggerLambdaCostOptimizer"
  arn       = aws_lambda_function.cost_optimizer.arn
}

# Allow EventBridge to Invoke the Lambda Function
resource "aws_lambda_permission" "allow_eventbridge" {
  statement_id  = "AllowExecutionFromEventBridge"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.cost_optimizer.function_name
  principal     = "events.amazonaws.com"
  source_arn    = aws_cloudwatch_event_rule.weekly_trigger.arn
}

💡 Production Architecture Best Practices

When deploying this inside your organization, implement these two key practices:

Remote State Files: Never store your local terraform.tfstate file on your work machine. Store it safely inside an encrypted Amazon S3 bucket configured with state locking via an Amazon DynamoDB table to prevent concurrent updates.
Environment Isolation: Use Terraform workspaces or distinct folder paths (environments/dev and environments/prod) to thoroughly test code changes in staging environments prior to executing deployments in production data structures.

🚀 Conclusion

By combining AWS serverless computing with Terraform, your organization shifts away from tedious manual monitoring dashboards into an elegant model of fully automated infrastructure lifecycle management.

Do you manage your serverless scripts via cloud consoles, or do you standardize everything through infrastructure as code pipelines? Let's discuss in the comments below!

Automating Cloud Cost Optimization: How to Automatically Clean Up Idle AWS Resources

Dharm Pal — Fri, 09 Oct 2026 18:17:06 +0000

As cloud infrastructure scales, idle resources like unattached EBS volumes, obsolete EC2 instances, and abandoned Elastic IPs quietly drain your budget. Managing this manually in an enterprise environment with hundreds of resources is impossible.

With over 12 years in IT and 6+ years managing production workloads on AWS, I’ve found that the best way to control cloud spend is to shift from reactive monitoring to automated remediation.

In this post, I will share a production-ready blueprint to automatically identify and clean up idle AWS resources using AWS Lambda, Amazon EventBridge, and AWS Systems Manager (SSM).

🏗️ The Automated Architecture

Instead of just looking at cost dashboards, we can build a serverless automation engine that cleans up resources during off-peak hours:

Amazon EventBridge triggers a cron job every Friday at 6:00 PM.
An AWS Lambda function scans the account for unattached EBS volumes and idle Elastic IPs.
If an idle resource is found, Lambda triggers an AWS Systems Manager (SSM) Automation Document to snapshot the volume for safety and then delete it.

🛠️ Step 1: The Lambda Automation Script (Python & Boto3)

Here is a snippet of the Lambda function used to detect and remove unattached EBS volumes. It checks for volumes that have been in an available (unattached) state for more than 7 days.

import boto3
from datetime import datetime, timedelta, timezone

def lambda_handler(event, context):
    ec2 = boto3.resource('ec2')
    client = boto3.client('ec2')

    # Threshold for idle resources (7 days)
    retention_days = 7
    cutoff_date = datetime.now(timezone.utc) - timedelta(days=retention_days)

    print("Scanning for unattached EBS volumes...")

    for volume in ec2.volumes.all():
        if volume.state == 'available':
            # Check how long the volume has been unattached/available
            if volume.create_time < cutoff_date:
                print(f"Found idle volume: {volume.id}. Creating final snapshot and deleting...")

                # Create snapshot for data safety
                client.create_snapshot(
                    VolumeId=volume.id,
                    Description=f"Automated pre-deletion snapshot for {volume.id}"
                )

                # Delete the volume
                volume.delete()
                print(f"Successfully deleted volume: {volume.id}")

💡 Lessons Learned from Production Deployments

Before rolling this out in your own environments, keep these two enterprise guardrails in mind:

The Opt-Out Tag: Always give your development teams a way to bypass automation. Implement a tag check (e.g., SkipCostAutomation = True) in your Lambda code so critical resources aren't deleted.
Dry-Run Mode First: When deploying this to production for the first time, configure your script to log the idle resources to Amazon CloudWatch or send a Slack alert via AWS Chatbot before actually executing the volume.delete() command.

🚀 What's Next?

Automating resource cleanup not only saves your organization money, but it also reduces your cloud attack surface by eliminating unmanaged infrastructure.

In my next post, I'll share the Terraform templates to deploy this entire infrastructure as code (IaC) across a multi-account AWS organization.

How does your team handle cloud cost optimization? Do you rely on manual checks, or have you automated your cleanup processes? Let's discuss in the comments below!

DEV Community: Dharm Pal

Architecting for Resiliency: Building a Multi-Region Disaster Recovery Setup on AWS

🏗️ The Multi-Region DR Architecture

🛠️ Step 1: Configuring Global Database Replication

🚦 Step 2: Intelligent Routing with Route 53 DNS Failover

💡 Crucial Operational Metrics: RTO vs. RPO

🚀 Conclusion

Infrastructure as Code: Deploying AWS Cost Optimization Engines with Terraform

📁 Project Directory Structure

🛠️ 1. Defining Variables (variables.tf)

🔒 2. Strict IAM Security Guardrails (iam.tf)

🏗️ 3. Main Automation & Scheduling Engine (main.tf)

💡 Production Architecture Best Practices

🚀 Conclusion

Automating Cloud Cost Optimization: How to Automatically Clean Up Idle AWS Resources

🏗️ The Automated Architecture

🛠️ Step 1: The Lambda Automation Script (Python & Boto3)

💡 Lessons Learned from Production Deployments

🚀 What's Next?

🛠️ 1. Defining Variables (`variables.tf`)

🔒 2. Strict IAM Security Guardrails (`iam.tf`)

🏗️ 3. Main Automation & Scheduling Engine (`main.tf`)