Не обязательно, для тех у кого нагрузка сильно динамична

Короче надо попробовать на деве

Добрый вечер, какие могут быть причины следующей ситуации?
Был RDS Postgresql инстанс, подняли из снэпшота его копию и переключили нагрузку на новый инстанс.
На старом инстансе Read Latency был около 1мс, на новом около 10мс.
И с Write Latency аналогичная ситуация разница примерно в 6-8 раз.
Регион, зона и настройки идентичные.

Может с хвостом не повезло?

Есть EC2 инстанс с nginx и бэкендом, которые крутятся в докере. Получил ssl сертификат для nginx через certbot. Если вдруг нагрузка возрастет и нам нужно будет поднять второй инстанс, то как это правильно сделать? Нужно ли на каждом сервере по нжинксу и сертификату? Как это вообще можно нормально организовать в рамках авс?

Через балансировщик

По идее, нужно поставить load balancer перед ec2

Ну и как обычно.
Есть два стула ...

Кто будет терминировать tls

На самом деле - самое простое решение для нагрузки - модифицировать инстанс на более модный.

Иначе вы получите плюс к стоимости ebs, трафик, ещё один инстанс, стоимость и трафик балансировщика и сложности в обновлении приложения + лишний геморрой для мониторинга и установки нового ec2

А если инстанс больше будет некуда модифицировать, то что? Или лучше все-таки не заморачиваться так?

Проблема пока теоретическая. Надо подготовиться к ситуации, когда вдруг все  будет медленно из-за нагрузки

Но все равно спасибо за полезную инфу

Более модный это как?

Резервирование(что получится в данном случае, с парой инстансов и балансёром) это тоже не есть плохо, если так подумать.

+asg (on-demand+spot)

У которого vcpu и памяти больше.

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

Система должна быть готова к скейлингу в ширь.
Если сессии, то выделенный сторедж. Или миграция на jwt.
Хелсчеки должны быть на бэкенде, чтобы балансировщик кидал запрос на живую ноду.
А построение хелчеков грамотно это не тривиально.

Ещё сбор логов будет проблемой.

Если планировщик есть, то нужно строить распределеный лок или кворумы

Бэкенд у тебя стейтлесс?
Если да, то можно смело переходить на ecs, ибо руками оркестрировать докер в один момент, мягко скажем, надоест

+ из коробки получишь интеграцию с alb/nlb

да там и стейтфулл можно, если данных немного - ефс прицепил и забил