diff --git a/content/1-Worklog/1.10-Week10/_index.md b/content/1-Worklog/1.10-Week10/_index.md index 49fa0c5..011dab2 100644 --- a/content/1-Worklog/1.10-Week10/_index.md +++ b/content/1-Worklog/1.10-Week10/_index.md @@ -5,53 +5,71 @@ weight: 2 chapter: false pre: " 1.10. " --- -{{% notice warning %}} + ### Week 10 Objectives: -* Connect and get acquainted with members of First Cloud Journey. -* Understand basic AWS services, how to use the console & CLI. +* Revise the **DocuFlow AI** architecture after evaluating that Bedrock should not be a mandatory dependency for the Free Tier/workshop environment. +* Replace the Bedrock normalization step with an **external AI provider/API** called through a Lambda adapter while keeping the post-Textract JSON normalization flow. +* Rewrite the proposal and workshop so the architecture, cost model, risks, and implementation steps match the new design. ### Tasks to be carried out this week: -| Day | Task | Start Date | Completion Date | Reference Material | -| --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- | --------------- | ----------------------------------------- | -| 2 | - Get acquainted with FCJ members
- Read and take note of internship unit rules and regulations | 08/11/2025 | 08/11/2025 | -| 3 | - Learn about AWS and its types of services
  + Compute
  + Storage
  + Networking
  + Database
  + ...
| 08/12/2025 | 08/12/2025 | | -| 4 | - Create AWS Free Tier account
- Learn about AWS Console & AWS CLI
- **Practice:**
  + Create AWS account
  + Install & configure AWS CLI
  + How to use AWS CLI | 08/13/2025 | 08/13/2025 | | -| 5 | - Learn basic EC2:
  + Instance types
  + AMI
  + EBS
  + ...
- SSH connection methods to EC2
- Learn about Elastic IP
| 08/14/2025 | 08/15/2025 | | -| 6 | - **Practice:**
  + Launch an EC2 instance
  + Connect via SSH
  + Attach an EBS volume | 08/15/2025 | 08/15/2025 | | +| Day | Task | Start Date | Completion Date | Reference Material | +| --- | ---- | ---------- | --------------- | ------------------ | +| 2 | - Review Free Tier and AI access constraints
  + Check Bedrock pricing and model access requirements
  + Decide that Bedrock should not be mandatory in the MVP
  + Move to an external AI approach to reduce account/policy risk | 06/22/2026 | 06/22/2026 | [Amazon Bedrock Pricing](https://aws.amazon.com/bedrock/pricing/)
[AWS Free Tier](https://aws.amazon.com/free/) | +| 3 | - Revise the system architecture
  + Remove the Bedrock state from the Step Functions workflow
  + Add an `externalAiNormalize` Lambda that calls an external AI API
  + Store the API key in Secrets Manager instead of code or frontend config
  + Update the diagram and data flow | 06/23/2026 | 06/23/2026 | [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)
[Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) | +| 4 | - Update the data contract, status model, and error handling
  + Keep the shared JSON schema for invoices/receipts
  + Add `EXTERNAL_AI_FAILED` handling or map it to `REVIEW_REQUIRED`/`FAILED`
  + Update workflow retry/catch behavior
  + Adjust the IAM role for the Lambda adapter | 06/24/2026 | 06/24/2026 | [Step Functions Error Handling](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html)
[IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) | +| 5 | - Update cost and risk analysis
  + Remove Bedrock from the AWS baseline cost table
  + Add external AI provider cost by request/token
  + Add risks for API keys, quota, latency, network timeout, and sensitive data leaving AWS
  + Update cost control and cleanup checklists | 06/25/2026 | 06/25/2026 | [AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html)
[CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
[Secrets Manager Pricing](https://aws.amazon.com/secrets-manager/pricing/) | +| 6 | - Rewrite the proposal based on the new architecture
  + Update the executive summary, architecture, service selection, and workflow
  + Replace Bedrock with the External AI Lambda Adapter
  + Update the timeline, cost estimation, risk mitigation, and definition of done | 06/26/2026 | 06/26/2026 | [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)
[Serverless Lens](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html) | +| 7 | - Rewrite the workshop based on the updated proposal
  + Update overview, prerequisites, and the AI extraction module
  + Rewrite the external AI secret configuration steps
  + Update deploy steps, test cases, evidence, and cleanup
  + Re-check workshop internal links | 06/27/2026 | 06/27/2026 | [AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html)
[S3 Presigned URL Upload](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html)
[Amazon Textract AnalyzeExpense](https://docs.aws.amazon.com/textract/latest/dg/analyzing-document-expense.html) | ### Week 10 Achievements: -* Understood what AWS is and mastered the basic service groups: - * Compute - * Storage - * Networking - * Database - * ... +* Reconfirmed the **DocuFlow AI** architecture direction: + * Bedrock is no longer a mandatory MVP component because of policy/model access/cost risk in Free Tier or workshop accounts. + * Textract remains responsible for invoice/receipt data extraction. + * Normalization, classification, and JSON schema generation now move to an external AI provider behind a dedicated Lambda adapter. -* Successfully created and configured an AWS Free Tier account. +* Updated the processing flow: + * The user uploads an invoice/receipt to the S3 raw bucket using a presigned URL. + * The S3 Object Created event flows through EventBridge and SQS. + * Step Functions orchestrates file validation, Textract, `externalAiNormalize`, JSON validation, result persistence, and status updates. + * DynamoDB stores metadata/status; S3 processed stores result JSON; CloudWatch and SNS handle logs, alarms, and notifications. -* Became familiar with the AWS Management Console and learned how to find, access, and use services via the web interface. +* Redesigned the external AI integration: + * A Lambda adapter isolates external AI API calls from the main workflow. + * The API key is stored in AWS Secrets Manager, not in frontend code, source code, or public configuration files. + * The adapter handles sensitive-data masking when needed, input length limits, timeout, retry, and response normalization into the internal schema. -* Installed and configured AWS CLI on the computer, including: - * Access Key - * Secret Key - * Default Region - * ... +* Updated the data contract and status model: + * Kept the shared schema with `documentId`, `userId`, `fileName`, `documentType`, `vendorName`, `invoiceDate`, `currency`, `totalAmount`, `taxAmount`, `lineItems`, `confidenceScore`, `status`, `s3RawPath`, and `s3ProcessedPath`. + * Added handling for external AI failures such as timeout, quota exceeded, invalid JSON, and schema mismatch. + * Failures can move to `REVIEW_REQUIRED` when human review is useful, or `FAILED` when the workflow cannot continue. -* Used AWS CLI to perform basic operations such as: +* Updated the cost analysis: + * Removed Bedrock from the AWS baseline cost. + * Kept the main AWS services: Cognito, S3, CloudFront, API Gateway, Lambda, EventBridge, SQS, Step Functions, Textract, DynamoDB, CloudWatch, SNS, Secrets Manager, and SAM/CloudFormation. + * Added external AI provider cost as a separate item based on request/token usage and outside AWS Free Tier. + * Added cost controls: demo file limit, page-per-file limit, input/output token limits, budget alerts, and post-workshop cleanup. - * Check account & configuration information - * Retrieve the list of regions - * View EC2 service - * Create and manage key pairs - * Check information about running services - * ... +* Updated the risk matrix: + * External AI API key exposure is mitigated with Secrets Manager and least-privilege IAM. + * Quota/rate-limit risk is mitigated with controlled retry, timeout, and fallback to `REVIEW_REQUIRED`. + * Sensitive data leaving AWS is mitigated by sending only fields needed for normalization, masking when required, and documenting the boundary in the workshop. + * Latency/network timeout risk is mitigated with Step Functions retry/catch and explicit statuses. -* Acquired the ability to connect between the web interface and CLI to manage AWS resources in parallel. -* ... +* Reworked the proposal: + * Updated the high-level architecture and service selection. + * Replaced Bedrock with the External AI Lambda Adapter. + * Updated workflow, cost estimation, risk mitigation, security baseline, and definition of done. + * Synchronized the bilingual Vietnamese and English content. + +* Reworked the workshop: + * Updated overview and prerequisites for the new architecture. + * Rewrote the AI extraction module to use Textract + external AI adapter instead of Textract + Bedrock. + * Added secret configuration, deployment, happy-path test, low-confidence/failure-path test, and cleanup steps. + * Rechecked the evidence checklist for the final report. diff --git a/content/1-Worklog/1.10-Week10/_index.vi.md b/content/1-Worklog/1.10-Week10/_index.vi.md index 0674415..667b93a 100644 --- a/content/1-Worklog/1.10-Week10/_index.vi.md +++ b/content/1-Worklog/1.10-Week10/_index.vi.md @@ -5,53 +5,71 @@ weight: 2 chapter: false pre: " 1.10. " --- -{{% notice warning %}} + ### Mục tiêu tuần 10: -* Kết nối, làm quen với các thành viên trong First Cloud Journey. -* Hiểu dịch vụ AWS cơ bản, cách dùng console & CLI. +* Điều chỉnh lại kiến trúc **DocuFlow AI** sau khi đánh giá Bedrock không phù hợp làm dependency bắt buộc cho môi trường Free Tier/workshop. +* Thay bước Bedrock bằng **External AI provider/API** được gọi qua Lambda adapter để vẫn giữ được luồng chuẩn hóa JSON sau Textract. +* Làm lại proposal và workshop để đồng bộ với kiến trúc mới, chi phí mới, rủi ro mới và các bước triển khai mới. ### Các công việc cần triển khai trong tuần này: -| Thứ | Công việc | Ngày bắt đầu | Ngày hoàn thành | Nguồn tài liệu | -| --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | --------------- | ----------------------------------------- | -| 2 | - Làm quen với các thành viên FCJ
- Đọc và lưu ý các nội quy, quy định tại đơn vị thực tập | 11/08/2025 | 11/08/2025 | -| 3 | - Tìm hiểu AWS và các loại dịch vụ
  + Compute
  + Storage
  + Networking
  + Database
  + ...
| 12/08/2025 | 12/08/2025 | | -| 4 | - Tạo AWS Free Tier account
- Tìm hiểu AWS Console & AWS CLI
- **Thực hành:**
  + Tạo AWS account
  + Cài AWS CLI & cấu hình
  + Cách sử dụng AWS CLI | 13/08/2025 | 13/08/2025 | | -| 5 | - Tìm hiểu EC2 cơ bản:
  + Instance types
  + AMI
  + EBS
  + ...
- Các cách remote SSH vào EC2
- Tìm hiểu Elastic IP
| 14/08/2025 | 15/08/2025 | | -| 6 | - **Thực hành:**
  + Tạo EC2 instance
  + Kết nối SSH
  + Gắn EBS volume | 15/08/2025 | 15/08/2025 | | +| Thứ | Công việc | Ngày bắt đầu | Ngày hoàn thành | Nguồn tài liệu | +| --- | --------- | ------------ | --------------- | -------------- | +| 2 | - Rà soát lại ràng buộc Free Tier và quyền truy cập AI
  + Kiểm tra Bedrock pricing/model access
  + Xác định Bedrock không nên là service bắt buộc trong MVP
  + Chốt hướng chuyển sang external AI để giảm rủi ro account/policy | 22/06/2026 | 22/06/2026 | [Amazon Bedrock Pricing](https://aws.amazon.com/bedrock/pricing/)
[AWS Free Tier](https://aws.amazon.com/free/) | +| 3 | - Sửa lại kiến trúc hệ thống
  + Bỏ state Bedrock khỏi Step Functions workflow
  + Thêm Lambda `externalAiNormalize` gọi external AI API
  + Lưu API key bằng Secrets Manager, không hard-code trong code hoặc frontend
  + Cập nhật diagram và luồng dữ liệu mới | 23/06/2026 | 23/06/2026 | [AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)
[Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html) | +| 4 | - Cập nhật data contract, status model và error handling
  + Giữ output JSON schema chung cho invoice/receipt
  + Thêm lỗi `EXTERNAL_AI_FAILED` hoặc map về `REVIEW_REQUIRED`/`FAILED`
  + Cập nhật retry/catch trong workflow
  + Điều chỉnh IAM role cho Lambda adapter | 24/06/2026 | 24/06/2026 | [Step Functions Error Handling](https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html)
[IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) | +| 5 | - Cập nhật chi phí và rủi ro
  + Loại Bedrock khỏi bảng cost baseline
  + Thêm chi phí external AI provider theo request/token
  + Bổ sung rủi ro API key, quota, latency, network timeout và dữ liệu nhạy cảm gửi ra ngoài AWS
  + Cập nhật cost control và cleanup checklist | 25/06/2026 | 25/06/2026 | [AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html)
[CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
[Secrets Manager Pricing](https://aws.amazon.com/secrets-manager/pricing/) | +| 6 | - Làm lại proposal theo kiến trúc mới
  + Sửa executive summary, architecture, service selection và workflow
  + Thay Bedrock bằng External AI Lambda Adapter
  + Cập nhật timeline, cost estimation, risk mitigation và definition of done | 26/06/2026 | 26/06/2026 | [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)
[Serverless Lens](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html) | +| 7 | - Làm lại workshop theo proposal mới
  + Cập nhật overview, prerequisite và module AI extraction
  + Viết lại bước cấu hình secret external AI
  + Cập nhật hướng dẫn deploy, test case, evidence và cleanup
  + Kiểm tra lại liên kết nội bộ của workshop | 27/06/2026 | 27/06/2026 | [AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html)
[S3 Presigned URL Upload](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html)
[Amazon Textract AnalyzeExpense](https://docs.aws.amazon.com/textract/latest/dg/analyzing-document-expense.html) | ### Kết quả đạt được tuần 10: -* Hiểu AWS là gì và nắm được các nhóm dịch vụ cơ bản: - * Compute - * Storage - * Networking - * Database - * ... +* Đã xác định lại hướng kiến trúc cho **DocuFlow AI**: + * Bedrock không còn là thành phần bắt buộc trong MVP vì rủi ro policy/model access/cost đối với tài khoản Free Tier hoặc tài khoản workshop. + * Textract vẫn giữ vai trò trích xuất dữ liệu invoice/receipt. + * Bước chuẩn hóa, phân loại và tạo JSON schema được chuyển sang external AI provider thông qua một Lambda adapter riêng. -* Đã tạo và cấu hình AWS Free Tier account thành công. +* Cập nhật luồng xử lý mới: + * User upload invoice/receipt lên S3 raw bằng presigned URL. + * S3 Object Created event đi qua EventBridge và SQS. + * Step Functions điều phối các bước validate file, gọi Textract, gọi `externalAiNormalize`, validate JSON, lưu kết quả và cập nhật status. + * DynamoDB lưu metadata/status; S3 processed lưu JSON kết quả; CloudWatch và SNS xử lý log/alarm/notification. -* Làm quen với AWS Management Console và biết cách tìm, truy cập, sử dụng dịch vụ từ giao diện web. +* Thiết kế lại phần external AI integration: + * Tạo Lambda adapter để cô lập logic gọi external AI API khỏi workflow chính. + * API key được lưu trong AWS Secrets Manager, không đưa vào frontend, source code hoặc file cấu hình public. + * Lambda adapter chịu trách nhiệm mask dữ liệu nhạy cảm nếu cần, giới hạn input length, timeout, retry và chuẩn hóa response về schema nội bộ. -* Cài đặt và cấu hình AWS CLI trên máy tính bao gồm: - * Access Key - * Secret Key - * Region mặc định - * ... +* Cập nhật data contract và status model: + * Giữ schema chung gồm `documentId`, `userId`, `fileName`, `documentType`, `vendorName`, `invoiceDate`, `currency`, `totalAmount`, `taxAmount`, `lineItems`, `confidenceScore`, `status`, `s3RawPath`, `s3ProcessedPath`. + * Bổ sung handling cho lỗi external AI như timeout, quota exceeded, invalid JSON hoặc schema mismatch. + * Các lỗi có thể chuyển sang `REVIEW_REQUIRED` nếu cần reviewer kiểm tra, hoặc `FAILED` nếu workflow không thể tiếp tục. -* Sử dụng AWS CLI để thực hiện các thao tác cơ bản như: +* Cập nhật phân tích chi phí: + * Loại Bedrock khỏi baseline AWS cost. + * Giữ các dịch vụ AWS chính: Cognito, S3, CloudFront, API Gateway, Lambda, EventBridge, SQS, Step Functions, Textract, DynamoDB, CloudWatch, SNS, Secrets Manager và SAM/CloudFormation. + * Thêm chi phí external AI provider như một hạng mục riêng, phụ thuộc vào request/token và không tính là AWS Free Tier. + * Bổ sung cost control: giới hạn số file demo, giới hạn số trang/file, giới hạn token đầu vào/đầu ra, budget alert và cleanup sau workshop. - * Kiểm tra thông tin tài khoản & cấu hình - * Lấy danh sách region - * Xem dịch vụ EC2 - * Tạo và quản lý key pair - * Kiểm tra thông tin dịch vụ đang chạy - * ... +* Cập nhật risk matrix: + * Rủi ro external AI API key bị lộ được giảm bằng Secrets Manager và IAM least privilege. + * Rủi ro quota/rate limit được giảm bằng retry có kiểm soát, timeout và fallback sang `REVIEW_REQUIRED`. + * Rủi ro gửi dữ liệu nhạy cảm ra ngoài AWS được giảm bằng cách chỉ gửi field cần chuẩn hóa, mask dữ liệu nếu cần và ghi rõ giới hạn trong workshop. + * Rủi ro latency/network timeout được giảm bằng Step Functions retry/catch và status rõ ràng. -* Có khả năng kết nối giữa giao diện web và CLI để quản lý tài nguyên AWS song song. -* ... +* Làm lại proposal: + * Cập nhật kiến trúc high-level và service selection. + * Thay Bedrock bằng External AI Lambda Adapter. + * Cập nhật workflow, cost estimation, risk mitigation, security baseline và definition of done. + * Đồng bộ lại các phần bilingual để nội dung tiếng Việt và tiếng Anh nhất quán. + +* Làm lại workshop: + * Cập nhật overview và prerequisite theo kiến trúc mới. + * Viết lại module AI extraction để dùng Textract + external AI adapter thay vì Textract + Bedrock. + * Bổ sung bước cấu hình secret, deploy, test happy path, test low confidence/failure path và cleanup. + * Rà soát lại checklist evidence để phục vụ báo cáo cuối kỳ. diff --git a/content/1-Worklog/1.6-Week6/_index.md b/content/1-Worklog/1.6-Week6/_index.md index 027b66e..c14c522 100644 --- a/content/1-Worklog/1.6-Week6/_index.md +++ b/content/1-Worklog/1.6-Week6/_index.md @@ -5,53 +5,51 @@ weight: 1 chapter: false pre: " 1.6. " --- -{{% notice warning %}} + ### Week 6 Objectives: -* Connect and get acquainted with members of First Cloud Journey. -* Understand basic AWS services, how to use the console & CLI. +* Build a foundation in **resource governance** with AWS Tags and Resource Groups for organizing, querying, and automating actions across many resources. +* Strengthen **IAM least privilege** with tag-based access control for EC2 and Permission Boundaries that cap the maximum permissions of users. +* Practice **encryption at rest** for Amazon S3 using AWS KMS, combined with AWS CloudTrail and Amazon Athena to audit key usage. +* Get started with **AWS Security Hub** to centralize security findings and run continuous compliance checks against AWS best practices. +* Optimize **operations and cost** with Lambda-based EC2 start/stop automation. ### Tasks to be carried out this week: -| Day | Task | Start Date | Completion Date | Reference Material | -| --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- | --------------- | ----------------------------------------- | -| 2 | - Get acquainted with FCJ members
- Read and take note of internship unit rules and regulations | 08/11/2025 | 08/11/2025 | -| 3 | - Learn about AWS and its types of services
  + Compute
  + Storage
  + Networking
  + Database
  + ...
| 08/12/2025 | 08/12/2025 | | -| 4 | - Create AWS Free Tier account
- Learn about AWS Console & AWS CLI
- **Practice:**
  + Create AWS account
  + Install & configure AWS CLI
  + How to use AWS CLI | 08/13/2025 | 08/13/2025 | | -| 5 | - Learn basic EC2:
  + Instance types
  + AMI
  + EBS
  + ...
- SSH connection methods to EC2
- Learn about Elastic IP
| 08/14/2025 | 08/15/2025 | | -| 6 | - **Practice:**
  + Launch an EC2 instance
  + Connect via SSH
  + Attach an EBS volume | 08/15/2025 | 08/15/2025 | | +| Day | Task | Start Date | Completion Date | Reference Material | +| --- | ---- | ---------- | --------------- | ------------------ | +| 2 | - Practice **Tags & Resource Groups**:
  + Apply tags to EC2/S3 and other resources
  + Create a tag-based Resource Group
  + Use the group to manage and automate actions
  + Clean up resources | 25/05/2026 | 25/05/2026 | [Tags & Resource Groups](https://000027.awsstudygroup.com/) | +| 3 | - Practice **IAM tag-based access control for EC2**:
  + Create IAM policy with `Condition` on resource tags
  + Create IAM role for an EC2 Administrator persona
  + Validate least-privilege behavior
- Practice **IAM Permission Boundary**:
  + Create restriction policy as a boundary
  + Create a bounded IAM user
  + Verify the effective permissions and clean up | 26/05/2026 | 26/05/2026 | [IAM with Resource Tags](https://000028.awsstudygroup.com/)
[IAM Permission Boundary](https://000030.awsstudygroup.com/) | +| 4 | - Practice **Encrypt at rest with AWS KMS**:
  + Prepare IAM users/roles for the lab
  + Create a KMS Customer Managed Key (CMK)
  + Create an S3 bucket and enable SSE-KMS
  + Configure CloudTrail and query KMS events with Athena
  + Test sharing encrypted objects and clean up | 27/05/2026 | 27/05/2026 | [Encrypt at Rest with AWS KMS](https://000033.awsstudygroup.com/) | +| 5 | - Practice **AWS Security Hub**:
  + Review supported security standards
  + Enable Security Hub and integrations
  + Read the security score and findings by standard
  + Clean up resources | 28/05/2026 | 28/05/2026 | [AWS Security Hub](https://000018.awsstudygroup.com/) | +| 6 | - Practice **Optimize EC2 cost with Lambda**:
  + Tag instances by start/stop schedule
  + Create IAM role for Lambda
  + Author Lambda function and trigger via EventBridge
  + Verify start/stop and clean up | 29/05/2026 | 29/05/2026 | [Optimize EC2 Cost with Lambda](https://000022.awsstudygroup.com/) | ### Week 6 Achievements: -* Understood what AWS is and mastered the basic service groups: - * Compute - * Storage - * Networking - * Database - * ... +* Understood the role of **Tags** as metadata for organizing AWS resources by purpose, owner, environment, or cost center, and applied a consistent tagging convention across EC2 and S3 resources. -* Successfully created and configured an AWS Free Tier account. +* Created a **Resource Group** based on tag query to manage many resources as a single logical unit and reviewed how Resource Groups support automation across services. -* Became familiar with the AWS Management Console and learned how to find, access, and use services via the web interface. +* Applied the **principle of least privilege** in IAM by writing a policy with `Condition` blocks that grant EC2 actions only when the target resource carries a specific tag, and validated the behavior with an EC2 Administrator role. -* Installed and configured AWS CLI on the computer, including: - * Access Key - * Secret Key - * Default Region - * ... +* Configured an **IAM Permission Boundary** to cap the maximum permissions of a user, observed how the effective permissions are the intersection of the identity policy and the boundary, and used the pattern to mitigate privilege escalation risks. -* Used AWS CLI to perform basic operations such as: +* Created an **AWS KMS Customer Managed Key (CMK)** with appropriate key policies and used it to enable **SSE-KMS** encryption on an Amazon S3 bucket for data protection at rest. - * Check account & configuration information - * Retrieve the list of regions - * View EC2 service - * Create and manage key pairs - * Check information about running services - * ... +* Enabled **AWS CloudTrail** to capture KMS and S3 events and queried the trail logs with **Amazon Athena** to audit who used the key, when, and against which objects. -* Acquired the ability to connect between the web interface and CLI to manage AWS resources in parallel. -* ... +* Practiced **sharing encrypted S3 objects** across IAM principals while keeping key access controlled through KMS grants and key policies, and completed full cleanup of KMS, S3, CloudTrail and Athena artifacts. + +* Enabled **AWS Security Hub** and reviewed supported standards (e.g., AWS Foundational Security Best Practices, CIS) to get a centralized view of high-priority findings across services. + +* Read the **security score by standard**, drilled into failed controls, and understood how Security Hub aggregates findings from sources such as GuardDuty, Inspector, and Macie into a single dashboard. + +* Built an **EC2 cost optimization** workflow with **AWS Lambda**: tagged instances with start/stop schedules, created a Lambda execution role with `ec2:StartInstances` and `ec2:StopInstances`, and authored a function to act on tagged instances. + +* Verified the start/stop logic by triggering the Lambda manually and on a schedule via EventBridge, confirming that only tagged instances were affected, and cleaned up the function, role, and policies after the lab. + +* Reinforced the **cleanup discipline** at the end of every workshop to keep AWS bills predictable and the practice account tidy. diff --git a/content/1-Worklog/1.6-Week6/_index.vi.md b/content/1-Worklog/1.6-Week6/_index.vi.md index 997d0e9..7f8841f 100644 --- a/content/1-Worklog/1.6-Week6/_index.vi.md +++ b/content/1-Worklog/1.6-Week6/_index.vi.md @@ -5,52 +5,51 @@ weight: 1 chapter: false pre: " 1.6. " --- -{{% notice warning %}} + ### Mục tiêu tuần 6: -* Kết nối, làm quen với các thành viên trong First Cloud Journey. -* Hiểu dịch vụ AWS cơ bản, cách dùng console & CLI. +* Xây nền **resource governance** với AWS Tags và Resource Groups để tổ chức, truy vấn và tự động hoá thao tác trên nhiều tài nguyên. +* Củng cố **IAM least privilege** với tag-based access control cho EC2 và Permission Boundary để giới hạn quyền tối đa của user. +* Thực hành **mã hoá dữ liệu lúc nghỉ (encryption at rest)** cho Amazon S3 bằng AWS KMS, kết hợp AWS CloudTrail và Amazon Athena để audit việc sử dụng key. +* Làm quen với **AWS Security Hub** nhằm tập trung hoá security findings và liên tục đánh giá tuân thủ theo best practices của AWS. +* Tối ưu **vận hành và chi phí** bằng Lambda tự động start/stop EC2. ### Các công việc cần triển khai trong tuần này: -| Thứ | Công việc | Ngày bắt đầu | Ngày hoàn thành | Nguồn tài liệu | -| --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | --------------- | ----------------------------------------- | -| 2 | - Làm quen với các thành viên FCJ
- Đọc và lưu ý các nội quy, quy định tại đơn vị thực tập | 11/08/2025 | 11/08/2025 | -| 3 | - Tìm hiểu AWS và các loại dịch vụ
  + Compute
  + Storage
  + Networking
  + Database
  + ...
| 12/08/2025 | 12/08/2025 | | -| 4 | - Tạo AWS Free Tier account
- Tìm hiểu AWS Console & AWS CLI
- **Thực hành:**
  + Tạo AWS account
  + Cài AWS CLI & cấu hình
  + Cách sử dụng AWS CLI | 13/08/2025 | 13/08/2025 | | -| 5 | - Tìm hiểu EC2 cơ bản:
  + Instance types
  + AMI
  + EBS
  + ...
- Các cách remote SSH vào EC2
- Tìm hiểu Elastic IP
| 14/08/2025 | 15/08/2025 | | -| 6 | - **Thực hành:**
  + Tạo EC2 instance
  + Kết nối SSH
  + Gắn EBS volume | 15/08/2025 | 15/08/2025 | | +| Thứ | Công việc | Ngày bắt đầu | Ngày hoàn thành | Nguồn tài liệu | +| --- | --------- | ------------ | --------------- | -------------- | +| 2 | - Thực hành **Tags & Resource Groups**:
  + Gắn tag cho EC2/S3 và các tài nguyên khác
  + Tạo Resource Group theo tag query
  + Dùng group để quản lý và tự động hoá thao tác
  + Cleanup tài nguyên | 25/05/2026 | 25/05/2026 | [Tags & Resource Groups](https://000027.awsstudygroup.com/) | +| 3 | - Thực hành **IAM tag-based access control cho EC2**:
  + Tạo IAM policy với `Condition` theo resource tag
  + Tạo IAM role cho persona EC2 Administrator
  + Kiểm thử hành vi least-privilege
- Thực hành **IAM Permission Boundary**:
  + Tạo restriction policy làm boundary
  + Tạo IAM user gắn boundary
  + Xác minh effective permissions và cleanup | 26/05/2026 | 26/05/2026 | [IAM with Resource Tags](https://000028.awsstudygroup.com/)
[IAM Permission Boundary](https://000030.awsstudygroup.com/) | +| 4 | - Thực hành **Encrypt at rest với AWS KMS**:
  + Chuẩn bị IAM user/role cho lab
  + Tạo KMS Customer Managed Key (CMK)
  + Tạo S3 bucket và bật SSE-KMS
  + Cấu hình CloudTrail và truy vấn event KMS bằng Athena
  + Test chia sẻ object đã mã hoá và cleanup | 27/05/2026 | 27/05/2026 | [Encrypt at Rest với AWS KMS](https://000033.awsstudygroup.com/) | +| 5 | - Thực hành **AWS Security Hub**:
  + Xem các security standard được hỗ trợ
  + Bật Security Hub và các integration
  + Đọc security score và findings theo từng standard
  + Cleanup tài nguyên | 28/05/2026 | 28/05/2026 | [AWS Security Hub](https://000018.awsstudygroup.com/) | +| 6 | - Thực hành **Tối ưu chi phí EC2 với Lambda**:
  + Gắn tag instance theo lịch start/stop
  + Tạo IAM role cho Lambda
  + Viết Lambda function và trigger qua EventBridge
  + Kiểm thử start/stop và cleanup | 29/05/2026 | 29/05/2026 | [Optimize EC2 Cost với Lambda](https://000022.awsstudygroup.com/) | ### Kết quả đạt được tuần 6: -* Hiểu AWS là gì và nắm được các nhóm dịch vụ cơ bản: - * Compute - * Storage - * Networking - * Database - * ... - -* Đã tạo và cấu hình AWS Free Tier account thành công. - -* Làm quen với AWS Management Console và biết cách tìm, truy cập, sử dụng dịch vụ từ giao diện web. - -* Cài đặt và cấu hình AWS CLI trên máy tính bao gồm: - * Access Key - * Secret Key - * Region mặc định - * ... - -* Sử dụng AWS CLI để thực hiện các thao tác cơ bản như: - - * Kiểm tra thông tin tài khoản & cấu hình - * Lấy danh sách region - * Xem dịch vụ EC2 - * Tạo và quản lý key pair - * Kiểm tra thông tin dịch vụ đang chạy - * ... - -* Có khả năng kết nối giữa giao diện web và CLI để quản lý tài nguyên AWS song song. -* ... + +* Hiểu vai trò của **Tag** như metadata để tổ chức tài nguyên AWS theo mục đích, owner, environment hoặc cost center, và đã áp dụng convention tag thống nhất trên EC2 và S3. + +* Tạo **Resource Group** dựa trên tag query để quản lý nhiều tài nguyên như một đơn vị logic duy nhất, đồng thời hiểu cách Resource Groups hỗ trợ automation xuyên service. + +* Áp dụng **nguyên tắc least privilege** trong IAM bằng policy có `Condition` cấp quyền EC2 chỉ khi resource mang tag phù hợp, và xác minh hành vi qua role EC2 Administrator. + +* Cấu hình **IAM Permission Boundary** để giới hạn quyền tối đa của user, quan sát được effective permissions là phần giao giữa identity policy và boundary, và áp dụng pattern này để giảm rủi ro privilege escalation. + +* Tạo **AWS KMS Customer Managed Key (CMK)** với key policy phù hợp và dùng key này để bật **SSE-KMS** cho S3 bucket nhằm bảo vệ dữ liệu lúc nghỉ. + +* Bật **AWS CloudTrail** để ghi lại event của KMS và S3, sau đó dùng **Amazon Athena** truy vấn log để audit ai đã dùng key, khi nào và trên object nào. + +* Thực hành **chia sẻ object S3 đã mã hoá** giữa các IAM principal trong khi vẫn kiểm soát quyền truy cập key qua key policy/grant, và cleanup toàn bộ KMS, S3, CloudTrail, Athena artifact sau lab. + +* Bật **AWS Security Hub** và xem qua các standard được hỗ trợ (ví dụ AWS Foundational Security Best Practices, CIS) để có cái nhìn tập trung về findings ưu tiên cao xuyên các service. + +* Đọc **security score theo từng standard**, drill-down vào các control fail, và hiểu cách Security Hub gom findings từ GuardDuty, Inspector, Macie về một dashboard duy nhất. + +* Xây dựng workflow **tối ưu chi phí EC2** bằng **AWS Lambda**: gắn tag schedule cho instance, tạo execution role với quyền `ec2:StartInstances`/`ec2:StopInstances`, viết hàm Lambda thao tác trên các instance được tag. + +* Xác minh logic start/stop qua trigger thủ công và lịch tự động bằng EventBridge, đảm bảo chỉ instance được tag bị tác động, sau đó cleanup function, role và policy sau lab. + +* Củng cố thói quen **cleanup** sau mỗi workshop để giữ chi phí AWS dự đoán được và tài khoản thực hành gọn gàng. diff --git a/content/1-Worklog/1.7-Week7/_index.md b/content/1-Worklog/1.7-Week7/_index.md index 8cb1440..bd3e630 100644 --- a/content/1-Worklog/1.7-Week7/_index.md +++ b/content/1-Worklog/1.7-Week7/_index.md @@ -5,53 +5,50 @@ weight: 1 chapter: false pre: " 1.7. " --- -{{% notice warning %}} -⚠️ **Note:** The following information is for reference purposes only. Please **do not copy verbatim** for your own report, including this warning. -{{% /notice %}} - ### Week 7 Objectives: -* Connect and get acquainted with members of First Cloud Journey. -* Understand basic AWS services, how to use the console & CLI. +* Deep-dive into **advanced AWS IAM** — roles, conditions, Permission Boundaries, Identity Center SSO — to apply least-privilege at enterprise scale. +* Understand and practice **network-level security** with AWS WAF and VPC Endpoints (PrivateLink) to protect workloads from the public internet. ### Tasks to be carried out this week: -| Day | Task | Start Date | Completion Date | Reference Material | -| --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- | --------------- | ----------------------------------------- | -| 2 | - Get acquainted with FCJ members
- Read and take note of internship unit rules and regulations | 08/11/2025 | 08/11/2025 | -| 3 | - Learn about AWS and its types of services
  + Compute
  + Storage
  + Networking
  + Database
  + ...
| 08/12/2025 | 08/12/2025 | | -| 4 | - Create AWS Free Tier account
- Learn about AWS Console & AWS CLI
- **Practice:**
  + Create AWS account
  + Install & configure AWS CLI
  + How to use AWS CLI | 08/13/2025 | 08/13/2025 | | -| 5 | - Learn basic EC2:
  + Instance types
  + AMI
  + EBS
  + ...
- SSH connection methods to EC2
- Learn about Elastic IP
| 08/14/2025 | 08/15/2025 | | -| 6 | - **Practice:**
  + Launch an EC2 instance
  + Connect via SSH
  + Attach an EBS volume | 08/15/2025 | 08/15/2025 | | - +| Day | Task | Start Date | Completion Date | Reference Material | +| --- | ---- | ---------- | --------------- | ------------------ | +| 2 | - Practice **IAM Role & Condition**:
  + Review IAM concepts (User, Group, Role, Policy)
  + Create IAM Group and IAM User for EC2 and RDS administrators
  + Create IAM Role with `Condition` (IP address and time restrictions)
  + Test assume-role behavior and clean up | 01/06/2026 | 01/06/2026 | [IAM Role & Condition](https://000044.awsstudygroup.com/) | +| 3 | - Practice **IAM Permission Boundary**:
  + Understand Permission Boundary vs. Identity-based Policy
  + Create a restriction policy and apply it as a Permission Boundary
  + Create a bounded IAM user and verify effective permissions
  + Observe privilege-escalation prevention in practice
  + Clean up resources | 02/06/2026 | 02/06/2026 | [IAM Permission Boundary](https://000030.awsstudygroup.com/) | +| 4 | - Practice **AWS IAM Identity Center (SSO)**:
  + Enable IAM Identity Center and set up the Identity Store
  + Create groups and users in the Identity Store
  + Assign permission sets to groups across AWS accounts
  + Configure AWS CLI access via Identity Center
  + Apply time-based access control and Customer Managed Policies
  + Use Identity Store APIs to manage identities programmatically
  + Clean up resources | 03/06/2026 | 03/06/2026 | [IAM Identity Center](https://000012.awsstudygroup.com/) | +| 5 | - Practice **AWS Web Application Firewall (WAF)**:
  + Review WAF concepts: WebACL, Rule, Rule Group, IP Set
  + Prepare a target resource (ALB / CloudFront)
  + Create and attach a WebACL with managed and custom rules
  + Test WAF block/allow behavior
  + Clean up resources | 04/06/2026 | 04/06/2026 | [AWS WAF](https://000026.awsstudygroup.com/) | +| 6 | - Practice **Secure Hybrid Access to S3 using VPC Endpoints**:
  + Understand Gateway vs. Interface VPC Endpoints
  + Create a Gateway VPC Endpoint for S3 and update route tables
  + Create an Interface VPC Endpoint for S3 (PrivateLink)
  + Access S3 from on-premises via the Interface Endpoint
  + Configure VPC Endpoint Policies to restrict access (Bonus)
  + Clean up resources | 05/06/2026 | 05/06/2026 | [VPC Endpoints for S3](https://000111.awsstudygroup.com/) | +| 7 | - Practice **AWS Security Hub**:
  + Review security standards (AWS FSBP, CIS, PCI DSS)
  + Enable Security Hub and linked integrations
  + Analyze security score and findings by standard
  + Understand aggregation from GuardDuty, Inspector, Macie
  + Clean up resources | 06/06/2026 | 06/06/2026 | [AWS Security Hub](https://000018.awsstudygroup.com/) | ### Week 7 Achievements: -* Understood what AWS is and mastered the basic service groups: - * Compute - * Storage - * Networking - * Database - * ... +* Reinforced the **IAM trust model** by distinguishing Identity-based Policies, Resource-based Policies, and Trust Policies for roles, then applied `Condition` blocks (IP CIDR and `DateGreaterThan`/`DateLessThan`) to restrict when and from where a role can be assumed. + +* Created IAM Groups and scoped IAM Users for EC2 and RDS administrator personas, validated that each user can only act within their assigned service boundary, and practiced the full assume-role flow with condition evaluation. + +* Understood and applied **IAM Permission Boundaries** as a guardrail layer that caps the maximum effective permissions regardless of the identity policy attached — a key control to prevent privilege escalation in multi-team environments. + +* Observed the intersection logic: *effective permissions = Identity Policy ∩ Permission Boundary*, and used this pattern to safely delegate permission management to developers without risking over-privilege. + +* Set up **AWS IAM Identity Center** (formerly AWS SSO) to provide centralized, federated access to multiple AWS accounts from a single identity source, eliminating per-account IAM user management. + +* Configured permission sets mapped to Identity Store groups and assigned them to AWS accounts, then accessed the accounts via AWS CLI using Identity Center credentials — practicing Zero Trust principles at the organizational level. + +* Applied **time-based access control** in Identity Center and managed identities programmatically through the **Identity Store APIs**, understanding how these capabilities support automated on-boarding and off-boarding workflows. + +* Learned the core **AWS WAF** components — WebACL, Rules, Rule Groups, IP Sets, and Managed Rule Groups — and understood how WAF integrates with CloudFront, ALB, API Gateway, and AppSync as a Layer 7 defense. + +* Created a WebACL with both AWS Managed Rules and a custom rate-limiting rule, attached it to a target resource, and confirmed block/allow behavior by sending test requests. -* Successfully created and configured an AWS Free Tier account. +* Understood the two types of **VPC Endpoints**: Gateway Endpoints (route-table-based, for S3 and DynamoDB, no extra cost) and Interface Endpoints (ENI-based, DNS-resolved, for PrivateLink services). -* Became familiar with the AWS Management Console and learned how to find, access, and use services via the web interface. +* Created a **Gateway VPC Endpoint** for S3, updated the associated route table, and verified that traffic from EC2 instances no longer traverses the public internet when accessing S3. -* Installed and configured AWS CLI on the computer, including: - * Access Key - * Secret Key - * Default Region - * ... +* Created an **Interface VPC Endpoint** (PrivateLink) for S3 and configured it to accept connections from an on-premises environment, understanding how private DNS and security groups control access. -* Used AWS CLI to perform basic operations such as: +* Configured **VPC Endpoint Policies** to grant fine-grained, resource-level access control on top of IAM — a defense-in-depth layer that limits which S3 buckets can be accessed through a given endpoint. - * Check account & configuration information - * Retrieve the list of regions - * View EC2 service - * Create and manage key pairs - * Check information about running services - * ... +* Enabled **AWS Security Hub** and reviewed the aggregated findings dashboard, understanding how it pulls findings from GuardDuty, Inspector, Macie, and other sources into a single prioritized view aligned to standards such as AWS FSBP and CIS Benchmarks. -* Acquired the ability to connect between the web interface and CLI to manage AWS resources in parallel. -* ... +* Consistently applied **cleanup discipline** across all labs to prevent unexpected charges and maintain a tidy practice account. diff --git a/content/1-Worklog/1.7-Week7/_index.vi.md b/content/1-Worklog/1.7-Week7/_index.vi.md index edc789a..4173c81 100644 --- a/content/1-Worklog/1.7-Week7/_index.vi.md +++ b/content/1-Worklog/1.7-Week7/_index.vi.md @@ -5,53 +5,50 @@ weight: 1 chapter: false pre: " 1.7. " --- -{{% notice warning %}} -⚠️ **Lưu ý:** Các thông tin dưới đây chỉ nhằm mục đích tham khảo, vui lòng **không sao chép nguyên văn** cho bài báo cáo của bạn kể cả warning này. -{{% /notice %}} - ### Mục tiêu tuần 7: -* Kết nối, làm quen với các thành viên trong First Cloud Journey. -* Hiểu dịch vụ AWS cơ bản, cách dùng console & CLI. +* Đi sâu vào **AWS IAM nâng cao** — role, condition, Permission Boundary, Identity Center SSO — để áp dụng nguyên tắc least-privilege ở quy mô doanh nghiệp. +* Tìm hiểu và thực hành **bảo mật cấp mạng** với AWS WAF và VPC Endpoints (PrivateLink) nhằm bảo vệ workload khỏi internet công cộng. ### Các công việc cần triển khai trong tuần này: -| Thứ | Công việc | Ngày bắt đầu | Ngày hoàn thành | Nguồn tài liệu | -| --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | --------------- | ----------------------------------------- | -| 2 | - Làm quen với các thành viên FCJ
- Đọc và lưu ý các nội quy, quy định tại đơn vị thực tập | 11/08/2025 | 11/08/2025 | -| 3 | - Tìm hiểu AWS và các loại dịch vụ
  + Compute
  + Storage
  + Networking
  + Database
  + ...
| 12/08/2025 | 12/08/2025 | | -| 4 | - Tạo AWS Free Tier account
- Tìm hiểu AWS Console & AWS CLI
- **Thực hành:**
  + Tạo AWS account
  + Cài AWS CLI & cấu hình
  + Cách sử dụng AWS CLI | 13/08/2025 | 13/08/2025 | | -| 5 | - Tìm hiểu EC2 cơ bản:
  + Instance types
  + AMI
  + EBS
  + ...
- Các cách remote SSH vào EC2
- Tìm hiểu Elastic IP
| 14/08/2025 | 15/08/2025 | | -| 6 | - **Thực hành:**
  + Tạo EC2 instance
  + Kết nối SSH
  + Gắn EBS volume | 15/08/2025 | 15/08/2025 | | - +| Thứ | Công việc | Ngày bắt đầu | Ngày hoàn thành | Nguồn tài liệu | +| --- | --------- | ------------ | --------------- | -------------- | +| 2 | - Thực hành **IAM Role & Condition**:
  + Ôn lại các khái niệm IAM (User, Group, Role, Policy)
  + Tạo IAM Group và IAM User cho admin EC2 và RDS
  + Tạo IAM Role với `Condition` (giới hạn theo địa chỉ IP và thời gian)
  + Kiểm tra hành vi assume-role và dọn dẹp tài nguyên | 01/06/2026 | 01/06/2026 | [IAM Role & Condition](https://000044.awsstudygroup.com/) | +| 3 | - Thực hành **IAM Permission Boundary**:
  + Hiểu sự khác biệt giữa Permission Boundary và Identity-based Policy
  + Tạo restriction policy và áp dụng làm Permission Boundary
  + Tạo IAM User bị giới hạn và kiểm tra effective permissions
  + Quan sát cơ chế ngăn chặn leo thang đặc quyền (privilege escalation)
  + Dọn dẹp tài nguyên | 02/06/2026 | 02/06/2026 | [IAM Permission Boundary](https://000030.awsstudygroup.com/) | +| 4 | - Thực hành **AWS IAM Identity Center (SSO)**:
  + Bật IAM Identity Center và thiết lập Identity Store
  + Tạo group và user trong Identity Store
  + Gán permission set cho group trên nhiều AWS account
  + Cấu hình AWS CLI truy cập qua Identity Center
  + Áp dụng time-based access control và Customer Managed Policies
  + Dùng Identity Store APIs quản lý danh tính theo chương trình
  + Dọn dẹp tài nguyên | 03/06/2026 | 03/06/2026 | [IAM Identity Center](https://000012.awsstudygroup.com/) | +| 5 | - Thực hành **AWS Web Application Firewall (WAF)**:
  + Ôn lại các khái niệm WAF: WebACL, Rule, Rule Group, IP Set
  + Chuẩn bị tài nguyên đích (ALB / CloudFront)
  + Tạo và gắn WebACL với managed rule và custom rule
  + Kiểm tra hành vi block/allow của WAF
  + Dọn dẹp tài nguyên | 04/06/2026 | 04/06/2026 | [AWS WAF](https://000026.awsstudygroup.com/) | +| 6 | - Thực hành **Truy cập S3 an toàn qua VPC Endpoints**:
  + Phân biệt Gateway Endpoint và Interface Endpoint (PrivateLink)
  + Tạo Gateway VPC Endpoint cho S3 và cập nhật route table
  + Tạo Interface VPC Endpoint cho S3 (PrivateLink)
  + Truy cập S3 từ môi trường on-premises qua Interface Endpoint
  + Cấu hình VPC Endpoint Policies để kiểm soát quyền truy cập (Bonus)
  + Dọn dẹp tài nguyên | 05/06/2026 | 05/06/2026 | [VPC Endpoints cho S3](https://000111.awsstudygroup.com/) | +| 7 | - Thực hành **AWS Security Hub**:
  + Xem xét các security standard (AWS FSBP, CIS, PCI DSS)
  + Bật Security Hub và các tích hợp liên kết
  + Phân tích security score và findings theo từng standard
  + Hiểu cơ chế tổng hợp từ GuardDuty, Inspector, Macie
  + Dọn dẹp tài nguyên | 06/06/2026 | 06/06/2026 | [AWS Security Hub](https://000018.awsstudygroup.com/) | ### Kết quả đạt được tuần 7: -* Hiểu AWS là gì và nắm được các nhóm dịch vụ cơ bản: - * Compute - * Storage - * Networking - * Database - * ... +* Củng cố **mô hình tin cậy IAM** bằng cách phân biệt rõ Identity-based Policy, Resource-based Policy và Trust Policy của role; áp dụng `Condition` block (giới hạn IP CIDR và khoảng thời gian `DateGreaterThan`/`DateLessThan`) để kiểm soát điều kiện assume-role. + +* Tạo IAM Group và IAM User cho từng persona (EC2 admin, RDS admin), xác minh mỗi người chỉ thao tác được trong phạm vi dịch vụ được phân công, và thực hành toàn bộ luồng assume-role cùng với quá trình đánh giá condition. + +* Hiểu và áp dụng **IAM Permission Boundary** như một lớp kiểm soát trần — giới hạn quyền tối đa cho user/role bất kể identity policy được gán là gì — đây là biện pháp chủ chốt để ngăn leo thang đặc quyền trong môi trường nhiều nhóm. + +* Quan sát công thức giao quyền: *effective permissions = Identity Policy ∩ Permission Boundary*, và vận dụng mô hình này để ủy quyền quản lý IAM cho developer mà không lo rủi ro cấp quyền thừa. + +* Thiết lập **AWS IAM Identity Center** (trước là AWS SSO) để cấp quyền truy cập liên kết tập trung vào nhiều AWS account từ một nguồn định danh duy nhất, loại bỏ việc phải tạo IAM user riêng trên từng account. + +* Cấu hình permission set ánh xạ với group trong Identity Store, gán cho AWS account và truy cập qua AWS CLI bằng thông tin xác thực Identity Center — thực hành nguyên tắc Zero Trust ở cấp độ tổ chức. + +* Áp dụng **time-based access control** trong Identity Center và quản lý danh tính theo chương trình qua **Identity Store APIs**, hiểu cách các khả năng này hỗ trợ luồng onboarding/offboarding tự động. + +* Học các thành phần cốt lõi của **AWS WAF** — WebACL, Rule, Rule Group, IP Set, Managed Rule Group — và hiểu cách WAF tích hợp với CloudFront, ALB, API Gateway, AppSync như một lớp phòng thủ tầng 7 (Layer 7). + +* Tạo WebACL với AWS Managed Rules và custom rate-limiting rule, gắn vào tài nguyên đích, xác nhận hành vi block/allow bằng cách gửi request kiểm thử. -* Đã tạo và cấu hình AWS Free Tier account thành công. +* Phân biệt rõ hai loại **VPC Endpoint**: Gateway Endpoint (dựa trên route table, dành cho S3 và DynamoDB, không phát sinh chi phí thêm) và Interface Endpoint (dựa trên ENI, phân giải qua DNS, dành cho dịch vụ PrivateLink). -* Làm quen với AWS Management Console và biết cách tìm, truy cập, sử dụng dịch vụ từ giao diện web. +* Tạo **Gateway VPC Endpoint** cho S3, cập nhật route table liên kết và xác nhận traffic từ EC2 instance không còn đi qua internet công cộng khi truy cập S3. -* Cài đặt và cấu hình AWS CLI trên máy tính bao gồm: - * Access Key - * Secret Key - * Region mặc định - * ... +* Tạo **Interface VPC Endpoint** (PrivateLink) cho S3 và cấu hình để chấp nhận kết nối từ môi trường on-premises, hiểu cách private DNS và security group kiểm soát quyền truy cập. -* Sử dụng AWS CLI để thực hiện các thao tác cơ bản như: +* Cấu hình **VPC Endpoint Policies** để kiểm soát quyền truy cập chi tiết ở cấp resource — lớp phòng thủ theo chiều sâu (defense-in-depth) giới hạn bucket S3 nào có thể được truy cập qua endpoint. - * Kiểm tra thông tin tài khoản & cấu hình - * Lấy danh sách region - * Xem dịch vụ EC2 - * Tạo và quản lý key pair - * Kiểm tra thông tin dịch vụ đang chạy - * ... +* Bật **AWS Security Hub** và xem dashboard tổng hợp findings, hiểu cách Security Hub kéo findings từ GuardDuty, Inspector, Macie và các nguồn khác vào một giao diện được ưu tiên theo các standard như AWS FSBP và CIS Benchmarks. -* Có khả năng kết nối giữa giao diện web và CLI để quản lý tài nguyên AWS song song. -* ... +* Duy trì **kỷ luật clean-up** sau mỗi lab để tránh phát sinh chi phí không mong muốn và giữ tài khoản thực hành gọn gàng. diff --git a/content/1-Worklog/1.8-Week8/_index.md b/content/1-Worklog/1.8-Week8/_index.md index 9f6aa0b..5b76709 100644 --- a/content/1-Worklog/1.8-Week8/_index.md +++ b/content/1-Worklog/1.8-Week8/_index.md @@ -5,53 +5,71 @@ weight: 1 chapter: false pre: " 1.8. " --- -{{% notice warning %}} + ### Week 8 Objectives: -* Connect and get acquainted with members of First Cloud Journey. -* Understand basic AWS services, how to use the console & CLI. +* Study the business problem and MVP scope for **DocuFlow AI** - a serverless intelligent invoice and receipt processing platform on AWS. +* Identify the required AWS services, operating cost, technical risks, and high-level solution architecture. +* Prepare the initial project proposal as the baseline for the workshop and module ownership. ### Tasks to be carried out this week: -| Day | Task | Start Date | Completion Date | Reference Material | -| --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- | --------------- | ----------------------------------------- | -| 2 | - Get acquainted with FCJ members
- Read and take note of internship unit rules and regulations | 08/11/2025 | 08/11/2025 | -| 3 | - Learn about AWS and its types of services
  + Compute
  + Storage
  + Networking
  + Database
  + ...
| 08/12/2025 | 08/12/2025 | | -| 4 | - Create AWS Free Tier account
- Learn about AWS Console & AWS CLI
- **Practice:**
  + Create AWS account
  + Install & configure AWS CLI
  + How to use AWS CLI | 08/13/2025 | 08/13/2025 | | -| 5 | - Learn basic EC2:
  + Instance types
  + AMI
  + EBS
  + ...
- SSH connection methods to EC2
- Learn about Elastic IP
| 08/14/2025 | 08/15/2025 | | -| 6 | - **Practice:**
  + Launch an EC2 instance
  + Connect via SSH
  + Attach an EBS volume | 08/15/2025 | 08/15/2025 | | +| Day | Task | Start Date | Completion Date | Reference Material | +| --- | ---- | ---------- | --------------- | ------------------ | +| 2 | - Study the **DocuFlow AI** project overview
  + Identify the pain points of manual invoice and receipt data entry
  + Lock the MVP scope around invoice/receipt processing
  + Identify user roles: EndUser, Reviewer, Admin | 06/08/2026 | 06/08/2026 | [Amazon Textract - Invoices and Receipts](https://docs.aws.amazon.com/textract/latest/dg/invoices-receipts.html) | +| 3 | - Study AWS services required for the project
  + Cognito, API Gateway, Lambda, S3
  + EventBridge, SQS, Step Functions
  + Textract, Bedrock, DynamoDB
  + CloudWatch, SNS/SES, IAM/KMS | 06/09/2026 | 06/09/2026 | [Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html)
[API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
[Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
[S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)
[Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
[Textract](https://docs.aws.amazon.com/textract/latest/dg/what-is.html)
[Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) | +| 4 | - Analyze project cost
  + Identify services billed by request, page, or token
  + Review cost drivers for Textract, Bedrock, Step Functions, S3, Lambda, and CloudWatch
  + Propose demo file limits, budget alerts, and cleanup after the workshop | 06/10/2026 | 06/10/2026 | [AWS Pricing Calculator](https://calculator.aws/)
[Textract Pricing](https://aws.amazon.com/textract/pricing/)
[Bedrock Pricing](https://aws.amazon.com/bedrock/pricing/)
[Step Functions Pricing](https://aws.amazon.com/step-functions/pricing/)
[AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) | +| 5 | - Analyze project risks
  + Oversized scope if the system targets all business document types
  + Textract extraction errors for low-quality documents
  + Bedrock returning JSON that does not match the schema
  + Overly broad IAM or unexpected AI service cost | 06/11/2026 | 06/11/2026 | [Textract AnalyzeExpense](https://docs.aws.amazon.com/textract/latest/dg/analyzing-document-expense.html)
[Bedrock User Guide](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html)
[IAM Security Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
[AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) | +| 6 | - Draw the solution architecture
  + Design the upload flow with presigned URL and S3 raw bucket
  + Design the EventBridge, SQS, Step Functions, Textract, and Bedrock workflow
  + Define the metadata path to DynamoDB and processed output path to S3 | 06/12/2026 | 06/12/2026 | [S3 Presigned URL Upload](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html)
[S3 EventBridge Notifications](https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventBridge.html)
[SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
[Step Functions Workflow Type](https://docs.aws.amazon.com/step-functions/latest/dg/choosing-workflow-type.html)
[DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) | +| 7 | - Prepare the project proposal
  + Write the executive summary, problem statement, MVP scope, and success criteria
  + Document the architecture, service selection, workflow, risks, and cost control
  + Split the project into five modules and define deliverables | 06/13/2026 | 06/13/2026 | [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)
[Serverless Lens](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html)
[CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
[SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) | ### Week 8 Achievements: -* Understood what AWS is and mastered the basic service groups: - * Compute - * Storage - * Networking - * Database - * ... +* Understood the business problem of **DocuFlow AI**: reducing manual data entry for invoices and receipts, improving status tracking, normalizing extracted data, and supporting auditability for Finance/Ops teams. -* Successfully created and configured an AWS Free Tier account. +* Locked the MVP scope to a workshop-friendly end-to-end flow: + * Users authenticate with Cognito. + * Users upload PDF/JPG/PNG files through the frontend and a presigned URL. + * The S3 raw bucket triggers an asynchronous processing workflow. + * Textract extracts invoice/receipt data. + * Bedrock normalizes, classifies, and returns output using a shared JSON schema. + * DynamoDB stores metadata/status, and S3 processed stores JSON/CSV results. + * CloudWatch and SNS/SES notify failures or low-confidence documents. -* Became familiar with the AWS Management Console and learned how to find, access, and use services via the web interface. +* Identified the main AWS services and their roles in the serverless, event-driven architecture: + * **Cognito** for EndUser, Reviewer, and Admin authentication/authorization. + * **API Gateway + Lambda** for presigned URL creation, status updates, and lightweight backend logic. + * **S3** for raw documents and processed results. + * **EventBridge + SQS + Step Functions** for asynchronous processing, retry, and execution audit. + * **Textract + Bedrock** for extraction, normalization, classification, and schema-based output. + * **DynamoDB** for the status table and metadata. + * **CloudWatch + SNS/SES** for logs, metrics, alarms, and notifications. + * **IAM/KMS** for least privilege and data encryption. -* Installed and configured AWS CLI on the computer, including: - * Access Key - * Secret Key - * Default Region - * ... +* Analyzed cost and proposed control measures: + * Limit the demo to 5-10 small invoice/receipt files. + * Track services billed by request, page, or token, especially Textract, Bedrock, and Step Functions. + * Query only the processed demo folder when using Athena to avoid unnecessary scan cost. + * Configure S3 lifecycle policies for raw/processed data and prepare cleanup/destroy commands after the demo. + * Set up budget alerts to catch unexpected cost. -* Used AWS CLI to perform basic operations such as: +* Built the initial risk matrix and mitigation plan: + * Oversized scope: keep the MVP focused on invoice/receipt processing and move contracts, purchase orders, email ingestion, and advanced QuickSight dashboards to extensions. + * OCR errors on low-quality documents: use confidence scores, a REVIEW_REQUIRED threshold, and a manual review loop. + * Bedrock schema mismatch: define strict prompts/schema, validate output with Lambda, and add retry/fallback behavior. + * Overly broad IAM: create module-specific roles, apply least privilege, and avoid hard-coded access keys. + * Unexpected AI cost: limit demo files, enable budget alerts, and clean up resources after the workshop. - * Check account & configuration information - * Retrieve the list of regions - * View EC2 service - * Create and manage key pairs - * Check information about running services - * ... +* Completed the first end-to-end architecture draft for DocuFlow AI, covering client/access, ingestion/workflow, AI processing, storage, analytics, observability, and DevOps/IaC layers. -* Acquired the ability to connect between the web interface and CLI to manage AWS resources in parallel. -* ... +* Completed the initial project proposal with the following sections: + * Executive summary and problem statement. + * MVP scope, out-of-scope items, and success criteria. + * Solution architecture and service selection. + * End-to-end workflow. + * Data contract, status model, and five-person module ownership. + * Security baseline, observability, analytics, cost control, risk mitigation, and definition of done. diff --git a/content/1-Worklog/1.8-Week8/_index.vi.md b/content/1-Worklog/1.8-Week8/_index.vi.md index ef21245..0a0a0bb 100644 --- a/content/1-Worklog/1.8-Week8/_index.vi.md +++ b/content/1-Worklog/1.8-Week8/_index.vi.md @@ -5,53 +5,71 @@ weight: 1 chapter: false pre: " 1.8. " --- -{{% notice warning %}} + ### Mục tiêu tuần 8: -* Kết nối, làm quen với các thành viên trong First Cloud Journey. -* Hiểu dịch vụ AWS cơ bản, cách dùng console & CLI. +* Tìm hiểu bài toán và phạm vi MVP cho dự án **DocuFlow AI** - nền tảng xử lý invoice/receipt thông minh trên AWS. +* Xác định các dịch vụ AWS phù hợp, chi phí vận hành, rủi ro kỹ thuật và kiến trúc tổng thể cho dự án. +* Hoàn thiện proposal ban đầu để làm cơ sở triển khai workshop và chia module cho nhóm. ### Các công việc cần triển khai trong tuần này: -| Thứ | Công việc | Ngày bắt đầu | Ngày hoàn thành | Nguồn tài liệu | -| --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | --------------- | ----------------------------------------- | -| 2 | - Làm quen với các thành viên FCJ
- Đọc và lưu ý các nội quy, quy định tại đơn vị thực tập | 11/08/2025 | 11/08/2025 | -| 3 | - Tìm hiểu AWS và các loại dịch vụ
  + Compute
  + Storage
  + Networking
  + Database
  + ...
| 12/08/2025 | 12/08/2025 | | -| 4 | - Tạo AWS Free Tier account
- Tìm hiểu AWS Console & AWS CLI
- **Thực hành:**
  + Tạo AWS account
  + Cài AWS CLI & cấu hình
  + Cách sử dụng AWS CLI | 13/08/2025 | 13/08/2025 | | -| 5 | - Tìm hiểu EC2 cơ bản:
  + Instance types
  + AMI
  + EBS
  + ...
- Các cách remote SSH vào EC2
- Tìm hiểu Elastic IP
| 14/08/2025 | 15/08/2025 | | -| 6 | - **Thực hành:**
  + Tạo EC2 instance
  + Kết nối SSH
  + Gắn EBS volume | 15/08/2025 | 15/08/2025 | | +| Thứ | Công việc | Ngày bắt đầu | Ngày hoàn thành | Nguồn tài liệu | +| --- | --------- | ------------ | --------------- | -------------- | +| 2 | - Tìm hiểu tổng quan dự án **DocuFlow AI**
  + Xác định pain point nhập liệu hóa đơn/biên nhận thủ công
  + Chốt phạm vi MVP tập trung vào invoice/receipt processing
  + Ghi nhận các đối tượng người dùng: EndUser, Reviewer, Admin | 08/06/2026 | 08/06/2026 | [Amazon Textract - Invoices and Receipts](https://docs.aws.amazon.com/textract/latest/dg/invoices-receipts.html) | +| 3 | - Tìm hiểu các dịch vụ AWS cần dùng cho dự án
  + Cognito, API Gateway, Lambda, S3
  + EventBridge, SQS, Step Functions
  + Textract, Bedrock, DynamoDB
  + CloudWatch, SNS/SES, IAM/KMS | 09/06/2026 | 09/06/2026 | [Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html)
[API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)
[Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
[S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)
[Step Functions](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
[Textract](https://docs.aws.amazon.com/textract/latest/dg/what-is.html)
[Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) | +| 4 | - Phân tích chi phí cho dự án
  + Xác định các dịch vụ tính phí theo request/trang/token
  + Đánh giá chi phí Textract, Bedrock, Step Functions, S3, Lambda và CloudWatch
  + Đề xuất giới hạn file demo, budget alert và cleanup sau workshop | 10/06/2026 | 10/06/2026 | [AWS Pricing Calculator](https://calculator.aws/)
[Textract Pricing](https://aws.amazon.com/textract/pricing/)
[Bedrock Pricing](https://aws.amazon.com/bedrock/pricing/)
[Step Functions Pricing](https://aws.amazon.com/step-functions/pricing/)
[AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) | +| 5 | - Phân tích rủi ro cho dự án
  + Scope quá rộng nếu xử lý mọi loại tài liệu
  + Textract đọc sai chứng từ chất lượng thấp
  + Bedrock trả JSON sai schema
  + IAM quá rộng hoặc chi phí AI vượt dự kiến | 11/06/2026 | 11/06/2026 | [Textract AnalyzeExpense](https://docs.aws.amazon.com/textract/latest/dg/analyzing-document-expense.html)
[Bedrock User Guide](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html)
[IAM Security Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
[AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) | +| 6 | - Vẽ kiến trúc giải pháp
  + Thiết kế luồng upload qua presigned URL vào S3 raw bucket
  + Thiết kế workflow EventBridge, SQS, Step Functions, Textract và Bedrock
  + Xác định luồng lưu metadata vào DynamoDB và kết quả vào S3 processed | 12/06/2026 | 12/06/2026 | [S3 Presigned URL Upload](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html)
[S3 EventBridge Notifications](https://docs.aws.amazon.com/AmazonS3/latest/userguide/EventBridge.html)
[SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
[Step Functions Workflow Type](https://docs.aws.amazon.com/step-functions/latest/dg/choosing-workflow-type.html)
[DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) | +| 7 | - Làm proposal cho dự án
  + Viết executive summary, problem statement, MVP scope, success criteria
  + Mô tả architecture, service selection, workflow, risk và cost control
  + Chia module cho nhóm 5 người và định nghĩa deliverable | 13/06/2026 | 13/06/2026 | [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)
[Serverless Lens](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html)
[CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
[SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) | ### Kết quả đạt được tuần 8: -* Hiểu AWS là gì và nắm được các nhóm dịch vụ cơ bản: - * Compute - * Storage - * Networking - * Database - * ... +* Nắm được bài toán nghiệp vụ của **DocuFlow AI**: giảm nhập liệu thủ công cho invoice/receipt, tăng khả năng theo dõi trạng thái, chuẩn hóa dữ liệu và hỗ trợ audit cho đội Finance/Ops. -* Đã tạo và cấu hình AWS Free Tier account thành công. +* Chốt phạm vi MVP ở mức phù hợp với workshop: + * Người dùng đăng nhập bằng Cognito. + * Upload PDF/JPG/PNG qua frontend và presigned URL. + * S3 raw bucket kích hoạt workflow xử lý bất đồng bộ. + * Textract trích xuất dữ liệu chứng từ. + * Bedrock chuẩn hóa, phân loại và trả output theo JSON schema. + * DynamoDB lưu metadata/status, S3 processed lưu kết quả JSON/CSV. + * CloudWatch và SNS/SES cảnh báo lỗi hoặc confidence thấp. -* Làm quen với AWS Management Console và biết cách tìm, truy cập, sử dụng dịch vụ từ giao diện web. +* Xác định danh sách dịch vụ AWS chính và vai trò của từng dịch vụ trong kiến trúc serverless, event-driven: + * **Cognito** cho xác thực và phân quyền EndUser/Reviewer/Admin. + * **API Gateway + Lambda** cho API tạo presigned URL, cập nhật trạng thái và xử lý logic nhẹ. + * **S3** cho raw document và processed result. + * **EventBridge + SQS + Step Functions** cho luồng xử lý bất đồng bộ, retry và audit execution. + * **Textract + Bedrock** cho extraction, normalization, classification và schema output. + * **DynamoDB** cho status table và metadata. + * **CloudWatch + SNS/SES** cho log, metric, alarm và notification. + * **IAM/KMS** cho least privilege và mã hóa dữ liệu. -* Cài đặt và cấu hình AWS CLI trên máy tính bao gồm: - * Access Key - * Secret Key - * Region mặc định - * ... +* Phân tích chi phí và đề xuất các biện pháp kiểm soát: + * Giới hạn demo ở 5-10 file invoice/receipt kích thước nhỏ. + * Theo dõi các dịch vụ tính phí theo request, trang hoặc token như Textract, Bedrock và Step Functions. + * Chỉ query dữ liệu processed khi dùng Athena để tránh tăng chi phí scan. + * Đặt lifecycle policy cho S3 raw/processed và chuẩn bị lệnh cleanup/destroy sau demo. + * Thiết lập budget alert để phát hiện chi phí bất thường. -* Sử dụng AWS CLI để thực hiện các thao tác cơ bản như: +* Lập ma trận rủi ro chính và hướng giảm thiểu: + * Scope quá rộng: khóa MVP vào invoice/receipt, đưa contract, purchase order, email ingestion, QuickSight nâng cao thành extension. + * OCR sai với chứng từ chất lượng thấp: dùng confidence score, ngưỡng REVIEW_REQUIRED và manual review loop. + * Bedrock trả JSON sai schema: thiết kế prompt/schema rõ ràng, Lambda validate schema và retry/fallback. + * IAM quá rộng: tách role theo module, áp dụng least privilege, không hard-code access key. + * Chi phí AI vượt dự kiến: giới hạn file demo, bật cảnh báo ngân sách và cleanup sau workshop. - * Kiểm tra thông tin tài khoản & cấu hình - * Lấy danh sách region - * Xem dịch vụ EC2 - * Tạo và quản lý key pair - * Kiểm tra thông tin dịch vụ đang chạy - * ... +* Hoàn thành bản phác thảo kiến trúc end-to-end cho DocuFlow AI, gồm các lớp client/access, ingestion/workflow, AI processing, storage, analytics, observability và DevOps/IaC. -* Có khả năng kết nối giữa giao diện web và CLI để quản lý tài nguyên AWS song song. -* ... +* Hoàn thành proposal ban đầu cho dự án với các nội dung chính: + * Executive summary và problem statement. + * MVP scope, out-of-scope và success criteria. + * Solution architecture và service selection. + * End-to-end workflow. + * Data contract, status model và phân chia module cho nhóm 5 người. + * Security baseline, observability, analytics, cost control, risk mitigation và definition of done. diff --git a/content/1-Worklog/1.9-Week9/_index.md b/content/1-Worklog/1.9-Week9/_index.md index a375206..c86e9dd 100644 --- a/content/1-Worklog/1.9-Week9/_index.md +++ b/content/1-Worklog/1.9-Week9/_index.md @@ -5,53 +5,54 @@ weight: 1 chapter: false pre: " 1.9. " --- -{{% notice warning %}} + ### Week 9 Objectives: -* Connect and get acquainted with members of First Cloud Journey. -* Understand basic AWS services, how to use the console & CLI. +* Stand up the **DocuFlow AI** project foundation as the baseline for all later modules. +* Build the identity, storage, and upload layers: Cognito, S3 buckets, DynamoDB, API Gateway, and the upload Lambda. +* Deliver a working secure upload flow from the frontend to the S3 raw bucket via presigned URL. ### Tasks to be carried out this week: -| Day | Task | Start Date | Completion Date | Reference Material | -| --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- | --------------- | ----------------------------------------- | -| 2 | - Get acquainted with FCJ members
- Read and take note of internship unit rules and regulations | 08/11/2025 | 08/11/2025 | -| 3 | - Learn about AWS and its types of services
  + Compute
  + Storage
  + Networking
  + Database
  + ...
| 08/12/2025 | 08/12/2025 | | -| 4 | - Create AWS Free Tier account
- Learn about AWS Console & AWS CLI
- **Practice:**
  + Create AWS account
  + Install & configure AWS CLI
  + How to use AWS CLI | 08/13/2025 | 08/13/2025 | | -| 5 | - Learn basic EC2:
  + Instance types
  + AMI
  + EBS
  + ...
- SSH connection methods to EC2
- Learn about Elastic IP
| 08/14/2025 | 08/15/2025 | | -| 6 | - **Practice:**
  + Launch an EC2 instance
  + Connect via SSH
  + Attach an EBS volume | 08/15/2025 | 08/15/2025 | | +| Day | Task | Start Date | Completion Date | Reference Material | +| --- | ---- | ---------- | --------------- | ------------------ | +| 2 | - Set up the project foundation
  + Initialize the `docuflow-ai` monorepo (pnpm workspaces)
  + Scaffold the AWS SAM root template and `samconfig.toml`
  + Configure ESLint/Prettier and shared `tsconfig` | 06/15/2026 | 06/15/2026 | [AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html)
[pnpm workspaces](https://pnpm.io/workspaces) | +| 3 | - Build the identity layer
  + Create the Cognito User Pool with `end-user`, `reviewer`, `admin` groups
  + Configure the app client and hosted sign-in
  + Wire the Cognito authorizer for API Gateway | 06/16/2026 | 06/16/2026 | [Cognito User Pools](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html)
[API Gateway Cognito Authorizer](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html) | +| 4 | - Build the storage layer
  + Create `docuflow-raw` and `docuflow-processed` S3 buckets (Block Public Access, SSE-KMS)
  + Create the DynamoDB `Documents` table (PK `documentId`, GSI on `userId`+`status`)
  + Apply S3 lifecycle rules | 06/17/2026 | 06/17/2026 | [S3 Block Public Access](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html)
[DynamoDB Secondary Indexes](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html) | +| 5 | - Build the upload API
  + Create the API Gateway REST API and `POST /uploads` route
  + Implement the `presignUpload` Lambda (Node.js 20.x)
  + Generate short-lived presigned URLs and write the `UPLOADED` item to DynamoDB | 06/18/2026 | 06/18/2026 | [S3 Presigned URL Upload](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html)
[Lambda Node.js](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html) | +| 6 | - Build frontend hosting and auth
  + Scaffold the React + Vite SPA
  + Host the build in a private S3 bucket served via CloudFront with Origin Access Control
  + Implement Cognito login and the upload page | 06/19/2026 | 06/19/2026 | [CloudFront Origin Access Control](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html)
[amazon-cognito-identity-js](https://www.npmjs.com/package/amazon-cognito-identity-js) | +| 7 | - Integrate and verify the upload flow
  + Connect frontend → `POST /uploads` → presigned URL → S3 PUT
  + Confirm the `UPLOADED` status in DynamoDB
  + Deploy the consolidated SAM stack and capture evidence | 06/20/2026 | 06/20/2026 | [SAM CLI Deploy](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-deploy.html) | ### Week 9 Achievements: -* Understood what AWS is and mastered the basic service groups: - * Compute - * Storage - * Networking - * Database - * ... - -* Successfully created and configured an AWS Free Tier account. - -* Became familiar with the AWS Management Console and learned how to find, access, and use services via the web interface. - -* Installed and configured AWS CLI on the computer, including: - * Access Key - * Secret Key - * Default Region - * ... - -* Used AWS CLI to perform basic operations such as: - - * Check account & configuration information - * Retrieve the list of regions - * View EC2 service - * Create and manage key pairs - * Check information about running services - * ... - -* Acquired the ability to connect between the web interface and CLI to manage AWS resources in parallel. -* ... +* Stood up the **DocuFlow AI** project foundation: + * Initialized the `docuflow-ai` monorepo with pnpm workspaces (`apps/`, `packages/`, `services/`, `infrastructure/`). + * Scaffolded the AWS SAM root template with one stack per environment for repeatable deploy and clean teardown. + * Configured shared ESLint, Prettier, and `tsconfig` across the workspace. + +* Built the identity layer with Amazon Cognito: + * Created the User Pool with `end-user`, `reviewer`, and `admin` groups. + * Configured the app client and sign-in flow. + * Wired the Cognito User Pool authorizer to protect API Gateway endpoints. + +* Built the storage layer: + * Created the `docuflow-raw` bucket (Block Public Access, SSE-KMS, 60-day expiry) and the `docuflow-processed` bucket (versioning, STANDARD-IA after 30 days). + * Created the on-demand DynamoDB `Documents` table with PK `documentId` and a GSI on `userId`+`status` for the user dashboard. + +* Built the secure upload API: + * Created the API Gateway REST API with the `POST /uploads` route behind the Cognito authorizer. + * Implemented the `presignUpload` Lambda (Node.js 20.x, 256 MB) that generates a `documentId`, writes the `UPLOADED` item to DynamoDB, and returns a short-lived presigned URL scoped to `docuflow-raw/{userId}/{documentId}.{ext}`. + +* Built the frontend hosting and auth: + * Scaffolded the React 18 + Vite + TypeScript SPA. + * Hosted the build in a private S3 bucket served through CloudFront with Origin Access Control over HTTPS. + * Implemented Cognito login and the file upload page. + +* Verified the end-to-end upload flow: + * Frontend requests an upload slot, receives a presigned URL, and PUTs the file directly to S3 without the bytes passing through API Gateway or Lambda. + * Confirmed the `UPLOADED` status is recorded in DynamoDB. + * Deployed the consolidated SAM stack and captured screenshots as evidence. diff --git a/content/1-Worklog/1.9-Week9/_index.vi.md b/content/1-Worklog/1.9-Week9/_index.vi.md index 045c68a..b3c47f2 100644 --- a/content/1-Worklog/1.9-Week9/_index.vi.md +++ b/content/1-Worklog/1.9-Week9/_index.vi.md @@ -5,53 +5,54 @@ weight: 1 chapter: false pre: " 1.9. " --- -{{% notice warning %}} + ### Mục tiêu tuần 9: -* Kết nối, làm quen với các thành viên trong First Cloud Journey. -* Hiểu dịch vụ AWS cơ bản, cách dùng console & CLI. +* Dựng nền tảng dự án **DocuFlow AI** làm baseline cho các module sau. +* Xây các layer identity, storage và upload: Cognito, S3 buckets, DynamoDB, API Gateway và Lambda upload. +* Hoàn thành luồng upload an toàn từ frontend lên S3 raw bucket qua presigned URL. ### Các công việc cần triển khai trong tuần này: -| Thứ | Công việc | Ngày bắt đầu | Ngày hoàn thành | Nguồn tài liệu | -| --- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | --------------- | ----------------------------------------- | -| 2 | - Làm quen với các thành viên FCJ
- Đọc và lưu ý các nội quy, quy định tại đơn vị thực tập | 11/08/2025 | 11/08/2025 | -| 3 | - Tìm hiểu AWS và các loại dịch vụ
  + Compute
  + Storage
  + Networking
  + Database
  + ...
| 12/08/2025 | 12/08/2025 | | -| 4 | - Tạo AWS Free Tier account
- Tìm hiểu AWS Console & AWS CLI
- **Thực hành:**
  + Tạo AWS account
  + Cài AWS CLI & cấu hình
  + Cách sử dụng AWS CLI | 13/08/2025 | 13/08/2025 | | -| 5 | - Tìm hiểu EC2 cơ bản:
  + Instance types
  + AMI
  + EBS
  + ...
- Các cách remote SSH vào EC2
- Tìm hiểu Elastic IP
| 14/08/2025 | 15/08/2025 | | -| 6 | - **Thực hành:**
  + Tạo EC2 instance
  + Kết nối SSH
  + Gắn EBS volume | 15/08/2025 | 15/08/2025 | | +| Thứ | Công việc | Ngày bắt đầu | Ngày hoàn thành | Nguồn tài liệu | +| --- | --------- | ------------ | --------------- | -------------- | +| 2 | - Thiết lập nền tảng dự án
  + Khởi tạo monorepo `docuflow-ai` (pnpm workspaces)
  + Dựng SAM root template và `samconfig.toml`
  + Cấu hình ESLint/Prettier và `tsconfig` dùng chung | 15/06/2026 | 15/06/2026 | [AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html)
[pnpm workspaces](https://pnpm.io/workspaces) | +| 3 | - Xây layer identity
  + Tạo Cognito User Pool với groups `end-user`, `reviewer`, `admin`
  + Cấu hình app client và hosted sign-in
  + Gắn Cognito authorizer cho API Gateway | 16/06/2026 | 16/06/2026 | [Cognito User Pools](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html)
[API Gateway Cognito Authorizer](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html) | +| 4 | - Xây layer storage
  + Tạo S3 bucket `docuflow-raw` và `docuflow-processed` (Block Public Access, SSE-KMS)
  + Tạo DynamoDB table `Documents` (PK `documentId`, GSI trên `userId`+`status`)
  + Áp dụng S3 lifecycle rules | 17/06/2026 | 17/06/2026 | [S3 Block Public Access](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html)
[DynamoDB Secondary Indexes](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html) | +| 5 | - Xây upload API
  + Tạo API Gateway REST API và route `POST /uploads`
  + Viết Lambda `presignUpload` (Node.js 20.x)
  + Sinh presigned URL ngắn hạn và ghi item `UPLOADED` vào DynamoDB | 18/06/2026 | 18/06/2026 | [S3 Presigned URL Upload](https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html)
[Lambda Node.js](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html) | +| 6 | - Xây frontend hosting và auth
  + Dựng SPA React + Vite
  + Host build trong S3 bucket private serve qua CloudFront với Origin Access Control
  + Làm Cognito login và trang upload | 19/06/2026 | 19/06/2026 | [CloudFront Origin Access Control](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html)
[amazon-cognito-identity-js](https://www.npmjs.com/package/amazon-cognito-identity-js) | +| 7 | - Tích hợp và kiểm thử luồng upload
  + Nối frontend → `POST /uploads` → presigned URL → S3 PUT
  + Xác nhận status `UPLOADED` trong DynamoDB
  + Deploy SAM stack hợp nhất và thu thập evidence | 20/06/2026 | 20/06/2026 | [SAM CLI Deploy](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-deploy.html) | ### Kết quả đạt được tuần 9: -* Hiểu AWS là gì và nắm được các nhóm dịch vụ cơ bản: - * Compute - * Storage - * Networking - * Database - * ... - -* Đã tạo và cấu hình AWS Free Tier account thành công. - -* Làm quen với AWS Management Console và biết cách tìm, truy cập, sử dụng dịch vụ từ giao diện web. - -* Cài đặt và cấu hình AWS CLI trên máy tính bao gồm: - * Access Key - * Secret Key - * Region mặc định - * ... - -* Sử dụng AWS CLI để thực hiện các thao tác cơ bản như: - - * Kiểm tra thông tin tài khoản & cấu hình - * Lấy danh sách region - * Xem dịch vụ EC2 - * Tạo và quản lý key pair - * Kiểm tra thông tin dịch vụ đang chạy - * ... - -* Có khả năng kết nối giữa giao diện web và CLI để quản lý tài nguyên AWS song song. -* ... +* Dựng xong nền tảng dự án **DocuFlow AI**: + * Khởi tạo monorepo `docuflow-ai` với pnpm workspaces (`apps/`, `packages/`, `services/`, `infrastructure/`). + * Dựng SAM root template với một stack cho mỗi environment để deploy tái lập và teardown sạch. + * Cấu hình ESLint, Prettier và `tsconfig` dùng chung trên toàn workspace. + +* Xây layer identity với Amazon Cognito: + * Tạo User Pool với các groups `end-user`, `reviewer` và `admin`. + * Cấu hình app client và luồng sign-in. + * Gắn Cognito User Pool authorizer để bảo vệ các endpoint API Gateway. + +* Xây layer storage: + * Tạo bucket `docuflow-raw` (Block Public Access, SSE-KMS, expire sau 60 ngày) và bucket `docuflow-processed` (versioning, chuyển STANDARD-IA sau 30 ngày). + * Tạo DynamoDB table `Documents` (on-demand) với PK `documentId` và GSI trên `userId`+`status` phục vụ dashboard người dùng. + +* Xây upload API an toàn: + * Tạo API Gateway REST API với route `POST /uploads` đặt sau Cognito authorizer. + * Viết Lambda `presignUpload` (Node.js 20.x, 256 MB) sinh `documentId`, ghi item `UPLOADED` vào DynamoDB và trả presigned URL ngắn hạn theo path `docuflow-raw/{userId}/{documentId}.{ext}`. + +* Xây frontend hosting và auth: + * Dựng SPA React 18 + Vite + TypeScript. + * Host build trong S3 bucket private serve qua CloudFront với Origin Access Control trên HTTPS. + * Làm Cognito login và trang upload file. + +* Kiểm thử luồng upload end-to-end: + * Frontend xin upload slot, nhận presigned URL và PUT file trực tiếp lên S3 mà bytes không đi qua API Gateway hay Lambda. + * Xác nhận status `UPLOADED` được ghi vào DynamoDB. + * Deploy SAM stack hợp nhất và chụp screenshots làm evidence. diff --git a/content/1-Worklog/_index.md b/content/1-Worklog/_index.md index fa042ba..c2607dc 100644 --- a/content/1-Worklog/_index.md +++ b/content/1-Worklog/_index.md @@ -24,15 +24,15 @@ Typically, and as a standard, a worklog is carried out over about 3 months (thro **Week 5:** [Practicing tags, IAM least privilege, KMS encryption, Security Hub, Lambda cost optimization, and Grafana](1.5-week5/) -**Week 6:** [Doing task E...](1.6-week6/) +**Week 6:** [Practicing tags & resource groups, IAM tag-based access control, Permission Boundary, KMS encryption, Security Hub, and Lambda cost optimization](1.6-week6/) -**Week 7:** [Doing task G...](1.7-week7/) +**Week 7:** [Practicing advanced IAM (Role Condition, Permission Boundary, Identity Center) and network security (WAF, VPC Endpoints, Security Hub)](1.7-week7/) -**Week 8:** [Doing task H...](1.8-week8/) +**Week 8:** [DocuFlow AI Research and Proposal](1.8-week8/) -**Week 9:** [Doing task I...](1.9-week9/) +**Week 9:** [Building the DocuFlow AI foundation: Cognito, S3, DynamoDB, upload API, and frontend hosting](1.9-week9/) -**Week 10:** [Doing task L...](1.10-week10/) +**Week 10:** [DocuFlow AI Architecture and Documentation Revision](1.10-week10/) **Week 11:** [Doing task M...](1.11-week11/) diff --git a/content/1-Worklog/_index.vi.md b/content/1-Worklog/_index.vi.md index ac1acbc..1241d92 100644 --- a/content/1-Worklog/_index.vi.md +++ b/content/1-Worklog/_index.vi.md @@ -25,15 +25,15 @@ Thông thường và cũng là tiêu chuẩn, một worklog được thực hi **Tuần 5:** [Thực hành tags, IAM least privilege, mã hoá KMS, Security Hub, tối ưu chi phí với Lambda và Grafana](1.5-week5/) -**Tuần 6:** [Làm công việc E...](1.6-week6/) +**Tuần 6:** [Thực hành tags & resource groups, IAM tag-based access control, Permission Boundary, mã hoá KMS, Security Hub và tối ưu chi phí với Lambda](1.6-week6/) -**Tuần 7:** [Làm công việc G...](1.7-week7/) +**Tuần 7:** [Thực hành IAM nâng cao (Role Condition, Permission Boundary, Identity Center) và bảo mật mạng (WAF, VPC Endpoints, Security Hub)](1.7-week7/) -**Tuần 8:** [Làm công việc H...](1.8-week8/) +**Tuần 8:** [Nghiên cứu và Proposal DocuFlow AI](1.8-week8/) -**Tuần 9:** [Làm công việc I...](1.9-week9/) +**Tuần 9:** [Dựng nền tảng DocuFlow AI: Cognito, S3, DynamoDB, upload API và frontend hosting](1.9-week9/) -**Tuần 10:** [Làm công việc L...](1.10-week10/) +**Tuần 10:** [Điều chỉnh kiến trúc và tài liệu DocuFlow AI](1.10-week10/) **Tuần 11:** [Làm công việc M...](1.11-week11/) diff --git a/content/2-Proposal/_index.md b/content/2-Proposal/_index.md index 26fed5c..58de924 100644 --- a/content/2-Proposal/_index.md +++ b/content/2-Proposal/_index.md @@ -1,115 +1,425 @@ --- title: "Proposal" -date: 2024-01-01 +date: 2026-04-20 weight: 2 chapter: false pre: " 2. " --- -{{% notice warning %}} -⚠️ **Note:** The information below is for reference purposes only. Please **do not copy verbatim** for your report, including this warning. -{{% /notice %}} -In this section, you need to summarize the contents of the workshop that you **plan** to conduct. +# DocuFlow AI - Serverless Intelligent Invoice & Receipt Processing Platform on AWS -# IoT Weather Platform for Lab Research -## A Unified AWS Serverless Solution for Real-Time Weather Monitoring +## An AWS Serverless Solution for Intelligent Invoice and Receipt Processing ### 1. Executive Summary -The IoT Weather Platform is designed for the ITea Lab team in Ho Chi Minh City to enhance weather data collection and analysis. It supports up to 5 weather stations, with potential scalability to 10-15, utilizing Raspberry Pi edge devices with ESP32 sensors to transmit data via MQTT. The platform leverages AWS Serverless services to deliver real-time monitoring, predictive analytics, and cost efficiency, with access restricted to 5 lab members via Amazon Cognito. + +DocuFlow AI is designed for small and medium businesses that need to process invoices and receipts with less manual work. The platform allows authenticated users to upload PDF, JPG, or PNG documents, then uses AWS managed services to extract financial fields, normalize the result, store metadata, and show the processing status in a simple web interface. + +The solution uses a serverless, event-driven architecture deployed with AWS SAM in `ap-southeast-1` (Singapore). Users access the frontend through Amazon CloudFront and AWS Amplify, sign in with Amazon Cognito, and upload documents through presigned URLs. Amazon S3 stores the original files, EventBridge and SQS decouple ingestion from processing, Step Functions orchestrates the workflow, Amazon Textract extracts invoice and receipt data, an AI Proxy Lambda calls an External AI API to normalize the extracted result, a Confidence + Status Lambda determines the final status, and DynamoDB stores document status and metadata. + +The workshop is scoped for a five-person team. Each member owns one module: frontend/auth/upload, ingestion/workflow, AI extraction and validation, data/result dashboard, and observability/security/IaC. ### 2. Problem Statement -### What’s the Problem? -Current weather stations require manual data collection, becoming unmanageable with multiple units. There is no centralized system for real-time data or analytics, and third-party platforms are costly and overly complex. -### The Solution -The platform uses AWS IoT Core to ingest MQTT data, AWS Lambda and API Gateway for processing, Amazon S3 for storage (including a data lake), and AWS Glue Crawlers and ETL jobs to extract, transform, and load data from the S3 data lake to another S3 bucket for analysis. AWS Amplify with Next.js provides the web interface, and Amazon Cognito ensures secure access. Similar to Thingsboard and CoreIoT, users can register new devices and manage connections, though this platform operates on a smaller scale and is designed for private use. Key features include real-time dashboards, trend analysis, and low operational costs. +#### What's the Problem? + +Many businesses still process invoices and receipts through email, shared folders, spreadsheets, or manual data entry. This creates several issues: + +- Finance and operations teams spend repetitive time entering vendor name, invoice date, tax, total amount, and line items. +- Manual entry can introduce wrong values, missing fields, and inconsistent document formats. +- Users cannot easily know whether a document is uploaded, processing, failed, extracted, or waiting for review. +- Documents are hard to search, audit, and summarize when they are spread across inboxes and shared drives. +- Finance teams have limited visibility into spending by vendor, month, document type, or failed processing reason. +- Running always-on servers for an uneven document workload increases cost and operational work. + +#### The Solution + +DocuFlow AI centralizes document upload and processing on AWS. The frontend provides login, upload, status tracking, result viewing, and manual correction. The backend uses presigned URLs for secure upload to S3, then processes documents asynchronously with EventBridge, SQS, Lambda, and Step Functions. + +Amazon Textract extracts invoice and receipt fields. An AI Proxy Lambda sends only the minimized Textract output to the External AI API, maps inconsistent field names into a consistent schema, classifies the document as invoice or receipt, explains missing fields, and returns structured JSON. Lambda validates the schema, confidence score, and business rules before saving the result to DynamoDB and S3 processed storage. The frontend never calls the external AI API directly, and raw PDF or image files are not sent to the external AI provider unless the team explicitly approves that behavior. + +#### Benefits and Return on Investment + +DocuFlow AI reduces manual data entry and gives teams a repeatable process for handling financial documents. The system creates a searchable metadata store, provides status visibility, and supports a review loop for low-confidence documents. Because the MVP is serverless, the platform can stay low-cost for a workshop workload and scale with document volume when needed. -### Benefits and Return on Investment -The solution establishes a foundational resource for lab members to develop a larger IoT platform, serving as a study resource, and provides a data foundation for AI enthusiasts for model training or analysis. It reduces manual reporting for each station via a centralized platform, simplifying management and maintenance, and improves data reliability. Monthly costs are $0.66 USD per the AWS Pricing Calculator, with a 12-month total of $7.92 USD. All IoT equipment costs are covered by the existing weather station setup, eliminating additional development expenses. The break-even period of 6-12 months is achieved through significant time savings from reduced manual work. +The estimated AWS cost for the workshop workload is about **$3.50-$8.00 per month**, or **$42-$96 for 12 months** in `ap-southeast-1` (Singapore), depending on Textract pages, External AI API usage, CloudWatch/X-Ray volume, log retention, and alert testing. The project also provides reusable learning value for AWS serverless architecture, AI document processing, asynchronous workflows, secure secret handling, observability, governance, and cleanup. ### 3. Solution Architecture -The platform employs a serverless AWS architecture to manage data from 5 Raspberry Pi-based stations, scalable to 15. Data is ingested via AWS IoT Core, stored in an S3 data lake, and processed by AWS Glue Crawlers and ETL jobs to transform and load it into another S3 bucket for analysis. Lambda and API Gateway handle additional processing, while Amplify with Next.js hosts the dashboard, secured by Cognito. The architecture is detailed below: -![IoT Weather Station Architecture](/images/2-Proposal/edge_architecture.jpeg) +DocuFlow AI uses a serverless AWS architecture for secure upload, asynchronous processing, AI-assisted extraction, result storage, and operational monitoring. The high-level architecture is shown below: + +![DocuFlow AI high-level serverless architecture with External AI API](/images/2-Proposal/docuflow_high_level_architecture.png) + +The diagram reflects the approved architecture scope: CloudFront, Amplify, Cognito, API Gateway, Lambda, S3 Raw/Processed buckets, EventBridge, SQS with DLQ, Step Functions Standard Workflow, Textract, AI Proxy Lambda, External AI API, DynamoDB, CloudWatch, X-Ray, SNS/SES, IAM, KMS, Secrets Manager, CloudTrail, Budgets, and SAM. + +#### AWS Services Used + +The services below are grouped by architectural layer. Each row maps directly to the Budget Estimation in section 6. + +**Identity & Security** + +- Amazon Cognito: User Pool with groups (end-user, reviewer, admin), used as the Cognito User Pool authorizer for every API Gateway endpoint. +- AWS IAM: Least-privilege role per Lambda function and a dedicated Step Functions execution role; no shared admin role. +- AWS KMS: AWS-managed keys (`aws/s3`, `aws/dynamodb`, `aws/sqs`) for encryption at rest; no customer-managed keys to keep cost at $0. +- AWS Secrets Manager: Stores the External AI API key outside source code and frontend code. Lambda stores only the secret name in an environment variable. +- AWS CloudTrail: Provides audit visibility for AWS account activity and project resource changes. + +**Frontend Delivery** + +- Amazon CloudFront + AWS Amplify: CloudFront provides the secure, scalable user entry point, while Amplify hosts and deploys the React/Vite single-page app with Git-based CI/CD, managed HTTPS, preview deployments, and optional custom domain support. + +**API & Compute** + +- Amazon API Gateway (REST): Endpoints `POST /documents/upload-url`, `GET /documents`, and `GET /documents/{id}`, all protected by the Cognito authorizer. +- AWS Lambda: Seven Node.js 20.x functions at 256 MB — `generateUploadUrl`, `jobStarter`, `validateDocument`, `textractExtraction`, `aiProxyNormalization`, `confidenceStatus`, and `statusApi`. Notification logic can be implemented as a dedicated Lambda or as a workflow task depending on the final SAM template. -![IoT Weather Platform Architecture](/images/2-Proposal/platform_architecture.jpeg) +**Storage** -### AWS Services Used -- **AWS IoT Core**: Ingests MQTT data from 5 stations, scalable to 15. -- **AWS Lambda**: Processes data and triggers Glue jobs (two functions). -- **Amazon API Gateway**: Facilitates web app communication. -- **Amazon S3**: Stores raw data in a data lake and processed outputs (two buckets). -- **AWS Glue**: Crawlers catalog data, and ETL jobs transform and load it. -- **AWS Amplify**: Hosts the Next.js web interface. -- **Amazon Cognito**: Secures access for lab users. +- Amazon S3: Two buckets — `docuflow-raw` (Block Public Access, SSE-KMS, 60-day lifecycle expiration) and `docuflow-processed` (versioned, transition to STANDARD-IA after 30 days). +- Amazon DynamoDB: On-demand table `Documents` keyed by `documentId`, with a GSI on `userId`+`status` for the user dashboard; stores metadata, status, confidence score, normalized fields, AI provider/model metadata, S3 paths, and error codes. -### Component Design -- **Edge Devices**: Raspberry Pi collects and filters sensor data, sending it to IoT Core. -- **Data Ingestion**: AWS IoT Core receives MQTT messages from the edge devices. -- **Data Storage**: Raw data is stored in an S3 data lake; processed data is stored in another S3 bucket. -- **Data Processing**: AWS Glue Crawlers catalog the data, and ETL jobs transform it for analysis. -- **Web Interface**: AWS Amplify hosts a Next.js app for real-time dashboards and analytics. -- **User Management**: Amazon Cognito manages user access, allowing up to 5 active accounts. +**Eventing & Workflow** + +- Amazon EventBridge: Default bus receives S3 `Object Created` events and routes them to SQS. +- Amazon SQS: Standard queue plus Dead-Letter Queue (max 3 retries) to absorb spikes and isolate poison messages. +- AWS Step Functions (Standard Workflow): A state machine that validates document metadata and file type, runs Textract `AnalyzeExpense`, invokes the AI Proxy Lambda, runs confidence/status logic, saves metadata to DynamoDB, saves processed JSON to S3, and routes low-confidence or failed documents to `REVIEW_REQUIRED` or `FAILED`. + +**AI Services** + +- Amazon Textract `AnalyzeExpense`: Purpose-built API for invoices and receipts; returns `SUMMARY_FIELDS` and `LINE_ITEM_FIELDS` consumed by the External AI normalization step. +- AI Proxy Lambda + External AI API: The AI Proxy Lambda secures and controls calls to the external AI service. It receives Textract output, retrieves the API key from Secrets Manager, sends only extracted fields/text to the provider, validates the response, and returns normalized JSON to the workflow. + +**Observability & Notification** + +- Amazon CloudWatch: Logs, Metrics, Alarms, and Logs Insights for Lambda, Step Functions, SQS DLQ, Textract, AI Proxy timeout/rate-limit, low-confidence documents, and cost-related operational signals. +- AWS X-Ray: Trace visibility across API Gateway, Lambda, and workflow components where enabled. +- Amazon SNS + Amazon SES: SNS topics and SES email notifications alert the team when processing fails or confidence is low. + +**Operations & Cost** + +- AWS SAM: A single SAM template per environment for reproducible deployment and clean teardown through CloudFormation. +- AWS Budgets: Spending alerts at the $5 and $10 monthly thresholds defined in section 6. + +#### End-to-end Flow + +The happy path for a single invoice or receipt traverses the system as follows: + +1. **Open frontend** — User accesses the web app through CloudFront and Amplify. +2. **Sign in** — User authenticates through Cognito and receives a JWT for downstream API calls. +3. **Request upload slot** — Frontend sends an authenticated API request to API Gateway. The `generateUploadUrl` Lambda creates a `documentId`, writes an initial DynamoDB record, and returns a short-lived S3 presigned URL. +4. **Direct upload to S3 Raw Bucket** — Browser uploads the invoice or receipt directly to S3; document bytes do not pass through API Gateway or Lambda. +5. **Queue processing job** — S3 ObjectCreated event is routed through EventBridge into SQS; status moves from `UPLOADED` to `QUEUED`. +6. **Start workflow** — Job Starter Lambda polls SQS and starts a Step Functions Standard Workflow; status moves to `PROCESSING`. +7. **Validate and extract** — Step Functions invokes Validate Lambda, then runs Textract `AnalyzeExpense` to extract invoice/receipt fields. +8. **Normalize through AI Proxy** — AI Proxy Lambda retrieves the External AI API key from Secrets Manager, sends minimized Textract fields to the external AI provider, validates the response, and returns normalized JSON. +9. **Calculate confidence and status** — Confidence + Status Lambda determines whether the document is `EXTRACTED`, `REVIEW_REQUIRED`, or `FAILED`. +10. **Persist result** — Metadata and status are saved to DynamoDB, and processed `result.json` is saved to the S3 Processed Bucket. +11. **Alert and observe** — SNS/SES sends alerts for failed or low-confidence documents. CloudWatch and X-Ray provide logs, metrics, alarms, execution visibility, and traces. +12. **Review and approval** — Frontend displays document list, status, result, and review flow; users can move corrected results to `CORRECTED` and final results to `APPROVED`. + +Failure paths are handled by Step Functions Catch branches and SQS retry/DLQ rather than ad-hoc Lambda try/catch. When any state catches an error, the workflow transitions to `MarkFailed` (or `MarkReviewRequired` for low-confidence or schema issues) and the DynamoDB status is updated accordingly. Ingestion failures occurring before Step Functions starts are absorbed by SQS retry and end up in the DLQ. ### 4. Technical Implementation -**Implementation Phases** -This project has two parts—setting up weather edge stations and building the weather platform—each following 4 phases: -- Build Theory and Draw Architecture: Research Raspberry Pi setup with ESP32 sensors and design the AWS serverless architecture (1 month pre-internship) -- Calculate Price and Check Practicality: Use AWS Pricing Calculator to estimate costs and adjust if needed (Month 1). -- Fix Architecture for Cost or Solution Fit: Tweak the design (e.g., optimize Lambda with Next.js) to stay cost-effective and usable (Month 2). -- Develop, Test, and Deploy: Code the Raspberry Pi setup, AWS services with CDK/SDK, and Next.js app, then test and release to production (Months 2-3). -**Technical Requirements** -- Weather Edge Station: Sensors (temperature, humidity, rainfall, wind speed), a microcontroller (ESP32), and a Raspberry Pi as the edge device. Raspberry Pi runs Raspbian, handles Docker for filtering, and sends 1 MB/day per station via MQTT over Wi-Fi. -- Weather Platform: Practical knowledge of AWS Amplify (hosting Next.js), Lambda (minimal use due to Next.js), AWS Glue (ETL), S3 (two buckets), IoT Core (gateway and rules), and Cognito (5 users). Use AWS CDK/SDK to code interactions (e.g., IoT Core rules to S3). Next.js reduces Lambda workload for the fullstack web app. +#### Implementation Phases + +The project runs in four short phases. Section 5 breaks each phase into specific weeks. + +1. **Design** — Lock the MVP scope, draw the architecture, and define the data contract. +2. **Estimate** — Run AWS Pricing Calculator and confirm the workshop cost ceiling. +3. **Refine** — Tune workflow boundaries, confidence threshold, and log retention to fit the five-person team. +4. **Build, test, deploy** — Implement, test end-to-end, capture evidence, and verify cleanup. + +#### Technical Requirements + +- Frontend: Single-page web app delivered through CloudFront and deployed by AWS Amplify, with login, upload, document list, status/result pages, review/correction flow, managed HTTPS, and branch-based deployments. +- Authentication: Cognito user pool with three groups — `end-user`, `reviewer`, `admin` — wired into API Gateway as a Cognito authorizer. +- Document Input: PDF, JPG, or PNG invoices and receipts uploaded through 5-minute presigned URLs, with frontend pre-validation on file type, size (≤10 MB), and page count. +- Processing: Step Functions Standard Workflow with Node.js 20.x Lambda tasks at 256 MB, Validate Lambda, Textract `AnalyzeExpense`, AI Proxy Lambda, Confidence + Status Lambda, JSON schema validation, Retry/Catch on each state, and explicit status transitions. +- Status Model: `UPLOADED` → `QUEUED` → `PROCESSING` → `EXTRACTED` / `REVIEW_REQUIRED` / `FAILED` → `CORRECTED` → `APPROVED`. +- Data Model: DynamoDB table `Documents` with PK `documentId` and a GSI on `userId`+`status`. Item attributes: `documentId`, `userId`, `fileName`, `documentType`, `status`, normalized fields, `confidenceScore`, `reviewReasons`, `aiProvider`, `normalizationMethod`, `s3RawPath`, `s3ProcessedPath`, `errorCode`, `createdAt`, and `updatedAt`. +- Observability: CloudWatch Logs (7-day retention), Metrics, and Alarms on Lambda errors, Step Functions failed executions, SQS DLQ depth, Textract errors, AI Proxy timeout/rate-limit count, invalid AI response count, and low-confidence document count; X-Ray traces across API, Lambda, and workflow components where enabled. +- Security: No public S3 buckets (Block Public Access), no hard-coded keys, least-privilege IAM role per Lambda, AWS KMS managed keys for encryption at rest, short-lived presigned URLs, External AI API key stored in Secrets Manager, no raw PDF/image sent to the external AI provider by default, CloudTrail enabled for audit visibility, AWS Budgets for spending governance, and a SAM cleanup script. +- Infrastructure as Code: A single AWS SAM stack per environment provisions every resource above and supports clean teardown. +- Reporting Deliverables: Test cases, screenshots covering each status transition, demo recording, and bilingual workshop instructions. + +#### Data Contract and External AI Payload + +All modules share one JSON contract so frontend, workflow, storage, API response, and analytics stay consistent: + +```json +{ + "documentId": "doc-001", + "userId": "user-123", + "fileName": "invoice-001.pdf", + "documentType": "INVOICE", + "status": "EXTRACTED", + "vendorName": "ABC Company", + "invoiceDate": "2026-06-01", + "currency": "VND", + "totalAmount": 2500000, + "taxAmount": 250000, + "confidenceScore": 0.91, + "reviewReasons": [], + "aiProvider": "external-ai-api", + "normalizationMethod": "TEXTRACT_PLUS_AI_PROXY_EXTERNAL_API", + "s3RawPath": "s3://docuflow-dev-raw-bucket/raw/user-123/doc-001/original.pdf", + "s3ProcessedPath": "s3://docuflow-dev-processed-bucket/processed/user-123/doc-001/result.json", + "createdAt": "2026-06-08T10:00:00Z", + "updatedAt": "2026-06-08T10:01:00Z" +} +``` + +The External AI API receives a minimized payload only: + +```json +{ + "documentId": "doc-001", + "fileName": "invoice-001.pdf", + "textractSummaryFields": [ + { + "type": "VENDOR_NAME", + "text": "ABC Company", + "confidence": 0.96 + }, + { + "type": "TOTAL", + "text": "2,500,000 VND", + "confidence": 0.93 + } + ], + "textractLineItems": [], + "rawTextPreview": "Invoice ABC Company total 2,500,000 VND..." +} +``` + +The payload must not include raw PDF files, raw images, API keys, AWS credentials, full documents when not necessary, or unrelated sensitive information. The AI Proxy Lambda validates that the response is valid JSON, `documentType` is `INVOICE`, `RECEIPT`, or `UNKNOWN`, `totalAmount` is numeric, `invoiceDate` is ISO-8601 when available, `confidenceScore` is between 0 and 1, and low-confidence or missing required fields are represented in `reviewReasons`. + +#### Technology Stack + +The stack below complements the AWS services in section 3. It is the concrete code-level toolset the team uses to build, test, deploy, and document the platform. + +**Frontend** + +| Layer | Choice | Notes | +|---|---|---| +| Language | TypeScript 5 | Shared types with backend via a workspace package | +| Framework | React 18 | Single-page app delivered through CloudFront and deployed by Amplify | +| Build tool | Vite | Fast HMR, zero-config TypeScript | +| Auth | `amazon-cognito-identity-js` | Official lightweight Cognito SDK; talks to the User Pool from section 3 | +| API client | `axios` + `@tanstack/react-query` | Axios interceptor injects the Cognito JWT; TanStack Query caches server state | +| UI | shadcn/ui + Tailwind CSS | Component primitives, no vendor lock | +| Forms | React Hook Form + Zod | Zod schemas reused server-side | +| Routing | React Router v6 | | +| Testing | Vitest (unit) | E2E is out of scope for the workshop | + +**Backend Lambda** + +| Layer | Choice | Notes | +|---|---|---| +| Runtime | Node.js 20.x at 256 MB | As declared in sections 3 and 4 | +| Language | TypeScript 5 | Compiled with esbuild via SAM | +| AWS SDK | AWS SDK v3 modular packages | `client-s3`, `s3-request-presigner`, `client-dynamodb`, `lib-dynamodb`, `client-textract`, `client-secrets-manager`, `client-sns`, `client-sfn` | +| External API client | `fetch` / `undici` with timeout and retry limits | Calls the External AI API only from AI Proxy Lambda | +| Validation | Ajv (JSON Schema) + Zod | Ajv enforces the AI Proxy JSON contract; Zod validates HTTP payloads | +| Observability | AWS Lambda Powertools for TypeScript + X-Ray SDK | Structured logs, custom metrics, tracing | +| Testing | Vitest + `aws-sdk-client-mock` | | + +**Infrastructure & DevOps** + +| Concern | Choice | Notes | +|---|---|---| +| IaC | AWS SAM | Uses the CloudFormation transform; teardown via `sam delete` or `aws cloudformation delete-stack` per the section 7 contingency | +| Local Lambda | AWS SAM CLI (`sam local invoke`, `sam local start-api`) | | +| External AI API | Configured provider/model through environment variables | API key stored in Secrets Manager; raw files are not sent by default | +| Monorepo | pnpm workspaces | | +| Linting | ESLint + Prettier | One shared config across `apps/*`, `services/*`, `packages/*` | +| Secrets scan | gitleaks pre-commit hook | Blocks accidental key commits | +| CI/CD | Amplify Hosting for frontend; GitHub Actions with OIDC → IAM role for backend | Jobs: `lint-test` on PR, `deploy-dev` on `main`, `deploy-prod` on a `v*` tag | +| Documentation | Hugo + Learn theme (this repo) | Bilingual EN/VI, diagrams in draw.io | + +**Repository Layout** + +```text +docuflow-ai/ +├── frontend/ +│ └── src/ # React + Vite frontend deployed by Amplify +├── backend/ +│ ├── functions/ +│ │ ├── upload-url/ +│ │ ├── job-starter/ +│ │ ├── textract-extraction/ +│ │ ├── ai-proxy-normalization/ +│ │ ├── confidence-status/ +│ │ ├── status-api/ +│ │ └── notification/ +│ └── shared/ +│ ├── schema/ # JSON schema and Zod DTOs +│ └── utils/ +├── infrastructure/ +│ ├── template.yaml # SAM root template +│ └── parameters/{dev,demo}.json +├── docs/ +│ ├── architecture/ +│ ├── test-evidence/ +│ └── demo-script.md +└── samples/ + ├── invoices/ + └── receipts/ +``` + +The Lambda function folders mirror the responsibilities declared in section 3, and the shared schema package enforces the same data contract across upload, normalization, storage, API response, and analytics modules. + +#### Team Ownership + +| Member | Role | Main responsibility | +|---|---|---| +| Hoàng Trọng Trà | Leader / Integration Owner | Ingestion, EventBridge, SQS, Job Starter Lambda, Step Functions, integration flow | +| Vũ Duy Tài | AI Owner | Textract, AI Proxy Lambda, External AI API normalization, confidence/status logic | +| Nguyễn Hữu Tịnh | Frontend/Auth Owner | CloudFront, Amplify, Cognito, API Gateway integration, upload/result/review UI | +| Lâm Quang Lộc | Data Owner | DynamoDB, S3 processed JSON, metadata schema, document result management | +| Phạm Tùng Dương | Ops/Security/IaC Owner | IAM, KMS, Secrets Manager, CloudTrail, Budgets, SAM, CloudWatch, X-Ray, SNS/SES | ### 5. Timeline & Milestones -**Project Timeline** -- Pre-Internship (Month 0): 1 month for planning and old station review. -- Internship (Months 1-3): 3 months. - - Month 1: Study AWS and upgrade hardware. - - Month 2: Design and adjust architecture. - - Month 3: Implement, test, and launch. -- Post-Launch: Up to 1 year for research. + +#### Project Timeline + +- Week 1: Study FCAJ requirements, lock the MVP scope, define the data contract, and draw the architecture. +- Week 2-3: Build foundation services: Cognito, frontend hosting, API Gateway, Lambda upload API, S3 buckets, and DynamoDB table. +- Week 4-5: Build ingestion and workflow: EventBridge, SQS, Step Functions, retry/catch handling, and status transitions. +- Week 6-7: Build AI extraction and normalization: Textract processing, AI Proxy Lambda, External AI API integration, Secrets Manager secret retrieval, JSON schema validation, confidence/status logic, and result storage. +- Week 8: Build result and review UI: document list, document detail page, extracted-field display, correction flow, approval flow, and status tracking. +- Week 9-10: Add observability, security, governance, and IaC: CloudWatch logs/metrics/alarms, X-Ray tracing, SNS/SES alerts, IAM review, KMS encryption, CloudTrail, External AI API retry limits, AWS Budgets, and SAM stack consolidation per environment. +- Week 11: Run test cases, capture screenshots, prepare workshop instructions, and verify cleanup. +- Week 12: Polish bilingual report content, final demo flow, budget estimate, and submission materials. ### 6. Budget Estimation -You can find the budget estimation on the [AWS Pricing Calculator](https://calculator.aws/#/estimate?id=621f38b12a1ef026842ba2ddfe46ff936ed4ab01). -Or you can download the [Budget Estimation File](../attachments/budget_estimation.pdf). -### Infrastructure Costs -- AWS Services: - - AWS Lambda: $0.00/month (1,000 requests, 512 MB storage). - - S3 Standard: $0.15/month (6 GB, 2,100 requests, 1 GB scanned). - - Data Transfer: $0.02/month (1 GB inbound, 1 GB outbound). - - AWS Amplify: $0.35/month (256 MB, 500 ms requests). - - Amazon API Gateway: $0.01/month (2,000 requests). - - AWS Glue ETL Jobs: $0.02/month (2 DPUs). - - AWS Glue Crawlers: $0.07/month (1 crawler). - - MQTT (IoT Core): $0.08/month (5 devices, 45,000 messages). +The budget targets a workshop-scale workload that a five-person team can run end-to-end while staying close to the AWS Free Tier. The official estimate can be created and updated with the [AWS Pricing Calculator](https://calculator.aws/#/). + +#### Assumptions + +The estimate uses the following baseline so each cost line is reproducible: + +- Region: `ap-southeast-1` (Singapore — closest AWS region to Vietnam, lowest latency for local end users; pricing is moderately higher than `us-east-1` for CloudWatch, DynamoDB, API Gateway, and Step Functions, but still well within a workshop budget). +- Document volume: 100 invoice/receipt files per month, average 2 pages per file (about 200 pages per month). +- External AI API usage: 100 normalization requests per month through AI Proxy Lambda, sending only minimized Textract text/fields and line items. The team sets provider-side usage caps where available and validates actual pricing before running demos. +- API traffic: about 5,000 REST API calls per month across upload-url, list-documents, and document-status endpoints. +- Storage: 1 GB raw documents and 0.5 GB processed JSON/CSV. +- Logs: about 500 MB CloudWatch log ingestion per month with a 7-day retention. +- Users: 5–10 monthly active Cognito users (well within the always-free 50,000 MAU). +- Step Functions: 100 Standard-workflow executions per month, about 9 states per document. + +#### Monthly Cost Breakdown -Total: $0.7/month, $8.40/12 months +| Service | Usage assumption | Monthly cost (USD) | +|---|---|---| +| Amazon Textract `AnalyzeExpense` | 200 pages | $2.00 | +| External AI API | 100 normalization requests, minimized payload | $0.00 – $2.00 provider-dependent | +| AWS Secrets Manager | 1 external API secret | $0.40 | +| AWS Lambda | ~1,200 invocations, 256 MB, ~500 ms | $0.00 – $0.10 | +| Amazon API Gateway (REST) | ~5,000 calls | $0.02 – $0.03 | +| Amazon S3 | 1.5 GB Standard + small request volume | $0.03 – $0.10 | +| Amazon DynamoDB (on-demand) | 1,000 writes + 5,000 reads, < 1 GB storage | $0.05 – $0.30 | +| Amazon EventBridge + Amazon SQS | ~100 events, low queue volume | $0.00 – $0.10 | +| AWS Step Functions Standard | 100 executions × ~9 states | $0.00 – $0.10 | +| Amazon CloudWatch + AWS X-Ray | ~500 MB logs, 7-day retention, traces, ~5 alarms | $0.60 – $1.40 | +| Amazon SNS/SES | ~100 alerts | $0.00 – $0.10 | +| Amazon Cognito | 5–10 MAU (free tier covers 50k) | $0.00 | +| Amazon CloudFront + AWS Amplify Hosting | static React build, low demo traffic, occasional builds | $0.00 – $1.00 | +| AWS CloudTrail + AWS Budgets | management events and spending alerts | $0.00 | +| **Total** | | **$3.50 – $8.00** | -- Hardware: $265 one-time (Raspberry Pi 5 and sensors). +Annualized: about **$36 – $84 for 12 months**. Numbers vary with region, Textract pages, External AI API provider pricing, retry volume, token/payload size, and CloudWatch retention. AWS SAM/CloudFormation (deployment) and AWS Budgets (cost alerts) are also used and stay at **$0.00** within free usage limits. + +#### Free Tier Impact + +Free Tier coverage depends on the account creation date and selected account plan. Accounts created before July 15, 2025 can still follow the legacy 12-month Free Tier model, while newer accounts may use the current AWS Free Tier plan and credits. Before running the workshop, the team will verify the actual account's Free Tier status in AWS Billing and keep AWS Budgets alerts at $5 and $10. + +For this workload, several services may still be free or near-free at workshop volume, such as Lambda, DynamoDB, SNS, Cognito, CloudFront, and Amplify static hosting. API Gateway, S3 storage, CloudWatch logs/alarms, X-Ray traces, Step Functions, and Amplify build minutes/data transfer must be checked against the active account's Free Tier and pricing page rather than assumed to be free. + +Textract and the External AI API are **not** covered by AWS Free Tier assumptions in this proposal, so the team must validate both charges directly and keep the monthly workshop budget at or below **$10**. + +#### Scaling Scenario + +If the workload grows 10× to 1,000 documents and 2,000 pages per month, Textract scales linearly to roughly $20/month and the External AI API scales according to provider pricing, retry count, and payload size. The other services stay near current levels, putting the AWS-side platform around **$25 – $40/month** before provider-specific AI charges. + +#### Cost Controls + +- AWS Budgets alerts set at $5 and $10 thresholds with email notification. +- CloudWatch log retention set to 7 days; metric filters limited to essential workflow metrics. +- External AI API requests capped by payload size, retry count, timeout, and provider-side spending or usage limits where available. +- S3 lifecycle policy: expire raw uploads after 60 days, move processed JSON to STANDARD-IA after 30 days. +- Textract sample test files limited to ≤ 5 pages each during development. +- Step Functions per-task timeouts set to 30 seconds to avoid runaway executions. +- Final cleanup runs `aws cloudformation delete-stack` (or `sam delete`) on the backend workshop stack, then deletes the Amplify app/branches from the Amplify console or CLI. Together this removes the Cognito User Pool, S3 buckets, DynamoDB table, Step Functions state machine, API Gateway, Lambda functions, EventBridge rules, SQS queues, SNS topic, IAM roles, CloudWatch log groups, and frontend hosting resources. +- CloudTrail, Budgets, X-Ray, SNS, and SES are kept within narrow workshop usage so they provide governance and evidence without becoming open-ended cost drivers. ### 7. Risk Assessment + #### Risk Matrix -- Network Outages: Medium impact, medium probability. -- Sensor Failures: High impact, low probability. -- Cost Overruns: Medium impact, low probability. + +Severity is impact × probability on a 1–3 scale (max 9). Owner refers to the workshop module accountable for the mitigation. + +| ID | Risk | Impact | Probability | Severity | Owner | +|---|---|---|---|---|---| +| R-01 | Scope creep beyond invoice/receipt MVP | High (3) | Medium (2) | 6 | Tech lead | +| R-02 | Low Textract accuracy on poor scans | High (3) | Medium (2) | 6 | AI module | +| R-03 | External AI API returns malformed JSON / wrong schema | Medium (2) | Medium (2) | 4 | AI module | +| R-04 | Asynchronous workflow failure (Step Functions / SQS) | High (3) | Low (1) | 3 | Workflow module | +| R-05 | Cost overrun beyond $10/month budget | Medium (2) | Low (1) | 2 | IaC/Ops module | +| R-06 | IAM misconfiguration exposes data | High (3) | Low (1) | 3 | Security module | +| R-07 | External AI API timeout, rate limit, or outage | Medium (2) | Medium (2) | 4 | AI module | +| R-08 | Presigned URL leaked from frontend or logs | High (3) | Low (1) | 3 | Frontend / Security | +| R-09 | Document edge cases (low-DPI scan, encrypted, oversized) | Medium (2) | Medium (2) | 4 | AI module | +| R-10 | Sensitive document data sent unnecessarily to external provider | High (3) | Low (1) | 3 | Security / AI module | +| R-11 | External AI API key leaked or missing | High (3) | Low (1) | 3 | Security / IaC module | #### Mitigation Strategies -- Network: Local storage on Raspberry Pi with Docker. -- Sensors: Regular checks and spares. -- Cost: AWS budget alerts and optimization. + +- **R-01 (Scope)**: Lock the MVP to invoice and receipt only; any new document type goes through a change-request review before entering the backlog. +- **R-02 (Extraction)**: Use clear sample documents during dev, set a confidence threshold of 0.7, and route low-confidence results to `REVIEW_REQUIRED` for the human review path. +- **R-03 (External AI JSON)**: Strict prompt/instruction with a JSON-only contract, JSON schema validation in the normalization Lambda, automatic retry once, then mark `REVIEW_REQUIRED` if the structure is still invalid. +- **R-04 (Workflow)**: Step Functions Catch states on each task, SQS Standard queue with DLQ at 3 retries, CloudWatch alarm on DLQ depth, and clear DynamoDB status transitions. +- **R-05 (Cost)**: AWS Budgets alerts at $5 and $10, CloudWatch log retention capped at 7 days, External AI API request/retry caps, provider-side spending limit where available, S3 lifecycle policies, and a Textract sample limit of ≤5 pages per file during development. +- **R-06 (IAM)**: One IAM role per Lambda function, Step Functions execution role separated from task roles, AWS KMS managed keys for storage, S3 Block Public Access on every bucket, and a periodic IAM Access Analyzer review. +- **R-07 (External API availability)**: Retry with exponential backoff on timeout/rate-limit, cap retries, emit CloudWatch metrics, then mark `REVIEW_REQUIRED` or `FAILED` instead of blocking the whole workflow. +- **R-08 (Presigned URL)**: TTL of 5 minutes per URL, scope each URL to a single object key, never log the full URL, and filter URLs out of client-side error reports. +- **R-09 (Edge cases)**: Frontend pre-validates file type, size (≤10 MB), and page count; backend returns a structured error and writes the file to a `quarantine/` S3 prefix for manual triage. +- **R-10 (Sensitive data minimization)**: Send only extracted text/fields and a short raw text preview when necessary; do not send raw PDF/image files, AWS credentials, API keys, or unrelated sensitive fields to the external provider. +- **R-11 (Secret handling)**: Store the External AI API key in Secrets Manager, give only the AI Proxy Lambda permission to read that specific secret, never log the key, and rotate it if exposure is suspected. #### Contingency Plans -- Revert to manual methods if AWS fails. -- Use CloudFormation for cost-related rollbacks. + +- **R-02 / R-03 demo failure**: Use a prepared sample extraction result to demonstrate the status/result UI while showing the failed Step Functions execution history for transparency. +- **R-04 backlog growth**: Pause uploads, inspect SQS and DLQ, then replay only a small sample batch after fixing the root cause. +- **R-05 cost spike**: Stop test uploads, disable the External AI API key or lower provider usage limits, drop CloudWatch retention to 1 day, empty raw and processed buckets, and run the CloudFormation `delete-stack` script if needed. +- **R-06 IAM exposure**: Rotate any leaked credential, disable the affected role, and re-deploy the stack from a clean commit. +- **R-07 External AI API outage**: Route affected documents to `REVIEW_REQUIRED`, show the Step Functions execution history, and use prepared normalized JSON only for the demo UI if the provider remains unavailable. +- **R-08 URL leak**: Invalidate the user's active credentials, re-issue presigned URLs, and audit Amplify access logs / API Gateway logs for the leaked URL pattern. +- **R-10 / R-11 data or key exposure**: Stop external API calls, rotate the provider key, inspect CloudWatch logs for leakage, and re-enable only after payload minimization and log redaction are verified. ### 8. Expected Outcomes -#### Technical Improvements: -Real-time data and analytics replace manual processes. -Scalable to 10-15 stations. + +#### Technical Improvements + +DocuFlow AI replaces manual invoice and receipt entry with a serverless document-processing workflow. It provides secure upload, automated Textract extraction, External AI API normalization through AI Proxy Lambda, schema validation, metadata storage, status tracking, notifications, operational logs, audit visibility, and cost governance. + +#### Success Criteria + +The workshop is considered complete when each of the following has evidence: + +- Field-level extraction accuracy ≥ 90% for required summary fields on a curated test set of 20 sample invoices and receipts. Required fields are `vendorName`, `invoiceDate`, `totalAmount`, `taxAmount`, and `currency`; line-item extraction is treated as bonus evidence because it varies more across document formats. +- End-to-end processing latency ≤ 60 seconds at the 95th percentile. +- Workshop monthly AWS cost stays at or below **$10**, verified via AWS Budgets and Cost Explorer. +- Every Lambda function has its own least-privilege IAM role; no role is shared across functions. +- All primary DynamoDB status paths exercised with screenshots: `UPLOADED`, `QUEUED`, `PROCESSING`, `EXTRACTED`, `REVIEW_REQUIRED`, `FAILED`, `CORRECTED`, and `APPROVED`. +- Step Functions runs validate, Textract, AI Proxy, confidence/status, and save-result steps. +- External AI API key is stored in Secrets Manager, not source code, frontend code, logs, or API responses. +- External AI payloads contain minimized Textract output only; raw PDF/image files are not sent to the external provider by default. +- CloudWatch logs/alarms, X-Ray trace evidence, SNS/SES alert evidence, CloudTrail audit evidence, and Budgets screenshot are available. +- The SAM/CloudFormation stack deploys cleanly from a fresh account and tears down without manual cleanup. +- Bilingual report (EN/VI) covers each of the eight workshop modules in `5-Workshop`. + #### Long-term Value -1-year data foundation for AI research. -Reusable for future projects. \ No newline at end of file + +The project creates a reusable foundation for financial document processing on AWS. Future teams can extend the same pattern to more document types, stronger validation rules, richer reporting, and deeper finance-system integration. For FCAJ, the workshop demonstrates practical use of AWS serverless services, AI-assisted document processing, external API security, audit visibility, cost control, observability, and cleanup in one coherent solution. diff --git a/content/2-Proposal/_index.vi.md b/content/2-Proposal/_index.vi.md index e2ea5b6..192980f 100644 --- a/content/2-Proposal/_index.vi.md +++ b/content/2-Proposal/_index.vi.md @@ -1,108 +1,425 @@ --- title: "Bản đề xuất" -date: 2024-01-01 +date: 2026-04-20 weight: 2 chapter: false pre: " 2. " --- -{{% notice warning %}} -⚠️ **Lưu ý:** Các thông tin dưới đây chỉ nhằm mục đích tham khảo, vui lòng **không sao chép nguyên văn** cho bài báo cáo của bạn kể cả warning này. -{{% /notice %}} - -Tại phần này, bạn cần tóm tắt các nội dung trong workshop mà bạn **dự tính** sẽ làm. - -# IoT Weather Platform for Lab Research -## Giải pháp AWS Serverless hợp nhất cho giám sát thời tiết thời gian thực - -### 1. Tóm tắt điều hành -IoT Weather Platform được thiết kế dành cho nhóm *ITea Lab* tại TP. Hồ Chí Minh nhằm nâng cao khả năng thu thập và phân tích dữ liệu thời tiết. Nền tảng hỗ trợ tối đa 5 trạm thời tiết, có khả năng mở rộng lên 10–15 trạm, sử dụng thiết bị biên Raspberry Pi kết hợp cảm biến ESP32 để truyền dữ liệu qua MQTT. Nền tảng tận dụng các dịch vụ AWS Serverless để cung cấp giám sát thời gian thực, phân tích dự đoán và tiết kiệm chi phí, với quyền truy cập giới hạn cho 5 thành viên phòng lab thông qua Amazon Cognito. - -### 2. Tuyên bố vấn đề -*Vấn đề hiện tại* -Các trạm thời tiết hiện tại yêu cầu thu thập dữ liệu thủ công, khó quản lý khi có nhiều trạm. Không có hệ thống tập trung cho dữ liệu hoặc phân tích thời gian thực, và các nền tảng bên thứ ba thường tốn kém và quá phức tạp. - -*Giải pháp* -Nền tảng sử dụng AWS IoT Core để tiếp nhận dữ liệu MQTT, AWS Lambda và API Gateway để xử lý, Amazon S3 để lưu trữ (bao gồm data lake), và AWS Glue Crawlers cùng các tác vụ ETL để trích xuất, chuyển đổi, tải dữ liệu từ S3 data lake sang một S3 bucket khác để phân tích. AWS Amplify với Next.js cung cấp giao diện web, và Amazon Cognito đảm bảo quyền truy cập an toàn. Tương tự như Thingsboard và CoreIoT, người dùng có thể đăng ký thiết bị mới và quản lý kết nối, nhưng nền tảng này hoạt động ở quy mô nhỏ hơn và phục vụ mục đích sử dụng nội bộ. Các tính năng chính bao gồm bảng điều khiển thời gian thực, phân tích xu hướng và chi phí vận hành thấp. - -*Lợi ích và hoàn vốn đầu tư (ROI)* -Giải pháp tạo nền tảng cơ bản để các thành viên phòng lab phát triển một nền tảng IoT lớn hơn, đồng thời cung cấp nguồn dữ liệu cho những người nghiên cứu AI phục vụ huấn luyện mô hình hoặc phân tích. Nền tảng giảm bớt báo cáo thủ công cho từng trạm thông qua hệ thống tập trung, đơn giản hóa quản lý và bảo trì, đồng thời cải thiện độ tin cậy dữ liệu. Chi phí hàng tháng ước tính 0,66 USD (theo AWS Pricing Calculator), tổng cộng 7,92 USD cho 12 tháng. Tất cả thiết bị IoT đã được trang bị từ hệ thống trạm thời tiết hiện tại, không phát sinh chi phí phát triển thêm. Thời gian hoàn vốn 6–12 tháng nhờ tiết kiệm đáng kể thời gian thao tác thủ công. - -### 3. Kiến trúc giải pháp -Nền tảng áp dụng kiến trúc AWS Serverless để quản lý dữ liệu từ 5 trạm dựa trên Raspberry Pi, có thể mở rộng lên 15 trạm. Dữ liệu được tiếp nhận qua AWS IoT Core, lưu trữ trong S3 data lake và xử lý bởi AWS Glue Crawlers và ETL jobs để chuyển đổi và tải vào một S3 bucket khác cho mục đích phân tích. Lambda và API Gateway xử lý bổ sung, trong khi Amplify với Next.js cung cấp bảng điều khiển được bảo mật bởi Cognito. - -![IoT Weather Station Architecture](/images/2-Proposal/edge_architecture.jpeg) - -![IoT Weather Platform Architecture](/images/2-Proposal/platform_architecture.jpeg) - -*Dịch vụ AWS sử dụng* -- *AWS IoT Core*: Tiếp nhận dữ liệu MQTT từ 5 trạm, mở rộng lên 15. -- *AWS Lambda*: Xử lý dữ liệu và kích hoạt Glue jobs (2 hàm). -- *Amazon API Gateway*: Giao tiếp với ứng dụng web. -- *Amazon S3*: Lưu trữ dữ liệu thô (data lake) và dữ liệu đã xử lý (2 bucket). -- *AWS Glue*: Crawlers lập chỉ mục dữ liệu, ETL jobs chuyển đổi và tải dữ liệu. -- *AWS Amplify*: Lưu trữ giao diện web Next.js. -- *Amazon Cognito*: Quản lý quyền truy cập cho người dùng phòng lab. - -*Thiết kế thành phần* -- *Thiết bị biên*: Raspberry Pi thu thập và lọc dữ liệu cảm biến, gửi tới IoT Core. -- *Tiếp nhận dữ liệu*: AWS IoT Core nhận tin nhắn MQTT từ thiết bị biên. -- *Lưu trữ dữ liệu*: Dữ liệu thô lưu trong S3 data lake; dữ liệu đã xử lý lưu ở một S3 bucket khác. -- *Xử lý dữ liệu*: AWS Glue Crawlers lập chỉ mục dữ liệu; ETL jobs chuyển đổi để phân tích. -- *Giao diện web*: AWS Amplify lưu trữ ứng dụng Next.js cho bảng điều khiển và phân tích thời gian thực. -- *Quản lý người dùng*: Amazon Cognito giới hạn 5 tài khoản hoạt động. - -### 4. Triển khai kỹ thuật -*Các giai đoạn triển khai* -Dự án gồm 2 phần — thiết lập trạm thời tiết biên và xây dựng nền tảng thời tiết — mỗi phần trải qua 4 giai đoạn: -1. *Nghiên cứu và vẽ kiến trúc*: Nghiên cứu Raspberry Pi với cảm biến ESP32 và thiết kế kiến trúc AWS Serverless (1 tháng trước kỳ thực tập). -2. *Tính toán chi phí và kiểm tra tính khả thi*: Sử dụng AWS Pricing Calculator để ước tính và điều chỉnh (Tháng 1). -3. *Điều chỉnh kiến trúc để tối ưu chi phí/giải pháp*: Tinh chỉnh (ví dụ tối ưu Lambda với Next.js) để đảm bảo hiệu quả (Tháng 2). -4. *Phát triển, kiểm thử, triển khai*: Lập trình Raspberry Pi, AWS services với CDK/SDK và ứng dụng Next.js, sau đó kiểm thử và đưa vào vận hành (Tháng 2–3). - -*Yêu cầu kỹ thuật* -- *Trạm thời tiết biên*: Cảm biến (nhiệt độ, độ ẩm, lượng mưa, tốc độ gió), vi điều khiển ESP32, Raspberry Pi làm thiết bị biên. Raspberry Pi chạy Raspbian, sử dụng Docker để lọc dữ liệu và gửi 1 MB/ngày/trạm qua MQTT qua Wi-Fi. -- *Nền tảng thời tiết*: Kiến thức thực tế về AWS Amplify (lưu trữ Next.js), Lambda (giảm thiểu do Next.js xử lý), AWS Glue (ETL), S3 (2 bucket), IoT Core (gateway và rules), và Cognito (5 người dùng). Sử dụng AWS CDK/SDK để lập trình (ví dụ IoT Core rules tới S3). Next.js giúp giảm tải Lambda cho ứng dụng web fullstack. - -### 5. Lộ trình & Mốc triển khai -- *Trước thực tập (Tháng 0)*: 1 tháng lên kế hoạch và đánh giá trạm cũ. -- *Thực tập (Tháng 1–3)*: - - Tháng 1: Học AWS và nâng cấp phần cứng. - - Tháng 2: Thiết kế và điều chỉnh kiến trúc. - - Tháng 3: Triển khai, kiểm thử, đưa vào sử dụng. -- *Sau triển khai*: Nghiên cứu thêm trong vòng 1 năm. - -### 6. Ước tính ngân sách -Có thể xem chi phí trên [AWS Pricing Calculator](https://calculator.aws/#/estimate?id=621f38b12a1ef026842ba2ddfe46ff936ed4ab01) -Hoặc tải [tệp ước tính ngân sách](../attachments/budget_estimation.pdf). - -*Chi phí hạ tầng* -- AWS Lambda: 0,00 USD/tháng (1.000 request, 512 MB lưu trữ). -- S3 Standard: 0,15 USD/tháng (6 GB, 2.100 request, 1 GB quét). -- Truyền dữ liệu: 0,02 USD/tháng (1 GB vào, 1 GB ra). -- AWS Amplify: 0,35 USD/tháng (256 MB, request 500 ms). -- Amazon API Gateway: 0,01 USD/tháng (2.000 request). -- AWS Glue ETL Jobs: 0,02 USD/tháng (2 DPU). -- AWS Glue Crawlers: 0,07 USD/tháng (1 crawler). -- MQTT (IoT Core): 0,08 USD/tháng (5 thiết bị, 45.000 tin nhắn). - -*Tổng*: 0,7 USD/tháng, 8,40 USD/12 tháng -- *Phần cứng*: 265 USD một lần (Raspberry Pi 5 và cảm biến). - -### 7. Đánh giá rủi ro -*Ma trận rủi ro* -- Mất mạng: Ảnh hưởng trung bình, xác suất trung bình. -- Hỏng cảm biến: Ảnh hưởng cao, xác suất thấp. -- Vượt ngân sách: Ảnh hưởng trung bình, xác suất thấp. - -*Chiến lược giảm thiểu* -- Mạng: Lưu trữ cục bộ trên Raspberry Pi với Docker. -- Cảm biến: Kiểm tra định kỳ, dự phòng linh kiện. -- Chi phí: Cảnh báo ngân sách AWS, tối ưu dịch vụ. - -*Kế hoạch dự phòng* -- Quay lại thu thập thủ công nếu AWS gặp sự cố. -- Sử dụng CloudFormation để khôi phục cấu hình liên quan đến chi phí. - -### 8. Kết quả kỳ vọng -*Cải tiến kỹ thuật*: Dữ liệu và phân tích thời gian thực thay thế quy trình thủ công. Có thể mở rộng tới 10–15 trạm. -*Giá trị dài hạn*: Nền tảng dữ liệu 1 năm cho nghiên cứu AI, có thể tái sử dụng cho các dự án tương lai. \ No newline at end of file + +# DocuFlow AI - Nền tảng xử lý invoice & receipt thông minh bằng AWS Serverless + +## Giải pháp AWS Serverless cho xử lý invoice và receipt thông minh + +### 1. Tóm tắt điều hành + +DocuFlow AI được thiết kế cho các doanh nghiệp vừa và nhỏ cần xử lý invoice và receipt với ít thao tác thủ công hơn. Nền tảng cho phép người dùng đã đăng nhập upload tài liệu PDF, JPG hoặc PNG, sau đó dùng các dịch vụ managed của AWS để trích xuất dữ liệu tài chính, chuẩn hóa kết quả, lưu metadata và hiển thị trạng thái xử lý trên giao diện web đơn giản. + +Giải pháp sử dụng kiến trúc serverless, event-driven, deploy bằng AWS SAM tại region `ap-southeast-1` (Singapore). Người dùng truy cập frontend qua Amazon CloudFront và AWS Amplify, đăng nhập bằng Amazon Cognito, và upload tài liệu qua presigned URL. Amazon S3 lưu file gốc, EventBridge và SQS tách lớp ingestion khỏi processing, Step Functions điều phối workflow, Amazon Textract trích xuất dữ liệu invoice/receipt, AI Proxy Lambda gọi External AI API để chuẩn hóa kết quả trích xuất, Confidence + Status Lambda quyết định trạng thái cuối cùng, và DynamoDB lưu trạng thái cùng metadata của tài liệu. + +Workshop được giới hạn cho nhóm 5 người. Mỗi người phụ trách một module: frontend/auth/upload, ingestion/workflow, AI extraction và validation, data/result dashboard, observability/security/IaC. + +### 2. Tuyên bố vấn đề + +#### Vấn đề là gì? + +Nhiều doanh nghiệp vẫn xử lý invoice và receipt qua email, folder chia sẻ, spreadsheet hoặc nhập liệu thủ công. Cách làm này tạo ra nhiều vấn đề: + +- Đội Finance và Operations mất thời gian lặp lại để nhập vendor name, invoice date, tax, total amount và line items. +- Nhập liệu thủ công dễ gây sai giá trị, thiếu field và format dữ liệu không nhất quán. +- Người dùng khó biết tài liệu đang uploaded, processing, failed, extracted hay waiting for review. +- Tài liệu khó tìm kiếm, kiểm toán và tổng hợp khi bị phân tán qua email hoặc shared drive. +- Đội Finance thiếu góc nhìn tổng hợp theo vendor, tháng, loại chứng từ hoặc lý do xử lý thất bại. +- Chạy server thường trực cho workload tài liệu không đều làm tăng chi phí và công vận hành. + +#### Giải pháp + +DocuFlow AI tập trung upload và xử lý tài liệu trên AWS. Frontend cung cấp login, upload, theo dõi trạng thái, xem kết quả và chỉnh sửa thủ công khi cần. Backend dùng presigned URL để upload an toàn lên S3, sau đó xử lý bất đồng bộ bằng EventBridge, SQS, Lambda và Step Functions. + +Amazon Textract trích xuất field từ invoice và receipt. AI Proxy Lambda chỉ gửi payload Textract đã được rút gọn sang External AI API, map các field name không nhất quán về một schema thống nhất, phân loại tài liệu là invoice hoặc receipt, giải thích field thiếu và trả structured JSON. Lambda validate schema, confidence score và business rules trước khi lưu kết quả vào DynamoDB và S3 processed storage. Frontend không bao giờ gọi external AI API trực tiếp, và raw PDF/image không được gửi sang external AI provider trừ khi team phê duyệt rõ hành vi đó. + +#### Lợi ích và giá trị đầu tư + +DocuFlow AI giảm công nhập liệu thủ công và tạo quy trình lặp lại được cho xử lý chứng từ tài chính. Hệ thống tạo metadata store có thể tìm kiếm, hiển thị trạng thái rõ ràng và hỗ trợ review loop cho tài liệu có confidence thấp. Vì MVP dùng serverless, nền tảng giữ chi phí thấp cho workload workshop và có thể mở rộng theo số lượng tài liệu khi cần. + +Chi phí AWS ước tính cho workload workshop khoảng **$3.50-$8.00 mỗi tháng**, tương đương **$42-$96 cho 12 tháng** tại region `ap-southeast-1` (Singapore), tùy số trang Textract, usage của External AI API, CloudWatch/X-Ray volume, log retention và số lần test alert. Đề tài cũng có giá trị học tập rõ ràng về AWS serverless architecture, AI document processing, asynchronous workflow, secure secret handling, observability, governance và cleanup. + +### 3. Kiến trúc giải pháp + +DocuFlow AI dùng kiến trúc AWS serverless cho secure upload, asynchronous processing, AI-assisted extraction, result storage và operational monitoring. Kiến trúc tổng quan như sau: + +![Kiến trúc high-level của DocuFlow AI với External AI API](/images/2-Proposal/docuflow_high_level_architecture.png) + +Diagram thể hiện approved architecture scope: CloudFront, Amplify, Cognito, API Gateway, Lambda, S3 Raw/Processed buckets, EventBridge, SQS with DLQ, Step Functions Standard Workflow, Textract, AI Proxy Lambda, External AI API, DynamoDB, CloudWatch, X-Ray, SNS/SES, IAM, KMS, Secrets Manager, CloudTrail, Budgets và SAM. + +#### Dịch vụ AWS sử dụng + +Các dịch vụ dưới đây được nhóm theo layer kiến trúc. Mỗi dòng map trực tiếp với bảng Ước tính ngân sách ở Section 6. + +**Identity & Security** + +- Amazon Cognito: User Pool có groups (end-user, reviewer, admin), dùng làm Cognito User Pool authorizer cho mọi endpoint API Gateway. +- AWS IAM: Role least-privilege riêng cho từng Lambda function và một execution role riêng cho Step Functions; không dùng role admin chia sẻ. +- AWS KMS: AWS-managed keys (`aws/s3`, `aws/dynamodb`, `aws/sqs`) cho encryption at rest; không dùng customer-managed key để giữ chi phí $0. +- AWS Secrets Manager: Lưu External AI API key bên ngoài source code và frontend code. Lambda chỉ lưu secret name trong environment variable. +- AWS CloudTrail: Cung cấp audit visibility cho AWS account activity và các thay đổi resource của project. + +**Frontend Delivery** + +- Amazon CloudFront + AWS Amplify: CloudFront cung cấp secure/scalable entry point cho người dùng, còn Amplify host và deploy React/Vite single-page app với Git-based CI/CD, managed HTTPS, preview deployments và custom domain tùy chọn. + +**API & Compute** + +- Amazon API Gateway (REST): Các endpoint `POST /documents/upload-url`, `GET /documents`, `GET /documents/{id}`, đều được Cognito authorizer bảo vệ. +- AWS Lambda: Bảy function Node.js 20.x ở mức 256 MB — `generateUploadUrl`, `jobStarter`, `validateDocument`, `textractExtraction`, `aiProxyNormalization`, `confidenceStatus`, `statusApi`. Notification logic có thể tách thành Lambda riêng hoặc là task trong workflow tùy SAM template cuối cùng. + +**Storage** + +- Amazon S3: Hai bucket — `docuflow-raw` (Block Public Access, SSE-KMS, lifecycle expire sau 60 ngày) và `docuflow-processed` (bật versioning, chuyển STANDARD-IA sau 30 ngày). +- Amazon DynamoDB: Bảng on-demand `Documents` với PK `documentId` và GSI trên `userId`+`status` phục vụ dashboard người dùng; lưu metadata, status, confidence score, normalized fields, AI provider/model metadata, S3 paths và error codes. + +**Eventing & Workflow** + +- Amazon EventBridge: Default bus nhận S3 `Object Created` events và route sang SQS. +- Amazon SQS: Standard queue + Dead-Letter Queue (tối đa 3 retry) để đệm spike và cô lập poison message. +- AWS Step Functions (Standard Workflow): State machine validate document metadata và file type, chạy Textract `AnalyzeExpense`, gọi AI Proxy Lambda, chạy confidence/status logic, lưu metadata vào DynamoDB, lưu processed JSON vào S3, và route tài liệu confidence thấp hoặc lỗi sang `REVIEW_REQUIRED` hoặc `FAILED`. + +**AI Services** + +- Amazon Textract `AnalyzeExpense`: API chuyên cho invoice và receipt; trả về `SUMMARY_FIELDS` và `LINE_ITEM_FIELDS` để bước External AI normalization xử lý tiếp. +- AI Proxy Lambda + External AI API: AI Proxy Lambda bảo vệ và kiểm soát call sang external AI service. Lambda nhận output Textract, đọc API key từ Secrets Manager, chỉ gửi extracted fields/text sang provider, validate response, và trả normalized JSON về workflow. + +**Observability & Notification** + +- Amazon CloudWatch: Logs, Metrics, Alarms và Logs Insights cho Lambda, Step Functions, SQS DLQ, Textract, AI Proxy timeout/rate-limit, low-confidence documents và cost-related operational signals. +- AWS X-Ray: Trace visibility qua API Gateway, Lambda và workflow components khi được enable. +- Amazon SNS + Amazon SES: SNS topics và SES email notifications cảnh báo team khi processing fail hoặc confidence thấp. + +**Operations & Cost** + +- AWS SAM: Một SAM template duy nhất cho mỗi environment để deploy có thể tái lập và teardown sạch thông qua CloudFormation. +- AWS Budgets: Email alert ở ngưỡng $5 và $10 hàng tháng đã định nghĩa ở Section 6. + +#### Luồng xử lý end-to-end + +Happy path cho một invoice hoặc receipt đi qua hệ thống như sau: + +1. **Mở frontend** — Người dùng truy cập web app qua CloudFront và Amplify. +2. **Đăng nhập** — Người dùng xác thực qua Cognito và nhận JWT cho các API call sau. +3. **Xin upload slot** — Frontend gửi authenticated API request tới API Gateway. Lambda `generateUploadUrl` sinh `documentId`, ghi DynamoDB record ban đầu, và trả presigned URL S3 ngắn hạn. +4. **Upload trực tiếp lên S3 Raw Bucket** — Browser upload invoice hoặc receipt trực tiếp lên S3; document bytes không đi qua API Gateway hay Lambda. +5. **Queue processing job** — S3 ObjectCreated event được route qua EventBridge vào SQS; status chuyển từ `UPLOADED` sang `QUEUED`. +6. **Start workflow** — Job Starter Lambda poll SQS và start Step Functions Standard Workflow; status chuyển sang `PROCESSING`. +7. **Validate và extract** — Step Functions gọi Validate Lambda, sau đó chạy Textract `AnalyzeExpense` để trích xuất invoice/receipt fields. +8. **Normalize qua AI Proxy** — AI Proxy Lambda đọc External AI API key từ Secrets Manager, gửi minimized Textract fields sang external AI provider, validate response, và trả normalized JSON. +9. **Tính confidence và status** — Confidence + Status Lambda quyết định tài liệu là `EXTRACTED`, `REVIEW_REQUIRED` hay `FAILED`. +10. **Lưu kết quả** — Metadata và status được lưu vào DynamoDB, processed `result.json` được lưu vào S3 Processed Bucket. +11. **Alert và observe** — SNS/SES gửi alert cho tài liệu fail hoặc confidence thấp. CloudWatch và X-Ray cung cấp logs, metrics, alarms, execution visibility và traces. +12. **Review và approve** — Frontend hiển thị document list, status, result và review flow; user có thể chuyển kết quả đã sửa sang `CORRECTED` và kết quả cuối sang `APPROVED`. + +Các đường lỗi được xử lý qua Catch branches của Step Functions và retry/DLQ của SQS, không dùng try/catch rải rác trong Lambda. Khi state bất kỳ catch lỗi, workflow chuyển sang `MarkFailed` (hoặc `MarkReviewRequired` cho trường hợp confidence thấp / schema lỗi) và DynamoDB status được cập nhật tương ứng. Các lỗi ingestion xảy ra trước khi Step Functions chạy được hấp thụ bởi SQS retry và rơi vào DLQ. + +### 4. Triển khai kỹ thuật + +#### Các giai đoạn triển khai + +Dự án chạy theo bốn giai đoạn ngắn. Section 5 chia mỗi giai đoạn thành các tuần cụ thể. + +1. **Thiết kế** — Khóa MVP scope, vẽ kiến trúc và định nghĩa data contract. +2. **Ước tính** — Chạy AWS Pricing Calculator và chốt mức chi phí workshop. +3. **Tinh chỉnh** — Điều chỉnh workflow boundaries, confidence threshold và log retention cho nhóm 5 người. +4. **Build, test, deploy** — Triển khai, test end-to-end, thu thập evidence và verify cleanup. + +#### Yêu cầu kỹ thuật + +- Frontend: Single-page web app delivered qua CloudFront và deploy bằng AWS Amplify, có login, upload, document list, status/result pages, review/correction flow, managed HTTPS và branch-based deployments. +- Authentication: Cognito user pool với ba groups — `end-user`, `reviewer`, `admin` — gắn vào API Gateway dưới dạng Cognito authorizer. +- Document Input: Invoice/receipt dạng PDF, JPG hoặc PNG được upload qua presigned URL TTL 5 phút, với pre-validate ở frontend cho file type, size (≤10 MB) và page count. +- Processing: Step Functions Standard Workflow với Lambda task chạy Node.js 20.x ở mức 256 MB, Validate Lambda, Textract `AnalyzeExpense`, AI Proxy Lambda, Confidence + Status Lambda, JSON schema validation, Retry/Catch trên mỗi state, và status transitions rõ ràng. +- Status Model: `UPLOADED` → `QUEUED` → `PROCESSING` → `EXTRACTED` / `REVIEW_REQUIRED` / `FAILED` → `CORRECTED` → `APPROVED`. +- Data Model: DynamoDB table `Documents` với PK `documentId` và GSI trên `userId`+`status`. Item attributes: `documentId`, `userId`, `fileName`, `documentType`, `status`, normalized fields, `confidenceScore`, `reviewReasons`, `aiProvider`, `normalizationMethod`, `s3RawPath`, `s3ProcessedPath`, `errorCode`, `createdAt`, `updatedAt`. +- Observability: CloudWatch Logs (retention 7 ngày), Metrics và Alarms trên Lambda errors, Step Functions failed executions, SQS DLQ depth, Textract errors, AI Proxy timeout/rate-limit count, invalid AI response count và low-confidence document count; X-Ray traces qua API, Lambda và workflow components khi được enable. +- Security: Không public S3 bucket (Block Public Access), không hard-code key, IAM role theo least privilege cho mỗi Lambda, AWS KMS managed keys cho encryption at rest, presigned URL TTL ngắn, External AI API key lưu trong Secrets Manager, mặc định không gửi raw PDF/image sang external AI provider, CloudTrail enabled cho audit visibility, AWS Budgets cho spending governance, và có SAM cleanup script. +- Infrastructure as Code: Một AWS SAM stack duy nhất cho mỗi environment provision toàn bộ resource ở trên và hỗ trợ teardown sạch. +- Reporting Deliverables: Test cases, screenshots cho mỗi status transition, demo recording và workshop instructions song ngữ. + +#### Data Contract và External AI Payload + +Tất cả module dùng chung một JSON contract để frontend, workflow, storage, API response và analytics không lệch nhau: + +```json +{ + "documentId": "doc-001", + "userId": "user-123", + "fileName": "invoice-001.pdf", + "documentType": "INVOICE", + "status": "EXTRACTED", + "vendorName": "ABC Company", + "invoiceDate": "2026-06-01", + "currency": "VND", + "totalAmount": 2500000, + "taxAmount": 250000, + "confidenceScore": 0.91, + "reviewReasons": [], + "aiProvider": "external-ai-api", + "normalizationMethod": "TEXTRACT_PLUS_AI_PROXY_EXTERNAL_API", + "s3RawPath": "s3://docuflow-dev-raw-bucket/raw/user-123/doc-001/original.pdf", + "s3ProcessedPath": "s3://docuflow-dev-processed-bucket/processed/user-123/doc-001/result.json", + "createdAt": "2026-06-08T10:00:00Z", + "updatedAt": "2026-06-08T10:01:00Z" +} +``` + +External AI API chỉ nhận payload đã rút gọn: + +```json +{ + "documentId": "doc-001", + "fileName": "invoice-001.pdf", + "textractSummaryFields": [ + { + "type": "VENDOR_NAME", + "text": "ABC Company", + "confidence": 0.96 + }, + { + "type": "TOTAL", + "text": "2,500,000 VND", + "confidence": 0.93 + } + ], + "textractLineItems": [], + "rawTextPreview": "Invoice ABC Company total 2,500,000 VND..." +} +``` + +Payload không được chứa raw PDF files, raw images, API keys, AWS credentials, full documents khi không cần thiết hoặc thông tin nhạy cảm không liên quan. AI Proxy Lambda validate response phải là JSON hợp lệ, `documentType` thuộc `INVOICE`, `RECEIPT` hoặc `UNKNOWN`, `totalAmount` là number, `invoiceDate` theo ISO-8601 khi có, `confidenceScore` nằm trong khoảng 0 đến 1, và các field confidence thấp hoặc thiếu phải được thể hiện trong `reviewReasons`. + +#### Technology Stack + +Stack dưới đây bổ trợ cho danh sách AWS services ở section 3. Đây là toolset code-level cụ thể mà team dùng để build, test, deploy và document nền tảng. + +**Frontend** + +| Layer | Choice | Notes | +|---|---|---| +| Language | TypeScript 5 | Share type với backend qua workspace package | +| Framework | React 18 | SPA delivered qua CloudFront và deploy bằng Amplify | +| Build tool | Vite | HMR nhanh, zero-config TypeScript | +| Auth | `amazon-cognito-identity-js` | Cognito SDK chính thức, gọn nhẹ; giao tiếp với User Pool ở section 3 | +| API client | `axios` + `@tanstack/react-query` | Axios interceptor gắn JWT của Cognito; TanStack Query cache server state | +| UI | shadcn/ui + Tailwind CSS | Component primitive, không vendor lock | +| Forms | React Hook Form + Zod | Schema Zod reuse được ở backend | +| Routing | React Router v6 | | +| Testing | Vitest (unit) | E2E nằm ngoài scope workshop | + +**Backend Lambda** + +| Layer | Choice | Notes | +|---|---|---| +| Runtime | Node.js 20.x ở 256 MB | Như đã chốt ở section 3 và 4 | +| Language | TypeScript 5 | Compile bằng esbuild qua SAM | +| AWS SDK | AWS SDK v3 modular | `client-s3`, `s3-request-presigner`, `client-dynamodb`, `lib-dynamodb`, `client-textract`, `client-secrets-manager`, `client-sns`, `client-sfn` | +| External API client | `fetch` / `undici` với timeout và retry limits | Chỉ gọi External AI API từ AI Proxy Lambda | +| Validation | Ajv (JSON Schema) + Zod | Ajv enforce JSON contract của AI Proxy; Zod validate HTTP payload | +| Observability | AWS Lambda Powertools for TypeScript + X-Ray SDK | Structured logs, custom metrics, tracing | +| Testing | Vitest + `aws-sdk-client-mock` | | + +**Infrastructure & DevOps** + +| Concern | Choice | Notes | +|---|---|---| +| IaC | AWS SAM | Dùng CloudFormation transform; teardown qua `sam delete` hoặc `aws cloudformation delete-stack` theo contingency ở section 7 | +| Local Lambda | AWS SAM CLI (`sam local invoke`, `sam local start-api`) | | +| External AI API | Provider/model cấu hình qua environment variables | API key lưu trong Secrets Manager; mặc định không gửi raw files | +| Monorepo | pnpm workspaces | | +| Linting | ESLint + Prettier | Một config chung cho `apps/*`, `services/*`, `packages/*` | +| Secrets scan | gitleaks pre-commit hook | Chặn commit nhầm key | +| CI/CD | Amplify Hosting cho frontend; GitHub Actions với OIDC → IAM role cho backend | Jobs: `lint-test` khi PR, `deploy-dev` khi push `main`, `deploy-prod` khi tag `v*` | +| Documentation | Hugo + Learn theme (repo hiện tại) | Song ngữ EN/VI, diagrams bằng draw.io | + +**Repository Layout** + +```text +docuflow-ai/ +├── frontend/ +│ └── src/ # Frontend React + Vite deploy bằng Amplify +├── backend/ +│ ├── functions/ +│ │ ├── upload-url/ +│ │ ├── job-starter/ +│ │ ├── textract-extraction/ +│ │ ├── ai-proxy-normalization/ +│ │ ├── confidence-status/ +│ │ ├── status-api/ +│ │ └── notification/ +│ └── shared/ +│ ├── schema/ # JSON schema và Zod DTOs +│ └── utils/ +├── infrastructure/ +│ ├── template.yaml # SAM root template +│ └── parameters/{dev,demo}.json +├── docs/ +│ ├── architecture/ +│ ├── test-evidence/ +│ └── demo-script.md +└── samples/ + ├── invoices/ + └── receipts/ +``` + +Các folder Lambda function khớp với trách nhiệm đã khai báo ở section 3, và shared schema giúp cùng một data contract được áp dụng cho upload, normalization, storage, API response và analytics modules. + +#### Phân công trách nhiệm nhóm + +| Thành viên | Vai trò | Trách nhiệm chính | +|---|---|---| +| Hoàng Trọng Trà | Leader / Integration Owner | Ingestion, EventBridge, SQS, Job Starter Lambda, Step Functions, integration flow | +| Vũ Duy Tài | AI Owner | Textract, AI Proxy Lambda, External AI API normalization, confidence/status logic | +| Nguyễn Hữu Tịnh | Frontend/Auth Owner | CloudFront, Amplify, Cognito, API Gateway integration, upload/result/review UI | +| Lâm Quang Lộc | Data Owner | DynamoDB, S3 processed JSON, metadata schema, document result management | +| Phạm Tùng Dương | Ops/Security/IaC Owner | IAM, KMS, Secrets Manager, CloudTrail, Budgets, SAM, CloudWatch, X-Ray, SNS/SES | + +### 5. Tiến độ & Cột mốc + +#### Tiến độ dự án + +- Tuần 1: Nghiên cứu yêu cầu FCAJ, chốt MVP scope, định nghĩa data contract và vẽ architecture. +- Tuần 2-3: Xây nền tảng: Cognito, frontend hosting, API Gateway, Lambda upload API, S3 buckets và DynamoDB table. +- Tuần 4-5: Xây ingestion và workflow: EventBridge, SQS, Step Functions, retry/catch handling và status transitions. +- Tuần 6-7: Xây AI extraction và normalization: Textract processing, AI Proxy Lambda, External AI API integration, Secrets Manager secret retrieval, JSON schema validation, confidence/status logic và result storage. +- Tuần 8: Xây result và review UI: document list, document detail page, extracted-field display, correction flow, approval flow và status tracking. +- Tuần 9-10: Bổ sung observability, security, governance và IaC: CloudWatch logs/metrics/alarms, X-Ray tracing, SNS/SES alerts, IAM review, KMS encryption, CloudTrail, External AI API retry limits, AWS Budgets và hợp nhất stack SAM theo environment. +- Tuần 11: Chạy test cases, chụp screenshots, chuẩn bị workshop instructions và verify cleanup. +- Tuần 12: Hoàn thiện nội dung song ngữ, final demo flow, budget estimate và submission materials. + +### 6. Ước tính ngân sách + +Ngân sách hướng đến workload quy mô workshop mà nhóm 5 người có thể chạy end-to-end và phần lớn vẫn nằm trong AWS Free Tier. Bạn có thể tạo và cập nhật estimate chính thức bằng [AWS Pricing Calculator](https://calculator.aws/#/). + +#### Giả định + +Ước tính dùng baseline dưới đây để mỗi dòng chi phí đều có thể tái lập: + +- Region: `ap-southeast-1` (Singapore — region AWS gần Việt Nam nhất, độ trễ thấp cho người dùng cuối tại VN; giá nhỉnh hơn `us-east-1` ở CloudWatch, DynamoDB, API Gateway và Step Functions, nhưng vẫn nằm trong ngân sách workshop). +- Document volume: 100 file invoice/receipt mỗi tháng, trung bình 2 trang/file (khoảng 200 trang/tháng). +- External AI API usage: 100 normalization requests/tháng qua AI Proxy Lambda, chỉ gửi text/fields và line items đã rút gọn từ Textract. Team đặt provider-side usage cap nếu có và kiểm tra pricing thật trước khi chạy demo. +- API traffic: khoảng 5,000 REST API calls/tháng cho các endpoint upload-url, list-documents và document-status. +- Storage: 1 GB raw documents và 0.5 GB processed JSON/CSV. +- Logs: khoảng 500 MB CloudWatch log ingestion/tháng với retention 7 ngày. +- Users: 5–10 monthly active Cognito users (nằm sâu trong always-free 50,000 MAU). +- Step Functions: 100 Standard-workflow executions/tháng, khoảng 9 states cho mỗi document. + +#### Bảng chi phí hàng tháng + +| Dịch vụ | Giả định usage | Chi phí/tháng (USD) | +|---|---|---| +| Amazon Textract `AnalyzeExpense` | 200 trang | $2.00 | +| External AI API | 100 normalization requests, payload rút gọn | $0.00 – $2.00 tùy provider | +| AWS Secrets Manager | 1 external API secret | $0.40 | +| AWS Lambda | ~1,200 invocations, 256 MB, ~500 ms | $0.00 – $0.10 | +| Amazon API Gateway (REST) | ~5,000 calls | $0.02 – $0.03 | +| Amazon S3 | 1.5 GB Standard + ít request | $0.03 – $0.10 | +| Amazon DynamoDB (on-demand) | 1,000 writes + 5,000 reads, < 1 GB storage | $0.05 – $0.30 | +| Amazon EventBridge + Amazon SQS | ~100 events, queue volume thấp | $0.00 – $0.10 | +| AWS Step Functions Standard | 100 executions × ~9 states | $0.00 – $0.10 | +| Amazon CloudWatch + AWS X-Ray | ~500 MB logs, retention 7 ngày, traces, ~5 alarms | $0.60 – $1.40 | +| Amazon SNS/SES | ~100 alerts | $0.00 – $0.10 | +| Amazon Cognito | 5–10 MAU (free tier cover 50k) | $0.00 | +| Amazon CloudFront + AWS Amplify Hosting | static React build, demo traffic thấp, build không thường xuyên | $0.00 – $1.00 | +| AWS CloudTrail + AWS Budgets | management events và spending alerts | $0.00 | +| **Tổng** | | **$3.50 – $8.00** | + +Quy ra năm: khoảng **$42 – $96 cho 12 tháng**. Con số dao động theo region, số trang Textract, pricing của External AI API provider, số lần retry, kích thước token/payload và retention CloudWatch/X-Ray. AWS SAM/CloudFormation (deployment) và AWS Budgets (cost alerts) cũng được dùng và giữ ở mức **$0.00** trong free usage limits. + +#### Ảnh hưởng từ Free Tier + +Free Tier phụ thuộc vào ngày tạo account và account plan đang chọn. Account tạo trước ngày 15/07/2025 vẫn có thể theo mô hình legacy 12-month Free Tier, còn account mới hơn có thể dùng AWS Free Tier plan và credits hiện tại. Trước khi chạy workshop, team sẽ kiểm tra Free Tier status thật trong AWS Billing và giữ AWS Budgets alert ở ngưỡng $5 và $10. + +Với workload này, một số dịch vụ vẫn có thể miễn phí hoặc gần như miễn phí ở quy mô workshop, như Lambda, DynamoDB, SNS, Cognito, CloudFront và Amplify static hosting. API Gateway, S3 storage, CloudWatch logs/alarms, X-Ray traces, Step Functions và Amplify build minutes/data transfer cần được kiểm tra theo Free Tier và pricing page thực tế của account, thay vì mặc định xem là miễn phí. + +Textract và External AI API **không** được giả định là nằm trong AWS Free Tier ở proposal này, nên team phải kiểm tra trực tiếp cả hai loại chi phí và giữ ngân sách workshop hàng tháng ở mức tối đa **$10**. + +#### Kịch bản scale + +Nếu workload tăng 10× lên 1,000 documents và 2,000 trang/tháng, Textract scale tuyến tính tới khoảng $20/tháng và External AI API scale theo pricing provider, số lần retry và payload size. Các dịch vụ còn lại vẫn ở mức hiện tại, đưa phần AWS-side platform về khoảng **$25 – $40/tháng** trước khi tính provider-specific AI charges. + +#### Kiểm soát chi phí + +- Đặt AWS Budgets alert ở ngưỡng $5 và $10 với email notification. +- CloudWatch log retention 7 ngày; metric filters chỉ giữ các metric cần cho workflow. +- Cap External AI API request bằng payload size, retry count, timeout và provider-side spending/usage limits nếu có. +- S3 lifecycle: expire raw uploads sau 60 ngày, chuyển processed JSON sang STANDARD-IA sau 30 ngày. +- File mẫu Textract giới hạn ≤ 5 trang/file trong giai đoạn phát triển. +- Step Functions per-task timeout 30 giây để tránh execution chạy lan. +- Cleanup cuối workshop chạy `aws cloudformation delete-stack` (hoặc `sam delete`) trên backend workshop stack, sau đó xoá Amplify app/branches và kiểm tra CloudFront distribution trong Amplify console hoặc CLI. Tổng thể cleanup sẽ xoá Cognito User Pool, S3 buckets, DynamoDB table, Step Functions state machine, API Gateway, Lambda functions, EventBridge rules, SQS queues, SNS topic, SES notification resources, IAM roles, CloudWatch log groups và frontend hosting resources. +- CloudTrail, Budgets, X-Ray, SNS và SES được giữ trong phạm vi workshop hẹp để có governance/evidence mà không tạo chi phí mở. + +### 7. Đánh giá rủi ro + +#### Ma trận rủi ro + +Severity = impact × probability theo thang 1–3 (tối đa 9). Owner là module workshop chịu trách nhiệm cho mitigation. + +| ID | Risk | Impact | Probability | Severity | Owner | +|---|---|---|---|---|---| +| R-01 | Scope creep vượt khỏi MVP invoice/receipt | High (3) | Medium (2) | 6 | Tech lead | +| R-02 | Textract accuracy thấp trên scan kém | High (3) | Medium (2) | 6 | AI module | +| R-03 | External AI API trả JSON sai cấu trúc / sai schema | Medium (2) | Medium (2) | 4 | AI module | +| R-04 | Workflow bất đồng bộ lỗi (Step Functions / SQS) | High (3) | Low (1) | 3 | Workflow module | +| R-05 | Cost overrun vượt ngân sách $10/tháng | Medium (2) | Low (1) | 2 | IaC/Ops module | +| R-06 | IAM cấu hình sai làm lộ dữ liệu | High (3) | Low (1) | 3 | Security module | +| R-07 | External AI API timeout, rate limit hoặc outage | Medium (2) | Medium (2) | 4 | AI module | +| R-08 | Presigned URL bị lộ từ frontend hoặc log | High (3) | Low (1) | 3 | Frontend / Security | +| R-09 | Document edge case (scan low-DPI, file mã hóa, quá lớn) | Medium (2) | Medium (2) | 4 | AI module | +| R-10 | Dữ liệu tài liệu nhạy cảm bị gửi không cần thiết sang external provider | High (3) | Low (1) | 3 | Security / AI module | +| R-11 | External AI API key bị lộ hoặc thiếu | High (3) | Low (1) | 3 | Security / IaC module | + +#### Chiến lược giảm thiểu + +- **R-01 (Scope)**: Khóa MVP chỉ ở invoice và receipt; mọi loại tài liệu mới phải qua change-request review trước khi vào backlog. +- **R-02 (Extraction)**: Dùng sample documents rõ trong dev, đặt confidence threshold 0.7, kết quả thấp confidence chuyển sang `REVIEW_REQUIRED` cho luồng review thủ công. +- **R-03 (External AI JSON)**: Prompt/instruction nghiêm ngặt với JSON-only contract, JSON schema validation trong normalization Lambda, retry tự động 1 lần, sau đó đánh dấu `REVIEW_REQUIRED` nếu cấu trúc vẫn không hợp lệ. +- **R-04 (Workflow)**: Catch states trên mỗi task của Step Functions, SQS Standard queue với DLQ retry 3 lần, CloudWatch alarm trên DLQ depth, và DynamoDB status transitions rõ ràng. +- **R-05 (Cost)**: AWS Budgets alert ở $5 và $10, CloudWatch log retention 7 ngày, External AI API request/retry caps, provider-side spending limit nếu có, S3 lifecycle policy, và giới hạn Textract sample ≤5 trang/file trong dev. +- **R-06 (IAM)**: Mỗi Lambda function có IAM role riêng, Step Functions execution role tách khỏi task role, dùng AWS KMS managed keys cho storage, bật S3 Block Public Access trên mọi bucket, và review định kỳ bằng IAM Access Analyzer. +- **R-07 (External API availability)**: Retry với exponential backoff khi timeout/rate-limit, giới hạn số retry, emit CloudWatch metrics, sau đó mark `REVIEW_REQUIRED` hoặc `FAILED` thay vì chặn toàn bộ workflow. +- **R-08 (Presigned URL)**: TTL 5 phút mỗi URL, mỗi URL scope đúng 1 object key, không log URL đầy đủ, và lọc URL ra khỏi client-side error report. +- **R-09 (Edge cases)**: Frontend pre-validate file type, size (≤10 MB) và page count; backend trả lỗi có cấu trúc và ghi file vào prefix S3 `quarantine/` để xử lý thủ công. +- **R-10 (Data minimization)**: Chỉ gửi extracted text/fields và raw text preview ngắn khi cần; không gửi raw PDF/image files, AWS credentials, API keys hoặc field nhạy cảm không liên quan sang external provider. +- **R-11 (Secret handling)**: Lưu External AI API key trong Secrets Manager, chỉ cấp quyền read secret cụ thể cho AI Proxy Lambda, không log key, và rotate key nếu nghi ngờ bị lộ. + +#### Kế hoạch dự phòng + +- **R-02 / R-03 demo failure**: Dùng prepared sample extraction result để trình bày status/result UI đồng thời show failed Step Functions execution history để minh bạch. +- **R-04 backlog tăng**: Dừng upload, kiểm tra SQS và DLQ, replay chỉ 1 batch mẫu nhỏ sau khi fix root cause. +- **R-05 cost spike**: Dừng test upload, disable External AI API key hoặc hạ provider usage limits, hạ CloudWatch retention xuống 1 ngày, dọn raw/processed buckets, và chạy `delete-stack` của CloudFormation nếu cần. +- **R-06 IAM exposure**: Rotate credential bị lộ, disable role bị ảnh hưởng, re-deploy stack từ commit sạch. +- **R-07 External AI API outage**: Route tài liệu bị ảnh hưởng sang `REVIEW_REQUIRED`, show Step Functions execution history, và chỉ dùng prepared normalized JSON cho demo UI nếu provider vẫn unavailable. +- **R-08 URL leak**: Vô hiệu hóa credential đang active của user, re-issue presigned URL, audit Amplify access logs / API Gateway logs để tìm pattern URL bị lộ. +- **R-10 / R-11 data hoặc key exposure**: Dừng external API calls, rotate provider key, kiểm tra CloudWatch logs để tìm dữ liệu lộ, và chỉ bật lại sau khi verify payload minimization và log redaction. + +### 8. Kết quả kỳ vọng + +#### Cải thiện kỹ thuật + +DocuFlow AI thay thế nhập liệu invoice/receipt thủ công bằng workflow xử lý tài liệu serverless. Hệ thống cung cấp secure upload, Textract extraction tự động, External AI API normalization qua AI Proxy Lambda, schema validation, metadata storage, status tracking, notifications, operational logs, audit visibility và cost governance. + +#### Tiêu chí thành công + +Workshop được xem là hoàn thành khi từng tiêu chí sau có evidence: + +- Field-level extraction accuracy ≥ 90% cho các summary fields bắt buộc trên test set 20 invoice/receipt mẫu được chuẩn bị sẵn. Các field bắt buộc gồm `vendorName`, `invoiceDate`, `totalAmount`, `taxAmount` và `currency`; line-item extraction được xem là bonus evidence vì biến động nhiều hơn theo format tài liệu. +- End-to-end processing latency ≤ 60 giây ở mức 95th percentile. +- Chi phí AWS hàng tháng của workshop ≤ **$10**, verify qua AWS Budgets và Cost Explorer. +- Mỗi Lambda function có IAM role riêng theo least-privilege; không role nào được chia sẻ. +- Các status path chính của DynamoDB đều có screenshots: `UPLOADED`, `QUEUED`, `PROCESSING`, `EXTRACTED`, `REVIEW_REQUIRED`, `FAILED`, `CORRECTED`, `APPROVED`. +- Step Functions chạy đủ các bước validate, Textract, AI Proxy, confidence/status và save-result. +- External AI API key được lưu trong Secrets Manager, không nằm trong source code, frontend code, logs hoặc API responses. +- Payload gửi sang External AI chỉ chứa output Textract đã rút gọn; raw PDF/image files mặc định không gửi sang external provider. +- Có CloudWatch logs/alarms, X-Ray trace evidence, SNS/SES alert evidence, CloudTrail audit evidence và Budgets screenshot. +- Stack SAM/CloudFormation deploy sạch từ tài khoản mới và teardown sạch, không cần dọn thủ công. +- Báo cáo song ngữ (EN/VI) cover đủ tám module workshop trong `5-Workshop`. + +#### Giá trị dài hạn + +Dự án tạo nền tảng tái sử dụng cho xử lý chứng từ tài chính trên AWS. Các nhóm sau có thể mở rộng cùng pattern này cho nhiều loại tài liệu hơn, validation rules chặt hơn, reporting đầy đủ hơn và tích hợp sâu hơn với hệ thống finance. Với FCAJ, workshop thể hiện cách dùng thực tế các AWS serverless services, AI-assisted document processing, external API security, audit visibility, cost control, observability và cleanup trong một giải pháp thống nhất. diff --git a/content/3-BlogsTranslated/3.1-Blog1/_index.md b/content/3-BlogsTranslated/3.1-Blog1/_index.md index eefafa2..e1c53dc 100644 --- a/content/3-BlogsTranslated/3.1-Blog1/_index.md +++ b/content/3-BlogsTranslated/3.1-Blog1/_index.md @@ -5,122 +5,164 @@ weight: 1 chapter: false pre: " 3.1. " --- -{{% notice warning %}} -⚠️ **Note:** The information below is for reference purposes only. Please **do not copy verbatim** for your report, including this warning. -{{% /notice %}} -# Getting Started with Healthcare Data Lakes: Using Microservices +# Cyber Resilience on AWS: A Reference Approach for Recovery from Ransomware and Destructive Events -Data lakes can help hospitals and healthcare facilities turn data into business insights, maintain business continuity, and protect patient privacy. A **data lake** is a centralized, managed, and secure repository to store all your data, both in its raw and processed forms for analysis. Data lakes allow you to break down data silos and combine different types of analytics to gain insights and make better business decisions. +## References -This blog post is part of a larger series on getting started with setting up a healthcare data lake. In my final post of the series, *“Getting Started with Healthcare Data Lakes: Diving into Amazon Cognito”*, I focused on the specifics of using Amazon Cognito and Attribute Based Access Control (ABAC) to authenticate and authorize users in the healthcare data lake solution. In this blog, I detail how the solution evolved at a foundational level, including the design decisions I made and the additional features used. You can access the code samples for the solution in this Git repo for reference. +- AWS Architecture Blog: [Cyber resilience on AWS: A reference approach for recovery from ransomware and destructive events](https://aws.amazon.com/vi/blogs/architecture/cyber-resilience-on-aws-a-reference-approach-for-recovery-from-ransomware-and-destructive-events/) +- Authors: Ashish Panwar, Kanniah Vagathupatti Jaikumar, and Rakesh Singh +- Published: May 20, 2026 ---- +## Overview -## Architecture Guidance +When discussing security, it is common to focus on prevention and detection: keeping attackers out and finding suspicious activity quickly. The AWS blog highlights another important area: **cyber resilience**, which is the ability to recover workloads to a trustworthy state after ransomware, data extortion, or destructive cyber events. -The main change since the last presentation of the overall architecture is the decomposition of a single service into a set of smaller services to improve maintainability and flexibility. Integrating a large volume of diverse healthcare data often requires specialized connectors for each format; by keeping them encapsulated separately as microservices, we can add, remove, and modify each connector without affecting the others. The microservices are loosely coupled via publish/subscribe messaging centered in what I call the “pub/sub hub.” +The main idea I learned from this post is that recovery cannot assume everything is still trusted. After a serious incident, the production environment, credentials, backups, and even the recovery path may have been targeted. Therefore, a good recovery strategy is not only about having backups. It also needs protected backup storage, an isolated recovery environment, validation before restore, and a clear decision process for choosing a safe recovery point. -This solution represents what I would consider another reasonable sprint iteration from my last post. The scope is still limited to the ingestion and basic parsing of **HL7v2 messages** formatted in **Encoding Rules 7 (ER7)** through a REST interface. +## Problem Context -**The solution architecture is now as follows:** +For critical workloads on AWS, ransomware can create more risk than encrypted data alone. An attacker may attempt to delete backups, change configurations, steal credentials, or leave malicious changes in the environment before the incident is detected. -> *Figure 1. Overall architecture; colored boxes represent distinct services.* +If a team restores the latest backup without validating it, the restored environment may still contain the same issue that caused the incident. This is especially risky when the attacker was present before detection and recent backups were created during that compromise window. ---- +A cyber recovery plan should answer several practical questions: -While the term *microservices* has some inherent ambiguity, certain traits are common: -- Small, autonomous, loosely coupled -- Reusable, communicating through well-defined interfaces -- Specialized to do one thing well -- Often implemented in an **event-driven architecture** +- Are backups protected from deletion or shortened retention? +- Is the recovery environment isolated from the compromised production environment? +- How can the team identify which recovery point is safe to use? +- Which components should be rebuilt from code, restored from backup, or generated fresh? -When determining where to draw boundaries between microservices, consider: -- **Intrinsic**: technology used, performance, reliability, scalability -- **Extrinsic**: dependent functionality, rate of change, reusability -- **Human**: team ownership, managing *cognitive load* +## Reference Recovery Architecture ---- +The AWS blog describes a three-account pattern inside AWS Organizations. -## Technology Choices and Communication Scope +![Isolated Recovery Environment](/images/3-BlogsTranslated/Blog1/IsolatedRecoveryEnvironment(IRE).png) -| Communication scope | Technologies / patterns to consider | -| ----------------------------------------- | ------------------------------------------------------------------------------------------ | -| Within a single microservice | Amazon Simple Queue Service (Amazon SQS), AWS Step Functions | -| Between microservices in a single service | AWS CloudFormation cross-stack references, Amazon Simple Notification Service (Amazon SNS) | -| Between services | Amazon EventBridge, AWS Cloud Map, Amazon API Gateway | +*Source: AWS Architecture Blog - Cyber resilience on AWS* ---- +### Production Account -## The Pub/Sub Hub +The production account is where the workload normally runs. After a confirmed cyber event, this account should be isolated for investigation. Recovery should not happen directly in the old production environment because its identities, network paths, or configurations may no longer be fully trusted. -Using a **hub-and-spoke** architecture (or message broker) works well with a small number of tightly related microservices. -- Each microservice depends only on the *hub* -- Inter-microservice connections are limited to the contents of the published message -- Reduces the number of synchronous calls since pub/sub is a one-way asynchronous *push* +### Recovery Account -Drawback: **coordination and monitoring** are needed to avoid microservices processing the wrong message. +The recovery account manages critical backups, especially the **AWS Backup logically air-gapped vault**. This vault protects recovery points from deletion during the retention period, even if a root user or administrator account is compromised. ---- +This account should be restricted with Service Control Policies (SCPs) and focused on backup and restore operations. By separating backup controls from production, a compromised production identity cannot easily change or delete protected recovery points. -## Core Microservice +One important detail is that the logically air-gapped vault is designed around the idea that recovery points must remain available long enough for investigation and recovery. It uses strict protection so recovery points cannot be deleted or have their retention shortened during the configured retention period. For Amazon S3 data, the article also mentions a similar protection pattern using **S3 Versioning** and **S3 Object Lock in Compliance mode** to protect object versions from unwanted deletion or overwrite. -Provides foundational data and communication layer, including: -- **Amazon S3** bucket for data -- **Amazon DynamoDB** for data catalog -- **AWS Lambda** to write messages into the data lake and catalog -- **Amazon SNS** topic as the *hub* -- **Amazon S3** bucket for artifacts such as Lambda code +### Isolated Recovery Environment (IRE) -> Only allow indirect write access to the data lake through a Lambda function → ensures consistency. +The IRE is where backups are restored, validated, and used to rebuild the new environment before cutover. It has no trust relationship with the production account, no VPC peering to production, and no public internet-facing resources. ---- +This design limits blast radius. If a restored backup is still unsafe, the issue remains contained inside the IRE instead of spreading back to production or outside the AWS environment. -## Front Door Microservice +## AWS Services Involved -- Provides an API Gateway for external REST interaction -- Authentication & authorization based on **OIDC** via **Amazon Cognito** -- Self-managed *deduplication* mechanism using DynamoDB instead of SNS FIFO because: - 1. SNS deduplication TTL is only 5 minutes - 2. SNS FIFO requires SQS FIFO - 3. Ability to proactively notify the sender that the message is a duplicate +- **AWS Backup**: manages backup and restore across supported AWS resources. +- **AWS Backup logically air-gapped vault**: protects recovery points from deletion during retention. +- **AWS Resource Access Manager (AWS RAM)**: shares recovery points across accounts. +- **Amazon S3 Versioning and S3 Object Lock**: protect S3 object versions from deletion or overwrite when strict retention is required. +- **IAM Identity Center and Multi-party approval (MPA)**: require approval from multiple predefined approvers before restore. +- **Amazon GuardDuty Malware Protection**: scans restored volumes or backup contents for malware. +- **AWS CloudTrail, VPC Flow Logs, and AWS Security Hub**: help build an investigation timeline and identify suspicious activity. +- **AWS Config and IAM Access Analyzer**: help identify cross-account dependencies, policies, and trust relationships before cutover. +- **AWS PrivateLink / VPC endpoints**: allow the IRE to call AWS service APIs without opening internet connectivity. ---- +## End-to-End Recovery Workflow -## Staging ER7 Microservice +The original article does not only describe architecture components. It also shows how recovery should be operated in stages. I summarize the workflow into five main steps: -- Lambda “trigger” subscribed to the pub/sub hub, filtering messages by attribute -- Step Functions Express Workflow to convert ER7 → JSON -- Two Lambdas: - 1. Fix ER7 formatting (newline, carriage return) - 2. Parsing logic -- Result or error is pushed back into the pub/sub hub +![Recovery workflow](/images/3-BlogsTranslated/Blog1/Recovery_workflow.jpg) ---- +*Source: AWS Architecture Blog - Cyber resilience on AWS* + +1. **Establish the timeline**: reconstruct the incident timeline from logs, alerts, and indicators of compromise. +2. **Validate candidates**: choose potentially safe recovery points and validate them inside the IRE. +3. **Approval**: require approval before using a recovery point, especially for critical workloads. +4. **Rebuild and restore**: rebuild clean infrastructure, restore validated data, and rotate all secrets. +5. **Cutover**: check dependencies, move traffic to the new environment, and continue monitoring. + +What I like about this workflow is that it avoids the rushed approach of restoring the latest backup and reopening the system immediately. Each stage includes validation or approval to reduce the chance of bringing the threat back into production. + +## Validation Pipeline: Restore Does Not Mean Safe + +One useful point from the article is that a successful restore only proves the backup can be read. It does not prove the backup is safe. + +AWS recommends combining multiple validation layers: + +- Restore testing to verify backups are recoverable. +- Malware scanning to detect known malicious tools or indicators. +- Workload-specific checks such as database consistency checks or configuration comparison against a known-good baseline. +- Log and audit review to identify unexpected identity, network, or configuration changes. + +These checks should run inside the IRE. A recovery point should only be approved after it passes both technical validation and the organization’s approval process. + +## Selecting a Safe Recovery Point + +For normal operational recovery, the most recent backup is often the best option. For cyber events, the most recent backup might not be safe because it may have been created after the attacker entered the environment. + +![Selecting a safe recovery point](/images/3-BlogsTranslated/Blog1/Selecting_a_safe_recovery_point.png) + +*Source: AWS Architecture Blog - Cyber resilience on AWS* + +A safer process is: + +1. Build an investigation timeline using CloudTrail, VPC Flow Logs, GuardDuty, Security Hub, and workload logs. +2. Identify the earliest plausible indicator of the event. +3. Consider recovery points created before that event boundary. +4. Validate candidates in reverse chronological order, starting with the newest candidate before the boundary. +5. If validation fails, move to an older recovery point. +6. Document the selected recovery point, validation result, approver, and reason. + +This process reduces the chance of restoring compromised data or configuration. + +## Checks Before Cutover + +After rebuild and restore are complete, traffic should not be moved immediately. The new environment still needs careful checks for dependencies across accounts, services, and identities. + +Some items to review before cutover include: + +- IAM role trust policies and resource-based policies. +- AWS KMS key policies, grants, and encrypt/decrypt permissions. +- Cross-account references or service integrations that still point to the old production environment. +- Security groups, route tables, DNS records, and endpoint configuration. +- Log forwarding, monitoring, alerting, and backup plans for the new environment. + +In my view, this is one of the easiest areas to miss during recovery. Even if the data is restored successfully, the system can still fail or keep security risk if KMS permissions are missing, DNS cutover is incorrect, or IAM trust policies still reference the old account. + +## Rebuild-Restore-Rotate Framework + +The blog summarizes cyber recovery with a simple framework: + +| Category | Examples | Recovery action | +| --- | --- | --- | +| Rebuild | VPC, security groups, IAM roles, Lambda functions, CI/CD pipelines | Rebuild from reviewed Infrastructure as Code or a trusted source repository | +| Restore | RDS, Aurora, EBS, EFS, FSx, business data | Restore from validated backups | +| Rotate | Passwords, API keys, access keys, certificates, SSH keys | Rotate or re-issue instead of reusing old secrets | + +The key lesson is that not everything should be restored from backup. Infrastructure and configuration should come from trusted code. Business data should come from validated backups. Credentials should be replaced because it is difficult to prove they were not exposed during the event. + +## What I Learned + +Before reading this article, I mostly thought of backup as the core of disaster recovery. After studying the post, I realized that ransomware recovery requires a stricter mindset. A backup is only useful if it is protected, validated, and restored into an environment that does not inherit trust from compromised production. + +I also learned why AWS account separation is valuable. AWS Organizations, SCPs, AWS RAM, AWS Backup vaults, and IAM controls can work together to create clear trust boundaries. This is stronger than keeping all recovery resources inside the same production account. + +## Conclusion + +Cyber resilience on AWS is not only about defending against attacks. It is also about preparing to recover when parts of the environment can no longer be trusted. The reference approach with a Recovery Account, IRE, logically air-gapped vault, validation pipeline, and Rebuild-Restore-Rotate framework gives organizations a clearer recovery process for ransomware and destructive events. + +For a real system, I think the first practical steps should be: + +- Create a Recovery Account and logically air-gapped vault for critical workloads. +- Prepare the IRE in advance instead of building it only after an incident. +- Enable AWS Backup Restore Testing and run restore tests regularly. +- Enable GuardDuty Malware Protection as part of the validation process. +- Define workload-specific integrity checks such as database checks, file hashes, or baseline configuration comparison. +- Write a runbook for Rebuild-Restore-Rotate. +- Practice credential rotation and cutover regularly. -## New Features in the Solution - -### 1. AWS CloudFormation Cross-Stack References -Example *outputs* in the core microservice: -```yaml -Outputs: - Bucket: - Value: !Ref Bucket - Export: - Name: !Sub ${AWS::StackName}-Bucket - ArtifactBucket: - Value: !Ref ArtifactBucket - Export: - Name: !Sub ${AWS::StackName}-ArtifactBucket - Topic: - Value: !Ref Topic - Export: - Name: !Sub ${AWS::StackName}-Topic - Catalog: - Value: !Ref Catalog - Export: - Name: !Sub ${AWS::StackName}-Catalog - CatalogArn: - Value: !GetAtt Catalog.Arn - Export: - Name: !Sub ${AWS::StackName}-CatalogArn +Waiting until an incident occurs would make recovery slower, riskier, and more error-prone. This article helped me understand that cyber recovery must be designed, tested, and practiced in advance, just like a required part of the system architecture instead of an optional document created after deployment. diff --git a/content/3-BlogsTranslated/3.1-Blog1/_index.vi.md b/content/3-BlogsTranslated/3.1-Blog1/_index.vi.md index f0fc746..33ebb6b 100644 --- a/content/3-BlogsTranslated/3.1-Blog1/_index.vi.md +++ b/content/3-BlogsTranslated/3.1-Blog1/_index.vi.md @@ -5,122 +5,164 @@ weight: 1 chapter: false pre: " 3.1. " --- -{{% notice warning %}} -⚠️ **Lưu ý:** Các thông tin dưới đây chỉ nhằm mục đích tham khảo, vui lòng **không sao chép nguyên văn** cho bài báo cáo của bạn kể cả warning này. -{{% /notice %}} -# Bắt đầu với healthcare data lakes: Sử dụng microservices +# Cyber Resilience trên AWS: Cách tiếp cận tham khảo để phục hồi sau ransomware và sự cố phá hủy -Các data lake có thể giúp các bệnh viện và cơ sở y tế chuyển dữ liệu thành những thông tin chi tiết về doanh nghiệp và duy trì hoạt động kinh doanh liên tục, đồng thời bảo vệ quyền riêng tư của bệnh nhân. **Data lake** là một kho lưu trữ tập trung, được quản lý và bảo mật để lưu trữ tất cả dữ liệu của bạn, cả ở dạng ban đầu và đã xử lý để phân tích. data lake cho phép bạn chia nhỏ các kho chứa dữ liệu và kết hợp các loại phân tích khác nhau để có được thông tin chi tiết và đưa ra các quyết định kinh doanh tốt hơn. +## Nguồn tham khảo -Bài đăng trên blog này là một phần của loạt bài lớn hơn về việc bắt đầu cài đặt data lake dành cho lĩnh vực y tế. Trong bài đăng blog cuối cùng của tôi trong loạt bài, *“Bắt đầu với data lake dành cho lĩnh vực y tế: Đào sâu vào Amazon Cognito”*, tôi tập trung vào các chi tiết cụ thể của việc sử dụng Amazon Cognito và Attribute Based Access Control (ABAC) để xác thực và ủy quyền người dùng trong giải pháp data lake y tế. Trong blog này, tôi trình bày chi tiết cách giải pháp đã phát triển ở cấp độ cơ bản, bao gồm các quyết định thiết kế mà tôi đã đưa ra và các tính năng bổ sung được sử dụng. Bạn có thể truy cập các code samples cho giải pháp tại Git repo này để tham khảo. +- AWS Architecture Blog: [Cyber resilience on AWS: A reference approach for recovery from ransomware and destructive events](https://aws.amazon.com/vi/blogs/architecture/cyber-resilience-on-aws-a-reference-approach-for-recovery-from-ransomware-and-destructive-events/) +- Tác giả: Ashish Panwar, Kanniah Vagathupatti Jaikumar, Rakesh Singh +- Ngày phát hành: 20/05/2026 ---- +## Tổng quan -## Hướng dẫn kiến trúc +Khi nhắc đến bảo mật, chúng ta thường nghĩ đến việc ngăn chặn tấn công hoặc phát hiện mối đe dọa càng sớm càng tốt. Tuy nhiên, bài viết của AWS nhấn mạnh thêm một khía cạnh rất quan trọng: **cyber resilience**, tức là khả năng khôi phục workload về một trạng thái đáng tin cậy sau khi môi trường đã bị ảnh hưởng bởi ransomware, data extortion hoặc các sự cố phá hủy. -Thay đổi chính kể từ lần trình bày cuối cùng của kiến trúc tổng thể là việc tách dịch vụ đơn lẻ thành một tập hợp các dịch vụ nhỏ để cải thiện khả năng bảo trì và tính linh hoạt. Việc tích hợp một lượng lớn dữ liệu y tế khác nhau thường yêu cầu các trình kết nối chuyên biệt cho từng định dạng; bằng cách giữ chúng được đóng gói riêng biệt với microservices, chúng ta có thể thêm, xóa và sửa đổi từng trình kết nối mà không ảnh hưởng đến những kết nối khác. Các microservices được kết nối rời thông qua tin nhắn publish/subscribe tập trung trong cái mà tôi gọi là “pub/sub hub”. +Điểm mình thấy quan trọng nhất là: trong một sự cố nghiêm trọng, không thể mặc định production, credential, backup hoặc hạ tầng recovery vẫn còn an toàn. Vì vậy, chiến lược phục hồi không chỉ là "có backup", mà còn phải đảm bảo backup không bị xóa, môi trường phục hồi được cô lập, và dữ liệu được kiểm tra trước khi đưa trở lại production. -Giải pháp này đại diện cho những gì tôi sẽ coi là một lần lặp nước rút hợp lý khác từ last post của tôi. Phạm vi vẫn được giới hạn trong việc nhập và phân tích cú pháp đơn giản của các **HL7v2 messages** được định dạng theo **Quy tắc mã hóa 7 (ER7)** thông qua giao diện REST. +## Vấn đề cần giải quyết -**Kiến trúc giải pháp bây giờ như sau:** +Với các workload quan trọng trên AWS, ransomware có thể gây ra nhiều rủi ro hơn việc mã hóa dữ liệu. Kẻ tấn công có thể cố xóa backup, thay đổi cấu hình, đánh cắp credential, hoặc để lại thay đổi độc hại trong hệ thống trước khi bị phát hiện. -> *Hình 1. Kiến trúc tổng thể; những ô màu thể hiện những dịch vụ riêng biệt.* +Nếu doanh nghiệp chỉ restore backup mới nhất mà không kiểm tra, backup đó có thể đã nằm trong khoảng thời gian bị xâm nhập. Khi đó, hệ thống mới có thể tiếp tục mang theo lỗi, mã độc hoặc cấu hình không đáng tin cậy. ---- +Vì vậy, recovery plan cần trả lời được các câu hỏi: -Mặc dù thuật ngữ *microservices* có một số sự mơ hồ cố hữu, một số đặc điểm là chung: -- Chúng nhỏ, tự chủ, kết hợp rời rạc -- Có thể tái sử dụng, giao tiếp thông qua giao diện được xác định rõ -- Chuyên biệt để giải quyết một việc -- Thường được triển khai trong **event-driven architecture** +- Backup có được bảo vệ khỏi việc bị xóa hay rút ngắn retention không? +- Môi trường phục hồi có tách biệt khỏi production bị ảnh hưởng không? +- Làm sao xác định recovery point nào đủ an toàn để dùng? +- Phần nào nên rebuild từ code, phần nào restore từ backup, và phần nào phải tạo mới? -Khi xác định vị trí tạo ranh giới giữa các microservices, cần cân nhắc: -- **Nội tại**: công nghệ được sử dụng, hiệu suất, độ tin cậy, khả năng mở rộng -- **Bên ngoài**: chức năng phụ thuộc, tần suất thay đổi, khả năng tái sử dụng -- **Con người**: quyền sở hữu nhóm, quản lý *cognitive load* +## Kiến trúc phục hồi được đề xuất ---- +Bài AWS đưa ra cách chia môi trường thành ba nhóm tài khoản chính trong AWS Organizations. -## Lựa chọn công nghệ và phạm vi giao tiếp +![Isolated Recovery Environment](/images/3-BlogsTranslated/Blog1/IsolatedRecoveryEnvironment(IRE).png) -| Phạm vi giao tiếp | Các công nghệ / mô hình cần xem xét | -| ---------------------------------------- | ------------------------------------------------------------------------------------------ | -| Trong một microservice | Amazon Simple Queue Service (Amazon SQS), AWS Step Functions | -| Giữa các microservices trong một dịch vụ | AWS CloudFormation cross-stack references, Amazon Simple Notification Service (Amazon SNS) | -| Giữa các dịch vụ | Amazon EventBridge, AWS Cloud Map, Amazon API Gateway | +*Nguồn: AWS Architecture Blog - Cyber resilience on AWS* ---- +### Production Account -## The pub/sub hub +Đây là nơi workload đang chạy thực tế. Khi xác nhận có sự cố nghiêm trọng, production account nên được cô lập để điều tra. Việc phục hồi không nên thực hiện trực tiếp trong production cũ, vì nếu môi trường này đã bị compromise thì các trust boundary, credential hoặc cấu hình hiện tại không còn đáng tin hoàn toàn. -Việc sử dụng kiến trúc **hub-and-spoke** (hay message broker) hoạt động tốt với một số lượng nhỏ các microservices liên quan chặt chẽ. -- Mỗi microservice chỉ phụ thuộc vào *hub* -- Kết nối giữa các microservice chỉ giới hạn ở nội dung của message được xuất -- Giảm số lượng synchronous calls vì pub/sub là *push* không đồng bộ một chiều +### Recovery Account -Nhược điểm: cần **phối hợp và giám sát** để tránh microservice xử lý nhầm message. +Recovery Account là nơi quản lý backup quan trọng, đặc biệt là **AWS Backup logically air-gapped vault**. Vault này giúp bảo vệ recovery point khỏi việc bị xóa trong thời gian retention, kể cả khi root user hoặc administrator bị compromise. ---- +Tài khoản này nên được giới hạn quyền bằng Service Control Policies (SCPs), chỉ tập trung vào hoạt động backup và restore. Như vậy, nếu production account bị tấn công, attacker không thể dễ dàng can thiệp vào backup control plane. -## Core microservice +Một điểm đáng chú ý là logically air-gapped vault hoạt động với tư duy "recovery point phải tồn tại đủ lâu để có thể điều tra và phục hồi". Vault dùng chế độ bảo vệ chặt chẽ để ngăn việc xóa hoặc rút ngắn retention trong khoảng thời gian đã cấu hình. Với dữ liệu Amazon S3, bài viết cũng nhắc đến cách tiếp cận tương đương bằng **S3 Versioning** và **S3 Object Lock ở Compliance mode**, nhằm bảo vệ object version khỏi việc bị xóa hoặc ghi đè ngoài ý muốn. -Cung cấp dữ liệu nền tảng và lớp truyền thông, gồm: -- **Amazon S3** bucket cho dữ liệu -- **Amazon DynamoDB** cho danh mục dữ liệu -- **AWS Lambda** để ghi message vào data lake và danh mục -- **Amazon SNS** topic làm *hub* -- **Amazon S3** bucket cho artifacts như mã Lambda +### Isolated Recovery Environment (IRE) -> Chỉ cho phép truy cập ghi gián tiếp vào data lake qua hàm Lambda → đảm bảo nhất quán. +IRE là môi trường dùng để restore, validate và rebuild workload mới trước khi cutover. Môi trường này không có trust relationship với production account, không VPC peering với production, và không expose trực tiếp ra Internet. ---- +Cách thiết kế này giúp giới hạn rủi ro: nếu một backup được restore ra vẫn chứa threat, threat đó bị giữ trong môi trường cô lập thay vì lan ngược về production hoặc ra ngoài. -## Front door microservice +## Các dịch vụ AWS liên quan -- Cung cấp API Gateway để tương tác REST bên ngoài -- Xác thực & ủy quyền dựa trên **OIDC** thông qua **Amazon Cognito** -- Cơ chế *deduplication* tự quản lý bằng DynamoDB thay vì SNS FIFO vì: - 1. SNS deduplication TTL chỉ 5 phút - 2. SNS FIFO yêu cầu SQS FIFO - 3. Chủ động báo cho sender biết message là bản sao +- **AWS Backup**: quản lý backup và restore cho nhiều loại tài nguyên AWS. +- **AWS Backup logically air-gapped vault**: bảo vệ recovery point khỏi việc bị xóa trong thời gian retention. +- **AWS Resource Access Manager (AWS RAM)**: chia sẻ recovery point giữa các account. +- **Amazon S3 Versioning và S3 Object Lock**: bảo vệ dữ liệu S3 khỏi xóa hoặc ghi đè trong các tình huống cần retention nghiêm ngặt. +- **IAM Identity Center và Multi-party approval (MPA)**: yêu cầu nhiều người phê duyệt trước khi restore. +- **Amazon GuardDuty Malware Protection**: quét malware trên volume hoặc backup được restore. +- **AWS CloudTrail, VPC Flow Logs, AWS Security Hub**: hỗ trợ điều tra timeline và phát hiện hành vi bất thường. +- **AWS Config và IAM Access Analyzer**: kiểm tra dependency, policy, trust relationship và cấu hình liên quan khi cutover. +- **AWS PrivateLink / VPC endpoints**: cho phép IRE gọi AWS service API mà không cần mở Internet. ---- +## Quy trình phục hồi tổng thể -## Staging ER7 microservice +Bài gốc không chỉ đưa ra các thành phần kiến trúc, mà còn mô tả cách vận hành recovery theo từng giai đoạn. Mình tóm tắt lại thành 5 bước chính: -- Lambda “trigger” đăng ký với pub/sub hub, lọc message theo attribute -- Step Functions Express Workflow để chuyển ER7 → JSON -- Hai Lambda: - 1. Sửa format ER7 (newline, carriage return) - 2. Parsing logic -- Kết quả hoặc lỗi được đẩy lại vào pub/sub hub +![Recovery workflow](/images/3-BlogsTranslated/Blog1/Recovery_workflow.jpg) ---- +*Nguồn: AWS Architecture Blog - Cyber resilience on AWS* + +1. **Establish the timeline**: dựng lại timeline sự cố từ log, alert và dấu hiệu compromise. +2. **Validate candidates**: chọn các recovery point có khả năng an toàn và kiểm tra trong IRE. +3. **Approval**: yêu cầu phê duyệt trước khi dùng recovery point, đặc biệt với workload quan trọng. +4. **Rebuild and restore**: dựng lại hạ tầng sạch, restore dữ liệu đã validate, rotate toàn bộ secret. +5. **Cutover**: kiểm tra dependency, chuyển traffic sang môi trường mới và tiếp tục giám sát. + +Điểm hay của workflow này là nó tránh cách làm vội vàng "restore backup mới nhất rồi mở lại hệ thống". Thay vào đó, mỗi bước đều có kiểm tra và phê duyệt để giảm nguy cơ đưa threat quay lại production. + +## Validation pipeline: restore được chưa chắc đã an toàn + +Một ý mình thấy rất thực tế là: restore thành công chỉ chứng minh backup còn đọc được, chưa chứng minh backup đó an toàn. + +AWS đề xuất kết hợp nhiều lớp kiểm tra: + +- Restore testing để xác nhận backup có thể phục hồi. +- Malware scanning để phát hiện mã độc hoặc công cụ mã hóa dữ liệu. +- Kiểm tra đặc thù theo workload, ví dụ database consistency check hoặc so sánh cấu hình với baseline. +- Review log và audit trail để tìm thay đổi bất thường về identity, network hoặc configuration. + +Các bước validation nên chạy trong IRE. Chỉ khi recovery point vượt qua các kiểm tra này thì mới được phê duyệt để restore vào môi trường rebuilt. + +## Chọn recovery point an toàn + +Trong sự cố vận hành thông thường, backup mới nhất thường là lựa chọn tốt. Nhưng trong cyber event, backup mới nhất chưa chắc an toàn, vì attacker có thể đã tồn tại trong hệ thống trước thời điểm bị phát hiện. + +![Selecting a safe recovery point](/images/3-BlogsTranslated/Blog1/Selecting_a_safe_recovery_point.png) + +*Nguồn: AWS Architecture Blog - Cyber resilience on AWS* + +Cách tiếp cận hợp lý là: + +1. Xây dựng timeline điều tra từ CloudTrail, VPC Flow Logs, GuardDuty, Security Hub và log của workload. +2. Xác định thời điểm sớm nhất có khả năng bắt đầu sự cố. +3. Chọn các recovery point trước mốc đó. +4. Validate từng recovery point, bắt đầu từ bản gần nhất. +5. Nếu validation fail, lùi về recovery point cũ hơn. +6. Ghi lại lý do chọn recovery point và người phê duyệt. + +Cách này giúp giảm nguy cơ restore lại chính dữ liệu hoặc cấu hình đã bị ảnh hưởng. + +## Kiểm tra trước khi cutover + +Sau khi rebuild và restore thành công, vẫn chưa nên chuyển traffic ngay. Môi trường mới cần được kiểm tra kỹ các dependency với account, service và identity khác. + +Một số điểm nên review trước cutover: + +- IAM role trust policies và resource-based policies. +- AWS KMS key policy, grant và quyền decrypt/encrypt. +- Cross-account references hoặc service integrations đang trỏ về production cũ. +- Security group, route table, DNS record và endpoint configuration. +- Log forwarding, monitoring, alerting và backup plan cho môi trường mới. + +Theo mình, đây là phần rất dễ bị bỏ sót trong recovery. Nếu chỉ restore được dữ liệu nhưng thiếu KMS permission, DNS cutover sai, hoặc IAM trust policy vẫn trỏ về account cũ thì hệ thống có thể chạy lỗi hoặc tiếp tục giữ lại rủi ro bảo mật. + +## Framework Rebuild-Restore-Rotate + +Bài viết tóm gọn recovery thành ba nhóm hành động rất dễ nhớ: + +| Nhóm | Ví dụ | Cách xử lý | +| --- | --- | --- | +| Rebuild | VPC, security group, IAM role, Lambda, pipeline | Dựng lại từ Infrastructure as Code hoặc source đáng tin cậy | +| Restore | RDS, Aurora, EBS, EFS, FSx, dữ liệu nghiệp vụ | Khôi phục từ backup đã validate | +| Rotate | Password, API key, access key, certificate, SSH key | Tạo mới hoặc rotate, không dùng lại secret cũ | + +Điểm quan trọng là không nên restore mọi thứ từ backup. Hạ tầng và cấu hình nên được dựng lại từ code đã review. Dữ liệu nghiệp vụ thì restore từ backup đã kiểm tra. Credential phải được thay mới vì không thể biết chắc chúng đã bị lộ hay chưa. + +## Điều mình học được + +Trước khi đọc bài này, mình thường nghĩ backup là yếu tố chính của disaster recovery. Sau khi tìm hiểu, mình nhận ra trong ransomware recovery, backup chỉ là một phần. Điều quan trọng hơn là backup có được bảo vệ không, restore ở đâu, validate như thế nào, và credential có được rotate đầy đủ không. + +Mình cũng thấy mô hình tách account rất phù hợp với AWS vì AWS Organizations, SCP, RAM, Backup vault và IAM có thể kết hợp để tạo trust boundary rõ ràng. Đây là điểm khác biệt lớn so với việc chỉ lưu backup trong cùng production account. + +## Kết luận + +Cyber resilience trên AWS không chỉ là phòng thủ trước tấn công, mà là chuẩn bị để phục hồi khi một phần môi trường không còn đáng tin cậy. Cách tiếp cận với Recovery Account, IRE, logically air-gapped vault, validation pipeline và Rebuild-Restore-Rotate giúp doanh nghiệp có quy trình phục hồi rõ ràng hơn trước ransomware hoặc destructive events. + +Nếu áp dụng vào một hệ thống thực tế, mình nghĩ các bước nên làm sớm là: + +- Tạo Recovery Account và logically air-gapped vault cho workload quan trọng. +- Chuẩn bị IRE trước, không đợi đến lúc có sự cố mới dựng. +- Bật AWS Backup Restore Testing và kiểm thử restore định kỳ. +- Bật GuardDuty Malware Protection cho quy trình validation. +- Định nghĩa workload-specific integrity checks, ví dụ kiểm tra database, file hash hoặc cấu hình baseline. +- Viết runbook cho Rebuild-Restore-Rotate. +- Luyện tập credential rotation và cutover định kỳ. -## Tính năng mới trong giải pháp - -### 1. AWS CloudFormation cross-stack references -Ví dụ *outputs* trong core microservice: -```yaml -Outputs: - Bucket: - Value: !Ref Bucket - Export: - Name: !Sub ${AWS::StackName}-Bucket - ArtifactBucket: - Value: !Ref ArtifactBucket - Export: - Name: !Sub ${AWS::StackName}-ArtifactBucket - Topic: - Value: !Ref Topic - Export: - Name: !Sub ${AWS::StackName}-Topic - Catalog: - Value: !Ref Catalog - Export: - Name: !Sub ${AWS::StackName}-Catalog - CatalogArn: - Value: !GetAtt Catalog.Arn - Export: - Name: !Sub ${AWS::StackName}-CatalogArn +Nếu đợi đến lúc sự cố xảy ra mới thiết kế recovery plan thì khả năng downtime và sai sót sẽ rất cao. Bài viết này giúp mình hiểu rằng cyber recovery là một quy trình cần được thiết kế, kiểm thử và luyện tập trước, giống như một phần bắt buộc của kiến trúc hệ thống chứ không phải tài liệu phụ sau khi triển khai. diff --git a/content/3-BlogsTranslated/3.2-Blog2/_index.md b/content/3-BlogsTranslated/3.2-Blog2/_index.md index 0185a87..8ee1256 100644 --- a/content/3-BlogsTranslated/3.2-Blog2/_index.md +++ b/content/3-BlogsTranslated/3.2-Blog2/_index.md @@ -5,122 +5,186 @@ weight: 1 chapter: false pre: " 3.2. " --- -{{% notice warning %}} -⚠️ **Note:** The information below is for reference purposes only. Please **do not copy verbatim** for your report, including this warning. -{{% /notice %}} -# Getting Started with Healthcare Data Lakes: Using Microservices +# Building a Multi Account Patch Compliance Dashboard with Kiro Specs -Data lakes can help hospitals and healthcare facilities turn data into business insights, maintain business continuity, and protect patient privacy. A **data lake** is a centralized, managed, and secure repository to store all your data, both in its raw and processed forms for analysis. Data lakes allow you to break down data silos and combine different types of analytics to gain insights and make better business decisions. +## References -This blog post is part of a larger series on getting started with setting up a healthcare data lake. In my final post of the series, *“Getting Started with Healthcare Data Lakes: Diving into Amazon Cognito”*, I focused on the specifics of using Amazon Cognito and Attribute Based Access Control (ABAC) to authenticate and authorize users in the healthcare data lake solution. In this blog, I detail how the solution evolved at a foundational level, including the design decisions I made and the additional features used. You can access the code samples for the solution in this Git repo for reference. +- AWS Cloud Operations Blog: [Build a Multi Account Patch Compliance Dashboard with Kiro Specs](https://aws.amazon.com/vi/blogs/mt/build-a-multi-account-patch-compliance-dashboard-with-kiro-specs/) +- Author: Justin Thomas +- Published: June 9, 2026 ---- +## Overview -## Architecture Guidance +Patch management is an important part of operating secure and reliable systems. It directly affects security posture, system stability, and compliance. When an environment only has a few servers or a few AWS accounts, tracking patch status can be simple. When an organization grows to dozens or hundreds of accounts, answering "how many instances are currently non-compliant?" becomes much harder. -The main change since the last presentation of the overall architecture is the decomposition of a single service into a set of smaller services to improve maintainability and flexibility. Integrating a large volume of diverse healthcare data often requires specialized connectors for each format; by keeping them encapsulated separately as microservices, we can add, remove, and modify each connector without affecting the others. The microservices are loosely coupled via publish/subscribe messaging centered in what I call the “pub/sub hub.” +The AWS blog introduces how to build a **Multi Account Patch Compliance Dashboard** using **Kiro Specs**. What I found interesting is that the article is not only about the dashboard itself. It also shows how spec-driven development can turn an operational requirement into architecture, implementation tasks, and a working codebase. -This solution represents what I would consider another reasonable sprint iteration from my last post. The scope is still limited to the ingestion and basic parsing of **HL7v2 messages** formatted in **Encoding Rules 7 (ER7)** through a REST interface. +The dashboard uses **AWS Systems Manager Patch Manager** data through **Resource Data Sync**, aggregates the data in Amazon S3, and presents it through a private web interface. Users access the dashboard with **AWS Systems Manager Session Manager port forwarding**, so the solution does not need to expose a public endpoint to the internet. -**The solution architecture is now as follows:** +## Problem Context -> *Figure 1. Overall architecture; colored boxes represent distinct services.* +AWS Systems Manager provides features such as Inventory, Explorer, and Compliance to help report managed node compliance. Resource Data Sync can export inventory and patch compliance data to Amazon S3. However, when the data comes from many accounts and Regions, manual reporting or reading thousands of raw S3 files every time the dashboard loads is not efficient. ---- +A practical patch compliance dashboard needs to: -While the term *microservices* has some inherent ambiguity, certain traits are common: -- Small, autonomous, loosely coupled -- Reusable, communicating through well-defined interfaces -- Specialized to do one thing well -- Often implemented in an **event-driven architecture** +- Show total instances, compliance rate, compliant count, and non-compliant count quickly. +- Aggregate data across multiple AWS accounts. +- Let users drill down from an account to instance-level detail. +- Show which patches are missing and their severity. +- Avoid exposing the dashboard to the public internet. +- Remain cost-efficient with a serverless, pay-per-use model. +- Have a clear deployment process that is easy to validate and extend. -When determining where to draw boundaries between microservices, consider: -- **Intrinsic**: technology used, performance, reliability, scalability -- **Extrinsic**: dependent functionality, rate of change, reusability -- **Human**: team ownership, managing *cognitive load* +## Solution Architecture ---- +The original article proposes a serverless and private architecture focused on operations. -## Technology Choices and Communication Scope +The main flow works like this: -| Communication scope | Technologies / patterns to consider | -| ----------------------------------------- | ------------------------------------------------------------------------------------------ | -| Within a single microservice | Amazon Simple Queue Service (Amazon SQS), AWS Step Functions | -| Between microservices in a single service | AWS CloudFormation cross-stack references, Amazon Simple Notification Service (Amazon SNS) | -| Between services | Amazon EventBridge, AWS Cloud Map, Amazon API Gateway | +1. A user starts **SSM Session Manager port forwarding** to forward a local port to an internal Application Load Balancer through a bastion host. +2. The user opens `https://localhost:8443/` in the browser. +3. The request travels through the SSM tunnel to the bastion host and then to the **internal Application Load Balancer** in a private VPC. +4. The ALB routes frontend requests to a **Frontend Lambda**, which serves the React application stored in the Dashboard S3 bucket. +5. The React app calls APIs such as `/api/compliance-summary` or `/api/compliance-detail`. +6. The **API Lambda** reads pre-aggregated data from the `/cache/` prefix in the Dashboard S3 bucket. +7. A **Cache Compute Lambda** runs every 30 minutes through Amazon EventBridge, reads raw data from the Resource Data Sync bucket, aggregates it, and writes JSON cache files to the Dashboard S3 bucket. ---- +The important design choice is that the frontend does not read raw Resource Data Sync files directly. Raw data is transformed into pre-aggregated cache files first. This improves dashboard load time and keeps a clear separation between the source data bucket and the serving bucket. -## The Pub/Sub Hub +## AWS Services Involved -Using a **hub-and-spoke** architecture (or message broker) works well with a small number of tightly related microservices. -- Each microservice depends only on the *hub* -- Inter-microservice connections are limited to the contents of the published message -- Reduces the number of synchronous calls since pub/sub is a one-way asynchronous *push* +| Service | Role in the solution | +| --- | --- | +| AWS Systems Manager Patch Manager | Manages and collects patch compliance status for managed nodes | +| AWS Systems Manager Resource Data Sync | Exports inventory and compliance data to Amazon S3 | +| Amazon S3 | Stores raw compliance data, frontend assets, and aggregated JSON cache files | +| AWS Lambda | Handles frontend serving, API requests, and cache aggregation | +| Amazon EventBridge | Triggers the Cache Compute Lambda every 30 minutes | +| Application Load Balancer | Routes internal requests to Lambda targets | +| Amazon VPC | Hosts the private architecture with private subnets and internal ALB | +| Session Manager | Provides private dashboard access through port forwarding | +| AWS CloudFormation | Deploys buckets, network, compute, and supporting infrastructure | +| CloudWatch Logs / VPC Flow Logs / ALB logs | Provides operational logging and audit visibility | -Drawback: **coordination and monitoring** are needed to avoid microservices processing the wrong message. +## Why This Architecture Prioritizes Security ---- +The most important security point is that the dashboard is not public. Instead of using a public ALB or CloudFront distribution, a user must have valid AWS credentials and the correct SSM permissions to open the tunnel. -## Core Microservice +The article highlights several security decisions: -Provides foundational data and communication layer, including: -- **Amazon S3** bucket for data -- **Amazon DynamoDB** for data catalog -- **AWS Lambda** to write messages into the data lake and catalog -- **Amazon SNS** topic as the *hub* -- **Amazon S3** bucket for artifacts such as Lambda code +- **Zero public attack surface**: the ALB is internal-only, Lambda functions run in private subnets, and no public endpoint is exposed. +- **Private-only access pattern**: the dashboard fits enterprise environments where internal tools must not be accessible from the internet. +- **Strict data separation**: the Resource Data Sync bucket is used only as a read source, while a separate Dashboard S3 bucket stores cache and frontend assets. +- **Encryption in transit and at rest**: the ALB uses HTTPS, S3 encryption is enabled, and bucket policies can deny non-TLS requests. +- **Comprehensive logging**: VPC Flow Logs, ALB access logs, and CloudWatch Log Groups support monitoring and audit. -> Only allow indirect write access to the data lake through a Lambda function → ensures consistency. +In my view, this is a reasonable design because a compliance dashboard contains sensitive operational information: which accounts have unpatched instances, which platforms are affected, and how severe the missing patches are. If this dashboard were exposed incorrectly, it could give attackers useful information. ---- +## Kiro Specs and Spec-Driven Development -## Front Door Microservice +The most interesting part of the article is how **Kiro** is used to build the solution with spec-driven development. Instead of prompting an AI assistant to write code immediately, Kiro breaks the work into three phases: -- Provides an API Gateway for external REST interaction -- Authentication & authorization based on **OIDC** via **Amazon Cognito** -- Self-managed *deduplication* mechanism using DynamoDB instead of SNS FIFO because: - 1. SNS deduplication TTL is only 5 minutes - 2. SNS FIFO requires SQS FIFO - 3. Ability to proactively notify the sender that the message is a duplicate +1. **Requirements**: define what needs to be built, what the dashboard must display, and what the acceptance criteria are. +2. **Design**: define architecture, data flow, component responsibilities, API contracts, and cache schemas. +3. **Tasks**: break the implementation into ordered tasks. ---- +This workflow reduces risk when using an AI coding assistant. If the process jumps straight to code, the generated solution may choose the wrong architecture, expose a public endpoint, or process data inefficiently. With Kiro Specs, important decisions are documented first and implementation follows those decisions. -## Staging ER7 Microservice +## Steering Files: Keeping Context for AI -- Lambda “trigger” subscribed to the pub/sub hub, filtering messages by attribute -- Step Functions Express Workflow to convert ER7 → JSON -- Two Lambdas: - 1. Fix ER7 formatting (newline, carriage return) - 2. Parsing logic -- Result or error is pushed back into the pub/sub hub +The article uses **steering files** in the `.kiro/steering/` folder. These are Markdown files that Kiro automatically includes in context. Their purpose is to avoid repeatedly explaining project conventions, architecture, and security rules during every interaction. ---- +The main steering files are: + +- **architecture.md**: describes the internal ALB, Lambda targets, private VPC, SSM access, EventBridge cache refresh, and Lambda settings. +- **data-schemas.md**: describes Resource Data Sync structures and cache formats for summary and detail views. +- **compliance-logic.md**: defines business rules, such as an instance being compliant only when `MissingCount = 0` and `InstalledPendingRebootCount = 0`. +- **frontend-specs.md**: describes layout, UI components, and Cloudscape Design System usage. +- **security.md**: defines security baselines such as HTTPS-only, S3 encryption, least-privilege IAM, security headers, input validation, and dependency pinning. + +I think steering files are very practical. When working with AI, output quality depends heavily on context. If the context is written clearly in files, the assistant can generate requirements, design, and tasks more consistently. + +## MCP Servers for Validation + +Steering files tell Kiro what to build, while MCP servers help validate what Kiro produces. The article recommends AWS MCP servers such as: + +- **Security Scanner MCP** to scan for security issues. +- **AWS IaC MCP Server** to check Infrastructure as Code against AWS best practices. + +The lesson for me is that AI should not only be used to generate code. It should also be paired with validation tools that review generated code, CloudFormation templates, and architecture choices. + +## What the Dashboard Displays + +The dashboard is designed with two levels. + +![Multi-account patch compliance dashboard generated by the spec workflow](/images/3-BlogsTranslated/Blog2/Multi-account_patch_compliance_dashboard_generated_by_the_spec_workflow.png) + +*Source: AWS Cloud Operations Blog - Build a Multi Account Patch Compliance Dashboard with Kiro Specs* + +### Main View + +The main view helps an operations team answer high-level questions quickly: + +- Total instances. +- Compliance rate. +- Number of compliant and non-compliant instances. +- Compliance status chart. +- Platform breakdown such as Linux or Windows. +- Missing patches by severity. +- Accounts table to identify which accounts need attention first. + +### Detail View + +When a user clicks an account, the dashboard shows more detail: + +- Instances in the account. +- Which instances are non-compliant. +- Number of missing patches. +- Last scan time. +- Specific missing patches and how many instances are affected. + +This structure makes sense because operators usually need a high-level overview first, then they drill down into the accounts or instances that need action. + +## Deployment and Operations + +The original article shows how Kiro can generate a deployment script for creating and deleting the resources. The deploy script builds the frontend, packages Lambda functions, deploys CloudFormation stacks in order, creates a self-signed TLS certificate for the internal ALB, uploads assets, updates Lambda code, and invokes the cache Lambda so the dashboard has data before users access it. + +After deployment, the script prints an SSM port forwarding command similar to: + +```bash +aws ssm start-session \ + --target \ + --document-name AWS-StartPortForwardingSessionToRemoteHost \ + --parameters '{"host":[""],"portNumber":["443"],"localPortNumber":["8443"]}' +``` + +Then the user opens `https://localhost:8443/` to access the dashboard. + +The article also includes cleanup guidance to avoid ongoing charges, such as deleting CloudFormation stacks, emptying S3 buckets, and removing the VPC, ALB, Lambda functions, bastion instance, and ACM certificate. + +## Possible Extensions + +The solution is a working foundation, not a final product for every organization. Some useful extensions include: + +- Add Amazon Cognito authentication for multi-user access. +- Add server-side pagination for environments with more than 10,000 instances. +- Create custom widgets for organization-specific compliance metrics. +- Integrate with Amazon SNS for compliance alerts. +- Integrate with Amazon Inspector to show CVE details for missing patches. + +## What I Learned + +Before reading this article, I thought of a compliance dashboard mostly as a frontend that displays data. After studying it, I realized the harder parts are data architecture and secure access. + +If the dashboard reads raw S3 data every time it loads, it can become slow and more expensive as the number of accounts grows. Building a scheduled cache with Lambda and EventBridge separates heavy processing from user requests. + +I also learned that Kiro Specs are useful when using AI to build systems with clear requirements. Instead of letting AI guess, the project provides steering files, requirements, design, and tasks. This makes the output easier to control, especially for sensitive areas such as IAM, private network access, and security baselines. + +## Conclusion + +This article shows how AWS Systems Manager, Resource Data Sync, Lambda, S3, EventBridge, an internal ALB, and Session Manager can work together to build a private, serverless multi-account patch compliance dashboard. + +The key point is not only the dashboard, but also the development process with Kiro Specs. When requirements, architecture, security rules, and tasks are clearly described from the beginning, an AI coding assistant can help implement faster while still keeping the solution controlled and reviewable. -## New Features in the Solution - -### 1. AWS CloudFormation Cross-Stack References -Example *outputs* in the core microservice: -```yaml -Outputs: - Bucket: - Value: !Ref Bucket - Export: - Name: !Sub ${AWS::StackName}-Bucket - ArtifactBucket: - Value: !Ref ArtifactBucket - Export: - Name: !Sub ${AWS::StackName}-ArtifactBucket - Topic: - Value: !Ref Topic - Export: - Name: !Sub ${AWS::StackName}-Topic - Catalog: - Value: !Ref Catalog - Export: - Name: !Sub ${AWS::StackName}-Catalog - CatalogArn: - Value: !GetAtt Catalog.Arn - Export: - Name: !Sub ${AWS::StackName}-CatalogArn +For a real environment, I think the most important steps are standardizing Resource Data Sync, defining compliance logic clearly, designing private access from the start, and validating generated infrastructure before deploying to production. diff --git a/content/3-BlogsTranslated/3.2-Blog2/_index.vi.md b/content/3-BlogsTranslated/3.2-Blog2/_index.vi.md index d56cf82..9fc09f1 100644 --- a/content/3-BlogsTranslated/3.2-Blog2/_index.vi.md +++ b/content/3-BlogsTranslated/3.2-Blog2/_index.vi.md @@ -6,122 +6,185 @@ chapter: false pre: " 3.2. " --- -{{% notice warning %}} -⚠️ **Lưu ý:** Các thông tin dưới đây chỉ nhằm mục đích tham khảo, vui lòng **không sao chép nguyên văn** cho bài báo cáo của bạn kể cả warning này. -{{% /notice %}} +# Xây dựng Multi Account Patch Compliance Dashboard với Kiro Specs -# Bắt đầu với healthcare data lakes: Sử dụng microservices +## Nguồn tham khảo -Các data lake có thể giúp các bệnh viện và cơ sở y tế chuyển dữ liệu thành những thông tin chi tiết về doanh nghiệp và duy trì hoạt động kinh doanh liên tục, đồng thời bảo vệ quyền riêng tư của bệnh nhân. **Data lake** là một kho lưu trữ tập trung, được quản lý và bảo mật để lưu trữ tất cả dữ liệu của bạn, cả ở dạng ban đầu và đã xử lý để phân tích. data lake cho phép bạn chia nhỏ các kho chứa dữ liệu và kết hợp các loại phân tích khác nhau để có được thông tin chi tiết và đưa ra các quyết định kinh doanh tốt hơn. +- AWS Cloud Operations Blog: [Build a Multi Account Patch Compliance Dashboard with Kiro Specs](https://aws.amazon.com/vi/blogs/mt/build-a-multi-account-patch-compliance-dashboard-with-kiro-specs/) +- Tác giả: Justin Thomas +- Ngày phát hành: 09/06/2026 -Bài đăng trên blog này là một phần của loạt bài lớn hơn về việc bắt đầu cài đặt data lake dành cho lĩnh vực y tế. Trong bài đăng blog cuối cùng của tôi trong loạt bài, *“Bắt đầu với data lake dành cho lĩnh vực y tế: Đào sâu vào Amazon Cognito”*, tôi tập trung vào các chi tiết cụ thể của việc sử dụng Amazon Cognito và Attribute Based Access Control (ABAC) để xác thực và ủy quyền người dùng trong giải pháp data lake y tế. Trong blog này, tôi trình bày chi tiết cách giải pháp đã phát triển ở cấp độ cơ bản, bao gồm các quyết định thiết kế mà tôi đã đưa ra và các tính năng bổ sung được sử dụng. Bạn có thể truy cập các code samples cho giải pháp tại Git repo này để tham khảo. +## Tổng quan ---- +Patch management là một phần quan trọng trong vận hành hệ thống vì nó liên quan trực tiếp đến bảo mật, độ ổn định và compliance. Với một vài máy chủ hoặc một vài AWS account, việc theo dõi trạng thái patch có thể còn đơn giản. Nhưng khi tổ chức mở rộng lên hàng chục hoặc hàng trăm account, việc trả lời câu hỏi "toàn bộ hệ thống hiện có bao nhiêu instance chưa compliant?" trở nên khó hơn nhiều. -## Hướng dẫn kiến trúc +Bài viết của AWS giới thiệu cách xây dựng một **Multi Account Patch Compliance Dashboard** bằng **Kiro Specs**. Điểm mình thấy hay là bài không chỉ nói về dashboard, mà còn trình bày cách dùng spec-driven development để biến yêu cầu vận hành thành kiến trúc, task triển khai và source code hoàn chỉnh. -Thay đổi chính kể từ lần trình bày cuối cùng của kiến trúc tổng thể là việc tách dịch vụ đơn lẻ thành một tập hợp các dịch vụ nhỏ để cải thiện khả năng bảo trì và tính linh hoạt. Việc tích hợp một lượng lớn dữ liệu y tế khác nhau thường yêu cầu các trình kết nối chuyên biệt cho từng định dạng; bằng cách giữ chúng được đóng gói riêng biệt với microservices, chúng ta có thể thêm, xóa và sửa đổi từng trình kết nối mà không ảnh hưởng đến những kết nối khác. Các microservices được kết nối rời thông qua tin nhắn publish/subscribe tập trung trong cái mà tôi gọi là “pub/sub hub”. +Dashboard này lấy dữ liệu patch compliance từ **AWS Systems Manager Patch Manager** thông qua **Resource Data Sync**, tổng hợp dữ liệu vào Amazon S3, rồi hiển thị dưới dạng giao diện web private. Người dùng truy cập dashboard thông qua **AWS Systems Manager Session Manager port forwarding**, không cần mở public endpoint ra Internet. -Giải pháp này đại diện cho những gì tôi sẽ coi là một lần lặp nước rút hợp lý khác từ last post của tôi. Phạm vi vẫn được giới hạn trong việc nhập và phân tích cú pháp đơn giản của các **HL7v2 messages** được định dạng theo **Quy tắc mã hóa 7 (ER7)** thông qua giao diện REST. +## Vấn đề cần giải quyết -**Kiến trúc giải pháp bây giờ như sau:** +AWS Systems Manager có nhiều tính năng hỗ trợ quản lý compliance như Inventory, Explorer và Compliance. Resource Data Sync có thể export dữ liệu inventory và patch compliance ra Amazon S3. Tuy nhiên, khi dữ liệu đến từ nhiều account và nhiều Region, việc tổng hợp thủ công hoặc đọc trực tiếp hàng ngàn file trong S3 mỗi lần mở dashboard sẽ không hiệu quả. -> *Hình 1. Kiến trúc tổng thể; những ô màu thể hiện những dịch vụ riêng biệt.* +Một dashboard patch compliance thực tế cần đáp ứng các yêu cầu: ---- +- Hiển thị nhanh tổng số instance, tỷ lệ compliant và non-compliant. +- Tổng hợp dữ liệu từ nhiều AWS account. +- Cho phép drill down từ account xuống từng instance. +- Cho biết patch nào đang thiếu và mức độ severity. +- Không expose dashboard ra Internet. +- Có chi phí thấp và phù hợp với mô hình serverless. +- Có quy trình triển khai rõ ràng, dễ kiểm tra và dễ mở rộng. -Mặc dù thuật ngữ *microservices* có một số sự mơ hồ cố hữu, một số đặc điểm là chung: -- Chúng nhỏ, tự chủ, kết hợp rời rạc -- Có thể tái sử dụng, giao tiếp thông qua giao diện được xác định rõ -- Chuyên biệt để giải quyết một việc -- Thường được triển khai trong **event-driven architecture** +## Kiến trúc giải pháp -Khi xác định vị trí tạo ranh giới giữa các microservices, cần cân nhắc: -- **Nội tại**: công nghệ được sử dụng, hiệu suất, độ tin cậy, khả năng mở rộng -- **Bên ngoài**: chức năng phụ thuộc, tần suất thay đổi, khả năng tái sử dụng -- **Con người**: quyền sở hữu nhóm, quản lý *cognitive load* +Bài gốc đề xuất một kiến trúc serverless, private và tập trung vào khả năng vận hành. ---- +Luồng hoạt động chính như sau: -## Lựa chọn công nghệ và phạm vi giao tiếp +1. Người dùng chạy lệnh **SSM Session Manager port forwarding** để forward local port đến internal Application Load Balancer thông qua bastion host. +2. Người dùng mở `https://localhost:8443/` trên trình duyệt. +3. Request đi qua SSM tunnel đến bastion host, sau đó đến **internal Application Load Balancer** trong private VPC. +4. ALB route request frontend đến **Frontend Lambda**, Lambda này phục vụ React application được lưu trong Dashboard S3 bucket. +5. React app gọi API như `/api/compliance-summary` hoặc `/api/compliance-detail`. +6. **API Lambda** đọc dữ liệu đã được aggregate sẵn từ prefix `/cache/` trong Dashboard S3 bucket. +7. **Cache Compute Lambda** được kích hoạt định kỳ mỗi 30 phút bằng Amazon EventBridge, đọc raw data từ Resource Data Sync bucket, tổng hợp lại và ghi cache JSON vào Dashboard S3 bucket. -| Phạm vi giao tiếp | Các công nghệ / mô hình cần xem xét | -| ---------------------------------------- | ------------------------------------------------------------------------------------------ | -| Trong một microservice | Amazon Simple Queue Service (Amazon SQS), AWS Step Functions | -| Giữa các microservices trong một dịch vụ | AWS CloudFormation cross-stack references, Amazon Simple Notification Service (Amazon SNS) | -| Giữa các dịch vụ | Amazon EventBridge, AWS Cloud Map, Amazon API Gateway | +Điểm quan trọng là frontend không đọc trực tiếp dữ liệu raw từ Resource Data Sync bucket. Dữ liệu raw được chuyển thành cache đã tổng hợp trước, giúp dashboard tải nhanh hơn và tách rõ nguồn dữ liệu khỏi nơi phục vụ giao diện. ---- +## Các dịch vụ AWS liên quan -## The pub/sub hub +| Dịch vụ | Vai trò trong giải pháp | +| --- | --- | +| AWS Systems Manager Patch Manager | Quản lý và thu thập trạng thái patch compliance của managed nodes | +| AWS Systems Manager Resource Data Sync | Export inventory và compliance data ra Amazon S3 | +| Amazon S3 | Lưu raw compliance data, frontend assets và cache JSON đã tổng hợp | +| AWS Lambda | Xử lý frontend, API request và cache aggregation | +| Amazon EventBridge | Kích hoạt Cache Compute Lambda theo lịch 30 phút | +| Application Load Balancer | Route request nội bộ đến các Lambda target | +| Amazon VPC | Chạy kiến trúc private với private subnet và internal ALB | +| Session Manager | Cho phép truy cập dashboard private thông qua port forwarding | +| AWS CloudFormation | Triển khai bucket, network, compute và các thành phần hạ tầng | +| CloudWatch Logs / VPC Flow Logs / ALB logs | Ghi log phục vụ vận hành và audit | -Việc sử dụng kiến trúc **hub-and-spoke** (hay message broker) hoạt động tốt với một số lượng nhỏ các microservices liên quan chặt chẽ. -- Mỗi microservice chỉ phụ thuộc vào *hub* -- Kết nối giữa các microservice chỉ giới hạn ở nội dung của message được xuất -- Giảm số lượng synchronous calls vì pub/sub là *push* không đồng bộ một chiều +## Vì sao kiến trúc này ưu tiên bảo mật? -Nhược điểm: cần **phối hợp và giám sát** để tránh microservice xử lý nhầm message. +Điểm mình thấy đáng chú ý nhất là dashboard không được public ra Internet. Thay vì dùng public ALB hoặc CloudFront, người dùng phải có AWS credential và quyền SSM phù hợp để mở tunnel. ---- +Bài viết nhấn mạnh một số quyết định bảo mật: -## Core microservice +- **Zero public attack surface**: ALB là internal-only, Lambda chạy trong private subnet và không có public endpoint. +- **Private-only access pattern**: dashboard phù hợp với môi trường enterprise yêu cầu công cụ nội bộ không truy cập được từ Internet. +- **Strict data separation**: Resource Data Sync bucket chỉ đóng vai trò nguồn đọc; Dashboard S3 bucket riêng dùng để chứa cache và frontend assets. +- **Encryption in transit and at rest**: ALB dùng HTTPS, S3 bật encryption và bucket policy có thể chặn non-TLS request. +- **Comprehensive logging**: VPC Flow Logs, ALB access logs và CloudWatch Log Groups giúp theo dõi hoạt động hệ thống. -Cung cấp dữ liệu nền tảng và lớp truyền thông, gồm: -- **Amazon S3** bucket cho dữ liệu -- **Amazon DynamoDB** cho danh mục dữ liệu -- **AWS Lambda** để ghi message vào data lake và danh mục -- **Amazon SNS** topic làm *hub* -- **Amazon S3** bucket cho artifacts như mã Lambda +Theo mình, đây là lựa chọn hợp lý vì dashboard compliance thường chứa thông tin nhạy cảm: account nào có instance chưa patch, nền tảng nào đang thiếu bản vá, và patch severity ra sao. Nếu dashboard này public sai cách thì nó có thể trở thành nguồn thông tin hữu ích cho attacker. -> Chỉ cho phép truy cập ghi gián tiếp vào data lake qua hàm Lambda → đảm bảo nhất quán. +## Kiro Specs và spec-driven development ---- +Phần thú vị nhất của bài là cách dùng **Kiro** để xây dựng giải pháp theo hướng spec-driven development. Thay vì chỉ prompt AI viết code ngay, Kiro chia quá trình thành ba giai đoạn: -## Front door microservice +1. **Requirements**: xác định cần xây dựng gì, dashboard phải hiển thị dữ liệu nào và tiêu chí chấp nhận là gì. +2. **Design**: xác định kiến trúc, data flow, component responsibility, API contract và cache schema. +3. **Tasks**: chia implementation thành các task cụ thể theo thứ tự hợp lý. -- Cung cấp API Gateway để tương tác REST bên ngoài -- Xác thực & ủy quyền dựa trên **OIDC** thông qua **Amazon Cognito** -- Cơ chế *deduplication* tự quản lý bằng DynamoDB thay vì SNS FIFO vì: - 1. SNS deduplication TTL chỉ 5 phút - 2. SNS FIFO yêu cầu SQS FIFO - 3. Chủ động báo cho sender biết message là bản sao +Cách làm này giúp giảm rủi ro khi dùng AI coding assistant. Nếu nhảy thẳng vào code, AI có thể tạo ra kiến trúc không đúng yêu cầu bảo mật hoặc đọc dữ liệu không tối ưu. Với Kiro Specs, các quyết định quan trọng được ghi lại trong spec trước, sau đó mới chuyển sang implementation. ---- +## Steering files: giữ ngữ cảnh cho AI -## Staging ER7 microservice +Bài viết sử dụng các **steering files** trong thư mục `.kiro/steering/`. Đây là các file Markdown mà Kiro tự động đưa vào ngữ cảnh khi làm việc. Mục tiêu là không phải giải thích lại project convention, kiến trúc và quy tắc bảo mật trong mỗi lần trò chuyện. -- Lambda “trigger” đăng ký với pub/sub hub, lọc message theo attribute -- Step Functions Express Workflow để chuyển ER7 → JSON -- Hai Lambda: - 1. Sửa format ER7 (newline, carriage return) - 2. Parsing logic -- Kết quả hoặc lỗi được đẩy lại vào pub/sub hub +Các steering files chính gồm: ---- +- **architecture.md**: mô tả internal ALB, Lambda targets, private VPC, SSM access, EventBridge cache refresh và thông số Lambda. +- **data-schemas.md**: mô tả cấu trúc dữ liệu từ Resource Data Sync và định dạng cache cho summary/detail view. +- **compliance-logic.md**: định nghĩa business rules, ví dụ instance chỉ compliant khi `MissingCount = 0` và `InstalledPendingRebootCount = 0`. +- **frontend-specs.md**: mô tả layout, UI component và cách dùng Cloudscape Design System. +- **security.md**: mô tả baseline bảo mật như HTTPS-only, S3 encryption, least privilege IAM, security headers, input validation và dependency pinning. + +Theo mình, steering files là phần rất thực tế. Khi làm việc với AI, kết quả tốt hay không phụ thuộc nhiều vào context. Nếu context được viết thành file rõ ràng, AI có thể tạo requirement, design và task nhất quán hơn. + +## MCP servers để kiểm tra kết quả + +Steering files giúp Kiro biết phải xây gì, còn MCP servers giúp kiểm tra thứ Kiro tạo ra. Bài viết đề xuất dùng các MCP servers của AWS như: + +- **Security Scanner MCP** để scan vấn đề bảo mật. +- **AWS IaC MCP Server** để kiểm tra Infrastructure as Code theo best practices. + +Điểm mình rút ra là AI không nên chỉ được dùng để sinh code. Nó cũng nên được kết hợp với công cụ validation để kiểm tra code, CloudFormation template và kiến trúc có đi đúng best practices hay không. + +## Dashboard hiển thị gì? + +Dashboard được thiết kế thành hai tầng: + +![Multi-account patch compliance dashboard generated by the spec workflow](/images/3-BlogsTranslated/Blog2/Multi-account_patch_compliance_dashboard_generated_by_the_spec_workflow.png) + +*Nguồn: AWS Cloud Operations Blog - Build a Multi Account Patch Compliance Dashboard with Kiro Specs* + +### Main view + +Main view giúp team trả lời nhanh câu hỏi tổng quan: + +- Tổng số instances. +- Compliance rate. +- Số lượng compliant và non-compliant instances. +- Biểu đồ compliance status. +- Biểu đồ phân loại theo platform như Linux hoặc Windows. +- Biểu đồ missing patches theo severity. +- Bảng account để biết account nào cần xử lý trước. + +### Detail view + +Khi click vào một account, người dùng có thể xem chi tiết hơn: + +- Danh sách instances trong account. +- Instance nào đang non-compliant. +- Số lượng patch còn thiếu. +- Thời điểm scan gần nhất. +- Danh sách patch cụ thể đang thiếu và số instance bị ảnh hưởng. + +Cách chia này hợp lý vì người vận hành thường cần nhìn tổng quan trước, sau đó mới đi sâu vào account hoặc instance có vấn đề. + +## Triển khai và vận hành + +Bài gốc hướng dẫn dùng Kiro tạo deployment script để triển khai và xóa tài nguyên. Script deploy có nhiệm vụ build frontend, đóng gói Lambda, triển khai các CloudFormation stacks theo thứ tự, tạo TLS certificate tự ký cho internal ALB, upload assets, cập nhật Lambda code và kích hoạt cache Lambda để dashboard có dữ liệu trước khi người dùng truy cập. + +Sau khi triển khai, script in ra lệnh SSM port forwarding tương tự: + +```bash +aws ssm start-session \ + --target \ + --document-name AWS-StartPortForwardingSessionToRemoteHost \ + --parameters '{"host":[""],"portNumber":["443"],"localPortNumber":["8443"]}' +``` + +Sau đó người dùng mở `https://localhost:8443/` để truy cập dashboard. + +Bài cũng nhắc đến cleanup để tránh phát sinh chi phí, bao gồm xóa CloudFormation stacks, empty S3 buckets, xóa VPC, ALB, Lambda functions, bastion instance và ACM certificate. + +## Những điểm có thể mở rộng + +Giải pháp trong bài là nền tảng ban đầu, không phải sản phẩm cuối cùng cho mọi tổ chức. Một số hướng mở rộng đáng chú ý: + +- Thêm Amazon Cognito authentication cho nhiều người dùng. +- Server-side pagination nếu có hơn 10.000 instances. +- Tạo custom widgets cho metric compliance riêng. +- Tích hợp Amazon SNS để gửi cảnh báo compliance. +- Tích hợp Amazon Inspector để xem CVE liên quan đến patch còn thiếu. + +## Điều mình học được + +Trước khi đọc bài này, mình thường nghĩ dashboard compliance chỉ là phần frontend hiển thị dữ liệu. Sau khi tìm hiểu, mình thấy phần khó hơn nằm ở kiến trúc dữ liệu và bảo mật truy cập. + +Nếu đọc trực tiếp dữ liệu raw từ S3 mỗi lần mở dashboard, hệ thống có thể chậm và tốn chi phí khi số account tăng lên. Việc tạo cache định kỳ bằng Lambda và EventBridge giúp tách quá trình xử lý nặng khỏi request của người dùng. + +Mình cũng thấy Kiro Specs là một cách làm tốt khi dùng AI để xây dựng hệ thống có yêu cầu rõ ràng. Thay vì để AI tự suy đoán, mình cung cấp steering files, yêu cầu, design và task. Cách này khiến kết quả dễ kiểm soát hơn, đặc biệt với các phần nhạy cảm như IAM, network private access và security baseline. + +## Kết luận + +Bài viết này cho thấy cách kết hợp AWS Systems Manager, Resource Data Sync, Lambda, S3, EventBridge, internal ALB và Session Manager để xây dựng một dashboard patch compliance nhiều account theo hướng serverless và private. + +Điểm nổi bật không chỉ nằm ở dashboard, mà còn ở quy trình phát triển bằng Kiro Specs. Khi yêu cầu, kiến trúc, security rules và task được mô tả rõ ràng từ đầu, AI coding assistant có thể hỗ trợ triển khai nhanh hơn nhưng vẫn giữ được tính kiểm soát. -## Tính năng mới trong giải pháp - -### 1. AWS CloudFormation cross-stack references -Ví dụ *outputs* trong core microservice: -```yaml -Outputs: - Bucket: - Value: !Ref Bucket - Export: - Name: !Sub ${AWS::StackName}-Bucket - ArtifactBucket: - Value: !Ref ArtifactBucket - Export: - Name: !Sub ${AWS::StackName}-ArtifactBucket - Topic: - Value: !Ref Topic - Export: - Name: !Sub ${AWS::StackName}-Topic - Catalog: - Value: !Ref Catalog - Export: - Name: !Sub ${AWS::StackName}-Catalog - CatalogArn: - Value: !GetAtt Catalog.Arn - Export: - Name: !Sub ${AWS::StackName}-CatalogArn +Nếu áp dụng vào môi trường thực tế, mình nghĩ các bước quan trọng nhất là chuẩn hóa Resource Data Sync, định nghĩa compliance logic rõ ràng, thiết kế private access ngay từ đầu, và kiểm tra generated infrastructure bằng các công cụ validation trước khi triển khai production. diff --git a/content/3-BlogsTranslated/3.3-Blog3/_index.md b/content/3-BlogsTranslated/3.3-Blog3/_index.md index 07a1029..adef912 100644 --- a/content/3-BlogsTranslated/3.3-Blog3/_index.md +++ b/content/3-BlogsTranslated/3.3-Blog3/_index.md @@ -1,126 +1,125 @@ --- title: "Blog 3" date: 2024-01-01 -weight: 1 +weight: 3 chapter: false pre: " 3.3. " --- -{{% notice warning %}} -⚠️ **Note:** The information below is for reference purposes only. Please **do not copy verbatim** for your report, including this warning. -{{% /notice %}} -# Getting Started with Healthcare Data Lakes: Using Microservices +# Architecting an AI-Powered Resilience Framework on AWS -Data lakes can help hospitals and healthcare facilities turn data into business insights, maintain business continuity, and protect patient privacy. A **data lake** is a centralized, managed, and secure repository to store all your data, both in its raw and processed forms for analysis. Data lakes allow you to break down data silos and combine different types of analytics to gain insights and make better business decisions. +## References -This blog post is part of a larger series on getting started with setting up a healthcare data lake. In my final post of the series, *“Getting Started with Healthcare Data Lakes: Diving into Amazon Cognito”*, I focused on the specifics of using Amazon Cognito and Attribute Based Access Control (ABAC) to authenticate and authorize users in the healthcare data lake solution. In this blog, I detail how the solution evolved at a foundational level, including the design decisions I made and the additional features used. You can access the code samples for the solution in this Git repo for reference. +- AWS Architecture Blog: [Architecting AI-powered resilience framework on AWS](https://aws.amazon.com/vi/blogs/architecture/architecting-ai-powered-resilience-framework-on-aws/) +- Author: Medha Shree +- Published: June 22, 2026 ---- +## Reading This Changed How I Think About Resilience -## Architecture Guidance +Before reading this article, I usually thought about resilience in terms of familiar AWS patterns: Multi-AZ, Auto Scaling, health checks, backups, retries, and failover. All of those are important, but this blog made me focus on a harder question: **how do we know those resilience mechanisms actually work when failure happens?** -The main change since the last presentation of the overall architecture is the decomposition of a single service into a set of smaller services to improve maintainability and flexibility. Integrating a large volume of diverse healthcare data often requires specialized connectors for each format; by keeping them encapsulated separately as microservices, we can add, remove, and modify each connector without affecting the others. The microservices are loosely coupled via publish/subscribe messaging centered in what I call the “pub/sub hub.” +A system can look resilient in an architecture diagram, but production keeps changing. A new service call appears, a connection string gets hard-coded, a timeout value is misconfigured, a temporary dependency becomes permanent, or a quick hotfix never makes it back into the documentation. When an incident happens, the team may discover that an important weakness was never tested. -This solution represents what I would consider another reasonable sprint iteration from my last post. The scope is still limited to the ingestion and basic parsing of **HL7v2 messages** formatted in **Encoding Rules 7 (ER7)** through a REST interface. +The main message I took from the AWS blog is simple: **resilience should be proven continuously, not assumed once during design**. -**The solution architecture is now as follows:** +## Why Resilience Testing Is Difficult -> *Figure 1. Overall architecture; colored boxes represent distinct services.* +At the infrastructure level, it is easy to list the services an application uses: EC2, RDS, Lambda, DynamoDB, S3, or a load balancer. But resilience is not only about resources. It also depends on how the application calls dependencies, how retries are configured, how timeouts behave, how circuit breakers react, and how the team recovers when something fails. ---- +The problem is that this information is scattered across many places: architecture diagrams, CloudFormation or Terraform, source code, runbooks, logs, dashboards, and the knowledge of individual teams. When systems deploy continuously, documentation falls behind quickly. -While the term *microservices* has some inherent ambiguity, certain traits are common: -- Small, autonomous, loosely coupled -- Reusable, communicating through well-defined interfaces -- Specialized to do one thing well -- Often implemented in an **event-driven architecture** +That is why the article proposes an AI-powered resilience framework. AI is not used to randomly break systems. It is used to help teams understand the system more deeply, find hidden dependencies, generate relevant experiments, and bring resilience testing into the normal development workflow. -When determining where to draw boundaries between microservices, consider: -- **Intrinsic**: technology used, performance, reliability, scalability -- **Extrinsic**: dependent functionality, rate of change, reusability -- **Human**: team ownership, managing *cognitive load* +## The Five-Layer Framework ---- +The AWS article breaks the framework into five layers: Discovery, Test Generation, Experimentation, Gap Analysis, and Continuous Validation. I understand them this way: -## Technology Choices and Communication Scope +| Layer | My interpretation | +| --- | --- | +| Discovery | Find what the system actually depends on | +| Test Generation | Create failure scenarios that match the system’s real risks | +| Experimentation | Run chaos experiments with guardrails and stop conditions | +| Gap Analysis | Analyze weaknesses and prioritize remediation | +| Continuous Validation | Bring resilience checks into CI/CD to prevent regressions | -| Communication scope | Technologies / patterns to consider | -| ----------------------------------------- | ------------------------------------------------------------------------------------------ | -| Within a single microservice | Amazon Simple Queue Service (Amazon SQS), AWS Step Functions | -| Between microservices in a single service | AWS CloudFormation cross-stack references, Amazon Simple Notification Service (Amazon SNS) | -| Between services | Amazon EventBridge, AWS Cloud Map, Amazon API Gateway | +What I like about this structure is that it creates a loop. Resilience testing is not something the team runs once and forgets. Every time the system changes, the dependency map and experiments should evolve with it. ---- +## Discovery Is the Part Teams Often Underestimate -## The Pub/Sub Hub +The Discovery layer stood out to me the most. The next generation of AWS Resilience Hub can perform native dependency discovery to identify AWS services, internal endpoints, and third-party endpoints used by an application. A custom agent running on Amazon Bedrock AgentCore can then extend this analysis into code and Infrastructure as Code. -Using a **hub-and-spoke** architecture (or message broker) works well with a small number of tightly related microservices. -- Each microservice depends only on the *hub* -- Inter-microservice connections are limited to the contents of the published message -- Reduces the number of synchronous calls since pub/sub is a one-way asynchronous *push* +The agent can inspect CloudFormation, Terraform, source repositories, connection strings, timeout settings, retry logic, and circuit breakers. This matters because many resilience issues do not show up in architecture diagrams. They live in runtime behavior and application code. -Drawback: **coordination and monitoring** are needed to avoid microservices processing the wrong message. +For example, a database may run in Multi-AZ mode, but if the application does not retry connections properly during failover, users can still see errors. On paper, the architecture looks resilient. In practice, the application behavior may not be. ---- +According to the article, initial discovery can reduce infrastructure mapping from weeks to hours for a single-account environment with thousands of resources. Later runs can process only changes tracked by AWS Config. That is valuable because the architecture map becomes closer to the actual runtime state instead of a static document. -## Core Microservice +## AI Helps Generate Experiments with Context -Provides foundational data and communication layer, including: -- **Amazon S3** bucket for data -- **Amazon DynamoDB** for data catalog -- **AWS Lambda** to write messages into the data lake and catalog -- **Amazon SNS** topic as the *hub* -- **Amazon S3** bucket for artifacts such as Lambda code +After the system understands dependencies, the next step is experiment generation. This is where Amazon Bedrock and Amazon Bedrock AgentCore become useful. -> Only allow indirect write access to the data lake through a Lambda function → ensures consistency. +Instead of running generic tests like “stop an instance” or “inject latency” without a clear reason, the framework uses system context to generate meaningful hypotheses. It can combine the dependency map, RTO, RPO, availability targets, application tier, and business impact to prioritize experiments. ---- +For example, if a customer-facing service depends on a critical database, a database failover experiment may deserve higher priority than a low-impact internal test. If a dependency looks like a single point of failure, experiments around that dependency should move up the list. -## Front Door Microservice +This is where AI adds real value. It does not completely replace SREs or cloud architects. It acts more like an assistant that gathers context, highlights risk, and suggests what to validate. Whether an experiment should run in production still requires approval, review, and guardrails. The article also recommends AWS Step Functions for manual approval workflows before sensitive experiments run. -- Provides an API Gateway for external REST interaction -- Authentication & authorization based on **OIDC** via **Amazon Cognito** -- Self-managed *deduplication* mechanism using DynamoDB instead of SNS FIFO because: - 1. SNS deduplication TTL is only 5 minutes - 2. SNS FIFO requires SQS FIFO - 3. Ability to proactively notify the sender that the message is a duplicate +## Chaos Engineering Is Not Randomly Breaking Systems ---- +Chaos engineering is sometimes misunderstood as intentionally breaking production. This article makes the opposite point: experiments must be controlled. -## Staging ER7 Microservice +AWS Fault Injection Service can run scenarios such as terminating EC2 instances, injecting network latency, throttling API calls, failing over Amazon RDS, or simulating Availability Zone connectivity issues. But experiments should not begin with a large blast radius. The article suggests starting small, such as 1% of resources, and then expanding to 5%, 10%, or 25% only when results remain safe. -- Lambda “trigger” subscribed to the pub/sub hub, filtering messages by attribute -- Step Functions Express Workflow to convert ER7 → JSON -- Two Lambdas: - 1. Fix ER7 formatting (newline, carriage return) - 2. Parsing logic -- Result or error is pushed back into the pub/sub hub +Amazon CloudWatch alarms act as stop conditions. If error rate, latency, or availability approaches a risky threshold, the experiment should stop before it seriously affects the SLA. This is what makes chaos engineering practical: the goal is to learn from failure inside a safe boundary, not to create another outage. ---- +## Every Experiment Should Teach the System Something + +Running experiments only to generate reports is not enough. The article adds a Gap Analysis layer to turn test results into action. + +AWS Resilience Hub can correlate experiment outcomes with resilience policies and classify gaps across architecture, operations, data protection, and testing coverage. Each gap is prioritized by severity, likelihood, and business impact. That makes sense because not every gap deserves the same urgency. + +Another useful point is the role of AWS Systems Manager Automation documents. If a recovery procedure is validated through an experiment, the team can codify it as an automation runbook. Over time, this can reduce MTTR because the team is not reinventing recovery steps during a real incident. + +In other words, the framework does not only find weaknesses. It helps turn lessons from testing into reusable improvements. + +## Bringing Resilience into CI/CD + +The Continuous Validation layer makes the framework feel practical. Resilience testing should not be something teams run occasionally or only before a major launch. It should be part of the pipeline. + +The article suggests a two-tier model. The lightweight tier is policy-as-code checking, such as using Open Policy Agent to validate Infrastructure as Code or Dockerfiles. These checks run quickly on every commit and can catch basic issues like missing health checks, single-AZ configuration, or missing resilience baselines. + +The heavier tier is a full resilience assessment, better suited for pre-production gates or significant architecture changes. For routine deployments, teams can run a smaller set of regression tests around critical scenarios such as database failover, Availability Zone loss, or circuit breaker activation. + +This is a realistic approach because it avoids slowing down every pipeline run while still catching meaningful risks before production. Resilience shifts left, similar to how security testing and unit testing became part of modern delivery workflows. + +## Scaling to Enterprise Requires Discipline + +The article also recommends a phased rollout. It would be risky to apply the framework to all production workloads immediately. + +A good starting point is a non-critical application with a well-understood architecture. Enable AWS Config, deploy the discovery agent on Amazon Bedrock AgentCore, and run a baseline assessment in AWS Resilience Hub. After the team understands the workflow, expand to a few applications across different tiers and run small-scope experiments during low-traffic windows. + +At enterprise scale, the article discusses multi-account architecture, centralized reporting, cross-account experiment coordination, shared templates through AWS Organizations, and dashboards with Amazon QuickSight. At that stage, tiered resilience policies matter because a mission-critical workload should not have the same RTO, RPO, or testing cadence as a low-impact internal workload. + +## AI Agent Security Is Part of the Architecture + +One point I would not skip is agent security. Because the agent can read infrastructure, code, and configuration context, its permissions must be scoped carefully. + +The article emphasizes least privilege, read-only access during discovery, audit trails through AWS CloudTrail, encryption with AWS KMS, and guardrails for Amazon Bedrock. Amazon Bedrock AgentCore Runtime also provides MicroVM session isolation so each discovery session runs in a separated environment. + +For me, this is an important reminder: using AI in cloud operations does not mean giving AI unlimited control. The agent needs clear boundaries, scoped IAM permissions, logging, approval gates, and guardrails. + +## What I Took Away + +This blog made me think about resilience testing in a more mature way. Before reading it, I saw AWS FIS experiments as the main activity. Now I think the stronger starting point is dependency discovery. If the dependency map is wrong, experiments can look sophisticated while testing the wrong thing. + +AI fits this problem because resilience involves many types of context: infrastructure, code, dependencies, RTO/RPO, business impact, previous experiment results, and CI/CD changes. An AI agent can combine those signals and suggest better tests, but execution still needs guardrails, approvals, and monitoring. + +The lesson that stayed with me is this: systems will fail. The difference is whether we discover weaknesses during controlled experiments or let customers discover them in production. + +## Conclusion + +The AWS article presents a strong approach for combining AWS Resilience Hub, AWS Fault Injection Service, Amazon Bedrock AgentCore, AWS Systems Manager, AWS Config, and CloudWatch into a continuous resilience testing loop. + +The value is not only automated chaos experiment generation. The bigger value is turning resilience into a living process: discover dependencies, generate contextual tests, run experiments safely, analyze gaps, automate remediation, and validate again through CI/CD. -## New Features in the Solution - -### 1. AWS CloudFormation Cross-Stack References -Example *outputs* in the core microservice: -```yaml -Outputs: - Bucket: - Value: !Ref Bucket - Export: - Name: !Sub ${AWS::StackName}-Bucket - ArtifactBucket: - Value: !Ref ArtifactBucket - Export: - Name: !Sub ${AWS::StackName}-ArtifactBucket - Topic: - Value: !Ref Topic - Export: - Name: !Sub ${AWS::StackName}-Topic - Catalog: - Value: !Ref Catalog - Export: - Name: !Sub ${AWS::StackName}-Catalog - CatalogArn: - Value: !GetAtt Catalog.Arn - Export: - Name: !Sub ${AWS::StackName}-CatalogArn +If I were applying this in a real environment, I would start with a non-critical application, define clear RTO and RPO targets, enable AWS Config, run an AWS Resilience Hub assessment, and only then introduce the AI agent and automated experiments. Once the team trusts the guardrails and review process, the framework can expand to more important workloads. diff --git a/content/3-BlogsTranslated/3.3-Blog3/_index.vi.md b/content/3-BlogsTranslated/3.3-Blog3/_index.vi.md index 09a5a2e..f36bc92 100644 --- a/content/3-BlogsTranslated/3.3-Blog3/_index.vi.md +++ b/content/3-BlogsTranslated/3.3-Blog3/_index.vi.md @@ -1,127 +1,125 @@ --- title: "Blog 3" date: 2024-01-01 -weight: 1 +weight: 3 chapter: false pre: " 3.3. " --- -{{% notice warning %}} -⚠️ **Lưu ý:** Các thông tin dưới đây chỉ nhằm mục đích tham khảo, vui lòng **không sao chép nguyên văn** cho bài báo cáo của bạn kể cả warning này. -{{% /notice %}} +# Kiến trúc AI-powered Resilience Framework trên AWS -# Bắt đầu với healthcare data lakes: Sử dụng microservices +## Nguồn tham khảo -Các data lake có thể giúp các bệnh viện và cơ sở y tế chuyển dữ liệu thành những thông tin chi tiết về doanh nghiệp và duy trì hoạt động kinh doanh liên tục, đồng thời bảo vệ quyền riêng tư của bệnh nhân. **Data lake** là một kho lưu trữ tập trung, được quản lý và bảo mật để lưu trữ tất cả dữ liệu của bạn, cả ở dạng ban đầu và đã xử lý để phân tích. data lake cho phép bạn chia nhỏ các kho chứa dữ liệu và kết hợp các loại phân tích khác nhau để có được thông tin chi tiết và đưa ra các quyết định kinh doanh tốt hơn. +- AWS Architecture Blog: [Architecting AI-powered resilience framework on AWS](https://aws.amazon.com/vi/blogs/architecture/architecting-ai-powered-resilience-framework-on-aws/) +- Tác giả: Medha Shree +- Ngày phát hành: 22/06/2026 -Bài đăng trên blog này là một phần của loạt bài lớn hơn về việc bắt đầu cài đặt data lake dành cho lĩnh vực y tế. Trong bài đăng blog cuối cùng của tôi trong loạt bài, *“Bắt đầu với data lake dành cho lĩnh vực y tế: Đào sâu vào Amazon Cognito”*, tôi tập trung vào các chi tiết cụ thể của việc sử dụng Amazon Cognito và Attribute Based Access Control (ABAC) để xác thực và ủy quyền người dùng trong giải pháp data lake y tế. Trong blog này, tôi trình bày chi tiết cách giải pháp đã phát triển ở cấp độ cơ bản, bao gồm các quyết định thiết kế mà tôi đã đưa ra và các tính năng bổ sung được sử dụng. Bạn có thể truy cập các code samples cho giải pháp tại Git repo này để tham khảo. +## Sau khi đọc bài này, mình hiểu resilience theo một cách khác ---- +Trước đây, khi nghĩ về resilience trên AWS, mình thường nghĩ đến những thiết kế quen thuộc như Multi-AZ, Auto Scaling, health check, backup, retry hoặc failover. Những thứ đó đều quan trọng, nhưng bài blog này làm mình chú ý đến một câu hỏi khác: **làm sao biết chắc các cơ chế resilience đó thật sự hoạt động khi hệ thống gặp lỗi?** -## Hướng dẫn kiến trúc +Một hệ thống có thể được thiết kế rất đẹp trên sơ đồ kiến trúc, nhưng production lại luôn thay đổi. Một service mới được thêm vào, một connection string bị hard-code trong code, một timeout cấu hình sai, một dependency tạm thời trở thành dependency lâu dài, hoặc một hotfix không được cập nhật lại vào tài liệu. Đến lúc sự cố xảy ra, team mới phát hiện hệ thống có một điểm yếu chưa từng được kiểm thử. -Thay đổi chính kể từ lần trình bày cuối cùng của kiến trúc tổng thể là việc tách dịch vụ đơn lẻ thành một tập hợp các dịch vụ nhỏ để cải thiện khả năng bảo trì và tính linh hoạt. Việc tích hợp một lượng lớn dữ liệu y tế khác nhau thường yêu cầu các trình kết nối chuyên biệt cho từng định dạng; bằng cách giữ chúng được đóng gói riêng biệt với microservices, chúng ta có thể thêm, xóa và sửa đổi từng trình kết nối mà không ảnh hưởng đến những kết nối khác. Các microservices được kết nối rời thông qua tin nhắn publish/subscribe tập trung trong cái mà tôi gọi là “pub/sub hub”. +Thông điệp mình rút ra từ bài AWS này là: **resilience không nên chỉ được giả định, mà phải được kiểm chứng liên tục**. -Giải pháp này đại diện cho những gì tôi sẽ coi là một lần lặp nước rút hợp lý khác từ last post của tôi. Phạm vi vẫn được giới hạn trong việc nhập và phân tích cú pháp đơn giản của các **HL7v2 messages** được định dạng theo **Quy tắc mã hóa 7 (ER7)** thông qua giao diện REST. +## Vì sao resilience testing khó? -**Kiến trúc giải pháp bây giờ như sau:** +Nếu chỉ nhìn ở mức hạ tầng, chúng ta có thể biết ứng dụng đang dùng EC2, RDS, Lambda, DynamoDB, S3 hay Load Balancer. Nhưng resilience không chỉ nằm ở resource. Nó còn nằm ở cách ứng dụng gọi dependency, cách retry được cấu hình, cách timeout hoạt động, cách circuit breaker phản ứng, và cách team khôi phục khi một thành phần bị lỗi. -> *Hình 1. Kiến trúc tổng thể; những ô màu thể hiện những dịch vụ riêng biệt.* +Vấn đề là những thông tin này thường nằm rải rác ở nhiều nơi: architecture diagram, CloudFormation hoặc Terraform, source code, runbook, log, dashboard và cả kinh nghiệm của từng team. Khi hệ thống deploy liên tục, tài liệu rất dễ bị lỗi thời. ---- +Đó là lý do bài viết đề xuất một AI-powered resilience framework. AI ở đây không phải để “tự động phá hệ thống”, mà để giúp team hiểu hệ thống kỹ hơn, tìm dependency ẩn, tạo experiment phù hợp và đưa việc kiểm thử resilience vào quy trình phát triển hằng ngày. -Mặc dù thuật ngữ *microservices* có một số sự mơ hồ cố hữu, một số đặc điểm là chung: -- Chúng nhỏ, tự chủ, kết hợp rời rạc -- Có thể tái sử dụng, giao tiếp thông qua giao diện được xác định rõ -- Chuyên biệt để giải quyết một việc -- Thường được triển khai trong **event-driven architecture** +## Framework 5 lớp: từ hiểu hệ thống đến kiểm chứng liên tục -Khi xác định vị trí tạo ranh giới giữa các microservices, cần cân nhắc: -- **Nội tại**: công nghệ được sử dụng, hiệu suất, độ tin cậy, khả năng mở rộng -- **Bên ngoài**: chức năng phụ thuộc, tần suất thay đổi, khả năng tái sử dụng -- **Con người**: quyền sở hữu nhóm, quản lý *cognitive load* +Bài AWS chia framework thành 5 lớp: Discovery, Test Generation, Experimentation, Gap Analysis và Continuous Validation. Mình hiểu đơn giản như sau: ---- +| Lớp | Mình hiểu là | +| --- | --- | +| Discovery | Tìm xem hệ thống thật sự đang phụ thuộc vào những gì | +| Test Generation | Tạo các kịch bản lỗi đúng với kiến trúc và rủi ro của hệ thống | +| Experimentation | Chạy chaos experiment có kiểm soát, có guardrail và stop condition | +| Gap Analysis | Phân tích điểm yếu sau khi test và ưu tiên hướng xử lý | +| Continuous Validation | Đưa resilience checks vào CI/CD để tránh regression sau mỗi lần thay đổi | -## Lựa chọn công nghệ và phạm vi giao tiếp +Điều mình thích ở cách chia này là nó tạo thành một vòng lặp. Không phải chạy một lần rồi thôi, mà mỗi lần hệ thống thay đổi, dependency map và experiment cũng nên được cập nhật theo. -| Phạm vi giao tiếp | Các công nghệ / mô hình cần xem xét | -| ---------------------------------------- | ------------------------------------------------------------------------------------------ | -| Trong một microservice | Amazon Simple Queue Service (Amazon SQS), AWS Step Functions | -| Giữa các microservices trong một dịch vụ | AWS CloudFormation cross-stack references, Amazon Simple Notification Service (Amazon SNS) | -| Giữa các dịch vụ | Amazon EventBridge, AWS Cloud Map, Amazon API Gateway | +## Discovery: phần quan trọng nhất thường bị xem nhẹ ---- +Phần Discovery làm mình ấn tượng nhất. AWS Resilience Hub thế hệ mới có khả năng native dependency discovery để tìm các AWS services, internal endpoints và third-party endpoints mà ứng dụng đang dùng. Sau đó, custom agent chạy trên Amazon Bedrock AgentCore có thể mở rộng việc phân tích xuống tầng code và Infrastructure as Code. -## The pub/sub hub +Agent có thể đọc CloudFormation, Terraform, repository code, connection string, timeout configuration, retry logic và circuit breaker. Đây là điểm rất thực tế, vì nhiều vấn đề resilience không nằm trên sơ đồ kiến trúc mà nằm trong cách code vận hành. -Việc sử dụng kiến trúc **hub-and-spoke** (hay message broker) hoạt động tốt với một số lượng nhỏ các microservices liên quan chặt chẽ. -- Mỗi microservice chỉ phụ thuộc vào *hub* -- Kết nối giữa các microservice chỉ giới hạn ở nội dung của message được xuất -- Giảm số lượng synchronous calls vì pub/sub là *push* không đồng bộ một chiều +Ví dụ, một database có thể đã bật Multi-AZ, nhưng nếu application không xử lý retry khi failover thì người dùng vẫn có thể gặp lỗi. Trên giấy tờ, kiến trúc có vẻ resilient. Trong thực tế, behavior của ứng dụng lại chưa chắc resilient. -Nhược điểm: cần **phối hợp và giám sát** để tránh microservice xử lý nhầm message. +Theo bài gốc, discovery ban đầu có thể rút ngắn từ vài tuần xuống còn vài giờ trong môi trường single-account có hàng ngàn resource. Các lần chạy sau có thể dựa vào AWS Config để chỉ xử lý phần thay đổi. Với mình, đây là giá trị lớn: architecture map không còn là tài liệu tĩnh mà tiến gần hơn đến trạng thái runtime thật. ---- +## AI giúp tạo experiment có ngữ cảnh hơn -## Core microservice +Sau khi hiểu dependency, bước tiếp theo là tạo experiment. Đây là nơi Amazon Bedrock và Amazon Bedrock AgentCore phát huy vai trò. -Cung cấp dữ liệu nền tảng và lớp truyền thông, gồm: -- **Amazon S3** bucket cho dữ liệu -- **Amazon DynamoDB** cho danh mục dữ liệu -- **AWS Lambda** để ghi message vào data lake và danh mục -- **Amazon SNS** topic làm *hub* -- **Amazon S3** bucket cho artifacts như mã Lambda +Thay vì chạy các bài test chung chung như “tắt một instance” hoặc “inject network latency” mà không rõ mục tiêu, framework dùng context của hệ thống để tạo các hypothesis có ý nghĩa hơn. Nó có thể kết hợp dependency map, RTO, RPO, availability target, application tier và business impact để ưu tiên experiment. -> Chỉ cho phép truy cập ghi gián tiếp vào data lake qua hàm Lambda → đảm bảo nhất quán. +Ví dụ, nếu một service customer-facing phụ thuộc vào một database quan trọng, experiment về database failover có thể đáng ưu tiên hơn một test ít ảnh hưởng đến người dùng. Nếu một dependency có dấu hiệu single point of failure, experiment liên quan đến dependency đó nên được đưa lên trước. ---- +Điểm mình thấy hay là AI không thay thế hoàn toàn SRE hay cloud architect. Nó giống một trợ lý giúp gom thông tin, chỉ ra rủi ro và đề xuất hướng kiểm thử. Còn việc có chạy experiment trong production hay không vẫn cần approval, review và guardrail rõ ràng. Bài viết cũng đề xuất dùng AWS Step Functions để tạo manual approval workflow trước khi chạy các experiment nhạy cảm. -## Front door microservice +## Chaos engineering không phải là làm hỏng hệ thống một cách ngẫu nhiên -- Cung cấp API Gateway để tương tác REST bên ngoài -- Xác thực & ủy quyền dựa trên **OIDC** thông qua **Amazon Cognito** -- Cơ chế *deduplication* tự quản lý bằng DynamoDB thay vì SNS FIFO vì: - 1. SNS deduplication TTL chỉ 5 phút - 2. SNS FIFO yêu cầu SQS FIFO - 3. Chủ động báo cho sender biết message là bản sao +Một hiểu lầm phổ biến là chaos engineering nghĩa là cố tình làm sập hệ thống. Bài này giải thích ngược lại: chaos experiment phải được thiết kế có kiểm soát. ---- +AWS Fault Injection Service được dùng để chạy các kịch bản như terminate EC2 instance, inject network latency, throttle API call, failover Amazon RDS hoặc mô phỏng vấn đề ở Availability Zone. Nhưng experiment không nên bắt đầu với phạm vi lớn. Bài viết gợi ý bắt đầu rất nhỏ, ví dụ 1% resource, rồi tăng dần lên 5%, 10% hoặc 25% tùy mức độ an toàn và risk tolerance. -## Staging ER7 microservice +Amazon CloudWatch alarms đóng vai trò stop condition. Nếu error rate, latency hoặc availability bắt đầu tiến gần ngưỡng rủi ro, experiment phải dừng lại trước khi ảnh hưởng nghiêm trọng đến SLA. Mình thấy đây là phần làm cho chaos engineering trở nên thực dụng hơn: mục tiêu là học từ lỗi trong phạm vi an toàn, không phải tạo thêm outage. -- Lambda “trigger” đăng ký với pub/sub hub, lọc message theo attribute -- Step Functions Express Workflow để chuyển ER7 → JSON -- Hai Lambda: - 1. Sửa format ER7 (newline, carriage return) - 2. Parsing logic -- Kết quả hoặc lỗi được đẩy lại vào pub/sub hub +## Sau mỗi experiment, hệ thống phải học được điều gì đó ---- +Nếu chạy experiment xong chỉ để có report thì chưa đủ. Bài viết đưa ra lớp Gap Analysis để biến kết quả test thành hành động cụ thể. + +AWS Resilience Hub có thể liên kết kết quả experiment với resilience policy và phân loại gap theo nhiều nhóm: kiến trúc, vận hành, bảo vệ dữ liệu và phạm vi kiểm thử. Mỗi gap được ưu tiên theo severity, likelihood và business impact. Cách này hợp lý vì không phải gap nào cũng quan trọng như nhau. + +Một điểm mình thích là AWS Systems Manager Automation documents có thể được dùng để biến recovery procedure thành automation runbook. Nếu một cách khôi phục đã được kiểm chứng qua experiment, team có thể codify nó để giảm MTTR trong sự cố thật. + +Nói cách khác, framework không chỉ tìm lỗi. Nó còn giúp biến bài học sau mỗi lần kiểm thử thành cải tiến có thể tái sử dụng. + +## Đưa resilience vào CI/CD thay vì để cuối dự án + +Phần Continuous Validation là phần làm bài viết này khác với cách nghĩ truyền thống. Resilience testing không nên là hoạt động thỉnh thoảng mới làm, hoặc chỉ làm trước khi go-live. Nó nên được đưa vào pipeline. + +Bài viết đề xuất một cách làm hai tầng. Tầng nhẹ là policy-as-code check, ví dụ dùng Open Policy Agent để kiểm tra Infrastructure as Code hoặc Dockerfile. Các check này chạy nhanh trong mỗi commit và giúp phát hiện lỗi cơ bản như thiếu health check, cấu hình single-AZ hoặc thiếu baseline resilience. + +Tầng nặng hơn là full resilience assessment, phù hợp với pre-production gate hoặc khi có thay đổi kiến trúc đáng kể. Với deployment thường ngày, có thể chỉ chạy một số regression test quan trọng như database failover, Availability Zone loss hoặc circuit breaker activation. + +Mình thấy cách chia này thực tế vì không làm pipeline quá chậm, nhưng vẫn giúp phát hiện vấn đề trước production. Resilience vì vậy được shift-left, giống như security testing hoặc unit testing trong quy trình phát triển hiện đại. + +## Khi scale lên enterprise thì cần cẩn thận hơn + +Bài viết cũng nói về cách triển khai theo giai đoạn. Không nên vừa đọc xong là áp dụng ngay cho toàn bộ production. + +Giai đoạn đầu nên chọn một ứng dụng không quá critical, kiến trúc tương đối dễ hiểu, bật AWS Config, deploy discovery agent trên Amazon Bedrock AgentCore và chạy baseline assessment trong AWS Resilience Hub. Khi team đã hiểu cách framework hoạt động, có thể mở rộng sang vài ứng dụng khác ở nhiều tier khác nhau và bắt đầu chạy experiment với scope nhỏ trong thời gian low-traffic. + +Khi triển khai ở quy mô enterprise, bài viết đề xuất multi-account architecture, centralized reporting, cross-account experiment coordination, shared templates qua AWS Organizations và dashboard bằng Amazon QuickSight. Lúc này cũng cần chính sách resilience theo tier, vì ứng dụng mission-critical không thể có cùng RTO/RPO và tần suất kiểm thử với workload ít quan trọng. + +## Bảo mật cho AI agent cũng là một phần của kiến trúc + +Một điểm mình nghĩ không nên bỏ qua là bảo mật cho AI agent. Vì agent có thể đọc thông tin hạ tầng, code và cấu hình, quyền của nó phải được giới hạn rõ ràng. + +Bài viết nhấn mạnh least privilege, read-only access trong giai đoạn discovery, audit bằng AWS CloudTrail, encryption bằng AWS KMS và guardrail cho Amazon Bedrock. Amazon Bedrock AgentCore Runtime cung cấp MicroVM session isolation để mỗi discovery session chạy trong môi trường tách biệt. + +Với mình, đây là nhắc nhở quan trọng: dùng AI trong cloud operations không có nghĩa là trao toàn quyền cho AI. AI agent nên hoạt động trong một boundary rõ ràng, có IAM scope, logging, approval gate và guardrail. + +## Điều mình rút ra + +Bài blog này làm mình nhìn resilience testing theo hướng trưởng thành hơn. Trước đây mình nghĩ dùng AWS FIS để mô phỏng lỗi đã là phần chính. Nhưng thật ra, trước khi test, mình phải hiểu hệ thống đang phụ thuộc vào gì. Nếu dependency map sai, experiment có thể chạy rất “xịn” nhưng vẫn kiểm thử nhầm thứ. + +AI phù hợp với bài toán này vì nó có thể xử lý nhiều loại context cùng lúc: infrastructure, code, dependency, RTO/RPO, business impact, kết quả experiment cũ và thay đổi trong CI/CD. Nhưng AI chỉ nên hỗ trợ phân tích và đề xuất. Phần thực thi vẫn cần guardrail, approval và monitoring. + +Thông điệp mình nhớ nhất là: hệ thống chắc chắn sẽ có lúc gặp lỗi. Sự khác biệt nằm ở việc mình phát hiện điểm yếu trong một experiment có kiểm soát, hay để khách hàng phát hiện nó trong production. + +## Kết luận + +Bài viết của AWS cho thấy một hướng tiếp cận rất đáng học: kết hợp AWS Resilience Hub, AWS Fault Injection Service, Amazon Bedrock AgentCore, AWS Systems Manager, AWS Config và CloudWatch để tạo một vòng lặp resilience testing liên tục. + +Giá trị lớn nhất không chỉ là tự động tạo chaos experiment, mà là biến resilience thành một quy trình sống: khám phá dependency, tạo test đúng ngữ cảnh, chạy experiment an toàn, phân tích gap, tự động hóa remediation và kiểm chứng lại trong CI/CD. -## Tính năng mới trong giải pháp - -### 1. AWS CloudFormation cross-stack references -Ví dụ *outputs* trong core microservice: -```yaml -Outputs: - Bucket: - Value: !Ref Bucket - Export: - Name: !Sub ${AWS::StackName}-Bucket - ArtifactBucket: - Value: !Ref ArtifactBucket - Export: - Name: !Sub ${AWS::StackName}-ArtifactBucket - Topic: - Value: !Ref Topic - Export: - Name: !Sub ${AWS::StackName}-Topic - Catalog: - Value: !Ref Catalog - Export: - Name: !Sub ${AWS::StackName}-Catalog - CatalogArn: - Value: !GetAtt Catalog.Arn - Export: - Name: !Sub ${AWS::StackName}-CatalogArn +Nếu áp dụng thực tế, mình sẽ bắt đầu nhỏ với một ứng dụng không quá critical, xác định RTO/RPO rõ ràng, bật AWS Config, chạy assessment trong AWS Resilience Hub, rồi mới đưa AI agent và experiment tự động vào. Khi team đã tin vào guardrail và quy trình review, lúc đó mới nên mở rộng sang workload quan trọng hơn. diff --git a/content/3-BlogsTranslated/3.4-Blog4/_index.md b/content/3-BlogsTranslated/3.4-Blog4/_index.md deleted file mode 100644 index 464c5b3..0000000 --- a/content/3-BlogsTranslated/3.4-Blog4/_index.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -title: "Blog 4" -date: 2024-01-01 -weight: 1 -chapter: false -pre: " 3.4. " ---- -{{% notice warning %}} -⚠️ **Note:** The information below is for reference purposes only. Please **do not copy verbatim** for your report, including this warning. -{{% /notice %}} - -# Getting Started with Healthcare Data Lakes: Using Microservices - -Data lakes can help hospitals and healthcare facilities turn data into business insights, maintain business continuity, and protect patient privacy. A **data lake** is a centralized, managed, and secure repository to store all your data, both in its raw and processed forms for analysis. Data lakes allow you to break down data silos and combine different types of analytics to gain insights and make better business decisions. - -This blog post is part of a larger series on getting started with setting up a healthcare data lake. In my final post of the series, *“Getting Started with Healthcare Data Lakes: Diving into Amazon Cognito”*, I focused on the specifics of using Amazon Cognito and Attribute Based Access Control (ABAC) to authenticate and authorize users in the healthcare data lake solution. In this blog, I detail how the solution evolved at a foundational level, including the design decisions I made and the additional features used. You can access the code samples for the solution in this Git repo for reference. - ---- - -## Architecture Guidance - -The main change since the last presentation of the overall architecture is the decomposition of a single service into a set of smaller services to improve maintainability and flexibility. Integrating a large volume of diverse healthcare data often requires specialized connectors for each format; by keeping them encapsulated separately as microservices, we can add, remove, and modify each connector without affecting the others. The microservices are loosely coupled via publish/subscribe messaging centered in what I call the “pub/sub hub.” - -This solution represents what I would consider another reasonable sprint iteration from my last post. The scope is still limited to the ingestion and basic parsing of **HL7v2 messages** formatted in **Encoding Rules 7 (ER7)** through a REST interface. - -**The solution architecture is now as follows:** - -> *Figure 1. Overall architecture; colored boxes represent distinct services.* - ---- - -While the term *microservices* has some inherent ambiguity, certain traits are common: -- Small, autonomous, loosely coupled -- Reusable, communicating through well-defined interfaces -- Specialized to do one thing well -- Often implemented in an **event-driven architecture** - -When determining where to draw boundaries between microservices, consider: -- **Intrinsic**: technology used, performance, reliability, scalability -- **Extrinsic**: dependent functionality, rate of change, reusability -- **Human**: team ownership, managing *cognitive load* - ---- - -## Technology Choices and Communication Scope - -| Communication scope | Technologies / patterns to consider | -| ----------------------------------------- | ------------------------------------------------------------------------------------------ | -| Within a single microservice | Amazon Simple Queue Service (Amazon SQS), AWS Step Functions | -| Between microservices in a single service | AWS CloudFormation cross-stack references, Amazon Simple Notification Service (Amazon SNS) | -| Between services | Amazon EventBridge, AWS Cloud Map, Amazon API Gateway | - ---- - -## The Pub/Sub Hub - -Using a **hub-and-spoke** architecture (or message broker) works well with a small number of tightly related microservices. -- Each microservice depends only on the *hub* -- Inter-microservice connections are limited to the contents of the published message -- Reduces the number of synchronous calls since pub/sub is a one-way asynchronous *push* - -Drawback: **coordination and monitoring** are needed to avoid microservices processing the wrong message. - ---- - -## Core Microservice - -Provides foundational data and communication layer, including: -- **Amazon S3** bucket for data -- **Amazon DynamoDB** for data catalog -- **AWS Lambda** to write messages into the data lake and catalog -- **Amazon SNS** topic as the *hub* -- **Amazon S3** bucket for artifacts such as Lambda code - -> Only allow indirect write access to the data lake through a Lambda function → ensures consistency. - ---- - -## Front Door Microservice - -- Provides an API Gateway for external REST interaction -- Authentication & authorization based on **OIDC** via **Amazon Cognito** -- Self-managed *deduplication* mechanism using DynamoDB instead of SNS FIFO because: - 1. SNS deduplication TTL is only 5 minutes - 2. SNS FIFO requires SQS FIFO - 3. Ability to proactively notify the sender that the message is a duplicate - ---- - -## Staging ER7 Microservice - -- Lambda “trigger” subscribed to the pub/sub hub, filtering messages by attribute -- Step Functions Express Workflow to convert ER7 → JSON -- Two Lambdas: - 1. Fix ER7 formatting (newline, carriage return) - 2. Parsing logic -- Result or error is pushed back into the pub/sub hub - ---- - -## New Features in the Solution - -### 1. AWS CloudFormation Cross-Stack References -Example *outputs* in the core microservice: -```yaml -Outputs: - Bucket: - Value: !Ref Bucket - Export: - Name: !Sub ${AWS::StackName}-Bucket - ArtifactBucket: - Value: !Ref ArtifactBucket - Export: - Name: !Sub ${AWS::StackName}-ArtifactBucket - Topic: - Value: !Ref Topic - Export: - Name: !Sub ${AWS::StackName}-Topic - Catalog: - Value: !Ref Catalog - Export: - Name: !Sub ${AWS::StackName}-Catalog - CatalogArn: - Value: !GetAtt Catalog.Arn - Export: - Name: !Sub ${AWS::StackName}-CatalogArn diff --git a/content/3-BlogsTranslated/3.4-Blog4/_index.vi.md b/content/3-BlogsTranslated/3.4-Blog4/_index.vi.md deleted file mode 100644 index b723700..0000000 --- a/content/3-BlogsTranslated/3.4-Blog4/_index.vi.md +++ /dev/null @@ -1,127 +0,0 @@ ---- -title: "Blog 4" -date: 2024-01-01 -weight: 1 -chapter: false -pre: " 3.4. " ---- - -{{% notice warning %}} -⚠️ **Lưu ý:** Các thông tin dưới đây chỉ nhằm mục đích tham khảo, vui lòng **không sao chép nguyên văn** cho bài báo cáo của bạn kể cả warning này. -{{% /notice %}} - -# Bắt đầu với healthcare data lakes: Sử dụng microservices - -Các data lake có thể giúp các bệnh viện và cơ sở y tế chuyển dữ liệu thành những thông tin chi tiết về doanh nghiệp và duy trì hoạt động kinh doanh liên tục, đồng thời bảo vệ quyền riêng tư của bệnh nhân. **Data lake** là một kho lưu trữ tập trung, được quản lý và bảo mật để lưu trữ tất cả dữ liệu của bạn, cả ở dạng ban đầu và đã xử lý để phân tích. data lake cho phép bạn chia nhỏ các kho chứa dữ liệu và kết hợp các loại phân tích khác nhau để có được thông tin chi tiết và đưa ra các quyết định kinh doanh tốt hơn. - -Bài đăng trên blog này là một phần của loạt bài lớn hơn về việc bắt đầu cài đặt data lake dành cho lĩnh vực y tế. Trong bài đăng blog cuối cùng của tôi trong loạt bài, *“Bắt đầu với data lake dành cho lĩnh vực y tế: Đào sâu vào Amazon Cognito”*, tôi tập trung vào các chi tiết cụ thể của việc sử dụng Amazon Cognito và Attribute Based Access Control (ABAC) để xác thực và ủy quyền người dùng trong giải pháp data lake y tế. Trong blog này, tôi trình bày chi tiết cách giải pháp đã phát triển ở cấp độ cơ bản, bao gồm các quyết định thiết kế mà tôi đã đưa ra và các tính năng bổ sung được sử dụng. Bạn có thể truy cập các code samples cho giải pháp tại Git repo này để tham khảo. - ---- - -## Hướng dẫn kiến trúc - -Thay đổi chính kể từ lần trình bày cuối cùng của kiến trúc tổng thể là việc tách dịch vụ đơn lẻ thành một tập hợp các dịch vụ nhỏ để cải thiện khả năng bảo trì và tính linh hoạt. Việc tích hợp một lượng lớn dữ liệu y tế khác nhau thường yêu cầu các trình kết nối chuyên biệt cho từng định dạng; bằng cách giữ chúng được đóng gói riêng biệt với microservices, chúng ta có thể thêm, xóa và sửa đổi từng trình kết nối mà không ảnh hưởng đến những kết nối khác. Các microservices được kết nối rời thông qua tin nhắn publish/subscribe tập trung trong cái mà tôi gọi là “pub/sub hub”. - -Giải pháp này đại diện cho những gì tôi sẽ coi là một lần lặp nước rút hợp lý khác từ last post của tôi. Phạm vi vẫn được giới hạn trong việc nhập và phân tích cú pháp đơn giản của các **HL7v2 messages** được định dạng theo **Quy tắc mã hóa 7 (ER7)** thông qua giao diện REST. - -**Kiến trúc giải pháp bây giờ như sau:** - -> *Hình 1. Kiến trúc tổng thể; những ô màu thể hiện những dịch vụ riêng biệt.* - ---- - -Mặc dù thuật ngữ *microservices* có một số sự mơ hồ cố hữu, một số đặc điểm là chung: -- Chúng nhỏ, tự chủ, kết hợp rời rạc -- Có thể tái sử dụng, giao tiếp thông qua giao diện được xác định rõ -- Chuyên biệt để giải quyết một việc -- Thường được triển khai trong **event-driven architecture** - -Khi xác định vị trí tạo ranh giới giữa các microservices, cần cân nhắc: -- **Nội tại**: công nghệ được sử dụng, hiệu suất, độ tin cậy, khả năng mở rộng -- **Bên ngoài**: chức năng phụ thuộc, tần suất thay đổi, khả năng tái sử dụng -- **Con người**: quyền sở hữu nhóm, quản lý *cognitive load* - ---- - -## Lựa chọn công nghệ và phạm vi giao tiếp - -| Phạm vi giao tiếp | Các công nghệ / mô hình cần xem xét | -| ---------------------------------------- | ------------------------------------------------------------------------------------------ | -| Trong một microservice | Amazon Simple Queue Service (Amazon SQS), AWS Step Functions | -| Giữa các microservices trong một dịch vụ | AWS CloudFormation cross-stack references, Amazon Simple Notification Service (Amazon SNS) | -| Giữa các dịch vụ | Amazon EventBridge, AWS Cloud Map, Amazon API Gateway | - ---- - -## The pub/sub hub - -Việc sử dụng kiến trúc **hub-and-spoke** (hay message broker) hoạt động tốt với một số lượng nhỏ các microservices liên quan chặt chẽ. -- Mỗi microservice chỉ phụ thuộc vào *hub* -- Kết nối giữa các microservice chỉ giới hạn ở nội dung của message được xuất -- Giảm số lượng synchronous calls vì pub/sub là *push* không đồng bộ một chiều - -Nhược điểm: cần **phối hợp và giám sát** để tránh microservice xử lý nhầm message. - ---- - -## Core microservice - -Cung cấp dữ liệu nền tảng và lớp truyền thông, gồm: -- **Amazon S3** bucket cho dữ liệu -- **Amazon DynamoDB** cho danh mục dữ liệu -- **AWS Lambda** để ghi message vào data lake và danh mục -- **Amazon SNS** topic làm *hub* -- **Amazon S3** bucket cho artifacts như mã Lambda - -> Chỉ cho phép truy cập ghi gián tiếp vào data lake qua hàm Lambda → đảm bảo nhất quán. - ---- - -## Front door microservice - -- Cung cấp API Gateway để tương tác REST bên ngoài -- Xác thực & ủy quyền dựa trên **OIDC** thông qua **Amazon Cognito** -- Cơ chế *deduplication* tự quản lý bằng DynamoDB thay vì SNS FIFO vì: - 1. SNS deduplication TTL chỉ 5 phút - 2. SNS FIFO yêu cầu SQS FIFO - 3. Chủ động báo cho sender biết message là bản sao - ---- - -## Staging ER7 microservice - -- Lambda “trigger” đăng ký với pub/sub hub, lọc message theo attribute -- Step Functions Express Workflow để chuyển ER7 → JSON -- Hai Lambda: - 1. Sửa format ER7 (newline, carriage return) - 2. Parsing logic -- Kết quả hoặc lỗi được đẩy lại vào pub/sub hub - ---- - -## Tính năng mới trong giải pháp - -### 1. AWS CloudFormation cross-stack references -Ví dụ *outputs* trong core microservice: -```yaml -Outputs: - Bucket: - Value: !Ref Bucket - Export: - Name: !Sub ${AWS::StackName}-Bucket - ArtifactBucket: - Value: !Ref ArtifactBucket - Export: - Name: !Sub ${AWS::StackName}-ArtifactBucket - Topic: - Value: !Ref Topic - Export: - Name: !Sub ${AWS::StackName}-Topic - Catalog: - Value: !Ref Catalog - Export: - Name: !Sub ${AWS::StackName}-Catalog - CatalogArn: - Value: !GetAtt Catalog.Arn - Export: - Name: !Sub ${AWS::StackName}-CatalogArn diff --git a/content/3-BlogsTranslated/3.5-Blog5/_index.md b/content/3-BlogsTranslated/3.5-Blog5/_index.md deleted file mode 100644 index 3f59632..0000000 --- a/content/3-BlogsTranslated/3.5-Blog5/_index.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -title: "Blog 5" -date: 2024-01-01 -weight: 1 -chapter: false -pre: " 3.5. " ---- -{{% notice warning %}} -⚠️ **Note:** The information below is for reference purposes only. Please **do not copy verbatim** for your report, including this warning. -{{% /notice %}} - -# Getting Started with Healthcare Data Lakes: Using Microservices - -Data lakes can help hospitals and healthcare facilities turn data into business insights, maintain business continuity, and protect patient privacy. A **data lake** is a centralized, managed, and secure repository to store all your data, both in its raw and processed forms for analysis. Data lakes allow you to break down data silos and combine different types of analytics to gain insights and make better business decisions. - -This blog post is part of a larger series on getting started with setting up a healthcare data lake. In my final post of the series, *“Getting Started with Healthcare Data Lakes: Diving into Amazon Cognito”*, I focused on the specifics of using Amazon Cognito and Attribute Based Access Control (ABAC) to authenticate and authorize users in the healthcare data lake solution. In this blog, I detail how the solution evolved at a foundational level, including the design decisions I made and the additional features used. You can access the code samples for the solution in this Git repo for reference. - ---- - -## Architecture Guidance - -The main change since the last presentation of the overall architecture is the decomposition of a single service into a set of smaller services to improve maintainability and flexibility. Integrating a large volume of diverse healthcare data often requires specialized connectors for each format; by keeping them encapsulated separately as microservices, we can add, remove, and modify each connector without affecting the others. The microservices are loosely coupled via publish/subscribe messaging centered in what I call the “pub/sub hub.” - -This solution represents what I would consider another reasonable sprint iteration from my last post. The scope is still limited to the ingestion and basic parsing of **HL7v2 messages** formatted in **Encoding Rules 7 (ER7)** through a REST interface. - -**The solution architecture is now as follows:** - -> *Figure 1. Overall architecture; colored boxes represent distinct services.* - ---- - -While the term *microservices* has some inherent ambiguity, certain traits are common: -- Small, autonomous, loosely coupled -- Reusable, communicating through well-defined interfaces -- Specialized to do one thing well -- Often implemented in an **event-driven architecture** - -When determining where to draw boundaries between microservices, consider: -- **Intrinsic**: technology used, performance, reliability, scalability -- **Extrinsic**: dependent functionality, rate of change, reusability -- **Human**: team ownership, managing *cognitive load* - ---- - -## Technology Choices and Communication Scope - -| Communication scope | Technologies / patterns to consider | -| ----------------------------------------- | ------------------------------------------------------------------------------------------ | -| Within a single microservice | Amazon Simple Queue Service (Amazon SQS), AWS Step Functions | -| Between microservices in a single service | AWS CloudFormation cross-stack references, Amazon Simple Notification Service (Amazon SNS) | -| Between services | Amazon EventBridge, AWS Cloud Map, Amazon API Gateway | - ---- - -## The Pub/Sub Hub - -Using a **hub-and-spoke** architecture (or message broker) works well with a small number of tightly related microservices. -- Each microservice depends only on the *hub* -- Inter-microservice connections are limited to the contents of the published message -- Reduces the number of synchronous calls since pub/sub is a one-way asynchronous *push* - -Drawback: **coordination and monitoring** are needed to avoid microservices processing the wrong message. - ---- - -## Core Microservice - -Provides foundational data and communication layer, including: -- **Amazon S3** bucket for data -- **Amazon DynamoDB** for data catalog -- **AWS Lambda** to write messages into the data lake and catalog -- **Amazon SNS** topic as the *hub* -- **Amazon S3** bucket for artifacts such as Lambda code - -> Only allow indirect write access to the data lake through a Lambda function → ensures consistency. - ---- - -## Front Door Microservice - -- Provides an API Gateway for external REST interaction -- Authentication & authorization based on **OIDC** via **Amazon Cognito** -- Self-managed *deduplication* mechanism using DynamoDB instead of SNS FIFO because: - 1. SNS deduplication TTL is only 5 minutes - 2. SNS FIFO requires SQS FIFO - 3. Ability to proactively notify the sender that the message is a duplicate - ---- - -## Staging ER7 Microservice - -- Lambda “trigger” subscribed to the pub/sub hub, filtering messages by attribute -- Step Functions Express Workflow to convert ER7 → JSON -- Two Lambdas: - 1. Fix ER7 formatting (newline, carriage return) - 2. Parsing logic -- Result or error is pushed back into the pub/sub hub - ---- - -## New Features in the Solution - -### 1. AWS CloudFormation Cross-Stack References -Example *outputs* in the core microservice: -```yaml -Outputs: - Bucket: - Value: !Ref Bucket - Export: - Name: !Sub ${AWS::StackName}-Bucket - ArtifactBucket: - Value: !Ref ArtifactBucket - Export: - Name: !Sub ${AWS::StackName}-ArtifactBucket - Topic: - Value: !Ref Topic - Export: - Name: !Sub ${AWS::StackName}-Topic - Catalog: - Value: !Ref Catalog - Export: - Name: !Sub ${AWS::StackName}-Catalog - CatalogArn: - Value: !GetAtt Catalog.Arn - Export: - Name: !Sub ${AWS::StackName}-CatalogArn diff --git a/content/3-BlogsTranslated/3.5-Blog5/_index.vi.md b/content/3-BlogsTranslated/3.5-Blog5/_index.vi.md deleted file mode 100644 index e31a378..0000000 --- a/content/3-BlogsTranslated/3.5-Blog5/_index.vi.md +++ /dev/null @@ -1,127 +0,0 @@ ---- -title: "Blog 5" -date: 2024-01-01 -weight: 1 -chapter: false -pre: " 3.6. " ---- - -{{% notice warning %}} -⚠️ **Lưu ý:** Các thông tin dưới đây chỉ nhằm mục đích tham khảo, vui lòng **không sao chép nguyên văn** cho bài báo cáo của bạn kể cả warning này. -{{% /notice %}} - -# Bắt đầu với healthcare data lakes: Sử dụng microservices - -Các data lake có thể giúp các bệnh viện và cơ sở y tế chuyển dữ liệu thành những thông tin chi tiết về doanh nghiệp và duy trì hoạt động kinh doanh liên tục, đồng thời bảo vệ quyền riêng tư của bệnh nhân. **Data lake** là một kho lưu trữ tập trung, được quản lý và bảo mật để lưu trữ tất cả dữ liệu của bạn, cả ở dạng ban đầu và đã xử lý để phân tích. data lake cho phép bạn chia nhỏ các kho chứa dữ liệu và kết hợp các loại phân tích khác nhau để có được thông tin chi tiết và đưa ra các quyết định kinh doanh tốt hơn. - -Bài đăng trên blog này là một phần của loạt bài lớn hơn về việc bắt đầu cài đặt data lake dành cho lĩnh vực y tế. Trong bài đăng blog cuối cùng của tôi trong loạt bài, *“Bắt đầu với data lake dành cho lĩnh vực y tế: Đào sâu vào Amazon Cognito”*, tôi tập trung vào các chi tiết cụ thể của việc sử dụng Amazon Cognito và Attribute Based Access Control (ABAC) để xác thực và ủy quyền người dùng trong giải pháp data lake y tế. Trong blog này, tôi trình bày chi tiết cách giải pháp đã phát triển ở cấp độ cơ bản, bao gồm các quyết định thiết kế mà tôi đã đưa ra và các tính năng bổ sung được sử dụng. Bạn có thể truy cập các code samples cho giải pháp tại Git repo này để tham khảo. - ---- - -## Hướng dẫn kiến trúc - -Thay đổi chính kể từ lần trình bày cuối cùng của kiến trúc tổng thể là việc tách dịch vụ đơn lẻ thành một tập hợp các dịch vụ nhỏ để cải thiện khả năng bảo trì và tính linh hoạt. Việc tích hợp một lượng lớn dữ liệu y tế khác nhau thường yêu cầu các trình kết nối chuyên biệt cho từng định dạng; bằng cách giữ chúng được đóng gói riêng biệt với microservices, chúng ta có thể thêm, xóa và sửa đổi từng trình kết nối mà không ảnh hưởng đến những kết nối khác. Các microservices được kết nối rời thông qua tin nhắn publish/subscribe tập trung trong cái mà tôi gọi là “pub/sub hub”. - -Giải pháp này đại diện cho những gì tôi sẽ coi là một lần lặp nước rút hợp lý khác từ last post của tôi. Phạm vi vẫn được giới hạn trong việc nhập và phân tích cú pháp đơn giản của các **HL7v2 messages** được định dạng theo **Quy tắc mã hóa 7 (ER7)** thông qua giao diện REST. - -**Kiến trúc giải pháp bây giờ như sau:** - -> *Hình 1. Kiến trúc tổng thể; những ô màu thể hiện những dịch vụ riêng biệt.* - ---- - -Mặc dù thuật ngữ *microservices* có một số sự mơ hồ cố hữu, một số đặc điểm là chung: -- Chúng nhỏ, tự chủ, kết hợp rời rạc -- Có thể tái sử dụng, giao tiếp thông qua giao diện được xác định rõ -- Chuyên biệt để giải quyết một việc -- Thường được triển khai trong **event-driven architecture** - -Khi xác định vị trí tạo ranh giới giữa các microservices, cần cân nhắc: -- **Nội tại**: công nghệ được sử dụng, hiệu suất, độ tin cậy, khả năng mở rộng -- **Bên ngoài**: chức năng phụ thuộc, tần suất thay đổi, khả năng tái sử dụng -- **Con người**: quyền sở hữu nhóm, quản lý *cognitive load* - ---- - -## Lựa chọn công nghệ và phạm vi giao tiếp - -| Phạm vi giao tiếp | Các công nghệ / mô hình cần xem xét | -| ---------------------------------------- | ------------------------------------------------------------------------------------------ | -| Trong một microservice | Amazon Simple Queue Service (Amazon SQS), AWS Step Functions | -| Giữa các microservices trong một dịch vụ | AWS CloudFormation cross-stack references, Amazon Simple Notification Service (Amazon SNS) | -| Giữa các dịch vụ | Amazon EventBridge, AWS Cloud Map, Amazon API Gateway | - ---- - -## The pub/sub hub - -Việc sử dụng kiến trúc **hub-and-spoke** (hay message broker) hoạt động tốt với một số lượng nhỏ các microservices liên quan chặt chẽ. -- Mỗi microservice chỉ phụ thuộc vào *hub* -- Kết nối giữa các microservice chỉ giới hạn ở nội dung của message được xuất -- Giảm số lượng synchronous calls vì pub/sub là *push* không đồng bộ một chiều - -Nhược điểm: cần **phối hợp và giám sát** để tránh microservice xử lý nhầm message. - ---- - -## Core microservice - -Cung cấp dữ liệu nền tảng và lớp truyền thông, gồm: -- **Amazon S3** bucket cho dữ liệu -- **Amazon DynamoDB** cho danh mục dữ liệu -- **AWS Lambda** để ghi message vào data lake và danh mục -- **Amazon SNS** topic làm *hub* -- **Amazon S3** bucket cho artifacts như mã Lambda - -> Chỉ cho phép truy cập ghi gián tiếp vào data lake qua hàm Lambda → đảm bảo nhất quán. - ---- - -## Front door microservice - -- Cung cấp API Gateway để tương tác REST bên ngoài -- Xác thực & ủy quyền dựa trên **OIDC** thông qua **Amazon Cognito** -- Cơ chế *deduplication* tự quản lý bằng DynamoDB thay vì SNS FIFO vì: - 1. SNS deduplication TTL chỉ 5 phút - 2. SNS FIFO yêu cầu SQS FIFO - 3. Chủ động báo cho sender biết message là bản sao - ---- - -## Staging ER7 microservice - -- Lambda “trigger” đăng ký với pub/sub hub, lọc message theo attribute -- Step Functions Express Workflow để chuyển ER7 → JSON -- Hai Lambda: - 1. Sửa format ER7 (newline, carriage return) - 2. Parsing logic -- Kết quả hoặc lỗi được đẩy lại vào pub/sub hub - ---- - -## Tính năng mới trong giải pháp - -### 1. AWS CloudFormation cross-stack references -Ví dụ *outputs* trong core microservice: -```yaml -Outputs: - Bucket: - Value: !Ref Bucket - Export: - Name: !Sub ${AWS::StackName}-Bucket - ArtifactBucket: - Value: !Ref ArtifactBucket - Export: - Name: !Sub ${AWS::StackName}-ArtifactBucket - Topic: - Value: !Ref Topic - Export: - Name: !Sub ${AWS::StackName}-Topic - Catalog: - Value: !Ref Catalog - Export: - Name: !Sub ${AWS::StackName}-Catalog - CatalogArn: - Value: !GetAtt Catalog.Arn - Export: - Name: !Sub ${AWS::StackName}-CatalogArn diff --git a/content/3-BlogsTranslated/3.6-Blog6/_index.md b/content/3-BlogsTranslated/3.6-Blog6/_index.md deleted file mode 100644 index 352ac00..0000000 --- a/content/3-BlogsTranslated/3.6-Blog6/_index.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -title: "Blog 6" -date: 2024-01-01 -weight: 1 -chapter: false -pre: " 3.6. " ---- -{{% notice warning %}} -⚠️ **Note:** The information below is for reference purposes only. Please **do not copy verbatim** for your report, including this warning. -{{% /notice %}} - -# Getting Started with Healthcare Data Lakes: Using Microservices - -Data lakes can help hospitals and healthcare facilities turn data into business insights, maintain business continuity, and protect patient privacy. A **data lake** is a centralized, managed, and secure repository to store all your data, both in its raw and processed forms for analysis. Data lakes allow you to break down data silos and combine different types of analytics to gain insights and make better business decisions. - -This blog post is part of a larger series on getting started with setting up a healthcare data lake. In my final post of the series, *“Getting Started with Healthcare Data Lakes: Diving into Amazon Cognito”*, I focused on the specifics of using Amazon Cognito and Attribute Based Access Control (ABAC) to authenticate and authorize users in the healthcare data lake solution. In this blog, I detail how the solution evolved at a foundational level, including the design decisions I made and the additional features used. You can access the code samples for the solution in this Git repo for reference. - ---- - -## Architecture Guidance - -The main change since the last presentation of the overall architecture is the decomposition of a single service into a set of smaller services to improve maintainability and flexibility. Integrating a large volume of diverse healthcare data often requires specialized connectors for each format; by keeping them encapsulated separately as microservices, we can add, remove, and modify each connector without affecting the others. The microservices are loosely coupled via publish/subscribe messaging centered in what I call the “pub/sub hub.” - -This solution represents what I would consider another reasonable sprint iteration from my last post. The scope is still limited to the ingestion and basic parsing of **HL7v2 messages** formatted in **Encoding Rules 7 (ER7)** through a REST interface. - -**The solution architecture is now as follows:** - -> *Figure 1. Overall architecture; colored boxes represent distinct services.* - ---- - -While the term *microservices* has some inherent ambiguity, certain traits are common: -- Small, autonomous, loosely coupled -- Reusable, communicating through well-defined interfaces -- Specialized to do one thing well -- Often implemented in an **event-driven architecture** - -When determining where to draw boundaries between microservices, consider: -- **Intrinsic**: technology used, performance, reliability, scalability -- **Extrinsic**: dependent functionality, rate of change, reusability -- **Human**: team ownership, managing *cognitive load* - ---- - -## Technology Choices and Communication Scope - -| Communication scope | Technologies / patterns to consider | -| ----------------------------------------- | ------------------------------------------------------------------------------------------ | -| Within a single microservice | Amazon Simple Queue Service (Amazon SQS), AWS Step Functions | -| Between microservices in a single service | AWS CloudFormation cross-stack references, Amazon Simple Notification Service (Amazon SNS) | -| Between services | Amazon EventBridge, AWS Cloud Map, Amazon API Gateway | - ---- - -## The Pub/Sub Hub - -Using a **hub-and-spoke** architecture (or message broker) works well with a small number of tightly related microservices. -- Each microservice depends only on the *hub* -- Inter-microservice connections are limited to the contents of the published message -- Reduces the number of synchronous calls since pub/sub is a one-way asynchronous *push* - -Drawback: **coordination and monitoring** are needed to avoid microservices processing the wrong message. - ---- - -## Core Microservice - -Provides foundational data and communication layer, including: -- **Amazon S3** bucket for data -- **Amazon DynamoDB** for data catalog -- **AWS Lambda** to write messages into the data lake and catalog -- **Amazon SNS** topic as the *hub* -- **Amazon S3** bucket for artifacts such as Lambda code - -> Only allow indirect write access to the data lake through a Lambda function → ensures consistency. - ---- - -## Front Door Microservice - -- Provides an API Gateway for external REST interaction -- Authentication & authorization based on **OIDC** via **Amazon Cognito** -- Self-managed *deduplication* mechanism using DynamoDB instead of SNS FIFO because: - 1. SNS deduplication TTL is only 5 minutes - 2. SNS FIFO requires SQS FIFO - 3. Ability to proactively notify the sender that the message is a duplicate - ---- - -## Staging ER7 Microservice - -- Lambda “trigger” subscribed to the pub/sub hub, filtering messages by attribute -- Step Functions Express Workflow to convert ER7 → JSON -- Two Lambdas: - 1. Fix ER7 formatting (newline, carriage return) - 2. Parsing logic -- Result or error is pushed back into the pub/sub hub - ---- - -## New Features in the Solution - -### 1. AWS CloudFormation Cross-Stack References -Example *outputs* in the core microservice: -```yaml -Outputs: - Bucket: - Value: !Ref Bucket - Export: - Name: !Sub ${AWS::StackName}-Bucket - ArtifactBucket: - Value: !Ref ArtifactBucket - Export: - Name: !Sub ${AWS::StackName}-ArtifactBucket - Topic: - Value: !Ref Topic - Export: - Name: !Sub ${AWS::StackName}-Topic - Catalog: - Value: !Ref Catalog - Export: - Name: !Sub ${AWS::StackName}-Catalog - CatalogArn: - Value: !GetAtt Catalog.Arn - Export: - Name: !Sub ${AWS::StackName}-CatalogArn diff --git a/content/3-BlogsTranslated/3.6-Blog6/_index.vi.md b/content/3-BlogsTranslated/3.6-Blog6/_index.vi.md deleted file mode 100644 index 7976aee..0000000 --- a/content/3-BlogsTranslated/3.6-Blog6/_index.vi.md +++ /dev/null @@ -1,127 +0,0 @@ ---- -title: "Blog 6" -date: 2024-01-01 -weight: 1 -chapter: false -pre: " 3.6. " ---- - -{{% notice warning %}} -⚠️ **Lưu ý:** Các thông tin dưới đây chỉ nhằm mục đích tham khảo, vui lòng **không sao chép nguyên văn** cho bài báo cáo của bạn kể cả warning này. -{{% /notice %}} - -# Bắt đầu với healthcare data lakes: Sử dụng microservices - -Các data lake có thể giúp các bệnh viện và cơ sở y tế chuyển dữ liệu thành những thông tin chi tiết về doanh nghiệp và duy trì hoạt động kinh doanh liên tục, đồng thời bảo vệ quyền riêng tư của bệnh nhân. **Data lake** là một kho lưu trữ tập trung, được quản lý và bảo mật để lưu trữ tất cả dữ liệu của bạn, cả ở dạng ban đầu và đã xử lý để phân tích. data lake cho phép bạn chia nhỏ các kho chứa dữ liệu và kết hợp các loại phân tích khác nhau để có được thông tin chi tiết và đưa ra các quyết định kinh doanh tốt hơn. - -Bài đăng trên blog này là một phần của loạt bài lớn hơn về việc bắt đầu cài đặt data lake dành cho lĩnh vực y tế. Trong bài đăng blog cuối cùng của tôi trong loạt bài, *“Bắt đầu với data lake dành cho lĩnh vực y tế: Đào sâu vào Amazon Cognito”*, tôi tập trung vào các chi tiết cụ thể của việc sử dụng Amazon Cognito và Attribute Based Access Control (ABAC) để xác thực và ủy quyền người dùng trong giải pháp data lake y tế. Trong blog này, tôi trình bày chi tiết cách giải pháp đã phát triển ở cấp độ cơ bản, bao gồm các quyết định thiết kế mà tôi đã đưa ra và các tính năng bổ sung được sử dụng. Bạn có thể truy cập các code samples cho giải pháp tại Git repo này để tham khảo. - ---- - -## Hướng dẫn kiến trúc - -Thay đổi chính kể từ lần trình bày cuối cùng của kiến trúc tổng thể là việc tách dịch vụ đơn lẻ thành một tập hợp các dịch vụ nhỏ để cải thiện khả năng bảo trì và tính linh hoạt. Việc tích hợp một lượng lớn dữ liệu y tế khác nhau thường yêu cầu các trình kết nối chuyên biệt cho từng định dạng; bằng cách giữ chúng được đóng gói riêng biệt với microservices, chúng ta có thể thêm, xóa và sửa đổi từng trình kết nối mà không ảnh hưởng đến những kết nối khác. Các microservices được kết nối rời thông qua tin nhắn publish/subscribe tập trung trong cái mà tôi gọi là “pub/sub hub”. - -Giải pháp này đại diện cho những gì tôi sẽ coi là một lần lặp nước rút hợp lý khác từ last post của tôi. Phạm vi vẫn được giới hạn trong việc nhập và phân tích cú pháp đơn giản của các **HL7v2 messages** được định dạng theo **Quy tắc mã hóa 7 (ER7)** thông qua giao diện REST. - -**Kiến trúc giải pháp bây giờ như sau:** - -> *Hình 1. Kiến trúc tổng thể; những ô màu thể hiện những dịch vụ riêng biệt.* - ---- - -Mặc dù thuật ngữ *microservices* có một số sự mơ hồ cố hữu, một số đặc điểm là chung: -- Chúng nhỏ, tự chủ, kết hợp rời rạc -- Có thể tái sử dụng, giao tiếp thông qua giao diện được xác định rõ -- Chuyên biệt để giải quyết một việc -- Thường được triển khai trong **event-driven architecture** - -Khi xác định vị trí tạo ranh giới giữa các microservices, cần cân nhắc: -- **Nội tại**: công nghệ được sử dụng, hiệu suất, độ tin cậy, khả năng mở rộng -- **Bên ngoài**: chức năng phụ thuộc, tần suất thay đổi, khả năng tái sử dụng -- **Con người**: quyền sở hữu nhóm, quản lý *cognitive load* - ---- - -## Lựa chọn công nghệ và phạm vi giao tiếp - -| Phạm vi giao tiếp | Các công nghệ / mô hình cần xem xét | -| ---------------------------------------- | ------------------------------------------------------------------------------------------ | -| Trong một microservice | Amazon Simple Queue Service (Amazon SQS), AWS Step Functions | -| Giữa các microservices trong một dịch vụ | AWS CloudFormation cross-stack references, Amazon Simple Notification Service (Amazon SNS) | -| Giữa các dịch vụ | Amazon EventBridge, AWS Cloud Map, Amazon API Gateway | - ---- - -## The pub/sub hub - -Việc sử dụng kiến trúc **hub-and-spoke** (hay message broker) hoạt động tốt với một số lượng nhỏ các microservices liên quan chặt chẽ. -- Mỗi microservice chỉ phụ thuộc vào *hub* -- Kết nối giữa các microservice chỉ giới hạn ở nội dung của message được xuất -- Giảm số lượng synchronous calls vì pub/sub là *push* không đồng bộ một chiều - -Nhược điểm: cần **phối hợp và giám sát** để tránh microservice xử lý nhầm message. - ---- - -## Core microservice - -Cung cấp dữ liệu nền tảng và lớp truyền thông, gồm: -- **Amazon S3** bucket cho dữ liệu -- **Amazon DynamoDB** cho danh mục dữ liệu -- **AWS Lambda** để ghi message vào data lake và danh mục -- **Amazon SNS** topic làm *hub* -- **Amazon S3** bucket cho artifacts như mã Lambda - -> Chỉ cho phép truy cập ghi gián tiếp vào data lake qua hàm Lambda → đảm bảo nhất quán. - ---- - -## Front door microservice - -- Cung cấp API Gateway để tương tác REST bên ngoài -- Xác thực & ủy quyền dựa trên **OIDC** thông qua **Amazon Cognito** -- Cơ chế *deduplication* tự quản lý bằng DynamoDB thay vì SNS FIFO vì: - 1. SNS deduplication TTL chỉ 5 phút - 2. SNS FIFO yêu cầu SQS FIFO - 3. Chủ động báo cho sender biết message là bản sao - ---- - -## Staging ER7 microservice - -- Lambda “trigger” đăng ký với pub/sub hub, lọc message theo attribute -- Step Functions Express Workflow để chuyển ER7 → JSON -- Hai Lambda: - 1. Sửa format ER7 (newline, carriage return) - 2. Parsing logic -- Kết quả hoặc lỗi được đẩy lại vào pub/sub hub - ---- - -## Tính năng mới trong giải pháp - -### 1. AWS CloudFormation cross-stack references -Ví dụ *outputs* trong core microservice: -```yaml -Outputs: - Bucket: - Value: !Ref Bucket - Export: - Name: !Sub ${AWS::StackName}-Bucket - ArtifactBucket: - Value: !Ref ArtifactBucket - Export: - Name: !Sub ${AWS::StackName}-ArtifactBucket - Topic: - Value: !Ref Topic - Export: - Name: !Sub ${AWS::StackName}-Topic - Catalog: - Value: !Ref Catalog - Export: - Name: !Sub ${AWS::StackName}-Catalog - CatalogArn: - Value: !GetAtt Catalog.Arn - Export: - Name: !Sub ${AWS::StackName}-CatalogArn diff --git a/content/3-BlogsTranslated/_index.md b/content/3-BlogsTranslated/_index.md index 828fc36..17eb2b5 100644 --- a/content/3-BlogsTranslated/_index.md +++ b/content/3-BlogsTranslated/_index.md @@ -6,26 +6,17 @@ chapter: false pre: " 3. " --- -{{% notice warning %}} + -This section will list and introduce the blogs you have translated. For example: + -### [Blog 1 - Getting started with healthcare data lakes: Using microservices](3.1-Blog1/) -This blog introduces how to start building a data lake in the healthcare sector by applying a microservices architecture. You will learn why data lakes are important for storing and analyzing diverse healthcare data (electronic medical records, lab test data, medical IoT devices…), how microservices help make the system more flexible, scalable, and easier to maintain. The article also guides you through the steps to set up the environment, organize the data processing pipeline, and ensure compliance with security & privacy standards such as HIPAA. +### [Blog 1 - Cyber Resilience on AWS: Recovery from ransomware and destructive events](3.1-Blog1/) +This blog summarizes an AWS reference approach for building cyber resilience for critical workloads. It focuses on separating production, the recovery account, and the isolated recovery environment, using AWS Backup logically air-gapped vaults to protect recovery points, validating backups before restore, selecting a safe recovery point, and applying the Rebuild-Restore-Rotate framework. -### [Blog 2 - ...](3.2-Blog2/) -This blog introduces how to start building a data lake in the healthcare sector by applying a microservices architecture. You will learn why data lakes are important for storing and analyzing diverse healthcare data (electronic medical records, lab test data, medical IoT devices…), how microservices help make the system more flexible, scalable, and easier to maintain. The article also guides you through the steps to set up the environment, organize the data processing pipeline, and ensure compliance with security & privacy standards such as HIPAA. +### [Blog 2 - Building a Multi Account Patch Compliance Dashboard with Kiro Specs](3.2-Blog2/) +This blog summarizes how AWS builds a multi-account patch compliance dashboard using AWS Systems Manager Patch Manager, Resource Data Sync, Amazon S3, AWS Lambda, EventBridge, an internal ALB, and Session Manager. It also focuses on how Kiro Specs, steering files, and MCP servers support a spec-driven development workflow. -### [Blog 3 - ...](3.3-Blog3/) -This blog introduces how to start building a data lake in the healthcare sector by applying a microservices architecture. You will learn why data lakes are important for storing and analyzing diverse healthcare data (electronic medical records, lab test data, medical IoT devices…), how microservices help make the system more flexible, scalable, and easier to maintain. The article also guides you through the steps to set up the environment, organize the data processing pipeline, and ensure compliance with security & privacy standards such as HIPAA. - -### [Blog 4 - ...](3.4-Blog4/) -This blog introduces how to start building a data lake in the healthcare sector by applying a microservices architecture. You will learn why data lakes are important for storing and analyzing diverse healthcare data (electronic medical records, lab test data, medical IoT devices…), how microservices help make the system more flexible, scalable, and easier to maintain. The article also guides you through the steps to set up the environment, organize the data processing pipeline, and ensure compliance with security & privacy standards such as HIPAA. - -### [Blog 5 - ...](3.5-Blog5/) -This blog introduces how to start building a data lake in the healthcare sector by applying a microservices architecture. You will learn why data lakes are important for storing and analyzing diverse healthcare data (electronic medical records, lab test data, medical IoT devices…), how microservices help make the system more flexible, scalable, and easier to maintain. The article also guides you through the steps to set up the environment, organize the data processing pipeline, and ensure compliance with security & privacy standards such as HIPAA. - -### [Blog 6 - ...](3.6-Blog6/) -This blog introduces how to start building a data lake in the healthcare sector by applying a microservices architecture. You will learn why data lakes are important for storing and analyzing diverse healthcare data (electronic medical records, lab test data, medical IoT devices…), how microservices help make the system more flexible, scalable, and easier to maintain. The article also guides you through the steps to set up the environment, organize the data processing pipeline, and ensure compliance with security & privacy standards such as HIPAA. +### [Blog 3 - Architecting an AI-Powered Resilience Framework on AWS](3.3-Blog3/) +This blog summarizes how AWS combines AWS Resilience Hub, AWS Fault Injection Service, Amazon Bedrock AgentCore, AWS Systems Manager, AWS Config, and CloudWatch to build a continuous resilience testing framework. It focuses on five layers: discovery, test generation, experimentation, gap analysis, and continuous validation in CI/CD. diff --git a/content/3-BlogsTranslated/_index.vi.md b/content/3-BlogsTranslated/_index.vi.md index dfab008..7b5f94c 100644 --- a/content/3-BlogsTranslated/_index.vi.md +++ b/content/3-BlogsTranslated/_index.vi.md @@ -6,21 +6,15 @@ chapter: false pre: " 3. " --- -{{% notice warning %}} + -### [Blog 1 - Getting started with healthcare data lakes: Using microservices](3.1-Blog1/) -Blog này giới thiệu cách bắt đầu xây dựng data lake trong lĩnh vực y tế bằng cách áp dụng kiến trúc microservices. Bạn sẽ tìm hiểu vì sao data lake quan trọng trong việc lưu trữ và phân tích dữ liệu y tế đa dạng (hồ sơ bệnh án điện tử, dữ liệu xét nghiệm, thiết bị IoT y tế…), cách microservices giúp hệ thống linh hoạt, dễ mở rộng và dễ bảo trì hơn. Bài viết cũng hướng dẫn các bước khởi tạo môi trường, tổ chức pipeline xử lý dữ liệu, và đảm bảo tuân thủ các tiêu chuẩn bảo mật & quyền riêng tư như HIPAA. -### [Blog 2 - ...](3.2-Blog2/) -Blog này giới thiệu cách bắt đầu xây dựng data lake trong lĩnh vực y tế bằng cách áp dụng kiến trúc microservices. Bạn sẽ tìm hiểu vì sao data lake quan trọng trong việc lưu trữ và phân tích dữ liệu y tế đa dạng (hồ sơ bệnh án điện tử, dữ liệu xét nghiệm, thiết bị IoT y tế…), cách microservices giúp hệ thống linh hoạt, dễ mở rộng và dễ bảo trì hơn. Bài viết cũng hướng dẫn các bước khởi tạo môi trường, tổ chức pipeline xử lý dữ liệu, và đảm bảo tuân thủ các tiêu chuẩn bảo mật & quyền riêng tư như HIPAA. -### [Blog 3 - ...](3.3-Blog3/) -Blog này giới thiệu cách bắt đầu xây dựng data lake trong lĩnh vực y tế bằng cách áp dụng kiến trúc microservices. Bạn sẽ tìm hiểu vì sao data lake quan trọng trong việc lưu trữ và phân tích dữ liệu y tế đa dạng (hồ sơ bệnh án điện tử, dữ liệu xét nghiệm, thiết bị IoT y tế…), cách microservices giúp hệ thống linh hoạt, dễ mở rộng và dễ bảo trì hơn. Bài viết cũng hướng dẫn các bước khởi tạo môi trường, tổ chức pipeline xử lý dữ liệu, và đảm bảo tuân thủ các tiêu chuẩn bảo mật & quyền riêng tư như HIPAA. -### [Blog 4 - ...](3.4-Blog4/) -Blog này giới thiệu cách bắt đầu xây dựng data lake trong lĩnh vực y tế bằng cách áp dụng kiến trúc microservices. Bạn sẽ tìm hiểu vì sao data lake quan trọng trong việc lưu trữ và phân tích dữ liệu y tế đa dạng (hồ sơ bệnh án điện tử, dữ liệu xét nghiệm, thiết bị IoT y tế…), cách microservices giúp hệ thống linh hoạt, dễ mở rộng và dễ bảo trì hơn. Bài viết cũng hướng dẫn các bước khởi tạo môi trường, tổ chức pipeline xử lý dữ liệu, và đảm bảo tuân thủ các tiêu chuẩn bảo mật & quyền riêng tư như HIPAA. -### [Blog 5 - ...](3.5-Blog5/) -Blog này giới thiệu cách bắt đầu xây dựng data lake trong lĩnh vực y tế bằng cách áp dụng kiến trúc microservices. Bạn sẽ tìm hiểu vì sao data lake quan trọng trong việc lưu trữ và phân tích dữ liệu y tế đa dạng (hồ sơ bệnh án điện tử, dữ liệu xét nghiệm, thiết bị IoT y tế…), cách microservices giúp hệ thống linh hoạt, dễ mở rộng và dễ bảo trì hơn. Bài viết cũng hướng dẫn các bước khởi tạo môi trường, tổ chức pipeline xử lý dữ liệu, và đảm bảo tuân thủ các tiêu chuẩn bảo mật & quyền riêng tư như HIPAA. -### [Blog 6 - ...](3.6-Blog6/) -Blog này giới thiệu cách bắt đầu xây dựng data lake trong lĩnh vực y tế bằng cách áp dụng kiến trúc microservices. Bạn sẽ tìm hiểu vì sao data lake quan trọng trong việc lưu trữ và phân tích dữ liệu y tế đa dạng (hồ sơ bệnh án điện tử, dữ liệu xét nghiệm, thiết bị IoT y tế…), cách microservices giúp hệ thống linh hoạt, dễ mở rộng và dễ bảo trì hơn. Bài viết cũng hướng dẫn các bước khởi tạo môi trường, tổ chức pipeline xử lý dữ liệu, và đảm bảo tuân thủ các tiêu chuẩn bảo mật & quyền riêng tư như HIPAA. \ No newline at end of file +### [Blog 1 - Cyber Resilience trên AWS: Phục hồi sau ransomware và sự cố phá hủy](3.1-Blog1/) +Blog này chia sẻ cách AWS đề xuất xây dựng năng lực cyber resilience cho các workload quan trọng. Nội dung tập trung vào việc tách biệt production, recovery account và isolated recovery environment, sử dụng AWS Backup logically air-gapped vault để bảo vệ recovery point, kiểm tra backup trước khi restore, chọn recovery point an toàn và áp dụng framework Rebuild-Restore-Rotate. +### [Blog 2 - Xây dựng Multi Account Patch Compliance Dashboard với Kiro Specs](3.2-Blog2/) +Blog này chia sẻ cách AWS xây dựng dashboard theo dõi patch compliance trên nhiều account bằng AWS Systems Manager Patch Manager, Resource Data Sync, Amazon S3, AWS Lambda, EventBridge, internal ALB và Session Manager. Nội dung cũng tập trung vào cách dùng Kiro Specs, steering files và MCP servers để phát triển giải pháp theo hướng spec-driven development. +### [Blog 3 - Kiến trúc AI-powered Resilience Framework trên AWS](3.3-Blog3/) +Blog này chia sẻ cách AWS kết hợp AWS Resilience Hub, AWS Fault Injection Service, Amazon Bedrock AgentCore, AWS Systems Manager, AWS Config và CloudWatch để xây dựng framework kiểm thử resilience liên tục. Nội dung tập trung vào 5 lớp chính: discovery, test generation, experimentation, gap analysis và continuous validation trong CI/CD. \ No newline at end of file diff --git a/content/4-EventParticipated/4.1-Event1/_index.md b/content/4-EventParticipated/4.1-Event1/_index.md index 9f491ab..6bdfa22 100644 --- a/content/4-EventParticipated/4.1-Event1/_index.md +++ b/content/4-EventParticipated/4.1-Event1/_index.md @@ -1,5 +1,5 @@ --- -title: "Community Day FCAJ HCM" +title: "FCAJ Community Day" date: 2024-01-01 weight: 1 chapter: false @@ -10,7 +10,7 @@ pre: " 4.1. " ⚠️ **Note:** The information below is for reference purposes only. Please **do not copy it verbatim** into your report, including this warning. {{% /notice %}}--> -# Summary Report: “Community Day FCAJ HCM” +# Summary Report: “FCAJ Community Day” ### Event Objectives diff --git a/content/4-EventParticipated/4.1-Event1/_index.vi.md b/content/4-EventParticipated/4.1-Event1/_index.vi.md index 71677a7..b89c077 100644 --- a/content/4-EventParticipated/4.1-Event1/_index.vi.md +++ b/content/4-EventParticipated/4.1-Event1/_index.vi.md @@ -1,5 +1,5 @@ --- -title: "Community Day FCAJ HCM" +title: "FCAJ Community Day" date: 2024-01-01 weight: 1 chapter: false @@ -10,7 +10,7 @@ pre: " 4.1. " ⚠️ **Lưu ý:** Các thông tin dưới đây chỉ nhằm mục đích tham khảo, vui lòng **không sao chép nguyên văn** cho bài báo cáo của bạn kể cả warning này. {{% /notice %}}--> -# Bài thu hoạch “Community Day FCAJ HCM” +# Bài thu hoạch “FCAJ Community Day” ### Mục đích của sự kiện diff --git a/content/4-EventParticipated/4.2-Event2/_index.md b/content/4-EventParticipated/4.2-Event2/_index.md index 4f1323c..7a7f0b1 100644 --- a/content/4-EventParticipated/4.2-Event2/_index.md +++ b/content/4-EventParticipated/4.2-Event2/_index.md @@ -1,7 +1,7 @@ --- title: "AWS First Cloud AI Journey - Community Day" date: 2024-01-01 -weight: 1 +weight: 2 chapter: false pre: " 4.2. " --- @@ -35,8 +35,8 @@ pre: " 4.2. " | Time | Speaker | Session | |---|---|---| | 09:00 – 09:30 | **Tinh Truong** | Context Is Everything: Making AI Actually Work for You | -| 09:30 – 09:45 | **Thinh Nguyen** | Friendly AI Assistant with Amazon Quick | -| 09:45 – 10:25 | **Anh Pham** | From Edge To Origin: CloudFront as Your Foundation | +| 09:30 – 09:45 | **Anh Pham** | Friendly AI Assistant with Amazon Quick | +| 09:45 – 10:25 | **Thinh Nguyen** | From Edge To Origin: CloudFront as Your Foundation | | 10:25 – 10:55 | **Uyen Le, Thao Nguyen, Mai Nguyen** | 36 hrs with LotusHacks – Building UTMorpho from Idea to Reality | | 10:55 – 11:00 | — | Coffee Break | | 11:00 – 11:30 | **Duc Dao** | Non-Determinism of "Deterministic" LLM Settings | @@ -51,14 +51,14 @@ pre: " 4.2. " - How better context produces better results — practical mindset and tips - Career insights and how students can start building with AI -#### Thinh Nguyen – Friendly AI Assistant with Amazon Quick +#### Anh Pham – Friendly AI Assistant with Amazon Quick - **Quick Chat Agent**: AI assistants for exploring and analyzing data - **Quick Flows**: build intelligent workflows with natural language, no coding required - **Quick Spaces**: collaborative spaces that turn individual insights into team knowledge - **Quick Sight**: build dashboards and reports from raw data using natural language -#### Anh Pham – From Edge To Origin: CloudFront as Your Foundation +#### Thinh Nguyen – From Edge To Origin: CloudFront as Your Foundation - Amazon CloudFront for every workload type - Cost optimization techniques with CloudFront @@ -131,8 +131,8 @@ Attending **AWS First Cloud AI Journey – Community Day** on May 23, 2026 was a - **Vy Lam** showed how multi-agent systems are already being used in serious financial domains, not just demos. #### Hands-on AWS exposure -- **Thinh Nguyen** demoed the **Amazon Quick** suite, which lowers the bar for building internal AI tools. -- **Anh Pham** went deep on **CloudFront** beyond CDN — security, cost, and reliability angles I had underused. +- **Anh Pham** demoed the **Amazon Quick** suite, which lowers the bar for building internal AI tools. +- **Thinh Nguyen** went deep on **CloudFront** beyond CDN — security, cost, and reliability angles I had underused. #### Inspiration from peers - The **UTMorpho / LotusHacks** story from **Uyen Le, Thao Nguyen, Mai Nguyen** was a strong reminder that 36 hours is enough to ship something meaningful with the right team. @@ -142,6 +142,20 @@ Attending **AWS First Cloud AI Journey – Community Day** on May 23, 2026 was a #### Some event photos -![Speakers of FCAJ Community Day](/images/4-EventParticipated/event-2/speakers.jpg) +![FCAJ Community Day](/images/4-EventParticipated/event-2/fcaj-community.jpg) + +![Nguyen Gia Hung](/images/4-EventParticipated/event-2/NguyenGiaHung.jpg) + +![Tinh Truong – Platform Engineer @ GoTymeX](/images/4-EventParticipated/event-2/TinhTruong.jpg) + +![Thinh Nguyen – DevOps Engineer | FCAJ Ambassador](/images/4-EventParticipated/event-2/ThinhNguyen.jpg) + +![Anh Pham – Cloud Consultant @ G-AsiaPacific Vietnam](/images/4-EventParticipated/event-2/AnhPham.jpg) + +![Uyen Le, Thao Nguyen, Mai Nguyen – GenAI Engineers @ VIB](/images/4-EventParticipated/event-2/UyenLe-ThaoNguyen-MaiNguyen.jpg) + +![Duc Dao – Solutions Architect @ Cloud Kinetics](/images/4-EventParticipated/event-2/DucDao.jpg) + +![Vy Lam – Senior Business Systems Analyst @ VPBank](/images/4-EventParticipated/event-2/VyLam.jpg) > Overall, the event reinforced that **building useful AI products is mostly about context, guardrails, and team execution** — and that the FCAJ community in HCMC is a great place to learn this together. diff --git a/content/4-EventParticipated/4.2-Event2/_index.vi.md b/content/4-EventParticipated/4.2-Event2/_index.vi.md index 6bc5df3..d9b5103 100644 --- a/content/4-EventParticipated/4.2-Event2/_index.vi.md +++ b/content/4-EventParticipated/4.2-Event2/_index.vi.md @@ -1,7 +1,7 @@ --- title: "AWS First Cloud AI Journey - Community Day" date: 2024-01-01 -weight: 1 +weight: 2 chapter: false pre: " 4.2. " --- @@ -35,8 +35,8 @@ pre: " 4.2. " | Thời gian | Diễn giả | Chủ đề | |---|---|---| | 09:00 – 09:30 | **Tinh Truong** | Context Is Everything: Making AI Actually Work for You | -| 09:30 – 09:45 | **Thinh Nguyen** | Friendly AI Assistant with Amazon Quick | -| 09:45 – 10:25 | **Anh Pham** | From Edge To Origin: CloudFront as Your Foundation | +| 09:30 – 09:45 | **Anh Pham** | Friendly AI Assistant with Amazon Quick | +| 09:45 – 10:25 | **Thinh Nguyen** | From Edge To Origin: CloudFront as Your Foundation | | 10:25 – 10:55 | **Uyen Le, Thao Nguyen, Mai Nguyen** | 36 hrs with LotusHacks – Building UTMorpho from Idea to Reality | | 10:55 – 11:00 | — | Giải lao | | 11:00 – 11:30 | **Duc Dao** | Non-Determinism of "Deterministic" LLM Settings | @@ -51,14 +51,14 @@ pre: " 4.2. " - Context tốt hơn dẫn đến kết quả tốt hơn — mindset và tips thực tế - Định hướng nghề nghiệp và cách sinh viên có thể bắt đầu xây dựng cùng AI -#### Thinh Nguyen – Friendly AI Assistant với Amazon Quick +#### Anh Pham – Friendly AI Assistant với Amazon Quick - **Quick Chat Agent**: trợ lý AI để khám phá và phân tích dữ liệu - **Quick Flows**: xây dựng workflow thông minh bằng ngôn ngữ tự nhiên, không cần code - **Quick Spaces**: không gian cộng tác biến insight cá nhân thành tri thức team - **Quick Sight**: dựng dashboard và report từ dữ liệu thô bằng natural language -#### Anh Pham – From Edge To Origin: CloudFront làm nền tảng +#### Thinh Nguyen – From Edge To Origin: CloudFront làm nền tảng - Amazon CloudFront cho mọi loại workload - Tối ưu chi phí với CloudFront @@ -131,8 +131,8 @@ Tham gia **AWS First Cloud AI Journey – Community Day** ngày 23/05/2026 là m - **Vy Lam** cho thấy multi-agent system đã được dùng trong domain tài chính nghiêm túc, không chỉ là demo. #### Tiếp cận AWS thực tế -- **Thinh Nguyen** demo bộ **Amazon Quick** — hạ thấp rào cản khi xây tool AI nội bộ. -- **Anh Pham** đào sâu **CloudFront** ngoài góc CDN — bảo mật, chi phí, độ tin cậy mà em từng dùng chưa hết. +- **Anh Pham** demo bộ **Amazon Quick** — hạ thấp rào cản khi xây tool AI nội bộ. +- **Thinh Nguyen** đào sâu **CloudFront** ngoài góc CDN — bảo mật, chi phí, độ tin cậy mà em từng dùng chưa hết. #### Cảm hứng từ những người trẻ - Câu chuyện **UTMorpho / LotusHacks** từ **Uyen Le, Thao Nguyen, Mai Nguyen** là minh chứng rằng 36 giờ vẫn đủ để ship một sản phẩm có ý nghĩa nếu có team đúng. @@ -142,6 +142,20 @@ Tham gia **AWS First Cloud AI Journey – Community Day** ngày 23/05/2026 là m #### Một số hình ảnh khi tham gia sự kiện -![Speakers of FCAJ Community Day](/images/4-EventParticipated/event-2/speakers.jpg) +![FCAJ Community Day](/images/4-EventParticipated/event-2/fcaj-community.jpg) + +![Nguyen Gia Hung](/images/4-EventParticipated/event-2/NguyenGiaHung.jpg) + +![Tinh Truong – Platform Engineer @ GoTymeX](/images/4-EventParticipated/event-2/TinhTruong.jpg) + +![Thinh Nguyen – DevOps Engineer | FCAJ Ambassador](/images/4-EventParticipated/event-2/ThinhNguyen.jpg) + +![Anh Pham – Cloud Consultant @ G-AsiaPacific Vietnam](/images/4-EventParticipated/event-2/AnhPham.jpg) + +![Uyen Le, Thao Nguyen, Mai Nguyen – GenAI Engineers @ VIB](/images/4-EventParticipated/event-2/UyenLe-ThaoNguyen-MaiNguyen.jpg) + +![Duc Dao – Solutions Architect @ Cloud Kinetics](/images/4-EventParticipated/event-2/DucDao.jpg) + +![Vy Lam – Senior Business Systems Analyst @ VPBank](/images/4-EventParticipated/event-2/VyLam.jpg) > Tổng thể, sự kiện củng cố một niềm tin: **xây dựng sản phẩm AI hữu ích chủ yếu là chuyện context, guardrails và năng lực thực thi của team** — và cộng đồng FCAJ tại HCMC là nơi rất tốt để cùng học điều đó. diff --git a/content/4-EventParticipated/4.3-Event3/_index.md b/content/4-EventParticipated/4.3-Event3/_index.md new file mode 100644 index 0000000..91e5931 --- /dev/null +++ b/content/4-EventParticipated/4.3-Event3/_index.md @@ -0,0 +1,146 @@ +--- +title: "Agentic Build Day and Community Activity" +date: 2024-01-01 +weight: 3 +chapter: false +pre: " 4.3. " +--- + + + +# Summary Report: “Agentic Build Day and Community Activity” + +### Event Objectives + +- Provide a 3-hour technical deep-dive into AWS's **agentic services** +- Walk through a real-world reference architecture: an **AI-powered marketing campaign platform** that orchestrates multiple specialized agents to automate audience segmentation, campaign creation, and promotions end to end +- Give attendees a working mental model of how AWS agentic services fit together +- Combine technical content with a hands-on **community activity** (making no-sew plush toys for children) + +### Speakers & Hosts + +- **Diem My / Dinh Nguyen** – Community Activity hosts +- **My Nguyen** – Why Agentic AI & the MarTech use case +- **Dai Truong / Thi Nguyen** – Kiro Workshop Guidance +- AWS GenAI Builders Club team – technical sessions + +### Agenda Timeline + +| Time | Session | Speaker | +|---|---|---| +| 13:00 – 14:00 | 🧸 Make No-Sew Plush Toys for Children (Community Activity) | Diem My / Dinh Nguyen | +| 14:00 – 14:15 | Why Agentic AI & the MarTech use case we'll explore | My Nguyen | +| 14:15 – 15:00 | AWS Agentic Services in Action: AgentCore Runtime, Memory, MCP Gateway & Agent-to-Agent (A2A) Communication | — | +| 15:00 – 15:15 | ☕ Tea Break | — | +| 15:15 – 15:40 | The Strands Agents Framework & how it ties everything together | — | +| 15:40 – 16:10 | Full Workflow Walkthrough: tracing the code from user prompt to campaign creation | — | +| 16:10 – 16:30 | Security Patterns, Session Persistence & Infrastructure as Code | — | +| 16:30 – 16:45 | Key Takeaways & Source Code Tour | — | +| 16:45 – 17:00 | Kiro Workshop Guidance | Dai Truong / Thi Nguyen | + +### Key Highlights + +#### Community Activity – No-Sew Plush Toys for Children + +- A warm, hands-on opener where attendees crafted **no-sew plush toys** to donate to children +- A reminder that a builders' community is about people, not just technology + +#### My Nguyen – Why Agentic AI & the MarTech use case + +- Why **agentic AI** is different from traditional prompt-response models +- Introduction to the **MarTech** reference use case: an AI-powered marketing campaign platform +- How multiple specialized agents collaborate to automate audience segmentation, campaign creation, and promotions + +#### AWS Agentic Services in Action + +- **AgentCore Runtime**: the execution environment for running agents +- **Memory**: how agents retain and recall context across interactions +- **MCP Gateway**: connecting agents to tools and data through the Model Context Protocol +- **Agent-to-Agent (A2A) Communication**: how specialized agents coordinate with each other + +#### The Strands Agents Framework + +- Overview of the **Strands Agents** framework +- How it ties the agentic services together into a cohesive workflow +- The role of orchestration in multi-agent systems + +#### Full Workflow Walkthrough + +- Tracing the code end to end — from a **user prompt** to a **created campaign** +- Seeing how the reference architecture executes in practice + +#### Security Patterns, Session Persistence & Infrastructure as Code + +- **Security patterns** for agentic workloads (IAM, least privilege) +- **Session persistence** to maintain state across agent runs +- **Infrastructure as Code** (CDK) to make the architecture reproducible + +#### Key Takeaways & Source Code Tour + +- A recap of the core concepts and how the pieces connect +- A guided tour of the **full source code** for self-paced exploration + +#### Dai Truong / Thi Nguyen – Kiro Workshop Guidance + +- Guidance on using **Kiro** for the workshop and building agentic features +- How to apply the spec-driven workflow to real projects + +### Key Takeaways + +- **Agentic AI** moves beyond single prompts toward systems of collaborating agents +- AWS provides building blocks — **AgentCore Runtime, Memory, MCP Gateway, A2A** — that fit together +- The **Strands Agents** framework is the glue that orchestrates multi-agent workflows +- Production agentic systems still need **security, session persistence, and IaC** to be reliable +- Having a complete **reference architecture + source code** is the fastest way to learn by adapting + +### Applying to Work + +- Use the **MarTech reference architecture** as a template for any multi-step automation use case +- Experiment with **AgentCore Memory** to give internal assistants persistent context +- Connect existing tools through an **MCP Gateway** instead of hardcoding integrations +- Apply **A2A communication** to break a complex single-agent prompt into specialized agents +- Adopt **CDK / Infrastructure as Code** so agentic deployments are reproducible and reviewable +- Try **Kiro** for spec-driven development of agentic features + +### Prerequisites + +- Familiarity with AWS (Lambda, IAM, CDK) and basic Python +- No prior experience with AI agents required + +### Event Experience + +Attending **Agentic Build Day and Community Activity** on May 29, 2026 was a great mix of meaningful community work and a focused technical deep-dive. Key moments included: + +#### Starting with the community +- The event opened with a **no-sew plush toy** activity for children, hosted by **Diem My** and **Dinh Nguyen** — a heartwarming way to connect with other builders before diving into code. + +#### Learning the agentic stack end to end +- **My Nguyen** framed the day with a clear **MarTech use case**, making the abstract idea of "agentic AI" concrete. +- The deep-dive into **AgentCore Runtime, Memory, MCP Gateway, and A2A** finally connected services I had only read about separately. +- Seeing the **Strands Agents** framework tie everything together clarified how orchestration actually works in practice. + +#### Following real code +- The **full workflow walkthrough** — from user prompt to campaign creation — was the most valuable part, turning theory into a traceable execution path. +- The session on **security, session persistence, and IaC** was a good reminder that demos are easy but production needs guardrails. + +#### Hands-on with Kiro +- **Dai Truong** and **Thi Nguyen** wrapped up with **Kiro Workshop Guidance**, showing how to apply a spec-driven workflow to build agentic features. + +#### What I left with +- A working mental model of how AWS agentic services fit together +- A reference architecture I can adapt for my own use cases +- Access to the full source code to explore at my own pace + +#### Some event photos + +![Agentic Build Day](/images/4-EventParticipated/event-3/1780046299367.jpg) + +![Agentic Build Day](/images/4-EventParticipated/event-3/1780046308292.jpg) + +![Agentic Build Day](/images/4-EventParticipated/event-3/1780046311474.jpg) + +![Agentic Build Day](/images/4-EventParticipated/event-3/1780050160542.jpg) + +> Overall, **Agentic Build Day** balanced heart and engineering — giving back to the community in the first hour, then handing us a complete, adaptable blueprint for building real agentic systems on AWS. diff --git a/content/4-EventParticipated/4.3-Event3/_index.vi.md b/content/4-EventParticipated/4.3-Event3/_index.vi.md new file mode 100644 index 0000000..d3eefad --- /dev/null +++ b/content/4-EventParticipated/4.3-Event3/_index.vi.md @@ -0,0 +1,146 @@ +--- +title: "Agentic Build Day and Community Activity" +date: 2024-01-01 +weight: 3 +chapter: false +pre: " 4.3. " +--- + + + +# Bài thu hoạch “Agentic Build Day and Community Activity” + +### Mục đích của sự kiện + +- Buổi deep-dive kỹ thuật 3 tiếng về các **agentic services** của AWS +- Đi qua một reference architecture thực tế: nền tảng **AI-powered marketing campaign** điều phối nhiều agent chuyên biệt để tự động hóa phân khúc khách hàng, tạo chiến dịch và khuyến mãi từ đầu đến cuối +- Giúp người tham dự có mô hình tư duy rõ ràng về cách các agentic services của AWS ghép lại với nhau +- Kết hợp nội dung kỹ thuật với **hoạt động cộng đồng** (làm thú nhồi bông không cần may cho trẻ em) + +### Diễn giả & người dẫn + +- **Diem My / Dinh Nguyen** – Dẫn dắt hoạt động cộng đồng +- **My Nguyen** – Why Agentic AI & use case MarTech +- **Dai Truong / Thi Nguyen** – Hướng dẫn Kiro Workshop +- Đội ngũ AWS GenAI Builders Club – các phiên kỹ thuật + +### Lịch trình sự kiện + +| Thời gian | Nội dung | Diễn giả | +|---|---|---| +| 13:00 – 14:00 | 🧸 Làm thú nhồi bông không cần may cho trẻ em (Hoạt động cộng đồng) | Diem My / Dinh Nguyen | +| 14:00 – 14:15 | Vì sao Agentic AI & use case MarTech sẽ khám phá | My Nguyen | +| 14:15 – 15:00 | AWS Agentic Services in Action: AgentCore Runtime, Memory, MCP Gateway & Agent-to-Agent (A2A) Communication | — | +| 15:00 – 15:15 | ☕ Giải lao | — | +| 15:15 – 15:40 | Strands Agents Framework & cách nó kết nối mọi thứ | — | +| 15:40 – 16:10 | Full Workflow Walkthrough: lần theo code từ user prompt đến tạo chiến dịch | — | +| 16:10 – 16:30 | Security Patterns, Session Persistence & Infrastructure as Code | — | +| 16:30 – 16:45 | Key Takeaways & Source Code Tour | — | +| 16:45 – 17:00 | Hướng dẫn Kiro Workshop | Dai Truong / Thi Nguyen | + +### Nội dung nổi bật + +#### Hoạt động cộng đồng – Thú nhồi bông không cần may cho trẻ em + +- Phần mở đầu ấm áp, ai cũng tự tay làm **thú nhồi bông không cần may** để tặng cho trẻ em +- Nhắc nhở rằng một cộng đồng builder là về con người, không chỉ công nghệ + +#### My Nguyen – Vì sao Agentic AI & use case MarTech + +- Vì sao **agentic AI** khác với mô hình prompt-response truyền thống +- Giới thiệu use case tham chiếu **MarTech**: nền tảng marketing campaign chạy bằng AI +- Cách nhiều agent chuyên biệt phối hợp để tự động hóa phân khúc khách hàng, tạo chiến dịch và khuyến mãi + +#### AWS Agentic Services in Action + +- **AgentCore Runtime**: môi trường thực thi để chạy các agent +- **Memory**: cách agent lưu giữ và truy hồi context qua các lần tương tác +- **MCP Gateway**: kết nối agent với tools và dữ liệu qua Model Context Protocol +- **Agent-to-Agent (A2A) Communication**: cách các agent chuyên biệt phối hợp với nhau + +#### Strands Agents Framework + +- Tổng quan về framework **Strands Agents** +- Cách nó gắn kết các agentic services thành một workflow thống nhất +- Vai trò của orchestration trong hệ multi-agent + +#### Full Workflow Walkthrough + +- Lần theo code từ đầu đến cuối — từ **user prompt** đến **chiến dịch được tạo ra** +- Thấy reference architecture chạy thực tế ra sao + +#### Security Patterns, Session Persistence & Infrastructure as Code + +- **Security patterns** cho agentic workloads (IAM, least privilege) +- **Session persistence** để giữ trạng thái qua các lần chạy agent +- **Infrastructure as Code** (CDK) để kiến trúc có thể tái lập + +#### Key Takeaways & Source Code Tour + +- Tóm tắt các khái niệm cốt lõi và cách các mảnh ghép kết nối +- Tour qua **toàn bộ source code** để tự khám phá theo nhịp riêng + +#### Dai Truong / Thi Nguyen – Hướng dẫn Kiro Workshop + +- Hướng dẫn dùng **Kiro** cho workshop và xây các tính năng agentic +- Cách áp dụng workflow spec-driven vào project thực tế + +### Những gì học được + +- **Agentic AI** vượt khỏi single prompt, tiến tới hệ thống các agent phối hợp với nhau +- AWS cung cấp các building block — **AgentCore Runtime, Memory, MCP Gateway, A2A** — ghép lại với nhau +- Framework **Strands Agents** là chất keo điều phối các workflow multi-agent +- Hệ agentic chạy production vẫn cần **security, session persistence và IaC** để đáng tin cậy +- Có sẵn **reference architecture + source code** là cách học nhanh nhất qua việc tùy biến lại + +### Ứng dụng vào công việc + +- Dùng **reference architecture MarTech** làm template cho mọi use case tự động hóa nhiều bước +- Thử nghiệm **AgentCore Memory** để cho trợ lý nội bộ có context bền vững +- Kết nối các tool hiện có qua **MCP Gateway** thay vì hardcode integration +- Áp dụng **A2A communication** để tách một prompt single-agent phức tạp thành các agent chuyên biệt +- Dùng **CDK / Infrastructure as Code** để deploy agentic có thể tái lập và review được +- Thử **Kiro** cho phát triển spec-driven các tính năng agentic + +### Yêu cầu cần có + +- Quen thuộc với AWS (Lambda, IAM, CDK) và Python cơ bản +- Không cần kinh nghiệm trước với AI agents + +### Trải nghiệm trong event + +Tham gia **Agentic Build Day and Community Activity** ngày 29/05/2026 là sự kết hợp tuyệt vời giữa hoạt động cộng đồng ý nghĩa và một buổi deep-dive kỹ thuật tập trung. Một số khoảnh khắc nổi bật: + +#### Bắt đầu bằng cộng đồng +- Sự kiện mở đầu bằng hoạt động làm **thú nhồi bông không cần may** cho trẻ em, do **Diem My** và **Dinh Nguyen** dẫn dắt — một cách rất ấm áp để kết nối với các builder khác trước khi vào phần code. + +#### Học toàn bộ agentic stack +- **My Nguyen** mở màn với use case **MarTech** rõ ràng, biến khái niệm trừu tượng "agentic AI" thành thứ cụ thể. +- Phần deep-dive về **AgentCore Runtime, Memory, MCP Gateway và A2A** cuối cùng đã kết nối những service mà trước đó em chỉ đọc rời rạc. +- Thấy framework **Strands Agents** gắn kết mọi thứ giúp em hiểu orchestration thực sự hoạt động thế nào. + +#### Lần theo code thật +- **Full workflow walkthrough** — từ user prompt đến tạo chiến dịch — là phần giá trị nhất, biến lý thuyết thành một đường thực thi có thể lần theo được. +- Phiên về **security, session persistence và IaC** là lời nhắc rằng demo thì dễ nhưng production cần guardrails. + +#### Thực hành với Kiro +- **Dai Truong** và **Thi Nguyen** khép lại với **Hướng dẫn Kiro Workshop**, cho thấy cách áp dụng workflow spec-driven để xây tính năng agentic. + +#### Những gì em mang về +- Mô hình tư duy rõ ràng về cách các agentic services của AWS ghép lại với nhau +- Một reference architecture có thể tùy biến cho use case của riêng mình +- Quyền truy cập toàn bộ source code để tự khám phá theo nhịp riêng + +#### Một số hình ảnh khi tham gia sự kiện + +![Agentic Build Day](/images/4-EventParticipated/event-3/1780046299367.jpg) + +![Agentic Build Day](/images/4-EventParticipated/event-3/1780046308292.jpg) + +![Agentic Build Day](/images/4-EventParticipated/event-3/1780046311474.jpg) + +![Agentic Build Day](/images/4-EventParticipated/event-3/1780050160542.jpg) + +> Tổng thể, **Agentic Build Day** cân bằng giữa cái tâm và kỹ thuật — cho đi với cộng đồng trong giờ đầu, rồi trao cho chúng em một blueprint hoàn chỉnh, dễ tùy biến để xây dựng hệ agentic thực sự trên AWS. diff --git a/content/4-EventParticipated/4.4-Event4/_index.md b/content/4-EventParticipated/4.4-Event4/_index.md new file mode 100644 index 0000000..8e8ab9d --- /dev/null +++ b/content/4-EventParticipated/4.4-Event4/_index.md @@ -0,0 +1,121 @@ +--- +title: "Amazon Quick & Kiro Fiesta #2" +date: 2024-01-01 +weight: 4 +chapter: false +pre: " 4.4. " +--- + + + +# Summary Report: “Amazon Quick & Kiro Fiesta #2” + +### Event Objectives + +- Deliver a full-day, hands-on AI workshop hosted by AWS, split into two sessions for two audiences +- **Morning – Amazon Quick:** show business and finance leaders how an AI-powered executive assistant streamlines decision-making, from morning briefs to strategic analysis, with no technical skills required +- **Afternoon – Kiro:** show infrastructure teams how Kiro, AWS's AI-native IDE, brings AI productivity together with enterprise-grade guardrails for Security, DevOps, and FinOps +- Give attendees hands-on time to configure their own Amazon Quick workspace and set up Kiro with AWS Solutions Architect guidance + +### Hosts + +- **Morning Session (Amazon Quick):** AWS team from Singapore +- **Afternoon Session (Kiro):** AWS Vietnam team & AWS Solutions Architects +- AWS GenAI Builders Club + +### Agenda Timeline + +#### Morning Session: Amazon Quick — “A Day in the Life of a CxO” + +| Time | Session | +|---|---| +| 9:00 – 9:30 | Morning Brief — AI pulls overnight updates, flags exceptions, prepares your daily snapshot | +| 9:30 – 10:30 | Financial Deep-Dive — Budget vs actual, cash flow forecasting, case studies (Zurich, Jabil $400K savings) | +| 10:30 – 11:15 | Strategic Analysis — Quick Research: complex questions answered in minutes from your own data | +| 11:15 – 12:00 | Hands-On — Configure your own Amazon Quick workspace with AWS SA guidance | +| 12:00 – 1:30 | 🍽️ Lunch & Networking | + +#### Afternoon Session: Kiro — “KiroOps” + +| Time | Session | +|---|---| +| 1:30 – 1:45 | Introduction — GenAI for Infrastructure: use cases for DevOps, Security, FinOps, SRE | +| 1:45 – 2:15 | Getting Started — Set up Kiro IDE/CLI, explore Supervised vs Autopilot modes | +| 2:15 – 3:00 | Empowering Your Kiro — Agent Hooks (auto cfn-lint, block destructive commands), Steering (security baselines, tagging), AWS MCP Server | +| 3:00 – 3:15 | ☕ Break | +| 3:15 – 3:45 | Enterprise Governance — SCPs + user-agent markers, cost management, CloudTrail audit | +| 3:45 – 4:15 | Troubleshoot Lab — Diagnose a real infrastructure issue with Kiro (network, IAM, cost) | +| 4:15 – 4:30 | Wrap-up — Next steps, Assisted Trial Program, Q&A | + +### Key Highlights + +#### Morning – Amazon Quick: “Your 24/7 AI-Powered Executive Assistant” + +- The framing problem: executives lose 40+ hours monthly switching between apps, compiling data, and waiting for answers +- Walked through a real CxO's day to show how **Amazon Quick** acts as an AI Chief of Staff that already knows your data, people, and priorities +- **Morning Brief:** the assistant pulls overnight updates, flags exceptions, and prepares a daily snapshot +- **Financial Deep-Dive:** budget vs actual, cash flow forecasting, with real case studies (Zurich, Jabil's $400K savings) +- **Strategic Analysis:** Quick Research answers complex questions in minutes directly from your own data +- **Hands-On:** attendees configured their own Amazon Quick workspace with AWS SA guidance — no technical skills required + +#### Afternoon – Kiro: “KiroOps for Infrastructure Teams” + +- The framing problem: infrastructure teams are adopting AI coding tools and velocity is up, but who ensures the AI follows security baselines, enforces tagging, and controls what it can do in your AWS accounts? +- **Getting Started:** set up the Kiro IDE/CLI and explored **Supervised vs Autopilot** modes +- **Empowering Your Kiro:** **Agent Hooks** (auto cfn-lint, block destructive commands), **Steering** (security baselines, tagging policies), and the **AWS MCP Server** +- **Enterprise Governance:** SCPs combined with user-agent markers, cost management, and CloudTrail audit +- **Troubleshoot Lab:** diagnosed a real infrastructure issue with Kiro across network, IAM, and cost +- **Wrap-up:** next steps, the Assisted Trial Program, and Q&A + +### Key Takeaways + +- AI assistants like **Amazon Quick** can remove repetitive executive workload — data gathering, reporting, and ad-hoc research — and return hours back to leaders +- Self-service analytics built on your own data shortens the path from question to decision +- For engineering teams, AI productivity must come with **guardrails**: Agent Hooks, Steering, and governance keep AI-assisted work safe and compliant +- **Kiro's Supervised vs Autopilot** modes let teams choose the right level of control for each task +- Enterprise governance — **SCPs, user-agent markers, cost controls, and CloudTrail audit** — is what makes AI tooling safe to adopt at scale + +### Applying to Work + +- Use **Amazon Quick** patterns to automate recurring reporting and research instead of manual app-switching +- Adopt **Kiro Agent Hooks** to auto-run cfn-lint and block destructive commands in my own workflow +- Apply **Steering files** to encode security baselines and tagging policies so AI output stays consistent +- Connect the **AWS MCP Server** to give Kiro safe, scoped access to AWS context +- Default to **Supervised mode** for high-risk infrastructure changes and **Autopilot** for routine tasks + +### Who Should Attend + +- **Morning (Amazon Quick):** CxOs, VPs, Finance Directors, CFOs, FP&A Analysts, Controllers, Heads of Operations, and IT Directors seeking self-service analytics +- **Afternoon (Kiro):** Platform Engineers, DevOps Engineers, Cloud Architects, Security Engineers, Compliance Officers, FinOps Practitioners, SRE / Operations Engineers, and Engineering Managers overseeing infrastructure teams + +### Event Experience + +Attending **Amazon Quick & Kiro Fiesta #2** on June 19, 2026 at the AWS Vietnam Office was a packed, full-day experience covering both the business and engineering sides of AI adoption. Key moments included: + +#### A leadership lens in the morning +- The **Amazon Quick** session reframed AI around an executive's real day, making the value tangible: less time compiling data, more time deciding. +- The financial case studies (Zurich, Jabil's $400K savings) showed concrete outcomes rather than abstract promises. +- The hands-on workspace setup made the tool feel approachable even without technical background. + +#### An engineering lens in the afternoon +- The **Kiro** session spoke directly to the concern of every infrastructure team: how to gain AI velocity without losing control. +- Seeing **Agent Hooks** auto-run cfn-lint and block destructive commands made the guardrails concept concrete. +- **Steering** for security baselines and tagging, plus the **AWS MCP Server**, showed how to keep AI output aligned with policy. +- The **Troubleshoot Lab** was the highlight — diagnosing a real network/IAM/cost issue with Kiro turned theory into practice. + +#### What I left with +- A clear picture of how AI helps both leaders and engineers, each in their own workflow +- Practical guardrail patterns I can apply with Kiro right away +- Awareness of the Assisted Trial Program for continued learning + +#### Some event photos + +![Amazon Quick & Kiro Fiesta #2](/images/4-EventParticipated/event-4/1781862217262.jpg) + +![Amazon Quick & Kiro Fiesta #2](/images/4-EventParticipated/event-4/1781862219032.jpg) + +![Amazon Quick & Kiro Fiesta #2](/images/4-EventParticipated/event-4/1781914266028.jpg) + +> Overall, **Amazon Quick & Kiro Fiesta #2** connected two audiences in one day — showing leaders how AI returns hours to their schedule, and showing engineers how to adopt AI with enterprise-grade guardrails built in. diff --git a/content/4-EventParticipated/4.4-Event4/_index.vi.md b/content/4-EventParticipated/4.4-Event4/_index.vi.md new file mode 100644 index 0000000..7a7e904 --- /dev/null +++ b/content/4-EventParticipated/4.4-Event4/_index.vi.md @@ -0,0 +1,121 @@ +--- +title: "Amazon Quick & Kiro Fiesta #2" +date: 2024-01-01 +weight: 4 +chapter: false +pre: " 4.4. " +--- + + + +# Bài thu hoạch “Amazon Quick & Kiro Fiesta #2” + +### Mục đích của sự kiện + +- Một workshop AI hands-on trọn ngày do AWS tổ chức, chia thành hai phiên cho hai nhóm đối tượng +- **Buổi sáng – Amazon Quick:** cho các lãnh đạo kinh doanh và tài chính thấy một trợ lý điều hành chạy bằng AI giúp tinh gọn việc ra quyết định ra sao, từ morning brief đến phân tích chiến lược, không yêu cầu kỹ năng kỹ thuật +- **Buổi chiều – Kiro:** cho các đội hạ tầng thấy Kiro — AI-native IDE của AWS — kết hợp năng suất AI với guardrails cấp doanh nghiệp cho Security, DevOps và FinOps +- Dành thời gian hands-on để người tham dự tự cấu hình Amazon Quick workspace của mình và set up Kiro với sự hướng dẫn của AWS Solutions Architect + +### Đơn vị tổ chức + +- **Phiên sáng (Amazon Quick):** Đội ngũ AWS từ Singapore +- **Phiên chiều (Kiro):** Đội ngũ AWS Vietnam & các AWS Solutions Architects +- AWS GenAI Builders Club + +### Lịch trình sự kiện + +#### Phiên sáng: Amazon Quick — “A Day in the Life of a CxO” + +| Thời gian | Nội dung | +|---|---| +| 9:00 – 9:30 | Morning Brief — AI tổng hợp cập nhật qua đêm, gắn cờ ngoại lệ, chuẩn bị snapshot trong ngày | +| 9:30 – 10:30 | Financial Deep-Dive — Budget vs actual, dự báo dòng tiền, case study (Zurich, Jabil tiết kiệm $400K) | +| 10:30 – 11:15 | Strategic Analysis — Quick Research: trả lời câu hỏi phức tạp trong vài phút từ dữ liệu của bạn | +| 11:15 – 12:00 | Hands-On — Tự cấu hình Amazon Quick workspace với hướng dẫn của AWS SA | +| 12:00 – 1:30 | 🍽️ Ăn trưa & Networking | + +#### Phiên chiều: Kiro — “KiroOps” + +| Thời gian | Nội dung | +|---|---| +| 1:30 – 1:45 | Introduction — GenAI cho hạ tầng: use case cho DevOps, Security, FinOps, SRE | +| 1:45 – 2:15 | Getting Started — Set up Kiro IDE/CLI, khám phá chế độ Supervised vs Autopilot | +| 2:15 – 3:00 | Empowering Your Kiro — Agent Hooks (auto cfn-lint, chặn lệnh phá hủy), Steering (security baseline, tagging), AWS MCP Server | +| 3:00 – 3:15 | ☕ Giải lao | +| 3:15 – 3:45 | Enterprise Governance — SCPs + user-agent markers, quản lý chi phí, CloudTrail audit | +| 3:45 – 4:15 | Troubleshoot Lab — Chẩn đoán một sự cố hạ tầng thực tế với Kiro (network, IAM, cost) | +| 4:15 – 4:30 | Wrap-up — Bước tiếp theo, Assisted Trial Program, Q&A | + +### Nội dung nổi bật + +#### Buổi sáng – Amazon Quick: “Trợ lý điều hành chạy bằng AI 24/7” + +- Vấn đề đặt ra: lãnh đạo mất hơn 40 giờ mỗi tháng để chuyển qua lại giữa các app, tổng hợp dữ liệu và chờ câu trả lời +- Đi qua một ngày làm việc thật của CxO để thấy **Amazon Quick** đóng vai trò AI Chief of Staff đã hiểu sẵn dữ liệu, con người và ưu tiên của bạn +- **Morning Brief:** trợ lý tổng hợp cập nhật qua đêm, gắn cờ ngoại lệ và chuẩn bị snapshot trong ngày +- **Financial Deep-Dive:** budget vs actual, dự báo dòng tiền, kèm case study thực tế (Zurich, Jabil tiết kiệm $400K) +- **Strategic Analysis:** Quick Research trả lời câu hỏi phức tạp trong vài phút ngay từ dữ liệu của bạn +- **Hands-On:** người tham dự tự cấu hình Amazon Quick workspace với hướng dẫn của AWS SA — không cần kỹ năng kỹ thuật + +#### Buổi chiều – Kiro: “KiroOps cho đội hạ tầng” + +- Vấn đề đặt ra: đội hạ tầng đang dùng AI coding tools và tốc độ tăng lên, nhưng ai đảm bảo AI tuân theo security baseline, enforce tagging và kiểm soát những gì AI được làm trong tài khoản AWS? +- **Getting Started:** set up Kiro IDE/CLI và khám phá chế độ **Supervised vs Autopilot** +- **Empowering Your Kiro:** **Agent Hooks** (auto cfn-lint, chặn lệnh phá hủy), **Steering** (security baseline, chính sách tagging) và **AWS MCP Server** +- **Enterprise Governance:** SCPs kết hợp user-agent markers, quản lý chi phí và CloudTrail audit +- **Troubleshoot Lab:** chẩn đoán một sự cố hạ tầng thực tế với Kiro qua network, IAM và cost +- **Wrap-up:** bước tiếp theo, Assisted Trial Program và Q&A + +### Những gì học được + +- Các trợ lý AI như **Amazon Quick** có thể bỏ bớt khối lượng việc lặp lại của lãnh đạo — thu thập dữ liệu, báo cáo, nghiên cứu ad-hoc — và trả lại thời gian cho họ +- Self-service analytics dựa trên chính dữ liệu của bạn rút ngắn đường đi từ câu hỏi đến quyết định +- Với đội kỹ thuật, năng suất AI phải đi kèm **guardrails**: Agent Hooks, Steering và governance giúp việc dùng AI an toàn và tuân thủ +- Chế độ **Supervised vs Autopilot** của Kiro cho phép đội chọn mức kiểm soát phù hợp cho từng task +- Enterprise governance — **SCPs, user-agent markers, kiểm soát chi phí và CloudTrail audit** — là thứ giúp tooling AI an toàn khi áp dụng ở quy mô lớn + +### Ứng dụng vào công việc + +- Áp dụng pattern của **Amazon Quick** để tự động hóa báo cáo và nghiên cứu định kỳ thay vì chuyển app thủ công +- Dùng **Kiro Agent Hooks** để tự chạy cfn-lint và chặn lệnh phá hủy trong workflow của mình +- Dùng **Steering files** để mã hóa security baseline và chính sách tagging nhằm giữ output của AI nhất quán +- Kết nối **AWS MCP Server** để cho Kiro truy cập context AWS an toàn và có giới hạn +- Mặc định dùng **Supervised mode** cho các thay đổi hạ tầng rủi ro cao và **Autopilot** cho task thường ngày + +### Đối tượng nên tham gia + +- **Buổi sáng (Amazon Quick):** CxO, VP, Finance Director, CFO, FP&A Analyst, Controller, Head of Operations và IT Director cần self-service analytics +- **Buổi chiều (Kiro):** Platform Engineer, DevOps Engineer, Cloud Architect, Security Engineer, Compliance Officer, FinOps Practitioner, SRE / Operations Engineer và Engineering Manager phụ trách đội hạ tầng + +### Trải nghiệm trong event + +Tham gia **Amazon Quick & Kiro Fiesta #2** ngày 19/06/2026 tại văn phòng AWS Vietnam là một trải nghiệm trọn ngày dày đặc, bao quát cả khía cạnh kinh doanh lẫn kỹ thuật của việc áp dụng AI. Một số khoảnh khắc nổi bật: + +#### Góc nhìn lãnh đạo buổi sáng +- Phiên **Amazon Quick** đặt AI vào một ngày làm việc thật của lãnh đạo, làm giá trị trở nên rõ ràng: bớt thời gian tổng hợp dữ liệu, thêm thời gian ra quyết định. +- Các case study tài chính (Zurich, Jabil tiết kiệm $400K) cho thấy kết quả cụ thể chứ không phải hứa hẹn trừu tượng. +- Phần tự set up workspace khiến công cụ trở nên dễ tiếp cận kể cả khi không có nền tảng kỹ thuật. + +#### Góc nhìn kỹ thuật buổi chiều +- Phiên **Kiro** nói thẳng vào nỗi lo của mọi đội hạ tầng: làm sao có tốc độ AI mà không mất kiểm soát. +- Thấy **Agent Hooks** tự chạy cfn-lint và chặn lệnh phá hủy giúp khái niệm guardrails trở nên cụ thể. +- **Steering** cho security baseline và tagging, cùng **AWS MCP Server**, cho thấy cách giữ output AI bám theo chính sách. +- **Troubleshoot Lab** là phần hay nhất — chẩn đoán một sự cố network/IAM/cost thật với Kiro biến lý thuyết thành thực hành. + +#### Những gì em mang về +- Bức tranh rõ ràng về cách AI hỗ trợ cả lãnh đạo lẫn kỹ sư, mỗi bên trong workflow riêng +- Các pattern guardrails thực dụng có thể áp dụng với Kiro ngay +- Biết đến Assisted Trial Program để tiếp tục học hỏi + +#### Một số hình ảnh khi tham gia sự kiện + +![Amazon Quick & Kiro Fiesta #2](/images/4-EventParticipated/event-4/1781862217262.jpg) + +![Amazon Quick & Kiro Fiesta #2](/images/4-EventParticipated/event-4/1781862219032.jpg) + +![Amazon Quick & Kiro Fiesta #2](/images/4-EventParticipated/event-4/1781914266028.jpg) + +> Tổng thể, **Amazon Quick & Kiro Fiesta #2** kết nối hai nhóm đối tượng trong một ngày — cho lãnh đạo thấy AI trả lại thời gian cho lịch làm việc của họ, và cho kỹ sư thấy cách áp dụng AI với guardrails cấp doanh nghiệp tích hợp sẵn. diff --git a/content/4-EventParticipated/4.5-Event5/_index.md b/content/4-EventParticipated/4.5-Event5/_index.md new file mode 100644 index 0000000..8b5a94f --- /dev/null +++ b/content/4-EventParticipated/4.5-Event5/_index.md @@ -0,0 +1,136 @@ +--- +title: "FCAJ Community Day" +date: 2024-01-01 +weight: 5 +chapter: false +pre: " 4.5. " +--- + +# Summary Report: “FCAJ Community Day” + +### Event Objectives + +- Introduce practical AI solutions for cloud operations, incident response, customer conversations, and enterprise workforce planning +- Show how AWS services and agentic systems can move operational teams from detecting problems to taking guided or autonomous action +- Share architectures and live demonstrations involving Amazon Nova Sonic, AWS DevOps Agent, Amazon Bedrock AgentCore, Amazon Quick, and Model Context Protocol (MCP) +- Discuss the security and connectivity requirements needed to bring enterprise data and private tools into AI-assisted workflows + +### Agenda Timeline + +| Time | Session | Speakers | +|---|---|---| +| 8:30 – 9:00 | Check-in and settle into the venue | Organizing team | +| 9:00 – 9:25 | Deep Response Engine: From Detection to Autonomous Resolution | Nhat Tran | +| 9:25 – 9:55 | Voice Agents: Building Human-Like AI Conversations at Scale | Trung Vu, Kiet Tran, Nghị Danh Hoàng Hiếu | +| 9:55 – 10:20 | AWS DevOps Agent: Your Always-Available Operations Teammate | Bao Phan Kim, Minh Nguyen Nguyen | +| 10:20 – 10:45 | AI-Powered Productivity: Workforce Planning for Enterprise | Trường Trần, Minh Anh Đặng Cao | +| 10:45 – 11:30 | Building Secure Private MCP Connection with Amazon Quick | Đức Toàn Nguyễn, Nghị Danh Hoàng Hiếu | + +### Key Highlights + +#### Deep Response Engine: From Detection to Autonomous Resolution + +**Speaker:** Nhat Tran + +- Explained the complexity wall that cloud operations teams face as infrastructure and service dependencies grow +- Compared alert-driven operations, where engineers manually investigate every signal, with action-driven systems that can collect context and recommend or execute remediation +- Presented the architecture of a Deep Response Engine and demonstrated an autonomous incident-response flow +- Connected technical improvements to measurable business outcomes such as lower operating cost and reduced downtime + +#### Voice Agents: Building Human-Like AI Conversations at Scale + +**Speakers:** Trung Vu, Kiet Tran, and Nghị Danh Hoàng Hiếu + +- Traced the evolution from traditional IVR systems and text chatbots to conversational AI voice agents +- Discussed the main engineering challenges: end-to-end latency, speech accuracy, natural turn-taking, and knowing when a user has finished speaking +- Introduced **Amazon Nova Sonic** as a speech-to-speech foundation model for real-time conversation +- Explained an architecture combining telephony, bidirectional streaming, Amazon Bedrock, and MCP-connected tools +- Demonstrated enterprise use cases and implementation practices for building voice experiences at scale + +#### AWS DevOps Agent: An Always-Available Operations Teammate + +**Speakers:** Bao Phan Kim and Minh Nguyen Nguyen + +- Introduced **AWS DevOps Agent** and its role in supporting investigation and response throughout the incident lifecycle +- Showed how AI-assisted operations can reduce Mean Time to Detect (MTTD) and Mean Time to Resolve (MTTR) +- Covered support for AWS, multi-cloud, and hybrid environments rather than limiting operations context to a single platform +- Explained the use of **Amazon Bedrock AgentCore** and multi-agent reasoning to bring together telemetry, operational knowledge, and recommended actions +- Walked through a practical Amazon ECS troubleshooting demonstration + +#### AI-Powered Workforce Planning with Amazon Quick + +**Speakers:** Trường Trần and Minh Anh Đặng Cao + +- Framed common HR challenges such as manual CV screening, limited visibility into talent pipelines, and decisions made without complete data +- Introduced the capabilities of the **Amazon Quick Suite**, including chat agents, research, QuickSight, flows, and automation +- Demonstrated how automation can accelerate recurring HR processes and make workforce analytics easier to access +- Connected operational HR data with strategic workforce planning and enterprise decision-making + +#### Secure Private MCP Connectivity with Amazon Quick + +**Speakers:** Đức Toàn Nguyễn and Nghị Danh Hoàng Hiếu + +- Explained how MCP extends an AI assistant by connecting it to external tools and enterprise context +- Identified the risk of exposing an MCP server through a public endpoint, including a larger attack surface, sensitive data traveling over the public internet, and data-residency or zero-trust concerns +- Presented private VPC connectivity as a safer integration pattern for Amazon Quick and internal MCP services +- Combined architecture explanation with a demonstration and practical implementation insights + +### Key Takeaways + +- Modern operations should progress from collecting more alerts to creating a reliable path from detection, through investigation, to action +- Autonomous remediation is valuable only when it has clear context, scoped permissions, observability, and safe fallback paths +- Real-time voice AI is a streaming-system problem as much as a model problem; latency and turn-taking directly shape the user experience +- AI operations agents can reduce MTTD and MTTR by correlating telemetry and operational knowledge, but engineers remain responsible for validating high-impact actions +- Enterprise AI adoption requires private connectivity, least-privilege access, auditable tool calls, and explicit controls around sensitive data +- Amazon Quick can support both knowledge work and workforce planning when it is connected to trusted organizational data + +### Applying the Lessons to My Work + +- Design incident workflows with explicit stages for detection, context collection, diagnosis, recommendation, approval, execution, and post-incident review +- Apply human approval to high-risk remediation while allowing low-risk, repeatable actions to be automated +- Measure operational improvements through MTTD, MTTR, recurrence rate, and the proportion of incidents resolved without escalation +- When prototyping a voice agent, test interruption handling, turn detection, response latency, and failure recovery instead of evaluating only answer quality +- Keep MCP services private where possible and enforce IAM, network boundaries, logging, and least-privilege tool access +- Use trusted data sources and clear access controls when applying Amazon Quick to internal reporting or workforce analysis + +### Event Experience + +Attending **FCAJ Community Day** gave me a connected view of how agentic AI is moving from experimentation into real operational and enterprise workflows. Instead of presenting AI as a standalone chatbot, the sessions showed it working with telemetry, cloud services, voice streams, internal data, and private tools. + +#### From cloud signals to operational action + +- The Deep Response Engine and AWS DevOps Agent sessions made the incident lifecycle concrete: detect a signal, gather context, reason across possible causes, and propose or perform a safe response. +- The ECS demonstration helped connect the architecture to a scenario that cloud engineers can encounter in real systems. + +#### Understanding voice AI as a complete system + +- The voice-agent session showed that natural conversation depends on much more than speech recognition. +- The discussion about latency, interruption, and turn-taking clarified why streaming architecture and user-experience design are essential to voice applications. + +#### Connecting AI to enterprise data safely + +- The Amazon Quick sessions expanded the discussion from engineering operations to workforce planning and enterprise productivity. +- The private MCP connectivity session was especially relevant because it addressed the security boundary between an AI assistant and sensitive internal systems. + +#### What I left with + +- A clearer mental model for agentic operations and autonomous incident response +- Practical criteria for evaluating real-time voice-agent architectures +- A stronger understanding of how MCP connectivity, VPC design, and access control support secure enterprise AI +- New ideas that can be applied to cloud architecture and the DocuFlow AI project, particularly around safe external-tool integration and human approval for high-impact actions + +#### Some event photos + +![FCAJ Community Day group photo](/images/4-EventParticipated/event-5/1782566925005.jpg) + +![Deep Response Engine and agentic operations session](/images/4-EventParticipated/event-5/1782566950117.jpg) + +![Voice Agents session](/images/4-EventParticipated/event-5/1782566951589.jpg) + +![AWS DevOps Agent session](/images/4-EventParticipated/event-5/1782566953748.jpg) + +![AI-powered workforce planning with Amazon Quick](/images/4-EventParticipated/event-5/1782566951571.jpg) + +![Secure private MCP connection with Amazon Quick](/images/4-EventParticipated/event-5/1782566953984.jpg) + +> Overall, **FCAJ Community Day** showed that useful enterprise AI is not only about model capability. It also depends on reliable architecture, operational context, security boundaries, and thoughtful control over when an AI system may recommend or take action. diff --git a/content/4-EventParticipated/4.5-Event5/_index.vi.md b/content/4-EventParticipated/4.5-Event5/_index.vi.md new file mode 100644 index 0000000..8a6668f --- /dev/null +++ b/content/4-EventParticipated/4.5-Event5/_index.vi.md @@ -0,0 +1,136 @@ +--- +title: "FCAJ Community Day" +date: 2024-01-01 +weight: 5 +chapter: false +pre: " 4.5. " +--- + +# Bài thu hoạch “FCAJ Community Day” + +### Mục đích của sự kiện + +- Giới thiệu các giải pháp AI thực tế cho vận hành cloud, ứng phó sự cố, hội thoại với khách hàng và hoạch định nhân sự trong doanh nghiệp +- Cho thấy cách các dịch vụ AWS và hệ thống agentic chuyển hoạt động vận hành từ phát hiện vấn đề sang đề xuất hoặc thực hiện hành động xử lý +- Chia sẻ kiến trúc và demo liên quan đến Amazon Nova Sonic, AWS DevOps Agent, Amazon Bedrock AgentCore, Amazon Quick và Model Context Protocol (MCP) +- Phân tích các yêu cầu về bảo mật và kết nối khi đưa dữ liệu doanh nghiệp cùng các công cụ nội bộ vào workflow có AI hỗ trợ + +### Lịch trình sự kiện + +| Thời gian | Nội dung | Diễn giả | +|---|---|---| +| 08:30 – 09:00 | Check-in và ổn định chỗ ngồi | Đội ngũ tổ chức | +| 09:00 – 09:25 | Deep Response Engine: From Detection to Autonomous Resolution | Nhat Tran | +| 09:25 – 09:55 | Voice Agents: Building Human-Like AI Conversations at Scale | Trung Vu, Kiet Tran, Nghị Danh Hoàng Hiếu | +| 09:55 – 10:20 | AWS DevOps Agent: Your Always-Available Operations Teammate | Bao Phan Kim, Minh Nguyen Nguyen | +| 10:20 – 10:45 | AI-Powered Productivity: Workforce Planning for Enterprise | Trường Trần, Minh Anh Đặng Cao | +| 10:45 – 11:30 | Building Secure Private MCP Connection with Amazon Quick | Đức Toàn Nguyễn, Nghị Danh Hoàng Hiếu | + +### Nội dung nổi bật + +#### Deep Response Engine: Từ phát hiện đến tự động xử lý + +**Diễn giả:** Nhat Tran + +- Phân tích “complexity wall” mà đội vận hành cloud gặp phải khi hạ tầng và quan hệ phụ thuộc giữa các dịch vụ ngày càng phức tạp +- So sánh cách vận hành dựa trên cảnh báo, trong đó kỹ sư phải tự điều tra từng tín hiệu, với hệ thống hướng đến hành động có khả năng thu thập context và đề xuất hoặc thực hiện phương án xử lý +- Trình bày tổng quan kiến trúc Deep Response Engine và demo quy trình tự động ứng phó sự cố +- Liên hệ cải tiến kỹ thuật với hiệu quả kinh doanh như giảm chi phí vận hành và hạn chế downtime + +#### Voice Agents: Xây dựng hội thoại AI tự nhiên ở quy mô lớn + +**Diễn giả:** Trung Vu, Kiet Tran và Nghị Danh Hoàng Hiếu + +- Đi từ hệ thống IVR và chatbot truyền thống đến AI voice agent có khả năng hội thoại theo thời gian thực +- Phân tích các thách thức chính gồm độ trễ đầu cuối, độ chính xác, khả năng tương tác tự nhiên và xác định thời điểm người dùng đã nói xong +- Giới thiệu **Amazon Nova Sonic** — foundation model speech-to-speech dành cho hội thoại thời gian thực +- Trình bày kiến trúc kết hợp telephony, streaming hai chiều, Amazon Bedrock và các công cụ kết nối qua MCP +- Chia sẻ use case doanh nghiệp, best practices và demo cách xây dựng voice agent ở quy mô lớn + +#### AWS DevOps Agent: Đồng đội vận hành luôn sẵn sàng + +**Diễn giả:** Bao Phan Kim và Minh Nguyen Nguyen + +- Giới thiệu **AWS DevOps Agent** và vai trò hỗ trợ điều tra, xử lý trong toàn bộ vòng đời sự cố +- Cho thấy AI trong vận hành có thể góp phần giảm Mean Time to Detect (MTTD) và Mean Time to Resolve (MTTR) +- Mở rộng context vận hành ra môi trường multi-cloud và hybrid thay vì giới hạn trong một nền tảng duy nhất +- Giải thích cách **Amazon Bedrock AgentCore** và multi-agent reasoning kết hợp telemetry, kiến thức vận hành và hành động được đề xuất +- Minh họa qua demo điều tra sự cố thực tế trên Amazon ECS + +#### Hoạch định nhân sự với Amazon Quick + +**Diễn giả:** Trường Trần và Minh Anh Đặng Cao + +- Đặt vấn đề từ các khó khăn phổ biến của HR như sàng lọc CV thủ công, thiếu khả năng quan sát talent pipeline và ra quyết định khi dữ liệu chưa đầy đủ +- Giới thiệu các khả năng của **Amazon Quick Suite**, gồm chat agents, research, QuickSight, flows và automation +- Demo cách automation rút ngắn các quy trình HR lặp lại và giúp workforce analytics dễ tiếp cận hơn +- Kết nối dữ liệu vận hành nhân sự với hoạch định nguồn lực và ra quyết định chiến lược trong doanh nghiệp + +#### Kết nối MCP riêng tư, an toàn với Amazon Quick + +**Diễn giả:** Đức Toàn Nguyễn và Nghị Danh Hoàng Hiếu + +- Giải thích cách MCP mở rộng AI assistant bằng việc kết nối với công cụ và context bên ngoài +- Chỉ ra rủi ro khi MCP server phải sử dụng public endpoint: tăng attack surface, dữ liệu nhạy cảm đi qua internet và các vấn đề về data residency hoặc zero trust +- Trình bày private VPC connectivity như một pattern an toàn hơn khi kết nối Amazon Quick với dịch vụ MCP nội bộ +- Kết hợp giải thích kiến trúc, demo và kinh nghiệm triển khai thực tế + +### Những gì học được + +- Vận hành hiện đại không nên chỉ tạo thêm cảnh báo mà cần xây dựng đường đi đáng tin cậy từ phát hiện, điều tra đến hành động +- Tự động remediation chỉ thực sự hữu ích khi hệ thống có đủ context, quyền hạn được giới hạn, khả năng quan sát và phương án fallback an toàn +- Voice AI thời gian thực vừa là bài toán streaming system, vừa là bài toán mô hình; độ trễ và turn-taking tác động trực tiếp đến trải nghiệm người dùng +- AI agent trong vận hành có thể giảm MTTD và MTTR bằng cách liên kết telemetry với kiến thức vận hành, nhưng kỹ sư vẫn phải kiểm chứng các hành động có ảnh hưởng lớn +- Ứng dụng AI trong doanh nghiệp cần private connectivity, least-privilege access, khả năng audit các tool call và kiểm soát rõ ràng đối với dữ liệu nhạy cảm +- Amazon Quick có thể hỗ trợ knowledge work và workforce planning khi được kết nối với nguồn dữ liệu nội bộ đáng tin cậy + +### Ứng dụng vào công việc + +- Thiết kế workflow xử lý sự cố theo các bước rõ ràng: phát hiện, thu thập context, chẩn đoán, đề xuất, phê duyệt, thực thi và post-incident review +- Giữ bước phê duyệt của con người đối với remediation có rủi ro cao; chỉ tự động hóa các hành động ít rủi ro và có thể lặp lại +- Đo hiệu quả vận hành bằng MTTD, MTTR, tỷ lệ tái diễn và tỷ lệ sự cố được xử lý mà không phải escalation +- Khi thử nghiệm voice agent, kiểm tra interruption handling, turn detection, độ trễ phản hồi và khả năng phục hồi khi lỗi thay vì chỉ đánh giá chất lượng câu trả lời +- Ưu tiên đặt MCP service trong private network và áp dụng IAM, network boundary, logging cùng quyền truy cập tool theo nguyên tắc tối thiểu +- Sử dụng nguồn dữ liệu đáng tin cậy và kiểm soát truy cập rõ ràng khi dùng Amazon Quick cho báo cáo nội bộ hoặc phân tích nhân sự + +### Trải nghiệm trong event + +Tham gia **FCAJ Community Day** giúp em có một góc nhìn liền mạch hơn về cách agentic AI đang chuyển từ giai đoạn thử nghiệm sang các workflow vận hành và doanh nghiệp thực tế. Thay vì xem AI như một chatbot đứng độc lập, các phiên chia sẻ cho thấy AI có thể làm việc cùng telemetry, dịch vụ cloud, luồng âm thanh, dữ liệu nội bộ và các công cụ riêng tư. + +#### Từ tín hiệu cloud đến hành động vận hành + +- Hai phiên Deep Response Engine và AWS DevOps Agent giúp em hình dung cụ thể vòng đời sự cố: phát hiện tín hiệu, thu thập context, suy luận nguyên nhân và đề xuất hoặc thực hiện phương án xử lý an toàn. +- Demo trên Amazon ECS kết nối phần kiến trúc với một tình huống mà kỹ sư cloud có thể gặp trong hệ thống thực tế. + +#### Hiểu voice AI như một hệ thống hoàn chỉnh + +- Phiên Voice Agents cho thấy hội thoại tự nhiên phụ thuộc vào nhiều yếu tố hơn việc chuyển giọng nói thành văn bản. +- Phần phân tích độ trễ, khả năng ngắt lời và turn-taking giúp em hiểu rõ vì sao streaming architecture và thiết kế trải nghiệm người dùng là hai phần thiết yếu của ứng dụng voice AI. + +#### Kết nối AI với dữ liệu doanh nghiệp một cách an toàn + +- Hai phiên Amazon Quick mở rộng câu chuyện từ vận hành kỹ thuật sang hoạch định nhân sự và năng suất doanh nghiệp. +- Nội dung về private MCP connectivity đặc biệt thực tế vì đi thẳng vào ranh giới bảo mật giữa AI assistant và hệ thống nội bộ chứa dữ liệu nhạy cảm. + +#### Những gì em mang về + +- Mô hình tư duy rõ ràng hơn về agentic operations và autonomous incident response +- Các tiêu chí thực tế để đánh giá kiến trúc voice agent thời gian thực +- Hiểu sâu hơn vai trò của MCP connectivity, VPC design và access control trong việc triển khai AI doanh nghiệp an toàn +- Những ý tưởng có thể áp dụng vào kiến trúc cloud và dự án DocuFlow AI, đặc biệt ở phần tích hợp công cụ bên ngoài an toàn và duy trì phê duyệt của con người cho hành động có ảnh hưởng lớn + +#### Một số hình ảnh khi tham gia sự kiện + +![Ảnh tập thể FCAJ Community Day](/images/4-EventParticipated/event-5/1782566925005.jpg) + +![Phiên Deep Response Engine và agentic operations](/images/4-EventParticipated/event-5/1782566950117.jpg) + +![Phiên Voice Agents](/images/4-EventParticipated/event-5/1782566951589.jpg) + +![Phiên AWS DevOps Agent](/images/4-EventParticipated/event-5/1782566953748.jpg) + +![Hoạch định nhân sự với Amazon Quick](/images/4-EventParticipated/event-5/1782566951571.jpg) + +![Kết nối MCP riêng tư với Amazon Quick](/images/4-EventParticipated/event-5/1782566953984.jpg) + +> Tổng thể, **FCAJ Community Day** cho em thấy AI hữu ích trong doanh nghiệp không chỉ phụ thuộc vào khả năng của mô hình. Một giải pháp tốt còn cần kiến trúc đáng tin cậy, context vận hành đầy đủ, ranh giới bảo mật rõ ràng và cơ chế kiểm soát phù hợp đối với thời điểm AI được đề xuất hoặc thực hiện hành động. diff --git a/content/4-EventParticipated/_index.md b/content/4-EventParticipated/_index.md index 0a1dc55..c84f1f9 100644 --- a/content/4-EventParticipated/_index.md +++ b/content/4-EventParticipated/_index.md @@ -21,10 +21,10 @@ pre: " 4. " > * Outcomes or value gained (lessons learned, new skills, contribution to the team/project) > * This listing helps demonstrate your actual participation as well as the soft skills and experience you have gained from each event.--> -During my internship, I participated in two events. Each one was a memorable experience that provided new, interesting, and useful knowledge, along with gifts and wonderful moments. +During my internship, I participated in five events. Each one was a memorable experience that provided new, interesting, and useful knowledge, along with gifts and wonderful moments. ### [Event 1](4.1-Event1/) - **Event Name:** Community Day FCAJ HCM + **Event Name:** FCAJ Community Day  **Date & Time:** 09:00, May 09, 2026 @@ -42,3 +42,36 @@ During my internship, I participated in two events. Each one was a memorable exp  **Location:** 26th Floor, Bitexco Tower, 02 Hai Trieu Street, Saigon Ward, Ho Chi Minh City  **Role:** Attendee + +--- + +### [Event 3](4.3-Event3/) + **Event Name:** Agentic Build Day and Community Activity + + **Date & Time:** 13:00, May 29, 2026 + + **Location:** AWS Event Hall, 26th Floor, Bitexco Tower, 02 Hai Trieu Street, Saigon Ward, Ho Chi Minh City + + **Role:** Attendee + +--- + +### [Event 4](4.4-Event4/) + **Event Name:** Amazon Quick & Kiro Fiesta #2 + + **Date & Time:** 09:00, June 19, 2026 + + **Location:** AWS Vietnam Office, Ho Chi Minh City + + **Role:** Attendee + +--- + +### [Event 5](4.5-Event5/) + **Event Name:** FCAJ Community Day + + **Date & Time:** 09:00, June 27, 2026 + + **Location:** Bitexco Financial Tower, 02 Hai Trieu Street, Saigon Ward, Ho Chi Minh City + + **Role:** Attendee diff --git a/content/4-EventParticipated/_index.vi.md b/content/4-EventParticipated/_index.vi.md index 943aa1c..7d15e71 100644 --- a/content/4-EventParticipated/_index.vi.md +++ b/content/4-EventParticipated/_index.vi.md @@ -22,10 +22,10 @@ pre: " 4. " > * Việc liệt kê này giúp thể hiện rõ sự tham gia thực tế của bạn, cũng như các kỹ năng mềm và kinh nghiệm bạn đã tích lũy qua từng sự kiện.--> -Trong quá trình thực tập, em đã tham gia 2 events, với mỗi event là một trải nghiệm đáng nhớ với những kiến thức mới, hay và bổ ích, cùng với đó là nhứng món quà và những khoảnh khắc rất tuyệt vời. +Trong quá trình thực tập, em đã tham gia 5 events. Mỗi event là một trải nghiệm đáng nhớ, mang đến những kiến thức mới, bổ ích, cùng những món quà và khoảnh khắc rất tuyệt vời. ### [Event 1](4.1-Event1/) - **Tên sự kiện:** Community Day FCAJ HCM + **Tên sự kiện:** FCAJ Community Day  **Thời gian:** 09:00 ngày 09/05/2026 @@ -44,3 +44,36 @@ Trong quá trình thực tập, em đã tham gia 2 events, với mỗi event là  **Vai trò trong sự kiện:** Người tham dự + + +### [Event 3](4.3-Event3/) + **Tên sự kiện:** Agentic Build Day and Community Activity + + **Thời gian:** 13:00 ngày 29/05/2026 + + **Địa điểm:** AWS Event Hall, Tầng 26, tòa nhà Bitexco, số 02 đường Hải Triều, phường Sài Gòn, thành phố Hồ Chí Minh + + **Vai trò trong sự kiện:** Người tham dự + + + +### [Event 4](4.4-Event4/) + **Tên sự kiện:** Amazon Quick & Kiro Fiesta #2 + + **Thời gian:** 09:00 ngày 19/06/2026 + + **Địa điểm:** Văn phòng AWS Vietnam, thành phố Hồ Chí Minh + + **Vai trò trong sự kiện:** Người tham dự + + + +### [Event 5](4.5-Event5/) + **Tên sự kiện:** FCAJ Community Day + + **Thời gian:** 09:00 ngày 27/06/2026 + + **Địa điểm:** Tòa nhà Bitexco Financial Tower, số 02 đường Hải Triều, phường Sài Gòn, thành phố Hồ Chí Minh + + **Vai trò trong sự kiện:** Người tham dự + diff --git a/content/5-Workshop/5.1-Workshop-overview/_index.md b/content/5-Workshop/5.1-Workshop-overview/_index.md index 3ff6950..07176a2 100644 --- a/content/5-Workshop/5.1-Workshop-overview/_index.md +++ b/content/5-Workshop/5.1-Workshop-overview/_index.md @@ -1,18 +1,63 @@ --- -title : "Introduction" -date : 2024-01-01 -weight : 1 -chapter : false -pre : " 5.1. " +title: "Workshop Overview" +date: 2026-04-20 +weight: 1 +chapter: false +pre: " 5.1. " --- -#### VPC endpoints -+ **VPC endpoints** are virtual devices. They are horizontally scaled, redundant, and highly available VPC components. They allow communication between your compute resources and AWS services without imposing availability risks. -+ Compute resources running in VPC can access **Amazon S3** using a Gateway endpoint. PrivateLink interface endpoints can be used by compute resources running in VPC or on-premises. +#### What You Will Build -#### Workshop overview -In this workshop, you will use two VPCs. -+ **"VPC Cloud"** is for cloud resources such as a **Gateway endpoint** and an EC2 instance to test with. -+ **"VPC On-Prem"** simulates an on-premises environment such as a factory or corporate datacenter. An EC2 instance running strongSwan VPN software has been deployed in "VPC On-prem" and automatically configured to establish a Site-to-Site VPN tunnel with AWS Transit Gateway. This VPN simulates connectivity from an on-premises location to the AWS cloud. To minimize costs, only one VPN instance is provisioned to support this workshop. When planning VPN connectivity for your production workloads, AWS recommends using multiple VPN devices for high availability. +In this workshop you build **DocuFlow AI**, a serverless platform that turns uploaded invoices and receipts into structured, searchable data with minimal manual work. An authenticated user uploads a PDF, JPG, or PNG; the platform extracts vendor, date, tax, totals, and line items; and the result is stored, tracked by status, and shown in a web dashboard with a manual review path for low-confidence documents. -![overview](/images/5-Workshop/5.1-Workshop-overview/diagram1.png) \ No newline at end of file +The system is fully serverless and event-driven. There are no servers to manage, you pay only for what you process, and the whole platform is defined as a single AWS SAM stack deployed in `ap-southeast-1` (Singapore). + +#### Architecture + +![DocuFlow AI high-level serverless architecture](/images/2-Proposal/docuflow_high_level_architecture.png) + +The platform is organized into layers: + +- **Identity & Frontend** - Amazon Cognito authenticates users; a React single-page app is delivered through Amazon CloudFront and deployed with AWS Amplify Hosting. +- **API & Compute** - Amazon API Gateway exposes REST endpoints backed by AWS Lambda functions. +- **Storage** - Amazon S3 holds raw uploads and processed output; Amazon DynamoDB stores document metadata and status. +- **Ingestion & Workflow** - Amazon EventBridge and Amazon SQS decouple upload from processing; AWS Step Functions orchestrates the pipeline. +- **AI Extraction** - Amazon Textract reads the document; an AI Proxy Lambda calls an External AI API to normalize the output into a consistent JSON schema. +- **Observability & Notification** - Amazon CloudWatch and AWS X-Ray provide logs, metrics, alarms, and traces; Amazon SNS triggers Amazon SES email notifications. + +#### End-to-end Flow + +A single document moves through the platform as follows: + +1. The user signs in with Cognito and requests an upload slot. +2. A Lambda returns a short-lived S3 presigned URL and writes an initial DynamoDB item with status `UPLOADED`. +3. The browser uploads the file directly to S3; no document bytes pass through the API. +4. S3 emits an event to EventBridge, which routes it through SQS; status moves to `QUEUED`. +5. Job Starter Lambda starts a Step Functions execution; the workflow validates input, calls Textract, then calls the AI Proxy Lambda for External AI normalization. +6. Confidence + Status Lambda saves metadata to DynamoDB and processed JSON to S3 with status `EXTRACTED`, `REVIEW_REQUIRED`, or `FAILED`. +7. On low confidence or failure, SNS and SES notify reviewers, who can correct fields and move the status to `CORRECTED` or `APPROVED`. + +#### Workshop Modules + +You build the platform incrementally. Each module adds resources to the same SAM stack. + +| Module | Focus | Key services added | +|---|---|---| +| 5.1 | Overview (this page) | — | +| 5.2 | Prerequisites | Tooling, AWS profile, region, budget guardrails | +| 5.3 | Frontend, Auth, Upload | CloudFront, Amplify Hosting, Cognito, API Gateway, presign Lambda | +| 5.4 | Storage, Ingestion, Workflow | S3 buckets, EventBridge, SQS + DLQ, Step Functions | +| 5.5 | AI Extraction | Textract, AI Proxy Lambda, External AI API, confidence/status Lambda | +| 5.6 | Data, Result, Review | DynamoDB, API Gateway, review Lambdas | +| 5.7 | Observability & Security | CloudWatch, X-Ray, SNS/SES, IAM, KMS, Secrets Manager, CloudTrail, Budgets | +| 5.8 | Cleanup | Stack teardown and verification | + +#### Who This Is For + +This workshop suits a five-person team, where each member can own one or two modules. It assumes basic familiarity with the AWS console, the command line, and JavaScript or TypeScript. Deep prior experience with serverless services is not required, each module explains the services it introduces. + +#### Cost and Time + +The workshop workload costs about **$3.50 - $8.00 per month** in `ap-southeast-1`, and far less on a new account where the AWS Free Tier covers most services. Plan roughly 10 to 12 weeks for a team building and documenting all modules end to end. Remember to run the cleanup in module 5.8 to avoid ongoing charges. + +When you are ready, continue to **5.2 Prerequisites** to set up your environment. diff --git a/content/5-Workshop/5.1-Workshop-overview/_index.vi.md b/content/5-Workshop/5.1-Workshop-overview/_index.vi.md index 573eb9f..d0634e1 100644 --- a/content/5-Workshop/5.1-Workshop-overview/_index.vi.md +++ b/content/5-Workshop/5.1-Workshop-overview/_index.vi.md @@ -1,19 +1,63 @@ --- -title : "Giới thiệu" -date : 2024-01-01 -weight : 1 -chapter : false -pre : " 5.1. " +title: "Tổng quan Workshop" +date: 2026-04-20 +weight: 1 +chapter: false +pre: " 5.1. " --- -#### Giới thiệu về VPC Endpoint +#### Bạn sẽ xây gì -+ Điểm cuối VPC (endpoint) là thiết bị ảo. Chúng là các thành phần VPC có thể mở rộng theo chiều ngang, dự phòng và có tính sẵn sàng cao. Chúng cho phép giao tiếp giữa tài nguyên điện toán của bạn và dịch vụ AWS mà không gây ra rủi ro về tính sẵn sàng. -+ Tài nguyên điện toán đang chạy trong VPC có thể truy cập Amazon S3 bằng cách sử dụng điểm cuối Gateway. Interface Endpoint PrivateLink có thể được sử dụng bởi tài nguyên chạy trong VPC hoặc tại TTDL. +Trong workshop này bạn xây dựng **DocuFlow AI**, một nền tảng serverless biến invoice và receipt được upload thành dữ liệu có cấu trúc, tìm kiếm được, với ít thao tác thủ công nhất. Người dùng đã đăng nhập upload file PDF, JPG hoặc PNG; nền tảng trích xuất vendor, date, tax, totals và line items; kết quả được lưu lại, theo dõi theo status và hiển thị trên dashboard web kèm đường review thủ công cho tài liệu confidence thấp. -#### Tổng quan về workshop -Trong workshop này, bạn sẽ sử dụng hai VPC. -+ **"VPC Cloud"** dành cho các tài nguyên cloud như Gateway endpoint và EC2 instance để kiểm tra. -+ **"VPC On-Prem"** mô phỏng môi trường truyền thống như nhà máy hoặc trung tâm dữ liệu của công ty. Một EC2 Instance chạy phần mềm StrongSwan VPN đã được triển khai trong "VPC On-prem" và được cấu hình tự động để thiết lập đường hầm VPN Site-to-Site với AWS Transit Gateway. VPN này mô phỏng kết nối từ một vị trí tại TTDL (on-prem) với AWS cloud. Để giảm thiểu chi phí, chỉ một phiên bản VPN được cung cấp để hỗ trợ workshop này. Khi lập kế hoạch kết nối VPN cho production workloads của bạn, AWS khuyên bạn nên sử dụng nhiều thiết bị VPN để có tính sẵn sàng cao. +Hệ thống hoàn toàn serverless và event-driven. Không có server phải quản lý, chỉ trả tiền cho phần xử lý thực tế, và toàn bộ nền tảng được định nghĩa bằng một AWS SAM stack duy nhất deploy ở `ap-southeast-1` (Singapore). -![overview](/images/5-Workshop/5.1-Workshop-overview/diagram1.png) +#### Kiến trúc + +![Kiến trúc high-level của DocuFlow AI](/images/2-Proposal/docuflow_high_level_architecture.png) + +Nền tảng được tổ chức theo các layer: + +- **Identity & Frontend** - Amazon Cognito xác thực người dùng; React single-page app được phân phối qua Amazon CloudFront và deploy bằng AWS Amplify Hosting. +- **API & Compute** - Amazon API Gateway cung cấp REST endpoint backed bởi các AWS Lambda function. +- **Storage** - Amazon S3 giữ raw uploads và processed output; Amazon DynamoDB lưu metadata và status của tài liệu. +- **Ingestion & Workflow** - Amazon EventBridge và Amazon SQS tách upload khỏi processing; AWS Step Functions điều phối pipeline. +- **AI Extraction** - Amazon Textract đọc tài liệu; AI Proxy Lambda gọi External AI API để chuẩn hóa output về một JSON schema thống nhất. +- **Observability & Notification** - Amazon CloudWatch và AWS X-Ray cung cấp logs, metrics, alarms và traces; Amazon SNS kích hoạt Amazon SES email notifications. + +#### Luồng xử lý end-to-end + +Một tài liệu đi qua nền tảng như sau: + +1. Người dùng đăng nhập bằng Cognito và xin một upload slot. +2. Một Lambda trả S3 presigned URL ngắn hạn và ghi DynamoDB item ban đầu với status `UPLOADED`. +3. Browser upload file trực tiếp lên S3; document bytes không đi qua API. +4. S3 phát event sang EventBridge, route qua SQS; status chuyển sang `QUEUED`. +5. Job Starter Lambda start một Step Functions execution; workflow validate input, gọi Textract, rồi gọi AI Proxy Lambda để normalize bằng External AI API. +6. Confidence + Status Lambda lưu metadata vào DynamoDB và processed JSON vào S3 với status `EXTRACTED`, `REVIEW_REQUIRED` hoặc `FAILED`. +7. Khi confidence thấp hoặc lỗi, SNS và SES thông báo reviewer, người này có thể sửa field và chuyển status sang `CORRECTED` hoặc `APPROVED`. + +#### Các module Workshop + +Bạn xây nền tảng theo từng bước. Mỗi module thêm resource vào cùng một SAM stack. + +| Module | Trọng tâm | Dịch vụ chính được thêm | +|---|---|---| +| 5.1 | Tổng quan (trang này) | — | +| 5.2 | Chuẩn bị | Tooling, AWS profile, region, budget guardrails | +| 5.3 | Frontend, Auth, Upload | CloudFront, Amplify Hosting, Cognito, API Gateway, presign Lambda | +| 5.4 | Storage, Ingestion, Workflow | S3 buckets, EventBridge, SQS + DLQ, Step Functions | +| 5.5 | AI Extraction | Textract, AI Proxy Lambda, External AI API, confidence/status Lambda | +| 5.6 | Data, Result, Review | DynamoDB, API Gateway, review Lambdas | +| 5.7 | Observability & Security | CloudWatch, X-Ray, SNS/SES, IAM, KMS, Secrets Manager, CloudTrail, Budgets | +| 5.8 | Cleanup | Teardown stack và kiểm tra | + +#### Workshop dành cho ai + +Workshop phù hợp cho nhóm 5 người, mỗi người có thể phụ trách một hoặc hai module. Yêu cầu quen cơ bản với AWS console, command line và JavaScript hoặc TypeScript. Không cần kinh nghiệm sâu trước về dịch vụ serverless, mỗi module đều giải thích các dịch vụ mà nó giới thiệu. + +#### Chi phí và thời gian + +Workload workshop tốn khoảng **$3.50 - $8.00 mỗi tháng** ở `ap-southeast-1`, và ít hơn nhiều trên tài khoản mới nơi AWS Free Tier bao phủ hầu hết dịch vụ. Dự kiến khoảng 10 đến 12 tuần cho một nhóm xây và document toàn bộ module end-to-end. Nhớ chạy cleanup ở module 5.8 để tránh phát sinh chi phí. + +Khi đã sẵn sàng, tiếp tục sang **5.2 Chuẩn bị** để thiết lập môi trường. diff --git a/content/5-Workshop/5.2-Prerequisite/_index.md b/content/5-Workshop/5.2-Prerequisite/_index.md new file mode 100644 index 0000000..9e7e4ff --- /dev/null +++ b/content/5-Workshop/5.2-Prerequisite/_index.md @@ -0,0 +1,162 @@ +--- +title: "Prerequisites" +date: 2026-04-20 +weight: 2 +chapter: false +pre: " 5.2. " +--- + +#### Overview + +This module prepares your local machine and AWS account to build and deploy DocuFlow AI. By the end you will have the required tools installed, an AWS profile configured for `ap-southeast-1`, Amazon Bedrock model access enabled, and a validated AWS SAM template. + +You only need to do this setup once. Every later module assumes these prerequisites are in place. + +#### Required Tools + +Install the following on your workstation. Versions are minimums; newer patch releases are fine. + +| Tool | Version | Purpose | +|---|---|---| +| Node.js | 20.x LTS | Runtime for frontend build and Lambda functions | +| pnpm | 9.x | Monorepo package manager | +| Git | 2.40+ | Version control | +| AWS CLI | v2 (latest) | Authenticate and call AWS APIs | +| AWS SAM CLI | latest 1.x | Build, validate, and deploy the serverless stack | +| Docker | 24+ (optional) | Only for `sam local` emulation and `sam build --use-container` | + +Verify each tool: + +```bash +node --version # v20.x +pnpm --version # 9.x +git --version # 2.40+ +aws --version # aws-cli/2.x +sam --version # SAM CLI, version 1.x +docker --version # optional: Docker version 24+ +``` + +{{% notice tip %}} +If `pnpm` is not installed, enable it through Corepack which ships with Node.js 20: `corepack enable && corepack prepare pnpm@9 --activate`. +{{% /notice %}} + +{{% notice info %}} +Docker is **not** required for normal development. Our Lambda functions are TypeScript bundled with esbuild, so `sam build` runs natively without containers. Install Docker only if you want to emulate Lambda locally with `sam local invoke` or `sam local start-api`. +{{% /notice %}} + +#### Step 1 - Configure AWS Access + +DocuFlow AI deploys to **`ap-southeast-1` (Singapore)**, the closest region to Vietnam. DocuFlow AI treats long-lived access keys as a security risk (see proposal risks R-06 and R-08), so the recommended way to authenticate is **AWS IAM Identity Center** (short-lived credentials that refresh automatically and never sit on disk). + +**Option A - IAM Identity Center (recommended)** + +```bash +aws configure sso --profile docuflow +``` + +Follow the prompts to enter your SSO start URL and region, then select the account and permission set. Set the CLI default region to `ap-southeast-1` and output to `json`. Sign in whenever the session expires: + +```bash +aws sso login --profile docuflow +``` + +**Option B - Access keys (only if Identity Center is unavailable)** + +If your account cannot use Identity Center, fall back to a temporary access key and delete it after the workshop: + +```bash +aws configure --profile docuflow +# Default region name: ap-southeast-1 +# Default output format: json +``` + +Confirm the identity and region with either option: + +```bash +aws sts get-caller-identity --profile docuflow +aws configure get region --profile docuflow # ap-southeast-1 +``` + +{{% notice warning %}} +Never commit credentials to Git. The repository ships with a `gitleaks` pre-commit hook (see module 5.7) and a `.gitignore` that excludes `.env` files. For CI/CD, this workshop uses GitHub OIDC instead of any stored keys. If you used Option B, delete the access key in the IAM console once the workshop is complete. +{{% /notice %}} + +#### Step 2 - IAM Permissions + +The account or role used for the workshop needs permission to create and delete the services in the DocuFlow architecture. For a personal workshop account, an administrator-equivalent policy is the simplest option. For a shared or restricted account, attach a policy scoped to these services: + +```text +cloudformation, s3, cognito-idp, apigateway, lambda, states, +dynamodb, events, sqs, sns, textract, bedrock, cloudfront, +logs, cloudwatch, iam, kms, budgets, ssm +``` + +The single SAM stack provisions every resource, so the deploying principal also needs `iam:CreateRole`, `iam:PassRole`, and `cloudformation:*` on the stack. + +#### Step 3 - Enable Amazon Bedrock Model Access + +Bedrock models are opt-in per region. Enable access before running the AI extraction module (5.5). + +1. Open the **Amazon Bedrock** console in `ap-southeast-1`. +2. Go to **Model access** in the left navigation. +3. Choose **Manage model access** (or **Enable specific models**). +4. Enable **Amazon Nova Lite** (primary model) and **Anthropic Claude 3 Haiku** (fallback). +5. Submit and wait until status shows **Access granted**. + +Verify from the CLI that the models are listed: + +```bash +aws bedrock list-foundation-models \ + --profile docuflow \ + --region ap-southeast-1 \ + --query "modelSummaries[?contains(modelId, 'nova-lite') || contains(modelId, 'haiku')].modelId" +``` + +{{% notice info %}} +If Nova Lite is not yet generally available in `ap-southeast-1` at the time of the workshop, set the `BedrockRegion` parameter to `us-east-1`. The architecture isolates this behind a single environment variable (`BEDROCK_REGION`), as described in the proposal risk R-07. +{{% /notice %}} + +#### Step 4 - Clone the Repository + +```bash +git clone https://github.com//docuflow-ai.git +cd docuflow-ai +pnpm install +``` + +`pnpm install` reads `pnpm-workspace.yaml` and links the `apps/*`, `packages/*`, and `services/functions/*` workspaces. At this stage the workspaces are skeletons, so the install completes quickly with no application dependencies. + +#### Step 5 - Validate the SAM Template + +The repository ships with a baseline SAM template at `infrastructure/template.yaml`. Validate it before making any changes: + +```bash +sam validate --lint --template infrastructure/template.yaml --region ap-southeast-1 +``` + +Expected output: + +```text +infrastructure/template.yaml is a valid SAM Template +``` + +This confirms your AWS CLI credentials, region, and SAM CLI installation all work together. + +#### Step 6 - (Optional) GitHub OIDC for CI/CD + +To let GitHub Actions deploy without storing AWS keys, create an IAM OIDC identity provider for `token.actions.githubusercontent.com` and a role that trusts your repository. This is optional for local development but required for the `deploy-dev` and `deploy-prod` pipelines in module 5.7. + +You will configure this in detail during the observability and security module. For now, note that the CI workflow at `.github/workflows/ci.yml` only runs lint, typecheck, test, and `sam validate` — none of which need AWS credentials. + +#### Checklist + +Before moving to module 5.3, confirm: + +- [ ] Node 20, pnpm 9, Git, AWS CLI v2, and SAM CLI are installed (Docker optional). +- [ ] `aws sts get-caller-identity --profile docuflow` returns your account (via SSO or access key). +- [ ] Default region for the profile is `ap-southeast-1`. +- [ ] Bedrock model access granted for Nova Lite and Claude 3 Haiku. +- [ ] Repository cloned and `pnpm install` completed. +- [ ] `sam validate --lint` reports a valid template. + +With these in place, continue to **5.3 Frontend, Auth, and Upload**. diff --git a/content/5-Workshop/5.2-Prerequisite/_index.vi.md b/content/5-Workshop/5.2-Prerequisite/_index.vi.md new file mode 100644 index 0000000..e5fce89 --- /dev/null +++ b/content/5-Workshop/5.2-Prerequisite/_index.vi.md @@ -0,0 +1,162 @@ +--- +title: "Chuẩn bị" +date: 2026-04-20 +weight: 2 +chapter: false +pre: " 5.2. " +--- + +#### Tổng quan + +Module này chuẩn bị máy local và tài khoản AWS để build và deploy DocuFlow AI. Kết thúc module, bạn sẽ có đủ tool cần thiết, một AWS profile cấu hình cho `ap-southeast-1`, đã bật model access của Amazon Bedrock, và một SAM template đã validate. + +Phần setup này chỉ làm một lần. Mọi module sau đều giả định các bước này đã hoàn tất. + +#### Tool cần cài + +Cài các tool sau trên máy. Version là mức tối thiểu; bản patch mới hơn vẫn dùng được. + +| Tool | Version | Mục đích | +|---|---|---| +| Node.js | 20.x LTS | Runtime cho frontend build và Lambda functions | +| pnpm | 9.x | Package manager cho monorepo | +| Git | 2.40+ | Quản lý version | +| AWS CLI | v2 (mới nhất) | Xác thực và gọi AWS API | +| AWS SAM CLI | bản 1.x mới nhất | Build, validate và deploy serverless stack | +| Docker | 24+ (tùy chọn) | Chỉ cần cho `sam local` và `sam build --use-container` | + +Kiểm tra từng tool: + +```bash +node --version # v20.x +pnpm --version # 9.x +git --version # 2.40+ +aws --version # aws-cli/2.x +sam --version # SAM CLI, version 1.x +docker --version # tùy chọn: Docker version 24+ +``` + +{{% notice tip %}} +Nếu chưa có `pnpm`, bật qua Corepack đi kèm Node.js 20: `corepack enable && corepack prepare pnpm@9 --activate`. +{{% /notice %}} + +{{% notice info %}} +Docker **không** bắt buộc cho phát triển bình thường. Các Lambda function của chúng ta là TypeScript bundle bằng esbuild, nên `sam build` chạy native không cần container. Chỉ cài Docker nếu bạn muốn giả lập Lambda local bằng `sam local invoke` hoặc `sam local start-api`. +{{% /notice %}} + +#### Bước 1 - Cấu hình truy cập AWS + +DocuFlow AI deploy lên **`ap-southeast-1` (Singapore)**, region gần Việt Nam nhất. DocuFlow AI coi access key dài hạn là một rủi ro bảo mật (xem risk R-06 và R-08 trong proposal), nên cách xác thực được khuyến nghị là **AWS IAM Identity Center** (credential ngắn hạn, tự refresh và không nằm trên đĩa). + +**Phương án A - IAM Identity Center (khuyến nghị)** + +```bash +aws configure sso --profile docuflow +``` + +Làm theo hướng dẫn để nhập SSO start URL và region, sau đó chọn account và permission set. Đặt CLI default region là `ap-southeast-1` và output là `json`. Đăng nhập lại mỗi khi session hết hạn: + +```bash +aws sso login --profile docuflow +``` + +**Phương án B - Access key (chỉ khi không dùng được Identity Center)** + +Nếu account không dùng được Identity Center, dùng tạm access key và xoá sau khi xong workshop: + +```bash +aws configure --profile docuflow +# Default region name: ap-southeast-1 +# Default output format: json +``` + +Xác nhận identity và region với cả hai phương án: + +```bash +aws sts get-caller-identity --profile docuflow +aws configure get region --profile docuflow # ap-southeast-1 +``` + +{{% notice warning %}} +Không bao giờ commit credential vào Git. Repository đã có sẵn `gitleaks` pre-commit hook (xem module 5.7) và `.gitignore` loại trừ các file `.env`. Với CI/CD, workshop dùng GitHub OIDC thay cho mọi key lưu trữ. Nếu bạn dùng Phương án B, xoá access key trong IAM console khi workshop kết thúc. +{{% /notice %}} + +#### Bước 2 - Quyền IAM + +Tài khoản hoặc role dùng cho workshop cần quyền tạo và xoá các dịch vụ trong kiến trúc DocuFlow. Với tài khoản workshop cá nhân, policy tương đương administrator là đơn giản nhất. Với tài khoản dùng chung hoặc bị giới hạn, gắn policy scope theo các dịch vụ sau: + +```text +cloudformation, s3, cognito-idp, apigateway, lambda, states, +dynamodb, events, sqs, sns, textract, bedrock, cloudfront, +logs, cloudwatch, iam, kms, budgets, ssm +``` + +Vì một SAM stack provision toàn bộ resource, principal deploy cũng cần `iam:CreateRole`, `iam:PassRole` và `cloudformation:*` trên stack. + +#### Bước 3 - Bật Model Access của Amazon Bedrock + +Model Bedrock phải opt-in theo từng region. Bật access trước khi chạy module AI extraction (5.5). + +1. Mở console **Amazon Bedrock** ở `ap-southeast-1`. +2. Vào **Model access** ở thanh điều hướng bên trái. +3. Chọn **Manage model access** (hoặc **Enable specific models**). +4. Bật **Amazon Nova Lite** (model chính) và **Anthropic Claude 3 Haiku** (fallback). +5. Submit và chờ tới khi trạng thái hiển thị **Access granted**. + +Kiểm tra từ CLI rằng các model đã có: + +```bash +aws bedrock list-foundation-models \ + --profile docuflow \ + --region ap-southeast-1 \ + --query "modelSummaries[?contains(modelId, 'nova-lite') || contains(modelId, 'haiku')].modelId" +``` + +{{% notice info %}} +Nếu Nova Lite chưa GA ở `ap-southeast-1` tại thời điểm workshop, đặt parameter `BedrockRegion` thành `us-east-1`. Kiến trúc cô lập việc này sau một environment variable duy nhất (`BEDROCK_REGION`), như mô tả ở risk R-07 trong proposal. +{{% /notice %}} + +#### Bước 4 - Clone Repository + +```bash +git clone https://github.com//docuflow-ai.git +cd docuflow-ai +pnpm install +``` + +`pnpm install` đọc `pnpm-workspace.yaml` và link các workspace `apps/*`, `packages/*` và `services/functions/*`. Ở giai đoạn này các workspace mới là skeleton nên install hoàn tất nhanh, chưa có application dependency. + +#### Bước 5 - Validate SAM Template + +Repository đã có sẵn SAM template baseline tại `infrastructure/template.yaml`. Validate trước khi chỉnh sửa gì: + +```bash +sam validate --lint --template infrastructure/template.yaml --region ap-southeast-1 +``` + +Output mong đợi: + +```text +infrastructure/template.yaml is a valid SAM Template +``` + +Bước này xác nhận credential AWS CLI, region và bản cài SAM CLI hoạt động ăn khớp với nhau. + +#### Bước 6 - (Tùy chọn) GitHub OIDC cho CI/CD + +Để GitHub Actions deploy mà không lưu AWS key, tạo một IAM OIDC identity provider cho `token.actions.githubusercontent.com` và một role tin tưởng repository của bạn. Bước này không bắt buộc cho phát triển local nhưng cần cho pipeline `deploy-dev` và `deploy-prod` ở module 5.7. + +Bạn sẽ cấu hình chi tiết trong module observability và security. Hiện tại, lưu ý CI workflow ở `.github/workflows/ci.yml` chỉ chạy lint, typecheck, test và `sam validate` — đều không cần credential AWS. + +#### Checklist + +Trước khi sang module 5.3, xác nhận: + +- [ ] Đã cài Node 20, pnpm 9, Git, AWS CLI v2 và SAM CLI (Docker tùy chọn). +- [ ] `aws sts get-caller-identity --profile docuflow` trả về tài khoản của bạn (qua SSO hoặc access key). +- [ ] Region mặc định của profile là `ap-southeast-1`. +- [ ] Đã được cấp Bedrock model access cho Nova Lite và Claude 3 Haiku. +- [ ] Đã clone repository và `pnpm install` hoàn tất. +- [ ] `sam validate --lint` báo template hợp lệ. + +Khi đã đủ các mục trên, tiếp tục sang **5.3 Frontend, Auth và Upload**. diff --git a/content/5-Workshop/5.2-Prerequiste/_index.md b/content/5-Workshop/5.2-Prerequiste/_index.md deleted file mode 100644 index 71f0773..0000000 --- a/content/5-Workshop/5.2-Prerequiste/_index.md +++ /dev/null @@ -1,242 +0,0 @@ ---- -title : "Prerequiste" -date : 2024-01-01 -weight : 2 -chapter : false -pre : " 5.2. " ---- - -#### IAM permissions -Add the following IAM permission policy to your user account to deploy and cleanup this workshop. -``` -{ - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "VisualEditor0", - "Effect": "Allow", - "Action": [ - "cloudformation:*", - "cloudwatch:*", - "ec2:AcceptTransitGatewayPeeringAttachment", - "ec2:AcceptTransitGatewayVpcAttachment", - "ec2:AllocateAddress", - "ec2:AssociateAddress", - "ec2:AssociateIamInstanceProfile", - "ec2:AssociateRouteTable", - "ec2:AssociateSubnetCidrBlock", - "ec2:AssociateTransitGatewayRouteTable", - "ec2:AssociateVpcCidrBlock", - "ec2:AttachInternetGateway", - "ec2:AttachNetworkInterface", - "ec2:AttachVolume", - "ec2:AttachVpnGateway", - "ec2:AuthorizeSecurityGroupEgress", - "ec2:AuthorizeSecurityGroupIngress", - "ec2:CreateClientVpnEndpoint", - "ec2:CreateClientVpnRoute", - "ec2:CreateCustomerGateway", - "ec2:CreateDhcpOptions", - "ec2:CreateFlowLogs", - "ec2:CreateInternetGateway", - "ec2:CreateLaunchTemplate", - "ec2:CreateNetworkAcl", - "ec2:CreateNetworkInterface", - "ec2:CreateNetworkInterfacePermission", - "ec2:CreateRoute", - "ec2:CreateRouteTable", - "ec2:CreateSecurityGroup", - "ec2:CreateSubnet", - "ec2:CreateSubnetCidrReservation", - "ec2:CreateTags", - "ec2:CreateTransitGateway", - "ec2:CreateTransitGatewayPeeringAttachment", - "ec2:CreateTransitGatewayPrefixListReference", - "ec2:CreateTransitGatewayRoute", - "ec2:CreateTransitGatewayRouteTable", - "ec2:CreateTransitGatewayVpcAttachment", - "ec2:CreateVpc", - "ec2:CreateVpcEndpoint", - "ec2:CreateVpcEndpointConnectionNotification", - "ec2:CreateVpcEndpointServiceConfiguration", - "ec2:CreateVpnConnection", - "ec2:CreateVpnConnectionRoute", - "ec2:CreateVpnGateway", - "ec2:DeleteCustomerGateway", - "ec2:DeleteFlowLogs", - "ec2:DeleteInternetGateway", - "ec2:DeleteNetworkInterface", - "ec2:DeleteNetworkInterfacePermission", - "ec2:DeleteRoute", - "ec2:DeleteRouteTable", - "ec2:DeleteSecurityGroup", - "ec2:DeleteSubnet", - "ec2:DeleteSubnetCidrReservation", - "ec2:DeleteTags", - "ec2:DeleteTransitGateway", - "ec2:DeleteTransitGatewayPeeringAttachment", - "ec2:DeleteTransitGatewayPrefixListReference", - "ec2:DeleteTransitGatewayRoute", - "ec2:DeleteTransitGatewayRouteTable", - "ec2:DeleteTransitGatewayVpcAttachment", - "ec2:DeleteVpc", - "ec2:DeleteVpcEndpoints", - "ec2:DeleteVpcEndpointServiceConfigurations", - "ec2:DeleteVpnConnection", - "ec2:DeleteVpnConnectionRoute", - "ec2:Describe*", - "ec2:DetachInternetGateway", - "ec2:DisassociateAddress", - "ec2:DisassociateRouteTable", - "ec2:GetLaunchTemplateData", - "ec2:GetTransitGatewayAttachmentPropagations", - "ec2:ModifyInstanceAttribute", - "ec2:ModifySecurityGroupRules", - "ec2:ModifyTransitGatewayVpcAttachment", - "ec2:ModifyVpcAttribute", - "ec2:ModifyVpcEndpoint", - "ec2:ReleaseAddress", - "ec2:ReplaceRoute", - "ec2:RevokeSecurityGroupEgress", - "ec2:RevokeSecurityGroupIngress", - "ec2:RunInstances", - "ec2:StartInstances", - "ec2:StopInstances", - "ec2:UpdateSecurityGroupRuleDescriptionsEgress", - "ec2:UpdateSecurityGroupRuleDescriptionsIngress", - "iam:AddRoleToInstanceProfile", - "iam:AttachRolePolicy", - "iam:CreateInstanceProfile", - "iam:CreatePolicy", - "iam:CreateRole", - "iam:DeleteInstanceProfile", - "iam:DeletePolicy", - "iam:DeleteRole", - "iam:DeleteRolePolicy", - "iam:DetachRolePolicy", - "iam:GetInstanceProfile", - "iam:GetPolicy", - "iam:GetRole", - "iam:GetRolePolicy", - "iam:ListPolicyVersions", - "iam:ListRoles", - "iam:PassRole", - "iam:PutRolePolicy", - "iam:RemoveRoleFromInstanceProfile", - "lambda:CreateFunction", - "lambda:DeleteFunction", - "lambda:DeleteLayerVersion", - "lambda:GetFunction", - "lambda:GetLayerVersion", - "lambda:InvokeFunction", - "lambda:PublishLayerVersion", - "logs:CreateLogGroup", - "logs:DeleteLogGroup", - "logs:DescribeLogGroups", - "logs:PutRetentionPolicy", - "route53:ChangeTagsForResource", - "route53:CreateHealthCheck", - "route53:CreateHostedZone", - "route53:CreateTrafficPolicy", - "route53:DeleteHostedZone", - "route53:DisassociateVPCFromHostedZone", - "route53:GetHostedZone", - "route53:ListHostedZones", - "route53domains:ListDomains", - "route53domains:ListOperations", - "route53domains:ListTagsForDomain", - "route53resolver:AssociateResolverEndpointIpAddress", - "route53resolver:AssociateResolverRule", - "route53resolver:CreateResolverEndpoint", - "route53resolver:CreateResolverRule", - "route53resolver:DeleteResolverEndpoint", - "route53resolver:DeleteResolverRule", - "route53resolver:DisassociateResolverEndpointIpAddress", - "route53resolver:DisassociateResolverRule", - "route53resolver:GetResolverEndpoint", - "route53resolver:GetResolverRule", - "route53resolver:ListResolverEndpointIpAddresses", - "route53resolver:ListResolverEndpoints", - "route53resolver:ListResolverRuleAssociations", - "route53resolver:ListResolverRules", - "route53resolver:ListTagsForResource", - "route53resolver:UpdateResolverEndpoint", - "route53resolver:UpdateResolverRule", - "s3:AbortMultipartUpload", - "s3:CreateBucket", - "s3:DeleteBucket", - "s3:DeleteObject", - "s3:GetAccountPublicAccessBlock", - "s3:GetBucketAcl", - "s3:GetBucketOwnershipControls", - "s3:GetBucketPolicy", - "s3:GetBucketPolicyStatus", - "s3:GetBucketPublicAccessBlock", - "s3:GetObject", - "s3:GetObjectVersion", - "s3:GetBucketVersioning", - "s3:ListAccessPoints", - "s3:ListAccessPointsForObjectLambda", - "s3:ListAllMyBuckets", - "s3:ListBucket", - "s3:ListBucketMultipartUploads", - "s3:ListBucketVersions", - "s3:ListJobs", - "s3:ListMultipartUploadParts", - "s3:ListMultiRegionAccessPoints", - "s3:ListStorageLensConfigurations", - "s3:PutAccountPublicAccessBlock", - "s3:PutBucketAcl", - "s3:PutBucketPolicy", - "s3:PutBucketPublicAccessBlock", - "s3:PutObject", - "secretsmanager:CreateSecret", - "secretsmanager:DeleteSecret", - "secretsmanager:DescribeSecret", - "secretsmanager:GetSecretValue", - "secretsmanager:ListSecrets", - "secretsmanager:ListSecretVersionIds", - "secretsmanager:PutResourcePolicy", - "secretsmanager:TagResource", - "secretsmanager:UpdateSecret", - "sns:ListTopics", - "ssm:DescribeInstanceProperties", - "ssm:DescribeSessions", - "ssm:GetConnectionStatus", - "ssm:GetParameters", - "ssm:ListAssociations", - "ssm:ResumeSession", - "ssm:StartSession", - "ssm:TerminateSession" - ], - "Resource": "*" - } - ] -} - -``` - -#### Provision resources using CloudFormation - -In this lab, we will use **N.Virginia region (us-east-1)**. - -To prepare the workshop environment, deploy this **CloudFormation Template** (click link): [PrivateLinkWorkshop ](https://us-east-1.console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/quickcreate?templateURL=https://s3.us-east-1.amazonaws.com/reinvent-endpoints-builders-session/Nested.yaml&stackName=PLCloudSetup). Accept all of the defaults when deploying the template. - -![create stack](/images/5-Workshop/5.2-Prerequisite/create-stack1.png) - -+ Tick 2 acknowledgement boxes -+ Choose **Create stack** - -![create stack](/images/5-Workshop/5.2-Prerequisite/create-stack2.png) - -The **ClouddFormation** deployment requires about 15 minutes to complete. - -![complete](/images/5-Workshop/5.2-Prerequisite/complete.png) - -+ **2 VPCs** have been created - -![vpcs](/images/5-Workshop/5.2-Prerequisite/vpcs.png) - -+ **3 EC2s** have been created - -![EC2](/images/5-Workshop/5.2-Prerequisite/ec2.png) \ No newline at end of file diff --git a/content/5-Workshop/5.2-Prerequiste/_index.vi.md b/content/5-Workshop/5.2-Prerequiste/_index.vi.md deleted file mode 100644 index cba7d12..0000000 --- a/content/5-Workshop/5.2-Prerequiste/_index.vi.md +++ /dev/null @@ -1,242 +0,0 @@ ---- -title : "Các bước chuẩn bị" -date : 2024-01-01 -weight : 2 -chapter : false -pre : " 5.2. " ---- - -#### IAM permissions -Gắn IAM permission policy sau vào tài khoản aws user của bạn để triển khai và dọn dẹp tài nguyên trong workshop này. -``` -{ - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "VisualEditor0", - "Effect": "Allow", - "Action": [ - "cloudformation:*", - "cloudwatch:*", - "ec2:AcceptTransitGatewayPeeringAttachment", - "ec2:AcceptTransitGatewayVpcAttachment", - "ec2:AllocateAddress", - "ec2:AssociateAddress", - "ec2:AssociateIamInstanceProfile", - "ec2:AssociateRouteTable", - "ec2:AssociateSubnetCidrBlock", - "ec2:AssociateTransitGatewayRouteTable", - "ec2:AssociateVpcCidrBlock", - "ec2:AttachInternetGateway", - "ec2:AttachNetworkInterface", - "ec2:AttachVolume", - "ec2:AttachVpnGateway", - "ec2:AuthorizeSecurityGroupEgress", - "ec2:AuthorizeSecurityGroupIngress", - "ec2:CreateClientVpnEndpoint", - "ec2:CreateClientVpnRoute", - "ec2:CreateCustomerGateway", - "ec2:CreateDhcpOptions", - "ec2:CreateFlowLogs", - "ec2:CreateInternetGateway", - "ec2:CreateLaunchTemplate", - "ec2:CreateNetworkAcl", - "ec2:CreateNetworkInterface", - "ec2:CreateNetworkInterfacePermission", - "ec2:CreateRoute", - "ec2:CreateRouteTable", - "ec2:CreateSecurityGroup", - "ec2:CreateSubnet", - "ec2:CreateSubnetCidrReservation", - "ec2:CreateTags", - "ec2:CreateTransitGateway", - "ec2:CreateTransitGatewayPeeringAttachment", - "ec2:CreateTransitGatewayPrefixListReference", - "ec2:CreateTransitGatewayRoute", - "ec2:CreateTransitGatewayRouteTable", - "ec2:CreateTransitGatewayVpcAttachment", - "ec2:CreateVpc", - "ec2:CreateVpcEndpoint", - "ec2:CreateVpcEndpointConnectionNotification", - "ec2:CreateVpcEndpointServiceConfiguration", - "ec2:CreateVpnConnection", - "ec2:CreateVpnConnectionRoute", - "ec2:CreateVpnGateway", - "ec2:DeleteCustomerGateway", - "ec2:DeleteFlowLogs", - "ec2:DeleteInternetGateway", - "ec2:DeleteNetworkInterface", - "ec2:DeleteNetworkInterfacePermission", - "ec2:DeleteRoute", - "ec2:DeleteRouteTable", - "ec2:DeleteSecurityGroup", - "ec2:DeleteSubnet", - "ec2:DeleteSubnetCidrReservation", - "ec2:DeleteTags", - "ec2:DeleteTransitGateway", - "ec2:DeleteTransitGatewayPeeringAttachment", - "ec2:DeleteTransitGatewayPrefixListReference", - "ec2:DeleteTransitGatewayRoute", - "ec2:DeleteTransitGatewayRouteTable", - "ec2:DeleteTransitGatewayVpcAttachment", - "ec2:DeleteVpc", - "ec2:DeleteVpcEndpoints", - "ec2:DeleteVpcEndpointServiceConfigurations", - "ec2:DeleteVpnConnection", - "ec2:DeleteVpnConnectionRoute", - "ec2:Describe*", - "ec2:DetachInternetGateway", - "ec2:DisassociateAddress", - "ec2:DisassociateRouteTable", - "ec2:GetLaunchTemplateData", - "ec2:GetTransitGatewayAttachmentPropagations", - "ec2:ModifyInstanceAttribute", - "ec2:ModifySecurityGroupRules", - "ec2:ModifyTransitGatewayVpcAttachment", - "ec2:ModifyVpcAttribute", - "ec2:ModifyVpcEndpoint", - "ec2:ReleaseAddress", - "ec2:ReplaceRoute", - "ec2:RevokeSecurityGroupEgress", - "ec2:RevokeSecurityGroupIngress", - "ec2:RunInstances", - "ec2:StartInstances", - "ec2:StopInstances", - "ec2:UpdateSecurityGroupRuleDescriptionsEgress", - "ec2:UpdateSecurityGroupRuleDescriptionsIngress", - "iam:AddRoleToInstanceProfile", - "iam:AttachRolePolicy", - "iam:CreateInstanceProfile", - "iam:CreatePolicy", - "iam:CreateRole", - "iam:DeleteInstanceProfile", - "iam:DeletePolicy", - "iam:DeleteRole", - "iam:DeleteRolePolicy", - "iam:DetachRolePolicy", - "iam:GetInstanceProfile", - "iam:GetPolicy", - "iam:GetRole", - "iam:GetRolePolicy", - "iam:ListPolicyVersions", - "iam:ListRoles", - "iam:PassRole", - "iam:PutRolePolicy", - "iam:RemoveRoleFromInstanceProfile", - "lambda:CreateFunction", - "lambda:DeleteFunction", - "lambda:DeleteLayerVersion", - "lambda:GetFunction", - "lambda:GetLayerVersion", - "lambda:InvokeFunction", - "lambda:PublishLayerVersion", - "logs:CreateLogGroup", - "logs:DeleteLogGroup", - "logs:DescribeLogGroups", - "logs:PutRetentionPolicy", - "route53:ChangeTagsForResource", - "route53:CreateHealthCheck", - "route53:CreateHostedZone", - "route53:CreateTrafficPolicy", - "route53:DeleteHostedZone", - "route53:DisassociateVPCFromHostedZone", - "route53:GetHostedZone", - "route53:ListHostedZones", - "route53domains:ListDomains", - "route53domains:ListOperations", - "route53domains:ListTagsForDomain", - "route53resolver:AssociateResolverEndpointIpAddress", - "route53resolver:AssociateResolverRule", - "route53resolver:CreateResolverEndpoint", - "route53resolver:CreateResolverRule", - "route53resolver:DeleteResolverEndpoint", - "route53resolver:DeleteResolverRule", - "route53resolver:DisassociateResolverEndpointIpAddress", - "route53resolver:DisassociateResolverRule", - "route53resolver:GetResolverEndpoint", - "route53resolver:GetResolverRule", - "route53resolver:ListResolverEndpointIpAddresses", - "route53resolver:ListResolverEndpoints", - "route53resolver:ListResolverRuleAssociations", - "route53resolver:ListResolverRules", - "route53resolver:ListTagsForResource", - "route53resolver:UpdateResolverEndpoint", - "route53resolver:UpdateResolverRule", - "s3:AbortMultipartUpload", - "s3:CreateBucket", - "s3:DeleteBucket", - "s3:DeleteObject", - "s3:GetAccountPublicAccessBlock", - "s3:GetBucketAcl", - "s3:GetBucketOwnershipControls", - "s3:GetBucketPolicy", - "s3:GetBucketPolicyStatus", - "s3:GetBucketPublicAccessBlock", - "s3:GetObject", - "s3:GetObjectVersion", - "s3:GetBucketVersioning", - "s3:ListAccessPoints", - "s3:ListAccessPointsForObjectLambda", - "s3:ListAllMyBuckets", - "s3:ListBucket", - "s3:ListBucketMultipartUploads", - "s3:ListBucketVersions", - "s3:ListJobs", - "s3:ListMultipartUploadParts", - "s3:ListMultiRegionAccessPoints", - "s3:ListStorageLensConfigurations", - "s3:PutAccountPublicAccessBlock", - "s3:PutBucketAcl", - "s3:PutBucketPolicy", - "s3:PutBucketPublicAccessBlock", - "s3:PutObject", - "secretsmanager:CreateSecret", - "secretsmanager:DeleteSecret", - "secretsmanager:DescribeSecret", - "secretsmanager:GetSecretValue", - "secretsmanager:ListSecrets", - "secretsmanager:ListSecretVersionIds", - "secretsmanager:PutResourcePolicy", - "secretsmanager:TagResource", - "secretsmanager:UpdateSecret", - "sns:ListTopics", - "ssm:DescribeInstanceProperties", - "ssm:DescribeSessions", - "ssm:GetConnectionStatus", - "ssm:GetParameters", - "ssm:ListAssociations", - "ssm:ResumeSession", - "ssm:StartSession", - "ssm:TerminateSession" - ], - "Resource": "*" - } - ] -} - -``` - -#### Khởi tạo tài nguyên bằng CloudFormation - -Trong lab này, chúng ta sẽ dùng N.Virginia region (us-east-1). - -Để chuẩn bị cho môi trường làm workshop, chúng ta deploy CloudFormation template sau (click link): [PrivateLinkWorkshop ](https://us-east-1.console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/quickcreate?templateURL=https://s3.us-east-1.amazonaws.com/reinvent-endpoints-builders-session/Nested.yaml&stackName=PLCloudSetup). Để nguyên các lựa chọn mặc định. - -![create stack](/images/5-Workshop/5.2-Prerequisite/create-stack1.png) - -+ Lựa chọn 2 mục acknowledgement -+ Chọn Create stack - -![create stack](/images/5-Workshop/5.2-Prerequisite/create-stack2.png) - -Quá trình triển khai CloudFormation cần khoảng 15 phút để hoàn thành. - -![complete](/images/5-Workshop/5.2-Prerequisite/complete.png) - -+ 2 VPCs đã được tạo - -![vpcs](/images/5-Workshop/5.2-Prerequisite/vpcs.png) - -+ 3 EC2s đã được tạo - -![EC2](/images/5-Workshop/5.2-Prerequisite/ec2.png) \ No newline at end of file diff --git a/content/5-Workshop/5.3-S3-vpc/5.3.1-create-gwe/_index.md b/content/5-Workshop/5.3-S3-vpc/5.3.1-create-gwe/_index.md deleted file mode 100644 index d61f486..0000000 --- a/content/5-Workshop/5.3-S3-vpc/5.3.1-create-gwe/_index.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title : "Create a gateway endpoint" -date : 2024-01-01 -weight : 1 -chapter : false -pre : " 5.3.1 " ---- - -1. Open the [Amazon VPC console](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#Home:) -2. In the navigation pane, choose **Endpoints**, then click **Create Endpoint**: - -{{% notice note %}} -You will see **6 existing VPC endpoints** that support **AWS Systems Manager (SSM)**. These endpoints were deployed automatically by the **CloudFormation Templates** for this workshop. -{{% /notice %}} - -![endpoint](/images/5-Workshop/5.3-S3-vpc/endpoints.png) - -3. In the Create endpoint console: -+ Specify name of the endpoint: ```s3-gwe``` -+ In service category, choose **AWS services** - -![endpoint](/images/5-Workshop/5.3-S3-vpc/create-s3-gwe1.png) - -+ In **Services**, type ```s3``` in the search box and choose the service with type **gateway** - -![endpoint](/images/5-Workshop/5.3-S3-vpc/services.png) - -+ For VPC, select **VPC Cloud** from the drop-down. -+ For **Configure route tables**, select the route table that is already associated with **two subnets** (note: this is not the main route table for the VPC, but a second route table created by CloudFormation). - -![endpoint](/images/5-Workshop/5.3-S3-vpc/vpc.png) - -+ **For Policy**, leave the default option, **Full Access**, to allow full access to the service. You will deploy **a VPC endpoint policy** in a later lab module to demonstrate restricting access to **S3 buckets** based on policies. - -![endpoint](/images/5-Workshop/5.3-S3-vpc/policy.png) - -+ Do not add a tag to the VPC endpoint at this time. -+ Click **Create endpoint**, then click x after receiving a successful creation message. - -![endpoint](/images/5-Workshop/5.3-S3-vpc/complete.png) \ No newline at end of file diff --git a/content/5-Workshop/5.3-S3-vpc/5.3.1-create-gwe/_index.vi.md b/content/5-Workshop/5.3-S3-vpc/5.3.1-create-gwe/_index.vi.md deleted file mode 100644 index e424858..0000000 --- a/content/5-Workshop/5.3-S3-vpc/5.3.1-create-gwe/_index.vi.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title : "Tạo một Gateway Endpoint" -date : 2024-01-01 -weight : 1 -chapter : false -pre : " 5.3.1 " ---- - -1. Mở [Amazon VPC console](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#Home:) -2. Trong thanh điều hướng, chọn **Endpoints**, click **Create Endpoint**: - -{{% notice note %}} -Bạn sẽ thấy 6 điểm cuối VPC hiện có hỗ trợ AWS Systems Manager (SSM). Các điểm cuối này được Mẫu CloudFormation triển khai tự động cho workshop này. -{{% /notice %}} - -![endpoint](/images/5-Workshop/5.3-S3-vpc/endpoints.png) - -3. Trong Create endpoint console: -+ Đặt tên cho endpoint: s3-gwe -+ Trong service category, chọn **aws services** - -![endpoint](/images/5-Workshop/5.3-S3-vpc/create-s3-gwe1.png) - -+ Trong **Services**, gõ "s3" trong hộp tìm kiếm và chọn dịch vụ với loại **gateway** - -![endpoint](/images/5-Workshop/5.3-S3-vpc/services.png) - -+ Đối với VPC, chọn **VPC Cloud** từ drop-down menu. -+ Đối với Route tables, chọn bảng định tuyến mà đã liên kết với 2 subnets (lưu ý: đây không phải là bảng định tuyến chính cho VPC mà là bảng định tuyến thứ hai do CloudFormation tạo). - -![endpoint](/images/5-Workshop/5.3-S3-vpc/vpc.png) - -+ Đối với Policy, để tùy chọn mặc định là Full access để cho phép toàn quyền truy cập vào dịch vụ. Bạn sẽ triển khai VPC endpoint policy trong phần sau để chứng minh việc hạn chế quyền truy cập vào S3 bucket dựa trên các policies. - -![endpoint](/images/5-Workshop/5.3-S3-vpc/policy.png) - -+ Không thêm tag vào VPC endpoint. -+ Click Create endpoint, click x sau khi nhận được thông báo tạo thành công. - -![endpoint](/images/5-Workshop/5.3-S3-vpc/complete.png) diff --git a/content/5-Workshop/5.3-S3-vpc/5.3.2-test-gwe/_index.md b/content/5-Workshop/5.3-S3-vpc/5.3.2-test-gwe/_index.md deleted file mode 100644 index 0788941..0000000 --- a/content/5-Workshop/5.3-S3-vpc/5.3.2-test-gwe/_index.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title : "Test the Gateway Endpoint" -date : 2024-01-01 -weight : 2 -chapter : false -pre : " 5.3.2 " ---- - -#### Create S3 bucket - -1. Navigate to **S3 management console** -2. In the Bucket console, choose **Create bucket** - -![Create bucket](/images/5-Workshop/5.3-S3-vpc/create-bucket.png) - -3. In **the Create bucket console** -+ **Name the bucket**: choose a name that hasn't been given to any bucket globally (hint: lab number and your name) - -![Bucket name](/images/5-Workshop/5.3-S3-vpc/bucket-name.png) - -+ Leave other fields as they are (default) -+ Scroll down and choose **Create bucket** - -![Create](/images/5-Workshop/5.3-S3-vpc/create-button.png) - -+ Successfully create S3 bucket. - -![Success](/images/5-Workshop/5.3-S3-vpc/bucket-success.png) - -#### Connect to EC2 with session manager - -+ For this workshop, you will use **AWS Session Manager** to access several **EC2 instances**. **Session Manager** is a fully managed **AWS Systems Manager** capability that allows you to manage your **Amazon EC2 instances** and on-premises virtual machines (VMs) through an interactive one-click browser-based shell. Session Manager provides secure and auditable instance management without the need to open inbound ports, maintain bastion hosts, or manage SSH keys. - -+ First cloud journey [Lab](https://000058.awsstudygroup.com/1-introduce/) for indepth understanding of Session manager. - -1. In the **AWS Management Console**, start typing ```Systems Manager``` in the quick search box and press **Enter**: - -![system manager](/images/5-Workshop/5.3-S3-vpc/sm.png) - -2. From the **Systems Manager** menu, find **Node Management** in the left menu and click **Session Manager**: - -![system manager](/images/5-Workshop/5.3-S3-vpc/sm1.png) - -3. Click **Start Session**, and select **the EC2 instance** named **Test-Gateway-Endpoint**. -{{% notice info %}} -This EC2 instance is already running in "VPC Cloud" and will be used to test connectivity to Amazon S3 through the Gateway endpoint you just created (s3-gwe). {{% /notice %}} - -![Start session](/images/5-Workshop/5.3-S3-vpc/start-session.png) - -**Session Manager** will open a new browser tab with a shell prompt: sh-4.2 $ - -![Success](/images/5-Workshop/5.3-S3-vpc/start-session-success.png) - -You have successfully start a session - connect to the EC2 instance in VPC cloud. In the next step, we will create a S3 bucket and a file in it. - -#### Create a file and upload to s3 bucket - -1. Change to the ssm-user's home directory by typing ```cd ~``` in the CLI - -![Change user's dir](/images/5-Workshop/5.3-S3-vpc/cli1.png) - -2. Create a new file to use for testing with the command ```fallocate -l 1G testfile.xyz```, which will create a file of 1GB size named "testfile.xyz". - -![Create file](/images/5-Workshop/5.3-S3-vpc/cli-file.png) - -3. Upload file to S3 bucket with command ```aws s3 cp testfile.xyz s3://your-bucket-name```. Replace your-bucket-name with the name of S3 bucket that you created earlier. - -![Uploaded](/images/5-Workshop/5.3-S3-vpc/uploaded.png) - -You have successfully uploaded the file to your S3 bucket. You can now terminate the session. - -#### Check object in S3 bucket - -1. Navigate to S3 console. -2. Click the name of your s3 bucket -3. In the Bucket console, you will see the file you have uploaded to your S3 bucket - -![Check S3](/images/5-Workshop/5.3-S3-vpc/check-s3-bucket.png) - -#### Section summary - -Congratulation on completing access to S3 from VPC. In this section, you created a Gateway endpoint for Amazon S3, and used the AWS CLI to upload an object. The upload worked because the Gateway endpoint allowed communication to S3, without needing an Internet Gateway attached to "VPC Cloud". This demonstrates the functionality of the Gateway endpoint as a secure path to S3 without traversing the Public Internet. - - - - - - - - - - - - - diff --git a/content/5-Workshop/5.3-S3-vpc/5.3.2-test-gwe/_index.vi.md b/content/5-Workshop/5.3-S3-vpc/5.3.2-test-gwe/_index.vi.md deleted file mode 100644 index 890307b..0000000 --- a/content/5-Workshop/5.3-S3-vpc/5.3.2-test-gwe/_index.vi.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title : "Kiểm tra Gateway Endpoint" -date : 2024-01-01 -weight : 2 -chapter : false -pre : " 5.3.2 " ---- - -#### Tạo S3 bucket - -1. Đi đến S3 management console -2. Trong Bucket console, chọn **Create bucket** - -![Create bucket](/images/5-Workshop/5.3-S3-vpc/create-bucket.png) - -3. Trong Create bucket console -+ Đặt tên bucket: chọn 1 tên mà không bị trùng trong phạm vi toàn cầu (gợi ý: lab\\) - -![Bucket name](/images/5-Workshop/5.3-S3-vpc/bucket-name.png) - - -+ Giữ nguyên giá trị của các fields khác (default) -+ Kéo chuột xuống và chọn **Create bucket** - -![Create](/images/5-Workshop/5.3-S3-vpc/create-button.png) - -+ Tạo thành công S3 bucket - -![Success](/images/5-Workshop/5.3-S3-vpc/bucket-success.png) - -#### Kết nối với EC2 bằng session manager - -+ Trong workshop này, bạn sẽ dùng AWS Session Manager để kết nối đến các EC2 instances. Session Manager là 1 tính năng trong dịch vụ Systems Manager được quản lý hoàn toàn bởi AWS. System manager cho phép bạn quản lý Amazon EC2 instances và các máy ảo on-premises (VMs)thông qua 1 browser-based shell. Session Manager cung cấp khả năng quản lý phiên bản an toàn và có thể kiểm tra mà không cần mở cổng vào, duy trì máy chủ bastion host hoặc quản lý khóa SSH. - -+ First cloud journey [Lab](https://000058.awsstudygroup.com/1-introduce/) để hiểu sâu hơn về Session manager. - -1. Trong AWS Management Console, gõ Systems Manager trong ô tìm kiếm và nhấn Enter: - -![system manager](/images/5-Workshop/5.3-S3-vpc/sm.png) - -2. Từ **Systems Manager** menu, tìm **Node Management** ở thanh bên trái và chọn **Session Manager**: - -![system manager](/images/5-Workshop/5.3-S3-vpc/sm1.png) - -3. Click Start Session, và chọn EC2 instance tên **Test-Gateway-Endpoint**. -{{% notice info %}} -Phiên bản EC2 này đã chạy trong "VPC cloud" và sẽ được dùng để kiểm tra khả năng kết nối với Amazon S3 thông qua điểm cuối Cổng mà bạn vừa tạo (s3-gwe). {{% /notice %}} - -![Start session](/images/5-Workshop/5.3-S3-vpc/start-session.png) - -Session Manager sẽ mở browser tab mới với shell prompt: sh-4.2 $ - -![Success](/images/5-Workshop/5.3-S3-vpc/start-session-success.png) - -Bạn đã bắt đầu phiên kết nối đến EC2 trong VPC Cloud thành công. Trong bước tiếp theo, chúng ta sẽ tạo một S3 bucket và một tệp trong đó. -#### Create a file and upload to s3 bucket - -1. Đổi về ssm-user's thư mục bằng lệnh "cd ~" - -![Change user's dir](/images/5-Workshop/5.3-S3-vpc/cli1.png) - -2. Tạo 1 file để kiểm tra bằng lệnh "fallocate -l 1G testfile.xyz", 1 file tên "testfile.xyz" có kích thước 1GB sẽ được tạo. - -![Create file](/images/5-Workshop/5.3-S3-vpc/cli-file.png) - -3. Tải file mình vừa tạo lên S3 với lệnh "aws s3 cp testfile.xyz s3://your-bucket-name". Thay your-bucket-name bằng tên S3 bạn đã tạo. - -![Uploaded](/images/5-Workshop/5.3-S3-vpc/uploaded.png) - -Bạn đã tải thành công tệp lên bộ chứa S3 của mình. Bây giờ bạn có thể kết thúc session. - -#### Kiểm tra object trong S3 bucket - -1. Đi đến S3 console. -2. Click tên s3 bucket của bạn -3. Trong Bucket console, bạn sẽ thấy tệp bạn đã tải lên S3 bucket của mình - -![Check S3](/images/5-Workshop/5.3-S3-vpc/check-s3-bucket.png) - -#### Tóm tắt - -Chúc mừng bạn đã hoàn thành truy cập S3 từ VPC. Trong phần này, bạn đã tạo gateway endpoint cho Amazon S3 và sử dụng AWS CLI để tải file lên. Quá trình tải lên hoạt động vì gateway endpoint cho phép giao tiếp với S3 mà không cần Internet gateway gắn vào "VPC Cloud". Điều này thể hiện chức năng của gateway endpoint như một đường dẫn an toàn đến S3 mà không cần đi qua pub lic Internet. \ No newline at end of file diff --git a/content/5-Workshop/5.3-S3-vpc/_index.md b/content/5-Workshop/5.3-S3-vpc/_index.md deleted file mode 100644 index 748fd7d..0000000 --- a/content/5-Workshop/5.3-S3-vpc/_index.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title : "Access S3 from VPC" -date : 2024-01-01 -weight : 3 -chapter : false -pre : " 5.3. " ---- - -#### Using Gateway endpoint - -In this section, you will create **a Gateway eendpoint** to access **Amazon S3** from **an EC2 instance**. **The Gateway endpoint** will allow upload an object to S3 buckets without using **the Public Internet**. To create an endpoint, you must specify the VPC in which you want to create the endpoint, and the service (in this case, S3) to which you want to establish the connection. - -![overview](/images/5-Workshop/5.3-S3-vpc/diagram2.png) - -#### Content - -- [Create gateway endpoint](3.1-create-gwe/) -- [Test gateway endpoint](3.2-test-gwe/) \ No newline at end of file diff --git a/content/5-Workshop/5.3-S3-vpc/_index.vi.md b/content/5-Workshop/5.3-S3-vpc/_index.vi.md deleted file mode 100644 index 23e052d..0000000 --- a/content/5-Workshop/5.3-S3-vpc/_index.vi.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title : "Truy cập S3 từ VPC" -date : 2024-01-01 -weight : 3 -chapter : false -pre : " 5.3. " ---- - -#### Sử dụng Gateway endpoint - -Trong phần này, bạn sẽ tạo một Gateway endpoint để truy cập Amazon S3 từ một EC2 instance. Gateway endpoint sẽ cho phép tải một object lên S3 bucket mà không cần sử dụng Internet Công cộng. Để tạo endpoint, bạn phải chỉ định VPC mà bạn muốn tạo endpoint và dịch vụ (trong trường hợp này là S3) mà bạn muốn thiết lập kết nối. - -![overview](/images/5-Workshop/5.3-S3-vpc/diagram2.png) - -#### Nội dung - -- [Tạo gateway endpoint](3.1-create-gwe/) -- [Test gateway endpoint](3.2-test-gwe/) \ No newline at end of file diff --git a/content/5-Workshop/5.4-S3-onprem/5.4.1-prepare/_index.md b/content/5-Workshop/5.4-S3-onprem/5.4.1-prepare/_index.md deleted file mode 100644 index 07ab771..0000000 --- a/content/5-Workshop/5.4-S3-onprem/5.4.1-prepare/_index.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -title : "Prepare the environment" -date : 2024-01-01 -weight : 1 -chapter : false -pre : " 5.4.1 " ---- - -To prepare for this part of the workshop you will need to: -+ Deploying a CloudFormation stack -+ Modifying a VPC route table. - -These components work together to simulate on-premises DNS forwarding and name resolution. - -#### Deploy the CloudFormation stack - -The CloudFormation template will create additional services to support an on-premises simulation: -+ One Route 53 Private Hosted Zone that hosts Alias records for the PrivateLink S3 endpoint -+ One Route 53 Inbound Resolver endpoint that enables "VPC Cloud" to resolve inbound DNS resolution requests to the Private Hosted Zone -+ One Route 53 Outbound Resolver endpoint that enables "VPC On-prem" to forward DNS requests for S3 to "VPC Cloud" - -![route 53 diagram](/images/5-Workshop/5.4-S3-onprem/route53.png) - -1. Click the following link to open the [AWS CloudFormation console](https://us-east-1.console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/quickcreate?templateURL=https://s3.amazonaws.com/reinvent-endpoints-builders-session/R53CF.yaml&stackName=PLOnpremSetup). The required template will be pre-loaded into the menu. Accept all default and click Create stack. - -![Create stack](/images/5-Workshop/5.4-S3-onprem/create-stack.png) - -![Button](/images/5-Workshop/5.4-S3-onprem/create-stack-button.png) - -It may take a few minutes for stack deployment to complete. You can continue with the next step without waiting for the deployemnt to finish. - -#### Update on-premise private route table - -This workshop uses a strongSwan VPN running on an EC2 instance to simulate connectivty between an on-premises datacenter and the AWS cloud. Most of the required components are provisioned before your start. To finalize the VPN configuration, you will modify the "VPC On-prem" routing table to direct traffic destined for the cloud to the strongSwan VPN instance. - -1. Open the Amazon EC2 console - -2. Select the instance named infra-vpngw-test. From the Details tab, copy the Instance ID and paste this into your text editor - -![ec2 id](/images/5-Workshop/5.4-S3-onprem/ec2-onprem-id.png) - -3. Navigate to the VPC menu by using the Search box at the top of the browser window. - -4. Click on Route Tables, select the RT Private On-prem route table, select the Routes tab, and click Edit Routes. - -![rt](/images/5-Workshop/5.4-S3-onprem/rt.png) - -5. Click Add route. -+ Destination: your Cloud VPC cidr range -+ Target: ID of your infra-vpngw-test instance (you saved in your editor at step 1) - -![add route](/images/5-Workshop/5.4-S3-onprem/add-route.png) - -6. Click Save changes - - - diff --git a/content/5-Workshop/5.4-S3-onprem/5.4.1-prepare/_index.vi.md b/content/5-Workshop/5.4-S3-onprem/5.4.1-prepare/_index.vi.md deleted file mode 100644 index 0fca0c6..0000000 --- a/content/5-Workshop/5.4-S3-onprem/5.4.1-prepare/_index.vi.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title : "Chuẩn bị tài nguyên" -date : 2024-01-01 -weight : 1 -chapter : false -pre : " 5.4.1 " ---- - -Để chuẩn bị cho phần này của workshop, bạn sẽ cần phải: -+ Triển khai CloudFormation stack -+ Sửa đổi bảng định tuyến VPC. - -Các thành phần này hoạt động cùng nhau để mô phỏng DNS forwarding và name resolution. - -#### Triển khai CloudFormation stack - -Mẫu CloudFormation sẽ tạo các dịch vụ bổ sung để hỗ trợ mô phỏng môi trường truyền thống: -+ Một Route 53 Private Hosted Zone lưu trữ các bản ghi Bí danh (Alias records) cho điểm cuối PrivateLink S3 -+ Một Route 53 Inbound Resolver endpoint cho phép "VPC Cloud" giải quyết các yêu cầu resolve DNS gửi đến Private Hosted Zone -+ Một Route 53 Outbound Resolver endpoint cho phép "VPC On-prem" chuyển tiếp các yêu cầu DNS cho S3 sang "VPC Cloud" - -![route 53 diagram](/images/5-Workshop/5.4-S3-onprem/route53.png) - -1. Click link sau để mở [AWS CloudFormation console](https://us-east-1.console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/quickcreate?templateURL=https://s3.amazonaws.com/reinvent-endpoints-builders-session/R53CF.yaml&stackName=PLOnpremSetup). Mẫu yêu cầu sẽ được tải sẵn vào menu. Chấp nhận tất cả mặc định và nhấp vào Tạo stack. - -![Create stack](/images/5-Workshop/5.4-S3-onprem/create-stack.png) - -![Button](/images/5-Workshop/5.4-S3-onprem/create-stack-button.png) - -Có thể mất vài phút để triển khai stack hoàn tất. Bạn có thể tiếp tục với bước tiếp theo mà không cần đợi quá trình triển khai kết thúc. - -#### Cập nhật bảng định tuyến private on-premise - -Workshop này sử dụng StrongSwan VPN chạy trên EC2 instance để mô phỏng khả năng kết nối giữa trung tâm dữ liệu truyền thống và môi trường cloud AWS. Hầu hết các thành phần bắt buộc đều được cung cấp trước khi bạn bắt đầu. Để hoàn tất cấu hình VPN, bạn sẽ sửa đổi bảng định tuyến "VPC on-prem" để hướng lưu lượng đến cloud đi qua StrongSwan VPN instance. - -1. Mở Amazon EC2 console - -2. Chọn instance tên infra-vpngw-test. Từ Details tab, copy Instance ID và paste vào text editor của bạn để sử dụng ở những bước tiếp theo - -![ec2 id](/images/5-Workshop/5.4-S3-onprem/ec2-onprem-id.png) - -3. Đi đến VPC menu bằng cách gõ "VPC" vào Search box - -4. Click vào Route Tables, chọn RT Private On-prem route table, chọn Routes tab, và click Edit Routes. - -![rt](/images/5-Workshop/5.4-S3-onprem/rt.png) - -5. Click Add route. -+ Destination: CIDR block của Cloud VPC -+ Target: ID của infra-vpngw-test instance (bạn đã lưu lại ở bước trên) - -![add route](/images/5-Workshop/5.4-S3-onprem/add-route.png) - -6. Click Save changes - - - - diff --git a/content/5-Workshop/5.4-S3-onprem/5.4.2-create-interface-enpoint/_index.md b/content/5-Workshop/5.4-S3-onprem/5.4.2-create-interface-enpoint/_index.md deleted file mode 100644 index 0eee36b..0000000 --- a/content/5-Workshop/5.4-S3-onprem/5.4.2-create-interface-enpoint/_index.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title : "Create an S3 Interface endpoint" -date : 2024-01-01 -weight : 2 -chapter : false -pre : " 5.4.2 " ---- - -In this section you will create and test an S3 interface endpoint using the simulated on-premises environment deployed as part of this workshop. - -1. Return to the Amazon VPC menu. In the navigation pane, choose Endpoints, then click Create Endpoint. - -2. In Create endpoint console: -+ Name the interface endpoint -+ In Service category, choose **aws services** - -![name](/images/5-Workshop/5.4-S3-onprem/s3-interface-endpoint1.png) - -3. In the Search box, type S3 and press Enter. Select the endpoint named com.amazonaws.us-east-1.s3. Ensure that the Type column indicates Interface. - -![service](/images/5-Workshop/5.4-S3-onprem/s3-interface-endpoint2.png) - -4. For VPC, select VPC Cloud from the drop-down. -{{% notice warning %}} -Make sure to choose "VPC Cloud" and not "VPC On-prem" -{{% /notice %}} -+ Expand **Additional settings** and ensure that Enable DNS name is *not* selected (we will use this in the next part of the workshop) - -![vpc](/images/5-Workshop/5.4-S3-onprem/s3-interface-endpoint3.png) - -5. Select 2 subnets in the following AZs: us-east-1a and us-east-1b - -![subnets](/images/5-Workshop/5.4-S3-onprem/s3-interface-endpoint4.png) - -6. For Security group, choose SGforS3Endpoint: - -![sg](/images/5-Workshop/5.4-S3-onprem/s3-interface-endpoint5.png) - -7. Keep the default policy - full access and click Create endpoint - -![success](/images/5-Workshop/5.4-S3-onprem/s3-interface-endpoint-success.png) - -Congratulation on successfully creating S3 interface endpoint. In the next step, we will test the interface endpoint. \ No newline at end of file diff --git a/content/5-Workshop/5.4-S3-onprem/5.4.2-create-interface-enpoint/_index.vi.md b/content/5-Workshop/5.4-S3-onprem/5.4.2-create-interface-enpoint/_index.vi.md deleted file mode 100644 index fc3ffdd..0000000 --- a/content/5-Workshop/5.4-S3-onprem/5.4.2-create-interface-enpoint/_index.vi.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title : "Tạo một S3 Interface endpoint" -date : 2024-01-01 -weight : 2 -chapter : false -pre : " 5.4.2 " ---- - -Trong phần này, bạn sẽ tạo và kiểm tra Interface Endpoint S3 bằng cách sử dụng môi trường truyền thống mô phỏng. - -1. Quay lại Amazon VPC menu. Trong thanh điều hướng bên trái, chọn Endpoints, sau đó click Create Endpoint. - -2. Trong Create endpoint console: -+ Đặt tên interface endpoint -+ Trong Service category, chọn **aws services** - -![name](/images/5-Workshop/5.4-S3-onprem/s3-interface-endpoint1.png) - -3. Trong Search box, gõ S3 và nhấn Enter. Chọn endpoint có tên com.amazonaws.us-east-1.s3. Đảm bảo rằng cột Type có giá trị Interface. - -![service](/images/5-Workshop/5.4-S3-onprem/s3-interface-endpoint2.png) - -4. Đối với VPC, chọn VPC Cloud từ drop-down. -{{% notice warning %}} -Đảm bảo rằng bạn chọn "VPC Cloud" và không phải "VPC On-prem" -{{% /notice %}} -+ Mở rộng **Additional settings** và đảm bảo rằng Enable DNS name *không* được chọn (sẽ sử dụng điều này trong phần tiếp theo của workshop) - -![vpc](/images/5-Workshop/5.4-S3-onprem/s3-interface-endpoint3.png) - -5. Chọn 2 subnets trong AZs sau: us-east-1a and us-east-1b - -![subnets](/images/5-Workshop/5.4-S3-onprem/s3-interface-endpoint4.png) - -6. Đối với Security group, chọn SGforS3Endpoint: - -![sg](/images/5-Workshop/5.4-S3-onprem/s3-interface-endpoint5.png) - -7. Giữ default policy - full access và click Create endpoint - -![success](/images/5-Workshop/5.4-S3-onprem/s3-interface-endpoint-success.png) - -Chúc mừng bạn đã tạo thành công S3 interface endpoint. Ở bước tiếp theo, chúng ta sẽ kiểm tra interface endpoint. \ No newline at end of file diff --git a/content/5-Workshop/5.4-S3-onprem/5.4.3-test-endpoint/_index.md b/content/5-Workshop/5.4-S3-onprem/5.4.3-test-endpoint/_index.md deleted file mode 100644 index fa1fbfa..0000000 --- a/content/5-Workshop/5.4-S3-onprem/5.4.3-test-endpoint/_index.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title : "Test the Interface Endpoint" -date : 2024-01-01 -weight : 3 -chapter : false -pre : " 5.4.3 " ---- - -#### Get the regional DNS name of S3 interface endpoint -1. From the Amazon VPC menu, choose Endpoints. - -2. Click the name of newly created endpoint: s3-interface-endpoint. Click details and save the regional DNS name of the endpoint (the first one) to your text-editor for later use. - -![dns name](/images/5-Workshop/5.4-S3-onprem/dns.png) - - -#### Connect to EC2 instance in "VPC On-prem" - -1. Navigate to **Session manager** by typing "session manager" in the search box - -2. Click **Start Session**, and select the EC2 instance named **Test-Interface-Endpoint**. This EC2 instance is running in "VPC On-prem" and will be used to test connectivty to Amazon S3 through the Interface endpoint we just created. Session Manager will open a new browser tab with a shell prompt: **sh-4.2 $** - -![Start session](/images/5-Workshop/5.4-S3-onprem/start-session.png) - -3. Change to the ssm-user's home directory with command "cd ~" - -4. Create a file named testfile2.xyz -``` -fallocate -l 1G testfile2.xyz -``` - -![user](/images/5-Workshop/5.4-S3-onprem/cli1.png) - - -5. Copy file to the same S3 bucket we created in section 3.2 - -``` -aws s3 cp --endpoint-url https://bucket. testfile2.xyz s3:// -``` -+ This command requires the --endpoint-url parameter, because you need to use the endpoint-specific DNS name to access S3 using an Interface endpoint. -+ Do not include the leading ' * ' when copying/pasting the regional DNS name. -+ Provide your S3 bucket name created earlier - -![copy file](/images/5-Workshop/5.4-S3-onprem/cli2.png) - - -Now the file has been added to your S3 bucket. Let check your S3 bucket in the next step. - -#### Check Object in S3 bucket - -1. Navigate to S3 console -2. Click Buckets -3. Click the name of your bucket and you will see testfile2.xyz has been added to your bucket - -![check bucket](/images/5-Workshop/5.4-S3-onprem/check-bucket.png) - - - - diff --git a/content/5-Workshop/5.4-S3-onprem/5.4.3-test-endpoint/_index.vi.md b/content/5-Workshop/5.4-S3-onprem/5.4.3-test-endpoint/_index.vi.md deleted file mode 100644 index 8c2b319..0000000 --- a/content/5-Workshop/5.4-S3-onprem/5.4.3-test-endpoint/_index.vi.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -title : "Kiểm tra Interface Endpoint" -date : 2024-01-01 -weight : 3 -chapter : false -pre : " 5.4.3 " ---- - -#### Lấy regional DNS name (tên DNS khu vực) của S3 interface endpoint -1. Trong Amazon VPC menu, chọn Endpoints. - -2. Click tên của endpoint chúng ta mới tạo ở mục 4.2: s3-interface-endpoint. Click details và lưu lại regional DNS name của endpoint (cái đầu tiên) vào text-editor của bạn để dùng ở các bước sau. - -![dns name](/images/5-Workshop/5.4-S3-onprem/dns.png) - -#### Kết nối đến EC2 instance ở trong "VPC On-prem" (giả lập môi trường truyền thống) - -1. Đi đến **Session manager** bằng cách gõ "session manager" vào ô tìm kiếm - -2. Click **Start Session**, chọn EC2 instance có tên **Test-Interface-Endpoint**. EC2 instance này đang chạy trên "VPC On-prem" và sẽ được sử dụng để kiểm tra kết nối đến Amazon S3 thông qua Interface endpoint. Session Manager sẽ mở 1 browser tab mới với shell prompt: **sh-4.2 $** - -![Start session](/images/5-Workshop/5.4-S3-onprem/start-session.png) - -3. Đi đến ssm-user's home directory với lệnh "cd ~" - -4. Tạo 1 file tên testfile2.xyz -``` -fallocate -l 1G testfile2.xyz -``` - -![user](/images/5-Workshop/5.4-S3-onprem/cli1.png) - -5. Copy file vào S3 bucket mình tạo ở section 4.2 -``` -aws s3 cp --endpoint-url https://bucket. testfile2.xyz s3:// -``` -+ Câu lệnh này yêu cầu thông số --endpoint-url, bởi vì bạn cần sử dụng DNS name chỉ định cho endpoint để truy cập vào S3 thông qua Interface endpoint. -+ Không lấy ' * ' khi copy/paste tên DNS khu vực. -+ Cung cấp tên S3 bucket của bạn - -![copy file](/images/5-Workshop/5.4-S3-onprem/cli2.png) - -Bây giờ tệp đã được thêm vào bộ chứa S3 của bạn. Hãy kiểm tra bộ chứa S3 của bạn trong bước tiếp theo. - -#### Kiểm tra Object trong S3 bucket - -1. Đi đến S3 console -2. Click Buckets -3. Click tên bucket của bạn và bạn sẽ thấy testfile2.xyz đã được thêm vào s3 bucket của bạn - -![check bucket](/images/5-Workshop/5.4-S3-onprem/check-bucket.png) - - - - diff --git a/content/5-Workshop/5.4-S3-onprem/5.4.4-dns-simulation/_index.md b/content/5-Workshop/5.4-S3-onprem/5.4.4-dns-simulation/_index.md deleted file mode 100644 index c098e9a..0000000 --- a/content/5-Workshop/5.4-S3-onprem/5.4.4-dns-simulation/_index.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -title : "On-premises DNS Simulation" -date : 2024-01-01 -weight : 4 -chapter : false -pre : " 5.4.4 " ---- - -AWS PrivateLink endpoints have a fixed IP address in each Availability Zone where they are deployed, for the life of the endpoint (until it is deleted). These IP addresses are attached to Elastic Network Interfaces (ENIs). AWS recommends using DNS to resolve the IP addresses for endpoints so that downstream applications use the latest IP addresses when ENIs are added to new AZs, or deleted over time. - -In this section, you will create a forwarding rule to send DNS resolution requests from a simulated on-premises environment to a Route 53 Private Hosted Zone. This section leverages the infrastructure deployed by CloudFormation in the Prepare the environment section. - -#### Create DNS Alias Records for the Interface endpoint -1. Navigate to the [Route 53 management console](https://us-east-1.console.aws.amazon.com/route53/v2/hostedzones?region=us-east-1#) (Hosted Zones section). The CloudFormation template you deployed in the Prepare the environment section created this Private Hosted Zone. Click on the name of the Private Hosted Zone, s3.us-east-1.amazonaws.com: - -![hosted zone](/images/5-Workshop/5.4-S3-onprem/hosted-zone.png) - -2. Create a new record in the Private Hosted Zone: - -![Create record](/images/5-Workshop/5.4-S3-onprem/create-record1.png) - -+ Record name and record type keep default options -+ Alias Button: Click to enable -+ Route traffic to: Alias to VPC Endpoint -+ Region: US East (N. Virginia) [us-east-1] -+ Choose endpoint: Paste the Regional VPC Endpoint DNS name from your text editor (you saved when doing section 4.3) - -![record1](/images/5-Workshop/5.4-S3-onprem/record1.png) - -3. Click Add another record, and add a second record using the following values. Click Create records when finished to create both records. -+ Record name: *. -+ Record type: keep default value (type A) -+ Alias Button: Click to enable -+ Route traffic to: Alias to VPC Endpoint -+ Region: US East (N. Virginia) [us-east-1] -+ Choose endpoint: Paste the Regional VPC Endpoint DNS name from your text editor - -![record 2](/images/5-Workshop/5.4-S3-onprem/record2.png) - -The new records appear in the Route 53 console: - -![result](/images/5-Workshop/5.4-S3-onprem/result.png) - -#### Create a Resolver Forwarding Rule - -Route 53 Resolver Forwarding Rules allow you to forward DNS queries from your VPC to other sources for name resolution. Outside of a workshop environment, you might use this feature to forward DNS queries from your VPC to DNS servers running on-premises. In this section, you will simulate an on-premises conditional forwarder by creating a forwarding rule that forwards DNS queries for Amazon S3 to a Private Hosted Zone running in "VPC Cloud" in-order to resolve the PrivateLink interface endpoint regional DNS name. - -1. From the Route 53 management console, click **Inbound endpoints** on the left side bar -2. In the Inbound endpoints console, click the ID of the inbound endpoint - -![Inbound endpoint](/images/5-Workshop/5.4-S3-onprem/route53-1.png) - -3. Copy the two IP addresses listed to your text editor - -![Ip addresses](/images/5-Workshop/5.4-S3-onprem/route53-2.png) - -4. From the Route 53 menu, choose **Resolver** > **Rules**, and click **Create rule**: - -![Ip addresses](/images/5-Workshop/5.4-S3-onprem/route53-3.png) - -5. In the Create rule console: -+ Name: myS3Rule -+ Rule type: Forward -+ Domain name: s3.us-east-1.amazonaws.com - -![create rule](/images/5-Workshop/5.4-S3-onprem/route53-4.png) - -+ VPC: VPC On-prem -+ Outbound endpoint: VPCOnpremOutboundEndpoint - -![create rule](/images/5-Workshop/5.4-S3-onprem/route53-5.png) - -+ Target IP Addresses: Enter both IP addresses from your text editor (inbound endpoint addresses) and then click Submit - -![create rule](/images/5-Workshop/5.4-S3-onprem/route53-6.png) -You have successfully created resolver forwarding rule. - -![create rule](/images/5-Workshop/5.4-S3-onprem/route53-7.png) - -#### Test the on-premises DNS Simulation - -1. Connect to **Test-Interface-Endpoint EC2 instance** with **Session manager** - -![create rule](/images/5-Workshop/5.4-S3-onprem/test1.png) - -2. Test DNS resolution. The dig command will return the IP addresses assigned to the VPC Interface endpoint running in VPC Cloud (your IP's will be different): dig +short s3.us-east-1.amazonaws.com - -{{% notice note %}} -The IP addresses returned are the VPC endpoint IP addresses, NOT the Resolver IP addresses you pasted from your text editor. The IP addresses of the Resolver endpoint and the VPC endpoint look similar because they are all from the VPC Cloud CIDR block. -{{% /notice %}} - -![create rule](/images/5-Workshop/5.4-S3-onprem/dig.png) - - -3. Navigate to the VPC menu (Endpoints section), select the S3 Interface endpoint. Click the Subnets tab and verify that the IP addresses returned by Dig match the VPC endpoint: - -![create rule](/images/5-Workshop/5.4-S3-onprem/subnet.png) - -4. Return to your shell and use the AWS CLI to test listing your S3 buckets: - -``` -aws s3 ls --endpoint-url https://s3.us-east-1.amazonaws.com -``` - -![create rule](/images/5-Workshop/5.4-S3-onprem/endpoint.png) - -5. Terminate your Session Manager session: - -![create rule](/images/5-Workshop/5.4-S3-onprem/terminal.png) - -In this section you created an Interface endpoint for Amazon S3. This endpoint can be reached from on-premises through Site-to-Site VPN or AWS Direct Connect. Route 53 Resolver outbound endpoints simulated forwarding DNS requests from on-premises to a Private Hosted Zone running the cloud. Route 53 inbound Endpoints recieved the resolution request and returned a response containing the IP addresses of the VPC interface endpoint. Using DNS to resolve the endpoint IP addresses provides high availability in-case of an Availability Zone outage. \ No newline at end of file diff --git a/content/5-Workshop/5.4-S3-onprem/5.4.4-dns-simulation/_index.vi.md b/content/5-Workshop/5.4-S3-onprem/5.4.4-dns-simulation/_index.vi.md deleted file mode 100644 index 1686146..0000000 --- a/content/5-Workshop/5.4-S3-onprem/5.4.4-dns-simulation/_index.vi.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title : "Mô phỏng On-premises DNS " -date : 2024-01-01 -weight : 4 -chapter : false -pre : " 5.4.4 " ---- - - AWS PrivateLink endpoint có một địa chỉ IP cố định trong từng AZ nơi chúng được triển khai, trong suốt thời gian tồn tại của endpoint (cho đến khi endpoint bị xóa). Các địa chỉ IP này được gắn vào Elastic network interface (ENI). AWS khuyến nghị sử dụng DNS để resolve địa chỉ IP cho endpoint để các ứng dụng downstream sử dụng địa chỉ IP mới nhất khi ENIs được thêm vào AZ mới hoặc bị xóa theo thời gian. - -Trong phần này, bạn sẽ tạo một quy tắc chuyển tiếp (forwarding rule) để gửi các yêu cầu resolve DNS từ môi trường truyền thống (mô phỏng) đến Private Hosted Zone trên Route 53. Phần này tận dụng cơ sở hạ tầng do CloudFormation triển khai trong phần Chuẩn bị môi trường. - -#### Tạo DNS Alias Records cho Interface endpoint -1. Click link để đi đến [Route 53 management console](https://us-east-1.console.aws.amazon.com/route53/v2/hostedzones?region=us-east-1#) (Hosted Zones section). Mẫu CloudFormation mà bạn triển khai trong phần Chuẩn bị môi trường đã tạo Private Hosted Zone này. Nhấp vào tên của Private Hosted Zone, s3.us-east-1.amazonaws.com: - -![hosted zone](/images/5-Workshop/5.4-S3-onprem/hosted-zone.png) - -2. Tạo 1 record mới trong Private Hosted Zone: - -![Create record](/images/5-Workshop/5.4-S3-onprem/create-record1.png) - -+ Giữ nguyên Record name và record type -+ Alias Button: click để enable -+ Route traffic to: Alias to VPC Endpoint -+ Region: US East (N. Virginia) [us-east-1] -+ Chọn endpoint: Paste tên (Regional VPC Endpoint DNS) bạn đã lưu lại ở phần 4.3 - -![record1](/images/5-Workshop/5.4-S3-onprem/record1.png) - -3. Click Add another record, và add 1 cái record thứ 2 sử dụng những thông số sau: -+ Record name: *. -+ Record type: giữ giá trị default (type A) -+ Alias Button: Click để enable -+ Route traffic to: Alias to VPC Endpoint -+ Region: US East (N. Virginia) [us-east-1] -+ Chọn endpoint: Paste tên (Regional VPC Endpoint DNS) bạn đã lưu lại ở phần 4.3 -+ Click **Create records** - -![record 2](/images/5-Workshop/5.4-S3-onprem/record2.png) - -Record mới xuất hiện trên giao diện Route 53. - -![result](/images/5-Workshop/5.4-S3-onprem/result.png) - -#### Tạo một Resolver Forwarding Rule - -**Route 53 Resolver Forwarding Rules** cho phép bạn chuyển tiếp các DNS queries từ VPC của bạn đến các nguồn khác để resolve name. Bên ngoài môi trường workshop, bạn có thể sử dụng tính năng này để chuyển tiếp các DNS queries từ VPC của bạn đến các máy chủ DNS chạy trên on-premises. Trong phần này, bạn sẽ mô phỏng một on-premises conditional forwarder bằng cách tạo một forwarding rule để chuyển tiếp các DNS queries for Amazon S3 đến một Private Hosted Zone chạy trong "VPC Cloud" để resolve PrivateLink interface endpoint regional DNS name. - -1. Từ giao diện **Route 53**, chọn **Inbound endpoints** trên thanh bên trái - -2. Trong giao diện **Inbound endpoint**, Chọn ID của Inbound endpoint. - -![Inbound endpoint](/images/5-Workshop/5.4-S3-onprem/route53-1.png) - -3. Sao chép 2 địa chỉ IP trong danh sách vào trình chỉnh sửa. - -![Ip addresses](/images/5-Workshop/5.4-S3-onprem/route53-2.png) - -4. Từ giao diện Route 53, chọn **Resolver** > **Rules** và chọn **Create rule** - -![Ip addresses](/images/5-Workshop/5.4-S3-onprem/route53-3.png) - -5. Trong giao diện **Create rule** - -+ Name: myS3Rule -+ Rule type: Forward -+ Domain name: s3.us-east-1.amazonaws.com - -![create rule](/images/5-Workshop/5.4-S3-onprem/route53-4.png) - -+ VPC: VPC On-prem -+ Outbound endpoint: VPCOnpremOutboundEndpoint - -![create rule](/images/5-Workshop/5.4-S3-onprem/route53-5.png) - -+ Target IP Addresses: điền cả hai IP bạn đã lưu trữ trên trình soạn thảo (inbound endpoint addresses) và sau đó chọn **Submit** - -![create rule](/images/5-Workshop/5.4-S3-onprem/route53-6.png) - -Bạn đã tạo thành công resolver forwarding rule. - -![create rule](/images/5-Workshop/5.4-S3-onprem/route53-7.png) - -#### Kiểm tra on-premises DNS mô phỏng. - -1. Kết nối đến **Test-Interface-Endpoint EC2 instance** với **Session Manager** - -![create rule](/images/5-Workshop/5.4-S3-onprem/test1.png) - -2. Kiểm tra DNS resolution. Lệnh dig sẽ trả về địa chỉ IP được gán cho VPC endpoint interface đang chạy trên VPC (địa chỉ IP của bạn sẽ khác): - -``` -dig +short s3.us-east-1.amazonaws.com -``` -{{% notice note %}} -Các địa chỉ IP được trả về là các địa chỉ IP VPC enpoint, KHÔNG phải là các địa chỉ IP Resolver mà bạn đã dán từ trình chỉnh sửa văn bản của mình. Các địa chỉ IP của Resolver endpoint và VPC endpoin trông giống nhau vì chúng đều từ khối CIDR VPC Cloud. -{{% /notice %}} - -![create rule](/images/5-Workshop/5.4-S3-onprem/dig.png) - -3. Truy cập vào menu VPC (phần Endpoints), chọn S3 interface endpoint. Nhấp vào tab Subnets và xác nhận rằng các địa chỉ IP được trả về bởi lệnh Dig khớp với VPC endpoint: - -![create rule](/images/5-Workshop/5.4-S3-onprem/subnet.png) - -4. Hãy quay lại shell của bạn và sử dụng AWS CLI để kiểm tra danh sách các bucket S3 của bạn: - -``` -aws s3 ls --endpoint-url https://s3.us-east-1.amazonaws.com -``` - -![create rule](/images/5-Workshop/5.4-S3-onprem/endpoint.png) - -5. Kết thúc phiên làm việc của Session Manager của bạn: - -![create rule](/images/5-Workshop/5.4-S3-onprem/terminal.png) - - -Trong phần này, bạn đã tạo một **Interface Endpoint** cho Amazon S3. Điểm cuối này có thể được truy cập từ on-premises thông qua Site-to-Site VPN hoặc AWS Direct Connect. Các điểm cuối Route 53 Resolver outbound giả lập chuyển tiếp các yêu cầu DNS từ on-premises đến một Private Hosted Zone đang chạy trên đám mây. Các điểm cuối Route 53 inbound nhận yêu cầu giải quyết và trả về một phản hồi chứa địa chỉ IP của **Interface Endpoint** VPC. Sử dụng DNS để giải quyết các địa chỉ IP của điểm cuối cung cấp tính sẵn sàng cao trong trường hợp một Availability Zone gặp sự cố. \ No newline at end of file diff --git a/content/5-Workshop/5.4-S3-onprem/_index.md b/content/5-Workshop/5.4-S3-onprem/_index.md deleted file mode 100644 index e7c1c2c..0000000 --- a/content/5-Workshop/5.4-S3-onprem/_index.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title : "Access S3 from on-premises" -date : 2024-01-01 -weight : 4 -chapter : false -pre : " 5.4. " ---- - -#### Overview - -+ In this section, you will create an Interface endpoint to access Amazon S3 from a simulated on-premises environment. The Interface endpoint will allow you to route to Amazon S3 over a VPN connection from your simulated on-premises environment. - -+ Why using **Interface endpoint**: - + Gateway endpoints only work with resources running in the VPC where they are created. Interface endpoints work with resources running in VPC, and also resources running in on-premises environments. Connectivty from your on-premises environment to the cloud can be provided by AWS Site-to-Site VPN or AWS Direct Connect. - + Interface endpoints allow you to connect to services powered by AWS PrivateLink. These services include some AWS services, services hosted by other AWS customers and partners in their own VPCs (referred to as PrivateLink Endpoint Services), and supported AWS Marketplace Partner services. For this workshop, we will focus on connecting to Amazon S3. - -![Interface endpoint architecture](/images/5-Workshop/5.4-S3-onprem/diagram3.png) - - - diff --git a/content/5-Workshop/5.4-S3-onprem/_index.vi.md b/content/5-Workshop/5.4-S3-onprem/_index.vi.md deleted file mode 100644 index 5f04c8d..0000000 --- a/content/5-Workshop/5.4-S3-onprem/_index.vi.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title : "Truy cập S3 từ môi trường truyền thống" -date : 2024-01-01 -weight : 4 -chapter : false -pre : " 5.4. " ---- - -#### Tổng quan - -+ Trong phần này, bạn sẽ tạo một Interface Endpoint để truy cập Amazon S3 từ môi trường truyền thống mô phỏng. Interface Endpoint sẽ cho phép bạn định tuyến đến Amazon S3 qua kết nối VPN từ môi trường truyền thống mô phỏng của bạn. - -+ Tại sao nên sử dụng **Interface Endpoint**: - + Các Gateway endpoints chỉ hoạt động với các tài nguyên đang chạy trong VPC nơi chúng được tạo. Interface Endpoint hoạt động với tài nguyên chạy trong VPC và cả tài nguyên chạy trong môi trường truyền thống. Khả năng kết nối từ môi trường truyền thống của bạn với aws cloud có thể được cung cấp bởi AWS Site-to-Site VPN hoặc AWS Direct Connect. - + Interface Endpoint cho phép bạn kết nối với các dịch vụ do AWS PrivateLink cung cấp. Các dịch vụ này bao gồm một số dịch vụ AWS, dịch vụ do các đối tác và khách hàng AWS lưu trữ trong VPC của riêng họ (gọi tắt là Dịch vụ PrivateLink endpoints) và các dịch vụ Đối tác AWS Marketplace. Đối với workshop này, chúng ta sẽ tập trung vào việc kết nối với Amazon S3. - -![Interface endpoint architecture](/images/5-Workshop/5.4-S3-onprem/diagram3.png) - - - diff --git a/content/5-Workshop/5.5-Policy/_index.md b/content/5-Workshop/5.5-Policy/_index.md deleted file mode 100644 index 04b3333..0000000 --- a/content/5-Workshop/5.5-Policy/_index.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title : "VPC Endpoint Policies" -date : 2024-01-01 -weight : 5 -chapter : false -pre : " 5.5. " ---- - -When you create an interface or gateway endpoint, you can attach an endpoint policy to it that controls access to the service to which you are connecting. A VPC endpoint policy is an IAM resource policy that you attach to an endpoint. If you do not attach a policy when you create an endpoint, AWS attaches a default policy for you that allows full access to the service through the endpoint. - -You can create a policy that restricts access to specific S3 buckets only. This is useful if you only want certain S3 Buckets to be accessible through the endpoint. - -In this section you will create a VPC endpoint policy that restricts access to the S3 bucket specified in the VPC endpoint policy. - -![endpoint diagram](/images/5-Workshop/5.5-Policy/s3-bucket-policy.png) - -#### Connect to an EC2 instance and verify connectivity to S3 - -1. Start a new AWS Session Manager session on the instance named Test-Gateway-Endpoint. From the session, verify that you can list the contents of the bucket you created in Part 1: Access S3 from VPC: - -``` -aws s3 ls s3://\ -``` -![test](/images/5-Workshop/5.5-Policy/test1.png) - -The bucket contents include the two 1 GB files uploaded in earlier. - -2. Create a new S3 bucket; follow the naming pattern you used in Part 1, but add a '-2' to the name. Leave other fields as default and click create - -![create bucket](/images/5-Workshop/5.5-Policy/create-bucket.png) - -Successfully create bucket - -![Success](/images/5-Workshop/5.5-Policy/create-bucket-success.png) - -3. Navigate to: Services > VPC > Endpoints, then select the Gateway VPC endpoint you created earlier. Click the Policy tab. Click Edit policy. - -![policy](/images/5-Workshop/5.5-Policy/policy1.png) - -The default policy allows access to all S3 Buckets through the VPC endpoint. - -4. In Edit Policy console, copy & Paste the following policy, then replace yourbucketname-2 with your 2nd bucket name. This policy will allow access through the VPC endpoint to your new bucket, but not any other bucket in Amazon S3. Click Save to apply the policy. - -``` -{ - "Id": "Policy1631305502445", - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "Stmt1631305501021", - "Action": "s3:*", - "Effect": "Allow", - "Resource": [ - "arn:aws:s3:::yourbucketname-2", - "arn:aws:s3:::yourbucketname-2/*" - ], - "Principal": "*" - } - ] -} -``` - -![custom policy](/images/5-Workshop/5.5-Policy/policy2.png) - -Successfully customize policy - -![success](/static/images/5-Workshop/5.5-Policy/success.png) - -5. From your session on the Test-Gateway-Endpoint instance, test access to the S3 bucket you created in Part 1: Access S3 from VPC -``` -aws s3 ls s3:// -``` - -This command will return an error because access to this bucket is not permitted by your new VPC endpoint policy: - -![error](/static/images/5-Workshop/5.5-Policy/error.png) - -6. Return to your home directory on your EC2 instance ` cd~ ` - -+ Create a file ```fallocate -l 1G test-bucket2.xyz ``` -+ Copy file to 2nd bucket ```aws s3 cp test-bucket2.xyz s3://``` - -![success](/static/images/5-Workshop/5.5-Policy/test2.png) - -This operation succeeds because it is permitted by the VPC endpoint policy. - -![success](/static/images/5-Workshop/5.5-Policy/test2-success.png) - -+ Then we test access to the first bucket by copy the file to 1st bucket `aws s3 cp test-bucket2.xyz s3://` - -![fail](/static/images/5-Workshop/5.5-Policy/test2-fail.png) - -This command will return an error because access to this bucket is not permitted by your new VPC endpoint policy. - -#### Part 3 Summary: - -In this section, you created a VPC endpoint policy for Amazon S3, and used the AWS CLI to test the policy. AWS CLI actions targeted to your original S3 bucket failed because you applied a policy that only allowed access to the second bucket you created. AWS CLI actions targeted for your second bucket succeeded because the policy allowed them. These policies can be useful in situations where you need to control access to resources through VPC endpoints. - - diff --git a/content/5-Workshop/5.5-Policy/_index.vi.md b/content/5-Workshop/5.5-Policy/_index.vi.md deleted file mode 100644 index 814d98a..0000000 --- a/content/5-Workshop/5.5-Policy/_index.vi.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title : "VPC Endpoint Policies" -date : 2024-01-01 -weight : 5 -chapter : false -pre : " 5.5 " ---- - -Khi bạn tạo một Interface Endpoint hoặc cổng, bạn có thể đính kèm một chính sách điểm cuối để kiểm soát quyền truy cập vào dịch vụ mà bạn đang kết nối. Chính sách VPC Endpoint là chính sách tài nguyên IAM mà bạn đính kèm vào điểm cuối. Nếu bạn không đính kèm chính sách khi tạo điểm cuối, thì AWS sẽ đính kèm chính sách mặc định cho bạn để cho phép toàn quyền truy cập vào dịch vụ thông qua điểm cuối. - -Bạn có thể tạo chính sách chỉ hạn chế quyền truy cập vào các S3 bucket cụ thể. Điều này hữu ích nếu bạn chỉ muốn một số Bộ chứa S3 nhất định có thể truy cập được thông qua điểm cuối. - -Trong phần này, bạn sẽ tạo chính sách VPC Endpoint hạn chế quyền truy cập vào S3 bucket được chỉ định trong chính sách VPC Endpoint. - -![endpoint diagram](/images/5-Workshop/5.5-Policy/s3-bucket-policy.png) - -#### Kết nối tới EC2 và xác minh kết nối tới S3. - -1. Bắt đầu một phiên AWS Session Manager mới trên máy chủ có tên là Test-Gateway-Endpoint. Từ phiên này, xác minh rằng bạn có thể liệt kê nội dung của bucket mà bạn đã tạo trong Phần 1: Truy cập S3 từ VPC. - -``` -aws s3 ls s3:// -``` -![test](/images/5-Workshop/5.5-Policy/test1.png) - -Nội dung của bucket bao gồm hai tệp có dung lượng 1GB đã được tải lên trước đó. - -2. Tạo một bucket S3 mới; tuân thủ mẫu đặt tên mà bạn đã sử dụng trong Phần 1, nhưng thêm '-2' vào tên. Để các trường khác là mặc định và nhấp vào **Create**. - -![create bucket](/images/5-Workshop/5.5-Policy/create-bucket.png) - -3. Tạo bucket thành công. - -![Success](/images/5-Workshop/5.5-Policy/create-bucket-success.png) - -Policy mặc định cho phép truy cập vào tất cả các S3 Buckets thông qua VPC endpoint. - -4. Trong giao diện **Edit Policy**, sao chép và dán theo policy sau, thay thế yourbucketname-2 với tên bucket thứ hai của bạn. Policy này sẽ cho phép truy cập đến bucket mới thông qua VPC endpoint, nhưng không cho phép truy cập đến các bucket còn lại. Chọn **Save** để kích hoạt policy. - - -``` -{ - "Id": "Policy1631305502445", - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "Stmt1631305501021", - "Action": "s3:*", - "Effect": "Allow", - "Resource": [ - "arn:aws:s3:::yourbucketname-2", - "arn:aws:s3:::yourbucketname-2/*" - ], - "Principal": "*" - } - ] -} -``` - -![custom policy](/images/5-Workshop/5.5-Policy/policy2.png) - -Cấu hình policy thành công. - -![success](/images/5-Workshop/5.5-Policy/success.png) - -5. Từ session của bạn trên Test-Gateway-Endpoint instance, kiểm tra truy cập đến S3 bucket bạn tạo ở bước đầu - -``` -aws s3 ls s3:// -``` - -Câu lệnh trả về lỗi bởi vì truy cập vào S3 bucket không có quyền trong VPC endpoint policy. - -![error](/images/5-Workshop/5.5-Policy/error.png) - -6. Trở lại home directory của bạn trên EC2 instance ```cd~``` - -+ Tạo file ```fallocate -l 1G test-bucket2.xyz ``` -+ Sao chép file lên bucket thứ 2 ```aws s3 cp test-bucket2.xyz s3://``` - -![success](/images/5-Workshop/5.5-Policy/test2.png) - -Thao tác này được cho phép bởi VPC endpoint policy. - -![success](/images/5-Workshop/5.5-Policy/test2-success.png) - -Sau đó chúng ta kiểm tra truy cập vào S3 bucket đầu tiên - - ```aws s3 cp test-bucket2.xyz s3://``` - - ![fail](/images/5-Workshop/5.5-Policy/test2-fail.png) - - Câu lệnh xảy ra lỗi bởi vì bucket không có quyền truy cập bởi VPC endpoint policy. - -Trong phần này, bạn đã tạo chính sách VPC Endpoint cho Amazon S3 và sử dụng AWS CLI để kiểm tra chính sách. Các hoạt động AWS CLI liên quan đến bucket S3 ban đầu của bạn thất bại vì bạn áp dụng một chính sách chỉ cho phép truy cập đến bucket thứ hai mà bạn đã tạo. Các hoạt động AWS CLI nhắm vào bucket thứ hai của bạn thành công vì chính sách cho phép chúng. Những chính sách này có thể hữu ích trong các tình huống khi bạn cần kiểm soát quyền truy cập vào tài nguyên thông qua VPC Endpoint. diff --git a/content/5-Workshop/5.6-Cleanup/_index.md b/content/5-Workshop/5.6-Cleanup/_index.md deleted file mode 100644 index e08b160..0000000 --- a/content/5-Workshop/5.6-Cleanup/_index.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title : "Clean up" -date : 2024-01-01 -weight : 6 -chapter : false -pre : " 5.6. " ---- -Congratulations on completing this workshop! -In this workshop, you learned architecture patterns for accessing Amazon S3 without using the Public Internet. -+ By creating a gateway endpoint, you enabled direct communication between EC2 resources and Amazon S3, without traversing an Internet Gateway. -+ By creating an interface endpoint you extended S3 connectivity to resources running in your on-premises data center via AWS Site-to-Site VPN or Direct Connect. - -#### clean up -1. Navigate to Hosted Zones on the left side of Route 53 console. Click the name of *s3.us-east-1.amazonaws.com* zone. Click Delete and confirm deletion by typing delete. - -![hosted zone](/images/5-Workshop/5.6-Cleanup/delete-zone.png) - -2. Disassociate the Route 53 Resolver Rule - myS3Rule from "VPC Onprem" and Delete it. - -![hosted zone](/images/5-Workshop/5.6-Cleanup/vpc.png) - -4. Open the CloudFormation console and delete the two CloudFormation Stacks that you created for this lab: -+ PLOnpremSetup -+ PLCloudSetup - -![delete stack](/images/5-Workshop/5.6-Cleanup/delete-stack.png) - -5. Delete S3 buckets -+ Open S3 console -+ Choose the bucket we created for the lab, click and confirm empty. Click delete and confirm delete. - -![delete s3](/images/5-Workshop/5.6-Cleanup/delete-s3.png) \ No newline at end of file diff --git a/content/5-Workshop/5.6-Cleanup/_index.vi.md b/content/5-Workshop/5.6-Cleanup/_index.vi.md deleted file mode 100644 index 75cf0bd..0000000 --- a/content/5-Workshop/5.6-Cleanup/_index.vi.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title : "Dọn dẹp tài nguyên" -date : 2024-01-01 -weight : 6 -chapter : false -pre : " 5.6. " ---- - -#### Dọn dẹp tài nguyên - -Xin chúc mừng bạn đã hoàn thành xong lab này! -Trong lab này, bạn đã học về các mô hình kiến trúc để truy cập Amazon S3 mà không sử dụng Public Internet. - -+ Bằng cách tạo Gateway endpoint, bạn đã cho phép giao tiếp trực tiếp giữa các tài nguyên EC2 và Amazon S3, mà không đi qua Internet Gateway. -Bằng cách tạo Interface endpoint, bạn đã mở rộng kết nối S3 đến các tài nguyên chạy trên trung tâm dữ liệu trên chỗ của bạn thông qua AWS Site-to-Site VPN hoặc Direct Connect. - -#### Dọn dẹp -1. Điều hướng đến Hosted Zones trên phía trái của bảng điều khiển Route 53. Nhấp vào tên của s3.us-east-1.amazonaws.com zone. Nhấp vào Delete và xác nhận việc xóa bằng cách nhập từ khóa "delete". - -![hosted zone](/images/5-Workshop/5.6-Cleanup/delete-zone.png) - -2. Disassociate Route 53 Resolver Rule - myS3Rule from "VPC Onprem" and Delete it. - -![hosted zone](/images/5-Workshop/5.6-Cleanup/vpc.png) - -4.Mở console của CloudFormation và xóa hai stack CloudFormation mà bạn đã tạo cho bài thực hành này: -+ PLOnpremSetup -+ PLCloudSetup - -![delete stack](/images/5-Workshop/5.6-Cleanup/delete-stack.png) - -5. Xóa các S3 bucket - -+ Mở bảng điều khiển S3 -+ Chọn bucket chúng ta đã tạo cho lab, nhấp chuột và xác nhận là empty. Nhấp Delete và xác nhận delete. -+ -![delete s3](/images/5-Workshop/5.6-Cleanup/delete-s3.png) \ No newline at end of file diff --git a/content/5-Workshop/_index.md b/content/5-Workshop/_index.md index 99a674f..cc604eb 100644 --- a/content/5-Workshop/_index.md +++ b/content/5-Workshop/_index.md @@ -1,31 +1,30 @@ --- title: "Workshop" -date: 2024-01-01 +date: 2026-04-20 weight: 5 chapter: false pre: " 5. " --- -{{% notice warning %}} -⚠️ **Note:** The information below is for reference purposes only. Please **do not copy verbatim** for your report, including this warning. -{{% /notice %}} -# Secure Hybrid Access to S3 using VPC Endpoints +# DocuFlow AI - Building a Serverless Invoice & Receipt Processing Platform #### Overview -**AWS PrivateLink** provides private connectivity to AWS services from VPCs and your on-premises networks, without exposing your traffic to the Public Internet. +This workshop builds **DocuFlow AI**, a serverless platform that lets authenticated users upload invoices and receipts, then automatically extracts financial fields using Amazon Textract and Amazon Bedrock. The result is stored, tracked by status, and surfaced in a web dashboard with a manual review loop for low-confidence documents. -In this lab, you will learn how to create, configure, and test VPC endpoints that enable your workloads to reach AWS services without traversing the Public Internet. +You will build the system incrementally, one module at a time. Each module adds resources to a single AWS SAM stack deployed in `ap-southeast-1` (Singapore), so the platform grows from an empty template to a complete event-driven pipeline. -You will create two types of endpoints to access Amazon S3: a Gateway VPC endpoint, and an Interface VPC endpoint. These two types of VPC endpoints offer different benefits depending on if you are accessing Amazon S3 from the cloud or your on-premises location -+ **Gateway** - Create a gateway endpoint to send traffic to Amazon S3 or DynamoDB using private IP addresses.You route traffic from your VPC to the gateway endpoint using route tables. -+ **Interface** - Create an interface endpoint to send traffic to endpoint services that use a Network Load Balancer to distribute traffic. Traffic destined for the endpoint service is resolved using DNS. +#### Architecture + +The platform uses a serverless, event-driven architecture: Amazon Cognito for auth, Amazon S3 + CloudFront for the frontend, API Gateway and Lambda for the API, EventBridge and SQS for ingestion, Step Functions for orchestration, Textract and Bedrock for AI extraction, DynamoDB for metadata, and CloudWatch and SNS for observability. #### Content -1. [Workshop overview](5.1-Workshop-overview) -2. [Prerequiste](5.2-Prerequiste/) -3. [Access S3 from VPC](5.3-S3-vpc/) -4. [Access S3 from On-premises](5.4-S3-onprem/) -5. [VPC Endpoint Policies (Bonus)](5.5-Policy/) -6. [Clean up](5.6-Cleanup/) \ No newline at end of file +1. [Workshop Overview](5.1-Workshop-overview/) +2. [Prerequisites](5.2-Prerequisite/) +3. [Frontend, Auth, and Upload](5.3-Frontend-Auth-Upload/) +4. [Storage, Ingestion, and Workflow](5.4-Storage-Ingestion-Workflow/) +5. [AI Extraction with Bedrock](5.5-AI-Extraction-Bedrock/) +6. [Data, Result, and Review](5.6-Data-Result-Review/) +7. [Observability and Security](5.7-Observability-Security/) +8. [Cleanup](5.8-Cleanup/) diff --git a/content/5-Workshop/_index.vi.md b/content/5-Workshop/_index.vi.md index 05838e8..1fd003c 100644 --- a/content/5-Workshop/_index.vi.md +++ b/content/5-Workshop/_index.vi.md @@ -1,33 +1,30 @@ --- title: "Workshop" -date: 2024-01-01 +date: 2026-04-20 weight: 5 chapter: false pre: " 5. " --- -{{% notice warning %}} -⚠️ **Lưu ý:** Các thông tin dưới đây chỉ nhằm mục đích tham khảo, vui lòng **không sao chép nguyên văn** cho bài báo cáo của bạn kể cả warning này. -{{% /notice %}} - - -# Đảm bảo truy cập Hybrid an toàn đến S3 bằng cách sử dụng VPC endpoint +# DocuFlow AI - Xây dựng nền tảng xử lý invoice & receipt serverless #### Tổng quan -**AWS PrivateLink** cung cấp kết nối riêng tư đến các dịch vụ aws từ VPCs hoặc trung tâm dữ liệu (on-premise) mà không làm lộ lưu lượng truy cập ra ngoài public internet. +Workshop này xây dựng **DocuFlow AI**, một nền tảng serverless cho phép người dùng đã đăng nhập upload invoice và receipt, sau đó tự động trích xuất dữ liệu tài chính bằng Amazon Textract và Amazon Bedrock. Kết quả được lưu lại, theo dõi theo status và hiển thị trên dashboard web kèm review loop thủ công cho tài liệu có confidence thấp. + +Bạn sẽ xây hệ thống theo từng bước, mỗi module một phần. Mỗi module thêm resource vào một AWS SAM stack duy nhất deploy ở `ap-southeast-1` (Singapore), nên nền tảng lớn dần từ một template rỗng thành một pipeline event-driven hoàn chỉnh. -Trong bài lab này, chúng ta sẽ học cách tạo, cấu hình, và kiểm tra VPC endpoints để cho phép workload của bạn tiếp cận các dịch vụ AWS mà không cần đi qua Internet công cộng. +#### Kiến trúc -Chúng ta sẽ tạo hai loại endpoints để truy cập đến Amazon S3: gateway vpc endpoint và interface vpc endpoint. Hai loại vpc endpoints này mang đến nhiều lợi ích tùy thuộc vào việc bạn truy cập đến S3 từ môi trường cloud hay từ trung tâm dữ liệu (on-premise). -+ **Gateway** - Tạo gateway endpoint để gửi lưu lượng đến Amazon S3 hoặc DynamoDB using private IP addresses. Bạn điều hướng lưu lượng từ VPC của bạn đến gateway endpoint bằng các bảng định tuyến (route tables) -+ **Interface** - Tạo interface endpoint để gửi lưu lượng đến các dịch vụ điểm cuối (endpoints) sử dụng Network Load Balancer để phân phối lưu lượng. Lưu lượng dành cho dịch vụ điểm cuối được resolved bằng DNS. +Nền tảng dùng kiến trúc serverless, event-driven: Amazon Cognito cho auth, Amazon S3 + CloudFront cho frontend, API Gateway và Lambda cho API, EventBridge và SQS cho ingestion, Step Functions để điều phối, Textract và Bedrock cho AI extraction, DynamoDB cho metadata, và CloudWatch cùng SNS cho observability. #### Nội dung -1. [Tổng quan về workshop](5.1-Workshop-overview/) -2. [Chuẩn bị](5.2-Prerequiste/) -3. [Truy cập đến S3 từ VPC](5.3-S3-vpc/) -4. [Truy cập đến S3 từ TTDL On-premises](5.4-S3-onprem/) -5. [VPC Endpoint Policies (làm thêm)](5.5-Policy/) -6. [Dọn dẹp tài nguyên](5.6-Cleanup/) \ No newline at end of file +1. [Tổng quan Workshop](5.1-Workshop-overview/) +2. [Chuẩn bị](5.2-Prerequisite/) +3. [Frontend, Auth và Upload](5.3-Frontend-Auth-Upload/) +4. [Storage, Ingestion và Workflow](5.4-Storage-Ingestion-Workflow/) +5. [AI Extraction với Bedrock](5.5-AI-Extraction-Bedrock/) +6. [Data, Result và Review](5.6-Data-Result-Review/) +7. [Observability và Security](5.7-Observability-Security/) +8. [Cleanup](5.8-Cleanup/) diff --git a/content/7-Feedback/_index.md b/content/7-Feedback/_index.md index 30b62c6..b908265 100644 --- a/content/7-Feedback/_index.md +++ b/content/7-Feedback/_index.md @@ -6,42 +6,41 @@ chapter: false pre: " 7. " --- -{{% notice warning %}} -⚠️ **Note:** The information below is for reference purposes only. Please **do not copy verbatim** for your report, including this warning. -{{% /notice %}} - -> Here, you can freely share your personal opinions about your experience participating in the First Cloud Journey program. This will help the FCJ team improve any shortcomings based on the following aspects: +The following comments reflect my personal experience during the **First Cloud AI Journey** program. I hope this feedback can help the program continue improving the learning and hands-on experience for future interns. ### Overall Evaluation **1. Working Environment** -The working environment is very friendly and open. FCJ members are always willing to help whenever I encounter difficulties, even outside working hours. The workspace is tidy and comfortable, helping me focus better. However, I think it would be nice to have more social gatherings or team bonding activities to strengthen relationships. +The First Cloud Journey learning and working environment emphasizes self-direction. Instead of learning theory alone, I was expected to read documentation, complete workshops, test my deployments, and clean up AWS resources. This approach strengthened my independent research skills and made me more responsible for my own progress. **2. Support from Mentor / Team Admin** -The mentor provides very detailed guidance, explains clearly when I don’t understand, and always encourages me to ask questions. The admin team supports administrative tasks, provides necessary documents, and creates favorable conditions for me to work effectively. I especially appreciate that the mentor allows me to try and solve problems myself instead of just giving the answer. +The program roadmap and learning resources helped me identify what to study at each stage. Review milestones covering the idea, architecture, implementation, and workshop allowed me to receive feedback and adjust the project step by step. While developing DocuFlow AI, I had room to analyze problems and experiment independently while also using clear deliverable criteria to review my work before submitting it. **3. Relevance of Work to Academic Major** -The tasks I was assigned align well with the knowledge I learned at university, while also introducing me to new areas I had never encountered before. This allowed me to both strengthen my foundational knowledge and gain practical skills. +The internship content was relevant to my Information Technology major. My foundational knowledge of programming, networking, databases, and security was extended through practical AWS work. In particular, designing DocuFlow AI helped me connect software development with cloud architecture, security, cost, and operational considerations. **4. Learning & Skill Development Opportunities** -During the internship, I learned many new skills such as using project management tools, teamwork skills, and professional communication in a corporate environment. The mentor also shared valuable real-world experiences that helped me better plan my career path. +The program provided extensive hands-on opportunities with the AWS Management Console, AWS CLI, and services across multiple domains, including IAM, VPC, S3, EC2, Lambda, DynamoDB, KMS, and Security Hub. Beyond technical skills, I improved my ability to read documentation, analyze risks, estimate costs, write proposals, and present a structured technical solution. **5. Company Culture & Team Spirit** -The company culture is very positive: everyone respects each other, works seriously but still keeps things enjoyable. When there are urgent projects, everyone works together and supports one another regardless of their position. This made me feel like a real part of the team, even as an intern. +I value the knowledge-sharing culture represented by the workshop system, AWS Study Group materials, and community activities. Participating in events and researching my project exposed me to more perspectives on cloud and AI. The program could add more peer review sessions where interns share their progress, challenges, and lessons learned from their projects. **6. Internship Policies / Benefits** -The company provides an internship allowance and offers flexible working hours when needed. In addition, having the opportunity to join internal training sessions is a big plus. +The program provides an internship roadmap, workshop resources, and opportunities to participate in AWS-related learning activities. Its flexible and self-directed structure allowed me to balance studying, hands-on practice, and project development. The shared checklist for the proposal, architecture diagram, source code, test evidence, workshop, and resource cleanup helped me track all required deliverables and avoid overlooking important requirements. --- ### Additional Questions -- What did you find **most satisfying** during your internship? -- What do you think the company **should improve** for future interns? -- If recommending to a friend, would you **suggest they intern here**? Why or why not? ---- +**What I found most satisfying:** I was able to learn through hands-on work and apply that knowledge to a concrete project. Revising the DocuFlow AI architecture from a mandatory Amazon Bedrock dependency to an External AI Adapter taught me that a good solution must not only be technically sound but also fit access constraints, cost limits, and the deployment context. + +**What the program could improve:** Now that clear checklists and review milestones are in place, the program could add more real-world case analysis sessions. Topics such as incident response, system monitoring, cost optimization, and post-deployment security reviews would help interns understand the gap between completing a lab and operating a system in practice. + +**Whether I would recommend the program:** I would recommend First Cloud AI Journey to friends who are interested in cloud computing and AWS. It is particularly suitable for learners who want hands-on experience and are prepared to proactively read documentation, experiment, and solve problems. ### Suggestions & Expectations -- Do you have any suggestions to improve the internship experience? -- Would you like to continue this program in the future? -- Any other comments (free sharing): + +* Continue maintaining the existing project demo and technical sharing events, as they provide valuable opportunities to learn from the architecture, technical decisions, challenges, and practical experience of other participants. +* Add case studies on post-deployment operations, including observability, incident response, security reviews, and FinOps. +* Offer optional guidance sessions on career paths, AWS certifications, and how interns can continue developing their portfolios after the program. +* I would like to continue learning about serverless architecture, cloud security, observability, and operating AWS systems in real environments. If possible, I would also like to continue developing DocuFlow AI into a product that can be deployed and evaluated end to end. diff --git a/content/7-Feedback/_index.vi.md b/content/7-Feedback/_index.vi.md index 610e8a7..e81b911 100644 --- a/content/7-Feedback/_index.vi.md +++ b/content/7-Feedback/_index.vi.md @@ -5,40 +5,42 @@ weight: 7 chapter: false pre: " 7. " --- -{{% notice warning %}} -⚠️ **Lưu ý:** Các thông tin dưới đây chỉ nhằm mục đích tham khảo, vui lòng **không sao chép nguyên văn** cho bài báo cáo của bạn kể cả warning này. -{{% /notice %}} ->Tại đây bạn có thể tự do đóng góp ý kiến cá nhân về những trải nghiệm khi tham gia chương trình First Cloud Journey, giúp team FCJ cải thiện những vấn đề còn thiếu sót dựa trên các hạng mục sau: +Những chia sẻ dưới đây phản ánh trải nghiệm cá nhân của mình trong quá trình tham gia chương trình **First Cloud AI Journey**. Mình hy vọng các nhận xét này có thể góp phần giúp chương trình tiếp tục hoàn thiện trải nghiệm học tập và thực hành cho các thực tập sinh sau này. ### Đánh giá chung **1. Môi trường làm việc** -Môi trường làm việc rất thân thiện và cởi mở. Các thành viên trong FCJ luôn sẵn sàng hỗ trợ khi mình gặp khó khăn, kể cả ngoài giờ làm việc. Không gian làm việc gọn gàng, thoải mái, giúp mình tập trung tốt hơn. Tuy nhiên, mình nghĩ có thể bổ sung thêm một số buổi giao lưu hoặc team bonding để mọi người hiểu nhau hơn. +Môi trường học tập và thực hành của First Cloud AI Journey đề cao tính chủ động. Mình không chỉ học lý thuyết mà còn phải tự đọc tài liệu, triển khai workshop, kiểm thử và cleanup tài nguyên AWS. Cách học này giúp mình rèn luyện khả năng tự nghiên cứu và chịu trách nhiệm với tiến độ công việc của mình. **2. Sự hỗ trợ của mentor / team admin** -Mentor hướng dẫn rất chi tiết, giải thích rõ ràng khi mình chưa hiểu và luôn khuyến khích mình đặt câu hỏi. Team admin hỗ trợ các thủ tục, tài liệu và tạo điều kiện để mình làm việc thuận lợi. Mình đánh giá cao việc mentor cho phép mình thử và tự xử lý vấn đề thay vì chỉ đưa đáp án. +Lộ trình và nguồn tài liệu của chương trình đã giúp mình xác định được những nội dung cần học theo từng giai đoạn. Các mốc review từ ý tưởng, kiến trúc, bản triển khai đến workshop giúp mình nhận phản hồi và điều chỉnh dự án theo từng bước. Khi xây dựng DocuFlow AI, mình vừa có không gian tự phân tích và thử nghiệm giải pháp, vừa có tiêu chí đầu ra để tự kiểm tra trước khi gửi review. **3. Sự phù hợp giữa công việc và chuyên ngành học** -Công việc mình được giao phù hợp với kiến thức mình đã học ở trường, đồng thời mở rộng thêm những mảng mới mà mình chưa từng được tiếp cận. Nhờ vậy, mình vừa củng cố kiến thức nền tảng, vừa học thêm kỹ năng thực tế. +Nội dung thực tập phù hợp với chuyên ngành Công nghệ thông tin của mình. Các kiến thức nền tảng về lập trình, mạng, cơ sở dữ liệu và bảo mật được mở rộng qua việc thực hành trên AWS. Đặc biệt, quá trình thiết kế DocuFlow AI giúp mình kết nối kiến thức phát triển phần mềm với kiến trúc cloud, bảo mật, chi phí và khả năng vận hành. **4. Cơ hội học hỏi & phát triển kỹ năng** -Trong quá trình thực tập, mình học được nhiều kỹ năng mới như sử dụng công cụ quản lý dự án, kỹ năng làm việc nhóm, và cả cách giao tiếp chuyên nghiệp trong môi trường công ty. Mentor cũng chia sẻ nhiều kinh nghiệm thực tế giúp mình định hướng tốt hơn cho sự nghiệp. +Chương trình mang lại nhiều cơ hội thực hành với AWS Management Console, AWS CLI và các dịch vụ thuộc nhiều nhóm khác nhau như IAM, VPC, S3, EC2, Lambda, DynamoDB, KMS và Security Hub. Bên cạnh kỹ năng kỹ thuật, mình còn cải thiện khả năng đọc tài liệu, phân tích rủi ro, ước tính chi phí, viết proposal và trình bày một giải pháp kỹ thuật có cấu trúc. **5. Văn hóa & tinh thần đồng đội** -Văn hóa công ty rất tích cực: mọi người tôn trọng lẫn nhau, làm việc nghiêm túc nhưng vẫn vui vẻ. Khi có dự án gấp, mọi người cùng nhau cố gắng, hỗ trợ không phân biệt vị trí. Điều này giúp mình cảm thấy mình là một phần của tập thể, dù chỉ là thực tập sinh. +Mình đánh giá cao tinh thần chia sẻ kiến thức thông qua hệ thống workshop, tài liệu AWS Study Group và các hoạt động cộng đồng. Việc tham gia các sự kiện và nghiên cứu dự án giúp mình tiếp cận thêm nhiều góc nhìn về cloud và AI. Chương trình có thể tăng thêm các buổi trao đổi chéo giữa thực tập sinh để mọi người chia sẻ tiến độ, vướng mắc và bài học từ dự án của mình. **6. Chính sách / phúc lợi cho thực tập sinh** -Công ty có hỗ trợ phụ cấp thực tập và tạo điều kiện về thời gian linh hoạt khi cần thiết. Ngoài ra, việc được tham gia các buổi đào tạo nội bộ là một điểm cộng lớn. +Chương trình cung cấp lộ trình thực tập, nguồn workshop và cơ hội tham gia các hoạt động học tập liên quan đến AWS. Tính chủ động và linh hoạt giúp mình có thể sắp xếp việc học, thực hành và phát triển dự án. Checklist chung cho proposal, sơ đồ kiến trúc, source code, bằng chứng kiểm thử, workshop và cleanup giúp mình theo dõi đầy đủ các đầu ra và hạn chế bỏ sót những yêu cầu quan trọng. ### Một số câu hỏi khác -- Điều bạn **hài lòng nhất** trong thời gian thực tập? -- Điều bạn nghĩ công ty **cần cải thiện** cho các thực tập sinh sau? -- Nếu giới thiệu cho bạn bè, bạn có **khuyên họ thực tập ở đây không**? Vì sao? + +**Điều mình hài lòng nhất:** Mình được học theo hướng thực hành và áp dụng kiến thức vào một dự án cụ thể. Quá trình chuyển kiến trúc DocuFlow AI từ phụ thuộc Amazon Bedrock sang mô hình External AI Adapter giúp mình hiểu rằng một giải pháp tốt không chỉ đúng về kỹ thuật mà còn phải phù hợp với quyền truy cập, chi phí và bối cảnh triển khai. + +**Điều chương trình có thể cải thiện:** Sau khi đã có checklist và các mốc review rõ ràng, chương trình có thể bổ sung thêm các buổi phân tích tình huống thực tế. Các chủ đề như xử lý sự cố, giám sát hệ thống, tối ưu chi phí và đánh giá bảo mật sau triển khai sẽ giúp thực tập sinh hiểu rõ hơn khoảng cách giữa một bài lab hoàn chỉnh và một hệ thống được vận hành trong thực tế. + +**Khả năng giới thiệu chương trình:** Mình sẵn sàng giới thiệu First Cloud AI Journey cho những bạn quan tâm đến cloud và AWS. Chương trình phù hợp với những người muốn tích lũy kinh nghiệm thực hành và sẵn sàng chủ động đọc tài liệu, thử nghiệm và xử lý vấn đề. ### Đề xuất & mong muốn -- Bạn có đề xuất gì để cải thiện trải nghiệm trong kỳ thực tập? -- Bạn có muốn tiếp tục chương trình này trong tương lai? -- Góp ý khác (tự do chia sẻ): \ No newline at end of file + +* Tiếp tục duy trì các event demo và chia sẻ kỹ thuật, vì đây là cơ hội hữu ích để mình học từ kiến trúc, quyết định kỹ thuật, vấn đề và kinh nghiệm thực tế của những người tham gia. +* Bổ sung một số case study về vận hành hệ thống sau triển khai, bao gồm observability, incident response, security review và FinOps. +* Có thêm các buổi định hướng tự chọn về lộ trình nghề nghiệp, chứng chỉ AWS và cách tiếp tục phát triển portfolio sau chương trình. +* Mình mong muốn tiếp tục học sâu hơn về kiến trúc serverless, cloud security, observability và vận hành hệ thống AWS trong môi trường thực tế. Nếu có cơ hội, mình cũng muốn tiếp tục hoàn thiện DocuFlow AI thành một sản phẩm có thể triển khai và đánh giá end-to-end. diff --git a/content/_index.md b/content/_index.md index 96fb12e..f929c46 100644 --- a/content/_index.md +++ b/content/_index.md @@ -13,7 +13,7 @@ chapter: false {{% /notice %}} --> ### Student Information: -  **Full Name:** Tra Hoang Trong +  **Full Name:** Hoang Trong Tra   **Phone Number:** 0842366570 diff --git a/static/images/2-Proposal/docuflow_external_ai_architecture.svg b/static/images/2-Proposal/docuflow_external_ai_architecture.svg new file mode 100644 index 0000000..688194f --- /dev/null +++ b/static/images/2-Proposal/docuflow_external_ai_architecture.svg @@ -0,0 +1,80 @@ + + API Gateway + Protected REST API + + Lambda + Generate upload URL + + S3 Raw + Private uploads + + + + + + + EventBridge + Object created event + + SQS + Queue + DLQ + + Lambda + Start processing + + + + + Step Functions Standard Workflow + + Validate + type + size + + Textract + AnalyzeExpense + + External AI + Normalize + classify + + Validate + JSON schema + + Save + metadata + JSON + + Review / Failed + + + + + + + + Secrets Manager + or SSM Parameter Store + + + DynamoDB + status + metadata + + S3 Processed + normalized JSON + + + + CloudWatch + logs + metrics + alarms + + SNS/SES + failed / low confidence + + + + Optional analytics + S3 Processed JSON -> Glue Crawler -> Athena -> QuickSight dashboard + Enable only after the core MVP is stable and the budget is updated. + + Security rule + External AI payload = Textract summary fields + line items + short text preview. + Do not send raw PDF/image files, API keys, AWS credentials, or unrelated sensitive fields. + \ No newline at end of file diff --git a/static/images/2-Proposal/docuflow_high_level_architecture.png b/static/images/2-Proposal/docuflow_high_level_architecture.png new file mode 100644 index 0000000..3ab5b29 Binary files /dev/null and b/static/images/2-Proposal/docuflow_high_level_architecture.png differ diff --git a/static/images/3-BlogsTranslated/Blog1/IsolatedRecoveryEnvironment(IRE).png b/static/images/3-BlogsTranslated/Blog1/IsolatedRecoveryEnvironment(IRE).png new file mode 100644 index 0000000..a8412b8 Binary files /dev/null and b/static/images/3-BlogsTranslated/Blog1/IsolatedRecoveryEnvironment(IRE).png differ diff --git a/static/images/3-BlogsTranslated/Blog1/Recovery_workflow.jpg b/static/images/3-BlogsTranslated/Blog1/Recovery_workflow.jpg new file mode 100644 index 0000000..21f9803 Binary files /dev/null and b/static/images/3-BlogsTranslated/Blog1/Recovery_workflow.jpg differ diff --git a/static/images/3-BlogsTranslated/Blog1/Selecting_a_safe_recovery_point.png b/static/images/3-BlogsTranslated/Blog1/Selecting_a_safe_recovery_point.png new file mode 100644 index 0000000..5c0d395 Binary files /dev/null and b/static/images/3-BlogsTranslated/Blog1/Selecting_a_safe_recovery_point.png differ diff --git a/static/images/3-BlogsTranslated/Blog2/Multi-account_patch_compliance_dashboard_generated_by_the_spec_workflow.png b/static/images/3-BlogsTranslated/Blog2/Multi-account_patch_compliance_dashboard_generated_by_the_spec_workflow.png new file mode 100644 index 0000000..bd2efa3 Binary files /dev/null and b/static/images/3-BlogsTranslated/Blog2/Multi-account_patch_compliance_dashboard_generated_by_the_spec_workflow.png differ diff --git a/static/images/4-EventParticipated/event-1/memory.jpg b/static/images/4-EventParticipated/event-1/memory.jpg new file mode 100644 index 0000000..68c4785 Binary files /dev/null and b/static/images/4-EventParticipated/event-1/memory.jpg differ diff --git a/static/images/4-EventParticipated/event-1/speaker-khangnguyen.jpg b/static/images/4-EventParticipated/event-1/speaker-khangnguyen.jpg new file mode 100644 index 0000000..c5d0afc Binary files /dev/null and b/static/images/4-EventParticipated/event-1/speaker-khangnguyen.jpg differ diff --git a/static/images/4-EventParticipated/event-1/speaker-longhoang.jpg b/static/images/4-EventParticipated/event-1/speaker-longhoang.jpg new file mode 100644 index 0000000..c1cf023 Binary files /dev/null and b/static/images/4-EventParticipated/event-1/speaker-longhoang.jpg differ diff --git a/static/images/4-EventParticipated/event-1/speaker-thaonguyen.jpg b/static/images/4-EventParticipated/event-1/speaker-thaonguyen.jpg new file mode 100644 index 0000000..4c3caa3 Binary files /dev/null and b/static/images/4-EventParticipated/event-1/speaker-thaonguyen.jpg differ diff --git a/static/images/4-EventParticipated/event-1/speaker-thiennguyen.jpg b/static/images/4-EventParticipated/event-1/speaker-thiennguyen.jpg new file mode 100644 index 0000000..7b39274 Binary files /dev/null and b/static/images/4-EventParticipated/event-1/speaker-thiennguyen.jpg differ diff --git a/static/images/4-EventParticipated/event-2/AnhPham.jpg b/static/images/4-EventParticipated/event-2/AnhPham.jpg new file mode 100644 index 0000000..27e503d Binary files /dev/null and b/static/images/4-EventParticipated/event-2/AnhPham.jpg differ diff --git a/static/images/4-EventParticipated/event-2/DucDao.jpg b/static/images/4-EventParticipated/event-2/DucDao.jpg new file mode 100644 index 0000000..b2837c6 Binary files /dev/null and b/static/images/4-EventParticipated/event-2/DucDao.jpg differ diff --git a/static/images/4-EventParticipated/event-2/NguyenGiaHung.jpg b/static/images/4-EventParticipated/event-2/NguyenGiaHung.jpg new file mode 100644 index 0000000..671e955 Binary files /dev/null and b/static/images/4-EventParticipated/event-2/NguyenGiaHung.jpg differ diff --git a/static/images/4-EventParticipated/event-2/ThinhNguyen.jpg b/static/images/4-EventParticipated/event-2/ThinhNguyen.jpg new file mode 100644 index 0000000..daba2db Binary files /dev/null and b/static/images/4-EventParticipated/event-2/ThinhNguyen.jpg differ diff --git a/static/images/4-EventParticipated/event-2/TinhTruong.jpg b/static/images/4-EventParticipated/event-2/TinhTruong.jpg new file mode 100644 index 0000000..af1533d Binary files /dev/null and b/static/images/4-EventParticipated/event-2/TinhTruong.jpg differ diff --git a/static/images/4-EventParticipated/event-2/UyenLe-ThaoNguyen-MaiNguyen.jpg b/static/images/4-EventParticipated/event-2/UyenLe-ThaoNguyen-MaiNguyen.jpg new file mode 100644 index 0000000..ccfa40d Binary files /dev/null and b/static/images/4-EventParticipated/event-2/UyenLe-ThaoNguyen-MaiNguyen.jpg differ diff --git a/static/images/4-EventParticipated/event-2/VyLam.jpg b/static/images/4-EventParticipated/event-2/VyLam.jpg new file mode 100644 index 0000000..82d2172 Binary files /dev/null and b/static/images/4-EventParticipated/event-2/VyLam.jpg differ diff --git a/static/images/4-EventParticipated/event-2/fcaj-community.jpg b/static/images/4-EventParticipated/event-2/fcaj-community.jpg new file mode 100644 index 0000000..16d7c54 Binary files /dev/null and b/static/images/4-EventParticipated/event-2/fcaj-community.jpg differ diff --git a/static/images/4-EventParticipated/event-3/1780046299367.jpg b/static/images/4-EventParticipated/event-3/1780046299367.jpg new file mode 100644 index 0000000..6b3e5a8 Binary files /dev/null and b/static/images/4-EventParticipated/event-3/1780046299367.jpg differ diff --git a/static/images/4-EventParticipated/event-3/1780046308292.jpg b/static/images/4-EventParticipated/event-3/1780046308292.jpg new file mode 100644 index 0000000..b71663e Binary files /dev/null and b/static/images/4-EventParticipated/event-3/1780046308292.jpg differ diff --git a/static/images/4-EventParticipated/event-3/1780046311474.jpg b/static/images/4-EventParticipated/event-3/1780046311474.jpg new file mode 100644 index 0000000..6d2e53b Binary files /dev/null and b/static/images/4-EventParticipated/event-3/1780046311474.jpg differ diff --git a/static/images/4-EventParticipated/event-3/1780050160542.jpg b/static/images/4-EventParticipated/event-3/1780050160542.jpg new file mode 100644 index 0000000..2b0b464 Binary files /dev/null and b/static/images/4-EventParticipated/event-3/1780050160542.jpg differ diff --git a/static/images/4-EventParticipated/event-4/1781862217262.jpg b/static/images/4-EventParticipated/event-4/1781862217262.jpg new file mode 100644 index 0000000..bd8a522 Binary files /dev/null and b/static/images/4-EventParticipated/event-4/1781862217262.jpg differ diff --git a/static/images/4-EventParticipated/event-4/1781862219032.jpg b/static/images/4-EventParticipated/event-4/1781862219032.jpg new file mode 100644 index 0000000..b38676e Binary files /dev/null and b/static/images/4-EventParticipated/event-4/1781862219032.jpg differ diff --git a/static/images/4-EventParticipated/event-4/1781914266028.jpg b/static/images/4-EventParticipated/event-4/1781914266028.jpg new file mode 100644 index 0000000..7137011 Binary files /dev/null and b/static/images/4-EventParticipated/event-4/1781914266028.jpg differ diff --git a/static/images/4-EventParticipated/event-5/1782566925005.jpg b/static/images/4-EventParticipated/event-5/1782566925005.jpg new file mode 100644 index 0000000..ef3dca9 Binary files /dev/null and b/static/images/4-EventParticipated/event-5/1782566925005.jpg differ diff --git a/static/images/4-EventParticipated/event-5/1782566936888.jpg b/static/images/4-EventParticipated/event-5/1782566936888.jpg new file mode 100644 index 0000000..dffab25 Binary files /dev/null and b/static/images/4-EventParticipated/event-5/1782566936888.jpg differ diff --git a/static/images/4-EventParticipated/event-5/1782566938267.jpg b/static/images/4-EventParticipated/event-5/1782566938267.jpg new file mode 100644 index 0000000..3025153 Binary files /dev/null and b/static/images/4-EventParticipated/event-5/1782566938267.jpg differ diff --git a/static/images/4-EventParticipated/event-5/1782566945791.jpg b/static/images/4-EventParticipated/event-5/1782566945791.jpg new file mode 100644 index 0000000..94901cf Binary files /dev/null and b/static/images/4-EventParticipated/event-5/1782566945791.jpg differ diff --git a/static/images/4-EventParticipated/event-5/1782566947817.jpg b/static/images/4-EventParticipated/event-5/1782566947817.jpg new file mode 100644 index 0000000..d2431dd Binary files /dev/null and b/static/images/4-EventParticipated/event-5/1782566947817.jpg differ diff --git a/static/images/4-EventParticipated/event-5/1782566950117.jpg b/static/images/4-EventParticipated/event-5/1782566950117.jpg new file mode 100644 index 0000000..ebcd5b2 Binary files /dev/null and b/static/images/4-EventParticipated/event-5/1782566950117.jpg differ diff --git a/static/images/4-EventParticipated/event-5/1782566950779.jpg b/static/images/4-EventParticipated/event-5/1782566950779.jpg new file mode 100644 index 0000000..9a70633 Binary files /dev/null and b/static/images/4-EventParticipated/event-5/1782566950779.jpg differ diff --git a/static/images/4-EventParticipated/event-5/1782566951571.jpg b/static/images/4-EventParticipated/event-5/1782566951571.jpg new file mode 100644 index 0000000..a7b9dc7 Binary files /dev/null and b/static/images/4-EventParticipated/event-5/1782566951571.jpg differ diff --git a/static/images/4-EventParticipated/event-5/1782566951589.jpg b/static/images/4-EventParticipated/event-5/1782566951589.jpg new file mode 100644 index 0000000..4240fae Binary files /dev/null and b/static/images/4-EventParticipated/event-5/1782566951589.jpg differ diff --git a/static/images/4-EventParticipated/event-5/1782566953748.jpg b/static/images/4-EventParticipated/event-5/1782566953748.jpg new file mode 100644 index 0000000..1ca85ab Binary files /dev/null and b/static/images/4-EventParticipated/event-5/1782566953748.jpg differ diff --git a/static/images/4-EventParticipated/event-5/1782566953984.jpg b/static/images/4-EventParticipated/event-5/1782566953984.jpg new file mode 100644 index 0000000..719aa95 Binary files /dev/null and b/static/images/4-EventParticipated/event-5/1782566953984.jpg differ diff --git a/static/images/5-Workshop/5.1-Workshop-overview/docuflow_high_level_architecture.png b/static/images/5-Workshop/5.1-Workshop-overview/docuflow_high_level_architecture.png new file mode 100644 index 0000000..3ab5b29 Binary files /dev/null and b/static/images/5-Workshop/5.1-Workshop-overview/docuflow_high_level_architecture.png differ