Lambda Task Timed Out: VPC-, Timeout- und Memory-Konfiguration beheben

Ihr Monitoring hat gerade diesen Alarm ausgelöst:

{
  "errorType": "Task timed out after 30.03 seconds",
  "requestId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE"
}

Oder Sie sehen dies in den CloudWatch Logs:

REPORT RequestId: a1b2c3d4-5678-90ab-cdef-EXAMPLE
Duration: 900015.67 ms
Billed Duration: 900000 ms
Memory Size: 128 MB
Max Memory Used: 125 MB
Status: timeout

Lambda-Timeouts gehören zu den irreführendsten Fehlern in AWS, weil der erste Instinkt immer ist, den Code zu untersuchen. Aber nach meiner Erfahrung haben die meisten Lambda-Timeout-Probleme nichts mit der Code-Performance zu tun. Sie werden durch VPC-Netzwerk-Fehlkonfigurationen, unzureichenden Speicher, der zu CPU-Throttling führt, oder nicht erreichbare Downstream-Services verursacht.

Hier sind die fünf Ursachen, die ich am häufigsten antreffe, zusammen mit den Diagnoseschritten und CLI-Befehlen zur Identifizierung und Behebung jeder einzelnen.

Ursache 1: Lambda in VPC ohne NAT Gateway

Dies ist die einzeln häufigste Ursache für Lambda-Timeouts, und ich sehe sie mindestens einmal im Monat bei Kundenprojekten. Wenn Sie eine Lambda-Funktion in eine VPC platzieren, erstellt sie ein Elastic Network Interface (ENI) in den angegebenen Subnets. Wenn diese Subnets private Subnets ohne Route zu einem NAT Gateway sind, hat die Funktion keinen Internetzugang — und kann keinen AWS-Service-Endpunkt außerhalb der VPC erreichen.

Die Funktion schlägt nicht sofort fehl. Sie versucht eine Verbindung herzustellen, wartet auf den TCP-Timeout und überschreitet schließlich den Lambda-Timeout. Die Fehlermeldung sagt nichts über Netzwerkprobleme aus.

Diagnose

Prüfen Sie zunächst die VPC-Konfiguration der Lambda-Funktion:

aws lambda get-function-configuration \
  --function-name my-function \
  --query '{
    VpcConfig: VpcConfig,
    Timeout: Timeout,
    MemorySize: MemorySize
  }'

Dann prüfen Sie die Routentabelle für die Subnets, die die Funktion verwendet:

# Routentabelle des Subnets abrufen
aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-0abc123" \
  --query 'RouteTables[0].Routes[*].{
    Destination: DestinationCidrBlock,
    Target: GatewayId || NatGatewayId || TransitGatewayId,
    State: State
  }' \
  --output table

Wenn die einzige Route die lokale VPC-Route ist (10.0.0.0/16 -> local), hat das Subnet keinen Internetzugang. Sie benötigen eine Route zu einem NAT Gateway für das Ziel 0.0.0.0/0.

Überprüfen Sie auch, ob das NAT Gateway existiert und im Status available ist:

aws ec2 describe-nat-gateways \
  --filter "Name=vpc-id,Values=vpc-0abc123" \
  --query 'NatGateways[*].{
    ID: NatGatewayId,
    State: State,
    SubnetId: SubnetId,
    PublicIp: NatGatewayAddresses[0].PublicIp
  }' \
  --output table

Lösung

Erstellen Sie ein NAT Gateway in einem öffentlichen Subnet und fügen Sie eine Route vom privaten Subnet hinzu:

# Elastic IP zuweisen
ALLOC_ID=$(aws ec2 allocate-address --domain vpc --query 'AllocationId' --output text)

# NAT Gateway in einem öffentlichen Subnet erstellen
NAT_ID=$(aws ec2 create-nat-gateway \
  --subnet-id subnet-public123 \
  --allocation-id "$ALLOC_ID" \
  --query 'NatGateway.NatGatewayId' \
  --output text)

echo "Warte auf NAT Gateway..."
aws ec2 wait nat-gateway-available --nat-gateway-ids "$NAT_ID"

