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

Đáp án

D — CÓ phí truyền dữ liệu khi sao chép XUYÊN REGION.

Vì sao đúng

Đây là nguyên tắc giá chung của AWS áp cho read replica:

Sao chép TRONG cùng một Region (kể cả chéo AZ):
    → MIỄN PHÍ

Sao chép XUYÊN Region:
    → tính phí truyền dữ liệu, ~0,02 USD/GB

Bảng đầy đủ về phí truyền dữ liệu của RDS read replica: | Phạm vi | Chi phí | |---|---| | Cùng AZ | miễn phí | | Chéo AZ, cùng Region | miễn phí | | Xuyên Region | ~0,02 USD/GB |

Vì sao AWS miễn phí sao chép trong Region:

Multi-AZ và read replica trong Region là mẫu kiến trúc
mà AWS KHUYẾN KHÍCH cho sẵn sàng cao
    → tính phí sẽ làm nản lòng thực hành tốt
        ↓
    Miễn phí phần này

Và xuyên Region tính phí vì đó là truyền dữ liệu qua hạ tầng liên lục địa:

Read replica ở Region khác:
    → mọi thay đổi phải vượt qua đường truyền dài
    → chi phí hạ tầng thật

Ước lượng cho một database ghi 100 GB mỗi tháng:

100 GB × 0,02 USD = 2 USD/tháng cho phí sao chép xuyên Region

Nghe nhỏ, nhưng với database ghi nhiều thì con số này lớn nhanh — và nó thường bị bỏ sót khi lập ngân sách.

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

• **A. KHÔNG có phí truyền dữ liệu khi sao chép xuyên Region — đây là phương án gần nhất vì nó nói về đúng phạm vi, nhưng nó đảo ngược kết luận: xuyên Region chính là trường hợp DUY NHẤT có tính phí.
• **C. CÓ phí khi sao chép trong cùng Region — sai: sao chép trong Region miễn phí, kể cả chéo AZ.
• **B. CÓ phí khi sao chép trong cùng AZ — sai, và đây là trường hợp ít có phí nhất.

Ghi nhớ

Nguyên tắc giá truyền dữ liệu của AWS — bảng phải thuộc: | Chiều | Chi phí | |---|---| | VÀO AWS từ Internet | MIỄN PHÍ | | RA Internet | ~0,09 USD/GB (có 100 GB miễn phí/tháng) | | Giữa các Region | ~0,02 USD/GB | | Giữa các AZ trong Region | ~0,01 USD/GB mỗi chiều (với EC2) | | Trong cùng AZ, IP riêng | miễn phí | | Sao chép RDS trong Region | MIỄN PHÍ ← câu này |

Lưu ý: truyền chéo AZ của EC2 có phí, nhưng sao chép RDS trong Region thì không — đây là ngoại lệ có chủ ý.

Ba dịch vụ miễn phí truyền chéo AZ: | Dịch vụ | Chi tiết | |---|---| | RDS Multi-AZ và read replica trong Region | ← câu này | | EFS | truy cập chéo AZ miễn phí | | ALB cross-zone load balancing | miễn phí (NLB thì tính phí) |

Ba khoản chi phí của RDS read replica: | Khoản | Chi tiết | |---|---| | Instance của replica | như một instance riêng | | Lưu trữ của replica | nhân theo số replica | | Truyền dữ liệu xuyên Region | ← câu này |

Khoản đầu tiên là lớn nhất — mỗi replica là một instance đầy đủ phải trả tiền.

Multi-AZ và Read Replica — bảng phân biệt: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | sẵn sàng cao | mở rộng đọc | | 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 | | Phí truyền | miễn phí | miễn phí trong Region |

Ba trường hợp dùng cross-Region read replica: | Trường hợp | Chi tiết | |---|---| | Giảm độ trễ đọc cho người dùng ở xa | | | Khôi phục thảm hoạ cấp Region | promote khi Region chính hỏng | | Di chuyển database sang Region khác | promote rồi cắt chuyển |

Ba lưu ý về cross-Region read replica: | Lưu ý | Chi tiết | |---|---| | Độ trễ sao chép CAO HƠN | phụ thuộc khoảng cách | | Tốn phí truyền dữ liệu | ← câu này | | Promote là KHÔNG ĐẢO NGƯỢC | replica thành instance độc lập |

Ba cách giảm chi phí truyền dữ liệu: | Cách | Tiết kiệm | |---|---| | Giữ compute cùng Region với dữ liệu | tránh phí xuyên Region | | Dùng VPC endpoint cho S3 và DynamoDB | tránh phí NAT Gateway | | CloudFront cho nội dung ra Internet | rẻ hơn từ S3 trực tiếp |

Và Aurora Global Database tính phí khác:

Aurora Global Database:
    → tính theo triệu WRITE I/O được sao chép
    → không tính theo GB như RDS read replica

Ba công cụ theo dõi chi phí truyền dữ liệu: | Công cụ | Việc | |---|---| | Cost Explorer với nhóm theo "Usage Type" | thấy rõ khoản DataTransfer-Regional-Bytes | | VPC Flow Logs | biết lưu lượng đi đâu | | Cost Anomaly Detection | phát hiện tăng bất thường |

Và mã usage type đáng biết: | Mã | Nghĩa | |---|---| | DataTransfer-Regional-Bytes | chéo AZ trong Region | | DataTransfer-Out-Bytes | ra Internet | | <Region>-<Region>-AWS-Out-Bytes | xuyên Region |

Ba lưu ý khi thiết kế nhiều Region: | Lưu ý | Chi tiết | |---|---| | Tính trước lượng dữ liệu sao chép mỗi tháng | dựa trên tốc độ ghi | | Cân nhắc Aurora Global Database | độ trễ thấp hơn nhiều | | Chỉ sao chép sang Region THỰC SỰ cần | mỗi Region là một khoản chi phí |

Và một lời khuyên: hãy đo lượng dữ liệu ghi mỗi tháng trước khi tạo cross-Region replica. Với database ghi nhiều — ví dụ hệ thống log hay telemetry — phí truyền xuyên Region có thể vượt cả chi phí instance của replica, và đó là con số ít ai ước lượng trước.

Đáp án

B — Tạo snapshot ĐÃ MÃ HOÁ của database, chia sẻ snapshot, và cấp quyền truy cập khoá mã hoá KMS.

Vì sao đúng

Đề nêu hai yêu cầu, và chia sẻ snapshot là cách duy nhất thoả cả hai: | Yêu cầu | Cơ chế | |---|---| | Kiểm toán viên cần BẢN SAO RIÊNG của database | snapshot khôi phục thành instance độc lập | | Chia sẻ AN TOÀN | snapshot mã hoá, kiểm soát bằng key policy |

Ba bước triển khai:

# ① Chụp snapshot (nếu database đã mã hoá thì snapshot cũng mã hoá)
aws rds create-db-snapshot --db-instance-identifier db-ke-toan   --db-snapshot-identifier snap-cho-kiem-toan

# ② Cấp quyền dùng khoá KMS cho tài khoản kiểm toán viên
aws kms create-grant --key-id abc-123   --grantee-principal arn:aws:iam::444455556666:root   --operations Decrypt DescribeKey CreateGrant

# ③ Chia sẻ snapshot
aws rds modify-db-snapshot-attribute   --db-snapshot-identifier snap-cho-kiem-toan   --attribute-name restore --values-to-add 444455556666

Và bước hai là phần hay bị quên:

Chia sẻ snapshot MÃ HOÁ mà không chia sẻ khoá KMS:
    → tài khoản kiểm toán viên THẤY snapshot
    → nhưng KHÔNG khôi phục được
    → lỗi AccessDenied khó hiểu

Ba lợi ích của cách này: | Lợi ích | Chi tiết | |---|---| | Kiểm toán viên có bản sao HOÀN TOÀN RIÊNG | không đụng gì tới database sản xuất | | Dữ liệu vẫn được MÃ HOÁ suốt quá trình | | | THU HỒI được bất cứ lúc nào | gỡ chia sẻ snapshot hoặc thu hồi grant |

Và thu hồi rất đơn giản:

aws rds modify-db-snapshot-attribute   --db-snapshot-identifier snap-cho-kiem-toan   --attribute-name restore --values-to-remove 444455556666

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

• **A. Dựng read replica và dùng IAM database authentication để cấp quyền cho kiểm toán viên — đây là phương án gần nhất và cũng cho truy cập dữ liệu, nhưng nó không cho "bản sao RIÊNG": read replica vẫn nằm trong tài khoản của công ty và liên kết với database sản xuất. Kiểm toán viên truy vấn nặng sẽ ảnh hưởng cụm, và họ không có quyền kiểm soát môi trường của mình.
• **D. Xuất ra tệp văn bản, lưu trong S3, tạo IAM user cho kiểm toán viên — mất hoàn toàn cấu trúc database: kiểm toán viên nhận tệp phẳng, không có ràng buộc, index hay khả năng truy vấn SQL. Và tạo IAM user cho người ngoài là thực hành kém (nên dùng cross-account role).
• **C. Tạo "snapshot của database trong S3" và gán IAM role cho kiểm toán viên truy cập object đó — hiểu sai cơ chế: snapshot của RDS không nằm trong bucket S3 của bạn. Chúng do AWS quản lý và chỉ truy cập được qua API của RDS.

