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

Đáp án

D — Thiết lập một cluster placement group trong MỘT Availability Zone duy nhất, cùng một AWS Region.

Vì sao đúng

Đề nêu vấn đề rõ: HPC cluster trải trên nhiều AZ đang gặp độ trễ cao cho giao tiếp node-to-node gắn kết chặt (tightly-coupled).

Nguyên nhân gốc: giao tiếp chéo AZ có độ trễ cao hơn hẳn.

Trong cùng AZ, cùng cluster placement group:
    → instance đặt gần nhau về mặt vật lý
    → độ trễ vài chục MICROgiây
    → băng thông tới 100 Gbps giữa các instance

Chéo AZ:
    → AZ là các trung tâm dữ liệu CÁCH XA NHAU vài km
    → độ trễ MILIgiây (cao hơn hàng chục lần)
    → với HPC gắn kết chặt, đó là nút thắt nghiêm trọng

Cluster placement group giải quyết bằng cách đặt instance gần nhau:

aws ec2 create-placement-group   --group-name cum-mo-phong-gio --strategy cluster

aws ec2 run-instances --placement GroupName=cum-mo-phong-gio   --instance-type c6in.32xlarge --count 20 ...

Và đây là đánh đổi có chủ đích mà HPC chấp nhận: | | Cluster placement group | Trải nhiều AZ | |---|---|---| | Độ trễ giữa node | thấp nhất | cao hơn hàng chục lần | | Băng thông | cao nhất | thấp hơn | | Chịu lỗi AZ | ❌ mất cả cụm | ✅ |

Với HPC, độ trễ quan trọng hơn tính sẵn sàng — công việc mô phỏng chạy lại được, nhưng chạy chậm gấp mười lần thì vô dụng.

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

• **A. Thiết lập spread placement group trải nhiều AZ ở nhiều Region — đây là phương án gần nhất về mặt cũng là placement group, nhưng nó làm điều ngược lại: spread placement group ĐẶT CÁC INSTANCE CÁCH XA NHAU trên phần cứng riêng biệt để tối đa hoá tính sẵn sàng. Nó làm độ trễ tệ hơn.
• **B. Thiết lập Direct Connect giữa các Availability Zone — hiểu sai Direct Connect: nó kết nối trung tâm dữ liệu TẠI CHỖ với AWS, không phải giữa các AZ. Các AZ trong một Region đã được nối bằng mạng riêng tốc độ cao sẵn.
• **C. Dùng Dedicated Instance với Elastic Inference accelerator — sai cả hai: Dedicated Instance đảm bảo phần cứng không chia sẻ với khách hàng khác (cho yêu cầu tuân thủ), không cải thiện độ trễ mạng. Và Elastic Inference tăng tốc suy luận học máy, không liên quan tới mô phỏng gió.

Ghi nhớ

Ba chiến lược placement group — bảng phải thuộc: | Chiến lược | Đặt instance | Mục tiêu | |---|---|---| | Cluster | SÁT NHAU trong MỘT AZ | độ trễ thấp nhất, băng thông cao nhất ← câu này | | Spread | TÁCH RA trên phần cứng riêng biệt | tối đa tính sẵn sàng | | Partition | nhóm thành các phân vùng cách ly | cân bằng — cho HDFS, Cassandra, Kafka |

Câu hỏi phân biệt:

"low latency", "HPC", "tightly-coupled", "node-to-node" → Cluster "critical instances", "maximize availability", "avoid correlated failure" → Spread "distributed database", "HDFS", "Cassandra" → Partition

Ba giới hạn của cluster placement group: | Giới hạn | Chi tiết | |---|---| | Chỉ trong MỘT Availability Zone | không trải AZ được | | Nên khởi chạy mọi instance CÙNG LÚC | tăng khả năng có đủ dung lượng | | Nên dùng cùng LOẠI instance | dễ được cấp phát hơn |

Lỗi InsufficientInstanceCapacity hay gặp khi thêm instance vào cluster placement group đã có — vì AWS phải tìm phần cứng gần các instance hiện tại. Khởi chạy toàn bộ cùng lúc giảm rủi ro này.

Elastic Fabric Adapter (EFA) là mảnh ghép còn thiếu cho HPC: | Đặc điểm | Chi tiết | |---|---| | Bỏ qua hệ điều hành (OS-bypass) | giao tiếp trực tiếp với phần cứng mạng | | Hỗ trợ MPI và NCCL | thư viện chuẩn của HPC và huấn luyện phân tán | | Độ trễ thấp hơn ENA thông thường | và ổn định hơn |

Kết hợp cluster placement group với EFA là cấu hình chuẩn cho HPC trên AWS — đề chỉ hỏi về placement group, nhưng EFA thường đi kèm.

Ba yếu tố ảnh hưởng tới hiệu năng mạng của EC2: | Yếu tố | Chi tiết | |---|---| | Loại instance | instance lớn hơn có băng thông cao hơn | | Enhanced networking (ENA hoặc EFA) | bắt buộc cho hiệu năng cao | | Vị trí vật lý (placement group) | ← câu này |

Ba lưu ý về spread placement group: | Lưu ý | Chi tiết | |---|---| | Tối đa 7 instance đang chạy mỗi AZ | giới hạn cứng | | Trải được nhiều AZ | khác cluster | | Dùng cho instance quan trọng riêng lẻ | không cho cụm lớn |

Và một lưu ý về đánh đổi mà đề ngầm chấp nhận: chuyển từ nhiều AZ về một AZ nghĩa là mất khả năng chịu sự cố AZ. Với HPC, cách xử lý thông thường là checkpoint định kỳ ra S3 hoặc FSx for Lustre — nếu AZ gặp sự cố, công việc chạy lại từ checkpoint gần nhất ở AZ khác thay vì từ đầu.

Đáp án

D — Theo mặc định, bản ghi dữ liệu chỉ truy cập được trong 24 GIỜ kể từ khi được thêm vào Kinesis stream.

Vì sao đúng

Đề cho hai dữ kiện, và mâu thuẫn giữa chúng là toàn bộ câu trả lời:

Cảm biến gửi dữ liệu MỖI NGÀY
Consumer xử lý dữ liệu MỖI HAI NGÀY
    ↓
Kinesis giữ bản ghi MẶC ĐỊNH 24 GIỜ
    ↓
Dữ liệu HẾT HẠN trước khi consumer kịp đọc

Cụ thể chuyện gì xảy ra:

Ngày 1, 9h sáng:  cảm biến gửi dữ liệu → vào stream
Ngày 2, 9h sáng:  dữ liệu HẾT HẠN, bị xoá khỏi stream
Ngày 3, 9h sáng:  consumer chạy → dữ liệu ngày 1 ĐÃ MẤT
                  chỉ đọc được dữ liệu ngày 2 (nếu chưa quá 24 giờ)

Đây là lý do S3 nhận thiếu dữ liệu — không phải cảm biến hỏng, không phải bị tấn công.

Cách khắc phục — hai hướng:

# Cách 1: tăng thời gian giữ dữ liệu
aws kinesis increase-stream-retention-period   --stream-name du-lieu-cong-vien --retention-period-hours 168   # 7 ngày

# Cách 2: cho consumer chạy thường xuyên hơn (mỗi ngày thay vì cách ngày)

Cách thứ nhất hợp lý hơn — nó cho biên độ an toàn nếu consumer gặp sự cố và ngừng vài ngày.

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

