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

Đáp án

C — Bỏ NAT Gateway và dùng Gateway VPC endpoint để truy cập S3 bucket từ instance.

Vì sao đúng

Đề nêu hai điều kiện, và gateway endpoint đáp ứng cả hai một cách tối ưu: | Điều kiện | Cơ chế | |---|---| | GIẢM chi phí | gateway endpoint HOÀN TOÀN MIỄN PHÍ | | KHÔNG giảm dự phòng hay tính sẵn sàng | AWS quản lý, sẵn sàng cao dựng sẵn |

Chênh lệch chi phí là rất lớn:

NAT Gateway:
    ~0,045 USD/giờ            → ~32 USD/tháng chỉ để tồn tại
  + ~0,045 USD mỗi GB xử lý
        ↓
    Job xử lý 10 TB/tháng: 32 + 450 = ~482 USD/tháng

Gateway endpoint:
    0 USD

Và điều kiện "không giảm redundancy hay availability" loại bỏ NAT instance:

NAT Gateway:
    → AWS quản lý, tự chịu lỗi trong AZ
NAT instance:
    → MỘT máy ảo bạn tự quản lý
    → máy chết là mất kết nối
    → phải tự dựng cơ chế dự phòng

Gateway endpoint không có vấn đề đó:

Nó chỉ là một ROUTE trong route table
    → không có thành phần nào để hỏng
    → không có giới hạn băng thông
    → AWS lo hoàn toàn

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à nó AN TOÀN HƠN: lưu lượng không bao giờ rời khỏi mạng AWS.

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

• **A. Thay NAT Gateway bằng NAT instance trên loại instance burstable — đây là phương án gần nhất và thực sự rẻ hơn NAT gateway, nhưng nó vi phạm điều kiện "without imposing risks on redundancy or availability": NAT instance là một máy ảo đơn lẻ — nó chết là mất kết nối, và loại burstable còn có thể cạn tín dụng CPU khi tải cao rồi tụt hiệu năng.
• **D. Chuyển NAT Gateway sang loại EC2 nhỏ hơn — sai về mặt kỹ thuật: NAT Gateway là dịch vụ được quản lý, nó không có "loại instance" để chọn. Không có tham số nào như vậy.
• **B. Triển khai Transit Gateway để peering giữa instance và S3 bucket — sai công cụ: Transit Gateway kết nối các VPC và mạng tại chỗ với nhau. S3 không phải VPC, không peering với nó được. Và TGW còn tính phí attachment cộng phí xử lý dữ liệu.

Ghi nhớ

Hai loại VPC endpoint: | | Gateway endpoint | Interface endpoint | |---|---|---| | Dịch vụ | 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 | | Sẵn sàng cao | tự động, không có thành phần nào để hỏng | cần endpoint ở mỗi AZ | | Truy cập từ tại chỗ | ❌ | ✅ |

NAT Gateway và NAT instance: | | NAT Gateway | NAT instance | |---|---|---| | Quản lý | AWS lo hoàn toàn | bạn tự vá, tự giám sát | | Băng thông | tới 100 Gbps, tự mở rộng | theo loại instance | | Sẵn sàng cao | trong AZ | phải tự dựng | | Chi phí | cao hơn | có thể rẻ hơn với lưu lượng nhỏ | | Security group | không gắn được | gắn được |

NAT Gateway là khoản chi phí âm thầm phổ biến nhất trên AWS — và gateway endpoint cho S3 và DynamoDB là cách giảm nó hiệu quả nhất.

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

# Xem VPC Flow Logs để biết đích của lưu lượng còn lại
fields @timestamp, srcAddr, dstAddr, bytes
| filter dstAddr not like /^10\./
| stats sum(bytes) by dstAddr
| sort by sum desc

Các dịch vụ hay tốn tiền qua NAT — đều có interface endpoint: | Dịch vụ | Lý do lưu lượng lớn | |---|---| | ECR | kéo image container rất nặng | | CloudWatch Logs | log đẩy lên liên tục | | Systems Manager | và cần thiết nếu không có NAT | | Secrets Manager, KMS | nhỏ nhưng thường xuyên |

Với khối lượng lớn, phí interface endpoint vẫn rẻ hơn phí NAT nhiều.

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à endpoint policy là biện pháp bảo mật miễn phí đáng dùng:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:GetObject"],
  "Resource": ["arn:aws:s3:::kho-du-lieu-dau-vao/*"]}]}

Instance chỉ đọc được đúng bucket đó qua endpoint này — chống rò rỉ dữ liệu hiệu quả.

Ba cách khác giảm chi phí NAT Gateway: | Cách | Chi tiết | |---|---| | Gộp NAT Gateway nếu chấp nhận được | nhưng đánh đổi tính sẵn sàng theo AZ | | Kiểm tra có tiến trình nào tải lặp lại không | lỗi ứng dụng có thể tạo lưu lượng khổng lồ | | Dùng VPC endpoint cho mọi dịch vụ AWS dùng nhiều | |

Dòng đầu là đánh đổi cần cân nhắc kỹ: một NAT gateway dùng chung cho mọi AZ rẻ hơn, nhưng AZ chứa nó sập là mọi private subnet mất đường ra Internet. Và lưu lượng chéo AZ còn tính phí thêm.

Ba metric cần theo dõi cho NAT Gateway: | Metric | Ý nghĩa | |---|---| | BytesOutToDestination | lưu lượng ra Internet — tăng đột biến là dấu hiệu bất thường | | ErrorPortAllocation | cạn cổng, cần thêm NAT gateway | | PacketsDropCount | gói tin bị rơi |

Và một lời khuyên: sau khi tạo gateway endpoint, hãy kiểm chứng bằng cách xem hoá đơn NAT tháng sau. Nếu nó không giảm như mong đợi, gần như chắc chắn là quên gắn endpoint vào một route table nào đó — đó là lỗi triển khai phổ biến nhất.

Đáp án

C — Weighted routing policy.

Vì sao đúng

Đề nêu yêu cầu rất cụ thể: đặt một TỶ LỆ PHẦN TRĂM lưu lượng cụ thể cho mỗi instance — và đó chính xác là chức năng của weighted routing.

Cách weighted routing hoạt động:

Nhiều bản ghi CÙNG TÊN, CÙNG LOẠI, mỗi bản ghi một TRỌNG SỐ
    ↓
Route 53 trả về từng bản ghi theo tỷ lệ:
    tỷ lệ = trọng số của bản ghi / TỔNG trọng số

Ví dụ chia 70/30:

# Instance 1 — 70%
aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{
    "Name":"ung-dung.congty.com","Type":"A","TTL":60,
    "SetIdentifier":"instance-1","Weight":70,
    "ResourceRecords":[{"Value":"203.0.113.10"}]}}]}'

# Instance 2 — 30%
    ... "SetIdentifier":"instance-2","Weight":30,
        "ResourceRecords":[{"Value":"203.0.113.20"}]

Trọng số nhận giá trị 0–255, và tỷ lệ tính theo tổng:

Weight 1 và 1   → 50% / 50%
Weight 70 và 30 → 70% / 30%
Weight 0        → KHÔNG nhận lưu lượng nào (dùng để rút một máy ra)

Và weighted routing rất hữu ích cho hai việc: | Việc | Cách dùng | |---|---| | Triển khai canary | phiên bản mới nhận 5%, quan sát, rồi tăng dần | | A/B testing | chia lưu lượng giữa hai phiên bản để so sánh | | Chuyển đổi dần | như bài toán di chuyển lên đám mây |

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

• **B. Failover routing — đây là phương án gần nhất về mặt cũng là chính sách nhiều bản ghi, nhưng nó không chia tỷ lệ: failover là mô hình primary/secondary — toàn bộ lưu lượng đi tới primary, secondary chỉ nhận khi primary hỏng. Đó là active-passive, không phải chia phần trăm.
• **A. Latency-based routing — định tuyến theo ĐỘ TRỄ MẠNG, không theo tỷ lệ bạn đặt: Route 53 tự chọn Region cho độ trễ thấp nhất với từng người dùng. Bạn không kiểm soát được tỷ lệ.
• **D. Geolocation routing — định tuyến theo VỊ TRÍ ĐỊA LÝ của người dùng: người ở châu Á đi tới endpoint này, người ở châu Âu đi tới endpoint kia. Cũng không phải chia theo tỷ lệ.

