Cloud Tagging Strategi i 2026: Komplet Guide til Omkostningsallokering på Tværs af AWS, Azure og GCP

Hvorfor 82% af alle virksomheder spilder penge på grund af dårlig tagging

Okay, lad os starte med den ubehagelige sandhed: tagging er nok det mest undervurderede emne inden for cloud-omkostningsstyring. Ikke fordi det er raketvidenskab — det er det virkelig ikke. Men fordi det kræver disciplin, konsistens og (her kommer den svære del) organisatorisk opbakning at gøre det ordentligt. Og de fleste virksomheder gør det bare ikke.

Tallene taler for sig selv. Ifølge en Virtana-undersøgelse fra 2025-2026 har 82% af virksomheder med offentlige cloud-workloads pådraget sig unødvendige omkostninger — primært på grund af dårlig ressourcesynlighed. Og den dårlige synlighed? Den skyldes næsten altid mangelfuld eller inkonsekvent tagging.

Det bliver værre.

Data fra State of FinOps 2026-rapporten viser, at organisationer uden en formel tagging-strategi typisk spilder 35-40% af deres cloud-budget. Med en struktureret tagging-praksis falder det til 20-25%. For en virksomhed der bruger 100.000 kr. om måneden på cloud, er det forskellen mellem 35.000 kr. og 20.000 kr. i spild. Hver eneste måned. Det er ikke ligefrem småpenge.

I denne artikel gennemgår vi en komplet, praktisk guide til cloud tagging i 2026. Du får konkrete kodeeksempler til AWS, Azure og GCP, Terraform-konfigurationer til automatisk håndhævelse, og en trinvis strategi til at implementere chargeback og showback i din organisation. Så lad os komme i gang.

Hvad er cloud tags egentlig, og hvorfor er de fundamentale for FinOps?

En cloud tag er i bund og grund et simpelt nøgle-værdi-par der tilknyttes en ressource som metadata. For eksempel: Environment: production eller Team: analytics. Tags ændrer ikke ressourcens adfærd — de beskriver den, intet mere.

Men netop den beskrivelse er fundamentet for alt andet i FinOps:

• Omkostningsallokering: Uden tags kan du simpelthen ikke tildele omkostninger til de rigtige teams, projekter eller afdelinger
• Chargeback og showback: Tags er forudsætningen for at kunne vise (showback) eller fakturere (chargeback) omkostninger til de ansvarlige
• Anomalidetektion: Utaggede ressourcer er reelt usynlige for dine overvågningsværktøjer
• Automatisering: Tags driver automatisk nedlukning af dev-miljøer om natten, auto-scaling-politikker og livscyklusstyring
• Compliance og governance: Tags hjælper med at spore ressourcer i forhold til regulatoriske krav

Tænk på tags som cloud-verdenens inventarliste. Uden den ved du ikke, hvad du ejer, hvem der ejer det, eller hvad det koster. Ærligt talt, jeg har set organisationer bruge måneder på avancerede FinOps-værktøjer, bare for at opdage at deres data var ubrugelig — fordi tagging-fundamentet manglede.

De 5-8 obligatoriske tags enhver organisation har brug for

En af de mest klassiske fejl er at starte med 20 obligatoriske tags. Det virker aldrig. Seriøst, aldrig.

Teams skubber imod, datakvaliteten styrtdykker, og folk begynder at skrive "test" eller "asdf" i tag-værdier bare for at komme igennem deployment-processen. Vi har alle set det ske.

Start med 5-8 obligatoriske tags. Det er sweet spot ifølge FinOps Foundation. Her er en anbefalet baseline:

Tag-nøgle	Formål	Eksempelværdi
Environment	Miljøidentifikation og politikhåndhævelse	production, staging, development
Owner	Ansvarlig person eller team til hændelseshåndtering	[email protected]
Application	Hvilken applikation ressourcen tilhører	webshop-backend
CostCenter	Omkostningssted til chargeback og finans	CC-4521
Project	Projekt- eller initiativtilknytning	q1-migration
ManagedBy	Hvordan ressourcen er provisioneret	terraform, manual

