Oracle Cloud Compute Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Compute

1. Introduction

Oracle Cloud Compute is the Oracle Cloud Infrastructure (OCI) service for running virtual machines (VMs) and bare metal servers in the cloud. It provides on-demand compute capacity, operating system images, networking attachments, and lifecycle controls so you can host applications without owning physical hardware.

In simple terms: Compute lets you create and manage servers (Linux or Windows) in Oracle Cloud, connect them to your network (VCN/subnets), secure them (security lists/NSGs/IAM), and scale them (instance pools/autoscaling) as your workload changes.

Technically, Compute is a regional OCI service that provisions instances into Availability Domains (ADs) (where available) and Fault Domains. Instances are built from images (Oracle-provided, Marketplace, or custom), run on specific shapes (fixed or flexible OCPU/memory), attach to block volumes and VNICs, integrate with IAM policies/compartments, and emit metrics/logs to OCI observability services.

What problem it solves: it gives teams a consistent way to deploy and operate compute capacity for web apps, APIs, batch jobs, CI/CD runners, enterprise middleware, and lift-and-shift workloads—while controlling cost, security, and reliability through OCI-native tooling.

Naming note: The service is currently named Compute in Oracle Cloud (OCI). The most common resource you create in Compute is an instance (VM or bare metal). This tutorial uses the official OCI terminology and keeps Compute as the primary service name throughout.

2. What is Compute?

Official purpose (service scope): Oracle Cloud Compute provides on-demand compute instances (VM and bare metal) that you can deploy, manage, resize, and integrate with OCI networking, storage, and security services.

Core capabilities

Provision VM instances and bare metal instances
Choose shapes (fixed or flexible OCPU/memory) including GPU and HPC-oriented options (availability depends on region)
Boot instances from platform images, custom images, or Marketplace images
Attach VNICs (network interfaces), assign private/public IPs, and control traffic with security lists and network security groups (NSGs)
Attach storage such as boot volumes and block volumes
Manage lifecycle: start/stop/reboot/terminate, console access, metadata, and recovery options (where applicable)
Scale out with Instance Configurations, Instance Pools, and Autoscaling
Improve placement and capacity predictability using constructs like Fault Domains and (where available) Capacity Reservations (verify availability in your region and tenancy)

Major components (you will see these in Console/CLI/API)

Instances: the running servers
Shapes: the compute resource templates (OCPU/memory/networking limits)
Images: platform images, custom images, and Marketplace images
Boot volumes / block volumes: persistent storage attached to instances
VNICs: networking attachments into subnets
Instance Console Connections: out-of-band access methods (for troubleshooting when SSH/RDP is unavailable; verify exact options per OS/image)
Instance Configurations & Instance Pools: templates and groups for repeatable deployment and scaling
Autoscaling: rules to add/remove instances in a pool based on metrics
Dedicated VM Hosts (if enabled/available): host-level isolation for certain compliance/licensing scenarios (verify current support)

Service type and scope

Service type: IaaS compute (VMs and bare metal)
Scope:
Tenancy-wide governance via IAM and compartments
Regional resource control (instances, images, volumes are created in a region)
AD / Fault Domain placement for resilience (ADs vary by region)

How Compute fits into the Oracle Cloud ecosystem

Compute is usually deployed alongside: – Networking: Virtual Cloud Network (VCN), subnets, route tables, Internet Gateway, NAT Gateway, Service Gateway, Bastion – Storage: Block Volume, Object Storage, File Storage (depending on workload) – Load balancing & edge: Load Balancer, Web Application Firewall (WAF), DNS – Observability: Monitoring, Logging, Events, Notifications – Security & governance: IAM, Vault (keys/secrets), Cloud Guard, Security Zones (where adopted) – Platform services: Autonomous Database, OCI Database, OKE (Kubernetes), Functions (serverless)

3. Why use Compute?

Business reasons

Faster time to deploy: provision servers in minutes instead of weeks.
Cost control: pay for what you run; stop/resize resources when not needed.
Global reach: deploy in OCI regions close to users or compliance boundaries.

Technical reasons

Broad workload compatibility: VMs and bare metal support many OS/app stacks, including legacy applications.
Flexible sizing: flexible shapes let you choose OCPU and memory (shape-dependent).
Performance options: bare metal, high network bandwidth shapes, and (region-dependent) GPU/HPC shapes.

Operational reasons

Automation-friendly: provision with Console, OCI CLI, SDKs, Terraform, or Resource Manager.
Repeatable deployments: instance configurations/pools support standardized rollouts.
Observability integration: metrics, logs, alarms, and events integrate with OCI services.

Security/compliance reasons

Strong isolation controls: compartment-based IAM policies, VCN isolation, NSGs.
Encryption options: boot/block volumes support encryption (Oracle-managed keys by default; customer-managed keys via Vault where used).
Auditability: OCI Audit logs API calls; Cloud Guard and security posture tooling can help detect misconfigurations.

Scalability/performance reasons

Scale-out patterns: instance pools + autoscaling for stateless tiers.
Placement strategy: AD and fault domain distribution for high availability.
Hybrid patterns: connect to on-prem via VPN or FastConnect.

When teams should choose Compute

Choose Compute when you need: – OS-level control (packages, kernel modules, custom agents) – Lift-and-shift migration of existing apps – Predictable runtime environments for enterprise software – Specialized performance profiles (bare metal, GPU, high bandwidth) – A stepping-stone to containers (host your own Kubernetes nodes or app servers)

When teams should not choose it

Consider alternatives when: – You want fully managed runtime with minimal server management (consider Functions, OKE, managed PaaS options). – Your workload is purely event-driven and sporadic (serverless may be cheaper/easier). – You need managed application hosting with opinionated workflows (PaaS can reduce ops overhead). – You require a managed database (use OCI database services rather than self-managed DB on Compute, unless you have a reason).

4. Where is Compute used?

Industries

Financial services (risk engines, secure middleware tiers)
Healthcare (HIPAA-like controls depend on your program; verify compliance offerings)
Retail/e-commerce (web/API tiers, batch jobs)
Manufacturing and IoT backends (ingestion services, analytics workers)
SaaS providers (multi-tenant application servers)
Education and research (HPC-like workloads; availability varies by region)

Team types

DevOps/SRE platform teams building standardized compute “landing zones”
Application teams needing VM-based deployments
Security teams enforcing network segmentation and least privilege
Data engineering teams running batch processing on VMs
IT operations teams migrating legacy systems

Workloads

Web servers (Nginx/Apache), application servers (Java/.NET), API gateways
CI/CD runners and build agents
Self-managed middleware (Kafka, RabbitMQ—if you accept the operational burden)
Self-managed databases (when required)
Background workers, cron jobs, ETL tasks
Bastion/jump host patterns (often replaced by OCI Bastion)

