Oracle Cloud

Comparison Table

Deployment Best Practices

• Multi-AD Regions: For maximum redundancy, deploy your application nodes across multiple ADs.
• Single-AD Regions: In regions with only one AD, you must use all three Fault Domains to ensure high availability.
• Resource Distribution: When launching multiple compute instances, OCI automatically cycles through FDs to distribute the load, but you can also manually specify them.

Strategic Services for Single-AD Availability

Beyond Fault Domains, OCI uses specific service architectures to maintain uptime in single–AD environments.

• Regional Services: Many OCI services are "regional" by design, meaning they are automatically distributed across all infrastructure in the region regardless of AD count. This includes:
  • Object Storage: Data is replicated across multiple storage nodes and Fault Domains.
  • Virtual Cloud Network (VCN): Subnets can be defined as Regional Subnets, automatically placing resources across all Fault Domains.
  • Load Balancers: When configured as "Regional," the Load Balancer nodes are automatically placed in different Fault Domains to ensure traffic flow continues if one FD fails.
• Block Volume Replication: While a Block Volume resides in a specific AD, users can use Policy-Based Backups to replicate data to different regions for disaster recovery.
• Flexible Infrastructure: OCI allows for "Burstable" instances and "Reserved Capacity" to ensure that even during hardware failures in one FD, there is enough capacity in others to restart workloads.

Best Practices for Single-AD Regions

• Use Regional Subnets: Always prefer regional subnets over AD-specific subnets to allow your resources to move or scale across FDs seamlessly.
• Distribute Workloads: Manually or via orchestration (like Terraform), ensure that your web servers, application servers, and database nodes are spread across FD1, FD2, and FD3.
• Cross-Region Copy: For mission-critical data, utilize Cross-Region Replication for Object Storage and Block Volume backups to protect against a total regional outage.

The OCI Service Gateway is a networking component that provides a path for private traffic between a Virtual Cloud Network (VCN) and supported Oracle services. Its primary purpose is to allow resources in a private subnet to access Oracle services without assigning public IP addresses to those resources.

How the Service Gateway Functions

The Service Gateway functions as a specialized router within the VCN. It uses a specific routing configuration to direct traffic internally through the Oracle Services Network.

• Private Connectivity: Traffic originating from a private instance stays entirely within the Oracle network fabric. It never traverses the public internet.
• Service CIDR Labels: Instead of using specific IP addresses, you use a Service CIDR Label (e.g., All <Region> Services in Oracle Services Network) in your route table. This label automatically encompasses all public IP ranges for Oracle services like Object Storage, Autonomous Database, and Streaming.
• No Public IPs Required: Instances do not need a Public IP or a NAT Gateway to communicate with these services.
• Source IP Preservation: When an instance communicates via a Service Gateway, the service sees the instance's private IP address, which can be useful for security and auditing.

Service Gateway vs. Other Gateways

Security and Prevention of Public Exposure

The Service Gateway prevents public internet exposure through several layers of control.

• Routing Control: By adding a route to the Service Gateway in the route table of a private subnet, you ensure that traffic destined for Oracle services is intercepted before it can reach an Internet Gateway.
• Network Security Groups (NSGs): You can define egress rules that only allow traffic to the Service Gateway's CIDR label, blocking all other outbound traffic.
• IAM Policies: Access to the services themselves is still governed by Identity and Access Management (IAM), ensuring that only authorized resources can interact with the data, even though the path is private.
• Service-Level Access: You can configure "Network Sources" or bucket policies in Object Storage to restrict access so that data can only be accessed via a specific VCN or Service Gateway.

Common Use Cases

• Backups: Backing up an on-premises database to OCI Object Storage via FastConnect and a Service Gateway.
• Patching: Allowing private instances to download OS updates from the Oracle Yum repository without internet access.
• Data Processing: Moving data from a private subnet to an Autonomous Data Warehouse for analysis.

The OCI Backbone Network is designed to function like a high-performance on-premises data center network but at a global scale. It achieves consistent, non-oversubscribed performance through a combination of flat topology and advanced hardware virtualization.

Core Mechanisms of Non-Oversubscribed Performance

Unlike traditional cloud networks that share resources and can suffer from "noisy neighbor" effects, OCI utilizes specific architectural choices:

• Flat, Non-Blocking Clos Topology: OCI uses a multi-tier Clos network (specifically an N-tier design). This ensures that every server has the same number of hops to any other server within an Availability Domain, providing predictable latency and massive "bisection bandwidth."
• Off-Box Network Virtualization: OCI moves network virtualization (the process of managing the VCN and security) off the server’s CPU and hypervisor and onto dedicated hardware. This eliminates "jitter" and ensures that the compute instance’s performance is never throttled by network overhead.
• 1:1 Oversubscription Ratio: While many providers oversubscribe their network (assuming not everyone will use their full bandwidth at once), OCI is designed for a 1:1 ratio. This means if you are provisioned for 25 Gbps, that bandwidth is physically available and guaranteed throughout the fabric.
• Massive Port Density: Each Availability Domain is built to support approximately 1 million network ports, allowing for massive horizontal scaling without creating bottlenecks.

Performance Comparison: OCI vs. Traditional Cloud Networking

Key Performance Attributes

• Low Latency: Within an Availability Domain, OCI typically achieves sub-100 microsecond latency between hosts.
• RDMA Cluster Networking: For specialized workloads like AI training or Big Data, OCI offers Remote Direct Memory Access (RDMA) over Converged Ethernet (RoCE), allowing servers to communicate at 1.5 microsecond latency by bypassing the OS stack entirely.
• Global Backbone: Inter-region traffic travels over a private, Oracle-owned fiber network rather than the public internet. This provides consistent jitter and bandwidth for disaster recovery and real-time data replication.
• Service Level Agreements (SLAs): OCI is unique in offering a Performance SLA, guaranteeing that the network will consistently deliver the speed and latency promised.

In Oracle Cloud Infrastructure (OCI), a Compartment is a primary building block used to organize and isolate cloud resources. Unlike physical data centers or networks, a compartment is a logical collection of related resources (such as instances, VCNs, and block volumes) that can be accessed only by those groups that have been given permission by an administrator.

How Compartments Work

• Logical Container: A compartment is not a physical location; it is a way to group resources regardless of which region they reside in.
• Hierarchy: Compartments can be nested to create a tree structure. You can have up to six levels of nested compartments starting from the Root Compartment (the tenancy itself).
• Global Scope: A compartment spans all regions within a tenancy. If you create a compartment named "Production," it exists in every region you have subscribed to.

Simplifying Resource Isolation and Governance

Compartments simplify cloud management by separating the resource itself from the permissions required to manage it.

Simplifying Resource Isolation and Governance

Compartments simplify cloud management by separating the resource itself from the permissions required to manage it.

Core Governance Principles

• Policy Attachment: Policies follow the hierarchy. If you apply a policy at the Root level, it applies to all sub-compartments. If you apply it to a sub-compartment, it is restricted to that specific branch.
• Resource Movement: Most resources can be moved from one compartment to another without downtime, though the associated policies will change based on the new parent compartment.
• Tagging Integration: Compartments work seamlessly with Cost-Tracking Tags, allowing for granular financial governance across complex organizational structures.
• Default Deny: By default, a user has no access to any compartment. Access must be explicitly granted via an IAM policy.

Design Best Practice

A common strategy is to design compartments based on Organizational Structure (e.g., HR, Finance) or Software Development Lifecycle (e.g., Dev, Test, Prod). This ensures that developers cannot accidentally touch production resources while still allowing them full freedom in their designated sandbox.

An OCID (Oracle Cloud Identifier) is a unique, Oracle-assigned ID for every resource created in Oracle Cloud Infrastructure. Whether it is a compute instance, a VCN, or a specific IAM policy, the OCID acts as the "address" for that resource across all OCI APIs and the Console.

OCID Structure

An OCID follows a specific syntax that allows both users and the OCI system to identify the resource type, its location, and its specific identity. The format is:

Component Breakdown

Key Characteristics of OCIDs

• Immutability: Once a resource is created, its OCID never changes, even if you rename the resource or move it to a different compartment.
• Global Uniqueness: No two resources in the entire Oracle Cloud ecosystem will ever share the same OCID.
• Global vs. Regional:
  • Regional Resources: (e.g., Instances, VCNs) include the region name in the OCID.
  • Global Resources: (e.g., Compartments, IAM Users, Groups) leave the region field blank (e.g., ocid1.tenancy.oc1..uniqueID).
• API Integration: When using the OCI CLI, SDKs, or Terraform, you almost always reference resources by their OCID rather than their display name, as display names are not required to be unique.

How to Find an OCID

• OCI Console: Every resource page has a "Resource Details" section where you can click "Copy" next to the OCID.
• CLI/SDK: When you list resources via the command line, the id field in the JSON output contains the OCID.
• Audit Logs: Every action tracked in the OCI Audit service logs the OCID of the resource that was modified or accessed.

In traditional cloud environments (Gen 1), the software that manages the network (the hypervisor and virtual switch) runs on the same physical CPU as the customer’s Virtual Machine. OCI’s Off-box Network Virtualization moves these tasks to a dedicated, custom-designed hardware layer.

How Off-box Virtualization Works

Instead of the host CPU handling network encapsulation, security rules, and routing, OCI uses a specialized SmartNIC or Network Interface Card that sits outside the host server.

• Decoupling: The network control plane is physically separated from the compute host.
• Hardware-Based: Network processing is handled by dedicated silicon (ASIC) rather than software running on the Intel/AMD/Ampere processor.
• Encapsulation: All Virtual Cloud Network (VCN) logic is executed on this external card before traffic ever reaches the host's physical port.

Impact on Performance and Security

Key Benefits for Users

• No "Noisy Neighbors": Because the network processing is hardware-isolated, another tenant's heavy network usage on the same physical server cannot slow down your network performance.
• Bare Metal Support: This technology is what allows OCI to offer Bare Metal Cloud Instances. Since the network virtualization is "off-box," Oracle can give you a raw physical server while still connecting it securely to your private VCN.
• Improved Security Posture: Since the network virtualization layer is not accessible from the host OS, it is much harder for malicious actors to spoof IP addresses or bypass security lists.

Core Advantage Summary

• Performance: Higher IOPS and lower latency for database and HPC workloads.
• Reliability: Predictable performance that meets strict Service Level Agreements (SLAs).
• Security: Stronger layer of protection between the tenant's environment and the cloud infrastructure provider.

Oracle Cloud Free Tier is split into two distinct parts: a time-limited Free Trial for testing premium services and a set of Always Free services that remain available as long as your account is active.

Key Differences at a Glance

Always Free Services (Perpetual)

These resources are intended for small-scale development, learning, or hosting low-traffic applications.

