blog-blueprint 0.0.2

package/BlueprintTemplate/public/assets/lessons/theory/aws-disaster-recovery-strategies.md

@@ -0,0 +1,117 @@
+# Chiến lược Disaster Recovery trên AWS: Hướng dẫn toàn diện cho SAA
+
+Disaster Recovery (DR) là yếu tố quan trọng trong kiến trúc hệ thống để đảm bảo ứng dụng luôn sẵn sàng và dữ liệu không bị mất khi xảy ra sự cố. AWS cung cấp nhiều mô hình DR khác nhau, từ phương án tiết kiệm chi phí đến phương án full active-active. Bài viết này sẽ phân tích 4 chiến lược DR phổ biến trên AWS.
+
+---
+
+## 1. Backup & Restore
+
+**Khái niệm:** Lưu trữ dữ liệu định kỳ để phục hồi thủ công khi sự cố xảy ra. Đây là phương án rẻ nhất nhưng chậm nhất.  
+
+**AWS Services:** S3, Glacier, RDS Snapshot, EBS Snapshot  
+
+**RTO:** Cao (phục hồi lâu)  
+**RPO:** Trung bình, tùy vào tần suất backup  
+**Chi phí:** Thấp nhất  
+
+**Khi nào dùng:**  
+- Ứng dụng không yêu cầu phục hồi nhanh  
+- Ưu tiên tiết kiệm chi phí  
+
+**Cách thực hiện:**  
+- Backup định kỳ, phục hồi khi cần  
+- Sử dụng S3 Cross-Region nếu muốn DR khác region  
+
+**Ví dụ trực quan:**  
+“Backup & Restore giống như có bản sao dữ liệu trong kho. Khi nhà cháy, bạn quay lại kho để lấy và xây lại nhà từ đầu. Rẻ, dễ làm, nhưng mất thời gian.”
+
+---
+
+## 2. Pilot Light
+
+**Khái niệm:** Chạy sẵn phần lõi của hệ thống ở region dự phòng. Khi sự cố xảy ra, bật thêm các phần còn lại để khởi động nhanh hơn.  
+
+**AWS Services:**  
+- DynamoDB Global Table hoặc backup  
+- S3 replicated data  
+- Minimal EC2/ASG, AMI để launch khi DR  
+
+**RTO:** Khá thấp  
+**RPO:** Tốt  
+**Chi phí:** Thấp đến trung bình  
+
+**Khi nào dùng:**  
+- Cần phục hồi nhanh hơn Backup & Restore  
+- Muốn tiết kiệm chi phí nhưng vẫn có hệ thống chạy sẵn  
+
+**Cách thực hiện:**  
+- DB và message queue chạy sẵn  
+- App server chỉ khởi động khi DR xảy ra  
+
+**Ví dụ trực quan:**  
+“Pilot Light giống như để lửa mồi nhỏ trong bếp. Khi cần nấu ăn, bạn chỉ mở to lửa và nấu ngay. Vừa tiết kiệm gas vừa khởi động nhanh.”
+
+---
+
+## 3. Warm Standby
+
+**Khái niệm:** Hệ thống chạy sẵn ở mức tối thiểu tại region dự phòng, failover gần như lập tức khi sự cố.  
+
+**AWS Services:**  
+- RDS read replica hoặc Multi-AZ + cross-region  
+- EC2 chạy ở low capacity  
+- ASG nhỏ, scale lên khi DR  
+
+**RTO:** Thấp  
+**RPO:** Thấp  
+**Chi phí:** Trung bình  
+
+**Khi nào dùng:**  
+- Muốn DR nhanh  
+- Không cần full active-active  
+
+**Cách thực hiện:**  
+- Toàn bộ ứng dụng chạy sẵn nhưng ở capacity nhỏ  
+- Khi DR xảy ra → route traffic qua region dự phòng → scale lên  
+
+**Ví dụ trực quan:**  
+“Warm Standby giống như quán ăn mở cửa nhưng chỉ để vài bàn. Khi khách đông, bạn mở thêm bàn và phục vụ đầy đủ ngay.”
+
+---
+
+## 4. Multi-Site / Active–Active
+
+**Khái niệm:** Hai region chạy full công suất cùng lúc. Nếu một bên lỗi, traffic tự chuyển ngay lập tức.  
+
+**AWS Services:**  
+- Route 53 latency/geo routing  
+- DynamoDB Global Tables  
+- Aurora Global Database  
+- S3 CRR  
+
+**RTO:** Gần như 0  
+**RPO:** Gần như 0  
+**Chi phí:** Cao nhất  
+
+**Khi nào dùng:**  
+- Ứng dụng yêu cầu luôn luôn hoạt động  
+- SLAs rất cao  
+
+**Cách thực hiện:**  
+- Deploy toàn bộ hệ thống ở cả 2 region  
+- Cả 2 region phục vụ người dùng song song  
+- Route 53 điều phối traffic  
+
+**Ví dụ trực quan:**  
+“Multi-Site giống như 2 cửa hàng mở cùng lúc. Nếu 1 cửa đóng, khách vẫn còn cửa bên kia. Rất an toàn nhưng tốn tiền nhất.”
+
+---
+
+## 5. Bảng so sánh nhanh
+
+| Strategy               | RTO        | RPO        | Chi phí       | Tốc độ phục hồi | Mô tả trực quan                          |
+|------------------------|------------|------------|---------------|----------------|-----------------------------------------|
+| Backup & Restore       | Cao        | Trung bình | Thấp          | Chậm           | Nhà cháy → xây lại từ bản sao dữ liệu   |
+| Pilot Light            | Trung bình | Thấp       | Thấp–TB       | Nhanh vừa      | Lửa mồi → bật to là chạy               |
+| Warm Standby           | Thấp       | Thấp       | Trung bình    | Rất nhanh      | Quán mở sẵn vài bàn                     |
+| Multi-Site Active-Active | Gần như 0 | Gần như 0 | Cao nhất      | Nhanh nhất     | Hai cửa hàng mở full                    |

