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

Đáp án

C và E — cả hai đều là: dùng Amazon SQS FIFO Queue thay cho standard queue.

Vì sao đúng

Đề mô tả triệu chứng rõ: standard queue khiến nhiều đơn hàng bị xử lý HAI LẦN.

Và đó là hành vi được thiết kế của standard queue:

SQS Standard đảm bảo giao "ÍT NHẤT MỘT LẦN" (at-least-once)
    → thông điệp CÓ THỂ được giao nhiều lần
    → đây không phải lỗi, mà là đánh đổi để có thông lượng vô hạn

FIFO queue giải quyết tận gốc bằng hai cơ chế: | Cơ chế | Việc | |---|---| | Exactly-once processing | mỗi thông điệp được xử lý ĐÚNG MỘT LẦN | | Deduplication trong 5 phút | thông điệp trùng gửi lại bị loại bỏ tự động | | First-In-First-Out | giữ đúng thứ tự trong mỗi message group |

Cách khử trùng lặp hoạt động:

Producer gửi thông điệp kèm MessageDeduplicationId
    → SQS ghi nhớ ID đó trong 5 PHÚT
    → gửi lại cùng ID trong khoảng đó → BỊ BỎ QUA

sqs.send_message(
    QueueUrl=url_hang_doi,
    MessageBody=json.dumps(don_hang),
    MessageGroupId=str(don_hang['ma_khach_hang']),
    MessageDeduplicationId=str(don_hang['ma_don_hang']))

Dùng mã đơn hàng làm MessageDeduplicationId là cách đảm bảo cùng một đơn không bao giờ vào hàng đợi hai lần.

Tạo FIFO queue — tên BẮT BUỘC kết thúc bằng .fifo:

aws sqs create-queue --queue-name xu-ly-don-hang.fifo   --attributes '{"FifoQueue":"true","ContentBasedDeduplication":"true"}'

Ghi nhớ về chất lượng câu hỏi

Phương án C và E có nội dung GIỐNG HỆT NHAU — chỉ khác ở chỗ E viết thêm chữ "Amazon" trước "SQS":

C. "Use an SQS FIFO Queue instead."
E. "Use an Amazon SQS FIFO Queue instead."

Đây là lỗi soạn đề: câu hỏi yêu cầu chọn hai đáp án, nhưng thực chất chỉ có một giải pháp duy nhất được viết ra hai lần. Nếu gặp dạng này trong bài thi, cứ chọn cả hai — nhưng đừng mất thời gian tìm khác biệt giữa chúng, vì không có.

Vì sao ba phương án còn lại sai

• **B. Đổi visibility timeout của SQS — đây là phương án gần nhất và thực sự liên quan tới việc xử lý trùng, nhưng nó chỉ giảm bớt một nguyên nhân, không loại bỏ: visibility timeout quá ngắn khiến thông điệp xuất hiện lại trong khi consumer còn đang xử lý. Tăng nó lên giúp ích, nhưng standard queue vẫn có thể giao trùng vì lý do khác (bản chất phân tán của hệ thống).
• **A. Đổi retention period — giải quyết vấn đề khác: thời hạn giữ quyết định thông điệp tồn tại bao lâu trước khi bị xoá tự động (1 phút – 14 ngày). Nó không ảnh hưởng gì tới việc trùng lặp.
• **D. Đổi kích thước thông điệp — hoàn toàn không liên quan: kích thước tối đa 256 KB (lớn hơn thì dùng SQS Extended Client với S3). Nó không dính gì tới số lần giao.

Ghi nhớ

SQS Standard và SQS FIFO — bảng phân biệt cốt lõi: | | Standard | FIFO | |---|---|---| | Thứ tự | KHÔNG đảm bảo | ✅ trong mỗi message group | | Giao | ít nhất một lần (có thể TRÙNG) | CHÍNH XÁC một lần | | Thông lượng | gần như không giới hạn | 300 TPS (3.000 với batching) | | Khử trùng lặp | ❌ | ✅ cửa sổ 5 phút | | Tên hàng đợi | tuỳ ý | BẮT BUỘC kết thúc .fifo | | Chi phí | thấp hơn | cao hơn một chút |

Đánh đổi cốt lõi: FIFO đổi THÔNG LƯỢNG lấy TÍNH ĐÚNG ĐẮN.

Và với FIFO high throughput mode, giới hạn được nới rất nhiều:

Bật high throughput:
    → 9.000 TPS (không batching)
    → 90.000 TPS (có batching)
    → điều kiện: nhiều message group khác nhau

Hai tham số bắt buộc khi gửi vào FIFO queue: | Tham số | Việc | |---|---| | MessageGroupId | thứ tự được đảm bảo TRONG cùng group | | MessageDeduplicationId | định danh để khử trùng lặp |

MessageGroupId là chìa khoá để có cả thứ tự lẫn thông lượng:

MessageGroupId = một giá trị cố định
    → thứ tự tuyệt đối toàn hàng đợi
    → nhưng xử lý TUẦN TỰ, thông lượng thấp

MessageGroupId = mã khách hàng
    → thứ tự được giữ CHO TỪNG KHÁCH HÀNG
    → các khách hàng khác nhau xử lý SONG SONG   ← thường là lựa chọn đúng

ContentBasedDeduplication là tuỳ chọn tiện:

Bật lên → SQS tự băm SHA-256 nội dung thông điệp làm dedup ID
    → không phải tự sinh ID
    → nhưng hai đơn hàng nội dung GIỐNG HỆT sẽ bị coi là trùng

Với đơn hàng, nên tự khai MessageDeduplicationId bằng mã đơn — an toàn hơn.

Ba cấu hình quan trọng khác của SQS: | Cấu hình | Ý nghĩa | Giá trị | |---|---|---| | VisibilityTimeout | thời gian thông điệp bị ẩn sau khi được nhận | phải ≥ thời gian xử lý | | MessageRetentionPeriod | giữ bao lâu nếu chưa ai xoá | 1 phút – 14 ngày | | ReceiveMessageWaitTimeSeconds | long polling | 20 giây — giảm chi phí lời gọi |

Và dead-letter queue là cấu hình nên có cho mọi hàng đợi sản xuất:

{"RedrivePolicy": "{\"deadLetterTargetArn\":\"<arn-dlq>\",
                    \"maxReceiveCount\":\"3\"}"}

Thông điệp xử lý thất bại 3 lần được chuyển sang DLQ — nếu không, nó quay lại hàng đợi mãi và chặn tiến độ.

Ngay cả với FIFO, consumer vẫn nên IDEMPOTENT:

def xu_ly_don_hang(don):
    if da_xu_ly(don['ma_don_hang']):   # kiểm tra trong DynamoDB
        return
    thuc_hien(don)
    danh_dau_da_xu_ly(don['ma_don_hang'])

Vì sao vẫn cần: FIFO đảm bảo giao chính xác một lần, nhưng nếu consumer xử lý xong rồi chết trước khi kịp xoá thông điệp, nó sẽ nhận lại thông điệp đó. Idempotency là lớp bảo vệ cuối cùng.

Và một lưu ý về việc chuyển đổi: không đổi standard queue thành FIFO được — phải tạo hàng đợi mới với tên kết thúc .fifo rồi chuyển producer và consumer sang. Hãy lên kế hoạch cho giai đoạn chuyển tiếp, khi cả hai hàng đợi cùng tồn tại.

Đáp án

A — Cấu hình AWS Config để chạy đánh giá kiểm tra tuân thủ chính sách mật khẩu định kỳ.

Vì sao đúng

Đề cần tự động kiểm tra và đánh giá xem chính sách mật khẩu của tài khoản có tuân thủ quy định của công ty hay không — và AWS Config có sẵn managed rule cho đúng việc đó.

iam-password-policy là rule dựng sẵn, chỉ cần khai tham số:

{"ConfigRuleName": "kiem-tra-chinh-sach-mat-khau",
 "Source": {"Owner": "AWS", "SourceIdentifier": "IAM_PASSWORD_POLICY"},
 "InputParameters": "{
    \"MinimumPasswordLength\": \"12\",
    \"RequireUppercaseCharacters\": \"true\",
    \"RequireNumbers\": \"true\",
    \"RequireSymbols\": \"true\",
    \"MaxPasswordAge\": \"90\"}"}

Bốn việc AWS Config làm sẵn: | Việc | Chi tiết | |---|---| | Đánh giá ĐỊNH KỲ và LIÊN TỤC | không cần lịch tự viết | | Bảng điều khiển tuân thủ | thấy ngay COMPLIANT hay NON_COMPLIANT | | Lịch sử cấu hình | biết chính sách thay đổi lúc nào | | Tự động khắc phục | gắn SSM Automation để tự sửa lại chính sách |

Và có sẵn remediation document cho việc này:

{"TargetType": "SSM_DOCUMENT",
 "TargetId": "AWSConfigRemediation-SetIAMPasswordPolicy",
 "Automatic": true}

Chuyển từ "phát hiện" sang "tự sửa" mà không viết dòng mã nào.

Và một điểm quan trọng mà đề ẩn ý: chính sách mật khẩu là cấu hình Ở MỨC TÀI KHOẢN, không phải của từng người dùng.

aws iam update-account-password-policy --minimum-password-length 12

