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

Đáp án

D — Dùng Aurora MySQL với Multi-AZ Aurora Replica, và tạo database dev bằng cách khôi phục từ bản sao lưu tự động của Aurora.

Vì sao đúng

Đề nêu vấn đề rất cụ thể: sao chép toàn bộ database sản xuất mỗi sáng làm người dùng bị chậm.

Nguyên nhân:
    Sao chép đầy đủ đọc TOÀN BỘ dữ liệu từ database sản xuất
    → chiếm I/O, CPU và bộ nhớ đệm
    → truy vấn của người dùng bị đẩy vào hàng chờ
        ↓
    Cần cách tạo database dev mà KHÔNG ĐỤNG tới instance sản xuất

Và khôi phục từ bản sao lưu tự động làm đúng điều đó:

Aurora automated backup:
    → được chụp LIÊN TỤC ở TẦNG LƯU TRỮ
    → KHÔNG ảnh hưởng hiệu năng của instance database
        ↓
    Khôi phục thành cụm MỚI:
    → đọc từ bản sao lưu, không đọc từ cụm sản xuất
    → cụm sản xuất KHÔNG bị ảnh hưởng gì

aws rds restore-db-cluster-to-point-in-time   --db-cluster-identifier cum-dev   --source-db-cluster-identifier cum-san-xuat   --restore-type copy-on-write   --use-latest-restorable-time

Và copy-on-write là điểm rất đáng chú ý:

Aurora database cloning với copy-on-write:
    → tạo bản sao gần như TỨC THÌ
    → KHÔNG sao chép dữ liệu ban đầu
    → chỉ ghi các trang bị THAY ĐỔI
        ↓
    Vài phút thay vì vài giờ
    Chi phí lưu trữ ban đầu gần bằng 0

Và vế "tải đọc nặng" được giải quyết bằng Aurora Replica:

Aurora Replica:
    → tới 15 replica, độ trễ dưới 100ms
    → dùng chung tầng lưu trữ, không tốn tài nguyên writer
    → reader endpoint tự cân bằng tải

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

• **B. Aurora MySQL với Multi-AZ replica, nhưng khôi phục database dev bằng mysqldump — đây là phương án gần nhất và vế Aurora hoàn toàn đúng, nhưng vế thứ hai không giải quyết vấn đề gốc: mysqldump đọc toàn bộ dữ liệu từ database đang chạy — chính xác là hành vi đang gây chậm. Đổi engine mà giữ nguyên cách sao chép thì triệu chứng vẫn còn.
• **A. RDS for SQL Server Multi-AZ với read replica, dùng read replica làm database dev — hai vấn đề: đề nói rõ sẵn sàng đổi engine để cải thiện khả năng mở rộng đọc, mà RDS SQL Server có giới hạn về read replica. Và dùng replica làm dev là nguy hiểm: replica chỉ đọc, đội phát triển không ghi được, và nếu promote thì mất khả năng mở rộng đọc.
• **C. RDS MySQL Multi-AZ, dùng standby instance làm database dev — không làm được về mặt kỹ thuật: standby của Multi-AZ KHÔNG truy cập được, nó chỉ tồn tại để chuyển đổi.

Ghi nhớ

Ba cách tạo bản sao database cho dev — bảng so sánh: | Cách | Ảnh hưởng sản xuất | Tốc độ | |---|---|---| | mysqldump từ instance đang chạy | CAO — đọc toàn bộ dữ liệu | chậm | | Khôi phục từ snapshot hoặc backup | KHÔNG | vừa | | Aurora database cloning (copy-on-write) | KHÔNG | gần như tức thì ← tốt nhất |

Aurora database cloning là tính năng rất mạnh:

aws rds restore-db-cluster-to-point-in-time   --db-cluster-identifier cum-dev   --source-db-cluster-identifier cum-san-xuat   --restore-type copy-on-write --use-latest-restorable-time

Đây là cách lý tưởng cho môi trường phát triển — mỗi sáng tạo clone mới, tối xoá đi.

Ba loại sao lưu của Aurora: | Loại | Chi tiết | |---|---| | Automated backup (liên tục) | point-in-time recovery, giữ 1–35 ngày | | Snapshot thủ công | giữ tới khi bạn xoá | | Backtrack (Aurora MySQL) | quay ngược thời gian TẠI CHỖ, không tạo cụm mới |

Backtrack là tính năng độc đáo của Aurora MySQL:

aws rds backtrack-db-cluster --db-cluster-identifier cum-dev   --backtrack-to 2026-08-30T09:00:00Z

Backtrack:
    → quay cụm về một thời điểm trước, TRONG VÀI PHÚT
    → không tạo cụm mới
    → rất tiện cho môi trường thử nghiệm sau khi chạy hỏng dữ liệu

Aurora và RDS — bảng phân biệt: | | RDS | Aurora | |---|---|---| | Sao chép | tầng database | tầng LƯU TRỮ | | Read replica | 5, độ trễ giây | 15, độ trễ dưới 100ms | | Bản sao dữ liệu | 2 | 6 qua 3 AZ | | Cloning copy-on-write | ❌ | ✅ | | Backtrack | ❌ | ✅ (MySQL) | | Chuyển đổi | 60–120 giây | dưới 30 giây |

Ba cách mở rộng đọc trên Aurora: | Cách | Chi tiết | |---|---| | Thêm Aurora Replica | tới 15, dùng reader endpoint | | Aurora Auto Scaling cho replica | tự thêm bớt theo CPU hoặc số kết nối | | Custom endpoint | tách truy vấn báo cáo sang replica riêng |

Custom endpoint rất hữu ích:

Reader endpoint  → replica nhỏ, phục vụ ứng dụng
Custom endpoint  → replica LỚN, phục vụ báo cáo và phân tích
    ↓
    Truy vấn báo cáo nặng không làm chậm ứng dụng

Ba lựa chọn chuyển từ SQL Server sang Aurora MySQL: | Công cụ | Việc | |---|---| | AWS SCT | chuyển lược đồ và stored procedure | | AWS DMS | chuyển dữ liệu, có CDC | | Babelfish | (chỉ cho Aurora PostgreSQL, không phải MySQL) |

Lưu ý: Babelfish chỉ có cho Aurora PostgreSQL — nếu muốn giữ T-SQL thì phải chọn PostgreSQL, không phải MySQL.

Ba khoản tiết kiệm khi rời SQL Server: | Khoản | Chi tiết | |---|---| | Giấy phép SQL Server | Enterprise Edition rất đắt | | Software Assurance | phí duy trì hằng năm | | Vận hành | Aurora tự sao lưu, vá lỗi |

Ba lưu ý khi lập kế hoạch chuyển đổi: | Lưu ý | Chi tiết | |---|---| | Chạy SCT assessment trước | biết tỷ lệ tự chuyển được | | Kiểm thử song song | so kết quả truy vấn | | Lên kế hoạch cho stored procedure | thường là phần khó nhất |

Ba thực hành cho môi trường dev: | Thực hành | Chi tiết | |---|---| | Dùng clone thay vì bản sao đầy đủ | ← điểm của câu này | | Che dữ liệu nhạy cảm trước khi cho dev dùng | tuân thủ | | Xoá clone sau khi dùng xong | kiểm soát chi phí |

Và một lời khuyên: hãy tự động hoá việc tạo và xoá clone bằng EventBridge Scheduler — tạo lúc 6 giờ sáng, xoá lúc 8 giờ tối. Với copy-on-write, chi phí chỉ tính cho dữ liệu bị thay đổi trong ngày, và mỗi sáng đội phát triển có dữ liệu mới nhất mà không ai phải nhớ làm gì.

Đáp án

A — Nó cho phép chạy EC2 instance CHỈ ở Region eu-west-1, và lời gọi API có thể phát ra từ bất cứ đâu trên thế giới.

Vì sao đúng

Điểm mấu chốt nằm ở khoá điều kiện aws:RequestedRegion — nó nói về Region NƠI TÀI NGUYÊN ĐƯỢC TẠO, không phải nơi phát ra lời gọi.

"Condition": {"StringEquals": {"aws:RequestedRegion": "eu-west-1"}}

aws:RequestedRegion là gì:

aws:RequestedRegion = Region mà REQUEST nhắm tới
    → được xác định bởi ENDPOINT bạn gọi
    → ví dụ: ec2.eu-west-1.amazonaws.com → eu-west-1
        ↓
    KHÔNG liên quan tới vị trí địa lý của người gọi

Minh hoạ:

# Từ Việt Nam, gọi endpoint của eu-west-1 → ĐƯỢC PHÉP
aws ec2 run-instances --region eu-west-1 --image-id ami-0abc

# Từ chính Ireland, gọi endpoint của us-east-1 → BỊ TỪ CHỐI
aws ec2 run-instances --region us-east-1 --image-id ami-0def

Vì sao "từ bất cứ đâu trên thế giới":

Chính sách KHÔNG có điều kiện nào về IP nguồn
    → aws:SourceIp không xuất hiện
    → không giới hạn vị trí người gọi
        ↓
    Lập trình viên ở Tokyo, Sydney hay São Paulo
    đều tạo được instance ở eu-west-1

Đây là mẫu chính sách rất phổ biến để giới hạn Region:

{"Effect": "Deny", "NotAction": [
   "iam:*", "organizations:*", "route53:*", "cloudfront:*",
   "support:*", "budgets:*", "waf:*", "sts:*"],
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:RequestedRegion": ["eu-west-1", "eu-central-1"]}}}

Dạng Deny + StringNotEquals mạnh hơn — nó chặn mọi dịch vụ chứ không chỉ EC2.

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

• **C. Cho phép chạy instance ở eu-west-1 khi lời gọi API được thực hiện TỪ eu-west-1 — đây là phương án gần nhất và là bẫy chính: nó đúng về Region đích nhưng thêm một ràng buộc không có trong chính sách. Muốn giới hạn vị trí người gọi thì cần aws:SourceIp hoặc aws:SourceVpc.
• **B. Cho phép chạy instance ở MỌI Region khi lời gọi phát ra từ eu-west-1 — đảo ngược hoàn toàn ý nghĩa của khoá điều kiện.
• **D. Cho phép chạy instance ở mọi nơi TRỪ eu-west-1 — đảo ngược toán tử: StringEquals nghĩa là bằng, không phải khác.

Ghi nhớ

Ba khoá điều kiện dễ nhầm — bảng phải thuộc: | Khoá | Nói về | |---|---| | aws:RequestedRegion | Region mà REQUEST NHẮM TỚI ← câu này | | aws:SourceIp | IP CÔNG CỘNG của người gọi | | aws:SourceVpc / aws:SourceVpce | VPC hoặc VPC endpoint mà request đi qua |

Mẹo phân biệt:

"Requested" → về TÀI NGUYÊN được yêu cầu "Source" → về NGƯỜI GỌI

Các khoá điều kiện toàn cục quan trọng: | Khoá | Ý nghĩa | |---|---| | aws:RequestedRegion | Region đích | | aws:SourceIp | IP người gọi | | aws:PrincipalArn | ARN của người gọi | | aws:PrincipalOrgID | id Organization | | aws:MultiFactorAuthPresent | có MFA không | | aws:SecureTransport | có HTTPS không | | aws:ViaAWSService | dịch vụ AWS gọi thay | | aws:CurrentTime | thời điểm | | aws:ResourceTag/<key> | thẻ tài nguyên | | aws:RequestTag/<key> | thẻ trong request |

Ba trường hợp dùng aws:RequestedRegion: | Trường hợp | Chi tiết | |---|---| | Tuân thủ về vị trí dữ liệu | GDPR yêu cầu dữ liệu ở EU | | Kiểm soát chi phí | ngăn tạo tài nguyên ở Region không quản lý | | Bảo mật | kẻ tấn công thường chọn Region bạn không giám sát |

Điểm cuối rất thực tế: kẻ tấn công chiếm được thông tin đăng nhập thường tạo instance đào tiền mã hoá ở Region ít dùng — nơi không ai nhìn dashboard.

Ba lưu ý khi giới hạn Region: | Lưu ý | Chi tiết | |---|---| | Dịch vụ TOÀN CẦU không có Region | IAM, CloudFront, Route 53, WAF (cho CloudFront) | | Phải đưa chúng vào NotAction | nếu không sẽ chặn nhầm | | Một số dịch vụ gọi tới us-east-1 | ví dụ billing |

Danh sách dịch vụ toàn cầu cần loại trừ:

"NotAction": [
  "iam:*", "organizations:*", "route53:*", "cloudfront:*",
  "waf:*", "wafv2:*", "shield:*", "globalaccelerator:*",
  "support:*", "budgets:*", "ce:*", "sts:*", "s3:GetBucketLocation"]

Thiếu một cái là dịch vụ đó ngừng hoạt động mà không rõ lý do.

Ba tầng áp chính sách giới hạn Region: | Tầng | Phạm vi | |---|---| | Service Control Policy | cả tài khoản hoặc OU — mạnh nhất | | Permissions boundary | một user hoặc role | | Identity policy | user hoặc role cụ thể ← câu này |

SCP là nơi đúng để giới hạn Region ở cấp tổ chức:

aws organizations create-policy --name gioi-han-region   --type SERVICE_CONTROL_POLICY --content file://scp-region.json

Và AWS cũng có tính năng bật tắt Region:

aws account disable-region --region-name ap-south-2

Region bị tắt thì không dùng được gì trong đó — biện pháp mạnh và đơn giản hơn SCP cho các Region chắc chắn không dùng.

Ba quy tắc đánh giá chính sách:

① Mặc định: TỪ CHỐI ngầm định
② Explicit Allow → cho phép
③ Explicit DENY → TỪ CHỐI, thắng mọi Allow

Bốn toán tử điều kiện hay dùng: | Toán tử | Khớp khi | |---|---| | StringEquals | bằng chính xác ← câu này | | StringNotEquals | khác | | StringLike | có ký tự đại diện | | ForAnyValue / ForAllValues | với khoá nhiều giá trị |

Ba công cụ kiểm tra: | Công cụ | Việc | |---|---| | IAM Policy Simulator | thử hành động ở từng Region | | IAM Access Analyzer policy validation | phát hiện lỗi cú pháp | | CloudTrail | xem lời gọi bị từ chối |

Và một lời khuyên: hãy kiểm chứng bằng cách thử tạo tài nguyên ở một Region bị cấm. Chính sách giới hạn Region là loại rất dễ chặn nhầm dịch vụ toàn cầu, và thử nghiệm sẽ phát hiện ngay — an toàn hơn nhiều so với phát hiện qua việc CloudFront ngừng cập nhật được vào giữa ngày làm việc.

Đáp án

A và E.

• A — Mount Amazon EFS trên mọi EC2 instance, chạy job một lần sao chép video từ mọi EBS volume sang EFS, sửa ứng dụng dùng EFS
• E — Chạy job một lần sao chép video sang Amazon S3, sửa ứng dụng dùng S3 Standard

Vì sao đúng

Đề mô tả triệu chứng rất rõ, và nguyên nhân là lưu trữ CỤC BỘ trên từng máy:

Video được lưu trên EBS volume của instance ĐANG XỬ LÝ request
    ↓
Lần sau người dùng vào, ALB gửi tới instance KHÁC
    → instance đó chỉ có video mà CHÍNH NÓ đã nhận
        ↓
    Người dùng thấy MỘT TẬP CON khác nhau mỗi lần

Và cả hai đáp án đều chuyển sang KHO DÙNG CHUNG: | Lựa chọn | Cơ chế | |---|---| | EFS | hệ thống tệp NFS, mọi instance mount cùng một nơi | | S3 | kho object, mọi instance gọi cùng một bucket |

E — S3 là lựa chọn TỐI ƯU cho video:

S3:
    ✓ rẻ hơn EFS khoảng 13 lần mỗi GB
    ✓ dung lượng không giới hạn
    ✓ độ bền 11 số 9
    ✓ tải lên trực tiếp từ trình duyệt bằng presigned URL
    ✓ phục vụ qua CloudFront rất hiệu quả
        ↓
    Đây là kiến trúc chuẩn cho ứng dụng chia sẻ nội dung

A — EFS cũng giải quyết vấn đề:

EFS:
    ✓ hàng nghìn instance mount đồng thời
    ✓ ứng dụng KHÔNG PHẢI SỬA nhiều — vẫn là đường dẫn tệp
    ✗ đắt hơn S3 đáng kể

Và EFS có ưu điểm về mức độ thay đổi mã:

Chuyển sang S3:
    → phải sửa mã dùng SDK thay vì thao tác tệp

Chuyển sang EFS:
    → chỉ đổi đường dẫn từ /var/videos sang /mnt/efs/videos
    → phần còn lại giữ nguyên

Hai đáp án là hai cách hợp lệ với hai đánh đổi khác nhau — đó là lý do câu hỏi yêu cầu chọn hai.

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

• **B. Sao chép video sang Amazon DynamoDB — đây là phương án gần nhất vì DynamoDB đúng là kho dùng chung, nhưng nó sai loại dữ liệu: DynamoDB giới hạn 400 KB mỗi item, còn video thường hàng chục tới hàng trăm MB. Nó dành cho dữ liệu có cấu trúc, không phải tệp nhị phân lớn.
• **C. Sao chép sang S3 Glacier Deep Archive — sai lớp lưu trữ: Deep Archive cần 12–48 giờ để khôi phục. Người dùng không thể chờ hai ngày để xem video của mình.
• **D. Sao chép sang Amazon RDS — sai loại kho: database quan hệ không phù hợp để lưu tệp nhị phân lớn. Nó làm database phình to, sao lưu chậm, và chi phí cao.

Ghi nhớ

Nguyên tắc kiến trúc quan trọng nhất của câu này:

Ứng dụng chạy trên nhiều instance KHÔNG được lưu trạng thái cục bộ.

Ba loại trạng thái phải đưa ra ngoài: | Trạng thái | Đưa vào đâu | |---|---| | Tệp người dùng tải lên | S3 hoặc EFS ← câu này | | Phiên đăng nhập | ElastiCache, DynamoDB, hoặc JWT | | Dữ liệu ứng dụng | RDS, DynamoDB |

S3 và EFS cho tệp — bảng so sánh: | | Amazon S3 | Amazon EFS | |---|---|---| | Mô hình | kho object (HTTP API) | hệ thống tệp POSIX (NFS) | | Giá mỗi GB | ~0,023 USD | ~0,30 USD (Standard) | | Sửa mã ứng dụng | cần dùng SDK | gần như không | | Sửa TẠI CHỖ một phần tệp | ❌ phải ghi lại cả object | ✅ | | Phục vụ qua CDN | ✅ rất tốt | phải qua ứng dụng | | Tải lên trực tiếp từ trình duyệt | ✅ presigned URL | ❌ | | Dung lượng | không giới hạn | không giới hạn |

Với ứng dụng chia sẻ video, S3 là lựa chọn đúng hơn hẳn.

Kiến trúc chuẩn cho ứng dụng tải lên video:

Trình duyệt
    ↓ ① xin presigned URL từ ứng dụng
Ứng dụng (EC2) → trả về presigned URL
    ↓ ② tải video THẲNG lên S3 (không qua EC2)
Amazon S3
    ↓ ③ S3 event → Lambda → MediaConvert chuyển mã
    ↓ ④ metadata vào DynamoDB
CloudFront phục vụ video cho người xem

Presigned URL là kỹ thuật quan trọng:

url = s3.generate_presigned_url('put_object',
    Params={'Bucket': 'kho-video', 'Key': f'{ma_nguoi_dung}/{ma_video}.mp4'},
    ExpiresIn=3600)

Lợi ích:
    ✓ video KHÔNG đi qua EC2 → không tốn băng thông và CPU
    ✓ tải lên nhanh hơn
    ✓ EC2 không cần dung lượng đĩa lớn

Ba lưu ý khi chuyển sang S3: | Lưu ý | Chi tiết | |---|---| | Đặt khoá theo người dùng | {ma_nguoi_dung}/{ma_video}.mp4 | | Bucket KHÔNG công khai | dùng CloudFront với OAC | | Presigned URL hoặc signed cookie cho video riêng tư | |

Và lifecycle rule quản lý chi phí:

{"Rules": [{
  "Status": "Enabled", "Filter": {},
  "Transitions": [
    {"Days": 90, "StorageClass": "STANDARD_IA"},
    {"Days": 365, "StorageClass": "GLACIER_IR"}],
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

Dòng cuối bắt buộc với video — tệp lớn luôn dùng multipart, và lần tải lên thất bại để lại phần dở dang tính tiền mãi mãi.

Ba lớp lưu trữ S3 phù hợp cho video: | Lớp | Dùng khi | |---|---| | Standard | video mới, xem nhiều | | Standard-IA | sau 90 ngày | | Glacier Instant Retrieval | lưu trữ lâu nhưng vẫn xem ngay được | | Intelligent-Tiering | mẫu truy cập khó đoán — phù hợp với nội dung có thể lan truyền |

Intelligent-Tiering đáng cân nhắc cho video người dùng:

Một video cũ bỗng được chia sẻ nhiều
    → Intelligent-Tiering tự đưa về tầng nóng
    → KHÔNG có phí truy xuất bất ngờ

Ba dịch vụ xử lý video trên AWS: | Dịch vụ | Việc | |---|---| | MediaConvert | chuyển mã sang nhiều độ phân giải | | MediaPackage | đóng gói cho phát trực tiếp | | Elemental MediaLive | mã hoá luồng trực tiếp |

Ba lưu ý nếu chọn EFS thay vì S3: | Lưu ý | Chi tiết | |---|---| | Bật lifecycle sang IA | giảm ~90% cho tệp cũ | | Dùng Elastic throughput | trả theo lượng dùng thật | | Một mount target mỗi AZ | tránh phí truyền chéo AZ |

Ba bước di chuyển an toàn: | Bước | Chi tiết | |---|---| | Sao chép dữ liệu hiện có | chạy job một lần từ mọi EBS volume | | Sửa ứng dụng ghi vào cả hai nơi tạm thời | giai đoạn chuyển tiếp | | Kiểm chứng rồi mới bỏ EBS | so số lượng tệp |

Và một lời khuyên: hãy kiểm chứng số lượng video của từng người dùng sau khi gộp từ mọi EBS volume. Với dữ liệu bị phân mảnh trên nhiều máy, rất dễ bỏ sót một volume — và người dùng sẽ chỉ phát hiện điều đó khi tìm một video cụ thể không còn nữa.

Đáp án

C và D.

• C — Triển khai AWS Transfer Family endpoint có bật SFTP, lưu tệp thẳng vào S3, gắn IAM role cho từng nhà cung cấp để giới hạn bucket hoặc prefix
• D — Cấu hình bucket policy dùng kiểm soát truy cập theo IAM role, kết hợp tích hợp nhà cung cấp danh tính của Transfer Family (Cognito hoặc IdP tuỳ chỉnh) cho phân quyền chi tiết

Vì sao đúng

Đề nêu bốn yêu cầu, và hai đáp án chia nhau giải quyết đủ: | Yêu cầu | Giải pháp | |---|---| | Nhà cung cấp cũ CHỈ dùng được SFTP | AWS Transfer Family — endpoint SFTP thật | | Tải thẳng vào S3 | Transfer Family ghi trực tiếp vào bucket | | Dịch vụ ĐƯỢC QUẢN LÝ HOÀN TOÀN | không có máy chủ nào phải vận hành | | Liên kết danh tính, ánh xạ tới bucket hoặc prefix | custom IdP hoặc Cognito + IAM role theo nhà cung cấp |

C — Transfer Family là dịch vụ SFTP được quản lý:

AWS Transfer Family:
    ✓ endpoint SFTP, FTPS, FTP, AS2 thật
    ✓ nhà cung cấp dùng client SFTP quen thuộc, KHÔNG đổi quy trình
    ✓ tệp vào thẳng S3, không qua máy chủ trung gian
    ✓ AWS lo hạ tầng, mở rộng, vá lỗi

aws transfer create-server --protocols SFTP   --identity-provider-type SERVICE_MANAGED   --endpoint-type VPC   --endpoint-details VpcId=vpc-0abc,SubnetIds=subnet-a,subnet-b

aws transfer create-user --server-id s-abc123   --user-name nha-cung-cap-a   --role arn:aws:iam::123456789012:role/vai-tro-nha-cung-cap-a   --home-directory-type LOGICAL   --home-directory-mappings '[{"Entry":"/","Target":"/kho-du-lieu/nha-cung-cap-a"}]'   --ssh-public-key-body "ssh-rsa AAAA..."

home-directory-type LOGICAL là chi tiết quan trọng:

Nhà cung cấp chỉ thấy "/" là thư mục gốc
    → KHÔNG biết tên bucket
    → KHÔNG thấy prefix của nhà cung cấp khác

D — liên kết danh tính cho phân quyền chi tiết:

Custom identity provider (Lambda hoặc API Gateway):
    → nhận thông tin đăng nhập từ SFTP
    → xác thực với hệ thống danh tính của công ty
    → trả về IAM role và scope-down policy phù hợp
        ↓
    Mỗi nhà cung cấp nhận đúng quyền của mình

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

• **B. Dùng Transfer Family với SFTP, nhưng tích hợp kiểm soát truy cập với Route 53 private hosted zone để tạo subdomain riêng cho từng nhà cung cấp — đây là phương án gần nhất vì vế Transfer Family đúng, nhưng vế thứ hai nhầm lẫn giữa DNS và phân quyền: subdomain chỉ là tên, nó không kiểm soát ai truy cập được gì. Phân quyền phải làm bằng IAM role và scope-down policy.
• **E. Dựng EC2 với OpenSSH tự cấu hình, cron job đẩy tệp lên S3 — vi phạm yêu cầu "fully managed": bạn phải vá lỗi, mở rộng, và đảm bảo sẵn sàng cao cho máy chủ SFTP. Và cron job tạo độ trễ giữa lúc nhận tệp và lúc tệp có mặt trong S3.
• **A. Dùng Amazon AppFlow trích xuất dữ liệu từ hệ thống nhà cung cấp — sai dịch vụ: AppFlow tích hợp với SaaS (Salesforce, Slack, Zendesk), nó không nói SFTP và không kết nối được với hệ thống cũ của nhà cung cấp.

Ghi nhớ

Bốn giao thức mà AWS Transfer Family hỗ trợ: | Giao thức | Đặc điểm | |---|---| | SFTP | SSH File Transfer — phổ biến nhất ← câu này | | FTPS | FTP over TLS | | FTP | không mã hoá — chỉ dùng trong VPC | | AS2 | trao đổi dữ liệu B2B (EDI) |

Ba đích lưu trữ: | Đích | Chi tiết | |---|---| | Amazon S3 | ← câu này | | Amazon EFS | khi cần ngữ nghĩa hệ thống tệp |

Ba loại nhà cung cấp danh tính: | Loại | Chi tiết | |---|---| | Service managed | Transfer Family lưu SSH public key — đơn giản nhất | | AWS Directory Service | tích hợp Active Directory | | Custom identity provider | Lambda hoặc API Gateway — linh hoạt nhất |

Custom IdP cho phép tích hợp với bất kỳ hệ thống nào:

def handler(event, context):
    ten = event['username']
    mat_khau = event.get('password')
    if not xac_thuc(ten, mat_khau):
        return {}
    return {
      'Role': f'arn:aws:iam::123456789012:role/vai-tro-{ten}',
      'HomeDirectoryType': 'LOGICAL',
      'HomeDirectoryDetails': json.dumps([
          {'Entry': '/', 'Target': f'/kho-du-lieu/{ten}'}]),
      'Policy': json.dumps(chinh_sach_thu_hep(ten))}

Và scope-down policy giới hạn quyền trong phiên:

{"Version": "2012-10-17",
 "Statement": [
   {"Effect": "Allow", "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::kho-du-lieu",
    "Condition": {"StringLike": {"s3:prefix": ["${transfer:UserName}/*"]}}},
   {"Effect": "Allow", "Action": ["s3:PutObject", "s3:GetObject"],
    "Resource": "arn:aws:s3:::kho-du-lieu/${transfer:UserName}/*"}]}

Biến ${transfer:UserName} cho phép dùng MỘT policy cho MỌI nhà cung cấp — rất dễ mở rộng.

Ba loại endpoint của Transfer Family: | Loại | Truy cập | |---|---| | Public | từ Internet | | VPC (internal) | chỉ trong VPC hoặc qua VPN/DX | | VPC (internet-facing) | từ Internet, có Elastic IP TĨNH |

Loại thứ ba rất hữu ích:

Endpoint VPC internet-facing với Elastic IP:
    ✓ nhà cung cấp truy cập từ Internet
    ✓ IP TĨNH để họ đưa vào danh sách trắng tường lửa
    ✓ bạn kiểm soát bằng security group

Ba cách kiểm soát truy cập: | Cách | Chi tiết | |---|---| | IAM role + scope-down policy | ← câu này | | Security group trên endpoint VPC | giới hạn IP nguồn | | Logical home directory | ẩn cấu trúc bucket |

Ba lưu ý về chi phí: | Khoản | Giá tham khảo | |---|---| | Endpoint | ~0,30 USD/giờ mỗi giao thức (~216 USD/tháng) | | Dữ liệu truyền | ~0,04 USD/GB | | Cộng phí S3 | lưu trữ và request |

Phí endpoint là cố định và khá cao — nên gộp mọi nhà cung cấp vào một server thay vì tạo nhiều server.

Ba tính năng vận hành đáng dùng: | Tính năng | Chi tiết | |---|---| | Managed workflow | tự xử lý tệp sau khi tải lên (giải nén, quét virus, gắn thẻ) | | CloudWatch logging | ghi mọi phiên và thao tác | | EventBridge event | kích hoạt xử lý khi có tệp mới |

Managed workflow rất hữu ích:

Tệp được tải lên
    ↓ workflow tự chạy
    ├── giải nén
    ├── kiểm tra định dạng
    ├── gắn thẻ theo nhà cung cấp
    └── chuyển sang prefix đã xử lý
        ↓
    Không cần viết Lambda riêng cho các bước phổ biến

Ba biện pháp bảo mật cho dữ liệu chuỗi cung ứng: | Biện pháp | Chi tiết | |---|---| | Mã hoá S3 bằng SSE-KMS | và cấp quyền kms:GenerateDataKey cho role | | Bật CloudTrail data event | biết ai tải gì lên | | Xoay vòng SSH key định kỳ | |

Ba lưu ý khi làm việc với nhà cung cấp bên ngoài: | Lưu ý | Chi tiết | |---|---| | Mỗi nhà cung cấp một prefix riêng | không thấy dữ liệu của nhau | | Đặt lifecycle dọn tệp cũ | tránh tích tụ | | Kiểm tra định dạng tệp trước khi xử lý | dữ liệu bên ngoài luôn cần kiểm tra |

Và một lời khuyên: hãy bật CloudWatch logging và giữ log cho mọi phiên SFTP. Khi có tranh chấp về việc "chúng tôi đã gửi tệp đó rồi", log ghi rõ thời điểm, tên tệp và kích thước là bằng chứng duy nhất — và với quan hệ nhà cung cấp trong chuỗi cung ứng, loại tranh chấp này xảy ra thường xuyên.

Đáp án

B — Tạo bucket S3 MỚI ở us-east-1 có bật replication sang bucket ở us-west-1; bật SSE-KMS trên bucket mới bằng AWS KMS multi-Region key; sao chép dữ liệu hiện có từ bucket cũ sang bucket mới.

Vì sao đúng

Đề nêu một yêu cầu rất chặt: dữ liệu phải được mã hoá và giải mã bằng CÙNG MỘT KHOÁ ở cả hai Region.

Khoá KMS thông thường có phạm vi MỘT REGION
    → khoá ở us-east-1 KHÔNG dùng được ở us-west-1
        ↓
    Cần AWS KMS MULTI-REGION KEY

Multi-Region key là gì:

KMS multi-Region key:
    → một khoá CHÍNH (primary) ở một Region
    → các bản SAO (replica) ở Region khác
    → CÙNG key material, CÙNG key ID
        ↓
    Dữ liệu mã hoá ở us-east-1 giải mã được ở us-west-1
    mà không cần gọi ngược về Region gốc

Và vì sao phải tạo bucket MỚI:

KHÔNG chuyển đổi được khoá single-Region thành multi-Region
    → đây là ràng buộc cứng của KMS
        ↓
    Phải: tạo multi-Region key mới
        → bucket mới dùng khoá đó
        → sao chép dữ liệu sang

Ba bước triển khai:

# ① Tạo multi-Region key ở us-east-1
aws kms create-key --multi-region --region us-east-1

# ② Nhân bản khoá sang us-west-1
aws kms replicate-key --key-id mrk-abc123   --replica-region us-west-1 --region us-east-1

# ③ Bucket mới với SSE-KMS dùng khoá đó
aws s3api put-bucket-encryption --bucket kho-moi-east   --server-side-encryption-configuration '{
    "Rules":[{"ApplyServerSideEncryptionByDefault":{
      "SSEAlgorithm":"aws:kms","KMSMasterKeyID":"mrk-abc123"},
      "BucketKeyEnabled":true}]}'

Và cấu hình replication:

{"Role": "<arn-role>",
 "Rules": [{
   "Status": "Enabled", "Priority": 1,
   "Filter": {}, "DeleteMarkerReplication": {"Status": "Disabled"},
   "SourceSelectionCriteria": {
     "SseKmsEncryptedObjects": {"Status": "Enabled"}},
   "Destination": {
     "Bucket": "arn:aws:s3:::kho-moi-west",
     "EncryptionConfiguration": {"ReplicaKmsKeyID": "arn:aws:kms:us-west-1:...:key/mrk-abc123"}}}]}

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

• **C. Chuyển đổi khoá single-Region hiện tại thành multi-Region key, dùng S3 Batch Replication cho dữ liệu cũ — đây là phương án gần nhất và vế Batch Replication hoàn toàn hợp lệ, nhưng vế đầu không làm được: KMS KHÔNG cho chuyển đổi khoá single-Region thành multi-Region. Đó là thuộc tính quyết định lúc tạo khoá và không thay đổi được.
• **A. Bật replication cho bucket hiện tại và "chia sẻ khoá KMS từ us-east-1 sang us-west-1" — không có cơ chế như vậy: khoá KMS thông thường không "chia sẻ" sang Region khác được. Bạn có thể cấp quyền dùng khoá cho principal ở Region khác, nhưng lời gọi vẫn phải về Region chứa khoá — không thoả yêu cầu "cùng khoá ở cả hai Region".
• **D. Dùng CloudWatch scheduled rule → Lambda sao chép dữ liệu hằng ngày — nhiều công và kém tin cậy: phải viết và bảo trì mã, xử lý lỗi và thử lại, và có độ trễ một ngày. S3 Replication làm việc này nguyên bản, gần thời gian thực.

Ghi nhớ

Ba loại khoá KMS theo phạm vi: | Loại | Phạm vi | |---|---| | Single-Region key (mặc định) | một Region | | Multi-Region key | nhân bản sang nhiều Region, CÙNG key material | | — | KHÔNG chuyển đổi qua lại được |

Ba đặc điểm của multi-Region key: | Đặc điểm | Chi tiết | |---|---| | Cùng key ID với tiền tố mrk- | dễ nhận diện | | Cùng key material | bản mã ở Region này giải mã được ở Region kia | | Key policy và grant QUẢN LÝ RIÊNG mỗi Region | linh hoạt về phân quyền |

Ba trường hợp dùng multi-Region key: | Trường hợp | Chi tiết | |---|---| | S3 Cross-Region Replication với SSE-KMS | ← câu này | | Khôi phục thảm hoạ đa Region | dữ liệu giải mã được ở Region dự phòng | | DynamoDB Global Tables mã hoá | |

Lưu ý quan trọng: multi-Region key KHÔNG phải mặc định.

AWS khuyến nghị dùng single-Region key trừ khi có nhu cầu cụ thể
    → single-Region cách ly rủi ro tốt hơn
    → multi-Region mở rộng phạm vi ảnh hưởng nếu khoá bị lộ

Ba cách xử lý dữ liệu CŨ khi bật replication: | Cách | Chi tiết | |---|---| | S3 Batch Replication | sao chép object đã có sang đích | | Sao chép thủ công (aws s3 cp) | ← đáp án của câu này | | S3 Batch Operations với Copy | linh hoạt hơn |

Vì replication chỉ áp cho object MỚI:

Bật replication:
    → chỉ object được ghi SAU đó mới được sao chép
    → object cũ nằm im
        ↓
    Phải xử lý riêng

S3 Batch Replication:

aws s3control create-job --account-id 123456789012   --operation '{"S3ReplicateObject":{}}'   --manifest-generator '{"S3JobManifestGenerator":{
    "SourceBucket":"arn:aws:s3:::kho-moi-east",
    "EnableManifestOutput":false,
    "Filter":{"ObjectReplicationStatuses":["NONE","FAILED"]}}}'   --priority 10 --role-arn <arn> --no-confirmation-required

Ba yêu cầu để S3 replication hoạt động: | Yêu cầu | Chi tiết | |---|---| | Versioning BẬT ở CẢ HAI bucket | bắt buộc | | IAM role có quyền đọc nguồn và ghi đích | | | Với SSE-KMS: role cần kms:Decrypt ở nguồn và kms:GenerateDataKey ở đích | hay bị quên |

Chính sách cho role replication với KMS:

{"Effect": "Allow",
 "Action": ["kms:Decrypt"],
 "Resource": "arn:aws:kms:us-east-1:123456789012:key/mrk-abc123"},
{"Effect": "Allow",
 "Action": ["kms:Encrypt", "kms:GenerateDataKey"],
 "Resource": "arn:aws:kms:us-west-1:123456789012:key/mrk-abc123"}

Ba tính năng của S3 Replication: | Tính năng | Chi tiết | |---|---| | Cross-Region Replication (CRR) | khác Region ← câu này | | Same-Region Replication (SRR) | cùng Region, khác tài khoản hoặc bucket | | Replication Time Control (RTC) | đảm bảo 99,99% object sao chép trong 15 PHÚT |

RTC đáng bật cho dữ liệu quan trọng:

{"Destination": {"ReplicationTime": {"Status": "Enabled",
   "Time": {"Minutes": 15}},
   "Metrics": {"Status": "Enabled", "EventThreshold": {"Minutes": 15}}}}

Có phí thêm nhưng cho cam kết về thời gian và metric theo dõi.

Ba thứ replication KHÔNG sao chép mặc định: | Không sao chép | Cách bật | |---|---| | Object đã có TRƯỚC khi bật | S3 Batch Replication | | Delete marker | DeleteMarkerReplication: Enabled | | Object mã hoá SSE-C | không hỗ trợ |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ ở CẢ HAI Region | nhân đôi | | Truyền dữ liệu xuyên Region | ~0,02 USD/GB | | Lời gọi KMS | bật Bucket Keys để giảm tới 99% |

Bucket Keys rất đáng bật với SSE-KMS:

{"BucketKeyEnabled": true}

Nó giảm mạnh số lời gọi KMS và chi phí tương ứng.

Và một lời khuyên: hãy kiểm chứng bằng cách giải mã một object ở Region đích sau khi thiết lập xong. Cấu hình khoá đa Region có nhiều tầng quyền (key policy ở hai Region, IAM role, bucket policy), và cách duy nhất để biết chúng khớp nhau là thử đọc thật một tệp từ phía us-west-1.

Đáp án

D — Chụp snapshot của database, sao chép snapshot đó thành bản ĐÃ MÃ HOÁ, khôi phục database mới từ snapshot đã mã hoá, rồi chấm dứt database cũ.

Vì sao đúng

Điểm mấu chốt: RDS KHÔNG cho bật mã hoá cho instance đã tồn tại.

Mã hoá at rest của RDS:
    → quyết định LÚC TẠO instance
    → KHÔNG có công tắc để bật sau
        ↓
    Muốn mã hoá database chưa mã hoá:
    phải TẠO INSTANCE MỚI đã mã hoá

Và quy trình bốn bước:

① Chụp snapshot của database chưa mã hoá
② SAO CHÉP snapshot với --kms-key-id → bản sao ĐƯỢC MÃ HOÁ
③ Khôi phục instance mới từ snapshot đã mã hoá
④ Chuyển ứng dụng sang, chấm dứt instance cũ

Bước hai là mấu chốt — chính thao tác sao chép snapshot là nơi mã hoá được áp dụng:

# ① Chụp snapshot
aws rds create-db-snapshot --db-instance-identifier db-cu   --db-snapshot-identifier snap-chua-ma-hoa

# ② Sao chép thành bản đã mã hoá
aws rds copy-db-snapshot   --source-db-snapshot-identifier snap-chua-ma-hoa   --target-db-snapshot-identifier snap-da-ma-hoa   --kms-key-id arn:aws:kms:ap-northeast-1:123456789012:key/abc-123

# ③ Khôi phục instance mới
aws rds restore-db-instance-from-db-snapshot   --db-instance-identifier db-moi   --db-snapshot-identifier snap-da-ma-hoa   --multi-az --db-instance-class db.m5.large

Và mã hoá bao trùm mọi thứ của instance mới:

--storage-encrypted mã hoá:
    ✓ dữ liệu trên đĩa
    ✓ snapshot tự động và thủ công
    ✓ read replica
    ✓ log

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

• **B. Tạo read replica, mã hoá replica đó, promote thành độc lập rồi chấm dứt database cũ — đây là phương án gần nhất và nghe rất hợp lý, nhưng nó không làm được về mặt kỹ thuật: read replica của một instance chưa mã hoá cũng bắt buộc chưa mã hoá. Không có cách nào "mã hoá replica" của một nguồn chưa mã hoá.
• **C. Bật mã hoá trực tiếp qua AWS Console — không tồn tại tuỳ chọn này: giao diện không có công tắc bật mã hoá cho instance đã chạy.
• **A. Bật Multi-AZ, đảm bảo standby được mã hoá, dừng primary để standby lên thay, rồi tắt Multi-AZ — cùng lỗi như B: standby của instance chưa mã hoá cũng chưa mã hoá. Trạng thái mã hoá luôn khớp giữa primary và standby.

Ghi nhớ

Nguyên tắc mã hoá của RDS — phải thuộc:

Mã hoá at rest quyết định LÚC TẠO
    → KHÔNG bật được sau
    → KHÔNG tắt được sau
        ↓
    Đổi trạng thái mã hoá = tạo instance MỚI

Và điều này áp cho cả nhánh liên quan: | Đối tượng | Trạng thái mã hoá | |---|---| | Read replica | luôn khớp với nguồn | | Multi-AZ standby | luôn khớp với primary | | Snapshot tự động | khớp với instance | | Snapshot sao chép | CÓ THỂ đổi — đây là kẽ hở duy nhất |

Dòng cuối là điểm mấu chốt của câu hỏi — thao tác copy-db-snapshot là nơi duy nhất thay đổi được trạng thái mã hoá.

Ba thao tác snapshot đổi được thuộc tính: | Thao tác | Đổi được | |---|---| | copy-db-snapshot với --kms-key-id | thêm mã hoá, hoặc đổi khoá KMS | | copy-db-snapshot với --source-region | sao chép sang Region khác | | Chia sẻ snapshot | snapshot mã hoá phải chia sẻ cả khoá KMS |

Ba lưu ý khi chia sẻ snapshot đã mã hoá: | Lưu ý | Chi tiết | |---|---| | Không chia sẻ được snapshot mã hoá bằng khoá aws/rds | phải dùng customer managed key | | Phải chia sẻ CẢ khoá KMS | qua key policy | | Tài khoản nhận phải sao chép trước khi khôi phục | |

Ba loại khoá KMS cho RDS: | Loại | Chi tiết | |---|---| | AWS managed key (aws/rds) | miễn phí, không đổi policy, KHÔNG chia sẻ được | | Customer managed key | ~1 USD/tháng, kiểm soát đầy đủ | | Multi-Region key | cho khôi phục thảm hoạ đa Region |

Với dữ liệu cần chia sẻ hoặc khôi phục ở Region khác, customer managed key là bắt buộc.

Ba bước lập kế hoạch cho việc chuyển đổi: | Bước | Chi tiết | |---|---| | Ước lượng thời gian khôi phục | database lớn mất hàng giờ | | Chọn cửa sổ bảo trì | có thời gian ngừng | | Chuẩn bị kế hoạch quay lại | giữ instance cũ tới khi xác nhận ổn |

Ba cách giảm thời gian ngừng: | Cách | Chi tiết | |---|---| | AWS DMS với CDC | đồng bộ liên tục, cắt chuyển trong vài phút | | Blue/Green Deployment của RDS | (hỗ trợ cho một số kịch bản) | | Chấp nhận cửa sổ bảo trì | đơn giản nhất |

DMS là cách ít gián đoạn nhất:

① Khôi phục instance MỚI đã mã hoá từ snapshot
② Dùng DMS với CDC đồng bộ thay đổi từ instance cũ
③ Chờ đuổi kịp
④ Dừng ghi vài phút, chuyển ứng dụng sang

Ba lớp mã hoá cho database: | Lớp | Cơ chế | |---|---| | At rest | --storage-encrypted với KMS | | In transit | bắt buộc TLS bằng parameter group | | Trong cột | mã hoá ở tầng ứng dụng |

Bắt buộc TLS:

# MySQL
require_secure_transport = ON
# PostgreSQL
rds.force_ssl = 1

Ba biện pháp bảo mật bổ sung: | Biện pháp | Chi tiết | |---|---| | Database trong PRIVATE subnet | không public IP | | Mật khẩu trong Secrets Manager, tự xoay vòng | | | Deletion protection | chặn xoá nhầm |

Và deletion protection nên bật cho mọi database sản xuất:

aws rds modify-db-instance --db-instance-identifier db-moi   --deletion-protection --apply-immediately

Ba công cụ phát hiện database chưa mã hoá: | Công cụ | Việc | |---|---| | AWS Config rule rds-storage-encrypted | tự phát hiện và báo | | Security Hub | tổng hợp theo chuẩn | | Trusted Advisor | kiểm tra cơ bản |

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "rds-phai-ma-hoa",
  "Source": {"Owner":"AWS","SourceIdentifier":"RDS_STORAGE_ENCRYPTED"}}'

