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

Đáp án

A — Dùng Amazon FSx tạo một SMB file share, và cho client từ xa kết nối tới share đó qua Client VPN.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Thay thế dịch vụ lưu trữ tại chỗ, ĐƯỢC QUẢN LÝ HOÀN TOÀN | FSx là dịch vụ được quản lý | | Nhân viên làm việc TỪ XA nhiều nơi | Client VPN cho từng người dùng | | Hệ thống tại chỗ cũng truy cập được | FSx nằm trong VPC, nối được qua VPN/DX |

Vì sao Client VPN là mảnh ghép cần thiết:

FSx nằm TRONG VPC, không có endpoint công khai
    → nhân viên ở nhà không tới được trực tiếp
        ↓
    Client VPN đưa máy của họ vào mạng VPC
    → mount file share như đang ngồi trong văn phòng

Dựng Client VPN:

aws ec2 create-client-vpn-endpoint   --client-cidr-block 10.100.0.0/22   --server-certificate-arn <arn-chung-chi>   --authentication-options '[{"Type":"directory-service-authentication",
    "ActiveDirectory":{"DirectoryId":"d-1234567890"}}]'   --connection-log-options '{"Enabled":true,
    "CloudwatchLogGroup":"/aws/clientvpn"}'   --split-tunnel

aws ec2 associate-client-vpn-target-network   --client-vpn-endpoint-id cvpn-endpoint-abc --subnet-id subnet-a

aws ec2 authorize-client-vpn-ingress   --client-vpn-endpoint-id cvpn-endpoint-abc   --target-network-cidr 10.0.0.0/16 --authorize-all-groups

⚠ --split-tunnel là tuỳ chọn nên bật:

Không split tunnel: MỌI lưu lượng của máy nhân viên
                    đi qua VPN, kể cả xem YouTube
    → tốn băng thông và phí truyền dữ liệu

Split tunnel: chỉ lưu lượng tới VPC đi qua VPN
    → phần còn lại ra Internet trực tiếp

Mount file share:

net use Z: \\amznfsxabc.congty.local\share /persistent:yes

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | AWS lo vá lỗi, sao lưu, nhân bản | | | Xác thực bằng Active Directory hiện có | | | Cùng một share cho cả người từ xa lẫn hệ thống tại chỗ | |

Và hệ thống tại chỗ nối vào cùng VPC:

Site-to-Site VPN hoặc Direct Connect
    → máy chủ trong trung tâm dữ liệu mount cùng share
        ↓
    Một hệ thống tệp, hai kiểu người dùng

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

• **C. Dùng Storage Gateway volume gateway lưu và chuyển tệp lên S3 — đây là phương án gần nhất vì cũng là dịch vụ lưu trữ của AWS, nhưng volume gateway xuất iSCSI (khối), không phải file share cho người dùng cuối. Và nó là cầu nối cho hạ tầng tại chỗ, không phải giải pháp thay thế được quản lý.
• **D. Dùng DataSync đồng bộ giữa dịch vụ tại chỗ và S3 — DataSync là công cụ di chuyển dữ liệu, không cung cấp file share nào để người dùng mount. Và nó không thay thế hệ thống lưu trữ.
• **B. Dùng "AWS Transfer Acceleration" nhân bản tệp lên S3 và bật truy cập công khai — tên dịch vụ không chính xác (đó là S3 Transfer Acceleration), và mở public access cho tệp nội bộ của công ty là sai lầm nghiêm trọng về bảo mật.

Ghi nhớ

⚠ Ba cách cho người dùng từ xa truy cập tài nguyên VPC — bảng phải thuộc: | Cách | Dành cho | |---|---| | AWS Client VPN | NGƯỜI DÙNG CÁ NHÂN từ xa | | Site-to-Site VPN | VĂN PHÒNG / trung tâm dữ liệu | | Direct Connect | kết nối riêng băng thông cao |

Từ khoá nhận diện:

"employees work remotely from various locations" → Client VPN "connect office network" → Site-to-Site VPN "managed file share, SMB" → FSx for Windows "managed file share, NFS" → EFS

Bốn dịch vụ FSx: | Dịch vụ | Giao thức | |---|---| | FSx for Windows File Server | SMB ← câu này | | FSx for Lustre | Lustre | | FSx for NetApp ONTAP | NFS + SMB + iSCSI | | FSx for OpenZFS | NFS |

Ba cách xác thực Client VPN: | Cách | Đặc điểm | |---|---| | Active Directory | dùng lại tài khoản hiện có | | Chứng chỉ tương hỗ (mutual TLS) | không cần AD | | SAML (IAM Identity Center, Okta) | SSO |

Ba thành phần của Client VPN: | Thành phần | Việc | |---|---| | Endpoint | điểm cuối phía AWS | | Target network association | subnet mà VPN nối vào | | Authorization rule | ai được tới mạng nào |

⚠ Authorization rule là bước hay quên:

Tạo endpoint và associate subnet xong
    → nhưng chưa có authorization rule
    → kết nối VPN thành công nhưng không tới được gì
        ↓
    Phải authorize từng CIDR đích

Phân quyền theo nhóm AD:

aws ec2 authorize-client-vpn-ingress   --client-vpn-endpoint-id cvpn-endpoint-abc   --target-network-cidr 10.0.1.0/24   --access-group-id <sid-nhom-ad-ke-toan>

Chỉ nhóm kế toán tới được subnet chứa dữ liệu kế toán
    → phân quyền mạng theo nhóm AD

Ba lưu ý về chi phí Client VPN: | Khoản | Chi tiết | |---|---| | Phí theo GIỜ mỗi subnet association | kể cả khi không ai kết nối | | Phí theo GIỜ mỗi kết nối đang hoạt động | | | Split tunnel giảm phí truyền dữ liệu | |

⚠ Vế đầu là chi phí ẩn:

Associate 3 subnet cho tính sẵn sàng cao
    → trả phí 3 association 24/7
        ↓
    Cân nhắc số subnet thực sự cần

Ba yêu cầu để dựng FSx for Windows: | Yêu cầu | Chi tiết | |---|---| | Active Directory | Managed AD hoặc AD tự quản | | Subnet ở hai AZ nếu Multi-AZ | | | Security group mở SMB (445) và cổng AD | |

Ba tính năng của FSx for Windows: | Tính năng | Chi tiết | |---|---| | ACL Windows và tích hợp AD | | | Shadow Copies | người dùng tự khôi phục tệp | | Deduplication | tiết kiệm 50-60% |

Ba lựa chọn thay thế cho làm việc từ xa: | Lựa chọn | Đặc điểm | |---|---| | Amazon WorkSpaces | máy tính ảo, không cần VPN | | Amazon WorkDocs | chia sẻ tệp qua trình duyệt | | FSx + Client VPN | ← câu này |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Bật connection log | ghi ai kết nối lúc nào | | Dùng MFA nếu AD hỗ trợ | | | Giới hạn authorization rule tới đúng subnet cần | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết nối VPN từ ngoài và mount share | | | Kiểm tra quyền AD áp đúng | | | Xem connection log trong CloudWatch | |

Và một lời khuyên: hãy bật split tunnel và giới hạn authorization rule chặt ngay từ đầu. Một Client VPN không split tunnel biến mọi lưu lượng cá nhân của nhân viên thành phí truyền dữ liệu của công ty — và một authorization rule mở toàn bộ 0.0.0.0/0 biến mỗi laptop ở nhà thành một cửa vào toàn bộ mạng VPC.

Đáp án

A — Cài SSM Agent trên mọi instance, gắn instance profile với chính sách Systems Manager, cấp quyền vào console bằng permission set của IAM Identity Center, và dùng Session Manager để truy cập máy mà không cần mở cổng mạng.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này là lựa chọn an toàn nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Nhà thầu cần vào AWS Console nhiều tài khoản | IAM Identity Center permission set | | Cần truy cập hệ điều hành EC2 ở subnet RIÊNG TƯ | Session Manager — không cần IP công khai | | MỌI hoạt động phải được ghi log | CloudTrail + session log ra S3/CloudWatch | | Giảm rủi ro truy cập trái phép | KHÔNG mở cổng, KHÔNG có khoá SSH, credential tạm |

⚠ Vì sao Session Manager an toàn hơn bastion host:

Bastion host:
    → phải mở cổng 22 ra Internet (hoặc tới dải IP nhà thầu)
    → phải quản lý và phân phối khoá SSH
    → khoá bị lộ = mất quyền kiểm soát
        ↓
Session Manager:
    → SSM Agent kết nối RA (outbound) tới AWS
    → KHÔNG mở cổng inbound nào
    → không có khoá SSH nào tồn tại
    → quyền kiểm soát bằng IAM, thu hồi tức thì

Cấu hình:

aws iam attach-role-policy --role-name VaiTroInstance   --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

aws ssm start-session --target i-abc123

Ghi log phiên làm việc:

aws ssm update-document --name SSM-SessionManagerRunShell   --document-version '$LATEST' --content '{
    "schemaVersion":"1.0",
    "inputs":{
      "s3BucketName":"log-phien-lam-viec",
      "s3EncryptionEnabled":true,
      "cloudWatchLogGroupName":"/aws/ssm/phien",
      "cloudWatchEncryptionEnabled":true,
      "kmsKeyId":"alias/khoa-phien"}}'   --document-format JSON

Mọi lệnh nhà thầu gõ đều được ghi lại
    → đáp ứng "all activities are logged"

⚠ Ba VPC endpoint cần cho subnet riêng tư: | Endpoint | Vì sao | |---|---| | ssm | API chính | | ssmmessages | kênh Session Manager | | ec2messages | Run Command |

Thiếu ssmmessages → instance hiện là "Managed"
    → nhưng start-session thất bại
        ↓
    Đây là lỗi hay gặp nhất khi dựng Session Manager

Ba lợi ích của IAM Identity Center cho nhà thầu: | Lợi ích | Chi tiết | |---|---| | Một nơi cấp và thu hồi quyền cho mọi tài khoản | | | Credential TẠM, tự hết hạn | | | Không có IAM user hay access key nào | |

