Serverless Omkostningsoptimering i 2026: Sådan Reducerer Du de Skjulte Omkostninger i AWS Lambda, Azure Functions og Google Cloud Functions

Serverless Omkostningsoptimering i 2026: Sådan Reducerer Du de Skjulte Omkostninger i AWS Lambda, Azure Functions og Google Cloud Functions

Serverless computing blev lanceret med et simpelt løfte: betal kun for det, du bruger. Ingen servere at administrere, ingen idle-kapacitet at betale for, og en prismodel der skalerer perfekt med din arbejdsbyrde. Det lyder næsten for godt til at være sandt — og ærligt talt, det er det også, i hvert fald delvist.

Ifølge undersøgelser fra 2025-2026 opdager mellem 60% og 75% af organisationer, at deres serverless-regninger er 2-5 gange højere end forventet. En startup der forventede en månedlig regning på $500, ender med $2.500. En enterprise-virksomhed der migrerede til serverless for at spare penge, ser pludselig deres AWS-regning stige med 40%.

Hvad går galt?

Problemet ligger ikke i selve Lambda-funktionerne eller Azure Functions-udførelserne. Det ligger i det usynlige økosystem af tjenester der omgiver dem — API Gateway-omkostninger, CloudWatch Logs der vokser ukontrolleret, NAT Gateway-gebyrer, datatransfer-omkostninger og provisioned concurrency der bare kører løs døgnet rundt. Disse "skjulte" omkostninger kan udgøre op til 80% af den samlede serverless-regning. Ja, du læste rigtigt. 80%.

I denne artikel gennemgår vi en komplet guide til serverless omkostningsoptimering i 2026. Vi dækker prismodeller på tværs af de tre store cloud-udbydere, identificerer alle de skjulte omkostninger, og præsenterer seks afprøvede strategier med praktiske kodeeksempler der kan reducere din serverless-regning med op til 60%.

Forstå Serverless Prismodeller

Før vi kan optimere noget som helst, skal vi forstå hvad vi egentlig betaler for. Alle tre store cloud-udbydere bruger en kombination af anmodningsgebyrer og compute-tid, men detaljerne varierer en hel del.

AWS Lambda Prismodel

AWS Lambda opkræver baseret på to dimensioner: antal anmodninger og varighed målt i GB-sekunder. En GB-sekund er én sekunds udførelse med 1 GB hukommelse allokeret.

• Anmodninger: $0,20 per 1 million anmodninger
• Varighed (x86): $0,0000166667 per GB-sekund
• Varighed (ARM/Graviton2): $0,0000133334 per GB-sekund — 20% billigere
• Gratis tier: 1 million anmodninger + 400.000 GB-sekunder per måned
• Provisioned Concurrency: $0,0000041667 per GB-sekund (altid-kørende kapacitet)

Azure Functions Prismodel

Azure Functions tilbyder flere hostingplaner, men de to mest relevante for serverless er Consumption og Flex Consumption.

• Consumption Plan - Udførelser: $0,20 per 1 million udførelser
• Consumption Plan - Varighed: $0,000016 per GB-sekund
• Gratis tier: 1 million udførelser + 400.000 GB-sekunder per måned
• Flex Consumption Plan: Tilbyder altid-klar instanser med reducerede cold starts, baseline-instanser fra $0,000016 per GB-sekund, on-demand skalering derudover
• Premium Plan (EP1): Fra ca. $155/måned for reserveret kapacitet med forudsigeligt workload

Google Cloud Functions Prismodel

Google Cloud Functions har to generationer med forskellige prismodeller:

• Gen 1 - Invokationer: $0,40 per 1 million invokationer (dobbelt så dyrt som AWS og Azure!)
• Gen 1 - Compute: $0,0000025 per GHz-sekund + $0,0000025 per GB-sekund
• Gen 2: Bygget på Cloud Run med vCPU- og hukommelsesbaseret prissætning: $0,00002400 per vCPU-sekund + $0,00000250 per GiB-sekund
• Gratis tier: 2 millioner invokationer, 400.000 GB-sekunder, 200.000 GHz-sekunder per måned

Prissammenligning: 10 Millioner Anmodninger per Måned

Lad os sammenligne de tre udbydere for et realistisk scenarie med 10 millioner anmodninger per måned, hver med 256 MB hukommelse og 200 ms gennemsnitlig varighed:

Komponent	AWS Lambda (x86)	AWS Lambda (ARM)	Azure Functions	GCF Gen 1
Anmodninger	$1,80	$1,80	$1,80	$3,60
Compute (GB-s)	$8,33	$6,67	$8,00	$2,50
Samlet (efter gratis tier)	~$3,46	~$1,80	~$3,13	~$2,65

Bemærk: Beregningen fratrækker de respektive gratis tiers. Priserne ser jo overkommelige ud, ikke? Men det her er kun compute-omkostningerne. De reelle omkostninger? De gemmer sig et helt andet sted.

De Skjulte Omkostninger ved Serverless

Okay, her begynder den virkelige historie. For de fleste serverless-applikationer udgør Lambda/Functions-compute kun 15-30% af den samlede regning. Resten er "støttetjenester" som rigtig mange teams glemmer at medregne.

