Account Management: Migrate non-prod workloads

[kartpop]

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

[Ayush8923]

Staging migration -- High Level action item

1. VPC/network design (For reference, check the existing)

2. Inventory + Dependency mapping

• EC2 List
• ECR List
• Security Groups
  • Either use Elastic IPs or via ALB
    • For kaapi console frontend
    • For kaapi backend
    • For guardrails we can use the internal private IPs.
• Secrets Manager
• Alarm/Monitoring
  • Setup the cloudwatch dashboard so that we can monitor all resource from the single dashboard.
• RDS MIgration
  • Export the Staging Database and import in the new RDS instance db.
• Setup the KMS related things.
• S3 Migration

3. Load Balancing, Certs & DNS

4. CI/CD Workflows Updates

5. Verify & Test

[Ayush8923]

For reference, Attaching the Non-Prod migration → action item steps document: https://docs.google.com/document/d/1trNbArZ3A6vSDY_NPKqeh9-L_sSakP7kM8pb0LcTbbg/edit?tab=t.0#heading=h.hcuvhc6y8rt8