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

1. Introduction

What this service is

Compute Cloud@Customer Isolated is an Oracle Cloud (OCI) “Cloud@Customer” offering that delivers OCI-style compute capabilities (and the minimum required control plane) into a customer-controlled location—typically an on-premises data center or a secure facility—while operating in an isolated / disconnected mode designed for strict regulatory, sovereignty, or air-gapped requirements.

One-paragraph simple explanation

If you need to run virtual machines (and possibly bare metal workloads) using OCI concepts like compartments, VCNs, and OCI APIs—but you cannot rely on continuous connectivity to a public Oracle Cloud region—Compute Cloud@Customer Isolated brings the cloud to you, rather than sending your workloads to the cloud.

One-paragraph technical explanation

Compute Cloud@Customer Isolated is part of Oracle’s Edge Cloud / Cloud@Customer portfolio. Oracle provides and supports infrastructure and a local control plane that exposes OCI-compatible interfaces for provisioning and managing compute resources on your premises. “Isolated” indicates that the environment is intended to operate without (or with extremely restricted) connectivity to Oracle Cloud public regions; operational workflows, patching/support processes, and service availability are therefore different from standard OCI. Exact included services and operational procedures can vary by contract and release—verify your specific deployment capabilities in the official documentation and your Oracle order documents.

What problem it solves

It solves the common “we need cloud automation and a cloud operating model, but our data and systems must stay in a controlled facility with limited external connectivity” problem—especially in government, defense, critical infrastructure, and regulated industries.

2. What is Compute Cloud@Customer Isolated?

Official purpose

Compute Cloud@Customer Isolated is designed to deliver OCI compute capabilities in a customer location under strict isolation requirements. It aims to provide a cloud-like provisioning and governance experience while meeting constraints such as:

No direct internet access
No continuous connectivity to an OCI public region
Strong data residency and operational control requirements

Because product packaging can evolve, confirm the latest positioning and scope using Oracle’s Cloud@Customer pages and the Compute Cloud@Customer documentation: – Cloud@Customer overview: https://www.oracle.com/cloud/cloud-at-customer/ – OCI documentation portal (search within for “Compute Cloud@Customer” and “Isolated”): https://docs.oracle.com/en-us/iaas/

Core capabilities (conceptual)

Compute Cloud@Customer Isolated typically focuses on the capabilities needed to run and manage compute workloads in an isolated environment:

Provision and manage compute instances (VMs and/or bare metal, depending on offering)
OCI-style identity, access control, and resource organization (tenancy/compartments, policies)
OCI-style networking constructs (for example, VCN/subnets/security rules) to the extent included in your deployment
Images, boot volumes, and block storage primitives to the extent included
Programmatic management via OCI APIs/SDKs/CLI endpoints hosted within the isolated environment

Important: The exact list of supported OCI services in a Cloud@Customer isolated deployment is not always identical to a public OCI region. Treat any service beyond core compute/networking as “verify in official docs for your deployment.”

Major components (high level)

A typical Compute Cloud@Customer Isolated environment includes:

On-premises infrastructure provided as part of the Cloud@Customer delivery (racks/nodes, storage, networking appliances as applicable)
Local control plane exposing OCI-like APIs and a console endpoint hosted within the customer environment
Compute capacity (VM and/or bare metal)
Local networking integration to connect the environment to customer networks
Operational tooling and processes for upgrades, patching, break-glass access, incident response, and metering (process differs in isolated mode)

Service type

Edge Cloud / Cloud@Customer: Oracle-managed or jointly operated cloud infrastructure placed in a customer-controlled site.
Not a “pure SaaS” service; it is a delivered system plus an operating model.

Scope model (how it is “scoped”)

Compute Cloud@Customer Isolated is best thought of as:

Environment/installation-scoped: It is tied to a specific customer site and delivered hardware/control plane.
Tenancy-scoped within that environment: You typically organize resources using OCI-like constructs (tenancy, compartments, groups, policies).
Region-like endpoint, but local: You access services via local endpoints. Whether the environment presents a “region identifier” similar to OCI public regions depends on the implementation—verify in your deployment docs.

How it fits into the Oracle Cloud ecosystem

Compute Cloud@Customer Isolated aligns with OCI concepts, APIs, and governance patterns so teams can:

Apply similar provisioning patterns (IaC, CI/CD, API-driven operations)
Standardize operational practices across public OCI and edge/on-prem (where allowed)
Support data sovereignty and air-gap requirements that public cloud regions may not satisfy

3. Why use Compute Cloud@Customer Isolated?

Business reasons

Meet strict residency and sovereignty constraints without giving up cloud-like operations.
Reduce approval friction for sensitive programs by keeping systems in controlled facilities.
Modernize legacy environments with automation and standardized governance patterns.

Technical reasons

Low-latency local compute for systems that must run near data sources or within secured networks.
Cloud-like provisioning APIs in an environment that cannot rely on public internet connectivity.
Consistency with OCI constructs (compartments, policies, networking patterns) for teams already using Oracle Cloud.

Operational reasons

Standard operating model for provisioning, change management, tagging, and access control.
Predictable environment boundary (a known site and hardware footprint).
Support model aligned to Oracle Cloud@Customer (exact responsibilities differ—verify your contract and runbooks).

Security/compliance reasons

Supports scenarios requiring:
Air-gapped or disconnected operations
Controlled facility requirements
Tight network egress control
Local-only management endpoints
Enables security teams to implement consistent controls around identity, segmentation, and logging within a defined boundary.

Scalability/performance reasons

Provides cloud-style elasticity within the installed capacity.
Scaling beyond installed capacity may require ordering additional capacity and change windows—this is not the same as “infinite” public cloud scaling.

When teams should choose it

Choose Compute Cloud@Customer Isolated when you need:

OCI-like compute provisioning on premises
Strong isolation requirements (no/limited external connectivity)
A cloud operations model for regulated or classified environments
A platform that can be standardized with Oracle Cloud practices

When they should not choose it

Avoid (or reconsider) Compute Cloud@Customer Isolated if:

You need rapid, unlimited capacity scaling without procurement lead times
Your workloads require a broad set of managed services only available in public OCI regions
You have no facility capability for hosting the system (power, cooling, physical security)
You cannot support the operational processes required for an isolated environment (offline patching, curated repos, controlled access)

4. Where is Compute Cloud@Customer Isolated used?

Industries

Commonly aligned industries include:

Government / defense / intelligence (classified or sovereign environments)
Critical infrastructure (energy, utilities, transportation)
Healthcare (highly regulated patient data environments)
Financial services (certain sovereign/regulated zones)
Manufacturing and industrial environments with strict OT/IT separation

Team types

Platform engineering teams building standardized internal clouds
Security engineering teams enforcing isolation and segmentation
SRE/operations teams managing lifecycle and reliability
DevOps teams implementing CI/CD in restricted networks
Application teams modernizing monoliths into VM-based micro-segmentation patterns

