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

Đáp án

**B — Khởi chạy một instance mới trong subnet mới từ một AMI tạo ra từ instance cũ, hướng lưu lượng sang instance mới bằng Route 53, rồi chấm dứt instance cũ.

Vì sao đúng

Đề nêu một ràng buộc mà AWS không cho phép vượt qua:

Đổi subnet của một EC2 instance
      đang tồn tại
        ↓
    KHÔNG có API nào làm được việc đó
        ↓
    Không có trong console, không có
      trong CLI

⚠ Điểm mấu chốt: subnet gắn với instance từ lúc khởi động và không đổi được:

Instance khởi động trong một subnet
        ↓
    ENI chính (eth0) nằm trong subnet
      đó
        ↓
    ENI chính KHÔNG tháo ra được khi
      instance đang chạy
        ↓
    Và cũng không tháo được khi
      instance đã dừng

Đây là lý do phương án A và D đều sai — cả hai giả định có thao tác đổi subnet.

⚠ Và ENI chính khác hẳn ENI phụ: | Loại ENI | Tháo ra được | |---|---| | Primary (eth0) | KHÔNG BAO GIỜ | | Secondary (eth1, eth2...) | CÓ |

Gắn thêm ENI từ subnet mới
        ↓
    Nhưng ENI chính vẫn ở subnet cũ
        ↓
    Không gỡ được nó
    → instance vẫn thuộc subnet cũ

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

⚠ Và ENI phụ phải cùng AZ với instance:

ENI gắn vào instance phải ở CÙNG
  Availability Zone
        ↓
    Đề nói subnet mới cùng AZ
    → về mặt này thì hợp lệ
        ↓
    Nhưng vẫn không gỡ được ENI chính

Quy trình đúng:

1. Tạo AMI từ instance hiện tại
        ↓
2. Khởi chạy instance mới trong
     subnet mới từ AMI đó
        ↓
3. Kiểm thử instance mới
        ↓
4. Đổi bản ghi Route 53 sang instance
     mới
        ↓
5. Chấm dứt instance cũ

Tạo AMI:

aws ec2 create-image \
  --instance-id i-cu123 \
  --name "ung-dung-web-$(date +%Y%m%d)" \
  --description "Ban sao de chuyen subnet" \
  --no-reboot

⚠ --no-reboot là con dao hai lưỡi:

Không có cờ này → instance khởi
  động lại để bảo đảm hệ tệp nhất
  quán
        ↓
    Có cờ này → không gián đoạn
        ↓
    Nhưng hệ tệp có thể không nhất
      quán
    → nên dừng dịch vụ ghi trước khi
      chụp

Khởi chạy instance mới:

aws ec2 run-instances \
  --image-id ami-moi123 \
  --instance-type m6i.large \
  --subnet-id subnet-moi \
  --security-group-ids sg-web \
  --iam-instance-profile Name=VaiTroUngDung

Đổi bản ghi Route 53:

aws route53 change-resource-record-sets --hosted-zone-id Z123 \
  --change-batch '{"Changes":[{
    "Action":"UPSERT",
    "ResourceRecordSet":{
      "Name":"ung-dung.cong-ty.vn",
      "Type":"A","TTL":60,
      "ResourceRecords":[{"Value":"10.0.2.15"}]}}]}'

⚠ Và TTL thấp là điều kiện để chuyển đổi nhanh:

TTL 300 giây
        ↓
    Client cache 5 phút
        ↓
    Đổi bản ghi xong vẫn còn lưu
      lượng tới máy cũ
        ↓
    Hạ TTL xuống 60 giây từ TRƯỚC
      khi chuyển

⚠ Và giữ instance cũ chạy thêm một thời gian:

Đổi DNS
        ↓
    Chờ ít nhất 2-3 lần TTL
        ↓
    Kiểm không còn lưu lượng tới máy
      cũ
        ↓
    Rồi mới chấm dứt

⚠ Và có một cách thay thế: dùng ALB thay vì Route 53:

Đăng ký instance mới vào target group
        ↓
    Chờ nó khoẻ mạnh
        ↓
    Gỡ instance cũ
        ↓
    Chuyển đổi tức thì, không phụ
      thuộc TTL DNS

aws elbv2 register-targets --target-group-arn <arn-tg> \
  --targets Id=i-moi456

aws elbv2 deregister-targets --target-group-arn <arn-tg> \
  --targets Id=i-cu123

⚠ Và cách này tận dụng connection draining:

Gỡ đăng ký instance cũ
        ↓
    ALB ngừng gửi yêu cầu mới
        ↓
    Nhưng cho yêu cầu đang xử lý
      hoàn tất
    → không cắt kết nối giữa chừng

⚠ Và cần chuyển cả những thứ không nằm trong AMI: | Thứ | Cách chuyển | |---|---| | Elastic IP | gỡ khỏi máy cũ, gắn vào máy mới | | EBS volume phụ | snapshot rồi tạo volume mới | | IAM instance profile | khai lại khi khởi chạy | | Tag | khai lại hoặc chép từ máy cũ | | Địa chỉ IP riêng | KHÔNG chuyển được — subnet khác |

⚠ Và địa chỉ IP riêng chắc chắn thay đổi:

Subnet mới có dải CIDR khác
        ↓
    IP riêng của instance mới nằm
      trong dải đó
        ↓
    Mọi nơi cài cứng IP cũ đều hỏng
    → đây là lý do dùng DNS

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hợp lệ về mặt kỹ thuật | | | Kiểm thử được máy mới trước khi chuyển | | | Quay lui bằng cách đổi DNS ngược | |

⚠ Và AMI mang theo mọi thứ trong ổ đĩa gốc:

Hệ điều hành, ứng dụng, cấu hình
        ↓
    Nhưng không mang theo:
      - dữ liệu trên EBS volume phụ
        (trừ khi khai `--block-device-mappings`)
      - trạng thái trong bộ nhớ
      - kết nối đang mở

⚠ Và nếu instance có EBS volume phụ:

aws ec2 create-image --instance-id i-cu123 \
  --name "ung-dung-day-du" \
  --block-device-mappings \
    'DeviceName=/dev/sdb,Ebs={SnapshotId=snap-abc,VolumeSize=100}'

Hoặc để mặc định — AMI tự chụp mọi
  volume đang gắn
        ↓
    Kiểm bằng `describe-images`

⚠ Và cách bền vững hơn là dùng Auto Scaling group:

Đặt instance trong ASG
        ↓
    Sửa launch template sang subnet
      mới
        ↓
    Instance refresh thay toàn bộ
        ↓
    Lần sau đổi subnet chỉ mất một
      lệnh

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name doi-web \
  --vpc-zone-identifier subnet-moi

aws autoscaling start-instance-refresh \
  --auto-scaling-group-name doi-web

⚠ Và đây là bài học kiến trúc: máy chủ nên là thứ thay được:

Instance đơn lẻ, cấu hình bằng tay
        ↓
    Mọi thay đổi hạ tầng đều thành
      dự án nhỏ
        ↓
    ASG + launch template + user data
    → thay máy là chuyện thường

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

• **C. Tạo một ENI mới trong subnet mới, gắn vào instance rồi gỡ ENI cũ — đây là phương án gần nhất và ENI phụ thật sự gắn và gỡ được khi instance đang chạy, nhưng ENI chính (eth0) không bao giờ tháo ra được, nên instance vẫn thuộc subnet cũ.
• **A. Đổi subnet của instance qua AWS Management Console — không có thao tác nào như vậy trong console.
• **D. Đổi subnet của instance qua AWS CLI — cũng không có API nào cho phép việc đó.

Ghi nhớ

⚠ Bốn thuộc tính KHÔNG đổi được sau khi khởi chạy instance — bảng phải thuộc: | Thuộc tính | Đổi được | |---|---| | Subnet (và VPC) | KHÔNG | | Availability Zone | KHÔNG | | Địa chỉ IP riêng chính | KHÔNG | | Kiểu instance | CÓ (phải dừng máy) | | Security group | CÓ (khi đang chạy) | | IAM instance profile | CÓ |

Từ khoá nhận diện:

"move instance to different subnet" → tạo AMI, khởi chạy máy mới "change instance type" → dừng máy, đổi, bật lại "change security group" → đổi trực tiếp được "change AZ" → cũng phải tạo máy mới

Ba lưu ý về ENI: | Lưu ý | Chi tiết | |---|---| | ENI chính không tháo được | | | ENI phụ phải cùng AZ | | | Số ENI tối đa tuỳ kiểu instance | |

⚠ ENI phụ hữu ích cho việc khác:

Gắn thêm ENI từ subnet quản trị
        ↓
    Tách lưu lượng quản trị khỏi
      lưu lượng ứng dụng
        ↓
    Hoặc giữ một IP riêng cố định
      khi thay máy
    → gỡ ENI khỏi máy cũ, gắn vào
      máy mới

Ba lưu ý về tạo AMI: | Lưu ý | Chi tiết | |---|---| | --no-reboot giữ máy chạy nhưng có rủi ro nhất quán | | | AMI tự chụp mọi volume đang gắn | | | AMI theo Region, phải copy sang Region khác | |

Ba lưu ý về chuyển đổi: | Cách | Tốc độ | |---|---| | Đổi bản ghi Route 53 | theo TTL | | Đăng ký/gỡ target ở ALB | tức thì | | Gỡ và gắn lại Elastic IP | tức thì |

⚠ Elastic IP chuyển được ngay:

aws ec2 associate-address \
  --instance-id i-moi456 --allocation-id eipalloc-abc

EIP tự gỡ khỏi máy cũ
        ↓
    Chuyển tức thì, không phụ thuộc
      DNS
        ↓
    Nhưng có gián đoạn ngắn

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | Hạ TTL nhiều ngày TRƯỚC khi chuyển | | | 60 giây là giá trị thường dùng | | | Nhiều client bỏ qua TTL | |

Ba lưu ý về những gì cần chuyển theo: | Thứ | Ghi chú | |---|---| | EBS volume phụ | snapshot rồi tạo lại | | Elastic IP | gắn lại | | Tag và instance profile | khai lại khi khởi chạy |

Ba lưu ý về thiết kế bền vững: | Lưu ý | Chi tiết | |---|---| | Đặt instance trong Auto Scaling group | | | Cấu hình bằng user data hoặc AMI dựng sẵn | | | Dùng DNS thay vì IP cài cứng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm ứng dụng chạy trên máy mới | | | Xem log truy cập của máy cũ đã hết lưu lượng | | | dig tên miền — phải ra IP mới | |

Và một lời khuyên: hãy hạ TTL của bản ghi DNS xuống 60 giây vài ngày trước khi chuyển. Việc đổi bản ghi chỉ mất vài giây, nhưng nếu TTL đang là 3.600 thì lưu lượng vẫn tới máy cũ suốt một giờ sau đó — và đó chính là khoảng thời gian bạn nghĩ mình đã chuyển xong.

Đáp án

**C — Dùng AWS Elemental MediaConvert xử lý video theo tệp và CloudFront để phân phối; dùng giao thức phát trực tuyến như HLS của Apple và tạo một tệp manifest; trỏ CloudFront distribution vào manifest đó.

Vì sao đúng

Đề nêu ba yêu cầu, và chỉ phát trực tuyến thích ứng đáp ứng cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Phát bắt đầu NHANH | HLS chia đoạn nhỏ, tải đoạn đầu là phát được | | Tua nhanh HIỆU QUẢ | nhảy thẳng tới đoạn cần, không tải cả tệp | | Không ngốn băng thông người dùng | bitrate thích ứng theo mạng |

⚠ Điểm mấu chốt: tệp MP4 nguyên khối không đáp ứng được ba yêu cầu đó:

Phục vụ một tệp MP4 lớn
        ↓
    Trình duyệt tải tuần tự
        ↓
    Tua tới phút thứ 40 → phải tải
      tới đó
        ↓
    Và luôn tải ở một chất lượng duy
      nhất
    → mạng yếu thì giật

⚠ Và HLS chia video thành nhiều đoạn nhỏ ở nhiều mức chất lượng:

Video gốc
        ↓
    MediaConvert chuyển mã thành:
      1080p, 720p, 480p, 360p
        ↓
    Mỗi mức chia thành đoạn 6-10 giây
        ↓
    Manifest liệt kê mọi đoạn và
      mọi mức

Tệp manifest chính:

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
1080p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2500000,RESOLUTION=1280x720
720p/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=854x480
480p/index.m3u8

⚠ Và trình phát tự chọn mức phù hợp — đây là "adaptive bitrate":

Bắt đầu ở mức thấp → phát ngay
        ↓
    Đo băng thông thực tế
        ↓
    Mạng tốt → chuyển lên 1080p
        ↓
    Mạng yếu → tụt xuống 480p
    → không giật, không ngốn băng
      thông thừa

⚠ Và tua nhanh chỉ cần tải đúng đoạn cần:

Người dùng kéo tới phút 40
        ↓
    Trình phát tính đoạn nào chứa
      thời điểm đó
        ↓
    Tải đúng đoạn đó từ CloudFront
    → gần như tức thì

Tạo job chuyển mã:

aws mediaconvert create-job \
  --role arn:aws:iam::111122223333:role/MediaConvert \
  --settings '{
    "Inputs": [{"FileInput": "s3://video-goc/phim.mp4"}],
    "OutputGroups": [{
      "Name": "Apple HLS",
      "OutputGroupSettings": {
        "Type": "HLS_GROUP_SETTINGS",
        "HlsGroupSettings": {
          "Destination": "s3://video-hls/phim/",
          "SegmentLength": 6,
          "MinSegmentLength": 0}},
      "Outputs": [
        {"NameModifier": "_1080p",
         "VideoDescription": {"Width": 1920, "Height": 1080,
           "CodecSettings": {"Codec": "H_264",
             "H264Settings": {"Bitrate": 5000000}}}},
        {"NameModifier": "_720p",
         "VideoDescription": {"Width": 1280, "Height": 720,
           "CodecSettings": {"Codec": "H_264",
             "H264Settings": {"Bitrate": 2500000}}}}]}]}'

⚠ Và vì sao phương án A thiếu bước chuyển mã:

A dùng S3 + CloudFront + HLS +
  manifest
        ↓
    Nhưng KHÔNG có bước tạo ra các
      đoạn HLS
        ↓
    Video gốc là MP4 nguyên khối
        ↓
    Không có gì để manifest trỏ tới
    → phải chuyển mã trước

⚠ Và đây là điểm phân biệt giữa A và C — chỉ khác một dịch vụ:

A: S3 lưu trữ + CloudFront + HLS
        ↓
    C: MediaConvert + CloudFront + HLS
        ↓
    Chỉ C có bước tạo ra nội dung HLS

⚠ Và vì sao phương án B thiếu HLS:

B có MediaConvert và CloudFront
        ↓
    Nhưng chỉ nói "CloudFront chuyển
      yêu cầu tới điểm biên tốt nhất"
        ↓
    Không nhắc tới giao thức phát
      trực tuyến hay manifest
        ↓
    → vẫn là phục vụ tệp
    → không có tua nhanh hiệu quả
      hay bitrate thích ứng

⚠ Và vì sao phương án D không giải quyết vấn đề gốc:

D dựng EC2 sau NLB ở nhiều Region
  với Global Accelerator
        ↓
    Giảm độ trễ MẠNG
        ↓
    Nhưng vẫn phục vụ tệp nguyên khối
        ↓
    Tua nhanh vẫn phải tải tuần tự
    → và tốn rất nhiều hạ tầng

Cấu hình CloudFront:

{"Origins": {"Items": [{
   "Id": "s3-video-hls",
   "DomainName": "video-hls.s3.ap-southeast-1.amazonaws.com",
   "S3OriginConfig": {"OriginAccessIdentity": ""},
   "OriginAccessControlId": "E1ABC"}]},
 "DefaultCacheBehavior": {
   "TargetOriginId": "s3-video-hls",
   "CachePolicyId": "658327ea-f89d-4fab-a63d-7e88639e58f6",
   "ViewerProtocolPolicy": "redirect-to-https"}}

⚠ Và cache của CloudFront rất hiệu quả với HLS:

Đoạn video là tệp tĩnh, không đổi
        ↓
    Đặt TTL rất dài
        ↓
    Đoạn phổ biến nằm ở điểm biên
    → phát tức thì cho người xem sau

⚠ Và manifest nên có TTL ngắn hơn đoạn: | Tệp | TTL đề xuất | |---|---| | Đoạn video (.ts, .m4s) | rất dài, bất biến | | Manifest (.m3u8) | ngắn với live, dài với VOD |

Video theo yêu cầu (VOD): manifest
  không đổi
        ↓
    TTL dài được
        ↓
    Phát trực tiếp: manifest cập nhật
      liên tục
    → TTL vài giây

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Phát bắt đầu trong một hai giây | | | Tua nhanh gần như tức thì | | | Chất lượng tự thích ứng với mạng | |

⚠ Và MediaConvert tạo được nhiều định dạng cùng lúc: | Giao thức | Hỗ trợ tốt trên | |---|---| | HLS | Apple, và hầu hết trình duyệt | | DASH | Android, trình duyệt hiện đại | | CMAF | dùng chung đoạn cho cả HLS và DASH |

⚠ CMAF tiết kiệm dung lượng đáng kể:

Tạo riêng HLS và DASH
        ↓
    Lưu hai bộ đoạn giống hệt nhau
        ↓
    CMAF: một bộ đoạn, hai manifest
    → giảm một nửa dung lượng và
      chi phí chuyển mã

⚠ Và bảo vệ nội dung bằng signed URL hoặc DRM:

CloudFront signed cookie cho cả
  thư mục HLS
        ↓
    Hoặc SPEKE với DRM (Widevine,
      FairPlay, PlayReady)
        ↓
    Signed URL không hợp vì có hàng
      trăm đoạn
    → cookie phủ cả tiền tố

⚠ Và MediaPackage là lớp bổ trợ cho việc đóng gói:

MediaConvert: chuyển mã theo tệp
        ↓
    MediaPackage: đóng gói và bảo vệ
      lúc phát
        ↓
    Tạo manifest động, chèn quảng cáo,
      giới hạn thời gian xem

⚠ Và cần bật Origin Shield cho nội dung video lớn:

Nhiều điểm biên cùng cache miss
        ↓
    Cùng kéo một đoạn từ S3
        ↓
    Origin Shield gom lại
    → S3 chỉ nhận một yêu cầu
    → giảm phí và tải cho origin

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

• **A. Dùng S3 lưu trữ và CloudFront phân phối, dùng HLS và tạo manifest, trỏ CloudFront vào manifest — đây là phương án gần nhất và mô tả đúng cách phân phối HLS, nhưng nó thiếu bước chuyển mã: video gốc phải được cắt thành các đoạn ở nhiều mức chất lượng trước thì manifest mới có gì để trỏ tới.
• **B. Dùng MediaConvert và CloudFront, trỏ distribution vào bucket chứa video — có chuyển mã nhưng không nhắc tới giao thức phát trực tuyến hay manifest, nên vẫn là phục vụ tệp.
• **D. Dựng EC2 sau NLB ở nhiều Region với Global Accelerator — giảm độ trễ mạng nhưng vẫn phục vụ tệp nguyên khối, và tốn rất nhiều hạ tầng.

Ghi nhớ

⚠ Bốn dịch vụ media của AWS — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | MediaConvert | chuyển mã theo TỆP (VOD) | | MediaLive | chuyển mã LUỒNG TRỰC TIẾP | | MediaPackage | đóng gói, bảo vệ, tạo manifest | | MediaTailor | chèn quảng cáo cá nhân hoá |

Từ khoá nhận diện:

"fast start, efficient seeking, adaptive quality" → HLS/DASH + manifest "file-based video processing" → MediaConvert "live stream" → MediaLive "insert ads" → MediaTailor

Ba lưu ý về HLS: | Lưu ý | Chi tiết | |---|---| | Manifest .m3u8 liệt kê các đoạn | | | Đoạn thường 6-10 giây | | | Nhiều mức bitrate cho thích ứng | |

⚠ Độ dài đoạn là đánh đổi:

Đoạn ngắn (2 giây): bắt đầu nhanh
  hơn, thích ứng nhanh hơn
        ↓
    Nhưng nhiều tệp hơn → nhiều yêu
      cầu hơn
        ↓
    Đoạn dài (10 giây): ít yêu cầu
    → nhưng phản ứng chậm với thay
      đổi mạng

Ba lưu ý về MediaConvert: | Lưu ý | Chi tiết | |---|---| | Tính phí theo phút video đầu ra | | | Nhiều đầu ra từ một job | | | Có preset dựng sẵn cho HLS, DASH | |

Ba lưu ý về CloudFront cho video: | Lưu ý | Chi tiết | |---|---| | Cache đoạn với TTL dài | | | Origin Shield giảm tải cho S3 | | | Signed cookie cho cả thư mục | |

Ba lưu ý về bảo vệ nội dung: | Cách | Mức độ | |---|---| | Signed cookie | kiểm soát truy cập | | DRM (SPEKE) | mã hoá nội dung | | Geo restriction | giới hạn theo quốc gia |

Ba lưu ý về chi phí: | Khoản | Cách giảm | |---|---| | Chuyển mã | chỉ tạo mức chất lượng thật sự cần | | Lưu trữ | vòng đời cho video cũ | | Phân phối | CloudFront rẻ hơn S3 trực tiếp |

⚠ Và số mức bitrate ảnh hưởng cả ba khoản:

Tạo 6 mức chất lượng
        ↓
    Chi phí chuyển mã và lưu trữ
      gấp 6 lần
        ↓
    3-4 mức thường là đủ
    → xem thống kê thiết bị của
      người dùng để quyết định

Ba lưu ý về trải nghiệm người xem: | Chỉ số | Ý nghĩa | |---|---| | Thời gian bắt đầu phát | dưới 2 giây là tốt | | Tỷ lệ buffer | dưới 1% thời gian xem | | Bitrate trung bình | càng cao càng tốt nếu không buffer |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo thời gian từ lúc bấm tới lúc phát | | | Tua tới giữa video và bấm giờ | | | Giả lập mạng chậm và xem có tự tụt chất lượng không | |

Và một lời khuyên: hãy cân nhắc CMAF nếu cần hỗ trợ cả HLS lẫn DASH. Tạo riêng hai bộ đoạn nghĩa là trả tiền chuyển mã và lưu trữ hai lần cho cùng một nội dung — còn CMAF dùng chung một bộ đoạn với hai tệp manifest khác nhau.

Đáp án

**A — Cài AWS Application Discovery Service trên từng máy ảo để thu thập dữ liệu cấu hình và mức sử dụng.

Vì sao đúng

Đề mô tả đúng tình huống mà Discovery Service sinh ra để giải quyết:

Trung tâm dữ liệu 10 năm tuổi
        ↓
    Tài liệu LỖI THỜI
        ↓
    Không ai biết hết những gì đang
      chạy
        ↓
    → cần KHẢO SÁT trước khi di trú

⚠ Điểm mấu chốt: Discovery Service thu thập ba nhóm dữ liệu: | Nhóm | Nội dung | |---|---| | Cấu hình | CPU, RAM, đĩa, hệ điều hành, phần mềm đã cài | | Mức sử dụng | CPU, bộ nhớ, I/O theo thời gian | | Phụ thuộc mạng | máy nào nói chuyện với máy nào, qua cổng nào |

Nhóm thứ ba là quan trọng nhất
        ↓
    Tài liệu không bao giờ ghi đủ
      phụ thuộc
        ↓
    Và đó chính là thứ làm hỏng đêm
      cutover

⚠ Và Discovery Service có hai chế độ — cần biết cả hai: | Chế độ | Cách hoạt động | |---|---| | Agent-based | cài agent lên TỪNG máy | | Agentless (Discovery Connector) | một OVA trên vCenter, không cài gì lên VM |

Đề nói "trộn Windows và Linux"
        ↓
    Không nói có VMware hay không
        ↓
    Agent-based hoạt động với mọi
      môi trường
    → và thu thập chi tiết hơn

Cài agent:

curl -o ./aws-discovery-agent.tar.gz \
  https://s3.us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/linux/latest/aws-discovery-agent.tar.gz
tar -xzf aws-discovery-agent.tar.gz
sudo bash install -r ap-southeast-1 \
  -k "AKIA..." -s "..."

Bắt đầu thu thập:

aws discovery start-data-collection-by-agent-ids \
  --agent-ids o-0000000123456789a o-0000000123456789b

⚠ Và agent-based thu thập chi tiết hơn agentless: | Dữ liệu | Agent | Agentless | |---|---|---| | Cấu hình phần cứng | CÓ | CÓ | | Mức dùng CPU, RAM | CÓ | CÓ | | Tiến trình đang chạy | CÓ | KHÔNG | | Kết nối mạng chi tiết | CÓ | hạn chế | | Cần cài lên VM | CÓ | không |

⚠ Và vì sao phương án D chỉ là một nửa:

D nói "đăng ký VM với Migration Hub
  để thu thập dữ liệu"
        ↓
    Migration Hub là nơi HIỂN THỊ và
      THEO DÕI
        ↓
    Nó không tự thu thập gì
        ↓
    Dữ liệu đến TỪ Discovery Service
      hoặc công cụ đối tác

⚠ Và Migration Hub là bảng điều khiển tổng hợp:

Discovery Service → gửi dữ liệu
        ↓
    MGN, DMS → báo cáo tiến độ
        ↓
    Công cụ đối tác → đẩy trạng thái
        ↓
    Migration Hub hiển thị tất cả
      ở một chỗ

⚠ Và vì sao phương án B sai — SMS đã ngừng:

AWS Server Migration Service
        ↓
    Đã ngừng, thay bằng Application
      Migration Service (MGN)
        ↓
    Và SMS là công cụ DI TRÚ
    → không phải công cụ khảo sát

⚠ Và vì sao phương án C hiểu sai công cụ:

Migration Portfolio Assessment
        ↓
    Là công cụ PHÂN TÍCH dữ liệu đã
      thu thập
        ↓
    Ước tính chi phí trên AWS, đề
      xuất chiến lược
        ↓
    Nó KHÔNG "kết nối tới từng VM"
    → nó nhận dữ liệu từ Discovery
      Service

⚠ Và MPA đã được thay bằng Migration Evaluator:

Migration Portfolio Assessment (MPA)
        ↓
    Nay là Migration Evaluator
        ↓
    Thu thập bằng agentless collector
      hoặc dữ liệu từ Discovery Service
        ↓
    Sinh báo cáo chi phí và kịch bản
      di trú

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Biết chính xác những gì đang chạy | | | Thấy phụ thuộc mà tài liệu không ghi | | | Có dữ liệu để tính đúng kích cỡ trên AWS | |

⚠ Và bản đồ phụ thuộc là kết quả giá trị nhất:

Máy chủ ứng dụng gọi một CSDL cũ
  mà không ai nhớ
        ↓
    Di trú ứng dụng, quên CSDL đó
        ↓
    Ứng dụng hỏng sau khi cutover
        ↓
    Bản đồ phụ thuộc bắt được điều đó

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

aws discovery list-configurations \
  --configuration-type SERVER \
  --query 'configurations[].[server.hostName,
                             server.osName,
                             server.agentId]' \
  --output table

⚠ Và xuất dữ liệu để phân tích sâu:

aws discovery start-export-task \
  --export-data-format CSV \
  --filters name=agentIds,values=o-0000000123456789a,condition=EQUALS

Kết quả xuất ra S3 dạng CSV
        ↓
    Phân tích bằng Athena hoặc
      QuickSight
    → hoặc đưa vào Migration Evaluator

⚠ Và nên chạy thu thập ÍT NHẤT hai tuần:

Mức sử dụng thay đổi theo ngày và
  theo tuần
        ↓
    Thu thập một ngày → thấy sai
      bức tranh
        ↓
    Hai tuần bắt được chu kỳ tuần
        ↓
    Một tháng bắt được cả chu kỳ
      cuối tháng

⚠ Và khảo sát thường phát hiện máy không ai dùng:

Kinh nghiệm thực tế: 10-20% máy
  chủ trong trung tâm dữ liệu cũ
  gần như không có tải
        ↓
    Di trú chúng = trả tiền cho thứ
      vô dụng
        ↓
    Chiến lược "Retire" trong 6R
    → thường tiết kiệm nhiều nhất

