ProjectTech4DevAI / ProjectTech4DevAI/kaapi-backend
Account Management: Migrate non-prod workloads
@Ayush8923 arbeitet bereits daran.
Seit 28.8.2026.
- Vorherrschende Sprache
- Python
- Sterne
- 18
- Forks
- 10
- Ø Merge
- 2 T. 20 Std.
- Gemergte PRs (30 T.)
- 14
Beschreibung
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
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Bewertung
Dieses Issue wurde noch nicht bewertet.