Workloads

Traditional enterprise applications requiring VMs
COTS applications with strict deployment and network constraints
Data processing pipelines operating on locally generated data
Security tooling, SOC platforms, and offline analytics
Private internal developer platforms (artifact repos, CI runners) in disconnected environments

Architectures

“On-prem cloud region” patterns with compartment-based governance
Hub-and-spoke networks with strict segmentation
Zero-trust internal network designs
Multi-enclave architectures (for example, dev/test vs prod separation at network + IAM levels)

Real-world deployment contexts

Secure data centers with controlled ingress/egress
Facilities with no internet connectivity
Environments requiring local operator-only access
Sites where audit evidence must remain on-prem

Production vs dev/test usage

Production: Common for regulated workloads that cannot leave the facility.
Dev/test: Often used when dev/test must mirror production isolation constraints (for example, classified programs).
A common pattern is hybrid: dev/test in public OCI, prod on isolated—but only if policy permits.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Compute Cloud@Customer Isolated is a strong fit. Exact feasibility depends on your deployment’s supported services—verify against official docs for your environment.

1) Air-gapped mission system modernization

Problem: A mission system must be modernized but cannot connect to the internet.
Why this service fits: Provides cloud-like provisioning and governance within an isolated environment.
Example scenario: A defense program migrates legacy VM workloads to an OCI-like on-prem environment, standardizing provisioning and patch windows.

2) Sovereign data residency with cloud-style operations

Problem: Regulations require data to remain inside a specific facility or jurisdiction.
Why this service fits: Compute and management planes run locally under controlled boundaries.
Example scenario: A regulated agency runs citizen data workloads in an on-prem facility with strict access controls and local audit trails.

3) Secure build and CI/CD runners for restricted codebases

Problem: Build pipelines must operate on code that cannot be exposed to external services.
Why this service fits: CI runners can run on isolated compute instances; artifact flow can be kept internal.
Example scenario: A platform team hosts internal Git/CI and runners on Compute Cloud@Customer Isolated with network segmentation by environment.

4) OT/IT boundary enforcement for industrial sites

Problem: Industrial control networks need compute for analytics without opening internet paths.
Why this service fits: Enables local compute close to OT data sources, with strict segmentation to IT.
Example scenario: A manufacturing site runs predictive maintenance analytics on local compute nodes, moving only aggregated results via controlled export.

5) Classified analytics enclave

Problem: Analysts need compute capacity for batch processing in a classified enclave.
Why this service fits: Local compute scaling within installed capacity, with strong isolation properties.
Example scenario: A government team runs nightly analytics jobs on private subnets; access is restricted to jump hosts and approved workstations.

6) COTS application hosting in a disconnected facility

Problem: A vendor application requires VMs and specific OS versions, and must be hosted offline.
Why this service fits: VM-based compute is well-suited for COTS; operations can be standardized.
Example scenario: A facility hosts a COTS case management platform with database and app tiers separated by network security groups.

7) Security tooling (SIEM collectors, forensics, malware analysis)

Problem: Security tooling must process sensitive logs/artifacts locally.
Why this service fits: Compute instances can host collectors and analysis tools inside the secure boundary.
Example scenario: A SOC runs local log processing pipelines; only curated alerts are exported to a central system.

8) Private internal web applications for restricted users

Problem: Internal users need web apps accessible only inside a secure network.
Why this service fits: App servers can be hosted on private subnets; access via internal load balancers (if available) or reverse proxies.
Example scenario: An internal portal runs on private IPs with strict ingress rules from corporate CIDRs.

9) Offline data staging and transformation

Problem: Data enters via controlled media/import processes and must be transformed internally.
Why this service fits: Batch compute can run transformations without cloud egress.
Example scenario: A research lab ingests datasets via secure import, runs ETL on isolated compute, and stores results on internal storage.

10) DR rehearsal and resilience within a secure site

Problem: Teams need predictable recovery procedures without relying on external services.
Why this service fits: Standardized provisioning and images support repeatable environment recreation.
Example scenario: A team runs quarterly “restore from image/backup” drills within the isolated environment to validate RTO/RPO assumptions.

11) Regulated dev/test mirror of production enclave

Problem: Developers need an environment with the same isolation constraints as production.
Why this service fits: Enables consistent IAM/network patterns and repeatable provisioning.
Example scenario: A team validates releases in an isolated dev environment where external dependency calls are blocked by design.

12) Legacy-to-cloud operating model transition

Problem: An organization wants cloud governance patterns but cannot move workloads off-prem yet.
Why this service fits: Provides a stepping stone: cloud operating model on-prem now, potential hybrid later if allowed.
Example scenario: A bank standardizes compartments/policies/tags and automation in an isolated environment while preparing for future hybrid adoption.

6. Core Features

Because Cloud@Customer portfolios can vary by contract and release, treat this as a “core feature set” view and verify the exact supported services in your deployment’s documentation.

OCI-style compute provisioning (VMs and/or bare metal)

What it does: Lets you create and manage compute instances using OCI-like constructs (shapes, images, boot volumes).
Why it matters: Enables standardized provisioning and lifecycle management in a restricted environment.
Practical benefit: Faster environment creation and consistent change control.
Caveats: Instance shapes and capacity are bounded by installed hardware. Some public OCI shapes/features may not exist in your on-prem footprint.

Local control plane and console/API endpoints

What it does: Exposes a management console and APIs within the isolated environment.
Why it matters: Operations do not require public internet access.
Practical benefit: Teams can automate with IaC/CLI against local endpoints.
Caveats: Endpoint configuration differs from public OCI; client tools may require custom endpoint/region configuration—follow your deployment’s guide.

OCI-style IAM concepts (users/groups/policies) and compartments

What it does: Enables least-privilege access control and resource isolation using familiar OCI policy language and compartment structure.
Why it matters: Strong governance is essential in high-trust environments.
Practical benefit: Clear separation of duties (platform admins vs app teams) and strong auditability.
Caveats: Federation/SSO options depend on your environment and connectivity constraints—verify supported identity integrations.

Networking constructs (VCN-like segmentation)

What it does: Provides logical network segmentation (for example VCNs/subnets/security rules) aligned with OCI patterns.
Why it matters: Network segmentation is a foundational control in isolated environments.
Practical benefit: Simple, repeatable segmentation patterns for multi-tier apps.
Caveats: Specific networking features (NAT gateways, service gateways, load balancers) may vary—verify in official docs.

Boot volumes, images, and instance lifecycle operations

What it does: Supports instance creation from images, stopping/starting, and lifecycle management.
Why it matters: Enables patching, golden image pipelines, and predictable rebuild processes.
Practical benefit: Standardization: rebuild is safer than manual drift management.
Caveats: Image import/export is constrained by isolation; you typically need a controlled artifact pipeline (offline repos, signed images).

