Introduction to the key concepts of Oracle Cloud Infrastructure

September 22, 2020 | 6 minute read
Text Size 100%:

This blog post introduces you to the key concepts of Oracle Cloud Infrastructure (OCI). These concepts and terms are used throughout the Developer Resource Center and are the basis of the OCI and cloud resources that we’ll talk about in later posts.

Tenancies and Compartments

When you sign up for an Oracle Cloud Infrastructure account, you’re assigned a secure and isolated partition within the cloud infrastructure called a tenancy.

The tenancy has the same name as the cloud account that you selected during the sign-up process. If you want to change the tenancy name, you can do so by following these instructions.

The tenancy is a logical concept. You can think of it as a root container where you can create, organize, and administer your cloud resources.

The second logical concept used for organizing and controlling access to cloud resources is compartments. A compartment is a collection of related cloud resources. Your tenancy is also your root compartment.

You can create more compartments within your tenancy (up to six-levels deep) and use corresponding policies to control access to the resources in each compartment. Every time you create a cloud resource, you must specify the compartment that you want the resource to belong to.

The following figure shows a compartment called Engineering inside the root compartment. The Engineering compartment has two sub-compartments (for Project-A and Project-B), and each one of those compartments is further separated into multiple compartments.

Figure 1: Root tenancy and sub-compartments


This structure isolates resources between environments (development, QA, production) and different projects. You can apply policies to and designate administrators for each compartment. Creating more fine-grained policies ensures that users have access to the compartments that they need and that resources can connect to each other.

Create compartments

Let’s create a compartment structure like the one in the previous figure.

  1. Sign in to your OCI account.
  2. Open the navigation menu, select Identity, and then select Compartments.

Figure 2: Identity menu

  1. To create a sub-compartment in your tenancy, click Create Compartment.
  2. In the Create Compartment dialog, enter the name of the first compartment (in our example, Engineering) and a description, and then select the tenancy or root compartment from the Parent Compartment menu. Click Create Compartment.

Compartment names can’t have spaces, but they can contain hyphens (-) and periods (.).

Figure 3: Create compartments dialog box

When it’s created, the compartment is assigned an Oracle Cloud Identifier (OCID), like any other resource in OCI. You can read more about OCID and other resource identifiers in the documentation.

The OCID uses the following syntax:


The following example, shows what the OCID of your compartment might look like:


You can follow the same steps to create sub-compartments for Project A and Project B inside the Engineering compartment and the Dev, QA, and Prod compartments inside each project.

Here’s what the Project-A compartment details page looks like after its subcompartments are created:

Figure 4: Project-A Compartment


Policy inheritance and attachment

With the compartment hierarchy set up as described, the sub-compartments inherit all access permissions from the compartments higher up in the hierarchy. For example, the Prod compartment inherits the permissions from Project-A and Project-A inherits the permissions from the Engineering compartment.

When you create an access policy, you need to specify which compartment to attach it to. This setting controls who can later modify or delete the policy. For example, you could create an access policy for the Project-A compartment and attach it to the same compartment. With this design, you can give the administrators of the Project-A compartment access to manage their own compartment’s policies. However, if you attach that same access policy to the Engineering compartment, only people who have access to manage policies in the Engineering compartment can modify or delete the policy.

Moving resources between compartments

Most of the resources created in a compartment can be moved to another compartment. However, some resources can’t be moved, such as Container Engine for Kubernetes clusters, functions, or policies.

Additionally, some resources might have attached resource dependencies. When you move such resources, the attached dependencies move asynchronously. So, even if the parent resource is moved and immediately visible in the new compartment, it might take time for the attached dependencies to move and become visible in the new compartment.

For some resources, the attached resource dependencies don’t automatically move to the new compartment. You must move these resources independently.

Finally, be aware of how the policies work when moving resources between compartments. When you move a resource to a new compartment, the policies that govern the new compartment are immediately applied and will affect access to the resource.

To learn more about compartments, see the Managing compartments documentation.

Regions and Realms

Now that you understand what tenancies and compartments are and how they work, let’s look at regions and realms. When you signed up for your account, you selected your home region, and a tenancy was created for you in that region. Your home region is the geographic location where your account and Identity Access Management (IAM) resources are created.

You can create and update the following resources only in the home region:

  • Users
  • Groups
  • Policies
  • Compartments
  • Dynamic groups
  • Federation resources

You can’t change your home region. However, through the Console or the Oracle Cloud Infrastructure CLI, you can subscribe your tenancy to other regions.

If you’re using a trial, free tier, or pay-as-you-go tenancy, you are limited to one region.

When you subscribe to a region, the IAM resources in your home region are propagated and enforced in that region. Using policies you can define access levels for each region separately.

Updates to IAM resources are not immediately enforced in all regions. Allow up to several minutes for the changes to propagate.

If we take the compartment hierarchy from the previous example and subscribe to two more regions, we can then create individual resources in those regions as shown in the following figure. Notice that the compartments span the regions, but the resources within those compartments are created in specific regions.

Figure 5: Subscribed Regions


For more information more about supported regions, see the Data Regions page.

All Oracle Cloud Infrastructure resources are physically hosted in regions and in one or more availability domains. An availability domain is a data center located in a region. Availability domains (AD) are isolated from each other - they don’t share infrastructure, such as power or networking. This isolation minimizes the possibility of simultaneous failures. By using multiple availability domains, you can create a highly-available and resilient architecture.

A realm is a logical collection of regions. Realms are isolated from each other, and they don’t share any data. A tenancy can exist in a single realm, and it has access to the regions that belong to that realm. Currently, Oracle Cloud Infrastructure has a single commercial realm (OC1) and multiple realms for the Government Cloud.


This blog post gave you a short overview of some of the key concepts and terminology you need to understand when working with the Oracle Cloud Infrastructure. We briefly mentioned access policies, and we’ll explain those in more detail in the next post.

Additional Resources

Every use case is different. The only way to know if Oracle Cloud Infrastructure is right for you is to try it. You can select either the Oracle Cloud Free Tier or a 30-day free trial, which includes US$300 in credit to get you started with a range of services, including compute, storage, and networking.

Peter Jausovec

Peter Jausovec is a Consulting Solution Architect at Oracle working on cloud-native solutions. He has more than a decade of experience in the field of software development and tech, in various roles such as QA (test), software engineering and leading tech teams. He's been working in the cloud-native space for the past couple of years, and delivering talks and workshops around the world. He authored and co-authored a couple of books, latest being Cloud Native: Using Containers, Functions, and Data to Build Next-Generation Applications.

Previous Post

Podcast #385: Avi Miller on Linux, Open Source, Legos, and Development in 2020

Jim Grisanzio | 2 min read

Next Post

Working with identity and access management (IAM) in Oracle Cloud Infrastructure

Peter Jausovec | 5 min read