blog-blueprint 0.0.2

package/BlueprintTemplate/public/assets/lessons/core/aws-sqs-guide.md

@@ -0,0 +1,173 @@
+# Amazon SQS: Hướng dẫn toàn diện về hàng đợi tin nhắn trên AWS
+
+**Amazon SQS (Simple Queue Service)** là dịch vụ quản lý hàng đợi tin nhắn (message queue) trên AWS.  
+
+Bạn có thể tưởng tượng SQS như một "hộp đựng phiếu" ở siêu thị:  
+- Người gửi bỏ phiếu vào hộp (Producer)  
+- Người nhận đến lấy phiếu khi rảnh và xử lý (Consumer)  
+- Hai bên không cần biết nhau, không phụ thuộc  
+
+---
+
+## 1. Khái niệm & Phân loại
+
+### Phân loại
+1. **Standard Queue**
+   - Throughput rất cao  
+   - Không đảm bảo thứ tự  
+   - “At-least-once delivery” (có thể trùng message)
+2. **FIFO Queue**
+   - Giữ đúng thứ tự gửi  
+   - “Exactly-once processing”  
+   - Throughput thấp hơn Standard Queue nhưng có trật tự
+
+---
+
+## 2. Thành phần chính
+
+| Thành phần | Mô tả |
+|------------|-------|
+| Queue | Nơi lưu message |
+| Message | Dữ liệu gửi (tối đa 256KB) |
+| Producer | Tạo và gửi message |
+| Consumer | Lấy message và xử lý |
+| Visibility Timeout | Thời gian message tạm bị ẩn để consumer xử lý |
+| Dead-Letter Queue (DLQ) | Chứa message lỗi quá số lần xử lý cho phép |
+| Message Retention | Thời gian lưu message (1 phút → 14 ngày) |
+| Long Polling | Giảm chi phí & tăng hiệu quả lấy message |
+
+---
+
+## 3. SQS dùng để làm gì?
+
+### Giải quyết vấn đề
+- Tách rời (decoupling) giữa các services → microservices bền vững hơn  
+- Xử lý không đồng bộ: hệ thống bận → message vẫn an toàn trong queue  
+- Không mất dữ liệu khi hạ tầng bị lỗi  
+- Ổn định tải (buffer) khi có spike traffic
+
+### Khi nên dùng
+- Khi cần buffer giữa các service  
+- Khi workload không cần xử lý ngay lập tức  
+- Khi cần tự động retry message lỗi  
+- Khi cần đảm bảo thứ tự xử lý → FIFO Queue
+
+### Khi không nên dùng
+- Cần push notification → dùng SNS  
+- Pub/sub nhiều subscriber → SNS hoặc EventBridge  
+- Real-time streaming → dùng Kinesis  
+- Workflow có logic điều hướng → dùng Step Functions
+
+---
+
+## 4. Ưu & Nhược điểm
+
+### Ưu điểm
+- Đảm bảo message không mất  
+- Tách rời producer – consumer  
+- Tự động retry bằng DLQ  
+- Chi phí thấp  
+- Scale gần như vô hạn  
+- Dễ tích hợp với Lambda và Auto Scaling
+
+### Nhược điểm
+- Không push, chỉ pull  
+- Consumer phải liên tục poll nếu không dùng long polling  
+- Không hỗ trợ routing theo rule phức tạp (EventBridge tốt hơn)  
+- FIFO throughput thấp hơn Standard Queue  
+- Không phù hợp cho real-time
+
+---
+
+## 5. So sánh với các dịch vụ tương tự
+
+| Dịch vụ | Dùng khi nào | Khác SQS |
+|---------|--------------|-----------|
+| SNS | Pub/sub, push | SNS không lưu message, không retry như queue |
+| EventBridge | Định tuyến sự kiện theo rule | EventBridge là event bus, SQS là queue |
+| Kinesis | Streaming lớn, analytics | Kinesis có shard, giữ data 1–7 ngày |
+| Kafka (MSK) | Streaming + pub/sub + event log | Kafka phức tạp hơn, SQS đơn giản hơn |
+
+**Mẹo thi SAA:**  
+- SNS = push, fan-out  
+- SQS = pull, queue  
+- EventBridge = router  
+- Kinesis = streaming
+
+---
+
+## 6. Luồng hoạt động
+
+1. Producer gửi message vào SQS  
+2. SQS lưu message bền vững (durable)  
+3. Consumer poll queue để nhận message  
+4. SQS ẩn message trong thời gian Visibility Timeout  
+5. Consumer xử lý:
+   - Nếu thành công → DeleteMessage  
+   - Nếu lỗi → message hiện lại → retry  
+6. Message retry quá nhiều lần → chuyển vào DLQ
+
+---
+
+## 7. Cách mở rộng (Scalability)
+
+- SQS tự động scale, không cấu hình  
+- Tạo nhiều consumer (EC2, ECS, Lambda) để xử lý nhanh hơn  
+- Dùng Auto Scaling theo metric:
+  - ApproximateNumberOfMessagesVisible  
+  - ApproximateAgeOfOldestMessage  
+- Kết hợp SNS → SQS fan-out để lưu nhiều phiên bản message
+
+---
+
+## 8. Cách bảo mật
+
+- IAM Policy giới hạn ai được gửi/nhận message  
+- Queue Access Policy cho phép cross-account hoặc SNS publish  
+- KMS encryption mã hóa message  
+- HTTPS cho API call  
+- VPC Endpoint để không đi Internet  
+- Client-side encryption (hiếm dùng)
+
+---
+
+## 9. SQS tích hợp với các dịch vụ
+
+- SNS (fan-out)  
+- Lambda (consumer event)  
+- ECS / EC2 Auto Scaling  
+- CloudWatch Alarm  
+- AWS Step Functions  
+- S3 events → SNS → SQS  
+- EventBridge → SQS (routing)
+
+---
+
+## 10. Kiến trúc thực tế sử dụng SQS
+
+1. **Decoupled Microservices**  
+   Service A → SQS → Service B
+
+2. **Fan-out Architecture**  
+   Event → SNS → N SQS queues → multiple consumers
+
+3. **Order Processing (FIFO)**  
+   Order API → SQS FIFO → Worker
+
+4. **Buffer cho hệ thống tải lớn**  
+   Website → SQS buffer → Batch processor
+
+5. **Xử lý ảnh/video async**  
+   S3 upload → Event → SQS → Lambda/EC2 worker
+
+---
+
+## 11. Sự cố thường gặp & cách xử lý
+
+| Sự cố | Cách xử lý |
+|-------|------------|
+| Message bị duplicate (Standard Queue) | Dùng FIFO nếu cần exactly-once, Idempotent consumer |
+| Visibility Timeout quá ngắn → message bị xử lý 2 lần | Tăng timeout, dùng ChangeMessageVisibility khi xử lý lâu |
+| Message bị đẩy vào DLQ quá nhanh | Kiểm tra logic xử lý, tăng maxReceiveCount, log chi tiết |
+| Consumer chạy quá chậm | Tăng số lượng consumer, dùng Auto Scaling, long polling |
+| Queue không nhận được message từ SNS | Kiểm tra Queue Policy có cho phép SNS gửi, kiểm tra KMS permission |