Isolation mode (disconnected operations)

What it does: Supports operation without connectivity to Oracle Cloud public regions.
Why it matters: Enables compliance with air-gap policies.
Practical benefit: Reduced risk from external dependency chains.
Caveats: Operational processes (updates, support data exchange, metering) require offline procedures. Plan for curated package repositories and offline vulnerability feeds.

Tagging, naming, and governance patterns (OCI-aligned)

What it does: Supports tagging to organize resources and allocate costs.
Why it matters: Even isolated environments require cost governance and ownership.
Practical benefit: Chargeback/showback, audit readiness.
Caveats: Exact tagging capabilities depend on the platform release—verify.

Observability hooks (monitoring/logging) — if included

What it does: Provides metrics/logging capabilities (or integrations) for operations.
Why it matters: SRE practices depend on telemetry.
Practical benefit: Faster incident triage and compliance evidence.
Caveats: In isolated mode, integrations to external SaaS endpoints are restricted; you may need local log shipping and local dashboards. If OCI Monitoring/Logging services are not part of your deployment, use OS-level agents and on-prem monitoring stacks.

7. Architecture and How It Works

High-level architecture

A Compute Cloud@Customer Isolated deployment typically consists of:

Customer facility boundary
Physical security and access control
Customer network integration (core switches, firewalls)
Cloud@Customer system
Compute nodes and storage
Local control plane services exposing OCI-like endpoints
Access paths
Admin/operator access from controlled workstations or jump hosts
Application traffic via internal networks
Operations
Provisioning via console, CLI, SDKs
Offline patching/artifact ingestion workflows

Request/data/control flow (conceptual)

Control plane requests: Users/tools call local endpoints to create/manage resources.
Data plane traffic: Workload traffic stays inside your networks (east-west) and to approved networks (north-south) as configured.
Identity and policy evaluation: IAM controls authorize actions; auditing records management-plane events.
Telemetry: Metrics/logs are collected locally and exported only through approved channels (if any).

Integrations with related services

Common integrations (depending on what’s supported in your isolated deployment):

Enterprise identity provider (for SSO/federation) — verify support
On-prem DNS/DHCP/IPAM
On-prem SIEM/SOAR
Artifact repositories (OS packages, container registries) hosted internally
Configuration management (Ansible, Puppet, etc.) from internal control nodes
IaC pipelines (Terraform) executed within the enclave

Dependency services (typical)

Network connectivity between Cloud@Customer system and customer LAN (management + workload)
IP address management, routing, firewall policies
Jump hosts and controlled admin workstations
Local time sync (NTP) sources in the enclave
Local certificate authority / PKI for TLS in internal services

Security/authentication model (typical)

Centralized authorization through OCI-like IAM policies
Strong separation of duties:
Platform administrators manage base infrastructure, quotas, network foundations
App teams deploy into dedicated compartments/subnets
Audit trail for management-plane actions
“Break-glass” procedures for emergency access

Networking model (typical)

One or more logical virtual networks mapped to the customer network boundary
Private subnets for workloads
Optional DMZ subnets for ingress gateways (if permitted)
Strict egress controls by default (common in isolated environments)

Monitoring/logging/governance considerations

Prefer local collection and retention aligned to policy
Use immutable log storage patterns where feasible
Regular evidence generation for compliance (access reviews, policy drift checks)
Tagging standards for owner, environment, data classification

Simple architecture diagram (Mermaid)

flowchart LR
  U[Admin / DevOps User] -->|Console / CLI / API| CP[Local OCI-like Control Plane\n(Compute Cloud@Customer Isolated)]
  CP --> IAM[IAM Policies & Compartments]
  CP --> NET[Virtual Networking\n(VCN/Subnets/Security Rules)]
  CP --> CMP[Compute Instances\n(VM/Bare Metal)]
  CMP --> APP[Application Workloads]
  APP -->|Internal traffic| LAN[Customer Internal Network]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Facility[Customer Secure Facility / Data Center]
    subgraph Access[Controlled Admin Access]
      WS[Privileged Workstation] --> JH[Jump Host / Bastion]
      JH --> CPAPI[Local Console/API Endpoint]
    end

    subgraph CCoC[Compute Cloud@Customer Isolated System]
      CPAPI --> IAM[IAM / Policies / Compartments]
      CPAPI --> NET[Network Control\n(VCN/Subnets/NSGs/Sec Lists)]
      CPAPI --> AUD[Audit Logs (Management Plane)]
      NET --> SUBP[Private Subnets]
      SUBP --> WEB[Web Tier VMs]
      SUBP --> APP[App Tier VMs]
      SUBP --> DB[DB Tier VMs]
    end

    subgraph Enterprise[Enterprise Services (On-Prem)]
      IDP[Identity Provider (SSO)\n(verify support)] --> IAM
      DNS[DNS / NTP / PKI] --> WEB
      DNS --> APP
      DNS --> DB
      SIEM[SIEM / Log Platform] <-->|Log shipping| WEB
      SIEM <-->|Log shipping| APP
      SIEM <-->|Log shipping| DB
      REPO[Offline OS/Artifact Repo] --> WEB
      REPO --> APP
      REPO --> DB
    end

    FW[Internal Firewall / Segmentation] --- NET
    LAN[Corporate / Mission Networks] --- FW
  end

8. Prerequisites

Compute Cloud@Customer Isolated is not a “click-to-enable” public cloud feature; you need a delivered environment and the right access.

Account/subscription/tenancy requirements

A provisioned Compute Cloud@Customer Isolated environment installed in your facility (or approved site).
Tenancy/environment access as provided by Oracle and your internal platform team.

Permissions/IAM roles

You typically need (names vary by organization):

Ability to create and manage:
Compartments/projects
Virtual networks and subnets
Compute instances
Security rules (security lists / NSGs)
Read access to:
Images/shapes available in your environment
Quotas/limits

Ask your platform admin for a role equivalent to “Compute + Network Admin” inside a sandbox compartment.

Billing requirements

Cloud@Customer offerings are commonly contract-based (subscription/commitment). Ensure:
You understand who owns the cost center
Tagging/chargeback standards are defined

CLI/SDK/tools needed

SSH client (OpenSSH)
A workstation that can reach the local console/API endpoints (often via jump host)
Optional (recommended for automation):
OCI CLI: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
Terraform OCI Provider: https://registry.terraform.io/providers/oracle/oci/latest/docs (use only if supported in your environment)

In isolated mode, you may need to host installers internally and follow your enclave’s software approval process.

Region availability

Cloud@Customer is site-specific. Availability is not “regions list in the public console.”
Validate the environment endpoints and supported services with your Oracle delivery and internal platform team.

Quotas/limits

Capacity is constrained by installed hardware.
Tenancy/service limits apply within the environment (exact limits vary). Plan for:
Maximum instances per compartment
CPU/memory availability by shape
Limits on VCNs/subnets/security rules

