Ngân hàng đề — AWS Certified Solutions Architect Associate

Đáp án

B — Dùng Amazon RDS Read Replicas.

Vì sao đúng

Đề nêu hai yêu cầu, và read replica là lựa chọn trực tiếp nhất: | Yêu cầu | Cơ chế | |---|---| | Tăng THÔNG LƯỢNG ĐỌC | read replica phục vụ truy vấn đọc | | KHÔNG đổi logic cốt lõi của ứng dụng | chỉ đổi endpoint cho đường đọc |

Cách read replica giải quyết vấn đề:

Trước:
    Hàng nghìn lượt Lambda ────▶ MỘT instance RDS
                                 (đọc và ghi tranh nhau)

Sau:
    Lambda đọc  ──▶ read replica 1, 2, 3
    Lambda ghi  ──▶ primary
        ↓
    Tải đọc được phân tán, primary chỉ lo ghi

Tạo read replica:

aws rds create-db-instance-read-replica   --db-instance-identifier replica-doc-1   --source-db-instance-identifier db-chia-se-anh   --db-instance-class db.r6g.large

Và trong Lambda chỉ cần hai chuỗi kết nối:

import os, psycopg2
conn_doc = psycopg2.connect(host=os.environ['DB_READER'])
conn_ghi = psycopg2.connect(host=os.environ['DB_WRITER'])

Đây là thay đổi nhỏ nhất có thể — không sửa truy vấn, không sửa mô hình dữ liệu.

Và RDS hỗ trợ tới 5 read replica (Aurora là 15).

Với ứng dụng chia sẻ ảnh, độ trễ sao chép vài giây thường chấp nhận được:

Người dùng xem ảnh của người khác
    → dữ liệu cũ vài giây không ảnh hưởng trải nghiệm
        ↓
    Chỉ cần chú ý trường hợp đọc-sau-ghi

Vì sao các phương án khác sai

• **C. Dùng Amazon ElastiCache — đây là phương án gần nhất và thực sự giảm tải đọc rất hiệu quả, nhưng nó đòi sửa logic ứng dụng: phải viết mã kiểm tra cache, nạp khi trượt, và vô hiệu hoá khi dữ liệu đổi. Đề nêu rõ "without changing the application's core logic".
• **A. Dùng RDS Multi-AZ — sai mục đích: Multi-AZ là cơ chế SẴN SÀNG CAO, và standby của Multi-AZ instance KHÔNG phục vụ đọc. Nó không tăng thông lượng đọc chút nào.
• **D. Dùng DynamoDB — thay đổi lớn nhất: chuyển từ PostgreSQL sang NoSQL đòi thiết kế lại mô hình dữ liệu và viết lại toàn bộ tầng truy cập.

Ghi nhớ

Multi-AZ và Read Replica — bảng phải thuộc: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC ← câu này | | Sao chép | đồng bộ | bất đồng bộ | | Chuyển đổi | tự động | thủ công (promote) | | Standby phục vụ đọc | ❌ (Multi-AZ instance) | ✅ | | Phạm vi | cùng Region | cùng hoặc khác Region | | Số lượng | 1 standby | 5 (RDS), 15 (Aurora) |

Từ khoá nhận diện:

"increase read throughput", "read scalability" → Read replica "high availability", "automatic failover" → Multi-AZ "cache repeated queries" → ElastiCache (nhưng cần sửa mã)

Ba cách giảm tải đọc — theo thứ tự nên thử: | Thứ tự | Cách | |---|---| | ① | Tối ưu truy vấn và index — rẻ nhất, thường hiệu quả nhất | | ② | Đệm kết quả (ElastiCache) | | ③ | Thêm read replica |

Ba lưu ý về read replica: | Lưu ý | Chi tiết | |---|---| | CHỈ ĐỌC | ứng dụng phải tách đường ghi | | Có ĐỘ TRỄ sao chép | không dùng cho đọc-sau-ghi | | Promote là KHÔNG đảo ngược | thành instance độc lập |

Mẫu xử lý đọc-sau-ghi:

def cap_nhat_anh(ma, du_lieu):
    ghi_vao_primary(ma, du_lieu)
    danh_dau_vua_ghi(ma, thoi_han=5)

def doc_anh(ma):
    if vua_ghi(ma):
        return doc_tu_primary(ma)
    return doc_tu_replica(ma)

Ba lưu ý quan trọng khi Lambda kết nối RDS: | Lưu ý | Chi tiết | |---|---| | Hàng nghìn lượt Lambda đồng thời = hàng nghìn kết nối | cạn connection pool của database | | Dùng RDS Proxy để gom kết nối | gần như bắt buộc | | Khởi tạo kết nối NGOÀI handler | tái dùng giữa các lượt gọi |

RDS Proxy là bổ sung quan trọng cho kiến trúc này:

aws rds create-db-proxy --db-proxy-name proxy-anh   --engine-family POSTGRESQL   --auth '[{"SecretArn":"<arn-secret>","IAMAuth":"REQUIRED"}]'   --role-arn <arn-role> --vpc-subnet-ids subnet-a subnet-b

Không có Proxy:
    1.000 lượt Lambda đồng thời → 1.000 kết nối database
    → cạn sạch, lỗi "too many connections"

Có Proxy:
    → gom lại còn vài chục kết nối thật

Ba lợi ích của RDS Proxy: | Lợi ích | Chi tiết | |---|---| | Gom kết nối | hàng nghìn client → ít kết nối database | | Rút ngắn thời gian chuyển đổi tới 66% | | | Xác thực bằng IAM và Secrets Manager | |

Ba lựa chọn nâng cấp dài hạn: | Lựa chọn | Đặc điểm | |---|---| | Aurora PostgreSQL | 15 replica, độ trễ dưới 100ms, reader endpoint tự cân bằng | | Aurora Serverless v2 | tự co giãn năng lực | | ElastiCache trước database | giảm hẳn tải đọc |

Aurora có reader endpoint tự cân bằng:

RDS: phải tự chọn replica nào để kết nối
Aurora: reader endpoint TỰ cân bằng tải qua mọi replica
        ↓
    Thêm replica là tự động được dùng

Ba cách di chuyển sang Aurora: | Cách | Gián đoạn | |---|---| | Tạo Aurora read replica từ RDS rồi promote | rất ngắn | | Khôi phục từ snapshot | dài hơn | | DMS với CDC | ngắn, phức tạp hơn |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ReplicaLag | độ trễ sao chép | | DatabaseConnections | gần trần thì cần Proxy | | ReadIOPS trên từng instance | xác nhận tải đã tách |

Metric cuối là cách kiểm chứng:

Sau khi sửa ứng dụng dùng replica:
    → ReadIOPS trên primary phải GIẢM
    → ReadIOPS trên replica phải TĂNG
        ↓
    Nếu không, ứng dụng vẫn đang đọc từ primary

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Mỗi replica là một instance đầy đủ | trả tiền như instance thường | | Sao chép trong Region MIỄN PHÍ | không có phí truyền | | Replica xuyên Region tính phí truyền | ~0,02 USD/GB |

Và một lời khuyên: hãy bật Performance Insights trước khi tạo replica. Nếu vấn đề thực sự là vài truy vấn thiếu index, việc thêm index sẽ giải quyết triệt để mà không tốn thêm instance nào — và với ứng dụng chia sẻ ảnh, truy vấn liệt kê ảnh theo người dùng là nơi index hay bị thiếu nhất.

Đáp án

D — Amazon Neptune.

Vì sao đúng

Đề mô tả chính xác loại truy vấn mà database đồ thị giải quyết:

"số lượt thích trên video được đăng bởi BẠN BÈ của người dùng A"
        ↓
    Cần đi qua NHIỀU CẤP QUAN HỆ:
    Người dùng A → bạn bè → video họ đăng → lượt thích

Và đó là loại truy vấn mà database quan hệ xử lý rất kém:

Trong SQL:
    JOIN bang_ban_be
    JOIN bang_video
    JOIN bang_luot_thich
        ↓
    Mỗi cấp quan hệ là một JOIN
    → truy vấn phức tạp, chậm khi dữ liệu lớn
    → và "bạn của bạn" cần JOIN đệ quy

Neptune xử lý quan hệ như công dân hạng nhất:

Database đồ thị lưu:
    ✓ ĐỈNH (vertex): người dùng, video
    ✓ CẠNH (edge): "là bạn của", "đã đăng", "đã thích"
        ↓
    Đi từ đỉnh này sang đỉnh khác là thao tác CƠ BẢN
    → không cần JOIN

Truy vấn bằng Gremlin:

g.V().has('nguoiDung', 'ten', 'A')
  .out('laBanCua')          // bạn bè của A
  .out('daDang')            // video họ đăng
  .in('daThich')            // ai đã thích
  .count()

Hoặc bằng openCypher:

MATCH (a:NguoiDung {ten: 'A'})-[:LA_BAN_CUA]->(b:NguoiDung)
      -[:DA_DANG]->(v:Video)<-[:DA_THICH]-(t:NguoiDung)
RETURN count(t)

Và Neptune hỗ trợ ba ngôn ngữ truy vấn đồ thị: | Ngôn ngữ | Mô hình | |---|---| | Gremlin | property graph (Apache TinkerPop) | | openCypher | property graph (chuẩn của Neo4j) | | SPARQL | RDF (dữ liệu liên kết ngữ nghĩa) |

Vì sao các phương án khác sai

