bug: EC2 deletes subnets and VPC still referenced by an active application load balancer

[AndreKurait]

An active application load balancer does not prevent deletion of either of its subnets. Once both subnets are deleted, its VPC can also be deleted, while DescribeLoadBalancers still returns the same active load balancer with the deleted subnet IDs.

Reproduced on an isolated, unmodified localstack/localstack-pro:dev container on Linux ARM64:

• API version: 2026.10.0.dev102.
• Multiarchitecture image digest: sha256:32adad290f38267baf073c8d519addfeee2dced2d9d68d3d28666cce88735bf7.
• ARM64 image configuration: sha256:c64ee0830b70bf09e2c58122b128e70ca44058a28d52caf1bcfa448f2fdf7ca5.
• Services: ec2,elbv2,sts; EC2_VM_MANAGER=mock, EC2_DOWNLOAD_DEFAULT_IMAGES=0, EAGER_SERVICE_LOADING=1.
• No extensions, initialization hooks, source modifications, or mounted Docker socket.

Observed

1. Create a VPC, two subnets in different availability zones, an internal ALB, an IP target group, and an HTTP listener.
2. Confirm the ALB is active and references those subnets.
3. DeleteSubnet returns HTTP 200 for both subnets.
4. DeleteVpc returns HTTP 200.
5. DescribeVpcs returns InvalidVpcID.NotFound, but DescribeLoadBalancers still returns the active ALB referencing the deleted subnets.

As controls, deleting an empty VPC succeeds, while deleting a VPC with an ordinary remaining subnet correctly returns DependencyViolation. The missing dependency is exposed when deleting the subnets used by the ALB.

Expected

Deleting a subnet still used by a load balancer should refuse with DependencyViolation. Deleting the load balancer first should eventually release its subnet dependency. The VPC should remain protected while its subnets remain.

AWS documents the network interfaces created for each enabled ALB zone and that requester-managed network interfaces are removed by deleting their owning service resource:

• https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html
• https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requester-managed-eni.html

This report is based on a LocalStack runtime reproduction and the documented AWS resource dependency. I did not run the destructive sequence against an AWS account.

Reproduction

Run this against a disposable LocalStack instance listening on local port 4566. It deliberately attempts to delete the resources it creates. It uses only dummy local credentials.

import json
import uuid

import boto3
from botocore.config import Config
from botocore.exceptions import ClientError

options = dict(
    endpoint_url="http://127.0.0.1:4566",
    region_name="eu-west-1",
    aws_access_key_id="000000000000",
    aws_secret_access_key="test",
    config=Config(
        connect_timeout=3,
        read_timeout=20,
        retries={"total_max_attempts": 1},
        proxies={},
    ),
)
ec2 = boto3.client("ec2", **options)
elb = boto3.client("elbv2", **options)
name = "subnet-dependency-" + uuid.uuid4().hex[:8]
vpc = ec2.create_vpc(CidrBlock="10.232.0.0/16")["Vpc"]["VpcId"]
subnets = [
    ec2.create_subnet(
        VpcId=vpc,
        CidrBlock=f"10.232.{i}.0/24",
        AvailabilityZone=zone,
    )["Subnet"]["SubnetId"]
    for i, zone in enumerate(("eu-west-1a", "eu-west-1b"), 1)
]
lb = elb.create_load_balancer(
    Name=name, Scheme="internal", Type="application", Subnets=subnets
)["LoadBalancers"][0]["LoadBalancerArn"]
target = elb.create_target_group(
    Name=name, Protocol="HTTP", Port=80, VpcId=vpc, TargetType="ip"
)["TargetGroups"][0]["TargetGroupArn"]
elb.create_listener(
    LoadBalancerArn=lb,
    Protocol="HTTP",
    Port=80,
    DefaultActions=[{"Type": "forward", "TargetGroupArn": target}],
)
print("before:", json.dumps(elb.describe_load_balancers(
    LoadBalancerArns=[lb])["LoadBalancers"], default=str))

def observe(operation, **parameters):
    try:
        response = operation(**parameters)
        print(operation.__name__, response)
    except ClientError as error:
        print(operation.__name__, error.response)

for subnet in subnets:
    observe(ec2.delete_subnet, SubnetId=subnet)
observe(ec2.delete_vpc, VpcId=vpc)
observe(ec2.describe_vpcs, VpcIds=[vpc])
observe(elb.describe_load_balancers, LoadBalancerArns=[lb])

# Explicit service cleanup; a target group surviving DeleteLoadBalancer
# alone is expected and is not the defect reported here.
observe(elb.delete_load_balancer, LoadBalancerArn=lb)
observe(elb.delete_target_group, TargetGroupArn=target)
for subnet in subnets:
    observe(ec2.delete_subnet, SubnetId=subnet)
observe(ec2.delete_vpc, VpcId=vpc)

Impact

Independent resource deletion can proceed before the load balancer is removed, leaving live service resources referencing deleted networking. This undermines dependency-based cleanup and retry ordering. The isolated reproduction establishes the API inconsistency; it does not establish a specific application's concurrency failure.

[AntonLage]

Hello Andre.

Thanks for the detailed report. I escalated the issue to the engineering team to work on it. I will update you as soon as I can.