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

Đáp án

**D — Dựng chuyển đổi DNS kiểu active-active bằng định tuyến theo độ trễ phân giải tới ELB, và đặt thuộc tính Evaluate Target Health là Yes.

Vì sao đúng

Đề nêu hai yêu cầu, và phương án này khớp cả hai: | Yêu cầu | Cách đáp ứng | |---|---| | Giữ trang sống khi mất một Region | cả hai Region cùng phục vụ, mất một cái thì còn cái kia | | Thời gian phục hồi ngắn | không phải dựng gì, chỉ ngừng gửi lưu lượng tới Region hỏng |

⚠ Evaluate Target Health = Yes là phần quan trọng nhất:

Đặt `No`: Route 53 vẫn trả về
  bản ghi trỏ tới ELB đã chết
        ↓
    Người dùng đi tới Region hỏng
    → không có chuyển đổi nào cả
        ↓
    Đặt `Yes`: Route 53 hỏi chính ELB
      xem còn target khoẻ không
    → hết target khoẻ thì ngừng trả
      bản ghi đó

Đây là lý do phương án A sai — nó đặt No.

Tạo bản ghi alias theo độ trễ:

aws route53 change-resource-record-sets --hosted-zone-id <id> \
  --change-batch '{"Changes":[{"Action":"CREATE",
    "ResourceRecordSet":{
      "Name":"app.congty.com","Type":"A",
      "SetIdentifier":"ap-southeast-1",
      "Region":"ap-southeast-1",
      "AliasTarget":{
        "HostedZoneId":"<zone-alb-sg>",
        "DNSName":"<dns-alb-sg>",
        "EvaluateTargetHealth":true}}}]}'

⚠ Với bản ghi alias trỏ tới ELB, EvaluateTargetHealth thay cả health check riêng:

Route 53 tự hỏi ELB
    → ELB còn target khoẻ không
        ↓
    Không cần tạo health check riêng
    → và không tính phí health check

⚠ Active-active so với active-passive — đây là điểm phân biệt: | Kiểu | Hành vi | |---|---| | Latency routing | CẢ HAI Region phục vụ, mỗi người đi tới Region nhanh nhất | | Failover routing | chỉ Region chính phục vụ; phụ chờ sẵn |

Đề nói ứng dụng đã chạy ở NHIỀU
  Region
        ↓
    Cả hai đang phục vụ
    → active-active
    → latency routing tận dụng
      cả hai và giảm độ trễ

⚠ Và ElastiCache với AOF không cứu được sự cố mất Region:

AOF (Append Only File) ghi lệnh
  ra tệp trên node
        ↓
    Node khởi động lại: đọc lại AOF
      để phục hồi dữ liệu
        ↓
    Nhưng mất cả Region
    → node biến mất, AOF biến mất
    → AOF chỉ chống mất dữ liệu
      khi node restart

⚠ Bảo vệ đúng cho ElastiCache đa Region:

Redis Global Datastore
    → nhân bản xuyên Region
    → độ trễ thường dưới một giây
        ↓
    Đây mới là thứ giữ cache sống
      khi mất một Region

aws elasticache create-global-replication-group \
  --global-replication-group-id-suffix cache-toan-cau \
  --primary-replication-group-id cum-chinh

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cả hai Region cùng phục vụ, không lãng phí | | | Người dùng đi tới Region gần nhất | | | Mất một Region: chuyển tự động | |

⚠ Nhưng thời gian chuyển đổi vẫn phụ thuộc TTL:

Health check phát hiện: vài chục giây
    + TTL của bản ghi DNS
        ↓
    Client và resolver trung gian
      vẫn còn cache
    → đặt TTL 60 giây cho bản ghi
      đa Region

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

• **A. Bật DNSSEC, cấu hình Route 53 chuyển đổi tự động sang nhóm tài nguyên dự phòng, và đặt Evaluate Target Health là No — đây là phương án gần nhất và có nhắc tới chuyển đổi tự động, nhưng DNSSEC chống giả mạo bản ghi DNS chứ không liên quan tới sẵn sàng cao; và đặt No nghĩa là Route 53 vẫn trả bản ghi của Region đã chết.
• **B. Dựng Transit VPC định tuyến lưu lượng nhiều VPC qua VPN xuyên Region — đây là thành phần mạng nội bộ; nó không quyết định người dùng Internet đi tới Region nào.
• **C. Gộp mọi VPC ở nhiều Region vào một Private Hosted Zone — private hosted zone phân giải tên bên trong VPC; nó không phục vụ người dùng công khai.

Ghi nhớ

⚠ Bảy kiểu định tuyến của Route 53 — bảng phải thuộc: | Kiểu | Dùng khi | |---|---| | Simple | một đích duy nhất | | Weighted | chia tỷ lệ, thử nghiệm A/B | | Latency | active-active, chọn Region nhanh nhất | | Failover | active-passive, chính/phụ | | Geolocation | theo quốc gia người dùng | | Geoproximity | theo khoảng cách, có bias | | Multivalue answer | nhiều IP kèm health check |

Từ khoá nhận diện:

"both Regions serve traffic" → latency routing "passive standby Region" → failover routing "survive Region outage, short downtime" → active-active + health check "prevent DNS spoofing" → DNSSEC

⚠ EvaluateTargetHealth — phải hiểu rõ: | Giá trị | Hành vi | |---|---| | true | Route 53 kiểm sức khoẻ của chính đích alias | | false | luôn trả bản ghi, bất kể đích sống hay chết |

Với alias tới ELB: `true` nghĩa là
  hỏi ELB xem còn target khoẻ không
        ↓
    Với alias tới S3 website: luôn
      coi là khoẻ, không kiểm được

Ba lưu ý về health check của Route 53: | Lưu ý | Chi tiết | |---|---| | Kiểm tra từ nhiều nơi trên thế giới | | | Đích phải có IP công khai | | | Calculated health check gộp nhiều điều kiện | |

⚠ Health check không tới được IP riêng tư:

Instance trong subnet riêng
    → Route 53 không kiểm được
        ↓
    Dùng CloudWatch alarm làm nguồn
      cho health check
    → hoặc dựa vào health check của ELB

Ba lưu ý về TTL: | Lưu ý | Chi tiết | |---|---| | TTL ngắn: chuyển nhanh, nhiều truy vấn | | | 60 giây là mức cân bằng phổ biến | | | Client vẫn có thể cache lâu hơn TTL | |

Ba lưu ý về nhân bản dữ liệu đa Region: | Dịch vụ | Cách | |---|---| | DynamoDB | global table, ghi ở mọi Region | | Aurora | Global Database, một writer | | ElastiCache Redis | Global Datastore | | S3 | Cross-Region Replication |

⚠ Chuyển đổi DNS vô nghĩa nếu dữ liệu không sẵn:

Route 53 chuyển sang Region còn lại
    → ứng dụng ở đó gọi CSDL...
      ở Region đã sập
        ↓
    Phải nhân bản dữ liệu TRƯỚC

Ba lưu ý về Global Accelerator: | Lưu ý | Chi tiết | |---|---| | IP tĩnh anycast, không phụ thuộc DNS | | | Chuyển đổi trong khoảng 30 giây | | | Hỗ trợ cả TCP và UDP | |

⚠ Global Accelerator nhanh hơn Route 53:

Route 53: phụ thuộc TTL và cache
  của client
        ↓
    Global Accelerator: chuyển đích
      ở tầng mạng
    → client không biết gì cả

Ba lưu ý về ElastiCache: | Lưu ý | Chi tiết | |---|---| | AOF chỉ phục hồi khi node restart | | | Multi-AZ với replica chống hỏng AZ | | | Global Datastore chống mất Region | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tắt ELB ở một Region, xem DNS có ngừng trả | | | Đo thời gian chuyển đổi thật | | | dig từ nhiều nơi xem trả về Region nào | |

Và một lời khuyên: hãy kiểm tra EvaluateTargetHealth trên mọi bản ghi alias đa Region. Đặt sai một giá trị boolean là biến một kiến trúc đa Region tốn kém thành một cấu hình vẫn gửi người dùng thẳng vào Region đã chết — và không có cảnh báo nào cho bạn biết điều đó.

Đáp án

**C — Thêm một tầng lưu trữ trong bộ nhớ bằng Amazon ElastiCache for Redis để giảm tải cho CSDL; bật nhân bản Redis để co giãn tải đọc và có cụm sẵn sàng cao.

Vì sao đúng

Đề nêu hai ràng buộc, và phương án này thoả cả hai: | Ràng buộc | Cách đáp ứng | |---|---| | Nhanh và rẻ | thêm một tầng cache, không đổi kiến trúc | | Giảm độ trễ cho người đọc | truy vấn lặp lại trả từ bộ nhớ |

⚠ Nút thắt nằm ở CSDL tại chỗ — đây là điểm mấu chốt:

Máy chủ web trên AWS
    → CSDL còn ở trung tâm dữ liệu
        ↓
    Mỗi truy vấn đi qua Internet
      hoặc VPN
    → độ trễ hàng chục tới hàng
      trăm mili giây
        ↓
    Trang cần nhiều truy vấn
    → cộng dồn thành thời gian tải chậm

⚠ Cache cắt phần lớn số lần đi vòng đó:

Bài viết được đọc hàng nghìn lần
    → cùng một truy vấn lặp lại
        ↓
    Lần đầu: đi tới CSDL tại chỗ
    → những lần sau: lấy từ Redis
      trong VPC
    → độ trễ micro giây

Cache truy vấn:

import redis, json
cache = redis.Redis(host=diem_cuoi, port=6379, ssl=True)

def lay_bai_viet(ma_bai):
    khoa = f'bai-viet:{ma_bai}'
    da_co = cache.get(khoa)
    if da_co:
        return json.loads(da_co)
    du_lieu = truy_van_csdl_tai_cho(ma_bai)
    cache.setex(khoa, 300, json.dumps(du_lieu))
    return du_lieu

⚠ Luôn đặt TTL — thiếu nó là cache đầy bộ nhớ:

Khoá không có hạn
    → tích tụ mãi
        ↓
    Cache đầy, chính sách thu hồi
      xoá cả khoá đang dùng
    → hiệu quả giảm dần không rõ lý do

