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

Đáp án

**C — Dùng multipart upload để tải video lên S3, và cấu hình ứng dụng dùng endpoint S3 Transfer Acceleration để cải thiện tốc độ tải lên và tối ưu luôn cả multipart.

Vì sao đúng

Đề mô tả rõ chiều dữ liệu đang có vấn đề:

Người dùng ở Melbourne và Sydney
        ↓
    Bucket ở Virginia (us-east-1)
        ↓
    Kêu ca TẢI LÊN chậm và timeout
        ↓
    Cần cải thiện chiều LÊN

⚠ Điểm mấu chốt: CloudFront tối ưu cho chiều TẢI XUỐNG:

CloudFront cache nội dung ở biên
        ↓
    Lần đọc thứ hai trở đi rất nhanh
        ↓
    Nhưng TẢI LÊN không có gì để cache
    → mỗi lần tải lên là một lần
      đi tới origin

Đây là lý do phương án D thua — nó dùng đúng công cụ nhưng cho sai chiều.

⚠ Và S3 Transfer Acceleration sinh ra đúng cho chiều lên:

Client tải lên → điểm biên gần nhất
  (Sydney)
        ↓
    Từ đó đi trên mạng xương sống
      AWS tới us-east-1
        ↓
    Thay vì đi qua Internet công
      cộng suốt chặng dài

⚠ Và multipart giải quyết nguyên nhân thứ hai — timeout:

Video 10 GB tải một lần
        ↓
    Một kết nối TCP giữ mở rất lâu
        ↓
    Đứt giữa chừng → làm lại từ đầu
    → đây chính là "timeout" trong đề
        ↓
    Multipart: chia nhỏ, tải song
      song, thử lại từng phần

⚠ Và với tệp 10 GB thì multipart là BẮT BUỘC:

Giới hạn PUT một lần: 5 GB
        ↓
    Video tới 10 GB
    → không tải lên được nếu không
      dùng multipart

Cấu hình multipart với endpoint tăng tốc:

import boto3
from boto3.s3.transfer import TransferConfig
from botocore.config import Config

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

cau_hinh = TransferConfig(
    multipart_threshold=64*1024*1024,
    max_concurrency=20,
    multipart_chunksize=64*1024*1024,
    use_threads=True)

s3.upload_file('video.mp4', 'video-nguoi-dung',
               'tai-len/video.mp4', Config=cau_hinh)

⚠ Và hai cơ chế này cộng hưởng với nhau:

Multipart chia thành 20 luồng
        ↓
    Mỗi luồng đi qua điểm biên gần
      nhất
        ↓
    Cả 20 luồng đều được tăng tốc
    → đây là lý do đề nói "tối ưu
      luôn cả multipart upload"

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

B tạo bucket ở mỗi Region có người
  dùng rồi dùng replication đồng bộ
        ↓
    Người dùng Úc tải lên bucket Úc
      → nhanh
        ↓
    Nhưng phải quản nhiều bucket
        ↓
    Và replication chỉ MỘT CHIỀU
      cho mỗi luật
    → đồng bộ hai chiều rất phức tạp

⚠ Nhưng Multi-Region Access Point là cách làm đúng nếu chọn hướng này:

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

Một endpoint toàn cầu
        ↓
    Tự định tuyến tới bucket gần nhất
        ↓
    Nhưng vẫn cần CRR hai chiều
    → và xung đột theo "last writer
      wins"

⚠ Và vì sao phương án A sai — AWS Outposts không đặt ở điểm biên:

A nói cấu hình Outposts "trên các
  điểm biên của Region"
        ↓
    Outposts là giá thiết bị AWS
      đặt trong TRUNG TÂM DỮ LIỆU
      CỦA BẠN
        ↓
    Không phải thứ triển khai ở
      điểm biên AWS
        ↓
    Và với ứng dụng di động công
      cộng thì hoàn toàn không hợp

⚠ Và có một dịch vụ đúng nghĩa "S3 ở điểm biên":

S3 on Outposts: S3 API trên phần
  cứng của bạn
        ↓
    Local Zones: hạ tầng AWS đặt
      gần thành phố lớn
        ↓
    Nhưng cả hai đều không phải
      giải pháp cho bài toán này

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Tải lên nhanh hơn đáng kể từ xa | | | Hết timeout với tệp lớn | | | Giữ nguyên một bucket, một kho | |

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

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

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

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

Chạy từ Sydney
        ↓
    Biết mức cải thiện thực tế
    → thường 50-500% cho khoảng
      cách đó

⚠ Và pre-signed URL cho phép ứng dụng di động tải thẳng:

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

Client tải thẳng lên S3
        ↓
    Máy chủ ứng dụng chỉ cấp URL
    → không phải trung chuyển 10 GB

⚠ Và hạn của pre-signed URL phải đủ dài cho tệp lớn:

URL hết hạn sau 15 phút
        ↓
    Video 10 GB trên mạng di động
      mất hàng giờ
        ↓
    Đặt hạn dài, hoặc dùng multipart
      với từng phần có URL riêng

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

• **D. Dùng multipart upload và cấu hình CloudFront với origin là S3 — đây là phương án gần nhất và multipart hoàn toàn đúng, nhưng CloudFront tối ưu cho việc phân phối nội dung xuống chứ không tăng tốc tải lên; công cụ đúng cho chiều lên là S3 Transfer Acceleration.
• **B. Tạo bucket ở mỗi Region và dùng S3 replication đồng bộ — phải quản nhiều bucket, và replication một chiều nên đồng bộ hai chiều rất phức tạp.
• **A. Cấu hình AWS Outposts trên các điểm biên — Outposts là phần cứng AWS đặt trong trung tâm dữ liệu của khách hàng, không phải thứ triển khai ở điểm biên.

Ghi nhớ

⚠ Bốn cách tăng tốc theo chiều dữ liệu — bảng phải thuộc: | Cách | Chiều | |---|---| | CloudFront | TẢI XUỐNG (có cache) | | S3 Transfer Acceleration | TẢI LÊN (và xuống) | | Multipart song song | TẢI LÊN | | Global Accelerator | TCP/UDP, không hỗ trợ S3 |

Từ khoá nhận diện:

"slow uploads from far away" → S3TA + multipart "slow downloads globally" → CloudFront "files over 5 GB" → multipart bắt buộc "upload timeouts" → multipart để thử lại từng phần

Ba lưu ý về multipart: | Lưu ý | Chi tiết | |---|---| | Bắt buộc trên 5 GB | | | Tối đa 10.000 phần | | | Đặt luật dọn phần dở dang | |

⚠ Tính kích thước phần cho tệp 10 GB:

Phần 5 MB → 2.048 phần
        ↓
    Phần 64 MB → 160 phần
        ↓
    Ít phần hơn = ít overhead hơn
    → nhưng thử lại tốn hơn khi hỏng

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

Ba lưu ý về tải lên từ ứng dụng di động: | Lưu ý | Chi tiết | |---|---| | Pre-signed URL, không nhúng credential | | | Giới hạn kích thước trong điều kiện | | | Cho phép tiếp tục sau khi mất mạng | |

⚠ Multipart cho phép tiếp tục sau gián đoạn:

phan_da_tai = s3.list_parts(
    Bucket=KHO, Key=KHOA, UploadId=ma_tai_len)

Ứng dụng lưu `UploadId`
        ↓
    Mất mạng, mở lại ứng dụng
        ↓
    Liệt kê phần đã tải và tiếp tục
    → không phải làm lại từ đầu

Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Truyền VÀO S3 | miễn phí | | Phí yêu cầu multipart | mỗi phần là một PUT | | Phần dở dang | vẫn tính phí lưu trữ |

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

Ba lưu ý về xử lý video: | Dịch vụ | Việc | |---|---| | MediaConvert | chuyển mã, tạo thumbnail | | MediaPackage | đóng gói phát trực tuyến | | CloudFront | phân phối tới người xem |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy công cụ so tốc độ từ Sydney | | | Tải thử tệp 10 GB và bấm giờ | | | Kiểm không còn phần multipart dở dang | |

Và một lời khuyên: hãy lưu UploadId ở phía ứng dụng để người dùng tiếp tục được sau khi mất mạng. Với video 10 GB trên kết nối di động, việc mất mạng giữa chừng là chuyện bình thường — và không có khả năng tiếp tục thì mọi cải thiện tốc độ đều vô nghĩa với người dùng đó.

Đáp án

**C — Trong quá trình liên kết SAML, truyền thuộc tính DevelopmentDept dưới dạng session tag của STS; và cập nhật chính sách của IAM role mà lập trình viên giả nhận với một hành động Deny kèm điều kiện StringNotEquals giữa thẻ tài nguyên DevelopmentDept và aws:PrincipalTag/DevelopmentDept.

Vì sao đúng

Đề nêu hai yêu cầu tưởng như mâu thuẫn, và ABAC giải quyết cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Không đội nào tắt được EC2 của đội khác | Deny khi thẻ không khớp | | Mọi đội vẫn giữ quyền cần thiết | cho phép mọi thứ trong phạm vi thẻ của mình |

⚠ Điểm mấu chốt: ABAC so THẺ CỦA NGƯỜI với THẺ CỦA TÀI NGUYÊN:

`aws:PrincipalTag/DevelopmentDept`
  = thẻ của NGƯỜI đang gọi
        ↓
    `ec2:ResourceTag/DevelopmentDept`
  = thẻ của TÀI NGUYÊN bị tác động
        ↓
    Hai giá trị khác nhau → Deny

Chính sách ABAC:

{"Version": "2012-10-17", "Statement": [
  {"Sid": "ChoPhepQuanLyEC2",
   "Effect": "Allow",
   "Action": ["ec2:StartInstances", "ec2:StopInstances",
              "ec2:RebootInstances", "ec2:TerminateInstances"],
   "Resource": "*"},
  {"Sid": "TuChoiNeuKhacDoi",
   "Effect": "Deny",
   "Action": ["ec2:StartInstances", "ec2:StopInstances",
              "ec2:RebootInstances", "ec2:TerminateInstances"],
   "Resource": "*",
   "Condition": {"StringNotEquals": {
     "ec2:ResourceTag/DevelopmentDept":
       "${aws:PrincipalTag/DevelopmentDept}"}}}]}

⚠ Cú pháp ${aws:PrincipalTag/...} là biến chính sách:

IAM thay biến đó bằng giá trị thẻ
  phiên của người đang gọi
        ↓
    MỘT chính sách phục vụ mọi đội
        ↓
    Thêm đội mới → không sửa chính
      sách

Truyền session tag trong khẳng định SAML:

<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:DevelopmentDept">
  <AttributeValue>doi-thanh-toan</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys">
  <AttributeValue>DevelopmentDept</AttributeValue>
</Attribute>

⚠ TransitiveTagKeys giữ thẻ qua các lần giả nhận vai trò tiếp theo:

Người dùng giả nhận vai trò A
        ↓
    Từ A giả nhận tiếp vai trò B
        ↓
    Không khai transitive
    → thẻ mất ở bước hai
        ↓
    Khai transitive → thẻ đi theo

⚠ Và vì sao phương án A không hoạt động — SCP không dùng Allow kiểu đó:

A dùng SCP với hành động ALLOW và
  điều kiện StringEquals
        ↓
    SCP là TRẦN quyền, không phải
      nguồn cấp quyền
        ↓
    Một SCP chỉ Allow một hành động
      cụ thể
    → mọi hành động khác bị chặn
        ↓
    Gắn vào root OU → tê liệt cả
      tổ chức

⚠ Và SCP có hỗ trợ aws:PrincipalTag, nhưng cách viết phải là Deny:

{"Effect": "Deny",
 "Action": "ec2:StopInstances",
 "Resource": "*",
 "Condition": {"StringNotEquals": {
   "ec2:ResourceTag/DevelopmentDept":
     "${aws:PrincipalTag/DevelopmentDept}"}}}

Viết đúng thì SCP cũng làm được
        ↓
    Và mạnh hơn vì quản trị viên
      tài khoản không gỡ được
        ↓
    Nhưng phương án A viết là Allow
    → không dùng được

⚠ Và vì sao phương án B sai — mọi đội dùng CHUNG một tài khoản:

B lập OU riêng cho từng phòng ban
  và gắn SCP theo OU
        ↓
    Nhưng đề nói rõ: "MỘT tài khoản
      sản xuất DÙNG CHUNG cho mọi đội"
        ↓
    OU áp cho TÀI KHOẢN
    → không phân biệt được các đội
      trong cùng một tài khoản

⚠ Và vì sao phương án D không mở rộng được:

D tạo một IAM policy RIÊNG cho mỗi
  phòng ban
        ↓
    Mười đội → mười chính sách
        ↓
    Thêm đội → thêm chính sách,
      thêm vai trò
        ↓
    ABAC: MỘT chính sách cho tất cả

⚠ Và ABAC còn cần bắt buộc gắn thẻ khi tạo tài nguyên:

{"Effect": "Deny",
 "Action": "ec2:RunInstances",
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"StringNotEquals": {
   "aws:RequestTag/DevelopmentDept":
     "${aws:PrincipalTag/DevelopmentDept}"}}}

Không có ràng buộc này
        ↓
    Đội A tạo máy và gắn thẻ đội B
        ↓
    Rồi không tự sửa được máy của
      chính mình

⚠ Và phải cấm sửa thẻ:

{"Effect": "Deny",
 "Action": ["ec2:CreateTags", "ec2:DeleteTags"],
 "Resource": "*",
 "Condition": {"ForAnyValue:StringEquals": {
   "aws:TagKeys": ["DevelopmentDept"]}}}

Không cấm: đội A đổi thẻ máy của
  đội B thành của mình
        ↓
    Rồi tắt nó
    → toàn bộ cơ chế vô hiệu

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một chính sách cho mọi đội | | | Thêm đội không cần sửa gì | | | Danh tính quản ở IdP, quyền quản bằng thẻ | |

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

• **D. Tạo IAM policy riêng cho từng phòng ban với điều kiện StringEquals và gán vai trò tương ứng khi liên kết SAML — đây là phương án gần nhất và thật sự thực thi được sự cách ly, nhưng số chính sách và vai trò tăng theo số đội, trái với tinh thần ABAC vốn dùng một chính sách duy nhất.
• **A. Truyền session tag và dùng SCP với hành động Allow gắn vào root OU — SCP là trần quyền chứ không cấp quyền; một SCP chỉ Allow một hành động sẽ chặn mọi hành động khác của toàn tổ chức.
• **B. Lập OU riêng cho từng phòng ban và gắn SCP theo OU — mọi đội dùng chung một tài khoản sản xuất, nên OU không phân biệt được họ.

Ghi nhớ

⚠ RBAC và ABAC — bảng phải thuộc: | Tiêu chí | RBAC | ABAC | |---|---|---| | Số chính sách | tăng theo số nhóm | một cho tất cả | | Thêm đội mới | tạo chính sách và vai trò mới | chỉ thêm giá trị thẻ | | Điều kiện | ARN cụ thể | so thẻ với thẻ | | Yêu cầu | không | mọi tài nguyên phải có thẻ đúng |

Từ khoá nhận diện:

"teams share one account, isolate resources" → ABAC với session tag "scales without new policies" → ABAC "prevent even account admin" → SCP "pass attribute during SAML federation" → session tag

⚠ Ba khoá điều kiện của ABAC: | Khoá | Nghĩa | |---|---| | aws:PrincipalTag/Khoa | thẻ của người gọi | | aws:ResourceTag/Khoa | thẻ của tài nguyên | | aws:RequestTag/Khoa | thẻ trong yêu cầu tạo |

Ba lưu ý về session tag: | Lưu ý | Chi tiết | |---|---| | Tối đa 50 thẻ mỗi phiên | | | Khoá tối đa 128 ký tự, giá trị 256 | | | TransitiveTagKeys giữ qua nhiều lần giả nhận | |

⚠ Session tag đè lên thẻ của vai trò:

Vai trò có thẻ DevelopmentDept = X
        ↓
    Phiên truyền DevelopmentDept = Y
        ↓
    Giá trị hiệu lực là Y
    → session tag thắng

Ba lưu ý về dịch vụ hỗ trợ ABAC: | Dịch vụ | Hỗ trợ ResourceTag | |---|---| | EC2, RDS, Lambda, S3 (bucket) | CÓ | | S3 object | CÓ, qua s3:ExistingObjectTag | | Một số dịch vụ cũ | KHÔNG — phải kiểm tài liệu |

⚠ Không phải dịch vụ nào cũng hỗ trợ đầy đủ:

Kiểm bảng "Actions, resources, and
  condition keys" của từng dịch vụ
        ↓
    Hành động không hỗ trợ
      `ResourceTag`
    → chính sách ABAC không áp được
        ↓
    Phải bù bằng cách khác

Ba lưu ý về bắt buộc gắn thẻ: | Lưu ý | Chi tiết | |---|---| | Deny tạo tài nguyên không có thẻ | | | Deny gắn thẻ khác với thẻ của mình | | | Deny xoá thẻ kiểm soát | |

Ba lưu ý về IAM Identity Center: | Lưu ý | Chi tiết | |---|---| | Hỗ trợ ABAC bằng thuộc tính từ IdP | | | Permission set dùng chung nhiều tài khoản | | | Đơn giản hơn tự dựng liên kết SAML | |

⚠ Identity Center bật ABAC bằng một cấu hình:

aws sso-admin create-instance-access-control-attribute-configuration \
  --instance-arn <arn> \
  --instance-access-control-attribute-configuration '{
    "AccessControlAttributes": [{
      "Key": "DevelopmentDept",
      "Value": {"Source": ["${path:enterprise.department}"]}}]}'

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử tắt máy của đội khác — phải bị từ chối | | | Thử tắt máy của đội mình — phải được | | | Thử đổi thẻ của máy đội khác — phải bị từ chối | |

Và một lời khuyên: hãy cấm sửa thẻ kiểm soát ngay khi triển khai ABAC. Toàn bộ cơ chế cách ly dựa vào giá trị của một thẻ, nên nếu lập trình viên đổi được thẻ đó thì họ tự cấp cho mình quyền trên bất kỳ tài nguyên nào — và điều đó không để lại dấu vết nào ngoài một dòng CreateTags trong CloudTrail.

Đáp án

**D — Tách RDS DB instance khỏi môi trường Beanstalk (môi trường A), rồi dùng triển khai blue/green của chính Elastic Beanstalk để môi trường B kết nối tới cơ sở dữ liệu đã tách sau khi nâng cấp.

Vì sao đúng

Đề nêu hai ràng buộc, và cả hai đều bắt buộc phải tách CSDL ra trước:

Nâng cấp từ môi trường A sang B
        ↓
    KHÔNG được gián đoạn
        ↓
    KHÔNG được mất dữ liệu

⚠ Điểm mấu chốt: RDS nằm TRONG môi trường Beanstalk sẽ bị XOÁ theo môi trường:

Tạo RDS qua console Beanstalk
        ↓
    Nó thành tài nguyên của môi
      trường đó
        ↓
    Chấm dứt môi trường → XOÁ CSDL
        ↓
    Đây chính là "dependency" mà
      đề nói phải gỡ bỏ

⚠ Và quy trình tách gồm hai bước quan trọng:

1. Đặt DeletionPolicy = Retain
        ↓
2. Gỡ khai báo RDS khỏi cấu hình
     môi trường
        ↓
    RDS trở thành tài nguyên độc lập
    → môi trường bị xoá cũng không
      ảnh hưởng

Đặt chính sách giữ lại:

# .ebextensions/rds-giu-lai.config
Resources:
  AWSEBRDSDatabase:
    DeletionPolicy: Retain

⚠ Phải triển khai cấu hình đó TRƯỚC khi tách:

Không đặt DeletionPolicy
        ↓
    Gỡ RDS khỏi môi trường
    → CloudFormation XOÁ nó
        ↓
    Mất toàn bộ dữ liệu

Quy trình đầy đủ không gián đoạn:

1. Chụp snapshot CSDL (an toàn)
        ↓
2. Triển khai .ebextensions với
     DeletionPolicy: Retain
        ↓
3. Lưu lại endpoint, user, password
        ↓
4. Tạo cấu hình môi trường mới KHÔNG
     có RDS, khai chuỗi kết nối qua
     biến môi trường
        ↓
5. Dựng môi trường B với cấu hình đó
        ↓
6. Kiểm thử môi trường B
        ↓
7. Swap URL giữa A và B
        ↓
8. Chấm dứt A — CSDL vẫn còn

Khai chuỗi kết nối bằng biến môi trường:

aws elasticbeanstalk update-environment \
  --environment-name moi-truong-b \
  --option-settings \
    Namespace=aws:elasticbeanstalk:application:environment,\
OptionName=DB_HOST,Value=csdl.abc.rds.amazonaws.com \
    Namespace=aws:elasticbeanstalk:application:environment,\
OptionName=DB_NAME,Value=ung_dung

⚠ Và swap URL của Beanstalk là cách chuyển đổi không gián đoạn:

aws elasticbeanstalk swap-environment-cnames \
  --source-environment-name moi-truong-a \
  --destination-environment-name moi-truong-b

⚠ Nhưng swap CNAME có độ trễ DNS — chi tiết phải biết:

Swap đổi bản ghi CNAME
        ↓
    Client đã cache DNS vẫn tới
      môi trường cũ
        ↓
    Giữ môi trường A chạy thêm một
      thời gian
    → và hạ TTL từ trước

⚠ Và vì sao phương án C sai — rolling deployment không tách được CSDL:

Rolling deployment cập nhật ứng
  dụng theo lô TRONG cùng môi trường
        ↓
    Không tạo môi trường mới
        ↓
    Và không đụng gì tới quan hệ
      giữa môi trường và RDS

⚠ Và vì sao phương án A sai — CodeDeploy không quản môi trường Beanstalk:

CodeDeploy triển khai ỨNG DỤNG lên
  EC2, Lambda, ECS
        ↓
    Beanstalk có cơ chế triển khai
      riêng
        ↓
    Hai dịch vụ không phối hợp theo
      cách đó

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

B dùng CloudFormation dựng blue/green
        ↓
    Nhưng không nói tách RDS bằng
      cách nào
        ↓
    Nếu RDS vẫn nằm trong stack của
      môi trường A
    → xoá stack đó vẫn mất CSDL

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | CSDL sống độc lập với vòng đời môi trường | | | Chuyển đổi bằng swap URL, không gián đoạn | | | Quay lui chỉ cần swap ngược | |

⚠ Và đây là lý do KHÔNG NÊN đặt RDS trong môi trường Beanstalk ngay từ đầu:

RDS trong môi trường: tiện lúc dựng
        ↓
    Nhưng gắn vòng đời CSDL với vòng
      đời ứng dụng
        ↓
    Mọi thao tác blue/green đều
      thành rủi ro mất dữ liệu
        ↓
    AWS khuyến nghị đặt RDS ngoài
      cho môi trường sản xuất

⚠ Và security group phải cho phép môi trường mới truy cập:

aws ec2 authorize-security-group-ingress \
  --group-id sg-rds \
  --protocol tcp --port 5432 \
  --source-group sg-moi-truong-b

Môi trường B có security group MỚI
        ↓
    RDS chưa cho phép nó
    → kết nối thất bại
        ↓
    Bước hay bị quên nhất

⚠ Và cả hai môi trường dùng chung một CSDL trong giai đoạn chuyển:

A và B cùng ghi vào một CSDL
        ↓
    Schema phải tương thích cả hai
      phiên bản ứng dụng
        ↓
    Quy tắc: mở rộng trước, thu hẹp
      sau
    → thêm cột nullable, triển khai
      mã, rồi mới siết ràng buộc

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

• **B. Dùng CloudFormation dựng blue/green để tách RDS khỏi môi trường A — đây là phương án gần nhất và CloudFormation thật sự là nền của Beanstalk, nhưng nó không nêu bước tách RDS; nếu CSDL vẫn nằm trong stack của môi trường A thì xoá môi trường vẫn mất dữ liệu.
• **C. Dùng rolling deployment policy của Beanstalk để tách RDS — rolling deployment cập nhật ứng dụng trong cùng môi trường, không tạo môi trường mới và không đụng tới quan hệ với RDS.
• **A. Dùng AWS CodeDeploy quản lý blue/green — CodeDeploy triển khai lên EC2, Lambda, ECS; nó không quản lý môi trường Beanstalk.

