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

Đáp án

A và B.

• A — Bật xác thực đa yếu tố (MFA) cho tài khoản root
• B — Đặt mật khẩu mạnh cho tài khoản root

Vì sao đúng

Tài khoản root có toàn quyền tuyệt đối và không giới hạn được bằng IAM policy — nên bảo vệ nó là ưu tiên số một.

Vì sao root đặc biệt nguy hiểm nếu bị chiếm:

Tài khoản root có thể:
    ✓ đóng cả tài khoản AWS
    ✓ đổi phương thức thanh toán
    ✓ xoá mọi tài nguyên
    ✓ gỡ mọi ràng buộc IAM
        ↓
    → IAM policy KHÔNG giới hạn được root
    → chỉ SCP của Organizations mới hạn chế được phần nào

A — MFA là lớp bảo vệ mạnh nhất:

Mật khẩu bị lộ (lừa đảo, dùng lại, rò rỉ):
    Không có MFA → kẻ tấn công vào được ngay
    Có MFA       → vẫn cần thiết bị vật lý

B — và mật khẩu mạnh là điều kiện nền:

Mật khẩu root nên:
    ✓ dài (20 ký tự trở lên)
    ✓ ngẫu nhiên, sinh bằng trình quản lý mật khẩu
    ✓ KHÔNG dùng lại ở bất kỳ đâu khác
    ✓ lưu trong két an toàn hoặc trình quản lý mật khẩu

Và AWS khuyến nghị mạnh:

Sau khi tạo tài khoản:
    ① Bật MFA cho root
    ② Tạo IAM user hoặc Identity Center cho công việc hằng ngày
    ③ CẤT thông tin đăng nhập root đi
    ④ KHÔNG tạo access key cho root

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

• **C. Tạo access key cho root và chỉ chia sẻ với chủ doanh nghiệp — đây là phương án gần nhất vì nó có vẻ hạn chế phạm vi chia sẻ, nhưng nó đi ngược khuyến nghị rõ ràng nhất của AWS: không bao giờ tạo access key cho tài khoản root. Access key dài hạn với toàn quyền tuyệt đối là thứ nguy hiểm nhất có thể tồn tại trong một tài khoản AWS.
• **E. Mã hoá access key và lưu trên S3 — cùng vấn đề: access key của root không nên tồn tại. Và lưu chúng trong chính tài khoản mà chúng kiểm soát là vòng luẩn quẩn — mất quyền vào tài khoản thì cũng không lấy được key ra.
• **D. Gửi email thông tin đăng nhập root cho chủ doanh nghiệp — rất kém: email thường không mã hoá đầu-cuối, được lưu vô thời hạn ở nhiều nơi, và hòm thư bị xâm nhập là mất cả tài khoản AWS.

Ghi nhớ

Sáu việc phải làm ngay khi tạo tài khoản AWS: | Việc | Lý do | |---|---| | Bật MFA cho root | ← câu này | | Đặt mật khẩu root mạnh, không dùng lại | ← câu này | | KHÔNG tạo access key cho root | không có key thì không lộ được | | Tạo danh tính riêng cho việc hằng ngày | Identity Center hoặc IAM user | | Bật CloudTrail | ghi lại mọi thao tác | | Đặt cảnh báo chi phí | phát hiện lạm dụng sớm |

Và AWS khuyến nghị đăng ký NHIỀU thiết bị MFA cho root:

Từ 2024, mỗi user root và IAM user gắn được tối đa 8 thiết bị MFA
    → đăng ký ít nhất 2 (một khoá phần cứng, một ứng dụng)
    → mất một cái vẫn vào được

Ba loại MFA — chọn cái nào: | Loại | Đặc điểm | |---|---| | Khoá bảo mật FIDO2 (YubiKey) | chống lừa đảo tốt nhất — khuyến nghị cho root | | Passkey | tiện, cũng chống lừa đảo | | Virtual MFA (ứng dụng) | miễn phí, phổ biến, nhưng OTP vẫn bị lừa lấy được |

Sáu việc CHỈ tài khoản root làm được: | Việc | Chi tiết | |---|---| | Đổi thông tin thanh toán và email tài khoản | | | ĐÓNG tài khoản AWS | | | Đổi kế hoạch AWS Support | | | Bật MFA Delete cho bucket S3 | ← điểm hay gặp trong đề thi | | Khôi phục quyền khi IAM policy bị khoá nhầm | | | Đăng ký làm người bán trên Marketplace | |

Chính vì danh sách này mà root không xoá được — chỉ cất đi.

Ba biện pháp bảo vệ root ở cấp tổ chức: | Biện pháp | Chi tiết | |---|---| | SCP chặn hành động của root ở tài khoản thành viên | cơ chế duy nhất giới hạn được root | | Cảnh báo khi có đăng nhập root | CloudWatch metric filter + SNS | | Quản lý tập trung root với Organizations | tính năng mới, xoá được thông tin đăng nhập root của tài khoản thành viên |

SCP chặn root ở tài khoản thành viên:

{"Effect": "Deny", "Action": "*", "Resource": "*",
 "Condition": {"StringLike": {"aws:PrincipalArn": "arn:aws:iam::*:root"}}}

Lưu ý: SCP không áp cho tài khoản quản lý của Organization — tài khoản đó vẫn cần bảo vệ theo cách thông thường.

Và alarm cho đăng nhập root:

aws logs put-metric-filter --log-group-name /aws/cloudtrail   --filter-name dang-nhap-root   --filter-pattern '{$.userIdentity.type = "Root" && $.eventName != "AwsServiceEvent"}'   --metric-transformations metricName=DangNhapRoot,metricNamespace=BaoMat,metricValue=1

Đăng nhập root nên là sự kiện hiếm — mỗi lần đều đáng được xem xét.

Ba dấu hiệu tài khoản bị xâm nhập: | Dấu hiệu | Kiểm tra ở đâu | |---|---| | Instance EC2 lạ ở Region không dùng | EC2 console mọi Region | | IAM user hoặc access key mới không rõ nguồn | Credential Report | | Chi phí tăng đột biến | Cost Explorer, Billing alert |

Và quy trình xử lý khi nghi ngờ:

① Đổi mật khẩu root, xoay vòng mọi access key
② Xoá IAM user và role lạ
③ Kiểm tra CloudTrail để biết đã làm gì
④ Liên hệ AWS Support

Ba công cụ rà soát bảo mật định kỳ: | Công cụ | Việc | |---|---| | IAM Credential Report | ai chưa bật MFA, key nào quá cũ | | AWS Trusted Advisor | kiểm tra bảo mật cơ bản | | AWS Security Hub | tổng hợp theo chuẩn CIS, PCI |

Và một lời khuyên cho doanh nghiệp nhỏ: hãy lưu thông tin đăng nhập root vào két sắt vật lý cùng với một khoá MFA phần cứng dự phòng, và ghi rõ quy trình khôi phục. Doanh nghiệp vừa và nhỏ thường chỉ có một người biết mật khẩu — và khi người đó nghỉ việc hoặc mất thiết bị, việc lấy lại quyền vào tài khoản AWS là một quá trình rất chậm và đau đớn.

Đáp án

A — Dùng Amazon GuardDuty giám sát hoạt động độc hại trên dữ liệu S3, và dùng Amazon Inspector để kiểm tra lỗ hổng trên EC2 instance.

Vì sao đúng

Hai dịch vụ, hai mục đích hoàn toàn khác nhau — và đáp án ghép đúng cả hai:

GuardDuty cho S3:

GuardDuty S3 Protection phân tích CloudTrail data event của S3
    → phát hiện:
        ✓ truy cập từ IP độc hại đã biết
        ✓ truy cập từ Tor exit node
        ✓ mẫu tải xuống bất thường (rò rỉ dữ liệu)
        ✓ vô hiệu hoá Block Public Access
        ✓ hành vi giống ransomware

Finding tiêu biểu: | Finding | Ý nghĩa | |---|---| | Exfiltration:S3/AnomalousBehavior | tải xuống bất thường — dấu hiệu rò rỉ | | Impact:S3/MaliciousIPCaller | gọi từ IP độc hại | | Discovery:S3/AnomalousBehavior | dò quét bucket | | PenTest:S3/KaliLinux | truy cập từ công cụ kiểm thử xâm nhập |

Inspector cho EC2:

Amazon Inspector quét LIÊN TỤC:
    ✓ CVE trong gói phần mềm đã cài
    ✓ vấn đề network reachability (cổng phơi ra Internet)
    ✓ chấm điểm rủi ro theo ngữ cảnh
        ↓
    Dùng SSM Agent — KHÔNG cần cài agent riêng

Và cả hai đều bật bằng một công tắc:

aws guardduty create-detector --enable   --data-sources '{"S3Logs":{"Enable":true}}'
aws inspector2 enable --resource-types EC2 ECR LAMBDA

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

• **D. Dùng GuardDuty cho CẢ HAI — đây là phương án gần nhất vì vế S3 đúng, nhưng nó sai vế EC2: GuardDuty phát hiện hành vi độc hại (giao tiếp với máy chủ điều khiển, đào tiền mã hoá), nó không quét lỗ hổng phần mềm. Hai việc khác nhau: một cái tìm "có ai đang tấn công không", cái kia tìm "có chỗ nào dễ bị tấn công không".
• **C. Dùng Inspector cho cả hai — sai vế S3: Inspector quét EC2, container image trong ECR, và Lambda. Nó không giám sát hoạt động trên dữ liệu S3.
• **B. Inspector cho S3 và GuardDuty cho EC2 — đảo ngược hoàn toàn.