package/BlueprintTemplate/public/assets/lessons/core/aws-vpc-guide.md

@@ -0,0 +1,145 @@
+# Amazon VPC: Hướng dẫn toàn diện về mạng ảo trên AWS
+
+**Amazon VPC (Virtual Private Cloud)** là một mạng ảo riêng biệt trên AWS, nơi bạn có toàn quyền kiểm soát cấu hình mạng như địa chỉ IP, subnet, bảng định tuyến, firewall, NAT...  
+
+Bạn có thể hình dung VPC như một trung tâm dữ liệu riêng trong AWS, tự chia mạng, bảo vệ và kết nối theo ý mình.
+
+---
+
+## 1. Khái niệm & Phân loại
+
+- **Default VPC**: AWS tạo sẵn cho mỗi region, cấu hình cơ bản, dùng nhanh, phù hợp test/lab.  
+- **Custom VPC**: Tự tạo, tự thiết kế subnet, security, routing, dùng cho production.
+
+---
+
+## 2. Thành phần chính
+
+| Thành phần | Mô tả |
+|------------|-------|
+| Subnet | Chia VPC thành các vùng mạng nhỏ hơn (public/private) |
+| Route Table | Bảng định tuyến quyết định gói tin đi đâu |
+| Internet Gateway (IGW) | Kết nối subnet ra internet |
+| NAT Gateway/Instance | Cho private subnet đi ra ngoài internet (1 chiều) |
+| Security Group | Firewall cho instance, kiểm soát inbound/outbound |
+| Network ACL (NACL) | Firewall cho subnet, kiểm soát traffic vào/ra subnet |
+| Elastic IP | Địa chỉ IP tĩnh cho tài nguyên |
+| VPC Peering | Kết nối VPC với nhau |
+| Endpoints | Kết nối private tới dịch vụ AWS mà không cần internet |
+
+---
+
+## 3. VPC dùng để làm gì?
+
+### Mục đích
+- Tạo môi trường mạng riêng, an toàn, triển khai các tài nguyên (EC2, RDS, Lambda) theo nhu cầu bảo mật và kết nối.
+
+### Giải quyết vấn đề
+- Phân tách môi trường (prod/dev/test)  
+- Bảo mật (ai được truy cập, subnet nào ra internet)  
+- Kết nối với on-premise (VPN, Direct Connect)
+
+### Khi nên dùng
+- Triển khai ứng dụng cần kiểm soát mạng, bảo mật cao  
+- Có nhiều tầng (web/app/db) cần subnet riêng  
+- Kết nối hybrid/on-premise
+
+### Khi không nên dùng
+- Không cần kiểm soát mạng (dùng dịch vụ fully managed như S3, DynamoDB)  
+- Ứng dụng nhỏ, chỉ cần test nhanh
+
+---
+
+## 4. Ưu & Nhược điểm
+
+### Ưu điểm
+- Toàn quyền kiểm soát cấu hình mạng  
+- Bảo mật tốt  
+- Dễ mở rộng, tích hợp với nhiều dịch vụ  
+- Kết nối được với on-premise
+
+### Nhược điểm
+- Cấu hình phức tạp, dễ sai sót (route, security, NACL)  
+- Nếu thiết kế kém, dễ tạo lỗ hổng bảo mật  
+- Có thể phát sinh chi phí (NAT Gateway, VPN...)
+
+---
+
+## 5. So sánh với dịch vụ tương tự
+
+| Dịch vụ | Ưu điểm | Nhược điểm |
+|---------|---------|------------|
+| VPC | Toàn quyền kiểm soát mạng, bảo mật cao | Cấu hình phức tạp, dễ sai sót |
+| AWS PrivateLink | Kết nối private tới dịch vụ AWS, không expose public IP | Chỉ dùng cho một số dịch vụ, không thay thế VPC |
+| Default VPC | Dùng nhanh, không cần cấu hình nhiều | Không phù hợp production, thiếu tùy chỉnh |
+| Public Cloud Shared Network | Đơn giản, nhanh | Không kiểm soát, bảo mật kém |
+
+---
+
+## 6. Luồng hoạt động
+
+1. Khởi tạo VPC (chọn CIDR, tạo subnet)  
+2. Tạo các tài nguyên trong subnet (EC2, RDS...)  
+3. Cấp quyền truy cập (Security Group, NACL)  
+4. Gắn Internet Gateway/NAT Gateway nếu cần kết nối internet  
+5. Thiết lập routing (route table)  
+6. Các tài nguyên hoạt động và giao tiếp theo cấu hình mạng đã tạo
+
+---
+
+## 7. Cách mở rộng
+
+- Thêm subnet khi cần mở rộng vùng mạng  
+- Tăng CIDR block (thêm secondary CIDR)  
+- VPC Peering hoặc Transit Gateway: kết nối nhiều VPC  
+- Auto Scaling: tài nguyên trong VPC tự động thêm/bớt
+
+---
+
+## 8. Cách bảo mật
+
+- Security Group: Kiểm soát truy cập từng instance  
+- NACL: Bảo vệ subnet, block IP bất thường  
+- Flow Logs: Ghi lại traffic, phát hiện bất thường  
+- Endpoints: Truy cập dịch vụ AWS mà không cần internet  
+- Bảo mật kết nối: VPN, Direct Connect dùng mã hóa  
+- Không expose tài nguyên ra public subnet khi không cần thiết
+
+---
+
+## 9. Tích hợp với dịch vụ nào
+
+- EC2, RDS, ElastiCache, Lambda (in VPC), ECS, EKS  
+- Direct Connect, VPN (kết nối on-premise)  
+- AWS PrivateLink, VPC Endpoint: truy cập private tới dịch vụ AWS khác  
+- CloudFormation: tự động hóa tạo VPC
+
+---
+
+## 10. Kiến trúc thực tế dùng VPC
+
+- **3-tier web app**:  
+  - Public subnet (load balancer)  
+  - Private subnet (app server, DB)  
+  - NAT Gateway cho app server ra ngoài  
+  - Security group phân tách rõ ràng
+
+- **Hybrid cloud**: Kết nối VPC với data center qua VPN/Direct Connect
+
+- **Multi-VPC**: VPC peering hoặc Transit Gateway để các VPC giao tiếp
+
+---
+
+## 11. Sự cố thường gặp & cách xử lý
+
+| Sự cố | Cách xử lý |
+|-------|------------|
+| Không kết nối được internet | Thiếu Internet Gateway, route table chưa đúng, thiếu NAT Gateway cho private subnet |
+| Không ping được giữa các instance | Security group, NACL block traffic |
+| Không truy cập được DB | DB đặt ở private subnet, security group chưa mở port |
+| Route table sai | Gói tin không đi đúng hướng, kiểm tra lại route |
+| CIDR trùng khi peering VPC | Không peering được, cần đổi CIDR |
+
+---
+
+VPC là nền tảng mạng quan trọng nhất trên AWS, giúp kiểm soát, bảo vệ và kết nối tài nguyên một cách linh hoạt và an toàn. Khi triển khai, hãy luôn lập sơ đồ, chú ý bảo mật và kiểm tra kỹ các bảng route, security group để tránh lỗi kết nối.

