- Le plus récent
- Le plus de votes
- La plupart des commentaires
Run the following command to find the remaining dependencies. Be sure to replace vpc-id with your VPC ID and NetworkInterfaceId
aws ec2 describe-network-interfaces --filters 'Name=vpc-id,Values='$vpc | grep NetworkInterfaceId
Assuming you created/deleted this ECS cluster on the console, have you checked if the Cloudformation Stack has successfully removed all resources? As explained here: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create_cluster.html
The console cluster creation wizard provides a simple way to create the resources that are needed by an Amazon ECS cluster by creating a AWS CloudFormation stack.
Interesting that Console uses CloudFormation. But it was created and deleted using Terraform. I don't have any CloudFormation stacks.
Look for all objects that could be associated with the VPC that contains these un-deletable Network Interfaces like Load Balancers, EndPoints, Volumes, RDS db, etc., and delete them.
In my case there was a directory service using the networks I couldn't delete. I saw a resource ID and tried to search for it with AWS resource explorer, but it came up empty. Eventually I stumbled across the directory service, which we must have set up so we could connect a VPN to our partner. That, in turn was used by something else which had to be deleted first. The key for me was one of the error popups mentioned 'directory d-92670****' and that ID showed up in the "Directory Service" list.
An interface type of Branch as dictated by your output doesn’t seem to correspond to an ECS task or EC2 interface. Im not 100% sure what branch is but I don’t believe its related to your ECS cluster
Ran into the same issue. Had a Classic LoadBalancer running which I had to delete first manually. Then was able to delete the interface.
Check whether Namespaces of the registered Cluster has been deleted or not. After removing the Namespace associated with your ENI, the ENI will be automatically deleted. Hope this helps!
I got stuck in the similar situation. I have created ELB and other resources from within the EKS Cluster using eksctl, kubectl etc. and after deleting EKS cluster I can't delete multiple ENIs. I get an error: (Failed to detach the network interface. API error: "You do not have permission to access the specified resource."). How can I resolve or raise an issue if our Organization doesn't have Support purchased on this particular AWS Account?
When I try to resolve the issue one of my steps was this one in order to find out where this ENI is attached to.
aws support describe-attachment --attachment-id eni-attach-1aabbbccc123123
An error occurred (SubscriptionRequiredException) when calling the DescribeAttachment operation: Amazon Web Services Premium Support Subscription is required to use this service.
How can I get rid of orphan ENIs without purchasing Premium Subscription?
VPC_ID="" AWS_REGION="" aws ec2 describe-network-interfaces --region $AWS_REGION --filters 'Name=vpc-id,Values='$VPC_ID
The above helped me find the ELB associated with the network interface. Deleting the ELB helped in my case.
Contenus pertinents
- demandé il y a un an
- demandé il y a un an
- demandé il y a 10 mois
AWS OFFICIELA mis à jour il y a 5 ans
Thanks but that just gives me the info about the network interface I'm trying to delete. There isn't any attachment info. The description indicates an ECS attachment but there isn't anything in ECS to delete.
{ "NetworkInterfaces": [ { "AvailabilityZone": "us-east-1b", "Description": "arn:aws:ecs:us-east-1:XXXXXX:attachment/6b329514-eb5c-469a-8c8b-824c5f137502", "Groups": [ { "GroupName": "dev-release-ecs", "GroupId": "sg-057d044a0225fd3b7" } ], "InterfaceType": "branch", "Ipv6Addresses": [], "MacAddress": "0a:c7:53:2b:43:1d", "NetworkInterfaceId": "eni-042364fcb6f4babfe", "OwnerId": "XXXXXX", "PrivateDnsName": "ip-10-12-6-205.ec2.internal", "PrivateIpAddress": "10.12.6.205", "PrivateIpAddresses": [ { "Primary": true, "PrivateDnsName": "ip-10-12-6-205.ec2.internal", "PrivateIpAddress": "10.12.6.205" } ], "RequesterId": "YYYYYY", "RequesterManaged": true, "SourceDestCheck": true, "Status": "in-use", "SubnetId": "subnet-0466e11da627b5a60", "TagSet": [], "VpcId": "vpc-067c433463dfcd6b4" } ] }
It's worth contacting support about this; they can investigate why the network interface is still showing as in-use.
Thanks Brettski@AWS. Does that mean I have to upgrade from basic support to open a ticket? I haven't had to open a technical support before. It seems strange that I have to pay to have AWS address an issue on their side.