Monday, May 25, 2026

 

Send Email Notification When Object Is Uploaded to OCI Object Storage

In cloud environments mostly Object Storage is used as a landing zone for files, documents, logs, reports, images, and application data. Once a file is uploaded, teams often need an alert so that the next process can begin. This could be a manual review, downstream processing, file validation, or simply an operational notification. The desired requirement is to get alerted when an object is uploaded to bucket.

Oracle Cloud Infrastructure provides a simple event-driven approach for this requirement. We can use OCI Object Storage, OCI Events, and OCI Notifications to send an email whenever a new object is uploaded to a bucket.

In this article, we will configure an automated email notification flow. When a file is uploaded to an Object Storage bucket, OCI Events will detect the object creation event and send an email through OCI Notifications. We user OCI services OCI Object Storage, OCI Events, OCI Notifications.

OCI Object Storage is used to store the uploaded files.

OCI Events is used to detect the object upload activity.

OCI Notifications is used to send the email alert.

This is a serverless notification pattern. We do not need to manage any compute instance, scheduler, or custom polling script.

Prerequisites

Before starting the configuration, the following items should be available:

OCI tenancy access
Required compartment
Permission to create Object Storage bucket
Permission to create Notification topic
Permission to create Events rule
Valid email address for subscription

For this article, we will use a simple Object Storage bucket and one email subscription.

Create Object Storage Bucket

We will start by creating an Object Storage bucket.

From the OCI Console, we can navigate to Object Storage and create a new bucket in the required compartment.

 

Example bucket name:

object-upload-notification-bucket

The default bucket settings can be used for this activity. Once the bucket is created, it will be used as the source for upload events.

Enable Object Events for the Bucket

After creating the bucket, object events must be enabled for the bucket.

This is an important step. If object events are not enabled, OCI Events will not receive object-level activities from the bucket.

In the bucket console page, setting is available under the bucket details.

We can edit the bucket and enable:

Emit Object Events

After enabling this option, Object Storage can publish events when objects are created, updated, or deleted.

Create Notification Topic

Next, we will create a Notification topic. Click Developer Services -> Application Integration -> Notifications.

The Notification topic acts as the target for the Events rule. When the Events rule matches an object upload event, it sends the message to this topic.

 

Example topic name:

object-upload-email-topic

After the topic is created, it will be used as the action target in the Events rule.

Create Email Subscription

After creating the topic, we need to add an email subscription.

The subscription has multiple protocols; in this article we use Email. The email address should be the recipient address where upload alerts need to be sent.

Once the subscription is created, OCI sends a confirmation email to the recipient. The subscription remains in pending status until the confirmation link is accepted.

The email subscription must be confirmed before notifications can be received.

After confirmation, the subscription status changes to active.

Create Events Rule

Now we will create an Events rule.

The Events rule is responsible for capturing the Object Storage upload event and triggering the Notification topic.

From the OCI Console, we can navigate to Events Service through observability & Managemetn -> Events service -> Rules. and create a new rule.

Example rule name:

object-upload-email-rule

The rule condition should match the Object Storage object creation event.

The event type should be related to:

Object Storage - Create Object

This event is generated when a new object is uploaded into Object Storage.

To keep the rule specific, we can also add a condition for the bucket name. This helps us avoid sending alerts for every bucket in the compartment.

Example condition:

bucketName = object-upload-notification-bucket

This means the rule will only match object upload events from this specific bucket.

Configure Rule Action

After defining the rule condition, we need to configure the action.

The action type should be:

Notifications

The target topic should be:

object-upload-email-topic

Once the rule is created, OCI Events will monitor object creation events and send matching events to the Notification topic.

Upload Test File

After the Events rule is created, we can test the setup by uploading a file to the Object Storage bucket.

Example file name:

Sample_test.txt

Once the file is uploaded, Object Storage emits a create object event. OCI Events evaluates the event and sends it to the Notification topic. The subscribed email address receives the alert.

In most cases, the email is delivered within a short time. A small delay is normal.

Validate Email Notification

After the test file is uploaded, we can check the subscribed email inbox.

The notification email usually contains event details in JSON format. The message includes useful information such as:

eventType
eventTime
compartmentId
bucketName
objectName
namespace
resourceName

The most important values for this use case are:

bucketName
objectName
eventType
eventTime

These values confirm which object was uploaded and when the event occurred.

Sample Notification Payload

The email message may include an event payload similar to the following:

This payload confirms that the uploaded object triggered the event successfully.

 

 OCI Service Connector Hub: Move Logs from OCI Logging to Object Storage

Oracle Cloud Infrastructure provides centralized logging through the OCI Logging service. Logs are very useful for troubleshooting, auditing, security review, and operational analysis. However, in many real-time environments, we may need to retain logs for a longer period, store them in a centralized location, or keep them for compliance and future analysis.

The Logs could be VCN Flow Logs, Load balancer Logs, API Gateway logs, Object storage logs or any custom logs. By doing this we can store logs beyond the default log retention period. OCI Object storage is perfect location to store logs and even we can store logs in the archive storage to reduce the cost.

OCI Connector Hub helps to move data between OCI services. It can move log data from OCI Logging to targets such as Object Storage, Streaming, Logging Analytics, Monitoring, Functions, and Notifications. For this article, we will configure a connector to move logs from OCI Logging to OCI Object Storage.

Prerequisites

Before starting this activity, make sure the following resources are available:

  • OCI tenancy access
  • Required compartment
  • OCI Logging enabled for any OCI service
  • Object Storage bucket
  • Permission to create Service Connector Hub connector
  • Permission to read logs and write objects into Object Storage

 

Step 1: Create Object Storage Bucket

First, we will create an Object Storage bucket to store archived logs.

Open the OCI Console.

Go to:

Storage → Object Storage & Archive Storage → Buckets

Choose the correct compartment and click Create Bucket, provide a bucket name.

Example:

oci-logging-archive-bucket

Keep the default storage tier as Standard unless Archive Storage is specifically required.

Click Create.

After the bucket is created, open the bucket and confirm that it is empty.

Step 2: Identify the Source Log in OCI Logging

Now we need to identify the log that we want to move into Object Storage.

Go to:

Observability & Management → Logging → Logs

Select the correct compartment.

Review the available log groups and logs.

For this article, select the log group and log that need to be archived.

Example:

Log group : VCN_Flow_logs

Log Name: VCN_Flow_Log_1

Open the log and confirm that log records are available.

Step 3: Create Service Connector

Now we will create the Service Connector.

Go to:

Analytics & AI → Messaging → Connector Hub

Click Create Connector.

Provide a connector name.

Example:

logging-to-object-storage-connector

Select the compartment where the connector should be created. Under Configure connector, select:

Source: Logging
Target: Object Storage

 

Step 4: Configure Source Connection

In the source connection section, select the log details.

Choose:

Compartment: <compartment where log exists>
Log Group: <log group name>
Logs: <log name>

If needed, we can add multiple logs by using the Another Log option.

For this article, we are selecting one log.

Step 5: Optional Filter Configuration

Service Connector Hub also allows filtering the log data before sending it to the target. This is useful when we do not want to archive every log record.

For example, in VCN Flow Logs, we may want to move only rejected traffic logs.Example filter idea:

data.action = 'REJECT'

For this article, we will not apply any filter. We will move all selected log records to Object Storage.

Step 6: Configure Target Connection

In the target connection section, select the Object Storage bucket.

Choose:

Compartment: <bucket compartment>
Bucket: oci-logging-archive-bucket

This is where the log files will be stored.

Step 7: Create Required Policy

While creating the connector, OCI may prompt us to create the required policy.

If prompted, click Create.

This policy allows the Service Connector to read from OCI Logging and write objects into the selected Object Storage bucket. By clicking Create button a policy statement gets created with below statement.

allow any-user to manage objects in compartment id ocid1.compartment.oc1..aaaaaaaa where all {request.principal.type='serviceconnector', target.bucket.name='oci-logging-archive-bucket', request.principal.compartment.id='ocid1.compartment.oc1..aaaaaaaaj'}

If the user is part of the Administrators group, this may already be allowed. Otherwise, proper IAM policies are required.

Step 8: Verify Connector Status

After the connector is created, open the connector details page.

Verify the connector status.

The connector should show as active.

Review the following details:

Source: Logging
Target: Object Storage
Status: Active

Step 9: Generate Log Activity

Now we need to generate some log activity.

The activity depends on the source log selected.

Examples:

For VCN Flow Logs:

  • Connect to a compute instance
  • Run ping, SSH, curl, or any network traffic
  • Generate accepted or rejected traffic based on security rules

For Load Balancer Logs:

  • Access the load balancer endpoint

For Object Storage Logs:

  • Upload or download an object

Wait for a few minutes for logs to be processed and delivered.

 

