If you read our Oracle Database at AWS guide, you already understand the concept: Oracle Exadata hardware physically inside a cloud provider's data center, managed by Oracle, connected to your workloads via a private network link.

Oracle Database at Azure (ODP — Oracle Database Service for Azure) follows the same model. But almost everything underneath is different: the networking uses Azure ExpressRoute instead of a VPC endpoint, identity uses Microsoft Entra ID (formerly Azure AD) instead of AWS IAM, billing integrates into your Azure invoice rather than a separate Oracle invoice, and the latency profile, support boundaries, and deployment regions are all distinct.

This guide walks you through the architecture differences, step-by-step provisioning via both Azure Portal and CLI, networking setup with Azure Virtual Network peering, Entra ID integration, pricing comparison against Azure SQL and the AWS equivalent, and an honest assessment of when Oracle Database@Azure beats Oracle Database@AWS and vice versa.

🎯 Who This Is For

Cloud architects and DBAs evaluating Oracle Database@Azure for workloads already on Microsoft Azure — particularly those running .NET applications, Power BI, Azure Data Factory, or Azure Kubernetes Service that need an Oracle backend.

What Is Oracle Database at Azure (ODP)?

Oracle Database@Azure — formally called Oracle Database Service for Azure or ODP — is a partnership announced in September 2023 and reaching GA in early 2024. Oracle Exadata X9M hardware racks are physically co-located inside Microsoft Azure data centers, connected to your Azure Virtual Network through Azure ExpressRoute at sub-2ms latency.

The key architectural difference from Oracle Database at AWS: on AWS, you connect via a VPC endpoint (a software-defined construct). On Azure, the connection is a dedicated ExpressRoute circuit — a physical-layer private connection provisioned by Microsoft between the Oracle Exadata infrastructure and your Azure VNet. This gives slightly more predictable latency but requires ExpressRoute to be provisioned in your Azure subscription.

Available Services

Oracle Database at Azure vs Oracle Database at AWS — Key Differences

💡 MACC Is a Big Deal

If your organization has a Microsoft Azure Consumption Commitment (MACC), Oracle Database@Azure spend counts toward it. This means you can use existing Azure budget for Oracle — a significant procurement advantage that Oracle DB@AWS cannot offer.

Network Architecture: ExpressRoute Deep Dive

The network topology for Oracle Database at Azure is more complex than the AWS equivalent because it uses ExpressRoute rather than a VPC endpoint. Understanding this is essential before provisioning.

Layer 1 — Physical co-location: Oracle Exadata X9M racks sit inside Azure data centers on dedicated floor space leased by Oracle. Microsoft provides power, cooling, and physical security. Oracle operates the hardware.

Layer 2 — ExpressRoute circuit: An Azure ExpressRoute circuit is provisioned between the Oracle Exadata infrastructure and Microsoft's network edge. This is a dedicated private circuit — not a shared tunnel, not the public internet. Oracle provisions this on your behalf when you create an ODP resource.

Layer 3 — Virtual Network Gateway: In your Azure subscription, an ExpressRoute Virtual Network Gateway connects your Azure Virtual Network to the ExpressRoute circuit. This gateway must be provisioned in the same region as your ODP resource.

Layer 4 — Your Azure VNet: Your Azure VMs, AKS pods, App Service instances, and Azure Functions connect to Oracle DB through the VNet — same as any other Azure service. No special Oracle client configuration beyond the wallet.

Latency Profile

Prerequisites

Azure Requirements

●      Azure subscription with Owner or Contributor role

●      Azure CLI 2.x installed: az --version

●      An Azure Virtual Network (VNet) in the target region with at least one subnet

●      An ExpressRoute Virtual Network Gateway deployed in your VNet (Standard SKU minimum)

●      Microsoft Entra ID tenant with permissions to create service principals

●      Azure subscription linked to Oracle — done via Azure Marketplace (one-time setup)

OCI Requirements

●      An OCI tenancy (trial or paid) — Oracle provisions ODP resources in OCI behind the scenes

●      OCI CLI installed and configured: oci --version

●      Oracle account linked to your Azure subscription via the ODP onboarding flow

Step 1: Link Azure Subscription to Oracle via Marketplace

Navigate to Azure Portal → Marketplace → search 'Oracle Database@Azure' → Subscribe. This creates the cross-cloud trust relationship and provisions the ExpressRoute connectivity.

#Verify ODP provider is registered in your Azure subscription

az provider register --namespace Oracle.Database

az provider show --namespace Oracle.Database --query "registrationState"

#Expected: "Registered"

Step 2: Create ExpressRoute Virtual Network Gateway

This is the most time-consuming step — provisioning an ExpressRoute gateway takes 20–45 minutes. Do this first.

#Create gateway subnet (required naming — must be GatewaySubnet)

az network vnet subnet create \

--resource-group myRG \

--vnet-name myVNet \

--name GatewaySubnet \

--address-prefixes 10.0.255.0/27

#Create public IP for gateway

az network public-ip create \

--resource-group myRG \

--name oracle-er-gateway-pip \

--sku Standard \

--allocation-method Static

#Create ExpressRoute Virtual Network Gateway (takes 20-45 minutes)

az network vnet-gateway create \

--resource-group myRG \

--name oracle-er-gateway \

--vnet myVNet \

--gateway-type ExpressRoute \

--sku Standard \

--public-ip-address oracle-er-gateway-pip \

--no-wait  # Run async, check status with az network vnet-gateway show

Step-by-Step: Provisioning Oracle Autonomous Database on Azure

Step 3: Create ODP Resource via Azure Portal

Once the ExpressRoute gateway is provisioned, navigate to Azure Portal → Create a resource → Oracle Database@Azure → Autonomous Database.

Step 4: Store Credentials in Azure Key Vault

Unlike Oracle Database@AWS where you download a wallet ZIP, Oracle Database@Azure integrates with Azure Key Vault for credential management.

#Create Key Vault (if not existing)

az keyvault create \

--name oracle-prod-kv \

--resource-group oracle-prod-rg \

--location eastus \

--enable-rbac-authorization true

#Store the ADB admin password

az keyvault secret set \

--vault-name oracle-prod-kv \

--name "adb-admin-password" \

--value "YourSecurePassword2026!"

#Grant your app's managed identity access to the secret

az role assignment create \

--role "Key Vault Secrets User" \

--assignee <managed-identity-object-id> \

--scope /subscriptions/<sub-id>/resourceGroups/oracle-prod-rg/providers/Microsoft.KeyVault/vaults/oracle-prod-kv

Step 5: Download Wallet and Test Connectivity

#Download wallet via OCI CLI (ODP resources appear in OCI too)

oci db autonomous-database generate-wallet \

--autonomous-database-id <adb-ocid> \

--password "WalletPassword2026!" \

--file ~/wallets/prod-adb-azure.zip

mkdir -p ~/wallets/prod-adb-azure

unzip ~/wallets/prod-adb-azure.zip -d ~/wallets/prod-adb-azure

#Test connection from an Azure VM in the same VNet

export TNS_ADMIN=~/wallets/prod-adb-azure

sql ADMIN/YourSecurePassword2026!@prodadb01_high

#Verify platform

SELECT platform_name, version_full FROM v\(database d, v\)instance i;

Step 6: Connect from .NET / C# Application

Oracle Database@Azure is designed with Azure-native workloads in mind — particularly .NET applications. Use Oracle.ManagedDataAccess.Core:

// Install NuGet: Oracle.ManagedDataAccess.Core

// dotnet add package Oracle.ManagedDataAccess.Core

using Oracle.ManagedDataAccess.Client;

using Azure.Identity;

using Azure.Security.KeyVault.Secrets;

// Retrieve password from Key Vault (Managed Identity auth)

var kvClient = new SecretClient(

new Uri("https://oracle-prod-kv.vault.azure.net/"),

new DefaultAzureCredential()  // Uses Managed Identity in Azure, local creds in dev

);

var secret = await kvClient.GetSecretAsync("adb-admin-password");

// Build connection string

var connString = $"User Id=ADMIN;Password={secret.Value.Value};" +

"Data Source=prodadb01_high;" +

"Connection Timeout=30;Pooling=true;Min Pool Size=5;Max Pool Size=50;";

// Set wallet location

OracleConfiguration.TnsAdmin = "/path/to/wallet";

OracleConfiguration.WalletLocation = "/path/to/wallet";

using var conn = new OracleConnection(connString);

await conn.OpenAsync();

Console.WriteLine($"Connected: {conn.ServerVersion}");

Microsoft Entra ID Integration

One of the most compelling features of Oracle Database at Azure is native Microsoft Entra ID (formerly Azure AD) authentication for Oracle DB users. Your employees can log into Oracle using their corporate Entra ID credentials — no separate Oracle passwords to manage.

Enable Entra ID Authentication on ADB

-- Connect as ADMIN and enable Entra ID authentication EXEC DBMS_CLOUD_ADMIN.ENABLE_PRINCIPAL_AUTH( provider => 'AZURE_AD', params => JSON_OBJECT( 'azure_tenant_id' VALUE '', 'azure_app_id' VALUE '' ) );

-- Create a mapped Oracle user for an Entra ID user CREATE USER "user@yourdomain.com" IDENTIFIED EXTERNALLY AS 'user@yourdomain.com'; GRANT CONNECT, CREATE TABLE TO "user@yourdomain.com";

-- Create a mapped Oracle role for an Entra ID group CREATE ROLE "Oracle-DBAs" IDENTIFIED EXTERNALLY AS 'Oracle-DBAs'; -- Now assign permissions to the role; all members of the Entra group inherit them

🔐 Security Win

With Entra ID auth, DBA offboarding is instant — remove them from the Entra group and they immediately lose Oracle DB access. No hunting for Oracle passwords to revoke. No separate Oracle user lifecycle management.

Azure-Native Integrations

Oracle Database@Azure integrates with the broader Azure ecosystem in ways that Oracle Database@AWS does not — because Azure Portal surfaces ODP as a first-class Azure resource.