Ghi nhớ

Các dịch vụ bảo mật của AWS — bảng cần thuộc: | Dịch vụ | Việc | |---|---| | GuardDuty | PHÁT HIỆN ĐE DOẠ từ log (CloudTrail, VPC Flow, DNS, S3, EKS, RDS) | | Inspector | QUÉT LỖ HỔNG (EC2, ECR, Lambda) | | Macie | PHÁT HIỆN DỮ LIỆU NHẠY CẢM trong S3 (PII, PHI) | | Security Hub | TỔNG HỢP finding từ mọi dịch vụ, chấm theo chuẩn | | Detective | ĐIỀU TRA sâu một finding | | AWS Config | tuân thủ cấu hình theo quy tắc | | CloudTrail | ghi lời gọi API | | AWS WAF | lọc lưu lượng web |

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

"malicious activity", "threat detection", "unusual behavior", "compromised" → GuardDuty "vulnerabilities", "CVE", "unpatched software", "security assessment" → Inspector "sensitive data", "PII", "PHI", "credit card in S3" → Macie "compliance standard", "aggregate findings", "CIS benchmark" → Security Hub "root cause", "investigate", "visualize relationships" → Detective

Ba nguồn dữ liệu chính của GuardDuty: | Nguồn | Phát hiện | |---|---| | CloudTrail | lời gọi API bất thường, thông tin đăng nhập bị lộ | | VPC Flow Logs | giao tiếp với IP độc hại, đào tiền mã hoá | | DNS logs | truy vấn tới miền độc hại, DNS tunneling |

Và các tính năng bảo vệ mở rộng (tính phí riêng): | Tính năng | Phát hiện | |---|---| | S3 Protection | ← câu này | | EKS Protection | hành vi bất thường trong cụm Kubernetes | | Malware Protection | quét mã độc trên volume EBS | | RDS Protection | đăng nhập database bất thường | | Lambda Protection | hoạt động mạng đáng ngờ từ hàm |

Ba đặc điểm của Amazon Inspector: | Đặc điểm | Chi tiết | |---|---| | Quét LIÊN TỤC, tự động | không phải lên lịch | | Dùng SSM Agent | không cài agent riêng | | Chấm điểm theo NGỮ CẢNH | CVE nghiêm trọng trên máy không phơi ra Internet được hạ điểm |

Điểm cuối rất giá trị:

CVSS thô: 9,8 (nghiêm trọng)
Inspector score: 4,2
    → vì máy nằm trong private subnet, không có đường từ Internet
        ↓
    → Ưu tiên vá đúng thứ thật sự nguy hiểm

Ba loại tài nguyên Inspector quét: | Loại | Chi tiết | |---|---| | EC2 | CVE trong gói phần mềm + network reachability | | ECR | image container khi đẩy lên | | Lambda | mã và phụ thuộc |

Và quét ECR rất đáng bật — nó bắt lỗ hổng trước khi image được triển khai.

Ba lưu ý về chi phí: | Dịch vụ | Cách tính | |---|---| | GuardDuty | theo lượng log phân tích — S3 Protection có thể đắt với bucket lưu lượng lớn | | Inspector | theo instance-tháng và image quét | | Macie | theo dung lượng dữ liệu quét |

Cả ba đều có 30 ngày dùng thử miễn phí — nên bật thử để biết chi phí thật trước khi cam kết.

Ba việc nên làm sau khi bật: | Việc | Chi tiết | |---|---| | Nối vào Security Hub | một chỗ xem mọi finding | | Đặt EventBridge rule cho finding nghiêm trọng | tự động cảnh báo hoặc phản ứng | | Bật ở TẤT CẢ Region | kẻ tấn công thường chọn Region bạn không dùng |

Và tự động phản ứng với finding:

{"source": ["aws.guardduty"],
 "detail-type": ["GuardDuty Finding"],
 "detail": {"severity": [{"numeric": [">=", 7]}]}}

→ Lambda cách ly instance, xoay vòng thông tin đăng nhập, hoặc gửi cảnh báo.

Ba lưu ý khi vận hành nhiều tài khoản: | Lưu ý | Chi tiết | |---|---| | Chỉ định tài khoản quản trị viên uỷ quyền | quản lý tập trung cho cả Organization | | Bật tự động cho tài khoản MỚI | không sót tài khoản nào | | Tập trung finding về một chỗ | Security Hub |

Và một lời khuyên: hãy nhớ GuardDuty và Inspector bổ sung nhau, không thay thế nhau. Inspector cho biết bạn có lỗ hổng gì; GuardDuty cho biết có ai đang khai thác nó không. Chỉ có một trong hai là hoặc bạn vá mù, hoặc bạn phát hiện muộn.

Đáp án

A và C.

• A — Triển khai Babelfish for Aurora PostgreSQL để hỗ trợ lệnh T-SQL
• C — Dùng AWS Schema Conversion Tool (SCT) cùng AWS Database Migration Service (DMS) để chuyển lược đồ và dữ liệu

Vì sao đúng

Đề nêu ràng buộc then chốt: tránh sửa lớn logic ứng dụng hiện có.

A — Babelfish là thứ giải quyết đúng ràng buộc đó:

Babelfish for Aurora PostgreSQL:
    → hiểu giao thức TDS của SQL Server
    → hiểu cú pháp T-SQL
        ↓
    Ứng dụng vẫn kết nối như đang nói chuyện với SQL Server
    → chuỗi kết nối gần như giữ nguyên
    → truy vấn T-SQL chạy được không cần viết lại

Cụ thể Babelfish làm gì: | Thành phần | Chi tiết | |---|---| | Cổng TDS 1433 | chính là cổng SQL Server — client không biết khác biệt | | Phương ngữ T-SQL | TOP, ISNULL, GETDATE, biến @, stored procedure | | Cổng PostgreSQL 5432 | vẫn dùng được song song |

aws rds create-db-cluster --engine aurora-postgresql   --engine-version 15.3 --db-cluster-identifier cum-khach-hang   --enable-babelfish   --db-cluster-parameter-group-name pg-babelfish

C — SCT và DMS là bộ công cụ chuẩn để chuyển:

AWS SCT:
    → phân tích lược đồ SQL Server
    → chuyển bảng, index, view, stored procedure sang PostgreSQL
    → BÁO CÁO những gì không tự chuyển được

AWS DMS:
    → chuyển dữ liệu
    → có CDC (change data capture) → đồng bộ liên tục
    → cắt chuyển với thời gian ngừng rất ngắn

Và hai đáp án bổ sung nhau đúng theo trình tự:

① SCT + DMS  → đưa lược đồ và dữ liệu sang Aurora PostgreSQL
② Babelfish  → cho ứng dụng tiếp tục nói T-SQL với database mới

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

• **B. Dùng AWS Glue để chuyển truy vấn T-SQL sang SQL tương thích PostgreSQL trong lúc di chuyển — đây là phương án gần nhất vì Glue thực sự là công cụ ETL của AWS, nhưng nó sai chức năng: Glue chuyển DỮ LIỆU, không dịch MÃ TRUY VẤN trong ứng dụng. Công cụ dịch lược đồ và mã là SCT.
• **D. Cấu hình Aurora PostgreSQL với custom endpoint mô phỏng hành vi SQL Server — không có cơ chế như vậy: custom endpoint của Aurora chỉ là cách nhóm các instance trong cụm để phân luồng kết nối. Nó không đổi phương ngữ SQL.
• **E. Dùng Aurora Global Database để sao chép xuyên Region "cho tương thích" — sai mục đích hoàn toàn: Global Database phục vụ khôi phục thảm hoạ và đọc ở nhiều Region, không liên quan gì tới tương thích cú pháp.

Ghi nhớ

Bộ công cụ di chuyển database của AWS: | Công cụ | Việc | |---|---| | AWS SCT | chuyển LƯỢC ĐỒ và MÃ (stored procedure, function) | | AWS DMS | chuyển DỮ LIỆU, có CDC | | Babelfish | lớp tương thích T-SQL cho Aurora PostgreSQL | | DMS Schema Conversion | bản chạy trong đám mây của SCT |

Hai loại di chuyển database: | Loại | Đặc điểm | |---|---| | Homogeneous (cùng engine) | SQL Server → RDS SQL Server: chỉ cần DMS | | Heterogeneous (khác engine) | SQL Server → PostgreSQL: cần CẢ SCT LẪN DMS |

Ba giai đoạn của một dự án di chuyển:

① Đánh giá   → SCT tạo báo cáo: bao nhiêu phần trăm tự chuyển được
② Chuyển đổi → SCT chuyển lược đồ, con người xử lý phần còn lại
③ Di chuyển  → DMS full load + CDC, rồi cắt chuyển

Và báo cáo đánh giá của SCT rất quan trọng:

Nó phân loại từng đối tượng:
    ✓ tự chuyển được hoàn toàn
    ⚠ chuyển được nhưng cần xem lại
    ✗ phải viết lại bằng tay
        ↓
    → Đây là căn cứ để ước lượng thời gian dự án