Architectures and deployment contexts

Single-instance dev/test environments
Highly available web tier behind Load Balancer with instance pools
Hybrid app tiers connected to on-prem networks
Blue/green deployments using instance pools and multiple backends

Production typically emphasizes: – private subnets, minimal public IP usage – automated scaling and patching strategy – monitoring/alerting and controlled change management

Dev/test typically emphasizes: – small shapes, Always Free-eligible (if available) – shorter instance lifetimes with automation – lower-cost storage and simplified networking (while still secure)

5. Top Use Cases and Scenarios

Below are realistic scenarios where Oracle Cloud Compute is a good fit.

1) Public web server (Nginx/Apache)

Problem: Host a basic website or reverse proxy.
Why Compute fits: Simple VM provisioning and full control of OS/packages.
Example: A marketing site deployed to a VM in a public subnet with HTTPS termination at a Load Balancer.

2) API application tier behind a load balancer

Problem: Scale stateless APIs with predictable performance.
Why Compute fits: Instance pools + autoscaling + Load Balancer integration.
Example: Two or more VMs across fault domains behind OCI Load Balancer, scaling on CPU utilization.

3) Legacy app lift-and-shift

Problem: Move an on-prem app that requires a specific OS and configuration.
Why Compute fits: VM images, custom images, and full OS control.
Example: A Windows-based line-of-business app migrated to a VM with attached block storage.

4) Secure administrative jump host (or Bastion alternative)

Problem: Securely reach private instances without exposing them to the internet.
Why Compute fits: You can run a hardened SSH jump host (though OCI Bastion is often preferred).
Example: A jump VM in a public subnet with strict NSGs, used to access private subnets.

5) CI/CD build agents and runners

Problem: Build workloads need isolated, scalable executors.
Why Compute fits: Ephemeral instances can be created on demand via automation.
Example: A pipeline spins up a VM runner, builds artifacts, pushes to Object Storage, then terminates.

6) Batch processing / scheduled jobs

Problem: Run CPU/memory-heavy tasks periodically.
Why Compute fits: Start/stop scheduling and flexible shapes (shape-dependent).
Example: Nightly report generation on a VM that runs for 2 hours, then shuts down.

7) Self-managed middleware

Problem: Need custom configs for message brokers or caches.
Why Compute fits: OS-level tuning and persistent volumes.
Example: A RabbitMQ cluster on VMs with block volumes for durable queues (with careful HA design).

8) GPU-backed inference server (region-dependent)

Problem: Serve ML inference with GPUs.
Why Compute fits: GPU shapes (availability varies), VCN isolation, and scaling with pools.
Example: A model inference API running on GPU VMs behind a Load Balancer.

9) High-performance computing node (region-dependent)

Problem: Run tightly coupled compute jobs or high-throughput workloads.
Why Compute fits: Bare metal/HPC-oriented shapes and high bandwidth networking (shape/region dependent).
Example: A compute farm running simulations, writing outputs to Object Storage.

10) Secure file processing and transformation

Problem: Process documents/media in a controlled environment.
Why Compute fits: Combine private networking with Object Storage access via Service Gateway.
Example: A private VM pulls files from Object Storage, transforms them, pushes results back—without public internet.

11) Development environments and sandboxes

Problem: Provide developers a reproducible environment close to production.
Why Compute fits: Standard images, cloud-init bootstrap, and IAM-controlled access.
Example: Per-developer VMs created from an instance configuration, with tagging for cost tracking.

12) Vendor software that requires BYOL or host-level controls

Problem: Some enterprise software requires licensing models or host isolation.
Why Compute fits: Bare metal or dedicated host options (verify support) and OS control.
Example: Commercial security scanning appliance deployed on a VM with multiple VNICs.

6. Core Features

This section focuses on commonly used, current features of Oracle Cloud Compute. Availability can vary by region, shape, and tenancy configuration—verify in official docs for your region.

Instances (VM and bare metal)

What it does: Runs your OS and applications on OCI infrastructure.
Why it matters: Core building block for IaaS workloads.
Practical benefit: Full control over OS, packages, runtime, and agents.
Caveats: You are responsible for OS-level patching, hardening, and availability design.

Shapes (fixed and flexible)

What it does: Defines CPU (OCPUs), memory, and networking limits.
Why it matters: Right-sizing is the biggest driver of cost and performance.
Practical benefit: Flexible shapes allow tuning OCPUs/memory for workload needs (where supported).
Caveats: Not all shapes are available in all regions; some shapes have minimum/maximum OCPU/memory constraints.

Images (platform, custom, and Marketplace)

What it does: Source template for instance boot disk.
Why it matters: Determines OS, patch level baseline, and baked-in software.
Practical benefit: Use custom images to standardize golden builds across environments.
Caveats: You must update and govern custom images; Marketplace images may have licensing terms and costs.

Boot volumes and block volumes

What it does: Persistent storage for OS (boot) and data (block) attached to instances.
Why it matters: Instance local storage is not a substitute for durable storage.
Practical benefit: Resize volumes, take backups, and (depending on features) clone/restore to speed deployments.
Caveats: Storage costs can exceed compute costs if over-provisioned; performance depends on volume type and tuning.

Networking: VNICs, subnets, private/public IPs

What it does: Connects instances to your VCN and controls reachability.
Why it matters: Most security posture is implemented at network boundaries.
Practical benefit: Place instances in private subnets and expose only controlled entry points (Load Balancer, Bastion).
Caveats: Misconfigured security lists/NSGs and route tables are common causes of “can’t connect” issues.

Security Lists and Network Security Groups (NSGs)

What it does: Stateful virtual firewall rules for instance traffic.
Why it matters: Enforces least privilege network access.
Practical benefit: NSGs can be more granular and easier to manage than subnet-wide security lists for large environments.
Caveats: Rule ordering isn’t a “deny-first” model; ensure you understand stateful behavior and route requirements.

Instance metadata and cloud-init bootstrapping

What it does: Provides instance-specific configuration and startup automation.
Why it matters: Enables repeatable configuration without manual SSH steps.
Practical benefit: Install packages, fetch config from Object Storage, register to monitoring—all at first boot.
Caveats: Misconfigured cloud-init can break first boot; keep scripts idempotent and log outputs.

Console access (Instance Console Connection)

What it does: Out-of-band access for troubleshooting when network access fails.
Why it matters: Helps recover from firewall mistakes, broken SSH config, or bad routing.
Practical benefit: Diagnose boot and networking issues without public access.
Caveats: Exact console connection options and prerequisites vary—verify in docs for your OS/image.

Instance Pools and Instance Configurations

