什麼 HTTP 狀態程式碼可以避免實例在 AWS Elastic Beanstalk 上被標記為不健康
我正在 AWS Elastic Beanstalk 上執行應用程序。如果實例過於頻繁地響應 500（伺服器錯誤）範圍內的 HTTP 狀態程式碼，AWS 會將此實例標記為執行狀況不佳並從負載均衡器中刪除該實例。
我理解這一點並同意這實際上是一種良好的行為。但不幸的是，這會導致我的應用程序出現問題。
我的應用程序需要連接到幾個外部 API 並聚合它們的數據。其中一個不受我控制的外部 API 很不穩定，並且經常以 500 狀態程式碼響應。
目前，如果 API 引發錯誤，我的應用程序只會將該錯誤傳遞回使用者。導致 AWS 認為我的應用程序有錯誤，因此終止該實例並啟動新伺服器。但實際上，它只是導致 500 錯誤率恆定的端點之一，而所有其他端點仍然正常。
一方面，外部伺服器錯誤導致我的應用程序只返回該錯誤是正確的。另一方面，這種外部伺服器錯誤不在我的應用程序中，我可以捕捉到它。但即使我發現錯誤，我也無法返回任何對使用者有用的東西，因此仍然需要返回錯誤程式碼。
怎麼能處理這個？避免伺服器錯誤狀態程式碼不會觸發不健康的實例，但同時不使用客戶端錯誤狀態程式碼，因為使用者無能為力，他們只需要重試？
你有什麼建議？或者是否有其他選項可以微調 AWS Elastic Beanstalks 行為？
那麼問題主要是：當對該 API 的請求失敗時，您的應用程序工作流程是否要求您的客戶/使用者
a) 被通知
b) 需要採取後續行動
c) 是 HTTP 錯誤響應，這是他們可以做到的唯一方式收到通知？
如果是這樣：然後考慮遠端 API 何時生成 500 內部伺服器錯誤以讓您的應用程序返回 408 錯誤響應，這有點合適，因為它允許客戶端稍後重新送出相同的請求。（如果沒有以下限制，“502 Bad Gateway”會更好：）
此外，您可以在 Elastic Beanstalk 中配置高級執行狀況規則，指示 Elastic Beanstalk 忽略 4xx 錯誤以指示執行狀況不佳。不幸的是，在撰寫本文時，您無法對 5xx 甚至更具體的 http 狀態程式碼執行相同操作。