Đặt chính sách này là mọi người dùng bị áp ngay — đó mới là cách thực thi đúng, còn Config là cơ chế canh chừng để nó không bị đổi.

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

• **C. Tạo Lambda function theo lịch chạy script kiểm tra tuân thủ — đây là phương án gần nhất và hoạt động được, nhưng nó nhiều công hơn: phải viết mã, dựng lịch, xử lý lỗi, tự làm cơ chế báo cáo. AWS Config đã có tất cả những thứ đó dưới dạng managed rule.
• **B. Tạo CloudTrail trail lọc theo ChangePassword để xem danh sách người đã đổi mật khẩu — trả lời câu hỏi khác: nó cho biết AI ĐÃ ĐỔI mật khẩu, chứ không đánh giá chính sách hiện tại có tuân thủ hay không. Một người có thể đổi mật khẩu mà vẫn đặt mật khẩu ngắn.
• **D. Tạo CloudWatch Events rule khớp sự kiện ChangePassword rồi gửi SNS — cùng vấn đề: nó phản ứng với sự kiện đổi mật khẩu, không đánh giá tính tuân thủ. Và nó gửi thông báo cho mỗi lần đổi mật khẩu — phần lớn là hợp lệ, tạo ra rất nhiều nhiễu.

Ghi nhớ

Vai trò của ba dịch vụ — đừng nhầm: | Dịch vụ | Câu hỏi nó trả lời | |---|---| | AWS Config | "cấu hình hiện tại có ĐÚNG QUY ĐỊNH không?" | | CloudTrail | "AI đã làm gì, lúc nào?" | | CloudWatch | "hệ thống đang chạy thế nào?" |

Đề hỏi "check and EVALUATE whether the current password policy COMPLIES" — đó chính xác là vai trò của Config.

Các managed rule của Config liên quan tới IAM: | Rule | Kiểm tra | |---|---| | iam-password-policy | chính sách mật khẩu của tài khoản ← câu này | | iam-user-mfa-enabled | người dùng đã bật MFA chưa | | access-keys-rotated | access key quá N ngày chưa xoay | | iam-user-unused-credentials-check | thông tin đăng nhập không dùng | | iam-root-access-key-check | root có access key không — nên là KHÔNG | | mfa-enabled-for-iam-console-access | MFA cho truy cập Console |

AWS Config có hơn 300 managed rule — hãy tìm rule sẵn có trước khi viết custom rule.

Các tuỳ chọn của chính sách mật khẩu IAM: | Tuỳ chọn | Ý nghĩa | |---|---| | MinimumPasswordLength | 6–128 ký tự | | RequireUppercase/Lowercase/Numbers/Symbols | yêu cầu loại ký tự | | MaxPasswordAge | buộc đổi sau N ngày | | PasswordReusePrevention | không cho dùng lại N mật khẩu gần nhất (tới 24) | | AllowUsersToChangePassword | người dùng tự đổi được | | HardExpiry | hết hạn thì phải nhờ quản trị viên đặt lại |

Hai cơ chế kích hoạt đánh giá của Config rule: | Cơ chế | Khi nào chạy | |---|---| | Configuration change | ngay khi tài nguyên thay đổi | | Periodic | theo chu kỳ — iam-password-policy dùng kiểu này |

Vì sao là periodic: chính sách mật khẩu là cấu hình mức tài khoản, không phải một tài nguyên phát sự kiện thay đổi cấu hình như EC2 hay S3.

Ba loại rule trong AWS Config: | Loại | Đặc điểm | |---|---| | Managed rule | hơn 300 rule dựng sẵn ← nên dùng | | Custom rule (Lambda) | logic riêng bằng mã | | Custom Policy rule (Guard) | viết bằng ngôn ngữ Guard, không cần Lambda |

Và một cách mạnh hơn để THỰC THI thay vì chỉ phát hiện: Service Control Policy.

{"Effect": "Deny",
 "Action": "iam:UpdateAccountPasswordPolicy",
 "Resource": "*"}

SCP ngăn không cho ai đổi chính sách mật khẩu — kể cả người có quyền quản trị trong tài khoản thành viên. Đây là biện pháp phòng ngừa; Config là biện pháp phát hiện. Kiến trúc tốt có cả hai.

Và giải pháp căn bản nhất cho tình huống của đề: bỏ IAM user, dùng IAM Identity Center.

Nhân viên đăng nhập bằng danh tính doanh nghiệp (AD, Okta, Entra ID)
    → chính sách mật khẩu do hệ thống danh tính đó quản lý
    → nhất quán với toàn công ty
    → thông tin đăng nhập AWS là TẠM THỜI, tự hết hạn
    → không còn mật khẩu IAM để mà kiểm tra

Ba lưu ý về chi phí AWS Config: | Khoản | Chi tiết | |---|---| | Mục cấu hình được ghi | theo số bản ghi | | Số lần đánh giá rule | theo số lần chạy | | Conformance pack | gói nhiều rule theo chuẩn (PCI-DSS, HIPAA) |

Conformance pack đáng biết: thay vì bật từng rule một, bạn triển khai cả gói tương ứng với một chuẩn tuân thủ — AWS có sẵn gói cho CIS Benchmark, PCI-DSS, HIPAA và nhiều chuẩn khác.

Đáp án

A — Dùng AWS DataSync agent để di chuyển dữ liệu nhanh chóng qua service endpoint.

Vì sao đúng

Đề nêu ba yêu cầu, và DataSync đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Giải pháp được QUẢN LÝ HOÀN TOÀN | DataSync là dịch vụ managed, không tự viết script | | TỰ ĐỘNG HOÁ và TĂNG TỐC sao chép | giao thức riêng, nhanh hơn công cụ mã nguồn mở tới 10 lần | | Sao chép ĐẾN VÀ TỪ nhiều dịch vụ lưu trữ AWS | S3, EFS, FSx đều hỗ trợ |

Và vế "over a service endpoint" là chi tiết quyết định:

Đề nói rõ tổ chức có AWS DIRECT CONNECT
    ↓
Muốn lưu lượng DataSync đi qua Direct Connect:
    → agent phải kết nối tới VPC ENDPOINT của DataSync
    → chứ không phải endpoint công khai qua Internet

So sánh hai đường đi:

Qua Internet:
    Agent → Internet công cộng → endpoint công khai của DataSync
        → bỏ phí kết nối DX đã trả tiền
        → băng thông và độ trễ không ổn định

Qua service endpoint (VPC endpoint):
    Agent → Direct Connect → VPC endpoint → DataSync
        → dùng đúng đường dành riêng
        → nhất quán, an toàn, không qua Internet

Cấu hình:

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc123   --service-name com.amazonaws.ap-southeast-1.datasync   --vpc-endpoint-type Interface --subnet-ids subnet-0abc

aws datasync create-agent --activation-key <ma-kich-hoat>   --vpc-endpoint-id vpce-0abc123   --subnet-arns arn:aws:ec2:...:subnet/subnet-0abc   --security-group-arns arn:aws:ec2:...:security-group/sg-0abc

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

• **C. Dùng DataSync agent để di chuyển dữ liệu qua Internet — đây là phương án gần nhất và chỉ khác đúng một cụm từ, nhưng cụm từ đó phủ nhận toàn bộ lý do tổ chức đầu tư vào Direct Connect. Đề nêu DX ngay câu đầu — đi qua Internet là bỏ phí nó.
• **D. Dùng Storage Gateway file gateway với giao thức SMB — sai loại nhu cầu: file gateway phục vụ TRUY CẬP liên tục (dùng như ổ đĩa mạng, dữ liệu ở AWS). Đề cần DI CHUYỂN dữ liệu một cách tự động và nhanh — đó là việc của DataSync.
• **B. Dùng Storage Gateway tape gateway lưu lên băng ảo — sai mục đích: tape gateway thay thế thư viện băng từ vật lý, phục vụ sao lưu qua phần mềm backup truyền thống. Nó không phải công cụ đồng bộ dữ liệu tốc độ cao.

Ghi nhớ

DataSync và Storage Gateway — bảng phân biệt cốt lõi: | | AWS DataSync | AWS Storage Gateway | |---|---|---| | Mục đích | DI CHUYỂN / ĐỒNG BỘ dữ liệu | TRUY CẬP dữ liệu liên tục | | Mô hình | chạy theo tác vụ (task), một lần hoặc theo lịch | thường trực, như ổ đĩa mạng | | Tốc độ | tối ưu, nhanh hơn rsync/scp nhiều lần | phụ thuộc cache | | Đích | S3, EFS, FSx | S3, Glacier, FSx | | Xác minh dữ liệu | ✅ tự kiểm tra tính toàn vẹn | — |

Chúng bổ sung nhau: DataSync chuyển khối lượng ban đầu, Storage Gateway phục vụ truy cập hằng ngày sau đó.

Bốn đặc điểm của DataSync: | Đặc điểm | Chi tiết | |---|---| | Nhanh hơn công cụ mã nguồn mở tới 10 lần | giao thức riêng, nén và truyền song song | | Tự xác minh tính toàn vẹn | so checksum sau khi truyền | | Giữ metadata | quyền, timestamp, ACL | | Điều tiết băng thông | đặt giới hạn để không nghẽn giờ làm việc |