Ghi nhớ

Ba cách chia sẻ dữ liệu RDS với bên ngoài: | Cách | Đặc điểm | |---|---| | Chia sẻ snapshot | bản sao độc lập, thu hồi được ← câu này | | Cross-account read replica | (chỉ Aurora, phức tạp hơn) | | Xuất sang S3 | mất cấu trúc, phù hợp cho phân tích |

Và RDS có tính năng xuất snapshot sang S3 dạng Parquet:

aws rds start-export-task --export-task-identifier xuat-kiem-toan   --source-arn <arn-snapshot> --s3-bucket-name kho-xuat   --iam-role-arn <arn-role> --kms-key-id <arn-key>

Định dạng Parquet, truy vấn được bằng Athena — phù hợp khi kiểm toán viên chỉ cần phân tích chứ không cần database chạy.

Ba quy tắc chia sẻ snapshot mã hoá: | Quy tắc | Chi tiết | |---|---| | KHÔNG chia sẻ được snapshot mã hoá bằng khoá aws/rds | phải dùng customer managed key | | Phải chia sẻ CẢ khoá KMS | qua key policy hoặc grant | | Tài khoản nhận phải SAO CHÉP snapshot trước | rồi mới khôi phục |

Dòng đầu là ràng buộc hay gây bất ngờ:

Khoá AWS managed (aws/rds):
    → không sửa được key policy
    → không chia sẻ được
        ↓
    Muốn chia sẻ snapshot: phải dùng customer managed key
    → tức là phải tạo lại database với khoá đó

Ba cách cấp quyền dùng khoá KMS xuyên tài khoản: | Cách | Chi tiết | |---|---| | KMS grant | linh hoạt, thu hồi dễ ← dùng trong câu này | | Key policy | thêm principal của tài khoản kia | | Cả hai | grant cho quyền tạm, policy cho lâu dài |

Key policy cho chia sẻ:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::444455556666:root"},
 "Action": ["kms:Decrypt", "kms:DescribeKey", "kms:CreateGrant"],
 "Resource": "*"}

Ba mức chia sẻ snapshot: | Mức | Chi tiết | |---|---| | Riêng tư (mặc định) | chỉ tài khoản sở hữu | | Chia sẻ với tài khoản cụ thể | ← câu này | | Công khai (all) | KHÔNG làm được với snapshot mã hoá |

Và snapshot công khai là rủi ro nghiêm trọng — có nhiều vụ rò rỉ dữ liệu bắt nguồn từ snapshot bị đặt công khai nhầm.

Ba việc nên làm khi chia sẻ với bên ngoài: | Việc | Chi tiết | |---|---| | Che hoặc xoá dữ liệu nhạy cảm trước | nếu kiểm toán viên không cần toàn bộ | | Ghi lại thời điểm chia sẻ và thu hồi | phục vụ kiểm toán chính việc chia sẻ | | Đặt lịch thu hồi | không để chia sẻ vô thời hạn |

Cách che dữ liệu trước khi chia sẻ:

① Khôi phục snapshot thành instance TẠM
② Chạy script che cột nhạy cảm (số thẻ, số CMND)
③ Chụp snapshot MỚI từ instance đã che
④ Chia sẻ snapshot mới
⑤ Xoá instance tạm

Ba công cụ phát hiện chia sẻ ngoài ý muốn: | Công cụ | Việc | |---|---| | IAM Access Analyzer | tìm tài nguyên chia sẻ ra ngoài tài khoản | | AWS Config rule rds-snapshots-public-prohibited | phát hiện snapshot công khai | | CloudTrail | ghi lại ModifyDBSnapshotAttribute |

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "snapshot-khong-duoc-cong-khai",
  "Source": {"Owner":"AWS","SourceIdentifier":"RDS_SNAPSHOTS_PUBLIC_PROHIBITED"}}'

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Snapshot thủ công tính phí lưu trữ | tới khi bạn xoá | | Tài khoản kiểm toán viên trả tiền cho bản sao của họ | | | Xoá snapshot sau khi kiểm toán xong | |

Và một lời khuyên: hãy đặt lịch nhắc thu hồi chia sẻ ngay khi tạo. Snapshot được chia sẻ sẽ nằm đó vô thời hạn nếu không ai nhớ gỡ — và một bản sao dữ liệu kế toán nhạy cảm ở tài khoản của bên thứ ba là thứ kiểm toán viên năm sau sẽ hỏi tới.

Đáp án

C — Cấu hình S3 gửi event notification vào SQS queue mỗi khi có ảnh tải lên; đặt Lambda function đọc hàng đợi và xử lý ảnh bất đồng bộ.

Vì sao đúng

Đề cho hai con số quyết định, và cả hai đều nằm trong giới hạn của Lambda:

Mỗi ảnh cần:
    ~3 PHÚT xử lý   → Lambda cho phép tới 15 phút ✓
    512 MB bộ nhớ   → Lambda cho phép tới 10 GB ✓
        ↓
    Lambda hoàn toàn phù hợp

Và kiến trúc S3 → SQS → Lambda là mẫu chuẩn:

Ảnh tải lên S3
    ↓ S3 event notification
SQS queue (vùng đệm)
    ↓ Lambda event source mapping
Lambda xử lý ảnh
    ↓
Kết quả lưu lại

Vì sao đặt SQS ở giữa thay vì S3 gọi thẳng Lambda: | Lợi ích | Chi tiết | |---|---| | Hấp thụ đỉnh tải | hàng nghìn ảnh tải lên cùng lúc không làm Lambda bị throttle | | Thử lại và dead-letter queue | ảnh xử lý hỏng không mất | | Kiểm soát tốc độ xử lý | qua reserved concurrency |

Và về chi phí, Lambda thắng rõ rệt:

Lambda:
    → trả tiền theo mili giây THỰC SỰ chạy
    → ảnh nào cũng chỉ 3 phút
    → không có máy nào chạy không

EC2 chạy liên tục:
    → trả tiền 24/7 kể cả lúc không có ảnh nào

Ước lượng cho 10.000 ảnh mỗi ngày:

10.000 × 180 giây × 512 MB = 921.600 GB-giây
≈ 15 USD/tháng cho Lambda

So với một EC2 t3.medium chạy 24/7: ~30 USD/tháng
    → và EC2 không co giãn khi có đỉnh tải

Và vế "gần thời gian thực" được đáp ứng — xử lý bắt đầu trong vài giây sau khi tải lên.

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

• **A. S3 event → EventBridge rule → Step Functions → ECS Fargate task — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó phức tạp và tốn kém hơn cần thiết: Fargate task mất vài chục giây để khởi động cho mỗi ảnh, và Step Functions thêm một tầng điều phối không cần thiết cho một bước xử lý đơn giản. Fargate chỉ đáng dùng khi vượt giới hạn của Lambda.
• **D. S3 → SQS → một EC2 Reserved Instance duy nhất đọc hàng đợi — không co giãn: một máy xử lý tuần tự sẽ tụt lại rất xa khi có đỉnh tải, và Reserved Instance nghĩa là cam kết trả tiền cả năm cho năng lực cố định.
• **B. Cấu hình S3 kích hoạt AWS App Runner trực tiếp — không có tích hợp như vậy: App Runner phục vụ ứng dụng web và API qua HTTP, S3 event notification không gọi App Runner được. Các đích được hỗ trợ là Lambda, SQS, SNS và EventBridge.

Ghi nhớ

Bốn đích của S3 Event Notification — bảng cần thuộc: | Đích | Chi tiết | |---|---| | AWS Lambda | gọi trực tiếp | | Amazon SQS | vùng đệm — mẫu bền vững nhất ← câu này | | Amazon SNS | phát tán tới nhiều nơi | | Amazon EventBridge | định tuyến linh hoạt, hơn 270 đích |

EventBridge mở rộng khả năng rất nhiều:

aws s3api put-bucket-notification-configuration --bucket kho-anh   --notification-configuration '{"EventBridgeConfiguration": {}}'

Sau đó dùng EventBridge rule định tuyến tới ECS, Step Functions, API đích bất kỳ.

Chọn dịch vụ compute theo thời gian chạy — bảng phải thuộc: | Thời gian chạy | Dịch vụ | |---|---| | Dưới 15 phút | Lambda ← câu này (3 phút) | | Trên 15 phút | Fargate | | Hàng nghìn job song song | AWS Batch | | Cần GPU | ECS/EKS trên EC2 |

Giới hạn của Lambda — nhắc lại: | Giới hạn | Giá trị | |---|---| | Thời gian chạy | 15 phút | | Bộ nhớ | 128 MB – 10.240 MB | | vCPU | ~6 (tỷ lệ theo bộ nhớ) | | /tmp | 512 MB – 10 GB | | Đồng thời mặc định | 1.000 mỗi tài khoản mỗi Region |

Ba cấu hình quan trọng cho Lambda xử lý ảnh: | Cấu hình | Chi tiết | |---|---| | Bộ nhớ | tăng bộ nhớ = tăng CPU = chạy nhanh hơn, có khi RẺ HƠN | | Timeout | đặt cao hơn thời gian xử lý dài nhất | | Reserved concurrency | bảo vệ các hàm khác khỏi bị chiếm hết |