Và SCP ngăn tạo database chưa mã hoá ngay từ đầu:

{"Effect": "Deny", "Action": "rds:CreateDBInstance", "Resource": "*",
 "Condition": {"Bool": {"rds:StorageEncrypted": "false"}}}

Phòng ngừa tốt hơn phát hiện — nó đảm bảo vấn đề này không tái diễn.

Và một lời khuyên: hãy kiểm chứng dữ liệu đầy đủ trước khi chấm dứt instance cũ. So số dòng của các bảng chính và chạy vài truy vấn nghiệp vụ trên instance mới — quá trình snapshot và khôi phục rất đáng tin cậy, nhưng việc chấm dứt database sản xuất là thao tác không đảo ngược được, và vài phút kiểm tra là bảo hiểm rẻ nhất bạn có thể mua.

Đáp án

B — Bật storage auto-scaling cho Amazon RDS MySQL.

Vì sao đúng

Đề nêu hai yêu cầu, và storage auto-scaling là lựa chọn duy nhất thoả cả hai: | Yêu cầu | Cơ chế | |---|---| | Giải quyết nguy cơ HẾT DUNG LƯỢNG | RDS tự mở rộng lưu trữ khi sắp đầy | | ÍT công phát triển và quản trị nhất | một lệnh, không gián đoạn, không đổi mã |