Step 10: Validate Logs in Object Storage

Go to:

Storage → Object Storage & Archive Storage → Buckets

Open the bucket:

oci-logging-archive-bucket

Check whether log objects are created. We should see objects created by the Service Connector.

Open the object and review the content.

The logs are usually delivered in structured format, and the object names are automatically generated.

 

Step 11: Download and Review the Log File

Download the log files from Object Storage.

Open the file in a text editor.

Review the log records.

Example fields may include:

datetime
logContent
data
source
type
oracle

 Example:

{"id":"de9bb2f0","time":"2026-05-25T17:18:56Z","oracle":{"compartmentid":"ocid1.compartment.oc1..aaaaaaaaj7vcmtjkoungbmz5x3o2di56ewryi54vcoj5e5qsas4r7h52fxiq","filterOcid:":"DEFAULT_CAPTURE_FILTER","ingestedtime":"2026-05-25T17:20:41.335Z","instanceOcid:":"VNICaaS:ocid1.vnic.oc1.iad.abuwcljtazluubqqhm7jz6vbd6ri2kz2e3jkyvqj6m6tbej2exo4znzrfohq","loggroupid":"ocid1.loggroup.oc1.iad.amaaaaaaq444raaanpcwllthfwrfc3cllmuvrqb5nbs37ahx2bbtwzjggxpq","logid":"ocid1.log.oc1.iad.amaaaaaaq444raaa5f6vthyw6ev647d4zfg367yfrkxd4susqlhr75jeidma","managed":"true","resourceId":"ocid1.privateendpoint.oc1.iad.aaaaaaaael4mvgs4m5connq4c2yfpvl7rcdkhwhdpbkovflfbs3ykkz5tpka","resourceType":"PrivateEndpoint","tenantid":"ocid1.tenancy.oc1..aaaaaaaacq5gprsqz26em4koaokcntrpey4adi7mzzgve53cm44ozbxa4z4a","vcnOcid":"ocid1.vcn.oc1.iad.amaaaaaaq444raaaffljepgvsc4dbzvq7cq4xeh7ufc76hmagrsqae4zhlvq","vniccompartmentocid":"ocid1.compartment.oc1..aaaaaaaaj7vcmtjkoungbmz5x3o2di56ewryi54vcoj5e5qsas4r7h52fxiq","vnicocid":"ocid1.vnic.oc1.iad.abuwcljtazluubqqhm7jz6vbd6ri2kz2e3jkyvqj6m6tbej2exo4znzrfohq","vnicsubnetocid":"ocid1.subnet.oc1.iad.aaaaaaaaazzsdkncfvrvco6vbt5ctxwzz22gmqfh7uwlldmxa732phlzg3ma"},"source":"-","specversion":"1.0","subject":"-","type":"com.oraclecloud.vcn.flowlogs.QualityEvent.NoData","data":{"flowid":"de9bb2f0","version":"2","status":"NODATA","startTime":1779729536,"endTime":1779729597}}

 

The exact fields depend on the OCI service log type. This confirms that logs are successfully moved from OCI Logging to Object Storage.

 

Saturday, May 23, 2026

 Resolve Private DNS Hostnames Across Cross-Tenancy Peered OCI VCNs

In the previous article, we created private connectivity between two OCI tenancies using cross-tenancy VCN peering through DRG. We used this setup to allow an Autonomous Database in one tenancy to communicate privately with a VM database in another tenancy.

In this article, we will extend that setup and configure private DNS resolution across the peered VCNs. Private network connectivity allows resources to communicate using private IP addresses, but hostname resolution across VCNs or tenancies does not always work automatically. For applications and database connections, using hostnames is often better than using hardcoded private IP addresses.

In this setup, we will have instances in different tenancies. The details are as below. We have two VCNs connected using cross-tenancy VCN peering through DRG.

Component

Value

Source VCN

DBSource

Source VCN CIDR

192.168.0.0/16

Source hostname

windows-instance.sub05070237210.dbsource.oraclevcn.com

Source private IP

192.168.0.213

Destination VCN

DBVCN

Destination VCN CIDR

10.0.0.0/16

Destination hostname

db19c.sub05052324220.dbvcn.oraclevcn.com

Destination private IP

10.0.0.169

Connectivity

Cross-tenancy VCN peering through DRG

The requirement is:

windows-instance.sub05070237210.dbsource.oraclevcn.com

should be able to resolve:

db19c.sub05052324220.dbvcn.oraclevcn.com

