Инфраструктура как код в AWS: CloudFormation и CDK

CloudFormation: декларативное ядро

CloudFormation — нативный для AWS сервис «инфраструктура как код». Ты пишешь template — документ в YAML или JSON, — который описывает желаемое конечное состояние инфраструктуры. У template есть несколько верхнеуровневых секций: Resources (единственная обязательная — собственно ресурсы AWS, которые надо создать), Parameters (типизированные входы, которые ты передаёшь при деплое), Mappings (статические таблицы соответствий, например регион к AMI), Conditions (булевы значения, которые включают или нет ресурс или свойство) и Outputs (значения, которые стек экспортирует, например ID VPC, который импортирует другой стек). Ты описываешь, что хочешь; CloudFormation сам разбирается с порядком, зависимостями и вызовами API.

Stack — это развёрнутый экземпляр template, работающая совокупность ресурсов, которые CloudFormation создал и теперь управляет ими как единым целым. Отношение точь-в-точь как у класса и объекта: один template может стоять за многими стеками (dev, staging, prod). И важнейшее: CloudFormation управляет состоянием за тебя. Нет файла состояния, который надо хранить, блокировать или повредить, — AWS отслеживает, какие реальные ресурсы принадлежат какому стеку, на своей стороне. Это и есть самое большое операционное отличие от сторонних IaC-инструментов.

AWSTemplateFormatVersion: "2010-09-09"
Description: A bucket and a table, parameterized by environment.

Parameters:
  Environment:
    Type: String
    AllowedValues: [dev, prod]
    Default: dev

Conditions:
  IsProd: !Equals [!Ref Environment, prod]

Resources:
  AssetsBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "myapp-assets-${Environment}"
      VersioningConfiguration:
        Status: !If [IsProd, Enabled, Suspended]

  SessionsTable:
    Type: AWS::DynamoDB::Table
    Properties:
      # Переименование DynamoDB-таблицы требует REPLACEMENT — новая таблица, данные исчезают.
      TableName: !Sub "sessions-${Environment}"
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: sessionId
          AttributeType: S
      KeySchema:
        - AttributeName: sessionId
          KeyType: HASH

Outputs:
  BucketName:
    Value: !Ref AssetsBucket
    Export:
      Name: !Sub "${Environment}-assets-bucket"

Когда ты обновляешь стек, CloudFormation сравнивает новый template с текущим стеком и формирует change set — превью того, что именно произойдёт, до того как что-либо изменится. Change set классифицирует каждый ресурс как add, modify или remove, а для изменений сообщает update behavior: No interruption (ресурс обновляется на месте без простоя), Some interruption (обновляется на месте, но с кратким перебоем) или — опасный вариант — Replacement (CloudFormation создаёт новый ресурс, затем удаляет старый). Replacement зависит от свойства: некоторые свойства просто нельзя изменить на живом ресурсе, поэтому их изменение пересоздаёт его. Для базы данных или stateful-хранилища Replacement может быть разрушительным — новый ресурс пуст, а старый удаляется. Весь смысл change set в том, чтобы показать это слово Replacement до выполнения, а не после.

CloudFormation также откатывается при сбое: если любой ресурс в обновлении падает, он пытается вернуть каждый ресурс в прежнее состояние. У этой страховки есть собственный печально известный режим отказа — UPDATE_ROLLBACK_FAILED, когда сам откат не может завершиться (часто из-за того, что ресурс изменили в обход), и стек заклинивает, пока ты вручную не починишь или не пропустишь проблемный ресурс.

Drift: когда реальность перестаёт совпадать с template

У той правки в консоли в 2 ночи из вступления есть имя: drift. CloudFormation определяет drift как расхождение фактической конфигурации стека с ожидаемой, записанной в template. Любое изменение вне CloudFormation — через консоль, CLI или другой инструмент, что часто называют ClickOps, — может его внести. Drift detection сравнивает живые значения свойств каждого поддерживаемого ресурса с template и сообщает статус: IN_SYNC, когда они совпадают, MODIFIED, когда значение свойства отличается, DELETED, когда ресурс удалили в обход, и NOT_CHECKED для типов ресурсов, не поддерживающих drift detection. Стек в статусе DRIFTED, если дрейфнул хотя бы один ресурс.