Điểm về bộ nhớ đáng lưu ý:

512 MB, chạy 180 giây → 92 GB-giây
1024 MB, chạy 90 giây → 92 GB-giây
    ↓
    CÙNG chi phí nhưng NHANH GẤP ĐÔI

AWS Lambda Power Tuning tìm ra điểm tối ưu — thường vừa nhanh hơn vừa rẻ hơn.

Ba cấu hình của event source mapping với SQS: | Cấu hình | Việc | |---|---| | BatchSize | số thông điệp mỗi lần gọi | | MaximumBatchingWindowInSeconds | chờ gom lô | | FunctionResponseTypes: ReportBatchItemFailures | chỉ trả lại thông điệp HỎNG |

Tuỳ chọn thứ ba rất quan trọng:

Không bật:
    Một ảnh trong lô 10 xử lý hỏng
    → CẢ 10 quay lại hàng đợi
    → 9 ảnh tốt bị xử lý LẠI (tốn tiền, có thể trùng kết quả)

Ba cấu hình SQS quan trọng: | Cấu hình | Giá trị nên dùng | |---|---| | Visibility timeout | ≥ 6 lần timeout của Lambda (AWS khuyến nghị) | | Dead-letter queue | sau 3–5 lần thử | | Message retention | 4–14 ngày |

Ba dịch vụ xử lý ảnh trên AWS: | Dịch vụ | Việc | |---|---| | Lambda với thư viện xử lý ảnh | linh hoạt nhất ← câu này | | Amazon Rekognition | nhận diện nhãn, khuôn mặt, kiểm duyệt nội dung | | S3 Object Lambda | biến đổi ảnh KHI ĐỌC, không lưu bản sao |

S3 Object Lambda đáng biết cho ứng dụng ảnh:

Thay vì tạo sẵn nhiều kích thước thumbnail:
    → lưu một bản gốc
    → Object Lambda tạo kích thước cần thiết khi có request
        ↓
    Tiết kiệm lưu trữ, linh hoạt hơn

Ba lưu ý khi Lambda xử lý ảnh: | Lưu ý | Chi tiết | |---|---| | Ảnh lớn dùng /tmp | tăng dung lượng /tmp nếu cần | | Đóng gói thư viện vào layer | Pillow, ImageMagick | | Ghi kết quả sang PREFIX KHÁC | tránh vòng lặp vô tận |

Vòng lặp vô tận là bẫy kinh điển:

Lambda đọc từ kho-anh/ và ghi kết quả vào kho-anh/
    → ghi kích hoạt event mới
    → Lambda chạy lại
    → VÒNG LẶP VÔ TẬN, hoá đơn tăng vọt
        ↓
    → Ghi vào bucket KHÁC hoặc prefix khác,
      và lọc event theo prefix

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | tăng dần = xử lý không kịp | | Lambda Throttles | chạm hạn mức đồng thời | | Số thông điệp trong DLQ | phải là 0 |

Và một lời khuyên: hãy đặt filter theo prefix cho S3 event notification ngay từ đầu, ví dụ chỉ kích hoạt cho tai-len/. Nó vừa tránh vòng lặp, vừa đảm bảo Lambda không bị gọi cho các tệp phụ trợ mà ứng dụng ghi vào cùng bucket.

Đáp án

B và C.

• B — Đặt lifecycle policy chuyển dữ liệu vùng raw sang S3 Glacier Deep Archive sau 1 ngày
• C — Dùng Glue ETL job ghi dữ liệu vùng refined ở định dạng NÉN

Vì sao đúng

Đề nêu hai ràng buộc, và hai đáp án giải quyết hai vùng dữ liệu khác nhau: | Vùng | Đặc điểm | Giải pháp | |---|---|---| | Raw | phải giữ 5 NĂM vì tuân thủ, KHÔNG ai truy vấn | Deep Archive — rẻ nhất | | Refined | nhà phân tích truy vấn bằng Athena | nén — giảm cả lưu trữ lẫn chi phí quét |

B — vì sao Deep Archive cho vùng raw:

Dữ liệu raw:
    → chỉ giữ để tuân thủ
    → Glue ETL đọc MỘT LẦN rồi thôi
    → sau đó không ai chạm tới
        ↓
    Deep Archive: ~0,00099 USD/GB-tháng
    So với Standard: ~0,023 USD/GB-tháng
    → RẺ HƠN KHOẢNG 23 LẦN

Và chuyển sau 1 ngày là hợp lệ:

Ràng buộc lifecycle:
    → sang Standard-IA hoặc One Zone-IA: cần ÍT NHẤT 30 NGÀY ở Standard
    → sang GLACIER (mọi loại): KHÔNG có ràng buộc
        ↓
    Days: 1 hoàn toàn hợp lệ cho Deep Archive

{"Rules": [{
  "ID": "raw-sang-deep-archive",
  "Status": "Enabled",
  "Filter": {"Prefix": "raw/"},
  "Transitions": [{"Days": 1, "StorageClass": "DEEP_ARCHIVE"}]}]}

Tính toán tiết kiệm với 1 TB mỗi ngày:

1 năm = 365 TB dữ liệu raw
Standard:     365.000 GB × 0,023 = ~8.395 USD/tháng
Deep Archive: 365.000 GB × 0,00099 = ~361 USD/tháng
    → tiết kiệm hơn 8.000 USD mỗi tháng

C — vì sao nén cho vùng refined:

Nén (Parquet + Snappy) giảm dung lượng 70–90%
    ↓
    Vừa giảm phí LƯU TRỮ
    Vừa giảm phí QUÉT của Athena (tính theo dữ liệu đọc)
        ↓
    Lợi ích KÉP

glueContext.write_dynamic_frame.from_options(
    frame=du_lieu,
    connection_type="s3",
    connection_options={"path": "s3://kho/refined/",
                        "partitionKeys": ["nam", "thang"]},
    format="parquet",
    format_options={"compression": "snappy"})

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

• **E. Chuyển dữ liệu vùng REFINED sang Deep Archive sau 1 ngày — đây là phương án gần nhất và giống hệt B về cơ chế, nhưng nó áp cho SAI VÙNG: nhà phân tích chạy truy vấn ad-hoc trên vùng refined. Deep Archive cần 12–48 giờ để khôi phục, nên Athena sẽ không đọc được và ứng dụng phân tích hỏng hoàn toàn.
• **A. Dùng Lambda xoá dữ liệu raw sau 1 ngày — vi phạm yêu cầu tuân thủ: đề nói rõ dữ liệu nguồn phải giữ tối thiểu 5 năm. Xoá là vi phạm quy định.
• **D. Ghi dữ liệu refined ở định dạng CSV — đi ngược mục tiêu: CSV là định dạng dòng, không nén, và Athena phải quét toàn bộ tệp. Nó làm tăng cả chi phí lưu trữ lẫn chi phí truy vấn.

Ghi nhớ

Bảng lớp lưu trữ S3 — nội dung cốt lõi: | Lớp | Truy xuất | Giá lưu trữ | Lưu tối thiểu | |---|---|---|---| | Standard | tức thì | ~0,023 USD/GB | không | | Standard-IA | tức thì | ~0,0125 USD/GB | 30 ngày | | Glacier Instant Retrieval | mili giây | ~0,004 USD/GB | 90 ngày | | Glacier Flexible | 1 phút – 12 giờ | ~0,0036 USD/GB | 90 ngày | | Glacier Deep Archive | 12–48 giờ | ~0,00099 USD/GB | 180 ngày |

Hai loại ràng buộc thời gian — phân biệt rõ:

Ràng buộc CHUYỂN ĐỔI:
    Standard → IA:      cần ít nhất 30 ngày ở Standard
    Standard → Glacier: KHÔNG có ràng buộc

Ràng buộc LƯU TỐI THIỂU:
    xoá trước hạn vẫn bị tính đủ phí (30/90/180 ngày)

Ba định dạng cho data lake — bảng so sánh: | Định dạng | Đặc điểm | |---|---| | Parquet | cột, nén tốt, Athena đọc rất nhanh | | ORC | cột, tương tự Parquet | | CSV, JSON | dòng, không nén, quét toàn bộ | | Avro | dòng, có lược đồ, tốt cho streaming |

Vì sao định dạng cột nhanh hơn cho phân tích:

Truy vấn: SELECT tong_tien FROM don_hang WHERE nam = 2026

CSV:     đọc TOÀN BỘ mọi cột của mọi dòng
Parquet: đọc CHỈ cột tong_tien và nam
             + bỏ qua row group không khớp
        ↓
    Giảm dữ liệu quét tới 90%

Ba cách giảm chi phí Athena: | Cách | Tiết kiệm | |---|---| | Dùng Parquet hoặc ORC | giảm dữ liệu quét rất nhiều | | PHÂN VÙNG theo cột hay lọc | chỉ quét phân vùng cần | | Nén | ít byte hơn |

Phân vùng có tác động lớn nhất:

s3://kho/refined/nam=2026/thang=08/ngay=30/du-lieu.parquet
    ↓
