InvalidSubnetID.NotFound: VPC- und Subnet-Fehlkonfigurationen debuggen

Sie deployen einen CloudFormation-Stack und das Deployment schlägt in Minute zwölf mit diesem Fehler fehl:

An error occurred (InvalidSubnetID.NotFound) when calling the CreateFunction
operation: The subnet ID 'subnet-0abc123def456789a' does not exist

Oder Sie sehen diese Variante beim Starten einer RDS-Instanz:

DBSubnetGroupDoesNotCoverEnoughAZs: DB Subnet Group doesn't meet availability
zone coverage requirement. Present availability zones: [us-east-1a].
At least 2 availability zones must be present. (Service: AmazonRDS;
Status Code: 400)

Der InvalidSubnetID.NotFound-Fehler ist einer der frustrierendsten VPC-Fehler, weil er bei nahezu jedem AWS-Service auftreten kann, der VPC-Platzierung unterstützt — Lambda, RDS, ECS, ElastiCache, EKS und mehr. Das Subnet existierte, als Sie die Ressource ursprünglich konfiguriert haben. Wo ist es also hin?

In diesem Beitrag gehe ich die fünf häufigsten Ursachen durch, die mir bei Kundenprojekten begegnen, zeige die exakten CLI-Befehle zur Diagnose jeder einzelnen und erkläre die Präventionsstrategien, die verhindern, dass dieser Fehler erneut in Ihrer Deployment-Pipeline auftaucht.

Die Fehlermeldungen, die Sie sehen werden

Verschiedene AWS-Services zeigen diesen Fehler auf leicht unterschiedliche Weise an:

# EC2 / Lambda
InvalidSubnetID.NotFound: The subnet ID 'subnet-xxx' does not exist

# CloudFormation
Resource handler returned message: "The subnet ID 'subnet-xxx' does not exist"

# RDS
InvalidSubnet: Subnet 'subnet-xxx' not found

# ECS
InvalidParameterException: The subnet ID 'subnet-xxx' does not exist

Unabhängig vom Service fällt die Ursache in eine von fünf Kategorien.

Ursache 1: Das Subnet wurde gelöscht

Dies ist die häufigste Ursache. Jemand hat das Subnet gelöscht — entweder manuell in der Konsole oder durch eine Infrastructure-as-Code-Änderung — während andere Ressourcen es noch referenzierten. Ich sehe dies häufig in Organisationen, in denen das Netzwerk-Team die VPC-Infrastruktur getrennt von den Anwendungsteams verwaltet.

Diagnose

Überprüfen Sie zunächst, ob das Subnet tatsächlich nicht mehr existiert:

aws ec2 describe-subnets \
  --subnet-ids subnet-0abc123def456789a \
  --region us-east-1

Wenn das Subnet gelöscht wurde, erhalten Sie:

An error occurred (InvalidSubnetID.NotFound) when calling the
DescribeSubnets operation: The subnet ID 'subnet-0abc123def456789a'
does not exist

Prüfen Sie CloudTrail, um herauszufinden, wann und wer es gelöscht hat:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=subnet-0abc123def456789a \
  --start-time "2026-03-01T00:00:00Z" \
  --end-time "2026-04-05T23:59:59Z" \
  --query 'Events[?EventName==`DeleteSubnet`].{
    Time: EventTime,
    User: Username,
    Source: EventSource
  }'

Lösung

Sie haben zwei Möglichkeiten: Erstellen Sie das Subnet mit dem gleichen CIDR-Block in der richtigen VPC und AZ neu, oder aktualisieren Sie alle Ressourcen, die die alte Subnet-ID referenzieren, auf ein existierendes Subnet. Um die verbleibenden Subnets in der VPC zu finden:

aws ec2 describe-subnets \
  --filters "Name=vpc-id,Values=vpc-0abc123def456789a" \
  --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone,CIDR:CidrBlock,Name:Tags[?Key==`Name`]|[0].Value}' \
  --output table

Ursache 2: Regionsübergreifende Subnet-Referenz

Subnet-IDs sind regionsbezogen. Ein Subnet in us-east-1 existiert nicht in us-west-2. Das klingt offensichtlich, passiert aber häufiger als man erwarten würde — besonders bei Multi-Region-Deployments, in denen Infrastruktur-Code fest codierte Subnet-IDs oder den falschen SSM-Parameter verwendet.

Diagnose

Prüfen Sie, in welcher Region das Subnet tatsächlich existiert. Wenn Sie es nicht wissen, iterieren Sie durch Ihre aktiven Regionen:

for region in us-east-1 us-west-2 eu-west-1 eu-central-1; do
  echo "Prüfe $region..."
  aws ec2 describe-subnets \
    --subnet-ids subnet-0abc123def456789a \
    --region "$region" 2>/dev/null && echo "GEFUNDEN in $region"
done

Lösung

Wenn Sie CloudFormation oder CDK verwenden, codieren Sie niemals Subnet-IDs fest. Verwenden Sie stattdessen SSM-Parameter, die auf die Deployment-Region zugeschnitten sind:

# Subnet-IDs pro Region in SSM Parameter Store speichern
aws ssm put-parameter \
  --name "/network/private-subnet-1" \
  --value "subnet-0abc123def456789a" \
  --type String \
  --region us-east-1

Dann referenzieren Sie den Parameter in Ihrem CloudFormation-Template:

Parameters:
  PrivateSubnet1:
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Subnet::Id>
    Default: /network/private-subnet-1

Resources:
  MyFunction:
    Type: AWS::Lambda::Function
    Properties:
      VpcConfig:
        SubnetIds:
          - !Ref PrivateSubnet1

Ursache 3: Subnet und Security Group in verschiedenen VPCs

Dies ist eine subtile Variante. Das Subnet existiert, befindet sich aber in einer anderen VPC als die Security Group, die Sie referenzieren. AWS lässt es nicht zu, eine Security Group aus VPC-A an eine Ressource in einem Subnet von VPC-B anzuhängen.

Die Fehlermeldung ist manchmal irreführend. Anstatt Ihnen den VPC-Mismatch mitzuteilen, kann sie das Subnet als nicht gefunden melden — aus dem Kontext der VPC der Security Group.

Diagnose

Vergleichen Sie die VPC-IDs Ihres Subnets und Ihrer Security Group:

# VPC des Subnets abrufen
aws ec2 describe-subnets \
  --subnet-ids subnet-0abc123def456789a \
  --query 'Subnets[0].VpcId' \
  --output text

# VPC der Security Group abrufen
aws ec2 describe-security-groups \
  --group-ids sg-0abc123def456789b \
  --query 'SecurityGroups[0].VpcId' \
  --output text

Wenn die beiden VPC-IDs nicht übereinstimmen, haben Sie das Problem gefunden.

Lösung

Stellen Sie sicher, dass sowohl das Subnet als auch die Security Group zur gleichen VPC gehören. Wenn Sie Infrastructure as Code verwenden, referenzieren Sie beide von der gleichen VPC-Ressource:

// CDK-Beispiel — beide aus der gleichen VPC ableiten
const vpc = ec2.Vpc.fromLookup(this, 'Vpc', {
  vpcId: 'vpc-0abc123def456789a',
});

new lambda.Function(this, 'MyFunction', {
  vpc: vpc,
  vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS },
  securityGroups: [
    ec2.SecurityGroup.fromSecurityGroupId(this, 'SG', 'sg-xxx'),
  ],
  // ...
});

Ursache 4: RDS Subnet Group mit fehlenden oder unzureichenden Subnets

RDS erfordert eine DB-Subnet-Group mit Subnets in mindestens zwei Availability Zones. Wenn eines dieser Subnets gelöscht wird oder Sie die Subnet-Group mit Subnets in nur einer AZ erstellt haben, tritt dieser Fehler auf.

Diagnose

Untersuchen Sie die bestehende DB-Subnet-Group:

aws rds describe-db-subnet-groups \
  --db-subnet-group-name my-db-subnet-group \
  --query 'DBSubnetGroups[0].{
    Name: DBSubnetGroupName,
    VpcId: VpcId,
    Subnets: Subnets[*].{
      ID: SubnetIdentifier,
      AZ: SubnetAvailabilityZone.Name,
      Status: SubnetStatus
    }
  }'

Dann überprüfen Sie, ob jedes Subnet noch existiert:

aws ec2 describe-subnets \
  --subnet-ids subnet-aaa subnet-bbb subnet-ccc \
  --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone,State:State}'

Wenn ein Subnet einen Fehler zurückgibt, wurde es gelöscht.

Lösung

Ändern Sie die DB-Subnet-Group, um gültige Subnets über mindestens zwei AZs einzuschließen:

aws rds modify-db-subnet-group \
  --db-subnet-group-name my-db-subnet-group \
  --subnet-ids subnet-aaa subnet-ddd subnet-eee \
  --db-subnet-group-description "Aktualisierte private Subnets"

Ursache 5: Lambda-VPC-Konfiguration mit veralteten Subnets

