Cuando empecé a usar CDK venía de escribir YAML para CloudFormation y, honestamente, ya no aguantaba más la indentación y los errores silenciosos. CDK cambió mi forma de trabajar porque me permite definir infraestructura con TypeScript, que es lo que escribo todos los días.
En este artículo te cuento el flujo que uso para arrancar un proyecto desde cero.
Instalación
npm install -g aws-cdk
cdk --version
Luego inicializas el proyecto:
mkdir mi-stack && cd mi-stack
cdk init app --language typescript
Estructura que me funciona
Lo primero que hago es separar los stacks por responsabilidad. No mezclo la base de datos con la capa de cómputo en el mismo archivo porque después es imposible hacer cdk destroy sin tumbar cosas que no querías.
lib/
network-stack.ts
database-stack.ts
compute-stack.ts
bin/
app.ts
Un stack mínimo pero útil
import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';
import { Construct } from 'constructs';
export class StorageStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
new s3.Bucket(this, 'AssetsBucket', {
versioned: true,
encryption: s3.BucketEncryption.S3_MANAGED,
removalPolicy: cdk.RemovalPolicy.RETAIN,
});
}
}
El flujo que uso día a día
-
cdk synthpara revisar el CloudFormation generado antes de aplicar. -
cdk diffpara ver qué va a cambiar. -
cdk deploycuando estoy seguro.
El paso 2 me ha salvado más veces de las que puedo contar, sobre todo cuando trabajo con stacks compartidos.
Cierre
CDK no es magia, al final genera CloudFormation. Pero la diferencia entre escribir 200 líneas de YAML y 20 líneas de TypeScript con autocompletado e IntelliSense cambia completamente la experiencia. Si vienes de Terraform, la curva es menor de lo que parece.
Top comments (0)