Ba lợi ích của Babelfish: | Lợi ích | Chi tiết | |---|---| | Không sửa (hoặc sửa rất ít) mã ứng dụng | ← lý do chính | | Bỏ chi phí GIẤY PHÉP SQL Server | khoản tiết kiệm lớn nhất | | Chuyển đổi DẦN DẦN | viết lại từng phần sang PostgreSQL nguyên bản theo thời gian |

Điểm cuối là chiến lược thực tế nhất:

Giai đoạn 1: mọi thứ qua cổng TDS của Babelfish
Giai đoạn 2: viết lại module mới bằng SQL PostgreSQL, dùng cổng 5432
Giai đoạn 3: dần dần chuyển hết, tắt Babelfish
    → không có "vụ nổ lớn" nào

Ba hạn chế của Babelfish cần biết: | Hạn chế | Chi tiết | |---|---| | Không hỗ trợ 100% T-SQL | phải kiểm thử kỹ | | Không có SQL Server Agent, SSIS, SSRS | phải thay bằng công cụ khác | | Một số kiểu dữ liệu và hàm không có | |

Và AWS có công cụ kiểm tra tương thích trước:

Babelfish Compass — phân tích mã T-SQL của bạn
    → báo cáo cái gì Babelfish hỗ trợ, cái gì không
    → chạy TRƯỚC khi quyết định

Đây là bước bắt buộc — đừng bắt đầu dự án mà không biết tỷ lệ tương thích.

Ba chế độ của DMS: | Chế độ | Việc | |---|---| | Full load | chuyển toàn bộ dữ liệu hiện có | | CDC | chỉ chuyển thay đổi — đồng bộ liên tục | | Full load + CDC | chuyển hết rồi bám theo — thời gian ngừng tối thiểu |

Chế độ thứ ba là cách cắt chuyển với gián đoạn ngắn nhất:

① Full load chạy trong nhiều ngày (không ảnh hưởng hệ thống cũ)
② CDC bám theo mọi thay đổi mới
③ Đến giờ cắt chuyển: dừng ghi vào nguồn vài phút
④ Chờ CDC đuổi kịp → chuyển ứng dụng sang đích

Ba lưu ý khi dùng DMS: | Lưu ý | Chi tiết | |---|---| | DMS không chuyển index, khoá ngoại, trigger | chỉ chuyển dữ liệu — phần đó do SCT | | Tạo index SAU khi full load xong | nhanh hơn nhiều | | Bật validation | so sánh nguồn và đích |

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, tính theo lõi | | Software Assurance | phí duy trì hằng năm | | Chi phí vận hành | Aurora tự sao lưu, vá lỗi, mở rộng |

Và DMS miễn phí cho việc di chuyển sang Aurora — chỉ trả tiền cho replication instance.

Và một lời khuyên về kiểm thử: hãy chạy song song hệ thống cũ và mới trong vài tuần, gửi cùng lưu lượng vào cả hai và so kết quả. Với Babelfish, khác biệt về cú pháp thường không gây lỗi rõ ràng mà cho kết quả hơi khác — ví dụ cách sắp xếp chuỗi hoặc làm tròn số — và đó là loại lỗi chỉ so sánh mới phát hiện được.

Đáp án

A — Ở Region B tồn tại 1 EC2 instance, 1 AMI và 1 snapshot.

Vì sao đúng

Điểm mấu chốt: sao chép AMI sang Region khác cũng SAO CHÉP LUÔN snapshot nền của nó.

Lần theo từng bước trong đề:

Region A:
    ① Tạo instance 1A
    ② Chụp snapshot của 1A          → 1 snapshot ở A
    ③ Tạo AMI từ snapshot đó        → 1 AMI ở A
    ④ Sao chép AMI sang Region B    → ???

Region B:
    → AMI được sao chép             → 1 AMI ở B
    → snapshot nền TỰ ĐỘNG được sao chép → 1 snapshot ở B
    ⑤ Tạo instance 1B từ AMI đó     → 1 instance ở B
        ↓
    Tổng ở Region B: 1 instance + 1 AMI + 1 snapshot

Vì sao snapshot bắt buộc phải đi cùng:

AMI KHÔNG chứa dữ liệu — nó chỉ là BẢN KÊ (manifest):
    ✓ trỏ tới snapshot chứa nội dung ổ đĩa thật
    ✓ kèm metadata: kiến trúc, kernel, ánh xạ thiết bị khối
        ↓
    Snapshot nằm ở Region A thì AMI ở Region B không dùng được
    → snapshot và AMI đều có phạm vi REGION
    → nên sao chép AMI kéo theo sao chép snapshot

Và có thể kiểm chứng bằng lệnh:

aws ec2 copy-image --source-region us-east-1   --source-image-id ami-0abc123 --region eu-west-1 --name "ban-sao-ami"

# Sau đó ở Region B:
aws ec2 describe-snapshots --owner-ids self --region eu-west-1
# → thấy snapshot mới được tạo tự động

Đây cũng là điểm về chi phí hay bị bỏ sót: bạn trả tiền lưu trữ snapshot ở cả hai Region.

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

• **D. 1 instance và 1 AMI ở Region B — đây là phương án gần nhất và là bẫy chính của câu hỏi: nó đúng về instance và AMI nhưng quên snapshot. Người trả lời thường nghĩ AMI là một thực thể tự chứa, trong khi nó chỉ là bản kê trỏ tới snapshot.
• **C. 1 instance và 2 AMI — sai số lượng AMI: chỉ một AMI được sao chép sang B. AMI gốc vẫn ở Region A.
• **B. 1 instance và 1 snapshot — quên AMI: AMI được sao chép sang B và tồn tại ở đó như một tài nguyên riêng.

Ghi nhớ

Phạm vi của các tài nguyên EC2 — bảng cần thuộc: | Tài nguyên | Phạm vi | |---|---| | AMI | REGION | | Snapshot EBS | REGION | | EBS volume | AVAILABILITY ZONE | | Instance | AVAILABILITY ZONE | | Security group | VPC (nên là Region) | | Key pair | Region | | Elastic IP | Region | | IAM (user, role, policy) | TOÀN CẦU | | S3 bucket | tên toàn cầu, dữ liệu ở Region | | Route 53, CloudFront, WAF (cho CloudFront) | toàn cầu |

Bảng này là nội dung được hỏi rất thường xuyên.

Quan hệ giữa AMI, snapshot và volume:

Instance đang chạy
    │
    ├── EBS volume (trong một AZ)
    │       ↓ chụp
    │   Snapshot (phạm vi Region, lưu trong S3 do AWS quản lý)
    │       ↓ đăng ký
    └── AMI (bản kê trỏ tới snapshot)
            ↓ khởi động
        Instance mới với volume mới tạo từ snapshot

Ba đặc điểm của snapshot EBS: | Đặc điểm | Chi tiết | |---|---| | Tăng dần (incremental) | chỉ lưu khối ĐÃ THAY ĐỔI so với snapshot trước | | Lưu trong S3 do AWS quản lý | không thấy trong bucket của bạn | | Sao chép xuyên Region và xuyên tài khoản được | |

Tính tăng dần có hệ quả quan trọng:

Xoá một snapshot ở giữa chuỗi:
    → AWS TỰ giữ lại các khối mà snapshot sau còn cần
    → snapshot sau vẫn khôi phục được đầy đủ
        ↓
    → Xoá snapshot giữa chuỗi là AN TOÀN

Ba cách chia sẻ AMI: | Cách | Chi tiết | |---|---| | Riêng tư (mặc định) | chỉ chủ sở hữu | | Chia sẻ với tài khoản cụ thể | phải chia sẻ CẢ snapshot nền | | Công khai | mọi tài khoản AWS |

Dòng giữa là lỗi hay gặp:

# Chia sẻ AMI thôi là CHƯA ĐỦ
aws ec2 modify-image-attribute --image-id ami-0abc   --launch-permission "Add=[{UserId=444455556666}]"
# Phải chia sẻ cả snapshot
aws ec2 modify-snapshot-attribute --snapshot-id snap-0abc   --attribute createVolumePermission   --operation-type add --user-ids 444455556666

Thiếu bước thứ hai, tài khoản kia thấy AMI nhưng khởi động thất bại.

Ba lưu ý khi sao chép AMI xuyên Region: | Lưu ý | Chi tiết | |---|---| | AMI mới có ID KHÁC | tự động hoá phải tra lại id theo Region | | AMI mã hoá bằng KMS cần khoá ở Region ĐÍCH | khoá KMS có phạm vi Region | | Tốn phí truyền dữ liệu xuyên Region | với AMI lớn thì đáng kể |

Dòng giữa là nguồn lỗi phổ biến: khoá KMS ở us-east-1 không dùng được ở eu-west-1, phải khai --kms-key-id của Region đích khi sao chép.

Ba cách quản lý AMI ở quy mô lớn: | Cách | Chi tiết | |---|---| | EC2 Image Builder | tự dựng, kiểm thử và phân phối AMI theo lịch | | Data Lifecycle Manager | tự tạo và xoá snapshot theo chính sách | | SSM Parameter Store | lưu id AMI mới nhất theo tên chuẩn |

Cách cuối rất hữu ích cho tự động hoá:

aws ssm get-parameter --name /cong-ty/ami/web/moi-nhat --query Parameter.Value

