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

Đáp án

D và E.

• D — RDS child processes
• E — OS processes

Vì sao đúng

Câu hỏi phân biệt Enhanced Monitoring với CloudWatch metric thông thường của RDS — và điểm khác biệt nằm ở chỗ dữ liệu được lấy từ đâu.

Hai nguồn dữ liệu hoàn toàn khác nhau:

CloudWatch metric THÔNG THƯỜNG:
    → thu thập từ TẦNG HYPERVISOR (bên ngoài máy ảo)
    → chu kỳ 60 giây
    → thấy được: CPU, kết nối, bộ nhớ trống, IOPS
    → KHÔNG thấy được gì bên trong hệ điều hành

ENHANCED MONITORING:
    → agent chạy BÊN TRONG hệ điều hành của DB instance
    → chu kỳ tới 1 GIÂY
    → thấy được: DANH SÁCH TIẾN TRÌNH, luồng, bộ nhớ theo tiến trình

Và hai đáp án chính là thứ chỉ có ở tầng hệ điều hành: | Metric | Nội dung | |---|---| | RDS child processes | các tiến trình con của engine cơ sở dữ liệu | | OS processes | tiến trình của hệ điều hành hỗ trợ RDS |

Vì sao sự khác biệt này quan trọng trong thực tế:

CPU ở CloudWatch thường: 90%
    → biết CPU cao, KHÔNG biết tiến trình nào gây ra

Enhanced Monitoring:
    → thấy CHÍNH XÁC tiến trình nào chiếm CPU
    → phân biệt được engine bận hay tiến trình hệ thống bận

aws rds modify-db-instance --db-instance-identifier db-tuyen-sinh   --monitoring-interval 5   --monitoring-role-arn arn:aws:iam::123456789012:role/rds-monitoring-role

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

(Ba phương án còn lại đều là metric có sẵn ở CloudWatch thông thường, không cần Enhanced Monitoring.)

• **A. CPU Utilization — đây là phương án gần nhất vì Enhanced Monitoring cũng báo CPU, nhưng CloudWatch thông thường ĐÃ CÓ metric này. Nó không phải thứ mà Enhanced Monitoring bổ sung thêm.
• **B. Database Connections — metric CloudWatch tiêu chuẩn, có sẵn không cần bật gì.
• **C. Freeable Memory — cũng là metric CloudWatch tiêu chuẩn.

Ghi nhớ

Ba công cụ giám sát RDS — bảng phân biệt cốt lõi: | | CloudWatch metric | Enhanced Monitoring | Performance Insights | |---|---|---|---| | Nguồn dữ liệu | hypervisor | agent TRONG hệ điều hành | bên trong ENGINE database | | Chu kỳ nhỏ nhất | 60 giây | 1 giây | 1 giây | | Thấy được | CPU, kết nối, IOPS, bộ nhớ | tiến trình, luồng, chi tiết OS | TRUY VẤN nào chậm, chờ ở đâu | | Nơi lưu | CloudWatch Metrics | CloudWatch Logs | kho riêng của Performance Insights | | Chi phí | có sẵn | phí CloudWatch Logs | 7 ngày MIỄN PHÍ |

Ba công cụ trả lời ba câu hỏi khác nhau:

CloudWatch          → "instance có đang quá tải không?"
Enhanced Monitoring → "TIẾN TRÌNH nào đang ngốn tài nguyên?"
Performance Insights→ "TRUY VẤN nào chậm và nó đang chờ cái gì?"

Với "vấn đề hiệu năng của database", Performance Insights thường là công cụ hữu ích nhất — nó chỉ thẳng ra truy vấn tốn kém nhất và loại chờ đợi (chờ I/O, chờ khoá, chờ CPU). Enhanced Monitoring hữu ích khi nghi ngờ vấn đề nằm ở tầng hệ điều hành.

Các metric mà Enhanced Monitoring bổ sung: | Nhóm | Metric | |---|---| | Tiến trình | RDS child processes, RDS processes, OS processes | | CPU chi tiết | guest, irq, nice, steal, system, user, wait | | Bộ nhớ chi tiết | active, buffers, cached, free, dirty, writeback | | Đĩa và hệ thống tệp | readKb, writeKb, avgQueueLen, util | | Tải hệ thống | loadAverageMinute (1, 5, 15 phút) |

Metric steal đáng chú ý: nó cho biết thời gian CPU bị "đánh cắp" bởi hypervisor — giá trị cao nghĩa là máy chủ vật lý đang quá tải, một thông tin mà CloudWatch thường không cho biết.

Các metric CloudWatch tiêu chuẩn quan trọng của RDS: | Metric | Cảnh báo khi | |---|---| | CPUUtilization | trên 80% kéo dài | | FreeableMemory | xuống thấp — nguy cơ swap và chậm nghiêm trọng | | FreeStorageSpace | dưới 15% — hết đĩa là database NGỪNG GHI | | DatabaseConnections | tiến gần max_connections | | ReadLatency / WriteLatency | tăng đột biến | | ReplicaLag | replica tụt hậu | | DiskQueueDepth | I/O bị nghẽn |

Ba lưu ý khi bật Enhanced Monitoring: | Lưu ý | Chi tiết | |---|---| | Cần IAM role riêng | AmazonRDSEnhancedMonitoringRole | | Dữ liệu vào CloudWatch LOGS, không phải Metrics | log group RDSOSMetrics | | Chu kỳ càng ngắn thì phí log càng cao | 1 giây tạo rất nhiều dữ liệu |

Chu kỳ 60 giây là đủ cho giám sát thường xuyên; chỉ hạ xuống 1–5 giây khi đang chẩn đoán một sự cố cụ thể.

Và Performance Insights có một tính năng rất đáng dùng: Database Load (AAS).

AAS = Average Active Sessions
    → so với số vCPU của instance
    → AAS > số vCPU nghĩa là database đang quá tải
    → biểu đồ phân tách theo loại CHỜ ĐỢI cho biết nghẽn ở đâu

Và một lời khuyên cho hệ thống đăng ký tuyển sinh như đề mô tả: tải của nó có đỉnh rất cao trong đợt tuyển sinh rồi gần như bằng không ngoài kỳ. Hãy bật Performance Insights trước mùa cao điểm (7 ngày lưu trữ là miễn phí) để có dữ liệu so sánh, thay vì bật lúc đang có sự cố khi không còn gì để đối chiếu.

Đáp án

A — Với rule MS SQL, đổi Source thành ID của security group gắn với tầng ứng dụng.

Vì sao đúng

Đề yêu cầu áp dụng nguyên tắc quyền tối thiểu cho kết nối tới cơ sở dữ liệu, và tầng ứng dụng nằm trong một Auto Scaling group.

Và đó chính là lý do phải tham chiếu theo security group thay vì theo IP:

Auto Scaling group:
    instance được TẠO và XOÁ liên tục
        → IP thay đổi liên tục
        → instance ID thay đổi liên tục
    ↓
Rule dựa trên IP hoặc instance ID sẽ HỎNG sau mỗi lần co giãn

Tham chiếu theo security group thì luôn đúng:

Source = sg-tang-ung-dung
    → bất kỳ instance nào MANG security group đó đều kết nối được
    → máy mới khởi chạy: tự động được phép
    → máy bị chấm dứt: tự động mất quyền
    → KHÔNG phải cập nhật rule bao giờ

aws ec2 authorize-security-group-ingress --group-id sg-tang-du-lieu   --protocol tcp --port 1433 --source-group sg-tang-ung-dung

Và đây cũng là quyền tối thiểu đúng nghĩa: chỉ các máy thuộc tầng ứng dụng mới vào được cổng 1433 — không phải cả subnet, không phải cả VPC, không phải 0.0.0.0/0.

(Ảnh cấu hình security group trong đề không hiển thị được ở đây, nhưng dạng câu hỏi này luôn cho thấy rule MS SQL cổng 1433 với nguồn quá rộng — thường là 0.0.0.0/0 hoặc cả dải CIDR của VPC.)

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

