I would just run:
aws ec2 describe-instances --filters Name=instance-state-name,Values=pending,running,shutting-down,stopping,stopped
This will implicitly filter by ec2 instances that are not terminated because terminated
is the only state not included in the filter.
You could also try using --query
parameter to filter by if it is not terminated. However, that it is done client side unlike the --filters
which is done server side.
The inverse feature does not look to be apart of EC2's API. If I were to guess this is a customization done by the console on top of EC2's API. I am not sure if we would want to add it as a feature to the CLI either because there is a viable workaround and writing the customization would be complicated.
Let me know how that works out for you and/or if you have any questions.
Hmm. I agree that if the inverse is done client side by the console, it wouldn't make sense to implement it, as there's a simple workaround, like you mentioned.
I do see a use case though for a server side inverse filtering for a case where the values don't form a finite set (e.g. tags, instance types) and you want to return 'all but this'.
Looking at the EC2 API docs for Filter I initially though that the API doesn't support that, but after examining the network traffic of the web console and playing with curls, I noticed that the inverse filtering is done on the server side and the filter value in the POST request looks like this:
"filters":[{"name":"instanceType", "values":["^((?!t2\\.micro).)*$"]}]
The above filter is an inverse search for instance types != t2.micro. If it's possible over HTTP, it's probably also feasible to implement it over CLI. The question is, is there interest for it?
Interesting. I was not aware of this. I actually tried doing this from the CLI, but I had no luck.
If it is possible to do this but it is not documented, I would preferably not want to expose this in the CLI because there is a chance that the feature may change without us knowing, leading to a breaking change.
If the EC2 API was to ever expose such a feature, I would be in favor of supporting that feature. But as of now, I think not much progress can be made on implementing this feature.
Given the situation, I am going to label this as feature request, but close the issue as you can use client-side filtering through the --query
parameter. We can reopen once there is a clear path on how to support this type of server-side filtering.
@danielsiwiec Feel free to reopen if you discover anything else that can lead to a way of supporting this feature.
Definitely think that this would indeed be a useful addition. I tried specifying a JSON query to aws cli with the inversion and it didn't seem to work.
@kyleknap given that we can't really file feature requests against the actual AWS API (as far as I can tell), it seems like our best bet is to leave this open and then loop it into whatever internal machines AWS uses to track feature requests, using this ticket as an indicator that people want it.
@copumpkin You can ask for features on the EC2 forums
Most helpful comment
Hmm. I agree that if the inverse is done client side by the console, it wouldn't make sense to implement it, as there's a simple workaround, like you mentioned.
I do see a use case though for a server side inverse filtering for a case where the values don't form a finite set (e.g. tags, instance types) and you want to return 'all but this'.
Looking at the EC2 API docs for Filter I initially though that the API doesn't support that, but after examining the network traffic of the web console and playing with curls, I noticed that the inverse filtering is done on the server side and the filter value in the POST request looks like this:
The above filter is an inverse search for instance types != t2.micro. If it's possible over HTTP, it's probably also feasible to implement it over CLI. The question is, is there interest for it?