package/BlueprintTemplate/public/assets/lessons/groups/aws-application-integration-overview.md

@@ -0,0 +1,194 @@
+# AWS Application Integration – Tổng quan các dịch vụ và mô hình kiến trúc
+
+Trong hệ sinh thái AWS, **Application Integration** là nhóm dịch vụ giúp các ứng dụng và microservices **giao tiếp với nhau một cách linh hoạt, mở rộng tốt và giảm phụ thuộc lẫn nhau**.
+
+Bài viết này cung cấp:
+- Tổng quan các dịch vụ Application Integration chính trên AWS
+- Giải thích các mô hình kiến trúc thường gặp
+- Gợi ý khi nào nên sử dụng từng dịch vụ
+
+---
+
+## 1. Các dịch vụ Application Integration chính
+
+### Amazon SQS (Simple Queue Service)
+
+Amazon SQS là dịch vụ **hàng đợi tin nhắn** được quản lý hoàn toàn bởi AWS.  
+Một thành phần (producer) gửi message vào queue, các thành phần khác (consumer) sẽ lấy message ra xử lý khi sẵn sàng.
+
+Điểm quan trọng là producer và consumer **không cần hoạt động cùng thời điểm**, giúp hệ thống tách biệt và ổn định hơn.
+
+**Đặc điểm chính:**
+- Fully managed queue
+- Giúp decouple các microservices
+- Message được lưu trữ tạm thời
+- Consumer xử lý theo tốc độ riêng
+- Hỗ trợ hai loại queue: Standard và FIFO
+
+---
+
+### Amazon SNS (Simple Notification Service)
+
+Amazon SNS là dịch vụ **publish/subscribe**.  
+Khi một sự kiện xảy ra, SNS publish message và **nhiều subscriber có thể nhận cùng lúc**.
+
+SNS phù hợp khi bạn cần gửi cùng một thông tin đến nhiều hệ thống khác nhau.
+
+**Đặc điểm chính:**
+- Mô hình Pub/Sub
+- Push-based
+- Tích hợp Lambda, SQS, Email, HTTP endpoint
+- Thường dùng cho mô hình fan-out
+
+---
+
+### Amazon EventBridge
+
+EventBridge là dịch vụ **phân phối và định tuyến sự kiện**.  
+Nó nhận events từ:
+- AWS services
+- Ứng dụng SaaS
+- Custom application events  
+
+Sau đó route các event này đến đúng target dựa trên rule và điều kiện lọc.
+
+**Đặc điểm chính:**
+- Event bus trung tâm
+- Rule-based routing
+- Hỗ trợ event filtering
+- Kết nối nhiều ứng dụng rời rạc
+- Serverless
+
+---
+
+### AWS Step Functions
+
+AWS Step Functions dùng để **điều phối workflow** giữa nhiều bước xử lý khác nhau.  
+Bạn định nghĩa luồng xử lý dưới dạng **state machine**, AWS sẽ đảm nhiệm việc thực thi theo đúng thứ tự.
+
+Điều này giúp tách logic workflow ra khỏi code nghiệp vụ.
+
+**Đặc điểm chính:**
+- Orchestration
+- State machine
+- Hỗ trợ retry, catch, parallel
+- Kết hợp Lambda, ECS, Glue
+- Dễ quan sát và debug
+
+---
+
+### Amazon Kinesis (Tổng quan)
+
+Amazon Kinesis là nhóm dịch vụ dùng cho **xử lý dữ liệu streaming thời gian thực**, ví dụ:
+- Log hệ thống
+- Clickstream
+- Dữ liệu IoT
+
+**Đặc điểm chính:**
+- Real-time data streams
+- Gồm Kinesis Data Streams, Firehose, Analytics
+- Phù hợp cho big data pipeline và analytics
+
+---
+
+## 2. Các mô hình và khái niệm kiến trúc quan trọng
+
+### Event-driven Architecture
+
+Trong kiến trúc event-driven:
+- Các hệ thống không gọi trực tiếp nhau
+- Thay vào đó phát ra event
+- Thành phần nào quan tâm sẽ tự xử lý
+
+Cách tiếp cận này giúp hệ thống linh hoạt và dễ mở rộng.
+
+**Đặc điểm:**
+- Loose coupling
+- Scalability tốt
+- Ít phụ thuộc thời gian thực
+- Thường dùng với SNS, SQS, EventBridge
+
+---
+
+### Fan-out Model
+
+Fan-out là mô hình:
+- Một event
+- Được gửi đến nhiều consumer để xử lý song song
+
+**Ví dụ phổ biến:**
+- SNS nhận event
+- SNS gửi message đến nhiều SQS queues
+- Mỗi queue xử lý một nhiệm vụ riêng
+
+**Lợi ích:**
+- Parallel processing
+- Các consumer không ảnh hưởng nhau
+- Tăng throughput hệ thống
+
+---
+
+### SQS: FIFO Queue vs Standard Queue
+
+#### Standard Queue
+- Không đảm bảo thứ tự message
+- Throughput rất cao
+- Có thể có duplicate message
+
+Phù hợp khi **thứ tự xử lý không quan trọng**.
+
+---
+
+#### FIFO Queue
+- Đảm bảo đúng thứ tự gửi – nhận
+- Không bị duplicate
+- Throughput giới hạn (~3,000 message/giây)
+
+Phù hợp cho:
+- Thanh toán
+- Xử lý đơn hàng
+- Các nghiệp vụ cần đảm bảo thứ tự
+
+---
+
+### Choreography vs Orchestration
+
+#### Choreography
+
+Trong mô hình choreography:
+- Mỗi service tự lắng nghe event
+- Tự quyết định hành động cần làm
+- Không có trung tâm điều phối
+
+Phù hợp với hệ thống microservices lớn, phân tán.
+
+**Thường dùng:** EventBridge, SNS, SQS
+
+---
+
+#### Orchestration
+
+Trong mô hình orchestration:
+- Có một thành phần trung tâm điều phối luồng xử lý
+- Thứ tự các bước được định nghĩa rõ ràng
+- Dễ theo dõi, retry và xử lý lỗi
+
+Trên AWS, **Step Functions là dịch vụ orchestration chính**.
+
+---
+
+## 3. Tổng kết
+
+Nhóm dịch vụ Application Integration giúp bạn:
+- Kết nối các hệ thống một cách lỏng lẻo
+- Thiết kế kiến trúc event-driven và serverless
+- Mở rộng hệ thống mà không làm phức tạp code
+
+**Ghi nhớ nhanh:**
+- SQS: queue và decouple services
+- SNS: publish/subscribe và fan-out
+- EventBridge: event routing và integration
+- Step Functions: workflow orchestration
+- Kinesis: xử lý dữ liệu streaming thời gian thực
+
+Nắm vững các dịch vụ này là nền tảng quan trọng để thiết kế hệ thống hiện đại trên AWS.

