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

Đáp án

C — Gỡ access key khỏi AMI; tạo IAM role có quyền truy cập bảng DynamoDB và gán role đó cho các EC2 instance.

Vì sao đúng

Đề mô tả một trong những lỗi bảo mật nghiêm trọng nhất trên AWS: lưu access key dưới dạng văn bản thuần trong AMI.

Vì sao đây là lỗi nghiêm trọng:

Access key nằm trong AMI:
    ✗ AMI chia sẻ được → chia sẻ luôn khoá
    ✗ Ai vào được instance là đọc được khoá
    ✗ Khoá KHÔNG BAO GIỜ hết hạn
    ✗ Xoay vòng khoá đòi nướng lại AMI và thay toàn bộ instance
    ✗ Không biết khoá đã bị dùng ở đâu

IAM role giải quyết trọn vẹn:

Gán IAM role cho instance
    ↓
SDK và CLI tự lấy thông tin đăng nhập TẠM THỜI qua IMDS:
    http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>
    ↓
    → tự động làm mới trước khi hết hạn
    → KHÔNG có khoá nào lưu trên đĩa
    → đổi quyền = sửa policy, có hiệu lực NGAY

aws iam create-role --role-name vai-tro-ung-dung   --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{
    "Effect":"Allow","Principal":{"Service":"ec2.amazonaws.com"},
    "Action":"sts:AssumeRole"}]}'

aws ec2 associate-iam-instance-profile --instance-id i-0abc123   --iam-instance-profile Name=ho-so-ung-dung

Và policy nên theo quyền tối thiểu:

{"Effect": "Allow",
 "Action": ["dynamodb:GetItem", "dynamodb:PutItem",
            "dynamodb:UpdateItem", "dynamodb:Query"],
 "Resource": "arn:aws:dynamodb:ap-southeast-1:123456789012:table/bang-ung-dung"}

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

• **B. Đặt access key vào S3 bucket thay vì AMI — đây là phương án gần nhất vì cũng là di chuyển khoá đi chỗ khác, nhưng nó không giải quyết vấn đề gốc: khoá vẫn là thông tin đăng nhập dài hạn, và giờ lại nảy sinh câu hỏi mới — instance dùng khoá nào để đọc S3? Vòng luẩn quẩn.
• **A. Đặt access key vào Amazon Glacier — cùng vấn đề, và còn tệ hơn: Glacier mất vài giờ để lấy dữ liệu.
• **D. Không cần làm gì, kiến trúc đã an toàn — sai hoàn toàn: lưu thông tin đăng nhập dạng văn bản thuần trong AMI là một trong những cấu hình rủi ro nhất có thể có.

Ghi nhớ

Nguyên tắc cốt lõi: KHÔNG BAO GIỜ nhúng thông tin đăng nhập dài hạn vào mã, AMI, hay image container.

Cách cấp quyền đúng cho từng loại tài nguyên: | Tài nguyên | Cơ chế | |---|---| | EC2 instance | IAM role qua instance profile | | Lambda function | execution role | | ECS task | task role (không phải instance role) | | EKS pod | IRSA — IAM Roles for Service Accounts | | CI/CD ngoài AWS | OIDC federation (GitHub Actions, GitLab) | | Người dùng | IAM Identity Center với SSO |

Không trường hợp nào cần access key dài hạn.

Cách IAM role hoạt động trên EC2:

① Gán instance profile chứa IAM role
② SDK tự gọi IMDS lấy thông tin đăng nhập tạm thời
③ Thông tin đăng nhập có hiệu lực vài giờ
④ SDK tự làm mới trước khi hết hạn

Và phải bắt buộc dùng IMDSv2 để chống tấn công SSRF:

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

Với IMDSv1:
    lỗ hổng SSRF trong ứng dụng web
        → kẻ tấn công ép máy chủ gọi 169.254.169.254
        → LẤY ĐƯỢC thông tin đăng nhập của IAM role
        → đây là nguyên nhân của nhiều vụ rò rỉ dữ liệu lớn

Với IMDSv2:
    cần PUT lấy token trước → SSRF thông thường không làm được

Ba việc phải làm nếu phát hiện access key đã bị lộ: | Việc | Thứ tự | |---|---| | ① Vô hiệu hoá khoá NGAY | aws iam update-access-key --status Inactive | | ② Kiểm tra CloudTrail | xem khoá đã được dùng làm gì, từ IP nào | | ③ Xoá khoá và nướng lại AMI | và thay toàn bộ instance đang dùng |

Và với AMI đã chứa khoá, việc gỡ khoá là chưa đủ:

Khoá đã nằm trong mọi bản sao AMI
    → mọi snapshot của AMI đó
    → mọi instance đã khởi chạy từ nó
        ↓
    Phải VÔ HIỆU HOÁ và XOÁ chính access key đó ở IAM

Ba công cụ phát hiện thông tin đăng nhập bị lộ: | Công cụ | Việc | |---|---| | IAM Credential Report | liệt kê mọi khoá và tuổi của chúng | | AWS Config rule access-keys-rotated | phát hiện khoá quá hạn xoay vòng | | GuardDuty | phát hiện khoá bị dùng từ nơi bất thường |

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d

Và biện pháp phòng ngừa mạnh nhất: SCP chặn tạo access key.

{"Effect": "Deny",
 "Action": ["iam:CreateAccessKey"],
 "Resource": "*"}

Không tạo được khoá thì không có gì để rò rỉ — với tổ chức đã chuyển hẳn sang IAM role và Identity Center, đây là cấu hình hợp lý.

Ba lưu ý khi dùng IAM role trên EC2: | Lưu ý | Chi tiết | |---|---| | Instance profile là vỏ bọc của role | gán instance profile, không gán role trực tiếp | | Đổi policy có hiệu lực gần như ngay | không cần khởi động lại instance | | Một instance chỉ gắn được MỘT role | cần nhiều quyền thì gộp vào một policy |

Và với ứng dụng chạy trên nhiều instance chia sẻ AMI, hãy dùng ABAC:

{"Effect": "Allow", "Action": "dynamodb:*",
 "Resource": "*",
 "Condition": {"StringEquals":
   {"aws:ResourceTag/MoiTruong": "${aws:PrincipalTag/MoiTruong}"}}}

Một role, một policy, áp đúng phạm vi cho từng môi trường — nhờ thẻ.

Và một lời khuyên vận hành: hãy chạy IAM Access Analyzer để sinh policy từ hoạt động thực tế trong CloudTrail. Thay vì đoán ứng dụng cần quyền gì, bạn cấp rộng trong môi trường thử, đo xem nó thật sự dùng gì, rồi sinh policy khớp chính xác — quyền tối thiểu dựa trên dữ liệu chứ không phải phỏng đoán.

Đáp án

A — Storage Optimized Instances.

Vì sao đúng

Đề nêu ba đặc điểm workload, và cả ba đều chỉ tới họ instance tối ưu lưu trữ: | Đặc điểm | Kết luận | |---|---| | Đọc ghi TUẦN TỰ (sequential) | họ D hoặc H — tối ưu thông lượng | | Tần suất truy cập CAO | cần IOPS và băng thông lớn | | Tập dữ liệu RẤT LỚN trên LƯU TRỮ CỤC BỘ | instance store gắn trực tiếp |

Vì sao lưu trữ cục bộ nhanh hơn EBS:

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

Instance store (lưu trữ cục bộ):
    Instance → đĩa gắn TRỰC TIẾP vào máy chủ vật lý
        → không qua mạng
        → thông lượng và IOPS cao hơn hẳn

Và họ Storage Optimized chia làm hai nhánh: | Nhánh | Đĩa | Tối ưu cho | |---|---|---| | I3, I4i, Im4gn, I7i | NVMe SSD | IOPS cao — NoSQL, cache, tìm kiếm | | D2, D3, D3en, H1 | HDD dung lượng rất lớn | THÔNG LƯỢNG TUẦN TỰ — MapReduce, kho dữ liệu |

Đề nói "sequential read and write access to VERY LARGE data sets" → nhánh HDD (họ D) là lựa chọn khớp nhất, dù cả hai nhánh đều thuộc Storage Optimized.

Con số cụ thể của họ D3en:

Tới 336 TB dung lượng HDD cục bộ
Tới 6,2 GB/giây thông lượng đọc tuần tự

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

