DEV Community: Rajeev

I Accidentally Deleted Our Production S3 Bucket — Here's What Happened in the Next 4 Hours

Rajeev — Mon, 31 Aug 2026 11:37:39 +0000

I Accidentally Deleted Our Production S3 Bucket — Here's What Happened in the Next 4 Hours

The command ran in under a second. The recovery took 4 hours. Here's the full story, what we lost, what we saved, and what we now have in place so it can never happen again.

There's a moment every cloud engineer dreads.

The cursor blinks. The command runs. And then a silence that feels different from normal silence.

aws s3 rb s3://my-app-production-uploads --force

I was targeting the staging bucket. I was in the wrong terminal window.

In under a second, 3 years of user-uploaded files — profile pictures, documents, exported reports — were gone.

This is what happened next.

The First 60 Seconds

The first thing you do when something goes catastrophically wrong is nothing.

Not because you're calm. Because your brain genuinely cannot process what just happened. I stared at the terminal output for probably 10 seconds before the word production registered.

Then I checked the AWS console. The bucket was gone. Not empty — gone. No objects, no metadata, no bucket at all. S3 bucket deletion removes the bucket itself, not just the contents.

I looked at the clock: 11:47 PM.

I typed one message in Slack: "I need help. Production S3 bucket just got deleted. Staging terminal wrong window."

Three people came online within 2 minutes. That response time, at midnight, is what actually saved us.

What Was in the Bucket

Before I explain the recovery, you need to understand what we lost — or thought we lost:

User profile pictures — every account photo uploaded since launch
Document uploads — files users had submitted through the app
Exported reports — generated PDFs that users could re-download
Some application assets — a handful of static files referenced in the app

The user-facing impact was immediate. Profile pictures showed broken image icons. Document download links returned 403. The export feature threw errors.

It was 11:47 PM on a Tuesday. Low traffic. That was the only lucky part.

The Recovery Attempt — Hour 1

The first thing we checked: S3 Versioning.

S3 Versioning, when enabled, keeps every version of every object including delete markers. When you delete an object with versioning on, S3 adds a delete marker rather than actually removing the data. The object is "deleted" but recoverable.

We had versioning enabled on the production bucket.

The problem: deleting the bucket itself with --force does something different. It first deletes all objects and versions, then deletes the bucket. By the time the bucket is gone, the versioned objects are gone too.

Versioning alone didn't save us. But it was a clue that we were thinking about this correctly — we just needed another layer.

Then someone asked the question that changed the next 3 hours:

"Do we have Cross-Region Replication set up?"

The Recovery — Hour 2

We did have Cross-Region Replication (CRR) configured. Set up 8 months earlier as a compliance requirement, never actually tested, mostly forgotten about.

CRR continuously replicates objects from a source bucket to a destination bucket in another region. It runs automatically, in the background, silently.

We checked the destination bucket.

It was there. All of it. Every object, replicated.

Source bucket (deleted):      0 objects
Destination bucket (intact):  47,832 objects ✅

47,832 files. All of them. The replication had been running every time someone uploaded anything, for 8 months, without us ever consciously thinking about it.

The recovery process:

Create a new source bucket with the same name in the original region
Copy all objects from the replica bucket back to the new source bucket
Update bucket policies, CORS configuration, and lifecycle rules to match original
Re-enable CRR on the new bucket pointing to the replica
Verify application could read all files

# Copy everything from replica back to new source bucket
aws s3 sync \
  s3://my-app-production-uploads-replica \
  s3://my-app-production-uploads \
  --source-region us-west-2 \
  --region ap-south-1

The sync took 47 minutes for 47,832 files.

At 2:34 AM — 2 hours and 47 minutes after the deletion — every broken image was loading again. Every download link worked. Every export was accessible.

Total permanent data loss: zero.

What We Lost That We Couldn't Recover

Not everything was perfect.

The bucket policy was gone. We had to reconstruct it from memory and the IAM policy attached to our application role. Close enough, but not exact — there were edge case permissions we discovered were missing over the following week when specific features started throwing permission errors.

The lifecycle rules were gone. We had automated deletion of files older than 365 days for GDPR compliance. Those rules had to be manually recreated. We found them eventually in a Terraform file that was slightly out of date.

The CORS configuration took three attempts to get right. We had it in a config file but the file wasn't fully updated — there were two origin entries we'd added manually and never committed.

Lesson: the bucket itself is infrastructure. Treat it like infrastructure. Version-control every policy, every lifecycle rule, every CORS config.

The 4 Layers We Now Have in Place

Layer 1 — S3 Versioning (Was Already On)

Versioning doesn't protect against bucket deletion with --force but it protects against accidental object deletion and overwrites. Keep it on. Always.

Layer 2 — Cross-Region Replication (Was Already On, Saved Us)

CRR was our actual recovery mechanism. The lesson: don't set it up and forget it. Test it. We had never run a recovery drill. We got lucky that it was working correctly when we needed it.

Test your replication quarterly:

Delete a test object from source
Verify it still exists in replica
Restore it
Confirm restoration worked

Layer 3 — S3 Object Lock (Added After)

S3 Object Lock in Compliance mode prevents objects from being deleted by anyone — including root account users — for a defined retention period.

For our document uploads that have legal retention requirements, we now use Object Lock with a 90-day retention window. Even aws s3 rb --force cannot delete locked objects.

Layer 4 — IAM Boundary on Deployment Credentials (Added After)

The access key I was using had full S3 permissions. It didn't need them. Our deployment pipeline only needs PutObject and GetObject on specific buckets.

We added a permission boundary that explicitly denies s3:DeleteBucket and s3:DeleteObject on production buckets for all non-root credentials.

{
  "Effect": "Deny",
  "Action": [
    "s3:DeleteBucket",
    "s3:DeleteObject",
    "s3:DeleteObjectVersion"
  ],
  "Resource": [
    "arn:aws:s3:::my-app-production-*",
    "arn:aws:s3:::my-app-production-*/*"
  ]
}

This policy means even if someone runs aws s3 rb --force on a production bucket, the API call returns AccessDenied. The bucket stays.

The Conversation We Had to Have

At 3 AM, with everything recovered and the immediate crisis over, the four of us stayed on the call for another 30 minutes.

Not to assign blame. Not to write a post-mortem. Just to talk through what had actually happened and what it meant.

