Oracle Cloud at Customer Gen1 Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Other Services

1. Introduction

Cloud at Customer Gen1 is an Oracle Cloud service designed to run Oracle-managed cloud infrastructure inside your own data center. It exists for organizations that need cloud operating models (self-service, elastic capacity within a footprint, metering, standard APIs) while keeping workloads and data on-premises for latency, residency, or regulatory reasons.

In simple terms: Oracle delivers cloud hardware to your site, Oracle operates it as a cloud, and your teams consume it like Oracle Cloud—but the servers are physically in your building.

Technically, Cloud at Customer Gen1 is an on-premises cloud platform delivered as an engineered system (hardware + software + operations processes) that exposes a defined catalog of Oracle Cloud services through cloud-style interfaces. Oracle is typically responsible for infrastructure lifecycle (patching, break/fix, capacity planning according to contract), while the customer controls tenants/projects, workloads, identities, network segmentation, and application operations.

It solves a very specific problem: how to get cloud-like agility and standardization when you cannot (or should not) move certain systems to a public cloud region—without building and operating a full private cloud stack yourself.

Important status note (read first): Oracle has evolved its “Cloud@Customer” portfolio over time. In many environments, Cloud at Customer Gen1 is considered a legacy/earlier generation offering relative to newer OCI-based Cloud@Customer services (for example, Compute Cloud@Customer and Exadata Cloud@Customer). Availability for new purchases, service catalog, console/CLI experience, and integrations can vary by contract and deployment vintage. Verify the current status and exact capabilities for your tenancy in official Oracle documentation and with Oracle support/sales.

2. What is Cloud at Customer Gen1?

Official purpose

The purpose of Cloud at Customer Gen1 is to provide Oracle Cloud services delivered on-premises—allowing customers to meet data locality, latency, and compliance needs while still adopting a cloud consumption model.

Core capabilities (high-level)

Capabilities depend on what Oracle provisioned for your site and what your contract includes, but commonly center around:

On-premises cloud infrastructure (compute, networking, storage) operated in a standardized way
Self-service provisioning of cloud resources through a console and/or APIs
Tenant/project-style isolation so multiple teams can share the platform
Metering and subscription-based consumption (contract-defined)
Oracle-operated infrastructure lifecycle (patching/break-fix per contract)

Because Cloud at Customer Gen1 is an on-prem deployed service, the exact “service catalog” is not always identical to what is available in a public Oracle Cloud region. Verify in official docs which services and limits apply to your specific Cloud at Customer Gen1 installation.

Major components

A typical Cloud at Customer Gen1 deployment includes:

On-prem hardware footprint (racked systems in customer facility)
Virtualization / cloud control plane (management services that expose APIs/console)
Network integration into the customer’s LAN/WAN (routing, firewall, DNS, NTP)
Identity integration (often federated with enterprise IdP)
Operations tooling (monitoring/alerts/logging, plus Oracle support access paths)

Service type

Type: On-premises managed cloud service (Oracle-managed infrastructure, customer-managed workloads)
Delivery model: Engineered system installed at customer site
Consumption model: Subscription/contract, typically capacity-based plus service terms

Scope (how you should think about it)

Cloud at Customer Gen1 is not “regional” in the public-cloud sense; it is site-scoped:

Site-scoped: The platform is deployed to a specific data center location (or a pair, depending on contract).
Tenant/account scoped: Access is usually controlled through an Oracle Cloud account/tenant model.
Network-scoped: All traffic is within your site unless you explicitly connect it to other networks or to Oracle Cloud services.

How it fits into the Oracle Cloud ecosystem

Cloud at Customer Gen1 is part of Oracle Cloud’s “Other Services” category because it is primarily a delivery and operating model for cloud services rather than a single discrete service like object storage or a database. It is most often used to:

Keep sensitive/regulated workloads on-prem while adopting Oracle Cloud patterns
Provide a stepping stone for modernization and cloud operating model adoption
Integrate with Oracle’s broader cloud portfolio (where supported), such as identity federation, monitoring, and hybrid networking

3. Why use Cloud at Customer Gen1?

Business reasons

Data residency and sovereignty: Keep data physically within a specific facility/country boundary.
Regulatory compliance: Support regulated workloads that cannot move to a public cloud region.
Risk management: Reduce dependency on WAN connectivity for mission-critical systems.
Contracting and procurement alignment: Some enterprises prefer cap/term-based on-prem contracts instead of pure usage-based public cloud.

Technical reasons

Low latency: Place compute close to factory floors, trading systems, hospital systems, or other latency-sensitive environments.
Predictable performance: Dedicated on-prem footprint reduces noisy-neighbor effects common in shared public regions (though multi-tenant internal contention still exists).
Hybrid architecture enablement: Keep “system of record” on-prem while integrating with cloud-native services where allowed.

Operational reasons

Oracle-managed infrastructure: Offload portions of infrastructure lifecycle to Oracle (hardware break/fix, patching processes—contract-defined).
Standardization: Provide a consistent, cloud-like environment to multiple teams without building a private cloud platform from scratch.

Security and compliance reasons

Physical control: Systems remain in your facility with your physical security controls.
Network control: You define routing, firewalling, and segmentation in alignment with enterprise security policies.
Audit alignment: Logs and data can be retained on-prem to satisfy audit retention rules.

Scalability and performance reasons

Local scaling within the footprint: Scale workloads without waiting for new data center builds (within contracted capacity).
Deterministic network paths: Internal routing can be tuned for east-west traffic and application tiers.

When teams should choose it

Choose Cloud at Customer Gen1 when you need:

Cloud self-service and governance on-prem
Strong constraints on where data can be stored/processed
Very low latency to on-prem systems
A managed approach (Oracle operates infrastructure components) rather than full DIY private cloud

When teams should not choose it

Avoid or reconsider Cloud at Customer Gen1 when:

You want rapid global expansion across many geographies (public regions are better)
Your workload is highly bursty and benefits from elastic hyperscale capacity
You lack facility readiness (power/cooling/space) or cannot support on-prem footprint
You need a broad set of modern cloud-native services not available in your Gen1 service catalog
(In this case, consider newer Oracle Cloud@Customer offerings or Oracle Cloud regions.)

4. Where is Cloud at Customer Gen1 used?

Industries

Cloud at Customer Gen1 tends to appear in industries with strict compliance and operational constraints:

Financial services (trading, risk, payments)
Government / public sector
Defense and controlled environments
Healthcare (patient data systems, imaging)
Telecommunications (network functions, OSS/BSS)
Manufacturing (plant-floor systems and OT integration)
Energy and utilities (SCADA-adjacent data processing)