Ghi nhớ

⚠ Hai cách gắn RDS với Beanstalk — bảng phải thuộc: | Cách | Vòng đời CSDL | |---|---| | Tạo trong môi trường | gắn với môi trường, xoá theo | | Tạo ngoài, khai qua biến môi trường | độc lập |

Từ khoá nhận diện:

"decouple RDS from Beanstalk" → DeletionPolicy Retain + gỡ khai báo "no downtime environment upgrade" → blue/green + swap CNAME "rolling deployment" → cập nhật trong cùng môi trường "immutable deployment" → dựng đội mới trong cùng môi trường

⚠ Bốn chính sách triển khai của Beanstalk: | Chính sách | Gián đoạn | Tốc độ | |---|---|---| | All at once | CÓ | nhanh nhất | | Rolling | giảm công suất | trung bình | | Rolling with additional batch | không | chậm hơn | | Immutable | không | chậm nhất, an toàn nhất |

Ba lưu ý về blue/green trong Beanstalk: | Lưu ý | Chi tiết | |---|---| | Hai môi trường độc lập | | | Swap CNAME để chuyển đổi | | | Quay lui bằng swap ngược | |

Ba lưu ý về .ebextensions: | Lưu ý | Chi tiết | |---|---| | Tệp YAML trong thư mục .ebextensions/ | | | Chạy theo thứ tự chữ cái | | | Sửa được tài nguyên CloudFormation phía dưới | |

⚠ Beanstalk sinh ra một stack CloudFormation:

Mọi tài nguyên của môi trường nằm
  trong stack đó
        ↓
    `.ebextensions` chèn thêm hoặc
      sửa tài nguyên
        ↓
    Đây là cách đặt DeletionPolicy

Ba lưu ý về di trú schema: | Nguyên tắc | Chi tiết | |---|---| | Mở rộng trước, thu hẹp sau | | | Thêm cột nullable, không xoá cột đang dùng | | | Hai phiên bản ứng dụng phải cùng chạy được | |

Ba lưu ý về swap CNAME: | Lưu ý | Chi tiết | |---|---| | Hạ TTL từ nhiều ngày trước | | | Giữ môi trường cũ chạy thêm một thời gian | | | Kiểm chỉ số của môi trường mới trước khi xoá cũ | |

Ba lưu ý về giữ dữ liệu: | Lưu ý | Chi tiết | |---|---| | Chụp snapshot trước mọi thao tác lớn | | | Bật deletion protection cho RDS | | | DeletionPolicy Retain trong CloudFormation | |

⚠ Deletion protection là lớp bảo vệ độc lập:

aws rds modify-db-instance \
  --db-instance-identifier csdl \
  --deletion-protection

Không xoá được instance dù có
  quyền
        ↓
    Phải tắt cờ đó trước
    → một bước cố ý để dừng lại
      suy nghĩ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm RDS không còn trong stack của môi trường | | | Chấm dứt môi trường thử và xem CSDL còn không | | | Kiểm security group cho phép môi trường mới | |

Và một lời khuyên: hãy chụp snapshot cơ sở dữ liệu trước khi bắt đầu quy trình tách. DeletionPolicy: Retain chỉ có hiệu lực nếu bạn triển khai nó thành công trước bước gỡ khai báo — và nếu thứ tự bị đảo, CloudFormation sẽ xoá cơ sở dữ liệu một cách hoàn toàn đúng theo cấu hình mà bạn vừa đưa cho nó.

Đáp án

**A — Tạo một private virtual interface trên kết nối Direct Connect ở us-east-1; dựng một interface VPC endpoint và cấu hình hệ thống tại chỗ truy cập S3 qua endpoint đó.

Vì sao đúng

Đề nêu một ràng buộc quyết định mọi thứ:

Bucket policy TỪ CHỐI truy cập từ
  ĐỊA CHỈ IP CÔNG KHAI
        ↓
    Mọi cách đi qua endpoint công
      khai của S3 đều bị chặn
        ↓
    Phải tới S3 bằng địa chỉ RIÊNG

⚠ Điểm mấu chốt: interface endpoint có IP RIÊNG trong VPC:

Interface endpoint tạo ENI trong
  subnet
        ↓
    ENI đó có IP riêng, ví dụ
      10.0.1.50
        ↓
    Máy tại chỗ gọi tới IP đó qua
      private VIF
    → S3 thấy nguồn là IP riêng

⚠ Và đây là lý do gateway endpoint KHÔNG dùng được: | Loại endpoint | Cơ chế | Dùng được từ tại chỗ | |---|---|---| | Gateway | route trong bảng định tuyến VPC | KHÔNG | | Interface | ENI có IP riêng | CÓ, qua DX hoặc VPN |

Gateway endpoint hoạt động bằng
  cách thêm tuyến vào route table
        ↓
    Máy tại chỗ không dùng route
      table của VPC
        ↓
    Không tới được

Tạo interface endpoint cho S3:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.us-east-1.s3 \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-1a subnet-1b \
  --security-group-ids sg-endpoint \
  --private-dns-enabled

⚠ Và --private-dns-enabled là chi tiết quan trọng:

Bật private DNS
        ↓
    `bucket.s3.us-east-1.amazonaws.com`
      phân giải thành IP RIÊNG
        ↓
    Ứng dụng không phải đổi endpoint
    → nhưng chỉ hoạt động TRONG VPC

⚠ Và từ TẠI CHỖ thì phải giải quyết DNS riêng:

Máy tại chỗ dùng DNS của công ty
        ↓
    Không phân giải được tên riêng
      của VPC
        ↓
    Ba cách:
      - Route 53 Resolver inbound
        endpoint
      - forwarder trỏ tới
        VPC_CIDR + 2
      - gọi thẳng tên DNS riêng của
        endpoint

aws ec2 describe-vpc-endpoints --vpc-endpoint-ids vpce-abc \
  --query 'VpcEndpoints[0].DnsEntries[].DnsName'

⚠ Và bucket policy nên khoá theo endpoint:

{"Effect": "Deny",
 "Principal": "*",
 "Action": "s3:*",
 "Resource": ["arn:aws:s3:::log-truy-cap",
              "arn:aws:s3:::log-truy-cap/*"],
 "Condition": {"StringNotEquals": {
   "aws:SourceVpce": "vpce-0abc123"}}}

⚠ Và vì sao phương án B sai — public VIF dùng IP công khai:

Public VIF tới endpoint công khai
  của S3
        ↓
    Địa chỉ nguồn là IP CÔNG KHAI
      của công ty
        ↓
    Bucket policy từ chối chính
      loại địa chỉ đó

⚠ Và HTTPS proxy trong phương án B cũng không cứu được:

Proxy tại chỗ chuyển tiếp tới S3
        ↓
    Vẫn qua endpoint công khai
        ↓
    Vẫn IP công khai

⚠ Và vì sao phương án C sai — không quảng bá tuyến cho S3 được:

C nói dùng BGP quảng bá tuyến cho S3
        ↓
    S3 không có dải IP cố định để
      quảng bá
        ↓
    Và qua Site-to-Site VPN tới VGW
      thì cũng chỉ vào VPC
    → vẫn cần endpoint để tới S3

⚠ Và vì sao phương án D sai — NAT gateway biến IP thành công khai:

D dùng NAT gateway và HTTPS proxy
  trong VPC
        ↓
    NAT gateway dịch địa chỉ nguồn
      thành IP CÔNG KHAI của nó
        ↓
    S3 thấy IP công khai
    → bị chặn

⚠ Đây là điểm quan trọng về NAT gateway:

NAT gateway có Elastic IP công khai
        ↓
    Mọi lưu lượng qua nó ra ngoài
      đều mang IP đó
        ↓
    Muốn tới S3 bằng IP riêng
    → phải dùng endpoint, không
      phải NAT

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lưu lượng không bao giờ ra Internet | | | Địa chỉ nguồn là IP riêng, qua được bucket policy | | | Đáp ứng yêu cầu PCI-DSS về cách ly mạng | |

⚠ Và PCI-DSS có yêu cầu cụ thể về việc này:

PCI-DSS yêu cầu mã hoá dữ liệu chủ
  thẻ khi truyền qua mạng công cộng
        ↓
    Direct Connect + private VIF +
      interface endpoint
    → dữ liệu không đi qua mạng
      công cộng chút nào
        ↓
    Đơn giản hoá phạm vi kiểm toán

⚠ Nhưng Direct Connect KHÔNG mã hoá:

DX là đường riêng, không phải
  đường mã hoá
        ↓
    Lưu lượng tới S3 vẫn dùng HTTPS
    → nên nội dung được bảo vệ
        ↓
    Cần mã hoá tầng dưới
    → MACsec hoặc VPN chồng lên DX

⚠ Và interface endpoint tính phí — khác gateway endpoint: | Loại | Chi phí | |---|---| | Gateway endpoint | MIỄN PHÍ | | Interface endpoint | ~0,01 USD/giờ mỗi AZ + phí GB |

Nhiều VPC cần endpoint
        ↓
    Cân nhắc endpoint tập trung ở
      shared services VPC
        ↓
    Nhưng gateway endpoint không
      chia sẻ được — chỉ interface

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

• **B. Tạo public virtual interface và dùng HTTPS proxy tại chỗ gửi lưu lượng tới S3 qua Direct Connect — đây là phương án gần nhất và public VIF thật sự cho phép tới S3 qua đường Direct Connect, nhưng địa chỉ nguồn vẫn là IP công khai, đúng thứ mà bucket policy từ chối.
• **D. Dựng VPN tới VPC, tạo NAT gateway và dùng HTTPS proxy trong VPC — NAT gateway dịch địa chỉ nguồn thành IP công khai của nó.
• **C. Dựng Site-to-Site VPN và dùng BGP quảng bá tuyến cho S3 — S3 không có dải IP cố định để quảng bá, và VPN tới VGW chỉ vào được VPC.

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc: | Tiêu chí | Gateway | Interface | |---|---|---| | Dịch vụ | S3, DynamoDB | hầu hết dịch vụ khác | | Cơ chế | route table | ENI có IP riêng | | Từ tại chỗ (DX/VPN) | KHÔNG | CÓ | | Chi phí | miễn phí | theo giờ + GB |

Từ khoá nhận diện:

"access S3 from on-premises with private IP" → interface endpoint + private VIF "deny public IP addresses" → aws:SourceVpce hoặc aws:SourceVpc "S3 access from within VPC only" → gateway endpoint (miễn phí) "traffic must not traverse Internet" → DX + private VIF + interface endpoint

Ba lưu ý về interface endpoint: | Lưu ý | Chi tiết | |---|---| | Tạo ENI, tốn IP trong subnet | | | Security group kiểm soát ai gọi tới | | | Endpoint policy giới hạn gọi được gì | |

⚠ Endpoint policy là lớp kiểm soát thứ hai:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:PutObject"],
  "Resource": "arn:aws:s3:::log-truy-cap/*",
  "Condition": {"StringEquals": {
    "aws:PrincipalOrgID": "o-abc123"}}}]}

Ba lưu ý về DNS cho endpoint: | Tình huống | Cách | |---|---| | Từ trong VPC | private DNS tự phân giải | | Từ tại chỗ | Resolver inbound endpoint | | Endpoint tập trung | tắt private DNS, dùng private hosted zone |

Ba lưu ý về Direct Connect: | Lưu ý | Chi tiết | |---|---| | Private VIF tới VPC | | | Public VIF tới dịch vụ công khai | | | KHÔNG mã hoá — cần MACsec hoặc VPN | |

Ba lưu ý về khoá bucket theo mạng: | Khoá điều kiện | Dùng khi | |---|---| | aws:SourceVpce | một endpoint cụ thể | | aws:SourceVpc | cả VPC | | aws:SourceIp | IP công khai — KHÔNG khớp với endpoint |

⚠ Chú ý khi viết chính sách Deny theo endpoint:

Deny áp cho MỌI principal, kể cả bạn
        ↓
    Không truy cập được từ console
        ↓
    Chừa ngoại lệ cho vai trò quản
      trị khẩn cấp

Ba lưu ý về PCI-DSS trên AWS: | Lưu ý | Chi tiết | |---|---| | AWS chịu trách nhiệm hạ tầng | | | Khách hàng chịu trách nhiệm cấu hình | | | Artifact có báo cáo tuân thủ của AWS | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig tên bucket từ máy tại chỗ — phải ra IP riêng | | | Tải lên một tệp và kiểm thành công | | | Thử từ Internet — phải bị từ chối | |

Và một lời khuyên: hãy kiểm tra phân giải DNS từ máy tại chỗ trước khi kết luận endpoint không hoạt động. Interface endpoint hoạt động hoàn hảo trong VPC nhờ private DNS, nhưng máy tại chỗ dùng máy phân giải khác — và triệu chứng của việc thiếu Resolver inbound endpoint giống hệt triệu chứng của một endpoint cấu hình sai.

Đáp án

**D — Bật mã hoá mặc định bằng khoá do S3 quản lý (SSE-S3, AES-256) trên bucket chứa audit log, và dùng Redshift Spectrum để truy vấn dữ liệu phục vụ kiểm toán hằng tháng.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp cả ba với chi phí thấp nhất: | Yêu cầu | Cách đáp ứng | |---|---| | Mã hoá log khi lưu | SSE-S3 (AES-256) | | Giữ ít nhất một năm | S3 với luật vòng đời | | Truy vấn hằng tháng, hiệu quả chi phí | Redshift Spectrum |

⚠ Điểm mấu chốt thứ nhất: SSE-S3 rẻ hơn SSE-KMS: | Cách mã hoá | Chi phí | |---|---| | SSE-S3 | MIỄN PHÍ | | SSE-KMS | 1 USD/khoá/tháng + 0,03 USD/10.000 lời gọi API |

Audit log của Redshift sinh ra rất
  nhiều tệp
        ↓
    Mỗi lần đọc/ghi là một lời gọi
      KMS
        ↓
    Với hàng triệu tệp, phí KMS
      đáng kể
        ↓
    SSE-S3 mã hoá bằng AES-256 và
      không tính phí

⚠ Và đề không yêu cầu kiểm soát khoá riêng:

Yêu cầu: "lưu log AN TOÀN bằng cách
  MÃ HOÁ khi lưu"
        ↓
    Không nói phải tự quản khoá
        ↓
    Không nói phải kiểm toán việc
      dùng khoá
        ↓
    SSE-S3 đáp ứng đủ

Bật mã hoá mặc định:

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

⚠ Điểm mấu chốt thứ hai: Redshift Spectrum truy vấn TẠI CHỖ trên S3:

Log nằm trên S3
        ↓
    Spectrum tạo bảng ngoài trỏ tới đó
        ↓
    Truy vấn SQL trực tiếp
    → KHÔNG nạp vào cụm

Tạo bảng ngoài cho audit log:

CREATE EXTERNAL SCHEMA spectrum_audit
FROM DATA CATALOG DATABASE 'audit_db'
IAM_ROLE 'arn:aws:iam::111122223333:role/RedshiftSpectrum'
CREATE EXTERNAL DATABASE IF NOT EXISTS;

CREATE EXTERNAL TABLE spectrum_audit.user_activity (
    userid       INT,
    username     VARCHAR(50),
    xid          BIGINT,
    recordtime   VARCHAR(50),
    db           VARCHAR(50),
    query        VARCHAR(60000))
PARTITIONED BY (nam VARCHAR(4), thang VARCHAR(2))
ROW FORMAT DELIMITED FIELDS TERMINATED BY '|'
LOCATION 's3://audit-log-redshift/AWSLogs/';

⚠ Và vì sao phương án A sai — nạp vào cụm là ngược hướng:

A nạp dữ liệu từ S3 VÀO cụm Redshift
  mỗi khi cần kiểm toán
        ↓
    Chiếm dung lượng cụm
        ↓
    Tốn thời gian COPY
        ↓
    Và phải xoá đi sau
    → quy trình thủ công lặp lại
      hằng tháng

⚠ Và vì sao phương án C đắt hơn mà không cần thiết:

C dùng SSE-KMS + Spectrum
        ↓
    Vế Spectrum đúng
        ↓
    Nhưng SSE-KMS tính phí khoá và
      phí lời gọi API
        ↓
    Đề hỏi "hiệu quả chi phí"

⚠ Nhưng S3 Bucket Keys giảm mạnh phí KMS nếu vẫn muốn dùng:

"BucketKeyEnabled": true

Giảm tới 99% lời gọi KMS
        ↓
    S3 xin một khoá cấp bucket rồi
      dùng lại
        ↓
    Với bucket log lớn, đây là biện
      pháp bắt buộc nếu chọn KMS

⚠ Và vì sao phương án B sai — QuickSight không truy vấn thẳng S3:

B dùng SSE-KMS + QuickSight
        ↓
    QuickSight kết nối tới Athena,
      Redshift, RDS...
        ↓
    Nó KHÔNG đọc thẳng tệp trên S3
    → phải qua Athena hoặc Spectrum
        ↓
    Và QuickSight là công cụ trực
      quan, không phải công cụ truy
      vấn kiểm toán

Bật audit logging của Redshift:

aws redshift enable-logging \
  --cluster-identifier cum-nghiep-vu \
  --bucket-name audit-log-redshift \
  --s3-key-prefix redshift-audit/

⚠ Và Redshift audit log có ba loại tệp: | Loại | Nội dung | |---|---| | Connection log | kết nối, xác thực, ngắt kết nối | | User log | thay đổi định nghĩa người dùng | | User activity log | mọi truy vấn đã chạy |

User activity log cần bật thêm
  tham số
        ↓
    `enable_user_activity_logging = true`
      trong parameter group
        ↓
    Đây là log quan trọng nhất cho
      kiểm toán

⚠ Và có thể ghi audit log vào CloudWatch Logs thay S3:

aws redshift modify-cluster \
  --cluster-identifier cum-nghiep-vu \
  --logging-properties '{
    "LogDestinationType": "cloudwatch",
    "LogExports": ["connectionlog","useractivitylog","userlog"]}'

Truy vấn ngay bằng Logs Insights
        ↓
    Nhưng lưu một năm ở CloudWatch
      Logs đắt hơn S3 nhiều
        ↓
    Đề yêu cầu giữ một năm
    → S3 rẻ hơn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mã hoá miễn phí | | | Không nạp dữ liệu vào cụm | | | Chỉ trả tiền cho phần quét khi kiểm toán | |

⚠ Và phân vùng là chìa khoá giảm chi phí Spectrum:

Kiểm toán tháng 9
        ↓
    `WHERE nam='2026' AND thang='09'`
        ↓
    Chỉ quét thư mục đó
    → thay vì quét cả năm

⚠ Và chuyển log sang Parquet giảm thêm một bậc nữa:

Log gốc là văn bản có phân cách
        ↓
    Glue job chuyển sang Parquet
        ↓
    Quét ít hơn nhiều lần
    → nhưng thêm một bước xử lý

⚠ Và luật vòng đời giữ một năm rồi xoá:

{"Rules": [{
  "ID": "giu-mot-nam",
  "Filter": {"Prefix": "redshift-audit/"},
  "Status": "Enabled",
  "Transitions": [{"Days": 90, "StorageClass": "STANDARD_IA"}],
  "Expiration": {"Days": 400}}]}

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

• **C. Bật SSE-KMS cho bucket audit log và dùng Redshift Spectrum — đây là phương án gần nhất và Spectrum hoàn toàn đúng, nhưng SSE-KMS tính phí khoá và phí lời gọi API, đắt hơn SSE-S3 mà đề không yêu cầu kiểm soát khoá riêng.
• **A. Bật SSE-S3 và nạp dữ liệu từ S3 vào cụm Redshift khi cần kiểm toán — nạp vào cụm chiếm dung lượng, tốn thời gian, và là quy trình thủ công lặp lại.
• **B. Bật SSE-KMS và dùng QuickSight truy vấn — QuickSight không đọc thẳng tệp trên S3, và nó là công cụ trực quan chứ không phải công cụ kiểm toán.

Ghi nhớ

⚠ Bốn cách mã hoá S3 — bảng phải thuộc: | Cách | Ai quản khoá | Chi phí | |---|---|---| | SSE-S3 | AWS hoàn toàn | miễn phí | | SSE-KMS | bạn, qua KMS | phí khoá + phí API | | DSSE-KMS | bạn, mã hoá hai lớp | cao hơn | | SSE-C | bạn giữ khoá | miễn phí, tự quản |

Từ khoá nhận diện:

"encrypt at rest, cost-effective" → SSE-S3 "audit key usage, control key policy" → SSE-KMS "query S3 data from Redshift" → Redshift Spectrum "query S3 without a cluster" → Athena

⚠ Athena cũng là câu trả lời hợp lệ:

Athena: serverless, không cần cụm
        ↓
    Spectrum: cần cụm Redshift đang
      chạy
        ↓
    Đề nói đã CÓ cụm Redshift
    → Spectrum tận dụng nó
        ↓
    Không có cụm → Athena rẻ hơn

Ba lưu ý về Redshift Spectrum: | Lưu ý | Chi tiết | |---|---| | Cần cụm Redshift đang chạy | | | Tính phí theo TB quét, tách khỏi phí cụm | | | JOIN được với bảng trong cụm | |

Ba lưu ý về giảm chi phí quét: | Cách | Mức giảm | |---|---| | Phân vùng | rất lớn | | Parquet/ORC | lớn | | Nén | vừa |

Ba lưu ý về audit log của Redshift: | Lưu ý | Chi tiết | |---|---| | User activity log cần bật tham số riêng | | | Giao vào S3 có độ trễ vài giờ | | | Cũng có bảng hệ thống STL_QUERY trong cụm | |

⚠ Bảng hệ thống chỉ giữ vài ngày:

`STL_QUERY`, `STL_CONNECTION_LOG`
  giữ khoảng 2-5 ngày
        ↓
    Đề yêu cầu giữ một năm
    → phải xuất ra S3

Ba lưu ý về S3 Bucket Keys: | Lưu ý | Chi tiết | |---|---| | Giảm tới 99% lời gọi KMS | | | Bật ở cấp bucket | | | Trong suốt với ứng dụng | |

Ba lưu ý về vòng đời log: | Tuổi | Lớp lưu trữ | |---|---| | 0-90 ngày | Standard | | 90-365 ngày | Standard-IA | | Trên 365 ngày | xoá hoặc Glacier |

Ba lưu ý về bảo vệ log kiểm toán: | Lưu ý | Chi tiết | |---|---| | Bucket ở tài khoản riêng | | | Object Lock chống xoá | | | Bật versioning | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy truy vấn Spectrum mẫu | | | Xem SVL_S3QUERY_SUMMARY biết đã quét bao nhiêu | | | Kiểm object có header mã hoá | |

Và một lời khuyên: hãy phân vùng audit log theo năm và tháng ngay từ khi bật ghi log. Kiểm toán hằng tháng chỉ cần một tháng dữ liệu, nhưng nếu không phân vùng thì mỗi truy vấn sẽ quét cả năm — và chi phí đó nhân lên mười hai lần mỗi năm.

Đáp án

**D và E — Dùng S3 MFA Delete trên bucket chứa log CloudTrail và tệp digest; và bật CloudTrail log file integrity validation.

Vì sao đúng

Đề hỏi cách bảo vệ log CloudTrail với ít công sức nhất, và hai đáp án đều là tính năng bật bằng một lệnh: | Đáp án | Chống gì | |---|---| | MFA Delete | xoá log, kể cả cố ý | | Log file integrity validation | sửa đổi log mà không bị phát hiện |

⚠ Điểm mấu chốt: hai mối đe doạ khác nhau cần hai biện pháp khác nhau:

Kẻ tấn công muốn xoá dấu vết
        ↓
    Cách 1: XOÁ tệp log
    → MFA Delete chặn
        ↓
    Cách 2: SỬA nội dung log
    → integrity validation phát hiện