Nguồn và đích mà DataSync hỗ trợ: | Nguồn | Đích | |---|---| | NFS, SMB tại chỗ | S3 (mọi lớp), EFS, FSx for Windows, FSx for Lustre | | HDFS | FSx for OpenZFS, FSx for NetApp ONTAP | | Object storage tương thích S3 | | | AWS sang AWS | S3 ↔ EFS ↔ FSx, kể cả xuyên Region và xuyên tài khoản |

Dòng cuối đáng biết: DataSync không chỉ dùng cho di chuyển từ tại chỗ — nó cũng là công cụ tốt để đồng bộ giữa các dịch vụ lưu trữ trong AWS.

Ba cách kết nối agent với AWS: | Cách | Đặc điểm | |---|---| | VPC endpoint (PrivateLink) | qua Direct Connect hoặc VPN — không ra Internet ← câu này | | Endpoint công khai | qua Internet | | FIPS endpoint | cho yêu cầu tuân thủ liên bang Mỹ |

Ba loại virtual interface của Direct Connect — liên quan tới cách chọn endpoint: | Loại VIF | Dùng để | |---|---| | Private VIF | vào VPC riêng tư — dùng với VPC endpoint | | Public VIF | truy cập dịch vụ công khai của AWS qua DX | | Transit VIF | vào Transit Gateway |

Cả private VIF (kèm VPC endpoint) lẫn public VIF đều giữ lưu lượng trên Direct Connect — nhưng private VIF + VPC endpoint là cách được khuyến nghị vì lưu lượng hoàn toàn riêng tư.

Các dịch vụ di chuyển dữ liệu của AWS — chọn đúng: | Dịch vụ | Phù hợp | |---|---| | DataSync | đồng bộ tệp qua mạng, tự động, nhanh ← câu này | | Storage Gateway | truy cập lai liên tục | | Snow Family | khối lượng rất lớn, băng thông kém — gửi thiết bị vật lý | | Transfer Family | endpoint SFTP/FTPS cho đối tác bên ngoài | | DMS | cơ sở dữ liệu | | MGN | máy chủ nguyên khối (lift-and-shift) |

Quy tắc ước lượng: nếu truyền qua mạng mất hơn một tuần, hãy cân nhắc Snow Family.

Ba cấu hình quan trọng của DataSync task: | Cấu hình | Việc | |---|---| | Bandwidth throttle | giới hạn tốc độ theo lịch | | Verification mode | kiểm tra toàn bộ, chỉ dữ liệu mới, hoặc không | | Transfer mode | chỉ tệp thay đổi, hoặc toàn bộ | | Filter | bao gồm hoặc loại trừ theo mẫu đường dẫn |

Chế độ "chỉ tệp thay đổi" khiến các lần chạy sau rất nhanh — DataSync so sánh metadata và chỉ truyền phần khác biệt.

Và một lưu ý về chi phí: DataSync tính phí theo dữ liệu được truyền (~0,0125 USD/GB), cộng chi phí của VPC endpoint nếu dùng. Với việc di chuyển một lần khối lượng lớn, hãy tính trước — và so sánh với chi phí Snowball nếu dung lượng lên tới hàng trăm terabyte.

Đáp án

A — Tạo standby replica ở Availability Zone khác bằng cách bật Multi-AZ deployment.

Vì sao đúng

Đề nêu hai yêu cầu, và Multi-AZ là cơ chế duy nhất đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | TỰ ĐỘNG chuyển đổi sang instance khác khi có sự cố | Multi-AZ tự failover, không cần người can thiệp | | Sẵn sàng cao nhất có thể | standby ở AZ khác, sao chép đồng bộ |

Cách Multi-AZ hoạt động:

Primary (AZ-a)  ──sao chép ĐỒNG BỘ──▶  Standby (AZ-b)
    → mọi giao dịch được ghi vào CẢ HAI trước khi xác nhận
    → dữ liệu ở standby LUÔN GIỐNG HỆT primary
        ↓
Primary hỏng:
    → RDS TỰ ĐỘNG chuyển endpoint DNS sang standby
    → thường hoàn tất trong 60–120 GIÂY
    → ứng dụng không phải đổi chuỗi kết nối

Điểm mấu chốt: endpoint DNS không đổi.

db-ung-dung.abc123.ap-southeast-1.rds.amazonaws.com
    → trước failover trỏ tới instance ở AZ-a
    → sau failover trỏ tới instance ở AZ-b
    → ứng dụng chỉ cần kết nối lại, không sửa cấu hình

Và sao chép đồng bộ đảm bảo KHÔNG MẤT DỮ LIỆU:

Read replica (bất đồng bộ):
    primary hỏng → các giao dịch chưa kịp sao chép BỊ MẤT

Multi-AZ (đồng bộ):
    giao dịch chỉ được xác nhận khi CẢ HAI đã ghi
    → RPO = 0

aws rds modify-db-instance --db-instance-identifier db-ung-dung   --multi-az --apply-immediately

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

• **B. Tạo read replica cùng Region và một read replica xuyên Region, khi có sự cố thì promote một replica lên làm primary — đây là phương án gần nhất và cung cấp khả năng phục hồi tốt, nhưng nó KHÔNG TỰ ĐỘNG: promote là thao tác thủ công, cần người phát hiện sự cố rồi thực hiện. Đề yêu cầu "automatically failover". Và sao chép bất đồng bộ nghĩa là có thể mất dữ liệu.
• **C. Tạo năm read replica ở các AZ khác nhau rồi promote khi cần — cùng vấn đề: promote thủ công, sao chép bất đồng bộ. Và năm replica là chi phí lớn cho mục đích sẵn sàng cao — replica sinh ra để mở rộng đọc, không phải để failover.
• **D. Tạo năm read replica xuyên Region ở mỗi Region — đắt nhất và vẫn thủ công: chi phí instance nhân lên rất nhiều, cộng phí truyền dữ liệu xuyên Region liên tục, mà vẫn không có failover tự động.

Ghi nhớ

Multi-AZ và Read Replica — bảng phân biệt cốt lõi: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC | | Sao chép | ĐỒNG BỘ | bất đồng bộ | | Failover | TỰ ĐỘNG (60–120 giây) | THỦ CÔNG (promote) | | Mất dữ liệu khi sự cố | KHÔNG (RPO = 0) | có thể mất | | Instance thứ hai phục vụ đọc | ❌ KHÔNG | ✅ | | Vị trí | AZ khác cùng Region | cùng AZ, khác AZ, hoặc khác Region | | Số lượng | 1 standby | tới 5 (RDS) / 15 (Aurora) |

"Standby của Multi-AZ không phục vụ đọc" là bẫy xuất hiện rất thường xuyên trong đề thi.

Và chúng bổ sung nhau — kiến trúc sản xuất dùng cả hai:

Primary (Multi-AZ)  ──đồng bộ──▶  Standby        (sẵn sàng cao)
      │
      └──bất đồng bộ──▶  Read replica × N        (mở rộng đọc)

Các sự kiện kích hoạt failover tự động: | Sự kiện | Có failover không | |---|---| | Mất kết nối AZ chứa primary | ✅ | | Lỗi phần cứng của primary | ✅ | | Lỗi mạng của primary | ✅ | | Đổi loại instance | ✅ (trong quá trình bảo trì) | | Vá lỗi hệ điều hành | ✅ | | Bấm nút Reboot with failover | ✅ (dùng để diễn tập) |

Nút "Reboot with failover" rất hữu ích để diễn tập — nó cho bạn đo thời gian failover thật và kiểm chứng ứng dụng có kết nối lại đúng không.

Hai loại triển khai Multi-AZ của RDS: | Loại | Đặc điểm | |---|---| | Multi-AZ DB instance | 1 primary + 1 standby (standby không đọc được) | | Multi-AZ DB cluster | 1 writer + 2 READER (đọc được!), failover dưới 35 giây |

Multi-AZ DB cluster là lựa chọn mới đáng chú ý — nó kết hợp cả sẵn sàng cao lẫn mở rộng đọc trong một cấu hình, và failover nhanh hơn. Hiện hỗ trợ MySQL và PostgreSQL.

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Chi phí GẤP ĐÔI | trả tiền cho cả hai instance | | Độ trễ ghi cao hơn | phải chờ standby xác nhận | | Sao lưu và bảo trì diễn ra trên standby | không ảnh hưởng hiệu năng primary |

Dòng cuối là lợi ích ít được nhắc tới: với Single-AZ, việc chụp snapshot gây tạm dừng I/O; với Multi-AZ thì không.

Ba cấu hình ứng dụng cần có để failover hoạt động trơn tru: | Cấu hình | Lý do | |---|---| | Dùng ENDPOINT DNS, không hard-code IP | IP đổi sau failover | | Đặt TTL cache DNS của JVM ngắn | Java mặc định cache DNS vĩnh viễn | | Có cơ chế thử lại kết nối | failover mất 60–120 giây |

Dòng giữa là cạm bẫy kinh điển với ứng dụng Java:

java.security.Security.setProperty("networkaddress.cache.ttl", "5");

Không đặt thì ứng dụng vẫn gọi tới IP cũ mãi sau khi failover xong — triệu chứng là database đã khôi phục mà ứng dụng vẫn báo lỗi kết nối.