⚠ Và nhân bản Redis cho hai thứ cùng lúc:

Replica phục vụ đọc
    → chia tải truy vấn cache
        ↓
    Multi-AZ với tự động chuyển đổi
    → node chính chết thì replica
      thăng cấp
        ↓
    Đề nói rõ "co giãn đọc và có
      cụm sẵn sàng cao"

aws elasticache create-replication-group \
  --replication-group-id cum-bai-viet \
  --replication-group-description "Cache bai viet" \
  --engine redis --cache-node-type cache.r7g.large \
  --num-cache-clusters 3 \
  --automatic-failover-enabled \
  --multi-az-enabled \
  --transit-encryption-enabled \
  --at-rest-encryption-enabled

⚠ Vì sao chuyển CSDL sang Aurora (phương án A) không phải "nhanh và rẻ":

Di chuyển CSDL là dự án lớn
    → chuyển schema, kiểm thử,
      lên kế hoạch cắt chuyển
        ↓
    Đề nói "nhanh chóng và tiết kiệm
      chi phí sửa hạ tầng hiện có"
    → cache thêm vào là việc vài ngày

⚠ Và CloudFront (phương án B) không giải quyết đúng vấn đề:

CloudFront cache nội dung tĩnh
    → trang tin có bình luận, có nội
      dung động
        ↓
    Chuyển toàn bộ sang S3 tĩnh
    → mất chức năng bình luận
    → không phải "sửa nhỏ"

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Triển khai trong vài ngày | | | Giảm mạnh số lần đi tới CSDL tại chỗ | | | Replica cho cả co giãn đọc lẫn chuyển đổi | |

⚠ Và cache còn giúp khi đường truyền tới CSDL gặp sự cố:

VPN hoặc Internet chập chờn
    → yêu cầu trúng cache vẫn
      phục vụ được
        ↓
    Sự cố mạng không thành gián đoạn
      thấy được ngay lập tức

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

• **A. Chuyển CSDL tại chỗ sang Aurora bằng DMS và SCT, tạo Aurora Replica xuyên AZ — đây là phương án gần nhất và là hướng đi đúng về lâu dài, nhưng di chuyển CSDL là dự án nhiều tuần với rủi ro cắt chuyển; đề hỏi cách nhanh chóng cải thiện.
• **B. Tạo CloudFront và chuyển toàn bộ trang sang S3 static hosting — trang có bình luận nên cần logic động; chuyển sang tĩnh là mất chức năng.
• **D. Thay CSDL bằng OpenSearch với ELK stack — OpenSearch là công cụ tìm kiếm và phân tích, không phải CSDL giao dịch; thay thế như vậy là viết lại toàn bộ ứng dụng.

Ghi nhớ

⚠ Ba nguồn độ trễ và cách xử lý — bảng phải thuộc: | Nguồn | Cách giảm | |---|---| | Khoảng cách tới người dùng | CloudFront | | Truy vấn CSDL lặp lại | cache trong bộ nhớ | | Đường truyền tới CSDL tại chỗ | cache, hoặc chuyển CSDL lên cloud |

Từ khoá nhận diện:

"quickly and cost-effectively reduce latency" → thêm cache "database is on-premises, app on AWS" → cache hoặc di chuyển CSDL "global readers, static content" → CloudFront "full-text search" → OpenSearch

⚠ Redis và Memcached — bảng phải thuộc: | Tiêu chí | Redis | Memcached | |---|---|---| | Kiểu dữ liệu | phong phú | chỉ chuỗi | | Bền vững | có (AOF, RDB) | không | | Replica và chuyển đổi | CÓ | không | | Global Datastore | có | không |

Đề nói "nhân bản để co giãn đọc
  và có cụm sẵn sàng cao"
        ↓
    Chỉ Redis làm được

Ba mẫu cache: | Mẫu | Cách | |---|---| | Cache-aside | ứng dụng đọc cache, trượt thì đọc CSDL | | Write-through | ghi cả CSDL lẫn cache | | TTL | để dữ liệu tự hết hạn |

⚠ Cache-aside có bẫy "cache stampede":

Khoá phổ biến hết hạn cùng lúc
    → hàng nghìn yêu cầu cùng trượt
    → tất cả cùng gọi CSDL tại chỗ
        ↓
    Đường truyền nghẹt
    → dùng TTL lệch nhau chút ít
      hoặc khoá phân tán

Ba lưu ý về ElastiCache: | Lưu ý | Chi tiết | |---|---| | Luôn đặt TTL cho mọi khoá | | | Bật mã hoá khi truyền và khi lưu | | | Serverless nếu tải khó đoán | |

Ba lưu ý về chỉ số cần theo dõi: | Chỉ số | Ý nghĩa | |---|---| | CacheHitRate | cache có được dùng không | | Evictions | cache đầy, đang xoá khoá | | CurrConnections | số kết nối tới cache |

⚠ Evictions tăng là dấu hiệu cache quá nhỏ:

Cache đầy bộ nhớ
    → xoá khoá theo chính sách LRU
        ↓
    Tỷ lệ trúng giảm dần
    → tăng cỡ node hoặc rà lại TTL

Ba lưu ý về nội dung tĩnh: | Lưu ý | Chi tiết | |---|---| | CloudFront cho ảnh, CSS, JavaScript | | | Bổ sung cho cache CSDL, không thay thế | | | Hai tầng cache giải quyết hai vấn đề khác nhau | |

Ba lưu ý về Spot instance trong đề: | Lưu ý | Chi tiết | |---|---| | Spot bị thu hồi bất kỳ lúc nào | | | Với trang tin sản xuất là quyết định đáng ngờ | | | Cache ngoài instance nên thu hồi không mất gì | |

Ba lưu ý về bước tiếp theo: | Bước | Chi tiết | |---|---| | Cache ngay bây giờ | giải quyết vấn đề trước mắt | | CloudFront cho nội dung tĩnh | bước kế | | Di chuyển CSDL lên cloud | khi có thời gian |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo thời gian tải trang trước và sau | | | Theo dõi tỷ lệ trúng cache | | | Đếm số truy vấn tới CSDL tại chỗ | |

Và một lời khuyên: hãy thêm cache trước khi nghĩ tới việc di chuyển CSDL. Cache giải quyết được phần lớn vấn đề trong vài ngày và có thể gỡ ra bất cứ lúc nào — còn di chuyển CSDL là quyết định một chiều mà bạn muốn đưa ra khi có thời gian chuẩn bị, chứ không phải khi đang bị áp lực về hiệu năng.

Đáp án

**D — Lập snapshot copy grant cho một khoá chủ ở Region đích, rồi bật cross-region snapshot copy trên cụm Redshift để sao chép ảnh chụp sang Region đó.

Vì sao đúng

Đề có một dữ kiện quyết định, và nó là điểm phân biệt duy nhất giữa đáp án và phương án gần nhất:

"Mã hoá CSDL được bật trên cụm
  bằng AWS KMS"
        ↓
    Khoá KMS chỉ tồn tại trong
      MỘT Region
        ↓
    Ảnh chụp mã hoá không tự sang
      Region khác được
    → cần snapshot copy grant

⚠ Snapshot copy grant giải quyết đúng vấn đề đó:

Redshift ở Region nguồn không thể
  dùng khoá KMS ở Region đích
        ↓
    Grant cho phép Redshift mã hoá
      lại ảnh chụp bằng khoá của
      Region đích
        ↓
    Không có grant: bật copy sẽ
      THẤT BẠI với cụm mã hoá

Tạo grant ở Region đích:

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

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

aws redshift enable-snapshot-copy \
  --cluster-identifier cum-phan-tich \
  --destination-region us-west-2 \
  --retention-period 30 \
  --snapshot-copy-grant-name grant-dr

⚠ Với cụm KHÔNG mã hoá thì phương án C đủ:

Cụm không mã hoá
    → `enable-snapshot-copy` là xong
        ↓
    Nhưng đề nói RÕ là có mã hoá
    → phải thêm grant

Đây là lý do phương án C thiếu một bước.

⚠ Và Redshift tự sao chép — không cần Lambda tự viết:

Bật một lần
    → Redshift tự sao mọi ảnh chụp
      tự động sang Region đích
        ↓
    Tự viết Lambda gọi `copy-cluster-snapshot`
    → làm lại thứ đã có sẵn
    → và phải tự lo lịch, lỗi, dọn dẹp

Đây là lý do phương án B tốn công hơn.

⚠ Yêu cầu khoảng cách 800 km là dấu hiệu bắt buộc dùng Region khác:

Các AZ trong một Region cách nhau
  vài chục km
        ↓
    Không đạt yêu cầu 500 dặm
    → chỉ Region khác mới đủ xa
        ↓
    Đây là yêu cầu tuân thủ phổ biến
      trong ngành viễn thông và tài chính

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

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

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Redshift tự sao chép, không phải viết mã | | | Ảnh chụp giữ nguyên mã hoá ở Region đích | | | Không phải chạy cụm dự phòng thường trực | |

⚠ Nhưng phải hiểu đây là chiến lược Backup & Restore:

Không có cụm nào chạy ở Region đích
    → khi sự cố: khôi phục từ ảnh chụp
        ↓
    Cụm lớn mất hàng giờ để khôi phục
    → RTO tính bằng giờ
        ↓
    Cần RTO ngắn hơn: phải giữ
      một cụm chạy sẵn

⚠ Và tần suất ảnh chụp quyết định RPO:

aws redshift modify-cluster \
  --cluster-identifier cum-phan-tich \
  --automated-snapshot-retention-period 7

Redshift chụp tự động mỗi 8 giờ
  hoặc mỗi 5 GB thay đổi
        ↓
    Cộng thời gian sao chép sang
      Region đích
    → RPO thực tế vài giờ

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

• **C. Bật cross-region snapshot copy trên cụm Redshift để sao ảnh chụp sang Region khác — đây là phương án gần nhất và là đúng cơ chế, nhưng với cụm đã mã hoá bằng KMS thì thiếu snapshot copy grant, và thao tác bật sẽ thất bại.
• **B. Viết Lambda theo lịch chụp ảnh và sao chép sang Region khác — làm lại bằng tay thứ Redshift đã có sẵn, thêm mã phải bảo trì và thêm chỗ hỏng.
• **A. Dùng CloudFormation dựng cụm ở Region khác và sao lưu vào S3 có CRR — Redshift không sao lưu vào bucket S3 của bạn theo cách đó; ảnh chụp là tài nguyên do Redshift quản lý.