Prerequisite services

Depending on your organization’s design:

DNS, NTP, certificate authority available within the enclave
Offline OS package repositories (highly recommended)
Central log platform or SIEM (local)

9. Pricing / Cost

Current pricing model (how to think about it)

Compute Cloud@Customer Isolated is typically purchased through an Oracle Cloud@Customer commercial agreement. Pricing is often contracted and may include a combination of:

Consumption-based pricing for enabled services (OCI-like units) and/or
Fixed infrastructure fees
Minimum commitments
Support and lifecycle management terms

Because pricing differs by country, contract, ordering vehicle, and included services, do not treat any third-party numbers as authoritative. Use Oracle’s official pricing resources and your Oracle order documents.

Official starting points: – Cloud@Customer overview: https://www.oracle.com/cloud/cloud-at-customer/ – Cloud@Customer pricing entry point (verify current page): https://www.oracle.com/cloud/cloud-at-customer/pricing/ – OCI Pricing: https://www.oracle.com/cloud/pricing/ – OCI Cost Estimator (public OCI reference; for Cloud@Customer you must confirm applicability): https://www.oracle.com/cloud/costestimator.html

Pricing dimensions (common drivers)

Expect costs to be influenced by:

Committed capacity (installed compute/storage footprint)
Compute consumption (OCPU/CPU, memory, instance-hours) depending on contract model
Storage consumption (boot/block volumes, snapshots/backups) depending on included services
Support level and operational model (who does what; isolated environments can require special procedures)
Expansion events (adding racks/nodes may have lead time and cost)
License implications (if you run licensed software on top—OS, databases, middleware)

Free tier

Oracle Cloud Free Tier applies to public OCI and is generally not applicable to Cloud@Customer installations. Treat Compute Cloud@Customer Isolated as a paid, contracted service.

Cost drivers (direct and indirect)

Direct: – Contracted service charges (compute, storage, support, infrastructure)

Indirect (often bigger than expected in isolated environments): – Facility costs: power, cooling, rack space – Network/security appliances and firewall rule management – Offline patching pipeline (repos, signing, artifact scanning) – Operations headcount: 24×7 coverage, change management, audits – Backup/DR tooling (if not included natively)

Network/data transfer implications

In an isolated environment, “egress to internet” is usually not the cost driver; the driver is network architecture complexity:
Cross-zone segmentation
Dedicated links between enclaves
Controlled export processes for data

If any connectivity to an OCI region exists (some customers allow limited connectivity even in “isolated-like” postures), confirm: – Whether metering, support telemetry, or data export crosses that link – Whether your contract treats that connectivity as billable transfer

How to optimize cost

Right-size shapes and use smaller test compartments for non-prod.
Standardize golden images to reduce drift and incident cost.
Use strict tag policies (owner, cost center, environment, data classification).
Avoid “always-on” non-prod instances—schedule shutdown where permitted.
Consolidate shared services (repos, logging collectors) into a platform compartment rather than duplicating in every app compartment.

Example low-cost starter estimate (how to estimate without making up prices)

Because numbers are contract-dependent, use this approach:

Identify the smallest sandbox footprint you can run: – 1 small admin/jump VM – 1 test app VM – Minimal storage for boot volumes
Determine whether your contract is: – Fixed capacity fee regardless of use, or – Metered within committed capacity
Multiply expected instance-hours by your contracted rate (from order documents) and add storage.

If you do not have the contract rate sheet, you cannot produce a reliable estimate—request it from procurement or your Oracle account team.

Example production cost considerations

For production, cost planning must include:

N+1 capacity for maintenance and failure domains
Separate environments (dev/test/prod) and segmentation overhead
Backups and retention (especially in regulated settings)
Security tooling, vulnerability scanning, and audit evidence generation
Planned expansion cycles (capex-like planning even if billed as a service)

10. Step-by-Step Hands-On Tutorial

This lab is designed to be realistic and executable inside a Compute Cloud@Customer Isolated environment, assuming you already have access to its local console/API endpoint and your platform team has provided a sandbox compartment (or permission to create one).

Because isolated deployments vary, any step that depends on optional features is called out explicitly.

Objective

Provision a small, private web workload in Compute Cloud@Customer Isolated:

Create a sandbox compartment (if allowed)
Create a private virtual network and subnet
Launch two compute instances:
A “web” instance that runs an HTTP server
A “client” instance used to test internal connectivity
Validate traffic using private IPs only
Clean up all created resources

Lab Overview

You will build a minimal “private-only” architecture:

1 VCN (or equivalent virtual network)
1 private subnet
2 compute instances on the same subnet
Security rules allowing:
SSH from your jump host or admin CIDR
HTTP traffic from the client instance to the web instance

Why private-only? In isolated environments, public IPs and internet gateways are often disallowed. This lab matches that reality.

Step 1: Confirm access, endpoints, and your sandbox boundary

Obtain from your platform admin: – Local console URL (for the isolated environment) – Your username and MFA requirements (if used) – Your assigned compartment (recommended) or permission to create one – Network rules for admin access (what CIDR can SSH to instances)
Log in to the local console.

Expected outcome – You can access the Compute Cloud@Customer Isolated console and see your compartment(s).

Verification – In the console, confirm you can navigate to Compute resources and Networking resources without authorization errors.

Step 2: Create (or select) a compartment for the lab

If your organization allows you to create compartments:

Go to Identity & Security → Compartments.
Click Create Compartment.
Use: – Name: lab-ccoc-isolated – Description: Hands-on lab compartment for Compute Cloud@Customer Isolated
Create.

If compartments are centrally managed, use the sandbox compartment you were given.

Expected outcome – A dedicated compartment exists to isolate and clean up lab resources.

Verification – Switch your console scope to the compartment and confirm it appears in the compartment selector.

Step 3: Create a private network (VCN) and subnet

Go to Networking → Virtual Cloud Networks (or your platform’s equivalent).
Click Create VCN.
Use a simple CIDR that does not overlap with your on-prem networks, for example: – VCN CIDR: 10.10.0.0/16
Create one private subnet: – Subnet CIDR: 10.10.10.0/24 – “Public subnet”: No (private)
Keep defaults for route tables and DHCP options unless your platform team has standards to follow.

Expected outcome – A VCN with a private subnet exists.

Verification – Confirm subnet is Available. – Confirm the subnet has a security list or NSG capability available for instance attachments.

If your environment provides predefined networks that you must use, follow your platform team’s guidance and adapt the lab by deploying into the approved private subnet.

Step 4: Create security rules for SSH and HTTP (least privilege)

You need two kinds of access:

SSH admin access to instances (from a controlled CIDR, often a jump host subnet)
HTTP access from the client instance to the web instance (internal only)

Choose one of these patterns (use what your environment supports):
A) Security Lists, or B) Network Security Groups (NSGs).