API Gateway: Den Dyreste Dør

Hvis dine Lambda-funktioner betjener HTTP-trafik, har du sandsynligvis en API Gateway foran dem. AWS tilbyder to typer:

• REST API (v1): $3,50 per million anmodninger — inkluderer features som API-nøgler, brugsbegrænsning og WAF-integration
• HTTP API (v2): $1,00 per million anmodninger — 71% billigere, men med færre features

For 100 millioner API-kald per måned er forskellen markant: REST API koster $350, mens HTTP API koster $100. Det er $250 i besparelse — hver eneste måned — bare ved at skifte API-type. Og ofte er det eneste du mister, features som du alligevel ikke bruger.

CloudWatch Logs: Den Tavse Budgetmorder

Den her er lidt af en klassiker. Hver Lambda-funktion logger som standard til CloudWatch Logs. Prisen er $0,50 per GB indsamlet. Det lyder harmløst, indtil du indser at:

• En funktion der logger 1 KB per invokation med 10 millioner invokationer genererer ~10 GB logs = $5/måned
• Slår du debug-logging til (5-10 KB per invokation), stiger det til $25-50/måned per funktion
• Med 50 funktioner i produktion kan det hurtigt blive $1.250-2.500/måned bare for logs
• Standard-retention er uendelig — logs slettes simpelthen aldrig automatisk

NAT Gateway: Den Dyreste Netværksforbindelse

Hvis dine Lambda-funktioner kører i et VPC (f.eks. for at tilgå en RDS-database), har du brug for en NAT Gateway for at nå internettet. Og prisen er, skal vi sige, lidt barsk:

• Fast pris: ~$33 per måned per NAT Gateway (per availability zone)
• Databehandling: $0,045 per GB processeret
• Med 2 AZ'er og moderat trafik kan det hurtigt løbe op til $100-200/måned

Datatransfer og Egress

Udgående datatransfer fra AWS koster $0,09 per GB (de første 10 TB). For en API der returnerer gennemsnitligt 50 KB per respons med 10 millioner anmodninger, er det ~500 GB egress = $45/måned.

Orkestreringstjenester

• Step Functions (Standard): $0,025 per 1.000 tilstandsovergange. En workflow med 10 trin der kører 1 million gange = $250/måned
• Step Functions (Express): Baseret på varighed og antal anmodninger — markant billigere for korte workflows
• SQS: $0,40 per million anmodninger (efter første million gratis)
• SNS: $0,50 per million publiceringer
• EventBridge: $1,00 per million events

Databaseforbindelser

Lambda-funktioner opretter nye databaseforbindelser ved hver cold start. Med hundredvis af samtidige udførelser kan du hurtigt overbelaste din database. Løsningen — RDS Proxy — koster fra $0,015 per vCPU-time, hvilket typisk betyder $20-50 ekstra per måned.

Samlet Billede: Hvad Koster Serverless Reelt?

Så lad os se det fulde billede:

Omkostningskomponent	Månedlig pris (eksempel)	% af total
Lambda Compute	$50	8%
API Gateway (REST)	$175	28%
CloudWatch Logs	$125	20%
NAT Gateway	$100	16%
Data Transfer	$45	7%
Step Functions	$75	12%
SQS/SNS/EventBridge	$30	5%
RDS Proxy	$25	4%
Total	$625	100%

Lambda compute udgør kun 8% af den samlede regning. Otte procent! Det er derfor optimeringer der kun fokuserer på Lambda-konfiguration langt fra er nok. Vi er nødt til at tænke holistisk.

Strategi 1: Memory Right-Sizing med AWS Lambda Power Tuning

Den nemmeste optimering er ofte at allokere den rigtige mængde hukommelse til dine Lambda-funktioner. Mere hukommelse betyder mere CPU (lineær skalering), og det kan faktisk betyde hurtigere udførelse og lavere omkostninger — selv med en højere per-sekund pris. Det virker kontraintuitivt, men det er sådan det fungerer.

AWS Lambda Power Tuning

AWS har udviklet et open source-værktøj kaldet AWS Lambda Power Tuning der automatisk tester din funktion med forskellige hukommelseskonfigurationer og finder det optimale punkt.

Installer værktøjet via AWS Serverless Application Repository eller deploy det med SAR:

# Deploy Lambda Power Tuning via AWS SAR
aws serverlessrepo create-cloud-formation-change-set \
  --application-id arn:aws:serverlessrepo:us-east-1:451282441545:applications/aws-lambda-power-tuning \
  --stack-name lambda-power-tuning \
  --capabilities CAPABILITY_IAM

# Eller brug SAM CLI
sam deploy \
  --template-file template.yaml \
  --stack-name lambda-power-tuning \
  --capabilities CAPABILITY_IAM \
  --resolve-s3

Kør derefter tuning via Step Functions med følgende input:

{
  "lambdaARN": "arn:aws:lambda:eu-west-1:123456789:function:min-api-handler",
  "powerValues": [128, 256, 512, 1024, 1769, 2048, 3008],
  "num": 50,
  "payload": {
    "httpMethod": "GET",
    "path": "/api/products",
    "queryStringParameters": { "category": "electronics" }
  },
  "parallelInvocation": true,
  "strategy": "balanced"
}