The thing nobody said but everyone was thinking: we got lucky.

Lucky that CRR was set up. Lucky that it had been running correctly for 8 months without us verifying it. Lucky that traffic was low. Lucky that three people responded at midnight.

A production incident that resolves with zero data loss still costs something. It costs 4 hours of sleep, a spike of cortisol that doesn't fully fade for days, and a team that now moves a little more carefully around production resources than they did before.

That carefulness is worth more than any technical safeguard.

What Actually Protects Your S3 Data

Not one thing. All of these, in layers:

Layer 1 — Versioning
  Protects against: accidental object deletion, overwrites
  Does NOT protect: bucket deletion with --force

Layer 2 — Cross-Region Replication  
  Protects against: bucket deletion, regional failure
  Requirement: test it before you need it

Layer 3 — S3 Object Lock
  Protects against: everything, including root account
  Best for: compliance data, legal holds, critical assets

Layer 4 — IAM Deny on DeleteBucket/DeleteObject
  Protects against: credential misuse, wrong terminal window
  Best practice: least privilege on all non-root credentials

Layer 5 — AWS Backup for S3
  Protects against: all of the above
  Adds: point-in-time recovery, automated backup schedules

You don't need all five on every bucket. But you need to know which layers you have, verify they work, and match protection level to data criticality.

The Checklist I Wish I Had Before That Night

Before every AWS CLI session:
☐ Check which terminal window is active
☐ Check which AWS profile is set (aws sts get-caller-identity)
☐ Double-check the resource name before any destructive command

For every production S3 bucket:
☐ Versioning: enabled
☐ Cross-Region Replication: enabled and tested
☐ MFA Delete: enabled for critical buckets
☐ IAM Deny policy: DeleteBucket + DeleteObject on prod buckets
☐ Bucket policy + lifecycle rules: version-controlled in git

Recovery drills (quarterly):
☐ Delete a test object, verify replica has it, restore it
☐ Confirm CORS, bucket policy, lifecycle rules are in source control
☐ Know the exact sync command to run if you need it at 2am

One Last Thing

Before you close this tab — run this:

aws sts get-caller-identity

Check which account you're in right now.

If the answer is your production account and you don't need to be there, switch profiles before you do anything else.

That command takes 2 seconds. The recovery takes 4 hours.

Have a recovery story of your own? Drop it in the comments. The more of these we share, the less likely someone else has to learn the same lesson at midnight.

Tags: #AWS #S3 #DevOps #Cloud #DataRecovery #Lessons #Backend #Infrastructure

Our ECS Fargate Task Was Silently Failing for Days — Here's Exactly How We Found It

Rajeev — Wed, 26 Aug 2026 15:07:51 +0000

Our ECS Fargate Task Was Silently Failing for Days — Here's Exactly How We Found It

No alarm fired. No Slack alert. No PagerDuty page. Just a service quietly burning compute while cycling through thousands of failed tasks. Here's the full story.

It started with a routine check.

I opened the ECS console to verify a deployment and noticed something wrong in the numbers. The running task count was 0. The desired count was 1. And the service had been in that state for longer than I wanted to admit.

No notification. No alert. No one on the team had noticed.

The task was starting, failing its health check, getting killed by ECS, and restarting — on a 60-second loop. Silently. Automatically. Expensively.

This is the story of how we found it, what caused it, and the three things we now have in place so it never goes undetected again.

What Was Happening

ECS Fargate has a deceptively simple failure loop:

Task starts
    ↓
Health check runs
    ↓
Health check fails
    ↓
ECS kills the task
    ↓
ECS starts a new task (desired count not met)
    ↓
Repeat indefinitely

From the outside, your service looks like it's "working" — ECS is doing exactly what it's designed to do, trying to maintain your desired count. From the inside, your application is never actually serving traffic. And unless you're watching the right metrics, you won't know.

The console shows this:

Service: my-backend
Desired: 1 | Running: 0 | Pending: 1

Recent events:
  service my-backend has started 1 tasks
  service my-backend: task failed health check, will be stopped
  service my-backend has started 1 tasks
  service my-backend: task failed health check, will be stopped
  ...

Every 60 seconds. Over and over.

The Root Cause

Our health check was configured to hit /api/health.

The container was serving the application — but on a different path after a recent refactor. The endpoint had moved. The health check hadn't been updated.

Health check expected:  GET /api/health  → 200 OK
Container was serving:  GET /health      → 200 OK
                        GET /api/health  → 404

One forgotten update. That's it.

ECS saw a 404 on every health check. Interpreted it as unhealthy. Killed the task. Started a new one. Repeat.

The application code was perfect. The deployment was clean. The task definition was correct. The only problem was a single path string in the health check configuration.

How We Found It

Three signals that told us something was wrong — none of them were the alarm we should have had:

Signal 1 — ECS console service events
The events tab in the ECS service console shows every task start and stop. When a service is stuck in a failure loop, this list fills up fast. A healthy service might have 5-10 events. Ours had hundreds.

Signal 2 — CloudWatch metric: RunningTaskCount
This metric drops to 0 when all tasks fail. If you graph it, you see a flat line at 0 instead of the expected flat line at 1. We weren't graphing it. We should have been.

Signal 3 — CloudWatch logs — or the absence of them
Application logs stop when the task dies. If your log stream has a gap or just stops entirely, the task isn't running. Check the timestamp on the last log line.

None of these required any special setup. They were all there, visible, waiting. We just weren't watching.

The Fix — 3 Layers We Now Have in Place

Layer 1 — Health Check Path Validation

Before every deployment we now verify health check path matches the actual endpoint:

Application route:   /health        ✅
Health check path:   /health        ✅ match — good to deploy

Application route:   /health        ✅  
Health check path:   /api/health    ❌ mismatch — fix before deploy

Simple manual check. Takes 30 seconds. Would have prevented the entire incident.

Layer 2 — CloudWatch Alarm on RunningTaskCount

The metric RunningTaskCount dropping below your desired count for more than 5 minutes means something is wrong. This alarm now fires to Slack the moment it happens:

Metric:     ECS/RunningTaskCount
Condition:  < 1 for 5 consecutive minutes
Action:     SNS → Slack notification

We missed days of failure because this didn't exist. It takes about 10 minutes to set up.

Layer 3 — ECS Service Events in CloudWatch

ECS service events can be streamed to CloudWatch Logs via EventBridge. Once there, you can search them, alert on patterns, and see the full history without opening the console.

