I am new to AWS. After invalid deployment my environment cloudapp went to the Grey state. I have created another environment cloudapp-1and successfully uploaded and deployed my app. Then I swap the URLs to keep the first address still working.
Now when my first env is in the Grey state I am not able to do anything with it. I am not able to deploy, rebuild or even terminate it. I receive errors like this ones below.
Stack deletion failed: The following resource(s) failed to delete: [awseb-xxx-AWSEBSecurityGroup].
2016-07-13 13:23:32 UTC+0200 ERROR Deleting security group named: awseb-xxx-AWSEBSecurityGroup failed Reason: resource sg-xxxxxxx has a dependent object
I have tried to remove AWSEBSecurityGroup from cloudapp but i cannot because:
Error
Unable to validate settings: Environment named cloudapp is in an invalid state for this operation. Must be Ready.
It looks like kind of deadlock. I cannot delete the env because of a security group and I cannot change that group because the env is not Ready.
How to fix it?
First make sure that no other instances than the ElasticBeanstalk EC2 instances belonging to this particular environment is using the sg-xxxxxx security group.
Then you must make sure that you do not have any depending objects of that security group, like the error message vaguely states. Go to EC2 > Security Groups and search by Source/Destination (Group Id) for the sg-xxxxxx group.
This will give you a list of all security groups having rules referencing sg-xxxxxx. Once you've removed the depending rules you can retry your ElasticBeanstalk operation.
Related
I'm trying to create an autoscaling group manages EKS worker node provisioning. According to AWS' docs under the "Nodes fail to join cluster" section, in order for instances to join a cluster, the new instances must contain the tag kubernetes.io/cluster/my-cluster where my-cluster is the name of the cluster and the value of the tag must be owned. However, when the auto scaling group tries to provision new instances, I see the following error in the activity section:
Launching a new EC2 instance. Status Reason: Could not launch Spot
Instances. InvalidParameterValue -
'kubernetes.io/cluster/my-cluster' is not a valid tag
key. Tag keys must match pattern ([0-9a-zA-Z\-_+=,.#:]{1,255}), and
must not be a reserved name ('.', '.', '_index'). Launching EC2
instance failed.
Does anyone know why this is happening and how I can address this?
I worked with AWS Support and discovered the issue is coming from a new feature called instance tags on EC2 instance metadata service.
This feature provides an alternative solution to making API calls via AWS CLI by allowing developers to use the metadata service API to query instance tags. This is useful to reduce the number of API calls if you are having issues with exceeding the maximum number of requests to AWS.
However, this causes conflicts with auto scaling group when the special IAM key is required which includes non-supported characters.
The solution to the problem is to set 'Metadata accessible' to 'Don't include in launch template' or 'Disabled' when creating your launch template.
You can find this option when creating or modifying a launch template under: Advanced details section > Metadata accessible
I am trying so hard to delete an elastic beanstalk environment but it is showing some error as shown in the below screenshot. Any help will be appreciated.
It is saying that something (else) is using the Security Group.
You should:
Try to manually delete that Security Group
If you get an error (most likely), then you will need to hunt for other resources that are using that security group (probably some other EC2 instances)
If you are okay with removing the Security Group:
Detach the Security Group from the other resource(s)
Try terminating the stack again
If you do not wish to delete that Security Group, then:
Delete the CloudFormation stack manually
When stack deletion fails, try it again and it will ask which resources you do not wish to delete. You can select the Security Group here
Once the Stack is deleted, go back into Elastic Beanstalk and try to clean things up
I am new to AWS and,
Here's the drill:
- Logged in to AWS with root admin credentials.
- I created few security groups in AWS.
- Terminated all the EC2 instances that I had.
- Deleted ELB successfully.
- Deleted RDS successfully.
- Using default VPC and no Elastic IPs.
Now, when I am trying to delete security groups, one group says its being referenced by another. When I try to delete the referenced one, it says that the security group is being referenced by a Network Interface.
We get two options here- Associate with another group or Delete that Network Interface.
Trying first makes no sense as I want to get rid of all the Security Groups except the default (Like it was in the beginning). Still I tried that option and got the error "You do not have permission to access the specified resource" and it did not let me associate that Network Interface (Status-In Use) with any Security Group.
Tried deleting/detaching(force) that Network Interface and got an error message "You do not have permission to access the specified resource."
A similar issue can be found below without any known solution:
https://forums.aws.amazon.com/thread.jspa?threadID=99189&start=0&tstart=0
Unresolved Stackoverflow link: issue in deleting VPC and network interface
I would really appreciate if someone hits me with a hammer of facts :)
Thanks, in advance!
I had the same issue, after having removed load balancers, auto-scaling groups, the memcached cluster and so on, I couldn't delete the VPC.
I had the feeling that there was some vicious circle between two network interfaces that I couldn't detach or modify and the security group itself that I couldn't remove as long as it was attached to the interfaces.
I ran the aws elasticache describe-instances command (I saw a reference to elasticache in a network interface description) to see if it would show something I missed.
And indeed, there was some redis cluster remaining, that I didn't see in the mess of the UI, which was some remnant of a long forgotten test. After having removed this cluster, I could delete the VPC.
So I'd say that kind of issue: unauthorized access, even for admins is mainly related to a component managed by AWS, and to the fact that the UI is far from friendly when it comes to know from where an error comes.
https://forums.aws.amazon.com/thread.jspa?threadID=168376
It looks like sg-72bd411a does in fact reference itself. You'll need to go into it and remove the reference before you can delete it.
I created a launch configuration using the Amazon ECS-oriented AMI. All of the instances are connected to a VPC but also have a public non-EIP address.
When I create an autoscaling group, I can look in the Instances page and see the instances pass all health checks.
Furthermore, the ELB I created picks the new instances up and begins to serve traffic to them.
However, the autoscaler always shows my instances as "pending" and eventually destroys them.
What is going on?
Instances:
ELB:
Autoscaling show instances pending:
Thanks for any help!
EDIT
Here's the output from the launch log, with a very unhelpful message:
Check your ASG Activity History tab from the Auto Scaling Group module, checking in particular for the transition from Scale Out to Pending, to Terminated.
For each of those, check the 'more' arrow that will display the following fields:
Description: Launching a new EC2 instance: i-0aaaaa06b45ce05
Cause: At 2016-06-16T17:54:25Z an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 2 to 4
The activity history and the related lifecyle events description and cause will help you narrow down the problem quickly.
The cause for the Terminated/Cancelled event will be of particular interest. Here is an example of a Terminated event:
Description: Terminating EC2 instance: i-0aaaaaad47162b8f84
Cause: At 2016-05-20T08:12:42Z an instance was taken out of service in response to a EC2 instance status checks failure.
EDIT:
Based on the log history provided, the instance is failing to launch because of a Only EC2-Classic instances may be linked. error. There is configuration problem in the Launch Configuration.
Check your Launch Configuration, and make sure that Link to VPC option is unchecked in Advanced Details.
I'm creating EC2 machines in AWS using JClouds. The machines are created without any issues but they are put into a default security group created by JClouds. A typical default security group by JClouds will have the "jclouds#" prefix like here:
jclouds#euweawlt-c96-j40788-26
Since we have predefined security groups I want to use them instead.
According the link JClouds AWS guide this should be possible through a simple line of code:
template.getOptions().as(EC2TemplateOptions.class).securityGroups(group1, group2);
So I've added it to my code as well:
computeTemplate.getOptions().as(EC2TemplateOptions.class).securityGroups(securityGroup);
...where securityGroup is the name of our predefined security group.
The same documentation page states that this should be enough:
"With respect to the security group, jclouds creates a security group for you, with rules corresponding to the inboundPorts() option (defaults to open port 22), unless you use the option EC2TemplateOptions.securityGroups()."
The end result is that the EC2 machine is added to the security group specified by the above code AND the default "jcloud#..." security group as well. Hence JClouds does create a default security group after all.
I really want to get rid of that since we already have a security group, it is not removed when the machine is terminated and there have been exceptions thrown by the JClouds API due the security group not being available after creation, whatever that means.
Any pointers are welcome.
Looking at the code, it looks like you're right and jclouds will always create that security group by default. I think there is no current workaround for that and I'd suggest you report that as an issue in the jclouds JIRA.
I think the fix should be as easy as moving the highlighted lines into the previous else clause, but let's better open the issue so it can be properly tracked