Ghi nhớ

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

Từ khoá nhận diện:

"encrypted cluster, cross-region snapshot" → snapshot copy grant "recovery site far from primary" → Region khác, không phải AZ khác "automatic replication of snapshots" → enable-snapshot-copy "RTO in minutes for Redshift" → cụm chạy sẵn, không phải khôi phục |

Ba lưu ý về snapshot copy grant: | Lưu ý | Chi tiết | |---|---| | Tạo ở REGION ĐÍCH | | | Trỏ tới khoá KMS của Region đích | | | Chỉ cần cho cụm đã mã hoá | |

⚠ Đây là lỗi hay gặp khi thiết lập DR cho Redshift:

Tạo grant ở Region nguồn
    → lệnh thất bại hoặc grant
      không dùng được
        ↓
    Grant phải nằm ở nơi chứa
      khoá sẽ mã hoá bản sao

Ba lưu ý về mã hoá Redshift: | Lưu ý | Chi tiết | |---|---| | Bật mã hoá phải làm lúc tạo cụm hoặc qua resize | | | KMS hoặc HSM | | | Ảnh chụp kế thừa mã hoá của cụm | |

Ba lưu ý về khôi phục: | Lưu ý | Chi tiết | |---|---| | Khôi phục tạo cụm MỚI, không ghi đè | | | Endpoint đổi, phải cập nhật ứng dụng | | | Cụm lớn mất hàng giờ | |

⚠ Thời gian khôi phục là con số phải đo:

Cụm vài TB: hàng giờ
    → RTO của kế hoạch DR phải
      tính con số này
        ↓
    Không đo trước
    → con số trong tài liệu chỉ là
      hy vọng

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Ảnh chụp ở Region đích tính phí lưu trữ | | | Có phí truyền dữ liệu xuyên Region | | | Đặt thời gian giữ hợp lý | |

Ba lưu ý về Redshift Serverless: | Lưu ý | Chi tiết | |---|---| | Không quản cụm, trả theo RPU dùng | | | Cũng sao chép ảnh chụp xuyên Region được | | | Hợp với tải phân tích không đều | |

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

⚠ Redshift không có "cụm dự phòng tự chuyển đổi":

Khác với RDS Multi-AZ
    → Redshift không có chuyển đổi
      tự động xuyên Region
        ↓
    Phải khôi phục và đổi endpoint
      bằng tay hoặc bằng script

Ba lưu ý về Multi-AZ của Redshift: | Lưu ý | Chi tiết | |---|---| | RA3 hỗ trợ triển khai Multi-AZ | | | Chống hỏng AZ, không chống mất Region | | | Bổ sung cho sao chép xuyên Region | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm ảnh chụp đã xuất hiện ở Region đích | | | Khôi phục thử và bấm giờ | | | Chạy vài truy vấn trên cụm đã khôi phục | |

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

Đáp án

**A, C và E — Cải thiện hiệu năng mạng của từng node bằng EC2 có Elastic Fabric Adapter (EFA); cải thiện hiệu năng lưu trữ bằng Amazon FSx for Lustre thay cho EFS; và đặt mọi node gần nhau trong MỘT vùng sẵn sàng, dùng cluster placement group.

Vì sao đúng

Đề mô tả một cụm HPC với node tính toán và lưu trữ gắn chặt với nhau, và ba đáp án lo ba nút thắt khác nhau: | Nút thắt | Giải pháp | |---|---| | Mạng giữa các node | EFA | | Thông lượng lưu trữ dùng chung | FSx for Lustre | | Độ trễ vật lý giữa các node | cluster placement group |

⚠ EFS không đủ cho HPC quy mô 1.000 node:

EFS: hệ thống tệp NFS đa mục đích
    → thông lượng theo chế độ elastic
      hoặc provisioned
        ↓
    Lustre: hệ thống tệp SONG SONG
      chuyên cho HPC
    → hàng trăm GB/giây
    → độ trễ dưới một mili giây

Tạo hệ thống tệp Lustre:

aws fsx create-file-system --file-system-type LUSTRE \
  --storage-capacity 48000 --storage-type SSD \
  --subnet-ids subnet-abc \
  --lustre-configuration '{
    "DeploymentType":"PERSISTENT_2",
    "PerUnitStorageThroughput":1000,
    "DataCompressionType":"LZ4"}'

⚠ PerUnitStorageThroughput quyết định thông lượng:

Thông lượng = dung lượng (TiB)
              × giá trị này (MB/s mỗi TiB)
        ↓
    48 TiB × 1000 = 48 GB/giây
    → tăng dung lượng hoặc tăng
      hệ số để có thêm thông lượng

⚠ Và EFA khác hẳn card mạng thường:

Card mạng thường (ENA): đi qua
  ngăn xếp TCP/IP của hệ điều hành
        ↓
    EFA: OS bypass — ứng dụng nói
      thẳng với phần cứng mạng
    → độ trễ thấp hơn nhiều
    → và ổn định hơn ở quy mô lớn

Gắn EFA vào launch template:

aws ec2 create-launch-template --launch-template-name mau-hpc \
  --launch-template-data '{
    "InstanceType":"hpc7a.96xlarge",
    "NetworkInterfaces":[{
      "DeviceIndex":0,
      "InterfaceType":"efa",
      "Groups":["sg-hpc"]}],
    "Placement":{"GroupName":"nhom-cum-hpc"}}'

⚠ Security group của EFA phải cho phép MỌI lưu lượng với CHÍNH NÓ:

aws ec2 authorize-security-group-ingress \
  --group-id sg-hpc --protocol -1 --source-group sg-hpc
aws ec2 authorize-security-group-egress \
  --group-id sg-hpc --protocol -1 --source-group sg-hpc

EFA dùng giao thức riêng, không phải
  TCP hay UDP
        ↓
    Không mở toàn bộ với chính nhóm
    → EFA không hoạt động
    → và lỗi rất khó lần

⚠ Cluster placement group đặt các node trên cùng một rack: | Loại placement group | Mục đích | |---|---| | Cluster | GẦN NHAU — độ trễ thấp, băng thông cao | | Spread | TÁCH RA — mỗi instance một phần cứng | | Partition | nhóm theo phân vùng — cho HDFS, Cassandra |

HPC gắn chặt cần độ trễ thấp nhất
    → cluster placement group
        ↓
    Và nó chỉ hoạt động TRONG MỘT AZ
    → đây là lý do phương án D sai

⚠ Trải nhiều AZ là điều SAI với HPC gắn chặt:

Node ở hai AZ khác nhau
    → độ trễ giữa chúng cao gấp
      nhiều lần
        ↓
    Với tính toán đồng bộ hoá liên tục
    → node chậm nhất quyết định
      tốc độ cả cụm
        ↓
    Đánh đổi độ trễ lấy chịu lỗi
      là ngược với mục tiêu HPC

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mạng, lưu trữ và vị trí đều được tối ưu | | | Lustre liên kết được với S3 để nạp dữ liệu | | | EFA cho MPI hiệu năng gần như trên phần cứng thật | |

⚠ Và Lustre liên kết S3 là tính năng rất hợp với HPC:

{"DataRepositoryConfiguration": {
  "ImportPath": "s3://du-lieu-mo-phong/",
  "ExportPath": "s3://du-lieu-mo-phong/ket-qua/"}}

Dữ liệu gốc nằm trên S3 (rẻ)
    → Lustre nạp lười khi cần
    → xuất kết quả về S3
        ↓
    Xoá hệ thống tệp khi xong việc

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

• **D. Trải instance sang nhiều vùng sẵn sàng để tăng hiệu năng và khả năng mở rộng, dùng EBS RAID 0 — đây là phương án gần nhất và nhắc tới cả tính toán lẫn lưu trữ, nhưng trải nhiều AZ tăng độ trễ giữa các node, ngược hẳn với nhu cầu của HPC gắn chặt; và EBS không phải hệ thống tệp dùng chung.
• **B. Dùng EBS Throughput Optimized với RAID 0 thay EFS — EBS gắn vào một instance; 1.000 node không dùng chung được. Và RAID 0 không có dự phòng nào.
• **F. Gắn nhiều network interface vào mỗi instance để tăng băng thông — băng thông của instance là giới hạn ở mức instance, không phải ở mức card mạng; thêm ENI không tăng tổng băng thông.

Ghi nhớ

⚠ Ba loại placement group — bảng phải thuộc: | Loại | Đặt ở đâu | Dùng cho | |---|---|---| | Cluster | cùng rack, MỘT AZ | HPC, độ trễ thấp | | Spread | phần cứng riêng biệt | ứng dụng quan trọng, ít instance | | Partition | nhóm phân vùng riêng | HDFS, Cassandra, Kafka |

Từ khoá nhận diện:

"tightly coupled HPC" → cluster placement group + EFA "parallel file system, high throughput" → FSx for Lustre "MPI workload" → EFA "maximum fault isolation" → spread placement group

⚠ Bốn hệ thống tệp — chọn theo tải: | Dịch vụ | Hợp với | |---|---| | FSx for Lustre | HPC, thông lượng rất cao | | EFS | NFS chung, nhiều AZ, tải vừa | | FSx for Windows | SMB, Windows ACL | | FSx for NetApp ONTAP | NFS và SMB, tính năng doanh nghiệp |

Ba lưu ý về EFA: | Lưu ý | Chi tiết | |---|---| | Chỉ hỗ trợ một số loại instance | | | Cần cài Libfabric và EFA driver | | | Security group phải mở toàn bộ với chính nó | |

⚠ EFA chỉ tăng tốc lưu lượng dùng Libfabric:

Lưu lượng TCP/IP thường vẫn đi
  qua ngăn xếp bình thường
        ↓
    Chỉ ứng dụng MPI hoặc NCCL
      dùng được đường OS bypass
    → cài đúng thư viện mới có lợi ích

Ba lưu ý về cluster placement group: | Lưu ý | Chi tiết | |---|---| | Chỉ trong một AZ | | | Khởi chạy hết instance cùng lúc để chắc đủ chỗ | | | Dùng cùng loại instance | |

