DEV Community: Khaing Zin

Automating MongoDB Auditlogs Cleanup & Restore Workflow with S3 Backup

Khaing Zin — Wed, 27 May 2026 09:24:00 +0000

Managing database growth is one of the most overlooked challenges in backend infrastructure. Everything works smoothly in the beginning, but over time collections like auditlogs grow rapidly. Every login attempt, API request, status change, and system activity gets stored continuousy.

Eventually, the database becomes larger, queries become slower, storage usage increases, and backups take longer to complete.

This is exactly the kind of operational issue many production systems face.

In the prod environment, the goal was simple:

Automatically clean old auditlogs
Keep a backup before deletion
Store backups safely in Amazon S3
Ensure the restore workflow works correctly
Automate the entire process with Cron

Instead of manually exporting logs and cleaning collections repeatedly, the process was converted into a fully automated backup and cleanup workflow using Bash scripting, MongoDB tools, AWS S3, and Cron Jobs.

This setup creates a safer and more production-ready maintenance process for MongoDB operations.

Why Auditlogs Need Special Handling

Audit logs are important because they provide traceability inside applications.

They help teams:

Track user activities
Monitor system events
Investigate incidents
Debug production issues
Maintain compliance records

However, auditlogs are also one of the fastest-growing collections in most systems.

Unlike business-critical collections such as users or transactions, auditlogs are usually append-only data. New records keep getting inserted, but older records are rarely accessed.

If these logs are never cleaned:

Database size grows continuously
Disk usage increases
Backup size becomes larger
Query performance may degrade
Infrastructure costs increase

This is why organizations commonly implement:

Log retention policies
Scheduled cleanup jobs
Backup archiving systems

In this workflow, Amazon S3 is used as long-term backup storage before deleting auditlogs from MongoDB.

Designing the Backup & Cleanup Workflow

The workflow was designed around one important principle:

Never delete data before creating a recoverable backup.

The process follows this sequence:

Dump the auditlogs collection
Compress the backup
Upload it to Amazon S3
Verify upload success
Delete auditlogs from MongoDB
Remove temporary local files

This ensures backups remain recoverable even after cleanup happens.

The automation runs safely on the mongodb-testing server before production rollout.

Creating an S3 Bucket for Auditlogs Backup

The first step is preparing an Amazon S3 bucket.

The bucket acts as centralized cloud storage for compressed MongoDB backups.

Example bucket:

s3://incoming-auditlogs-backup

Using S3 provides several advantages:

Durable backup storage
Low-cost archival
Easy recovery process
Secure cloud-based retention
Separation between production DB and backup storage

Instead of storing backups locally on the server, backups remain protected even if the EC2 instance fails.

Building the Bash Automation Script

The heart of the automation is a Bash script called:

/home/ubuntu/auditlogs-dump.sh

This script automates the complete lifecycle:

Backup
Compression
Upload
Cleanup

The script begins with several configuration variables.

MONGO_HOST="localhost"
MONGO_PORT="2707"
MONGO_DB="incoming"
MONGO_COLLECTION="auditlogs"

These variables define:

MongoDB host
Database name
Collection name

This makes the script reusable and easier to maintain later.

The S3 destination and backup naming logic are also configured:

S3_BUCKET="s3://incoming-auditlogs-backup"
BACKUP_NAME="auditlogs_backup_$(date +%F_%H-%M-%S)"

Using timestamps inside filenames is extremely important because:

Every backup becomes unique
Older backups are preserved
Restores become easier
Chronological tracking becomes possible

A generated backup name may look like:

auditlogs_backup_2025-08-19_02-00-01

This naming strategy is commonly used in production backup systems.

Dumping the MongoDB Collection

The first operational step inside the script is creating a MongoDB dump using mongodump.

mongodump \
  --host $MONGO_HOST \
  --port $MONGO_PORT \
  --db $MONGO_DB \
  --collection $MONGO_COLLECTION \
  --out $DUMP_PATH

mongodump exports the collection into BSON files that can later be restored using mongorestore.

Instead of backing up the entire database, only the auditlogs collection is exported.

This approach is efficient because:

Backup size remains smaller
Upload time becomes faster
Restore operations become simpler

This is especially useful for collections that grow aggressively.

Compressing the Backup

After the dump completes, the backup is compressed into a .tar.gz archive.