• **C. Amazon Aurora — đây là phương án gần nhất và về nguyên tắc trả lời được câu hỏi bằng SQL, nhưng nó kém hiệu quả với truy vấn nhiều cấp quan hệ: mỗi cấp là một JOIN, và với mạng xã hội hàng triệu người dùng, truy vấn "bạn của bạn" trở nên rất chậm. Database quan hệ tối ưu cho dữ liệu dạng bảng, không phải dạng mạng lưới.
• **B. Amazon Redshift — sai loại tải: Redshift là kho dữ liệu phân tích (OLAP), tối ưu cho tổng hợp trên khối lượng lớn theo cột. Nó không tối ưu cho truy vấn đi qua quan hệ.
• **A. Amazon OpenSearch Service — sai mục đích: OpenSearch là công cụ tìm kiếm và phân tích log, tối ưu cho tìm kiếm toàn văn và truy vấn theo thuộc tính, không phải cho việc duyệt quan hệ.

Ghi nhớ

Các loại database của AWS — bảng phải thuộc: | Loại | Dịch vụ | Phù hợp | |---|---|---| | Quan hệ (OLTP) | RDS, Aurora | giao dịch, lược đồ cố định | | Key-value / document | DynamoDB, DocumentDB | truy cập theo khoá, quy mô lớn | | ĐỒ THỊ | Neptune | quan hệ nhiều cấp ← câu này | | Kho dữ liệu (OLAP) | Redshift | phân tích, tổng hợp | | Trong bộ nhớ | ElastiCache, MemoryDB | đệm, độ trễ micro giây | | Chuỗi thời gian | Timestream | IoT, metric | | Sổ cái | QLDB | lịch sử bất biến, có mật mã | | Tìm kiếm | OpenSearch | tìm kiếm toàn văn, log |

Từ khoá nhận diện — bảng quan trọng nhất:

"relationships", "friends of friends", "social network", "recommendation", "fraud ring" → Neptune "full-text search", "log analytics" → OpenSearch "data warehouse", "aggregate over billions of rows" → Redshift "time-series, IoT metrics" → Timestream "immutable ledger, cryptographically verifiable" → QLDB

Ba trường hợp dùng Neptune: | Trường hợp | Ví dụ | |---|---| | Mạng xã hội | bạn bè, người theo dõi, gợi ý kết nối ← câu này | | Hệ thống gợi ý | "người mua sản phẩm này cũng mua..." | | Phát hiện gian lận | tìm mạng lưới tài khoản liên quan | | Đồ thị tri thức | quan hệ ngữ nghĩa giữa thực thể | | Quản lý danh tính và quyền truy cập | quan hệ phân cấp phức tạp |

Ba đặc điểm của Neptune: | Đặc điểm | Chi tiết | |---|---| | Được quản lý hoàn toàn | AWS lo sao lưu, vá lỗi, chuyển đổi | | Kiến trúc lưu trữ như Aurora | 6 bản sao qua 3 AZ | | Tới 15 read replica | mở rộng đọc |

Hai mô hình dữ liệu đồ thị: | Mô hình | Ngôn ngữ | Đặc điểm | |---|---|---| | Property graph | Gremlin, openCypher | đỉnh và cạnh có thuộc tính | | RDF | SPARQL | bộ ba (chủ ngữ, vị ngữ, tân ngữ) |

Property graph phổ biến hơn cho ứng dụng — RDF thường dùng cho dữ liệu liên kết ngữ nghĩa.

Ba khái niệm của property graph: | Khái niệm | Ví dụ | |---|---| | Vertex (đỉnh) | người dùng, video | | Edge (cạnh) | "là bạn của", "đã thích" | | Property (thuộc tính) | tên, ngày đăng, số lượt xem |

Ba lưu ý về Neptune: | Lưu ý | Chi tiết | |---|---| | Chạy trong VPC, không có endpoint công khai | | | Cần IAM authentication hoặc security group | | | Nạp dữ liệu hàng loạt từ S3 | bulk loader nhanh hơn nhiều so với chèn từng cái |

Bulk loader:

curl -X POST https://<endpoint>:8182/loader -d '{
  "source": "s3://kho-du-lieu/do-thi/",
  "format": "csv",
  "iamRoleArn": "<arn-role>",
  "region": "ap-northeast-1",
  "failOnError": "FALSE"}'

Ba tính năng nâng cao: | Tính năng | Việc | |---|---| | Neptune Analytics | phân tích đồ thị quy mô lớn trong bộ nhớ | | Neptune ML | gợi ý và dự đoán bằng học máy trên đồ thị | | Neptune Serverless | tự co giãn năng lực |

Neptune ML đáng biết cho mạng xã hội:

Neptune ML:
    → dùng Graph Neural Network
    → dự đoán liên kết ("gợi ý kết bạn")
    → phân loại đỉnh ("người dùng này có phải spam không")
        ↓
    Tích hợp với SageMaker, truy vấn bằng Gremlin

Ba lưu ý khi thiết kế đồ thị: | Lưu ý | Chi tiết | |---|---| | Cạnh nên có HƯỚNG rõ ràng | "A là bạn của B" khác "B theo dõi A" | | Đặt nhãn nhất quán | dễ truy vấn | | Tránh đỉnh siêu kết nối | một đỉnh có hàng triệu cạnh làm chậm truy vấn |

Ba lựa chọn kiến trúc kết hợp:

Neptune:   quan hệ giữa người dùng và nội dung
DynamoDB:  hồ sơ người dùng, metadata video
S3:        tệp video và ảnh
OpenSearch: tìm kiếm nội dung
        ↓
    Mỗi database làm đúng việc của nó

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | GremlinRequestsPerSec | tải truy vấn | | CPUUtilization | năng lực instance | | VolumeBytesUsed | dung lượng đồ thị |

Và một lời khuyên: hãy thử nghiệm với một tập dữ liệu thật trước khi cam kết. Database đồ thị vượt trội cho truy vấn nhiều cấp, nhưng nếu phần lớn truy vấn của ứng dụng chỉ là "lấy hồ sơ theo id", thì DynamoDB rẻ và nhanh hơn — và kiến trúc tốt nhất thường là dùng cả hai, mỗi cái cho đúng loại truy vấn của nó.

Đáp án

A — Triển khai AWS Storage Gateway ở chế độ CACHED VOLUME: giữ dữ liệu truy cập thường xuyên ở địa phương, đồng thời ghi toàn bộ dữ liệu chính bất đồng bộ lên S3.

Vì sao đúng

Đề nêu bốn yêu cầu, và cached volume đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Mở rộng dung lượng lên đám mây | dữ liệu chính ở S3, dung lượng gần như vô hạn | | Truy cập nhanh dữ liệu quan trọng từ địa phương | cache cục bộ cho dữ liệu nóng | | KHÔNG có phí truy xuất hay độ trễ khi đọc | S3 Standard không có phí truy xuất | | Ít phải cấu hình lại ứng dụng | volume gắn qua iSCSI như ổ đĩa thường |

Vế "không có phí truy xuất" là điểm loại phương án D:

S3 Standard: KHÔNG có phí truy xuất
S3 Standard-IA: CÓ phí truy xuất mỗi GB
        ↓
    Đề nêu rõ "avoid any RETRIEVAL FEES or delays"

Cached volume hoạt động thế nào:

Ứng dụng ghi vào volume iSCSI
    ↓
Gateway ghi vào upload buffer
    ↓ bất đồng bộ
Amazon S3 (dữ liệu CHÍNH, đầy đủ)
    ↓
Cache cục bộ giữ dữ liệu NÓNG cho đọc nhanh

Cấu hình:

aws storagegateway create-cachedi-scsi-volume   --gateway-arn <arn-gateway>   --volume-size-in-bytes 10995116277760   --target-name du-lieu-y-te   --network-interface-id 10.100.0.50   --client-token $(uuidgen)

Và vế "tối ưu băng thông khi di chuyển":

Gateway ghi bất đồng bộ, có thể giới hạn băng thông theo lịch
    → không nghẽn đường truyền trong giờ làm việc

aws storagegateway update-bandwidth-rate-limit   --gateway-arn <arn> --average-upload-rate-limit-in-bits-per-sec 100000000

Vì sao các phương án khác sai

• **B. Dùng Storage Gateway ở chế độ STORED VOLUME, giữ toàn bộ dữ liệu tại chỗ và sao lưu snapshot lên S3 — đây là phương án gần nhất và cùng dịch vụ, nhưng nó không giải quyết vấn đề của đề: stored volume giữ TOÀN BỘ dữ liệu tại chỗ, nên không mở rộng được dung lượng — mà đề nêu rõ tổ chức đang hết chỗ trên máy chủ tại chỗ.
• **D. Dùng S3 Standard-IA làm tầng lưu trữ chính với DataSync đồng bộ — vi phạm yêu cầu về phí truy xuất: Standard-IA có phí truy xuất mỗi GB, và đề nói rõ muốn tránh điều đó. Và DataSync là đồng bộ định kỳ, không cho truy cập liên tục như ổ đĩa.
• **C. Dùng FSx for Windows File Server và mount từ tại chỗ qua VPN — không có cache cục bộ: mọi thao tác tệp phải đi qua WAN, độ trễ cao. Đề yêu cầu "frequent local access to key datasets".

Ghi nhớ

Hai chế độ Volume Gateway — bảng phải thuộc: | | Cached volume | Stored volume | |---|---|---| | Dữ liệu ĐẦY ĐỦ nằm ở | S3 | TẠI CHỖ | | Tại chỗ giữ gì | CHỈ cache dữ liệu nóng | toàn bộ dữ liệu | | S3 giữ gì | toàn bộ | bản sao lưu (EBS snapshot) | | Dung lượng tối đa | 1 PB | 512 TB | | Phù hợp | MỞ RỘNG dung lượng ← câu này | khôi phục thảm hoạ |