• **D. General Purpose Instances — đây là phương án gần nhất vì cũng dùng được cho nhiều việc, nhưng nó cân bằng giữa CPU, bộ nhớ và mạng mà không tối ưu cho I/O. Với tập dữ liệu rất lớn cần thông lượng cao, nó sẽ là nút thắt cổ chai.
• **C. Compute Optimized Instances — tối ưu cho CPU: họ C phục vụ mã hoá, xử lý theo lô nặng tính toán, máy chủ game. Chúng không có dung lượng lưu trữ cục bộ lớn.
• **B. Memory Optimized Instances — tối ưu cho RAM: họ R, X, z phục vụ in-memory database, phân tích dữ liệu lớn trong bộ nhớ. Không phải cho I/O tuần tự.

Ghi nhớ

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

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

"sequential read/write", "very large data sets", "local storage", "high IOPS" → Storage Optimized "in-memory", "large RAM", "SAP HANA" → Memory Optimized "CPU-intensive", "batch processing", "encoding" → Compute Optimized "machine learning training", "GPU" → Accelerated Computing

Hai nhánh của Storage Optimized — chọn đúng: | | Họ I (NVMe SSD) | Họ D và H (HDD) | |---|---|---| | Tối ưu | IOPS — truy cập NGẪU NHIÊN | THÔNG LƯỢNG — truy cập TUẦN TỰ | | Dung lượng | vài TB tới vài chục TB | tới 336 TB | | Workload | NoSQL, cache, OLTP | MapReduce, kho dữ liệu, log |

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 | rất tốt (io2 tới 256.000 IOPS) | | Bền vững qua stop/terminate | ❌ MẤT | ✅ | | Snapshot | ❌ | ✅ | | Chi phí | bao gồm trong giá instance | tính riêng |

Điều kiện để dùng instance store an toàn: | Điều kiện | Chi tiết | |---|---| | Dữ liệu TÁI TẠO ĐƯỢC | hoặc đã sao chép ở tầng ứng dụng | | Cụm tự sao chép | Cassandra, Elasticsearch, Kafka, HDFS | | Dữ liệu tạm hoặc cache | mất cũng không sao |

Và bảng hành vi dữ liệu instance store: | Thao tác | Dữ liệu | |---|---| | Reboot | GIỮ | | Stop/Start | MẤT | | Terminate | MẤT | | Lỗi phần cứng nền | MẤT |

Ba chi tiết vận hành với instance store NVMe: | Chi tiết | Xử lý | |---|---| | Phải ĐỊNH DẠNG và MOUNT thủ công | đưa lệnh vào user data | | Mất dữ liệu sau mỗi lần stop/start | user data phải xử lý được đĩa trống | | Kiểm tra bằng lsblk | xem thiết bị nào có sẵn |

sudo mkfs -t xfs /dev/nvme1n1
sudo mkdir -p /du-lieu && sudo mount /dev/nvme1n1 /du-lieu

Ba lựa chọn thay thế cho thông lượng cao: | Lựa chọn | Phù hợp | |---|---| | Instance store | thông lượng cao nhất, dữ liệu tái tạo được ← câu này | | EBS st1 (HDD tối ưu thông lượng) | dữ liệu phải bền vững, truy cập tuần tự | | FSx for Lustre | nhiều máy cùng đọc, hàng trăm GB/giây |

FSx for Lustre đáng cân nhắc khi nhiều instance cùng xử lý một tập dữ liệu — nó liên kết trực tiếp với S3 và cho thông lượng vượt xa đĩa cục bộ của một máy.

Và với EBS, nhớ hai loại HDD: | Loại | Tối ưu | |---|---| | st1 (Throughput Optimized HDD) | thông lượng tuần tự, tới 500 MB/giây | | sc1 (Cold HDD) | rẻ nhất, truy cập rất thưa |

Cả hai đều KHÔNG dùng làm root volume được và rất kém cho truy cập ngẫu nhiên.

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

Đáp án

A — Các lần gọi thất bại đã chạy quá 15 phút và chạm thời gian thực thi tối đa.

Vì sao đúng

Đề cho một con số quyết định: hàm chạy trung bình 15 PHÚT — đúng bằng giới hạn tối đa của Lambda.

Và "trung bình" nghĩa là có những lần chạy LÂU HƠN:

Trung bình 15 phút
    → có lần 12 phút, có lần 14 phút
    → và có lần VƯỢT 15 phút
        ↓
    Lambda CHẤM DỨT hàm khi chạm timeout
    → xử lý dở dang → dữ liệu không nhất quán

Đó chính xác là triệu chứng mà đề mô tả:

"Most invocations were successfully processed"  → phần lớn dưới 15 phút
"a few terminated invocations"                  → số ít vượt quá
"caused data discrepancy"                       → xử lý dở dang

Và 15 phút là giới hạn CỨNG, không tăng được:

aws lambda update-function-configuration   --function-name xu-ly-du-lieu --timeout 900
# 900 giây = 15 phút — giá trị TỐI ĐA

Ba cách khắc phục: | Cách | Chi tiết | |---|---| | Chia nhỏ công việc | Step Functions điều phối nhiều Lambda ngắn | | Chuyển sang Fargate hoặc AWS Batch | không giới hạn thời gian chạy | | Tối ưu hàm | tăng bộ nhớ để có nhiều CPU hơn, xử lý song song |

Và cách thứ ba đáng thử trước:

Lambda cấp CPU TỶ LỆ THUẬN với bộ nhớ
    → tăng từ 1 GB lên 4 GB có thể rút thời gian chạy xuống một nửa
    → đôi khi còn RẺ HƠN vì tính phí theo GB-giây

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

• **B. Đã chạm giới hạn số lần gọi đồng thời — đây là phương án gần nhất vì cũng gây thất bại, nhưng triệu chứng khác hẳn: chạm giới hạn đồng thời gây lỗi TooManyRequestsException (mã 429) và hàm KHÔNG BAO GIỜ BẮT ĐẦU CHẠY. Đề nói các lần gọi bị CHẤM DỨT — tức là đã chạy rồi mới bị cắt.
• **C. Hàm chứa mã đệ quy và chạy quá 15 phút — đệ quy gây triệu chứng khác: nó tạo ra số lần gọi tăng vọt và hoá đơn tăng đột biến, không phải "một vài lần bị chấm dứt". Và AWS hiện có cơ chế phát hiện đệ quy tự động dừng hàm.
• **D. Lần gọi thất bại chứa lỗi ServiceException (lỗi nội bộ của AWS) — rất hiếm và không khớp mẫu: lỗi nội bộ xảy ra ngẫu nhiên, không tương quan với thời gian chạy. Và đề mô tả một mẫu rõ ràng liên quan tới thời lượng.

Ghi nhớ

Giới hạn của AWS Lambda — bảng cần thuộc: | Giới hạn | Giá trị | |---|---| | Thời gian thực thi tối đa | 15 phút (900 giây) — KHÔNG tăng được | | Bộ nhớ | 128 MB – 10.240 MB | | Lưu trữ tạm /tmp | 512 MB – 10.240 MB | | Kích thước gói zip | 50 MB nén / 250 MB giải nén | | Container image | 10 GB | | Payload đồng bộ | 6 MB | | Payload bất đồng bộ | 256 KB | | Mức đồng thời mặc định | 1.000 (tăng được) |

Ba lỗi phổ biến của Lambda và cách phân biệt: | Lỗi | Triệu chứng | |---|---| | Timeout | "Task timed out after X seconds" trong log | | TooManyRequestsException (429) | hàm KHÔNG chạy — bị chặn ngay | | Out of memory | "Runtime exited with error: signal: killed" |

Cách phát hiện timeout qua CloudWatch:

fields @timestamp, @message
| filter @message like /Task timed out/
| stats count() by bin(1h)

Và metric Duration cho biết hàm đang tiến gần giới hạn:

aws cloudwatch put-metric-alarm --alarm-name lambda-sap-timeout   --metric-name Duration --namespace AWS/Lambda   --statistic Maximum --period 300 --threshold 840000   --comparison-operator GreaterThanThreshold   --dimensions Name=FunctionName,Value=xu-ly-du-lieu

840.000 mili giây = 14 phút — cảnh báo trước khi chạm trần.

Chọn dịch vụ compute theo thời gian chạy: | Thời gian | Dịch vụ | |---|---| | Dưới 15 phút | Lambda | | Không giới hạn, chạy theo lô | AWS Batch | | Không giới hạn, dịch vụ thường trực | Fargate hoặc ECS/EKS | | Nhiều bước phối hợp | Step Functions điều phối các bước |

Và Step Functions là cách giữ được Lambda mà vẫn xử lý được việc dài:

Chia công việc 20 phút thành 4 bước 5 phút
    → Step Functions gọi tuần tự
    → mỗi bước là một Lambda riêng
    → tổng thời gian workflow: tới MỘT NĂM