package/BlueprintTemplate/public/assets/lessons/groups/aws-compute-architecture-overview.md

@@ -0,0 +1,187 @@
+# AWS Compute Architecture – Tổng quan các dịch vụ và cách lựa chọn
+
+Trong AWS, **Compute Architecture** là tập hợp các dịch vụ dùng để chạy ứng dụng, xử lý logic và mở rộng hệ thống theo nhu cầu.  
+Việc hiểu rõ từng dịch vụ và biết khi nào nên dùng dịch vụ nào là nền tảng quan trọng để thiết kế kiến trúc hiệu quả, tối ưu chi phí và dễ vận hành.
+
+Bài viết này cung cấp:
+- Tổng quan các dịch vụ compute phổ biến trên AWS
+- Vai trò của load balancing và auto scaling
+- Hướng dẫn lựa chọn dịch vụ phù hợp theo từng loại workload
+
+---
+
+## 1. Các dịch vụ Compute chính trên AWS
+
+### Amazon EC2 (Elastic Compute Cloud)
+
+Amazon EC2 là **máy chủ ảo truyền thống** trên AWS.  
+Bạn có toàn quyền kiểm soát hệ điều hành và môi trường chạy ứng dụng, từ cài đặt phần mềm cho đến cấu hình mạng và bảo mật.
+
+**Đặc điểm chính:**
+- Toàn quyền kiểm soát OS
+- Phù hợp với workload chạy lâu dài, ổn định
+- Dùng khi cần custom networking, driver hoặc phần mềm đặc thù
+- Tính phí theo thời gian chạy (On-Demand, Reserved, Spot)
+- Mở rộng bằng Auto Scaling Group
+
+---
+
+### Application Load Balancer (ALB) & Network Load Balancer (NLB)
+
+Load Balancer có nhiệm vụ **phân phối traffic** đến nhiều backend server để tránh quá tải và tăng độ sẵn sàng.
+
+#### Application Load Balancer (ALB)
+- Hoạt động ở Layer 7 (HTTP/HTTPS)
+- Hỗ trợ routing theo path và host
+- Phù hợp cho web application và microservices
+
+#### Network Load Balancer (NLB)
+- Hoạt động ở Layer 4 (TCP)
+- Hiệu năng rất cao, độ trễ thấp
+- Phù hợp cho hệ thống traffic lớn, tài chính, gaming, IoT
+
+---
+
+### Auto Scaling Group (ASG)
+
+Auto Scaling Group giúp hệ thống **tự động tăng hoặc giảm số lượng EC2 instance** dựa trên tải thực tế.
+
+**Đặc điểm chính:**
+- Scale out khi CPU hoặc traffic tăng
+- Scale in khi tải giảm
+- Kết hợp với ALB để health check
+- Giúp tối ưu chi phí và tăng tính sẵn sàng
+- Thường dùng cùng CloudWatch alarms
+
+---
+
+### Amazon ECS & AWS Fargate
+
+#### Amazon ECS (EC2 mode)
+ECS là dịch vụ điều phối container.  
+Ở chế độ EC2, bạn **tự quản lý các EC2 instance** chạy container.
+
+**Phù hợp khi:**
+- Muốn tối ưu chi phí (Spot EC2)
+- Cần custom AMI, daemon hoặc monitoring đặc biệt
+- Cần kiểm soát hạ tầng chi tiết
+
+---
+
+#### AWS Fargate
+Fargate cho phép chạy container **mà không cần quản lý server**.  
+Bạn chỉ định CPU và RAM, AWS lo toàn bộ phần hạ tầng.
+
+**Đặc điểm chính:**
+- Serverless container
+- Không cần quản lý EC2
+- Triển khai nhanh, dễ vận hành
+- Trả tiền theo CPU/RAM sử dụng
+
+> ECS (EC2 mode) và Fargate dùng chung **ECS Task Definition**, chỉ khác cách vận hành hạ tầng.
+
+---
+
+### AWS Lambda
+
+AWS Lambda cho phép chạy code dưới dạng **function serverless**.  
+Bạn chỉ tập trung viết logic, AWS tự động lo scaling và hạ tầng.
+
+**Đặc điểm chính:**
+- Event-driven (S3, API Gateway, EventBridge…)
+- Rất tiết kiệm chi phí cho workload không liên tục
+- Thời gian chạy tối đa 15 phút
+- Không phù hợp cho workload dài hoặc CPU nặng
+- Tự động scale gần như không giới hạn
+
+---
+
+### Amazon API Gateway
+
+API Gateway đóng vai trò **cổng vào cho API**.  
+Client gọi API → API Gateway điều phối request đến Lambda, ECS hoặc EC2.
+
+**Đặc điểm chính:**
+- Hỗ trợ REST API, HTTP API, WebSocket
+- Auto scaling
+- Throttling, caching, usage plan
+- Kết hợp rất tốt với Lambda cho kiến trúc serverless
+
+---
+
+### AWS Step Functions
+
+Step Functions dùng để **điều phối workflow** giữa nhiều bước xử lý.
+
+**Đặc điểm chính:**
+- Workflow orchestration
+- Điều khiển thứ tự thực thi
+- Hỗ trợ retry, parallel steps
+- Phù hợp cho automation, ETL, pipeline
+
+---
+
+## 2. Các quyết định kiến trúc quan trọng
+
+### Khi nào dùng EC2 và khi nào dùng Lambda
+
+**Chọn Lambda khi:**
+- Workload theo sự kiện, không liên tục
+- Không muốn quản lý server
+- Cần auto scale nhanh
+- Thời gian chạy ≤ 15 phút
+
+**Chọn EC2 khi:**
+- Workload chạy liên tục
+- Cần custom OS, driver, agent
+- CPU/RAM lớn
+- Ứng dụng legacy
+
+---
+
+### Khi nào dùng ECS, Fargate và Lambda
+
+- **Lambda**: xử lý logic nhỏ, event-based
+- **Fargate**: chạy container serverless, dễ deploy
+- **ECS (EC2 mode)**: kiểm soát hạ tầng, tối ưu chi phí, workload phức tạp
+
+---
+
+### Khi nào cần Load Balancer
+
+Bạn nên dùng Load Balancer khi:
+- Hệ thống có từ 2 server trở lên
+- Cần chia tải request
+- Cần health check backend
+- Yêu cầu high availability
+
+**Gợi ý:**
+- ALB cho HTTP/HTTPS
+- NLB cho TCP, traffic lớn
+
+---
+
+### Khi nào cần Auto Scaling
+
+Auto Scaling phù hợp khi:
+- Traffic không ổn định
+- CPU/Memory biến động mạnh
+- Muốn tối ưu chi phí
+- Cần tự động phục hồi khi instance gặp sự cố
+
+---
+
+## 3. Tổng kết
+
+AWS cung cấp nhiều lựa chọn compute để phù hợp với từng loại ứng dụng và mô hình vận hành.
+
+**Tóm tắt nhanh:**
+- EC2: toàn quyền kiểm soát
+- ALB/NLB: chia tải và tăng độ sẵn sàng
+- Auto Scaling: mở rộng linh hoạt
+- ECS/Fargate: container hóa ứng dụng
+- Lambda: serverless function
+- API Gateway: cổng vào API
+- Step Functions: điều phối workflow
+
+Việc chọn đúng dịch vụ compute giúp hệ thống **ổn định, mở rộng tốt và tiết kiệm chi phí** ngay từ đầu.