# Routentabelle des privaten Subnets abrufen
RT_ID=$(aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=subnet-private123" \
  --query 'RouteTables[0].RouteTableId' \
  --output text)

# Standardroute über NAT Gateway hinzufügen
aws ec2 create-route \
  --route-table-id "$RT_ID" \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id "$NAT_ID"

Wenn Ihre Funktion nur auf AWS-Services zugreifen muss (S3, DynamoDB, SQS, etc.) und nicht auf das öffentliche Internet, verwenden Sie VPC-Endpoints statt eines NAT Gateways — sie sind günstiger und haben geringere Latenz.

Ursache 2: Unzureichender Speicher verursacht CPU-Throttling

Lambda weist CPU-Leistung proportional zum Speicher zu. Eine Funktion mit 128 MB Speicher bekommt einen Bruchteil einer vCPU, während eine Funktion mit 1769 MB eine volle vCPU erhält. Wenn Ihre Funktion CPU-intensive Arbeit durchführt — JSON-Parsing, Datentransformation, kryptografische Operationen — wird eine niedrige Speichereinstellung die CPU drosseln und die Funktion deutlich langsamer als erwartet laufen lassen.

Diagnose

Prüfen Sie die Speicherkonfiguration und die tatsächliche Speichernutzung:

aws lambda get-function-configuration \
  --function-name my-function \
  --query '{MemorySize: MemorySize, Timeout: Timeout}'

Dann fragen Sie CloudWatch Logs Insights nach Speichernutzungsmustern ab:

filter @type = "REPORT"
| stats avg(@maxMemoryUsed/@memorySize * 100) as avg_mem_pct,
        max(@maxMemoryUsed/@memorySize * 100) as max_mem_pct,
        avg(@duration) as avg_duration_ms,
        max(@duration) as max_duration_ms
by bin(1h)
| sort @timestamp desc
| limit 24

Wenn avg_mem_pct über 70% liegt oder die Dauer im Verhältnis zu dem, was der Code benötigen sollte, hoch ist, ist der Speicher wahrscheinlich der Engpass.

Lösung

Verwenden Sie AWS Lambda Power Tuning, ein Open-Source-Tool, um die optimale Speichereinstellung zu finden. Als schnelle Lösung verdoppeln Sie den Speicher und beobachten die Auswirkung:

aws lambda update-function-configuration \
  --function-name my-function \
  --memory-size 512

Vergleichen Sie die Dauern vorher und nachher:

filter @type = "REPORT"
| stats avg(@duration) as avg_ms,
        pct(@duration, 95) as p95_ms,
        avg(@maxMemoryUsed) as avg_mem_mb
by datefloor(@timestamp, 1h)
| sort @timestamp desc
| limit 48

Oft reduziert eine Erhöhung des Speichers von 128 MB auf 512 MB die Ausführungszeit um 60-70%, was die Kosten tatsächlich senken kann, da Sie nach GB-Sekunden abgerechnet werden.

Ursache 3: Security Group blockiert ausgehenden Traffic

Lambda-Funktionen in einer VPC verwenden die angegebene Security Group für ihre ENIs. Wenn die Security Group ausgehenden Traffic auf den erforderlichen Ports nicht zulässt, kann die Funktion keine Downstream-Services erreichen.

Diagnose

Prüfen Sie die Ausgangsregeln der Security Group:

aws ec2 describe-security-groups \
  --group-ids sg-0abc123 \
  --query 'SecurityGroups[0].{
    GroupId: GroupId,
    GroupName: GroupName,
    IngressRules: IpPermissions[*].{
      Protocol: IpProtocol,
      FromPort: FromPort,
      ToPort: ToPort,
      Sources: IpRanges[*].CidrIp
    },
    EgressRules: IpPermissionsEgress[*].{
      Protocol: IpProtocol,
      FromPort: FromPort,
      ToPort: ToPort,
      Destinations: IpRanges[*].CidrIp
    }
  }'

Wenn die Egress-Regeln Port 443 (für HTTPS zu AWS-Services) oder den Port Ihres Downstream-Services nicht einschließen, ist das das Problem.

Lösung

Fügen Sie die erforderlichen Ausgangsregeln hinzu:

# HTTPS ausgehend erlauben (für AWS-API-Aufrufe)
aws ec2 authorize-security-group-egress \
  --group-id sg-0abc123 \
  --ip-permissions IpProtocol=tcp,FromPort=443,ToPort=443,IpRanges='[{CidrIp=0.0.0.0/0}]'

# Datenbank-Port ausgehend erlauben (z.B. PostgreSQL)
aws ec2 authorize-security-group-egress \
  --group-id sg-0abc123 \
  --ip-permissions IpProtocol=tcp,FromPort=5432,ToPort=5432,IpRanges='[{CidrIp=10.0.0.0/16}]'