⚠ Và dữ liệu sử dụng cho phép chọn đúng kích cỡ instance:

Máy vật lý 32 GB RAM
        ↓
    Nhưng thực tế chỉ dùng 6 GB
        ↓
    Chọn instance theo cấu hình cũ
    → trả tiền cho công suất thừa
        ↓
    Chọn theo mức dùng thật
    → tiết kiệm rất lớn

⚠ Và Discovery Service miễn phí:

Không tính phí cho việc thu thập
        ↓
    Chỉ tính phí lưu dữ liệu xuất
      ra S3
        ↓
    Không có lý do gì không chạy
      trước khi di trú

⚠ Và quy trình khảo sát đầy đủ:

1. Cài agent hoặc collector
        ↓
2. Thu thập 2-4 tuần
        ↓
3. Xem bản đồ phụ thuộc trong
     Migration Hub
        ↓
4. Nhóm máy thành ứng dụng
        ↓
5. Chọn chiến lược 6R cho từng nhóm
        ↓
6. Ước tính chi phí bằng Migration
     Evaluator

⚠ Và nhóm máy thành ứng dụng là bước quan trọng:

aws discovery create-application \
  --name "He thong ban hang" \
  --description "Web + app + CSDL"

aws discovery associate-configuration-items-to-application \
  --application-configuration-id d-application-abc \
  --configuration-ids d-server-123 d-server-456

Di trú theo ỨNG DỤNG, không theo máy
        ↓
    Mọi thành phần của một ứng dụng
      phải chuyển cùng nhau

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

• **D. Đăng ký VM tại chỗ với Migration Hub để thu thập dữ liệu cấu hình và mức sử dụng — đây là phương án gần nhất và Migration Hub thật sự là nơi bạn xem toàn bộ dữ liệu khảo sát, nhưng nó chỉ hiển thị và theo dõi; việc thu thập do Discovery Service hoặc công cụ đối tác thực hiện.
• **C. Dùng Migration Portfolio Assessment kết nối tới từng VM — MPA (nay là Migration Evaluator) phân tích dữ liệu đã thu thập chứ không tự kết nối tới VM.
• **B. Triển khai SMS connector bằng OVA trên cụm VMware — SMS đã ngừng, và nó là công cụ di trú chứ không phải khảo sát.

Ghi nhớ

⚠ Bốn công cụ trong giai đoạn khảo sát — bảng phải thuộc: | Công cụ | Việc | |---|---| | Application Discovery Service | THU THẬP dữ liệu | | Migration Hub | HIỂN THỊ và theo dõi tiến độ | | Migration Evaluator | ước tính chi phí và kịch bản | | MGN | THỰC HIỆN di trú |

Từ khoá nhận diện:

"outdated documentation, unknown workloads" → Discovery Service "track migration progress" → Migration Hub "estimate AWS cost before migrating" → Migration Evaluator "migrate servers to EC2" → MGN

Ba lưu ý về Discovery Service: | Lưu ý | Chi tiết | |---|---| | Agent-based hoặc agentless | | | Miễn phí | | | Nên chạy ít nhất 2-4 tuần | |

⚠ Agentless collector cho VMware:

Triển khai một OVA trên vCenter
        ↓
    Thu thập từ mọi VM mà không cài
      gì lên chúng
        ↓
    Hợp khi không được phép cài agent
    → nhưng ít chi tiết hơn

Ba lưu ý về bản đồ phụ thuộc: | Lưu ý | Chi tiết | |---|---| | Chỉ agent-based mới thu thập đầy đủ | | | Cho biết máy nào gọi máy nào, cổng nào | | | Phát hiện phụ thuộc không có trong tài liệu | |

Ba lưu ý về chiến lược 6R: | Chiến lược | Khi nào | |---|---| | Retire | máy không ai dùng — kiểm tra trước tiên | | Rehost | lift-and-shift bằng MGN | | Replatform | đổi CSDL sang RDS | | Refactor | viết lại — tốn nhất |

⚠ Retire thường tiết kiệm nhiều nhất:

Khảo sát phát hiện máy có CPU dưới
  1% suốt hai tuần
        ↓
    Hỏi chủ sở hữu
        ↓
    Thường là hệ thống đã ngừng dùng
    → tắt đi thay vì di trú

Ba lưu ý về right-sizing: | Lưu ý | Chi tiết | |---|---| | Chọn theo mức dùng thật, không theo cấu hình cũ | | | Máy vật lý thường thừa công suất rất nhiều | | | Compute Optimizer tinh chỉnh tiếp sau khi lên AWS | |

Ba lưu ý về Migration Hub: | Lưu ý | Chi tiết | |---|---| | Chọn một Region làm home region | | | Nhóm máy thành ứng dụng | | | Theo dõi tiến độ từ nhiều công cụ | |

Ba lưu ý về kế hoạch: | Lưu ý | Chi tiết | |---|---| | Khảo sát trước, di trú sau | | | Di trú theo ứng dụng, không theo máy lẻ | | | Bắt đầu từ ứng dụng ít rủi ro nhất | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | So số máy phát hiện được với tài liệu | | | Xem bản đồ phụ thuộc tìm liên kết bất ngờ | | | Kiểm máy nào có mức dùng gần bằng 0 | |

Và một lời khuyên: hãy chạy khảo sát ít nhất bốn tuần trước khi lập kế hoạch di trú. Mức sử dụng của một trung tâm dữ liệu có chu kỳ theo tuần và theo tháng, và một mẫu vài ngày sẽ cho bạn con số sai — thường là quá thấp, dẫn tới việc chọn instance nhỏ hơn mức cần và phát hiện điều đó vào đúng ngày chốt sổ.

Đáp án

**A — Cấu hình một Route 53 Resolver inbound endpoint cho VPC chứa EFS; tạo một private hosted zone và thêm bản ghi CNAME trỏ tới tên DNS của EFS; cấu hình forwarding rule trên DNS server tại chỗ để chuyển tiếp truy vấn tên miền tuỳ chỉnh tới private hosted zone đó.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này khớp cả bốn: | Yêu cầu | Cách đáp ứng | |---|---| | Ứng dụng tại chỗ phân giải qua DNS tại chỗ | forwarding rule trên DNS server | | Truy vấn tới được Route 53 | inbound endpoint | | Dùng tên miền TUỲ CHỈNH | CNAME trong private hosted zone | | Tránh dùng IP của EFS mount target | phân giải qua tên |

⚠ Điểm mấu chốt thứ nhất: INBOUND vì truy vấn đi TỪ tại chỗ VÀO AWS:

Máy tại chỗ hỏi tên
        ↓
    DNS server tại chỗ chuyển tiếp
      tới Route 53
        ↓
    Truy vấn ĐI VÀO VPC
        ↓
    → INBOUND endpoint

⚠ Và cách nhớ: tên endpoint đặt theo hướng nhìn từ VPC: | Endpoint | Chiều truy vấn | |---|---| | Inbound | tại chỗ → VPC | | Outbound | VPC → tại chỗ |

Đây là lý do phương án C sai — nó dùng outbound.

⚠ Điểm mấu chốt thứ hai: PRIVATE hosted zone, không phải public:

Tên DNS của EFS chỉ phân giải được
  TRONG VPC
        ↓
    `fs-abc.efs.ap-southeast-1.amazonaws.com`
        ↓
    Public hosted zone phân giải từ
      Internet
    → nhưng tên EFS không có bản ghi
      công khai
        ↓
    → phải là private hosted zone

Đây là lý do phương án B và D đều sai.

⚠ Và CNAME là loại bản ghi đúng — không phải PTR:

CNAME: bí danh trỏ tới một tên khác
        ↓
    `efs.noi-bo.vn` → `fs-abc.efs...`
        ↓
    PTR: phân giải NGƯỢC, từ IP ra tên
        ↓
    Không dùng cho việc này

Đây là lý do phương án D sai ở vế thứ hai.

Tạo private hosted zone:

aws route53 create-hosted-zone \
  --name noi-bo.cong-ty.vn \
  --caller-reference $(uuidgen) \
  --vpc VPCRegion=ap-southeast-1,VPCId=vpc-efs \
  --hosted-zone-config PrivateZone=true

Thêm bản ghi CNAME:

aws route53 change-resource-record-sets --hosted-zone-id Z123 \
  --change-batch '{"Changes":[{
    "Action":"UPSERT",
    "ResourceRecordSet":{
      "Name":"kho-tep.noi-bo.cong-ty.vn",
      "Type":"CNAME","TTL":300,
      "ResourceRecords":[{
        "Value":"fs-0abc123.efs.ap-southeast-1.amazonaws.com"}]}}]}'

Tạo inbound endpoint:

aws route53resolver create-resolver-endpoint \
  --name endpoint-vao \
  --direction INBOUND \
  --security-group-ids sg-resolver \
  --ip-addresses SubnetId=subnet-1a SubnetId=subnet-1b \
  --creator-request-id $(uuidgen)

Cấu hình forwarder tại chỗ (BIND):

zone "noi-bo.cong-ty.vn" {
    type forward;
    forwarders { 10.0.1.50; 10.0.2.50; };
};

Hai IP là địa chỉ của inbound
  endpoint
        ↓
    Lấy bằng `describe-resolver-endpoints`

⚠ Và inbound endpoint cần tối thiểu HAI IP ở HAI AZ:

Route 53 Resolver yêu cầu ít nhất
  2 địa chỉ IP
        ↓
    Ở hai Availability Zone
        ↓
    DNS hỏng là ứng dụng chết
    → dự phòng là bắt buộc

⚠ Và security group phải mở cổng 53 CẢ UDP LẪN TCP:

aws ec2 authorize-security-group-ingress \
  --group-id sg-resolver \
  --ip-permissions \
    'IpProtocol=udp,FromPort=53,ToPort=53,IpRanges=[{CidrIp=192.168.0.0/16}]' \
    'IpProtocol=tcp,FromPort=53,ToPort=53,IpRanges=[{CidrIp=192.168.0.0/16}]'

⚠ Chỉ mở UDP là bẫy rất khó chẩn đoán:

Truy vấn nhỏ đi bằng UDP → chạy tốt
        ↓
    Phản hồi lớn (nhiều bản ghi,
      DNSSEC) dùng TCP
        ↓
    Chỉ một số tên miền không phân
      giải được
    → triệu chứng rất khó lần ra

⚠ Và vì sao đề muốn tránh dùng IP của mount target:

EFS có một mount target mỗi AZ
        ↓
    Mỗi cái một IP riêng
        ↓
    Mount bằng IP:
      - phải chọn AZ nào
      - IP không đổi nhưng cứng nhắc
      - mất AZ đó là mất kết nối
        ↓
    Mount bằng TÊN: Route 53 trả về
      IP của mount target trong AZ
      phù hợp

Mount từ máy tại chỗ:

sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,\
hard,timeo=600,retrans=2,noresvport \
  kho-tep.noi-bo.cong-ty.vn:/ /du-lieu-chung

⚠ Và tên miền tuỳ chỉnh cho phép đổi hệ tệp mà không sửa client:

Đổi sang một EFS mới
        ↓
    Chỉ sửa bản ghi CNAME
        ↓
    Mọi máy tại chỗ tự trỏ sang cái
      mới
    → không phải đụng vào cấu hình
      mount của từng máy

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tên ổn định, không phụ thuộc IP | | | Đổi hệ tệp không cần sửa client | | | Route 53 tự trả IP mount target phù hợp | |

⚠ Và có thể dùng chính tên EFS mà không cần CNAME:

Forwarder chuyển tiếp
  `efs.ap-southeast-1.amazonaws.com`
        ↓
    Máy tại chỗ mount thẳng bằng tên
      EFS
        ↓
    Nhưng đề yêu cầu TÊN MIỀN TUỲ
      CHỈNH
    → phải có CNAME

⚠ Và mount EFS từ tại chỗ cần kết nối Direct Connect hoặc VPN:

EFS chỉ có địa chỉ RIÊNG
        ↓
    Không truy cập được từ Internet
        ↓
    Phải có DX hoặc VPN
    → đề nói đã có môi trường lai

⚠ Và độ trễ NFS qua kết nối lai là điều phải tính:

NFS rất nhạy với độ trễ
        ↓
    Mỗi thao tác tệp là một vòng
      khứ hồi
        ↓
    Direct Connect: chấp nhận được
        ↓
    VPN qua Internet: độ trễ dao động
    → hiệu năng kém

⚠ Và nên dùng efs-utils khi mount từ EC2 trong VPC:

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

`efs-utils` hỗ trợ TLS và IAM
        ↓
    Nhưng nó dùng tên DNS của EFS
        ↓
    Từ tại chỗ thì dùng `nfs4` với
      tên tuỳ chỉnh

⚠ Và Route 53 Resolver có giới hạn thông lượng:

Mỗi ENI của endpoint xử lý khoảng
  10.000 truy vấn/giây
        ↓
    Tải DNS cao → thêm IP vào endpoint
        ↓
    Tối đa 6 IP mỗi endpoint

⚠ Và nên bật query logging để chẩn đoán:

aws route53resolver create-resolver-query-log-config \
  --name log-truy-van \
  --destination-arn <arn-log-group>

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

• **B. Inbound endpoint đúng nhưng dùng public hosted zone với bản ghi CNAME — đây là phương án gần nhất và chỉ khác đáp án đúng ở loại hosted zone, nhưng tên DNS của EFS chỉ phân giải được trong VPC nên public hosted zone sẽ trả về kết quả không dùng được.
• **C. Dùng outbound endpoint và public hosted zone — outbound dành cho truy vấn đi từ VPC ra tại chỗ, ngược với chiều cần thiết.
• **D. Inbound endpoint với public hosted zone và bản ghi PTR — sai cả loại hosted zone lẫn loại bản ghi; PTR dùng cho phân giải ngược từ IP ra tên.

Ghi nhớ

⚠ Hai loại Resolver endpoint — bảng phải thuộc: | Loại | Chiều truy vấn | Cần thêm | |---|---|---| | Inbound | tại chỗ → VPC | chỉ endpoint | | Outbound | VPC → tại chỗ | endpoint + resolver rule |

