OCI Limits, IAM Policies, and Identity Domain Disaster Recovery: What We Learned From Oracle

OCI Limits, IAM Policies, and Identity Domain Disaster Recovery: What We Learned From Oracle

Soft limits keep you out of trouble, hard limits keep moving, and there is one checkbox worth verifying today.

In the same session with Oracle's OCI identity team that I wrote about in my last post, one of our architects asked a question I suspect a lot of enterprise customers carry around quietly. Setting aside divestitures and business unit boundaries, are there scale limits that should push us toward multiple tenancies?

It is a fair question. Policy limits in particular had shaped some of our earlier decisions. The answer, and the conversation it opened up, covered service limits, policy design, and identity disaster recovery. All three are worth writing down.

Soft limits and hard limits are different things

Oracle drew a clean distinction between the two.

Soft limits are bumpers. They exist to keep you from getting yourself into trouble. A default cap on how many VMs you can launch is not there because Oracle cannot run more. It is there because a sudden jump to a very large number usually means something went wrong, a runaway script or a mistake, and the next call is usually a refund request. Need more? Ask, and the limit goes up.

Hard limits are architectural. They exist because going past them could affect you or other tenants. The example given was vaults backed by dedicated hardware security module capacity. A region has a finite pool, and some code paths were written with an expected upper bound. Asking for a handful more is routine. Asking for an unusually large number in one tenancy becomes a real conversation.

Two things stood out to me. Oracle tracks hard limits proactively and works with customers before they reach them. And hard limits are not static. Oracle continually evaluates them and raises them as customers demonstrate a need.

For perspective, Oracle noted that some customers run thousands of VMs across dozens of regions and move enormous volumes of data continuously. A typical enterprise application footprint, ours included, is nowhere near the hard limits they see elsewhere.

The policy limit story is a good example

IAM policy limits used to be one of those hard limits, and the old tenancy-wide ceiling was tight for large organizations. Customers told Oracle they needed more. Oracle worked with them, changed how the policy engine evaluates policies, and the old ceiling no longer applies the way it once did. The limit is now applied along the compartment hierarchy rather than as a single flat number for the tenancy.

The practical consequence is that placement matters. Put everything at the root and you concentrate your budget in one place. Put policies in the compartments where they are actually needed and the limit largely stops being a constraint. Check the current OCI documentation for exact numbers, because they have moved and will move again.

Oracle also shared, with the appropriate grain of salt for anything roadmap-related, that a significant effort is underway to raise policy limits from the hundreds into the thousands. Their suggestion was to understand where you are and where Oracle is heading before investing heavily in reducing policy counts on a short timeline.

The default policies are simple on purpose

If you have several Fusion pods, you have probably noticed that each identity domain arrives with its own set of policies at the root of the tenancy. Multiply that across many domains and the root gets crowded quickly.

Oracle was direct about why those policies look the way they do. They are intentionally simple, typically one group, one resource type, one location per statement. That makes them easy to read and reason about, and they were designed with typical customers in mind rather than those running a large number of identity domains.

Two things follow from that:

·        They can be consolidated. Multiple groups and resource types can be combined into fewer statements while still expressing least privilege. Our team has worked through this. It is very doable, though it takes care.

·        Most of them do not have to live at the root. A small number of tenancy-level permissions do, but most resources, and the policies governing them, can live in compartments.

Oracle offered two perspectives that I think are both right. First, simple policies have value. If they work for you, do not rush to optimize them away just to reduce a count, especially with limits increasing. Second, from a security standpoint, a crowded root is not ideal. The more that lives at the root, the more there is to watch. Our own cleanup effort is aimed at the second point without giving up the readability of the first.

Oracle also offered to walk through the consolidation with us, which I appreciated.

Identity domain disaster recovery: go check the box

This is the part of the session I would most encourage other customers to act on.

A tenancy's Default identity domain is homed in the tenancy's home region. If disaster recovery is enabled, and a region-level disaster takes the home region down, Oracle is responsible for bringing that domain up in the paired disaster recovery region so you can keep managing your resources elsewhere.

The details matter:

·        The domain comes back with the same URL and hostname.

·        The IP address may change.

·        Client IDs, secrets, and the applications relying on the domain continue to work.

·        It does not cost anything extra.

·        It only happens if the option is enabled. If it is not, Oracle cannot move the domain.

That last point is why I say go check. It takes minutes to confirm, and you do not want to find out during an incident.

HA and DR are not the same thing

Oracle made a distinction that is easy to blur. Within a region, identity domains run as highly available microservices. Disaster recovery to another region is something different, reserved for serious, region-level events expected to last hours or days.

A 20 or 30 minute disruption will usually not trigger a regional failover, because relocating a domain takes time and would likely take longer than the disruption itself. That is a sensible trade-off, and it should shape your expectations and your runbooks. Identity DR protects you from catastrophe, not from every hiccup.

Make sure identity lives where your workloads live