• **A. Có vấn đề ở cảm biến, chúng bị mất kết nối gián đoạn nên dữ liệu không tới stream — đây là phương án gần nhất về mặt là một giả thuyết hợp lý, nhưng đề đã loại trừ nó tường minh: "You checked the sensors... and verified that the data is indeed sent every day."
• **B. Theo mặc định, Amazon S3 lưu dữ liệu 1 ngày rồi chuyển sang Glacier — hoàn toàn bịa: S3 không có hành vi mặc định nào như vậy. Object nằm ở lớp bạn đặt cho tới khi có lifecycle rule chuyển đi.
• **C. Tài khoản AWS bị hack và ai đó đã xoá dữ liệu trong stream — không có căn cứ nào trong đề, và cũng không phải cách chẩn đoán đúng: luôn kiểm tra cấu hình và giới hạn dịch vụ trước khi giả định có tấn công.

Ghi nhớ

Thời gian giữ dữ liệu của Kinesis Data Streams: | Giá trị | Chi tiết | |---|---| | Mặc định | 24 giờ | | Mở rộng (extended) | tới 7 ngày | | Dài hạn (long-term) | tới 365 ngày |

Tăng thời gian giữ tính thêm phí — nhưng thường rẻ hơn nhiều so với việc mất dữ liệu.

Bốn dịch vụ trong họ Kinesis và thời gian giữ: | Dịch vụ | Giữ dữ liệu | |---|---| | Kinesis Data Streams | 24 giờ – 365 ngày | | Data Firehose | KHÔNG giữ — giao ngay rồi thôi | | Kinesis Video Streams | 1 giờ – 10 năm | | DynamoDB Streams | 24 giờ (cố định) |

DynamoDB Streams cũng giữ 24 giờ và KHÔNG tăng được — nên nếu consumer lỗi quá một ngày, bản ghi mất vĩnh viễn. Đây là ràng buộc tương tự cần nhớ.

Kinesis Data Streams và Data Firehose — chọn đúng cho tình huống này: | | Data Streams | Data Firehose | |---|---|---| | Mô hình | hàng đợi, tự viết consumer | giao tự động vào S3 | | Giữ dữ liệu | 24 giờ – 365 ngày | không giữ | | Phát lại | ✅ | ❌ | | Công vận hành | cao hơn | thấp — không viết mã |

Với tình huống của đề — chỉ cần đưa dữ liệu cảm biến vào S3 — Data Firehose sẽ đơn giản hơn nhiều: nó tự giao vào S3 theo lô, không có khái niệm hết hạn dữ liệu, và không cần consumer nào.

Ba khái niệm của Kinesis Data Streams: | Khái niệm | Chi tiết | |---|---| | Shard | đơn vị thông lượng — 1 MB/giây ghi, 2 MB/giây đọc | | Partition key | quyết định bản ghi vào shard nào | | Sequence number | vị trí bản ghi trong shard |

Ba metric cần giám sát: | Metric | Cảnh báo khi | |---|---| | GetRecords.IteratorAgeMilliseconds | consumer tụt hậu — chỉ báo TỐT NHẤT cho vấn đề này | | WriteProvisionedThroughputExceeded | shard không đủ cho lượng ghi | | ReadProvisionedThroughputExceeded | quá nhiều consumer đọc |

IteratorAgeMilliseconds là metric đáng đặt alarm nhất cho tình huống của đề: nếu nó tiến gần tới thời gian giữ dữ liệu, bạn sắp mất bản ghi. Đặt alarm ở mức 50% thời gian giữ để có thời gian phản ứng.

Ba nguyên nhân khiến consumer tụt hậu: | Nguyên nhân | Cách xử lý | |---|---| | Consumer chạy quá thưa | ← vấn đề của đề; chạy thường xuyên hơn | | Không đủ consumer song song | thêm consumer, tăng shard | | Xử lý mỗi bản ghi quá chậm | tối ưu mã, xử lý theo lô |

Và một mẹo chẩn đoán chung: khi dữ liệu "biến mất" trong một đường ống, hãy kiểm tra thời gian giữ của từng thành phần trước khi nghi ngờ nguồn hay bảo mật. Rất nhiều dịch vụ luồng có giới hạn thời gian mặc định mà người ta không để ý — và triệu chứng luôn là mất dữ liệu một cách âm thầm.

Đáp án

D — Có một giới hạn On-Demand Instance theo vCPU cho mỗi Region nên các request sau bị thất bại. Gửi biểu mẫu yêu cầu tăng hạn mức cho AWS rồi thử lại sau khi được duyệt.

Vì sao đúng

Đề mô tả triệu chứng: 20 request đầu thành công, các request sau thất bại — đó là dấu hiệu điển hình của việc chạm hạn mức dịch vụ.

Và mô hình hạn mức hiện tại của AWS là theo vCPU, không theo số instance:

Mô hình CŨ (đã ngừng):
    giới hạn 20 INSTANCE mỗi Region

Mô hình HIỆN TẠI:
    giới hạn theo TỔNG SỐ vCPU cho mỗi HỌ instance, mỗi Region
    → "Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances"
    → mặc định thường là vài trăm vCPU

Hệ quả thực tế của mô hình vCPU:

Hạn mức 64 vCPU cho họ Standard:
    → 64 instance t3.micro (1 vCPU mỗi cái)
    → hoặc 8 instance m5.2xlarge (8 vCPU mỗi cái)
    → hoặc 2 instance m5.8xlarge (32 vCPU mỗi cái)

Cùng một hạn mức, số lượng instance khác nhau hoàn toàn tuỳ loại máy.

Và cách xử lý đúng là yêu cầu tăng hạn mức:

aws service-quotas request-service-quota-increase   --service-code ec2   --quota-code L-1216C47A   --desired-value 256

(L-1216C47A là mã quota cho "Running On-Demand Standard instances".)

Hạn mức là theo REGION, không phải theo AZ — nên chuyển sang AZ khác trong cùng Region không giúp gì.

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

• **B. Mặc định AWS cho phép tối đa 20 instance mỗi REGION; chọn Region khác và thử lại — đây là phương án gần nhất và đúng về phạm vi (Region), nhưng nó dùng mô hình hạn mức ĐÃ LỖI THỜI: giới hạn hiện nay tính theo vCPU, không theo số instance. Và chuyển Region là né tránh vấn đề, không giải quyết nó — hạ tầng bị phân tán ngoài ý muốn.
• **C. Mặc định tối đa 20 instance mỗi AVAILABILITY ZONE; chọn AZ khác — sai cả con số lẫn phạm vi: hạn mức áp cho cả Region, không phải từng AZ.
• **A. Có vấn đề với EC2 API, cứ gửi lại request là được — chẩn đoán sai: thất bại có quy luật (đúng sau 20 request) chỉ tới giới hạn, không phải lỗi ngẫu nhiên. Gửi lại sẽ tiếp tục thất bại với cùng lỗi.

Ghi nhớ

Mô hình hạn mức vCPU của EC2 — bảng cần biết: | Nhóm hạn mức | Bao gồm | |---|---| | Standard | A, C, D, H, I, M, R, T, Z | | F | instance có FPGA | | G và VT | instance có GPU đồ hoạ | | P | instance GPU cho học máy | | Inf, Trn | chip suy luận và huấn luyện của AWS | | X | instance bộ nhớ rất lớn |

Mỗi nhóm có hạn mức RIÊNG — và mỗi loại mua (On-Demand, Spot, Dedicated Host) cũng có hạn mức riêng.