⚠ Khởi chạy dần dần dễ bị InsufficientCapacity:

Khởi chạy 100 máy hôm nay
    → thêm 900 máy tuần sau
        ↓
    Rack đó có thể không còn chỗ
    → xin cả 1.000 trong một lời gọi

Ba lưu ý về FSx for Lustre: | Lưu ý | Chi tiết | |---|---| | Scratch: rẻ hơn, không nhân bản | | | Persistent: có nhân bản và tự sửa | | | Liên kết S3 để nạp và xuất dữ liệu | |

Ba lưu ý về instance cho HPC: | Họ | Đặc điểm | |---|---| | Hpc7a, Hpc7g | thiết kế riêng cho HPC | | C7g, C6i | tính toán mạnh | | P5, Trn1 | học máy, GPU |

Ba lưu ý về AWS ParallelCluster: | Lưu ý | Chi tiết | |---|---| | Dựng cụm HPC bằng một tệp cấu hình | | | Tích hợp Slurm, EFA, Lustre | | | Tự co giãn theo hàng đợi job | |

⚠ ParallelCluster làm sẵn mọi thứ trong câu này:

HeadNode:
  InstanceType: c6i.xlarge
Scheduling:
  Scheduler: slurm
  SlurmQueues:
    - Name: tinh-toan
      Networking:
        PlacementGroup: {Enabled: true}
      ComputeResources:
        - Name: node
          InstanceType: hpc7a.96xlarge
          Efa: {Enabled: true}
SharedStorage:
  - Name: luu-tru
    StorageType: FsxLustre

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chạy fi_info -p efa xem EFA có nhận không | | | Đo độ trễ giữa các node bằng benchmark MPI | | | Đo thông lượng Lustre bằng fio hoặc IOR | |

Và một lời khuyên: hãy đo độ trễ giữa các node trước và sau khi dùng cluster placement group. Với tính toán gắn chặt, node chậm nhất quyết định tốc độ của cả cụm — và vài chục micro giây chênh lệch giữa hai rack có thể là toàn bộ khác biệt giữa 200 node chạy tốt và 1.000 node chạy tệ hơn.

Đáp án

**C và E — Viết hàm Lambda tạo quy tắc duyệt tự động, lưu danh sách AMI đã duyệt trong SSM Parameter Store, và đặt quy tắc cron 30 ngày trên EventBridge kích hoạt một tài liệu SSM Automation chạy trên mọi EC2; đồng thời tạo assessment template trên Amazon Inspector nhắm vào các instance và chạy quét CVE chi tiết trên những instance khởi chạy từ AMI cần kiểm tra.

Vì sao đúng

Đề nêu ba yêu cầu, và hai đáp án lo hai phần khác nhau của cùng quy trình: | Yêu cầu | Đáp án | |---|---| | Quét CVE trên instance từ AMI mới | Inspector assessment | | Gắn tag AMI đã duyệt | Lambda + Parameter Store | | Quét lại mỗi 30 ngày | EventBridge cron + SSM Automation |

⚠ Inspector là dịch vụ DUY NHẤT chạy đánh giá CVE:

Config: kiểm tra CẤU HÌNH có đúng
  chuẩn không
    → không biết gì về lỗ hổng phần mềm
        ↓
    Patch Manager: CÀI bản vá
    → không tự phát hiện lỗ hổng
        ↓
    Inspector: quét gói phần mềm
      đối chiếu cơ sở dữ liệu CVE

Đây là lý do phương án A và B sai — cả hai dùng Config cho việc quét CVE.

⚠ Và AMI không tự quét được — phải khởi chạy instance từ nó:

Inspector quét INSTANCE đang chạy
  (và ECR image, Lambda)
        ↓
    Muốn đánh giá một AMI mới
    → khởi chạy một instance tạm
      từ AMI đó
    → quét, gắn tag kết quả, rồi
      thu hồi instance

Quy trình tự động:

AMI mới được tạo
    → EventBridge bắt sự kiện
        ↓
    Lambda khởi chạy instance tạm
        ↓
    Inspector quét
        ↓
    Không có lỗ hổng nghiêm trọng
    → gắn tag `DuyetBoiBaoMat=true`
      và thêm vào Parameter Store
        ↓
    Thu hồi instance tạm

Lưu danh sách AMI đã duyệt:

aws ssm put-parameter --name /bao-mat/ami-duoc-duyet \
  --type StringList --overwrite \
  --value "ami-0abc,ami-0def,ami-0ghi"

⚠ Parameter Store là nơi đúng cho danh sách này:

Hardcode trong mã Lambda
    → duyệt AMI mới phải sửa mã
      và triển khai lại
        ↓
    Parameter Store: cập nhật một
      tham số
    → mọi nơi đọc nó đều thấy ngay

Lịch quét lại 30 ngày:

aws events put-rule --name quet-lai-30-ngay \
  --schedule-expression "rate(30 days)"

aws events put-targets --rule quet-lai-30-ngay \
  --targets '[{"Id":"1",
    "Arn":"arn:aws:ssm:ap-southeast-1::automation-definition/QuetVaVaLoi",
    "RoleArn":"<arn-vai-tro>"}]'

⚠ Vì sao phải quét LẠI dù AMI đã duyệt:

AMI được duyệt hôm nay
    → không có lỗ hổng nào đã biết
        ↓
    Ba tuần sau, một CVE mới được
      công bố cho gói trong ảnh đó
    → AMI vẫn "đã duyệt" nhưng
      thực tế đã dễ tổn thương
        ↓
    Đây là lý do đề đòi quét định kỳ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | AMI mới được kiểm trước khi dùng | | | Danh sách duyệt cập nhật tự động | | | Quét lại định kỳ bắt được CVE mới | |

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

⚠ "Assessment template" là thuật ngữ của Inspector CLASSIC, đã bị thay thế.

Inspector v2 quét liên tục
    → không có "assessment template"
    → và không cần cron 30 ngày
        ↓
    Nó tự quét lại khi có CVE mới
      được công bố

Điều này làm phần lớn câu hỏi mất ý nghĩa:

Yêu cầu "quét lại mỗi 30 ngày"
    → Inspector v2 làm tốt hơn:
      quét ngay khi có CVE mới
        ↓
    Không phải chờ tới chu kỳ 30 ngày
      tiếp theo

Và quét AMI ngày nay có cách tốt hơn:

EC2 Image Builder có bước kiểm thử
  tích hợp Inspector
        ↓
    Ảnh không qua kiểm thử
    → pipeline dừng, ảnh không
      được phân phối
    → phòng ngừa thay vì phát hiện

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

• **A. Lambda tạo quy tắc duyệt, Parameter Store lưu danh sách, và quy tắc Config quét liên tục mọi EC2; phát hiện lỗ hổng thì chạy SSM Automation — đây là phương án gần nhất và phần Lambda cùng Parameter Store hoàn toàn đúng, nhưng Config đánh giá cấu hình chứ không quét lỗ hổng CVE.
• **B. Đọc CloudTrail log tìm instance ID khởi chạy từ AMI cần quét, rồi dùng Config managed rule chạy đánh giá CVE — Config không có quy tắc nào chạy đánh giá CVE.
• **D. Cài SSM Agent rồi "chạy quét CVE chi tiết trên instance" — SSM Agent là điều kiện tiên quyết cho Inspector v2, nhưng bản thân nó không chạy quét CVE nào.

Ghi nhớ

⚠ Bốn dịch vụ trong chủ đề lỗ hổng — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Inspector | PHÁT HIỆN lỗ hổng CVE | | Patch Manager | CÀI bản vá | | Config | KIỂM cấu hình đúng chuẩn | | Security Hub | GOM phát hiện từ mọi nguồn |

Từ khoá nhận diện:

"CVE assessment" → Inspector "install patches" → Patch Manager "approved AMI list" → Config approved-amis-by-id "scan images before deployment" → Image Builder + Inspector

Ba lưu ý về Inspector v2: | Lưu ý | Chi tiết | |---|---| | Quét liên tục, không phải theo lịch | | | Cần SSM Agent trên instance | | | Phủ EC2, ECR image và Lambda | |

⚠ Bật cho toàn tổ chức:

aws inspector2 enable --resource-types EC2 ECR LAMBDA \
  --account-ids 111122223333

aws inspector2 update-organization-configuration \
  --auto-enable ec2=true,ecr=true,lambda=true

Ba lưu ý về EC2 Image Builder: | Lưu ý | Chi tiết | |---|---| | Pipeline dựng AMI có bước kiểm thử | | | Tích hợp Inspector trong bước validate | | | Chỉ ảnh qua kiểm thử mới được phân phối | |

⚠ Đây là cách chuyển từ phát hiện sang phòng ngừa:

Quét sau khi AMI đã dùng
    → phát hiện muộn
        ↓
    Quét trong pipeline dựng ảnh
    → ảnh xấu không bao giờ ra
      tới môi trường nào

Ba lưu ý về Parameter Store: | Lưu ý | Chi tiết | |---|---| | StringList cho danh sách | | | Standard miễn phí, Advanced có phí | | | CloudFormation đọc trực tiếp được | |

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

Ba lưu ý về SSM Automation: | Lưu ý | Chi tiết | |---|---| | Runbook mô tả chuỗi bước tự động | | | Có bước duyệt tay nếu cần | | | Chạy được trên nhiều instance song song | |

Ba lưu ý về EventBridge scheduler: | Lưu ý | Chi tiết | |---|---| | rate() cho khoảng đều | | | cron() cho lịch cụ thể | | | EventBridge Scheduler mới linh hoạt hơn | |

Ba lưu ý về xử lý phát hiện: | Lưu ý | Chi tiết | |---|---| | Đẩy phát hiện Inspector sang Security Hub | | | EventBridge bắt phát hiện nghiêm trọng | | | Tự chạy Patch Manager để vá | |

{"source": ["aws.inspector2"],
 "detail-type": ["Inspector2 Finding"],
 "detail": {"severity": ["CRITICAL", "HIGH"]}}