De tre tilgængelige strategier er:

• cost: Finder den billigste konfiguration uanset hastighed
• speed: Finder den hurtigste konfiguration uanset pris
• balanced: Finder det bedste kompromis mellem pris og hastighed

Værktøjet genererer en visualisering der viser pris vs. varighed for hver hukommelseskonfiguration. Et typisk resultat ser sådan ud:

Hukommelse	Gns. Varighed	Gns. Pris	Bemærkning
128 MB	2.400 ms	$0,0000050	For langsom, timeout-risiko
256 MB	1.200 ms	$0,0000050	Halveret tid, samme pris
512 MB	620 ms	$0,0000052	God balance
1024 MB	350 ms	$0,0000058	Hurtig men dyrere
1769 MB	310 ms	$0,0000091	Fuld vCPU, marginal forbedring

I dette eksempel er 512 MB det balanced valg: næsten 4 gange hurtigere end 128 MB, men kun 4% dyrere. Det er en klassisk fejl at sætte funktioner til 128 MB for at "spare penge" — det giver ironisk nok ofte langsom udførelse og højere omkostninger på samme tid.

Automatiser Right-Sizing

Integrer Power Tuning i din CI/CD-pipeline for at validere hukommelseskonfiguration ved større ændringer:

# GitHub Actions workflow til automatisk power tuning
name: Lambda Power Tuning
on:
  pull_request:
    paths:
      - 'src/handlers/**'

jobs:
  power-tune:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy kandidatfunktion
        run: |
          sam build && sam deploy --stack-name pr-${{ github.event.number }}-test
      - name: Kør Power Tuning
        run: |
          aws stepfunctions start-execution \
            --state-machine-arn ${{ secrets.POWER_TUNING_ARN }} \
            --input '{
              "lambdaARN": "'$FUNCTION_ARN'",
              "powerValues": [256, 512, 1024, 1769],
              "num": 100,
              "strategy": "balanced"
            }'
      - name: Kommenter PR med resultater
        run: |
          gh pr comment ${{ github.event.number }} --body "$(cat tuning-results.md)"

Strategi 2: Skift til ARM/Graviton2

En af de enkleste og mest effektive optimeringer du kan lave, er at skifte dine Lambda-funktioner fra x86_64 til ARM (Graviton2). AWS tilbyder en 20% prisreduktion for ARM-baserede funktioner, og benchmarks viser konsekvent op til 34% bedre pris-ydeevne.

Det er i bund og grund gratis penge.

Hvornår Kan Du Skifte?

De fleste workloads kan skifte helt uden ændringer:

• Node.js, Python, Ruby, Java — alle kører nativt på ARM
• .NET 6+ og Go — fuldt understøttet
• Undtagelser: Binære afhængigheder kompileret til x86, eller custom runtimes med x86-specifikke binaries

SAM/CloudFormation Eksempel

# template.yaml - SAM skabelon med ARM-arkitektur
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Globals:
  Function:
    Runtime: nodejs20.x
    Architectures:
      - arm64          # Skift fra x86_64 til arm64
    MemorySize: 512
    Timeout: 30
    Tracing: Active

Resources:
  ProcessOrderFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: handlers/processOrder.handler
      Architectures:
        - arm64        # Graviton2/ARM
      Events:
        ApiEvent:
          Type: HttpApi
          Properties:
            Path: /orders
            Method: POST

  # Funktion der SKAL forblive på x86 (binær afhængighed)
  ImageProcessingFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: handlers/imageProcessing.handler
      Architectures:
        - x86_64       # Beholder x86 pga. native Sharp-binaries
      MemorySize: 1769
      Layers:
        - !Sub arn:aws:lambda:${AWS::Region}:123456789:layer:sharp-x86:1

Terraform Eksempel

# main.tf - Terraform konfiguration med ARM-arkitektur
resource "aws_lambda_function" "api_handler" {
  function_name = "api-handler"
  runtime       = "nodejs20.x"
  handler       = "index.handler"
  architectures = ["arm64"]   # Graviton2/ARM
  memory_size   = 512
  timeout       = 30

  filename         = data.archive_file.lambda_zip.output_path
  source_code_hash = data.archive_file.lambda_zip.output_base64sha256
  role             = aws_iam_role.lambda_exec.arn

  environment {
    variables = {
      NODE_ENV   = "production"
      TABLE_NAME = aws_dynamodb_table.orders.name
    }
  }

  tags = {
    Environment  = "production"
    CostCenter   = "platform-team"
    Architecture = "arm64"
  }
}

# Variabel til at styre arkitektur per miljø
variable "lambda_architecture" {
  description = "CPU-arkitektur for Lambda-funktioner"
  type        = string
  default     = "arm64"
  validation {
    condition     = contains(["arm64", "x86_64"], var.lambda_architecture)
    error_message = "Arkitektur skal være arm64 eller x86_64."
  }
}

Migreringsstrategi

Test altid grundigt i et staging-miljø før du skifter i produktion. Her er den fremgangsmåde vi anbefaler:

1. Deploy en ARM-version parallelt med den eksisterende x86-version
2. Brug Lambda aliases og weighted routing til at sende 10% trafik til ARM
3. Overvåg fejlrater, latenstider og funktionel korrekthed i 48-72 timer
4. Rul gradvist ud til 50%, så 100%

Strategi 3: Optimer API Gateway Omkostninger

API Gateway er ofte den største enkeltomkostning i en serverless-arkitektur. Her er tre konkrete ting du kan gøre:

Skift fra REST API til HTTP API

AWS HTTP API (v2) er 71% billigere end REST API (v1) og understøtter de fleste use cases. Her er en hurtig sammenligning:

Feature	REST API ($3,50/M)	HTTP API ($1,00/M)
Lambda-integration	Ja	Ja
JWT Authorizers	Via Custom Auth	Indbygget
CORS	Manuel konfiguration	Indbygget
API Keys / Usage Plans	Ja	Nej
Request Validation	Ja	Nej
WAF Integration	Ja	Nej
Caching	Ja (ekstra kostnad)	Nej (brug CloudFront)

Medmindre du specifikt har brug for WAF-integration, request validation eller API keys på gateway-niveau, er HTTP API næsten altid det rigtige valg. Og det er overraskende mange teams der kører REST API uden faktisk at bruge de ekstra features.

CloudFront Caching Foran API Gateway

Placer en CloudFront-distribution foran din API Gateway for at cache GET-anmodninger. Selv en kort TTL på bare 60 sekunder kan reducere API Gateway-kald markant:

# CloudFront distribution foran HTTP API
Resources:
  ApiCacheDistribution:
    Type: AWS::CloudFront::Distribution
    Properties:
      DistributionConfig:
        Origins:
          - Id: HttpApiOrigin
            DomainName: !Sub "${HttpApi}.execute-api.${AWS::Region}.amazonaws.com"
            CustomOriginConfig:
              OriginProtocolPolicy: https-only
        DefaultCacheBehavior:
          TargetOriginId: HttpApiOrigin
          ViewerProtocolPolicy: redirect-to-https
          CachePolicyId: !Ref ApiCachePolicy
          AllowedMethods: [GET, HEAD, OPTIONS]
          CachedMethods: [GET, HEAD]
        Enabled: true

  ApiCachePolicy:
    Type: AWS::CloudFront::CachePolicy
    Properties:
      CachePolicyConfig:
        Name: api-cache-60s
        DefaultTTL: 60
        MaxTTL: 300
        MinTTL: 0
        ParametersInCacheKeyAndForwardedToOrigin:
          CookiesConfig:
            CookieBehavior: none
          HeadersConfig:
            HeaderBehavior: whitelist
            Headers:
              - Authorization
          QueryStringsConfig:
            QueryStringBehavior: all
          EnableAcceptEncodingGzip: true

Med en cache hit rate på 70% for GET-anmodninger reducerer du API Gateway-omkostningerne med 70% for den trafik. CloudFront koster kun $0,0085 per 10.000 HTTPS-anmodninger — det er langt billigere end API Gateway.

Pre-Signed URLs til Filupload

Undgå at sende store filer (billeder, dokumenter osv.) gennem API Gateway og Lambda. Brug i stedet pre-signed S3 URLs:

// generateUploadUrl.js - Lambda der genererer pre-signed URL
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
import { getSignedUrl } from '@aws-sdk/s3-request-presigner';

const s3Client = new S3Client({ region: 'eu-west-1' });

export const handler = async (event) => {
  const { fileName, contentType } = JSON.parse(event.body);
  const key = `uploads/${Date.now()}-${fileName}`;

  const command = new PutObjectCommand({
    Bucket: process.env.UPLOAD_BUCKET,
    Key: key,
    ContentType: contentType,
  });

  // URL er gyldig i 15 minutter
  const uploadUrl = await getSignedUrl(s3Client, command, {
    expiresIn: 900,
  });

  return {
    statusCode: 200,
    body: JSON.stringify({ uploadUrl, key }),
  };
};

For en applikation der håndterer 100.000 filuploads per måned med en gennemsnitlig filstørrelse på 5 MB, sparer denne tilgang dig fra at sende 500 GB data gennem API Gateway og Lambda. Det er en besparelse på potentielt $50-100/måned.

Strategi 4: Kontroller CloudWatch Logs

CloudWatch Logs er en af de mest undervurderede omkostningsposter i serverless. Her er fire konkrete ting du kan gøre med det samme:

Sæt Retentionspolitikker

Standard-retention i CloudWatch er Never Expire, hvilket betyder at logs bare akkumuleres for evigt. Det er som at aldrig tømme papirkurven — det ender med at koste dig. Sæt altid en retention-policy:

# CloudFormation snippet til log-retention
Resources:
  ProcessOrderLogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub "/aws/lambda/${ProcessOrderFunction}"
      RetentionInDays: 14       # Behold logs i 14 dage
      Tags:
        - Key: Environment
          Value: production

For eksisterende log groups uden retentionspolitik kan du køre dette automatiserede script:

# setRetention.py - Sæt retention på alle log groups
import boto3

