Compute Management

OCI Compute Management - Expert Knowledge

NEVER Do This

NEVER launch instances without checking service limits first

oci limits resource-availability get \
  --service-name compute \
  --limit-name "standard-e4-core-count" \
  --compartment-id <ocid> \
  --availability-domain <ad>

87% of "out of capacity" errors are actually quota limits, not infrastructure capacity. Check limits BEFORE launching to get accurate error messages.

NEVER use console serial connection as primary access

• Creates security audit findings (bypasses SSH key controls)
• Use only for boot troubleshooting when SSH fails
• Delete connection immediately after troubleshooting

NEVER mix regional and AD-specific resources in templates

• Breaks portability when moving between regions
• Use AD-agnostic designs: spread via fault domains, not hardcoded ADs

NEVER forget boot volume preservation flag in dev/test

oci compute instance terminate --instance-id <id> --preserve-boot-volume false

Without --preserve-boot-volume false: $50+/month per deleted instance (orphaned boot volumes accumulate silently)

NEVER enable public IP on production instances

• Use bastion service or private endpoints for access
• Cost impact: $500–5000+ per security incident from exposed instances

NEVER use fixed shapes when Flex covers the same specs

• Fixed shapes (e.g., VM.Standard2.1) are often MORE expensive than Flex equivalents
• Always compare Flex pricing first before choosing a fixed shape

Capacity Error Decision Tree

"Out of host capacity for shape X"?
│
├─ Check service limits FIRST (87% of cases)
│  └─ oci limits resource-availability get
│     ├─ available = 0 → Request limit increase (NOT a capacity issue)
│     └─ available > 0 → True capacity issue, continue below
│
├─ Same shape, different AD?
│  └─ Try each AD in region (PHX/IAD each have 3, all independent)
│
├─ Different shape, same series?
│  └─ E4 failed → try E5 (newer gen, often more available)
│  └─ Standard failed → try Optimized or DenseIO variants
│
├─ Different architecture?
│  └─ AMD → ARM (A1.Flex often has capacity when Intel/AMD full)
│
└─ All ADs exhausted?
   └─ Create capacity reservation (guarantees future launches)

Shape Selection: Cost vs Performance

Budget-critical (save ~66%):

• VM.Standard.A1.Flex (ARM): $0.01/OCPU/hr vs $0.03 AMD
• Caveat: test ARM compatibility — not all software runs on ARM

General purpose (balanced):

• VM.Standard.E4.Flex: 2:16 CPU:RAM ratio, $0.03/OCPU/hr
• Start with 2 OCPUs, scale based on metrics — not guesses

Memory-intensive (databases, caches):

• VM.Standard.E4.Flex with custom ratio: up to 1:64 CPU:RAM
• Cost: $0.03/OCPU + $0.0015/GB RAM

Quick Cost Reference

Free Tier: 2x AMD VM (1/8 OCPU, 1GB) + 4 ARM cores (24GB total) — always free

Formula: (OCPUs × $/OCPU + GB × $0.0015) × 730 hrs/month Example: 2 OCPU, 16GB E4 = (2×$0.03 + 16×$0.0015) × 730 = $61.32/month

Instance Principal Authentication (Production)

When an instance needs to call OCI APIs, NEVER put user credentials on the instance.

# 1. Create dynamic group
oci iam dynamic-group create \
  --name "app-instances" \
  --matching-rule "instance.compartment.id = '<compartment-ocid>'"

# 2. Grant permissions (IAM policy)
# "Allow dynamic-group app-instances to read object-family in compartment X"

# 3. Code uses instance principal — no credentials needed:
signer = oci.auth.signers.InstancePrincipalsSecurityTokenSigner()
client = oci.object_storage.ObjectStorageClient(config={}, signer=signer)

Benefits: No credential rotation, no secrets to manage, automatic token refresh.

OCI-Specific Gotchas

Availability Domain names are tenant-specific

• Your AD: fMgC:US-ASHBURN-AD-1
• Another tenant: ErKW:US-ASHBURN-AD-1
• MUST query your own tenant: oci iam availability-domain list
• Hardcoding AD names from examples breaks cross-tenant portability