Ba lưu ý về vòng khép kín: | Bước | Công cụ | |---|---| | Phát hiện | Inspector | | Thông báo | Security Hub, SNS | | Sửa | Patch Manager hoặc dựng AMI mới |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khởi chạy instance từ AMI cũ, xem Inspector có báo | | | Kiểm danh sách AMI trong Parameter Store cập nhật đúng | | | Xem có phát hiện nào lọt qua chu kỳ 30 ngày không | |

Và một lời khuyên: hãy đưa việc quét vào pipeline dựng AMI thay vì quét sau khi đã triển khai. Một AMI có lỗ hổng bị chặn ở bước kiểm thử tốn vài phút để sửa — còn cùng AMI đó đã chạy trên hàng trăm instance sản xuất thì là một chiến dịch thay thế cả đội máy.

Đáp án

**D — Tạo một IAM role mới cho bên thứ ba, gắn chính sách chỉ cho phép đúng những hành động ứng dụng đó cần, và thêm trust policy có điều kiện kiểm ExternalId khớp với mã khách hàng duy nhất mà nhà cung cấp đã đưa.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Đặc quyền tối thiểu | chính sách chỉ gồm hành động cần thiết | | Credential không dùng được bởi bên thứ ba KHÁC | ExternalId | | Bên thứ ba đã có tài khoản AWS và mã khách hàng | vai trò xuyên tài khoản |

⚠ ExternalId chống lại tấn công "confused deputy":

Nhà cung cấp X phục vụ nhiều
  khách hàng
    → giữ ARN vai trò của từng khách
        ↓
    Kẻ tấn công cũng là khách của X
    → đưa cho X ARN vai trò của BẠN
        ↓
    X giả nhận vai trò đó và báo
      cáo dữ liệu về cho kẻ tấn công
    → X bị lợi dụng làm "phó quan
      bối rối"

⚠ ExternalId chặn đúng điều đó:

Trust policy đòi ExternalId = "KH-8842"
    → chỉ X biết giá trị này gắn
      với tài khoản của BẠN
        ↓
    Kẻ tấn công không đoán được
    → và X sẽ dùng ExternalId của
      CHÍNH kẻ tấn công, không khớp

Trust policy đúng:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::999988887777:root"},
  "Action": "sts:AssumeRole",
  "Condition": {"StringEquals":
    {"sts:ExternalId": "KH-8842"}}}]}

Chính sách đặc quyền tối thiểu:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Action": ["ec2:DescribeInstances",
             "ec2:DescribeInstanceStatus",
             "ec2:DescribeTags"],
  "Resource": "*"}]}

⚠ Ứng dụng chỉ "khám phá tài nguyên EC2" — nên chỉ cần quyền Describe:

Đề nói ứng dụng "phát hiện tài
  nguyên EC2 đang chạy"
        ↓
    Chỉ cần đọc
    → không cần quyền tạo, sửa, xoá
      bất cứ thứ gì

⚠ Và mã khách hàng do NHÀ CUNG CẤP sinh, không phải bạn:

Bạn tự chọn giá trị
    → hai khách hàng có thể chọn trùng
    → hoặc chọn giá trị dễ đoán
        ↓
    Nhà cung cấp sinh giá trị duy nhất
      cho từng khách hàng
    → và họ chịu trách nhiệm dùng
      đúng giá trị
        ↓
    Đề nói rõ họ ĐÃ cung cấp mã này

Bên thứ ba giả nhận:

aws sts assume-role \
  --role-arn arn:aws:iam::111122223333:role/KiemToanBenThuBa \
  --role-session-name phien-kiem-toan \
  --external-id KH-8842

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không chia sẻ credential lâu dài nào | | | Credential tạm, hết hạn tự động | | | Thu hồi bằng cách xoá vai trò hoặc đổi điều kiện | |

⚠ Và CloudTrail ghi rõ mọi lần giả nhận:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \
  --query 'Events[?contains(CloudTrailEvent, `KiemToanBenThuBa`)]'

Biết được nhà cung cấp truy cập
  lúc nào, làm gì
    → và phát hiện được nếu có
      hoạt động bất thường

⚠ Siết thêm bằng điều kiện IP nếu nhà cung cấp có dải cố định:

{"Condition": {
  "StringEquals": {"sts:ExternalId": "KH-8842"},
  "IpAddress": {"aws:SourceIp": ["203.0.113.0/24"]}}}

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

• **B. Tạo IAM user trong tài khoản doanh nghiệp với quyền chỉ đủ cho ứng dụng, sinh access key và secret key rồi đưa cho nhà cung cấp — đây là phương án gần nhất và có phần đặc quyền tối thiểu đúng, nhưng credential tồn tại lâu dài nằm ở hệ thống bên ngoài, không thu hồi được tự động, và không có gì ngăn nó được dùng cho khách hàng khác.
• **C. Dùng Amazon Connect cho phép ứng dụng bên thứ ba truy cập, khai ExternalId trong cấu hình Connect — Amazon Connect là dịch vụ tổng đài chăm sóc khách hàng, hoàn toàn không liên quan tới việc cấp quyền truy cập AWS.
• **A. Đưa access key và secret key của chính bạn cho phần mềm bên thứ ba — vi phạm mọi nguyên tắc bảo mật; cấp toàn quyền của bạn cho một bên ngoài.

Ghi nhớ

⚠ Ba cách cấp quyền cho bên ngoài — bảng phải thuộc: | Cách | Đánh giá | |---|---| | Vai trò + ExternalId | ĐÚNG cho bên thứ ba | | Vai trò thường | cho tài khoản trong cùng tổ chức | | IAM user + access key | credential lâu dài, tránh |

Từ khoá nhận diện:

"third-party vendor, unique customer ID" → ExternalId "confused deputy" → ExternalId hoặc aws:SourceAccount "cross-account within organization" → aws:PrincipalOrgID "credentials cannot be used by another party" → ExternalId

Ba lưu ý về ExternalId: | Lưu ý | Chi tiết | |---|---| | Nhà cung cấp sinh, không phải bạn | | | Duy nhất cho từng khách hàng của họ | | | Không phải bí mật, nhưng không được đoán được | |

⚠ ExternalId KHÔNG thay thế xác thực:

Nó không phải mật khẩu
    → bên thứ ba vẫn phải có
      credential hợp lệ của
      tài khoản họ
        ↓
    ExternalId chỉ bảo đảm họ đang
      hành động THAY MẶT đúng
      khách hàng

Ba lưu ý về trust policy: | Lưu ý | Chi tiết | |---|---| | Principal là ARN tài khoản của nhà cung cấp | | | Điều kiện sts:ExternalId bắt buộc | | | Thêm điều kiện IP nếu có dải cố định | |

Ba lưu ý về đặc quyền tối thiểu: | Lưu ý | Chi tiết | |---|---| | Chỉ cấp API họ thật sự gọi | | | Ưu tiên chỉ đọc nếu đủ | | | Rà soát khi họ đổi tính năng | |

⚠ IAM Access Analyzer sinh chính sách từ hoạt động thật:

aws accessanalyzer start-policy-generation \
  --policy-generation-details \
    principalArn=arn:aws:iam::111122223333:role/KiemToanBenThuBa

Phân tích CloudTrail
    → sinh chính sách chỉ gồm API
      nhà cung cấp thật sự gọi
        ↓
    Thu hẹp từ quyền rộng ban đầu

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi mọi lần giả nhận | | | Cảnh báo nếu giả nhận ngoài giờ dự kiến | | | IAM Access Analyzer phát hiện chia sẻ ra ngoài | |

⚠ Bật Access Analyzer ở mọi tài khoản:

aws accessanalyzer create-analyzer \
  --analyzer-name phan-tich-to-chuc --type ORGANIZATION

Liệt kê MỌI tài nguyên chia sẻ ra
  ngoài tổ chức
    → vai trò, bucket, khoá KMS
        ↓
    Thường phát hiện thứ không ai
      nhớ đã chia sẻ

Ba lưu ý về thu hồi: | Lưu ý | Chi tiết | |---|---| | Xoá vai trò cắt quyền ngay | | | Hoặc đổi ExternalId | | | Phiên đang chạy vẫn hết hạn tự nhiên | |

Ba lưu ý về rà soát định kỳ: | Lưu ý | Chi tiết | |---|---| | Đối tác đến rồi đi, vai trò thì ở lại | | | Rà soát danh sách vai trò bên thứ ba mỗi quý | | | Xoá vai trò của nhà cung cấp đã ngừng hợp tác | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử giả nhận không có ExternalId — phải bị từ chối | | | Thử với ExternalId sai — phải bị từ chối | | | Kiểm CloudTrail có ghi externalId không | |

Và một lời khuyên: hãy rà soát danh sách vai trò cấp cho bên thứ ba mỗi quý và xoá những cái không còn dùng. Kiểm toán kết thúc, hợp đồng hết hạn, nhà cung cấp đổi — nhưng vai trò IAM thì ở lại mãi, và mỗi cái là một cánh cửa vào môi trường của bạn mà không ai còn nhớ đã mở.

Đáp án

**A — Thêm một giai đoạn AWS CodeBuild vào pipeline để kiểm thử tự động trên môi trường không phải sản xuất; dùng change set của CloudFormation xem trước thay đổi trước khi áp lên sản xuất; và lập mẫu blue/green trên CodeDeploy để triển khai sang môi trường riêng và quay lui nhanh khi cần.

Vì sao đúng

Đề nêu một sự cố cụ thể và phương án này chặn nó ở ba lớp: | Lớp | Cách chặn | |---|---| | Trước khi tới sản xuất | CodeBuild kiểm thử tự động ở môi trường thấp | | Trước khi áp thay đổi | change set cho thấy cái gì sẽ bị thay thế | | Sau khi áp | blue/green quay lui trong vài giây |

⚠ Change set là lớp phòng thủ đặc thù cho CloudFormation:

Sửa một thuộc tính bất biến
    → CloudFormation quyết định
      THAY THẾ tài nguyên
        ↓
    Thay thế CSDL = mất dữ liệu
    → thay thế launch template =
      thay cả đội máy
        ↓
    Change set cho biết TRƯỚC
      điều đó

Tạo và xem change set:

aws cloudformation create-change-set \
  --stack-name stack-san-xuat \
  --change-set-name kiem-tra-truoc \
  --template-body file://template.yaml