Team types

Platform engineering teams offering internal cloud platforms
Enterprise infrastructure teams modernizing data centers
Security engineering teams enforcing locality controls
SRE/operations teams needing deterministic performance
DevOps teams modernizing CI/CD for on-prem workloads

Workloads

Line-of-business applications with strict data locality
Databases and middleware stacks that must stay on-prem (verify supported service catalog)
Legacy apps being containerized/modernized (depending on platform capabilities)
Batch processing where data gravity remains on-prem
Latency-sensitive APIs and analytics near data sources

Architectures

Three-tier application stacks entirely on-prem (web/app/db)
Hybrid: on-prem data tier with integration to external services
Shared internal cloud for multiple business units with segmentation
“Landing zone” pattern with standardized network/IAM/tagging

Real-world deployment contexts

A primary data center with a Cloud at Customer Gen1 footprint and enterprise WAN integration
A regulated site where data must never leave the facility
A modernization program that cannot move to public cloud within the project timeline

Production vs dev/test usage

Production: common for regulated, latency-sensitive, or data-gravity workloads
Dev/test: used when dev/test must mirror production locality and controls, or when external connectivity is limited
(But many organizations keep dev/test in public cloud and reserve on-prem cloud capacity for production.)

5. Top Use Cases and Scenarios

Below are realistic scenarios where Cloud at Customer Gen1 can fit. Because on-prem catalogs differ by installation, treat service references as conceptual and verify in official docs what your Gen1 environment supports.

1) Regulated data processing on-prem

Problem: Data cannot leave a controlled facility due to regulation.
Why Cloud at Customer Gen1 fits: Provides cloud-style provisioning while keeping data physically on-prem.
Example: A government agency processes citizen records in an on-prem cloud environment with strict network isolation.

2) Low-latency apps tied to on-prem systems

Problem: Applications depend on millisecond-level latency to local systems (OT/legacy/mainframe gateways).
Why it fits: Compute runs in the same facility; network paths are local.
Example: A manufacturing execution system (MES) consumes sensor data and controls line equipment without WAN hops.

3) Cloud operating model for internal teams (private cloud alternative)

Problem: Teams need self-service, but IT cannot operate a full private cloud stack.
Why it fits: Oracle manages the underlying platform lifecycle (per contract).
Example: A large enterprise offers an internal portal/API for provisioning standardized VM stacks.

4) Data gravity: analytics near on-prem data stores

Problem: Moving petabytes of data to public cloud is slow, expensive, or prohibited.
Why it fits: Run compute near existing datasets.
Example: Telecom CDR analytics runs on-prem where raw data is generated and stored.

5) Compliance-driven isolation and audit retention

Problem: Audit requires logs and sensitive datasets to remain within a facility for a fixed period.
Why it fits: On-prem storage and logging retention can remain under local control.
Example: A bank retains security logs and database audit trails on-prem for multi-year retention.

6) Modernization bridge for legacy Oracle estates

Problem: Organization wants to modernize but cannot move core systems to public cloud yet.
Why it fits: Enables standardization and automation on-prem while planning future migration.
Example: A retailer modernizes deployment pipelines and infrastructure-as-code around on-prem cloud resources first.

7) Edge-adjacent workloads (but not full edge)

Problem: Needs local processing in a plant or controlled campus.
Why it fits: Provides a managed on-prem cloud footprint (though not as small as true edge devices).
Example: A utility runs forecasting workloads close to SCADA data collection systems.

8) Dedicated platform for shared services

Problem: Shared services (identity brokers, integration gateways) need stable, dedicated infrastructure.
Why it fits: Provides standardized VM/networking, controlled change windows.
Example: An enterprise runs API gateways and integration brokers on Cloud at Customer Gen1 for internal consumption.

9) Disaster recovery preparation with locality controls

Problem: Need DR plans that keep replicas on-prem and within compliance boundaries.
Why it fits: Supports on-prem architecture patterns; DR can be designed within permitted boundaries.
Example: A healthcare provider uses a second controlled site for DR (subject to contract and design).

10) Security-constrained environments with restricted internet access

Problem: Site cannot allow outbound internet for production systems.
Why it fits: On-prem control plane and local network controls can operate in restricted mode (implementation-specific).
Example: A defense contractor runs workloads in a segmented environment with strict egress control.

11) Standardized “landing zone” for multiple business units

Problem: Multiple teams need isolated environments with shared governance.
Why it fits: Tenant/project and network segmentation support internal multi-tenancy.
Example: A conglomerate creates separate compartments/projects for each subsidiary with consistent tagging and policy.

12) Predictable cost model for fixed-capacity needs

Problem: Finance prefers predictable subscription costs rather than variable public-cloud spend.
Why it fits: On-prem capacity and term contracts can improve predictability.
Example: A public institution budgets annual spend for on-prem cloud capacity for fixed workloads.

6. Core Features

Because Cloud at Customer Gen1 is delivered as an on-prem system, “features” often combine platform capabilities and operational model. Exact feature availability is deployment- and contract-dependent. The items below reflect commonly expected characteristics; verify in official docs for your environment.

1) On-premises deployment of Oracle Cloud services

What it does: Runs Oracle-provided cloud infrastructure within your data center.
Why it matters: Meets locality and latency requirements.
Practical benefit: Keep regulated data on-prem without giving up cloud-style provisioning.
Caveats: Capacity is limited to installed footprint; expansion requires procurement and delivery lead time.

2) Oracle-managed infrastructure operations (contract-defined)

What it does: Oracle handles certain lifecycle tasks (hardware break/fix, platform patching, platform health checks).
Why it matters: Reduces operational burden compared to DIY private cloud.
Practical benefit: Platform team focuses more on app enablement than on low-level hardware maintenance.
Caveats: Patch windows and operational responsibilities are governed by contract and change management.

3) Self-service provisioning via console and APIs

What it does: Enables users to create/manage cloud resources using a UI and/or programmatic interfaces.
Why it matters: Enables DevOps automation and faster delivery.
Practical benefit: Repeatable provisioning and standardized environments.
Caveats: API compatibility may differ from OCI public regions (Gen1 vs Gen2 differences). Verify tooling support.

4) Tenant/project-style isolation and governance

What it does: Separates resources by organizational boundaries.
Why it matters: Enables safe multi-team sharing.
Practical benefit: Delegated administration with guardrails.
Caveats: Governance model depends on identity integration and the platform’s IAM constructs.

5) Network segmentation and security controls