Và Step Functions còn cho retry, error handling, và trạng thái hiển thị được.

Ba nguyên nhân khiến hàm chạy lâu bất thường: | Nguyên nhân | Cách kiểm tra | |---|---| | Dữ liệu đầu vào lớn bất thường | log kích thước đầu vào | | Dịch vụ phụ thuộc chậm | dùng X-Ray để truy vết | | Thiếu bộ nhớ → CPU ít → chậm | thử tăng bộ nhớ lên gấp đôi |

Và AWS Lambda Power Tuning là công cụ tìm cấu hình bộ nhớ tối ưu:

Chạy hàm ở nhiều mức bộ nhớ
    → vẽ biểu đồ chi phí và thời gian
    → thường tìm ra điểm vừa NHANH HƠN vừa RẺ HƠN

Ba biện pháp phòng ngừa lỗi mất dữ liệu: | Biện pháp | Chi tiết | |---|---| | Làm hàm IDEMPOTENT | chạy lại không gây tác dụng phụ | | Dùng dead-letter queue | bắt các lần gọi thất bại | | Checkpoint tiến độ | ghi vào DynamoDB để lần chạy sau tiếp tục được |

Cấu hình DLQ và destination:

aws lambda update-function-configuration --function-name xu-ly-du-lieu   --dead-letter-config TargetArn=arn:aws:sqs:...:dlq-xu-ly

aws lambda put-function-event-invoke-config --function-name xu-ly-du-lieu   --maximum-retry-attempts 2   --destination-config '{"OnFailure":{"Destination":"arn:aws:sqs:...:that-bai"}}'

Và một lời khuyên cho tình huống của đề: hàm chạy trung bình đúng 15 phút là dấu hiệu rõ ràng rằng Lambda không phải công cụ đúng cho workload này. Chuyển sang Fargate hoặc AWS Batch loại bỏ hẳn lớp vấn đề này — thay vì tối ưu để lách sát giới hạn và vẫn thỉnh thoảng vượt.

Đáp án

C — Để dùng Cross-Region Replication trên S3, phải bật VERSIONING trên bucket trước.

Vì sao đúng

S3 replication có một điều kiện tiên quyết cứng: versioning phải bật ở CẢ bucket nguồn LẪN bucket đích.

Vì sao versioning là bắt buộc:

Replication theo dõi PHIÊN BẢN của object
    → mỗi thay đổi tạo một version ID mới
    → S3 dùng version ID để biết cái nào đã sao chép, cái nào chưa
        ↓
Không có versioning:
    → không có cách nào theo dõi trạng thái sao chép
    → không xử lý được xung đột và thứ tự

Nên nếu versioning chưa bật, tuỳ chọn replication bị làm mờ trong Console.

aws s3api put-bucket-versioning --bucket kho-nguon   --versioning-configuration Status=Enabled
aws s3api put-bucket-versioning --bucket kho-dich   --versioning-configuration Status=Enabled

Sau đó mới cấu hình được replication:

{"Role": "arn:aws:iam::123456789012:role/vai-tro-sao-chep",
 "Rules": [{
   "ID": "sao-chep-toan-bo",
   "Status": "Enabled",
   "Priority": 1,
   "Filter": {},
   "Destination": {"Bucket": "arn:aws:s3:::kho-dich"},
   "DeleteMarkerReplication": {"Status": "Enabled"}}]}

Bốn điều kiện đầy đủ để bật replication:

① Bucket NGUỒN bật versioning
② Bucket ĐÍCH bật versioning
③ IAM role cho phép S3 đọc nguồn và ghi đích
④ Bucket đích phải tồn tại

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

• **D. CRR chỉ có với S3 Standard-Infrequent Access — đây là phương án gần nhất vì cũng nói về lớp lưu trữ, nhưng nó sai: replication hoạt động với MỌI lớp lưu trữ, và bạn còn đổi được lớp ở đích (ví dụ nguồn Standard, đích Glacier để tiết kiệm).
• **A. CRR chỉ có với S3 One Zone-IA — cùng lý do sai.
• **B. Đây là tính năng cao cấp chỉ dành cho tài khoản Enterprise — sai: replication có sẵn cho mọi tài khoản AWS, không phụ thuộc gói hỗ trợ.

Ghi nhớ

Hai loại replication của S3: | Loại | Phạm vi | Dùng cho | |---|---|---| | CRR (Cross-Region Replication) | Region KHÁC | phục hồi thảm hoạ, tuân thủ, giảm độ trễ | | SRR (Same-Region Replication) | cùng Region, bucket khác | gộp log, tách môi trường, tuân thủ nội bộ |

Cả hai đều cần versioning ở hai đầu.

Ba hành vi quan trọng của replication: | Hành vi | Chi tiết | |---|---| | CHỈ sao chép object MỚI | object đã có từ trước KHÔNG tự sao chép | | Bất đồng bộ | thường vài giây tới vài phút | | Không sao chép chuỗi | A→B→C thì object từ A không tới C |

Dòng đầu là cạm bẫy hay gặp nhất: bật replication xong tưởng đã an toàn, nhưng dữ liệu cũ vẫn chỉ có một bản. Dùng S3 Batch Replication để xử lý phần đã có:

aws s3control create-job --account-id 123456789012   --operation '{"S3ReplicateObject": {}}'   --manifest-generator '{"S3JobManifestGenerator": {
    "SourceBucket": "arn:aws:s3:::kho-nguon",
    "Filter": {"ObjectReplicationStatuses": ["NONE"]}}}'

Những gì KHÔNG được sao chép:

✗ Object đã có TRƯỚC khi bật replication (trừ khi dùng Batch Replication)
✗ Object được mã hoá bằng SSE-C
✗ Object trong bucket nguồn được sao chép từ bucket khác (không bắc cầu)
✗ Thao tác lifecycle ở nguồn (xoá do lifecycle không lan sang đích)

Ba tuỳ chọn đáng biết khi cấu hình: | Tuỳ chọn | Việc | |---|---| | DeleteMarkerReplication | có sao chép delete marker sang đích hay không | | StorageClass ở đích | đổi lớp lưu trữ để tiết kiệm | | AccessControlTranslation | đổi chủ sở hữu object sang chủ bucket đích |

Về DeleteMarkerReplication, cân nhắc kỹ:

BẬT:  xoá ở nguồn → delete marker lan sang đích → hai bên đồng bộ
TẮT:  xoá ở nguồn → đích VẪN GIỮ → bảo vệ khỏi xoá nhầm

Với mục đích phục hồi thảm hoạ, TẮT thường an toàn hơn. (Lưu ý: xoá một phiên bản cụ thể thì không bao giờ được sao chép — chỉ delete marker mới có tuỳ chọn.)

Và một tuỳ chọn cho yêu cầu tuân thủ chặt: S3 Replication Time Control (RTC).

Cam kết 99,99% object được sao chép trong 15 PHÚT
    → có SLA và metric theo dõi
    → tính phí thêm

Ba metric theo dõi replication: | Metric | Ý nghĩa | |---|---| | ReplicationLatency | độ trễ sao chép | | OperationsPendingReplication | số object đang chờ | | OperationsFailedReplication | số object sao chép thất bại |

Ba ứng dụng của replication: | Ứng dụng | Loại | |---|---| | Phục hồi thảm hoạ đa Region | CRR | | Tuân thủ về vị trí dữ liệu | CRR | | Giảm độ trễ cho người dùng ở xa | CRR | | Gộp log từ nhiều bucket | SRR | | Sao chép sang tài khoản khác để cách ly | SRR hoặc CRR |

Dòng cuối là biện pháp chống ransomware đáng chú ý: sao chép sang bucket ở tài khoản khác với quyền chỉ ghi — kẻ tấn công chiếm được tài khoản chính vẫn không xoá được bản sao.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Lưu trữ ở CẢ HAI bucket | trả tiền hai lần | | Phí truyền dữ liệu xuyên Region | ~0,02 USD/GB | | Phí request replication | theo số object |

Cân nhắc lọc theo prefix thay vì sao chép toàn bộ:

{"Filter": {"Prefix": "du-lieu-quan-trong/"}}

Và một lời khuyên: hãy kiểm chứng replication đang hoạt động bằng cách xem trạng thái của object:

aws s3api head-object --bucket kho-nguon --key tep-thu.txt   --query ReplicationStatus
# PENDING, COMPLETED, hoặc FAILED

Trạng thái FAILED thường do IAM role thiếu quyền hoặc bucket đích có policy chặn — và nó không hiện ra ở đâu khác nếu bạn không chủ động kiểm tra.

Đáp án