SELECT * FROM bang WHERE nam=2026 AND thang=8
    → chỉ quét thư mục thang=08
    → bỏ qua toàn bộ dữ liệu năm khác

Ba thuật toán nén cho Parquet: | Thuật toán | Đặc điểm | |---|---| | Snappy (mặc định) | nhanh, tỷ lệ nén vừa — cân bằng tốt nhất | | GZIP | nén tốt hơn, chậm hơn | | ZSTD | nén tốt và nhanh — lựa chọn hiện đại |

Ba lưu ý về Glacier Deep Archive: | Lưu ý | Chi tiết | |---|---| | PHẢI restore trước khi đọc | 12 giờ (Standard) hoặc 48 giờ (Bulk) | | Lưu tối thiểu 180 ngày | xoá sớm vẫn tính đủ | | Có phí truy xuất | tính theo GB |

Và với dữ liệu tuân thủ giữ 5 năm, ràng buộc 180 ngày không phải vấn đề.

Ba lưu ý khi chuyển tệp nhỏ sang Glacier: | Lưu ý | Chi tiết | |---|---| | Phí tối thiểu 40 KB mỗi object (Glacier) | gộp tệp nhỏ trước | | Có phí chuyển đổi mỗi object | với hàng triệu tệp thì đáng kể | | Lọc theo kích thước trong lifecycle | ObjectSizeGreaterThan |

Với 1 TB mỗi ngày, nếu chia thành hàng triệu tệp nhỏ thì phí chuyển đổi có thể lớn hơn khoản tiết kiệm.

Ba biện pháp bảo vệ dữ liệu tuân thủ: | Biện pháp | Chi tiết | |---|---| | S3 Object Lock (COMPLIANCE) | không ai xoá được trong thời hạn — kể cả root | | Versioning | chống ghi đè | | Cross-Region Replication | chống thảm hoạ Region |

Object Lock rất phù hợp với dữ liệu y tế giữ 5 năm:

aws s3api put-object-lock-configuration --bucket kho-raw   --object-lock-configuration '{"ObjectLockEnabled":"Enabled",
    "Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Years":5}}}'

Ba việc nên làm với data lake: | Việc | Chi tiết | |---|---| | Bật S3 Storage Lens | thấy phân bố dung lượng theo prefix | | Lifecycle rule dọn multipart dở dang | bắt buộc | | Glue Data Catalog cho metadata | Athena và EMR dùng chung |

Và một lời khuyên: hãy kiểm chứng khoản tiết kiệm bằng Cost Explorer sau một tháng. Với data lake tăng 1 TB mỗi ngày, chi phí lưu trữ tăng đều mỗi tháng, và con số thực tế sau khi áp lifecycle là thứ thuyết phục ban lãnh đạo hơn mọi bảng ước tính.

Đáp án

A, E và F.

• A — Security group của RDS: inbound từ security group của EC2 trên cổng 5432
• E — Security group của EC2: inbound từ security group của ALB trên cổng 80
• F — Security group của ALB: inbound từ mọi nguồn trên cổng 443

Vì sao đúng

Ba đáp án mô tả đúng chuỗi lưu lượng của kiến trúc ba tầng:

Internet ──443 (HTTPS)──▶ ALB
                            │ (ALB kết thúc TLS)
                            ├──80 (HTTP)──▶ EC2 (ASG)
                                              │
                                              └──5432──▶ RDS PostgreSQL

F — ALB nhận HTTPS từ Internet:

Đề nói rõ: "ALB provides HTTPS TERMINATION"
    → người dùng kết nối bằng HTTPS (cổng 443)
    → ALB giải mã TLS tại đó

E — ALB chuyển tiếp bằng HTTP tới EC2:

Sau khi ALB kết thúc TLS:
    → lưu lượng tới EC2 là HTTP thuần (cổng 80)
    → và CHỈ từ security group của ALB
        ↓
    EC2 không nhận request trực tiếp từ Internet

A — RDS nhận từ EC2 trên cổng PostgreSQL:

PostgreSQL dùng cổng 5432
    → inbound CHỈ từ security group của EC2
    → không phải từ CIDR, không phải từ mọi nguồn

Và vì sao tham chiếu SECURITY GROUP là cấu hình an toàn nhất:

Dùng CIDR:
    → mọi máy trong dải đó vào được
    → và IP thay đổi khi ASG tạo máy mới

Dùng security group:
    → chỉ máy được gán SG đó mới vào được
    → instance mới do ASG tạo TỰ ĐỘNG được phép

aws ec2 authorize-security-group-ingress --group-id sg-rds   --protocol tcp --port 5432 --source-group sg-ec2

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

• **C. Security group của ALB: inbound từ mọi nguồn trên cổng 80 — đây là phương án gần nhất và về nguyên tắc không sai (nhiều kiến trúc mở cổng 80 để chuyển hướng sang HTTPS), nhưng đề nói rõ ALB kết thúc HTTPS, nên cổng người dùng kết nối là 443. Câu hỏi chỉ cho chọn ba, và F mô tả đúng luồng chính.
• **B. Security group của RDS: inbound từ SG của EC2 trên cổng 80 — sai cổng: PostgreSQL dùng 5432, không phải 80.
• **D. Security group của EC2: inbound từ SG của RDS trên cổng 5432 — đảo ngược chiều kết nối: EC2 gọi tới RDS, không phải ngược lại. Và security group là stateful nên phản hồi tự động được phép.

Ghi nhớ

Cổng của các database phổ biến — bảng nên thuộc: | Database | Cổng | |---|---| | PostgreSQL, Aurora PostgreSQL | 5432 | | MySQL, MariaDB, Aurora MySQL | 3306 | | Microsoft SQL Server | 1433 | | Oracle | 1521 | | Redis | 6379 | | Memcached | 11211 | | MongoDB / DocumentDB | 27017 | | NFS (EFS) | 2049 | | SMB | 445 | | HTTP / HTTPS | 80 / 443 | | SSH / RDP | 22 / 3389 |

Ba đặc điểm của security group: | Đặc điểm | Chi tiết | |---|---| | CHỈ có quy tắc Allow | không có Deny | | STATEFUL | phản hồi tự động được phép — không cần quy tắc ngược | | Tham chiếu security group khác được | ← điểm mấu chốt |

Tính stateful có hệ quả quan trọng:

EC2 gửi truy vấn tới RDS trên cổng 5432
    → SG của RDS cho phép inbound 5432 ✓
    → phản hồi TỰ ĐỘNG được phép đi ra
    → KHÔNG cần quy tắc outbound trên SG của RDS
    → KHÔNG cần quy tắc inbound trên SG của EC2

Security group và NACL — bảng phân biệt: | | Security group | Network ACL | |---|---|---| | Phạm vi | ENI | SUBNET | | Quy tắc | chỉ Allow | Allow và Deny | | Trạng thái | stateful | stateless | | Tham chiếu SG khác | ✅ | ❌ chỉ CIDR | | Mặc định | chặn inbound, cho outbound | cho cả hai chiều |

Mẫu chuỗi tham chiếu cho kiến trúc ba tầng:

SG-ALB:  inbound 443 từ 0.0.0.0/0
SG-EC2:  inbound 80  từ SG-ALB
SG-RDS:  inbound 5432 từ SG-EC2
    ↓
    Mỗi tầng chỉ nhận từ tầng ngay trên nó

Ba lưu ý về HTTPS termination ở ALB: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ ACM gắn vào listener HTTPS | miễn phí, tự gia hạn | | Lưu lượng ALB → EC2 là HTTP thuần | trong VPC riêng nên chấp nhận được | | Mã hoá đầu-cuối nếu cần | dùng HTTPS cả chặng thứ hai |

Với dữ liệu rất nhạy cảm, nên mã hoá cả chặng ALB → EC2:

Listener HTTPS 443 → target group với protocol HTTPS 443
    → EC2 cần chứng chỉ riêng (tự ký cũng được)
    → ALB không kiểm tra chứng chỉ của target

Ba cấu hình nên có cho listener HTTP:

aws elbv2 create-rule --listener-arn <arn-listener-80> --priority 1   --conditions '[{"Field":"path-pattern","Values":["/*"]}]'   --actions '[{"Type":"redirect","RedirectConfig":
    {"Protocol":"HTTPS","Port":"443","StatusCode":"HTTP_301"}}]'

Chuyển hướng mọi HTTP sang HTTPS — đây là lý do nhiều kiến trúc vẫn mở cổng 80 trên ALB.

Ba nguyên tắc thiết kế security group: | Nguyên tắc | Chi tiết | |---|---| | Một SG cho mỗi TẦNG | dễ quản lý hơn một SG cho mỗi máy | | Tham chiếu SG thay vì CIDR | an toàn hơn và tự thích ứng | | Chỉ mở cổng thật sự cần | không mở dải rộng |

Ba lưu ý về outbound rule: | Lưu ý | Chi tiết | |---|---| | Mặc định cho phép MỌI outbound | | | Thắt chặt tăng bảo mật | chặn rò rỉ dữ liệu | | Nhớ mở cho dịch vụ AWS cần dùng | qua VPC endpoint |