• **B. Đổi Source thành instance ID của các máy trong Auto Scaling group — đây là phương án gần nhất về mặt ý định thu hẹp phạm vi, nhưng nó sai về kỹ thuật và không bền: security group không chấp nhận instance ID làm nguồn — nguồn hợp lệ chỉ là CIDR, security group ID, hoặc prefix list. Và ngay cả nếu được thì instance ID thay đổi mỗi lần ASG co giãn.
• **C. Đổi Source thành địa chỉ AnyCast tĩnh gắn với tầng ứng dụng — không tồn tại trong ngữ cảnh này: địa chỉ AnyCast là khái niệm của Global Accelerator, dùng cho lưu lượng ĐI VÀO từ Internet. Instance trong ASG không có địa chỉ AnyCast để làm nguồn.
• **D. Đổi Source thành Network ACL ID — không phải giá trị hợp lệ: security group không tham chiếu được NACL. Hai cơ chế này hoạt động độc lập ở hai tầng khác nhau.

Ghi nhớ

Bốn loại nguồn hợp lệ cho security group rule: | Loại | Ví dụ | Dùng khi | |---|---|---| | CIDR block | 10.0.1.0/24, 203.0.113.5/32 | IP cố định, mạng bên ngoài | | Security group ID | sg-0abc123 | tài nguyên trong cùng VPC — bền vững nhất | | Prefix list | pl-0abc123 | nhóm CIDR quản lý tập trung | | Security group của tài khoản khác | 123456789012/sg-0abc | VPC peering |

KHÔNG hợp lệ: instance ID, NACL ID, ARN, tên miền.

Vì sao tham chiếu theo security group là thực hành tốt nhất: | Lợi ích | Chi tiết | |---|---| | Không phụ thuộc IP | máy đổi IP, thêm bớt máy — rule vẫn đúng | | Tự động áp cho instance mới | hợp với Auto Scaling | | Đọc rule là hiểu ý định kiến trúc | "tầng ứng dụng gọi được tầng dữ liệu" | | Không cần cập nhật thủ công | ít cơ hội sai sót |

Kiến trúc phân tầng chuẩn bằng security group:

sg-alb          : inbound 443 từ 0.0.0.0/0
     ↓
sg-ung-dung     : inbound 8080 từ sg-alb          ← không phải IP
     ↓
sg-du-lieu      : inbound 1433 từ sg-ung-dung     ← câu này

Mỗi tầng chỉ nhận lưu lượng từ tầng ngay trên nó — không tầng nào phơi ra rộng hơn mức cần.

Các cổng cơ sở dữ liệu thường gặp: | Cổng | Cơ sở dữ liệu | |---|---| | 1433 | Microsoft SQL Server | | 3306 | MySQL, Aurora MySQL, MariaDB | | 5432 | PostgreSQL, Aurora PostgreSQL | | 1521 | Oracle | | 6379 | Redis | | 11211 | Memcached | | 27017 | MongoDB, DocumentDB |

Ba đặc điểm của security group cần nhớ: | Đặc điểm | Chi tiết | |---|---| | Stateful | phản hồi tự động được phép — chỉ cần rule một chiều | | Chỉ có rule ALLOW | muốn chặn cụ thể thì phải dùng NACL | | Mọi rule đều được xét | không có thứ tự ưu tiên |

Và một chi tiết quan trọng: đổi rule security group KHÔNG ngắt kết nối đang mở.

Vì security group stateful, các kết nối đã thiết lập vẫn tiếp tục
    → gỡ rule không cắt được kẻ đang kết nối
    → muốn cắt ngay thì phải dùng NACL (stateless)

Ba lỗi cấu hình security group phổ biến: | Lỗi | Hậu quả | |---|---| | Cổng database mở 0.0.0.0/0 | phơi database ra Internet — lỗi nghiêm trọng nhất | | Dùng CIDR của cả VPC làm nguồn | mọi tài nguyên trong VPC vào được, kể cả máy bị xâm nhập | | Rule mở cổng 22 hoặc 3389 rộng | bị dò mật khẩu liên tục |

Công cụ phát hiện: AWS Config rule restricted-common-ports và Trusted Advisor đều kiểm tra riêng các trường hợp này.

Ba lớp bảo vệ cho tầng cơ sở dữ liệu: | Lớp | Cấu hình | |---|---| | Đặt trong PRIVATE subnet | không có route ra Internet Gateway | | Security group tham chiếu SG của tầng ứng dụng | ← câu này | | Bật mã hoã at rest và in transit | KMS + bắt buộc SSL |

Dòng đầu quan trọng không kém dòng thứ hai: security group chặt mà database nằm ở public subnet với IP công khai vẫn là thiết kế sai — một rule cấu hình nhầm là phơi ra ngay.

Và một lưu ý về Auto Scaling: hãy đảm bảo launch template gán đúng security group cho instance mới. Nếu ASG dùng template cũ với security group khác, máy mới sẽ không kết nối được database — và triệu chứng chỉ xuất hiện khi ASG mở rộng, tức là đúng lúc tải cao.

Đáp án

B — Gắn Elastic Fabric Adapter (EFA) vào mỗi EC2 instance.

Vì sao đúng

Đề nêu ba yêu cầu rất đặc thù, và cả ba đều là mô tả chính xác của EFA: | Yêu cầu | Cơ chế của EFA | |---|---| | Độ trễ thấp và thông lượng cao hơn TCP truyền thống | giao thức SRD thay cho TCP | | Tăng hiệu năng giao tiếp GIỮA CÁC INSTANCE | thiết kế cho HPC và huấn luyện phân tán | | OS-bypass: giao tiếp TRỰC TIẾP với phần cứng mạng | đặc trưng riêng chỉ EFA có |

OS-bypass là từ khoá quyết định:

Mạng thông thường (kể cả ENA):
    Ứng dụng → nhân hệ điều hành → driver → phần cứng mạng
        → mỗi lớp thêm độ trễ và tiêu tốn CPU

EFA với OS-bypass:
    Ứng dụng → THẲNG tới phần cứng mạng
        → bỏ qua nhân hệ điều hành
        → độ trễ thấp hơn nhiều, CPU rảnh để tính toán

Và EFA dùng giao thức riêng của AWS: SRD (Scalable Reliable Datagram)

SRD thay cho TCP:
    - truyền qua NHIỀU đường đồng thời (multipath)
    - phục hồi mất gói nhanh hơn
    - không đảm bảo thứ tự (ứng dụng HPC tự lo)
    → độ trễ đuôi (tail latency) thấp hơn TCP rất nhiều

Và EFA hỗ trợ các thư viện chuẩn của HPC và học sâu: | Thư viện | Dùng cho | |---|---| | MPI (Message Passing Interface) | tính toán song song truyền thống | | NCCL | huấn luyện học sâu phân tán trên nhiều GPU |

Với dự án xe tự lái dùng học sâu như đề mô tả, NCCL là thứ quyết định tốc độ huấn luyện.

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

• **A. Gắn Elastic Network Adapter (ENA) — đây là phương án gần nhất và ENA thực sự là công nghệ mạng hiệu năng cao (Enhanced Networking, tới 100 Gbps), nhưng nó KHÔNG có OS-bypass: lưu lượng vẫn đi qua nhân hệ điều hành và dùng TCP. Đề nêu đích danh yêu cầu OS-bypass. (Thực tế EFA là ENA cộng thêm khả năng OS-bypass — nó làm được mọi thứ ENA làm và nhiều hơn.)
• **C. Gắn Elastic Network Interface (ENI) — là giao diện mạng ẢO cơ bản: mọi instance đều có ít nhất một ENI. Nó không tăng tốc gì cả.
• **D. Gắn Private Virtual Interface (VIF) — sai ngữ cảnh hoàn toàn: private VIF là cấu hình của AWS Direct Connect để kết nối trung tâm dữ liệu với VPC. Nó không gắn vào EC2 instance và không liên quan tới giao tiếp giữa các instance.

Ghi nhớ

Ba loại giao diện mạng của EC2 — bảng cần thuộc: | Loại | Đặc điểm | Dùng cho | |---|---|---| | ENI (Elastic Network Interface) | giao diện mạng ảo CƠ BẢN | mọi instance đều có | | ENA (Elastic Network Adapter) | Enhanced Networking, tới 100 Gbps | workload cần băng thông cao | | EFA (Elastic Fabric Adapter) | ENA + OS-BYPASS | HPC, MPI, huấn luyện phân tán |

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

