ProjectTech4DevAI / ProjectTech4DevAI/kaapi-backend
Account Management: Migrate non-prod workloads
@Ayush8923 is already working on this.
Since Aug 28, 2026.
- Dominant language
- Python
- Stars
- 18
- Forks
- 10
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 14
Description
Is your feature request related to a problem?
All Kaapi workloads currently reside in a single shared AWS account, making it difficult to contain issues and monitor costs effectively. We need to separate non-prod workloads into a dedicated account to enhance security and billing clarity.
Describe the solution you'd like
- Migrate Kaapi non-prod workloads to a dedicated AWS account.
- Follow an incremental approach: start with staging workloads.
- Establish access governance via Google Workspace groups and automated offboarding.
- Handle migration by creating volume snapshots, AMIs, and restoring them in the new account.
- Create a sprint task checklist for tracking migrations and validate the new setup.
Original issue
Context
Today all Kaapi workloads (prod + non-prod) live in a single shared AWS account. Way forward: separation of non-prod into a dedicated per-product account — Kaapi gets its own non-prod account, while prod stays in the shared account for now. Rationale: blast-radius containment (a breached non-prod account can't touch prod) and cleaner billing/cost monitoring than tag-based separation.
The migration is deliberately incremental and sprint-by-sprint: staging workloads move first, prod does not move yet. Scheduled for the week of the Sept 20 sprint when the team is co-located; no hard deadline, end-of-sprint is acceptable.
Access model
- Access governed via Google Workspace groups (prefix
AWS access), synced into AWS by a Lambda polling Google Groups every ~15 min. Offboarding becomes automatic (lose Google identity → lose AWS). - Prod access should be intentional membership in a dedicated group, not inherited — clean, auditable revocation. The whole dev team can be in the prod group, but membership must be deliberate.
- New sign-in path: project tech4dev → PowerUserAccess → new Kaapi non-prod account number.
Migration mechanics
- No native EC2 "move": create volume snapshots + AMIs, share cross-account, restore in new account. DB can move via dump/restore.
- Recreate VPC, ALB, EC2 from snapshots/AMIs; restore DB.
Owners
- Ayush (hands-on) + Kartikeya (alongside) own the actual migration.
Next steps / acceptance criteria
- Create sprint task checklist tracking what needs migrating (staging first).
- Work out cross-account AMI/snapshot sharing mechanics (AI-assisted automation acceptable).
- Recreate infra and restore DB in new non-prod account; validate staging.
@Ayush8923 @vprashrex
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.