OCI Foundations - Cloud Fundamentals and OCI Architecture¶

Table of Contents¶

Cloud Computing Fundamentals
Cloud Service Models
Cloud Deployment Models
Cloud Benefits and Economics
OCI Architecture Overview
Global Infrastructure
Regions
Availability Domains (ADs)
Fault Domains (FDs)
OCI Organizational Concepts
Tenancy
Compartments
Resource Hierarchy
OCI Architecture Patterns
Exam Tips

Cloud Computing Fundamentals¶

Cloud Service Models¶

Infrastructure as a Service (IaaS)¶

Definition: Provides virtualized computing resources over the internet.

Characteristics: - Customer manages: OS, middleware, runtime, data, applications - Provider manages: Compute, storage, networking, virtualization, physical infrastructure - Most flexible cloud service model - Pay-as-you-go pricing

OCI IaaS Examples: - Compute Instances (VMs and Bare Metal) - Block Storage - Virtual Cloud Networks (VCN) - Load Balancers - Object Storage

Use Cases: - Migrating on-premises workloads (lift-and-shift) - Development and testing environments - High-performance computing (HPC) - Big data analytics

Platform as a Service (PaaS)¶

Definition: Provides a platform allowing customers to develop, run, and manage applications.

Characteristics: - Customer manages: Data and applications - Provider manages: Everything else (OS, middleware, runtime, infrastructure) - Focus on application development, not infrastructure management - Built-in tools and services for developers

OCI PaaS Examples: - Autonomous Database (ATP, ADW) - Oracle Analytics Cloud - Oracle Integration Cloud - Container Engine for Kubernetes (OKE) - Oracle Functions (serverless)

Use Cases: - Application development and deployment - API development and management - Database workloads without infrastructure management - Business intelligence and analytics

Software as a Service (SaaS)¶

Definition: Delivers software applications over the internet on a subscription basis.

Characteristics: - Provider manages: Everything (entire stack) - Customer uses: The application - Accessible via web browser - Subscription-based pricing

OCI SaaS Examples: - Oracle ERP Cloud - Oracle HCM Cloud - Oracle SCM Cloud - Oracle CX Cloud

Use Cases: - Enterprise resource planning (ERP) - Customer relationship management (CRM) - Human capital management (HCM) - Email and collaboration

Cloud Deployment Models¶

Public Cloud¶

Definition: Cloud infrastructure available to the general public over the internet.

Characteristics: - Owned and operated by cloud provider - Resources shared among multiple customers (multi-tenant) - No capital expenditure (CapEx) - Pay only for what you use (OpEx)

OCI Public Cloud: - Standard OCI commercial regions - Available worldwide - Multi-tenant architecture with strong isolation - Full suite of OCI services

Private Cloud¶

Definition: Cloud infrastructure operated solely for a single organization.

Characteristics: - Can be on-premises or hosted - Greater control and security - Higher CapEx - Dedicated resources

OCI Private Cloud Options: - Dedicated Region: Entire OCI region for single customer - Oracle Cloud@Customer: OCI infrastructure deployed in customer data center - Exadata Cloud@Customer: Exadata infrastructure in customer data center

Hybrid Cloud¶

Definition: Combination of public and private cloud environments.

Characteristics: - Workloads can move between private and public clouds - Greater flexibility - Data and application portability - Optimized for cost and performance

OCI Hybrid Cloud Solutions: - FastConnect: Private connectivity between on-premises and OCI - VPN Connect: Encrypted connection over internet - Cloud@Customer: OCI services in customer data center - Roving Edge Infrastructure: Portable OCI compute and storage

Cloud Benefits and Economics¶

Key Cloud Benefits¶

1. Elasticity and Scalability - Elasticity: Automatically scale resources up or down based on demand - Scalability: Add resources as needed to handle growth - OCI Examples: - Autoscaling for compute instances - Autonomous Database auto-scaling - Flexible storage expansion

2. Cost Efficiency - CapEx to OpEx: No upfront hardware costs - Pay-as-you-go: Pay only for resources used - No maintenance costs: Provider handles infrastructure maintenance - OCI Cost Benefits: - Competitive pricing (typically 30-50% lower than competitors) - No data egress charges for data transfer out - Bring Your Own License (BYOL) - Universal Credits for flexibility