Từ khoá nhận diện:

"on-premises resolves AWS names" → inbound endpoint "AWS resolves on-premises names" → outbound endpoint + rule "custom domain name for AWS resource" → private hosted zone + CNAME "avoid using IP address" → phân giải qua tên

Ba lưu ý về private hosted zone: | Lưu ý | Chi tiết | |---|---| | Cần enableDnsSupport và enableDnsHostnames | | | Gắn được với nhiều VPC, nhiều Region | | | Gắn liên tài khoản cần authorization hai bước | |

⚠ Private zone thắng public zone trong VPC:

Truy vấn khớp private zone
        ↓
    Dùng private zone
        ↓
    Không tìm thấy bản ghi
    → NXDOMAIN, KHÔNG rơi về public

Ba lưu ý về inbound endpoint: | Lưu ý | Chi tiết | |---|---| | Tối thiểu 2 IP ở 2 AZ | | | Security group mở cổng 53 UDP và TCP | | | Mỗi ENI khoảng 10.000 truy vấn/giây | |

Ba loại bản ghi DNS hay dùng: | Loại | Việc | |---|---| | A | tên → IPv4 | | CNAME | tên → tên khác | | Alias | tên → tài nguyên AWS, miễn phí truy vấn | | PTR | IP → tên (phân giải ngược) |

⚠ CNAME không đặt được ở đỉnh tên miền:

`cong-ty.vn` không có CNAME được
        ↓
    Vì đỉnh phải có bản ghi NS và SOA
        ↓
    Route 53 Alias giải quyết được
    → nhưng chỉ cho tài nguyên AWS
      hỗ trợ

Ba lưu ý về EFS: | Lưu ý | Chi tiết | |---|---| | Một mount target mỗi AZ | | | Tên DNS trả về IP của mount target phù hợp | | | Mount từ tại chỗ cần DX hoặc VPN | |

Ba lưu ý về forwarding rule tại chỗ: | Lưu ý | Chi tiết | |---|---| | Chuyển tiếp có điều kiện theo tên miền | | | Trỏ tới IP của inbound endpoint | | | Cấu hình trên BIND, Windows DNS, Infoblox... | |

Ba lưu ý về chẩn đoán: | Việc | Cách | |---|---| | dig @<ip-inbound> ten.noi-bo.vn | thử trực tiếp | | Resolver query logging | xem truy vấn và kết quả | | Kiểm security group cổng 53 | |

Ba lưu ý về DNS Firewall: | Lưu ý | Chi tiết | |---|---| | Chặn truy vấn tới tên miền độc hại | | | Chống rò rỉ dữ liệu qua DNS tunneling | | | Có danh sách do AWS quản lý | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig kho-tep.noi-bo.vn từ máy tại chỗ | | | Mount thử và ghi một tệp | | | Kiểm IP trả về là mount target của AZ gần nhất | |

Và một lời khuyên: hãy mở cổng 53 cho cả UDP lẫn TCP trong security group của inbound endpoint. Phần lớn truy vấn DNS đi bằng UDP nên mọi thứ trông như hoạt động bình thường — cho tới khi một phản hồi vượt 512 byte và client phải thử lại bằng TCP, tạo ra lỗi phân giải chỉ xảy ra với vài tên miền nhất định.

Đáp án

**D — Dựng một CloudFront distribution và cấu hình nó cache object từ một custom origin; việc này giảm tải cho máy chủ tại chỗ. Tuỳ chỉnh hành vi cache bằng cách đặt TTL phù hợp với nhu cầu nghiệp vụ.

Vì sao đúng

Đề nêu ba ràng buộc, và CloudFront đáp ứng cả ba: | Ràng buộc | Cách đáp ứng | |---|---| | Chịu được đỉnh lưu lượng đột ngột | hơn 600 điểm biên hấp thụ | | Không cần nhiều công sức phát triển | chỉ cấu hình, không sửa mã | | Triển khai nhanh trước mùa sale | dựng trong vài phút |

⚠ Điểm mấu chốt: CloudFront dùng được với origin TẠI CHỖ:

Custom origin không nhất thiết phải
  ở AWS
        ↓
    Bất kỳ endpoint HTTP/HTTPS công
      khai nào
        ↓
    Kể cả máy chủ Linux trong trung
      tâm dữ liệu
    → không phải di trú gì cả

Cấu hình custom origin trỏ tới tại chỗ:

{"Origins": {"Items": [{
   "Id": "may-chu-tai-cho",
   "DomainName": "goc.cong-ty.vn",
   "CustomOriginConfig": {
     "HTTPPort": 80, "HTTPSPort": 443,
     "OriginProtocolPolicy": "https-only",
     "OriginSslProtocols": {"Quantity": 2,
       "Items": ["TLSv1.2", "TLSv1.3"]},
     "OriginReadTimeout": 30}}]}}

⚠ Và đây là lý do phương án B không đủ nhanh:

B dùng Elastic Beanstalk lift-and-shift
        ↓
    Phải đóng gói ứng dụng, thử
      nghiệm, di trú dữ liệu
        ↓
    Và CSDL vẫn ở tại chỗ hoặc phải
      di trú theo
        ↓
    Đề nói "không cần công sức phát
      triển đáng kể"
    → và mùa sale sắp tới

⚠ Và vì sao phương án C là công sức lớn nhất:

C đổi kiến trúc sang Docker và ECS
        ↓
    Phải đóng gói lại toàn bộ ứng dụng
        ↓
    Thay đổi cách vận hành, cách
      triển khai, cách giám sát
        ↓
    Đây là dự án nhiều tháng

⚠ Và vì sao phương án A không giải quyết đúng vấn đề:

A dựng website tĩnh trên S3 và
  Route 53 failover
        ↓
    Đó là trang "xin lỗi, chúng tôi
      đang quá tải"
        ↓
    Người dùng không mua hàng được
        ↓
    Đề muốn XỬ LÝ được lưu lượng
    → không phải hiển thị trang thay
      thế

⚠ Và CloudFront giảm tải theo tỷ lệ cache hit:

Website thương mại điện tử:
    - ảnh sản phẩm
    - CSS, JavaScript
    - trang danh mục
        ↓
    Phần lớn nội dung giống nhau cho
      mọi người
        ↓
    Cache hit 80-90%
    → máy chủ gốc chỉ nhận 10-20%
      lưu lượng

⚠ Và TTL là thứ quyết định tỷ lệ đó:

{"CachePolicy": {
   "DefaultTTL": 86400,
   "MaxTTL": 31536000,
   "MinTTL": 0}}

⚠ Và nên đặt TTL khác nhau theo loại nội dung: | Nội dung | TTL đề xuất | |---|---| | Ảnh, CSS, JS có mã băm trong tên | một năm | | Trang danh mục sản phẩm | vài phút | | Giá và tồn kho | vài giây hoặc không cache | | Giỏ hàng, thanh toán | KHÔNG cache |

Cache behavior cho nội dung tĩnh:

{"PathPattern": "/static/*",
 "TargetOriginId": "may-chu-tai-cho",
 "CachePolicyId": "658327ea-f89d-4fab-a63d-7e88639e58f6",
 "ViewerProtocolPolicy": "redirect-to-https",
 "Compress": true}

Cache behavior cho giỏ hàng:

{"PathPattern": "/gio-hang/*",
 "TargetOriginId": "may-chu-tai-cho",
 "CachePolicyId": "4135ea2d-6df8-44a3-9df3-4b5a84be39ad",
 "OriginRequestPolicyId": "216adef6-5c7f-47e4-b989-5492eafa07d3",
 "AllowedMethods": {"Quantity": 7,
   "Items": ["GET","HEAD","OPTIONS","PUT","POST","PATCH","DELETE"]}}

⚠ Và CachingDisabled cho nội dung động là bắt buộc:

Cache trang giỏ hàng
        ↓
    Người dùng A thấy giỏ hàng của
      người dùng B
        ↓
    Sự cố nghiêm trọng về quyền riêng
      tư
    → luôn tắt cache cho nội dung
      cá nhân hoá

⚠ Và ngay cả nội dung không cache cũng hưởng lợi từ CloudFront:

Kết nối TLS kết thúc ở điểm biên
        ↓
    Từ đó tới origin đi trên mạng
      xương sống AWS
        ↓
    Và kết nối tới origin được tái
      dùng (keep-alive)
    → giảm độ trễ và giảm số kết nối
      mới tới máy chủ gốc

⚠ Và Origin Shield giảm tải thêm một bậc:

"OriginShield": {"Enabled": true,
                 "OriginShieldRegion": "ap-southeast-1"}

Nhiều điểm biên cùng cache miss
        ↓
    Cùng kéo một object từ origin
        ↓
    Origin Shield gom lại
    → origin chỉ nhận MỘT yêu cầu
        ↓
    Rất quan trọng khi origin là máy
      chủ tại chỗ có băng thông hạn
      chế

⚠ Và nên bật nén để giảm băng thông của origin:

"Compress": true

CloudFront tự nén gzip hoặc brotli
        ↓
    Nhưng nó nén nội dung TỪ origin
        ↓
    Origin vẫn gửi bản chưa nén
    → bật nén ở chính máy chủ gốc
      để tiết kiệm băng thông

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Triển khai trong vài giờ | | | Không sửa một dòng mã nào | | | Giảm tải origin theo tỷ lệ cache hit | |

⚠ Và có thể thêm WAF ngay trên CloudFront:

Rate-based rule chống flood
        ↓
    Managed rule chống bot
        ↓
    Chặn ở biên, không tới origin

⚠ Và CloudFront có Shield Standard miễn phí:

Chống DDoS tầng 3/4 tự động
        ↓
    Bật sẵn cho mọi distribution
        ↓
    Origin tại chỗ được che sau nó

⚠ Nhưng phải bịt đường vào trực tiếp origin:

Kẻ tấn công tìm ra IP của máy chủ
  tại chỗ
        ↓
    Gọi thẳng, bỏ qua CloudFront
        ↓
    Bịt bằng:
      - header bí mật từ CloudFront
      - firewall chỉ nhận từ dải IP
        CloudFront

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

Với origin tại chỗ thì lấy dải IP
  từ tệp `ip-ranges.json` của AWS
        ↓
    Lọc theo service `CLOUDFRONT_ORIGIN_FACING`

⚠ Và đo tỷ lệ cache hit để biết hiệu quả thật:

aws cloudwatch get-metric-statistics \
  --namespace AWS/CloudFront --metric-name CacheHitRate \
  --dimensions Name=DistributionId,Value=E1ABC \
               Name=Region,Value=Global \
  --statistics Average --period 3600 \
  --start-time 2026-09-01T00:00:00Z \
  --end-time 2026-09-02T00:00:00Z

⚠ Và tỷ lệ hit thấp thường do cache key quá cụ thể:

Cache policy chuyển tiếp mọi header
  và cookie
        ↓
    Mỗi người dùng một khoá cache
      riêng
        ↓
    Tỷ lệ hit gần bằng 0
    → chỉ giữ những gì THẬT SỰ ảnh
      hưởng nội dung

⚠ Và query string cũng phá cache:

`?utm_source=facebook&fbclid=abc`
        ↓
    Mỗi lượt chia sẻ là một khoá mới
        ↓
    Cache policy chỉ giữ tham số có
      nghĩa
    → bỏ tham số theo dõi

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

• **B. Lift and shift ứng dụng bằng Elastic Beanstalk để tăng khả năng co giãn — đây là phương án gần nhất và thật sự giải quyết được vấn đề co giãn về lâu dài, nhưng nó đòi đóng gói lại ứng dụng, di trú dữ liệu và thử nghiệm, không kịp trước mùa sale và trái với yêu cầu "không cần công sức phát triển đáng kể".
• **C. Đổi kiến trúc sang Docker và ECS — công sức lớn nhất trong bốn phương án, là một dự án nhiều tháng.
• **A. Dựng website tĩnh trên S3 và Route 53 failover — đó là trang thay thế khi hệ thống chết, không giúp xử lý được lưu lượng.

Ghi nhớ

⚠ Bốn cách giảm tải cho máy chủ gốc — bảng phải thuộc: | Cách | Công sức | Hiệu quả | |---|---|---| | CloudFront cache | thấp nhất | cao với nội dung tĩnh | | Origin Shield | thấp | gom cache miss | | Di trú lên AWS + ASG | cao | giải quyết triệt để | | Viết lại kiến trúc | cao nhất | tốt nhất về lâu dài |

Từ khoá nhận diện:

"handle traffic spikes without development effort" → CloudFront trước origin hiện có "on-premises origin" → custom origin, hoàn toàn hợp lệ "failover to static site" → chỉ là trang thay thế, không xử lý được "reduce origin requests further" → Origin Shield

Ba lưu ý về custom origin: | Lưu ý | Chi tiết | |---|---| | Phải có endpoint HTTP/HTTPS công khai | | | Chứng chỉ phải do CA công cộng ký | | | Cài đủ chuỗi chứng chỉ | |

⚠ Chứng chỉ tự ký ở origin gây lỗi 502:

CloudFront kiểm chứng chứng chỉ của
  custom origin
        ↓
    Tự ký, hết hạn, hoặc thiếu chuỗi
    → 502 Bad Gateway
        ↓
    Khác với ALB, vốn chấp nhận tự ký

Ba lưu ý về cache policy: | Lưu ý | Chi tiết | |---|---| | Quyết định KHOÁ cache | | | Thêm header càng nhiều, cache càng phân mảnh | | | Có chính sách quản lý sẵn | |

⚠ Phân biệt cache policy và origin request policy:

Cache policy: cái gì tạo thành KHOÁ
        ↓
    Origin request policy: cái gì
      CHUYỂN TỚI origin
        ↓
    Origin cần header mà không muốn
      phân mảnh cache
    → để trong origin request policy

Ba lưu ý về TTL: | Loại nội dung | TTL | |---|---| | Tài nguyên có mã băm trong tên | một năm | | Trang danh mục | vài phút | | Giỏ hàng, thanh toán | không cache |

