BudgetBot: Thiết kế AI Money Coach trên AWS trong 48 giờ (Hackathon)

I. Đặt vấn đề: "Nỗi đau" của việc quản lý tài chính cá nhân

"Tháng này mình tiêu gì mà hết tiền nhanh thế nhỉ?"

Chắc chắn ai trong chúng ta cũng đã từng tự hỏi câu đó khi đối mặt với số dư tài khoản hao hụt vào cuối tháng. Thông thường, chúng ta có hai cách để tìm câu trả lời: mở app ngân hàng lên để xem lại danh sách giao dịch viết tắt khô khan dạng FT261982739281 VND..., hoặc tải một app quản lý chi tiêu về và bắt đầu cặm cụi ghi chép.

Nhưng thực tế phũ phàng là hầu hết mọi người đều bỏ cuộc chỉ sau 3 ngày vì quá lười nhập tay từng khoản chi tiêu nhỏ lẻ. Việc bắt người dùng ghi chép thủ công là một thiết kế chưa thực sự tối ưu hóa cho hành vi con người.

Khi tham gia cuộc thi XBrain AWS Accelerator, đội ngũ Group 4 của chúng tôi đã quyết định giải quyết triệt để nỗi đau này bằng cách phát triển BudgetBot — AI Money Coach dành cho người Việt. Ý tưởng cốt lõi rất đơn giản: Người dùng chỉ cần tải lên file sao kê ngân hàng (CSV, Excel, PDF) hoặc ảnh chụp chuyển khoản (VCB, Techcombank, MoMo...) -> AI sẽ tự động phân loại, tính toán ngân sách và trò chuyện trực tiếp để tư vấn chi tiêu.

Xây dựng một ứng dụng AI chạy mượt mà trên máy local là một chuyện, đưa nó lên đám mây AWS để vận hành ổn định, bảo mật dữ liệu tài chính nhạy cảm và tối ưu hóa chi phí với tải thực tế lại là một bài toán hoàn toàn khác. Dưới đây là câu chuyện thiết kế kiến trúc đám mây thực chiến của chúng tôi trong hành trình 48 giờ đầy áp lực đó.

II. The "Ah-ha" Moment: Sơ đồ kiến trúc hạ tầng và các Quyết định thiết kế

Hạ tầng AWS của BudgetBot được thiết kế để phục vụ môi trường production thực tế, chia thành các phân lớp rõ ràng nhằm bảo đảm tính sẵn sàng cao, bảo mật nhiều lớp và khả năng tự động mở rộng theo tải.

Sơ đồ: Kiến trúc tổng thể hệ thống BudgetBot trên AWS Cloud.

Khi thiết kế hạ tầng này, chúng tôi đã đưa ra hai quyết định kiến trúc quan trọng làm thay đổi hoàn toàn hiệu năng và chi phí vận hành của ứng dụng:

1. Tại sao chọn ECS Fargate thay vì AWS Lambda cho Background Worker?

Ban đầu, nhóm đã thảo luận về việc dùng Lambda Serverless cho Worker xử lý file sao kê vì tính tiện lợi và thời gian triển khai nhanh. Tuy nhiên, Fargate đã được chọn vì các yếu tố thực chiến sau:

Khắc phục giới hạn cứng Timeout: Quá trình chạy OCR hình ảnh chuyển khoản qua Textract hoặc gọi Bedrock batch-classification cho hàng nghìn giao dịch là các tác vụ rất nặng và tốn thời gian. AWS Lambda bị giới hạn thời gian chạy tối đa là 15 phút, dễ bị ngắt giữa chừng. ECS Fargate Worker không bị giới hạn thời gian chạy, đảm bảo hoàn thành 100% công việc.
Dự báo chi phí tối ưu (Cost Predictability): Lambda tính phí tuyến tính theo số lượng request và thời gian thực thi tính theo mili-giây. Dưới tải lớn liên tục, chi phí Lambda tăng lũy tiến và rất khó kiểm soát. ECS Fargate chạy ổn định, cho phép quản lý dung lượng tối thiểu/tối đa và tối ưu hóa chi phí tốt hơn trong các tác vụ tính toán kéo dài liên tục.
Quản lý Connection Pooling tới Database: Mỗi khi Lambda scale-out mạnh mẽ, nó sẽ mở ra hàng ngàn connection đồng thời tới RDS PostgreSQL, dễ dẫn đến tràn connection pool và làm sập Database. Đối với container Fargate Web/Worker chạy liên tục (Long-lived process), chúng tôi cấu hình connection pooling ở mức ứng dụng (thư viện SQLAlchemy/psycopg2) trực tiếp trong mã nguồn ứng dụng, giúp tái sử dụng kết nối thay vì mở/đóng liên tục cho mỗi request, bảo vệ RDS khỏi hiện tượng quá tải kết nối.