What it does: Creates a template (configuration) and a managed group (pool) of identical instances.
Why it matters: Standard pattern for stateless tiers and scalable services.
Practical benefit: Replace unhealthy instances, scale out/in, and roll out changes more predictably.
Caveats: Pools work best for stateless workloads; stateful services need additional design.

Autoscaling

What it does: Automatically adjusts pool size based on metrics (for example CPU utilization).
Why it matters: Handles load spikes while controlling cost during low usage.
Practical benefit: Operational automation; fewer manual interventions.
Caveats: Scaling policies must be tuned to avoid thrash; ensure apps start quickly and are load balancer-ready.

Fault Domains and Availability Domains

What it does: Placement constructs to reduce correlated failures.
Why it matters: Availability requires distributing instances.
Practical benefit: Run multiple instances across fault domains and/or ADs.
Caveats: Some regions are single-AD; you still should use fault domains and consider multi-region DR for critical systems.

Capacity planning controls (region/shape dependent)

What it does: Helps reserve or predict capacity for specific shapes (where offered).
Why it matters: Avoids launch failures during capacity constraints.
Practical benefit: Better reliability for planned deployments.
Caveats: Not universally available; check OCI docs and your account limits.

7. Architecture and How It Works

High-level architecture

At a high level, Oracle Cloud Compute sits behind the OCI control plane: – You request instance creation via Console, CLI, SDK, Terraform, or API. – OCI provisions capacity in the selected region, AD, and subnet. – The instance boots from an image onto a boot volume, attaches VNICs, and becomes reachable depending on routes and security rules. – The instance emits metrics to Monitoring and can send logs to Logging (with agents/config). – IAM policies govern who can create/manage instances and associated networking/storage.

Request/control flow (typical “create instance”)

User/automation authenticates to OCI using IAM (user, instance principal, workload identity—depending on setup).
A “CreateInstance” call references: – compartment – subnet (and thus VCN) – shape – image – SSH keys
OCI provisions compute capacity and attaches networking and storage.
Instance boots; cloud-init runs if provided.
You verify access (SSH/RDP), then deploy application.

Common integrations

VCN for networking
Block Volume for persistent disk
Object Storage for artifacts, backups, and images
Load Balancer to expose services
Bastion for private access patterns
Vault for encryption keys/secrets (customer-managed keys, secret retrieval patterns)
Monitoring/Logging/Events/Notifications for observability and automation
Resource Manager (Terraform) for infrastructure-as-code

Dependency services (practically required)

IAM (tenancy, users, groups, policies, compartments)
Networking (VCN, subnet, routing)
Storage (boot volume is created/used implicitly; block volumes optional)

Security/authentication model

Identity is managed by OCI IAM.
Authorization uses policy statements scoped to compartments.
Compute instances can authenticate to OCI APIs using instance principals (via dynamic groups + policies), reducing the need to store API keys on instances (recommended for automation).

Networking model (important for real deployments)

Instances attach to a subnet in a VCN.
Public reachability depends on:
instance has a public IP (or is behind a public Load Balancer)
subnet route table routes 0.0.0.0/0 to an Internet Gateway
security rules allow ingress (SSH/HTTP/etc.)
Private-only instances can reach OCI public services privately via Service Gateway (for supported services) or use NAT Gateway for general outbound internet without inbound exposure.

Monitoring/logging/governance considerations

Monitoring: OCI provides instance and VNIC-related metrics; you can add OS/application metrics using agents.
Logging: use OCI Logging with agents or application-native log forwarding; store and search centrally.
Audit: OCI Audit records control plane actions (create instance, modify subnet, etc.).
Governance: use compartments, tagging, quotas, and budgets to prevent sprawl.

Simple architecture diagram (single VM web server)

flowchart LR
  U[User Browser] -->|HTTPS| IGW[Internet Gateway]
  IGW --> VCN[VCN]
  VCN --> SUB[Public Subnet]
  SUB --> VM[Compute Instance\nNginx/Web App]
  VM --> BV[Boot/Block Volume]

Production-style architecture diagram (HA web tier + private app + DB)

flowchart TB
  U[Users] --> DNS[OCI DNS]
  DNS --> WAF[WAF (optional)]
  WAF --> LB[OCI Load Balancer\nPublic Subnet]

  subgraph VCN[VCN]
    subgraph PUB[Public Subnet]
      LB
      BAST[OCI Bastion or Jump Host\n(optional)]
    end

    subgraph PRIVAPP[Private Subnet - App Tier]
      POOL[Compute Instance Pool\n(Autoscaling)]
      POOL2[Compute Instance Pool\n(Autoscaling)]
    end

    subgraph PRIVDB[Private Subnet - Data Tier]
      DB[(Database Service or\nSelf-managed DB on Compute)]
    end

    LB --> POOL
    LB --> POOL2
    POOL --> DB
    POOL2 --> DB
  end

  POOL --> OBS[Object Storage\n(via Service Gateway)]
  POOL2 --> MON[Monitoring/Logging]

8. Prerequisites

Before you start using Oracle Cloud Compute, confirm the following.

Account/tenancy requirements

An active Oracle Cloud (OCI) tenancy
Access to a compartment where you can create:
compute instances
networking resources (VCN/subnet/IGW/route tables/security lists or NSGs)
storage (boot volumes are implicit; block volumes optional)

Permissions / IAM policies

You need permissions to manage compute and the required networking resources. Exact policy depends on your org model. Common patterns:

For admins in a compartment (broad example; adjust to least privilege):
Manage instances
Manage VCN/subnet/network security groups
Manage volumes

OCI IAM policy syntax varies by scope; use official docs for exact statements: – IAM policies overview: https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/policies.htm
– Compute IAM policies: https://docs.oracle.com/en-us/iaas/Content/Compute/Concepts/computeoverview.htm (navigate to IAM/policies section)

Billing requirements

A billing-enabled tenancy is typically required, even if you plan to stay within Always Free resources (if applicable to your account and region). Always Free eligibility can vary—verify in official docs:
Free Tier overview: https://www.oracle.com/cloud/free/

Tools

OCI Console (web UI) for the tutorial
Optional but recommended:
OCI CLI: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
SSH client (OpenSSH on macOS/Linux; Windows Terminal/OpenSSH or PuTTY)
Terraform/Resource Manager for IaC (optional)

Region availability

Compute is available in OCI regions globally, but shapes and features vary by region. Always check shape availability in your chosen region.

Quotas/limits

OCI enforces service limits (instance counts, OCPU limits, etc.) per region/tenancy.
If you cannot launch an instance due to limits, request a limit increase (if applicable) or choose a smaller shape.

Prerequisite services

Networking: VCN + subnet + routing + security rules
SSH keys: for Linux instance access (or RDP credentials for Windows images, depending on image workflow)

