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

Đáp án

**B — Dùng AWS Application Discovery Service thu thập dữ liệu về trung tâm dữ liệu tại chỗ và thực hiện phân tích chi phí sở hữu (TCO).

Vì sao đúng

Đề nêu ba loại dữ liệu cần thu thập, và Discovery Service là dịch vụ được thiết kế đúng cho việc đó: | Dữ liệu cần | Discovery Service thu thập | |---|---| | Cấu hình | CPU, RAM, đĩa, hệ điều hành | | Mức sử dụng | hiệu năng thực tế theo thời gian | | Hành vi | tiến trình đang chạy và KẾT NỐI MẠNG |

⚠ Cột "hành vi" là thứ chỉ Discovery Service cho:

Biết máy chủ nào GỌI máy chủ nào
    → vẽ được sơ đồ phụ thuộc
        ↓
    Từ đó biết di chuyển cái gì trước
      và cái gì phải đi cùng nhau
    → và máy nào không ai gọi tới
      (ứng viên để tắt hẳn)

Hai chế độ thu thập: | Chế độ | Cách | Dữ liệu | |---|---|---| | Agentless Collector | máy ảo trong VMware | cấu hình + hiệu năng | | Discovery Agent | cài lên từng máy chủ | thêm tiến trình và KẾT NỐI MẠNG |

Cần sơ đồ phụ thuộc
    → phải dùng AGENT
    → agentless không thấy kết nối mạng

Xem dữ liệu đã thu thập:

aws discovery list-configurations \
  --configuration-type SERVER

aws discovery start-export-task \
  --export-data-format CSV \
  --filters name=agentIds,values=<id>,condition=EQUALS

Nhóm máy chủ thành ứng dụng:

aws discovery create-application \
  --name he-thong-ke-toan \
  --description "Web, ung dung, CSDL"

aws discovery associate-configuration-items-to-application \
  --application-configuration-id d-application-abc \
  --configuration-ids d-server-1 d-server-2 d-server-3

⚠ Thu thập tối thiểu HAI TUẦN — đây là con số có lý do:

Thu thập một ngày
    → không thấy tải cuối tuần
    → không thấy job chạy cuối tháng
        ↓
    Định cỡ theo dữ liệu thiếu
    → máy thiếu công suất đúng lúc bận nhất

⚠ Và vì sao Migration Hub không phải đáp án:

Migration Hub: nơi TỔNG HỢP và
  THEO DÕI tiến độ
    → nó hiển thị dữ liệu do
      Discovery Service thu thập
        ↓
    Nó không tự thu thập gì cả
    → đây là lý do phương án D sai

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Quyết định dựa trên dữ liệu thật, không phỏng đoán | | | Sơ đồ phụ thuộc tránh chia nhầm đợt | | | Phát hiện máy chủ không ai dùng | |

⚠ Lợi ích thứ ba thường là khoản tiết kiệm lớn nhất:

Khảo sát điển hình: 10-20% máy chủ
  không còn kết nối mạng nào
        ↓
    Đó là chiến lược "Retire"
    → tắt luôn, tiết kiệm ngay
    → không cần di chuyển gì

⚠ Và Migration Evaluator là công cụ chuyên cho TCO:

Discovery Service: thu thập dữ liệu
        ↓
    Migration Evaluator: đọc dữ liệu đó
    → ước tính chi phí trên AWS
    → so với chi phí hiện tại
    → sinh báo cáo luận chứng kinh doanh
        ↓
    Hai cái đi cùng nhau

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

• **D. Dùng AWS Migration Hub thu thập dữ liệu từ từng máy chủ và làm TCO — đây là phương án gần nhất và Migration Hub thật sự là trung tâm của quy trình di chuyển, nhưng nó chỉ hiển thị và theo dõi; việc thu thập dữ liệu là của Discovery Service.
• **C. Dùng Application Migration Service (MGN) để di chuyển máy chủ và thu thập dữ liệu cho TCO — MGN thực hiện việc di chuyển; nó không phải công cụ khảo sát trước khi quyết định.
• **A. Dùng AWS SAM để chuyển dữ liệu và làm TCO — SAM (Serverless Application Model) là khung phát triển ứng dụng không máy chủ, hoàn toàn không liên quan.

Ghi nhớ

⚠ Ba giai đoạn di chuyển và công cụ — bảng phải thuộc: | Giai đoạn | Công cụ | |---|---| | Đánh giá | Discovery Service, Migration Evaluator | | Chuẩn bị | Migration Hub, Strategy Recommendations | | Di chuyển | MGN, DMS, DataSync, Snowball |

Từ khoá nhận diện:

"collect configuration, usage, behavioural data" → Application Discovery Service "track progress across migration tools" → Migration Hub "build business case, estimate cost" → Migration Evaluator "lift and shift servers" → MGN

⚠ Bảy chiến lược 7R — phải thuộc: | Chiến lược | Nghĩa | |---|---| | Retire | bỏ hẳn | | Retain | giữ tại chỗ | | Rehost | chuyển nguyên | | Relocate | đổi nền ảo hoá | | Repurchase | đổi sang SaaS | | Replatform | đổi nền tảng, giữ mã | | Refactor | viết lại |

Ba lưu ý về Discovery Agent: | Lưu ý | Chi tiết | |---|---| | Cài lên từng máy — tốn công hơn agentless | | | Nhưng cho dữ liệu kết nối mạng | | | Chạy được trên cả máy vật lý | |

Ba lưu ý về Agentless Collector: | Lưu ý | Chi tiết | |---|---| | Một máy ảo trong vCenter là đủ | | | Không đụng vào máy chủ nào | | | Không thấy tiến trình và kết nối | |

Ba lưu ý về định cỡ: | Lưu ý | Chi tiết | |---|---| | Máy tại chỗ thường thừa công suất rất nhiều | | | Định cỡ theo hiệu năng thật, không theo cấu hình | | | Compute Optimizer tinh chỉnh tiếp sau khi lên | |

⚠ Định cỡ theo cấu hình cũ là sai lầm tốn kém:

Máy tại chỗ: 32 vCPU, dùng trung bình 8%
    → chọn instance 32 vCPU trên AWS
        ↓
    Trả tiền cho công suất chưa bao giờ dùng
    → dữ liệu hiệu năng cho biết
      4 vCPU là đủ

Ba lưu ý về Migration Hub: | Lưu ý | Chi tiết | |---|---| | Chọn một Region làm nơi tập trung | | | Miễn phí, chỉ trả tiền công cụ bên dưới | | | Nhóm theo ứng dụng, không theo máy lẻ | |

Ba lưu ý về Strategy Recommendations: | Lưu ý | Chi tiết | |---|---| | Gợi ý chiến lược 7R cho từng ứng dụng | | | Phân tích được cả mã nguồn và CSDL | | | Nằm trong Migration Hub | |

Ba lưu ý về sơ đồ phụ thuộc: | Lưu ý | Chi tiết | |---|---| | Di chuyển cả cụm cùng lúc | | | Chia nhầm đợt gây độ trễ nghiêm trọng | | | Xuất CSV để phân tích ngoài | |

⚠ Chia nhầm đợt là sai lầm phổ biến nhất:

Máy web lên cloud, CSDL còn tại chỗ
    → mỗi truy vấn đi vòng qua
      đường Direct Connect
        ↓
    Trang cần 50 truy vấn
    → cộng dồn thành vài giây
    → người dùng phàn nàn ngay ngày đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đối chiếu kiểm kê với danh sách tài sản | | | Xem sơ đồ phụ thuộc có hợp lý không | | | Kiểm dữ liệu đã thu đủ hai tuần chưa | |

Và một lời khuyên: hãy dành đủ thời gian cho giai đoạn khám phá trước khi di chuyển bất cứ thứ gì. Gần như mọi dự án di chuyển gặp trục trặc đều bắt đầu từ một phụ thuộc không ai biết — và nó luôn lộ ra vào đêm cutover chứ không phải trong cuộc họp lập kế hoạch.

Đáp án

**B — Dựng Tape Gateway để sao lưu dữ liệu vào Amazon S3 rồi lưu trữ trong Amazon Glacier, dùng chính quy trình băng từ hiện có.

Vì sao đúng

Đề nêu ba yêu cầu, và Tape Gateway khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Chuyển từ hạ tầng sao lưu băng từ hiện có | Tape Gateway mô phỏng thư viện băng | | Lưu trữ dài hạn, rẻ | Glacier | | Bền vững | S3 và Glacier: 11 số 9 |

⚠ Điểm mấu chốt: Tape Gateway lộ ra như một thư viện băng THẬT:

Phần mềm sao lưu (Veeam, NetBackup,
  Backup Exec...) nói giao thức
  iSCSI VTL
        ↓
    Nó thấy một thư viện băng,
      các ổ băng, các cuộn băng
    → không biết phía sau là S3
        ↓
    KHÔNG phải đổi phần mềm hay
      quy trình sao lưu

Đây là lý do File Gateway (phương án C) sai — nó lộ ra chia sẻ NFS/SMB, không phải thư viện băng.

⚠ Vòng đời của một cuộn băng ảo:

Tạo băng ảo
    ↓
Ghi dữ liệu vào (qua phần mềm sao lưu)
    → dữ liệu nằm trong S3
    ↓
"Đẩy ra khỏi thư viện" (eject)
    → chuyển sang Virtual Tape Shelf
    → tức là Glacier
    ↓
Cần lấy lại: "retrieve" băng
    → về lại thư viện ảo

⚠ Và đây là chỗ phương án A gây nhầm lẫn:

Virtual Tape Shelf (VTS) CHÍNH LÀ
  lớp lưu trữ Glacier
        ↓
    Nhưng phương án A nói "sao lưu
      point-in-time as tapes"
    → mô tả này không đúng với cách
      Tape Gateway hoạt động
    → nó không tạo bản sao point-in-time,
      nó lưu chính cuộn băng

Tạo băng ảo:

aws storagegateway create-tapes \
  --gateway-arn <arn-gateway> \
  --tape-size-in-bytes 107374182400 \
  --num-tapes-to-create 10 \
  --tape-barcode-prefix TD \
  --pool-id GLACIER

