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

Đáp án

C — Dùng AWS Storage Gateway — Cached Volumes.

Vì sao đúng

Đề nêu ba yêu cầu, và cached volume gateway đáp ứng chính xác cả ba: | Yêu cầu | Cơ chế | |---|---| | Dữ liệu chính lưu ở AWS | toàn bộ dữ liệu nằm trong S3 | | Dữ liệu HAY TRUY CẬP giữ tại chỗ | cache trên đĩa cục bộ | | Không mở rộng được kho tại chỗ | dung lượng thật nằm trên đám mây |

Cách cached volume hoạt động:

Máy chủ tại chỗ mount volume qua iSCSI
    → dùng như một ổ đĩa bình thường
        ↓
Dữ liệu ĐẦY ĐỦ lưu ở S3 (do AWS quản lý)
Đĩa cục bộ chỉ giữ CACHE của phần hay dùng
    → đọc dữ liệu nóng: nhanh như đĩa cục bộ
    → đọc dữ liệu nguội: lấy từ S3

Và đó chính là "mở rộng dung lượng bằng đám mây" mà đề mô tả:

Đĩa cục bộ 2 TB làm cache
    → phục vụ được 30 TB dữ liệu nằm ở S3
    → không phải mua thêm tủ đĩa

Mỗi cached volume chứa tới 32 TB, một gateway hỗ trợ 32 volume — tổng cộng khoảng 1 PB.

Và dữ liệu ở S3 thì bền vững và mở rộng được — đúng yêu cầu "durable and scalable storage service" của đề.

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

• **A. Dùng đội EC2 instance với EBS volume để lưu dữ liệu hay dùng — đây là phương án gần nhất về mặt cũng dùng lưu trữ AWS, nhưng nó không giải quyết vấn đề truy cập tại chỗ: EBS chỉ gắn được vào EC2 trong AWS. Máy chủ trong trung tâm dữ liệu không mount EBS được, nên dữ liệu "hay truy cập" vẫn phải đi qua mạng ra AWS mỗi lần đọc.
• **B. Dùng ElastiCache và S3 cho dữ liệu hay truy cập — ElastiCache nằm TRONG VPC của AWS, không phải trên máy chủ tại chỗ. Nó không cung cấp cache cục bộ nào cho trung tâm dữ liệu.
• **D. Dùng Amazon Glacier — sai loại nhu cầu: Glacier dành cho lưu trữ dài hạn hiếm khi truy cập, thời gian lấy dữ liệu tính bằng phút tới giờ. Nó không phục vụ dữ liệu "frequently accessed".

Ghi nhớ

Ba loại Storage Gateway — bảng cần thuộc: | Loại | Giao thức | Đích | Dùng cho | |---|---|---|---| | File Gateway | NFS, SMB | S3 | chia sẻ tệp, kho dữ liệu | | Volume Gateway | iSCSI | S3 dạng EBS snapshot | ổ đĩa khối cho ứng dụng ← câu này | | Tape Gateway | iSCSI VTL | S3 Glacier | thay thư viện băng từ |

Hai chế độ của Volume Gateway — điểm phân biệt chính: | | Cached volume | Stored volume | |---|---|---| | Dữ liệu ĐẦY ĐỦ ở đâu | AWS (S3) | TẠI CHỖ | | Đĩa cục bộ dùng làm gì | CACHE | lưu toàn bộ dữ liệu | | AWS giữ gì | dữ liệu chính | bản sao lưu (snapshot) | | Dung lượng mỗi volume | tới 32 TB | tới 16 TB | | Mở rộng dung lượng bằng đám mây | ✅ | ❌ | | Độ trễ đọc | thấp cho dữ liệu nóng | thấp cho MỌI dữ liệu |

Quy tắc chọn:

"Không đủ chỗ tại chỗ, muốn mở rộng bằng đám mây" → CACHED "Đủ chỗ tại chỗ, chỉ cần sao lưu lên đám mây" → STORED

Đề nói rõ "they do not have the option to extend their on-premises storage" → cached volume.

Ba yêu cầu khi triển khai Volume Gateway: | Yêu cầu | Chi tiết | |---|---| | Máy ảo gateway tại chỗ | VMware, Hyper-V, KVM, hoặc thiết bị phần cứng của AWS | | Đĩa cục bộ cho CACHE | kích thước quyết định trải nghiệm | | Đĩa cục bộ cho UPLOAD BUFFER | vùng đệm dữ liệu chờ đẩy lên S3 |

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

Cache nhỏ hơn tập dữ liệu nóng
    → mọi lần đọc phải lấy từ S3
    → người dùng cảm nhận rõ độ trễ
    → mất hết lợi ích của mô hình cached

AWS khuyến nghị cache ít nhất bằng 20% dung lượng volume, và lớn hơn nếu tập dữ liệu nóng lớn.

Ba đặc điểm khác của Volume Gateway: | Đặc điểm | Chi tiết | |---|---| | Snapshot theo lịch | lưu thành EBS snapshot, khôi phục được thành EBS volume | | Khôi phục sang EC2 | volume tại chỗ khôi phục được thành EBS volume trong AWS | | Nén dữ liệu khi truyền | tiết kiệm băng thông |

Dòng giữa là lợi ích đáng chú ý cho phục hồi thảm hoạ: trung tâm dữ liệu gặp sự cố, bạn khôi phục snapshot thành EBS volume và chạy ứng dụng trên EC2.

Các dịch vụ lưu trữ lai — chọn đúng: | Dịch vụ | Phù hợp | |---|---| | Storage Gateway | truy cập LIÊN TỤC — tại chỗ dùng, dữ liệu ở AWS | | AWS DataSync | DI CHUYỂN hoặc đồng bộ định kỳ | | AWS Snow Family | khối lượng rất lớn, băng thông kém | | FSx File Gateway | truy cập FSx for Windows từ tại chỗ |

Storage Gateway và DataSync hay bị nhầm:

DataSync:         DI CHUYỂN dữ liệu (một lần hoặc theo lịch)
Storage Gateway:  TRUY CẬP dữ liệu liên tục (như ổ đĩa mạng)

Thường dùng cùng nhau: DataSync chuyển khối lượng ban đầu (nhanh hơn), Storage Gateway phục vụ truy cập hằng ngày.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí gateway theo giờ | tính cho mỗi gateway đang chạy | | Chi phí lưu trữ ở S3 | theo dung lượng thật | | Phí truyền dữ liệu RA khỏi AWS | khi cache miss và phải đọc từ S3 |

Dòng cuối đáng lưu ý: nếu tỷ lệ cache miss cao, phí truyền dữ liệu ra có thể lớn bất ngờ. Đây là một lý do nữa để cấp cache đủ lớn.

Và một lời khuyên về băng thông: hãy đặt giới hạn băng thông theo lịch để việc đẩy dữ liệu lên S3 không làm nghẽn đường truyền trong giờ làm việc — Storage Gateway hỗ trợ cấu hình này sẵn.

Đáp án

D — Dùng CloudTrail với cấu hình MẶC ĐỊNH.

Vì sao đúng

Đề cần log file được mã hoá — và CloudTrail đã làm điều đó sẵn.

Mã hoá mặc định của CloudTrail:

CloudTrail ghi log vào S3 bucket
    → TỰ ĐỘNG mã hoá bằng SSE-S3 (AES-256)
    → không cần bật gì
    → không cần cấu hình gì

Nên câu trả lời cho "how to implement the encryption" là: nó đã được thực hiện rồi.

Và CloudTrail còn có sẵn một cơ chế bảo vệ nữa: log file validation.

Bật validation → CloudTrail tạo tệp digest có CHỮ KÝ SỐ
    → chứng minh log CHƯA BỊ SỬA ĐỔI kể từ lúc AWS ghi ra
    → quan trọng cho kiểm toán và điều tra

aws cloudtrail update-trail --name theo-doi-api --enable-log-file-validation

Và nó đáp ứng luôn nhu cầu chính của đề — theo dõi thay đổi tài nguyên:

CloudTrail ghi MỌI lời gọi API:
    ai gọi (principal)
    gọi gì (RunInstances, DeleteBucket, ModifyDBInstance...)
    lúc nào, từ IP nào
    thành công hay thất bại

Muốn tìm nhanh thay đổi gần đây, dùng CloudTrail Event history (có sẵn 90 ngày, không cần tạo trail):

aws cloudtrail lookup-events   --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances   --start-time 2026-08-29T00:00:00Z

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

