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

Đáp án

**D và E — Dùng CloudFront signed URL để giới hạn truy cập tệp cài đặt ứng dụng, và dùng CloudFront signed cookie để giới hạn truy cập toàn bộ tệp trong khu vực thành viên.

Vì sao đúng

Đề mô tả hai tình huống khác nhau, và mỗi cơ chế hợp với một tình huống: | Tình huống | Số tệp | Cơ chế | |---|---|---| | Tải tệp cài đặt | MỘT tệp | signed URL | | Xem khu vực thành viên | NHIỀU tệp | signed cookie |

⚠ Đây là quy tắc chọn giữa hai cơ chế:

Cấp quyền cho MỘT tệp cụ thể
        ↓
    Signed URL — URL chứa chữ ký
      cho đúng đường dẫn đó
        ↓
    Cấp quyền cho NHIỀU tệp hoặc
      cả một khu vực
        ↓
    Signed cookie — cookie gửi kèm
      mọi yêu cầu, không phải ký
      từng URL

⚠ Và vì sao signed URL không hợp cho khu vực thành viên:

Một trang web có hàng chục ảnh,
  CSS, JS
        ↓
    Signed URL: phải ký TỪNG tài
      nguyên
    → và viết lại mọi đường dẫn
      trong HTML
        ↓
    Không khả thi

⚠ Và vì sao signed cookie không hợp cho tệp cài đặt:

Cookie áp cho cả một dải đường dẫn
        ↓
    Không kiểm soát được từng tệp
      riêng lẻ
        ↓
    Và cookie không dùng được khi
      client là trình tải xuống
      chuyên dụng, không phải
      trình duyệt

Tạo signed URL:

from botocore.signers import CloudFrontSigner
from cryptography.hazmat.primitives import hashes, serialization
from cryptography.hazmat.primitives.asymmetric import padding
import datetime

def ky(thong_diep):
    with open('khoa-rieng.pem', 'rb') as f:
        khoa = serialization.load_pem_private_key(f.read(), password=None)
    return khoa.sign(thong_diep, padding.PKCS1v15(), hashes.SHA1())

nguoi_ky = CloudFrontSigner('K2JCJMDEHXQW6F', ky)
url = nguoi_ky.generate_presigned_url(
    'https://d123.cloudfront.net/cai-dat/ung-dung-v3.dmg',
    date_less_than=datetime.datetime.utcnow() +
                   datetime.timedelta(hours=2))

Tạo signed cookie:

cookie = nguoi_ky.generate_presigned_cookies(
    policy=json.dumps({"Statement": [{
        "Resource": "https://d123.cloudfront.net/thanh-vien/*",
        "Condition": {
            "DateLessThan": {"AWS:EpochTime": het_han},
            "IpAddress": {"AWS:SourceIp": "203.0.113.0/24"}}}]}))

⚠ Custom policy cho phép đặt điều kiện phức tạp — đây là điểm mạnh: | Điều kiện | Tác dụng | |---|---| | DateLessThan | hạn hết hiệu lực (bắt buộc) | | DateGreaterThan | chưa có hiệu lực trước thời điểm này | | IpAddress | chỉ IP hoặc dải IP này | | Resource có * | áp cho nhiều tệp |

⚠ Và canned policy chỉ có một điều kiện:

Canned policy: chỉ đặt được
  DateLessThan
        ↓
    URL ngắn hơn
        ↓
    Custom policy: đặt được cả IP,
      thời điểm bắt đầu, wildcard
    → dài hơn nhưng linh hoạt hơn

⚠ Và cả hai cơ chế cần key pair và key group:

aws cloudfront create-public-key --public-key-config '{
  "CallerReference": "khoa-2026",
  "Name": "khoa-ky-url",
  "EncodedKey": "-----BEGIN PUBLIC KEY-----\n..."}'

aws cloudfront create-key-group --key-group-config '{
  "Name": "nhom-khoa-thanh-vien",
  "Items": ["K2JCJMDEHXQW6F"]}'

⚠ Trusted key group thay thế trusted signer cũ: | Cơ chế | Trạng thái | |---|---| | Trusted key group | hiện hành, khuyến nghị | | Trusted signer (CloudFront key pair của root) | legacy, cần root account |

Cơ chế cũ đòi tài khoản ROOT tạo
  key pair
        ↓
    Trái với thực hành không dùng
      root
        ↓
    Key group: tạo bằng IAM user
      bình thường

⚠ Và vì sao phương án B sai:

B nói yêu cầu HTTPS giữa CloudFront
  và origin S3
        ↓
    Đó là bảo vệ dữ liệu KHI TRUYỀN
        ↓
    Không kiểm soát AI được truy cập
    → sai loại bảo mật

⚠ Và OAC vẫn cần thiết song song:

Signed URL/cookie chặn người dùng
  không hợp lệ ở CloudFront
        ↓
    Nhưng nếu bucket S3 công khai
    → ai cũng tải thẳng từ S3
        ↓
    OAC bịt lối đó lại

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Kiểm soát chính xác ai xem được gì | | | Có hạn thời gian, không cần thu hồi | | | Giới hạn được cả theo IP | |

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

• **A. Dùng signed URL để giới hạn truy cập toàn bộ tệp trong khu vực thành viên — đây là phương án gần nhất và signed URL thật sự kiểm soát được truy cập, nhưng phải ký từng tệp một và viết lại mọi đường dẫn trong trang, không khả thi với một khu vực có nhiều tệp.
• **C. Dùng signed cookie để giới hạn truy cập tệp cài đặt — cookie áp cho cả dải đường dẫn, không kiểm soát được một tệp riêng lẻ, và không dùng được với client không phải trình duyệt.
• **B. Yêu cầu HTTPS giữa CloudFront và origin S3 — đó là bảo vệ dữ liệu khi truyền, không phải kiểm soát truy cập.

Ghi nhớ

⚠ Signed URL và signed cookie — bảng phải thuộc: | Tiêu chí | Signed URL | Signed cookie | |---|---|---| | Phạm vi | một tệp | nhiều tệp theo mẫu | | Client không phải trình duyệt | DÙNG ĐƯỢC | không | | Giữ nguyên URL gốc | không | CÓ | | Hợp với | tải tệp đơn lẻ | khu vực có xác thực |

Từ khoá nhận diện:

"restrict access to a single file" → signed URL "restrict access to an entire members area" → signed cookie "restrict S3 origin to CloudFront only" → OAC "restrict by country" → geo restriction

Ba lưu ý về signed URL: | Lưu ý | Chi tiết | |---|---| | Canned policy chỉ có hạn thời gian | | | Custom policy thêm được IP và wildcard | | | Khoá riêng phải giữ an toàn tuyệt đối | |

⚠ Lộ khoá riêng là lộ toàn bộ nội dung:

Ai có khoá riêng thì tự ký URL
  cho bất kỳ tệp nào
        ↓
    Lưu trong Secrets Manager
    → và xoay định kỳ bằng cách
      thêm khoá mới vào key group

Ba lưu ý về key group: | Lưu ý | Chi tiết | |---|---| | Chứa được nhiều public key | | | Nhiều khoá cho phép xoay không gián đoạn | | | Gắn vào cache behavior cụ thể | |

Ba lưu ý về OAC: | Lưu ý | Chi tiết | |---|---| | Thay thế OAI, hỗ trợ SSE-KMS | | | Bucket policy dùng service principal + AWS:SourceArn | | | Bắt buộc nếu muốn bucket riêng tư | |

Ba lưu ý về geo restriction: | Lưu ý | Chi tiết | |---|---| | Danh sách cho phép hoặc danh sách chặn | | | Ở cấp distribution, không theo đường dẫn | | | WAF geo match linh hoạt hơn | |

Ba lưu ý về thời hạn: | Lưu ý | Chi tiết | |---|---| | Đặt hạn ngắn cho tệp nhạy cảm | | | Hạn quá ngắn làm tải tệp lớn thất bại | | | Hạn tính từ lúc bắt đầu tải, không phải lúc xong | |

⚠ Điểm cuối là bẫy thật với tệp lớn:

URL hết hạn sau 5 phút
        ↓
    Tệp 2 GB tải mất 20 phút
        ↓
    CloudFront kiểm hạn lúc BẮT ĐẦU
    → tải xong bình thường
        ↓
    Nhưng nếu kết nối đứt và tải lại
    → URL đã hết hạn

Ba lưu ý về xác thực người dùng: | Lưu ý | Chi tiết | |---|---| | Ứng dụng xác thực rồi mới cấp signed URL/cookie | | | Cognito hoặc hệ thống đăng nhập riêng | | | CloudFront không tự xác thực người dùng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi URL không có chữ ký — phải 403 | | | Gọi URL đã hết hạn — phải 403 | | | Gọi thẳng URL S3 — phải bị từ chối | |

Và một lời khuyên: hãy đặt hạn của signed URL đủ dài cho việc tải tệp lớn hoàn tất kể cả khi phải tải lại. Một URL hết hạn sau năm phút hoạt động hoàn hảo trong thử nghiệm và thất bại với người dùng có đường truyền chậm — đúng nhóm người dùng cần nhất một lần tải thành công.

Đáp án

**D — Dùng AWS DataSync để tự động hoá và tăng tốc việc chuyển dữ liệu trực tuyến sang các dịch vụ lưu trữ đó.

Vì sao đúng

Đề cho ba dữ kiện, và DataSync khớp cả ba: | Dữ kiện | Cách đáp ứng | |---|---| | Đích là S3, EFS VÀ FSx for Windows | DataSync hỗ trợ cả ba | | Chuyển TRỰC TUYẾN, tự động hoá | DataSync có lịch và agent | | Hàng trăm TB mỗi ngày | DataSync tối ưu cho lượng lớn |

⚠ Điểm mấu chốt: chỉ DataSync hỗ trợ cả ba đích đó: | Dịch vụ | S3 | EFS | FSx for Windows | |---|---|---|---| | DataSync | CÓ | CÓ | CÓ | | File Gateway | có | không | không (có FSx File Gateway riêng) | | Transfer Family | có | có | không | | Snowball Edge | có | không | không |

⚠ Và từ khoá "online data transfers" loại Snowball ngay:

Snowball là chuyển OFFLINE
        ↓
    Thiết bị vật lý gửi qua đường
      bưu chính
        ↓
    Đề nói "online data transfers"
    → và "hằng ngày"
        ↓
    Chu trình Snowball 1-2 tuần
    → không thể làm hằng ngày

Tạo agent và vị trí:

aws datasync create-location-nfs \
  --server-hostname 192.168.1.100 \
  --subdirectory /du-lieu-nghien-cuu \
  --on-prem-config AgentArns=<arn-agent>

aws datasync create-location-s3 \
  --s3-bucket-arn arn:aws:s3:::du-lieu-gen \
  --s3-config BucketAccessRoleArn=<arn-role>

Tạo tác vụ có lịch:

aws datasync create-task \
  --source-location-arn <arn-nguon> \
  --destination-location-arn <arn-dich> \
  --schedule ScheduleExpression="cron(0 2 * * ? *)" \
  --options VerifyMode=ONLY_FILES_TRANSFERRED,\
TransferMode=CHANGED,PreserveDeletedFiles=REMOVE,\
BytesPerSecond=500000000

⚠ TransferMode=CHANGED là chìa khoá cho việc chạy hằng ngày:

`ALL`: chuyển lại toàn bộ mỗi lần
        ↓
    `CHANGED`: chỉ chuyển tệp mới
      hoặc đã đổi
        ↓
    Với hàng trăm TB, khác biệt này
      là tất cả

⚠ Và BytesPerSecond là giới hạn băng thông — tính năng quan trọng:

Không giới hạn: DataSync chiếm hết
  đường truyền
        ↓
    Nhân viên không dùng được mạng
        ↓
    Đặt trần theo giờ: ban đêm cao,
      ban ngày thấp

⚠ Và DataSync nhanh hơn công cụ tự viết nhiều lần:

Giao thức tối ưu riêng của AWS
        ↓
    Nén, xử lý song song, chỉ chuyển
      phần khác biệt
        ↓
    AWS công bố nhanh hơn khoảng
      10 lần so với công cụ chép
      thông thường

⚠ Và có kiểm tra toàn vẹn sẵn: | Chế độ | Kiểm gì | |---|---| | POINT_IN_TIME_CONSISTENT | so checksum toàn bộ đích với nguồn | | ONLY_FILES_TRANSFERRED | chỉ so tệp vừa chuyển — nhanh hơn | | NONE | không kiểm |

⚠ Và vì sao phương án A (File Gateway) không hợp:

File Gateway là cầu nối TRUY CẬP
  liên tục
        ↓
    Ứng dụng tại chỗ ghi qua NFS/SMB,
      dữ liệu thành object S3
        ↓
    Không phải công cụ DI TRÚ
    → và chỉ hỗ trợ S3, không hỗ
      trợ EFS hay FSx

⚠ Và vì sao phương án C (Transfer Family) không hợp:

Transfer Family phơi SFTP, FTPS,
  FTP, AS2
        ↓
    Dành cho ĐỐI TÁC bên ngoài gửi
      tệp vào
        ↓
    Không phải công cụ đồng bộ
      hàng loạt
    → và không hỗ trợ FSx for Windows

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một công cụ cho cả ba đích | | | Có lịch, có kiểm tra toàn vẹn | | | Giới hạn được băng thông | |

⚠ Và DataSync còn chuyển được giữa các dịch vụ AWS:

S3 ↔ EFS
    S3 ↔ FSx
        ↓
    Và liên Region, liên tài khoản
        ↓
    Không cần agent cho các cặp
      này — chỉ cần khi nguồn ở
      tại chỗ

⚠ Và agent chạy được ở nhiều nơi: | Nơi chạy | Khi nào | |---|---| | VMware, Hyper-V, KVM tại chỗ | nguồn ở tại chỗ | | EC2 | nguồn là hệ thống tệp trong AWS | | Snowcone | địa điểm hẻo lánh |

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

• **A. Dùng File Gateway để tự động hoá và tăng tốc chuyển dữ liệu — đây là phương án gần nhất và thật sự là cầu nối giữa hệ thống tệp tại chỗ và AWS, nhưng nó dành cho truy cập liên tục chứ không phải di trú hàng loạt, và chỉ hỗ trợ S3.
• **C. Dùng AWS Transfer Family — dịch vụ phơi SFTP/FTPS cho đối tác gửi tệp, không phải công cụ đồng bộ hàng loạt, và không hỗ trợ FSx for Windows.
• **B. Dùng Snowball Edge Storage Optimized — chuyển ngoại tuyến qua thiết bị vật lý, không đáp ứng được yêu cầu "trực tuyến" và "hằng ngày".

Ghi nhớ

⚠ Bốn dịch vụ chuyển dữ liệu — bảng phải thuộc: | Dịch vụ | Dùng khi | |---|---| | DataSync | đồng bộ hàng loạt, trực tuyến, có lịch | | Storage Gateway | truy cập lai liên tục | | Transfer Family | đối tác gửi tệp qua SFTP/FTPS | | Snow Family | lượng rất lớn, băng thông kém |

Từ khoá nhận diện:

"automate and accelerate online transfers" → DataSync "to S3, EFS, and FSx" → DataSync (chỉ nó hỗ trợ cả ba) "keep accessing data from on-premises" → Storage Gateway "partners upload via SFTP" → Transfer Family

Ba lưu ý về DataSync: | Lưu ý | Chi tiết | |---|---| | Cần agent khi nguồn ở tại chỗ | | | Tính phí theo GB chuyển | | | Có báo cáo tệp nào chuyển thành công/thất bại | |

⚠ Agent cần tài nguyên đáng kể:

Tối thiểu 4 vCPU, 32 GB RAM,
  80 GB đĩa
        ↓
    Agent thiếu tài nguyên
    → tốc độ chuyển sụt mạnh

Ba lưu ý về nguồn được hỗ trợ: | Nguồn | Ghi chú | |---|---| | NFS | v3, v4.0, v4.1 | | SMB | v1 tới v3 | | HDFS | cụm Hadoop | | Object storage khác | API tương thích S3 |

Ba lưu ý về tuỳ chọn tác vụ: | Tuỳ chọn | Tác dụng | |---|---| | PreserveDeletedFiles | giữ hay xoá tệp đã xoá ở nguồn | | OverwriteMode | ghi đè hay bỏ qua tệp đã có | | PosixPermissions | giữ quyền POSIX |

⚠ PreserveDeletedFiles=PRESERVE biến đồng bộ thành sao lưu:

PRESERVE: tệp xoá ở nguồn vẫn còn
  ở đích
        ↓
    REMOVE: đích khớp chính xác nguồn
        ↓
    Chọn PRESERVE cho sao lưu
    → REMOVE cho đồng bộ

Ba lưu ý về lọc: | Bộ lọc | Tác dụng | |---|---| | Includes | chỉ chuyển tệp khớp mẫu | | Excludes | bỏ qua tệp khớp mẫu | | Dùng | ngăn cách nhiều mẫu | |

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | BytesTransferred | lượng đã chuyển | | FilesTransferred | số tệp | | Task execution log | tệp nào lỗi và vì sao |

Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Phí DataSync theo GB | ~0,0125 USD/GB | | Truyền vào AWS | miễn phí | | Lưu trữ ở đích | theo dịch vụ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So số tệp và dung lượng hai bên | | | Đọc báo cáo thực thi tác vụ | | | Đo tốc độ thật so với băng thông đường truyền | |

Và một lời khuyên: hãy đặt giới hạn băng thông cho tác vụ DataSync ngay từ đầu. Nó được thiết kế để chạy nhanh hết mức có thể, nên một tác vụ không giới hạn sẽ chiếm sạch đường truyền của trung tâm dữ liệu — và người đầu tiên phát hiện ra thường là bộ phận hỗ trợ, không phải bạn.

Đáp án

**B, C và F — Read Replica của RDS MySQL nâng lên thành instance ĐỘC LẬP, còn Read Replica của Aurora MySQL nâng lên thành instance CHÍNH của cụm; Multi-AZ của cả RDS MySQL lẫn Aurora MySQL đều dùng sao chép ĐỒNG BỘ; và RDS MySQL Multi-AZ nâng cấp primary và standby CÙNG LÚC, Aurora MySQL nâng cấp mọi instance cùng lúc.

Vì sao đúng

Ba mệnh đề này phản ánh ba khác biệt kiến trúc căn bản giữa RDS và Aurora.

⚠ Mệnh đề B — promote replica cho kết quả khác nhau:

RDS MySQL: replica là một instance
  RIÊNG, có bản dữ liệu riêng
        ↓
    Promote → tách hẳn thành CSDL
      độc lập
    → không còn liên hệ gì với gốc
        ↓
    Aurora: mọi instance dùng CHUNG
      một tầng lưu trữ
        ↓
    Promote → replica nhận vai trò
      writer TRONG CÙNG cụm

Đây là lý do mệnh đề E sai — nó đảo ngược hai vế.

⚠ Và đây là hệ quả thực tế rất khác nhau: | Tình huống | RDS MySQL | Aurora | |---|---|---| | Writer hỏng | promote thủ công, mất dữ liệu chưa sao chép | tự động, dữ liệu chung nên không mất | | Sau khi promote | hai CSDL riêng biệt | vẫn một cụm | | Thời gian | vài phút | thường dưới 30 giây |

Promote với RDS:

aws rds promote-read-replica \
  --db-instance-identifier replica-1

Chuyển đổi với Aurora:

aws rds failover-db-cluster \
  --db-cluster-identifier cum-aurora \
  --target-db-instance-identifier aurora-replica-1

⚠ Mệnh đề C — cả hai đều dùng sao chép đồng bộ cho Multi-AZ:

RDS Multi-AZ: ghi vào primary và
  standby CÙNG LÚC
        ↓
    Giao dịch xác nhận khi cả hai
      đã ghi xong
        ↓
    Aurora: ghi vào 6 bản trên 3 AZ
    → xác nhận khi 4/6 bản đã ghi
      (quorum)
        ↓
    Cả hai đều là ĐỒNG BỘ

Đây là lý do mệnh đề D sai — nó nói RDS Multi-AZ không đồng bộ.

⚠ Và cơ chế quorum của Aurora đáng hiểu:

6 bản: 2 bản mỗi AZ, 3 AZ
        ↓
    Ghi cần 4/6 bản xác nhận
        ↓
    Đọc cần 3/6
        ↓
    Chịu được mất cả một AZ + một
      bản nữa mà vẫn ghi được

⚠ Mệnh đề F — nâng cấp phiên bản engine:

RDS Multi-AZ: primary và standby
  nâng cấp CÙNG LÚC
        ↓
    Có gián đoạn trong lúc nâng cấp
        ↓
    Aurora: mọi instance trong cụm
      nâng cấp cùng lúc
    → vì chúng dùng chung tầng lưu
      trữ, không thể chạy hai phiên
      bản engine khác nhau

Đây là lý do mệnh đề A sai — nó nói Aurora chỉ nâng cấp primary.

⚠ Và đây là hệ quả vận hành:

Không thể nâng cấp cuốn chiếu
  từng node Aurora
        ↓
    Nâng cấp phiên bản chính là
      thao tác gây gián đoạn
        ↓
    Blue/Green Deployment của RDS
      giảm được gián đoạn này

aws rds create-blue-green-deployment \
  --blue-green-deployment-name nang-cap-aurora \
  --source <arn-cum-hien-tai> \
  --target-engine-version 8.0.mysql_aurora.3.05.2

Ba lợi ích khi hiểu đúng khác biệt: | Lợi ích | Chi tiết | |---|---| | Chọn đúng cơ chế cho khôi phục | | | Không kỳ vọng promote RDS giữ nguyên cụm | | | Lên kế hoạch gián đoạn khi nâng cấp | |

⚠ Và tóm tắt khác biệt kiến trúc: | Tiêu chí | RDS MySQL | Aurora MySQL | |---|---|---| | Lưu trữ | mỗi instance một bản EBS | tầng lưu trữ chung, 6 bản/3 AZ | | Số replica | 5 | 15 | | Độ trễ replica | giây | thường dưới 100 ms | | Chuyển đổi | 60-120 giây | thường dưới 30 giây | | Reader endpoint | không có | CÓ, tự cân bằng | | Auto scaling replica | không | CÓ |

⚠ Và Aurora có thêm những thứ RDS không có:

Backtrack: quay ngược thời gian
  mà không cần khôi phục
        ↓
    Global Database: replica liên
      Region, độ trễ dưới một giây
        ↓
    Serverless v2: co giãn CPU/RAM
      theo tải
        ↓
    Cloning: tạo bản sao gần như
      tức thì, chia sẻ tầng lưu trữ

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

• **E. Read Replica của Aurora nâng lên thành instance độc lập, còn của RDS MySQL nâng lên thành primary — đây là phương án gần nhất và chỉ khác đáp án đúng ở chỗ đảo hai vế, nhưng chính Aurora mới giữ replica trong cụm vì chúng dùng chung tầng lưu trữ.
• **D. Multi-AZ của Aurora đồng bộ còn của RDS MySQL không đồng bộ — RDS Multi-AZ dùng sao chép đồng bộ; đó là điều bảo đảm không mất dữ liệu khi chuyển đổi.
• **A. Nâng cấp engine chỉ diễn ra ở primary với Aurora còn RDS thì nâng cấp mọi instance — ngược lại; Aurora nâng cấp toàn cụm cùng lúc vì dùng chung tầng lưu trữ.

