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.

AI Configurator Is Deprecated in 26C. Here Is What It Means for Prompts You Already Changed.

AI Configurator Is Deprecated in 26C. Here Is What It Means for Prompts You Already Changed.

The notification tells HCM customers to stop using it. It is far less clear about the work you have already done.

If you run Oracle Fusion HCM and anyone on your team has ever edited a prompt behind an embedded AI feature, you probably received a notification recently. Starting in Update 26C, AI Configurator is deprecated and replaced by AI Agent Studio. The immediate action listed is to stop using AI Configurator and make sure prompts are not propagated to production.

Clear enough on its own terms. The question it left our team with was a different one. What happens to the prompts we already modified? Do they stop working at 26C? Do we have to redo that work, and if so, by when?

The notice does not say. We had time scheduled with Oracle's AI product management team, so I asked. Between that conversation and the readiness documentation, here is the fuller picture.

What the documentation actually says

The 26C readiness note is worth reading directly rather than relying on the summary in the notification email. Several things in it matter.

AI Configurator is described as the built-in tool inside Oracle HCM Experience Design Studio, used for locally editing prompts for embedded AI features. It is deprecated in 26C.

If you previously configured prompts with it, the documentation is direct about what you owe. You must re-create and revalidate those configurations in AI Agent Studio. That is not framed as optional.

It also states that you retain access to AI Configurator so you can copy your prompts and reuse them in Agent Studio. This is not a case of the tool vanishing and taking your work with it.

What the documentation does not say is when. That is the part I wanted answered.

What Oracle told us about timing

Existing configurations do not stop working when 26C lands. That was stated plainly. There is no date on which your modified prompts revert to Oracle defaults and your users notice a difference.

The trigger for action is more specific than a release number. Today some of these embedded use cases call a completion endpoint. Oracle is progressively moving each use case over to the invoke agent and invoke sync APIs instead. When a use case you modified makes that move, your prompt change needs to already exist in Agent Studio, in the relevant LLM node, for it to keep applying.

So the re-creation the documentation asks for is real work you need to plan. The sequencing follows Oracle's migration of each individual use case rather than a single cutover date.

From an end user perspective, none of this is visible. Same experience, different plumbing underneath.

A short note on what AI Configurator was

Worth a detour, because plenty of people received this notification without a clear sense of what the tool did.

Fusion has embedded AI features throughout the interface, the ones sitting behind an AI Assist button. Goal setting is the example most people recognize. You click it and the system drafts goals in the SMART format, specific and measurable and the rest.

That formatting instruction lives in a prompt. Some organizations wanted a different structure, different language, or different emphasis for reasons of their own. AI Configurator existed so you could modify that prompt without involving Oracle.

If nobody at your organization ever opened it, this deprecation does not create work for you.

The practical sequence

This is the order we landed on, and I think it generalizes to most HCM customers in the same position.

1.        Build an inventory of what you actually modified. Which use cases, what changed, and why. This is the step people skip and it is the one that matters most.

2.        Copy the prompts out of AI Configurator. Put them somewhere you control rather than leaving them inside a tool being retired.

3.        If something cannot be recovered, ask Oracle. They confirmed they can retrieve prompts from the underlying tables if needed.

4.        Re-create and revalidate in Agent Studio, sequenced against Oracle moving each use case to the agent framework.

On the first step, the notification identified the environments where prompts had been configured, which is a helpful pointer, but it does not tell you which specific use cases were touched or what the change was. That inventory is yours to build.

I would also involve whoever asked for the original change rather than treating this as a purely technical exercise. Someone modified that prompt for a business reason. Migrating the text without carrying the reasoning forward means you cannot revalidate it properly, and revalidation is explicitly part of what Oracle is asking for.

The access requirement people will trip over

The readiness note contains one line that is easy to skim past. You must have access to use AI Agent Studio.

That access is not automatic. AI Configurator lived inside HCM Experience Design Studio. Agent Studio is a separate tool with its own access requirements. There is a reasonable chance the person who made your original prompt changes cannot get into Agent Studio today.

Sort that out before you reach the migration work rather than during it.

On cost

I asked directly whether maintaining these configurations after the move generates any additional charge. The answer was no.

The reasoning holds up. These embedded use cases are simple calls, summarization and short text generation, comfortably within what a hosted model handles. Oracle hosts a model for this category of work and treats calls to it differently from models it has to source externally. This kind of usage did not generate a bill before and does not after.

I have written separately about how that metering works, because it is the most misunderstood part of Fusion AI right now.

Why the destination is better than the origin

I will be honest that a deprecation notice with an unclear impact statement is irritating, and I said as much on the call. That said, where this lands is genuinely better, and the readiness documentation is specific about why.

·        Prompt configuration and agent configuration stop living in two separate tools.

·        Access control improves. Prompts inherit the same security model as agents, so an HCM administrator cannot configure prompts belonging to other product families. If you care about governance, that is substantive rather than cosmetic.

·        You get a broader range of models to choose from.

·        You can evaluate a prompt before publishing it. Editing prompt text in isolation and hoping for the best is how most of us have worked until now.

·        You get the full set of workflow nodes for editing, plus the ability to add and remove variables, which AI Configurator did not offer.

What I would still like to see

Two things, offered as the feedback I would want if our positions were reversed.

Clearer impact statements in deprecation communications. The notice told customers to stop using a tool without addressing the status of work already done with it. That single gap produced more internal speculation on our side than the migration itself will produce work. One sentence would have covered it.

Published sequencing for the underlying migration. Because the practical trigger is Oracle moving each use case to the agent framework, knowing which use cases move in which update would let customers plan instead of react. That timing is not visible from outside today.

Neither of these is a reason to be worried about the change. Both are the kind of thing that would make the next one land better because this change is actually a huge improvement and something to be excited about!

Where to read more

Oracle's 26C readiness note covering the deprecation and transition is at docs.oracle.com under the HCM 26C common technologies what's new, titled Deprecation of AI Configurator and Transition to AI Agent Studio.

If you received the notification and have not started, begin with the inventory. Everything else depends on knowing what you actually changed.

Based on Oracle's 26C readiness documentation and customer notification, combined with a working session between our team and Oracle's Fusion AI product management group in August 2026. Statements about migration timing and cost reflect that conversation and are not a substitute for Oracle's published guidance. Confirm specifics against your own environment and your Oracle account team. Views are my own.