Cách kiểm tra hạn mức hiện tại:

aws service-quotas get-service-quota   --service-code ec2 --quota-code L-1216C47A

# Xem mức sử dụng thực tế
aws cloudwatch get-metric-statistics   --namespace AWS/Usage --metric-name ResourceCount ...

Console Service Quotas cũng hiển thị mức dùng so với hạn mức — nên bạn thấy được mình còn bao nhiêu chỗ trước khi chạm trần.

Ba loại hạn mức: | Loại | Đặc điểm | |---|---| | Soft limit | tăng được qua yêu cầu | | Hard limit | không tăng được (ví dụ 5 VPC mỗi Region là soft, nhưng một số giới hạn kiến trúc thì cứng) | | Theo tài khoản, theo Region | hầu hết hạn mức có phạm vi Region |

Ba thực hành để tránh chạm hạn mức bất ngờ: | Thực hành | Lý do | |---|---| | Đặt CloudWatch alarm trên metric AWS/Usage | biết trước khi chạm trần | | Yêu cầu tăng hạn mức TRƯỚC sự kiện lớn | duyệt có thể mất vài giờ tới vài ngày | | Dùng Service Quotas để theo dõi tập trung | thấy mọi hạn mức ở một chỗ |

Dòng giữa là bài học quan trọng: nếu bạn biết sẽ có đợt mở rộng lớn (sự kiện, ra mắt sản phẩm), hãy xin tăng hạn mức trước vài ngày — không ai muốn phát hiện mình chạm trần đúng lúc lưu lượng đang tăng vọt.

Ba hạn mức khác của EC2 hay gặp: | Hạn mức | Mặc định điển hình | |---|---| | Elastic IP mỗi Region | 5 | | VPC mỗi Region | 5 | | Security group mỗi ENI | 5 (tăng tới 16) | | Rule mỗi security group | 60 inbound + 60 outbound |

Và một cách viết mã tự động hoá chịu được hạn mức: xử lý lỗi InstanceLimitExceeded một cách tường minh thay vì để script chết giữa chừng. Kết hợp với backoff luỹ thừa và ghi log rõ ràng, bạn biết ngay nguyên nhân thay vì phải chẩn đoán từ một stack trace mơ hồ.

Đáp án

A — Tạo một VPC peering connection MỚI giữa PROD và DEV với các tuyến định tuyến phù hợp.

Vì sao đúng

Đề mô tả cấu trúc peering hiện tại, và mấu chốt là một đặc tính căn bản của VPC peering.

Cấu trúc hiện tại:

DEV ──peering── UAT ──peering── PROD

DEV và PROD: KHÔNG có kết nối trực tiếp

Và VPC peering KHÔNG BẮC CẦU (non-transitive):

A ↔ B  và  B ↔ C
    → KHÔNG cho A ↔ C

Lưu lượng từ DEV KHÔNG đi qua UAT để tới PROD
    → dù cả hai đường peering đều hoạt động

Vì sao AWS thiết kế như vậy: nếu peering bắc cầu, một VPC vô tình trở thành đường đi cho lưu lượng giữa các VPC khác — gây rủi ro bảo mật và làm việc định tuyến khó kiểm soát.

Nên giải pháp duy nhất là tạo peering trực tiếp:

aws ec2 create-vpc-peering-connection   --vpc-id vpc-dev --peer-vpc-id vpc-prod

aws ec2 accept-vpc-peering-connection   --vpc-peering-connection-id pcx-0abc123

Và vế "with the appropriate routes" là bước bắt buộc thứ hai:

# Trong route table của DEV
aws ec2 create-route --route-table-id rtb-dev   --destination-cidr-block 10.2.0.0/16 --vpc-peering-connection-id pcx-0abc123

# Trong route table của PROD
aws ec2 create-route --route-table-id rtb-prod   --destination-cidr-block 10.0.0.0/16 --vpc-peering-connection-id pcx-0abc123

Peering ở trạng thái active mà không có route thì gói tin không đi đâu cả — và triệu chứng là timeout không có thông báo lỗi rõ ràng.

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

• **B. Thêm một tuyến tới PROD trong route table của DEV, dùng VPC peering connection hiện có làm target — đây là phương án gần nhất và thoạt nhìn hợp lý, nhưng nó không hoạt động vì peering không bắc cầu: peering connection DEV↔UAT chỉ định tuyến được tới CIDR của UAT. Thêm tuyến tới CIDR của PROD qua nó sẽ bị từ chối hoặc gói tin bị bỏ.
• **D. Không cần làm gì, vì hai VPC đã kết nối qua UAT nên đã thông với nhau — chính là hiểu lầm mà câu hỏi nhắm tới: peering không bắc cầu.
• **C. Đổi CIDR của DEV và PROD thành chồng lấn nhau để kết nối được — ngược hoàn toàn: VPC peering KHÔNG thiết lập được nếu hai VPC có CIDR chồng lấn. Đó là điều kiện tiên quyết bị vi phạm.

Ghi nhớ

Ba hạn chế của VPC peering — bảng phải thuộc: | Hạn chế | Chi tiết | |---|---| | KHÔNG bắc cầu | A↔B và B↔C KHÔNG cho A↔C ← câu này | | CIDR KHÔNG được chồng lấn | điều kiện tiên quyết | | Tham chiếu security group chỉ trong CÙNG Region | peering liên Region không hỗ trợ |

Và peering cũng không hỗ trợ:

✗ Edge-to-edge routing: VPC A không dùng được IGW, NAT, VGW hay
  VPC endpoint của VPC B

Bài toán mở rộng: số kết nối tăng theo cấp số nhân.

n VPC cần kết nối đầy đủ với nhau:
    số peering = n × (n − 1) / 2

3 VPC  →  3 kết nối
5 VPC  →  10 kết nối
10 VPC →  45 kết nối
20 VPC →  190 kết nối   ← không quản lý nổi

Đây chính là lý do AWS Transit Gateway ra đời: | | VPC Peering | Transit Gateway | |---|---|---| | Bắc cầu | ❌ | ✅ | | Số kết nối cho n VPC | n(n−1)/2 | n | | Chi phí | miễn phí (chỉ phí truyền dữ liệu) | phí theo giờ + GB | | Băng thông | không giới hạn giữa hai VPC | 50 Gbps mỗi attachment | | Phù hợp | vài VPC | nhiều VPC, kiến trúc hub-and-spoke |

Với ba VPC như đề mô tả, peering vẫn hợp lý — nhưng nếu công ty dự kiến thêm nhiều VPC nữa, Transit Gateway là hướng đi bền hơn:

        Transit Gateway
       /       |       \
     DEV      UAT      PROD
    → mọi VPC nói chuyện được với nhau
    → thêm VPC mới chỉ cần MỘT attachment
    → route table của TGW kiểm soát ai nói chuyện với ai

Và Transit Gateway route table cho phép kiểm soát chi tiết — bạn vẫn tách được DEV khỏi PROD nếu muốn, thứ mà peering đầy đủ không làm được một cách gọn gàng.

Ba bước để VPC peering hoạt động:

① Tạo peering connection và bên kia CHẤP NHẬN
② Cập nhật ROUTE TABLE ở CẢ HAI VPC
③ Cấu hình SECURITY GROUP cho phép lưu lượng

Bước ② hay bị quên nhất — và triệu chứng là timeout im lặng.

