Комментарии 7
Есть в нём какой-то смысл при наличии terraform, умеющего работать с целой кучей провайдеров, а не только AWS?
Конечно есть, vendor lock-in называется.
Ну а вдруг туда каких-нибудь супер плюшевых плюшек насыпали? Может кто-нибудь в теме расскажет.
в cloud formation быстрее приходят обновления, новые сервисы, новые настройки в ресурсах.
для того же серверлесса есть удобная надстройка cloudformation aws sam, который существенно упрощает работу с теми же лямбдами (сборка, развертывание и все в одном инструменте). возможно и для терраформа уже есть что-то похожее и удобное.
CFN почти не пользуюсь, но CDK на TS это просто совсем другой уровень удобства. Начиная с поддержки TS в VSCode c autocompletion и подсветкой ошибок и прочего и заканчивая примитивами высокого уровня, когда условный сервис можно задеплоить в ECS одной строкой кода.
Еще меня очень бесит писать руками IAM policies, а в CDK можно просто указать что то типа ddbtable.grantRead(lambdaFunction) и он сгенерит все нужные policies.
Код terraform, написанный для одного облака, as is не перенести на другое. Так что выбор между tf и cf для работы с AWS это более дело вкуса. Ну и как человек, много написавший в cf, не могу не выделить сильной стороны (может даже единственной реально хорошей) у данного решения: документация, она просто выше всех похвал.
Стоит заметить, что в реальной жизни CFN используют совсем уж махровые заказчики, где нужно конфиг прибить гвоздями, подписать кровью и никогда не менять. В остальном CDK дает огромную фору по удобству и скорости разработки (код на CDK в среднем в ДЕСЯТЬ раз компактнее)
Основные принципы и обучающее руководство по AWS CloudFormation