Cách storage auto-scaling hoạt động:

RDS theo dõi dung lượng trống
    ↓ khi thoả CẢ BA điều kiện:
    ① dung lượng trống dưới 10% tổng dung lượng
    ② tình trạng đó kéo dài ít nhất 5 phút
    ③ đã qua 6 giờ kể từ lần mở rộng trước
        ↓
    RDS TỰ mở rộng thêm
    → KHÔNG gián đoạn, không cần thao tác

Bật bằng một lệnh:

aws rds modify-db-instance --db-instance-identifier db-game   --max-allocated-storage 2000 --apply-immediately

--max-allocated-storage là trần — RDS mở rộng tới đó rồi dừng.

Mức mở rộng mỗi lần:

Lớn hơn trong hai giá trị:
    ① 10 GiB
    ② 10% dung lượng hiện tại
    (và ước lượng đủ dùng cho 7 giờ tới theo tốc độ tăng)

Và vì sao đây là "khẩn cấp" đúng nghĩa:

✓ có hiệu lực NGAY
✓ không gián đoạn dịch vụ
✓ không phải di chuyển dữ liệu
✓ không phải sửa dòng mã nào

Đây chính xác là điều đội kỹ thuật cần khi lưu lượng đang tăng nhanh.

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

• **D. Chuyển sang Amazon Aurora vì Aurora có storage auto-scaling — đây là phương án gần nhất và Aurora thực sự tự mở rộng lưu trữ tới 128 TB, nhưng nó là một dự án di chuyển, không phải giải pháp khẩn cấp: phải lên kế hoạch, kiểm thử, và có cửa sổ cắt chuyển. Đề nói rõ cần giải pháp khẩn cấp với ít công nhất.
• **A. Tạo read replica cho RDS MySQL — giải quyết vấn đề khác: read replica mở rộng khả năng ĐỌC, nó không thêm dung lượng lưu trữ cho instance chính. Database vẫn hết chỗ.
• **C. Chuyển sang DynamoDB vì nó tự cấp phát dung lượng — thay đổi lớn nhất: DynamoDB là NoSQL, chuyển sang nó đòi thiết kế lại mô hình dữ liệu và viết lại toàn bộ tầng truy cập dữ liệu.