Azure Data Factory Oracle Connector

If you use Azure Data Factory for data movement, the Oracle connector works directly with Oracle Database at Azure — no self-hosted integration runtime needed if your ADF is in the same VNet:

// ADF Linked Service JSON (Oracle Database@Azure)

{

  "name": "OracleADB_LinkedService",

  "type": "Oracle",

  "typeProperties": {

    "connectionString": {

      "type": "SecureString",

      "value": "Host=<adb-host>;Port=1522;Sid=<service_name>;User Id=adf_user;"

    },

    "password": {

      "type": "AzureKeyVaultSecret",

      "store": { "referenceName": "AzureKeyVaultLinkedService", "type": "LinkedServiceReference" },

      "secretName": "adb-adf-password"

    }

  }

}

Pricing: Oracle Database at Azure vs Oracle Database at AWS vs Azure SQL

💰 MACC Advantage Calculation

If you have a \(500K MACC and use Oracle DB@Azure at \)900/month, that $10,800/year counts toward your Azure commitment — reducing your at-risk MACC balance. Oracle DB@AWS does NOT count toward MACC. For organizations with large Azure commitments, this can justify a 10–20% price premium over the AWS equivalent.

Oracle DB@Azure vs Oracle DB@AWS — When to Use Which

Migration Paths to Oracle Database at Azure

From On-Premises Oracle (Recommended: GoldenGate)

If you have existing Oracle on-premises and want to migrate to Oracle DB@Azure with minimal downtime:

-- Source: your on-premises Oracle DB

-- Target: Oracle ADB@Azure

-- Step 1: Install GoldenGate on-premises and configure Extract

-- (GoldenGate Microservices runs on OCI, accessible from on-prem via ExpressRoute)

-- Step 2: Verify supplemental logging is enabled on source

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;

-- Step 3: Initial load via Data Pump to Oracle Object Storage

expdp SYSTEM/password SCHEMAS=APP_USER DIRECTORY=DATA_PUMP_DIR \

  DUMPFILE=app_%U.dmp PARALLEL=4

-- Step 4: Start GoldenGate replication (catches changes during load)

-- Step 5: Validate row counts and data integrity

-- Step 6: Cutover — stop writes to source, let GoldenGate drain, switch app connection string

From Oracle on Azure VM (Simplest Path)

If you're already running Oracle Database on an Azure Virtual Machine, this is the simplest migration — you're in the same VNet, same region, no cross-cloud complexity:

#Direct Data Pump export from Oracle on Azure VM expdp SYSTEM/password@source_vm_db FULL=Y DUMPFILE=full_export_%U.dmp DIRECTORY=DATA_PUMP_DIR PARALLEL=8

#Copy dump files to Azure Blob Storage (then Oracle imports from Object Storage)

azcopy copy "/oracle/datapump/*.dmp" \

  "https://mystorageaccount.blob.core.windows.net/migration-container/" \

  --recursive

#Import into ADB@Azure via DBMS_DATAPUMP over DBMS_CLOUD -- (Run this on the ADB@Azure instance as ADMIN) BEGIN DBMS_CLOUD.GET_OBJECT( credential_name => 'AZURE_BLOB_CRED', object_uri => 'https://mystorageaccount.blob.core.windows.net/migration-container/full_export_01.dmp', directory_name => 'DATA_PUMP_DIR' ); END;

Best Practices for Production

Common Issues and Fixes

Issue: ExpressRoute Gateway Not Connecting

If the ODP resource is provisioned but the ExpressRoute circuit shows 'Not Connected', the most common cause is the gateway SKU. ODP requires Standard SKU or higher — the Basic SKU is not supported.

#Check ExpressRoute gateway SKU

az network vnet-gateway show \

  --resource-group myRG \

  --name oracle-er-gateway \

  --query "sku.name"

#If output is "Basic", you need to delete and recreate with Standard SKU

#Check circuit provisioning state

az network express-route list \

  --resource-group myRG \

  --query "[].{Name:name, State:provisioningState, CircuitState:circuitProvisioningState}"

Issue: ORA-12541 from Azure VM

If your Azure VM cannot reach the Oracle endpoint on port 1522, check the Network Security Group (NSG) on both the Oracle subnet and the VM subnet:

#Check NSG rules on the oracle-subnet

az network nsg rule list \

  --resource-group myRG \

  --nsg-name oracle-subnet-nsg \

  --output table

#Required: Allow inbound TCP 1522 from your app subnet

az network nsg rule create \

  --resource-group myRG \

  --nsg-name oracle-subnet-nsg \

  --name Allow-Oracle-TLS \

  --priority 100 \

  --protocol Tcp \

  --destination-port-range 1522 \

  --source-address-prefixes 10.0.1.0/24 \

  --access Allow

Issue: Entra ID Authentication Failing (ORA-01017)

If Entra ID authentication fails, verify the app registration in Entra ID has the correct API permissions and that the Oracle DB user name exactly matches the Entra UPN (case-sensitive):

-- Verify the mapped Oracle user exists and matches UPN exactly

SELECT username, authentication_type FROM dba_users

WHERE authentication_type = 'EXTERNAL';

-- UPN must be ALL CAPS in Oracle user definition

-- Correct:   CREATE USER "USER@YOURDOMAIN.COM" IDENTIFIED EXTERNALLY

-- Wrong:     CREATE USER "user@yourdomain.com" IDENTIFIED EXTERNALLY

📌 Subscribe

All posts publish at cloudexplorers.club — no paywalls, no sponsored content. Independent analysis only.

Safe Harbour & Disclaimer

PRICING DISCLAIMER: All prices shown are estimates based on publicly available Oracle Cloud, Microsoft Azure, and AWS pricing pages as of March 2026. Verify current pricing at cloud.oracle.com, azure.microsoft.com/pricing, and aws.amazon.com/pricing before making purchasing decisions.

SAFE HARBOUR: Oracle Database@Azure (ODP) features, regional availability, MACC eligibility, and pricing may change at any time without notice.

NO AFFILIATION: cloudexplorers.club is an independent technical blog not affiliated with Oracle Corporation or Microsoft Corporation. License: CC BY 4.0 — share and adapt with attribution to cloudexplorers.club.

Most engineers evaluating LLM APIs start with OpenAI, drift to Bedrock for AWS integration, and never look at OCI Generative AI. That is a mistake — especially if you are already running workloads on Oracle Cloud or need enterprise-grade data residency guarantees.

OCI Generative AI Service went GA in March 2024 with a model lineup that has grown steadily since: Cohere Command R, Command R+, Meta Llama 3, Cohere Embed, and Cohere Rerank. The service runs on dedicated GPU clusters inside OCI regions. Your prompts and completions never leave the region, and Oracle does not use your data to train models.

This guide takes you from zero to production-ready in a single session: OCI Console setup, IAM policies, your first API call via CLI, Python SDK integration, LangChain compatibility, embeddings, RAG pipeline, and an honest pricing comparison against OpenAI GPT-4o and AWS Bedrock.

Target Audience

Developers, ML engineers, and cloud architects who want to run LLM inference on OCI — either because they are already on Oracle Cloud or need enterprise data residency. No prior OCI AI experience required.

What Is OCI Generative AI Service?

OCI Generative AI is a fully managed inference service. You send a prompt, you get a completion. No GPUs to provision, no model weights to manage, no CUDA drivers. Oracle handles the infrastructure; you pay per token.

The service sits inside OCI as a first-class regional service — same IAM, same VCN networking, same audit logging as any other OCI service. It supports private endpoints, meaning your traffic can stay entirely within your VCN and never traverse the public internet.

Available Models (March 2026)

Model Selection Rule

For most RAG pipelines: command-r-plus for generation + embed-english-v3.0 for retrieval + rerank-english-v3.0 for reranking. This is a complete Cohere stack on OCI with no external API dependencies and full data residency.

Prerequisites and IAM Setup

Before writing a single line of code, IAM must be configured correctly. This is the step most tutorials skip — and why most developers hit OCI 401 errors on their first attempt.

Step 1: Enable OCI Generative AI

Navigate to OCI Console > Generative AI > Overview. Full model catalog is available in us-chicago-1. Frankfurt (eu-frankfurt-1) and London (uk-london-1) have a limited subset. Verify your tenancy region before starting.

Step 2: Create IAM Policy

OCI Generative AI requires explicit IAM policy statements. Without these, all API calls return 404 or 401.

#Create a group for GenAI users (OCI CLI)

oci iam group create \

  --name genai-users \

  --description "Users allowed to invoke OCI Generative AI"

#Add your user to the group

oci iam group add-user \

  --group-id <group-ocid> \

  --user-id <user-ocid>

Create the policy in OCI Console > Identity > Policies > Create Policy:

#Minimal policy (tenancy-wide)

Allow group genai-users to use generative-ai-family in tenancy

#Recommended: compartment-scoped for production

Allow group genai-users to use generative-ai-chat in compartment genai-prod

Allow group genai-users to use generative-ai-text-generation in compartment genai-prod

Allow group genai-users to use generative-ai-embed in compartment genai-prod

Allow group genai-users to use generative-ai-summarize in compartment genai-prod

Step 3: Install OCI CLI and Python SDK

#Install OCI CLI

bash -c "$(curl -L https://raw.githubusercontent.com/oracle/oci-cli/master/scripts/install/install.sh)"

oci setup config

#Verify Generative AI access

oci generative-ai model list \

  --compartment-id <your-compartment-ocid> \

  --output table

#Install Python SDK + LangChain

pip install oci langchain-community

#Verify

python3 -c "import oci; print(oci.__version__)"

Your First OCI Generative AI API Call

Let us start simple: a basic chat completion using Cohere Command R+. This verifies credentials, region endpoint, and IAM policy before building anything complex.

Via OCI CLI — Quickest Verification

export COMPARTMENT_ID="ocid1.compartment.oc1..xxxxxxxxxxxx"

