Account Management: Migrate non-prod workloads #1166

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