👋 Hey there, tech enthusiasts!
I'm Sarvar, a Cloud Architect with a passion for transforming complex technological challenges into elegant solutions. With extensive experience spanning Cloud Operations (AWS & Azure), Data Operations, Analytics, DevOps, and Generative AI, I've had the privilege of architecting solutions for global enterprises that drive real business impact. Through this article series, I'm excited to share practical insights, best practices, and hands-on experiences from my journey in the tech world. Whether you're a seasoned professional or just starting out, I aim to break down complex concepts into digestible pieces that you can apply in your projects.
Let's dive in and explore the fascinating world of cloud technology together! 🚀
The Transition: From Doing to Designing
When I became a Cloud Architect, I thought my bottleneck days were over. I assumed my role would shift from reviewing pull requests to designing scalable systems.
I was wrong.
Currently, I lead two different teams within the same project, each responsible for managing its own infrastructure requirements:
- Team A: Migrating a legacy monolithic application to microservices on Amazon Elastic Kubernetes Service (EKS)
- Team B: Building a secure and scalable CI/CD platform
Both teams required architectural guidance, infrastructure reviews, security approvals, and cost validation. And naturally, most of those decisions came to me. Within three months, I realized I had become a bottleneck again. But this time, it was worse.
Previously, my delays affected a single team. Now, they were affecting two different teams working in parallel. Every architectural review, infrastructure change, and security approval had to pass through me.
Something had to change. And this time, I had the authority to change it.
The Architect's Advantage: I Could Design the Solution
As a Senior DevOps Engineer, I could only optimize my own workflow. As a Cloud Architect, I could design a system for everyone.
I started asking questions:
- What if I had an AI assistant that understood our entire codebase?
- What if I could ask it to review PRs, check security, and validate costs in seconds?
- What if I could delegate the routine checklist items to AI while I focused on architecture?
But I didn't want just any AI solution. I needed something that:
- Integrated with our existing tools (GitHub, AWS, Terraform)
- Understood infrastructure code (not just generic code review)
- Could access our repositories on-demand without complex setup
- Scaled across multiple projects without requiring me to be in every review
That's when I discovered the combination that changed everything: Amazon Q Developer CLI + GitHub MCP Server.
Why Amazon Q Developer CLI + GitHub MCP Server?
I evaluated several AI code review tools. Most were designed for application code, not infrastructure. And none of them gave me the speed and context I needed.
Then I found Amazon Q Developer CLI with the GitHub MCP (Model Context Protocol) server. Here's why it clicked:
Amazon Q Developer CLI
- Built by AWS, so it understands AWS infrastructure patterns
- Can analyze Terraform, CloudFormation, CDK, and Kubernetes manifests
- Knows AWS best practices, security guidelines, and cost optimization strategies
- Works directly from my terminal - no context switching
GitHub MCP Server
- Gives Amazon Q direct access to GitHub repositories
- Can read PRs, files, commits, and issues on-demand
- Understands our branching strategy and codebase structure
- No complex authentication setup - just works
The Combination
When you connect Amazon Q CLI to GitHub via MCP, you get an AI assistant that:
- Instantly accesses any PR or code across all your repositories
- Reviews changes against AWS best practices when you ask
- Provides detailed, actionable feedback in seconds
- Helps you identify security issues and cost implications
- Answers questions about infrastructure code with full context
It's like having a senior DevOps engineer available 24/7. Except you control when and how to use it, and it scales across unlimited repositories.
The Implementation: How I Built It
I didn't roll this out to both teams at once. That would have been chaos. Instead, I ran a pilot with Team B (the CI/CD platform team) for two weeks.
Week 1: Setup and Workflow Design
Step 1: Set up Amazon Q Developer CLI
- Installed Amazon Q CLI on my machine and team leads' machines
- Configured AWS credentials and permissions
- Created a shared knowledge base with our infrastructure standards
Step 2: Connect GitHub MCP Server
- Set up GitHub MCP server locally
- Connected it to our GitHub organization
- Configured repository access tokens
Step 3: Define Review Guidelines
I created a checklist document that I would use with Q for reviews:
security_checks:
- encryption_at_rest: required
- encryption_in_transit: required
- iam_least_privilege: enforce
- public_access: flag_for_review
cost_checks:
- unused_resources: flag
- oversized_instances: warn
- missing_lifecycle_policies: warn
compliance_checks:
- tagging_standards: enforce
- backup_policies: required
- logging_enabled: required
Step 4: Test the Workflow
I started with small, low-risk PRs. Instead of manually reviewing everything, I would:
- Open Amazon Q CLI
- Ask it to review the PR
- Get instant feedback on security, cost, and best practices
- Add my architectural insights
- Approve or request changes
Week 2: Real-World Testing
By week 2, I was confident enough to use Q for all PR reviews.
Monday: Team B submitted a Terraform PR to create a new EKS cluster. I asked Q to review it:
Me: "Review PR #234 in team-b-infra repo for security and cost issues"
Q: "I've analyzed the PR. Here are the findings:
- Missing encryption for EBS volumes (line 45)
- No pod security policies defined (line 78)
- Cluster logging not enabled (line 92)
- Estimated cost: $2,400/month - this is high for a dev environment"
I reviewed Q's analysis. All valid. I added one more comment about using Fargate and posted the review.
Time spent: 15 minutes instead of 2 hours.
Wednesday: Team B submitted a GitHub Actions workflow change. I asked Q:
Me: "Check PR #241 for security issues in the workflow file"
Q: "Security concerns found:
- AWS credentials hardcoded in workflow (line 23) - HIGH RISK
- No timeout defined - could run indefinitely
- Missing error handling in deployment step"
I reviewed it. Added my suggestion about OIDC authentication. Posted the review.
Time spent: 10 minutes instead of 1 hour.
Friday: Team A submitted multiple small PRs. I asked Q to review all of them in one session:
Me: "Review all open PRs in team-a-eks repo"
Q: "Reviewed 5 PRs:
- PR #156: S3 bucket config - looks good, encryption enabled
- PR #157: IAM policy update - follows least privilege
- PR #158: Lambda config - all checks passed
- PR #159: Security group update - flagged: allows 0.0.0.0/0 on port 22
- PR #160: RDS parameter group - looks good"
Time spent: 20 minutes instead of 3 hours.
The Rollout: Scaling to Team A
After two weeks with Team B, I was convinced. The approach was working. It was time to enable Team A's lead engineer with the same setup.
Team Rollout
- Team B (CI/CD platform): Lead engineer already using Q CLI during pilot phase
- Team A (EKS migration): Lead engineer onboarded in week 3 with Kubernetes-focused review guidelines
Each team lead received training on how to use Q CLI with GitHub MCP for infrastructure reviews. They could now:
- Review PRs in seconds instead of hours
- Get instant security and cost analysis
- Ask Q questions about any part of the codebase
- Share Q's insights with their team members
The underlying tool remained the same: Amazon Q Developer CLI integrated with GitHub MCP Server using the Model Context Protocol.
This allowed both teams to maintain their own review standards while benefiting from AI-assisted infrastructure reviews.
The Results: What Changed
Before (6 months ago)
- Average PR review time: 2-4 days
- My time spent on reviews: 6-7 hours/day
- Deployments per week (both teams): 12-15
- Security issues caught post-deployment: 3-4/month
- My time for architecture work: 1-2 hours/day
After (Today)
- Average PR review time: 2-4 hours
- My time spent on reviews: 1-2 hours/day
- Deployments per week (both teams): 35-40
- Security issues caught post-deployment: 0-1/month
- My time for architecture work: 5-6 hours/day
The Numbers That Matter
- 83% reduction in review time
- 3x increase in deployment velocity
- 75% reduction in post-deployment security issues
- 5x increase in my time for strategic work
But the numbers don't tell the whole story.
What I Learned: The Real Benefits
1. Consistency Across Teams
Before, each team got different quality of reviews depending on how busy I was. Now, with Q CLI, I can provide thorough reviews consistently, every time.
2. Knowledge Sharing
Q's analysis is educational. I share the insights with teams. Junior engineers learn from them. I've seen team members start catching issues before asking Q.
3. Faster Feedback Loops
I can review PRs in minutes using Q, not days. Developers get feedback faster. They can iterate quickly. They stay in flow.
4. Better Architecture Decisions
I'm not exhausted from manual reviews anymore. I have energy for architecture discussions. For mentoring. For solving hard problems.
5. Scalability
When we expand to additional teams, I can train their leads on Q CLI. The tool scales. I don't have to be in every review.
The Technical Details: How It Actually Works
For those who want to implement this, here's the technical architecture:
Architecture Overview
Developer
↓
Opens Amazon Q CLI
↓
Asks Q to review PR
↓
Q connects to GitHub MCP Server
↓
MCP fetches PR data from GitHub
↓
Q analyzes:
├─ Security Checks
├─ Cost Analysis
├─ Best Practices
└─ Custom Guidelines
↓
Q provides review feedback
↓
Developer reviews Q's analysis
↓
Developer posts comments to GitHub PR
Key Components
1. Amazon Q Developer CLI
- Runs locally on your machine
- Connects to AWS for infrastructure knowledge
- Analyzes infrastructure code (Terraform, CloudFormation, K8s manifests)
- Applies security, cost, and compliance best practices
- Provides detailed feedback with specific line numbers and suggestions
2. GitHub MCP Server
- Runs locally or as a service
- Authenticates with GitHub using personal access token or GitHub App
- Provides Q with read access to repositories and PRs
- Fetches PR diffs, files, and commit history on-demand
3. Review Guidelines Document
- YAML or markdown file defining what to check
- Team-specific guidelines (e.g., Team A has stricter Kubernetes security requirements)
- Organization-wide standards (e.g., all S3 buckets must be encrypted)
- Used as context when asking Q to review
4. Human-in-the-Loop
The workflow always involves human review:
- You ask Q to analyze a PR
- Q provides detailed feedback
- You review Q's analysis and add your insights
- You post the final review to GitHub
- Critical decisions remain with you
The Challenges: What Didn't Work
Not everything was smooth. Here are the problems I encountered and how I solved them:
Challenge 1: Learning Curve
Problem: Team leads needed time to learn how to ask Q the right questions.
Example: Initially, they would ask vague questions like "Is this PR good?" instead of "Check this PR for security issues in IAM policies."
Solution: Created a guide with example prompts and best practices for getting useful feedback from Q.
Challenge 2: Context Limitations
Problem: Q didn't always understand business-specific requirements without additional context.
Example: Team B's serverless pipeline intentionally used public S3 buckets for static website hosting. Q flagged them as security risks.
Solution: Added a .q-context.md file to each repo explaining project-specific requirements and exceptions.
Challenge 3: Over-Reliance Risk
Problem: Some engineers wanted to blindly follow Q's suggestions without critical thinking.
Solution: Made it clear that Q is a tool to augment reviews, not replace judgment. All reviews still require human approval and architectural oversight.
The Unexpected Benefits
Some benefits I didn't anticipate:
1. Junior Engineers Level Up Faster
Q's analysis is like having a senior engineer explain issues. Junior engineers learn faster by seeing the reasoning behind recommendations.
2. Documentation Improved
When Q flags missing documentation, teams started writing better READMEs and runbooks to provide context.
3. Cost Savings
Q helped identify cost issues we didn't know existed. Saved $18,000/month across both teams by catching oversized resources and unused services.
4. Security Posture Improved
Zero security incidents related to infrastructure misconfigurations in the last 6 months. Q catches issues before they reach production.
5. I Sleep Better
Knowing that I can quickly review any PR with Q's help, even when I'm busy with architecture work, is incredibly reassuring.
The Future: Where I'm Taking This Next
This is just the beginning. Here's what I'm working on:
Phase 2: Proactive Analysis
Using Q to regularly audit our infrastructure:
- "Analyze all RDS instances and suggest cost optimizations"
- "Review all S3 buckets for security best practices"
- "Check IAM policies across all repos for least privilege violations"
Phase 3: Team Enablement
Training more team members to use Q CLI:
- Senior engineers can do their own reviews with Q's help
- Reduces dependency on me for routine reviews
- Spreads the knowledge across teams
Phase 4: Knowledge Base Expansion
Building a comprehensive context library:
- Team-specific guidelines and exceptions
- Architecture decision records (ADRs)
- Common patterns and anti-patterns
- Q can reference these when providing feedback
How You Can Implement This
If you're a Cloud Architect, DevOps Lead, or Platform Engineer dealing with review bottlenecks, here's how to get started:
Step 1: Assess Your Bottlenecks
- How many infrastructure PRs per week?
- How long do reviews take?
- What percentage of reviews are routine vs. complex?
Step 2: Start Small
- Pick one team or project
- Run a 2-week pilot with yourself or a team lead
- Measure time savings
Step 3: Set Up the Tools
- Install Amazon Q Developer CLI
- Set up GitHub MCP server locally
- Configure GitHub authentication
Step 4: Create Review Guidelines
- Document your security requirements
- Define cost thresholds
- List compliance rules
- Note team-specific exceptions
Step 5: Learn the Workflow
- Practice asking Q to review PRs
- Experiment with different prompts
- Learn what questions get the best results
- Share findings with your team
Step 6: Scale Gradually
- Train team leads on using Q CLI
- Share best practices and example prompts
- Create context files for each repository
- Monitor and gather feedback
What I'd Tell My Past Self
If I could go back to that moment when I was drowning in reviews, I'd tell myself:
You're not supposed to review everything manually. You're supposed to use tools that amplify your expertise.
As a Senior DevOps Engineer, you optimize workflows. As a Cloud Architect, you architect solutions. The bottleneck isn't you. The bottleneck is trying to do everything manually when AI can help you scale your expertise.
Use Q to handle the checklist items. You focus on what only you can do - the architectural decisions, the strategic thinking, the mentoring.
You're not being lazy. You're being efficient.
The Real Transformation
This isn't a story about AI replacing Cloud Architects or DevOps Engineers. It's a story about AI enabling us to do what we're actually good at.
I'm not reviewing less because I'm lazy. I'm reviewing faster because I have an AI assistant that helps me scale my expertise. I'm not doing more architecture because I have more time. I'm doing more architecture because I'm not burned out from manual reviews. I'm not leading better because I'm less busy. I'm leading better because I'm focused on strategy, not checklists.
The AI didn't take my job. It amplified my capabilities.
The job where I design resilient systems. Architect multi-region solutions. Enable both teams to move fast and safe.
Not the job where I'm manually checking every line of Terraform for missing tags.
The Question I Ask Now
When I talk to other Cloud Architects or DevOps Leaders who are drowning in reviews, I ask them:
"Are you reviewing infrastructure manually? Or are you using AI to amplify your expertise?"
Because there's a difference. Reviewing every PR yourself might feel responsible. But if it's making you a bottleneck, you're not leading efficiently. You're blocking progress.
Your teams don't need you to manually check every line of code. Your teams need you to provide fast, thorough feedback so they can move forward. Sometimes, the best solution is using AI to help you scale your expertise across multiple teams.
And sometimes, the solution is as simple as asking Amazon Q to help you review.
Resources
Want to implement this? Here are the resources I used:
- Amazon Q Developer CLI: aws.amazon.com/q/developer
- GitHub MCP Server: github.com/modelcontextprotocol/servers
- Model Context Protocol: modelcontextprotocol.io
- My Setup Guide: [Coming soon - I'm documenting the complete setup]
- Sample Review Guidelines: [Coming soon - sharing my checklist templates]
I went from being a bottleneck to using AI to amplify my expertise. You can too.
If you're a Cloud Architect or DevOps Leader struggling with review bottlenecks, it's time to leverage AI assistance.
Your teams are waiting. And the tools are ready.
Let's use AI to scale our expertise, not become bottlenecks ourselves.
📌 Wrapping Up
Thank you for reading! I hope this article gave you practical insights and a clearer perspective on the topic.
Was this helpful?
- ❤️ Like if it added value
- 🦄 Unicorn if you’re applying it today
- 💾 Save for your next optimization session
- 🔄 Share with your team
Follow me for more on:
- AWS architecture patterns
- FinOps automation
- Multi-account strategies
- AI-driven DevOps
💡 What’s Next
More deep dives coming soon on cloud operations, GenAI, Agentic-AI, DevOps, and data workflows follow for weekly insights.
🌐 Portfolio & Work
You can explore my full body of work, certifications, architecture projects, and technical articles here:
🛠️ Services I Offer
If you're looking for hands-on guidance or collaboration, I provide:
- Cloud Architecture Consulting (AWS / Azure)
- DevSecOps & Automation Design
- FinOps Optimization Reviews
- Technical Writing (Cloud, DevOps, GenAI)
- Product & Architecture Reviews
- Mentorship & 1:1 Technical Guidance
🤝 Let’s Connect
I’d love to hear your thoughts drop a comment or connect with me on LinkedIn.
For collaborations, consulting, or technical discussions, feel free to reach out directly at simplynadaf@gmail.com
Happy Learning 🚀
Top comments (0)