oci generative-ai-inference chat \

  --compartment-id $COMPARTMENT_ID \

  --serving-mode '{"modelId":"cohere.command-r-plus","servingType":"ON_DEMAND"}' \

  --chat-request '{

    "message": "Explain Oracle Exadata in 2 sentences.",

    "maxTokens": 200,

    "temperature": 0.7,

    "chatHistory": []

  }'

Via Python SDK — Chat Completion

import oci

config = oci.config.from_file()

client = oci.generative_ai_inference.GenerativeAiInferenceClient(

    config=config,

    service_endpoint="https://inference.generativeai.us-chicago-1.oci.oraclecloud.com"

)

COMPARTMENT_ID = "ocid1.compartment.oc1..xxxxxxxxxxxx"

#Build request

chat_detail = oci.generative_ai_inference.models.CohereChatRequest() chat_detail.message = "What is Oracle Autonomous Database 23ai?" chat_detail.max_tokens = 500 chat_detail.temperature = 0.7

chat_request = oci.generative_ai_inference.models.ChatDetails() chat_request.serving_mode = oci.generative_ai_inference.models.OnDemandServingMode( model_id="cohere.command-r-plus" ) chat_request.chat_request = chat_detail chat_request.compartment_id = COMPARTMENT_ID

#Send and print

response = client.chat(chat_request)

print(response.data.chat_response.text)

Streaming Response (Production Pattern)

chat_detail.is_stream = True  # Add this to any chat request

response = client.chat(chat_request)

for event in response.data.events():

    print(event.data, end="", flush=True)

print()

Embeddings and Semantic Search

Embeddings convert text into dense vector representations — the foundation of RAG pipelines, semantic search, and document clustering.

Generate Embeddings

def get_embeddings(texts: list[str], input_type: str = "search_document") -> list: """ input_type: "search_document" | "search_query" | "classification" | "clustering" Use "search_document" when indexing, "search_query" at query time. """ embed_req = oci.generative_ai_inference.models.EmbedTextDetails() embed_req.serving_mode = oci.generative_ai_inference.models.OnDemandServingMode( model_id="cohere.embed-english-v3.0" ) embed_req.compartment_id = COMPARTMENT_ID embed_req.inputs = texts embed_req.input_type = input_type response = client.embed_text(embed_req) return response.data.embeddings

#Example

docs = [

    "Oracle Autonomous Database is a self-managing database service.",

    "OCI Object Storage provides durable, scalable object storage.",

    "Oracle Exadata delivers extreme database performance.",

]

embeddings = get_embeddings(docs)

print(f"Embeddings: {len(embeddings)} vectors of dim {len(embeddings[0])}")

#Output: Embeddings: 3 vectors of dim 1024

Simple Semantic Search

import numpy as np

def cosine_similarity(a, b): a, b = np.array(a), np.array(b) return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

query_emb = get_embeddings(["Best service for high-performance DB?"], "search_query")[0] results = sorted([(cosine_similarity(query_emb, e), d) for e, d in zip(embeddings, docs)], reverse=True)

for score, doc in results: print(f"{score:.4f} — {doc[:60]}")

#0.8821 — Oracle Exadata delivers extreme database performance...

#0.7234 — Oracle Autonomous Database is a self-managing...

LangChain Integration

OCI Generative AI has first-class support in LangChain — drop it into any existing pipeline as a replacement for OpenAI or Bedrock.

LangChain Chat + RAG Pipeline

from langchain_community.chat_models.oci_generative_ai import ChatOCIGenAI from langchain_community.embeddings.oci_generative_ai import OCIGenAIEmbeddings from langchain_community.vectorstores import FAISS from langchain_core.prompts import ChatPromptTemplate from langchain_core.runnables import RunnablePassthrough from langchain_core.output_parsers import StrOutputParser

#LLM llm = ChatOCIGenAI( model_id="cohere.command-r-plus", service_endpoint="https://inference.generativeai.us-chicago-1.oci.oraclecloud.com", compartment_id=COMPARTMENT_ID, model_kwargs={"temperature": 0.7, "max_tokens": 500} )

#Embeddings embeddings = OCIGenAIEmbeddings( model_id="cohere.embed-english-v3.0", service_endpoint="https://inference.generativeai.us-chicago-1.oci.oraclecloud.com", compartment_id=COMPARTMENT_ID, input_type="search_document" )

#Build vector store and RAG chain

docs = ["Oracle ADB auto-scales compute independently from storage.",

        "OCI Gen AI supports Cohere and Llama 3 on dedicated GPU clusters.",

        "Data Guard provides automatic failover with RPO under 5 seconds."] 

vectorstore = FAISS.from_texts(docs, embeddings)

retriever = vectorstore.as_retriever(search_kwargs={"k": 2})

prompt = ChatPromptTemplate.from_template(

    "Answer based only on context:\n{context}\n\nQuestion: {question}"

)

chain = ({"context": retriever, "question": RunnablePassthrough()} | prompt | llm | StrOutputParser())

print(chain.invoke("Does OCI support automatic database failover?"))

Pricing: OCI vs OpenAI vs AWS Bedrock

Cost Reality Check

OCI Llama 3 70B is currently FREE on On Demand. For production workloads where GPT-4o quality is not required, Llama 3 70B on OCI reduces LLM inference cost to zero at the model layer. You only pay OCI compute for your application server.

Best Practices for Production

Honest Limitations

●      No function calling / tool use for Cohere models via OCI SDK — use direct Cohere API for structured tool use workflows

●      Llama 3 context window is 8K tokens — not suitable for long-document tasks (use Command R+ at 128K instead)

●      No image / multimodal support yet — vision models not available on OCI Gen AI Service as of March 2026

●      Region availability: Full model catalog only in us-chicago-1; other regions have limited model selection

●      Rate limits on On Demand tier are per-tenancy, not per-compartment — a spike in one team throttles others

When to Choose OCI Gen AI

Use OCI if: already on OCI, need data residency, want Llama 3 for free, or need the full Cohere RAG stack (Command R+ + Embed + Rerank) without external dependencies. Use OpenAI/Bedrock if: you need multimodal, function calling, or the absolute latest frontier models within days of release.

Safe Harbour & Disclaimer

PRICING DISCLAIMER: All prices are estimates based on publicly available OCI, OpenAI, and AWS pricing pages as of March 2026. Llama 3 free pricing is subject to Oracle pricing policy changes without notice. Verify at cloud.oracle.com, openai.com/pricing, and aws.amazon.com/bedrock/pricing before purchasing decisions.

SAFE HARBOUR: OCI Generative AI model availability, pricing, and features may change at any time without notice.

NO AFFILIATION: cloudexplorers.club is an independent technical blog not affiliated with Oracle Corporation, Cohere Inc., or Meta Platforms. License: CC BY 4.0 — share and adapt with attribution to cloudexplorers.club.

For decades, Oracle and AWS operated like rival kingdoms — you could run Oracle Database on an EC2 instance, but you were doing it yourself, unsupported, with all the infrastructure complexity that entails. In June 2023, that changed dramatically.

Oracle and AWS announced Oracle Database@AWS: a fully managed Oracle Database service running on dedicated Oracle Exadata infrastructure inside AWS data centers — but owned, operated, and supported entirely by Oracle. You manage it through the OCI console. You pay Oracle for the database. AWS never touches it.

This is not a marketing rebrand of RDS for Oracle. This is fundamentally different infrastructure with a fundamentally different support model. This guide explains exactly what it is, how the networking works, how to set it up step by step, and — critically — when you should and should not use it.

🎯 Who This Post Is For

DBAs, cloud architects, and engineering leads evaluating whether to run Oracle Autonomous Database or Oracle Exadata in AWS environments without re-platforming to PostgreSQL or Aurora.

What Is Oracle Database@AWS, Exactly?

Oracle Database@AWS is a managed service that provisions Oracle Database infrastructure — specifically Oracle Exadata Database Service and Oracle Autonomous Database — inside AWS Availability Zones. The key technical details:

Infrastructure: Oracle Exadata X9M hardware racks physically located inside AWS data centers

Network connectivity: Connected to your AWS VPC via a high-speed, low-latency private network link (sub-millisecond latency to EC2)

Management plane: OCI Console, OCI APIs, and OCI CLI — not the AWS Console

Support: Oracle Cloud Support — not AWS Support

Billing: Oracle Cloud billing — appears on your OCI invoice, not your AWS bill

Identity: OCI IAM for database users; AWS IAM for your applications via cross-service roles

Regions: Initially US East (N. Virginia), expanding to additional regions

What Databases Are Available?

💡 Key Insight

For most teams evaluating Oracle Database@AWS, the answer is Oracle Autonomous Database Serverless — it requires zero Exadata rack commitment, scales by the ECPU, and is the fastest to provision (under 5 minutes).

Network Architecture: How It Actually Connects

Understanding the network topology is critical before you provision anything. Oracle Database@AWS does not create an endpoint inside your VPC in the traditional sense. Instead, it creates an OCI VCN (Virtual Cloud Network) that is peered into your AWS VPC through a dedicated interconnect.

The Three-Layer Network Model

Layer 1 — Physical interconnect:

Oracle and AWS maintain a dedicated high-speed network link between Oracle Exadata racks and AWS network infrastructure within the same data center campus. This is NOT traversing the public internet.

Layer 2 — OCI VCN:

Your Oracle Database instances live inside an OCI VCN subnet. Oracle manages this entirely. You see it in the OCI Console.

Layer 3 — AWS VPC endpoint:

Oracle provisions a VPC endpoint in your AWS account. Your EC2 instances, Lambda functions, ECS containers, and EKS pods connect to Oracle DB through this endpoint using standard Oracle Net (TCP/1521 or TCP/2484 for TLS).

Latency Characteristics

Prerequisites Before You Start

Before provisioning Oracle Database@AWS, you need accounts and configurations in both OCI and AWS. This is genuinely the most confusing part for teams new to the service — you're operating across two cloud consoles simultaneously.

OCI Requirements

●      An active OCI tenancy (trial or paid)

●      OCI user with tenancy-level privileges (or appropriate IAM policies)

