AWS CDK of Terraform? Eerlijk advies
Teams die voor het eerst infrastructure as code opzetten op AWS vragen dit standaard: CDK of Terraform? Beide zijn gratis, beide werken goed, maar ze passen bij andere situaties.
Wat CDK voor je doet
AWS CDK (Cloud Development Kit) laat je infrastructuur schrijven in echte programmeertalen: TypeScript, Python, Java, Go en C#. Je schrijft klassen en methodes, geen YAML of HCL.
Het grote voordeel van CDK is de L2- en L3-constructbibliotheek. Een L2-construct geeft je een VPC of een S3-bucket met redelijke standaardwaarden, zonder dat je elk attribuut hoeft in te vullen. Een L3-construct (ook wel “patterns” genoemd) is een combinatie van diensten die samen een werkend patroon vormen, zoals een load-balanced Fargate-service met één CDK-klasse.
In de praktijk bespaart dat veel code. Een werkende ECS-taakdefinitie in ruwe CloudFormation kost honderd regels. Met CDK L3 zijn dat tien regels.
Nog een voordeel: CDK heeft volledige TypeScript-type-controle. Je kunt geen ongeldige waarden invullen zonder dat je editor je waarschuwt.
Wat Terraform voor je doet
Terraform is de standaard in de bredere infrastructure as code-wereld. HCL (HashiCorp Configuration Language) is leesbaar voor mensen die geen programmeur zijn, wat onboarding makkelijker maakt.
Het grootste voordeel van Terraform is dat het provider-agnostisch is. Eén toolchain beheert AWS, Azure, GCP, Cloudflare, Datadog en tientallen andere platforms. Als je organisatie meerdere clouds gebruikt, vermijdt Terraform dat je twee verschillende IaC-tools moet onderhouden.
De Terraform-community is ook groot. Voor vrijwel elke architectuurvraag is er al een module op het Terraform Registry.
Het drift-probleem van CDK
CDK compileert naar CloudFormation. Dat klinkt als een implementatiedetail, maar het heeft een praktisch nadeel: als iemand handmatig iets in de AWS-console wijzigt, weet CDK dat pas als je een diff draait. CloudFormation detecteert drift, maar lost hem niet automatisch op.
Terraform houdt zijn eigen state bij in een statefile. Dat brengt eigen hoofdpijn (wie bewaart de state, wat als hij corrupt raakt?), maar het geeft ook een duidelijker model: Terraform kent de gewenste en de werkelijke toestand en zegt precies wat er gaat veranderen voor je iets deployed.
Wanneer kies je CDK?
- Je team werkt al in TypeScript of Python en wil geen nieuwe taal leren.
- Je draait uitsluitend op AWS en verwacht dat dat de komende jaren zo blijft.
- Je wilt maximaal profiteren van L2/L3-constructs om minder boilerplate te schrijven.
- Je bouwt intern tooling waarbij type-veiligheid en hergebruik van code belangrijk zijn.
Wanneer kies je Terraform?
- Je gebruikt meerdere clouds of van plan bent dat te doen.
- Je wilt dat ook niet-ontwikkelaars de infrastructuurcode kunnen lezen en begrijpen.
- Je organisatie heeft al Terraform-kennis in huis en je wilt geen tweede tool.
- Je wilt een groot ecosysteem aan bestaande modules gebruiken.
CDK en Terraform kunnen ook naast elkaar bestaan. Sommige teams gebruiken Terraform voor de basisinfrastructuur (netwerken, accounts, DNS) en CDK voor de applicatiespecifieke resources. Dat werkt, maar voeg alleen complexiteit toe als je er een duidelijke reden voor hebt.