package/BlueprintTemplate/public/assets/lessons/theory/aws-event-driven-architecture.md

@@ -0,0 +1,77 @@
+# Kiến trúc Event-Driven trên AWS: Hướng dẫn toàn diện cho SAA
+
+Event-Driven Architecture (EDA) là mô hình kiến trúc ứng dụng dựa trên sự kiện, giúp hệ thống **decoupled, scalable và fault-tolerant**. Khi một sự kiện xảy ra, nó được đẩy vào router và các consumer xử lý tương ứng. Bài viết này phân tích chi tiết các thành phần và pattern quan trọng của EDA trên AWS.
+
+---
+
+## 1. Event Producers
+
+**Khái niệm:** Là nơi phát sinh sự kiện.  
+
+**Các dịch vụ AWS:**  
+- **Applications:** Backend tạo event khi user hành động, ví dụ: `OrderCreated`, `UserSignedUp`.  
+- **Lambda:** Chạy xong publish event lên EventBridge.  
+- **IoT Core:** Gửi sensor data (nhiệt độ, GPS…) vào pipeline.  
+- **Kinesis (Producer):** App push streaming data như log, clickstream, IoT, metrics.  
+
+**Mục đích:** Producers tạo thông báo về các hành động, dữ liệu hoặc trạng thái mới trong hệ thống để consumer có thể xử lý.
+
+---
+
+## 2. Event Routers
+
+**Khái niệm:** Thành phần trung gian chuyển tiếp sự kiện đến các consumer.  
+
+**Các dịch vụ AWS:**  
+- **EventBridge:** Rule-based routing, lọc event, đổi định dạng, gửi đến target, hỗ trợ SaaS integrations.  
+- **SNS (Pub/Sub):** Fan-out, push notifications tới nhiều hệ thống.  
+- **Kinesis Data Streams:** Stream data realtime, shard-based high throughput, consumer đọc theo thứ tự trong shard.  
+- **SQS:** Queue cho async decoupling, FIFO hoặc Standard, đảm bảo delivery, retry, DLQ.  
+
+**Mục đích:** Event routers quyết định event sẽ đi đâu, hỗ trợ phân phối, đảm bảo thứ tự và độ bền của dữ liệu.
+
+---
+
+## 3. Event Consumers
+
+**Khái niệm:** Nơi xử lý sự kiện.  
+
+**Các dịch vụ AWS:**  
+- **Lambda:** Xử lý event nhỏ, logic nhẹ, auto-scale, zero admin.  
+- **Step Functions:** Orchestration nhiều bước, workflow dài.  
+- **ECS:** Xử lý event cần nhiều CPU/RAM, batch jobs, ML inference, heavy processing.  
+
+**Mục đích:** Consumers nhận nhiệm vụ từ producers thông qua router và thực thi logic xử lý, tính toán hoặc cập nhật dữ liệu.
+
+---
+
+## 4. Các Pattern Quan Trọng
+
+### Pub/Sub (Publish-Subscribe)
+- SNS và EventBridge dùng mô hình này.  
+- Producer không biết consumer là ai, consumer đăng ký nhận event push.  
+- Ví dụ: “Giống như đăng ký nhận tin từ fanpage Facebook. Fanpage post bài → ai follow đều nhận.”
+
+### Fan-out Pattern
+- Một event → đẩy đến nhiều consumer.  
+- Dùng SNS → SQS queues → Lambda/ECS.  
+- Giúp tách workflow, tránh coupling.  
+- Ví dụ: “Một tin gửi tới nhiều đích cùng lúc.”
+
+### FIFO Messaging
+- SQS FIFO hoặc Kinesis giữ thứ tự + exactly-once delivery.  
+- Dùng khi thứ tự quan trọng (payment, trading).  
+- Ví dụ: “Xếp hàng mua vé, ai tới trước được phục vụ trước.”
+
+### Async Decoupling
+- Producers gửi event mà không chờ consumer xử lý.  
+- SQS, Kinesis, SNS, EventBridge hỗ trợ.  
+- Tăng resilience và khả năng scale.  
+- Ví dụ: “Một cái hộp thư, bỏ thư vào → người nhận tới lúc nào cũng được.”
+
+### Event vs Message
+- **Event:** Thông báo chuyện đã xảy ra, stateless, không mong đợi trả lời. Ví dụ: `OrderCreated`.  
+- **Message:** Nhiệm vụ cần xử lý, gửi trực tiếp đến một consumer. Ví dụ: `ProcessPayment(orderId)`.  
+- Điểm phân biệt quan trọng để thiết kế kiến trúc chính xác.
+
+---

