Subnet or VCN Deletion

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 Subnet Isn't 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:


When you create one of the preceding resources, you specify a VCN and subnet for it. The relevant service creates at least one VNIC in the subnet and attaches the VNIC to the resource. The service manages the VNICs on your behalf, so they are not readily apparent to you in the Console. 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. This documentation uses the term parent resource to refer to this type of resource.

If the subnet is empty when you try to delete it, its state changes to TERMINATING briefly and then to TERMINATED.

If the subnet is not empty, you instead get an error indicating that there are still resources that you must delete first. The error includes the OCID of a VNIC that is in the subnet (there could be more, but the error returns only a single VNIC's OCID).

You can use the Oracle Cloud Infrastructure command line interface (CLI) or another SDK or client to call the GetVnic operation with the VNIC OCID. The response includes the VNIC's display name. Depending on the type of parent resource, the display name can indicate which parent resource the VNIC belongs to. You can then delete that parent resource, or you can contact your administrator to determine who owns the resource. When the VNIC's parent resource is deleted, the attached VNIC is also deleted from the subnet. If there are remaining VNICs in the subnet, repeat the process of determining and deleting each parent resource until the subnet is empty. Then you can delete the subnet.

For example, if you're using the CLI, use this command to get information about the VNIC.

oci network vnic get --vnic-id <VNIC_OCID>
Load balancer example

Here is an example CLI response for a VNIC that belongs to a load balancer. The display name shows the load balancer's OCID:

  "data": {
    "availability-domain": "fooD:PHX-AD-1", 
    "compartment-id": "ocid1.compartment.oc1..<unique_id_1>", 
    "defined-tags": {}, 
    "display-name": "VNIC for LB ocid1.loadbalancer.oc1.phx.<unique_id_2>", 
    "freeform-tags": {}, 
    "hostname-label": null, 
    "id": "ocid1.vnic.oc1.phx.<unique_id_3>", 
    "is-primary": false, 
    "lifecycle-state": "AVAILABLE", 
    "mac-address": "00:00:17:00:BB:CA", 
    "private-ip": "", 
    "public-ip": null, 
    "skip-source-dest-check": false, 
    "subnet-id": "ocid1.subnet.oc1.phx.<unique_id_4>", 
    "time-created": "2019-05-11T04:28:31.950000+00:00"
  "etag": "5d8213fa"
File Storage example

Here's an example for a VNIC that belongs to a File Storage mount target:

"display-name": "fss-<integer>",

Although the display name does not include an OCID, the fss characters indicate that the resource is for the File Storage service.

Database example

Here's an example of the display name for a VNIC that belongs to a DB system:

"display-name": "ocid1.dbnode.oc1.phx.<unique_id>", 

A Network Security Group Isn't Empty

Another reason a VCN can't be deleted is because it contains a one or more network security groups (NSGs) that are not yet empty. To delete an NSG, it must not contain any VNICs (or parent resources with VNICs). You can determine what parent resources are in an NSG by using either the Console or REST API. For more information, see To delete an NSG.

There Are Resources in Compartments You Don't Have Access To

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 compartments , 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.