9. Pricing / Cost

Oracle Cloud Compute pricing is usage-based and depends on what you run and how long it runs. Exact prices are region-specific and can change; do not rely on static numbers from third parties.

Official pricing sources

Compute pricing page (start here): https://www.oracle.com/cloud/compute/pricing/
OCI price list: https://www.oracle.com/cloud/price-list.html
OCI Cost Management and Budgets (for tracking/controls):
https://docs.oracle.com/en-us/iaas/Content/Billing/Concepts/billingoverview.htm

Pricing dimensions (how you get charged)

Common cost dimensions include: – Instance runtime (per hour/second depending on billing granularity; verify current billing unit in your region) – Shape type: – OCPU count and memory size (especially for flexible shapes) – GPU shapes (if used) often have separate pricing – Bare metal priced differently than VM – Boot volume and block volume: – capacity (GB-month) – performance tiers (if applicable) – backups (storage consumed by backups) – Networking: – outbound data transfer (internet egress) – Load Balancer usage (if used) – NAT Gateway or other networking services may have costs – Public IP and traffic patterns (primarily through data egress and related services)

Free Tier / Always Free considerations

Oracle Cloud has a Free Tier program, including Always Free resources in many tenancies/regions. The specific Always Free compute shapes/limits can change (for example, certain micro instances and/or Arm-based instances with a limited total OCPU/memory). Verify the current Always Free compute entitlements here: – https://www.oracle.com/cloud/free/

Primary cost drivers

Over-provisioned shapes (too many OCPUs or too much memory)
Always-on instances for dev/test that could be stopped outside business hours
Large boot/block volumes and retained backups
High internet egress (downloads, CDN-less architectures, cross-region traffic)
Load Balancer and other “supporting services” in production architectures

Hidden or indirect costs to watch

Block volume backups that accumulate over time
Golden image sprawl (custom images and copies across regions)
Log ingestion/storage if you centralize large volumes of logs
Cross-AD or cross-region traffic depending on architecture (verify OCI networking billing rules)

Network/data transfer implications

In many cloud environments, ingress is typically free and egress is billed, but you must confirm OCI’s current rules for:
internet egress
inter-region egress
service gateway traffic (often designed to avoid public egress for supported OCI services) Use the official price list for your region and specific services.

How to optimize cost (practical)

Right-size: start smaller, measure, then scale.
Use flex shapes when available to fine-tune OCPU/memory.
Use instance pools for stateless tiers so you can scale horizontally instead of oversizing one VM.
Stop or terminate non-production instances automatically (scheduling via automation).
Minimize public internet egress:
use Service Gateway to access supported OCI services privately
consider CDN patterns for public content (if applicable in OCI services you adopt)
Control storage:
set backup retention policies
delete unused block volumes and old boot volumes after instance termination (verify whether they’re retained)
Use tagging + budgets to detect sprawl early.

Example low-cost starter estimate (conceptual)

A low-cost starter environment usually includes: – 1 small VM instance (possibly Always Free-eligible, if your tenancy qualifies) – 1 boot volume (default size) – minimal outbound data transfer – no Load Balancer (direct SSH + HTTP testing)

Because exact rates vary by region and shape, calculate using the official pricing pages and validate in the OCI Console cost tools.

Example production cost considerations (what to model)

For a typical HA web/API tier: – Load Balancer (public) – 2–6 instances in an instance pool (autoscaling) – Block volumes (boot + possibly data) – NAT Gateway (private subnet outbound) – Logging/Monitoring retention – WAF (optional) – Backups and DR copy (if implemented)

Production cost is often dominated by: – steady-state instance runtime across multiple nodes – load balancer – storage and backup retention – egress volume

10. Step-by-Step Hands-On Tutorial

This lab builds a small, realistic deployment: a Linux Compute instance running Nginx, reachable over HTTP, with SSH access for administration. It is designed to be low-cost and compatible with Free Tier where possible—but you must verify Always Free eligibility and shape availability in your region.

Objective

Create the required network (VCN + public subnet + Internet Gateway + route rule).
Launch an Oracle Cloud Compute instance (Oracle Linux) with an SSH key.
Install and run Nginx.
Verify public access to the web server.
Clean up all resources to avoid ongoing charges.

Lab Overview

You will create: – 1 VCN with a public subnet – 1 Internet Gateway + route table update – Security rules to allow: – SSH (TCP/22) from your IP (recommended) – HTTP (TCP/80) from the internet for testing – 1 Compute instance with a public IP – Nginx installed via dnf (Oracle Linux)

If your organization requires private-only instances, use a private subnet + Bastion + Load Balancer. This lab intentionally uses a public subnet for beginner accessibility.

Step 1: Choose a compartment and region

Sign in to the OCI Console.
Select the region you want to use (top-right region menu).
Select or create a compartment you can use for the lab.

Expected outcome: You know the region and compartment where all lab resources will be created.

Verification: – In Console, confirm the compartment name in the left-side compartment picker. – Ensure you have permissions to create networking and compute resources.

Step 2: Create an SSH key pair (local machine)

On your local machine, generate an SSH key pair (if you don’t already have one).

macOS / Linux

ssh-keygen -t ed25519 -C "oci-compute-lab" -f ~/.ssh/oci_compute_lab

Windows (PowerShell with OpenSSH)

ssh-keygen -t ed25519 -C "oci-compute-lab" -f $env:USERPROFILE\.ssh\oci_compute_lab

This creates: – Private key: oci_compute_lab – Public key: oci_compute_lab.pub

Expected outcome: You have a public key to paste into the instance creation form.

Verification:

ls -l ~/.ssh/oci_compute_lab ~/.ssh/oci_compute_lab.pub

Step 3: Create a VCN with a public subnet

In OCI Console: 1. Go to Networking → Virtual Cloud Networks. 2. Click Create VCN. 3. Choose VCN with Internet Connectivity (wizard).
– This typically creates: – VCN – Internet Gateway – Route table with a default route to the IGW – Public subnet – Security list
The exact wizard options may evolve—follow the prompts and review what will be created. 4. Provide: – Name: vcn-compute-lab – (Optionally) CIDR: keep default unless you need a specific range 5. Click Create.

Expected outcome: A VCN exists with a public subnet that can route to the internet.

Verification: – Open the VCN details. – Confirm an Internet Gateway exists and is attached. – Confirm the public subnet exists. – Confirm the route table has 0.0.0.0/0 → Internet Gateway.

Step 4: Configure inbound security rules (SSH and HTTP)

You need inbound rules to allow SSH and HTTP to the instance.

You can do this with either: – the subnet Security List, or – a Network Security Group (NSG) attached to the instance (often preferred for fine-grained control).

For a beginner lab, updating the Security List is simplest.