Và với Aurora, cơ chế khác và tốt hơn: | | RDS Multi-AZ | Aurora | |---|---|---| | Kiến trúc | 2 instance, 2 bản dữ liệu | tầng lưu trữ chung, 6 bản qua 3 AZ | | Failover | 60–120 giây | dưới 30 giây | | Replica phục vụ đọc | ❌ | ✅ tới 15 | | Replica làm mục tiêu failover | — | ✅ tự động chọn |

Và một lời khuyên vận hành: hãy diễn tập failover định kỳ bằng nút "Reboot with failover" vào giờ thấp điểm. Nó cho biết thời gian ngừng thật của ứng dụng và phát hiện các vấn đề như DNS cache hay thiếu cơ chế thử lại — trước khi sự cố thật xảy ra.

Đáp án

B — Cài unified CloudWatch agent lên các EC2 instance; lưu cấu hình agent trong Systems Manager Parameter Store để tạo metric tổng hợp về phần trăm dùng bộ nhớ; co giãn Auto Scaling group theo metric tổng hợp đó.

Vì sao đúng

Đề mô tả triệu chứng chính xác: ASG không mở rộng dù bộ nhớ đã cao — và nguyên nhân nằm ở một sự thật cốt lõi về CloudWatch.

CloudWatch KHÔNG tự biết mức dùng bộ nhớ của EC2:

CloudWatch thu thập metric từ TẦNG HYPERVISOR (bên ngoài máy ảo)
    → thấy được: CPU, mạng, I/O đĩa ở mức thiết bị
    → KHÔNG thấy được: bộ nhớ, dung lượng đĩa còn trống, tiến trình
        ↓ vì những thứ đó nằm BÊN TRONG hệ điều hành
    → phải có AGENT chạy trong máy mới thu thập được

Nên ASG không mở rộng được là hoàn toàn hợp lý — không có metric bộ nhớ nào tồn tại để mà co giãn theo.

Ba bước của giải pháp:

① Cài unified CloudWatch agent lên instance
② Cấu hình agent phát metric mem_used_percent kèm dimension
   AutoScalingGroupName → tạo METRIC TỔNG HỢP cho cả nhóm
③ Tạo scaling policy theo metric tuỳ chỉnh đó

Cấu hình agent — điểm mấu chốt là append_dimensions:

{"metrics": {
   "namespace": "UngDungWeb",
   "append_dimensions": {"AutoScalingGroupName": "${aws:AutoScalingGroupName}"},
   "aggregation_dimensions": [["AutoScalingGroupName"]],
   "metrics_collected": {
     "mem": {"measurement": ["mem_used_percent"], "metrics_collection_interval": 60}}}}

aggregation_dimensions tạo ra metric TỔNG HỢP của cả nhóm — đó là thứ scaling policy cần, chứ không phải metric của từng máy riêng lẻ.

Và Parameter Store cho phép một cấu hình dùng chung cho cả đội máy:

aws ssm put-parameter --name "AmazonCloudWatch-cau-hinh-bo-nho"   --type String --value file://cau-hinh.json

aws ssm send-command --document-name "AmazonCloudWatch-ManageAgent"   --targets "Key=tag:aws:autoscaling:groupName,Values=asg-ung-dung"   --parameters '{"action":["configure"],
                 "optionalConfigurationSource":["ssm"],
                 "optionalConfigurationLocation":["AmazonCloudWatch-cau-hinh-bo-nho"]}'

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

• **C. Bật detailed monitoring trên EC2 rồi dùng custom metric để co giãn theo bộ nhớ tổng hợp — đây là phương án gần nhất và vế custom metric đúng, nhưng nó hiểu sai detailed monitoring: detailed monitoring chỉ rút chu kỳ thu thập từ 5 phút xuống 1 phút cho các metric đã có sẵn. Nó KHÔNG thêm metric bộ nhớ. Và phương án không nói cách nào để có được metric đó.
• **A. Dùng Amazon Comprehend theo dõi bộ nhớ và SageMaker AI kích hoạt co giãn — sai hoàn toàn về vai trò dịch vụ: Comprehend là NLP xử lý văn bản, SageMaker là nền tảng học máy. Không cái nào giám sát hạ tầng.
• **D. Dùng Amazon Rekognition nhận diện nguyên nhân dùng nhiều bộ nhớ và Well-Architected Tool kích hoạt mở rộng — cũng sai vai trò: Rekognition phân tích ẢNH và VIDEO; Well-Architected Tool là công cụ rà soát kiến trúc thủ công, nó không kích hoạt hành động nào.

Ghi nhớ

Metric nào có sẵn, metric nào cần agent — bảng cần thuộc: | Metric | Cần agent | |---|---| | CPUUtilization | ❌ có sẵn | | NetworkIn / NetworkOut | ❌ có sẵn | | DiskReadOps / DiskWriteOps (mức thiết bị) | ❌ có sẵn | | StatusCheckFailed | ❌ có sẵn | | Mức dùng BỘ NHỚ | ✅ CẦN AGENT | | Dung lượng đĩa còn TRỐNG (mức hệ thống tệp) | ✅ CẦN AGENT | | Số tiến trình, swap | ✅ cần agent |

Hai dòng in đậm là lý do câu hỏi này tồn tại — và là nguyên nhân của rất nhiều hệ thống "không tự mở rộng được".

Basic và Detailed monitoring — làm rõ vì phương án C nhắc tới: | | Basic | Detailed | |---|---|---| | Chu kỳ | 5 phút | 1 phút | | Chi phí | miễn phí | có phí | | Thêm metric mới | — | ❌ KHÔNG — chỉ tăng tần suất |

Detailed monitoring hữu ích khi cần phản ứng nhanh với thay đổi tải, nhưng nó không giải quyết vấn đề của đề.

Bốn loại scaling policy của Auto Scaling: | Loại | Cách hoạt động | |---|---| | Target tracking | giữ metric ở một giá trị mục tiêu — đơn giản nhất | | Step scaling | thêm/bớt theo bậc tuỳ mức vượt ngưỡng | | Simple scaling | một hành động, có thời gian chờ | | Predictive scaling | dự báo tải và mở rộng TRƯỚC |

Target tracking với metric tuỳ chỉnh cho bộ nhớ:

{"TargetValue": 70.0,
 "CustomizedMetricSpecification": {
   "MetricName": "mem_used_percent",
   "Namespace": "UngDungWeb",
   "Dimensions": [{"Name": "AutoScalingGroupName", "Value": "asg-ung-dung"}],
   "Statistic": "Average"}}

Ba lưu ý khi co giãn theo bộ nhớ: | Lưu ý | Chi tiết | |---|---| | Phải dùng metric TỔNG HỢP của nhóm | metric từng máy không dùng để co giãn nhóm được | | Chọn ngưỡng thấp hơn CPU | bộ nhớ đầy gây swap và chậm nghiêm trọng, khó phục hồi | | Kiểm tra xem có RÒ RỈ BỘ NHỚ không | mở rộng thêm máy không chữa được rò rỉ |

Dòng cuối rất quan trọng với "ứng dụng web legacy" như đề mô tả: nếu bộ nhớ tăng đều theo thời gian và không bao giờ giảm, đó là rò rỉ — thêm máy chỉ làm chậm lại thời điểm sập chứ không giải quyết. Khi đó cách chữa tạm là thay instance định kỳ (instance refresh theo lịch), còn cách chữa thật là sửa ứng dụng.

Ba cấu hình khác nên kiểm tra khi ASG không mở rộng: | Cấu hình | Kiểm tra | |---|---| | MaxSize | đã chạm trần chưa | | Cooldown period | quá dài thì phản ứng chậm | | Health check grace period | quá ngắn thì máy mới bị coi là hỏng và bị thay liên tục |

Và một điểm cần lưu ý về FSx for OpenZFS trong kiến trúc của đề: nếu ứng dụng chậm vì I/O tới file system chứ không phải vì bộ nhớ của instance, thì thêm máy không giúp gì. Hãy kiểm tra metric throughput và IOPS của FSx trước khi kết luận nguyên nhân — "basic monitoring" mà đề nhắc tới cũng là dấu hiệu rằng phần giám sát FSx đang rất sơ sài.

Và một lời khuyên chung: cài unified CloudWatch agent ngay từ AMI hoặc user data cho mọi instance sản xuất. Metric bộ nhớ và dung lượng đĩa là hai thứ cơ bản nhất mà lại không có mặc định — và người ta thường chỉ phát hiện ra điều đó khi đang cần chúng nhất.

Đáp án

B — Bật IAM Identity Center với thư mục Identity Center; tạo permission set cấp quyền chi tiết cho Aurora và EFS; gán các đội vào nhóm liên kết với permission set tương ứng.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này đáp ứng cả ba với ít công nhất: | Yêu cầu | Cơ chế | |---|---| | Tổ chức ĐÃ triển khai IAM Identity Center | tận dụng thứ đã có, không dựng hệ thống song song | | Ba đội cần quyền khác nhau, theo quyền tối thiểu | permission set riêng cho từng vai trò | | Giảm thiểu công quản trị | gán theo NHÓM, không theo từng người |

Mô hình permission set + group là cách mở rộng được:

Permission set "khoa-hoc-du-lieu"  → quyền đọc Aurora + đọc EFS
Permission set "ky-thuat"          → quyền đầy đủ Aurora + EFS
Permission set "tuan-thu"          → chỉ đọc, kèm quyền xem log
        ↓
