Prerequisite: Oracle AI Database@AWS – FAQ – Networking configuration

Back in May 2026, the custom NSG for Oracle AI Database@AWS was added. In this blog I will give a complete explanation of this new feature since sometimes it is causing confusion when it should be used.

Let’s recall how the built-in security for Oracle AI Database@AWS is working. After the ODB Network finishes the configuration the shadow OCI VCN containing the associated subnets (Client and Backup for Exadata and Client for ADB), Client subnet route table and NSGs are also created. We will look specifically at the NSGs that are automatically updated by the automation when a new peer CIDR is added.

The two NSGs are listed as:

  • EXA_1521_ADJUSTABLE_NSG
  • ADB_1521_2484_ADJUSTABLE_NSG

EXA_1521_ADJUSTABLE_NSG is used for Exadata Database and ADB_1521_2484_ADJUSTABLE_NSG for Autonomous AI Database.

These two NSGs automatically created are very important and are updated with four security entries (at the moment if this writing) for each and every peer CIDR added, three ingress security rules and one egress, details below:

The NSG has a default limit of 120 security rules ingress+egress. Doing a simple math, with the default NSG configuration we can accommodate 120 / 4 = 30 peered CIDRs. In some case our customers are requesting to add more than 30 peered CIDRs and a limit increase for the NSG to support more than 120 security entries is to be raised.

With the launch of custom NSGs for Oracle AI Database@AWS some clarification is needed.

We may think that if we detach the default NSG created by automation (the two NSGs listed above) and attach a custom created NSG, then the default NSG will not be used at all, it will stop being populated when a new peer CIDR is added for ODB peering and we will not face the limit of the number of security entries. All because now we are just using a custom NSG that we fully control to add just the entries that we require. Here is the confusion.

The reality is a little bit different. For using a custom NSG to granular control which traffic to allow (this is actually the single scope of using a custom NSG) we need to detach (without deleting) the default NSG and attach the custom NSG. Even if we have detached the default NSG, this NSG is still populated with the four security entries when a new peer CIDR is added and we can still hit the limit for the number of security entries.

That being said, adding a custom NSG will not make the default one to not be populated by the automation and we can still have the limit issue.

The solution each and every time when you need to add more than 30 peered CIDRs is to raise a ticket for a limit increase and not use a custom NSG. We can use the custom NSG for having a more granular security entries or to simplify by creating generic entries like 10.0.0.0/8 on port 1521 and not to resolve the limit related to the number of security entries supported by an NSG.

I do hope that this blog clarifies the usage of custom NSG for Oracle AI Database@AWS.