"OS-bypass"
"HPC" / "High Performance Computing"
"MPI" / "NCCL"
"inter-instance communication"
"lower latency than TCP"
"tightly coupled workload"

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

Ba yêu cầu để dùng EFA hiệu quả: | Yêu cầu | Chi tiết | |---|---| | Loại instance được hỗ trợ | c5n, m5n, r5n, p3dn, p4d, hpc6a... | | Cùng một CLUSTER PLACEMENT GROUP | OS-bypass chỉ hoạt động TRONG cùng subnet và placement group | | Cài EFA software (libfabric) | có sẵn trong AWS Deep Learning AMI | | Security group cho phép chính nó | inbound và outbound từ/tới chính security group đó |

Dòng thứ hai là hạn chế cần biết: EFA không tăng tốc lưu lượng ra Internet hay tới Region khác — nó chỉ tối ưu giao tiếp giữa các node trong cùng cụm.

Yêu cầu security group đặc biệt của EFA:

aws ec2 authorize-security-group-ingress --group-id sg-efa   --protocol -1 --source-group sg-efa
aws ec2 authorize-security-group-egress --group-id sg-efa   --protocol -1 --source-group sg-efa

Phải cho phép MỌI lưu lượng từ chính nó ở cả hai chiều — đây là cấu hình bắt buộc mà nhiều người bỏ sót.

Ba loại placement group: | Loại | Bố trí | Dùng cho | |---|---|---| | Cluster | các instance GẦN NHAU trong cùng một AZ | HPC, độ trễ thấp nhất ← câu này | | Spread | mỗi instance trên một GIÁ máy chủ khác | tối đa hoá khả năng chịu lỗi | | Partition | nhóm instance trên các phân vùng phần cứng tách biệt | HDFS, Cassandra, Kafka |

Cluster placement group là bạn đồng hành bắt buộc của EFA — nó đặt các instance trên cùng một mạng con vật lý, cho băng thông tối đa và độ trễ tối thiểu giữa chúng.

Đánh đổi của cluster placement group:

Mọi instance ở CÙNG MỘT AZ
    → độ trễ thấp nhất
    → NHƯNG mất AZ đó là mất toàn bộ cụm
→ chấp nhận được với HPC (công việc chạy lại được), không chấp nhận được với dịch vụ trực tuyến

Ba lưu ý khác về EFA: | Lưu ý | Chi tiết | |---|---| | Không tính phí thêm | chỉ trả tiền instance như bình thường | | Chỉ Linux hỗ trợ | Windows không dùng được OS-bypass | | Một EFA mỗi instance | không gắn nhiều |

Và một lời khuyên cho dự án xe tự lái như đề mô tả: bên cạnh EFA, hãy cân nhắc Amazon FSx for Lustre cho tầng lưu trữ. Huấn luyện học sâu trên khối lượng dữ liệu cảm biến khổng lồ thường bị nghẽn ở I/O chứ không phải ở mạng hay GPU — FSx for Lustre cho thông lượng hàng trăm GB/giây và liên kết trực tiếp với S3, nên dữ liệu được nạp song song thay vì tải tuần tự.

Đáp án

A và B.

• A — AWS Certificate Manager (ACM)
• B — IAM certificate store

Vì sao đúng

Đề hỏi nơi NHẬP (import) chứng chỉ SSL/TLS mua từ một CA bên thứ ba — và AWS có đúng hai kho cho việc đó.

A — ACM là nơi được khuyến nghị:

aws acm import-certificate   --certificate fileb://chung-chi.pem   --private-key fileb://khoa-rieng.pem   --certificate-chain fileb://chuoi-chung-chi.pem

Sau khi nhập, gắn vào ALB chỉ bằng một thao tác chọn — ACM tích hợp sẵn với ALB, NLB, CloudFront và API Gateway.

B — IAM certificate store là kho cũ, vẫn dùng được:

aws iam upload-server-certificate   --server-certificate-name chung-chi-ung-dung   --certificate-body file://chung-chi.pem   --private-key file://khoa-rieng.pem   --certificate-chain file://chuoi-chung-chi.pem

Vì sao IAM certificate store vẫn tồn tại: | Trường hợp | Lý do | |---|---| | Region chưa có ACM | một số Region đặc biệt | | CloudFront ở tài khoản dùng cấu hình cũ | tương thích ngược | | Tài nguyên đời cũ | ELB Classic |

Và điểm chung của cả hai: khoá riêng được lưu AN TOÀN, mã hoá, có kiểm soát truy cập bằng IAM — đó là điều mà hai phương án S3 không đảm bảo.

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

• **E. CloudFront — đây là phương án gần nhất và CloudFront thực sự DÙNG chứng chỉ, nhưng nó không phải nơi LƯU: CloudFront tham chiếu tới chứng chỉ đã nhập vào ACM (bắt buộc ở us-east-1) hoặc IAM certificate store. Nó là nơi tiêu thụ, không phải kho.
• **C. S3 bucket riêng tư có bật versioning — không phải kho chứng chỉ: bạn có thể đặt tệp ở đó về mặt kỹ thuật, nhưng ALB không đọc chứng chỉ từ S3. Và lưu khoá riêng trong S3 là thực hành kém — một cấu hình sai là lộ khoá.
• **D. S3 bucket có SSE-C — cùng vấn đề. Mã hoá không biến S3 thành kho chứng chỉ mà dịch vụ AWS đọc được.

Ghi nhớ

Hai kho chứng chỉ của AWS: | | ACM | IAM certificate store | |---|---|---| | Trạng thái | được khuyến nghị | cũ, giữ để tương thích | | Cấp chứng chỉ MỚI | ✅ miễn phí | ❌ chỉ nhập | | Tự động gia hạn | ✅ (chỉ với chứng chỉ ACM cấp) | ❌ | | Giao diện quản lý | ✅ Console đầy đủ | chỉ qua CLI/API | | Tích hợp | ALB, NLB, CloudFront, API Gateway | ELB Classic, CloudFront |

Chứng chỉ ACM cấp và chứng chỉ NHẬP vào ACM — khác biệt quan trọng: | | ACM cấp | Nhập vào ACM | |---|---|---| | Chi phí | miễn phí | phải mua từ CA | | Tự động gia hạn | ✅ | ❌ BẠN phải nhập lại thủ công | | Xuất khoá riêng | ❌ không được | ❌ không được |

Dòng thứ hai là điều quan trọng nhất phải nhớ với chứng chỉ nhập vào: ACM không gia hạn hộ chứng chỉ bạn mua từ bên ngoài. Hết hạn là website báo lỗi bảo mật.

Vì vậy hãy đặt alarm:

aws cloudwatch put-metric-alarm --alarm-name chung-chi-sap-het-han   --metric-name DaysToExpiry --namespace AWS/CertificateManager   --statistic Minimum --period 86400 --threshold 30   --comparison-operator LessThanThreshold --evaluation-periods 1   --dimensions Name=CertificateArn,Value=<arn>   --alarm-actions <arn-sns>

ACM phát metric DaysToExpiry cho cả chứng chỉ nhập vào — đây là cách duy nhất biết trước khi nó hết hạn.

Bốn thành phần khi nhập chứng chỉ: | Thành phần | Nội dung | |---|---| | Certificate body | chứng chỉ của tên miền, định dạng PEM | | Private key | khoá riêng, KHÔNG được mã hoá bằng passphrase | | Certificate chain | chứng chỉ trung gian của CA |

Lỗi hay gặp khi nhập: khoá riêng có passphrase. Phải gỡ trước:

openssl rsa -in khoa-co-mat-khau.pem -out khoa-rieng.pem

Giới hạn Region — áp cho cả chứng chỉ nhập vào: | Dùng cho | Chứng chỉ phải ở | |---|---| | ALB, NLB, API Gateway (regional) | cùng Region với tài nguyên | | CloudFront | BẮT BUỘC us-east-1 |