Ba đặc điểm khác của peering: | Đặc điểm | Chi tiết | |---|---| | Chéo Region được | có phí truyền dữ liệu | | Chéo tài khoản được | bên kia phải chấp nhận | | Lưu lượng không qua Internet | đi trên mạng riêng của AWS |

Và một lưu ý về bảo mật cho tình huống của đề: nối DEV trực tiếp với PROD nghĩa là môi trường phát triển có đường vào môi trường sản xuất. Hãy giới hạn chặt bằng security group tham chiếu cụ thể và route table chỉ tới các subnet cần thiết — thay vì mở toàn bộ CIDR. Với dữ liệu tài chính như công ty bảo hiểm trong đề, đó là rủi ro đáng cân nhắc kỹ.

Đáp án

D — AWS Storage Gateway.

Vì sao đúng

Đề nêu bốn yêu cầu, và Storage Gateway (cụ thể là File Gateway) đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Đang dùng chia sẻ tệp SMB tại chỗ | File Gateway hỗ trợ SMB | | Sao chép toàn bộ dữ liệu lên AWS để tiết kiệm chi phí lưu trữ | dữ liệu thành object trên S3 | | Giữ được độ trễ thấp như file share cục bộ | CACHE trên đĩa tại chỗ | | Không có năng lực tự phát triển công cụ | dịch vụ được quản lý, không viết mã |

Cách File Gateway hoạt động:

Máy chủ tại chỗ
    ↓ mount qua SMB (đường dẫn UNC như cũ)
File Gateway (máy ảo chạy tại trung tâm dữ liệu của bạn)
    ├─ CACHE cục bộ: dữ liệu VỪA TRUY CẬP → độ trễ thấp
    └─ đồng bộ lên S3: mỗi tệp thành MỘT OBJECT

Và mẫu truy cập mà đề mô tả khớp hoàn hảo với cơ chế cache:

Ứng dụng sinh ~50 MB mỗi ngày
    nhưng chỉ truy cập MỘT PHẦN cho công việc hằng ngày
        ↓
Phần được dùng thường xuyên → nằm trong CACHE → nhanh như đĩa cục bộ
Phần còn lại                → nằm trên S3     → rẻ, lấy về khi cần

Đây chính là ý nghĩa của "retain the ability to retrieve data with the same low-latency access as the local file share".

Và ứng dụng không cần sửa gì — nó vẫn mount cùng một đường dẫn SMB như trước.

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

• **B. Amazon FSx for Windows File Server — đây là phương án gần nhất và cũng cung cấp SMB, nhưng nó nằm hoàn toàn trên AWS: máy chủ tại chỗ truy cập nó phải đi qua mạng (Direct Connect hoặc VPN), nên không có cache cục bộ và độ trễ cao hơn. (Có FSx File Gateway cho việc đó — nhưng đó lại là Storage Gateway.)
• **C. AWS Snowball Edge — chỉ giải quyết việc di chuyển một lần: nó là thiết bị vận chuyển vật lý. Sau khi dữ liệu vào S3, không còn cơ chế truy cập độ trễ thấp nào cho máy chủ tại chỗ.
• **A. AWS VPN — chỉ là kết nối mạng: nó nối trung tâm dữ liệu với VPC, nhưng không cung cấp lưu trữ, không có cache, không chuyển giao thức. Nó là một mảnh hạ tầng, không phải giải pháp lưu trữ.

Ghi nhớ

Bốn loại AWS Storage Gateway: | Loại | Giao thức | Dữ liệu lưu thành | Dùng cho | |---|---|---|---| | File Gateway (S3) | NFS, SMB | object S3 gốc | chia sẻ tệp lai với cache ← câu này | | FSx File Gateway | SMB | FSx for Windows | truy cập FSx từ tại chỗ có cache | | Volume Gateway | iSCSI (khối) | EBS snapshot | ổ đĩa khối cho ứng dụng | | Tape Gateway | iSCSI VTL | băng ảo | thay thư viện băng vật lý |

Câu hỏi phân biệt:

"SMB", "NFS", "file share", "local cache", "hybrid" → File Gateway "iSCSI block volume" → Volume Gateway "backup software", "virtual tape" → Tape Gateway

Storage Gateway và FSx — khi nào chọn cái nào: | | Storage Gateway | FSx for Windows | |---|---|---| | Vị trí | máy ảo TẠI CHỖ | hoàn toàn trên AWS | | Cache cục bộ | ✅ | ❌ | | Dữ liệu chính nằm ở | S3 | FSx | | Phù hợp | kiến trúc LAI ← câu này | ứng dụng đã chuyển hẳn lên AWS |

Từ khoá quyết định trong đề: "on-premises server" vẫn tồn tại và cần truy cập độ trễ thấp — đó là kiến trúc lai, và Storage Gateway sinh ra cho nó.

Hai chế độ của Volume Gateway — để so sánh: | Chế độ | Dữ liệu chính ở | |---|---| | Cached volumes | S3, cache nóng tại chỗ | | Stored volumes | TẠI CHỖ, sao lưu bất đồng bộ lên S3 |

Ba lưu ý khi triển khai File Gateway: | Lưu ý | Chi tiết | |---|---| | Kích thước cache quyết định trải nghiệm | AWS khuyến nghị tối thiểu 150 GB | | Tích hợp Active Directory cho SMB | phân quyền theo tài khoản domain | | Điều tiết băng thông tải lên | tránh chiếm hết đường truyền giờ làm việc |

Dòng đầu là yếu tố quan trọng nhất: cache quá nhỏ nghĩa là phần lớn lượt đọc phải lấy từ S3 — vừa chậm vừa tốn phí truyền dữ liệu, đúng thứ mà giải pháp muốn tránh.

Ba lợi ích của việc dữ liệu nằm trên S3: | Lợi ích | Chi tiết | |---|---| | Độ bền 11 số 9 | tốt hơn hầu hết hệ thống lưu trữ tại chỗ | | Lifecycle rule | tự chuyển tệp cũ sang Glacier để giảm chi phí | | Truy cập được bằng S3 API | dịch vụ khác trên AWS dùng dữ liệu đó được |

Dòng cuối là lợi ích đáng kể: dữ liệu do File Gateway ghi lên là object S3 gốc (không phải định dạng độc quyền), nên bạn phân tích được bằng Athena, quét bằng Macie, hay xử lý bằng Lambda mà không phải chuyển đổi gì.

Và với ~50 MB mỗi ngày như đề mô tả — khoảng 18 GB một năm — chi phí S3 rất nhỏ. Khoản tiết kiệm thật đến từ việc không phải mua thêm dung lượng cho NAS tại chỗ, và từ lifecycle rule chuyển dữ liệu cũ sang lớp lưu trữ rẻ hơn.

Đáp án

B và E.

• B — Thiết lập Client-Side Encryption với AWS KMS key
• E — Thiết lập Client-Side Encryption dùng client-side master key

Vì sao đúng

Đề nêu một yêu cầu tuyệt đối: việc mã hoá phải được thực hiện TRƯỚC KHI gửi lên S3 — và đó là định nghĩa của client-side encryption.

Hai kiểu client-side encryption, và cả hai đều hợp lệ:

B — Client-side với KMS key:
    Ứng dụng gọi KMS lấy data key
        ↓ mã hoá dữ liệu CỤC BỘ bằng data key
        ↓ chỉ BẢN MÃ được gửi lên S3
    → AWS không bao giờ thấy dữ liệu rõ
    → master key nằm ở KMS