C — Tạo Amazon Pinpoint journey cho chiến dịch SMS và một Kinesis Data Stream để phân tích; cấu hình Pinpoint gửi sự kiện vào Kinesis; đặt thời gian giữ dữ liệu của Kinesis là 365 ngày.

Vì sao đúng

Đề nêu bốn yêu cầu, và Pinpoint kết hợp Kinesis đáp ứng đủ: | Yêu cầu | Cơ chế | |---|---| | Chiến dịch marketing SMS nhiều bước | Pinpoint journey — công cụ chuyên cho việc này | | Người nhận TRẢ LỜI được tin nhắn | Pinpoint hỗ trợ SMS hai chiều | | Giữ phản hồi CẢ NĂM để phân tích | Kinesis giữ tới 365 ngày | | Xử lý và phân tích GẦN THỜI GIAN THỰC | Kinesis là luồng thời gian thực |

Amazon Pinpoint là dịch vụ marketing đa kênh:

Pinpoint hỗ trợ:
    ✓ SMS (một chiều và HAI CHIỀU)
    ✓ Email, push notification, voice, in-app
    ✓ Phân khúc người nhận
    ✓ Journey — chuỗi bước tự động theo hành vi
    ✓ Phân tích tỷ lệ gửi thành công, mở, nhấp

Và SMS hai chiều là điểm phân biệt quan trọng:

Amazon SNS gửi SMS:
    → MỘT CHIỀU — người nhận KHÔNG trả lời được

Amazon Pinpoint:
    → HAI CHIỀU — nhận được phản hồi
    → phản hồi phát thành sự kiện

Đề nói rõ "allow a subscriber to REPLY to the SMS messages" — chỉ Pinpoint làm được.

Và con số 365 ngày khớp chính xác với giới hạn của Kinesis Data Streams:

aws kinesis increase-stream-retention-period   --stream-name luong-phan-hoi-sms --retention-period-hours 8760
# 8.760 giờ = 365 ngày — mức TỐI ĐA

Cấu hình Pinpoint gửi sự kiện vào Kinesis:

aws pinpoint put-event-stream --application-id <app-id>   --write-event-stream '{
    "DestinationStreamArn": "arn:aws:kinesis:...:stream/luong-phan-hoi-sms",
    "RoleArn": "arn:aws:iam::...:role/vai-tro-pinpoint"}'

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

• **A. Tạo SNS topic và Kinesis data stream với cấu hình mặc định; tích hợp Kinesis với SNS topic — đây là phương án gần nhất vì cũng dùng Kinesis, nhưng nó sai ở hai chỗ: SNS gửi SMS MỘT CHIỀU, không nhận được trả lời. Và cấu hình mặc định của Kinesis giữ 24 GIỜ, không phải 365 ngày như yêu cầu.
• **B. Dùng SQS queue để gửi SMS — sai hoàn toàn: SQS là hàng đợi thông điệp giữa các thành phần ứng dụng, nó không gửi SMS. Và Glacier Instant Retrieval không phải nơi phân tích gần thời gian thực.
• **D. Dùng Amazon Connect contact flow gửi SMS xác nhận — sai loại dịch vụ: Amazon Connect là trung tâm liên lạc (call center) phục vụ tương tác trực tiếp với khách hàng qua điện thoại và chat. Nó không phải công cụ chiến dịch marketing hàng loạt.

Ghi nhớ

Ba dịch vụ nhắn tin của AWS — đừng nhầm: | Dịch vụ | Việc | |---|---| | Amazon SNS | phát tán thông báo — SMS MỘT CHIỀU, email, HTTP, Lambda | | Amazon Pinpoint | marketing đa kênh — SMS HAI CHIỀU, journey, phân khúc, phân tích | | Amazon SES | email giao dịch và marketing khối lượng lớn | | Amazon Connect | trung tâm liên lạc — tổng đài |

Quy tắc nhận diện:

"marketing campaign", "journey", "segment", "two-way SMS" → Pinpoint "notification", "fan-out", "pub/sub" → SNS "email at scale", "bounce handling" → SES "call center", "agent", "IVR" → Connect

Thời gian giữ dữ liệu của Kinesis Data Streams: | Mức | Giá trị | |---|---| | Mặc định | 24 giờ | | Tối đa (extended retention) | 365 ngày (8.760 giờ) | | Long-term retention | từ 7 ngày trở lên tính phí thêm |

Con số 365 ngày là chi tiết mà đề nhắm tới — nó khớp với yêu cầu "kept for an entire year".

Ba khả năng của Pinpoint journey: | Khả năng | Chi tiết | |---|---| | Chuỗi bước tự động | gửi tin → chờ → nếu chưa trả lời thì gửi nhắc | | Rẽ nhánh theo hành vi | người trả lời và người không trả lời đi hai nhánh khác nhau | | Lên lịch và giới hạn tần suất | tránh làm phiền khách hàng |

Ba loại sự kiện Pinpoint phát ra: | Sự kiện | Nội dung | |---|---| | _SMS.SUCCESS / _SMS.FAILURE | trạng thái gửi | | _SMS.OPTOUT | người dùng huỷ đăng ký | | Inbound message | nội dung phản hồi của người nhận |

Và _SMS.OPTOUT là sự kiện BẮT BUỘC phải xử lý — quy định về SMS ở hầu hết quốc gia yêu cầu ngừng gửi ngay khi người dùng trả lời STOP.

Kiến trúc đầy đủ cho tình huống của đề:

Pinpoint journey → gửi SMS
        ↓ người dùng trả lời
Pinpoint phát sự kiện → Kinesis Data Stream (giữ 365 ngày)
        ├─▶ Managed Service for Apache Flink → phân tích thời gian thực
        ├─▶ Firehose → S3 → Athena (phân tích sâu về sau)
        └─▶ Lambda → cập nhật phân khúc khách hàng

Ba lưu ý về gửi SMS trên AWS: | Lưu ý | Chi tiết | |---|---| | Cần đăng ký số gửi (origination identity) | long code, short code, hoặc sender ID tuỳ quốc gia | | Nhiều quốc gia yêu cầu đăng ký trước | Mỹ cần 10DLC, có thể mất vài tuần | | Hạn mức chi tiêu mặc định thấp | phải yêu cầu tăng trước chiến dịch lớn |

Dòng cuối là chi tiết vận hành quan trọng: tài khoản mới có hạn mức chi tiêu SMS rất thấp (khoảng 1 USD/tháng ở sandbox). Với chiến dịch gửi cho toàn bộ người đăng ký, phải yêu cầu tăng hạn mức và thoát sandbox trước.

Ba lưu ý về Kinesis retention dài hạn: | Lưu ý | Chi tiết | |---|---| | Chi phí tăng theo thời gian giữ | giữ 365 ngày đắt hơn nhiều so với 24 giờ | | Cân nhắc Firehose → S3 cho lưu trữ dài | rẻ hơn nhiều lần | | Kinesis phù hợp cho phần cần PHÁT LẠI | không phải kho lưu trữ chính |

Trong thực tế, mẫu kinh tế hơn là:

Kinesis giữ 7 ngày (đủ để phát lại khi consumer lỗi)
    + Firehose đẩy sang S3 để lưu trữ 365 ngày
    → chi phí thấp hơn nhiều, và Athena truy vấn được

(Đáp án C vẫn đúng theo bộ đề vì nó đáp ứng yêu cầu bằng một cấu hình duy nhất.)

Và một lưu ý về tuân thủ: chiến dịch SMS chịu quản lý chặt ở nhiều quốc gia (TCPA ở Mỹ, PDPA ở một số nước châu Á). Hãy lưu bằng chứng người dùng đã đồng ý nhận tin cùng với dữ liệu phản hồi — đó thường là thứ đầu tiên cơ quan quản lý hỏi tới.

Đáp án

C — Thiết lập chiến lược pilot light dùng AWS Elastic Disaster Recovery (AWS DRS) để sao chép thay đổi từ ứng dụng tại chỗ sang AWS.

Vì sao đúng

Đề nêu ba yêu cầu, và AWS DRS ở chế độ pilot light đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | RPO 60 giây hoặc ít hơn | DRS sao chép LIÊN TỤC ở mức khối — RPO tính bằng giây | | RTO 1 giờ | khởi chạy instance từ bản sao chép — mất vài phút tới chục phút | | TIẾT KIỆM CHI PHÍ NHẤT | chỉ trả tiền lưu trữ, KHÔNG trả tiền compute khi chờ |

Cách AWS DRS hoạt động:

Cài AWS Replication Agent trên máy chủ SQL Server tại chỗ
    ↓