Boot Volume backups do NOT include instance config

• Backup captures disk only — NOT shape, networking, or metadata
• For DR: use custom images (captures config) or Terraform for infrastructure

Instance Metadata Service has 3 versions — always use v2

• v1: http://169.254.169.254/opc/v1/ (legacy, vulnerable to SSRF)
• v2: http://169.254.169.254/opc/v2/ (requires session token, prevents SSRF)
• v1 is still enabled by default on older instances

Progressive Loading Reference

Load `references/oci-compute-shapes-reference.md` when:

• Comparing flexible shape specs (E4 vs E5 vs E6 vs A1/A2/A4.Flex)
• Looking up bare metal, GPU, Dense I/O, or HPC shapes
• Need official Oracle specs (memory limits, OCPU counts, network bandwidth)

Do NOT load for quick cost comparisons, capacity troubleshooting, or shape selection — this file covers those.

• When a new region becomes available, it might take a few weeks before host capacity also becomes available.

To obtain a list of shapes available to you, run the ListShapes operation.

• If your instance uses stateful security rules, each instance has a maximum number of concurrent connections that can be tracked, based on the instance's shape.

Compute Shape Pricing 🔗

You can use the Cost Estimator to estimate your expected monthly project costs with Oracle Cloud Infrastructure. For detailed information about billing, see Billing and Cost Management and the Oracle Compute Cloud Services section of Oracle PaaS and IaaS Universal Credits Service Descriptions.

OCPUs and vCPUs

Oracle measures compute resource pricing differently. The Oracle CPU (OCPU) represents physical CPU cores and is the unit of measurement for CPUs on x86 CPUs (AMD and Intel) and Arm CPUs (OCI Ampere Compute). A virtual CPU (vCPU), the industry-standard for measuring compute resources, represents one execution thread of a physical CPU core.

Most CPU architectures, including x86, runs two threads per physical core, so one OCPU is the equal of two vCPUs for x86-based compute. For OCI Compute, the minimum unit of provisioning starts from one OCPU on both X86 (Intel and AMD) and OCI Ampere Compute processors.

The following are the provisioning units for compute instances:

• 1 OCPU on Arm A1 (Compute) = 1 core on Arm A1 (Compute) or 1 vCPU
• 1 OCPU on Arm A2 (Compute) and A4 (Compute) = 2 cores on Arm A2 (Compute) and A4 (Compute) or 2 vCPUs
• 1 OCPU on x86 (AMD and Intel) = 2 vCPUs

For more information, see Cloud Price List. In addition, you can read this blog post on vCPU and OCPU pricing information.

Flexible Shapes 🔗