Option A (simple): Update the subnet’s Security List

In the VCN, go to Security Lists.
Open the security list used by your public subnet.
Add Ingress Rules: – SSH:
- Stateless: No
- Source CIDR: your public IP/32 (recommended)
- If you don’t know it, search “what is my ip” in your browser.
- IP Protocol: TCP
- Destination Port Range: 22
- HTTP:
- Source CIDR: 0.0.0.0/0
- IP Protocol: TCP
- Destination Port Range: 80

Expected outcome: OCI network rules allow inbound SSH from your IP and HTTP from anywhere.

Verification: – Review the ingress rules list and confirm ports 22 and 80 are present.

Security note: Avoid 0.0.0.0/0 for SSH in real environments. Restrict SSH to trusted IPs or use OCI Bastion.

Step 5: Create a Compute instance

Go to Compute → Instances.
Click Create instance.
Set: – Name: compute-nginx-lab – Compartment: your lab compartment
Placement: – Availability domain: choose one (if your region has multiple) – Fault domain: leave default or choose one
Image and shape: – Image: Oracle Linux (choose a current version offered) – Shape: pick a small shape suitable for the lab and within your limits (and Always Free eligibility if applicable). Shape names vary by region—choose what’s available and affordable.
Networking: – VCN: vcn-compute-lab – Subnet: your public subnet – Public IPv4 address: Assign (for this lab)
SSH keys: – Paste the contents of ~/.ssh/oci_compute_lab.pub into the SSH key field.
Click Create.

Wait until the instance state becomes Running.

Expected outcome: A running Compute instance with a public IP address.

Verification: – Open the instance details. – Copy the Public IPv4 address. – Confirm the VNIC is in the expected subnet.

Step 6: SSH into the instance

From your local machine:

ssh -i ~/.ssh/oci_compute_lab opc@<PUBLIC_IP>

Replace <PUBLIC_IP> with the instance public IP.

Expected outcome: You get a shell prompt on the instance.

Verification:

uname -a
cat /etc/os-release

Common first-SSH issue: “Permission denied (publickey)” – Confirm you used the right user (opc is common for Oracle Linux images). – Confirm you pasted the correct public key during instance creation. – Confirm your local private key file permissions: bash chmod 600 ~/.ssh/oci_compute_lab

Step 7: Install and start Nginx

On the instance:

sudo dnf -y install nginx
sudo systemctl enable --now nginx
sudo systemctl status nginx --no-pager

Expected outcome: Nginx is installed and running.

Verification:

curl -I http://localhost/

You should see HTTP/1.1 200 OK (or similar).

Step 8: Allow HTTP through the instance firewall (if required)

Some OS images enable host-level firewall rules. If HTTP is blocked at the OS level, open port 80.

On Oracle Linux (commonly using firewalld), try:

sudo firewall-cmd --state

If running, allow HTTP:

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --reload

Expected outcome: The OS allows inbound HTTP.

Verification:

sudo firewall-cmd --list-all

Step 9: Test from the internet

From your local machine:

curl -I http://<PUBLIC_IP>/

Or open http://<PUBLIC_IP>/ in a browser.

Expected outcome: You see the Nginx default page (or at least a 200 OK response).

Validation

Confirm all layers are correct:

Instance is running in OCI Console.
VCN routing: public subnet route table has 0.0.0.0/0 → Internet Gateway.
Security rules: – Ingress TCP/80 allowed to the instance (security list or NSG).
Host firewall allows port 80 (if firewalld is enabled).
Nginx is running: bash systemctl is-active nginx

Troubleshooting

Problem: SSH timeout

Likely causes: – No public IP assigned – Subnet is not truly public (missing IGW route) – Security list/NSG missing TCP/22 ingress – Your source IP changed (if you restricted SSH to one IP)

Fix: – Confirm instance has a public IP in VNIC details. – Confirm route table has 0.0.0.0/0 → IGW. – Add ingress rule for TCP/22 from your current IP.

Problem: SSH “Permission denied (publickey)”

Likely causes: – Wrong username (opc for Oracle Linux; other images differ) – Wrong key pasted – Using the wrong private key locally

Fix: – Verify the image’s documented default user. – If needed, create a new instance with the correct public key.

Problem: HTTP works on localhost but not from the internet

Likely causes: – Missing TCP/80 ingress rule in security list/NSG – Host firewall blocks port 80 – You tested the wrong public IP

Fix: – Add TCP/80 rule in the right security list/NSG. – Open firewalld HTTP service. – Re-check the instance’s current public IP.

Problem: Instance launch fails due to capacity or limits

Likely causes: – OCPU/instance limit reached in region – Shape not available in the AD

Fix: – Choose a smaller shape or different AD. – Request service limit increase (if applicable). – Try another region (if allowed).

Cleanup

To avoid ongoing charges, delete what you created:

Terminate the instance – Compute → Instances → compute-nginx-lab → Terminate – If prompted about preserving the boot volume, choose Delete boot volume for full cleanup (unless you need it).
Delete the VCN – Networking → VCNs → vcn-compute-lab → Terminate – The console may require you to delete dependent resources first (subnets, gateways, route tables, etc.). If you used the wizard, the VCN delete workflow typically guides dependency cleanup.
Confirm no leftover: – Block volumes / boot volumes – Public IP resources (if separately allocated) – Load balancers (not created in this lab)

11. Best Practices

Architecture best practices

Design for failure: use multiple instances across fault domains (and ADs where applicable).
Keep app tiers stateless where possible; store state in managed databases or shared storage services.
Prefer Load Balancer + instance pools for scalable web/API tiers.
Use private subnets for application and database tiers; expose only load balancers or API gateways.
Plan for DR: backups, image strategy, and (if needed) multi-region patterns.

IAM/security best practices

Use compartments to separate environments (dev/test/prod) and teams.
Enforce least privilege policies; avoid broad “manage all-resources” policies outside admin groups.
Prefer instance principals (dynamic groups) over embedding API keys on instances.
Restrict SSH:
don’t expose SSH to the internet when possible
use OCI Bastion or VPN access patterns

Cost best practices

Right-size instances and volumes; periodically review utilization.
Use autoscaling for variable workloads.
Stop non-prod instances outside working hours via automation.
Clean up unused boot volumes, block volumes, and backups.
Tag resources for cost allocation (environment, application, owner, cost-center).

Performance best practices

Choose shapes based on measured needs; benchmark if performance is critical.
Use appropriate storage performance options and tune OS/filesystems.
Place latency-sensitive components in the same region/VCN and avoid unnecessary cross-region calls.

Reliability best practices

Use multiple instances + health checks + load balancer.
Use instance pools to automatically replace unhealthy nodes.
Keep configuration in code and externalize secrets/config.
Regularly test restore procedures (from backups/images).

