This topic covers reasons why deletion of a subnet or VCN might fail.
- To delete a VCN, it must first be empty and have no related resources or attached gateways (for example: no internet gateway, dynamic routing gateway, and so on).
- To delete a VCN's subnets, they must first be empty.
The most common reason a subnet (and thus a VCN) can't be deleted is because the subnet contains one or more of these resources:
- Orphaned mount target for a file system (see the instructions for deleting orphaned mount targets)
- Load balancer
- DB system
When you create one of the preceding resources, you specify a VCN and subnet for it, and a VNIC is automatically created in that subnet and attached to the resource. The VNIC enables the resource to communicate with other resources over the network. Although this documentation commonly talks about the resource itself being in the subnet, it's actually the resource's attached VNIC.
If the subnet is empty when you try to delete it, its state changes to TERMINATING briefly and then to TERMINATED. If it's not empty, you instead get an error indicating that there are still resources that you must delete first.
You might not be able to see all the resources in a subnet or VCN. This is because subnets and VCNs can contain resources in multiple A collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization., and you might not have access to all the compartments. For example, the subnet might contain instances that your team manages but also DB systems that another team manages. Another example: The VCN might have security lists or a gateway in a compartment that another team manages. You might need to contact your tenancy administrator to help you determine who owns the resources in the subnet or VCN.