Compute:

• AMD-based: 2 Virtual Machines (VM.Standard.E2.1.Micro) with 1 GB RAM each.
• Arm-based: Up to 4 instances of Ampere A1 Compute with 24 GB of RAM and 4 OCPUs (shared across the instances).

Storage:

• Block Volume: 200 GB total (combined boot and data volumes).
• Object Storage: 10 GB Standard, 10 GB Infrequent Access, and 10 GB Archive storage.

Database:

• 2 Autonomous Databases (e.g., Transaction Processing or Data Warehouse), each with 20 GB of storage.

Networking:

• 10 TB of outbound data transfer per month.

$300 Free Trial (Promotional)

The trial credit allows you to "test drive" high-end OCI features that are not part of the Always Free tier.

• Full Catalog Access: Use the $300 for Bare Metal instances, GPU shapes, Load Balancers with higher bandwidth, or advanced Security services.
• Credit Consumption: Credits are deducted based on the standard OCI price list. If you exceed $300 or reach 30 days, the trial ends.
• Transition: Once the trial expires, any non-Always Free resource you created (like a high-performance database or a 100 GB RAM instance) will be stopped and eventually deleted unless you upgrade to a Pay As You Go account.

Important Note on Account Status

• If you upgrade to Pay As You Go, you keep your Always Free resources forever and only pay if you exceed those specific free limits.
• Many users choose to upgrade immediately because "Paid" accounts often have higher priority for resource availability in high-demand regions compared to "Trial" accounts.

Oracle Cloud Advisor is a built-in, free OCI service that continuously scans your tenancy to provide actionable guidance for optimizing your environment. It aggregates insights from various OCI services to help you balance performance, cost, and security.

How It Works

• Automated Scanning: It scans your entire tenancy once every 24 hours.
• Data Collection: For performance-based advice (like rightsizing), it typically requires seven days of utilization data to ensure recommendations are accurate and not based on temporary spikes.
• Centralized Dashboard: Findings are presented in a unified console where you can implement, postpone, or dismiss suggestions.

Cost and Security Recommendations

Additional Optimization Categories

Cloud Advisor also provides insights beyond just cost and security:

• Performance: Identifies overutilized resources (e.g., a Compute instance hitting 100% CPU) and suggests upgrading the "shape" to prevent application bottlenecks.
• High Availability: Provides best practices for resilience, such as suggesting you distribute Compute instances across different Fault Domains or Availability Domains to avoid single points of failure.

Implementation Features

• Estimated Savings: For cost recommendations, it provides a specific dollar amount estimate of how much you will save per month if the change is implemented.
• "Fix-it" Workflows: Many recommendations include an "Implement" button that automatically triggers the necessary changes (e.g., resizing a VM) directly from the Advisor interface.
• Customization: You can tune the logic (e.g., setting the threshold for what counts as "underutilized") to match your organization’s specific risk tolerance.

OCI Bare Metal vs. Virtual Machine Instances

In Oracle Cloud Infrastructure (OCI), Compute services are offered primarily in two forms: Bare Metal (BM) and Virtual Machines (VM). The choice between them comes down to the level of control, isolation, and performance your workload requires.

Core Definitions

• Bare Metal: A physical server dedicated entirely to a single customer. Oracle provides the hardware, network, and power, but there is no Oracle-installed hypervisor. You have complete root access to the physical machine.
• Virtual Machine: An independent computing environment that runs on top of a physical bare metal server using a hypervisor. The underlying physical hardware is usually shared among multiple VMs (unless using dedicated virtual machine hosts).

Key Differences Comparison

When to Choose Bare Metal

• Extreme Performance: Ideal for High-Performance Computing (HPC), big data platforms, and massive database workloads where every ounce of CPU and memory matters.
• Custom Virtualization: If you want to run your own hypervisor (like VMware ESXi or KVM) to manage your own cluster of VMs.
• Strict Compliance: Workloads that require absolute physical isolation for security, regulatory, or licensing reasons (so-called "bring your own license" or BYOL scenarios that are tied to physical sockets).
• Direct Hardware Access: Necessary for applications that require direct access to physical components like NVMe drives or specific GPU architectures without virtualization layers.

When to Choose Virtual Machines

• General Workloads: Perfect for web servers, application servers, microservices, and standard enterprise applications.
• Cost Efficiency: Since you can provision smaller, right-sized shapes (like Flexible shapes where you pick the exact number of OCPUs and RAM), VMs are significantly more cost-effective for everyday workloads.
• Rapid Elasticity: VMs can be spun up, scaled out, or terminated much faster than physical hardware, making them ideal for auto-scaling environments.

OCI E5 Flexible Shapes

In Oracle Cloud Infrastructure (OCI), Flexible Shapes (like the AMD EPYC-based E5 series) revolutionize instance provisioning by decoupling compute power from memory. Instead of forcing you into pre-defined, fixed configurations, they allow you to build a Virtual Machine tailored exactly to your workload's requirements.

How the Customization Works

• Independent Selection: During instance creation, you use sliders or direct input fields to pick the exact number of OCPUs and the precise amount of memory (in GB) you need.
• Defined Ratios: While flexible, there are architectural guardrails. The amount of memory you can select is tied to an allowed ratio based on the OCPUs chosen (for E5, this is typically between 1 GB and 64 GB of memory per individual OCPU).
• Network Bandwidth Scaling: As you increase the number of OCPUs, the network bandwidth allocated to the instance scales proportionately, ensuring your networking capabilities match your compute power.
• Dynamic Resizing: You can modify these allocations after creation. If an application suddenly needs more RAM but the same CPU power, you can scale the memory up independently without over-provisioning (and paying for) unnecessary OCPUs.

Rigid vs. Flexible Shapes

Primary Benefits

• Cost Optimization: By eliminating the need to round up to the next available fixed shape, you stop paying for idle CPU cores or unused gigabytes of RAM.
• Right-Sizing Workloads: It allows for highly specialized deployments. For example, you can build a memory-intensive instance for an in-memory database cache (low CPU, high RAM) or a compute-heavy instance for batch processing (high CPU, low RAM).

OCI Burstable Instances

OCI Burstable Instances are a specialized type of Virtual Machine designed for workloads that do not require continuous, sustained CPU performance. They provide a guaranteed baseline of CPU power while allowing the instance to "burst" to full CPU capacity for short periods when demand spikes.

How Burstable Instances Work

• Baseline Utilization: When you provision a burstable instance, you select a baseline fraction of the total OCPU (typically 12.5% or 50%). This is the guaranteed minimum processing power always available to you.
• CPU Credits: The instance continuously earns and accumulates "CPU credits" when its workload operates below the selected baseline.
• Bursting: When a sudden spike in traffic or processing occurs, the instance automatically consumes its accumulated credits to burst above the baseline—up to 100% of the provisioned OCPUs.
• Cost Efficiency: You are billed at a significantly lower rate because you only pay for the baseline OCPU fraction you selected (along with the standard cost for the memory provisioned).

Standard vs. Burstable Instances

When to Use Burstable Instances

Burstable instances are ideal for applications that sit idle for long periods but need quick bursts of power:

• Development and Testing: Environments that are mostly inactive but require brief, intense processing when developers compile code or run automated testing scripts.
• Web Servers with Spiky Traffic: Blogs, internal admin portals, or informational sites that receive intermittent, unpredictable bursts of user requests.
• Bastion Hosts / Jump Boxes: Security gateways that administrators only log into occasionally to manage internal network resources.
• Lightweight Microservices: Background services, monitoring agents, or cron jobs that wake up, perform a quick task, and go back to sleep.

OCI Ampere A1 Compute (ARM-based) Workloads

The OCI Ampere A1 Compute instances utilize ARM-based architecture (specifically Ampere Altra processors) and play a critical role in modern, cost-optimized cloud workloads. Unlike traditional processors, ARM chips use a Reduced Instruction Set Computer (RISC) architecture, making them highly efficient for specific types of scalable applications.

Core Roles in Modern Workloads

Because ARM processors excel at handling many smaller, independent tasks efficiently, A1 instances are primarily deployed for:

• Cloud-Native Applications: Ideal for containerized microservices managed by Kubernetes (OKE), as these architectures benefit from lightweight, highly scalable compute resources.
• Web and Application Servers: Excellent for running standard web servers (like NGINX or Apache) and application frameworks (like Node.js or Spring Boot) that serve high volumes of concurrent requests.
• CI/CD Pipelines: Frequently used as build agents in Jenkins, GitLab, or GitHub Actions. The predictable performance accelerates software compilation and testing.
• In-Memory Databases and Caching: Applications like Redis or Memcached perform exceptionally well because A1 instances can be provisioned with large amounts of memory at a very low cost.
• Media Encoding: The architecture efficiently handles video streaming and media transcoding tasks.

x86 vs. ARM (Ampere A1) Comparison

Key Advantages

• Predictable Performance: Ampere A1 processors do not use Simultaneous Multithreading (SMT). Every OCPU you provision maps directly to a physical, dedicated core. This eliminates the "noisy neighbor" effect between threads on the same core, guaranteeing consistent performance.
• Cost Savings: A1 instances provide one of the best price-to-performance ratios in the cloud, often costing significantly less per core and per gigabyte of RAM compared to standard x86 instances.
• Ecosystem Maturity: The software ecosystem has heavily adopted ARM. Most popular Linux distributions, container registries (like Docker Hub), and programming languages (Python, Java, Go) now offer native ARM support, making migration seamless.

OCI Container Instances vs. Oracle Kubernetes Engine (OKE)

In Oracle Cloud Infrastructure (OCI), both Container Instances and Oracle Kubernetes Engine (OKE) allow you to run containerized applications, but they serve entirely different levels of architectural complexity and management overhead.

Core Definitions

• OCI Container Instances: A serverless compute service that lets you instantly run containers without provisioning or managing any underlying infrastructure (like Virtual Machines). You simply provide your container image, allocate CPU and memory, and the container starts running.
• Oracle Kubernetes Engine (OKE): A fully managed, enterprise-grade Kubernetes orchestration service. It is designed to automate the deployment, scaling, and management of complex, multi-container applications across clusters of compute nodes.

Key Differences Comparison

When to Choose Container Instances

• Simplicity: When you have a single container (or a small group of tightly coupled containers) and do not want to learn or manage Kubernetes.
• Event-Driven Tasks: Perfect for batch processing, data transformation scripts, or automated tests that spin up, complete their job, and shut down automatically.
• Rapid Deployment: When you need an API endpoint or lightweight web server online immediately without configuring a cluster first.

When to Choose OKE