Operations best practices

Centralize logging and create alerts for:
CPU/memory/disk saturation
instance down/unreachable
application health endpoints
Patch OS regularly using a defined maintenance window and tooling (consider OCI OS management services).
Use immutable patterns where possible: update via new images/config and replace instances rather than patching in-place.

Governance/tagging/naming best practices

Naming:
env-app-tier-region-## (example: prod-payments-api-iad-01)
Tagging:
Environment, Owner, CostCenter, AppName, DataSensitivity
Use quotas and budgets to prevent runaway spend.

12. Security Considerations

Identity and access model

OCI IAM governs access using:
users, groups, policies
compartments
For workloads running on instances:
use instance principals with dynamic groups and IAM policies to grant the instance permission to call OCI APIs.

Encryption

Boot and block volumes support encryption (Oracle-managed keys by default).
For higher control, integrate with OCI Vault for customer-managed keys where required (verify exact configuration and supported services):
Vault overview: https://docs.oracle.com/en-us/iaas/Content/KeyManagement/home.htm

Network exposure

Minimize public IP usage.
Prefer:
public Load Balancer + private instances
OCI Bastion for admin access
NAT Gateway for outbound-only internet from private subnets
Use NSGs for instance-level segmentation (web vs app vs admin).

Secrets handling

Do not store secrets in:
instance metadata
user-data scripts in plaintext
AMIs/images without protection
Use Vault secrets and retrieve them at runtime (with instance principal permissions).

Audit/logging

OCI Audit logs control plane actions.
Enable centralized log collection for OS and app logs.
Monitor authentication events and network changes.

Compliance considerations

Compliance depends on:
region selection
your organization’s controls
OCI compliance programs
Start with Oracle’s compliance documentation and align with your security team’s requirements. Verify in official Oracle materials.

Common security mistakes

SSH open to 0.0.0.0/0
Instances in public subnets with broad inbound rules
No patching process
No centralized logging
Excess IAM permissions for developers/service accounts
Long-lived API keys stored on servers

Secure deployment recommendations

Use private subnets by default.
Expose only what you must (typically 443 via Load Balancer/WAF).
Enforce least privilege and use instance principals.
Adopt a hardened baseline image and regularly rebuild.
Use vulnerability scanning and OS configuration management.

13. Limitations and Gotchas

Known limitations / practical constraints

Shape availability varies by region and AD; not all regions have GPU/HPC options.
Some regions are single-AD, affecting HA strategies (you’ll rely on fault domains and multi-region DR).
Service limits/quotas can prevent instance launches (OCPU limits, instance count limits).
Marketplace images may introduce licensing constraints or extra costs.

Operational gotchas

“Public subnet” requires both:
a route to Internet Gateway
correct ingress security rules
(and often) OS firewall configuration
Deleting an instance does not always imply deleting all associated storage—watch for:
retained boot volumes
unattached block volumes
backups
Cloud-init/user-data scripts can fail silently if not logged/validated; always test idempotency.

Pricing surprises

Always Free eligibility is not universal and can change; verify entitlement.
Egress and load balancer charges can dominate cost at scale.
Storage and backups can quietly accumulate.

Compatibility issues

Certain enterprise software may require specific CPU instruction sets or OS kernels—validate in a proof-of-concept.
BYOL licensing compliance is your responsibility.

Migration challenges

IP addressing changes and DNS updates
Re-architecting for HA (single VM → pool + load balancer)
Rebuilding automation and security controls in OCI models (compartments, policies)

Vendor-specific nuances

OCI uses OCPUs as a unit of CPU capacity. Map your needs carefully when comparing to other clouds’ vCPU models (exact equivalence depends on platform; verify in official docs).

14. Comparison with Alternatives

Nearest services in Oracle Cloud

Container Engine for Kubernetes (OKE): better for container orchestration and microservices; uses compute nodes underneath but abstracts deployment/scaling.
Functions: serverless; best for event-driven tasks without server management.
Oracle-managed application platforms (where applicable): reduce OS management overhead.

Nearest services in other clouds

AWS EC2, Azure Virtual Machines, Google Compute Engine are direct analogs for VM/bare metal compute.

Open-source/self-managed alternatives

On-prem VMware or OpenStack for private cloud IaaS
Proxmox/KVM for smaller-scale virtualization

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Oracle Cloud Compute	VM/bare metal workloads needing OS control	OCI integration (VCN/IAM), flexible sizing (shape-dependent), instance pools/autoscaling	You manage OS/security patches; HA must be designed	Lift-and-shift, custom runtime, scalable VM app tiers
OCI OKE (Kubernetes)	Containerized microservices	Declarative deployments, service discovery, rolling updates	Kubernetes operational complexity	You’re standardizing on containers and need orchestration
OCI Functions	Event-driven tasks	No servers to manage; scales automatically	Cold starts/limits; not for long-running stateful apps	Spiky workloads, automation hooks, lightweight APIs
AWS EC2	General VM compute	Mature ecosystem; many instance types	Different IAM/networking model; costs vary	You’re already standardized on AWS or need specific AWS services
Azure Virtual Machines	Microsoft-centric stacks	Strong integration with Azure AD/Windows tooling	Different networking/ops patterns	You’re aligned to Azure and Microsoft services
Google Compute Engine	Data/ML-heavy or general compute	Strong global network; integrations with GCP data services	Different IAM/networking model	You’re aligned to GCP services
On-prem VMware/OpenStack	Private cloud requirements	Full control, data residency, legacy integrations	CapEx, maintenance overhead	Strict on-prem requirements or existing investment

15. Real-World Example

Enterprise example: HA API platform for an internal finance system

Problem: A finance department runs internal APIs used by multiple business units. Downtime impacts billing and reporting.
Proposed architecture:
VCN with public and private subnets
Public OCI Load Balancer terminating TLS
Private Compute instance pool (autoscaling) running API servers
OCI Bastion for admin access
Database on an OCI managed database service (or a carefully designed self-managed DB tier if required)
Central Logging + Monitoring + Alarms + Notifications
Why Compute was chosen:
The API runtime needs OS-level tuning and specific libraries.
The enterprise wants predictable scaling and straightforward VM operations.
Instance pools provide resilience (replace unhealthy nodes).
Expected outcomes:
Higher availability through redundancy and health checks
Controlled scaling during peak periods
Improved security posture (private subnets, least privilege IAM, centralized audit)

Startup/small-team example: Low-cost web app hosting with a simple pipeline