aws cloudformation describe-change-set \
  --stack-name stack-san-xuat \
  --change-set-name kiem-tra-truoc \
  --query 'Changes[?ResourceChange.Replacement==`True`].[ResourceChange.LogicalResourceId,ResourceChange.ResourceType]'

⚠ Truy vấn trên lọc đúng thứ nguy hiểm nhất:

Chỉ hiện tài nguyên sẽ bị THAY THẾ
    → đây là danh sách cần đọc kỹ
      nhất trước mỗi lần cập nhật
      sản xuất

⚠ Và blue/green cho phép quay lui nhanh như triển khai:

Môi trường cũ VẪN CÒN sau khi
  chuyển lưu lượng
        ↓
    Có vấn đề: chuyển ngược
    → vài giây
        ↓
    So với sửa template rồi chạy lại
      `update-stack`
    → hàng chục phút

Ba lớp trong pipeline:

Nguồn (CodeCommit/GitHub)
    ↓
Build (CodeBuild: lint, cfn-lint, unit test)
    ↓
Triển khai môi trường thử
    ↓
Kiểm thử tích hợp (CodeBuild)
    ↓
Change set cho sản xuất
    ↓
Duyệt tay
    ↓
Thực thi change set / blue-green

⚠ cfn-lint và cfn-guard bắt lỗi trước khi triển khai:

cfn-lint template.yaml
cfn-guard validate --rules quy-tac.guard --data template.yaml

cfn-lint: lỗi cú pháp, thuộc tính sai
    ↓
cfn-guard: vi phạm chính sách
  (ví dụ bucket không mã hoá)
        ↓
    Cả hai chạy trong vài giây
    → chặn được phần lớn lỗi cấu hình

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Lỗi bị bắt ở môi trường không ai dùng | | | Thấy trước tài nguyên nào bị thay thế | | | Quay lui nhanh nếu vẫn lọt | |

⚠ Và cfn-signal với WaitOnResourceSignals là lớp phụ:

CloudFormation coi instance "sẵn sàng"
  ngay khi EC2 khởi động
        ↓
    Nhưng ứng dụng còn đang cài
    → gửi tín hiệu từ user data
      sau khi thật sự sẵn sàng
        ↓
    Đây chính là cfn helper script
      mà phương án B nhắc tới
    → hữu ích, nhưng chỉ là một phần

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

• **B. Cập nhật template thêm cfn helper script để phát hiện và báo cáo tình trạng, và tạo kế hoạch kiểm thử cho đội QA làm thủ công — đây là phương án gần nhất và cfn-signal thật sự là công cụ đúng, nhưng kiểm thử thủ công không co giãn với "nhiều lần cập nhật mỗi chu kỳ phát triển"; và nó không có cơ chế quay lui nhanh.
• **C. Kiểm template bằng plugin trong IDE, xác thực bằng AWS CLI, thêm cfn helper script, và kiểm thử thủ công ở môi trường thấp — kiểm ở IDE bắt được lỗi cú pháp nhưng không bắt được lỗi logic; và vẫn là thủ công.
• **D. Lập blue/green trên CodeDeploy dùng CloudFormation cập nhật script user data, rồi đăng nhập tay vào instance để kiểm thử — kiểm thử thủ công trên từng instance là đúng thứ cần loại bỏ.

Ghi nhớ

⚠ Ba lớp bảo vệ cho pipeline hạ tầng — bảng phải thuộc: | Lớp | Công cụ | |---|---| | Kiểm tra tĩnh | cfn-lint, cfn-guard, IDE plugin | | Kiểm thử động | triển khai môi trường thử + test tự động | | Xem trước và quay lui | change set, blue/green |

Từ khoá nhận diện:

"preview infrastructure changes" → change set "quick rollback" → blue/green "automated testing in pipeline" → CodeBuild stage "signal when instance is ready" → cfn-signal + WaitOnResourceSignals

⚠ Bốn thuộc tính đặc biệt của tài nguyên CloudFormation: | Thuộc tính | Kiểm soát | |---|---| | CreationPolicy | chờ tín hiệu khi TẠO | | UpdatePolicy | cách CẬP NHẬT | | DeletionPolicy | khi XOÁ stack | | UpdateReplacePolicy | khi tài nguyên bị THAY THẾ |

⚠ UpdateReplacePolicy là thứ hay bị quên nhất:

`DeletionPolicy: Retain` bảo vệ khi
  xoá stack
        ↓
    Nhưng cập nhật làm CloudFormation
      thay thế tài nguyên
    → `UpdateReplacePolicy` mới
      có tiếng nói
        ↓
    Thiếu nó: mặc định `Delete`
    → mất dữ liệu dù đã cẩn thận

Ba lưu ý về change set: | Lưu ý | Chi tiết | |---|---| | Luôn dùng với stack sản xuất | | | Cho biết tài nguyên nào bị thay thế | | | Đưa vào pipeline làm bước bắt buộc | |

Ba lưu ý về CodeBuild trong pipeline: | Lưu ý | Chi tiết | |---|---| | Chạy lint, unit test, security scan | | | Buildspec khai các bước | | | Thất bại thì pipeline dừng | |

version: 0.2
phases:
  install:
    commands:
      - pip install cfn-lint
  build:
    commands:
      - cfn-lint template.yaml
      - cfn-guard validate --rules quy-tac.guard --data template.yaml
      - pytest kiem-thu/

Ba lưu ý về blue/green: | Lưu ý | Chi tiết | |---|---| | Hai phiên bản cùng chạy trong lúc chuyển | | | Thay đổi schema CSDL phải tương thích ngược | | | Giữ môi trường cũ một thời gian trước khi xoá | |

⚠ Expand rồi mới contract:

Lần 1: THÊM cột mới, mã ghi cả hai
    ↓
Lần 2: mã chỉ đọc cột mới
    ↓
Lần 3: XOÁ cột cũ
        ↓
    Mỗi bước đều quay lui được

Ba lưu ý về stack policy: | Lưu ý | Chi tiết | |---|---| | Chặn cập nhật tài nguyên quan trọng | | | Áp khi UpdateStack, không áp khi xoá | | | Ghi đè tạm khi thật sự cần cập nhật | |

Ba lưu ý về giám sát sau triển khai: | Lưu ý | Chi tiết | |---|---| | Theo dõi tỷ lệ lỗi 15 phút đầu | | | Alarm gắn vào cấu hình triển khai | | | Có kịch bản quay lui viết sẵn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đưa một template hỏng vào, xem pipeline có chặn | | | Xem change set có báo tài nguyên bị thay thế | | | Diễn tập quay lui và bấm giờ | |

Và một lời khuyên: hãy đưa bước xem change set thành cổng bắt buộc trước mỗi lần cập nhật sản xuất. Phần lớn sự cố do CloudFormation gây ra không phải vì template sai cú pháp — mà vì một thay đổi trông vô hại khiến nó âm thầm quyết định thay thế một tài nguyên chứa dữ liệu.

Đáp án

**D — Chạy Auto Scaling group EC2 trên BA vùng sẵn sàng, gắn Application Load Balancer, dùng Aurora với Aurora Replica làm tầng CSDL, và tạo bản ghi Alias trong Route 53 trỏ tới ELB.

Vì sao đúng

Đề đòi sẵn sàng cao và chịu lỗi, và phương án này là phương án duy nhất đúng ở cả bốn tầng: | Tầng | Lựa chọn | |---|---| | DNS | bản ghi Alias (đúng cho ELB) | | Cân bằng tải | ALB | | Tính toán | ASG trên ba AZ | | CSDL | Aurora + Replica |

⚠ Bản ghi Alias là bắt buộc khi trỏ tới ELB: | Tiêu chí | Alias | Bản ghi A thường | CNAME | |---|---|---|---| | Trỏ tới ELB | ĐÚNG | sai — IP của ELB đổi | được, nhưng không ở đỉnh tên miền | | Ở đỉnh tên miền | được | | KHÔNG được | | Chi phí truy vấn | miễn phí | | tính phí |

ELB đổi IP liên tục khi co giãn
    → không bao giờ trỏ bản ghi A
      tới IP của ELB
        ↓
    Đây là lý do phương án A và C sai
    → cả hai dùng bản ghi A

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

`congty.com` (đỉnh)
    → CNAME bị RFC cấm ở đây
        ↓
    Chỉ Alias của Route 53 làm được
    → đây là lý do phương án B sai

Tạo bản ghi Alias:

aws route53 change-resource-record-sets --hosted-zone-id <id> \
  --change-batch '{"Changes":[{"Action":"UPSERT",
    "ResourceRecordSet":{
      "Name":"congty.com","Type":"A",
      "AliasTarget":{
        "HostedZoneId":"<zone-id-cua-alb>",
        "DNSName":"<dns-alb>",
        "EvaluateTargetHealth":true}}}]}'

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

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

⚠ Và Aurora Replica cho cả hai thứ cùng lúc:

Replica phục vụ đọc
    → chia tải truy vấn
        ↓
    Và là ứng viên thăng cấp khi
      writer hỏng
    → chuyển đổi thường dưới 30 giây

Cấu hình cụm Aurora:

aws rds create-db-cluster \
  --db-cluster-identifier cum-giao-thong \
  --engine aurora-postgresql \
  --db-subnet-group-name nhom-3az

aws rds create-db-instance --db-instance-identifier writer \
  --db-cluster-identifier cum-giao-thong \
  --db-instance-class db.r6g.large --engine aurora-postgresql

aws rds create-db-instance --db-instance-identifier reader-1 \
  --db-cluster-identifier cum-giao-thong \
  --db-instance-class db.r6g.large --engine aurora-postgresql \
  --promotion-tier 1

⚠ promotion-tier quyết định replica nào được thăng cấp trước:

Tier 0 được ưu tiên nhất
    → đặt replica cùng cỡ với writer
      ở tier thấp
        ↓
    Replica nhỏ hơn ở tier cao
    → chỉ thăng cấp khi không còn
      lựa chọn nào tốt hơn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chịu được mất một AZ ở cả ba tầng | | | Aurora lưu sáu bản trên ba AZ | | | Alias miễn phí và tự theo IP của ELB | |

⚠ Aurora lưu trữ vốn đã trải ba AZ:

Sáu bản dữ liệu, hai bản mỗi AZ
    → mất một AZ vẫn còn bốn bản
        ↓
    Lưu trữ tách khỏi tính toán
    → thêm replica không phải
      chép lại dữ liệu

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