package/BlueprintTemplate/public/assets/lessons/theory/aws-ha-ft-scalability.md

@@ -0,0 +1,98 @@
+# High Availability, Fault Tolerance và Scalability trên AWS: Hướng dẫn toàn diện
+
+Trong kiến trúc AWS, ba khái niệm quan trọng là **High Availability (HA)**, **Fault Tolerance (FT)** và **Scalability**. Bài viết này giải thích chi tiết các thành phần, cách triển khai và patterns quan trọng.
+
+---
+
+## 1. High Availability (HA)
+
+**Khái niệm:** Hệ thống luôn hoạt động, dù một Availability Zone (AZ) bị lỗi. Người dùng gần như không nhận ra sự cố.  
+
+**Các thành phần và cách triển khai:**
+
+- **Multi-AZ:**  
+  - Triển khai tài nguyên trên ít nhất 2 AZ độc lập về điện và mạng.  
+  - Dùng cho: RDS, EC2, ElastiCache, ALB targets.  
+  - Lưu ý: Multi-AZ chỉ chống lỗi trong cùng region, không phải multi-region.
+
+- **ALB (Application Load Balancer):**  
+  - Phân phối lưu lượng giữa nhiều EC2 / ECS / Lambda.  
+  - Health check tự động route về instance khỏe.  
+  - Hỗ trợ path routing và host routing.
+
+- **Aurora Replicas:**  
+  - Reader Replicas trong cùng region (multi-AZ).  
+  - Failover tự động < 30s, tách đọc/ghi tăng performance.
+
+- **Auto Scaling Group (ASG):**  
+  - Nếu instance chết → ASG tạo instance mới.  
+  - Duy trì số lượng EC2 healthy, kết hợp ALB tạo HA hoàn chỉnh.  
+
+---
+
+## 2. Fault Tolerance (FT)
+
+**Khái niệm:** Hệ thống vẫn hoạt động ngay cả khi cả region gặp sự cố.  
+
+**Các thành phần và cách triển khai:**
+
+- **Multi-Region Deployment:**  
+  - Active-active hoặc active-passive.  
+  - Route 53 routing policy để failover.  
+  - Dữ liệu replicate giữa regions.
+
+- **Global DynamoDB:**  
+  - Multi-region, multi-master.  
+  - Ghi và đọc từ bất kỳ region, replicate trong vài ms.  
+  - Dùng cho ứng dụng global low-latency.
+
+- **S3 Cross-Region Replication (CRR):**  
+  - Tự động replicate object sang region khác.  
+  - Versioning phải bật, chỉ replicate object mới.  
+
+- **Route 53 Failover Routing:**  
+  - Health check, nếu region A chết → chuyển sang B.  
+  - Dùng cho active-passive hoặc active-active.
+
+---
+
+## 3. Scalability
+
+**Khái niệm:** Khả năng tăng hoặc giảm tài nguyên khi load thay đổi.  
+
+**Các cách triển khai:**
+
+- **Horizontal vs Vertical Scaling:**  
+  - Vertical (Scale-up): Tăng kích thước server, giới hạn bởi phần cứng.  
+  - Horizontal (Scale-out): Thêm nhiều instance, không giới hạn, cần app stateless.
+
+- **Auto Scaling:**  
+  - Tăng giảm EC2 theo CPU / request ALB / queue length SQS.  
+  - Target tracking tốt nhất, step scaling dùng khi cần tùy chỉnh.
+
+- **Lambda (Serverless Scaling):**  
+  - Tự động scale theo request, không cần quản lý server.  
+  - Hỗ trợ 1000+ concurrent invocations.  
+  - Provisioned Concurrency nếu cần tốc độ cao.
+
+- **Serverless Scaling:**  
+  - Dịch vụ tự động scale: Lambda, DynamoDB, SQS, SNS, API Gateway, Fargate.  
+  - Không cần quản lý server, scaling tự động.
+
+---
+
+## 4. AWS Patterns thường gặp
+
+- **Stateless Application:**  
+  - Server không giữ session, session data lưu ở DynamoDB, ElastiCache, S3.  
+  - Giúp dễ scale-out.  
+
+- **Loose Coupling:**  
+  - Dịch vụ không phụ thuộc trực tiếp vào nhau.  
+  - Dùng SQS, SNS, EventBridge để tránh synchronous coupling.
+
+- **Multi-AZ + Multi-Region Architecture:**  
+  - App tier: Multi-AZ (ASG + ALB).  
+  - DB tier: Multi-AZ (RDS/Aurora).  
+  - Multi-region DR: Route 53 failover.  
+  - Multi-AZ = HA, Multi-region = Fault Tolerance.

