VCN Flow Logs

In OCI, communication between resources depends on the Virtual Cloud Network (VCN) configuration. Because of this, enabling network logging is important for monitoring traffic, debugging connectivity problems, and troubleshooting network issues.

In this article, we discuss the prerequisites and the enablement of VCN Flow Logs. In the next article, we will see how VCN Flow Logs can be used to troubleshoot network problems. VCN Flow Logs show network traffic details inside OCI and help us understand whether traffic was allowed or rejected. VCN Flow Logs are useful for auditing traffic and for troubleshooting security lists and NSGs.

When a connection does not work, we usually look for did information related to traffic status, source IP and Destination IP got involved in the communication. VCN Flow Logs help us answer these questions. Oracle says they record details about traffic that passes through a VCN and can help troubleshoot security lists and NSGs.

We could also consider flow logs as a Network traffic diary.

Flow logs are stored in the Logging service, so we first need a log group.

Create a Log Group

Logically a log group is like a folder that keeps related logs together.  Log group can be invoked from Observability & Management -> Logging -> Log groups.

We can create a log group by clicking “Create log group” button.

After that, the log group will be visible in OCI.

 

The next step is Create a capture fitler. Capture filter is a networking component that defines rules to selectively include or exclude specific traffic for VCN flow logs. It helps control costs and improve security monitoring by filtering traffic based on protocols, IP addresses, or ports before it is logged or mirrored.

Capture filter can be invoked from Networking -> Network command center -> Capture filters.

The capture filters support:

·        a sampling rate - Helps to control how much network traffic is captured in the flow logs.

·        include rules - Allow to capture only the traffic that matches specific conditions.

·        exclude rules - Helps ignore traffic that we do not want to capture in the flow logs.

·        filters based on CIDR, protocol, and traffic direction - Helps to narrow the captured traffic by source or destination network, type of protocol, and whether the traffic is incoming or outgoing.

 

 

Enable the Flow Log

In the OCI Console, we open Networking and then go to Network Command Center. From there, we open Flow logs.

In the Flow logs page, Click Enable Flow logs button.

Now we review the settings and enable the flow log.

The Flow creation requires a name, destination which is Log group and Filter to customize the logging and then the Enablement Points which is source for the Flow log.

The Enablement point cloud be VCN or Subnet or particular resource like targeting instances, load balancers, or network load balancers.  

VCN – It will enable flow logs to all VNIC registered with the VCN.

Subnet – It enables flow logs to VNIC which are registered with specific subnet.

Resources – We could specifically choose particular Instance, load balancer or Network load balancer.

For our exercise, lets go with subnet option. First let us choose a subnet which is not enabled with flow logging.

Now add enablement points as subnet and Enable the flow logs.

We could see the flow logs has been created for chosen subnet.

The same has been reflected in the subnet page (Subnet deails -> Monitoring)

At this stage the Subnet has been enabled with logging.  We will discuss about Troubleshooting the subnet traffic in the next article.

 OCI Events: Email Notification for Object Storage Updates

Oracle object storage is used in daily tasks like uploading backup data, archiving data, purging old data, etc. It will be very useful if we get notified about the changes happening in object storage. We can achieve this through OCI events. In this article we will go through the steps to configure OCI events for Object storage updates.

Object Storage Bucket → OCI Events Rule → OCI Notifications Topic → Email Alert

Whenever a new object is created in an OCI Object Storage bucket, OCI can generate an event, match it with an Events rule, and send an email notification through the Notifications service. OCI Events is designed to create notification based on resource state changes, and Object Storage supports emitting events for object state changes at the bucket level.

1)     Create an Object Storage Bucket

In the OCI console, open the navigation menu and move to Storage → Buckets. Select the compartment and click Create Bucket. Enter a bucket name and click Create

We will create events to capture the updates in this bucket.

---

2) Enable Event Emission for Object State Changes

For Object Storage to participate in this workflow, the bucket must emit events for object state changes. In the bucket details page, click Emit object events.

Click Enable button.

Now we could see Emit Object Events status is enabled in the console.

This allows OCI to generate an event when an object is created, updated, or deleted in the bucket.

3)  Create an OCI Notifications Topic

Next, create a topic that will receive messages from OCI Events.

In the OCI console, move to Developer Services -> Application Integration -> Notification services.