def handler(event, context):
    client = boto3.client('logs')
    default_retention_days = 14

    paginator = client.get_paginator('describe_log_groups')
    for page in paginator.paginate():
        for log_group in page['logGroups']:
            if 'retentionInDays' not in log_group:
                print(f"Sætter {default_retention_days}d retention på: "
                      f"{log_group['logGroupName']}")
                client.put_retention_policy(
                    logGroupName=log_group['logGroupName'],
                    retentionInDays=default_retention_days
                )
    return {"updated": True}

Brug Struktureret Logging og Reducer Volumen

// Struktureret logging med sampling i Node.js
import { Logger } from '@aws-lambda-powertools/logger';

const logger = new Logger({
  serviceName: 'order-service',
  logLevel: process.env.LOG_LEVEL || 'INFO',  // Brug INFO i prod
  sampleRateValue: 0.1,  // Log DEBUG for 10% af invokationer
});

export const handler = async (event, context) => {
  logger.addContext(context);

  // INFO logges altid
  logger.info('Ordre modtaget', { orderId: event.orderId });

  // DEBUG logges kun for 10% af invokationerne
  logger.debug('Fuld event payload', { event });

  try {
    const result = await processOrder(event);
    logger.info('Ordre behandlet', {
      orderId: event.orderId,
      totalAmount: result.total,
    });
    return result;
  } catch (error) {
    // ERROR logges altid med fuld kontekst
    logger.error('Fejl ved ordrebehandling', {
      orderId: event.orderId,
      error: error.message,
      stack: error.stack,
    });
    throw error;
  }
};

Eksporter Gamle Logs til S3

For logs der skal bevares i længere tid (compliance-krav og den slags), eksporter til S3 hvor storage koster $0,023/GB i stedet for CloudWatch Logs' $0,03/GB for opbevaring. Brug CloudWatch Logs Subscription Filters med Kinesis Data Firehose til automatisk eksport.

Strategi 5: Brug Savings Plans

AWS Compute Savings Plans gælder også for Lambda og kan give op til 17% rabat på compute-omkostninger mod en 1- eller 3-årig forpligtelse. Det er ikke verdens vildeste rabat, men det er stadig penge der tæller.

AWS Compute Savings Plans for Lambda

Savings Plans dækker Lambda-varighed (GB-sekunder), men ikke anmodninger. De fungerer ved at du forpligter dig til et minimumsbeløb per time:

• 1 år, ingen forudbetaling: Op til 17% rabat
• 1 år, delvis forudbetaling: Op til 17% rabat (lidt bedre effektiv sats)
• 3 år, fuld forudbetaling: Op til 17% rabat

Eksempel: Hvis din Lambda-compute koster $100/måned ($0,137/time), kan en Savings Plan på $0,114/time spare dig ~$17/måned. Over et år er det $204 i besparelse.

# Analysér Lambda-forbrug for at beregne optimal Savings Plan
aws ce get-cost-and-usage \
  --time-period Start=2026-01-01,End=2026-02-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" "UsageQuantity" \
  --filter '{
    "Dimensions": {
      "Key": "SERVICE",
      "Values": ["AWS Lambda"]
    }
  }' \
  --group-by Type=DIMENSION,Key=USAGE_TYPE

# Se Savings Plans anbefalinger
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS

Azure Reserved Instances for Premium Plan

Hvis du bruger Azure Functions Premium Plan (EP1/EP2/EP3) for forudsigelige workloads, kan du købe reserverede instanser med op til 38% rabat for en 3-årig forpligtelse. Det giver god mening når du har en konstant baseline af trafik suppleret med serverless skalering.

Hvornår Giver Savings Plans Mening?

Savings Plans er mest effektive når:

• Din Lambda-compute er stabil og forudsigelig (lav varians måned-til-måned)
• Du allerede har optimeret hukommelse og arkitektur — optimer først, forpligt dig derefter
• Du bruger nok til at besparelsen retfærdiggør forpligtelsen

Strategi 6: Arkitektoniske Mønstre til Omkostningsreduktion

De virkelig store besparelser kommer ofte fra arkitektoniske ændringer der eliminerer unødvendige invokationer helt. Det her er der, det for alvor bliver interessant.

Direkte Integrationer: Spring Lambda Over

API Gateway kan integrere direkte med mange AWS-tjenester uden en Lambda-funktion imellem. Hver undgået Lambda-invokation sparer både compute og anmodningsgebyrer:

# API Gateway direkte integration med DynamoDB
# Ingen Lambda nødvendig for simple CRUD-operationer
Resources:
  GetItemIntegration:
    Type: AWS::ApiGatewayV2::Integration
    Properties:
      ApiId: !Ref HttpApi
      IntegrationType: AWS_PROXY
      IntegrationSubtype: DynamoDB-GetItem
      PayloadFormatVersion: "1.0"
      CredentialsArn: !GetAtt ApiRole.Arn
      RequestParameters:
        TableName: !Ref OrdersTable
        Key:
          orderId:
            S: $request.path.orderId

S3 Event Notifications Direkte til SQS