What it does: Supports isolated networks/subnets and security rules to control east-west and north-south traffic.
Why it matters: Segmentation is foundational for compliance and secure architectures.
Practical benefit: Build multi-tier architectures with controlled traffic flows.
Caveats: Feature names and constructs vary by Gen1 platform version; coordinate with network/security teams.

6) Metering/usage reporting (subscription consumption)

What it does: Tracks consumption against contracted capacity or metered usage depending on agreement.
Why it matters: Enables chargeback/showback and capacity planning.
Practical benefit: Helps internal platform teams allocate costs to business units.
Caveats: Metering granularity and export options vary; confirm reporting capabilities.

7) Integration with enterprise identity (federation)

What it does: Allows centralized authentication/authorization patterns (for example, SSO).
Why it matters: Reduces credential sprawl and improves auditability.
Practical benefit: Joiners/movers/leavers processes align with corporate identity governance.
Caveats: Federation methods vary; validate supported IdPs and protocols.

8) Support and escalation path with Oracle

What it does: Provides vendor support for the platform (hardware/software) via Oracle support processes.
Why it matters: Critical for on-prem managed services—especially incidents and patching.
Practical benefit: Clear ownership for platform-level issues.
Caveats: Ensure your RACI is documented: what Oracle supports vs what your team owns.

9) Hybrid connectivity patterns (environment-dependent)

What it does: Enables connectivity to other on-prem sites or (where supported) to Oracle Cloud services/regions.
Why it matters: Most enterprises are hybrid.
Practical benefit: Integrate on-prem cloud workloads with external services (CI/CD, logging, backup, identity).
Caveats: Connectivity patterns (VPN, private circuits) and supported endpoints are contract and design specific.

7. Architecture and How It Works

High-level architecture

Cloud at Customer Gen1 can be understood as three planes:

Data plane: Where your workloads run (VMs/instances, storage, virtual networks).
Control plane: APIs, console, orchestration, IAM enforcement, metering.
Operations plane: Monitoring, logging, patching, hardware management, support access paths.

Request/data/control flow (typical)

A user or pipeline authenticates to the Cloud at Customer Gen1 console/API endpoint.
IAM policies/roles determine what actions are allowed.
The control plane schedules provisioning actions (create instance, attach volume, configure network rules).
The data plane executes: compute hosts allocate CPU/RAM, storage allocates volumes, networking programs virtual switches/routers.
Operational telemetry (health, metrics, logs) is captured by platform tooling and, if configured, forwarded to enterprise monitoring/SIEM.

Integrations with related services (common patterns)

Integrations vary widely, but common enterprise patterns include:

Identity provider (IdP): SSO using enterprise identity
DNS/NTP: Corporate DNS and time services
Enterprise monitoring: Central monitoring/SIEM (syslog forwarders, agents, log collectors)
CI/CD: Build systems deploying to on-prem endpoints
ITSM: Change/incident workflows tied to platform operations

Dependency services

A production Cloud at Customer Gen1 environment depends on:

Facility readiness (power, cooling, rack space)
LAN/WAN connectivity and routing
Firewall rules and security zones
IP addressing plan and DNS
Identity integration
Oracle support connectivity method (implementation-specific)

Security/authentication model (conceptual)

Authenticate via local identity store or federated enterprise identity (implementation-specific)
Authorize actions via roles/policies scoped to tenant/project boundaries
Audit user and API activity for governance

Networking model (conceptual)

One or more virtual networks with subnets mapped to security zones
Security rules controlling ingress/egress between subnets and to external networks
North-south connectivity through enterprise firewalls
Optional connectivity to other sites or Oracle Cloud (where supported)

Monitoring/logging/governance considerations

Define platform SLOs and incident processes: what is Oracle-owned vs customer-owned
Centralize logs into a SIEM and align retention with compliance rules
Monitor capacity: compute, storage, IP pools
Standardize tags/labels for cost allocation and ownership

Simple architecture diagram (Mermaid)

flowchart LR
  U[Users / CI-CD] -->|SSO/API| CP[Cloud at Customer Gen1\nControl Plane (on-prem)]
  CP --> DP[Data Plane: Compute/Storage/Network\n(on-prem)]
  DP --> APP[Applications/Workloads]
  DP -->|Logs/Metrics| MON[Monitoring & Logging\n(on-prem or integrated)]
  CP -->|Metering/Reports| FIN[Chargeback/Showback]
  DP <-->|LAN/WAN| NET[Enterprise Network\n(FW/DNS/NTP)]

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph DC[Customer Data Center]
    subgraph SECZ[Security Zones]
      subgraph DMZ[DMZ Subnet]
        LB[Load Balancer / Reverse Proxy\n(customer-managed)]
      end
      subgraph APPZ[App Subnet]
        APP1[App Instances]
        APP2[App Instances]
      end
      subgraph DATAZ[Data Subnet]
        DB[(Database / Data Stores\n(as supported))]
        VOL[Block/Local Storage\n(as supported)]
      end
    end

    subgraph CACC[Cloud at Customer Gen1 Platform]
      CP2[Control Plane APIs & Console]
      IAM[IAM / Federation Endpoint\n(implementation-specific)]
      OPS[Ops Tooling: Monitoring/Logging\n+ Oracle Support Channel]
      HV[Compute Hosts / Hypervisors]
      VNET[Virtual Networking\n(subnets, routing, security rules)]
      CP2 --> HV
      CP2 --> VNET
      HV --> APP1
      HV --> APP2
      VOL --> APP1
      VOL --> APP2
      DB --- VOL
    end

    NET2[Enterprise FW/Router/DNS/NTP]
  end

  USERS[Corporate Users & CI/CD Runners] --> NET2 --> CP2
  USERS --> NET2 --> LB
  LB --> APP1
  LB --> APP2
  APP1 --> DB
  APP2 --> DB
  OPS --> SIEM[Central SIEM / Log Lake\n(optional)]

8. Prerequisites

Because Cloud at Customer Gen1 is installed on customer premises and typically sold via contract, prerequisites are more about organizational readiness than clicking “Sign up”.

Account/subscription/tenancy requirements

An active Oracle Cloud contract covering Cloud at Customer Gen1
A provisioned environment (hardware installed and commissioned)
A tenant/account and administrative access model established by Oracle and your organization

Permissions / IAM roles

You typically need (names vary by deployment):

A platform administrator role to:
Create projects/tenants/compartments (as applicable)
Manage networks/subnets/security rules
Create and manage compute resources
A security admin/auditor role to:
View audit logs
Configure log forwarding (if supported)
A billing/finance role to:
Access usage/metering reports