Ghi nhớ

Bảy chính sách định tuyến của Route 53 — bảng cần thuộc: | Chính sách | Quyết định theo | Dùng cho | |---|---|---| | Simple | không có logic | một endpoint duy nhất | | Weighted | TỶ LỆ bạn đặt | A/B test, canary, chia tải ← câu này | | Latency-based | độ trễ mạng thực tế | ứng dụng đa Region | | Failover | health check — primary/secondary | phục hồi thảm hoạ | | Geolocation | vị trí người dùng | nội dung theo khu vực, tuân thủ pháp lý | | Geoproximity | khoảng cách + bias điều chỉnh được | dịch chuyển lưu lượng theo vùng | | Multivalue answer | trả về tới 8 bản ghi lành mạnh | cân bằng tải đơn giản | | IP-based | dải IP của người dùng | tối ưu theo nhà mạng |

Từ khoá nhận diện:

"specific percentage", "70/30", "A/B testing", "canary" → Weighted "lowest latency", "closest region" → Latency-based "primary and secondary", "disaster recovery" → Failover "users in Europe see X" → Geolocation

Ba yêu cầu chung cho mọi chính sách nhiều bản ghi: | Yêu cầu | Chi tiết | |---|---| | Cùng TÊN và cùng LOẠI bản ghi | ví dụ đều là A record cho ung-dung.congty.com | | SetIdentifier khác nhau | bắt buộc — để phân biệt các bản ghi | | Nên có health check | Route 53 loại bản ghi hỏng khỏi câu trả lời |

Và health check biến weighted routing thành cơ chế chịu lỗi:

Instance 1 (weight 50) hỏng
    → health check thất bại
    → Route 53 NGỪNG trả về bản ghi đó
    → 100% lưu lượng đi tới instance 2

Không có health check thì Route 53 vẫn gửi 50% lưu lượng tới máy đã chết.

Ba lưu ý quan trọng khi dùng Route 53 thay ELB: | Lưu ý | Chi tiết | |---|---| | DNS được CACHE ở client | tỷ lệ thực tế lệch so với trọng số đã đặt | | Không phân phối theo từng REQUEST | mỗi client dính với một IP trong suốt TTL | | Không biết tình trạng tải của máy | ELB biết, DNS thì không |

Dòng đầu là hạn chế cốt lõi:

Trọng số 50/50 với TTL 300 giây
    → một client phân giải một lần rồi dùng kết quả đó 5 phút
    → với ít client, tỷ lệ thực tế có thể lệch xa 50/50
    → cần nhiều client thì luật số lớn mới cho đúng tỷ lệ

Vì vậy với ứng dụng thật, ELB thường tốt hơn Route 53 cho việc cân bằng tải: | | ELB | Route 53 weighted | |---|---|---| | Phân phối theo | từng REQUEST | mỗi lần phân giải DNS | | Biết tình trạng target | ✅ health check liên tục | health check độc lập | | Chuyển đổi khi máy hỏng | tức thì | phụ thuộc TTL | | Chi phí | phí giờ + LCU | phí truy vấn DNS | | Đa Region | ❌ | ✅ |

Route 53 weighted phù hợp khi cần chia lưu lượng giữa các Region hoặc giữa AWS và hệ thống bên ngoài — những chỗ mà một ELB không vươn tới được.

Ba cấu hình TTL cần cân nhắc: | Tình huống | TTL đề xuất | |---|---| | Đang chuyển đổi hoặc canary | 60 giây hoặc thấp hơn | | Bản ghi ổn định | 300–3600 giây | | Trước khi thay đổi lớn | hạ TTL vài ngày TRƯỚC, rồi mới đổi |

Dòng cuối là thực hành quan trọng: hạ TTL trước giúp thay đổi có hiệu lực nhanh; nếu đổi ngay khi TTL còn cao, một phần người dùng vẫn dùng bản ghi cũ rất lâu.

Và một lưu ý về weight bằng 0: đặt trọng số 0 cho một bản ghi khiến nó không nhận lưu lượng nào nhưng vẫn tồn tại. Đây là cách rút một máy ra khỏi vòng phục vụ mà không phải xoá bản ghi — tiện khi cần bảo trì rồi đưa lại vào.

Đáp án

A — Bật Enhanced Networking với Elastic Network Adapter (ENA) trên các EC2 instance Windows.

Vì sao đúng

Đề cho một chi tiết quyết định mà dễ bỏ sót: cụm chạy Windows Server.

Và đó là điều kiện loại bỏ EFA:

Elastic Fabric Adapter (EFA):
    → CHỈ hỗ trợ LINUX
    → tính năng OS-bypass phụ thuộc vào nhân Linux
    → KHÔNG dùng được trên Windows

Nên với Windows, ENA là lựa chọn duy nhất trong họ Enhanced Networking:

ENA cung cấp:
    ✓ Băng thông cao (tới 100 Gbps tuỳ loại instance)
    ✓ Packet per second (PPS) cao hơn
    ✓ Độ trễ giữa các instance thấp và NHẤT QUÁN
    ✓ Giảm nhiễu giữa các instance trên cùng máy chủ

Và ba lợi ích đó khớp chính xác với ba yêu cầu trong đề: | Yêu cầu trong đề | ENA đáp ứng | |---|---| | "higher bandwidth" | ✅ | | "higher packet per second (PPS) performance" | ✅ | | "consistently lower inter-instance latencies" | ✅ |

Và ENA MIỄN PHÍ — không tính thêm phí gì, đúng yêu cầu "cost-effective".

Kiểm tra và bật:

aws ec2 describe-instances --instance-ids i-0abc123   --query 'Reservations[].Instances[].EnaSupport'

aws ec2 modify-instance-attribute --instance-id i-0abc123 --ena-support

(Phải dừng instance trước khi bật.)

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

• **B. Bật Enhanced Networking với Elastic Fabric Adapter (EFA) — đây là phương án gần nhất và EFA thực sự mạnh hơn ENA cho HPC, nhưng nó KHÔNG hỗ trợ Windows. Đây là điểm phân biệt của câu hỏi, và cũng là chi tiết hay bị bỏ sót.
• **C. Dùng Intel 82599 Virtual Function (VF) — là thế hệ Enhanced Networking CŨ: nó chỉ hỗ trợ các loại instance đời trước (C3, R3, I2) với băng thông tối đa 10 Gbps. Instance t3a trong đề dùng ENA, không dùng VF.
• **D. Dùng AWS ParallelCluster — là công cụ QUẢN LÝ cụm, không phải công nghệ mạng: ParallelCluster tự động hoá việc dựng và vận hành cụm HPC (bộ lập lịch, hệ thống tệp chung, co giãn). Nó không tự cải thiện băng thông hay độ trễ mạng — nó chỉ giúp dựng cụm dễ hơn.

Ghi nhớ

Ba công nghệ mạng của EC2 — bảng cần thuộc: | Công nghệ | Hệ điều hành | Đặc điểm | |---|---|---| | Intel 82599 VF | Linux, Windows | thế hệ CŨ, tối đa 10 Gbps | | ENA (Elastic Network Adapter) | Linux VÀ Windows | tới 100 Gbps, hiện hành ← câu này | | EFA (Elastic Fabric Adapter) | CHỈ LINUX | ENA + OS-BYPASS cho HPC |

"EFA chỉ hỗ trợ Linux" là điều cần thuộc lòng — nó là điểm phân biệt trong nhiều câu hỏi.

EFA là gì và khi nào cần:

EFA = ENA + khả năng OS-bypass
    → ứng dụng giao tiếp THẲNG với phần cứng mạng
    → bỏ qua nhân hệ điều hành
    → dùng giao thức SRD thay TCP
    → hỗ trợ MPI và NCCL
        ↓
