Lambda mit privatem RDS verbinden: VPC-Konfiguration, Subnets und Security Groups

Eine Lambda-Funktion kann plötzlich keine Verbindung mehr zu einer RDS-Instanz in einem privaten Subnet aufbauen — kein Timeout-Log, keine klare Fehlermeldung, nur ein generisches 'Connection timed out'. Wer Lambda und RDS zum ersten Mal in einer VPC-Umgebung kombiniert, tappt hier schnell in eine Falle: Die Funktion läuft, die Datenbank läuft, aber die Verbindung kommt nie an. Der Grund liegt fast immer in der VPC-Konfiguration der Lambda-Funktion selbst.

TL;DR: Lambda mit privatem RDS verbinden

Schritt	Was zu tun ist
1	Lambda-Funktion in dieselbe VPC wie RDS einbinden
2	Private Subnets (mindestens zwei AZs) für Lambda konfigurieren
3	Eigene Security Group für Lambda erstellen
4	RDS Security Group: Inbound-Regel für Lambda-SG auf DB-Port freischalten
5	IAM-Rolle der Lambda mit `AWSLambdaVPCAccessExecutionRole` ausstatten
6	Verbindung testen und CloudWatch Logs prüfen

Wie Lambda und RDS in einer VPC zusammenarbeiten

Ohne VPC-Konfiguration läuft eine Lambda-Funktion in einem von AWS verwalteten Netzwerk — vollständig außerhalb der eigenen VPC. Eine RDS-Instanz in einem privaten Subnet ist per Definition nicht über das öffentliche Internet erreichbar. Damit Lambda überhaupt einen TCP-Handshake zur Datenbank aufbauen kann, muss die Funktion in dieselbe VPC eingebunden werden.

Wenn Lambda mit einer VPC konfiguriert wird, erstellt AWS Elastic Network Interfaces (ENIs) in den angegebenen Subnets. Der Netzwerkverkehr der Funktion läuft dann über diese ENIs — und damit durch die normalen VPC-Routing- und Security-Group-Regeln. Das bedeutet: Lambda verhält sich aus Netzwerksicht wie eine EC2-Instanz in diesem Subnet.

Wichtig zu verstehen: Lambda selbst hat keine feste IP-Adresse. Die ENIs werden beim Kaltstart erstellt und können sich ändern. Security Groups sind deshalb das richtige Werkzeug zur Zugriffssteuerung — nicht IP-basierte Regeln.

