Skip to main content

Command Palette

Search for a command to run...

Syllabus học AWS Load balancers

Updated
16 min readView as Markdown

Ngày 1: Tổng quan Load Balancers & Kiến trúc nền tảng

  • Sáng:

    • Ôn tập kiến thức cơ bản về Load Balancing: các loại, lợi ích, so sánh Layer 4 và Layer 7.

    • Kiến trúc nền tảng của ELB (mới, quan trọng cho phỏng vấn/production): tìm hiểu Nitro System và công nghệ Hyperplane - lớp hạ tầng ảo hoá cho phép ELB scale gần như tức thời và xử lý hàng triệu request/giây mà không cần "pre-warming" thủ công như trước đây. Hiểu vì sao ALB/NLB vẫn có thể bị giới hạn (subnet hết IP khi scale, connection limits) để thiết kế subnet/CIDR đúng ngay từ đầu.

    • Đi sâu vào kiến trúc và hoạt động của ALB, NLB, GWLB:

      • ALB: cấu trúc chi tiết của Listener Rules, các loại điều kiện (path-based, host-based, header-based, query-string, source-IP), thứ tự ưu tiên rule, redirect, và rewrite rule dùng regex cho URL/host header (tính năng mới).

      • NLB: các chế độ proxy (TCP, TLS, UDP), sticky sessions (source IP), preservation of client source IP, và QUIC pass-through (giảm latency cho client di động/HTTP3).

      • GWLB: giao thức GENEVE, cách GWLB tương tác với thiết bị ảo qua Gateway Load Balancer Endpoint (GWLBE) - một loại VPC Endpoint dùng AWS PrivateLink.

    • So sánh 4 loại LB hiện có trên AWS: ALB, NLB, GWLB, và Classic LB (legacy, chỉ nên biết để maintain hệ thống cũ, không dùng cho thiết kế mới).

  • Chiều:

    • Bài tập 1: Tạo một ALB với nhiều Listener Rules (chuyển hướng dựa trên header, rewrite URL bằng regex).

    • Bài tập 2: Thiết lập NLB với sticky sessions và preservation of client source IP; thử nghiệm đo latency với và không có QUIC pass-through.

    • Bài tập 3: Nghiên cứu và so sánh chi tiết tính năng bảo mật của ALB, NLB, GWLB (WAF trên ALB, mTLS trên NLB, security groups theo loại LB - lưu ý: NLB truyền thống không hỗ trợ Security Group trực tiếp trên listener trừ khi bật tính năng Security Groups for NLB).

    • Bài tập 4: Viết toàn bộ hạ tầng bài tập 1-2 bằng Infrastructure as Code (Terraform hoặc AWS CDK) thay vì Console - đây là chuẩn production, không dùng ClickOps.

Ngày 2-3: Application Load Balancer (ALB)

  • Ngày 2:

    • Sáng:

      • Xử lý nội dung động với ALB: tích hợp ALB với AWS Lambda (Lambda Target Groups), lưu ý giới hạn payload 1MB và timeout.

      • Cân bằng tải cho ứng dụng container: ALB với Amazon ECS (bao gồm ECS Express Mode - cách triển khai nhanh production-ready với ALB, ACM, CloudWatch tự động cấu hình) và Amazon EKS.

      • Kiểm soát traffic chi tiết: weighted target groups, content-based routing, cross-zone load balancing, và Automatic Target Weighting (ATW) - ALB tự động giảm trọng số cho target đang lỗi/chậm để hạn chế lan truyền sự cố (rất quan trọng cho resilience).

      • ALB Target Optimizer: tính năng tối ưu concurrency cho từng target - đặc biệt hữu ích cho workload AI/inference cần xử lý tuần tự theo từng task thay vì round-robin đơn thuần.

    • Chiều:

      • Bài tập 1: Tạo ALB chuyển hướng traffic đến Lambda function, đo cold-start ảnh hưởng thế nào đến latency p99.

      • Bài tập 2: Thiết lập ALB cân bằng tải cho ứng dụng chạy trên ECS bằng Express Mode, so sánh với cách cấu hình thủ công.

      • Bài tập 3: Cấu hình ALB phân phối traffic không đồng đều giữa Target Groups (weighted target groups) để triển khai canary/blue-green.

      • Bài tập 4: Bật Automatic Target Weighting, chủ động gây lỗi 5xx trên 1 target (chaos test) và quan sát ALB tự điều chỉnh traffic.

  • Ngày 3:

    • Sáng:

      • Xác thực và ủy quyền với ALB: tích hợp Amazon Cognito, OIDC, SAML - hiểu rõ luồng redirect và vì sao ALB authentication chỉ hỗ trợ IPv4 khi gọi IdP (một lỗi phổ biến khi bật dual-stack mà quên public IPv4).

      • Bảo mật ứng dụng web: tích hợp AWS WAF (Web ACL, managed rule groups, rate-based rules) và AWS Shield/Shield Advanced.

      • Mitigation mode của ALB (desync mitigation): monitor / defensive / strictest - hiểu default là "defensive" và khi nào cần strictest cho compliance.

      • Tích hợp Amazon API Gateway (REST API) private integration với ALB (tính năng mới) - dùng khi cần expose API có auth/throttling của API Gateway nhưng backend chạy sau ALB nội bộ (VPC Link).

      • Giám sát và xử lý sự cố chuyên sâu: CloudWatch Logs Insights, Access Logs (định dạng chi tiết field), AWS X-Ray để phân tích và tối ưu hiệu suất ALB.

    • Chiều:

      • Bài tập 1: Cấu hình ALB yêu cầu xác thực người dùng qua Amazon Cognito, kiểm tra hành vi khi session hết hạn.

      • Bài tập 2: Thiết lập AWS WAF bảo vệ ứng dụng web sau ALB khỏi OWASP Top 10, cấu hình rate-based rule chống brute-force/DDoS lớp ứng dụng.

      • Bài tập 3: Dùng CloudWatch Logs Insights phân tích mẫu truy cập bất thường, viết query tìm request có latency > p99, tìm target trả về nhiều 5xx nhất.

      • Bài tập 4: Kết nối API Gateway REST API với ALB nội bộ qua private integration, so sánh với NLB + VPC Link truyền thống.

