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

Đáp án

**B — Dùng DMS và SCT để chuyển đổi, di chuyển và tái kiến trúc IBM Db2 sang Amazon Aurora; dựng Auto Scaling group EC2 sau một ELB để chuyển và tái lưu trú IBM WebSphere; và chuyển IBM MQ sang Amazon MQ theo từng giai đoạn.

Vì sao đúng

Đề nêu ba hệ thống, và mỗi hệ thống có một chiến lược phù hợp: | Hệ thống | Chiến lược | Đích | |---|---|---| | IBM Db2 | refactor | Aurora | | IBM WebSphere | rehost | EC2 + ASG + ELB | | IBM MQ | replatform | Amazon MQ |

⚠ Amazon MQ là dịch vụ được thiết kế đúng cho việc thay IBM MQ:

Amazon MQ hỗ trợ ActiveMQ và
  RabbitMQ
    → nói các giao thức chuẩn:
      JMS, AMQP, MQTT, STOMP, OpenWire
        ↓
    IBM MQ cũng nói JMS và AMQP
    → ứng dụng gần như không phải
      sửa mã

⚠ Còn SQS đòi VIẾT LẠI ứng dụng:

SQS có API riêng của AWS
    → không nói JMS hay AMQP
        ↓
    Mọi chỗ dùng thư viện JMS
      phải viết lại
    → với ứng dụng doanh nghiệp cũ
      là dự án lớn

Đây là lý do phương án A và C sai.

⚠ Và "theo từng giai đoạn" là chi tiết quan trọng:

Chuyển hàng đợi một lần tất cả
    → rủi ro rất cao với hệ thống
      nhắn tin trung tâm
        ↓
    Chuyển từng hàng đợi một
    → kiểm chứng rồi mới sang cái tiếp
    → giữ được đường lui

Tạo broker Amazon MQ:

aws mq create-broker --broker-name broker-doanh-nghiep \
  --engine-type ACTIVEMQ --engine-version 5.18 \
  --host-instance-type mq.m5.large \
  --deployment-mode ACTIVE_STANDBY_MULTI_AZ \
  --publicly-accessible false \
  --subnet-ids subnet-a subnet-b \
  --users Username=quantri,Password=<mat-khau>

⚠ ACTIVE_STANDBY_MULTI_AZ là chế độ cho sẵn sàng cao: | Chế độ | Đặc điểm | |---|---| | SINGLE_INSTANCE | một broker, một AZ | | ACTIVE_STANDBY_MULTI_AZ | hai broker, tự chuyển đổi | | CLUSTER_MULTI_AZ | RabbitMQ, ba node |

Đề nói "cải thiện tính sẵn sàng"
    → phải chọn chế độ nhiều AZ

Chuyển Db2 sang Aurora:

aws dms create-replication-task \
  --replication-task-identifier chuyen-db2 \
  --migration-type full-load-and-cdc \
  --source-endpoint-arn <arn-db2> \
  --target-endpoint-arn <arn-aurora> \
  --replication-instance-arn <arn-instance> \
  --table-mappings file://anh-xa.json

⚠ SCT làm phần mà DMS không làm:

DMS: chuyển DỮ LIỆU
    → SCT: chuyển SCHEMA, stored
      procedure, trigger
        ↓
    Db2 sang Aurora là đổi engine
    → bắt buộc phải có SCT

⚠ Và SCT báo trước phần không tự chuyển được:

# SCT sinh báo cáo đánh giá
# → liệt kê object phải sửa tay
#   và ước tính công sức

Chạy đánh giá TRƯỚC khi cam kết
    → biết được bao nhiêu phần trăm
      chuyển tự động
    → và bao nhiêu phải viết lại

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mỗi hệ thống dùng chiến lược phù hợp nhất | | | Amazon MQ giữ nguyên giao thức, ít sửa mã | | | Aurora và Amazon MQ đều là dịch vụ quản lý | |

⚠ Và WebSphere trên EC2 là lựa chọn thực tế:

WebSphere là máy chủ ứng dụng
  Java EE thương mại
        ↓
    Không có dịch vụ AWS tương đương
    → chỉ rehost lên EC2
        ↓
    Về sau có thể refactor sang
      container hoặc Spring Boot

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

• **A. DMS và SCT chuyển Db2 sang Aurora, ASG EC2 cho WebSphere, nhưng chuyển IBM MQ sang SQS FIFO Queue — đây là phương án gần nhất và hai phần đầu hoàn toàn đúng, nhưng SQS có API riêng nên phải viết lại mọi chỗ dùng JMS; và SQS FIFO có trần thông lượng thấp hơn nhiều so với IBM MQ.
• **D. Dùng MGN chuyển máy chủ, tải giấy phép IBM lên License Manager, và chuyển IBM MQ sang Amazon MQ — giữ Db2 trên EC2 là bỏ lỡ cơ hội dùng dịch vụ quản lý; đề đòi "cải thiện tính sẵn sàng của hạ tầng".
• **C. Dùng MGN chuyển máy chủ, giữ WebSphere và Db2 trên EC2 riêng, chuyển IBM MQ sang SQS Standard — vừa giữ gánh nặng vận hành Db2, vừa phải viết lại tầng nhắn tin.

Ghi nhớ

⚠ Ba dịch vụ nhắn tin và trường hợp dùng — bảng phải thuộc: | Dịch vụ | Chọn khi | |---|---| | Amazon MQ | DI CHUYỂN ứng dụng cũ dùng JMS/AMQP | | SQS | thiết kế mới, hàng đợi đơn giản | | SNS | phát tán tới nhiều người nhận |

Từ khoá "migrate existing MQ"
    → Amazon MQ
        ↓
    Từ khoá "new application"
    → SQS

Từ khoá nhận diện:

"IBM MQ, JMS, AMQP" → Amazon MQ "convert database engine" → DMS + SCT "lift and shift servers" → MGN hoặc EC2 "phased migration" → chuyển từng phần, giữ đường lui

⚠ Bảy chiến lược 7R áp cho câu này: | Hệ thống | Chiến lược | |---|---| | Db2 → Aurora | Refactor (đổi engine) | | WebSphere → EC2 | Rehost | | IBM MQ → Amazon MQ | Replatform |

Ba lưu ý về Amazon MQ: | Lưu ý | Chi tiết | |---|---| | ActiveMQ hoặc RabbitMQ | | | Tính phí theo giờ broker và lưu trữ | | | Không co giãn vô hạn như SQS | |

⚠ Amazon MQ có trần thông lượng theo cỡ broker:

SQS: thông lượng gần như vô hạn
    → Amazon MQ: giới hạn theo
      loại instance broker
        ↓
    Ứng dụng cũ thường không cần
      thông lượng SQS
    → nhưng phải kiểm tra trước

Ba lưu ý về DMS: | Lưu ý | Chi tiết | |---|---| | Cần replication instance trong VPC | | | full-load-and-cdc cho ít gián đoạn | | | Nguồn phải bật ghi nhật ký thay đổi | |

Ba lưu ý về SCT: | Lưu ý | Chi tiết | |---|---| | Chạy báo cáo đánh giá TRƯỚC | | | Chuyển được phần lớn schema tự động | | | Stored procedure phức tạp phải sửa tay | |

⚠ Báo cáo đánh giá quyết định có nên refactor không:

SCT báo 95% chuyển tự động
    → refactor khả thi
        ↓
    SCT báo 40%, hàng trăm procedure
      phải viết lại
    → cân nhắc rehost Db2 lên EC2 trước
    → refactor sau khi ổn định

Ba lưu ý về WebSphere trên AWS: | Lưu ý | Chi tiết | |---|---| | Kiểm giấy phép IBM cho môi trường cloud | | | License Manager theo dõi số lõi dùng | | | Dedicated Host nếu giấy phép tính theo lõi vật lý | |

Ba lưu ý về di chuyển theo giai đoạn: | Lưu ý | Chi tiết | |---|---| | Chuyển hệ thống ít rủi ro trước | | | Giữ đường lui trong vài tuần | | | Di chuyển cả cụm phụ thuộc cùng lúc | |

⚠ Với hệ thống nhắn tin, chạy song song một thời gian:

IBM MQ và Amazon MQ cùng chạy
    → cầu nối chuyển thông điệp
      giữa hai bên
        ↓
    Chuyển từng ứng dụng sang
      Amazon MQ
    → tắt IBM MQ khi không ai
      còn dùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy báo cáo đánh giá SCT trước khi cam kết | | | Kiểm thử ứng dụng với Amazon MQ ở môi trường thử | | | Buộc chuyển đổi broker và bấm giờ | |

Và một lời khuyên: hãy chạy báo cáo đánh giá của SCT trước khi hứa hẹn thời gian cho việc chuyển Db2. Nó cho biết chính xác bao nhiêu phần trăm schema chuyển được tự động — và con số đó là khác biệt giữa một dự án vài tuần và một dự án vài quý.

Đáp án

**C — Gỡ quyền đọc công khai khỏi bucket S3; dùng CloudFront làm mạng phân phối nội dung cho ảnh và dùng signed URL có ngày hết hạn.

Vì sao đúng

Đề nêu hai vấn đề, và phương án này giải cả hai: | Vấn đề | Cách giải | |---|---| | Trang khác nhúng thẳng ảnh, mất doanh thu quảng cáo | signed URL có hạn | | Ảnh tải chậm | CloudFront cache ở biên |

⚠ Gỡ quyền công khai là bước bắt buộc đầu tiên:

Bucket còn công khai
    → dù đặt CloudFront lên trước
    → ai cũng gọi thẳng URL S3
        ↓
    Mọi biện pháp ở tầng CloudFront
      trở nên vô nghĩa

Chặn truy cập công khai:

aws s3api put-public-access-block --bucket kho-anh \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true

⚠ Và signed URL là thứ duy nhất chống được hotlinking triệt để:

Chặn theo IP (phương án A)
    → trang khác đổi IP là xong
    → và không chặn được người dùng
      của họ
        ↓
    Signed URL: mỗi link có chữ ký
      và hạn dùng
    → sao chép link sang trang khác
      thì vài phút sau link chết

Sinh signed URL:

from botocore.signers import CloudFrontSigner
import datetime, rsa

def ky(thong_diep):
    return rsa.sign(thong_diep, khoa_rieng, 'SHA-1')

nguoi_ky = CloudFrontSigner(MA_KHOA_CONG_KHAI, ky)
url = nguoi_ky.generate_presigned_url(
    'https://anh.congty.com/anh/12345.jpg',
    date_less_than=datetime.datetime.utcnow()
                   + datetime.timedelta(minutes=15))