Ba lưu ý về bảo vệ origin: | Cách | Chi tiết | |---|---| | Header bí mật từ CloudFront | kiểm ở origin | | Firewall chỉ nhận dải IP CloudFront | lấy từ ip-ranges.json | | WAF trên CloudFront | chặn trước khi tới origin |

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | CacheHitRate | hiệu quả cache | | OriginLatency | origin phản hồi chậm không | | 5xxErrorRate | origin có lỗi không |

Ba lưu ý về kế hoạch dài hạn: | Bước | Việc | |---|---| | Ngắn hạn | CloudFront giảm tải ngay | | Trung hạn | di trú web tier lên AWS | | Dài hạn | di trú CSDL, co giãn tự động |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem header X-Cache trong phản hồi | | | Đo lưu lượng tới origin trước và sau | | | Chạy thử tải với đỉnh dự kiến | |

Và một lời khuyên: hãy rà lại cache policy và đo tỷ lệ cache hit ngay sau khi bật CloudFront. Toàn bộ giá trị của giải pháp này nằm ở việc origin chỉ nhận phần nhỏ lưu lượng — và một cache key chứa cookie phiên hay tham số theo dõi sẽ khiến tỷ lệ hit gần bằng không mà mọi thứ vẫn trông như đang hoạt động.

Đáp án

**D và E — Thêm dải CIDR của subnet hoặc địa chỉ IP của replication instance vào quy tắc vào của security group của cụm Redshift; và cụm Redshift phải nằm trong CÙNG tài khoản và CÙNG Region với replication instance.

Vì sao đúng

Hai mệnh đề này là hai ràng buộc cứng khi dùng DMS với Redshift làm đích.

⚠ Ràng buộc thứ nhất: DMS kết nối tới Redshift qua mạng, cần mở security group:

Replication instance nằm trong VPC
        ↓
    Nó kết nối tới cụm Redshift qua
      cổng 5439
        ↓
    Security group của cụm phải cho
      phép
        ↓
    Thiếu → tác vụ thất bại với lỗi
      kết nối

aws ec2 authorize-security-group-ingress \
  --group-id sg-redshift \
  --protocol tcp --port 5439 \
  --cidr 10.0.1.0/24

⚠ Và có thể dùng chính security group thay vì CIDR:

aws ec2 authorize-security-group-ingress \
  --group-id sg-redshift \
  --protocol tcp --port 5439 \
  --source-group sg-dms

Tham chiếu security group chặt hơn
        ↓
    Và tự đúng khi replication
      instance đổi IP

⚠ Ràng buộc thứ hai: cùng tài khoản và cùng Region là bắt buộc:

DMS ghi vào Redshift qua một bucket
  S3 TRUNG GIAN
        ↓
    Rồi phát lệnh `COPY`
        ↓
    Toàn bộ luồng đó đòi cùng Region
        ↓
    Và DMS cần quyền trong cùng tài
      khoản

⚠ Và đây là điều đáng nhớ vì nó khác với đích khác: | Đích của DMS | Liên Region | |---|---| | RDS, Aurora | được (qua peering hoặc endpoint công khai) | | S3 | được | | Redshift | KHÔNG — phải cùng Region |

⚠ Và DMS dùng bucket S3 trung gian — chi tiết quan trọng:

DMS ghi tệp CSV vào một bucket do
  nó tự tạo
        ↓
    Rồi chạy `COPY` từ bucket đó vào
      Redshift
        ↓
    `COPY` chạy song song trên mọi
      slice
    → nhanh hơn `INSERT` rất nhiều

⚠ Và vì sao mệnh đề B sai — versioning không liên quan:

B nói phải bật versioning cho bucket
  trung gian trước khi chạy tác vụ
        ↓
    DMS tự quản bucket đó
        ↓
    Versioning không phải yêu cầu
        ↓
    Và bật nó chỉ làm tích luỹ phiên
      bản rác

⚠ Và vì sao mệnh đề C sai — DMS KHÔNG tự tạo vai trò:

C nói "DMS tự tạo IAM role và
  policy cần thiết"
        ↓
    DMS cần ba vai trò có tên CỐ ĐỊNH
        ↓
    Console tạo giúp trong một số
      trường hợp
        ↓
    Nhưng dùng CLI hoặc CloudFormation
      thì PHẢI tạo trước

Ba vai trò của DMS phải tạo trước:

dms-vpc-role
dms-cloudwatch-logs-role
dms-access-for-endpoint

aws iam create-role --role-name dms-vpc-role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "dms.amazonaws.com"},
      "Action": "sts:AssumeRole"}]}'

aws iam attach-role-policy --role-name dms-vpc-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AmazonDMSVPCManagementRole

⚠ Và tên vai trò phải ĐÚNG CHÍNH XÁC:

DMS tìm vai trò theo TÊN cố định
        ↓
    Đặt tên khác → DMS không tìm thấy
        ↓
    Lỗi khi tạo replication instance
    → và thông báo lỗi không rõ ràng

⚠ Và vì sao mệnh đề A sai — DMS không có "custom DNS names":

A nói DMS hỗ trợ tên DNS tuỳ chỉnh
  bên cạnh tên do Amazon cấp
        ↓
    Không có tính năng nào như vậy
        ↓
    Endpoint của DMS khai bằng
      hostname hoặc IP
    → nhưng đó là cấu hình endpoint,
      không phải "custom DNS names"

Tạo endpoint Redshift:

aws dms create-endpoint \
  --endpoint-identifier dich-redshift \
  --endpoint-type target \
  --engine-name redshift \
  --server-name cum.abc.ap-southeast-1.redshift.amazonaws.com \
  --port 5439 --database-name kho \
  --username dms_user --password '...' \
  --redshift-settings '{
    "BucketName": "dms-trung-gian",
    "ServiceAccessRoleArn":
      "arn:aws:iam::111122223333:role/dms-access-for-endpoint"}'

⚠ Và vai trò dms-access-for-endpoint cần quyền S3 và Redshift:

{"Effect": "Allow",
 "Action": ["s3:PutObject", "s3:DeleteObject",
            "s3:GetObject", "s3:ListBucket",
            "redshift:DescribeClusters"],
 "Resource": "*"}

Ba lợi ích khi cấu hình đúng: | Lợi ích | Chi tiết | |---|---| | Tác vụ chạy được ngay từ lần đầu | | | COPY song song nạp nhanh | | | Có CDC để đồng bộ liên tục | |

⚠ Và nên bật data validation để kiểm chứng:

--replication-task-settings '{
  "ValidationSettings": {
    "EnableValidation": true,
    "ValidationMode": "ROW_LEVEL",
    "ThreadCount": 5}}'

So từng dòng giữa nguồn và đích
        ↓
    Phát hiện lỗi ánh xạ kiểu dữ liệu
        ↓
    Đề nói "chạy thử một phần"
    → validation là bước bắt buộc

⚠ Và ánh xạ kiểu dữ liệu là chỗ hay sai nhất: | Nguồn | Đích Redshift | Rủi ro | |---|---|---| | NUMBER không khai độ chính xác | DOUBLE | mất độ chính xác | | CLOB, BLOB | VARCHAR giới hạn | bị cắt | | TIMESTAMP WITH TIME ZONE | TIMESTAMP | mất múi giờ |

⚠ Và Redshift có giới hạn kích thước cột:

`VARCHAR` tối đa 65.535 byte
        ↓
    Cột text lớn hơn bị cắt
        ↓
    Redshift không có kiểu `TEXT`
      không giới hạn
    → cân nhắc để dữ liệu lớn ở S3

⚠ Và nên khai DISTKEY và SORTKEY cho bảng đích:

CREATE TABLE giao_dich (
    ma_giao_dich BIGINT,
    ma_khach     VARCHAR(32) DISTKEY,
    ngay         DATE        SORTKEY,
    so_tien      DECIMAL(12,2));

DMS tự tạo bảng nếu chưa có
        ↓
    Nhưng bảng đó không có DISTKEY
      hay SORTKEY
        ↓
    Tạo bảng TRƯỚC với khoá đúng
    → hiệu năng truy vấn khác hẳn

⚠ Và replication instance phải đủ lớn:

Instance nhỏ
        ↓
    Full load chậm
        ↓
    CDC không bắt kịp thay đổi
    → độ trễ tăng dần, không về 0
        ↓
    Bắt đầu với `dms.c5.large` trở lên
      cho tải thật

⚠ Và DMS Serverless bỏ được việc chọn kích thước:

aws dms create-replication-config \
  --replication-config-identifier di-tru-kho \
  --source-endpoint-arn <arn-nguon> \
  --target-endpoint-arn <arn-redshift> \
  --replication-type full-load-and-cdc \
  --compute-config MinCapacityUnits=1,MaxCapacityUnits=16

⚠ Và cần theo dõi bảng lỗi của Redshift khi COPY thất bại:

SELECT starttime, filename, line_number, colname, err_reason
FROM stl_load_errors
ORDER BY starttime DESC LIMIT 20;

DMS báo tác vụ chạy
        ↓
    Nhưng `COPY` thất bại vì một dòng
      sai định dạng
        ↓
    Bảng đích trống mà không có lỗi
      rõ ràng ở DMS

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

• **C. DMS tự tạo các IAM role và policy cần thiết — đây là phương án gần nhất và console của DMS thật sự tạo giúp trong một số trường hợp, nhưng ba vai trò dms-vpc-role, dms-cloudwatch-logs-role và dms-access-for-endpoint phải tồn tại với đúng tên trước khi tạo replication instance bằng CLI hoặc CloudFormation.
• **B. Bật versioning cho bucket S3 trung gian trước khi chạy tác vụ — DMS tự quản bucket đó, versioning không phải yêu cầu và chỉ tích luỹ phiên bản rác.
• **A. DMS hỗ trợ custom DNS name bên cạnh tên do Amazon cấp — không có tính năng nào như vậy.

Ghi nhớ

⚠ Bốn điều kiện để DMS ghi vào Redshift — bảng phải thuộc: | Điều kiện | Chi tiết | |---|---| | Cùng tài khoản | bắt buộc | | Cùng Region | bắt buộc | | Security group mở cổng 5439 | cho replication instance | | Vai trò dms-access-for-endpoint | quyền S3 và Redshift |

Từ khoá nhận diện:

"DMS to Redshift" → cùng account, cùng Region "DMS creates roles automatically" → SAI với CLI/CloudFormation "validate data was migrated" → DMS data validation "minimal downtime" → full load + CDC

Ba lưu ý về DMS: | Lưu ý | Chi tiết | |---|---| | Replication instance phải đủ lớn | | | Đặt trong VPC nhìn được cả nguồn và đích | | | DMS Serverless tự co giãn | |

Ba vai trò IAM của DMS: | Vai trò | Việc | |---|---| | dms-vpc-role | quản ENI trong VPC | | dms-cloudwatch-logs-role | ghi log | | dms-access-for-endpoint | truy cập S3, Redshift, Kinesis... |

Ba lưu ý về CDC: | Lưu ý | Chi tiết | |---|---| | Nguồn phải bật ghi log thay đổi | | | Bảng không có khoá chính gây vấn đề | | | DDL trong lúc chạy có thể làm hỏng tác vụ | |

⚠ Yêu cầu bật log theo engine: | Engine | Cấu hình | |---|---| | Oracle | supplemental logging, ARCHIVELOG | | PostgreSQL | wal_level = logical | | MySQL | binlog định dạng ROW | | SQL Server | CDC hoặc MS-REPLICATION |

Ba lưu ý về Redshift làm đích: | Lưu ý | Chi tiết | |---|---| | DMS dùng bucket S3 trung gian | | | Tạo bảng trước với DISTKEY và SORTKEY | | | Kiểm stl_load_errors khi có vấn đề | |

Ba lưu ý về data validation: | Lưu ý | Chi tiết | |---|---| | Cần khoá chính hoặc chỉ mục duy nhất | | | Kết quả trong awsdms_validation_failures_v1 | | | Bảng thiếu khoá bị bỏ qua âm thầm | |

Ba lưu ý về hiệu năng: | Lưu ý | Chi tiết | |---|---| | MaxFullLoadSubTasks điều khiển mức song song | | | Full load nặng cho nguồn — chạy ngoài giờ | | | Theo dõi CDCLatencyTarget | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đếm số dòng mỗi bảng hai bên | | | Bật data validation | | | Đọc stl_load_errors của Redshift | |

Và một lời khuyên: hãy tạo bảng đích trong Redshift với DISTKEY và SORTKEY trước khi chạy tác vụ DMS. DMS tự tạo bảng nếu chưa có, nhưng bảng nó tạo không có khoá phân bố hay khoá sắp xếp nào — và với một kho dữ liệu thì đó là khác biệt giữa truy vấn vài giây và truy vấn vài phút.

Đáp án

**A — Tạo một bucket S3 duy nhất; tạo một IAM user cho mỗi khách hàng; gom họ vào một IAM group có chính sách cho phép truy cập thư mục con trong bucket bằng biến chính sách username; và hướng dẫn khách hàng dùng client S3 thay cho client FTP.

Vì sao đúng

Đề nêu ba yêu cầu, và biến chính sách giải quyết cả ba: | Yêu cầu | Cách đáp ứng | |---|---| | Co giãn tốt hơn | S3 không giới hạn dung lượng | | Giảm chi phí | một bucket, một chính sách | | Cách ly hoàn toàn giữa khách hàng | biến ${aws:username} trong Resource |

⚠ Điểm mấu chốt: biến chính sách cho phép MỘT chính sách phục vụ MỌI khách hàng:

{"Version": "2012-10-17", "Statement": [
  {"Sid": "ChoPhepLietKeThuMucCuaMinh",
   "Effect": "Allow",
   "Action": "s3:ListBucket",
   "Resource": "arn:aws:s3:::kho-khach-hang",
   "Condition": {"StringLike": {
     "s3:prefix": ["${aws:username}/*"]}}},
  {"Sid": "ChoPhepThaoTacTrongThuMucCuaMinh",
   "Effect": "Allow",
   "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
   "Resource": "arn:aws:s3:::kho-khach-hang/${aws:username}/*"}]}

⚠ ${aws:username} được IAM thay bằng tên user đang gọi:

User `khach-a` gọi API
        ↓
    IAM thay biến → `kho-khach-hang/khach-a/*`
        ↓
    User `khach-b` gọi cùng chính sách
    → `kho-khach-hang/khach-b/*`
        ↓
    Một chính sách, cách ly hoàn toàn