Ghi nhớ

⚠ Bốn điều phải thuộc khi so RDS với Aurora: | Điều | Nội dung | |---|---| | 1 | Cả hai đều đồng bộ cho Multi-AZ | | 2 | Read replica của cả hai đều không đồng bộ | | 3 | Promote RDS → tách rời; promote Aurora → vẫn trong cụm | | 4 | Aurora nâng cấp toàn cụm cùng lúc |

Từ khoá nhận diện:

"promote to standalone" → RDS "promote to primary of cluster" → Aurora "shared storage layer" → Aurora "reader endpoint" → chỉ Aurora "backtrack in time" → chỉ Aurora

Ba lưu ý về Aurora Backtrack: | Lưu ý | Chi tiết | |---|---| | Quay ngược tới 72 giờ | | | KHÔNG tạo instance mới | | | Chỉ có với Aurora MySQL | |

aws rds backtrack-db-cluster \
  --db-cluster-identifier cum-aurora \
  --backtrack-to 2026-09-01T10:00:00Z

Xoá nhầm bảng lúc 10:05
        ↓
    Backtrack về 10:00 trong vài phút
    → nhanh hơn khôi phục snapshot
      rất nhiều

Ba lưu ý về Aurora Cloning: | Lưu ý | Chi tiết | |---|---| | Tạo bản sao gần như tức thì | | | Dùng chung tầng lưu trữ, copy-on-write | | | Chỉ trả tiền cho phần dữ liệu thay đổi | |

⚠ Cloning rất hợp cho môi trường thử nghiệm:

Cụm sản xuất 5 TB
        ↓
    Clone: vài phút, gần như không
      tốn thêm dung lượng
        ↓
    Đội phát triển thử nghiệm trên
      dữ liệu thật

Ba lưu ý về Multi-AZ DB cluster của RDS: | Lưu ý | Chi tiết | |---|---| | 1 writer + 2 reader ở ba AZ | | | Reader phục vụ đọc được | | | Chuyển đổi dưới 35 giây | |

Ba lưu ý về chuyển đổi: | Cơ chế | Thời gian | |---|---| | RDS Multi-AZ instance | 60-120 giây | | RDS Multi-AZ DB cluster | dưới 35 giây | | Aurora + replica | thường dưới 30 giây | | Aurora + RDS Proxy | nhanh hơn, kết nối không đứt |

Ba lưu ý về di trú sang Aurora: | Cách | Ngừng dịch vụ | |---|---| | Tạo Aurora Read Replica từ RDS rồi promote | rất ngắn | | Khôi phục từ snapshot | dài | | DMS full load + CDC | rất ngắn |

Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Aurora tính thêm phí I/O (trừ I/O-Optimized) | | | Aurora Serverless v2 theo ACU-giờ | | | Lưu trữ Aurora tự tăng, không cấp trước | |

⚠ Aurora I/O-Optimized đáng cân nhắc khi I/O nhiều:

Cấu hình chuẩn: phí instance +
  phí I/O theo lượt
        ↓
    I/O-Optimized: instance đắt hơn
      ~30%, KHÔNG tính phí I/O
        ↓
    Khi phí I/O vượt 25% hoá đơn
    → chuyển sang I/O-Optimized rẻ hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ép chuyển đổi và bấm giờ | | | Đo AuroraReplicaLag | | | Thử promote trên môi trường thử | |

Và một lời khuyên: hãy lên lịch nâng cấp phiên bản Aurora vào cửa sổ bảo trì có gián đoạn. Vì mọi instance dùng chung tầng lưu trữ, chúng phải cùng chạy một phiên bản engine — nên không có cách nào nâng cấp cuốn chiếu như với một cụm gồm các máy độc lập.

Đáp án

**C — Chuyển ứng dụng từ EFS sang S3, tải video thẳng lên bucket; cấu hình S3 trigger gọi Lambda mỗi khi có tệp mới, Lambda đẩy một tin nhắn vào SQS chứa liên kết và hướng dẫn xử lý; đổi ứng dụng xử lý video để đọc từ hàng đợi SQS.

Vì sao đúng

Đề mô tả một lỗi thiết kế rất cụ thể:

Nhiều máy cùng QUÉT thư mục EFS
  tìm tệp mới
        ↓
    Không có cơ chế nào chia việc
        ↓
    Hai máy thấy cùng một tệp
    → cùng xử lý
        ↓
    Thêm máy không làm nhanh hơn
    → chỉ tăng số lần xử lý trùng

⚠ Điểm mấu chốt: hàng đợi giải quyết đúng vấn đề đó:

SQS giao mỗi tin cho MỘT consumer
        ↓
    Tin bị ẩn (visibility timeout)
      trong lúc xử lý
        ↓
    Consumer khác không thấy nó
    → không có xử lý trùng
        ↓
    Và thêm consumer thì thật sự
      xử lý nhanh hơn

⚠ Và mẫu quét thư mục là chống mẫu kinh điển: | Vấn đề | Chi tiết | |---|---| | Không có phân chia việc | mọi máy thấy mọi tệp | | Không biết tệp đã xử lý chưa | phải tự dựng cơ chế đánh dấu | | Quét tốn tài nguyên | danh sách càng lớn càng chậm | | Không có thử lại tự động | máy chết giữa chừng thì tệp mất |

Cấu hình S3 trigger:

aws s3api put-bucket-notification-configuration \
  --bucket video-tho \
  --notification-configuration '{
    "LambdaFunctionConfigurations": [{
      "LambdaFunctionArn": "<arn-lambda>",
      "Events": ["s3:ObjectCreated:*"],
      "Filter": {"Key": {"FilterRules": [
        {"Name": "suffix", "Value": ".mp4"}]}}}]}'

Lambda đẩy việc vào hàng đợi:

import boto3, json, urllib.parse
sqs = boto3.client('sqs')
s3 = boto3.client('s3')

def xu_ly(event, context):
    for ban_ghi in event['Records']:
        kho = ban_ghi['s3']['bucket']['name']
        khoa = urllib.parse.unquote_plus(
            ban_ghi['s3']['object']['key'])
        huong_dan = s3.get_object(
            Bucket=kho, Key=khoa.replace('.mp4', '.json'))
        sqs.send_message(
            QueueUrl=URL_HANG_DOI,
            MessageBody=json.dumps({
                'kho': kho, 'khoa': khoa,
                'huong_dan': json.loads(
                    huong_dan['Body'].read())}))

⚠ Và vì sao phương án A gần đúng nhưng thua:

A dùng EventBridge để bắt sự kiện
  tải lên
        ↓
    Hoạt động được — nhưng phải bật
      EventBridge notification trên
      bucket
        ↓
    S3 trigger gọi thẳng Lambda:
      ít một thành phần hơn
        ↓
    Với luồng một-nguồn-một-đích,
      S3 trigger đơn giản hơn

⚠ Nhưng EventBridge có ưu điểm riêng đáng biết:

S3 trigger: một sự kiện, một đích
  (hoặc vài đích cùng loại)
        ↓
    EventBridge: lọc theo mẫu, nhiều
      đích, có archive và replay
        ↓
    Khi luồng phức tạp hơn
    → EventBridge tốt hơn

⚠ Và vì sao phương án B sai — Lambda xử lý video 1 GB:

Lambda: timeout tối đa 15 phút
        ↓
    Bộ nhớ tối đa 10 GB
        ↓
    `/tmp` tối đa 10 GB
        ↓
    Video 1 GB với hiệu ứng tổng hợp
    → rất dễ vượt cả ba

⚠ Và vì sao phương án D sai:

D dùng cron đồng bộ EFS sang S3
  mỗi giờ
        ↓
    Vẫn giữ EFS làm nơi nhận
        ↓
    Trễ tới một giờ
    → và vẫn dùng Lambda xử lý video

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không còn xử lý trùng | | | Thêm máy thì thật sự nhanh hơn | | | Máy chết thì việc quay lại hàng đợi | |

⚠ Và co giãn theo độ dài hàng đợi là mẫu đúng:

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

⚠ Và BacklogPerInstance tốt hơn số tin thô:

Số tin trong hàng đợi = 500
        ↓
    Nhiều hay ít? Tuỳ số máy đang chạy
        ↓
    Backlog mỗi máy = số tin / số máy
    → chỉ số này co giãn đúng

⚠ Và visibility timeout phải dài hơn thời gian xử lý:

Xử lý video 1 GB mất 10 phút
        ↓
    Visibility timeout 30 giây
    → tin hiện lại giữa chừng
    → xử lý trùng quay lại
        ↓
    Đặt 12 giờ, hoặc gia hạn động

sqs.change_message_visibility(
    QueueUrl=URL, ReceiptHandle=bien_lai,
    VisibilityTimeout=1800)

⚠ Và S3 phù hợp hơn EFS cho tệp video: | Tiêu chí | EFS | S3 | |---|---|---| | Chi phí lưu trữ | cao hơn nhiều | rẻ | | Tải lên trực tiếp từ client | không | CÓ (pre-signed URL) | | Sự kiện khi có tệp mới | không | CÓ | | Vòng đời tự động | có (IA, Archive) | CÓ, nhiều lớp hơn |

⚠ Và tải thẳng lên S3 bỏ được máy chủ ứng dụng khỏi đường dữ liệu:

url = s3.generate_presigned_post(
    Bucket='video-tho', Key=f'{ma_nguoi_dung}/${{filename}}',
    Conditions=[['content-length-range', 0, 1073741824]],
    ExpiresIn=3600)

Client tải thẳng lên S3
        ↓
    Máy chủ chỉ cấp URL
    → không còn là nút thắt

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

• **A. Chuyển sang S3, dùng EventBridge kích hoạt Lambda đẩy việc vào SQS, ứng dụng đọc từ SQS — đây là phương án gần nhất và giải quyết đúng vấn đề xử lý trùng, nhưng nó thêm một thành phần (EventBridge) mà luồng đơn giản này không cần; S3 trigger gọi thẳng Lambda là đủ.
• **B. Tải lên qua API Gateway, S3 trigger gọi Lambda tự xử lý video — Lambda có timeout 15 phút và giới hạn bộ nhớ, không hợp để xử lý video 1 GB có hiệu ứng tổng hợp.
• **D. Dùng cron đồng bộ EFS sang S3 mỗi giờ — vẫn giữ EFS làm nơi nhận, thêm độ trễ một giờ, và vẫn dùng Lambda xử lý video.

Ghi nhớ

⚠ Bốn mẫu phân chia việc — bảng phải thuộc: | Mẫu | Có xử lý trùng | |---|---| | Quét thư mục chung | CÓ — chống mẫu | | SQS | không (visibility timeout) | | Kinesis theo shard | không (mỗi shard một consumer) | | Lambda với S3 trigger | không |

Từ khoá nhận diện:

"files processed twice, adding instances doesn't help" → thiếu hàng đợi "decouple producers and consumers" → SQS "long-running media processing" → ECS/EC2, không phải Lambda "scale workers by queue depth" → BacklogPerInstance

Ba lưu ý về SQS: | Lưu ý | Chi tiết | |---|---| | Visibility timeout dài hơn thời gian xử lý | | | Long polling giảm lời gọi rỗng | | | DLQ cho tin xử lý hỏng nhiều lần | |

Ba lưu ý về S3 event: | Lưu ý | Chi tiết | |---|---| | Đích: Lambda, SQS, SNS, EventBridge | | | Lọc theo tiền tố và hậu tố | | | Giao ít nhất một lần | |

⚠ S3 event cũng có thể giao trùng:

"At least once delivery"
        ↓
    Một lần tải lên có thể sinh
      hai sự kiện
        ↓
    Consumer vẫn phải chịu được
      xử lý lặp

Ba lưu ý về xử lý video: | Lựa chọn | Đặc điểm | |---|---| | MediaConvert | dịch vụ chuyên, quản lý sẵn | | ECS/Fargate | tuỳ biến cao, chạy lâu được | | EC2 + Spot | rẻ nhất cho tải lớn |

⚠ MediaConvert đáng cân nhắc thay vì tự viết:

aws mediaconvert create-job \
  --role <arn-role> \
  --settings file://cau-hinh-chuyen-ma.json

Tạo thumbnail, nhiều độ phân giải,
  HLS/DASH
        ↓
    Không phải quản đội máy nào
    → trả theo phút video

Ba lưu ý về co giãn: | Lưu ý | Chi tiết | |---|---| | BacklogPerInstance là chỉ số đúng | | | Spot Instance rẻ cho tải chịu gián đoạn | | | Đặt cooldown để không co giãn dao động | |

Ba lưu ý về tính bất biến: | Lưu ý | Chi tiết | |---|---| | Dùng khoá object làm mã việc | | | Ghi kết quả với ConditionExpression | | | Hoặc kiểm tra kết quả đã tồn tại chưa trước khi xử lý | |

Ba lưu ý về thông báo cho người dùng: | Cách | Đặc điểm | |---|---| | SNS mobile push | thông báo đẩy | | AppSync subscription | cập nhật trong ứng dụng | | Hỏi trạng thái qua API | đơn giản nhất |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải một video, đếm số lần nó được xử lý | | | Thêm máy và đo thông lượng có tăng không | | | Kiểm ApproximateAgeOfOldestMessage | |

Và một lời khuyên: hãy gia hạn visibility timeout động thay vì đặt một giá trị cố định rất lớn. Video có kích thước rất khác nhau, nên một giá trị đủ cho tệp lớn nhất sẽ khiến một máy chết lúc xử lý tệp nhỏ giữ tin nhắn đó kẹt hàng giờ trước khi ai khác nhận lại được.

Đáp án

**C — Nhận dữ liệu cảm biến vào một hàng đợi SQS Standard, để một hàm Lambda đọc theo lô, và ghi vào một bảng DynamoDB có auto scaling.

Vì sao đúng

Đề nêu một ràng buộc rất rõ và nó loại bỏ phần lớn phương án:

"Hoàn toàn serverless, được cấp
  phát và quản lý TỰ ĐỘNG bởi AWS"
        ↓
    "KHÔNG muốn phương án đòi cấp
      công suất THỦ CÔNG"
        ↓
    "Không muốn phản ứng thủ công
      với lượng dữ liệu thay đổi"

⚠ Điểm mấu chốt: chỉ SQS và Lambda thoả mãn cả ba vế: | Thành phần | Cấp công suất thủ công | |---|---| | SQS | KHÔNG — không có gì để cấp | | Lambda | KHÔNG — tự co giãn | | DynamoDB auto scaling | không (hoặc on-demand) | | EC2 | CÓ — phải chọn cỡ và số máy | | Kinesis Data Streams (provisioned) | CÓ — phải chọn số shard |

⚠ Và đây là lý do hai phương án dùng EC2 (B, D) bị loại:

EC2 phải chọn kiểu máy, số lượng,
  cấu hình ASG
        ↓
    Và phải vá hệ điều hành
        ↓
    Đề nói "hoàn toàn serverless"
    → EC2 không phải serverless

⚠ Và Kinesis Data Streams ở chế độ provisioned cũng đòi cấp công suất:

Phải khai số SHARD
        ↓
    Lượng dữ liệu tăng → phải
      resharding
        ↓
    Đó chính là "phản ứng thủ công
      với lượng dữ liệu thay đổi"

⚠ Nhưng Kinesis on-demand thì lại là serverless:

aws kinesis create-stream --stream-name du-lieu-cam-bien \
  --stream-mode-details StreamMode=ON_DEMAND

On-demand: tự co giãn tới 200 MB/s
        ↓
    Không quản shard
    → cũng thoả mãn yêu cầu
        ↓
    Nhưng đề viết phương án D với
      EC2 làm consumer
    → nên vẫn bị loại

⚠ Và vì sao phương án A sai — Firehose không ghi vào DynamoDB:

Đích của Kinesis Data Firehose:
    S3, Redshift, OpenSearch,
    Splunk, HTTP endpoint,
    Snowflake, Iceberg
        ↓
    DynamoDB KHÔNG nằm trong danh sách
        ↓
    Phương án A mô tả một luồng
      không tồn tại

Cấu hình Lambda đọc SQS theo lô:

aws lambda create-event-source-mapping \
  --function-name xu-ly-cam-bien \
  --event-source-arn <arn-hang-doi> \
  --batch-size 10 \
  --maximum-batching-window-in-seconds 5 \
  --function-response-types ReportBatchItemFailures

⚠ Đọc theo lô là chi tiết quan trọng về hiệu quả:

Một tin một lời gọi Lambda
        ↓
    Chi phí khởi tạo lặp lại
        ↓
    Lô 10 tin một lời gọi
    → giảm 10 lần số lượt gọi
        ↓
    Và ghi vào DynamoDB bằng
      `BatchWriteItem`

import boto3, json
bang = boto3.resource('dynamodb').Table('du-lieu-cam-bien')

def xu_ly(event, context):
    that_bai = []
    with bang.batch_writer() as lo:
        for r in event['Records']:
            try:
                dl = json.loads(r['body'])
                lo.put_item(Item={
                    'ma_cab': dl['ma_cab'],
                    'thoi_diem': dl['thoi_diem'],
                    'vi_tri': dl['vi_tri']})
            except Exception:
                that_bai.append({'itemIdentifier': r['messageId']})
    return {'batchItemFailures': that_bai}

⚠ ReportBatchItemFailures là cấu hình nên bật:

Không bật: một tin lỗi làm cả lô
  10 tin quay lại
        ↓
    9 tin đã ghi thành công bị xử
      lý lại
        ↓
    Bật: chỉ tin lỗi quay lại

⚠ Và DynamoDB on-demand đơn giản hơn auto scaling: | Chế độ | Đặc điểm | |---|---| | On-demand | không cấu hình gì, chịu đỉnh gấp đôi mức cao nhất | | Provisioned + auto scaling | rẻ hơn khi tải ổn định, phản ứng chậm vài phút |

Đề nói "auto-scaled DynamoDB table"
        ↓
    Cả hai chế độ đều thoả mãn
    → nhưng on-demand đúng tinh
      thần serverless hơn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có gì phải cấp phát hay vá | | | Hàng đợi đệm khi có đỉnh dữ liệu | | | Trả tiền theo lượng dùng thật | |

⚠ Và SQS đệm là điểm mạnh với dữ liệu cảm biến:

Đội xe vào giờ cao điểm gửi gấp
  nhiều lần
        ↓
    SQS nhận hết ngay
        ↓
    Lambda xử lý dần
    → DynamoDB không bị dội

⚠ Nhưng SQS không giữ thứ tự — điều cần cân nhắc:

SQS Standard: thứ tự KHÔNG bảo đảm
        ↓
    Dữ liệu vị trí có dấu thời gian
    → sắp xếp lại được khi đọc
        ↓
    Cần thứ tự nghiêm ngặt
    → FIFO queue hoặc Kinesis

⚠ Và SQS không phát lại được — khác Kinesis: | Tiêu chí | SQS | Kinesis | |---|---|---| | Sau khi xử lý | tin bị xoá | dữ liệu còn tới hết hạn giữ | | Nhiều consumer độc lập | không | CÓ | | Phát lại | không | CÓ |

Đề chỉ có một luồng xử lý xuống
  DynamoDB
        ↓
    Không cần phát lại, không cần
      nhiều consumer
    → SQS đủ và đơn giản hơn

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

• **D. Nhận dữ liệu vào Kinesis Data Stream, ứng dụng trên EC2 đọc và ghi vào DynamoDB — đây là phương án gần nhất và Kinesis thật sự là dịch vụ chuẩn cho dữ liệu luồng từ cảm biến, nhưng EC2 không phải serverless và Kinesis provisioned đòi khai số shard thủ công.
• **B. Nhận vào SQS, ứng dụng trên EC2 đọc và ghi vào DynamoDB — SQS đúng nhưng EC2 vi phạm yêu cầu serverless.
• **A. Nhận vào Kinesis Data Firehose, ghi thẳng vào DynamoDB — Firehose không hỗ trợ DynamoDB làm đích.

Ghi nhớ

⚠ Bốn dịch vụ nhận dữ liệu và mức serverless — bảng phải thuộc: | Dịch vụ | Serverless | |---|---| | SQS | hoàn toàn | | Firehose | hoàn toàn | | Kinesis Data Streams on-demand | hoàn toàn | | Kinesis Data Streams provisioned | phải quản shard | | MSK | phải quản cụm (trừ MSK Serverless) |

Từ khoá nhận diện:

"fully serverless, no manual capacity" → SQS + Lambda + DynamoDB "multiple independent consumers" → Kinesis "deliver to S3/Redshift/OpenSearch" → Firehose "strict ordering" → SQS FIFO hoặc Kinesis

⚠ Đích của Firehose — bảng phải thuộc: | Đích | Hỗ trợ | |---|---| | S3 | CÓ | | Redshift | CÓ (qua S3) | | OpenSearch | CÓ | | Splunk, HTTP endpoint | CÓ | | DynamoDB | KHÔNG | | RDS | KHÔNG |

Ba lưu ý về Lambda với SQS: | Lưu ý | Chi tiết | |---|---| | Batch size tối đa 10 (Standard mặc định) | | | Batching window gom thêm tin trước khi gọi | | | MaximumConcurrency giới hạn tải xuống hệ thống sau | |

⚠ Giới hạn đồng thời bảo vệ DynamoDB:

Lambda co giãn tới 1.000 phiên bản
        ↓
    1.000 tiến trình ghi đồng thời
    → DynamoDB bị chặn
        ↓
    `MaximumConcurrency=200` giữ
      tải ở mức chịu được

Ba lưu ý về DynamoDB cho dữ liệu cảm biến: | Lưu ý | Chi tiết | |---|---| | Partition key nên là mã thiết bị | | | Sort key là thời điểm | | | TTL tự dọn dữ liệu cũ | |

⚠ Đừng dùng thời gian làm partition key:

Mọi ghi trong cùng khoảng thời
  gian dồn vào một phân vùng
        ↓
    Phân vùng nóng, bị chặn
        ↓
    Mã thiết bị phân tán đều

Ba lưu ý về SQS: | Lưu ý | Chi tiết | |---|---| | Giữ tin tối đa 14 ngày | | | Visibility timeout dài hơn thời gian xử lý | | | DLQ cho tin xử lý hỏng | |

Ba lưu ý về IoT: | Dịch vụ | Việc | |---|---| | IoT Core | kết nối thiết bị qua MQTT, xác thực bằng chứng chỉ | | IoT Rules Engine | định tuyến tin tới DynamoDB, Kinesis, Lambda | | IoT Device Shadow | trạng thái thiết bị khi mất kết nối |

⚠ IoT Core là lựa chọn đáng cân nhắc cho đội xe:

Hàng nghìn xe kết nối
        ↓
    IoT Core: MQTT, xác thực từng
      thiết bị bằng chứng chỉ X.509
        ↓
    Rules Engine ghi thẳng vào
      DynamoDB — không cần Lambda