Launch template trỏ vào parameter thay vì id cứng — cập nhật AMI chỉ cần đổi giá trị parameter.

Ba khoản chi phí liên quan: | Khoản | Chi tiết | |---|---| | Lưu trữ snapshot | ~0,05 USD/GB-tháng, ở MỖI Region | | Truyền dữ liệu khi sao chép | tính một lần | | AMI bản thân | miễn phí — chỉ snapshot mới tính tiền |

Và AMI cũ tích tụ là lãng phí phổ biến:

aws ec2 describe-images --owners self   --query 'Images[?CreationDate<`2025-01-01`].[ImageId,Name,CreationDate]'   --output table

Và một lời khuyên: hãy huỷ đăng ký AMI cũ VÀ xoá snapshot của chúng — huỷ đăng ký AMI không tự xoá snapshot, nên snapshot mồ côi nằm lại tính tiền vô thời hạn. Đây chính là hệ quả trực tiếp của việc AMI và snapshot là hai tài nguyên riêng biệt, đúng như câu hỏi này chỉ ra.

Đáp án

D — Tạo service account riêng cho UI và cho dịch vụ xử lý dữ liệu; dùng IAM Roles for Service Accounts (IRSA) ánh xạ mỗi service account tới một IAM role chỉ có quyền cần thiết.

Vì sao đúng

Đề yêu cầu đặc quyền tối thiểu ở mức POD — và IRSA là cơ chế duy nhất trong các phương án làm được điều đó.

Cách IRSA hoạt động:

Cụm EKS có OIDC identity provider
    ↓
Kubernetes service account được gắn annotation trỏ tới IAM role
    ↓
Pod dùng service account đó nhận TOKEN OIDC
    ↓ token được đổi lấy thông tin đăng nhập AWS qua STS
Pod có đúng quyền của IAM role đó — KHÔNG hơn

Cấu hình đầy đủ:

# ① Liên kết OIDC provider cho cụm
eksctl utils associate-iam-oidc-provider --cluster cum-san-xuat --approve

# ② Tạo service account gắn với IAM role
eksctl create iamserviceaccount --cluster cum-san-xuat   --name sa-giao-dien --namespace ung-dung   --attach-policy-arn arn:aws:iam::aws:policy/AmazonDynamoDBReadOnlyAccess --approve

eksctl create iamserviceaccount --cluster cum-san-xuat   --name sa-xu-ly-du-lieu --namespace ung-dung   --attach-policy-arn arn:aws:iam::123456789012:policy/chi-doc-ghi-s3 --approve

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-giao-dien
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/vai-tro-giao-dien
---
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      serviceAccountName: sa-giao-dien   # Pod này CHỈ truy cập được DynamoDB

Và kết quả đúng như đề yêu cầu:

Pod giao diện       → chỉ DynamoDB
Pod xử lý dữ liệu   → chỉ S3
    → không pod nào chạm được tài nguyên của pod kia

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

• **C. Gắn cả hai policy vào instance profile của EC2 worker node, dùng Kubernetes RBAC để phân quyền — đây là phương án gần nhất và là bẫy chính: RBAC của Kubernetes kiểm soát quyền trên API của Kubernetes (tạo pod, đọc secret), nó hoàn toàn không kiểm soát quyền AWS. Mọi pod trên node đó đều gọi được instance metadata và dùng cả hai quyền — đúng thứ mà đề muốn tránh.
• **B. Một service account DÙNG CHUNG với IAM role có cả AmazonS3FullAccess lẫn AmazonDynamoDBFullAccess — đi ngược hẳn yêu cầu: mọi pod có toàn quyền cả hai dịch vụ.
• **A. Gắn IAM policy trực tiếp vào Pod bằng annotation của Kubernetes — không có cơ chế như vậy: IAM policy gắn vào IAM role, và Pod liên kết với role qua service account, không phải qua annotation trực tiếp trên Pod.

Ghi nhớ

Ba cách cấp quyền AWS cho Pod trong EKS — bảng cần thuộc: | Cách | Mức chi tiết | Đánh giá | |---|---|---| | Instance profile của node | TOÀN BỘ node | ❌ mọi pod dùng chung quyền | | IRSA | từng service account | ✅ được khuyến nghị | | EKS Pod Identity | từng service account | ✅ mới hơn, đơn giản hơn IRSA |

EKS Pod Identity là lựa chọn mới đáng biết (ra mắt cuối 2023): | | IRSA | EKS Pod Identity | |---|---|---| | Cần OIDC provider | ✅ mỗi cụm một cái | ❌ | | Trust policy của role | phải sửa cho từng cụm | đơn giản, dùng lại được | | Dùng lại role giữa nhiều cụm | khó | ✅ dễ | | Cần add-on | không | ✅ Pod Identity Agent |

Với cụm mới, AWS khuyến nghị Pod Identity — nó bỏ được việc quản lý OIDC provider và trust policy phức tạp.

aws eks create-addon --cluster-name cum-san-xuat   --addon-name eks-pod-identity-agent

aws eks create-pod-identity-association --cluster-name cum-san-xuat   --namespace ung-dung --service-account sa-giao-dien   --role-arn arn:aws:iam::123456789012:role/vai-tro-giao-dien

Kubernetes RBAC và IAM — phân biệt rõ ràng: | | Kubernetes RBAC | IAM | |---|---|---| | Kiểm soát | API của Kubernetes | API của AWS | | Ví dụ | ai tạo được Pod, đọc được Secret | ai gọi được s3:GetObject | | Đối tượng | user, group, service account của K8s | IAM principal |

Hai hệ thống này ĐỘC LẬP — đây là điểm nhầm lẫn phổ biến nhất và chính là bẫy của phương án C.

Ba thành phần của trust policy trong IRSA:

{"Effect": "Allow",
 "Principal": {"Federated":
   "arn:aws:iam::123456789012:oidc-provider/oidc.eks.ap-northeast-1.amazonaws.com/id/ABC123"},
 "Action": "sts:AssumeRoleWithWebIdentity",
 "Condition": {"StringEquals": {
   "oidc.eks.ap-northeast-1.amazonaws.com/id/ABC123:sub":
     "system:serviceaccount:ung-dung:sa-giao-dien",
   "oidc.eks.ap-northeast-1.amazonaws.com/id/ABC123:aud": "sts.amazonaws.com"}}}

Điều kiện sub là thứ khoá role vào ĐÚNG service account — thiếu nó thì mọi pod trong cụm đảm nhận được role.

Ba biện pháp bảo mật bổ sung cho node: | Biện pháp | Chi tiết | |---|---| | Chặn Pod truy cập instance metadata | --http-put-response-hop-limit 1 | | Bắt buộc IMDSv2 | chống SSRF | | Gỡ quyền thừa khỏi node role | chỉ để lại quyền tối thiểu cho kubelet |

Chặn metadata là bước bắt buộc khi dùng IRSA:

aws ec2 modify-instance-metadata-options --instance-id i-0abc   --http-put-response-hop-limit 1 --http-tokens required

Không chặn:
    Pod vẫn gọi được 169.254.169.254
    → lấy được thông tin đăng nhập của NODE ROLE
    → vòng qua toàn bộ IRSA

Đây là lỗ hổng nghiêm trọng và rất hay bị bỏ qua.

Ba nguyên tắc đặc quyền tối thiểu trong EKS: | Nguyên tắc | Chi tiết | |---|---| | Mỗi dịch vụ một service account riêng | ← câu này | | Node role chỉ có quyền tối thiểu cho kubelet | | | Dùng namespace để cách ly | kèm NetworkPolicy |

Và NetworkPolicy bổ sung cách ly ở tầng mạng:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
spec:
  podSelector: {matchLabels: {app: xu-ly-du-lieu}}
  policyTypes: [Ingress]
  ingress:
  - from: [{podSelector: {matchLabels: {app: giao-dien}}}]

EKS hỗ trợ NetworkPolicy nguyên bản từ VPC CNI 1.14 — không cần cài Calico nữa.

Ba công cụ kiểm tra cấu hình EKS: | Công cụ | Việc | |---|---| | IAM Access Analyzer | tìm quyền quá rộng | | Amazon Inspector | quét lỗ hổng trong image | | GuardDuty EKS Protection | phát hiện hành vi bất thường |

Và một lời khuyên: hãy kiểm chứng bằng cách thử làm việc bị cấm. Vào pod giao diện và chạy aws s3 ls — nó phải trả về AccessDenied. Cấu hình IRSA sai thường không có lỗi rõ ràng lúc triển khai, và chỉ khi thử đúng cái mình muốn chặn thì mới biết ranh giới có thật hay không.

Đáp án

C — Tạo Route 53 Resolver OUTBOUND endpoint, định nghĩa forwarding rule chuyển truy vấn cho tên miền tại chỗ tới máy chủ DNS tại chỗ, và gắn rule đó với VPC.

Vì sao đúng

Đề mô tả hướng truy vấn rất rõ: ứng dụng TRONG VPC cần phân giải tên miền của hệ thống TẠI CHỖ.

Nguồn truy vấn: bên TRONG VPC
Đích phân giải: máy chủ DNS TẠI CHỖ
    ↓
    Truy vấn đi TỪ VPC RA NGOÀI
    → cần OUTBOUND endpoint

