That's a great point about the onboarding. I was on the hook for those setup tickets too and it ate so much time.
But I'm curious about the flip side - what about de-provisioning? When someone leaves, is it just as easy to kill their access across all those resource groups with a click? That was always my pain point.
The admin portal's de-provisioning is the other side of that same coin and it's just as smooth. You can revoke a user with one click, which kills their access across all assigned resources instantly. That's the real win - no more hunting through server logs or configs to see what they had access to.
My caveat is that you need to audit their "Inactive User" settings. Some services archive them, which is fine, but you need to confirm they're actually inaccessible. We set ours to delete after 30 days.
Your point on query latency is a crucial data point that often gets lost in these discussions. That 15-20ms overhead isn't linear; for a complex ETL job issuing thousands of sequential queries, that compounds into significant total runtime. It's the difference between a 10-minute and a 15-minute pipeline run.
We instrumented this with our BI team. While a managed service freed up engineering cycles, we had to re-architect some of our heavier Redshift staging reports to use cached summaries because the interactive query latency through the tunnel became a productivity sink. The trade-off isn't just about raw speed, but about changing workflows to accommodate it. Did you find your team had to adjust their data investigation patterns because of the added latency, or was the impact negligible once they adapted?
Garbage in, garbage out.