Verktyg i praktiken: Terraform, OpenTofu, CloudFormation och Pulumi

Valet av IaC-verktyg beror på molnstrategi, befintlig kompetens och krav på öppen källkod. Här är en ärlig jämförelse baserad på vad Opsios team ser i produktion:

Opsios rekommendation: För de flesta svenska organisationer som kör multi-cloud eller planerar att göra det är Terraform (eller OpenTofu om ni vill undvika HashiCorps BSL-licens) det säkraste valet. Har ni en ren AWS-miljö och inga planer på Azure eller GCP kan CloudFormation vara enklare att drifta. Pulumi passar team med stark utvecklarbakgrund som föredrar att skriva infrastruktur i sitt vardagsspråk.

Managerad DevOps

Bästa praxis: Vad som skiljer fungerande IaC från kaos

Vi ser regelbundet organisationer som "kör IaC" men fortfarande har problem. Koden finns, men den är monolitisk, otestad och distribuerad manuellt. Här är de praxis som faktiskt gör skillnad:

Modulär arkitektur

Undvik en enda stor Terraform-konfiguration för hela organisationen. Bryt ner i moduler: en modul för VPC, en för EKS-kluster, en för RDS-instanser. Varje modul ska ha tydliga in- och utparametrar, vara testbar isolerat och versioneras separat.

Exempel på strukturregel vi tillämpar hos Opsios kunder:

```

infrastructure/

├── modules/

│ ├── networking/

│ ├── compute/

│ ├── database/

│ └── monitoring/

├── environments/

│ ├── dev/

│ ├── staging/

│ └── production/

└── global/

├── iam/

└── dns/

```

State-hantering — den vanligaste felkällan

Terraform state är den fil som mappar din kod till verkliga resurser. Förloras den, vet Terraform inte vad som redan existerar. Lagra state i en krypterad S3-bucket med DynamoDB-lås (AWS) eller Azure Storage Account med locking. Använd aldrig lokal state i team.

Policy-as-code med OPA och Sentinel

Att definiera infrastruktur i kod räcker inte — du behöver också kodifiera reglerna för vad som är tillåtet. Open Policy Agent (OPA) med Conftest eller HashiCorps Sentinel kan blockera resurser innan de skapas:

• Inga publika S3-buckets utan explicit godkännande
• Alla EC2-instanser måste ha kryptering aktiverad
• Resurser i eu-north-1 eller Sweden Central — aldrig utanför EU (kritiskt för GDPR och NIS2-efterlevnad)
• Alla resurser måste ha taggar för kostnadsallokering (FinOps-grundkrav)

Automatiserad testning

Kör terraform validate och terraform plan i CI/CD-pipelinen vid varje pull request. Använd verktyg som Checkov eller tfsec för statisk säkerhetsanalys. För avancerade team: Terratest för integrationstester som faktiskt provisionerar och river ner resurser i en sandlådemiljö.

Drift-detektering

Schemalägg terraform plan i er CI/CD-pipeline (exempelvis var 6:e timme) och larma om resultatet visar förändringar som inte matchar koden. Det avslöjar manuella ändringar som smugit sig in. Hos Opsio kopplar vi den här detekteringen till vårt NOC som agerar dygnet runt.

Cloud FinOps

IaC och säkerhet: NIS2, GDPR och spårbarhet

För svenska organisationer som omfattas av NIS2-direktivet (implementerat via svensk lag) ställer krav på dokumenterade processer för incidenthantering, riskanalys och åtkomstkontroll. IaC ger er:

• Fullständig ändringslogg — varje infrastrukturförändring finns i Git med tidsstämpel, författare och godkännare
• Reproducerbarhet — ni kan bevisa att produktionsmiljön ser ut exakt som den koddefinierade konfigurationen
• Automatisk regelefterlevnad — policy-as-code blockerar icke-kompatibla resurser före driftsättning, inte efter revision
• Snabb incidentrespons — rollback till senast kända fungerande tillstånd via Git revert + apply

Integritetsskyddsmyndigheten (IMY) granskar alltmer hur organisationer hanterar tekniska skyddsåtgärder. Att kunna visa en kodifierad, versionshanterad och automatiskt testad infrastruktur är en konkret demonstration av "lämpliga tekniska åtgärder" enligt GDPR artikel 32.

Molnsäkerhet

IaC som grund för FinOps och kostnadsoptimering

Kodifierad infrastruktur är en förutsättning för fungerande FinOps. Utan IaC saknar ni den maskinläsbara beskrivningen av vad som borde köras — och kan därmed inte jämföra med vad som faktiskt körs (och kostar).

Konkreta fördelar:

• Tagging i kod — kräv kostnadstaggar (team, projekt, miljö) som obligatoriska variabler i Terraform-moduler. Ingen resurs skapas utan dem.
• Right-sizing som kod — instanstyper definieras i variabler som kan uppdateras centralt baserat på faktisk användning.
• Automatisk nedstängning — definiera schemalagd avstängning av dev/test-miljöer direkt i IaC.
• Kostnadsestimering — verktyg som Infracost integreras i CI/CD och visar den beräknade månadskostnaden för varje pull request innan resursen skapas.

Flexeras State of the Cloud har konsekvent visat att molnkostnadsoptimering är organisationers främsta molnutmaning. Vår erfarenhet på Opsio bekräftar detta — de kunder som har störst kontroll över sina kostnader är utan undantag de som kör all infrastruktur som kod med obligatorisk tagging och automatiserade granskningstester.

Managerade molntjänster

Vanliga misstag vi ser — och hur du undviker dem

Manuella nödändringar som aldrig kodifieras. Någon fixar en akut brandkårsutryckning direkt i konsolen. Ändringen dokumenteras inte i kod. Nästa terraform apply skriver över fixen. Lösning: strikt "no-click-ops"-policy, IAM-roller som begränsar konsolåtkomst i produktion, och drift-detektering som larmar.

Monolitisk state. All infrastruktur i en enda state-fil. En enda apply tar 20 minuter och riskerar att påverka orelaterade resurser. Lösning: dela upp i separata state-filer per miljö och ansvarsområde (networking, compute, data).

Kopierad kod istället för moduler. Tre miljöer med identisk men manuellt kopierad kod. Ändring i en glöms i de andra. Lösning: versionerade moduler i ett internt modulregister.

Ingen testning i pipeline. Terraform-kod som aldrig körts genom plan före merge. Lösning: obligatorisk CI-pipeline som kör validate, plan, säkerhetsskanning och policy-check.

Hur Opsio arbetar med IaC åt våra kunder

Vårt tillvägagångssätt bygger på att IaC inte är ett projekt utan en kapabilitet som måste underhållas:

1. Inventering och kodifiering — vi kartlägger befintlig infrastruktur och skriver den i Terraform, inklusive import av existerande resurser

2. Modulbibliotek — vi bygger organisationsspecifika moduler med inbyggda säkerhetspolicyer och taggingkrav

3. CI/CD-integration — GitLab CI, GitHub Actions eller Azure DevOps med plan, test och apply-steg

4. Kontinuerlig övervakning — vårt NOC i Karlstad och Bangalore kör drift-detektering dygnet runt och eskalerar avvikelser

5. Kunskapsöverföring — vi lämnar inte över kod utan kontext. Era team tränas i att underhålla och vidareutveckla modulerna

Molnmigrering

Vanliga frågor

Vad är skillnaden mellan Terraform och CloudFormation?

Terraform (och dess fork OpenTofu) är molnagnostiskt och stödjer AWS, Azure, GCP och hundratals andra leverantörer via providers. CloudFormation är AWS-specifikt och har djupare integration med AWS-tjänster, men låser dig till en enda molnleverantör. Välj Terraform för multi-cloud eller hybrid, CloudFormation om du enbart kör AWS och vill ha tätast möjliga integration.

Hur kommer man igång med IaC i en organisation som aldrig använt det?

Börja med ett avgränsat projekt — exempelvis en staging-miljö eller en ny mikrotjänst. Välj Terraform med en remote state backend (S3 + DynamoDB eller Terraform Cloud). Skriv moduler för era vanligaste resurser, inför code review via pull requests och automatisera plan/apply i CI/CD. Skala sedan gradvis.

Är IaC säkert? Vi oroar oss för att exponera infrastrukturdetaljer i kod.

IaC ökar säkerheten jämfört med manuell hantering eftersom varje förändring granskas, loggas och kan automatiskt skannas mot policy. Hemligheter hanteras via secrets managers (AWS Secrets Manager, HashiCorp Vault), aldrig i klartext i koden. Kombinera med policy-as-code (OPA/Sentinel) för att blockera regelvidriga resurser innan de skapas.

Hur hanterar man drift mellan faktisk infrastruktur och IaC-kod?

Konfigurationsdrift uppstår när någon ändrar resurser manuellt utanför IaC-flödet. Lös det med terraform plan i schemalagda pipelines som larmar vid avvikelser, strikta IAM-policyer som begränsar manuella ändringar, och en kultur där all förändring går genom kod. Opsios NOC övervakar driftavvikelser åt våra kunder dygnet runt.

Vad kostar det att införa IaC?

Terraform och OpenTofu är open source och gratis. Kostnaden ligger i kompetensuppbyggnad och den initiala insatsen att kodifiera befintlig infrastruktur. Räkna med 2–6 veckor för ett medelstort team att bli produktivt. ROI:n kommer snabbt: eliminerade manuella fel, snabbare provisionering och möjlighet att reproducera hela miljöer på minuter istället för dagar.