Hai loại endpoint của Route 53 Resolver — nhớ theo hướng: | Loại | Hướng | Dùng khi | |---|---|---| | Outbound | VPC → tại chỗ | tài nguyên trong VPC phân giải tên miền tại chỗ ← câu này | | Inbound | tại chỗ → VPC | máy tại chỗ phân giải tên miền của AWS |

Luồng hoạt động đầy đủ:

Pod hoặc EC2 trong VPC hỏi: he-thong-cu.noi-bo.congty.local
    ↓
Route 53 Resolver (địa chỉ VPC+2) nhận truy vấn
    ↓ khớp forwarding rule cho miền .noi-bo.congty.local
Outbound endpoint (ENI trong VPC)
    ↓ qua VPN site-to-site
Máy chủ DNS tại chỗ trả lời
    ↓
Ứng dụng nhận IP nội bộ

Cấu hình:

# ① Tạo outbound endpoint
aws route53resolver create-resolver-endpoint   --name ra-ngoai-toi-tai-cho --direction OUTBOUND   --security-group-ids sg-dns   --ip-addresses SubnetId=subnet-a SubnetId=subnet-b

# ② Tạo forwarding rule
aws route53resolver create-resolver-rule   --name chuyen-tiep-noi-bo --rule-type FORWARD   --domain-name noi-bo.congty.local   --resolver-endpoint-id rslvr-out-abc123   --target-ips Ip=10.0.100.10,Port=53 Ip=10.0.100.11,Port=53

# ③ Gắn rule với VPC
aws route53resolver associate-resolver-rule   --resolver-rule-id rslvr-rr-abc --vpc-id vpc-0abc123

Và vì sao đây là cách an toàn nhất: truy vấn đi qua VPN đã có sẵn, không phơi máy chủ DNS ra Internet, không sao chép dữ liệu DNS lên đám mây.

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

• **D. Cấu hình INBOUND endpoint và tạo forwarding rule, bật phân giải đệ quy trong VPC — đây là phương án gần nhất và là bẫy chính: inbound endpoint đúng là một nửa của giải pháp DNS lai, nhưng nó phục vụ hướng NGƯỢC LẠI — cho máy tại chỗ hỏi tên miền của AWS. Với hướng trong đề, nó không giúp gì.
• **A. Tạo private hosted zone cho tên miền tại chỗ và gắn với VPC — phải sao chép và duy trì thủ công: bạn sẽ phải tự tạo lại mọi bản ghi DNS của hệ thống cũ trong Route 53 và giữ chúng đồng bộ. Nguồn sự thật vẫn nằm ở máy chủ DNS tại chỗ, nên bản sao sẽ lệch.
• **B. Tạo "hybrid connectivity gateway" và gắn máy chủ DNS tại chỗ vào Route 53 làm authoritative zone — không có dịch vụ nào tên như vậy, và Route 53 không "gắn" máy chủ DNS bên ngoài làm authoritative theo cách đó.

Ghi nhớ

Hai hướng của DNS lai — bảng cần thuộc: | Nhu cầu | Endpoint | |---|---| | Tài nguyên AWS phân giải tên miền TẠI CHỖ | OUTBOUND ← câu này | | Máy TẠI CHỖ phân giải tên miền của AWS | INBOUND | | Cả hai chiều | cả hai endpoint |

Mẹo nhớ: đặt mình ở vị trí VPC — truy vấn đi RA thì outbound, đi VÀO thì inbound.

Ba thành phần của Route 53 Resolver: | Thành phần | Việc | |---|---| | Resolver mặc định (VPC+2) | có sẵn mọi VPC, phân giải tên miền công cộng và private hosted zone | | Inbound endpoint | ENI nhận truy vấn từ ngoài | | Outbound endpoint | ENI gửi truy vấn ra ngoài | | Resolver rule | quyết định miền nào chuyển đi đâu |

Địa chỉ VPC+2 là chi tiết đáng nhớ:

VPC CIDR 10.0.0.0/16 → Resolver ở 10.0.0.2
    → cũng truy cập được qua 169.254.169.253

Ba loại resolver rule: | Loại | Việc | |---|---| | FORWARD | chuyển truy vấn cho miền này tới IP chỉ định | | SYSTEM | NGOẠI LỆ — không chuyển tiếp miền con này | | RECURSIVE | dùng resolver mặc định |

Rule SYSTEM rất hữu ích cho ngoại lệ:

FORWARD:  congty.local        → máy chủ DNS tại chỗ
SYSTEM:   aws.congty.local    → dùng Route 53 (không chuyển đi)
    → rule CỤ THỂ HƠN thắng

Ba yêu cầu của outbound endpoint: | Yêu cầu | Chi tiết | |---|---| | Ít nhất 2 địa chỉ IP ở 2 AZ khác nhau | để chịu lỗi | | Security group cho phép cổng 53 (UDP và TCP) | ra máy chủ DNS tại chỗ | | Có đường mạng tới máy chủ đích | VPN hoặc Direct Connect |

Và nhớ mở CẢ UDP LẪN TCP cổng 53:

UDP 53: truy vấn thông thường
TCP 53: phản hồi lớn hơn 512 byte, chuyển vùng zone

Chỉ mở UDP là lỗi khiến truy vấn lớn thất bại một cách khó hiểu.

Ba tính năng khác của Route 53 Resolver: | Tính năng | Việc | |---|---| | Resolver Query Logging | ghi lại mọi truy vấn DNS từ VPC | | Resolver DNS Firewall | chặn truy vấn tới miền độc hại | | Rule chia sẻ qua AWS RAM | dùng chung giữa nhiều tài khoản |

DNS Firewall đáng bật cho môi trường y tế:

Chặn truy vấn tới:
    ✓ miền độc hại đã biết (danh sách do AWS quản lý)
    ✓ miền tự tạo trong danh sách chặn
        ↓
    Phát hiện và chặn DNS tunneling — kênh rò rỉ dữ liệu phổ biến

Và query logging phục vụ kiểm toán:

aws route53resolver create-resolver-query-log-config   --name nhat-ky-dns --destination-arn <arn-log-group-hoac-s3>

Với dữ liệu y tế, biết máy nào đã hỏi tên miền nào là thông tin điều tra rất giá trị.

Chia sẻ rule qua AWS RAM cho kiến trúc nhiều tài khoản:

Tài khoản mạng (networking):
    → tạo outbound endpoint và rule MỘT LẦN
    → chia sẻ rule qua RAM
        ↓
Các tài khoản ứng dụng chỉ cần gắn rule vào VPC của mình
    → không phải mỗi tài khoản một endpoint (mỗi endpoint đều tính phí)

Đây là mẫu chuẩn và tiết kiệm đáng kể — endpoint tính phí theo ENI mỗi giờ.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Endpoint | ~0,125 USD/giờ mỗi ENI — hai ENI là ~180 USD/tháng | | Truy vấn | theo triệu truy vấn | | Query logging | phí CloudWatch Logs hoặc S3 |

Và một lời khuyên: hãy dùng hai máy chủ DNS tại chỗ ở hai vị trí khác nhau làm target của forwarding rule. Nếu máy chủ DNS duy nhất ngừng hoạt động, mọi ứng dụng trong VPC mất khả năng phân giải tên miền nội bộ — và triệu chứng sẽ trông như lỗi ứng dụng chứ không giống lỗi DNS.

Đáp án

D — Bảng tính trên EFS truy cập được từ các Region khác thông qua kết nối VPC peering XUYÊN REGION.

Vì sao đúng

Điểm cần làm rõ: EFS là dịch vụ cấp Region, nhưng "cấp Region" không có nghĩa là "không truy cập được từ Region khác".

Hai khái niệm khác nhau:

"EFS là dịch vụ REGION"
    → file system TỒN TẠI trong một Region
    → mount target nằm trong các AZ của Region đó

KHÔNG có nghĩa là:
    → chỉ máy trong Region đó mới mount được

Thực tế: mount được từ bất cứ đâu có đường mạng tới mount target. | Nguồn | Cơ chế | |---|---| | EC2 trong cùng VPC | trực tiếp | | VPC khác cùng Region | VPC peering hoặc Transit Gateway | | VPC ở REGION KHÁC | inter-region VPC peering ← câu này | | Trung tâm dữ liệu tại chỗ | Direct Connect hoặc VPN |

Và inter-region VPC peering là tính năng có thật, hỗ trợ từ 2017:

aws ec2 create-vpc-peering-connection   --vpc-id vpc-my --peer-vpc-id vpc-chau-a   --peer-region ap-northeast-1

Sau đó cấu hình như peering thường:

① Chấp nhận yêu cầu peering ở Region kia
② Thêm route vào bảng định tuyến của cả hai bên
③ Mở cổng 2049 (NFS) trong security group của mount target
④ Mount từ EC2 ở Region kia

Và vì sao đây là cách ÍT CÔNG VẬN HÀNH NHẤT:

✓ MỘT bản duy nhất của bảng tính — không có xung đột phiên bản
✓ không cần đồng bộ hay sao chép
✓ không cần đổi định dạng dữ liệu
✓ mọi người sửa cùng một tệp

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