Ba công cụ kiểm tra cấu hình mạng: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | kiểm tra đường đi giữa hai tài nguyên | | VPC Flow Logs | thấy lưu lượng thật, kể cả bị từ chối | | AWS Config rule | phát hiện SG mở quá rộng |

aws ec2 create-network-insights-path   --source i-ec2 --destination <arn-rds>   --destination-port 5432 --protocol tcp

Nó chỉ ra chính xác thành phần nào chặn — security group, NACL hay route table.

Và một lời khuyên: hãy đặt tên security group theo TẦNG (sg-alb, sg-web, sg-db) chứ không theo ứng dụng. Khi kiến trúc phát triển, chuỗi tham chiếu giữa các tầng vẫn giữ nguyên ý nghĩa, còn tên theo ứng dụng sẽ nhanh chóng không còn phản ánh đúng thực tế.

Đáp án

B — Dùng SQS FIFO queue, và đảm bảo dữ liệu telemetry được gửi kèm thuộc tính Group ID mang giá trị Desktop ID.

Vì sao đúng

Đề nêu ba yêu cầu, và MessageGroupId là cơ chế giải quyết cả ba cùng lúc: | Yêu cầu | Cơ chế | |---|---| | Dữ liệu của MỖI máy xử lý ĐÚNG THỨ TỰ | FIFO đảm bảo thứ tự trong mỗi message group | | ĐỘC LẬP giữa các máy | mỗi Desktop ID là một group riêng | | Số consumer có thể bằng số máy | các group xử lý SONG SONG |

Cách MessageGroupId hoạt động:

Mọi thông điệp cùng MessageGroupId:
    → xử lý TUẦN TỰ, đúng thứ tự gửi
    → chỉ một consumer nhận tại một thời điểm

Các MessageGroupId KHÁC nhau:
    → xử lý SONG SONG hoàn toàn
    → không chờ nhau

Áp vào tình huống:

sqs.send_message(
    QueueUrl=url,
    MessageBody=json.dumps(du_lieu_telemetry),
    MessageGroupId=ma_may_tinh,          # mỗi máy một group
    MessageDeduplicationId=f'{ma_may_tinh}-{dau_thoi_gian}')

10.000 máy tính → 10.000 message group
    → tới 10.000 luồng xử lý song song
    → mỗi luồng giữ đúng thứ tự cho máy của nó
        ↓
    Đúng yêu cầu "scale consumers to equal number of desktops"

Và vì sao FIFO chứ không phải Standard:

SQS Standard: KHÔNG đảm bảo thứ tự
    → dữ liệu telemetry của một máy có thể bị đảo
    → đề yêu cầu "processed IN ORDER"

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

• **D. Dùng Kinesis Data Stream với Partition ID là Desktop ID — đây là phương án gần nhất và cũng đảm bảo thứ tự theo từng máy, nhưng nó không đạt mức song song mà đề yêu cầu: trong Kinesis, mức song song bị giới hạn bởi SỐ SHARD, không phải số partition key. Nhiều Desktop ID sẽ ánh xạ vào cùng một shard và phải chờ nhau. Muốn 10.000 luồng song song thì cần 10.000 shard — không khả thi về chi phí.
• **A. Dùng FIFO queue nhưng gửi dữ liệu NGUYÊN TRẠNG (không có Group ID) — mất hoàn toàn tính song song: không khai MessageGroupId thì mọi thông điệp vào cùng một group mặc định, xử lý tuần tự một cái một lúc. Với hàng nghìn máy gửi mỗi phút, hàng đợi sẽ tồn đọng vô hạn.
• **C. Dùng SQS Standard queue gửi nguyên trạng — vi phạm yêu cầu thứ tự: Standard không đảm bảo thứ tự xử lý.

Ghi nhớ

Hai id của SQS FIFO — bảng phải thuộc: | Id | Việc | |---|---| | MessageGroupId | nhóm cần giữ thứ tự — các nhóm xử lý SONG SONG | | MessageDeduplicationId | khử trùng trong cửa sổ 5 phút |

MessageGroupId là quyết định thiết kế quan trọng nhất khi dùng FIFO:

Một group cho toàn hệ thống:
    → thông lượng thực tế RẤT THẤP (tuần tự hoàn toàn)

Nhiều group (theo thực thể nghiệp vụ):
    → song song cao
    → vẫn giữ thứ tự trong từng thực thể
        ↓
    Chọn khoá tự nhiên: mã máy, mã khách hàng, mã tài khoản

Hạn mức thông lượng của SQS FIFO: | Chế độ | Thông lượng | |---|---| | Tiêu chuẩn | 300 thao tác/giây, 3.000 thông điệp/giây khi gom lô 10 | | High-throughput | tới 70.000 thông điệp/giây (tuỳ Region) |

Bật high-throughput FIFO:

aws sqs set-queue-attributes --queue-url <url> --attributes '{
  "DeduplicationScope": "messageGroup",
  "FifoThroughputLimit": "perMessageGroupId"}'

Chế độ này cho 300 thao tác/giây MỖI message group
    → với hàng nghìn group, thông lượng tổng rất cao
        ↓
    Đây là cấu hình đúng cho tình huống trong đề

SQS FIFO và Kinesis — bảng phân biệt: | | SQS FIFO | Kinesis Data Streams | |---|---|---| | Đơn vị song song | message group (không giới hạn số lượng) | SHARD (phải cấp phát) | | Đọc lại dữ liệu cũ | ❌ | ✅ tới 365 ngày | | Nhiều consumer độc lập | ❌ | ✅ | | Khử trùng | ✅ dựng sẵn | ❌ | | Chi phí | theo request | theo shard-giờ hoặc theo lượng dùng |

Quy tắc chọn:

Cần thứ tự + SONG SONG CAO theo thực thể → SQS FIFO với MessageGroupId Cần ĐỌC LẠI hoặc NHIỀU consumer độc lập → Kinesis

Ba đảm bảo của SQS FIFO: | Đảm bảo | Cơ chế | |---|---| | Đúng thứ tự | MessageGroupId | | Đúng một lần | MessageDeduplicationId, cửa sổ 5 phút | | Không mất | lưu bền, xoá khi consumer xác nhận |

Ba lưu ý khi dùng Lambda với FIFO queue: | Lưu ý | Chi tiết | |---|---| | Số lượt đồng thời = số message group đang có thông điệp | KHÔNG phải hạn mức Lambda | | Mỗi lô chỉ chứa thông điệp của MỘT group | Lambda xử lý tuần tự trong group | | ReportBatchItemFailures để tránh xử lý lại cả lô | |

Ba cấu hình SQS quan trọng: | Cấu hình | Chi tiết | |---|---| | Visibility timeout | ≥ 6 lần timeout của Lambda | | Long polling (20 giây) | giảm request rỗng và chi phí | | Dead-letter queue | thông điệp hỏng không kẹt mãi |

Ba lưu ý về ContentBasedDeduplication: | Lưu ý | Chi tiết | |---|---| | Bật thì SQS hash NỘI DUNG làm dedup id | tiện | | Nội dung giống hệt trong 5 phút bị BỎ | nguy hiểm với telemetry định kỳ | | Khai tường minh thì an toàn hơn | dùng mã máy + dấu thời gian |

Dòng giữa rất quan trọng với tình huống này:

Máy tính gửi telemetry mỗi phút
    → nếu hai lần liên tiếp có giá trị GIỐNG HỆT
    → và bật ContentBasedDeduplication
        ↓
    Bản ghi thứ hai bị NUỐT MẤT âm thầm
    → dữ liệu giám sát bị thủng lỗ

Nên luôn khai MessageDeduplicationId tường minh có chứa dấu thời gian.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | tăng dần = xử lý không kịp | | ApproximateNumberOfMessagesVisible | độ sâu hàng đợi | | Số thông điệp trong DLQ | phải là 0 |

Ba lựa chọn cho tầng xử lý: | Lựa chọn | Đặc điểm | |---|---| | Lambda với SQS event source | ít công nhất, tự co giãn | | ECS hoặc EC2 với ASG theo độ sâu hàng đợi | cho việc chạy lâu | | Fargate | container, không quản lý máy |

Và một lời khuyên: hãy bật high-throughput FIFO ngay từ đầu nếu số máy giám sát lớn. Chế độ tiêu chuẩn giới hạn 300 thao tác mỗi giây cho cả hàng đợi, và với 10.000 máy gửi mỗi phút thì con số đó bị vượt ngay — trong khi chuyển đổi sau lại đòi tạo hàng đợi mới.

Đáp án

D — Dựng Amazon RDS MySQL với Multi-AZ để sao chép dữ liệu ĐỒNG BỘ.

Vì sao đúng

Đề nêu hai yêu cầu, và Multi-AZ là cơ chế duy nhất đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | GIẢM THIỂU mất dữ liệu | sao chép ĐỒNG BỘ → RPO = 0 | | Mỗi giao dịch lưu trên ÍT NHẤT HAI node | primary + standby, cùng lúc |

Cách sao chép đồng bộ hoạt động:

Ứng dụng ghi vào primary
    ↓
Primary ghi xuống đĩa của mình
    ↓ ĐỒNG THỜI gửi sang standby ở AZ khác