3. Agility and Speed - Rapid provisioning (minutes vs. weeks) - Fast deployment of applications - Quick scaling to meet demand - OCI Speed: Launch instances in seconds

4. Global Reach - Deploy applications closer to users globally - Reduce latency - Improve user experience - OCI: 40+ regions worldwide

5. Reliability and Availability - High availability through redundancy - Disaster recovery capabilities - SLA guarantees - OCI SLAs: - 99.95% for most services - 99.99% for Autonomous Database - 99.9% for Object Storage

6. Security - Professional security management - Compliance certifications - Advanced security features - OCI Security: Built-in security at all layers

Cloud Economics¶

Total Cost of Ownership (TCO): - Lower TCO compared to on-premises - No hardware refresh costs - Reduced data center costs - Lower operational expenses

Pricing Models: - Pay As You Go (PAYG): Per-second billing, no commitments - Monthly Flex: Commit to monthly spend for discounts - Annual Flex: Commit to annual spend for deeper discounts

OCI Architecture Overview¶

Global Infrastructure¶

OCI's global infrastructure is designed for high availability, low latency, and maximum security.

Key Characteristics: - 40+ regions worldwide (as of 2024) - Multiple availability domains per region (where possible) - Fault domains within each availability domain - Low-latency networking between regions - Isolated network virtualization

Design Principles: 1. Isolation: Each region is independent and isolated 2. Redundancy: Multiple levels of redundancy (regions, ADs, FDs) 3. Security: Security built into every layer 4. Performance: High-speed, low-latency network 5. Scalability: Designed to scale globally

Regions¶

Definition: A localized geographic area containing one or more availability domains.

Characteristics: - Independent and isolated from other regions - Data residency and compliance boundary - Connected via OCI's high-speed backbone network - Services may vary by region - Each region has a unique identifier (e.g., us-phoenix-1, us-ashburn-1)

Region Types:

1. Multi-AD Regions (Preferred)¶

Contains 3 availability domains
Highest level of availability
Examples: Phoenix, Ashburn, Frankfurt, London, Tokyo

Benefits: - Withstand complete AD failure - Distribute workloads across ADs - Built-in disaster recovery

2. Single-AD Regions¶

Contains 1 availability domain
3 fault domains within the AD
Examples: Some government and smaller regions

Use Cases: - Data sovereignty requirements - Specific geographic presence needed - Cost optimization for non-critical workloads

Realm Types¶

1. Commercial Realms: - Standard OCI public cloud - Global regions - Full service availability

2. Government Realms: - OCI Government Cloud: For US government (FedRAMP authorized) - UK Government Cloud: For UK public sector - Enhanced security and compliance - Physical and logical isolation

Region Naming Convention:

[country-code]-[city]-[number]

Examples:
- us-phoenix-1
- us-ashburn-1
- eu-frankfurt-1
- ap-tokyo-1
- uk-london-1

Region Selection Considerations: 1. Latency: Choose region closest to users 2. Data Residency: Comply with data sovereignty laws 3. Service Availability: Verify required services are available 4. Cost: Pricing may vary by region 5. Disaster Recovery: Select paired regions for DR

Availability Domains (ADs)¶

Definition: One or more isolated, fault-tolerant data centers within a region.

Key Characteristics: - Physically separated: Different buildings, different power, different cooling - Independent: Failure in one AD doesn't affect others - Low-latency connectivity: Connected within region via high-speed network - Resource distribution: Resources can span ADs

Numbering: - ADs are numbered: AD-1, AD-2, AD-3 - AD numbers are customer-specific (randomized mapping) - Your AD-1 may be different physical AD than another customer's AD-1

Purpose: - Provide redundancy and fault tolerance - Enable high availability architectures - Protect against data center failures

Best Practices:

High Availability Pattern:
- Deploy resources across multiple ADs
- Use load balancers to distribute traffic
- Replicate data across ADs

Example Architecture:
AD-1: Web Server 1, Database Primary
AD-2: Web Server 2, Database Standby
AD-3: Web Server 3, Database Backup

