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

Đáp án

**B và C — Dùng EC2 Instance Store làm tầng dịch vụ, và dùng Amazon EFS làm tầng dữ liệu.

Vì sao đúng

Đề mô tả hai tầng với hai yêu cầu hoàn toàn khác nhau: | Tầng | Yêu cầu | Dịch vụ | |---|---|---| | Dữ liệu | hệ tệp POSIX chia sẻ giữa nhiều máy | EFS | | Dịch vụ | lưu trữ khối, TRÊN MỘT TRIỆU IOPS | Instance Store |

⚠ Con số "trên một triệu IOPS" quyết định mọi thứ: | Loại lưu trữ | IOPS tối đa | |---|---| | gp3 | 16.000 | | io2 | 64.000 | | io2 Block Express | 256.000 | | Instance store NVMe | hàng TRIỆU |

io2 Block Express đạt 256.000
    → vẫn thấp hơn một triệu bốn lần
        ↓
    Chỉ NVMe gắn trực tiếp vào máy
      chủ vật lý mới vượt mốc đó

Đây là lý do phương án A (Provisioned IOPS EBS) sai.

⚠ Và instance store nhanh vì nó không đi qua mạng:

EBS là lưu trữ qua MẠNG
    → mọi thao tác I/O đi qua
      hạ tầng mạng
        ↓
    Instance store: NVMe cắm thẳng
      vào máy chủ vật lý
    → độ trễ micro giây

Xem đĩa instance store:

lsblk
# nvme1n1  1.7T  disk
sudo mkfs -t xfs /dev/nvme1n1
sudo mount /dev/nvme1n1 /du-lieu-nhanh

⚠ Và EFS là lựa chọn duy nhất cho "POSIX chia sẻ giữa nhiều máy": | Kho | POSIX | Nhiều máy cùng mount | |---|---|---| | EFS | CÓ | CÓ | | S3 | KHÔNG (object) | có, nhưng không phải hệ tệp | | EBS | CÓ | một máy (trừ Multi-Attach) | | Instance store | CÓ | KHÔNG |

S3 không phải hệ tệp POSIX
    → không có khoá tệp, không có
      quyền POSIX, không ghi đè
      một phần tệp
        ↓
    Đây là lý do phương án E sai

Mount EFS trên nhiều instance:

sudo mount -t efs -o tls fs-0abc123:/ /du-lieu-chung

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

D dùng instance store làm tầng
  DỮ LIỆU
        ↓
    Instance store gắn với MỘT máy
    → không chia sẻ được
        ↓
    Và mất dữ liệu khi máy dừng

⚠ Đây là đặc tính quan trọng nhất của instance store:

Dừng instance → MẤT dữ liệu
Chấm dứt instance → MẤT dữ liệu
Máy chủ vật lý hỏng → MẤT dữ liệu
        ↓
    Khởi động lại (reboot) thì còn
        ↓
    Đây là bộ nhớ TẠM, không phải
      lưu trữ bền vững

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | IOPS cao nhất có thể trên AWS | | | Instance store không tính phí riêng | | | EFS tự co giãn dung lượng | |

⚠ Và instance store đi kèm giá instance:

Không có khoản phí lưu trữ riêng
    → i4i, i3, im4gn... đã tính
      NVMe vào giá
        ↓
    So với io2 Block Express:
      trả tiền cho từng IOPS đã cấp
    → instance store rẻ hơn nhiều
      ở mức IOPS cực cao

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

⚠ Đề nói tầng dịch vụ chứa "nội dung tệp tĩnh" — mà instance store thì mất dữ liệu khi máy dừng.

"Static file content" nghe như dữ
  liệu cần giữ lại
        ↓
    Instance store không giữ được
        ↓
    Phải có nguồn gốc ở nơi khác
      (S3 hoặc EFS)
    → và chép vào instance store
      lúc khởi động

Mẫu dùng đúng là:

Nguồn gốc: S3
        ↓
    User data chép vào instance
      store lúc khởi động
        ↓
    Ứng dụng đọc từ NVMe cục bộ
    → tốc độ tối đa
        ↓
    Máy chết: dựng máy mới, chép lại

#!/bin/bash
mkfs -t xfs /dev/nvme1n1
mkdir -p /noi-dung && mount /dev/nvme1n1 /noi-dung
aws s3 sync s3://noi-dung-goc/ /noi-dung/

Và "một triệu IOPS" là con số rất bất thường cho việc phục vụ tệp tĩnh. Nội dung tĩnh thường được phục vụ qua CloudFront với tỷ lệ cache hit cao, nên gần như không chạm tới tầng lưu trữ. Con số này hợp lý hơn với CSDL trong bộ nhớ hoặc phân tích thời gian thực.

⚠ Và cần chọn đúng họ instance mới có NVMe cục bộ: | Họ | Đặc điểm | |---|---| | i4i, i3en | tối ưu lưu trữ, NVMe rất lớn | | im4gn, is4gen | Graviton, tối ưu lưu trữ | | m5d, c5d, r5d | có thêm NVMe cục bộ | | m5, c5, r5 | KHÔNG có instance store |

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

• **A. Dùng EBS Provisioned IOPS làm tầng dịch vụ — đây là phương án gần nhất và io2 Block Express là loại EBS nhanh nhất, nhưng trần của nó là 256.000 IOPS, chưa tới một phần tư mức đề yêu cầu.
• **E. Dùng Amazon S3 làm tầng dữ liệu — S3 là kho object, không phải hệ tệp POSIX; không có khoá tệp, không ghi đè một phần tệp được.
• **D. Dùng instance store làm tầng dữ liệu — không chia sẻ được giữa nhiều máy và mất dữ liệu khi instance dừng.

Ghi nhớ

⚠ Bốn loại lưu trữ trên AWS — bảng phải thuộc: | Loại | Ví dụ | Đặc trưng | |---|---|---| | Khối | EBS, instance store | gắn vào một máy, định dạng được | | Tệp | EFS, FSx | POSIX/SMB, nhiều máy mount | | Object | S3 | HTTP API, không phải hệ tệp | | Lưu trữ lạnh | Glacier | rất rẻ, lấy ra chậm |

Từ khoá nhận diện:

"shared POSIX file system" → EFS "millions of IOPS" → instance store NVMe "up to 256,000 IOPS, persistent" → io2 Block Express "Windows SMB share" → FSx for Windows "HPC, lowest latency shared" → FSx for Lustre

Ba lưu ý về instance store: | Lưu ý | Chi tiết | |---|---| | Mất dữ liệu khi stop/terminate | | | Còn dữ liệu khi reboot | | | Không có snapshot | |

⚠ Và phải tự định dạng sau mỗi lần khởi động:

Instance dừng rồi khởi động lại
    → nằm trên máy chủ vật lý KHÁC
    → đĩa NVMe mới, chưa định dạng
        ↓
    Đưa lệnh mkfs vào user data

Ba lưu ý về EFS: | Lưu ý | Chi tiết | |---|---| | Chế độ Elastic tự co giãn thông lượng | | | General Purpose và Max I/O (chế độ hiệu năng) | | | Lớp IA rẻ hơn cho tệp ít đọc | |

⚠ Max I/O đánh đổi độ trễ lấy thông lượng:

General Purpose: độ trễ thấp nhất,
  trần 35.000 IOPS
        ↓
    Max I/O: độ trễ cao hơn một
      chút, nhưng mở rộng gần
      như không giới hạn
        ↓
    Chọn sai không sửa được —
      phải tạo hệ tệp mới

Ba lưu ý về FSx for Lustre: | Lưu ý | Chi tiết | |---|---| | Thông lượng hàng trăm GB/s | | | Liên kết trực tiếp với bucket S3 | | | Hợp với HPC và huấn luyện mô hình | |

Ba lưu ý về EBS Multi-Attach: | Lưu ý | Chi tiết | |---|---| | Chỉ io1/io2, tối đa 16 instance | | | Phải dùng hệ tệp cụm (không phải ext4/xfs) | | | Các instance phải cùng một AZ | |

⚠ Không có hệ tệp cụm là hỏng dữ liệu:

Mount ext4 trên hai máy cùng lúc
        ↓
    Hai máy cùng ghi metadata
    → hệ tệp hỏng
        ↓
    Phải dùng GFS2, OCFS2 hoặc
      tương tự

Ba lưu ý về chọn kiểu instance: | Nhu cầu | Họ | |---|---| | IOPS cục bộ cực cao | i4i, i3en | | Cân bằng | m7i, m7g | | Tính toán mạnh | c7i, c7g | | Bộ nhớ lớn | r7i, x2idn |

Ba lưu ý về bảo vệ dữ liệu trên instance store: | Lưu ý | Chi tiết | |---|---| | Nguồn gốc phải nằm ở S3 hoặc EFS | | | Chép lại lúc khởi động bằng user data | | | Đừng coi nó là nơi lưu trữ chính | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo IOPS thật bằng fio | | | Dừng rồi khởi động máy — kiểm dữ liệu | | | Mount EFS trên hai máy, ghi từ cả hai | |

Và một lời khuyên: hãy luôn giữ một bản gốc của dữ liệu trên instance store ở S3 hoặc EFS. Instance store cho tốc độ không gì sánh được, nhưng nó biến mất hoàn toàn khi máy dừng — và khác với ổ cứng hỏng, chuyện đó xảy ra trong quy trình vận hành bình thường chứ không phải khi có sự cố.

Đáp án

**B — Replatform hạ tầng lên AWS Cloud, dùng AWS OpsWorks làm dịch vụ quản lý cấu hình để tự động hoá cấu hình máy chủ.

Vì sao đúng

Đề nêu hai yêu cầu, và cả hai chỉ ra cùng một hướng: | Yêu cầu | Cách đáp ứng | |---|---| | Thay đổi tối thiểu ở quy trình cấu hình | OpsWorks chạy chính công thức Chef đang có | | Ít việc vận hành sau khi lên đám mây | AWS quản lý máy chủ Chef |

⚠ Điểm mấu chốt: OpsWorks là Chef được AWS quản lý:

Tại chỗ: tự dựng và vận hành
  Chef Server
        ↓
    Vá, sao lưu, mở rộng — tự lo
        ↓
    OpsWorks for Chef Automate:
      AWS lo máy chủ Chef
    → công thức Chef giữ nguyên

⚠ Và đây là lý do câu trả lời là "replatform" chứ không phải "rehost": | Chiến lược | Nghĩa | |---|---| | Rehost | chuyển y nguyên, không đổi gì | | Replatform | chuyển và đổi một thành phần sang dịch vụ quản lý | | Refactor | viết lại theo kiến trúc đám mây |

Rehost: dựng EC2 rồi tự cài
  Chef Server lên đó
        ↓
    Vẫn phải vá, vẫn phải sao lưu
    → không giảm việc vận hành
        ↓
    Replatform: đổi Chef Server tự
      quản thành OpsWorks
    → đây chính là "đổi một thành
      phần sang dịch vụ quản lý"

Đây là lý do phương án A sai — nó dùng đúng công cụ nhưng gọi sai chiến lược.

⚠ Và đây là điểm cần đọc kỹ trong loại câu này:

A và B khác nhau ĐÚNG MỘT TỪ:
  "rehost" và "replatform"
        ↓
    Cùng nói dùng OpsWorks
    → chỉ chiến lược khác
        ↓
    Đề nhắc "ít việc vận hành sau
      khi lên đám mây"
    → đó là dấu hiệu của replatform

Tạo Chef Automate server:

aws opsworks-cm create-server \
  --engine "ChefAutomate" \
  --server-name "chef-cong-ty" \
  --instance-type "m5.large" \
  --instance-profile-arn <arn-profile> \
  --service-role-arn <arn-role> \
  --backup-retention-count 10 \
  --preferred-backup-window "01:00"

