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

Tìm thấy 2194 câu.

Câu 431 Design Cost-Optimized Architectures

A company runs a data processing workflow that takes about 60 minutes to complete. The workflow can withstand disruptions and it can be started and stopped multiple times.

Which is the most cost-effective solution to build a solution for the workflow?

  1. A

    Use Amazon EC2 reserved instances to run the workflow processes
  2. B

    Use Amazon EC2 on-demand instances to run the workflow processes
  3. C

    Use AWS Lambda function to run the workflow processes
  4. D

    Use Amazon EC2 spot instances to run the workflow processes
Xem giải thích

Đáp án

D — Dùng Amazon EC2 Spot Instances.

Vì sao đúng

Đề mô tả đúng ba đặc điểm mà Spot yêu cầu: | Đặc điểm trong đề | Vì sao hợp với Spot | |---|---| | Chịu được gián đoạn | Spot bị thu hồi khi AWS cần năng lực | | Dừng và khởi động lại nhiều lần được | không mất tiến độ khi bị thu hồi | | Chạy khoảng 60 phút | vượt giới hạn 15 phút của Lambda |

Và Spot rẻ hơn rất nhiều:

Spot Instance:
    → dùng năng lực DƯ THỪA của AWS
    → giảm tới 90% so với On-Demand
    → đổi lại: AWS thu hồi khi cần, báo trước 2 PHÚT

Bảng so sánh giá tham khảo: | Mô hình | Giá tương đối | |---|---| | On-Demand | 100% | | Reserved / Savings Plans (1 năm) | ~60% | | Reserved / Savings Plans (3 năm) | ~40% | | Spot | 10–30% |

Và cơ chế báo trước 2 phút cho phép xử lý êm:

AWS gửi thông báo thu hồi vào instance metadata
    ↓ ứng dụng kiểm tra định kỳ
Phát hiện → lưu điểm kiểm tra (checkpoint) → thoát sạch
    ↓
    Lần chạy sau tiếp tục từ điểm đã lưu

# Kiểm tra thông báo thu hồi (IMDSv2)
TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token"   -H "X-aws-ec2-metadata-token-ttl-seconds: 300")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN"   http://169.254.169.254/latest/meta-data/spot/instance-action

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

  • **B. Dùng On-Demand Instances — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó đắt hơn Spot tới 10 lần cho đúng cùng một công việc. Khi workload chịu được gián đoạn, trả giá On-Demand là trả tiền cho một đảm bảo mình không cần.
  • **A. Dùng Reserved Instances — sai mô hình cam kết: RI đòi cam kết 1 hoặc 3 năm cho năng lực chạy liên tục. Workload chạy từng đợt sẽ lãng phí phần lớn thời gian đã trả tiền.
  • **C. Dùng AWS Lambda — vượt giới hạn kỹ thuật: quy trình chạy 60 phút, Lambda tối đa 15 phút.

Ghi nhớ

Bốn mô hình mua EC2 — bảng cần thuộc: | Mô hình | Cam kết | Giảm giá | Phù hợp | |---|---|---|---| | On-Demand | không | 0% | tải khó đoán, ngắn hạn | | Savings Plans | 1 hoặc 3 năm, theo USD/giờ | tới 72% | tải ổn định — LINH HOẠT nhất | | Reserved Instances | 1 hoặc 3 năm, theo cấu hình | tới 72% | tải ổn định, cấu hình cố định | | Spot | không | tới 90% | chịu được gián đoạn ← câu này | | Dedicated Host | tuỳ | — | yêu cầu giấy phép hoặc tuân thủ |

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

"fault-tolerant", "can be interrupted", "flexible start/end time", "batch" → Spot "steady state", "24/7", "predictable" → Savings Plans hoặc RI "unpredictable", "short-term spike" → On-Demand "under 15 minutes", "event-driven" → Lambda

Ba đặc điểm của Spot cần nhớ: | Đặc điểm | Chi tiết | |---|---| | Báo trước 2 phút | qua instance metadata và EventBridge | | Giá thay đổi theo cung cầu | nhưng ổn định hơn nhiều so với trước 2017 | | Không đảm bảo có năng lực | pool có thể hết máy |

Ba loại workload phù hợp với Spot: | Loại | Ví dụ | |---|---| | Xử lý lô | ETL, kết xuất video, phân tích ← câu này | | CI/CD | build và test | | Huấn luyện mô hình có checkpoint | học máy | | Container không trạng thái | web tier có ASG |

Và ba loại KHÔNG nên dùng Spot:

❌ Database và kho trạng thái
❌ Dịch vụ đòi sẵn sàng liên tục không gián đoạn
❌ Việc chạy lâu KHÔNG có checkpoint

Ba cách tăng độ ổn định khi dùng Spot: | Cách | Chi tiết | |---|---| | Đa dạng hoá loại instance và AZ | quan trọng nhất — nhiều pool thì ít bị thu hồi cùng lúc | | Chiến lược capacity-optimized | chọn pool có năng lực dồi dào nhất | | Trộn Spot với On-Demand | giữ mức nền đảm bảo |

Cấu hình trộn trong launch template:

{"InstancesDistribution": {
   "OnDemandBaseCapacity": 2,
   "OnDemandPercentageAboveBaseCapacity": 20,
   "SpotAllocationStrategy": "capacity-optimized"},
 "Overrides": [
   {"InstanceType": "m5.large"}, {"InstanceType": "m5a.large"},
   {"InstanceType": "m6i.large"}, {"InstanceType": "m5n.large"}]}

Càng nhiều loại instance thay thế được, tỷ lệ bị thu hồi càng thấp.

Ba cách nhận thông báo thu hồi: | Cách | Chi tiết | |---|---| | Instance metadata | ứng dụng tự hỏi mỗi 5 giây | | EventBridge event | EC2 Spot Instance Interruption Warning | | ASG lifecycle hook | xử lý êm trước khi máy bị gỡ |

Và Spot Instance Rebalance Recommendation đến SỚM HƠN:

Rebalance recommendation: cảnh báo pool sắp căng, SỚM hơn 2 phút
    → có nhiều thời gian hơn để dịch chuyển công việc

Ba dịch vụ tự dùng Spot rất tốt: | Dịch vụ | Chi tiết | |---|---| | AWS Batch | tự quản lý hàng đợi và thử lại | | EMR | node lõi On-Demand, node task Spot | | ECS/EKS với Fargate Spot | container không trạng thái |

AWS Batch đáng cân nhắc cho đúng tình huống trong đề:

AWS Batch:
    ✓ tự cấp và thu hồi năng lực tính toán
    ✓ tự thử lại khi job bị gián đoạn
    ✓ quản lý hàng đợi và mức ưu tiên
    ✓ dùng Spot mặc định với chiến lược tối ưu
        ↓
    Ít công vận hành hơn tự dựng ASG với Spot

Ba cách kiểm chứng khoản tiết kiệm: | Công cụ | Việc | |---|---| | Cost Explorer | so chi phí trước và sau | | Spot Instance advisor | xem tần suất bị thu hồi của từng loại instance | | Spot placement score | Region và AZ nào có năng lực tốt nhất |

Và một lời khuyên: hãy xem Spot Instance Advisor trước khi chọn loại máy. Nó cho biết tỷ lệ bị thu hồi lịch sử của từng loại — một số loại phổ biến có tỷ lệ trên 20%, trong khi loại thế hệ cũ hơn thường dưới 5% với mức giảm giá tương đương.

Câu 432 Design Cost-Optimized Architectures

A technology blogger wants to write a review on the comparative pricing for various storage types available on AWS Cloud. The blogger has created a test file of size 1 gigabytes with some random data. Next he copies this test file into AWS S3 Standard storage class, provisions an Amazon EBS volume (General Purpose SSD (gp2)) with 100 gigabytes of provisioned storage and copies the test file into the Amazon EBS volume, and lastly copies the test file into an Amazon EFS Standard Storage filesystem. At the end of the month, he analyses the bill for costs incurred on the respective storage types for the test file.

What is the correct order of the storage charges incurred for the test file on these three storage types?

  1. A

    Cost of test file storage on Amazon S3 Standard < Cost of test file storage on Amazon EFS < Cost of test file storage on Amazon EBS
  2. B

    Cost of test file storage on Amazon EBS < Cost of test file storage on Amazon S3 Standard < Cost of test file storage on Amazon EFS
  3. C

    Cost of test file storage on Amazon EFS < Cost of test file storage on Amazon S3 Standard < Cost of test file storage on Amazon EBS
  4. D

    Cost of test file storage on Amazon S3 Standard < Cost of test file storage on Amazon EBS < Cost of test file storage on Amazon EFS
Xem giải thích

Đáp án

A — Chi phí trên S3 Standard < chi phí trên EFS < chi phí trên EBS.

Vì sao đúng

Đây là câu tính toán, và điểm mấu chốt nằm ở cách tính phí khác nhau của ba dịch vụ:

Bảng tính cho tệp 1 GB: | Dịch vụ | Cách tính | Số tiền mỗi tháng | |---|---|---| | S3 Standard | theo dữ liệu THỰC TẾ lưu | 1 GB × 0,023 = ~0,023 USD | | EFS Standard | theo dữ liệu THỰC TẾ lưu | 1 GB × 0,30 = ~0,30 USD | | EBS gp2 | theo dung lượng CẤP PHÁT | 100 GB × 0,10 = ~10 USD |

Điểm bẫy của câu hỏi nằm ở EBS:

Tệp chỉ 1 GB, nhưng volume được CẤP PHÁT 100 GB
    ↓
    EBS tính tiền theo dung lượng CẤP PHÁT, không phải dung lượng DÙNG
    → trả tiền cho đủ 100 GB dù chỉ dùng 1 GB
        ↓
    Đắt hơn S3 khoảng 430 lần cho cùng một tệp

Và thứ tự: 0,023 < 0,30 < 10 → S3 < EFS < EBS.

Vì sao S3 rẻ nhất:

S3 là kho object, thiết kế cho quy mô rất lớn
    → hạ tầng tối ưu cực độ cho chi phí mỗi GB
    → không cần cấp phát trước
    → không có chi phí gắn với một máy chủ nào

Và vì sao EFS đắt hơn S3 khoảng 13 lần:

EFS cung cấp ngữ nghĩa HỆ THỐNG TỆP POSIX
    → khoá tệp, quyền, thư mục, ghi tại chỗ
    → nhiều máy mount đồng thời
    → hạ tầng phức tạp hơn nhiều so với kho object

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

  • **D. S3 < EBS < EFS — đây là phương án gần nhất vì cũng đặt S3 rẻ nhất, nhưng nó đảo ngược hai vị trí sau: EBS trong bài toán này bị tính đủ 100 GB cấp phát nên đắt nhất, còn EFS chỉ tính 1 GB thật.
  • **B. EBS < S3 < EFS — sai vị trí EBS: 10 USD không thể rẻ hơn 0,023 USD.
  • **C. EFS < S3 < EBS — sai vị trí EFS và S3: EFS đắt hơn S3 khoảng 13 lần mỗi GB.

Ghi nhớ

Ba mô hình tính phí lưu trữ — bảng cần thuộc: | Dịch vụ | Tính theo | Hệ quả | |---|---|---| | S3 | dữ liệu THỰC TẾ | không lãng phí | | EFS | dữ liệu THỰC TẾ, tự co giãn | không lãng phí | | EBS | dung lượng CẤP PHÁT | cấp thừa = trả tiền thừa | | FSx | dung lượng cấp phát | như EBS |

Đây là điểm phân biệt quan trọng nhất giữa EBS và hai dịch vụ kia.

Giá tham khảo mỗi GB-tháng (us-east-1): | Lớp | Giá | |---|---| | S3 Glacier Deep Archive | ~0,00099 USD | | S3 Glacier Instant Retrieval | ~0,004 USD | | S3 Standard-IA | ~0,0125 USD | | S3 Standard | ~0,023 USD | | EBS sc1 (Cold HDD) | ~0,015 USD | | EBS st1 | ~0,045 USD | | EBS gp3 | ~0,08 USD | | EBS gp2 | ~0,10 USD | | EBS io2 | ~0,125 USD + phí IOPS | | EFS One Zone-IA | ~0,016 USD | | EFS Standard-IA | ~0,025 USD | | EFS Standard | ~0,30 USD |

Quy tắc thứ tự cần nhớ: S3 < EBS (mỗi GB) < EFS (mỗi GB) — nhưng khi EBS bị cấp thừa, thứ tự tổng chi phí đảo lại như câu này.

Ba khoản phí ẩn thường bị bỏ qua: | Dịch vụ | Khoản ẩn | |---|---| | S3 | phí REQUEST và phí TRUY XUẤT của lớp IA/Glacier | | EBS | snapshot tích tụ; volume available vẫn tính tiền | | EFS | phí thông lượng nếu dùng chế độ Provisioned |

Volume EBS mồ côi là lãng phí phổ biến nhất:

Terminate instance mà DeleteOnTermination = false
    → volume ở trạng thái "available"
    → KHÔNG gắn với máy nào
    → VẪN tính tiền đủ 100%

aws ec2 describe-volumes --filters Name=status,Values=available   --query 'Volumes[].{Id:VolumeId,GB:Size,Tao:CreateTime}' --output table

Nên chạy lệnh này định kỳ — hầu hết tài khoản đều có vài volume kiểu này.

Ba cách giảm chi phí EBS: | Cách | Tiết kiệm | |---|---| | Chuyển gp2 sang gp3 | ~20%, một lệnh, không gián đoạn | | Cấp đúng dung lượng cần | EBS mở rộng được sau, không cần cấp thừa | | Dọn snapshot bằng Data Lifecycle Manager | snapshot tích tụ âm thầm |

Và EBS mở rộng được khi đang chạy:

aws ec2 modify-volume --volume-id vol-0abc123 --size 200
# rồi mở rộng hệ thống tệp trong OS
sudo growpart /dev/nvme0n1 1 && sudo resize2fs /dev/nvme0n1p1

Nên bắt đầu nhỏ và mở rộng khi cần — không mở rộng được thì mới phải cấp thừa.

Ba lưu ý về chi phí EFS: | Lưu ý | Chi tiết | |---|---| | Bật lifecycle sang IA | giảm ~90% cho tệp ít truy cập | | Elastic throughput là mặc định mới | trả theo lượng dùng thật | | Provisioned throughput tính phí dù không dùng | chỉ bật khi thực sự cần |

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

Ba câu hỏi để chọn đúng loại lưu trữ:

① Cần ngữ nghĩa hệ thống tệp POSIX không?
      Không → S3 (rẻ nhất)
② Nhiều máy cùng truy cập không?
      Có → EFS;  Không → EBS
③ Dung lượng có biết trước không?
      Không → EFS (tự co giãn);  Có → EBS

Ba công cụ theo dõi chi phí: | Công cụ | Việc | |---|---| | Cost Explorer | phân tích theo dịch vụ và thẻ | | S3 Storage Lens | phân bố dung lượng theo prefix và lớp | | Trusted Advisor | phát hiện volume mồ côi và tài nguyên nhàn rỗi | | AWS Budgets | cảnh báo khi vượt ngưỡng |

Và một lời khuyên: hãy gắn thẻ mọi volume EBS theo dự án và chủ sở hữu ngay từ đầu. Khi hoá đơn tăng, câu hỏi đầu tiên luôn là "volume này của ai và còn dùng không" — không có thẻ thì không ai dám xoá, và chúng nằm đó tính tiền hàng năm trời.

Câu 433 Design High-Performing Architectures

A data analytics company measures what the consumers watch and what advertising they’re exposed to. This real-time data is ingested into its on-premises data center and subsequently, the daily data feed is compressed into a single file and uploaded on Amazon S3 for backup. The typical compressed file size is around 2 gigabytes.

Which of the following is the fastest way to upload the daily compressed file into Amazon S3?

  1. A

    FTP the compressed file into an Amazon EC2 instance that runs in the same region as the Amazon S3 bucket. Then transfer the file from the Amazon EC2 instance into the Amazon S3 bucket
  2. B

    Upload the compressed file using multipart upload with Amazon S3 Transfer Acceleration (Amazon S3TA)
  3. C

    Upload the compressed file using multipart upload
  4. D

    Upload the compressed file in a single operation
Xem giải thích

Đáp án

B — Tải tệp nén lên bằng multipart upload KẾT HỢP với Amazon S3 Transfer Acceleration (S3TA).

Vì sao đúng

Đề cho hai dữ kiện, và mỗi dữ kiện đòi một kỹ thuật: | Dữ kiện | Kỹ thuật | |---|---| | Tệp khoảng 2 GB | multipart upload — chia và tải song song | | Từ trung tâm dữ liệu TẠI CHỖ lên S3 | S3TA — vào mạng AWS sớm nhất có thể |

Và đề hỏi cách NHANH NHẤT, nên câu trả lời là dùng CẢ HAI.

Multipart giải quyết nút thắt của một luồng TCP:

Một luồng TCP đơn:
    → thông lượng bị giới hạn bởi cửa sổ TCP và độ trễ
    → đường truyền có độ trễ cao thì một luồng không bao giờ đầy băng thông

20 luồng song song:
    → mỗi luồng tải một phần
    → tổng thông lượng gấp nhiều lần

S3TA giải quyết nút thắt của khoảng cách:

Không có S3TA:
    Trung tâm dữ liệu → Internet công cộng (nhiều chặng, mất gói) → S3

Có S3TA:
    Trung tâm dữ liệu → điểm biên CloudFront GẦN NHẤT
                      → mạng xương sống riêng của AWS → S3

Cấu hình và chạy:

aws s3api put-bucket-accelerate-configuration   --bucket kho-du-lieu --accelerate-configuration Status=Enabled

aws configure set default.s3.multipart_threshold 64MB
aws configure set default.s3.multipart_chunksize 64MB
aws configure set default.s3.max_concurrent_requests 20
aws configure set default.s3.use_accelerate_endpoint true

aws s3 cp du-lieu-hang-ngay.gz s3://kho-du-lieu/

Hai kỹ thuật này hoàn toàn tương thích — S3TA chỉ đổi endpoint, còn multipart là cách gửi.

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

  • **C. Tải lên bằng multipart upload (không có S3TA) — đây là phương án gần nhất và thực sự nhanh hơn tải một lần, nhưng nó bỏ mất một nửa cải thiện: nó tận dụng được băng thông nhưng vẫn đi qua Internet công cộng suốt quãng đường tới S3.
  • **A. FTP tệp lên EC2 trong cùng Region với bucket, rồi chuyển từ EC2 vào S3 — thêm một chặng và chậm hơn: chặng khó nhất (từ trung tâm dữ liệu ra AWS) vẫn phải đi, mà giờ còn qua FTP (giao thức kém hiệu quả hơn). Cộng thêm chi phí EC2 và công vận hành.
  • **D. Tải lên trong một thao tác duy nhất — chậm nhất: một luồng TCP, không tận dụng băng thông, và hỏng giữa chừng thì làm lại từ đầu 2 GB.

Ghi nhớ

Ba kỹ thuật tăng tốc tải lên S3 — giải quyết ba nút thắt: | Kỹ thuật | Nút thắt | |---|---| | Multipart upload | một luồng TCP không đủ nhanh | | S3 Transfer Acceleration | khoảng cách địa lý | | Nhiều prefix | trần request mỗi giây |

Khi đề hỏi "nhanh nhất", đáp án thường là KẾT HỢP.

Ba ngưỡng của multipart: | Ngưỡng | Giá trị | |---|---| | Bắt buộc | trên 5 GB | | AWS khuyến nghị | trên 100 MB | | Kích thước phần | 5 MB – 5 GB | | Số phần tối đa | 10.000 |

Bốn lợi ích của multipart: | Lợi ích | Chi tiết | |---|---| | Thông lượng cao hơn | tải song song | | Phục hồi nhanh | chỉ tải lại phần hỏng | | Tạm dừng và tiếp tục | | | Tải khi chưa biết tổng kích thước | luồng dữ liệu |

Và phần dở dang phải được dọn:

{"Rules": [{"Status": "Enabled",
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

aws s3api list-multipart-uploads --bucket kho-du-lieu

Phần dở dang không hiện trong s3 ls nhưng vẫn tính tiền — với tệp 2 GB tải mỗi ngày, chúng tích tụ rất nhanh nếu có lỗi.

Ba đặc điểm của S3TA: | Đặc điểm | Chi tiết | |---|---| | Endpoint riêng | bucket.s3-accelerate.amazonaws.com | | CHỈ tính phí khi thực sự nhanh hơn | AWS tự đo | | Tên bucket không được chứa dấu chấm | yêu cầu của endpoint |

Dòng cuối là ràng buộc hay bị quên — bucket tên du-lieu.congty.com không bật S3TA được.

Và công cụ đo trước khi bật:

s3-accelerate-speedtest.s3-accelerate.amazonaws.com
    → so tốc độ có và không có S3TA từ vị trí của bạn tới mọi Region

Ba trường hợp S3TA KHÔNG giúp: | Trường hợp | Lý do | |---|---| | Cùng Region với bucket | đã gần rồi | | Tệp rất nhỏ | chi phí thiết lập lấn át | | Nghẽn ở đường truyền của chính bạn | S3TA không nới được băng thông |

Ba tham số của AWS CLI ảnh hưởng tốc độ: | Tham số | Việc | |---|---| | max_concurrent_requests | số luồng song song (mặc định 10) | | multipart_chunksize | kích thước mỗi phần | | multipart_threshold | từ cỡ nào thì dùng multipart |

Tăng số luồng là cách cải thiện dễ nhất:

aws configure set default.s3.max_concurrent_requests 30

Nhưng đừng tăng quá mức — vượt băng thông sẵn có sẽ gây mất gói và làm chậm lại.

Các lựa chọn di chuyển dữ liệu — chọn theo khối lượng: | Khối lượng | Công cụ | |---|---| | Vài GB mỗi ngày | multipart + S3TA ← câu này | | Hàng TB, đồng bộ định kỳ | AWS DataSync | | Hàng chục TB tới PB | Snow Family | | Băng thông chuyên dụng lâu dài | Direct Connect |

Và DataSync đáng cân nhắc cho việc chạy hằng ngày:

DataSync:
    ✓ nhanh hơn công cụ mã nguồn mở tới 10 lần
    ✓ tự kiểm tra tính toàn vẹn dữ liệu
    ✓ lên lịch, báo cáo, tự thử lại
    ✓ tính phí theo GB chuyển

Với một tệp 2 GB mỗi ngày, script với AWS CLI vẫn đơn giản hơn — nhưng nếu số tệp tăng lên, DataSync giảm nhiều công vận hành.

Ba lưu ý về tính toàn vẹn: | Lưu ý | Chi tiết | |---|---| | S3 kiểm tra checksum tự động | MD5 hoặc thuật toán bạn chọn | | Multipart có ETag dạng đặc biệt | <hash>-<số phần>, không phải MD5 của cả tệp | | Dùng --checksum-algorithm để kiểm chặt hơn | SHA-256, CRC32C |

Và một lời khuyên: hãy đo thời gian tải lên và ghi lại để phát hiện khi có gì đó xấu đi. Với việc chạy hằng ngày, một thay đổi ở đường truyền hoặc ở nhà mạng có thể làm chậm gấp đôi mà không ai để ý cho tới khi công việc chồng lấn sang ngày hôm sau.

Câu 434 Chọn nhiều đáp án Design Resilient Architectures

A healthcare startup needs to enforce compliance and regulatory guidelines for objects stored in Amazon S3. One of the key requirements is to provide adequate protection against accidental deletion of objects.

As a solutions architect, what are your recommendations to address these guidelines? (Select two) ?

  1. A

    Create an event trigger on deleting any Amazon S3 object. The event invokes an Amazon Simple Notification Service (Amazon SNS) notification via email to the IT manager
  2. B

    Change the configuration on Amazon S3 console so that the user needs to provide additional confirmation while deleting any Amazon S3 object
  3. C

    Enable multi-factor authentication (MFA) delete on the Amazon S3 bucket
  4. D

    Establish a process to get managerial approval for deleting Amazon S3 objects
  5. E

    Enable versioning on the Amazon S3 bucket
Xem giải thích

Đáp án

C và E.

  • C — Bật MFA Delete trên bucket S3
  • E — Bật versioning trên bucket S3

Vì sao đúng

Hai đáp án là hai lớp bảo vệ kỹ thuật chống xoá nhầm, và chúng bổ sung nhau:

E — versioning là nền tảng:

Không có versioning:
    Xoá object → MẤT VĨNH VIỄN

Có versioning:
    Xoá object → S3 đặt DELETE MARKER
        → object "biến mất" khỏi danh sách
        → nhưng phiên bản gốc VẪN CÒN NGUYÊN
        → xoá delete marker → object trở lại

aws s3api put-bucket-versioning --bucket kho-ho-so-suc-khoe   --versioning-configuration Status=Enabled

# Khôi phục: chỉ cần xoá delete marker
aws s3api delete-object --bucket kho-ho-so-suc-khoe   --key ho-so.pdf --version-id <id-cua-delete-marker>

C — MFA Delete bảo vệ lớp sâu hơn:

Versioning bảo vệ khỏi xoá THÔNG THƯỜNG
    → nhưng ai có quyền vẫn xoá được PHIÊN BẢN CỤ THỂ (xoá vĩnh viễn)

MFA Delete:
    → xoá phiên bản đòi mã MFA
    → tắt versioning cũng đòi mã MFA
        ↓
    Kẻ tấn công chiếm được thông tin đăng nhập vẫn không xoá được

aws s3api put-bucket-versioning --bucket kho-ho-so-suc-khoe   --versioning-configuration Status=Enabled,MFADelete=Enabled   --mfa "arn:aws:iam::123456789012:mfa/root-account-mfa-device 123456"

Và hai lớp này là biện pháp KỸ THUẬT, không phụ thuộc con người — đúng yêu cầu của môi trường tuân thủ.

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

  • **A. Tạo event trigger khi xoá object, gửi thông báo SNS cho quản lý qua email — đây là phương án gần nhất vì nó thực sự cải thiện khả năng phát hiện, nhưng nó chỉ THÔNG BÁO SAU khi việc đã xảy ra. Đề yêu cầu "bảo vệ đầy đủ chống xoá nhầm" — cảnh báo là bổ sung hữu ích, không phải cơ chế bảo vệ.
  • **D. Lập quy trình xin phê duyệt của quản lý trước khi xoá — kiểm soát hành chính, không phải kỹ thuật: không có gì ép người dùng tuân thủ, và một thao tác nhầm vẫn xoá được dữ liệu.
  • **B. Đổi cấu hình trên console S3 để bắt xác nhận thêm khi xoá — không có cấu hình như vậy. Và kể cả có, nó chỉ áp cho console chứ không áp cho CLI, SDK hay API.

Ghi nhớ

Ba lớp bảo vệ chống mất dữ liệu trên S3 — theo mức độ: | Lớp | Chống lại | |---|---| | Versioning | xoá và ghi đè nhầm — khôi phục được | | MFA Delete | xoá phiên bản cố ý hoặc do thông tin đăng nhập bị lộ | | Object Lock (COMPLIANCE) | KHÔNG AI xoá được, kể cả root |

Với dữ liệu y tế cần lưu nhiều năm, Object Lock là lớp mạnh nhất — nhưng câu hỏi cho hai lựa chọn và versioning + MFA Delete là cặp đúng.

Ba đặc điểm quan trọng của MFA Delete: | Đặc điểm | Chi tiết | |---|---| | CHỈ bật được bằng TÀI KHOẢN ROOT | IAM user có toàn quyền cũng không bật được | | CHỈ bật được bằng CLI hoặc API | console không có tuỳ chọn này | | Cần versioning bật trước | |

Dòng đầu là ràng buộc vận hành lớn — nó đòi dùng thông tin đăng nhập root, thứ mà thực hành tốt bảo phải khoá lại. Nhiều tổ chức chọn Object Lock thay vì MFA Delete vì lý do này.

Hai thứ MFA Delete bảo vệ:

① Xoá vĩnh viễn một PHIÊN BẢN cụ thể
② TẮT versioning trên bucket

Nó KHÔNG chặn DeleteObject thông thường — thao tác đó vẫn tạo delete marker được.

Ba trạng thái versioning của bucket: | Trạng thái | Ý nghĩa | |---|---| | Unversioned | mặc định, ghi đè là mất | | Enabled | giữ mọi phiên bản | | Suspended | phiên bản CŨ vẫn giữ, phiên bản MỚI không tạo thêm |

Versioning KHÔNG tắt hẳn được — chỉ tạm dừng, và các phiên bản cũ vẫn nằm đó.

Ba lưu ý về chi phí của versioning: | Lưu ý | Chi tiết | |---|---| | MỌI phiên bản đều tính tiền | kể cả phiên bản không ai đọc | | Delete marker cũng chiếm chỗ | rất nhỏ nhưng có | | Phải có lifecycle cho phiên bản cũ | nếu không dung lượng phình vô hạn |

{"Rules": [{
  "ID": "quan-ly-phien-ban-cu",
  "Status": "Enabled", "Filter": {},
  "NoncurrentVersionTransitions": [
    {"NoncurrentDays": 30, "StorageClass": "GLACIER_IR"}],
  "NoncurrentVersionExpiration": {
    "NoncurrentDays": 2555, "NewerNoncurrentVersions": 5},
  "Expiration": {"ExpiredObjectDeleteMarker": true}}]}
Quy tắc Việc
NewerNoncurrentVersions luôn giữ ít nhất 5 phiên bản gần nhất
ExpiredObjectDeleteMarker dọn delete marker mồ côi

Ba biện pháp bổ sung cho dữ liệu y tế: | Biện pháp | Chống lại | |---|---| | Cross-Region Replication | sự cố cả Region | | Object Lock COMPLIANCE | ransomware và xoá cố ý | | Bucket policy chặn s3:DeleteObject | giới hạn ai được xoá |

Và chính sách chặn xoá theo prefix:

{"Effect": "Deny", "Principal": "*",
 "Action": ["s3:DeleteObject", "s3:DeleteObjectVersion"],
 "Resource": "arn:aws:s3:::kho-ho-so-suc-khoe/luu-tru/*",
 "Condition": {"StringNotLike":
   {"aws:PrincipalArn": "arn:aws:iam::123456789012:role/vai-tro-quan-tri-luu-tru"}}}

Ba cơ chế phát hiện (bổ sung, không thay thế bảo vệ): | Cơ chế | Việc | |---|---| | CloudTrail data event | ghi mọi thao tác object-level | | EventBridge + SNS | cảnh báo khi có xoá hàng loạt | | S3 Inventory | báo cáo định kỳ về object và phiên bản |

Ba yêu cầu tuân thủ HIPAA liên quan: | Yêu cầu | Cơ chế | |---|---| | Ký BAA với AWS | bắt buộc pháp lý cho PHI | | Mã hoá at rest và in transit | SSE-KMS + TLS | | Audit trail đầy đủ | CloudTrail + data event |

Và một lời khuyên: hãy thử khôi phục thật một object đã xoá trên môi trường thử nghiệm trước khi tin vào cấu hình. Versioning bật rồi nhưng lifecycle rule xoá phiên bản cũ sau 7 ngày là một cấu hình mâu thuẫn hay gặp — và nó chỉ lộ ra vào đúng lúc bạn cần khôi phục.

Câu 435 Design Resilient Architectures

A new DevOps engineer has just joined a development team and wants to understand the replication capabilities for Amazon RDS Multi-AZ deployment as well as Amazon RDS Read-replicas.

Which of the following correctly summarizes these capabilities for the given database?

  1. A

    Multi-AZ follows synchronous replication and spans at least two Availability Zones (AZs) within a single region. Read replicas follow asynchronous replication and can be within an Availability Zone (AZ), Cross-AZ, or Cross-Region
  2. B

    Multi-AZ follows asynchronous replication and spans one Availability Zone (AZ) within a single region. Read replicas follow synchronous replication and can be within an Availability Zone (AZ), Cross-AZ, or Cross-Region
  3. C

    Multi-AZ follows asynchronous replication and spans at least two Availability Zones (AZs) within a single region. Read replicas follow asynchronous replication and can be within an Availability Zone (AZ), Cross-AZ, or Cross-Region
  4. D

    Multi-AZ follows asynchronous replication and spans at least two Availability Zones (AZs) within a single region. Read replicas follow synchronous replication and can be within an Availability Zone (AZ), Cross-AZ, or Cross-Region
Xem giải thích

Đáp án

A — Multi-AZ dùng sao chép ĐỒNG BỘ và trải qua ít nhất hai AZ trong CÙNG một Region. Read replica dùng sao chép BẤT ĐỒNG BỘ và có thể trong cùng AZ, khác AZ, hoặc khác Region.

Vì sao đúng

Hai cơ chế phục vụ hai mục đích khác nhau, và cách sao chép phản ánh đúng mục đích đó:

Multi-AZ — sao chép ĐỒNG BỘ vì mục tiêu là KHÔNG MẤT DỮ LIỆU:

Ứng dụng ghi vào primary
    ↓
Primary ghi vào đĩa của mình
    ↓ ĐỒNG THỜI gửi sang standby
Standby ghi xong và XÁC NHẬN
    ↓
Chỉ khi đó primary mới báo "ghi thành công"
        ↓
    → Standby LUÔN có đủ mọi giao dịch
    → RPO = 0, không mất dữ liệu khi chuyển đổi

Read replica — sao chép BẤT ĐỒNG BỘ vì mục tiêu là MỞ RỘNG ĐỌC:

Primary ghi và báo thành công NGAY
    ↓ gửi thay đổi sang replica ở nền
Replica áp dụng khi nhận được
        ↓
    → KHÔNG làm chậm ghi trên primary
    → đổi lại: replica có ĐỘ TRỄ, dữ liệu hơi cũ

Nếu read replica dùng đồng bộ thì mọi lợi ích biến mất:

Đồng bộ với replica ở Region khác:
    → mỗi lần ghi phải chờ round-trip xuyên lục địa (~150ms)
    → primary chậm đi hàng chục lần
    → đó là lý do read replica BẮT BUỘC phải bất đồng bộ

Và phạm vi vị trí cũng khác nhau: | | Multi-AZ | Read replica | |---|---|---| | Phạm vi | ít nhất 2 AZ, CÙNG Region | cùng AZ, khác AZ, hoặc KHÁC REGION |

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

  • **C. Multi-AZ bất đồng bộ, read replica bất đồng bộ — đây là phương án gần nhất vì vế read replica đúng, nhưng nó sai vế Multi-AZ: nếu Multi-AZ bất đồng bộ thì khi primary hỏng đột ngột sẽ mất các giao dịch chưa kịp sao chép — phá vỡ chính mục đích tồn tại của nó.
  • **D. Multi-AZ bất đồng bộ, read replica đồng bộ — đảo ngược cả hai.
  • **B. Multi-AZ bất đồng bộ và chỉ trải MỘT AZ, read replica đồng bộ — sai mọi vế: "Multi-AZ" mà chỉ một AZ là mâu thuẫn ngay trong tên gọi.

Ghi nhớ

Multi-AZ và Read Replica — bảng phân biệt cốt lõi: | | 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ộ | | Phạm vi | ≥ 2 AZ, cùng Region | cùng AZ, khác AZ, khác Region | | Standby phục vụ đọc | ❌ (Multi-AZ instance) | ✅ | | Chuyển đổi | TỰ ĐỘNG | thủ công (promote) | | Số lượng | 1 standby | tối đa 5 (RDS), 15 (Aurora) |

Từ khoá nhận diện:

"high availability", "automatic failover", "no data loss" → Multi-AZ "scale reads", "reporting", "analytics workload" → Read replica "disaster recovery across Regions" → Cross-Region read replica

Và có ba loại triển khai của RDS: | Loại | Đặc điểm | |---|---| | Single-AZ | một instance | | Multi-AZ instance | 1 standby, KHÔNG phục vụ đọc | | Multi-AZ DB cluster | 2 standby CÓ phục vụ đọc, chuyển đổi dưới 35 giây |

Multi-AZ DB cluster là lựa chọn mới đáng biết — nó cho cả sẵn sàng cao lẫn khả năng đọc từ standby, thứ mà Multi-AZ instance không có.

Ba yếu tố kích hoạt chuyển đổi Multi-AZ: | Yếu tố | Chi tiết | |---|---| | Primary instance hỏng | phần cứng hoặc phần mềm | | AZ mất kết nối | | | Bảo trì có kế hoạch | vá lỗi, đổi cỡ instance |

Và chuyển đổi diễn ra qua DNS:

Endpoint KHÔNG ĐỔI (ví dụ: db.abc123.us-east-1.rds.amazonaws.com)
    → RDS trỏ bản ghi DNS sang standby
    → ứng dụng chỉ cần KẾT NỐI LẠI
        ↓
    → Đặt TTL của DNS cache ở JVM thấp (Java mặc định cache vĩnh viễn!)

Với ứng dụng Java, đây là lỗi kinh điển: networkaddress.cache.ttl mặc định là -1 (cache mãi mãi), nên sau khi chuyển đổi ứng dụng vẫn cố kết nối vào IP cũ.

Ba lưu ý về read replica: | Lưu ý | Chi tiết | |---|---| | Có ĐỘ TRỄ sao chép | không dùng cho dữ liệu cần đọc-sau-ghi | | Promote được thành instance độc lập | và không quay lại làm replica được | | Cross-Region replica dùng cho DR | nhưng RPO không bằng 0 |

Và metric cần theo dõi:

ReplicaLag (giây) — độ trễ sao chép
    → tăng dần nghĩa là replica không theo kịp
    → thường do replica nhỏ hơn primary, hoặc truy vấn nặng trên replica

Aurora khác RDS ở kiến trúc sao chép: | | RDS | Aurora | |---|---|---| | Sao chép | ở tầng DATABASE | ở tầng LƯU TRỮ | | Số bản sao dữ liệu | 2 (Multi-AZ) | 6 bản qua 3 AZ | | Độ trễ replica | giây | thường dưới 100ms | | Chuyển đổi | 60–120 giây | thường dưới 30 giây |

Aurora không có khái niệm "Multi-AZ" riêng biệt — lưu trữ của nó vốn đã trải 3 AZ, và thêm replica là vừa mở rộng đọc vừa tăng sẵn sàng.

Ba endpoint của Aurora: | Endpoint | Trỏ tới | |---|---| | Cluster (writer) | instance ghi hiện tại | | Reader | cân bằng tải qua các replica | | Custom | nhóm instance do bạn định nghĩa |

Ba chiến lược khôi phục thảm hoạ: | Chiến lược | RPO | RTO | |---|---|---| | Multi-AZ | 0 | 1–2 phút | | Cross-Region read replica | giây tới phút | phút (promote thủ công) | | Aurora Global Database | thường dưới 1 giây | dưới 1 phút |

Và một lời khuyên: hãy thử chuyển đổi thật trên môi trường thử nghiệm bằng reboot --force-failover. Nó cho biết ứng dụng mất bao lâu để kết nối lại và có xử lý được lỗi kết nối tạm thời hay không — hai điều mà tài liệu không trả lời thay bạn được.

Câu 436 Chọn nhiều đáp án Design High-Performing Architectures

The engineering team at an in-home fitness company is evaluating multiple in-memory data stores with the ability to power its on-demand, live leaderboard. The company's leaderboard requires high availability, low latency, and real-time processing to deliver customizable user data for the community of users working out together virtually from the comfort of their home.

As a solutions architect, which of the following solutions would you recommend? (Select two)

  1. A

    Power the on-demand, live leaderboard using Amazon ElastiCache for Redis as it meets the in-memory, high availability, low latency requirements
  2. B

    Power the on-demand, live leaderboard using Amazon Neptune as it meets the in-memory, high availability, low latency requirements
  3. C

    Power the on-demand, live leaderboard using Amazon DynamoDB as it meets the in-memory, high availability, low latency requirements
  4. D

    Power the on-demand, live leaderboard using Amazon RDS for Aurora as it meets the in-memory, high availability, low latency requirements
  5. E

    Power the on-demand, live leaderboard using Amazon DynamoDB with DynamoDB Accelerator (DAX) as it meets the in-memory, high availability, low latency requirements
Xem giải thích

Đáp án

A và E.

  • A — Amazon ElastiCache for Redis
  • E — Amazon DynamoDB với DynamoDB Accelerator (DAX)

Vì sao đúng

Đề nêu bốn yêu cầu, và hai đáp án là hai lựa chọn duy nhất thoả cả bốn: | Yêu cầu | ElastiCache Redis | DynamoDB + DAX | |---|---|---| | Trong bộ nhớ (in-memory) | ✅ | ✅ nhờ DAX | | Sẵn sàng cao | ✅ Multi-AZ | ✅ | | Độ trễ thấp | micro giây | micro giây | | Xử lý thời gian thực | ✅ | ✅ |

A — Redis là lựa chọn kinh điển cho bảng xếp hạng:

Redis có kiểu dữ liệu SORTED SET
    → mỗi phần tử có một điểm số
    → Redis TỰ giữ thứ tự
    → lấy top N là thao tác một lệnh, độ phức tạp O(log N)

ZADD bang-xep-hang 1250 "nguoi-dung-A"
ZADD bang-xep-hang 1890 "nguoi-dung-B"
ZREVRANGE bang-xep-hang 0 9 WITHSCORES   # top 10
ZREVRANK bang-xep-hang "nguoi-dung-A"     # thứ hạng của một người

Đây chính xác là bài toán mà sorted set được sinh ra để giải — AWS nêu đích danh bảng xếp hạng game là trường hợp dùng của ElastiCache Redis.

Và sẵn sàng cao:

ElastiCache Redis với Multi-AZ:
    → replica ở AZ khác
    → tự chuyển đổi khi primary hỏng
    → cluster mode chia dữ liệu qua nhiều shard

E — DynamoDB với DAX:

DynamoDB:
    ✓ sẵn sàng cao dựng sẵn (sao chép qua 3 AZ)
    ✓ độ trễ mili giây một chữ số
    ✓ tự co giãn

Thêm DAX:
    ✓ đưa độ trễ đọc xuống MICRO GIÂY
    ✓ thành kho trong bộ nhớ đúng nghĩa

Lưu ý quan trọng: DynamoDB một mình KHÔNG phải in-memory — chính DAX mới là phần bộ nhớ. Đó là lý do C sai và E đúng.

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

  • **C. Dùng DynamoDB (không có DAX) — đây là phương án gần nhất và DynamoDB thực sự cho sẵn sàng cao và độ trễ thấp, nhưng nó không thoả vế "in-memory": DynamoDB lưu trên SSD, độ trễ mili giây một chữ số. Đề nêu rõ đang đánh giá kho dữ liệu TRONG BỘ NHỚ.
  • **D. Dùng Amazon RDS Aurora — không phải in-memory: Aurora là database quan hệ trên đĩa. Tính điểm xếp hạng bằng ORDER BY trên hàng triệu dòng cho mỗi lần xem là rất tốn kém.
  • **B. Dùng Amazon Neptune — sai loại database: Neptune là database đồ thị cho dữ liệu quan hệ phức tạp (mạng xã hội, phát hiện gian lận), không phải kho trong bộ nhớ.

Ghi nhớ

Hai lựa chọn in-memory được quản lý trên AWS: | Lựa chọn | Đặc điểm | |---|---| | ElastiCache (Redis / Valkey / Memcached) | kho trong bộ nhớ đa năng | | DynamoDB + DAX | bộ đệm chuyên dụng cho DynamoDB | | MemoryDB for Redis | Redis BỀN VỮNG — dùng làm database chính |

MemoryDB đáng biết:

ElastiCache: bộ ĐỆM — mất dữ liệu chấp nhận được
MemoryDB:    DATABASE CHÍNH — bền vững nhờ transaction log đa AZ
    → độ trễ đọc micro giây, ghi mili giây một chữ số

Với bảng xếp hạng là nguồn dữ liệu duy nhất, MemoryDB an toàn hơn ElastiCache.

Redis và Memcached — bảng phân biệt: | | Redis | Memcached | |---|---|---| | Cấu trúc dữ liệu | phong phú: sorted set, list, hash, stream | chỉ chuỗi key-value | | Bền vững | có (snapshot, AOF) | ❌ | | Sao chép và Multi-AZ | ✅ | ❌ | | Pub/Sub, transaction, Lua | ✅ | ❌ | | Đa luồng | có I/O threading từ v6 | ✅ từ đầu |

Quy tắc: cần bất cứ thứ gì ngoài key-value đơn giản → Redis.

Ba kiểu dữ liệu Redis hay dùng: | Kiểu | Dùng cho | |---|---| | Sorted set (ZADD, ZREVRANGE) | bảng xếp hạng ← câu này | | Hash (HSET, HGETALL) | hồ sơ đối tượng | | String với TTL (SETEX) | phiên đăng nhập, đệm | | Stream | hàng đợi sự kiện |

Ba chế độ triển khai ElastiCache Redis: | Chế độ | Đặc điểm | |---|---| | Cluster mode disabled | một shard, có replica | | Cluster mode enabled | chia dữ liệu qua nhiều shard — mở rộng ngang | | Serverless | tự co giãn, trả theo lượng dùng |

ElastiCache Serverless là lựa chọn tốt khi tải khó đoán — không phải chọn cỡ node.

Ba cấu hình cho sẵn sàng cao: | Cấu hình | Chi tiết | |---|---| | Multi-AZ với automatic failover | replica ở AZ khác | | Ít nhất 2 replica | chịu được mất một node | | Bật snapshot tự động | khôi phục khi cần |

Ba lưu ý về DAX: | Lưu ý | Chi tiết | |---|---| | CHỈ dùng cho DynamoDB | không đệm nguồn khác | | Nhất quán cuối cùng | đọc nhất quán mạnh phải bỏ qua DAX | | Chỉ đổi client, không sửa truy vấn | tương thích API |

Và query cache của DAX bị xoá sạch khi có ghi:

Bảng xếp hạng cập nhật liên tục
    → mỗi lần ghi xoá toàn bộ query cache
    → hiệu quả của DAX giảm với workload ghi nhiều
        ↓
    → Đây là lý do Redis sorted set thường phù hợp HƠN cho bảng xếp hạng

So sánh cho đúng bài toán bảng xếp hạng: | Tiêu chí | Redis sorted set | DynamoDB + DAX | |---|---|---| | Tính thứ hạng | một lệnh, O(log N) | phải quét và sắp xếp | | Cập nhật liên tục | tối ưu | query cache bị xoá thường xuyên | | Bền vững | snapshot (MemoryDB thì bền hẳn) | bền vững dựng sẵn |

Redis là lựa chọn tự nhiên hơn cho bảng xếp hạng — nhưng câu hỏi yêu cầu hai đáp án và cả hai đều thoả các tiêu chí đã nêu.

Ba mẫu đệm phổ biến: | Mẫu | Cơ chế | |---|---| | Lazy loading (cache-aside) | đọc trượt thì nạp từ database | | Write-through | ghi vào cache và database cùng lúc | | TTL | tự hết hạn để tránh dữ liệu cũ |

Và một lời khuyên cho bảng xếp hạng thời gian thực: hãy giữ bảng xếp hạng trong Redis nhưng ghi bản sao bền vững vào DynamoDB ở nền. Redis cho tốc độ và phép tính thứ hạng, DynamoDB đảm bảo dữ liệu không mất nếu cụm cache gặp sự cố — và với dữ liệu thành tích tập luyện của người dùng, mất là không dựng lại được.

Câu 437 Design Cost-Optimized Architectures

A biotechnology firm runs genomics data analysis workloads using AWS Lambda functions deployed inside a VPC in their central AWS account. The input data for these workloads consists of large files stored in an Amazon Elastic File System (Amazon EFS) that resides in a separate AWS account managed by a research partner. The firm wants the Lambda function in their account to access the shared EFS storage directly. The access pattern and file volume are expected to grow as additional research datasets are added over time, so the solution must be scalable and cost-efficient, and should require minimal operational overhead.

Which solution best meets these requirements in the MOST cost-effective way?

  1. A

    Package the genomic input data as a Lambda layer and publish it in the research partner's account. Share the layer across accounts by modifying its resource policy and attach the layer to the Lambda function in the central account to access the data during execution
  2. B

    Use Amazon EFS resource policies to allow cross-account access to the file system from the central account. Attach the EFS mount target to a shared VPC or peered VPC, and mount the file system in the Lambda function configuration using an EFS access point
  3. C

    Set up an Amazon S3 bucket in the research partner’s account and periodically copy EFS contents into the bucket using scheduled AWS DataSync jobs. Use Amazon S3 Access Points to expose the data to the Lambda function in the central account, allowing access via S3 API calls instead of file system mounts
  4. D

    Create a second Lambda function in the research partner's account that mounts the EFS file system locally. Have the main Lambda function in the central account invoke this secondary Lambda via Amazon API Gateway for data access and computation. Use IAM cross-account permissions to allow invocation
Xem giải thích

Đáp án

B — Dùng EFS resource policy cho phép truy cập xuyên tài khoản; gắn mount target vào VPC dùng chung hoặc VPC đã peering, và mount trong cấu hình Lambda qua EFS Access Point.

Vì sao đúng

Đề nêu bốn yêu cầu, và đáp án đáp ứng đủ với ít công nhất: | Yêu cầu | Cơ chế | |---|---| | Lambda truy cập TRỰC TIẾP EFS dùng chung | Lambda hỗ trợ mount EFS nguyên bản | | EFS ở TÀI KHOẢN KHÁC | file system policy cho truy cập xuyên tài khoản | | Mở rộng khi dữ liệu tăng | EFS tự co giãn, không giới hạn dung lượng | | Ít công vận hành, tiết kiệm | không sao chép dữ liệu, không thành phần trung gian |

Ba mảnh ghép của giải pháp:

① EFS file system policy → cho phép tài khoản trung tâm mount
② Mạng thông nhau     → VPC peering hoặc shared VPC
③ EFS Access Point     → Lambda mount qua đây

File system policy cho truy cập xuyên tài khoản:

{"Statement": [{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:role/vai-tro-lambda-gen"},
  "Action": ["elasticfilesystem:ClientMount",
             "elasticfilesystem:ClientWrite"],
  "Condition": {"Bool":
    {"elasticfilesystem:AccessedViaMountTarget": "true"}}}]}

Và cấu hình Lambda mount EFS:

aws lambda update-function-configuration --function-name phan-tich-gen   --file-system-configs     Arn=arn:aws:elasticfilesystem:ap-northeast-1:444455556666:access-point/fsap-0abc,LocalMountPath=/mnt/du-lieu

Trong hàm, dữ liệu hiện ra như thư mục thường:

def handler(event, context):
    with open('/mnt/du-lieu/bo-gen-001.fastq') as f:
        ...

Vì sao đây là cách tiết kiệm nhất:

KHÔNG sao chép dữ liệu (không tốn dung lượng gấp đôi)
KHÔNG có thành phần trung gian phải vận hành
KHÔNG có độ trễ đồng bộ
    ↓
    Lambda đọc thẳng tệp gốc, tệp lớn cỡ nào cũng được

Điều này quan trọng với dữ liệu gen — tệp thường hàng chục GB, vượt xa giới hạn 10 GB của /tmp trong Lambda.

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

  • **C. Sao chép nội dung EFS sang S3 bằng DataSync định kỳ, dùng S3 Access Point cho Lambda gọi qua S3 API — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó tốn kém và phức tạp hơn: phải trả tiền lưu trữ hai bản dữ liệu hàng chục TB, chạy và giám sát job DataSync, và chấp nhận độ trễ đồng bộ — dữ liệu mới chưa kịp sao chép thì Lambda không thấy.
  • **A. Đóng gói dữ liệu thành Lambda layer — vượt giới hạn kỹ thuật rất xa: layer tối đa 250 MB (giải nén), còn dữ liệu gen là hàng chục GB. Và layer là tài nguyên tĩnh, phải xuất bản lại mỗi lần dữ liệu đổi.
  • **D. Tạo Lambda thứ hai ở tài khoản đối tác, gọi qua API Gateway — thêm một tầng phức tạp không cần thiết: hai hàm phải bảo trì, giới hạn payload 6 MB của Lambda đồng bộ, và timeout 29 giây của API Gateway.

Ghi nhớ

Ba cách Lambda truy cập dữ liệu lớn: | Cách | Giới hạn | |---|---| | /tmp | 512 MB – 10 GB, mất sau khi hàm kết thúc | | Amazon S3 | không giới hạn, nhưng phải tải về hoặc dùng range request | | Amazon EFS | không giới hạn, truy cập như hệ thống tệp ← câu này |

Từ khoá nhận diện:

"file system access", "shared across invocations", "large files", "POSIX" → EFS "object storage", "immutable", "archival" → S3 "under 10 GB, temporary" → /tmp

Ba yêu cầu để Lambda mount EFS: | Yêu cầu | Chi tiết | |---|---| | Lambda phải ở TRONG VPC | và VPC đó phải có đường tới mount target | | Phải dùng EFS Access Point | không mount trực tiếp file system | | Execution role cần quyền EFS | ClientMount, ClientWrite |

Và Lambda trong VPC có hệ quả về mạng:

Lambda trong VPC KHÔNG có Internet mặc định
    → cần gọi dịch vụ AWS khác?
        → NAT Gateway (có phí) hoặc VPC endpoint (rẻ hơn)

Ba cách nối mạng hai VPC ở hai tài khoản: | Cách | Đặc điểm | |---|---| | VPC peering | đơn giản, rẻ, KHÔNG bắc cầu (không transitive) | | Transit Gateway | nhiều VPC, có định tuyến tập trung, đắt hơn | | Shared VPC (RAM) | chia subnet cho tài khoản khác — không cần peering |

Shared VPC qua AWS RAM đáng cân nhắc:

Tài khoản đối tác chia sẻ subnet chứa mount target
    → Lambda của tài khoản trung tâm chạy TRONG subnet đó
    → không cần peering, không cần định tuyến chéo

Ba lợi ích của EFS Access Point: | Lợi ích | Chi tiết | |---|---| | Ép POSIX user | không phụ thuộc uid của client | | Ép thư mục gốc | client chỉ thấy phần của mình | | Đơn giản hoá phân quyền | một access point cho một ứng dụng |

aws efs create-access-point --file-system-id fs-0abc123   --posix-user Uid=1001,Gid=1001   --root-directory 'Path=/du-lieu-gen,CreationInfo={OwnerUid=1001,OwnerGid=1001,Permissions=755}'

Ba chế độ hiệu năng và thông lượng của EFS: | Cấu hình | Lựa chọn | |---|---| | Performance mode | General Purpose (mặc định) / Max I/O | | Throughput mode | Elastic (mặc định mới) / Provisioned / Bursting | | Storage class | Standard / One Zone, có IA |

Elastic throughput là mặc định đúng cho hầu hết trường hợp — trả theo lượng dùng thật, không phải chọn trước.

Ba cách giảm chi phí EFS: | Cách | Tiết kiệm | |---|---| | Lifecycle sang IA | ~90% cho tệp ít truy cập | | One Zone cho dữ liệu tái tạo được | ~47% | | Elastic throughput | không trả cho thông lượng không dùng |

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

Với dữ liệu gen — ghi một lần, đọc thưa — lifecycle sang IA tiết kiệm rất lớn.

Ba lưu ý về hiệu năng khi Lambda đọc EFS: | Lưu ý | Chi tiết | |---|---| | Nhiều lượt Lambda đọc cùng lúc | thông lượng EFS chia sẻ giữa chúng | | Cold start lâu hơn khi mount EFS | thêm vài trăm mili giây | | Timeout 15 phút vẫn áp dụng | tệp quá lớn thì cân nhắc Fargate |

Dòng cuối đáng lưu ý với phân tích gen: nếu một tệp mất hơn 15 phút để xử lý, Lambda không phải công cụ đúng — ECS Fargate cũng mount EFS được và không có giới hạn thời gian.

Và một lời khuyên về bảo mật xuyên tài khoản: hãy dùng điều kiện aws:PrincipalOrgID trong file system policy nếu hai tài khoản cùng một Organization, thay vì liệt kê ARN của từng role. Cách đó tránh việc policy hỏng mỗi khi bên kia đổi tên vai trò — một nguồn sự cố thầm lặng trong hợp tác nhiều tài khoản.

Câu 438 Design High-Performing Architectures

A gaming company is developing a mobile game that streams score updates to a backend processor and then publishes results on a leaderboard. The company has hired you as an AWS Certified Solutions Architect Associate to design a solution that can handle major traffic spikes, process the mobile game updates in the order of receipt, and store the processed updates in a highly available database. The company wants to minimize the management overhead required to maintain the solution.

Which of the following will you recommend to meet these requirements?

  1. A

    Push score updates to an Amazon Simple Notification Service (Amazon SNS) topic, subscribe an AWS Lambda function to this Amazon SNS topic to process the updates and then store these processed updates in a SQL database running on Amazon EC2 instance
  2. B

    Push score updates to an Amazon Simple Queue Service (Amazon SQS) queue which uses a fleet of Amazon EC2 instances (with Auto Scaling) to process these updates in the Amazon SQS queue and then store these processed updates in an Amazon RDS MySQL database
  3. C

    Push score updates to Amazon Kinesis Data Streams which uses an AWS Lambda function to process these updates and then store these processed updates in Amazon DynamoDB
  4. D

    Push score updates to Amazon Kinesis Data Streams which uses a fleet of Amazon EC2 instances (with Auto Scaling) to process the updates in Amazon Kinesis Data Streams and then store these processed updates in Amazon DynamoDB
Xem giải thích

Đáp án

C — Đẩy cập nhật điểm vào Amazon Kinesis Data Streams, dùng AWS Lambda xử lý, và lưu kết quả vào Amazon DynamoDB.

Vì sao đúng

Đề nêu bốn yêu cầu, và đáp án là lựa chọn duy nhất thoả cả bốn: | Yêu cầu | Cơ chế | |---|---| | Chịu được đỉnh tải lớn | Kinesis mở rộng bằng shard | | Xử lý ĐÚNG THỨ TỰ NHẬN | Kinesis đảm bảo thứ tự trong mỗi shard | | Lưu vào database sẵn sàng cao | DynamoDB — sao chép qua 3 AZ | | Ít công vận hành nhất | Lambda + DynamoDB đều serverless |

Vì sao Kinesis chứ không phải SQS hay SNS:

Yêu cầu "process in the ORDER OF RECEIPT"
    ↓
SQS Standard: KHÔNG đảm bảo thứ tự
SNS:          không đảm bảo thứ tự
Kinesis:      ĐẢM BẢO thứ tự trong mỗi shard

Và cách Kinesis giữ thứ tự:

Mỗi bản ghi có PARTITION KEY
    → cùng partition key → luôn vào CÙNG một shard
    → trong một shard, thứ tự được giữ nguyên
        ↓
    Dùng mã người chơi làm partition key
    → mọi cập nhật điểm của một người xử lý đúng thứ tự
    → các người chơi khác nhau xử lý SONG SONG

kinesis.put_record(
    StreamName='cap-nhat-diem',
    Data=json.dumps({'nguoi_choi': ma, 'diem': diem, 'thoi_diem': ts}),
    PartitionKey=ma_nguoi_choi)   # đảm bảo thứ tự cho từng người chơi

Và Lambda là consumer ít công nhất:

Lambda event source mapping với Kinesis:
    ✓ Lambda TỰ đọc từ mọi shard
    ✓ tự co giãn theo số shard
    ✓ tự thử lại khi lỗi
    ✓ KHÔNG có máy chủ nào để quản lý

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

  • **D. Kinesis Data Streams nhưng dùng fleet EC2 với Auto Scaling để xử lý — đây là phương án gần nhất và vế Kinesis + DynamoDB hoàn toàn đúng, nhưng nó vi phạm yêu cầu ít công vận hành: phải quản lý AMI, vá lỗi hệ điều hành, cấu hình ASG, và tự viết ứng dụng dùng Kinesis Client Library để phối hợp việc đọc shard.
  • **B. Dùng SQS queue với fleet EC2 và RDS MySQL — vi phạm hai yêu cầu: SQS Standard không đảm bảo thứ tự, và EC2 + RDS đòi nhiều công vận hành hơn Lambda + DynamoDB.
  • **A. Dùng SNS với Lambda và SQL database trên EC2 — vi phạm nặng nhất: SNS không đảm bảo thứ tự, và database tự cài trên EC2 thì không sẵn sàng cao (một instance, một AZ) và tốn nhiều công nhất.

Ghi nhớ

Bốn dịch vụ nhắn tin và luồng dữ liệu — bảng cần thuộc: | Dịch vụ | Thứ tự | Đọc lại được | Nhiều consumer | |---|---|---|---| | SQS Standard | ❌ | ❌ (xoá sau khi đọc) | một consumer nhận | | SQS FIFO | ✅ trong message group | ❌ | một consumer nhận | | SNS | ❌ | ❌ | ✅ phát tán | | Kinesis Data Streams | ✅ trong shard | ✅ giữ 1–365 ngày | ✅ nhiều consumer độc lập |

Từ khoá nhận diện:

"order of receipt", "real-time streaming", "replay", "multiple consumers" → Kinesis "exactly once", "no duplicates" → SQS FIFO "fan-out to many subscribers" → SNS "simple decoupling, high throughput" → SQS Standard

Ba đặc điểm của Kinesis Data Streams: | Đặc điểm | Chi tiết | |---|---| | Shard là đơn vị thông lượng | 1 MB/giây ghi, 2 MB/giây đọc, 1.000 bản ghi/giây ghi | | Giữ dữ liệu 24 giờ mặc định | mở rộng tới 365 ngày | | Nhiều consumer đọc ĐỘC LẬP | mỗi cái có vị trí đọc riêng |

Khả năng đọc lại là lợi thế lớn so với SQS:

SQS: đọc xong thì thông điệp biến mất
Kinesis: dữ liệu nằm đó tới hết thời gian giữ
    → lỗi trong xử lý? đọc lại từ đầu
    → thêm consumer mới? xử lý cả dữ liệu cũ

Hai chế độ dung lượng của Kinesis: | Chế độ | Đặc điểm | |---|---| | Provisioned | bạn chọn số shard, rẻ hơn khi tải ổn định | | On-demand | tự co giãn, đắt hơn nhưng không phải tính toán |

Với game có đỉnh tải khó đoán, on-demand thường là lựa chọn đúng:

aws kinesis create-stream --stream-name cap-nhat-diem   --stream-mode-details StreamMode=ON_DEMAND

Ba lưu ý khi chọn partition key: | Lưu ý | Chi tiết | |---|---| | Phân bố ĐỀU giữa các shard | key lệch tạo "hot shard" | | Cùng key = cùng shard = giữ thứ tự | | | Số key phải nhiều hơn số shard | nếu không có shard không nhận gì |

Hot shard là vấn đề hiệu năng phổ biến nhất của Kinesis:

Dùng "khu-vuc" làm partition key với 3 khu vực và 10 shard
    → chỉ 3 shard nhận dữ liệu, 7 shard nhàn rỗi
    → thông lượng thực tế chỉ bằng 30% năng lực đã trả tiền

Ba cấu hình của Lambda event source mapping: | Cấu hình | Việc | |---|---| | BatchSize | số bản ghi mỗi lần gọi (tối đa 10.000) | | ParallelizationFactor | xử lý song song tới 10 lô trên MỘT shard | | MaximumRetryAttempts | tránh "poison pill" chặn cả shard |

Poison pill là bẫy kinh điển với Kinesis + Lambda:

Một bản ghi gây lỗi
    → Lambda thử lại MÃI MÃI
    → shard đó KẸT HOÀN TOÀN, không xử lý được gì thêm
        ↓
    → Đặt MaximumRetryAttempts và cấu hình on-failure destination

aws lambda update-event-source-mapping --uuid <id>   --maximum-retry-attempts 3 --bisect-batch-on-function-error   --destination-config '{"OnFailure":{"Destination":"<arn-sqs-dlq>"}}'

Ba dịch vụ khác trong họ Kinesis: | Dịch vụ | Việc | |---|---| | Data Firehose | giao thẳng vào S3, Redshift, OpenSearch — KHÔNG lưu lại | | Managed Service for Apache Flink | phân tích SQL/Java trên luồng | | Video Streams | luồng video |

Firehose KHÔNG ghi được vào DynamoDB — đích hỗ trợ là S3, Redshift, OpenSearch, Splunk và một số endpoint HTTP.

Ba lưu ý về DynamoDB cho bảng xếp hạng: | Lưu ý | Chi tiết | |---|---| | Chọn partition key phân bố đều | tránh hot partition | | On-demand cho tải khó đoán | không phải cấp WCU/RCU trước | | Global Secondary Index để sắp xếp theo điểm | truy vấn top N |

Và một lời khuyên: hãy theo dõi metric IteratorAge của Lambda. Nó cho biết bản ghi đang được xử lý đã nằm trong stream bao lâu — con số tăng dần nghĩa là consumer không theo kịp tốc độ ghi, và nếu vượt thời gian giữ dữ liệu thì bạn mất dữ liệu vĩnh viễn mà không có lỗi nào báo.

Câu 439 Design Secure Architectures

An organization wants to delegate access to a set of users from the development environment so that they can access some resources in the production environment which is managed under another AWS account.

As a solutions architect, which of the following steps would you recommend?

  1. A

    It is not possible to access cross-account resources
  2. B

    Create a new IAM role with the required permissions to access the resources in the production environment. The users can then assume this IAM role while accessing the resources from the production environment
  3. C

    Create new IAM user credentials for the production environment and share these credentials with the set of users from the development environment
  4. D

    Both IAM roles and IAM users can be used interchangeably for cross-account access
Xem giải thích

Đáp án

B — Tạo một IAM role mới có quyền cần thiết ở môi trường sản xuất; người dùng đảm nhận (assume) role đó khi cần truy cập.

Vì sao đúng

Đây là mẫu chuẩn cho truy cập xuyên tài khoản trên AWS — và nó dựa trên thông tin đăng nhập tạm thời.

Cách hoạt động:

Tài khoản DEV (111122223333)          Tài khoản PROD (444455556666)
   IAM user "lan"                        IAM role "vai-tro-truy-cap-prod"
       │                                        │
       │  sts:AssumeRole ──────────────────────▶│ trust policy cho phép
       │                                        │ tài khoản dev
       │◀───── thông tin đăng nhập TẠM THỜI ────│
       │        (access key + session token)
       ▼
   Gọi API vào tài nguyên PROD

Hai chính sách phải khớp nhau:

① Trust policy trên role (ở tài khoản PROD) — AI được đảm nhận:

{"Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
   "Action": "sts:AssumeRole",
   "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}}]}

② Identity policy ở tài khoản DEV — được phép GỌI AssumeRole:

{"Effect": "Allow", "Action": "sts:AssumeRole",
 "Resource": "arn:aws:iam::444455556666:role/vai-tro-truy-cap-prod"}

Thiếu một trong hai là không hoạt động — đây là điểm hay gây nhầm lẫn.

Và lợi ích cốt lõi: thông tin đăng nhập TẠM THỜI.

Không có access key dài hạn nào được tạo hay chia sẻ
    → tự hết hạn sau 1–12 giờ
    → lộ ra cũng chỉ có giá trị trong thời gian ngắn
    → CloudTrail ghi rõ AI đã đảm nhận role, lúc nào

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

  • **C. Tạo IAM user mới ở môi trường production và CHIA SẺ thông tin đăng nhập cho nhóm ở dev — đây là phương án gần nhất vì nó cũng cho truy cập được, nhưng nó vi phạm nguyên tắc căn bản: thông tin đăng nhập dài hạn được chia sẻ nghĩa là CloudTrail chỉ ghi được "user chung X đã làm gì" mà không biết ai thật sự làm, và không thu hồi được cho từng người.
  • **D. IAM role và IAM user dùng thay thế nhau được cho truy cập xuyên tài khoản — sai về mặt kỹ thuật: IAM user thuộc về một tài khoản cụ thể và không "đảm nhận xuyên tài khoản" được theo cách của role. Role tồn tại chính là để giải bài toán này.
  • **A. Không thể truy cập tài nguyên xuyên tài khoản — sai hoàn toàn: đây là kịch bản được hỗ trợ đầy đủ và rất phổ biến.

Ghi nhớ

IAM user và IAM role — bảng phân biệt cốt lõi: | | IAM user | IAM role | |---|---|---| | Thông tin đăng nhập | dài hạn | TẠM THỜI, tự hết hạn | | Gắn với | một người hoặc ứng dụng cụ thể | ai đảm nhận cũng được nếu trust policy cho phép | | Xuyên tài khoản | ❌ | ✅ | | Dùng cho dịch vụ AWS | không nên | ✅ EC2, Lambda, ECS |

Ba trường hợp phải dùng role: | Trường hợp | Chi tiết | |---|---| | Truy cập xuyên tài khoản | ← câu này | | Dịch vụ AWS gọi dịch vụ khác | EC2 → S3, Lambda → DynamoDB | | Liên kết danh tính (federation) | AD, Okta, Google |

Ba tham số của sts:AssumeRole: | Tham số | Việc | |---|---| | RoleArn | role muốn đảm nhận | | RoleSessionName | tên phiên — HIỆN TRONG CloudTrail, giúp truy vết | | DurationSeconds | 900 giây – 12 giờ | | ExternalId | chống "confused deputy" với bên thứ ba |

RoleSessionName là chi tiết quan trọng cho kiểm toán:

aws sts assume-role   --role-arn arn:aws:iam::444455556666:role/vai-tro-truy-cap-prod   --role-session-name lan-nguyen-2026-08-30

Đặt tên phiên theo danh tính người thật thì CloudTrail truy được về đúng cá nhân.

Và ExternalId bắt buộc khi cấp quyền cho bên THỨ BA:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::999988887777:root"},
 "Action": "sts:AssumeRole",
 "Condition": {"StringEquals": {"sts:ExternalId": "chuoi-bi-mat-rieng"}}}

Không có nó, nhà cung cấp dịch vụ có thể bị lừa dùng quyền của bạn cho khách hàng khác — đó là lỗ hổng "confused deputy".

Cấu hình profile trong AWS CLI để dùng hằng ngày:

[profile prod]
role_arn = arn:aws:iam::444455556666:role/vai-tro-truy-cap-prod
source_profile = dev
mfa_serial = arn:aws:iam::111122223333:mfa/lan
duration_seconds = 3600

aws s3 ls --profile prod

CLI tự gọi AssumeRole, tự hỏi mã MFA, tự lưu cache — trong suốt với người dùng.

Ba biện pháp bảo vệ nên có trong trust policy: | Biện pháp | Điều kiện | |---|---| | Bắt buộc MFA | aws:MultiFactorAuthPresent | | Giới hạn IP nguồn | aws:SourceIp | | Giới hạn thời gian phiên | DurationSeconds ngắn |

Và giới hạn cụ thể tới role thay vì cả tài khoản:

{"Principal": {"AWS": "arn:aws:iam::111122223333:role/vai-tro-lap-trinh-vien"}}

Khai :root nghĩa là uỷ quyền cho tài khoản kia tự quyết ai được đảm nhận — chấp nhận được trong cùng tổ chức, nhưng khai cụ thể thì chặt hơn.

Ba lựa chọn hiện đại hơn IAM user: | Lựa chọn | Phù hợp | |---|---| | IAM Identity Center | truy cập của CON NGƯỜI vào nhiều tài khoản — được khuyến nghị | | IAM Roles Anywhere | máy chủ ngoài AWS | | OIDC federation | CI/CD như GitHub Actions |

AWS khuyến nghị Identity Center thay cho việc tự dựng chuỗi assume-role:

Identity Center:
    ✓ portal đăng nhập một lần cho mọi tài khoản
    ✓ permission set gán theo nhóm
    ✓ tự tạo và quản lý role ở tài khoản đích
    ✓ thông tin đăng nhập tạm thời, hết hạn tự động

Ba lưu ý về quyền hiệu lực khi đảm nhận role:

Quyền = quyền của ROLE (không cộng dồn với quyền của user gốc)
      ∩ session policy (nếu có)
      ∩ permissions boundary của role
      ∩ SCP của tài khoản đích

Dòng đầu hay gây bất ngờ: sau khi assume role, bạn mất mọi quyền của user gốc và chỉ còn quyền của role.

Và một lời khuyên: hãy đặt DurationSeconds ngắn cho tài khoản production — một giờ là đủ cho phần lớn công việc, và nó giới hạn thiệt hại nếu máy trạm của ai đó bị xâm nhập trong lúc phiên còn hiệu lực.

Câu 440 Chọn nhiều đáp án Design High-Performing Architectures

The DevOps team at an e-commerce company has deployed a fleet of Amazon EC2 instances under an Auto Scaling group (ASG). The instances under the ASG span two Availability Zones (AZ) within the us-east-1 region. All the incoming requests are handled by an Application Load Balancer (ALB) that routes the requests to the Amazon EC2 instances under the Auto Scaling Group. As part of a test run, two instances (instance 1 and 2, belonging to AZ A) were manually terminated by the DevOps team causing the Availability Zones (AZ) to have unbalanced resources. Later that day, another instance (belonging to AZ B) was detected as unhealthy by the Application Load Balancer's health check.

Can you identify the correct outcomes for these events? (Select two)

  1. A

    Amazon EC2 Auto Scaling creates a new scaling activity to terminate the unhealthy instance and launch the new instance simultaneously
  2. B

    As the resources are unbalanced in the Availability Zones, Amazon EC2 Auto Scaling will compensate by rebalancing the Availability Zones. When rebalancing, Amazon EC2 Auto Scaling terminates old instances before launching new instances, so that rebalancing does not cause extra instances to be launched
  3. C

    Amazon EC2 Auto Scaling creates a new scaling activity for terminating the unhealthy instance and then terminates it. Later, another scaling activity launches a new instance to replace the terminated instance
  4. D

    As the resources are unbalanced in the Availability Zones, Amazon EC2 Auto Scaling will compensate by rebalancing the Availability Zones. When rebalancing, Amazon EC2 Auto Scaling launches new instances before terminating the old ones, so that rebalancing does not compromise the performance or availability of your application
  5. E

    Amazon EC2 Auto Scaling creates a new scaling activity for launching a new instance to replace the unhealthy instance. Later, Amazon EC2 Auto Scaling creates a new scaling activity for terminating the unhealthy instance and then terminates it
Xem giải thích

Đáp án

C và D.

  • C — Với instance KHÔNG KHOẺ MẠNH: ASG tạo một scaling activity để CHẤM DỨT nó trước, SAU ĐÓ một activity khác mới khởi động instance thay thế
  • D — Với việc CÂN BẰNG LẠI giữa các AZ: ASG KHỞI ĐỘNG máy mới TRƯỚC, rồi mới chấm dứt máy cũ

Vì sao đúng

Điểm mấu chốt của câu này: ASG xử lý hai tình huống theo hai thứ tự NGƯỢC NHAU, và lý do rất hợp lý.

C — thay instance hỏng: CHẤM DỨT trước:

Instance đã KHÔNG KHOẺ MẠNH
    → nó không phục vụ được nữa
    → giữ lại chẳng ích gì
        ↓
    ASG chấm dứt ngay → rồi khởi động máy thay thế
    → tổng số máy tạm thời GIẢM

D — cân bằng lại AZ: KHỞI ĐỘNG trước:

Các instance hiện tại đều KHOẺ MẠNH và ĐANG PHỤC VỤ
    → chấm dứt trước sẽ GIẢM năng lực đột ngột
    → ảnh hưởng hiệu năng và tính sẵn sàng
        ↓
    ASG khởi động máy mới ở AZ thiếu → chờ khoẻ mạnh
    → RỒI mới chấm dứt máy cũ ở AZ thừa
    → năng lực KHÔNG BAO GIỜ tụt dưới mức mong muốn

Nguyên tắc chung đằng sau:

Máy đã HỎNG      → chấm dứt trước (giữ lại vô ích)
Máy còn KHOẺ     → khởi động trước (đừng tự làm giảm năng lực)

Và trong tình huống của đề, hai điều xảy ra tách biệt:

Sáng: hai máy ở AZ A bị chấm dứt thủ công
    → AZ mất cân bằng → ASG cân bằng lại (khởi động trước) ← D

Chiều: một máy ở AZ B bị ALB đánh giá là hỏng
    → ASG thay máy hỏng (chấm dứt trước) ← C

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

  • **B. Khi cân bằng lại AZ, ASG chấm dứt máy cũ TRƯỚC rồi mới khởi động máy mới, để việc cân bằng không sinh thêm máy — đây là phương án gần nhất vì nó mô tả đúng cơ chế cân bằng lại và lý do nghe hợp lý (tránh vượt số máy), nhưng nó đảo ngược thứ tự thật: AWS ưu tiên không làm giảm năng lực hơn là tránh vượt tạm thời vài máy.
  • **A. ASG chấm dứt máy hỏng và khởi động máy mới ĐỒNG THỜI — sai về cơ chế: đó là hai scaling activity riêng biệt, tuần tự, không phải một hành động đồng thời.
  • **E. ASG khởi động máy thay thế TRƯỚC rồi mới chấm dứt máy hỏng — đảo ngược đúng vế C: với máy đã hỏng, ASG chấm dứt trước.

Ghi nhớ

Hai thứ tự của Auto Scaling — bảng cần thuộc: | Tình huống | Thứ tự | |---|---| | Thay instance KHÔNG KHOẺ MẠNH | chấm dứt → khởi động | | Cân bằng lại giữa AZ | khởi động → chấm dứt | | Instance refresh | tuỳ MinHealthyPercentage |

Và nguyên tắc: máy còn phục vụ được thì không bao giờ bỏ trước.

Ba loại health check của ASG: | Loại | Kiểm tra gì | |---|---| | EC2 (mặc định) | chỉ status check của instance — máy chạy là coi như khoẻ | | ELB | health check của load balancer — kiểm tra ỨNG DỤNG | | Custom | bạn tự gọi SetInstanceHealth |

Health check kiểu EC2 là mặc định và thường KHÔNG đủ:

Ứng dụng treo nhưng hệ điều hành vẫn chạy
    → EC2 status check: PASS
    → ASG coi là khoẻ mạnh, không thay
    → ALB thì thấy hỏng và ngừng gửi lưu lượng
        ↓
    → Máy nằm đó không phục vụ mà không ai thay

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-ung-dung   --health-check-type ELB --health-check-grace-period 300

Đổi sang ELB là một trong những cấu hình quan trọng nhất của ASG.

Và HealthCheckGracePeriod phải đủ dài:

Quá ngắn:
    Máy mới chưa khởi động xong ứng dụng
    → ALB đánh giá hỏng
    → ASG chấm dứt và khởi động máy khác
    → VÒNG LẶP CHẤM DỨT VÔ TẬN

Đây là lỗi khiến ASG liên tục thay máy mà không bao giờ ổn định.

Ba nguyên nhân ASG KHÔNG chấm dứt máy hỏng: | Nguyên nhân | Chi tiết | |---|---| | Grace period chưa hết | ← đáp án B của một câu hỏi khác | | Health check type là EC2, không phải ELB | ứng dụng hỏng không bị phát hiện | | Instance đang ở trạng thái Standby | ASG không quản lý | | Scale-in protection đang bật | |

Chính sách chấm dứt mặc định của ASG — theo thứ tự:

① AZ có NHIỀU instance nhất
② Trong AZ đó, instance dùng launch template hoặc configuration CŨ NHẤT
③ Instance gần nhất với mốc TÍNH TIỀN THEO GIỜ tiếp theo
④ Chọn ngẫu nhiên

Và có thể đổi chính sách:

aws autoscaling update-auto-scaling-group   --auto-scaling-group-name asg-ung-dung   --termination-policies "OldestInstance"
Chính sách Chấm dứt
Default theo thứ tự trên
OldestInstance máy cũ nhất — hữu ích khi đổi loại instance
NewestInstance máy mới nhất — hữu ích khi rollback
ClosestToNextInstanceHour tối ưu chi phí (ít ý nghĩa với tính phí theo giây)

Ba trạng thái vòng đời của instance trong ASG: | Trạng thái | Ý nghĩa | |---|---| | Pending | đang khởi động | | InService | đang phục vụ | | Terminating | đang chấm dứt | | Standby | tạm gỡ khỏi ASG để bảo trì, không bị thay |

Standby rất hữu ích khi cần gỡ lỗi một máy:

aws autoscaling enter-standby --instance-ids i-0abc   --auto-scaling-group-name asg-ung-dung --should-decrement-desired-capacity

Máy vẫn chạy, bạn vào xem được, và ASG không chấm dứt nó.

Ba lifecycle hook đáng dùng: | Hook | Việc | |---|---| | EC2_INSTANCE_LAUNCHING | cài đặt hoặc nạp dữ liệu trước khi phục vụ | | EC2_INSTANCE_TERMINATING | đẩy log ra ngoài trước khi máy biến mất | | Cả hai | thông báo qua SNS hoặc EventBridge |

Hook chấm dứt đặc biệt quan trọng — không có nó, log cục bộ và tệp tạm mất theo máy, và bạn không bao giờ biết vì sao nó hỏng.

Và một lời khuyên khi chẩn đoán: xem Activity history của ASG. Nó ghi từng scaling activity kèm lý do — "an instance was taken out of service in response to an ELB system health check failure" nói rõ hơn mọi phỏng đoán, và nó cũng cho thấy đúng thứ tự các activity đã diễn ra.