De tre absolut kritiske tags ifølge FinOps-eksperter er: CostCenter (til chargeback), Environment (til politikhåndhævelse), og Owner (til ansvarlighed og hændelsesstyring). Har du kun kapacitet til tre? Start med dem.

Terraform: Automatisk tagging med default_tags

Den bedste måde at sikre konsekvent tagging er at bygge det ind i din Infrastructure as Code (IaC). Med Terraform kan du bruge default_tags i AWS-provideren, så alle ressourcer automatisk arver de obligatoriske tags:

# providers.tf — Automatisk tagging for alle AWS-ressourcer
provider "aws" {
  region = var.aws_region

  default_tags {
    tags = {
      Environment = var.environment
      Owner       = var.team_email
      Application = var.application_name
      CostCenter  = var.cost_center
      Project     = var.project_name
      ManagedBy   = "terraform"
    }
  }
}

# variables.tf
variable "environment" {
  type        = string
  description = "Deployment-miljø"
  validation {
    condition     = contains(["production", "staging", "development", "sandbox"], var.environment)
    error_message = "Environment skal være: production, staging, development eller sandbox."
  }
}

variable "team_email" {
  type        = string
  description = "Ansvarligt teams e-mail"
  validation {
    condition     = can(regex("^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$", var.team_email))
    error_message = "Owner skal være en gyldig e-mailadresse."
  }
}

variable "cost_center" {
  type        = string
  description = "Omkostningssted-kode"
  validation {
    condition     = can(regex("^CC-[0-9]{4,6}$", var.cost_center))
    error_message = "CostCenter skal følge formatet CC-XXXX (f.eks. CC-4521)."
  }
}

Med denne konfiguration tagges hver eneste ressource du opretter med Terraform automatisk — EC2-instanser, S3-buckets, RDS-databaser, Lambda-funktioner. Du behøver ikke huske det. Det bare sker. Og det er præcis det der gør IaC-tilgangen så kraftfuld.

Tilføj variabelvalidering for formatkontrol

Læg mærke til validation-blokkene ovenfor. De forhindrer, at nogen deployer med et tomt CostCenter eller et forkert format. Det lyder måske småt, men det er præcis den slags der forhindrer tag-sprawl — altså situationen hvor du ender med 47 variationer af "production" (prod, Prod, PROD, production, Production...). Ja, det sker i virkeligheden.

AWS: Tag Policy-håndhævelse med Organizations

Terraform default_tags er fantastisk, men det dækker kun ressourcer oprettet via Terraform. Hvad med alt det andet? Ressourcer oprettet via konsollen, CLI eller andre værktøjer? Der har du brug for AWS Organizations Tag Policies.

Opret en Tag Policy med Terraform

# tag-policy.tf — Organisationsniveau tag-håndhævelse
resource "aws_organizations_policy" "mandatory_tags" {
  name        = "mandatory-tags-policy"
  description = "Håndhæver obligatoriske tags på tværs af alle konti"
  type        = "TAG_POLICY"

  content = jsonencode({
    tags = {
      Environment = {
        tag_key = { "@@assign" = "Environment" }
        tag_value = {
          "@@assign" = [
            "production",
            "staging",
            "development",
            "sandbox"
          ]
        }
        enforced_for = {
          "@@assign" = [
            "ec2:instance",
            "ec2:volume",
            "rds:db",
            "s3:bucket",
            "lambda:function",
            "elasticloadbalancing:loadbalancer"
          ]
        }
      }
      CostCenter = {
        tag_key = { "@@assign" = "CostCenter" }
        enforced_for = {
          "@@assign" = [
            "ec2:instance",
            "ec2:volume",
            "rds:db",
            "s3:bucket"
          ]
        }
      }
      Owner = {
        tag_key = { "@@assign" = "Owner" }
        enforced_for = {
          "@@assign" = [
            "ec2:instance",
            "rds:db",
            "lambda:function"
          ]
        }
      }
    }
  })
}

# Tilknyt politikken til rod-OU
resource "aws_organizations_policy_attachment" "mandatory_tags" {
  policy_id = aws_organizations_policy.mandatory_tags.id
  target_id = aws_organizations_organization.main.roots[0].id
}

Nyt i 2025-2026: IaC-native Tag Policy Enforcement