Ba lý do nên dùng chứng chỉ do ACM cấp thay vì mua ngoài: | Lý do | Chi tiết | |---|---| | Miễn phí | tiết kiệm hoàn toàn phí chứng chỉ | | Tự động gia hạn | không bao giờ hết hạn bất ngờ | | Khoá riêng không bao giờ rời khỏi AWS | an toàn hơn tự quản lý tệp |

Khi nào vẫn cần mua chứng chỉ bên ngoài: | Trường hợp | Lý do | |---|---| | Cần EV (Extended Validation) | ACM chỉ cấp DV (Domain Validation) | | Cần dùng chứng chỉ CẢ ngoài AWS | ACM không cho xuất khoá riêng | | Chính sách công ty yêu cầu CA cụ thể | ràng buộc tổ chức |

Ba lưu ý bảo mật về chứng chỉ: | Lưu ý | Chi tiết | |---|---| | KHÔNG BAO GIỜ đưa khoá riêng vào Git | dù repo riêng tư | | Không lưu khoá riêng trong S3 hay Parameter Store thường | dùng kho chuyên dụng | | Xoay vòng ngay nếu nghi ngờ khoá bị lộ | thu hồi chứng chỉ cũ tại CA |

Và một lưu ý về tương lai của chứng chỉ TLS: ngành đang tiến tới rút ngắn thời hạn chứng chỉ xuống 47 ngày trong vài năm tới. Với chứng chỉ mua ngoài, điều đó nghĩa là phải nhập lại rất thường xuyên — càng thêm lý do để chuyển sang chứng chỉ do ACM cấp và tự gia hạn.

Đáp án

A — 3 instance ở eu-west-1a, 3 ở eu-west-1b, và 3 ở eu-west-1c.

Vì sao đúng

Đề nêu hai ràng buộc: cần tối thiểu 6 instance, và chịu được mất một AZ, đồng thời phải RẺ NHẤT.

Kiểm tra từng phương án:

A. 3 + 3 + 3 = 9 máy
   Mất bất kỳ AZ nào → còn 6 máy   ✅ ĐỦ, tổng 9 máy

B. 6 + 6 + 6 = 18 máy
   Mất một AZ → còn 12 máy         ✅ đủ nhưng THỪA RẤT NHIỀU

C. 2 + 2 + 2 = 6 máy
   Mất một AZ → còn 4 máy          ✗ THIẾU 2

D. 6 + 6 + 0 = 12 máy
   Mất 2a hoặc 2b → còn 6 máy      ✅ đủ, nhưng tốn 12 máy

A và D đều chịu lỗi được; A dùng 9 máy còn D dùng 12 — nên A rẻ hơn 25%. B cũng chịu lỗi được nhưng dùng 18 máy — gấp đôi A.

Công thức đằng sau con số 3:

Máy mỗi AZ = ceil( N / (K − 1) )
           = ceil( 6 / (3 − 1) )
           = ceil(3) = 3
Tổng = 3 AZ × 3 máy = 9

Và đây là bài học thiết kế: dùng NHIỀU AZ hơn thì cần ÍT dự phòng hơn.

2 AZ: mỗi AZ phải gánh TOÀN BỘ tải khi AZ kia sập → 6+6 = 12 máy
3 AZ: mỗi AZ chỉ gánh thêm một nửa                → 3+3+3 = 9 máy
    → tiết kiệm 25%

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

• **D. 6 ở eu-west-1a, 6 ở eu-west-1b, 0 ở eu-west-1c — đây là phương án gần nhất và CHỊU LỖI ĐÚNG, nhưng nó đắt hơn 33%: 12 máy so với 9. Đề hỏi "most cost-effective solution which ALSO maintains the fault-tolerance" — cả hai điều kiện phải thoả, và A thoả cả hai tốt hơn.
• **C. 2 + 2 + 2 = 6 máy — rẻ nhất nhưng KHÔNG chịu lỗi: mất một AZ còn 4 máy, thiếu so với yêu cầu tối thiểu 6. Rẻ mà không đáp ứng yêu cầu thì không phải giải pháp.
• **B. 6 + 6 + 6 = 18 máy — chịu lỗi rất tốt nhưng lãng phí gấp đôi: nó dự phòng cho tình huống mất hai AZ, mà đề chỉ yêu cầu chịu được mất một.

Ghi nhớ

Công thức chịu lỗi N+1 theo AZ:

Cần N máy, có K AZ, chịu được mất 1 AZ:
    Máy mỗi AZ = ceil( N / (K − 1) )
    Tổng       = K × ceil( N / (K − 1) )

Bảng tra nhanh: | Cần | 2 AZ | 3 AZ | 4 AZ | |---|---|---|---| | 4 máy | 8 | 6 | 8 | | 6 máy | 12 | 9 ← đáp án | 8 | | 8 máy | 16 | 12 | 12 | | 9 máy | 18 | 15 | 12 | | 12 máy | 24 | 18 | 16 |

Quy tắc kiểm tra nhanh: TỔNG − (AZ đông nhất) ≥ N.

Chú ý dòng "6 máy, 4 AZ" = 8 — ít hơn cả 3 AZ. Nhưng nó đòi Region có 4 AZ, và eu-west-1 (Ireland) trong đề chỉ được nêu 3 AZ.

Ba cấu hình Auto Scaling group cho phương án A: | Cấu hình | Giá trị | |---|---| | MinSize | 9 | | DesiredCapacity | 9 | | MaxSize | cao hơn để chịu tăng tải bất ngờ | | Subnet | ba subnet ở ba AZ |

aws autoscaling create-auto-scaling-group   --auto-scaling-group-name asg-ung-dung-web   --min-size 9 --desired-capacity 9 --max-size 18   --vpc-zone-identifier "subnet-1a,subnet-1b,subnet-1c"   --health-check-type ELB --health-check-grace-period 300

ASG tự phân bổ đều giữa các AZ — không cần chỉ định số máy cho từng AZ.

Ba cơ chế của ASG hỗ trợ chịu lỗi: | Cơ chế | Việc | |---|---| | Phân bổ đều khi khởi chạy | ưu tiên AZ đang ít instance nhất | | AZ Rebalancing | tự cân bằng sau khi AZ phục hồi | | Health check kiểu ELB | thay instance mà load balancer đánh giá là hỏng |

Health check kiểu ELB là cấu hình quan trọng hay bị bỏ qua: mặc định ASG chỉ dùng EC2 status check, nên instance treo ở tầng ứng dụng nhưng máy vẫn "sống" sẽ không bị thay.

Ba cách giảm chi phí cho 9 instance chạy liên tục: | Cách | Tiết kiệm | |---|---| | Savings Plan hoặc Reserved Instance cho mức nền | tới 72% cho 9 máy chạy 24/7 | | Mixed instance policy với Spot cho phần vượt | tới 90% cho phần co giãn | | Chọn đúng kích thước instance | đo bằng Compute Optimizer |

Mức nền 9 máy là ứng viên hoàn hảo cho Savings Plan — biết chắc sẽ chạy dài hạn, biết chắc số lượng.

Ba yếu tố khác của kiến trúc chịu lỗi mà câu hỏi không nhắc: | Yếu tố | Chi tiết | |---|---| | Database phải Multi-AZ | tầng web 3 AZ mà database 1 AZ là vô nghĩa | | NAT Gateway mỗi AZ | một NAT dùng chung là điểm hỏng đơn | | Phí truyền dữ liệu giữa AZ | ~0,01 USD/GB mỗi chiều |

Và một lưu ý về dung lượng thực tế: khi một AZ sập, mọi khách hàng AWS trong Region cùng lúc cố khởi chạy instance ở các AZ còn lại. Đó là lý do nên dựng sẵn đủ 9 máy thay vì đặt 6 máy rồi trông chờ ASG mở rộng kịp — đúng như phương án A làm.

Đáp án

A — Tạo Origin Access Control (OAC) cho CloudFront và cấp cho nó quyền đọc các object trong S3 bucket.

Vì sao đúng

Đề cần phục vụ nội dung từ S3 qua CloudFront trong khi bucket KHÔNG công khai — và OAC là cơ chế chính thức cho đúng việc đó.