tar -czf "$DUMP_PATH.tar.gz" -C /tmp "$BACKUP_NAME"

Compression is important because:

Storage consumption decreases
Upload speed improves
Transfer bandwidth is reduced

In production systems where backups happen frequently, compression significantly reduces infrastructure costs over time.

Uploading Backup to Amazon S3

Once compressed, the backup is uploaded to Amazon S3 using AWS CLI.

aws s3 cp "$DUMP_PATH.tar.gz" "$S3_BUCKET/$BACKUP_NAME.tar.gz" --profile "$AWS_PROFILE"

This step creates an offsite backup copy before cleanup begins.

Using AWS CLI profiles is also a good operational practice because credentials remain separated and manageable.

Example:

aws configure --profile s3

This allows the script to securely authenticate with AWS without hardcoding access keys directly inside the script.

Cleaning the Auditlogs Collection

After the backup upload succeeds, the script cleans the MongoDB collection.

mongosh --host $MONGO_HOST --port $MONGO_PORT $MONGO_DB \
  --eval "db.getCollection('$MONGO_COLLECTION').deleteMany({})"

This removes all documents inside the auditlogs collection.

At this stage:

Backup already exists in S3
Data remains recoverable
Database size gets reduced

This creates a controlled cleanup workflow instead of dangerous direct deletion.

Removing Temporary Files

The final step removes temporary backup files from the local server.

rm -rf "$DUMP_PATH" "$DUMP_PATH.tar.gz"

This is extremely important because backup files can consume large amounts of disk space if left on the server continuously.

Cleanup helps:

Prevent storage exhaustion
Maintain server hygiene
Reduce operational risks

At the end, the script prints a success message confirming completion.

Making the Script Executable

Before execution, the script needs executable permission.

sudo chmod +x /home/ubuntu/auditlogs-dump.sh

Without this permission, Linux will not allow direct execution of the script.

Manual Testing Before Automation

Before scheduling automation, the script should always be tested manually.

/home/ubuntu/auditlogs-dump.sh

This validation step is important because it helps verify:

MongoDB dump works correctly
Compression succeeds
S3 upload succeeds
Collection cleanup works
Temporary files are removed

In production operations, testing automation manually before enabling Cron Jobs is a critical best practice.

Automating Cleanup with Cron

Once validated, the process can be scheduled using Cron.

The requirement here is:

Run every 2 days
Execute at 2:00 AM MMT

Cron configuration:

crontab -e

Add:

0 2 */2 * * /home/ubuntu/auditlogs-dump.sh

This transforms the process into a fully automated maintenance workflow.

Running during early morning hours minimizes production impact because traffic is usually lower.

Why Restore Testing Is Critical

Creating backups is only half the job.

The real question is:

Can the backup actually be restored successfully?

Many teams create backups regularly but never verify recovery workflows until a disaster happens.

This workflow includes a dedicated restore testing process on the mongodb-testing server.

This is an extremely important operational practice.

Restore Testing Workflow

The testing process begins by downloading the latest full database backup from S3.

aws s3 cp s3://incoming-mongodb-daily-backup/mongo_backup_2025-08-19_02-00-01.tar.gz /home/ubuntu/tmp/ --profile s3

The backup is then extracted:

tar -xzvf /home/ubuntu/tmp/mongo_backup_2025-08-19_02-00-01.tar.gz -C /home/ubuntu/tmp/

After extraction, the database is restored using mongorestore.

mongorestore --drop --db incoming /home/ubuntu/tmp/mongo_backup_2025-08-19_02-00-01/incoming

The --drop option ensures old collections are removed before restore begins.

This prevents duplicate or inconsistent data.

Verifying Data Restoration

After restore completes, verification is performed using:

mongosh incoming --eval "db.auditlogs.count()"

This confirms:

Data exists
Restore succeeded
Collection integrity remains intact

Verification steps like this are critical in real-world disaster recovery procedures.

Simulating Cleanup & Recovery

The workflow then intentionally deletes auditlogs:

mongosh incoming --eval "db.auditlogs.deleteMany({})"

This simulates a cleanup scenario.

Next, the latest auditlogs-only backup is restored from S3.

aws s3 cp s3://audit-bucket/auditlogs_backup_2025-08-19_02-00-01.tar.gz /home/ubuntu/tmp/ --profile s3