Her er noget der virkelig er værd at bemærke. AWS har i 2025-2026 introduceret en kraftig udvidelse: IaC-native håndhævelse af Tag Policies. Det betyder, at tag-politikker nu valideres før ressourcer oprettes — uanset om du bruger CloudFormation, Terraform eller Pulumi.

Organisationer der har implementeret dette rapporterer en 95% reduktion i tag-overtrædelser. Det er ret vildt.

For CloudFormation aktiverer du det sådan:

# Aktivér i CloudFormation
aws cloudformation activate-type \
  --type HOOK \
  --type-name AWS::TagPolicies::TaggingComplianceValidator \
  --execution-role-arn arn:aws:iam::123456789012:role/TagPolicyHookRole

Aktivér Cost Allocation Tags

En vigtig detalje som overraskende mange overser: det er ikke nok bare at sætte tags på ressourcer. Du skal også aktivere dem som cost allocation tags i AWS Billing-konsollen, ellers dukker de simpelthen ikke op i dine omkostningsrapporter:

# Aktivér tags til omkostningsrapportering
aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status \
    Key=Environment,Status=Active \
    Key=CostCenter,Status=Active \
    Key=Owner,Status=Active \
    Key=Application,Status=Active \
    Key=Project,Status=Active

Bemærk: Det tager op til 24 timer, før nyligt aktiverede cost allocation tags begynder at dukke op i dine omkostningsrapporter. Og de er ikke retroaktive — de viser kun data fra aktiveringstidspunktet og fremad. Det er en af de ting man gerne ville have vidst fra starten.

Azure: Tag-håndhævelse med Azure Policy

Azure har et ret stærkt policy-system, der gør tag-håndhævelse til en naturlig del af governance-stakken. Du kan både blokere deployment af ressourcer uden tags og automatisk tilføje tags til eksisterende ressourcer. Det er en fleksibilitet som er svær at finde andre steder.

Bloker ressourcer uden obligatoriske tags

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "anyOf": [
        {
          "field": "tags['Environment']",
          "exists": "false"
        },
        {
          "field": "tags['CostCenter']",
          "exists": "false"
        },
        {
          "field": "tags['Owner']",
          "exists": "false"
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

Automatisk tag-arv fra ressourcegrupper

Her er noget der overrasker mange: I Azure arves tags ikke automatisk fra ressourcegrupper til de underliggende ressourcer. Man skulle tro det, men nej. Heldigvis kan du håndhæve det med Azure Policy og Modify-effekten:

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "tags['CostCenter']",
          "exists": "false"
        },
        {
          "value": "[resourceGroup().tags['CostCenter']]",
          "notEquals": ""
        }
      ]
    },
    "then": {
      "effect": "modify",
      "details": {
        "roleDefinitionIds": [
          "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
        ],
        "operations": [
          {
            "operation": "addOrReplace",
            "field": "tags['CostCenter']",
            "value": "[resourceGroup().tags['CostCenter']]"
          }
        ]
      }
    }
  }
}

Med denne politik arver alle ressourcer automatisk CostCenter-tagget fra deres ressourcegruppe. Og med en remediation task kan du også anvende det retroaktivt på eksisterende, utaggede ressourcer. Smart, ikke?

GCP: Labels og Organization Policy

GCP gør det lidt anderledes (selvfølgelig gør de det). De opererer med to begreber: labels og tags. Og nej, de er ikke det samme.

• Labels: Nøgle-værdi-par til metadata og omkostningssporing. Kan ikke bruges til politikhåndhævelse.
• Tags: Nøgle-værdi-par der kan styre IAM-betingelser og firewall-regler. Kan bruges til politikhåndhævelse.

Til omkostningsallokering bruger du primært labels. Til governance og adgangsstyring bruger du tags. Det er vigtigt at holde styr på forskellen.

Obligatoriske labels med Terraform

# GCP-projekt med obligatoriske labels
resource "google_project" "main" {
  name       = var.project_name
  project_id = var.project_id
  org_id     = var.org_id

  labels = {
    environment = var.environment
    cost_center = var.cost_center
    owner       = var.owner
    application = var.application
    managed_by  = "terraform"
  }
}