package/BlueprintTemplate/public/assets/lessons/theory/aws-hybrid-cloud.md

@@ -0,0 +1,82 @@
+# Hybrid Cloud trên AWS: VPN, Direct Connect và các patterns kết nối On-Premise
+
+Hybrid Cloud là giải pháp kết nối hệ thống **On-Premise** với AWS qua **VPN** hoặc **Direct Connect (DX)**. Hai phương thức này giúp doanh nghiệp vừa tận dụng hạ tầng tại chỗ, vừa mở rộng lên AWS, tối ưu chi phí và hiệu suất.
+
+---
+
+## 1. VPN (Site-to-Site VPN)
+
+**IPSec VPN**  
+- Kết nối mã hóa qua Internet.  
+- Tạo bằng Virtual Private Gateway (VGW).  
+- Sử dụng IPSec Tunnel, thường có 2 tunnel để đảm bảo redundancy.  
+
+**Site-to-Site VPN**  
+- Kết nối router on-prem ↔ AWS.  
+- Dễ dựng trong vài phút, giá rẻ.  
+- Thích hợp cho PoC, Dev hoặc DR.
+
+**Routing**  
+- Hỗ trợ static routing hoặc BGP dynamic routing.  
+- BGP giúp tự động failover.  
+- Có thể kết hợp với Transit Gateway.
+
+**Lưu ý:**  
+- VPN thường có throughput thấp hơn Direct Connect.  
+- Latency biến động, không phù hợp workload lớn hoặc yêu cầu băng thông cao.  
+
+---
+
+## 2. Direct Connect (DX)
+
+**Dedicated vs Hosted**  
+- **Dedicated DX:** AWS cấp cổng vật lý riêng, tốc độ 1/10/100 Gbps, phù hợp doanh nghiệp lớn.  
+- **Hosted DX:** Thuê từ partner, tốc độ 50 Mbps → 10 Gbps, dễ tiếp cận hơn.  
+
+**DX Gateway**  
+- Cho phép kết nối DX với nhiều VPC.  
+- Cross-region được phép.  
+- Thích hợp khi nhiều VPC cần share cùng DX.
+
+**Private VIF vs Public VIF**  
+- **Private VIF:** Kết nối on-prem → VPC, dùng để truy cập private subnet, DB, app servers.  
+- **Public VIF:** Kết nối on-prem → AWS public services (S3, DynamoDB) mà không đi qua Internet.
+
+**Lưu ý:**  
+- Direct Connect ổn định, tốc độ cao, thích hợp production traffic.  
+- Chi phí cao hơn VPN, setup phức tạp hơn.
+
+---
+
+## 3. VPN + DX Redundancy
+
+- **DX primary:** Tốc độ cao, latency ổn định, dùng cho production traffic.  
+- **VPN backup:** Failover tự động nhờ BGP, đảm bảo hệ thống hoạt động liên tục khi DX gặp sự cố.  
+- Kết hợp DX + VPN giúp vừa nhanh vừa có dự phòng chi phí thấp.
+
+---
+
+## 4. Patterns kết nối On-Premise → AWS
+
+**Active Directory Integration**  
+- AWS Managed AD hoặc AD Connector.  
+- Hybrid identity (on-prem AD ↔ AWS).
+
+**Database Migration**  
+- DMS + SCT, hỗ trợ replication, CDC.  
+- Hỗ trợ migrate Oracle, SQL Server, MySQL, …
+
+**VPC ↔ On-Prem Routing**  
+- Qua VPN hoặc DX.  
+- Sử dụng VGW hoặc Transit Gateway (TGW) cho routing phức tạp, multi-VPC, multi-region.
+
+**Common Hybrid Patterns**  
+- Web tier trên AWS, DB on-prem.  
+- Active-Passive DR.  
+- On-prem main workload + AWS burst capacity.  
+- Analytics trên AWS (copy data từ on-prem).
+
+---
+
+**Tóm tắt:**  
+Hybrid Cloud giúp doanh nghiệp chạy một phần ứng dụng tại on-prem và phần còn lại trên AWS. VPN nhanh, giá rẻ nhưng throughput thấp; Direct Connect tốc độ cao, ổn định; kết hợp DX + VPN cung cấp cả hiệu suất lẫn dự phòng. Các pattern hybrid như database migration, AD integration và routing TGW giúp quản lý môi trường phức tạp dễ dàng.