Lambda-Funktionen, die für VPC-Zugriff konfiguriert sind, speichern die Subnet-IDs in ihrer Konfiguration. Wenn diese Subnets später gelöscht werden, schlägt die Funktion beim nächsten Cold Start fehl, weil AWS das Elastic Network Interface (ENI) nicht in einem nicht existierenden Subnet erstellen kann.

Diagnose

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

aws lambda get-function-configuration \
  --function-name my-function \
  --query '{
    SubnetIds: VpcConfig.SubnetIds,
    SecurityGroupIds: VpcConfig.SecurityGroupIds,
    VpcId: VpcConfig.VpcId
  }'

Dann validieren Sie jedes Subnet:

aws ec2 describe-subnets \
  --subnet-ids subnet-aaa subnet-bbb \
  --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone}' 2>&1

Lösung

Aktualisieren Sie die VPC-Konfiguration der Lambda-Funktion mit gültigen Subnets:

aws lambda update-function-configuration \
  --function-name my-function \
  --vpc-config SubnetIds=subnet-new1,subnet-new2,SecurityGroupIds=sg-xxx

Stellen Sie sicher, dass die neuen Subnets eine Route zu einem NAT Gateway haben, wenn Ihre Funktion Internetzugang benötigt, oder VPC-Endpoints, wenn sie nur AWS-Services erreichen muss.

Prävention: Diesen Fehler in Zukunft vermeiden

Nachdem Sie das unmittelbare Problem behoben haben, setzen Sie Schutzmaßnahmen ein, damit es nicht erneut auftritt.

1. Infrastructure as Code mit Querverweisen verwenden

Codieren Sie niemals Subnet-IDs fest. In CDK verwenden Sie VPC-Lookups. In Terraform verwenden Sie Data Sources. In CloudFormation verwenden Sie SSM-Parameter oder Cross-Stack-Referenzen.

# Subnet-IDs aus Ihrem Netzwerk-Stack exportieren
aws cloudformation list-exports \
  --query 'Exports[?starts_with(Name, `Network-`)].{Name:Name,Value:Value}' \
  --output table

2. Löschschutz hinzufügen

Für Subnets, die von anderen Ressourcen referenziert werden, verwenden Sie AWS Config Rules oder SCPs, um versehentliches Löschen zu verhindern:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PreventSubnetDeletion",
      "Effect": "Deny",
      "Action": "ec2:DeleteSubnet",
      "Resource": "arn:aws:ec2:us-east-1:123456789012:subnet/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Protected": "true"
        }
      }
    }
  ]
}

3. Pre-Deployment-Validierung durchführen

Fügen Sie Ihrer CI/CD-Pipeline einen Validierungsschritt hinzu, der prüft, ob alle referenzierten Subnet-IDs vor dem Deployment existieren:

#!/bin/bash
SUBNETS="subnet-aaa subnet-bbb subnet-ccc"
for subnet in $SUBNETS; do
  if ! aws ec2 describe-subnets --subnet-ids "$subnet" &>/dev/null; then
    echo "FEHLER: Subnet $subnet existiert nicht!"
    exit 1
  fi
done
echo "Alle Subnets validiert."

4. Subnets taggen

Verwenden Sie konsistentes Tagging, damit Infrastruktur-Code Subnets nach Tag statt nach fest codierter ID nachschlagen kann:

aws ec2 describe-subnets \
  --filters \
    "Name=tag:Environment,Values=production" \
    "Name=tag:Tier,Values=private" \
  --query 'Subnets[*].{ID:SubnetId,AZ:AvailabilityZone,CIDR:CidrBlock}' \
  --output table

5. VPC-Änderungen mit AWS Config überwachen

Aktivieren Sie AWS Config, um Subnet-Löschungen und -Änderungen zu verfolgen. Richten Sie eine CloudWatch Events-Regel ein, die bei Subnet-Löschungen alarmiert:

aws events put-rule \
  --name "SubnetDeletionAlert" \
  --event-pattern '{
    "source": ["aws.ec2"],
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
      "eventName": ["DeleteSubnet"]
    }
  }'

Brauchen Sie Hilfe mit Ihrer VPC-Architektur?

VPC-Fehlkonfigurationen gehören zu den häufigsten Ursachen für Deployment-Ausfälle, die wir bei AWS-Infrastruktur-Reviews sehen. Wenn Ihr Team Zeit mit dem Debuggen von Netzwerkfehlern verbringt, anstatt Features zu entwickeln, können wir helfen. Wir bieten kostenlose Erstberatungen an, um Ihre AWS-Architektur zu bewerten und die Konfigurationsprobleme zu identifizieren, die Sie ausbremsen.

Kontaktieren Sie uns für eine kostenlose AWS-Beratung