• **B. Dùng CloudTrail và cấu hình bucket đích dùng SSE — đây là phương án gần nhất và không sai về mặt kỹ thuật, nhưng nó thừa: SSE-S3 đã được áp dụng mặc định cho log của CloudTrail. Cấu hình lại không thêm gì. (Nếu muốn dùng SSE-KMS để có audit trail về việc giải mã thì đó là cấu hình có ý nghĩa — nhưng phương án không nói vậy.)
• **C. Dùng SSE với thuật toán AES-128 — sai thông số: SSE-S3 dùng AES-256, không có tuỳ chọn AES-128.
• **A. Cấu hình Glacier archive đích dùng SSE — sai đích lưu: CloudTrail ghi log vào S3 bucket, không ghi thẳng vào Glacier vault. (Có thể dùng lifecycle rule chuyển log sang Glacier sau, nhưng đó là bước riêng.)

Ghi nhớ

Ba cơ chế bảo vệ log của CloudTrail: | Cơ chế | Trạng thái | |---|---| | Mã hoá SSE-S3 | BẬT MẶC ĐỊNH | | Log file validation | phải bật tường minh — nên bật | | SSE-KMS | tuỳ chọn, cho kiểm soát và audit chặt hơn |

Ba loại sự kiện của CloudTrail — bảng cần thuộc: | Loại | Ghi gì | Chi phí | |---|---|---| | Management event | thao tác trên TÀI NGUYÊN: tạo, sửa, xoá | miễn phí cho bản sao đầu tiên | | Data event | thao tác TRÊN DỮ LIỆU: s3:GetObject, lambda:Invoke | có phí, khối lượng RẤT LỚN | | Insights event | phát hiện hoạt động API bất thường | có phí |

Đề nói "creation, modification, and deletion of AWS resources" → đó là management event, có sẵn miễn phí.

CloudTrail và CloudWatch — đừng nhầm: | | CloudTrail | CloudWatch | |---|---|---| | Câu hỏi trả lời | "AI đã làm gì?" | "hệ thống chạy thế nào?" | | Nội dung | lời gọi API | metric và log | | Dùng cho | kiểm toán, bảo mật, tuân thủ | giám sát hiệu năng |

Ba đặc điểm của CloudTrail cần nhớ: | Đặc điểm | Chi tiết | |---|---| | Event history 90 ngày MIỄN PHÍ | có sẵn, không cần tạo trail | | Muốn giữ lâu hơn phải tạo TRAIL ghi vào S3 | | | Độ trễ khoảng 15 phút | không phải thời gian thực |

Bốn thực hành tốt khi cấu hình CloudTrail: | Thực hành | Lý do | |---|---| | Tạo trail cho TOÀN BỘ Region | --is-multi-region-trail — hoạt động ở Region lạ vẫn bị ghi | | Ghi vào bucket ở TÀI KHOẢN RIÊNG | kẻ tấn công chiếm tài khoản chính vẫn không xoá được log | | Bật log file validation | chứng minh log toàn vẹn | | Bật organization trail | một trail cho mọi tài khoản trong Organizations |

Dòng thứ hai là biện pháp bảo vệ quan trọng nhất:

Log nằm cùng tài khoản với hệ thống bị tấn công
    → kẻ tấn công có quyền quản trị sẽ XOÁ log để xoá dấu vết
    ↓
Log ở tài khoản riêng, chỉ ghi được không xoá được
    → dấu vết được bảo toàn

Và bảo vệ log bằng S3 Object Lock:

Object Lock chế độ Compliance
    → KHÔNG AI xoá được log trong thời hạn giữ, kể cả root
    → đáp ứng yêu cầu WORM của nhiều quy định

Ba cách phân tích log CloudTrail: | Cách | Đặc điểm | |---|---| | CloudTrail Event history (Console) | nhanh nhất cho 90 ngày gần đây | | CloudTrail Lake | kho được quản lý, truy vấn bằng SQL, giữ tới 10 năm | | Athena trên bucket log | linh hoạt, rẻ |

CloudTrail Lake đáng biết: nó bỏ qua bước dựng bảng Athena và cho truy vấn SQL trực tiếp, giữ dữ liệu lâu hơn nhiều so với event history.

Và để nhận cảnh báo thời gian thực về thay đổi quan trọng:

CloudTrail → CloudWatch Logs → metric filter → alarm → SNS

Hoặc gọn hơn: EventBridge rule bắt trực tiếp sự kiện API:

{"source": ["aws.ec2"],
 "detail-type": ["AWS API Call via CloudTrail"],
 "detail": {"eventName": ["TerminateInstances", "DeleteSecurityGroup"]}}

Và một lưu ý về chi phí: management event miễn phí cho bản sao đầu tiên, nhưng tạo nhiều trail cùng ghi management event thì các bản sau tính phí. Và data event rất tốn với bucket có lưu lượng lớn — hãy giới hạn phạm vi theo prefix thay vì bật cho toàn bộ.

Đáp án

B — AWS Directory Service, kết nối VPN, và Amazon WorkSpaces.

Vì sao đúng

Đề nêu ba yêu cầu, và mỗi dịch vụ giải một yêu cầu: | Yêu cầu | Dịch vụ | |---|---| | Triển khai MÁY TÍNH ẢO (virtual desktop) | Amazon WorkSpaces | | Tận dụng Active Directory sẵn có | AWS Directory Service | | Vẫn liên lạc được với mạng tại chỗ | VPN connection |

Amazon WorkSpaces là dịch vụ máy tính để bàn ảo (DaaS) của AWS:

Thay vì mua máy trạm vật lý cho nhân viên mới:
    → cấp một WorkSpace cho mỗi người
    → truy cập từ trình duyệt hoặc ứng dụng client
    → trả tiền theo tháng hoặc theo giờ
    → khởi tạo trong vài phút

Và WorkSpaces BẮT BUỘC phải có thư mục — đó là lý do Directory Service là thành phần không thể thiếu:

WorkSpaces dùng Active Directory để:
    ✓ xác thực người dùng
    ✓ áp Group Policy
    ✓ quản lý danh sách người dùng tập trung

Ba lựa chọn thư mục cho tình huống này: | Lựa chọn | Đặc điểm | |---|---| | AD Connector | cầu nối tới AD tại chỗ — KHÔNG lưu dữ liệu nào trên AWS | | AWS Managed Microsoft AD | AD thật trên AWS, tạo trust với AD tại chỗ | | Simple AD | tương thích Samba, cho nhu cầu cơ bản |

Với startup chỉ có 10 máy tính và AD tại chỗ sẵn có, AD Connector là lựa chọn gọn nhất — không phải nhân bản danh tính, và đúng yêu cầu "leverage the existing security controls".

Và VPN nối hai mạng lại:

VPC (WorkSpaces + AD Connector)
    ↕ Site-to-Site VPN
Mạng tại chỗ (Active Directory, máy chủ tệp)

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

• **C. Directory Service, VPN, và AWS IAM — đây là phương án gần nhất vì cả ba đều là dịch vụ hợp lệ, nhưng nó thiếu phần quan trọng nhất: IAM quản lý quyền truy cập tài nguyên AWS, nó không cung cấp máy tính để bàn ảo. Không có WorkSpaces thì không có virtual desktop nào.
• **A. Directory Service, VPN, và ClassicLink — dịch vụ đã lỗi thời: ClassicLink dùng để nối EC2-Classic với VPC, đã ngừng hoàn toàn. Và nó không liên quan tới máy tính ảo.
• **D. Directory Service, VPN, và Amazon S3 — S3 là kho lưu trữ object, không phải nền tảng máy tính để bàn.

Ghi nhớ

Ba dịch vụ máy tính ảo của AWS: | Dịch vụ | Việc | |---|---| | Amazon WorkSpaces | máy tính để bàn ảo ĐẦY ĐỦ (Windows hoặc Linux) | | Amazon AppStream 2.0 | truyền một ỨNG DỤNG cụ thể, không phải cả desktop | | WorkSpaces Web | truy cập web an toàn từ trình duyệt |

Bốn loại thư mục trong AWS Directory Service: | Loại | Đặc điểm | |---|---| | AWS Managed Microsoft AD | AD thật chạy trên AWS, tạo trust được với AD tại chỗ | | AD Connector | CẦU NỐI tới AD tại chỗ — không lưu dữ liệu nào | | Simple AD | tương thích Samba, rẻ, cho nhu cầu cơ bản | | Cognito | cho người dùng ứng dụng, không phải nhân viên |