• **C. Phải sao chép EFS sang các Region khác vì EFS là dịch vụ Region và không cho phép truy cập từ Region khác — đây là phương án gần nhất và vế đầu (EFS là dịch vụ Region) đúng, nhưng kết luận sai: truy cập xuyên Region hoàn toàn làm được qua peering. Và nhiều bản sao nghĩa là xung đột nội dung — hai người sửa hai bản khác nhau thì không hợp nhất được.
• **A. Phải sao chép bảng tính lên S3 — thay đổi mô hình truy cập: S3 là kho object, không cho sửa tại chỗ. Mỗi lần lưu là tải lên object mới, và hai người lưu cùng lúc thì một bản ghi đè bản kia — mất dữ liệu âm thầm.
• **B. Phải đưa dữ liệu vào RDS MySQL — thay đổi lớn nhất và vô lý: chuyển một bảng tính thành lược đồ quan hệ đòi thiết kế bảng, viết ứng dụng truy cập, và người dùng mất hoàn toàn công cụ bảng tính quen thuộc.

Ghi nhớ

Phạm vi của các dịch vụ lưu trữ: | Dịch vụ | Phạm vi | Truy cập xuyên Region | |---|---|---| | EFS | Region | ✅ qua peering/TGW/VPN | | EBS | AZ | ❌ (phải snapshot rồi sao chép) | | S3 | Region (tên toàn cầu) | ✅ qua API công cộng | | FSx | Region | ✅ qua mạng |

Ba cách nối mạng xuyên Region: | Cách | Đặc điểm | |---|---| | Inter-region VPC peering | đơn giản, rẻ, KHÔNG bắc cầu | | Transit Gateway peering | nhiều VPC, định tuyến tập trung | | VPN hoặc Direct Connect | qua trung tâm dữ liệu |

Hạn chế "không bắc cầu" của peering rất quan trọng:

VPC-A ⟷ VPC-B (peering)
VPC-B ⟷ VPC-C (peering)
    → A KHÔNG nói chuyện được với C
    → cần thêm peering A ⟷ C
        ↓
    Với N VPC cần N×(N-1)/2 kết nối
    → 10 VPC = 45 kết nối → dùng Transit Gateway

Ba lưu ý khi mount EFS xuyên Region: | Lưu ý | Chi tiết | |---|---| | Độ trễ CAO hơn nhiều | Mỹ ↔ châu Á khoảng 150–200ms | | Tốn phí truyền dữ liệu xuyên Region | ~0,02 USD/GB | | CIDR của hai VPC không được chồng lấn | yêu cầu của peering |

Độ trễ là điều phải cân nhắc nghiêm túc:

NFS rất nhạy với độ trễ:
    → mỗi thao tác tệp là một vòng lượt mạng
    → mở một bảng tính có thể cần hàng trăm thao tác
        ↓
    Trải nghiệm từ châu Á tới file system ở Mỹ sẽ CHẬM ĐÁNG KỂ

Và có lựa chọn tốt hơn cho hợp tác toàn cầu về tài liệu: | Lựa chọn | Đặc điểm | |---|---| | Amazon WorkDocs (đã ngừng nhận khách mới) | chia sẻ tài liệu có phiên bản | | Dịch vụ bảng tính đám mây | hợp tác thời gian thực đúng nghĩa | | EFS + peering | ← đáp án của câu này | | S3 + versioning | lưu trữ, không hợp tác đồng thời |

Ba cách sao chép EFS nếu thật sự cần bản ở Region khác: | Cách | Đặc điểm | |---|---| | EFS Replication | tính năng dựng sẵn, RPO khoảng 15 phút, đích CHỈ ĐỌC | | AWS DataSync | đồng bộ theo lịch, hai chiều được | | Script với rsync | tự quản lý |

EFS Replication đáng biết:

aws efs create-replication-configuration --source-file-system-id fs-0abc   --destinations Region=ap-northeast-1

Nhưng đích là CHỈ ĐỌC — nên nó phục vụ khôi phục thảm hoạ, không phục vụ hợp tác sửa chung.

Ba yêu cầu mạng để mount EFS: | Yêu cầu | Chi tiết | |---|---| | Cổng 2049 (NFS) mở trong security group của mount target | | | Có route tới subnet chứa mount target | | | Cài amazon-efs-utils | để dùng -t efs với TLS và IAM |

sudo mount -t efs -o tls,iam fs-0abc123.efs.us-east-1.amazonaws.com:/ /du-lieu

Lưu ý: mount xuyên Region phải dùng tên DNS đầy đủ hoặc IP của mount target — tên rút gọn chỉ phân giải được trong cùng Region.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ EFS | ~0,30 USD/GB-tháng (Standard) | | Truyền dữ liệu xuyên Region | ~0,02 USD/GB | | Truyền chéo AZ trong Region | miễn phí với EFS |

Và lifecycle sang IA giảm mạnh chi phí:

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

Và một lời khuyên thực tế: với một bảng tính danh mục sản phẩm mà nhiều nhóm ở nhiều châu lục cùng sửa, EFS xuyên Region là câu trả lời đúng cho câu hỏi thi nhưng không phải công cụ đúng cho bài toán thật. NFS không có cơ chế hợp tác đồng thời — hai người mở cùng lúc thì người lưu sau ghi đè người lưu trước. Một dịch vụ tài liệu đám mây giải quyết vấn đề gốc tốt hơn nhiều.

Đáp án

A — Yêu cầu đối tác đặt Network Load Balancer trước instance RDS for MySQL, rồi dùng AWS PrivateLink phơi NLB đó ra dưới dạng interface VPC endpoint trong VPC của công ty nghiên cứu.

Vì sao đúng

Đề nêu ràng buộc rất chặt: VPC của công ty nghiên cứu không có Internet, không có Direct Connect, không có VPN.

Không Internet     → loại mọi giải pháp đi qua mạng công cộng
Không DX, không VPN → loại mọi giải pháp dựa trên kết nối lai
    ↓
    Cần kết nối RIÊNG TƯ giữa hai VPC ở hai TÀI KHOẢN khác nhau

Và PrivateLink là cơ chế được thiết kế đúng cho việc này:

Tài khoản ĐỐI TÁC                    Tài khoản NGHIÊN CỨU
   RDS MySQL                            Interface VPC endpoint
       ▲                                    │ (ENI có IP riêng trong VPC)
       │                                    │
   Network Load Balancer ◀── PrivateLink ───┘
       │
   VPC Endpoint Service

Ba bước triển khai:

# ① Bên đối tác: tạo NLB trỏ tới RDS
aws elbv2 create-target-group --name tg-mysql --protocol TCP --port 3306   --target-type ip --vpc-id vpc-doi-tac

# ② Bên đối tác: tạo endpoint service từ NLB
aws ec2 create-vpc-endpoint-service-configuration   --network-load-balancer-arns <arn-nlb> --no-acceptance-required

# ③ Bên nghiên cứu: tạo interface endpoint
aws ec2 create-vpc-endpoint --vpc-endpoint-type Interface   --service-name com.amazonaws.vpce.ap-northeast-1.vpce-svc-0abc123   --vpc-id vpc-nghien-cuu --subnet-ids subnet-a subnet-b   --security-group-ids sg-truy-cap-db

Bốn lợi ích khiến PrivateLink là lựa chọn đúng: | Lợi ích | Chi tiết | |---|---| | Lưu lượng KHÔNG rời mạng AWS | không qua Internet | | MỘT CHIỀU | đối tác không truy cập ngược vào VPC nghiên cứu | | CIDR có thể CHỒNG LẤN | khác với peering | | Chỉ phơi ĐÚNG một dịch vụ | không mở cả VPC |

Vế thứ hai là điểm mạnh về bảo mật: với peering, hai VPC nhìn thấy nhau; với PrivateLink, chỉ có một endpoint một chiều.

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

• **B. Thiết lập VPC peering giữa hai VPC, dùng Transit Gateway ở tài khoản đối tác, sửa route table của subnet RDS — đây là phương án gần nhất và peering thực sự cho kết nối riêng tư, nhưng nó kém an toàn và có ràng buộc kỹ thuật: peering mở đường hai chiều ở tầng mạng, và CIDR hai VPC không được chồng lấn — điều không kiểm soát được khi hai tổ chức độc lập. Phương án còn trộn lẫn peering và Transit Gateway một cách thừa thãi.
• **C. Bật public access cho RDS và mở security group theo dải IP của công ty; truy cập qua Internet bằng NAT Gateway — vi phạm cả yêu cầu lẫn nguyên tắc bảo mật: đề nói rõ VPC không có Internet, và phơi database y sinh ra Internet công cộng là điều không chấp nhận được.
• **D. Cấu hình Client VPN endpoint cho các nhà nghiên cứu, rồi Direct Connect gateway tới VPC đối tác — mâu thuẫn với đề bài: đề nêu rõ không có Direct Connect. Và Client VPN dành cho người dùng cá nhân kết nối vào, không giải quyết kết nối giữa hai VPC.

Ghi nhớ

Ba cách kết nối riêng tư giữa hai VPC — bảng cần thuộc: | Cách | Chiều | CIDR chồng lấn | Phơi ra | |---|---|---|---| | VPC peering | hai chiều | ❌ không được | cả VPC | | Transit Gateway | hai chiều | ❌ không được | cả VPC | | PrivateLink | MỘT CHIỀU | ✅ được | CHỈ một dịch vụ ← câu này |

Quy tắc chọn:

Phơi MỘT dịch vụ cho bên khác, giữ phần còn lại riêng tư → PrivateLink Nhiều tài nguyên cần nói chuyện hai chiều → peering hoặc TGW Nhiều VPC, cần định tuyến tập trung → Transit Gateway

Ba loại VPC endpoint: | Loại | Dịch vụ | Cơ chế | |---|---|---| | Gateway endpoint | CHỈ S3 và DynamoDB | route table, MIỄN PHÍ | | Interface endpoint (PrivateLink) | hầu hết dịch vụ AWS + dịch vụ của bên thứ ba | ENI có IP riêng, có phí | | Gateway Load Balancer endpoint | thiết bị bảo mật | chuyển hướng lưu lượng |

Gateway endpoint miễn phí — nên luôn tạo cho S3 và DynamoDB khi VPC không có Internet.

Ba yêu cầu của PrivateLink phía nhà cung cấp: | Yêu cầu | Chi tiết | |---|---| | Phải có Network Load Balancer | hoặc Gateway Load Balancer — KHÔNG dùng ALB được | | Tạo VPC Endpoint Service từ NLB | | | Cho phép principal của bên tiêu thụ | hoặc bật acceptance-required |

Ràng buộc "phải là NLB" là chi tiết hay bị hỏi — PrivateLink hoạt động ở tầng 4, nên ALB (tầng 7) không dùng được.

Và RDS không phải target trực tiếp của NLB được:

NLB target type = IP
    → trỏ tới địa chỉ IP hiện tại của RDS endpoint
        ↓
    ⚠ IP của RDS ĐỔI khi có failover
    → cần cơ chế cập nhật target
        (Lambda theo dõi sự kiện RDS, hoặc dùng RDS Proxy)

Đây là điểm vận hành quan trọng mà câu hỏi không nêu.

Ba tính năng bảo mật của PrivateLink: | Tính năng | Chi tiết | |---|---| | Endpoint policy | giới hạn hành động được thực hiện qua endpoint | | Security group trên endpoint ENI | kiểm soát ai trong VPC gọi được | | Danh sách principal được phép | chỉ tài khoản cụ thể tạo được endpoint |

aws ec2 modify-vpc-endpoint-service-permissions   --service-id vpce-svc-0abc123   --add-allowed-principals arn:aws:iam::111122223333:root

Ba lưu ý về chi phí PrivateLink: | Khoản | Chi tiết | |---|---| | Endpoint | ~0,01 USD/giờ mỗi ENI mỗi AZ | | Dữ liệu xử lý | ~0,01 USD/GB | | So với NAT Gateway | thường rẻ hơn cho lưu lượng lớn tới dịch vụ AWS |

Ba trường hợp dùng PrivateLink: | Trường hợp | Ví dụ | |---|---| | Truy cập dịch vụ AWS không qua Internet | S3, KMS, Secrets Manager | | SaaS của bên thứ ba | Snowflake, MongoDB Atlas, Datadog | | Chia sẻ dịch vụ giữa các tài khoản | ← câu này |

Ba lưu ý cho VPC hoàn toàn riêng tư: | Lưu ý | Chi tiết | |---|---| | Cần interface endpoint cho MỖI dịch vụ AWS dùng tới | SSM, ECR, CloudWatch Logs... | | Gateway endpoint cho S3 và DynamoDB là miễn phí | luôn tạo | | Bật PrivateDnsEnabled | tên miền chuẩn của dịch vụ tự trỏ vào endpoint |

PrivateDnsEnabled khiến mọi thứ trong suốt:

Không bật: phải sửa mã dùng endpoint DNS riêng
Có bật:   secretsmanager.ap-northeast-1.amazonaws.com
          tự phân giải thành IP riêng của endpoint
    → SDK và CLI hoạt động không cần đổi gì

Và một lời khuyên về vận hành: hãy yêu cầu đối tác đặt RDS Proxy giữa NLB và RDS thay vì trỏ NLB thẳng vào IP của database. Proxy có endpoint ổn định, xử lý failover trong suốt, và giải quyết đúng vấn đề IP thay đổi — thứ sẽ gây gián đoạn khó chẩn đoán nếu bỏ qua.

Đáp án

B — Cấu hình AWS WAF trên Application Load Balancer.

Vì sao đúng

Đề yêu cầu chặn truy cập theo QUỐC GIA — và AWS WAF là dịch vụ duy nhất trong các phương án làm được điều đó trên ALB.

AWS WAF có quy tắc khớp theo địa lý:

{"Name": "chi-cho-phep-viet-nam",
 "Priority": 0,
 "Action": {"Block": {}},
 "Statement": {
   "NotStatement": {"Statement": {
     "GeoMatchStatement": {"CountryCodes": ["VN"]}}}},
 "VisibilityConfig": {"SampledRequestsEnabled": true,
   "CloudWatchMetricsEnabled": true, "MetricName": "chan-ngoai-nuoc"}}

Quy tắc này chặn mọi request KHÔNG đến từ Việt Nam — đúng yêu cầu "chỉ cho phép nước sở tại".

Và WAF gắn trực tiếp vào ALB:

aws wafv2 associate-web-acl   --web-acl-arn <arn-web-acl>   --resource-arn <arn-application-load-balancer>

Vì sao phải là WAF chứ không phải security group: | | Security group | AWS WAF | |---|---|---| | Tầng | 3/4 — IP và cổng | 7 — nội dung HTTP | | Lọc theo quốc gia | ❌ | ✅ GeoMatch | | Lọc theo IP | ✅ nhưng phải liệt kê thủ công | ✅ IP set | | Quy tắc từ chối | ❌ chỉ có Allow | ✅ Allow và Block |

Dòng cuối là hạn chế căn bản của security group: nó chỉ có quy tắc cho phép, không diễn đạt được "chặn hai nước này".

Và WAF dùng cơ sở dữ liệu định vị IP được cập nhật liên tục — bạn không phải tự duy trì danh sách dải IP của từng quốc gia, thứ thay đổi hằng ngày và có hàng chục nghìn mục.

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

• **D. Dùng Geo Restriction của CloudFront — đây là phương án gần nhất và CloudFront thực sự có tính năng chặn theo quốc gia, nhưng nó không áp dụng được cho kiến trúc trong đề: hệ thống hiện tại là EC2 sau ALB, không có CloudFront. Thêm CloudFront là thay đổi kiến trúc, và cụm "trong một Amazon VPC" trong phương án cũng sai — CloudFront là dịch vụ biên toàn cầu, không nằm trong VPC.
• **A. Cấu hình security group của EC2 instance — không lọc được theo quốc gia, và với ALB thì security group của EC2 chỉ thấy IP của ALB chứ không thấy IP của người dùng.
• **C. Cấu hình security group trên ALB — cùng hạn chế: security group chỉ khớp CIDR, không có khái niệm quốc gia, và không có quy tắc từ chối.

Ghi nhớ

Ba cách chặn theo địa lý trên AWS: | Cách | Gắn vào | Đặc điểm | |---|---|---| | AWS WAF GeoMatch | ALB, CloudFront, API Gateway, AppSync, Cognito | linh hoạt nhất, kết hợp được với quy tắc khác | | CloudFront Geo Restriction | chỉ CloudFront | đơn giản, miễn phí | | Route 53 geolocation routing | DNS | KHÔNG phải cơ chế chặn — chỉ định tuyến |

Dòng cuối quan trọng: định tuyến theo địa lý của Route 53 gửi người dùng tới endpoint khác nhau, nhưng ai biết IP thật vẫn truy cập thẳng được.

Các tài nguyên mà WAF gắn được: | Tài nguyên | Hỗ trợ | |---|---| | CloudFront distribution | ✅ (Web ACL phải ở us-east-1) | | Application Load Balancer | ✅ ← câu này | | API Gateway REST API | ✅ | | AppSync GraphQL API | ✅ | | Cognito user pool | ✅ | | Network Load Balancer | ❌ — NLB ở tầng 4 |

Dòng cuối là chi tiết hay bị hỏi.

Sáu loại statement của WAF: | Statement | Khớp theo | |---|---| | GeoMatchStatement | quốc gia ← câu này | | IPSetReferenceStatement | danh sách IP hoặc CIDR | | RateBasedStatement | số request từ một IP trong 5 phút | | ByteMatchStatement | chuỗi trong header, URI, body | | SqliMatchStatement / XssMatchStatement | tấn công SQL injection và XSS | | LabelMatchStatement | nhãn do quy tắc khác gắn |

Và Managed Rule Groups tiết kiệm rất nhiều công: | Nhóm quy tắc | Bảo vệ khỏi | |---|---| | AWSManagedRulesCommonRuleSet | OWASP Top 10 cơ bản | | AWSManagedRulesKnownBadInputsRuleSet | payload tấn công đã biết | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu | | AWSManagedRulesBotControlRuleSet | bot (tính phí thêm) |

Ba lưu ý về chặn theo địa lý: | Lưu ý | Chi tiết | |---|---| | VPN và proxy vòng qua được | không phải cơ chế tuân thủ tuyệt đối | | Độ chính xác của định vị IP không hoàn hảo | có sai số, nhất là với mạng di động | | Người dùng hợp lệ đi công tác bị chặn | cần cơ chế ngoại lệ |

Dòng đầu quan trọng khi báo cáo với bộ phận pháp chế: chặn theo địa lý là biện pháp hợp lý và được chấp nhận rộng rãi, nhưng không phải rào cản tuyệt đối.

