Introduction

Checking whether a subnet is still in use sounds simple, but in most cloud environments there is no single button that lists every dependent service. The practical approach is to inspect the network interfaces and then trace them back to the compute, load balancing, database, or managed platform resources attached to that subnet.

Start with Network Interfaces

In AWS, the best first step is usually describe-network-interfaces. Elastic network interfaces, often shortened to ENIs, are the clearest signal that something is attached to a subnet.

1aws ec2 describe-network-interfaces \
2  --filters Name=subnet-id,Values=subnet-0123456789abcdef0 \
3  --query 'NetworkInterfaces[].[
4    NetworkInterfaceId,
5    Status,
6    Description,
7    PrivateIpAddress,
8    InterfaceType
9  ]' \
10  --output table

If this command returns active ENIs, the subnet is in use. The Description field often tells you what created the interface, such as EC2, Lambda, an EKS node, or a load balancer.

This check is more reliable than looking only for EC2 instances because many AWS services allocate ENIs behind the scenes.

Check Compute Resources

After identifying that the subnet has attached interfaces, find the compute resources that explicitly reference it. EC2 instances are the most direct example:

1aws ec2 describe-instances \
2  --filters Name=subnet-id,Values=subnet-0123456789abcdef0 \
3  --query 'Reservations[].Instances[].[
4    InstanceId,
5    State.Name,
6    PrivateIpAddress,
7    Tags[?Key==`Name`].Value | [0]
8  ]' \
9  --output table

If you use Auto Scaling groups or EKS managed node groups, instances may come and go, so a subnet can appear unused at one moment even though the platform still depends on it. That is why the ENI check should come first.

You should also remember that Lambda functions configured for VPC access create ENIs in private subnets. Those interfaces may remain even when no invocation is currently running.

Check Managed Services That Commonly Occupy Subnets

Several AWS services use subnets without showing up as plain EC2 instances. The most common ones are load balancers, RDS, ElastiCache, EKS, and private endpoints.

For load balancers:

1aws elbv2 describe-load-balancers \
2  --query 'LoadBalancers[?contains(AvailabilityZones[].SubnetId, `subnet-0123456789abcdef0`)].[
3    LoadBalancerName,
4    Type,
5    State.Code
6  ]' \
7  --output table

For RDS:

1aws rds describe-db-instances \
2  --query 'DBInstances[?contains(DBSubnetGroup.Subnets[].SubnetIdentifier, `subnet-0123456789abcdef0`)].[
3    DBInstanceIdentifier,
4    DBInstanceStatus,
5    Engine
6  ]' \
7  --output table

For VPC endpoints:

1aws ec2 describe-vpc-endpoints \
2  --filters Name=subnet-id,Values=subnet-0123456789abcdef0 \
3  --query 'VpcEndpoints[].[
4    VpcEndpointId,
5    VpcEndpointType,
6    State,
7    ServiceName
8  ]' \
9  --output table

These commands help you connect a subnet to the service that depends on it instead of stopping at the interface layer.

Decide Whether the Subnet Is Safe to Remove

A subnet is only safe to remove when there are no active dependencies left. In practice, that means:

• no ENIs attached
• no instances launched in it
• no load balancers assigned to it
• no database subnet groups still referencing it
• no VPC endpoints or managed services using it

A cautious workflow is to check the subnet from both directions:

1. Start with describe-network-interfaces.
2. Inspect service-level resources that can create ENIs.
3. Review route tables, network ACLs, and security group expectations.
4. Confirm recent traffic with VPC Flow Logs if you are unsure.

Flow logs are especially useful when you suspect intermittent use. A subnet may look quiet during a manual check but still serve scheduled jobs or low-frequency traffic.

Example Investigation Workflow

The following shell session is a realistic pattern for troubleshooting:

1SUBNET_ID=subnet-0123456789abcdef0
2
3aws ec2 describe-network-interfaces \
4  --filters Name=subnet-id,Values=$SUBNET_ID \
5  --output table
6
7aws ec2 describe-instances \
8  --filters Name=subnet-id,Values=$SUBNET_ID \
9  --output table
10
11aws elbv2 describe-load-balancers \
12  --query "LoadBalancers[?contains(AvailabilityZones[].SubnetId, '$SUBNET_ID')]"

If the first command returns interfaces but the second returns no instances, focus on managed services. That is a common sign that the subnet is being used by infrastructure components rather than application servers.

Common Pitfalls

The biggest mistake is checking only EC2 instances and concluding that an empty result means the subnet is unused. ENIs from Lambda, EKS, load balancers, private endpoints, and database services can keep the subnet active.

Another problem is ignoring recently deleted resources. Interfaces can linger briefly after service changes, so if you are cleaning up infrastructure, re-run the checks after the platform settles.

Teams also forget about dependencies outside pure networking. A subnet may still be referenced by infrastructure-as-code templates, launch templates, or subnet groups even if no traffic is visible at the moment. Removing it too early can break the next deployment.

Finally, do not rely on one console page. Use both service-level inspection and network-interface inspection before declaring a subnet unused.

Summary

• The fastest way to see whether a subnet is in use is to inspect its network interfaces.
• In AWS, describe-network-interfaces is usually the most informative first command.
• Managed services can occupy a subnet even when no EC2 instances are present.
• Check load balancers, RDS, VPC endpoints, Lambda, and EKS-related resources before deleting a subnet.
• Use VPC Flow Logs and repeated checks when usage may be intermittent.