●      OCI CLI installed and configured: oci --version should return 3.x+

●      OCI tenancy subscribed to the US East (Ashburn) or relevant region

●      Credit card or Oracle Universal Credits on file

AWS Requirements

●      AWS account with permissions to create VPCs, subnets, security groups

●      AWS CLI configured: aws --version should return 2.x+

●      A VPC in us-east-1 (N. Virginia) with at least one private subnet

●      AWS account linked to OCI via the Oracle Database@AWS integration

Linking Your AWS Account to OCI

The linking process is a one-time setup done in the AWS Marketplace. Navigate to AWS Marketplace → find 'Oracle Database@AWS' → subscribe. This creates the cross-account trust relationship.

# Verify OCI CLI is configured

oci iam region list --output table

# Verify AWS CLI is configured

aws sts get-caller-identity

# Output should show your AWS account ID

# {

#   "UserId": "AIDAXXXXXXXXXXXXXXXXX",

#   "Account": "123456789012",

#   "Arn": "arn:aws:iam::123456789012:user/your-user"

# }

Step-by-Step: Provisioning Oracle Autonomous Database on AWS

We'll provision an Oracle Autonomous Database Serverless instance — the quickest path to a running Oracle DB in AWS. The full process takes approximately 10–15 minutes once prerequisites are met.

Step 1: Create the Oracle Database@AWS Resource in OCI Console

Navigate to the OCI Console → Oracle Database@AWS → Autonomous Database. Click 'Create Autonomous Database'.

Step 2: Retrieve the Connection Endpoint

After provisioning (3–8 minutes), navigate to your ADB instance → DB Connection → Download Wallet. The wallet contains:

●      tnsnames.ora — connection string definitions

●      sqlnet.ora — network configuration

●      cwallet.sso and ewallet.p12 — SSL certificates

●      ojdbc.properties — JDBC properties file

# Unzip wallet to a secure directory

mkdir -p ~/oracle-wallet/prod-adb

unzip Wallet_PRODADB01.zip -d ~/oracle-wallet/prod-adb

# Check available connection strings

cat ~/oracle-wallet/prod-adb/tnsnames.ora

# Output will show connection strings like:

# prodadb01_high = (description=(retry_count=20)(retry_delay=3)

#   (address=(protocol=tcps)(port=1522)

#   (host=adb.us-east-1.oraclecloud.com))

#   (connect_data=(service_name=xxxxx_prodadb01_high.adb.oraclecloud.com))

#   (security=(ssl_server_dn_match=yes)))

Step 3: Configure Security Groups

Your EC2 instances need outbound access to the Oracle DB endpoint on port 1522 (TLS). Create a security group rule:

# Get the VPC endpoint DNS name from OCI Console

# Then create outbound rule for your application security group

aws ec2 authorize-security-group-egress \

--group-id sg-xxxxxxxxxxxxxxxxx \

--ip-permissions '[

{

"IpProtocol": "tcp",

"FromPort": 1522,

"ToPort": 1522,

"IpRanges": [{"CidrIp": "10.0.0.0/8", "Description": "Oracle DB@AWS endpoint"}]

}

]'

# For mutual TLS (recommended), also allow port 1521

aws ec2 authorize-security-group-egress \

--group-id sg-xxxxxxxxxxxxxxxxx \

--ip-permissions '[{"IpProtocol": "tcp", "FromPort": 1521, "ToPort": 1521,

"IpRanges": [{"CidrIp": "10.0.0.0/8"}]}]'

Step 4: Test Connectivity from EC2

SSH into an EC2 instance in the same VPC and run a connection test using SQLcl or SQL*Plus:

# Install SQLcl on Amazon Linux 2023

sudo dnf install java-21-amazon-corretto -y

wget https://download.oracle.com/otn_software/java/sqldeveloper/sqlcl-latest.zip

unzip sqlcl-latest.zip

# Set wallet location in environment

export TNS_ADMIN=~/oracle-wallet/prod-adb

# Connect to Autonomous Database

sql ADMIN/'OCI#Secure2026!'@prodadb01_high

# Expected output:

# SQLcl: Release 24.3 Production on ...

# Connected to:

# Oracle Database 23ai Enterprise Edition

# SQL>

# Verify you are on Exadata infrastructure

SELECT platform_name, version_full FROM v\(database d, v\)instance i;

Step 5: Connect a Java Application via JDBC

For production applications, use the Oracle JDBC driver with the wallet. Add the dependency to your pom.xml:

com.oracle.database.jdbc

ojdbc11

23.5.0.24.07

com.oracle.database.security

oraclepki

23.5.0.24.07

// Java connection example with wallet

import oracle.jdbc.pool.OracleDataSource;

OracleDataSource ods = new OracleDataSource();

ods.setURL("jdbc:oracle:thin:@prodadb01_high?TNS_ADMIN=/path/to/wallet");

ods.setUser("ADMIN");

ods.setPassword(System.getenv("ORACLE_DB_PASSWORD")); // Never hardcode!

try (Connection conn = ods.getConnection()) {

Statement stmt = conn.createStatement();

ResultSet rs = stmt.executeQuery("SELECT * FROM v$version");

while (rs.next()) {

System.out.println(rs.getString(1));

}

}

Pricing: What It Actually Costs

Oracle Database@AWS pricing has two components: the Oracle database service (ECPU + Storage + Options) and any AWS data transfer charges. There are no Oracle fees for the network interconnect itself.

Autonomous Database Serverless Pricing (us-east-1, April 2026)

Oracle Database@AWS vs Alternatives: Cost Comparison

When to Use Oracle Database@AWS (And When Not To)

This is the section most comparison articles skip. Oracle Database@AWS is genuinely excellent for specific scenarios and genuinely wrong for others.

✅ Use Oracle Database@AWS When:

●      Your application is already on AWS (ECS, EKS, Lambda, EC2) and you need Oracle DB — no migration, no re-architecture

●      You need Oracle-specific features: Partitioning, Advanced Compression, RAC, Data Guard — features RDS for Oracle supports poorly or not at all

●      Oracle licensing compliance is critical — Oracle Customer Success provides direct support, not AWS

●      You need Oracle 23ai features: JSON Relational Duality Views, True Cache, AI Vector Search

●      Your DBA team knows Oracle but not AWS-native databases — lowest re-training cost

●      Regulatory requirements mandate Oracle as the database (common in banking, healthcare, government)

❌ Do NOT Use Oracle Database@AWS When:

●      You are a greenfield project — consider Aurora PostgreSQL or DynamoDB first

●      Cost is the primary constraint — Oracle licensing costs will dominate

●      Your workload is 100% cloud-native and Oracle-agnostic — you are paying for features you will not use

●      You need multi-region active-active — Oracle Data Guard is active-passive; global tables on DynamoDB or Aurora Global are better

●      Your team has no Oracle DBA expertise — managed does not mean zero-knowledge

●      You are evaluating this as a "migration path off Oracle" — this keeps you on Oracle; if you want off, use AWS DMS to PostgreSQL instead

Migrating an Existing Oracle Database to Oracle DB@AWS

If you have Oracle running on-premises or on EC2, here are the three primary migration paths:

Option A: Oracle Data Pump (Export/Import) — Best for < 500 GB

-- On source database: export schema

expdp SYSTEM/password@source_db \

SCHEMAS=APP_USER \

DIRECTORY=DATA_PUMP_DIR \

DUMPFILE=app_export_%U.dmp \

LOGFILE=app_export.log \

PARALLEL=4

-- Upload to OCI Object Storage

oci os object bulk-upload \

--bucket-name migration-bucket \

--src-dir /oracle/datapump/

-- On target ADB: import

impdp ADMIN/password@prodadb01_high \

SCHEMAS=APP_USER \

DIRECTORY=DATA_PUMP_DIR \

DUMPFILE=app_export_%U.dmp \

REMAP_SCHEMA=APP_USER:APP_USER \

PARALLEL=4

Option B: Oracle GoldenGate — Best for Zero-Downtime Migration

GoldenGate provides continuous replication from your source database to ADB, allowing you to cut over with < 1 minute downtime. This is the recommended path for production systems with SLA requirements.

The process: configure GoldenGate Extract on source → configure GoldenGate Replicat on ADB → initial load → catch up CDC → validate data → cutover.

Option C: AWS Database Migration Service (DMS) + Schema Conversion

DMS supports Oracle as a source and Oracle as a target. Use this path if you are also evaluating conversion to PostgreSQL — SCT (Schema Conversion Tool) shows you the conversion complexity before you commit.

Monitoring & Observability

Oracle Database@AWS exposes metrics through both OCI Monitoring and — critically — AWS CloudWatch. This dual-plane observability is one of the service's underrated strengths.

OCI Monitoring Metrics

# Query ADB CPU utilization via OCI CLI

oci monitoring metric-data summarize-metrics-data \

--compartment-id ocid1.compartment.oc1..xxxx \

--namespace oracle_autonomous_database \

--query-text 'CpuUtilization[1m]{resourceId = "ocid1.autonomousdatabase.oc1..xxxx"}.mean()' \

--start-time 2026-03-17T00:00:00Z \

--end-time 2026-03-17T06:00:00Z

CloudWatch Integration

Enable CloudWatch metrics publishing from the OCI Console → Autonomous Database → CloudWatch Integration. Metrics appear in CloudWatch under the OracleDatabase namespace within 5 minutes.

Best Practices for Production Deployments

Common Issues and Fixes

Issue: ORA-12541: TNS:no listener

Most common cause: your EC2 security group outbound rules do not allow traffic to port 1522. Secondary cause: TNS_ADMIN environment variable not pointing to the correct wallet directory.

# Verify TNS_ADMIN is set

echo $TNS_ADMIN

# Test port connectivity from EC2

nc -zv 1522

# If nc fails, check security group egress rules

aws ec2 describe-security-groups \

--group-ids sg-xxxxxxxxxxxxxxxxx \

--query "SecurityGroups[0].IpPermissionsEgress"