Option A: Security List approach (simple)

Go to your subnet’s Security List.
Add Ingress Rules: – Allow SSH:
- Source CIDR: your admin/jump CIDR (example: 192.168.50.0/24)
  Use your real admin CIDR; do not guess.
- Protocol: TCP
- Destination port: 22
- Allow HTTP from inside subnet:
- Source CIDR: 10.10.10.0/24
- Protocol: TCP
- Destination port: 80
Keep egress rules minimal (often default allow-all egress is acceptable for an isolated lab, but production should be tighter).

Option B: NSG approach (recommended for production patterns)

If NSGs are supported and enabled:

Create an NSG nsg-web allowing TCP/80 from nsg-client (or from subnet CIDR).
Create an NSG nsg-client with SSH rules as needed.
Attach NSGs to the respective instances.

Expected outcome – Network rules allow only the required access paths.

Verification – Review the effective rules and confirm: – Port 22 allowed only from admin/jump CIDR – Port 80 allowed only from the subnet (or client NSG)

Step 5: Generate an SSH key pair (on your admin workstation)

On your admin workstation (or jump host), generate a key:

ssh-keygen -t ed25519 -f ~/.ssh/ccoc_isolated_lab -C "ccoc-isolated-lab"

This creates: – Private key: ~/.ssh/ccoc_isolated_lab – Public key: ~/.ssh/ccoc_isolated_lab.pub

Expected outcome – You have an SSH public key to inject into instances.

Verification

ls -l ~/.ssh/ccoc_isolated_lab*
cat ~/.ssh/ccoc_isolated_lab.pub

Step 6: Launch the “web” compute instance

Go to Compute → Instances.
Click Create Instance.
Configure: – Name: web-01 – Compartment: lab-ccoc-isolated (or your sandbox) – Placement: accept defaults (availability/fault domain options vary) – Image: choose an approved Linux image available in your environment
(Oracle Linux is common; use what’s approved and available.) – Shape: choose a small shape suitable for a lab – Networking: attach to your private subnet (10.10.10.0/24) – Public IP: Disabled / none – SSH keys: paste the contents of ccoc_isolated_lab.pub
Create the instance.

Expected outcome – Instance web-01 is running with a private IP (for example, 10.10.10.10).

Verification – In instance details, note: – Lifecycle state: Running – Private IP address

Step 7: Launch the “client” compute instance

Repeat instance creation with:

Name: client-01
Same subnet
Same SSH key

Expected outcome – Instance client-01 is running with a private IP (for example, 10.10.10.11).

Verification – Confirm both instances are in Running state and have private IPs.

Step 8: Connect to the client instance (via jump host) and test reachability

How you SSH depends on your environment:

If you can SSH directly from your workstation to the private subnet (rare), use direct SSH.
More commonly, you SSH to a jump host first, then to the instance.

Example SSH (direct from a host that can reach the subnet)

ssh -i ~/.ssh/ccoc_isolated_lab opc@10.10.10.11

Usernames vary by image (for example opc, oraclelinux, ubuntu). Use the username documented for your selected image.

Expected outcome – You have shell access to client-01.

Verification

hostname
ip addr | grep "10.10.10"

Step 9: Install and start a web server on web-01

From client-01, SSH to web-01:

ssh -i ~/.ssh/ccoc_isolated_lab opc@10.10.10.10

Install a small HTTP server. Choose a method that works with your OS and your enclave’s package repository situation:

Option A (preferred): Use the approved package repository inside the enclave

For Oracle Linux (example; adjust if you use a different OS and repo):

sudo dnf -y install nginx
sudo systemctl enable --now nginx

Create a simple page:

echo "Hello from Compute Cloud@Customer Isolated: $(hostname)" | sudo tee /usr/share/nginx/html/index.html

Option B (fallback): Python HTTP server (no packages needed)

If you cannot install packages due to repo restrictions:

mkdir -p ~/webroot
echo "Hello from Compute Cloud@Customer Isolated: $(hostname)" > ~/webroot/index.html
cd ~/webroot
python3 -m http.server 8080

If you use port 8080, update security rules accordingly.

Expected outcome – web-01 is serving HTTP content on port 80 (or 8080).

Verification (on web-01)

curl -s http://127.0.0.1/ | head

Step 10: Test HTTP from client-01 to web-01 over private IP

Exit back to client-01 (or open another terminal on it), then:

curl -v http://10.10.10.10/

Expected outcome – You receive the “Hello from…” response. – The TCP connection succeeds without using any public IP.

Verification – Confirm curl output returns HTTP 200 (or a valid response if using Python server).

Validation

Use this checklist:

Instances running – web-01: running, private IP assigned – client-01: running, private IP assigned
SSH works – From jump/admin network to instances on port 22
HTTP works – client-01 can curl http://web-01-private-ip/
No public exposure – No public IPs assigned – Security rules do not allow 0.0.0.0/0 ingress on SSH/HTTP (unless your policy explicitly requires it, which is uncommon in isolated environments)

Troubleshooting

Issue: SSH timeout

Causes – Missing route between jump network and subnet – Security rule missing port 22 from correct source CIDR – OS firewall blocking SSH (less common on default images)

Fix – Confirm security rules: allow TCP/22 from your jump CIDR. – Confirm the subnet route and on-prem routing are correct (work with network team). – Verify instance is in correct subnet and has correct private IP.

Issue: “Permission denied (publickey)”

Causes – Wrong username for the OS image – Wrong key used – Key not injected properly

Fix – Verify correct username for image. – Confirm you used the matching private key (ccoc_isolated_lab). – Confirm the SSH public key in instance metadata (console).

Issue: HTTP connection refused

Causes – Web server not running – Wrong port – Security rules missing port 80 – OS firewall blocking port 80

Fix – On web-01: sudo systemctl status nginx – Confirm rules allow TCP/80 from subnet CIDR. – If using Python server on 8080, update rules and use correct URL.

Issue: No package repository access

Causes – In isolated environments, outbound internet repos are blocked (expected). – Internal mirror repo not configured.

Fix – Use the Python server method for the lab. – For production, implement an approved offline repository and signed artifact pipeline.

Cleanup

To avoid consuming capacity:

Terminate instances: – web-01 – client-01
Delete network resources (if created for the lab): – Subnet – VCN – NSGs/security list rules (if separate objects)
Delete the lab compartment (only if you created it and your org allows it).
Note: compartment deletion may require all resources to be fully removed first and may take time.

Expected outcome – No remaining instances, networks, or lab artifacts consuming capacity.

11. Best Practices

Architecture best practices

Design with private subnets by default; treat public ingress as an exception requiring formal approval.
Use a hub-and-spoke segmentation model:
Shared services in a platform compartment (repos, logging, CI runners)
Application compartments per team/environment
Build for rebuildability:
Golden images
Immutable infrastructure patterns where feasible
Avoid hidden dependencies on internet services (time servers, package repos, license servers). Provide internal equivalents.