Standby ghi xong và XÁC NHẬN
    ↓
Chỉ khi đó primary mới báo "ghi thành công"
        ↓
    Mỗi giao dịch đã committed đều nằm trên HAI node
    → RPO = 0

Và đó chính là câu "stores every transaction on at least two nodes" trong đề.

Bật Multi-AZ:

aws rds modify-db-instance --db-instance-identifier db-san-xuat   --multi-az --apply-immediately

Ba lợi ích của Multi-AZ: | Lợi ích | Chi tiết | |---|---| | Chuyển đổi TỰ ĐỘNG | 60–120 giây, không cần can thiệp | | Không mất dữ liệu | sao chép đồng bộ | | Bảo trì ít gián đoạn hơn | vá lỗi standby trước rồi chuyển đổi |

Và chuyển đổi diễn ra qua DNS:

Endpoint KHÔNG ĐỔI
    → RDS trỏ bản ghi DNS sang standby
    → ứng dụng chỉ cần KẾT NỐI LẠI

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

• **B. Dựng RDS MySQL rồi tạo read replica ở AZ khác với sao chép đồng bộ — đây là phương án gần nhất và là bẫy chính: read replica luôn sao chép BẤT ĐỒNG BỘ, không có tuỳ chọn đồng bộ. Nghĩa là các giao dịch chưa kịp sao chép sẽ mất khi primary hỏng, và promote replica là thao tác thủ công.
• **C. Read replica ở Region khác với sao chép đồng bộ — cùng lỗi, và còn tệ hơn: sao chép xuyên Region có độ trễ cao hơn nhiều, và đồng bộ xuyên lục địa là bất khả thi về hiệu năng.
• **A. EC2 cài MySQL kích hoạt Lambda sao chép đồng bộ sang RDS MySQL — không phải cơ chế có thật: sao chép database ở tầng lưu trữ, không phải thứ Lambda làm được. Và nó thêm rất nhiều công vận hành cho một việc RDS làm sẵn.

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 | | Sao chép | ĐỒNG BỘ | BẤT ĐỒNG BỘ | | RPO | 0 — không mất dữ liệu | giây tới phút | | Chuyển đổi | TỰ ĐỘNG | thủ công (promote) | | Standby phục vụ đọc | ❌ (Multi-AZ instance) | ✅ | | Phạm vi | cùng Region, ≥ 2 AZ | cùng hoặc khác Region | | Số lượng | 1 standby | 5 (RDS), 15 (Aurora) |

Từ khoá nhận diện:

"no data loss", "every transaction on two nodes", "automatic failover" → Multi-AZ "scale reads", "reporting queries" → Read replica "disaster recovery across Regions" → Cross-Region read replica

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 lại |

Multi-AZ cho RPO = 0 và RTO 1–2 phút.

Ba kiểu triển khai của RDS: | Kiểu | Đặc điểm | |---|---| | Single-AZ | một instance, chỉ cho dev | | Multi-AZ instance | 1 standby, KHÔNG phục vụ đọc | | Multi-AZ DB cluster | 2 standby CÓ phục vụ đọc, chuyển đổi dưới 35 giây |

Multi-AZ DB cluster là lựa chọn mới đáng biết — nó cho cả sẵn sàng cao lẫn khả năng đọc từ standby, thứ mà Multi-AZ instance không có.

Ba tình huống kích hoạt chuyển đổi: | Tình huống | Chi tiết | |---|---| | Primary hỏng | phần cứng hoặc phần mềm | | AZ mất kết nối | | | Bảo trì có kế hoạch | vá lỗi, đổi cỡ instance |

Ba lưu ý về ứng dụng khi có chuyển đổi: | Lưu ý | Chi tiết | |---|---| | Ứng dụng phải xử lý được lỗi kết nối tạm thời | và thử lại | | Java cache DNS VĨNH VIỄN theo mặc định | đặt networkaddress.cache.ttl = 60 | | Dùng connection pool có kiểm tra sức khoẻ | |

Dòng giữa là lỗi kinh điển với ứng dụng Java — sau chuyển đổi, ứng dụng vẫn cố kết nối vào IP cũ và không bao giờ phục hồi.

Ba việc Multi-AZ KHÔNG bảo vệ: | Không bảo vệ | Cách bảo vệ | |---|---| | Lỗi con người (xoá nhầm bảng) | automated backup + PITR | | Thảm hoạ cấp Region | cross-Region replica hoặc snapshot | | Dữ liệu hỏng do ứng dụng | PITR |

Multi-AZ là cơ chế SẴN SÀNG, không phải SAO LƯU — sai sót logic được sao chép sang standby ngay lập tức.

Ba cơ chế bảo vệ bổ sung nhau: | Cơ chế | Chống lại | |---|---| | Multi-AZ | hỏng hạ tầng | | Automated backup (PITR, tới 35 ngày) | lỗi con người | | Snapshot thủ công | giữ lâu dài, không bị xoá theo instance |

Lưu ý: automated backup bị XOÁ khi xoá instance — snapshot thủ công thì không.

Ba lưu ý về chi phí Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Giá gấp ĐÔI Single-AZ | trả cho cả standby | | Standby không phục vụ đọc | không tận dụng được | | Sao chép trong Region MIỄN PHÍ | không có phí truyền dữ liệu |

Và Aurora là lựa chọn thay thế đáng cân nhắc: | | RDS Multi-AZ | Aurora | |---|---|---| | Bản sao dữ liệu | 2 | 6 qua 3 AZ | | Chuyển đổi | 60–120 giây | thường dưới 30 giây | | Replica phục vụ đọc | ❌ | ✅ tới 15 | | Hiệu năng | chuẩn | cao hơn tới 5 lần |

Ba việc cần làm trước khi go-live: | Việc | Chi tiết | |---|---| | THỬ chuyển đổi thật | reboot --force-failover | | Đo thời gian ứng dụng phục hồi | | | Đặt alarm cho các metric chính | CPU, kết nối, độ trễ, dung lượng |

Và một lời khuyên: hãy thử chuyển đổi trong giờ thấp điểm ngay sau khi bật Multi-AZ. Nó cho biết ứng dụng mất bao lâu để kết nối lại và có xử lý được ngoại lệ hay không — và với công ty vừa trải qua sự cố mất database, việc chứng minh cơ chế mới thực sự hoạt động quan trọng ngang với việc bật nó.

Đáp án

C — Triển khai AWS Global Accelerator, tạo endpoint cho mọi Region, và đăng ký các ALB của từng Region vào endpoint tương ứng.

Vì sao đúng

Đề nêu vấn đề rất cụ thể: quá nhiều ALB ở nhiều Region, quá nhiều địa chỉ IP phải cho phép trong tường lửa.

Mỗi ALB có nhiều IP và IP THAY ĐỔI theo thời gian
    → tường lửa phải cho phép hàng chục dải
    → mỗi lần AWS đổi IP của ALB, danh sách trắng hỏng
        ↓
    Cần MỘT điểm vào duy nhất với IP CỐ ĐỊNH

Và Global Accelerator cung cấp đúng điều đó:

Global Accelerator cho HAI ĐỊA CHỈ IP ANYCAST TĨNH
    → đại diện cho TOÀN BỘ hạ tầng ở mọi Region
    → IP KHÔNG BAO GIỜ đổi
        ↓
    Tường lửa chỉ cần cho phép HAI IP
    Dù phía sau có bao nhiêu ALB ở bao nhiêu Region

Cấu hình:

aws globalaccelerator create-accelerator --name diem-vao-toan-cau --enabled

aws globalaccelerator create-listener --accelerator-arn <arn>   --protocol TCP --port-ranges FromPort=443,ToPort=443

# Đăng ký ALB của từng Region
aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region ap-northeast-1   --endpoint-configurations EndpointId=<arn-alb-tokyo>,Weight=100

aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region eu-west-1   --endpoint-configurations EndpointId=<arn-alb-ireland>,Weight=100

Và ba lợi ích phụ đáng kể: | Lợi ích | Chi tiết | |---|---| | Giảm độ trễ | lưu lượng đi qua mạng riêng của AWS | | Chuyển vùng tự động ~30 giây | Region hỏng thì tự chuyển | | Quản lý tập trung | một chỗ điều khiển định tuyến toàn cầu |

Với công ty game, độ trễ thấp và ổn định là lợi ích quan trọng ngang với việc gọn danh sách IP.

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

• **A. Dựng Network Load Balancer với Elastic IP, đăng ký IP riêng của mọi ALB làm target — đây là phương án gần nhất và NLB thực sự có IP tĩnh, nhưng nó không hoạt động xuyên Region: NLB chỉ định tuyến tới target trong cùng VPC hoặc qua peering trong cùng Region. Nó không nối được ALB ở nhiều Region. Và IP riêng của ALB thay đổi theo thời gian.
• **D. Cấu hình Elastic IP cho từng ALB ở mỗi Region — không làm được về mặt kỹ thuật: ALB KHÔNG hỗ trợ Elastic IP (chỉ NLB mới hỗ trợ). Và kể cả làm được, nó vẫn để lại hàng chục IP phải quản lý.
• **B. Gán Elastic IP cho Auto Scaling group và dựng EC2 sau ASG ở mỗi Region — không phải khái niệm có thật: Elastic IP gắn với một instance, không gắn với ASG. Và nó bỏ mất tầng cân bằng tải.

