How do NSGs differ from security lists in OCI?

Security lists apply to all VNICs in a subnet and are limited to five per subnet with 200 rules each. NSGs attach to individual VNICs and support up to 120 rules per NSG with five NSGs per VNIC. The key advantage of NSGs is that you can reference other NSGs as sources or destinations, enabling dynamic security rules that automatically include new instances added to the referenced NSG. Oracle recommends NSGs as the primary security mechanism.

Can I use both security lists and NSGs simultaneously?

Yes, and OCI evaluates rules from both using union semantics. If either a security list rule or an NSG rule allows the traffic, it is permitted. This means combining both can only make access more permissive, never more restrictive. A common pattern is to use security lists for broad baseline rules (like allowing all intra-VCN ICMP) and NSGs for application-specific rules (like allowing port 8080 only from the load balancer NSG).

What source and destination types can NSG rules reference?

NSG rules support three source/destination types: CIDR blocks for IP-based rules, NSG OCID references for rules that dynamically include all VNICs in another NSG, and SERVICE_CIDR_BLOCK for rules targeting Oracle Services Network ranges accessible via the service gateway. The NSG reference type is particularly powerful because it decouples security rules from IP addresses, making your network security more maintainable.

OCI NSG Rule Builder

NetworkingOCI

Build Network Security Group rules with CIDR and NSG source references.

Last verified: May 2026

OCI Network Security Groups Configuration

Build NSG ingress and egress security rules with CIDR, NSG source/destination references.

Required Fields

compartmentIdvcnIddisplayNamesecurityRules

{
  "compartmentId": "ocid1.compartment.oc1..aaaaaaaexample",
  "vcnId": "ocid1.vcn.oc1.iad.aaaaaaaexample",
  "displayName": "web-app-nsg",
  "securityRules": [
    {
      "direction": "INGRESS",
      "protocol": "6",
      "source": "0.0.0.0/0",
      "sourceType": "CIDR_BLOCK",
      "isStateless": false,
      "tcpOptions": {
        "destinationPortRange": {
          "min": 443,
          "max": 443
        }
      },
      "description": "Allow HTTPS from anywhere"
    },
    {
      "direction": "INGRESS",
      "protocol": "6",
      "source": "ocid1.networksecuritygroup.oc1.iad.aaaaaaabastion",
      "sourceType": "NETWORK_SECURITY_GROUP",
      "isStateless": false,
      "tcpOptions": {
        "destinationPortRange": {
          "min": 22,
          "max": 22
        }
      },
      "description": "Allow SSH from bastion NSG"
    },
    {
      "direction": "EGRESS",
      "protocol": "6",
      "destination": "ocid1.networksecuritygroup.oc1.iad.aaaaaaaadb",
      "destinationType": "NETWORK_SECURITY_GROUP",
      "isStateless": false,
      "tcpOptions": {
        "destinationPortRange": {
          "min": 1521,
          "max": 1521
        }
      },
      "description": "Allow Oracle DB access to database NSG"
    },
    {
      "direction": "EGRESS",
      "protocol": "6",
      "destination": "0.0.0.0/0",
      "destinationType": "CIDR_BLOCK",
      "isStateless": false,
      "tcpOptions": {
        "destinationPortRange": {
          "min": 443,
          "max": 443
        }
      },
      "description": "Allow HTTPS outbound for API calls"
    }
  ],
  "freeformTags": {
    "tier": "web",
    "environment": "production"
  }
}

Generated Output

Output will appear here...

See It in Action

Your team is replacing flat security list rules with NSG-based segmentation for a 50-instance production VCN. The builder generates 4 NSGs (web, app, db, mgmt) with NSG-reference rules between tiers (web → app → db). The transformation: instead of CIDR-based rules that need updates whenever IPs change, you now have rules that automatically include new instances based on NSG membership. Adding a new app server: just attach it to the app-tier NSG. The rules apply automatically.

What This Tool Does

Network Security Groups (NSGs) in OCI provide VNIC-level security rules that are more granular than subnet-level security lists. Unlike security lists that apply to all VNICs in a subnet, NSGs can be attached to specific VNICs — individual compute instances, load balancers, or database systems. Each NSG contains up to 120 ingress and egress rules, and a VNIC can belong to up to five NSGs. This builder helps you construct NSG rules with correct source/destination types (CIDR, NSG, or service), protocol settings, and stateful/stateless flags.

Technical Details

The builder constructs OCI Network Security Group rules with: direction (INGRESS/EGRESS), protocol number (6=TCP, 17=UDP, 1=ICMP, 'all'), source or destination type (CIDR_BLOCK / NETWORK_SECURITY_GROUP / SERVICE_CIDR_BLOCK), source/destination value, port ranges (TCP/UDP only), ICMP type and code (ICMP only), stateful flag, and description. Output is oci CLI commands and Terraform oci_core_network_security_group_security_rule resources.

Common Use Cases

1Building NSG rules for a three-tier application where web servers accept HTTPS, app servers accept traffic only from the web NSG, and databases accept traffic only from the app NSG
2Creating NSG rules that reference other NSGs as sources or destinations for service-to-service communication without hardcoding CIDR blocks
3Configuring stateless NSG rules for high-performance computing clusters that need minimum network latency
4Generating NSG configurations that allow OCI service gateway traffic to specific Oracle Services Network CIDRs

Common Questions

How do NSGs differ from security lists in OCI?: Security lists apply to all VNICs in a subnet and are limited to five per subnet with 200 rules each. NSGs attach to individual VNICs and support up to 120 rules per NSG with five NSGs per VNIC. The key advantage of NSGs is that you can reference other NSGs as sources or destinations, enabling dynamic security rules that automatically include new instances added to the referenced NSG. Oracle recommends NSGs as the primary security mechanism.
Can I use both security lists and NSGs simultaneously?: Yes, and OCI evaluates rules from both using union semantics. If either a security list rule or an NSG rule allows the traffic, it is permitted. This means combining both can only make access more permissive, never more restrictive. A common pattern is to use security lists for broad baseline rules (like allowing all intra-VCN ICMP) and NSGs for application-specific rules (like allowing port 8080 only from the load balancer NSG).
What source and destination types can NSG rules reference?: NSG rules support three source/destination types: CIDR blocks for IP-based rules, NSG OCID references for rules that dynamically include all VNICs in another NSG, and SERVICE_CIDR_BLOCK for rules targeting Oracle Services Network ranges accessible via the service gateway. The NSG reference type is particularly powerful because it decouples security rules from IP addresses, making your network security more maintainable.

Expert Tips

TIP

NSG-to-NSG references (rather than CIDR-based rules) are the killer OCI feature. Define a 'web-tier' NSG and an 'app-tier' NSG, then create a rule on app-tier NSG saying 'allow port 8080 from web-tier NSG'. Add new web instances to the NSG and they automatically get access — no rule changes needed.

TIP

OCI's 5-NSG-per-VNIC limit is enforced strictly. Plan NSG composition carefully: 1 baseline NSG for common rules + 1-2 application-specific NSGs is typical. Don't try to use NSGs as fine-grained access tokens — that pattern hits the limit fast.

TIP

Always name NSGs with a clear scheme like '{env}-{tier}-nsg' (e.g., prod-web-nsg, prod-app-nsg). When you have 30+ NSGs across compartments, finding the right one in dropdowns becomes a real productivity drag without naming discipline.

Related Learning Guides

OCI VCN Networking Deep Dive25 min read
OCI Security Best Practices24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.