IAM/security best practices

Use least privilege policies:
Separate network admins from compute admins where possible
Grant app teams rights only within their compartments
Use groups and policies, not individual grants.
Implement break-glass accounts with strong controls:
Separate credentials
Time-bound approval
Full auditing and post-incident review
Require MFA where supported and permitted.

Cost best practices

Enforce tagging: owner, cost-center, env, data-classification, app.
Build non-prod scheduling (stop/start) if your operational model allows it.
Track capacity usage as a finite resource:
Monitor free CPU/memory capacity
Avoid “VM sprawl” with quotas and approval gates

Performance best practices

Keep high-IO workloads close to their storage and within the same fault domain guidance (as supported).
Standardize baseline images with performance tooling (sysstat, tuned profiles).
Use consistent instance sizing and avoid “oversizing by default.”

Reliability best practices

Use multi-tier redundancy (multiple instances) where capacity allows.
Prepare for maintenance windows for platform upgrades (common in managed appliances).
Document and rehearse restore procedures (image-based rebuilds, backups).

Operations best practices

Maintain a “day-2 operations” runbook:
Provisioning standards
Patch cadence
Incident response
Capacity planning
Centralize logs locally; define retention and access.
Keep an internal mirror of required packages and dependencies.

Governance/tagging/naming best practices

Naming convention example:
{env}-{app}-{tier}-{index} → prod-payments-web-01
Tagging convention:
env=dev|test|prod
owner=email/team
data_class=public|internal|confidential|restricted
Use compartments to model environments and teams, and enforce guardrails with policies.

12. Security Considerations

Identity and access model

Use OCI-style IAM constructs:
Users, groups, policies, compartments
Integrate with enterprise IdP if supported in isolated mode—verify in official docs.
Apply separation of duties:
Platform/IAM admins
Network/security admins
Application operators

Encryption

Data-at-rest encryption depends on the platform’s storage implementation and enabled services.
For workloads:
Use OS-level disk encryption if required by policy (and operationally supported).
Use TLS for all internal service-to-service communication.
If key management services (like OCI Vault equivalents) are available in your deployment, use them; otherwise, rely on approved on-prem HSM/KMS solutions.

Because isolated deployments can differ, confirm encryption controls and compliance evidence paths in your specific documentation.

Network exposure

Default-deny inbound at subnet boundaries.
Avoid assigning public IPs (often disallowed anyway).
Use jump hosts with strict controls (session recording if required).
Implement micro-segmentation:
NSGs for app tiers
Restrictive security lists

Secrets handling

Do not store secrets in instance user-data or images.
Prefer:
Local secrets manager (if approved and available)
OS-level secure storage with strict permissions
Short-lived credentials where feasible
Rotate keys on a defined schedule, especially after staff changes.

Audit/logging

Ensure management-plane actions are audited.
Forward logs to a local SIEM/log platform.
Protect audit logs:
Restricted access
Immutable retention (WORM-like) if required

Compliance considerations

Compute Cloud@Customer Isolated is often selected to support: – Classified or sovereign controls – Restricted connectivity mandates – Strong chain-of-custody requirements

However, compliance is not automatic: – You still must configure IAM, networks, logging, patching, and evidence collection correctly. – Document control mappings (NIST, ISO, CIS, etc.) and validate with auditors.

Common security mistakes

Allowing 0.0.0.0/0 ingress “temporarily” and forgetting it
Using shared admin accounts
Skipping internal patch repo setup and allowing ad-hoc removable media processes
No break-glass process (or break-glass used routinely)
Missing asset inventory and ownership tags

Secure deployment recommendations

Enforce policy-as-code where possible (Terraform with internal pipelines, if permitted).
Require code review for IAM/network changes.
Use hardened images and CIS benchmarks where applicable.
Treat the isolated environment as a high-value enclave: minimum software, minimum ports, maximum logging.

13. Limitations and Gotchas

These are common constraints in isolated edge-cloud systems; validate specifics for your Compute Cloud@Customer Isolated deployment.

Known limitations (typical)

Finite capacity: You can’t instantly scale beyond installed hardware.
Service catalog differences: Not all OCI public region services may be present.
Operational procedures differ: Upgrades/patches may require scheduled windows and offline processes.
Dependency management: OS/package updates require internal mirrors.

Quotas

Instance count and resource limits per compartment/tenancy.
Network object limits (VCNs, subnets, rules).
Limits vary—verify in official docs.

Regional constraints

This is site-specific; there is no “switch to another OCI region” unless you have another installation.

Pricing surprises

Contract minimums and infrastructure fees may dominate costs more than usage.
Non-prod sprawl consumes finite capacity even if “metering” is not your primary cost driver.

Compatibility issues

Some third-party tools assume internet access (license checks, update servers).
Some agents require endpoints that may be blocked in isolated mode.

Operational gotchas

Time sync: ensure internal NTP is reliable.
Certificates: plan an internal PKI and rotation process.
DNS: avoid hardcoding IPs; ensure internal DNS is robust.
Patch pipeline: without internal repos, systems become unpatchable quickly.

Migration challenges

Exporting/importing images and data requires controlled transfer procedures.
App architectures with many external dependencies need redesign for offline operation.
Governance model changes (compartments/policies) may require training for traditional virtualization teams.

Vendor-specific nuances

Support workflows can differ in isolated mode (log bundles, offline diagnostics, controlled data exchange). Establish and test the support process early.

14. Comparison with Alternatives

Compute Cloud@Customer Isolated sits in a specific niche: OCI-like compute on premises with strong isolation requirements. Here’s how it compares at a high level.

Option	Best For	Strengths	Weaknesses	When to Choose
Compute Cloud@Customer Isolated (Oracle Cloud)	Air-gapped or strongly isolated OCI-style on-prem compute	OCI-aligned governance and APIs; local control plane; designed for restricted connectivity	Finite capacity; service catalog may differ from public OCI; contracted delivery and lead times	When isolation is non-negotiable and you want OCI-like operations on-prem
Oracle Cloud Compute (public OCI regions)	Elastic compute with broad OCI service ecosystem	Rapid scaling; managed services; global regions	Requires connectivity; data residency may be harder for certain constraints	When workloads can run in public cloud and need managed services
Oracle Dedicated Region Cloud@Customer	Full OCI region in customer location (broad service set)	Region-like experience on-prem; many OCI services	Larger footprint and complexity; may be overkill for “compute-only” needs	When you need a broad OCI service catalog on-prem and can support the footprint
Oracle Roving Edge Infrastructure	Rugged/portable edge compute	Portable edge use; local processing near data sources	Different operational model; not the same as Cloud@Customer	When you need portable edge compute rather than a data-center installation
AWS Outposts	AWS infrastructure on-prem	AWS consistency; integrated services	Service availability varies; connectivity requirements differ by design	When your org is standardized on AWS and needs on-prem extension
Azure Stack Hub / Azure Stack HCI	Microsoft on-prem cloud/hybrid	Strong Windows/AD integration; hybrid patterns	Different APIs/governance than OCI	When Microsoft ecosystem integration is primary
Google Distributed Cloud	Google-managed hybrid/edge	Designed for distributed environments	Service catalog and availability depends on offering	When aligned with Google hybrid strategy
Self-managed VMware / OpenStack	Traditional private cloud	Full control; no vendor lock-in to managed appliance	Higher ops burden; harder to match cloud governance consistency	When you need maximum control and can staff operations heavily