⚠ pool-id quyết định lớp lưu trữ khi băng bị đẩy ra: | Pool | Lớp | Thời gian lấy | |---|---|---| | GLACIER | Glacier Flexible Retrieval | 3-5 giờ (Standard) | | DEEP_ARCHIVE | Glacier Deep Archive | 12 giờ trở lên |

Deep Archive rẻ hơn nhiều
    → nhưng thời gian lấy rất dài
        ↓
    Chọn theo yêu cầu khôi phục thật

⚠ Thời gian lưu tối thiểu là chi phí ẩn:

Glacier: tối thiểu 90 ngày
Deep Archive: tối thiểu 180 ngày
        ↓
    Xoá băng sớm hơn vẫn bị tính
      đủ thời gian đó
    → chính sách giữ băng phải
      dài hơn con số này

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không đổi phần mềm và quy trình sao lưu | | | Bỏ được thư viện băng vật lý và việc vận chuyển | | | Glacier rẻ hơn nhiều so với giữ băng vật lý | |

⚠ Và lợi ích khó thấy nhất: hết chuyện băng hỏng:

Băng từ vật lý: xuống cấp theo thời gian,
  hỏng khi vận chuyển, đọc lại mới
  biết là không đọc được
        ↓
    S3 và Glacier: 11 số 9 độ bền
    → và tự kiểm tra toàn vẹn

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

• **A. Dựng Tape Gateway sao lưu vào S3 với bản sao point-in-time dạng băng lưu trong Virtual Tape Shelf — đây là phương án gần nhất và Virtual Tape Shelf chính là Glacier, nhưng mô tả "point-in-time backups as tapes" không phản ánh đúng cơ chế: Tape Gateway lưu chính cuộn băng ảo chứ không tạo ảnh chụp thời điểm.
• **C. Dựng File Gateway để sao lưu vào S3 và lưu trữ trong Glacier bằng quy trình băng từ hiện có — File Gateway lộ ra chia sẻ NFS/SMB, phần mềm sao lưu ghi băng không dùng được nó; câu "bằng quy trình băng từ hiện có" mâu thuẫn với chính nó.
• **D. Dựng Stored Volume Gateway với bản sao point-in-time dạng EBS snapshot — volume gateway dành cho lưu trữ khối qua iSCSI, không thay được thư viện băng; và chế độ stored còn giữ toàn bộ dữ liệu trên đĩa cục bộ.

Ghi nhớ

⚠ Bốn kiểu Storage Gateway — bảng phải thuộc: | Kiểu | Giao thức | Dùng cho | |---|---|---| | Tape Gateway | iSCSI VTL | THAY THƯ VIỆN BĂNG | | Volume Gateway | iSCSI | volume khối | | File Gateway (S3) | NFS, SMB | tệp thành object S3 | | FSx File Gateway | SMB | cache cho FSx for Windows |

Từ khoá nhận diện:

"existing tape-based backup process" → Tape Gateway "NFS or SMB share backed by S3" → File Gateway "block storage over iSCSI" → Volume Gateway "long-term archive, cheapest" → Glacier Deep Archive

Ba lưu ý về Tape Gateway: | Lưu ý | Chi tiết | |---|---| | Tương thích với phần mềm sao lưu phổ biến | | | Băng trong thư viện nằm ở S3 | | | Băng đã đẩy ra nằm ở Glacier | |

⚠ Kiểm danh sách phần mềm tương thích TRƯỚC:

AWS công bố danh sách phần mềm
  đã kiểm chứng
    → Veeam, Veritas NetBackup,
      Commvault, Micro Focus...
        ↓
    Phần mềm ngoài danh sách
    → có thể chạy nhưng không được
      hỗ trợ chính thức

Ba lưu ý về khôi phục: | Lưu ý | Chi tiết | |---|---| | Phải "retrieve" băng từ Glacier trước | | | Standard mất 3-5 giờ | | | Tính vào RTO của kế hoạch khôi phục | |

⚠ Đây là điều phải nói rõ với người vận hành:

Quy trình cũ: lấy băng khỏi kho,
  đưa vào ổ đọc — vài phút
        ↓
    Quy trình mới: retrieve từ Glacier
    → vài giờ
        ↓
    Không phải vấn đề nếu kế hoạch
      cho phép, nhưng phải biết trước

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Trả tiền dung lượng thật dùng | | | Thời gian lưu tối thiểu 90 hoặc 180 ngày | | | Có phí lấy dữ liệu ra khỏi Glacier | |

Ba lưu ý về hạ tầng gateway: | Lưu ý | Chi tiết | |---|---| | Chạy trên VMware, Hyper-V, KVM hoặc EC2 | | | Cần đĩa cache và upload buffer | | | Theo dõi UploadBufferPercentUsed | |

⚠ Buffer đầy làm phần mềm sao lưu treo:

Ghi nhanh hơn tốc độ tải lên
    → buffer đầy
        ↓
    Gateway từ chối ghi mới
    → job sao lưu treo, không rõ lý do
    → cảnh báo ở mức 80%

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Dữ liệu mã hoá khi truyền và khi lưu | | | Dùng khoá KMS riêng nếu cần | | | CHAP xác thực kết nối iSCSI | |

Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | Băng ghi rồi có chế độ WORM | | | Đáp ứng yêu cầu giữ bất biến | | | Ghi lại chính sách giữ và xoá | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy một job sao lưu đầy đủ | | | Retrieve một băng và khôi phục thử | | | Bấm giờ toàn bộ quá trình khôi phục | |

Và một lời khuyên: hãy khôi phục thử từ một cuộn băng đã đẩy sang Glacier trước khi bỏ thư viện băng cũ. Đó là cách duy nhất biết thời gian khôi phục thật, và cũng là lần cuối bạn còn có đường lui nếu con số đó không chấp nhận được.

Đáp án

**A và C — Lên lịch chụp ảnh EC2 hằng ngày cho tầng web và tầng ứng dụng rồi sao chép ảnh chụp sang Region dự phòng; và dựng read replica xuyên Region của Aurora sang Region đó, thăng cấp nó thành CSDL chính khi có sự cố.

Vì sao đúng

Đề cho hai con số, và hai đáp án lo hai tầng khác nhau: | Tầng | Chỉ tiêu | Cách đáp ứng | |---|---|---| | Ứng dụng (stateless) | RTO 30 phút | ảnh chụp EC2, khởi động lại khi cần | | Dữ liệu | RPO 5 phút | Aurora cross-region replica |

⚠ Vì sao ảnh chụp hằng ngày là đủ cho tầng ứng dụng:

Đề nói web và ứng dụng đều STATELESS
    → không giữ dữ liệu nào
        ↓
    Ảnh chụp chỉ để có AMI khởi động
    → nội dung "cũ một ngày" không sao
    → RPO của tầng này không có ý nghĩa

⚠ Và RTO 30 phút đủ rộng để khởi động từ ảnh chụp:

Sao chép AMI đã có sẵn ở Region kia
    → khởi động ASG từ AMI đó
    → vài phút
        ↓
    Không cần chạy sẵn máy nào
    → đây là chỗ tiết kiệm chi phí

Đây là lý do phương án D (hot standby) đắt hơn mức cần thiết.

Sao chép AMI sang Region khác:

aws ec2 copy-image --source-region ap-southeast-1 \
  --source-image-id ami-abc \
  --name "ung-dung-$(date +%F)" \
  --region us-west-2

⚠ Aurora cross-region replica cho RPO dưới một phút:

aws rds create-db-cluster \
  --db-cluster-identifier cum-dr \
  --engine aurora-mysql \
  --replication-source-identifier <arn-cum-chinh> \
  --region us-west-2

⚠ Nhưng có hai lựa chọn Aurora xuyên Region — phải phân biệt: | Cơ chế | RPO | RTO chuyển đổi | |---|---|---| | Cross-region read replica | giây tới phút | thăng cấp, vài phút | | Aurora Global Database | dưới 1 giây | thường dưới 1 phút |

Global Database dùng nhân bản ở
  tầng LƯU TRỮ
    → nhanh hơn nhiều và không
      tốn CPU của instance chính
        ↓
    Với 40 TB dữ liệu thì đây là
      lựa chọn tốt hơn hẳn

⚠ Vì sao ảnh chụp Aurora mỗi 5 phút không khả thi:

Phương án B nói "snapshot tự động
  mỗi 5 phút"
        ↓
    Aurora KHÔNG cho đặt tần suất
      ảnh chụp tự động
    → và ảnh chụp cụm 40 TB mất
      rất lâu, không xong trong 5 phút
        ↓
    Khôi phục 40 TB cũng vượt RTO
      30 phút

Thăng cấp khi có sự cố:

aws rds promote-read-replica-db-cluster \
  --db-cluster-identifier cum-dr --region us-west-2

⚠ Thăng cấp là thao tác MỘT CHIỀU:

Replica thành cụm độc lập
    → mất liên kết với cụm gốc
        ↓
    Muốn quay về Region chính
    → phải dựng lại chiều nhân bản ngược
    → lên kế hoạch cho cả chiều về

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | RPO dữ liệu tính bằng giây | | | Không chạy máy ứng dụng thường trực ở Region phụ | | | Chi phí thấp hơn nhiều so với hot standby | |

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

• **D. Dựng hot standby cho tầng web và ứng dụng ở Region dự phòng, chuyển lưu lượng khi có sự cố — đây là phương án gần nhất và chắc chắn đáp ứng RTO, nhưng nó chạy công suất đầy đủ 24/7 trong khi RTO 30 phút cho phép khởi động từ AMI; đề nhấn mạnh "cost-effective".
• **B. Đặt ảnh chụp tự động Aurora mỗi 5 phút rồi khôi phục nhanh ở Region dự phòng — Aurora không cho đặt tần suất ảnh chụp như vậy, và khôi phục 40 TB không xong trong RTO 30 phút.
• **E. Dùng AWS Backup sao chép EBS volume và dữ liệu RDS vào một bucket S3 ở Region khác — AWS Backup lưu vào backup vault, không phải bucket S3; và sao lưu theo lịch không đạt RPO 5 phút.

Ghi nhớ