Drift не просто косметика. Как показало вступление, следующий деплой делает diff относительно картины мира template, поэтому изменение в обход может быть молча откачено — или, хуже, может столкнуться со свойством Replacement и уничтожить данные. Зрелые команды гоняют drift detection по расписанию и считают любой DRIFTED-стек инцидентом, потому что это значит, что код больше не источник истины. Дисциплина, делающая IaC ценным, — это не править в обход него; drift detection — сигнализация, которая сообщает, что кто-то это сделал.

Для крупных систем template разбивают: nested stacks (родительский стек, чьи ресурсы сами являются дочерними стеками) и cross-stack references (Outputs одного стека экспортируются и импортируются другим через Fn::ImportValue) позволяют собирать инфраструктуру без одного неуправляемого файла на 3000 строк. Учти один острый угол: drift detection на родительском стеке не рекурсирует во вложенные — drift на каждый nested stack ты определяешь напрямую.

CDK: настоящий язык, компилирующийся в CloudFormation

Писать YAML руками быстро становится больно: нет циклов, нет настоящих условий, нет типов, и интент из пяти ресурсов раздувается в сотни строк. AWS Cloud Development Kit (CDK) — это ответ: ты описываешь инфраструктуру на языке общего назначения (TypeScript, Python, Java, C#, Go), используя constructs — переиспользуемые строительные блоки. Конструкты бывают трёх уровней: L1 (классы Cfn*) — голые соответствия один-к-одному ресурсам CloudFormation; L2 оборачивают их разумными, безопасными умолчаниями и хелперами (s3.Bucket, который сам настраивает шифрование и removal policy); L3 — это patterns, которые собирают много ресурсов в один мнениевый блок (ApplicationLoadBalancedFargateService, который поднимает VPC, кластер, балансировщик и сервис разом).

Ключевое озарение — в механизме: cdk synth синтезирует твой код в template CloudFormation, а cdk deploy передаёт этот template в CloudFormation для провижининга. CDK — это генератор более высокого уровня поверх CloudFormation, а не его замена. Ты по-прежнему получаешь стеки, change sets, откат и drift detection — потому что фактически запускается всё тот же стек CloudFormation. Несколько десятков строк CDK рутинно выдают template на 500+ строк и 50+ ресурсов.

import { Stack, StackProps, RemovalPolicy } from "aws-cdk-lib";
import { Construct } from "constructs";
import * as s3 from "aws-cdk-lib/aws-s3";
import * as dynamodb from "aws-cdk-lib/aws-dynamodb";

export class AppStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const isProd = id.includes("prod");

    // L2 конструкт: разумные, безопасные умолчания (шифрование по умолчанию включено).
    new s3.Bucket(this, "AssetsBucket", {
      versioned: isProd,                      // настоящий boolean, а не CFN Condition
      removalPolicy: isProd
        ? RemovalPolicy.RETAIN                // защищаем данные prod при удалении стека
        : RemovalPolicy.DESTROY,
    });

    new dynamodb.Table(this, "SessionsTable", {
      partitionKey: { name: "sessionId", type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
    });
  }
}
// `cdk synth` превращает это в template CloudFormation выше (и больше);
// `cdk deploy` прогоняет его через CloudFormation как стек.

Трейдофф реален. CDK даёт тебе циклы, условия, проверку типов, юнит-тесты и переиспользуемые абстракции — весь инструментарий языка программирования, применённый к инфраструктуре. Стоит это шага сборки, сгенерированных template, которые бывают большими и плохо читаемыми, и обязанности понимать выдаваемый CloudFormation. Голый CloudFormation — противоположность: более многословный и менее переиспользуемый, зато абсолютно прозрачный — что написал, то и развернётся, без слоя синтеза, о котором надо рассуждать.