One more design point came out of this. Identity domains serve the workloads that depend on them. If a domain is homed in a different region from the applications it supports, which happened with some older IDCS provisioning, an outage in the identity region can affect production running in a perfectly healthy region. Oracle acknowledged the pattern and agreed it is something to solve for as part of a longer-term identity plan.

My own addition, not something Oracle said: if you have firewall rules or allowlists tied to IP addresses for identity endpoints, revisit them. Oracle's DR commitment is built around the hostname. Build around the hostname too.

A short checklist

1.      Confirm disaster recovery is enabled for the identity domains you depend on.

2.      Confirm each domain's home region aligns with the region where the workloads it serves run.

3.      Replace IP-based dependencies on identity endpoints with hostname-based ones.

4.      Inventory the policies at your root. Separate the few that truly must be there from those that can move to compartments.

5.      Consolidate where it improves clarity, not only to reduce a count, and watch Oracle's limit increases before committing to a large reduction effort.

6.      If you think you are approaching a hard limit, talk to Oracle early. They would rather hear from you before you hit it.

They do not stand still

Near the end of the session, someone on our side observed that there always seems to be something new coming in OCI. Oracle's reply was simple: they don't stand still.

That feels like the right note to end on. Several constraints that shaped enterprise OCI designs a few years ago have already been lifted, and more are on the way. Design for today's limits, but revisit the assumptions behind your architecture regularly. Some of the reasons you split things apart may not apply anymore.

Based on a working session between our team and Oracle's OCI identity team in September 2026, combined with Oracle's public documentation. Product behavior, limits, and licensing change over time. Confirm specifics against your own environment and your Oracle account team. Views are my own.

One Tenancy or Many? What Oracle Told Us About Tenancies, Identity Domains, and Fusion

 One Tenancy or Many? What Oracle Told Us About Tenancies, Identity Domains, and Fusion

A tenancy is a hard boundary by design. Once that clicks, most of the other decisions get easier.

If your organization has been on Oracle Cloud for a while, there is a good chance your footprint did not arrive all at once. Fusion pods came first, or PaaS services did. A new module showed up with its own activation email. Somebody made a reasonable call at the time, and a few years later you are looking at several tenancies, a growing list of identity domains, and a question nobody can answer in one sentence: where should the next thing go?

That is where our team is. We recently sat down with Oracle's OCI identity team to talk less about how we got here and more about where Oracle is heading, and how a customer should think about tenancies and identity going forward. I want to write down what I took away from it.

Start with the vocabulary

Oracle Cloud identity runs on OCI IAM with identity domains. If you have been around long enough to remember IDCS, identity domains are where that capability lives now.

When you get a tenancy, you get one identity domain automatically, the Default domain. It exists so you can sign in to the tenancy, manage it, and do everything else an administrator does there. You can create additional domains for other purposes.

When you buy Fusion, things get more interesting.

Why every Fusion pod has its own identity domain

Buy three Fusion pods for development, test, and production, and you get three identity domains, one pre-wired to each pod, in addition to the tenancy's Default domain.

That surprises people at first. It seems like a lot of identity. The reasoning is sound, and the example Oracle used made it click for me.

Picture a developer configuring a timesheet approval flow. To prove it works, they need to sign in as the employee who submits the timesheet, then the manager who approves it, then the director above that. In a development environment that usually means a set of test users the developer controls. You cannot wire that environment to your production corporate identity provider, because those test personas do not, and should not, exist there.

So each pod is its own island of identity. Development gets test identities. Pre-production connects to your pre-production identity system. Production connects to production. Not every customer works that way, but it is a very common pattern and Oracle has to support the customers who do.

The greenfield picture

This is the part I found most clarifying. If you provision PaaS services to support a Fusion environment, such as Visual Builder, Integration, Analytics Cloud, Fusion Data Intelligence (formerly Fusion Analytics Warehouse), or Autonomous Database, you provision them in the same tenancy using the same identity domain as the pod they support.

Do that, and they are pre-integrated. No extra trust to set up, and no federation to maintain between services that are supposed to behave as one environment.

The picture Oracle described for a customer starting today looks like this:

·        One tenancy, with compartments per environment.

·        A development compartment holding the dev Fusion pod and the dev instances of Integration, Visual Builder, and whatever else supports it, all sharing the dev identity domain.

·        A pre-production compartment that mirrors it, and a production compartment that mirrors that.

·        Integrations, extensions, and configuration promoted through those environments the way you would expect.

Oracle was candid that most long-standing customers, us included, do not look like this, because services were provisioned at different times for reasons that made sense then. It is a target state, not a judgment on anyone's current state. Getting from here to there is its own conversation, and one Oracle offered to work through with us.

Everything Oracle runs is on OCI

One comment reframed things for a few people in the room. We tend to talk about moving PaaS "into the same OCI as Fusion" as if Fusion recently arrived there. It did not. Fusion has run on OCI for a long time, as does essentially everything Oracle offers, homegrown or acquired.

