1 Answer
- Newest
- Most votes
- Most comments
0
As you may know, an instance sticks around for a bit after being terminated (you can even view it in the console). Unless you have a log that stated it was terminated it can be hard to know for certain. For example the API may respond as if the instance never existed, or what if its just an outage preventing you from getting the correct information back.
Pardon my unsolicited suggestion. When you get a 400, you catch the 400 and check CloudTrail (via API) to see if there is a log. However there is a limit to how long cloud train keeps that information, so you could also write it to an S3 bucket and query there if the instance was terminated.
See this SO answer for hints too https://stackoverflow.com/a/35054667/419097
answered 3 months ago
Relevant content
- Accepted Answerasked 2 months ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 9 months ago
Providing your application with a guaranteed record of terminated instances will help stability and performance.
Yes, but the instance state is included in the response, so I can determine whether it has been terminated.
The 400 response includes a message that the instance was not found, so it is clear whether it's not found vs an outage.
I consider an instance terminated if 1) state is terminated, 2) instance not in response, or 3) 400 with not found message.
My question is simply "what is the difference between case 2 and case 3?"