Và thu hồi quyền là một thao tác:

aws sso-admin delete-account-assignment --instance-arn <arn>   --target-id 111122223333 --target-type AWS_ACCOUNT   --permission-set-arn <arn-ps>   --principal-type GROUP --principal-id <id-nhom-nha-thau>

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

• **B. SSM Agent + Session Manager, nhưng cấp IAM user tạm thời trong TỪNG tài khoản — đây là phương án gần nhất vì phần truy cập EC2 hoàn toàn đúng, nhưng phần console kém an toàn hơn: IAM user có access key dài hạn, phải tạo và xoá thủ công ở từng tài khoản, và rất dễ sót khi kết thúc hợp đồng.
• **D. Dựng bastion host trong subnet công khai với SSH key và IAM user — kém an toàn nhất: mở cổng 22 ra Internet, phân phối khoá SSH cho bên ngoài, và không có ghi log lệnh gõ.
• **C. Dựng VPN/Direct Connect tới văn phòng nhà thầu và cho SSH từ dải IP đó — an toàn hơn D nhưng vẫn dùng SSH và khoá tĩnh, vẫn tạo IAM user ở từng tài khoản, và dựng kết nối mạng riêng tới bên thứ ba là công vận hành lớn.

Ghi nhớ

⚠ Ba cách truy cập EC2 — bảng phải thuộc: | Cách | Cổng mở | Khoá SSH | Audit lệnh | |---|---|---|---| | Session Manager | KHÔNG | KHÔNG | ✅ | | EC2 Instance Connect Endpoint | không | tạm thời | qua CloudTrail | | Bastion host + SSH | 22 ra Internet | có | phải tự dựng |

Từ khoá nhận diện:

"secure OS access, private subnets, logged" → Session Manager "third-party/contractor console access, multiple accounts" → IAM Identity Center permission set "no open inbound ports" → Session Manager

Ba yêu cầu của Session Manager: | Yêu cầu | Chi tiết | |---|---| | SSM Agent | có sẵn trên AMI Amazon Linux, Ubuntu mới | | Instance profile với AmazonSSMManagedInstanceCore | | | Đường ra tới endpoint SSM | NAT hoặc VPC endpoint |

Ba lợi ích của Session Manager cho tuân thủ: | Lợi ích | Chi tiết | |---|---| | Ghi toàn bộ nội dung phiên ra S3/CloudWatch | | | CloudTrail ghi ai mở phiên với instance nào | | | Kiểm soát bằng IAM, thu hồi tức thì | |

Giới hạn ai được vào máy nào bằng tag:

{"Effect":"Allow","Action":"ssm:StartSession",
 "Resource":"arn:aws:ec2:*:*:instance/*",
 "Condition":{"StringEquals":
   {"ssm:resourceTag/nha-thau":"cho-phep"}}}

Nhà thầu chỉ vào được máy có tag phù hợp
    → không phải mọi instance trong tài khoản

Ba tính năng bổ sung của Session Manager: | Tính năng | Việc | |---|---| | Port forwarding | tunnel tới cổng nội bộ | | SSH over Session Manager | dùng ssh quen thuộc | | Chạy dưới người dùng chỉ định | không phải root |

Port forwarding rất hữu ích:

aws ssm start-session --target i-abc123   --document-name AWS-StartPortForwardingSessionToRemoteHost   --parameters '{"host":["csdl.abc.rds.amazonaws.com"],
                 "portNumber":["5432"],"localPortNumber":["5432"]}'

Kết nối tới RDS trong subnet riêng tư từ máy cá nhân
    → không cần bastion, không cần VPN

Ba lưu ý về IAM Identity Center với bên ngoài: | Lưu ý | Chi tiết | |---|---| | Tạo nhóm riêng cho nhà thầu | | | Session duration ngắn (1-2 giờ) | | | Permission set giới hạn chặt | |

Ba biện pháp bổ sung cho bên thứ ba: | Biện pháp | Chi tiết | |---|---| | Bắt buộc MFA | | | Giới hạn theo IP nguồn | aws:SourceIp | | Rà soát quyền định kỳ | |

Giới hạn IP trong permission set:

{"Effect":"Deny","Action":"*","Resource":"*",
 "Condition":{"NotIpAddress":{"aws:SourceIp":["203.0.113.0/24"]}}}

Ba lưu ý về ghi log: | Lưu ý | Chi tiết | |---|---| | Bật session log ra S3 VÀ CloudWatch | | | Mã hoá log bằng KMS | | | Bật Object Lock nếu cần bất biến | |

Ba lựa chọn thay thế Session Manager: | Lựa chọn | Khi nào | |---|---| | EC2 Instance Connect Endpoint | muốn dùng SSH thuần | | AWS Client VPN | cần truy cập cả mạng | | Bastion host | hầu như không còn lý do |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | aws ssm describe-instance-information | máy đã Managed chưa | | Mở một phiên và kiểm tra log | | | Xác nhận không có security group nào mở 22 | |

aws ssm describe-instance-information   --query "InstanceInformationList[].[InstanceId,PingStatus,PlatformName]"   --output table

Và một lời khuyên: hãy kiểm tra ba VPC endpoint trước khi kết luận Session Manager không hoạt động. Triệu chứng khi thiếu ssmmessages rất dễ gây lạc hướng — instance hiển thị trạng thái "Online" bình thường trong danh sách, chỉ có lệnh mở phiên là thất bại với thông báo không nhắc gì tới mạng.

Đáp án

A — Dùng Amazon EFS để cung cấp một hệ thống tệp chia sẻ tương thích NFS, tích hợp với các dịch vụ AWS.

Vì sao đúng

Đề nêu bốn yêu cầu, và EFS khớp cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Mã nguồn cũ CHỈ dùng được NFS | EFS chính là NFS v4.1 | | Không sửa được ứng dụng | chỉ đổi đường dẫn mount | | Tính sẵn sàng cao | dữ liệu nhân bản qua nhiều AZ | | Có khả năng mở rộng | tự co giãn tới petabyte |

Vế đầu là ràng buộc tuyệt đối:

"cannot be modified to use any protocol other than NFS"
    → loại mọi lựa chọn dùng giao thức khác
        ↓
    S3 (HTTP API), FSx for Windows (SMB) đều bị loại
    → chỉ còn EFS và File Gateway

Tạo EFS:

aws efs create-file-system --performance-mode generalPurpose   --throughput-mode elastic --encrypted   --tags Key=Name,Value=du-lieu-mo-phong

aws efs create-mount-target --file-system-id fs-abc   --subnet-id subnet-az-a --security-groups sg-efs
aws efs create-mount-target --file-system-id fs-abc   --subnet-id subnet-az-b --security-groups sg-efs

Mount trên EC2:

sudo yum install -y amazon-efs-utils
sudo mount -t efs -o tls fs-abc:/ /du-lieu-mo-phong

⚠ Và trong /etc/fstab để tự mount khi khởi động:

fs-abc:/ /du-lieu-mo-phong efs _netdev,tls 0 0

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Nhân bản qua nhiều AZ tự động | tính sẵn sàng cao | | Tự co giãn, không cấp phát trước | | | Trả tiền theo dung lượng THỰC DÙNG | |

Vế cuối khác hẳn EBS:

EBS: cấp 1 TB, dùng 200 GB → trả tiền 1 TB
EFS: dùng 200 GB → trả tiền 200 GB
        ↓
    Dữ liệu mô phỏng tăng dần → không phải dự đoán trước

Và lifecycle giảm chi phí:

aws efs put-lifecycle-configuration --file-system-id fs-abc   --lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"},
                         {"TransitionToArchive":"AFTER_90_DAYS"},
                         {"TransitionToPrimaryStorageClass":"AFTER_1_ACCESS"}]'

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

• **B. Dùng Storage Gateway File Gateway cung cấp giao diện NFS trên nền S3 — đây là phương án gần nhất vì cũng xuất NFS, nhưng File Gateway là cầu nối cho hạ tầng TẠI CHỖ truy cập đám mây. Sau khi di chuyển lên AWS thì không còn "tại chỗ" nữa, và đặt một gateway giữa EC2 và S3 là thêm một tầng vô ích cùng một điểm hỏng mới.
• **C. Dùng EBS gắn vào từng EC2 rồi tự cài phần mềm NFS — tạo điểm hỏng đơn lẻ: máy chủ NFS đó chết là mọi thứ dừng, và bạn phải tự vá lỗi, tự sao lưu, tự mở rộng. Ngược hẳn "highly available".
• **D. Dùng FSx for Windows với giao thức SMB — sai giao thức: đề nói rõ mã nguồn chỉ dùng được NFS.

Ghi nhớ

⚠ Bảng ánh xạ giao thức — cách chọn nhanh nhất: | Giao thức | Dịch vụ | |---|---| | NFS | EFS, FSx for ONTAP, FSx for OpenZFS | | SMB | FSx for Windows, FSx for ONTAP | | Lustre | FSx for Lustre | | iSCSI | Volume Gateway, FSx for ONTAP | | HTTP API | S3 |

Từ khoá nhận diện:

"NFS only, cannot modify code" + trên AWS → EFS "NFS from on-premises to cloud storage" → File Gateway "SMB, Windows, AD" → FSx for Windows "HPC parallel" → FSx for Lustre

⚠ EFS và File Gateway — khi nào dùng cái nào: | | Amazon EFS | S3 File Gateway | |---|---|---| | Client ở đâu | trong AWS | tại chỗ | | Dữ liệu lưu ở | EFS | S3 | | Cache cục bộ | không cần | có | | Đa AZ | ✅ | gateway là một máy |

Hai chế độ hiệu năng EFS: | Chế độ | Đặc điểm | |---|---| | General Purpose | độ trễ thấp nhất — mặc định | | Max I/O | thông lượng cao hơn, độ trễ CAO hơn |

⚠ Không đổi được sau khi tạo — phải tạo file system mới.

Ba chế độ thông lượng: | Chế độ | Đặc điểm | |---|---| | Elastic | tự co giãn, trả theo dùng ← khuyến nghị | | Bursting | theo dung lượng, có credit | | Provisioned | cố định |