Cần cho: mô phỏng CFD, huấn luyện học sâu phân tán, tính toán khoa học

Nhưng chỉ trên Linux — và đó là lý do đề này phải dùng ENA.

Ba yêu cầu để Enhanced Networking hoạt động: | Yêu cầu | Chi tiết | |---|---| | Loại instance hỗ trợ | hầu hết loại thế hệ hiện tại | | AMI có driver ENA | AMI Amazon Linux và Windows gần đây đã có | | Thuộc tính enaSupport bật | thường bật sẵn với instance mới |

Và một cách tăng hiệu năng mạng nữa: cluster placement group.

Cluster placement group:
    → đặt các instance GẦN NHAU trong cùng một AZ
    → băng thông giữa chúng cao nhất
    → độ trễ thấp nhất
    → BỔ SUNG cho ENA, không thay thế

aws ec2 create-placement-group --group-name cum-cfd --strategy cluster

Ba loại placement group: | Loại | Bố trí | Dùng cho | |---|---|---| | Cluster | gần nhau trong MỘT AZ | HPC, độ trễ thấp nhất | | Spread | mỗi instance một giá máy chủ khác | tối đa hoá chịu lỗi | | Partition | nhóm trên các phân vùng phần cứng tách biệt | HDFS, Cassandra, Kafka |

Và có một vấn đề trong đề mà câu hỏi không hỏi tới nhưng đáng nêu: t3a.medium là lựa chọn RẤT KÉM cho HPC.

Họ T là instance BURSTABLE:
    → hiệu năng CPU dựa trên TÍN DỤNG
    → tải nặng liên tục sẽ CẠN tín dụng
    → rồi bị giới hạn xuống mức cơ sở rất thấp
        ↓
Mô phỏng CFD chạy CPU 100% hàng giờ
    → cạn tín dụng trong vài phút
    → hiệu năng sụp đổ

Và băng thông mạng của t3a.medium cũng rất thấp — khoảng 5 Gbps burst, không phải mức "higher bandwidth" mà đề mong muốn.

Loại instance phù hợp cho CFD: | Họ | Đặc điểm | |---|---| | c5n, c6in | tối ưu tính toán, băng thông mạng 100 Gbps, hỗ trợ EFA | | hpc6a, hpc7a | thiết kế riêng cho HPC | | m5n, r5n | cân bằng, băng thông cao |

Hậu tố n nghĩa là "network optimized" — băng thông cao hơn hẳn loại thường cùng kích thước.

Và AWS ParallelCluster vẫn đáng dùng, chỉ là không phải câu trả lời cho câu hỏi này:

ParallelCluster tự động hoá:
    ✓ dựng head node và compute node
    ✓ cài bộ lập lịch (Slurm)
    ✓ gắn FSx for Lustre làm hệ thống tệp chung
    ✓ tự co giãn số node theo hàng đợi công việc

Nó là công cụ vận hành tuyệt vời, nhưng hiệu năng mạng vẫn do ENA hoặc EFA quyết định.

Và một lưu ý về tầng lưu trữ cho CFD: mô phỏng thường bị nghẽn ở I/O chứ không phải mạng hay CPU. Amazon FSx for Lustre cho thông lượng hàng trăm GB/giây và liên kết trực tiếp với S3 — với dữ liệu mô phỏng lớn, đó thường là cải thiện lớn hơn cả việc tối ưu mạng.

Đáp án

B — Bật access log trên Application Load Balancer; tích hợp cụm Amazon ECS với CloudWatch Application Insights để phân tích mẫu lưu lượng và đơn giản hoá việc chẩn đoán.

Vì sao đúng

Đề nêu ba yêu cầu, và access log của ALB đáp ứng trọn vẹn yêu cầu chính: | Yêu cầu | ALB access log có | |---|---| | Thông tin CHI TIẾT của mọi request HTTP | ✅ mỗi request một dòng | | Địa chỉ IP của client | ✅ trường client:port | | Độ trễ mạng | ✅ ba trường thời gian riêng biệt | | Ghi mỗi năm phút | ✅ ALB ghi log theo lô mỗi 5 phút |

Ba trường thời gian trong access log — đúng thứ đề cần:

request_processing_time  → thời gian ALB nhận request và gửi tới target
target_processing_time   → thời gian TARGET xử lý
response_processing_time → thời gian ALB gửi phản hồi về client

Ba con số này cho biết độ trễ nằm ở đâu — mạng, ứng dụng, hay đường về.

Và "LEAST amount of overhead" được đáp ứng vì access log là tính năng dựng sẵn:

aws elbv2 modify-load-balancer-attributes --load-balancer-arn <arn>   --attributes Key=access_logs.s3.enabled,Value=true                Key=access_logs.s3.bucket,Value=kho-log-alb

Bật một công tắc, không cài agent, không viết mã.

Và ALB ghi log theo chu kỳ 5 phút — khớp chính xác với yêu cầu "every five minutes" của đề.

Phân tích bằng Athena:

SELECT client_ip, count(*) AS so_request,
       avg(target_processing_time) AS do_tre_tb
FROM alb_logs
WHERE elb_status_code LIKE '5%'
GROUP BY client_ip ORDER BY so_request DESC LIMIT 20;

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

• **C. Cài AWS X-Ray daemon trên cụm ECS và dùng CloudWatch ServiceLens — đây là phương án gần nhất và X-Ray thực sự mạnh cho việc chẩn đoán, nhưng nó nhiều công hơn hẳn: phải cài daemon, sửa mã ứng dụng để thêm SDK, và X-Ray mặc định chỉ lấy mẫu một phần request chứ không ghi tất cả. Đề đòi "detailed information of ALL HTTP requests".
• **A. Bật CloudTrail cho ALB và dùng CloudTrail Lake — sai loại log: CloudTrail ghi lời gọi API quản trị (tạo listener, sửa target group), không ghi lưu lượng HTTP đi qua load balancer.
• **D. Tích hợp EventBridge metrics trên ALB để lấy IP client — không có cơ chế như vậy: EventBridge định tuyến sự kiện, và metric của ALB là số liệu tổng hợp (số request, độ trễ trung bình), không chứa IP của từng client.

Ghi nhớ

Ba loại log của Elastic Load Balancer: | Log | Nội dung | Đích | |---|---|---| | Access log | MỌI request: IP client, độ trễ, mã trạng thái, user agent | S3 | | Connection log | thông tin kết nối TLS của client | S3 | | CloudWatch metric | số liệu tổng hợp | CloudWatch |

Access log KHÔNG bật mặc định — và nó miễn phí ngoài chi phí lưu trữ S3.

Các trường quan trọng trong ALB access log: | Trường | Nội dung | |---|---| | client:port | IP và cổng của client | | target:port | target xử lý request | | request_processing_time | thời gian ALB → target | | target_processing_time | thời gian target xử lý | | response_processing_time | thời gian target → client | | elb_status_code | mã ALB trả về client | | target_status_code | mã target trả về ALB | | received_bytes / sent_bytes | kích thước | | request | phương thức, URL, phiên bản HTTP | | user_agent, ssl_cipher, trace_id | thông tin bổ sung |

Cặp elb_status_code và target_status_code rất hữu ích khi chẩn đoán:

elb = 502, target = trống  → target không phản hồi hoặc phản hồi sai định dạng
elb = 504, target = trống  → target xử lý quá lâu, ALB timeout
elb = 500, target = 500    → lỗi nằm trong ứng dụng

Giá trị -1 trong các trường thời gian nghĩa là request không tới được target — dấu hiệu của lỗi kết nối.

Ba công cụ quan sát — mỗi cái một vai: | Công cụ | Trả lời câu hỏi | |---|---| | ALB access log | "request nào, từ ai, mất bao lâu?" | | AWS X-Ray | "request đi qua những dịch vụ nào, chậm ở đâu?" | | Container Insights | "container dùng bao nhiêu CPU và bộ nhớ?" | | Application Insights | "có gì bất thường trong ứng dụng không?" |