Problem: A small team needs to host a web app quickly and cheaply, with minimal platform complexity.
Proposed architecture:
One small Compute instance for web/app
Object Storage for build artifacts and static assets
Basic monitoring/alerting for uptime
Nightly automated backups (where appropriate)
Why Compute was chosen:
Lowest barrier to entry: a single VM is easy to understand.
Full control to install dependencies without learning Kubernetes.
Easy to evolve later into load balancing + pools when growth demands it.
Expected outcomes:
Fast launch with low initial costs
Clear path to scale (add Load Balancer, add instance pool)
Operational learning foundation for the team

16. FAQ

1) What is Oracle Cloud Compute?

Oracle Cloud Compute is OCI’s service for provisioning and operating VM and bare metal instances, including shapes, images, networking attachments, and lifecycle management.

2) Is Compute regional or global?

Compute is regional. Instances are created in a region and placed into an Availability Domain (where available) and a Fault Domain.

3) What’s the difference between a VM and bare metal instance?

A VM runs on shared physical hardware with virtualization isolation; bare metal gives you an entire physical server. Bare metal can be useful for performance, licensing, or specialized control requirements, but it costs more and still requires HA design.

4) What is a shape in Compute?

A shape defines the CPU (OCPUs), memory, and network limits for an instance. Some shapes are flexible, allowing you to select OCPU and memory within allowed ranges.

5) What is an OCPU?

An OCPU is OCI’s unit of CPU capacity. When comparing across clouds, validate equivalence using official OCI documentation because “vCPU” definitions vary by provider.

6) How do I access a Linux Compute instance?

Typically via SSH using a key pair. You paste the public key at instance creation and use the private key locally.

7) How do I access a private instance without a public IP?

Common options include: – OCI Bastion – VPN/FastConnect into the VCN – A tightly locked down jump host (less preferred than managed Bastion)

8) Do I need an Internet Gateway to SSH to a public instance?

Yes, generally you need: – a public IP on the instance – a subnet route to an Internet Gateway – ingress security rules allowing TCP/22 from your source IP

9) What are instance pools used for?

Instance pools manage a group of identical instances based on an instance configuration. They’re commonly used for stateless web/app tiers and can integrate with autoscaling.

10) Can Compute autoscale automatically?

Yes—autoscaling can adjust instance pool size based on metrics. Tune policies carefully to avoid rapid scale in/out cycles.

11) How do I patch instances?

You patch at the OS level (package updates, kernel updates) using your chosen process/tooling. OCI also has OS management services you can evaluate to standardize patching (verify the current recommended service in OCI docs for your environment).

12) Is storage deleted when I terminate an instance?

Not always. Pay attention to whether the boot volume is deleted on termination and whether separate block volumes remain. Always verify after cleanup to avoid storage charges.

13) How do I reduce Compute costs?

Right-size shapes and volumes
Stop non-prod instances when not needed
Use autoscaling for variable traffic
Control egress and use private access paths to OCI services where possible

14) What’s the best way to deploy production web apps on Compute?

A common pattern is: – public Load Balancer – private instance pool across fault domains/ADs – centralized logging/monitoring – automated image/config rollouts

15) How does Compute relate to Kubernetes (OKE)?

OKE uses compute instances as worker nodes (unless using a serverless/managed compute mode, if offered). If you don’t need Kubernetes, Compute can be simpler for many workloads.

16) Can I use Terraform with Compute?

Yes. OCI supports Terraform through the OCI provider and OCI Resource Manager (managed Terraform). Verify current provider docs for the exact resources and arguments.

17) What should I use for secrets on instances?

Use OCI Vault (secrets) and retrieve secrets at runtime using instance principals. Avoid hardcoding secrets in images or scripts.

17. Top Online Resources to Learn Compute

Resource Type	Name	Why It Is Useful
Official documentation	OCI Compute documentation	Primary source for features, APIs, and operational guidance: https://docs.oracle.com/en-us/iaas/Content/Compute/home.htm
Official documentation	OCI Compute “Instances” concepts	Deep dive on instance lifecycle, shapes, images (navigate within Compute docs): https://docs.oracle.com/en-us/iaas/Content/Compute/Concepts/computeoverview.htm
Official pricing	Compute pricing	Current pricing model and SKUs by region: https://www.oracle.com/cloud/compute/pricing/
Official pricing	OCI price list	Region/SKU reference pricing: https://www.oracle.com/cloud/price-list.html
Official Free Tier	Oracle Cloud Free Tier	Always Free eligibility and limits (verify current entitlements): https://www.oracle.com/cloud/free/
Official CLI docs	OCI CLI installation	Install/configure CLI for automation: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
Official architecture	OCI Architecture Center	Reference architectures including HA web tiers and networking: https://docs.oracle.com/en/solutions/
Official security	IAM policies	How IAM policies work and how to write them: https://docs.oracle.com/en-us/iaas/Content/Identity/Concepts/policies.htm
Official observability	Monitoring overview	Metrics, alarms, and operational monitoring: https://docs.oracle.com/en-us/iaas/Content/Monitoring/home.htm
Official logging	Logging overview	Centralized logging options: https://docs.oracle.com/en-us/iaas/Content/Logging/home.htm
Official tutorials/labs	OCI tutorials	Hands-on labs across OCI services (search Compute topics): https://docs.oracle.com/en/learn/
Official YouTube	Oracle Developers / Oracle Cloud channels	Practical demos and service updates (verify playlists): https://www.youtube.com/@OracleDevelopers
Code samples	OCI SDK samples (GitHub)	Examples for provisioning/automation (verify repository relevance): https://github.com/oracle/oci-python-sdk (and related Oracle OCI repos)

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, cloud engineers	OCI fundamentals, automation, DevOps practices (verify course outline)	check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate IT professionals	DevOps/SCM foundations and cloud operations (verify OCI coverage)	check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud operations teams	Cloud ops, monitoring, incident response patterns (verify OCI modules)	check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, platform engineers	Reliability engineering, observability, operations practices (verify OCI labs)	check website	https://www.sreschool.com/
AiOpsSchool.com	Ops teams adopting AIOps	Monitoring, event correlation, AIOps concepts (verify OCI integration topics)	check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	Cloud/DevOps training content (verify current offerings)	Beginners to intermediate	https://www.rajeshkumar.xyz/
devopstrainer.in	DevOps training	DevOps engineers and sysadmins	https://www.devopstrainer.in/
devopsfreelancer.com	DevOps consulting/training platform (verify services)	Small teams needing practical guidance	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and training resources (verify scope)	Ops teams and engineers	https://www.devopssupport.in/

20. Top Consulting Companies

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify exact portfolio)	OCI adoption, migrations, automation, platform setup	VCN + Compute landing zone, VM migration factory, monitoring/alerting rollout	https://cotocus.com/
DevOpsSchool.com	DevOps and cloud consulting/training	DevOps transformation, CI/CD, infrastructure automation	Terraform-based Compute provisioning, secure network patterns, ops runbooks	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting	Delivery pipelines, cloud operations, reliability improvements	Instance pool deployment patterns, immutable image pipelines, cost governance setup	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Compute