Ursache 4: Fehlende VPC-Endpoints für AWS-Services

Wenn Ihre Lambda-Funktion in einer VPC ist und AWS-Services wie DynamoDB, S3, SQS oder Secrets Manager aufruft, benötigt sie einen Netzwerkpfad zu diesen Services. Ohne NAT Gateway oder VPC-Endpoint werden diese Aufrufe durch Timeout fehlschlagen.

VPC-Endpoints sind NAT Gateways für den Zugriff auf AWS-Services vorzuziehen, weil sie den Traffic im AWS-Netzwerk halten, günstiger sind und geringere Latenz bieten.

Diagnose

Listen Sie bestehende VPC-Endpoints in Ihrer VPC auf:

aws ec2 describe-vpc-endpoints \
  --filters "Name=vpc-id,Values=vpc-0abc123" \
  --query 'VpcEndpoints[*].{
    ID: VpcEndpointId,
    Service: ServiceName,
    Type: VpcEndpointType,
    State: State
  }' \
  --output table

Wenn Ihre Funktion DynamoDB aufruft, aber kein com.amazonaws.us-east-1.dynamodb-Endpoint existiert, müssen Sie einen erstellen.

Lösung

Erstellen Sie die erforderlichen VPC-Endpoints. Für Gateway-Endpoints (S3, DynamoDB):

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123 \
  --service-name com.amazonaws.us-east-1.dynamodb \
  --route-table-ids rtb-private123

Für Interface-Endpoints (SQS, Secrets Manager, SSM, etc.):

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc123 \
  --vpc-endpoint-type Interface \
  --service-name com.amazonaws.us-east-1.secretsmanager \
  --subnet-ids subnet-private123 subnet-private456 \
  --security-group-ids sg-0abc123 \
  --private-dns-enabled

Ursache 5: Timeout zu niedrig für Cold Starts

Lambda-Cold-Starts fügen der ersten Aufrufung nach einer Inaktivitätsperiode Latenz hinzu. Wenn Ihre Funktion in einer VPC ist, sind Cold Starts länger, weil AWS ein ENI erstellen oder anhängen muss. Wenn die Funktion auch schwere SDKs, Datenbankverbindungspools oder ML-Modelle während der Init-Phase initialisiert, kann der Cold Start einen erheblichen Teil des Timeouts verbrauchen.

Diagnose

Identifizieren Sie Cold-Start-Dauern mit CloudWatch Logs Insights:

filter @type = "REPORT"
| fields @initDuration as cold_start_ms, @duration as exec_ms, @timestamp
| filter ispresent(@initDuration)
| stats avg(cold_start_ms) as avg_cold_ms,
        max(cold_start_ms) as max_cold_ms,
        avg(exec_ms) as avg_exec_ms,
        count(*) as cold_starts
by bin(1d)
| sort @timestamp desc
| limit 14

Wenn max_cold_ms + avg_exec_ms nahe an oder über Ihrem Timeout liegt, verursachen Cold Starts die Timeouts.

Lösung

Erhöhen Sie den Timeout, um Cold Starts zu berücksichtigen, und erwägen Sie Provisioned Concurrency für latenzempfindliche Funktionen:

# Timeout erhöhen
aws lambda update-function-configuration \
  --function-name my-function \
  --timeout 60

# Provisioned Concurrency aktivieren (hält Instanzen warm)
aws lambda put-provisioned-concurrency-config \
  --function-name my-function \
  --qualifier prod \
  --provisioned-concurrent-executions 5

Optimieren Sie auch den Initialisierungscode. Verschieben Sie die Erstellung von SDK-Clients und Datenbankverbindungen in den Modulbereich (außerhalb der Handler-Funktion), damit sie über Aufrufe hinweg wiederverwendet werden.

Erweitertes Debugging: Lambda Insights und X-Ray

Wenn die Ursache aus den Basisprüfungen nicht ersichtlich ist, aktivieren Sie Lambda Insights und X-Ray Tracing für detaillierte Performance-Daten.

Lambda Insights aktivieren

aws lambda update-function-configuration \
  --function-name my-function \
  --layers arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:52

Lambda Insights liefert CPU-Nutzung, Speicherauslastung, Netzwerkdurchsatz und Disk-I/O-Metriken pro Aufruf. Dies ist wesentlich, um zwischen CPU-Throttling und Netzwerkproblemen zu unterscheiden.

X-Ray Tracing aktivieren

aws lambda update-function-configuration \
  --function-name my-function \
  --tracing-config Mode=Active

