Oracle Cloud Compartments and the Always Free Tier Explained

Everything starts with the tenancy

Sign up for Oracle Cloud Infrastructure and the first object created on your behalf is a tenancy. It is the top of the hierarchy, the thing your invoice is addressed to, and the container every other resource ultimately lives inside. Each tenancy carries an Oracle Cloud Identifier, a long string beginning ocid1.tenancy.oc1.. that you will paste into configuration files more often than you expect.

A tenancy also has a home region, chosen at signup. Identity objects such as users, groups and policies are mastered there, even when your compute and storage run elsewhere. The home region cannot be casually changed afterwards, so it is worth a moment of thought during signup rather than a shrug.

The tenancy is simultaneously the root compartment. That dual role confuses newcomers, because the tenancy appears in compartment pickers alongside the compartments you create. It helps to read it as: the root is a compartment, and every compartment you make is a child of it.

Compartments are the idea that makes OCI click

Where AWS reaches for separate accounts and Google Cloud reaches for projects, Oracle reaches for compartments. A compartment is a logical container that holds resources, can be nested inside another compartment, and acts as the unit that access policies and quotas are written against.

Three properties matter in daily use. A resource lives in exactly one compartment at a time. Compartments nest, so a Production compartment can contain Network, Database and Application children. And resources can be moved between compartments after creation, which makes an imperfect initial layout recoverable rather than permanent.

Because compartments are free to create and cheap to reorganise, the usual advice is to create a small set early rather than dumping everything into the root. A workable starting layout separates shared networking from workloads and separates environments from each other:

• Network for the virtual cloud network, subnets, gateways and DRG attachments that several teams share.
• Security for the Vault, keys, logging configuration and audit-related resources.
• Prod and NonProd for workload resources, each with children per application if the estate grows.
• Sandbox for experiments, with a quota policy that stops anyone spending seriously in it.

Compare that with the equivalents described in what a cloud account is. The compartment is closer to a Google Cloud folder than to an AWS account, because it provides policy scope without providing a separate billing entity.

Policies are sentences about compartments

OCI policy is unusual and, once you adjust, pleasant. Instead of JSON documents, you write near-English statements that name a group, a verb, a resource type and a compartment. A typical rule reads:

Allow group Developers to manage instance-family in compartment NonProd

The verbs form a ladder of increasing power: inspect lets you list, read adds the contents, use adds working with existing resources, and manage adds creating and deleting. Resource types come in families, so instance-family covers compute instances and their close relatives while object-family covers buckets and objects.

Policies attach to a compartment or to the tenancy, and permissions flow downward into nested compartments. That inheritance is what makes a sensible compartment tree so valuable: one statement at the right level replaces a dozen at the wrong one.

Two additions are worth knowing early. Dynamic groups let resources themselves, such as instances, be granted permissions without embedding credentials. Compartment quotas are written in the same declarative style and let you cap how much of a service may be consumed inside a compartment, which is the cleanest way to stop a sandbox becoming expensive. The broader principles behind all of this are covered in cloud IAM fundamentals.

The Always Free tier and what sits inside it

Oracle's entry offer has two parts that are easy to conflate. The first is a time-limited trial with promotional credit, which behaves like the trials on other platforms and expires. The second is the Always Free allocation, a set of resources that keeps running after the trial ends for as long as the tenancy stays in good standing.

The Always Free set is the reason the platform gets attention from developers. It spans several service families rather than a single token instance:

Two caveats save disappointment. Always Free Arm capacity is subject to availability in a given region, so a launch can fail with an out of capacity response even though your entitlement is intact; trying a different availability domain or a different region is the normal response. And an Always Free resource that sits idle for a long period may be reclaimed, so treat the tier as a working environment rather than a parking space.

What changes when the account moves to paid

Upgrading a tenancy to pay as you go keeps the Always Free resources in place and adds everything the trial restricted. Higher shapes become launchable, service limits become eligible for increase requests, and usage beyond the free allocations is metered against universal credits.

The distinction between trial credit and a standing free allowance is exactly the one drawn in free trial versus pay-as-you-go. Oracle is unusual in keeping a meaningful permanent allowance after conversion, which makes the upgrade less of a cliff than it is elsewhere.

After upgrading, check service limits per region before planning anything substantial. OCI expresses these as limits on shapes and services, visible under Limits, Quotas and Usage, and they are separate from the compartment quotas you set yourself. One is a ceiling from Oracle; the other is a ceiling you impose internally.

Finding your way with the OCI CLI

The command line makes the hierarchy concrete faster than the console does. Start by generating a configuration profile, then list the compartment tree:

oci setup config

oci iam compartment list --compartment-id-in-subtree true --all

Every subsequent command takes a compartment OCID, which is the clearest possible demonstration that compartments are not cosmetic. To see where you can place an instance and then launch one:

oci iam availability-domain list --compartment-id $C

oci compute instance launch --compartment-id $C --availability-domain AD-1 --shape VM.Standard.A1.Flex --shape-config '{"ocpus":1,"memoryInGBs":6}' --image-id $IMAGE --subnet-id $SUBNET

Notice the flexible shape configuration. Ampere A1 and the flexible AMD shapes let you choose core count and memory independently rather than picking from a fixed menu, which is one of the platform's more developer-friendly touches. Oracle documents the full command set in its OCI command line interface documentation.

Questions Oracle Cloud newcomers ask