⚠ Bốn chiến lược DR và RTO/RPO — bảng phải thuộc: | Chiến lược | RTO | RPO | Chi phí | |---|---|---|---| | Backup & Restore | giờ | theo tần suất sao lưu | thấp nhất | | Pilot Light | chục phút | phút | thấp | | Warm Standby | phút | giây | trung bình | | Multi-Site | gần 0 | gần 0 | cao nhất |

RTO 30 phút + RPO 5 phút
    → Pilot Light là vừa đủ
    → dữ liệu nhân bản liên tục,
      tầng ứng dụng dựng khi cần

Từ khoá nhận diện:

"stateless tiers, RTO tens of minutes" → AMI + ASG, không cần chạy sẵn "RPO seconds to minutes" → nhân bản liên tục "cost-effective DR" → không chạy công suất đầy ở Region phụ "RPO near zero" → Aurora Global Database

Ba lưu ý về Aurora Global Database: | Lưu ý | Chi tiết | |---|---| | Nhân bản ở tầng lưu trữ, độ trễ dưới 1 giây | | | Tới 5 Region phụ | | | Managed planned failover và unplanned failover | |

⚠ failover-global-cluster cho chuyển đổi có kiểm soát:

aws rds failover-global-cluster \
  --global-cluster-identifier cum-toan-cau \
  --target-db-cluster-identifier <arn-cum-phu>

Chuyển đổi có kế hoạch: không mất dữ liệu
    → dùng cho diễn tập định kỳ

Ba lưu ý về AMI xuyên Region: | Lưu ý | Chi tiết | |---|---| | Phải sao chép sang Region đích trước | | | AMI mã hoá cần khoá KMS ở Region đích | | | Tự động hoá bằng EventBridge + Lambda | |

⚠ AMI mã hoá là chỗ hay vướng:

Sao chép AMI mã hoá sang Region khác
    → cần chỉ định khoá KMS
      của Region ĐÍCH
        ↓
    Và vai trò phải có quyền dùng
      cả hai khoá

Ba lưu ý về hạn ngạch Region phụ: | Lưu ý | Chi tiết | |---|---| | Hạn ngạch vCPU thường ở mức mặc định | | | Xin tăng TRƯỚC, không phải lúc sự cố | | | Kiểm cả hạn ngạch EIP, ENI, ALB | |

Ba lưu ý về hạ tầng dạng mã: | Lưu ý | Chi tiết | |---|---| | CloudFormation dựng ASG và ALB bằng một lệnh | | | Giữ template đồng bộ giữa hai Region | | | Đây là yếu tố rút ngắn RTO lớn nhất | |

Ba lưu ý về Route 53: | Lưu ý | Chi tiết | |---|---| | Failover routing với health check | | | TTL ngắn cho bản ghi chuyển đổi | | | Global Accelerator nhanh hơn nếu cần | |

Ba lưu ý về diễn tập: | Lưu ý | Chi tiết | |---|---| | Diễn tập định kỳ, bấm giờ thật | | | Kiểm cả chiều quay về Region chính | | | Ghi lại RTO và RPO đo được | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khởi động ASG từ AMI ở Region phụ, bấm giờ | | | Đo độ trễ nhân bản Aurora | | | Thăng cấp replica ở môi trường thử | |

Và một lời khuyên: hãy cân nhắc Aurora Global Database thay vì cross-region read replica cho cụm 40 TB. Nhân bản ở tầng lưu trữ không tiêu CPU của instance chính và cho RPO dưới một giây — chênh lệch đó đáng giá hơn nhiều so với phần chi phí tăng thêm.

Đáp án

**C — Dùng AWS IoT Core với MQTT, tạo một endpoint Data-ATS mới, cập nhật bản ghi Route 53 trỏ tới endpoint đó để thiết bị gửi dữ liệu bằng MQTT, và tạo IoT rule chèn thẳng dữ liệu vào bảng DynamoDB.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Broker MQTT không được sập vì quá tải | IoT Core là dịch vụ quản lý, tự co giãn | | Không mất dữ liệu cảm biến | không còn máy chủ nào để sập | | Rẻ | trả theo tin nhắn, không có EC2 chạy 24/7 |

⚠ Vấn đề gốc là tự vận hành broker MQTT:

Một EC2 lớn chạy broker
    → hàng triệu cảm biến gửi về
        ↓
    Quá tải → sập → MẤT dữ liệu
        ↓
    Thêm máy và cân bằng tải chỉ
      dời điểm gãy đi chỗ khác
    → IoT Core loại bỏ hẳn lớp này

⚠ Và IoT rule ghi thẳng vào DynamoDB — bỏ được cả tầng ứng dụng:

Kiến trúc cũ:
  cảm biến → broker → ứng dụng → DynamoDB
        ↓
    Kiến trúc mới:
  cảm biến → IoT Core → rule → DynamoDB
        ↓
    Bớt hai tầng có thể hỏng

Tạo rule ghi vào DynamoDB:

aws iot create-topic-rule --rule-name ghi_nhiet_do \
  --topic-rule-payload '{
    "sql": "SELECT maCamBien, nhietDo, timestamp() AS thoiGian FROM \"cam-bien/+/nhiet-do\"",
    "actions": [{"dynamoDBv2": {
      "roleArn": "<arn-vai-tro>",
      "putItem": {"tableName": "DuLieuNhietDo"}}}],
    "errorAction": {"republish": {
      "topic": "loi/ghi-dynamodb", "roleArn": "<arn>"}}}'

⚠ errorAction là phần luôn nên khai:

Ghi DynamoDB thất bại (hết WCU,
  quyền sai)
    → không có error action:
      thông điệp biến mất
        ↓
    Có: chuyển sang chủ đề lỗi
    → điều tra được

⚠ Endpoint Data-ATS là chi tiết kỹ thuật quan trọng:

ATS = Amazon Trust Services
    → chuỗi chứng chỉ hiện đại
        ↓
    Endpoint cũ (VeriSign) đã bị
      loại bỏ dần
    → thiết bị mới phải dùng ATS

aws iot describe-endpoint --endpoint-type iot:Data-ATS

⚠ Và trỏ Route 53 tới endpoint IoT Core:

Thiết bị đã cài cứng tên miền
  `iot.tutorialsdojotest.com`
        ↓
    Tạo CNAME trỏ tới endpoint ATS
    → không phải cập nhật firmware
      hàng triệu thiết bị
        ↓
    Đây là chi tiết khiến phương án này
      khả thi trong thực tế

⚠ Nhưng phải chú ý một ràng buộc về chứng chỉ:

IoT Core cấp chứng chỉ cho tên miền
  của chính nó
    → client kiểm tên miền sẽ thấy lệch
        ↓
    Cần custom domain (configurable
      endpoint) để dùng tên riêng
      với chứng chỉ hợp lệ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không còn máy chủ nào để sập | | | Co giãn tới hàng triệu thiết bị | | | Chi phí theo lượng tin nhắn thật | |

⚠ Và Basic Ingest giảm chi phí thêm nữa:

Chủ đề dành riêng:
  `$aws/rules/<ten-rule>/<phan-tuy-y>`
        ↓
    Bỏ qua message broker
    → không tính phí messaging
    → dùng được khi không cần
      pub/sub giữa các thiết bị

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

• **A. Tạo ASG cho broker MQTT sau một NLB vì NLB hỗ trợ TCP, dùng EFS làm lưu trữ dùng chung — đây là phương án gần nhất và NLB thật sự xử lý được TCP cho MQTT, nhưng vẫn phải tự vận hành đội broker: MQTT là giao thức có trạng thái phiên, cân bằng tải nó phức tạp hơn nhiều so với HTTP, và EFS không giải quyết việc đồng bộ trạng thái broker.
• **B. Dùng IoT Device Management cập nhật firmware để thiết bị gửi lệch giờ, và thêm một EC2 broker ở Region khác — chia tải bằng cách làm thiết bị gửi thưa hơn là giảm độ chi tiết dữ liệu; và vẫn giữ nguyên mô hình tự vận hành broker.
• **D. Tạo endpoint Data-ATS trong AWS IoT Greengrass — Greengrass là phần mềm chạy ở thiết bị biên, nó không phải endpoint đám mây để hàng triệu cảm biến kết nối vào.

Ghi nhớ

⚠ Bốn dịch vụ IoT — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | IoT Core | kết nối, xác thực, định tuyến thông điệp | | IoT Device Management | kiểm kê, theo dõi, cập nhật đội thiết bị | | IoT Device Defender | kiểm toán bảo mật, phát hiện bất thường | | IoT Greengrass | chạy logic tại thiết bị biên |

Từ khoá nhận diện:

"self-managed MQTT broker crashes" → IoT Core "run inference offline at the edge" → Greengrass "are devices still connected" → Device Management, Fleet Indexing "industrial equipment, OPC-UA" → IoT SiteWise

Ba lưu ý về IoT rule: | Lưu ý | Chi tiết | |---|---| | Cú pháp giống SQL, lọc ngay tại nguồn | | | Ghi thẳng vào DynamoDB, S3, Kinesis, Lambda | | | Luôn khai errorAction | |

⚠ Lọc tại nguồn giảm chi phí ở mọi tầng phía sau:

SELECT maCamBien, nhietDo
FROM 'cam-bien/+/nhiet-do'
WHERE nhietDo > 35 OR nhietDo < 5

Chỉ đẩy đi giá trị bất thường
    → giảm ghi DynamoDB rất nhiều

Ba lưu ý về DynamoDB cho dữ liệu cảm biến: | Lưu ý | Chi tiết | |---|---| | Khoá phân vùng theo mã cảm biến | | | Khoá sắp xếp theo thời gian | | | TTL tự xoá dữ liệu cũ | |

⚠ On-demand hợp hơn provisioned ở đây:

Hàng triệu cảm biến, lượng gửi
  khó đoán
        ↓
    Provisioned phải canh và chỉnh tay
    → on-demand không có trần để chạm

Ba lưu ý về Timestream: | Lưu ý | Chi tiết | |---|---| | CSDL chuỗi thời gian chuyên dụng | | | Tự chuyển dữ liệu cũ sang lớp rẻ | | | Hợp hơn DynamoDB cho dữ liệu đo lường | |

⚠ Với dữ liệu nhiệt độ theo thời gian, Timestream đáng cân nhắc:

DynamoDB: tốt cho tra cứu theo khoá
        ↓
    Timestream: tốt cho truy vấn
      theo khoảng thời gian, nội suy,
      tính trung bình trượt
    → và rẻ hơn cho dữ liệu chuỗi

Ba lưu ý về bảo mật IoT: | Lưu ý | Chi tiết | |---|---| | Mỗi thiết bị một chứng chỉ X.509 | | | Chính sách giới hạn theo chủ đề | | | Fleet Provisioning cho việc cấp chứng chỉ hàng loạt | |

{"Effect": "Allow", "Action": "iot:Publish",
 "Resource": "arn:aws:iot:*:*:topic/cam-bien/${iot:Connection.Thing.ThingName}/*"}

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | Fleet Metrics đếm thiết bị đang online | | | Cảnh báo khi số thiết bị giảm đột ngột | | | Bật log của IoT Core ở mức ERROR | |

⚠ Hệ thống IoT hỏng theo kiểu im lặng:

Không có lỗi nào, không có ngoại lệ
    → chỉ đơn giản là dữ liệu
      ngừng đến
        ↓
    Cảnh báo trên số thiết bị kết nối
      là biện pháp phát hiện duy nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dùng MQTT test client gửi thử một tin | | | Kiểm bảng DynamoDB có bản ghi mới | | | Xem chủ đề lỗi có tin nào không | |

Và một lời khuyên: hãy bỏ hẳn lớp broker tự vận hành thay vì tìm cách làm nó chịu tải tốt hơn. Thêm máy và cân bằng tải chỉ dời điểm gãy sang chỗ khác — còn một dịch vụ quản lý thì không có điểm gãy nào để bạn phải trực đêm mà canh.

Đáp án

**B và E — Cấu hình CloudFront dùng chứng chỉ SSL/TLS mặc định của nó bằng cách đổi thiết lập Viewer Protocol Policy cho một hoặc nhiều cache behavior sang bắt buộc HTTPS; và đặt Viewer Protocol Policy thành Redirect HTTP to HTTPS hoặc HTTPS Only.

Vì sao đúng

Đề cho một dữ kiện quyết định mọi thứ:

Phân phối dùng TÊN MIỀN MẶC ĐỊNH
  `dtut0r1al5doj0.cloudfront.net`
        ↓
    CloudFront đã có sẵn chứng chỉ
      cho `*.cloudfront.net`
    → không cần yêu cầu chứng chỉ nào
        ↓
    Chỉ cần BẬT bắt buộc HTTPS

⚠ Ba giá trị của Viewer Protocol Policy — bảng phải thuộc: | Giá trị | Hành vi | |---|---| | allow-all | cho cả HTTP và HTTPS (mặc định cũ) | | redirect-to-https | HTTP nhận 301 chuyển sang HTTPS | | https-only | HTTP nhận lỗi 403 |

`redirect-to-https`: người dùng gõ http
  vẫn vào được, được chuyển tự động
        ↓
    `https-only`: từ chối thẳng
    → an toàn hơn nhưng có thể
      làm hỏng liên kết cũ

Cấu hình:

aws cloudfront update-distribution --id <id> \
  --distribution-config '{
    "DefaultCacheBehavior": {
      "ViewerProtocolPolicy": "redirect-to-https",
      "TargetOriginId": "elb-goc"},
    "ViewerCertificate": {
      "CloudFrontDefaultCertificate": true,
      "MinimumProtocolVersion": "TLSv1.2_2021"}}'

⚠ Chứng chỉ mặc định chỉ hợp lệ cho tên miền *.cloudfront.net:

Dùng tên miền riêng
  (`www.congty.com`)
    → chứng chỉ mặc định KHÔNG khớp
    → trình duyệt báo lỗi
        ↓
    Lúc đó mới cần chứng chỉ ACM
      ở us-east-1

⚠ Và đề chỉ hỏi phần "viewer tới CloudFront":

Viewer Protocol Policy: giữa NGƯỜI DÙNG
  và CloudFront
        ↓
    Origin Protocol Policy: giữa CloudFront
      và ORIGIN
    → là hai thiết lập khác nhau
        ↓
    Đề hỏi vế đầu
    → nên chứng chỉ ở ELB không liên quan

Đây là lý do các phương án nói về ELB đều sai.

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Miễn phí, không phải xin chứng chỉ | | | Bật bằng một thiết lập, có hiệu lực ngay | | | Cải thiện xếp hạng tìm kiếm như đề mong muốn | |

⚠ Nhưng đầu-cuối chưa hoàn chỉnh nếu origin vẫn HTTP:

Người dùng → CloudFront: mã hoá
        ↓
    CloudFront → ELB: nếu để HTTP
      thì đoạn này ở dạng rõ
        ↓
    Đặt `OriginProtocolPolicy: https-only`
    → và ELB cần chứng chỉ hợp lệ

{"CustomOriginConfig": {
  "OriginProtocolPolicy": "https-only",
  "OriginSslProtocols": {"Quantity": 1, "Items": ["TLSv1.2"]}}}

Ghi nhớ về chất lượng câu hỏi

⚠ Hai đáp án về bản chất là cùng một hành động.

Cả B và E đều nói tới việc đặt Viewer Protocol Policy sang chế độ bắt buộc HTTPS:

B: "dùng chứng chỉ mặc định bằng cách
    ĐỔI Viewer Protocol Policy"
        ↓
    E: "đặt Viewer Protocol Policy thành
        Redirect HTTP to HTTPS hoặc HTTPS Only"
        ↓
    B mô tả cùng thao tác nhưng thêm
      phần "dùng chứng chỉ mặc định"

Về mặt kỹ thuật cả hai đều đúng, nhưng đây không phải hai giải pháp độc lập — chúng là một giải pháp được diễn đạt hai lần với mức chi tiết khác nhau. Câu hỏi yêu cầu chọn hai đáp án nhưng thực chất chỉ có một hành động.

Và một chi tiết nữa đáng lưu ý:

Đề nói ASG dùng SPOT instance cho
  một website sản xuất
        ↓
    Đây là quyết định thiết kế đáng
      ngờ nhưng không liên quan tới
      câu hỏi
    → Spot bị thu hồi là mất công suất
      giữa lúc bận

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

• **A. Cấu hình ELB dùng chứng chỉ SSL/TLS mặc định của nó — đây là phương án gần nhất và liên quan tới TLS, nhưng ELB không có chứng chỉ mặc định nào; và kể cả có thì nó nằm ở đoạn CloudFront–origin, không phải đoạn viewer–CloudFront mà đề hỏi.
• **C. Dùng chứng chỉ tự ký ở ELB — chứng chỉ tự ký làm trình duyệt báo lỗi bảo mật; và lại sai đoạn.
• **D. Dùng chứng chỉ tự ký ở ELB lưu trong bucket S3 riêng tư — ELB nhận chứng chỉ từ ACM hoặc IAM certificate store, không đọc từ S3.

Ghi nhớ

⚠ Hai thiết lập giao thức của CloudFront — bảng phải thuộc: | Thiết lập | Đoạn đường | |---|---| | Viewer Protocol Policy | người dùng ↔ CloudFront | | Origin Protocol Policy | CloudFront ↔ origin |

Từ khoá nhận diện:

"require HTTPS between viewers and CloudFront" → Viewer Protocol Policy "end-to-end HTTPS" → cả hai thiết lập + chứng chỉ ở origin "custom domain with HTTPS" → ACM ở us-east-1 "default cloudfront.net domain" → chứng chỉ mặc định là đủ

Ba lưu ý về chứng chỉ CloudFront: | Lưu ý | Chi tiết | |---|---| | Mặc định chỉ hợp lệ cho *.cloudfront.net | | | Tên miền riêng cần ACM ở us-east-1 | | | SNI miễn phí, dedicated IP rất đắt | |

⚠ SNI so với dedicated IP: | Tiêu chí | SNI | Dedicated IP | |---|---|---| | Chi phí | miễn phí | ~600 USD/tháng | | Hỗ trợ trình duyệt cũ không hiểu SNI | không | có |

Trình duyệt hiện đại đều hiểu SNI
    → dedicated IP gần như không
      còn lý do tồn tại

Ba lưu ý về SSL policy: | Lưu ý | Chi tiết | |---|---| | Đặt MinimumProtocolVersion từ TLS 1.2 | | | TLSv1.2_2021 là lựa chọn phổ biến | | | Bỏ TLS 1.0/1.1 để đạt tuân thủ | |

Ba lưu ý về HSTS: | Lưu ý | Chi tiết | |---|---| | Bảo trình duyệt luôn dùng HTTPS | | | Thêm bằng response headers policy | | | Bắt đầu với max-age ngắn | |

aws cloudfront create-response-headers-policy \
  --response-headers-policy-config '{
    "Name":"bao-mat-co-ban",
    "SecurityHeadersConfig":{
      "StrictTransportSecurity":{
        "AccessControlMaxAgeSec":31536000,
        "IncludeSubdomains":true,"Override":true}}}'

⚠ HSTS includeSubDomains là quyết định khó đảo ngược:

Trình duyệt ghi nhớ trong một năm
    → mọi tên miền con bị ép HTTPS
        ↓
    Một tên miền con chưa có chứng chỉ
    → không truy cập được
    → bắt đầu với max-age vài phút

Ba lưu ý về mã hoá tới origin: | Lưu ý | Chi tiết | |---|---| | https-only cho đoạn CloudFront–origin | | | Origin cần chứng chỉ hợp lệ | | | CloudFront kiểm chứng chỉ của origin | |

⚠ Điểm cuối khác với ALB tới target:

ALB tới target: KHÔNG kiểm chứng chỉ
    → tự ký cũng được
        ↓
    CloudFront tới origin: CÓ kiểm
    → chứng chỉ tự ký sẽ bị từ chối

Ba lưu ý về SEO: | Lưu ý | Chi tiết | |---|---| | HTTPS là yếu tố xếp hạng của Google | | | Dùng chuyển hướng 301, không phải 302 | | | Cập nhật liên kết nội bộ sang HTTPS | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl -I http://... xem có 301 không | | | openssl s_client kiểm chuỗi chứng chỉ | | | Kiểm không còn nội dung hỗn hợp HTTP | |

