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.
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.
Let’s create a compartment structure like the one in the previous figure.
Figure 2: Identity menu
Compartment names can’t have spaces, but they can contain hyphens (-) and periods (.).
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:
ocid1.<RESOURCE TYPE>.<REALM>.[REGION][.FUTURE USE].<UNIQUE ID>
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
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.
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.
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:
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.
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.
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.