⚠ Bursting là bẫy với file system nhỏ:

Thông lượng cơ sở = 50 KB/s mỗi GB
    → file system 100 GB → chỉ 5 MB/s cơ sở
    → burst credit cạn → chậm đột ngột
        ↓
    Theo dõi BurstCreditBalance, hoặc dùng Elastic

Bốn lớp lưu trữ EFS: | Lớp | Đặc điểm | |---|---| | Standard | đa AZ, giá cao nhất | | Infrequent Access | rẻ hơn ~85%, có phí đọc | | Archive | rẻ hơn nữa | | One Zone | một AZ — kém sẵn sàng |

⚠ One Zone rẻ hơn nhưng không đáp ứng "highly available".

Ba yêu cầu mạng: | Yêu cầu | Chi tiết | |---|---| | Mount target ở MỖI AZ có instance | | | Security group EFS mở cổng 2049 | NFS | | Nguồn là security group của EC2 | |

Cổng 2049 là lỗi hay gặp nhất:

aws ec2 authorize-security-group-ingress --group-id sg-efs   --protocol tcp --port 2049 --source-group sg-ung-dung

Thiếu quy tắc này: lệnh mount treo rất lâu rồi timeout
    → thông báo không nhắc gì tới security group

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | Độ trễ cao hơn EBS | NFS qua mạng | | Nhiều tệp nhỏ chậm hơn ít tệp lớn | | | Không đặt CSDL cần IOPS cao trên EFS | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá at rest bật KHI TẠO | không bật sau được | | -o tls cho mã hoá đường truyền | | | Access point giới hạn thư mục và UID/GID | |

Ba bước di chuyển dữ liệu từ NFS tại chỗ: | Bước | Việc | |---|---| | Dùng DataSync chép sang EFS | | | Kiểm tra số tệp và quyền | | | Chuyển ứng dụng sang mount point mới | |

aws datasync create-task   --source-location-arn <arn-nfs-tai-cho>   --destination-location-arn <arn-efs>   --options '{"PosixPermissions":"PRESERVE","Uid":"INT_VALUE","Gid":"INT_VALUE"}'

⚠ Nếu dùng Auto Scaling:

Đưa lệnh mount vào USER DATA của launch template
    → không chỉ sửa /etc/fstab trên máy đang chạy
        ↓
    Máy mới không mount EFS sẽ ghi vào đĩa cục bộ
    → mất dữ liệu khi máy bị thay, âm thầm

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | PercentIOLimit | gần 100% là chạm trần General Purpose | | BurstCreditBalance | nếu dùng Bursting | | ClientConnections | số máy đang mount |

Và một lời khuyên: hãy chọn chế độ thông lượng Elastic ngay từ đầu. Chế độ Bursting cho hiệu năng tốt trong lúc thử nghiệm rồi tụt hẳn khi burst credit cạn — và triệu chứng đó xuất hiện đúng vào ngày ứng dụng bắt đầu chạy tải thật.

Đáp án

A — Tạo một AMI cho mỗi ứng dụng, khởi chạy hai EC2 instance cho mỗi ứng dụng ở hai Availability Zone khác nhau, và dùng Application Load Balancer phân phối lưu lượng giữa chúng.

Vì sao đúng

Đề nêu bốn ràng buộc, và phương án này thoả hết: | Ràng buộc | Cách đáp ứng | |---|---| | Phần mềm độc quyền KHÔNG SỬA ĐƯỢC | giữ nguyên trong AMI | | Mỗi ứng dụng chạy trên máy ảo riêng | mỗi ứng dụng một cặp EC2 | | Chịu được hỏng MỘT Availability Zone | hai AZ cho mỗi ứng dụng | | Thay đổi kiến trúc và công vận hành TỐI THIỂU | lift-and-shift, không viết lại |

Vì sao AMI là cách đúng cho phần mềm không sửa được:

Chụp AMI = giữ nguyên toàn bộ môi trường
    → hệ điều hành, thư viện, cấu hình, giấy phép
        ↓
    Không phải container hoá
    → không phải kiểm chứng lại phần mềm độc quyền
    → không cần nhà cung cấp hỗ trợ nền tảng mới

Kiến trúc kết quả:

              ALB
        ┌──────┴──────┐
   [EC2 AZ-a]    [EC2 AZ-b]     ← ứng dụng 1
        │              │
   (lặp lại cho mỗi ứng dụng, với target group riêng)
        ↓
    Mất AZ-a → ALB gửi hết sang AZ-b

Tạo AMI và triển khai:

aws ec2 create-image --instance-id i-goc --name "ung-dung-ho-tro-v1"   --no-reboot

aws ec2 run-instances --image-id ami-abc --count 1   --instance-type m6i.large --subnet-id subnet-az-a
aws ec2 run-instances --image-id ami-abc --count 1   --instance-type m6i.large --subnet-id subnet-az-b

Đăng ký vào target group riêng cho từng ứng dụng:

aws elbv2 create-target-group --name tg-ung-dung-1   --protocol HTTP --port 8080 --vpc-id vpc-abc   --health-check-path /health

aws elbv2 register-targets --target-group-arn <arn-tg>   --targets Id=i-az-a Id=i-az-b

Và ALB định tuyến theo host hoặc path:

aws elbv2 create-rule --listener-arn <arn-listener> --priority 10   --conditions Field=host-header,Values=ungdung1.vidu.com   --actions Type=forward,TargetGroupArn=<arn-tg-1>

Một ALB phục vụ nhiều ứng dụng
    → mỗi ứng dụng một target group
    → tiết kiệm hơn mỗi ứng dụng một ALB

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không đụng vào phần mềm | giữ được hỗ trợ của nhà cung cấp | | Chịu được mất một AZ | | | Kiến trúc quen thuộc, dễ vận hành | |

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

• **B. Dùng AWS Elastic Disaster Recovery (DRS) nhân bản máy ảo lên AWS rồi chạy trong Auto Scaling group đa AZ — đây là phương án gần nhất và DRS đúng là công cụ di chuyển tốt, nhưng hai điểm sai: DRS là công cụ khôi phục thảm hoạ, không phải để chạy sản xuất liên tục; và đặt các máy ảo được nhân bản vào ASG không hoạt động như mô tả vì mỗi ứng dụng là một máy riêng với cấu hình riêng, không phải nhóm máy giống hệt nhau.
• **C. Tái cấu trúc thành microservice và triển khai lên ECS Fargate — vi phạm trực tiếp ràng buộc "phần mềm độc quyền không sửa được" và "tối thiểu thay đổi kiến trúc". Đây là công sức lớn nhất trong bốn phương án.
• **D. Dùng AWS Backup sao lưu mỗi giờ vào Glacier và khôi phục khi hỏng — đây là mẫu Backup & Restore: có thời gian ngừng tính bằng giờ (Glacier cần khôi phục hàng giờ), và mất tới một giờ dữ liệu. Không phải "highly available".

Ghi nhớ

⚠ Ba chiến lược di chuyển lên đám mây — bảng phải thuộc: | Chiến lược | Nghĩa | Công | |---|---|---| | Rehost (lift-and-shift) | chuyển nguyên trạng lên EC2 | thấp nhất ← câu này | | Replatform | đổi vài thành phần (ví dụ sang RDS) | trung bình | | Refactor | viết lại kiến trúc | cao nhất |

Bảy chiến lược "7 R" của AWS: | Chiến lược | Nghĩa | |---|---| | Rehost | chuyển nguyên trạng | | Relocate | chuyển hạ tầng (VMware Cloud) | | Replatform | tối ưu nhẹ | | Refactor | viết lại | | Repurchase | mua SaaS thay thế | | Retire | bỏ đi | | Retain | giữ tại chỗ |

Từ khoá nhận diện:

"cannot be modified" + "minimize changes" → rehost lên EC2 "modernize, microservices" → refactor sang container "disaster recovery replication" → AWS DRS "multiple AZ + load balancer" → tính sẵn sàng cao

⚠ Ba khái niệm dễ lẫn: | Khái niệm | Nghĩa | |---|---| | Tính sẵn sàng cao (HA) | tự chịu được hỏng, KHÔNG gián đoạn | | Khôi phục thảm hoạ (DR) | phục hồi sau sự cố, có RTO/RPO | | Sao lưu | giữ bản sao dữ liệu |

Đề nói "continue to operate in the event of an AZ failure"
    → yêu cầu HA, không phải DR
        ↓
    Đây là lý do B và D không đủ

Ba công cụ di chuyển của AWS: | Công cụ | Việc | |---|---| | AWS Application Migration Service (MGN) | rehost máy chủ lên EC2 | | AWS Elastic Disaster Recovery (DRS) | DR — nhân bản để chờ sự cố | | AWS App2Container | container hoá ứng dụng .NET/Java |

⚠ MGN và DRS rất giống nhau về kỹ thuật nhưng khác mục đích:

MGN: di chuyển MỘT LẦN, rồi tắt nguồn cũ
DRS: nhân bản LIÊN TỤC, giữ nguồn cũ chạy
        ↓
    Với việc di chuyển ứng dụng lên AWS thì MGN là công cụ đúng

Ba lưu ý khi tạo AMI cho ứng dụng cũ: | Lưu ý | Chi tiết | |---|---| | --no-reboot giữ máy chạy nhưng có thể không nhất quán | | | Dừng dịch vụ trước khi chụp nếu được | | | Kiểm tra giấy phép phần mềm có ràng buộc phần cứng không | |

Vế thứ ba là rủi ro thật với phần mềm độc quyền:

Một số phần mềm khoá giấy phép theo MAC address
hoặc theo mã máy
    → nhân bản sang máy mới làm giấy phép hết hiệu lực
        ↓
    Kiểm tra với nhà cung cấp TRƯỚC khi lên kế hoạch

Ba lưu ý về trạng thái ứng dụng: | Lưu ý | Chi tiết | |---|---| | Ứng dụng cũ thường giữ session trong bộ nhớ | | | Bật sticky session của ALB nếu cần | | | Hoặc chấp nhận mất session khi failover | |

Sticky session:

aws elbv2 modify-target-group-attributes --target-group-arn <arn>   --attributes Key=stickiness.enabled,Value=true                Key=stickiness.type,Value=lb_cookie                Key=stickiness.lb_cookie.duration_seconds,Value=86400

Ba lưu ý về dữ liệu chia sẻ: | Lưu ý | Chi tiết | |---|---| | Hai máy cần thấy cùng tệp → EFS hoặc FSx | | | CSDL nên chuyển sang RDS Multi-AZ | | | Tệp tải lên nên đưa sang S3 hoặc EFS | |

Ba lưu ý về ALB: | Lưu ý | Chi tiết | |---|---| | Trải qua ít nhất hai AZ | | | Health check trỏ đúng đường dẫn ứng dụng | | | Một ALB phục vụ nhiều ứng dụng bằng listener rule | |

Ba bước tiến hoá tiếp theo (khi có thời gian): | Bước | Chi tiết | |---|---| | Đưa vào Auto Scaling group | tự thay máy hỏng | | Chuyển CSDL sang RDS | | | Rồi mới cân nhắc container hoá | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tắt hết máy ở một AZ, xem ứng dụng còn chạy không | | | Kiểm tra health check phát hiện đúng | | | Đo thời gian chuyển đổi | |

Và một lời khuyên: hãy đưa các instance vào Auto Scaling group với min=max=2 ngay cả khi chưa cần co giãn. Hai máy cố định chịu được mất một AZ, nhưng khi một máy chết vì lỗi phần cứng thì phải có người dựng lại — còn ASG sẽ tự thay máy đó trong vài phút mà không ai phải thức dậy.

Đáp án

B — Amazon FSx for Lustre.

Vì sao đúng

Đề nêu ba yêu cầu, và FSx for Lustre là dịch vụ duy nhất thoả cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Hệ thống tệp HIỆU NĂNG CAO | thông lượng hàng trăm GB/s, độ trễ dưới mili giây | | Tập dữ liệu nằm trên S3 | tích hợp S3 gốc | | TÍCH HỢP LIỀN MẠCH — object truy cập được như TỆP | import/export tự động |

Vế thứ ba là điểm quyết định:

"seamless integration so objects can be accessed AS FILES"
    → đây chính là mô tả tính năng liên kết S3 của Lustre
        ↓
    Tạo file system với ImportPath trỏ vào bucket
    → toàn bộ cây thư mục của bucket hiện ra ngay
    → ứng dụng đọc bằng open()/read() bình thường

Tạo file system liên kết S3:

aws fsx create-file-system --file-system-type LUSTRE   --storage-capacity 4800 --storage-type SSD   --subnet-ids subnet-tinh-toan   --lustre-configuration     'DeploymentType=PERSISTENT_2,PerUnitStorageThroughput=250,
     DataRepositoryConfiguration={
       ImportPath=s3://du-lieu-tai-chinh/dau-vao,
       ExportPath=s3://du-lieu-tai-chinh/ket-qua,
       AutoImportPolicy=NEW_CHANGED}'

Mount:

sudo amazon-linux-extras install -y lustre
sudo mount -t lustre -o noatime,flock   fs-abc.fsx.ap-southeast-1.amazonaws.com@tcp:/xyz /fsx

⚠ Lazy loading là điều làm "seamless" trở thành hiện thực:

Tạo file system với ImportPath
    → METADATA của mọi object hiện ra NGAY
    → NỘI DUNG chỉ tải về khi có ai đọc lần đầu
        ↓
    File system 50 TB dùng được ngay
    → không phải chờ chép trước

Vì sao Lustre cho mô hình tài chính: | Đặc điểm | Con số | |---|---| | Thông lượng | hàng trăm GB/s | | Độ trễ | dưới mili giây | | IOPS | hàng triệu |

Mô hình tài chính (định giá, mô phỏng Monte Carlo)
    → hàng trăm node đọc song song cùng tập dữ liệu
        ↓
    Đây là đúng loại tải Lustre được thiết kế cho

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Dữ liệu bền vững vẫn nằm ở S3 (rẻ) | | | Tính toán nhanh trên Lustre (đắt nhưng tạm thời) | | | Xoá file system sau khi xong, không mất dữ liệu | |

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

• **C. Amazon EFS — đây là phương án gần nhất vì cũng là hệ thống tệp chia sẻ được quản lý, nhưng nó thua ở hai điểm: thông lượng chỉ vài GB/s (kém Lustre hàng chục lần), và không có tích hợp S3 — bạn phải tự chép dữ liệu qua lại.
• **A. FSx for Windows File Server — dùng SMB cho môi trường Windows và Active Directory, không đạt thông lượng của tải HPC, và không tích hợp S3.
• **D. Amazon EBS — gắn vào một instance tại một thời điểm, không chia sẻ được cho nhiều node tính toán, và không có liên kết S3.

Ghi nhớ

⚠ Bốn dịch vụ FSx — bảng phải thuộc: | Dịch vụ | Giao thức | Đặc trưng | |---|---|---| | FSx for Lustre | Lustre | HPC + tích hợp S3 ← câu này | | FSx for Windows | SMB | Windows, AD | | FSx for NetApp ONTAP | NFS+SMB+iSCSI | đa giao thức | | FSx for OpenZFS | NFS | di chuyển từ ZFS |

Từ khoá nhận diện:

"high-performance" + "data on S3" + "access as files" → FSx for Lustre "shared Linux file system, general purpose" → EFS "Windows, SMB" → FSx for Windows "single instance block storage" → EBS

⚠ EFS và FSx for Lustre — bảng phân biệt: | | EFS | FSx for Lustre | |---|---|---| | Thông lượng | vài GB/s | hàng trăm GB/s | | Độ trễ | mili giây | dưới mili giây | | Tích hợp S3 | ❌ | ✅ import/export | | Đa AZ | ✅ | ❌ một AZ | | Giá | thấp hơn | cao hơn |

Hai kiểu triển khai Lustre: | Kiểu | Đặc điểm | |---|---| | Scratch | rẻ, KHÔNG nhân bản — cho tải tạm | | Persistent | nhân bản trong AZ, tự sửa lỗi, có sao lưu |

Chạy theo đợt rồi xoá, dữ liệu gốc ở S3 → Scratch
Chạy dài, cần dữ liệu tồn tại              → Persistent

Ba tính năng liên kết S3: | Tính năng | Việc | |---|---| | ImportPath | object S3 hiện ra như tệp (lazy load) | | ExportPath | tệp mới chảy về S3 | | AutoImportPolicy | object mới trong S3 tự hiện |

Ba giá trị AutoImportPolicy: | Giá trị | Hành vi | |---|---| | NONE | không tự đồng bộ | | NEW | object mới tự hiện | | NEW_CHANGED | object mới và bị sửa | | NEW_CHANGED_DELETED | thêm cả xoá |

Export thủ công khi cần:

aws fsx create-data-repository-task --file-system-id fs-abc   --type EXPORT_TO_REPOSITORY --paths /fsx/ket-qua   --report Enabled=true,Path=s3://du-lieu-tai-chinh/bao-cao,Format=REPORT_CSV_20191124,Scope=FAILED_FILES_ONLY

⚠ Ba mức thông lượng của Persistent: | PerUnitStorageThroughput | Đơn vị | |---|---| | 125, 250, 500, 1000 | MB/s trên mỗi TiB |

File system 4,8 TiB với 250 MB/s/TiB → 1.200 MB/s tổng
    → muốn nhanh hơn: tăng dung lượng hoặc tăng mức

Ba lưu ý về mạng: | Lưu ý | Chi tiết | |---|---| | Lustre nằm trong MỘT AZ | | | EC2 nên cùng AZ | tránh phí và độ trễ chéo | | Security group mở cổng 988 và 1018-1023 | |

Cổng là chỗ hay quên:

aws ec2 authorize-security-group-ingress --group-id sg-fsx   --protocol tcp --port 988 --source-group sg-tinh-toan
aws ec2 authorize-security-group-ingress --group-id sg-fsx   --protocol tcp --port 1018-1023 --source-group sg-tinh-toan

Ba lưu ý về client: | Lưu ý | Chi tiết | |---|---| | Lustre client là MODULE KERNEL | | | Nâng cấp kernel có thể làm mount hỏng | | | Ghim phiên bản kernel hoặc cài lại client sau mỗi lần vá | |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Tính theo dung lượng CẤP PHÁT | không phải dùng thật | | Đắt hơn S3 nhiều lần mỗi GB | | | Xoá file system khi không chạy | |

Mô hình tiết kiệm cho tải theo đợt:

1. Tạo FSx từ S3 import path
2. Chạy mô hình, ghi kết quả vào /fsx
3. Export về S3, kiểm tra báo cáo
4. Xoá file system
        ↓
    Chỉ trả tiền lưu trữ hiệu năng cao vài giờ mỗi lần

Ba dịch vụ bổ trợ cho HPC: | Dịch vụ | Việc | |---|---| | AWS ParallelCluster | dựng cụm HPC tự động | | AWS Batch | xếp lịch job | | Elastic Fabric Adapter (EFA) | mạng độ trễ cực thấp |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra tệp từ S3 hiện trong file system | | | Đo thông lượng thật | metric DataReadBytes | | Kiểm tra báo cáo export trước khi xoá | |

Và một lời khuyên: hãy kiểm tra báo cáo của tác vụ export trước khi xoá file system. Export chạy bất đồng bộ và một tệp lỗi chỉ nằm im trong báo cáo chứ không ngăn lệnh xoá — nghĩa là kết quả của cả một lần chạy mô hình có thể biến mất vì script tự động chạy nhanh hơn dữ liệu.

Đáp án

B — Bật một Amazon Route 53 health check.

Vì sao đúng

Đề mô tả một kiến trúc DR đã dựng xong và chỉ thiếu đúng một mảnh: | Hiện trạng | Vấn đề | |---|---| | Đã có bản sao ứng dụng sau ALB thứ hai ở vùng khác | hạ tầng sẵn sàng | | Cần TỰ ĐỘNG cập nhật bản ghi DNS sang ALB thứ hai | thiếu cơ chế phát hiện |