Ghi nhớ

Ba điều kiện kích hoạt storage auto-scaling:

① Dung lượng trống dưới 10% tổng dung lượng
② Kéo dài ít nhất 5 PHÚT
③ Đã qua ít nhất 6 GIỜ kể từ lần mở rộng trước

Điều kiện thứ ba đáng lưu ý: nếu dữ liệu tăng cực nhanh, sáu giờ giữa hai lần mở rộng có thể không đủ — nên đặt dung lượng ban đầu có biên độ.

Ba lưu ý về storage auto-scaling: | Lưu ý | Chi tiết | |---|---| | CHỈ mở rộng, KHÔNG thu hẹp | giảm dung lượng phải tạo instance mới | | Phải đặt MaxAllocatedStorage | trần để kiểm soát chi phí | | Không áp cho magnetic storage | chỉ gp2, gp3, io1, io2 |

Dòng đầu quan trọng về chi phí: dung lượng đã mở rộng thì trả tiền mãi, kể cả sau khi xoá bớt dữ liệu.

Ba giới hạn dung lượng của RDS MySQL: | Giới hạn | Giá trị | |---|---| | Tối thiểu | 20 GiB | | Tối đa (gp3) | 64 TiB | | Tối đa (io1/io2) | 64 TiB |

RDS và Aurora — bảng phân biệt về lưu trữ: | | RDS MySQL | Aurora MySQL | |---|---|---| | Cấp phát | khai trước, auto-scaling tuỳ chọn | TỰ ĐỘNG hoàn toàn | | Tối đa | 64 TiB | 128 TiB | | Tính phí | theo dung lượng CẤP PHÁT | theo dung lượng DÙNG THẬT | | Thu hẹp | ❌ | ✅ tự động |