Ngày 4-5: Network Load Balancer (NLB)

  • Ngày 4:

    • Sáng:

      • NLB và các giao thức: TCP, UDP, TLS (mutual TLS authentication), và QUIC pass-through cho các ứng dụng HTTP/3.

      • Cân bằng tải cho ứng dụng đòi hỏi hiệu năng cao: UDP cho VoIP/gaming, cân bằng tải cho cơ sở dữ liệu (ví dụ giao tiếp với các node trong cluster CSDL qua NLB static IP).

      • Tối ưu hiệu suất NLB: Proxy Protocol v2 (lấy được source IP thật khi target không thể enable "preserve client IP"), connection draining (deregistration delay), cross-zone load balancing (lưu ý: bật cross-zone trên NLB phát sinh phí data transfer liên AZ).

      • NLB Weighted Target Groups (tính năng mới, 11/2025): tương tự ALB, cho phép canary/blue-green ở Layer 4 - trước đây chỉ ALB mới làm được điều này, giờ NLB đã hỗ trợ.

    • Chiều:

      • Bài tập 1: Thiết lập NLB cân bằng tải cho ứng dụng VoIP dùng UDP.

      • Bài tập 2: Cấu hình NLB với mutual TLS authentication, verify chain chứng chỉ client.

      • Bài tập 3: Tối ưu hiệu suất NLB dùng Proxy Protocol và connection draining; benchmark trước/sau.

      • Bài tập 4: Triển khai blue/green deployment ở tầng NLB bằng Weighted Target Groups, dịch chuyển traffic dần 10% → 50% → 100% có giám sát CloudWatch alarms tự động rollback.

  • Ngày 5:

    • Sáng:

      • NLB và microservices: dùng NLB làm nền tảng cho service mesh/PrivateLink (expose service qua NLB + Endpoint Service để chia sẻ giữa nhiều VPC/account mà không cần VPC peering).

      • Bảo mật NLB: Security Groups cho NLB (tính năng hiện đã GA - trước đây NLB không hỗ trợ SG trực tiếp), Network ACLs, AWS Shield Advanced.

      • Tích hợp NLB với dịch vụ khác: ECS, EKS (qua AWS Load Balancer Controller), API Gateway (VPC Link v2).

    • Chiều:

      • Bài tập 1: Thiết kế và triển khai kiến trúc microservices dùng NLB + PrivateLink để chia sẻ service xuyên account.

      • Bài tập 2: Cấu hình Security Groups trực tiếp trên NLB và Network ACLs, kiểm tra traffic bị chặn đúng như kỳ vọng.

      • Bài tập 3: Tích hợp NLB với API Gateway (VPC Link) để cung cấp một điểm truy cập duy nhất cho microservices nội bộ.