Bật log file integrity validation:

aws cloudtrail update-trail --name trail-chinh \
  --enable-log-file-validation

⚠ Cơ chế: CloudTrail ký số và sinh tệp digest mỗi giờ:

Mỗi tệp log có mã hash SHA-256
        ↓
    Tệp digest chứa hash của mọi
      tệp log trong giờ đó
        ↓
    Digest được ký bằng khoá riêng
      của CloudTrail
        ↓
    Và mỗi digest tham chiếu digest
      TRƯỚC ĐÓ
    → tạo thành chuỗi liên kết

⚠ Chuỗi liên kết là chi tiết quan trọng nhất:

Xoá một tệp digest
        ↓
    Chuỗi bị đứt
        ↓
    `validate-logs` phát hiện ngay
    → không thể xoá âm thầm

Kiểm chứng:

aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:ap-southeast-1:111122223333:trail/trail-chinh \
  --start-time 2026-08-01T00:00:00Z \
  --end-time 2026-09-01T00:00:00Z

Bật MFA Delete:

aws s3api put-bucket-versioning --bucket log-cloudtrail \
  --versioning-configuration Status=Enabled,MFADelete=Enabled \
  --mfa "arn:aws:iam::111122223333:mfa/root-account-mfa-device 123456"

⚠ MFA Delete có ba ràng buộc phải biết: | Ràng buộc | Chi tiết | |---|---| | Chỉ ROOT bật được | không phải IAM user | | Bắt buộc bật versioning | MFA Delete không tồn tại độc lập | | Chỉ dùng được qua CLI/API | console không hỗ trợ |

Đây là lý do mệnh đề A (versioning)
  cũng là điều kiện tiên quyết
        ↓
    Nhưng nó không phải BIỆN PHÁP
      bảo vệ tự thân
    → nó là điều kiện để MFA Delete
      hoạt động

⚠ Và MFA Delete bảo vệ hai thao tác:

Xoá vĩnh viễn một PHIÊN BẢN object
        ↓
    Tắt versioning của bucket
        ↓
    Cả hai đều đòi mã MFA
    → xoá thông thường chỉ tạo
      delete marker, không mất dữ liệu

⚠ Và vì sao mệnh đề B không phải "ít công sức":

B dùng CloudWatch alarm báo khi log
  bị thay đổi
        ↓
    Phải dựng: data event cho bucket
      log, metric filter, alarm, SNS
        ↓
    Nhiều bước hơn hẳn hai lệnh
        ↓
    Và nó chỉ PHÁT HIỆN, không CHẶN

⚠ Và vì sao mệnh đề C là thực hành tệ:

C nói dùng tài khoản ROOT để quản
  log CloudTrail
        ↓
    Root chỉ nên dùng cho vài thao
      tác bắt buộc
        ↓
    Dùng root hằng ngày là mở rộng
      rủi ro
    → trái với mọi khuyến nghị

⚠ Nhưng có một mỉa mai: MFA Delete lại BẮT BUỘC dùng root:

Chỉ root bật/tắt được MFA Delete
        ↓
    Đó là thao tác một lần
        ↓
    Khác hẳn việc "dùng root để
      quản lý log" hằng ngày

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không xoá được log nếu không có MFA | | | Phát hiện được mọi sửa đổi | | | Cả hai bật bằng một lệnh | |

⚠ Và có lớp bảo vệ mạnh hơn nữa — bucket ở tài khoản riêng:

Log ghi vào bucket ở tài khoản
  KIỂM TOÁN
        ↓
    Tài khoản sản xuất chỉ có quyền
      GHI
        ↓
    Kẻ chiếm được tài khoản sản xuất
      không xoá được log
    → đây là mẫu "log archive
      account" của Control Tower

⚠ Và S3 Object Lock là lựa chọn hiện đại hơn MFA Delete:

aws s3api put-object-lock-configuration \
  --bucket log-cloudtrail \
  --object-lock-configuration '{
    "ObjectLockEnabled": "Enabled",
    "Rule": {"DefaultRetention": {
      "Mode": "COMPLIANCE", "Years": 7}}}'

MFA Delete cản trở tự động hoá
        ↓
    Mọi thao tác dọn dẹp đều cần
      người nhập mã
        ↓
    Object Lock chặt hơn và không
      cản tự động hoá

⚠ Và SCP cấm tắt CloudTrail là lớp cuối:

{"Effect": "Deny",
 "Action": ["cloudtrail:StopLogging",
            "cloudtrail:DeleteTrail",
            "cloudtrail:UpdateTrail",
            "cloudtrail:PutEventSelectors"],
 "Resource": "*"}

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

• **A. Bật versioning trên bucket chứa log và tệp digest — đây là phương án gần nhất và thật sự là điều kiện tiên quyết của MFA Delete, nhưng bản thân versioning chỉ giữ phiên bản cũ; ai có quyền vẫn xoá vĩnh viễn được. Nó là nền chứ không phải biện pháp bảo vệ.
• **B. Tích hợp CloudWatch alarm báo khi log CloudTrail bị thay đổi — cần dựng nhiều thành phần, và chỉ phát hiện chứ không chặn.
• **C. Dùng tài khoản root để quản lý log CloudTrail — vi phạm nghiêm trọng thực hành bảo mật.

Ghi nhớ

⚠ Bốn lớp bảo vệ log CloudTrail — bảng phải thuộc: | Lớp | Chống | |---|---| | Log file integrity validation | sửa đổi âm thầm | | MFA Delete hoặc Object Lock | xoá | | Bucket ở tài khoản riêng | kẻ chiếm tài khoản sản xuất | | SCP cấm tắt trail | tắt ghi log |

Từ khoá nhận diện:

"detect log tampering" → log file integrity validation "prevent log deletion" → MFA Delete hoặc Object Lock "nobody can delete, not even root" → Object Lock Compliance "prevent stopping CloudTrail" → SCP

Ba lưu ý về integrity validation: | Lưu ý | Chi tiết | |---|---| | Sinh tệp digest mỗi giờ | | | Mỗi digest tham chiếu digest trước | | | validate-logs kiểm chuỗi | |

⚠ Digest nằm ở tiền tố riêng:

s3://bucket/AWSLogs/<account>/CloudTrail-Digest/
        ↓
    Đừng đặt luật vòng đời xoá nó
      sớm hơn log
        ↓
    Mất digest → không kiểm chứng
      được nữa

Ba lưu ý về MFA Delete: | Lưu ý | Chi tiết | |---|---| | Chỉ root bật/tắt được | | | Cần versioning | | | Chỉ CLI/API, không có trong console | |

Ba lưu ý về Object Lock: | Lưu ý | Chi tiết | |---|---| | Phải bật khi TẠO bucket | | | Governance mode gỡ được với quyền đặc biệt | | | Compliance mode không ai gỡ được | |

Ba lưu ý về organization trail: | Lưu ý | Chi tiết | |---|---| | Một trail cho mọi tài khoản | | | Tài khoản mới tự vào | | | Tài khoản con không tắt được | |

Ba lưu ý về mã hoá log: | Lưu ý | Chi tiết | |---|---| | SSE-KMS cho phép kiểm soát ai giải mã | | | Chính sách khoá phải cho CloudTrail dùng | | | Người đọc log cần kms:Decrypt | |

⚠ Mã hoá bằng KMS thêm một lớp kiểm soát:

Kẻ tấn công có quyền đọc bucket
        ↓
    Nhưng không có quyền dùng khoá
    → không đọc được nội dung log

Ba lưu ý về phân tích log: | Công cụ | Việc | |---|---| | Athena | truy vấn SQL trên log S3 | | CloudWatch Logs Insights | truy vấn gần thời gian thực | | Security Lake | chuẩn hoá theo OCSF |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy validate-logs định kỳ | | | Thử xoá một phiên bản object — phải đòi MFA | | | Kiểm digest có liên tục không | |

Và một lời khuyên: hãy cân nhắc S3 Object Lock thay vì MFA Delete cho bucket log. MFA Delete bảo vệ tốt nhưng buộc mọi thao tác quản lý phải qua tài khoản root với mã MFA — điều đó khiến việc tự động hoá vòng đời log trở nên bất khả thi, và cuối cùng ai đó sẽ tắt nó đi để làm việc.

Đáp án

**C — Gửi cập nhật điểm số vào Kinesis Data Streams, dùng một hàm Lambda xử lý, và lưu kết quả vào DynamoDB.

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 | Thành phần | |---|---| | Chịu đỉnh lưu lượng lớn | Kinesis đệm, Lambda tự co giãn | | Xử lý ĐÚNG THỨ TỰ nhận | Kinesis giữ thứ tự trong shard | | Cơ sở dữ liệu sẵn sàng cao | DynamoDB sao chép 3 AZ | | Ít việc vận hành nhất | cả ba đều là dịch vụ quản lý |

⚠ Điểm mấu chốt: "xử lý theo thứ tự nhận" loại SNS ngay:

SNS là mô hình đẩy, KHÔNG bảo đảm
  thứ tự
        ↓
    Và SNS không lưu trữ
        ↓
    Lambda bị chặn → SNS thử lại
      rồi bỏ
    → mất cập nhật điểm

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

⚠ Và Kinesis giữ thứ tự TRONG MỖI SHARD:

Cùng partition key → cùng shard
        ↓
    Trong shard, bản ghi giữ đúng
      thứ tự
        ↓
    Dùng mã người chơi làm khoá
    → điểm của mỗi người xử lý
      đúng thứ tự

Gửi cập nhật điểm:

import boto3, json
kinesis = boto3.client('kinesis')

def cap_nhat_diem(ma_nguoi_choi, diem, thoi_diem):
    kinesis.put_record(
        StreamName='cap-nhat-diem',
        Data=json.dumps({'ma_nguoi_choi': ma_nguoi_choi,
                         'diem': diem,
                         'thoi_diem': thoi_diem}),
        PartitionKey=ma_nguoi_choi)

⚠ Và chọn partition key là quyết định thiết kế quan trọng nhất:

Mã người chơi làm khoá
        ↓
    Điểm của một người luôn cùng shard
    → giữ đúng thứ tự
        ↓
    Và phân tán đều trên nhiều shard
    → không có shard nóng

Lambda xử lý theo lô:

import base64, json, boto3
bang = boto3.resource('dynamodb').Table('diem-nguoi-choi')

def xu_ly(event, context):
    that_bai = []
    for r in event['Records']:
        try:
            dl = json.loads(base64.b64decode(r['kinesis']['data']))
            bang.update_item(
                Key={'ma_nguoi_choi': dl['ma_nguoi_choi']},
                UpdateExpression='SET diem = :d, cap_nhat = :t',
                ConditionExpression='attribute_not_exists(cap_nhat) '
                                    'OR cap_nhat < :t',
                ExpressionAttributeValues={':d': dl['diem'],
                                           ':t': dl['thoi_diem']})
        except bang.meta.client.exceptions.ConditionalCheckFailedException:
            pass
        except Exception:
            that_bai.append({'itemIdentifier':
                             r['kinesis']['sequenceNumber']})
    return {'batchItemFailures': that_bai}

⚠ ConditionExpression chống ghi đè bằng dữ liệu cũ:

Bản ghi được giao lại sau lỗi
        ↓
    Nếu điểm mới hơn đã ghi rồi
    → điều kiện chặn việc lùi lại
        ↓
    Đây là lớp bảo vệ ngoài thứ tự
      của shard

⚠ Và vì sao hai phương án dùng EC2 (A, D) thua:

Đề nói "giảm thiểu việc quản lý
  cần thiết để duy trì giải pháp"
        ↓
    Đội EC2 với Auto Scaling
    → phải vá hệ điều hành
    → phải quản AMI
    → phải viết logic checkpoint
        ↓
    Lambda: không có gì để vá

⚠ Và phương án A còn dùng SQS + RDS MySQL:

SQS Standard: KHÔNG giữ thứ tự
        ↓
    RDS MySQL: phải quản phiên bản,
      backup, chuyển đổi
        ↓
    Và ghi điểm số tần suất cao vào
      CSDL quan hệ
    → khó co giãn bằng DynamoDB