Ba lưu ý về chi phí: | Thành phần | Cách tính | |---|---| | SQS | theo triệu yêu cầu | | Lambda | GB-giây + lượt gọi | | DynamoDB on-demand | theo đơn vị đọc/ghi |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo ApproximateAgeOfOldestMessage | | | Kiểm ThrottledRequests của DynamoDB | | | Chạy thử với đỉnh dữ liệu dự kiến | |

Và một lời khuyên: hãy đặt MaximumConcurrency cho event source mapping của Lambda. Lambda co giãn rất nhanh khi hàng đợi dồn ứ, và nếu không giới hạn thì nó sẽ đẩy toàn bộ áp lực xuống DynamoDB — biến một vấn đề về hàng đợi thành một vấn đề về cơ sở dữ liệu.

Đáp án

**A — Instance khởi động bởi cả Launch Configuration LC-A lẫn LC-B đều có tenancy là "dedicated".

Vì sao đúng

Quy tắc tenancy có một nguyên tắc duy nhất, và nó giải thích cả hai trường hợp:

Tenancy hiệu lực = mức HẠN CHẾ
  HƠN giữa VPC và cấu hình khởi động
        ↓
    "dedicated" hạn chế hơn "default"
        ↓
    Chỉ cần MỘT trong hai là
      "dedicated"
    → instance chạy dedicated

⚠ Bảng kết hợp phải thuộc: | Tenancy của VPC | Tenancy khai lúc khởi động | Kết quả | |---|---|---| | default | default | default (chia sẻ) | | default | dedicated | DEDICATED | | dedicated | default | DEDICATED | | dedicated | dedicated | DEDICATED |

LC-A: VPC-A default + LC dedicated
    → DEDICATED
        ↓
    LC-B: VPC-B dedicated + LC default
    → DEDICATED

⚠ Điểm mấu chốt: VPC có tenancy dedicated là ràng buộc TUYỆT ĐỐI:

VPC khai `dedicated`
        ↓
    MỌI instance trong VPC đó đều
      dedicated
        ↓
    Không có cách nào khởi động
      instance chia sẻ trong đó
    → kể cả khi khai `default`

⚠ Và VPC có tenancy default thì linh hoạt:

VPC khai `default`
        ↓
    Instance mặc định là chia sẻ
        ↓
    Nhưng khai `dedicated` lúc khởi
      động thì được dedicated
    → trộn được cả hai loại

Xem tenancy của VPC:

aws ec2 describe-vpcs --vpc-ids vpc-abc \
  --query 'Vpcs[0].InstanceTenancy'

Khai tenancy trong launch template:

aws ec2 create-launch-template \
  --launch-template-name mau-dedicated \
  --launch-template-data '{
    "ImageId": "ami-0abc123",
    "InstanceType": "m6i.large",
    "Placement": {"Tenancy": "dedicated"}}'

⚠ Và tenancy của VPC KHÔNG đổi được sau khi tạo — trừ một chiều:

aws ec2 modify-vpc-tenancy --vpc-id vpc-abc \
  --instance-tenancy default

Đổi `dedicated` → `default`: ĐƯỢC
        ↓
    Đổi `default` → `dedicated`:
      KHÔNG
        ↓
    Và thay đổi chỉ áp cho instance
      khởi động SAU đó

⚠ Và ba mức tenancy — phải phân biệt: | Mức | Nghĩa | |---|---| | default (shared) | chung máy chủ vật lý với tài khoản khác | | dedicated | máy chủ vật lý riêng cho tài khoản bạn | | host | Dedicated Host — bạn kiểm soát cả máy chủ vật lý |

⚠ Dedicated Instance và Dedicated Host khác nhau: | Tiêu chí | Dedicated Instance | Dedicated Host | |---|---|---| | Cách ly phần cứng | CÓ | CÓ | | Biết instance nằm ở socket/core nào | không | CÓ | | Dùng giấy phép BYOL theo socket | không | CÓ | | Instance đặt lại đúng máy cũ sau khi dừng | không bảo đảm | CÓ (affinity) |

Ngân hàng cần cách ly phần cứng
        ↓
    Dedicated Instance đủ
        ↓
    Cần dùng giấy phép Oracle hoặc
      Windows theo socket
    → phải Dedicated Host

⚠ Và chi phí là điều phải biết:

Dedicated Instance: giá instance
  cao hơn khoảng 10%
        ↓
    CỘNG THÊM phí "dedicated per
      Region" khoảng 2 USD/giờ
        ↓
    Phí đó tính MỘT LẦN cho mỗi
      Region, dù chạy bao nhiêu máy

⚠ Đây là lý do vô tình dùng dedicated rất tốn kém:

Chỉ chạy vài instance nhỏ
        ↓
    Phí 2 USD/giờ = ~1.460 USD/tháng
    → bất kể quy mô
        ↓
    Tạo VPC với tenancy dedicated
      rồi quên
    → hoá đơn tăng mà không rõ lý do

Ba lợi ích của dedicated tenancy: | Lợi ích | Chi tiết | |---|---| | Cách ly phần cứng khỏi tài khoản khác | | | Đáp ứng yêu cầu tuân thủ nghiêm ngặt | | | Giảm rủi ro tấn công qua kênh phụ | |

⚠ Và có những dịch vụ không chạy trong VPC dedicated:

Một số dịch vụ quản lý không hỗ
  trợ VPC có tenancy dedicated
        ↓
    Ví dụ: một số cấu hình RDS,
      ElastiCache, EMR
        ↓
    Kiểm tra trước khi đặt tenancy
      ở cấp VPC

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

• **C. LC-A cho dedicated còn LC-B cho default — đây là phương án gần nhất và vế đầu hoàn toàn đúng, nhưng VPC-B có tenancy dedicated, mà tenancy của VPC là ràng buộc tuyệt đối nên LC-B cũng cho ra instance dedicated.
• **B. LC-A cho default còn LC-B cho dedicated — ngược lại; khai dedicated lúc khởi động luôn thắng.
• **D. Cả hai cho default — không đúng với cả hai trường hợp.

Ghi nhớ

⚠ Nguyên tắc tenancy duy nhất phải nhớ:

Mức hạn chế hơn thắng
        ↓
    VPC dedicated → mọi thứ dedicated
        ↓
    VPC default → tuỳ theo khai lúc
      khởi động

Từ khoá nhận diện:

"physically isolated at host hardware level" → dedicated tenancy "BYOL licensing per socket/core" → Dedicated Host "instance must return to same host" → Dedicated Host với affinity "VPC tenancy is dedicated" → mọi instance đều dedicated

Ba lưu ý về Dedicated Host: | Lưu ý | Chi tiết | |---|---| | Trả tiền theo HOST, không theo instance | | | Thấy được số socket và core vật lý | | | Host Resource Group tự quản host | |

⚠ License Manager quản giấy phép trên Dedicated Host:

aws license-manager create-license-configuration \
  --name giay-phep-oracle \
  --license-counting-type Core \
  --license-count 32 --license-count-hard-limit

Đếm số core đã dùng
        ↓
    Chặn khởi động khi vượt số
      giấy phép

Ba lưu ý về chi phí dedicated: | Khoản | Ghi chú | |---|---| | Phí per-Region | ~2 USD/giờ, tính một lần | | Giá instance cao hơn | khoảng 10% | | Reserved Instance áp được | có, cho dedicated |

Ba lưu ý về placement: | Chiến lược | Mục đích | |---|---| | Cluster | độ trễ mạng thấp nhất, cùng rack | | Spread | mỗi instance một phần cứng riêng | | Partition | nhóm instance trên các phần cứng tách biệt |

⚠ Spread placement group cũng cho cách ly phần cứng:

Spread: mỗi instance trên một
  máy chủ vật lý riêng
        ↓
    Nhưng máy chủ đó vẫn CHIA SẺ
      với tài khoản khác
        ↓
    Khác hẳn dedicated tenancy

Ba lưu ý về launch template: | Lưu ý | Chi tiết | |---|---| | Launch template thay thế launch configuration | | | Có phiên bản, quay lui được | | | Hỗ trợ nhiều tính năng mới mà LC không có | |

⚠ Launch configuration đã ngừng nhận tạo mới:

Từ tháng 12/2023, không tạo được
  launch configuration mới
        ↓
    Cái đã có vẫn chạy
        ↓
    Chuyển sang launch template

Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | Config rule kiểm tenancy của instance | | | SCP chặn khởi động instance không dedicated | | | Ghi rõ yêu cầu tenancy trong tài liệu kiến trúc | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | describe-instances xem Placement.Tenancy | | | Kiểm hoá đơn có dòng phí dedicated per-Region | | | Xem describe-vpcs biết tenancy của VPC | |

Và một lời khuyên: hãy đặt tenancy ở cấp launch template chứ đừng đặt ở cấp VPC trừ khi thật sự muốn mọi thứ trong VPC đó là dedicated. Tenancy của VPC không đổi ngược lại được và nó âm thầm áp cho mọi tài nguyên khởi động về sau — kể cả những thứ bạn không định trả giá dedicated cho chúng.

Đáp án

**A — Dùng Amazon Aurora Global Database để cho phép đọc cục bộ nhanh với độ trễ thấp ở từng Region.

Vì sao đúng

Đề nêu ba ràng buộc, và Aurora Global Database khớp cả ba: | Ràng buộc | Cách đáp ứng | |---|---| | Không đổi schema quan hệ hiện có | Aurora tương thích MySQL | | Hoạt động ở quy mô toàn cầu | replica ở tối đa 5 Region phụ | | Hiệu quả chi phí và hiệu năng cao | replica chỉ đọc, độ trễ dưới giây |

⚠ Điểm mấu chốt: "không rời khỏi schema quan hệ" loại DynamoDB ngay:

DynamoDB là NoSQL khoá-giá trị
        ↓
    Không có JOIN, không có giao dịch
      nhiều bảng theo kiểu SQL
        ↓
    Chuyển sang nó = viết lại toàn
      bộ tầng dữ liệu
    → trái với ràng buộc của đề

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

⚠ Và Aurora Global Database khác read replica liên Region thông thường: | Tiêu chí | Aurora Global Database | RDS cross-Region replica | |---|---|---| | Cơ chế sao chép | tầng lưu trữ, chuyên dụng | phát lại log giao dịch | | Độ trễ điển hình | dưới 1 giây | giây tới phút | | Ảnh hưởng hiệu năng writer | rất ít | có | | Chuyển đổi Region | dưới 1 phút | promote thủ công, lâu hơn | | Số Region phụ | tối đa 5 | tuỳ hạn ngạch replica |

Sao chép ở tầng LƯU TRỮ, không
  qua engine CSDL
        ↓
    Writer không phải làm thêm việc
    → khác hẳn sao chép logic

Tạo global database:

aws rds create-global-cluster \
  --global-cluster-identifier cum-toan-cau \
  --source-db-cluster-identifier <arn-cum-chinh>

aws rds create-db-cluster \
  --db-cluster-identifier cum-eu \
  --global-cluster-identifier cum-toan-cau \
  --engine aurora-mysql --region eu-west-1

aws rds create-db-instance \
  --db-instance-identifier cum-eu-reader-1 \
  --db-cluster-identifier cum-eu \
  --db-instance-class db.r6g.xlarge \
  --engine aurora-mysql --region eu-west-1

⚠ Và đây là lý do "cost-effective" — Region phụ chỉ cần một instance nhỏ:

Region phụ có thể chạy với đúng
  MỘT instance
        ↓
    Hoặc thậm chí KHÔNG instance nào
      (headless)
        ↓
    Vẫn nhận sao chép, chỉ trả tiền
      lưu trữ
    → dựng instance khi cần

⚠ Cụm headless là mẫu tiết kiệm đáng biết:

Region phụ chỉ để khôi phục thảm hoạ
        ↓
    Không cần phục vụ đọc hằng ngày
        ↓
    Không tạo instance nào trong đó
    → chỉ trả phí lưu trữ và sao chép
        ↓
    Khi cần: tạo instance trong
      vài phút