X-Ray mạnh hơn cho việc truy vết qua nhiều microservice, nhưng cần sửa mã và chỉ lấy mẫu. Access log đơn giản hơn và ghi đủ mọi request.

Ba tối ưu khi phân tích access log ở quy mô lớn: | Tối ưu | Lợi ích | |---|---| | Phân vùng theo ngày | truy vấn chỉ quét phân vùng cần | | Chuyển sang Parquet | giảm 80–90% dữ liệu quét | | Lifecycle rule chuyển sang Glacier | log tích tụ rất nhanh |

Cấu trúc thư mục mà ALB tạo ra:

s3://kho-log-alb/AWSLogs/<account-id>/elasticloadbalancing/<region>/
    <yyyy>/<mm>/<dd>/<file>.log.gz

Đây đã là dạng phân vùng theo ngày — chỉ cần khai partition trong Athena để tận dụng.

Và một lưu ý về ECS Anywhere mà đề nhắc tới:

ECS Anywhere chạy container trên hạ tầng CỦA BẠN
    → Container Insights vẫn thu thập metric được
    → nhưng lưu lượng qua ALB thì vẫn ghi bình thường ở phía AWS

Ba lưu ý về access log: | Lưu ý | Chi tiết | |---|---| | Ghi theo lô mỗi 5 phút | không phải thời gian thực | | Bucket phải cùng Region với ALB | yêu cầu bắt buộc | | Bucket policy phải cho phép ALB ghi | AWS cấp sẵn mẫu policy |

Và với yêu cầu "phân tích mẫu lưu lượng", hãy cân nhắc dựng dashboard:

ALB access log → S3 → Glue Crawler → Athena → QuickSight

QuickSight cho biểu đồ tương tác — hữu ích hơn nhiều so với đọc kết quả SELECT khi tìm mẫu bất thường.

Và một lời khuyên về chi phí: log của một ALB lưu lượng lớn có thể lên tới hàng trăm GB mỗi tháng. Hãy đặt lifecycle rule chuyển sang Standard-IA sau 30 ngày và Glacier sau 90 ngày — chi phí giảm đáng kể mà vẫn giữ được dữ liệu cho việc điều tra về sau.

Đáp án

B — Dùng AWS DataSync chuyển hồ sơ hiện có lên AWS; tạo S3 bucket mới lưu cả hồ sơ cũ lẫn mới; bật CloudTrail với Data Events và S3 Object Lock.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này đáp ứng đủ: | Yêu cầu | Thành phần | |---|---| | Chuyển NGAY hàng triệu hồ sơ cũ lên AWS | DataSync — nhanh, tự động, có xác minh | | Hỗ trợ lượng hồ sơ mới không ngừng tăng | S3 — dung lượng không giới hạn | | Không được SỬA ĐỔI sau khi lưu, giữ vô thời hạn | S3 Object Lock — WORM | | Kiểm toán MỌI lần truy cập dữ liệu | CloudTrail DATA EVENTS |

Vế "each data access must be audited" là điểm phân biệt quan trọng nhất:

CloudTrail MANAGEMENT event:
    → ghi thao tác trên TÀI NGUYÊN: tạo bucket, đổi policy, xoá bucket
    → KHÔNG ghi việc ai đọc tệp nào

CloudTrail DATA event:
    → ghi thao tác trên DỮ LIỆU: s3:GetObject, s3:PutObject, s3:DeleteObject
    → biết CHÍNH XÁC ai đọc hồ sơ bệnh nhân nào, lúc nào, từ đâu

Đề nói "each DATA ACCESS must be audited at all levels" → bắt buộc phải là data event.

aws cloudtrail put-event-selectors --trail-name theo-doi-ho-so-y-te   --advanced-event-selectors '[{
    "Name": "Ghi moi thao tac object",
    "FieldSelectors": [
      {"Field": "eventCategory", "Equals": ["Data"]},
      {"Field": "resources.type", "Equals": ["AWS::S3::Object"]},
      {"Field": "resources.ARN", "StartsWith": ["arn:aws:s3:::kho-ho-so-y-te/"]}]}]'

Và S3 Object Lock đảm bảo tính bất biến:

{"ObjectLockEnabled": "Enabled",
 "Rule": {"DefaultRetention": {"Mode": "COMPLIANCE", "Years": 100}}}

Chế độ Compliance: KHÔNG AI xoá hay sửa được, kể cả tài khoản root.

Và DataSync là công cụ đúng cho việc chuyển một lần khối lượng lớn — nhanh hơn công cụ mã nguồn mở tới 10 lần, tự xác minh tính toàn vẹn.

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

• **D. DataSync + S3 + Object Lock nhưng dùng CloudTrail với MANAGEMENT Events — đây là phương án gần nhất và chỉ khác đúng một chữ, nhưng chữ đó quyết định: management event không ghi việc ai đọc tệp nào. Yêu cầu kiểm toán từng lần truy cập dữ liệu không được đáp ứng.
• **A. Dùng Storage Gateway để chuyển + Management Events — hai vấn đề: Storage Gateway phục vụ truy cập lai LIÊN TỤC, không phải công cụ di chuyển một lần khối lượng lớn. Và vẫn sai loại CloudTrail event.
• **C. Storage Gateway + lưu vào EC2 với EBS + S3 server access logging — sai kiến trúc: EBS gắn với một AZ, dung lượng có hạn, không phù hợp cho "hàng triệu hồ sơ và còn tăng". Và Object Lock là tính năng của S3, không áp cho EBS được.

Ghi nhớ

Ba loại sự kiện CloudTrail — bảng cần thuộc: | Loại | Ghi gì | Chi phí | |---|---|---| | Management event | thao tác trên TÀI NGUYÊN (control plane) | miễn phí cho bản sao đầu | | Data event | thao tác trên DỮ LIỆU (data plane) | 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í |

Ví dụ để phân biệt:

Management: CreateBucket, PutBucketPolicy, DeleteBucket
Data:       GetObject, PutObject, DeleteObject     ← "ai đọc tệp nào"

Hai chế độ của S3 Object Lock: | Chế độ | Ai vượt qua được | |---|---| | Governance | người có quyền s3:BypassGovernanceRetention | | Compliance | KHÔNG AI — kể cả root |

Với hồ sơ y tế "protected from any type of modifications", chế độ Compliance là đúng.

Hai kiểu giữ dữ liệu: | Kiểu | Đặc điểm | |---|---| | Retention period | cấm xoá tới một ngày cụ thể | | Legal hold | cấm xoá VÔ THỜI HẠN tới khi gỡ tường minh |

Ba yêu cầu để bật Object Lock:

① Bucket phải bật VERSIONING
② Object Lock phải bật LÚC TẠO BUCKET (hoặc liên hệ AWS Support)
③ Đặt chế độ và thời hạn mặc định, hoặc theo từng object

Điều kiện ② là ràng buộc quan trọng — không bật được cho bucket đã tồn tại qua Console.

Các dịch vụ chuyển dữ liệu — chọn đúng: | Dịch vụ | Phù hợp | |---|---| | DataSync | DI CHUYỂN hoặc đồng bộ, nhanh, tự động ← câu này | | Storage Gateway | TRUY CẬP liên tục — tại chỗ dùng, dữ liệu ở AWS | | Snow Family | khối lượng rất lớn, băng thông kém | | Transfer Family | endpoint SFTP cho đối tác |

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

DataSync:         DI CHUYỂN dữ liệu
Storage Gateway:  TRUY CẬP dữ liệu liên tục

Ba đặc điểm của DataSync: | Đặc điểm | Chi tiết | |---|---| | Nhanh hơn rsync/scp tới 10 lần | giao thức riêng, nén, truyền song song | | Tự xác minh tính toàn vẹn | so checksum — quan trọng với hồ sơ y tế | | Giữ metadata | quyền, timestamp |

Và với 5 TB trở lên, hãy tính thời gian truyền:

Quy tắc ước lượng: nếu truyền qua mạng mất HƠN MỘT TUẦN
    → cân nhắc AWS Snowball

Ba biện pháp bổ sung cho hồ sơ y tế: | Biện pháp | Lý do | |---|---| | Mã hoá SSE-KMS | audit trail về ai giải mã | | Bucket policy bắt buộc HTTPS | điều kiện aws:SecureTransport | | Lifecycle chuyển hồ sơ cũ sang Glacier | hàng triệu hồ sơ lỗi thời — tiết kiệm rất lớn |

Dòng cuối đáng chú ý cho tình huống của đề: hồ sơ "obsolete, not accessed by the web application" là ứng viên hoàn hảo cho Glacier Deep Archive — rẻ hơn Standard khoảng 23 lần.

Lưu ý quan trọng: Object Lock VẪN có hiệu lực sau khi chuyển sang Glacier — tính bất biến không mất đi khi đổi lớp lưu trữ.

Ba yêu cầu tuân thủ cho dữ liệu y tế: | Yêu cầu | Chi tiết | |---|---| | Ký BAA với AWS | bắt buộc về pháp lý cho PHI | | Chỉ dùng dịch vụ đủ điều kiện HIPAA | S3, DataSync, CloudTrail đều nằm trong danh sách | | Quyền truy cập chi tiết | đề nói "granular access control" |

Và với "granular access control", S3 Access Point là công cụ phù hợp:

Access point cho bác sĩ  → chỉ đọc thư mục của khoa mình
Access point cho kiểm toán → chỉ đọc, mọi thư mục
Access point cho ứng dụng → đọc và ghi thư mục hoạt động

Mỗi nhóm một access point với policy riêng — thay vì một bucket policy khổng lồ khó đọc.

Và một lưu ý về chi phí data event: với bucket có hàng triệu object được truy cập thường xuyên, phí CloudTrail data event có thể rất lớn. Hãy giới hạn phạm vi theo prefix thay vì bật cho toàn bộ bucket, và cân nhắc CloudTrail Lake để lưu trữ và truy vấn hiệu quả hơn.

Đáp án

B — AWS CloudTrail.

Vì sao đúng

Đề cần ghi lại và lưu trữ bền vững mọi lời gọi API tới tài nguyên AWS phục vụ kiểm toán — và đó chính xác là mục đích của CloudTrail.

CloudTrail ghi lại năm thông tin cho mỗi lời gọi API:

AI     → identity của người gọi (IAM user, role, dịch vụ AWS)
GÌ     → tên API (PutObject, DeleteTable, RunInstances...)
KHI NÀO → dấu thời gian chính xác
Ở ĐÂU  → IP nguồn, Region, user agent
KẾT QUẢ → thành công hay thất bại, kèm mã lỗi

Và nó bắt được mọi cách gọi API:

✓ Console
✓ AWS CLI
✓ SDK (như ứng dụng trong đề)
✓ Dịch vụ AWS gọi hộ

Và vế "durably stored" được đáp ứng bằng cách tạo trail ghi vào S3:

aws cloudtrail create-trail --name theo-doi-kiem-toan   --s3-bucket-name kho-log-cloudtrail   --is-multi-region-trail --enable-log-file-validation

Ba cấu hình trong lệnh trên đều quan trọng: | Cấu hình | Lý do | |---|---| | --is-multi-region-trail | hoạt động ở Region lạ vẫn bị ghi lại | | --enable-log-file-validation | chứng minh log chưa bị sửa | | Ghi vào S3 | lưu trữ bền vững, giữ được vô thời hạn |

Và log tự động được mã hoá bằng SSE-S3 — không cần cấu hình gì thêm.

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

• **A. Amazon CloudWatch — đây là phương án gần nhất vì cũng là dịch vụ giám sát, nhưng nó trả lời câu hỏi khác: CloudWatch thu thập metric hiệu năng (CPU, số request, độ trễ) và log ứng dụng. Nó không ghi lời gọi API tới AWS. (CloudTrail có thể gửi log SANG CloudWatch Logs, nhưng nguồn dữ liệu vẫn là CloudTrail.)
• **C. AWS X-Ray — là công cụ truy vết phân tán: nó theo dõi một request đi qua các microservice để tìm nút thắt hiệu năng. Nó không phải công cụ kiểm toán bảo mật.
• **D. Amazon API Gateway — là dịch vụ TẠO API, không phải công cụ ghi log: nó cho phép bạn xây API cho ứng dụng của mình. Nó không ghi lời gọi tới các dịch vụ AWS khác.

Ghi nhớ

Ba dịch vụ quan sát của AWS — mỗi cái một câu hỏi: | Dịch vụ | Trả lời | |---|---| | CloudTrail | "AI đã làm GÌ với tài nguyên nào?" | | CloudWatch | "hệ thống đang chạy thế nào?" | | X-Ray | "request đi qua đâu và chậm ở chỗ nào?" | | AWS Config | "cấu hình hiện tại có đúng quy định không?" |

Ba loại sự kiện của CloudTrail: | 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 bất thường | có phí |

Đề nói "all API calls to your AWS resources" → management event là đủ cho phần lớn nhu cầu kiểm toán. Nếu cần biết ai đọc object nào trong S3 thì phải bật thêm data event.

Ba đặc điểm cần nhớ về CloudTrail: | Đặ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 | |---|---| | Trail cho TOÀN BỘ Region | 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 tính toàn vẹn | | Organization trail | một trail cho mọi tài khoản |

Dòng thứ hai là biện pháp quan trọng nhất về mặt bảo mậ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ệ thêm bằng S3 Object Lock:

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

Log file validation hoạt động thế nào:

CloudTrail tạo tệp DIGEST mỗi giờ
    → chứa hash SHA-256 của các tệp log
    → ký bằng khoá riêng của AWS
        ↓
Kiểm chứng:
    aws cloudtrail validate-logs --trail-arn <arn> --start-time <t>
    → phát hiện được nếu log bị sửa hoặc xoá

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

Tìm nhanh một thao tác cụ thể:

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

Và để nhận cảnh báo thời gian thực về thao tác nguy hiểm:

{"source": ["aws.s3", "aws.ec2", "aws.iam"],
 "detail-type": ["AWS API Call via CloudTrail"],
 "detail": {"eventName": ["DeleteBucket", "TerminateInstances",
                          "DeleteUser", "PutBucketPolicy"]}}

EventBridge rule bắt trực tiếp và gọi SNS — nhanh hơn nhiều so với đợi ai đó đọc log.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Management event | bản sao đầu tiên miễn phí, các trail sau tính phí | | Data event | rất tốn với bucket lưu lượng lớn — giới hạn theo prefix | | Lưu trữ S3 | dùng lifecycle rule chuyển sang Glacier |

Và một lời khuyên cho việc chuẩn bị kiểm toán: hãy dựng sẵn vài truy vấn Athena thường dùng (ai đăng nhập từ IP lạ, ai xoá tài nguyên trong tháng, thao tác nào thất bại nhiều nhất). Khi kiểm toán viên hỏi, có sẵn truy vấn nhanh hơn nhiều so với viết từ đầu dưới áp lực thời gian.

Đáp án

A và B.

• A — Dùng Amazon Macie phát hiện dữ liệu nhạy cảm và tạo EventBridge rule bắt loại sự kiện SensitiveData
• B — Đặt SNS topic làm đích của EventBridge rule để gửi thông báo khi lỗi tái diễn

Vì sao đúng

Đề nêu hai yêu cầu, và hai đáp án giải quyết lần lượt: | Yêu cầu | Giải pháp | |---|---| | Phát hiện PII bị tải nhầm lên S3 | A — Macie quét và phân loại dữ liệu nhạy cảm | | Được THÔNG BÁO khi lỗi tái diễn | B — SNS gửi cảnh báo |

Amazon Macie là dịch vụ dành riêng cho việc này:

Macie dùng học máy và khớp mẫu để quét S3
    → phát hiện: số thẻ tín dụng, số bảo hiểm xã hội,
      hộ chiếu, khoá API, thông tin y tế, tên và địa chỉ
    → phân loại theo mức độ nghiêm trọng
    → phát finding vào EventBridge và Security Hub

EventBridge rule bắt finding:

{"source": ["aws.macie"],
 "detail-type": ["Macie Finding"],
 "detail": {"type": [{"prefix": "SensitiveData:"}]}}

Các loại finding của Macie: | Loại | Nghĩa | |---|---| | SensitiveData:S3Object/Personal | thông tin cá nhân — PII | | SensitiveData:S3Object/Financial | thông tin tài chính | | SensitiveData:S3Object/Credentials | khoá và mật khẩu | | Policy:IAMUser/S3BucketPublic | bucket bị mở công khai |

Và SNS là đích phù hợp cho việc thông báo:

SNS gửi tới email, SMS, Lambda, HTTP endpoint
    → đội bảo mật nhận cảnh báo ngay
    → một topic phát tán tới nhiều người nhận

aws events put-targets --rule canh-bao-du-lieu-nhay-cam   --targets "Id"="1","Arn"="arn:aws:sns:ap-southeast-1:123456789012:canh-bao-bao-mat"

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

• **C. Dùng Amazon GuardDuty phát hiện dữ liệu nhạy cảm với finding loại CRITICAL — đây là phương án gần nhất vì GuardDuty cũng là dịch vụ bảo mật phát finding vào EventBridge, nhưng nó làm việc khác: GuardDuty phát hiện HÀNH VI ĐE DOẠ (truy cập bất thường, gọi API đáng ngờ, liên lạc với IP độc hại). Nó KHÔNG quét NỘI DUNG dữ liệu để tìm PII.
• **D. Đặt SQS làm đích của EventBridge rule để gửi thông báo — SQS là hàng đợi, không phải kênh thông báo: nó lưu thông điệp chờ ai đó đến lấy. Muốn người nhận được cảnh báo thì phải có thêm consumer đọc hàng đợi và gửi đi — thừa một bước so với SNS.
• **E. Đặt AWS IoT Message Broker làm đích — sai ngữ cảnh hoàn toàn: IoT Message Broker phục vụ giao tiếp MQTT giữa các thiết bị IoT. Nó không phải kênh cảnh báo cho đội bảo mật.

Ghi nhớ

Các dịch vụ bảo mật của AWS — mỗi cái một vai: | Dịch vụ | Phát hiện | |---|---| | Amazon Macie | DỮ LIỆU NHẠY CẢM trong S3 (PII, tài chính, thông tin đăng nhập) | | Amazon GuardDuty | HÀNH VI ĐE DOẠ (truy cập bất thường, mã độc, dò quét) | | Amazon Inspector | LỖ HỔNG phần mềm (CVE) trong EC2, ECR, Lambda | | AWS Security Hub | TỔNG HỢP finding từ mọi dịch vụ trên | | Amazon Detective | ĐIỀU TRA sâu một sự cố đã phát hiện | | AWS Config | cấu hình sai so với quy tắc |

Bốn dịch vụ đầu là bộ tứ hay bị nhầm lẫn nhất trong đề thi:

Macie      → "có dữ liệu nhạy cảm nào bị để nhầm chỗ không?"
GuardDuty  → "có ai đang hành xử đáng ngờ không?"
Inspector  → "phần mềm của tôi có lỗ hổng nào không?"
Security Hub → "tổng hợp tất cả lại cho tôi xem"

Ba khả năng của Amazon Macie: | Khả năng | Chi tiết | |---|---| | Khám phá dữ liệu nhạy cảm tự động | quét liên tục, lấy mẫu thông minh để tiết kiệm | | Job phân loại theo lịch | quét sâu toàn bộ bucket | | Đánh giá tình trạng bảo mật của bucket | phát hiện bucket công khai, chưa mã hoá |

Và Macie hỗ trợ mẫu tuỳ chỉnh:

{"regex": "MSBN-[0-9]{4}-[0-9]{6}",
 "name": "ma-so-benh-nhan",
 "keywords": ["ma benh nhan", "patient id"]}

Rất hữu ích cho định danh riêng của tổ chức mà mẫu dựng sẵn không biết.

SNS và SQS — phân biệt: | | SNS | SQS | |---|---|---| | Mô hình | phát tán (pub/sub) — ĐẨY tới người nhận | hàng đợi — người nhận KÉO về | | Đích | email, SMS, Lambda, HTTP, SQS | ứng dụng consumer | | Phù hợp | thông báo cho CON NGƯỜI | xử lý bất đồng bộ |

Đề cần "notified" → SNS là lựa chọn đúng.

Và mẫu kết hợp cả hai cũng phổ biến:

EventBridge → SNS topic
                ├─▶ Email đội bảo mật (thông báo ngay)
                └─▶ SQS queue → Lambda (tự động khắc phục)

Ba biện pháp PHÒNG NGỪA — tốt hơn phát hiện: | Biện pháp | Chi tiết | |---|---| | Block Public Access ở mức TÀI KHOẢN | ngăn mọi bucket bị mở công khai | | SCP chặn tạo bucket công khai | ràng buộc ở mức tổ chức | | Bắt buộc mã hoá bằng bucket policy | chặn ghi không mã hoá |

Và tự động khắc phục khi Macie phát hiện PII:

def lambda_handler(event, context):
    d = event['detail']
    bucket = d['resourcesAffected']['s3Bucket']['name']
    key = d['resourcesAffected']['s3Object']['key']
    # Chuyển object sang bucket cách ly và gỡ quyền công khai
    s3.copy_object(Bucket='kho-cach-ly', Key=key,
                   CopySource={'Bucket': bucket, 'Key': key})
    s3.delete_object(Bucket=bucket, Key=key)

Chuyển từ "phát hiện rồi báo" sang "phát hiện rồi tự xử lý" — giảm thời gian dữ liệu nhạy cảm nằm ở nơi không an toàn.

Ba lưu ý về chi phí Macie: | Khoản | Chi tiết | |---|---| | Đánh giá bucket | tính theo số bucket được giám sát | | Quét nội dung | tính theo GB được quét — khoản lớn nhất | | Mức miễn phí | 30 ngày dùng thử |

Với bucket rất lớn, hãy dùng lấy mẫu và giới hạn phạm vi theo prefix thay vì quét toàn bộ mỗi lần.

Và một lời khuyên về quy trình: khi Macie phát hiện PII, đừng chỉ xoá tệp. Hãy điều tra xem dữ liệu đó đã ở đó bao lâu và ai đã truy cập — dùng CloudTrail data event. Với nhiều quy định về quyền riêng tư, việc dữ liệu bị phơi ra có thể kích hoạt nghĩa vụ thông báo cho người dùng bị ảnh hưởng.

Đáp án

B — Cấu hình SQS dùng long polling bằng cách đặt ReceiveMessageWaitTimeSeconds LỚN HƠN 0.

Vì sao đúng

Đề mô tả triệu chứng chính xác của short polling: consumer poll liên tục, nhận về phản hồi rỗng, tốn CPU và tốn tiền.

Vì sao short polling gây lãng phí:

Short polling (ReceiveMessageWaitTimeSeconds = 0):
    → gọi ReceiveMessage → TRẢ VỀ NGAY
    → hàng đợi rỗng → trả về kết quả rỗng
    → consumer gọi lại ngay lập tức
        ↓
    Vòng lặp chặt: hàng nghìn request rỗng mỗi phút
    → tốn CPU (đề nêu đúng điều này)
    → tốn tiền (SQS tính phí theo SỐ REQUEST)

Long polling giải quyết triệt để:

Long polling (ReceiveMessageWaitTimeSeconds = 20):
    → gọi ReceiveMessage
    → hàng đợi rỗng → SQS GIỮ KẾT NỐI, chờ tới 20 giây
    → có thông điệp → trả về NGAY
    → hết 20 giây vẫn rỗng → trả về rỗng
        ↓
    Một request phục vụ 20 giây thay vì vài mili giây
    → số request giảm hàng trăm lần