Quy tắc chọn:

Hết chỗ tại chỗ, muốn mở rộng → cached Đủ chỗ tại chỗ, muốn sao lưu và khôi phục thảm hoạ → stored

Ba loại Storage Gateway: | Loại | Giao thức | Đích | |---|---|---| | File Gateway | NFS, SMB | S3 (mỗi tệp là một object) | | Volume Gateway | iSCSI (KHỐI) | S3 dạng EBS snapshot ← câu này | | Tape Gateway | iSCSI VTL | S3 Glacier |

Từ khoá nhận diện:

"iSCSI", "block volume", "cached locally" → Volume Gateway "NFS", "SMB", "file share" → File Gateway "replace tape library", "backup software" → Tape Gateway

Ba thành phần cần cấu hình: | Thành phần | Việc | |---|---| | Đĩa CACHE | giữ dữ liệu nóng — kích thước quyết định trải nghiệm | | Upload buffer | vùng đệm chờ đẩy lên S3 | | Volume | dung lượng logic ứng dụng thấy |

Kích thước cache là yếu tố quyết định:

Cache nhỏ hơn tập dữ liệu nóng
    → mọi lần đọc phải lấy từ S3
    → độ trễ cao, mất hết lợi ích
        ↓
    AWS khuyến nghị cache ít nhất 20% dung lượng volume

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitPercent | thấp nghĩa là cache quá nhỏ | | CachePercentUsed | gần đầy thì cần mở rộng | | UploadBufferPercentUsed | đầy sẽ CHẶN việc ghi |

Dòng cuối là sự cố nghiêm trọng:

Upload buffer đầy:
    → gateway không nhận ghi mới
    → ứng dụng bị treo
        ↓
    Nguyên nhân thường là băng thông lên AWS không đủ

Ba lớp lưu trữ S3 và phí truy xuất: | Lớp | Phí truy xuất | |---|---| | Standard | KHÔNG ← yêu cầu của đề | | Standard-IA, One Zone-IA | CÓ | | Glacier (mọi loại) | CÓ, và cần restore | | Intelligent-Tiering | KHÔNG (có phí giám sát nhỏ) |

Intelligent-Tiering đáng cân nhắc:

Nếu muốn tiết kiệm mà vẫn không có phí truy xuất:
    → Intelligent-Tiering
    → tự phân tầng theo mẫu truy cập
    → không có phí truy xuất

Ba đặc điểm của Volume Gateway: | Đặc điểm | Chi tiết | |---|---| | Sao lưu dạng EBS snapshot | khôi phục thành EBS volume trên AWS được | | Lên lịch snapshot tự động | | | Volume tối đa 32 TB (cached) | tổng 1 PB |

Khả năng khôi phục thành EBS là lợi ích phụ quan trọng:

Trung tâm dữ liệu gặp sự cố
    → khôi phục snapshot thành EBS volume
    → gắn vào EC2 và chạy tiếp
        ↓
    Volume Gateway vừa mở rộng dung lượng
    vừa là cơ chế khôi phục thảm hoạ

Ba yêu cầu triển khai: | Yêu cầu | Chi tiết | |---|---| | Nền tảng chạy gateway | VMware, Hyper-V, KVM, EC2, hoặc thiết bị phần cứng | | Đĩa cho cache và upload buffer | | | Băng thông ổn định lên AWS | |

Ba lựa chọn lưu trữ lai — chọn đúng: | Nhu cầu | Dịch vụ | |---|---| | Ổ đĩa KHỐI với cache | Volume Gateway ← câu này | | Chia sẻ TỆP với cache | File Gateway | | Di chuyển một lần hoặc định kỳ | DataSync |

Ba biện pháp cho dữ liệu y tế: | Biện pháp | Chi tiết | |---|---| | Ký BAA với AWS | bắt buộc cho PHI | | Mã hoá at rest bằng KMS | trên bucket S3 | | Mã hoá in transit | gateway dùng TLS |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ S3 | theo GB thực tế | | Snapshot | tăng dần, chỉ lưu khối đã đổi | | Truyền dữ liệu VÀO AWS | MIỄN PHÍ |

Và một lời khuyên: hãy đặt alarm cho CacheHitPercent dưới 80% và cho UploadBufferPercentUsed trên 80%. Với dữ liệu hình ảnh y tế tăng liên tục, cả hai chỉ số này sẽ xấu dần theo thời gian — và phát hiện sớm cho bạn thời gian mở rộng đĩa trước khi bác sĩ bắt đầu phàn nàn về tốc độ mở hồ sơ.

Đáp án

A và C.

• A — Đặt minimum capacity là 2
• C — Dùng Reserved Instances cho phần năng lực tối thiểu

Vì sao đúng

Đề nêu ba mục tiêu, và hai đáp án cân bằng cả ba: | Mục tiêu | Giải pháp | |---|---| | Sẵn sàng cao | min = 2, trải qua 3 AZ | | Co giãn nhanh khi có giải đấu | ASG mở rộng theo nhu cầu | | Tối ưu chi phí | RI cho phần nền, on-demand hoặc Spot cho phần đỉnh |

A — vì sao min = 2 chứ không phải 1 hay 3:

min = 1:
    → instance duy nhất hỏng → NGỪNG DỊCH VỤ hoàn toàn
    → không có sẵn sàng cao

min = 2:
    → một instance hỏng vẫn còn một cái phục vụ
    → ASG thay cái hỏng
    → CÂN BẰNG giữa sẵn sàng và chi phí

min = 3:
    → sẵn sàng cao hơn một chút
    → nhưng trả tiền thêm một instance chạy 24/7
    → đề yêu cầu "optimize your costs"

C — vì sao RI cho phần tối thiểu:

Phần năng lực TỐI THIỂU chạy 24/7 quanh năm
    → mẫu tải hoàn toàn dự đoán được
        ↓
    Reserved Instance hoặc Savings Plans:
    → giảm tới 72% so với on-demand

Và phần đỉnh khi có giải đấu dùng on-demand hoặc Spot:

Tải giải đấu:
    → không dự đoán được thời điểm chính xác
    → chỉ chạy vài giờ
        ↓
    On-demand (đảm bảo) hoặc Spot (rẻ, nếu chịu được gián đoạn)

Cấu hình trộn trong ASG:

{"MixedInstancesPolicy": {
   "InstancesDistribution": {
     "OnDemandBaseCapacity": 2,
     "OnDemandPercentageAboveBaseCapacity": 20,
     "SpotAllocationStrategy": "price-capacity-optimized"},
   "LaunchTemplate": {"Overrides": [
     {"InstanceType": "c6i.2xlarge"}, {"InstanceType": "c6a.2xlarge"},
     {"InstanceType": "m6i.2xlarge"}, {"InstanceType": "c5.2xlarge"}]}}}

OnDemandBaseCapacity: 2 đảm bảo hai máy nền luôn là on-demand — và RI tự áp cho chúng.

Vì sao các phương án khác sai

• **E. Đặt minimum capacity là 3 — đây là phương án gần nhất và cho sẵn sàng cao hơn (một máy mỗi AZ), nhưng nó kém tối ưu về chi phí: đề nêu rõ "optimize your costs" và máy chủ nhàn rỗi khi không có giải đấu. Hai máy đã đủ chịu được mất một instance.
• **D. Đặt minimum capacity là 1 — không có sẵn sàng cao: một instance hỏng là ngừng dịch vụ hoàn toàn cho tới khi ASG khởi động máy mới, mất vài phút.
• **B. Dùng Dedicated Hosts cho phần năng lực tối thiểu — đắt nhất trong mọi lựa chọn: Dedicated Host dành cho yêu cầu giấy phép hoặc tuân thủ về phần cứng đơn thuê, không phải để tối ưu chi phí.

Ghi nhớ

Nguyên tắc phân tầng chi phí EC2 — bảng phải thuộc:

Tải NỀN ổn định (chạy 24/7)
    → Savings Plans hoặc Reserved Instances (giảm tới 72%)

Tải BIẾN ĐỘNG, cần đảm bảo
    → On-Demand

Tải BIẾN ĐỘNG, chịu được gián đoạn
    → Spot (giảm tới 90%)

Bốn mô hình mua EC2: | Mô hình | Cam kết | Giảm giá | Đảm bảo năng lực | |---|---|---|---| | On-Demand | không | 0% | ✅ | | Savings Plans | 1 hoặc 3 năm theo USD/giờ | tới 72% | ❌ | | Reserved Instances (zonal) | 1 hoặc 3 năm | tới 72% | ✅ | | Spot | không | tới 90% | ❌ |

Savings Plans thường tốt hơn RI: | | Savings Plans | Reserved Instances | |---|---|---| | Cam kết theo | USD mỗi giờ | cấu hình cụ thể | | Đổi loại instance và Region | ✅ (Compute SP) | hạn chế | | Áp cho Fargate và Lambda | ✅ (Compute SP) | ❌ | | Bán lại | ❌ | ✅ (Standard RI) |

Công thức N+1 theo AZ:

Số máy mỗi AZ = (số máy cần phục vụ) ÷ (số AZ − 1)

Với 3 AZ và cần 1 máy phục vụ, min = 2 là đủ chịu được mất một máy.

Ba cấu hình ASG cho sẵn sàng cao: | Cấu hình | Giá trị nên dùng | |---|---| | MinSize | đủ chịu được mất một instance | | HealthCheckType = ELB | thay máy mà ứng dụng hỏng | | Trải qua nhiều AZ | ← đề đã có 3 AZ |

