Мигрировать со своих мощностей в Амазон трудно.

Еще сложнее - пересоздать фундамент внутри.

И еще сложнее сделать это с помощью инструментов Infra-as-Code.

У Terraform, не смотря на большой (на мой взгляд) недостаток - невозможность отката изменений - есть конкурентное преимущество, позволяющее импортировать существующий ресурс. У Cloudformation такого нет, равно как и нет возможности пересоздать или изменить ресурс, если тот был модифицирован или удален в консоли.

Вызвано это не техническими ограничениями. Амазон, как компания с ОЧЕНЬ агрессивной бизнес моделью, стремится навязать вам не только использование своих ресурсов, зачастую жестких vendor lock’ов (одна только DynamoDB чего стоит), но и свою модель проектирования и управления облаком.

Иными словами, если вы начали создавать свою инфраструктуру через консоль, то и делайте это через консоль. Начали с IaC и Cloudformation - придерживайтесь строго этой модели, иначе никак.

Последняя “фича” drift detection, отслеживающая разницу между state’ом CFN и фактическим состоянием ресурсов, лишь предупреждает вас об отличиях. Сделать с этим ничего нельзя, нужно ручками идти в консоль и править там.

По уму приходится делать следующее: запрещать все API вызовы, кроме Get (читай - ReadOnly) для всех ролей, кроме service role для CFN, долго объяснять разработчикам, почему увеличение размера ASG на 1 экземпляр должно проходить через относительно длинный CI/CD, и что еще важнее - навязать это среди своей команды.

2019-ый год определенно будет для меня интересным.
В целях: пересоздать фундамент с нуля (MultiAccount strategy + Cloudformation + переезд с сервисов на ЕС2 на managed) и получить AWS Solution Architect Professional.

Причем я еще не знаю, что из этого сложнее.