DEV Community: Prajwal P

How I Debugged an "Undeletable" AWS Elastic IP and Traced It Back to Redshift Serverless

Prajwal P — Mon, 11 May 2026 12:01:27 +0000

Here's your clean blog ready to paste on Dev.to and Medium:

TITLE:

How I Debugged an "Undeletable" AWS Elastic IP and Traced It Back to Redshift Serverless

COVER IMAGE: Use a screenshot of your AWS console or the diagram we created earlier.

CONTENT — paste exactly as below:

If you work with AWS long enough, you'll eventually hit a resource that looks simple but turns into a deep troubleshooting rabbit hole.

Recently, while cleaning up unused AWS resources to reduce costs, I discovered an idle Elastic IP in my account.

At first glance, everything looked normal:

No EC2 instance attached
No NAT Gateway
No Load Balancer
No obvious parent resource

So naturally, I thought: "This should be easy. I'll just release the Elastic IP."

AWS had other plans.

The Problem

When I tried deleting the related VPC endpoint, AWS returned this error:

Operation is not allowed for requester-managed VPC endpoints

That error started one of the most interesting AWS troubleshooting sessions I've worked on — involving ENIs, VPC Endpoints, Security Groups, VPC Flow Logs, CloudWatch Logs Insights, AWS CLI, and Redshift Serverless hidden networking dependencies.

First Clue — ENI With No EC2 Instance

Inside EC2 → Network Interfaces, I found an ENI with these details:

Interface Type: vpc_endpoint
Status: in-use
Requester-managed: true

Immediately, several questions came up:

Why does a VPC endpoint have an Elastic IP?
Which AWS service owns this?
Why can't I delete it?

Understanding "Requester-Managed"

This was the major breakthrough.

When AWS marks a resource as RequesterManaged = true it means the resource exists inside your AWS account, but another AWS-managed service owns and controls it.

That is why I could see the ENI, the VPC endpoint, and the Elastic IP — but could not directly delete them.

This behavior commonly happens with managed AWS services such as Redshift Serverless, EKS, Lambda VPC networking, OpenSearch, SageMaker, ECS/Fargate, and PrivateLink integrations.

Investigating the VPC Endpoint

I inspected the endpoint using AWS CLI:

aws ec2 describe-vpc-endpoints \
  --vpc-endpoint-ids vpce-009f75251024f3fb2 \
  --region ap-south-1

The service name returned was a generated ID — AWS hides backend managed services behind these. Not useful on its own.

Security Group Investigation — The Turning Point

The endpoint was attached to a security group called data-engineering-SG.

So I listed all ENIs using that security group:

aws ec2 describe-network-interfaces \
  --filters Name=group-id,Values=sg-013897824370ebff3

One ENI description contained this string:

711651397674-REDSHIFT

That single word changed the entire investigation.

Confirming Redshift Serverless

I ran:

aws redshift-serverless list-workgroups

The output showed:

"vpcEndpointId": "vpce-009f75251024f3fb2"

Root cause confirmed.

The actual dependency chain was:

Redshift Serverless
        ↓
Requester-managed VPC Endpoint
        ↓
AWS-managed ENIs
        ↓
Elastic IP

The Elastic IP itself was never the real issue. It was simply a networking dependency created by Redshift Serverless.

Bonus Discovery — Internet Bots Were Hitting the Endpoint

Before confirming Redshift, I enabled VPC Flow Logs to verify whether anything inside my VPC was actively using the endpoint.

The logs showed traffic from public internet scanners continuously probing the endpoint because the attached security group allowed all traffic from 0.0.0.0/0.

That traffic made the endpoint appear active even though no legitimate workloads were using it.

First immediate fix: removed all 0.0.0.0/0 inbound rules.

The Fix

Once the root cause was confirmed, I deleted the Redshift Serverless resources.

Step 1 — Delete the Workgroup:

aws redshift-serverless delete-workgroup \
  --workgroup-name demos-workgroup

Step 2 — Delete the Namespace:

aws redshift-serverless delete-namespace \
  --namespace-name demos-namespace

After that, AWS automatically cleaned up the VPC endpoint, the ENIs, and the Elastic IP association.

The "undeletable" Elastic IP disappeared automatically.

Key Takeaways

1. RequesterManaged = true is always a clue
Stop trying to delete the networking resource directly. Find the managed AWS service that owns it.

2. Networking resources are usually symptoms, not root causes
The Elastic IP was not the actual issue. Redshift Serverless was.

3. Security groups can mislead investigations
Internet scanners made the endpoint appear active even though no internal workloads were using it.

4. Follow the dependency chain
Elastic IP → ENI → VPC Endpoint → Security Group → ENI Metadata → Parent Service → Delete

5. VPC Flow Logs are underrated
They helped eliminate false assumptions and saved hours of troubleshooting.

AWS Services That Commonly Create Hidden Networking Resources

Redshift Serverless
EKS
Lambda VPC networking
ECS/Fargate
OpenSearch
SageMaker
RDS Proxy
AWS Glue
PrivateLink / VPC Lattice

Final Thought

What started as "Why can't I delete this Elastic IP?" turned into a VPC networking investigation, a security audit, and a managed-service dependency trace.

The biggest lesson:

In AWS, always delete the parent resource — not the symptom.

The next time you see RequesterManaged = true, your first troubleshooting step should be:

aws redshift-serverless list-workgroups

Have you ever debugged a mysterious AWS dependency caused by a managed service? Drop your experience in the comments.

# 🚀 From “Why is nothing working?” to “Now I Understand Everything” — My Docker Compose + MongoDB + Volume Learning Journey

Prajwal P — Tue, 14 Apr 2026 12:53:58 +0000

``## 📌 Introduction

This is not just a blog.

This is a complete journey of how I:

Deployed a multi-container application on EC2
Debugged Docker networking issues
Fixed backend and frontend problems
Understood MongoDB behavior
And finally learned Docker volumes deeply

I didn’t learn this from theory.

I learned it by:

`text id="k5l1tt" breaking things → debugging → understanding → fixing `

🏗️ Project Architecture

My setup had 3 containers:

Node.js App (Frontend + Backend)
MongoDB Database
Mongo Express (DB UI)

All managed using Docker Compose.

⚙️ Step 1: Initial Setup

I ran:

`id="g3f8t0" docker compose up -d `

Everything started successfully.

When I opened:

`id="v34txs" http://<EC2-IP>:3000 `

👉 UI loaded
👉 But no data was showing from MongoDB ❌

❗ Problem 1: No Data in UI

`text id="x0k3qv" Data from MongoDB: `

👉 Empty

🔍 Debugging Step 1: Browser Network Tab

I checked DevTools → Network

`id="zk6v0l" /fetch-data → FAILED ❌ `

❗ Problem 2: Wrong API URL

Frontend code:

`id="s2o64r" fetch("http://localhost:3000/fetch-data") `

👉 Wrong ❌

Why?

Browser → localhost = my laptop
App → running on EC2

✅ Fix 1: Use Relative Path

`id="kz8yqf" fetch("/fetch-data") `

🔍 Debugging Step 2: API Response

Now API returned:

`id="r1w9cz" 200 OK `

But response:

`id="2l6c9c" {} `

❗ Problem 3: MongoDB Empty

I checked MongoDB:

`id="s1vxz1" show dbs use my-db show collections `

👉 No collections ❌

✅ Fix 2: Insert Data

`id="7x6pkn" db.my-collection.insertOne({ data: "some dynamic data loaded from DB" }) `

🔍 Debugging Step 3: Still Not Working

Even after inserting data:
👉 UI still empty ❌

❗ Problem 4: Backend Not Fetching Data

Backend was not:

Selecting DB properly
Querying collection
Returning response

✅ Fix 3: Backend Logic

`js id="v9u5ah"
const db = client.db("my-db");

db.collection("my-collection").findOne({}, function (err, result) {
res.json({
data: result.data
});
});
`

🔍 Debugging Step 4: Still Empty UI

Now:

API working ✅
DB has data ✅
Backend correct ✅

👉 UI still empty ❌

❗ Problem 5: Frontend Bug

Mistake:

`id="n3x7ml" fetch('/fetch-data'); const jsonResponse = await response.json(); `

👉 response undefined ❌

✅ Fix 4: Correct Fetch

`js id="9z1qj8" const response = await fetch('/fetch-data'); const jsonResponse = await response.json(); `

❗ Problem 6: DOM Not Loaded

`id="3u7q3x" document.getElementById('dynamic') `

👉 ran too early ❌

✅ Fix 5: window.onload

`js id="y5u2p0"
window.onload = async function () {
const response = await fetch('/fetch-data');
const jsonResponse = await response.json();

document.getElementById('dynamic').textContent = jsonResponse.data;
};
`

❗ Problem 7: Container Not Updating

Changes not reflecting ❌

✅ Fix 6: Rebuild + Recreate

`id="0j6yxn" docker compose down docker compose up --build --force-recreate -d `

🎉 Final Result

`id="l8m1n7" Data from MongoDB: some dynamic data loaded from DB `

💾 The Biggest Learning — Docker Volumes

After everything worked, I discovered a critical issue.

When I ran:

`id="w5n6t2" docker compose down -v `

👉 My database data was gone 💥

❗ Why Data Was Lost

Because:

Containers are temporary
Data inside container is NOT persistent

🔥 What Is a Docker Volume?

A Docker volume is persistent storage mounted directly into a container.

🧠 My Initial Wrong Thinking

“Volume is just a link”

❌ WRONG

✅ Correct Understanding

Volume is directly mounted into container

📦 MongoDB Data Path

`id="d7n9rs" /data/db `

🔗 What Docker Does

`yaml id="3c5y7a"
volumes:

mongo-data:/data/db `

👉 Docker:

`text id="9n4qkz" mounts volume → /data/db `

📊 Visual Flow

`id="y0h4b8" [ Container ] │ ▼ /data/db │ ▼ [ Docker Volume ] │ ▼ [ Host Storage ] `

🔁 What Happens on Recreate

`id="5v1q6k" docker compose down docker compose up `

Container deleted ❌
Volume remains ✅
New container created ✅
Volume mounted again ✅

👉 MongoDB reads existing data ✅

💡 Real-world Analogy

Container = Laptop 💻
Volume = External Hard Disk 💾

⚠️ Critical Command

`id="3m9q8x" docker compose down -v `

👉 Deletes volume ❌
👉 Deletes data 💥

✅ Safe Command

`id="n8k2z7" docker compose down `

👉 Keeps data ✅

🧠 Final Understanding

Container = temporary
Volume = persistent
Data lives in volume
Container just uses it

🎯 Final DevOps Insight

“Containers are ephemeral, but data must be persistent. Docker volumes ensure data survives container lifecycle.”

🚀 What I Learned

This project taught me:

Docker Compose networking
Service name vs localhost
EC2 deployment
MongoDB authentication
Backend API debugging
Frontend async handling
Docker rebuild vs recreate
Docker volumes (most important 🔥)

🧠 Interview Answer

“I deployed a multi-container app using Docker Compose on EC2, debugged networking and application issues, and implemented Docker volumes to ensure persistent database storage across container restarts.”

📢 Connect with me

LinkedIn: https://www.linkedin.com/in/prajwalputtaraju/
GitHub: https://github.com/Prajwal8651

Docker #DockerCompose #DockerVolumes #DevOps #MongoDB #AWS #NodeJS #Debugging #LearningByDoing #30DaysofAWSTerraform