Ba cách co giãn nhanh cho giải đấu: | Cách | Chi tiết | |---|---| | Scheduled scaling | nếu biết trước lịch giải đấu | | Target tracking | phản ứng theo tải | | Warm pool | giữ sẵn máy đã cấu hình, chuyển vào phục vụ trong vài giây |

Warm pool rất phù hợp với tình huống này:

aws autoscaling put-warm-pool --auto-scaling-group-name asg-game   --min-size 5 --pool-state Stopped

Máy trong warm pool đã cài đặt xong
    → chuyển sang InService trong vài chục giây
    → thay vì vài phút khởi động từ đầu
        ↓
    Quan trọng với game — người chơi không chờ được

Và scheduled scaling nếu biết lịch:

aws autoscaling put-scheduled-update-group-action   --auto-scaling-group-name asg-game   --scheduled-action-name mo-rong-truoc-giai-dau   --start-time 2026-09-15T18:00:00Z --desired-capacity 20

Ba lưu ý về Reserved Instances: | Lưu ý | Chi tiết | |---|---| | RI áp TỰ ĐỘNG cho instance khớp thuộc tính | không phải gán tay | | Regional RI có size flexibility | 1 RI của c6i.4xlarge = 2 của c6i.2xlarge | | Regional RI KHÔNG đảm bảo năng lực | chỉ zonal RI có |

Ba cách xác định mức nền để mua cam kết: | Cách | Chi tiết | |---|---| | Cost Explorer RI/SP Recommendations | AWS phân tích lịch sử và đề xuất | | Xem biểu đồ mức dùng vài tháng | tìm đáy ổn định | | Mua thận trọng rồi bổ sung | mua thiếu sửa được, mua thừa thì không |

Ba cách dùng Spot cho phần đỉnh: | Cách | Chi tiết | |---|---| | Đa dạng hoá loại instance | quan trọng nhất | | price-capacity-optimized | cân bằng giá và năng lực | | Giữ mức nền on-demand | OnDemandBaseCapacity |

Ba lưu ý khi dùng Spot cho máy chủ game: | Lưu ý | Chi tiết | |---|---| | Spot bị thu hồi giữa trận đấu là trải nghiệm rất xấu | | | Cân nhắc chỉ dùng Spot cho tải phụ trợ | không cho máy chủ trận đấu | | Xử lý thông báo 2 phút để chuyển người chơi | |

Ba công cụ theo dõi: | Công cụ | Việc | |---|---| | Cost Explorer RI/SP Utilization | cam kết được dùng bao nhiêu phần trăm | | RI/SP Coverage | mức dùng được cam kết bao phủ bao nhiêu | | ASG Activity history | lịch sử co giãn |

Và một lời khuyên: hãy dùng warm pool thay vì tăng MinSize để chuẩn bị cho giải đấu. Warm pool giữ máy ở trạng thái Stopped nên không tính phí instance, chỉ tính phí EBS — vừa cho tốc độ mở rộng gần như tức thì, vừa không phải trả tiền cho năng lực nhàn rỗi giữa các giải đấu.

Đáp án

B — Cấu hình cụm Aurora dùng Aurora I/O-Optimized: cho thông lượng cao, độ trễ thấp với giá dự đoán được và KHÔNG tính phí theo I/O.

Vì sao đúng

Điểm mấu chốt: Aurora KHÔNG dùng các loại volume EBS như gp2 hay io1.

Aurora có kiến trúc lưu trữ RIÊNG:
    → tầng lưu trữ phân tán, 6 bản sao qua 3 AZ
    → tự mở rộng tới 128 TB
        ↓
    Không có khái niệm "chọn loại EBS volume" cho Aurora

Aurora chỉ có HAI cấu hình lưu trữ: | Cấu hình | Cách tính phí | |---|---| | Aurora Standard | phí lưu trữ + phí THEO SỐ I/O | | Aurora I/O-Optimized | phí lưu trữ và tính toán cao hơn, KHÔNG tính phí I/O |

Và với tải có đỉnh đột ngột, I/O-Optimized là lựa chọn đúng:

Aurora Standard:
    → sự kiện trực tiếp làm I/O tăng vọt
    → hoá đơn I/O tăng theo, KHÓ DỰ ĐOÁN

Aurora I/O-Optimized:
    → giá CỐ ĐỊNH bất kể số I/O
    → dự đoán được chi phí

Quy tắc chọn:

Nếu chi phí I/O vượt ~25% tổng chi phí Aurora
    → I/O-Optimized rẻ hơn
        ↓
    Với tải I/O nặng như trong đề, thường là như vậy

Bật I/O-Optimized:

aws rds modify-db-cluster --db-cluster-identifier cum-noi-dung   --storage-type aurora-iopt1 --apply-immediately

Và nó kết hợp tốt với Aurora Serverless v2:

Serverless v2: tự co giãn NĂNG LỰC TÍNH TOÁN
I/O-Optimized: hiệu năng I/O cao, giá dự đoán được
        ↓
    Cả compute lẫn I/O đều xử lý được đỉnh tải

Vì sao các phương án khác sai

• **A. Cấu hình cụm Aurora dùng General Purpose SSD (gp2) và tăng năng lực tính toán — đây là phương án gần nhất vì gp2 là loại lưu trữ có thật của AWS, nhưng nó không áp dụng cho Aurora: gp2 là loại volume của EBS, dùng cho RDS thường và EC2. Aurora có tầng lưu trữ riêng.
• **C. Chọn Provisioned IOPS (io1) và điều chỉnh IOPS thủ công — cùng lỗi: io1 là loại EBS, không dùng cho Aurora. Và "điều chỉnh thủ công" đi ngược yêu cầu "without manual provisioning or tuning".
• **D. Cấu hình với Magnetic (Standard) storage — cũng là loại EBS, và là loại chậm nhất, hoàn toàn không phù hợp.

Ghi nhớ

Hai cấu hình lưu trữ của Aurora — bảng phải thuộc: | | Aurora Standard | Aurora I/O-Optimized | |---|---|---| | Phí lưu trữ | thấp hơn | cao hơn ~2,25 lần | | Phí tính toán | chuẩn | cao hơn ~30% | | Phí I/O | tính theo số request | KHÔNG TÍNH | | Phù hợp | tải I/O thấp | tải I/O nặng, cần giá dự đoán được |

Điểm hoà vốn: khoảng 25% tổng chi phí đến từ I/O.

Ba đặc điểm kiến trúc lưu trữ của Aurora: | Đặc điểm | Chi tiết | |---|---| | 6 bản sao dữ liệu qua 3 AZ | tự sửa chữa khi phát hiện hỏng | | Tự mở rộng tới 128 TB | không cấp phát trước | | Tách rời khỏi tầng tính toán | replica dùng chung lưu trữ |

Và đó là lý do Aurora khác RDS: | | RDS | Aurora | |---|---|---| | Lưu trữ | EBS volume (gp2, gp3, io1) | tầng lưu trữ RIÊNG | | Sao chép | tầng database | tầng lưu trữ | | Bản sao dữ liệu | 2 (Multi-AZ) | 6 qua 3 AZ | | Cấp phát dung lượng | trước | tự động | | Read replica | 5, độ trễ giây | 15, độ trễ dưới 100ms |

Ba lựa chọn năng lực tính toán của Aurora: | Lựa chọn | Đặc điểm | |---|---| | Provisioned | chọn cỡ instance cố định | | Serverless v2 | tự co giãn từng giây, 0,5–256 ACU ← đề đang dùng | | Serverless v1 | cũ, co giãn nhảy bậc |

Aurora Serverless v2 khác v1 rất nhiều: | | v1 (cũ) | v2 | |---|---|---| | Co giãn | nhảy bậc, có gián đoạn | mượt, từng giây | | Multi-AZ | hạn chế | ✅ đầy đủ | | Read replica | ❌ | ✅ | | Global Database | ❌ | ✅ |

Ba khái niệm của Serverless v2: | Khái niệm | Chi tiết | |---|---| | ACU | khoảng 2 GiB bộ nhớ + CPU và mạng tương ứng | | MinCapacity | 0,5 ACU — không xuống 0 | | MaxCapacity | tới 256 ACU |

Cấu hình:

aws rds modify-db-cluster --db-cluster-identifier cum-noi-dung   --serverless-v2-scaling-configuration MinCapacity=2,MaxCapacity=64

Ba cách tối ưu I/O cho Aurora: | Cách | Chi tiết | |---|---| | Aurora I/O-Optimized | giá dự đoán được ← câu này | | Tăng bộ nhớ (buffer pool lớn hơn) | giảm số lần đọc từ lưu trữ | | Tối ưu truy vấn và index | giảm I/O gốc |

Điểm thứ hai đáng chú ý:

Instance lớn hơn → buffer pool lớn hơn
    → nhiều dữ liệu nằm trong bộ nhớ
    → ít đọc từ tầng lưu trữ
        ↓
    Với Aurora Standard, điều này giảm phí I/O trực tiếp

Ba cách theo dõi chi phí I/O: | Cách | Việc | |---|---| | CloudWatch VolumeReadIOPs và VolumeWriteIOPs | số I/O thực tế | | Cost Explorer lọc theo usage type | Aurora:StorageIOUsage | | Performance Insights | truy vấn nào gây nhiều I/O |

Và AWS có công cụ so sánh:

Trong console RDS, Aurora hiển thị ước tính
    chi phí giữa Standard và I/O-Optimized
    dựa trên mức dùng thực tế của bạn
        ↓
    Nên xem trước khi chuyển đổi