Verify in official docs the exact IAM roles and policy constructs for Cloud at Customer Gen1.

Billing requirements

Cloud at Customer Gen1 is generally not a click-to-enable pay-as-you-go service.
Expect a negotiated contract that covers:
Hardware footprint and term
Operational responsibilities
Support levels
Expansion terms

CLI/SDK/tools needed

Tooling differs by generation and deployment. Common needs:

SSH client for instance access
Enterprise certificate tools (if TLS interception/corporate PKI is involved)
Infrastructure automation tooling used by your org (Ansible, Terraform, etc.), if supported
Oracle-provided console/API endpoint access

If you plan to use Terraform/CLI, first confirm that your Cloud at Customer Gen1 environment supports the same providers and endpoints as OCI public regions. If not, use the supported APIs/tools documented for Gen1.

Region availability

Cloud at Customer Gen1 is site-specific, not region-specific.
Availability depends on Oracle sales and delivery in your geography and the current product status. Verify with Oracle.

Quotas/limits

Expect limits around: – Total compute capacity (cores/RAM) – Storage capacity (block/object as available) – IP address pools / VLANs / subnet counts – Maximum instances per project – API rate limits

Exact quotas are deployment-specific.

Prerequisite services

Usually required in the customer environment: – DNS and NTP sources – IP plan and routing – Firewall rules (north-south and management) – Identity federation readiness (optional but recommended) – A monitoring/logging strategy (on-prem collectors or integrations)

9. Pricing / Cost

Cloud at Customer Gen1 pricing is usually contractual and negotiated, not a simple public price-per-hour page. The most accurate sources are:

Oracle pricing entry points: https://www.oracle.com/cloud/pricing/
Oracle Sales / your Oracle account team (for Cloud@Customer contract SKUs)
Your ordering documents and service descriptions (authoritative for what you purchased)

Pricing dimensions (typical for on-prem managed cloud)

While exact SKUs vary, Cloud at Customer Gen1 cost is commonly shaped by:

Installed capacity (compute and storage footprint)
Subscription term length
Support level and operational scope
Expansion options (adding racks/nodes/storage shelves)
Optional services (connectivity, additional environments, specialized compliance)

Free tier

Cloud at Customer Gen1 typically does not align with Oracle Cloud Free Tier due to on-prem hardware delivery.
(Free tier may still apply to some public Oracle Cloud services you integrate with, but not to the on-prem appliance itself.)

Primary cost drivers

Capacity you must provision upfront: Unlike public cloud elasticity, you pay for (or commit to) an on-prem footprint.
Environment count: Dev/test + staging + prod footprints can multiply cost if physically separated.
High availability requirements: Redundancy across rooms/sites affects footprint.
Support and operational scope: The more Oracle manages, the higher the service component may be.

Hidden or indirect costs (don’t miss these)

Facilities: rack space, power, cooling, and possibly raised-floor requirements
Network: switches/ports, firewall capacity, load balancers, cabling
People/process: change management, incident management, patch coordination
Security: SIEM ingest/storage costs, vulnerability scanning, endpoint protection agents
Backup/DR: off-platform backup storage or secondary site costs

Network/data transfer implications

Internal (on-prem) traffic is typically not “metered” like public cloud egress, but you still pay for:
WAN circuits
Firewall throughput licensing
Load balancer capacity
If you integrate with public Oracle Cloud services, your WAN/provider costs and any public-cloud network charges may apply. Verify with Oracle for any specific interconnect billing.

Storage/compute/API factors

If your contract includes metering, costs may correlate to:
number of vCPUs/cores allocated
storage GB provisioned
snapshots/backups retained
If your contract is fixed-capacity, costs correlate to:
committed footprint regardless of utilization (underutilization becomes the “cost”)

How to optimize cost (practical)

Right-size environments: Don’t mirror production footprint for dev/test unless required.
Implement cleanup automation: Stop/delete non-production instances and reclaim storage.
Tag for ownership: Enforce owner/cost-center tags and implement chargeback/showback.
Capacity governance: Set quotas per team/project to avoid resource hoarding.
Plan expansions carefully: Align expansion lead time with roadmap; avoid emergency expansions.

Example low-cost starter estimate (conceptual)

Because exact prices are negotiated, a “starter estimate” should be framed as a method:

Identify minimum footprint for: – baseline management overhead – one non-prod environment – one small prod workload
Add facilities and network costs.
Add operational staffing and monitoring/SIEM costs.
Compare against a public Oracle Cloud region equivalent for the same workload profile.

Do not assume you can start at a tiny monthly spend; on-prem managed cloud usually has a meaningful minimum commitment.

Example production cost considerations (conceptual)

For production, include:

N+1 capacity overhead
Security zone separation and firewall throughput
Log retention and SIEM indexing costs
Backup storage and restore testing
DR approach (secondary site vs other method)
Patch windows and change overhead (time cost)

10. Step-by-Step Hands-On Tutorial

This lab is designed to be realistic and executable in a Cloud at Customer Gen1 environment, but it cannot be “one-click” like a public cloud lab because Cloud at Customer Gen1 requires an on-prem installation and account provisioning.

To keep the lab practical, we’ll focus on a universal pattern that exists across most cloud platforms: provision a small compute instance, restrict network access, connect via SSH, attach/mount storage (if available), and validate.

Console and API labels vary across Cloud at Customer Gen1 deployments and vintages. Where names differ, use the closest equivalent in your environment and verify in official docs for your specific console.

Objective

Provision a small Linux instance on Cloud at Customer Gen1, secure it with least-privilege network rules, connect via SSH, optionally attach a block volume (if supported), and validate access and basic operations.

Lab Overview

You will:

Confirm access to the Cloud at Customer Gen1 console/API endpoint.
Create or select a project/compartment (as applicable).
Create a network/subnet and a minimal SSH-only security rule.
Launch a Linux instance.
Connect via SSH and harden basic access.
(Optional) Attach and mount a block volume.
Validate network and storage.
Clean up resources.

Step 1: Confirm access and identify your environment endpoints

What you do 1. Obtain from your platform administrator: – Cloud at Customer Gen1 console URL – API endpoint (if you will automate) – Your user credentials or SSO instructions – Your assigned project/tenant/compartment 2. Log in to the console.

Expected outcome – You can access the Cloud at Customer Gen1 console and view at least one landing page listing services/resources.

Verification – Confirm you can reach the console URL from your workstation network. – Confirm your user is shown in the profile menu and you can see your assigned scope.