Và một lời khuyên: hãy kiểm tra nội dung hỗn hợp sau khi bật HTTPS. Trang tải qua HTTPS mà vẫn nhúng ảnh hoặc script qua HTTP sẽ bị trình duyệt chặn hoặc cảnh báo — và với một trang chia sẻ ảnh thì đó là thứ hỏng thấy ngay.

Đáp án

**D — Tạo bucket S3 và chuyển dữ liệu từ hệ thống tệp dùng chung sang đó, dùng lớp S3 Intelligent-Tiering; dùng lazy loading trên hệ thống tệp FSx for Lustre để nhập nội dung từ bucket; dùng hệ thống tệp đó làm lưu trữ dùng chung cho tầng ứng dụng trong lúc chạy rồi xoá đi khi xong.

Vì sao đúng

Đề nêu đúng một vấn đề: tầng lưu trữ chạy 24/7 nhưng chỉ được dùng 72 giờ mỗi tháng.

Cụm EC2 giữ 200 TB chạy liên tục
    → 720 giờ mỗi tháng
    → chỉ dùng 72 giờ
        ↓
    90% thời gian là trả tiền
      cho công suất nhàn rỗi

⚠ Giải pháp là tách LƯU TRỮ khỏi TÍNH TOÁN:

S3 giữ dữ liệu vĩnh viễn — rất rẻ
        ↓
    FSx for Lustre dựng khi cần
    → hiệu năng cao cho 72 giờ
    → XOÁ khi xong
        ↓
    Chỉ trả tiền hiệu năng cao
      trong đúng 72 giờ

⚠ Lazy loading là cơ chế làm việc này khả thi:

Tạo hệ thống tệp liên kết với bucket
    → KHÔNG chép 200 TB ngay
        ↓
    Khi ứng dụng đọc một tệp lần đầu
    → Lustre kéo tệp đó từ S3
        ↓
    Hệ thống tệp sẵn sàng trong vài phút
    → thay vì chờ chép hết

Tạo hệ thống tệp liên kết S3:

aws fsx create-file-system --file-system-type LUSTRE \
  --storage-capacity 24000 \
  --subnet-ids subnet-abc \
  --lustre-configuration '{
    "DeploymentType":"SCRATCH_2",
    "DataRepositoryConfiguration":{
      "ImportPath":"s3://du-lieu-tai-chinh/",
      "ExportPath":"s3://du-lieu-tai-chinh/ket-qua/"}}'

⚠ SCRATCH_2 là loại triển khai đúng cho công việc tạm: | Loại | Đặc điểm | |---|---| | Scratch | hiệu năng cao, KHÔNG nhân bản, rẻ hơn | | Persistent | có nhân bản, tự sửa chữa, đắt hơn |

Dữ liệu gốc nằm trên S3
    → hệ thống tệp chỉ là bản sao tạm
    → mất nó không mất gì
        ↓
    Scratch là lựa chọn đúng và rẻ hơn

⚠ Và đây là lý do Intelligent-Tiering thắng Glacier Instant Retrieval:

FSx for Lustre KHÔNG đọc trực tiếp
  được object ở lớp Glacier
        ↓
    Phải khôi phục về Standard trước
    → thêm bước và thêm độ trễ
        ↓
    Intelligent-Tiering: object vẫn
      truy cập được ngay ở mọi tầng
    → mà vẫn tự giảm chi phí

Đây là điểm phân biệt D với B.

Xuất kết quả về S3:

aws fsx create-data-repository-task \
  --file-system-id fs-abc --type EXPORT_TO_REPOSITORY \
  --paths /ket-qua --report Enabled=false

⚠ Phải xuất kết quả TRƯỚC khi xoá hệ thống tệp:

Xoá Lustre scratch mà chưa xuất
    → mất toàn bộ kết quả 72 giờ tính toán
        ↓
    Luôn chạy export task và chờ
      hoàn tất rồi mới xoá

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Bỏ hẳn cụm lưu trữ chạy 24/7 | | | Lustre cho thông lượng rất cao khi cần | | | S3 giữ dữ liệu với chi phí thấp nhất | |

⚠ Và Lustre là hệ thống tệp song song, đúng cho tải này:

Nhiều instance đọc cùng lúc
    → Lustre trải dữ liệu qua nhiều
      máy chủ lưu trữ
        ↓
    Thông lượng tổng lên tới
      hàng trăm GB/giây
    → đây là thứ EFS không làm được

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

• **B. Cùng kiến trúc S3 + FSx for Lustre nhưng dùng lớp S3 Glacier Instant Retrieval — đây là phương án gần nhất và chỉ khác một lớp lưu trữ, nhưng FSx for Lustre không nhập trực tiếp được object ở lớp Glacier; và Glacier có thời gian lưu tối thiểu 90 ngày cùng phí truy xuất.
• **A. Chuyển sang EFS lớp Standard-IA và mount cho tầng ứng dụng — EFS đắt hơn nhiều so với S3 cho 200 TB, và thông lượng của nó thấp hơn Lustre đáng kể cho tải tính toán song song.
• **C. Tạo một EBS volume lớn có Multi-Attach — Multi-Attach chỉ hỗ trợ io1/io2, giới hạn 16 instance, chỉ trong một AZ, và volume vẫn tồn tại (vẫn tính tiền) sau khi xong việc.

Ghi nhớ

⚠ Bốn hệ thống tệp dùng chung — bảng phải thuộc: | Dịch vụ | Hợp với | |---|---| | EFS | NFS chung, nhiều AZ, tải vừa | | FSx for Lustre | HPC, tính toán song song, thông lượng rất cao | | FSx for Windows | SMB, Windows ACL, Active Directory | | FSx for NetApp ONTAP | NFS và SMB, tính năng doanh nghiệp |

Từ khoá nhận diện:

"high performance compute, temporary" → FSx for Lustre scratch "data lives in S3, compute occasionally" → Lustre + lazy loading "Windows ACLs, AD domain" → FSx for Windows "simple shared NFS" → EFS

Ba lưu ý về FSx for Lustre: | Lưu ý | Chi tiết | |---|---| | Liên kết được với bucket S3 | | | Lazy loading nạp tệp khi đọc lần đầu | | | Scratch không nhân bản — dữ liệu gốc phải ở S3 | |

⚠ Lần đọc đầu tiên chậm hơn:

Lazy loading: tệp chưa nạp
    → lần đọc đầu phải kéo từ S3
        ↓
    Muốn tránh: dùng preload
    → hoặc chấp nhận vài phút đầu chậm

aws fsx create-data-repository-task \
  --file-system-id fs-abc \
  --type IMPORT_METADATA_FROM_REPOSITORY \
  --paths s3://du-lieu-tai-chinh/

Ba lưu ý về S3 Intelligent-Tiering: | Lưu ý | Chi tiết | |---|---| | Tự chuyển tầng theo mẫu truy cập thật | | | KHÔNG có phí truy xuất | | | Có phí giám sát nhỏ mỗi object | |

⚠ Với hàng triệu object nhỏ, phí giám sát đáng kể:

Phí theo SỐ object, không theo dung lượng
    → tính thử trước khi chọn
        ↓
    Ít object lớn: Intelligent-Tiering
      rất đáng
    → nhiều object nhỏ: cân nhắc
      lifecycle cố định

Ba lưu ý về EBS Multi-Attach: | Lưu ý | Chi tiết | |---|---| | Chỉ io1 và io2 | | | Tối đa 16 instance, cùng một AZ | | | Cần hệ thống tệp hỗ trợ truy cập đồng thời | |

⚠ Multi-Attach không phải hệ thống tệp dùng chung:

Nhiều instance gắn cùng volume
    → nhưng ext4 hay XFS KHÔNG chịu được
    → dữ liệu hỏng ngay
        ↓
    Phải dùng hệ thống tệp cụm
      (GFS2, OCFS2)

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Lustre tính theo GB và giờ | | | Xoá ngay sau khi xong việc | | | S3 giữ dữ liệu với giá thấp nhất | |

Ba lưu ý về tự động hoá: | Lưu ý | Chi tiết | |---|---| | Step Functions điều phối: tạo, chạy, xuất, xoá | | | EventBridge kích hoạt theo lịch cuối tháng | | | CloudFormation dựng và xoá stack | |

⚠ Tự động hoá là điều bắt buộc ở đây:

Quên xoá hệ thống tệp sau khi xong
    → 24 TB Lustre chạy cả tháng
    → mất hết phần tiết kiệm
        ↓
    Đưa bước xoá vào chính quy trình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo thông lượng thật khi chạy job | | | Kiểm kết quả đã xuất về S3 trước khi xoá | | | So chi phí tháng trước và sau | |

Và một lời khuyên: hãy đưa bước xoá hệ thống tệp vào chính quy trình tự động chứ đừng để ai đó nhớ làm. Toàn bộ khoản tiết kiệm của kiến trúc này nằm ở chỗ Lustre chỉ tồn tại 72 giờ — và một lần quên xoá là đủ xoá sạch phần tiết kiệm của cả tháng.

Đáp án

**B — Dùng On-Demand cho cả master node lẫn core node, và dùng Spot cho task node.

Vì sao đúng

Ba loại node trong EMR có vai trò khác nhau, và điều đó quyết định mô hình mua: | Loại node | Vai trò | Mất node thì sao | |---|---|---| | Master | điều phối cụm | CỤM SẬP HOÀN TOÀN | | Core | tính toán + LƯU DỮ LIỆU HDFS | có thể MẤT DỮ LIỆU | | Task | chỉ tính toán | chỉ chậm lại |

⚠ Đây là lý do core node không được dùng Spot:

Core node giữ khối dữ liệu HDFS
    → Spot bị thu hồi
        ↓
    Mất một bản sao khối dữ liệu
    → mất nhiều core cùng lúc
      = MẤT DỮ LIỆU
        ↓
    Đề nói rõ "không hy sinh
      tính toàn vẹn dữ liệu"

⚠ Và task node an toàn với Spot vì chúng không giữ gì:

Task node chỉ nhận việc và tính
    → bị thu hồi giữa chừng
        ↓
    YARN giao lại việc đó cho
      node khác
    → chỉ chậm lại, không mất gì

