Working with Instances

Oracle Cloud Infrastructure Compute lets you provision and manage compute hosts, known as instances. You can create instances as needed to meet your compute and application requirements. After you create an instance, you can access it securely from your computer, restart it, attach and detach volumes, and terminate it when you're done with it.

Managing Tags for an Instance

Apply tags to your resources to help organize them according to your business needs. Apply tags at the time you create a resource, or update the resource later with the wanted tags. For general information about applying tags, see Resource Tags.

To manage tags for an instance:

  1. Open the navigation menu and click Compute. Under Compute, click Instances.
  2. Click the instance that you're interested in.

  3. Click the Tags tab to view or edit the existing tags. Or click More Actions, and then click Add tags to add new ones.

Security Zones

Security Zones ensure that your cloud resources comply with Oracle security principles. If any operation on a resource in a security zone compartment violates a policy for that security zone, then the operation is denied.

The following security zone policies affect the ability to create instances:

  • The boot volume for a compute instance in a security zone must also be in the same security zone.
  • A compute instance that isn't in a security zone can't use a boot volume that is in a security zone.
  • A compute instance in a security zone must use subnets that are also in the same security zone.
  • All compute instances in a security zone must be created using platform images. You can't create a compute instance from a custom image in a security zone.

Failing to implement one of the listed security zone policies might prevent the creation of an instance.

Required IAM Policy for Working with Instances

To use Oracle Cloud Infrastructure, you must be granted security access in a policy  by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don’t have permission or are unauthorized, verify with your administrator what type of access you have and which compartment  to work in.


When you create an instance, several other resources are involved, such as an image, a cloud network, and a subnet. Those other resources can be in the same compartment  with the instance or in other compartments. You must have the required level of access to each of the compartments involved in order to launch the instance. This is also true when you attach a volume to an instance; they don't have to be in the same compartment, but if they're not, you need the required level of access to each of the compartments.

For administrators: The simplest policy to let users create, edit, and terminate (delete) instances is listed in Let users launch compute instances. It gives the specified group general access to manage instances and images, along with the required level of access to attach existing block volumes to the instances. If the specified group doesn't need to launch instances or attach volumes, you could simplify that policy to include only manage instance-family, and remove the statements involving volume-family and virtual-network-family.

If the group needs to create block volumes, they'll need the ability to manage block volumes. See Let volume admins manage block volumes, backups, and volume groups.

If the group needs access to community images specifically, they'll need the ability to read community images. See Publishing Community Applications.

If you're new to policies, see Getting Started with Policies and Common Policies. For reference material about writing policies for instances, cloud networks, or other Core Services API resources, see Details for the Core Services.

Some Compute tasks require additional policies, as described in the following sections.

SSH and Remote Desktop Access

For users: To connect to a running instance with a Secure Shell (SSH) or Remote Desktop connection, you don't need an IAM policy to grant you access. However, you do need the public IP address of the instance.

For administrators: If there's a policy that lets users launch an instance, that policy probably also lets users get the instance's IP address. The simplest policy that does both is listed in Let users launch compute instances.

Here's a more restrictive policy that lets the specified group get the IP address of existing instances and use power actions on the instances (for example, stop or start the instance), but not launch or terminate instances. The policy assumes the instances and the cloud network are together in a single compartment (XYZ).

Allow group InstanceUsers to read virtual-network-family in compartment XYZ
Allow group InstanceUsers to use instance-family in compartment XYZ

Before You Begin

For administrators: To set up contextual notifications for an instance, use the following policy.

allow group ContextualNotificationsUsers to manage alarms in tenancy
allow group ContextualNotificationsUsers to read metrics in tenancy
allow group ContextualNotificationsUsers to manage ons-topics in tenancy
allow group ContextualNotificationsUsers to manage cloudevents-rules in tenancy

Instance Metadata Service (IMDS)

For users: No IAM policy is required if you're logged in to the instance and using cURL to get the instance metadata.

For administrators: Users can also get instance metadata through the Compute API (for example, with GetInstance). The policy in Let users launch compute instances covers that ability.

To require that legacy IMDSv1 endpoints are disabled on any new instances that are created, use the following policy:

Allow group InstanceLaunchers to manage instances in compartment ABC
 where request.instanceOptions.areLegacyEndpointsDisabled= 'true'

Capacity Reservations

For administrators: The following examples show typical policies that give access to capacity reservations. Create the policy in the tenancy so that the access is easily granted to all compartments by way of policy inheritance. To reduce the scope of access to just the capacity reservations in a particular compartment, specify that compartment instead of the tenancy.

Type of access: Ability to launch an instance in a reservation.

Allow group InstanceLaunchers to use compute-capacity-reservations in tenancy

Type of access: Ability to manage capacity reservations.

Allow group InstanceLaunchers to manage compute-capacity-reservations in tenancy

Run Command

For administrators: To write policy for the run command feature, do the following:

  1. Create a group that includes the users who you want to allow to issue commands, cancel commands, and view the command output for the instances in a compartment. Then, write the following policy to grant access for the group:

    Allow group RunCommandUsers to manage instance-agent-command-family in compartment ABC
  2. Create a dynamic group that includes the instances that you want to allow commands to run on. For example, a rule inside the dynamic group can state:

    any { = 'ocid1.instance.oc1.phx.<unique_ID_1>', 'ocid1.instance.oc1.phx.<unique_ID_2>' }
  3. Write the following policy to grant access for the dynamic group:

    If you create an instance and then add it to a dynamic group, it takes up to 30 minutes for the instance to start to poll for commands. If you create the dynamic group first and then create the instance, the instance starts to poll for commands as soon as the instance is created.
    Allow dynamic-group RunCommandDynamicGroup to use instance-agent-command-execution-family in compartment ABC where
  4. To allow the dynamic group to access the script file from an Object Storage bucket and save the response to an Object Storage bucket, write the following policies:

    Allow dynamic-group RunCommandDynamicGroup to read objects in compartment ABC where all { = '<bucket_with_script_file>'}
    Allow dynamic-group RunCommandDynamicGroup to manage objects in compartment ABC where all { = '<bucket_for_command_output>'}