> 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-support-matrix.md). # Platform support matrix What AWS, Azure and Google Cloud will run for you and what you still operate yourself — built from the shipped infrastructure modules, including the three gaps that change a design. ## What this is, and when you need it This is the table to check before you promise anyone a managed stateful tier. It is built from the infrastructure modules that ship with OpenIAM's deployment tooling — one module per component per platform — rather than from a diagram, and the picture it gives is less uniform than most cloud designs assume. You need it at the point where a design says "we will use managed services", which is usually before anyone has checked which managed services exist. Three of the entries below routinely surprise people, and all three change how much stateful workload the customer ends up operating. ## The decision | Component | AWS | Azure | Google Cloud | Self-managed | | ----------------------------- | ------------------------------------------------------------------------------ | ----------------------------------------------------------- | ----------------------------------------------------------------------------------------- | ------------------------------- | | Relational database | Managed | Managed | Managed | Yes | | Cache | Managed | Managed | Managed | Yes | | Graph store | Managed — a graph service replaces JanusGraph and Cassandra outright | **No module.** JanusGraph and Cassandra both run in-cluster | Partly — a managed wide-column store replaces Cassandra; JanusGraph still runs in-cluster | JanusGraph over Cassandra | | Search tier | **Self-managed.** A managed module exists but is not wired into the deployment | **Self-managed** | **Self-managed** | Yes | | Message broker | **No module** | **No module** | **No module** | Yes, always | | Secrets store and its backend | **No module** | **No module** | **No module** | Yes, always | | Monitoring | **No module** | **No module** | **No module** | Optional Prometheus and Grafana | | Search dashboards | Not shipped | Not shipped | Not shipped | Not shipped | Google Cloud is fully supported and is routinely overlooked, because older topology material mentions only AWS and Azure. If the customer is on Google Cloud, the shipped modules cover the cluster, the network, the database, the cache and the graph store's storage backend. ## The three gaps that change a design ### There is no Azure graph module On Azure the entitlement graph runs self-managed: JanusGraph deployed as a workload, backed by a Cassandra cluster also deployed as a workload from a public chart. **The Cassandra behind it is in-cluster and self-managed, not a managed Cassandra service** — this is the detail most often stated loosely, and getting it wrong understates the Azure operational footprint by a whole distributed database. The authorization service does recognise a graph provider setting whose values include a managed Azure graph, but no module ships to provision one, so an Azure design should assume the self-managed path and size for it. The practical consequence: an Azure deployment operates two more stateful components than the equivalent AWS deployment, and one of them is Cassandra. ### Managed search is not available on any platform A managed search module exists in the shipped material for AWS. It is not connected to the deployment, and has not been since the product moved to a search client newer than the managed service supports — the module is left in place but bypassed in favour of the self-managed chart. The consequence is simple and should be stated plainly in any design: **on all three clouds and on every packaged Linux topology, you operate the search tier yourself.** That is the component most sensitive to disk and heap tuning, it holds the audit trail, and it is the one whose rebuild path does not cover everything — see [Availability and recovery](/solution-architecture/deployment/availability-and-recovery.md). Budget for it. ### The broker and the secrets store are always yours There is no managed-broker module and no managed-secrets module on any platform. RabbitMQ, HashiCorp Vault and the Consul store behind Vault run wherever OpenIAM runs, in all nine topologies. Since the broker carries every call between services, it is a hard dependency you operate regardless of how managed the rest of the design is. ## What each managed component actually gives you ### The relational database The engine families differ by platform, and the differences are real constraints rather than preferences. | Platform | Engines the shipped module provisions | Notes | | ------------ | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | AWS | MariaDB, PostgreSQL, Oracle | **SQL Server is not supported on the AWS managed database.** Of the Oracle editions, only Standard Edition 2 is tested; Enterprise Edition is untested and licence-constrained; the older Standard editions cap at an Oracle version the migration tooling cannot use | | Azure | MySQL, PostgreSQL, SQL Server | No Oracle option | | Google Cloud | MySQL, PostgreSQL | No SQL Server and no Oracle option. **For PostgreSQL, none of the standard machine tiers provides enough concurrent connections** — a custom tier is required | | Self-managed | MariaDB, PostgreSQL, SQL Server, Oracle | OpenIAM ships migration trees for four database families: MySQL and MariaDB, PostgreSQL, SQL Server and Oracle | Two of those rows carry a decision. If the estate's database standard is SQL Server, AWS is out for the managed database and the choice is Azure, self-managed, or a different engine. If the estate's standard is Oracle, AWS Standard Edition 2 is the only tested managed path. The Google Cloud connection note generalises. OpenIAM's deployment tooling provisions database connections as a multiple of the replica count of the ESB, workflow and authorization services — thirty-five per replica of each — so a three-node deployment asks for several hundred connections before anything unusual happens. Check the connection cap of any managed database tier against that arithmetic before choosing it; it is the most common cause of a managed database being provisioned too small, and it is covered further in [Sizing](/solution-architecture/deployment/sizing.md). ### The cache All three platforms provision a managed cache, and all three present it to OpenIAM the same way: **a single endpoint in single mode.** Redis sentinel mode is available only when you run the cache yourself. Two properties of the shipped modules are worth knowing. The AWS module provisions a single cache node rather than a replicated group, so redundancy there is whatever you add. The AWS and Google Cloud modules provision the cache relying on network isolation rather than on an authentication credential, so **adding authentication to the cache is a hardening step the design should include** on those two platforms. Settle it at design time rather than at the security review, particularly where your standard requires authenticated access to every data service. ### The graph store | Platform | What the module provisions | What you still run | | ------------ | --------------------------------------------------------------- | ------------------------------------------------ | | AWS | A managed graph cluster with a configurable number of instances | Nothing. Both JanusGraph and Cassandra disappear | | Google Cloud | A managed wide-column store as the graph's storage backend | JanusGraph itself, as an in-cluster workload | | Azure | Nothing | JanusGraph and Cassandra, both in-cluster | | Self-managed | Nothing | JanusGraph and Cassandra, both in-cluster | The AWS row is worth stating deliberately, because this page is otherwise sceptical about modules that exist without being connected. The AWS graph module is not in that category: it provisions the cluster and it is wired into the AWS deployment, and the platform is configured to use it. That is the difference between it and the managed search module described above, which exists and is not connected. Wherever JanusGraph runs self-managed it also needs the search tier, which it uses as its index backend. That coupling is set out in Part 1, *The OpenIAM architecture*, and it means the Azure and Google Cloud designs have a dependency from the graph onto a component you are already operating. ### Monitoring The shipped material includes an optional Prometheus, Grafana and node-exporter deployment with dashboards for the nodes, the services, the broker and the search tier, plus a database exporter for MariaDB deployments. It is self-managed and off unless enabled, and there is no managed-monitoring module on any platform. Most customers will point OpenIAM at whatever observability platform they already run instead; the shipped stack is a starting point, not a requirement. ## What the cluster modules provision For the container topologies, the platform modules also build the cluster and the network around it. Three details affect a design. **One node pool, sized to the replica count, with no autoscaling.** The same on all three platforms. **A stated minimum worker size.** AWS and Google Cloud both document a floor of roughly four virtual CPUs and sixteen gigabytes per worker. That is a floor for the deployment to start, not a production recommendation. **A private cluster on Azure, with a peered deployment network.** The Azure module provisions a private cluster and expects a separate deployment host in a hub network peered to it, which also needs to reach the managed database's private endpoint. Agree that with the network team before the build. ## What we recommend **Take every component your platform has a working module for, and design explicitly around the rest.** On AWS that is the database, the cache and the graph — leaving the broker, the secrets store and the search tier. On Google Cloud it is the database, the cache and the graph's storage backend. On Azure it is the database and the cache only. **Treat Azure as the design that needs the most explicit planning.** Self-managed JanusGraph, a self-managed Cassandra cluster and a self-managed search tier is three distributed stateful systems in the cluster. That is a supported configuration and it works; it is also a materially larger operational commitment than the same design on AWS, and the person who should hear that is the infrastructure owner, before the architecture board rather than after. **Choose the database engine before choosing the cloud, if the engine is fixed.** The engine subsets do not match across platforms, and a SQL Server or Oracle standard eliminates options. **Treat monitoring as an optional starting point rather than a delivered capability**, and plan to integrate with the tooling the estate already runs. The circumstance that changes this advice is a multi-cloud estate with a preference not yet fixed. In that case this table is an argument for AWS on operational-load grounds alone — it is the only platform where the graph can be handed away entirely. ## What OpenIAM does not do here * **There is no Azure graph module.** JanusGraph and Cassandra both run self-managed on Azure, and the Cassandra is in-cluster, not a managed service. * **There is no working managed search option on any platform.** The one module that exists is bypassed. * **There is no managed message broker, managed secrets store or managed monitoring module** on any platform. * **No search dashboard component ships.** There is no OpenSearch Dashboards or Kibana deployment in the shipped charts or the packaged Linux distribution; the console's own screens are the supported way to read what is indexed, and audit search runs from the Webconsole. * **The AWS managed database does not support SQL Server**, and only one Oracle edition is tested. * **Google Cloud's standard PostgreSQL tiers cannot carry OpenIAM's connection count.** A custom tier is required. * **Managed caches are presented in single mode on every platform.** Sentinel mode is self-managed only. ## Related * [Topologies using cloud platform services](/solution-architecture/deployment/platform-service-topologies.md) — the three shapes that use this table. * [Kubernetes topologies](/solution-architecture/deployment/kubernetes-topologies.md) — the cluster side of the same modules. * [Sizing](/solution-architecture/deployment/sizing.md) — the connection arithmetic that constrains the managed database tier. * [Availability and recovery](/solution-architecture/deployment/availability-and-recovery.md) — what a managed database changes about backup scope. * Part 1, *The OpenIAM architecture* — what each of these components holds and what its loss costs you. * *Configure platform services* in the Administration Guide — the administrator's view of the components you end up operating. *Applies to OpenIAM 2026.8.1. Last reviewed 13 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-support-matrix.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.