⚠ Vì sao KHÔNG dùng Reserved Instance:

Đề nói cụm CHẠY MỘT LẦN, 48 giờ
        ↓
    Reserved Instance cam kết
      1 hoặc 3 NĂM
    → trả tiền cho 3 năm để dùng
      2 ngày
        ↓
    Đây là lý do phương án A và C sai

Tạo cụm với đúng cấu hình:

aws emr create-cluster --name phan-tich-hieu-nang \
  --release-label emr-7.0.0 \
  --applications Name=Spark \
  --instance-groups \
    'InstanceGroupType=MASTER,InstanceCount=1,InstanceType=m6g.xlarge,Market=ON_DEMAND' \
    'InstanceGroupType=CORE,InstanceCount=10,InstanceType=r6g.2xlarge,Market=ON_DEMAND' \
    'InstanceGroupType=TASK,InstanceCount=19,InstanceType=r6g.2xlarge,Market=SPOT,BidPrice=0.50' \
  --auto-terminate

⚠ --auto-terminate là cờ quan trọng cho cụm chạy một lần:

Cụm tự tắt sau khi bước cuối xong
    → không có chuyện quên tắt
        ↓
    Quên tắt cụm 30 máy
    → hoá đơn tăng đều mỗi giờ
      mà không ai để ý

⚠ Và EMRFS thay thế HDFS là hướng tốt hơn nữa:

Đọc/ghi thẳng vào S3 thay vì HDFS
    → core node không giữ dữ liệu nữa
        ↓
    Lúc đó CORE cũng dùng Spot được
    → và dữ liệu tồn tại sau khi
      cụm tắt

--configurations '[{
  "Classification":"emrfs-site",
  "Properties":{"fs.s3.consistent":"true"}}]'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Phần lớn công suất chạy trên Spot, rẻ tới 90% | | | Dữ liệu HDFS an toàn trên core node | | | Không cam kết dài hạn cho việc chạy một lần | |

⚠ Đa dạng loại máy cho task node:

InstanceFleetType: TASK
InstanceTypeConfigs:
  - InstanceType: r6g.2xlarge
  - InstanceType: r6i.2xlarge
  - InstanceType: r5.2xlarge
  - InstanceType: m6g.4xlarge

Chỉ xin một loại: hết công suất
  loại đó là không có task node nào
        ↓
    Instance fleet với nhiều loại
    → xác suất mất hết rất thấp

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

• **A. Dùng Reserved cho master và core, Spot cho task — đây là phương án gần nhất và phân bổ theo vai trò node hoàn toàn đúng, nhưng Reserved Instance cam kết 1-3 năm cho một cụm chỉ chạy 48 giờ; đó là khoản chi hoàn toàn lãng phí.
• **C. On-Demand cho core, Reserved cho master, Spot cho task — vẫn có Reserved cho một cụm chạy một lần.
• **D. Kết hợp On-Demand và Spot cho cả master lẫn core, dùng On-Demand cho task — đảo ngược hoàn toàn: master trên Spot nghĩa là cả cụm có thể sập, và task node là chỗ duy nhất nên dùng Spot thì lại dùng On-Demand.

Ghi nhớ

⚠ Ba loại node EMR và mô hình mua — bảng phải thuộc: | Node | Mô hình mua | Lý do | |---|---|---| | Master | On-Demand | mất là sập cụm | | Core | On-Demand | giữ dữ liệu HDFS | | Task | Spot | không giữ gì |

Từ khoá nhận diện:

"cluster runs once" → KHÔNG dùng Reserved "without sacrificing data integrity" → core không dùng Spot "most cost-effective" → Spot cho task node "long-running cluster, steady" → cân nhắc Reserved cho master và core

⚠ Ngoại lệ: cụm chạy lâu dài thì Reserved lại hợp lý:

Cụm EMR chạy 24/7 nhiều năm
    → master và core dùng Reserved
      hoặc Savings Plan
        ↓
    Nhưng đề này nói rõ "chạy một lần"

Ba lưu ý về Spot trên EMR: | Lưu ý | Chi tiết | |---|---| | Instance fleet đa dạng loại máy | | | price-capacity-optimized là chiến lược tốt nhất | | | Đặt số lượng On-Demand tối thiểu làm nền | |

Ba lưu ý về HDFS: | Lưu ý | Chi tiết | |---|---| | Hệ số nhân bản mặc định là 3 | | | Mất nhiều core cùng lúc là mất dữ liệu | | | EMRFS (S3) tách được lưu trữ khỏi tính toán | |

⚠ Tách lưu trữ khỏi tính toán là hướng hiện đại:

Dữ liệu trên S3 (EMRFS)
    → cụm chỉ là tính toán tạm
        ↓
    Tắt cụm không mất gì
    → dựng cụm mới đọc lại dữ liệu cũ
    → và core node dùng Spot được

Ba lưu ý về chi phí EMR: | Lưu ý | Chi tiết | |---|---| | Phí EMR cộng thêm trên giá EC2 | | | Cụm tạm (transient) tự tắt sau khi xong | | | EMR Serverless không phải quản cụm | |

⚠ EMR Serverless đáng cân nhắc cho việc chạy một lần:

Không chọn số node, không chọn loại máy
    → nộp job, trả tiền theo tài nguyên
      thật dùng
        ↓
    Với công việc 48 giờ chạy một lần
    → đơn giản hơn nhiều

Ba lưu ý về tối ưu hiệu năng: | Lưu ý | Chi tiết | |---|---| | Chọn họ instance theo tải: r cho bộ nhớ, c cho CPU | | | Đặt số executor và bộ nhớ Spark phù hợp | | | Nén dữ liệu đầu vào giảm I/O | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | Spark UI xem giai đoạn nào chậm | | | CloudWatch có chỉ số của cụm | | | Cảnh báo khi tỷ lệ mất Spot cao | |

Ba lưu ý về xử lý mất Spot: | Lưu ý | Chi tiết | |---|---| | YARN tự giao lại việc | | | Đặt số lần thử lại của Spark đủ lớn | | | Chấp nhận thời gian chạy dài hơn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy thử với dữ liệu nhỏ trước | | | Xem có mất core node nào không | | | So chi phí thực tế với ước tính | |

Và một lời khuyên: hãy cân nhắc chuyển sang EMRFS trên S3 thay vì HDFS trên core node. Khi dữ liệu không còn nằm trên node tính toán, cả cụm trở thành thứ dùng xong là vứt — và lúc đó Spot dùng được ở mọi vị trí, không chỉ ở task node.

Đáp án

**B — Dùng On-Demand cho cả master node lẫn core node, và dùng Spot cho task node.

Vì sao đúng

Đề cho ba dữ kiện, và mỗi dữ kiện loại bớt một nhóm phương án: | Dữ kiện | Suy ra | |---|---| | Cụm chạy MỘT LẦN, 8 giờ | KHÔNG dùng Reserved (cam kết 1-3 năm) | | 200 instance, 300 TB | phần lớn công suất nên chạy Spot | | Kết quả lưu TẠM trước khi vào Redshift | core node giữ dữ liệu — không dùng Spot |

⚠ Vai trò ba loại node quyết định tất cả:

Master: điều phối, quản lý YARN
    → mất là CỤM SẬP
        ↓
    Core: tính toán + giữ khối HDFS
    → mất nhiều core = MẤT DỮ LIỆU
        ↓
    Task: chỉ tính toán
    → mất chỉ chậm lại

⚠ Và cụm 200 instance làm việc phân bổ càng quan trọng:

Giả sử 1 master + 20 core + 179 task
        ↓
    179 máy chạy Spot
    → tiết kiệm tới 90% trên
      gần 90% công suất
        ↓
    Đây là khoản tiết kiệm rất lớn
      ở quy mô này

Tạo cụm với instance fleet:

aws emr create-cluster --name phan-tich-hat \
  --release-label emr-7.0.0 \
  --applications Name=Spark \
  --instance-fleets \
    '{"InstanceFleetType":"MASTER","TargetOnDemandCapacity":1,
      "InstanceTypeConfigs":[{"InstanceType":"m6g.2xlarge"}]}' \
    '{"InstanceFleetType":"CORE","TargetOnDemandCapacity":20,
      "InstanceTypeConfigs":[{"InstanceType":"r6g.4xlarge"}]}' \
    '{"InstanceFleetType":"TASK","TargetSpotCapacity":179,
      "InstanceTypeConfigs":[
        {"InstanceType":"r6g.4xlarge"},
        {"InstanceType":"r6i.4xlarge"},
        {"InstanceType":"r5.4xlarge"},
        {"InstanceType":"m6g.8xlarge"}]}' \
  --auto-terminate

⚠ Đa dạng loại máy là điều bắt buộc ở quy mô 179 máy Spot:

Xin 179 máy cùng một loại
    → nhóm công suất Spot của loại đó
      có thể không đủ
        ↓
    Bốn loại tương đương
    → EC2 lấy từ nhóm nào rộng nhất
    → và ít bị thu hồi cùng lúc hơn

⚠ Chiến lược phân bổ:

{"SpotSpecification": {
  "AllocationStrategy": "price-capacity-optimized",
  "TimeoutDurationMinutes": 30,
  "TimeoutAction": "SWITCH_TO_ON_DEMAND"}}

`price-capacity-optimized`: cân bằng
  giữa giá rẻ và nhóm công suất sâu
        ↓
    `SWITCH_TO_ON_DEMAND`: không xin
      đủ Spot trong 30 phút thì
      chuyển sang On-Demand
    → cụm vẫn chạy được

⚠ Và "lưu tạm trước khi vào Redshift" nên là S3, không phải HDFS:

Kết quả nằm trên HDFS của core node
    → cụm tắt là mất
        ↓
    Ghi kết quả ra S3
    → rồi `COPY` vào Redshift
    → và S3 là nơi trung chuyển đúng

COPY ket_qua_phan_tich
FROM 's3://ket-qua-tam/phan-tich/'
IAM_ROLE 'arn:aws:iam::111122223333:role/RedshiftCopy'
FORMAT AS PARQUET;

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Gần 90% công suất chạy giá Spot | | | Dữ liệu HDFS an toàn trên core | | | Cụm tự tắt sau khi xong | |

