> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/solution-architecture/deployment/platform-service-topologies.md). # Topologies using cloud platform services The three topologies that substitute cloud platform services for part of OpenIAM's stateful tier — which components you hand away, what that changes, and what you still operate yourself. ## What this is, and when you need it Three of the nine shipped topologies keep OpenIAM's services on virtual machines but move part of the stateful tier to cloud platform services. This page is about what that substitution actually changes: which components leave your operational scope, which stubbornly do not, and what the substitution does to availability, cost and network design. You need it when the deployment is in a public cloud and someone has asked how much of the stateful tier can be handed to the platform. The honest answer is "most of it on AWS, less on Google Cloud, less again on Azure" — and the difference is large enough to change a design. ## The decision | Topology | Nodes | Handed to the platform | Still yours | | ------------------------------------------------------ | ----------------------------------------------------------------------------- | --------------------------------------- | -------------------------------------------------------------------------------------------------------- | | **5. Non-HA with platform services** | One Linux VM | Relational database, cache, graph store | Message broker, secrets store, search tier, all OpenIAM services, all consoles, the reverse proxy | | **6. Medium HA with platform services** | Three Linux nodes behind a load balancer | Relational database, cache, graph store | The same list, clustered across the three nodes | | **7. Large HA with platform and distributed services** | Three console and reverse-proxy nodes; three service and infrastructure nodes | Relational database, cache, graph store | Broker, secrets store and search tier on the service nodes; a network path to on-premise connector hosts | The three components you can hand away are the same in all three shapes. What changes between them is node count and how the remaining self-managed components are laid out, exactly as in the packaged Linux topologies. ## What actually leaves your scope Being precise about this matters, because "we will use managed services" is usually said with a larger scope in mind than the shipped material supports. **The relational database leaves your scope completely, and it is the most valuable of the three to hand away.** It is the one component holding a system of record with no rebuild path, so backup, point-in-time recovery, failover and patching becoming somebody else's problem is the single largest reduction in operational risk available in any OpenIAM deployment. What you give up is engine and version choice: each cloud's shipped module supports a subset of OpenIAM's four database families, and the subsets do not match. [Platform support matrix](/solution-architecture/deployment/platform-support-matrix.md) has the detail. **The cache leaves your scope, and loses nothing if it fails.** Redis holds cached configuration and entitlement data and the distributed locks that stop several nodes doing the same startup work at once. It is a hard dependency — losing it stops the platform — but it holds nothing you would have to restore. There is one important consequence of taking a managed cache: **every shipped managed cache module presents the cache to OpenIAM as a single endpoint in single mode.** Redis sentinel mode is available only when you run the cache yourself. Whatever redundancy a managed cache has is the platform's internal business and is invisible to OpenIAM. **The graph store may or may not leave your scope, and this is where designs go wrong.** On AWS, a managed graph service replaces JanusGraph and its Cassandra store outright — two stateful components gone. On Google Cloud, a managed wide-column store replaces Cassandra but JanusGraph still runs as a workload you operate, so one component goes and one stays. On Azure there is no graph module at all, and both JanusGraph and Cassandra remain yours. An Azure design that assumed a managed graph has underestimated its stateful footprint by two components. **The search tier does not leave your scope on any platform.** A managed search module exists in the shipped material for one cloud, but it is not wired into the deployment and has not been since the product moved to a search client newer than that managed service supports. Every shipped topology, on every platform, runs the search tier itself. Plan for it. **The message broker and the secrets store never leave your scope.** There is no managed-broker and no managed-secrets module on any platform. RabbitMQ, HashiCorp Vault and the Consul store behind Vault are yours in all nine topologies. ## What the substitution does to the design Three consequences are worth carrying into a design review. **The VM becomes rebuildable, and that is the real prize in topology 5.** Once the database, the cache and the graph are outside the machine, a single-instance deployment holds no durable state except the secrets store and the search indices, both of which are recoverable. That makes topology 5 a materially better non-production shape than topology 1: you can destroy and recreate the VM without losing the environment. **Managed does not mean highly available by default.** A managed database can be provisioned as a single instance or with a standby, and the shipped modules expose that as a setting rather than assuming it. Topology 9's description of "an HA-enabled managed database" is a statement about how the module is configured, not about what managed databases are. If your design says "managed, therefore highly available", check the setting. **Network design becomes part of the deployment.** Managed services live on their own subnets and are reached over private endpoints, which means the deployment now has a subnet plan, private DNS, and — on at least one platform — a requirement for a separate deployment host in a peered network that can reach the private database endpoint. None of this is difficult, but all of it needs to be agreed with the network team before the build, not during it. ## Topology 7 and the on-premise question Topology 7 is the only shipped shape that explicitly names a link to on-premise connector hosts, and that is the thing to notice about it rather than its node counts. A cloud-hosted OpenIAM that has to provision into on-premise Active Directory, on-premise databases, on-premise Linux servers or an on-premise mainframe needs a network path to them. Connector processes dial out to the message broker rather than being called, which simplifies the firewall conversation considerably — but the path still has to exist, and it is normally a site-to-site link between the cloud network and the corporate network. **The shipped infrastructure modules do not build that link.** They create the cloud-side network, its subnets and, where a managed database requires it, peering between the deployment network and the cluster network. A corporate site-to-site tunnel, a dedicated interconnect or an equivalent is supplied by you and designed with your network team. Treat it as a lead-time item: it is frequently the longest-lead dependency in a cloud-hosted OpenIAM programme, and it is discovered late because it does not appear in any component diagram. [Connector placement](/solution-architecture/integration/connector-placement.md) covers the placement decision that sits on top of it. ## What we recommend **Take topology 6 as the default cloud shape.** Three nodes with a managed database, a managed cache and — where the platform offers one — a managed graph store is the best ratio of availability to operational load in the catalogue. Add the topology 7 separations only for a stated reason: a network zoning requirement, a very high sign-in volume, or an on-premise estate large enough that the connector tier deserves its own design. **Hand away every component your platform has a module for, and design explicitly around the gaps.** The gaps are not the same on the three clouds and they are not obvious. Read [Platform support matrix](/solution-architecture/deployment/platform-support-matrix.md) before you promise anyone a fully managed stateful tier. **Use topology 5 for development and demonstration in a cloud, in preference to topology 1.** The rebuildable VM is worth the managed-service cost for a long-lived non-production environment. **Do not let the managed database's engine choice be made by the module's convenience.** The database family is a long-lived decision that affects your DBA team, your backup tooling and your migration path. Choose the engine first, then check which cloud's managed service supports it. The circumstance that changes this advice is a data-residency or sovereignty constraint that rules out managed services for identity data. There, topologies 5 to 7 collapse back to the packaged Linux shapes, and the argument for a separate infrastructure cluster gets stronger because you are operating all of it anyway. ## What OpenIAM does not do here * **There is no managed message broker option.** RabbitMQ is self-managed in every topology on every platform. * **There is no managed secrets-store option.** Vault and the Consul store behind it are self-managed everywhere. * **The search tier is self-managed on every platform.** The one managed search module in the shipped material is not wired into any deployment. * **There is no Azure graph module.** On Azure, JanusGraph and its Cassandra store are both yours. * **A managed cache is presented to OpenIAM in single mode on every platform.** Sentinel mode exists only for a self-managed cache. * **The shipped modules do not provision connectivity to your corporate network.** A site-to-site link is yours to design and build. ## Related * [Platform support matrix](/solution-architecture/deployment/platform-support-matrix.md) — exactly what is managed on AWS, Azure and Google Cloud. * [Choosing a topology](/solution-architecture/deployment/choosing-a-topology.md) — where these three sit among the nine. * [Connector placement](/solution-architecture/integration/connector-placement.md) — reaching on-premise managed systems from a cloud deployment. * [Network zones and traffic flow](/solution-architecture/deployment/network-design.md) — what a managed service changes about where the boundaries fall. * [Availability and recovery](/solution-architecture/deployment/availability-and-recovery.md) — what a managed database changes about your backup scope. * *Rotate service credentials* in the Administration Guide — what the secrets store does for the administrator, since you will be running it. * The [Installation Guide](/installation/installation.md) — provisioning and connecting the platform services. *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/solution-architecture/deployment/platform-service-topologies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.