package/BlueprintTemplate/public/assets/lessons/theory/aws-microservices-vs-monolithic.md

@@ -0,0 +1,77 @@
+# Microservices vs Monolithic: So sánh kiến trúc ứng dụng và triển khai trên AWS
+
+Trong phát triển phần mềm, hai kiến trúc phổ biến là **Monolithic** và **Microservices**. Hiểu rõ ưu nhược điểm và cách triển khai trên AWS giúp bạn xây dựng hệ thống dễ mở rộng, resilient và maintainable.
+
+---
+
+## 1. Microservices
+
+### Ưu điểm
+- **Scale riêng từng service:** Chỉ cần scale phần service cần thiết, không scale toàn bộ ứng dụng.  
+- **Resilience:** Một service gặp lỗi không làm sập toàn bộ hệ thống.  
+- **Deploy độc lập:** Các team có thể deploy riêng rẽ mà không ảnh hưởng các phần khác.  
+- **Technology freedom:** Mỗi service có thể dùng công nghệ phù hợp (Java, Node.js, Python…).
+
+### Nhược điểm
+- **Networking phức tạp:** Cần service discovery, routing, retries, circuit breaker.  
+- **Observability khó:** Cần tracing, logs, metrics tập trung (AWS X-Ray, CloudWatch, OpenTelemetry).  
+- **Complexity của hệ thống phân tán:** Data consistency, event ordering, idempotency.
+
+### Dịch vụ AWS đi kèm
+- **Lambda:** Serverless microservices, scale tự động.  
+- **API Gateway:** Entry point cho microservices, hỗ trợ rate limiting, auth, routing.  
+- **ECS / EKS:** Chạy container-based microservices, hỗ trợ service discovery.  
+- **EventBridge:** Event-driven microservices, giúp loose coupling.
+
+---
+
+## 2. Monolithic Architecture
+
+### Ưu điểm
+- **Đơn giản để bắt đầu:** Một codebase duy nhất, dễ deploy.  
+- **Dễ maintain ở giai đoạn đầu:** Dev mới vào hiểu nhanh.  
+- **Debug đơn giản:** Tất cả trong cùng một process.
+
+### Nhược điểm
+- **Khó scale:** Muốn scale 1 tính năng phải scale toàn app.  
+- **Deploy chậm:** Thay đổi 1 dòng code → build và deploy toàn bộ ứng dụng.  
+- **Low resilience:** Một lỗi nhỏ có thể làm crash toàn hệ thống.
+
+### Dịch vụ AWS đi kèm
+- **EC2:** Chạy nguyên một ứng dụng lớn.  
+- **ELB (ALB/NLB):** Load balancer phân phối traffic, scale phía trước.  
+- **Auto Scaling Group:** Scale cả ứng dụng, không theo service.
+
+---
+
+## 3. Anti-Patterns (thường gặp khi triển khai Microservices)
+
+- Dùng **chung database** giữa nhiều service → tạo coupling.  
+- Tạo **quá nhiều microservices quá sớm** → "distributed monolith", phức tạp hơn monolithic.  
+- Không có **observability** → logs không tập trung, khó debug.  
+- Không có **API contract** rõ ràng → thay đổi một service ảnh hưởng service khác.  
+- Internal services gọi nhau theo chuỗi dài → tạo latency và failure cascade.
+
+---
+
+## 4. Khi nào nên chuyển từ Monolithic sang Microservices
+
+**Nên chuyển khi:**
+- Team lớn hơn.  
+- Ứng dụng bắt đầu scale không đều.  
+- Một phần hệ thống quá nặng.  
+- Release chậm và dễ tạo lỗi.  
+- Workload tăng và cần resilient hơn.
+
+**Không nên chuyển nếu:**
+- Product chưa ổn định.  
+- Team nhỏ.  
+- Traffic chưa cao.  
+- Không có nhu cầu scale độc lập.
+
+---
+
+**Tóm tắt:**  
+- **Monolithic:** Dễ bắt đầu, debug đơn giản, nhưng khó scale, deploy chậm, low resilience.  
+- **Microservices:** Scale linh hoạt, resilient, deploy độc lập, nhưng quản lý phức tạp, networking và observability khó.  
+- Lựa chọn kiến trúc phù hợp dựa trên quy mô team, workload và nhu cầu mở rộng.