Ghi nhớ về chất lượng câu hỏi

⚠ Câu này gần như trùng hoàn toàn với một câu khác trong cùng bộ đề (mã #10469).

Chỉ khác con số và câu chuyện
    → cùng một kiến thức được
      hỏi hai lần
        ↓
    Dấu hiệu bộ đề gom từ nhiều
      lần thi mà không biên tập lại

Điều này không làm câu hỏi sai, nhưng người luyện thi nên biết: gặp câu thứ hai không có nghĩa là bạn đã học thêm được gì mới.

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

• **C. Reserved cho master, On-Demand cho core, Spot cho task — đây là phương án gần nhất và phân bổ theo vai trò đúng, nhưng Reserved Instance cam kết 1-3 năm cho một cụm chạy 8 giờ.
• **A. Reserved cho master và core, Spot cho task — cùng vấn đề Reserved.
• **D. Kết hợp On-Demand và Spot cho master và core, Spot cho task — master trên Spot nghĩa là cả cụm 200 máy có thể sập giữa chừng.

Ghi nhớ

⚠ Ba loại node EMR — bảng phải thuộc: | Node | Giữ dữ liệu | Spot được không | |---|---|---| | Master | metadata cụm | KHÔNG | | Core | khối HDFS | không (trừ khi dùng EMRFS) | | Task | không giữ gì | CÓ |

Từ khoá nhận diện:

"cluster runs once" → không dùng Reserved "data integrity" → core không dùng Spot "temporary results before warehouse" → S3 rồi COPY vào Redshift "long-running steady cluster" → cân nhắc Savings Plan

Ba lưu ý về instance fleet: | Lưu ý | Chi tiết | |---|---| | Khai nhiều loại máy cho mỗi fleet | | | Đặt timeout và hành động khi không đủ Spot | | | Linh hoạt hơn instance group | |

Ba lưu ý về EMR quy mô lớn: | Lưu ý | Chi tiết | |---|---| | Kiểm hạn ngạch vCPU trước khi tạo 200 máy | | | Đặt cụm trong placement group nếu cần độ trễ thấp | | | Chú ý số IP trống trong subnet | |

⚠ Hạn ngạch và IP là hai thứ chặn cụm lớn:

200 instance r6g.4xlarge = 3.200 vCPU
    → hạn ngạch mặc định thường thấp hơn
        ↓
    Và subnet /24 chỉ có 251 IP dùng được
    → 200 instance là gần chạm trần

Ba lưu ý về EMRFS: | Lưu ý | Chi tiết | |---|---| | Đọc/ghi thẳng S3 thay HDFS | | | Core node không giữ dữ liệu nữa | | | Lúc đó core cũng dùng Spot được | |

Ba lưu ý về Redshift: | Lưu ý | Chi tiết | |---|---| | COPY từ S3 nhanh hơn INSERT rất nhiều | | | Parquet nhanh hơn CSV | | | Chia tệp thành nhiều phần để nạp song song | |

⚠ Số tệp nên là bội của số slice:

Redshift nạp song song theo slice
    → một tệp lớn: chỉ một slice làm việc
        ↓
    Chia thành nhiều tệp bằng nhau
    → mọi slice cùng nạp
    → nhanh hơn nhiều lần

Ba lưu ý về giám sát cụm lớn: | Lưu ý | Chi tiết | |---|---| | Theo dõi tỷ lệ mất Spot | | | Xem Spark UI tìm giai đoạn nghẽn | | | Cảnh báo khi cụm chạy quá dự kiến | |

Ba lưu ý về EMR Serverless: | Lưu ý | Chi tiết | |---|---| | Không chọn số node hay loại máy | | | Trả tiền theo tài nguyên thật dùng | | | Đơn giản hơn cho việc chạy một lần | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy thử với dữ liệu nhỏ trước | | | Kiểm hạn ngạch và số IP trống | | | Xác nhận kết quả đã vào S3 trước khi tắt cụm | |

Và một lời khuyên: hãy kiểm tra hạn ngạch vCPU trước khi lên kế hoạch cho một cụm 200 máy. Đó là thứ chặn bạn ngay ở lệnh tạo cụm chứ không phải sau đó — và xin tăng hạn ngạch có thể mất vài ngày làm việc.

Đáp án

**A — Dùng AWS Systems Manager Patch Manager triển khai bản vá bảo mật hệ điều hành lên các EC2, và dùng AWS Config để quản lý, phát hiện và ghi lại trạng thái tuân thủ bảo mật của chúng.

Vì sao đúng

Đề nêu hai việc, và mỗi dịch vụ lo một việc: | Việc | Dịch vụ | |---|---| | Vá lỗ hổng càng sớm càng tốt | Patch Manager | | GHI LẠI mọi thay đổi bản vá và trạng thái tuân thủ | AWS Config |

⚠ Chữ "ghi lại" (record) là từ khoá quyết định:

Patch Manager có báo cáo tuân thủ
    → nhưng nó cho trạng thái HIỆN TẠI
        ↓
    Config ghi LỊCH SỬ cấu hình
    → "máy này đã tuân thủ từ ngày nào,
      đã vi phạm khoảng nào"
        ↓
    Đây là thứ kiểm toán cần

Tạo patch baseline:

aws ssm create-patch-baseline \
  --name baseline-khan-cap \
  --operating-system AMAZON_LINUX_2 \
  --approval-rules 'PatchRules=[{
    PatchFilterGroup={PatchFilters=[
      {Key=CLASSIFICATION,Values=[Security]},
      {Key=SEVERITY,Values=[Critical,Important]}]},
    ApproveAfterDays=0, ComplianceLevel=CRITICAL}]'

⚠ ApproveAfterDays=0 cho lỗ hổng đang bị khai thác:

Bình thường chờ 7 ngày để bản vá
  ổn định
        ↓
    Nhưng đề nói lỗ hổng ĐÃ BIẾT
      và cần vá NGAY
    → duyệt luôn, chấp nhận rủi ro
      bản vá có thể có vấn đề

Vá ngay bằng Run Command:

aws ssm send-command \
  --document-name "AWS-RunPatchBaseline" \
  --targets Key=tag:MoiTruong,Values=SanXuat \
  --parameters 'Operation=Install' \
  --max-concurrency "25%" --max-errors "5%"

⚠ max-concurrency và max-errors bảo vệ đội máy:

Vá 25% một lúc
    → hơn 5% lỗi thì DỪNG
        ↓
    Bản vá hỏng không hạ toàn bộ
      đội máy cùng lúc

Bật Config rule ghi nhận tuân thủ:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "tuan-thu-va-loi",
  "Source": {"Owner": "AWS",
    "SourceIdentifier": "EC2_MANAGEDINSTANCE_PATCH_COMPLIANCE_STATUS_CHECK"},
  "Scope": {"ComplianceResourceTypes":
    ["AWS::SSM::ManagedInstanceInventory"]}}'

⚠ Config ghi lịch sử, xem lại được theo thời gian:

aws configservice get-compliance-details-by-config-rule \
  --config-rule-name tuan-thu-va-loi \
  --compliance-types NON_COMPLIANT

"Ngày 15/8 có 12 máy chưa vá"
    → trả lời được câu hỏi này
    → Patch Manager một mình
      không trả lời được

Ba điều kiện tiên quyết của SSM — thiếu một là không chạy: | Điều kiện | Chi tiết | |---|---| | SSM Agent đang chạy | | | Instance profile có AmazonSSMManagedInstanceCore | | | Có đường tới endpoint SSM | Internet hoặc VPC endpoint |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Vá được ngay, không chờ cửa sổ bảo trì | | | Có lịch sử tuân thủ cho kiểm toán | | | Cả hai đều là dịch vụ quản lý | |

⚠ Và Config có thể TỰ SỬA:

aws configservice put-remediation-configurations \
  --remediation-configurations '[{
    "ConfigRuleName": "tuan-thu-va-loi",
    "TargetType": "SSM_DOCUMENT",
    "TargetId": "AWS-RunPatchBaseline",
    "Automatic": true,
    "MaximumAutomaticAttempts": 3}]'

Phát hiện máy chưa vá
    → tự chạy vá
        ↓
    Vòng khép kín: phát hiện → sửa → ghi nhận

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

• **D. Dùng State Manager bảo đảm bản vá được cài, và OpenSearch để ghi, theo dõi, trực quan hoá trạng thái vá — đây là phương án gần nhất và State Manager thật sự giữ cấu hình ở trạng thái mong muốn, nhưng Patch Manager mới là công cụ chuyên cho việc vá; và dựng cụm OpenSearch chỉ để xem trạng thái vá là nhiều việc hơn hẳn Config.
• **B. Tạo AMI mới tự cài bản vá hằng tuần rồi triển khai lại đội máy — hằng tuần là quá chậm cho một lỗ hổng đã biết; và AMI không tự cài gì, phải có pipeline dựng ảnh.
• **C. Dùng Amazon Control Tower triển khai bản vá và Managed Grafana trực quan hoá — Control Tower dựng và quản trị landing zone nhiều tài khoản, nó không triển khai bản vá.

Ghi nhớ

⚠ Sáu năng lực Systems Manager hay bị lẫn — bảng phải thuộc: | Năng lực | Việc | |---|---| | Patch Manager | vá hệ điều hành theo baseline | | State Manager | giữ cấu hình ở trạng thái mong muốn | | Run Command | chạy lệnh một lần trên nhiều máy | | Maintenance Windows | lịch chạy việc bảo trì | | Session Manager | mở shell không cần SSH | | Inventory | kiểm kê phần mềm đã cài |

Từ khoá nhận diện:

"patch operating systems" → Patch Manager "record compliance over time" → AWS Config "find vulnerabilities" → Amazon Inspector "keep configuration consistent" → State Manager

⚠ Ba dịch vụ trong chủ đề lỗ hổng:

Inspector: "máy này có lỗ hổng gì?"
    ↓
Patch Manager: "cài bản vá đi"
    ↓
Config: "máy này có tuân thủ không,
        từ bao giờ?"

Ba lưu ý về Inspector: | Lưu ý | Chi tiết | |---|---| | Quét liên tục, không phải theo lịch | | | Phủ EC2, ECR image, Lambda | | | Chỉ báo cáo, KHÔNG vá | |

