InvalidSubnetID.NotFound: Debugging VPC and Subnet Misconfigurations

You are deploying a CloudFormation stack and the deployment fails at minute twelve with this error:

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

Or maybe you see this variant when launching an RDS instance:

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)

The InvalidSubnetID.NotFound error is one of the most frustrating VPC errors because it can appear across nearly every AWS service that supports VPC placement — Lambda, RDS, ECS, ElastiCache, EKS, and more. The subnet existed when you first configured the resource. So where did it go?

In this post, I will walk through the five most common root causes I encounter during client engagements, the exact CLI commands to diagnose each one, and the prevention strategies that keep this error from showing up in your deployment pipeline again.

The Error Messages You Will See

Different AWS services surface this error in slightly different ways:

# 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

Regardless of the service, the root cause falls into one of five categories.

Root Cause 1: The Subnet Was Deleted

This is the most common cause. Someone deleted the subnet — either manually in the console or through an infrastructure-as-code change — while other resources still referenced it. I see this frequently in organizations where the networking team manages VPC infrastructure separately from the application teams.

Diagnosis

First, verify that the subnet truly does not exist:

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

If the subnet was deleted, you will get:

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

Check CloudTrail to find out when and who deleted it:

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
  }'

Solution

You have two options. Either recreate the subnet with the same CIDR block in the correct VPC and AZ, or update all resources that reference the old subnet ID to point to an existing subnet. To find the remaining subnets in the VPC:

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

Root Cause 2: Cross-Region Subnet Reference

Subnet IDs are region-scoped. A subnet in us-east-1 does not exist in us-west-2. This sounds obvious, but it happens more often than you would expect — especially in multi-region deployments where infrastructure code uses hardcoded subnet IDs or the wrong SSM parameter.

Diagnosis

Check which region the subnet actually lives in. If you do not know, iterate through your active regions:

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

Solution

If you are using CloudFormation or CDK, never hardcode subnet IDs. Instead, use SSM parameters scoped to the deployment region:

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

Then reference the parameter in your 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

Root Cause 3: Subnet and Security Group in Different VPCs

This is a subtle variant. The subnet exists, but it is in a different VPC than the security group you are referencing. AWS will not let you attach a security group from VPC-A to a resource in a subnet belonging to VPC-B.

The error message is sometimes misleading. Instead of telling you the VPC mismatch, it may report the subnet as not found from the security group's VPC context.

Diagnosis

Compare the VPC IDs of your subnet and security group:

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

# Get the security group's VPC
aws ec2 describe-security-groups \
  --group-ids sg-0abc123def456789b \
  --query 'SecurityGroups[0].VpcId' \
  --output text

If the two VPC IDs do not match, that is your problem.

Solution

Ensure both the subnet and security group belong to the same VPC. If you are using infrastructure as code, reference them from the same VPC resource:

// CDK example — derive both from the same VPC
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'),
  ],
  // ...
});

Root Cause 4: RDS Subnet Group With Missing or Insufficient Subnets

RDS requires a DB subnet group containing subnets in at least two Availability Zones. If one of those subnets is deleted, or if you created the subnet group with subnets in only one AZ, you will hit this error.

Diagnosis

Inspect the existing 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
    }
  }'

Then verify each subnet still exists:

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

If any subnet returns an error, it has been deleted.

Solution

Modify the DB subnet group to include valid subnets across at least two AZs:

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 "Updated private subnets"

Root Cause 5: Lambda VPC Configuration Pointing to Stale Subnets

Lambda functions configured for VPC access store the subnet IDs in their configuration. If those subnets are later deleted, the function will fail on the next cold start because AWS cannot create the Elastic Network Interface (ENI) in a non-existent subnet.

Diagnosis

Check the Lambda function's VPC configuration:

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

Then validate each subnet:

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

Solution

Update the Lambda function's VPC configuration to use valid subnets:

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

Make sure the new subnets have a route to a NAT Gateway if your function needs internet access, or VPC endpoints if it only needs to reach AWS services.

Prevention: Stop This Error From Happening Again

After fixing the immediate issue, put guardrails in place so this does not recur.

1. Use Infrastructure as Code With Cross-References

Never hardcode subnet IDs. In CDK, use VPC lookups. In Terraform, use data sources. In CloudFormation, use SSM parameters or cross-stack references.

# Export subnet IDs from your networking stack
aws cloudformation list-exports \
  --query 'Exports[?starts_with(Name, `Network-`)].{Name:Name,Value:Value}' \
  --output table

2. Add Deletion Protection

For subnets that are referenced by other resources, use AWS Config rules or SCPs to prevent accidental deletion:

{
  "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. Run Pre-Deployment Validation

Add a validation step to your CI/CD pipeline that checks whether all referenced subnet IDs exist before deploying:

#!/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 "ERROR: Subnet $subnet does not exist!"
    exit 1
  fi
done
echo "All subnets validated."

4. Tag Your Subnets

Use consistent tagging so that infrastructure code can look up subnets by tag rather than hardcoded ID:

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. Monitor VPC Changes With AWS Config

Enable AWS Config to track subnet deletions and modifications. Set up a CloudWatch Events rule to alert when a subnet is deleted:

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

Need Help With Your VPC Architecture?

VPC misconfigurations are one of the most common sources of deployment failures we see during AWS infrastructure reviews. If your team is spending time debugging networking errors instead of building features, we can help. We offer free initial consultations to assess your AWS architecture and identify the configuration issues that are slowing you down.

Get in touch for a free AWS consultation