Ba lưu ý khi chuyển sang I/O-Optimized: | Lưu ý | Chi tiết | |---|---| | Chuyển đổi KHÔNG gián đoạn | áp dụng ngay | | Chỉ đổi được MỘT LẦN mỗi 30 ngày | cân nhắc kỹ | | Áp cho cả cụm | không riêng từng instance |

Ba tính năng khác của Aurora đáng biết: | Tính năng | Chi tiết | |---|---| | Database cloning (copy-on-write) | bản sao gần như tức thì cho môi trường thử nghiệm | | Backtrack (Aurora MySQL) | quay ngược thời gian tại chỗ | | Global Database | replica xuyên Region, độ trễ dưới 1 giây |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ServerlessDatabaseCapacity | ACU đang dùng | | ACUUtilization | gần MaxCapacity thì cần nâng trần | | VolumeReadIOPs | quyết định chọn Standard hay I/O-Optimized |

Và một lời khuyên: hãy xem tỷ lệ chi phí I/O trong hoá đơn tháng gần nhất trước khi chuyển sang I/O-Optimized. Nếu nó dưới 25% tổng chi phí Aurora thì Standard vẫn rẻ hơn — và vì chỉ đổi được một lần mỗi 30 ngày, quyết định dựa trên số liệu thật quan trọng hơn nhiều so với dựa trên dự đoán.

Đáp án

B — Trust policy.

Vì sao đúng

Đây là một chi tiết cụ thể về IAM: dịch vụ IAM chỉ hỗ trợ ĐÚNG MỘT loại resource-based policy, và đó là trust policy.

Resource-based policy = chính sách GẮN VÀO TÀI NGUYÊN
    → khai AI được phép làm gì với tài nguyên đó
        ↓
    Trong dịch vụ IAM, "tài nguyên" là IAM ROLE
    → và chính sách gắn vào role là TRUST POLICY

Trust policy làm gì:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Principal": {"Service": "ec2.amazonaws.com"},
   "Action": "sts:AssumeRole"}]}

Nó khai: AI ĐƯỢC PHÉP ĐẢM NHẬN role này
    → dịch vụ AWS (ec2, lambda)
    → tài khoản AWS khác
    → nhà cung cấp danh tính liên kết

Và mỗi IAM role có HAI loại chính sách: | Loại | Việc | |---|---| | Trust policy (resource-based) | AI được đảm nhận role | | Permissions policy (identity-based) | role LÀM ĐƯỢC GÌ |

Hai thứ này trả lời hai câu hỏi khác nhau:

Trust policy:       "Ai được mượn danh tính này?"
Permissions policy: "Danh tính này làm được gì?"

Xem trust policy:

aws iam get-role --role-name vai-tro-ung-dung   --query 'Role.AssumeRolePolicyDocument'

Vì sao các phương án khác sai

• **C. Permissions boundary — đây là phương án gần nhất và là một khái niệm quan trọng của IAM, nhưng nó là identity-based policy, không phải resource-based: boundary gắn vào một IAM user hoặc role để giới hạn quyền tối đa của thực thể đó.
• **A. Service Control Policy (SCP) — thuộc AWS Organizations, không phải IAM, và nó áp cho tài khoản hoặc OU, không gắn vào tài nguyên IAM.
• **D. Access control list (ACL) — không phải cơ chế của IAM: ACL là chính sách kiểu cũ của S3 (và một số dịch vụ khác), không thuộc dịch vụ IAM.

Ghi nhớ

Hai loại chính sách theo nơi gắn — bảng phải thuộc: | Loại | Gắn vào | Ví dụ | |---|---|---| | Identity-based policy | user, group, role | managed policy, inline policy | | Resource-based policy | TÀI NGUYÊN | trust policy, bucket policy, key policy |

Các dịch vụ có resource-based policy: | Dịch vụ | Tên gọi | |---|---| | IAM | trust policy (CHỈ MỘT loại) ← câu này | | S3 | bucket policy | | KMS | key policy | | SQS, SNS | queue/topic policy | | Lambda | resource policy (ai gọi được hàm) | | Secrets Manager | resource policy | | EFS | file system policy | | ECR, API Gateway, EventBridge | resource policy |

Quy tắc đánh giá quyền — bảng phải thuộc: | Ngữ cảnh | Yêu cầu | |---|---| | CÙNG tài khoản | identity policy HOẶC resource policy cho phép | | KHÁC tài khoản | CẢ HAI đều phải cho phép |

Ba thành phần của trust policy: | Thành phần | Chi tiết | |---|---| | Principal | ai được đảm nhận | | Action | thường là sts:AssumeRole | | Condition | ràng buộc thêm (MFA, ExternalId, IP) |

Bốn loại principal trong trust policy: | Loại | Ví dụ | |---|---| | Service | {"Service": "ec2.amazonaws.com"} | | AWS account | {"AWS": "arn:aws:iam::123456789012:root"} | | IAM role hoặc user cụ thể | {"AWS": "arn:aws:iam::123456789012:role/abc"} | | Federated | {"Federated": "arn:aws:iam::...:oidc-provider/..."} |

Ba biến thể của sts:AssumeRole: | Action | Dùng khi | |---|---| | sts:AssumeRole | dịch vụ AWS hoặc tài khoản khác | | sts:AssumeRoleWithWebIdentity | OIDC (Cognito, GitHub Actions, IRSA) | | sts:AssumeRoleWithSAML | liên kết SAML (Active Directory) |

Ba điều kiện quan trọng trong trust policy: | Điều kiện | Việc | |---|---| | sts:ExternalId | chống "confused deputy" với bên thứ ba | | aws:MultiFactorAuthPresent | bắt buộc MFA | | aws:SourceIp | giới hạn IP |

ExternalId bắt buộc khi cấp quyền cho nhà cung cấp dịch vụ bên ngoài:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::999988887777:root"},
 "Action": "sts:AssumeRole",
 "Condition": {"StringEquals": {"sts:ExternalId": "chuoi-bi-mat-rieng"}}}

Không có nó:
    → nhà cung cấp có thể bị lừa dùng quyền của bạn cho khách hàng khác
    → đó là lỗ hổng "confused deputy"

Ba loại chính sách khác của IAM (đều là identity-based): | Loại | Việc | |---|---| | Managed policy | dùng lại được, gắn cho nhiều thực thể | | Inline policy | gắn chặt với một thực thể | | Permissions boundary | giới hạn quyền TỐI ĐA của một user hoặc role |

Permissions boundary — nhắc lại vì là phương án nhiễu:

Boundary KHÔNG cấp quyền
    → nó GIỚI HẠN mức quyền tối đa
        ↓
Quyền hiệu lực = identity policy ∩ permissions boundary

Và boundary CHỈ gắn được vào user và role, không gắn vào group.

Công thức quyền hiệu lực đầy đủ:

Quyền = SCP ∩ identity policy ∩ permissions boundary ∩ session policy
        và KHÔNG có explicit Deny nào ở bất kỳ tầng nào

Ba lưu ý về trust policy: | Lưu ý | Chi tiết | |---|---| | Sửa được bất cứ lúc nào | không cần dừng gì | | Khai principal CỤ THỂ tốt hơn :root | chặt chẽ hơn | | Kiểm tra định kỳ | phát hiện role tin cậy quá rộng |

Và IAM Access Analyzer phát hiện trust policy quá rộng:

aws accessanalyzer create-analyzer --analyzer-name phan-tich --type ACCOUNT

Nó báo:
    → role nào tin cậy tài khoản ngoài
    → bucket nào chia sẻ ra ngoài
    → khoá KMS nào cho phép bên ngoài dùng

Ba công cụ kiểm tra: | Công cụ | Việc | |---|---| | IAM Policy Simulator | thử một hành động | | IAM Access Analyzer | tìm truy cập từ ngoài tài khoản | | CloudTrail | xem ai đã đảm nhận role nào |

Và một lời khuyên: hãy đặt RoleSessionName có ý nghĩa khi gọi AssumeRole. Trust policy quyết định ai được mượn danh tính, nhưng CloudTrail chỉ truy được về đúng cá nhân nếu tên phiên phản ánh danh tính thật — và đó là điều duy nhất giúp bạn trả lời "ai đã làm việc này" khi nhiều người dùng chung một role.

Đáp án

D — Dùng Cluster placement group.

Vì sao đúng

Đề nêu hai điểm, và cả hai đều dẫn tới cluster placement group: | Điểm trong đề | Kết luận | |---|---| | Framework xử lý dữ liệu phân tán chạy tốt nhất khi HIỆU NĂNG MẠNG giữa các máy CAO | cần độ trễ thấp và băng thông cao giữa node | | Chỉ quan tâm HIỆU NĂNG | không phải cân nhắc chi phí hay chịu lỗi |

Cluster placement group tối ưu đúng điều đó:

Cluster placement group:
    → đặt instance RẤT GẦN NHAU về mặt vật lý
    → cùng rack hoặc rack liền kề trong MỘT AZ
        ↓
    ✓ độ trễ mạng THẤP NHẤT
    ✓ băng thông tới 100 Gbps giữa các instance
    ✓ tỷ lệ mất gói gần như bằng 0

Và đề nói rõ "chỉ nhìn vào hiệu năng":

Đánh đổi của cluster placement group:
    ✗ mọi instance ở MỘT AZ
    ✗ AZ hỏng là mất cả cụm
        ↓
    Nhưng đề đã loại bỏ mối lo đó
    → hiệu năng là tiêu chí DUY NHẤT

Cấu hình:

aws ec2 create-placement-group --group-name cum-big-data --strategy cluster