Common issues – If the console is not reachable: check VPN, firewall rules, DNS resolution, and whether the console is only accessible from a management subnet.

Step 2: Create a project/compartment (or select an existing one)

What you do – If your organization uses compartments/projects: 1. Create a new one for this lab, for example: – Name: lab-cacc-gen1 – Description: Hands-on lab resources 2. Apply required tags/labels (owner, cost center, environment).

Expected outcome – A dedicated scope exists where you can safely create and delete resources.

Verification – Navigate to the scope and confirm it is selected as the active context.

Common issues – Permission denied: request a role that allows creating projects/compartments, or ask an admin to create it for you.

Step 3: Create a subnet and a minimal SSH security rule

This step enforces a key operational habit: never expose SSH to the entire corporate network (or worse, the internet) unless required.

What you do 1. Navigate to the networking section (often “Networking”, “Virtual Networks”, or similar). 2. Create a network (if required) and a subnet: – Network name: lab-net – Subnet name: lab-subnet – CIDR: choose an unused range in your enterprise IP plan (for example 10.50.10.0/24) 3. Create security rules (security list / security group / firewall rules—terms vary): – Inbound: TCP 22 (SSH) from your workstation IP (recommended) or a small admin subnet – Outbound: allow required egress to OS package repositories only if your policy permits (in restricted environments, use internal mirrors)

Expected outcome – A subnet exists and has security rules that only allow SSH from approved sources.

Verification – Confirm the security rule shows the correct source CIDR and port. – Confirm no broad 0.0.0.0/0 inbound SSH rule exists.

Common issues – Can’t choose CIDR due to overlap: coordinate with network team; use an approved address block. – SSH blocked by enterprise firewall: request a rule from your workstation to the subnet.

Step 4: Generate an SSH key pair (client-side)

On your workstation:

ssh-keygen -t ed25519 -C "cacc-gen1-lab" -f ~/.ssh/cacc_gen1_lab

Expected outcome – You have: – Private key: ~/.ssh/cacc_gen1_lab – Public key: ~/.ssh/cacc_gen1_lab.pub

Verification

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

Common issues – Permission warnings later: ensure your private key is not group/world readable:

chmod 600 ~/.ssh/cacc_gen1_lab

Step 5: Launch a small Linux compute instance

What you do 1. Go to Compute (or Instances/VMs). 2. Click Create Instance. 3. Choose: – Name: lab-vm-1 – Image: a supported Linux image (Oracle Linux or another supported distro) – Shape/flavor: smallest allowed for your environment (to reduce capacity use) – Network: lab-net / lab-subnet – SSH public key: paste contents of ~/.ssh/cacc_gen1_lab.pub 4. Create the instance.

Expected outcome – Instance transitions to a “Running” state. – You receive a private IP (and possibly no public IP, depending on design).

Verification – From the instance details page, capture: – Private IP address (e.g., 10.50.10.25) – Username for the image (often opc, oracle, or distro-specific—verify in image docs)

Common issues – Insufficient capacity/quota: request quota increase or use a smaller shape. – Image not available: your Gen1 catalog may be limited; choose an approved image.

Step 6: Connect to the instance via SSH

If your instance only has a private IP, ensure your workstation is on the right network/VPN or use a bastion host (preferred in enterprise designs).

SSH:

ssh -i ~/.ssh/cacc_gen1_lab <username>@<private-ip>

Example:

ssh -i ~/.ssh/cacc_gen1_lab opc@10.50.10.25

Expected outcome – You get a shell prompt on the VM.

Verification Run:

hostname
uname -a
ip addr

Common issues and fixes – Permission denied (publickey): ensure you used the correct username and the same public key was injected at provisioning time. – No route to host: check subnet routing, firewall rules, VPN, and that the VM is in “Running” state. – Timeout: check inbound rule (TCP 22) source CIDR and enterprise firewall.

Step 7: Apply basic hardening on the VM (safe defaults)

On the instance:

Update packages (use your enterprise-approved method; example below assumes yum/dnf):

sudo dnf -y update || sudo yum -y update

Confirm SSH settings align with policy (do not change without approval). Common checks:

sudo ss -lntp | grep :22 || true
sudo cat /etc/ssh/sshd_config | egrep -i 'passwordauthentication|permitrootlogin' || true

Expected outcome – OS is patched (or update attempt is blocked due to restricted egress, which is acceptable if you use internal repos).

Verification – Confirm package manager completes successfully or shows a clear policy-related error.

Common issues – No outbound internet: configure internal repo mirrors; allow outbound to approved repositories; or use golden images.

Step 8 (Optional): Create, attach, and mount a block volume

Whether this is available depends on the Cloud at Customer Gen1 service catalog and what your admin enabled.

What you do (conceptual) 1. In Storage, create a block volume: – Name: lab-vol-1 – Size: minimum allowed (for example, 50 GB—verify minimum) 2. Attach it to lab-vm-1 using the recommended attachment type for your platform.

On the VM: discover and mount 1. List block devices:

lsblk

Identify the new disk (example: /dev/sdb). Create a filesystem:

sudo mkfs.xfs /dev/sdb

Create mount point and mount:

sudo mkdir -p /mnt/labdata
sudo mount /dev/sdb /mnt/labdata
df -h /mnt/labdata

Persist mount (example using UUID):

sudo blkid /dev/sdb

Copy the UUID, then:

echo 'UUID=<your-uuid> /mnt/labdata xfs defaults,nofail 0 2' | sudo tee -a /etc/fstab
sudo mount -a

Expected outcome – Volume is attached and mounted at /mnt/labdata.

Verification

echo "hello from cacc gen1" | sudo tee /mnt/labdata/hello.txt
sudo cat /mnt/labdata/hello.txt

Common issues – Volume not visible: attachment not completed, wrong device path, or requires iSCSI steps (platform-specific). Verify in official docs for your attachment method. – Filesystem command missing: install xfsprogs or use ext4 if approved.

Validation

Use the checklist:

Console shows lab-vm-1 in Running state.
You can SSH to the VM from the approved source network.
VM has the expected IP configuration.
(Optional) Block volume is mounted and survives reboot.

Reboot test (optional):

sudo reboot

Then reconnect and verify:

df -h | grep /mnt/labdata || true

Troubleshooting

Symptom	Likely cause	Fix
SSH timeout	Security rule or enterprise firewall blocking	Restrictively allow TCP/22 from your IP/admin subnet; verify routing
Permission denied (publickey)	Wrong username or wrong key injected	Verify image username; re-create instance with correct public key
No package updates	No outbound access or no internal repos	Use enterprise mirrors; request egress to approved repos
Volume attach fails	Catalog limitation or wrong attachment type	Confirm storage service availability and supported attachment method
Can’t create instance	Quota/capacity exhausted	Use smaller shape, clean up resources, or request capacity/quota