⚠ Và write forwarding cho phép Region phụ nhận cả lệnh ghi:

aws rds modify-db-cluster \
  --db-cluster-identifier cum-eu \
  --enable-global-write-forwarding

Ứng dụng ở châu Âu ghi vào cụm eu
        ↓
    Aurora chuyển tiếp lệnh ghi về
      Region chính
        ↓
    Ứng dụng chỉ cần một endpoint
    → nhưng lệnh ghi vẫn chịu độ
      trễ liên Region

⚠ Và vì sao phương án B sai — tự dựng MySQL trên EC2:

Tự cài MySQL ở mỗi Region
        ↓
    Tự cấu hình sao chép, tự vá,
      tự sao lưu, tự làm HA
        ↓
    Đề nói "urgent basis"
    → và "cost-effective"
        ↓
    Chi phí vận hành lớn nhất

⚠ Và vì sao phương án D sai — Redshift là kho phân tích:

Redshift tối ưu cho truy vấn tổng
  hợp trên dữ liệu lớn
        ↓
    Không phải CSDL giao dịch
    → không thay được MySQL cho
      ứng dụng
        ↓
    Và cụm ở mỗi Region là chi phí
      rất lớn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Đọc cục bộ với độ trễ thấp ở mỗi Region | | | Không đổi schema hay mã ứng dụng | | | Region phụ chạy tối thiểu, chi phí thấp | |

⚠ Và có một lợi ích phụ về khôi phục thảm hoạ:

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

RPO thường dưới 1 giây
        ↓
    RTO dưới 1 phút
        ↓
    Đạt được mức đó bằng RDS thường
      là rất khó

⚠ Nhưng ứng dụng phải tách endpoint đọc và ghi:

Ghi → cụm chính (hoặc write
  forwarding)
        ↓
    Đọc → reader endpoint của cụm
      địa phương
        ↓
    Không tách: mọi truy vấn vẫn
      về Region chính
    → không có lợi ích gì

⚠ Và ElastiCache là lớp bổ trợ đáng thêm:

Aurora Global Database giảm độ trễ
  xuống mili giây
        ↓
    ElastiCache ở mỗi Region đưa
      xuống dưới mili giây
        ↓
    Và giảm hẳn số truy vấn tới CSDL

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

• **C. Dùng DynamoDB Global Tables cho hiệu năng đọc và ghi cục bộ ở mỗi Region — đây là phương án gần nhất và thật sự cho hiệu năng liên Region tốt nhất, kể cả ghi, nhưng đề nói rõ không được rời khỏi schema quan hệ hiện có, mà chuyển sang DynamoDB là viết lại toàn bộ tầng dữ liệu.
• **B. Dựng EC2 cài MySQL ở mỗi Region và di trú dữ liệu — chi phí vận hành lớn nhất, phải tự cấu hình sao chép và sẵn sàng cao.
• **D. Dựng cụm Redshift ở mỗi Region — Redshift là kho dữ liệu phân tích, không thay được CSDL giao dịch.

Ghi nhớ

⚠ Bốn cách mở rộng CSDL ra toàn cầu — bảng phải thuộc: | Cách | Ghi ở đâu | Schema | |---|---|---| | Aurora Global Database | một Region chính | quan hệ | | DynamoDB Global Tables | MỌI Region | NoSQL | | RDS cross-Region replica | một Region chính | quan hệ | | Tự dựng sao chép | tuỳ cấu hình | tuỳ |

Từ khoá nhận diện:

"keep relational schema, global low-latency reads" → Aurora Global Database "active-active writes in every Region" → DynamoDB Global Tables "analytics across Regions" → Redshift, không phải CSDL giao dịch "RPO under 1 second, RTO under 1 minute" → Aurora Global Database

Ba lưu ý về Aurora Global Database: | Lưu ý | Chi tiết | |---|---| | Tối đa 5 Region phụ | | | Mỗi Region phụ tối đa 16 reader | | | Sao chép ở tầng lưu trữ, không tốn CPU của writer | |

⚠ Và có AuroraGlobalDBReplicationLag để theo dõi:

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name AuroraGlobalDBReplicationLag \
  --dimensions Name=DBClusterIdentifier,Value=cum-eu \
  --statistics Maximum --period 60 \
  --start-time 2026-09-01T00:00:00Z --end-time 2026-09-01T01:00:00Z

Ba lưu ý về write forwarding: | Lưu ý | Chi tiết | |---|---| | Chỉ có với Aurora MySQL | | | Lệnh ghi vẫn chịu độ trễ liên Region | | | Đặt mức nhất quán đọc-sau-ghi được | |

SET aurora_replica_read_consistency = 'SESSION';

EVENTUAL: nhanh nhất, có thể đọc
  dữ liệu cũ
        ↓
    SESSION: thấy được lệnh ghi
      của chính phiên mình
        ↓
    GLOBAL: thấy mọi lệnh ghi đã
      xác nhận — chậm nhất

Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Instance ở mỗi Region | có thể chạy tối thiểu hoặc headless | | Lưu trữ nhân theo Region | mỗi Region một bản | | Sao chép liên Region | theo triệu thao tác I/O |

Ba lưu ý về chuyển đổi: | Loại | Đặc điểm | |---|---| | Planned failover | có kế hoạch, không mất dữ liệu | | Unplanned (detach and promote) | khi Region chính không truy cập được |

⚠ Chuyển đổi ngoài kế hoạch phức tạp hơn:

Region chính không phản hồi
        ↓
    Tách cụm phụ khỏi global cluster
        ↓
    Promote thành cụm độc lập
        ↓
    Sau khi Region chính hồi phục,
      phải dựng lại quan hệ

Ba lưu ý về ứng dụng: | Lưu ý | Chi tiết | |---|---| | Tách chuỗi kết nối đọc và ghi | | | Route 53 latency routing tới endpoint gần nhất | | | Xử lý được trường hợp đọc dữ liệu hơi cũ | |

Ba lưu ý về ElastiCache bổ trợ: | Lưu ý | Chi tiết | |---|---| | Một cụm ở mỗi Region | | | Cache-aside với TTL | | | Vô hiệu hoá cache khi dữ liệu đổi | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ truy vấn từ mỗi Region | | | Theo dõi AuroraGlobalDBReplicationLag | | | Thử chuyển đổi có kế hoạch trên môi trường thử | |

Và một lời khuyên: hãy kiểm tra ứng dụng có thật sự dùng reader endpoint địa phương hay không sau khi dựng Global Database. Nếu chuỗi kết nối vẫn trỏ về Region chính thì bạn đang trả tiền cho các cụm phụ mà mọi truy vấn vẫn đi nửa vòng trái đất.

Đáp án

**A — Sao lưu vào một bucket S3 dùng lớp S3 Standard ở Region sản xuất; bật sao chép liên Region sang một bucket S3 cũng dùng S3 Standard ở Region dự phòng; và đặt luật vòng đời ở Region dự phòng chuyển ngay sang Glacier.

Vì sao đúng

Đề cho hai mục tiêu khôi phục khác nhau cho hai Region: | Region | Yêu cầu | Lớp lưu trữ | |---|---|---| | Sản xuất | khôi phục NGAY LẬP TỨC | S3 Standard | | Dự phòng | khôi phục trong 24 giờ | Glacier |

⚠ Điểm mấu chốt: hai Region có yêu cầu khác nhau nên dùng lớp khác nhau:

"Available to be restored
  IMMEDIATELY" ở Region sản xuất
        ↓
    Glacier không đọc ngay được
    → phải Standard hoặc Standard-IA
        ↓
    "Within 24 hours" ở Region dự
      phòng
    → Glacier hoàn toàn đủ, và rẻ
      hơn nhiều

⚠ Và vì sao phương án B sai — chi tiết rất nhỏ nhưng quyết định:

B sao chép sang bucket dùng lớp
  STANDARD-IA ở Region dự phòng
        ↓
    Rồi luật vòng đời chuyển NGAY
      sang Glacier
        ↓
    Standard-IA có phí tối thiểu
      30 NGÀY
    → chuyển đi sau 1 ngày vẫn trả
      đủ 30 ngày

⚠ Đây là bảng phí tối thiểu phải thuộc: | Lớp | Thời gian tối thiểu | |---|---| | Standard | KHÔNG có | | Standard-IA / One Zone-IA | 30 ngày | | Glacier Instant Retrieval | 90 ngày | | Glacier Flexible Retrieval | 90 ngày | | Glacier Deep Archive | 180 ngày |

Đi qua Standard-IA rồi chuyển ngay
        ↓
    Trả tiền Standard-IA đủ 30 ngày
    + tiền Glacier từ ngày 1
        ↓
    Đắt hơn đi thẳng từ Standard

⚠ Và Standard không có phí tối thiểu — nên đi thẳng từ đó rẻ hơn:

Standard → Glacier sau 1 ngày
        ↓
    Trả 1 ngày Standard + Glacier
      từ ngày 2
        ↓
    Không có khoản phạt nào

Cấu hình sao chép liên Region:

aws s3api put-bucket-replication --bucket sao-luu-san-xuat \
  --replication-configuration '{
    "Role": "arn:aws:iam::111122223333:role/S3Replication",
    "Rules": [{
      "ID": "sang-region-du-phong",
      "Status": "Enabled", "Priority": 1,
      "Filter": {},
      "DeleteMarkerReplication": {"Status": "Disabled"},
      "Destination": {
        "Bucket": "arn:aws:s3:::sao-luu-du-phong",
        "StorageClass": "STANDARD"}}]}'

Luật vòng đời ở Region dự phòng:

{"Rules": [{
  "ID": "sang-glacier-ngay",
  "Filter": {},
  "Status": "Enabled",
  "Transitions": [{"Days": 0, "StorageClass": "GLACIER"}]}]}

⚠ Days: 0 chuyển ngay trong ngày đầu — hợp lệ với Glacier:

Glacier không có ràng buộc chờ
  30 ngày như IA
        ↓
    Chuyển từ Standard sang Glacier
      ngay được

⚠ Và CRR có thể đặt lớp lưu trữ đích trực tiếp:

"Destination": {"StorageClass": "GLACIER"}

Bỏ được cả bước vòng đời
        ↓
    Object tới Region dự phòng là
      đã ở Glacier
        ↓
    Nhưng đề đưa ra phương án có
      vòng đời — cả hai đều đúng
      về kết quả

⚠ Và vì sao phương án D sai:

D nói "cross-Region replication
  của dữ liệu trong GLACIER"
        ↓
    CRR sao chép giữa hai BUCKET S3
        ↓
    Object ở lớp Glacier KHÔNG sao
      chép được bằng CRR
    → phải sao chép rồi mới chuyển
      tầng

Và Glacier ở Region sản xuất vi
  phạm yêu cầu "khôi phục ngay"

⚠ Và vì sao phương án C sai:

C dùng EBS volume lớn gắn vào máy
  chủ sao lưu
        ↓
    Rồi cron chụp snapshot và chép
      sang Region khác
        ↓
    Phải vận hành một máy chủ
    → và EBS đắt hơn S3 nhiều lần
        ↓
    Đề nói "hoàn toàn tự động"
    → cron trên một máy là điểm
      hỏng đơn lẻ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Khôi phục ngay ở Region sản xuất | | | Chi phí thấp nhất ở Region dự phòng | | | Hoàn toàn tự động, không có script nào | |

⚠ Và CRR chỉ sao chép object MỚI — điểm phải nhớ:

Bật CRR hôm nay
        ↓
    Object đã có KHÔNG được sao chép
        ↓
    Dùng S3 Batch Replication cho
      dữ liệu cũ