15. Real-World Example

Enterprise example: regulated government analytics enclave

Problem: A government organization must run analytics on sensitive datasets in a facility with no internet connectivity. They need standardized provisioning, access control, and auditable operations.
Proposed architecture:
Compute Cloud@Customer Isolated installed in the facility
Compartments for platform, dev, prod
Private subnets only; jump hosts with session controls
Internal artifact repositories for OS updates and tools
Central local SIEM receiving audit logs and OS logs
Why this service was chosen:
Provides OCI-like governance and automation inside a disconnected environment
Supports strong segmentation and auditable access control
Expected outcomes:
Faster environment provisioning with consistent controls
Reduced configuration drift through image-based rebuilds
Improved audit readiness due to standardized IAM and logging patterns

Startup/small-team example: manufacturing site with strict OT isolation

Problem: A small manufacturing company wants to run local dashboards and batch analytics on machine data but cannot allow broad internet connectivity from the production network.
Proposed architecture:
Compute Cloud@Customer Isolated hosts a small set of VMs:
- Data ingestion VM
- Analytics VM
- Dashboard VM
Segmented network between OT ingestion and IT viewer access
Offline update process with internal package mirror
Why this service was chosen:
The team needs cloud-like provisioning and governance without exposing OT networks to the internet
A managed on-prem cloud model reduces operational burden compared to building from scratch
Expected outcomes:
Lower latency analytics and improved production visibility
Stronger security posture via segmentation and controlled egress
Repeatable deployment patterns as additional sites are added (subject to procurement/capacity planning)

16. FAQ

1) Is Compute Cloud@Customer Isolated the same as public OCI Compute?

No. It is designed to provide OCI-like compute in a customer location, but service availability, scaling, and operations differ. Expect finite capacity and deployment-specific service catalogs.

2) What does “Isolated” mean in practice?

It generally means the environment is intended to operate without continuous connectivity to OCI public regions and with strict network egress controls. Confirm the exact isolation model for your deployment.

3) Do I get the same OCI console experience?

You typically get a local console/API experience aligned with OCI patterns, but exact UI and available services can differ by release.

4) Can I use OCI CLI and SDKs?

Often yes, against local endpoints—but configuration may differ from public OCI. Follow your deployment documentation for endpoint/region configuration.

5) Can I use Terraform?

Possibly, if the OCI APIs exposed in your environment are compatible and Terraform is approved in your enclave. Verify supported provider versions and endpoints.

6) Does it support compartments and IAM policies?

OCI-style governance is a common design goal. Confirm the IAM feature set and federation options in your deployment.

7) Can I assign public IPs?

In many isolated deployments, public IPs and internet gateways are restricted or disallowed. Design for private-only access unless your security policy allows otherwise.

8) How do OS updates work without internet access?

You typically need internal mirrors of OS repositories and a controlled artifact ingestion pipeline. Plan this early—it is a major operational dependency.

9) How do I monitor instances?

If platform monitoring services are included, use them. Otherwise use OS-level monitoring agents and local telemetry stacks (Prometheus, syslog, etc.) approved for the enclave.

10) How does scaling work?

You can scale within installed capacity. Scaling beyond that usually requires procurement and expansion of the on-prem footprint.

11) Is this a good fit for container platforms?

You can run containers on VMs you provision. Whether a managed Kubernetes service is available depends on the Cloud@Customer service catalog—verify in official docs.

12) What about backups and disaster recovery?

Backups depend on included storage services and your organization’s backup tooling. DR may require a second site or a defined restoration process within the same site.

13) How is security auditing handled?

Management-plane actions are typically auditable. You should also centralize OS and application logs locally and ensure retention and immutability as required.

14) How does support work in an isolated environment?

Support workflows may involve offline log bundles and controlled data exchange procedures. Establish the process and test it during onboarding.

15) Is Compute Cloud@Customer Isolated considered “Edge Cloud”?

Yes. It is an edge/on-prem deployment model in Oracle Cloud’s Cloud@Customer portfolio, commonly used for secure or low-connectivity environments.

16) Can I connect it to an OCI public region later?

Some organizations evolve from isolated to limited connectivity, but this is a policy and architecture decision. Treat it as “possible but not assumed”—verify supported connectivity models and compliance constraints.

17) What’s the first thing to plan?

Networking and identity: – Define compartment structure and policies – Define IP ranges and segmentation – Define admin access paths and jump hosts – Define offline patch/artifact flows

17. Top Online Resources to Learn Compute Cloud@Customer Isolated

Because Oracle documentation structure can change, use Oracle’s docs search for the most current Compute Cloud@Customer Isolated materials.

Resource Type	Name	Why It Is Useful
Official product overview	Oracle Cloud@Customer	High-level positioning and where Compute Cloud@Customer fits in Oracle Cloud@Customer portfolio. https://www.oracle.com/cloud/cloud-at-customer/
Official documentation portal	Oracle Cloud Infrastructure Documentation	Entry point for OCI docs; use search for “Compute Cloud@Customer” and “Isolated”. https://docs.oracle.com/en-us/iaas/
Official OCI CLI docs	OCI CLI Installation and Usage	How to install and use OCI CLI; adapt endpoint configuration for isolated environments per your deployment docs. https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
Official pricing	Cloud@Customer pricing	Starting point for official pricing model; Cloud@Customer is typically contract-based. Verify current details. https://www.oracle.com/cloud/cloud-at-customer/pricing/
Official pricing	Oracle Cloud Pricing	General OCI pricing concepts useful for understanding dimensions even when Cloud@Customer is contracted. https://www.oracle.com/cloud/pricing/
Official estimator	Oracle Cloud Cost Estimator	Helps structure estimation; confirm applicability to Cloud@Customer terms. https://www.oracle.com/cloud/costestimator.html
Architecture center	Oracle Cloud Architecture Center	Reference architectures and design principles (adapt for isolated connectivity constraints). https://www.oracle.com/cloud/architecture/
Terraform provider docs	OCI Terraform Provider	Useful if your environment supports Terraform automation. https://registry.terraform.io/providers/oracle/oci/latest/docs
Training (official)	Oracle University / OCI training	Official training paths and certifications for OCI concepts that apply to Cloud@Customer operational models. https://education.oracle.com/

