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

Đáp án

C — Dùng Kinesis Data Streams ở chế độ on-demand để nạp dữ liệu tương tác người dùng, cấu hình Lambda làm consumer xử lý sự kiện theo thời gian thực.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án C đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Nạp và phân tích THỜI GIAN THỰC | Kinesis độ trễ dưới một giây | | Đỉnh tải KHÔNG ĐOÁN TRƯỚC | on-demand tự co giãn | | SERVERLESS | on-demand không quản shard, Lambda không quản máy | | Không cấp phát thủ công | ← đúng nghĩa on-demand |

Chế độ on-demand là điểm quyết định:

Kinesis provisioned:
    → phải khai SỐ SHARD
    → tải tăng vượt dự tính → bị throttle
    → phải theo dõi và điều chỉnh thủ công

Kinesis on-demand:
    → tự co giãn tới 200 MB/giây
    → tự thích ứng tới GẤP ĐÔI đỉnh 30 ngày trước
        ↓
    Đúng "seamlessly adjust without manual provisioning"

Tạo stream:

aws kinesis create-stream --stream-name su-kien-nguoi-dung   --stream-mode-details StreamMode=ON_DEMAND

Và gắn Lambda làm consumer:

aws lambda create-event-source-mapping   --function-name xu-ly-su-kien   --event-source-arn <arn-stream>   --starting-position LATEST   --batch-size 100 --maximum-batching-window-in-seconds 1   --parallelization-factor 4

maximum-batching-window-in-seconds 1 giữ độ trễ thấp — Lambda không chờ đầy lô mới xử lý.

Và vì sao Data Streams chứ không phải Firehose:

Data Streams:
    ✓ độ trễ dưới một giây
    ✓ NHIỀU consumer đọc độc lập
    ✓ giữ dữ liệu 1–365 ngày, phát lại được
        ↓
Firehose:
    ✗ độ trễ tối thiểu ~60 giây
    ✗ không giữ lại, không phát lại
    ✗ không cho ứng dụng đọc trực tiếp

Với "analyzed in REAL TIME", độ trễ 60 giây của Firehose không đạt.

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

• **D. Dùng Kinesis Data Firehose nạp vào S3, dùng Athena với truy vấn theo lịch — đây là phương án gần nhất và cũng là đường ống serverless hợp lệ, nhưng nó KHÔNG phải thời gian thực: Firehose đệm tối thiểu 60 giây, và truy vấn theo lịch còn thêm độ trễ nữa. Đề nói rõ "ingested and analyzed in REAL TIME".
• **A. EC2 chạy Apache Kafka, script tự viết co giãn cụm theo CPU — hoàn toàn không serverless: phải vận hành cụm Kafka, tự viết logic co giãn. Đi ngược yêu cầu rõ ràng nhất của đề.
• **B. SNS phát sự kiện, SQS nhận, Glue job theo lịch xử lý — xử lý theo lô, không thời gian thực: Glue chạy theo khoảng cố định. Và SNS không giữ dữ liệu, không phát lại được.

Ghi nhớ

Ba dịch vụ luồng dữ liệu của AWS — bảng phải thuộc: | Dịch vụ | Độ trễ | Giữ dữ liệu | Nhiều consumer | |---|---|---|---| | Kinesis Data Streams | dưới 1 giây | 1–365 ngày | ✅ | | Kinesis Data Firehose | ~60 giây trở lên | ❌ | ❌ | | Amazon MSK | dưới 1 giây | theo cấu hình | ✅ |

Từ khoá nhận diện:

"real time", "multiple consumers", "replay" → Data Streams "load into S3/Redshift/OpenSearch", "no code" → Firehose "existing Kafka" → MSK

Hai chế độ dung lượng của Kinesis Data Streams: | | Provisioned | On-demand | |---|---|---| | Quản shard | ✅ phải khai | ❌ tự động | | Giới hạn | theo số shard | 200 MB/giây, 200.000 bản ghi/giây | | Chi phí khi tải ổn định | thấp hơn | cao hơn | | Phù hợp | tải đã biết | tải khó đoán ← câu này |

Đổi chế độ được:

aws kinesis update-stream-mode --stream-arn <arn>   --stream-mode-details StreamMode=PROVISIONED

Tối đa hai lần mỗi 24 giờ.

Giới hạn của một shard (chế độ provisioned): | Chiều | Giới hạn | |---|---| | Ghi | 1.000 bản ghi/giây HOẶC 1 MB/giây | | Đọc chia sẻ | 2 MB/giây, 5 GetRecords/giây | | Enhanced fan-out | 2 MB/giây riêng mỗi consumer |

Ba lưu ý về Lambda đọc từ Kinesis: | Lưu ý | Chi tiết | |---|---| | Một Lambda mỗi shard (mặc định) | | | ParallelizationFactor tới 10 | nhiều Lambda mỗi shard | | Lỗi CHẶN cả shard | phải cấu hình DLQ |

Cấu hình chống chặn shard:

{"MaximumRetryAttempts": 3,
 "BisectBatchOnFunctionError": true,
 "MaximumRecordAgeInSeconds": 3600,
 "DestinationConfig": {"OnFailure": {"Destination": "<arn-sqs>"}}}

Không có nó: một bản ghi lỗi chặn toàn bộ shard
    → dữ liệu phía sau không được xử lý cho tới khi hết hạn

Ba lưu ý về partition key: | Lưu ý | Chi tiết | |---|---| | Quyết định bản ghi vào shard nào | | | Phân bố ĐỀU tránh hot shard | | | Cùng key = cùng shard = giữ THỨ TỰ | |

Với dữ liệu clickstream, mã phiên hoặc mã người dùng là khoá tốt.

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | IteratorAgeMilliseconds | consumer tụt lại bao xa — quan trọng nhất | | WriteProvisionedThroughputExceeded | bị throttle (chế độ provisioned) | | IncomingRecords | lượng bản ghi vào |

Ba mẫu kiến trúc thường thấy: | Mẫu | Chi tiết | |---|---| | Kinesis → Lambda → DynamoDB | thời gian thực ← câu này | | Kinesis → Firehose → S3 | lưu trữ lâu dài | | Kinesis → Managed Flink | phân tích cửa sổ thời gian |

Và nên làm CẢ HAI mẫu đầu song song:

Kinesis Data Streams
    ├─→ Lambda: xử lý thời gian thực, cập nhật gợi ý
    └─→ Firehose: đẩy vào S3 cho phân tích lịch sử
        ↓
    Một luồng, hai mục đích

Ba lưu ý về Managed Service for Apache Flink: | Lưu ý | Chi tiết | |---|---| | Phân tích theo CỬA SỔ THỜI GIAN | đếm, tổng hợp trong 5 phút gần nhất | | SQL hoặc Java/Python | | | Serverless | |

Rất phù hợp cho việc phân tích tương tác người dùng theo cửa sổ.

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | On-demand đắt hơn provisioned khi tải cao ổn định | | | PUT payload unit tính theo đơn vị 25 KB | gộp lô tiết kiệm | | Lambda tính theo GB-giây | |

Và một lời khuyên: hãy đặt alarm cho IteratorAgeMilliseconds ngay từ đầu. Với dữ liệu thời gian thực, việc consumer tụt lại là loại sự cố tệ nhất — dữ liệu vẫn vào bình thường, không có lỗi nào, chỉ là kết quả phân tích ngày càng cũ đi cho tới khi vô dụng.

Đáp án

B, C và E.

• B — Dùng AWS Application Migration Service (MGN), cài AWS Replication Agent trên các máy ảo nguồn
• E — Thực hiện sao chép ban đầu, khởi động instance kiểm thử trong AWS để xác thực trước khi chuyển đổi cuối cùng
• C — Khởi động cutover instance sau khi kiểm thử xong và xác nhận sao chép đã cập nhật

Vì sao đúng

Đề nêu chiến lược lift-and-shift với thời hạn gấp và không tái cấu trúc, và ba bước trên chính là quy trình chuẩn của MGN.

Quy trình ba giai đoạn của Application Migration Service:

① Cài AWS Replication Agent lên máy ảo nguồn        ← đáp án B
   → sao chép LIÊN TỤC ở mức KHỐI sang AWS
   → nguồn vẫn chạy bình thường, không gián đoạn

② Khởi động TEST INSTANCE                            ← đáp án E
   → xác thực ứng dụng chạy đúng trên AWS
   → nguồn VẪN đang chạy và vẫn được sao chép

③ Khởi động CUTOVER INSTANCE                         ← đáp án C
   → khi đã xác nhận và dữ liệu đã đồng bộ
   → chuyển lưu lượng sang, tắt nguồn

Vì sao MGN phù hợp với lift-and-shift:

Sao chép ở mức KHỐI (block-level)
    → không quan tâm ứng dụng chạy gì
    → không cần sửa mã, không cần đóng gói lại
        ↓
    Đúng "without requiring extensive application refactoring"

Và thời gian ngừng rất ngắn:

Sao chép liên tục chạy nền nhiều ngày
    → tới lúc cutover, chỉ còn chênh lệch vài phút
        ↓
    Thời gian ngừng tính bằng phút, không phải giờ

Cài agent trên máy nguồn:

sudo python3 aws-replication-installer-init.py   --region ap-northeast-1   --aws-access-key-id <key> --aws-secret-access-key <secret>   --no-prompt

Và giai đoạn kiểm thử là bước không được bỏ qua:

Test instance chạy TÁCH BIỆT
    → dùng subnet và security group riêng
    → nguồn không bị ảnh hưởng gì
        ↓
    Phát hiện vấn đề về driver, IP cứng, giấy phép
      TRƯỚC khi cutover thật

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

• **A. Dùng CloudEndure Disaster Recovery sao chép liên tục rồi thăng cấp instance đích — đây là phương án gần nhất vì CloudEndure chính là công nghệ nền của MGN, nhưng nó là sản phẩm SAI mục đích và đã được thay thế: CloudEndure Disaster Recovery dành cho khôi phục thảm hoạ; bản Migration đã được đổi tên thành AWS Application Migration Service. Với việc di chuyển, MGN là dịch vụ đúng.
• **D. Tắt máy ảo nguồn rồi tạo AMI thủ công — gây ngừng dài và rủi ro cao: phải tắt nguồn trước, tự xuất và nhập ảnh đĩa, và không có giai đoạn kiểm thử nào.
• **F. Dùng EC2 Auto Scaling để tự tạo lại VM — hiểu sai chức năng: Auto Scaling khởi động instance từ launch template, nó không di chuyển hay sao chép máy ảo hiện có.

Ghi nhớ

Các công cụ di chuyển của AWS — bảng phải thuộc: | Công cụ | Việc | |---|---| | AWS Application Migration Service (MGN) | lift-and-shift máy chủ, sao chép mức khối | | AWS Database Migration Service (DMS) | di chuyển DATABASE, có CDC | | AWS DataSync | di chuyển TỆP hàng loạt | | AWS Migration Hub | theo dõi tiến độ di chuyển tập trung | | AWS Application Discovery Service | khảo sát môi trường nguồn | | Snowball | vận chuyển vật lý dữ liệu lớn |

Từ khoá nhận diện:

"lift and shift", "rehost", "no refactoring", "VMs" → MGN "migrate database with minimal downtime" → DMS "migrate files/NFS/SMB" → DataSync

Ba giai đoạn của MGN: | Giai đoạn | Chi tiết | |---|---| | Replication | agent sao chép liên tục sang staging area | | Test | khởi động instance kiểm thử, nguồn vẫn chạy | | Cutover | chuyển sang thật, dừng nguồn |

Sáu chiến lược di chuyển (6 R) — bảng cần biết: | Chiến lược | Nghĩa | |---|---| | Rehost | lift-and-shift, không sửa gì ← câu này | | Replatform | sửa nhẹ (ví dụ chuyển DB sang RDS) | | Refactor | viết lại cho đám mây | | Repurchase | chuyển sang SaaS | | Retire | bỏ hẳn | | Retain | giữ nguyên tại chỗ |

Rehost nhanh nhất, refactor cho lợi ích lớn nhất — với thời hạn gấp, rehost là lựa chọn đúng.

Ba đặc điểm của MGN: | Đặc điểm | Chi tiết | |---|---| | Sao chép mức KHỐI, liên tục | không quan tâm hệ điều hành hay ứng dụng | | Hỗ trợ Windows và nhiều bản Linux | | | MIỄN PHÍ trong 90 ngày mỗi máy chủ | chỉ trả phí tài nguyên AWS |

Ba thành phần trong tài khoản AWS: | Thành phần | Việc | |---|---| | Staging area subnet | chứa replication server và volume tạm | | Replication server | nhận dữ liệu từ agent | | Launch template | cấu hình instance đích |

Ba việc cần chuẩn bị trước: | Việc | Chi tiết | |---|---| | Kết nối mạng từ nguồn tới AWS | cổng 443 và 1500 | | Khảo sát bằng Application Discovery Service | biết máy nào phụ thuộc máy nào | | Lập thứ tự di chuyển theo nhóm ứng dụng | |

Dòng giữa quan trọng:

Ứng dụng thường phụ thuộc lẫn nhau
    → di chuyển một máy mà để máy phụ thuộc lại tại chỗ
    → độ trễ tăng vọt hoặc kết nối đứt
        ↓
    Di chuyển theo NHÓM (application wave)

Ba lưu ý ở giai đoạn kiểm thử: | Lưu ý | Chi tiết | |---|---| | Dùng subnet và security group RIÊNG | không đụng sản xuất | | Kiểm tra IP cứng trong cấu hình | rất hay gặp với ứng dụng cũ | | Kiểm tra giấy phép phần mềm | một số ràng buộc theo phần cứng |

Ba lưu ý khi cutover: | Lưu ý | Chi tiết | |---|---| | Chọn giờ thấp điểm | | | Xác nhận lag sao chép gần bằng 0 | | | Có kế hoạch quay lại | giữ nguồn vài ngày |

Ba việc cần làm sau khi cutover: | Việc | Chi tiết | |---|---| | Gỡ agent khỏi máy nguồn | | | Dọn staging area | volume tạm tính phí | | Tối ưu kích thước instance | Compute Optimizer |

Dòng cuối là bước hay bị bỏ quên:

MGN tạo instance có cấu hình giống máy ảo nguồn
    → máy ảo tại chỗ thường được cấp thừa
        ↓
    Chạy Compute Optimizer sau 2 tuần và thu nhỏ
    → đây là nơi phần lớn khoản tiết kiệm của việc lên đám mây nằm

Ba lưu ý về chi phí trong lúc di chuyển: | Khoản | Chi tiết | |---|---| | MGN miễn phí 90 ngày mỗi máy | | | Replication server và volume staging tính phí | | | Test instance tính phí như instance thường | tắt sau khi kiểm thử |

Và một lời khuyên: hãy chạy giai đoạn kiểm thử nhiều lần trước khi cutover, không chỉ một. Test instance không ảnh hưởng gì tới nguồn và có thể huỷ đi tạo lại tuỳ ý — mỗi vòng kiểm thử phát hiện thêm một thứ, và với ứng dụng cũ thì danh sách đó thường dài hơn dự kiến.

Đáp án

A — Dùng ELB phân phối lưu lượng cho bốn EC2 instance, trong đó hai instance ở AZ A của us-east-1 và hai instance ở AZ B của us-west-1.

Vì sao đúng

Câu hỏi tìm cấu hình KHÔNG được phép, và điểm mấu chốt là:

Elastic Load Balancing là dịch vụ THEO REGION
    → chỉ phân phối lưu lượng cho target TRONG CÙNG Region
        ↓
    us-east-1 và us-west-1 là HAI REGION KHÁC NHAU
    → một ELB KHÔNG làm được điều này

Ba cấu hình còn lại đều hợp lệ: | Cấu hình | Hợp lệ | |---|---| | 4 máy trong 1 AZ của us-west-1 | ✅ (không dư thừa, nhưng được phép) | | 4 máy trong 1 AZ của us-east-1 | ✅ | | 4 máy trải 2 AZ của us-east-1 | ✅ khuyến nghị |

Và cách đúng để cân bằng tải xuyên Region: | Cách | Cơ chế | |---|---| | AWS Global Accelerator | 2 IP anycast tĩnh, endpoint group ở nhiều Region | | Route 53 latency-based routing | DNS trỏ tới ELB của Region gần nhất | | CloudFront | cho nội dung HTTP |

Kiến trúc đa Region đúng:

Global Accelerator
    ├─→ endpoint group us-east-1 → ALB us-east-1 → EC2
    └─→ endpoint group us-west-1 → ALB us-west-1 → EC2
        ↓
    MỖI Region có ELB RIÊNG

aws globalaccelerator create-endpoint-group   --listener-arn <arn> --endpoint-group-region us-east-1   --endpoint-configurations EndpointId=<arn-alb-east>,Weight=128

aws globalaccelerator create-endpoint-group   --listener-arn <arn> --endpoint-group-region us-west-1   --endpoint-configurations EndpointId=<arn-alb-west>,Weight=128

Ngoại lệ duy nhất đáng biết — target group kiểu IP:

ALB/NLB với target type = ip
    → đăng ký được IP trong VPC đã peering CÙNG REGION
    → hoặc IP on-premises qua VPN/Direct Connect
        ↓
    NHƯNG vẫn KHÔNG đăng ký được EC2 ở Region khác

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

• **D. Bốn instance trải hai AZ của us-east-1 — đây là phương án gần nhất về mặt trông giống một cấu hình phức tạp, nhưng nó hoàn toàn hợp lệ và còn là cấu hình được KHUYẾN NGHỊ: trải nhiều AZ trong cùng Region là mẫu chuẩn cho sẵn sàng cao.
• **B. Bốn instance trong một AZ của us-west-1 — hợp lệ về mặt kỹ thuật, chỉ là không có dư thừa theo AZ.
• **C. Bốn instance trong một AZ của us-east-1 — cùng lý do, vẫn hợp lệ.

Ghi nhớ

Phạm vi của các dịch vụ AWS — bảng phải thuộc: | Dịch vụ | Phạm vi | |---|---| | Elastic Load Balancing | REGION ← câu này | | Auto Scaling group | REGION (trải nhiều AZ) | | EBS volume | AZ | | Subnet | AZ | | VPC, security group | REGION | | S3 bucket | REGION | | AMI, snapshot | REGION | | IAM, Route 53, CloudFront | TOÀN CẦU | | Global Accelerator | TOÀN CẦU |

Ba cách phân phối lưu lượng xuyên Region: | Cách | Cơ chế | |---|---| | Global Accelerator | IP anycast, chuyển vùng ~30 giây | | Route 53 (latency, geolocation, failover) | DNS | | CloudFront | edge, cho HTTP |