After extraction, the auditlogs collection is restored using:

mongorestore --drop --db incoming /home/ubuntu/tmp/auditlogs_backup_2025-08-19_02-00-01/incoming

This validates that:

Auditlogs backups are usable
Partial collection recovery works correctly
Data remains recoverable after cleanup
Cleaning the Testing Environment

Finally, the testing database is cleaned:

mongosh incoming --eval "db.dropDatabase()"

This ensures:

No leftover test data remains
Testing environments stay clean
Future restore tests remain isolated

Operational cleanliness is a small detail that becomes very important in long-running infrastructure environments.

Final Thoughts

This MongoDB auditlogs automation workflow demonstrates several important DevOps and infrastructure engineering concepts:

Backup automation
Cloud storage integration
Infrastructure scripting
Database maintenance
Disaster recovery testing
Operational safety
Scheduled automation with Cron

Instead of relying on manual database cleanup, the system now:

Creates recoverable backups automatically
Stores backups securely in S3
Cleans unnecessary auditlogs
Verifies restore capability safely

Building a Self-Healing and Scalable Infrastructure on AWS

Khaing Zin — Wed, 27 May 2026 08:48:29 +0000

When building applications in the cloud, one of the biggest challenges is handling unpredictable traffic. An application may work perfectly fine with a few users, but what happens when thousands of users suddenly visit at the same time?

This is a common real-world problem for startups, e-commerce websites, SaaS platforms, and modern web applications.

Imagine running a simple web application on AWS using only one EC2 instance. During normal days, everything works smoothly. Pages load fast, the server responds quickly, and users have a good experience.

But during a promotion campaign, viral social media post, or seasonal sale, traffic suddenly increases. The single EC2 instance starts receiving too many requests. CPU usage spikes, memory usage increases, response times become slower, and eventually the server may crash completely.

This is exactly where AWS Auto Scaling becomes powerful.

According to the uploaded slides, the purpose of Auto Scaling is to automatically create additional EC2 instances whenever system load increases and remove unnecessary instances when traffic decreases. This allows the system to remain stable even during sudden traffic spikes.

Why High Availability Matters

In modern cloud infrastructure, downtime is expensive.

If an application goes offline:

Customers cannot access services
Businesses lose revenue
User trust decreases
Performance becomes unreliable

High availability means designing systems that continue running even when failures happen.

Instead of depending on a single server, AWS encourages distributing workloads across multiple servers and multiple Availability Zones. This creates fault tolerance and improves reliability.

The architecture presented in the slides follows this exact principle.

Understanding the Architecture

The architecture starts with users sending requests to the application.

However, instead of directly connecting users to an EC2 instance, requests first go through an Application Load Balancer (ALB).

The Load Balancer acts like an intelligent traffic controller. Its responsibility is to:

Receive incoming requests
Check which servers are healthy
Distribute traffic evenly across EC2 instances

Behind the Load Balancer, EC2 instances are managed by an Auto Scaling Group (ASG).

The Auto Scaling Group continuously monitors system demand. If traffic increases, new EC2 instances are launched automatically. If traffic decreases, unnecessary instances are terminated to save cost.

This creates an infrastructure that can dynamically adapt to changing workloads without requiring manual intervention.

What makes this architecture powerful is its ability to remain operational even when failures occur. If one instance becomes unhealthy, traffic is redirected to healthy servers automatically.

This is one of the core ideas behind cloud-native infrastructure design.

Implementation

The entire setup process can be divided into several stages:

Creating a Launch Template
Configuring User Data
Creating a Target Group
Creating an Application Load Balancer
Configuring Auto Scaling Group
Testing the Infrastructure

Let’s explore each step in detail.

Step 1 — Creating a Launch Template

The first step is creating a Launch Template.

A Launch Template works like a reusable blueprint for EC2 instances. Instead of manually configuring every new server, AWS uses the template whenever Auto Scaling launches a new instance.

The template defines:

Which AMI to use
Instance type
Security Groups
Storage settings
Startup scripts

Amazon Linux 2023 is selected
t2.micro is used as the instance type
HTTP traffic on port 80 is allowed through the Security Group

Allowing port 80 is important because the application will serve web traffic using Nginx.

This approach introduces one of the biggest advantages of cloud infrastructure: standardization.

Every EC2 instance launched from the template will have the exact same configuration, reducing human error and making infrastructure predictable.

