Let's cut through the marketing fluff right away. You have a thousand users, a foot in both AWS and Azure, and you're probably being bombarded with architectures involving a dozen microservices, sidecars, and a Kubernetes cluster just to manage logins. The sheer overkill I see proposed for "simple" SSO never ceases to amaze me.
You're looking at Ping Identity. Fine. It's a contender. But before you get lost in a forest of identity providers, federation protocols, and containerized deployment models, let's ground this in the actual problem. You need reliable, secure authentication for a thousand people across two clouds. This is not a scale problem that demands a distributed system of epic complexity. The real questions are about operational burden, unexpected costs, and the migration path from whatever rickety system you're currently using.
I've seen teams deploy PingFederate or PingOne with a level of infrastructure that would make a bank's trading platform blush, all for a workload that could run on a pair of adequately sized VMs. The complexity, and thus the cost, often hides in:
* **The deployment model:** Are you going for the SaaS PingOne, or self-hosted PingFederate on your own infrastructure? The former trades capital expense for operational dependency and potential long-term subscription lock-in. The latter requires you to actually manage it.
* **Cloud integration tangles:** Yes, it supports SAML, OIDC, SCIM. Theoretically, plug and play. In practice, you'll be debugging trust configurations and attribute mappings for weeks. The Azure AD and AWS SSO integrations are mature, but they are not magic. You will write configuration.
* **The hidden capacity planning trap:** With a thousand users, your peak load is likely a few hundred concurrent logins at morning startup. A monolithic PingFederate instance, properly tuned, could handle this on a single `c5.xlarge` without breaking a sweat. Yet, I've seen proposals for auto-scaling groups of containers because "cloud-native." This is where costs spiral for no tangible benefit.
Consider this simplistic Terraform snippet for a *potential* self-hosted deployment baseline on AWS. It's not a full config, but it illustrates the point that the core infrastructure need not be a spaceship.
```hcl
resource "aws_instance" "pingfederate_primary" {
ami = data.aws_ami.rhel_9.id
instance_type = "c5.xlarge" # Overprovisioned for 1k users, intentionally.
subnet_id = aws_subnet.private.id
root_block_device {
volume_size = 100 # For logs, backups. Don't skimp.
}
user_data = templatefile("${path.module}/bootstrap.sh", {
pingfederate_installer_url = var.pingfederate_rpm_url
})
}
```
The real review isn't about if Ping "works." It does. It's about whether its architecture aligns with your tolerance for ceremony. PingOne (SaaS) simplifies operations but at a recurring cost and less control. PingFederate (self-managed) gives control but demands your team understand Java application servers, load balancer health checks, and database failover.
So, when you read reviews, ignore the ones talking about feature checklists. Look for the war stories. Ask about:
* The actual monthly run-rate for 1k users with your expected authentication volume.
* The time it took to go from installation to production with Azure AD and AWS SSO connected.
* Whether anyone on the team had to become a full-time Ping administrator, or if it truly runs in the background.
The best SSO is the one you hardly have to think about after it's set up. My contrarian take: for a thousand users, a well-tuned monolith (whether Ping's or a simpler alternative) will almost always be more cost-effective and operationally sane than a glittery "cloud-native" distributed identity mesh.
monoliths are not evil