⚠ Và Lambda với Kinesis tự lo checkpoint:

Dùng KCL trên EC2
        ↓
    Phải quản bảng DynamoDB lưu
      checkpoint
    → phải xử lý cân bằng shard khi
      máy vào/ra
        ↓
    Lambda: AWS lo hết

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Thứ tự bảo đảm cho từng người chơi | | | Không có máy chủ nào phải quản | | | Kinesis đệm đỉnh, phát lại được | |

⚠ Và khả năng phát lại là lợi thế lớn của Kinesis:

Lambda có lỗi logic, ghi sai điểm
        ↓
    Sửa mã
        ↓
    Đọc lại từ `TRIM_HORIZON` hoặc
      từ một thời điểm
    → tính lại toàn bộ
        ↓
    SQS không làm được — tin đã xoá

⚠ Và chế độ on-demand bỏ được việc quản shard:

aws kinesis create-stream --stream-name cap-nhat-diem \
  --stream-mode-details StreamMode=ON_DEMAND

Tự co giãn tới 200 MB/s
        ↓
    Không phải resharding khi có đỉnh
    → phù hợp với "đỉnh lưu lượng lớn"

⚠ Nhưng cần chú ý: một bản ghi lỗi làm KẸT cả shard:

Lambda ném lỗi trên một bản ghi
        ↓
    Cả lô thử lại
        ↓
    Shard không tiến được
    → dữ liệu sau đó ứ lại
        ↓
    Đặt `MaximumRetryAttempts` và DLQ

aws lambda create-event-source-mapping \
  --function-name xu-ly-diem \
  --event-source-arn <arn-luong> \
  --starting-position LATEST \
  --maximum-retry-attempts 3 \
  --bisect-batch-on-function-error \
  --function-response-types ReportBatchItemFailures \
  --destination-config '{"OnFailure": {"Destination": "<arn-sqs-dlq>"}}'

⚠ BisectBatchOnFunctionError khoanh vùng bản ghi độc:

Lô 100 bản ghi lỗi
        ↓
    Chia đôi, thử lại từng nửa
        ↓
    Lặp cho tới khi tìm ra bản ghi
      gây lỗi
    → chỉ nó vào DLQ, phần còn lại
      xử lý được

⚠ Và bảng xếp hạng nên tách khỏi bảng điểm:

DynamoDB không sắp xếp toàn bảng
        ↓
    Bảng xếp hạng cần top N theo điểm
        ↓
    Dùng ElastiCache Redis Sorted Set
    → hoặc GSI với partition key cố
      định (cẩn thận phân vùng nóng)

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

• **D. Gửi vào Kinesis Data Streams và dùng đội EC2 với Auto Scaling xử lý, lưu vào DynamoDB — đây là phương án gần nhất và kiến trúc dữ liệu hoàn toàn đúng, nhưng đội EC2 đòi vá hệ điều hành, quản AMI và tự viết logic checkpoint, trái với yêu cầu giảm thiểu việc quản lý.
• **A. Gửi vào SQS và dùng đội EC2 xử lý, lưu vào RDS MySQL — SQS Standard không giữ thứ tự, và cả EC2 lẫn RDS đều đòi nhiều việc vận hành hơn.
• **B. Gửi vào SNS topic và Lambda xử lý, lưu vào SQL database trên EC2 — SNS không giữ thứ tự và không lưu trữ; CSDL tự cài trên EC2 là việc vận hành lớn nhất.

Ghi nhớ

⚠ Bốn dịch vụ nhận dữ liệu và tính chất thứ tự — bảng phải thuộc: | Dịch vụ | Thứ tự | |---|---| | Kinesis Data Streams | trong mỗi shard | | SQS FIFO | trong mỗi message group | | SQS Standard | KHÔNG bảo đảm | | SNS Standard | KHÔNG bảo đảm |

Từ khoá nhận diện:

"process in order received" → Kinesis hoặc SQS FIFO "handle major traffic spikes" → Kinesis hoặc SQS đệm "minimize management overhead" → Lambda, không phải EC2 "highly available database" → DynamoDB

Ba lưu ý về Kinesis: | Lưu ý | Chi tiết | |---|---| | Thứ tự chỉ trong shard, không toàn cục | | | Partition key quyết định shard | | | Giữ 1-365 ngày, phát lại được | |

⚠ Thứ tự toàn cục cần một shard duy nhất:

Một shard → thứ tự tuyệt đối
        ↓
    Nhưng trần 1 MB/s và 1.000 bản
      ghi/giây
        ↓
    Với game nhiều người chơi
    → không đủ
        ↓
    Thứ tự theo người chơi là đủ

Ba lưu ý về Lambda với Kinesis: | Lưu ý | Chi tiết | |---|---| | Một Lambda cho mỗi shard tại một thời điểm | | | ParallelizationFactor tăng lên tới 10 | | | Lỗi làm kẹt shard nếu không cấu hình | |

⚠ ParallelizationFactor đánh đổi thứ tự lấy thông lượng:

Mặc định 1: một consumer mỗi shard,
  giữ thứ tự
        ↓
    Đặt 10: mười consumer song song
      trên một shard
    → thứ tự chỉ còn trong mỗi
      partition key

Ba lưu ý về DynamoDB cho điểm số: | Lưu ý | Chi tiết | |---|---| | Partition key là mã người chơi | | | ConditionExpression chống ghi lùi | | | On-demand cho tải khó đoán | |

Ba lưu ý về xử lý lặp: | Lưu ý | Chi tiết | |---|---| | Kinesis giao ít nhất một lần | | | Consumer phải chịu được lặp | | | Dùng số thứ tự hoặc dấu thời gian để lọc | |

Ba chỉ số cần theo dõi: | Chỉ số | Ý nghĩa | |---|---| | IteratorAgeMilliseconds | consumer tụt lại bao xa | | WriteProvisionedThroughputExceeded | ghi bị chặn | | DynamoDB ThrottledRequests | CSDL bị chặn |

Ba lưu ý về bảng xếp hạng: | Cách | Đặc điểm | |---|---| | Redis Sorted Set | nhanh nhất, có sẵn logic xếp hạng | | DynamoDB GSI | bền, nhưng dễ phân vùng nóng | | Tính trước theo lô | rẻ nhất, không thời gian thực |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi nhiều cập nhật cho một người chơi, kiểm thứ tự | | | Đo IteratorAge khi có đỉnh | | | Cố ý gửi bản ghi lỗi, xem có kẹt shard không | |

Và một lời khuyên: hãy cấu hình MaximumRetryAttempts và DLQ cho event source mapping ngay từ đầu. Với Kinesis, một bản ghi gây lỗi sẽ chặn toàn bộ shard cho tới khi nó hết hạn giữ — và trong game, điều đó nghĩa là điểm số của cả một nhóm người chơi đứng im mà không ai biết tại sao.

Đáp án

**B và D — Dùng AWS Config rule để kiểm toán thay đổi tài nguyên định kỳ và giám sát mức tuân thủ, kèm custom rule bằng Lambda để tự động đánh giá cấu hình theo bộ kiểm soát cần thiết; và dùng CloudTrail rà soát hoạt động quản trị của mọi tài khoản, bật ở mọi tài khoản và mọi dịch vụ, mã hoá log bằng khoá KMS, giám sát qua CloudWatch Logs.

Vì sao đúng

Đề nêu hai yêu cầu, và hai dịch vụ trả lời hai câu hỏi khác nhau: | Yêu cầu | Dịch vụ | |---|---| | Tài nguyên phải giữ đúng cấu hình | AWS Config | | Kiểm toán định kỳ thay đổi trái phép | CloudTrail + Config |

⚠ Điểm mấu chốt: hai dịch vụ bổ trợ chứ không thay thế nhau:

CloudTrail: AI đã gọi API nào,
  lúc nào, từ đâu
        ↓
    Config: tài nguyên ĐANG cấu hình
      thế nào, có đúng chuẩn không
        ↓
    Thiếu Config: biết ai sửa nhưng
      không biết hiện trạng có đúng
      chuẩn không
        ↓
    Thiếu CloudTrail: biết sai nhưng
      không biết ai làm

⚠ Và đề nói rõ mọi thao tác đều qua CONSOLE — chi tiết quan trọng:

Chỉ dùng AWS Management Console
        ↓
    Không có pipeline hạ tầng dạng mã
        ↓
    Không có chỗ nào để kiểm tra
      trước khi triển khai
        ↓
    Nên phải PHÁT HIỆN sau khi đã
      thay đổi

Bật organization trail:

aws cloudtrail create-trail --name trail-toan-to-chuc \
  --s3-bucket-name kiem-toan-tap-trung \
  --is-organization-trail --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id <arn-khoa-kms> \
  --cloud-watch-logs-log-group-arn <arn-log-group> \
  --cloud-watch-logs-role-arn <arn-role>

⚠ Bốn cờ trong lệnh đó đều là yêu cầu của đề: | Cờ | Đáp ứng yêu cầu nào | |---|---| | is-organization-trail | "mọi tài khoản AWS" | | is-multi-region-trail | "mọi dịch vụ khả dụng" | | kms-key-id | "mã hoá log bằng khoá KMS" | | cloud-watch-logs-log-group-arn | "giám sát qua CloudWatch Logs" |

⚠ Và ghi vào CloudWatch Logs cho phép cảnh báo gần thời gian thực:

aws logs put-metric-filter --log-group-name trail-logs \
  --filter-name thay-doi-trai-phep \
  --filter-pattern '{ ($.eventName = "AuthorizeSecurityGroupIngress")
                   || ($.eventName = "DeleteTrail")
                   || ($.eventName = "PutBucketPolicy") }' \
  --metric-transformations \
    metricName=ThayDoiNhayCam,metricNamespace=KiemToan,metricValue=1

Custom Config rule bằng Lambda:

import boto3, json
config = boto3.client('config')

def xu_ly(event, context):
    muc = json.loads(event['invokingEvent'])['configurationItem']
    tuan_thu = 'COMPLIANT'
    if muc['resourceType'] == 'AWS::EC2::Volume':
        if not muc['configuration'].get('encrypted'):
            tuan_thu = 'NON_COMPLIANT'
    config.put_evaluations(
        Evaluations=[{
            'ComplianceResourceType': muc['resourceType'],
            'ComplianceResourceId': muc['resourceId'],
            'ComplianceType': tuan_thu,
            'OrderingTimestamp': muc['configurationItemCaptureTime']}],
        ResultToken=event['resultToken'])

⚠ Và Custom Policy rule là cách mới không cần Lambda:

rule ma_hoa_ebs {
  configuration.encrypted == true
}

Viết bằng CloudFormation Guard
        ↓
    Không phải quản runtime Lambda
    → không phải vá gì
        ↓
    AWS khuyến nghị cách này cho
      luật đơn giản

⚠ Và vì sao mệnh đề C và A chỉ là ỨNG PHÓ chứ không phải kiểm toán:

A: Systems Manager + Lambda tự hoàn
  tác thay đổi trái phép
        ↓
C: EventBridge + Lambda tự hoàn tác
        ↓
    Cả hai là cơ chế PHẢN ỨNG
        ↓
    Đề hỏi "kiểm toán định kỳ" và
      "giữ đúng cấu hình"
    → cần đánh giá tuân thủ, không
      phải chỉ hoàn tác

⚠ Và tự hoàn tác mọi thay đổi rất nguy hiểm:

Không phân biệt được thay đổi hợp
  lệ với trái phép
        ↓
    Đội vận hành sửa security group
      để xử lý sự cố
        ↓
    Lambda hoàn tác ngay
    → sự cố kéo dài

⚠ Và vì sao mệnh đề E sai — SDK không ghi log:

E nói dùng CloudWatch Logs agent
  gom "log của AWS SDK"
        ↓
    SDK không ghi log ở đâu theo
      mặc định
        ↓
    Và thao tác qua CONSOLE không
      đi qua SDK của bạn
    → bỏ sót đúng thứ đề nói tới

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Biết cả hiện trạng lẫn lịch sử thay đổi | | | Log có chữ ký và mã hoá | | | Luật tuỳ chỉnh theo chuẩn của công ty | |

⚠ Và conformance pack đóng gói nhiều luật thành một:

aws configservice put-organization-conformance-pack \
  --organization-conformance-pack-name pci-dss \
  --template-s3-uri \
    s3://mau/Operational-Best-Practices-for-PCI-DSS.yaml

AWS có sẵn gói cho PCI-DSS, HIPAA,
  NIST, CIS, SOC 2
        ↓
    Hàng chục luật bằng một lệnh
    → phù hợp với công ty dịch vụ
      tài chính

⚠ Và remediation có thể bật ở chế độ thủ công:

aws configservice put-remediation-configurations \
  --remediation-configurations '[{
    "ConfigRuleName": "ma-hoa-ebs",
    "TargetType": "SSM_DOCUMENT",
    "TargetId": "AWSConfigRemediation-EncryptEBSVolume",
    "Automatic": false}]'

`Automatic: false`
        ↓
    Config phát hiện, con người
      quyết định sửa
        ↓
    Tránh được vấn đề tự hoàn tác
      nhầm

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

⚠ Câu này gần như trùng với một câu ở lô trước (mã #10612): cũng công ty ngành nhạy cảm, cũng "liên tục đánh giá, kiểm toán và giám sát cấu hình", và đáp án cũng là CloudTrail + Config rule với cùng cách diễn đạt.

Khác biệt duy nhất: câu kia nói dùng console là phương thức ưa thích, câu này nói console là phương thức duy nhất. Cùng một kiến thức, hai lần kiểm tra.

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

• **C. Dùng EventBridge giám sát mẫu sự kiện và Lambda tự hoàn tác thay đổi trái phép, SNS thông báo — đây là phương án gần nhất và thật sự phản ứng rất nhanh, nhưng đó là cơ chế ứng phó chứ không phải kiểm toán tuân thủ; và tự hoàn tác dễ hoàn tác nhầm thay đổi hợp lệ.
• **A. Dùng Systems Manager để xem và kiểm soát hạ tầng, Lambda tự hoàn tác — Systems Manager quản lý instance chứ không đánh giá tuân thủ cấu hình tài nguyên AWS.
• **E. Dùng CloudWatch Logs agent gom log của AWS SDK — SDK không ghi log mặc định, và thao tác qua console không đi qua SDK của bạn.

Ghi nhớ

⚠ Bốn dịch vụ giám sát và kiểm toán — bảng phải thuộc: | Dịch vụ | Trả lời | |---|---| | CloudTrail | ai làm gì | | AWS Config | cấu hình hiện tại có đúng chuẩn không | | GuardDuty | có hành vi độc hại không | | Security Hub | tổng hợp và chấm điểm tuân thủ |

Từ khoá nhận diện:

"maintain a particular configuration" → AWS Config "audit for unauthorized changes" → CloudTrail + Config "automatically revert changes" → remediation, nhưng cẩn thận "encrypt CloudTrail logs" → KMS key

Ba lưu ý về Config: | Lưu ý | Chi tiết | |---|---| | Bật ở từng Region, từng tài khoản | | | Aggregator gom kết quả về một chỗ | | | Giới hạn loại tài nguyên để kiểm soát chi phí | |

⚠ Chi phí Config dễ bị bất ngờ:

Ghi mọi loại tài nguyên
        ↓
    ENI của Lambda thay đổi liên tục
        ↓
    Sinh rất nhiều configuration item
    → giới hạn danh sách loại tài
      nguyên

Ba loại Config rule: | Loại | Đặc điểm | |---|---| | Managed | AWS viết sẵn, hàng trăm luật | | Custom Lambda | linh hoạt nhất | | Custom Policy (Guard) | DSL khai báo, không cần Lambda |

Ba lưu ý về CloudTrail: | Lưu ý | Chi tiết | |---|---| | Data event phải bật riêng | | | Organization trail gom mọi tài khoản | | | Log file validation phát hiện sửa đổi | |

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

Ba lưu ý về mã hoá log: | Lưu ý | Chi tiết | |---|---| | Chính sách khoá phải cho CloudTrail dùng | | | Người đọc log cần kms:Decrypt | | | Xoay khoá tự động hằng năm | |

Ba lưu ý về Security Hub: | Lưu ý | Chi tiết | |---|---| | Dựa trên Config để chạy chuẩn | | | Gom phát hiện của GuardDuty, Inspector, Macie | | | Chấm điểm tuân thủ theo chuẩn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sửa một tài nguyên qua console, xem Config có bắt | | | Chạy validate-logs kiểm toàn vẹn | | | Kiểm aggregator có đủ mọi tài khoản | |

Và một lời khuyên: hãy để chế độ khắc phục ở Automatic: false cho những thay đổi có thể hợp lệ. Tự động hoàn tác mọi thay đổi nghe rất chặt chẽ cho tới lúc đội vận hành mở một cổng để xử lý sự cố và bị đóng lại sau ba mươi giây — lúc đó cơ chế bảo vệ trở thành nguyên nhân của sự cố tiếp theo.

Đáp án

**A và D — Tạo một VPC Gateway endpoint và dựng file gateway dùng endpoint đó; hoặc tạo một VPC Interface endpoint và dựng file gateway dùng endpoint đó.

Vì sao đúng

Đề yêu cầu file gateway không giao tiếp với dịch vụ AWS qua Internet, và cả hai loại VPC endpoint đều đáp ứng:

File Gateway cần nói chuyện với
  HAI dịch vụ:
    - Storage Gateway (điều khiển)
    - S3 (dữ liệu)
        ↓
    Cả hai đều có endpoint riêng tư

⚠ Và mỗi dịch vụ dùng một loại endpoint khác nhau: | Dịch vụ | Loại endpoint | |---|---| | Amazon S3 | Gateway hoặc Interface | | AWS Storage Gateway | Interface (PrivateLink) |

Gateway cần cả hai
        ↓
    Interface endpoint cho
      `com.amazonaws.<region>.storagegateway`
        ↓
    Gateway hoặc interface endpoint
      cho S3

Tạo gateway endpoint cho S3:

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

Tạo interface endpoint cho Storage Gateway:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.storagegateway \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-1a subnet-1b \
  --security-group-ids sg-endpoint \
  --private-dns-enabled

⚠ Và hai loại endpoint khác nhau căn bản: | Tiêu chí | Gateway | Interface | |---|---|---| | Cơ chế | route trong bảng định tuyến | ENI có IP riêng | | Dịch vụ | chỉ S3 và DynamoDB | hầu hết dịch vụ | | Chi phí | MIỄN PHÍ | theo giờ + GB | | Từ tại chỗ (DX/VPN) | KHÔNG | CÓ |

⚠ Và lựa chọn giữa hai loại tuỳ vào nơi gateway chạy:

File Gateway chạy TRONG VPC
  (trên EC2)
        ↓
    Gateway endpoint cho S3 dùng
      được — và miễn phí
        ↓
    File Gateway chạy TẠI CHỖ
    → gateway endpoint KHÔNG dùng
      được
    → phải interface endpoint

⚠ Đây là lý do cả hai phương án đều đúng:

Đề không nói gateway chạy ở đâu
        ↓
    Cả hai kiến trúc đều hợp lệ
        ↓
    Gateway trong VPC → gateway
      endpoint rẻ hơn
    → Gateway tại chỗ → interface
      endpoint

⚠ Và vì sao phương án C sai — VPC peering không nối tới dịch vụ AWS:

VPC peering nối HAI VPC
        ↓
    S3 không phải một VPC
        ↓
    Nó là dịch vụ có endpoint
    → không peering được

⚠ Và vì sao phương án B sai — Gateway Load Balancer endpoint khác hẳn:

Gateway Load Balancer endpoint
        ↓
    Dùng để chuyển lưu lượng tới
      THIẾT BỊ AN NINH bên thứ ba
        ↓
    Tường lửa ảo, IDS/IPS
    → không liên quan tới việc truy
      cập S3

⚠ Và vì sao phương án E sai — private VIF thuộc Direct Connect:

Private virtual interface là khái
  niệm của Direct Connect
        ↓
    Nó nối trung tâm dữ liệu với VPC
        ↓
    Không phải cơ chế nối gateway
      với S3

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lưu lượng không ra Internet | | | Không cần NAT gateway hay internet gateway | | | Endpoint policy giới hạn được truy cập | |

⚠ Và bỏ NAT gateway là khoản tiết kiệm đáng kể:

Không có endpoint
        ↓
    Gateway trong subnet riêng phải
      qua NAT để tới S3
        ↓
    NAT tính phí giờ + phí xử lý GB
        ↓
    Với lưu lượng tệp lớn, khoản
      này rất lớn
    → gateway endpoint miễn phí
      hoàn toàn

⚠ Và cần cả endpoint cho các dịch vụ phụ trợ:

File Gateway cũng gọi:
    - CloudWatch (chỉ số)
    - CloudWatch Logs (nhật ký)
    - KMS (nếu dùng SSE-KMS)
        ↓
    Muốn hoàn toàn riêng tư
    → tạo interface endpoint cho cả
      những dịch vụ đó

for dv in monitoring logs kms; do
  aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
    --service-name com.amazonaws.ap-southeast-1.$dv \
    --vpc-endpoint-type Interface \
    --subnet-ids subnet-1a subnet-1b \
    --security-group-ids sg-endpoint --private-dns-enabled
done

⚠ Và endpoint policy là lớp kiểm soát thứ hai:

{"Statement": [{
  "Effect": "Allow", "Principal": "*",
  "Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
  "Resource": ["arn:aws:s3:::kho-tep",
               "arn:aws:s3:::kho-tep/*"]}]}

Qua endpoint này chỉ tới được
  bucket đã khai
        ↓
    Chống rò rỉ dữ liệu sang bucket
      cá nhân

⚠ Và bucket policy khoá theo endpoint là chiều ngược lại:

{"Effect": "Deny", "Principal": "*", "Action": "s3:*",
 "Resource": ["arn:aws:s3:::kho-tep",
              "arn:aws:s3:::kho-tep/*"],
 "Condition": {"StringNotEquals": {
   "aws:SourceVpce": "vpce-0abc123"}}}

⚠ Và security group của interface endpoint phải mở cổng 443:

aws ec2 authorize-security-group-ingress \
  --group-id sg-endpoint \
  --protocol tcp --port 443 \
  --source-group sg-file-gateway

Thiếu bước này: gateway không kết
  nối được
        ↓
    Và triệu chứng là gateway ở
      trạng thái không hoạt động
      mà không rõ lý do

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

• **E. Dựng một private virtual interface giữa Storage Gateway và S3 — đây là phương án gần nhất và private VIF thật sự là cơ chế kết nối riêng tư, nhưng nó thuộc Direct Connect và nối trung tâm dữ liệu với VPC, không phải nối gateway với dịch vụ S3.
• **B. Dựng Gateway Load Balancer endpoint — dùng để chuyển lưu lượng tới thiết bị an ninh bên thứ ba, không liên quan tới việc truy cập S3.
• **C. Dựng VPC peering giữa file gateway và S3 — peering nối hai VPC; S3 không phải VPC.

Ghi nhớ

⚠ Bốn loại endpoint trong VPC — bảng phải thuộc: | Loại | Dùng cho | |---|---| | Gateway endpoint | S3, DynamoDB — miễn phí | | Interface endpoint (PrivateLink) | hầu hết dịch vụ AWS và dịch vụ riêng | | Gateway Load Balancer endpoint | thiết bị an ninh bên thứ ba | | Endpoint service | phơi dịch vụ của bạn cho người khác |

Từ khoá nhận diện:

"no Internet communication with AWS services" → VPC endpoint "free endpoint for S3" → gateway endpoint "access from on-premises" → interface endpoint "third-party firewall inspection" → Gateway Load Balancer endpoint

Ba lưu ý về gateway endpoint: | Lưu ý | Chi tiết | |---|---| | Chỉ S3 và DynamoDB | | | Miễn phí hoàn toàn | | | Không dùng được qua peering, TGW, hoặc DX | |

⚠ Điểm cuối là hạn chế quan trọng:

Gateway endpoint dùng prefix list
  trong route table CỦA VPC ĐÓ
        ↓
    VPC khác không dùng chung được
        ↓
    Mỗi VPC phải có endpoint riêng
    → nhưng nó miễn phí nên không sao

Ba lưu ý về interface endpoint: | Lưu ý | Chi tiết | |---|---| | Tạo ENI, tốn IP trong subnet | | | Tính phí theo giờ mỗi AZ và theo GB | | | Private DNS giúp không phải đổi endpoint trong mã | |

Ba lưu ý về Storage Gateway trong VPC: | Lưu ý | Chi tiết | |---|---| | Cần endpoint cho storagegateway và S3 | | | Nên có cả cho CloudWatch và KMS | | | Security group phải mở cổng 443 | |

Ba lưu ý về File Gateway: | Lưu ý | Chi tiết | |---|---| | Phơi NFS hoặc SMB | | | Mỗi tệp là một object S3 đọc được | | | Cache tối thiểu 150 GB | |

Ba lưu ý về bảo mật: | Lớp | Kiểm soát | |---|---| | Endpoint policy | qua endpoint tới được gì | | Bucket policy | bucket nhận từ đâu | | Security group | ai gọi tới endpoint |

Ba lưu ý về chi phí: | Khoản | Ghi chú | |---|---| | Gateway endpoint | miễn phí | | Interface endpoint | ~0,01 USD/giờ mỗi AZ + 0,01 USD/GB | | NAT gateway (nếu không dùng endpoint) | ~0,045 USD/giờ + 0,045 USD/GB |

⚠ Với lưu lượng lớn, endpoint rẻ hơn NAT rõ rệt:

10 TB qua NAT: ~450 USD phí xử lý
        ↓
    10 TB qua interface endpoint:
      ~100 USD
        ↓
    10 TB qua gateway endpoint: 0 USD

Ba lưu ý về chẩn đoán: | Triệu chứng | Nguyên nhân hay gặp | |---|---| | Gateway không kích hoạt được | thiếu endpoint storagegateway | | Tệp không lên S3 | thiếu endpoint S3 hoặc route | | Timeout | security group chưa mở 443 |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig tên endpoint từ trong VPC | | | Kiểm route table có prefix list của S3 | | | Xem VPC Flow Log xác nhận không ra Internet | |

Và một lời khuyên: hãy tạo endpoint cho cả CloudWatch và KMS chứ đừng chỉ tạo cho S3 và Storage Gateway. Gateway vẫn cần đẩy chỉ số và ghi log, và nếu thiếu đường đi riêng cho chúng thì bạn vẫn phải giữ NAT gateway — tức là chưa đạt được điều mà cả cấu hình này hướng tới.

Đáp án

**D — Cấu hình CloudFront gửi một header tuỳ chỉnh, và tạo một quy tắc AWS WAF trên ALB của origin chỉ chấp nhận lưu lượng có chứa header đó.

Vì sao đúng

Đề nêu đúng mối lo và yêu cầu mức bảo vệ MẠNH NHẤT:

Kẻ tấn công tìm ra IP của origin
        ↓
    Gọi thẳng ALB, bỏ qua CloudFront
        ↓
    Mọi lớp bảo vệ ở CloudFront
      (WAF, Shield, cache) vô hiệu

⚠ Điểm mấu chốt: header bí mật là thứ kẻ tấn công không đoán được:

CloudFront thêm header vào MỌI
  yêu cầu tới origin
        ↓
    Header đó chỉ CloudFront biết
        ↓
    WAF trên ALB kiểm header
    → không có → chặn

Cấu hình custom header ở CloudFront:

{"Origins": {"Items": [{
  "Id": "alb-goc",
  "DomainName": "alb-abc.ap-southeast-1.elb.amazonaws.com",
  "CustomOriginConfig": {
    "HTTPPort": 80, "HTTPSPort": 443,
    "OriginProtocolPolicy": "https-only"},
  "CustomHeaders": {"Quantity": 1, "Items": [{
    "HeaderName": "X-Origin-Verify",
    "HeaderValue": "chuoi-bi-mat-rat-dai-va-ngau-nhien"}]}}]}}

Quy tắc WAF trên ALB:

{"Name": "chi-nhan-tu-cloudfront",
 "Priority": 0,
 "Statement": {"NotStatement": {
   "Statement": {"ByteMatchStatement": {
     "FieldToMatch": {"SingleHeader": {"Name": "x-origin-verify"}},
     "PositionalConstraint": "EXACTLY",
     "SearchString": "chuoi-bi-mat-rat-dai-va-ngau-nhien",
     "TextTransformations": [{"Priority": 0, "Type": "NONE"}]}}}},
 "Action": {"Block": {}}}

⚠ Và vì sao phương án B (OAI) không dùng được ở đây:

Origin Access Identity chỉ áp cho
  origin là S3
        ↓
    Đề nói origin là ALB
        ↓
    OAI (và cả OAC) không gắn được
      vào custom origin

⚠ Đây là ranh giới quan trọng phải nhớ: | Loại origin | Cơ chế bảo vệ | |---|---| | S3 | OAC (hoặc OAI cũ) | | ALB, EC2, tại chỗ | custom header + WAF, hoặc prefix list |

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

Signed URL kiểm soát AI xem được
  NỘI DUNG
        ↓
    Nó không ngăn ai gọi thẳng origin
        ↓
    Kẻ tấn công biết IP ALB vẫn gọi
      được
    → sai loại bảo vệ

⚠ Và vì sao phương án A (Lambda@Edge) không phải cách mạnh nhất:

Lambda@Edge chạy ở phía CloudFront
        ↓
    Nó không kiểm soát được ai gọi
      thẳng vào ALB
        ↓
    Muốn xác minh ở ALB thì phải
      có gì đó Ở ALB
    → đó là WAF hoặc listener rule

⚠ Và có một lớp bảo vệ mạnh hơn nữa — prefix list của CloudFront:

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

aws ec2 authorize-security-group-ingress \
  --group-id sg-alb --ip-permissions \
  'IpProtocol=tcp,FromPort=443,ToPort=443,
   PrefixListIds=[{PrefixListId=pl-3b927c52}]'

⚠ Và kết hợp cả hai là cách chặt nhất:

Security group: chỉ nhận từ dải IP
  của CloudFront
        ↓
    WAF: trong dải đó, chỉ nhận yêu
      cầu có header đúng
        ↓
    Kẻ tấn công phải vừa ở trong
      mạng CloudFront vừa biết header
    → gần như không thể

⚠ Vì sao chỉ dùng prefix list là chưa đủ:

Prefix list cho phép MỌI CloudFront
  distribution
        ↓
    Bất kỳ ai cũng tạo được một
      distribution trỏ tới ALB của bạn
        ↓
    Và lưu lượng đó đến từ dải IP
      hợp lệ
    → header bí mật phân biệt
      distribution của bạn

⚠ Và header bí mật phải được xoay định kỳ:

Lộ header = mất lớp bảo vệ
        ↓
    Lưu trong Secrets Manager
        ↓
    Lambda xoay định kỳ:
      - cập nhật CloudFront
      - cập nhật quy tắc WAF
        ↓
    Trong lúc xoay, chấp nhận cả hai
      giá trị

import boto3
wafv2 = boto3.client('wafv2')
cf = boto3.client('cloudfront')

def xoay_header(gia_tri_moi, gia_tri_cu):
    # WAF chấp nhận cả hai trong giai đoạn chuyển
    # rồi cập nhật CloudFront
    # rồi bỏ giá trị cũ khỏi WAF
    pass

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chặn được lưu lượng bỏ qua CloudFront | | | Hoạt động với mọi loại origin | | | Kết hợp được với prefix list | |

⚠ Và ALB listener rule cũng làm được nếu không muốn dùng WAF:

aws elbv2 create-rule --listener-arn <arn> \
  --priority 1 \
  --conditions '[{"Field":"http-header",
    "HttpHeaderConfig":{"HttpHeaderName":"X-Origin-Verify",
      "Values":["chuoi-bi-mat-rat-dai-va-ngau-nhien"]}}]' \
  --actions '[{"Type":"forward","TargetGroupArn":"<arn-tg>"}]'