2. Tối ưu chi phí hạ tầng: NAT Gateway Bypassed & Bảo mật bằng VPC Endpoints (PrivateLink)

Một NAT Gateway chạy liên tục sẽ tiêu tốn khoảng ~$32/tháng chi phí duy trì cố định (chưa tính phí xử lý dữ liệu) — một con số đáng kể đối với một dự án MVP/Hackathon. Để tối ưu hóa chi phí, chúng tôi đã đưa ra một quyết định táo bạo: Không sử dụng NAT Gateway và không chia Private Subnet cho Compute.

Thay vào đó, toàn bộ các container ECS Fargate chạy API backend và Fargate Worker đều được deploy trên Public Subnets với IP công cộng được gán tự động (assign_public_ip = true). Cách thiết kế này cho phép container kết nối trực tiếp ra internet thông qua Internet Gateway để tải thư viện ngoài hoặc cập nhật hệ thống mà không cần NAT Gateway.

Tuy nhiên, đối với dữ liệu tài chính nhạy cảm, làm thế nào để đảm bảo an ninh mạng khi không có Private Subnet cho compute? Chúng tôi đã giải quyết bằng thiết kế bảo mật mạng 3 lớp:

Cô lập Database: RDS PostgreSQL và cache Valkey được cấu hình publicly_accessible = false và Security Groups chỉ cho phép duy nhất traffic từ Security Group của container ECS Fargate đi vào. Mọi truy cập trực tiếp từ internet bên ngoài đều bị chặn đứng tuyệt đối.
AWS WAFv2 & ALB: Đứng ở biên CloudFront và ALB để lọc bỏ lưu lượng độc hại trước khi chạm tới API. WAF được cấu hình các quy tắc AWS Managed Rules Common Rule Set (CRS) chống tấn công OWASP Top 10 và IP Rate Limiting giới hạn tối đa 2000 requests mỗi 5 phút cho một địa chỉ IP nhằm ngăn chặn tấn công DDoS và spam API.
VPC Endpoints (PrivateLink) nội bộ: Để kết nối tới các dịch vụ AWS nhạy cảm như S3, Bedrock, Textract, SQS, Secrets Manager và CloudWatch Logs, chúng tôi không để dữ liệu đi qua internet công cộng. Chúng tôi thiết lập các VPC Interface Endpoints và Gateway Endpoints trực tiếp trong VPC. Mọi lưu lượng dữ liệu nhạy cảm (file sao kê, hình ảnh hóa đơn, API key, token AI...) đi từ container Fargate đến các dịch vụ AWS đều chạy hoàn toàn trên mạng backbone nội bộ của AWS Cloud thông qua PrivateLink, giúp giảm đáng kể chi phí data processing qua NAT Gateway đồng thời mang lại tính an toàn tuyệt đối trước các nguy cơ tấn công nghe lén.

III. The Journey of a Transaction: Hành trình của một giao dịch sao kê

Hãy cùng theo dõi con đường đi của một file sao kê ngân hàng — ví dụ như tệp tin VCB_Statement_04.csv — từ khi người dùng tải lên cho đến khi dữ liệu hiển thị trên Dashboard:

1. Luồng xử lý bất đồng bộ biên

Để đảm bảo người dùng truy cập BudgetBot với độ trễ thấp nhất từ mọi nơi tại Việt Nam, chúng tôi sử dụng Amazon Route 53 định tuyến thông minh kết hợp với Amazon CloudFront phân phối React SPA tĩnh lưu trữ trên Amazon S3 (được bảo vệ bằng Origin Access Control - OAC).
Khi người dùng kéo thả file VCB_Statement_04.csv lên giao diện UI, trình duyệt gửi yêu cầu POST /upload đến API Backend (chạy trên ECS Fargate thông qua ALB).
FastAPI backend sinh ra một S3 Pre-signed URL an sau và trả về cho browser. Trình duyệt thực hiện đẩy trực tiếp (upload) tệp tin VCB_Statement_04.csv lên Amazon S3 (Uploads Bucket) bằng Pre-signed URL này, giúp giải phóng băng thông cho API Server.
Sau khi upload thành công, browser gửi yêu cầu xử lý /enqueue tới API. Backend ghi nhận trạng thái Job là QUEUED vào RDS PostgreSQL, đồng thời gửi một tin nhắn chứa metadata của job vào Amazon SQS và lập tức phản hồi mã 202 Accepted về Frontend để không block UI.