Nhóm "DoiKhoaHocDuLieu"  → gán permission set tương ứng
        ↓
Thêm người mới = thêm vào NHÓM
    → không phải tạo IAM user, không phải gắn policy riêng

Và thông tin đăng nhập là TẠM THỜI:

Người dùng đăng nhập qua portal của Identity Center
    → nhận thông tin đăng nhập ngắn hạn qua STS
    → tự hết hạn
    → KHÔNG có access key dài hạn nào để rò rỉ

Nhân viên nghỉ việc: vô hiệu hoá ở một chỗ, mất quyền ở mọi tài khoản AWS.

Ví dụ permission set cho đội khoa học dữ liệu:

{"Effect": "Allow",
 "Action": ["rds-db:connect"],
 "Resource": "arn:aws:rds-db:*:*:dbuser:cluster-ABC/nguoi_doc"}

{"Effect": "Allow",
 "Action": ["elasticfilesystem:ClientMount"],
 "Resource": "arn:aws:elasticfilesystem:*:*:file-system/fs-0abc",
 "Condition": {"StringEquals": {"elasticfilesystem:AccessPointArn": "<arn-access-point>"}}}

Chú ý ClientMount mà không có ClientWrite — đó là quyền tối thiểu đúng nghĩa cho đội chỉ cần đọc dữ liệu.

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

• **D. Tạo tài khoản AWS riêng cho mỗi đội qua Organizations và thiết lập cross-account IAM role — đây là phương án gần nhất và là mô hình hợp lệ trong nhiều tổ chức, nhưng nó nhiều công hơn hẳn cho tình huống này: tách tài khoản nghĩa là phải nhân bản hạ tầng hoặc dựng truy cập chéo tài khoản tới Aurora và EFS — mà cả hai đều nằm trong VPC. Đề nói rõ "minimize administrative overhead", và ba đội cùng dùng chung một hệ thống thì không cần tách tài khoản.
• **C. Dùng Cognito User Pool để xác thực và Identity Pool cấp thông tin đăng nhập tạm thời — sai đối tượng người dùng: Cognito dành cho người dùng cuối của ứng dụng (khách hàng, người dùng app di động). Với nhân viên nội bộ, công cụ đúng là IAM Identity Center. Và nó bỏ phí hệ thống Identity Center mà tổ chức đã triển khai.
• **A. Dùng AWS Control Tower quản lý truy cập đa tài khoản và SCP hạn chế truy cập Aurora và EFS — hiểu sai vai trò của SCP: SCP GIỚI HẠN quyền tối đa, nó không CẤP quyền cho ai. Nó là hàng rào ở mức tài khoản, không phải cơ chế phân quyền chi tiết cho ba đội trong cùng một tài khoản.

Ghi nhớ

Ba khái niệm cốt lõi của IAM Identity Center: | Khái niệm | Việc | |---|---| | Identity source | nơi lấy danh tính: thư mục nội bộ, AD, hoặc IdP hỗ trợ SAML | | Permission set | tập hợp policy — trở thành IAM role trong tài khoản đích | | Assignment | gán (người dùng hoặc nhóm) × (permission set) × (tài khoản AWS) |

Cách permission set hoạt động bên dưới:

Gán permission set cho nhóm ở tài khoản X
    → Identity Center TẠO một IAM role trong tài khoản X
    → người dùng đăng nhập → đảm nhận role đó qua STS
    → nhận thông tin đăng nhập tạm thời

Bạn không phải tạo hay quản lý role đó — Identity Center lo toàn bộ.

Bốn nguồn danh tính mà Identity Center hỗ trợ: | Nguồn | Phù hợp | |---|---| | Identity Center directory | tổ chức chưa có hệ thống danh tính ← đề này | | AWS Managed Microsoft AD | đã có AD trên AWS | | AD Connector | AD tại chỗ | | IdP hỗ trợ SAML 2.0 | Okta, Entra ID, Google Workspace, Ping |

IAM Identity Center và IAM user — bảng phân biệt: | | IAM Identity Center | IAM user | |---|---|---| | Thông tin đăng nhập | TẠM THỜI, tự hết hạn | dài hạn (mật khẩu, access key) | | Quản lý nhiều tài khoản | ✅ tập trung | mỗi tài khoản riêng | | Người nghỉ việc | xoá một chỗ | phải xoá ở từng tài khoản | | MFA | quản lý tập trung | từng người tự cấu hình | | Trạng thái | được khuyến nghị | dùng cho trường hợp đặc biệt |

AWS khuyến nghị dùng Identity Center thay cho IAM user cho MỌI truy cập của con người.

Ba loại policy trong permission set: | Loại | Chi tiết | |---|---| | AWS managed policy | policy có sẵn của AWS | | Customer managed policy | policy bạn tạo trong từng tài khoản | | Inline policy | viết trực tiếp trong permission set — tiện cho quyền riêng | | Permissions boundary | giới hạn quyền tối đa |

Bốn cơ chế truy cập Aurora — chọn theo nhu cầu: | Cơ chế | Đặc điểm | |---|---| | IAM database authentication | rds-db:connect — không cần mật khẩu, token 15 phút | | Secrets Manager | mật khẩu database, tự xoay vòng | | RDS Proxy với IAM auth | thêm gộp kết nối | | Mật khẩu tĩnh | không khuyến nghị |

IAM database authentication là cách phù hợp nhất với mô hình của đề — nó gắn quyền truy cập database vào chính danh tính IAM, nên permission set kiểm soát được cả tầng dữ liệu:

TOKEN=$(aws rds generate-db-auth-token   --hostname cluster-abc.ap-southeast-1.rds.amazonaws.com   --port 3306 --username nguoi_doc)

Ba cơ chế kiểm soát truy cập EFS: | Cơ chế | Việc | |---|---| | IAM policy | ClientMount, ClientWrite, ClientRootAccess | | EFS Access Point | ép POSIX user/group và thư mục gốc riêng cho từng đội | | File system policy | resource policy ở mức file system |

EFS Access Point là công cụ rất phù hợp cho ba đội dùng chung một file system:

Access point "khoa-hoc-du-lieu" → thư mục /du-lieu, POSIX uid 1001, chỉ đọc
Access point "ky-thuat"         → thư mục /, uid 1002, đọc ghi

Mỗi đội chỉ thấy phần dữ liệu của mình — cách ly ở tầng hệ thống tệp, bổ sung cho cách ly ở tầng IAM.

Và một lời khuyên cho tổ chức tài chính như đề mô tả: bật CloudTrail và ghi cả data event cho S3 và các thao tác rds-db:connect. Với yêu cầu quyền riêng tư dữ liệu nghiêm ngặt, kiểm toán viên sẽ hỏi "ai đã truy cập dữ liệu khách hàng nào, lúc nào" — và permission set chỉ trả lời được "ai được phép", không trả lời được "ai đã thực sự".

Đáp án

A — Dùng Storage optimized instance với instance store volume.

Vì sao đúng

Đề nêu bốn dữ kiện, và cả bốn đều chỉ tới cùng một lựa chọn: | Dữ kiện | Kết luận | |---|---| | IOPS cao và truy cập TUẦN TỰ | họ instance Storage optimized (i3, i4i, d3, im4gn) | | Thông lượng I/O là ƯU TIÊN CAO NHẤT | instance store — đĩa NVMe cục bộ, nhanh nhất | | Cơ sở dữ liệu NoSQL | phù hợp với instance store | | Dữ liệu TỰ ĐỘNG SAO CHÉP nhiều bản | rủi ro mất dữ liệu cục bộ được chấp nhận |

Vì sao instance store nhanh hơn EBS:

EBS:
    Instance → MẠNG → tầng lưu trữ EBS
        → có độ trễ mạng, có giới hạn băng thông EBS của instance

Instance store:
    Instance → đĩa NVMe GẮN TRỰC TIẾP vào máy chủ vật lý
        → không qua mạng
        → hàng triệu IOPS, độ trễ microgiây

Con số cụ thể: | Loại | IOPS tối đa | |---|---| | EBS io2 Block Express | 256.000 | | Instance store NVMe (i4i) | hàng TRIỆU |

Và dữ kiện quyết định là "database replicates data automatically":

Instance store MẤT dữ liệu khi instance dừng hoặc bị chấm dứt
    → thường là rủi ro không chấp nhận được
    ↓
Nhưng NoSQL này tự giữ NHIỀU BẢN SAO
    → mất một node không mất dữ liệu
    → cụm tự phục hồi bằng cách sao chép lại
    → rủi ro được xử lý ở TẦNG ỨNG DỤNG

Đây chính là mẫu kiến trúc mà Cassandra, Elasticsearch, MongoDB replica set đều dùng.

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

• **B. General purpose instance với EBS volume — đây là phương án gần nhất và là lựa chọn an toàn mặc định, nhưng nó không tối ưu cho ưu tiên đã nêu: EBS đi qua mạng nên thông lượng và độ trễ kém hơn instance store. Đề nói rõ "I/O throughput is the HIGHEST PRIORITY".
• **C. Compute optimized instance với instance store — sai họ instance: họ C tối ưu cho tỷ lệ CPU trên bộ nhớ cao (mã hoá, xử lý theo lô, máy chủ game). Một số loại có instance store nhưng dung lượng và thông lượng thấp hơn hẳn họ Storage optimized.
• **D. Memory optimized instance với EBS volume — sai cả hai vế: họ R tối ưu cho bộ nhớ lớn (in-memory database, phân tích), và EBS không phải lựa chọn cho ưu tiên thông lượng cao nhất.

