Week 9: GuardScript - Backend Migration to AWS

1. Objectives

  • Move GuardScript from the local prototype to an AWS serverless architecture.
  • Redesign the backend data and infrastructure layers to fit Lambda, DynamoDB, and S3.
  • Stabilize the main business flows after migration.

2. Weekly Tasks Breakdown

DayMain TaskDetailsStatus
MonMigration Planning- Reviewed the old prototype and identified the parts that needed migration.
- Clarified changes across runtime, database, storage, and deployment flow.		Completed
TueLambda Backend Restructure- Reorganized the backend into a Lambda-based modular monolith.
- Centralized routing and kept controllers separated by domain for AWS deployment.		Completed
WedDynamoDB Data Redesign- Designed the multi-table model and GSIs for users, workspaces, projects, licenses, invitations, and logs.
- Standardized data access paths for the API layer.		Completed
ThuS3 Storage Migration- Shifted file and script storage to S3 using content references.
- Reduced dependency on the local prototype storage pattern.		Completed
FriAWS Infrastructure Setup- Used SAM/CloudFormation to deploy Lambda, S3, CloudFront, DynamoDB, and WebSocket API.
- Adjusted backend flows so frontend integration could continue after migration.		Completed

3. Outcomes

  • The backend moved toward a clearer AWS-centric architecture.
  • The migration path from local prototype storage to DynamoDB and S3 became technically grounded.
  • Infrastructure-as-code now reflected the main deployment components of the system.

4. Issues & Solutions

  • Issue: Migration required changing runtime model, persistence strategy, and data access patterns at the same time.
  • Solution: Preserved a reasonable API surface while replacing the storage and deployment layers underneath.

5. Next Steps

  • Run end-to-end integration checks between frontend and backend on AWS.
  • Continue stabilizing APIs and resolving migration-related issues.