18. Training and Certification Providers

The following providers are listed as external training resources. Availability, course accuracy, and alignment to Compute Cloud@Customer Isolated should be validated on each site.

DevOpsSchool.com – Suitable audience: DevOps engineers, platform teams, cloud beginners to intermediate – Likely learning focus: DevOps practices, cloud fundamentals, automation – Mode: Check website – Website URL: https://www.devopsschool.com/
ScmGalaxy.com – Suitable audience: SCM/DevOps learners, engineers seeking tooling knowledge – Likely learning focus: Source control, CI/CD, DevOps toolchain – Mode: Check website – Website URL: https://www.scmgalaxy.com/
CLoudOpsNow.in – Suitable audience: CloudOps/operations practitioners – Likely learning focus: Operations, monitoring, reliability, cloud operations – Mode: Check website – Website URL: https://www.cloudopsnow.in/
SreSchool.com – Suitable audience: SREs, operations teams, reliability-focused engineers – Likely learning focus: SRE principles, incident response, SLIs/SLOs – Mode: Check website – Website URL: https://www.sreschool.com/
AiOpsSchool.com – Suitable audience: Ops teams exploring AIOps concepts – Likely learning focus: AIOps tooling, automation, operational analytics – Mode: Check website – Website URL: https://www.aiopsschool.com/

19. Top Trainers

Listed as training resource platforms/sites. Verify specific trainer credentials and course relevance for Oracle Cloud and Compute Cloud@Customer Isolated.

RajeshKumar.xyz – Likely specialization: DevOps/cloud coaching (verify site specifics) – Suitable audience: Engineers seeking guided training – Website URL: https://rajeshkumar.xyz/
devopstrainer.in – Likely specialization: DevOps tools and practices training – Suitable audience: Beginners to intermediate DevOps learners – Website URL: https://www.devopstrainer.in/
devopsfreelancer.com – Likely specialization: Freelance DevOps services/training resources – Suitable audience: Teams seeking short-term help or coaching – Website URL: https://www.devopsfreelancer.com/
devopssupport.in – Likely specialization: DevOps support and training resources – Suitable audience: Ops/DevOps teams needing practical support – Website URL: https://www.devopssupport.in/

20. Top Consulting Companies

These are listed as consulting resources. Validate offerings, scope, and references directly with each company.

cotocus.com – Likely service area: Cloud/DevOps consulting (verify exact offerings) – Where they may help: Delivery planning, automation, CI/CD, operations processes – Consulting use case examples: IaC standardization, pipeline design, operational runbooks – Website URL: https://cotocus.com/
DevOpsSchool.com – Likely service area: DevOps consulting and training services – Where they may help: DevOps transformation, tooling implementation, skills development – Consulting use case examples: CI/CD rollout, infrastructure automation, observability practices – Website URL: https://www.devopsschool.com/
DEVOPSCONSULTING.IN – Likely service area: DevOps consulting services (verify exact offerings) – Where they may help: Platform engineering guidance, automation, cloud operations – Consulting use case examples: Deployment automation, monitoring/logging setup, SRE practices – Website URL: https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

OCI fundamentals – Compartments, IAM policies, networking concepts (VCN/subnets/security rules)
Linux administration – SSH, systemd, package management, firewall basics
Networking – CIDR, routing, DNS, load balancing fundamentals
Security basics – Least privilege, segmentation, audit logging, key management
Automation – CLI usage, Terraform basics (if allowed), configuration management basics

What to learn after this service

Golden image pipelines – Patching, hardening, image versioning, rollback strategy
Offline software supply chain – Artifact signing, SBOMs, vulnerability scanning, curated repositories
Observability in isolated environments – Local metrics/logging stacks, alerting, retention design
Resilience engineering – Capacity planning for finite hardware, maintenance windows, DR drills
Policy-as-code and governance – Automated compliance checks, drift detection

Job roles that use it

Cloud/Platform Engineer (Edge/On-Prem Cloud)
DevOps Engineer (restricted environments)
Site Reliability Engineer (SRE)
Cloud Security Engineer / Security Architect
Infrastructure Architect / Solutions Architect
Operations Lead for regulated enclaves

Certification path (if available)

Oracle certifications generally focus on OCI public cloud fundamentals and architectures. Those skills often transfer conceptually to Cloud@Customer.
Start with Oracle University OCI training and verify current certification tracks:
https://education.oracle.com/

Project ideas for practice

Build a compartment and network baseline module (Terraform if supported).
Create a hardened golden image and a rebuild pipeline.
Implement a local OS repository mirror and signed update workflow.
Create a “private-only” reference architecture for a 3-tier app with strict NSG rules.
Build an internal monitoring/logging stack and document incident runbooks.

22. Glossary

Cloud@Customer: Oracle’s portfolio for deploying Oracle Cloud infrastructure/services in a customer-controlled location.
Compute Cloud@Customer Isolated: A Cloud@Customer compute offering designed for isolated/disconnected operations (verify exact scope for your deployment).
Compartment: OCI governance boundary used to organize resources and apply IAM policies.
IAM Policy: Authorization rule describing who can do what on which resources.
VCN (Virtual Cloud Network): OCI virtual networking construct for isolating IP spaces and subnets (availability depends on deployment).
Subnet: A CIDR range within a VCN where instances are placed.
Security List / NSG: Network access control constructs to allow/deny traffic at subnet/instance level.
Jump Host / Bastion: Controlled host used to access private instances without exposing them publicly.
Golden Image: A standardized, patched, hardened base image used to launch instances consistently.
Air-gapped: Physically or logically isolated from external networks, especially the internet.
Management plane: APIs/console used to create and manage resources.
Data plane: Actual workload traffic flowing between applications and users/systems.

23. Summary

Compute Cloud@Customer Isolated (Oracle Cloud, Edge Cloud category) brings OCI-style compute provisioning and governance into a customer-controlled location designed for isolated or disconnected operations. It matters when regulatory, sovereignty, or mission constraints prevent the use of public cloud regions, but teams still need cloud-like automation, segmentation, and policy-based access control.

Architecturally, it fits as a secure “on-prem cloud” boundary: private subnets, strict ingress controls, local endpoints, and offline-first operational design (repos, patching, logging). Cost planning is contract-driven and must account for finite capacity, facility and operations overhead, and lifecycle processes unique to isolated environments. Security success depends on least-privilege IAM, micro-segmentation, hardened images, strong audit logging, and well-tested break-glass/support procedures.

If your primary requirement is strict isolation with a cloud operating model on premises, Compute Cloud@Customer Isolated is a strong candidate. Next, validate your deployment’s supported service catalog and runbooks in the official documentation and perform a small pilot like the private web lab in this tutorial to confirm networking, access, and offline operations end-to-end.

rajeshkumar

Category