⚠ Và đây là lý do nó mở rộng được:

Thêm khách hàng thứ 201
        ↓
    Chỉ tạo IAM user và thêm vào group
        ↓
    KHÔNG sửa chính sách
        ↓
    Phương án B: thêm một bucket và
      một bucket policy nữa

⚠ Và vì sao phương án B chạm hạn ngạch:

B tạo một bucket cho mỗi khách hàng
        ↓
    200 khách → 200 bucket
        ↓
    Hạn ngạch mặc định 100 bucket
      mỗi tài khoản
        ↓
    Nâng được lên 1.000
    → nhưng vẫn không mở rộng vô hạn

⚠ Và quản lý 200 bucket là gánh nặng thật:

Mỗi bucket cần:
    - bucket policy
    - cấu hình mã hoá
    - luật vòng đời
    - cấu hình log
    - chặn truy cập công khai
        ↓
    Sửa một chính sách chung → phải
      sửa 200 chỗ

⚠ Và vì sao phương án C sai về mặt kỹ thuật:

C nói tạo "bucket con dưới bucket cha"
        ↓
    S3 KHÔNG có khái niệm bucket lồng
      nhau
        ↓
    Không gian tên bucket là PHẲNG
        ↓
    Cái mà người ta gọi là "thư mục"
      chỉ là tiền tố trong khoá object

⚠ Và "thư mục" trong S3 là ảo:

`kho/khach-a/tep.pdf`
        ↓
    Không có thư mục `khach-a` nào tồn
      tại
        ↓
    Chỉ có một object với khoá chứa
      dấu gạch chéo
        ↓
    Console hiển thị như thư mục cho
      dễ nhìn

⚠ Và vì sao phương án D không giải quyết đúng yêu cầu:

D bật Requester Pays để khách hàng
  tự trả phí
        ↓
    Đề nói giảm chi phí và tăng co giãn
        ↓
    Không nói chuyển chi phí sang khách
        ↓
    Và vẫn tạo một bucket mỗi khách
    → cùng vấn đề với B

⚠ Và Requester Pays có ràng buộc riêng:

Người yêu cầu phải xác thực bằng
  tài khoản AWS của họ
        ↓
    Và phải khai `--request-payer requester`
      trong mọi lời gọi
        ↓
    Không dùng được cho truy cập ẩn
      danh

Tạo IAM user và group:

aws iam create-group --group-name khach-hang

aws iam put-group-policy --group-name khach-hang \
  --policy-name truy-cap-thu-muc-rieng \
  --policy-document file://chinh-sach.json

aws iam create-user --user-name khach-a
aws iam add-user-to-group --group-name khach-hang \
  --user-name khach-a

⚠ Và s3:prefix trong điều kiện ListBucket là chi tiết quan trọng:

`ListBucket` áp cho BUCKET, không
  áp cho object
        ↓
    Resource là `arn:aws:s3:::kho`
      (không có `/*`)
        ↓
    Điều kiện `s3:prefix` giới hạn
      phần được liệt kê
        ↓
    Thiếu điều kiện → khách thấy tên
      thư mục của mọi khách khác

⚠ Và đây là lỗi rò rỉ thông tin hay gặp:

Chỉ giới hạn `GetObject`
        ↓
    Khách không đọc được tệp của
      người khác
        ↓
    Nhưng LIỆT KÊ được tên thư mục
    → biết công ty có những khách nào

⚠ Và client S3 thay FTP là thay đổi cho khách hàng:

Khách quen dùng FileZilla, WinSCP
        ↓
    Chuyển sang AWS CLI hoặc S3 client
        ↓
    Cần đào tạo và tài liệu
        ↓
    Đây là cái giá của phương án này

⚠ Và AWS Transfer Family là lựa chọn giữ nguyên FTP:

aws transfer create-server \
  --protocols SFTP \
  --identity-provider-type SERVICE_MANAGED \
  --domain S3

Khách vẫn dùng client SFTP quen thuộc
        ↓
    Dữ liệu vẫn nằm trên S3
        ↓
    Không phải đào tạo lại ai
        ↓
    Nhưng tính phí theo giờ endpoint
      + theo GB

⚠ Và Transfer Family cũng dùng được biến chính sách:

{"Effect": "Allow",
 "Action": ["s3:GetObject", "s3:PutObject"],
 "Resource": "arn:aws:s3:::kho/${transfer:UserName}/*"}

`${transfer:UserName}` tương tự
  `${aws:username}`
        ↓
    Cách ly theo người dùng SFTP

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một chính sách cho mọi khách hàng | | | Không chạm hạn ngạch bucket | | | Thêm khách chỉ mất một lệnh | |

⚠ Và IAM user cũng có hạn ngạch — cần biết:

5.000 IAM user mỗi tài khoản
        ↓
    200 khách → không sao
        ↓
    Hàng chục nghìn khách
    → phải dùng Cognito hoặc
      federation

⚠ Và với quy mô lớn thì dùng vai trò thay IAM user:

Cognito identity pool
        ↓
    Mỗi khách nhận credential tạm
        ↓
    Chính sách dùng
      `${cognito-identity.amazonaws.com:sub}`
    → cách ly tương tự
    → và không có khoá dài hạn nào

⚠ Và S3 Access Point là lựa chọn thứ ba:

aws s3control create-access-point \
  --account-id 111122223333 \
  --name diem-khach-a \
  --bucket kho-khach-hang \
  --policy file://chinh-sach-khach-a.json

Mỗi khách một access point
        ↓
    Mỗi cái một chính sách riêng
        ↓
    Tối đa 10.000 access point mỗi
      bucket
    → mở rộng tốt hơn bucket riêng

⚠ Và phải chặn truy cập công khai ở cấp tài khoản:

aws s3control put-public-access-block \
  --account-id 111122223333 \
  --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,\
BlockPublicPolicy=true,RestrictPublicBuckets=true

Dữ liệu khách hàng phải riêng tư
        ↓
    Block Public Access ở cấp tài
      khoản
    → không object nào công khai được

⚠ Và nên bật mã hoá mặc định:

aws s3api put-bucket-encryption --bucket kho-khach-hang \
  --server-side-encryption-configuration '{
    "Rules": [{"ApplyServerSideEncryptionByDefault":
      {"SSEAlgorithm": "AES256"}, "BucketKeyEnabled": true}]}'

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

• **B. Tạo một bucket riêng cho mỗi khách hàng với bucket policy cho phép đúng khách đó — đây là phương án gần nhất và cách ly hoàn toàn về mặt logic, nhưng hạn ngạch bucket mỗi tài khoản chỉ 100 (nâng tối đa 1.000) và phải quản lý chính sách, mã hoá, vòng đời cho từng bucket.
• **D. Bucket riêng cho mỗi khách kèm Requester Pays — cùng vấn đề hạn ngạch, và đề không yêu cầu chuyển chi phí sang khách hàng.
• **C. Tạo bucket con dưới một bucket cha — S3 không có khái niệm bucket lồng nhau; không gian tên bucket là phẳng.

Ghi nhớ

⚠ Bốn cách cách ly dữ liệu nhiều khách trên S3 — bảng phải thuộc: | Cách | Giới hạn quy mô | |---|---| | Tiền tố + biến chính sách | 5.000 IAM user | | Access Point mỗi khách | 10.000 mỗi bucket | | Bucket riêng mỗi khách | 1.000 bucket | | Cognito + credential tạm | gần như không giới hạn |

Từ khoá nhận diện:

"isolate data per customer, one bucket" → biến chính sách ${aws:username} "replace FTP but keep the protocol" → AWS Transfer Family "thousands of customers" → Cognito hoặc Access Point "customer pays for data transfer" → Requester Pays

Ba biến chính sách hay dùng: | Biến | Nguồn | |---|---| | ${aws:username} | tên IAM user | | ${aws:userid} | ID duy nhất của danh tính | | ${cognito-identity.amazonaws.com:sub} | danh tính Cognito | | ${transfer:UserName} | người dùng Transfer Family |

⚠ ${aws:username} chỉ hoạt động với IAM user:

Vai trò được giả nhận KHÔNG có
  `aws:username`
        ↓
    Biến không được thay
    → chính sách không khớp gì
        ↓
    Với vai trò thì dùng
      `${aws:userid}` hoặc session tag