Cleanup

To avoid consuming scarce on-prem capacity:

Unmount and detach optional volume: bash sudo umount /mnt/labdata || true
In console: – Detach and delete lab-vol-1 (if created) – Terminate/delete instance lab-vm-1 – Delete subnet/network lab-subnet / lab-net (if dedicated to the lab) – Delete project/compartment lab-cacc-gen1 if created for lab use and policy allows

Expected outcome – No lab resources remain and capacity is reclaimed.

11. Best Practices

Architecture best practices

Design for segmentation: Use separate subnets/security zones for DMZ/app/data tiers.
Use standardized landing zones: Define consistent IAM, network, logging, and tagging patterns before onboarding teams.
Plan for capacity constraints: Treat on-prem capacity as a finite pool; implement quotas and forecasting.
Treat the platform as cattle, workloads as pets only when necessary: Automate provisioning; avoid hand-crafted snowflakes.

IAM/security best practices

Least privilege: Roles should map to job functions (network admin, compute admin, auditor, developer).
Short-lived access: Prefer federated SSO and avoid shared accounts.
Separation of duties: Production network/security changes should require elevated roles and approvals.
Audit everything: Ensure management-plane actions are logged and reviewed.

Cost best practices

Chargeback/showback: Allocate capacity consumption to teams; prevent resource hoarding.
Non-prod governance: Enforce TTL labels and scheduled cleanup.
Right-size images and shapes: Standardize on a small set of approved sizes.
Monitor storage growth: Snapshots and orphaned volumes can accumulate.

Performance best practices

Place latency-sensitive tiers close together: Keep app/data tiers in the same on-prem fabric when required.
Use OS tuning and right storage classes: Verify performance characteristics of available storage.
Avoid chatty cross-zone traffic through firewalls: Design east-west flows efficiently while maintaining security.

Reliability best practices

Document RACI: Who handles what during incidents—Oracle vs your ops team.
Backups and restore testing: On-prem doesn’t automatically mean “backed up.”
Change management: Coordinate platform patch windows with app maintenance windows.
Capacity headroom: Keep buffer capacity for failover and emergency scaling.

Operations best practices

Centralize monitoring: Integrate host metrics/logs with enterprise monitoring and SIEM.
Golden images: Use hardened images and configuration management.
Runbooks: Create runbooks for common actions (provisioning, access requests, incident triage).
Patch compliance reporting: Track OS and application patch levels continuously.

Governance/tagging/naming best practices

Naming convention: Include environment, app, owner, and sequence (e.g., prd-payments-api-01).
Mandatory tags: owner, cost_center, environment, data_classification.
Policy as code (where possible): Standardize network/security baselines.

12. Security Considerations

Identity and access model

Prefer federated identity (SSO) integrated with enterprise IdP.
Avoid local user sprawl; enforce MFA where supported.
Use role-based access with clear scoping boundaries (project/tenant/compartment).

Encryption

In transit: Require TLS for console and API endpoints. Validate certificate trust chain and rotation process.
At rest: Storage encryption availability depends on the storage subsystem and platform configuration. Verify in official docs whether encryption at rest is enabled by default and whether customer-managed keys are supported.

Network exposure

Treat Cloud at Customer Gen1 management endpoints as high-value targets:
Place console/API endpoints on management networks
Restrict admin access by IP and strong authentication
Use bastion/jump hosts for SSH access to workloads
Avoid direct inbound exposure from untrusted networks.

Secrets handling

Do not store secrets in instance user-data, images, or repos.
Use your enterprise secrets manager (or an approved secrets system) and rotate credentials.
Audit access to secrets, and scope secrets to environment and application.

Audit/logging

Ensure management-plane actions (create/delete instances, modify security rules, attach volumes) are logged.
Forward logs to a centralized, immutable store per compliance needs.
Monitor for:
privilege escalation attempts
unusual provisioning spikes
repeated failed logins
changes to network/security policies

Compliance considerations

Map Cloud at Customer Gen1 controls to your compliance framework (ISO 27001, PCI DSS, HIPAA, etc.).
Confirm:
where logs are stored
who has physical access
how Oracle support access is controlled and audited
Maintain evidence: change tickets, patch reports, vulnerability scans.

Common security mistakes

Broad SSH exposure (0.0.0.0/0) or wide corporate ranges without justification
Shared administrator accounts
No central log collection
Not defining Oracle vs customer responsibilities (gaps in incident response)
Leaving orphaned volumes with sensitive data

Secure deployment recommendations

Create a hardened baseline:
standard network segments
default-deny inbound rules
egress control aligned with policy
Use golden images, CIS-aligned hardening (where applicable), and continuous scanning.
Implement mandatory tagging and ownership metadata to support incident response.

13. Limitations and Gotchas

Because Cloud at Customer Gen1 is an on-prem managed platform, you should expect differences compared to public cloud.

Known limitations (common patterns)

Finite capacity: You cannot instantly scale beyond installed footprint.
Service catalog differences: Not all Oracle Cloud services may be available. Verify in official docs for your Gen1 version.
Expansion lead time: Adding capacity is procurement + shipping + install.
Change windows: Platform updates may require coordination with Oracle and your operations team.

Quotas

Hard quotas around compute, storage, networks, and projects are common.
Some quotas may be contractual rather than self-service adjustable.

Regional constraints

Site-specific; resiliency across regions is not inherent unless you build multi-site designs.

Pricing surprises

Underutilization: paying for committed capacity even when idle
Facilities and operational overhead (power/cooling/logging/SIEM costs)
DR requirements: duplicating footprint for DR is expensive

Compatibility issues

Tooling mismatch if you assume OCI public region parity.
Image availability may be limited to approved/hardened images.

Operational gotchas

Network ownership ambiguity: enterprise firewall/routing changes can delay provisioning.
Patch coordination: platform and OS patch schedules must be aligned.
Access paths for Oracle support must be designed securely and audited.

Migration challenges

Moving from Gen1 to newer Cloud@Customer or OCI may require:
API/tooling changes
network redesign
re-creation of images and pipelines
data migration planning

Vendor-specific nuances

Clarify support boundaries: hardware vs hypervisor vs guest OS vs application.
Confirm what telemetry Oracle can access and how it is governed.

14. Comparison with Alternatives