What has changed is visibility. Services are progressively surfacing in the Oracle Cloud console at cloud.oracle.com, which is the console for all of Oracle Cloud rather than only infrastructure. When people say "OCI" they usually mean compute, storage, and networking. The console is that, plus PaaS, plus SaaS, and Oracle's direction is that everything you subscribe to shows up there.

It also explains how so many of us ended up with split tenancies. Fusion pods originally existed without any tenancy at all. You signed a contract and consumed your environments from their URLs. When tenancies were introduced a few years ago to give customers a way to manage everything, Fusion pods were attached to one, and PaaS services bought earlier often lived in another.

A tenancy is a box, on purpose

The question our team was most eager to ask: could we simply move things between tenancies to consolidate?

The short answer is no, and the reason is a good one. When a tenancy is created, keys and certificates are generated for it and held in hardware security modules. Tenancies are a hard partition, and Oracle has intentionally not built tooling to move resources from one to another. A compute instance, a block volume, an Integration instance, a Fusion pod: whatever is created in a tenancy stays in that tenancy.

What you can do is rebuild and migrate:

·        Export and import configuration, such as Integration projects, users and groups, and API gateway definitions.

·        Use Terraform to recreate infrastructure and the PaaS service instances themselves.

·        Use the standard environment migration and refresh tooling where it applies.

Plan for the fact that a rebuilt instance is a new instance. It will have a new URL, and anything that pointed at the old one needs to change.

I appreciated the framing. A tenancy is a box that things can come into and go out of, but cannot slide sideways between. Once you accept that, "move" stops being the right word, and the real questions become whether a rebuild is worth it and where the new thing should be born.

Where new subscriptions land

That leads to the most practical takeaway I would pass to anyone buying something new from Oracle.

When you subscribe to a new Fusion service, the person who placed the order receives an activation email. It asks where you want the service to go: an existing tenancy, or a new one.

Expanding an existing subscription is different. If you have three pods and add two more, the new ones are provisioned alongside the existing ones in the same tenancy.

Oracle's direction is that SaaS services live in a tenancy. For a specific product, confirm how activation works before you assume. Oracle sells a lot of SaaS, and not every service follows exactly the same path today.

My advice is to treat that activation click as an architecture decision, not an administrative step. Decide where a new service belongs before the email arrives. We have made that call deliberately in the past, including once choosing a new, isolated tenancy on purpose, and I was glad we had talked it through first.

So, one tenancy or many?

Oracle's position was balanced. You can put everything in one tenancy, and for a smaller organization a single tenancy is ideal. There are also legitimate reasons larger enterprises do not:

·        Business units that operate independently, or could be divested someday. Separating a tenancy after the fact is hard, so if a unit might leave, it probably belongs in its own.

·        Administrative separation, where different groups need clearly distinct control.

The counterpoint Oracle offered is the one I keep coming back to. If it is your HR system and everything that supports it, and you are buying it from Oracle, it makes sense to keep it together unless you have a specific reason not to. The same applies to ERP.

A separate tenancy also comes with work. A few things our team noted you take on:

·        Network connectivity. A new tenancy does not automatically share your existing FastConnect. Remote peering or a hub-and-spoke design can bridge it, but it has to be designed.

·        Identity wiring. Inside one tenancy, the same identity flows naturally across Fusion, Integration, analytics, and the rest of an environment. Across tenancies, you build and maintain that federation yourself. This matters more every release, especially as capabilities like AI Agent Studio span product families and benefit from a common identity.

·        Commercial alignment. Subscriptions and credits are associated with a tenancy, so how you consume services in a new one is a conversation for your account team.

A word on identity domain types

One more piece helps explain the design. The Default domain in a tenancy is a Free domain type intended for managing the tenancy, and its user limit reflects that purpose. The identity domain delivered with a Fusion pod is an Oracle Apps domain type, provided as part of the Fusion subscription. It covers what your users need to access Fusion and the services supporting it in the same tenancy.

If you still carry bring-your-own licensing assumptions from older IDCS or on-premises identity deployments, it is worth revisiting them. For the Fusion use case you may not need them. If you plan to use a Fusion identity domain well beyond supporting Fusion, have that licensing conversation with your account team up front.

What I am taking away

·        Design toward the target state: one tenancy per logical platform, compartments per environment, and supporting PaaS provisioned against the same identity domain as the Fusion pod it supports.

·        Stop saying "move." Resources do not move between tenancies. Plan rebuilds with export, import, and Terraform, and plan for new URLs.

·        Decide where new services land before the activation email arrives.

·        Create a new tenancy when there is a genuine boundary, such as an independent or divestible business unit, and budget for the networking, identity, and commercial work that comes with it.

·        Keep identity consistent within each environment. The more your Oracle products work together, the more that pays off.

We closed the session with a standing offer from Oracle to go deeper on specifics once we have worked out what we want our architecture to achieve. That is the next step on our side, and I will share what we learn.

Based on a working session between our team and Oracle's OCI identity team in September 2026, combined with Oracle's public documentation. Product behavior, limits, and licensing change over time. Confirm specifics against your own environment and your Oracle account team. Views are my own.