⚠ Và OpsWorks có ba biến thể — phải phân biệt: | Biến thể | Nội dung | |---|---| | OpsWorks for Chef Automate | máy chủ Chef do AWS quản | | OpsWorks for Puppet Enterprise | máy chủ Puppet do AWS quản | | OpsWorks Stacks | phiên bản Chef Solo riêng của AWS |

Đội đang dùng Chef
    → hai biến thể đầu là lựa chọn
        ↓
    OpsWorks Stacks dùng Chef Solo
      với mô hình lớp riêng của AWS
    → phải viết lại công thức

⚠ Và vì sao phương án C sai — AWS Config không phải quản lý cấu hình máy chủ:

Tên nghe rất giống nhau, nhưng:
        ↓
    "Configuration management" trong
      DevOps = cài đặt và cấu hình
      phần mềm trên máy chủ
        ↓
    AWS Config = ghi lại và đánh giá
      cấu hình TÀI NGUYÊN AWS
        ↓
    Hai việc hoàn toàn khác nhau

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

Elastic Beanstalk là nền tảng
  triển khai ỨNG DỤNG
        ↓
    Bạn đưa mã nguồn, nó dựng
      môi trường
        ↓
    Không chạy công thức Chef
    → đội phải bỏ toàn bộ quy trình
      hiện có

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Công thức Chef dùng lại được | | | AWS lo máy chủ Chef | | | Sao lưu tự động, khôi phục được | |

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

⚠ AWS đã thông báo ngừng OpsWorks — cả ba biến thể.

Với kiến thức hiện tại, hướng đi là Systems Manager: | Nhu cầu | Thay thế | |---|---| | Giữ cấu hình đúng chuẩn | SSM State Manager | | Chạy lệnh trên nhiều máy | SSM Run Command | | Vá hệ điều hành | SSM Patch Manager | | Vẫn muốn dùng Chef | tự dựng Chef Server trên EC2, hoặc Chef SaaS |

SSM State Manager áp một tài liệu
  cấu hình theo lịch
        ↓
    Máy lệch chuẩn → tự đưa về
        ↓
    Đây chính là việc Chef làm,
      bằng công cụ của AWS

aws ssm create-association \
  --name "AWS-ApplyChefRecipes" \
  --targets "Key=tag:MoiTruong,Values=san-xuat" \
  --schedule-expression "rate(30 minutes)"

⚠ Và tài liệu AWS-ApplyChefRecipes cho phép chạy công thức Chef qua SSM:

Không cần Chef Server nào cả
    → công thức lấy từ S3
    → chef-client chạy ở chế độ local
        ↓
    Đây là đường di trú tự nhiên
      nhất cho đội đang dùng Chef

Câu hỏi vẫn kiểm tra đúng khái niệm rehost và replatform, nhưng dịch vụ mà nó gọi tên đã không còn nhận khách hàng mới.

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

• **A. Rehost hạ tầng lên AWS và dùng OpsWorks — đây là phương án gần nhất và chọn đúng dịch vụ, nhưng rehost nghĩa là chuyển y nguyên; việc đổi Chef Server tự quản sang dịch vụ quản lý của AWS chính là replatform.
• **C. Replatform và dùng AWS Config làm dịch vụ quản lý cấu hình — AWS Config đánh giá cấu hình tài nguyên AWS, không cài đặt hay cấu hình phần mềm trên máy chủ.
• **D. Rehost và dùng Elastic Beanstalk — Beanstalk triển khai ứng dụng từ mã nguồn, không chạy công thức Chef.

Ghi nhớ

⚠ Sáu chiến lược di trú (6 R) — bảng phải thuộc: | Chiến lược | Nghĩa | Ví dụ | |---|---|---| | Rehost | lift-and-shift | MGN chuyển VM sang EC2 | | Replatform | đổi một thành phần sang dịch vụ quản lý | MySQL tự quản → RDS | | Repurchase | mua SaaS thay thế | CRM tự viết → Salesforce | | Refactor | viết lại kiến trúc | monolith → serverless | | Retire | bỏ đi | hệ thống không ai dùng | | Retain | giữ tại chỗ | ràng buộc pháp lý |

⚠ Replatform còn được gọi là "lift-tinker-and-shift".

Từ khoá nhận diện:

"minimal changes but less ops overhead" → replatform "no changes at all, fastest" → rehost "redesign for cloud-native" → refactor "configuration management for servers" → SSM State Manager (trước là OpsWorks) "configuration compliance of AWS resources" → AWS Config

Ba lưu ý về SSM State Manager: | Lưu ý | Chi tiết | |---|---| | Association gắn tài liệu với nhóm máy theo thẻ | | | Chạy theo lịch hoặc theo tốc độ | | | Báo cáo tuân thủ cho từng máy | |

Ba lưu ý về SSM Agent: | Lưu ý | Chi tiết | |---|---| | Cài sẵn trên AMI của Amazon Linux, Ubuntu, Windows | | | Cần instance profile có AmazonSSMManagedInstanceCore | | | Cần tới được endpoint SSM (Internet hoặc VPC endpoint) | |

⚠ Ba VPC endpoint cần cho SSM trong subnet riêng:

com.amazonaws.<region>.ssm
com.amazonaws.<region>.ssmmessages
com.amazonaws.<region>.ec2messages

Thiếu một cái → agent không kết
  nối được
    → và không có lỗi rõ ràng

Ba lưu ý về Patch Manager: | Lưu ý | Chi tiết | |---|---| | Patch baseline khai bản vá được duyệt | | | Maintenance window đặt thời điểm vá | | | Báo cáo tuân thủ vá cho từng máy | |

Ba lưu ý về hạ tầng bất biến: | Lưu ý | Chi tiết | |---|---| | Dựng AMI mới thay vì sửa máy đang chạy | | | EC2 Image Builder tự động hoá việc đó | | | Giảm hẳn nhu cầu quản lý cấu hình lúc chạy | |

⚠ Đây là hướng hiện đại hơn cả State Manager:

Quản lý cấu hình lúc chạy: máy
  dần lệch nhau (configuration drift)
        ↓
    Hạ tầng bất biến: máy mới luôn
      giống hệt AMI
    → không có drift
        ↓
    Đổi lại: mỗi thay đổi nhỏ cũng
      phải dựng AMI mới

Ba lưu ý về đánh giá trước di trú: | Công cụ | Việc | |---|---| | Application Discovery Service | thu thập cấu hình và phụ thuộc | | Migration Hub | theo dõi tiến độ | | Migration Evaluator | ước tính chi phí trên AWS |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy công thức Chef trên một máy thử | | | So cấu hình máy trên AWS với máy tại chỗ | | | Kiểm báo cáo tuân thủ của State Manager | |

Và một lời khuyên: hãy đọc thật kỹ từ chỉ chiến lược trong loại câu hỏi này. Hai phương án chỉ khác nhau ở "rehost" và "replatform" là kiểu đề rất phổ biến — và cụm từ quyết định thường nằm ở vế "ít việc vận hành hơn sau khi di trú", chứ không nằm ở tên dịch vụ.

Đáp án

**B — Dùng VPC endpoint tập trung cho nhiều VPC, tức mô hình shared services VPC.

Vì sao đúng

Đề đã cho sẵn nền tảng và hỏi cách tận dụng nó:

Đã có Transit Gateway theo mô hình
  hub-and-spoke
        ↓
    Nhiều VPC ở nhiều tài khoản
        ↓
    Cần: rẻ, nhanh, an toàn, cho
      workload ở mọi VPC dùng
      chung dịch vụ

⚠ Điểm mấu chốt: interface endpoint tính phí theo GIỜ cho mỗi endpoint:

Mỗi interface endpoint: khoảng
  0,01 USD/giờ mỗi AZ
        ↓
    Một VPC × 3 AZ × 10 dịch vụ
    → 30 endpoint
        ↓
    Nhân với 50 VPC
    → 1.500 endpoint
    → hàng nghìn USD mỗi tháng

⚠ Và endpoint tập trung gộp con số đó lại:

MỘT shared services VPC
        ↓
    Đặt interface endpoint ở đó
      (3 AZ × 10 dịch vụ = 30)
        ↓
    Mọi VPC khác đi qua Transit
      Gateway để tới
    → giảm 50 lần

Kiến trúc:

VPC ứng dụng A ─┐
VPC ứng dụng B ─┼→ Transit Gateway → Shared Services VPC
VPC ứng dụng C ─┘                         ├── endpoint SSM
                                          ├── endpoint Secrets Manager
                                          ├── endpoint ECR
                                          └── endpoint KMS

Tạo private hosted zone để phân giải tên:

aws route53 create-hosted-zone \
  --name ssm.ap-southeast-1.amazonaws.com \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-shared \
  --caller-reference $(uuidgen) \
  --hosted-zone-config PrivateZone=true

⚠ Phân giải DNS là phần khó nhất của mẫu này:

Interface endpoint tạo bản ghi DNS
  riêng tư TRONG VPC chứa nó
        ↓
    VPC khác không phân giải được
    → gói tin không biết đi đâu
        ↓
    Giải: private hosted zone chia
      sẻ cho mọi VPC

aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z123 \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-ung-dung-a

⚠ Và phải TẮT private DNS trên endpoint để tránh xung đột:

aws ec2 create-vpc-endpoint --vpc-id vpc-shared \
  --service-name com.amazonaws.ap-southeast-1.ssm \
  --vpc-endpoint-type Interface \
  --no-private-dns-enabled \
  --subnet-ids subnet-1a subnet-1b subnet-1c

Bật private DNS: chỉ VPC chứa
  endpoint dùng được
        ↓
    Tắt rồi tự tạo hosted zone
    → chia sẻ được cho mọi VPC

⚠ Và vì sao phương án D (VPC peering lưới đầy đủ) sai:

n VPC cần n(n-1)/2 kết nối peering
        ↓
    10 VPC → 45 kết nối
    50 VPC → 1.225 kết nối
        ↓
    Và peering KHÔNG bắc cầu
    → mỗi cặp phải nối trực tiếp
        ↓
    Đó chính là lý do Transit
      Gateway ra đời

⚠ Và vì sao phương án C (Transit VPC) là mô hình cũ:

Transit VPC: dựng thiết bị ảo
  (router phần mềm) trên EC2
        ↓
    Tự vận hành, tự làm HA,
      tự mở rộng
        ↓
    Transit Gateway thay thế nó
      từ 2018
    → và đề nói đã CÓ Transit Gateway

⚠ Và vì sao phương án A (Direct Connect) không trả lời câu hỏi:

Direct Connect nối trung tâm dữ
  liệu TẠI CHỖ với AWS
        ↓
    Đề hỏi về kết nối GIỮA CÁC VPC
      trên AWS
        ↓
    Sai bài toán

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chi phí endpoint giảm theo số VPC | | | Một nơi cấu hình chính sách endpoint | | | Lưu lượng không ra Internet | |

⚠ Và endpoint policy tập trung là lợi ích an ninh đáng kể:

{"Statement": [{
  "Effect": "Allow",
  "Principal": "*",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::kho-cong-ty/*",
  "Condition": {"StringEquals": {
    "aws:PrincipalOrgID": "o-abc123"}}}]}

Một chính sách áp cho mọi VPC
    → chỉ tài nguyên của tổ chức
      mới truy cập được

⚠ Nhưng cần nhớ: gateway endpoint thì KHÔNG chia sẻ được: | Loại endpoint | Dịch vụ | Chia sẻ liên VPC | |---|---|---| | Gateway | S3, DynamoDB | KHÔNG | | Interface (PrivateLink) | hầu hết dịch vụ khác | CÓ, qua TGW |

Gateway endpoint hoạt động bằng
  bảng ĐỊNH TUYẾN của chính VPC đó
        ↓
    Không đi qua Transit Gateway
      được
        ↓
    Mỗi VPC phải có gateway endpoint
      riêng — nhưng nó MIỄN PHÍ

⚠ Và có phí truyền dữ liệu qua Transit Gateway:

Endpoint tập trung: lưu lượng đi
  qua TGW
        ↓
    TGW tính phí theo GB xử lý
        ↓
    Với lưu lượng rất lớn tới một
      dịch vụ, endpoint riêng ở
      từng VPC có thể rẻ hơn
    → phải tính, không mặc định

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

• **C. Dùng Transit VPC để giảm chi phí và chia sẻ tài nguyên — đây là phương án gần nhất và thật sự là mô hình tập trung kết nối, nhưng Transit VPC dựa trên thiết bị ảo tự vận hành trên EC2, và đề đã có sẵn Transit Gateway thay thế nó.
• **D. Dùng VPC peering lưới đầy đủ — số kết nối tăng theo bình phương số VPC, và peering không bắc cầu nên không mở rộng được.
• **A. Dùng VPC nối bằng Direct Connect — Direct Connect nối tại chỗ với AWS, không phải nối các VPC với nhau.

Ghi nhớ

⚠ Bốn cách kết nối nhiều VPC — bảng phải thuộc: | Cách | Bắc cầu | Số kết nối | |---|---|---| | Transit Gateway | CÓ | n (mỗi VPC một attachment) | | VPC peering | KHÔNG | n(n-1)/2 | | PrivateLink | không áp dụng | một chiều, theo dịch vụ | | Transit VPC (cũ) | có | n, nhưng tự vận hành |

Từ khoá nhận diện:

"share services across many VPCs" → shared services VPC + interface endpoint "hundreds of VPCs, transitive routing" → Transit Gateway "expose one service to consumers" → PrivateLink endpoint service "connect on-premises" → Direct Connect hoặc VPN

⚠ PrivateLink cho dịch vụ tự viết:

aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns <arn-nlb> \
  --acceptance-required

Đội A phơi dịch vụ qua NLB
    → đội B tạo interface endpoint
      tới đó
        ↓
    Không cần peering, không lo
      trùng CIDR

⚠ Không lo trùng CIDR là ưu thế lớn của PrivateLink:

Peering và TGW: CIDR không được
  chồng nhau
        ↓
    Sáp nhập hai công ty cùng dùng
      10.0.0.0/16
    → không nối được
        ↓
    PrivateLink: chỉ phơi một
      endpoint, không định tuyến
      cả dải

Ba lưu ý về Transit Gateway: | Lưu ý | Chi tiết | |---|---| | Chia sẻ qua RAM cho nhiều tài khoản | | | Nhiều bảng định tuyến để phân đoạn mạng | | | Tính phí theo attachment và GB xử lý | |

⚠ Tắt liên kết và lan truyền mặc định để phân đoạn:

aws ec2 create-transit-gateway --options \
  DefaultRouteTableAssociation=disable,\
DefaultRouteTablePropagation=disable

Ba lưu ý về interface endpoint: | Lưu ý | Chi tiết | |---|---| | Tạo ENI trong subnet, tốn IP | | | Tính phí theo giờ mỗi AZ + GB xử lý | | | Endpoint policy giới hạn được truy cập | |

Ba lưu ý về gateway endpoint: | Lưu ý | Chi tiết | |---|---| | Chỉ có cho S3 và DynamoDB | | | MIỄN PHÍ | | | Hoạt động qua bảng định tuyến, không qua TGW | |

⚠ Gateway endpoint là biện pháp giảm chi phí lớn nhất:

Lưu lượng S3 chiếm phần lớn
  lưu lượng ra ở nhiều kiến trúc
        ↓
    Không có endpoint: đi qua NAT
      gateway, tính phí xử lý
        ↓
    Có gateway endpoint: miễn phí
      hoàn toàn

Ba lưu ý về DNS liên VPC: | Lưu ý | Chi tiết | |---|---| | Private hosted zone gắn được với nhiều VPC | | | Route 53 Resolver rule chia sẻ qua RAM | | | Tắt private DNS khi dùng endpoint tập trung | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Security group của endpoint kiểm soát ai gọi tới | | | Endpoint policy kiểm soát gọi được gì | | | Điều kiện aws:PrincipalOrgID chặn ngoài tổ chức | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig ssm.<region>.amazonaws.com từ VPC ứng dụng | | | Chạy Reachability Analyzer giữa hai VPC | | | So hoá đơn endpoint trước và sau khi gộp | |

Và một lời khuyên: hãy tính cả phí xử lý dữ liệu của Transit Gateway trước khi gộp endpoint. Gộp lại tiết kiệm phí endpoint theo giờ, nhưng mọi gói tin giờ phải đi qua TGW và bị tính theo GB — với một dịch vụ có lưu lượng rất lớn, khoản mới có thể lớn hơn khoản vừa tiết kiệm.

Đáp án

**B — Đặt ba thiết bị AWS Snowball Edge, chia và chuyển dữ liệu vào ba thiết bị rồi gửi về AWS để nạp vào S3.

Vì sao đúng

Đề cho hai đường truyền và một khối lượng dữ liệu, phải tính ra thời gian:

200 TB dữ liệu
        ↓
    Direct Connect 500 Mbps
    → hoặc VPN 1 Gbps
        ↓
    Yêu cầu: NHANH NHẤT có thể

⚠ Tính thời gian truyền qua từng đường: | Đường | Băng thông | Thời gian lý thuyết | Thực tế (~65%) | |---|---|---|---| | Direct Connect | 500 Mbps | ~37 ngày | ~57 ngày | | VPN | 1 Gbps | ~18,5 ngày | ~28 ngày | | Snowball Edge | — | ~1-2 tuần cả chu trình | ~1-2 tuần |

200 TB = 1.600.000.000 Mb
        ↓
    Ở 1 Gbps: 1.600.000 giây
    = 18,5 ngày
        ↓
    Snowball: nhanh hơn, và không
      chiếm đường truyền

⚠ Và tại sao BA thiết bị:

Snowball Edge Storage Optimized:
  80 TB dung lượng dùng được
        ↓
    200 TB / 80 TB = 2,5
    → cần 3 thiết bị
        ↓
    Và ba thiết bị chép SONG SONG
    → thời gian chép tại chỗ giảm
      ba lần

Đặt thiết bị:

aws snowball create-cluster \
  --job-type IMPORT \
  --resources '{"S3Resources": [{"BucketArn":
    "arn:aws:s3:::kho-di-tru"}]}' \
  --address-id <ma-dia-chi> \
  --role-arn <arn-role> \
  --snowball-type EDGE_S3_OPTIMIZED \
  --shipping-option EXPEDITED

Chép dữ liệu vào thiết bị:

snowballEdge unlock-device --endpoint https://192.0.2.10 \
  --manifest-file manifest.bin --unlock-code <ma>

aws s3 cp /du-lieu/ s3://kho-di-tru/ --recursive \
  --endpoint http://192.0.2.10:8080 --profile snowball

⚠ Và vì sao chiếm hết đường truyền là ý tưởng tồi:

Dùng 100% Direct Connect trong
  57 ngày
        ↓
    Mọi lưu lượng nghiệp vụ khác
      bị nghẽn
        ↓
    Phải giới hạn băng thông
    → thời gian còn dài hơn nữa

Đây là lý do phương án C và D thất bại ngoài chuyện thời gian.

⚠ Và vì sao phương án A (Transfer Acceleration) không giải quyết được:

S3TA tăng tốc bằng cách đưa lưu
  lượng vào mạng AWS sớm hơn
        ↓
    Nhưng nút thắt là băng thông
      ĐẦU RA của trung tâm dữ liệu
        ↓
    S3TA không tạo ra thêm băng
      thông ở đầu nguồn

S3TA hiệu quả khi: đường truyền
  rộng nhưng đường đi xa và kém
        ↓
    Không hiệu quả khi: đường
      truyền hẹp

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không chiếm băng thông nghiệp vụ | | | Ba thiết bị chép song song | | | Chi phí cố định, đoán trước được | |

⚠ Và Snowball Edge có mã hoá và chống can thiệp sẵn:

Dữ liệu mã hoá bằng KMS
    → khoá KHÔNG nằm trên thiết bị
        ↓
    Thiết bị bị mất trên đường
    → không ai đọc được
        ↓
    Có Trusted Platform Module
      phát hiện can thiệp vật lý

⚠ Và có mẹo quan trọng để chép nhanh:

Chép tuần tự từng tệp
    → chậm, nhất là với tệp nhỏ
        ↓
    Chạy nhiều tiến trình chép
      song song (10-16 luồng)
    → và gom tệp nhỏ lại trước
        ↓
    AWS khuyến nghị dùng client
      Snowball Edge với nhiều luồng

⚠ Và cần tính cả thời gian chép, không chỉ thời gian vận chuyển:

Chu trình đầy đủ:
  đặt hàng → giao (2-6 ngày)
  → chép (tuỳ tốc độ đĩa nguồn)
  → gửi trả (2-6 ngày)
  → AWS nạp vào S3 (1-2 ngày)
        ↓
    Với ba thiết bị chạy song song,
      khâu chép rút ngắn đáng kể

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

⚠ Đề nói "AWS Snowball Edge appliances" — cần biết dòng sản phẩm hiện tại.

⚠ Và có một mốc quyết định nữa cần nhớ:

Snowball Edge Storage Optimized
  bản mới: 210 TB
        ↓
    Với dung lượng đó, 200 TB
      vừa MỘT thiết bị
        ↓
    Nhưng chép 200 TB vào một thiết
      bị mất rất lâu
    → chia ba vẫn nhanh hơn

Câu hỏi vẫn đúng về nguyên tắc: khi truyền qua mạng mất hàng tuần trở lên, thiết bị vật lý là lựa chọn đúng.

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

• **D. Dùng VPN 1 Gbps truyền qua Internet công cộng — đây là phương án gần nhất và đường truyền rộng nhất trong hai lựa chọn, nhưng vẫn mất khoảng 28 ngày thực tế, và chiếm hết băng thông của cả công ty suốt thời gian đó.
• **C. Dùng Direct Connect 500 Mbps — chậm hơn nữa, khoảng 57 ngày thực tế.
• **A. Dùng S3 Transfer Acceleration — tăng tốc đường đi tới AWS nhưng không tạo thêm băng thông ở đầu nguồn, nơi đang là nút thắt.

Ghi nhớ

⚠ Ngưỡng chọn giữa mạng và thiết bị vật lý:

Thời gian truyền qua mạng
  > một tuần
        ↓
    Cân nhắc Snow Family
        ↓
    > một tháng
    → gần như chắc chắn dùng thiết bị

Công thức tính nhanh:

Số ngày ≈ (TB × 8.000.000) /
          (Mbps × 86.400 × 0,65)

Từ khoá nhận diện:

"hundreds of TB, shortest time" → nhiều Snowball Edge "exabytes" → nhiều Snowball (Snowmobile đã ngừng) "continuous sync after migration" → DataSync "edge computing in disconnected location" → Snowball Edge Compute Optimized

Ba lưu ý về Snowball Edge: | Lưu ý | Chi tiết | |---|---| | Mã hoá bằng KMS, khoá không nằm trên thiết bị | | | Có bản chạy được EC2 và Lambda tại chỗ | | | Tính phí theo thiết bị và số ngày giữ | |

⚠ Giữ thiết bị quá lâu tính phí thêm:

Giá cơ bản gồm 10 ngày dùng
    → quá thì tính theo ngày
        ↓
    Chuẩn bị sẵn dữ liệu trước khi
      thiết bị tới

Ba lưu ý về tối ưu tốc độ chép: | Lưu ý | Chi tiết | |---|---| | Chạy nhiều luồng song song | | | Gom tệp nhỏ thành tệp lớn | | | Đĩa nguồn thường là nút thắt | |

⚠ Tệp nhỏ chép rất chậm:

Hàng triệu tệp vài KB
    → chi phí siêu dữ liệu lấn át
        ↓
    Gom thành tar trước khi chép
    → nhanh hơn nhiều lần
        ↓
    Nhưng khi vào S3 sẽ là một
      object lớn, phải giải nén sau

Ba lưu ý về DataSync: | Lưu ý | Chi tiết | |---|---| | Chạy được TRÊN Snowball Edge | | | Có kiểm tra toàn vẹn sau khi chuyển | | | Đồng bộ phần chênh sau khi thiết bị đã đi | |

⚠ Mẫu kết hợp là cách làm thực tế nhất:

Snowball chở dữ liệu nền đi
        ↓
    DataSync đồng bộ phần thay đổi
      qua mạng
        ↓
    Cắt chuyển khi phần chênh nhỏ

Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Phí thiết bị theo lần dùng | | | Phí vận chuyển | | | Nhập dữ liệu vào AWS MIỄN PHÍ | |

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Manifest và unlock code gửi riêng nhau | | | AWS xoá sạch thiết bị theo chuẩn NIST sau khi nạp | | | Theo dõi thiết bị bằng E Ink shipping label | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đếm object trong S3 sau khi nạp | | | So checksum vài tệp mẫu | | | Kiểm báo cáo job của Snowball | |

Và một lời khuyên: hãy chuẩn bị và gom dữ liệu xong trước khi thiết bị đến nơi. Chu trình Snowball tính phí theo ngày giữ thiết bị, và khâu chép thường chậm hơn dự tính rất nhiều — nhất là khi dữ liệu gồm hàng triệu tệp nhỏ nằm trên một hệ thống lưu trữ đã cũ.

Đáp án

**C, E và F — Snapshot là bản sao lưu đầy đủ do người dùng chủ động tạo, sao chép và chia sẻ được sang Region và tài khoản khác; sao lưu tự động, snapshot thủ công và read replica đều hỗ trợ liên Region; và RTO là số giờ cần để đưa CSDL trở lại trạng thái hoạt động sau thảm hoạ.

Vì sao đúng

Ba mệnh đề này là ba sự thật cơ bản phải thuộc khi lập kế hoạch khôi phục cho RDS.

⚠ Mệnh đề F — định nghĩa RTO:

RTO = Recovery Time Objective
        ↓
    THỜI GIAN chấp nhận được để
      khôi phục dịch vụ
        ↓
    RPO = Recovery Point Objective
    → LƯỢNG DỮ LIỆU chấp nhận
      được để mất

⚠ Đây là lý do mệnh đề A sai:

A nói "RTO thể hiện bạn có thể
  mất bao nhiêu dữ liệu"
        ↓
    Đó là định nghĩa của RPO
    → tráo hai khái niệm

Cách nhớ:

RTO — Time — mất bao lâu để
  quay lại
        ↓
    RPO — Point — quay lại được
      tới ĐIỂM nào trong quá khứ

⚠ Mệnh đề C — snapshot thủ công khác sao lưu tự động: | Tiêu chí | Sao lưu tự động | Snapshot thủ công | |---|---|---| | Ai tạo | RDS theo lịch | người dùng | | Vòng đời | xoá khi hết hạn giữ (tối đa 35 ngày) | giữ tới khi tự xoá | | Xoá CSDL thì sao | MẤT theo | CÒN | | Chia sẻ được | KHÔNG | CÓ | | Sao chép liên Region | không trực tiếp | CÓ |

⚠ Điểm "xoá CSDL thì sao" rất quan trọng:

Xoá DB instance
        ↓
    Sao lưu tự động bị xoá theo
      (trừ khi tạo final snapshot)
        ↓
    Snapshot thủ công vẫn còn
    → luôn tạo snapshot thủ công
      trước khi xoá

Sao chép snapshot sang Region khác:

aws rds copy-db-snapshot \
  --source-db-snapshot-identifier \
    arn:aws:rds:ap-southeast-1:111122223333:snapshot:sao-luu-2026-09 \
  --target-db-snapshot-identifier sao-luu-2026-09-dr \
  --kms-key-id <khoa-o-region-dich> \
  --region ap-northeast-1

Chia sẻ snapshot với tài khoản khác:

aws rds modify-db-snapshot-attribute \
  --db-snapshot-identifier sao-luu-2026-09 \
  --attribute-name restore \
  --values-to-add 444455556666

⚠ Mệnh đề D sai vì hai lý do:

D nói "chia sẻ được sao lưu TỰ ĐỘNG
  với tối đa 20 tài khoản"
        ↓
    Sai thứ nhất: sao lưu tự động
      KHÔNG chia sẻ được
    → phải copy thành snapshot thủ
      công trước
        ↓
    Sai thứ hai: con số 20 chỉ đúng
      cho snapshot THỦ CÔNG

⚠ Mệnh đề E — cả ba cơ chế đều hỗ trợ liên Region: | Cơ chế | Liên Region | |---|---| | Snapshot thủ công | copy sang Region khác | | Sao lưu tự động | bật automated backup replication | | Read replica | tạo được ở Region khác |

aws rds start-db-instance-automated-backups-replication \
  --source-db-instance-arn <arn-nguon> \
  --backup-retention-period 7 \
  --region ap-northeast-1

⚠ Sao chép sao lưu tự động liên Region là tính năng đáng biết:

Cho phép point-in-time recovery
  ở Region ĐÍCH
        ↓
    Không phải chỉ khôi phục về
      thời điểm snapshot
    → khôi phục về bất kỳ giây nào

⚠ Mệnh đề B sai — chuyển đổi sang read replica KHÔNG tự động: | Cơ chế | Chuyển đổi | |---|---| | Multi-AZ | TỰ ĐỘNG, 60-120 giây | | Read replica | THỦ CÔNG, phải promote |

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

Promote xong: replica thành
  instance độc lập
        ↓
    Và KHÔNG quay lại làm replica
      được nữa
        ↓
    Đây là thao tác một chiều

⚠ Và đây là khác biệt căn bản giữa hai cơ chế: | Tiêu chí | Multi-AZ | Read replica | |---|---|---| | Mục đích | sẵn sàng cao | mở rộng đọc | | Sao chép | đồng bộ | không đồng bộ | | Phục vụ đọc | KHÔNG (kiểu instance) | CÓ | | Chuyển đổi | tự động | thủ công | | Liên Region | không (trong Region) | CÓ |

Ba lợi ích của kế hoạch đầy đủ: | Lợi ích | Chi tiết | |---|---| | Snapshot liên Region sống sót thảm hoạ vùng | | | Sao lưu tự động cho phép khôi phục theo thời điểm | | | Read replica liên Region cho RTO ngắn nhất | |

⚠ Và ba cơ chế phục vụ ba mức RTO khác nhau:

Read replica liên Region
    → promote trong vài phút
    → RTO ngắn nhất, đắt nhất
        ↓
Snapshot copy liên Region
    → khôi phục mất hàng chục phút
      tới hàng giờ
        ↓
Chỉ sao lưu trong Region
    → mất Region là mất hết

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

• **B. Chuyển đổi sang read replica là quá trình tự động như Multi-AZ, không cần can thiệp — đây là phương án gần nhất và read replica thật sự là một phần của kế hoạch khôi phục, nhưng phải chủ động gọi promote-read-replica; không có cơ chế tự động nào.
• **A. RTO thể hiện bạn có thể mất bao nhiêu dữ liệu — đó là định nghĩa của RPO.
• **D. Chia sẻ được sao lưu tự động với tối đa 20 tài khoản — sao lưu tự động không chia sẻ được; phải sao chép thành snapshot thủ công trước.

Ghi nhớ

⚠ RTO và RPO — bảng phải thuộc: | Chỉ tiêu | Đo gì | Giảm bằng cách | |---|---|---| | RTO | thời gian khôi phục | giữ sẵn bản dự phòng chạy được | | RPO | lượng dữ liệu mất | sao lưu/sao chép thường xuyên hơn |

Từ khoá nhận diện:

"how much data can we lose" → RPO "how long until we're back up" → RTO "automatic failover" → Multi-AZ "cross-Region disaster recovery" → read replica hoặc snapshot copy liên Region "point-in-time recovery" → sao lưu tự động

Ba lưu ý về sao lưu tự động: | Lưu ý | Chi tiết | |---|---| | Giữ 1-35 ngày | | | Đặt 0 là TẮT sao lưu tự động | | | Cho phép khôi phục tới bất kỳ giây nào trong khoảng giữ | |

⚠ Đặt retention bằng 0 là tắt luôn point-in-time recovery:

Không có sao lưu tự động
    → chỉ khôi phục về thời điểm
      snapshot thủ công
        ↓
    Và Multi-AZ yêu cầu retention
      lớn hơn 0

Ba lưu ý về snapshot: | Lưu ý | Chi tiết | |---|---| | Khôi phục tạo instance MỚI | | | Không ghi đè instance đang có | | | Instance mới có endpoint mới | |

⚠ Endpoint mới là chi tiết ảnh hưởng RTO:

Khôi phục xong: endpoint khác
        ↓
    Ứng dụng phải đổi chuỗi kết nối
        ↓
    Dùng CNAME trỏ tới CSDL
    → khôi phục xong chỉ cần đổi
      CNAME

Ba lưu ý về snapshot mã hoá: | Lưu ý | Chi tiết | |---|---| | Chia sẻ snapshot mã hoá cần chia sẻ cả khoá KMS | | | Không chia sẻ được snapshot mã hoá bằng khoá mặc định | | | Copy liên Region cần khoá ở Region đích | |

⚠ Khoá mặc định aws/rds không chia sẻ được:

Muốn chia sẻ snapshot
    → phải mã hoá bằng khoá KMS
      TỰ QUẢN
        ↓
    Rồi cấp quyền dùng khoá cho
      tài khoản kia

Ba lưu ý về read replica: | Lưu ý | Chi tiết | |---|---| | Tối đa 5 (RDS), 15 (Aurora) | | | Có độ trễ sao chép | | | Promote là thao tác một chiều | |

Ba lưu ý về Aurora Global Database: | Lưu ý | Chi tiết | |---|---| | Độ trễ sao chép thường dưới 1 giây | | | Chuyển đổi Region trong khoảng một phút | | | RTO và RPO tốt hơn hẳn read replica thườ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 tự động theo chính sách | | | Vault Lock chống xoá (WORM) | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khôi phục thật từ snapshot và bấm giờ | | | Promote một replica ở môi trường thử | | | Kiểm snapshot đã sao chép sang Region dự phòng | |

Và một lời khuyên: hãy tạo snapshot thủ công trước mọi thao tác có thể phải quay lui. Sao lưu tự động biến mất cùng với instance khi nó bị xoá, còn snapshot thủ công thì sống độc lập — và ranh giới giữa "sự cố nhỏ" với "mất dữ liệu vĩnh viễn" thường chỉ là một bản snapshot mà ai đó đã nghĩ đến việc tạo.

Đáp án

**D — Bật DMS data validation trên tác vụ di trú để nó so sánh dữ liệu nguồn với dữ liệu đích và báo cáo mọi chỗ lệch.

Vì sao đúng

Đề nêu hai yêu cầu, và data validation đáp ứng cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Xác nhận dữ liệu chuyển ĐÚNG trước khi chuyển đổi | so từng dòng giữa nguồn và đích | | Ảnh hưởng tối thiểu tới hiệu năng nguồn | chạy sau khi nạp, đọc theo lô, có điều tiết |

⚠ Điểm mấu chốt: data validation so SÁNH NỘI DUNG chứ không đếm số dòng:

Đếm số dòng: hai bên đều 1 triệu
        ↓
    Nhưng một cột `DECIMAL` bị làm
      tròn khi chuyển sang MySQL
    → đếm không phát hiện được
        ↓
    Data validation so GIÁ TRỊ
      từng cột từng dòng

Bật validation:

aws dms create-replication-task \
  --replication-task-identifier di-tru-oracle \
  --migration-type full-load-and-cdc \
  --source-endpoint-arn <arn-oracle> \
  --target-endpoint-arn <arn-aurora> \
  --table-mappings file://anh-xa.json \
  --replication-task-settings '{
    "ValidationSettings": {
      "EnableValidation": true,
      "ValidationMode": "ROW_LEVEL",
      "ThreadCount": 5,
      "PartitionSize": 10000,
      "FailureMaxCount": 10000,
      "RecordFailureDelayInMinutes": 5,
      "TableFailureMaxCount": 1000,
      "ValidationPartialLobSize": 0}}'

⚠ ThreadCount và PartitionSize điều tiết ảnh hưởng lên nguồn:

ThreadCount cao → so nhanh hơn
    → nhưng đọc nhiều hơn từ nguồn
        ↓
    Đề nói "ảnh hưởng tối thiểu tới
      hiệu năng nguồn"
    → giảm ThreadCount xuống

Xem kết quả:

aws dms describe-table-statistics \
  --replication-task-arn <arn-tac-vu> \
  --query 'TableStatistics[].[TableName,ValidationState,
                             ValidationFailedRecords,
                             ValidationPendingRecords]' \
  --output table

⚠ Các trạng thái validation cần hiểu: | Trạng thái | Nghĩa | |---|---| | Validated | mọi dòng khớp | | Mismatched records | có dòng lệch | | Pending records | chưa so xong | | Suspended records | tạm dừng, thường do bảng thay đổi liên tục | | No primary key | KHÔNG so được |

⚠ Trạng thái cuối là hạn chế lớn nhất:

Data validation cần KHOÁ CHÍNH
  hoặc chỉ mục duy nhất
        ↓
    Bảng không có → bỏ qua, không
      so được
        ↓
    Và nó không báo lỗi ồn ào
    → phải chủ động kiểm bảng nào
      bị bỏ qua

Bảng chi tiết dòng lệch:

SELECT * FROM awsdms_validation_failures_v1
WHERE TASK_NAME = 'di-tru-oracle';

⚠ Và vì sao phương án A (premigration assessment) sai:

Premigration assessment chạy TRƯỚC
  khi di trú
        ↓
    Nó kiểm tính tương thích:
      kiểu dữ liệu không hỗ trợ,
      bảng thiếu khoá chính,
      thiết lập LOB
        ↓
    Nó KHÔNG so sánh dữ liệu
    → vì lúc đó đích còn trống

⚠ Nhưng premigration assessment vẫn nên chạy:

aws dms start-replication-task-assessment-run \
  --replication-task-arn <arn> \
  --service-access-role-arn <arn-role> \
  --result-location-bucket ket-qua-danh-gia \
  --include-only '["unsupported-data-types-in-source",
                   "table-with-no-primary-key-or-unique-index"]'

Nó cảnh báo trước những bảng mà
  data validation sẽ không so được

⚠ Và vì sao phương án B (table metrics) không đủ:

Table statistics cho số liệu:
  bao nhiêu dòng đã chèn, cập nhật,
  xoá, bao nhiêu DDL đã chạy
        ↓
    Đó là số ĐẾM
    → không phải so sánh giá trị
        ↓
    Số khớp mà nội dung sai vẫn
      không phát hiện được

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

Schema Conversion Tool chuyển đổi
  SCHEMA và mã (stored procedure,
  trigger, function)
        ↓
    Nó không chạm tới DỮ LIỆU
    → và không so sánh gì

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | So từng giá trị, không chỉ đếm dòng | | | Chạy liên tục kể cả trong giai đoạn CDC | | | Điều tiết được để không ảnh hưởng nguồn | |

⚠ Và validation chạy tiếp trong pha CDC là điểm mạnh:

Full load xong → validation so
  toàn bộ
        ↓
    CDC tiếp tục → validation so
      lại các dòng thay đổi
        ↓
    Tới lúc chuyển đổi, có bằng
      chứng dữ liệu vẫn khớp

⚠ Nhưng cần biết những kiểu dữ liệu bị bỏ qua:

LOB không so được đầy đủ
  (ValidationPartialLobSize)
        ↓
    Một số kiểu đặc thù của Oracle
      (XMLTYPE, SDO_GEOMETRY)
        ↓
    Đọc bảng kiểu dữ liệu không hỗ
      trợ trong tài liệu DMS

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

• **A. Cấu hình DMS premigration assessment để so sánh dữ liệu nguồn và đích, báo cáo chỗ lệch — đây là phương án gần nhất và đánh giá trước khi di trú thật sự là bước nên làm, nhưng nó chạy trước khi nạp dữ liệu và kiểm tính tương thích, không so sánh nội dung.
• **B. Dùng table metrics của tác vụ DMS để kiểm số liệu bảng và số câu DDL đã chạy — đó là số đếm, không phát hiện được dữ liệu sai giá trị.
• **C. Dùng Schema Conversion Tool để so sánh dữ liệu — SCT chuyển đổi schema và mã, không đụng tới dữ liệu.

Ghi nhớ

⚠ Ba công cụ trong bộ di trú CSDL của AWS — bảng phải thuộc: | Công cụ | Việc | |---|---| | SCT | chuyển đổi schema, stored procedure, trigger | | DMS | chuyển dữ liệu, có CDC | | DMS data validation | so sánh nguồn và đích |

Từ khoá nhận diện:

"validate data was migrated accurately" → DMS data validation "check compatibility before migrating" → premigration assessment "convert Oracle PL/SQL to PostgreSQL" → SCT "minimal downtime" → full load + CDC

Ba lưu ý về data validation: | Lưu ý | Chi tiết | |---|---| | Cần khoá chính hoặc chỉ mục duy nhất | | | Chạy trên replication instance, tốn tài nguyên | | | Kết quả nằm trong awsdms_validation_failures_v1 | |

⚠ Validation có thể cần instance lớn hơn:

Vừa nạp dữ liệu vừa so sánh
        ↓
    Replication instance làm hai
      việc cùng lúc
        ↓
    Cân nhắc chạy validation sau
      khi full load xong

Ba lưu ý về di trú không đồng nhất: | Bước | Công cụ | |---|---| | Chuyển schema | SCT | | Chuyển dữ liệu | DMS | | Chuyển mã ứng dụng | thủ công (SCT có gợi ý) |

Ba lưu ý về ánh xạ kiểu dữ liệu: | Nguồn Oracle | Đích MySQL | |---|---| | NUMBER(p,s) | DECIMAL(p,s) | | NUMBER không khai độ chính xác | DOUBLE — DỄ MẤT ĐỘ CHÍNH XÁC | | DATE | DATETIME | | CLOB | LONGTEXT |

⚠ NUMBER không khai độ chính xác là bẫy kinh điển:

Oracle NUMBER lưu chính xác
  tuyệt đối
        ↓
    Ánh xạ mặc định sang DOUBLE
    → số dấu phẩy động
        ↓
    Giá trị tiền bị lệch ở chữ số
      cuối
    → data validation phát hiện
      đúng loại lỗi này

Ba lưu ý về LOB: | Chế độ | Đặc điểm | |---|---| | Limited LOB | nhanh, cắt LOB quá kích thước khai | | Full LOB | đầy đủ, chậm hơn nhiều | | Inline LOB | cân bằng: nhỏ thì inline, lớn thì tra riêng |

⚠ Limited LOB cắt dữ liệu âm thầm:

`LobMaxSize` = 32 KB
        ↓
    LOB lớn hơn bị CẮT
    → không có lỗi
        ↓
    Đây là lý do phải validate

Ba lưu ý về hiệu năng nguồn: | Lưu ý | Chi tiết | |---|---| | Full load đọc rất nặng — chạy ngoài giờ cao điểm | | | Giảm MaxFullLoadSubTasks để nhẹ hơn | | | Hoặc đọc từ một standby thay vì primary | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem ValidationState của mọi bảng | | | Kiểm bảng nào bị No primary key | | | Đọc awsdms_validation_failures_v1 xem chi tiết lệch | |

Và một lời khuyên: hãy kiểm xem bảng nào bị đánh dấu "No primary key" trước khi tin vào kết quả validation. Những bảng đó bị bỏ qua âm thầm — và một báo cáo toàn màu xanh có thể chỉ nghĩa là DMS đã không so sánh phần dữ liệu quan trọng nhất.

Đáp án

**C — Dựng một VPC endpoint cho S3 và viết bucket policy chỉ cho phép truy cập qua endpoint đó.

Vì sao đúng

Đề mô tả một vector tấn công rất cụ thể:

Thành viên có quyền vào EC2 trong
  VPC riêng
        ↓
    Người đó dựng một EC2 khác ở
      VPC KHÁC
        ↓
    Máy mới cũng dùng được cùng
      vai trò IAM
    → đọc được artifact

⚠ Điểm mấu chốt: phải ràng buộc theo ĐƯỜNG ĐI, không phải theo danh tính:

Ràng buộc theo vai trò IAM
    → vai trò gắn được vào bất kỳ
      instance nào, ở bất kỳ VPC nào
        ↓
    Ràng buộc theo VPC endpoint
    → chỉ lưu lượng đi QUA endpoint
      cụ thể đó mới được chấp nhận

Bucket policy khoá theo endpoint:

{"Version": "2012-10-17", "Statement": [{
  "Sid": "ChiChoPhepQuaEndpoint",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": ["arn:aws:s3:::artifact-cong-ty",
               "arn:aws:s3:::artifact-cong-ty/*"],
  "Condition": {"StringNotEquals": {
    "aws:SourceVpce": "vpce-0abc123def456"}}}]}

⚠ aws:SourceVpce là khoá điều kiện phải nhớ: | Khoá | Kiểm tra | |---|---| | aws:SourceVpce | ID của VPC endpoint cụ thể | | aws:SourceVpc | ID của VPC | | aws:VpcSourceIp | IP nguồn trong VPC |

`aws:SourceVpc` cũng dùng được
    → nhưng `SourceVpce` chặt hơn
    → vì nó khoá tới đúng một
      endpoint

Tạo gateway endpoint cho S3:

aws ec2 create-vpc-endpoint --vpc-id vpc-rieng \
  --service-name com.amazonaws.ap-southeast-1.s3 \
  --vpc-endpoint-type Gateway \
  --route-table-ids rtb-subnet-rieng

⚠ Gateway endpoint cho S3 MIỄN PHÍ — không có lý do gì không dùng:

Gateway endpoint: miễn phí hoàn
  toàn
        ↓
    Và lưu lượng S3 không đi qua
      NAT gateway nữa
    → tiết kiệm luôn phí xử lý
      của NAT

⚠ Và vì sao phương án A (chỉ dùng IAM role) không chặn được:

Bucket policy cho phép "vai trò X"
        ↓
    Kẻ tấn công dựng EC2 ở VPC khác
      và gắn CÙNG vai trò X
    → nếu họ có quyền
      `iam:PassRole`
        ↓
    Bucket policy vẫn thấy đúng
      vai trò
    → cho qua

Đề nói rõ: "thành viên nào có
  quyền vào instance này CŨNG có
  thể dựng EC2 ở VPC khác"
        ↓
    Nghĩa là họ có quyền tạo
      instance và gán vai trò

⚠ Và vì sao phương án B (Elastic IP) không dùng được:

Instance nằm trong VPC RIÊNG
        ↓
    Subnet riêng không gắn được
      Elastic IP để đi ra
    → phải qua NAT gateway
        ↓
    Và IP của NAT có thể thay đổi
    → và ai cũng dựng được một
      NAT rồi khai IP đó

⚠ Và vì sao phương án D (security group) không dùng được:

Bucket policy KHÔNG có điều kiện
  nào theo security group
        ↓
    S3 không nhìn thấy security
      group của bên gọi
        ↓
    Đơn giản là không viết được
      chính sách như vậy

⚠ Có một khoá gần giống nhưng khác hẳn: aws:SourceIp:

"Condition": {"NotIpAddress": {
  "aws:SourceIp": "203.0.113.0/24"}}

Chỉ dùng được với IP CÔNG KHAI
        ↓
    Lưu lượng qua VPC endpoint có
      IP RIÊNG
    → `aws:SourceIp` không khớp
        ↓
    Phải dùng `aws:SourceVpce`

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ràng buộc theo đường mạng, không thể giả | | | Gateway endpoint miễn phí | | | Lưu lượng không ra Internet | |

⚠ Và endpoint policy là lớp thứ hai nên thêm:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::artifact-cong-ty/*"}]}

Bucket policy: chỉ endpoint này
  vào được bucket
        ↓
    Endpoint policy: qua endpoint
      này chỉ vào được bucket này
        ↓
    Hai chiều khoá lẫn nhau

⚠ Nhưng cần cẩn thận khi khoá cứng theo endpoint:

Chính sách Deny áp cho MỌI
  principal, kể cả bạn
        ↓
    Không truy cập được bucket từ
      console hay CLI trên máy cá
      nhân nữa
        ↓
    Nên chừa một ngoại lệ cho vai
      trò quản trị

"Condition": {
  "StringNotEquals": {"aws:SourceVpce": "vpce-0abc"},
  "ArnNotLike": {"aws:PrincipalArn":
    "arn:aws:iam::111122223333:role/QuanTriKhanCap"}}

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

• **A. Tạo IAM role cho phép truy cập artifact và bucket policy chỉ cho phép vai trò đó — đây là phương án gần nhất và là thực hành chuẩn trong hầu hết trường hợp, nhưng chính đề đã nêu vector tấn công là người dùng gắn cùng vai trò vào instance ở VPC khác, nên ràng buộc theo danh tính không đủ.
• **D. Đặt security group rất hạn chế và bucket policy chỉ cho phép từ security group đó — bucket policy không có điều kiện nào theo security group; S3 không nhìn thấy thông tin đó.
• **B. Gắn Elastic IP vào instance và bucket policy chỉ cho phép IP đó — instance nằm trong subnet riêng nên không gắn Elastic IP được, và ràng buộc theo IP dễ bị lách.

Ghi nhớ

⚠ Bốn khoá điều kiện ràng buộc theo mạng — bảng phải thuộc: | Khoá | Dùng khi | |---|---| | aws:SourceVpce | khoá theo một VPC endpoint cụ thể | | aws:SourceVpc | khoá theo cả VPC | | aws:SourceIp | IP công khai (KHÔNG dùng với endpoint) | | aws:VpcSourceIp | IP riêng bên trong VPC |

Từ khoá nhận diện:

"only from instances in this VPC" → VPC endpoint + aws:SourceVpce "only from our office network" → aws:SourceIp "only from within our organization" → aws:PrincipalOrgID "prevent data exfiltration" → endpoint policy + bucket policy

⚠ aws:PrincipalOrgID chống rò rỉ ra ngoài tổ chức:

"Condition": {"StringNotEquals": {
  "aws:PrincipalOrgID": "o-abc123xyz"}}

Kết hợp với Deny: không ai ngoài
  tổ chức đọc được bucket
        ↓
    Kể cả khi có ai lỡ tay cấp
      quyền cho tài khoản lạ

Ba lưu ý về gateway endpoint: | Lưu ý | Chi tiết | |---|---| | Chỉ có cho S3 và DynamoDB | | | MIỄN PHÍ | | | Hoạt động bằng cách thêm route vào bảng định tuyến | |

⚠ Gateway endpoint dùng prefix list trong bảng định tuyến:

pl-xxxxxx → vpce-0abc123
        ↓
    Không có IP cố định
    → security group phải dùng
      prefix list nếu cần lọc

Ba lưu ý về interface endpoint (PrivateLink): | Lưu ý | Chi tiết | |---|---| | Tạo ENI có IP riêng trong subnet | | | Tính phí theo giờ và GB | | | Có cho hầu hết dịch vụ AWS | |

Ba lưu ý về endpoint policy: | Lưu ý | Chi tiết | |---|---| | Mặc định cho phép tất cả | | | Giới hạn được tới từng bucket | | | Là lớp kiểm soát độc lập với bucket policy | |

Ba lưu ý về chống rò rỉ dữ liệu: | Lớp | Việc | |---|---| | Endpoint policy | qua endpoint chỉ tới được bucket của mình | | Bucket policy | bucket chỉ nhận từ endpoint của mình | | SCP với aws:ResourceOrgID | cấm gọi tới tài nguyên ngoài tổ chức |

⚠ aws:ResourceOrgID là khoá mới rất hữu ích:

{"Effect": "Deny", "Action": "s3:*", "Resource": "*",
 "Condition": {"StringNotEquals": {
   "aws:ResourceOrgID": "o-abc123xyz"}}}

Nhân viên không copy được dữ liệu
  sang bucket cá nhân của họ
        ↓
    Vì bucket đó không thuộc tổ chức

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail data event ghi truy cập object | | | VPC Flow Log ghi lưu lượng tới endpoint | | | Access Analyzer tìm bucket chia sẻ ra ngoài | |

Ba lưu ý về chẩn đoán: | Triệu chứng | Nguyên nhân hay gặp | |---|---| | AccessDenied từ trong VPC | thiếu route tới endpoint | | AccessDenied từ console | chính sách Deny áp cả cho bạn | | Hoạt động nhưng vẫn qua NAT | route table chưa gắn endpoint |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dựng EC2 ở VPC khác, thử đọc — phải bị từ chối | | | Đọc từ VPC đúng — phải được | | | Kiểm VPC Flow Log xem lưu lượng đi qua endpoint | |

Và một lời khuyên: hãy chừa một ngoại lệ cho vai trò quản trị khẩn cấp trước khi áp chính sách Deny theo endpoint. Câu lệnh Deny với Principal: "*" áp cho cả bạn — và khoá luôn chính mình ra khỏi bucket là chuyện xảy ra thường xuyên hơn nhiều người tưởng.

Đáp án

**D — Tạo một chứng chỉ riêng cho từng FQDN ở TỪNG Region bằng AWS Certificate Manager, rồi gắn chứng chỉ vào ALB tương ứng trong Region đó.

Vì sao đúng

Đề đưa ra một bài toán mở rộng và có một ràng buộc kỹ thuật cứng:

Hơn 500 ứng dụng, mỗi ứng dụng
  một FQDN
        ↓
    Chuyển từ một Region sang
      nhiều Region
        ↓
    HTTPS không được gián đoạn

⚠ Ràng buộc cứng: chứng chỉ ACM KHÔNG dùng được liên Region:

Chứng chỉ ACM là tài nguyên
  THEO REGION
        ↓
    ALB ở ap-southeast-1 chỉ gắn
      được chứng chỉ ở
      ap-southeast-1
        ↓
    Không có cách nào "dùng lại"
      cùng một chứng chỉ ACM ở
      Region khác

Đây là lý do phương án B sai — nó nói dùng cùng một chứng chỉ cho ALB ở nhiều Region.

⚠ Và ACM không cho xuất khoá riêng — nên cũng không copy được:

Chứng chỉ do ACM cấp: khoá riêng
  không bao giờ rời khỏi ACM
        ↓
    Không tải về được
    → không nhập sang Region khác
      được
        ↓
    Chỉ có cách: yêu cầu chứng chỉ
      MỚI ở Region đó

Yêu cầu chứng chỉ ở từng Region:

for vung in ap-southeast-1 us-east-1 eu-west-1; do
  aws acm request-certificate --region $vung \
    --domain-name "*.cong-ty.vn" \
    --subject-alternative-names "cong-ty.vn" \
    --validation-method DNS
done

⚠ Và với 500 FQDN, chứng chỉ wildcard là cách sống sót:

500 chứng chỉ riêng × N Region
        ↓
    Không quản nổi
        ↓
    Một wildcard `*.cong-ty.vn`
      phủ mọi tên miền con
    → một chứng chỉ mỗi Region

⚠ Nhưng wildcard chỉ phủ MỘT cấp:

`*.cong-ty.vn` phủ:
    app1.cong-ty.vn ✅
    app2.cong-ty.vn ✅
        ↓
    KHÔNG phủ:
    api.app1.cong-ty.vn ❌
        ↓
    Cần cấp sâu hơn: thêm
      `*.app1.cong-ty.vn` vào SAN

⚠ Và ACM cho phép tới 10 tên miền trong một chứng chỉ (mặc định):

aws acm request-certificate \
  --domain-name cong-ty.vn \
  --subject-alternative-names \
    "*.cong-ty.vn" "*.api.cong-ty.vn" "cong-ty.com"

Hạn ngạch nâng lên được
    → nhưng vẫn không tới 500
        ↓
    Wildcard là lời giải, không
      phải liệt kê

⚠ Và xác thực bằng DNS là điều bắt buộc ở quy mô này: | Cách xác thực | Gia hạn | |---|---| | DNS | TỰ ĐỘNG, chỉ cần bản ghi CNAME còn đó | | Email | phải bấm link mỗi lần gia hạn |

500 chứng chỉ × nhiều Region,
  xác thực bằng email
        ↓
    Hàng nghìn email phải bấm mỗi
      năm
    → không khả thi

⚠ Và có một mẹo: nhiều chứng chỉ ACM cùng tên miền dùng CHUNG một bản ghi CNAME:

Cấp `*.cong-ty.vn` ở ba Region
        ↓
    Cả ba yêu cầu CÙNG một bản ghi
      xác thực DNS
        ↓
    Tạo một lần trong Route 53
    → cả ba tự xác thực và tự gia hạn

⚠ Và vì sao hai phương án về KMS (A, C) sai hoàn toàn:

KMS quản lý KHOÁ MÃ HOÁ
        ↓
    Nó KHÔNG cấp chứng chỉ TLS
    → không có khái niệm CA trong KMS
        ↓
    Chứng chỉ TLS công khai:
      ACM hoặc CA bên ngoài
    → chứng chỉ riêng tư:
      ACM Private CA

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chứng chỉ miễn phí và tự gia hạn | | | Không phải quản khoá riêng | | | Mỗi Region độc lập, hỏng một chỗ không lan | |

⚠ Và cần nhớ ngoại lệ cho CloudFront: | Dịch vụ | Chứng chỉ ở Region | |---|---| | ALB, NLB | cùng Region với LB | | CloudFront | BẮT BUỘC us-east-1 | | API Gateway edge-optimized | BẮT BUỘC us-east-1 | | API Gateway regional | cùng Region |

Nếu đặt CloudFront trước các ALB
        ↓
    Vẫn cần một chứng chỉ ở
      us-east-1
    → dù không có ALB nào ở đó

⚠ Và Route 53 latency routing hoàn thiện bức tranh:

aws route53 change-resource-record-sets --hosted-zone-id Z123 \
  --change-batch '{"Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "app1.cong-ty.vn", "Type": "A",
      "SetIdentifier": "ap-southeast-1",
      "Region": "ap-southeast-1",
      "AliasTarget": {"HostedZoneId": "Z_ALB",
                      "DNSName": "alb-sg.elb.amazonaws.com",
                      "EvaluateTargetHealth": true}}}]}'

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

• **B. Cấp một chứng chỉ cho mỗi FQDN qua ACM và gắn cùng chứng chỉ đó cho ALB ở các Region — đây là phương án gần nhất và dùng đúng dịch vụ, nhưng chứng chỉ ACM là tài nguyên theo Region và không dùng chung liên Region được.
• **A. Cấp chứng chỉ riêng cho từng FQDN ở từng Region bằng AWS KMS — KMS quản lý khoá mã hoá, không cấp chứng chỉ TLS.
• **C. Tạo cặp khoá rồi cấp chứng chỉ qua AWS KMS và dùng chung liên Region — sai cả về dịch vụ lẫn về khả năng dùng chung.

Ghi nhớ

⚠ Bốn nơi lấy chứng chỉ TLS trên AWS — bảng phải thuộc: | Nguồn | Đặc điểm | |---|---| | ACM (công khai) | miễn phí, tự gia hạn, chỉ dùng với dịch vụ AWS | | ACM Private CA | chứng chỉ nội bộ, tính phí theo CA và chứng chỉ | | Nhập từ CA bên ngoài | tự quản gia hạn | | Kho chứng chỉ IAM | legacy, chỉ khi ACM chưa có ở Region đó |

Từ khoá nhận diện:

"certificate for ALB in each Region" → ACM ở từng Region "certificate for CloudFront" → ACM us-east-1 "install certificate on EC2" → ACM Private CA hoặc CA bên ngoài "free auto-renewing" → ACM với xác thực DNS

Ba lưu ý về ACM: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ do ACM cấp: khoá riêng không xuất được | | | Chỉ gắn được vào dịch vụ AWS tích hợp | | | Tự gia hạn nếu xác thực DNS còn hiệu lực | |

⚠ ACM cố gia hạn từ 60 ngày trước hạn:

Bản ghi CNAME xác thực bị xoá
        ↓
    Gia hạn thất bại
    → ACM gửi email cảnh báo
        ↓
    Không ai đọc → chứng chỉ hết hạn
    → website chết
        ↓
    Đặt EventBridge rule bắt sự kiện
      `ACM Certificate Approaching Expiration`

Ba lưu ý về wildcard: | Lưu ý | Chi tiết | |---|---| | Chỉ phủ MỘT cấp tên miền con | | | Phải thêm tên miền gốc vào SAN nếu cần | | | Một wildcard thay được hàng trăm chứng chỉ | |

Ba lưu ý về SNI: | Lưu ý | Chi tiết | |---|---| | ALB gắn được nhiều chứng chỉ, chọn theo SNI | | | CloudFront: SNI miễn phí, IP riêng rất đắt | | | Client rất cũ không hỗ trợ SNI | |

⚠ ALB gắn nhiều chứng chỉ là cách phục vụ nhiều FQDN:

aws elbv2 add-listener-certificates \
  --listener-arn <arn> \
  --certificates CertificateArn=<arn-cc-1> \
                 CertificateArn=<arn-cc-2>

Tối đa 25 chứng chỉ mỗi listener
  (nâng lên được)
        ↓
    Với 500 FQDN → dùng wildcard

Ba lưu ý về chính sách bảo mật TLS: | Lưu ý | Chi tiết | |---|---| | Chọn bản TLS13 mới nhất nếu client hỗ trợ | | | Bản cũ hỗ trợ client cũ nhưng bộ mã yếu hơn | | | Kiểm tra bằng SSL Labs sau khi đổi | |

Ba lưu ý về kiến trúc nhiều Region: | Thành phần | Cách làm | |---|---| | DNS | Route 53 latency hoặc geolocation routing | | Chứng chỉ | cấp riêng ở mỗi Region | | Kiểm tra sức khoẻ | health check cho từng endpoint |

Ba lưu ý về tự động hoá: | Lưu ý | Chi tiết | |---|---| | CloudFormation/CDK cấp chứng chỉ theo Region | | | StackSets triển khai cùng lúc nhiều Region | | | Bản ghi xác thực DNS tạo tự động nếu dùng Route 53 | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | openssl s_client tới ALB ở mỗi Region | | | Kiểm ngày hết hạn của mọi chứng chỉ | | | Đặt cảnh báo DaysToExpiry dưới 30 | |

Và một lời khuyên: hãy đặt cảnh báo EventBridge cho sự kiện chứng chỉ sắp hết hạn ngay từ đầu. ACM tự gia hạn rất đáng tin, nhưng nó im lặng thất bại khi bản ghi CNAME xác thực bị ai đó dọn dẹp — và với 500 tên miền, bạn sẽ không nhận ra cho tới khi một trong số đó ngừng phục vụ.

Đáp án

**D — Cấu hình WAF web ACL gửi log tới Amazon Data Firehose, Firehose ghi vào một bucket S3; rồi dùng Athena truy vấn log để tìm lỗi và truy vết.

Vì sao đúng

Đề nêu vấn đề rất rõ: log nằm trên máy và biến mất cùng với máy.

Instance khởi động lại
    → log và dữ liệu tạm mất theo
        ↓
    Sự việc "không để lại dấu vết"
        ↓
    Cần: ghi lại VĨNH VIỄN mọi
      lưu lượng đi vào ứng dụng

⚠ Điểm mấu chốt: "toàn bộ lưu lượng đi vào" — WAF nằm đúng chỗ đó:

Lưu lượng vào: WAF → ALB → EC2
        ↓
    WAF là chốt ĐẦU TIÊN
    → thấy mọi yêu cầu HTTP trước
      khi tới bất kỳ đâu
        ↓
    Và đề nói WAF đã được cấu hình
      trên ALB

⚠ Và log của WAF chứa đúng thứ cần cho việc điều tra:

{"timestamp": 1756684800000,
 "httpRequest": {
   "clientIp": "203.0.113.42",
   "country": "VN",
   "uri": "/dat-hang",
   "httpMethod": "POST",
   "headers": [{"name": "User-Agent", "value": "..."}]},
 "action": "ALLOW",
 "terminatingRuleId": "Default_Action",
 "rateBasedRuleList": []}

Bật ghi log cho WAF:

aws wafv2 put-logging-configuration --logging-configuration '{
  "ResourceArn": "arn:aws:wafv2:ap-southeast-1:111122223333:regional/webacl/bao-ve/abc",
  "LogDestinationConfigs": [
    "arn:aws:firehose:ap-southeast-1:111122223333:deliverystream/aws-waf-logs-ung-dung"],
  "RedactedFields": [{"SingleHeader": {"Name": "authorization"}}]}'

⚠ Tên luồng Firehose BẮT BUỘC bắt đầu bằng aws-waf-logs-:

Đặt tên khác
    → WAF từ chối cấu hình
        ↓
    Đây là ràng buộc cứng, rất dễ
      vấp lần đầu

⚠ Và RedactedFields che thông tin nhạy cảm:

Log ghi cả header
    → có thể chứa cookie phiên,
      token uỷ quyền
        ↓
    Che chúng đi trước khi lưu
    → log lưu lâu dài không trở
      thành kho bí mật

Truy vấn bằng Athena:

CREATE EXTERNAL TABLE waf_logs (
  timestamp bigint,
  httprequest struct<clientip:string, country:string,
                     uri:string, httpmethod:string>,
  action string,
  terminatingruleid string)
PARTITIONED BY (nam string, thang string, ngay string)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://log-waf/AWSLogs/';

SELECT httprequest.clientip, COUNT(*) AS so_luot
FROM waf_logs
WHERE nam='2026' AND thang='09' AND action='BLOCK'
GROUP BY httprequest.clientip
ORDER BY so_luot DESC LIMIT 20;

⚠ Và vì sao phương án A (access log của ELB) là lựa chọn hợp lý nhưng thua:

ALB access log ghi được vào S3
        ↓
    Nhưng ALB KHÔNG ghi thẳng vào
      Firehose
    → nó ghi thẳng vào S3
        ↓
    Phương án A mô tả sai luồng

aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn <arn> --attributes \
    Key=access_logs.s3.enabled,Value=true \
    Key=access_logs.s3.bucket,Value=log-alb

Đây là cách đúng để bật access
  log của ALB — thẳng vào S3

⚠ Và vì sao phương án B sai — CloudTrail không nhận log của WAF:

B nói "cấu hình WAF gửi log tới
  CloudTrail"
        ↓
    CloudTrail ghi lời gọi API
      QUẢN TRỊ
    → ai sửa web ACL, ai thêm luật
        ↓
    Nó KHÔNG ghi lưu lượng người
      dùng đi qua WAF

⚠ Và vì sao phương án C không đủ:

VPC Flow Log ghi ở tầng MẠNG
        ↓
    IP nguồn, IP đích, cổng, giao
      thức, ACCEPT/REJECT
        ↓
    KHÔNG có: đường dẫn URL,
      phương thức HTTP, header,
      user agent
        ↓
    Điều tra sự cố ứng dụng cần
      những thứ đó

⚠ Ba tầng log và nội dung của chúng: | Tầng | Log | Nội dung | |---|---|---| | Mạng | VPC Flow Log | IP, cổng, byte, accept/reject | | Cân bằng tải | ALB access log | URL, mã trạng thái, độ trễ, target | | Tường lửa ứng dụng | WAF log | URL, header, luật nào khớp, hành động |

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Log nằm ngoài instance, sống sót mọi sự cố | | | Chứa đủ chi tiết tầng ứng dụng | | | Athena truy vấn không cần dựng hạ tầng | |

⚠ Và Firehose cho phép biến đổi trước khi lưu:

Lambda trong Firehose
    → thêm trường, lọc bớt, đổi
      sang Parquet
        ↓
    Parquet giảm chi phí truy vấn
      Athena rất nhiều

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

⚠ Từ 2021, WAF gửi log thẳng tới S3 và CloudWatch Logs được, không cần qua Firehose.

aws wafv2 put-logging-configuration --logging-configuration '{
  "ResourceArn": "<arn-webacl>",
  "LogDestinationConfigs": ["arn:aws:s3:::aws-waf-logs-ung-dung"]}'

Với yêu cầu trong đề (lưu lâu dài
  + truy vấn bằng Athena)
        ↓
    S3 trực tiếp là đủ và đơn giản
      nhất
        ↓
    Firehose chỉ đáng thêm khi cần
      chuyển sang Parquet hoặc gửi
      song song sang SIEM

Và bản chất vấn đề trong đề là một vấn đề khác: log ứng dụng nằm trên đĩa instance. Cách chữa đúng cho việc đó là CloudWatch Agent đẩy log ra ngoài liên tục — chứ không phải thay bằng log của WAF, vốn chỉ ghi lưu lượng đi vào chứ không ghi hoạt động bên trong ứng dụng.

[/var/log/ung-dung/*.log]
file = /var/log/ung-dung/*.log
log_group_name = /ung-dung/san-xuat
log_stream_name = {instance_id}

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

• **A. Cấu hình ELB ghi access log vào Firehose rồi từ đó vào S3 — đây là phương án gần nhất và access log của ALB thật sự ghi được mọi yêu cầu đi vào, nhưng ALB ghi thẳng vào S3 chứ không gửi qua Firehose; luồng mô tả trong phương án không tồn tại.
• **B. Cấu hình WAF gửi log tới CloudTrail và tạo trail cho mọi Region — CloudTrail ghi lời gọi API quản trị, không ghi lưu lượng người dùng.
• **C. Dùng VPC Flow Log đẩy vào Kinesis Data Streams — flow log ở tầng mạng, không có URL, phương thức HTTP hay header.

Ghi nhớ

⚠ Bốn nguồn log cho lưu lượng web — bảng phải thuộc: | Nguồn | Tầng | Có URL | |---|---|---| | VPC Flow Log | mạng | KHÔNG | | ALB access log | 7 | CÓ | | WAF log | 7 | CÓ, kèm luật nào khớp | | CloudFront access log | 7, ở biên | CÓ |

Từ khoá nhận diện:

"record all incoming traffic permanently" → WAF log hoặc ALB access log vào S3 "which WAF rule blocked this" → WAF log "who called which AWS API" → CloudTrail "packets between ENIs" → VPC Flow Log

Ba lưu ý về WAF log: | Lưu ý | Chi tiết | |---|---| | Tên luồng Firehose phải bắt đầu aws-waf-logs- | | | RedactedFields che header nhạy cảm | | | Lọc được chỉ ghi yêu cầu bị chặn | |

⚠ Lọc log giảm chi phí đáng kể:

"LoggingFilter": {"DefaultBehavior": "DROP",
  "Filters": [{"Behavior": "KEEP", "Requirement": "MEETS_ANY",
    "Conditions": [{"ActionCondition": {"Action": "BLOCK"}}]}]}

Chỉ ghi yêu cầu bị CHẶN
    → giảm mạnh lượng log
        ↓
    Nhưng mất dấu vết của lưu lượng
      hợp lệ
    → cân nhắc theo mục đích

Ba lưu ý về Athena trên log: | Lưu ý | Chi tiết | |---|---| | Phân vùng theo ngày là bắt buộc | | | Parquet giảm chi phí quét rất nhiều | | | Partition projection bỏ được việc thêm phân vùng | |

⚠ Partition projection rất hợp với log:

TBLPROPERTIES (
  'projection.enabled'='true',
  'projection.ngay.type'='date',
  'projection.ngay.range'='2026/01/01,NOW',
  'projection.ngay.format'='yyyy/MM/dd')

Không cần chạy crawler hay
  ALTER TABLE ADD PARTITION
        ↓
    Athena tự suy ra phân vùng từ
      đường dẫn

Ba lưu ý về vòng đời log: | Tuổi | Lớp lưu trữ | |---|---| | 0-30 ngày | S3 Standard | | 30-90 ngày | Standard-IA | | trên 90 ngày | Glacier Instant Retrieval |

Ba lưu ý về log ứng dụng: | Lưu ý | Chi tiết | |---|---| | CloudWatch Agent đẩy log ra ngoài liên tục | | | Đừng để log chỉ nằm trên đĩa instance | | | Đặt log group retention để khỏi lưu vô hạn | |

⚠ Log group mặc định lưu VĨNH VIỄN:

aws logs put-retention-policy \
  --log-group-name /ung-dung/san-xuat --retention-in-days 90

Không đặt → trả tiền lưu trữ mãi

Ba lưu ý về bảo vệ log: | Lưu ý | Chi tiết | |---|---| | Bucket log ở tài khoản riêng | | | S3 Object Lock chống xoá | | | SCP cấm tắt ghi log | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi một yêu cầu và tìm nó trong log | | | Chấm dứt một instance, kiểm log vẫn còn | | | Chạy một truy vấn Athena mẫu | |

Và một lời khuyên: hãy đẩy cả log ứng dụng ra CloudWatch Logs song song với việc bật log của WAF. Log của WAF cho biết ai gửi yêu cầu gì tới, nhưng khi cần biết ứng dụng đã làm gì với yêu cầu đó, chỉ có log của chính ứng dụng mới trả lời được — và đó chính là thứ đã biến mất cùng với instance.

Đáp án

**A, C và D — Ở tài khoản sở hữu bucket, tạo một S3 access point cho từng bucket mà ứng dụng cần dùng, và đặt mọi ứng dụng trong một data lake VPC; tạo gateway endpoint cho S3 trong VPC đó, gắn endpoint policy chỉ cho phép truy cập qua access point, và khai bảng định tuyến; đồng thời thêm bucket policy từ chối truy cập từ ngoài data lake VPC.

Vì sao đúng

Ba đáp án ghép thành ba lớp khoá chồng lên nhau: | Lớp | Kiểm soát | |---|---| | Access point (C) | chia chính sách theo từng ứng dụng | | Endpoint policy (A) | qua endpoint này chỉ tới được access point | | Bucket policy (D) | bucket chỉ nhận lưu lượng từ VPC này |

⚠ Điểm mấu chốt: S3 Access Point tách chính sách khổng lồ thành nhiều chính sách nhỏ:

Hàng trăm ứng dụng dùng chung
  vài bucket
        ↓
    Một bucket policy phải chứa
      quy tắc cho tất cả
        ↓
    Bucket policy có giới hạn
      20 KB
    → và không ai đọc hiểu nổi
        ↓
    Mỗi ứng dụng một access point,
      mỗi access point một chính
      sách riêng

Tạo access point khoá theo VPC:

aws s3control create-access-point \
  --account-id 111122223333 \
  --name diem-truy-cap-phan-tich \
  --bucket ho-du-lieu-co-cau-truc \
  --vpc-configuration VpcId=vpc-ho-du-lieu

⚠ Khai vpc-configuration là access point chỉ dùng được TRONG VPC đó:

Access point kiểu VPC
    → không có endpoint Internet
        ↓
    Gọi từ ngoài VPC → không phân
      giải được, không tới được
        ↓
    Đây là ràng buộc mạng ở cấp
      access point

Chính sách của access point:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:role/UngDungPhanTich"},
  "Action": ["s3:GetObject"],
  "Resource":
    "arn:aws:s3:ap-southeast-1:111122223333:accesspoint/diem-truy-cap-phan-tich/object/bao-cao/*"}]}

⚠ Và bucket policy phải uỷ quyền cho access point:

{"Effect": "Allow",
 "Principal": {"AWS": "*"},
 "Action": "s3:*",
 "Resource": ["arn:aws:s3:::ho-du-lieu-co-cau-truc",
              "arn:aws:s3:::ho-du-lieu-co-cau-truc/*"],
 "Condition": {"StringEquals": {
   "s3:DataAccessPointAccount": "111122223333"}}}

Không có câu này: access point
  không có quyền gì
        ↓
    Bucket phải "uỷ quyền" cho
      access point trước

Bucket policy từ chối ngoài VPC (đáp án D):

{"Effect": "Deny",
 "Principal": "*",
 "Action": "s3:*",
 "Resource": ["arn:aws:s3:::ho-du-lieu-co-cau-truc",
              "arn:aws:s3:::ho-du-lieu-co-cau-truc/*"],
 "Condition": {"StringNotEquals": {
   "aws:SourceVpc": "vpc-ho-du-lieu"}}}

Endpoint policy (đáp án A):

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:ap-southeast-1:111122223333:accesspoint/*"}]}

⚠ Và vì sao gateway endpoint chứ không phải interface endpoint (loại F): | Loại | Cho S3 | Chi phí | |---|---|---| | Gateway | CÓ | MIỄN PHÍ | | Interface | CÓ | theo giờ + GB |

Đề nói "hiệu quả nhất"
        ↓
    Gateway endpoint miễn phí
    → và F còn nhắc "VPC gateway
      attachment" cho endpoint S3
    → khái niệm đó không tồn tại

⚠ Và vì sao phương án B và E sai — chúng giả định nhiều VPC:

B: "tạo access point cho từng ứng
  dụng TỪ TỪNG TÀI KHOẢN AWS"
        ↓
E: "TỪ MỖI VPC ứng dụng, tạo
  gateway endpoint"
        ↓
    Đề nói dữ liệu nằm trong CÙNG
      MỘT tài khoản, cùng Region
        ↓
    Đáp án C khai rõ: đặt mọi ứng
      dụng trong MỘT data lake VPC
    → nên B và E mâu thuẫn với C

⚠ Đây là điểm phải đọc kỹ: ba đáp án phải NHẤT QUÁN với nhau:

C nói gộp về một VPC
        ↓
    A nói tạo endpoint TRONG data
      lake VPC — khớp
        ↓
    D nói chặn ngoài data lake VPC
      — khớp
        ↓
    E nói tạo endpoint ở TỪNG VPC
      ứng dụng — mâu thuẫn với C

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chính sách chia nhỏ, dễ đọc, dễ kiểm toán | | | Ràng buộc theo mạng, không chỉ theo danh tính | | | Gateway endpoint miễn phí | |

⚠ Và Access Point còn có biến thể mạnh hơn: Object Lambda:

aws s3control create-access-point-for-object-lambda \
  --account-id 111122223333 \
  --name che-du-lieu \
  --configuration '{"SupportingAccessPoint": "<arn-ap>",
    "TransformationConfigurations": [{"Actions": ["GetObject"],
      "ContentTransformation": {"AwsLambda":
        {"FunctionArn": "<arn-lambda>"}}}]}'

Lambda biến đổi object khi ĐỌC
        ↓
    Che số thẻ, lọc cột, đổi định
      dạng — tuỳ theo ai đọc
        ↓
    Một bản dữ liệu, nhiều góc nhìn

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

• **E. Từ mỗi VPC ứng dụng, tạo gateway endpoint cho S3 và endpoint policy cho phép tới access point — đây là phương án gần nhất và cấu hình endpoint policy hoàn toàn đúng về kỹ thuật, nhưng nó giả định mỗi ứng dụng nằm ở một VPC riêng, mâu thuẫn với phương án C vốn gộp mọi ứng dụng vào một data lake VPC.
• **B. Tạo access point cho từng ứng dụng từ từng tài khoản AWS — đề nói bucket nằm trong cùng một tài khoản; access point tạo ở tài khoản sở hữu bucket.
• **F. Tạo interface endpoint cho S3 ở mỗi VPC và "VPC gateway attachment" — interface endpoint tính phí trong khi gateway endpoint miễn phí, và không có khái niệm gateway attachment cho endpoint S3.

Ghi nhớ

⚠ Bốn cách kiểm soát truy cập S3 — bảng phải thuộc: | Cách | Phạm vi | |---|---| | Bucket policy | cả bucket, giới hạn 20 KB | | IAM policy | theo danh tính | | Access point policy | theo từng ứng dụng/luồng truy cập | | Endpoint policy | theo đường mạng |

Từ khoá nhận diện:

"hundreds of applications sharing buckets" → S3 Access Point "only from within our VPC" → VPC endpoint + aws:SourceVpc "transform data on read per consumer" → S3 Object Lambda "bucket policy too large" → Access Point

Ba lưu ý về S3 Access Point: | Lưu ý | Chi tiết | |---|---| | Mỗi bucket tối đa 10.000 access point | | | Có ARN riêng, ứng dụng gọi ARN đó thay tên bucket | | | Kiểu VPC không có endpoint Internet | |

⚠ Ứng dụng phải gọi ARN của access point:

s3.get_object(
    Bucket='arn:aws:s3:ap-southeast-1:111122223333:'
           'accesspoint/diem-truy-cap-phan-tich',
    Key='bao-cao/2026-09.parquet')

Gọi tên bucket trực tiếp
    → bucket policy Deny chặn lại
      (nếu đã khoá theo access point)

Ba lưu ý về Multi-Region Access Point: | Lưu ý | Chi tiết | |---|---| | Một endpoint toàn cầu cho bucket ở nhiều Region | | | Tự định tuyến tới Region gần nhất | | | Có failover khi một Region hỏng | |

Ba lưu ý về gateway endpoint: | Lưu ý | Chi tiết | |---|---| | Miễn phí, chỉ cho S3 và DynamoDB | | | Thêm route vào bảng định tuyến | | | Không dùng được qua Transit Gateway hay peering | |

⚠ Điểm cuối là lý do gộp về một VPC hợp lý:

Gateway endpoint chỉ phục vụ VPC
  chứa nó
        ↓
    VPC khác không dùng chung được
        ↓
    Hoặc mỗi VPC một endpoint
      (vẫn miễn phí)
    → hoặc gộp ứng dụng vào một VPC

Ba lưu ý về Lake Formation: | Lưu ý | Chi tiết | |---|---| | Quyền chi tiết tới cột và dòng | | | Tích hợp Athena, Redshift Spectrum, EMR | | | Quản quyền tập trung cho data lake | |

⚠ Lake Formation là lớp trên access point:

Access point: kiểm soát ai đọc
  được ĐƯỜNG DẪN nào
        ↓
    Lake Formation: kiểm soát ai
      đọc được CỘT nào, DÒNG nào
        ↓
    Với data lake thật sự, cần cả hai

Ba lưu ý về chống rò rỉ: | Lớp | Việc | |---|---| | Bucket policy aws:SourceVpc | chỉ VPC mình vào được | | Endpoint policy | qua endpoint chỉ tới bucket mình | | SCP aws:ResourceOrgID | không gọi ra bucket ngoài tổ chức |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail data event ghi truy cập qua access point | | | S3 Storage Lens thống kê toàn cảnh | | | Access Analyzer tìm chia sẻ ra ngoài | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi tên bucket trực tiếp — phải bị từ chối | | | Gọi qua ARN access point — phải được | | | Gọi từ VPC khác — phải bị từ chối | |

Và một lời khuyên: hãy nhớ thêm câu uỷ quyền cho access point vào bucket policy. Access point không tự có quyền gì — bucket phải cho phép nó trước, và triệu chứng khi thiếu bước này là AccessDenied trong khi chính sách của access point trông hoàn toàn đúng.