1 個回答
- 最新
- 最多得票
- 最多評論
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
已回答 3 個月前
相關內容
- 已提問 1 年前
- 已提問 6 個月前
- AWS 官方已更新 2 年前
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?"