A flexible shape is a shape that lets you customize the number of OCPUs and the amount of memory when launching or resizing your VM. When you [create a VM instance](https://docs.oracle.com/en-us/iaas/Content/Compute/Tasks/launchinginstance.htm "Create a bare metal or virtual machine (VM) compute instance.") using a flexible shape, you select the number of OCPUs and the amount of memory that you need for the workloads that run on the instance. The network bandwidth and number of VNICs scale proportionately with the number of OCPUs. This flexibility lets you build VMs that match your workload, enabling you to optimize performance and minimize cost.

The flexible shapes are:

• VM.Standard3.Flex (Intel)
• VM.Standard.E4.Flex (AMD)
• VM.Standard.E5.Flex (AMD)
• VM.Standard.E6.Flex (AMD)
• VM.Standard.A1.Flex (Altra processor from Ampere)
• VM.Standard.A2.Flex (AmpereOne processor from Ampere)
• VM.Standard.A4.Flex (AmpereOne-M processor from Ampere)
• VM.DenseIO.E4.Flex (AMD)
• VM.Optimized3.Flex (Intel)

Flexible memory is also available on flexible shapes. The amount of memory allowed is based on the number of OCPUs selected.

For standard and optimized flexible shapes, the ratio of memory to OCPUs depends on the shape.

For dense I/O flexible shapes, the following configurations are available:

• 8 OCPUs, 128 GB memory
• 16 OCPUs, 256 GB memory
• 32 OCPUs, 512 GB memory

These resources are billed at a per-second granularity with a one-minute minimum. Optimize your costs by choosing the shape that matches your workload and by changing the shape when your workload changes. For example, you can configure the VM to maximize compute processing power by choosing a low core-to-memory ratio. Or, for applications like in-memory databases or big data processing engines, configure an instance with a high core-to-memory ratio. Modify the OCPUs and memory as your workload changes, scaling up to increase performance or scaling down to reduce costs.

Supported Images 🔗

Most platform images are compatible with flexible shapes. Use a platform image that was published after the flexible shape was released (for release dates, see the Compute release notes).

Custom images are also supported, depending on the image. You must add flexible shape compatibility to the custom image, and then test the image on the flexible shape to ensure that it actually works on the shape.

Supported Regions 🔗

For a list of supported regions, see the compute instance service limits. As host capacity becomes available in additional regions, the list is updated.

Note

Capacity might be limited for A1 shapes.

Extended Memory VM Instances 🔗

[Extended memory virtual machine (VM) instances](https://docs.oracle.com/en-us/iaas/Content/Compute/References/extended-memory-vm-instances.htm "Extended memory virtual machine (VM) instances are VM instances that provide more memory and cores than available with standard shapes.") are VM instances that provide more memory and cores than available with standard shapes.

The following shapes are available for extended memory VM instances:

• VM.Standard3.Flex

• VM.Standard.E3.Flex

• VM.Standard.E4.Flex

• VM.Standard.E5.Flex

Bare Metal Shapes 🔗

The following shapes are available for bare metal instances:

• Standard Shapes
• Dense I/O Shapes
• GPU Shapes
• HPC and Optimized Shapes

Network bandwidth is based on expected bandwidth for traffic within a VCN. To determine which physical NICs are active for a shape, refer to the network bandwidth specifications in the following tables. If the network bandwidth is listed as "2 x <bandwidth> Gbps," it means that both NIC 0 and NIC 1 are active.

For bare metal instances, optionally [configure advanced BIOS settings](https://docs.oracle.com/en-us/iaas/Content/Compute/References/bios-settings.htm "When you create a bare metal compute instance, you can optionally configure advanced BIOS settings that let you optimize performance. For example, you can disable simultaneous multithreading to optimize the NUMA settings."), such as disabling simultaneous multithreading, disabling cores, or optimizing the NUMA settings.

Standard Shapes 🔗

Designed for general purpose workloads and suitable for a wide range of applications and use cases. Standard shapes provide a balance of cores, memory, and network resources. Standard shapes are available with Intel, AMD, and Arm-based processors.

These are the bare metal standard series:

• BM.Standard3: X9-based standard compute. Processor: Intel Xeon Platinum 8358. Base frequency 2.6 GHz, max turbo frequency 3.4 GHz.
• BM.Standard.E4: E4-based standard compute. Processor: AMD EPYC 7J13. Base frequency 2.55 GHz, max boost frequency 3.5 GHz.
• BM.Standard.E5: E5-based standard compute. Processor: AMD EPYC 9J14. Base frequency 2.4 GHz, max boost frequency 3.7 GHz.
• BM.Standard.E6: E6-based standard compute. Processor: AMD EPYC 9J45. Base frequency 2.7 GHz, max boost frequency 4.1 GHz.
• BM.Standard.A1:

OCI Ampere A1 Compute Arm-based standard compute. Each OCPU corresponds to a single hardware execution thread. Processor: Ampere Altra Q80-30. Max frequency 3.0 GHz.

• BM.Standard.A4: OCI Ampere A4 Compute Arm-based standard compute. Each OCPU corresponds to two hardware execution threads (2 cores). Processor: Ampere AmpereOne-M A06-36M. Frequency 3.6 GHz.

C-States and Frequency Scaling 🔗

Modern CPUs transition to a power-saving state (called c-states) when the CPU is idle or underutilized. These c-states start at C0, which is the normal CPU operating mode (the CPU is 100% activated). The higher the c-state, the deeper the sleep mode into which the CPU transitions. The sleep modes work by cutting the clock signal and power from idle units inside the CPU, thereby reducing the energy use. As the CPU transitions to higher c-states (deeper sleep states), the longer it takes to wake up the units that are shut down. This is an undesirable side effect of c-states transitions, because it can slow down a demanding application.

Fortunately, the hypervisor on standard VM shapes manages this complexity for the end user by preventing transitions to deeper sleep states even when the CPU is underutilized. In addition, it disables c-states when it sees sustained high utilization. When c-states are disabled, the CPU operates in C0 state, where all cores are active at base frequency. Each processor manufacturer names the maximum frequency per core differently; for Intel the maximum frequency is named max turbo frequency, and for AMD it is called max boost frequency. This maximum frequency is realized by the respective CPU's built-in algorithms when the processor is running in C0 state under normal but sustained load.

Currently, the hypervisor does not allow the client operating system running in the instance to manage the c-states using kernel command line options. The client always shows the base frequency, even when the hypervisor is running the processor at the maximum frequency advertised by the processor.

Dense I/O Shapes 🔗

Designed for large databases, big data workloads, and applications that require high-performance local storage. DenseIO shapes include locally-attached NVMe-based SSDs.

This is the bare metal dense I/O series:

• BM.DenseIO.E4: E4-based dense I/O compute. Processor: AMD EPYC 7J13. Base frequency 2.55 GHz, max boost frequency 3.5 GHz.
• BM.DenseIO.E5: E5-based dense I/O compute. Processor: AMD EPYC 9J14. Base frequency 2.6 GHz, max boost frequency 3.7 GHz.

Notes

1: Please contact an Oracle sales representative for additional details.

GPU Shapes 🔗

Designed for hardware-accelerated workloads. GPU shapes include Intel, AMD, or Arm CPUs with NVIDIA or AMD graphics processors. Some bare metal GPU shapes support cluster networking.

These are the bare metal GPU series:

• BM.GPU2: X7-based GPU compute.
• GPU: NVIDIA Tesla P100 16 GB
• CPU: Intel Xeon Platinum 8167M. Base frequency 2.0 GHz, max turbo frequency 2.4 GHz.
• BM.GPU3: X7-based GPU compute.
• GPU: NVIDIA Tesla V100 16 GB
• CPU: Intel Xeon Platinum 8167M. Base frequency 2.0 GHz, max turbo frequency 2.4 GHz.
• BM.GPU4: E3-based GPU compute.
• GPU: NVIDIA A100 40 GB
• CPU: AMD EPYC 7542. Base frequency 2.9 GHz, max boost frequency 3.4 GHz.
• BM.GPU.A10: X9-based GPU compute.
• GPU: NVIDIA A10 24 GB
• CPU: Intel Xeon Platinum 8358. Base frequency 2.6 GHz, max turbo frequency 3.4 GHz.
• BM.GPU.A100: E4-based GPU compute.
• GPU: NVIDIA A100 80 GB
• CPU: AMD EPYC 7J13. Base frequency 2.55 GHz, max boost frequency 3.7 GHz.
• BM.GPU.MI300X.8: X10-based GPU compute.
• GPU: 8x MI300X 192 GB
• CPU: Intel Sapphire Rapids 8480+ 2x 56c. Base frequency 2 GHz, max boost frequency 3.8 GHz.
• BM.GPU.MI355X.8: X10-based GPU compute.
• GPU: 8x MI355X 288 GB
• CPU: 2 x 64-core AMD 5th Gen AMD EPYC™ Processors
• BM.GPU.L40S.4
• GPU: 4x L40S 48 GB
• CPU: 2 x 56-core Intel Sapphire Rapids 8480+
• BM.GPU.H100.8: X10-based GPU compute.
• GPU: 8x H100 80 GB
• CPU: Intel Sapphire Rapids 8480+ 2x 56c. Base frequency 2 GHz, max boost frequency 3.8 GHz.
• BM.GPU.H200.8
• GPU: 8x NVIDIA H200 Tensor Core GPUs 141 GB
• CPU: 2 x 56-core Intel Sapphire Rapids 8480+
• BM.GPU.B200.8
• GPU: 8x NVIDIA B200 Tensor Core GPUs 180 GB
• CPU: 2 x 64-core Intel Emerald Rapids 8592+
• BM.GPU.GB200.4
• GPU: 4 x NVIDIA Blackwell B200 192 GB
• CPU: 2 x 72-core NVIDIA Grace
• BM.GPU.GB300.4
• GPU: 4 x NVIDIA Blackwell B300 278 GB
• CPU: 2 x 72-core NVIDIA Grace

HPC and Optimized Shapes 🔗

Designed for high-performance computing workloads that require high frequency processor cores. Bare metal HPC and optimized shapes support cluster networking.

This is the bare metal optimized series:

• BM.Optimized3: Processor: Intel Xeon 6354. Base frequency 3.0 GHz, max turbo frequency 3.6 GHz.
• BM.HPC.E5: Processor: AMD EPYC 9J14. Base frequency 2.4 GHz, max boost frequency 3.7 GHz.

Notes

1: Please contact an Oracle sales representative for additional details.

Virtual Machine (VM) Shapes 🔗

The following shapes are available for VMs:

• Standard Shapes
• Dense I/O Shapes
• GPU Shapes
• HPC and Optimized Shapes

Network bandwidth is based on expected bandwidth for traffic within a VCN.

Standard Shapes 🔗

Designed for general purpose workloads and suitable for a wide range of applications and use cases. Standard shapes provide a balance of cores, memory, and network resources. Standard shapes are available with Intel, AMD, and Arm-based processors.

These are the VM standard series:

• VM.Standard3: X9-based standard compute. Processor: Intel Xeon Platinum 8358. Base frequency 2.6 GHz, max turbo frequency 3.4 GHz.
• VM.Standard.E2.1.Micro: E2-based, E3-based, or E4-based standard compute. Oracle Cloud Infrastructure assigns one of the following processors:
• AMD EPYC 7551. Base frequency 2.0 GHz, max boost frequency 3.0 GHz.
• AMD EPYC 7742. Base frequency 2.25 GHz, max boost frequency 3.4 GHz.
• AMD EPYC 7J13. Base frequency 2.55 GHz, max boost frequency 3.5 GHz.
• VM.Standard.E4: E4-based standard compute. Processor: AMD EPYC 7J13. Base frequency 2.55 GHz, max boost frequency 3.5 GHz.
• VM.Standard.E5: E5-based standard compute. Processor: AMD EPYC 9J14. Base frequency 2.4 GHz, max boost frequency 3.7 GHz.
• VM.Standard.E6: E6-based standard compute. Processor: AMD EPYC 9J45. Base frequency 2.7 GHz, max boost frequency 4.1 GHz.
• VM.Standard.A1:

OCI Ampere A1 Compute Arm-based standard compute. Each OCPU corresponds to a single hardware execution thread. Processor: Ampere Altra Q80-30. Max frequency 3.0 GHz.

• VM.Standard.A2:

OCI Ampere A2 Compute Arm-based standard compute. Each OCPU corresponds to two hardware execution threads (2 cores). Processor: Ampere AmpereOne A160-30. Max frequency 3.0 GHz.

• VM.Standard.A4: OCI Ampere A4 Compute Arm-based standard compute. Each OCPU corresponds to two hardware execution threads (2 cores). Processor: Ampere AmpereOne-M A06-36M. Frequency 3.6 GHz.

Dense I/O Shapes 🔗

Designed for large databases, big data workloads, and applications that require high-performance local storage. DenseIO shapes include locally-attached NVMe-based SSDs.

This is the VM dense I/O series:

• VM.DenseIO.E4: E4-based dense I/O compute. Processor: AMD EPYC 7J13. Base frequency 2.55 GHz, max boost frequency 3.5 GHz.
• VM.DenseIO.E5: E5-based dense I/O compute. Processor: AMD EPYC 9J14. Base frequency 2.6 GHz, max boost frequency 3.7 GHz.

Notes

1: Please contact an Oracle sales representative for additional details.

GPU Shapes 🔗

Designed for hardware-accelerated workloads. GPU shapes include Intel, AMD, or Arm CPUs with NVIDIA or AMD graphics processors.

These are the VM GPU series:

• VM.GPU2: X7-based GPU compute.
• GPU: NVIDIA Tesla P100 16 GB
• CPU: Intel Xeon Platinum 8167M. Base frequency 2.0 GHz, max turbo frequency 2.4 GHz.
• VM.GPU3: X7-based GPU compute.
• GPU: NVIDIA Tesla V100 16 GB
• CPU: Intel Xeon Platinum 8167M. Base frequency 2.0 GHz, max turbo frequency 2.4 GHz.
• VM.GPU.A10: X9-based GPU compute.
• GPU: NVIDIA A10 24 GB
• CPU: Intel Xeon Platinum 8358. Base frequency 2.6 GHz, max turbo frequency 3.4 GHz.

HPC and Optimized Shapes 🔗

Designed for high-performance computing workloads that require high frequency processor cores.

This is the VM optimized series:

• VM.Optimized3: Processor: Intel Xeon 6354. Base frequency 3.0 GHz, max turbo frequency 3.6 GHz.

Dedicated Virtual Machine Host Shapes 🔗

Notes

1: The difference between total and usable OCPUs and memory is caused by the need to reserve OCPUs and memory for hypervisor use.

2: Because this dedicated virtual machine host shape supports hosted VMs that use a previous generation shape series, it is available by request only.

3: For Standard2, Standard.E2, and DenseIO2 shapes, billing is based on OCPUs, not memory. For all other shapes that support flexible hosted VMs, billing is based on OCPUs and memory, which are billed independently.

Previous Generation Shapes 🔗

Tip

Previous generation shapes are still fully supported. However, because the underlying hardware has reached the sustaining phase of its lifecycle, capacity in certain high-demand regions might be limited.

Oracle Cloud Infrastructure periodically releases new generations of Compute shapes. The latest shapes let you take advantage of newer hardware and a better price-performance ratio. When a shape is several years old, and newer generation shapes that are suited for the same purposes are available, the old shape transitions to become a previous generation shape.

Your current utilization is fully supported on the previous generation shape. In certain high demand regions, you may need to plan your utilization growth on a newer generation shape.

Upgrading from a Previous Generation Shape 🔗

To upgrade from a previous generation shape to a current generation shape, you can do the following things:

• For supported VM instances, change the shape of the instance.
• For bare metal instances and VM instances that don't support changing the shape, [terminate the instance but DO NOT delete the boot volume](https://docs.oracle.com/en-us/iaas/Content/Compute/Tasks/terminatinginstance.htm "You can permanently delete (terminate) instances that you no longer need. Any attached VNICs and volumes are automatically detached when the instance terminates. Eventually, the instance's public and private IP addresses are released and become available for other instances."). Then, [use the boot volume to create a new instance](https://docs.oracle.com/en-us/iaas/Content/Compute/Tasks/launchinginstance.htm "Create a bare metal or virtual machine (VM) compute instance.").

Previous Generation Bare Metal Shapes 🔗

These are the previous generation bare metal shape series.

BM.Standard1

Newer shape recommendation: BM.Standard3.64, BM.Standard.E4.128, or BM.Standard.A1.160

End of orderability date: December 31, 2020

X5-based standard compute. Processor: Intel Xeon E5-2699 v3. Base frequency 2.3 GHz, max turbo frequency 3.6 GHz.

BM.Standard.B1

Newer shape recommendation: BM.Standard3.64, BM.Standard.E4.128, or BM.Standard.A1.160

End of orderability date: December 31, 2020

X6-based standard compute. Processor: Intel Xeon E5-2699 v4. Base frequency 2.2 GHz, max turbo frequency 3.6 GHz.

BM.Standard2

Newer shape recommendation: BM.Standard3.64, BM.Standard.E4.128, or BM.Standard.A1.160

End of orderability date: February 28, 2022

X7-based standard compute. Processor: Intel Xeon Platinum 8167M. Base frequency 2.0 GHz, max turbo frequency 2.4 GHz.

BM.Standard.E2

Newer shape recommendation: BM.Standard3.64, BM.Standard.E4.128, or BM.Standard.A1.160

End of orderability date: February 8, 2021

E2-based standard compute. Processor: AMD EPYC 7551. Base frequency 2.0 GHz, max boost frequency 3.0 GHz.

BM.Standard.E3

Newer shape recommendation: BM.Standard.E4.128, BM.Standard3.64, or BM.Standard.A1.160

End of orderability date: March 31, 2022

E3-based standard compute. Processor: AMD EPYC 7742. Base frequency 2.25 GHz, max boost frequency 3.4 GHz.

BM.DenseIO1

Newer shape recommendation: BM.DenseIO.E4

End of orderability date: December 31, 2020

X5-based dense I/O compute. Processor: Intel Xeon E5-2699 v3. Base frequency 2.3 GHz, max turbo frequency 3.6 GHz.

BM.DenseIO2

Newer shape recommendation: BM.DenseIO.E4

End of orderability date: April 14, 2022

X7-based dense I/O compute. Processor: Intel Xeon Platinum 8167M. Base frequency 2.0 GHz, max turbo frequency 2.4 GHz.

BM.HPC2

Newer shape recommendation: BM.Optimized3.36

End of orderability date: February 28, 2022

X7-based high frequency compute. Processor: Intel Xeon Gold 6154. Base frequency 3.0 GHz, max turbo frequency 3.7 GHz.

Previous Generation VM Shapes 🔗

These are the previous generation VM shape series.

VM.Standard1

Newer shape recommendation: VM.Standard3.Flex, VM.Standard.E4.Flex, or VM.Standard.A1.Flex

End of orderability date: December 31, 2020

X5-based standard compute. Processor: Intel Xeon E5-2699 v3. Base frequency 2.3 GHz, max turbo frequency 3.6 GHz.

VM.Standard.B1

Newer shape recommendation: VM.Standard3.Flex, VM.Standard.E4.Flex, or VM.Standard.A1.Flex

End of orderability date: December 31, 2020

X6-based standard compute. Processor: Intel Xeon E5-2699 v4. Base frequency 2.2 GHz, max turbo frequency 3.6 GHz.

VM.Standard2

Newer shape recommendation: VM.Standard3.Flex, VM.Standard.E4.Flex, or VM.Standard.A1.Flex

End of orderability date: February 28, 2022

X7-based standard compute. Processor: Intel Xeon Platinum 8167M. Base frequency 2.0 GHz, max turbo frequency 2.4 GHz.

VM.Standard.E2

Newer shape recommendation: VM.Standard3.Flex, VM.Standard.E4.Flex, or VM.Standard.A1.Flex

End of orderability date: February 8, 2021

E2-based standard compute. Processor: AMD EPYC 7551. Base frequency 2.0 GHz, max boost frequency 3.0 GHz.

VM.Standard.E3

Newer shape recommendation: VM.Standard.E4.Flex, VM.Standard3.Flex, or VM.Standard.A1.Flex

End of orderability date: March 31, 2022

E3-based standard compute, with a flexible number of OCPUs. Processor: AMD EPYC 7742. Base frequency 2.25 GHz, max boost frequency 3.4 GHz.

VM.DenseIO1

Newer shape recommendation: VM.DenseIO.E4 series

End of orderability date: December 31, 2020

X5-based dense I/O compute. Processor: Intel Xeon E5-2699 v3. Base frequency 2.3 GHz, max turbo frequency 3.6 GHz.

VM.DenseIO2

Newer shape recommendation: VM.DenseIO.E4 series

End of orderability date: April 28, 2022

X7-based dense I/O compute. Processor: Intel Xeon Platinum 8167M. Base frequency 2.0 GHz, max turbo frequency 2.4 GHz.

Was this article helpful?

YesNo

• Expand All Expandable Areas

• Compute Shapes
• Compute Shape Pricing
• Flexible Shapes
• Supported Images
• Supported Regions
• Extended Memory VM Instances
• Bare Metal Shapes
• Standard Shapes
• Dense I/O Shapes
• GPU Shapes
• HPC and Optimized Shapes
• Virtual Machine (VM) Shapes
• Standard Shapes
• Dense I/O Shapes
• GPU Shapes
• HPC and Optimized Shapes
• Dedicated Virtual Machine Host Shapes
• Previous Generation Shapes
• Upgrading from a Previous Generation Shape
• Previous Generation Bare Metal Shapes
• Previous Generation VM Shapes

Was this article helpful?

YesNo