Подскажите пожайлуйста. RDS postgres Multi-AZ, хочу обновить некоторые параметры postgres и нужен ребут.
Reboot with failover поможет избежать даунтайма?

по докам вроде бы как да, но как на практике?

я не дба, но я делал фейловер этот и было ок

пасип

всем привет. подскажите, мне надо в стороннем сервисе указать IP-адреса или диапазон адресов, с которых будет разрешен доступ. сейчас у меня две ASG (blue - green deploy) и морочиться с EIP наверное не очень хочется. думал о том что бы сделать forward proxy (reverse proxy) и уже через него пускать весь трафик, но мб есть способ попроще?
т.е. у меня есть n-ое кол-во серверов, которой постоянно меняется и мне надо иметь какой то статический адрес или диапазон адресов, с которого будут приходить запросы в сторонний сервер

у тебя есть NAT gateway

с которого улетают во вне запросы, у него должен быть EIP настроен

Может уже сбрасывали, но вот кажется что-то интересное https://tutorialsdojo.com/ . фришного контента там немало

или ты про внутренний сервис, в той же VPC?

Ребят, кто хорошо cloudformation знает

есть вот такая загогулина !FindInMap [CustomAccessResourcesMap, !Select [2, !Split [":", !Ref CustomAccessArn]], !Ref CustomAccessType]. Если вместо второго параметра вставить строку - все работает, если оставить как есть Template error: every Fn::FindInMap object requires three parameters, the map name, map key and the attribute for return value

Select [2, !Split [":", !Ref CustomAccessArn]] - вот эта херь возвращает строку, если ее в Outputs вывести

причем верную строку

You can use the following functions in a Fn::FindInMap function:
• Fn::FindInMap
• Ref

жопа блин :(

хоть переменную создавать

Вообще не стоит грузить такую сложную логику в шаблон - лучше передавать с помощью используемого CI инструмента нужные параметры.

Хехе, в преимуществах то, от чего средства aws как раз избавляют

>Каждый новый сервер приводит к дополнительным накладным расходам, связанным с сетью, администрированием, объёмом хранилища, системами резервного копирования и восстановления, а также необходимостью добавления каждого сервера в систему по управлению активами (asset management). Кроме того, каждый новый сервер работает независимо от других, что может привести к проблемам с синхронизацией конфигурации между ними

IaC, Cloudformation, подготовленные AMI и вот это все

>Дополнительные проблемы возникают с хранением данных, так как каждый сервер использует свои диски и файловую систему, что часто требует от разработчиков добавления специального механизма для обработки пользовательских сессий

elastic cache, думаю с дефолтным хранилищем в файлике у фреймворков при масштабировании лямбды, которая имеет предел по ресурсам - будет то же самое

>При всплеске трафика сервисы автоматически масштабируются для удовлетворения спроса без необходимости установки новых серверов. Это позволяет приложениям быстро проходить путь от прототипа к выпуску в производственную среду

Ну всякие scale policy и прочее опять же есть. И на лямбду выделяются вроде как конкретные ресурсы, как будет решаться ситуация с той же конкуренцией процессов за ядра? Context switching, вот это все, как ее принудительно мастабировать не от трафика? Сам по себе трафик - вообще не показатель, 10000 rps для hello world обработаются легче чем 100 rps вытащить что-то из базы, посчитать для конкретного юзера и отдать ему

В общем странная статья

тоже самое можно про CI сказать) я бы наоборот хотел замены от CI сократить до минимума