⚠ Và chính sách tuỳ chỉnh giới hạn được cả IP:

{"Statement": [{
  "Resource": "https://anh.congty.com/anh/*",
  "Condition": {
    "DateLessThan": {"AWS:EpochTime": 1725062400},
    "IpAddress": {"AWS:SourceIp": "203.0.113.10/32"}}}]}

Link chỉ dùng được từ đúng IP
  của người xem
        ↓
    Sao chép sang nơi khác
    → không dùng được ngay lập tức

⚠ Bổ sung: kiểm tra header Referer ở tầng CloudFront:

function handler(su_kien) {
  var headers = su_kien.request.headers;
  var referer = headers.referer && headers.referer.value;
  if (!referer || referer.indexOf('congty.com') === -1) {
    return {statusCode: 403, statusDescription: 'Forbidden'};
  }
  return su_kien.request;
}

Chặn được phần lớn hotlinking
  đơn giản
        ↓
    Nhưng `Referer` giả được
    → chỉ là lớp bổ sung, không
      thay signed URL

Gắn OAC để bucket hoàn toàn riêng tư:

{"Effect": "Allow",
 "Principal": {"Service": "cloudfront.amazonaws.com"},
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::kho-anh/*",
 "Condition": {"StringEquals":
   {"AWS:SourceArn": "<arn-phan-phoi>"}}}

Bật signed URL cho cache behavior:

{"TrustedKeyGroups": {
  "Enabled": true, "Quantity": 1,
  "Items": ["<id-key-group>"]}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Link sao chép sang nơi khác tự chết | | | Ảnh phục vụ từ điểm gần người xem | | | Bucket hoàn toàn riêng tư | |

⚠ Nhưng signed URL làm giảm hiệu quả cache nếu làm sai:

Mỗi người dùng một URL khác nhau
  (chữ ký khác)
        ↓
    CloudFront tính cache key theo
      ĐƯỜNG DẪN, không tính chữ ký
    → vẫn trúng cache bình thường
        ↓
    Nhưng nếu đưa chữ ký vào
      query string và cache theo
      query string
    → cache vỡ vụn

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

• **A. Dùng CloudFront và chặn IP của các trang đang nhúng ảnh — đây là phương án gần nhất và có CloudFront đúng, nhưng chặn IP không hiệu quả: yêu cầu ảnh đến từ trình duyệt của người dùng cuối, không phải từ máy chủ của trang kia; chặn IP của họ không ảnh hưởng gì.
• **D. Chặn IP các trang vi phạm trong security group và dùng S3 Cross-Region Replication — security group không áp cho S3; và CRR là để nhân bản dữ liệu, không liên quan tới hotlinking.
• **B. Lưu ảnh trên EBS volume của máy chủ web với mã hoá — quay lại mô hình một máy chủ, mất khả năng co giãn và không giải quyết vấn đề nào trong hai vấn đề đề nêu.

Ghi nhớ

⚠ Ba cách hạn chế truy cập nội dung CloudFront — bảng phải thuộc: | Cách | Dùng khi | |---|---| | Signed URL | từng tệp riêng lẻ | | Signed cookie | nhiều tệp, không đổi URL được | | Geo restriction | chặn theo quốc gia |

Từ khoá nhận diện:

"third-party sites hotlinking" → signed URL + gỡ quyền công khai "only specific user can access" → signed URL "whole content library for subscribers" → signed cookie "prevent direct S3 access" → OAC + Block Public Access

⚠ Signed URL và signed cookie — chọn theo tình huống:

Trang ảnh có hàng chục ảnh mỗi trang
    → sinh hàng chục signed URL
        ↓
    Hoặc một signed cookie phủ
      cả tiền tố
    → trình duyệt tự gửi kèm mọi
      yêu cầu

Ba lưu ý về signed URL của CloudFront: | Lưu ý | Chi tiết | |---|---| | Cần key group và public key | | | Chính sách canned đơn giản, custom linh hoạt | | | Chỉ custom mới giới hạn được IP | |

aws cloudfront create-public-key --public-key-config \
  'CallerReference=k1,Name=khoa-ky,EncodedKey=<pem>'
aws cloudfront create-key-group --key-group-config \
  'Name=nhom-khoa,Items=[<id-khoa>]'

Ba lưu ý về thời hạn: | Lưu ý | Chi tiết | |---|---| | Đặt ngắn nhất mà trải nghiệm chịu được | | | Ảnh trong trang: vài phút là đủ | | | Không thu hồi được URL đã phát | |

⚠ Hạn ngắn là biện pháp chống hotlinking mạnh nhất:

Hạn 15 phút
    → trang khác sao chép link
    → 15 phút sau link chết
        ↓
    Họ phải tự động lấy link mới
      liên tục
    → chi phí và độ phức tạp đủ
      để họ bỏ cuộc

Ba lưu ý về OAC: | Lưu ý | Chi tiết | |---|---| | Thay thế OAI đã cũ | | | Hỗ trợ bucket mã hoá SSE-KMS | | | Bucket policy phải có AWS:SourceArn | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | TTL dài cho ảnh không đổi | | | Bật nén cho tệp có thể nén | | | Origin Shield nếu origin ở xa | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | Log CloudFront cho biết ai truy cập | | | Theo dõi tỷ lệ 403 (link hết hạn) | | | Phân tích Referer tìm trang nhúng lậu | |

SELECT referrer, COUNT(*) AS so_lan
FROM cloudfront_logs
WHERE uri LIKE '/anh/%'
  AND referrer NOT LIKE '%congty.com%'
GROUP BY referrer ORDER BY so_lan DESC LIMIT 20;

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | CloudFront rẻ hơn truyền thẳng từ S3 | | | Hotlinking là chi phí truyền dữ liệu thuần lỗ | | | Chặn nó tiết kiệm cả tiền lẫn doanh thu | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl URL S3 trực tiếp — phải 403 | | | Dùng lại một signed URL đã hết hạn — phải 403 | | | Đo tỷ lệ trúng cache sau khi bật signed URL | |

Và một lời khuyên: hãy đặt hạn signed URL ngắn hơn nhiều so với mức bạn nghĩ là cần. Với ảnh hiển thị trong trang, vài phút là đủ cho người xem thật — và đó chính là thứ khiến việc sao chép link sang trang khác trở nên vô ích.

Đáp án

**D — Tạo cụm ECS Fargate chạy container cho ứng dụng web; tạo Auto Scaling group EC2 Spot xử lý hàng đợi SQS; dùng Amazon Rekognition thay phần mềm bên thứ ba để phân tích và phân loại video; lưu video cùng nội dung tĩnh trên bucket S3.

Vì sao đúng

Đề nêu ba mục tiêu, và phương án này khớp từng cái: | Mục tiêu | Cách đáp ứng | |---|---| | Giảm chi phí | Fargate + Spot + S3 thay EBS | | Bỏ phụ thuộc phần mềm bên thứ ba | Rekognition | | Giảm công vận hành bằng dịch vụ quản lý | Fargate, S3, Rekognition |

⚠ Rekognition là dịch vụ AWS duy nhất phân tích và phân loại VIDEO:

Rekognition Video:
    `start-label-detection` — vật thể,
      cảnh, hoạt động
    `start-content-moderation` — nội
      dung không phù hợp
    `start-face-search` — người trong
      collection
        ↓
    Thay đúng việc mà phần mềm
      bên thứ ba đang làm

Phân tích video:

aws rekognition start-label-detection \
  --video '{"S3Object":{"Bucket":"kho-video","Name":"clip-01.mp4"}}' \
  --notification-channel '{"SNSTopicArn":"<arn>","RoleArn":"<arn>"}' \
  --min-confidence 80

⚠ Phân tích video là BẤT ĐỒNG BỘ — phải hiểu luồng:

`start-*` trả về JobId ngay
    → xử lý chạy nền
        ↓
    Xong thì đẩy thông báo vào SNS
    → Lambda gọi `get-*` lấy kết quả

⚠ Và EBS là nút thắt phải bỏ:

Video lưu trên EBS của từng instance
    → mỗi máy chỉ thấy video của nó
    → không chia sẻ được
        ↓
    Và EBS đắt hơn S3 nhiều lần
      cho khối lượng video
        ↓
    S3: mọi instance đọc chung,
      rẻ hơn, bền hơn

⚠ Spot rất hợp với việc xử lý hàng đợi:

Instance bị thu hồi giữa chừng
    → visibility timeout hết
    → thông điệp quay lại hàng đợi
        ↓
    Máy khác xử lý lại
    → không mất việc, chỉ chậm hơn
    → và rẻ hơn tới 90%

⚠ Nhưng tầng web KHÔNG nên dùng Spot:

Web server bị thu hồi
    → người dùng đang xem bị ngắt
        ↓
    Fargate cho tầng web: ổn định
    → Spot cho tầng xử lý nền:
      chịu được gián đoạn
        ↓
    Đây là lý do phương án D tách
      hai tầng dùng hai mô hình

⚠ Và Fargate phù hợp với "lưu lượng thay đổi":

Đề nói nội dung tĩnh có lưu lượng
  biến động
        ↓
    Fargate: co giãn theo task,
      không quản máy chủ nào
    → trả tiền theo vCPU và bộ nhớ
      thật dùng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không quản máy chủ cho tầng web | | | Spot giảm mạnh chi phí xử lý video | | | S3 rẻ hơn EBS rất nhiều cho video | |

⚠ Và S3 lifecycle giảm thêm chi phí:

{"Rules": [{
  "ID": "video-cu",
  "Status": "Enabled",
  "Transitions": [
    {"Days": 90, "StorageClass": "STANDARD_IA"},
    {"Days": 365, "StorageClass": "GLACIER_IR"}]}]}

⚠ Vì sao Beanstalk (phương án A) không phải "giảm công vận hành nhất":

Beanstalk vẫn dựng EC2 phía dưới
    → vẫn phải lo AMI, vá lỗi
      nền tảng
        ↓
    Fargate: không có instance nào
      để quản
    → ít việc hơn hẳn

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

• **A. Dùng Elastic Beanstalk cấp phát ASG cho cả web lẫn consumer SQS, dùng Rekognition, lưu trên S3 — đây là phương án gần nhất và có Rekognition cùng S3 đúng, nhưng Beanstalk vẫn quản lý EC2 phía dưới; và nó không tận dụng Spot cho tầng xử lý vốn chịu được gián đoạn.
• **B. Dựng trang web tĩnh trên S3 cho ứng dụng web, dùng S3 event và Lambda gọi Rekognition — ứng dụng cho phép người dùng tải lên và chia sẻ video nên cần logic phía máy chủ; trang tĩnh thuần không đủ.
• **C. Tạo EFS lưu video và nội dung tĩnh, mount lên mọi EC2 — EFS đắt hơn S3 nhiều lần cho khối lượng video, và không giải quyết việc bỏ phần mềm bên thứ ba (phương án này có Rekognition nhưng giữ EFS đắt đỏ và vẫn quản EC2).

Ghi nhớ

⚠ Ba dịch vụ AI cho media — bảng phải thuộc: | Dịch vụ | Vào | Ra | |---|---|---| | Rekognition | ảnh, video | vật thể, khuôn mặt, cảnh, kiểm duyệt | | Transcribe | âm thanh | văn bản | | Textract | tài liệu | văn bản, bảng, biểu mẫu |

Từ khoá nhận diện:

"analyse and categorise videos" → Rekognition "replace third-party software" → dịch vụ AI quản lý của AWS "reduce management overhead" → Fargate, S3, dịch vụ quản lý "queue processing, interruptible" → Spot

⚠ Ba mô hình chạy container — bảng phải thuộc: | Mô hình | Bạn quản | |---|---| | ECS trên EC2 | cụm EC2, AMI, vá lỗi | | ECS Fargate | chỉ task definition | | EKS Fargate | chỉ pod spec |

Ba lưu ý về Fargate: | Lưu ý | Chi tiết | |---|---| | Không quản máy chủ nào | | | Đắt hơn EC2 mỗi vCPU-giờ | | | Fargate Spot cho tải chịu gián đoạn | |

⚠ Fargate Spot là lựa chọn đáng biết:

aws ecs create-service --cluster cum-web \
  --service-name dich-vu-web \
  --capacity-provider-strategy \
    capacityProvider=FARGATE,weight=1,base=2 \
    capacityProvider=FARGATE_SPOT,weight=4

2 task luôn trên Fargate thường
    → phần co giãn dùng Fargate Spot
    → rẻ hơn tới 70%

Ba lưu ý về Spot cho hàng đợi: | Lưu ý | Chi tiết | |---|---| | Xử lý tín hiệu thu hồi 2 phút | | | Trả thông điệp về hàng đợi ngay | | | Đa dạng loại instance | |

def sap_bi_thu_hoi():
    r = requests.get(
        'http://169.254.169.254/latest/meta-data/spot/instance-action',
        timeout=1)
    return r.status_code == 200

Ba lưu ý về chi phí Rekognition: | Lưu ý | Chi tiết | |---|---| | Tính theo PHÚT video phân tích | | | Tính thử trên mẫu trước khi chạy hết | | | Chỉ bật tính năng thật sự cần | |

⚠ Với thư viện video lớn, chi phí này có thể là khoản lớn nhất:

Chạy thử vài chục giờ video
    → đo chi phí thực tế mỗi giờ
        ↓
    Nhân với tổng số giờ
    → có khi lớn hơn cả chi phí
      lưu trữ và tính toán cộng lại

Ba lưu ý về S3 cho video: | Lưu ý | Chi tiết | |---|---| | Multipart upload cho tệp lớn | | | Lifecycle dọn upload dở dang | | | CloudFront phục vụ video tới người xem | |

Ba lưu ý về SQS: | Lưu ý | Chi tiết | |---|---| | Visibility timeout dài hơn thời gian xử lý | | | Co giãn theo backlog per instance | | | Dead-letter queue cho video hỏng | |

Ba lưu ý về kiểm duyệt nội dung: | Lưu ý | Chi tiết | |---|---| | start-content-moderation phát hiện nội dung không phù hợp | | | Đặt ngưỡng độ tin cậy | | | Ca độ tin cậy thấp chuyển cho người xem | |

⚠ Với trang cho phép người dùng tải lên, kiểm duyệt là bắt buộc:

Không kiểm duyệt
    → nội dung vi phạm xuất hiện
      công khai
        ↓
    Rekognition kiểm duyệt tự động
    → và A2I cho ca khó

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So kết quả Rekognition với phần mềm cũ trên mẫu | | | Mô phỏng thu hồi Spot, xem có mất việc | | | Đo chi phí thật sau một tháng | |

Và một lời khuyên: hãy so kết quả của Rekognition với phần mềm bên thứ ba trên một mẫu thật trước khi thay hẳn. Chi phí và công vận hành đều giảm rõ ràng, nhưng chất lượng phân loại là thứ chỉ đo được bằng chính dữ liệu của bạn — và đó mới là điều người dùng nhận ra.

Đáp án

**D — Dùng một kết nối AWS Direct Connect cộng với một kết nối VPN quản lý để nối trung tâm dữ liệu với Amazon VPC.

Vì sao đúng

Đề nêu ba ràng buộc, và phương án này cân bằng cả ba: | Ràng buộc | Cách đáp ứng | |---|---| | Hiệu năng mạng ổn định | DX làm đường chính | | Vẫn có dự phòng | VPN làm đường phụ | | Rẻ hơn hai DX | VPN rẻ hơn DX rất nhiều |

⚠ Đây là mẫu dự phòng chuẩn được AWS khuyến nghị cho chi phí vừa phải:

Hai DX: dự phòng tốt nhất
    → nhưng phí cổng theo giờ
      nhân đôi
        ↓
    DX + VPN: giữ được hiệu năng
      khi bình thường
    → và không mất kết nối khi
      DX đứt

⚠ BGP tự chuyển đổi giữa hai đường:

AWS ưu tiên tuyến học được qua DX
  hơn tuyến qua VPN
        ↓
    DX còn sống: mọi lưu lượng
      đi qua DX
        ↓
    DX đứt: BGP rút tuyến
    → lưu lượng tự chuyển sang VPN
    → trong vài chục giây

Tạo VPN dự phòng:

aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --customer-gateway-id cgw-abc \
  --vpn-gateway-id vgw-abc \
  --options '{"StaticRoutesOnly": false}'

⚠ StaticRoutesOnly: false nghĩa là dùng BGP:

Tuyến tĩnh: phải sửa tay khi
  đường chính chết
        ↓
    BGP: tự phát hiện và chuyển
    → điều kiện để chuyển đổi
      tự động

⚠ Và điều khiển ưu tiên bằng AS path prepending:

Quảng bá cùng tiền tố qua cả
  DX và VPN
        ↓
    Thêm AS path prepending trên
      đường VPN
    → làm nó "kém hấp dẫn" hơn
    → lưu lượng ưu tiên DX

⚠ Và "tính năng chuyển đổi có sẵn" trong phương án A không tồn tại:

Một kết nối Direct Connect
    → là MỘT sợi cáp vật lý
        ↓
    Không có cơ chế chuyển đổi
      tự động nào bên trong nó
    → đứt là mất kết nối

⚠ Và VPN CloudHub (phương án B) giải quyết bài toán khác:

CloudHub: nối NHIỀU chi nhánh
  với nhau qua VGW
        ↓
    Đề chỉ có MỘT trung tâm dữ liệu
    → CloudHub không giải quyết
      vấn đề dự phòng

⚠ Và phương án C mô tả một cấu hình vô nghĩa:

"Hardware VPN dùng Direct Connect
  làm kết nối"
        ↓
    Chạy VPN QUA DX là kỹ thuật có
      thật (để mã hoá lưu lượng DX)
    → nhưng nó KHÔNG tạo ra dự phòng
    → DX đứt là cả hai cùng chết

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hiệu năng ổn định khi bình thường | | | Không mất kết nối khi DX đứt | | | Rẻ hơn nhiều so với hai DX | |

⚠ Nhưng phải chấp nhận băng thông giảm khi chuyển sang VPN:

DX 1 Gbps → VPN tối đa khoảng
  1,25 Gbps mỗi tunnel
        ↓
    Nhưng thực tế VPN qua Internet
      cho thông lượng thấp hơn nhiều
    → ứng dụng phải chịu được
      giai đoạn suy giảm

⚠ Và VPN phải được kiểm thử định kỳ:

VPN dựng xong rồi để đó
    → cấu hình lệch dần theo thời gian
        ↓
    Ngày DX đứt mới phát hiện VPN
      cũng không hoạt động
    → diễn tập chuyển đổi mỗi quý

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

• **C. Dựng Hardware VPN tại trung tâm dữ liệu và cho nó dùng Direct Connect làm kết nối — đây là phương án gần nhất và chạy VPN qua DX là kỹ thuật có thật (dùng để mã hoá lưu lượng DX), nhưng nó không tạo ra đường dự phòng nào: DX đứt thì cả VPN chạy trên đó cũng chết.
• **A. Dùng một Direct Connect và bật tính năng chuyển đổi có sẵn — không có tính năng chuyển đổi nào bên trong một kết nối DX đơn lẻ.
• **B. Dùng AWS VPN CloudHub nối trung tâm dữ liệu với VPC — CloudHub dành cho việc nối nhiều chi nhánh với nhau, không phải cơ chế dự phòng cho một địa điểm.

Ghi nhớ

⚠ Bốn mức dự phòng cho kết nối lai — bảng phải thuộc: | Mức | Cấu hình | Chi phí | |---|---|---| | Thấp nhất | một VPN | rất thấp | | Vừa | một DX + VPN dự phòng | vừa | | Cao | hai DX cùng vị trí | cao | | Cao nhất | hai DX ở hai vị trí | cao nhất |

Từ khoá nhận diện:

"predictable performance, cost-effective backup" → DX + VPN "maximum resiliency" → hai DX ở hai vị trí "connect multiple branch offices" → VPN CloudHub "encrypt Direct Connect traffic" → VPN qua DX, hoặc MACsec

⚠ Ba lý do chạy VPN qua Direct Connect:

1. Mã hoá — DX không mã hoá
   theo mặc định
        ↓
2. Yêu cầu tuân thủ đòi IPsec
        ↓
3. KHÔNG phải để dự phòng
   → vì cùng phụ thuộc một sợi cáp

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | Thời gian cung cấp tính bằng tuần | | | Phí cổng theo giờ dù không dùng | | | Một kết nối là một điểm hỏng | |

Ba lưu ý về VPN dự phòng: | Lưu ý | Chi tiết | |---|---| | Mỗi kết nối VPN có hai tunnel | | | Cấu hình CẢ HAI tunnel trên CGW | | | Dùng BGP để chuyển đổi tự động | |

⚠ Nhiều người chỉ cấu hình một tunnel:

Thiết bị CGW chỉ dựng tunnel 1
    → AWS bảo trì endpoint đó
        ↓
    Mất kết nối hoàn toàn
    → dù AWS đã cung cấp đường
      thứ hai

Ba lưu ý về BGP: | Lưu ý | Chi tiết | |---|---| | AWS ưu tiên DX hơn VPN mặc định | | | AS path prepending điều chỉnh ưu tiên | | | Local preference ở phía bạn | |

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | ConnectionState của DX | kết nối lên hay xuống | | TunnelState của VPN | tunnel nào đang hoạt động | | ConnectionBpsEgress | băng thông đang dùng |

aws cloudwatch put-metric-alarm \
  --alarm-name dx-xuong --namespace AWS/DX \
  --metric-name ConnectionState --statistic Minimum \
  --period 300 --threshold 1 \
  --comparison-operator LessThanThreshold \
  --dimensions Name=ConnectionId,Value=dxcon-abc

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | DX: phí cổng theo giờ + truyền dữ liệu | | | VPN: phí kết nối theo giờ, rẻ hơn nhiều | | | Truyền qua DX rẻ hơn qua Internet | |

Ba lưu ý về Transit Gateway: | Lưu ý | Chi tiết | |---|---| | Nhận cả DX (Transit VIF) lẫn VPN | | | Một điểm nối cho nhiều VPC | | | Đơn giản hoá định tuyến khi mở rộng | |

Ba lưu ý về diễn tập: | Lưu ý | Chi tiết | |---|---| | Ngắt DX thử mỗi quý | | | Đo thời gian chuyển đổi thật | | | Kiểm ứng dụng chịu được băng thông thấp hơn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm cả hai tunnel VPN đều UP | | | Ngắt DX, xem lưu lượng có chuyển sang VPN | | | Đo băng thông thật qua VPN khi chuyển | |

Và một lời khuyên: hãy diễn tập ngắt Direct Connect ít nhất mỗi quý. Đường VPN dự phòng dựng xong rồi để yên sẽ lặng lẽ lệch cấu hình theo thời gian — và ngày bạn phát hiện điều đó không nên là ngày sợi cáp bị cắt đứt.

Đáp án

**C — Triển khai trên BA vùng sẵn sàng với Auto Scaling group EC2 sau Application Load Balancer, và RDS cấu hình Multi-AZ.

Vì sao đúng

Đề đòi sẵn sàng cao 24/7 và chịu lỗi, và phương án này là phương án duy nhất đúng ở cả ba tầng: | Tầng | Lựa chọn | |---|---| | Cân bằng tải | ALB | | Tính toán | ASG trên ba AZ | | CSDL | Multi-AZ |

⚠ Read Replica KHÔNG phải cơ chế sẵn sàng cao — đây là điểm phân biệt: | Tiêu chí | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | CO GIÃN ĐỌC | | Nhân bản | đồng bộ, RPO = 0 | bất đồng bộ, có thể mất dữ liệu | | Chuyển đổi | TỰ ĐỘNG | thủ công, phải thăng cấp |

Đề đòi "chịu lỗi"
    → khi CSDL chính chết phải tự
      chuyển sang bản khác
        ↓
    Read Replica: phải có người
      thăng cấp bằng tay
    → không phải chịu lỗi

Đây là lý do phương án A và B sai.

⚠ Và "RDS chạy trên một Reserved EC2 Instance" là mô tả sai:

RDS là dịch vụ quản lý
    → bạn không chọn "chạy nó trên
      một EC2 instance"
        ↓
    Và "một instance" nghĩa là không
      có dự phòng nào

Đây là lý do phương án D sai.

Bật Multi-AZ:

aws rds create-db-instance \
  --db-instance-identifier csdl-sieu-thi \
  --db-instance-class db.r6g.large \
  --engine postgres --multi-az \
  --db-subnet-group-name nhom-3az \
  --backup-retention-period 7 \
  --storage-encrypted

⚠ Ba AZ rẻ hơn hai AZ ở cùng mức chịu lỗi:

2 AZ: mỗi AZ phải gánh 100% tải
    → tổng công suất 200%
        ↓
    3 AZ: mỗi AZ gánh 50%
    → tổng công suất 150%
    → tiết kiệm 25%

⚠ Và ba AZ cho khả năng chịu lỗi tốt hơn thật sự:

2 AZ, mất một cái
    → còn 50% công suất
    → phải chạy dư 100% để bù
        ↓
    3 AZ, mất một cái
    → còn 67% công suất
    → chỉ cần dư 50%

Cấu hình ASG:

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name asg-mua-sam \
  --min-size 6 --max-size 24 --desired-capacity 6 \
  --target-group-arns <arn-tg> \
  --health-check-type ELB --health-check-grace-period 300 \
  --vpc-zone-identifier "subnet-1a,subnet-1b,subnet-1c"

⚠ health-check-type ELB là cấu hình phải đổi:

Mặc định EC2: chỉ kiểm máy có
  chạy không
        ↓
    Ứng dụng chết mà máy vẫn sống
    → ASG không thay
        ↓
    ELB: dùng health check của
      target group
    → ứng dụng chết thì thay máy

⚠ Và ALB phải gắn đủ ba AZ:

aws elbv2 set-subnets --load-balancer-arn <arn> \
  --subnets subnet-1a subnet-1b subnet-1c

ASG tạo instance ở AZ-c
    → ALB chỉ gắn AZ-a và AZ-b
        ↓
    Instance ở AZ-c không nhận
      lưu lượng nào
    → và khả năng chịu lỗi kém hơn
      tính toán

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chịu được mất một AZ ở cả hai tầng | | | CSDL tự chuyển đổi, không mất dữ liệu | | | Ba AZ hiệu quả hơn hai về chi phí | |

⚠ Nhưng Multi-AZ không thay được read replica nếu tải đọc lớn:

Bản dự phòng Multi-AZ KHÔNG
  phục vụ đọc
        ↓
    Tải đọc lớn: thêm read replica
      SONG SONG với Multi-AZ
    → hai cơ chế cho hai mục đích

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

• **B. Ba AZ với ASG sau ALB, nhưng CSDL là một RDS instance với Read Replica ở hai AZ — đây là phương án gần nhất và phần tính toán hoàn toàn đúng, nhưng read replica là cơ chế co giãn đọc: instance chính chết thì phải thăng cấp thủ công, không phải chịu lỗi tự động.
• **A. Hai AZ với ASG (không nhắc load balancer) và RDS với Read Replica ở hai AZ — thiếu cân bằng tải, và read replica không cho chuyển đổi tự động.
• **D. Hai AZ với ASG sau ALB và RDS chạy trên một Reserved EC2 Instance — mô tả sai về RDS, và một instance nghĩa là không có dự phòng.

Ghi nhớ

⚠ Multi-AZ và Read Replica — bảng phải thuộc: | Tiêu chí | Multi-AZ | Read Replica | |---|---|---| | Mục đích | sẵn sàng cao | co giãn đọc | | Nhân bản | đồng bộ | bất đồng bộ | | Đọc từ bản kia | KHÔNG | có | | Chuyển đổi | tự động | thủ công | | Khác Region | không | có thể |

Từ khoá nhận diện:

"highly available and fault tolerant" → nhiều AZ + Multi-AZ "scale read traffic" → read replica "survive Region failure" → cross-region replica hoặc Aurora Global "recover from accidental deletion" → PITR |

⚠ Multi-AZ KHÔNG bảo vệ khỏi ba thứ:

1. Xoá nhầm dữ liệu
   → nhân bản đồng bộ sang bản
     dự phòng ngay
        ↓
2. Mất cả Region
        ↓
3. Lỗi logic của ứng dụng

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Chuyển đổi 60-120 giây | | | CNAME đổi, IP đổi theo | | | Ứng dụng phải làm mới cache DNS | |

⚠ Cache DNS là chỗ ứng dụng hay hỏng:

java.security.Security.setProperty(
    "networkaddress.cache.ttl", "60");

JVM cache DNS vĩnh viễn mặc định
    → chuyển đổi xong, CNAME đã đổi
    → ứng dụng vẫn nối vào IP cũ

Ba lưu ý về Multi-AZ DB cluster: | Tiêu chí | Instance | DB cluster | |---|---|---| | Số bản | 1 chính + 1 dự phòng | 1 writer + 2 reader | | Đọc từ bản phụ | không | CÓ | | Chuyển đổi | 60-120 giây | dưới 35 giây |

Ba lưu ý về ASG nhiều AZ: | Lưu ý | Chi tiết | |---|---| | ALB phải gắn đủ AZ mà ASG dùng | | | ASG tự cân bằng số instance giữa các AZ | | | Ít nhất ba AZ cho hệ thống quan trọng | |

Ba lưu ý về ứng dụng stateless: | Lưu ý | Chi tiết | |---|---| | Phiên nằm ngoài instance | | | Giỏ hàng lưu trong DynamoDB hoặc ElastiCache | | | Thu hồi máy bất kỳ lúc nào không ai nhận ra | |

⚠ Với trang mua sắm, giỏ hàng là trạng thái quan trọng nhất:

Giỏ hàng trong bộ nhớ instance
    → ASG thu hồi máy
    → khách mất giỏ hàng
        ↓
    Lưu trong DynamoDB với TTL
    → sống sót qua mọi lần thay máy

Ba lưu ý về giám sát: | Chỉ số | Cảnh báo khi | |---|---| | HealthyHostCount theo TỪNG AZ | giảm bất thường | | TargetResponseTime | p99 tăng | | DatabaseConnections | gần trần |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Buộc chuyển đổi Multi-AZ và bấm giờ | | | Mô phỏng mất một AZ bằng FIS | | | So AZ của ALB với AZ của ASG | |

Và một lời khuyên: hãy buộc chuyển đổi RDS Multi-AZ một lần ở môi trường thật trước khi tin rằng nó hoạt động. Phần AWS lo luôn chạy đúng — thứ hỏng gần như luôn là ứng dụng, vốn đang giữ chặt một địa chỉ IP đã không còn tồn tại.

Đáp án

**A — Dựng kết nối IPSec VPN bằng OpenVPN hoặc VPN/VGW qua dịch vụ VPC; chuẩn bị một instance MySQL bên ngoài Amazon RDS; cấu hình instance RDS làm nguồn nhân bản; dùng mysqldump chuyển CSDL từ RDS sang MySQL tại chỗ rồi khởi động nhân bản từ Read Replica của RDS.

Vì sao đúng

Đề nêu hai yêu cầu, và phương án này là phương án duy nhất đúng về mặt kỹ thuật: | Yêu cầu | Cách đáp ứng | |---|---| | Nhân bản RDS MySQL ra máy chủ tại chỗ | RDS hỗ trợ nhân bản ra ngoài | | An toàn nhất | VPN mã hoá, không đi Internet công cộng |

⚠ RDS MySQL THẬT SỰ nhân bản ra máy chủ ngoài được:

RDS MySQL và MariaDB hỗ trợ
  nhân bản ra instance bên ngoài
        ↓
    Dùng thủ tục `mysql.rds_set_external_master`
      và `mysql.rds_start_replication`
        ↓
    Đây là lý do phương án B sai
    → nó khẳng định "RDS không nhân bản
      ra máy chủ tại chỗ được"

Bật ghi nhật ký nhị phân trên RDS:

CALL mysql.rds_set_configuration('binlog retention hours', 24);

⚠ Giữ binlog đủ lâu là điều kiện bắt buộc:

RDS xoá binlog rất nhanh theo
  mặc định
        ↓
    Chưa kịp chuyển dump và bắt đầu
      nhân bản thì binlog đã mất
    → phải làm lại từ đầu

Chụp và chuyển dữ liệu:

mysqldump -h csdl.abc.ap-southeast-1.rds.amazonaws.com \
  -u quantri -p --databases phan_tich \
  --single-transaction --master-data=2 \
  > kho.sql

⚠ --master-data=2 ghi vị trí binlog vào tệp dump:

Không có nó: không biết bắt đầu
  nhân bản từ đâu
        ↓
    Có: tệp dump chứa dòng ghi chú
      với tên tệp binlog và vị trí
    → dùng đúng giá trị đó để
      khởi động nhân bản

Khởi động nhân bản trên máy chủ tại chỗ:

CHANGE MASTER TO
  MASTER_HOST='csdl.abc.ap-southeast-1.rds.amazonaws.com',
  MASTER_USER='nguoi_nhan_ban',
  MASTER_PASSWORD='<mat-khau>',
  MASTER_LOG_FILE='mysql-bin-changelog.000123',
  MASTER_LOG_POS=456,
  MASTER_SSL=1;
START SLAVE;

⚠ MASTER_SSL=1 mã hoá cả kênh nhân bản:

VPN đã mã hoá ở tầng mạng
    → thêm SSL ở tầng MySQL
    → hai lớp độc lập
        ↓
    Đây là điều làm phương án này
      "an toàn nhất"

⚠ Và nhân bản từ READ REPLICA chứ không phải instance chính:

Nhân bản trực tiếp từ instance chính
    → thêm tải cho CSDL sản xuất
        ↓
    Từ read replica: instance chính
      không bị ảnh hưởng
    → và đây chính là điều đáp án
      mô tả

⚠ Vì sao KHÔNG dùng Internet công cộng (phương án C):

Nhân bản MySQL qua Internet
    → dù có SSL vẫn lộ endpoint
      CSDL ra ngoài
        ↓
    Bề mặt tấn công lớn hơn hẳn
    → VPN giữ mọi thứ trong mạng riêng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Nhân bản liên tục, gần thời gian thực | | | Không lộ CSDL ra Internet | | | Instance chính không chịu thêm tải | |

⚠ Nhưng đây là cách CŨ — DMS là công cụ hiện đại:

aws dms create-replication-task \
  --replication-task-identifier nhan-ban-tai-cho \
  --migration-type full-load-and-cdc \
  --source-endpoint-arn <arn-rds> \
  --target-endpoint-arn <arn-mysql-tai-cho> \
  --replication-instance-arn <arn-instance>

DMS làm cả full load lẫn CDC
    → không phải tự chạy mysqldump
    → không phải tự quản vị trí binlog
        ↓
    Có giám sát và cảnh báo sẵn
    → và xử lý được cả trường hợp
      nhân bản đứt

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

• **C. Cấu hình RDS làm master và bật nhân bản qua Internet công cộng với endpoint SSL, dùng mysqldump chuyển từ Amazon S3 — đây là phương án gần nhất và nhân bản có SSL là hợp lệ, nhưng đi qua Internet công cộng kém an toàn hơn VPN; và câu "chuyển từ S3" mâu thuẫn với việc dump lấy từ RDS.
• **B. Khẳng định RDS không nhân bản ra máy chủ tại chỗ được nên phải nhân bản sang EC2 rồi từ đó qua VPN — tiền đề sai: RDS MySQL nhân bản ra ngoài được; và thêm một chặng EC2 là phức tạp không cần thiết.
• **D. Dùng Data Pipeline xuất dữ liệu mỗi đêm và tải về qua endpoint HTTPS của S3 — đây là sao chép theo lô hằng đêm, không phải nhân bản; ứng dụng phân tích sẽ luôn đọc dữ liệu cũ tới một ngày.

Ghi nhớ

⚠ Ba cách đưa dữ liệu RDS ra ngoài AWS — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Nhân bản MySQL gốc | liên tục, tự quản lý | | DMS với CDC | liên tục, dịch vụ quản lý | | Xuất theo lô (dump, snapshot) | định kỳ, dữ liệu cũ |

Từ khoá nhận diện:

"replicate RDS to on-premises" → nhân bản gốc hoặc DMS "most secure" → VPN hoặc Direct Connect, không dùng Internet "read-only endpoint for analytics" → replica "nightly export" → theo lô, không phải nhân bản

Ba lưu ý về nhân bản RDS ra ngoài: | Lưu ý | Chi tiết | |---|---| | Hỗ trợ MySQL và MariaDB | | | Phải bật và giữ binlog đủ lâu | | | Dùng thủ tục mysql.rds_* | |

⚠ Kiểm tra trạng thái nhân bản:

SHOW SLAVE STATUS\G

`Seconds_Behind_Master` cho biết
  độ trễ
        ↓
    Tăng đều đặn → nhân bản không
      theo kịp
    → hoặc đường mạng nghẽn

Ba lưu ý về DMS: | Lưu ý | Chi tiết | |---|---| | Cần replication instance trong VPC | | | full-load-and-cdc làm cả hai việc | | | Có chỉ số và cảnh báo sẵn | |

Ba lưu ý về kết nối an toàn: | Cách | Đặc điểm | |---|---| | Site-to-Site VPN | mã hoá, nhanh dựng, qua Internet | | Direct Connect | đường riêng, KHÔNG mã hoá mặc định | | DX + VPN | cả hai ưu điểm |

⚠ Direct Connect không mã hoá — hiểu nhầm phổ biến:

"Đường riêng nên an toàn"
    → riêng về định tuyến
    → dữ liệu ở dạng RÕ
        ↓
    Yêu cầu bảo mật cao
    → chạy VPN qua DX, hoặc MACsec

Ba lưu ý về bảo mật kênh nhân bản: | Lưu ý | Chi tiết | |---|---| | Bật MASTER_SSL=1 | | | Người dùng nhân bản chỉ có quyền REPLICATION SLAVE | | | Security group chỉ cho IP của máy chủ tại chỗ | |

CREATE USER 'nguoi_nhan_ban'@'%'
  IDENTIFIED BY '<mat-khau>' REQUIRE SSL;
GRANT REPLICATION SLAVE ON *.* TO 'nguoi_nhan_ban'@'%';

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | Seconds_Behind_Master | độ trễ nhân bản | | BinLogDiskUsage của RDS | binlog có tích tụ không | | Trạng thái VPN tunnel | kênh còn thông không |

⚠ Binlog tích tụ có thể làm đầy đĩa RDS:

Máy chủ tại chỗ ngừng đọc binlog
    → RDS giữ lại theo cấu hình
      retention
        ↓
    Giữ quá lâu: đĩa RDS đầy
    → cảnh báo trên `BinLogDiskUsage`

Ba lưu ý về xử lý khi nhân bản đứt: | Lưu ý | Chi tiết | |---|---| | Binlog còn thì START SLAVE là tiếp tục | | | Binlog đã mất thì phải dump lại | | | DMS xử lý việc này tốt hơn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi một bản ghi vào RDS, xem có sang tại chỗ | | | Đo Seconds_Behind_Master khi tải cao | | | Ngắt VPN thử, xem nhân bản có tự nối lại | |

Và một lời khuyên: hãy cân nhắc DMS thay vì tự quản lý nhân bản MySQL gốc. Cách gốc hoạt động tốt cho tới khi nhân bản đứt vào ban đêm và binlog đã bị xoá — lúc đó bạn phải dump lại toàn bộ CSDL, còn DMS thì tự xử lý phần lớn những tình huống như vậy.

Đáp án

**B — Dùng Amazon WorkDocs làm nơi lưu tài liệu, tận dụng sẵn tính năng quản lý quyền người dùng, quản lý phiên bản và mã hoá tích hợp; tích hợp WorkDocs Content Manager với các ứng dụng bên ngoài; và xây tính năng quay lui bằng cách thay phiên bản hiện tại bằng phiên bản trước từ WorkDocs.

Vì sao đúng

Đề nêu bốn yêu cầu, và WorkDocs có sẵn ba trong bốn: | Yêu cầu | WorkDocs | |---|---| | Tải lên tài liệu | có sẵn | | Tải về phiên bản cụ thể hoặc mới nhất | quản lý phiên bản có sẵn | | Quản lý quyền người dùng | có sẵn | | Truy cập qua API | Content Manager SDK |

⚠ Điểm phân biệt với S3: WorkDocs quản lý PHIÊN BẢN theo cách người dùng hiểu:

S3 versioning: mỗi phiên bản một
  Version ID ngẫu nhiên
        ↓
    Ứng dụng phải tự quản danh sách,
      tự xây giao diện chọn phiên bản
        ↓
    WorkDocs: phiên bản là khái niệm
      cấp một
    → API trả về danh sách có
      thứ tự và metadata

⚠ Và quản lý quyền là phần WorkDocs tiết kiệm nhiều công nhất:

S3 (phương án A, C): phải tạo IAM
  role cho TỪNG ứng dụng khách hàng
        ↓
    Số khách hàng tăng
    → số vai trò tăng theo
    → và phải tự quản việc gán quyền
        ↓
    WorkDocs: quyền theo người dùng
      và thư mục, có sẵn

⚠ Và phương án A, C có một lỗ hổng nghiêm trọng:

"Chia sẻ khoá mã hoá cho mọi
  khách hàng để mở tài liệu"
        ↓
    Một khoá chung cho tất cả
    → khách hàng A giải mã được
      tài liệu của khách hàng B
        ↓
    Đây là lỗi thiết kế bảo mật
      cơ bản

Tải lên qua API:

import boto3
workdocs = boto3.client('workdocs')

kq = workdocs.initiate_document_version_upload(
    ParentFolderId=ma_thu_muc,
    Name='hop-dong.pdf',
    ContentType='application/pdf')

# tai len bang URL da ky trong ket qua
requests.put(kq['UploadMetadata']['UploadUrl'],
             data=noi_dung,
             headers=kq['UploadMetadata']['SignedHeaders'])

workdocs.update_document_version(
    DocumentId=kq['Metadata']['Id'],
    VersionId=kq['Metadata']['LatestVersionMetadata']['Id'],
    VersionStatus='ACTIVE')

⚠ Bước update_document_version với ACTIVE là bắt buộc:

Tải lên xong nhưng chưa kích hoạt
    → phiên bản ở trạng thái nháp
    → không ai thấy được
        ↓
    Quên bước này là tài liệu
      "biến mất"

Lấy danh sách phiên bản:

ds = workdocs.describe_document_versions(
    DocumentId=ma_tai_lieu, Include='SOURCE')
for pb in ds['DocumentVersions']:
    print(pb['Id'], pb['CreatedTimestamp'], pb['Status'])

Quay lui về phiên bản cũ:

# tai noi dung phien ban cu
url_cu = workdocs.get_document_version(
    DocumentId=ma, VersionId=ma_pb_cu,
    Fields='SOURCE')['Metadata']['Source']['ORIGINAL']
noi_dung = requests.get(url_cu).content
# tai len lai lam phien ban moi

⚠ Quay lui bằng cách TẢI LÊN LẠI, không phải xoá:

Xoá phiên bản mới
    → mất lịch sử
        ↓
    Tải nội dung cũ lên làm phiên
      bản mới
    → giữ nguyên toàn bộ dấu vết
    → và quay lui được lần nữa

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không phải xây tầng quản lý quyền | | | Phiên bản là khái niệm sẵn có | | | Mã hoá và ghi nhật ký tích hợp | |

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

⚠ Amazon WorkDocs đã ngừng nhận khách hàng mới.

AWS công bố ngừng WorkDocs từ tháng 4/2024; khách hàng đang dùng được hỗ trợ tới hết thời hạn hợp đồng, nhưng không mở tài khoản mới được nữa.

Với hệ thống thiết kế hôm nay
    → WorkDocs không phải lựa chọn
        ↓
    Đáp án vẫn đúng trong phạm vi
      bốn phương án của đề
    → nhưng không dùng được
      trong thực tế

Các lựa chọn thay thế hiện nay: | Nhu cầu | Dịch vụ | |---|---| | Lưu tài liệu có phiên bản | S3 với versioning | | Quản lý quyền người dùng | Cognito + IAM, hoặc Identity Center | | Chia sẻ tệp doanh nghiệp | FSx for Windows, hoặc SaaS bên ngoài | | Nội dung có API | S3 + API Gateway + Lambda |

⚠ Và xây trên S3 ngày nay đơn giản hơn nhiều so với thời câu hỏi này ra đời:

S3 versioning + pre-signed URL
    + Cognito cho danh tính
    + bucket policy theo tiền tố
      từng khách hàng
        ↓
    Không cần chia sẻ khoá chung
      cho ai
    → và mỗi khách hàng chỉ thấy
      thư mục của mình

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

• **A. Dùng S3 với versioning và server access logging, tạo IAM role cho từng ứng dụng khách hàng, mã hoá phía client và chia sẻ khoá mã hoá cho mọi khách hàng — đây là phương án gần nhất và S3 versioning thật sự đáp ứng yêu cầu phiên bản, nhưng chia sẻ một khoá chung cho mọi khách hàng là lỗ hổng: ai cũng giải mã được tài liệu của người khác.
• **C. Dùng S3 với access logging, IAM role cho từng ứng dụng, và chia sẻ KMS Key ID cùng client-side master key cho tất cả khách hàng — cùng lỗ hổng khoá chung, và thiếu hẳn tính năng phiên bản.
• **D. Dùng Amazon EFS làm kho object, KMS lưu khoá riêng từng khách hàng, dùng file locking và file versioning của EFS — EFS là hệ thống tệp NFS, không có tính năng versioning; và nó không phải kho object có API như đề mô tả.

Ghi nhớ

⚠ Bốn cách lưu tài liệu có phiên bản trên AWS — bảng phải thuộc: | Cách | Phiên bản | |---|---| | S3 versioning | CÓ, Version ID ngẫu nhiên | | EFS | KHÔNG | | FSx for Windows | shadow copy, không phải versioning API | | WorkDocs | có (đã ngừng nhận khách mới) |

Từ khoá nhận diện:

"download specific version" → S3 versioning hoặc WorkDocs "roll back to previous version" → cùng cơ chế "per-customer isolation" → tiền tố riêng + IAM condition "shared encryption key for all" → SAI, lỗ hổng bảo mật

⚠ Cô lập khách hàng đúng cách trên S3:

{"Effect": "Allow",
 "Action": ["s3:GetObject", "s3:PutObject"],
 "Resource": "arn:aws:s3:::tai-lieu/${aws:PrincipalTag/MaKhachHang}/*"}

Mỗi khách hàng một tiền tố
    → thẻ phiên xác định họ là ai
        ↓
    MỘT chính sách cho mọi khách hàng
    → và không ai chạm được thư mục
      của người khác

Ba lưu ý về S3 versioning: | Lưu ý | Chi tiết | |---|---| | Bật rồi chỉ tạm dừng được, không tắt hẳn | | | Mọi phiên bản đều tính tiền | | | Lifecycle dọn phiên bản cũ | |

{"Rules": [{
  "ID": "don-phien-ban-cu",
  "Status": "Enabled", "Filter": {},
  "NoncurrentVersionExpiration": {"NoncurrentDays": 365},
  "Expiration": {"ExpiredObjectDeleteMarker": true}}]}

Ba lưu ý về mã hoá: | Cách | Ai giữ khoá | |---|---| | SSE-KMS | KMS, một khoá cho mỗi khách hàng được | | SSE-C | client gửi mỗi request | | Client-side | client mã hoá trước khi gửi |

⚠ Một khoá KMS cho mỗi khách hàng là cách đúng:

Khoá riêng từng khách hàng
    → key policy chỉ cho họ dùng
        ↓
    Rò rỉ một khoá chỉ ảnh hưởng
      một khách hàng
    → và thu hồi được độc lập

Ba lưu ý về API cho ứng dụng khách hàng: | Lưu ý | Chi tiết | |---|---| | API Gateway + Lambda cho tầng API | | | Pre-signed URL cho tải lên và tải về | | | Cognito hoặc IAM cho xác thực | |

Ba lưu ý về ghi nhật ký: | Lưu ý | Chi tiết | |---|---| | CloudTrail data event cho thao tác object | | | S3 server access log cho chi tiết HTTP | | | Giữ log ở tài khoản riêng | |

Ba lưu ý về Object Lock: | Lưu ý | Chi tiết | |---|---| | Chỉ bật được khi TẠO bucket | | | Chế độ compliance không ai gỡ được | | | Hữu ích cho tài liệu chịu quy định | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải lên hai phiên bản, tải về từng cái | | | Thử truy cập thư mục của khách hàng khác | | | Quay lui một tài liệu và kiểm lịch sử còn nguyên | |

Và một lời khuyên: hãy cấp cho mỗi khách hàng một khoá mã hoá riêng thay vì một khoá dùng chung. Khoá chung nghĩa là rò rỉ một khoá là rò rỉ mọi tài liệu của mọi khách hàng — và đó là loại sự cố không có cách nào khoanh vùng lại được.

Đáp án

**C — Cấu hình Redshift có ảnh chụp tự động và bật sao chép ảnh chụp xuyên Region để tự động nhân bản cụm sản xuất sang Region dự phòng.

Vì sao đúng

Đề cho hai con số, và phương án này khớp cả hai: | Chỉ tiêu | Yêu cầu | Cách đáp ứng | |---|---|---| | RPO | 24 giờ | ảnh chụp tự động mỗi 8 giờ | | RTO | 1 giờ | khôi phục từ ảnh chụp đã có sẵn ở Region đích | | Chịu được mất cả Region | | bản sao ở Region khác |

⚠ Redshift chụp ảnh tự động mỗi 8 giờ hoặc mỗi 5 GB thay đổi:

RPO tệ nhất: 8 giờ
    → cộng thời gian sao chép
      xuyên Region
        ↓
    Vẫn nằm trong yêu cầu 24 giờ
    → với biên an toàn rộng

Bật sao chép xuyên Region:

aws redshift enable-snapshot-copy \
  --cluster-identifier cum-kho-du-lieu \
  --destination-region us-west-2 \
  --retention-period 30

⚠ Với cụm ĐÃ MÃ HOÁ cần thêm snapshot copy grant:

aws redshift create-snapshot-copy-grant \
  --snapshot-copy-grant-name grant-dr \
  --kms-key-id <arn-khoa-region-dich> \
  --region us-west-2

aws redshift enable-snapshot-copy \
  --cluster-identifier cum-kho-du-lieu \
  --destination-region us-west-2 \
  --snapshot-copy-grant-name grant-dr

⚠ Và Redshift KHÔNG có nhân bản cụm-sang-cụm:

Không có tính năng nào kiểu
  "Redshift replication"
        ↓
    Cơ chế DR duy nhất là sao chép
      ẢNH CHỤP
    → rồi khôi phục thành cụm mới

Đây là lý do phương án D sai — nó mô tả một tính năng không tồn tại.

⚠ Và Redshift không có "Cross-Region Replication" như S3:

CRR là tính năng của S3
    → Redshift dùng thuật ngữ
      "cross-region snapshot copy"
        ↓
    Và phương án B nói "khi sự cố
      thì CHÉP TAY ảnh chụp sang"
    → chép hàng TB xuyên Region
      lúc đó thì không kịp RTO 1 giờ

Khôi phục ở Region đích:

aws redshift restore-from-cluster-snapshot \
  --cluster-identifier cum-dr \
  --snapshot-identifier <id-anh-chup> \
  --region us-west-2

⚠ Nhưng phải đo thời gian khôi phục thật:

Cụm vài TB: có thể mất hàng giờ
        ↓
    RTO 1 giờ là con số chặt
    → phải đo thử để biết cụm của
      mình có đạt không
        ↓
    Không đạt: phải giữ một cụm
      nhỏ chạy sẵn ở Region đích

⚠ Và Redshift cho truy vấn ngay khi khôi phục chưa xong:

Cụm khôi phục từ ảnh chụp
    → nhận truy vấn được ngay
    → dữ liệu nạp lười từ S3
        ↓
    Vài truy vấn đầu chậm hơn
    → nhưng dịch vụ đã sẵn sàng
    → đây là điều giúp đạt RTO

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Redshift tự sao chép, không phải viết mã | | | Không chạy cụm dự phòng thường trực | | | Đáp ứng cả RPO 24 giờ lẫn RTO 1 giờ | |

⚠ Và phương án A sai ở tiền đề:

"Redshift đã có ảnh chụp tự động
  mặc định nên không cần làm gì"
        ↓
    Ảnh chụp tự động nằm CÙNG Region
      với cụm
    → mất Region là mất luôn
      ảnh chụp
        ↓
    Phải bật sao chép xuyên Region
      tường minh

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

• **B. Cấu hình Redshift dùng Cross-Region Replication và khi có sự cố thì chép tay ảnh chụp sang Region dự phòng — đây là phương án gần nhất và nhắc đúng ý tưởng sao chép xuyên Region, nhưng Redshift không có tính năng tên "CRR"; và chép tay hàng TB lúc sự cố thì không kịp RTO 1 giờ.
• **D. Bật nhân bản Redshift từ cụm chính sang cụm phụ và đổi DNS endpoint khi sự cố — Redshift không có nhân bản cụm-sang-cụm.
• **A. Không cần cấu hình gì vì Redshift đã có ảnh chụp tự động — ảnh chụp tự động nằm cùng Region, không giúp gì khi mất cả Region.

Ghi nhớ

⚠ Ba loại ảnh chụp của Redshift — bảng phải thuộc: | Loại | Đặc điểm | |---|---| | Tự động | mỗi 8 giờ hoặc 5 GB, giữ theo cấu hình | | Thủ công | giữ tới khi bạn xoá | | Sao chép xuyên Region | bản sao ở Region khác |

Từ khoá nhận diện:

"survive Region failure, Redshift" → cross-region snapshot copy "encrypted cluster" → thêm snapshot copy grant "RTO in minutes" → giữ cụm chạy sẵn, không phải khôi phục "RPO 24 hours" → ảnh chụp tự động là đủ

Ba lưu ý về sao chép xuyên Region: | Lưu ý | Chi tiết | |---|---| | Bật một lần, Redshift tự sao mọi ảnh chụp | | | Đặt thời gian giữ riêng cho Region đích | | | Có phí truyền dữ liệu xuyên Region | |

Ba lưu ý về khôi phục: | Lưu ý | Chi tiết | |---|---| | Tạo cụm MỚI, không ghi đè | | | Endpoint đổi, phải cập nhật ứng dụng | | | Truy vấn được ngay, dữ liệu nạp lười | |

⚠ Đổi endpoint là bước phải tự động hoá:

Ứng dụng cài cứng endpoint cũ
    → khôi phục xong vẫn không
      kết nối được
        ↓
    Lưu endpoint trong Parameter Store
    → hoặc dùng Route 53 CNAME
    → đổi một chỗ

Ba lưu ý về RA3 và Multi-AZ: | Lưu ý | Chi tiết | |---|---| | RA3 tách lưu trữ khỏi tính toán | | | RA3 hỗ trợ triển khai Multi-AZ | | | Multi-AZ chống hỏng AZ, không chống mất Region | |

⚠ Multi-AZ và cross-region là hai lớp khác nhau:

Multi-AZ: chuyển đổi tự động
  trong Region
        ↓
    Cross-region snapshot: khôi phục
      khi mất cả Region
        ↓
    Dùng cả hai cho hệ thống
      quan trọng

Ba lưu ý về Redshift Serverless: | Lưu ý | Chi tiết | |---|---| | Không quản cụm, trả theo RPU | | | Cũng sao chép ảnh chụp xuyên Region | | | Khôi phục thành namespace mới | |

Ba lưu ý về giảm RTO: | Cách | RTO | |---|---| | Khôi phục từ ảnh chụp | chục phút tới giờ | | Giữ cụm nhỏ chạy sẵn, resize | chục phút | | Cụm đầy đủ chạy song song | phút |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Ảnh chụp ở Region đích tính phí lưu trữ | | | Phí truyền dữ liệu xuyên Region | | | Rẻ hơn nhiều so với chạy cụm dự phòng | |

Ba lưu ý về kiểm thử: | Lưu ý | Chi tiết | |---|---| | Khôi phục thử và bấm giờ | | | Chạy vài truy vấn kiểm chứng dữ liệu | | | Ghi lại RTO đo được cho hồ sơ tuân thủ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm ảnh chụp đã xuất hiện ở Region đích | | | Khôi phục thử và bấm giờ | | | Xác nhận số dòng và bảng đầy đủ | |

Và một lời khuyên: hãy đo thời gian khôi phục thật trước khi cam kết RTO một giờ. Với Redshift, khôi phục là bước duy nhất trong kế hoạch DR mà bạn không thể ước lượng từ tài liệu — nó phụ thuộc kích thước cụm và loại node, và chỉ một lần khôi phục thật mới cho bạn con số để báo cáo.

Đáp án

**D — Dùng Amazon DynamoDB với thông lượng ghi đã cấp phát, và đặt một hàng đợi SQS làm bộ đệm cho lưu lượng lớn trước khi các EC2 trong Auto Scaling group xử lý và ghi vào DynamoDB.

Vì sao đúng

Đề mô tả một tình huống rất cụ thể, và phương án này giải đúng nó:

Quảng cáo trên TV và mạng xã hội
    → lưu lượng bùng nổ không đoán
      trước được
        ↓
    Hàng triệu người quyên góp
    → rất nhiều lệnh GHI
        ↓
    Cần cả bộ đệm LẪN kho ghi
      thông lượng cao

⚠ DynamoDB là lựa chọn đúng cho tải ghi lớn:

CSDL quan hệ: mỗi kết nối là
  một tiến trình hoặc luồng
        ↓
    Hàng nghìn lệnh ghi đồng thời
    → chạm trần kết nối
        ↓
    DynamoDB: không có khái niệm
      kết nối lâu dài
    → co giãn theo phân vùng

⚠ Và hàng đợi là thứ khiến kiến trúc chịu được đỉnh:

Ghi thẳng vào DynamoDB
    → đỉnh vượt công suất đã cấp
    → bị chặn, MẤT lượt quyên góp
        ↓
    Có hàng đợi: nhận ngay, xếp hàng
    → consumer ghi theo tốc độ
      DynamoDB chịu được

⚠ Đây là điểm phân biệt với phương án C:

Phương án C: DynamoDB + CloudFront
    → CloudFront phục vụ nội dung tĩnh
    → không giúp gì cho tải GHI
        ↓
    Thiếu bộ đệm
    → đỉnh tải vẫn đập thẳng vào CSDL

Cấu hình hàng đợi:

aws sqs create-queue --queue-name hang-doi-quyen-gop \
  --attributes '{
    "VisibilityTimeout":"60",
    "MessageRetentionPeriod":"1209600",
    "ReceiveMessageWaitTimeSeconds":"20",
    "RedrivePolicy":"{\"deadLetterTargetArn\":\"<arn-dlq>\",\"maxReceiveCount\":\"5\"}"}'

⚠ Giữ 14 ngày là biên an toàn rất rộng:

Consumer chết lúc nửa đêm
    → phát hiện sáng hôm sau
        ↓
    Thông điệp vẫn nằm nguyên
      trong hàng đợi
    → không mất lượt quyên góp nào

Co giãn theo độ dài hàng đợi:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name asg-xu-ly-quyen-gop \
  --policy-name theo-hang-doi \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 10.0,
    "CustomizedMetricSpecification": {
      "MetricName": "BacklogPerInstance",
      "Namespace": "QuyenGop", "Statistic": "Average"}}'

⚠ Nhưng "provisioned write throughput" là lựa chọn đáng bàn:

Đề nói lưu lượng KHÓ ĐOÁN
    → provisioned phải đoán trước
      công suất
        ↓
    On-demand: không có trần để chạm
    → đắt hơn mỗi đơn vị nhưng
      không bao giờ bị chặn
        ↓
    Với chiến dịch quyên góp một lần
    → on-demand hợp lý hơn

Chuyển sang on-demand:

aws dynamodb update-table --table-name QuyenGop \
  --billing-mode PAY_PER_REQUEST

⚠ Và thiết kế khoá phân vùng quyết định có bị chặn hay không:

Khoá = ngày ("2026-08-31")
    → mọi lệnh ghi trong ngày vào
      MỘT phân vùng
    → phân vùng nóng, bị chặn dù
      tổng WCU rất lớn
        ↓
    Khoá = idQuyenGop (UUID)
    → phân tán đều

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không mất lượt quyên góp nào khi đỉnh | | | DynamoDB chịu được thông lượng ghi rất cao | | | Tầng xử lý co giãn theo hàng đợi | |

⚠ Và ghi theo lô giảm số lời gọi:

with bang.batch_writer() as bo_ghi:
    for tin in danh_sach_tin:
        bo_ghi.put_item(Item=doc(tin))

`BatchWriteItem` gom 25 mục
  một lời gọi
        ↓
    Giảm số lời gọi API
    → nhưng KHÔNG giảm WCU tiêu thụ

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

• **C. Dùng DynamoDB làm nơi lưu và CloudFront phân phối tài nguyên tĩnh — đây là phương án gần nhất và DynamoDB hoàn toàn đúng cho tải ghi, nhưng CloudFront chỉ giúp phần đọc nội dung tĩnh; nó không có bộ đệm nào cho lệnh ghi khi đỉnh tải tới.
• **B. Dùng Oracle trên một Dedicated EC2 với SQS đệm — hàng đợi đúng, nhưng Oracle trên một máy đơn lẻ là điểm hỏng và không co giãn được theo tải ghi lớn.
• **A. Dùng RDS với Provisioned IOPS — IOPS cao giúp đĩa nhanh hơn, nhưng không giải quyết trần số kết nối và không có bộ đệm cho đỉnh tải.

Ghi nhớ

⚠ Bốn cách xử lý đỉnh ghi — bảng phải thuộc: | Cách | Đánh giá | |---|---| | Hàng đợi ở giữa | không mất dữ liệu, tải ổn định | | On-demand capacity | không có trần để chạm | | Tăng công suất thường trực | tốn tiền, vẫn có trần | | Auto Scaling của DynamoDB | phản ứng chậm với đỉnh ngắn |

Từ khoá nhận diện:

"unpredictable traffic spike, high writes" → SQS + DynamoDB "must not lose submissions" → hàng đợi "scale by queue depth" → backlog per instance "serve static content globally" → CloudFront |

Ba lưu ý về DynamoDB: | Lưu ý | Chi tiết | |---|---| | 1 WCU = 1 KB mỗi giây | | | Khoá phân vùng quyết định phân tán | | | On-demand cho tải khó đoán | |

⚠ Kiểm tra phân vùng nóng:

aws dynamodb update-contributor-insights \
  --table-name QuyenGop \
  --contributor-insights-action ENABLE

Tổng WCU lớn mà vẫn bị chặn
    → dấu hiệu phân vùng nóng
    → Contributor Insights chỉ ra
      khoá nào bị dồn

Ba lưu ý về SQS: | Lưu ý | Chi tiết | |---|---| | Standard: thông lượng vô hạn, có thể trùng | | | Visibility timeout dài hơn thời gian xử lý | | | Dead-letter queue cho thông điệp hỏng | |

Ba lưu ý về xử lý idempotent: | Lưu ý | Chi tiết | |---|---| | SQS Standard có thể giao hơn một lần | | | Dùng ConditionExpression chống ghi trùng | | | Với tiền quyên góp thì ghi trùng là nghiêm trọng | |

bang.put_item(
    Item=du_lieu,
    ConditionExpression='attribute_not_exists(idQuyenGop)')

⚠ Đây là điểm quan trọng nhất với hệ thống tài chính:

Ghi trùng một lượt quyên góp
    → báo cáo sai số tiền
    → và có thể trừ tiền hai lần
        ↓
    Điều kiện `attribute_not_exists`
      bảo đảm mỗi lượt chỉ ghi
      một lần

Ba lưu ý về ASG cho consumer: | Lưu ý | Chi tiết | |---|---| | Co giãn theo backlog per instance | | | Min bằng 0 khi hết chiến dịch | | | Lifecycle hook để xử lý xong trước khi tắt | |

Ba lưu ý về kiến trúc thay thế: | Lựa chọn | Khi nào | |---|---| | Lambda thay EC2 | xử lý dưới 15 phút mỗi thông điệp | | Kinesis thay SQS | cần phát lại hoặc nhiều consumer | | API Gateway ghi thẳng SQS | bỏ một tầng |

⚠ API Gateway tích hợp thẳng SQS:

Không cần Lambda ở giữa để
  đẩy vào hàng đợi
        ↓
    Bớt một tầng có thể hỏng
    → và bớt một chỗ tính phí

Ba lưu ý về giám sát: | Chỉ số | Cảnh báo khi | |---|---| | ApproximateAgeOfOldestMessage | tăng đều | | WriteThrottleEvents | lớn hơn 0 | | Độ sâu DLQ | lớn hơn 0 |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy tải cao, đếm số bản ghi vào DynamoDB | | | Kiểm không có lượt nào ghi hai lần | | | Theo dõi hàng đợi có dồn quá lâu không | |

Và một lời khuyên: hãy dùng ConditionExpression cho mọi lệnh ghi liên quan tới tiền. SQS Standard có thể giao một thông điệp hơn một lần, và với hệ thống quyên góp thì một bản ghi trùng không chỉ là lỗi kỹ thuật — nó là con số sai trong báo cáo gửi cho nhà tài trợ.

Đáp án

**D — Dùng CloudFormation kết hợp Systems Manager Parameter Store để lấy AMI ID mới nhất cho template; khi muốn cập nhật EC2 thì gọi update-stack.

Vì sao đúng

Đề nêu một việc lặp lại tốn thời gian, và Parameter Store giải quyết đúng nó:

Sửa AMI ID trong template mỗi lần
  có ảnh mới
        ↓
    Template tham chiếu một tham số
    → cập nhật tham số một chỗ
    → mọi template dùng nó tự thấy
      giá trị mới

⚠ CloudFormation có kiểu tham số ĐẶC BIỆT cho việc này:

Parameters:
  MaAnh:
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /ung-dung/ami-moi-nhat

CloudFormation TỰ đọc giá trị từ
  Parameter Store lúc triển khai
        ↓
    Không phải truyền AMI ID vào
      mỗi lần
    → và giá trị được xác thực là
      một AMI ID hợp lệ

Cập nhật tham số khi có AMI mới:

aws ssm put-parameter --name /ung-dung/ami-moi-nhat \
  --type String --value ami-0abc123 --overwrite

⚠ Và AWS đã công bố sẵn tham số cho AMI chính thức:

aws ssm get-parameter \
  --name /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --query 'Parameter.Value'

Dùng thẳng tham số công khai
    → luôn lấy AMI Amazon Linux
      mới nhất
    → không phải tự cập nhật gì

⚠ Nhưng có một điểm quan trọng: đổi tham số KHÔNG tự cập nhật stack:

Cập nhật Parameter Store
    → stack đang chạy KHÔNG đổi
        ↓
    Phải gọi `update-stack`
    → CloudFormation đọc lại tham số
      và cập nhật launch template
        ↓
    Đây chính là điều đáp án mô tả

⚠ Và AWS::SSM::Parameter::Value khác dynamic reference: | Cách | Đọc khi nào | |---|---| | AWS::SSM::Parameter::Value<...> | lúc triển khai, hiện trong tham số stack | | {{resolve:ssm:...}} | lúc triển khai, không hiện trong tham số |

Kiểu tham số: thấy được giá trị
  đã dùng khi xem stack
        ↓
    Dynamic reference: gọn hơn nhưng
      không thấy giá trị

⚠ Và State Manager (phương án C) không lưu tham số:

State Manager: giữ cấu hình
  ở trạng thái mong muốn
        ↓
    Không phải kho lưu giá trị
    → Parameter Store mới là
      dịch vụ đó

⚠ Và Service Catalog (phương án A, B) là công cụ khác hẳn:

Service Catalog: danh mục sản phẩm
  tự phục vụ
        ↓
    Nó không "lấy AMI ID mới nhất"
    → và không giải quyết vấn đề
      cập nhật template

Thay đội máy khi AMI đổi:

NhomCoGian:
  Type: AWS::AutoScaling::AutoScalingGroup
  UpdatePolicy:
    AutoScalingRollingUpdate:
      MinInstancesInService: 4
      MaxBatchSize: 2
      PauseTime: PT10M
      WaitOnResourceSignals: true

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cập nhật một tham số thay vì sửa nhiều template | | | CloudFormation xác thực AMI ID hợp lệ | | | Kết hợp được với pipeline dựng ảnh | |

⚠ Và tự động hoá trọn vẹn bằng Image Builder:

EC2 Image Builder dựng AMI mới
    → sự kiện EventBridge
        ↓
    Lambda cập nhật Parameter Store
        ↓
    Pipeline gọi `update-stack`
        ↓
    Rolling update thay cả đội máy

aws imagebuilder create-distribution-configuration \
  --name phan-phoi-ami \
  --distributions '[{
    "region":"ap-southeast-1",
    "amiDistributionConfiguration":{
      "name":"ung-dung-{{imagebuilder:buildDate}}"}}]'

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

• **C. Dùng Systems Manager State Manager lưu AMI ID mới nhất và tích hợp với template, rồi gọi update-stack — đây là phương án gần nhất và phần update-stack hoàn toàn đúng, nhưng State Manager giữ cấu hình ở trạng thái mong muốn trên instance, nó không phải kho lưu giá trị; Parameter Store mới là dịch vụ đó.
• **A. Dùng CloudFormation với Service Catalog để lấy AMI ID mới nhất — Service Catalog là danh mục sản phẩm tự phục vụ, nó không cung cấp cơ chế lưu và lấy AMI ID.
• **B. Kết hợp Service Catalog với AWS Config để tự lấy AMI mới nhất — Config đánh giá tuân thủ cấu hình, không lưu giá trị tham số.

Ghi nhớ

⚠ Ba kiểu tham số SSM trong CloudFormation — bảng phải thuộc: | Kiểu | Dùng cho | |---|---| | AWS::SSM::Parameter::Value<String> | chuỗi thường | | AWS::SSM::Parameter::Value<AWS::EC2::Image::Id> | AMI ID, có xác thực | | AWS::SSM::Parameter::Value<List<String>> | danh sách |

Từ khoá nhận diện:

"latest AMI ID in CloudFormation" → Parameter Store "secret in CloudFormation" → dynamic reference tới Secrets Manager "build AMI automatically" → EC2 Image Builder "replace instances on stack update" → UpdatePolicy rolling

Ba lưu ý về Parameter Store: | Lưu ý | Chi tiết | |---|---| | Standard miễn phí, tối đa 4 KB | | | Advanced có phí, tối đa 8 KB, có chính sách | | | SecureString mã hoá bằng KMS | |

⚠ Đừng dùng Parameter Store cho mật khẩu cần xoay:

SecureString mã hoá tốt
    → nhưng KHÔNG có xoay tự động
        ↓
    Secrets Manager có xoay sẵn
      cho RDS, Redshift, DocumentDB

Ba lưu ý về dynamic reference: | Lưu ý | Chi tiết | |---|---| | {{resolve:ssm:ten:phien-ban}} | | | {{resolve:ssm-secure:ten}} | | | {{resolve:secretsmanager:ten:SecretString:khoa}} | |

Ba lưu ý về phiên bản tham số: | Lưu ý | Chi tiết | |---|---| | Mỗi lần --overwrite tạo phiên bản mới | | | Tham chiếu phiên bản cụ thể để cố định | | | Label đặt tên cho phiên bản | |

aws ssm label-parameter-version \
  --name /ung-dung/ami-moi-nhat \
  --parameter-version 5 --labels da-kiem-thu

⚠ Label cho phép tách "mới nhất" và "đã kiểm thử":

`/ung-dung/ami-moi-nhat` — bản mới
  vừa dựng
        ↓
    Label `da-kiem-thu` — bản đã qua
      kiểm thử
        ↓
    Môi trường thử dùng bản mới nhất
    → sản xuất dùng bản có label

Ba lưu ý về UpdatePolicy: | Thuộc tính | Ý nghĩa | |---|---| | MinInstancesInService | số máy luôn phục vụ | | MaxBatchSize | thay bao nhiêu máy mỗi đợt | | WaitOnResourceSignals | chờ instance báo sẵn sàng |

Ba lưu ý về Instance Refresh: | Lưu ý | Chi tiết | |---|---| | Tính năng của chính ASG | | | Có checkpoint dừng giữa chừng | | | Không cần đi qua CloudFormation | |

Ba lưu ý về EC2 Image Builder: | Lưu ý | Chi tiết | |---|---| | Pipeline dựng AMI có bước kiểm thử | | | Phân phối sang nhiều Region và tài khoản | | | Tích hợp với Inspector để quét lỗ hổng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cập nhật tham số rồi chạy update-stack | | | Kiểm launch template dùng AMI mới | | | Theo dõi rolling update không gây gián đoạn | |

Và một lời khuyên: hãy dùng label của Parameter Store để tách bản "mới nhất" khỏi bản "đã kiểm thử". Trỏ sản xuất thẳng vào AMI mới nhất nghĩa là mọi ảnh vừa dựng đều đi thẳng vào môi trường thật — kể cả ảnh vừa được dựng lúc năm giờ chiều thứ sáu.