Sao chép LIÊN TỤC ở mức KHỐI ĐĨA sang vùng chờ (staging area) trong AWS
    → chỉ dùng EBS giá rẻ + một instance sao chép nhỏ
    → KHÔNG chạy instance đích
        ↓
Khi có sự cố: bấm nút khởi chạy
    → DRS dựng instance từ dữ liệu đã sao chép
    → RTO tính bằng phút

Và đây chính là mô hình pilot light:

Pilot light = giữ "ngọn lửa mồi" — dữ liệu luôn được đồng bộ,
              nhưng phần compute chỉ bật khi cần

Chi phí so với warm standby:

AWS DRS (pilot light):
    chi phí lưu trữ EBS + instance sao chép rất nhỏ
    → khoảng vài chục USD/tháng cho một máy chủ

Warm standby với RDS chạy liên tục:
    chi phí instance RDS 24/7
    → hàng trăm tới hàng nghìn USD/tháng

Và DRS sao chép ở mức KHỐI nên không quan tâm tới engine database — SQL Server, ứng dụng, cấu hình hệ điều hành đều được sao chép nguyên trạng.

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

• **D. Dựng warm standby với RDS for SQL Server và dùng DMS với CDC để đồng bộ — đây là phương án gần nhất và đáp ứng được RPO và RTO, nhưng nó đắt hơn đáng kể: RDS instance chạy liên tục 24/7 dù không phục vụ ai, cộng chi phí replication instance của DMS. Đề hỏi "MOST cost-effective".
• **A. Dùng SQL Server Enterprise với Always On availability group và mô hình multi-site active/active — đắt nhất trong các phương án: đòi giấy phép SQL Server Enterprise (rất tốn kém), cộng hạ tầng chạy liên tục ở cả hai nơi. Đây là mức phục hồi cao nhất, vượt xa yêu cầu RTO 1 giờ.
• **B. Sao lưu SQL Server vào Storage Gateway và bật fast snapshot restore — không đạt RPO 60 giây: sao lưu theo lịch cho RPO tính bằng giờ, không phải giây. Và khôi phục từ bản sao lưu mất nhiều thời gian hơn 1 giờ với database lớn.

Ghi nhớ

Bốn chiến lược phục hồi thảm hoạ — bảng cần thuộc: | Chiến lược | RPO | RTO | Chi phí | |---|---|---|---| | Backup & Restore | hàng giờ | hàng giờ tới ngày | thấp nhất | | Pilot Light | vài phút hoặc ít hơn | hàng chục phút | thấp ← câu này | | Warm Standby | vài giây | vài phút | vừa | | Multi-Site Active/Active | gần bằng 0 | gần bằng 0 | cao nhất |

Phân biệt pilot light và warm standby:

Pilot light:
    Dữ liệu ĐƯỢC ĐỒNG BỘ liên tục
    Compute TẮT — chỉ bật khi có sự cố
        → rẻ, RTO tính bằng chục phút

Warm standby:
    Dữ liệu đồng bộ + phiên bản THU NHỎ CHẠY SẴN
        → đắt hơn, RTO tính bằng phút

Hai chỉ số cần xác định trước khi chọn chiến lược: | Chỉ số | Ý nghĩa | |---|---| | RPO (Recovery Point Objective) | chấp nhận MẤT bao nhiêu dữ liệu | | RTO (Recovery Time Objective) | chấp nhận NGỪNG bao lâu |

Đề cho RPO ≤ 60 giây và RTO ≤ 1 giờ → pilot light là điểm cân bằng đúng.

Ba đặc điểm của AWS Elastic Disaster Recovery: | Đặc điểm | Chi tiết | |---|---| | Sao chép LIÊN TỤC ở mức khối | RPO tính bằng giây | | Vùng chờ chi phí thấp | chỉ EBS + instance sao chép nhỏ | | Kiểm thử KHÔNG ảnh hưởng sản xuất | khởi chạy instance thử bất cứ lúc nào |

Khả năng kiểm thử là lợi ích lớn thường bị bỏ qua:

Bấm "Launch drill instance"
    → dựng bản sao đầy đủ để kiểm thử
    → máy nguồn VẪN CHẠY bình thường
    → xong thì xoá đi

Một kế hoạch phục hồi chưa từng được diễn tập chỉ là giả định.

AWS DRS và AWS MGN — hai dịch vụ rất giống nhau: | | AWS DRS | AWS MGN (Application Migration Service) | |---|---|---| | Mục đích | PHỤC HỒI THẢM HOẠ — sao chép liên tục lâu dài | DI CHUYỂN một lần | | Sau khi cắt chuyển | tiếp tục sao chép | kết thúc | | Hỗ trợ chiều ngược | ✅ failback về tại chỗ | — |

Chúng dùng chung công nghệ sao chép nhưng phục vụ hai bài toán khác nhau.

Ba lựa chọn phục hồi thảm hoạ cho SQL Server: | Lựa chọn | Đặc điểm | |---|---| | AWS DRS | sao chép mức khối, không quan tâm engine ← câu này | | DMS với CDC | sao chép mức dữ liệu, sang RDS | | Always On availability group | cần giấy phép Enterprise, đắt |

Và có một điểm cần lưu ý về SQL Server trên AWS:

RDS for SQL Server:
    ✓ được quản lý, ít công vận hành
    ✗ hạn chế một số tính năng (linked server, filestream)
    ✗ chi phí giấy phép tính vào giá instance

SQL Server trên EC2:
    ✓ toàn quyền kiểm soát
    ✓ mang giấy phép sẵn có (BYOL) trên Dedicated Host
    ✗ tự vá lỗi và quản lý

AWS DRS phù hợp với cả hai vì nó sao chép nguyên máy chủ.

Ba việc cần làm trong kế hoạch phục hồi thảm hoạ: | Việc | Chi tiết | |---|---| | Diễn tập định kỳ | ít nhất mỗi năm một lần, ghi lại thời gian thực tế | | Chuẩn bị sẵn kịch bản chuyển DNS | Route 53 failover record | | Kiểm tra phụ thuộc | ứng dụng có gọi dịch vụ nào chỉ có ở tại chỗ không |

Dòng cuối hay bị bỏ sót: database khôi phục xong nhưng ứng dụng vẫn gọi tới máy chủ xác thực hay dịch vụ tệp ở trung tâm dữ liệu đã sập — và kế hoạch vẫn thất bại.

Và một lưu ý về chi phí DRS: nó tính phí theo giờ cho mỗi máy chủ nguồn đang được sao chép, cộng chi phí EBS ở vùng chờ. Với một máy chủ, khoản này rất nhỏ; với hàng trăm máy thì cần tính toán — khi đó hãy cân nhắc chỉ bảo vệ các hệ thống thực sự quan trọng thay vì toàn bộ.

Đáp án

A — Policy liệt kê tường minh bốn hành động (PutItem, DeleteItem, GetItem, UpdateItem) trên đúng ARN của bảng tutorialsdojo.

Vì sao đúng

Đề nêu hai ràng buộc, và chỉ policy A thoả cả hai: | Ràng buộc | Policy A | |---|---| | Chỉ đọc, ghi, cập nhật, xoá ITEM | liệt kê đúng bốn hành động cần | | CHỈ trên bảng tutorialsdojo | Resource trỏ đúng ARN của bảng đó |

Bốn hành động khớp chính xác với bốn thao tác đề yêu cầu:

read   → dynamodb:GetItem
write  → dynamodb:PutItem
update → dynamodb:UpdateItem
delete → dynamodb:DeleteItem

Và Resource khoá đúng một bảng:

arn:aws:dynamodb:us-east-2:123456789012:table/tutorialsdojo

Đây là nguyên tắc quyền tối thiểu đúng nghĩa: cấp đúng thứ cần, không hơn.

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

• **B. Dùng ký tự đại diện trong Action: dynamodb:Put*, dynamodb:Delete*, dynamodb:Get*, dynamodb:Update* — đây là phương án gần nhất và Resource hoàn toàn đúng, nhưng ký tự đại diện cấp thừa quyền:

dynamodb:Delete*  → còn bao gồm DeleteTable, DeleteBackup
dynamodb:Update*  → còn bao gồm UpdateTable, UpdateTimeToLive,
                     UpdateContinuousBackups
dynamodb:Get*     → còn bao gồm GetResourcePolicy

DeleteTable cho phép ứng dụng XOÁ CẢ BẢNG — hậu quả nghiêm trọng hơn hẳn việc xoá một item.