aws s3control create-job --account-id 111122223333 \
  --operation '{"S3ReplicateObject": {}}' \
  --manifest-generator '{"S3JobManifestGenerator": {
    "SourceBucket": "arn:aws:s3:::sao-luu-san-xuat",
    "Filter": {"ObjectReplicationStatuses": ["NONE"]}}}' \
  --role-arn <arn-role> --priority 10 --no-confirmation-required

⚠ Và CRR bắt buộc bật versioning ở cả hai bucket:

Thiếu versioning → không bật được
  replication
        ↓
    Và versioning cũng chống xoá
      nhầm bản sao lưu
        ↓
    Nhớ đặt luật dọn phiên bản cũ

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

• **B. Sao chép sang bucket dùng S3 Standard-IA ở Region dự phòng rồi vòng đời chuyển ngay sang Glacier — đây là phương án gần nhất và kiến trúc hoàn toàn đúng, nhưng Standard-IA có phí lưu trữ tối thiểu 30 ngày, nên việc đi qua nó rồi chuyển ngay sẽ tốn thêm mà không được gì.
• **D. Sao lưu thẳng vào Glacier ở Region sản xuất và sao chép liên Region sang Glacier — vi phạm yêu cầu khôi phục ngay ở Region sản xuất; và CRR không sao chép object đã ở lớp Glacier.
• **C. Sao lưu vào EBS volume và cron chụp snapshot rồi chép liên Region — phải vận hành máy chủ, EBS đắt hơn nhiều, và cron là điểm hỏng đơn lẻ.

Ghi nhớ

⚠ Chọn lớp lưu trữ theo thời gian khôi phục — bảng phải thuộc: | Yêu cầu | Lớp | |---|---| | Ngay lập tức, đọc thường xuyên | Standard | | Ngay lập tức, ít đọc | Standard-IA hoặc Glacier Instant Retrieval | | Trong vài giờ | Glacier Flexible Retrieval | | Trong 12-48 giờ | Glacier Deep Archive |

Từ khoá nhận diện:

"restore immediately" → Standard hoặc Instant Retrieval "restore within 24 hours" → Glacier Flexible Retrieval "two geographically distinct Regions" → Cross-Region Replication "fully automated" → CRR + lifecycle, không phải cron

Ba lưu ý về CRR: | Lưu ý | Chi tiết | |---|---| | Cần versioning ở cả hai bucket | | | Chỉ sao chép object mới sau khi bật | | | Batch Replication cho object cũ | |

⚠ RTC cho SLA về thời gian sao chép:

"ReplicationTime": {"Status": "Enabled",
                    "Time": {"Minutes": 15}},
"Metrics": {"Status": "Enabled",
            "EventThreshold": {"Minutes": 15}}

99,99% object sao chép trong
  15 phút
        ↓
    Có SLA và chỉ số CloudWatch
    → tính phí thêm

Ba lưu ý về tốc độ lấy ra Glacier: | Tốc độ | Thời gian | Giá | |---|---|---| | Expedited | 1-5 phút | đắt nhất | | Standard | 3-5 giờ | trung bình | | Bulk | 5-12 giờ | rẻ nhất |

Hạn 24 giờ → Bulk là đủ
    → và rẻ nhất

Ba lưu ý về phí chuyển tầng: | Lưu ý | Chi tiết | |---|---| | Tính theo SỐ OBJECT, không theo GB | | | Nhiều tệp nhỏ thì phí chuyển lớn | | | Gom lại trước khi chuyển tầng | |

Ba lưu ý về AWS Backup: | Lưu ý | Chi tiết | |---|---| | Quản lý sao lưu tập trung nhiều dịch vụ | | | Sao chép liên Region theo chính sách | | | Vault Lock chống xoá (WORM) | |

⚠ AWS Backup là lựa chọn gọn hơn cho sao lưu nhiều dịch vụ:

aws backup create-backup-plan --backup-plan '{
  "BackupPlanName": "hang-dem",
  "Rules": [{
    "RuleName": "sao-luu-dem",
    "ScheduleExpression": "cron(0 2 * * ? *)",
    "TargetBackupVaultName": "kho-chinh",
    "Lifecycle": {"MoveToColdStorageAfterDays": 1,
                  "DeleteAfterDays": 365},
    "CopyActions": [{
      "DestinationBackupVaultArn": "<arn-kho-du-phong>",
      "Lifecycle": {"MoveToColdStorageAfterDays": 1}}]}]}'

Ba lưu ý về kiểm thử khôi phục: | Lưu ý | Chi tiết | |---|---| | Bản sao lưu chưa thử khôi phục là chưa chắc dùng được | | | Đo thời gian thật để biết RTO thật | | | Thử cả ở Region dự phòng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm object ở Region dự phòng đã ở lớp Glacier | | | Khôi phục thử một tệp và bấm giờ | | | Xem ReplicationLatency trong CloudWatch | |

Và một lời khuyên: hãy kiểm tra phí lưu trữ tối thiểu trước khi thiết kế chuỗi chuyển tầng. Một luật vòng đời đi qua Standard-IA rồi chuyển ngay sang Glacier trông có vẻ tiết kiệm hơn nhưng thực tế đắt hơn — vì bạn vẫn phải trả đủ 30 ngày cho một lớp mà dữ liệu chỉ ở đó một ngày.

Đáp án

**B và C — Dùng CloudFront distribution với origin là bucket S3, và bật S3 Transfer Acceleration cho bucket.

Vì sao đúng

Đề nêu hai chiều dữ liệu và cả hai đều chậm:

Nhân viên ở nhiều quốc gia
        ↓
    TẢI LÊN video 100 MB: chậm
    TẢI XUỐNG video: chậm
        ↓
    Cần cải thiện CẢ HAI CHIỀU

⚠ Điểm mấu chốt: hai đáp án phục vụ hai chiều khác nhau: | Đáp án | Cải thiện chủ yếu | |---|---| | CloudFront | TẢI XUỐNG (cache ở biên) | | Transfer Acceleration | TẢI LÊN (đường đi qua mạng AWS) |

⚠ Và CloudFront giúp tải xuống nhờ cache:

Video 100 MB được nhiều người xem
        ↓
    Lần đầu: kéo từ S3 về điểm biên
        ↓
    Lần sau: phục vụ ngay từ biên
    → nhanh hơn rất nhiều

⚠ Nhưng CloudFront cũng giúp cho lần tải đầu tiên:

Ngay cả khi cache miss
        ↓
    Client → điểm biên gần nhất
      (đường ngắn)
        ↓
    Điểm biên → S3 trên mạng xương
      sống AWS
    → ổn định hơn Internet công cộng

⚠ Và Transfer Acceleration dùng chính mạng biên đó cho chiều lên:

Client tải lên → điểm biên gần nhất
        ↓
    Điểm biên → bucket trên mạng
      AWS
        ↓
    Cải thiện rõ nhất khi client ở
      xa Region của bucket

Bật Transfer Acceleration:

aws s3api put-bucket-accelerate-configuration \
  --bucket tai-nguyen-san-pham \
  --accelerate-configuration Status=Enabled

import boto3
from botocore.config import Config
s3 = boto3.client('s3', config=Config(
    s3={'use_accelerate_endpoint': True}))

⚠ Và CloudFront có thể dùng cho cả tải lên:

"AllowedMethods": {"Quantity": 7,
  "Items": ["GET","HEAD","OPTIONS","PUT","POST","PATCH","DELETE"]}

CloudFront chuyển tiếp PUT tới
  origin
        ↓
    Kết nối TLS kết thúc ở biên
    → phần còn lại trên mạng AWS
        ↓
    Nên đáp án B nói đúng: nó tăng
      tốc cả hai chiều

⚠ Và vì sao phương án A sai — bucket ở mỗi Region:

Mỗi văn phòng một bucket riêng
        ↓
    Không còn kho TẬP TRUNG
        ↓
    Đề nói rõ "centralized storage"
    → và người ở văn phòng A không
      tìm thấy tệp của văn phòng B

⚠ Và nếu muốn nhiều bucket thì phải đồng bộ — phức tạp hơn nhiều:

Multi-Region Access Point là cách
  đúng nếu thật sự cần nhiều bucket
        ↓
    Một endpoint toàn cầu
    → tự định tuyến tới bucket gần
      nhất
        ↓
    Nhưng vẫn cần CRR để đồng bộ

⚠ Và vì sao phương án D sai:

D chuyển dữ liệu sang EFS và truy
  cập liên Region qua VPC peering
        ↓
    EFS là dịch vụ THEO REGION
        ↓
    Truy cập từ Region khác qua
      peering: độ trễ NFS rất cao
        ↓
    Và đề nói muốn giữ giải pháp
      serverless
    → EFS cần EC2 để mount

⚠ Và vì sao phương án E sai:

E dựng EC2 ở mỗi Region và chép
  dữ liệu vào EBS hằng ngày
        ↓
    Không còn serverless
        ↓
    Dữ liệu trễ tới một ngày
        ↓
    Và phải quản lý đồng bộ hai chiều

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cải thiện cả tải lên lẫn tải xuống | | | Giữ nguyên một kho tập trung | | | Không thêm máy chủ nào | |

⚠ Và multipart upload nên bật kèm cho tệp 100 MB:

from boto3.s3.transfer import TransferConfig
cau_hinh = TransferConfig(
    multipart_threshold=16*1024*1024,
    max_concurrency=10,
    multipart_chunksize=16*1024*1024)
s3.upload_file('video.mp4', KHO, 'video.mp4', Config=cau_hinh)

Chia thành nhiều phần tải song song
        ↓
    Vượt qua giới hạn của một luồng
      TCP đường dài
    → thường cải thiện nhiều hơn
      cả Transfer Acceleration

⚠ Và Transfer Acceleration chỉ tính phí khi thật sự nhanh hơn:

AWS so tốc độ qua biên với đi thẳng
        ↓
    Không nhanh hơn → không tính
      phí tăng tốc
        ↓
    Nên bật nó gần như không có
      rủi ro về chi phí

⚠ Và nên đo trước bằng công cụ của AWS:

https://s3-accelerate-speedtest.s3-accelerate.amazonaws.com/
  en/accelerate-speed-comparsion.html

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

• **A. Tạo bucket S3 ở mỗi Region có văn phòng để mỗi nơi tự quản kho của mình — đây là phương án gần nhất và thật sự giảm độ trễ cho từng văn phòng, nhưng nó phá vỡ yêu cầu kho tập trung và không có cơ chế đồng bộ nào giữa các bucket.
• **D. Chuyển dữ liệu sang EFS và truy cập liên Region qua VPC peering — EFS là dịch vụ theo Region, truy cập liên Region có độ trễ NFS rất cao, và nó cần EC2 để mount nên không còn serverless.
• **E. Dựng EC2 ở mỗi Region và chép dữ liệu vào EBS hằng ngày — không còn serverless, dữ liệu trễ một ngày, và phải tự quản đồng bộ.

Ghi nhớ

⚠ Bốn cách tăng tốc truy cập S3 toàn cầu — bảng phải thuộc: | Cách | Chiều nào | |---|---| | CloudFront | chủ yếu tải xuống (có cache) | | Transfer Acceleration | chủ yếu tải lên | | Multipart upload song song | tải lên | | Multi-Region Access Point | cả hai, cần nhiều bucket |

Từ khoá nhận diện:

"slow uploads and downloads globally" → CloudFront + S3TA "centralized storage, keep serverless" → giữ một bucket "buckets in multiple Regions" → Multi-Region Access Point + CRR "large file uploads" → multipart song song

Ba lưu ý về Transfer Acceleration: | Lưu ý | Chi tiết | |---|---| | Tên bucket không được có dấu chấm | | | Endpoint riêng s3-accelerate | | | Chỉ tính phí khi thật sự nhanh hơn | |

