Best Practices for Your Compute Instances

Oracle Cloud Infrastructure Compute provides bare metal and virtual machine (VM) compute capacity that delivers performance, flexibility, and control without compromise. It's powered by Oracle’s next generation, internet-scale infrastructure, designed to help you develop and run your most demanding applications and workloads in the cloud.

You can provision compute capacity through an easy-to-use web console or the API, SDKs, or CLI. The compute instance, once provisioned, provides you with access to the host. This gives you complete control of your instance.

Though you have full management authority for your instance, we recommend a variety of best practices to ensure system availability and top performance.

IP Addresses Reserved for Use by Oracle

Certain IP addresses are reserved for Oracle Cloud Infrastructure use and may not be used in your address numbering scheme.

These addresses are used for iSCSI connections to the boot and block volumes, instance metadata, and other services.

Class D and Class E

All addresses from to (Class D) are prohibited for use in a VCN, they are reserved for multicast address assignments in the IP standards. See RFC 3171 for details.

All addresses from to (Class E) are prohibited for use in a VCN, they are reserved for future use in the IP standards. See RFC 1112, Section 4 for details.

Three IP Addresses in Each Subnet

These addresses consist of:

  • The first IP address in the CIDR (the network address)
  • The last IP address in the CIDR (the broadcast address)
  • The first host address in the CIDR (the subnet default gateway address)

For example, in a subnet with CIDR, these addresses are reserved:

  • (the network address)
  • (the broadcast address)
  • (the subnet default gateway address)

The remaining addresses in the CIDR ( to are available for use.

Essential Firewall Rules

All platform images include rules that allow only "root" on Linux instances or "Administrators" on Windows Server instances to make outgoing connections to the iSCSI network endpoints (, that serve the instance's boot and block volumes.

  • We recommend that you do not reconfigure the firewall on your instance to remove these rules. Removing these rules allows non-root users or non-administrators to access the instance’s boot disk volume.

  • We recommend that you do not create custom images without these rules unless you understand the security risks.

  • Running Uncomplicated Firewall (UFW) on Ubuntu images might cause issues with these rules. Because of this, we recommend that you do not enable UFW on your instances. See Ubuntu instance fails to reboot after enabling Uncomplicated Firewall (UFW) for more information.

System Resilience

Follow industry-wide hardware failure best practices to ensure the resilience of your solution in the event of a hardware failure. Some best practices include:

  • Design your system with redundant compute nodes in different availability domains to support failover capability.
  • Create a custom image of your system drive each time you change the image.
  • Back up your data drives, or sync to spare drives, regularly.
If you experience a hardware failure and have followed these practices, you can terminate the failed instance, launch your custom image to create a new instance, and then apply the backup data.

Uninterrupted Access to the Instance

Make sure to keep the DHCP client running so you can always access the instance. If you stop the DHCP client manually or disable NetworkManager (which stops the DHCP client on Linux instances), the instance can't renew its DHCP lease and will become inaccessible when the lease expires (typically within 24 hours). Do not disable NetworkManager unless you use another method to ensure renewal of the lease.

Stopping the DHCP client might remove the host route table when the lease expires. Also, loss of network connectivity to your iSCSI connections might result in loss of the boot drive.

User Access

If you created your instance using a Linux platform image, you can use SSH to access your instance from a remote host as the opc user. After logging in, you can add users on your instance.

If you do not want to share SSH keys, you can create additional SSH-enabled users.

If you created your instance using a Windows platform image, you can access your instance using a Remote Desktop client as the opc user. After logging in, you can add users on your instance.

For more information about user access, see Adding Users to an Instance. For steps to log in to an instance, see Connecting to an Instance.

NTP Service

Oracle Cloud Infrastructure offers a fully managed, secure, and highly available NTP service that you can use to set the date and time of your compute and Database instances from within your virtual cloud network (VCN). The NTP service is enabled by default on all of the platform images that are available in Oracle Cloud Infrastructure. For information about this service, see Configuring the Oracle Cloud Infrastructure NTP Service for an Instance.

Fault Domains

A fault domain is a grouping of hardware and infrastructure that is distinct from other fault domains in the same availability domain. Each availability domain has three fault domains. By properly leveraging fault domains, you can increase the availability of applications running on Oracle Cloud Infrastructure. See Fault Domains for more information.

Your application's architecture determines whether you should separate or group instances using fault domains.

Scenario 1: Highly Available Application Architecture

In this scenario, you have a highly available application, for example you have two web servers and a clustered database. In this scenario, you should group one web server and one database node in one fault domain and the other half of each pair in another fault domain. This placement ensures that a failure of any one fault domain does not result in an outage for your application.

Scenario 2: Single Web Server and Database Instance Architecture

In this scenario, your application architecture is not highly available, for example you have one web server and one database instance. In this scenario, both the web server and the database instance should be placed in the same fault domain to minimize customer outages. This placement ensures that your application is only impacted by the failure of that single fault domain, providing greater application availability overall.

Customer-Managed Virtual Machine (VM) Maintenance

When an underlying infrastructure component needs to undergo maintenance, by default, Oracle Cloud Infrastructure sends a notification about the upcoming maintenance event. After 14 to 16 days, the VM instances are live migrated from the physical VM host that needs maintenance to a healthy VM host without disrupting running instances. Alternately, you can choose to have your instances automatically live migrated without a notification. If a VM cannot be live migrated, a short downtime occurs while the instance is reboot migrated.

You can control how and when your applications experience maintenance downtime by proactively rebooting (or stopping and starting) the instances at any time before the scheduled maintenance event. A maintenance reboot is different from a normal reboot. When you reboot an instance for maintenance, the instance is stopped on the physical VM host that needs maintenance, and then restarted on a healthy VM host.

If you choose not to reboot before the scheduled time, then Oracle Cloud Infrastructure migrates the instances before proceeding with the planned infrastructure maintenance. Optionally, you can configure the instances to remain stopped after they are reboot migrated. For more information, see Recovering a Virtual Machine (VM) During Planned Maintenance.