Aurora tính phí theo dung lượng dùng thật là ưu điểm lớn — không phải trả cho phần cấp thừa.

Ba metric cần đặt alarm: | Metric | Ngưỡng | |---|---| | FreeStorageSpace | dưới 20% là cảnh báo | | FreeableMemory | thiếu bộ nhớ gây chậm | | CPUUtilization | trên 80% liên tục | | DatabaseConnections | gần trần |

aws cloudwatch put-metric-alarm --alarm-name db-sap-het-cho   --metric-name FreeStorageSpace --namespace AWS/RDS   --dimensions Name=DBInstanceIdentifier,Value=db-game   --statistic Average --period 300 --threshold 21474836480   --comparison-operator LessThanThreshold --evaluation-periods 2

Ba cách giảm dung lượng cần dùng: | Cách | Chi tiết | |---|---| | Dọn dữ liệu cũ | xoá bản ghi hết giá trị | | Nén hoặc chuyển sang S3 | log, dữ liệu lịch sử | | Kiểm tra binlog và log tệp tạm | có thể chiếm rất nhiều |

Binlog là nguyên nhân bất ngờ hay gặp:

SHOW BINARY LOGS;

aws rds modify-db-instance --db-instance-identifier db-game   --binlog-retention-hours 24

Giữ binlog quá lâu chiếm dung lượng lớn — nhất là với ứng dụng ghi nhiều.

Ba mô hình mở rộng của database: | Mô hình | Việc | |---|---| | Storage auto-scaling | dung lượng ← câu này | | Đổi cỡ instance (scale up) | CPU và bộ nhớ | | Read replica (scale out) | khả năng đọc |

Ba lựa chọn dài hạn cho game đang tăng trưởng nhanh: | Lựa chọn | Chi tiết | |---|---| | Aurora MySQL | lưu trữ tự động, đọc mở rộng tới 15 replica | | Aurora Serverless v2 | tự co giãn cả năng lực tính toán | | Tách dữ liệu nóng và lạnh | dữ liệu cũ sang S3, truy vấn bằng Athena |

Và di chuyển sang Aurora rất dễ:

① Tạo Aurora read replica của RDS MySQL instance
② Chờ độ trễ sao chép về 0
③ Promote Aurora cluster
④ Chuyển ứng dụng sang endpoint mới

Gián đoạn chỉ vài phút — nên đây là kế hoạch trung hạn tốt sau khi đã xử lý khẩn cấp bằng auto-scaling.

Ba loại lưu trữ của RDS: | Loại | Đặc điểm | |---|---| | gp3 | IOPS và thông lượng khai RIÊNG với dung lượng | | gp2 | IOPS gắn với dung lượng (3 IOPS/GB) | | io1/io2 | IOPS cấp phát cao |

Chuyển gp2 sang gp3 thường vừa nhanh hơn vừa rẻ hơn:

aws rds modify-db-instance --db-instance-identifier db-game   --storage-type gp3 --apply-immediately

Và một lời khuyên: hãy bật storage auto-scaling ngay hôm nay và lên kế hoạch chuyển sang Aurora trong quý tới. Auto-scaling giải quyết nguy cơ trước mắt, nhưng với ứng dụng game đang tăng trưởng nhanh, giới hạn 64 TiB và mô hình cấp phát của RDS sẽ trở thành ràng buộc — và di chuyển lúc còn thời gian dễ hơn nhiều so với lúc đã chạm trần.

Đáp án

B — Chế độ hiệu năng Max I/O.

Vì sao đúng

Đề nêu hai từ khoá: big data và cải thiện hiệu năng — và Max I/O là chế độ được thiết kế cho tải song song quy mô lớn.

Hai chế độ hiệu năng của EFS: | Chế độ | Đặc điểm | |---|---| | General Purpose (mặc định) | ĐỘ TRỄ THẤP NHẤT, giới hạn IOPS thấp hơn | | Max I/O | THÔNG LƯỢNG và IOPS cao hơn, nhưng ĐỘ TRỄ CAO HƠN một chút |

Vì sao Max I/O phù hợp với big data:

Tải big data:
    → HÀNG TRĂM tới HÀNG NGHÌN node truy cập song song
    → mỗi node đọc ghi khối lớn
    → tổng thông lượng quan trọng hơn độ trễ của từng thao tác
        ↓
    Max I/O mở rộng tới mức IOPS cao hơn nhiều

Và đánh đổi được chấp nhận:

Max I/O:
    ✓ IOPS và thông lượng tổng cao hơn
    ✗ độ trễ mỗi thao tác cao hơn một chút
        ↓
    Với xử lý lô hàng giờ, vài mili giây không đáng kể
    Với ứng dụng web tương tác, độ trễ mới quan trọng

Cấu hình lúc tạo file system:

aws efs create-file-system --performance-mode maxIO   --throughput-mode elastic --encrypted

Lưu ý quan trọng: chế độ hiệu năng KHÔNG đổi được sau khi tạo — phải tạo file system mới và chuyển dữ liệu.

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

• **D. General Purpose — đây là phương án gần nhất và là mặc định cho hầu hết trường hợp, nhưng nó tối ưu cho ĐỘ TRỄ, không phải THÔNG LƯỢNG: nó phù hợp với web server, CMS, thư mục home — nơi mỗi thao tác cần nhanh. Với big data cần thông lượng tổng cao, nó chạm trần IOPS sớm hơn.
• **A. Provisioned Throughput — nhầm giữa hai loại cấu hình: đây là chế độ THÔNG LƯỢNG, không phải chế độ HIỆU NĂNG. Câu hỏi hỏi về performance mode.
• **C. Bursting Throughput — cùng lỗi: cũng là chế độ thông lượng, không phải chế độ hiệu năng.

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

Câu này phản ánh cách phân loại cũ của EFS, và lời khuyên hiện hành của AWS đã đổi.

Từ năm 2023–2024, với Elastic throughput, chế độ General Purpose đã hỗ trợ tới 90.000 read IOPS và 55.000 write IOPS — cao hơn nhiều so với trước. AWS hiện khuyến nghị General Purpose cho gần như mọi tải, kể cả big data, và nêu rõ:

Max I/O có độ trễ cao hơn cho mọi thao tác tệp và không hỗ trợ Elastic throughput.

Nói cách khác, chọn Max I/O ngày nay thường làm chậm hệ thống chứ không tăng tốc, trừ khi bạn thực sự vượt trần IOPS của General Purpose — điều hiếm khi xảy ra với cấu hình hiện tại.

Bảng so sánh cập nhật: | | General Purpose | Max I/O | |---|---|---| | Độ trễ | thấp nhất | cao hơn | | Read IOPS tối đa | ~90.000 (với Elastic) | cao hơn nhưng độ trễ kém | | Hỗ trợ Elastic throughput | ✅ | ❌ | | Khuyến nghị của AWS | cho gần như mọi tải | trường hợp rất đặc thù |

