Евгений Хлебников

Потерять можно все при любом действии и любым продуктом.
Терраформ просто позволяет сделать это .. красиво и очень удобно, если вы хреново его спланировали.
Правило 1: используйте автоприменение только в тех местах где не жалко или где вы железобетонно уверены(и берете риски на себя)
Правило 2: валидируйте план. Хотя бы глазами
Вообще, есть у некоторых людей практика делать план в файл, валидировать его какой то внешней логикой, и при успешной валидации применять план из файла, не просчитывая его заново (он делается при каждом апплае) с автоподтверждением. Мне не нравится, да и терраформ честно предупреждает что на момент реального применения ситуация может отличаться и менять придется совсем другие элементы.
Правило 3: разноси элементы по логическим слоям, чтобы уменьшить зону поражения при гибельном апплае. Например настройки сети а одной папке со своим стейтом, запуск приложения - в другой. И связывайте через ремоут стейт. Главное соблюдать меру, чтобы каждую, скажем , security group в aws не создавать в отдельных слоях.
Правило 4: используйте модули, если применение логической группы ресурсов используется более одного раза. Тут тоже не стоит плодить модули на каждый ресурс и подходить разумно.
Правило 5: тестируйте изменения! (Используя одни и те же модули для стейжа и прода). Логично предположить что если вы снесли стейж то и прод снесется.
Правило 6: используйте vcs для работы с кодом терраформ (для того чтобы откатывать код для восстановления убитого стейжа например)
Правило 7: используйте lifecycle политики Prevent destroy на ресурсах, чтобы запрещать из убиение
Помидор 7.1: используйте ignore changes там где это нужно
Правило 8: используйте правильный инструмент для того что вы хотите сделать. Терраформ умеет много чего, но конфигурейшн менеджер он не заменит, хотя по функциям они чуть да пересекаются.

В принципе, если продолжать я могу до штук 20 дойти полезных советов, но на 90% мои правила, по сути - используйте для работы с кодом терраформ те же правила что и для работы с любым другим кодом - снимете 70% проблем. Остальные будут связаны с особенностью работы терраформ и радиусом кривизны рук автора терраформ кода.

P.S. пишу на ходу в метро, орфографию и пунктуацию правит т9. Спрашивайте, вдруг заметите какой нибудь термин, который я писать не собирался :D

Функционала такого в S3, конечно же, нет.
S3 = Simple Storage Service. Основное предназначение - это хранение.
Cloudinary предоставляет вам хранение+манипуляции+еще что-то как сервис.
В S3 такое, как вам уже посоветовал Андрей, можно доделать самому, с помощью соответствующих сервисов.
Насколько много нужно танцевать - зависит от количества и качества вашего(или вашей команды) опыта в программировании.

https://docs.aws.amazon.com/en_us/cli/latest/userg...
Вы получаете креды.
Вам нужно положить их в соответствующие переменные окружения.
Далее следующая команда AWS CLI будет использовать их.

AWS (и другие подобные провайдеры) предоставляют вам не просто "виртуалку". Это возможность полностью управлять виртуальной инфраструктурой проекта - IAAS (ну и пачку SAAS конечно тоже)
Если ваш проект - одна виртуальная машина то для вас AWS это слишком много
Если у вас сложный по инфраструктуре проект, например:

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

Вот тогда вылезают плюсы AWS по управлению инфраструктурой проекта, а до того момента - и на VPS и в AWS: у вас есть виртуалка под убунту, вы подключаетесь по ssh и заверте...

RDS делает бэкапы кластера, даже если он однонодовый.
Насколько я знаю ( у меня нет такой необходимости в работе и я это не делаю) можно настроить дополнительный бэкап именно базы с помощью решений AWS Backup в S3 и выгружать оттуда.
Или дампить базу когда вам надо (как правило девелоперы так и делают в препродакшене с небольшими базами)