2.2 Compute Shapes, Images & Autoscaling

2.2 Compute Shapes, Images & Autoscaling

[!NOTE] Foundations Blueprint Focus: The OCI Foundations exam expects candidates to understand what an OCPU represents, how flexible shapes differ from fixed shapes, the primary shape families (Standard, DenseIO, GPU, HPC), compute image categories, and how Instance Configurations, Instance Pools, and Autoscaling collaborate to deliver automated horizontal elasticity.

When deploying compute workloads on Oracle Cloud Infrastructure, two foundational decisions dictate performance, cost, and availability: selecting the appropriate Compute Shape and choosing the base Compute Image. Furthermore, configuring automated elasticity guarantees that application tiers scale dynamically with customer demand while avoiding idle resource expenditure.

---

What is an Instance Shape?

An Instance Shape is a resource template that specifies the exact compute capacity allocated to an instance upon creation. The shape determines:

1. Number of OCPUs: Processing cores assigned to the instance.
2. Memory (RAM): Amount of system memory allocated (measured in gigabytes).
3. Network Bandwidth: Maximum network throughput (ranging from 1 Gbps up to 100+ Gbps).
4. Maximum VNICs: The number of Virtual Network Interface Cards that can be attached.
5. Local Storage: For storage-dense shapes, the presence and capacity of direct-attached NVMe solid-state drives.

The OCPU Concept (Oracle Compute Unit)

A critical distinction on the OCI Foundations exam is understanding the definition of an OCPU (Oracle Compute Unit) compared to virtual CPUs (vCPUs) used by competing cloud vendors:

• In x86 Architectures (Intel Xeon and AMD EPYC):
  • 1 OCPU = 1 Physical CPU Core with hyper-threading (symmetric multiprocessing) enabled.
  • Because a physical x86 core with hyper-threading exposes 2 hardware execution threads, 1 OCPU is equivalent to 2 vCPUs.
  • When migrating a workload requiring 8 vCPUs from AWS or Azure to OCI, you only need to provision 4 OCPUs in OCI to obtain identical thread execution capacity.
• In Arm Architecture (Ampere Altra):
  • Ampere Altra processors are single-threaded by design to prevent cache contention and timing attacks.
  • 1 OCPU = 1 Physical Arm Core (equivalent to 1 vCPU).

+-------------------------------------------------------------------------+
|                        The OCPU Architectural Unit                      |
|                                                                         |
|   x86 Architecture (AMD EPYC / Intel Xeon):                             |
|   [ 1 OCPU ] ===> [ 1 Physical Core ] ===> (Thread 0) + (Thread 1)      |
|                                            └───────── 2 vCPUs ─────────┘     |
|                                                                         |
|   Arm Architecture (Ampere Altra):                                      |
|   [ 1 OCPU ] ===> [ 1 Physical Core ] ===> (Single Thread / 1 vCPU)     |
+-------------------------------------------------------------------------+

Processor Architectures Supported in OCI

OCI provides diverse silicon options across industry-leading chipmakers:

• AMD EPYC: Delivers industry-leading price-per-performance for general-purpose, web, and database workloads. Designated in shape names with an "E" (e.g., VM.Standard.E4.Flex, VM.Standard.E5.Flex).
• Intel Xeon: Optimized for enterprise applications requiring high single-thread clock frequencies, legacy x86 software compatibility, or Intel-specific instruction sets (AVX-512, Intel DL Boost). Designated with an "X" or numeric code (e.g., VM.Standard3.Flex).
• Ampere Altra (Arm): Energy-efficient 64-bit Arm Neoverse cores delivering linear performance scaling and extremely low pricing per core-hour ($0.01 per OCPU/hr). Ideal for cloud-native web services, mobile app backends, and containerized microservices. Designated with an "A" (e.g., VM.Standard.A1.Flex).

---

Fixed Shapes vs. Flexible Shapes

Historically, cloud providers forced compute instances into rigid, predefined hardware profiles with locked CPU-to-memory ratios. OCI introduced Flexible Shapes (Flex) to overcome this limitation.

Fixed Shapes

In older fixed shapes (such as VM.Standard2.1 or VM.Standard2.2), the ratio of OCPUs to RAM was hardcoded (e.g., 1 OCPU with 15 GB RAM, 2 OCPUs with 30 GB RAM). If an application required 40 GB of RAM but only 2 OCPUs of processing power, the customer was forced to purchase a larger, expensive 4-OCPU shape simply to acquire the required memory, resulting in 50% wasted CPU spend.

Flexible Shapes (The Modern Standard)

Flexible shapes decouple CPU cores from memory, allowing customers to customize the exact number of OCPUs and amount of memory independently upon provisioning or during resizing:

• Example (VM.Standard.E4.Flex): Customers can select from 1 to 64 OCPUs and configure from 1 GB to 64 GB of RAM per OCPU (up to a maximum of 1,024 GB RAM).
• Elimination of Cloud Waste: If your in-memory cache requires 2 OCPUs and 64 GB of RAM, you configure exactly 2 OCPUs and 64 GB RAM. You pay only for the exact resources allocated.
• Dynamic Adjustment: As workload demands shift, flexible shapes can be resized vertically without rebuilding the instance.

---

OCI Compute Shape Families

OCI organizes compute shapes into specialized families optimized for distinct workload profiles:

---

Compute Images: Operating System Options

Every compute instance requires a base boot image containing the operating system and initial configuration. OCI categorizes images into four deployment streams:

1. Platform Images: Maintained, hardened, and regularly patched by Oracle. Available at no extra licensing cost for Linux distributions, including:
   • Oracle Linux (featuring the Unbreakable Enterprise Kernel - UEK and Autonomous Linux for zero-downtime kernel patching via Ksplice)
   • Ubuntu Linux
   • CentOS / Rocky Linux
   • Red Hat Enterprise Linux (RHEL)
   • Microsoft Windows Server (billed per OCPU-hour for licensing)
2. Custom Images: A private image created by taking a point-in-time snapshot of an existing compute instance's boot volume. Custom images preserve installed software, application binaries, and configuration files, making them ideal for "gold master" templates. Custom images only capture the boot volume; attached block storage data volumes are not included.
3. Marketplace Images: Pre-configured virtual appliances and software stacks packaged by Oracle and third-party independent software vendors (ISVs). Examples include enterprise firewalls (Palo Alto, Fortinet, Check Point), database systems, and developer toolchains.
4. Bring Your Own Image (BYOI): Enables enterprise customers to upload their existing on-premises virtual machine disk files (supporting QCOW2 and VMDK formats) to OCI Object Storage and import them as custom images, facilitating seamless cloud migration.

---

Elasticity: Vertical vs. Horizontal Scaling

Workload resource demands fluctuate over time. OCI provides two fundamental scaling mechanisms:

• Vertical Scaling (Scaling Up / Down):
  • Changing the shape of an existing compute instance (e.g., increasing a flexible VM from 2 OCPUs and 16 GB RAM to 8 OCPUs and 64 GB RAM).
  • Downtime Requirement: Vertical scaling requires an instance reboot. The instance stops, the new CPU/RAM envelope is allocated on the host, and the instance restarts. While simple, it cannot achieve zero-downtime elasticity.
• Horizontal Scaling (Scaling Out / In):
  • Adding or removing instances to distribute incoming network traffic across multiple nodes.
  • Zero Downtime: Active instances continue serving traffic while new instances are launched or surplus instances are terminated.
  • Managed natively in OCI using Instance Configurations, Instance Pools, and Autoscaling.

The Building Blocks of Automated Horizontal Scaling

+-------------------------------------------------------------------------+
| 1. Instance Configuration                                               |
|    [Blueprint: Image (Oracle Linux) + Shape (E4.Flex) + Subnet + Keys]  |
+-------------------------------------------------------------------------+
                                     │
                                     ▼
+-------------------------------------------------------------------------+
| 2. Instance Pool                                                        |
|    [Group of Identical Instances across ADs / Fault Domains + Load Balancer] |
+-------------------------------------------------------------------------+
                                     │
                                     ▼
+-------------------------------------------------------------------------+
| 3. Autoscaling Policy                                                   |
|    - Metric-Based: Scale Out when CPU > 75%, Scale In when CPU < 25%   |
|    - Schedule-Based: Scale to 10 nodes Mon 08:00, Scale to 2 nodes Fri  |
+-------------------------------------------------------------------------+

1. Instance Configuration: A reusable blueprint that defines all settings needed to create an instance: the base OS image, compute shape (OCPUs and RAM), network settings (VCN and subnets), SSH keys, cloud-init startup scripts, and attached block volumes.
2. Instance Pool: A managed collection of homogeneous instances created from a single Instance Configuration. The pool automatically distributes instances across multiple Availability Domains and Fault Domains to guarantee high availability. Instance Pools integrate directly with OCI Load Balancers to automatically register new instances in backend sets.
3. Autoscaling Configuration: An automated policy attached to an Instance Pool that controls when instances are added (scale-out) or removed (scale-in):
   • Metric-Based Autoscaling: Evaluates performance telemetry collected by the OCI Monitoring service. Administrators set CPU utilization or memory utilization thresholds (e.g., add 2 instances if average CPU exceeds 75% for 5 minutes; remove 1 instance if average CPU drops below 25%). Includes a cooldown period to prevent thrashing (rapid, continuous scaling actions).
   • Schedule-Based Autoscaling: Scales instance counts based on predictable calendar schedules defined by cron expressions (e.g., scale out ahead of Monday morning business hours and scale in on Friday evening).