Cách hoạt động:

CloudFront gửi request tới S3
    → KÝ request bằng SigV4 với danh tính OAC
    ↓
Bucket policy cho phép service principal cloudfront.amazonaws.com
    → và kiểm tra đúng distribution nào
    ↓
S3 trả nội dung
    → người dùng gọi THẲNG S3 thì bị 403

Bucket policy tương ứng:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::kho-video-dao-tao/*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1ABC"}}}

Điều kiện AWS:SourceArn rất quan trọng: không có nó thì bất kỳ distribution CloudFront nào của bất kỳ ai cũng đọc được bucket.

Và phải bật Block Public Access để bịt đường đi vòng:

Không bật:
    Người dùng → CloudFront → S3   ✅ (đường mong muốn)
    Người dùng ─────────────→ S3   ✅ (đường VÒNG, bỏ qua CloudFront)

Bật Block Public Access + OAC:
    Người dùng ─────────────→ S3   ❌ 403 Access Denied

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

• **C. Tạo bucket policy liệt kê CloudFront distribution ID làm principal và bucket làm ARN — đây là phương án gần nhất và gần đúng về ý tưởng, nhưng nó sai về cú pháp IAM: distribution ID không phải là một principal hợp lệ. Principal đúng là service principal cloudfront.amazonaws.com, còn distribution ARN được kiểm tra qua điều kiện AWS:SourceArn, không phải qua trường Principal.
• **B. Tạo một IAM user cho CloudFront và cấp quyền cho user đó — sai mô hình danh tính: CloudFront là dịch vụ của AWS, nó không dùng IAM user. Và tạo IAM user với access key dài hạn cho việc này là thực hành bảo mật kém.
• **D. Tạo web ACL trong AWS WAF để chặn truy cập công khai vào S3 rồi gắn vào CloudFront — sai vai trò của WAF: WAF lọc request ĐI QUA CloudFront hoặc ALB. Nó không kiểm soát được ai gọi thẳng vào endpoint của S3 — request đó không đi qua WAF chút nào.

Ghi nhớ

OAC và OAI — bảng phân biệt: | | OAC (Origin Access Control) | OAI (Origin Access Identity) | |---|---|---| | Trạng thái | hiện hành, được khuyến nghị | cũ, chỉ giữ để tương thích | | Bucket mã hoá SSE-KMS | ✅ hỗ trợ | ❌ KHÔNG | | Origin không phải S3 | ✅ (Lambda URL, MediaStore, MediaPackage) | ❌ | | Phương thức HTTP | đủ GET, PUT, POST, DELETE | chỉ GET, HEAD | | Ký request | SigV4 | SigV4 | | Hỗ trợ mọi Region | ✅ | hạn chế |

Nếu bucket dùng SSE-KMS thì BẮT BUỘC dùng OAC — OAI không ký được request tới KMS. Đây là lý do phổ biến nhất khiến người ta phải chuyển từ OAI sang OAC.

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

① Tạo Origin Access Control trong CloudFront
② Gắn OAC vào origin S3 của distribution
③ Cập nhật bucket policy cho phép service principal + SourceArn

aws cloudfront create-origin-access-control   --origin-access-control-config '{
    "Name": "oac-video-dao-tao",
    "OriginAccessControlOriginType": "s3",
    "SigningBehavior": "always",
    "SigningProtocol": "sigv4"}'

Ba lớp bảo vệ nội dung riêng tư qua CloudFront: | Lớp | Cơ chế | Bảo vệ khỏi | |---|---|---| | ① Chặn truy cập trực tiếp vào S3 | Block Public Access + OAC | người gọi thẳng S3 | | ② Kiểm soát ai xem được qua CloudFront | signed URL hoặc signed cookie | người không được cấp quyền | | ③ Hạn chế theo địa lý | geo restriction | truy cập từ vùng cấm |

Thiếu lớp ① thì lớp ② vô dụng — người ta chỉ cần lấy URL S3 trực tiếp là bỏ qua mọi kiểm soát của CloudFront.

(Đề chỉ hỏi về lớp ①. Với video đào tạo nội bộ của công ty, lớp ② cũng nên có — nếu không thì ai biết URL CloudFront đều xem được.)

Signed URL và signed cookie: | | Signed URL | Signed cookie | |---|---|---| | Phạm vi | một tệp | nhiều tệp theo mẫu đường dẫn | | URL thay đổi | ✅ | ❌ giữ nguyên | | Phù hợp | link chia sẻ một tệp | thư viện video, streaming |

Với thư viện video đào tạo, signed cookie tiện hơn — cấp một lần rồi nhân viên xem được cả bộ.

S3 pre-signed URL và CloudFront signed URL — đừng nhầm: | | S3 pre-signed | CloudFront signed | |---|---|---| | Trỏ tới | THẲNG vào S3 | qua CloudFront | | Tận dụng cache biên | ❌ | ✅ | | Ký bằng | thông tin đăng nhập IAM | cặp khoá riêng của CloudFront |

Với công ty truyền thông toàn cầu như đề mô tả, đi qua CloudFront quan trọng: video được cache tại điểm biên gần nhân viên, nên nhân viên ở châu Á không phải tải từ Region gốc ở Mỹ.

Ba cấu hình CloudFront nên có cho phân phối video: | Cấu hình | Lý do | |---|---| | Origin Shield | giảm tải origin — nhiều điểm biên chỉ gọi qua một lớp trung gian | | Cache policy TTL dài | video không đổi, cache càng lâu càng tốt | | Compression | ít tác dụng với video đã nén, nhưng hữu ích cho manifest và phụ đề |

Và một lưu ý về định dạng: nếu là video dài, hãy dùng HLS hoặc DASH thay vì một tệp MP4 lớn. Video được chia thành nhiều đoạn nhỏ, mỗi đoạn cache riêng, người xem tua giữa chừng không phải tải lại từ đầu — và chất lượng tự thích ứng theo băng thông của từng người.

Đáp án

C — Tạo EventBridge rule bắt sự kiện của AWS Personal Health Dashboard liên quan tới EC2 instance; đặt SNS topic làm đích để gửi thông báo.

Vì sao đúng

Đề cần được báo trước về các sự kiện AWS SẮP TỚI có ảnh hưởng tới CHÍNH các instance của mình — và Personal Health Dashboard là nguồn thông tin đó.

Phân biệt hai dashboard — đây là điểm mấu chốt: | | Service Health Dashboard | Personal Health Dashboard | |---|---|---| | Phạm vi | trạng thái CHUNG của dịch vụ AWS | tài nguyên CỦA BẠN | | Nội dung | "S3 ở us-east-1 đang có sự cố" | "instance i-0abc của bạn sẽ được bảo trì lúc..." | | Cá nhân hoá | ❌ giống nhau với mọi khách hàng | ✅ riêng cho tài khoản bạn | | Báo TRƯỚC sự kiện theo lịch | ❌ | ✅ |

Đề nói "upcoming AWS events that may affect THESE EC2 instances" — cụ thể tới từng instance, nên chỉ PHD trả lời được.

Các loại sự kiện PHD báo về EC2: | Loại | Ý nghĩa | |---|---| | AWS_EC2_INSTANCE_RETIREMENT_SCHEDULED | instance sẽ bị ngừng do phần cứng nền có vấn đề | | AWS_EC2_INSTANCE_REBOOT_MAINTENANCE_SCHEDULED | bảo trì cần khởi động lại | | AWS_EC2_SYSTEM_MAINTENANCE_SCHEDULED | bảo trì hệ thống | | AWS_EC2_INSTANCE_STOP_SCHEDULED | instance sẽ bị dừng | | AWS_EC2_PERSISTENT_INSTANCE_RETIREMENT_SCHEDULED | với instance store |

Và loại đầu tiên chính là nguyên nhân của sự cố mà đề mô tả — instance đột ngột tắt thường là do phần cứng nền hỏng và AWS đã lên lịch ngừng nó.

EventBridge rule:

{"source": ["aws.health"],
 "detail-type": ["AWS Health Event"],
 "detail": {
   "service": ["EC2"],
   "eventTypeCategory": ["scheduledChange", "issue"]}}

aws events put-rule --name canh-bao-suc-khoe-ec2   --event-pattern file://mau-su-kien.json
aws events put-targets --rule canh-bao-suc-khoe-ec2   --targets "Id"="1","Arn"="arn:aws:sns:ap-southeast-1:123456789012:canh-bao"

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

• **D. EventBridge rule bắt sự kiện của Service Health Dashboard — đây là phương án gần nhất và có cấu trúc giải pháp hoàn toàn đúng, nhưng nó sai nguồn sự kiện: Service Health Dashboard báo tình trạng chung của dịch vụ, không báo về instance cụ thể của bạn. (Và về mặt kỹ thuật, sự kiện Health trong EventBridge đến từ PHD; SHD là trang web trạng thái công khai, không phát sự kiện vào EventBridge của bạn.)
• **A. EventBridge rule chạy mỗi 24 giờ gọi Lambda kiểm tra Service Health Dashboard — sai nguồn và nhiều công: vẫn là SHD, cộng thêm phải viết và bảo trì Lambda cho việc mà PHD đã đẩy sự kiện tự động. Và chu kỳ 24 giờ có thể bỏ lỡ thông báo gấp.
• **B. EventBridge rule bắt thay đổi trạng thái instance rồi Lambda khởi động lại máy — phản ứng SAU khi đã hỏng: đề muốn biết TRƯỚC về sự kiện sắp tới, không phải xử lý hậu quả. Và khởi động lại một instance đã bị AWS ngừng vì lỗi phần cứng thường không giải quyết được gì.

Ghi nhớ

Ba nguồn thông tin về sức khoẻ hệ thống AWS: | Nguồn | Cho biết | |---|---| | Service Health Dashboard | tình trạng CHUNG của dịch vụ ở từng Region | | Personal Health Dashboard (AWS Health) | sự kiện ảnh hưởng tới TÀI NGUYÊN CỦA BẠN | | CloudWatch | số liệu hiệu năng của tài nguyên |

Ba danh mục sự kiện của AWS Health: | Danh mục | Ý nghĩa | |---|---| | issue | sự cố đang diễn ra | | scheduledChange | thay đổi ĐÃ LÊN LỊCH — báo trước ← đề cần cái này | | accountNotification | thông báo về tài khoản |

Ba trạng thái của sự kiện:

open       → đang diễn ra
upcoming   → sắp xảy ra theo lịch
closed     → đã kết thúc

Cách xử lý khi nhận thông báo INSTANCE_RETIREMENT_SCHEDULED: | Loại instance | Cách xử lý | |---|---| | EBS-backed | dừng rồi khởi động lại → chuyển sang máy chủ vật lý khác | | Instance store-backed | phải khởi chạy instance MỚI — dữ liệu cục bộ sẽ MẤT |

Dòng đầu là mẹo quan trọng: stop/start (không phải reboot) đưa instance sang phần cứng mới, giải quyết dứt điểm cảnh báo ngừng hoạt động.

Ba cách nhận thông báo từ AWS Health: | Cách | Đặc điểm | |---|---| | EventBridge rule → SNS | tự động, thời gian thực ← câu này | | Email tới địa chỉ liên hệ của tài khoản | mặc định, dễ bị bỏ qua | | AWS Health API | cần gói hỗ trợ Business trở lên |

Lưu ý về AWS Health API: truy vấn chủ động qua API đòi gói Business, Enterprise On-Ramp hoặc Enterprise. Nhưng sự kiện qua EventBridge thì có ở MỌI gói — nên phương án trong đề dùng được cho cả tài khoản gói Basic.

Và với "ứng dụng quan trọng" như đề mô tả, hãy làm nhiều hơn là chỉ nhận thông báo: | Biện pháp | Lý do | |---|---| | Đặt instance trong Auto Scaling group | máy hỏng được thay TỰ ĐỘNG, không cần người can thiệp | | Trải qua nhiều AZ | một AZ sập không làm mất dịch vụ | | Bật CloudWatch alarm với hành động recover | tự di chuyển instance sang host khác khi phần cứng lỗi |

Hành động recover của CloudWatch alarm rất phù hợp cho instance đơn lẻ không nằm trong ASG:

aws cloudwatch put-metric-alarm --alarm-name tu-phuc-hoi-instance   --metric-name StatusCheckFailed_System --namespace AWS/EC2   --statistic Maximum --period 60 --threshold 1   --comparison-operator GreaterThanOrEqualToThreshold --evaluation-periods 2   --dimensions Name=InstanceId,Value=i-0abc123   --alarm-actions arn:aws:automate:ap-southeast-1:ec2:recover

Nó giữ nguyên instance ID, IP riêng, Elastic IP và metadata — chỉ chuyển sang phần cứng khác.

Và một nhận xét về kiến trúc trong đề: "một tập EC2 instance CỐ ĐỊNH chạy ứng dụng quan trọng" là mô hình mong manh. Nhận thông báo sớm là cải thiện tốt, nhưng giải pháp căn bản là để Auto Scaling group quản lý các instance đó — khi ấy một máy bị AWS ngừng chỉ là một sự kiện thay máy bình thường, không phải sự cố.

Đáp án

A — Bật tính năng Requester Pays trên S3 bucket.

Vì sao đúng

Đề nêu hai yêu cầu, và Requester Pays giải đúng cả hai cùng lúc: | Yêu cầu | Cơ chế | |---|---| | GIẢM chi phí truyền dữ liệu cho startup | NGƯỜI TẢI trả phí truyền, không phải chủ bucket | | Vô hiệu hoá truy cập ẩn danh | Requester Pays BẮT BUỘC người gọi phải xác thực |

Cách hoạt động:

Bình thường:
    Chủ bucket trả PHÍ LƯU TRỮ + PHÍ TRUYỀN DỮ LIỆU RA

Requester Pays:
    Chủ bucket trả PHÍ LƯU TRỮ
    NGƯỜI TẢI trả PHÍ REQUEST + PHÍ TRUYỀN DỮ LIỆU

Với 5 TB dữ liệu tải từ Mỹ sang châu Âu, khoản tiết kiệm là đáng kể:

5 TB × ~0,09 USD/GB = ~460 USD mỗi lần tải toàn bộ
    → chuyển sang cho đối tác trả

Và vế "disable anonymous access" được đáp ứng như một hệ quả tự nhiên:

Requester Pays cần biết TÍNH PHÍ CHO AI
    → mọi request phải được XÁC THỰC
    → request ẩn danh bị TỪ CHỐI tự động

aws s3api put-bucket-request-payment --bucket kho-bat-dong-san   --request-payment-configuration Payer=Requester

Người tải phải khai rõ là họ chấp nhận trả:

aws s3 cp s3://kho-bat-dong-san/du-lieu.csv . --request-payer requester

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

• **C. Bật cross-account access cho bucket của startup để đối tác tải xuống — đây là phương án gần nhất và giải quyết được phần truy cập, nhưng nó không giảm chi phí gì: với cross-account access thông thường, chủ bucket vẫn trả toàn bộ phí truyền dữ liệu. Đề nhấn mạnh "keep its data transfer costs as low as possible".
• **B. Bật Cross-Region Replication để tự sao chép sang bucket của đối tác ở châu Âu — tốn kém hơn hẳn: startup phải trả phí truyền dữ liệu xuyên Region cho toàn bộ 5 TB, cộng phí request sao chép. Nó làm tăng chi phí thay vì giảm.
• **D. Bật S3 Object Lock ở chế độ governance và đặt Legal Hold để giảm phí truyền và chặn truy cập ẩn danh — hoàn toàn nhầm chức năng: Object Lock là cơ chế CHỐNG XOÁ dữ liệu. Nó không ảnh hưởng gì tới chi phí truyền và không kiểm soát truy cập ẩn danh.

Ghi nhớ

Ai trả gì trong Requester Pays: | Khoản | Bình thường | Requester Pays | |---|---|---| | Lưu trữ | chủ bucket | chủ bucket | | Request (GET, PUT...) | chủ bucket | NGƯỜI GỌI | | Truyền dữ liệu RA | chủ bucket | NGƯỜI GỌI |

Bốn đặc điểm của Requester Pays: | Đặc điểm | Chi tiết | |---|---| | Chặn truy cập ẩn danh | request không xác thực bị từ chối | | Người gọi phải khai x-amz-request-payer: requester | thiếu header thì nhận 403 | | Không áp cho chính chủ bucket | chủ vẫn trả như bình thường khi tự truy cập | | Không dùng được với BitTorrent | tính năng cũ đã ngừng |

Ba trường hợp dùng điển hình: | Trường hợp | Lý do | |---|---| | Chia sẻ dữ liệu với đối tác | ← câu này | | Bộ dữ liệu công cộng lớn | người dùng trả phí truy cập, chủ không gánh | | Dữ liệu nghiên cứu dùng chung | phân bổ chi phí công bằng |

Chi phí truyền dữ liệu của S3 — cần thuộc: | Hướng | Chi phí | |---|---| | VÀO S3 (upload) | MIỄN PHÍ | | RA Internet | ~0,09 USD/GB (giảm dần theo khối lượng) | | Sang Region khác | ~0,02 USD/GB | | Sang EC2 CÙNG Region | MIỄN PHÍ | | Sang CloudFront | MIỄN PHÍ |

Hai dòng "miễn phí" cuối là kiến thức tối ưu chi phí quan trọng nhất về S3.

Và có một lựa chọn thay thế đáng cân nhắc: phân phối qua CloudFront.

S3 → CloudFront: MIỄN PHÍ
CloudFront → người dùng: rẻ hơn S3 → Internet trực tiếp
    → và đối tác ở châu Âu được phục vụ từ điểm biên gần họ

(Requester Pays vẫn là đáp án đúng vì nó chuyển hẳn chi phí sang đối tác; CloudFront chỉ giảm chi phí.)

Ba cách chia sẻ dữ liệu S3 với tài khoản khác: | Cách | Đặc điểm | |---|---| | Bucket policy cấp quyền cho tài khoản đối tác | đơn giản nhất | | IAM role cho đối tác đảm nhận | kiểm soát chi tiết hơn | | S3 Access Point | chính sách riêng cho từng nhóm người dùng |

S3 Access Point đáng biết khi có nhiều đối tác: 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.

Bucket policy kết hợp với Requester Pays:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
 "Action": ["s3:GetObject", "s3:ListBucket"],
 "Resource": ["arn:aws:s3:::kho-bat-dong-san",
              "arn:aws:s3:::kho-bat-dong-san/*"]}

Requester Pays quyết định AI TRẢ TIỀN; bucket policy quyết định AI ĐƯỢC TRUY CẬP — cần cả hai.

Ba lưu ý khi bật Requester Pays: | Lưu ý | Chi tiết | |---|---| | Ứng dụng cũ có thể hỏng | thiếu header request-payer là nhận 403 | | Không dùng được với truy cập ẩn danh | website tĩnh trên bucket đó sẽ ngừng hoạt động | | Đối tác phải có tài khoản AWS | không chia sẻ được với người không dùng AWS |

Và một cân nhắc cho tình huống của đề: nếu đối tác cần toàn bộ 5 TB một lần rồi thôi, hãy cân nhắc S3 Batch Replication sang bucket của họ — đối tác trả phí lưu trữ, và chi phí một lần có thể rẻ hơn việc họ tải đi tải lại nhiều lần. Nếu họ cần truy cập chọn lọc và thường xuyên thì Requester Pays là lựa chọn đúng.

Đáp án

B — Cài AWS Replication Agent trên mỗi máy ảo tại chỗ để sao chép liên tục lên AWS; dùng AWS Application Migration Service (AWS MGN) để khởi chạy instance kiểm thử và thực hiện cắt chuyển sau khi kiểm thử xong.

Vì sao đúng

Đề nêu ba yêu cầu, và MGN là dịch vụ được AWS thiết kế cho đúng tình huống này: | Yêu cầu | Cơ chế | |---|---| | Chiến lược "lift-and-shift", ít thay đổi ứng dụng | sao chép nguyên khối đĩa — ứng dụng không biết gì | | GIẢM THIỂU thời gian ngừng | sao chép LIÊN TỤC trong khi máy nguồn vẫn chạy | | Cả Linux lẫn Windows | agent hỗ trợ cả hai |

Cách MGN giảm thời gian ngừng xuống mức tối thiểu:

① Cài Replication Agent trên máy ảo tại chỗ
    → máy VẪN CHẠY BÌNH THƯỜNG, không gián đoạn
② Sao chép khối đĩa liên tục theo thời gian thực (CDC)
    → mọi thay đổi được đồng bộ sang AWS
③ Khởi chạy INSTANCE KIỂM THỬ bất cứ lúc nào
    → kiểm tra ứng dụng chạy đúng trên AWS
    → máy gốc vẫn phục vụ người dùng
④ Cắt chuyển: dừng ứng dụng ở nguồn, chờ đồng bộ nốt,
   khởi chạy instance chính thức
    → thời gian ngừng chỉ VÀI PHÚT

Và bước ③ là điểm mạnh lớn nhất: bạn kiểm thử được nhiều lần trước khi cắt chuyển thật, không phải đánh cược vào một lần duy nhất.

AWS MGN là dịch vụ MIỄN PHÍ trong 90 ngày cho mỗi máy chủ — chỉ trả tiền cho tài nguyên AWS mà bản sao chép sử dụng.

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

• **A. Xuất máy ảo, tải ảnh lên S3, dùng VM Import/Export — đây là phương án gần nhất và thực sự làm được lift-and-shift, nhưng nó có thời gian ngừng RẤT DÀI: phải tắt máy ảo, xuất ảnh (hàng chục GB tới hàng TB), tải lên S3, chờ nhập. Với mỗi máy trong số nhiều máy legacy, quá trình này mất hàng giờ tới hàng ngày. Và không có cơ chế đồng bộ thay đổi phát sinh trong lúc đó.
• **C. Dùng AWS Application Discovery Service cho việc di chuyển lift-and-shift — sai vai trò dịch vụ: Application Discovery Service KHÁM PHÁ và LẬP DANH MỤC máy chủ tại chỗ (cấu hình, hiệu năng, quan hệ phụ thuộc). Nó là bước lập kế hoạch TRƯỚC khi di chuyển, nó không sao chép hay di chuyển gì cả.
• **D. Dùng AWS DataSync để di chuyển workload — sai loại dữ liệu: DataSync đồng bộ TỆP và OBJECT giữa các hệ thống lưu trữ (NFS, SMB, S3, EFS, FSx). Nó không sao chép nguyên máy chủ thành AMI khởi chạy được.

Ghi nhớ

Các dịch vụ di chuyển của AWS — mỗi cái một giai đoạn: | Dịch vụ | Giai đoạn | Việc | |---|---|---| | Application Discovery Service | ① Khám phá | lập danh mục máy chủ, đo hiệu năng, tìm phụ thuộc | | Migration Hub | ② Lập kế hoạch | theo dõi tiến độ di chuyển tập trung | | Application Migration Service (MGN) | ③ Di chuyển | lift-and-shift máy chủ, ít gián đoạn ← câu này | | Database Migration Service (DMS) | ③ Di chuyển | cơ sở dữ liệu, ít gián đoạn | | DataSync | ③ Di chuyển | tệp và object | | Snow Family | ③ Di chuyển | khối lượng rất lớn, băng thông kém |

Quy tắc nhận diện:

"lift-and-shift", "rehost", "minimize downtime", "server migration" → AWS MGN "database migration", "minimal downtime" → AWS DMS "file share", "NFS", "SMB", "sync" → DataSync "discover", "inventory", "assess", "dependency" → Application Discovery Service

Bảy chiến lược di chuyển (7 R): | Chiến lược | Nghĩa | |---|---| | Rehost (lift-and-shift) | chuyển nguyên trạng, không sửa gì ← đề này | | Replatform | sửa nhẹ để tận dụng dịch vụ đám mây (ví dụ chuyển DB sang RDS) | | Refactor | viết lại cho kiến trúc đám mây | | Repurchase | chuyển sang giải pháp SaaS | | Retire | ngừng hẳn ứng dụng không cần | | Retain | giữ lại tại chỗ | | Relocate | chuyển nguyên cụm VMware sang VMware Cloud on AWS |

Rehost là chiến lược nhanh nhất và ít rủi ro nhất — phù hợp khi cần rời trung tâm dữ liệu gấp. Tối ưu hoá (replatform, refactor) làm sau khi đã lên đám mây.

Ba giai đoạn của MGN: | Giai đoạn | Việc | |---|---| | Replication | sao chép liên tục, máy nguồn vẫn chạy | | Testing | khởi chạy instance kiểm thử — làm nhiều lần được | | Cutover | chuyển sang dùng thật |

Sau cắt chuyển vẫn giữ được khả năng quay lui trong một thời gian — máy nguồn chưa bị xoá.

Ba lưu ý khi dùng MGN: | Lưu ý | Chi tiết | |---|---| | Cần cổng 1500 TCP từ máy nguồn tới AWS | cho lưu lượng sao chép | | Máy nguồn cần dung lượng đĩa trống | cho quá trình sao chép | | Cấu hình launch template trước khi cắt chuyển | loại instance, subnet, security group |

Và MGN cho phép "right-sizing" ngay khi di chuyển: instance đích không nhất thiết phải cùng cấu hình với máy vật lý cũ — đây là cơ hội tốt để giảm chi phí, vì máy chủ tại chỗ thường được mua dư công suất.

Ba việc nên làm trước khi di chuyển: | Việc | Lý do | |---|---| | Chạy Application Discovery Service | hiểu ứng dụng nào phụ thuộc ứng dụng nào | | Nhóm các máy phụ thuộc nhau thành một đợt | cắt chuyển cùng lúc, tránh gọi chéo qua Internet | | Kiểm kê giấy phép phần mềm | Windows Server, SQL Server có thể mang theo (BYOL) hoặc mua kèm |

Dòng thứ hai quan trọng với ứng dụng legacy: chúng thường gọi lẫn nhau qua tên máy hoặc IP cố định. Chuyển một máy mà để máy phụ thuộc ở lại tại chỗ sẽ tạo ra độ trễ lớn và chi phí truyền dữ liệu — hoặc đơn giản là hỏng.

Và một lời khuyên về thứ tự: hãy di chuyển một ứng dụng ít quan trọng trước để đội ngũ làm quen quy trình và phát hiện những chỗ vướng, rồi mới tới các hệ thống quan trọng. MGN cho phép kiểm thử nhiều lần mà không ảnh hưởng máy nguồn — hãy tận dụng điều đó thay vì cắt chuyển ngay lần đầu.

Đáp án

D — Dữ liệu bị xoá tự động.

Vì sao đúng

Đề cho một chi tiết quyết định: instance dùng Instance Store-Backed AMI — nghĩa là root volume nằm trên đĩa vật lý của máy chủ, không phải EBS.

Và instance store là bộ nhớ TẠM THỜI (ephemeral):

Instance store = đĩa gắn TRỰC TIẾP vào máy chủ vật lý
    ↓
Instance bị chấm dứt (terminate)
    → instance rời khỏi máy chủ đó
    → dữ liệu trên đĩa cục bộ BỊ XOÁ HOÀN TOÀN
    → KHÔNG có cách nào khôi phục

Và AWS không tự sao lưu gì cả — đó là lý do hai phương án nói về snapshot và volume đều sai.

Bảng hành vi đầy đủ của instance store: | Thao tác | Dữ liệu instance store | |---|---| | Reboot | GIỮ (vẫn cùng máy chủ vật lý) | | Stop | MẤT (và instance store-backed AMI không stop được) | | Terminate | MẤT | | Lỗi phần cứng nền | MẤT |

Chú ý dòng đầu: reboot không mất dữ liệu — instance vẫn ở nguyên chỗ cũ. Chỉ khi rời khỏi máy chủ vật lý mới mất.

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

• **A. Dữ liệu tự động lưu thành EBS snapshot — đây là phương án gần nhất và là điều nhiều người mong đợi, nhưng AWS không làm điều đó: không có cơ chế tự chụp snapshot khi chấm dứt instance. Và snapshot vốn là tính năng của EBS, không áp cho instance store.
• **B. Dữ liệu tự động lưu thành EBS volume — cùng lý do: không có chuyển đổi tự động nào từ instance store sang EBS.
• **C. Dữ liệu không truy cập được cho tới khi khởi động lại instance — hiểu sai bản chất terminate: chấm dứt là vĩnh viễn. Instance đã terminate không khởi động lại được — nó không còn tồn tại.

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ủ | lưu trữ qua mạng | | Bền vững qua stop/start | ❌ MẤT | ✅ | | Snapshot | ❌ | ✅ | | Hiệu năng | cao hơn — không qua mạng | rất tốt (io2 tới 256.000 IOPS) | | Chi phí | bao gồm trong giá instance | tính riêng | | Gắn vào instance khác | ❌ | ✅ |

Instance store-backed AMI và EBS-backed AMI: | | Instance store-backed | EBS-backed | |---|---|---| | Root volume | instance store | EBS | | STOP được | ❌ chỉ reboot hoặc terminate | ✅ | | Thời gian khởi động | chậm hơn (tải AMI từ S3) | nhanh | | Đổi loại instance | ❌ | ✅ (khi đang stopped) | | Dữ liệu sống sót | ❌ | ✅ | | Trạng thái | cũ, hiếm dùng | tiêu chuẩn hiện nay |

Gần như mọi AMI hiện nay đều là EBS-backed — instance store-backed là di sản từ thời kỳ đầu của EC2. Đề nêu rõ loại này chính là để kiểm tra hiểu biết về sự khác biệt.

Ba trường hợp instance store VẪN hữu ích: | Trường hợp | Lý do | |---|---| | Bộ nhớ đệm, dữ liệu tạm | mất cũng không sao | | Không gian scratch cho xử lý dữ liệu | I/O rất cao | | Cụm NoSQL tự sao chép dữ liệu | Cassandra, Elasticsearch — mất một node không mất dữ liệu |

Loại instance có instance store NVMe cho hiệu năng rất cao: i3, i4i, d3, im4gn — chúng đạt hàng triệu IOPS, vượt xa EBS.

Bảng dữ liệu nào sống sót qua thao tác nào: | Thao tác | Instance store | EBS root | EBS phụ | Elastic IP | |---|---|---|---|---| | Reboot | GIỮ | giữ | giữ | giữ | | Stop/Start | MẤT | giữ | giữ | giữ | | Terminate | MẤT | tuỳ DeleteOnTermination | thường giữ | tách ra | | Hibernate | MẤT | giữ | giữ | giữ |

DeleteOnTermination mặc định:

Root volume:        true   → bị xoá cùng instance
Volume phụ:         false  → sống sót

Ba cách bảo vệ dữ liệu trên EC2: | Cách | Chi tiết | |---|---| | Không lưu dữ liệu quan trọng trên instance | thiết kế tốt nhất — dùng S3, EFS, RDS | | Dùng EBS với DeleteOnTermination = false | volume sống sót | | Chụp snapshot định kỳ bằng Data Lifecycle Manager | tự động hoá |

Dòng đầu là nguyên tắc kiến trúc quan trọng nhất: instance nên không lưu trạng thái. Khi ấy chấm dứt một instance là chuyện bình thường, không phải sự kiện đáng lo.

Nơi lưu trạng thái đúng: | Loại dữ liệu | Nơi lưu | |---|---| | Tệp người dùng | S3 hoặc EFS | | Phiên đăng nhập | ElastiCache hoặc DynamoDB | | Dữ liệu ứng dụng | RDS, Aurora, DynamoDB | | Log | CloudWatch Logs hoặc S3 |

Và một lời khuyên cho tình huống của đề: trước khi chấm dứt instance để ngừng ứng dụng legacy, hãy kiểm tra xem có dữ liệu nào cần giữ lại trên root volume không — cấu hình, log, tệp do người dùng tải lên. Với instance store-backed, không có cách nào lấy lại sau khi terminate. Sao chép những gì cần sang S3 trước là bước không thể bỏ qua.