Ba lưu ý về ListBucket: | Lưu ý | Chi tiết | |---|---| | Resource là bucket, không có /* | | | Điều kiện s3:prefix giới hạn phạm vi | | | Thiếu điều kiện → lộ tên thư mục của người khác | |

Ba lưu ý về hạn ngạch: | Hạn ngạch | Giá trị | |---|---| | Bucket mỗi tài khoản | 100 (nâng tới 1.000) | | IAM user mỗi tài khoản | 5.000 | | Access point mỗi bucket | 10.000 |

Ba lưu ý về Transfer Family: | Lưu ý | Chi tiết | |---|---| | Hỗ trợ SFTP, FTPS, FTP, AS2 | | | Đích là S3 hoặc EFS | | | Tính phí theo giờ endpoint + GB | |

⚠ Transfer Family đắt hơn dùng S3 trực tiếp:

~0,30 USD/giờ mỗi giao thức
        ↓
    ~216 USD/tháng cho một endpoint
        ↓
    Cộng phí theo GB
    → đổi lấy việc không phải đào tạo
      khách hàng

Ba lưu ý về bảo mật: | Lưu ý | Chi tiết | |---|---| | Block Public Access ở cấp tài khoản | | | Mã hoá mặc định SSE-S3 hoặc SSE-KMS | | | Bật versioning chống xoá nhầm | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail data event ghi truy cập object | | | S3 Storage Lens xem dung lượng theo tiền tố | | | Access Analyzer tìm chia sẻ ra ngoài | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng nhập bằng một khách, thử đọc thư mục khách khác | | | Thử ListBucket không có tiền tố — phải bị từ chối | | | Kiểm không có object nào công khai | |

Và một lời khuyên: hãy thêm điều kiện s3:prefix vào quyền ListBucket chứ đừng chỉ giới hạn GetObject. Không có nó, mỗi khách hàng vẫn liệt kê được tên thư mục của mọi khách hàng khác — và với một công ty phát triển web thì danh sách khách hàng chính là thông tin nhạy cảm.

Đáp án

**A — Replatform máy chủ sang Amazon EC2 và chọn một AMI phù hợp với yêu cầu về hệ điều hành; dùng AWS Snowball chuyển 90 TB dữ liệu ảnh sang Amazon S3.

Vì sao đúng

Đề nêu hai vấn đề riêng biệt, và mỗi vế của đáp án lo một cái: | Vấn đề | Cách giải quyết | |---|---| | Hệ điều hành sắp hết hỗ trợ | replatform lên AMI mới hơn | | 90 TB dữ liệu ảnh tĩnh | Snowball |

⚠ Điểm mấu chốt: đề nói rõ muốn NÂNG CẤP hệ điều hành:

"OS support will end soon"
        ↓
    "Đội muốn đẩy nhanh việc di trú
      sang EC2 với PHIÊN BẢN HỆ ĐIỀU
      HÀNH MỚI"
        ↓
    → không phải sao chép y nguyên
    → mà là REPLATFORM

⚠ Và đây là lý do phương án B không đúng:

B dùng MGN di trú "ứng dụng và toàn
  bộ dữ liệu"
        ↓
    MGN là công cụ REHOST — sao chép
      block-level
        ↓
    Nó mang theo CHÍNH hệ điều hành cũ
        ↓
    Vấn đề hệ điều hành hết hỗ trợ
      vẫn còn nguyên

⚠ Và MGN sao chép nguyên trạng:

Replication Agent sao chép từng khối
  đĩa
        ↓
    Instance đích giống hệt máy nguồn
        ↓
    Kể cả phiên bản hệ điều hành,
      driver, cấu hình cũ
        ↓
    Đó là ưu điểm của rehost
    → nhưng không giải quyết được
      bài toán ở đây

⚠ Và MGN cũng không hợp cho 90 TB dữ liệu tĩnh:

MGN sao chép qua MẠNG
        ↓
    90 TB qua đường truyền thông
      thường
        ↓
    Mất hàng tháng
        ↓
    Và ảnh tĩnh nên nằm ở S3, không
      nằm trên EBS của máy chủ

⚠ Và phân biệt sáu chiến lược 6R là chìa khoá của câu này: | Chiến lược | Nghĩa | |---|---| | Rehost | sao chép y nguyên (MGN) | | Replatform | đổi một thành phần, ví dụ hệ điều hành | | Repurchase | mua SaaS thay thế | | Refactor | viết lại kiến trúc | | Retire | bỏ đi | | Retain | giữ tại chỗ |

Đổi hệ điều hành sang phiên bản mới
        ↓
    Giữ nguyên ứng dụng
        ↓
    → replatform

⚠ Và tính thời gian truyền 90 TB:

90 TB = 720.000.000 Mb
        ↓
    Ở 1 Gbps: 720.000 giây ≈ 8,3 ngày
    (lý thuyết)
        ↓
    Thực tế khoảng 13 ngày
        ↓
    Ở 100 Mbps: hơn 4 tháng

⚠ Và Snowball Edge Storage Optimized chứa 80 TB dùng được:

90 TB → cần hai thiết bị
        ↓
    Hoặc một thiết bị bản 210 TB
        ↓
    Chu trình 1-2 tuần
    → nhanh hơn mạng trong hầu hết
      trường hợp

⚠ Và vì sao phương án C không hiệu quả về chi phí:

C dựng Direct Connect
        ↓
    Đề hỏi cách "hiệu quả chi phí nhất"
        ↓
    Direct Connect: phí lắp đặt, phí
      cổng theo giờ, hợp đồng dài hạn
        ↓
    Và mất hàng tuần tới hàng tháng
      để lắp
        ↓
    Cho một lần chuyển dữ liệu duy
      nhất → không đáng

⚠ Và vì sao phương án D không hợp:

D đặt ứng dụng trên Fargate
        ↓
    "Ứng dụng web CŨ" chạy 24/7
        ↓
    Container hoá đòi đóng gói lại,
      thử nghiệm, đổi cách vận hành
        ↓
    Đề nói "đẩy nhanh việc di trú"
    → refactor là chậm nhất

⚠ Và Fargate cũng không rẻ hơn EC2 cho tải chạy liên tục:

Ứng dụng chạy 24/7
        ↓
    Fargate: trả theo vCPU-giây và
      GB-giây, không có Savings Plan
      cho EC2
        ↓
    EC2 với Reserved Instance hoặc
      Savings Plan
    → rẻ hơn cho tải ổn định

Quy trình replatform:

1. Chọn AMI có hệ điều hành được hỗ
     trợ
        ↓
2. Khởi chạy instance từ AMI đó
        ↓
3. Cài lại ứng dụng và phụ thuộc
        ↓
4. Kiểm thử tương thích
        ↓
5. Chuyển đổi

Chuyển dữ liệu bằng Snowball:

aws snowball create-job \
  --job-type IMPORT \
  --resources '{"S3Resources": [{
    "BucketArn": "arn:aws:s3:::anh-ung-dung"}]}' \
  --address-id <ma-dia-chi> \
  --role-arn <arn-role> \
  --snowball-type EDGE_S3_OPTIMIZED \
  --shipping-option SECOND_DAY

⚠ Và ứng dụng phải sửa để đọc ảnh từ S3:

Trước: đọc từ thư mục cục bộ
        ↓
    Sau: gọi API S3
        ↓
    Đây là phần "replatform" của
      ứng dụng
        ↓
    Hoặc mount S3 bằng Mountpoint
      for Amazon S3
    → ít sửa mã hơn

mount-s3 anh-ung-dung /var/www/anh

⚠ Và Mountpoint có giới hạn — cần biết:

Mountpoint for S3 tối ưu cho ĐỌC
  tuần tự
        ↓
    Không hỗ trợ đầy đủ POSIX
        ↓
    Không ghi đè một phần tệp
    → hợp với ảnh tĩnh chỉ đọc

⚠ Và CloudFront trước S3 giúp phục vụ ảnh nhanh hơn:

Ảnh tĩnh trên S3
        ↓
    CloudFront cache ở điểm biên
        ↓
    Giảm tải cho ứng dụng
    → và giảm chi phí truyền dữ liệu

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Hệ điều hành được hỗ trợ trở lại | | | 90 TB chuyển trong 1-2 tuần | | | Ảnh ở S3 rẻ hơn EBS nhiều lần | |

⚠ Và chi phí lưu trữ 90 TB khác nhau rất lớn: | Kho | Giá xấp xỉ mỗi tháng | |---|---| | EBS gp3 | ~7.200 USD | | S3 Standard | ~2.070 USD | | S3 Standard-IA | ~1.125 USD | | S3 Glacier Instant Retrieval | ~360 USD |

Chuyển ảnh từ EBS sang S3
        ↓
    Tiết kiệm hơn 5.000 USD mỗi tháng
        ↓
    Đây là phần lớn giá trị của việc
      replatform

⚠ Và nên đặt luật vòng đời cho ảnh cũ:

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

⚠ Và với hệ điều hành sắp hết hỗ trợ, có lựa chọn thứ ba:

Extended Support của một số hệ điều
  hành
        ↓
    Ví dụ: RHEL ELS, Ubuntu Pro
        ↓
    Kéo dài hỗ trợ thêm vài năm
        ↓
    Nhưng tính phí, và chỉ là hoãn
      lại

⚠ Và AWS có License Manager cho việc quản giấy phép:

aws license-manager create-license-configuration \
  --name giay-phep-windows \
  --license-counting-type Core \
  --license-count 64

Windows Server BYOL cần Dedicated
  Host
        ↓
    Hoặc dùng AMI license-included
    → trả phí giấy phép theo giờ

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

• **B. Dùng AWS Application Migration Service di trú ứng dụng và toàn bộ dữ liệu sang EC2 — đây là phương án gần nhất và MGN là công cụ di trú máy chủ chuẩn của AWS, nhưng nó sao chép nguyên trạng nên mang theo chính hệ điều hành cũ đang hết hỗ trợ; và 90 TB qua mạng mất quá lâu.
• **C. Dựng Direct Connect để chuyển dữ liệu — phí lắp đặt và phí cổng cho một lần chuyển duy nhất là không hiệu quả, và mất hàng tuần để lắp đặt.
• **D. Đặt ứng dụng trên Fargate và dùng Snowball cho dữ liệu — container hoá một ứng dụng web cũ là refactor, chậm nhất trong các chiến lược, và Fargate không rẻ hơn EC2 cho tải chạy 24/7.

Ghi nhớ

⚠ Sáu chiến lược 6R — bảng phải thuộc: | Chiến lược | Công cụ | Đổi gì | |---|---|---| | Rehost | MGN | không đổi gì | | Replatform | AMI mới + cài lại | hệ điều hành, CSDL | | Repurchase | mua SaaS | cả sản phẩm | | Refactor | viết lại | kiến trúc | | Retire | tắt | — | | Retain | giữ nguyên | — |

Từ khoá nhận diện:

"update the OS version" → replatform, không phải rehost "copy servers as-is" → rehost bằng MGN "90 TB, cost-effective" → Snowball "containerize legacy app" → refactor, chậm nhất

⚠ Công thức tính thời gian truyền:

Số ngày ≈ (TB × 8.000.000) /
          (Mbps × 86.400 × 0,65)
        ↓
    90 TB ở 1 Gbps ≈ 13 ngày
    90 TB ở 100 Mbps ≈ 128 ngày

Ba lưu ý về Snowball Edge: | Lưu ý | Chi tiết | |---|---| | Storage Optimized 80 TB hoặc 210 TB | | | Chu trình 1-2 tuần | | | Nhập dữ liệu vào AWS miễn phí | |

Ba lưu ý về MGN: | Lưu ý | Chi tiết | |---|---| | Sao chép block-level, giữ nguyên hệ điều hành | | | Miễn phí 90 ngày mỗi máy chủ | | | Có test instance để kiểm thử trước | |

⚠ MGN cũng hỗ trợ post-launch action:

Sau khi khởi chạy instance đích
        ↓
    Chạy SSM document tự động
        ↓
    Cài agent, cấu hình, nâng cấp
    → biến rehost thành replatform
      một phần

Ba lưu ý về lưu trữ ảnh: | Kho | Hợp với | |---|---| | S3 | ảnh tĩnh, rẻ nhất | | EFS | cần POSIX, nhiều máy ghi | | EBS | đắt nhất, một máy |

Ba lưu ý về Mountpoint for S3: | Lưu ý | Chi tiết | |---|---| | Mount bucket như hệ tệp | | | Tối ưu cho đọc tuần tự | | | Không hỗ trợ đầy đủ POSIX | |

Ba lưu ý về chi phí: | Cách giảm | Chi tiết | |---|---| | Đưa dữ liệu tĩnh sang S3 | rẻ hơn EBS 3-4 lần | | Vòng đời sang IA hoặc Glacier | rẻ thêm nhiều lần | | Savings Plan cho EC2 | giảm tới 72% |

Ba lưu ý về nâng cấp hệ điều hành: | Cách | Đặc điểm | |---|---| | Dựng máy mới từ AMI mới | sạch nhất | | Nâng cấp tại chỗ | rủi ro, có thể hỏng ứng dụng | | Extended support | hoãn lại, tính phí |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy ứng dụng trên hệ điều hành mới ở môi trường thử | | | So checksum ảnh sau khi nhập từ Snowball | | | Đo chi phí lưu trữ trước và sau | |

Và một lời khuyên: hãy kiểm thử ứng dụng trên hệ điều hành mới trước khi lên kế hoạch cutover. Replatform giải quyết được vấn đề hết hỗ trợ, nhưng một ứng dụng web cũ thường phụ thuộc vào phiên bản thư viện hệ thống cụ thể — và phát hiện điều đó sau khi 90 TB đã chuyển xong là thời điểm tệ nhất.

Đáp án

**A — Chính sách có Statement là một mảng chứa CẢ HAI khối: một khối Allow cho ec2:Describe* và một khối Deny cho s3:*, cả hai đều trên "Resource": "*".

Vì sao đúng

Câu này kiểm tra cú pháp JSON của một chính sách IAM có nhiều statement. Cách viết đúng duy nhất là để Statement nhận một mảng:

{"Version": "2012-10-17",
 "Statement": [
   {"Effect": "Allow",
    "Action": "ec2:Describe*",
    "Resource": "*"},
   {"Effect": "Deny",
    "Action": "s3:*",
    "Resource": "*"}]}

⚠ Điểm mấu chốt: Statement nhận MỘT đối tượng hoặc MỘT MẢNG, không có dạng thứ ba:

Một statement:
    "Statement": { ... }
        ↓
    Nhiều statement:
    "Statement": [ { ... }, { ... } ]
        ↓
    Không có cú pháp nào cho phép
      lặp lại khoá "Statement" hai lần

⚠ Và JSON không cho khoá trùng trong cùng một đối tượng:

{"Statement": {...},
 "Statement": {...}}
        ↓
    Về mặt chuẩn JSON đây là không
      xác định
        ↓
    Phần lớn parser giữ giá trị CUỐI
      và bỏ giá trị đầu
        ↓
    → chính sách âm thầm mất một nửa

⚠ Và đây là kiểu lỗi nguy hiểm nhất trong IAM:

Viết khối Deny trước, khối Allow sau
        ↓
    Parser giữ khối Allow
        ↓
    Khối Deny biến mất
        ↓
    Chính sách vẫn hợp lệ về cú pháp
    → nhưng không chặn gì cả

⚠ Và IAM thật ra từ chối chính sách có khoá trùng:

Trình xác thực chính sách của IAM
  bắt được
        ↓
    Trả lỗi `MalformedPolicyDocument`
        ↓
    Nhưng đừng dựa vào đó
    → hãy viết đúng ngay từ đầu

⚠ Và mỗi statement là một đối tượng độc lập, đủ ba thành phần: | Thành phần | Bắt buộc | |---|---| | Effect | có — Allow hoặc Deny | | Action hoặc NotAction | có | | Resource hoặc NotResource | có với chính sách theo danh tính | | Sid | không, nhưng nên có | | Condition | không |

⚠ Và không được gộp hai Effect vào một statement:

{"Effect": ["Allow", "Deny"], ...}
        ↓
    Không hợp lệ
        ↓
    `Effect` là chuỗi, không phải mảng
        ↓
    Muốn hai hiệu lực → hai statement

⚠ Nhưng Action và Resource THÌ nhận mảng:

{"Effect": "Allow",
 "Action": ["ec2:DescribeInstances",
            "ec2:DescribeVolumes"],
 "Resource": ["arn:aws:ec2:*:*:instance/*",
              "arn:aws:ec2:*:*:volume/*"]}

Đây là chỗ hay nhầm:
    - `Effect`: chỉ chuỗi
    - `Action`, `Resource`: chuỗi
      hoặc mảng
    - `Statement`: đối tượng hoặc mảng

⚠ Và với SCP thì có thêm ràng buộc riêng:

Đề nói đây là Service Control Policy
        ↓
    SCP KHÔNG cấp quyền — chỉ đặt
      trần quyền
        ↓
    Khối `Allow ec2:Describe*` không
      cho ai quyền gì
    → nó chỉ định nghĩa hành động nào
      được PHÉP tồn tại trong trần

⚠ Và đây là hiểu lầm phổ biến nhất về SCP:

Gắn SCP có `Allow ec2:Describe*`
        ↓
    Người dùng vẫn không mô tả được
      instance
        ↓
    Vì họ chưa có chính sách IAM cấp
      quyền đó
        ↓
    Quyền thật = giao của SCP và
      chính sách IAM

     SCP                IAM policy
  (trần quyền)        (cấp quyền)
       ↓                    ↓
       └────── GIAO ────────┘
                ↓
          Quyền thực tế

⚠ Và SCP mặc định đã có FullAWSAccess:

Gốc của tổ chức gắn sẵn SCP
  `FullAWSAccess` cho phép `*`
        ↓
    Gắn thêm SCP chỉ `Allow ec2:Describe*`
        ↓
    Trần trở thành GIAO của hai cái
    → chỉ còn `ec2:Describe*`
        ↓
    Mọi dịch vụ khác bị chặn

⚠ Và vì thế viết SCP kiểu allow-list rất dễ gây sự cố:

Quên `iam:*`, `sts:*`, `cloudwatch:*`
        ↓
    Cả tài khoản không đăng nhập được
      hoặc không giám sát được
        ↓
    Thực tế nên dùng SCP kiểu
      deny-list
    → chặn cái không muốn, để
      `FullAWSAccess` lo phần còn lại

SCP kiểu deny-list thường dùng:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "ChanRegionNgoaiDanhSach",
   "Effect": "Deny",
   "NotAction": ["iam:*", "sts:*", "cloudfront:*",
                 "route53:*", "support:*"],
   "Resource": "*",
   "Condition": {"StringNotEquals": {
     "aws:RequestedRegion": ["ap-southeast-1", "us-east-1"]}}}]}

⚠ Và Deny luôn thắng Allow — đây là luật nền tảng:

Một khối Deny khớp
        ↓
    Không `Allow` nào lật ngược được
        ↓
    Kể cả `Allow` trong chính sách
      khác, ở tầng khác
    → Deny tường minh là tuyệt đối

Thứ tự đánh giá quyền:

1. Deny tường minh ở BẤT KỲ đâu → TỪ CHỐI
        ↓
2. SCP không cho phép → TỪ CHỐI
        ↓
3. Permissions boundary không cho → TỪ CHỐI
        ↓
4. Session policy không cho → TỪ CHỐI
        ↓
5. Có Allow tường minh → CHO PHÉP
        ↓
6. Mặc định → TỪ CHỐI

⚠ Và Resource: "*" trong SCP là bình thường:

SCP chỉ hỗ trợ `Resource: "*"` cho
  phần lớn trường hợp
        ↓
    Vì nó áp cho cả tài khoản
        ↓
    Muốn giới hạn tài nguyên cụ thể
    → dùng chính sách IAM, không dùng
      SCP

Kiểm chính sách trước khi gắn:

aws accessanalyzer validate-policy \
  --policy-document file://scp.json \
  --policy-type SERVICE_CONTROL_POLICY

aws organizations create-policy \
  --name chan-s3 --type SERVICE_CONTROL_POLICY \
  --description "Cho phep mo ta EC2, chan S3" \
  --content file://scp.json

Ba lợi ích khi viết đúng cú pháp: | Lợi ích | Chi tiết | |---|---| | Cả hai statement đều có hiệu lực | | | Chính sách đọc được và bảo trì được | | | Thêm statement thứ ba chỉ là thêm phần tử mảng | |

⚠ Và nên đặt Sid cho mỗi statement:

{"Sid": "ChoPhepMoTaEC2", ...}
{"Sid": "ChanMoiThaoTacS3", ...}

`Sid` không ảnh hưởng hiệu lực
        ↓
    Nhưng khi chính sách có 15
      statement
        ↓
    Đọc log CloudTrail và tra ngược
      dễ hơn nhiều

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

• **Phương án lặp lại khoá "Statement" hai lần trong cùng một đối tượng — đây là phương án gần nhất và nội dung hai khối hoàn toàn đúng, nhưng JSON không cho phép khoá trùng: parser giữ giá trị cuối và bỏ giá trị đầu, nên một trong hai statement biến mất mà không có dấu hiệu gì.
• **Phương án gộp cả Allow và Deny vào một statement duy nhất — Effect là một chuỗi, không nhận mảng hay hai giá trị.
• **Phương án đặt hai đối tượng cạnh nhau không bọc trong mảng — JSON không hợp lệ, sẽ bị từ chối ngay khi phân tích.

Ghi nhớ

⚠ Bốn quy tắc cú pháp chính sách IAM — bảng phải thuộc: | Khoá | Nhận | |---|---| | Statement | một đối tượng HOẶC một mảng | | Effect | chỉ chuỗi Allow/Deny | | Action, Resource | chuỗi hoặc mảng | | Condition | đối tượng lồng nhau |

Từ khoá nhận diện:

"multiple statements" → mảng, không lặp khoá "SCP allows an action" → chỉ đặt trần, không cấp quyền "explicit Deny" → thắng mọi Allow "Effect as array" → luôn sai

Ba lưu ý về SCP: | Lưu ý | Chi tiết | |---|---| | Không cấp quyền, chỉ đặt trần | | | Không áp cho tài khoản quản lý | | | Không áp cho service-linked role | |

⚠ SCP không áp cho tài khoản quản lý:

Gắn SCP chặn mọi thứ ở gốc
        ↓
    Tài khoản quản lý vẫn làm được
      mọi việc
        ↓
    Đó là thiết kế — tránh tự khoá
      mình ra ngoài
    → nhưng cũng nghĩa là không nên
      chạy tải sản xuất ở đó

Ba lưu ý về thứ tự đánh giá: | Bước | Kết quả | |---|---| | Deny tường minh | từ chối ngay | | Không có Allow nào | từ chối mặc định | | Allow và không Deny | cho phép |

Ba lưu ý về NotAction: | Lưu ý | Chi tiết | |---|---| | Deny + NotAction = chặn mọi thứ TRỪ danh sách | | | Allow + NotAction rất nguy hiểm | | | Dùng cho SCP giới hạn Region là đúng chỗ | |

Ba công cụ kiểm chính sách: | Công cụ | Việc | |---|---| | IAM Access Analyzer policy validation | bắt lỗi cú pháp và cảnh báo bảo mật | | IAM Policy Simulator | thử một hành động cụ thể | | aws organizations describe-effective-policy | xem trần thực tế |

Ba lưu ý khi triển khai SCP: | Lưu ý | Chi tiết | |---|---| | Thử ở OU nhỏ trước | | | Ưu tiên deny-list hơn allow-list | | | Có kế hoạch gỡ nhanh khi sự cố | |

Ba lưu ý về JSON: | Lưu ý | Chi tiết | |---|---| | Không cho khoá trùng | | | Không cho dấu phẩy thừa cuối mảng | | | Không có chú thích | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy validate-policy trước khi gắn | | | Thử một hành động bị chặn từ tài khoản con | | | Xem describe-effective-policy sau khi gắn | |

Và một lời khuyên: hãy chạy aws accessanalyzer validate-policy cho mọi chính sách trước khi gắn. Một chính sách viết sai cú pháp thường bị từ chối ngay, nhưng một chính sách viết đúng cú pháp mà thiếu mất một statement thì không báo lỗi gì cả — và với SCP thì cái thiếu đó thường chính là khối Deny bạn đặt ra để bảo vệ tổ chức.

Đáp án

**D — Cập nhật network ACL của subnet để cho phép lưu lượng ra.

Vì sao đúng

Manh mối nằm trong dòng log: mục REJECT ở chiều RA (egress). Chỉ có một thành phần trong VPC từ chối được lưu lượng ra sau khi lưu lượng vào đã được nhận.

⚠ Điểm mấu chốt: security group là STATEFUL:

Yêu cầu vào được security group cho
  phép
        ↓
    Security group tự nhớ kết nối đó
        ↓
    Phản hồi ra được cho phép TỰ ĐỘNG
        ↓
    → security group KHÔNG THỂ là
      nguyên nhân của REJECT chiều ra

⚠ Và network ACL là STATELESS — đây là khác biệt then chốt:

Network ACL đánh giá mỗi chiều RIÊNG
  BIỆT
        ↓
    Cho phép vào không tự cho phép ra
        ↓
    Phải khai LUẬT RA tường minh
        ↓
    Thiếu → phản hồi bị chặn
    → và log ghi REJECT ở chiều ra

Bảng phân biệt: | | Security Group | Network ACL | |---|---|---| | Trạng thái | stateful | stateless | | Phạm vi | ENI | subnet | | Luật | chỉ Allow | Allow và Deny | | Đánh giá | mọi luật cùng lúc | theo số thứ tự, dừng ở luật đầu khớp | | Chiều | vào và ra, tự ghép cặp | vào và ra, độc lập |

⚠ Và triệu chứng cổ điển: kết nối vào được nhưng không có phản hồi:

Client gửi SYN tới cổng 443
        ↓
    NACL inbound cho phép → tới được
      instance
        ↓
    Instance trả SYN-ACK từ cổng 443
      tới cổng cao của client
        ↓
    NACL outbound không cho phép dải
      cổng đó
    → REJECT

⚠ Và đây là lý do phải mở dải cổng phù du:

Client kết nối từ cổng ngẫu nhiên
  trong dải 1024-65535
        ↓
    Phản hồi đi TỚI cổng đó
        ↓
    Luật NACL outbound phải cho phép
      dải này
        ↓
    Chỉ cho phép cổng 443 ra là KHÔNG
      ĐỦ

Dải cổng phù du theo hệ điều hành: | Nguồn | Dải | |---|---| | Linux kernel | 32768-60999 | | Windows Server 2008 trở đi | 49152-65535 | | NAT Gateway, ELB | 1024-65535 | | Khuyến nghị chung | 1024-65535 |

Thêm luật outbound:

aws ec2 create-network-acl-entry \
  --network-acl-id acl-abc \
  --rule-number 100 \
  --protocol tcp \
  --port-range From=1024,To=65535 \
  --cidr-block 0.0.0.0/0 \
  --rule-action allow \
  --egress

⚠ Và số thứ tự luật quyết định — NACL dừng ở luật đầu khớp:

Luật 100: Deny 0.0.0.0/0
Luật 200: Allow TCP 1024-65535
        ↓
    Luật 100 khớp trước → từ chối
        ↓
    Luật 200 không bao giờ được xét
    → đặt luật Deny cụ thể ở số THẤP,
      Allow chung ở số CAO hơn

⚠ Và mọi NACL có một luật ẩn * ở cuối:

Luật `*`: Deny mọi thứ
        ↓
    Không xoá được, không sửa được
        ↓
    Không luật nào khớp → rơi vào đây
    → mặc định là từ chối

⚠ Và NACL mặc định của VPC cho phép mọi thứ:

VPC mới tạo → NACL mặc định
        ↓
    Luật 100 Allow tất cả, cả hai
      chiều
        ↓
    Nên phần lớn người dùng không bao
      giờ chạm tới NACL
        ↓
    Gặp REJECT ở đây → ai đó đã sửa
      NACL

⚠ Và vì sao phương án A và B đều sai:

A và B sửa security group
        ↓
    Security group là stateful
        ↓
    Nó không sinh ra REJECT chiều ra
      cho phản hồi của kết nối đã nhận
    → chẩn đoán sai thành phần

⚠ Và security group cũng không có luật Deny:

Security group chỉ có luật Allow
        ↓
    Không khớp luật nào → âm thầm bỏ
      gói tin
        ↓
    VPC Flow Log ghi REJECT
        ↓
    Nhưng chỉ ở chiều mà không có
      luật allow
    → với phản hồi thì luôn có

⚠ Và vì sao phương án C sai — route table không "reject":

C sửa route table
        ↓
    Thiếu route → gói tin bị bỏ, không
      đi đâu
        ↓
    Nhưng Flow Log ghi mục đó khác
        ↓
    Và đề nói lưu lượng VÀO tới nơi
      bình thường
    → route đã có, nếu không thì
      chiều vào cũng hỏng

Đọc một dòng VPC Flow Log:

2 111122223333 eni-abc 10.0.1.5 203.0.113.9
   443 49152 6 12 1200 1699000000 1699000060 REJECT OK

Nguồn là instance, đích là client
        ↓
    → đây là chiều RA
        ↓
    Cổng đích 49152 là cổng phù du
    → phản hồi bị chặn

⚠ Và Flow Log không ghi mọi thứ — cần biết giới hạn:

Flow Log KHÔNG ghi:
    - lưu lượng tới Amazon DNS
    - DHCP
    - metadata service 169.254.169.254
    - Windows license activation
        ↓
    Không thấy trong log không có
      nghĩa là không xảy ra

⚠ Và nên bật đủ trường để chẩn đoán:

aws ec2 create-flow-logs \
  --resource-type Subnet --resource-ids subnet-abc \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /vpc/flowlogs \
  --deliver-logs-permission-arn <arn-role> \
  --log-format '${version} ${vpc-id} ${subnet-id} ${instance-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${action} ${flow-direction} ${pkt-src-aws-service} ${pkt-dst-aws-service}'

⚠ Và trường flow-direction giúp đọc log nhanh hơn nhiều:

`ingress` hoặc `egress`
        ↓
    Không phải tự suy từ địa chỉ
      nguồn và đích
        ↓
    Rất đáng thêm vào định dạng log

Ba lợi ích khi sửa đúng NACL: | Lợi ích | Chi tiết | |---|---| | Phản hồi đi được, kết nối hoàn tất | | | Không phải nới lỏng security group | | | Vẫn giữ được NACL làm lớp phòng thủ | |

⚠ Và có công cụ chẩn đoán thay cho đọc log tay:

aws ec2 create-network-insights-path \
  --source i-abc --destination 203.0.113.9 \
  --protocol tcp --destination-port 443

aws ec2 start-network-insights-analysis \
  --network-insights-path-id nip-abc

Reachability Analyzer chỉ đúng thành
  phần đang chặn
        ↓
    Không cần dựng lưu lượng thật
    → và chỉ rõ luật NACL số mấy

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

• **A. Cập nhật security group để cho phép lưu lượng ra — đây là phương án gần nhất và security group đúng là có luật outbound, nhưng nó stateful: phản hồi cho một kết nối vào đã được chấp nhận luôn được cho ra tự động, nên nó không thể sinh ra REJECT này.
• **B. Cập nhật security group để cho phép lưu lượng vào — chiều vào đang hoạt động bình thường theo đề bài.
• **C. Cập nhật route table — thiếu route thì chiều vào cũng đã hỏng, và route table không sinh mục REJECT kiểu này.

Ghi nhớ

⚠ Bốn bước chẩn đoán REJECT trong Flow Log — bảng phải thuộc: | Bước | Việc | |---|---| | 1. Xác định chiều | so srcaddr với dstaddr | | 2. REJECT chiều ra cho phản hồi | → NACL | | 3. REJECT chiều vào | → SG hoặc NACL inbound | | 4. Không có mục nào | → route table hoặc mất kết nối |

Từ khoá nhận diện:

"REJECT on outbound, inbound works" → network ACL "stateful" → security group | "stateless" → NACL "connection hangs, no response" → thiếu luật cổng phù du "which component blocks this path" → Reachability Analyzer

Ba lưu ý về NACL: | Lưu ý | Chi tiết | |---|---| | Đánh giá theo số thứ tự tăng dần | | | Dừng ở luật đầu tiên khớp | | | Luật ẩn * từ chối mọi thứ còn lại | |

Ba lưu ý về cổng phù du: | Nguồn | Dải | |---|---| | Linux | 32768-60999 | | Windows | 49152-65535 | | ELB, NAT Gateway | 1024-65535 |

Ba lưu ý về security group: | Lưu ý | Chi tiết | |---|---| | Chỉ có luật Allow | | | Stateful cả hai chiều | | | Tham chiếu được security group khác | |

Ba lưu ý về Flow Log: | Lưu ý | Chi tiết | |---|---| | Bật ở cấp VPC, subnet hoặc ENI | | | Không ghi DNS, DHCP, metadata | | | Thêm flow-direction để đọc dễ hơn | |

Ba lưu ý về thứ tự áp dụng:

Gói tin vào:
  NACL inbound → security group inbound → instance
Gói tin ra:
  instance → security group outbound → NACL outbound

Ba công cụ chẩn đoán mạng: | Công cụ | Việc | |---|---| | VPC Flow Logs | thấy cái gì bị chặn | | Reachability Analyzer | chỉ ra thành phần chặn | | Traffic Mirroring | soi nội dung gói tin |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem luật outbound của NACL | | | Chạy Reachability Analyzer | | | Kiểm lại Flow Log sau khi sửa | |

Và một lời khuyên: hãy ghi nhớ rằng NACL stateless là nguyên nhân của gần như mọi ca "kết nối vào được nhưng treo không có phản hồi". Sửa security group trong tình huống đó chỉ nới lỏng bảo mật mà không chữa được gì — vì thành phần thật sự chặn nằm ở tầng subnet, và nó đòi luật cho dải cổng phù du chứ không phải cho cổng dịch vụ.