Click Topics and click Create Topic. Enter a topic name and click Create.

OCI Notifications uses topics as logical channels for publishing messages to subscribers.

4)  Add an Email Subscription

The next step is to add email as a subscriber to the topic.

Click the newly created topic and click Create Subscription.

Select protocol Email and enter email address that has to receive notification and click Create.

 

OCI will send a confirmation email to that address. The subscription remains pending until we confirm it.

5)  Confirm the Email Subscription

The email subscription will send a confirmation email to prescribed email ID. Open the confirmation email sent by OCI Notifications and click the confirmation link.

 

After confirming, In the OCI console, refresh the subscription page and verify the subscription status shows as Active. This step is mandatory, without this confirmation step, the email notifications will not be delivered.

 

6)  Create an OCI Events Rule

Now let’s create the rule that connects Object Storage events to the Notifications.

In the OCI console, choose Observability & Management → Events Service → Rules

Click Create Rule, enter a name and choose the event type related to Object Storage object creates.

For the action, choose Notifications and select the topic created earlier and click Create

7) Upload a File to the Bucket

Let’s test it now. In Object Storage bucket, Click Upload and Choose a file to upload and click Upload.

Once the object is created, OCI should emit the event, the Events rule should match it, and Notifications should send an email to the subscribed address. We can also enable notification for object delete, update.

---

8)  Verify the Email Notification

Check the mail inbox for the email notification generated by OCI. The below notification has been received for deleting an object from bucket.

At this point, we have a working event driven automation flow in your OCI tenancy.

 

 

OCI Logging – Auditing VCN Security list changes

In the previous post, we discussed how to audit VCN Security List changes. In this article, we will review how to audit VCN Route Table changes using OCI Audit service.

Route Tables control how traffic flows within a VCN. Any incorrect modification such as adding an Internet Gateway route or changing a DRG target can impact security posture, connectivity, or cost governance. Therefore, auditing route table changes is critical for enterprise cloud governance.

Login into OCI Console -> Networking -> VCN. It will show list of VCNS, we can choose the desired one.

In the VCN details page, choose Routing, it will list all the route tables associated with the VCN.

In this exercise we have only default route table with single route rule and the route rule is created for external access through Internet Gateway. We will add a route rule for Service Gateway.

Now route rule is added, we will use Audit to identify what changes happened in the route table.

OCI Audit is a native, always-on service that records all API operations across your tenancy. Any modification to a VCN Route Table (creation, update, or deletion) is captured here with full request payload and identity metadata.

Select:

• Compartment → root
• Set appropriate Time Range

Route Tables are network resources under specific compartments. Select the right compartment o see changes across all sub-compartments if required.

Once the timeframe is chosen the audit page will updated with all Event types recorded in that timeframe. Choose UpateRouteTable event type which is appropriate to our requirement.

Other available event types are below.

Event Name = UpdateRouteTable
Event Name = CreateRouteTable
Event Name = DeleteRouteTable

UpdateRouteTable event provides

·       Who made the change (User/Service Principal)

·       When it was made (Timestamp)

·       From which IP address

·       Target Resource OCID

·       Request/Response payload

 

In the JSON output, locate the stateChange section.

Inside stateChange, expand:

• previous
• current

Within these sections, examine routeRules.

By comparing the previous and current routeRules arrays, you can identify exactly what changed.

In our case:

• previous → One route rule
• current → Two route rules

This confirms that a new route rule was added.

In summary, OCI Audit logs provide a reliable and tamper-resistant mechanism to track route table changes, something the OCI Route Table UI itself does not natively provide.

 

OCI Logging – Auditing VCN Security list changes

In this article, we discuss a common governance requirement: auditing changes to a VCN Security List. VCN security list has set of firewall rules, but it doesn’t list information about when a rule has added/modified/removed. But this information will be very much required when we work on finding route cause of security related issues. It’s highly possible that security list changes would have created violations and we need to identify who changed what, when, and from where. 

Lets explore how OCI Audit helps to get the details. Choose a Security list and perform changes in the security list rules.

 

Add a Ingress security rule to the security list.

Add Ingress rule

Also add a egress rule to the security list.

Egress rule has been added.

We have added an Ingress and egress rule. Now our task is to identify when the ingress/egress rule has been changed and what changes have been done.