Ba loại load balancer: | Loại | Tầng | |---|---| | Application Load Balancer | 7 (HTTP/HTTPS) | | Network Load Balancer | 4 (TCP/UDP/TLS) | | Gateway Load Balancer | 3 (thiết bị bảo mật) |

Ba yêu cầu khi tạo load balancer: | Yêu cầu | Chi tiết | |---|---| | Ít nhất 2 subnet ở 2 AZ khác nhau | với ALB | | Cùng VPC | | | Security group (ALB, và NLB từ 2023) | |

Dòng đầu là yêu cầu bắt buộc của ALB — không tạo được ALB chỉ với một AZ.

Ba loại target type: | Loại | Đăng ký gì | |---|---| | instance | EC2 trong cùng VPC | | ip | IP trong VPC, VPC peering cùng Region, hoặc on-premises | | lambda | hàm Lambda (chỉ ALB) | | alb | ALB làm target của NLB |

Ba lưu ý về cross-zone load balancing: | Loại | Mặc định | |---|---| | ALB | BẬT, không tắt được ở mức LB, MIỄN PHÍ | | NLB | TẮT, bật thì TÍNH PHÍ chéo AZ | | GWLB | tắt |

Ba lợi ích của việc trải nhiều AZ: | Lợi ích | Chi tiết | |---|---| | Chịu được mất một AZ | | | Là yêu cầu để dùng ALB | | | Không tốn thêm phí với ALB | |

Ba lưu ý về kiến trúc đa Region: | Lưu ý | Chi tiết | |---|---| | Mỗi Region cần bộ hạ tầng riêng | VPC, ELB, ASG, AMI | | Dữ liệu phải sao chép | Aurora Global, DynamoDB Global Tables | | Chi phí gần như nhân đôi | |

Ba lý do thật sự cần đa Region: | Lý do | Chi tiết | |---|---| | Chịu được mất cả một Region | | | Yêu cầu pháp lý về vị trí dữ liệu | | | Giảm độ trễ cho người dùng toàn cầu | |

Với hầu hết ứng dụng, đa AZ là đủ — đa Region là quyết định lớn về chi phí và độ phức tạp.

Ba cách kiểm tra cấu hình ELB: | Cách | Lệnh | |---|---| | Xem subnet đang dùng | describe-load-balancers | | Xem target và sức khoẻ | describe-target-health | | Xem phân bố theo AZ | CloudWatch HealthyHostCount |

aws elbv2 describe-load-balancers --names lb-ung-dung   --query 'LoadBalancers[].AvailabilityZones[].{AZ:ZoneName,Subnet:SubnetId}'

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | HealthyHostCount theo AZ | phát hiện phân bố lệch | | TargetResponseTime | | | HTTPCode_ELB_5XX_Count | lỗi ở tầng load balancer |

Và một lời khuyên: hãy nhớ rằng gần như mọi tài nguyên mạng và tính toán của AWS đều bị giới hạn trong một Region. Khi một câu hỏi mô tả cấu hình trải nhiều Region cho một tài nguyên duy nhất — load balancer, ASG, VPC, subnet — thì đó thường chính là phương án sai mà câu hỏi đang tìm.

Đáp án

C — Tạo một group, gắn policy vào group, và đưa 50 người dùng vào group đó.

Vì sao đúng

Đề nêu hai yêu cầu, và IAM group đáp ứng cả hai: | Yêu cầu | Cơ chế | |---|---| | Nhanh nhất | gắn policy MỘT LẦN cho cả nhóm | | Thay đổi tối thiểu | không đụng tới policy của từng người |

So sánh công sức:

Gắn policy cho từng người:
    → 50 thao tác
    → thêm người mới: lại một thao tác nữa
    → thu hồi quyền: 50 thao tác

Dùng group:
    → 1 thao tác tạo group + gắn policy
    → 50 thao tác thêm người (làm hàng loạt được)
    → thêm người mới: thêm vào group
    → thu hồi quyền cho tất cả: sửa policy MỘT chỗ

Triển khai:

aws iam create-group --group-name nhom-ghi-s3

aws iam put-group-policy --group-name nhom-ghi-s3   --policy-name quyen-ghi-s3 --policy-document '{
    "Version":"2012-10-17",
    "Statement":[{"Effect":"Allow",
      "Action":["s3:GetObject","s3:PutObject","s3:DeleteObject"],
      "Resource":"arn:aws:s3:::kho-du-lieu/*"}]}'

for u in $(cat danh-sach-50-nguoi.txt); do
  aws iam add-user-to-group --group-name nhom-ghi-s3 --user-name "$u"
done

Và lợi ích lâu dài lớn hơn lợi ích trước mắt:

Cần thu hồi quyền ghi của cả 50 người:
    Với group:   sửa MỘT policy
    Không group: sửa 50 policy
        ↓
    Và quan trọng hơn: rà soát ai có quyền gì
    → xem thành viên group là biết ngay

Đây là mô hình quản trị quyền theo VAI TRÒ:

Người dùng → thuộc nhóm theo vai trò → nhóm có quyền
        ↓
    Thay đổi vai trò = đổi nhóm
    → không phải sửa quyền từng người

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

• **B. Tạo policy và gắn thủ công cho 50 người — đây là phương án gần nhất và cho kết quả giống hệt, nhưng nó tốn 50 thao tác và khó bảo trì: mỗi lần thay đổi quyền phải sửa 50 chỗ, và không có cách nào nhìn tổng thể ai đang có quyền gì.
• **D. Cập nhật bucket policy của S3 — phải liệt kê 50 ARN trong policy: dài, dễ sai, và bucket policy có giới hạn 20 KB. Với danh sách người dùng thay đổi thường xuyên, đây là cách bảo trì tệ nhất.
• **A. Tạo "MFA user có quyền đọc ghi và liên kết 50 IAM user với MFA" — không phải khái niệm có thật: MFA là cơ chế xác thực hai yếu tố cho một user, không phải một loại danh tính để liên kết quyền.

Ghi nhớ

Ba loại danh tính trong IAM — bảng phải thuộc: | Danh tính | Đặc điểm | |---|---| | IAM user | danh tính lâu dài cho người hoặc ứng dụng | | IAM group | TẬP HỢP user — KHÔNG phải danh tính, không đăng nhập được | | IAM role | danh tính TẠM THỜI, ai cũng assume được nếu được phép |

Ba đặc điểm của IAM group: | Đặc điểm | Chi tiết | |---|---| | Không lồng nhau | group không chứa group | | Một user thuộc tối đa 10 group | | | Không có credential riêng | không đăng nhập bằng group |

Dòng đầu là hạn chế hay bị hỏi — IAM không có phân cấp nhóm.

Hai loại policy gắn được: | Loại | Đặc điểm | |---|---| | Managed policy | dùng lại được, có phiên bản, tối đa 6.144 ký tự | | Inline policy | gắn chặt vào một danh tính, xoá danh tính thì mất theo |

Managed policy được khuyến nghị — dùng lại và theo dõi phiên bản được.

aws iam create-policy --policy-name quyen-ghi-s3   --policy-document file://chinh-sach.json

aws iam attach-group-policy --group-name nhom-ghi-s3   --policy-arn arn:aws:iam::123456789012:policy/quyen-ghi-s3

Ba giới hạn của IAM: | Giới hạn | Giá trị | |---|---| | Managed policy mỗi danh tính | 10 (nâng lên 20 được) | | Group mỗi user | 10 | | Kích thước inline policy | 2.048 (user) / 5.120 (group) ký tự |

Ba nguyên tắc quản trị quyền: | Nguyên tắc | Chi tiết | |---|---| | Quyền tối thiểu | chỉ hành động và tài nguyên cần thiết | | Gán quyền qua GROUP hoặc ROLE, không gán trực tiếp | | | Rà soát định kỳ | |

Ba cách rà soát quyền: | Cách | Việc | |---|---| | IAM Access Advisor | dịch vụ nào KHÔNG được dùng tới | | IAM Access Analyzer (unused access) | quyền và role không dùng | | Credential report | trạng thái mọi user |

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

Ba lý do AWS khuyến nghị BỎ IAM user cho con người: | Lý do | Chi tiết | |---|---| | Access key dài hạn dễ bị lộ | | | Không có đăng nhập một lần | | | Khó quản lý ở nhiều tài khoản | |

Cách thay thế được khuyến nghị:

AWS IAM Identity Center:
    ✓ nguồn danh tính tập trung (AD, Okta, Entra ID)
    ✓ credential TẠM THỜI
    ✓ permission set áp cho nhiều tài khoản
        ↓
    Với 200 người dùng, đây là hướng đi đúng lâu dài

Ba lưu ý về ABAC (phân quyền theo thuộc tính): | Lưu ý | Chi tiết | |---|---| | Dùng tag thay vì liệt kê danh tính | | | Một policy phục vụ nhiều nhóm | | | Mở rộng tốt hơn RBAC khi số nhóm lớn | |

{"Effect": "Allow", "Action": "s3:*",
 "Resource": "arn:aws:s3:::kho-du-lieu/${aws:PrincipalTag/doi}/*"}

Một policy duy nhất, mỗi đội chỉ truy cập được thư mục của mình.

Ba biện pháp bảo mật nên có: | Biện pháp | Chi tiết | |---|---| | Bắt buộc MFA | qua điều kiện trong policy | | Xoay vòng access key | hoặc bỏ hẳn access key | | Permission boundary cho quyền tối đa | |

Bắt buộc MFA cho thao tác nhạy cảm:

{"Effect": "Deny", "Action": "s3:DeleteObject", "Resource": "*",
 "Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}}}

Ba lưu ý về bucket policy so với IAM policy: | | IAM policy | Bucket policy | |---|---|---| | Gắn vào | user, group, role | bucket | | Có Principal | ❌ | ✅ | | Giới hạn kích thước | 6.144 ký tự | 20 KB | | Phù hợp | quản lý theo người dùng | quy tắc chung cho bucket |

Và một lời khuyên: hãy coi việc dùng group là bước đệm, không phải đích đến. Với 200 người dùng và một tổ chức đang lớn, IAM Identity Center với permission set sẽ giải quyết vấn đề tốt hơn nhiều — nó bỏ hẳn access key dài hạn và cho phép quản lý quyền trên nhiều tài khoản từ một chỗ.

Đáp án

C — Auto Scaling group với dung lượng mong muốn hai EC2 instance trải qua HAI Availability Zone, đặt sau Application Load Balancer, và RDS MySQL ở cấu hình Multi-AZ.

Vì sao đúng

Đề nêu hai yêu cầu, và phương án C đáp ứng cả hai ở cả hai tầng: | Tầng | Cơ chế | |---|---| | Ứng dụng | ASG trải 2 AZ + ALB | | Dữ liệu | RDS Multi-AZ | | Ít công bảo trì | dịch vụ được quản lý, không script tự viết |

Và vế "trải hai AZ" là điểm phân biệt với phương án D:

Hai instance trong CÙNG một AZ:
    → AZ đó hỏng → mất CẢ HAI
    → không có sẵn sàng cao thật sự

Hai instance ở HAI AZ:
    → mất một AZ vẫn còn một máy phục vụ

Và RDS Multi-AZ là công cụ đúng cho tầng dữ liệu:

Multi-AZ:
    ✓ standby ở AZ khác, sao chép ĐỒNG BỘ
    ✓ chuyển đổi TỰ ĐỘNG (60–120 giây)
    ✓ RPO = 0, không mất giao dịch
    ✓ AWS quản lý toàn bộ

Triển khai:

aws autoscaling create-auto-scaling-group   --auto-scaling-group-name asg-ung-dung   --launch-template LaunchTemplateName=lt-ung-dung,Version='$Latest'   --min-size 2 --desired-capacity 2 --max-size 6   --vpc-zone-identifier "subnet-az-a,subnet-az-c"   --target-group-arns <arn-tg>   --health-check-type ELB --health-check-grace-period 300

aws rds modify-db-instance --db-instance-identifier db-ung-dung   --multi-az --apply-immediately

Và vì sao Multi-AZ chứ không phải read replica:

Yêu cầu là SẴN SÀNG CAO, không phải mở rộng đọc
        ↓
    Multi-AZ:      chuyển đổi TỰ ĐỘNG, sao chép đồng bộ
    Read replica:  promote THỦ CÔNG, sao chép bất đồng bộ
        ↓
    Read replica đòi can thiệp tay khi sự cố
    → không đáp ứng "minimizing maintenance effort"

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

• **A. ASG 2 instance trải 2 AZ + ALB, nhưng RDS read replica ở AZ khác thay vì Multi-AZ — đây là phương án gần nhất và đúng hoàn toàn ở tầng ứng dụng, nhưng nó sai ở tầng dữ liệu: read replica không tự chuyển đổi, phải promote thủ công khi primary hỏng. Đó là công bảo trì mà đề muốn tránh.
• **D. ASG 2 instance trong MỘT AZ + ALB + RDS Multi-AZ — tầng ứng dụng không chịu lỗi AZ: đúng ở tầng dữ liệu nhưng sai ở tầng tính toán.
• **B. Instance thứ hai ở AZ khác, RDS thứ hai ở AZ khác, Route 53 phân phối và script tự viết đồng bộ hai MySQL — công bảo trì cao nhất và rủi ro lớn: tự viết cơ chế đồng bộ database là bài toán rất khó (xung đột, thứ tự, mất kết nối), và Route 53 không phải công cụ cân bằng tải cho việc này.

Ghi nhớ

Kiến trúc web sẵn sàng cao — mẫu chuẩn: | Tầng | Cơ chế | |---|---| | DNS | Route 53 alias record | | Cân bằng tải | ALB (tự dư thừa qua các AZ) | | Ứng dụng | ASG trải ít nhất 2 AZ | | Dữ liệu | RDS Multi-AZ hoặc Aurora |

Sẵn sàng cao phải có ở MỌI tầng — một tầng thiếu là cả kiến trúc có điểm hỏng đơn.

Multi-AZ và Read Replica — bảng phải thuộc: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC | | Sao chép | ĐỒNG BỘ | bất đồng bộ | | Chuyển đổi | TỰ ĐỘNG | thủ công | | Phục vụ đọc | ❌ | ✅ |

Câu hỏi nói "high availability, minimal maintenance" → Multi-AZ.

Ba cấu hình ASG quan trọng: | Cấu hình | Chi tiết | |---|---| | vpc-zone-identifier nhiều subnet ở nhiều AZ | ← điểm của câu này | | HealthCheckType = ELB | thay máy mà ứng dụng hỏng | | MinSize chịu được mất một AZ | |

Công thức N+1 theo AZ:

Số máy mỗi AZ = (số máy cần phục vụ) ÷ (số AZ − 1)
        ↓
    Cần 1 máy phục vụ, 2 AZ → 1 máy mỗi AZ, tổng 2
    Cần 2 máy phục vụ, 2 AZ → 2 máy mỗi AZ, tổng 4

Ba điều kiện để ứng dụng chạy được trong ASG: | Điều kiện | Chi tiết | |---|---| | STATELESS | phiên lưu ở ElastiCache hoặc DynamoDB | | Tệp tải lên ở S3 hoặc EFS | không lưu đĩa cục bộ | | Log gửi lên CloudWatch | |

Ba lợi ích của ALB: | Lợi ích | Chi tiết | |---|---| | Tự dư thừa qua các AZ | không phải cấu hình gì | | Health check phát hiện ứng dụng hỏng | | | Cross-zone load balancing miễn phí | luôn bật |

Ba yêu cầu khi tạo ALB: | Yêu cầu | Chi tiết | |---|---| | Ít nhất 2 subnet ở 2 AZ | bắt buộc | | Security group | | | Target group với health check | |

Ba tình huống chuyển đổi RDS Multi-AZ: | Tình huống | Chi tiết | |---|---| | Primary hỏng | | | AZ mất kết nối | | | Bảo trì có kế hoạch | vá lỗi luân phiên |

Ba việc Multi-AZ KHÔNG bảo vệ: | Không bảo vệ | Cách bảo vệ | |---|---| | Lỗi con người | automated backup + PITR | | Thảm hoạ Region | cross-Region backup hoặc replica | | Dữ liệu hỏng do ứng dụng | PITR |

Ba lưu ý về chi phí: | Khoản | Chi tiết | |---|---| | Multi-AZ gấp đôi chi phí RDS instance | | | Hai EC2 thay vì một | | | ALB tính theo giờ và LCU | |

Đây là chi phí của độ tin cậy — và với ứng dụng sản xuất, thường xứng đáng.

Ba bước nâng cấp từ kiến trúc một máy: | Bước | Chi tiết | |---|---| | ① Làm ứng dụng stateless | điều kiện tiên quyết | | ② Dựng ASG + ALB | | | ③ Bật RDS Multi-AZ | |

Bước đầu quan trọng nhất:

Đưa ứng dụng còn giữ trạng thái vào ASG
    → người dùng bị đăng xuất ngẫu nhiên
    → tệp vừa tải lên biến mất
        ↓
    Lỗi ngắt quãng rất khó tái hiện

Ba việc nên làm sau khi triển khai: | Việc | Chi tiết | |---|---| | Thử tắt hết máy trong một AZ | xác nhận vẫn phục vụ | | Thử chuyển đổi RDS | --force-failover | | Đo thời gian phục hồi thực tế | |

Và một lời khuyên: hãy thử chuyển đổi RDS trong giờ thấp điểm ngay sau khi bật Multi-AZ. Phía AWS luôn hoạt động đúng, nhưng ứng dụng thì chưa chắc — thiếu logic thử lại kết nối hoặc cache DNS quá lâu là hai vấn đề chỉ lộ ra khi chuyển đổi xảy ra thật.

Đáp án

B — Đặt Network Load Balancer ở PUBLIC subnet, tạo Auto Scaling group ở PRIVATE subnet và gắn vào NLB đó.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án B đáp ứng cả ba một cách an toàn nhất: | Yêu cầu | Cơ chế | |---|---| | Ứng dụng web truy cập CÔNG KHAI | load balancer ở PUBLIC subnet | | Bảo mật cao nhất | EC2 ở PRIVATE subnet, không có IP công cộng | | Kết thúc TLS ngoài EC2 | NLB với TLS listener |

Mẫu kiến trúc chuẩn:

Internet
    ↓
Public subnet:  Load balancer (điểm vào duy nhất)
    ↓
Private subnet: EC2 trong ASG (KHÔNG có IP công cộng)
    ↓
Private subnet: Database

Vì sao EC2 phải ở private subnet:

EC2 ở public subnet:
    → có IP công cộng
    → bị quét và tấn công trực tiếp từ Internet
        ↓
EC2 ở private subnet:
    → KHÔNG có đường vào từ Internet
    → chỉ load balancer gọi tới được
        ↓
    Giảm hẳn bề mặt tấn công

Và NLB hỗ trợ TLS termination từ 2019:

aws elbv2 create-listener --load-balancer-arn <arn-nlb>   --protocol TLS --port 443   --certificates CertificateArn=<arn-chung-chi>   --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06   --default-actions Type=forward,TargetGroupArn=<arn-tg>

TLS listener:
    → NLB giải mã TLS
    → chuyển tiếp TCP thuần tới target
        ↓
    EC2 KHÔNG phải xử lý mã hoá — đúng yêu cầu "offloaded"

Và security group thắt chặt thêm:

# NLB nhận từ Internet
aws ec2 authorize-security-group-ingress --group-id sg-nlb   --protocol tcp --port 443 --cidr 0.0.0.0/0

# EC2 chỉ nhận từ NLB
aws ec2 authorize-security-group-ingress --group-id sg-ec2   --protocol tcp --port 8080 --source-group sg-nlb

Và EC2 ở private subnet vẫn ra Internet được qua NAT Gateway — để tải bản cập nhật, gọi API AWS.

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

• **C. NLB ở public subnet, ASG cũng ở public subnet — đây là phương án gần nhất và hoạt động được, nhưng nó kém an toàn hơn hẳn: EC2 có IP công cộng và bị phơi trực tiếp ra Internet. Đề hỏi "in the MOST SECURE manner".
• **A. NLB ở private subnet, ASG ở private subnet — ứng dụng KHÔNG truy cập được từ Internet: load balancer ở private subnet không có đường vào từ ngoài, trái yêu cầu "publicly accessible".
• **D. NLB ở private subnet, ASG ở public subnet — sai cả hai chỗ: load balancer không nhận được lưu lượng từ Internet, và EC2 lại bị phơi ra.

Ghi nhớ

Mẫu kiến trúc ba tầng chuẩn — bảng phải thuộc: | Thành phần | Subnet | |---|---| | Load balancer, NAT Gateway, bastion | PUBLIC | | EC2 ứng dụng | PRIVATE | | Database | PRIVATE |

Định nghĩa public và private subnet:

Public subnet:  route table CÓ route 0.0.0.0/0 → Internet Gateway
Private subnet: KHÔNG có route đó
        ↓
    Đây là khác biệt DUY NHẤT

Ba lớp bảo mật của kiến trúc này: | Lớp | Cơ chế | |---|---| | Vị trí mạng | EC2 ở private subnet | | Security group | chỉ cho phép từ load balancer | | NACL | quy tắc thô ở cấp subnet |

Ba loại load balancer và TLS: | Loại | TLS termination | |---|---| | Application Load Balancer | ✅ HTTPS listener | | Network Load Balancer | ✅ TLS listener (từ 2019) | | Gateway Load Balancer | ❌ |

ALB và NLB — chọn cái nào cho ứng dụng web: | | ALB | NLB | |---|---|---| | Tầng | 7 (HTTP) | 4 (TCP/TLS) | | Định tuyến theo đường dẫn/host | ✅ | ❌ | | WAF | ✅ | ❌ | | Xác thực (Cognito, OIDC) | ✅ | ❌ | | IP tĩnh | ❌ | ✅ | | Hiệu năng | cao | cực cao |

Với ứng dụng web thông thường, ALB thường phù hợp hơn — nhưng đề chỉ đưa ra NLB, và NLB vẫn kết thúc TLS được.

Ba lợi ích của việc kết thúc TLS ở load balancer: | Lợi ích | Chi tiết | |---|---| | EC2 không tốn CPU giải mã | | | Quản lý chứng chỉ tập trung | ACM tự gia hạn | | Cập nhật TLS policy một chỗ | |

Ba lưu ý về chứng chỉ: | Lưu ý | Chi tiết | |---|---| | ACM cấp MIỄN PHÍ cho ALB và NLB | | | Chứng chỉ ở CÙNG Region với load balancer | khác CloudFront | | Xác thực DNS tự gia hạn | khuyến nghị |

Ba TLS policy nên dùng: | Policy | Chi tiết | |---|---| | ELBSecurityPolicy-TLS13-1-2-2021-06 | TLS 1.2 và 1.3, khuyến nghị | | ELBSecurityPolicy-FS-1-2-Res-2020-10 | forward secrecy nghiêm ngặt | | Policy cũ có TLS 1.0/1.1 | tránh dùng |

Ba lưu ý về private subnet: | Lưu ý | Chi tiết | |---|---| | Cần NAT Gateway để ra Internet | tải cập nhật | | VPC endpoint cho dịch vụ AWS | rẻ hơn NAT | | Session Manager để truy cập quản trị | không cần bastion |

VPC endpoint tiết kiệm đáng kể:

Gateway endpoint cho S3 và DynamoDB: MIỄN PHÍ
NAT Gateway: ~32 USD/tháng + 0,045 USD/GB
        ↓
    Nên có gateway endpoint ở mọi VPC

Ba lưu ý về NAT Gateway: | Lưu ý | Chi tiết | |---|---| | Đặt ở PUBLIC subnet | | | Một NAT mỗi AZ cho sẵn sàng cao | | | Tính phí theo giờ và theo GB | |

Ba cách truy cập EC2 ở private subnet: | Cách | Chi tiết | |---|---| | Systems Manager Session Manager | không mở cổng nào | | EC2 Instance Connect Endpoint | | | Bastion host ở public subnet | truyền thống |

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | HealthyHostCount | số target khoẻ | | ActiveFlowCount (NLB) | kết nối đang mở | | TargetTLSNegotiationErrorCount | lỗi bắt tay TLS |

Ba lưu ý về NLB và security group của target: | Lưu ý | Chi tiết | |---|---| | NLB target type instance GIỮ IP nguồn | SG của target phải cho phép IP CLIENT | | Target type ip thì thấy IP của NLB | | | NLB nay có security group riêng (từ 2023) | |

Dòng đầu là bẫy hay gặp:

NLB với target type `instance`
    → EC2 thấy IP THẬT của client, không phải IP của NLB
        ↓
    Cấu hình security group cho phép sg-nlb sẽ KHÔNG hoạt động
    → phải cho phép 0.0.0.0/0 hoặc dùng target type `ip`

Và một lời khuyên: hãy kiểm tra kỹ hành vi giữ IP nguồn của NLB khi cấu hình security group cho target. Với ALB thì tham chiếu security group hoạt động như mong đợi, nhưng với NLB target type instance thì EC2 nhìn thấy IP của client chứ không phải của load balancer — và mọi kết nối sẽ bị chặn mà cấu hình trông hoàn toàn hợp lý.

Đáp án

B, C và D.

• B — VPC Security Group
• C — AWS WAF
• D — AWS Shield Advanced

Vì sao đúng

AWS Firewall Manager là công cụ quản trị tập trung cho các dịch vụ bảo vệ mạng và ứng dụng, và ba lựa chọn trên đúng là những gì nó cấu hình được.

Danh sách đầy đủ tài nguyên Firewall Manager quản lý: | Tài nguyên | Việc | |---|---| | AWS WAF (web ACL) | áp cùng bộ rule cho mọi ALB, CloudFront trong tổ chức | | AWS Shield Advanced | bật bảo vệ DDoS đồng loạt | | VPC Security Group | kiểm toán và áp quy tắc chuẩn | | AWS Network Firewall | tường lửa cấp VPC | | Route 53 Resolver DNS Firewall | chặn tên miền độc hại | | Third-party firewall (Palo Alto, Fortinet) | qua Marketplace |

Điểm chung: tất cả đều là dịch vụ CHẶN LƯU LƯỢNG.

Firewall Manager quản lý các dịch vụ THỰC THI chính sách
    → không quản lý các dịch vụ PHÁT HIỆN
        ↓
    GuardDuty và Inspector chỉ PHÁT HIỆN, không chặn
    → nằm ngoài phạm vi của Firewall Manager

Ba chính sách security group của Firewall Manager: | Loại | Việc | |---|---| | Common security group | áp một security group chung cho tài nguyên khớp | | Content audit | kiểm tra và sửa security group vi phạm | | Usage audit | tìm security group không dùng hoặc dư thừa |

Content audit rất hữu ích:

{"securityGroupIsolationPolicy": {
   "auditSgIds": ["sg-mau-chuan"],
   "exclusiveResourceSecurityGroupManagement": false}}

Phát hiện security group mở cổng 22 cho 0.0.0.0/0
    → tự sửa hoặc báo vi phạm
        ↓
    Trên MỌI tài khoản trong tổ chức

Tạo policy WAF áp cho cả tổ chức:

aws fms put-policy --policy '{
  "PolicyName":"waf-toan-to-chuc",
  "SecurityServicePolicyData":{"Type":"WAFV2",
    "ManagedServiceData":"{\"type\":\"WAFV2\",\"preProcessRuleGroups\":[...]}"},
  "ResourceType":"AWS::ElasticLoadBalancingV2::LoadBalancer",
  "ExcludeResourceTags":false,
  "RemediationEnabled":true}'