Linux fundamentals (SSH, systemd, networking, firewalls)
Basic networking (CIDR, routing, DNS, TLS)
Cloud basics:
IAM concepts (users/roles/policies)
VPC/VCN concepts (subnets, gateways, security groups)
Basic security hygiene (patching, least privilege, key management)

What to learn after Compute

Infrastructure as Code:
Terraform with OCI provider
OCI Resource Manager
Scalable architectures:
instance pools + autoscaling
load balancing and health checks
multi-tier private network design
Observability:
metrics, logs, tracing concepts
alert tuning and incident response
Containerization:
Docker fundamentals
OCI Container Engine for Kubernetes (OKE)
Security hardening:
Vault, key management, secret rotation
network segmentation and zero trust patterns

Job roles that use Compute

Cloud Engineer (OCI)
DevOps Engineer / Platform Engineer
Site Reliability Engineer (SRE)
Systems Administrator (cloud-focused)
Solutions Architect
Security Engineer (cloud infrastructure)

Certification path (if available)

Oracle offers OCI certifications that commonly include compute and core infrastructure topics. Start with Oracle’s official certification listings and choose the track that matches your role: – https://education.oracle.com/certification

(Always verify the current certification names and exam objectives on Oracle’s site.)

Project ideas for practice

Build a 2-tier app: – public LB → private compute pool → managed database
Create a golden image pipeline: – build custom image → deploy pool → rolling replace
Implement private egress: – private subnet + NAT Gateway + restricted NSGs
Add observability: – alarms on CPU/disk, centralized logs, alert routing to email/Slack (via Notifications)
Implement instance principal automation: – instance reads from Object Storage securely without API keys

22. Glossary

Compute: Oracle Cloud (OCI) service for provisioning VM and bare metal instances.
Instance: A running VM or bare metal server in OCI.
Shape: A resource template defining CPU (OCPUs), memory, and network limits for an instance.
OCPU: OCI’s unit of CPU capacity used for pricing and sizing.
Image: The OS template used to create an instance (platform, custom, or Marketplace).
Boot volume: The persistent disk that contains the OS for an instance.
Block volume: Additional persistent storage attached to an instance.
VCN (Virtual Cloud Network): OCI’s virtual network.
Subnet: A segment of a VCN where instances are placed.
VNIC: Virtual network interface card attached to an instance.
Internet Gateway (IGW): Enables public internet connectivity for subnets with appropriate routing.
NAT Gateway: Allows outbound internet access from private subnets without inbound exposure.
Service Gateway: Private access to supported OCI public services without traversing the internet.
Security List: Subnet-level stateful firewall rules.
NSG (Network Security Group): Instance-level stateful firewall rules.
Compartment: OCI logical container used for isolation and access control.
IAM Policy: Rules defining who can access which OCI resources and how.
Instance Pool: Managed group of identical instances.
Autoscaling: Automatically adjusts pool size based on metrics.
Fault Domain: Logical grouping within an AD to reduce correlated failures.
Availability Domain (AD): A data center within a region (not all regions have multiple ADs).

23. Summary

Oracle Cloud Compute is OCI’s core service for running VM and bare metal servers with full operating system control. It matters because it’s the most direct and flexible way to host applications, migrate legacy workloads, and build scalable VM-based platforms in Oracle Cloud.

In OCI architectures, Compute typically sits behind VCN networking and integrates with Block Volume, Load Balancer, IAM, and Monitoring/Logging. Cost is driven mainly by instance runtime (shape/OCPU/memory), storage (boot/block volumes and backups), and network egress. Security depends on strong IAM policy boundaries (compartments, least privilege), minimal public exposure, and disciplined patching and logging.

Use Compute when you need OS-level control, broad compatibility, and scalable VM patterns (instance pools/autoscaling). Prefer higher-level services (OKE, Functions, managed databases) when you want to reduce server management overhead.

Next learning step: take the single-instance lab from this tutorial and evolve it into a production pattern—private subnets + load balancer + instance pool + autoscaling + centralized monitoring/logging + Vault-based secrets—using Terraform or OCI Resource Manager for repeatability.

rajeshkumar

Category

1. Introduction

2. What is Compute?

Core capabilities

Major components (you will see these in Console/CLI/API)

Service type and scope

How Compute fits into the Oracle Cloud ecosystem

3. Why use Compute?

Business reasons

Technical reasons

Operational reasons

Security/compliance reasons

Scalability/performance reasons

When teams should choose Compute

When teams should not choose it

4. Where is Compute used?

Industries

Team types

Workloads

Architectures and deployment contexts

5. Top Use Cases and Scenarios

1) Public web server (Nginx/Apache)

2) API application tier behind a load balancer

3) Legacy app lift-and-shift

4) Secure administrative jump host (or Bastion alternative)

5) CI/CD build agents and runners

6) Batch processing / scheduled jobs

7) Self-managed middleware

8) GPU-backed inference server (region-dependent)

9) High-performance computing node (region-dependent)

10) Secure file processing and transformation

11) Development environments and sandboxes

12) Vendor software that requires BYOL or host-level controls

6. Core Features

Instances (VM and bare metal)

Shapes (fixed and flexible)

Images (platform, custom, and Marketplace)

Boot volumes and block volumes

Networking: VNICs, subnets, private/public IPs

Security Lists and Network Security Groups (NSGs)

Instance metadata and cloud-init bootstrapping

Console access (Instance Console Connection)

Instance Pools and Instance Configurations

Autoscaling

Fault Domains and Availability Domains

Capacity planning controls (region/shape dependent)

7. Architecture and How It Works

High-level architecture

Request/control flow (typical “create instance”)

Common integrations

Dependency services (practically required)

Security/authentication model

Networking model (important for real deployments)

Monitoring/logging/governance considerations

Simple architecture diagram (single VM web server)

Production-style architecture diagram (HA web tier + private app + DB)

8. Prerequisites

Account/tenancy requirements

Permissions / IAM policies

Billing requirements

Tools

Region availability

Quotas/limits

Prerequisite services

9. Pricing / Cost

Official pricing sources

Pricing dimensions (how you get charged)

Free Tier / Always Free considerations

Primary cost drivers

Hidden or indirect costs to watch

Network/data transfer implications

How to optimize cost (practical)

Example low-cost starter estimate (conceptual)

Example production cost considerations (what to model)

10. Step-by-Step Hands-On Tutorial

Objective

Lab Overview

Step 1: Choose a compartment and region

Step 2: Create an SSH key pair (local machine)

macOS / Linux