to:

10.0.0.169

High-Level Architecture

The private DNS resolution flow will look like this:

Windows instance in DBSource VCN
        |
        | DNS query for db19c.sub05052324220.dbvcn.oraclevcn.com
        
DBSource VCN Resolver
        |
        | Resolver rule forwards dbvcn.oraclevcn.com queries
        
DBSource Forwarding Endpoint
        |
        | Cross-tenancy DRG peering
        
DBVCN Listening Endpoint
        |
        | Resolves using DBVCN private DNS view
        
db19c.sub05052324220.dbvcn.oraclevcn.com → 10.0.0.169


Prerequisites

Before configuring Private DNS, we need to make sure the following are already in place:

  • Cross-tenancy VCN peering through DRG is configured between DBSource and DBVCN.

  • Route tables allow traffic from 192.168.0.0/16 to 10.0.0.0/16.

  • Route tables allow return traffic from 10.0.0.0/16 to 192.168.0.0/16.

  • Security lists or NSGs allow DNS traffic between the resolver endpoint subnets.

For DNS communication we can allow only UDP port 53 and TCP port 53, as both protocols are required.

 Step 1: Confirm Source and Destination Hostnames

First, confirm the private hostnames and private IP addresses.

Source Instance

Source instance details:

VCN: DBSource
Hostname: windows-instance.sub05070237210.dbsource.oraclevcn.com
Private IP: 192.168.0.213

Destination Instance

Destination VM database details:

VCN: DBVCN
Hostname: db19c.sub05052324220.dbvcn.oraclevcn.com
Private IP: 10.0.0.169

Before Private DNS forwarding is configured, we may be able to reach the destination private IP if routing and security are correct:

Test-NetConnection 10.0.0.169 -Port 1521

But hostname resolution may fail:

nslookup db19c.sub05052324220.dbvcn.oraclevcn.com

Step 2: Create a Listening Endpoint in Destination VCN DBVCN

Since the hostname belongs to the destination VCN, create a listening endpoint in DBVCN.

Go to:

OCI Console
→ Networking
→ Virtual Cloud Networks
→ DBVCN
→ DNS Resolver

→ Choose Endpoints in DNS resolver page.

→ Create Endpoint

Select:

Endpoint type: Listening
VCN: DBVCN
Subnet: Select a private subnet in DBVCN
Endpoint IP: Auto-assigned or manually selected

After the endpoint is created, note the listener endpoint IP address. This IP address will be used in the resolver rule in the source VCN.


 Also create a Private view. In the DBVCN private resolver, open Associated private views and ensure the DBVCN private view is associated with the resolver. This allows the DBVCN listener endpoint to resolve private DNS records that belong to the DBVCN DNS domain.

Choose DBVCN as Private view and click Save changes.

Step 3: Create a Forwarding Endpoint in Source VCN DBSource

Now create a forwarding endpoint in the source VCN DBSource.

Go to:

OCI Console
→ Networking
→ Virtual Cloud Networks
→ DBSource
→ DNS Resolver


→ Endpoints
→ Create Endpoint

Select Endpoint type: Forwarding
VCN: DBSource
Subnet: Select a private subnet in DBSource
Endpoint IP: Auto-assigned or manually selected

Click Create Endpoint Button.

As the next step, create resolver rule.

Step 4: Create a Resolver Rule in DBSource

Now create a resolver rule in the source VCN resolver. This rule forwards DNS queries for the destination VCN domain to the DBVCN listening endpoint.

Go to:

OCI Console
→ Networking
→ Virtual Cloud Networks
→ DBSource
→ DNS Resolver
→ Rules
→ Create Rule

Create a forwarding rule:

Click Add Rule button.

In Match condition, Rule Condition: Domains
Domain: dbvcn.oraclevcn.com

Rule:

Action: Forward
source Endpoint: The forward endpoint created in last step.
Destination IP:  It is the IP of Listener endpoint we created in Destination VCN.

Click Save Changes.

Step 5: Validate DNS Resolution from Source Windows Instance

Log in to the source Windows instance:

windows-instance.sub05070237210.dbsource.oraclevcn.com

Run:

nslookup db19c.sub05052324220.dbvcn.oraclevcn.com

In case we need this hostname resolution in reverse way then we need to create Listener endpoint at source and Forwarder endpoint.

  Oracle AI Database@Azure: Why It Matters and When to Use It Oracle Database@Azure was announced by Oracle and Microsoft in September 202...