Proposal

Dai Viet Blood Donation & Emergency System (DaiVietBlood)

Implemented by: Skyline Team – FPT University Ho Chi Minh City

Date: December 7, 2025

Download PDF

TABLE OF CONTENTS

1. BACKGROUND AND MOTIVATION
   • 1.1 Executive Summary
   • 1.2 Project Success Criteria
   • 1.3 Assumptions
2. SOLUTION ARCHITECTURE / ARCHITECTURAL DIAGRAM
   • 2.1 Technical Architecture Diagram
   • 2.2 Technical Plan
   • 2.3 Project Plan
   • 2.4 Security Considerations
3. ACTIVITIES AND DELIVERABLES
   • 3.1 Activities and Deliverables
   • 3.2 Out of Scope
   • 3.3 Path to Production
4. EXPECTED AWS COST BREAKDOWN
5. IMPLEMENTATION TEAM
6. RESOURCES & ESTIMATED PERSONNEL COSTS
7. ACCEPTANCE

1. BACKGROUND AND MOTIVATION

1.1 EXECUTIVE SUMMARY

Customer Background:

The DaiVietBlood system is designed to serve the community, including voluntary blood donors, patients in need of emergency blood, and healthcare professionals in Vietnam. The primary customers are blood donors, patient families, and medical staff responsible for managing blood inventory and donation schedules. They require a centralized, reliable platform to optimize the matching process between donors and recipients and improve communication during emergencies. In the context of digital health transformation, DaiVietBlood provides a secure, accessible solution to address localized blood shortages.

Business and Technical Objectives:

Migrating the DaiVietBlood system from a local/on-premise environment to AWS offers superior advantages:

• Business: AWS allows the application to scale flexibly according to the user base, reduces hardware infrastructure operational costs, and ensures consistent performance nationwide.
• Technical: AWS provides High Availability and medical data security. Adopting a Serverless Architecture (AWS Lambda, API Gateway, Cognito, RDS) simplifies backend management, accelerates development, and reduces maintenance costs. The system integrates comprehensive monitoring (CloudWatch) and adheres to strict security standards.

Summary of Key Use Cases:

Summary of Partner’s Professional Services: The Skyline Team will provide comprehensive digital transformation services, including assessing the current local application, designing a Cloud-native architecture, and executing the migration of the system to an AWS Serverless environment. We commit to delivering a secure, scalable system accompanied by automated CI/CD pipelines and detailed operational documentation.

1.2 PROJECT SUCCESS CRITERIA

1. Functionality: 100% of core functions (registration, scheduling, emergency requests, administration) operate stably on AWS with no regression errors.
2. Availability: System achieves Uptime ≥ 99.9%, ensuring continuous 24/7 access.
3. Performance: Application response time improves by at least 30% compared to the local version. Emergency request processing time is reduced by 40%.
4. Cost: Infrastructure costs are optimized by at least 20% thanks to the Serverless model and Auto-scaling.
5. User Experience: UAT acceptance rate reaches a minimum of 95% for all user roles.
6. Security: Full compliance with data encryption, access management (IAM), and API security requirements.
7. Operations: CI/CD pipeline is fully automated with deployment time < 10 minutes. Monitoring system covers 100% of critical services.

1.3 ASSUMPTIONS

Technical & Architectural Assumptions:

• Source Code: The current Local application (Frontend & Backend) is functionally complete. The project focuses on Refactoring for the Cloud (Serverless), excluding the development of new features.
• AWS Region: The entire infrastructure is deployed in Singapore (ap-southeast-1) to optimize latency for users in Vietnam. Note: During the testing phase, due to limited VPC configurations and Free Tier/Student resources, latency may fluctuate (estimated ~3.5s/request).
• Service Limits: The AWS account uses default limits (Soft limits). Increasing limits to reduce latency will be approved by the Customer when necessary.
• Third-party Integration: The system uses the Gemini API for AI support features.
• Access Rights: The Skyline Team is granted Admin access (IAM Role) to provision resources.

Operational & Financial Assumptions:

• Domain: The Customer owns the domain name (e.g., daivietblood.com) and DNS configuration rights.
• Cost: The cost estimate is based on an assumption of approximately 50,000 API requests/month. Actual costs depend on usage levels (Pay-as-you-go).

2. SOLUTION ARCHITECTURE / ARCHITECTURAL DIAGRAM

2.1 TECHNICAL ARCHITECTURE DIAGRAM

The DaiVietBlood system utilizes a Serverless-First architecture on AWS Cloud, prioritizing scalability, security, and operational optimization.

Key Components:

1. Network Infrastructure (VPC):
   • Public Subnet: Contains Internet Gateway and NAT Gateway.
   • Private Subnet: Contains AWS Lambda and Amazon RDS to isolate and secure data, preventing direct Internet access.
2. Application & Data:
   • Frontend: Hosted on AWS Amplify, distributed via Amazon CloudFront (CDN), and assets stored on S3.
   • Authentication: Amazon Cognito manages identity and issues JWT tokens.
   • API & Compute: Amazon API Gateway receives requests and routes them to AWS Lambda for business logic processing.
   • Database: Amazon RDS stores structured data, located in the Private Subnet.
3. DevOps & Monitoring:
   • CI/CD: Uses AWS CodePipeline, CodeBuild, CodeDeploy to automate the deployment process.
   • Monitoring: Amazon CloudWatch centrally collects logs and metrics.