# Compute Engine med labels
resource "google_compute_instance" "web" {
  name         = "web-server-01"
  machine_type = "e2-medium"
  zone         = "europe-west1-b"

  labels = {
    environment = "production"
    cost_center = "cc-4521"
    owner       = "platform-team"
    application = "webshop"
  }

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
    }
  }

  network_interface {
    network = "default"
  }
}

GCP-begrænsninger du skal kende

GCP har nogle begrænsninger for tags og labels som er værd at have i baghovedet:

• Maksimalt 1.000 tag-nøgler per organisation
• Maksimalt 1.000 værdier per nøgle
• Maksimalt 50 nøgle-værdi-par per ressource
• Labels kan ikke bruges direkte til politikhåndhævelse — brug tags til det

I praksis er det sjældent en begrænsning med 50 nøgle-værdi-par per ressource. Hvis du har brug for mere end det, har du sandsynligvis et andet problem.

OPA og Sentinel: Policy-as-Code til tag-håndhævelse

For at tilføje et ekstra lag af sikkerhed (og ærligt talt, lidt ro i maven) kan du bruge Open Policy Agent (OPA) med Rego eller HashiCorp Sentinel til at validere tags i din CI/CD-pipeline, før Terraform overhovedet kan køre apply.

OPA/Rego-politik til obligatoriske tags

# enforce-tags.rego
package terraform.tags

required_tags := ["Environment", "Owner", "CostCenter", "Application"]

# Afvis ressourcer der mangler obligatoriske tags
deny[msg] {
  resource := input.resource_changes[_]
  resource.change.actions[_] == "create"
  tags := resource.change.after.tags
  tag := required_tags[_]
  not tags[tag]
  msg := sprintf(
    "Ressource %s mangler obligatorisk tag: %s",
    [resource.address, tag]
  )
}

# Afvis tomme tag-værdier
deny[msg] {
  resource := input.resource_changes[_]
  resource.change.actions[_] == "create"
  tags := resource.change.after.tags
  tag := required_tags[_]
  tags[tag] == ""
  msg := sprintf(
    "Ressource %s har tomt tag: %s",
    [resource.address, tag]
  )
}

Og her er hvordan du integrerer det i din CI/CD-pipeline:

# .gitlab-ci.yml eller GitHub Actions
validate-tags:
  script:
    - terraform plan -out=tfplan
    - terraform show -json tfplan > plan.json
    - opa eval --data enforce-tags.rego --input plan.json "data.terraform.tags.deny"
    - |
      VIOLATIONS=$(opa eval --data enforce-tags.rego \
        --input plan.json \
        --format raw \
        "count(data.terraform.tags.deny)")
      if [ "$VIOLATIONS" -gt 0 ]; then
        echo "Tag-overtrædelser fundet! Deployment blokeret."
        exit 1
      fi

Det smukke ved denne tilgang er, at uanset hvad nogen prøver at deploye, fanges manglende tags automatisk. Ingen diskussioner, ingen undtagelser.

Fra tags til handling: Showback og chargeback

Tags i sig selv er bare metadata. De gør ingenting af sig selv. Værdien kommer, når du bruger dem til at drive showback og chargeback — de to mekanismer, der skaber reel økonomisk ansvarlighed i din organisation.

Showback vs. chargeback: Hvad er forskellen?

Aspekt	Showback	Chargeback
Definition	Viser teams deres omkostninger uden at fakturere dem	Faktisk fakturering af omkostninger til teams/afdelinger
Formål	Bevidsthed og gennemsigtighed	Økonomisk ansvarlighed
Kompleksitet	Lav — kræver kun tagging og rapportering	Høj — kræver integration med finans og bogføring
Anbefalet start	Start her	Implementér efter showback er modent

FinOps Foundation anbefaler denne rækkefølge: Showback → Omkostningsallokering → Chargeback. Start med at vise teams deres forbrug. Når datakvaliteten er høj nok (og det tager typisk et par måneder), kan du begynde at fakturere.

Praktisk eksempel: AWS Cost Explorer med tags

# Hent omkostninger grupperet efter CostCenter-tag
aws ce get-cost-and-usage \
  --time-period Start=2026-02-01,End=2026-03-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --group-by Type=TAG,Key=CostCenter \
  --output json | jq '.ResultsByTime[0].Groups[] |
    {CostCenter: .Keys[0], Amount: .Metrics.UnblendedCost.Amount}'