AD Availability: - Multi-AD regions: 3 ADs - Single-AD regions: 1 AD (with 3 fault domains)

Fault Domains (FDs)¶

Definition: Grouping of hardware and infrastructure within an availability domain.

Key Characteristics: - 3 fault domains per availability domain - Logical grouping of hardware - Separate physical hardware (servers, switches, racks) - Share availability domain infrastructure - Protect against hardware failures

Purpose: - Provide redundancy within an AD - Protect against rack/hardware failures - Enable high availability in single-AD regions

Fault Domain Placement: - OCI automatically distributes resources across FDs - You can manually select FD for specific resources - Load balancers automatically use multiple FDs

FD vs AD Comparison:

Feature	Availability Domain	Fault Domain
Scope	Region level	AD level
Physical Separation	Different buildings	Different racks/hardware
Count	1-3 per region	3 per AD
Failure Protection	Data center failure	Hardware/rack failure
Network	Separate networks	Shared AD network
Best For	DR and HA	Additional redundancy

High Availability Architecture:

Region: us-phoenix-1
├── AD-1
│   ├── FD-1: Instance-1
│   ├── FD-2: Instance-2
│   └── FD-3: Instance-3
├── AD-2
│   ├── FD-1: Instance-4
│   ├── FD-2: Instance-5
│   └── FD-3: Instance-6
└── AD-3
    ├── FD-1: Instance-7
    ├── FD-2: Instance-8
    └── FD-3: Instance-9

OCI Organizational Concepts¶

Tenancy¶

Definition: The root compartment that contains all your cloud resources.

Characteristics: - Created when you sign up for OCI - Unique identifier: OCID (Oracle Cloud Identifier) - Root compartment for all resources - Cannot be deleted - Billing entity

Tenancy OCID Format:

ocid1.tenancy.oc1..<unique_ID>

Example:
ocid1.tenancy.oc1..aaaaaaaaba3pv6wkcr4jqae5f15p2b2m2yt2j6rx32uzr4h25vqstifsfdsq

Tenancy Properties: - Home Region: Primary region (cannot be changed) - Subscribed Regions: Regions you've activated - Tenancy Name: User-friendly name - Tenancy OCID: Unique identifier

Tenancy-Level Resources: - Users - Groups - Dynamic Groups - Policies - Federated Identity Providers - Audit Logs - Cost and Usage Reports

Compartments¶

Definition: Logical containers for organizing and isolating resources.

Purpose: 1. Organization: Group related resources 2. Isolation: Separate different projects/teams/environments 3. Access Control: Apply policies at compartment level 4. Budget Tracking: Track costs per compartment 5. Quota Management: Set quotas per compartment

Key Characteristics: - Resources belong to a single compartment - 6 levels deep (root + 5 nested levels) - Can be moved between compartments (most resources) - Can be deleted when empty - Inherit policies from parent compartments

Compartment Best Practices:

1. By Environment¶

Tenancy (root)
├── Development
│   ├── Dev-Network
│   ├── Dev-Compute
│   └── Dev-Database
├── Testing
│   ├── Test-Network
│   ├── Test-Compute
│   └── Test-Database
└── Production
    ├── Prod-Network
    ├── Prod-Compute
    └── Prod-Database

2. By Project/Application¶

Tenancy (root)
├── Project-Alpha
│   ├── Alpha-Network
│   ├── Alpha-Compute
│   └── Alpha-Database
└── Project-Beta
    ├── Beta-Network
    ├── Beta-Compute
    └── Beta-Database

3. By Department¶

Tenancy (root)
├── Finance
├── HR
├── Engineering
└── Marketing

4. By Lifecycle (Recommended for Large Orgs)¶

Tenancy (root)
├── Network (Shared)
│   ├── Prod-VCN
│   ├── Dev-VCN
│   └── Test-VCN
├── Security (Shared)
│   ├── Keys
│   └── Secrets
├── Application-A
│   ├── Prod
│   ├── Staging
│   └── Dev
└── Application-B
    ├── Prod
    └── Dev

Compartment Operations:

Creating Compartments (Console): 1. Navigate to Identity → Compartments 2. Click "Create Compartment" 3. Provide name and description 4. Select parent compartment 5. Add tags (optional) 6. Click "Create"

Creating Compartments (CLI):

oci iam compartment create \
  --compartment-id <parent_compartment_ocid> \
  --name "Development" \
  --description "Development environment resources"

Moving Resources Between Compartments:

oci compute instance update \
  --instance-id <instance_ocid> \
  --compartment-id <new_compartment_ocid>

Deleting Compartments:

# Must be empty first
oci iam compartment delete \
  --compartment-id <compartment_ocid>

Compartment Quotas: - Set limits on resource usage per compartment - Prevent runaway costs - Control resource allocation

# Set quota policy
oci limits quota create \
  --compartment-id <compartment_ocid> \
  --name "Dev-Quota" \
  --statements '["Set compute quotas core-count to 10 in compartment Development"]'

Resource Hierarchy¶

OCI Resource Hierarchy:

Tenancy (Root Compartment)
  ├── Compartment A
  │     ├── Sub-Compartment A1
  │     │     ├── VCN
  │     │     ├── Compute Instance
  │     │     └── Block Volume
  │     └── Sub-Compartment A2
  │           ├── Database
  │           └── Object Storage Bucket
  └── Compartment B
        ├── Compute Instance
        └── Load Balancer

OCID Structure: Every resource has a unique Oracle Cloud Identifier (OCID).

OCID Format:

ocid1.<resource_type>.<realm>.[region][.<future_use>].<unique_ID>

Components:
1. ocid1: Literal "ocid1"
2. resource_type: Type of resource (instance, vcn, volume, etc.)
3. realm: oc1 (commercial), oc2 (gov), oc3 (federal)
4. region: Region identifier (optional for global resources)
5. unique_ID: Unique identifier

Examples:
ocid1.instance.oc1.phx.abyhqljt...  (Compute instance in Phoenix)
ocid1.vcn.oc1.iad.aaaaaaaabcdef...  (VCN in Ashburn)
ocid1.user.oc1..aaaaaaaaxyz...      (User - global resource)

Resource Tags: - Free-form tags: User-defined key-value pairs - Defined tags: Namespace-based tags with governance - Used for cost tracking, organization, automation

Resource Naming: - Must be unique within compartment (for most resources) - Can use same name in different compartments - Best practice: Use descriptive, consistent naming convention

OCI Architecture Patterns¶

Single-Region Architecture¶

Basic Pattern:

Region: us-phoenix-1
├── VCN (10.0.0.0/16)
│   ├── Public Subnet (10.0.1.0/24) - AD-1
│   │   └── Load Balancer
│   ├── Private Subnet (10.0.2.0/24) - AD-1
│   │   └── App Server 1
│   ├── Private Subnet (10.0.3.0/24) - AD-2
│   │   └── App Server 2
│   └── Database Subnet (10.0.4.0/24) - AD-3
│       └── Database System

Use Cases: - Single-region compliance requirements - Cost optimization - Simple workloads

Multi-AD High Availability¶

Pattern:

Region: us-ashburn-1
├── AD-1
│   ├── Web Tier: Instance 1
│   ├── App Tier: Instance 1
│   └── Database: Primary
├── AD-2
│   ├── Web Tier: Instance 2
│   ├── App Tier: Instance 2
│   └── Database: Standby
└── AD-3
    ├── Web Tier: Instance 3
    ├── App Tier: Instance 3
    └── Database: Backup

Features: - Load balancer distributes across ADs - Database replication across ADs - Survives AD failure

Multi-Region Architecture¶

Pattern:

Primary Region: us-phoenix-1        Secondary Region: us-ashburn-1
├── VCN                             ├── VCN
├── Compute Instances               ├── Compute Instances
├── Database (Primary)              └── Database (Standby)
└── Object Storage                      └── Object Storage (Replicated)

Connected via: Remote VCN Peering or FastConnect

Use Cases: - Disaster recovery - Global applications - Latency optimization

Hybrid Cloud Architecture¶

Pattern:

On-Premises Data Center              OCI Region
├── Corporate Network               ├── VCN
├── Existing Applications           ├── Migrated Applications
└── Data                           └── Cloud Storage
         |                                |
         └──── FastConnect/VPN ──────────┘

Connectivity Options: - FastConnect: Dedicated private connection (1-10 Gbps) - Site-to-Site VPN: Encrypted IPSec tunnel over internet - Both: FastConnect for primary, VPN for backup

Exam Tips¶

Critical Concepts to Master¶

1. Regions, ADs, and FDs: - Multi-AD region = 3 ADs - Single-AD region = 1 AD with 3 FDs - ADs are physically separated (different buildings) - FDs are logically separated within an AD (different racks) - AD numbers are customer-specific

2. Compartments: - Maximum depth: 6 levels (root + 5 nested) - Resources can be moved between compartments - Policies are inherited from parent - Used for organization, access control, and billing

3. High Availability Design: - Spread resources across multiple ADs - Use multiple FDs within an AD - Implement load balancing - Plan for AD failure scenarios

4. Cloud Service Models: - IaaS: You manage OS and up - PaaS: You manage data and apps - SaaS: Provider manages everything

5. Tenancy: - Root compartment - Contains all resources - Home region cannot be changed - Subscribed regions can be added

Common Exam Questions¶

Q: What is the maximum number of compartment levels? A: 6 levels deep (root + 5 nested levels)

Q: Can a resource belong to multiple compartments? A: No, a resource belongs to a single compartment (but can be moved)

Q: What's the difference between AD and FD? A: ADs are physically separated data centers; FDs are logical separations within an AD

Q: How many fault domains in a single-AD region? A: 3 fault domains

Q: Can you change the home region of a tenancy? A: No, home region is permanent

Q: What happens if an entire AD fails? A: Resources in other ADs are unaffected; properly designed apps continue running

Key Terminology¶

Region: Geographic area with data centers
Availability Domain (AD): Isolated data center(s) within region
Fault Domain (FD): Hardware grouping within AD
Tenancy: Your OCI account/root compartment
Compartment: Logical container for resources
OCID: Oracle Cloud Identifier (unique ID for every resource)
Home Region: Primary region for account
Realm: Isolated cloud environment (commercial, government)

Exam Strategy Tips¶

Read carefully: Questions often have "MOST correct" answers
Eliminate wrong answers: Narrow down to 2 choices
Look for keywords: "high availability", "fault tolerance", "cost optimization"
Consider scenarios: Think about real-world implementations
Time management: 1.5 minutes per question average
Flag and return: Mark difficult questions, come back later

Quick Reference¶

High Availability Checklist: - [ ] Multiple ADs used - [ ] Multiple FDs within each AD - [ ] Load balancer configured - [ ] Database replication enabled - [ ] Backup strategy implemented

Compartment Design Checklist: - [ ] Logical hierarchy defined - [ ] Naming convention established - [ ] IAM policies planned - [ ] Budget tracking configured - [ ] Maximum 6 levels depth

Region Selection Checklist: - [ ] Latency requirements met - [ ] Data residency compliance verified - [ ] Required services available - [ ] Cost analyzed - [ ] DR strategy planned

Summary¶

Key Takeaways¶

Cloud Models: Understand IaaS, PaaS, SaaS responsibilities
Regions: Geographic areas with complete independence
ADs: Isolated data centers providing fault tolerance
FDs: Hardware groupings providing additional redundancy
Tenancy: Root compartment containing all resources
Compartments: Organizational units for resources (max 6 levels)
High Availability: Design across ADs and FDs
OCIDs: Unique identifiers for all resources

Study Focus Areas¶

Must Know: - Difference between AD and FD - Compartment hierarchy and limits - High availability architectures - Cloud service model responsibilities - Region and realm concepts

Should Know: - OCID structure and format - Compartment best practices - Resource movement between compartments - Tenancy properties and limitations - Multi-region architectures

Good to Know: - Specific region names and locations - Detailed OCID component breakdown - Advanced compartment strategies - Government cloud differences

Next Steps: Review Core Services (Compute, Storage, Networking, Database)