AD Connector và Managed Microsoft AD — chọn cái nào: | | AD Connector | Managed Microsoft AD | |---|---|---| | Lưu dữ liệu người dùng trên AWS | ❌ không | ✅ | | Hoạt động khi mất kết nối tới AD tại chỗ | ❌ ngừng xác thực | ✅ độc lập | | Chi phí | thấp hơn | cao hơn | | Phù hợp | AD tại chỗ là nguồn duy nhất | cần AD hoạt động độc lập trên AWS |

Dòng thứ hai là rủi ro thực tế của AD Connector: nếu VPN đứt, nhân viên không đăng nhập vào WorkSpaces được. Với môi trường quan trọng, Managed Microsoft AD với trust hai chiều an toàn hơn.

Ba lợi ích của WorkSpaces cho startup: | Lợi ích | Chi tiết | |---|---| | Không mua máy trạm vật lý | chi phí đầu tư ban đầu bằng 0 | | Cấp phát trong vài phút | nhân viên mới có máy ngay | | Dữ liệu KHÔNG nằm trên thiết bị cá nhân | an toàn hơn nhiều khi nhân viên dùng máy riêng |

Dòng cuối là lợi ích bảo mật quan trọng: laptop bị mất không kéo theo dữ liệu công ty, vì mọi thứ nằm trên WorkSpace trong đám mây.

Hai chế độ tính phí của WorkSpaces: | Chế độ | Phù hợp | |---|---| | AlwaysOn (theo tháng) | nhân viên toàn thời gian dùng hằng ngày | | AutoStop (theo giờ) | nhân viên bán thời gian, nhà thầu, dùng thưa |

AutoStop tự tắt WorkSpace sau thời gian không hoạt động — với người dùng vài giờ mỗi tuần, nó rẻ hơn rất nhiều.

Ba lưu ý khi triển khai WorkSpaces: | Lưu ý | Chi tiết | |---|---| | Cần ÍT NHẤT hai subnet ở hai AZ | yêu cầu của dịch vụ | | Băng thông và độ trễ ảnh hưởng trải nghiệm | giao thức PCoIP hoặc WSP | | Chọn đúng bundle | Value, Standard, Performance, Power, Graphics |

Và một lựa chọn quan trọng: giao thức truyền hình ảnh. | Giao thức | Đặc điểm | |---|---| | WSP (WorkSpaces Streaming Protocol) | tốt hơn khi độ trễ mạng cao, hỗ trợ webcam | | PCoIP | giao thức cũ, ổn định |

Với nhân viên làm việc từ xa qua đường truyền không ổn định, WSP cho trải nghiệm tốt hơn rõ rệt.

Và cân nhắc Direct Connect thay VPN khi số người dùng tăng:

VPN qua Internet:
    → độ trễ biến động → hình ảnh giật khi mạng nghẽn
Direct Connect:
    → độ trễ ổn định → trải nghiệm desktop mượt hơn

(Với startup 10 người và AD tại chỗ, VPN hoàn toàn đủ — nhưng đây là điều cần nhớ khi mở rộng.)

Và một lưu ý về sao lưu: WorkSpaces tự chụp snapshot mỗi 12 giờ cho ổ hệ thống và ổ người dùng. Nhưng đó không thay thế được chính sách sao lưu dữ liệu quan trọng — hãy khuyến khích nhân viên lưu tài liệu vào máy chủ tệp trung tâm hoặc S3 thay vì để trên desktop.

Đáp án

D — Tạo bản ghi A dạng alias trỏ tới tên DNS của load balancer.

Vì sao đúng

Đề nêu một ràng buộc kỹ thuật quan trọng: bản ghi ở ĐỈNH tên miền (zone apex), ví dụ congty.com chứ không phải www.congty.com.

Và đó là chỗ mà CNAME KHÔNG dùng được:

Chuẩn DNS (RFC 1034):
    Bản ghi CNAME KHÔNG được cùng tồn tại với bản ghi khác trên cùng tên
        ↓
    Đỉnh tên miền BẮT BUỘC phải có bản ghi SOA và NS
        ↓
    → không đặt CNAME ở đỉnh tên miền được

Alias record là giải pháp riêng của Route 53 cho vấn đề này:

Alias record là bản ghi A (hoặc AAAA) đặc biệt
    → trỏ tới TÀI NGUYÊN AWS thay vì địa chỉ IP
    → Route 53 tự phân giải thành IP hiện tại của tài nguyên đó
    → dùng được ở ĐỈNH tên miền

Ba ưu điểm của alias so với CNAME: | Ưu điểm | Chi tiết | |---|---| | Dùng được ở đỉnh tên miền | ← lý do chính | | MIỄN PHÍ | Route 53 không tính phí truy vấn alias tới tài nguyên AWS | | Tự cập nhật khi đích đổi IP | ALB đổi IP thường xuyên, alias tự theo |

aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes": [{"Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "congty.com",
      "Type": "A",
      "AliasTarget": {
        "HostedZoneId": "Z35SXDOTRQ7X7K",
        "DNSName": "alb-cong-ty-123456.ap-southeast-1.elb.amazonaws.com",
        "EvaluateTargetHealth": true}}}]}'

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

• **B. Tạo CNAME trỏ tới tên DNS của load balancer — đây là phương án gần nhất và hoàn toàn đúng cho tên miền CON, nhưng nó không dùng được ở ĐỈNH tên miền. Đó chính là điều mà câu hỏi kiểm tra.
• **C. Tạo alias cho bản ghi CNAME — sai về mặt khái niệm: alias trong Route 53 là một thuộc tính của bản ghi A hoặc AAAA, không phải của CNAME. Không có thứ gọi là "alias CNAME record".
• **A. Tạo bản ghi A trỏ tới ĐỊA CHỈ IP của load balancer — sai về mặt vận hành: ALB KHÔNG có IP tĩnh — địa chỉ của nó thay đổi khi AWS mở rộng hoặc thay thế node. Hard-code IP là bảo đảm sẽ hỏng.

Ghi nhớ

Alias và CNAME — bảng phân biệt cốt lõi: | | Alias | CNAME | |---|---|---| | Dùng ở ĐỈNH tên miền | ✅ | ❌ | | Chi phí truy vấn | MIỄN PHÍ (tới tài nguyên AWS) | tính phí | | Trỏ tới | tài nguyên AWS, hoặc record khác cùng zone | bất kỳ tên miền nào | | Loại bản ghi | A hoặc AAAA | CNAME | | Health check của đích | ✅ EvaluateTargetHealth | ❌ | | Hoạt động ngoài Route 53 | ❌ | ✅ |

Quy tắc: với tài nguyên AWS, LUÔN dùng alias.

Các đích mà alias record trỏ được:

CloudFront distribution
Elastic Load Balancer (ALB, NLB, CLB)   ← câu này
API Gateway custom domain name
S3 static website endpoint
Elastic Beanstalk environment
Global Accelerator
VPC interface endpoint
AWS App Runner
Record khác trong cùng hosted zone

Lưu ý: alias KHÔNG trỏ tới EC2 instance được — với EC2, dùng bản ghi A trỏ tới Elastic IP.

Ba loại IP của Elastic Load Balancer: | Loại LB | Địa chỉ | |---|---| | ALB | IP ĐỘNG — bắt buộc dùng tên DNS | | NLB | IP TĨNH mỗi AZ (hoặc Elastic IP) | | Global Accelerator | hai IP tĩnh anycast toàn cầu |

Nếu thực sự cần IP tĩnh cho ứng dụng web (ví dụ đối tác phải khai vào tường lửa), hãy đặt Global Accelerator trước ALB — nó cho hai IP cố định vĩnh viễn.

Và EvaluateTargetHealth là tuỳ chọn đáng bật:

EvaluateTargetHealth = true
    → Route 53 tự kiểm tra sức khoẻ của ALB
    → ALB hỏng → Route 53 không trả về bản ghi đó
    → kết hợp với failover routing để chuyển sang Region khác

Các loại bản ghi DNS thường gặp: | Loại | Việc | |---|---| | A | tên → địa chỉ IPv4 | | AAAA | tên → địa chỉ IPv6 | | CNAME | tên → tên khác | | MX | máy chủ email | | TXT | văn bản tuỳ ý (xác minh tên miền, SPF, DKIM) | | NS | máy chủ tên của zone | | SOA | thông tin quản trị của zone | | CAA | CA nào được cấp chứng chỉ cho tên miền |

Bảy chính sách định tuyến của Route 53: | Chính sách | Việc | |---|---| | Simple | một bản ghi, không health check | | Weighted | chia lưu lượng theo tỷ lệ | | Latency-based | tới Region có độ trễ thấp nhất | | Failover | primary / secondary | | Geolocation | theo vị trí người dùng | | Geoproximity | theo khoảng cách, có bias | | Multivalue answer | tới 8 bản ghi lành mạnh |

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | Alias record không có TTL riêng | kế thừa TTL của tài nguyên đích | | TTL thấp cho bản ghi dùng failover | 60 giây hoặc ít hơn | | TTL cao cho bản ghi ổn định | giảm số truy vấn, giảm chi phí |