Ghi nhớ

Các họ instance của EC2 — bảng cần thuộc: | Họ | Tối ưu cho | Ví dụ | |---|---|---| | General purpose (T, M) | cân bằng CPU, RAM, mạng | web server, ứng dụng nhỏ | | Compute optimized (C) | CPU cao | mã hoá, HPC, máy chủ game | | Memory optimized (R, X, z) | RAM lớn | in-memory DB, phân tích lớn | | Storage optimized (I, D, H, Im) | I/O cục bộ rất cao | NoSQL, kho dữ liệu, tìm kiếm ← câu này | | Accelerated (P, G, Inf, Trn) | GPU, chip AI | học sâu, kết xuất đồ hoạ |

Ba loại Storage optimized và đặc điểm: | Loại | Đĩa | Tối ưu cho | |---|---|---| | I3, I4i, Im4gn | NVMe SSD | IOPS cao — NoSQL, cache, tìm kiếm | | D2, D3, D3en | HDD dung lượng lớn | thông lượng TUẦN TỰ — MapReduce, kho dữ liệu | | H1 | HDD | thông lượng cao, dung lượng lớn |

Đề nói "high IOPS AND sequential read/write" — họ I phù hợp cho vế IOPS, họ D cho vế tuần tự thuần tuý. Với cơ sở dữ liệu NoSQL, họ I (như i4i) là lựa chọn thông thường.

Instance store và EBS — bảng phân biệt cốt lõi: | | Instance store | EBS | |---|---|---| | Vị trí | đĩa VẬT LÝ trên máy chủ | qua mạng | | Hiệu năng | cao nhất — hàng triệu IOPS | rất tốt (tới 256.000 IOPS) | | Bền vững qua stop/terminate | ❌ MẤT | ✅ | | Snapshot | ❌ | ✅ | | Gắn vào instance khác | ❌ | ✅ | | Chi phí | bao gồm trong giá instance | tính riêng |

Khi nào instance store là lựa chọn ĐÚNG: | Trường hợp | Lý do | |---|---| | Cụm tự sao chép dữ liệu | Cassandra, Elasticsearch, Kafka, MongoDB ← câu này | | Cache, dữ liệu tạm, không gian scratch | mất cũng không sao | | Workload cần I/O cực cao | và chấp nhận rủi ro |

Khi nào KHÔNG dùng: | Trường hợp | Lý do | |---|---| | Dữ liệu duy nhất, không sao chép | mất là mất vĩnh viễn | | Instance cần dừng thường xuyên | mỗi lần dừng là mất dữ liệu | | Cần snapshot để sao lưu | instance store không snapshot được |

Ba điều cần làm khi dùng instance store cho cụm NoSQL: | Việc | Lý do | |---|---| | Cấu hình hệ số sao chép ≥ 3 | chịu được mất một node mà không mất dữ liệu | | Trải node qua nhiều AZ | chịu được sự cố cả một AZ | | Có quy trình thay node tự động | node mới tự tham gia cụm và nhận dữ liệu |

Và một chi tiết vận hành quan trọng: instance store NVMe phải được ĐỊNH DẠNG và MOUNT thủ công sau khi khởi chạy.

# Kiểm tra đĩa
lsblk
# Định dạng và mount
sudo mkfs -t xfs /dev/nvme1n1
sudo mkdir -p /du-lieu
sudo mount /dev/nvme1n1 /du-lieu

Nên đưa các lệnh này vào user data — nếu không, instance mới do Auto Scaling tạo ra sẽ không có đĩa nào được gắn.

Và nhớ rằng dữ liệu mất sau mỗi lần stop/start — nên user data phải xử lý được cả trường hợp đĩa trống.

Ba lựa chọn thay thế cho NoSQL trên EC2: | Lựa chọn | Đặc điểm | |---|---| | Amazon DynamoDB | được quản lý hoàn toàn, không phải lo hạ tầng | | Amazon Keyspaces | tương thích Cassandra, được quản lý | | Amazon DocumentDB | tương thích MongoDB, được quản lý | | OpenSearch Service | tìm kiếm và phân tích, được quản lý |

Với đội ngũ nhỏ, dịch vụ được quản lý thường tiết kiệm hơn tổng thể — chi phí vận hành một cụm NoSQL tự quản lý (vá lỗi, mở rộng, xử lý node hỏng, nâng cấp) thường vượt phần chênh lệch về giá hạ tầng.

Và một lưu ý về chi phí: instance họ I khá đắt, nhưng instance store đã bao gồm trong giá — không phải trả thêm cho EBS. Với cụm chạy dài hạn, Savings Plan hoặc Reserved Instance giảm được tới 72%, và đó là khoản tiết kiệm đáng kể với loại instance có giá cao như thế này.

Đáp án

D — Triển khai EC2 instance TRONG CÙNG Region với S3 bucket; cài phần mềm chuyển đổi lên đó; thực hiện biến đổi và tải kết quả trở lại S3.

Vì sao đúng

Đề nêu yêu cầu quyết định: giảm thiểu chi phí TRUYỀN DỮ LIỆU cho 200 TB.

Và có một quy tắc giá của AWS giải quyết trọn vẹn bài toán:

Truyền dữ liệu giữa S3 và EC2 TRONG CÙNG MỘT REGION: MIỄN PHÍ

Phép tính cho thấy khác biệt rất lớn:

CÙNG Region:
    200 TB tải xuống + 200 TB tải lên = 0 USD

KHÁC Region:
    200 TB × ~0,02 USD/GB = ~4.000 USD (chỉ chiều tải xuống)
    → cộng thêm phí ghi ngược lại

Ra Internet:
    200 TB × ~0,09 USD/GB = ~18.000 USD

Luồng xử lý trong cùng Region:

S3 (us-east-1)
    ↓ tải xuống — MIỄN PHÍ
EC2 (us-east-1) chạy phần mềm chuyển đổi độc quyền
    ↓ tải lên — MIỄN PHÍ
S3 (us-east-1)

Và đề bắt buộc phải dùng EC2 vì phần mềm là của nhà cung cấp:

"vendor's PROPRIETARY file conversion software"
    → không chạy được trong Lambda (phụ thuộc hệ điều hành, giấy phép)
    → không có dịch vụ AWS nào làm được định dạng độc quyền đó
    → phải cài lên một máy

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

• **C. Triển khai EC2 instance ở Region KHÁC — đây là phương án gần nhất và chỉ khác đúng một chữ, nhưng chữ đó tốn hàng nghìn USD: truyền dữ liệu xuyên Region tính phí theo GB. Với 200 TB đi qua đi lại, đây là lựa chọn đắt nhất trong các phương án khả thi.
• **B. Xuất dữ liệu bằng Snowball Edge, cài phần mềm lên thiết bị, biến đổi rồi tải lại — rất tốn kém và chậm: phải chờ thiết bị chuyển phát cả hai chiều, và Snowball Edge chỉ chứa tối đa khoảng 80 TB — 200 TB cần nhiều thiết bị. Snowball dành cho nơi băng thông kém, còn dữ liệu ở đây đã nằm trong AWS.
• **A. Cài phần mềm chuyển đổi "vào Amazon S3" và dùng S3 Batch Operations — không làm được: S3 là kho lưu trữ object, KHÔNG chạy phần mềm nào. S3 Batch Operations thực hiện các thao tác dựng sẵn (copy, thay ACL, khôi phục) hoặc gọi Lambda — nó không chạy được phần mềm độc quyền của nhà cung cấp.

Ghi nhớ

Bảng chi phí truyền dữ liệu của AWS — kiến thức tối ưu chi phí quan trọng nhất: | Hướng | Chi phí | |---|---| | VÀO AWS từ Internet | MIỄN PHÍ | | S3 ↔ EC2 CÙNG Region | MIỄN PHÍ | | S3 → CloudFront | MIỄN PHÍ | | Giữa các AZ trong cùng Region | ~0,01 USD/GB mỗi chiều | | Giữa các Region | ~0,02 USD/GB | | RA Internet | ~0,09 USD/GB (giảm dần theo khối lượng) |

Ba dòng "miễn phí" đầu là nền tảng của rất nhiều quyết định kiến trúc.

Và dòng "giữa các AZ" đáng chú ý cho tình huống này: nếu EC2 và S3 cùng Region thì miễn phí, nhưng lưu lượng giữa hai EC2 ở hai AZ khác nhau thì tính phí — nên nếu xử lý phân tán, hãy giữ các node trong cùng AZ.

Ba nguyên tắc thiết kế để giảm chi phí truyền dữ liệu: | Nguyên tắc | Chi tiết | |---|---| | Đưa TÍNH TOÁN tới DỮ LIỆU | rẻ hơn nhiều so với chuyển dữ liệu tới tính toán ← câu này | | Dùng VPC gateway endpoint cho S3 và DynamoDB | miễn phí, tránh phí NAT gateway | | Dùng CloudFront cho nội dung phân phối ra Internet | rẻ hơn S3 trực tiếp |