RemediationEnabled: true là điểm mạnh nhất:

Tài nguyên MỚI tạo tự động được áp chính sách
    → không phải nhớ gắn WAF cho mỗi ALB mới
        ↓
    Đây là giá trị chính của Firewall Manager

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

• **A. Amazon GuardDuty — đây là phương án gần nhất vì cũng là dịch vụ bảo mật quản lý tập trung được, nhưng nó là dịch vụ PHÁT HIỆN, không phải thực thi: GuardDuty phân tích log tìm hành vi đe doạ, nó không có "rule" để Firewall Manager cấu hình. (GuardDuty bật đồng loạt bằng cơ chế delegated administrator riêng, không qua Firewall Manager.)
• **F. Amazon Inspector — cũng là dịch vụ phát hiện: quét lỗ hổng phần mềm trên EC2, container image và Lambda.
• **E. VPC Route Table — không phải dịch vụ bảo mật: route table là cấu hình định tuyến, Firewall Manager không đụng tới.

Ghi nhớ

Các dịch vụ bảo mật của AWS — phân loại theo vai trò: | Vai trò | Dịch vụ | |---|---| | THỰC THI (chặn) | WAF, Shield, Security Group, NACL, Network Firewall, DNS Firewall | | PHÁT HIỆN | GuardDuty, Inspector, Macie, Detective | | QUẢN TRỊ TẬP TRUNG | Firewall Manager (thực thi), Security Hub (phát hiện) |