Ghi nhớ

Global Accelerator và CloudFront — bảng phân biệt cốt lõi: | | Global Accelerator | CloudFront | |---|---|---| | Giao thức | TCP và UDP, mọi cổng | chỉ HTTP/HTTPS | | Caching | ❌ | ✅ | | Địa chỉ | 2 IP anycast TĨNH | tên miền | | Chuyển vùng | ~30 giây, không đụng DNS | theo origin | | Phù hợp | game, VoIP, IoT, IP tĩnh | web, nội dung tĩnh |

Từ khoá nhận diện:

"static IP", "whitelist in firewall", "UDP", "fast regional failover" → Global Accelerator "cache content", "HTTP", "reduce origin load" → CloudFront

Ba lợi ích của IP anycast tĩnh: | Lợi ích | Chi tiết | |---|---| | Đưa vào danh sách trắng tường lửa | ← lý do chính trong câu này | | Không phụ thuộc bộ đệm DNS | chuyển vùng tức thì | | Giữ nguyên khi đổi kiến trúc phía sau | client không biết gì |

Và bạn mang IP của mình vào được (BYOIP):

Nếu công ty đã có dải IP công cộng riêng
    → đưa vào AWS và dùng cho Global Accelerator
    → khách hàng không phải cập nhật danh sách trắng

Ba khái niệm của Global Accelerator: | Khái niệm | Việc | |---|---| | Accelerator | tài nguyên gốc, mang hai IP tĩnh | | Listener | cổng và giao thức | | Endpoint group | một Region, có traffic dial | | Endpoint | ALB, NLB, EC2, hoặc Elastic IP |

Các loại endpoint được hỗ trợ: | Endpoint | Hỗ trợ | |---|---| | Application Load Balancer | ✅ ← câu này | | Network Load Balancer | ✅ | | EC2 instance | ✅ | | Elastic IP | ✅ | | S3 bucket | ❌ (dùng S3 Transfer Acceleration) |

Hai loại accelerator: | Loại | Đặc điểm | |---|---| | Standard | định tuyến theo độ trễ và sức khoẻ ← câu này | | Custom routing | ánh xạ cố định IP+cổng → instance — phù hợp cho game |

Custom routing rất phù hợp với công ty game:

Nhiều phòng chơi trên cùng fleet EC2
    → mỗi cổng ánh xạ tới đúng một instance và cổng
    → người chơi cùng trận luôn tới đúng máy chủ trận đó

Ba yếu tố quyết định định tuyến của Standard accelerator: | Yếu tố | Chi tiết | |---|---| | Sức khoẻ endpoint | không gửi tới endpoint hỏng | | Traffic dial | tỷ lệ lưu lượng mỗi Region | | Vị trí client | Region gần nhất khoẻ mạnh |

Và traffic-dial-percentage cho triển khai dần:

aws globalaccelerator update-endpoint-group   --endpoint-group-arn <arn> --traffic-dial-percentage 10

Chuyển 10% lưu lượng sang Region mới, hoặc đặt 0 để rút một Region ra tức thì.

Ba lưu ý về IP của các load balancer: | Load balancer | IP | |---|---| | ALB | động, thay đổi — CHỈ dùng tên DNS | | NLB | có thể gán Elastic IP tĩnh | | Global Accelerator | 2 IP anycast tĩnh, toàn cầu |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Phí cố định | ~0,025 USD/giờ (~18 USD/tháng) | | Phí truyền dữ liệu cao cấp | theo GB, khác nhau theo Region | | Không có phí request | khác CloudFront |

Ba biện pháp bảo mật đi kèm: | Biện pháp | Chi tiết | |---|---| | AWS Shield Standard tự động | chống DDoS tầng 3/4 | | WAF trên từng ALB phía sau | lọc tầng 7 | | Security group trên ALB | giới hạn nguồn |

Lưu ý: WAF KHÔNG gắn được vào Global Accelerator — phải gắn vào ALB phía sau.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | NewFlowCount | số kết nối mới | | ProcessedBytesIn/Out | lưu lượng | | Health check của endpoint | Region nào đang phục vụ |

Và một lời khuyên: hãy ghi lại hai địa chỉ IP tĩnh vào tài liệu vận hành và chia sẻ với đội mạng của khách hàng doanh nghiệp. Đó chính là giá trị lớn nhất của giải pháp này — thay vì gửi cho họ một danh sách dải IP thay đổi liên tục, bạn gửi hai con số không bao giờ đổi.

Đáp án

C — Tạo bản ghi CNAME.

Vì sao đúng

Đề mô tả tình huống kinh điển của CNAME: trỏ một tên miền phụ sang một tên miền khác.

www.your-domain.com  →  yourapp.provider.com
        ↑                        ↑
    tên miền phụ          tên miền BÊN NGOÀI
    (subdomain)           (không phải tài nguyên AWS)

CNAME là bản ghi bí danh ở tầng DNS chuẩn:

CNAME nói: "tên này là bí danh của tên kia"
    → client tra www.your-domain.com
    → nhận CNAME trỏ tới yourapp.provider.com
    → tra tiếp tên đó để lấy IP

aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{
    "Name":"www.your-domain.com","Type":"CNAME","TTL":300,
    "ResourceRecords":[{"Value":"yourapp.provider.com"}]}}]}'

Và vì sao KHÔNG dùng alias record ở đây:

Alias record của Route 53:
    → CHỈ trỏ tới TÀI NGUYÊN AWS
      (CloudFront, ALB, S3 website, API Gateway, Global Accelerator,
       hoặc bản ghi khác trong CÙNG hosted zone)
        ↓
    yourapp.provider.com là tên miền của NHÀ CUNG CẤP BÊN NGOÀI
    → alias KHÔNG trỏ tới được

Điểm mấu chốt: đây là www, không phải đỉnh tên miền.

www.your-domain.com  → là SUBDOMAIN → CNAME được ✓
your-domain.com      → là ĐỈNH (apex) → CNAME KHÔNG được ✗

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

• **A. Tạo Alias record — đây là phương án gần nhất và là lựa chọn đúng trong nhiều tình huống khác, nhưng nó không dùng được ở đây: alias record chỉ trỏ tới tài nguyên AWS hoặc bản ghi trong cùng hosted zone. Tên miền của nhà cung cấp bên ngoài không thuộc nhóm đó.
• **B. Tạo bản ghi A — không phù hợp: bản ghi A trỏ tới một địa chỉ IP cụ thể. Bạn không biết IP của nhà cung cấp, và IP đó có thể thay đổi bất cứ lúc nào mà không ai báo.
• **D. Tạo bản ghi PTR — sai loại hoàn toàn: PTR dùng cho phân giải ngược (từ IP ra tên miền), phục vụ chống thư rác và ghi log. Không liên quan tới việc trỏ tên miền.

Ghi nhớ

Các loại bản ghi DNS — bảng cần thuộc: | Loại | Việc | |---|---| | A | tên miền → địa chỉ IPv4 | | AAAA | tên miền → địa chỉ IPv6 | | CNAME | tên miền → TÊN MIỀN KHÁC (chỉ subdomain) | | Alias (riêng của Route 53) | tên miền → TÀI NGUYÊN AWS (dùng được ở ĐỈNH) | | MX | máy chủ thư điện tử | | TXT | văn bản tuỳ ý (SPF, DKIM, xác minh sở hữu) | | NS | máy chủ tên của zone | | SOA | thông tin khởi đầu của zone | | PTR | IP → tên miền (phân giải ngược) | | SRV | dịch vụ và cổng | | CAA | CA nào được cấp chứng chỉ |

CNAME và Alias — bảng phân biệt cốt lõi: | | CNAME | Alias | |---|---|---| | Dùng ở ĐỈNH tên miền | ❌ KHÔNG | ✅ ĐƯỢC | | Trỏ tới tên miền BÊN NGOÀI | ✅ ĐƯỢC | ❌ KHÔNG | | Chi phí truy vấn | tính phí | MIỄN PHÍ khi trỏ tới tài nguyên AWS | | Chuẩn DNS | ✅ | ❌ riêng của Route 53 | | Kiểm tra sức khoẻ đích | ❌ | ✅ EvaluateTargetHealth |

Quy tắc chọn — hai câu hỏi:

① Đích có phải TÀI NGUYÊN AWS không?
      Có → alias (miễn phí, dùng được ở đỉnh)
      Không → CNAME

② Bản ghi có ở ĐỈNH tên miền không?
      Có → BẮT BUỘC alias (CNAME không được)
      Không → cả hai đều được

Vì sao CNAME không dùng được ở đỉnh:

Chuẩn DNS (RFC 1034) quy định:
    Nếu một tên có bản ghi CNAME
    → nó KHÔNG được có bản ghi loại khác
        ↓
    Nhưng đỉnh tên miền BẮT BUỘC phải có NS và SOA
    → nên không thể có CNAME