• **C. Đúng bốn hành động nhưng Resource là table/* — cấp quyền trên MỌI bảng trong tài khoản và Region đó. Vi phạm ràng buộc "chỉ bảng tutorialsdojo".
• **D. "Action": "*" trên đúng bảng — cấp TOÀN QUYỀN: bao gồm xoá bảng, đổi cấu hình, tạo backup, sửa quyền. Rộng nhất trong bốn phương án.

Ghi nhớ

Hai chiều của quyền tối thiểu — phải siết CẢ HAI: | Chiều | Câu hỏi | |---|---| | Action | được làm NHỮNG GÌ? | | Resource | trên NHỮNG TÀI NGUYÊN NÀO? |

Bảng phân tích bốn phương án: | | Action | Resource | Kết luận | |---|---|---|---| | A | hẹp ✅ | hẹp ✅ | đúng | | B | rộng ✗ | hẹp ✅ | thừa quyền hành động | | C | hẹp ✅ | rộng ✗ | thừa quyền tài nguyên | | D | rộng ✗ | hẹp ✅ | thừa nhiều nhất |

Các nhóm hành động của DynamoDB — phân biệt rõ: | Nhóm | Hành động | Tác động | |---|---|---| | Trên ITEM (data plane) | GetItem, PutItem, UpdateItem, DeleteItem, Query, Scan, BatchGetItem, BatchWriteItem | dữ liệu | | Trên BẢNG (control plane) | CreateTable, DeleteTable, UpdateTable, DescribeTable | cấu trúc — nguy hiểm hơn nhiều | | Sao lưu | CreateBackup, DeleteBackup, RestoreTableFromBackup | dữ liệu lịch sử |

Ứng dụng chỉ cần nhóm đầu.

Và nếu ứng dụng dùng thêm truy vấn, nhớ bổ sung:

{"Action": ["dynamodb:GetItem", "dynamodb:PutItem",
            "dynamodb:UpdateItem", "dynamodb:DeleteItem",
            "dynamodb:Query", "dynamodb:BatchGetItem"]}

Query là hành động riêng — không nằm trong GetItem.

Và với bảng có Global Secondary Index, cần thêm ARN của index:

{"Resource": [
   "arn:aws:dynamodb:us-east-2:123456789012:table/tutorialsdojo",
   "arn:aws:dynamodb:us-east-2:123456789012:table/tutorialsdojo/index/*"]}

Thiếu dòng thứ hai thì truy vấn qua GSI bị từ chối — lỗi hay gặp và khó đoán.

Cấu trúc ARN của DynamoDB:

arn:aws:dynamodb:<region>:<account-id>:table/<ten-bang>
arn:aws:dynamodb:<region>:<account-id>:table/<ten-bang>/index/<ten-index>
arn:aws:dynamodb:<region>:<account-id>:table/<ten-bang>/stream/<timestamp>

Và DynamoDB hỗ trợ phân quyền tới TỪNG DÒNG và TỪNG CỘT:

{"Effect": "Allow", "Action": ["dynamodb:GetItem", "dynamodb:Query"],
 "Resource": "arn:aws:dynamodb:...:table/tutorialsdojo",
 "Condition": {
   "ForAllValues:StringEquals": {
     "dynamodb:LeadingKeys": ["${aws:userid}"],
     "dynamodb:Attributes": ["ma", "ten", "email"]}}}

Đây là tính năng rất mạnh cho ứng dụng nhiều người dùng — mỗi người chỉ thấy dữ liệu của chính mình.

Ba công cụ hỗ trợ viết policy tối thiểu: | Công cụ | Việc | |---|---| | IAM Access Analyzer policy generation | sinh policy từ hoạt động THẬT trong CloudTrail | | IAM Policy Simulator | thử một hành động và xem kết quả kèm lý do | | Access Advisor | cho biết dịch vụ nào thực sự được dùng gần đây |

Công cụ đầu là cách thực dụng nhất: cấp rộng trong môi trường thử, chạy ứng dụng vài ngày, rồi để Access Analyzer sinh policy khớp chính xác những gì nó dùng.

Ba lưu ý về ký tự đại diện trong policy: | Lưu ý | Chi tiết | |---|---| | Action: "*" hoặc Resource: "*" | chỉ dùng khi thực sự cần quyền quản trị | | service:Verb* thường rộng hơn tưởng | kiểm tra tài liệu xem nó bao gồm gì | | Ưu tiên liệt kê tường minh | dài hơn nhưng an toàn hơn |

Và với ứng dụng chạy trên VMware Cloud on AWS như đề mô tả:

VMware Cloud on AWS chạy trong VPC riêng
    → ứng dụng không có IAM role của EC2
    → cần một trong hai cách:
        ① IAM user với access key (kém an toàn)
        ② Federation qua STS với identity provider của bạn (tốt hơn)

Và một lời khuyên: hãy thêm điều kiện giới hạn nguồn nếu biết trước ứng dụng gọi từ đâu:

{"Condition": {"IpAddress": {"aws:SourceIp": ["203.0.113.0/24"]}}}

Ngay cả khi thông tin đăng nhập bị lộ, kẻ tấn công ở ngoài dải đó cũng không dùng được.

Đáp án

C — Thiết lập RDS database và bật IAM DB Authentication.

Vì sao đúng

Đề nêu hai yêu cầu, và IAM DB Authentication đáp ứng cả hai cùng lúc: | Yêu cầu | Cơ chế | |---|---| | Lưu lượng tới database phải mã hoá bằng SSL | IAM DB auth BẮT BUỘC dùng SSL | | Dùng thông tin đăng nhập của EC2 thay cho mật khẩu | IAM role của instance sinh token |

Điểm mấu chốt: IAM DB Authentication bắt buộc SSL — không phải tuỳ chọn.

Token xác thực đi trong chuỗi kết nối
    → nếu không mã hoá thì token bị lộ khi truyền
        ↓
AWS BẮT BUỘC kết nối phải dùng SSL/TLS
    → giải quyết luôn yêu cầu mã hoá đường truyền

Và "profile credentials specific to your EC2 instance" chính là IAM role:

EC2 instance có IAM role
    → SDK tự lấy thông tin đăng nhập tạm thời qua IMDS
    → dùng chúng để sinh token database
    → KHÔNG có mật khẩu nào lưu ở đâu

Luồng đầy đủ:

# Trên EC2 — SDK tự dùng IAM role của instance
TOKEN=$(aws rds generate-db-auth-token   --hostname db-ung-dung.abc.ap-southeast-1.rds.amazonaws.com   --port 3306 --username nguoi_dung_ung_dung)

mysql --host=db-ung-dung.abc.ap-southeast-1.rds.amazonaws.com       --user=nguoi_dung_ung_dung --password="$TOKEN"       --ssl-ca=global-bundle.pem

Ba bước thiết lập:

-- ① Trong MySQL: tạo user dùng plugin IAM
CREATE USER 'nguoi_dung_ung_dung' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
GRANT SELECT, INSERT, UPDATE ON kho_du_lieu.* TO 'nguoi_dung_ung_dung';

// ② Cấp quyền IAM cho role của EC2
{"Effect": "Allow", "Action": ["rds-db:connect"],
 "Resource": "arn:aws:rds-db:ap-southeast-1:123456789012:dbuser:db-ABCDEFG/nguoi_dung_ung_dung"}

# ③ Bật IAM auth trên RDS instance
aws rds modify-db-instance --db-instance-identifier db-ung-dung   --enable-iam-database-authentication --apply-immediately

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

• **D. Khởi chạy mysql client với tham số --ssl-ca — đây là phương án gần nhất và đáp ứng đúng vế SSL, nhưng nó thiếu hẳn vế thứ hai: nó không thay thế mật khẩu bằng thông tin đăng nhập của EC2. Bạn vẫn phải lưu mật khẩu ở đâu đó.
• **B. Cấu hình RDS để bật mã hoá — sai loại mã hoá: tuỳ chọn này bật mã hoá AT REST (dữ liệu trên đĩa, snapshot) bằng KMS. Đề yêu cầu mã hoá lưu lượng mạng — đó là mã hoá in-transit.
• **A. Khởi chạy Aurora với tính năng Backtrack — hoàn toàn không liên quan: Backtrack cho phép quay ngược cả cluster về một thời điểm trước đó, phục vụ việc chữa lỗi do người. Nó không dính gì tới mã hoá hay xác thực.

Ghi nhớ

Hai loại mã hoá của RDS — đừng nhầm: | Loại | Bảo vệ | Bật thế nào | |---|---|---| | At rest | dữ liệu trên ĐĨA, snapshot, bản sao lưu | KMS, bật LÚC TẠO instance | | In transit | dữ liệu khi TRUYỀN qua mạng | SSL/TLS, dùng chứng chỉ CA của RDS |

Mã hoá at rest KHÔNG bật được cho instance đang chạy — phải chụp snapshot, sao chép có mã hoá, rồi khôi phục.

Ba cách xác thực vào RDS: | Cách | Đặc điểm | |---|---| | Mật khẩu tĩnh | đơn giản nhất, rủi ro nhất | | Secrets Manager | mật khẩu được lưu an toàn và XOAY VÒNG TỰ ĐỘNG | | IAM DB Authentication | token 15 phút, KHÔNG có mật khẩu ← câu này |

Quy tắc nhận diện:

"use EC2 instance profile credentials", "no password", "short-lived token" → IAM DB Authentication "rotate database password automatically" → Secrets Manager

Ba giới hạn của IAM DB Authentication: | Giới hạn | Chi tiết | |---|---| | Chỉ MySQL, MariaDB, PostgreSQL | không có với Oracle, SQL Server | | Giới hạn số kết nối MỚI mỗi giây | ~200/giây với MySQL | | Token hết hạn sau 15 phút | ứng dụng phải tự sinh lại |

Dòng giữa là hạn chế thực tế: IAM DB auth phù hợp cho ứng dụng dùng connection pool (ít kết nối, giữ lâu), không phù hợp cho ứng dụng mở kết nối mới mỗi request.

Và RDS Proxy giải quyết vấn đề đó:

Ứng dụng → (IAM auth) → RDS Proxy → (mật khẩu từ Secrets Manager) → RDS
    ✓ gộp và tái dùng kết nối
    ✓ giữ kết nối trong lúc failover
    ✓ giảm thời gian failover cảm nhận được tới 66%

Ba cách bắt buộc SSL cho RDS: | Cách | Chi tiết | |---|---| | Tham số require_secure_transport = ON (MySQL) | từ chối mọi kết nối không mã hoá | | rds.force_ssl = 1 (PostgreSQL) | tương đương | | IAM DB auth | tự động bắt buộc SSL |

aws rds modify-db-parameter-group --db-parameter-group-name pg-ung-dung   --parameters "ParameterName=require_secure_transport,ParameterValue=ON,ApplyMethod=immediate"

Đây là cách chắc chắn nhất — không phụ thuộc vào việc client có nhớ khai --ssl-ca hay không.

Và phải tải chứng chỉ CA của RDS để xác minh:

wget https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

Không xác minh chứng chỉ nghĩa là kết nối vẫn mã hoá nhưng không chống được tấn công người-đứng-giữa.

Ba biện pháp bảo mật khác cho RDS: | Biện pháp | Chi tiết | |---|---| | Đặt trong PRIVATE subnet | không có IP công khai | | Security group chỉ nhận từ SG của tầng ứng dụng | không dùng CIDR rộng | | Bật CloudTrail và database audit log | biết ai truy cập gì |

Và với việc di chuyển từ tại chỗ lên AWS như đề mô tả, đừng quên: | Việc | Công cụ | |---|---| | Chuyển lược đồ nếu đổi engine | AWS SCT | | Chuyển dữ liệu ít gián đoạn | AWS DMS với CDC | | Kiểm chứng dữ liệu sau khi chuyển | bật validation của DMS |

Và một lưu ý khi triển khai IAM DB auth: kiểm tra thư viện client có hỗ trợ token dài không. Token của RDS dài vài trăm ký tự, và một số driver cũ có giới hạn độ dài trường mật khẩu — đây là lỗi hay gặp và thông báo lỗi thường không nói rõ nguyên nhân.

Đáp án

C — Tạo bucket policy yêu cầu người dùng đặt ACL của object thành bucket-owner-full-control.

Vì sao đúng

Đề mô tả một vấn đề đặc thù của S3: object do tài khoản KHÁC tải lên thì tài khoản đó là CHỦ SỞ HỮU, không phải chủ bucket.

Vấn đề cụ thể:

Người dùng bên ngoài tải object lên bucket của bạn
    → object thuộc sở hữu của TÀI KHOẢN HỌ
    → CHỦ BUCKET có thể KHÔNG đọc được object trong chính bucket mình
    → và phải trả tiền lưu trữ cho nó

Cách sửa: bắt buộc người tải lên trao quyền cho chủ bucket:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "BatBuocTraoQuyenChoChuBucket",
   "Effect": "Deny",
   "Principal": "*",
   "Action": "s3:PutObject",
   "Resource": "arn:aws:s3:::kho-chia-se/*",
   "Condition": {"StringNotEquals":
     {"s3:x-amz-acl": "bucket-owner-full-control"}}}]}

Người tải lên phải khai header tương ứng:

aws s3 cp tep.pdf s3://kho-chia-se/ --acl bucket-owner-full-control

Thiếu header đó là bị từ chối ngay — không có object nào lọt vào mà chủ bucket không đọc được.

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

• **D. Bật server access logging và tạo IAM policy yêu cầu đặt ACL — đây là phương án gần nhất vì cũng nhắc tới ACL đúng, nhưng nó sai chỗ đặt chính sách: bạn không kiểm soát được IAM policy của tài khoản bên ngoài. Ràng buộc phải nằm ở bucket policy — thứ mà bạn sở hữu. Và access logging chỉ ghi lại, không ràng buộc gì.
• **A. Bật Requester Pays — giải quyết vấn đề khác: nó chuyển chi phí truyền dữ liệu sang người tải xuống. Không liên quan tới quyền sở hữu object.
• **B. Tạo cấu hình CORS — hoàn toàn không liên quan: CORS quy định trình duyệt có cho JavaScript từ tên miền này gọi tài nguyên ở tên miền khác hay không.

Ghi nhớ về cách làm hiện đại

Từ tháng 4/2023, AWS có cách giải quyết tốt hơn nhiều: S3 Object Ownership.

aws s3api put-bucket-ownership-controls --bucket kho-chia-se   --ownership-controls 'Rules=[{ObjectOwnership=BucketOwnerEnforced}]'

Ba chế độ Object Ownership: | Chế độ | Ý nghĩa | |---|---| | BucketOwnerEnforced (mặc định cho bucket MỚI) | ACL bị VÔ HIỆU HOÁ; chủ bucket sở hữu MỌI object tự động | | BucketOwnerPreferred | chủ bucket sở hữu object nếu người tải lên đặt ACL bucket-owner-full-control | | ObjectWriter | hành vi cũ — người tải lên sở hữu |

Với BucketOwnerEnforced, vấn đề trong đề biến mất hoàn toàn:

Không cần bucket policy về ACL
Không cần người tải lên khai header gì
Chủ bucket TỰ ĐỘNG sở hữu mọi object
    → quyền truy cập hoàn toàn do IAM và bucket policy quyết định

Đây là cách AWS khuyến nghị hiện nay — đáp án C là cách làm đúng ở thời điểm câu hỏi được soạn và vẫn hoạt động, nhưng bucket mới tạo hôm nay đã mặc định ở chế độ tốt hơn.

Ghi nhớ

Bốn cơ chế kiểm soát truy cập S3: | Cơ chế | Phạm vi | Trạng thái | |---|---|---| | Bucket policy | cả bucket hoặc theo prefix | được khuyến nghị | | IAM policy | theo user, role | cho truy cập đã xác thực | | ACL | từng object hoặc bucket | cũ — AWS khuyên tránh | | S3 Access Point | nhóm người dùng khác nhau | cho bucket dùng chung phức tạp |

Các giá trị ACL định sẵn (canned ACL): | Giá trị | Ý nghĩa | |---|---| | private | mặc định — chỉ chủ object | | bucket-owner-full-control | chủ bucket có toàn quyền ← câu này | | bucket-owner-read | chủ bucket chỉ đọc | | public-read | ai cũng đọc được | | authenticated-read | mọi người dùng AWS đọc được |

Ba vấn đề khi object thuộc sở hữu tài khoản khác: | Vấn đề | Hậu quả | |---|---| | Chủ bucket không đọc được object | dữ liệu trong bucket mình mà không dùng được | | Không áp được lifecycle rule đầy đủ | một số thao tác bị chặn | | Vẫn phải trả tiền lưu trữ | trả tiền cho thứ không kiểm soát được |

Và S3 Access Point là công cụ tốt cho bucket chia sẻ với nhiều bên:

aws s3control create-access-point --account-id 123456789012   --name diem-truy-cap-doi-tac --bucket kho-chia-se   --policy file://chinh-sach-doi-tac.json

Mỗi đối tác một access point với chính sách riêng — thay vì một bucket policy khổng lồ khó đọc và dễ sai.

Ba biện pháp nên có cho bucket nhận dữ liệu từ bên ngoài: | Biện pháp | Lý do | |---|---| | Bắt buộc mã hoá khi ghi | điều kiện s3:x-amz-server-side-encryption | | Bắt buộc HTTPS | điều kiện aws:SecureTransport | | Giới hạn prefix theo từng đối tác | mỗi bên chỉ ghi vào thư mục của mình |

Chính sách giới hạn prefix:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
 "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::kho-chia-se/doi-tac-a/*"}

Và bật Object Lock hoặc versioning nếu dữ liệu quan trọng:

Versioning: chống ghi đè nhầm
Object Lock: chống xoá hoàn toàn

Ba lưu ý về Block Public Access: | Lưu ý | Chi tiết | |---|---| | Bật ở mức TÀI KHOẢN | áp cho mọi bucket, kể cả bucket tạo sau | | Bật mặc định cho bucket mới từ 2023 | | | Không ảnh hưởng chia sẻ giữa các tài khoản AWS | chỉ chặn truy cập ẩn danh |

Và một lời khuyên: hãy dùng IAM Access Analyzer for S3 để rà soát định kỳ xem bucket nào đang truy cập được từ ngoài tổ chức. Với bucket chia sẻ với nhiều bên, cấu hình dễ trôi dạt theo thời gian — và công cụ này cho bức tranh chính xác về ai thực sự vào được.

Đáp án

D — Thu thập dữ liệu bằng Kinesis Data Streams và tạo Lambda function lưu dữ liệu vào Amazon DynamoDB.

Vì sao đúng

Đề nêu hai yêu cầu, và cặp Kinesis + DynamoDB đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Thu thập và phân tích THỜI GIAN THỰC | Kinesis Data Streams — độ trễ mili giây | | Thời gian phản hồi MILI GIÂY | DynamoDB — độ trễ mili giây một chữ số |

Vế "millisecond response times" là điều kiện quyết định lựa chọn kho lưu trữ:

DynamoDB:
    → độ trễ đọc và ghi MILI GIÂY MỘT CHỮ SỐ
    → ổn định bất kể quy mô
    → tự mở rộng theo lượng dữ liệu IoT

Redshift:
    → kho dữ liệu cho PHÂN TÍCH quét lượng lớn
    → độ trễ truy vấn tính bằng GIÂY
    → tối ưu cho OLAP, không phải truy vấn từng bản ghi

Và Kinesis Data Streams là lựa chọn đúng cho "ingest and analyze in REAL-TIME":

Kinesis Data Streams:
    → độ trễ MILI GIÂY
    → nhiều consumer độc lập
    → phát lại được (giữ 1–365 ngày)

Kinesis Data Firehose:
    → gom theo lô, độ trễ TỐI THIỂU ~60 GIÂY
    → không phải thời gian thực

Kiến trúc hoàn chỉnh:

Cảm biến IoT → Kinesis Data Streams
                    ↓ event source mapping
              Lambda (đọc theo LÔ)
                    ↓ BatchWriteItem
                DynamoDB

def lambda_handler(event, context):
    bang = boto3.resource('dynamodb').Table('du-lieu-cam-bien')
    with bang.batch_writer() as lo:
        for ban_ghi in event['Records']:
            du_lieu = json.loads(base64.b64decode(ban_ghi['kinesis']['data']))
            lo.put_item(Item=du_lieu)

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

• **A. Kinesis Data Streams + Lambda lưu vào Amazon Redshift — đây là phương án gần nhất và phần thu thập hoàn toàn đúng, nhưng nó sai kho lưu trữ: Redshift là kho dữ liệu OLAP, độ trễ truy vấn tính bằng giây. Và ghi từng bản ghi vào Redshift bằng INSERT là mẫu rất kém hiệu quả — Redshift được thiết kế cho COPY theo lô lớn.
• **B. Kinesis Data Firehose + Lambda lưu vào DynamoDB — sai ở tầng thu thập: Firehose gom dữ liệu theo lô với độ trễ tối thiểu khoảng 60 giây, không đáp ứng "real-time". Và vai trò của Lambda với Firehose là biến đổi dữ liệu trên đường đi, không phải làm consumer.
• **C. Amazon SQS + Lambda lưu vào Redshift — sai cả hai: SQS không giữ dữ liệu để phát lại và không hỗ trợ nhiều consumer độc lập; Redshift sai kho lưu trữ như đã nêu.

Ghi nhớ

Kinesis Data Streams và Data Firehose — bảng phân biệt cốt lõi: | | Data Streams | Data Firehose | |---|---|---| | Độ trễ | MILI GIÂY | tối thiểu ~60 giây | | Bạn viết consumer | ✅ CÓ | ❌ không cần | | Phát lại (replay) | ✅ 1–365 ngày | ❌ | | Nhiều consumer độc lập | ✅ | ❌ | | Vai trò của Lambda | ĐỌC bản ghi | BIẾN ĐỔI trên đường đi | | Đích | tuỳ bạn | S3, Redshift, OpenSearch, Splunk |

Quy tắc nhận diện:

"real-time", "millisecond", "replay", "multiple consumers" → Data Streams "deliver to S3/Redshift", "no code", "near real-time" → Firehose

Chọn kho lưu trữ theo mẫu truy cập: | Mẫu | Dịch vụ | |---|---| | Đọc ghi từng bản ghi, độ trễ mili giây | DynamoDB ← câu này | | Phân tích quét lượng lớn (OLAP) | Redshift | | Truy vấn SQL trên dữ liệu ở S3 | Athena | | Tìm kiếm và dashboard thời gian thực | OpenSearch | | Dữ liệu chuỗi thời gian | Timestream — thiết kế riêng cho IoT |

Và Amazon Timestream đáng cân nhắc cho dữ liệu cảm biến:

Timestream:
    ✓ thiết kế riêng cho dữ liệu CHUỖI THỜI GIAN
    ✓ tự phân tầng: dữ liệu nóng trong bộ nhớ, dữ liệu cũ ở tầng từ tính
    ✓ hàm phân tích chuỗi thời gian dựng sẵn (nội suy, làm mượt)
    ✓ rẻ hơn DynamoDB cho khối lượng lớn dữ liệu theo thời gian

(DynamoDB vẫn là đáp án đúng theo bộ đề và hoàn toàn dùng được; Timestream chuyên biệt hơn cho IoT.)

Ba cấu hình quan trọng của Lambda đọc Kinesis: | Cấu hình | Việc | |---|---| | BatchSize | số bản ghi mỗi lần gọi (tới 10.000) | | MaximumBatchingWindowInSeconds | chờ gom thêm — cân bằng độ trễ và chi phí | | ParallelizationFactor | số lô xử lý song song mỗi shard (tới 10) |

Và hai cấu hình xử lý lỗi là BẮT BUỘC trong sản xuất:

{"BisectBatchOnFunctionError": true,
 "MaximumRetryAttempts": 3,
 "DestinationConfig": {"OnFailure": {"Destination": "arn:aws:sqs:...:dlq"}}}

Không có chúng:
    một bản ghi hỏng → Lambda thử lại mãi
    → CHẶN CẢ SHARD → không xử lý được gì phía sau
    → tới khi bản ghi hỏng hết hạn lưu trữ

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

Hai chế độ dung lượng: | Chế độ | Phù hợp | |---|---| | Provisioned | tải ổn định, rẻ hơn | | On-demand | tải khó đoán — tự mở rộng tới 200 MB/giây |

Với cảm biến IoT mới ra mắt, on-demand là lựa chọn an toàn — không phải dự báo số shard khi chưa biết quy mô.

Ba nguyên tắc thiết kế bảng DynamoDB cho dữ liệu IoT: | Nguyên tắc | Lý do | |---|---| | Partition key = ID thiết bị | phân tán tốt, tránh hot partition | | Sort key = timestamp | truy vấn theo khoảng thời gian hiệu quả | | Bật TTL | tự xoá dữ liệu cũ, MIỄN PHÍ |

TTL đặc biệt quan trọng với IoT — dữ liệu cảm biến tích tụ rất nhanh:

aws dynamodb update-time-to-live --table-name du-lieu-cam-bien   --time-to-live-specification "Enabled=true,AttributeName=het_han_luc"

Và một lưu ý về kiến trúc mở rộng: nếu sau này cần cả truy vấn nhanh lẫn phân tích lịch sử, hãy dùng cả hai đích từ cùng một stream — Lambda ghi vào DynamoDB cho truy vấn tức thì, và Firehose đẩy sang S3 cho phân tích bằng Athena. Kinesis hỗ trợ nhiều consumer độc lập nên không phải chọn một trong hai.