Forem: Divesh Kumar

How I Slashed My AWS Bill to $0 While Securing a 46GB Backup (In 1 Command) 🚀

Divesh Kumar — Mon, 11 May 2026 05:11:58 +0000

Managing cloud infrastructure often feels like a balancing act between utility and cost. Recently, I faced a challenge: I needed to perform a total shutdown of an AWS account while ensuring a 46GB infrastructure backup was perfectly preserved.

Doing this manually via the AWS Console is a recipe for missed resources and lingering costs. Instead, I chose the path of automation. This article breaks down how I transformed a complex multi-service environment into a "single-enter" terminal operation.

🔍 Phase 1: The Automated Audit

Before you can back up, you have to know what you have. A simple look at the EC2 dashboard isn't enough.

I used scripts to crawl the account, mapping every dependency. One crucial trick was inspecting Lambda environment variables. Often, these variables contain hidden RDS connection strings, MongoDB URIs, or API keys that aren't immediately visible in the service-specific dashboards.

Mapping these "hidden" connections ensured that I didn't just back up the code, but also identified every data source that needed extraction.

📦 Phase 2: Surgical Extraction

Once the map was ready, the terminal took over. Here’s the breakdown of the core commands used for each service:

1. S3 Sync

For high-performance file retrieval, aws s3 sync is the gold standard. It only copies new or changed files, making it efficient for large buckets.

aws s3 sync s3://my-bucket-name ./backup/s3/my-bucket-name

2. Lambda Downloads

Retrieving Lambda code isn't as direct as S3. You first get a temporary signed URL, which you then use to download the ZIP file.

# Get the function details
aws lambda get-function --function-name MyFunction

Note: Look for the Code.Location URL in the JSON response—that's your download key!

3. RDS SQL Dumps

For local portability and ease of restoration, I bypassed snapshots and went straight for raw .sql files using pg_dump (for PostgreSQL) or mysqldump.

pg_dump -h [endpoint] -U [user] -d [dbname] -f backup.sql

4. DynamoDB JSON Export

For NoSQL data, I used full table scans to export everything into portable JSON format.

aws dynamodb scan --table-name MyTable --output json > MyTable.json

🧹 Phase 3: The "Zero Bill" Cleanup

The most satisfying part? Watching the cost counter stop. Once the 46GB backup was verified locally, I ran a cleanup script to target the "silent cost killers":

EC2 Instances: aws ec2 terminate-instances --instance-ids i-12345...
Load Balancers: aws elbv2 delete-load-balancer --load-balancer-arn ...
Elastic IPs: Often overlooked! Releasing them is vital to avoid hourly idle charges.
```
aws ec2 release-address --allocation-id eipalloc-...
```
RDS Instances: Deleted after verifying the local SQL dumps were 100% intact. I skipped the final snapshot to ensure zero remaining storage costs.
```
aws rds delete-db-instance --db-instance-identifier my-db --skip-final-snapshot
```

☁️ Phase 4: Final Cloud Redundancy

A backup isn't a backup until it's in at least two places. I synced the entire local backup/ folder to Google Drive using rclone. This provided geo-redundancy and peace of mind, knowing the data was safe outside of the AWS ecosystem.

💡 The Takeaway

The result was a comprehensive, documented backup and a clean AWS bill.

Modern DevOps is about building scripts that handle the manual heavy lifting. By automating the research, extraction, and cleanup, you minimize human error and ensure that "turning off the lights" doesn't leave any expensive bulbs burning in the background.

How do you handle your infrastructure decommissioning? Let's discuss in the comments!

aws #devops #automation #cloudcomputing #backup

🔔 Django Signals: Supercharging Your App with Event-Driven Architecture

Divesh Kumar — Thu, 04 Sep 2025 04:49:16 +0000

When building a Django application, you often need to perform actions whenever something specific happens — for example, sending a welcome email after a user registers.

Instead of writing extra logic inside your views or models, Django gives us a powerful feature: Signals.

In this post, we’ll break down what signals are, why you need them, and a real-world example with code.

🚀 What are Django Signals?

Django Signals allow decoupled applications to get notified when certain actions occur.

Think of them like a notification system inside Django.
• Event happens → Signal is fired
• Listener catches it → Executes extra logic

Examples:
• A user logs in → Update last login timestamp
• A new order is created → Send invoice email
• A profile is saved → Resize uploaded avatar

🛠️ Common Built-in Signals

Django comes with some built-in signals:
• pre_save / post_save → before/after saving a model
• pre_delete / post_delete → before/after deleting a model
• m2m_changed → when a ManyToMany relation is updated
• request_started / request_finished → when a request starts/ends
• user_logged_in / user_logged_out → authentication-related signals

You can also create custom signals.

🧑‍💻 Example: Auto-Creating a Profile When a User Registers

Instead of writing profile creation logic inside the signup view, let’s use signals.

Step 1: Create a Profile model

# app/models.py
from django.db import models
from django.contrib.auth.models import User

class Profile(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    bio = models.TextField(blank=True)
    created_at = models.DateTimeField(auto_now_add=True)

    def __str__(self):
        return f"{self.user.username}'s profile"

Step 2: Write a Signal Receiver

# app/signals.py
from django.db.models.signals import post_save
from django.dispatch import receiver
from django.contrib.auth.models import User
from .models import Profile

@receiver(post_save, sender=User)
def create_user_profile(sender, instance, created, **kwargs):
    if created:
        Profile.objects.create(user=instance)

Here’s what happens:
• When a new User is created → post_save signal is fired.
• Our create_user_profile function catches it.
• A Profile is automatically created for the new user.

Step 3: Connect the Signal in apps.py

# app/apps.py
from django.apps import AppConfig

class AppConfig(AppConfig):
    default_auto_field = 'django.db.models.BigAutoField'
    name = 'app'

    def ready(self):
        import app.signals

Now, whenever a new user registers, Django automatically creates a profile without extra code in the view.

⚡ Why Use Signals?
✅ Keeps code clean & decoupled
✅ Avoids duplicate logic across views
✅ Makes your app event-driven

⚠️ When NOT to Use Signals?
• When the logic is very specific to one place (better to keep it in the view).
• When debugging complex chains (signals can make code harder to trace).
• If overused → can create “hidden logic” that’s difficult for teams to maintain.

🎯 Final Thoughts
Django Signals are a game-changer for clean and modular code. Use them wisely to automate side-effects like profile creation, notifications, and logging.

👉 If you found this helpful, drop a ❤️ or share your thoughts in the comments.