2. Xử lý ngầm tại Background Worker

Message trong SQS được chuyển đến ECS Fargate Worker đang rảnh. SQS Visibility Timeout (300 giây) bảo vệ tác vụ; nếu Fargate Worker bị crash giữa chừng, tác vụ sẽ tự động xuất hiện lại trong queue để worker khác xử lý. Nếu lỗi xảy ra liên tục 3 lần (ví dụ do file hỏng), message sẽ tự động chuyển sang Dead Letter Queue (DLQ) để dev kiểm tra thủ công.
Fargate Worker nhận tin nhắn, tải file VCB_Statement_04.csv từ S3 xuống bộ nhớ tạm và bắt đầu tiền xử lý.

3. Thuật toán Khử trùng lặp 4 cấp độ (Data Integrity)

Trước khi ghi vào Database, dữ liệu giao dịch đi qua bộ lọc khử trùng lặp nghiêm ngặt:

Cấp độ 1 - File Hash SHA-256: So sánh mã hash của toàn bộ file để bỏ qua nếu người dùng tải trùng file.
Cấp độ 2 - Transaction Fingerprint: Tạo chữ ký số dựa trên bộ thuộc tính [Số tiền + Nội dung] kết hợp thuật toán Date Tolerance (dung sai lệch 1-3 ngày) để gộp các giao dịch thực chất là một nhưng bị ngân hàng hạch toán lệch ngày do cuối tuần.
Cấp độ 3 - Cảnh báo mềm (Soft warning): Cảnh báo nếu giao dịch tự nhập tay bị trùng lặp.
Cấp độ 4 - Chống lặp PDF: So khớp vân tay PDF để tránh scan trùng hóa đơn.

4. Hệ thống Phân loại (Classification Pipeline) & Tối ưu hóa AI

Sau khi khử trùng, giao dịch được đưa qua hệ thống phân loại thông minh:

Stage 1: Rule-based (Keyword Matching): Worker chạy kiểm tra từ khóa qua Regex từ điển tiếng Việt ánh xạ sẵn trong code (ví dụ: GRAB -> Transport, HIGHLANDS -> Food), phân loại thành công ~65% lượng giao dịch thông thường với chi phí 0 USD.
Stage 2: LLM Inference (Bedrock): 35% lượng giao dịch mơ hồ còn lại được gom nhóm thành các lô (batch 10 dòng) và gửi đến Amazon Bedrock (Claude Haiku) để phân loại.
Optimizations (Tối ưu): Chúng tôi tách biệt System Prompt và Few-shot ví dụ để Bedrock tối ưu hóa Prompt Caching, mang lại up to 90% cost reduction cho các cached input tokens.
Resilience (Dự phòng): Nếu Bedrock bị lỗi/throttle, hệ thống tự động fallback về phân loại rule-based offline của LocalAI với nhãn needs_review=True, đảm bảo tính High Availability của ứng dụng.
Lưu trữ & Hoàn thành: Giao dịch sau khi phân loại được ghi vào RDS PostgreSQL. Worker cập nhật trạng thái Job là COMPLETED và chủ động gọi API s3.delete_object xóa tệp tin sao kê gốc trên S3 ngay lập tức. S3 Lifecycle rule được cấu hình xóa sau 7 ngày (thời gian tối thiểu theo chu kỳ quét của AWS) đóng vai trò làm sạch dữ liệu dự phòng.
Cập nhật Giao diện: Frontend React SPA sử dụng React Query liên tục poll endpoint /job-status và lập tức cập nhật dashboard tài chính khi phát hiện Job hoàn thành.

IV. Security by Design: Bảo mật dữ liệu tài chính cá nhân

Dữ liệu sao kê ngân hàng là loại thông tin nhạy cảm cao (PII - Personally Identifiable Information). BudgetBot thiết lập cơ chế bảo mật dữ liệu nghiêm ngặt:

Chính sách Bảo vệ Dữ liệu AI: Chúng tôi cấu hình Amazon Bedrock với Data Protection Policy để ngăn chặn việc sử dụng dữ liệu đầu vào cho việc đào tạo mô hình, đồng thời dữ liệu được mã hóa tại chỗ (at rest) bằng AWS managed KMS keys mặc định của dịch vụ RDS (aws/rds) và S3 (aws/s3). AWS cam kết không bao giờ sử dụng dữ liệu prompt/response của khách hàng để huấn luyện các mô hình nền tảng của bên thứ ba (như Anthropic Claude).
Amazon Textract: Dịch vụ xử lý trích xuất văn bản tức thời trên bộ nhớ đệm và không lưu giữ bất kỳ tài liệu hóa đơn nào của khách hàng sau khi hoàn tất xử lý.
Cô lập mạng & định danh: Tất cả dữ liệu truyền qua VPC Endpoint nội bộ an toàn. Danh tính người dùng được cô lập thông qua Cognito User Pools.

V. Cost Optimization: Phân tích Chi phí Thực tế (The Math)

Để minh chứng tính thực tế và khả năng tối ưu hóa chi phí của BudgetBot, dưới đây là bảng tính chi phí ước tính dựa trên benchmark chạy script cost_estimate.py của dự án cho khối lượng 1,000 giao dịch/tháng:

Hạng mục dịch vụ	Chi phí hàng tháng (USD)	Mô tả & Cách tối ưu
Amazon Bedrock (Claude Haiku)	~$0.0166 / 1,000 txns	Chỉ gọi 35% giao dịch. Tối ưu up to 90% cost nhờ Prompt Caching cho cached input tokens.
Amazon RDS PostgreSQL	~$13.00	Sử dụng db.t3.micro (gp3, 20GB, storage encrypted).
Amazon ECS Fargate	~$16.00	Chạy 2 Fargate Tasks (0.25 vCPU, 0.5 GB RAM) cho HA.
Amazon S3 (Uploads)	~$0.50	Dung lượng lưu trữ tạm thời tối thiểu, file xóa ngay sau khi xử lý.
Các dịch vụ khác (SQS, WAF, Route53)	Khai thác Free Tier / Negligible	Chi phí không đáng kể ở quy mô nhỏ.
TỔNG CHI PHÍ ƯỚC TÍNH	~$30.00 / tháng	Hệ thống sẵn sàng cho production với chi phí tối ưu.

Bằng việc lồng ghép cơ chế Keyword matching offline để xử lý 65% giao dịch thông thường và kích hoạt Prompt Caching trên Bedrock, chi phí AI biến đổi của BudgetBot được tối ưu về mức gần như bằng 0 (chưa đến 2 cents cho 1,000 giao dịch). Chi phí duy trì hạ tầng chủ yếu nằm ở các dịch vụ lưu trữ và compute cố định giúp hệ thống luôn ở trạng thái sẵn sàng và có thể dự báo trước.

VI. Kết luận & Bài học kinh nghiệm

Hành trình thiết kế và triển khai BudgetBot trên AWS Cloud mang lại cho chúng tôi những bài học thực chiến giá trị:

Bảo mật dữ liệu tài chính ngay từ gốc: Thiết kế hạ tầng an toàn (Secure by Design) với VPC Endpoints và Security Groups cô lập là bắt buộc đối với các ứng dụng FinTech xử lý dữ liệu PII.
Tối ưu hóa chi phí thông minh: Không nhất thiết phải sử dụng NAT Gateway đắt đỏ nếu chúng ta biết cách tận dụng các public subnets kết hợp VPC Endpoints nội bộ để vừa tiết kiệm chi phí vừa giữ luồng dữ liệu an toàn.
IaC giúp tự động hóa: Việc định nghĩa toàn bộ hạ tầng bằng Terraform giúp việc triển khai, scale và dọn dẹp tài nguyên được thực hiện nhanh chóng, chính xác và đồng bộ trong cả đội ngũ phát triển.

Mã nguồn dự án: github.com/dragoncoil2609/fintech

TỪ ĐỐNG SAO KÊ LỘN XỘN ĐẾN AI INSIGHTS TRONG 48H: BẢN THIẾT KẾ HỆ THỐNG AI MONEY COACH ĐẬM CHẤT AWS NATIVE