• Microservices Architectures: When your application consists of dozens or hundreds of interdependent services that need service discovery and internal communication.
• High Availability & Scaling: When you require advanced load balancing, automated horizontal pod auto-scaling based on traffic, and multi-domain redundancy.
• Ecosystem Integration: When you need standard Kubernetes tools like Helm charts, Prometheus monitoring, or Istio service meshes.

OKE Virtual Nodes (The "Autopilot" Experience)

While "Autopilot" is a term used by Google Kubernetes Engine, the equivalent serverless Kubernetes operation mode in Oracle Cloud Infrastructure is officially called OKE Virtual Nodes.

Virtual Nodes provide a fully managed, serverless Kubernetes experience where the operational overhead of provisioning, managing, and upgrading worker nodes is completely abstracted away.

How Worker Node Provisioning is Managed

With traditional managed nodes, you are responsible for defining the underlying compute instances, patching their operating systems, and configuring the Kubernetes Cluster Autoscaler to add or remove instances. With Virtual Nodes, OCI handles all of this invisibly.

• Serverless Abstraction: You do not provision, see, or manage the underlying compute instances (VMs) in your tenancy. OCI automatically provides the necessary logical compute capacity in the background to run your pods.
• Pod-Level Resource Allocation: Instead of sizing a worker node and fitting pods into it, you define the required CPU and memory (requests and limits) directly in your Pod specification. OCI provisions the exact required compute for that specific Pod.
• Hypervisor-Level Isolation: Every Pod launched on a Virtual Node runs within its own secure, hypervisor-isolated environment. This ensures that workloads remain secure and isolated even without traditional VM boundaries.
• Simplified Scaling: Because there is no underlying node pool capacity to manage, you only need to use the Kubernetes Horizontal Pod Autoscaler (HPA). When the HPA requests a new Pod, OCI instantly provides the compute without waiting for a new virtual machine to boot.

Provisioning Comparison: Virtual vs. Managed Nodes

When to Use Virtual Nodes

Virtual Nodes are ideal when your primary goal is to deploy containerized applications without worrying about infrastructure management, node scaling, or OS maintenance. It shifts the operational burden entirely to Oracle, allowing your development teams to focus purely on application logic and Kubernetes manifests.

OCI Functions and Oracle Events Integration

In Oracle Cloud Infrastructure (OCI), the integration between the Events Service and OCI Functions enables a powerful event-driven, serverless architecture. This allows you to automatically execute custom code in response to state changes across your cloud environment without provisioning or managing any underlying servers.

How the Integration Works

The integration follows a seamless pipeline where infrastructure changes act as triggers for custom serverless logic:

• Event Emission: OCI resources automatically generate events when their state changes. For example, uploading a file to Object Storage, modifying a networking route, or completing a database backup all emit events.
• Event Rules: Within the Events Service, you define specific rules that listen for these emitted events. You can filter these rules by resource type, compartment, or specific event states.
• Action Trigger: When an emitted event matches your defined rule, the Events Service captures the event details in a JSON payload and forwards it to a designated destination.
• Function Execution: If an OCI Function is configured as the destination action, the function automatically wakes up, ingests the JSON payload, executes your custom code based on that data, and scales back down to zero once the task is complete.

Common Event-to-Function Scenarios

Key Benefits of this Architecture

• Real-Time Automation: Eliminates the need for constant polling or manual intervention. Your infrastructure reacts to changes immediately as events occur.
• Cost Efficiency: Because OCI Functions is serverless, you only pay for the exact compute time consumed while the function runs. There are no idle servers waiting for events.
• Decoupled Architecture: The resource generating the event does not need to know anything about the function executing the logic. This makes your cloud environment highly modular, scalable, and easier to maintain.

OCI Preemptible Compute

In Oracle Cloud Infrastructure (OCI), Preemptible Compute allows you to provision Virtual Machines using spare, unused physical capacity in an Availability Domain at a massive discount compared to standard on-demand pricing.

The primary trade-off for this deep discount is that OCI can reclaim (preempt) the instance at any time if that capacity is needed elsewhere. When reclaimed, the instance is immediately terminated, and its local storage is permanently deleted.

How It Reduces Costs for Fault-Tolerant Apps

Fault-tolerant applications are designed to expect and handle sudden node failures without experiencing system-wide downtime. By routing these specific workloads to preemptible instances, you can slash your compute bill (often by 50% or more) while relying on your application's architecture to handle the interruptions gracefully.

If a node drops, the application's orchestrator simply reschedules the task on another available node.

Preemptible vs. Standard Compute

Ideal Workloads for Preemptible Compute

Because these instances can vanish instantly, they should never be used for primary databases or legacy, stateful applications. They shine in the following scenarios:

• Batch Processing: Jobs that process chunks of data and save progress externally. If an instance dies, another can pick up the chunk where the last one left off (e.g., financial modeling, image rendering).
• CI/CD Pipelines: Automated testing and build environments. If a test runner gets preempted, the CI/CD system simply re-queues the test.
• Big Data & Analytics: Worker nodes in distributed frameworks like Apache Hadoop or Spark, which are inherently built to survive the loss of individual worker nodes.
• Stateless Web Tiers: Auto-scaling groups of web servers sitting behind a load balancer, as long as session state is stored externally (like in a database or Redis cache).

OCI GPU Shapes for Generative AI Training

Oracle Cloud Infrastructure (OCI) utilizes state-of-the-art GPU shapes, such as those powered by NVIDIA H100 Tensor Core GPUs, to handle the massive computational demands of training modern generative AI models, including Large Language Models (LLMs) and complex multi-modal systems.

How H100 GPUs Power AI Training

• Transformer Engine: The H100 architecture features a dedicated Transformer Engine that dynamically adjusts mathematical precision (utilizing FP8 precision) to dramatically accelerate training times for transformer-based models without sacrificing accuracy.
• Intra-Node Communication: Within a single Bare Metal instance (such as the 8-GPU shape), NVIDIA NVLink and NVSwitch provide ultra-high-bandwidth, low-latency communication between the GPUs. This allows all GPUs on the server to act as a single, massive accelerator.
• Cluster Networking: For large-scale generative AI, OCI connects tens of thousands of GPUs using non-blocking RDMA over Converged Ethernet (RoCEv2). This provides massive inter-node bandwidth, which is essential for distributed training across an OCI Supercluster.
• Local Storage: These compute shapes include substantial amounts of high-performance local NVMe storage to feed massive datasets directly into the GPUs, preventing data-loading bottlenecks.

Architectural Impact on Generative AI

Ideal Workloads

• Foundational LLMs: Training new large language models from scratch or fine-tuning massive existing open-source models.
• Complex Diffusion Models: Training high-resolution image and video generation architectures.
• Scientific AI: Accelerating generative models used for drug discovery, protein folding, and complex physical simulations.

OCI OS Management Service (OSMS) & OS Management Hub

At its core, OS Management is a centralized service designed to simplify, automate, and monitor routine operating system administration tasks—specifically patch and package management—for Oracle Linux and Microsoft Windows Server instances.

How It Handles Automated Patching

Instead of logging into individual servers via SSH or RDP to run local update commands, OS Management centralizes the process through a lightweight agent installed on each compute instance.

Here is how the automation works:

• Scheduled Update Jobs: Administrators can create automated, recurring jobs to apply patches during specific maintenance windows. You can configure jobs to install all available updates, only security updates, or specific bug fixes.
• Zero-Downtime Patching (Ksplice): For Oracle Linux instances, the service natively integrates with Oracle Ksplice. This technology applies critical kernel and user-space security patches in memory, taking effect immediately without requiring a system reboot.
• Lifecycle Environments: You can define strict update policies and push patches through a staged deployment cycle. For example, patches can be automatically applied to a "Development" group, verified, and then promoted to "Testing" and "Production" groups on a set schedule.
• Autonomous Linux Integration: When used with Oracle Autonomous Linux, OS Management provides a completely hands-off experience. The system automatically detects, downloads, and applies zero-downtime security updates without any human intervention or scheduled downtime.

Patching Strategies Comparison

Key Benefits of OS Management Automation

• Fleet Control: You manage thousands of instances from a single pane of glass, eliminating configuration drift across your environment.
• Security Posture: Automated vulnerability scanning and reporting ensure your instances are compliant with the latest security standards.
• Cost Efficiency: The service is included at no additional cost with OCI Compute subscriptions and Oracle Linux Premier Support, drastically reducing operational overhead.

Oracle Autonomous Database (ADB)

Oracle Autonomous Database (ADB) is the world’s first "self-driving" database. It is a cloud-native service that uses machine learning to automate database provisioning, tuning, security, and backups. By running on optimized Exadata infrastructure, it eliminates the manual labor typically required from Database Administrators (DBAs).

How It "Self-Repairs"

The "self-repairing" capability is designed to maximize uptime and protect data without human intervention. It focuses on predicting, detecting, and resolving issues before they cause an outage.

• Automated Fault Detection: The system uses AI to monitor hardware and software telemetry. If it detects a failing disk or a memory leak, it preemptively moves the workload to a healthy node or component.
• Autonomous Data Guard: It automatically creates and manages a standby database. If the primary instance fails due to a site-level disaster or hardware crash, ADB triggers an automatic failover with zero data loss (Zero RPO).
• Self-Healing Storage: Leveraging Exadata’s "Smart Scan" and redundancy, if a block of data becomes corrupted, the system automatically repairs it using a mirrored copy from another storage server in the background.
• Zero-Downtime Patching: All security updates, OS patches, and database bug fixes are applied in a rolling fashion across the nodes of a cluster. This ensures the database remains online and accessible even while the underlying software is being updated.

The Three Pillars of Autonomy

Key Benefits for Enterprise Workloads

• 99.995% Availability: Includes all planned maintenance windows, which is significantly higher than traditional manually managed databases.
• Minimized Human Error: Most database outages are caused by manual configuration mistakes; ADB removes the "human in the loop" for routine maintenance.
• Lower Operational Costs: By automating the "mundane" tasks of patching and repair, organizations can redirect their DBA talent toward high-value data modeling and architecture.

ADW vs. ATP: Key differences

While both Autonomous Data Warehouse (ADW) and Autonomous Transaction Processing (ATP) share the same underlying "self-driving" architecture and run on high-performance Exadata infrastructure, they are internally tuned for opposite workload profiles.

Core Optimization Comparison

When to Choose ADW

ADW is designed for "reading" and "analyzing" data. It is the best choice for:

• Business Intelligence (BI): Powering dashboards in tools like Oracle Analytics Cloud, Tableau, or Power BI.
• Data Science: Running in-database machine learning models on vast historical datasets.
• Data Lakes/Marts: Aggregating data from multiple sources for executive reporting and trend analysis.
• Complex Batch Processing: Tasks that require scanning millions of rows to calculate summaries.

When to Choose ATP

ATP is designed for "writing" and "interacting" with data. It is the best choice for:

• Operational Applications: Customer-facing web stores, banking systems, and mobile app backends.
• Mixed Workloads: Applications that need to handle real-time transactions while also running some light operational reporting.
• ERP/CRM Systems: Managing real-time business logic where data integrity and sub-second response times are critical.
• APEX Development: Building low-code applications that require high concurrency and rapid data entry.

Important Note

Because the internal storage formats (Columnar vs. Row) and memory structures are fundamentally different, you cannot "toggle" an instance between ADW and ATP. You must choose the optimization at the time of provisioning based on the primary nature of your application.

Autonomous JSON Database (AJD)

The Autonomous JSON Database (AJD) is a specialized, low-cost version of the Oracle Autonomous Database designed specifically for developers who prefer a document-store model (like MongoDB) over a traditional relational model. It allows for the storage, indexing, and querying of JSON documents using simple APIs without requiring SQL knowledge.

Catering to Document-Store Requirements

AJD bridges the gap between the flexibility of NoSQL and the reliability of enterprise-grade relational databases through several key features:

• Schemaless Development: Developers can store JSON data in "collections" without defining a fixed schema upfront. This allows for rapid iteration, as the data structure can evolve as the application grows.
• Simple Oracle Document Access (SODA): AJD provides a set of NoSQL-style APIs (SODA) for popular languages like Java, Node.js, Python, and C. This allows developers to perform CRUD operations (Create, Read, Update, Delete) using simple method calls rather than writing SQL.
• Mongo-Compatible API: AJD supports the Oracle Database API for MongoDB, allowing developers to use existing MongoDB drivers, tools, and frameworks to connect to an AJD instance.
• ACID Compliance: Unlike many traditional NoSQL document stores, AJD provides full ACID (Atomicity, Consistency, Isolation, Durability) compliance. You get the flexibility of JSON with the data integrity of a high-end relational engine.
• Native JSON Support: JSON is not stored as a simple "blob" of text. It is stored in a highly optimized binary format (OSON) that allows for lightning-fast partial updates and efficient indexing of specific fields within the document.

AJD vs. Standard NoSQL Document Stores

Cost-Effective Entry Point

AJD is positioned as a "JSON-centric" entry point. It is significantly cheaper than a full Autonomous Transaction Processing (ATP) instance.

• Promotion Path: If your application requirements change and you need to store more than 20 GB of non-JSON data or require advanced relational features, you can upgrade an AJD instance to a full ATP instance with a single click and no downtime.
• Integrated Tools: It includes Oracle APEX for low-code development and Database Actions for a web-based interface to manage your collections and run queries.

Ideal Use Cases

• Mobile App Backends: Storing user profiles, preferences, and activity logs.
• Content Management: Managing catalogs, product descriptions, and metadata.
• IoT Data: Ingesting and storing sensor data that may have varying attributes.

Exadata Cloud Service (ExaDB-D)

Exadata Cloud Service (officially Exadata Database Service on Dedicated Infrastructure) is Oracle’s most powerful database offering. It provides the full power of the Exadata hardware platform—including specialized compute servers, high-speed InfiniBand/RoCE networking, and intelligent storage servers—delivered as a managed cloud service.

Unlike standard RDS-style databases (which run on general-purpose virtualized hardware), Exadata is a purpose-built "database machine" engineered specifically to run Oracle Database at extreme scales.

Exadata vs. Standard RDS-Style Databases

When is Exadata Preferred?

Exadata is the preferred choice when a standard managed database hits its performance or architectural limits.

• Extreme Performance Requirements: When your workload requires millions of IOPS or sub-millisecond latency that general-purpose block storage cannot provide.
• Massive Data Consolidation: If you are migrating hundreds of on-premises databases into the cloud, Exadata allows you to "bin-pack" them into a single high-performance cluster while maintaining isolation.
• Critical "Zero Downtime" Apps: For mission-critical systems where even a 30-second failover is unacceptable. Exadata uses Oracle Real Application Clusters (RAC) to keep the database alive even if a server node fails.
• Large-Scale Data Warehousing: For queries scanning terabytes or petabytes of data. Exadata’s Hybrid Columnar Compression (HCC) reduces storage footprints by 10x–50x while speeding up scans.
• Complex SQL Workloads: If your application uses complex joins and analytics that cause "bottlenecks" on standard cloud hardware, Exadata’s Smart Scan offloads that processing to the storage layer.

Core Components

• Database Servers: High-core count Intel servers dedicated to your tenancy.
• Storage Servers: Intelligent servers that handle data filtering and decompression.
• Internal Fabric: 100 Gbps RoCE (RDMA over Converged Ethernet) connecting all components for near-zero latency.

Exadata Cloud@Customer (ExaCC)

Exadata Cloud@Customer (ExaCC) is a hybrid cloud offering that delivers the full power of Oracle Exadata Database Service and Autonomous Database directly within your own data center. While Oracle owns and remotely manages the hardware, the physical equipment sits behind your corporate firewall.

How it Satisfies Data Residency Laws

Data residency and sovereignty laws (such as GDPR in Europe, CCPA in California, or specific national banking regulations) often mandate that sensitive data must remain within a specific geographic border or physical facility.

ExaCC satisfies these requirements through several key architectural controls:

• Physical Locality: The data never leaves your data center. Unlike public cloud services where data resides in an Oracle-owned region, your database files, redo logs, and backups are stored on the physical Exadata racks located on your premises.
• Sovereignty Compliance: Because the infrastructure is physically located in your chosen jurisdiction, you meet legal requirements for data "at rest" staying within national or regional borders.
• Firewall Isolation: The system operates behind your existing security infrastructure. You control all inbound and outbound network traffic, ensuring that no unauthorized data reaches the public internet.
• Separation of Duties: While Oracle manages the infrastructure (patching hypervisors, firmware, and hardware), Oracle Cloud Operations has no access to your actual database content. You maintain the "root" credentials for the virtual machines and databases.
• Local Management of Encryption: You can integrate with on-premises key management systems (like Oracle Key Vault) to ensure that the encryption keys required to unlock the data are also kept locally under your control.

Exadata Cloud Service vs. Exadata Cloud@Customer

Common Use Cases

• Highly Regulated Industries: Banks, healthcare providers, and government agencies that are legally barred from moving data to a public cloud.
• Latency-Sensitive Apps: On-premises applications that require microsecond response times from the database (e.g., high-frequency trading or factory floor systems).
• Massive Data Volume: Situations where moving petabytes of data to the public cloud is physically or financially impractical due to "data gravity."

Select AI in Autonomous Database 26ai

Select AI is a breakthrough feature in Oracle Autonomous Database 26ai that allows users to query their data using plain English (or other natural languages). It acts as a bridge between the user’s intent and the complex SQL required to retrieve data, effectively making every user a "SQL expert."

How Natural Language Querying Works

Select AI does not just "guess" what you want; it follows a sophisticated multi-step process to ensure accuracy and security:

• Prompt Augmentation: When you submit a natural language question, the database retrieves relevant metadata (table names, column names, data types, and comments) from your schema. It then combines your question with this metadata to create an "augmented prompt."
• LLM Integration: This augmented prompt is sent to a Large Language Model (LLM)—such as OCI Generative AI, OpenAI, or Google Gemini—via an encrypted API call.
• SQL Generation: The LLM uses its understanding of language and code to translate the prompt into a precise Oracle SQL statement tailored specifically to your schema.
• Execution & Verification: The generated SQL is sent back to the Autonomous Database, where it is executed. The database then returns the actual data results to the user.
• Conversation Context: Select AI "remembers" previous questions in the session, allowing for follow-up questions like "Now show me only the ones from London" without needing to repeat the initial context.

Select AI Actions

Key Technical Advantages

• Metadata-Driven: It uses your existing database comments and table structures to "teach" the LLM about your business domain.
• Security & Privacy: Your actual data is never sent to the LLM provider; only the question and the metadata (structure) are shared.
• Reduced Hallucinations: By grounding the LLM in your specific schema metadata, the risk of the AI making up non-existent tables or columns is significantly reduced.
• Retrieval-Augmented Generation (RAG): It integrates with AI Vector Search to find relevant information from unstructured documents (like PDFs or manuals) stored in the database to answer broader business questions.

Getting Started

To use this, an administrator simply creates an AI Profile using the DBMS_CLOUD_AI package, which defines the LLM provider and the list of database objects the AI is allowed to "see."

In Oracle Cloud Infrastructure (OCI), storage is categorized based on how data is accessed, its performance characteristics, and the underlying structure of the data itself.

Core Definitions

• Block Volume: Provides high-performance, low-latency storage that acts like a physical hard drive (SAN) attached to a Compute instance.
• Object Storage: A massively scalable, flat storage architecture (Data Lake) where data is stored as "objects" (files + metadata) in buckets, accessed via APIs/HTTP.
• File Storage (FDS): A managed network file system (NAS) that supports the NFS v3 protocol, allowing multiple instances to read and write to the same data simultaneously.

Storage Comparison Table

When to Use Each Service

Block Volume

• Databases: Ideal for Oracle, MySQL, or SQL Server where high IOPS and low latency are critical.
• Boot Volumes: Every OCI instance uses a Block Volume as its OS boot disk.
• VMware Workloads: Storing virtual machine disk files (VMDKs).

Object Storage

• Backups & Archives: Storing database backups, logs, and long-term compliance data (using the Archive tier).
• Big Data/Data Lakes: Storing massive datasets for analysis by Hadoop or Spark.
• Content Delivery: Hosting static website assets like images, videos, and PDFs.

File Storage

• Shared Content: Applications that require a shared "home" directory or a shared configuration folder across multiple web servers.
• Lift and Shift: Moving on-premises legacy applications that rely on local file system structures and NFS mounts.
• Big Data Tools: Providing a shared scratch space for complex data processing jobs.

Key Performance Tip

Block Volume allows you to dynamically change Elastic Performance levels (Lower Cost, Balanced, Higher Performance, Ultra High Performance) without any downtime, allowing you to pay for high speed only when you need it.

Object Storage Cross-Region Replication

Object Storage Replication is a powerful feature that automatically and asynchronously copies data from a source bucket in one OCI region to a destination bucket in another. This is primarily used for Disaster Recovery (DR), meeting data redundancy compliance, and reducing latency for global users.

How the Replication Works

• Asynchronous Nature: Replication is not instantaneous. Once an object is uploaded or updated in the source bucket, OCI asynchronously copies it to the destination. The time taken depends on the object size and available regional bandwidth.
• Policy-Driven: You enable replication by creating a Replication Policy on the source bucket. This policy defines the destination region and the specific destination bucket.
• One-Way Traffic: By default, replication is one-way. The destination bucket becomes Read-Only while the policy is active. You cannot upload, delete, or rename objects directly in the destination bucket.
• Object Matching: Replicated objects retain the same name, metadata, ETag, and MD5 values as the source. However, system metadata like "Creation Timestamp" and "Last Modified" will reflect when the object arrived in the destination region.