Issue: ORA-28000: Account is locked

The ADMIN account locks after 10 failed login attempts. Unlock via OCI Console → Autonomous Database → Database Users → ADMIN → Unlock. For application users, unlock via SQL:

-- Connect as ADMIN and unlock application user

ALTER USER app_user ACCOUNT UNLOCK;

ALTER USER app_user IDENTIFIED BY "NewSecurePassword2026!";

Issue: Slow Query Performance vs. On-Premises Oracle

If queries are slower than expected after migration, the most common causes are: (1) missing indexes that Automatic Indexing hasn't yet identified, (2) stale statistics, (3) using the wrong connection string (_low instead of _high for OLTP).

-- Check and gather fresh statistics

EXEC DBMS_STATS.GATHER_SCHEMA_STATS(ownname => 'APP_USER', cascade => TRUE);

-- Check Automatic Indexing recommendations

SELECT * FROM DBA_AUTO_INDEX_IND_ACTIONS ORDER BY creation_time DESC;

-- Check current connection service level

SELECT SYS_CONTEXT('USERENV', 'SERVICE_NAME') FROM DUAL;

Safe Harbour & Disclaimer

PRICING DISCLAIMER: All prices shown are estimates based on publicly available AWS and Oracle pricing pages as of March 2026 and may not reflect current rates, promotional pricing, committed use discounts, or enterprise agreements. Verify current pricing at cloud.oracle.com and aws.amazon.com/pricing before making purchasing decisions.

SAFE HARBOUR: This post contains forward-looking statements based on current service capabilities. Oracle and AWS may change, discontinue, or alter Oracle Database@AWS features, availability, and pricing at any time without notice.

NO AFFILIATION: cloudexplorers.club is an independent technical blog. This post is not sponsored by, endorsed by, or affiliated with Oracle Corporation or Amazon Web Services. All opinions are those of the author.

LICENSE: This post is published under Creative Commons Attribution 4.0 International (CC BY 4.0). You may share and adapt with attribution to cloudexplorers.club.

Most cloud cost comparisons are useless. They compare raw compute prices while ignoring the three things that actually drive enterprise cloud bills: Oracle database licensing multipliers, data egress fees that compound every month, and support costs that silently add 3–10% to every invoice.

This post does it differently. We'll compare OCI and AWS across a realistic Oracle database workload — the kind teams actually run in production — using real pricing data, real OCI and AWS CLI commands to query what you're spending, and an honest verdict on where each platform wins.

Spoiler: OCI is dramatically cheaper for Oracle database workloads. But AWS wins in specific scenarios, and we'll cover those too. No vendor spin. Let's look at the numbers.

🎯  What This Post Covers

Real pricing comparison for: Compute (OCPU vs vCPU), Block Storage (OCI vs EBS), Object Storage egress (10TB/month), Oracle DB Enterprise Edition licensing multipliers on each cloud, enterprise support costs, and a full TCO calculator you can adapt to your own workload.

Section 1: How OCI and AWS Price Compute Differently

Before looking at numbers, you need to understand why compute pricing is fundamentally different between the two clouds — not just in dollars but in the unit of measure.

OCI: OCPU-Based Flexible Pricing

OCI prices compute in OCPUs (Oracle CPU units). One OCPU equals two vCPUs (one physical core with hyperthreading). You can also scale OCPUs and memory independently on flexible shapes — pay for exactly what you need, rounded to the nearest OCPU.

# Query your current OCI compute instance shapes and hourly costs

oci compute shape list \

--compartment-id $COMPARTMENT_OCID \

--query 'data[?contains(shapeFlex)].{shape:shape,ocpus:"ocpu-options".max,mem:"memory-options".max-in-gbs}' \

--output table

# Check running instance costs (requires Cost Management service)

oci usage-api usage-summary request \

--tenant-id $TENANCY_OCID \

--time-usage-started 2026-03-01T00:00:00Z \

--time-usage-ended 2026-03-31T23:59:59Z \

--granularity MONTHLY \

--query-type COST \

--group-by '[{"type":"tag","key":"computeShape"}]'

AWS: vCPU-Based Fixed Instance Families

AWS EC2 uses fixed instance families (m6a.xlarge, r6g.2xlarge, etc.) where you buy predefined CPU + memory bundles. You cannot split them. For Oracle licensing, this creates a critical hidden cost: AWS counts each vCPU as 0.5 processor licenses — which means an 8-vCPU instance requires 4 processor licenses. OCI counts OCPUs directly, so an 8-OCPU instance also requires 4 licenses — but those 8 OCPUs deliver 16 vCPUs of compute. You get twice the compute for the same license count.

# AWS CLI: List EC2 instance pricing for a specific type

aws pricing get-products \

  --service-code AmazonEC2 \

  --region us-east-1 \

  --filters \

    'Type=TERM_MATCH,Field=instanceType,Value=r6a.2xlarge' \

    'Type=TERM_MATCH,Field=operatingSystem,Value=Linux' \

    'Type=TERM_MATCH,Field=tenancy,Value=Shared' \

  --query 'PriceList[0]' | python3 -m json.tool | grep -A3 'pricePerUnit'

# Result: r6a.2xlarge (8 vCPU, 64GB RAM) = ~\(0.4536/hour = \)332/month

💡  The Licensing Multiplier — The Biggest Hidden Cost

On AWS: 8 vCPUs = 4 Oracle processor licenses required. On OCI: 8 OCPUs = 4 Oracle processor licenses required — but those 8 OCPUs = 16 vCPUs of compute. Same license cost, double the compute on OCI. At \(47,500/processor/year Oracle EE list price, this alone saves ~\)95,000/year for a moderately sized deployment.

Figure 1: OCI's flat network fabric vs AWS's layered architecture — fewer hops means lower latency and simpler cost modelling

Section 2: Storage — Where the Price Gap Gets Extreme

Block Storage: OCI vs AWS EBS

OCI Block Volumes use a simple model: you pay for capacity in GB-months and optionally for IOPS/throughput performance units. The baseline Balanced performance tier (60 IOPS/GB) is often more than enough for database workloads and costs a fraction of AWS EBS.

# OCI: Create a 2TB high-performance block volume

oci bv volume create \

  --compartment-id $COMPARTMENT_OCID \

  --availability-domain $AD \

  --display-name 'prod-db-volume' \

  --size-in-gbs 2048 \

  --vpus-per-gb 20    # 20 VPUs = High Performance (2000 IOPS/GB max)

# Query your block volume costs

oci bv volume list \

  --compartment-id $COMPARTMENT_OCID \

  --query 'data[*].{name:"display-name",gb:"size-in-gbs",vpus:"vpus-per-gb"}' \

  --output table

# OCI pricing (US East, on-demand):

# Balanced (10 VPUs):  \(0.0255/GB-month  = \)52/month for 2TB

# High Perf (20 VPUs): \(0.0375/GB-month = \)76/month for 2TB

# AWS: Equivalent EBS volume for Oracle DB (io2 for production IOPS)

aws ec2 create-volume \

  --region us-east-1 \

  --availability-zone us-east-1a \

  --size 2048 \

  --volume-type io2 \

  --iops 50000

# AWS EBS io2 pricing (us-east-1):

# Storage:  \(0.125/GB-month  = \)256/month for 2TB

# IOPS:     \(0.065/IOPS-month = \)3,250/month for 50,000 IOPS

# TOTAL:    ~$3,506/month for comparable performance

# gp3 (cheaper option, lower IOPS ceiling):

# Storage:  \(0.08/GB-month = \)164/month

# IOPS:     \(0.005/IOPS-month beyond 3000 = \)235/month extra for 50k IOPS

# TOTAL:   ~$399/month (but gp3 has 16,000 IOPS limit — not enough for Oracle OLTP)

💡  OCI Block Volume VPUs Explained

VPUs (Volume Performance Units) let you dial performance up or down on a live volume. 0 VPUs = Lower Cost (2 IOPS/GB), 10 VPUs = Balanced (60 IOPS/GB), 20 VPUs = Higher Performance (up to 225,000 IOPS). AWS requires you to pick gp2, gp3, io1, or io2 at creation — changing types requires a multi-hour migration.

Object Storage & Data Egress — Where OCI Wins by a Factor of 13

This is the line item that shocks most AWS-first architects when they see an OCI bill. OCI includes 10 TB of outbound data transfer per month at no charge across all regions. AWS includes 100 GB — then charges $0.09/GB for the next 9.9 TB.

# OCI: Check your egress usage this month

oci monitoring metric-data summarize-metrics-data \

  --compartment-id $COMPARTMENT_OCID \

  --namespace oci_objectstorage \

  --query-text 'BytesDownloaded[1d].sum()' \

  --start-time 2026-03-01T00:00:00Z \

  --end-time 2026-03-31T23:59:59Z

# OCI egress pricing:

# First 10 TB/month: FREE

# 10-50 TB/month:    \(0.0085/GB  (vs AWS \)0.09/GB = 10.6x cheaper)

# 50+ TB/month:      \(0.0068/GB  (vs AWS \)0.085/GB = 12.5x cheaper)

# 10 TB per month cost comparison:

# OCI:  $0 (within free tier)

# AWS: (10TB - 100GB) x \(0.09 = 9,900 GB x \)0.09 = $891/month

# AWS: Check your data transfer costs (Cost Explorer API)

aws ce get-cost-and-usage \

  --time-period Start=2026-03-01,End=2026-03-31 \

  --granularity MONTHLY \

  --filter '{"Dimensions":{"Key":"USAGE_TYPE","Values":["DataTransfer-Out-Bytes"]}}' \

  --metrics BlendedCost AmortizedCost

# If you're doing 50TB/month outbound (common for analytics/reporting):

# OCI:  first 10TB free + 40TB x \(0.0085 = \)340/month

# AWS:  50TB x \(0.09 (roughly) = \)4,500/month

# Annual delta: (\(4,500 - \)340) x 12 = $49,920/year saved