aws ec2 run-instances --image-id ami-0abc --instance-type c6in.32xlarge   --count 20 --placement GroupName=cum-big-data   --network-interfaces '[{"DeviceIndex":0,"InterfaceType":"efa","SubnetId":"subnet-a"}]'

Và ba lời khuyên đi kèm: | Lời khuyên | Lý do | |---|---| | Dùng CÙNG loại instance | giảm nguy cơ thiếu năng lực | | Khởi động HẾT trong MỘT lời gọi API | AWS tìm đủ chỗ trước | | Chọn instance có băng thông mạng cao | c6in, c7gn, hoặc họ hpc* |

Vì sao các phương án khác sai

• **A. Dùng Spread placement group — đây là phương án gần nhất và cũng là placement group, nhưng nó tối ưu NGƯỢC LẠI: spread trải instance ra XA NHAU trên phần cứng khác biệt để giảm rủi ro hỏng cùng lúc. Điều đó tăng độ trễ mạng — đúng thứ framework này không chịu được.
• **C. Dùng Spot Instances — là mô hình GIÁ, không phải cấu hình hiệu năng: Spot giảm chi phí nhưng không cải thiện hiệu năng mạng, và còn bị thu hồi bất cứ lúc nào.
• **B. Tối ưu kernel của EC2 qua User Data — cải thiện rất nhỏ so với vấn đề gốc: tinh chỉnh tham số kernel có thể giúp vài phần trăm, nhưng nút thắt là vị trí vật lý của các máy trong trung tâm dữ liệu — thứ chỉ placement group giải quyết được.

Ghi nhớ

Ba loại placement group — bảng phải thuộc: | Loại | Mục tiêu | Phạm vi | Giới hạn | |---|---|---|---| | Cluster | độ trễ thấp, thông lượng cao | MỘT AZ | nên dùng cùng loại instance | | Spread | tối đa hoá cách ly lỗi | nhiều AZ | 7 instance mỗi AZ | | Partition | giới hạn phạm vi ảnh hưởng | nhiều AZ | 7 phân vùng mỗi AZ |

Từ khoá nhận diện — bảng quan trọng:

"HPC", "MPI", "tightly coupled", "low latency between nodes", "performance only" → cluster "critical instances must not share hardware", "reduce correlated failures" → spread "HDFS", "Cassandra", "Kafka", "large distributed workload aware of topology" → partition

Và partition đáng cân nhắc cho big data:

Partition placement group:
    → chia instance thành các PHÂN VÙNG
    → mỗi phân vùng dùng bộ rack RIÊNG
        ↓
    Hadoop, Cassandra, Kafka biết được instance nào ở phân vùng nào
    → đặt bản sao dữ liệu ở phân vùng khác nhau
    → hỏng một rack không mất dữ liệu

Nhưng đề nói rõ "chỉ nhìn hiệu năng" — nên cluster vẫn là đáp án.

Ba đặc điểm của cluster placement group: | Đặc điểm | Chi tiết | |---|---| | Một AZ duy nhất | đánh đổi: AZ hỏng là mất cả cụm | | Nên dùng cùng loại instance | | | Khởi động hết trong một lời gọi | tránh InsufficientInstanceCapacity |

Và EFA là bổ sung quan trọng: | | ENA | EFA | |---|---|---| | Bỏ qua kernel (OS bypass) | ❌ | ✅ | | Độ trễ | vài chục micro giây | dưới 20 micro giây | | Hỗ trợ MPI và NCCL | ❌ | ✅ | | Hệ điều hành | mọi loại | CHỈ LINUX |

Ba nhóm instance cho hiệu năng mạng cao: | Nhóm | Đặc điểm | |---|---| | c6in, c7gn | băng thông mạng rất cao (tới 200 Gbps) | | hpc7a, hpc7g | thiết kế cho HPC, miễn phí truyền trong placement group | | p5, p4d | GPU cho học máy |

Ba lưu ý khi dùng placement group: | Lưu ý | Chi tiết | |---|---| | Có thể gặp InsufficientInstanceCapacity | cụm càng lớn càng dễ | | Chuyển instance đang chạy vào group phải STOP trước | | | Không trộn nhiều loại instance | tăng nguy cơ thiếu chỗ |

Và Capacity Reservation đảm bảo có chỗ:

aws ec2 create-capacity-reservation --instance-type c6in.32xlarge   --instance-platform Linux/UNIX --availability-zone ap-northeast-1a   --instance-count 20 --placement-group-arn <arn-placement-group>

Ba thành phần của cụm big data hiệu năng cao: | Thành phần | Lựa chọn | |---|---| | Tính toán | EC2 trong cluster placement group + EFA | | Lưu trữ chia sẻ | FSx for Lustre | | Điều phối | EMR, hoặc tự quản lý |

Amazon EMR đáng cân nhắc:

EMR:
    ✓ tự dựng cụm Hadoop, Spark, Presto
    ✓ hỗ trợ placement group
    ✓ tích hợp S3 (EMRFS)
    ✓ tự co giãn
        ↓
    Ít công hơn tự dựng cụm trên EC2

Ba cách đo hiệu năng mạng:

# Băng thông
iperf3 -c <ip-node-khac> -P 8

# Độ trễ
ping -c 100 <ip-node-khac>

# Với EFA, dùng bài kiểm tra MPI
mpirun -n 2 osu_latency

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Placement group MIỄN PHÍ | chỉ trả tiền instance | | Truyền dữ liệu trong cùng AZ | miễn phí với IP riêng | | Họ hpc* miễn phí truyền trong placement group | |

Ba lựa chọn tối ưu hiệu năng khác: | Cách | Chi tiết | |---|---| | Instance store NVMe | I/O cục bộ nhanh nhất | | Enhanced networking (ENA hoặc EFA) | | | Chọn instance có băng thông cao | |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | NetworkIn/Out | băng thông đang dùng | | NetworkPacketsIn/Out | số gói | | Thời gian hoàn thành công việc | chỉ số cuối cùng |

Và một lời khuyên: hãy đo hiệu năng mạng ngay sau khi dựng cụm bằng iperf3 giữa vài cặp node. Cluster placement group không phải lúc nào cũng đặt được mọi máy tối ưu, và biết con số thật giúp bạn phân biệt "framework chạy chậm" với "mạng không như kỳ vọng" — hai vấn đề có cách xử lý hoàn toàn khác nhau.

Đáp án

D — Nó cho phép TOÀN BỘ khối CIDR TRỪ MỘT địa chỉ IP truy cập bucket S3.

Vì sao đúng

Chính sách có hai điều kiện trong CÙNG một block Condition, và chúng được kết hợp bằng AND:

"Condition": {
  "IpAddress":    {"aws:SourceIp": "54.240.143.0/24"},
  "NotIpAddress": {"aws:SourceIp": "54.240.143.188/32"}
}

Cách đọc:

Điều kiện ① IpAddress:    IP nguồn PHẢI nằm trong 54.240.143.0/24
Điều kiện ② NotIpAddress: IP nguồn KHÔNG được là 54.240.143.188
        ↓
    Kết hợp bằng AND
    → cho phép dải 54.240.143.0/24 NGOẠI TRỪ .188

Minh hoạ:

54.240.143.0/24 chứa 256 địa chỉ (từ .0 tới .255)
    → 255 địa chỉ được phép
    → riêng .188 bị loại

Và quy tắc quan trọng: nhiều điều kiện trong một Condition block luôn là AND.

"Condition": {
  "ToanTuA": {...},     ← AND
  "ToanTuB": {...}      ← AND
}

Muốn OR thì phải tách thành nhiều statement.

Kiểm chứng bằng Policy Simulator:

aws iam simulate-custom-policy   --policy-input-list file://policy.json   --action-names s3:GetObject   --resource-arns "arn:aws:s3:::examplebucket/tep.txt"   --context-entries 'ContextKeyName=aws:SourceIp,ContextKeyValues=54.240.143.188,ContextKeyType=ip'

Vì sao các phương án khác sai

• **B. Nó cho phép một địa chỉ IP và một CIDR truy cập bucket — đây là phương án gần nhất và nhắc đúng hai thành phần trong chính sách, nhưng nó hiểu sai vai trò của NotIpAddress: điều kiện đó LOẠI TRỪ địa chỉ .188, không phải cho phép thêm nó.
• **C. Nó đảm bảo bucket phơi ra một IP bên ngoài trong dải CIDR, trừ một IP — hiểu sai bản chất: bucket policy kiểm soát AI ĐƯỢC TRUY CẬP, nó không "phơi ra" địa chỉ IP nào cả.
• **A. Nó đảm bảo EC2 instance kế thừa security group truy cập được bucket — nhầm khái niệm hoàn toàn: bucket policy không liên quan tới security group, và aws:SourceIp nói về IP công cộng của người gọi.

Ghi nhớ

Quy tắc kết hợp điều kiện trong IAM — bảng phải thuộc: | Cấu trúc | Kết hợp bằng | |---|---| | Nhiều TOÁN TỬ trong một Condition | AND | | Nhiều KHOÁ trong một toán tử | AND | | Nhiều GIÁ TRỊ của một khoá | OR | | Nhiều STATEMENT | OR (bất kỳ Allow nào khớp là đủ) |

Ví dụ minh hoạ ba dòng đầu:

"Condition": {
  "IpAddress": {"aws:SourceIp": ["1.2.3.0/24", "5.6.7.0/24"]},  ← OR giữa hai dải
  "Bool": {"aws:SecureTransport": "true"}                        ← AND với dòng trên
}

Đọc là: (IP thuộc dải 1 HOẶC dải 2) VÀ (dùng HTTPS).