Vì sao health check là mảnh ghép:

Route 53 failover routing cần HAI thứ:
    1. Cặp bản ghi PRIMARY và SECONDARY
    2. HEALTH CHECK gắn vào bản ghi primary
        ↓
    Thiếu health check → Route 53 không biết khi nào chuyển
    → vẫn phải có người sửa DNS bằng tay

Tạo health check:

aws route53 create-health-check --caller-reference $(uuidgen)   --health-check-config '{
    "Type":"HTTPS","ResourcePath":"/health",
    "FullyQualifiedDomainName":"alb-chinh.ap-southeast-1.elb.amazonaws.com",
    "Port":443,"RequestInterval":30,"FailureThreshold":3}'

Gắn vào cặp bản ghi failover:

aws route53 change-resource-record-sets --hosted-zone-id Z123   --change-batch '{"Changes":[
    {"Action":"UPSERT","ResourceRecordSet":{
      "Name":"ungdung.vidu.com","Type":"A","SetIdentifier":"chinh",
      "Failover":"PRIMARY","HealthCheckId":"hc-abc",
      "AliasTarget":{"HostedZoneId":"Z1","DNSName":"alb-chinh...",
                     "EvaluateTargetHealth":true}}},
    {"Action":"UPSERT","ResourceRecordSet":{
      "Name":"ungdung.vidu.com","Type":"A","SetIdentifier":"du-phong",
      "Failover":"SECONDARY",
      "AliasTarget":{"HostedZoneId":"Z2","DNSName":"alb-du-phong...",
                     "EvaluateTargetHealth":true}}}]}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chuyển tự động, không cần người trực | | | Chuyển ngược lại khi vùng chính hồi phục | | | Kết hợp được với CloudWatch alarm | |

⚠ Và có ba tham số quyết định thời gian chuyển: | Tham số | Ảnh hưởng | |---|---| | RequestInterval | 30 giây (hoặc 10 giây fast) | | FailureThreshold | số lần hỏng liên tiếp | | TTL của bản ghi | client cache DNS bao lâu |

Health check phát hiện trong 90 giây (30 × 3)
    → TTL 300 giây → client vẫn dùng IP cũ thêm 5 phút
        ↓
    Thời gian ngừng thực tế gần 7 phút
    → đặt TTL 60 giây cho bản ghi failover

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

• **A. Bật một ALB health check — đây là phương án gần nhất và nghe rất giống, nhưng ALB health check chỉ hoạt động BÊN TRONG một vùng: nó quyết định gửi request tới target nào trong target group. Nó không biết gì về ALB ở vùng khác và không đụng tới DNS.
• **C. Cấu hình một alarm trên CloudTrail trail — CloudTrail ghi lại các lệnh gọi API; nó không giám sát sức khoẻ ứng dụng và không kích hoạt việc đổi DNS.
• **D. Dùng EventBridge để "cluster" các ALB — không có khái niệm này: EventBridge là dịch vụ định tuyến sự kiện, không gom hai ALB thành một cụm nào.

Ghi nhớ

⚠ Ba loại health check của AWS — bảng phải thuộc: | Health check | Phạm vi | Quyết định | |---|---|---| | Route 53 health check | TOÀN CẦU | trả bản ghi DNS nào | | ALB / NLB health check | trong một vùng | gửi request tới target nào | | Auto Scaling health check | trong một ASG | thay instance nào |

Từ khoá nhận diện:

"automatically update DNS record to another Region" → Route 53 health check "remove unhealthy target" → ELB health check "replace unhealthy instance" → ASG health check

Ba loại Route 53 health check: | Loại | Kiểm tra | |---|---| | Endpoint | gọi HTTP/HTTPS/TCP tới địa chỉ | | Calculated | gộp nhiều health check khác | | CloudWatch alarm | theo trạng thái một alarm |

⚠ Loại thứ ba rất hữu ích khi ứng dụng "sống nửa vời":

ALB trả 200 nhưng CSDL sau lưng đã hỏng
    → endpoint health check không phát hiện được
        ↓
    Tạo CloudWatch alarm trên metric CSDL
    → health check kiểu alarm gắn vào đó

aws route53 create-health-check --caller-reference $(uuidgen)   --health-check-config '{"Type":"CLOUDWATCH_METRIC",
    "AlarmIdentifier":{"Region":"ap-southeast-1","Name":"csdl-hong"},
    "InsufficientDataHealthStatus":"Unhealthy"}'

Calculated health check gộp nhiều tầng:

(ALB khoẻ) VÀ (CSDL khoẻ) VÀ (cache khoẻ)
    → chỉ coi vùng là khoẻ khi mọi tầng đều khoẻ

Bảy chính sách định tuyến Route 53: | Chính sách | Dùng cho | |---|---| | Failover | DR chính/phụ ← câu này | | Latency-based | active-active theo hiệu năng | | Geolocation | theo quốc gia | | Geoproximity | theo khoảng cách | | Weighted | triển khai từng phần | | Multivalue answer | tới 8 bản ghi khoẻ | | Simple | một đích |

⚠ EvaluateTargetHealth với bản ghi ALIAS:

Đặt EvaluateTargetHealth = true cho ALIAS trỏ tới ALB
    → Route 53 tự dùng trạng thái target của ALB
        ↓
    Với trường hợp đơn giản, không cần health check riêng
    → nhưng health check tường minh kiểm tra sâu hơn

Ba thứ khác cần chuẩn bị cho DR đa vùng: | Thứ | Vì sao | |---|---| | CSDL đã sao chép sang vùng phụ | Aurora global database | | AMI, ảnh container ở vùng phụ | | | Chứng chỉ ACM ở vùng phụ | ACM theo vùng |

Bốn chiến lược DR: | Chiến lược | RTO | RPO | |---|---|---| | Backup & Restore | giờ - ngày | giờ | | Pilot Light | chục phút | phút - giây | | Warm Standby | phút | giây | | Multi-Site Active-Active | gần 0 | gần 0 |

Ba lưu ý về chi phí health check: | Khoản | Chi tiết | |---|---| | Health check trong AWS rẻ hơn ngoài AWS | | | Fast interval (10 giây) đắt hơn | | | Calculated health check tính riêng | |

Ba lưu ý khi cấu hình: | Lưu ý | Chi tiết | |---|---| | Đường dẫn health check phải NHẸ | không truy vấn CSDL nặng | | Nhưng phải kiểm tra được phụ thuộc chính | | | TTL ngắn cho bản ghi failover | |

⚠ Cân bằng giữa hai vế đầu:

/health chỉ trả "OK" → không phát hiện CSDL hỏng
/health truy vấn cả CSDL → mỗi 30 giây một truy vấn, từ nhiều nơi
        ↓
    Cách thường dùng: kiểm tra phụ thuộc và CACHE kết quả 10 giây

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạm ngắt vùng chính, đo thời gian chuyển | | | Kiểm tra chuyển ngược khi hồi phục | | | Đặt alarm khi health check đổi trạng thái | |

aws cloudwatch put-metric-alarm --alarm-name canh-bao-failover   --namespace AWS/Route53 --metric-name HealthCheckStatus   --dimensions Name=HealthCheckId,Value=hc-abc   --statistic Minimum --period 60 --evaluation-periods 1   --threshold 1 --comparison-operator LessThanThreshold

Và một lời khuyên: hãy đặt alarm để được báo mỗi khi health check đổi trạng thái. Chuyển vùng tự động là điều bạn muốn, nhưng chuyển vùng tự động mà không ai biết thì bạn sẽ chạy trên hạ tầng DR nhiều ngày liền — và chỉ phát hiện ra khi hoá đơn hoặc độ trễ nói cho bạn.

Đáp án

D — Dùng CloudFormation kèm script.

Vì sao đúng

Đề nêu bốn yêu cầu, và CloudFormation là công cụ đúng: | Yêu cầu | Cách đáp ứng | |---|---| | Tạo NHIỀU tài khoản thành viên | AWS::Organizations::Account | | TỰ ĐỘNG và LẶP LẠI ĐƯỢC | template khai báo, kết quả giống nhau mỗi lần | | Đưa tài khoản vào OU | thuộc tính ParentIds | | Tạo VPC và subnet trong từng tài khoản | StackSets triển khai xuống tài khoản mới |

Vì sao "lặp lại được" là từ khoá:

"automatically and REPEATABLY"
    → CLI và API làm được, nhưng là các bước rời rạc
    → phải tự viết logic xử lý lỗi, tự theo dõi trạng thái
        ↓
    CloudFormation mô tả TRẠNG THÁI MONG MUỐN
    → chạy lại cho ra cùng kết quả
    → tự rollback khi lỗi giữa chừng

Template tạo tài khoản:

Resources:
  TaiKhoanDoiA:
    Type: AWS::Organizations::Account
    Properties:
      AccountName: doi-a-san-xuat
      Email: aws-doi-a@congty.com
      ParentIds:
        - ou-abc1-11111111
      Tags:
        - Key: moi-truong
          Value: san-xuat

Và StackSets đưa VPC xuống mọi tài khoản:

aws cloudformation create-stack-set --stack-set-name mang-co-ban   --template-body file://vpc.yaml   --permission-model SERVICE_MANAGED   --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false   --capabilities CAPABILITY_NAMED_IAM

aws cloudformation create-stack-instances --stack-set-name mang-co-ban   --deployment-targets OrganizationalUnitIds=ou-abc1-11111111   --regions ap-southeast-1

⚠ --auto-deployment Enabled=true là tham số quan trọng nhất:

Tài khoản MỚI được thêm vào OU
    → StackSet TỰ ĐỘNG triển khai VPC vào đó
        ↓
    Đây chính là nghĩa của "repeatably"
    → không phải nhớ chạy thêm bước nào

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hạ tầng dưới dạng mã, kiểm soát phiên bản | | | Tự rollback khi lỗi giữa chừng | | | Xem trước thay đổi bằng change set | |

Vì sao đáp án nói "kèm script":