Ngày 6: Gateway Load Balancer (GWLB)

  • Sáng:

    • GWLB và các trường hợp sử dụng: tích hợp thiết bị ảo bên thứ ba (firewall, IDS/IPS) từ AWS Marketplace, triển khai giải pháp bảo mật mạng tập trung (centralized inspection VPC - mô hình hub-and-spoke với Transit Gateway + GWLB).

    • Tối ưu GWLB: cross-zone load balancing, health checks, Auto Scaling group cho fleet thiết bị ảo (target utilization-based scaling).

    • Chi phí GWLB (GLCU - Gateway Load Balancer Capacity Unit): hiểu 3 chiều tính phí (new flows/s, active flows, processed bytes) để dự đoán chi phí khi traffic tăng - tránh bất ngờ hoá đơn khi go-live.

    • Giám sát và xử lý sự cố GWLB: CloudWatch (Active Flow Count, Processed Bytes...), AWS X-Ray.

  • Chiều:

    • Bài tập 1: Tích hợp GWLB với một thiết bị ảo firewall bên thứ ba (hoặc mô phỏng bằng EC2 chạy iptables/Suricata).

    • Bài tập 2: Cấu hình health checks cho GWLB đảm bảo tính sẵn sàng của thiết bị ảo, test failover khi 1 appliance unhealthy.

    • Bài tập 3: Dựng mô hình centralized inspection: Transit Gateway + GWLB + Ingress/Egress VPC, kiểm tra traffic Internet ra/vào đều đi qua firewall tập trung.

    • Bài tập 4: Dùng AWS X-Ray/CloudWatch theo dõi và ước tính chi phí GLCU dựa trên traffic thực tế của bài tập.

Ngày 7-8: Load Balancer trong Kubernetes (EKS) & Ôn tập tổng hợp

  • Ngày 7:

    • Sáng:

      • AWS Load Balancer Controller (LBC) - GA với Kubernetes Gateway API (GA từ 03/2026): LBC giờ hỗ trợ cả Ingress annotation truyền thống lẫn Gateway API (Gateway, GatewayClass, HTTPRoute, TCPRoute) - chuẩn hoá, có schema validation, cross-namespace routing, tự động discover certificate, và role separation không cần quyền cluster-admin.

      • So sánh mô hình cũ (annotation-based Ingress) và mô hình mới (Gateway API CRD) - khi nào nên migrate.

      • Lưu ý vận hành quan trọng: Ingress NGINX (dự án phổ biến, không phải của AWS) sẽ retire vào tháng 3/2026 - team nào đang dùng cần có kế hoạch migrate sang AWS Load Balancer Controller hoặc controller Gateway API khác (Envoy Gateway, Istio...).

      • LBC điều phối cả L4 (TCP/UDP qua NLB) và L7 (HTTP/gRPC qua ALB) chỉ bằng một spec Gateway API - giảm khi kiến trúc cần cả hai loại LB.

      • AWS Load Balancer Controller + AWS Global Accelerator qua API khai báo Kubernetes - cho phép cải thiện performance toàn cầu ngay từ manifest, không cần thao tác thủ công ngoài cluster.

    • Chiều:

      • Bài tập 1: Cài đặt AWS Load Balancer Controller trên một cluster EKS, expose một Service qua Ingress (annotation-based) tạo ALB.

      • Bài tập 2: Viết lại cấu hình bài tập 1 bằng Gateway API (Gateway + HTTPRoute), so sánh trải nghiệm và khả năng validate.

      • Bài tập 3: Tạo TCPRoute cho một service cần NLB (L4) và HTTPRoute cho service cần ALB (L7) trong cùng cluster, dùng chung một Gateway API spec.

  • Ngày 8:

    • Ôn tập toàn bộ kiến thức Ngày 1-7, làm thêm bài tập.

    • Nghiên cứu thêm: Blue/Green Deployment với CodeDeploy + ALB/NLB, Auto Scaling (target tracking, predictive scaling), AWS Global Accelerator (Anycast IP, giảm latency toàn cầu, health check độc lập với LB).

    • Checklist review production-readiness (chuẩn bị cho dự án Ngày 9-13): high availability (multi-AZ tối thiểu 3 AZ), auto scaling, health check hợp lý (threshold, interval), TLS certificate tự động renew qua ACM, logging bật đầy đủ (access logs, connection logs), alarms cho 5xx rate / latency / unhealthy host count, WAF bật ở mọi entry point public, DR runbook (multi-region hay không).

Ngày 9: Chuẩn bị & Thiết kế kiến trúc dự án tổng hợp

  • Dành cả ngày thiết kế kiến trúc chi tiết (diagram, IaC skeleton, danh sách tài nguyên) cho dự án production ở Ngày 10-13, review chéo với "reviewer" (bạn học/giảng viên) như một Architecture Review Board thực tế trước khi build.