Và có một lợi ích thứ hai ít được nhắc tới:

Short polling hỏi một TẬP CON máy chủ SQS
    → có thể trả về RỖNG dù hàng đợi CÓ thông điệp

Long polling hỏi MỌI máy chủ
    → không bỏ sót thông điệp

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

Hoặc đặt theo từng lời gọi:

sqs.receive_message(QueueUrl=url, WaitTimeSeconds=20, MaxNumberOfMessages=10)

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

• **A. Cấu hình long polling bằng cách đặt ReceiveMessageWaitTimeSeconds bằng 0 — đây là phương án gần nhất và có tên cơ chế đúng, nhưng giá trị 0 chính là SHORT polling. Đây là bẫy đảo giá trị.
• **D. Cấu hình short polling với giá trị bằng 0 — đúng về mặt định nghĩa nhưng sai mục tiêu: đó chính là cấu hình hiện tại đang gây vấn đề.
• **C. Cấu hình short polling với giá trị lớn hơn 0 — mâu thuẫn nội tại: đặt giá trị lớn hơn 0 nghĩa là bật long polling, không phải short polling.

Ghi nhớ

Short polling và long polling — bảng phân biệt cốt lõi: | | Short polling | Long polling | |---|---|---| | ReceiveMessageWaitTimeSeconds | 0 | 1–20 | | Hàng đợi rỗng | trả về NGAY | CHỜ tới khi có thông điệp | | Phạm vi hỏi | một TẬP CON máy chủ SQS | MỌI máy chủ | | Có thể trả rỗng dù có thông điệp | ✅ | ❌ | | Chi phí | cao — nhiều request rỗng | thấp | | Độ trễ nhận thông điệp | thấp | thấp (trả về ngay khi có) |

Quy tắc: long polling nên bật cho MỌI hàng đợi. Không có nhược điểm đáng kể.

Và long polling KHÔNG làm tăng độ trễ:

Hiểu nhầm phổ biến: "chờ 20 giây nghĩa là thông điệp bị trễ 20 giây"
    ↓
SAI. Thông điệp đến lúc nào thì SQS trả về ngay lúc đó.
    → 20 giây chỉ là thời gian chờ TỐI ĐA khi không có gì

Bốn tham số thời gian của SQS: | Tham số | Mặc định | Khoảng | |---|---|---| | ReceiveMessageWaitTimeSeconds | 0 | 0–20 | | VisibilityTimeout | 30 giây | 0 – 12 giờ | | MessageRetentionPeriod | 4 ngày | 1 phút – 14 ngày | | DelaySeconds | 0 | 0 – 15 phút |

Ba cách khác giảm chi phí và tăng thông lượng SQS: | Cách | Lợi ích | |---|---| | MaxNumberOfMessages = 10 | lấy tối đa 10 thông điệp mỗi request | | SendMessageBatch / DeleteMessageBatch | gộp tới 10 thao tác mỗi request | | Client-side buffering của SDK | tự động gom lô |

Kết hợp long polling với batch cho hiệu quả tối đa:

r = sqs.receive_message(QueueUrl=url,
                        WaitTimeSeconds=20,
                        MaxNumberOfMessages=10)
# 1 request thay vì 10 → giảm 90% chi phí

SQS tính phí theo SỐ REQUEST, nên hai tối ưu trên tác động trực tiếp tới hoá đơn:

Không tối ưu: 1 thông điệp = 1 receive + 1 delete = 2 request
Có batch:     10 thông điệp = 1 receive + 1 delete = 2 request
    → giảm 10 lần

Ba lưu ý khi dùng long polling: | Lưu ý | Chi tiết | |---|---| | Đặt timeout của HTTP client LỚN HƠN WaitTimeSeconds | nếu không client tự ngắt trước khi SQS trả lời | | Với Lambda event source mapping, AWS tự lo | không cần cấu hình | | Áp được ở mức hàng đợi hoặc từng lời gọi | lời gọi ghi đè cấu hình hàng đợi |

Dòng đầu là lỗi cấu hình hay gặp:

config = Config(read_timeout=25)   # phải > WaitTimeSeconds = 20
sqs = boto3.client('sqs', config=config)

Không đặt thì SDK ném lỗi timeout dù SQS hoạt động bình thường.

Và với kiến trúc trong đề, hãy cân nhắc thay đội EC2 bằng Lambda: | | EC2 poll SQS | Lambda event source mapping | |---|---|---| | Poll | bạn tự viết vòng lặp | AWS lo — long polling sẵn | | Co giãn | Auto Scaling theo độ sâu hàng đợi | tự động theo số thông điệp | | Chi phí khi rảnh | vẫn trả tiền instance | 0 đồng | | Thời gian xử lý tối đa | không giới hạn | 15 phút |

Với hệ thống bán vé có tải biến động, Lambda thường rẻ hơn và ít công hơn nhiều.

Nếu vẫn dùng EC2, hãy co giãn theo độ sâu hàng đợi:

Metric: ApproximateNumberOfMessagesVisible / số instance
    → target tracking giữ tỷ lệ này ở một mức
    → đội máy tự lớn khi hàng đợi dài, co lại khi vắng

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | NumberOfEmptyReceives | số lần poll trả về rỗng — chỉ báo trực tiếp của vấn đề trong đề | | ApproximateAgeOfOldestMessage | consumer có theo kịp không | | ApproximateNumberOfMessagesVisible | hàng đợi tích tụ |

NumberOfEmptyReceives là cách đo hiệu quả của thay đổi: sau khi bật long polling, con số này phải giảm mạnh.

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 thứ nên khai tường minh ngay từ đầu là long polling (20 giây), VisibilityTimeout khớp thời gian xử lý, và một dead-letter queue — cả ba đều là mặc định mà SQS không đặt giúp bạn.

Đáp án

C — Cấu hình VPC Endpoint kèm route tương ứng để đưa dữ liệu tới S3.

Vì sao đúng

Đề nêu yêu cầu rõ: dữ liệu KHÔNG được đi qua Internet công cộng, và instance nằm trong private subnet.

Và VPC endpoint là cơ chế duy nhất trong bốn phương án làm được điều đó:

VPC gateway endpoint cho S3:
    → thêm route vào route table của private subnet
    → prefix list của S3 → vpce-xxxx
    → lưu lượng đi trên MẠNG NỘI BỘ của AWS
    → KHÔNG BAO GIỜ ra Internet

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à với S3, gateway endpoint còn MIỄN PHÍ hoàn toàn — không phí giờ, không phí xử lý dữ liệu.