• **B. Dùng ElastiCache, ASG trên bốn AZ với ALB, RDS Multi-AZ có Read Replica, và bản ghi CNAME trỏ tới ELB — đây là phương án gần nhất và về hạ tầng thậm chí dư thừa hơn, nhưng CNAME không đặt được ở đỉnh tên miền; Alias mới là cách đúng.
• **C. Dùng DynamoDB, ASG trên bốn AZ với ALB, và bản ghi A trỏ tới ELB — bản ghi A không trỏ tới ELB được vì IP của ELB thay đổi.
• **A. ASG trên hai AZ với ALB, RDS MySQL Multi-AZ, và bản ghi A trỏ tới ELB — cùng lỗi bản ghi A; và hai AZ cho khả năng chịu lỗi kém hơn ba.

Ghi nhớ

⚠ Ba loại bản ghi trỏ tới tài nguyên AWS — bảng phải thuộc: | Bản ghi | Trỏ tới ELB | Ở đỉnh tên miền | Chi phí | |---|---|---|---| | Alias (A) | ĐÚNG | được | miễn phí | | CNAME | được | KHÔNG | tính phí | | A thường | SAI | được | tính phí |

Từ khoá nhận diện:

"point to an ELB" → Alias record "zone apex / naked domain" → Alias, không phải CNAME "highly available and fault tolerant" → nhiều AZ + Multi-AZ CSDL "read scaling" → Aurora Replica hoặc RDS Read Replica

⚠ Alias trỏ được tới những gì: | Đích | Hỗ trợ Alias | |---|---| | ELB, CloudFront, API Gateway | có | | S3 static website | có | | Global Accelerator | có | | Bản ghi khác trong cùng hosted zone | có | | Máy chủ ngoài AWS | KHÔNG |

Ba lưu ý về EvaluateTargetHealth: | Lưu ý | Chi tiết | |---|---| | true: Route 53 hỏi ELB xem còn target khoẻ | | | Thay được health check riêng, tiết kiệm phí | | | Với S3 website: luôn coi là khoẻ | |

Ba lưu ý về ASG nhiều AZ: | Lưu ý | Chi tiết | |---|---| | ALB phải gắn đủ AZ mà ASG dùng | | | health-check-type ELB chứ không phải EC2 | | | ASG tự cân bằng số instance giữa các AZ | |

⚠ ALB thiếu một AZ là lỗi âm thầm:

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

Ba lưu ý về Aurora: | Lưu ý | Chi tiết | |---|---| | Tới 15 replica | | | Reader endpoint tự cân bằng qua các replica | | | Độ trễ nhân bản thường dưới 100ms | |

Ba lưu ý về ứng dụng stateless: | Lưu ý | Chi tiết | |---|---| | Phiên nằm ngoài instance (ElastiCache, DynamoDB) | | | Không lưu gì trên đĩa cục bộ | | | Thu hồi instance bất kỳ lúc nào không ai nhận ra | |

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

⚠ Cảnh báo gộp che mất vấn đề:

Tổng số host khoẻ vẫn bình thường
    → nhưng một AZ hoàn toàn trống
        ↓
    Chỉ lộ ra khi bạn mất một
      AZ KHÁC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | dig congty.com xem trả về IP của ELB | | | Tắt một AZ, xem dịch vụ còn chạy | | | Buộc chuyển đổi Aurora và bấm giờ | |

Và một lời khuyên: hãy kiểm tra danh sách AZ của ALB có khớp với ASG hay không. Đó là một lệnh mất ba giây và là lỗi cấu hình phổ biến nhất trong kiến trúc nhiều AZ — nó không gây lỗi nào, chỉ lặng lẽ làm một phần công suất của bạn trở nên vô dụng.

Đáp án

**A — SCP là nguyên nhân, vì nó không cho phép tường minh hành động cần thiết để tạo bucket S3.

Vì sao đúng

Đọc kỹ SCP đang gắn vào tài khoản:

{"Statement": [
  {"Effect": "Allow", "Action": "cloudtrail:*", "Resource": "*"},
  {"Effect": "Allow", "Action": "iam:*", "Resource": "*"}]}

Chỉ cho phép CloudTrail và IAM
    → KHÔNG có `s3:*` ở đâu cả
        ↓
    SCP là DANH SÁCH CHO PHÉP
    → thứ không nằm trong đó
      bị từ chối ngầm định

⚠ SCP hoạt động như một TRẦN, không phải như cấp quyền:

Quyền hiệu lực = GIAO của
  SCP và IAM policy
        ↓
    IAM policy cho phép `s3:*`
    + SCP không cho phép S3
        ↓
    Giao = RỖNG
    → không tạo được bucket

⚠ Và IAM policy của người dùng hoàn toàn ổn:

{"Statement": [
  {"Effect": "Allow", "Action": "s3:*",
   "Resource": ["arn:aws:s3:::*"]},
  {"Effect": "Deny", "NotAction": "s3:*",
   "NotResource": ["arn:aws:s3:::*"]}]}

Câu đầu: cho phép mọi hành động S3
        ↓
    Câu hai: từ chối mọi hành động
      KHÔNG phải S3 trên tài nguyên
      KHÔNG phải S3
        ↓
    Tức là chỉ cho làm việc với S3
    → chính sách này CHO PHÉP tạo bucket

Đây là lý do phương án C sai — IAM policy không hề chặn S3.

⚠ NotAction và NotResource là cú pháp dễ đọc nhầm:

`"Deny"` + `"NotAction": "s3:*"`
        ↓
    Đọc là: từ chối mọi thứ
      NGOẠI TRỪ hành động S3
        ↓
    Không phải: từ chối S3

⚠ Và SCP HOÀN TOÀN hỗ trợ danh sách cho phép:

SCP có hai chiến lược:
    Deny list: `FullAWSAccess` +
      thêm câu Deny
        ↓
    Allow list: gỡ `FullAWSAccess`,
      chỉ liệt kê Allow
        ↓
    SCP trong đề dùng allow list
    → hoàn toàn hợp lệ

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

Sửa SCP:

{"Version": "2012-10-17", "Statement": [
  {"Effect": "Allow", "Action": "cloudtrail:*", "Resource": "*"},
  {"Effect": "Allow", "Action": "iam:*", "Resource": "*"},
  {"Effect": "Allow", "Action": "s3:*", "Resource": "*"}]}

⚠ Chú ý: chính sách FullAWSAccess mặc định:

Tài khoản mới trong Organizations
    → có SCP `FullAWSAccess` gắn sẵn
        ↓
    Gắn thêm SCP allow list
    → quyền hiệu lực là GIAO của
      cả hai
    → nghĩa là bị thu hẹp về SCP mới

Kiểm tra SCP đang áp:

aws organizations list-policies-for-target \
  --target-id 444455556666 --filter SERVICE_CONTROL_POLICY

aws organizations describe-effective-policy \
  --policy-type SERVICE_CONTROL_POLICY \
  --target-id 444455556666

Ba lợi ích của việc hiểu đúng cơ chế: | Lợi ích | Chi tiết | |---|---| | Gỡ lỗi quyền nhanh hơn nhiều | | | Không sửa nhầm IAM policy vô ích | | | Thiết kế SCP có chủ đích | |

⚠ IAM Policy Simulator không tính SCP:

Simulator chỉ đánh giá IAM policy
    → sẽ báo "cho phép" trong khi
      thực tế bị SCP chặn
        ↓
    Dùng `describe-effective-policy`
      để xem SCP thật sự áp

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

• **B. Cả IAM policy lẫn SCP đều có vấn đề; SCP phải cho phép tạo bucket và IAM policy phải khớp chính xác quyền của SCP — đây là phương án gần nhất và đúng ở vế SCP, nhưng IAM policy không cần khớp chính xác với SCP: nó chỉ cần nằm trong phạm vi SCP cho phép, và chính sách hiện tại đã hợp lệ.
• **C. IAM policy là nguyên nhân vì đã từ chối quyền thực hiện hành động S3 — đọc nhầm NotAction; chính sách đó từ chối mọi thứ KHÔNG phải S3.
• **D. SCP là nguyên nhân vì nó không hỗ trợ danh sách cho phép — SCP hỗ trợ cả deny list lẫn allow list.

Ghi nhớ

⚠ Thứ tự đánh giá quyền — phải thuộc:

1. Deny tường minh (IAM, SCP, resource policy)
   → TỪ CHỐI, dừng luôn
        ↓
2. SCP có cho phép không?
   → không → từ chối
        ↓
3. Allow tường minh trong IAM?
   → không → từ chối ngầm định
        ↓
4. Permission boundary có cho phép?
        ↓
5. Cho phép

⚠ Bốn cơ chế chính sách — bảng phải thuộc: | Cơ chế | Tác dụng | |---|---| | Identity policy | CẤP quyền | | SCP | đặt TRẦN, KHÔNG cấp | | Permission boundary | trần cho một principal | | Resource policy | cấp quyền từ phía tài nguyên |

Từ khoá nhận diện:

"SCP allows only X and Y, cannot do Z" → SCP không cho phép Z "IAM policy looks correct but denied" → kiểm SCP hoặc permission boundary "prevent even administrators" → SCP "grant permissions" → IAM policy, KHÔNG phải SCP

⚠ Hai chiến lược SCP: | Chiến lược | Cách | |---|---| | Deny list | giữ FullAWSAccess, thêm câu Deny | | Allow list | gỡ FullAWSAccess, chỉ liệt kê Allow |

Deny list: dễ quản, ít gây bất ngờ
    → phổ biến hơn trong thực tế
        ↓
    Allow list: chặt hơn nhưng phải
      liệt kê đủ mọi dịch vụ cần dùng
    → dễ chặn nhầm

Ba lưu ý về SCP: | Lưu ý | Chi tiết | |---|---| | KHÔNG áp cho tài khoản quản lý | | | Không áp cho service-linked role | | | Deny luôn thắng Allow | |

⚠ SCP allow list rất dễ chặn nhầm dịch vụ phụ:

Cho phép `ec2:*` nhưng quên
  `iam:PassRole`
        ↓
    Không gắn được instance profile
    → và lỗi không nói gì về IAM