Ba lưu ý về Config: | Lưu ý | Chi tiết | |---|---| | Phải bật recorder trước, không có dữ liệu quá khứ | | | Aggregator gộp nhiều tài khoản và Region | | | Conformance pack đóng gói nhiều quy tắc | |

⚠ "Không có dữ liệu quá khứ" là điều phải nhớ:

Sự cố xảy ra hôm nay
    → mới bật Config hôm nay
        ↓
    Không dựng lại được trạng thái
      tuần trước
    → bật Config là việc làm TRƯỚC

Ba lưu ý về patch group: | Lưu ý | Chi tiết | |---|---| | Gắn baseline theo tag Patch Group | | | Dev nhận bản vá trước sản xuất | | | Phát hiện bản vá hỏng ở nơi ít rủi ro | |

Ba lưu ý về VPC endpoint cho SSM: | Endpoint | Vai trò | |---|---| | ssm | kênh chính | | ssmmessages | Session Manager | | ec2messages | Run Command |

Ba lưu ý về vá an toàn: | Lưu ý | Chi tiết | |---|---| | Chụp ảnh EBS trước khi vá | | | Vá theo đợt | | | Kiểm thử ở môi trường thấp trước | |

Ba lưu ý về thay AMI thay vì vá tại chỗ: | Lưu ý | Chi tiết | |---|---| | EC2 Image Builder dựng AMI đã vá | | | Rolling update thay cả đội | | | Mọi máy giống hệt nhau | |

⚠ Đây là hướng tốt hơn cho hệ thống có ASG:

Vá tại chỗ: mỗi máy có lịch sử riêng
    → sau một năm không máy nào
      giống nhau
        ↓
    Thay AMI: luôn dựng lại được
      từ đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem báo cáo tuân thủ vá lỗi | | | Kiểm bản vá thật sự cài trên máy | | | Xem lịch sử tuân thủ trong Config | |

Và một lời khuyên: hãy bật AWS Config trước khi bạn cần tới nó. Nó không dựng lại được quá khứ — và câu hỏi "hệ thống đã ở trạng thái dễ tổn thương bao lâu" là câu mà kiểm toán viên luôn hỏi, còn bạn chỉ trả lời được nếu đã bật nó từ trước.

Đáp án

**B và C — Cấu hình network ACL chỉ mở đúng cổng cần thiết và dùng AWS WAF nhận diện, chặn các mẫu yêu cầu DDoS phổ biến; đồng thời luôn dùng security group chỉ cho phép cổng và máy chủ được uỷ quyền, đặt origin sau CloudFront, và bật AWS Shield Advanced để phát hiện và theo dõi tấn công ở tầng ứng dụng.

Vì sao đúng

Đề hỏi hai việc: giảm bề mặt tấn công và thu nhỏ bán kính ảnh hưởng, và hai đáp án lo cả hai: | Chiến lược | Cách làm | |---|---| | Giảm bề mặt | NACL và SG chỉ mở cổng cần, origin ẩn sau CloudFront | | Thu nhỏ bán kính | CloudFront phân tán tải, WAF lọc, Shield phát hiện |

⚠ Đây là hai khái niệm cốt lõi mà AWS dùng trong tài liệu chống DDoS:

Attack surface (bề mặt tấn công):
  bao nhiêu điểm có thể bị đánh
    → càng ít điểm lộ ra càng tốt
        ↓
    Blast radius (bán kính ảnh hưởng):
      một điểm bị đánh thì lan tới đâu
    → phân tán và cô lập

⚠ Đặt origin sau CloudFront là biện pháp giảm bề mặt lớn nhất:

Người tấn công không thấy IP thật
  của máy chủ
        ↓
    Lưu lượng tấn công đập vào
      mạng biên toàn cầu của AWS
    → phân tán qua hàng trăm điểm
    → thay vì tập trung vào một ALB

Nhưng phải chặn cả đường vòng:

aws ec2 describe-managed-prefix-lists \
  --filters Name=prefix-list-name,Values=com.amazonaws.global.cloudfront.origin-facing

Kẻ tấn công tìm ra IP của ALB
    → đánh thẳng, bỏ qua CloudFront
        ↓
    Security group chỉ nhận từ
      prefix list của CloudFront
    → cộng header bí mật + WAF

Luật WAF chống tấn công tầng 7:

aws wafv2 create-web-acl --name chong-flood \
  --scope CLOUDFRONT --default-action Allow={} \
  --rules '[
    {"Name":"GioiHanTanSuat","Priority":1,
     "Statement":{"RateBasedStatement":{
       "Limit":2000,"AggregateKeyType":"IP"}},
     "Action":{"Block":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"rate"}},
    {"Name":"MauXauDaBiet","Priority":2,
     "Statement":{"ManagedRuleGroupStatement":{
       "VendorName":"AWS",
       "Name":"AWSManagedRulesKnownBadInputsRuleSet"}},
     "OverrideAction":{"None":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"badinput"}}]'

⚠ Luật rate-based là thứ duy nhất chặn được HTTP flood:

Yêu cầu hoàn toàn hợp lệ, chỉ là
  quá nhiều
        ↓
    Không có mẫu tấn công nào để khớp
    → chỉ chặn được theo TẦN SUẤT

Bật Shield Advanced:

aws shield create-protection \
  --name bao-ve-phan-phoi \
  --resource-arn <arn-cloudfront>

aws shield associate-drt-role \
  --role-arn arn:aws:iam::111122223333:role/DRTRole

⚠ Shield Standard và Advanced — bảng phải thuộc: | Tính năng | Standard | Advanced | |---|---|---| | Chi phí | miễn phí, tự động | 3.000 USD/tháng | | Chống DDoS tầng 3/4 | có | có | | THÔNG BÁO khi bị tấn công | KHÔNG | CÓ | | Đội ứng cứu (SRT) | không | có | | Bảo vệ chi phí khi co giãn | không | có | | WAF đi kèm | không | có |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Nhiều lớp: mạng, biên, ứng dụng | | | Origin không lộ ra Internet | | | Có thông báo và có đội ứng cứu | |

⚠ Và bảo vệ chi phí là lợi ích tài chính đáng kể:

DDoS làm ASG mở rộng tối đa
  và truyền dữ liệu tăng vọt
        ↓
    Shield Advanced hoàn lại phần
      chi phí phát sinh do tấn công

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

• **D. Thêm ELB và Auto Scaling, dùng instance cực lớn để hấp thụ lưu lượng tấn công, và dùng Session Manager lọc phiên web — đây là phương án gần nhất và co giãn thật sự là một phần của chiến lược chống DDoS, nhưng "dùng máy to để chịu tấn công" là cách tốn tiền nhất; và Session Manager là công cụ mở shell, hoàn toàn không lọc lưu lượng web.
• **A. Bắt buộc MFA và dùng Fraud Detector, Config, Trusted Advisor — MFA bảo vệ tài khoản chứ không chống DDoS; Fraud Detector phát hiện gian lận giao dịch, không phải tấn công mạng.
• **E. Bật versioning trên S3 và vá hệ điều hành bằng Patch Manager — cả hai đều là thực hành tốt nhưng không liên quan gì tới DDoS.

Ghi nhớ

⚠ Bốn lớp phòng thủ DDoS — bảng phải thuộc: | Lớp | Dịch vụ | Chặn gì | |---|---|---| | DNS | Route 53 | tấn công tầng DNS | | Biên | CloudFront, Global Accelerator | hấp thụ và phân tán | | Tầng 3/4 | Shield | SYN flood, UDP reflection | | Tầng 7 | WAF | HTTP flood, SQLi, XSS |

Từ khoá nhận diện:

"reduce attack surface" → ẩn origin, đóng cổng thừa "minimise blast radius" → phân tán qua biên, cô lập tài nguyên "notification of layer 3/4 attacks" → Shield Advanced "block SQLi and XSS" → WAF

Ba nhóm luật WAF quản lý nên bật: | Nhóm | Chặn gì | |---|---| | AWSManagedRulesCommonRuleSet | OWASP phổ biến | | AWSManagedRulesKnownBadInputsRuleSet | payload đã biết là độc | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu |

⚠ Luôn chạy Count trước khi chuyển sang Block:

{"OverrideAction": {"Count": {}}}

Bật Block ngay
    → luật quản lý chặn nhầm
      lưu lượng hợp lệ
        ↓
    Chạy Count vài ngày, đọc log
    → rồi mới chặn thật

Ba nguyên tắc giảm bề mặt: | Nguyên tắc | Chi tiết | |---|---| | Chỉ mở cổng thật sự cần | | | Đặt tài nguyên trong subnet riêng tư | | | Không để origin lộ IP công khai | |

Ba lưu ý về Shield Advanced: | Lưu ý | Chi tiết | |---|---| | Cam kết 1 năm | | | Áp cho cả tổ chức nếu dùng Organizations | | | Cấp vai trò cho SRT TRƯỚC khi cần | |

⚠ Cấp vai trò SRT lúc bình thường:

Đang bị tấn công lúc 3 giờ sáng
    → mới đi làm giấy tờ uỷ quyền
        ↓
    Mất thời gian quý nhất
    → làm trước, mất năm phút

Ba lưu ý về co giãn để hấp thụ: | Lưu ý | Chi tiết | |---|---| | ASG với trần đủ cao | | | Nhưng đặt trần để tránh hoá đơn khổng lồ | | | Shield Advanced hoàn chi phí co giãn do DDoS | |

Ba lưu ý về NACL: | Lưu ý | Chi tiết | |---|---| | Stateless — phải mở cả hai chiều | | | Có deny, khác security group | | | Đánh số cách quãng để chèn được sau | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl thẳng vào IP của ALB — phải bị chặn | | | Gửi payload thử — WAF phải chặn | | | Kiểm chỉ số DDoSDetected và cảnh báo | |

Và một lời khuyên: hãy chặn đường đi thẳng vào origin ngay khi đặt CloudFront lên trước. Một CDN không giúp gì nếu kẻ tấn công vẫn tìm được và gọi thẳng vào ALB — và địa chỉ đó thường không khó tìm như người ta tưởng.