We can find the details at Observability Management -> Logging -> Audit. OCI Audit records control-plane events - meaning actions performed through the OCI Console, OCI CLI, SDK, Terraform, or APIs that create, update, or delete OCI resources.

In the Audit page, first select the compartment where you want to review activity. Audit entries record control-plane events, such as creating, updating, or deleting OCI resources.

The most important filter on this page is the Time range. By default, the console shows events from the last 5 minutes. When you open the Audit page, it loads all audit events that occurred within that default time window.

Other filters—such as User, Resource, Request action, and related fields will be populated based on the events retrieved for the selected compartment and time range. If you expand the time window (for example, last 1 hour or last 24 hours), you will see more events and more filter values available.

Another important filter is Event type. All audit events have event type. Choosing right event type will help us to reach the event that we look for. In this exercise, we target the security list changes. Event type having security list change is “com.oraclecloud.virtualNetwork.UpdateSecurityList”.

In case if we are not seeing this event type, then we may need to increase the Filter by time.

Once the event type is chosen, we could see the related events. In our case Ingress and Egress change have happened at different time, hence it has created two different Audit events.

Click the arrow button located in the right corner, that will expand the event.

The event contains many details. To identify what changed in the Security List, locate the stateChange section. It contains two parts:

• current: the Security List state after the change
• previous: the Security List state before the change

Comparing these two sections reveals exactly what was modified.

The current denotes the current status of security list and previous denotes the state of security list before change. Comparing both will give the details of the change.

Under the current we can find egressSecurityRules and ingressSecurityRules which has details of security rules.

Click the egressSecurityRules

Collect egressSecurityRules from previous section.

We could the difference is “2” which is present only in current version. It means a rule has been added by the update.

Checking ingressSecurityRules, we could see it has same number of rules for current and previous section, which means only egress rule got changed at this time.

Along with the actual changes, we can fine some additional details.

Timecreated -> the time the change has happened.
CompartmentId -> compartment of security list
VcnID -> OCID of VCN
id -> OCID of security list.

In summary, OCI Audit logs provide a reliable way to track and prove changes made to VCN Security Lists, something the Security List UI alone does not capture. 

  OCI Logging – Enable Flow logging for VCN

Oracle Cloud Infrastructure (OCI) provides built-in observability features to help you monitor cloud activity. For networking, VCN Flow Logs capture traffic flow metadata (source/destination IP, ports, protocol, direction, bytes/packets, and accept/reject status). This is very useful for troubleshooting connectivity, validating security posture, and supporting audits or penetration testing evidence.

In this article, we will enable Flow Logs at the subnet level and control the captured traffic using a Capture Filter.

To enable Logging to VCN, go to Network -> VCN -> Subnets page.

Click Monitoring tab and in the Monitoring page, we could see Logs section.

 We need to enable Flow Logs. Click the three dots located in the right side and click Enable Log option.

Specify compartment, Log location, Log group and Log name.

We ned to specify Capture filter, it’s a required parameter to enable log. We need to specify OCID of desired Capture filter.

The network activities will create huge amount of logs, OCI provides option to mention which traffic needs to be included or excluded from flow logs. The Capture Filter can be created in the Networking -> Network Command center -> Capture Filters.

Specify name, compartment for Capture filter. It can be created for either Flow log capture filter and VTAP. For our activity we need capture filter for Flow log. Sampling rate defines the percentage of network flows to be examined, we can specify one of the predefined percentage (1%,5%,10%,20%,25%,50%,100%).

The next section is defining rules which needs to included or excluded from flow logs. We can define upto 10 rules in a capture filter and it will follow the order to examine. If first rule is met then it will stop executing other rules, so we need to be careful with the rules.

The rules can also defined later in the capture filter. Suppose we are not sure about the traffic to be excluded/included, then we can leave with Traffic disposition as All (Accept and Reject) and Include/Exclude as Include, in that way we are making to include all the traffic without any condition.

Once the capture filter is created, copy the OCID of that.

Paste the OCID in the Subnet’s Enable resource log page that we discussed earlier.

It also gives option to specify retention period of captured logs. Its available in the Advanced option.

The default and minimum Log retention is 1 month and Maximum is 6 months.

 Click the Log name and in the Log details page, choose Explore log. We could see all the flow traffic captured in the log.