E — Client-side với client-side master key:
    Ứng dụng dùng khoá do BẠN tự sinh và tự lưu
        ↓ mã hoá cục bộ
        ↓ gửi bản mã lên S3
    → AWS không thấy dữ liệu rõ
    → master key KHÔNG BAO GIỜ tới AWS

Bảng đối chiếu với yêu cầu của đề: | Kiểu | Mã hoá trước khi gửi? | Bạn quản lý và xoay vòng khoá? | |---|---|---| | Client-side + KMS key | ✅ | ✅ qua KMS | | Client-side + master key riêng | ✅ | ✅ hoàn toàn | | SSE bất kỳ | ❌ S3 mã hoá sau khi nhận | |

Và vế "spend time managing and rotating the encryption keys as well as controlling who can access those keys" khớp với cả hai: | Kiểu | Cách quản lý khoá | |---|---| | KMS key | key policy kiểm soát ai dùng được, xoay vòng tự động hoặc thủ công | | Client-side master key | bạn tự lo hoàn toàn — kiểm soát tuyệt đối |

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

• **C. Thiết lập Client-Side Encryption với khoá do S3 quản lý — đây là phương án gần nhất và có vế "client-side" đúng, nhưng nó mâu thuẫn nội tại: nếu khoá do S3 quản lý thì việc mã hoá phải diễn ra ở phía S3, tức là server-side. Không có kiểu "client-side với S3 managed key".
• **A. Thiết lập Server-Side Encryption với khoá lưu trong một S3 bucket khác — hai lỗi: đây là server-side, trái yêu cầu mã hoá trước khi gửi; và không có cơ chế nào của SSE lấy khoá từ một bucket khác.
• **D. Thiết lập Server-Side Encryption với EC2 key pair — nhầm hoàn toàn về loại khoá: EC2 key pair dùng để SSH vào instance hoặc lấy mật khẩu Windows. Nó không phải khoá mã hoá dữ liệu và S3 không nhận nó.

Ghi nhớ

Bốn kiểu mã hoá dữ liệu trên S3 — bảng cần thuộc: | Kiểu | Ai mã hoá | Ai giữ khoá | AWS thấy dữ liệu rõ? | |---|---|---|---| | SSE-S3 | S3 | AWS hoàn toàn | ✅ | | SSE-KMS | S3 | bạn qua KMS | ✅ | | SSE-C | S3 | bạn — gửi mỗi request | ✅ | | Client-side (KMS) | ứng dụng | bạn qua KMS | ❌ | | Client-side (master key riêng) | ứng dụng | bạn hoàn toàn | ❌ |

Câu hỏi phân biệt:

"encrypt BEFORE sending to S3", "data must never reach AWS unencrypted" → client-side "cần kiểm toán từng lần dùng khoá" → SSE-KMS "đơn giản nhất" → SSE-S3

Hai kiểu client-side encryption — so sánh: | | Với KMS key | Với master key riêng | |---|---|---| | Master key ở đâu | KMS (trên AWS) | hệ thống của bạn | | Kiểm toán lời gọi khoá | ✅ CloudTrail | ❌ tự lo | | Xoay vòng | KMS hỗ trợ | tự làm | | Mất khoá | KMS bảo quản | mất là mất dữ liệu VĨNH VIỄN | | Phù hợp | hầu hết trường hợp | quy định cấm khoá ở nhà cung cấp |

Công cụ để thực hiện: | Công cụ | Đặc điểm | |---|---| | AWS Encryption SDK | thư viện chuẩn, hỗ trợ nhiều nguồn khoá | | Amazon S3 Encryption Client | tích hợp sẵn với luồng S3 | | Tự viết | không khuyến khích — mã hoá tự viết rất dễ sai |

Ba cái giá của client-side encryption: | Cái giá | Chi tiết | |---|---| | Bạn chịu trách nhiệm hoàn toàn về khoá | mất khoá = mất dữ liệu | | Ứng dụng phức tạp hơn | phải dùng SDK ở mọi nơi đọc ghi | | Dịch vụ phân tích của AWS KHÔNG đọc được | Athena, Macie, S3 Select đều vô dụng với bản mã |

Dòng cuối là hạn chế bị đánh giá thấp nhất: dữ liệu mã hoá phía client là khối byte vô nghĩa với AWS — nên Macie không quét được dữ liệu nhạy cảm trong đó, và bạn mất một công cụ tuân thủ hữu ích.

Ba lớp nên có cho dữ liệu mật: | Lớp | Cơ chế | |---|---| | Mã hoá khi lưu | client-side hoặc SSE-KMS | | Mã hoá khi truyền | bucket policy bắt buộc aws:SecureTransport | | Kiểm soát truy cập | IAM, bucket policy, Block Public Access |

Bucket policy bắt buộc HTTPS:

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

Và một quy trình bắt buộc khi tự quản lý khoá: có kế hoạch sao lưu và khôi phục khoá nghiêm ngặt. Với client-side encryption, AWS không còn là lưới an toàn — mất khoá nghĩa là dữ liệu sao lưu trở thành vô dụng vĩnh viễn, và đó là kịch bản tệ hơn nhiều so với việc không có bản sao lưu nào.

Đáp án

B và D.

• B — Bật EBS Encryption
• D — Bật Server-Side Encryption trên S3 hoặc dùng Client-Side Encryption

Vì sao đúng

Đề nêu hai nơi lưu dữ liệu nhạy cảm, và mỗi đáp án bảo vệ một nơi: | Nơi lưu | Cơ chế | |---|---| | EBS volume của EC2 instance | B — EBS encryption | | S3 bucket (log, giao dịch, sao kê) | D — SSE hoặc CSE |

B — EBS encryption bảo vệ toàn diện và trong suốt:

Bật mã hoá cho volume EBS
    → dữ liệu trên volume: MÃ HOÁ
    → dữ liệu truyền giữa instance và volume: MÃ HOÁ
    → mọi snapshot của volume: MÃ HOÁ
    → mọi volume tạo từ snapshot đó: MÃ HOÁ

Và nó hoàn toàn trong suốt với ứng dụng — không sửa mã, không ảnh hưởng hiệu năng đáng kể.

D — S3 có nhiều lựa chọn mã hoá, và đề chấp nhận cả hai hướng: | Kiểu | Đặc điểm | |---|---| | SSE-S3 | đơn giản nhất, AES-256, mặc định hiện nay | | SSE-KMS | kiểm toán từng lần dùng khoá, kiểm soát bằng key policy | | Client-side | dữ liệu rõ không bao giờ tới AWS |

Với ngân hàng đầu tư và yêu cầu tuân thủ chặt như đề mô tả, SSE-KMS thường là lựa chọn đúng — nó cho dấu vết kiểm toán trong CloudTrail cho mỗi lần giải mã.

Và cả hai đáp án đều thuộc về "mã hoá khi lưu (at rest)" — đúng phạm vi mà đề hỏi.

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

• **C. Chuyển EC2 instance từ public sang private subnet — đây là phương án gần nhất và là biện pháp bảo mật hợp lý, nhưng nó thuộc về bảo mật MẠNG, không phải bảo vệ dữ liệu khi lưu. Đề hỏi cụ thể về "storing sensitive data".
• **E. Dùng AWS Shield và WAF — cùng vấn đề: chúng bảo vệ lưu lượng đến ứng dụng (DDoS, tấn công tầng 7). Chúng không mã hoá hay bảo vệ dữ liệu đã lưu.
• **A. Tạo EBS Snapshot — là biện pháp SAO LƯU, không phải bảo mật: snapshot giúp khôi phục khi mất dữ liệu, nhưng snapshot của volume KHÔNG mã hoá cũng KHÔNG được mã hoá — nó không thêm lớp bảo vệ nào.