(Đáp án B vẫn đúng theo cách phân loại mà bộ đề dựa vào: trong hai chế độ hiệu năng, Max I/O là chế độ nhắm tới tải song song quy mô lớn.)

Ghi nhớ

Hai loại cấu hình của EFS — phân biệt rõ: | Loại cấu hình | Lựa chọn | |---|---| | Performance mode (chế độ hiệu năng) | General Purpose / Max I/O ← câu này | | Throughput mode (chế độ thông lượng) | Elastic / Provisioned / Bursting |

Nhầm lẫn giữa hai loại này là bẫy chính của câu hỏi.

Ba chế độ thông lượng: | Chế độ | Đặc điểm | |---|---| | Elastic (mặc định mới) | tự co giãn, trả theo lượng dùng thật | | Provisioned | khai trước, tính phí dù không dùng | | Bursting | thông lượng theo dung lượng, có hệ thống credit |

Bursting là chế độ cũ và hay gây bất ngờ:

Baseline: 50 KB/giây mỗi GiB lưu trữ
    → file system 100 GiB → chỉ 5 MB/giây baseline
    → burst được lên cao hơn NHƯNG tiêu credit
        ↓
    Hết credit → tụt về baseline → CHẬM ĐỘT NGỘT

Metric BurstCreditBalance là thứ phải theo dõi nếu dùng chế độ này.

Elastic throughput giải quyết vấn đề đó:

Elastic:
    ✓ không có credit, không có trần theo dung lượng
    ✓ tự co giãn tới hàng GB/giây
    ✓ trả theo lượng dữ liệu đọc ghi thật

Ba lớp lưu trữ của EFS: | Lớp | Giá tham khảo | |---|---| | Standard | ~0,30 USD/GB-tháng | | Standard-IA | ~0,025 USD/GB-tháng | | Archive | ~0,008 USD/GB-tháng | | One Zone (và IA) | rẻ hơn ~47% |

Và lifecycle tự phân tầng:

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

Ba lựa chọn lưu trữ chia sẻ cho big data: | Lựa chọn | Đặc điểm | |---|---| | EFS | NFS đơn giản, tự co giãn ← câu này | | FSx for Lustre | thông lượng CAO NHẤT — chuẩn cho HPC và big data | | S3 | rẻ nhất, truy cập qua API |

FSx for Lustre thường là lựa chọn tốt hơn cho big data thật sự:

FSx for Lustre:
    ✓ hàng trăm GB/giây thông lượng
    ✓ hàng triệu IOPS
    ✓ tích hợp nguyên bản với S3 (lazy loading)
        ↓
    Nếu tải big data là nút thắt hiệu năng,
    đây là công cụ đúng hơn EFS ở bất kỳ chế độ nào

Ba cách tăng hiệu năng EFS: | Cách | Chi tiết | |---|---| | Dùng Elastic throughput | bỏ trần theo dung lượng | | Tăng số client song song | EFS mở rộng theo số kết nối | | Chỉnh tham số mount NFS | rsize, wsize, nconnect |

Tham số nconnect đáng biết:

sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,nconnect=16   fs-0abc.efs.ap-northeast-1.amazonaws.com:/ /du-lieu

nconnect mở nhiều kết nối TCP song song — tăng thông lượng đáng kể cho một client.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | PercentIOLimit | gần 100% nghĩa là chạm trần IOPS của chế độ hiện tại | | MeteredIOBytes | thông lượng thực tế | | BurstCreditBalance | chỉ với chế độ Bursting |

PercentIOLimit là chỉ báo trực tiếp — nếu nó thường xuyên gần 100% với General Purpose thì mới cần cân nhắc đổi.

Và một lời khuyên: hãy đo PercentIOLimit trước khi đổi chế độ hiệu năng. Chế độ không đổi được sau khi tạo file system, nên quyết định sai nghĩa là phải dựng lại và chuyển toàn bộ dữ liệu — và với cấu hình EFS hiện tại, phần lớn tải big data chạy tốt hơn trên General Purpose với Elastic throughput.

Đáp án

D — Amazon FSx for Windows File Server.

Vì sao đúng

Đề nêu từ khoá quyết định: DFSR (Distributed File System Replication) của Microsoft.

DFSR là công nghệ của WINDOWS SERVER
    → đồng bộ tệp giữa nhiều máy chủ Windows
    → gắn liền với SMB, NTFS và Active Directory
        ↓
    Chỉ dịch vụ dựa trên Windows Server mới thay thế được

FSx for Windows File Server chạy Windows Server thật:

FSx for Windows:
    ✓ hỗ trợ DFS Namespaces và DFS Replication
    ✓ giao thức SMB
    ✓ tích hợp Active Directory
    ✓ ACL của NTFS, shadow copy, quota
        ↓
    Đội ngũ dùng đúng công cụ và quy trình quen thuộc

Và hai khả năng DFS mà FSx cung cấp: | Khả năng | Việc | |---|---| | DFS Namespaces | gộp nhiều file system thành MỘT không gian tên | | DFS Replication | đồng bộ giữa hai FSx, hoặc giữa FSx và máy chủ tại chỗ |

Cấu hình DFS Replication giữa hai FSx:

New-DfsReplicationGroup -GroupName "NhomDongBo"
Add-DfsrMember -GroupName "NhomDongBo" -ComputerName "amznfsxabc123"
Add-DfsrMember -GroupName "NhomDongBo" -ComputerName "amznfsxdef456"
Add-DfsrConnection -GroupName "NhomDongBo" `
  -SourceComputerName "amznfsxabc123" -DestinationComputerName "amznfsxdef456"

Và cho mô hình lai, DFSR đồng bộ giữa tại chỗ và AWS:

Máy chủ Windows tại chỗ ⟷ DFS Replication ⟷ FSx for Windows
    (qua Direct Connect hoặc VPN)
        ↓
    Chuyển đổi DẦN DẦN, không phải cắt một lần

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

• **A. Amazon EFS — đây là phương án gần nhất vì cũng là dịch vụ hệ thống tệp chia sẻ được quản lý, nhưng nó sai giao thức: EFS phục vụ NFS cho Linux, không hỗ trợ SMB, không tích hợp Active Directory, và không có DFS. Máy chủ Windows không mount được EFS một cách tự nhiên.
• **C. FSx for Lustre — sai hoàn toàn: Lustre là hệ thống tệp song song cho HPC trên Linux, dùng giao thức Lustre. Không liên quan gì tới Windows hay DFS.
• **B. Amazon S3 — sai mô hình lưu trữ: S3 là kho object qua HTTP API, không mount được làm ổ đĩa Windows và không có khái niệm DFS.

Ghi nhớ

Bốn dịch vụ trong họ Amazon FSx — bảng phải thuộc: | Dịch vụ | Giao thức | Đặc trưng | |---|---|---| | FSx for Windows File Server | SMB | DFS, Active Directory, NTFS ACL ← câu này | | FSx for Lustre | Lustre (POSIX) | HPC, học máy, tích hợp S3 | | FSx for NetApp ONTAP | NFS, SMB, iSCSI | đa giao thức, snapshot, cloning | | FSx for OpenZFS | NFS | di chuyển từ ZFS tại chỗ |

Từ khoá nhận diện — bảng quan trọng:

"Windows", "SMB", "Active Directory", "DFS", "DFSR", "NTFS" → FSx for Windows "HPC", "parallel", "machine learning", "genomics" → FSx for Lustre "multi-protocol", "NetApp", "SnapMirror" → FSx for ONTAP "Linux NFS, auto-scaling, simple" → Amazon EFS "object storage, HTTP API" → S3

Ba tính năng riêng của FSx for Windows: | Tính năng | Chi tiết | |---|---| | Data deduplication | tiết kiệm 50–60% với dữ liệu doanh nghiệp | | Shadow Copy | người dùng tự khôi phục phiên bản cũ | | User quota | giới hạn dung lượng theo người dùng | | DFS Namespaces và Replication | ← câu này |

Hai kiểu triển khai: | Kiểu | Đặc điểm | |---|---| | Single-AZ | rẻ hơn, không chịu được mất AZ | | Multi-AZ | standby ở AZ khác, tự chuyển đổi — cho sản xuất |

Ba yêu cầu để triển khai: | Yêu cầu | Chi tiết | |---|---| | Active Directory | AWS Managed AD hoặc AD tại chỗ tự quản | | Subnet trong VPC | hai subnet nếu Multi-AZ | | Security group mở cổng SMB (445) và cổng AD | |

Và tích hợp với AD tại chỗ là lựa chọn thường dùng cho mô hình lai:

FSx tham gia CHÍNH domain AD tại chỗ
    → người dùng đăng nhập bằng tài khoản quen thuộc
    → ACL hiện có áp dụng nguyên vẹn
    → cần đường mạng tới domain controller

Ba cách di chuyển dữ liệu lên FSx: | Cách | Đặc điểm | |---|---| | AWS DataSync | nhanh, GIỮ ACL và metadata NTFS | | DFS Replication | đồng bộ liên tục hai chiều ← phù hợp mô hình lai | | Robocopy | thủ công, khối lượng nhỏ |

Giữ được ACL là điểm quan trọng:

Sao chép bằng công cụ thường:
    → mất ACL của NTFS
    → phải cấu hình lại toàn bộ phân quyền

DataSync và DFSR:
    → giữ nguyên ACL, timestamp, chủ sở hữu

Ba lựa chọn lưu trữ và thông lượng: | Cấu hình | Lựa chọn | |---|---| | Storage type | SSD (hiệu năng) hoặc HDD (dung lượng lớn, rẻ) | | Throughput capacity | 8 – 2.048+ MB/giây, đổi được sau | | Dung lượng | 32 GiB – 64 TiB (mở rộng được) |

Ba lưu ý về DFS Namespaces: | Lưu ý | Chi tiết | |---|---| | Cần máy chủ namespace | thường là EC2 Windows chạy DFS Namespace role | | Gộp nhiều FSx thành một không gian tên | vượt giới hạn dung lượng của một file system | | Người dùng thấy một đường dẫn thống nhất | \\congty.local\chia-se |

Ba dịch vụ liên quan cho mô hình lai: | Dịch vụ | Việc | |---|---| | FSx File Gateway | truy cập FSx từ tại chỗ với cache cục bộ | | AWS Managed Microsoft AD | thư mục danh tính trên AWS | | Direct Connect hoặc VPN | kết nối mạng |

FSx File Gateway giải quyết vấn đề độ trễ:

Người dùng tại chỗ truy cập FSx trên AWS:
    → không có gateway: mỗi thao tác tệp đi qua WAN
    → có gateway: dữ liệu nóng được cache tại chỗ
        ↓
    Trải nghiệm như file server nội bộ

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Tính theo dung lượng CẤP PHÁT | không phải dung lượng dùng | | Thông lượng tính riêng | ảnh hưởng giá đáng kể | | Bật deduplication | giảm dung lượng thật cần cấp |

Ba lưu ý khi lập kế hoạch di chuyển: | Lưu ý | Chi tiết | |---|---| | Kiểm kê ACL và cấu trúc thư mục hiện tại | | | Thử với một phần dữ liệu trước | kiểm chứng ACL được giữ | | Chạy song song một thời gian | DFSR đồng bộ hai chiều |

Và một lời khuyên: hãy dùng DFS Replication để chạy song song vài tuần trước khi tắt máy chủ tại chỗ. Nó cho phép người dùng chuyển dần và cho bạn thời gian phát hiện những phụ thuộc không ai nhớ tới — script cũ, ứng dụng nội bộ trỏ vào đường dẫn UNC cụ thể, hoặc máy in mạng ánh xạ tới thư mục nào đó.

Đáp án

A — Server-side encryption với AWS KMS keys (SSE-KMS) kèm xoay vòng khoá TỰ ĐỘNG.

Vì sao đúng

Đề nêu ba yêu cầu tuân thủ, và SSE-KMS với xoay vòng tự động là lựa chọn duy nhất thoả cả ba: | Yêu cầu | Cơ chế | |---|---| | GHI LOG việc dùng khoá để kiểm toán | CloudTrail ghi mọi lời gọi KMS | | Xoay vòng khoá MỖI NĂM | KMS tự xoay vòng hằng năm | | Mã hoá dữ liệu at rest | server-side encryption |

Vế thứ nhất là điểm phân biệt tuyệt đối:

SSE-KMS:
    → mỗi lời gọi Encrypt và Decrypt được ghi vào CloudTrail
    → biết CHÍNH XÁC: ai, object nào, lúc nào, từ IP nào

SSE-S3 và SSE-C:
    → KHÔNG có bản ghi nào về việc dùng khoá

Ví dụ bản ghi CloudTrail của SSE-KMS:

{"eventName": "Decrypt",
 "userIdentity": {"arn": "arn:aws:sts::...:assumed-role/vai-tro-bao-cao/i-0abc"},
 "requestParameters": {"encryptionContext": {
     "aws:s3:arn": "arn:aws:s3:::kho-tai-chinh/giao-dich-2026.json"}},
 "sourceIPAddress": "10.0.1.25"}

Trường encryptionContext cho biết chính xác object nào được giải mã.

Và vế "tự động" là điểm phân biệt với phương án C:

aws kms enable-key-rotation --key-id abc-123

Xoay vòng tự động:
    ✓ KMS tạo key material MỚI mỗi năm
    ✓ GIỮ LẠI key material cũ để giải mã dữ liệu cũ
    ✓ TRONG SUỐT với ứng dụng — không phải mã hoá lại gì
    ✓ không có thao tác thủ công nào

So với xoay vòng thủ công:

Thủ công:
    → phải tạo khoá mới
    → cập nhật cấu hình bucket
    → theo dõi lịch, dễ quên
    → nhiều công vận hành hơn hẳn

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

• **C. SSE-KMS với xoay vòng THỦ CÔNG — đây là phương án gần nhất và thoả cả ba yêu cầu về mặt kết quả, nhưng nó kém hiệu quả vận hành hơn: đề hỏi "MOST operationally efficient", và xoay vòng thủ công đòi quy trình, lịch nhắc và thao tác con người mỗi năm — đúng thứ mà tự động hoá loại bỏ.
• **B. SSE-C với xoay vòng tự động — hai lỗi: SSE-C không có audit trail (AWS không lưu khoá nên không ghi được), và không có cơ chế xoay vòng tự động — bạn tự quản lý khoá hoàn toàn.
• **D. SSE-S3 với xoay vòng tự động — thiếu vế audit: SSE-S3 do AWS quản lý khoá hoàn toàn và không ghi lại việc dùng khoá. (SSE-S3 có xoay vòng ở tầng nền nhưng bạn không thấy và không kiểm soát được.)

Ghi nhớ

Năm cách mã hoá S3 — bảng phải thuộc: | Cách | Ai giữ khoá | Audit dùng khoá | Xoay vòng | |---|---|---|---| | SSE-S3 | AWS hoàn toàn | ❌ | AWS lo, không thấy | | SSE-KMS | KMS, bạn kiểm soát policy | ✅ CloudTrail | ✅ tự động hằng năm | | DSSE-KMS | KMS, mã hoá HAI lớp | ✅ | ✅ | | SSE-C | BẠN — gửi mỗi request | ❌ | tự lo | | Client-side | BẠN hoàn toàn | ❌ | tự lo |

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

"audit key usage", "who used the key and when" → SSE-KMS "key rotation policy", "rotate annually" → SSE-KMS với enable-key-rotation "simplest, AWS manages everything" → SSE-S3 "key must never leave our premises" → SSE-C hoặc client-side

Ba loại khoá KMS và cách xoay vòng: | Loại | Xoay vòng | |---|---| | AWS managed key (aws/s3) | TỰ ĐỘNG mỗi năm, không tắt được | | Customer managed key | tuỳ chọn — bật bằng enable-key-rotation | | Khoá có key material nhập vào | KHÔNG tự xoay vòng được |

Với yêu cầu tuân thủ, customer managed key là lựa chọn đúng — nó cho phép đặt key policy riêng và audit chi tiết hơn.

Ba đặc điểm của xoay vòng tự động: | Đặc điểm | Chi tiết | |---|---| | Chu kỳ mặc định 365 ngày | tuỳ chỉnh được từ 90 tới 2560 ngày | | Key ID và ARN KHÔNG đổi | ứng dụng không phải sửa gì | | Key material CŨ được GIỮ LẠI | dữ liệu cũ vẫn giải mã được |

Điểm cuối rất quan trọng:

Xoay vòng KHÔNG mã hoá lại dữ liệu cũ
    → object cũ vẫn dùng key material cũ
    → KMS tự chọn đúng phiên bản khi giải mã
        ↓
    Hoàn toàn trong suốt

Và tuỳ chỉnh chu kỳ:

aws kms enable-key-rotation --key-id abc-123 --rotation-period-in-days 180

Ba chi phí của SSE-KMS: | Khoản | Chi tiết | |---|---| | Lưu khoá | ~1 USD/khoá/tháng (customer managed) | | Lời gọi API | ~0,03 USD mỗi 10.000 lời gọi | | Mỗi phiên bản khoá do xoay vòng | tính thêm ~1 USD/tháng |

Dòng cuối đáng lưu ý: sau 5 năm xoay vòng, một khoá có 5 phiên bản và tính phí tương ứng.

Và S3 Bucket Keys giảm mạnh chi phí lời gọi:

{"Rules": [{"ApplyServerSideEncryptionByDefault": {
    "SSEAlgorithm": "aws:kms", "KMSMasterKeyID": "<arn>"},
    "BucketKeyEnabled": true}]}

Giảm tới 99% số lời gọi KMS — nên bật cho mọi bucket dùng SSE-KMS.

Lưu ý: Bucket Keys làm giảm độ chi tiết của log CloudTrail — thay vì một bản ghi mỗi object, bạn có một bản ghi mỗi bucket key. Với yêu cầu audit rất chặt, đó là đánh đổi cần cân nhắc.

Ba biện pháp bổ sung cho dữ liệu tài chính: | Biện pháp | Chi tiết | |---|---| | Bắt buộc SSE-KMS bằng bucket policy | chặn PutObject không mã hoá | | Bắt buộc HTTPS | aws:SecureTransport | | Bật CloudTrail data event cho S3 | ghi mọi thao tác object-level |

Chính sách bắt buộc SSE-KMS:

{"Effect": "Deny", "Principal": "*", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::kho-tai-chinh/*",
 "Condition": {"StringNotEquals":
   {"s3:x-amz-server-side-encryption": "aws:kms"}}}

Nhớ thêm statement thứ hai chặn request thiếu hẳn header:

{"Condition": {"Null": {"s3:x-amz-server-side-encryption": "true"}}}

Ba nguồn audit bổ sung nhau: | Nguồn | Ghi gì | |---|---| | CloudTrail management event | thao tác quản trị (tạo bucket, đổi policy) | | CloudTrail data event cho S3 | ai ĐỌC object nào | | CloudTrail cho KMS | ai GIẢI MÃ, dùng khoá nào |

Và một lời khuyên: hãy bật cả CloudTrail data event cho S3 lẫn log của KMS. Chúng trả lời hai câu hỏi khác nhau — "ai chạm vào object" và "ai dùng khoá" — và với kiểm toán ngành tài chính, cả hai đều sẽ được hỏi tới.