7.2 OCI Events, Event Rules & OCI Notifications Fan-Out

5.4 OCI Events, Event Rules & OCI Notifications Fan-Out

OCI Events Service Architecture & Principles

Enterprise cloud governance and modern Site Reliability Engineering (SRE) require near real-time awareness of operational state changes across the cloud estate. Rather than running inefficient polling daemons that query OCI APIs periodically, modern cloud architectures rely on the OCI Events Service.

OCI Events Service is a fully managed, decentralized event backbone that tracks operational lifecycle transitions, resource state modifications, and system alerts generated by OCI services. It operates entirely without compute agents, sidecars, or manual instrumentation: whenever an administrator provisions an Autonomous Database, an Object Storage object is uploaded, a compute instance unexpectedly stops, or OCI Cloud Guard detects a security posture drift, the underlying service control plane automatically publishes a structured event record to the Events Service.

Key architectural characteristics include:

• Agentless: services emit events themselves; you only write rules.
• Broad coverage: events can represent create, update, and delete operations, lifecycle state changes, or system events such as a backup completing or failing.
• Object events are opt-in per bucket: Object Storage emits object-level events (such as object created) only when Emit Object Events is enabled on the bucket.

---

The CloudEvents Schema Anatomy

OCI events follow the Cloud Native Computing Foundation (CNCF) CloudEvents format. The envelope identifies the specification version in the cloudEventsVersion field, which is 0.1 for OCI events, and the event schema version in eventTypeVersion. The following is Oracle's example event emitted when a bucket is deleted:

Every event emitted in OCI contains a standardized JSON envelope encapsulating metadata and a resource-specific data payload:

{
  "cloudEventsVersion": "0.1",
  "eventID": "<unique_ID>",
  "eventType": "com.oraclecloud.objectstorage.deletebucket",
  "source": "objectstorage",
  "eventTypeVersion": "1.0",
  "eventTime": "2019-01-10T21:19:24Z",
  "contentType": "application/json",
  "extensions": { "compartmentId": "ocid1.compartment.oc1..<unique_ID>" },
  "data": {
    "compartmentId": "ocid1.compartment.oc1..<unique_ID>",
    "compartmentName": "example_name",
    "resourceName": "my_bucket",
    "resourceId": "ocid1.bucket.oc1..<unique_ID>",
    "freeformTags": { "Department": "Finance" },
    "additionalDetails": { "namespace": "example_namespace", "publicAccessType": "NoPublicAccess" }
  }
}

Core Envelope Attributes

• eventType: A reverse-domain string that identifies the action, such as com.oraclecloud.objectstorage.createobject or com.oraclecloud.objectstorage.deletebucket.
• source: The service that emitted the event, such as objectstorage.
• eventTime: The exact UTC ISO-8601 timestamp when the state transition occurred.
• data: A rich JSON object providing the tenancy OCID, compartment OCID, resource OCID, friendly resource name, and additionalDetails containing service-specific contextual metadata.

---

Event Rules & Filtering Engine

Architects define Event Rules to capture specific operational occurrences within a tenancy or compartment hierarchy. When an event is emitted, the Events engine matches the event against active rules:

1. Compartment Boundary: Rules can be scoped to a single compartment or configured to evaluate all sub-compartments recursively down the tenancy tree.
2. Filtering Conditions:
   • Service Name: Filters by service provider (e.g., Compute, Storage, Database, IAM).
   • Event Type: Multi-select filtering on specific actions (e.g., Instance - Launch End, Instance - Terminate End).
   • Attribute Filters: Exact key-value matching on fields within the data payload, such as resourceId, compartmentId, or nested additionalDetails attributes (e.g., matching a specific bucket name: data.additionalDetails.bucketName = 'financial-audits').
   • Advanced Pattern Matching: Custom JSON filter expressions enabling complex boolean logic (AND, OR, wildcard prefixes).

Target Action Dispatch

When an event satisfies a rule's conditions, the Events Service immediately dispatches the event payload to up to three native target action types:

• OCI Notifications (ONS): Publishes the event JSON to an ONS Topic for multi-channel fan-out.
• OCI Functions: Invokes an OCI Function directly, passing the full CloudEvent JSON payload to the function's container runtime for automated programmatic remediation.
• OCI Streaming: Writes the event record to an OCI Stream partition, buffering high-volume audit logs for ingestion into external Kafka clusters, SIEM platforms, or data lakes.

---

OCI Notifications (ONS) Architecture & Multi-Channel Fan-Out

OCI Notifications (ONS) is a fully managed, publish/subscribe messaging engine designed for high-throughput, low-latency broadcast delivery. In an enterprise event-driven architecture, ONS acts as the fan-out distribution hub:

OCI Events Service (Rule Matched)
          │
          ▼
   ONS Topic: SecurityAlerts
          ├── Protocol 1: Email ───────────────> CISO & SOC Distribution Lists
          ├── Protocol 2: PagerDuty ───────────> Automated On-Call Escalation
          ├── Protocol 3: Slack ───────────────> DevOps ChatOps Channel
          ├── Protocol 4: HTTPS Webhook ───────> ServiceNow Incident Automation
          └── Protocol 5: OCI Functions ───────> Auto-Quarantine Serverless Script

ONS Subscriptions & Protocol Endpoints

An ONS Topic is a communication channel to which publishers send messages. Consumers subscribe to topics using one or more supported protocols:

• HTTPS (Custom Webhook): Delivers messages via HTTP POST with JSON payloads to external incident management platforms (e.g., ServiceNow, Jira, custom webhooks). Supports basic authentication and custom verification headers.
• PagerDuty: Native integration for operational incidents; automatically pages on-call engineers when critical production alarms fire.
• Slack: Sends the message to a Slack channel. Other chat tools, such as Microsoft Teams, are reached through the HTTPS (Custom URL) protocol or a function.
• Email: Sends human-readable operational alerts and metric summaries to engineering teams.
• OCI Functions: Triggers a serverless function, allowing notification messages to drive secondary automated workflows.
• SMS: Sends text messages to phone numbers in supported countries.

Notifications delivers each message at least once per subscription. If an endpoint does not acknowledge a message, the service retries immediately and then with exponential backoff until the subscription's retry duration ends (two hours by default), after which the message is discarded. Design receivers to be idempotent and to acknowledge quickly.

---

Enterprise Incident Response & Automation Patterns

By combining OCI Events and OCI Notifications, enterprise architects replace brittle cron jobs and manual runbooks with automated, event-driven remediation pipelines:

Pattern 1: Automated Security Posture Remediation

When a developer inadvertently modifies a Network Security Group to allow unrestricted ingress (0.0.0.0/0 on port 22):

1. OCI Cloud Guard detects the compliance violation and emits com.oraclecloud.cloudguard.problemdetected.
2. An Event Rule matches the event type and dispatches to two targets simultaneously:
   • An ONS Topic that sends a high-priority PagerDuty incident alert and posts an incident card to the #secops-alerts Slack channel.
   • An OCI Function that parses the resourceId and immediately removes the non-compliant CIDR rule using Resource Principals.

Pattern 2: Alarm-Driven Notification and Remediation

1. A Monitoring alarm on a production metric moves to the FIRING state.
2. The alarm publishes to an ONS topic.
3. The topic fans out to an email list, a PagerDuty service, and a function that collects diagnostic information or scales the affected resource.
4. When the alarm returns to OK, a second message tells the on-call team the incident has cleared.

Pattern 3: Serverless Document Processing Pipeline

1. A customer uploads an invoice PDF to an Object Storage bucket.
2. Object Storage emits com.oraclecloud.objectstorage.createobject.
3. An Event Rule filters on the bucket name invoices-inbound (the bucket has Emit Object Events enabled) and invokes an OCI Function.
4. The function reads the object, triggers OCI Document Understanding AI to extract invoice line items, and persists the structured records to Autonomous Database.

---

Target Action Comparison