Các toán tử điều kiện cho IP: | Toán tử | Khớp khi | |---|---| | IpAddress | IP THUỘC dải | | NotIpAddress | IP KHÔNG thuộc dải |

Và mẫu "cho phép dải trừ một IP" là cách dùng chuẩn của cặp này.

Ba mẫu chính sách thường gặp: | Mẫu | Cách viết | |---|---| | Chỉ cho phép một dải | Allow + IpAddress | | Chặn một dải | Deny + IpAddress | | Cho phép dải trừ vài IP | Allow + IpAddress + NotIpAddress ← câu này |

Và cách viết an toàn hơn dùng Deny:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": "arn:aws:s3:::examplebucket/*",
 "Condition": {"NotIpAddress": {"aws:SourceIp": "54.240.143.0/24"}}}

Deny mạnh hơn Allow — nó thắng mọi chính sách cho phép khác.

Ba cạm bẫy của aws:SourceIp: | Cạm bẫy | Chi tiết | |---|---| | KHÔNG hoạt động qua VPC ENDPOINT | dùng aws:SourceVpce thay | | KHÔNG áp khi dịch vụ AWS gọi thay bạn | thêm aws:ViaAWSService | | Chỉ khớp IP CÔNG CỘNG | |

Cạm bẫy đầu tiên gây sự cố thật:

Bucket policy chặn theo aws:SourceIp
    → EC2 ở private subnet gọi S3 qua gateway endpoint
    → request KHÔNG có SourceIp công cộng
        ↓
    Bị TỪ CHỐI dù đúng ra phải được phép

Cách sửa:

"Condition": {
  "IpAddress": {"aws:SourceIp": "54.240.143.0/24"},
  "Bool": {"aws:ViaAWSService": "false"}}

Hoặc thêm statement riêng cho aws:SourceVpce.

Ba quy tắc đánh giá chính sách:

① Mặc định: TỪ CHỐI ngầm định
② Explicit Allow → cho phép
③ Explicit DENY → TỪ CHỐI, thắng mọi Allow

Và thứ tự xét đầy đủ:

Organizations SCP → Resource policy → Identity policy
    → Permissions boundary → Session policy
        ↓
    Một tầng Deny là toàn bộ bị từ chối

Ba lưu ý về bucket policy: | Lưu ý | Chi tiết | |---|---| | Principal là BẮT BUỘC | khác identity policy | | Resource phải khớp loại hành động | bucket ARN cho ListBucket, object ARN cho GetObject | | Giới hạn 20 KB | chính sách dài phải chia nhỏ |

Dòng giữa là lỗi rất phổ biến:

s3:ListBucket   → arn:aws:s3:::mybucket
s3:GetObject    → arn:aws:s3:::mybucket/*
        ↓
    Ghép sai thì hành động đó không bao giờ khớp

Ba khoá điều kiện riêng của S3: | Khoá | Việc | |---|---| | s3:prefix | giới hạn ListBucket theo thư mục | | s3:x-amz-server-side-encryption | bắt buộc mã hoá khi ghi | | s3:x-amz-acl | giới hạn ACL được đặt |

Ba biện pháp bảo vệ bucket nên có: | Biện pháp | Chi tiết | |---|---| | Block Public Access ở mức TÀI KHOẢN | ngăn cấu hình sai | | Bắt buộc HTTPS | aws:SecureTransport | | Bật versioning và CloudTrail data event | |

Bắt buộc HTTPS:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::examplebucket",
              "arn:aws:s3:::examplebucket/*"],
 "Condition": {"Bool": {"aws:SecureTransport": "false"}}}

Ba công cụ kiểm tra: | Công cụ | Việc | |---|---| | IAM Policy Simulator | thử với giá trị aws:SourceIp cụ thể | | IAM Access Analyzer | tìm bucket chia sẻ ra ngoài | | CloudTrail | xem request bị từ chối |

Và một lời khuyên: hãy chú ý dấu hiệu cảnh báo khi thấy Principal: "*" trong bucket policy. Ở đây nó an toàn vì có điều kiện IP đi kèm, nhưng nếu ai đó sửa hoặc xoá nhầm khối Condition, bucket lập tức mở cho toàn Internet — nên hãy bật Block Public Access ở cấp tài khoản làm lưới an toàn.

Đáp án

D — Warm Standby.

Vì sao đúng

Đề mô tả chính xác định nghĩa của Warm Standby:

"a SCALED-DOWN version of a FULLY FUNCTIONAL environment
 is ALWAYS RUNNING in the AWS cloud"
        ↓
    ✓ đầy đủ chức năng (fully functional)
    ✓ quy mô nhỏ (scaled-down)
    ✓ LUÔN CHẠY (always running)
        ↓
    Đó chính là Warm Standby

Bốn chiến lược khôi phục thảm hoạ — bảng phải thuộc: | Chiến lược | Chạy gì ở AWS | RTO | RPO | Chi phí | |---|---|---|---|---| | Backup & Restore | CHỈ dữ liệu | giờ | giờ | thấp nhất | | Pilot Light | database chạy, ứng dụng TẮT | chục phút | phút | thấp | | Warm Standby | MỌI tầng chạy ở quy mô NHỎ | phút | giây–phút | trung bình | | Multi-site active/active | đủ quy mô, phục vụ THẬT | gần 0 | gần 0 | cao nhất |

Và điểm phân biệt giữa Pilot Light và Warm Standby:

Pilot Light:
    → database sao chép liên tục
    → nhưng máy chủ ứng dụng TẮT
    → khi sự cố: phải KHỞI ĐỘNG chúng lên

Warm Standby:
    → MỌI tầng đang CHẠY, chỉ ở quy mô nhỏ
    → khi sự cố: chỉ cần MỞ RỘNG và chuyển lưu lượng
        ↓
    Nhanh hơn đáng kể

Kiến trúc Warm Standby điển hình:

Trung tâm dữ liệu (chính)     AWS (warm standby)
    Web tier đầy đủ      →     2 EC2 sau ALB (đang chạy)
    Database chính       →     RDS read replica (đang sao chép)
    Storage              →     S3 với DataSync đồng bộ
        ↓
    Route 53 failover record trỏ về trung tâm dữ liệu
    → sự cố → chuyển sang AWS

Và khi chuyển vùng:

① Route 53 health check phát hiện sự cố
② Chuyển bản ghi DNS sang ALB trên AWS
③ ASG mở rộng từ 2 lên số máy cần thiết
④ Promote read replica thành primary
        ↓
    RTO tính bằng PHÚT

Vì sao các phương án khác sai

• **B. Pilot Light — đây là phương án gần nhất và cũng có sao chép liên tục, nhưng nó không phải "fully functional environment always running": trong Pilot Light, tầng ứng dụng TẮT (chỉ có AMI và cấu hình sẵn sàng), phải khởi động lên khi có sự cố. Đề nói rõ môi trường đầy đủ chức năng và luôn chạy.
• **A. Multi Site — quy mô ĐẦY ĐỦ, không phải scaled-down: multi-site active/active chạy đủ năng lực ở cả hai nơi và cùng phục vụ lưu lượng. Nó cho RTO gần bằng 0 nhưng chi phí cao nhất, và đề nói rõ "scaled-down version".
• **C. Backup and Restore — không có gì chạy ở AWS: chỉ có dữ liệu sao lưu, phải dựng toàn bộ hạ tầng khi có sự cố. RTO tính bằng giờ.

Ghi nhớ

Bốn chiến lược khôi phục thảm hoạ — nhớ theo mức độ:

Backup & Restore  →  Pilot Light  →  Warm Standby  →  Multi-site
    ↑ rẻ nhất, chậm nhất              nhanh nhất, đắt nhất ↑

Từ khoá nhận diện — bảng quan trọng nhất:

"scaled-down but fully functional, always running" → Warm Standby "database replicating, application servers off" → Pilot Light "restore from backup when disaster strikes" → Backup & Restore "active-active, both sites serving traffic" → Multi-site

Hai khái niệm cốt lõi: | Khái niệm | Nghĩa | |---|---| | RPO (Recovery Point Objective) | mất bao nhiêu DỮ LIỆU | | RTO (Recovery Time Objective) | bao lâu để HOẠT ĐỘNG TRỞ LẠI |

Và hai chỉ số này quyết định chọn chiến lược nào:

RTO vài giờ, RPO vài giờ    → Backup & Restore
RTO chục phút, RPO phút     → Pilot Light
RTO phút, RPO giây          → Warm Standby
RTO gần 0, RPO gần 0        → Multi-site

Ba thành phần của Warm Standby: | Tầng | Cấu hình | |---|---| | Web/ứng dụng | ASG với số máy tối thiểu, sau ALB | | Database | read replica sao chép liên tục | | Lưu trữ | S3 với replication hoặc DataSync |

Ba cơ chế chuyển vùng: | Cơ chế | Tốc độ | |---|---| | Route 53 failover record | phút, phụ thuộc TTL | | Global Accelerator | ~30 giây, không phụ thuộc DNS | | Route 53 Application Recovery Controller | kiểm soát chủ động, đắt hơn |

Route 53 failover:

aws route53 create-health-check --caller-reference $(uuidgen)   --health-check-config '{"IPAddress":"203.0.113.10","Port":443,
    "Type":"HTTPS","ResourcePath":"/health",
    "RequestInterval":10,"FailureThreshold":2}'

RequestInterval=10 và FailureThreshold=2 cho phát hiện trong ~20–30 giây.

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | TTL thấp (60 giây) | chuyển vùng nhanh hơn | | Client cache DNS | một số bỏ qua TTL | | Global Accelerator không phụ thuộc DNS | lựa chọn tốt hơn nếu cần nhanh |

Ba việc phải làm để Warm Standby thực sự sẵn sàng: | Việc | Chi tiết | |---|---| | DIỄN TẬP chuyển vùng định kỳ | quan trọng nhất | | Giữ AMI và cấu hình đồng bộ | môi trường dự phòng chạy được mã hiện tại | | Đảm bảo ASG mở rộng KỊP | quy mô nhỏ phải tăng được khi nhận toàn bộ tải |

Dòng cuối là điểm hay bị bỏ sót:

Warm standby chạy 2 máy
    → khi nhận toàn bộ lưu lượng cần 20 máy
        ↓
    Nếu ASG mở rộng chậm, hệ thống sập ngay sau khi chuyển vùng

Ba cách rút ngắn thời gian mở rộng: | Cách | Chi tiết | |---|---| | Warm pool của ASG | máy đã cấu hình sẵn ở trạng thái Stopped | | AMI có sẵn ứng dụng | không cài đặt lúc khởi động | | Kiểm tra hạn mức instance ở Region dự phòng | hạn mức thấp là chặn mở rộng |

Dòng cuối rất thực tế:

Region dự phòng ít dùng
    → hạn mức số vCPU thấp
    → mở rộng lên 20 máy bị từ chối
        ↓
    → Yêu cầu nâng hạn mức TRƯỚC, không phải lúc có sự cố

Ba dịch vụ hỗ trợ khôi phục thảm hoạ: | Dịch vụ | Việc | |---|---| | AWS Elastic Disaster Recovery (DRS) | sao chép liên tục máy chủ tại chỗ lên AWS | | AWS Backup | sao lưu tập trung nhiều dịch vụ | | Route 53 ARC | kiểm soát chuyển vùng có sẵn sàng |

AWS Elastic Disaster Recovery đáng biết:

DRS:
    ✓ sao chép liên tục ở mức khối từ máy chủ tại chỗ
    ✓ RPO tính bằng GIÂY
    ✓ RTO tính bằng PHÚT
    ✓ chỉ trả tiền cho vùng lưu trữ nhỏ khi chờ
        ↓
    Cho kết quả gần Warm Standby với chi phí gần Pilot Light

Ba lưu ý về chi phí Warm Standby: | Lưu ý | Chi tiết | |---|---| | Trả tiền cho hạ tầng chạy 24/7 | dù ở quy mô nhỏ | | Read replica là một instance đầy đủ | | | Cân nhắc DRS nếu chi phí là vấn đề | |

Ba lưu ý cho công ty dịch vụ tài chính: | Lưu ý | Chi tiết | |---|---| | Yêu cầu quy định về RTO và RPO | thường rất chặt | | Phải chứng minh đã diễn tập | kiểm toán viên sẽ hỏi | | Ghi lại kết quả mỗi lần diễn tập | thời gian thực tế đạt được |

Và một lời khuyên: hãy diễn tập chuyển vùng ít nhất mỗi quý và ghi lại RTO thực tế. Khác biệt giữa "có kế hoạch khôi phục" và "kế hoạch chạy được" chỉ lộ ra khi thử thật — thường ở những chi tiết nhỏ như chứng chỉ hết hạn, hạn mức instance không đủ, hay một biến môi trường trỏ sai địa chỉ.

Đáp án

B — Mỗi target trong bốn target ở AZ-A nhận 12,5% lưu lượng.

Vì sao đúng

Đây là bài toán tính toán hai bước, và điểm mấu chốt là cross-zone load balancing bị TẮT.

Bước ①: Route 53 chia đều cho các NODE của NLB
    → 2 node (một ở mỗi AZ)
    → mỗi node nhận 50%

Bước ②: TẮT cross-zone → mỗi node CHỈ phân phối cho target TRONG AZ của nó
    → AZ-A: 50% ÷ 4 target = 12,5% mỗi cái
    → AZ-B: 50% ÷ 6 target = ~8,33% mỗi cái

Bảng kết quả: | Vị trí | Số target | Tổng lưu lượng | Mỗi target | |---|---|---|---| | AZ-A | 4 | 50% | 12,5% ← đáp án | | AZ-B | 6 | 50% | ~8,33% |

Và đây chính là lý do phải cân bằng số target giữa các AZ khi tắt cross-zone:

Số target lệch nhau + tắt cross-zone
    → target ở AZ ít máy bị QUÁ TẢI
    → target ở AZ nhiều máy NHÀN RỖI
        ↓
    Ở đây máy ở AZ-A gánh nhiều hơn máy ở AZ-B khoảng 1,5 lần

Nếu BẬT cross-zone thì khác hẳn:

Load balancer coi mọi target là một nhóm duy nhất
    → 10 target tổng cộng
    → mỗi target nhận 10%

Bật cross-zone cho NLB:

aws elbv2 modify-target-group-attributes --target-group-arn <arn>   --attributes Key=load_balancing.cross_zone.enabled,Value=true

Vì sao các phương án khác sai

• **C. Mỗi target ở AZ-A nhận 10% — đây là phương án gần nhất và là con số đúng KHI BẬT cross-zone (10 target chia đều 100%), nhưng đề nói rõ cross-zone đã TẮT.
• **A. Mỗi target ở AZ-B nhận 10% — cùng lỗi, và con số đúng cho AZ-B khi tắt cross-zone là ~8,33%.
• **D. Mỗi target ở AZ-A nhận 8% — nhầm với con số của AZ-B (và cũng không chính xác — AZ-B là 8,33%).

Ghi nhớ

Cross-zone load balancing — nguyên tắc phải thuộc:

BẬT:  chia đều cho MỌI target, bất kể AZ
TẮT:  chia đều cho mỗi AZ trước, rồi chia trong AZ

Mặc định khác nhau giữa các loại load balancer: | Loại | Mặc định | Phí truyền chéo AZ | |---|---|---| | Application Load Balancer | BẬT (không tắt được ở mức LB) | miễn phí | | Network Load Balancer | TẮT | TÍNH PHÍ khi bật | | Gateway Load Balancer | TẮT | tính phí khi bật | | Classic Load Balancer | tuỳ cách tạo | miễn phí |

Đây là bảng được hỏi rất thường xuyên.

Ba lý do vẫn có người tắt cross-zone cho NLB: | Lý do | Chi tiết | |---|---| | Tiết kiệm phí truyền chéo AZ | với lưu lượng lớn thì đáng kể | | Cách ly lỗi theo AZ | sự cố một AZ không lan sang AZ khác | | Giữ độ trễ thấp nhất | lưu lượng không rời AZ |

Và điều kiện để tắt an toàn:

Số target ở mỗi AZ phải CÂN BẰNG
    → dùng ASG trải đều qua các AZ
        ↓
    Nếu không, phân phối lệch như trong câu hỏi này

Ba cơ chế ASG duy trì phân bố đều: | Cơ chế | Chi tiết | |---|---| | AZ rebalancing | tự cân bằng khi lệch | | Chấm dứt từ AZ có nhiều máy nhất | chính sách mặc định | | Khởi động vào AZ có ít máy nhất | khi mở rộng |

ALB, NLB và GWLB — bảng phân biệt: | | ALB | NLB | GWLB | |---|---|---|---| | Tầng | 7 (HTTP) | 4 (TCP/UDP) | 3 (IP) | | Cross-zone mặc định | BẬT | TẮT | TẮT | | Định tuyến theo nội dung | ✅ | ❌ | ❌ | | IP tĩnh | ❌ | ✅ Elastic IP mỗi AZ | — | | WAF | ✅ | ❌ | ❌ |

Ba đặc điểm của NLB: | Đặc điểm | Chi tiết | |---|---| | Hàng triệu request/giây | độ trễ ~100 micro giây | | Hỗ trợ TCP, UDP, TLS | | | Giữ IP nguồn của client | với target type instance |

Ba loại target type: | Loại | Định tuyến bằng | |---|---| | instance | IP RIÊNG chính của ENI | | ip | địa chỉ IP bạn khai | | alb | ALB làm target của NLB |

Ba cách kiểm chứng phân phối thực tế: | Cách | Việc | |---|---| | CloudWatch metric theo target group | số request | | Access log của ALB | đếm request theo target | | Metric ở tầng ứng dụng | |

Ba lưu ý về phí truyền dữ liệu: | Chiều | Chi phí | |---|---| | Chéo AZ (EC2) | ~0,01 USD/GB mỗi chiều | | Trong cùng AZ, IP riêng | miễn phí | | ALB cross-zone | miễn phí | | NLB cross-zone | tính phí |

Ba lưu ý khi thiết kế nhiều AZ: | Lưu ý | Chi tiết | |---|---| | Ba AZ tiết kiệm hơn hai AZ cho cùng mức chịu lỗi | | | Giữ số target cân bằng giữa các AZ | ← điểm của câu này | | MinSize đủ chịu tải khi mất một AZ | |

Công thức N+1 theo AZ:

Số máy mỗi AZ = (số máy cần phục vụ) ÷ (số AZ − 1)

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | HealthyHostCount theo AZ | phát hiện lệch | | RequestCount theo target group | | | ActiveFlowCount (NLB) | số kết nối đang mở |

Và một lời khuyên: hãy kiểm tra số target ở mỗi AZ khi thấy một số máy bận hơn hẳn máy khác. Với NLB tắt cross-zone theo mặc định, phân bố lệch là nguyên nhân phổ biến nhất — và nó không hiện ra trong bất kỳ cảnh báo nào, chỉ lộ qua metric CPU chênh lệch giữa các máy.