The event pattern to watch for:

{
  "source": ["aws.ecs"],
  "detail-type": ["ECS Service Action"],
  "detail": {
    "eventType": ["WARN", "ERROR"]
  }
}

Any WARN or ERROR from ECS service events goes straight to a log group. From there a metric filter and alarm handles the rest.

What the Fixed Architecture Looks Like

ECS Task starts
    ↓
Health check: GET /health → 200 OK ✅
    ↓
Task marked healthy
    ↓
Traffic routed to task

        +-- CloudWatch Alarm watching RunningTaskCount
        |   fires if task count < desired for 5 mins
        |
        +-- EventBridge capturing ECS WARN/ERROR events
        |   streams to CloudWatch Logs
        |
        +-- Slack notification on any alarm state

Three independent detection layers. Any one of them would have caught the original failure within minutes.

The Cost of Not Watching

Every failed task in ECS Fargate still consumes compute during its startup window. If your task takes 60 seconds to start before failing the health check, and it restarts every 60 seconds:

Fargate 0.25 vCPU + 0.5GB = ~$0.015/hour
Constant restart loop = full billing, zero useful work

Over 3 days undetected:  3 × 24 × $0.015 = $1.08 wasted

Not a huge number — but that's a small task. Scale this to larger Fargate tasks or multiple services and it adds up fast. More importantly, your application was completely down the entire time.

Lessons Learned

1. ECS will not tell you when it's failing — by design.
ECS is doing its job: trying to maintain desired count. It has no concept of "this has been broken for too long." That judgement is yours to implement.

2. Health check path is a contract.
Change your application routes, update your health check. Always. Make it part of your PR checklist.

3. RunningTaskCount alarm is non-optional.
If you run ECS Fargate and don't have this alarm, you are flying blind. It takes 10 minutes to set up and covers an entire class of silent failures.

4. Log gaps are signals.
If your application log stream suddenly stops, the task stopped. The absence of logs is as important as the presence of errors.

5. Silent failures are more dangerous than loud ones.
A crashing application that sends an alert is manageable. An application that silently fails for days while appearing to run is much harder to deal with — because by the time you find it, the damage is done.

Quick Checklist Before Your Next ECS Deployment

Before deploying:
☐ Health check path matches current application route
☐ Health check interval and threshold are reasonable
☐ Container port matches task definition port mapping

After deploying:
☐ RunningTaskCount reaches desired count within 5 minutes
☐ Application logs are appearing in CloudWatch
☐ Health check is returning 200 in the target group

Monitoring (set up once, never remove):
☐ CloudWatch alarm: RunningTaskCount < desired for 5 mins
☐ EventBridge rule: ECS service WARN/ERROR events to CloudWatch
☐ Slack/SNS notification on alarm state change

Final Thought

The most expensive outages are the ones nobody notices.

A loud failure — exception thrown, service returns 500, alarm fires — gets fixed fast. A silent failure — task cycling, health check failing, no traffic getting through — can run for days before anyone looks at the right dashboard.

ECS is excellent infrastructure. But it will not babysit your application for you. The monitoring layer is yours to own.

Set up the RunningTaskCount alarm today. It takes 10 minutes. Future you will be grateful.

Running ECS Fargate? What monitoring do you have in place for silent failures? Drop it in the comments — curious what patterns people are using.

Tags: #AWS #ECS #Fargate #DevOps #CloudWatch #Monitoring #Backend #SRE

How We Cut AWS Staging Costs by 87% With EventBridge Scheduler (Zero Code Changes)

Rajeev — Mon, 24 Aug 2026 15:17:47 +0000

How We Cut AWS Staging Costs by 87% With EventBridge Scheduler

No code changes. No Lambda functions. No complex scripts. Just 4 schedulers and a realization that nobody uses staging at 3am.

Here's a question every engineering team should ask themselves:

"When was the last time someone actually used our staging environment at 2am?"

For us? Never. Not once.

Yet we were paying for it — EC2 running, ECS Fargate tasks spinning, compute burning money — every single hour of every single day, including weekends, holidays, and the 21 hours per day when nobody on our team was even awake.

That's the hidden tax of staging environments. And most teams never fix it because the solution feels complicated.

It isn't.

This is how we cut our staging compute costs by 87.5% — using AWS EventBridge Scheduler, zero Lambda functions, and zero lines of application code.

The Problem: Staging Was Running 24/7 For No Reason

Our staging environment had two resources running around the clock:

EC2 instance — our staging app server
ECS Fargate service — our backend API container

Our team actively uses staging for roughly 3 hours a day. That's it.

The math was embarrassing:

Running:    24 hours/day
Used:        3 hours/day
Wasted:     21 hours/day = 87.5% of compute going nowhere

Monthly cost breakdown:

EC2 + ECS Fargate (24x7):   ~$19.18/month
EC2 + ECS Fargate (3hr/day): ~$2.40/month

Monthly saving:  $16.78
Yearly saving:   $201.35
Reduction:       87.5%

$201/year saved on staging compute alone — with 45 minutes of setup and zero application code changes.

Multiply that across dev environments, QA clusters, review apps, and load test environments. The savings compound fast.

The Solution: AWS EventBridge Scheduler

Most engineers reach for Lambda when they need to automate AWS tasks on a schedule. That works — but it means writing code, managing runtimes, setting up CloudWatch Logs, and maintaining a function forever.

EventBridge Scheduler is the better tool here. It lets you call any AWS SDK action directly on a cron schedule — no Lambda, no code, no runtime to maintain.

The mental model is simple:

WHEN  →  cron expression (with native timezone support)
WHAT  →  any AWS API call (StartInstances, UpdateService, StopDBInstance...)
WHO   →  a dedicated IAM role with just enough permissions

That's the entire service. And it's free for the first 14 million invocations per month.

What We Built: 4 Schedulers

We created 4 EventBridge Schedulers targeting our staging resources:

Scheduler	Fires At	Action
`staging-ec2-start`	9:00 PM IST daily	Start staging EC2 instance
`staging-ec2-stop`	12:00 AM IST daily	Stop staging EC2 instance
`staging-ecs-scale-up`	9:00 PM IST daily	ECS service desiredCount to 1
`staging-ecs-scale-down`	12:00 AM IST daily	ECS service desiredCount to 0

Result:

Timeline (IST):
─────────────────────────────────────────────────────
12:00 AM  |████████████ OFF (21 hrs) ████████████| 9:00 PM
                                                  │
                                               9:00 PM
                                          ┌──────────────┐
                                          │ EC2 starts   │
                                          │ ECS → 1 task │
                                          └──────┬───────┘
                                                 │
                                          ┌──────▼───────┐
                                          │  RUNNING     │
                                          │  (3 hours)   │
                                          └──────┬───────┘
                                                 │
                                           12:00 AM
                                          ┌──────────────┐
                                          │ EC2 stops    │
                                          │ ECS → 0 tasks│
                                          └──────────────┘

Staging wakes up exactly when the team needs it. Goes dark at midnight. Every day. Automatically.

The Architecture

AWS EventBridge Scheduler
│
├── staging-ec2-start    ──► 9 PM IST  ──► ec2:StartInstances
├── staging-ec2-stop     ──► 12 AM IST ──► ec2:StopInstances
├── staging-ecs-scale-up ──► 9 PM IST  ──► ecs:UpdateService (count=1)
└── staging-ecs-scale-down──► 12 AM IST ──► ecs:UpdateService (count=0)
         │
         └── All using: staging-scheduler-role (least privilege IAM)

One dedicated IAM role. Four schedulers. Zero Lambda functions.

EventBridge Scheduler vs Lambda + Cron

	Lambda + EventBridge Rule	EventBridge Scheduler
Code to write	~30 lines per action	Zero
Runtime maintenance	Lambda versions, updates	None
Timezone handling	Manual UTC math	Built-in
Retry on failure	Manual implementation	Built-in
Setup time	20-30 mins per action	5 mins per action
Debugging	CloudWatch Logs setup	Native console

For simple time-based AWS automation, EventBridge Scheduler removes an entire layer of complexity.

Key Things to Know Before You Implement

The IAM role is the foundation — and where most people get stuck.

EventBridge Scheduler needs a role with the correct trust principal. There's a very common mistake here — getting this one thing wrong means your schedulers silently do nothing. Scope the role permissions to specific resource ARNs only. A staging scheduler role should be physically incapable of touching production.

Cron expressions use UTC by default.

Set the timezone parameter to your team's actual timezone. Forgetting this means your staging shuts down at the wrong time and your team spends 20 minutes debugging before realizing it's a UTC offset issue.

desiredCount: 0 is not the same as deleting the ECS service.

Setting desired count to zero stops all running tasks but preserves the full service definition, task definition, and all configuration. Scale back up to 1 and everything restarts exactly as before — same image, same env vars, same everything.

stopInstances is not terminateInstances.

Stopping preserves the EBS volume and all data. Terminating destroys it permanently. Our schedulers stop — never terminate.

Account for application warm-up time.

EC2 boot + ECS task startup + application initialization can take 3-5 minutes total. Schedule your start 10-15 minutes before your team actually needs it. We start at 8:45 PM for a 9 PM working session.

What Else Can You Schedule?

Once you understand this pattern, every always-on non-production resource is a candidate:

RDS instances — stop during nights, save $15-50/month per instance
DocumentDB clusters — same pattern, significant savings
Auto Scaling Groups — scale to minimum overnight
Additional ECS services — any non-prod service
ElastiCache — stop non-prod caches at night

Every resource running at 3am that nobody needs is costing you money right now.

The Results

BEFORE:  $19.18/month  (24x7 always on)
AFTER:    $2.40/month  (3hrs/day scheduled)

Saving:  $16.78/month
         $201.35/year
         87.5% reduction

Zero code changes. Zero Lambda functions. Zero new infrastructure.

Four schedulers calling two AWS APIs on a cron. That's it.

Lessons Learned

1. Analyze your actual usage before setting the schedule.
We assumed our team used staging 9 AM to 6 PM. The access logs showed 9 PM to midnight. Data beats assumptions every single time. Check your logs first.

2. EventBridge Scheduler and EventBridge Rules are completely different services.
Scheduler is time-driven. Rules are event-driven. The IAM trust principal, console location, and configuration format are all different. If you Google EventBridge automation and follow a tutorial, make sure it's for Scheduler — not Rules.

3. Separate schedulers per resource type.
EC2 and ECS need different API targets. Keep them as separate schedulers — cleaner, easier to debug, independently adjustable.

4. Weekend-only shutdown pushes savings higher.
If your team doesn't use staging on weekends, a single cron parameter change takes savings from 87.5% to ~94%. Worth knowing.

5. Always have a manual override plan.
Sometimes you need staging at 2am — production incident, urgent hotfix, client demo. Know how to start resources manually in 30 seconds without waiting for the next scheduled start.

Non-Production Cost Checklist

Today:
☐ Identify all always-on non-production EC2 instances
☐ Identify all always-on non-production ECS services
☐ Calculate actual usage hours vs paid running hours

This week:
☐ Set up EventBridge Schedulers for staging resources
☐ Stop non-prod RDS during off-hours
☐ Remove unused Elastic IPs (charged even when unattached)

Next sprint:
☐ Right-size non-prod instances based on actual usage
☐ Audit unused snapshots, AMIs, old EBS volumes
☐ Check for idle NAT Gateways (~$32/month each, easy to forget)

The Bigger Picture

This isn't really about the $201.

It's about the habit.

Every always-on non-production resource is a signal that your team treats cloud infrastructure like physical servers — provision once, leave forever. That habit is slightly expensive at small scale. At growth scale, it becomes a serious line item that nobody owns.

EventBridge Scheduler is the simplest tool to break that habit. Set it up once, forget it, and let AWS enforce the discipline automatically every single night.

Applied across all your non-production environments, teams typically see 40-70% reduction in total non-production AWS spend.

The cost of doing this: 45 minutes.
The cost of not doing this: compounding waste, every month, forever.

Implementing something similar or have a different approach? Drop it in the comments — I read everything.

If this saved you money, share it with someone still paying for an always-on staging environment.

Tags: #AWS #DevOps #CloudCost #ECS #EventBridge #CostOptimization #Fargate #EC2 #FinOps

We Ditched MongoDB Atlas for AWS DocumentDB — Here's Exactly How We Did It

Rajeev — Mon, 10 Aug 2026 15:02:24 +0000

We Ditched MongoDB Atlas for AWS DocumentDB — Here's Exactly How We Did It

