В целом все правильно.
Насчет деплоя - есть нюансы
- как CD pipeline знает адреса серверов? В современном "облачном" окружении они часто меняются, нужен какой-то метод для их динамического получения
- как обеспечить бесперебойную работу приложения во время деплоя?
В облаках (AWS/GCP/ наверно и Yandex) есть managed services, которые сами умеют решать эти и другие (autoscaling) проблемы. В AWS это ECS, Elastic Beanstalk, AWS App Runner, managed K8S.
Псевдо-кластер будет хуже чем один сервер - сделать надежный high availability "на коленке" не получится.
Поэтому только выбрать готовое решение и докупить необходимое железо.
Насколько понимаю, "старый" S3 Glacier сегодня неактуален и поддерживается для совместимости.
Здесь https://stackoverflow.com/a/65918160/499915 говорят, что у него более гибкие возможности для Vault Lock Policies, но похоже это очень нишевая вещь.
Сделать самому high availbility очень сложно, а с репликацией базы еще сложнее. Поэтому да - просто выбрать надежного хостера для вебсервера, а если есть деньги - хостера, который дает готовые решения для этого.
Например, multi-availability zone architecture in AWS.
Jenkins не сырая, а седая - 15 лет назад контейнеры не использовали. Я не использовал jenkins последние 4-5 лет, sshagent действительно выглядит некрасиво тут.
И стоит на что-то другое посмотреть?
Если можно использовать, то Github Actions, или другое "облачное" решение - тогда не нужно поднимать/конфигурировать build environment.
а текущем хостинге, как я понял, нужно самому создавать его, какой то самоподписной сертификат, я в этом не разбираюсь, мне надо чтобы работало по https.
Почитайте инструкцию еще раз - не может быть чтобы они рекомендовали самоподписной сертификат. Броузер такому не поверит, и правильно.
Если хостер не помогает в получение настоящего сертификата, и у вас "настоящий" линукс, а не shared hosting,
то можно воспользоваться бесплатным https://letsencrypt.org/getting-started/