Cloud at Customer Gen1 is one option in a broader landscape. The “best” choice depends on whether you want Oracle-managed on-prem, which services you need, and how closely you need to match public-cloud capabilities.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Oracle Cloud at Customer Gen1	Regulated/latency-sensitive on-prem workloads needing Oracle-managed platform	On-prem data locality, Oracle-managed infrastructure (contract-defined), cloud-like provisioning	Finite capacity, catalog/tooling differences vs OCI, may be legacy vs newer offerings	You already have Gen1 installed, or your program requires this exact platform and contract
Oracle Compute Cloud@Customer (newer)	OCI-style compute on-prem	OCI-aligned experience (often), clearer forward roadmap	Availability/capability depends on Oracle	When you want on-prem OCI-like compute and a newer platform direction
Oracle Exadata Cloud@Customer	High-performance Oracle Database on-prem with cloud operations	Strong DB performance, Oracle-managed Exadata ops	Database-centric; not general-purpose for all workloads	When the core need is Oracle Database performance + on-prem residency
AWS Outposts	AWS services on-prem	Tight AWS integration, consistent APIs with AWS	Service catalog constraints; vendor lock-in	When your org is AWS-centered and needs on-prem AWS services
Azure Stack Hub / Azure Stack HCI	Azure-consistent on-prem/hybrid	Azure integration and hybrid patterns	Complexity; service limitations	When Microsoft ecosystem alignment is primary
Google Distributed Cloud / Anthos (hybrid)	Kubernetes-centric hybrid	Strong K8s story, multi-cloud management	Operational complexity	When Kubernetes is the platform and you need hybrid consistency
VMware Cloud Foundation (self-managed)	Private cloud with VMware stack	Mature virtualization ecosystem	You operate it; cloud-like consumption is DIY	When you want maximum on-prem control and have VMware skills
OpenStack (self-managed)	Custom private cloud	Flexible and open	High operational overhead	When you need open/private cloud and can run a platform team

15. Real-World Example

Enterprise example: Regulated bank workloads with strict locality

Problem: A bank must keep certain customer and transaction datasets on-prem for regulatory reasons, but development teams need faster provisioning and standardized environments.
Proposed architecture:
Cloud at Customer Gen1 provides compute/network/storage on-prem.
Segmented subnets for DMZ/app/data with strict east-west rules.
Federated SSO with MFA for admin access.
Central log forwarding to the bank SIEM.
CI/CD deploys app tiers to on-prem instances; artifacts stored in an approved internal repo.
Why Cloud at Customer Gen1 was chosen:
Meets on-prem data residency requirements.
Provides self-service provisioning with governance.
Offloads hardware/platform operations to Oracle per contract.
Expected outcomes:
Faster environment provisioning (hours instead of weeks)
Improved audit posture (standardized logging and access control)
Reduced infrastructure maintenance burden for internal teams

Startup/small-team example: On-prem requirement due to customer contracts

Problem: A small SaaS team sells into regulated customers who require the SaaS to run in the customer’s facility.
Proposed architecture:
Deploy application stack on Cloud at Customer Gen1 in the customer site.
Use strict network segmentation; remote admin access only through bastion and customer VPN.
Automated provisioning scripts for repeatable deployments.
Why Cloud at Customer Gen1 was chosen:
Customer contract requires on-prem deployment and data locality.
Oracle-managed platform reduces the startup’s need to operate physical infrastructure.
Expected outcomes:
Ability to meet customer on-prem requirements with a repeatable platform approach
More predictable performance and reduced operational surprises compared to bespoke hardware builds

16. FAQ

Is Cloud at Customer Gen1 the same as Oracle Cloud regions?
No. Oracle Cloud regions are public cloud locations operated by Oracle. Cloud at Customer Gen1 is installed in your data center and is site-scoped.
Is Cloud at Customer Gen1 still available for new customers?
Availability can change as Oracle evolves its Cloud@Customer portfolio. Verify with Oracle sales and official documentation for current availability and recommended offerings.
What services are included in Cloud at Customer Gen1?
The service catalog varies by contract and deployment. Verify in official docs for your environment’s supported services.
Who manages the infrastructure?
Typically Oracle manages platform infrastructure tasks (per contract), while customers manage workloads, data, and configurations within their allowed scope.
Can I use Terraform with Cloud at Customer Gen1?
It depends on whether Gen1 exposes compatible APIs/providers. Verify in official docs and test in a non-production project.
How do I connect to instances if there’s no public IP?
Use enterprise routing/VPN and a bastion host/jump box pattern, or access via approved management networks.
What are the biggest cost drivers?
Contracted capacity/term, facilities (power/cooling/space), operational overhead, and DR/HA requirements.
Does Cloud at Customer Gen1 provide multi-site high availability?
Not automatically. HA/DR is an architecture you design, and it may require a second site and additional contracted capacity.
How is access audited?
Management-plane logging/auditing should be enabled and forwarded to a centralized audit store. Exact audit features depend on the platform version—verify in official docs.
Can we keep logs entirely on-prem?
Often yes, but exact log pipelines depend on what tooling is included and your integrations.
What’s the biggest operational gotcha?
Treating it like unlimited public cloud. Capacity is finite, and expansions take time.
Can Cloud at Customer Gen1 integrate with our SIEM?
Usually yes via log forwarding/agents, but the mechanism depends on your approved tooling and platform capabilities.
Do we need an internet connection?
Many sites run with restricted egress; you may need controlled connectivity for updates/support channels. Requirements vary—verify with Oracle.
How do patch windows work?
Platform patching and responsibilities are contract-defined. Coordinate patch windows with application maintenance.
Should we choose Gen1 or a newer Cloud@Customer offering?
For new projects, Oracle may recommend newer OCI-aligned Cloud@Customer options. If you already run Gen1, focus on secure operations and plan an evolution path. Verify with Oracle.

17. Top Online Resources to Learn Cloud at Customer Gen1

Because Oracle’s Cloud@Customer portfolio has multiple generations and offerings, start with Oracle’s Cloud@Customer hub and then follow product documentation relevant to your installed version.