Ba lưu ý về NotAction và NotResource: | Lưu ý | Chi tiết | |---|---| | NotAction với Allow: cho phép mọi thứ TRỪ | | | NotAction với Deny: từ chối mọi thứ TRỪ | | | Rất dễ đọc nhầm — cân nhắc viết tường minh | |

⚠ NotAction với Allow là mẫu nguy hiểm:

{"Effect": "Allow", "NotAction": "iam:*", "Resource": "*"}

Cho phép MỌI dịch vụ trừ IAM
    → gồm cả dịch vụ AWS ra mắt
      ngày mai
        ↓
    Đây là cách `PowerUserAccess`
      được viết — có chủ đích
    → nhưng dùng bừa thì rất rộng

Ba lưu ý về gỡ lỗi quyền: | Công cụ | Việc | |---|---| | describe-effective-policy | xem SCP thật sự áp | | IAM Policy Simulator | kiểm IAM policy (KHÔNG tính SCP) | | CloudTrail | xem lời gọi bị từ chối vì lý do gì |

Ba lưu ý về thiết kế OU: | Lưu ý | Chi tiết | |---|---| | Nhóm theo yêu cầu chính sách | | | Thử SCP ở OU nhỏ trước | | | Luôn có đường gỡ từ tài khoản quản lý | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | describe-effective-policy cho tài khoản đó | | | Thử tạo bucket sau khi sửa SCP | | | Kiểm CloudTrail xem lời gọi bị chặn ở tầng nào | |

Và một lời khuyên: hãy kiểm tra SCP trước khi động vào IAM policy khi gặp lỗi quyền khó hiểu. IAM policy là nơi ai cũng nhìn đầu tiên, nhưng SCP đứng trên nó và không hiện ra trong Policy Simulator — nên một chính sách trông hoàn toàn đúng vẫn có thể bị chặn ở một tầng bạn không nhìn thấy.

Đáp án

**B — Tạo một IAM role trong mỗi tài khoản cần kiểm toán, với trust policy liệt kê ARN của kiểm toán viên làm principal, và gán cho vai trò đó quyền chỉ đọc trên các tài nguyên cần thiết.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Kiểm toán viên có tài khoản AWS riêng | vai trò xuyên tài khoản | | Truy cập chỉ đọc | chính sách read-only | | Trên MỌI tài khoản của công ty | một vai trò ở mỗi tài khoản |

⚠ Vai trò phải nằm ở tài khoản CHỨA TÀI NGUYÊN:

Kiểm toán viên cần đọc tài nguyên
  trong tài khoản của công ty
        ↓
    Vai trò được tạo TRONG tài khoản đó
    → trust policy nói "tôi tin
      tài khoản kiểm toán viên"
        ↓
    Kiểm toán viên giả nhận từ
      tài khoản của họ

Trust policy:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::999988887777:root"},
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {"sts:ExternalId": "KIEM-TOAN-2026"},
    "Bool": {"aws:MultiFactorAuthPresent": "true"}}}]}

⚠ Nên thêm ExternalId vì đây là bên thứ ba:

Kiểm toán viên là công ty ngoài
    → có thể phục vụ nhiều khách hàng
        ↓
    `ExternalId` chống tấn công
      confused deputy
    → như đã dùng cho nhà cung cấp
      phần mềm

Chính sách chỉ đọc:

aws iam attach-role-policy --role-name VaiTroKiemToan \
  --policy-arn arn:aws:iam::aws:policy/SecurityAudit

aws iam attach-role-policy --role-name VaiTroKiemToan \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

⚠ Ba chính sách chỉ đọc hay bị lẫn — bảng phải thuộc: | Chính sách | Phạm vi | |---|---| | ReadOnlyAccess | đọc MỌI THỨ, kể cả NỘI DUNG dữ liệu | | SecurityAudit | chỉ đọc CẤU HÌNH bảo mật | | ViewOnlyAccess | chỉ liệt kê tài nguyên |

Kiểm toán PCI DSS cần xem cấu hình
  bảo mật
        ↓
    `SecurityAudit` đủ và hẹp hơn
    → `ReadOnlyAccess` cho phép đọc
      luôn object trong S3
    → thường là quá rộng cho
      dữ liệu thẻ

⚠ Và với dữ liệu thẻ tín dụng, phải chặn đọc nội dung:

{"Effect": "Deny",
 "Action": ["s3:GetObject", "dynamodb:GetItem",
            "dynamodb:Query", "dynamodb:Scan"],
 "Resource": "*"}

Kiểm toán viên xem cấu hình
    → không cần đọc dữ liệu thẻ
        ↓
    Deny tường minh bảo đảm điều đó
    → và chính bạn cũng chứng minh
      được với cơ quan quản lý

⚠ Triển khai vai trò cho mọi tài khoản bằng StackSets:

aws cloudformation create-stack-set \
  --stack-set-name vai-tro-kiem-toan \
  --template-body file://vai-tro.yaml \
  --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false

aws cloudformation create-stack-instances \
  --stack-set-name vai-tro-kiem-toan \
  --deployment-targets OrganizationalUnitIds=ou-abc \
  --regions us-east-1

⚠ auto-deployment là chi tiết quan trọng:

Công ty mở tài khoản mới
    → tự động có vai trò kiểm toán
        ↓
    Không phải nhớ tạo tay
    → không có tài khoản nào lọt
      khỏi phạm vi kiểm toán

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không tạo IAM user hay chia sẻ mật khẩu | | | Credential tạm, hết hạn tự động | | | Thu hồi bằng cách xoá vai trò khi kiểm toán xong | |

⚠ Và CloudTrail ghi rõ kiểm toán viên đã xem gì:

`userIdentity.arn` = vai trò kiểm toán
    + `sessionContext` = danh tính
      từ tài khoản của họ
        ↓
    Có bằng chứng đầy đủ cho cả
      hai bên

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

• **A. Tạo IAM user với access key và secret key cho kiểm toán viên, gắn quyền chỉ đọc — đây là phương án gần nhất và quyền chỉ đọc hoàn toàn đúng, nhưng access key là credential tồn tại lâu dài nằm ở hệ thống bên ngoài; không tự hết hạn và khó thu hồi triệt để.
• **D. Tạo tài khoản Active Directory cho kiểm toán viên và dùng liên kết SSO — đưa người ngoài vào thư mục nội bộ của công ty là rủi ro không cần thiết; và kiểm toán viên đã có tài khoản AWS riêng.
• **C. Đưa tên đăng nhập và mật khẩu của người dùng cho kiểm toán viên — chia sẻ credential vi phạm mọi nguyên tắc bảo mật, và làm mất khả năng truy vết ai đã làm gì.

Ghi nhớ

⚠ Ba cách cấp quyền cho bên ngoài — bảng phải thuộc: | Cách | Đánh giá | |---|---| | Vai trò + ExternalId | ĐÚNG cho bên thứ ba | | Vai trò thường | cho tài khoản trong cùng tổ chức | | IAM user + access key | credential lâu dài, tránh |

Từ khoá nhận diện:

"external auditor with own AWS account" → vai trò xuyên tài khoản "read-only security configuration" → SecurityAudit "deploy role to all accounts" → CloudFormation StackSets "third-party, multiple customers" → thêm ExternalId

Ba lưu ý về vai trò xuyên tài khoản: | Lưu ý | Chi tiết | |---|---| | Trust policy nói AI được giả nhận | | | Permission policy nói làm được GÌ | | | Cần cả hai phía đồng ý | |

⚠ Phía kiểm toán viên cũng phải có quyền:

{"Effect": "Allow",
 "Action": "sts:AssumeRole",
 "Resource": "arn:aws:iam::*:role/VaiTroKiemToan"}

`:root` trong trust policy nghĩa là
  "bất kỳ principal nào được chính
  tài khoản đó cho phép"
        ↓
    Không có IAM policy phía họ
    → vẫn không giả nhận được

Ba lưu ý về thời hạn phiên: | Lưu ý | Chi tiết | |---|---| | Mặc định 1 giờ, tối đa 12 giờ | | | Đặt ngắn cho vai trò kiểm toán | | | Hết hạn thì xin lại, không tự động gia hạn | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi mọi lần giả nhận | | | Đặt cảnh báo khi vai trò kiểm toán được dùng | | | Xem lại nhật ký sau khi kiểm toán xong | |

{"source": ["aws.sts"],
 "detail-type": ["AWS API Call via CloudTrail"],
 "detail": {"eventName": ["AssumeRole"],
   "requestParameters": {"roleArn":
     ["arn:aws:iam::*:role/VaiTroKiemToan"]}}}

Ba lưu ý về PCI DSS: | Lưu ý | Chi tiết | |---|---| | AWS cung cấp báo cáo tuân thủ qua Artifact | | | Mô hình trách nhiệm chia sẻ: AWS lo hạ tầng | | | Bạn lo cấu hình và dữ liệu | |

⚠ AWS Artifact có sẵn báo cáo cho kiểm toán viên:

aws artifact list-reports

Báo cáo PCI DSS, SOC, ISO của AWS
    → kiểm toán viên tải về được
        ↓
    Giảm phạm vi họ cần tự kiểm tra
    → chỉ còn phần cấu hình của bạn

Ba lưu ý về StackSets: | Lưu ý | Chi tiết | |---|---| | SERVICE_MANAGED dùng Organizations | | | auto-deployment phủ tài khoản mới | | | Triển khai theo OU hoặc toàn tổ chức | |

Ba lưu ý về thu hồi sau kiểm toán: | Lưu ý | Chi tiết | |---|---| | Xoá stack instance là xoá vai trò | | | Hoặc đổi ExternalId | | | Ghi lại ngày thu hồi cho hồ sơ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm toán viên giả nhận thử một tài khoản | | | Thử thao tác ghi — phải bị từ chối | | | Kiểm CloudTrail ghi đúng danh tính | |

Và một lời khuyên: hãy đặt lịch xoá vai trò kiểm toán ngay khi tạo nó. Kiểm toán có ngày kết thúc rõ ràng, nhưng vai trò IAM thì không tự biến mất — và một vai trò còn sót lại từ đợt kiểm toán năm ngoái là đúng loại cửa mở mà kiểm toán viên năm nay sẽ ghi vào báo cáo.