You've hit on a major hidden cost - the audit trail reconstruction. I once spent three days on an incident review pulling logs from six different microservices just to map one user's path, because our consolidated gateway's logs didn't capture the downstream app-specific authorization checks. The time spent building that timeline was more expensive than a year of the per-app seat fees we were trying to avoid.
The central problem is you're trading a defined, if expensive, security model for a bespoke one where the failure modes are unknown until you're in a breach scenario. That token scope mismatch is a classic example of a latent flaw that only surfaces during a compliance deep dive.
Garbage in, garbage out.
Wait, so it counts the same person separately for each app? That's wild. I was about to set this up for our team's admin panel and monitoring tools, thinking the cost would just be our 8 devs.
So if I have an app for Grafana and another for our staging env, and one dev uses both, that's two $7 seats? Even if they only used one once?
Containers are magic, but I want to know how the magic works.
Yes, that is precisely how the multiplier functions. Your core team of ten is not ten billed users, it's ten users *times* the number of discrete Access applications they each authenticate to within the billing cycle. The billing granularity is at the user-application pair level, not the user identity level.
Your contractor example highlights the secondary issue, which is the lack of a prorated or usage-based cost for infrequent access. A contractor who authenticates once on the first day of the month to a single app occupies a full seat for that entire month, incurring the same $7 as your core member who uses the app daily. This model effectively penalizes application sprawl and sporadic access patterns, which are common in development and testing environments.
The dashboard's billing summary will only show you the final aggregated "active user" count, which is that multiplied figure. To forecast, you must manually analyze audit logs per application, as others noted. This discrepancy between the apparent simplicity of the per-user price and the actual per-user-per-app billing is the core of the trap.
Oh, totally feel that initial excitement turning into sticker shock. You nailed it with the multiplier effect.
The beta tester example is a huge one. Even if they just log in once to validate something, that's a full $7 seat for the month. We saw that with preview environments for designers - they'd hop in for ten minutes, then we'd get the bill.
For us, the bigger surprise was service accounts and CI/CD bots. They're just checking status but they count as "users" too. 😬 So that $70 for 10 people can quietly double before you even add your contractors.