I stedet for S3 → Lambda → SQS, brug S3 Event Notifications direkte til SQS. Hvorfor have en Lambda i midten, hvis alt den gør er at videreformidle beskeden?

# S3 sender direkte til SQS uden Lambda imellem
Resources:
  DataBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: data-ingestion-bucket
      NotificationConfiguration:
        QueueConfigurations:
          - Event: s3:ObjectCreated:*
            Queue: !GetAtt ProcessingQueue.Arn
            Filter:
              S3Key:
                Rules:
                  - Name: prefix
                    Value: uploads/
                  - Name: suffix
                    Value: .csv

  ProcessingQueue:
    Type: AWS::SQS::Queue
    Properties:
      QueueName: file-processing-queue
      VisibilityTimeout: 300

Step Functions Express Workflows vs. Standard

Step Functions Standard Workflows koster $0,025 per 1.000 tilstandsovergange. Express Workflows er baseret på varighed og antal udførelser og er markant billigere for korte, høj-frekvens workflows:

Scenarie	Standard Workflow	Express Workflow	Besparelse
1M udførelser, 5 trin	$125,00	~$6,00	95%
100K udførelser, 10 trin	$25,00	~$1,20	95%

Express Workflows har dog begrænsninger: maksimal varighed på 5 minutter, at-least-once execution semantik (vs. exactly-once for Standard), og ingen visuel status-tracking i konsollen. Men de er ideelle til data-processering, IoT-eventbehandling og realtidsberegninger.

Fan-Out Mønster med SQS Batch

I stedet for at invokere én Lambda per besked, brug SQS batch-processering til at behandle op til 10.000 beskeder per invokation:

# SAM template med SQS batch processing
Resources:
  BatchProcessorFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: batchProcessor.handler
      Runtime: nodejs20.x
      Architectures: [arm64]
      MemorySize: 512
      Timeout: 300
      Events:
        SQSEvent:
          Type: SQS
          Properties:
            Queue: !GetAtt ProcessingQueue.Arn
            BatchSize: 100
            MaximumBatchingWindowInSeconds: 30
            FunctionResponseTypes:
              - ReportBatchItemFailures

// batchProcessor.js - Effektiv batch-behandling
export const handler = async (event) => {
  const batchItemFailures = [];

  const results = await Promise.allSettled(
    event.Records.map(async (record) => {
      try {
        const body = JSON.parse(record.body);
        await processMessage(body);
      } catch (error) {
        console.error(`Fejl for besked ${record.messageId}:`, error.message);
        batchItemFailures.push({
          itemIdentifier: record.messageId,
        });
      }
    })
  );

  console.info(`Behandlet ${event.Records.length} beskeder, `
    + `${batchItemFailures.length} fejlede`);

  return { batchItemFailures };
};

Ved at behandle 100 beskeder per invokation i stedet for 1, reducerer du Lambda-invokationer med 99%. Det sparer både anmodningsgebyrer og cold start overhead.

FinOps for Serverless: Overvågning og Styring

Optimering er ikke noget du gør én gang og derefter glemmer. Du har brug for kontinuerlig overvågning og governance for at holde omkostningerne i skak over tid.

FOCUS-Specifikationen

FinOps Open Cost and Usage Specification (FOCUS) er en relativt ny standard fra FinOps Foundation der standardiserer omkostningsdata på tværs af cloud-udbydere. I 2026 understøtter både AWS, Azure og GCP FOCUS-format, hvilket gør det muligt at sammenligne serverless-omkostninger direkte på tværs af platforme.

FOCUS definerer standardiserede kolonner som BilledCost, EffectiveCost, PricingCategory (On-Demand, Commitment-Based osv.), ServiceName og ResourceId der gør cross-cloud analyse mulig.

Tagging-Strategi

Tags er fundamentet for omkostningstilskrivning. Uden dem famler du i blinde. Implementer en konsistent tagging-strategi:

# Obligatoriske tags for alle serverless-ressourcer
Globals:
  Function:
    Tags:
      Project: "order-platform"
      Environment: !Ref Environment
      Team: "platform-engineering"
      CostCenter: "CC-4521"
      ManagedBy: "terraform"

# Tag Enforcement med AWS Organizations SCP
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireCostCenterTag",
      "Effect": "Deny",
      "Action": [
        "lambda:CreateFunction",
        "lambda:TagResource"
      ],
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:RequestTag/CostCenter": "true"
        }
      }
    }
  ]
}

Anomaly Detection og Budgetter

# CloudFormation til budget og anomaly detection
Resources:
  ServerlessBudget:
    Type: AWS::Budgets::Budget
    Properties:
      Budget:
        BudgetName: serverless-monthly-budget
        BudgetType: COST
        TimeUnit: MONTHLY
        BudgetLimit:
          Amount: 500
          Unit: USD
        CostFilters:
          Service:
            - AWS Lambda
            - Amazon API Gateway
            - Amazon CloudWatch
            - AWS Step Functions
      NotificationsWithSubscribers:
        - Notification:
            NotificationType: ACTUAL
            ComparisonOperator: GREATER_THAN
            Threshold: 80
            ThresholdType: PERCENTAGE
          Subscribers:
            - SubscriptionType: EMAIL
              Address: [email protected]
        - Notification:
            NotificationType: FORECASTED
            ComparisonOperator: GREATER_THAN
            Threshold: 100
            ThresholdType: PERCENTAGE
          Subscribers:
            - SubscriptionType: SNS
              Address: !Ref AlertTopic

  CostAnomalyMonitor:
    Type: AWS::CE::AnomalyMonitor
    Properties:
      MonitorName: serverless-anomaly-monitor
      MonitorType: DIMENSIONAL
      MonitorDimension: SERVICE

