Dit zou ik niet moeten doen

Samenvatting

AWS-infrastructuur loopt vast op onduidelijk eigenaarschap rond EKS, terwijl Terraform het beheer moet vastleggen.

AWS-infrastructuur en Terraform: wie voert het werk uit?

Een Reddit-gebruiker bouwt infrastructuur in AWS en liep eerder tegen een vaste werkwijze aan: nieuwe instances werden door DevOps of de servicedesk aangemaakt. Dit keer verwees de servicedesk de aanvrager echter terug naar zichzelf. RDS en OSS zijn inmiddels ingericht, maar EKS vormt nog een probleem.

De gebruiker voert al een week gesprekken met de servicedesk, management en een C-level-verantwoordelijke om vast te stellen wie de taak hoort uit te voeren. De infrastructuur wordt via Terraform uitgerold. Daardoor moet de gewenste inrichting uiteindelijk ook aan de Terraform-configuratie worden toegevoegd.

EKS maakt eigenaarschap zichtbaar

De kwestie gaat niet alleen over een ontbrekende EKS-configuratie. De blokkade ontstaat doordat niemand formeel vastlegt wie nieuwe infrastructuur aanmaakt, wie de configuratie beheert en wie verantwoordelijkheid draagt wanneer een implementatie vastloopt. RDS en OSS konden wel worden ingericht; EKS legt de onduidelijkheid scherper bloot.

Voor BI-professionals die AWS-diensten gebruiken, raakt dit direct aan de levering van dataomgevingen. Een rapportageomgeving kan technisch klaar lijken, terwijl een ontbrekende beslissing over beheer de volgende stap tegenhoudt. Terraform maakt de inrichting reproduceerbaar, maar bepaalt niet vanzelf wie wijzigingen mag goedkeuren of uitvoeren.

De casus laat ook zien dat zelfservice en centrale ondersteuning zonder duidelijke grens naast elkaar kunnen bestaan. De servicedesk verwijst door, terwijl de aanvrager niet weet of die formeel bevoegd is om de omgeving zelf te bouwen. Dat levert vooral overleg op in plaats van infrastructuur.

Concrete takeaway voor AWS-infrastructuur

Leg vóór de volgende Terraform-wijziging per AWS-dienst vast wie eigenaar is, wie de configuratie toevoegt en wie de wijziging goedkeurt. Noteer die afspraken naast de code, zodat EKS niet opnieuw blijft steken tussen servicedesk, DevOps en management.