graph LR LambdaFn["Lambda-Funktion
privates Subnet"] -->|TCP über ENI| LambdaSG["Security Group
Lambda"] LambdaSG -->|Outbound erlaubt| RDSSG["Security Group
RDS"] RDSSG -->|Inbound: Lambda-SG
Port 5432/3306| RDSInst["RDS-Instanz
privates Subnet"] style LambdaFn fill:#FF9900,color:#000 style RDSInst fill:#3F8624,color:#fff style LambdaSG fill:#232F3E,color:#fff style RDSSG fill:#232F3E,color:#fff

Lambda (VPC-gebunden): Die Funktion läuft in einem privaten Subnet der eigenen VPC über einen ENI.
Security Group Lambda: Ausgehender Traffic zum RDS-Port wird erlaubt.
Security Group RDS: Eingehender Traffic vom Lambda-SG auf den DB-Port (z.B. 5432 für PostgreSQL, 3306 für MySQL) wird explizit erlaubt.
RDS (privates Subnet): Kein öffentlicher Zugriff — nur über VPC-interne Verbindungen erreichbar.

Lambda mit privatem RDS verbinden: Schritt-für-Schritt-Konfiguration

Schritt 1: VPC-Konfiguration der Lambda-Funktion prüfen

Zuerst prüfen, ob die Lambda-Funktion überhaupt einer VPC zugeordnet ist. Ohne diese Zuordnung ist jeder weitere Schritt wirkungslos — die Funktion befindet sich schlicht in einem anderen Netzwerk.

aws lambda get-function-configuration \
  --function-name meine-lambda-funktion \
  --query 'VpcConfig' \
  --region us-east-1

Wenn die Ausgabe SubnetIds: [] und SecurityGroupIds: [] zeigt, ist keine VPC konfiguriert. Das ist der häufigste Grund für 'Connection timed out' bei RDS-Verbindungen.

Schritt 2: Security Group für Lambda erstellen

Eine dedizierte Security Group für die Lambda-Funktion anlegen — nicht die RDS-Security-Group direkt verwenden. Das ermöglicht eine saubere, referenzierbare Zugriffskontrolle auf der RDS-Seite.

aws ec2 create-security-group \
  --group-name lambda-rds-sg \
  --description 'Security Group fuer Lambda-RDS-Zugriff' \
  --vpc-id vpc-0123456789abcdef0 \
  --region us-east-1

Die ausgegebene GroupId (z.B. sg-0abc123def456) wird in den nächsten Schritten benötigt.

Schritt 3: RDS Security Group — Inbound-Regel für Lambda freischalten

Die RDS-Instanz verweigert standardmäßig alle eingehenden Verbindungen. Die Inbound-Regel muss explizit die Lambda-Security-Group als Quelle referenzieren — nicht eine IP-Range. Das ist robuster, weil Lambda-ENIs keine festen IPs haben.

aws ec2 authorize-security-group-ingress \
  --group-id sg-0rds456789abcdef \
  --protocol tcp \
  --port 5432 \
  --source-group sg-0abc123def456 \
  --region us-east-1

Den Port entsprechend der Datenbank-Engine anpassen: 5432 für PostgreSQL, 3306 für MySQL/MariaDB, 1433 für SQL Server.

Schritt 4: Lambda-Funktion mit VPC, Subnets und Security Group konfigurieren

Jetzt die Lambda-Funktion in die VPC einbinden. Mindestens zwei Subnets in verschiedenen Availability Zones angeben — das ist für Hochverfügbarkeit und für den Fall relevant, dass AWS ENIs in einer AZ nicht bereitstellen kann.

aws lambda update-function-configuration \
  --function-name meine-lambda-funktion \
  --vpc-config SubnetIds=subnet-0111aaa,subnet-0222bbb,SecurityGroupIds=sg-0abc123def456 \
  --region us-east-1

Schritt 5: IAM-Rolle der Lambda mit VPC-Berechtigungen ausstatten

Lambda benötigt Berechtigungen, um ENIs in der VPC zu erstellen, zu verwalten und zu löschen. Ohne diese Berechtigungen schlägt der Deployment-Prozess still fehl — die Funktion wird nicht gestartet, und CloudWatch zeigt einen Fehler wie Lambda was unable to configure your VPC.

Die verwaltete Richtlinie AWSLambdaVPCAccessExecutionRole deckt genau diese Berechtigungen ab.

aws iam attach-role-policy \
  --role-name meine-lambda-execution-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole

Die Richtlinie enthält unter anderem ec2:CreateNetworkInterface, ec2:DescribeNetworkInterfaces und ec2:DeleteNetworkInterface — alles, was Lambda für das ENI-Lifecycle-Management braucht.

🔽 Minimale IAM-Richtlinie (manuell, ohne verwaltete Richtlinie)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateNetworkInterface",
        "ec2:DescribeNetworkInterfaces",
        "ec2:DeleteNetworkInterface",
        "ec2:DescribeSubnets",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeVpcs"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/meine-lambda-funktion:*"
    }
  ]
}

Schritt 6: Verbindung verifizieren und Logs auswerten

Nach der Konfiguration die Funktion manuell aufrufen und die CloudWatch Logs auf Verbindungsfehler prüfen. Ein 'Connection timed out' nach wie vor deutet auf ein Security-Group-Problem hin. Ein 'Connection refused' deutet eher auf einen falschen Port oder eine falsche RDS-Endpunktadresse.

aws lambda invoke \
  --function-name meine-lambda-funktion \
  --payload '{}' \
  --cli-binary-format raw-in-base64-out \
  output.json \
  --region us-east-1 && cat output.json

aws logs tail /aws/lambda/meine-lambda-funktion \
  --follow \
  --region us-east-1

Typische Fehlerdiagnose: Symptom, Fehldiagnose, eigentliche Ursache

Symptom: Lambda-Funktion gibt nach ~30 Sekunden einen Timeout zurück. CloudWatch zeigt nur Task timed out after 30.00 seconds. Kein Datenbankfehler, kein Verbindungsprotokoll.

Fehldiagnose: Der erste Verdacht fällt auf den RDS-Endpunkt oder die Datenbankzugangsdaten. Die Verbindungszeichenkette wird geprüft, der Hostname aufgelöst — alles sieht korrekt aus. Dann wird der Lambda-Timeout erhöht, was das Problem natürlich nicht löst.

Eigentliche Ursache: Die Lambda-Funktion war nicht in der VPC konfiguriert. DNS-Auflösung des RDS-Endpunkts funktioniert auch außerhalb der VPC — der Hostname löst sich auf eine private IP auf. Aber der TCP-Verbindungsversuch zu dieser privaten IP läuft ins Leere, weil die Funktion sich außerhalb der VPC befindet. Das Timeout ist das einzige Observable.

Das ist wie eine Lieferung an eine Adresse schicken, die nur innerhalb eines privaten Geländes existiert — der Fahrer findet die Straße auf der Karte, kommt aber nie durch das Tor.

Fix: VPC-Konfiguration der Lambda-Funktion setzen (Schritt 4), IAM-Rolle prüfen (Schritt 5), Security-Group-Regel auf RDS-Seite hinzufügen (Schritt 3). Nach dem nächsten Deploy: Verbindung funktioniert beim ersten Aufruf.