package/BlueprintTemplate/public/assets/lessons/theory/aws-well-architected-framework.md

@@ -0,0 +1,174 @@
+# AWS Well-Architected Framework: 6 Pillars cho hệ thống Cloud tối ưu
+
+AWS Well-Architected Framework giúp xây dựng, triển khai và vận hành các hệ thống Cloud một cách hiệu quả, bảo mật, bền vững và tối ưu chi phí. Framework gồm 6 Pillars chính:
+
+---
+
+## 1. Operational Excellence (Vận hành hiệu quả)
+
+### Nguyên tắc chính
+- Giám sát (Observer) mọi thứ
+- Tự động hóa (Automate)
+- Ghi lại quy trình (Document)
+- Cải tiến liên tục (Continuous improvement)
+
+### Best Practices
+- IaC: CloudFormation, CDK
+- Deployment: CI/CD (CodePipeline, CodeDeploy)
+- Monitoring: CloudWatch logs, metrics, alarms
+- Config + Audit: AWS Config, CloudTrail
+- Game days: mô phỏng sự cố để test
+
+### Lỗi phổ biến
+- Không log → không biết lỗi ở đâu
+- Cấu hình thủ công thay vì IaC
+- Chỉ monitor health check ELB → thiếu metrics ứng dụng
+- Chạy cron script bằng EC2 thay vì EventBridge
+
+### Dịch vụ liên quan
+CloudWatch, CloudTrail, AWS Config, Lambda, Systems Manager, CodePipeline, CodeDeploy
+
+---
+
+## 2. Security (Bảo mật)
+
+### Nguyên tắc chính
+- Least privilege
+- Encryption everywhere
+- Identity first
+- Detect & respond
+
+### Best Practices
+- IAM boundaries, roles, MFA
+- Encryption at rest (KMS) + in transit (TLS)
+- Secrets Manager / Parameter Store
+- Security Groups + NACL
+- GuardDuty, Detective, Security Hub
+
+### Lỗi phổ biến
+- Lưu password DB trong EC2 user-data
+- Cho phép inbound 0.0.0.0/0 vào private resources
+- S3 public read/write
+- Không bật versioning
+- Chọn KMS nhưng quên bật key rotation
+
+### Dịch vụ liên quan
+IAM, KMS, Secrets Manager, ACM, WAF, Shield, GuardDuty, Inspector, Cognito
+
+---
+
+## 3. Reliability (Độ tin cậy)
+
+### Nguyên tắc chính
+- Fault tolerance
+- Automatic recovery
+- Multi-AZ, Multi-Region
+- Backup, DR, snapshots
+- Test recovery
+
+### Best Practices
+- Health checks (ALB, Route 53)
+- Auto Scaling
+- Multi-AZ cho RDS, EC2, ElastiCache
+- S3 cross-region replication
+- RDS snapshots, backup retention
+- SQS để xử lý retry
+
+### Lỗi phổ biến
+- Single-point-of-failure (DB 1 AZ, 1 EC2)
+- Tự viết retry logic thay vì dùng SQS/Lambda
+- Không cấu hình Route 53 failover
+- Tắt Multi-AZ để tiết kiệm chi phí
+
+### Dịch vụ liên quan
+Auto Scaling, Route 53 health checks, S3 versioning + replication, RDS Multi-AZ, DynamoDB global tables, SQS retry & DLQ
+
+---
+
+## 4. Performance Efficiency (Hiệu năng)
+
+### Nguyên tắc chính
+- Chọn đúng công cụ (Right resource)
+- Serverless first
+- Optimize storage
+- Caching, CDN
+- Parallelization
+
+### Best Practices
+- Compute: Lambda, Fargate, EC2 right-sizing
+- Caching: CloudFront, ElastiCache
+- Database: Aurora, DynamoDB
+- Storage: S3, EBS, EFS
+- Auto Scaling (horizontal > vertical scaling)
+
+### Lỗi phổ biến
+- Chọn EC2 quá lớn → tốn tiền, không scale được
+- Không dùng caching cho workload đọc nhiều
+- Dùng RDS cho workload NoSQL
+- Chạy batch processing bằng EC2 thay vì Lambda + SQS
+
+### Dịch vụ liên quan
+Auto Scaling, CloudFront, DynamoDB, Aurora, Lambda, Fargate, ElastiCache
+
+---
+
+## 5. Cost Optimization (Tối ưu chi phí)
+
+### Nguyên tắc chính
+- Avoid unnecessary resources
+- Pay-per-use
+- Measure and monitor cost
+- Use right sizing
+- Use Spot / Savings Plans
+
+### Best Practices
+- EC2 Spot instances
+- Savings Plans / Reserved Instances
+- S3 lifecycle (Infrequent Access, Glacier)
+- Auto Scaling để không chạy dư
+- Lambda (pay-per-request)
+
+### Lỗi phổ biến
+- EC2 chạy 24/7 khi không cần
+- Không dùng S3 lifecycle policies
+- Lưu log không giới hạn → CloudWatch cost cao
+- Dùng provisioned capacity thay vì serverless
+
+### Dịch vụ liên quan
+AWS Budgets, Cost Explorer, Compute Optimizer, S3 lifecycle, Savings Plans / RI
+
+---
+
+## 6. Sustainability (Bền vững)
+
+### Nguyên tắc chính
+- Optimize resource usage
+- Reduce compute waste
+- Serverless = less idle resources
+- Use efficient architectures
+
+### Best Practices
+- Dùng ARM-based Graviton
+- Tối ưu storage (giảm dữ liệu rác)
+- Tối ưu network (gần vùng người dùng)
+- Dùng managed services thay vì tự quản lý server
+
+### Lỗi phổ biến
+- Over-provision resources
+- Lưu dữ liệu không cần thiết
+- Chạy workload xa khách hàng → tốn băng thông + năng lượng
+- Dùng instance cũ/family không tối ưu
+
+### Dịch vụ liên quan
+Lambda, Fargate, Graviton instances, CloudFront, S3 Intelligent-Tiering
+
+---
+
+**Tóm tắt 6 Pillars của AWS Well-Architected Framework**
+
+1. Operational Excellence: Giám sát, tự động hóa, ghi log, CI/CD  
+2. Security: Least privilege, encryption, giám sát, cảnh báo  
+3. Reliability: Multi-AZ, backup, auto recovery, fault tolerance  
+4. Performance Efficiency: Chọn đúng công cụ, caching, scale tự động  
+5. Cost Optimization: Right-sizing, Spot, Savings Plans, Auto Scaling  
+6. Sustainability: Giảm lãng phí tài nguyên, dùng serverless, tối ưu storage/network