Replication Characteristics & Constraints

Disaster Recovery Workflow

In the event of a regional outage in your primary (source) region, you can perform a "failover":

• Stop Replication: From the destination bucket, you manually stop the replication policy.
• Conversion: The destination bucket is converted from "Read-Only" to a standard Read-Write bucket.
• App Redirection: Point your applications to the new bucket endpoint in the secondary region to resume operations.

Service Authorizations

To set this up, you must authorize the service with an IAM policy such as:

Allow service objectstorage-us-phoenix-1 to manage object-family in compartment MyCompartment
  

OCI Data Flow and Apache Spark

OCI Data Flow is a fully managed, serverless platform for running Apache Spark applications at scale. In a traditional setup, running Spark requires you to provision, configure, and manage a cluster of servers (nodes). OCI Data Flow removes this complexity entirely, allowing you to focus on your code rather than the infrastructure.

The Relationship with Apache Spark

Apache Spark is the "engine," and OCI Data Flow is the "driverless car" that runs it.

• Native Compatibility: OCI Data Flow is 100% compatible with standard Apache Spark. You can take an existing Spark application (written in Python, Java, or Scala) and run it on OCI Data Flow without making any code changes.
• Managed Runtime: While Apache Spark provides the framework for distributed data processing, OCI Data Flow provides the managed runtime environment. It automatically handles the lifecycle of the Spark driver and executors.

Key Differences: DIY Spark vs. OCI Data Flow

How OCI Data Flow Works

• Develop: Write your Spark script (e.g., process_data.py) on your local machine.
• Upload: Store your script and its dependencies in an OCI Object Storage bucket.
• Create Application: In the OCI Console, create a "Data Flow Application" by pointing to your script and selecting your desired compute "shapes" (CPU/Memory).
• Run: Execute the application. OCI Data Flow spins up a private Spark cluster, executes the job, saves the logs, and then tears the cluster down immediately.

Ideal Use Cases

• Massive ETL: Processing terabytes of logs or CSV files and moving them into Autonomous Data Warehouse (ADW).
• Data Science: Running large-scale feature engineering or machine learning model training using Spark MLlib.
• Log Analysis: Aggregating and querying massive volumes of application logs for security or performance insights.
• Spark Streaming: Performing real-time cloud ETL on continuous data streams (like Kafka or OCI Streaming).

OCI Big Data Service (BDS)

While OCI Data Flow is a serverless Spark service, OCI Big Data Service (BDS) is an automated cluster service. It provides a fully managed environment for deploying and operating the full Hadoop ecosystem, including Apache Spark, Hive, HBase, and Trino.

Think of BDS as "Hadoop-as-a-Service." It automates the complex task of building, configuring, and scaling clusters while giving you the full control of a dedicated environment.

How BDS Manages the Environment

OCI BDS simplifies the management of Big Data through several key automation features:

• Automated Provisioning: Instead of manually installing Linux and configuring Hadoop XML files, you select the components you need (e.g., Spark, Hive, Kafka). OCI automatically builds the cluster, configures the networking, and ensures all services are communicating.
• Auto-Scaling (Vertical and Horizontal): BDS can automatically add or remove worker nodes based on CPU or memory utilization. In 2026, it also supports Vertical Auto-Scaling, which allows you to change the shape (OCPU/RAM) of existing nodes to handle seasonal load increases.
• Cloud SQL Integration: This is a unique BDS feature that allows you to run a single SQL query that joins data sitting in HDFS (Hadoop), Object Storage, and NoSQL databases. It uses the Oracle Database's powerful query engine to "talk" to Hadoop.
• High Availability (HA): BDS automatically configures multi-master setups. If one master node fails, another takes over, ensuring that the cluster remains operational and your jobs continue to run.
• Integration with ODMS: It integrates with Oracle Data Management Suite for data cataloging and governance, ensuring that the petabytes of data you store in your cluster are searchable and secure.

BDS vs. Data Flow: Which should you use?

Why use BDS in 2026?

Even with the rise of serverless technologies, BDS remains critical for organizations that:

1. Migrate Legacy Hadoop: Companies moving from on-premises Cloudera or Hortonworks can lift-and-shift their existing workflows with minimal changes.
2. Require Specialized Tools: If you need specific components like Apache HBase for NoSQL or Apache Ranger for fine-grained security, BDS provides the flexibility to install and manage them.
3. Perform Intensive Local Processing: For workloads that require the extreme throughput of HDFS on local NVMe storage rather than remote Object Storage.

Virtual Cloud Network (VCN)

A Virtual Cloud Network (VCN) is the fundamental building block of your private network in Oracle Cloud Infrastructure (OCI). It is a software-defined version of a traditional physical network, complete with subnets, route tables, and gateways.

While a VCN is conceptually similar to AWS's Virtual Private Cloud (VPC), there are structural differences in how they handle regionality and security.

Core Components of a VCN

• Address Space: You define one or more CIDR blocks (e.g., 10.0.0.0/16) for the network.
• Subnets: Segments of the VCN. In OCI, these are Regional by default, meaning a single subnet spans all Availability Domains in a region for better high availability.
• Gateways:Internet Gateway (IGW): For public internet access.
• Service Gateway (SGW): For private access to OCI services (like Object Storage) without going over the internet.
• Dynamic Routing Gateway (DRG): For connecting to on-premises networks or other VCNs.
• Security Rules: Managed via Security Lists (subnet-level) and Network Security Groups (vNIC-level).

VCN vs. VPC: Key Differences

>Why the "Regional Subnet" matters

In 2026, OCI's push for "Regional Subnets" remains a major differentiator. In a traditional VPC, if you want a high-availability application, you must create a separate subnet for every Availability Zone (e.g., Subnet A in AZ1, Subnet B in AZ2).

In an OCI VCN, you create one Regional Subnet. When you launch instances, you simply distribute them across different Fault Domains or Availability Domains within that same subnet. This greatly simplifies route tables and security management.

Which one should you choose?

If you are coming from an AWS background, think of a VCN as a more "flat" and "global" version of a VPC. It requires fewer manual steps to achieve cross-zone redundancy and provides more predictable performance for heavy database workloads.

In Oracle Cloud Infrastructure (OCI), both Security Lists (SL) and Network Security Groups (NSG) act as virtual firewalls to control traffic at the packet level. However, they differ fundamentally in how they are applied and managed within your Virtual Cloud Network (VCN).

Core Difference: Application Level

• Security Lists: Applied at the Subnet level. Every resource (VNIC) within that subnet is subject to the same set of rules.
• Network Security Groups: Applied at the VNIC level. You choose which specific resources belong to the group, regardless of which subnet they are in.

Comparison Table

Why the Difference Matters

1. Micro-segmentation:
   If you have a "Web Tier" subnet but only want one specific server in that subnet to allow SSH from a certain IP, a Security List would force you to open SSH for the entire subnet. With an NSG, you can apply that rule only to that specific server's VNIC.
2. Decoupling Security from Architecture:
   NSGs allow you to separate your network's physical layout (subnets) from your security requirements. You can have a single subnet containing a web server, an app server, and a database, yet give them entirely different security rules by placing them in three different NSGs.
3. Reference by NSG:
   In an NSG rule, you can specify another NSG as the source or destination. For example: "Allow traffic from NSG-Web-Tier to NSG-DB-Tier." This is much easier to manage than manually updating CIDR blocks every time a subnet changes.

Best Practice: Use Both Together

Oracle generally recommends using NSGs as your primary tool for application security. However, it is common to use:

• Security Lists: for "baseline" security that applies to everyone (e.g., allowing internal VCN traffic).
• NSGs: for granular, application-specific rules (e.g., opening port 80 only for Load Balancers).

OCI FastConnect is a network connectivity alternative to using the public internet. it provides a dedicated, private connection between your on-premises data center and Oracle Cloud Infrastructure. Think of it as a private "express lane" that bypasses the congestion and unpredictability of the open web.

How it Provides Dedicated Connectivity

FastConnect establishes a physical and logical link that is reserved solely for your traffic. It works through three primary components:

1. Physical Connection (Cross-Connect): A physical fiber optic cable is established between your router (or a partner's router) and an Oracle edge device at a designated FastConnect location.
2. Dynamic Routing Gateway (DRG): On the OCI side, the FastConnect circuit terminates at a DRG. This acts as the "virtual router" for your VCN, handling the routing of traffic into your cloud network.
3. Virtual Circuits: Once the physical link is up, you create a "Virtual Circuit." This is the logical path that carries your data. You can choose between:
   • Private Peering: To connect your on-premises network directly to your VCN (using private IP addresses).
   • Public Peering: To access OCI public services (like Object Storage or the OCI Console) without using the internet.

FastConnect Connectivity Models

Why Choose FastConnect over Site-to-Site VPN?

While both provide private connectivity, FastConnect is superior for enterprise-grade requirements:

• Predictable Performance: Because it doesn't use the internet, latency is consistent (no "jitter").
• Massive Bandwidth: Supports port speeds from 1 Gbps to 400 Gbps.
• Cost Efficiency (No Egress Fees): Unlike many other clouds, OCI does not charge for data egress (outbound data transfer) over FastConnect. You only pay a flat hourly fee for the port.
• Security: Traffic is physically isolated from the public internet. For extra protection, in 2026, you can also run Site-to-Site VPN over FastConnect to add an extra layer of IPsec encryption to your dedicated line.

Redundancy Best Practice

For mission-critical workloads, Oracle recommends a "Dual-FastConnect" setup or using a Site-to-Site VPN as a backup path. If the FastConnect link fails, the DRG can automatically reroute traffic over the VPN.

Dynamic Routing Gateway (DRG)

The Dynamic Routing Gateway (DRG) is a virtual edge router that serves as the single point of entry and exit for all private traffic between your Virtual Cloud Network (VCN) and other networks. In OCI, the DRG is the "central hub" that connects your VCN to on-premises data centers, other VCNs, or even other cloud providers.

How the DRG Handles Transit Routing

In older cloud architectures, "transit routing" (passing traffic from one network through another to reach a third) was complex and often required managing multiple "peering" connections. The modern OCI DRG simplifies this by acting as a Transit Hub.

• Hub-and-Spoke Connectivity: You can attach multiple VCNs to a single DRG. If VCN-A and VCN-B are both attached to the same DRG, they can communicate with each other through the DRG without needing a direct "peering" link.
• On-Premises to VCN Transit: A DRG connected to your office via FastConnect or IPSec VPN can route traffic to all VCNs attached to it. Your data center doesn't need a separate connection for every VCN.
• Route Tables and Import/Export Policies: The DRG maintains its own internal route tables. It can automatically "learn" routes from one attachment (like a VPN) and "advertise" them to another (like a VCN). You can create Import and Export Route Distributions to strictly control which networks can see each other.
• Remote VCN Peering: By using a Remote Peering Connection (RPC), a DRG in the Ashburn region can talk to a DRG in the London region, allowing private, encrypted transit across the Oracle backbone.

DRG Attachment Types

Key Advantages of the Modern DRG

• Massive Scalability: A single DRG can support up to over 300 attachments (VCNs, VPNs, etc.), making it easy to build massive enterprise networks.
• Simplified Security: Because all transit traffic flows through the DRG, you can implement centralized security monitoring or route traffic through a Network Virtual Appliance (like a Palo Alto or Fortinet firewall) before it reaches its destination.
• Redundancy: DRGs are highly available by default. If you have two FastConnect circuits connected to one DRG, it can handle sub-second failover between them using BGP (Border Gateway Protocol).

Transit Routing Scenario

Imagine you have an "Inspection VCN" containing a firewall. You can configure your DRG to send all traffic coming from your "On-Premises" connection into the "Inspection VCN" first, then back out to your "Application VCNs." This is a classic "Firewall-on-a-stick" transit pattern.

In 2026, OCI Identity and Access Management (IAM) has fully converged with Identity Domains, creating a unified, cloud-native "Identity-as-a-Service" (IDaaS) platform. This evolution moved OCI away from the older "IDCS" (Identity Cloud Service) integration into a single, cohesive management experience.

What are Identity Domains?

An Identity Domain is a container for users and groups that acts as a boundary for security and administration. Instead of one giant pool of users for your entire company, you can create separate domains for different environments (e.g., a "Development" domain and a "Production" domain).

How Users and Groups are Managed

Key Concepts in 2026 IAM

1. Multi-Factor Authentication (MFA) Integration
   MFA is no longer an "add-on" but is baked directly into the Identity Domain. You can enforce MFA policies based on risk (e.g., "Require MFA if the user is logging in from a new country") or by group membership.
2. Policy Management
   OCI IAM uses a human-readable language to define what a group can do. A typical policy follows this syntax:

   Allow group <Group_Name> to <Verb> <Resource-Type> in compartment <Compartment_Name>
         

3. Identity Federation
   For most enterprises, OCI IAM acts as a "service provider." Users log in with their corporate credentials (like Microsoft Entra ID), and OCI IAM maps those external groups to OCI internal groups to determine their cloud permissions.
4. Self-Service and Lifecycle Management
   Users can manage their own profile, reset passwords, and enroll in MFA through a dedicated Self-Service Console, reducing the burden on IT administrators.

Identity Domain vs. The Old IAM

• The Old Way: You managed users in a separate "IDCS" console and mapped them to OCI IAM via federation.
• The 2026 Way: Everything—users, groups, MFA, and OCI resource policies—is managed in the Identity & Security section of the OCI Console under a single domain.

The "Root" Compartment and Default Domain

Every tenancy comes with a Default Domain in the Root Compartment. Most small-to-medium organizations perform all their management here, while larger enterprises create multiple domains to isolate different business units.

An OCI IAM Policy is a human-readable document that specifies who can access which resources and how. In Oracle Cloud, the security model is "deny-by-default", meaning a user has zero permissions until a policy explicitly grants them.

The Core Syntax

Every OCI policy follows a standardized grammar:

Allow group <group_name> to <verb> <resource-type> in <location> where <conditions>

• Group: The collection of users receiving the permission.
• Verb: The level of access (Inspect, Read, Use, or Manage).
• Resource-Type: The specific service (e.g., instances, volumes, database-family).
• Location: The compartment or the entire Tenancy where the resource lives.
• Conditions: Optional filters (e.g., where target.resource.tag.Environment='Production').

"Allow" vs. "Deny" Logic

Unlike some other cloud providers (like AWS), OCI policies are almost exclusively "Allow" statements.

The Hierarchy of Verbs

When writing an "Allow" statement, you choose one of four verbs. Each one includes the permissions of the ones above it:

1. Inspect: Ability to list resources (no metadata or details).
2. Read: Ability to list resources plus view detailed metadata and configurations.
3. Use: Ability to work with existing resources (e.g., start/stop a VM) but usually not create or delete them.
4. Manage: Full administrative rights (Create, Update, Delete, and Move).

Why "Deny" is Rare in OCI

Because OCI starts with a Zero Trust (Deny-All) stance, you don't typically need to write "Deny" rules. If you don't want someone to do something, you simply don't write an "Allow" policy for it.

The only time "Deny" is used is in Security Guardrails (via OCI Organizations) to ensure that even a Compartment Admin cannot perform certain dangerous actions, like disabling encryption or deleting audit logs.

OCI Vault: Key & Secret Management

OCI Vault is a managed security service that provides centralized control over the encryption keys that protect your data and the secrets (credentials) used to access resources. In 2026, it serves as the core "trust anchor" for OCI, integrating hardware-level security with automated lifecycle management.

How it Manages Master Encryption Keys (MEK)

Master Encryption Keys are the "keys to the kingdom." They are used to encrypt the Data Encryption Keys (DEKs) that actually lock and unlock your files and databases (a process known as Envelope Encryption).

• Protection Modes:
  • HSM (Hardware Security Module): Keys are stored on FIPS 140-2 Level 3 certified hardware. These keys cannot be exported; all cryptographic operations happen inside the HSM.
  • Software-Protected: Keys are stored on a server and can be exported for client-side encryption. These are typically used for dev/test environments to save on cost.
• Key Types: Supports symmetric keys (AES) for high-speed data encryption and asymmetric keys (RSA, ECDSA) for digital signatures and secure message exchange.
• Rotation: You can enable Auto-Rotation on a schedule (e.g., every 90 days). OCI creates a new key version and automatically uses it for new encryption tasks while keeping the old versions available for decrypting existing data.
• Bring Your Own Key (BYOK): You can generate your own key material on-premises and securely import it into OCI Vault to maintain control over the key's entropy.

How it Manages Secrets

Secrets are sensitive variables like database passwords, API keys, or SSH private keys. In 2026, secret management has evolved into a highly automated service.

• Encrypted Storage: Secrets are never stored in plain text. They are encrypted using a Master Encryption Key from your Vault before being saved to the OCI metadata store.
• Versioning: Each time you update a password, OCI creates a new Secret Version. Applications can be configured to always pull the "Latest" version or a specific version (e.g., "Current" vs. "Pending").
• Auto-Generation & Rotation: You can define templates to automatically generate complex passwords. For services like OCI Functions, the Vault can trigger a rotation script that updates the password in the database and the Vault simultaneously, ensuring no service interruption.
• Cross-Region Replication: In 2026, secrets can be replicated across up to three OCI regions. This ensures that if your primary region goes down, your secondary DR site still has access to the credentials needed to start up.

Keys vs. Secrets Comparison

Security Tip: Service Authorizations

To use a Vault key with OCI services (like Object Storage), you must write a policy allowing the service itself to use the key:

Allow service objectstorage-us-phoenix-1 to use keys in compartment Security_Comp where target.key.id = '< Key_OCID>'

OCI Bastion

OCI Bastion is a fully managed, serverless security service that provides restricted, time-limited SSH access to resources that do not have public endpoints. It acts as a secure proxy, allowing administrators to connect to private compute instances, databases, and Oracle Kubernetes Engine (OKE) clusters without exposing them to the internet.

How it Eliminates Public-Facing Jump Hosts

Traditionally, to access a private server, you had to maintain a "Jump Host" (or Bastion Host)—a small, hardened VM sitting in a public subnet with a public IP. OCI Bastion removes this necessity by replacing the physical host with a managed service.

• No Public IPs Required: Your target resources (web servers, databases) stay entirely within a private subnet with no public IP. The Bastion service provides the entry point without requiring you to manage a public-facing VM.
• Serverless and Zero Maintenance: Since it is a managed service, you don’t have to patch, update, or monitor a jump host. Oracle handles the underlying infrastructure.
• Identity-Based Access (IAM): Unlike a traditional jump host where anyone with the SSH key might get in, OCI Bastion is integrated with OCI IAM. You must have specific OCI permissions to even request a session.
• Just-in-Time (Ephemeral) Access: Access is not permanent. You create a session that lasts for a maximum of 3 hours. After the Time-to-Live (TTL) expires, the session is automatically deleted and the network path is severed.
• CIDR Allowlisting: You can restrict access so that only specific source IP addresses (like your office or home VPN) can initiate a session through the Bastion.

OCI Bastion Session Types

Traditional Jump Host vs. OCI Bastion

Setup Requirement

To use a Managed SSH Session, you must ensure the Bastion Plugin is enabled in the Oracle Cloud Agent tab of your target compute instance. Additionally, the target’s security list must allow ingress on the appropriate port (e.g., 22 for SSH or 3389 for RDP) from the Bastion’s Private Endpoint IP.

OCI Cloud Guard

OCI Cloud Guard is a free, cloud-native security posture management (CSPM) service that provides a "single pane of glass" view of your security health across your entire OCI tenancy. It continuously monitors your configurations and activities to identify security risks and can automatically remediate them.

How Continuous Monitoring Works

Cloud Guard operates on a simple "Observe, Detect, and Remediate" loop:

• Data Ingestion: It automatically collects data from various sources across all regions in your tenancy, including:
  • Audit Logs: Tracking user and operator activity.
  • Configuration Data: Checking the status of buckets, VCNs, and databases.
  • Vulnerability Scans: Integrating with the OCI Vulnerability Scanning Service.
• Detector Recipes: These are sets of rules that define what a "security problem" looks like. In 2026, Cloud Guard uses specialized recipes:
  • Configuration Detector: Identifies misconfigured resources (e.g., a public Object Storage bucket).
  • Activity Detector: Spots risky user behavior (e.g., an IAM policy change from an unusual IP).
  • Threat Detector: Uses machine learning to identify complex attack patterns based on the MITRE ATT&CK framework.
  • Instance Security: Monitors the inside of your virtual machines for OS-level vulnerabilities and suspicious processes.
• Problem Identification: When a rule is triggered, Cloud Guard creates a Problem. It calculates a Security Score (the health of your configuration) and a Risk Score (the severity of current threats) to help you prioritize what to fix first.

Automated Remediation: Responder Recipes

The "magic" of Cloud Guard lies in its ability to take action without human intervention via Responder Recipes.

Managing Across Tenancies (2026 Evolution)

In 2026, Cloud Guard has moved beyond single-compartment monitoring to provide true Multi-Tenancy and Global Oversight.

• Reporting Region: While monitoring happens in every region, all problems are aggregated into a single Reporting Region. This allows a global CISO to see every security hole in the company from one dashboard.
• Targets: You define a "Target" (usually the Root Compartment) to tell Cloud Guard what to watch. Targets can inherit recipes down through all child compartments, ensuring no "shadow IT" resources are missed.
• Managed Lists: You can create Allowlists of trusted IP addresses or approved OS images. Cloud Guard uses these lists to reduce "false positives," so your team only spends time on real threats.

Key Benefit: "Security by Default"

Cloud Guard is a "set it and forget it" service. By enabling it at the Root Compartment, you ensure that any new resource created by any developer, in any region, is automatically subjected to your company's security guardrails the moment it is provisioned.

Zero Trust Packet Routing (ZPR)

OCI Zero Trust Packet Routing (ZPR) is a groundbreaking security layer that decouples network security from network architecture. While traditional security (Security Lists and NSGs) relies on IP addresses and ports, ZPR uses security attributes (metadata) and natural language policies to govern traffic.

In 2026, ZPR has become the gold standard for "East-West" security (traffic between internal resources), ensuring that even if a network is misconfigured, your data remains protected.

How ZPR Secures VCN Traffic

ZPR works as an additional, "invisible" firewall layer that operates alongside traditional network rules. It follows three main steps:

1. Assign Security Attributes: You label your resources with meaningful tags (e.g., app:finance, database:sensitive). These attributes are tied to the resource itself, not its IP address.
2. Define Intent-Based Policies: You write human-readable policies that describe who should talk to whom.
   Example: allow network-traffic from app:finance to database:sensitive over tcp port 1521
3. Enforce at the Packet Level: As a packet moves through the OCI network fabric, the underlying infrastructure inspects it. If the source and destination do not have an explicit "allow" policy in ZPR, the packet is dropped, even if your Security Lists or NSGs mistakenly allow the traffic.

ZPR vs. Traditional Network Security

Key Benefits in 2026

• Protection Against Misconfiguration: If a junior admin accidentally opens a Security List to 0.0.0.0/0, ZPR acts as a safety net. If there isn’t a ZPR policy matching that traffic, the data still won’t move.
• Simplified Compliance: Auditors no longer need to parse thousands of IP-based firewall rules. They can simply read your ZPR policies to see exactly which applications are permitted to access sensitive databases.
• Security Follows the Workload: If you move a database to a new subnet or change its IP address, you don’t need to rewrite your security rules. Because the security attribute stays with the database, the ZPR policy remains in effect automatically.
• Cross-VCN Support: In 2026, ZPR seamlessly secures traffic across peered VCNs in the same region, allowing you to maintain a consistent security posture across your entire hub-and-spoke network.

Important Implementation Note

ZPR is additive. For a packet to reach its destination, it must pass both the traditional network rules (Security Lists/NSGs) and the ZPR policy. If you add a ZPR attribute to a resource but forget to write a matching policy, all traffic to that resource will be blocked immediately.

Oracle Database@Azure

Oracle Database@Azure is a strategic partnership that brings Oracle Cloud Infrastructure (OCI) services—including Exadata and Autonomous Database— directly into Microsoft Azure data centers.

Instead of connecting two separate clouds over the internet or a long-distance cable, Oracle physically installs its Exadata hardware inside Azure’s facilities. This makes the Oracle Database appear as a native Azure service.

How it Enables Low-Latency Multi-Cloud

The "multi-cloud" challenge has traditionally been network latency (the time it takes for data to travel between an app in Cloud A and a database in Cloud B). Oracle Database@Azure solves this through Physical Co-location:

• Microsecond Latency: Because the OCI hardware is in the same building as the Azure compute servers, the round-trip latency is typically under 2 milliseconds—and in many cases, measured in microseconds. This is equivalent to the latency found within a single data center.
• Direct Azure VNet Integration: The database is injected directly into your Azure Virtual Network (VNet). It uses a private IP address from your Azure subnet, so Azure applications "see" the Oracle database as if it were just another local server.
• Bypassing the Internet: Traffic never leaves the data center’s private network fabric. This eliminates the "jitter" and security risks associated with the public internet.
• Unified Management: You can provision and manage the database through the Azure Portal, use Azure CLI/APIs, and view logs and metrics in Azure Monitor. This "single pane of glass" reduces the operational latency of your IT team.

Key Benefits for Enterprise Workloads

The "Parent/Child" Architecture

In 2026, this is managed via a Parent Site (the OCI control plane in a nearby OCI region) and a Child Site (the actual database hardware inside the Azure AZ). This ensures that while the data stays in Azure, it is still managed by Oracle’s expert OCI operations team.

Oracle Database@AWS

Oracle Database@AWS is the latest evolution in multi-cloud, where Oracle and Amazon have partnered to co-locate OCI’s specialized database hardware—specifically Exadata—directly inside AWS data centers.

For long-time Exadata users, this service is a "game changer" because it removes the binary choice between staying on-premises or switching to a standard RDS database that lacks Exadata's unique performance features.

How it Simplifies Migration for Exadata Users

1. Zero Rearchitecting (Full RAC Support)

   Most mission-critical Exadata workloads rely on Oracle Real Application Clusters (RAC) for high availability. Standard AWS RDS does not support RAC. With Oracle Database@AWS, users can migrate their RAC clusters "as-is" into the AWS environment, maintaining the same clustering logic and failover capabilities they use on-premises.

2. Performance Parity

   Migrating a heavy Exadata workload to a general-purpose cloud VM often results in a "performance cliff." Oracle Database@AWS uses the exact same X11M Exadata hardware found in OCI. This means features like Smart Scan, Storage Indexes, and RDMA are fully available, ensuring that your migration doesn't require a massive "re-tuning" of your SQL queries.

3. Proven Migration Tooling (Zero Downtime Migration)

   Exadata users can use Oracle Zero Downtime Migration (ZDM) to move their databases to AWS. ZDM automates the entire process:

   • It sets up a physical standby database in AWS using Oracle Data Guard.
   • It synchronizes data in real-time.
   • It performs a coordinated "switchover" to the new AWS-based database with near-zero downtime.
4. Low-Latency Connectivity to AWS Apps

   The "proximity problem" is solved. Because the Oracle hardware sits in the same AWS Availability Zone as your Amazon EC2 or Amazon EKS clusters, the network latency is sub-millisecond. This allows "chatty" applications that make thousands of database calls to function just as fast as they did on-premises.

Key Technical & Operational Benefits

"Zero-ETL" Advantage

In 2026, a standout feature is the Zero-ETL integration with Amazon Redshift. Exadata users can now analyze their operational data in Redshift almost instantly, eliminating the need to maintain expensive and fragile data movement scripts between their Oracle and AWS environments.

OCI Dedicated Region

OCI Dedicated Region is a complete, self-contained Oracle Cloud region— including all 150+ OCI services and Oracle Fusion SaaS applications— deployed directly into a customer's own data center. It is managed by Oracle but physically resides on your premises, giving you the full power of a public cloud with the isolation of a private facility.

In 2026, Oracle has introduced the Dedicated Region25 configuration, which significantly lowers the entry barrier, allowing organizations to start with as few as three racks and scale up to hyperscale levels (over 450 racks).

How it Differs from the Public Cloud

While the services, APIs, and pricing are identical, the operational and physical characteristics are fundamentally different.

Key Benefits & Use Cases

• Total Data Sovereignty: For governments, central banks, and highly regulated industries (like defense or healthcare), Dedicated Region ensures that no data, metadata, or logs ever cross a national or physical border.
• Ultra-Low Latency: By placing the entire cloud region next to your legacy mainframes or factory floor systems, you achieve sub-millisecond response times that are impossible with a distant public cloud.
• Sovereign AI: In 2026, many organizations use Dedicated Region to train and run Large Language Models (LLMs) on sensitive internal data, ensuring the AI infrastructure remains under their physical control.
• Cloud Modernization without Migration: Instead of moving your apps to the cloud, you "move the cloud to your apps." This allows you to use modern tools (Kubernetes, Serverless, Autonomous DB) without the risk and cost of a massive data migration.

Management and Billing

Despite being on your site, Oracle handles all the "dirty work":

• Fully Managed: Oracle installs, patches, updates, and monitors the hardware and software 24/7.
• Pay-As-You-Go: You pay the same predictable public cloud prices for the services you consume. In 2026, the lower entry point for Dedicated Region25 makes this viable for mid-sized enterprises, not just global giants.

Oracle Alloy

Oracle Alloy is a complete cloud infrastructure platform that allows partners—such as Managed Service Providers (MSPs), Independent Software Vendors (ISVs), and telecommunications companies—to become their own independent cloud providers.

While OCI Dedicated Region is Oracle-managed and branded, Alloy is a "white-label" version of the same technology. It enables partners to offer 100% of OCI’s services (including Exadata, Autonomous Database, and Generative AI) under their own brand, using their own data centers and operational staff.

How it Allows Partners to Become Cloud Providers

Oracle Alloy provides the technical and commercial "blueprint" to run a hyperscale cloud business without needing to build the software stack from scratch.

1. Independent Operations

Unlike other OCI offerings, Alloy gives the partner full operational control. The partner’s own personnel manage the day-to-day operations, maintenance, and patching of the cloud infrastructure. This is critical for Sovereign Cloud requirements, where the government or a specific national entity must be the only ones with physical and logical access to the hardware.

2. Full Customization & Branding

Partners can completely "skin" the OCI Console with their own logo, colors, and legal terms. They can even customize the Software Development Kits (SDKs) and documentation to create seamless brand experiences for their end customers.

3. Custom Commercial Models

Alloy partners are not bound by OCI's standard public pricing. They can:

• Set their own pricing and discount structures.
• Create unique service bundles (e.g., bundling their own specialized software with OCI compute).
• Manage the entire billing lifecycle (invoicing, payments, and taxes) directly with their customers using integrated tools like Oracle Fusion Cloud ERP.

4. Software & Hardware Extensibility

Partners can build their own native cloud services on top of the Alloy platform using the same developer tools Oracle uses. They can also bring specialized third-party hardware (like specific mainframes or high-performance networking gear) and integrate it into their Alloy environment to offer specialized cloud services.

Alloy vs. Dedicated Region: The "Ownership" Difference

Why use Oracle Alloy in 2026?

As of 2026, Oracle Alloy has become the primary engine for National Sovereignty. For example, partners like SoftBank in Japan and Ooredoo in Qatar use Alloy to provide localized AI and cloud services that comply with strict national data laws, ensuring that data never leaves their borders and the cloud is operated by local citizens.

The OCI Generative AI Service is a fully managed platform that allows enterprises to integrate Large Language Models (LLMs) from partners like Meta (Llama) and Cohere into their applications via a single API.

Access Models and Hosting

OCI provides two primary ways to access these models, balancing cost-efficiency with performance and privacy.

Key Partnerships and Models
• Cohere Models:
• Command R / R+: Optimized for long-context tasks and RAG (Retrieval-Augmented Generation).
• Embed: Multilingual models that convert text into vector embeddings for semantic search.
• Rerank: Specialized models to improve search relevance by re-ordering document results.
• Meta Llama Models:
• Llama 3.1 / 3.3: High-performance open-source models available in various sizes (e.g., 70B and 405B).
• Llama 3.2 Vision: Models capable of processing both text and image inputs.

Advanced Managed Features
• Flexible Fine-Tuning: Users can refine models on proprietary data using efficient techniques like LoRA (for Llama) or T-Few (for Cohere) without needing to manage the underlying GPU clusters.
• OCI Generative AI Agents: A managed RAG (Retrieval-Augmented Generation) service that connects LLMs to your private data sources (like Oracle Database 23ai) to provide grounded, fact-based answers.
• The Playground: A no-code web interface in the OCI Console for testing prompts, adjusting parameters (temperature, top-p), and generating sample code for integration.
• The Playground: no-code web interface in the OCI Console for testing prompts, adjusting parameters (temperature, top-p), and generating sample code for integration.
• Security & Compliance: Full integration with OCI Identity and Access Management (IAM), ensuring that LLM access is governed by the same enterprise policies as other cloud resources.

In the Oracle Fusion Cloud suite, AI Agents are specialized, autonomous assistants embedded directly into business workflows. Unlike standard generative AI that simply drafts text, these agents are designed to execute multi-step tasks, reason through business rules, and interact with unified data across the enterprise.

Core Capabilities of Fusion AI Agents
• Autonomous Execution: They can perform end-to-end transactions, such as ingesting an invoice, matching it to a purchase order, performing fraud checks, and routing it for approval without manual navigation between screens.
• Contextual Reasoning: Built on Large Language Models (LLMs), they understand natural language and can make judgment-based decisions (e.g., identifying a "high-risk" shipment or suggesting a "best-fit" job candidate).
• Native Integration: These agents are "prebuilt" and available at no extra cost, running on OCI (Oracle Cloud Infrastructure) with built-in security and data privacy.
• No-Data-Copy Strategy: They access data directly within the Oracle Database (using technologies like Vector Search in Database 23ai), ensuring information is real-time and secure without needing to move it to a third-party AI platform.

AI Agents by Functional Area

Oracle AI Agent Studio

For organizations with unique needs, Oracle provides the AI Agent Studio. This low-code environment allows business analysts and developers to:

• Modify Prebuilt Agents: Adjust the prompts or data access of existing Fusion agents.
• Build Custom Agents: Create entirely new agents for proprietary business processes.
• Orchestrate "Agent Teams": Set up multiple agents to collaborate on a single complex workflow (e.g., a Sales agent passing data to a Finance agent).

High-Performance Use Case

A prominent example of this technology in action is the AI-Powered Strategy Agent used by Oracle Red Bull Racing. It automates data collection and analyzes thousands of race scenarios in real-time to help engineers make split-second decisions trackside.

OCI Vision: Real-Time Image and Video Analysis

OCI Vision is a cloud-native, AI-powered service designed to perform large-scale image and video analysis. For enterprise applications requiring real-time insights, OCI Vision uses a combination of high-performance GPU infrastructure and pre-trained deep learning models.

Core Capabilities for Real-Time Analysis

OCI Vision addresses real-time requirements through two distinct workflows: Image Analysis (for snapshots) and Streaming Video Analysis (for live feeds).

• Streaming Video Analysis: This is a fully managed, GPU-accelerated service that processes live RTSP (Real-Time Streaming Protocol) or WebRTC feeds. It can detect, track, and label objects (like vehicles or people) and faces across frames with minimal latency.
• Synchronous API Calls: For mobile or web apps, developers can use the analyzeImage REST API to send a single image and receive a JSON response containing labels, bounding boxes, and confidence scores in milliseconds.
• Object Tracking: live streams, the service assigns a unique Tracking ID to detected objects. This allows a system to follow an individual or item even if they temporarily move out of view or across different camera feeds.

Key Features for Enterprise Apps

Operational Architecture
• Serverless Execution: Developers do not need to manage underlying servers or GPUs. The service scales automatically based on the number of images or stream volume.
• Edge Integration: OCI Vision can be integrated with OCI Gateway and Functions to trigger immediate actions—such as sending an alert to a supervisor if a safety violation (like missing protective gear) is detected in a live feed.
• Data Labeling Service: To achieve high accuracy for niche enterprise needs, users can use the integrated OCI Data Labeling tool to quickly tag images for "transfer learning," which refines the model's performance on specialized datasets.

Performance Best Practices

To ensure consistent real-time performance, it is recommended to use cameras with a frame rate of at least 30 FPS and a resolution of 720p or higher. This provides the AI with enough visual data to maintain a high confidence score during rapid movement.

OCI Document Understanding is a fully managed, AI-powered service that allows developers to extract text, tables, and other critical data from business documents. It uses deep learning models to convert unstructured data (like scans and PDFs) into structured, machine-readable formats without requiring data science expertise.

How It Automates Data Extraction

The service automates the "manual entry" phase of business workflows through several specialized AI capabilities:

• Key-Value Extraction: Automatically identifies and extracts specific fields from common documents. For an invoice, it can instantly pull the Vendor Name, Total Amount, Tax, and Due Date.
• Table Extraction: Recognizes tabular structures within a page and extracts data while preserving the row and column relationships. This is essential for processing multi-item purchase orders or bank statements.
• Document Classification: Identifies the type of document being uploaded (e.g., distinguishing a "Resume" from an "Invoice" or a "Passport") to route it to the correct downstream process.
• Optical Character Recognition (OCR): Converts printed or handwritten text into digital characters, supporting a wide range of languages and handling tilted, rotated, or low-quality scans.

Pre-trained vs. Custom Models

OCI Document Understanding offers flexibility depending on the complexity of your business forms:

Enterprise Workflow Integration

The real power of Document Understanding lies in its ability to trigger automated actions across the Oracle ecosystem:

• Oracle Integration Cloud (OIC): You can build a "no-code" workflow where an email attachment is automatically sent to OCI Document Understanding, and the extracted data is used to create a Sales Order in Oracle ERP.
• Oracle APEX: Developers can integrate the service into low-code web apps, allowing users to upload a photo of a receipt and have the expense report fields auto-populated in seconds.
• Search and Retrieval: By digitizing large volumes of historical paper records, organizations can make their entire document archive searchable via keywords or specific metadata.
• Native Security: As with all OCI AI services, your document data is never used to train Oracle’s base models, ensuring strict data privacy and compliance.

OCI Language is a serverless AI service that uses advanced Natural Language Processing (NLP) to understand and extract insights from unstructured text. It eliminates the need for machine learning expertise by providing sophisticated, pre-trained models accessible via REST APIs and SDKs.

Sentiment Analysis

OCI Language evaluates the emotional tone of text, providing a granular look at how users feel about specific subjects.

• Analysis Levels:
• Sentence-Level: Provides an overall sentiment score for each individual sentence.
• Aspect-Based (ABSA): This is the most powerful feature. It identifies specific "aspects" (attributes or features) and assigns a sentiment to each. For example, in the sentence "The phone has a great screen but the battery life is terrible," the service identifies Screen as Positive and Battery as Negative.
• Classification: Expressions are categorized as Positive, Negative, Neutral, or Mixed.
• Confidence Scores: Every prediction includes a score between 0 and 1, allowing developers to set thresholds for automated actions (e.g., only flagging "Negative" reviews for human follow-up if the confidence is above 0.90).

Named Entity Recognition (NER)

Entity recognition identifies and categorizes key elements within a block of text, turning "noise" into structured data.

• Pre-trained Entities: Automatically recognizes over 18 common entity types, including:
• People: Names of individuals.
• Organizations: Businesses, government agencies, and institutions.
• Locations: Cities, countries, and addresses.
• Products: Specific brand names or item categories.
• Quantities: Dates, times, currency, and percentages.
• Custom Entity Extraction: For industry-specific needs, you can train Custom NER models. This is essential for identifying proprietary data like Product Part Codes, Financial Transaction IDs, or specialized Medical Terminology that standard models wouldn't recognize.

Key Comparison and Use Cases

Technical Implementation
1. Multilingual Support: Pre-trained models support over 100 languages for detection and many for advanced analysis (English, Spanish, French, German, etc.).
2. Batch Processing: To optimize performance, the service allows batching up to 100 records (up to 5,000 characters each) in a single API call.
3. Integration: It integrates natively with OCI Data Integration and Oracle Analytics Cloud (OAC), allowing you to run sentiment analysis directly on your data warehouse tables without writing code.

OCI Speech is an AI-native service that utilizes Automatic Speech Recognition (ASR) to convert audio into accurate text. In 2026, its role has expanded significantly from processing static files (batch) to supporting high-stakes, real-time streaming environments.

Key Roles in Real-Time Transcription

In modern enterprise workflows, OCI Speech serves as the "ears" of the cloud, providing instantaneous data for live interactions.

• Sub-Second Latency: Using WebSockets, the service provides a persistent connection that streams audio and returns text results in milliseconds. This is critical for live captioning and "voice-to-voice" AI agents.
• Neural Text-to-Speech (TTS) Integration: OCI Speech now works bi-directionally. It can transcribe a user's voice in real-time and, when paired with OCI's TTS, allow an application to "speak" back using natural, human-like synthetic voices.
• Live Speaker Diarization: The service can distinguish between multiple speakers in a live stream (e.g., distinguishing a doctor from a patient), which is essential for automated medical or legal documentation during live sessions.
• Custom Vocabulary: Organizations can upload specialized dictionaries (medical terms, technical jargon, or internal product names) to the real-time engine to ensure accuracy for niche industries.

Real-Time vs. Batch Transcription

Advanced Real-Time Features
• Profanity Filtering: Automatically masks, removes, or tags offensive language in a live feed before it reaches the end-user or is logged.
• Partial Results & Stability: The service provides "interim" results—showing words as they are spoken—and then "finalizes" the sentence once the speaker pauses, ensuring the user interface remains responsive.
• Punctuation & Normalization: It automatically formats numbers, currencies, and addresses in real-time, making the live text much easier for humans to read than raw phonetic output.
• Multilingual Streaming: real-time transcription for major languages including English, Spanish, Portuguese, German, French, Italian, and Hindi.

Strategic Business Impact

By 2026, OCI Speech is the primary engine behind AI Voice Agents in the Oracle Fusion Cloud. It allows businesses to automate customer service calls completely, as the AI can now "listen" and "understand" at the same speed as a human representative.