Và nên có danh sách IP ngoại lệ ưu tiên cao hơn:

Priority 0: cho phép IP trong danh sách trắng (văn phòng, đối tác)
Priority 1: chặn mọi quốc gia ngoài VN

Thứ tự priority quyết định — số nhỏ hơn được xét trước.

Ba chế độ hành động của WAF: | Hành động | Chi tiết | |---|---| | Block | trả về 403 (tuỳ chỉnh được nội dung) | | Allow | cho qua | | Count | chỉ ĐẾM, không chặn — dùng để thử nghiệm |

Luôn triển khai ở chế độ Count trước:

Bật Count trong vài ngày
    → xem metric: bao nhiêu request sẽ bị chặn
    → kiểm tra sampled request xem có người dùng thật không
    → rồi mới chuyển sang Block

Bỏ qua bước này là cách nhanh nhất để chặn nhầm khách hàng thật.

Ba công cụ giám sát WAF: | Công cụ | Việc | |---|---| | CloudWatch metric | số request bị chặn theo quy tắc | | Sampled requests | xem mẫu request thật đã khớp quy tắc | | WAF logging | ghi đầy đủ ra S3, Kinesis Firehose hoặc CloudWatch Logs |

Ba lưu ý về chi phí WAF: | Khoản | Giá tham khảo | |---|---| | Web ACL | ~5 USD/tháng | | Mỗi quy tắc | ~1 USD/tháng | | Mỗi triệu request | ~0,60 USD | | Managed rule group cao cấp | thêm phí |

Và một lời khuyên: hãy ghi log WAF ra S3 và giữ lại. Khi cơ quan quản lý hỏi "các anh đã chặn từ ngày nào và hiệu quả ra sao", log là bằng chứng duy nhất — và với yêu cầu đến từ quy định của chính phủ như trong đề, khả năng chứng minh quan trọng ngang với việc chặn.

Đáp án

D — Dùng EC2 instance có Instance Store.

Vì sao đúng

Đề nêu ba đặc điểm, và chúng dẫn thẳng tới instance store: | Đặc điểm trong đề | Kết luận | |---|---| | Cần hiệu năng I/O NGẪU NHIÊN cao | instance store NVMe cho IOPS cao nhất | | Dữ liệu do CHÍNH ỨNG DỤNG sao chép giữa các máy | không cần lưu trữ bền vững ở tầng hạ tầng | | Máy hỏng thì ứng dụng tự lo máy thay thế có dữ liệu | mất dữ liệu cục bộ không phải vấn đề |

Vì sao instance store nhanh nhất:

Instance store = đĩa NVMe VẬT LÝ gắn trực tiếp trên máy chủ
    → KHÔNG đi qua mạng
    → độ trễ micro giây
    → hàng triệu IOPS trên các loại instance i3, i4i, im4gn

EBS = lưu trữ qua MẠNG
    → mỗi thao tác I/O là một vòng lượt mạng
    → độ trễ mili giây một chữ số
    → tối đa 64.000 IOPS (io2), 256.000 (io2 Block Express)

Bảng so sánh IOPS thực tế: | Lưu trữ | IOPS ngẫu nhiên | |---|---| | Instance store NVMe (i4i.32xlarge) | ~3.000.000 | | io2 Block Express | ~256.000 | | gp3 | ~16.000 | | EFS | phụ thuộc chế độ, thấp hơn nhiều |

Và về chi phí — instance store là MIỄN PHÍ:

Instance store đã tính trong giá instance
    → KHÔNG có phí lưu trữ riêng
    → so với io2 với IOPS cấp phát cao thì tiết kiệm rất lớn

Đây là lý do nó là phương án "tối ưu chi phí và tài nguyên nhất" như đề hỏi.

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

• **B. Dùng instance dựa trên Amazon EBS — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó kém hơn ở cả hai tiêu chí: EBS đi qua mạng nên độ trễ cao hơn và IOPS thấp hơn nhiều, và bạn phải trả tiền cho khả năng bền vững mà đề nói rõ là không cần — ứng dụng đã tự sao chép dữ liệu rồi.
• **C. Dùng instance với EFS mount point — chậm nhất cho I/O ngẫu nhiên: EFS là NFS qua mạng, mỗi thao tác tệp là một vòng lượt. Nó tối ưu cho chia sẻ tệp giữa nhiều máy, không cho I/O ngẫu nhiên hiệu năng cao.
• **A. Dùng instance truy cập S3 — sai mô hình truy cập: S3 là kho object qua HTTP, không phải thiết bị khối. Không mount làm hệ thống tệp hiệu năng cao được, và mỗi thao tác là một lời gọi API.

Ghi nhớ

Instance store và EBS — bảng phân biệt cốt lõi: | | Instance store | EBS | |---|---|---| | Vị trí | đĩa VẬT LÝ trên máy chủ | qua mạng | | Hiệu năng | cao nhất, micro giây | rất tốt, mili giây | | Tồn tại qua STOP | ❌ MẤT | ✅ | | Tồn tại qua TERMINATE | ❌ | ✅ (nếu DeleteOnTermination=false) | | Tồn tại qua REBOOT | ✅ vẫn còn | ✅ | | Snapshot | ❌ | ✅ | | Đổi kích thước | ❌ cố định theo loại instance | ✅ | | Chi phí | miễn phí (trong giá instance) | tính theo GB cấp phát |

Dòng "reboot" hay bị nhớ nhầm: khởi động lại không mất dữ liệu instance store; chỉ stop và terminate mới mất.

Ba trường hợp dùng instance store: | Trường hợp | Lý do | |---|---| | Bộ đệm và dữ liệu tạm | mất thì tạo lại | | Ứng dụng TỰ sao chép dữ liệu | Cassandra, Elasticsearch, Hadoop HDFS ← câu này | | Vùng làm việc tạm cho xử lý dữ liệu | sắp xếp, ghép nối |

Nhóm giữa rất quan trọng: các database phân tán vốn giữ nhiều bản sao trên nhiều node, nên độ bền của từng ổ đĩa là dư thừa.

Các họ instance có NVMe instance store: | Họ | Tối ưu cho | |---|---| | i3, i3en, i4i, i7i | I/O chuyên sâu — NoSQL, kho dữ liệu | | im4gn, is4gen | I/O chuyên sâu, chip Graviton | | d3, d3en | dung lượng HDD lớn | | Nhiều họ đa dụng (m5d, c5d, r5d) | có thêm NVMe cục bộ |

Hậu tố d nghĩa là có instance store — m5.large không có, m5d.large có.

Ba lưu ý khi dùng instance store: | Lưu ý | Chi tiết | |---|---| | Phải TỰ format và mount sau khi khởi động | không có sẵn hệ thống tệp | | Thêm vào cloud-init hoặc user data | tự động hoá | | Không đưa vào /etc/fstab mà không có nofail | máy sẽ không khởi động được sau khi stop/start |

#!/bin/bash
mkfs.xfs /dev/nvme1n1
mkdir -p /du-lieu
mount /dev/nvme1n1 /du-lieu
echo "/dev/nvme1n1 /du-lieu xfs defaults,nofail 0 2" >> /etc/fstab

Tuỳ chọn nofail là bắt buộc — sau khi stop/start, instance store là ổ mới trắng và tên thiết bị có thể đổi.

Ba đặc điểm khác của instance store: | Đặc điểm | Chi tiết | |---|---| | Mã hoá tự động | trên các thế hệ mới, bằng khoá của phần cứng | | TRIM được hỗ trợ | duy trì hiệu năng theo thời gian | | Kích thước cố định theo loại instance | muốn nhiều hơn phải đổi loại máy |

Ba cách bù cho việc dữ liệu không bền: | Cách | Chi tiết | |---|---| | Ứng dụng tự sao chép | ← đúng tình huống trong đề | | Sao lưu định kỳ ra S3 | cho dữ liệu cần giữ | | Kết hợp: instance store cho nóng, EBS cho dữ liệu cần bền | |

Cách thứ ba là mẫu phổ biến:

Instance store: dữ liệu làm việc, index, cache
EBS root volume: hệ điều hành và cấu hình
S3: sao lưu và dữ liệu nguồn

Ba lưu ý khi thiết kế cụm tự sao chép: | Lưu ý | Chi tiết | |---|---| | Trải các node qua NHIỀU AZ | mất một AZ không mất mọi bản sao | | Đặt hệ số nhân bản đủ lớn | thường là 3 | | Tự động hoá việc thay node | ASG + script gia nhập cụm |

Và với instance store, "thay node" nghĩa là node mới phải NẠP LẠI dữ liệu từ các node khác — quá trình này tốn băng thông và thời gian, nên cần được tính vào thiết kế.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | IOPS và throughput của đĩa | qua CloudWatch agent | | Băng thông mạng khi nạp lại dữ liệu | có thể là nút thắt | | Số node khoẻ mạnh trong cụm | dưới hệ số nhân bản là báo động |

Và một lời khuyên: hãy thử chấm dứt một node trong môi trường thử nghiệm và đo xem cụm mất bao lâu để phục hồi đầy đủ số bản sao. Với instance store, đó là con số quyết định bạn chịu được mất bao nhiêu node cùng lúc — và nó thường lâu hơn nhiều so với dự đoán.