Automating Server Setup with User Data

One of the most interesting parts of the implementation is the use of User Data.

User Data allows developers to automatically execute scripts whenever a new EC2 instance launches.

This means:

Every new instance automatically becomes a working web server
No manual configuration is required
Scaling becomes fully automated

This is a fundamental DevOps concept called Infrastructure Automation.

Instead of manually logging into servers and configuring them one by one, infrastructure becomes programmable and repeatable.

In real-world production environments, User Data scripts are often used to:

Install application dependencies
Pull application code
Configure monitoring tools
Start Docker containers
Connect servers to databases

Automation like this significantly reduces operational overhead.

Creating the Target Group

After the Launch Template is ready, the next step is creating a Target Group.

A Target Group defines where the Load Balancer should forward traffic.

When users access the application:

Requests arrive at the Load Balancer
The Load Balancer checks healthy targets
Traffic is distributed to healthy EC2 instances

This creates intelligent traffic routing inside the infrastructure.

Without a Target Group, the Load Balancer would not know where to send incoming requests.

Building the Load Balancer

Next comes the Application Load Balancer (ALB).

The ALB acts as the public entry point for the application.

During setup:

The default VPC is selected
Multiple subnets are configured
HTTP listener on port 80 is attached

One of the most important concepts introduced here is the Multi-AZ setup.

AWS regions contain multiple Availability Zones (AZs), which are physically separate data centers.

If one Availability Zone experiences failure:

The application continues running from other zones
Downtime is minimized
Infrastructure becomes fault tolerant

This is a key principle behind designing resilient cloud systems.

Instead of placing everything inside one server or one data center, workloads are distributed across multiple zones.

Configuring the Auto Scaling Group

Once the Load Balancer is ready, the Auto Scaling Group can be configured.

In the slides:

Minimum capacity is set to 1
Desired capacity is set to 1
Maximum capacity is set to 2

This means:

At least one instance will always remain active
The infrastructure initially starts with one server
AWS can automatically create another instance if demand increases

The Auto Scaling Group continuously monitors metrics such as:

CPU utilization
Network traffic
Request count

When thresholds are exceeded, scaling policies automatically launch additional EC2 instances.

This allows the infrastructure to grow dynamically depending on workload.

Self-Healing Infrastructure with Health Checks

Another critical feature highlighted in the slides is Health Checks.

The Load Balancer continuously checks whether instances are healthy.

If an instance fails:

Traffic is no longer routed to it
The Auto Scaling Group detects the unhealthy state
A replacement instance is launched automatically

This creates a self-healing system.

One of the biggest advantages of cloud computing is that infrastructure can recover automatically without human intervention.

In traditional infrastructure environments, engineers often had to manually replace failed servers. Cloud-native systems automate this entire process.

Testing the Infrastructure

After completing the setup, the Load Balancer provides a DNS endpoint.

Opening the DNS address in a browser displays the default Nginx page, confirming that the web server is running successfully.

The most interesting part comes during load testing.

When traffic increases:

CPU utilization rises
Auto Scaling policies trigger
New EC2 instances launch automatically
Traffic gets distributed across multiple servers

This demonstrates the true power of Auto Scaling.

The infrastructure automatically adapts to workload changes in real time.

Real-World Impact of Auto Scaling
**

Auto Scaling is used everywhere in modern cloud systems.

E-Commerce Platforms

Traffic spikes heavily during flash sales and seasonal promotions.

Streaming Services

User activity fluctuates depending on time and trending content.

Gaming Platforms

Player traffic can suddenly increase during events or updates.

SaaS Applications

Businesses require consistent uptime and performance for customers worldwide.

Without scalable infrastructure, these platforms would struggle during high traffic periods.

Final Thoughts

This implementation demonstrates one of the most important concepts in cloud computing: building scalable and resilient infrastructure.

By combining:

EC2
Application Load Balancer
Auto Scaling Group
Multi-AZ deployment

AWS enables applications to automatically adapt to changing workloads while maintaining high availability.

Instead of manually managing servers, engineers can focus on building reliable systems that scale automatically.

For anyone learning Cloud Computing, DevOps, or Solution Architecture, understanding Auto Scaling is an essential foundational skill because modern applications are expected to remain fast, available, and reliable regardless of traffic conditions.