По моему личному опыту logstash ноду лучше держать поближе к поставщику данных, например в том же кластере где крутиться filebeat. Но кроме них есть еще другие стеки, я знаю два, которые могут оказаться лучше.

Одна зона не вариант, основная цель отказоустойчивость, реплика итак одна крутится. А вот данные на диске потерять нельзя, я ожидаю что он поедет в другую зону вместе с полезной нагрузкой. Спасибо, буду гонять EFS

Так а количество реплик можно менять? Кроме одной? Если да, то проще же сделать стейтфулсет с подантиаффинити и потологией, и каждая реплика в каждую зону попадет

Нет, одна реплика, общие конфиги и данные в разрезе приложения. Иначе получу разный набор данных.
Либо RWM нужно для PV, но тогда опять же EFS)
Спасибо за помощь. Сейчас клеймы переделаю и всё.

Понял

Хранить данные в региональном сервисе. Например EFS или S3. Зависит от того, что это за данные, какая скорость (задержка и пропускная способность) и отказоустойчивость нужна.

Совершенно не критично, EFS наш выбор.

Ещё как вариант S3+AWS storage gateway (хоть блочный, хоть файловый). У storage gateway есть кэш. Но его нельзя пока сделать HA, те нужно автоматизировать поднятие второго в случае отвала первого.

Имеется ввиду переход между командами внутри AWS?

Всего амазона. Насколько мне известно, то там не важно ты из ритейла в авс, или из авс в авс, все равно проходишь внутреннее интервью.

Вот хотел узнать на сколько оно серьезное

такое же как извне

Да. Подход такой же. Неважно что внутреннее перемещение. Кроме конечно скрининга.

Так получается мне нужно какие-то служебные Лямбды только для конвертации инпута в что-то поддерживаемое шагом Choice.
Иначе никак не обработать изменяемый payload где может быть секция или может не быть и порядок не контролируется.
К примеру на входе массив из обьектов сервисов в котором все параметры.

Допустим это не проблема, запустил параллельный разворот CFT.
В каждой бранче завершается все Хелсчеком.
В аутпуте получаю следующее, к примеру:
ParallelExecution:[
{
createdStackName": "auth-service-34523",
       isStackCreated: true,
},
{
createdStackName": "getaway-service-45213",
       isStackCreated: true
},
{
createdStackName": "store-service-5663",
       isStackCreated: false
}]

Мне стоит этот массив так же в какой-то сервисной лямбде в цикле обрабатывать и говорить что окружение готово или упало и идти на ролбек?

Мне здесь не нравится момент сокрытия логики в Лямбде, но других вариантов не вижу.
Так как для меня процесс управления инпут/атпут выглядит крайне не гибких на уровне SF.

Вообще, на чём угодно можно писать лямбды.
Можно даже свой язык написать и на нём писать.

https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html

Коллеги, подскажите плиз, это нормальный флоу и вообще возможно так реализовать:
1) Юзер с фронта стучится в Cognito - получает токен
2) Идет с этим токеном в API Gateway
3) В API Gateway отрабатывает лямбда, которая верифицирует токен, назначает роль юзеру и просаживает ниже в нужный микросервис.
Если пользователь пошел в gateway как аноним, и от микросервиса вернулась 401, то редиректить его на форму логина

дали кейс, избавиться от keycloak и zuul прокси в сторону средств aws

ой лол, Германия будет строить свое облако GAIA X

а вы над яндексом смеялись

Атата!

Атата набрасывать в понедельник!