Và endpoint policy siết thêm một lớp bảo vệ cho dữ liệu tài chính:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:PutObject"],
  "Resource": ["arn:aws:s3:::kho-du-lieu-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 quan trọng với ngân hàng.

Và ở chiều ngược lại, bucket policy khoá theo endpoint:

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

Bucket chỉ truy cập được qua đúng endpoint đó — kể cả người có thông tin đăng nhập hợp lệ cũng không tải dữ liệu về từ bên ngoài.

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

• **D. Đặt NAT gateway trong PRIVATE subnet với route trỏ tới S3 — đây là phương án gần nhất vì NAT là cách phổ biến để private subnet ra ngoài, nhưng nó sai ở hai điểm: NAT gateway phải nằm ở PUBLIC subnet (nó cần Internet Gateway để ra ngoài), và quan trọng hơn — lưu lượng qua NAT VẪN ĐI QUA INTERNET CÔNG CỘNG, vi phạm chính yêu cầu của đề.
• **A. Tạo Internet Gateway trong public subnet với route trỏ tới S3 — đi ngược yêu cầu: Internet Gateway là cửa ra Internet. Dùng nó nghĩa là dữ liệu tài chính đi qua mạng công cộng.
• **B. Cấu hình Transit Gateway với route trỏ tới S3 — sai công cụ: Transit Gateway kết nối các VPC và mạng tại chỗ với nhau. S3 không phải VPC — không có attachment nào tới S3.

Ghi nhớ

Hai loại VPC endpoint — bảng cần thuộc: | | Gateway endpoint | Interface endpoint (PrivateLink) | |---|---|---| | Dịch vụ | 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 dùng gateway endpoint" là điều cần thuộc lòng.

Khi nào phải dùng interface endpoint cho S3: | 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 |

Ba lợi ích của VPC endpoint: | Lợi ích | Chi tiết | |---|---| | Bảo mật | lưu lượng KHÔNG BAO GIỜ ra Internet ← câu này | | Chi phí | miễn phí (gateway), và bỏ được phí NAT | | Kiểm soát bằng endpoint policy | giới hạn bucket truy cập được |

Ba cách để private subnet ra ngoài — so sánh: | Cách | Đi qua Internet | Chi phí | |---|---|---| | VPC gateway endpoint | ❌ KHÔNG | miễn phí | | VPC interface endpoint | ❌ không | phí giờ + phí GB | | NAT Gateway | ✅ CÓ | ~32 USD/tháng + 0,045 USD/GB |

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 cho S3, hãy xem còn dịch vụ nào đi qua NAT: | Dịch vụ | Có interface endpoint | |---|---| | ECR | ✅ (kéo image container rất tốn băng thông) | | CloudWatch Logs | ✅ | | Systems Manager | ✅ (cần 3 endpoint: ssm, ssmmessages, ec2messages) | | Secrets Manager, KMS | ✅ | | STS | ✅ |

Với ngân hàng, việc đưa MỌI lưu lượng vào endpoint riêng tư thường là yêu cầu tuân thủ — không chỉ để tiết kiệm.

Bốn lớp bảo vệ cho dữ liệu tài chính trên S3: | Lớp | Cấu hình | |---|---| | Đường đi riêng tư | VPC endpoint ← câu này | | Mã hoá at rest | SSE-KMS với customer managed key | | 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 |

Và bật CloudTrail data event để kiểm toán:

aws cloudtrail put-event-selectors --trail-name theo-doi-du-lieu   --advanced-event-selectors '[{
    "FieldSelectors": [
      {"Field": "eventCategory", "Equals": ["Data"]},
      {"Field": "resources.type", "Equals": ["AWS::S3::Object"]}]}]'

Với dữ liệu tài chính, biết ai đọc tệp nào thường là yêu cầu kiểm toán bắt buộc.

Cách kiểm chứng endpoint đang hoạt động:

# Trên instance, kiểm tra route table
aws ec2 describe-route-tables --route-table-ids rtb-private-1a   --query 'RouteTables[].Routes[?GatewayId!=null]'
# Phải thấy một route với DestinationPrefixListId và VpcEndpointId

Và một lưu ý về VPC Flow Logs: sau khi đặt endpoint, hãy bật flow log và kiểm tra rằng không còn lưu lượng nào tới dải IP công khai của S3. Đó là bằng chứng cụ thể để trình bày với đội tuân thủ, thay vì chỉ nói "chúng tôi đã cấu hình endpoint".

Đáp án

C — Volume Gateway ở chế độ CACHED (cached mode).

Vì sao đúng

Đề nêu bốn yêu cầu, và cached volume gateway đáp ứng chính xác cả bốn: | Yêu cầu | Cơ chế | |---|---| | Mount bằng thiết bị iSCSI | Volume Gateway dùng iSCSI | | Giảm nhu cầu mở rộng kho tại chỗ | dữ liệu chính nằm ở AWS | | Truy cập ĐỘ TRỄ THẤP tới dữ liệu mới | cache cục bộ giữ phần hay dùng | | Dữ liệu cũ hiếm khi truy cập | lấy từ S3 khi cần |

Ba từ khoá trong đề chỉ thẳng tới đáp án:

"iSCSI"                              → Volume Gateway (không phải File Gateway)
"minimize the need to scale
 the on-premises storage"            → CACHED (không phải Stored)
"low-latency access to the
 latest data subsets"                → cache cục bộ

Cached mode và stored mode — khác biệt cốt lõi:

CACHED:
    Dữ liệu ĐẦY ĐỦ ở AWS (S3)
    Đĩa cục bộ = CACHE cho phần hay dùng
        → dung lượng tại chỗ nhỏ, phục vụ được dữ liệu lớn
        → ĐÚNG với yêu cầu "không mở rộng kho tại chỗ"

STORED:
    Dữ liệu ĐẦY ĐỦ ở TẠI CHỖ
    AWS giữ bản sao lưu (snapshot)
        → vẫn cần đủ đĩa cho toàn bộ dữ liệu
        → KHÔNG giải quyết vấn đề thiếu chỗ

Và mô hình truy cập mà đề mô tả khớp hoàn hảo với cached mode:

"frequently accesses the LATEST data subsets locally
 while the OLDER data are RARELY accessed"
    ↓
    Dữ liệu mới → nằm trong cache → đọc nhanh như đĩa cục bộ
    Dữ liệu cũ  → lấy từ S3 khi cần → chậm hơn nhưng hiếm khi cần

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

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

• **A. Volume Gateway ở chế độ STORED — đây là phương án gần nhất và cũng dùng iSCSI, nhưng nó không giải quyết vấn đề dung lượng: stored mode giữ toàn bộ dữ liệu tại chỗ, AWS chỉ có bản sao lưu. Công ty vẫn phải mua thêm đĩa cho khối lượng dữ liệu đang tăng.
• **D. File Gateway — sai giao thức: File Gateway dùng NFS hoặc SMB, không phải iSCSI. Đề nói rõ "mount using iSCSI devices".
• **B. Tape Gateway — sai loại nhu cầu: tape gateway mô phỏng thư viện băng từ ảo, phục vụ phần mềm sao lưu truyền thống. Nó không cung cấp ổ đĩa cho ứng dụng truy cập hằng ngày.

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ừ |

Từ khoá nhận diện:

"NFS", "SMB", "file share" → File Gateway "iSCSI", "block volume" → Volume Gateway "tape", "backup software", "VTL" → Tape Gateway

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

Quy tắc chọn:

"Không đủ chỗ, muốn mở rộng bằng đám mây" → CACHED "Đủ chỗ, cần sao lưu và phục hồi thảm hoạ" → STORED

Ba yêu cầu khi triển khai: | Yêu cầu | Chi tiết | |---|---| | Máy ảo gateway tại chỗ | VMware, Hyper-V, KVM, EC2, hoặc thiết bị phần cứng | | Đĩa cho CACHE | kích thước quyết định trải nghiệm | | Đĩa 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:

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

AWS khuyến nghị cache ít nhất 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 sang EC2 | volume tại chỗ khôi phụ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 ngay.

Và tích hợp với AWS Backup:

aws backup start-backup-job --backup-vault-name kho-sao-luu   --resource-arn <arn-volume-gateway> --iam-role-arn <arn-role>

Quản lý sao lưu tập trung cùng các tài nguyên AWS khác.

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 thường dùng CÙNG NHAU:

DataSync chuyển khối lượng ban đầu (nhanh hơn nhiều)
    ↓
Storage Gateway phục vụ truy cập hằng ngày sau đó

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí gateway theo giờ | 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 là lý do nữa để cấp cache đủ lớn — tỷ lệ cache miss cao nghĩa là phí truyền dữ liệu ra tăng theo.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CachePercentUsed | cache gần đầy nghĩa là cần mở rộng | | CacheHitPercent | tỷ lệ trúng cache — thấp nghĩa là cache quá nhỏ | | UploadBufferPercentUsed | buffer đầy sẽ chặn việc ghi |

Và một lời khuyên về băng thông: đặt giới hạn băng thông theo lịch để việc đẩy dữ liệu lên S3 không nghẽn đường truyền trong giờ làm việc — Storage Gateway hỗ trợ cấu hình này sẵn, và với công ty phân tích dữ liệu có khối lượng lớn, đó là thiết lập cần thiết ngay từ đầu.