Ngày 10-13: Dự án tổng hợp - Production

Dự án: Xây dựng hệ thống thương mại điện tử có khả năng mở rộng cao, resilient, quan sát được (observable), triển khai bằng IaC và có quy trình CI/CD, sử dụng nhiều loại Load Balancer.

Mô tả:

  1. Frontend:

    • ALB cân bằng tải cho các máy chủ web (EC2 Auto Scaling Group hoặc ECS Fargate qua ECS Express Mode) chạy ứng dụng frontend (React/Angular).

    • HTTPS listener với chứng chỉ ACM tự động renew; TLS security policy tối thiểu TLS1.2, ưu tiên TLS1.3.

    • AWS WAF (managed rule groups + rate-based rule) và Shield Standard/Advanced tuỳ mức độ rủi ro.

    • Weighted Target Groups + Automatic Target Weighting để triển khai canary release an toàn.

  2. Backend (microservices):

    • NLB (có thể kèm Weighted Target Groups để blue/green) cho các service Layer 4 hiệu năng cao (ví dụ dịch vụ thanh toán cần độ trễ thấp và static IP để whitelist với đối tác thanh toán).

    • Microservices chạy trên EKS, quản lý bằng AWS Load Balancer Controller + Gateway API (HTTPRoute cho ALB, TCPRoute cho NLB) - thay cho Ingress NGINX.

    • API Gateway (REST hoặc HTTP API) làm điểm truy cập duy nhất, dùng private integration với ALB/NLB nội bộ qua VPC Link.

    • Health checks phân biệt readiness/liveness, cấu hình threshold tránh false-positive khi có GC pause hoặc cold start.

  3. Network Security (defense in depth):

    • GWLB + Transit Gateway làm inspection layer tập trung cho traffic ra/vào (ingress/egress) toàn bộ VPC, tích hợp thiết bị ảo firewall/IDS-IPS từ Marketplace.

    • Security Groups (bao gồm SG trực tiếp trên NLB) và Network ACLs theo nguyên tắc least privilege.

    • AWS Shield Advanced cho tài nguyên public quan trọng (kèm SRT - Shield Response Team runbook).

  4. Observability & Vận hành:

    • CloudWatch dashboards cho toàn bộ LB (request count, latency p50/p90/p99, 4xx/5xx rate, unhealthy host count, active/new flow count của NLB/GWLB).

    • CloudWatch Alarms + SNS/Chatbot cảnh báo khi vi phạm SLO (ví dụ p99 latency > 500ms hoặc 5xx rate > 1%).

    • AWS X-Ray end-to-end tracing qua ALB → API Gateway → microservices.

    • Access logs của ALB/NLB đẩy vào S3, phân tích bằng Athena/CloudWatch Logs Insights.

  5. Auto Scaling & Chi phí:

    • Auto Scaling Group (target tracking theo CPU/ALBRequestCountPerTarget) hoặc Karpenter/Cluster Autoscaler cho EKS.

    • Ước tính và tối ưu chi phí: LCU của ALB, NLCU của NLB, GLCU của GWLB - mô hình hoá chi phí theo traffic dự kiến trước khi go-live.

    • Cân nhắc AWS Global Accelerator nếu có traffic đa vùng/đa quốc gia.

  6. CI/CD & IaC:

    • Toàn bộ hạ tầng viết bằng Terraform hoặc AWS CDK, review qua pull request (không ClickOps).

    • Pipeline blue/green hoặc canary tự động qua CodeDeploy/Argo Rollouts, có tiêu chí rollback tự động dựa trên CloudWatch Alarm.

  7. Kiểm thử độ tin cậy (Resilience testing):

    • Game day: chủ động tắt 1 AZ, gây lỗi 1 target group, ngắt 1 appliance sau GWLB - xác nhận hệ thống tự phục hồi theo đúng SLO.

    • Load test (ví dụ bằng k6/Locust) để xác định giới hạn thực tế của ALB/NLB/GWLB đã cấu hình, so sánh với ước tính GLCU/LCU.

Mục tiêu:

  • Hiểu rõ và có kinh nghiệm thực chiến với ALB, NLB, GWLB (bao gồm các tính năng mới nhất 2025-2026) trong một hệ thống gần với production thật.

  • Áp dụng đầy đủ vòng đời: thiết kế → IaC → triển khai → bảo mật → quan sát → chịu lỗi → tối ưu chi phí.

  • Rèn kỹ năng đọc release notes/whitepaper AWS để cập nhật kiến trúc theo tính năng mới, thay vì chỉ học một lần rồi áp dụng mãi mãi (LB trên AWS thay đổi khá nhanh).