Figure 2: Full TCO breakdown for an 8 OCPU/64GB Oracle EE BYOL production database — on-demand pricing, US East region

Section 3: Oracle Database Licensing — The Cost Multiplier

This section is critical and often misunderstood. Oracle's licensing policy directly ties to the physical core count of the underlying hardware in a way that's very different between OCI and AWS.

The Oracle Processor Core Factor Table

Oracle publishes a Processor Core Factor Table. For x86-64 processors (which both OCI and AWS use), the factor is 0.5 — meaning each physical core requires 0.5 processor licenses. The critical difference is how each cloud maps your VM to physical cores.

The same 4 licenses run on AWS cost you double in compute charges because AWS sells by vCPU not OCPU. You pay for the hyperthreading overhead but Oracle doesn't count it as extra compute in their licensing — only OCI makes this efficiency transparent in the pricing.

# OCI: Check what OCPU count your DB instance is using

oci db system get \

  --db-system-id $DB_SYSTEM_OCID \

  --query 'data.{shape:shape,cpuCoreCount:"cpu-core-count",memory:"data-storage-size-in-gbs"}' \

  --output table

# Calculate your Oracle license requirement:

# OCI formula: ceil(OCPU_count * 0.5) = processor licenses needed

# 4 OCPU  → 2 licenses

# 8 OCPU  → 4 licenses

# 16 OCPU → 8 licenses

# AWS formula (for standard EC2 with BYOL):

# ceil(vCPU_count * 0.5) — same math BUT you pay for more vCPUs

# to match OCI 8 OCPU performance you need 16 vCPU instance

# 16 vCPU → 8 processor licenses → double the licensing cost

💡  Oracle Support Rewards — Free Support for OCI Spend

OCI customers earn \(0.25–\)0.33 in Oracle Support Rewards for every \(1 spent on OCI. These rewards directly offset your Oracle on-premises software support bill — potentially reducing it to zero. AWS customers receive no equivalent benefit. For a team spending \)10,000/month on OCI, that's up to $3,300/month off your Oracle support invoice.

Section 4: The Full TCO Calculator — Build Your Own

Here's a reusable bash script that queries both OCI and does the equivalent AWS pricing calculation for your specific workload. Replace the variables at the top with your actual shapes and usage.

#!/bin/bash

# ── OCI vs AWS TCO Calculator ───────────────────────────────

# Adjust these variables for your workload:

OCI_OCPUS=8

OCI_MEM_GB=64

BLOCK_STORAGE_TB=2

EGRESS_TB_MONTH=10

ORACLE_PROC_LICENSES=4    # OCI value; AWS would need 8 for same compute

ORACLE_EE_SUPPORT_ANNUAL=47500  # Per processor, standard list price

# OCI pricing constants (US East, on-demand, Q1 2026)

OCI_OCPU_RATE=0.0300        # per OCPU-hour (E4 AMD Flex)

OCI_MEM_RATE=0.0015         # per GB-hour

OCI_BLOCK_RATE=0.0255       # per GB-month (Balanced)

OCI_EGRESS_FREE_TB=10

OCI_EGRESS_RATE=0.0085      # per GB above free tier

OCI_SUPPORT_RATE=0          # included

# AWS pricing constants (us-east-1, on-demand, r6a family)

AWS_VCPU_RATE=0.0567        # r6a.4xlarge per hour (÷16 vCPU)

AWS_EBS_GP3_RATE=0.08       # per GB-month (gp3)

AWS_EGRESS_RATE=0.09        # per GB beyond 100GB

AWS_SUPPORT_PCT=0.03        # 3% of monthly bill (Business tier)

AWS_LICENSE_MULTIPLIER=2    # Need 2x licenses for equivalent compute

# ── Calculate OCI Monthly Cost ───────────────────────────────