Ghi nhớ

Hai mặt của bảo vệ dữ liệu — luôn kiểm cả hai: | Mặt | Cơ chế trên AWS | |---|---| | At rest (khi lưu) | EBS encryption, S3 SSE/CSE, RDS encryption, KMS ← câu này | | In transit (khi truyền) | TLS/HTTPS, VPN IPsec |

Ba đặc điểm của EBS encryption: | Đặc điểm | Chi tiết | |---|---| | Trong suốt với ứng dụng | không sửa mã, ảnh hưởng hiệu năng không đáng kể | | Mã hoá cả snapshot và volume dẫn xuất | tính lan truyền | | Bật mặc định ở mức tài khoản được | ec2:EnableEbsEncryptionByDefault |

Bật mã hoá mặc định là việc nên làm ngay:

aws ec2 enable-ebs-encryption-by-default --region ap-northeast-1
aws ec2 modify-ebs-default-kms-key-id --kms-key-id alias/khoa-ebs-cong-ty

Nó đảm bảo không ai vô tình tạo volume không mã hoá — mạnh hơn việc dựa vào từng launch template nhớ bật.

Lưu ý quan trọng: không mã hoá volume đã có tại chỗ được.

Quy trình:
    ① Chụp snapshot của volume
    ② SAO CHÉP snapshot với tuỳ chọn mã hoá
    ③ Tạo volume mới từ snapshot đã mã hoá
    ④ Tháo volume cũ, gắn volume mới
    → có thời gian ngừng dịch vụ

Nên bật từ đầu tiết kiệm rất nhiều công.

Bốn kiểu mã hoá của S3: | Kiểu | Ai giữ khoá | Kiểm toán | |---|---|---| | SSE-S3 | AWS | không chi tiết | | SSE-KMS | bạn qua KMS | CloudTrail ghi mọi lần dùng khoá | | SSE-C | bạn, gửi mỗi request | | | Client-side | bạn hoàn toàn | tự lo |

Với ngân hàng, SSE-KMS đáng chọn hơn SSE-S3 vì ba lý do:

① Key policy kiểm soát chính xác ai giải mã được
② CloudTrail ghi lại mọi lần dùng khoá — bằng chứng kiểm toán
③ Xoay vòng khoá theo lịch của bạn

Và với SSE-KMS, nhớ bật S3 Bucket Keys — nó giảm mạnh số lời gọi KMS và chi phí mà không đổi mức bảo vệ.

Ba lớp bảo vệ đầy đủ cho dữ liệu tài chính: | Lớp | Cơ chế | |---|---| | Mã hoá at rest | EBS encryption + S3 SSE-KMS ← câu này | | Mã hoá in transit | HTTPS bắt buộc qua bucket policy | | Kiểm soát truy cập | IAM, bucket policy, Block Public Access, VPC endpoint | | Bất biến (nếu cần) | S3 Object Lock cho hồ sơ tuân thủ |

Bucket policy bắt buộc mã hoá khi ghi:

{"Effect": "Deny", "Principal": "*", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::du-lieu-vi-dien-tu/*",
 "Condition": {"StringNotEquals": {
   "s3:x-amz-server-side-encryption": "aws:kms"}}}

Và với sao kê giao dịch — dữ liệu cần giữ theo quy định — cân nhắc thêm S3 Object Lock chế độ COMPLIANCE: nó đảm bảo hồ sơ không bị sửa hay xoá trong thời hạn bắt buộc, kể cả bởi root user.

Ba biện pháp mà C và E đại diện — vẫn nên làm, chỉ là không trả lời câu hỏi này: | Biện pháp | Bảo vệ | |---|---| | Private subnet cho EC2 | giảm bề mặt tấn công mạng | | WAF + Shield | tấn công tầng ứng dụng và DDoS | | VPC endpoint cho S3 | lưu lượng không đi qua Internet |

Đáp án

D — Dùng Multipart Upload.

Vì sao đúng

Đề cho một con số quyết định: tệp lớn nhất là 1 TB — và đó là vượt xa giới hạn của một request PUT thông thường.

Ba giới hạn kích thước của S3 cần thuộc: | Giới hạn | Giá trị | |---|---| | Object tối đa | 5 TB | | MỘT lần PUT tối đa | 5 GB | | Khuyến nghị dùng multipart từ | 100 MB |

Nên với tệp 1 TB, multipart upload không phải tuỳ chọn mà là BẮT BUỘC.

Cách multipart upload hoạt động:

① InitiateMultipartUpload  → nhận uploadId
② UploadPart × N           → tải từng phần SONG SONG (5 MB – 5 GB mỗi phần)
③ CompleteMultipartUpload  → S3 ghép các phần thành một object

Bốn lợi ích, và cả bốn đều quan trọng với tệp lớn: | Lợi ích | Chi tiết | |---|---| | Vượt giới hạn 5 GB | tối đa 10.000 phần × 5 GB = 5 TB | | Tải song song | tận dụng hết băng thông sẵn có | | Thử lại chỉ phần lỗi | không phải tải lại cả 1 TB | | Tạm dừng và tiếp tục | hữu ích với kết nối không ổn định |

Dòng thứ ba là lợi ích lớn nhất trong thực tế: với tệp 1 TB, xác suất gián đoạn giữa chừng là đáng kể — và tải lại từ đầu mỗi lần là không chấp nhận được.

AWS CLI và SDK tự động dùng multipart khi tệp vượt ngưỡng:

aws configure set default.s3.multipart_threshold 100MB
aws configure set default.s3.multipart_chunksize 64MB
aws configure set default.s3.max_concurrent_requests 20

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

• **A. Dùng một request PUT duy nhất để tải tệp lớn — đây là phương án gần nhất về mặt đơn giản, nhưng nó vượt giới hạn kỹ thuật: một PUT tối đa 5 GB. Tệp 1 TB sẽ bị từ chối ngay.
• **B. Dùng AWS Snowball — sai loại nhu cầu: Snowball là thiết bị vật lý vận chuyển bằng bưu điện, dành cho một đợt di chuyển khối lượng lớn. Đây là ứng dụng web nhận tệp từ người dùng liên tục — không thể gửi thiết bị qua bưu điện cho mỗi lượt tải lên.
• **C. Dùng AWS Import/Export — dịch vụ đã lỗi thời: nó là tiền thân của Snow Family, đã ngừng hoạt động. Và cùng vấn đề: nó dành cho di chuyển vật lý, không phải luồng tải lên của ứng dụng.

Ghi nhớ

Ba giới hạn kích thước của S3: | Giới hạn | Giá trị | |---|---| | Object tối đa | 5 TB | | Một lần PUT | 5 GB | | Số phần trong multipart | 1 – 10.000 | | Kích thước mỗi phần | 5 MB – 5 GB (trừ phần cuối cùng) |

Phép tính giới hạn: 10.000 phần × 5 GB = 50 TB, nhưng object bị giới hạn ở 5 TB.

Ba tham số tối ưu cho multipart upload: | Tham số | Ảnh hưởng | |---|---| | multipart_threshold | tệp lớn hơn ngưỡng này mới dùng multipart | | multipart_chunksize | kích thước mỗi phần — lớn hơn thì ít request hơn | | max_concurrent_requests | số phần tải song song — tận dụng băng thông |

Với đường truyền tốc độ cao, tăng max_concurrent_requests là cách hiệu quả nhất — mặc định 10 thường chưa dùng hết đường 1 Gbps trở lên.

Một lifecycle rule BẮT BUỘC cho mọi bucket dùng multipart:

{"Rules": [{
  "Status": "Enabled",
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}
}]}

Vì sao bắt buộc: multipart upload thất bại giữa chừng để lại các phần đã tải, và chúng tính phí lưu trữ MÃI MÃI cho tới khi bị dọn. Với tệp 1 TB và nhiều người dùng, khoản này tích tụ rất nhanh mà không hiện ra trong danh sách object.

# Kiểm tra có phần dở dang nào không
aws s3api list-multipart-uploads --bucket kho-tai-lieu

Ba cách tăng tốc tải lên S3: | Cách | Phù hợp | |---|---| | Multipart upload song song | tệp lớn ← câu này | | S3 Transfer Acceleration | người dùng ở XA Region của bucket | | Snow Family | băng thông hạn chế, khối lượng rất lớn |

Kết hợp multipart với Transfer Acceleration là cấu hình tối ưu cho ứng dụng có người dùng toàn cầu tải tệp lớn — và đề mô tả đúng tình huống đó (người dùng trả phí tải tới 5 TB).

Ba cân nhắc cho kiến trúc tải tệp của ứng dụng web: | Cân nhắc | Cách làm | |---|---| | Đừng cho tệp đi qua máy chủ ứng dụng | dùng pre-signed URL để client tải THẲNG lên S3 | | Giới hạn dung lượng theo loại tài khoản | kiểm tra ở tầng ứng dụng trước khi cấp URL | | Thông báo khi tải xong | S3 event notification → Lambda |

Dòng đầu là mẫu kiến trúc quan trọng: nếu tệp 1 TB đi qua EC2 rồi mới lên S3, bạn cần băng thông và dung lượng đĩa tạm rất lớn. Pre-signed URL cho phép trình duyệt tải thẳng lên S3 — máy chủ chỉ cấp phép, không chạm vào dữ liệu:

url = s3.generate_presigned_url('put_object',
    Params={'Bucket': 'kho-tai-lieu', 'Key': f'{user_id}/{ten_tep}'},
    ExpiresIn=3600)

Và một lưu ý về gói dịch vụ mà đề mô tả: giới hạn 5 GB cho tài khoản miễn phí và 5 TB cho tài khoản trả phí nên được thực thi ở tầng ứng dụng trước khi cấp pre-signed URL — S3 không có cơ chế giới hạn dung lượng theo người dùng.

Đáp án

B — Đặt giá trị của thuộc tính DeleteOnTermination của EBS volume thành False.

Vì sao đúng

Đề nêu yêu cầu rõ: dữ liệu trên root EBS volume phải được giữ lại khi instance bị chấm dứt.

Và DeleteOnTermination là thuộc tính điều khiển chính xác hành vi đó:

DeleteOnTermination = true  (mặc định cho ROOT volume)
    → instance terminate → volume BỊ XOÁ THEO

DeleteOnTermination = false
    → instance terminate → volume VẪN TỒN TẠI
    → chuyển sang trạng thái "available"
    → gắn được vào instance khác

Điểm quan trọng: mặc định khác nhau giữa root volume và volume phụ: | Loại volume | DeleteOnTermination mặc định | |---|---| | Root volume | true — bị xoá cùng instance | | Volume phụ (thêm sau) | false — sống sót |

Đề nói rõ "root EBS volumes" — nên phải đổi mặc định.

Cấu hình trong launch template của Auto Scaling group:

{
  "BlockDeviceMappings": [{
    "DeviceName": "/dev/xvda",
    "Ebs": {
      "VolumeSize": 30,
      "VolumeType": "gp3",
      "DeleteOnTermination": false,
      "Encrypted": true
    }}]}

Hoặc đổi cho instance đang chạy:

aws ec2 modify-instance-attribute --instance-id i-0abc123   --block-device-mappings '[{"DeviceName":"/dev/xvda",
                             "Ebs":{"DeleteOnTermination":false}}]'

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

• **D. Bật Termination Protection cho mọi EC2 instance — đây là phương án gần nhất về mặt cũng liên quan tới việc chấm dứt, nhưng nó ngăn việc TERMINATE, không bảo vệ dữ liệu. Và quan trọng hơn: Auto Scaling KHÔNG tôn trọng termination protection — ASG vẫn chấm dứt instance khi thu hẹp. Nó chỉ chặn việc terminate thủ công qua API.
• **A. Dùng AWS DataSync sao chép dữ liệu root volume sang S3 — nhiều công và không đúng cơ chế: DataSync đồng bộ tệp giữa các hệ thống lưu trữ, và bạn phải dựng agent, lên lịch, xử lý lỗi. Nó không giữ lại chính volume như yêu cầu.
• **C. Cấu hình ASG tạm dừng tiến trình health check cho mỗi instance — giải quyết vấn đề khác: tạm dừng health check ngăn ASG thay thế instance bị coi là không lành mạnh. Nó không bảo vệ dữ liệu khi instance bị chấm dứt vì lý do khác (thu hẹp, người dùng chấm dứt thủ công).

Ghi nhớ

Hành vi mặc định của DeleteOnTermination: | Volume | Mặc định | Lý do | |---|---|---| | Root volume | true | tránh để lại volume mồ côi tốn tiền | | Volume phụ gắn thêm | false | thường chứa dữ liệu quan trọng |

Hệ quả cần lưu ý: đặt false cho root volume nghĩa là volume tích tụ — mỗi lần ASG thay instance để lại một volume available. Cần quy trình dọn dẹp, nếu không chi phí tăng đều đặn.

Ba cách bảo vệ dữ liệu trên EC2 — theo mức phù hợp: | Cách | Đặc điểm | |---|---| | DeleteOnTermination = false | giữ volume nguyên vẹn ← câu này | | EBS snapshot tự động (DLM hoặc AWS Backup) | sao lưu định kỳ, khôi phục được | | Không lưu dữ liệu trên instance | thiết kế tốt nhất — dữ liệu ở S3, EFS, RDS |

Dòng cuối là lời khuyên kiến trúc quan trọng nhất: instance trong Auto Scaling group nên KHÔNG LƯU TRẠNG THÁI. Nếu dữ liệu quan trọng nằm trên root volume, đó thường là dấu hiệu thiết kế cần xem lại.

Nơi lưu trạng thái đúng: | Loại dữ liệu | Nơi lưu | |---|---| | Tệp người dùng | S3 hoặc EFS | | Phiên người dùng | ElastiCache hoặc DynamoDB | | Dữ liệu ứng dụng | RDS, Aurora, DynamoDB | | Log | CloudWatch Logs hoặc S3 |

Ba đặc điểm của EBS volume: | Đặc điểm | Chi tiết | |---|---| | Tồn tại ĐỘC LẬP với instance | (nếu DeleteOnTermination = false) | | Gắn với MỘT Availability Zone | chuyển AZ phải qua snapshot | | Snapshot là phạm vi Region | sao chép chéo Region được |

Termination Protection — làm rõ vì nó hay bị nhầm: | Bảo vệ khỏi | Có hiệu lực | |---|---| | Terminate thủ công qua API/Console | ✅ | | Auto Scaling thu hẹp | ❌ KHÔNG | | Spot Instance bị thu hồi | ❌ | | Instance bị dừng do lỗi phần cứng | ❌ |

Cho Auto Scaling, cơ chế tương ứng là instance scale-in protection — khác hoàn toàn với termination protection.

Ba cách dọn volume mồ côi: | Cách | Chi tiết | |---|---| | AWS Config rule ec2-volume-inuse-check | phát hiện volume không gắn vào đâu | | Lambda theo lịch xoá volume available quá N ngày | tự động hoá | | Gắn tag khi tạo, dọn theo tag | dễ phân biệt volume cố ý giữ |

Và một lựa chọn thay thế đáng cân nhắc cho tình huống của đề: dùng lifecycle hook của Auto Scaling để chụp snapshot trước khi instance bị chấm dứt. Cách này giữ được dữ liệu ở dạng snapshot (rẻ hơn volume available) và không để lại volume tích tụ:

aws autoscaling put-lifecycle-hook   --lifecycle-hook-name chup-snapshot-truoc-khi-tat   --auto-scaling-group-name asg-ung-dung   --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING   --heartbeat-timeout 300

Đáp án

D — Amazon Kinesis Data Streams.

Vì sao đúng

Đề nêu một từ khoá quyết định: "built-in enhanced fan-out feature" — đó là tính năng riêng của Kinesis Data Streams.

Enhanced fan-out giải quyết vấn đề chia sẻ băng thông giữa các consumer:

Standard consumer (chia sẻ):
    Mỗi shard có 2 MB/giây thông lượng đọc
        → CHIA cho MỌI consumer
        → 5 consumer → mỗi cái ~400 KB/giây
        → độ trễ ~200 mili giây

Enhanced fan-out:
    MỖI consumer được 2 MB/giây RIÊNG cho mỗi shard
        → 5 consumer → mỗi cái đủ 2 MB/giây
        → độ trễ ~70 mili giây
        → dùng mô hình ĐẨY (HTTP/2), không phải poll

Với kiến trúc của đề — dữ liệu đi tới CẢ DynamoDB LẪN Redshift — có nhiều consumer, nên enhanced fan-out là cần thiết.

aws kinesis register-stream-consumer   --stream-arn arn:aws:kinesis:...:stream/du-lieu-mang-xa-hoi   --consumer-name consumer-dynamodb

Và "gigabytes per second" khớp với khả năng mở rộng của Kinesis:

Mỗi shard: 1 MB/giây ghi vào
    → cần 1 GB/giây → khoảng 1.000 shard
    → Kinesis hỗ trợ được (có thể cần tăng hạn mức)

Vế "fully-managed" và "LEAST administrative overhead" loại MSK: | | Kinesis Data Streams | Amazon MSK | |---|---|---| | Quản lý | hoàn toàn bởi AWS | bạn quản lý cấu hình Kafka, topic, partition | | Enhanced fan-out | ✅ tính năng gốc | ❌ (Kafka có consumer group, khác cơ chế) | | Công vận hành | thấp | cao hơn |

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

• **C. Amazon Managed Streaming for Apache Kafka (MSK) — đây là phương án gần nhất và cũng xử lý được luồng dữ liệu lớn, nhưng nó thua ở hai điểm: MSK không có "enhanced fan-out" (đó là thuật ngữ riêng của Kinesis); và nó nhiều công vận hành hơn — bạn vẫn phải quản lý topic, partition, cấu hình broker, dù AWS lo hạ tầng.
• **A. Amazon S3 Access Points — sai loại dịch vụ hoàn toàn: access point là cách đơn giản hoá quản lý quyền truy cập S3 bucket. Nó không thu thập hay xử lý luồng dữ liệu.
• **B. AWS Data Exchange — nhầm mục đích: đây là chợ dữ liệu nơi bạn tìm và đăng ký các bộ dữ liệu của bên thứ ba. Nó không phải công cụ nạp luồng dữ liệu của chính bạn.

Ghi nhớ

Hai loại consumer của Kinesis Data Streams: | | Standard (shared) | Enhanced fan-out | |---|---|---| | Thông lượng đọc | 2 MB/giây CHIA cho mọi consumer mỗi shard | 2 MB/giây RIÊNG cho MỖI consumer | | Mô hình | poll (GetRecords) | push (SubscribeToShard, HTTP/2) | | Độ trễ | ~200 mili giây | ~70 mili giây | | Số consumer tối đa | không giới hạn cứng nhưng chia băng thông | 20 mỗi stream | | Chi phí | không phí thêm | tính phí theo consumer-shard-giờ |

Enhanced fan-out đáng dùng khi có từ ba consumer trở lên hoặc khi cần độ trễ thấp — dưới đó, chi phí thêm thường không xứng đáng.

Bốn dịch vụ trong họ Kinesis: | Dịch vụ | Việc | |---|---| | Kinesis Data Streams | hàng đợi luồng, phát lại được, nhiều consumer ← câu này | | Data Firehose | giao dữ liệu tự động vào S3, Redshift, OpenSearch | | Kinesis Video Streams | video và âm thanh | | Managed Service for Apache Flink | xử lý luồng phức tạp |

Thông lượng của một shard: | Chiều | Giới hạn | |---|---| | Ghi vào | 1 MB/giây hoặc 1.000 bản ghi/giây | | Đọc ra (standard) | 2 MB/giây, chia cho mọi consumer | | Đọc ra (enhanced fan-out) | 2 MB/giây mỗi consumer |

Hai chế độ dung lượng của Kinesis Data Streams: | Chế độ | Đặc điểm | |---|---| | Provisioned | bạn khai số shard — rẻ hơn khi tải ổn định | | On-demand | tự mở rộng tới 200 MB/giây — không phải tính shard |

On-demand đáng dùng khi tải khó dự báo — nó tự điều chỉnh và bạn không phải theo dõi metric throttling.

Kinesis Data Streams và Data Firehose — chọn đúng: | | Data Streams | Data Firehose | |---|---|---| | Phát lại (replay) | ✅ giữ 1–365 ngày | ❌ | | Nhiều consumer độc lập | ✅ | ❌ | | Độ trễ | mili giây | tối thiểu ~60 giây | | Viết consumer | có | không cần |

Đề cần nhiều consumer (DynamoDB và Redshift) cùng enhanced fan-out — nên Data Streams là đáp án, dù Firehose đơn giản hơn cho trường hợp một đích.

Ba metric cần giám sát: | Metric | Cảnh báo khi | |---|---| | WriteProvisionedThroughputExceeded | không đủ shard cho lượng ghi | | GetRecords.IteratorAgeMilliseconds | consumer tụt hậu — nguy cơ mất dữ liệu khi hết hạn | | ReadProvisionedThroughputExceeded | quá nhiều consumer standard |

Metric thứ hai quan trọng nhất: nếu tuổi iterator tiến gần thời gian giữ dữ liệu, bản ghi sắp bị xoá trước khi được xử lý.

Và một lưu ý về kiến trúc trong đề: dùng Spot Instance cho ứng dụng xử lý là lựa chọn tiết kiệm hợp lý, nhưng Spot có thể bị thu hồi bất cứ lúc nào. Kinesis giữ dữ liệu (mặc định 24 giờ, tăng được tới 365 ngày) nên instance mới đọc tiếp từ checkpoint được — đó chính là lý do Data Streams phù hợp với kiến trúc dùng Spot hơn là Firehose.