Bonus: 3 ngày học GENEVE Protocol

Ngày 1: Khám phá Geneve Protocol và Thiết kế Cơ bản

  • Sáng:

    • Tổng quan về Geneve Protocol:

      • Giới thiệu mục đích và ứng dụng của Geneve protocol (RFC 8926).

      • Vai trò của Geneve trong việc đóng gói và chuyển tiếp lưu lượng mạng cho network virtualization.

      • So sánh Geneve với các giao thức encapsulation khác (VXLAN, GRE, NVGRE) - vì sao GWLB chọn Geneve thay vì VXLAN: khả năng mở rộng qua Tunnel Options linh hoạt hơn.

    • Yêu cầu thiết kế và thuật ngữ:

      • Các yêu cầu thiết kế cốt lõi của Geneve: tính độc lập của Control Plane, khả năng mở rộng của Data Plane.

      • Thuật ngữ quan trọng: Tunnel, Tunnel Header, Tunnel Options, NVE (Network Virtualization Endpoint).

  • Chiều:

    • Bài tập 1: Đọc và tóm tắt các yêu cầu thiết kế của Geneve (Phần 2, RFC 8926: https://datatracker.ietf.org/doc/html/rfc8926).

    • Bài tập 2: Tìm hiểu sự khác biệt giữa Control Plane và Data Plane trong kiến trúc mạng.

    • Bài tập 3: Nghiên cứu và so sánh Geneve với VXLAN và GRE bằng bảng so sánh (header overhead, khả năng mở rộng, use case).

Ngày 2: Chi tiết kỹ thuật của Geneve Encapsulation

  • Sáng:

    • Định dạng gói tin Geneve:

      • Phân tích chi tiết định dạng gói tin Geneve trên IPv4 và IPv6.

      • Vai trò của header UDP (port 6081 mặc định) và các trường trong Tunnel Header.

      • Các loại Tunnel Options (Type-Length-Value) và cách chúng được xử lý - đây chính là cơ chế GWLB dùng để mang metadata flow (flow cookie) giữa GWLB và appliance.

    • Các cân nhắc về triển khai:

      • Các tình huống áp dụng Geneve protocol trong thực tế production (không chỉ GWLB mà cả OVN, NSX...).

      • Quản lý congestion control, tính toán checksum UDP.

      • Đóng gói Geneve trong IP: phân mảnh (fragmentation), DSCP, ECN, TTL.

      • Xử lý VLAN bên trong gói tin Geneve.

  • Chiều:

    • Bài tập 1: Vẽ sơ đồ mô tả định dạng gói tin Geneve (outer IP/UDP, Geneve header, Tunnel Options, inner payload).

    • Bài tập 2: Tìm hiểu cách tính checksum UDP và cách nó được dùng trong Geneve.

    • Bài tập 3: Nghiên cứu các kỹ thuật offload phần cứng (NIC offloads) liên quan đến Geneve - vì sao điều này quan trọng cho hiệu năng GWLB ở traffic lớn.

Ngày 3: Ứng dụng Geneve trong GWLB và Cân nhắc An ninh

  • Sáng:

    • Geneve và GWLB:

      • Tìm hiểu cách GWLB dùng Geneve để chuyển tiếp traffic đến thiết bị ảo qua GWLBE (Gateway Load Balancer Endpoint - VPC Endpoint dựa trên PrivateLink).

      • Vai trò của GWLB trong việc mở rộng khả năng xử lý của thiết bị mạng ảo (auto scaling appliance fleet).

      • Các trường hợp sử dụng phổ biến (triển khai firewall, IDS/IPS, centralized inspection VPC).

    • Cân nhắc về bảo mật:

      • Các vấn đề bảo mật liên quan đến Geneve: bảo mật dữ liệu, xác thực NVE, tấn công giả mạo (spoofing).

      • Các biện pháp bảo mật được khuyến nghị: mã hoá, IPsec, kiểm soát truy cập ở lớp VPC (Security Groups/NACL bao quanh GWLBE).

  • Chiều:

    • Bài tập 1: Thiết lập môi trường lab đơn giản mô phỏng cách GWLB hoạt động với Geneve (dùng công cụ ảo hoá / EC2 + tcpdump để bắt gói Geneve thực tế).

    • Bài tập 2: Tìm hiểu các lỗ hổng bảo mật tiềm ẩn của Geneve và cách giảm thiểu.

    • Bài tập 3: Đọc và tóm tắt các cân nhắc bảo mật trong tài liệu (Phần 6, RFC 8926: https://datatracker.ietf.org/doc/html/rfc8926).

Knowledge

Part 1 of 50