Nguyên tắc đầu là bài học cốt lõi của câu hỏi này — và nó áp dụng cho mọi quy mô, không chỉ 200 TB.

Và một chi tiết quan trọng: nếu EC2 nằm trong private subnet, hãy tạo VPC gateway endpoint cho S3.

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc123   --service-name com.amazonaws.us-east-1.s3   --route-table-ids rtb-private

Không có endpoint, lưu lượng đi qua NAT gateway và bị tính ~0,045 USD/GB — với 400 TB đi qua đi lại, đó là khoảng 18.000 USD phí NAT, dù phí truyền S3 vẫn bằng 0.

Ba cách tối ưu việc xử lý 200 TB: | Cách | Lợi ích | |---|---| | Dùng nhiều instance xử lý SONG SONG | rút ngắn thời gian đáng kể | | Dùng Spot Instance | tiết kiệm tới 90% — công việc chạy lại được | | Chọn instance có băng thông mạng cao | tránh nghẽn ở tầng mạng |

Xử lý theo lô như thế này là ứng viên hoàn hảo cho Spot:

Mỗi tệp xử lý độc lập
    → instance bị thu hồi → chỉ mất tệp đang xử lý
    → tệp đó được giao lại cho máy khác

Và AWS Batch là công cụ điều phối phù hợp:

AWS Batch:
    → tự quản lý hàng đợi công việc
    → tự khởi chạy và tắt instance theo nhu cầu
    → hỗ trợ Spot sẵn
    → mỗi tệp là một job

Ba lưu ý khi chọn instance cho tác vụ chuyển đổi tệp: | Lưu ý | Chi tiết | |---|---| | Băng thông mạng | quyết định tốc độ tải lên/xuống S3 | | Dung lượng đĩa tạm | đủ chứa tệp đang xử lý | | CPU | phụ thuộc phần mềm chuyển đổi |

Với tệp lớn, instance có băng thông 25 Gbps trở lên (hậu tố n như c5n, m5n) thường đáng giá — thời gian tải chiếm phần lớn tổng thời gian xử lý.

Ba lưu ý khác về việc xử lý 200 TB trên S3: | Lưu ý | Chi tiết | |---|---| | Dùng multipart upload cho tệp lớn | bắt buộc nếu tệp trên 5 GB | | Đặt lifecycle rule dọn phần multipart dở dang | tránh chi phí ẩn tích tụ | | Cân nhắc giữ lại tệp gốc hay không | lưu cả hai bản là gấp đôi chi phí lưu trữ |

Dòng cuối đáng cân nhắc: sau khi chuyển đổi xong, 200 TB bản gốc có còn cần không? Nếu có yêu cầu giữ lại, hãy chuyển chúng sang Glacier Deep Archive — chi phí giảm khoảng 23 lần so với Standard.

Và một lời khuyên vận hành: hãy chạy thử trên một mẻ nhỏ trước (vài chục tệp) để đo thời gian xử lý và kiểm chứng kết quả, rồi mới ước lượng số instance cần cho toàn bộ 200 TB. Phát hiện phần mềm chuyển đổi có lỗi sau khi đã xử lý xong 200 TB là tình huống rất tốn kém.

Đáp án

A — Cấu hình Auto Scaling group dùng predictive scaling.

Vì sao đúng

Đề nêu ba dữ kiện, và cả ba đều chỉ tới predictive scaling: | Dữ kiện | Cơ chế | |---|---| | Khuyến mãi diễn ra HẰNG TUẦN — có mẫu lặp lại | predictive scaling học từ dữ liệu lịch sử | | Ứng dụng khởi động rất LÂU | mở rộng TRƯỚC khi tải tới | | Ít công nhất | tính năng dựng sẵn của ASG, không viết mã |

Vì sao dynamic scaling không đủ trong tình huống này:

Dynamic scaling (phản ứng):
    Tải tăng → CloudWatch phát hiện (1–5 phút)
             → ASG khởi chạy instance
             → instance boot + ỨNG DỤNG KHỞI ĐỘNG LÂU
             → tổng: có thể tới 10–15 phút
    ↓
    Trong khoảng đó → ứng dụng ĐÃ QUÁ TẢI → gián đoạn

Predictive scaling đảo ngược thứ tự:

Máy học phân tích metric của 14 NGÀY gần nhất
    → nhận ra mẫu "thứ Sáu 9 giờ sáng tải tăng gấp ba"
    → dự báo cho 48 giờ tới, cập nhật MỖI GIỜ
    → khởi chạy instance TRƯỚC thời điểm dự báo
    → tới lúc tải thật tới, máy đã sẵn sàng

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-thuong-mai-dien-tu   --policy-name du-bao-tai-hang-tuan   --policy-type PredictiveScaling   --predictive-scaling-configuration '{
    "MetricSpecifications": [{
      "TargetValue": 60,
      "PredefinedMetricPairSpecification": {"PredefinedMetricType": "ASGCPUUtilization"}}],
    "Mode": "ForecastAndScale",
    "SchedulingBufferTime": 600}'

SchedulingBufferTime là tham số dành riêng cho vấn đề của đề:

Đặt 600 giây
    → ASG khởi chạy instance SỚM HƠN 10 PHÚT so với thời điểm dự báo cần
    → đủ thời gian cho ứng dụng khởi động xong

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

• **C. Tạo dynamic scaling policy dựa trên tải CPU trung bình trong quá khứ — đây là phương án gần nhất và là cách làm phổ biến nhất, nhưng nó phản ứng SAU khi tải đã tăng. Với ứng dụng khởi động lâu như đề mô tả, khoảng trễ đó chính là lúc xảy ra gián đoạn — đúng vấn đề cần giải quyết.
• **D. Tạo EventBridge rule theo lịch chạy Lambda mở rộng mỗi nửa đêm — cứng nhắc và không khớp nhu cầu: khuyến mãi diễn ra hằng tuần vào một thời điểm cụ thể, không phải mỗi nửa đêm. Và phải tự viết, tự bảo trì Lambda cùng logic quyết định mở rộng bao nhiêu. (Scheduled scaling của ASG sẽ hợp lý hơn Lambda, nhưng vẫn cần con người tính toán và cập nhật số lượng.)
• **B. Dùng SageMaker Clarify phân tích và dự báo mẫu tải rồi tạo scheduled scaling policy — sai vai trò dịch vụ và rất nhiều công: SageMaker Clarify dùng để phát hiện THIÊN LỆCH và giải thích mô hình học máy, không phải để dự báo chuỗi thời gian. Và tự xây đường ống dự báo là làm lại thứ predictive scaling đã có sẵn miễn phí.

Ghi nhớ

Bốn loại scaling policy của Auto Scaling — bảng cần thuộc: | Loại | Cách hoạt động | Phù hợp | |---|---|---| | Target tracking | giữ metric ở giá trị mục tiêu | mặc định tốt cho hầu hết | | Step scaling | thêm/bớt theo bậc tuỳ mức vượt ngưỡng | cần kiểm soát chi tiết | | Simple scaling | một hành động kèm cooldown | cũ, ít dùng | | Predictive scaling | dự báo và mở rộng TRƯỚC | tải có MẪU LẶP LẠI + khởi động lâu ← câu này | | Scheduled scaling | theo lịch cố định | biết chính xác thời điểm (sự kiện đã lên lịch) |

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

"recurring pattern" / "weekly" / "cyclical"
"long initialization time"
"launch capacity IN ADVANCE"
"forecasted load"
"scale faster"

Đề này có bốn trong năm dấu hiệu.

Ba yêu cầu để predictive scaling hoạt động tốt: | Yêu cầu | Chi tiết | |---|---| | Ít nhất 24 giờ dữ liệu lịch sử | 14 ngày thì dự báo chính xác hơn nhiều | | Tải phải có MẪU LẶP LẠI | ngày, tuần — không dùng được với tải ngẫu nhiên | | Nên kết hợp với dynamic scaling | dự báo lo phần đoán được, dynamic lo phần bất ngờ |

Dòng cuối là thực hành được khuyến nghị:

Predictive scaling → đặt mức nền theo dự báo
Target tracking     → xử lý sai lệch so với dự báo
    → hai cái chạy song song, bổ sung nhau

Hai chế độ của predictive scaling: | Chế độ | Việc | |---|---| | ForecastOnly | chỉ dự báo, KHÔNG hành động — dùng để đánh giá trước | | ForecastAndScale | dự báo và thực sự mở rộng |

Luôn chạy ForecastOnly vài tuần trước — nó cho bạn xem biểu đồ so sánh dự báo với tải thực tế, để biết mô hình có nắm được mẫu của bạn không trước khi giao quyền điều khiển cho nó.

Ba metric mà predictive scaling hỗ trợ: | Metric | Ghi chú | |---|---| | ASGCPUUtilization | phổ biến nhất | | ASGNetworkIn / ASGNetworkOut | cho ứng dụng nặng về mạng | | ALBRequestCount | thường phản ánh tải thật tốt hơn CPU | | Metric tuỳ chỉnh | dùng được |

ALBRequestCount đáng cân nhắc cho ứng dụng thương mại điện tử — số request là chỉ báo trực tiếp của nhu cầu, còn CPU là hệ quả gián tiếp.