One connection string change. Zero downtime. One very long night. Here's the full story.

I want to tell you something most engineering blogs won't.

Migrations are messy. They go sideways at 11pm. They reveal assumptions you didn't know you had. And the "5-minute fix" always takes 3 hours.

This is the real story of how we migrated our production MongoDB database from Atlas to AWS DocumentDB — every command, every mistake, every fix, and every lesson learned the hard way.

If you're planning a similar migration, read this before you start. It will save you hours.

Why We Even Did This

Our stack was already 100% on AWS:

ECS Fargate running our Node.js backend
EC2 for our app server
RDS PostgreSQL for relational data
S3 for file storage
ALB for load balancing

And then there was MongoDB Atlas — sitting outside AWS, on MongoDB's cloud, billed separately, with data crossing the public internet every single request.

The CTO asked a simple question: "Why are we paying Atlas when we're already on AWS?"

That question started this migration.

The goals were clear:

Consolidate to one cloud provider
Cut cross-cloud data transfer costs
Put the database inside our VPC (zero public internet exposure)
One bill, one security boundary, one team managing everything

What We Were Working With

Before writing a single command, we mapped the full picture:

Source — MongoDB Atlas:

~32 collections
~2,400 documents (and growing daily)
Used by 2 ECS services (prod + staging) and an EC2 backend
Publicly accessible via mongodb+srv://

Target — Amazon DocumentDB:

MongoDB 5.0 compatible
Lives inside a private VPC (no public endpoint — this matters, a lot)
Managed by AWS (auto backups, failover, CloudWatch)
Tight integration with IAM, VPC Security Groups, KMS

The architecture we were building toward:

┌──────────────────────────────────────────────────┐
│                  AWS VPC (private)               │
│                                                  │
│  ┌─────────────────┐      ┌──────────────────┐  │
│  │  ECS Fargate    │      │  EC2 App Server  │  │
│  │  prod + staging │      │  Public IP       │  │
│  └────────┬────────┘      └────────┬─────────┘  │
│           │                        │             │
│           └──────────┬─────────────┘             │
│                      │ private network            │
│           ┌──────────▼──────────┐               │
│           │   Amazon DocumentDB  │               │
│           │   port 27017        │               │
│           │   encrypted at rest │               │
│           └─────────────────────┘               │
└──────────────────────────────────────────────────┘

Clean. Secure. Everything private. No data crossing the public internet.

Choosing the Migration Strategy

We had three options:

Strategy	Complexity	Downtime	Best For
AWS DMS (live CDC)	High	Zero	Large DBs, can't afford downtime
mongodump + mongorestore	Low	Minutes	Small-medium DBs
Custom change streams script	Very High	Zero	Custom transformations

We chose mongodump + mongorestore. Here's why:

Our database was under 1GB. Our staging environment would absorb the testing. And mongodump/mongorestore is the most battle-tested MongoDB migration tool in existence — boring is good when it comes to production data.

Phase 1: Infrastructure Setup (The Foundation)

Step 1 — DocumentDB Subnet Group

DocumentDB needs subnets across at least 2 availability zones for redundancy. We used our existing private subnets:

aws docdb create-db-subnet-group \
  --db-subnet-group-name myapp-docdb-subnet-group \
  --db-subnet-group-description "Subnet group for DocumentDB" \
  --subnet-ids subnet-xxxxxxxx subnet-yyyyyyyy \
  --region ap-south-1

Step 2 — Security Group (Port 27017, VPC Only)

Never open 27017 to the internet. VPC CIDR only:

# Create security group
aws ec2 create-security-group \
  --group-name myapp-docdb-sg \
  --description "DocumentDB security group" \
  --vpc-id vpc-xxxxxxxxxx

# Allow port 27017 from VPC only
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxxx \
  --protocol tcp \
  --port 27017 \
  --cidr 10.0.0.0/16

# Also allow from your ECS security group
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxxxx \
  --protocol tcp \
  --port 27017 \
  --source-group sg-your-ecs-sg

Step 3 — Create the Cluster + Instance

# Create cluster (encrypted at rest by default)
aws docdb create-db-cluster \
  --db-cluster-identifier myapp-docdb \
  --engine docdb \
  --master-username admin \
  --master-user-password "YourStrongPassword123!" \
  --db-subnet-group-name myapp-docdb-subnet-group \
  --vpc-security-group-ids sg-xxxxxxxxxx \
  --storage-encrypted \
  --region ap-south-1

# Add an instance to the cluster
aws docdb create-db-instance \
  --db-instance-identifier myapp-docdb-instance-1 \
  --db-cluster-identifier myapp-docdb \
  --db-instance-class db.t3.medium \
  --engine docdb

⏱️ Wait 8-10 minutes for the cluster to become available. Grab a coffee.

Phase 2: The Migration — Where It Gets Interesting

The Problem Nobody Warns You About

Here's what I wish someone had told me before I started:

DocumentDB has no public endpoint.

It lives inside your VPC. Period. You cannot run mongorestore from your laptop to DocumentDB. You need a machine inside the VPC to act as a bridge.

The architecture looks like this:

Your Laptop
    │
    │ 1. mongodump ──► reads Atlas
    ▼
/tmp/dump/ (BSON files on your machine)
    │
    │ 2. scp ──► copies files to EC2
    ▼
EC2 Instance (inside VPC) ◄── this is your bridge
    │
    │ 3. mongorestore ──► writes to DocumentDB
    ▼
Amazon DocumentDB (private, inside VPC) ✅

We used our existing EC2 app server as the bridge. No new infrastructure needed.

Step 4 — Dump Everything from Atlas

# Full database dump
mongodump \
  --uri="mongodb+srv://user:password@cluster.mongodb.net/mydb" \
  --out=/tmp/myapp_backup

# Verify the dump
ls -lh /tmp/myapp_backup/mydb/
# You should see .bson + .metadata.json for every collection

Step 5 — Transfer to EC2

# Copy all dump files to EC2
scp -i your-keypair.pem -r \
  /tmp/myapp_backup/ \
  ubuntu@<ec2-public-ip>:/tmp/myapp_backup/

# Verify files arrived
ssh -i your-keypair.pem ubuntu@<ec2-ip> "ls /tmp/myapp_backup/mydb/ | wc -l"

Step 6 — Download TLS Certificate on EC2