Bảng này giải thích trọn vẹn câu hỏi: Firewall Manager quản lý nhóm thứ nhất.

Firewall Manager và Security Hub — bảng phân biệt: | | Firewall Manager | Security Hub | |---|---|---| | Việc | ÁP chính sách chặn | TỔNG HỢP phát hiện | | Quản lý | WAF, Shield, SG, Network Firewall | GuardDuty, Inspector, Macie, Config | | Hành động | thực thi và sửa vi phạm | báo cáo và cảnh báo |

Ba yêu cầu để dùng Firewall Manager: | Yêu cầu | Chi tiết | |---|---| | AWS Organizations với "all features" | | | Chỉ định tài khoản quản trị Firewall Manager | | | Bật AWS Config ở mọi tài khoản | bắt buộc |

Dòng cuối hay bị bỏ sót:

aws fms associate-admin-account --admin-account 123456789012

Firewall Manager dựa vào AWS Config để phát hiện tài nguyên
    → tài khoản chưa bật Config → tài nguyên không được bảo vệ
        ↓
    Và không có cảnh báo rõ ràng về việc đó

Ba loại chính sách của Firewall Manager: | Loại | Áp cho | |---|---| | WAF policy | ALB, CloudFront, API Gateway | | Shield Advanced policy | ELB, CloudFront, Global Accelerator, EIP | | Security group policy | EC2, ENI, security group | | Network Firewall policy | VPC | | DNS Firewall policy | VPC |

Ba tài nguyên gắn được WAF — nhắc lại: | Tài nguyên | Scope | |---|---| | CloudFront | CLOUDFRONT (us-east-1) | | ALB, API Gateway, AppSync, Cognito, App Runner | REGIONAL | | NLB, EC2 | ❌ không gắn được |

Ba tính năng của Shield Advanced: | Tính năng | Chi tiết | |---|---| | Bảo vệ DDoS nâng cao | tầng 3, 4 và 7 | | Đội DDoS Response Team (DRT) | hỗ trợ 24/7 | | Bảo vệ chi phí | hoàn tiền phần co giãn do DDoS |

Shield Advanced có phí ~3.000 USD/tháng cho cả tổ chức — đắt nhưng bảo vệ chi phí thường bù lại khi bị tấn công lớn.

Shield Standard và Advanced: | | Standard | Advanced | |---|---|---| | Chi phí | MIỄN PHÍ, tự động | ~3.000 USD/tháng | | Tầng bảo vệ | 3 và 4 | 3, 4 và 7 | | Đội hỗ trợ | ❌ | ✅ | | Bảo vệ chi phí | ❌ | ✅ |

Ba cách bật dịch vụ bảo mật cho cả tổ chức: | Dịch vụ | Cơ chế | |---|---| | WAF, Shield, SG | Firewall Manager | | GuardDuty, Inspector, Macie | delegated administrator + auto-enable | | Config, CloudTrail | Organizations trail và aggregator |

Bật GuardDuty cho cả tổ chức:

aws guardduty enable-organization-admin-account --admin-account-id 123456789012
aws guardduty update-organization-configuration --detector-id <id>   --auto-enable-organization-members ALL

Ba lưu ý về chi phí Firewall Manager: | Khoản | Giá tham khảo | |---|---| | Mỗi policy mỗi Region | ~100 USD/tháng | | Cộng chi phí của dịch vụ bên dưới | WAF, Shield | | Cần AWS Config | có phí riêng |

Ba lợi ích chính: | Lợi ích | Chi tiết | |---|---| | Tài nguyên MỚI tự được bảo vệ | ← giá trị lớn nhất | | Một chỗ để rà soát tuân thủ | | | Tự sửa vi phạm | remediation |

Và một lời khuyên: hãy bật AWS Config ở mọi tài khoản trước khi tạo policy Firewall Manager. Không có Config, Firewall Manager không nhìn thấy tài nguyên trong tài khoản đó — và bảng điều khiển sẽ hiển thị "compliant" cho một tài khoản mà thực ra nó chưa từng kiểm tra được.

Đáp án

B — Dùng EC2 Auto Scaling group với target tracking policy cho tầng xử lý, theo dõi metric ApproximateNumberOfMessagesVisible của hàng đợi SQS.

Vì sao đúng

Đề mô tả ba triệu chứng, và cả ba đều chỉ về một nguyên nhân: tầng xử lý không co giãn theo tải.

Triệu chứng:
    ① Xử lý đơn hàng chậm hẳn khi tải tăng
    ② Độ sâu hàng đợi SQS tăng nhanh
    ③ CPU của EC2 xử lý chạm 100%
        ↓
    Kiến trúc đã đúng (đã có SQS tách rời)
    → chỉ thiếu cơ chế THÊM MÁY khi tồn đọng tăng

Và độ sâu hàng đợi là metric đúng để co giãn:

Co giãn theo CPU:
    → CPU chạm 100% rồi mới thêm máy
    → tồn đọng đã lớn, người dùng đã chờ lâu

Co giãn theo ApproximateNumberOfMessagesVisible:
    → phản ánh trực tiếp lượng việc CHƯA LÀM
    → thêm máy trước khi CPU bão hoà
        ↓
    Metric phản ánh đúng bản chất tải của hệ thống hàng đợi

Cấu hình:

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-xu-ly-don   --policy-name theo-hang-doi --policy-type TargetTrackingScaling   --target-tracking-configuration '{
    "TargetValue": 20,
    "CustomizedMetricSpecification": {
      "MetricName": "ApproximateNumberOfMessagesVisible",
      "Namespace": "AWS/SQS", "Statistic": "Average",
      "Dimensions": [{"Name":"QueueName","Value":"hang-doi-don-hang"}]}}'

Và metric tốt hơn nữa là "tồn đọng trên mỗi instance":

Backlog per instance = số thông điệp ÷ số instance đang chạy
        ↓
Mục tiêu = (thời gian chờ chấp nhận được) ÷ (thời gian xử lý mỗi việc)

Ví dụ: chấp nhận chờ 5 phút, mỗi đơn mất 15 giây
    → 300 ÷ 15 = 20 đơn mỗi instance

Đây là công thức AWS khuyến nghị chính thức — nó tự thích ứng khi số instance thay đổi.

Đẩy metric tuỳ chỉnh:

so_thong_diep = int(sqs.get_queue_attributes(
    QueueUrl=url, AttributeNames=['ApproximateNumberOfMessages']
)['Attributes']['ApproximateNumberOfMessages'])
so_may = len(asg_instances_in_service)
cloudwatch.put_metric_data(Namespace='UngDung',
    MetricData=[{'MetricName':'TonDongMoiMay',
                 'Value': so_thong_diep / max(so_may, 1)}])

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

• **D. Dùng scheduled Auto Scaling theo giờ cao điểm quá khứ, ngưỡng theo CPU trung bình — đây là phương án gần nhất và có co giãn, nhưng nó không xử lý được tải KHÔNG ĐOÁN TRƯỚC: đề nói rõ "unpredictable traffic surges". Scheduled scaling chỉ hoạt động với mẫu tải lặp lại.
• **C. Thêm Kinesis Data Streams đệm sự kiện, dùng enhanced fan-out — thay một hàng đợi bằng một luồng mà không giải quyết gì: vấn đề không phải ở khả năng nạp dữ liệu (SQS đã làm tốt), mà ở năng lực xử lý. Enhanced fan-out tăng băng thông đọc, không tăng số máy xử lý.
• **A. Dùng EventBridge gọi worker mỗi 10 phút xử lý theo lô — thêm độ trễ lớn: đơn hàng phải chờ tới lần chạy tiếp theo, và không co giãn theo lượng việc.

Ghi nhớ

Ba metric của SQS dùng để co giãn — bảng phải thuộc: | Metric | Ý nghĩa | |---|---| | ApproximateNumberOfMessagesVisible | độ sâu hàng đợi ← câu này | | ApproximateAgeOfOldestMessage | việc chờ lâu nhất — chỉ báo trải nghiệm tốt nhất | | ApproximateNumberOfMessagesNotVisible | đang được xử lý |

Metric thứ hai đáng dùng làm cảnh báo:

Số thông điệp lớn mà xử lý nhanh → vẫn ổn
Thông điệp cũ nhất chờ 30 phút → LUÔN là vấn đề
        ↓
    Đặt alarm cho ApproximateAgeOfOldestMessage

Năm loại scaling policy — bảng nhắc lại: | Loại | Khi nào | |---|---| | Target tracking | đơn giản nhất, giữ metric ở mức mục tiêu ← câu này | | Step scaling | kiểm soát chi tiết theo bậc | | Simple scaling | cũ, chậm vì cooldown | | Scheduled scaling | tải BIẾT TRƯỚC theo giờ | | Predictive scaling | tải có chu kỳ, học máy |

Từ khoá nhận diện:

"unpredictable spikes", "queue depth grows" → target tracking theo metric SQS "known peak hours" → scheduled scaling "recurring daily/weekly pattern" → predictive scaling

Ba cấu hình ASG quan trọng: | Cấu hình | Chi tiết | |---|---| | EstimatedInstanceWarmup | bỏ qua máy mới khi tính metric | | MaxSize đủ lớn | chạm trần thì không mở rộng thêm | | Instance scale-in protection | không tắt máy đang bận |

Instance scale-in protection quan trọng với worker:

aws autoscaling set-instance-protection   --auto-scaling-group-name asg-xu-ly-don   --instance-ids i-0abc --protected-from-scale-in

Máy đang xử lý một đơn hàng dài
    → ASG chọn nó để thu hẹp
    → công việc bị bỏ dở
        ↓
    Bật bảo vệ khi bắt đầu xử lý, gỡ khi xong

Ba thông số SQS phải đặt đúng: | Thông số | Chi tiết | |---|---| | Visibility timeout ≥ thời gian xử lý dài nhất | tránh xử lý trùng | | Long polling (ReceiveMessageWaitTimeSeconds = 20) | giảm chi phí API | | DLQ với maxReceiveCount 3–5 | |

Ba yêu cầu với consumer: | Yêu cầu | Chi tiết | |---|---| | IDEMPOTENT | SQS Standard giao ít nhất một lần | | Chỉ xoá thông điệp SAU KHI xong | | | Lifecycle hook để hoàn tất việc trước khi tắt | |

Lifecycle hook bảo vệ công việc đang dở:

aws autoscaling put-lifecycle-hook   --auto-scaling-group-name asg-xu-ly-don   --lifecycle-hook-name cho-xong-viec   --lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING   --heartbeat-timeout 600

Ba lựa chọn thay thế cho ASG + SQS: | Lựa chọn | Đặc điểm | |---|---| | Lambda đọc từ SQS | tự co giãn hoàn toàn, giới hạn 15 phút | | AWS Batch | tự quản hàng đợi và năng lực | | ECS/Fargate co giãn theo SQS | container, không quản máy |

Lambda đáng cân nhắc nếu xử lý dưới 15 phút:

aws lambda create-event-source-mapping   --function-name xu-ly-don --event-source-arn <arn-sqs>   --batch-size 10 --scaling-config MaximumConcurrency=200

Lambda tự co giãn theo độ sâu hàng đợi
    → không phải cấu hình scaling policy nào
        ↓
    Ít công vận hành hơn hẳn ASG

Ba cách giảm chi phí: | Cách | Tiết kiệm | |---|---| | Spot cho tầng xử lý | tới 90% — việc trong SQS không mất | | Graviton | ~20% | | Kích thước instance đúng nhu cầu | |

Spot rất phù hợp với worker đọc SQS:

Máy bị thu hồi giữa lúc xử lý
    → thông điệp quay lại hàng đợi sau visibility timeout
    → máy khác nhận và làm lại
        ↓
    Không mất đơn hàng nào

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | trải nghiệm người dùng | | GroupInServiceInstances | số máy đang phục vụ | | Số thông điệp trong DLQ | có lỗi cần điều tra |

Và một lời khuyên: hãy dùng công thức "tồn đọng trên mỗi instance" thay vì số thông điệp tuyệt đối. Một mục tiêu cố định như "giữ hàng đợi dưới 100 thông điệp" sẽ hành xử rất khác khi bạn có 2 máy so với khi có 40 máy — còn công thức chia cho số instance tự thích ứng ở mọi quy mô.

Đáp án

C và D.

• C — Tạo S3 VPC endpoint trong VPC chứa ứng dụng để kết nối riêng tư tới S3
• D — Tạo Cognito identity pool cho danh tính liên kết, dùng nó sinh credential AWS tạm thời cấp quyền S3 khi người dùng xác thực thành công

Vì sao đúng

Đề nêu hai nhóm yêu cầu, và hai đáp án giải quyết đúng từng nhóm: | Yêu cầu | Đáp án | |---|---| | Phân quyền chi tiết, an toàn, mở rộng được tới S3 | D — identity pool sinh credential tạm | | Giữ kiến trúc mạng RIÊNG TƯ | C — VPC endpoint cho S3 |

D — điểm mấu chốt: user pool và identity pool là HAI thứ khác nhau.

Cognito USER POOL:
    → XÁC THỰC người dùng (đăng nhập, đăng ký, MFA)
    → trả về JWT token
    → KHÔNG cấp quyền AWS nào

Cognito IDENTITY POOL:
    → đổi token đó lấy CREDENTIAL AWS TẠM THỜI
    → qua STS AssumeRoleWithWebIdentity
        ↓
    Chỉ identity pool mới cho phép gọi S3 trực tiếp

Và phân quyền tới từng người dùng bằng biến chính sách:

{"Effect": "Allow",
 "Action": ["s3:GetObject", "s3:PutObject"],
 "Resource": "arn:aws:s3:::tai-lieu-hoc-vien/${cognito-identity.amazonaws.com:sub}/*"}

${cognito-identity.amazonaws.com:sub} = định danh của người dùng
        ↓
    Mỗi học viên CHỈ truy cập được thư mục của mình
    → một policy duy nhất phục vụ mọi người dùng
    → đây chính là "scalable, fine-grained"

C — VPC endpoint giữ lưu lượng trong mạng AWS:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc   --service-name com.amazonaws.ap-northeast-1.s3   --vpc-endpoint-type Gateway --route-table-ids rtb-private

Ứng dụng ở PRIVATE subnet gọi S3
    → không có endpoint: phải qua NAT Gateway → Internet
    → có gateway endpoint: đi trong mạng AWS
        ↓
    ✓ giữ kiến trúc riêng tư
    ✓ tiết kiệm phí NAT
    ✓ gateway endpoint MIỄN PHÍ

Luồng hoàn chỉnh:

Người dùng đăng nhập → Cognito User Pool → JWT
    ↓
JWT → Cognito Identity Pool → credential AWS tạm (1 giờ)
    ↓
Client gọi S3 trực tiếp bằng credential đó
    ↓
Ứng dụng backend gọi S3 qua VPC endpoint (riêng tư)

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

• **E. Dùng user pool trực tiếp cấp quyền tải lên và tải xuống object — đây là phương án gần nhất và là hiểu lầm phổ biến nhất về Cognito: user pool chỉ xác thực, nó không sinh được credential AWS. Phải qua identity pool.
• **A. Viết Lambda làm proxy cho mọi lần tải lên, gọi sau mỗi lần đăng nhập — thêm tầng không cần thiết và tạo nút thắt: mọi byte phải đi qua Lambda (giới hạn payload 6 MB đồng bộ), tốn tiền và chậm hơn.
• **B. Bucket policy chỉ cho phép nếu request có HTTP header tuỳ chỉnh chứa Cognito user ID — không phải cơ chế bảo mật: header do client tự đặt, ai cũng giả mạo được. Đây là lỗ hổng nghiêm trọng.

Ghi nhớ

Cognito User Pool và Identity Pool — bảng phải thuộc: | | User Pool | Identity Pool (Federated Identities) | |---|---|---| | Việc | XÁC THỰC — ai là ai | UỶ QUYỀN — được làm gì trên AWS | | Trả về | JWT token | credential AWS TẠM THỜI | | Gọi được S3, DynamoDB trực tiếp | ❌ | ✅ | | Tính năng | đăng ký, MFA, khôi phục mật khẩu | assume IAM role |

Quy tắc: cần gọi dịch vụ AWS từ client → BẮT BUỘC có identity pool.

Ba nguồn danh tính của identity pool: | Nguồn | Chi tiết | |---|---| | Cognito user pool | ← câu này | | Nhà cung cấp xã hội | Google, Facebook, Apple | | SAML hoặc OIDC | IdP doanh nghiệp | | Guest (unauthenticated) | quyền hạn chế cho khách |

Ba biến chính sách hữu ích: | Biến | Nghĩa | |---|---| | ${cognito-identity.amazonaws.com:sub} | định danh duy nhất của người dùng | | ${aws:userid} | định danh của principal | | ${aws:PrincipalTag/...} | tag của principal (ABAC) |

Ba cách phân quyền trong identity pool: | Cách | Chi tiết | |---|---| | Default role (authenticated / unauthenticated) | đơn giản nhất | | Rule-based role mapping | chọn role theo claim trong token | | Token-based role mapping | claim cognito:roles quyết định |

Rule-based rất hữu ích:

Claim "custom:vai_tro" = "giang_vien" → role giảng viên
Claim "custom:vai_tro" = "hoc_vien"   → role học viên
        ↓
    Một identity pool phục vụ nhiều nhóm quyền

Hai loại VPC endpoint — nhắc lại: | | Gateway | Interface (PrivateLink) | |---|---|---| | Dịch vụ | CHỈ S3 và DynamoDB | hầu hết dịch vụ | | Cơ chế | route trong route table | ENI có IP riêng | | Chi phí | MIỄN PHÍ | ~0,01 USD/giờ mỗi AZ | | Từ on-premises | ❌ | ✅ |

Với S3 trong VPC, gateway endpoint là lựa chọn đúng — miễn phí.

Ba cách tăng cường bảo mật bucket: | Cách | Chi tiết | |---|---| | aws:SourceVpce trong bucket policy | CHỈ cho phép qua endpoint | | Block Public Access | ở cấp tài khoản | | Mã hoá SSE-KMS | với Bucket Keys |

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::tai-lieu-hoc-vien",
              "arn:aws:s3:::tai-lieu-hoc-vien/*"],
 "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc"}}}