Và một mẫu cấu hình phổ biến cho website:

congty.com       → A alias  → ALB          (đỉnh tên miền)
www.congty.com   → A alias  → ALB          (hoặc CNAME tới congty.com)

Nhiều tổ chức chọn một dạng làm chính rồi chuyển hướng 301 dạng kia — nhất quán hơn cho SEO.

Và một lưu ý khi chuyển tên miền sang Route 53: hãy hạ TTL của bản ghi cũ xuống 60 giây vài ngày TRƯỚC khi chuyển. Nếu không, các resolver trên thế giới vẫn giữ bản ghi cũ trong suốt thời gian TTL — và một số người dùng sẽ không truy cập được sau khi bạn đã chuyển xong.

Đáp án

A — Đổi kiến trúc để truy cập dữ liệu tài chính qua Gateway VPC Endpoint.

Vì sao đúng

Đề nêu hai yêu cầu, và gateway endpoint đáp ứng cả hai tối ưu: | Yêu cầu | Cơ chế | |---|---| | Loại bỏ rủi ro do kết nối Internet tới S3 | lưu lượng đi qua mạng nội bộ của AWS | | TIẾT KIỆM CHI PHÍ NHẤT | gateway endpoint HOÀN TOÀN MIỄN PHÍ |

Cách nó loại bỏ rủi ro:

TRƯỚC:
    EC2 (private subnet) → NAT gateway → Internet → endpoint công khai của S3
        → lưu lượng ĐI QUA Internet công cộng

SAU khi có gateway endpoint:
    EC2 → route table → vpce-xxxx → S3
        → KHÔNG BAO GIỜ ra khỏi mạng AWS

Và nó miễn phí hoàn toàn:

Gateway endpoint (chỉ S3 và DynamoDB):
    Không phí giờ
    Không phí xử lý dữ liệu
    → 0 đồng

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc123   --service-name com.amazonaws.ap-southeast-1.s3   --route-table-ids rtb-private-1a rtb-private-1b