Các đích mà alias record hỗ trợ: | Đích | Hỗ trợ | |---|---| | CloudFront distribution | ✅ | | Application/Network Load Balancer | ✅ | | S3 static website endpoint | ✅ | | API Gateway | ✅ | | Global Accelerator | ✅ | | Elastic Beanstalk environment | ✅ | | VPC interface endpoint | ✅ | | Bản ghi khác trong CÙNG hosted zone | ✅ | | Tên miền bên ngoài | ❌ ← lý do câu này chọn CNAME |

Dòng áp chót đáng chú ý: alias trỏ tới bản ghi khác trong cùng zone là cách chuẩn để đỉnh tên miền trỏ về www.

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | TTL thấp (60 giây) | chuyển đổi nhanh, nhiều truy vấn hơn | | TTL cao (86400 giây) | ít truy vấn, chuyển đổi chậm | | Alias record KHÔNG khai TTL | Route 53 dùng TTL của tài nguyên đích |

Ba lưu ý về chi phí Route 53: | Khoản | Giá tham khảo | |---|---| | Hosted zone | 0,50 USD/tháng (25 zone đầu) | | Truy vấn tiêu chuẩn | ~0,40 USD/triệu | | Truy vấn alias tới tài nguyên AWS | MIỄN PHÍ | | Health check | ~0,50 USD/tháng mỗi cái |

Ba lưu ý khi trỏ tới nhà cung cấp bên ngoài: | Lưu ý | Chi tiết | |---|---| | Nhà cung cấp đổi IP không ảnh hưởng bạn | CNAME tự theo | | Nhưng bạn phụ thuộc DNS của họ | thêm một tầng tra cứu | | Chứng chỉ TLS phải khớp tên miền của bạn | nhà cung cấp phải hỗ trợ tên miền tuỳ chỉnh |

Dòng cuối là chi tiết vận hành quan trọng: nếu nhà cung cấp chỉ có chứng chỉ cho provider.com, trình duyệt sẽ báo lỗi bảo mật khi người dùng vào www.your-domain.com.

Ba cách xử lý đỉnh tên miền: | Cách | Chi tiết | |---|---| | Alias tới tài nguyên AWS | nếu ứng dụng chạy trên AWS | | Alias tới bản ghi www trong cùng zone | cách đơn giản cho chuyển hướng | | S3 bucket cấu hình redirect + alias | chuyển hướng đỉnh sang www |

Ba công cụ kiểm tra DNS:

dig www.your-domain.com CNAME
dig www.your-domain.com +short
nslookup www.your-domain.com

Và một lời khuyên: hãy đặt TTL thấp (60–300 giây) khi mới thiết lập, rồi tăng lên sau khi xác nhận mọi thứ hoạt động. Nếu cấu hình sai hoặc cần đổi nhà cung cấp gấp, TTL 86400 nghĩa là một số người dùng sẽ vẫn thấy giá trị cũ suốt một ngày.

Đáp án

B, C và F.

• B — Nếu spot request là persistent, nó được mở lại sau khi Spot Instance bị gián đoạn
• C — Spot Fleet CÓ THỂ duy trì target capacity bằng cách khởi động instance thay thế
• F — Khi bạn huỷ một spot request đang hoạt động, nó KHÔNG chấm dứt instance liên quan

Vì sao đúng

Ba đáp án mô tả đúng ba cơ chế của Spot:

B — spot request có hai loại: | Loại | Hành vi khi instance bị thu hồi | |---|---| | One-time | request kết thúc, không làm gì thêm | | Persistent | request được MỞ LẠI, AWS tìm năng lực mới |

aws ec2 request-spot-instances --instance-count 5   --type persistent   --instance-interruption-behavior stop   --launch-specification file://cau-hinh.json

C — Spot Fleet duy trì target capacity:

Spot Fleet với type = "maintain":
    → theo dõi năng lực hiện có
    → instance bị thu hồi → TỰ khởi động instance thay thế
    → giữ tổng năng lực ở mức mục tiêu

{"TargetCapacity": 20, "Type": "maintain",
 "AllocationStrategy": "priceCapacityOptimized"}

F — huỷ request không chấm dứt instance:

Huỷ spot request:
    → chỉ dừng việc TÌM năng lực mới
    → instance ĐANG CHẠY vẫn tiếp tục chạy
        ↓
    Muốn dừng cả instance thì phải chấm dứt riêng

Đây là điểm hay gây bất ngờ về chi phí:

Huỷ request rồi tưởng đã xong
    → instance vẫn chạy và vẫn tính tiền
    → phát hiện qua hoá đơn tháng sau

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

• **E. Nếu spot request là persistent thì nó được mở lại sau khi bạn DỪNG (stop) Spot Instance — đây là phương án gần nhất và rất dễ nhầm với B, nhưng nó sai về thời điểm: khi bạn tự dừng instance, request chuyển sang trạng thái disabled và chỉ mở lại khi bạn KHỞI ĐỘNG instance đó. Request được mở lại tự động là khi AWS thu hồi instance, không phải khi bạn chủ động dừng.
• **A. Huỷ spot request đang hoạt động cũng chấm dứt instance — đảo ngược F.
• **D. Spot Fleet KHÔNG THỂ duy trì target capacity — đảo ngược C.

Ghi nhớ

Hai loại spot request — bảng phải thuộc: | Loại | Sau khi instance bị thu hồi | |---|---| | one-time | request kết thúc | | persistent | request mở lại, AWS tìm năng lực mới |

Và ba hành vi khi bị gián đoạn: | Hành vi | Chi tiết | |---|---| | terminate (mặc định) | chấm dứt instance | | stop | DỪNG instance, giữ EBS volume — khởi động lại được | | hibernate | lưu RAM xuống đĩa, phục hồi trạng thái |

stop và hibernate chỉ dùng được với persistent request — và chúng rất hữu ích cho công việc có trạng thái.

Ba loại yêu cầu năng lực Spot: | Cách | Đặc điểm | |---|---| | Spot Instance request | một loại instance, một AZ | | Spot Fleet | nhiều loại, nhiều AZ, tổng năng lực | | EC2 Fleet | như Spot Fleet nhưng trộn được On-Demand và RI | | ASG với mixed instances policy | cách hiện đại nhất, được khuyến nghị |

Hai chế độ của Spot Fleet: | Chế độ | Việc | |---|---| | request | chỉ đặt yêu cầu MỘT LẦN, không bù đắp | | maintain | duy trì target capacity, tự thay thế ← đáp án C |

Bốn chiến lược phân bổ: | Chiến lược | Cách chọn | |---|---| | priceCapacityOptimized | cân bằng giá và năng lực — AWS khuyến nghị | | capacityOptimized | pool dồi dào nhất, ít bị thu hồi nhất | | lowestPrice | rẻ nhất, dễ bị thu hồi | | diversified | trải đều mọi pool |

Ba đặc điểm của Spot cần nhớ: | Đặc điểm | Chi tiết | |---|---| | Giảm tới 90% so với On-Demand | | | Báo trước 2 PHÚT khi bị thu hồi | qua metadata và EventBridge | | Không đảm bảo năng lực | pool có thể hết máy |

Và có thông báo đến SỚM HƠN:

Rebalance Recommendation:
    → cảnh báo pool sắp căng, SỚM hơn thông báo 2 phút
    → có nhiều thời gian hơn để dịch chuyển công việc

Cách bắt thông báo thu hồi:

TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token"   -H "X-aws-ec2-metadata-token-ttl-seconds: 300")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN"   http://169.254.169.254/latest/meta-data/spot/instance-action

Hoặc qua EventBridge:

{"source": ["aws.ec2"],
 "detail-type": ["EC2 Spot Instance Interruption Warning"]}

Ba loại workload phù hợp với Spot: | Loại | Ví dụ | |---|---| | Xử lý lô | ← tình huống trong đề | | CI/CD | build và test | | Kết xuất, chuyển mã | video, đồ hoạ | | Container không trạng thái | web tier có ASG |

Ba loại KHÔNG nên dùng Spot:

❌ Database và kho trạng thái
❌ Dịch vụ đòi sẵn sàng liên tục
❌ Việc chạy lâu KHÔNG có checkpoint

Ba cách tăng độ ổn định: | Cách | Chi tiết | |---|---| | Đa dạng hoá loại instance và AZ | quan trọng nhất | | Dùng priceCapacityOptimized | | | Xử lý êm thông báo thu hồi | lưu checkpoint trong 2 phút |

Ba dịch vụ tự quản lý Spot tốt: | Dịch vụ | Chi tiết | |---|---| | AWS Batch | tự quản lý hàng đợi, tự thử lại | | EMR | node lõi On-Demand, node task Spot | | ECS/EKS với Fargate Spot | container |

Ba công cụ đánh giá: | Công cụ | Việc | |---|---| | Spot Instance Advisor | tần suất bị thu hồi lịch sử của từng loại | | Spot placement score | Region và AZ nào có năng lực tốt | | Cost Explorer | so chi phí trước và sau |

Và một lời khuyên: hãy kiểm tra danh sách instance đang chạy sau khi huỷ spot request. Đây chính là điểm mà đáp án F chỉ ra — huỷ request không dừng máy, và với công việc chạy lô hằng đêm, một instance bị bỏ quên sẽ chạy suốt tháng mà không ai để ý.