CloudFormation lo phần khai báo hạ tầng
    → nhưng vẫn cần script cho:
    → sinh danh sách tài khoản và email
    → gọi deploy theo thứ tự
    → kiểm tra kết quả
        ↓
    Đây là mô hình thực tế: IaC + tự động hoá bao quanh

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

• **B. Dùng AWS Organizations API — đây là phương án gần nhất vì API đúng là thứ CloudFormation gọi bên dưới, nhưng dùng API trực tiếp nghĩa là tự viết toàn bộ logic: tạo tài khoản, chờ hoàn tất, di chuyển vào OU, rồi assume role sang tài khoản mới để tạo VPC, xử lý lỗi ở từng bước. CloudFormation đóng gói sẵn tất cả.
• **A. Dùng AWS CLI — cùng vấn đề, ở mức thấp hơn nữa: một chuỗi lệnh rời rạc, không có trạng thái mong muốn, không rollback, và rất khó đảm bảo kết quả giống nhau mỗi lần.
• **C. Dùng AWS Management Console — thủ công hoàn toàn, ngược hẳn yêu cầu "automatically and repeatably".

Ghi nhớ

⚠ Ba công cụ dựng tài khoản hàng loạt — bảng phải thuộc: | Công cụ | Đặc điểm | |---|---| | AWS Control Tower | landing zone dựng sẵn, có guardrail | | CloudFormation + StackSets | linh hoạt, kiểm soát hoàn toàn ← câu này | | Account Factory for Terraform (AFT) | nếu dùng Terraform |

⚠ Control Tower đáng biết — thường là câu trả lời tốt hơn trong thực tế:

Control Tower Account Factory:
    → tạo tài khoản theo mẫu chuẩn
    → tự áp guardrail (SCP + Config rule)
    → tự dựng log tập trung và audit
        ↓
    Nếu đề có Control Tower thì thường đó là đáp án
    → CloudFormation là lựa chọn khi cần tuỳ biến sâu

Từ khoá nhận diện:

"automatically and repeatably" + hạ tầng → CloudFormation "deploy to many accounts and Regions" → StackSets "governed landing zone with guardrails" → Control Tower "one-off manual task" → console (hầu như luôn sai trong đề)

Ba khái niệm CloudFormation: | Khái niệm | Nghĩa | |---|---| | Template | mô tả trạng thái mong muốn | | Stack | một lần triển khai template | | StackSet | triển khai một stack ra nhiều tài khoản và vùng |

Hai mô hình quyền của StackSets: | Mô hình | Đặc điểm | |---|---| | SELF_MANAGED | tự tạo IAM role ở tài khoản đích | | SERVICE_MANAGED | dùng Organizations, có auto-deployment |

SERVICE_MANAGED là lựa chọn đúng khi đã có Organizations
    → không phải tạo role thủ công ở từng tài khoản
    → và có auto-deployment cho tài khoản mới

Ba đặc điểm của AWS::Organizations::Account: | Đặc điểm | Chi tiết | |---|---| | Mỗi tài khoản cần một EMAIL DUY NHẤT | | | Xoá stack KHÔNG xoá tài khoản | chỉ gỡ khỏi quản lý | | Tạo tài khoản mất vài phút | |

⚠ Email duy nhất là ràng buộc thực tế:

Mỗi tài khoản AWS cần một địa chỉ email riêng
    → dùng subaddressing: aws+doi-a@congty.com
    → hoặc tạo alias trong hệ thống mail
        ↓
    Lên kế hoạch đặt tên email TRƯỚC khi tạo hàng loạt

Ba tính năng CloudFormation nên dùng: | Tính năng | Việc | |---|---| | Change set | xem trước thay đổi | | Drift detection | phát hiện ai sửa tay | | DeletionPolicy: Retain | giữ tài nguyên quan trọng |

aws cloudformation create-change-set --stack-name mang-co-ban   --template-body file://vpc-moi.yaml --change-set-name thay-doi-1

aws cloudformation describe-change-set --change-set-name thay-doi-1   --stack-name mang-co-ban --query "Changes[].ResourceChange.[Action,LogicalResourceId]"

Ba lưu ý về StackSets: | Lưu ý | Chi tiết | |---|---| | Triển khai theo đợt để giảm rủi ro | | | FailureTolerance giới hạn số lỗi | | | MaxConcurrentPercentage điều khiển tốc độ | |

aws cloudformation update-stack-set --stack-set-name mang-co-ban   --operation-preferences     FailureTolerancePercentage=10,MaxConcurrentPercentage=25,RegionConcurrencyType=PARALLEL

Ba lựa chọn IaC khác: | Công cụ | Đặc điểm | |---|---| | AWS CDK | viết bằng ngôn ngữ lập trình, sinh CloudFormation | | Terraform | đa nhà cung cấp | | AWS SAM | tối ưu cho serverless |

CDK đáng cân nhắc cho việc này:

for (const doi of ['doi-a', 'doi-b', 'doi-c']) {
  new CfnAccount(this, `TaiKhoan-${doi}`, {
    accountName: doi,
    email: `aws+${doi}@congty.com`,
    parentIds: [ouId],
  });
}

Vòng lặp trong ngôn ngữ thật
    → dễ hơn nhiều so với lặp trong YAML

Ba thứ nên có trong mọi tài khoản mới: | Thứ | Vì sao | |---|---| | VPC chuẩn và subnet | ← đề yêu cầu | | CloudTrail và Config | audit | | SCP từ OU | guardrail |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm tra tài khoản đã vào đúng OU | | | Kiểm tra VPC đã tạo ở tài khoản mới | | | Chạy drift detection sau vài tuần | |

aws organizations list-accounts-for-parent --parent-id ou-abc1-11111111
aws cloudformation list-stack-instances --stack-set-name mang-co-ban

Và một lời khuyên: hãy bật auto-deployment cho StackSet ngay khi tạo. Đó là khác biệt giữa một quy trình thực sự lặp lại được và một quy trình mà ai đó phải nhớ chạy thêm một lệnh mỗi lần có tài khoản mới — và người ta luôn quên đúng lần quan trọng nhất.

Đáp án

D — AWS Lake Formation.

Vì sao đúng

Đề nêu ba yêu cầu, và Lake Formation là dịch vụ được thiết kế cho việc này: | Yêu cầu | Cách đáp ứng | |---|---| | Xây một KHO DỮ LIỆU TẬP TRUNG | Lake Formation dựng và quản trị data lake | | Gom dữ liệu đám mây đang có | đăng ký vị trí S3 vào data lake | | DỄ lấy dữ liệu từ RDS MySQL | blueprint nạp từ CSDL quan hệ có sẵn |

Vế thứ ba là điểm quyết định:

"easily retrieve data from the database"
    → Lake Formation có BLUEPRINT dựng sẵn cho JDBC
    → tự sinh workflow Glue để nạp từ RDS vào data lake
        ↓
    Không phải tự viết job ETL

Dựng data lake:

aws lakeformation register-resource   --resource-arn arn:aws:s3:::ho-du-lieu-ml   --use-service-linked-role

aws lakeformation grant-permissions   --principal DataLakePrincipalIdentifier=<arn-role-ml>   --resource '{"Table":{"DatabaseName":"du_lieu_van_hanh",
                        "TableWildcard":{}}}'   --permissions SELECT DESCRIBE

Blueprint nạp từ RDS:

Lake Formation console → Blueprints → Database snapshot
    → chọn kết nối JDBC tới RDS MySQL
    → chọn bảng nguồn và đích trong data lake
    → nó sinh ra một Glue workflow hoàn chỉnh
        ↓
    Chạy một lần hoặc theo lịch (incremental)

⚠ Vì sao Lake Formation hơn S3 thuần: | | S3 thuần | Lake Formation | |---|---|---| | Lưu trữ | ✅ | ✅ (dùng S3 bên dưới) | | Danh mục dữ liệu | ❌ tự dựng | ✅ Glue Data Catalog | | Phân quyền theo BẢNG, CỘT, DÒNG | ❌ chỉ theo tiền tố | ✅ | | Nạp từ CSDL quan hệ | tự viết | ✅ blueprint | | Audit truy cập dữ liệu | thô | ✅ |

Phân quyền chi tiết là giá trị lớn nhất:

-- Chỉ cho phép đọc vài cột
aws lakeformation grant-permissions   --principal DataLakePrincipalIdentifier=<arn-role-phan-tich>   --resource '{"TableWithColumns":{
      "DatabaseName":"du_lieu_van_hanh","Name":"khach_hang",
      "ColumnNames":["ma_kh","khu_vuc","doanh_thu"]}}'   --permissions SELECT

Nhà khoa học dữ liệu thấy được doanh thu
    → nhưng KHÔNG thấy cột số điện thoại hay email
        ↓
    Với S3 thuần thì phải tách thành hai bucket

Ba lợi ích cho MLOps: | Lợi ích | Chi tiết | |---|---| | Một danh mục cho mọi nguồn dữ liệu | | | SageMaker, Athena, EMR đều truy cập được | | | Phân quyền tập trung, không rải rác | |

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

• **C. Amazon S3 — đây là phương án gần nhất và thực sự là tầng lưu trữ của mọi data lake trên AWS, nhưng bản thân S3 chỉ là kho object: không có danh mục, không có phân quyền theo cột, và không có cơ chế nào để "dễ dàng lấy dữ liệu từ RDS". Lake Formation là lớp quản trị đặt trên S3 và bổ sung đúng những phần đó.
• **A. Amazon Neptune — CSDL đồ thị, dùng cho dữ liệu quan hệ mạng lưới (mạng xã hội, phát hiện gian lận theo liên kết). Không phải kho dữ liệu tập trung cho học máy.
• **B. Amazon QLDB — sổ cái bất biến cho dữ liệu cần chứng minh toàn vẹn bằng mật mã. Không phải data lake và không hợp cho phân tích quy mô lớn.

Ghi nhớ

⚠ Bốn CSDL chuyên biệt hay bị hỏi — bảng phải thuộc: | Dịch vụ | Đặc trưng | |---|---| | AWS Lake Formation | dựng và quản trị DATA LAKE | | Amazon Neptune | CSDL đồ thị | | Amazon QLDB | sổ cái bất biến | | Amazon Timestream | chuỗi thời gian |