DocumentDB requires TLS. The cert needs to be on the machine running mongorestore:

ssh -i your-keypair.pem ubuntu@<ec2-ip>

# Inside EC2:
wget https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

Step 7 — Restore to DocumentDB

# Run this inside EC2
mongorestore \
  --uri="mongodb://admin:password@myapp-docdb.cluster-xxxxx.region.docdb.amazonaws.com:27017/mydb?tls=true&tlsCAFile=global-bundle.pem&replicaSet=rs0&retryWrites=false" \
  --db=mydb \
  --dir=/tmp/myapp_backup/mydb \
  --drop

The --drop flag is crucial — it drops each collection before restoring. This makes the command idempotent (safe to re-run if something goes wrong).

Step 8 — Verify Every Collection Count

Never skip this step.

# Check Atlas counts
mongosh "atlas-connection-string" --quiet --eval \
  "db.getCollectionNames().forEach(c => print(db[c].countDocuments() + '\t' + c))" | sort -rn

# Check DocumentDB counts (from EC2)
mongosh "docdb-connection-string" --quiet --eval \
  "db.getCollectionNames().forEach(c => print(db[c].countDocuments() + '\t' + c))" | sort -rn

Every single number must match. If one doesn't — fix it before moving on.

Phase 3: The Connection String — The Devil Is In The Details

This is where most migrations break silently.

Atlas string:

mongodb+srv://user:pass@cluster.mongodb.net/mydb?retryWrites=true&w=majority

DocumentDB string:

mongodb://user:pass@myapp-docdb.cluster-xxxxx.docdb.amazonaws.com:27017/mydb?tls=true&tlsAllowInvalidCertificates=true&replicaSet=rs0&retryWrites=false&authMechanism=SCRAM-SHA-1

The critical differences:

Parameter	Atlas	DocumentDB	Why
Protocol	`mongodb+srv`	`mongodb://`	SRV not supported
`retryWrites`	`true`	`false`	DocumentDB doesn't support it
`replicaSet`	not needed	`rs0`	Required for DocumentDB
Port	auto (SRV)	`27017`	Must be explicit
TLS cert	automatic	manual	`global-bundle.pem` needed

Miss any of these and your app either crashes silently or throws cryptic errors.

Phase 4: Application Switchover

Always Staging First. Always.

We updated the ECS task definition environment variable:

# Register new task definition revision with updated MONGODB_URI
aws ecs register-task-definition \
  --family myapp-backend \
  --container-definitions '[{
    "name": "backend",
    "environment": [
      {
        "name": "MONGODB_URI",
        "value": "mongodb://user:pass@docdb-endpoint:27017/mydb?tls=true&tlsAllowInvalidCertificates=true&replicaSet=rs0&retryWrites=false&authMechanism=SCRAM-SHA-1&maxPoolSize=10&minPoolSize=2&connectTimeoutMS=5000&socketTimeoutMS=30000&serverSelectionTimeoutMS=5000"
      }
    ]
  }]'

# Deploy to staging ONLY first
aws ecs update-service \
  --cluster myapp-cluster \
  --service myapp-staging \
  --task-definition myapp-backend:NEW_REVISION \
  --force-new-deployment

Watch the logs until you see:

🚀 Server running on port 5000
MongoDB connected successfully ✅

Phase 5: The 504 Nightmare

After switching staging to DocumentDB — login started taking 3-5 seconds. Users were getting 504 Gateway Timeout errors.

This one hurt.

The root cause: DocumentDB connection latency is higher than Atlas. Without connection pool configuration, every request was creating a new DB connection from scratch. Cold connections on DocumentDB take 3-5 seconds.

The fix was adding connection pool parameters to the URI:

&maxPoolSize=10
&minPoolSize=2
&connectTimeoutMS=5000
&socketTimeoutMS=30000
&serverSelectionTimeoutMS=5000
&heartbeatFrequencyMS=10000

Full optimized string:

mongodb://user:pass@docdb-endpoint:27017/mydb?tls=true&tlsAllowInvalidCertificates=true&replicaSet=rs0&retryWrites=false&authMechanism=SCRAM-SHA-1&maxPoolSize=10&minPoolSize=2&connectTimeoutMS=5000&socketTimeoutMS=30000&serverSelectionTimeoutMS=5000&heartbeatFrequencyMS=10000

Result: Login went from 3-5 seconds → under 500ms. ✅

minPoolSize=2 is the key — it keeps 2 warm connections alive at all times, so the first request never has to wait for a cold connection.

Phase 6: The Re-sync Problem

We migrated on Day 1. We deployed to staging on Day 3. We did a final check on Day 16.

Atlas had 157 new documents that DocumentDB didn't.

This is normal and expected. Any live database will accumulate new data between your migration and your cutover date. The fix is a re-sync run right before prod switchover:

# Step 1: Fresh dump from Atlas
mongodump --uri="atlas-uri" --out=/tmp/resync

# Step 2: Transfer to EC2
scp -r /tmp/resync/ ubuntu@ec2-ip:/tmp/

# Step 3: Restore with --drop (fully safe, idempotent)
mongorestore \
  --uri="docdb-uri" \
  --dir=/tmp/resync/mydb \
  --drop

# Step 4: Verify counts again
# Atlas count == DocumentDB count? ✅ Good to go.

Run this re-sync as close to prod cutover as possible — ideally within hours.

What's Different in DocumentDB vs Atlas

Before you migrate — test these in your app:

Feature	Atlas	DocumentDB
Basic CRUD	✅ Full	✅ Full
Mongoose ODM	✅ Full	✅ Full
`$lookup` aggregation	✅ Full	⚠️ Limited
Transactions	✅ Full ACID	⚠️ Limited
Change streams	✅ Full	⚠️ Limited
Atlas Search	✅ Yes	❌ No
`retryWrites=true`	✅ Yes	❌ Must be false
Text search	✅ Yes	⚠️ Limited

If your app uses basic Mongoose CRUD — you're fine. If you rely heavily on complex aggregations, transactions, or Atlas Search — test everything on staging before touching prod.

Developer Access After Migration

This confused our dev team at first.

Atlas: Anyone with the connection string can connect from anywhere.
DocumentDB: Private VPC. Can't connect from outside without a tunnel.

Dev Laptop ──► SSH Tunnel ──► EC2 ──► DocumentDB

SSH tunnel command:

# Keep this running in a terminal
ssh -i your-keypair.pem -N \
  -L 27017:docdb-endpoint:27017 \
  ubuntu@ec2-public-ip

Then connect to 127.0.0.1:27017 from your app or MongoDB Compass.

Our recommendation: Keep Atlas for local development. Use DocumentDB for prod/staging only. Zero friction, cleanest separation.

The Rollback Plan (Non-Negotiable)

Before every prod migration, write your rollback plan:

If DocumentDB fails:
1. Update ECS task def → revert MONGODB_URI to Atlas string
2. aws ecs update-service --force-new-deployment
3. Back on Atlas in under 5 minutes

Rule: Never delete Atlas until DocumentDB runs in prod for 30+ days.

We kept Atlas running as a safety net the entire time. This is not optional.

The Numbers

Metric	Before (Atlas)	After (DocumentDB)
Cross-cloud data transfer	Charged per GB	Free (same VPC)
Public internet exposure	✅ DB accessible publicly	❌ DB fully private
Security surface	Atlas IP whitelist	AWS Security Groups + VPC
Monitoring	Atlas UI	CloudWatch + Alerts
Backup	Atlas managed	AWS automated + S3 cron
Login response time (after pool fix)	~200ms	~450ms

The Complete Migration Checklist

INFRASTRUCTURE
☐ DocumentDB subnet group (private subnets, 2+ AZs)
☐ Security group (port 27017, VPC only)
☐ Allow ECS + EC2 security groups in DocDB SG
☐ DocumentDB cluster (storage encrypted)
☐ DocumentDB instance (right size for workload)

MIGRATION
☐ mongodump full backup from Atlas
☐ Verify dump files exist for all collections
☐ scp files to EC2
☐ Download global-bundle.pem on EC2
☐ mongorestore with --drop flag
☐ Verify doc counts match on EVERY collection

APPLICATION
☐ New MONGODB_URI with all required params
☐ Add connection pool params to URI
☐ Deploy to staging first
☐ Watch logs for "MongoDB connected successfully"
☐ Test all critical API endpoints on staging
☐ Monitor for 24h on staging before touching prod
☐ Re-sync Atlas → DocumentDB right before prod cutover
☐ Deploy to prod
☐ Monitor prod logs and CloudWatch

POST-MIGRATION
☐ Set up daily mongodump → S3 backup cron
☐ Configure CloudWatch alarms (connections, CPU, latency)
☐ Keep Atlas alive for 30 days minimum
☐ Delete Atlas cluster only after team sign-off

Key Takeaways

1. The bridge EC2 pattern is your best friend.
DocumentDB's private-only design is a feature. Use your existing EC2 as the migration bridge.

2. Connection pool tuning is not optional.
minPoolSize=2 alone will save you from 504 nightmares. Add it from day one.

3. Always staging first.
We caught the 504 issue on staging before it ever touched prod. This is why staging exists.

4. Plan for re-sync.
Your live database never stops growing. Always re-sync within hours of prod cutover, not days.

5. Keep Atlas longer than you think you need to.
The cost of one extra month of Atlas is nothing compared to the cost of a production incident with no rollback.

6. Your app code changes nothing.
With Mongoose, only the MONGODB_URI env var changes. Zero code changes required.

Final Thoughts

Moving from Atlas to DocumentDB is fundamentally a security and infrastructure consolidation play. Your data moves from the public internet into a private VPC. Your costs consolidate to one provider. Your team manages one less external service.

The technical work is real — but it's manageable. The hardest part isn't the commands. It's the patience to test everything on staging, verify every collection count, and resist the urge to rush to prod.

Do it right, and your app code never knows the difference.

Have questions about your own migration? Drop them in the comments — happy to help.

If this saved you time, consider sharing it with someone who's about to go through the same thing.

Tags: #AWS #MongoDB #DocumentDB #DevOps #DatabaseMigration #BackendEngineering #CloudArchitecture #NodeJS #ECS #SoftwareEngineering

💻 AWS RDS Services: Comprehensive Guide

Rajeev — Sun, 02 Mar 2025 05:40:43 +0000

AWS Relational Database Service (RDS) is a managed service for setting up, operating, and scaling relational databases in the cloud. This guide will help you understand RDS theoretically and implement it practically.

🎯 What is AWS RDS?

AWS RDS is a fully managed relational database service designed to simplify database management tasks like setup, scaling, patching, and backups while providing high availability and durability. It supports popular database engines such as:

Amazon Aurora (PostgreSQL and MySQL-compatible)
MySQL
MariaDB
PostgreSQL
Oracle
Microsoft SQL Server

📋 Key Features of RDS

Managed Service: Automates database administration tasks.
Multi-AZ Deployment: Ensures high availability and automatic failover.
Scalability: Easy to scale storage and compute capacity.
Backup and Recovery: Automated backups, manual snapshots, and point-in-time recovery.
Security: Encryption at rest and in transit, IAM integration, and VPC support.
Monitoring: Integrated with CloudWatch for performance metrics.
Support for Read Replicas: Improves read performance by replicating data across multiple instances.

🛠️ Practical Guide: Getting Started with RDS

Part 1: Create an RDS Instance

Log in to AWS Console
- Navigate to the RDS Dashboard.
Click on "Create Database"
- Select Standard Create for advanced configuration.
Choose Database Engine
- Select an engine like MySQL, PostgreSQL, or Amazon Aurora.
Specify Instance Details
- DB Instance Class: Choose based on your workload (e.g., db.t2.micro for testing).
- Storage: Allocate storage (default: 20 GB).
Configure Connectivity
- VPC: Choose a VPC or create a new one.
- Public Access: Enable or disable based on your requirements.
- Security Groups: Ensure proper inbound/outbound rules.
Additional Settings
- Enable Multi-AZ Deployment for production environments.
- Set up automated backups and specify a backup retention period.
Launch the Instance
- Review and click "Create Database".

Part 2: Connect to the RDS Instance

Retrieve Connection Information
- Go to the RDS dashboard, select your instance, and copy the Endpoint and Port.
Access via a SQL Client
- Use a client like MySQL Workbench, pgAdmin, or any terminal-based tool.
- Example for MySQL:
```
 mysql -h <endpoint> -u <username> -p
```

Test the Connection

Create and query a sample database:

 CREATE DATABASE testdb;
 USE testdb;
 CREATE TABLE users (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50));
 INSERT INTO users (name) VALUES ('John Doe');
 SELECT * FROM users;