Resource Type	Name	Why It Is Useful
Official product overview	https://www.oracle.com/cloud/cloud-at-customer/	Entry point to Oracle’s Cloud@Customer portfolio and positioning
Official documentation landing page	https://docs.oracle.com/en/cloud/	Starting point to locate Cloud@Customer and related docs
Official OCI documentation (context)	https://docs.oracle.com/en-us/iaas/Content/Index.htm	Useful for understanding OCI concepts that may apply in hybrid/adjacent designs
Official pricing entry point	https://www.oracle.com/cloud/pricing/	Official pricing hub (Cloud@Customer pricing is often contract-based)
Official Architecture Center	https://www.oracle.com/cloud/architecture-center/	Reference architectures and design guidance (hybrid patterns)
Official videos	https://www.youtube.com/@Oracle	Oracle’s official YouTube channel; search within for “Cloud@Customer”
Product pages for newer alternatives (for roadmap planning)	https://www.oracle.com/cloud/exadata-cloud-at-customer/	Helps compare Gen1 with newer Cloud@Customer offerings
Product pages for newer alternatives (for roadmap planning)	https://www.oracle.com/cloud/compute-cloud-at-customer/	Helps evaluate OCI-aligned on-prem compute options (availability varies)

If you need the exact Cloud at Customer Gen1 admin/user guides for your environment, use the documentation links provided in your customer support portal or from your Oracle account team, because Gen1 documentation can be version- and contract-specific.

18. Training and Certification Providers

The following training providers may offer DevOps, SRE, cloud, and platform engineering curricula that can complement Oracle Cloud and on-prem cloud operations. Availability of Cloud at Customer Gen1-specific training should be checked on their websites.

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, platform teams	DevOps, CI/CD, cloud fundamentals, automation	check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate engineers	SCM, DevOps tooling, build/release practices	check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud/ops practitioners	Cloud operations, monitoring, governance	check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, operations teams	Reliability engineering, incident response, observability	check website	https://www.sreschool.com/
AiOpsSchool.com	Ops/SRE leaders, automation engineers	AIOps concepts, event correlation, automation	check website	https://www.aiopsschool.com/

19. Top Trainers

These sites may provide trainer listings, corporate training, or independent trainer services. Verify Cloud at Customer Gen1 coverage directly with the provider.

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training content	Engineers seeking practical DevOps guidance	https://www.rajeshkumar.xyz/
devopstrainer.in	DevOps tooling and practices	Beginners to intermediate DevOps engineers	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps support/training	Teams needing short-term enablement	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and mentoring	Ops/DevOps teams needing hands-on help	https://www.devopssupport.in/

20. Top Consulting Companies

These consultancies may help with cloud adoption, DevOps, platform engineering, and operations—often relevant when deploying and governing on-prem cloud platforms.

Company Name	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting	Architecture, automation, platform engineering	Landing zone design, CI/CD rollout, monitoring strategy	https://cotocus.com/
DevOpsSchool.com	DevOps consulting and enablement	Training + implementation support	DevOps pipeline buildout, IaC practices, ops runbooks	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting	DevOps transformations and operations	Observability rollout, incident response processes, automation	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

To work effectively with Cloud at Customer Gen1, you should understand:

Linux administration (SSH, storage, networking, systemd)
IP networking fundamentals (subnets, routing, DNS, NAT, firewall rules)
Identity and access management (RBAC, SSO, MFA, least privilege)
Virtualization and basic cloud concepts (instances, images, volumes)
Operational fundamentals (monitoring, logging, incident/change management)

What to learn after this service

To grow beyond basic operations:

Infrastructure as Code (if supported): Terraform/Ansible patterns
Secure network architecture: segmentation, zero trust principles
Observability engineering: metrics, logs, traces; SIEM integration
Capacity management and FinOps: chargeback/showback, utilization optimization
Hybrid integration patterns: API management, message queues, private connectivity
Migration strategy: Gen1 to newer Oracle Cloud@Customer or to Oracle Cloud regions

Job roles that use it

Cloud/Platform Engineer (on-prem cloud)
DevOps Engineer supporting regulated environments
SRE for internal cloud platforms
Security Engineer for cloud governance and audit
Solutions Architect designing hybrid/on-prem cloud patterns
Operations Engineer managing capacity and reliability

Certification path (if available)

Oracle certification paths change over time. Start at Oracle’s official training portal and look for:

Oracle Cloud Infrastructure (OCI) foundations and architect tracks
Hybrid cloud and security courses

Then map that knowledge to your Cloud at Customer Gen1 deployment specifics.

Verify current Oracle certifications and learning paths on Oracle University: – https://education.oracle.com/

Project ideas for practice

Build a “golden image” pipeline for Linux VMs and validate CIS-aligned hardening
Implement a tagging policy and showback dashboard for internal teams
Create a standard three-tier reference deployment with restricted security rules
Design a logging pipeline from instances to a central SIEM with retention policy
Write runbooks for provisioning, incident triage, and capacity forecasting

22. Glossary

Cloud at Customer Gen1: Oracle Cloud offering delivered into a customer data center (first-generation), providing cloud-like services on-prem with Oracle-managed infrastructure aspects (contract-defined).
Control plane: The management layer (console/APIs) used to provision and govern resources.
Data plane: The layer where workloads run and data is processed (compute/storage/network).
Operations plane: Monitoring, logging, patching, support, and day-2 management processes.
Tenant/Project/Compartment: Logical boundaries for organizing and isolating resources (exact term varies).
Security zone / Subnet segmentation: Dividing networks into smaller trust boundaries to limit blast radius.
Bastion host (jump box): A controlled entry point used to access private instances securely.
Golden image: A standardized VM image with approved OS settings, agents, and hardening.
RACI: Responsibility assignment matrix clarifying who is Responsible/Accountable/Consulted/Informed.
Showback/Chargeback: Reporting (showback) or billing (chargeback) internal teams based on usage.
Finite capacity: On-prem capacity is limited to installed hardware; scaling requires expansion.

23. Summary

Cloud at Customer Gen1 (Oracle Cloud, Other Services) is an on-premises, Oracle-delivered cloud platform that brings cloud provisioning and governance into your data center. It matters when data residency, latency, or regulatory constraints prevent the use of public Oracle Cloud regions, but your teams still need cloud operating models and self-service.

Architecturally, treat it as a site-scoped cloud with distinct control/data/operations planes, strong segmentation requirements, and finite capacity. Cost is typically contract-based and driven by committed footprint, facilities, and operational overhead—so governance, quota management, and chargeback/showback are essential. Security success depends on least-privilege IAM, tight network exposure controls, centralized auditing, and clear RACI boundaries between Oracle and customer responsibilities.

Use Cloud at Customer Gen1 when on-prem constraints are real and enduring. If you are planning new deployments, also evaluate newer Oracle Cloud@Customer offerings for roadmap alignment—then validate capabilities, pricing, and tooling in official Oracle documentation and with Oracle representatives as your next step.

rajeshkumar

Category