Automatiseret Omkostningsrapportering

Opret en Lambda-funktion der genererer ugentlige omkostningsrapporter — det tager ikke lang tid at sætte op, og det giver et fantastisk overblik:

# cost_reporter.py - Ugentlig serverless omkostningsrapport
import boto3
import json
from datetime import datetime, timedelta

def handler(event, context):
    ce_client = boto3.client('ce')

    end = datetime.now().strftime('%Y-%m-%d')
    start = (datetime.now() - timedelta(days=7)).strftime('%Y-%m-%d')

    response = ce_client.get_cost_and_usage(
        TimePeriod={'Start': start, 'End': end},
        Granularity='DAILY',
        Metrics=['UnblendedCost'],
        Filter={
            'Dimensions': {
                'Key': 'SERVICE',
                'Values': [
                    'AWS Lambda',
                    'Amazon API Gateway',
                    'AmazonCloudWatch',
                    'AWS Step Functions',
                    'Amazon Simple Queue Service',
                ]
            }
        },
        GroupBy=[
            {'Type': 'DIMENSION', 'Key': 'SERVICE'}
        ]
    )

    total_cost = 0
    service_costs = {}
    for result in response['ResultsByTime']:
        for group in result['Groups']:
            service = group['Keys'][0]
            cost = float(group['Metrics']['UnblendedCost']['Amount'])
            service_costs[service] = service_costs.get(service, 0) + cost
            total_cost += cost

    report = f"Serverless Omkostningsrapport ({start} til {end})\n"
    report += f"Total: ${total_cost:.2f}\n\n"
    for service, cost in sorted(service_costs.items(),
                                  key=lambda x: x[1], reverse=True):
        pct = (cost / total_cost * 100) if total_cost > 0 else 0
        report += f"  {service}: ${cost:.2f} ({pct:.1f}%)\n"

    return {'statusCode': 200, 'body': report}

Praktisk Eksempel: En Komplet Optimeringsrejse

Lad os følge en optimeringsrejse for "NordicShop", en e-handelsplatform der kører en serverless-arkitektur på AWS. Vi viser deres udgangspunkt, de ændringer de foretog, og de resultater de opnåede.

Udgangspunkt: Før Optimering

NordicShop havde følgende serverless-arkitektur:

• 45 Lambda-funktioner (alle x86, 256 MB hukommelse)
• REST API Gateway med 50 millioner anmodninger/måned
• CloudWatch Logs med no-expiry retention
• Lambda-funktioner i VPC med NAT Gateway (2 AZ'er)
• Step Functions Standard Workflows for ordrebehandling (500K udførelser/måned, 8 trin)
• Debug-logging aktiveret i produktion (ups)
• Billeder uploaded via API Gateway → Lambda → S3

Omkostningspost	Månedlig pris (FØR)
Lambda Compute (x86, 256 MB)	$120
REST API Gateway (50M req)	$175
CloudWatch Logs (250 GB/mnd)	$125
CloudWatch Logs Storage (2 TB)	$60
NAT Gateway (2 AZ)	$100
Step Functions Standard	$100
Data Transfer	$65
SQS/SNS	$35
RDS Proxy	$40
TOTAL	$820/måned

Optimeringshandlinger

Uge 1-2: Hurtige gevinster

1. Skiftede til ARM/Graviton2 for alle 45 funktioner (42 fungerede direkte, 3 krævede opdaterede dependencies)
2. Satte CloudWatch Logs retention til 14 dage for alle log groups
3. Skiftede log-niveau fra DEBUG til INFO i produktion, med 10% sampling af DEBUG
4. Migrerede fra REST API til HTTP API (krævede ændring af JWT authorizer-implementering)

Uge 3-4: Arkitektoniske ændringer

1. Kørte Lambda Power Tuning på de 10 mest brugte funktioner — ændrede hukommelse til optimale værdier
2. Konverterede ordreprocessering fra Step Functions Standard til Express Workflows
3. Implementerede pre-signed URLs for billedupload
4. Erstattede 5 simple CRUD-Lambda-funktioner med direkte API Gateway → DynamoDB integrationer
5. Implementerede SQS batch processing med batch size 50 for notifikationssystemet

Uge 5-6: FinOps og langsigtet governance

1. Tilføjede CloudFront caching foran API'en for produktkatalog-endpoints (80% cache hit rate)
2. Købte Compute Savings Plan baseret på 60-dages historisk forbrug
3. Implementerede automatiserede omkostningsrapporter og anomaly detection
4. Oprettede tagging-enforcement via SCP'er

Resultater: Efter Optimering

Omkostningspost	FØR	EFTER	Besparelse
Lambda Compute	$120	$58	52%
API Gateway	$175	$15	91%
CloudWatch Logs Ingest	$125	$20	84%
CloudWatch Logs Storage	$60	$3	95%
NAT Gateway	$100	$100	0%
Step Functions	$100	$6	94%
Data Transfer	$65	$30	54%
SQS/SNS	$35	$12	66%
RDS Proxy	$40	$40	0%
Savings Plan rabat	—	-$10	—
TOTAL	$820	$274	67%

NordicShop reducerede deres serverless-regning med $546 per måned — det er $6.552 per år i besparelser. Og det her var for en relativt lille applikation. For enterprise-skala applikationer med 10-100x trafikken er besparelserne tilsvarende større.

De Vigtigste Læringer

• API Gateway var den største enkeltpost — og den nemmeste at optimere (skift til HTTP API)
• CloudWatch Logs akkumulering er et stille problem der vokser over tid uden at nogen lægger mærke til det
• Arkitektoniske ændringer (direkte integrationer, Express Workflows, batch processing) gav de største procentvise besparelser
• NAT Gateway og RDS Proxy er faste omkostninger der desværre er svære at eliminere
• Savings Plans bør altid være det sidste trin — optimer først, forpligt dig derefter

Avanceret Tip: Multi-Cloud Serverless Omkostningsoptimering

For organisationer der bruger flere cloud-udbydere, er det vigtigt at placere workloads strategisk baseret på pris og use case:

• Høj-frekvens, lav-compute funktioner: AWS Lambda ARM er typisk billigst pga. den lave GB-sekund pris og Graviton2-rabatten
• Compute-intensive funktioner: Google Cloud Functions Gen 1 har den laveste GHz-sekund pris, hvilket favoriserer CPU-tunge operationer
• Forudsigelige workloads: Azure Functions Premium Plan med reserverede instanser kan være op til 38% billigere end pay-per-use for stabile baseline-workloads
• Event-driven pipelines: Evaluer omkostningerne for hele kæden (event source → function → destination), ikke kun compute-prisen alene

Brug FOCUS-specifikationen til at normalisere omkostningsdata på tværs af udbydere og skab en samlet visning af dine serverless-omkostninger.

Tjekliste: Serverless Omkostningsoptimering

Brug denne tjekliste som udgangspunkt for din egen optimeringsrejse:

1. Compute-optimering
   • Kør Lambda Power Tuning på alle funktioner med mere end 100K invokationer/måned
   • Migrer alle kompatible funktioner til ARM/Graviton2
   • Overvej Provisioned Concurrency KUN for latens-kritiske funktioner med høj trafik
2. API Gateway-optimering
   • Migrer fra REST API til HTTP API, medmindre du har brug for WAF eller request validation
   • Implementer CloudFront caching for GET-endpoints
   • Brug pre-signed URLs for fil-uploads
3. Logging-optimering
   • Sæt retention på ALLE CloudWatch Log Groups (14-30 dage anbefalet)
   • Brug INFO-level i produktion med sampled DEBUG
   • Eksporter compliance-logs til S3 for langtidsopbevaring
4. Arkitektur-optimering
   • Brug direkte integrationer for simple CRUD-operationer
   • Konverter korte, hyppige workflows til Step Functions Express
   • Implementer SQS batch processing med ReportBatchItemFailures
5. Governance
   • Implementer konsistent tagging
   • Opsæt budgetter og anomaly detection
   • Generer ugentlige omkostningsrapporter
   • Evaluer Savings Plans efter 60 dages optimeret forbrug

Konklusion

Serverless computing leverer stadig på sit grundlæggende løfte: ingen servere at administrere, automatisk skalering og pay-per-use prissætning. Men "pay-per-use" betyder ikke automatisk "billigt". De skjulte omkostninger i API Gateway, CloudWatch Logs, NAT Gateway, datatransfer og orkestreringstjenester kan nemt overstige selve compute-omkostningerne med en faktor 5-10.

De seks strategier vi har gennemgået — memory right-sizing, ARM-migrering, API Gateway-optimering, log-kontrol, Savings Plans og arkitektoniske mønstre — er ikke teoretiske øvelser. De er afprøvede teknikker der konsekvent leverer 40-70% besparelser på den samlede serverless-regning.

Den vigtigste indsigt er denne: optimer holistisk, ikke kun Lambda. Kig på hele din serverless-arkitektur som et system af tjenester, og optimer de dyreste led først. API Gateway og CloudWatch Logs er næsten altid de lavthængende frugter. Arkitektoniske ændringer som direkte integrationer og batch processing giver de største langsigtede besparelser.

Start med at få overblik over dine faktiske omkostninger med korrekt tagging og omkostningsrapportering. Kør derefter de hurtige gevinster (ARM, log retention, HTTP API). Og først når din arkitektur er optimeret, bør du overveje Savings Plans for at låse yderligere rabatter fast.

Serverless i 2026 er modnet betydeligt, og med de rigtige FinOps-praksisser kan det levere den omkostningseffektivitet det altid har lovet. Det kræver bare at du kigger ud over den simple compute-pris og forstår det fulde billede.