What we run today — not a roadmap

Platform Architecture

Managed Keycloak on AWS — Fargate cells, a serverless control plane, an Aurora PostgreSQL source of truth, and availability that scales with your architecture tier.

Read the full docs → Talk to an engineer

The Default Deployment

A stateful data plane on AWS Fargate fronted by CloudFront and an ALB, with everything around Keycloak running serverless in the control plane.

Default deployment — single region, multi-AZData planeControl planeDatabaseUsers / SPAs / APIsCloudFront (edge)TLS · WAF / Shield · caches /resources/*DATA PLANE· AWS us-east-1 · Fargate (Keycloak / Quarkus, autoscaled)Regional ALB (L7)Availability Zone 1Availability Zone 2KC task 1KC task 2KC task 3KC task n◄── clustered via JDBC_PING · embedded Infinispan (in-region) ──►Aurora PostgreSQL — Multi-AZprimary + synchronous replica · source of truthCONTROL PLANE· serverless (Lambda)Provisioning APIBilling / metering (Stripe)AI-config service (Bedrock)Analytics — Firehose → S3 → AthenaNotifications (SES / SNS)STS token-brokerTenant registry + placementAdmin REST APIScales two ways · availability by tierMany tenants → add cells(cell = Fargate + DB + cache, N realms)One huge realm → dedicated Fargatesized by login rate (~1 vCPU / 15 logins/s)99.9% single-region · 99.95% multi-region active-passive · 99.99% active-active multi-cloud (backed after production maturity)
⤢ Click to enlarge

Data plane — Fargate (JVM)

Long-running, clustered Keycloak (Quarkus) across AZs via JDBC_PING, autoscaled on CPU. Not Lambda, not native — both break the SPIs and clustering the product depends on.

Control plane — serverless

Provisioning, billing, AI-config, analytics, notifications, and the STS token-broker run on Lambda and drive Keycloak through its Admin REST API.

Aurora PostgreSQL

Multi-AZ primary + synchronous replica is the source of truth. Sessions persist to the DB (persistent-user-sessions); Infinispan is an in-region near-cache.

Multi-Tenancy That Scales in Cells

A cell is a self-contained Keycloak unit (Fargate + its DB + its cache) bounded to a set number of realms. You scale by adding cells; a placement engine routes each tenant to one.

Cell-based multi-tenancyCloudFront + edge routerresolve tenant → cell (host / path / custom domain)Tenant registryPlacement enginePOOLED CELL Aup to N realmsKeycloak clusterFargate · multi-AZAuroracell databaseInfinispanin-region cachePOOLED CELL Bup to N realmsKeycloak clusterFargate · multi-AZAuroracell databaseInfinispanin-region cacheDEDICATED SILO · ENTERPRISETenant's own Keycloak + own DBstrongest isolation · own keys / upgradesoptional multi-cloud (Yugabyte) cellThree isolation tiers — used together, not either/orOrganizationsOrg inside a shared realmHighest densityMany small B2B tenantsdensity ▲ · isolation ▽Realm-per-tenant (pooled)A realm on a shared clusterStrong isolation, own keysThe standard tierbalancedInstance-per-tenant (silo)Dedicated Keycloak + DBStrongest isolationEnterprise / regulateddensity ▽ · isolation ▲
⤢ Click to enlarge

Multi-Cloud, Done Honestly

Two premium options, depending on whether you need disaster recovery across clouds or true active-active. Standard deployments stay single-cloud, multi-region.

Multi-cloud — premium optionsOption A — cross-cloud warm standby (active-passive)Route 53 — health-check failoverlatency routing · 60s TTL · promote standby on region lossAWS · US-EAST-1 (ACTIVE)Keycloak (Fargate) — serving trafficAurora PostgreSQL — PRIMARYlogical-replication PUBLICATIONAZURE · EAST US (WARM STANDBY)Keycloak (standby → promoted on failover)Azure DB for PostgreSQL — SUBSCRIBERwarm standbylogical replicationover VPN / interconnect (or AWS DMS)Native physical log shipping is impossible — Aurora's log-structured storage doesn't expose WAL.Active-passive: RTO = standby promotion + replication catch-up · RPO = replication lagOption B — YugabyteDB geo-distributed (active-active)Keycloak — AWSKeycloak — AzureKeycloak — GCPone YugabyteDB cluster (Raft) spans clouds · no failover gap → the tier that backs 99.99%tradeoffs: gated DB migrations · cross-cloud egress cost · heavier ops · cell tagged capabilities:["multi-cloud"]
⤢ Click to enlarge

Option A — Cross-cloud warm standby

Aurora (AWS) replicates to Azure Database for PostgreSQL via logical replication — physical log shipping isn't possible on Aurora. Active-passive with DNS failover; great for DR and data sovereignty.

Option B — YugabyteDB active-active

One distributed-SQL cluster spans clouds with no failover gap — the tier that credibly backs 99.99%. Trades that for gated DB migrations, cross-cloud egress cost, and heavier ops.

Availability, Tiered by Architecture

Tier Architecture Target SLA
Single region Aurora Multi-AZ 99.9%
Multi-region Aurora Global active-passive + DNS failover 99.95%
Active-active multi-cloud YugabyteDB (no failover gap) 99.99%

SLA tiers are backed after production maturity.

Standard vs. Premium Opt-In

Standard (included) Premium (opt-in)
Single AWS region, Multi-AZMulti-region active-passive DR (Aurora Global)
Pooled cells, realm-per-tenantDedicated silo (own Keycloak + DB)
Aurora PostgreSQLCross-cloud warm standby (AWS→Azure)
99.9% target SLAYugabyteDB active-active (99.99% target)

Want the full detail?

Migration, rolling upgrades & patching, HA & resiliency, realm setup, analytics, and security — all in the documentation.

Browse the docs → Start free