Và endpoint policy siết thêm một lớp bảo vệ:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": ["arn:aws:s3:::kho-tai-chinh/*"]}]}

Instance không dùng endpoint này để tải dữ liệu lên bucket khác được — biện pháp chống rò rỉ dữ liệu hiệu quả.

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

• **D. Truy cập S3 qua interface VPC endpoint (PrivateLink) — đây là phương án gần nhất và cũng loại bỏ được kết nối Internet, nhưng nó TỐN TIỀN: interface endpoint tính phí theo giờ cho mỗi AZ CỘNG phí mỗi GB xử lý. Đề hỏi "most cost-effective manner", và gateway endpoint làm cùng việc với giá 0.
• **B. Truy cập S3 qua kết nối VPN — sai kiến trúc: VPN nối VPC với mạng tại chỗ, không phải với dịch vụ AWS. Và nó vẫn đi qua Internet.
• **C. Tạo custom VPC endpoint service cho S3 — hiểu sai công cụ: VPC endpoint service (PrivateLink) là cách BẠN phơi dịch vụ CỦA MÌNH cho VPC khác. Nó không dùng để truy cập S3 — AWS đã cung cấp endpoint sẵn cho S3.

Ghi nhớ

Hai loại VPC endpoint — bảng phân biệt cốt lõi: | | Gateway endpoint | Interface endpoint | |---|---|---| | Dịch vụ hỗ trợ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS | | Chi phí | MIỄN PHÍ | phí giờ mỗi AZ + phí mỗi GB | | Cơ chế | route trong route table | ENI có IP riêng trong subnet | | Truy cập từ tại chỗ (DX/VPN) | ❌ | ✅ | | Dùng qua VPC peering | ❌ | ✅ | | Security group | không gắn được | gắn được |

"Chỉ S3 và DynamoDB" là điều cần thuộc lòng.

Khi nào PHẢI dùng interface endpoint cho S3 dù tốn tiền: | Tình huống | Lý do | |---|---| | Truy cập từ trung tâm dữ liệu qua Direct Connect | gateway endpoint không hoạt động ngoài VPC | | Truy cập từ VPC khác qua peering | gateway endpoint không đi qua peering | | Tường lửa tại chỗ lọc theo IP riêng tư | cần địa chỉ IP cố định |

Và có một chi tiết trong đề đáng làm rõ: pre-signed URL.

Đề nói người dùng truy cập dữ liệu qua pre-signed URL trên Internet
    → đó là NGƯỜI DÙNG CUỐI gọi thẳng S3 từ trình duyệt
    → VPC endpoint KHÔNG ảnh hưởng tới luồng đó
        ↓
VPC endpoint giải quyết luồng: ỨNG DỤNG trên EC2 → S3
    → đó là mối lo mà đội bảo mật nêu ra

Nếu muốn siết luôn luồng người dùng cuối, có hai hướng: | Hướng | Cách làm | |---|---| | CloudFront + Origin Access Control + signed URL | bucket riêng tư hoàn toàn, phân phối qua CDN | | Bucket policy giới hạn theo endpoint | chỉ cho truy cập qua VPC endpoint |

Bucket policy khoá theo endpoint:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::kho-tai-chinh",
              "arn:aws:s3:::kho-tai-chinh/*"],
 "Condition": {"StringNotEquals": {"aws:sourceVpce": "vpce-0abc123"}}}

Lưu ý: chính sách này cũng CHẶN LUÔN pre-signed URL từ Internet — hãy cân nhắc xem yêu cầu nghiệp vụ có cho phép không.

Ba lưu ý khi triển khai gateway endpoint: | Lưu ý | Chi tiết | |---|---| | Phải gắn vào ĐÚNG mọi route table | quên một cái là subnet đó vẫn đi qua NAT | | Chỉ hoạt động trong cùng Region | bucket ở Region khác vẫn đi Internet | | Không thay thế IAM | endpoint là đường đi, quyền vẫn do IAM quyết định |

Và sau khi đặt endpoint, hãy kiểm tra còn lưu lượng nào qua NAT:

Các dịch vụ hay tốn tiền qua NAT:
    ECR (kéo image container)
    CloudWatch Logs
    Systems Manager
    Secrets Manager, KMS
→ tất cả đều có interface endpoint

Ba biện pháp bảo mật khác cho dữ liệu tài chính trên S3: | Biện pháp | Cấu hình | |---|---| | Mã hoá bằng SSE-KMS | có audit trail về ai giải mã | | Bắt buộc HTTPS | điều kiện aws:SecureTransport | | Block Public Access ở mức tài khoản | ngăn cấu hình sai | | Bật CloudTrail data event | ghi mọi thao tác object-level |

Chính sách bắt buộc HTTPS:

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

Nhớ liệt kê CẢ bucket ARN lẫn object ARN — thiếu một cái là chính sách hở.

Và một lưu ý về pre-signed URL: hãy đặt thời hạn ngắn nhất có thể (vài phút thay vì vài giờ) và cân nhắc thêm điều kiện IP nếu biết trước phạm vi người dùng. URL đã cấp không thu hồi được — chỉ có thể chờ nó hết hạn.

Đáp án

A — EBS volume DÙNG ĐƯỢC BÌNH THƯỜNG trong khi snapshot đang được tạo.

Vì sao đúng

Đề hỏi về hành vi của EBS khi đang chụp snapshot — và câu trả lời là snapshot không cản trở việc sử dụng volume.

Cách EBS snapshot hoạt động:

Bắt đầu chụp snapshot
    → EBS ghi nhận TRẠNG THÁI của volume tại thời điểm đó
    → API trả về NGAY (trạng thái pending)
        ↓
Việc sao chép dữ liệu sang S3 diễn ra Ở NỀN
    → volume vẫn đọc ghi bình thường
    → instance vẫn chạy bình thường
    → gắn hoặc tháo volume vẫn được

Điểm mấu chốt: snapshot là ảnh chụp TẠI THỜI ĐIỂM BẮT ĐẦU (point-in-time).

Dữ liệu ghi vào volume SAU khi bắt đầu chụp
    → KHÔNG nằm trong snapshot đó
    → nhưng cũng không làm hỏng snapshot

Nên trong tình huống của đề, kỹ sư hoàn toàn có thể thao tác ngay:

Snapshot đang chạy lúc 12 giờ đêm
    → vẫn sửa được cấu hình trên instance
    → vẫn ghi dữ liệu vào volume
    → vẫn tháo và gắn volume nếu cần

Và có một lưu ý về tính nhất quán của dữ liệu:

Snapshot ghi lại trạng thái ĐĨA, không phải trạng thái ỨNG DỤNG
    → dữ liệu đang nằm trong bộ đệm của hệ điều hành hoặc database
      có thể CHƯA được ghi xuống đĩa
    → snapshot sẽ thiếu phần đó

Với database, hãy flush bộ đệm hoặc tạm dừng ghi trước khi chụp để có snapshot nhất quán về mặt ứng dụng.

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

• **C. Volume dùng được ở chế độ CHỈ ĐỌC trong lúc chụp — đây là phương án gần nhất và là hạn chế mà nhiều hệ thống lưu trữ truyền thống có, nhưng EBS không giới hạn ghi: volume đọc và ghi bình thường suốt quá trình.
• **B. Volume không tháo hoặc gắn được cho tới khi snapshot xong — sai: các thao tác gắn và tháo vẫn thực hiện được bình thường.
• **D. Volume không dùng được cho tới khi snapshot xong — sai hoàn toàn: đây là hiểu nhầm về cách EBS snapshot hoạt động.

Ghi nhớ

Ba đặc điểm của EBS snapshot: | Đặc điểm | Chi tiết | |---|---| | Không chặn việc dùng volume | ← câu này | | TĂNG DẦN (incremental) | chỉ lưu KHỐI DỮ LIỆU THAY ĐỔI so với snapshot trước | | Lưu trong S3 do AWS quản lý | bạn không thấy bucket, nhưng độ bền rất cao |

Tính chất tăng dần là điều quan trọng nhất về mặt chi phí:

Snapshot 1: volume 100 GB có 40 GB dữ liệu → lưu 40 GB
Snapshot 2: thay đổi 5 GB                  → chỉ lưu 5 GB
Snapshot 3: thay đổi 3 GB                  → chỉ lưu 3 GB
    → tổng lưu trữ: 48 GB, không phải 120 GB

Và xoá snapshot trung gian KHÔNG làm hỏng snapshot sau:

Xoá snapshot 2
    → AWS tự giữ lại các khối mà snapshot 3 còn cần
    → snapshot 3 vẫn khôi phục được đầy đủ

Ba lưu ý về tính nhất quán của snapshot: | Mức nhất quán | Cách đạt được | |---|---| | Crash-consistent | chụp trực tiếp — như rút điện đột ngột | | File-system consistent | flush bộ đệm hệ điều hành trước khi chụp | | Application-consistent | tạm dừng ghi của ứng dụng, hoặc dùng VSS trên Windows |

Với database, hãy dùng một trong ba cách:

① Dừng ứng dụng ghi, flush, chụp, tiếp tục
② Dùng cơ chế backup của chính database (RDS snapshot, mysqldump)
③ Dùng AWS Backup với tuỳ chọn application-consistent (Windows VSS)

Ba cách tự động hoá snapshot: | Cách | Đặc điểm | |---|---| | Data Lifecycle Manager (DLM) | dựng sẵn, theo thẻ, tự xoá snapshot cũ — MIỄN PHÍ | | AWS Backup | quản lý tập trung nhiều dịch vụ, có vault lock | | EventBridge + Lambda | tự viết, linh hoạt nhất |

DLM là lựa chọn đúng cho phần lớn trường hợp:

aws dlm create-lifecycle-policy   --description "Snapshot hang ngay luc 12h dem"   --state ENABLED --execution-role-arn <arn>   --policy-details '{
    "ResourceTypes": ["VOLUME"],
    "TargetTags": [{"Key": "SaoLuu", "Value": "hang-ngay"}],
    "Schedules": [{
      "Name": "hang-ngay",
      "CreateRule": {"Interval": 24, "IntervalUnit": "HOURS", "Times": ["00:00"]},
      "RetentionRule": {"Count": 7}}]}'

RetentionRule tự xoá snapshot cũ — nếu không, snapshot tích tụ và chi phí tăng đều đặn.

Ba đặc điểm khác của snapshot: | Đặc điểm | Chi tiết | |---|---| | Phạm vi Region | sao chép sang Region khác được | | Chia sẻ được với tài khoản khác | hoặc công khai | | Volume tạo từ snapshot mã hoá thì tự mã hoá | tính mã hoá được kế thừa |

Và một hành vi cần biết khi khôi phục: "lazy loading".

Tạo volume mới từ snapshot
    → volume dùng được NGAY
    → nhưng dữ liệu được nạp DẦN từ S3 khi được đọc lần đầu
    → các lần đọc đầu tiên CHẬM hơn bình thường

Muốn tránh, dùng Fast Snapshot Restore (FSR):

aws ec2 enable-fast-snapshot-restores   --availability-zones ap-southeast-1a   --source-snapshot-ids snap-0abc123

FSR khiến volume đạt hiệu năng đầy đủ ngay lập tức — nhưng nó tính phí theo giờ, nên chỉ bật cho snapshot thực sự cần khôi phục nhanh.

Ba lưu ý về chi phí snapshot: | Lưu ý | Chi tiết | |---|---| | Tính theo dữ liệu THAY ĐỔI, không phải kích thước volume | nhờ tính tăng dần | | Snapshot tích tụ âm thầm | đặt retention rule ngay từ đầu | | Snapshot mồ côi sau khi xoá volume | vẫn tính tiền cho tới khi bạn xoá |

Và một lời khuyên vận hành: hãy thử khôi phục snapshot định kỳ. Một chính sách sao lưu chưa từng được kiểm chứng chỉ là giả định — và thời điểm phát hiện snapshot không dùng được không nên là lúc đang có sự cố thật.

Đáp án

B — Amazon SQS đã tự động xoá các thông điệp tồn tại trong hàng đợi quá thời hạn giữ tối đa.

Vì sao đúng

Đề cho hai con số, và mâu thuẫn giữa chúng là nguyên nhân:

Ứng dụng xử lý hàng đợi MỖI TUẦN (7 ngày)
Hàng đợi dùng CẤU HÌNH MẶC ĐỊNH
    ↓
MessageRetentionPeriod mặc định = 4 NGÀY
    ↓
Thông điệp tồn quá 4 ngày → SQS TỰ XOÁ
    → tới ngày thứ 7 khi ứng dụng chạy, thông điệp đã biến mất

Và đó là hành vi được thiết kế, không phải lỗi:

SQS không giữ thông điệp vô hạn
    → mỗi thông điệp có "hạn sử dụng"
    → hết hạn thì bị xoá tự động, không báo trước

Cách sửa — tăng thời hạn giữ:

aws sqs set-queue-attributes --queue-url <url>   --attributes MessageRetentionPeriod=1209600

1.209.600 giây = 14 ngày, mức tối đa của SQS — đủ cho chu kỳ xử lý hằng tuần với biên độ an toàn.

Nhưng cách sửa TỐT HƠN là xem lại kiến trúc:

Xử lý mỗi tuần một lần nghĩa là:
    → thông điệp nằm chờ tới 7 ngày
    → dữ liệu cũ tới một tuần mới được xử lý
    → và chỉ cần một tuần trễ hạn là mất dữ liệu
        ↓
Hàng đợi vốn dùng để TÁCH RỜI và làm phẳng tải,
không phải để LƯU TRỮ dữ liệu dài hạn

Nếu cần giữ lâu, hãy đẩy thông điệp sang S3 hoặc DynamoDB rồi xử lý theo lịch.

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

• **C. Hàng đợi đang dùng short polling — đây là phương án gần nhất vì đúng là mặc định của SQS, nhưng short polling chỉ ảnh hưởng tới việc một lời gọi ReceiveMessage có thể trả về rỗng dù hàng đợi có thông điệp. Gọi lại vài lần là lấy được hết. Nó không làm mất thông điệp.
• **A. Ứng dụng được cấu hình long polling — long polling không gây mất thông điệp, nó chỉ khiến lời gọi chờ tới 20 giây trước khi trả về. Và nó là cấu hình tốt, nên khuyến khích chứ không phải nguyên nhân lỗi.
• **D. Thiếu quyền trong SQS — triệu chứng sẽ khác hẳn: thiếu quyền thì ứng dụng nhận lỗi AccessDenied rõ ràng và KHÔNG xử lý được thông điệp NÀO, chứ không phải "không xử lý được hết".

Ghi nhớ

Bốn tham số thời gian của SQS — bảng cần thuộc: | Tham số | Mặc định | Khoảng | Việc | |---|---|---|---| | MessageRetentionPeriod | 4 ngày | 1 phút – 14 ngày | thông điệp tồn tại bao lâu ← câu này | | VisibilityTimeout | 30 giây | 0 – 12 giờ | thời gian ẩn sau khi được nhận | | ReceiveMessageWaitTimeSeconds | 0 (short polling) | 0 – 20 giây | long polling | | DelaySeconds | 0 | 0 – 15 phút | hoãn thông điệp mới |

Con số "4 ngày" là mặc định cần nhớ — nó là nguyên nhân của rất nhiều sự cố mất thông điệp âm thầm.

Short polling và long polling: | | Short polling (mặc định) | Long polling | |---|---|---| | Hàng đợi rỗng | trả về NGAY, kết quả rỗng | CHỜ tới khi có thông điệp | | Cách hoạt động | hỏi một TẬP CON máy chủ SQS | hỏi mọi máy chủ | | Có thể trả rỗng dù có thông điệp | ✅ có thể | ❌ | | Chi phí | cao — nhiều request rỗng | thấp |

Long polling nên bật cho mọi hàng đợi:

aws sqs set-queue-attributes --queue-url <url>   --attributes ReceiveMessageWaitTimeSeconds=20

Nó vừa rẻ hơn vừa giảm độ trễ nhận thông điệp.

Ba metric cần đặt alarm — có thể phát hiện vấn đề này sớm: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | thông điệp cũ nhất bao nhiêu giây — báo động khi tiến gần retention period | | ApproximateNumberOfMessagesVisible | hàng đợi đang tích tụ | | NumberOfMessagesDeleted | so với số gửi vào để phát hiện mất mát |

ApproximateAgeOfOldestMessage là metric quan trọng nhất cho tình huống này:

aws cloudwatch put-metric-alarm --alarm-name thong-diep-sap-het-han   --metric-name ApproximateAgeOfOldestMessage --namespace AWS/SQS   --statistic Maximum --period 3600 --threshold 259200   --comparison-operator GreaterThanThreshold --evaluation-periods 1   --dimensions Name=QueueName,Value=hang-doi-xu-ly   --alarm-actions <arn-sns>

259.200 giây = 3 ngày — cảnh báo trước một ngày so với hạn 4 ngày.

Ba mẫu kiến trúc thay thế cho việc xử lý theo lô định kỳ: | Mẫu | Chi tiết | |---|---| | Xử lý LIÊN TỤC với ASG theo độ sâu hàng đợi | hàng đợi không bao giờ tích tụ lâu | | Lambda với event source mapping | tự động, không cần máy chủ | | Đẩy sang S3 rồi xử lý theo lô | phù hợp khi thật sự cần chu kỳ dài |

Nếu vẫn muốn giữ lịch hằng tuần, mẫu thứ ba là kiến trúc đúng:

Producer → SQS → Lambda (chạy liên tục) → ghi vào S3
                                              ↓
                                    Job hằng tuần đọc S3 và xử lý

S3 giữ dữ liệu vô hạn — không có nguy cơ mất do hết hạn.

Và Kinesis Data Streams là lựa chọn khác nếu cần phát lại: | | SQS | Kinesis Data Streams | |---|---|---| | Thời gian giữ tối đa | 14 ngày | 365 ngày | | Phát lại (replay) | ❌ xoá sau khi xử lý | ✅ | | Nhiều consumer độc lập | ❌ | ✅ |

Ba lưu ý khác về SQS: | Lưu ý | Chi tiết | |---|---| | Dead-letter queue cũng có retention riêng | đặt dài hơn hàng đợi chính | | Kích thước thông điệp tối đa 256 KB | lớn hơn thì dùng SQS Extended Client với S3 | | Giới hạn thông điệp đang bay | 120.000 (standard), 20.000 (FIFO) |

Dòng đầu là chi tiết dễ bỏ sót: nếu DLQ có retention 4 ngày, thông điệp hỏng cũng biến mất trước khi ai kịp điều tra. Đặt DLQ ở mức 14 ngày là thực hành tốt.

Và một lời khuyên chung: đừng dùng giá trị mặc định cho hàng đợi sản xuất. Ba tham số nên khai tường minh ngay từ đầu là MessageRetentionPeriod, VisibilityTimeout (khớp thời gian xử lý), và ReceiveMessageWaitTimeSeconds (bật long polling) — cùng với một dead-letter queue.

Đáp án

A — Thay đổi cooldown period của Auto Scaling group và đặt ngưỡng CloudWatch metric CAO HƠN.

Vì sao đúng

Đề mô tả triệu chứng rõ: ứng dụng co giãn lên xuống nhiều lần trong một giờ — hiện tượng gọi là thrashing (dao động).

Vì sao dao động vừa tốn tiền vừa hại:

Mỗi lần mở rộng:
    → khởi chạy instance mới
    → EC2 tính phí TỐI THIỂU 60 GIÂY
    → instance mất vài phút mới thực sự phục vụ được
        ↓
Thu hẹp ngay sau đó:
    → vừa trả tiền cho máy chưa kịp làm gì
    → và lần mở rộng tiếp theo lại bắt đầu từ đầu

Hai thay đổi trong đáp án giải quyết hai nguyên nhân khác nhau: | Thay đổi | Chống lại | |---|---| | Tăng cooldown period | phản ứng liên tiếp quá nhanh, chưa kịp thấy hiệu quả của lần trước | | Nâng ngưỡng metric | kích hoạt vì đột biến ngắn hạn không đáng kể |

Cooldown period giải quyết vấn đề "chưa kịp ổn định":

Không có cooldown đủ dài:
    ASG thêm máy → máy mới chưa khởi động xong
        → metric vẫn cao → ASG thêm tiếp
        → mở rộng QUÁ MỨC → rồi thu hẹp ồ ạt

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-ung-dung   --default-cooldown 600

Và nâng ngưỡng lọc bớt nhiễu:

Ngưỡng CPU 40% → mọi đợt tăng nhẹ đều kích hoạt
Ngưỡng CPU 70% → chỉ tải thật sự cao mới kích hoạt

Và cách này giữ được tính đàn hồi — đúng yêu cầu "optimize cost WHILE PRESERVING ELASTICITY": hệ thống vẫn co giãn, chỉ là không phản ứng thái quá.

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

• **C. Tăng số instance nền của Auto Scaling group — đây là phương án gần nhất và giảm được dao động, nhưng nó đi ngược mục tiêu tiết kiệm chi phí: giữ nhiều máy chạy liên tục hơn nghĩa là trả tiền nhiều hơn. Và nó giảm tính đàn hồi — đúng thứ đề muốn bảo toàn.
• **B. Nâng cấp loại instance trong launch template — không giải quyết nguyên nhân: máy mạnh hơn làm metric CPU thấp hơn ở cùng mức tải, nhưng ASG vẫn dao động quanh ngưỡng nếu ngưỡng và cooldown không đổi. Và instance lớn hơn thì đắt hơn.
• **D. Thêm provisioned IOPS cho instance — hoàn toàn không liên quan: IOPS là hiệu năng đĩa. Nó không ảnh hưởng tới việc ASG quyết định thêm hay bớt máy.

Ghi nhớ

Ba nguyên nhân gây dao động co giãn (thrashing): | Nguyên nhân | Cách sửa | |---|---| | Cooldown quá ngắn | tăng lên 300–600 giây | | Ngưỡng quá nhạy | nâng ngưỡng, hoặc dùng target tracking | | Khoảng cách giữa ngưỡng mở rộng và thu hẹp quá hẹp | nới rộng ra |

Dòng cuối đáng chú ý:

Mở rộng khi CPU > 50%, thu hẹp khi CPU < 45%
    → khoảng đệm chỉ 5 điểm → dao động liên tục
        ↓
Mở rộng khi CPU > 70%, thu hẹp khi CPU < 30%
    → khoảng đệm 40 điểm → ổn định hơn nhiều

Ba cấu hình thời gian của Auto Scaling — đừng nhầm: | Cấu hình | Việc | Áp cho | |---|---|---| | Cooldown period | thời gian chờ giữa hai hoạt động co giãn | simple scaling | | Instance warmup | thời gian chờ instance mới sẵn sàng trước khi tính vào metric | target tracking, step scaling | | Health check grace period | thời gian bỏ qua health check cho instance mới | mọi loại |

Với target tracking và step scaling, EstimatedInstanceWarmup mới là tham số đúng:

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-ung-dung   --policy-name giu-cpu-70 --policy-type TargetTrackingScaling   --estimated-instance-warmup 300   --target-tracking-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"}}'

Và target tracking vốn đã chống dao động tốt hơn simple scaling: | | Simple scaling | Target tracking | |---|---|---| | Cơ chế | ngưỡng cứng + cooldown | giữ metric quanh một giá trị | | Chống dao động | kém — phụ thuộc cooldown | ✅ tự cân bằng, thu hẹp thận trọng | | Cấu hình | nhiều tham số | một con số |

AWS khuyến nghị target tracking cho hầu hết trường hợp — nó tự tạo và quản lý alarm, và mặc định thu hẹp thận trọng hơn mở rộng.

Ba nguyên tắc để co giãn ổn định: | Nguyên tắc | Lý do | |---|---| | Mở rộng NHANH, thu hẹp CHẬM | mở rộng muộn gây gián đoạn; thu hẹp muộn chỉ tốn ít tiền | | Chọn metric phản ánh đúng tải | | | Đặt MinSize đủ để chịu tải nền | tránh co giãn liên tục quanh mức thấp |

Chọn metric phù hợp: | Metric | Phù hợp | |---|---| | ASGAverageCPUUtilization | ứng dụng nặng tính toán | | ALBRequestCountPerTarget | thường phản ánh tải thật tốt hơn CPU | | Độ sâu hàng đợi SQS | ứng dụng xử lý theo hàng đợi | | Metric bộ nhớ tuỳ chỉnh | cần CloudWatch agent |

ALBRequestCountPerTarget ổn định hơn CPU — số request là chỉ báo trực tiếp của nhu cầu, còn CPU dao động theo cả những việc nền không liên quan.

Và với tải có mẫu lặp lại, predictive scaling giải quyết tận gốc:

Predictive scaling học từ 14 ngày dữ liệu
    → dự báo tải cho 48 giờ tới
    → mở rộng TRƯỚC khi tải tới
    → không còn phản ứng giật cục theo metric

Ba lợi ích khác của việc giảm dao động: | Lợi ích | Chi tiết | |---|---| | Ít gián đoạn phiên người dùng | mỗi lần thu hẹp là một số kết nối bị ngắt | | Cache của ứng dụng ổn định hơn | máy mới luôn có cache lạnh | | Log và metric dễ đọc hơn | ít nhiễu từ việc máy liên tục sinh ra và biến mất |

Và nếu vẫn phải thu hẹp thường xuyên, hãy đặt deregistration_delay hợp lý:

aws elbv2 modify-target-group-attributes --target-group-arn <arn>   --attributes Key=deregistration_delay.timeout_seconds,Value=30

Nó cho phép instance xử nốt request đang dở trước khi bị chấm dứt — tránh lỗi 502 với người dùng.

Và một cách xác nhận vấn đề trước khi sửa: xem Activity history của Auto Scaling group. Nó liệt kê mọi lần co giãn kèm lý do và thời điểm — nhìn vào đó là thấy ngay hệ thống đang dao động quanh ngưỡng nào và với tần suất bao nhiêu.

Đáp án

A và C.

• A — Dùng khoá của chính bạn trong AWS KMS (customer managed key)
• C — Dùng khoá do Amazon quản lý trong AWS KMS (AWS managed key)

Vì sao đúng

Câu hỏi kiểm tra một điều đơn giản: EBS mã hoá bằng dịch vụ nào, và câu trả lời là AWS KMS — với hai loại khoá.

Hai lựa chọn khoá cho EBS: | Loại khoá | Đặc điểm | |---|---| | AWS managed key (aws/ebs) | AWS tạo và quản lý, MIỄN PHÍ lưu khoá ← C | | Customer managed key | BẠN tạo và kiểm soát policy, ~1 USD/tháng ← A |

Cả hai đều nằm trong KMS — khác biệt chỉ ở mức kiểm soát.

Cách mã hoá EBS hoạt động (mã hoá phong bì):

① KMS sinh một DATA KEY
② Data key mã hoá dữ liệu trên volume (làm tại tầng hạ tầng, rất nhanh)
③ CMK trong KMS mã hoá chính data key đó
④ Data key đã mã hoá lưu kèm metadata của volume
    → khoá gốc KHÔNG BAO GIỜ rời khỏi KMS

Và mã hoá bao trùm toàn bộ vòng đời:

✓ Dữ liệu nằm trên volume
✓ Dữ liệu di chuyển giữa volume và instance
✓ Mọi snapshot tạo từ volume
✓ Mọi volume tạo từ snapshot đó

Với yêu cầu HIPAA như đề mô tả, customer managed key thường là lựa chọn đúng:

Customer managed key cho:
    ✓ key policy riêng — kiểm soát ai dùng được khoá
    ✓ xoay vòng tự động hằng năm
    ✓ audit trail chi tiết trong CloudTrail
    ✓ vô hiệu hoá hoặc lên lịch xoá khoá được

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

• **E. Dùng mật khẩu lưu trong CloudHSM — đây là phương án gần nhất vì CloudHSM cũng là dịch vụ quản lý khoá, nhưng EBS không tích hợp trực tiếp với CloudHSM: nó dùng KMS. (Có thể dùng KMS custom key store backed by CloudHSM, nhưng đó vẫn là đi qua KMS — và "mật khẩu" không phải cơ chế mã hoá EBS.)
• **B. Dùng S3 Server-Side Encryption — sai dịch vụ: SSE là cơ chế mã hoá của S3, không áp cho EBS volume.
• **D. Dùng S3 Client-Side Encryption — cùng lý do: đó là mã hoá phía client cho object S3.
• **F. Dùng chứng chỉ SSL từ ACM — nhầm loại mã hoá: chứng chỉ TLS bảo vệ dữ liệu khi truyền qua mạng, không mã hoá dữ liệu khi lưu trữ.

Ghi nhớ

Ba loại khoá trong AWS KMS: | Loại | Chi phí | Kiểm soát | |---|---|---| | AWS managed key | miễn phí lưu | không đổi được policy, xoay hằng năm tự động | | Customer managed key | ~1 USD/tháng | đầy đủ: policy, xoay vòng, vô hiệu hoá | | AWS owned key | miễn phí | AWS dùng nội bộ, bạn không thấy |

Khi nào cần customer managed key: | Trường hợp | Lý do | |---|---| | Yêu cầu tuân thủ (HIPAA, PCI-DSS) | cần kiểm soát và audit được khoá | | Chia sẻ snapshot mã hoá với tài khoản khác | khoá aws/ebs KHÔNG chia sẻ được | | Cần vô hiệu hoá khoá khẩn cấp | khoá AWS managed không tắt được | | Cần lịch xoay vòng riêng | tuỳ chỉnh được |

Dòng thứ hai là ràng buộc kỹ thuật cứng — nhiều người chỉ phát hiện khi cần chia sẻ snapshot mới biết.

Những gì được mã hoá khi bật mã hoá EBS: | Đối tượng | Mã hoá | |---|---| | Dữ liệu trên volume | ✅ | | Dữ liệu giữa volume và instance | ✅ (nhiều người không biết) | | Snapshot | ✅ tự động | | Volume tạo từ snapshot mã hoá | ✅ tự động | | AMI tạo từ volume mã hoá | ✅ |

Và một cạm bẫy: KHÔNG mã hoá được volume đang tồn tại trực tiếp.

Quy trình chuyển đổi:
    ① Chụp snapshot của volume chưa mã hoá
    ② Sao chép snapshot với --encrypted
    ③ Tạo volume mới từ snapshot đã mã hoá
    ④ Tháo volume cũ, gắn volume mới

aws ec2 copy-snapshot --source-snapshot-id snap-0abc123   --source-region ap-southeast-1 --encrypted --kms-key-id alias/khoa-y-te

Cách tránh vấn đề này hoàn toàn: bật mã hoá MẶC ĐỊNH cho Region.

aws ec2 enable-ebs-encryption-by-default --region ap-southeast-1
aws ec2 modify-ebs-default-kms-key-id --kms-key-id alias/khoa-y-te

Mọi volume mới tự động mã hoá bằng khoá bạn chọn — không ai quên được nữa. Đây là cấu hình nên bật cho mọi tài khoản xử lý dữ liệu nhạy cảm.

Các dịch vụ AWS dùng KMS để mã hoá at rest: | Dịch vụ | Ghi chú | |---|---| | EBS | ← câu này | | S3 | SSE-KMS | | RDS, Aurora, DocumentDB, Neptune | bật LÚC TẠO, không bật sau được | | DynamoDB | mã hoá mặc định | | EFS, FSx | bật lúc tạo | | Lambda | biến môi trường | | Secrets Manager, Parameter Store | SecureString |

Dòng RDS đáng nhớ: giống EBS, mã hoá phải bật lúc tạo — muốn mã hoá cluster chưa mã hoá thì phải chụp snapshot, sao chép có mã hoá, rồi khôi phục.

Ba yêu cầu tuân thủ HIPAA trên AWS: | Yêu cầu | Chi tiết | |---|---| | Ký BAA với AWS | bắt buộc về pháp lý | | Chỉ dùng dịch vụ đủ điều kiện HIPAA | EC2, EBS, S3, RDS đều nằm trong danh sách | | Mã hoá at rest VÀ in transit | KMS + TLS | | Audit trail đầy đủ | CloudTrail |

Và key policy là chỗ hay gây lỗi AccessDenied:

Quyền dùng khoá KMS = CẢ key policy LẪN IAM policy
    → cấp kms:Decrypt trong IAM là CHƯA ĐỦ
    → key policy cũng phải cho phép principal đó

Ba lưu ý về Dedicated Instance mà đề nhắc tới: | Lưu ý | Chi tiết | |---|---| | Đảm bảo phần cứng không chia sẻ với khách hàng khác | phục vụ yêu cầu tuân thủ | | KHÔNG liên quan tới mã hoá | hai biện pháp bổ sung nhau | | Đắt hơn shared tenancy | cân nhắc xem có thực sự cần |

Và một lưu ý về hiệu năng: mã hoá EBS gần như không ảnh hưởng IOPS hay độ trễ — việc mã hoá diễn ra ở tầng hạ tầng của AWS với phần cứng chuyên dụng. Không có lý do về hiệu năng để không bật mã hoá.

Đáp án

A — Dùng ECS làm dịch vụ quản lý container; thiết lập kết hợp Reserved Instance cho công việc quan trọng và Spot Instance cho công việc không thiết yếu.

Vì sao đúng

Đề mô tả hai loại công việc có yêu cầu khác nhau, và cách tiết kiệm nhất là dùng mô hình mua phù hợp cho từng loại: | Loại công việc | Mô hình mua | Lý do | |---|---|---| | Quan trọng (mission-critical) | Reserved Instance | cần đảm bảo dung lượng, không được gián đoạn | | Không thiết yếu (non-essential) | Spot Instance | chịu được gián đoạn, rẻ hơn tới 90% |

Vì sao không dùng Spot cho công việc quan trọng:

Spot có thể bị THU HỒI bất cứ lúc nào (báo trước 2 phút)
    → công việc quan trọng bị ngắt giữa chừng
    → không chấp nhận được

Và vì sao không dùng Reserved cho công việc không thiết yếu:

Reserved Instance = cam kết trả tiền 1 hoặc 3 năm
    → trả giá cao cho tính đảm bảo mà workload này KHÔNG CẦN
    → Spot rẻ hơn 5–9 lần cho cùng công việc

Chênh lệch chi phí:

On-Demand:          100%
Reserved (3 năm):   ~28–40%
Spot:               ~10–30%

Triển khai bằng capacity provider của ECS:

{"capacityProviders": ["FARGATE", "cp-reserved", "cp-spot"],
 "defaultCapacityProviderStrategy": [
   {"capacityProvider": "cp-reserved", "base": 2, "weight": 1},
   {"capacityProvider": "cp-spot", "weight": 4}]}

base đảm bảo luôn có 2 task chạy trên dung lượng ổn định, phần vượt trên đó dùng Spot.

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

• **D. Dùng Spot cho CẢ HAI loại — đây là phương án gần nhất về mặt rẻ nhất, nhưng nó đặt công việc quan trọng vào rủi ro: Spot bị thu hồi bất cứ lúc nào. Với "mission-critical data", đó là rủi ro không chấp nhận được.
• **B. Dùng Reserved cho cả hai — an toàn nhưng lãng phí: trả giá cao cho phần công việc không cần đảm bảo gì. Và Reserved đòi cam kết dài hạn cho khối lượng có thể biến động.
• **C. Dùng On-Demand cho cả hai — đắt nhất trong ba phương án khả thi: không tận dụng được giảm giá nào. On-Demand chỉ hợp lý cho tải ngắn hạn, không đoán trước.

Ghi nhớ

Năm mô hình mua EC2 — bảng cần thuộc: | Mô hình | Giảm giá | Cam kết | Rủi ro gián đoạn | |---|---|---|---| | On-Demand | 0% | không | không | | Savings Plans | tới 72% | 1 hoặc 3 năm (theo USD/giờ) | không | | Reserved Instances | tới 72% | 1 hoặc 3 năm (theo cấu hình) | không | | Spot | tới 90% | không | ✅ bị thu hồi | | Dedicated Host | — | tuỳ chọn | không |

Từ khoá nhận diện trong đề thi:

"fault-tolerant", "can be interrupted", "batch", "non-critical", "flexible" → Spot "steady state", "predictable", "mission-critical", "1-year commitment" → Reserved / Savings Plan "unpredictable", "short-term", "cannot be interrupted" → On-Demand

Và Savings Plan thường tốt hơn Reserved Instance hiện nay: | | Reserved Instance | Savings Plan | |---|---|---| | Cam kết theo | cấu hình instance cụ thể | số USD/giờ | | Áp cho Fargate và Lambda | ❌ | ✅ (Compute Savings Plan) | | Tự áp cho tài nguyên phù hợp | cần khớp cấu hình | ✅ tự động | | Bán lại | ✅ (Standard RI) | ❌ |

Compute Savings Plan là lựa chọn mặc định tốt — nó tự áp cho EC2 ở mọi Region, mọi loại instance, cộng cả Fargate và Lambda.

Ba kiến trúc làm cho Spot an toàn: | Kiến trúc | Cơ chế | |---|---| | Hàng đợi (SQS) + worker | thông điệp quay lại queue khi worker chết | | Checkpoint định kỳ | chạy lại từ điểm gần nhất | | Công việc chia nhỏ, độc lập | mất một phần không ảnh hưởng phần khác |

Và xử lý cảnh báo thu hồi Spot trên ECS:

ECS tự động:
    → nhận cảnh báo 2 phút
    → đưa instance vào trạng thái DRAINING
    → chuyển task sang instance khác
    → task mới khởi động trước khi task cũ dừng

Đây là lý do ECS quản lý Spot tốt hơn tự viết — nó lo phần thoát êm.

Ba chiến lược phân bổ Spot: | Chiến lược | Đặc điểm | |---|---| | capacity-optimized | chọn pool dư dung lượng nhất — ÍT bị thu hồi nhất | | lowest-price | rẻ nhất nhưng dễ bị thu hồi hơn | | diversified | trải đều nhiều pool |

capacity-optimized là khuyến nghị của AWS — chênh lệch giá nhỏ nhưng độ ổn định cao hơn hẳn.

Ba cách giảm rủi ro Spot: | Cách | Lợi ích | |---|---| | Dùng NHIỀU loại instance và NHIỀU AZ | giảm mạnh khả năng bị thu hồi đồng loạt | | Mixed instance policy với base On-Demand | luôn có nền ổn định | | Đặt MaxSize hợp lý | tránh mở rộng ngoài tầm kiểm soát |

Ba capacity provider của ECS: | Provider | Đặc điểm | |---|---| | FARGATE | không quản lý máy chủ | | FARGATE_SPOT | Fargate với giá Spot — rẻ hơn tới 70% | | Auto Scaling group | dựa trên EC2, tự cấu hình mix |

FARGATE_SPOT đáng cân nhắc cho công việc không thiết yếu — nó cho cả tiết kiệm của Spot lẫn sự đơn giản của Fargate, không phải quản lý instance nào.

Và một cấu hình phổ biến cho tình huống của đề:

{"capacityProviderStrategy": [
   {"capacityProvider": "FARGATE", "base": 1, "weight": 1},
   {"capacityProvider": "FARGATE_SPOT", "weight": 3}]}

Một task luôn chạy trên Fargate thường, ba phần tư phần vượt dùng Spot.

Ba lưu ý khi dùng ECS với EC2: | Lưu ý | Chi tiết | |---|---| | Task phải khai cpu và memory | ECS dùng để đặt task lên instance phù hợp | | Bật managed scaling của capacity provider | ECS tự điều chỉnh số instance | | Bật managed termination protection | ngăn ASG chấm dứt instance đang chạy task |

Và một lời khuyên về việc phân loại công việc: hãy gắn thẻ rõ ràng cho từng loại (MucDoQuanTrong = cao / thap) và dùng placement constraint của ECS để đảm bảo task quan trọng chỉ chạy trên instance ổn định. Nếu không, ECS có thể đặt nhầm task quan trọng lên máy Spot.