Và có một cách bổ sung rất hiệu quả cho vấn đề "khởi động lâu": warm pool.

Warm pool giữ sẵn một nhóm instance ở trạng thái
    Stopped, Running, hoặc Hibernated
        ↓
Cần mở rộng → chuyển instance từ warm pool sang InService
    → nhanh hơn nhiều so với khởi chạy từ đầu

aws autoscaling put-warm-pool   --auto-scaling-group-name asg-thuong-mai-dien-tu   --min-size 5 --pool-state Stopped

Instance ở trạng thái Stopped trong warm pool không tính phí compute — chỉ trả phí EBS. Đây là cách rẻ để có sẵn dung lượng dự phòng.

Ba cách khác rút ngắn thời gian khởi động: | Cách | Lợi ích | |---|---| | AMI đã nướng sẵn ứng dụng và cấu hình | không cài đặt lúc khởi chạy | | Giảm việc làm trong user data | mọi lệnh đều thêm thời gian | | Đặt HealthCheckGracePeriod đủ dài | tránh ASG thay instance chưa kịp khởi động xong |

Dòng cuối là lỗi cấu hình hay gặp với ứng dụng khởi động lâu: grace period quá ngắn khiến ASG coi instance mới là hỏng và chấm dứt nó — tạo ra vòng lặp khởi chạy rồi huỷ liên tục.

Và một lưu ý về chi phí: predictive scaling không tính phí thêm — nó là tính năng có sẵn của Auto Scaling. Chi phí duy nhất là các instance được khởi chạy sớm hơn vài phút so với nhu cầu thật, và đó là cái giá rất nhỏ so với việc mất doanh thu trong đợt khuyến mãi.

Đáp án

C — Dùng AWS Control Tower để dựng landing zone, tự động cấp phát và cấu hình tài khoản mới qua Account Factory; dùng bảng điều khiển của Control Tower để theo dõi các tài khoản; thiết lập guardrail phòng ngừa và phát hiện để thực thi chính sách.

Vì sao đúng

Đề nêu bốn yêu cầu, và Control Tower là dịch vụ được AWS thiết kế để đáp ứng đúng cả bốn: | Yêu cầu | Thành phần | |---|---| | Thiết lập môi trường đa tài khoản an toàn, tuân thủ | landing zone dựng sẵn theo thực hành tốt | | BẢNG ĐIỀU KHIỂN phát hiện liên tục vi phạm chính sách | Control Tower dashboard | | Tuân theo chiến lược đa tài khoản của AWS | cấu trúc OU và tài khoản theo khuyến nghị chính thức | | DỄ NHẤT | thiết lập bằng vài cú nhấp, không tự cấu hình từng phần |

Control Tower dựng sẵn toàn bộ nền tảng:

Bấm "Set up landing zone" → Control Tower tự tạo:
    ✓ AWS Organizations với cấu trúc OU chuẩn
    ✓ Tài khoản Log Archive (tập trung log CloudTrail và Config)
    ✓ Tài khoản Audit (truy cập chỉ đọc để kiểm toán)
    ✓ IAM Identity Center cho truy cập tập trung
    ✓ CloudTrail toàn tổ chức
    ✓ AWS Config ở mọi tài khoản
    ✓ Bộ guardrail được khuyến nghị

Tự làm từng thứ trên mất hàng tuần; Control Tower làm trong khoảng một giờ.

Hai loại guardrail — đúng thứ đề nêu: | Loại | Cơ chế | Việc | |---|---|---| | Preventive (phòng ngừa) | Service Control Policy | CHẶN hành động không được phép | | Detective (phát hiện) | AWS Config rule | PHÁT HIỆN tài nguyên không tuân thủ | | Proactive (chủ động) | CloudFormation Hooks | chặn tài nguyên sai ngay khi triển khai |

Và Account Factory tự động hoá việc tạo tài khoản mới:

Yêu cầu tài khoản mới
    → Account Factory tạo tài khoản
    → tự đặt vào đúng OU
    → tự áp guardrail của OU đó
    → tự cấu hình VPC theo chuẩn
    → tự thêm vào IAM Identity Center

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

• **B. Tạo tài khoản bằng CloudFormation StackSets; dùng AWS Config theo dõi và Multi-Account Multi-Region Data Aggregator để xem tập trung — đây là phương án gần nhất và thực sự làm được về mặt kỹ thuật, nhưng nó nhiều công hơn hẳn: bạn phải tự dựng từng thành phần mà Control Tower cung cấp sẵn, tự thiết kế cấu trúc OU, tự viết guardrail, tự dựng cơ chế tạo tài khoản. Đề hỏi "the EASIEST way".
• **A. Dùng AWS Organizations dựng landing zone và AWS Personal Health Dashboard để xem các tài khoản — sai công cụ ở cả hai vế: Organizations là nền móng nhưng nó không tự dựng landing zone — đó chính là việc Control Tower làm. Và Personal Health Dashboard báo sự kiện ảnh hưởng tới tài nguyên, nó không hiển thị tình trạng tuân thủ.
• **D. Dùng AWS Service Catalog tạo tài khoản mới và Launch Constraint để theo dõi thay đổi cấu hình — hiểu sai chức năng: Service Catalog quản lý danh mục sản phẩm được phê duyệt để người dùng tự triển khai. Launch constraint quy định IAM role dùng khi triển khai sản phẩm — nó không theo dõi tuân thủ. (Account Factory của Control Tower thực chất dùng Service Catalog bên dưới, nhưng bản thân Service Catalog không tạo tài khoản.)

Ghi nhớ

Ba dịch vụ nền tảng cho môi trường đa tài khoản: | Dịch vụ | Việc | |---|---| | AWS Organizations | NỀN MÓNG: gộp tài khoản, OU, SCP, thanh toán chung | | AWS Control Tower | DỰNG SẴN landing zone trên nền Organizations | | IAM Identity Center | truy cập tập trung cho con người |

Quan hệ giữa chúng:

Control Tower DÙNG Organizations bên dưới
    → nó không thay thế, mà tự động hoá việc cấu hình
    → nếu đã có Organizations, Control Tower vẫn dùng được

Cấu trúc OU mà Control Tower dựng sẵn:

Root
├── Security (bắt buộc)
│   ├── Log Archive     ← tập trung log
│   └── Audit           ← truy cập kiểm toán
└── Sandbox (tuỳ chọn)
    └── các tài khoản dùng thử

Bạn thêm OU riêng cho môi trường của mình: Workloads/Production, Workloads/Development.

Ba loại guardrail và mức áp dụng: | Mức | Ý nghĩa | |---|---| | Mandatory | luôn bật, không tắt được | | Strongly recommended | AWS khuyến nghị mạnh | | Elective | tuỳ chọn theo nhu cầu |

Ví dụ guardrail bắt buộc:

Cấm thay đổi cấu hình CloudTrail của Control Tower
Cấm xoá bucket log archive
Cấm thay đổi vai trò do Control Tower tạo

Ba lợi ích chính của mô hình đa tài khoản: | Lợi ích | Chi tiết | |---|---| | Cách ly rủi ro | sự cố ở một tài khoản không lan sang tài khoản khác | | Ranh giới hạn mức rõ ràng | một đội dùng hết hạn mức không ảnh hưởng đội khác | | Phân bổ chi phí tự nhiên | mỗi tài khoản một hoá đơn riêng |

Ba lưu ý khi triển khai Control Tower: | Lưu ý | Chi tiết | |---|---| | Cần tài khoản quản lý sạch | không nên chạy workload trong đó | | Có phí cho Config và CloudTrail | guardrail phát hiện dùng Config — tính phí theo số đánh giá | | Landing zone có phiên bản | cần cập nhật định kỳ khi AWS phát hành bản mới |

Dòng giữa đáng lưu ý về chi phí: Control Tower bản thân miễn phí, nhưng nó bật AWS Config ở mọi tài khoản và mọi Region được quản lý — với nhiều tài nguyên thay đổi thường xuyên, khoản này tích tụ. Hãy giới hạn số Region được quản lý xuống những nơi thực sự dùng.

Ba khả năng khác của Control Tower đáng biết: | Khả năng | Việc | |---|---| | Account Factory for Terraform (AFT) | tạo tài khoản qua Terraform pipeline | | Customizations for Control Tower (CfCT) | thêm tài nguyên riêng vào quy trình tạo tài khoản | | Landing zone accelerator | cho môi trường có yêu cầu tuân thủ đặc biệt |

Và một lời khuyên cho startup như đề mô tả: hãy dựng Control Tower NGAY TỪ ĐẦU.

Dựng từ đầu:      vài giờ
Chuyển đổi sau:   tốn công gấp nhiều lần
    → phải di chuyển tài khoản đã có vào cấu trúc mới
    → phải hoà giải các cấu hình đã lệch nhau

Đây là loại nền tảng mà chi phí thiết lập tăng theo thời gian bạn trì hoãn.

Và một lưu ý về giới hạn: Control Tower không hỗ trợ mọi Region ngay khi Region mới ra mắt, và có giới hạn về số tài khoản quản lý được (mặc định vài trăm, tăng được). Với tổ chức rất lớn, hãy kiểm tra hạn mức trước khi cam kết vào kiến trúc.