Output:

{
  "CostCenter": "CostCenter$CC-4521",
  "Amount": "2847.32"
}
{
  "CostCenter": "CostCenter$CC-1103",
  "Amount": "1523.67"
}
{
  "CostCenter": "CostCenter$",
  "Amount": "892.15"
}

Bemærk den sidste linje — CostCenter$ uden værdi. Det er dine utaggede ressourcer. 892,15 USD i omkostninger du ikke kan allokere til nogen. Det er præcis derfor tagging-compliance er så vigtigt at få styr på.

Håndtering af delte omkostninger

Her er en realitet vi ikke kan ignorere: ikke alle omkostninger kan tagges direkte til ét team. Delte ressourcer — som en fælles database, netværksinfrastruktur, support-kontrakter eller monitoring-værktøjer — kræver en shared cost-strategi.

FinOps Foundation anbefaler at følge KISS-princippet (Keep It Simple Stupid). Der er tre gængse metoder:

• Proportional allokering: Fordel delte omkostninger baseret på hvert teams andel af det samlede forbrug. Bruger Team A 60% af compute, betaler de 60% af de delte omkostninger.
• Forbrugsbaseret allokering: Brug faktiske forbrugsmetrics — GB overført, CPU-timer, antal requests — til at fordele omkostninger. Mere præcist, men kræver bedre instrumentering.
• Fast fordeling: Del ligeligt mellem teams eller efter en foruddefineret nøgle. Simpelt, men potentielt uretfærdigt.

Min anbefaling? Start med proportional allokering. Det er den bedste balance mellem nøjagtighed og kompleksitet — og det er nemt at forklare til finans.

Audit og compliance: Find dine utaggede ressourcer

Selv med den bedste tagging-strategi i verden vil der altid være ressourcer der slipper igennem. Det er bare sådan det er. Derfor har du brug for en løbende audit-proces.

AWS Config: Find utaggede ressourcer

# AWS Config-regel der markerer utaggede EC2-instanser
resource "aws_config_config_rule" "required_tags" {
  name = "required-tags-ec2"

  source {
    owner             = "AWS"
    source_identifier = "REQUIRED_TAGS"
  }

  input_parameters = jsonencode({
    tag1Key   = "Environment"
    tag2Key   = "CostCenter"
    tag3Key   = "Owner"
    tag4Key   = "Application"
  })

  scope {
    compliance_resource_types = ["AWS::EC2::Instance"]
  }
}

Hurtig CLI-audit af utaggede ressourcer

# Find EC2-instanser uden CostCenter-tag
aws ec2 describe-instances \
  --query "Reservations[].Instances[?!Tags || !contains(Tags[].Key, 'CostCenter')].[InstanceId, State.Name, LaunchTime]" \
  --output table

# Find S3-buckets uden Environment-tag
for bucket in $(aws s3api list-buckets --query "Buckets[].Name" --output text); do
  tags=$(aws s3api get-bucket-tagging --bucket "$bucket" 2>/dev/null | \
    jq -r '.TagSet[] | select(.Key=="Environment") | .Value' 2>/dev/null)
  if [ -z "$tags" ]; then
    echo "MANGLER TAG: $bucket"
  fi
done

Azure Resource Graph: Tværgående tag-audit

# Kusto-forespørgsel i Azure Resource Graph
az graph query -q "
  Resources
  | where tags !has 'CostCenter' or tags !has 'Environment'
  | project name, type, resourceGroup, subscriptionId
  | order by type asc
" --output table

KPI'er til at måle din tagging-strategi

Du kan ikke forbedre, hvad du ikke måler. (Ja, det er et cliché, men det er sandt.) Her er de tre vigtigste KPI'er for din tagging-strategi:

KPI	Definition	Mål
Tagging Compliance Rate	Procentdel af ressourcer med alle obligatoriske tags	>95% inden for 6 måneder
Untagged Resource Cost	Samlet omkostning for ressourcer uden korrekte tags	<5% af samlet spend
Cost Attribution Coverage	Procentdel af omkostninger der kan allokeres til en ejer	>90% som udgangspunkt

