У нас есть интерфейс, реализованный в ECS. Этот интерфейс взаимодействует со шлюзами API, которые, в свою очередь, выполняют вызовы лямбда-функций. Мы внедряем решение для аварийного восстановления для этой архитектуры. Это не полная архитектура, но достаточно для этого вопроса. Таким образом, мы уверены в отказоустойчивости DNS, политике маршрутизации и т. Д., И мы хороши, когда дело доходит до реализации DR только для внешнего интерфейса. Теперь мы перешли ко второй части, которая является API Gateway и Lambda. Для шлюза API мы пришли к выводу, что интерфейс может проверить работоспособность шлюза API, если он не получил ответ в течение времени T, и сделать T + delta t как RTO. Если шлюз API не работает, он отправит запрос на шлюз API в другом регионе AWS. Мы хороши до здесь. Но проблема в том, что если лямбда не функционирует в области A, а шлюз API не функционирует в регионе B. В этом случае шлюз API региона A должен иметь возможность вызывать лямбда области B, а также должен вызывать лямбду региона А когда это здорово.
Что мне приходит в голову, так это то, что в моем коде Terraform я могу поместить некоторую логику (очевидно, декларативным способом или некоторый обходной путь), чтобы шлюз API выполнял вызовы только для здоровой лямбды и сам интегрировался обратно в лямбду области А, когда лямбда области А возвращается к здоровому состоянию. Это может быть проверено некоторыми постоянными проверками здоровья. Однако для этого нужно приложить некоторые усилия.
Хотя это редкий сценарий, когда AWS Lambda не работает во всем одном регионе, но клиент является гигантом E COM, и если мы упомянем RTO дельта t, это должно быть в определенных пределах. Мы доверяем AWS, но мы также хотим быть в безопасности во всех сценариях и иметь минимальные RTO и RPO.
Есть ли лучший способ для этого? Можем ли мы каким-то образом интегрировать несколько лямбда-шлюзов в API?