Introduction
When customers deploy Oracle AI Database@AWS, the first security conversation usually starts with the ODB network, the peering model, and the routing path from AWS to the database environment.
Oracle AI Database@AWS is operated across both AWS and OCI control planes. That gives customers a powerful deployment model, but it also means some security behaviour is service-driven rather than fully customer-defined. One of the clearest examples is the Network Security Group model attached to Exadata VM clusters, backup interfaces, and DNS endpoints.
This topic was covered before by my colleagues in previous post that can be found here and here. This blog is designed to enter more deeper into the NSG model and briefly show how an NSG attached or detach action shows-up in the logs.
During ODB Network provisioning, Oracle automation creates and manages a set of default Network Security Groups (NSGs). These NSGs are required to support core service behaviour such as intra-cluster communication, listener access, backup flows, DNS communication, and other internal service functions.
Every time a new ODB peering is made, or a new peered CIDR is added to an existing peering, the security rules of the default NSGs are updated.
The challenge is that the default model is designed for functionality first. In some customer environments, especially those with multiple peered CIDRs or internet outbound architectures, that baseline may be broader than the customer’s intended least-privilege posture.
Oracle-Managed NSGs and Why They Matter
Oracle AI Database@AWS uses Oracle-managed NSGs for system-level communication and default client connectivity within the ODB network. Depending on the deployment type and enabled features, customers may see NSGs such as:
- `EXA_STATIC_NSG`
- `EXA_1521_ADJUSTABLE_NSG`
- `EXA_BACKUP_STATIC_NSG`
- `EXA_BACKUP_ADJUSTABLE_NSG`
- `ADB_STATIC_NSG`
- `ADB_1521_2484_ADJUSTABLE_NSG`
- `DNS_NSG`
- `ZRCV_NSG`
- `ADBS_1521_1522_ ADJUSTABLE_NSG`
- `ADBS_ STATIC_NSG`
These NSGs are created automatically, populated by the automation, and attached to the relevant resources. Their role is straightforward: make the service function correctly and consistently. That includes internal communication inside the VM cluster, backup traffic, DNS flows, ICMP, and access to the database listener from the configured peered CIDRs. This eliminates the extra operational effort for the customers to configure.
The important detail is that these NSGs are also populated based on peered CIDRs. In other words, if the connectivity model becomes broader, the resulting default access model can become broader as well.
The Client Subnet Question
For Exadata VM clusters, three Oracle-managed NSGs are especially relevant on the client side:
`EXA_STATIC_NSG`
This NSG is used for intra-cluster communication and internal service traffic within the VM cluster. It is not the place to make casual edits. These rules support core functionality, and missing entries can affect cluster behaviour.
`EXA_1521_ADJUSTABLE_NSG`
This NSG is used for client connectivity on listener port `1521`. By default, it allows access from all peered CIDRs in the ODB network. In a simple environment, that may be acceptable. In a shared or transit-connected environment, it is often wider than the intended security model.
`DNS_NSG`
This NSG controls DNS ingress and egress and is attached to the private DNS listener endpoint. If the customer wants DNS resolution limited only to approved DNS forwarders, resolvers, or Route 53 integration points, then this default attachment usually deserves a closer review.
Why the Default Model Can Become Too Broad
This difference between the default configuration and the customer need becomes more visible in environments that implemented the internet outbound use case described in the A-Team architecture for Oracle Database@AWS internet egress. That architecture explains that outbound internet access is not provided by default and that customer designs may extend peered CIDR scope to route selected traffic through AWS infrastructure such as a Transit Gateway, Cloud WAN, NAT, or firewall path. It also notes that Oracle-managed NSGs in the shadow OCI side are updated based on peered CIDRs, which can increase the breadth of the effective access model.
That does not mean the automation is behaving incorrectly. It means the automation is doing exactly what it was built to do: maintain service functionality according to its expected baseline. Sometimes the baseline is too broad, and it does not meet the requirements or the customer needs.
Reconciliation Behaviour Is Expected
One important aspect of Oracle Database at AWS networking is understanding how Oracle-managed NSGs integrate with the service lifecycle.
Oracle-managed NSGs are designed to provide consistent, reliable connectivity for core service functionality. During ODB network modify or update operations, these NSGs are automatically reconciled to their expected baseline configuration. This ensures that required service communication paths, security dependencies, and platform integrations remain aligned with the supported service architecture.
This managed approach is consistent with the Oracle Database at AWS operational model, where AWS manages the ODB network and infrastructure lifecycle while OCI remains part of the overall service control plane.
This is why editing Oracle-managed NSGs directly is not a durable security solution.
Even if the immediate test succeeds, the change is not anchored to the service’s supported reconciliation model.
The Recommended Pattern
For customers who require more granular or application-specific security controls, Oracle recommends using customer-managed NSGs. This approach provides full and persistent control over custom security policies while allowing Oracle-managed NSGs to continue supporting essential platform functionality.
By separating platform-managed networking from customer-defined access controls, customers can implement least-privilege security models while maintaining alignment with the supported Oracle Database at AWS service architecture.
Adding custom rules to the NSGs attached to the VM cluster is covered in this blog published by Aditya.
1. Replace `EXA_1521_ADJUSTABLE_NSG` for client connectivity
For customers who require more granular or least-privilege access controls, replacing the default client connectivity NSG is often the simplest and most effective approach.
The recommended process is:
- Create a customer-managed NSG.
- Configure only the required ingress and egress rules for approved application connectivity.
- Attach the customer-managed NSG to the VM cluster.
- Detach EXA_1521_ADJUSTABLE_NSG from the VM cluster.
This approach provides customers with full and persistent control over client connectivity policies while allowing Oracle-managed NSGs to continue supporting required platform functionality.
2. Replace `EXA_STATIC_NSG` only with care
This is possible, but it is not recommended.
If the customer chooses to replace `EXA_STATIC_NSG`, the custom NSG must fully replicate the existing rule set before the Oracle-managed NSG is detached.
Any missing rule may affect database or cluster functionality.
3. Replace `DNS_NSG` if DNS access must be restricted
If the requirement is to allow DNS resolution only from approved sources such as on-premises resolvers or specific AWS Route 53 resolver endpoints, then a custom DNS NSG is the right pattern.
The sequence is:
- Create a customer-managed DNS NSG.
- Configure only the required DNS ingress and egress rules.
- Attach customer-managed NSG to the DNS listener endpoint.
- Detach `DNS_NSG`from the DNS listener endpoint.
Important Operational Considerations
There are a few rules here that should not be treated as optional guidance.
First, these changes must be performed per VM cluster. There is no single global replacement step that covers every cluster automatically.
Second, customer-managed NSGs are not reconcile or rewrote by the Oracle automation.
Third, Oracle-managed NSGs should not be deleted. They are required by automation and deleting them can cause failures.
Fourth, detached Oracle-managed NSGs must remain in the environment as inactive stubs. They should not be reattached unless needed, but they also should not be deleted.
Retaining detached Oracle-managed NSGs helps maintain alignment with service automation and the supported operational model, while allowing customers to implement least-privilege access controls using customer-managed NSGs.
Treatment Plan
In practice, I recommend splitting the work into three tracks.
Customer Managed NSGs attached to the VM cluster client vNic
Create new customer-managed NSGs that allow only approved client traffic flows. Attach these customer managed NSGs to the VM clusters client vNIC first. Then detach the automatically created adjustable NSGs but leave those Oracle-managed NSGs in place as unused objects.
DNS NSG
Create a customer managed DNS NSG and permit only the specific IP addresses or source ranges of the DNS systems that should resolve ODB network FQDNs through the OCI DNS listener endpoint. Attach the customer managed NSG to the DNS listener endpoint and detach the Oracle-managed `DNS_NSG`.
Monitoring and Audit
This model also has the advantage of being observable.
When an NSG is attached to or detached from a VM cluster, the action can be audited. This action triggers an update on the VM Cluster which will result in an update of the VNICS of the VMs from that cluster. That request had a “PUT” as action and the event is: “UpdateVnic”.
In the OCI Audit logs that action can be found under: “stateChange”>”Current”>”Current state”>”nsgIds”. I This field lists the OCIDs of the NSGs currently attached to the VM cluster. In the example below, a customer managed NSG was attached in addition to the default client connectivity NSGs. As a result, the audit log shows all three NSG OCIDs associated with the cluster. In the log you can observe the 3 OCIDs.
When a custom NSG is modified, those changes can be tracked in OCI Audit logs, including events such as `com.oraclecloud.virtualNetwork.RemoveNetworkSecurityGroupSecurityRules` and `com.oraclecloud.virtualNetwork.AddNetworkSecurityGroupSecurityRules`.
Bellow you can see an Audit log extract for adding a new security rule for the 0.0.0.0/0 CIDR for the 1234 port.
That gives customers a clean control point for change tracking and operational review.
One Final Detail: Backup Interfaces
The same design principles apply to the backup-side NSGs attached to the Exadata VM cluster. If the default backup interface rules are broader than required, customers can create custom backup NSGs, attach them first, detach the Oracle-managed adjustable or static backup NSGs, and keep the Oracle-managed versions as unused stubs.
That keeps the treatment plan consistent across client and backup interfaces.
Conclusion
Oracle-managed NSGs are designed to support the operational and networking requirements of the Oracle Database at AWS service. They provide a consistent baseline configuration that enables core platform functionality, service communication, and lifecycle automation.
At the same time, many enterprise environments require more granular, application-specific, or least-privilege access controls. Oracle Database at AWS supports this model through customer-managed NSGs, allowing organizations to implement security policies that align with their internal standards and compliance requirements.
The recommended approach is straightforward:
Retain Oracle-managed NSGs to maintain compatibility with service automation and the supported operational model
Avoid modifying Oracle-managed NSGs directly
Use customer-managed NSGs for externally exposed or application-specific connectivity requirements
Attach customer-managed NSGs before detaching Oracle-managed NSGs
Do not delete Oracle-managed NSG objects, even if they are detached and unused
This model allows customers to implement tighter security controls while preserving service stability, supportability, and alignment with the managed-service architecture of Oracle Databaseat AWS.