Từ khoá nhận diện:

"centralized data repository", "data lake", "governance" → Lake Formation "graph, relationships, connections" → Neptune "immutable ledger, cryptographic verification" → QLDB "IoT sensor time-series" → Timestream

⚠ Ba tầng của một data lake trên AWS: | Tầng | Dịch vụ | |---|---| | Lưu trữ | Amazon S3 | | Danh mục | AWS Glue Data Catalog | | Quản trị và phân quyền | AWS Lake Formation |

Lake Formation KHÔNG thay thế S3
    → nó là lớp quản trị ĐẶT TRÊN S3 và Glue
        ↓
    Đó là lý do C không sai hoàn toàn, nhưng thiếu

Ba khả năng chính của Lake Formation: | Khả năng | Chi tiết | |---|---| | Blueprint nạp dữ liệu | từ RDS, S3, log | | Phân quyền chi tiết | bảng, cột, dòng, ô | | LF-Tags | phân quyền theo thẻ, mở rộng tốt |

LF-Tags là cách quản trị quy mô lớn:

aws lakeformation create-lf-tag --tag-key do-nhay-cam   --tag-values cong-khai noi-bo mat

aws lakeformation add-lf-tags-to-resource   --resource '{"Table":{"DatabaseName":"du_lieu","Name":"khach_hang"}}'   --lf-tags TagKey=do-nhay-cam,TagValues=mat

aws lakeformation grant-permissions   --principal DataLakePrincipalIdentifier=<arn-role>   --resource '{"LFTagPolicy":{"ResourceType":"TABLE",
    "Expression":[{"TagKey":"do-nhay-cam","TagValues":["cong-khai"]}]}}'   --permissions SELECT

Gán thẻ cho dữ liệu, cấp quyền theo thẻ
    → thêm bảng mới gắn thẻ là tự có quyền đúng
        ↓
    Không phải cấp quyền cho từng bảng

Ba loại blueprint: | Loại | Nạp từ | |---|---| | Database snapshot | toàn bộ bảng RDS một lần | | Incremental database | chỉ dữ liệu mới (dùng bookmark) | | Log file | CloudTrail, ALB log |

Incremental blueprint hợp với đề:

Chạy hằng đêm, chỉ nạp bản ghi mới từ RDS
    → dùng cột tăng dần (id hoặc timestamp) làm bookmark
        ↓
    Data lake luôn có dữ liệu mới mà không nạp lại toàn bộ

Ba dịch vụ tiêu thụ data lake: | Dịch vụ | Việc | |---|---| | Amazon Athena | truy vấn SQL | | Amazon SageMaker | huấn luyện mô hình | | Amazon EMR / Redshift Spectrum | xử lý lớn |

Ba lưu ý về định dạng dữ liệu: | Lưu ý | Chi tiết | |---|---| | Parquet rẻ và nhanh hơn CSV nhiều | | | Phân vùng theo ngày hoặc khu vực | | | Nén (Snappy, ZSTD) | |

⚠ Ba định dạng bảng mở đáng biết: | Định dạng | Đặc điểm | |---|---| | Apache Iceberg | hỗ trợ ACID, time travel, schema evolution | | Apache Hudi | cập nhật và xoá theo bản ghi | | Delta Lake | |

Data lake truyền thống chỉ ghi thêm
    → Iceberg cho phép UPDATE và DELETE
    → và xem dữ liệu tại một thời điểm trong quá khứ
        ↓
    Athena và Glue đều hỗ trợ Iceberg

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lake Formation không tính phí riêng | trả cho S3, Glue, Athena | | Glue job tính theo DPU-giờ | | | Athena tính theo dữ liệu quét | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Mã hoá S3 bằng KMS | | | Lake Formation ghi log truy cập dữ liệu | | | Kết hợp Macie tìm dữ liệu nhạy cảm | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy blueprint và kiểm tra bảng xuất hiện | | | Thử truy vấn Athena với role hạn chế | | | Xác nhận cột nhạy cảm bị ẩn đúng | |

Và một lời khuyên: hãy thiết kế hệ thống LF-Tags trước khi có nhiều bảng. Cấp quyền cho từng bảng chạy được với mười bảng nhưng không quản nổi với năm trăm — còn gán thẻ theo mức độ nhạy cảm ngay từ đầu thì mọi bảng mới tự động có đúng quyền mà không ai phải nhớ cấp.

Đáp án

C — Thiết lập AWS Global Accelerator và thêm các endpoint.

Vì sao đúng

Đề nêu ba dữ kiện, và Global Accelerator khớp cả ba: | Dữ kiện | Cách đáp ứng | |---|---| | Ứng dụng ở NHIỀU VÙNG, truy cập toàn cầu | anycast định tuyến tới vùng tối ưu | | **Ứng dụng phơi bày IP CÔNG KHAI TĨNH | Global Accelerator cung cấp 2 IP tĩnh | | Một số người dùng chậm khi đi qua Internet | chặng dài chạy trên mạng xương sống AWS |

Vế thứ hai là gợi ý mạnh nhất:

"The application exposes STATIC PUBLIC IP ADDRESSES"
    → CloudFront có IP thay đổi
    → Route 53 chỉ trả IP của endpoint
        ↓
    Global Accelerator là dịch vụ duy nhất
    tự cung cấp IP tĩnh anycast

Global Accelerator giảm độ trễ thế nào:

Không có GA:  client ──── Internet công cộng ────▶ endpoint
              → qua nhiều nhà mạng, đường đi thay đổi
              → độ trễ dao động, mất gói

Có GA:        client ──▶ edge AWS gần nhất (vài chục ms)
                        │
                        └── MẠNG XƯƠNG SỐNG AWS ──▶ endpoint
              → chặng dài chạy trên mạng riêng

Cấu hình:

aws globalaccelerator create-accelerator --name tang-toc-ung-dung   --ip-address-type IPV4 --enabled

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

aws globalaccelerator create-endpoint-group   --listener-arn <arn-listener> --endpoint-group-region ap-southeast-1   --endpoint-configurations EndpointId=<arn-alb-sg>,Weight=100

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

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hai IP tĩnh — không đổi suốt đời accelerator | | | Chuyển vùng nhanh, không phụ thuộc DNS cache | | | Hiệu năng ổn định hơn Internet công cộng | |

Vế thứ hai đáng nhấn mạnh:

Route 53 failover: đổi bản ghi DNS
    → client phải chờ TTL hết hạn
        ↓
Global Accelerator: IP KHÔNG đổi
    → chỉ đổi đích phía sau
    → client không cần phân giải lại gì

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

• **B. Dựng CloudFront distribution — đây là phương án gần nhất vì cũng dùng mạng edge của AWS và cũng giảm độ trễ, nhưng nó không phù hợp với dữ kiện IP tĩnh: CloudFront có dải IP thay đổi liên tục. Và CloudFront tối ưu cho nội dung cache được; với ứng dụng động đa vùng cần định tuyến theo hiệu năng thì Global Accelerator đúng hơn.
• **A. Dùng Route 53 geoproximity routing — định tuyến theo khoảng cách địa lý, không theo hiệu năng mạng thật. Và nó là DNS nên phụ thuộc cache của client, chuyển vùng chậm hơn.
• **D. Dựng Direct Connect ở nhiều vùng — DX nối trung tâm dữ liệu của bạn với AWS. Nó hoàn toàn không giúp gì cho người dùng cuối trên Internet.

Ghi nhớ

⚠ CloudFront và Global Accelerator — bảng phải thuộc: | | CloudFront | Global Accelerator | |---|---|---| | Có cache | ✅ | ❌ | | Giao thức | HTTP/HTTPS | TCP và UDP | | IP | thay đổi | 2 IP TĨNH anycast | | Tối ưu cho | nội dung tĩnh, web | ứng dụng động, non-HTTP | | Failover đa vùng | origin group | rất nhanh, không qua DNS |

Từ khoá nhận diện:

"static IP" + "multiple Regions" + "reduce internet latency" → Global Accelerator "cache static content globally" → CloudFront "UDP, gaming, VoIP" → Global Accelerator "connect on-premises to AWS" → Direct Connect

⚠ Ba đặc điểm của Global Accelerator: | Đặc điểm | Chi tiết | |---|---| | Hai IP tĩnh từ hai network zone | | | Hỗ trợ ALB, NLB, EC2, Elastic IP | KHÔNG hỗ trợ S3 | | Health check chủ động tới endpoint | |

Ba tham số điều khiển lưu lượng: | Tham số | Việc | |---|---| | Traffic dial (0-100%) | rút lưu lượng khỏi một vùng | | Endpoint weight | tỷ lệ trong cùng nhóm | | Client affinity | giữ client ở cùng endpoint |

Traffic dial cho triển khai an toàn:

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

Đặt 10% cho vùng vừa triển khai bản mới
    → quan sát lỗi → tăng dần lên 100
        ↓
    Blue-green giữa các vùng

Hai loại accelerator: | Loại | Dùng cho | |---|---| | Standard | định tuyến tới endpoint tối ưu | | Custom routing | ánh xạ cổng tới instance cụ thể (game, VoIP) |

Ba trường hợp Global Accelerator toả sáng: | Trường hợp | Chi tiết | |---|---| | Ứng dụng đa vùng cần failover nhanh | ← câu này | | Giao thức không phải HTTP | | | Khách hàng cần IP tĩnh cho allowlist | |

⚠ Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Phí cố định theo GIỜ | ~0,025 USD/giờ | | Phí truyền dữ liệu cao cấp theo GB | | | Đắt hơn Route 53 đáng kể | |

Route 53 latency-based gần như miễn phí
    → chỉ dùng Global Accelerator khi thực sự cần
      IP tĩnh, failover nhanh, hoặc non-HTTP

Ba lưu ý khi kết hợp với CloudFront: | Lưu ý | Chi tiết | |---|---| | CloudFront cho nội dung tĩnh | | | Global Accelerator cho API và nội dung động | | | Hai dịch vụ bổ sung, không thay thế | |