package/BlueprintTemplate/public/robots.txt

@@ -0,0 +1,23 @@
+User-agent: *
+Allow: /
+
+# Allow search engines, disallow AI training
+Content-signal: search=yes, ai-train=no
+
+# Block AI training bots
+User-agent: GPTBot
+Disallow: /
+
+User-agent: Google-Extended
+Disallow: /
+
+User-agent: ClaudeBot
+Disallow: /
+
+User-agent: CCBot
+Disallow: /
+
+User-agent: Bytespider
+Disallow: /
+
+Sitemap: https://awsedu.io.vn/sitemap.xml

package/BlueprintTemplate/public/sitemap.xml

@@ -0,0 +1,11 @@
+<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
+  <url>
+    <loc>https://awsedu.io.vn/</loc>
+    <priority>1.0</priority>
+  </url>
+
+  <url>
+    <loc>https://awsedu.io.vn/seo</loc>
+    <priority>0.8</priority>
+  </url>
+</urlset>

package/BlueprintTemplate/src/app/app.config.server.ts

@@ -0,0 +1,12 @@
+import { mergeApplicationConfig, ApplicationConfig } from '@angular/core';
+import { provideServerRendering, withRoutes } from '@angular/ssr';
+import { appConfig } from './app.config';
+import { serverRoutes } from './app.routes.server';
+
+const serverConfig: ApplicationConfig = {
+  providers: [
+    provideServerRendering(withRoutes(serverRoutes))
+  ]
+};
+
+export const config = mergeApplicationConfig(appConfig, serverConfig);