Lưu ý: điều kiện này chặn cả client gọi từ ngoài VPC — cần cân nhắc nếu người dùng tải trực tiếp lên S3.

Ba mẫu tải tệp lên S3 từ client: | Mẫu | Đặc điểm | |---|---| | Credential tạm từ identity pool | client gọi trực tiếp ← câu này | | Presigned URL từ backend | backend kiểm soát hoàn toàn | | Qua API Gateway và Lambda | tốn tiền, giới hạn kích thước |

Presigned URL là lựa chọn thay thế tốt:

url = s3.generate_presigned_post(
    Bucket='tai-lieu-hoc-vien', Key=f'{ma_hoc_vien}/{ten_tep}',
    Conditions=[['content-length-range', 0, 10485760]],
    ExpiresIn=3600)

Có thêm khả năng giới hạn kích thước tệp — điều mà credential tạm không làm được.

Ba lưu ý về credential tạm: | Lưu ý | Chi tiết | |---|---| | Mặc định hết hạn sau 1 giờ | | | SDK tự làm mới | | | Quyền theo IAM role của identity pool | |

Ba lưu ý về CORS: | Lưu ý | Chi tiết | |---|---| | Bucket phải có CORS configuration | cho tải lên từ trình duyệt | | Khai đúng origin, method, header | | | Thiếu CORS: lỗi im lặng trong trình duyệt | |

[{"AllowedOrigins": ["https://hoc.vidu.com"],
  "AllowedMethods": ["GET", "PUT", "POST"],
  "AllowedHeaders": ["*"],
  "ExposeHeaders": ["ETag"], "MaxAgeSeconds": 3000}]

Ba biện pháp bảo mật bổ sung: | Biện pháp | Chi tiết | |---|---| | Bật MFA trong user pool | | | Giới hạn kích thước và loại tệp | ở tầng ứng dụng | | Quét mã độc tệp tải lên | GuardDuty Malware Protection for S3 |

Và một lời khuyên: hãy dùng biến ${cognito-identity.amazonaws.com:sub} trong Resource của policy. Đó là cách duy nhất để một policy duy nhất phục vụ hàng nghìn người dùng mà mỗi người chỉ thấy dữ liệu của mình — và nó không cần bất kỳ mã kiểm tra quyền nào ở tầng ứng dụng.

Đáp án

B và E.

• B — Nếu tạo AMI từ một instance, dữ liệu trên instance store volume KHÔNG được giữ lại
• E — KHÔNG tháo instance store volume khỏi một instance để gắn vào instance khác được

Vì sao đúng

B — AMI chỉ chụp EBS volume:

create-image từ một instance:
    ✓ chụp snapshot của các EBS volume
    ✗ KHÔNG chụp dữ liệu instance store
        ↓
    Instance khởi động từ AMI đó có instance store TRỐNG

Điều này hợp lý vì instance store gắn với phần cứng cụ thể:

Instance store là ổ NVMe/SSD gắn TRỰC TIẾP vào máy chủ vật lý
    → nó không phải tài nguyên độc lập
    → không có khái niệm snapshot cho nó

E — không tháo và gắn lại được:

EBS volume:
    → tài nguyên ĐỘC LẬP, có ID riêng
    → detach từ máy này, attach vào máy khác

Instance store:
    → gắn cứng vào máy chủ vật lý đang chạy instance
    → KHÔNG có API detach/attach
        ↓
    Vòng đời gắn chặt với vòng đời instance

Bảng vòng đời dữ liệu instance store: | Thao tác | Dữ liệu | |---|---| | Reboot | CÒN | | Stop / Start | MẤT | | Hibernate | MẤT | | Terminate | MẤT | | Hỏng phần cứng | MẤT |

Và instance store phải tự khởi tạo:

lsblk                              # tìm ổ NVMe
sudo mkfs -t xfs /dev/nvme1n1
sudo mkdir /scratch && sudo mount /dev/nvme1n1 /scratch

Ổ instance store KHÔNG được định dạng sẵn — phải làm trong user data hoặc AMI.

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

• **D. Instance store bị xoá khi stop hoặc terminate, nhưng dữ liệu được GIỮ khi hibernate — đây là phương án gần nhất và vế đầu hoàn toàn đúng, nhưng vế sau sai: hibernate lưu nội dung RAM vào EBS root volume, và dữ liệu instance store vẫn MẤT. (Đó cũng là lý do instance có instance store không hibernate được trong nhiều trường hợp.)
• **A. Có thể khai instance store volume khi launch HOẶC khi restart — sai vế sau: instance store chỉ khai được lúc launch, không thêm được sau. (Và số lượng ổ cố định theo loại instance.)
• **C. Instance store là loại lưu trữ MẠNG — ngược hoàn toàn: instance store gắn trực tiếp vào máy chủ vật lý, không đi qua mạng. Đó chính là lý do nó nhanh nhất. (EBS mới là lưu trữ qua mạng.)

Ghi nhớ

Instance store và EBS — bảng phải thuộc: | | Instance store | EBS | |---|---|---| | Kết nối | trực tiếp vào máy chủ vật lý | qua mạng | | Hiệu năng | cao nhất (micro giây) | dưới mili giây | | Bền vững | ❌ mất khi stop/terminate | ✅ | | Tháo gắn lại | ❌ | ✅ | | Snapshot | ❌ | ✅ | | Có trong AMI | ❌ | ✅ | | Đổi kích thước | ❌ cố định theo loại instance | ✅ | | Chi phí | đã trong giá instance | tính riêng |

Ba trường hợp dùng instance store: | Trường hợp | Lý do | |---|---| | Không gian làm việc tạm (scratch) | dữ liệu tái tạo được | | Bộ đệm | | | Bản sao của cụm phân tán | Cassandra, Elasticsearch |

Nguyên tắc: chỉ để dữ liệu TÁI TẠO ĐƯỢC trên instance store.

Ba họ instance có instance store lớn: | Họ | Đặc điểm | |---|---| | i4i, i3en | tối ưu lưu trữ, NVMe dung lượng lớn nhất | | d3, d3en | HDD dung lượng rất lớn | | m6id, c6id, r6id | biến thể "d" của họ thông thường |

Chữ "d" trong tên loại instance nghĩa là có instance store.

Ba đặc điểm của instance store NVMe hiện đại: | Đặc điểm | Chi tiết | |---|---| | Mã hoá TỰ ĐỘNG, không tắt được | khoá do phần cứng quản lý | | Hàng triệu IOPS | | | Bị xoá an toàn khi instance kết thúc | |

Ba lưu ý khi thiết kế với instance store: | Lưu ý | Chi tiết | |---|---| | Ghi kết quả lên S3 theo từng phần | không đợi tới cuối | | Quy trình phải làm lại được từ đầu | | | Khởi tạo ổ trong user data | chưa được định dạng sẵn |

User data khởi tạo instance store:

#!/bin/bash
DEV=$(lsblk -dn -o NAME,MODEL | grep -i "Instance Storage" | head -1 | awk '{print "/dev/"$1}')
if [ -n "$DEV" ]; then
  mkfs -t xfs "$DEV"
  mkdir -p /scratch && mount "$DEV" /scratch && chmod 777 /scratch
fi

Ba lưu ý về RAID với nhiều ổ instance store: | Lưu ý | Chi tiết | |---|---| | RAID 0 cộng dồn IOPS và thông lượng | | | Không cần RAID 1 | dữ liệu vốn đã không bền | | Phải dựng lại sau mỗi lần khởi động | |

sudo mdadm --create /dev/md0 --level=0 --raid-devices=4   /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1 /dev/nvme4n1

Ba đặc điểm của hibernate (để phân biệt với phương án D): | Đặc điểm | Chi tiết | |---|---| | Lưu nội dung RAM vào EBS root volume | | | Root volume phải mã hoá và đủ lớn | | | Dữ liệu instance store VẪN MẤT | ← điểm của câu này |

Ba lựa chọn lưu trữ theo nhu cầu: | Nhu cầu | Chọn | |---|---| | Hiệu năng tối đa, dữ liệu tạm | instance store | | Bền vững, gắn một máy | EBS | | Chia sẻ nhiều máy | EFS, FSx, S3 |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Instance store MIỄN PHÍ | đã trong giá instance | | Instance có NVMe đắt hơn loại thường một chút | | | Kết hợp với Spot cho tải tái tạo được | rẻ nhất |

Ba lưu ý khi tạo AMI: | Lưu ý | Chi tiết | |---|---| | AMI chỉ chứa snapshot EBS | ← đáp án B | | --no-reboot để không dừng instance | nhưng có thể không nhất quán | | Dọn AMI và snapshot cũ định kỳ | |

Ba metric của instance store: | Metric | Ghi chú | |---|---| | DiskReadOps, DiskWriteOps | chỉ cho instance store, không phải EBS | | DiskReadBytes, DiskWriteBytes | | | — | metric EBS có tiền tố EBS riêng |

Chi tiết này hay gây nhầm: metric có tên Disk* là của instance store, EBS* mới là của EBS volume.

Và một lời khuyên: hãy thiết kế quy trình sao cho mất một máy chỉ tốn vài phút làm lại. Với instance store, việc mất dữ liệu không phải là rủi ro cần phòng tránh mà là hành vi bình thường cần chấp nhận — và cách duy nhất để sống chung với nó là ghi kết quả ra S3 liên tục thay vì tích luỹ trên đĩa cục bộ.