2.2 TECHNICAL PLAN

The technical implementation process follows the Infrastructure-as-Code (IaC) methodology:

• Infrastructure Automation: Use AWS CloudFormation to provision VPC, Lambda, RDS, and API Gateway, ensuring consistency across environments (Dev/Staging/Prod).
• Application Development: Refactor backend into modular Lambda functions (NodeJS/Python). Environment variables and sensitive information (DB credentials) are securely encrypted.
• CI/CD Process:
  • Source (GitHub) -> Build (CodeBuild) -> Deploy (CloudFormation/CodeDeploy).
  • Includes a Manual Approval step before deploying to the Production environment.
• Testing Strategy: Unit Tests for Lambda, Integration Tests for API, and Load Tests to ensure capacity.

2.3 PROJECT PLAN

The project applies the Agile Scrum model over 8 weeks (4 Sprints):

• Sprint 1 (Foundation): Set up AWS Account, VPC, RDS.
• Sprint 2 (Backend Core): Develop Lambda, API Gateway, Cognito.
• Sprint 3 (Integration): Deploy Frontend (Amplify), finalize CI/CD Pipeline.
• Sprint 4 (Stabilization): UAT, Performance Optimization, Handover.

2.4 SECURITY CONSIDERATIONS

1. Access Management: Use Cognito for user authentication and IAM Roles for service authorization (Least Privilege).
2. Network Isolation: Database and Lambda are located in the Private Subnet, accessing the Internet only via NAT Gateway.
3. Data Protection: Data encryption At-rest (on RDS/S3) and In-transit (via HTTPS).
4. Security Monitoring: CloudWatch Logs record all activities for auditing and intrusion detection.

3. ACTIVITIES AND DELIVERABLES

3.1 ACTIVITIES AND DELIVERABLES

3.2 OUT OF SCOPE

• Optimal user search algorithm based on real-time Geo-location (currently using simplified logic).
• Complex Auto-scaling for the Database layer (currently using basic RDS).
• Deep Latency Optimization for regions outside Singapore.
• Advanced Security Compliance standards such as HIPAA/PCI-DSS.

3.3 PATH TO PRODUCTION

To upgrade from the current MVP to a large-scale Production system, the following are required:

1. Environment Strategy: Strictly separate Dev/Staging/Prod environments across different AWS accounts (Multi-account strategy).
2. Database Scaling: Migrate to Amazon Aurora Serverless or use Read Replicas to increase read/write capacity.
3. Enhanced Monitoring: Integrate AWS X-Ray to trace requests and identify performance bottlenecks.
4. Strengthened Security: Deploy AWS WAF with rules to block DDoS and automated bots; use Amazon Inspector for periodic vulnerability scanning.

4. EXPECTED AWS COST BREAKDOWN

The following Cost Estimation is based on the Asia Pacific (Singapore) region, which is the standard region for low latency access from Vietnam.

5. TEAM

AWS FCJ Program Lead (Mentor)

Project Stakeholders

Internship Team (FPT University)

Project Escalation Contacts

6. RESOURCES & COST ESTIMATES

Resource Breakdown

Hours by Project Phase

Cost Distribution

*Note on Cost Efficiency: The labor cost for this project is subsidized as part of the FPT University Internship and AWS First Cloud Journey (FCJ) program. The estimated $15 represents the infrastructure running costs (AWS Credits) required for development and testing environments.

7. ACCEPTANCE

7.1 Submission of Deliverables:

Upon completion of the final phase (“Handover”), Skyline Team (PROVIDER) will submit the associated tangible Deliverables (Source Code, AWS Architecture Documentation, Admin Credentials, and Operational Manual) to the Project Stakeholders/Instructors (CUSTOMER). This submission will be accompanied by an Acceptance Form (or a formal Acceptance Email).

7.2 Acceptance Period & Review:

Upon such submission, the Customer will review, evaluate, and perform User Acceptance Testing (UAT) on the applicable Deliverable(s) within five (5) business days (the “Acceptance Period”). The review will determine whether each Deliverable satisfies the Project Success Criteria (defined in Section 1.2) and adheres to the AWS Architecture (defined in Section 2.1) in all material respects.

7.3 Confirmation of Acceptance:

If the Deliverable satisfies its acceptance criteria, the Customer will furnish a written acceptance confirmation to the Provider via the Acceptance Form prior to the end of the Acceptance Period. This signature (or written confirmation) marks the official closure of the project.

7.4 Rejection & Remediation:

For a Deliverable that is not accepted due to a non-conformity (e.g., Critical bugs, Security vulnerabilities, or missing features compared to the Scope of Work), the Customer will indicate the detailed reasons for such rejection on the Acceptance Form (a “Rejection Notice”) within the Acceptance Period.

Upon receipt of a Rejection Notice, the Provider will promptly correct any defects or non-conformities to the extent required. Thereafter, the Provider will resubmit the modified Deliverable to the Customer, and the acceptance process set forth above will be repeated.

7.5 Scope of Re-evaluation:

The Customer will limit its review of resubmitted Deliverables to determining whether or not the Provider has corrected the defects identified in the Rejection Notice and to the effects which these corrections have on other portions of the system.

7.6 Deemed Acceptance:

If the Customer fails to provide the Provider with the above-described Rejection Notice or signed Acceptance Form prior to the end of the applicable Acceptance Period, then the corresponding Deliverable(s) and the project as a whole are deemed accepted.