OCI_COMPUTE=\((echo "\)OCI_OCPUS \(OCI_OCPU_RATE 730 + \)OCI_MEM_GB $OCI_MEM_RATE 730" | bc)

OCI_BLOCK=\((echo "\)BLOCK_STORAGE_TB 1024 $OCI_BLOCK_RATE" | bc)

OCI_EGRESS=0  # within free tier

OCI_LICENSE_MO=\((echo "\)ORACLE_PROC_LICENSES * $ORACLE_EE_SUPPORT_ANNUAL / 12" | bc)

OCI_TOTAL=\((echo "\)OCI_COMPUTE + \(OCI_BLOCK + \)OCI_EGRESS + $OCI_LICENSE_MO" | bc)

# ── Calculate AWS Monthly Cost ───────────────────────────────

AWS_VCPUS=$((OCI_OCPUS * 2))  # double vCPUs for same performance

AWS_COMPUTE=\((echo "\)AWS_VCPUS $AWS_VCPU_RATE 730" | bc)

AWS_BLOCK=\((echo "\)BLOCK_STORAGE_TB 1024 $AWS_EBS_GP3_RATE" | bc)

AWS_EGRESS_GB=\((echo "(\)EGRESS_TB_MONTH * 1024) - 100" | bc)

AWS_EGRESS=\((echo "\)AWS_EGRESS_GB * $AWS_EGRESS_RATE" | bc)

AWS_LICENSE_MO=\((echo "\)ORACLE_PROC_LICENSES \(AWS_LICENSE_MULTIPLIER \)ORACLE_EE_SUPPORT_ANNUAL / 12" | bc)

AWS_SUBTOTAL=\((echo "\)AWS_COMPUTE + \(AWS_BLOCK + \)AWS_EGRESS + $AWS_LICENSE_MO" | bc)

AWS_SUPPORT=\((echo "\)AWS_SUBTOTAL * $AWS_SUPPORT_PCT" | bc)

AWS_TOTAL=\((echo "\)AWS_SUBTOTAL + $AWS_SUPPORT" | bc)

# ── Print Report ─────────────────────────────────────────────

echo '============================================'

echo '   OCI vs AWS TCO COMPARISON (Monthly)'

echo '============================================'

printf '%-30s %10s %10s\n' 'Component' 'OCI' 'AWS'

printf '%-30s %10s %10s\n' '---' '---' '---'

printf '%-30s %10s %10s\n' 'Compute' "$$OCI_COMPUTE" "$$AWS_COMPUTE"

printf '%-30s %10s %10s\n' 'Block Storage' "$$OCI_BLOCK" "$$AWS_BLOCK"

printf '%-30s %10s %10s\n' 'Data Egress' "$$OCI_EGRESS" "$$AWS_EGRESS"

printf '%-30s %10s %10s\n' 'Oracle Licensing' "$$OCI_LICENSE_MO" "$$AWS_LICENSE_MO"

printf '%-30s %10s %10s\n' 'Enterprise Support' 'INCL.' "$$AWS_SUPPORT"

echo '---'

printf '%-30s %10s %10s\n' 'TOTAL' "$$OCI_TOTAL" "$$AWS_TOTAL"

Figure 3: Decision framework — when OCI wins vs when AWS is the right call for your specific workload

Section 5: Where AWS Wins — The Honest Part

This post would be dishonest if it didn't acknowledge the scenarios where AWS is genuinely the better choice. Here they are:

GPU Workloads at Small Scale

For A10-class GPU instances, AWS g5 instances are approximately 33% cheaper than equivalent OCI GPU shapes at small scale (1–2 GPUs). OCI wins significantly for A100 and H100 deployments at scale (4+ GPUs), but if you're running small ML inference, AWS has the edge here.

Service Breadth and Ecosystem

AWS has over 200 managed services vs OCI's approximately 80. If your architecture depends on AWS-native services — Kinesis, Step Functions, AWS Glue, EventBridge, SageMaker, or Bedrock — AWS is simply the more integrated choice. Replicating these on OCI requires more custom work.

Spot Compute for Batch Workloads

AWS Spot instances offer 70–90% discounts over on-demand pricing for fault-tolerant workloads, and the Spot market is far more mature and liquid than OCI's preemptible instances. If you're running large batch processing jobs that can tolerate interruption, AWS Spot pricing can undercut OCI significantly.

Developer Tooling and Community Size

AWS has a larger developer community, more third-party integrations, more StackOverflow answers, and more readily available talent. For new projects where you're not running Oracle workloads and where team expertise matters, AWS's ecosystem advantage is real.

⚠️  The Real Question to Ask

The right question isn't 'which cloud is cheaper' globally — it's 'which cloud is cheaper for MY workload profile'. OCI wins decisively for Oracle database workloads, egress-heavy architectures, and compute at scale. AWS wins for non-Oracle ecosystems, small GPU inference, and teams deeply invested in AWS-native services. Most enterprise Oracle shops should be running OCI for their database tier and potentially keeping other services on AWS — that's what Oracle@AWS and the multicloud agreements are designed for.

Quick Reference: OCI vs AWS Pricing Cheat Sheet

Conclusion: Run the Numbers for Your Workload

The headline finding is clear: for Oracle database workloads, OCI delivers approximately 65% lower total cost of ownership than equivalent AWS deployments once you account for compute, storage, egress, licensing, and support costs together.

The key insight most teams miss is that cost comparisons that only look at compute rates are systematically misleading. Data egress costs alone can eclipse compute costs for analytics-heavy Oracle environments. Oracle licensing multipliers can double your licensing spend on AWS vs OCI for identical performance. Enterprise support that's free on OCI costs thousands per month on AWS.

Use the TCO script from Section 4 to run your own numbers. Plug in your actual OCPU counts, storage sizes, and egress volumes. The delta will almost certainly be larger than you expect.

The next post in this series will look at OCI Object Storage vs S3 vs Azure Blob in depth — including lifecycle policies, multipart upload performance benchmarks, and a real cost comparison for a data lake workload pushing 500TB/month.

Disclaimer & Safe Harbour Statement 

The pricing figures, cost estimates, and comparisons presented in this article are based on publicly available list prices from Oracle Cloud Infrastructure (OCI) and Amazon Web Services (AWS) pricing pages as of Q1 2026. Cloud pricing is subject to change without notice, and actual costs will vary based on your specific configuration, reserved pricing agreements, enterprise discount programmes, committed use contracts, region selection, and usage patterns. This content is provided for informational and educational purposes only. Nothing in this article constitutes financial, procurement, or architectural advice. Readers should conduct their own due diligence and consult directly with Oracle and AWS representatives to obtain pricing tailored to their workloads before making purchasing or migration decisions. 

Safe Harbour — Forward-Looking Statements

Certain statements in this article regarding future product availability, pricing structures, service levels, or vendor roadmaps may constitute forward-looking statements. These are based on current public information and reasonable assumptions. Actual outcomes may differ materially from any expectations expressed or implied here. cloudexplorers.club assumes no obligation to update such statements. 

No Affiliation:**

 cloudexplorers.club is an independent technical blog. The author is not employed by, sponsored by, or affiliated with Oracle, Amazon Web Services, or any other vendor mentioned. No compensation was received for the views expressed in this article. All product names, logos, and trademarks are the property of their respective owners. Accuracy: While every effort has been made to ensure the accuracy of technical information, the author makes no warranties, express or implied, about the completeness, accuracy, or fitness for a particular purpose of the content. Use of any information in this article is at your own risk.

© 2026 cloudexplorers.club — Content published under Creative Commons Attribution 4.0 International (CC BY 4.0). You are free to share and adapt with attribution

If you've been clicking around the OCI Console to create VMs, networks, and databases — you're not alone. Most people start that way. But once you need to repeat that setup for a second environment, hand it off to a colleague, or recover from an accidental deletion, you quickly realize: clicking through a UI is not infrastructure management. It's infrastructure guessing.

That's where Terraform comes in. Terraform is an Infrastructure as Code (IaC) tool that lets you describe your cloud infrastructure in simple text files, then apply, change, or destroy it in a repeatable, auditable way. On Oracle Cloud Infrastructure, Terraform is a first-class citizen — Oracle maintains the official OCI provider, and the latest version (6.x) supports virtually every OCI service.

This guide is for complete beginners. We'll start from zero — what Terraform is, how it thinks, how to connect it to OCI — and build up to a real working example: a fully functional VCN with subnets, an Internet Gateway, and a Compute instance you can SSH into. Every line of code is explained.

🎯  What You'll Build By the End

A working OCI environment built entirely with Terraform: VCN + Public subnet + Internet Gateway + Route Table + Security list + Ubuntu compute instance with SSH access. Everything destroyed with one command when you're done.

Section 1: What Is Terraform and How Does It Work?

Terraform, built by HashiCorp, is an open-source IaC tool that uses a declarative approach to infrastructure management. That means you tell Terraform what you want — not how to build it. You write configuration files in HashiCorp Configuration Language (HCL), and Terraform figures out the sequence of API calls needed to make reality match your description.

The Terraform Workflow: Plan, Apply, Destroy

Terraform operates in a simple three-command loop that you'll use constantly:

Terraform State: The Source of Truth

Terraform maintains a state file (terraform.tfstate) that maps your configuration to real OCI resources. This is how Terraform knows what already exists and what needs to change. By default it's a local file, but for team environments you should store it remotely — OCI Object Storage works perfectly for this.

⚠️  Never Manually Edit the State File

The terraform.tfstate file is Terraform's internal database. Editing it manually corrupts it. If you need to modify state, use 'terraform state' subcommands. Also — add terraform.tfstate to your .gitignore, as it can contain sensitive values.

Key Terraform Concepts at a Glance

•      Provider — A plugin that enables Terraform to talk to a specific platform (in our case, oracle/oci)

•      Resource — A cloud object to create (e.g. oci_core_vcn, oci_core_instance)

•      Data Source — Read-only query for existing OCI data (e.g. get all availability domains)

•      Variable — Parameterize your config so it's reusable across environments

•      Output — Print useful values after apply (e.g. the new instance's public IP)

•      Module — A reusable group of resources, like a blueprint for a network pattern

Section 2: Installing Terraform and Connecting to OCI

Step 1: Install Terraform

Terraform is a single binary — no dependencies. Install the latest version for your OS:

Verify the installation:

terraform -version # Expected output: Terraform v1.9.x (or higher)

Step 2: Set Up OCI API Key Authentication

Terraform authenticates to OCI using an API key pair. You'll create an RSA key, upload the public key to OCI, and configure a local credentials file. This is a one-time setup.

1.     Log into the OCI Console

2.     Click your profile icon (top-right) → My Profile

3.     Scroll to API Keys → Add API Key → Generate API Key Pair

4.     Download the Private Key (.pem file) → click Add

5.     Copy the configuration snippet shown — you'll need these values

Create the OCI credentials file:

mkdir -p ~/.oci

# Move your downloaded private key:

mv ~/Downloads/your-key.pem ~/.oci/oci_api_key.pem

chmod 400 ~/.oci/oci_api_key.pem

# Create the config file:

vi ~/.oci/config

Paste the following into ~/.oci/config (use the values from the OCI console snippet):

[DEFAULT]

user=ocid1.user.oc1..aaaaaaaaxxx          # Your User OCID

tenancy=ocid1.tenancy.oc1..aaaaaaaaxxx    # Your Tenancy OCID

region=ap-mumbai-1                         # Your home region

fingerprint=aa:bb:cc:dd:...               # Key fingerprint from OCI console

key_file=~/.oci/oci_api_key.pem          # Path to your private key

💡  Finding Your OCIDs

Tenancy OCID: OCI Console → top-right profile → Tenancy. User OCID: Profile → My Profile. Compartment OCID: Identity & Security → Compartments → click your compartment. OCIDs start with 'ocid1.' and are long strings — copy them carefully.

Step 3: Verify the OCI CLI Connection

Before writing any Terraform, confirm your credentials work:

# Install OCI CLI if not already installed:

pip install oci-cli --break-system-packages

# Test authentication:

oci iam region list --output table

# Should list all OCI regions — if it does, credentials are working

Section 3: Your First Terraform Project — File Structure

Good Terraform projects split configuration across multiple files by concern. Here's the recommended structure for a beginner OCI project:

oci-terraform-demo/

├── provider.tf       # OCI provider configuration and authentication

├── variables.tf      # Input variable declarations

├── terraform.tfvars  # Variable values (DO NOT commit to Git)

├── main.tf           # Core resources: VCN, subnets, gateways

├── compute.tf        # Compute instance resources

└── outputs.tf       # Output values to display after apply

Create the project directory and open it:

provider.tf — Connecting Terraform to OCI

This file tells Terraform which provider to use and how to authenticate. Create provider.tf with the following content:

terraform {

  required_providers {

    oci = {

      source  = "oracle/oci"

      version = ">= 6.0.0"    # Always pin a minimum version

    }

  }

  required_version = ">= 1.9.0"

}

provider "oci" {

  tenancy_ocid     = var.tenancy_ocid

  user_ocid        = var.user_ocid

  fingerprint      = var.fingerprint

  private_key_path = var.private_key_path

  region           = var.region

}

🔒  Never Hardcode Credentials

Notice we use variables (var.tenancy_ocid) instead of pasting OCIDs directly. The actual values go in terraform.tfvars which you add to .gitignore. This prevents accidental credential exposure when pushing to GitHub.

variables.tf — Declaring Input Variables

Declare all variables your configuration needs. This file is safe to commit — it contains no values, just declarations:

# Authentication variables

variable "tenancy_ocid" {

  description = "OCID of your OCI tenancy"

  type        = string

}

variable "user_ocid" {

  description = "OCID of the OCI user for API authentication"

  type        = string

}

variable "fingerprint" {

  description = "Fingerprint of the API key"

  type        = string

}

variable "private_key_path" {

  description = "Local path to the OCI API private key (.pem)"

  type        = string

  default     = "~/.oci/oci_api_key.pem"

}

variable "region" {

  description = "OCI region identifier"

  type        = string

  default     = "ap-mumbai-1"

}

# Infrastructure variables

variable "compartment_ocid" {

  description = "OCID of the compartment to create resources in"

  type        = string

}

 variable "ssh_public_key" {

  description = "SSH public key to inject into the compute instance"

  type        = string

}

terraform.tfvars — Your Actual Values (Keep Private)

This file holds the real values for your variables. Add it to .gitignore immediately:

# terraform.tfvars — DO NOT COMMIT TO GIT

tenancy_ocid      = "ocid1.tenancy.oc1..aaaaaaaaxxxxxxxxxxx"

user_ocid         = "ocid1.user.oc1..aaaaaaaaxxxxxxxxxxx"

fingerprint       = "aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88:99"

private_key_path  = "/home/yourname/.oci/oci_api_key.pem"

region            = "ap-mumbai-1"

compartment_ocid  = "ocid1.compartment.oc1..aaaaaaaaxxxxxxxxxxx"

ssh_public_key   = "ssh-rsa AAAAB3NzaC1yc2E... your-public-key"

Create your .gitignore immediately:

# .gitignore

terraform.tfvars

*.tfvars

.terraform/

terraform.tfstate

terraform.tfstate.backup

*.pem

Section 4: Real Example — Build a Full OCI Network with Terraform

Now the exciting part. We'll create a main.tf that provisions a complete, functional OCI network: a Virtual Cloud Network (VCN), a public subnet, an Internet Gateway, and the route table needed to make it all work.

Understanding What We're Building

In OCI, before you can launch a compute instance, you need this networking chain in place:

•      VCN → The top-level private network, like an AWS VPC

•      Subnet → A subdivision of the VCN where resources live

•      Internet Gateway → Allows traffic between the subnet and the public internet

•      Route Table → Rules that direct traffic; the subnet must have a route pointing to the IGW

•      Security List → Stateful firewall rules (like AWS Security Groups) at the subnet level

main.tf — VCN, Subnet, Internet Gateway, and Security

# ── DATA SOURCE: Get Availability Domains ──────────────────────────

# This queries OCI to find the names of availability domains in your region.

# We use it to deploy the subnet into a specific AD.

data "oci_identity_availability_domains" "ads" {

  compartment_id = var.tenancy_ocid

}

# ── VIRTUAL CLOUD NETWORK (VCN) ─────────────────────────────────────

resource "oci_core_vcn" "main_vcn" {

  compartment_id = var.compartment_ocid

  cidr_block     = "10.0.0.0/16"

  display_name   = "terraform-demo-vcn"

  dns_label      = "tfdemov cn"   # Must be alphanumeric, max 15 chars

  freeform_tags = {

    "Project"     = "terraform-demo"

    "ManagedBy"   = "terraform"

    "Environment" = "learning"

  }

}

# ── INTERNET GATEWAY ─────────────────────────────────────────────────

# Required for instances in the public subnet to reach the internet.

resource "oci_core_internet_gateway" "igw" {

  compartment_id = var.compartment_ocid

  vcn_id         = oci_core_vcn.main_vcn.id   # Reference the VCN we just defined

  display_name   = "terraform-demo-igw"

  enabled        = true

}

# ── ROUTE TABLE ──────────────────────────────────────────────────────

# Directs all outbound internet traffic (0.0.0.0/0) through the IGW.

resource "oci_core_route_table" "public_rt" {

  compartment_id = var.compartment_ocid

  vcn_id         = oci_core_vcn.main_vcn.id

  display_name   = "public-route-table"

  route_rules {

    destination       = "0.0.0.0/0"           # All internet traffic

    network_entity_id = oci_core_internet_gateway.igw.id

  }

}

# ── SECURITY LIST ─────────────────────────────────────────────────────

# Defines firewall rules: allow SSH in, allow all traffic out.

resource "oci_core_security_list" "public_sl" {

  compartment_id = var.compartment_ocid

  vcn_id         = oci_core_vcn.main_vcn.id

  display_name   = "public-security-list"

  # Inbound: Allow SSH from anywhere

  ingress_security_rules {

    protocol  = "6"         # 6 = TCP

    source    = "0.0.0.0/0"

    stateless = false

    tcp_options {

      min = 22

      max = 22

    }

    description = "Allow SSH access"

  }

  # Inbound: Allow ICMP (ping)

  ingress_security_rules {

    protocol  = "1"         # 1 = ICMP

    source    = "0.0.0.0/0"

    stateless = false

  }

  # Outbound: Allow all traffic out

  egress_security_rules {

    protocol    = "all"

    destination = "0.0.0.0/0"

    stateless   = false

  }

}

# ── PUBLIC SUBNET ─────────────────────────────────────────────────────

resource "oci_core_subnet" "public_subnet" {

  compartment_id    = var.compartment_ocid

  vcn_id            = oci_core_vcn.main_vcn.id

  cidr_block        = "10.0.1.0/24"

  display_name      = "public-subnet"

  dns_label         = "public"

  # Attach the route table and security list we created above

  route_table_id    = oci_core_route_table.public_rt.id

  security_list_ids = [oci_core_security_list.public_sl.id]

  # false = allow public IPs on instances in this subnet

  prohibit_public_ip_on_vnic = false

}

Section 5: Adding a Compute Instance (compute.tf)

Now let's add a compute instance to the public subnet. Create compute.tf:

# ── LOOKUP: Find the Ubuntu 22.04 Image OCID ─────────────────────────

# OCI image OCIDs are region-specific. This data source finds the latest

# Ubuntu 22.04 image automatically — no hardcoding needed.

data "oci_core_images" "ubuntu_22" {

  compartment_id           = var.compartment_ocid

  operating_system         = "Canonical Ubuntu"

  operating_system_version = "22.04"

  shape                    = "VM.Standard.A1.Flex"   # ARM shape

  sort_by                  = "TIMECREATED"

  sort_order               = "DESC"

}

# ── COMPUTE INSTANCE ─────────────────────────────────────────────────

resource "oci_core_instance" "web_server" {

  availability_domain = data.oci_identity_availability_domains.ads.availability_domains[0].name

  compartment_id      = var.compartment_ocid

  display_name        = "terraform-demo-server"

  # Shape: ARM Always Free tier — 1 OCPU, 6GB RAM

  shape = "VM.Standard.A1.Flex"

  shape_config {

    ocpus         = 1

    memory_in_gbs = 6

  }

  # OS Image: Use the latest Ubuntu 22.04 found above

  source_details {

    source_type             = "image"

    source_id               = data.oci_core_images.ubuntu_22.images[0].id

    boot_volume_size_in_gbs = 50

  }

  # Network: Place in the public subnet we created

  create_vnic_details {

    subnet_id        = oci_core_subnet.public_subnet.id

    assign_public_ip = true    # Give this instance a public IP

    display_name     = "primary-vnic"

  }

  # SSH: Inject your public key so you can log in

  metadata = {

    ssh_authorized_keys = var.ssh_public_key

  }

  freeform_tags = {

    "ManagedBy"   = "terraform"

    "Environment" = "learning"

  }

}

outputs.tf — See Your Results

Create outputs.tf to display useful information after applying:

output "vcn_id" {

  description = "OCID of the created VCN"

  value       = oci_core_vcn.main_vcn.id

}

output "subnet_id" {

  description = "OCID of the public subnet"

  value       = oci_core_subnet.public_subnet.id

}

output "instance_public_ip" {

  description = "Public IP address of the compute instance"

  value       = oci_core_instance.web_server.public_ip

}

output "ssh_command" {

  description = "Ready-to-run SSH command to connect to your instance"

  value       = "ssh -i ~/.ssh/id_rsa ubuntu@${oci_core_instance.web_server.public_ip}"

}

Section 6: Running Terraform — Init, Plan, Apply

terraform init

Initialize the project. This downloads the OCI provider plugin (~200MB) and sets up the working directory:

terraform init

# Expected output:

# Initializing the backend...

# Initializing provider plugins...

# - Finding oracle/oci versions matching ">= 6.0.0"...

# - Installing oracle/oci v6.x.x...

# Terraform has been successfully initialized!

terraform plan

Preview exactly what Terraform will create — nothing is changed in OCI yet:

terraform plan

# You'll see output like:

# Terraform will perform the following actions:

#

#   + resource "oci_core_vcn" "main_vcn" will be created

#   + resource "oci_core_internet_gateway" "igw" will be created

#   + resource "oci_core_route_table" "public_rt" will be created

#   + resource "oci_core_security_list" "public_sl" will be created

#   + resource "oci_core_subnet" "public_subnet" will be created

#   + resource "oci_core_instance" "web_server" will be created

#

# Plan: 6 to add, 0 to change, 0 to destroy.

💡  Always Review the Plan

The plan output is your change log before deployment. Read it carefully — especially lines starting with '-' (destroy) or '~' (modify in place). A '+' means create. Getting comfortable reading plans is the single most important Terraform habit.

terraform apply

Apply the plan to create your real OCI resources. Terraform will pause and ask for confirmation:

terraform apply

# Terraform will show the plan again, then prompt:

# Do you want to perform these actions?

#   Terraform will perform the actions described above.

#   Only 'yes' will be accepted to approve.

#

# Enter a value: yes

# ... Terraform creates resources, then shows outputs:

# Outputs:

# instance_public_ip = "130.61.xxx.xxx"

# ssh_command = "ssh -i ~/.ssh/id_rsa ubuntu@130.61.xxx.xxx"

# subnet_id = "ocid1.subnet.oc1..."

# vcn_id = "ocid1.vcn.oc1..."

Copy the ssh_command output and connect to your new instance:

ssh -i ~/.ssh/id_rsa ubuntu@130.61.xxx.xxx

# You should be logged in to your brand new OCI VM!

# ubuntu@terraform-demo-server:~$

Section 7: Terraform Lifecycle — Modify and Destroy

Making Changes

Terraform's real power is in how it handles changes. Edit your configuration — for example, add port 80 to the security list — then re-run terraform plan. Terraform shows exactly what will change, and terraform apply makes it so. No manual clicking, no forgetting a step.

# Add this inside the security list resource in main.tf:

  ingress_security_rules {

    protocol  = "6"

    source    = "0.0.0.0/0"

    stateless = false

    tcp_options { min = 80; max = 80 }

    description = "Allow HTTP access"

  }

# Then:

terraform plan    # Shows: 1 to change

terraform apply  # Updates the security list in place

Destroying Everything

When you're done experimenting, destroy all resources with a single command. This is one of Terraform's most powerful features — clean teardown with no orphaned resources:

terraform destroy

# Terraform shows everything it will delete, then prompts:

# Enter a value: yes

# All 6 resources are deleted cleanly.

# Destroy complete! Resources: 6 destroyed.

⚠️  Destroy is Irreversible

terraform destroy permanently deletes real OCI resources including any data on them. Always review the destroy plan carefully. For production environments, consider using Terraform's prevent_destroy lifecycle argument on critical resources to add a safety net.

Section 8: Best Practices for Terraform on OCI

Bonus: Storing Terraform State in OCI Object Storage

For any serious usage — especially if you're working with a team or in a CI/CD pipeline — move your state file to OCI Object Storage. This prevents state file conflicts and ensures everyone works from the same source of truth.

# First, create an OCI bucket manually (or via Terraform in a separate root module)

# Then update provider.tf to add a backend block:

terraform {

  required_providers {

    oci = { source = "oracle/oci", version = ">= 6.0.0" }

  }

  backend "http" {

    # OCI Object Storage pre-authenticated request URL for state

    address        = "https://objectstorage.ap-mumbai-1.oraclecloud.com/..."

    update_method  = "PUT"

  }

}

# After updating the backend, re-initialize to migrate local state:

terraform init -migrate-state

Quick Reference: Common OCI Terraform Resources

Safe Harbour: This site may contain forward-looking statements regarding cloud architectures, infrastructure strategies, product roadmaps, performance benchmarks, or emerging technologies that are subject to change without notice. Actual results may vary due to technical, operational, or market factors. All content is provided for informational and educational purposes only and does not constitute professional, legal, financial, or investment advice. We undertake no obligation to update such statements.