X-Ray zeigt Ihnen genau, wo die Zeit während jedes Aufrufs verbracht wird — DNS-Auflösung, TCP-Verbindung, TLS-Handshake und Antwortwartezeit für jeden Downstream-Aufruf. Wenn der Trace eine lange TCP-Verbindungszeit zu einem bestimmten Endpunkt zeigt, ist das Problem die Netzwerkkonnektivität, nicht der Code.

Diagnostischer Entscheidungsbaum

Hier ist die Reihenfolge, die ich beim Debuggen von Lambda-Timeouts befolge:

# 1. Funktionskonfiguration abrufen
aws lambda get-function-configuration \
  --function-name FUNCTION_NAME \
  --query '{VPC:VpcConfig,Timeout:Timeout,Memory:MemorySize}'

# 2. Bei VPC: Routentabellen auf NAT-Gateway-Route prüfen
aws ec2 describe-route-tables \
  --filters "Name=association.subnet-id,Values=SUBNET_ID" \
  --query 'RouteTables[0].Routes'

# 3. Security-Group-Egress-Regeln prüfen
aws ec2 describe-security-groups \
  --group-ids SG_ID \
  --query 'SecurityGroups[0].IpPermissionsEgress'

# 4. VPC-Endpoints prüfen
aws ec2 describe-vpc-endpoints \
  --filters "Name=vpc-id,Values=VPC_ID" \
  --query 'VpcEndpoints[*].ServiceName'

# 5. Speicherauslastung in CloudWatch prüfen
# (Logs Insights-Abfrage aus Ursache 2 verwenden)

# 6. Cold-Start-Dauern prüfen
# (Logs Insights-Abfrage aus Ursache 5 verwenden)

Präventionsstrategien

Lambda nicht in eine VPC setzen, wenn es nicht nötig ist

Dies ist die effektivste Präventionsstrategie. Wenn Ihre Funktion nicht auf Ressourcen innerhalb einer VPC zugreifen muss (wie eine RDS-Datenbank oder einen ElastiCache-Cluster), platzieren Sie sie nicht in einer VPC. Funktionen außerhalb einer VPC haben standardmäßig Internetzugang und haben nie ENI-bezogene Cold Starts.

VPC-Endpoints statt NAT Gateways verwenden, wenn möglich

Wenn Ihre Funktion nur AWS-Services aufruft, sind VPC-Endpoints günstiger und zuverlässiger als NAT Gateways. Ein NAT Gateway kostet ca. 32 USD/Monat plus Datenverarbeitungsgebühren. VPC-Interface-Endpoints kosten ca. 7,30 USD/Monat pro AZ.

Timeout auf mindestens 2x der erwarteten Dauer setzen

Wenn Ihre Funktion normalerweise in 5 Sekunden abgeschlossen wird, setzen Sie den Timeout auf mindestens 10-15 Sekunden, um Cold Starts und temporäre Latenzspitzen zu berücksichtigen. Setzen Sie ihn aber nicht auf das Maximum von 900 Sekunden "für alle Fälle" — das würde dazu führen, dass API Gateway bei 29 Sekunden ausläuft, während Ihre Lambda weiterlauft und Kosten verursacht.

Mit CloudWatch-Alarmen überwachen

Erstellen Sie Alarme für Dauer-Anomalien, damit Sie Timeout-Probleme erkennen, bevor es die Benutzer tun:

aws cloudwatch put-metric-alarm \
  --alarm-name "Lambda-my-function-Duration" \
  --metric-name Duration \
  --namespace AWS/Lambda \
  --statistic p95 \
  --period 300 \
  --threshold 10000 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 3 \
  --dimensions Name=FunctionName,Value=my-function \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:alerts \
  --treat-missing-data notBreaching

Brauchen Sie Hilfe bei der Optimierung Ihrer Lambda-Architektur?

Lambda-Timeout-Probleme sind ein Symptom tieferliegender Architekturentscheidungen — VPC-Design, Speicherzuweisungsstrategie und Service-Konnektivitätsmuster. Wir helfen Teams, Serverless-Architekturen zu entwerfen, die diese Fallstricke von Anfang an vermeiden. Wenn Ihre Lambda-Funktionen durch Timeouts ausfallen und Sie die Ursache nicht identifizieren können, oder wenn Sie eine Serverless-Migration planen und die Architektur von Anfang an richtig machen wollen, können wir helfen.

Kontaktieren Sie uns für eine kostenlose AWS-Beratung