Kèm một rule mặc định trả 403
        ↓
    Rẻ hơn WAF
    → nhưng không có log chi tiết
      và không có managed rule

⚠ Và cách mạnh nhất về mặt kiến trúc: đặt origin trong subnet riêng:

ALB internal, không có IP công khai
        ↓
    CloudFront tới qua VPC origin
      (tính năng mới)
        ↓
    Không có địa chỉ công khai nào
      để tấn công

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

• **B. Cấu hình Origin Access Identity trên máy chủ origin để chỉ nhận yêu cầu từ CloudFront — đây là phương án gần nhất và OAI/OAC đúng là cơ chế bảo vệ origin của CloudFront, nhưng nó chỉ áp dụng cho origin là S3, còn ở đây origin là Application Load Balancer.
• **C. Dùng signed URL hoặc signed cookie — đó là cơ chế kiểm soát ai xem được nội dung, không ngăn được việc gọi thẳng vào origin.
• **A. Dùng Lambda@Edge xác minh lưu lượng tới ALB có đến từ CloudFront — Lambda@Edge chạy ở phía CloudFront nên không kiểm soát được yêu cầu gọi thẳng vào ALB.

Ghi nhớ

⚠ Bốn cách bảo vệ origin của CloudFront — bảng phải thuộc: | Cách | Áp cho origin | |---|---| | OAC | S3 | | Custom header + WAF | ALB, EC2, tại chỗ | | Prefix list CloudFront trong SG | ALB, EC2 trong AWS | | VPC origin (ALB nội bộ) | ALB không public |

Từ khoá nhận diện:

"protect ALB origin from direct access" → custom header + WAF "protect S3 origin" → OAC "strongest protection" → kết hợp header + prefix list | "control who can view content" → signed URL/cookie

Ba lưu ý về custom header: | Lưu ý | Chi tiết | |---|---| | CloudFront thêm vào mọi yêu cầu tới origin | | | Giá trị phải dài và ngẫu nhiên | | | Xoay định kỳ qua Secrets Manager | |

Ba lưu ý về prefix list: | Lưu ý | Chi tiết | |---|---| | com.amazonaws.global.cloudfront.origin-facing | | | AWS tự cập nhật khi dải IP đổi | | | Tính vào hạn ngạch quy tắc security group | |

⚠ Prefix list chiếm nhiều "chỗ" trong security group:

Một prefix list tính bằng SỐ MỤC
  trong nó
        ↓
    Prefix list CloudFront có
      khoảng 55 mục
        ↓
    Hạn ngạch mặc định 60 quy tắc
    → gần như dùng hết
        ↓
    Xin nâng hạn ngạch nếu cần

Ba lưu ý về VPC origin: | Lưu ý | Chi tiết | |---|---| | Tính năng mới của CloudFront | | | ALB nội bộ, không có IP công khai | | | Loại bỏ hẳn bề mặt tấn công trực tiếp | |

Ba lưu ý về Shield Advanced: | Lưu ý | Chi tiết | |---|---| | Bảo vệ CloudFront, ALB, NLB, Route 53 | | | Có đội ứng cứu (SRT) | | | Bảo vệ chi phí khi bị tấn công | |

Ba lưu ý về WAF trên ALB: | Lưu ý | Chi tiết | |---|---| | Scope REGIONAL | | | Đặt quy tắc kiểm header ở priority thấp nhất | | | Bật log để phân tích lưu lượng bị chặn | |

Ba lưu ý về xoay bí mật: | Bước | Chi tiết | |---|---| | Thêm giá trị mới vào WAF (chấp nhận cả hai) | | | Cập nhật CloudFront sang giá trị mới | | | Bỏ giá trị cũ khỏi WAF | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | curl thẳng vào DNS của ALB — phải 403 | | | curl qua CloudFront — phải 200 | | | Xem log WAF đếm số yêu cầu bị chặn | |

Và một lời khuyên: hãy kết hợp header bí mật với prefix list của CloudFront trong security group. Chỉ dùng prefix list thì bất kỳ ai cũng tạo được một CloudFront distribution trỏ vào origin của bạn và lưu lượng đó vẫn đến từ dải IP hợp lệ — header bí mật mới là thứ phân biệt distribution của bạn với của họ.