Ba lưu ý về CloudFront cho S3: | Lưu ý | Chi tiết | |---|---| | OAC để bucket riêng tư | | | Cache policy quyết định TTL | | | Cho phép PUT nếu cần tải lên qua CDN | |

⚠ Cache video lớn cần chú ý TTL:

Video hiếm khi đổi
        ↓
    Đặt TTL rất dài
        ↓
    Đổi nội dung → đổi tên tệp
    → không cần invalidate

Ba lưu ý về Multi-Region Access Point: | Lưu ý | Chi tiết | |---|---| | Một endpoint toàn cầu | | | Tự định tuyến tới bucket gần nhất | | | Cần CRR để đồng bộ giữa các bucket | |

⚠ MRAP có chế độ active-active:

aws s3control create-multi-region-access-point \
  --account-id 111122223333 \
  --details '{"Name": "kho-toan-cau",
    "Regions": [{"Bucket": "kho-apse1"},
                {"Bucket": "kho-euw1"},
                {"Bucket": "kho-use1"}]}'

Ghi ở bất kỳ đâu, CRR đồng bộ
        ↓
    Nhưng xung đột giải quyết theo
      "last writer wins"

Ba lưu ý về multipart: | Lưu ý | Chi tiết | |---|---| | Bắt buộc trên 5 GB | | | Khuyến nghị từ 100 MB | | | Đặt luật dọn phần dở dang | |

Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Truyền vào S3 | miễn phí | | S3 → CloudFront | miễn phí | | CloudFront → Internet | rẻ hơn S3 → Internet | | S3TA | chỉ khi thật sự nhanh hơn |

Ba lưu ý về đo lường: | Việc | Cách | |---|---| | Đo từ nhiều khu vực | CloudWatch Synthetics | | Tỷ lệ cache hit | chỉ số CloudFront | | So tốc độ có và không có S3TA | công cụ của AWS |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải lên một tệp 100 MB từ mỗi văn phòng, bấm giờ | | | Kiểm header X-Cache khi tải xuống | | | Xem hoá đơn có dòng phí S3TA không | |

Và một lời khuyên: hãy bật multipart upload song song trước khi tính tới Transfer Acceleration. Với tệp 100 MB, phần lớn cải thiện thường đến từ việc chia nhỏ và tải nhiều luồng cùng lúc — và đó là thay đổi ở phía client, không phát sinh chi phí nào.

Đáp án

**D — Dùng SQS FIFO queue ở chế độ batch với 8 tin nhắn mỗi thao tác để xử lý ở mức đỉnh.

Vì sao đúng

Đề cho hai ràng buộc, và chúng dẫn tới một phép tính duy nhất:

Thứ tự xử lý PHẢI đúng thứ tự nhận
        ↓
    → BẮT BUỘC dùng FIFO queue
        ↓
    Đỉnh 2.400 tin nhắn mỗi giây
        ↓
    → phải tính batch size

⚠ Điểm mấu chốt: FIFO queue có giới hạn 300 THAO TÁC mỗi giây:

300 lời gọi API mỗi giây cho mỗi
  hành động
  (SendMessage, ReceiveMessage,
   DeleteMessage)
        ↓
    Không dùng batch: 300 tin/giây
        ↓
    Dùng batch: 300 × số tin mỗi lô

Tính batch size cần:

2.400 tin/giây ÷ 300 thao tác/giây
        ↓
    = 8 tin mỗi thao tác

⚠ Và đây là lý do ba phương án còn lại sai: | Phương án | Batch | Thông lượng | Kết quả | |---|---|---|---| | A | 4 | 300 × 4 = 1.200 | KHÔNG đủ | | D | 8 | 300 × 8 = 2.400 | vừa đủ | | C | 12 | vượt giới hạn 10 | KHÔNG hợp lệ |

⚠ Batch tối đa của SQS là 10 — con số cứng:

`SendMessageBatch` nhận tối đa
  10 tin
        ↓
    `ReceiveMessage` trả tối đa
      10 tin
        ↓
    12 tin mỗi thao tác là không
      thể

Đây là lý do phương án C sai — nó mô tả một cấu hình không tồn tại.

⚠ Và vì sao phương án B sai — Standard queue không giữ thứ tự:

SQS Standard: thông lượng gần như
  không giới hạn
        ↓
    Nhưng thứ tự KHÔNG bảo đảm
        ↓
    Đề nói rõ "messages processed
      in the order they are received"
    → Standard bị loại

Gửi theo lô:

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

def gui_lo(danh_sach_lenh):
    for i in range(0, len(danh_sach_lenh), 8):
        lo = danh_sach_lenh[i:i+8]
        sqs.send_message_batch(
            QueueUrl=URL_HANG_DOI,
            Entries=[{
                'Id': str(j),
                'MessageBody': json.dumps(lenh),
                'MessageGroupId': lenh['ma_chung_khoan'],
                'MessageDeduplicationId': lenh['ma_lenh']}
                for j, lenh in enumerate(lo)])

⚠ MessageGroupId là chi tiết quyết định hiệu năng FIFO:

Thứ tự chỉ bảo đảm TRONG một nhóm
        ↓
    Nhóm khác nhau xử lý SONG SONG
        ↓
    Dùng mã chứng khoán làm nhóm
    → lệnh cùng một mã đúng thứ tự
    → mã khác nhau chạy song song

⚠ Và nếu dùng một nhóm duy nhất thì thông lượng sụt thảm hại:

Mọi tin cùng `MessageGroupId`
        ↓
    Chỉ MỘT consumer xử lý được
      tại một thời điểm
        ↓
    Thông lượng thực tế rất thấp
    → dù giới hạn API vẫn là 300/giây

⚠ Và MessageDeduplicationId chống trùng trong 5 phút:

Gửi cùng một deduplication ID
  hai lần trong 5 phút
        ↓
    Lần thứ hai bị BỎ QUA im lặng
        ↓
    Hữu ích khi client thử lại
    → nhưng phải chọn ID cẩn thận

⚠ Hoặc bật khử trùng lặp theo nội dung:

aws sqs create-queue --queue-name lenh-giao-dich.fifo \
  --attributes '{
    "FifoQueue": "true",
    "ContentBasedDeduplication": "true",
    "VisibilityTimeout": "60"}'

⚠ Và tên hàng đợi FIFO BẮT BUỘC kết thúc bằng .fifo:

Thiếu hậu tố → tạo hàng đợi thất bại
        ↓
    Chi tiết nhỏ nhưng vấp thường xuyên

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Thứ tự bảo đảm trong từng mã chứng khoán | | | Batch giảm 8 lần số lời gọi API | | | Và giảm chi phí theo tỷ lệ đó | |

⚠ Và batch giảm chi phí đáng kể:

SQS tính tiền theo YÊU CẦU
        ↓
    Batch 8 tin = 1 yêu cầu
        ↓
    Giảm 8 lần chi phí API
    → và giảm cả độ trễ mạng

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

⚠ Giới hạn 300 thao tác/giây là hạn ngạch MẶC ĐỊNH; FIFO có chế độ thông lượng cao.

aws sqs set-queue-attributes --queue-url <url> \
  --attributes '{
    "FifoThroughputLimit": "perMessageGroupId",
    "DeduplicationScope": "messageGroup"}'

High throughput FIFO ra mắt 2021
        ↓
    Với chế độ đó, 2.400 tin/giây
      không cần tính batch gì cả
        ↓
    Câu hỏi kiểm tra đúng phép tính
      với hạn ngạch mặc định — vẫn
      hợp lệ, nhưng không phản ánh
      lựa chọn hiện nay

Và điều kiện để bật chế độ thông lượng cao:

`FifoThroughputLimit`
  = perMessageGroupId
        ↓
    `DeduplicationScope` = messageGroup
        ↓
    Và phải có NHIỀU message group
    → một nhóm duy nhất vẫn chậm

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

• **A. FIFO queue với batch 4 tin mỗi thao tác — đây là phương án gần nhất và dùng đúng loại hàng đợi và đúng ý tưởng batch, nhưng 300 × 4 = 1.200 tin/giây, chỉ được một nửa mức đỉnh cần xử lý.
• **C. FIFO queue với batch 12 tin — SQS giới hạn batch tối đa 10 tin, nên cấu hình này không tồn tại.
• **B. Dùng SQS Standard queue — thông lượng dư sức nhưng không bảo đảm thứ tự, vi phạm yêu cầu.

Ghi nhớ

⚠ SQS Standard và FIFO — bảng phải thuộc: | Tiêu chí | Standard | FIFO | |---|---|---| | Thứ tự | không bảo đảm | bảo đảm trong nhóm | | Giao hàng | ít nhất một lần | CHÍNH XÁC một lần | | Thông lượng | gần như không giới hạn | 300 thao tác/giây (mặc định) | | Tên hàng đợi | tuỳ ý | phải kết thúc .fifo |

Từ khoá nhận diện:

"process in order received" → FIFO "exactly once processing" → FIFO "unlimited throughput" → Standard "N messages per second with FIFO" → chia cho 300 để ra batch size

⚠ Công thức tính batch size:

Batch size = tin mỗi giây ÷ 300
        ↓
    Làm tròn LÊN
        ↓
    Nếu vượt 10 → cần high
      throughput mode

Ba lưu ý về message group: | Lưu ý | Chi tiết | |---|---| | Bắt buộc với FIFO | | | Thứ tự chỉ trong cùng nhóm | | | Nhiều nhóm cho phép song song | |

⚠ Chọn message group là quyết định thiết kế quan trọng:

Nhóm quá ít → thông lượng thấp
        ↓
    Nhóm quá nhiều → mất ý nghĩa
      thứ tự
        ↓
    Chọn theo đơn vị nghiệp vụ cần
      thứ tự: mã chứng khoán, mã
      khách hàng, mã tài khoản

Ba lưu ý về khử trùng lặp: | Cách | Đặc điểm | |---|---| | MessageDeduplicationId | tự khai, kiểm soát chính xác | | ContentBasedDeduplication | hash SHA-256 của thân tin | | Cửa sổ 5 phút | cố định, không đổi được |

⚠ Khử trùng lặp theo nội dung có bẫy:

Hai lệnh giao dịch giống hệt nhau
  trong 5 phút
        ↓
    Lệnh thứ hai bị BỎ QUA
        ↓
    Với hệ thống giao dịch, đó có
      thể là lệnh hợp lệ
    → nên dùng ID riêng

Ba lưu ý về consumer FIFO: | Lưu ý | Chi tiết | |---|---| | Mỗi nhóm chỉ một consumer tại một thời điểm | | | Tin chưa xoá thì nhóm đó bị chặn | | | Xử lý chậm một tin làm kẹt cả nhóm | |

Ba lưu ý về Lambda với FIFO: | Lưu ý | Chi tiết | |---|---| | Lambda xử lý theo nhóm, giữ thứ tự | | | Số nhóm quyết định mức song song | | | Lỗi một tin chặn cả nhóm cho tới khi hết hạn | |

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | ApproximateAgeOfOldestMessage | có nhóm nào bị kẹt không | | NumberOfMessagesSent | thông lượng thật | | ApproximateNumberOfMessagesVisible | tồn đọng |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy thử ở 2.400 tin/giây | | | Kiểm không bị lỗi ThrottlingException | | | Xác nhận thứ tự trong từng nhóm đúng | |

Và một lời khuyên: hãy chọn MessageGroupId có độ phân tán cao ngay từ đầu. Thứ tự chỉ được bảo đảm trong một nhóm, nên một nhóm duy nhất cho toàn hệ thống sẽ biến hàng đợi FIFO thành một đường ống tuần tự — và không có phép tính batch nào cứu được điều đó.