Bảy chính sách định tuyến Route 53 (để so sánh): | Chính sách | Chọn theo | |---|---| | Latency-based | độ trễ mạng đo được | | Geolocation | quốc gia | | Geoproximity | khoảng cách + bias | | Failover | health check | | Weighted | tỷ lệ | | Multivalue | tới 8 bản ghi khoẻ | | Simple | một đích |

⚠ Route 53 latency và Global Accelerator — chọn cái nào:

Cả hai đều định tuyến theo hiệu năng
    → Route 53: qua DNS, rẻ, nhưng phụ thuộc cache
    → GA:       qua anycast, tất định, chuyển nhanh
        ↓
    Đề nhắc tới IP TĨNH → Global Accelerator

Ba lưu ý về client affinity: | Giá trị | Hành vi | |---|---| | NONE | mỗi kết nối định tuyến độc lập | | SOURCE_IP | cùng IP nguồn tới cùng endpoint |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | HealthyEndpointCount | endpoint nào còn sống | | NewFlowCount | lượng kết nối mới | | ProcessedBytesIn/Out | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ từ nhiều khu vực trước và sau | | | Tắt một vùng, đo thời gian chuyển | | | Ghi hai IP tĩnh vào tài liệu vận hành | |

Và một lời khuyên: hãy ghi lại hai địa chỉ IP tĩnh vào tài liệu ngay khi tạo accelerator. Chúng là thứ khách hàng doanh nghiệp đưa vào tường lửa của họ, và xoá rồi tạo lại accelerator sẽ cấp một cặp IP hoàn toàn khác — kéo theo một vòng làm việc với từng khách hàng để cập nhật.

Đáp án

C — Mã hoá tài liệu bằng client-side encryption với customer managed key, rồi tải tệp đã mã hoá lên S3.

Vì sao đúng

Đề nêu hai yêu cầu, và chỉ một phương án thoả cả hai: | Yêu cầu | Ý nghĩa | |---|---| | Mã hoá tài liệu TRƯỚC KHI lưu vào S3 | mã hoá phải xảy ra ở phía client | | Tuân thủ quy định bảo mật nghiêm ngặt của cơ quan chính phủ | cơ quan phải kiểm soát khoá |

Vế đầu loại sạch mọi phương án server-side:

Server-side encryption (SSE):
    tài liệu đi TRẦN tới S3 (trong đường TLS)
    → S3 nhận rồi mới mã hoá khi ghi xuống đĩa
        ↓
    Tại thời điểm S3 nhận, dữ liệu chưa được mã hoá
    → không thoả "encrypt BEFORE storing"

Client-side encryption:
    tài liệu được mã hoá TRÊN MÁY của cơ quan
    → S3 chỉ nhận một khối byte vô nghĩa

Và vì sao customer managed key chứ không phải khoá do S3 quản lý:

Khoá của S3 nằm trong hạ tầng AWS
    → cơ quan không kiểm soát được vòng đời khoá
        ↓
    Customer managed key (trong KMS hoặc tự giữ):
    → cơ quan đặt key policy, bật xoay khoá,
      vô hiệu hoá khoá khi cần

Cách hoạt động (envelope encryption):

1. Client gọi KMS: GenerateDataKey
2. KMS trả về data key dạng THÔ + dạng ĐÃ MÃ HOÁ
3. Client dùng data key thô mã hoá tài liệu
4. Client xoá data key thô khỏi bộ nhớ
5. Tải lên S3: tài liệu mã hoá + data key mã hoá (trong metadata)
        ↓
    Khi đọc: gửi data key mã hoá cho KMS giải mã

Dùng AWS Encryption SDK:

import boto3
from aws_encryption_sdk import EncryptionSDKClient, StrictAwsKmsMasterKeyProvider

client = EncryptionSDKClient()
kp = StrictAwsKmsMasterKeyProvider(
    key_ids=['arn:aws:kms:ap-southeast-1:123456789012:key/abc-123'])

with open('tai-lieu-mat.pdf', 'rb') as f:
    du_lieu_ma_hoa, header = client.encrypt(source=f.read(), key_provider=kp)

boto3.client('s3').put_object(
    Bucket='kho-tai-lieu-mat', Key='tai-lieu-mat.pdf', Body=du_lieu_ma_hoa)

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | AWS KHÔNG BAO GIỜ thấy dữ liệu trần | | | Cơ quan kiểm soát hoàn toàn khoá | | | Vẫn có audit đầy đủ trong CloudTrail | |

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

• **B. SSE-KMS với key policy tuỳ chỉnh — đây là phương án gần nhất và là lựa chọn tốt nhất cho hầu hết trường hợp thực tế, nhưng nó mã hoá sau khi S3 nhận dữ liệu, không phải trước khi tải lên. Đề nêu ràng buộc rất cụ thể ở chỗ này.
• **D. SSE-C (khoá do khách cung cấp) — vẫn là server-side: bạn gửi khoá kèm request, S3 dùng nó để mã hoá sau khi nhận. Và phải tự quản lý khoá, gửi theo mỗi request.
• **A. Client-side encryption với khoá do Amazon S3 quản lý — mô tả một thứ không tồn tại: "S3 managed keys" (SSE-S3) chỉ có ở phía máy chủ. Không có cơ chế nào để S3 quản lý khoá mà mã hoá lại diễn ra ở client.

Ghi nhớ

⚠ Bốn lựa chọn mã hoá S3 — bảng phải thuộc: | Lựa chọn | Mã hoá ở đâu | Ai giữ khoá | |---|---|---| | SSE-S3 | máy chủ S3 | AWS hoàn toàn | | SSE-KMS | máy chủ S3 | KMS, bạn đặt policy | | SSE-C | máy chủ S3 | bạn — gửi mỗi request | | Client-side (CSE) | MÁY CLIENT | bạn |

Từ khoá nhận diện:

"encrypt BEFORE upload", "AWS must never see plaintext" → client-side encryption "audit key usage, control key policy" → SSE-KMS "simplest, default" → SSE-S3 "reduce KMS costs" → S3 Bucket Key

⚠ SSE-S3 giờ là MẶC ĐỊNH:

Từ 01/2023, mọi object mới trong mọi bucket
    tự động được mã hoá bằng SSE-S3
        ↓
    Câu hỏi giờ là "có nâng lên SSE-KMS hoặc CSE không"

⚠ Ba nhược điểm của client-side encryption — phải cân nhắc thật: | Nhược điểm | Chi tiết | |---|---| | Mất khả năng dùng dịch vụ AWS xử lý dữ liệu | Athena, Glue, Macie không đọc được | | Phải quản lý thư viện mã hoá ở mọi client | | | Tự lo tương thích khi đổi cách mã hoá | |

Dòng đầu là cái giá lớn nhất:

Dữ liệu mã hoá phía client trong S3
    → Athena không truy vấn được
    → Macie không quét được dữ liệu nhạy cảm
    → S3 Select không dùng được
        ↓
    S3 chỉ còn là nơi cất khối byte

Ba loại khoá KMS: | Loại | Kiểm soát | |---|---| | AWS managed key (aws/s3) | AWS quản lý, xoay hằng năm | | Customer managed key | bạn đặt policy, bật xoay, vô hiệu hoá được | | AWS owned key | không thấy được |

Ba lợi ích của customer managed key: | Lợi ích | Chi tiết | |---|---| | Đặt key policy riêng | ai được dùng khoá | | Bật xoay khoá tự động | | | Vô hiệu hoá khoá = khoá sạch dữ liệu | |

aws kms disable-key --key-id <id>

Vô hiệu hoá khoá → mọi dữ liệu mã hoá bằng nó
    không giải mã được nữa
        ↓
    Cách "phá huỷ mật mã" nhanh khi nghi bị xâm nhập

Ba khái niệm KMS cần biết: | Khái niệm | Nghĩa | |---|---| | Envelope encryption | data key mã hoá dữ liệu, KMS mã hoá data key | | GenerateDataKey | trả về data key thô + đã mã hoá | | Key policy | nguồn quyền CHÍNH trên khoá |

⚠ Ba lưu ý về key policy: | Lưu ý | Chi tiết | |---|---| | Key policy là nguồn quyền chính | IAM policy một mình không đủ | | Phải cho tài khoản quyền quản lý khoá | | | Sai policy có thể khoá vĩnh viễn | |

Key policy không cho ai quyền kms:PutKeyPolicy
    → không ai sửa được chính sách đó nữa
    → khoá và mọi dữ liệu dùng nó bị khoá vĩnh viễn
        ↓
    AWS Support cũng không gỡ được

Ba thư viện hỗ trợ client-side encryption: | Thư viện | Đặc điểm | |---|---| | AWS Encryption SDK | đa ngôn ngữ, có định dạng thông điệp chuẩn | | Amazon S3 Encryption Client | tích hợp sẵn với S3 | | DynamoDB Encryption Client | cho DynamoDB |

Ba lựa chọn cho tuân thủ rất nghiêm ngặt: | Lựa chọn | Đặc điểm | |---|---| | CSE với KMS | ← câu này | | AWS CloudHSM | HSM riêng, FIPS 140-2 Level 3 | | KMS External Key Store (XKS) | khoá nằm ngoài AWS hoàn toàn |

XKS đáng biết cho cơ quan chính phủ:

Khoá gốc nằm trong HSM của chính cơ quan
    → AWS gọi ra ngoài để dùng khoá
        ↓
    AWS không bao giờ giữ khoá
    → mức kiểm soát cao nhất

Ba lưu ý về vận hành: | Lưu ý | Chi tiết | |---|---| | Ghi tài liệu khoá nào dùng cho dữ liệu nào | | | Bật xoay khoá tự động | | | Đặt alarm trên kms:Decrypt bất thường | |

Và một lời khuyên: hãy hỏi lại bộ phận tuân thủ xem SSE-KMS có đủ không trước khi chọn client-side encryption. Rất nhiều yêu cầu "phải mã hoá trước khi đưa lên đám mây" thực chất được thoả bằng SSE-KMS với customer managed key — và cái giá của CSE là mất hẳn mọi công cụ phân tích và quét dữ liệu của AWS.