Vis disse KPI'er på et dashboard og gennemgå dem månedligt. Og her er et lille tip fra praksis: peer pressure virker bemærkelsesværdigt godt. Når teams kan se, at de har den laveste tagging-compliance, har de en stærk tendens til at rette op. Ingen vil være det team der ligger sidst.

Implementeringsplan: Fra nul til 95% compliance på 90 dage

Her er en realistisk plan til at implementere en tagging-strategi i din organisation. Den er testet i praksis, og den virker — men den kræver commitment fra ledelsen.

Uge 1-2: Fundament

• Definér 5-8 obligatoriske tags med accepterede værdier
• Dokumentér tagging-politikken og del den med alle teams
• Implementér default_tags i Terraform-providere
• Aktivér cost allocation tags i AWS Billing / Azure Cost Management

Uge 3-4: Håndhævelse

• Deploy AWS Tag Policies / Azure Policy / GCP Organization Policy
• Tilføj OPA/Rego-validering i CI/CD-pipelines
• Opsæt AWS Config-regler eller Azure Resource Graph-forespørgsler til audit

Uge 5-8: Oprydning

• Kør audit og identificér alle utaggede ressourcer
• Tag eksisterende ressourcer — start med de dyreste (det giver mest værdi hurtigst)
• Kør Azure Policy remediation tasks for retroaktiv tagging
• Implementér showback-dashboards til hvert team

Uge 9-12: Optimering

• Mål tagging compliance rate og untagged resource cost ugentligt
• Justér politikker baseret på feedback fra teams
• Overvej chargeback-implementering når compliance er over 90%
• Automatisér rapportering og notifikationer ved tag-overtrædelser

Ofte stillede spørgsmål om cloud tagging

Hvad er forskellen mellem chargeback og showback i FinOps?

Showback viser teams deres cloud-omkostninger uden at fakturere dem — det skaber bevidsthed og gennemsigtighed. Chargeback går et skridt videre og fakturerer faktisk omkostningerne til de ansvarlige teams eller afdelinger via den interne bogføring. De fleste organisationer starter med showback og går over til chargeback, når datakvaliteten og tagging-compliance er tilstrækkeligt høj — typisk over 90%.

Hvor mange tags bør man have som obligatoriske?

FinOps Foundation anbefaler 5-8 obligatoriske tags som sweet spot. Færre end 5 giver ikke tilstrækkelig synlighed, mens mere end 8-10 ofte fører til tag-sprawl og dårlig datakvalitet. Start med Environment, Owner og CostCenter som de tre absolut kritiske, og udvid derfra baseret på organisationens behov.

Kan man opnå 100% tagging compliance?

Kort svar: i praksis, nej. 100% compliance er meget svært at opnå, fordi visse cloud-ressourcer simpelthen ikke understøtter tags (f.eks. nogle managed services og interne AWS-ressourcer). Sigt efter over 90% som et realistisk initialt mål og over 95% på længere sigt. Det vigtigste er, at de utaggede ressourcer udgør mindre end 5% af det samlede spend.

Hvordan håndterer man delte omkostninger, som ikke kan tagges til ét team?

Delte omkostninger som netværksinfrastruktur, support-kontrakter og fælles databaser kan fordeles via tre metoder: proportional allokering (baseret på hvert teams andel af samlet forbrug), forbrugsbaseret allokering (baseret på faktiske metrics som CPU-timer eller datatrafik) eller fast fordeling. Start med proportional allokering — det er den bedste balance mellem nøjagtighed og enkelthed.

Hvad koster det at have utaggede cloud-ressourcer?

Ifølge data fra 2025-2026 spilder organisationer uden en tagging-strategi typisk 35-40% af deres cloud-budget — sammenlignet med 20-25% for organisationer med struktureret tagging. Utaggede ressourcer er usynlige for omkostningsstyringsværktøjer, hvilket betyder at de hverken kan optimeres, allokeres eller overvåges effektivt. For en virksomhed med et månedligt cloud-spend på 500.000 kr. kan forskellen mellem god og dårlig tagging være over 75.000 kr. om måneden. Det er seriøse penge.