Internetzugang für Lambda in einer VPC

Ein häufig übersehener Nebeneffekt: Sobald Lambda in eine VPC eingebunden wird, verliert die Funktion den direkten Internetzugang — auch wenn sie vorher problemlos externe APIs aufrufen konnte. Lambda in einer VPC routet Traffic nur innerhalb der VPC, es sei denn, ein NAT-Gateway oder ein VPC-Endpoint ist konfiguriert.

Wenn die Lambda-Funktion sowohl RDS als auch externe Dienste (z.B. Secrets Manager, externe APIs) erreichen muss, gibt es zwei Optionen:

NAT-Gateway: Lambda in privaten Subnets, die über ein NAT-Gateway in einem öffentlichen Subnet ins Internet routen. Kostenpflichtig pro Stunde und pro verarbeitetem GB.
VPC-Endpoints: Für AWS-Dienste wie Secrets Manager, S3 oder SSM können Interface-Endpoints oder Gateway-Endpoints in der VPC konfiguriert werden. Kein NAT-Gateway erforderlich, kein Internettraffic.

aws ec2 describe-vpc-endpoints \
  --filters Name=vpc-id,Values=vpc-0123456789abcdef0 \
  --query 'VpcEndpoints[*].{Service:ServiceName,State:State}' \
  --region us-east-1

graph TD LambdaFn["Lambda-Funktion
privates Subnet"] --> RDSInst["RDS-Instanz
privates Subnet"] LambdaFn --> VPCEndpoint["VPC Endpoint
Secrets Manager"] LambdaFn --> NATGateway["NAT Gateway
öffentliches Subnet"] NATGateway --> Internet["Internet
externe APIs"] VPCEndpoint --> SecretsManager["AWS Secrets Manager"] style LambdaFn fill:#FF9900,color:#000 style RDSInst fill:#3F8624,color:#fff style VPCEndpoint fill:#232F3E,color:#fff style NATGateway fill:#8C4FFF,color:#fff style Internet fill:#aaa,color:#000 style SecretsManager fill:#DD344C,color:#fff

Lambda (privates Subnet): Verbindet sich über ENI mit RDS im selben privaten Subnet-Bereich.
VPC Endpoint (Secrets Manager): Ermöglicht Lambda den Zugriff auf Secrets Manager ohne Internettraffic.
NAT Gateway: Für externen Internettraffic — nur notwendig, wenn Lambda externe Endpunkte erreichen muss.

RDS Proxy: Verbindungsmanagement für Lambda optimieren

Lambda-Funktionen können bei hoher Parallelität schnell Hunderte von Datenbankverbindungen öffnen — jede Funktionsinstanz hält ihre eigene Verbindung. RDS hat ein festes Verbindungslimit, das je nach Instanzgröße variiert. Bei intensiver Lambda-Nutzung ist RDS Proxy die empfohlene Lösung: Der Proxy pooled Verbindungen und gibt Lambda eine einzelne Endpunktadresse.

In der Praxis bedeutet das: Lambda verbindet sich mit dem RDS-Proxy-Endpunkt statt direkt mit der RDS-Instanz. Der Proxy liegt ebenfalls in der VPC — die Security-Group-Konfiguration bleibt dieselbe, nur der Zielendpunkt ändert sich.

Lambda mit privatem RDS verbinden: Abschluss und nächste Schritte

Die Kernregel ist einfach: Lambda muss in dieselbe VPC wie RDS eingebunden sein, mit passenden Subnets und einer Security Group, die von der RDS-Security-Group als Quelle akzeptiert wird. Die IAM-Rolle muss ENI-Berechtigungen haben. Ohne einen dieser drei Bausteine schlägt die Verbindung still fehl.

Weiterführende Ressourcen:

Glossar

Begriff	Bedeutung
ENI (Elastic Network Interface)	Virtuelle Netzwerkkarte in einer VPC. Lambda erstellt ENIs in konfigurierten Subnets, um VPC-Konnektivität zu ermöglichen.
Security Group	Zustandsbehaftete Firewall auf Instanz-/ENI-Ebene. Regelt ein- und ausgehenden Traffic über Protokoll, Port und Quelle/Ziel.
Privates Subnet	Subnet ohne direkte Route zum Internet-Gateway. RDS-Instanzen in privaten Subnets sind nur über VPC-interne Verbindungen erreichbar.
NAT-Gateway	Ermöglicht ausgehenden Internettraffic für Ressourcen in privaten Subnets, ohne eingehende Verbindungen zuzulassen.
RDS Proxy	Verwalteter Datenbankproxy von AWS, der Verbindungen pooled und das Verbindungslimit der RDS-Instanz schützt.

Dieses Blog durchsuchen

SW BBANG D