- Newest
- Most votes
- Most comments
1. Is this a known behavior/timing issue with RDS Proxy's internal networking cleanup after a rollback?
Yes. RDS Proxy creates its own network interfaces (RequesterManaged=true / RequesterId=amazon-rds) in your VPC (Requester-managed network interfaces, RDS Proxy network prerequisites). During an update, the proxy can create a new ENI before releasing the old one. Even though the proxy itself rolled back cleanly to its original SG (as you confirmed via describe-db-proxies), the transient ENI created during the update can lag behind on cleanup.
In your specific case — where the stack reached a stable UPDATE_ROLLBACK_COMPLETE and CloudFormation emitted "Some resources failed to delete but were skipped … Clean them up manually." — CloudFormation encountered the dependency during its cleanup phase and auto-skipped the SG, leaving it orphaned but not blocking the rollback (Fix CloudFormation stacks stuck in the cleanup state). So the state you're seeing is expected for this scenario.
Note: This auto-skip behavior is specific to the cleanup phase. It is not universal — if a dependency violation blocks the rollback itself, the stack often ends up in
UPDATE_ROLLBACK_FAILEDinstead, and you have to skip the resource manually viaContinueUpdateRollback(How do I get my CloudFormation stack to update if it's stuck in UPDATE_ROLLBACK_FAILED?). Your case is the former (stableUPDATE_ROLLBACK_COMPLETE), so no manualContinueUpdateRollbackis needed here.
2. Roughly how long before AWS releases this ENI on its own?
Requester-managed ENIs are automatically detached and deleted by the owning AWS service when the associated resource changes (Requester-managed network interfaces).
Caveat on timing: AWS does not publish a specific SLA or guaranteed time window for this cleanup — the documentation only states that the service detaches/deletes the interface, without committing to a duration. From community reports and general experience, it often completes within a day or two, but treat any such number as a rough, anecdotal expectation, not a guarantee. A few hours is well within "still normal" territory. If it persists for several days with no change, it's more likely a stale/orphaned managed ENI that needs backend cleanup (see this similar case: RDS-managed ENI stuck in-use 6+ days after instance deletion).
3. Anything safe you can do to expedite it, or does it require AWS-side intervention?
Don't try to force-detach/delete the ENI yourself. Because it's RequesterId=amazon-rds / RequesterManaged=true, EC2 will reject detach/delete (AuthFailure or "in use"), and forcing it isn't safe (Resolve errors deleting an elastic network interface).
Do verify nothing still legitimately references the SG/ENI. In ap-south-1, confirm nothing references sg-01148c21398686858 or the proxy's subnets:
aws rds describe-db-proxies --region ap-south-1 \ --query "DBProxies[].{Name:DBProxyName,Status:Status,VpcSubnetIds:VpcSubnetIds,VpcSecurityGroupIds:VpcSecurityGroupIds}" aws rds describe-db-proxy-endpoints --region ap-south-1 aws rds describe-db-instances --region ap-south-1 \ --query "DBInstances[].{Id:DBInstanceIdentifier,SG:VpcSecurityGroups}" aws rds describe-db-clusters --region ap-south-1 \ --query "DBClusters[].{Id:DBClusterIdentifier,SG:VpcSecurityGroups}"
You've already confirmed the proxy is back on its original SG — good.
A low-risk lever you can try (but no guarantee): since the proxy is healthy and settled, applying a no-op modify-db-proxy (e.g. re-applying the same VPC security group set) may prompt RDS to reconcile its ENIs and release the stale one. Be aware this is not guaranteed — re-applying the same SG set does not force RDS to rebuild its interfaces, so it may have no effect. It's worth trying only because it's essentially harmless (you're setting the proxy back to its current desired state, not changing topology):
aws rds modify-db-proxy --db-proxy-name <your-proxy-name> \ --region ap-south-1 \ --vpc-security-group-ids <current-sg-id-1> <current-sg-id-2>
On cost: the orphaned SG itself incurs no charge, and the RDS-managed ENI doesn't add charges either. The "could incur charges" wording in the CFN message is generic.
Good to know (when you can delete it): the docs note that if the service detached the ENI but didn't delete it, you can delete the detached ENI yourself (Requester-managed network interfaces). So if the ENI's Status flips from in-use to available (detached), you can then delete sg-01148c21398686858 (or the ENI) normally. Right now it's still in-use, so that condition doesn't apply yet.