Part 3: Enable Read Replicas for Scalability

Create a Read Replica
- Open the RDS instance details.
- Click on "Create Read Replica".
Configure the Replica
- Specify instance class and storage.
- Assign a unique identifier and launch it.
Use the Replica for Read Operations
- Connect to the replica using its endpoint for read-only queries.

Part 4: Automate Backup and Recovery

Automated Backups
- Enabled by default. Modify settings under Backup Configuration.
Manual Snapshots
- Go to the RDS dashboard, select your instance, and click "Take Snapshot".
Restore from Snapshot
- Navigate to Snapshots, choose a snapshot, and click "Restore Snapshot".

🔒 RDS Security Best Practices

VPC Isolation
- Deploy RDS instances within private subnets of a VPC.
IAM Policies
- Restrict access to RDS resources based on roles.
Encryption
- Enable encryption for data at rest using AWS KMS.
Access Control
- Use security groups to define inbound/outbound traffic rules.

📊 Monitoring and Optimization

CloudWatch Metrics
- Monitor CPU utilization, IOPS, connections, and latency.
Performance Insights
- Use AWS RDS Performance Insights for analyzing query performance.
Scaling
- Modify the instance class or use Aurora Serverless for automatic scaling.

🛠️ AWS CLI Commands for RDS

Create RDS Instance:

   aws rds create-db-instance \
     --db-instance-identifier mydbinstance \
     --db-instance-class db.t2.micro \
     --engine mysql \
     --allocated-storage 20 \
     --master-username admin \
     --master-user-password mypassword \
     --backup-retention-period 7 \
     --availability-zone us-east-1a

List RDS Instances:

   aws rds describe-db-instances

Delete RDS Instance:

   aws rds delete-db-instance \
     --db-instance-identifier mydbinstance \
     --skip-final-snapshot

🔗 Use Cases of AWS RDS

Web Applications
- Store application data for websites built with frameworks like Django, Laravel, or Spring.
Data Warehousing
- Use read replicas to offload analytical queries.
ERP and CRM Systems
- Host relational data for enterprise-grade systems.

📂 Additional Resources

Start leveraging AWS RDS for your database needs to save time, increase scalability, and ensure data reliability. 🚀

🚀 Learn AWS EC2: Ultimate Beginner's Guide 🌐

Rajeev — Sun, 02 Mar 2025 05:39:08 +0000

Welcome to the AWS EC2 Tutorial! This guide will take you through everything you need to know about Amazon Elastic Compute Cloud (EC2)—from launching instances to hosting your first webpage!

🎯 What is AWS EC2?

Amazon EC2 is a web service that provides resizable compute capacity in the cloud. It enables businesses to deploy applications quickly without hardware investments.

📋 Table of Contents

🌟 Why Learn EC2?
🚀 Getting Started
📦 EC2 Instance Types
⚙️ Launching an EC2 Instance
🌐 Hosting a Simple Webpage
🔒 Security Best Practices
📈 Monitoring and Scaling
🎉 Conclusion

🌟 Why Learn EC2?

🚀 Cloud Computing Mastery: EC2 is the backbone of AWS services.
💼 Career Growth: EC2 knowledge is crucial for DevOps, cloud engineers, and developers.
🌍 Real-World Applications: Use EC2 to host websites, deploy applications, or run data pipelines.

🚀 Getting Started

Prerequisites

Before you begin, ensure you have:

✅ An AWS account (free-tier eligible).
✅ Basic knowledge of cloud computing.

📦 EC2 Instance Types

AWS EC2 offers various instance types tailored for different workloads:

Type	Use Case	Examples
General	Balanced performance	`t2.micro`, `t3.small`
Compute	High-performance computing	`c5.large`, `c6i.xlarge`
Memory	Memory-intensive apps	`r5.large`, `r6g.xlarge`
Storage	Data-heavy workloads	`i3.large`, `i4i.xlarge`
GPU	Machine learning, gaming	`g5.large`, `p3.2xlarge`

⚙️ Launching an EC2 Instance

Follow these steps to launch your first EC2 instance:

Login to AWS Console 🖥️
- Navigate to EC2 under the "Compute" section.
Click "Launch Instance" 🚀
- Provide a name for your instance.
- Select an AMI (Amazon Machine Image) like Ubuntu, Amazon Linux, or Windows Server.
Choose an Instance Type 🖱️
- For beginners, choose t2.micro (free-tier eligible).
Configure Security Groups 🔒
- Add rules to allow inbound traffic for HTTP (port 80) and SSH (port 22).
Key Pair 🗝️
- Create or select an existing key pair for secure access.
Launch Your Instance 🎉
- Click Launch Instance and wait for it to initialize.

🌐 Hosting a Simple Webpage

Here’s how you can host a basic index.html file on your EC2 instance.

Step 1: Install a Web Server

Log into your EC2 instance via SSH and run the following commands to install a web server:

# Update the package manager
sudo apt update  

# Install Apache2
sudo apt install apache2 -y  

# Start Apache2 service
sudo systemctl start apache2  

# Enable Apache2 to start on boot
sudo systemctl enable apache2

Step 2: Create Your Webpage

Navigate to the default web server directory and create an index.html file:

# Navigate to the default directory
cd /var/www/html  

# Create or edit the index.html file
sudo nano index.html

Add the following content to your index.html file:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Welcome to My Webpage</title>
</head>
<body>
    <h1>🚀 Welcome to My First AWS EC2 Hosted Webpage!</h1>
    <p>This is a simple webpage hosted on an EC2 instance.</p>
</body>
</html>

Save and exit (Ctrl+O, Enter, Ctrl+X).

Step 3: Open Your Webpage

In your browser, navigate to: http://<Public_IP_of_EC2_Instance>

You should see your index.html webpage live! 🎉

🔒 Security Best Practices

Use Security Groups: Restrict inbound traffic to only required ports.
Key Management: Keep your .pem file secure.
IAM Roles: Assign least privilege roles to your instances.

🎉 Conclusion

With this guide, you’ve:

Launched your first EC2 instance.
Installed a web server.
Hosted your first index.html webpage.

Continue exploring AWS to enhance your cloud computing skills!

Need Help? Reach out on AWS Forums or join the AWS Community.

Happy Hosting! 🚀



By Rajeev Kumar