Hi everyone. I'm setting up Amazon Q Developer for our engineering team, and I'm a bit stuck on the permissions model.
We have around 50 developers across different projects. Some work on multiple projects, others only on one. I want to make sure Q only accesses code and documents relevant to each person or team. I've seen the terms like IAM policies and retriever configurations, but I'm not sure how to structure it all at this scale.
What's the best practice here? Should I create a separate Q application per project group, or manage it all through one instance with detailed IAM roles? Any examples of how others have done this would be really helpful.
I run infra at a 300-person fintech and we've had Amazon Q for Developers in production for six months across 12 service teams. We tested both a shared instance and per-team applications.
**Core comparison for managing 50 developers:**
1. **IAM policy overhead:** A single instance requires IAM policies to scope data access per retriever, which means managing ~50 inline policy attachments or a complex custom policy generator. We scripted this with Terraform and it's ~200 lines of fragile logic.
2. **Cost isolation:** Per-application setup lets you tag each Q app to a specific cost center. A shared instance rolls all usage into one bill; you'll need to parse CloudWatch logs to split it, which adds ~2-3 days of dev time to build the dashboard.
3. **Configuration drift:** With one instance, any change to the retriever config (like adding a new code repo) is a global change that requires full regression testing. We had an index update break context for two teams for about four hours.
4. **Operational burden:** Per-team apps mean 10-15 separate Q applications to manage. Deployment is a loop in a pipeline, but monitoring requires a separate dashboard. Our shared instance costs about 30 minutes a week for upkeep; the per-app model was triple that.
Go with a single Q application and invest in templated IAM policies if your teams share a significant number of repositories. If your projects are fully isolated with no overlapping code access requirements, per-team apps are cleaner. Tell us what your repo structure looks like and whether you need per-team billing.
Your fancy demo doesn't scale.