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

Đáp án

B — Tải gói triển khai Lambda từ tài khoản nguồn và tạo hàm mới ở tài khoản đích; chia sẻ cụm Aurora với tài khoản đích bằng AWS RAM và cấp quyền cho tài khoản đích clone cụm đó.

Vì sao đúng

Đề đòi chuyển ứng dụng sang tài khoản khác trong cùng tổ chức với downtime tối thiểu. Hai thành phần cần hai cách xử lý khác nhau.

⚠ Điểm mấu chốt: Aurora cloning tạo bản sao gần như tức thì nhờ copy-on-write — nhanh hơn khôi phục từ snapshot rất nhiều:

Khôi phục từ snapshot (phương án A, C)
        ↓
    Phải đọc toàn bộ dữ liệu từ snapshot, dựng lại cụm
    Với cơ sở dữ liệu lớn → hàng chục phút tới hàng giờ
        ↓
Aurora clone qua RAM
        ↓
    Chia sẻ tầng lưu trữ, chỉ ghi các khối thay đổi (copy-on-write)
        ↓
    → clone sẵn sàng gần như ngay lập tức, bất kể kích thước
        ↓
    → đây là cách đạt "downtime tối thiểu"

# Ở tài khoản nguồn: chia sẻ cụm qua RAM
aws ram create-resource-share --name chia-se-aurora \
  --resource-arns arn:aws:rds:ap-southeast-1:111122223333:cluster:don-hang \
  --principals <tai-khoan-dich>

# Ở tài khoản đích: clone
aws rds restore-db-cluster-to-point-in-time \
  --source-db-cluster-identifier <arn-cum-nguon> \
  --db-cluster-identifier ban-sao --restore-type copy-on-write --use-latest-restorable-time

Vì sao Lambda phải tạo lại chứ không chia sẻ. AWS RAM không hỗ trợ chia sẻ Lambda function. Cách chuyển hàm sang tài khoản khác là lấy gói triển khai (hoặc container image) rồi tạo hàm mới — nhanh và không có gì phức tạp.

⚠ Snapshot TỰ ĐỘNG của Aurora không chia sẻ được — chỉ snapshot thủ công mới chia sẻ được:

Automated snapshot
        ↓
    Thuộc về AWS quản lý, KHÔNG share sang tài khoản khác được
        ↓
    Muốn chia sẻ thì phải copy nó thành manual snapshot trước
        ↓
    → đây là lỗi của phương án A và C

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

• A (tải gói Lambda và tạo lại — đúng; nhưng chia sẻ automated Aurora snapshot với tài khoản đích) — đây là phương án gần nhất và vế Lambda của nó chính xác. Nhưng nó vướng hai chỗ ở vế cơ sở dữ liệu: snapshot tự động không chia sẻ được (phải copy thành manual trước), và ngay cả khi làm được thì khôi phục từ snapshot mất nhiều thời gian hơn clone — đi ngược yêu cầu downtime tối thiểu. Snapshot cũng là bản chụp tại một thời điểm, nên dữ liệu phát sinh sau đó bị mất.

• D (chia sẻ CẢ Lambda lẫn Aurora qua RAM, cấp quyền clone) — vế Aurora đúng nhưng RAM không chia sẻ được Lambda function. Danh sách tài nguyên RAM hỗ trợ gồm subnet, transit gateway, Route 53 Resolver rule, License Manager, Aurora DB cluster và một số loại khác — Lambda không nằm trong đó.

• C (chia sẻ Lambda qua RAM, chia sẻ automated snapshot) — gộp cả hai lỗi: RAM không chia sẻ Lambda, và automated snapshot không chia sẻ được.

Ghi nhớ

⚠ Bốn cách sao chép cơ sở dữ liệu Aurora — bảng phải thuộc: | Cách | Tốc độ | Ghi chú | |---|---|---| | Clone (copy-on-write) | gần như tức thì | chia sẻ lưu trữ ban đầu, liên tài khoản được qua RAM | | Khôi phục từ snapshot | chậm, tuỳ kích thước | bản chụp tại một thời điểm | | Cross-Region replica | liên tục | cho DR đa Region | | DMS | liên tục, đổi engine được | thêm thành phần phải vận hành |

Từ khoá nhận diện:

"minimize downtime" + chuyển Aurora sang tài khoản khác → RAM + clone "share automated snapshot" → LUÔN SAI, phải copy thành manual trước "share Lambda via RAM" → LUÔN SAI, RAM không hỗ trợ Lambda chuyển Lambda sang tài khoản khác → tải gói triển khai, tạo lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài khoản đích đã nhận chia sẻ chưa | aws ram get-resource-share-invitations | | Clone có chạy được không | kết nối và chạy thử truy vấn | | Hàm Lambda có đủ quyền không | kiểm execution role ở tài khoản đích |

Và một lời khuyên: hãy kiểm lại execution role và biến môi trường của hàm Lambda sau khi tạo lại ở tài khoản đích. Gói triển khai chỉ chứa mã; mọi thứ khác — role, biến môi trường, cấu hình VPC, layer, quyền gọi từ API Gateway — đều là cấu hình phải dựng lại. Hàm sẽ tạo thành công và trông hoàn toàn bình thường trong console, rồi thất bại ở lời gọi đầu tiên với một lỗi AccessDenied trỏ tới một tài nguyên mà bạn tưởng đã cấu hình xong. Đó là phần tốn thời gian nhất của việc chuyển tài khoản, và nó không nằm trong bất kỳ gói triển khai nào.

Đáp án

A — Dùng AWS SAM cùng CodeDeploy tích hợp sẵn để triển khai phiên bản Lambda mới, chuyển dần lưu lượng sang phiên bản đó, và dùng hàm kiểm thử pre-traffic và post-traffic để xác minh mã; tự lùi lại khi CloudWatch alarm kêu.

Vì sao đúng

Đề đòi rút ngắn thời gian đổi phiên bản và phát hiện lỗi nhanh hơn. SAM tích hợp sẵn CodeDeploy cho Lambda, và nó tự động hoá trọn vẹn cả hai.

⚠ Điểm mấu chốt: hook pre-traffic và post-traffic chạy TRONG quá trình triển khai — chúng chặn được bản lỗi trước khi người dùng chạm tới:

CodeDeploy bắt đầu triển khai
        ↓
    BeforeAllowTraffic: chạy hàm kiểm thử pre-traffic
        ↓
    Thất bại → dừng, KHÔNG chuyển lưu lượng nào
        ↓
    Đạt → chuyển dần lưu lượng theo cấu hình canary
        ↓
    AfterAllowTraffic: chạy hàm kiểm thử post-traffic
        ↓
    CloudWatch alarm kêu bất cứ lúc nào → tự động lùi lại

Toàn bộ khai báo trong một template SAM, không cần script:

Resources:
  HamXuLy:
    Type: AWS::Serverless::Function
    Properties:
      AutoPublishAlias: prod
      DeploymentPreference:
        Type: Canary10Percent5Minutes
        Alarms:
          - !Ref AlarmTyLeLoi
        Hooks:
          PreTraffic: !Ref HamKiemThuTruoc
          PostTraffic: !Ref HamKiemThuSau

⚠ Alarm phải đo đúng thứ phản ánh sức khoẻ, nếu không cơ chế lùi lại vô dụng:

Alarm chỉ theo dõi Errors của hàm
        ↓
    Một bản lỗi trả về HTTP 200 kèm dữ liệu sai sẽ KHÔNG kích hoạt alarm
        ↓
    → nên thêm alarm trên chỉ số nghiệp vụ, hoặc để hàm post-traffic kiểm nội dung

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

• B (CloudFormation stack với API Gateway endpoint trỏ tới phiên bản Lambda mới; đổi origin của CloudFront khi thành công, ngược lại thì lùi) — đây là phương án gần nhất và nó có cơ chế lùi lại. Nhưng nó chậm hơn nhiều: dựng một endpoint API Gateway mới rồi đổi origin CloudFront nghĩa là chờ distribution triển khai lại, thường mất vài phút — và cả chiều lùi cũng vậy. Nó cũng không có bước phát hiện lỗi tự động; việc "trong trường hợp thành công" do ai đó quyết định.

• C (đưa CloudFront và API Gateway vào stack cha, Lambda vào stack con; dùng change set và revert khi thất bại) — nested stack và change set là công cụ tốt cho hạ tầng, nhưng ở đây chúng chậm và thô: một lần cập nhật stack mất vài phút, và revert một change set không phải thao tác tức thì — CloudFormation phải chạy lại quá trình cập nhật theo chiều ngược. Nó cũng không có kiểm thử tự động trong lúc triển khai.

• D (gộp các script CLI thành một script duy nhất) — chính là hiện trạng, chỉ gọn hơn. Vẫn thủ công, vẫn không chuyển lưu lượng dần, vẫn dựa vào con người phát hiện lỗi.

Ghi nhớ

⚠ Bốn cấu hình triển khai Lambda của CodeDeploy — bảng phải thuộc: | Cấu hình | Cách chuyển | |---|---| | Canary10Percent5Minutes | 10% trong 5 phút rồi chuyển hết | | Canary10Percent30Minutes | như trên, cửa sổ dài hơn | | Linear10PercentEvery1Minute | tăng đều 10% mỗi phút | | AllAtOnce | chuyển ngay toàn bộ |

Từ khoá nhận diện:

"gradually shift traffic" cho Lambda → SAM + CodeDeploy, hoặc alias routing-config "pre-traffic / post-traffic hooks" → kiểm thử tự động trong lúc triển khai "rollback khi alarm" → DeploymentPreference.Alarms đổi origin CloudFront để chuyển phiên bản → chậm, phụ thuộc thời gian triển khai distribution gộp script CLI → vẫn thủ công, không giải quyết gì

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lưu lượng có chia đúng không | Invocations theo dimension ExecutedVersion | | Hook có chạy không | log của hàm hook trong CloudWatch | | Lùi lại có tự động không | cố ý làm alarm kêu trong môi trường thử |

Và một lời khuyên: hãy cố ý làm alarm kêu một lần trong môi trường thử và xác nhận CodeDeploy thật sự lùi lại. Cơ chế tự lùi là phần duy nhất của toàn bộ thiết lập mà bạn sẽ không bao giờ thấy hoạt động trong lúc mọi thứ suôn sẻ — nghĩa là nếu alarm được cấu hình sai ngưỡng, gắn nhầm hàm, hay đơn giản là ở trạng thái INSUFFICIENT_DATA vì hàm chưa có lưu lượng, bạn sẽ không phát hiện ra cho tới đúng lần triển khai hỏng đầu tiên. Một phép thử có chủ đích tốn mười phút và biến một giả định thành một sự thật đã kiểm chứng.

Đáp án

D — Áp dụng chiến lược triển khai blue/green.

Vì sao đúng

Đề nêu đúng một vấn đề: các lần cập nhật gần đây gây gián đoạn dịch vụ. Blue/green là chiến lược duy nhất trong bốn phương án loại bỏ được gián đoạn khi triển khai.

⚠ Điểm mấu chốt: blue/green tách việc TRIỂN KHAI khỏi việc CHUYỂN TẢI — đó là chỗ gián đoạn biến mất:

Cập nhật tại chỗ
        ↓
    Máy đang phục vụ bị sửa trong lúc đang chạy
        ↓
    Có khoảng máy không sẵn sàng → gián đoạn

Blue/green
        ↓
    Dựng môi trường xanh lá hoàn chỉnh, kiểm thử xong
        ↓
    Chuyển tải sang trong một thao tác
        ↓
    → không có khoảng nào máy vừa phục vụ vừa bị sửa
    → có sự cố thì chuyển ngược, môi trường xanh dương vẫn nguyên

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

⚠ AWS OpsWorks đã ngừng hoạt động từ 26/5/2024:

Đề mô tả đội DevOps dùng CloudFormation cho hạ tầng và OpsWorks cho ứng dụng
        ↓
    OpsWorks Stacks và OpsWorks for Chef/Puppet đã EOL
        ↓
    → tình huống của đề không còn dựng lại được trong thực tế

Khoá đáp án vẫn đúng — blue/green là câu trả lời bất kể công cụ nào — nhưng nếu gặp bài toán này hôm nay, phần OpsWorks sẽ được thay bằng CodeDeploy (vốn hỗ trợ blue/green sẵn) hoặc Systems Manager.

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

• A (áp dụng chiến lược canary release) — đây là phương án gần nhất và canary cũng giảm rủi ro triển khai rất tốt: chuyển dần lưu lượng và theo dõi ở từng bước. Nhưng với vấn đề mà đề mô tả — gián đoạn dịch vụ trong lúc cập nhật hạ tầng và ứng dụng — canary vẫn cập nhật trên chính các máy đang phục vụ ở mỗi bước, nên vẫn có khoảng gián đoạn cục bộ. Blue/green tránh được hoàn toàn vì môi trường mới được dựng riêng. Ngoài ra canary thiên về phát hiện lỗi dần, còn đề nhấn mạnh độ tin cậy của bản cập nhật.

• C (áp dụng CloudFormation change set) — hữu ích và nên có, nhưng nó là công cụ xem trước, không phải chiến lược triển khai. Change set cho bạn biết thay đổi sẽ làm gì; nó không làm cho việc áp dụng thay đổi đó trở nên không gián đoạn.

• B (áp dụng CloudFormation StackSets) — sai mục đích. StackSets triển khai cùng một stack ra nhiều tài khoản và Region; nó không liên quan gì tới việc giảm gián đoạn khi cập nhật một môi trường.

Ghi nhớ

⚠ Năm chiến lược triển khai — bảng phải thuộc: | Chiến lược | Downtime | Lùi lại | Chi phí hạ tầng | |---|---|---|---| | In-place | có thể có | chậm | thấp | | Rolling | không | chậm | thấp | | Blue/green | không | tức thì | gấp đôi khi chuyển | | Canary | không | nhanh cho phần đã chuyển | thêm một phần nhỏ | | Immutable | không | nhanh | thêm một nhóm mới |

Từ khoá nhận diện:

"service disruption during updates" → blue/green "gradually shift and monitor" → canary "change set" → công cụ xem trước, không phải chiến lược triển khai "StackSets" → đa tài khoản/Region, không liên quan gián đoạn "OpsWorks" → dịch vụ đã ngừng (5/2024)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lùi lại có nhanh thật không | diễn tập chuyển ngược trong môi trường thử | | Môi trường cũ còn nguyên không | đếm instance của cả hai nhóm sau khi chuyển | | Có tương thích ngược không | chạy phiên bản cũ với lược đồ mới |

Và một lời khuyên: hãy giữ mọi thay đổi lược đồ cơ sở dữ liệu tương thích ngược, nếu không khả năng lùi lại chỉ là ảo tưởng. Blue/green cho bạn quay về trong ba giây — nhưng nếu phiên bản mới đã chạy migration xoá một cột mà mã cũ vẫn đọc, thì môi trường cũ không chạy nổi nữa. Cơ chế lùi hoạt động hoàn hảo ở tầng hạ tầng, không lỗi gì cả, chỉ là ứng dụng cũ đang nhìn vào một cơ sở dữ liệu nó không hiểu. Nguyên tắc là mỗi lần triển khai chỉ thêm, và chỉ xoá ở lần sau khi chắc chắn không cần quay lại.

Đáp án

C — Tái kiến trúc ứng dụng: nạp dữ liệu vào S3, dùng AWS Glue biến đổi, lưu lược đồ bảng trong Glue Data Catalog, dùng Amazon Athena để truy vấn.

Vì sao đúng

Đề có ba ràng buộc, và một trong số đó thường bị bỏ qua: công cụ phân tích hiện tại dùng ODBC.

⚠ Điểm mấu chốt: Athena có driver ODBC chính thức — đó là thứ giữ được công cụ phân tích hiện tại:

Yêu cầu "must support the current analytics tool" dùng ODBC
        ↓
    Athena cung cấp driver ODBC và JDBC
        ↓
    Công cụ BI hiện tại kết nối như tới một cơ sở dữ liệu bình thường
        ↓
    → không phải đổi công cụ, không phải đào tạo lại người dùng

Vì sao serverless giải được nghẽn tính toán. Vấn đề của đề là thiếu dung lượng tính toán và mất dữ liệu vào. Với S3 làm nơi nhận và Glue/Athena xử lý theo yêu cầu, không còn cụm nào để mà thiếu dung lượng — mỗi truy vấn tự cấp phát tài nguyên riêng.

-- Athena truy vấn dữ liệu JSON đã được Glue chuyển thành Parquet
SELECT thiet_bi, avg(nhiet_do)
FROM cam_bien
WHERE nam='2026' AND thang='09'
GROUP BY thiet_bi;

⚠ Chuyển JSON sang Parquet trong bước Glue là thứ quyết định chi phí Athena:

Athena tính tiền theo BYTE QUÉT
        ↓
    JSON thô: quét toàn bộ mọi trường của mọi bản ghi
    Parquet: dạng cột, nén tốt — thường giảm 5–10 lần byte quét
        ↓
    → cộng với phân vùng theo ngày, chi phí truy vấn gần như không tăng theo dữ liệu

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

• B (nạp vào S3, dùng Kinesis Data Analytics biến đổi, tạo external schema trong Glue Data Catalog, dùng Redshift Spectrum truy vấn) — đây là phương án gần nhất và nó cũng dùng S3 làm nơi lưu, cũng dùng Glue Data Catalog. Nhưng nó vướng hai chỗ. Redshift Spectrum đòi một cụm Redshift chạy — tức là vẫn có cụm phải trả tiền 24/7, đi ngược yêu cầu tiết kiệm chi phí, trong khi Athena không cần gì cả. Và Kinesis Data Analytics dùng để phân tích LUỒNG đang chảy, không phải công cụ ETL theo lô cho dữ liệu đã nằm trong S3 — đó là việc của Glue.

• A (nạp vào S3, Lambda biến đổi, DynamoDB global table hai Region, dùng Elasticsearch truy vấn) — nhiều chỗ lệch. Global table hai Region là giải pháp cho tính sẵn sàng đa vùng, không liên quan tới vấn đề dung lượng tính toán. Và Elasticsearch/OpenSearch không có driver ODBC theo cách công cụ BI truyền thống mong đợi, nên yêu cầu giữ công cụ hiện tại không đạt.

• D (replatform: API Gateway nhận dữ liệu, Lambda biến đổi, Aurora PostgreSQL với replica, QuickSight sinh báo cáo) — hai vấn đề. Nó đổi công cụ phân tích sang QuickSight, trong khi đề đòi giữ công cụ hiện tại. Và với dữ liệu IoT khối lượng lớn, một cụm Aurora là kho tốn kém và vẫn có trần dung lượng — đúng loại giới hạn mà đề đang muốn thoát.

Ghi nhớ

⚠ Bốn công cụ truy vấn dữ liệu trong S3 — bảng phải thuộc: | Công cụ | Cần cụm | ODBC/JDBC | |---|---|---| | Athena | không | có | | Redshift Spectrum | có (cụm Redshift) | có | | EMR (Presto, Spark) | có | tuỳ | | S3 Select | không | không — chỉ trong một object |

Từ khoá nhận diện:

"must support the current ODBC tool" → Athena hoặc Redshift "cost-effective" + không muốn cụm → Athena "Redshift Spectrum" khi đòi tiết kiệm → vẫn cần cụm Redshift chạy "Kinesis Data Analytics" cho ETL theo lô → SAI, đó là phân tích luồng "global table" để chữa nghẽn tính toán → SAI, đó là đa Region

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí mỗi truy vấn | cột Data scanned trong lịch sử Athena | | Công cụ BI có nối được không | cài driver ODBC của Athena và thử | | Dữ liệu có bị mất không | so số bản ghi vào S3 với số bản ghi nguồn |

Và một lời khuyên: hãy chuyển JSON sang Parquet ngay trong bước Glue, đừng để Athena truy vấn thẳng JSON thô. Đây là quyết định gần như miễn phí lúc thiết lập và tốn kém về sau nếu bỏ qua: truy vấn trên JSON thô hoạt động hoàn toàn bình thường, trả về kết quả đúng, không có cảnh báo nào — nó chỉ quét nhiều hơn năm tới mười lần số byte cần thiết cho mỗi truy vấn. Với dữ liệu IoT tích luỹ hằng ngày và một đội phân tích chạy hàng trăm truy vấn mỗi tuần, khoảng cách đó xuất hiện trên hoá đơn dưới dạng một dòng Athena tăng đều mà không ai giải thích được.

Đáp án

B — Dựng sẵn cụm ECS và service trên Fargate ở Region thứ hai; tạo cross-Region RDS read replica ở Region đó; viết Lambda thăng cấp replica thành primary và cập nhật Route 53; thêm Lambda đó làm target của EventBridge rule.

Vì sao đúng

Đề đòi khôi phục nhanh ở Region khác. Điểm phân biệt giữa bốn phương án nằm ở cách xử lý tầng dữ liệu.

⚠ Điểm mấu chốt: read replica đã sao chép liên tục — khi sự cố xảy ra, dữ liệu ĐÃ ở đó rồi:

Cross-Region read replica
        ↓
    Sao chép liên tục, độ trễ thường vài giây
        ↓
    Sự cố → chỉ cần thăng cấp (promote)
        ↓
    → vài phút, và gần như không mất dữ liệu

Chụp snapshot khi sự cố xảy ra (A, C, D)
        ↓
    Phải chụp, phải chuyển sang Region khác, phải dựng cụm mới
        ↓
    → hàng chục phút, và dữ liệu chỉ tới thời điểm chụp

Vì sao dựng sẵn cụm ECS. Đề nói "quick restoration". Với Fargate, một service ở chế độ chờ có thể đặt desired count thấp hoặc bằng 0 — chi phí gần như không có, nhưng task definition, cluster, target group và ALB đã sẵn sàng, nên chỉ cần tăng số task.

aws rds promote-read-replica --db-instance-identifier du-phong-us-west
aws ecs update-service --cluster dr --service ung-dung --desired-count 10
aws route53 change-resource-record-sets --hosted-zone-id Z1 --change-batch file://chuyen-vung.json

⚠ EventBridge rule kích hoạt tự động rất nhanh — nên phải chắc chắn alarm không báo động giả:

Alarm nhạy quá → chuyển vùng vì một sự cố thoáng qua
        ↓
    Chuyển vùng là thao tác một chiều (promote replica không đảo ngược được)
        ↓
    → cân nhắc để bước cuối cần người phê duyệt, hoặc đặt ngưỡng alarm đủ chặt

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

• C (dựng sẵn cụm ECS ở Region khác — đúng; nhưng Lambda chụp snapshot RDS, nhân bản sang Region mới, dựng RDS từ snapshot) — đây là phương án gần nhất và vế tính toán của nó chính xác. Nhưng vế dữ liệu quá chậm: chụp snapshot của một cơ sở dữ liệu production tại thời điểm nó vừa gặp sự cố là điều có thể không thực hiện được, và ngay cả khi được thì việc sao chép snapshot sang Region khác rồi khôi phục mất hàng chục phút. Đề đòi "quick restoration", và cách này chậm hơn hẳn read replica.

• A (Lambda tự động triển khai cụm ECS backup, chụp sao lưu RDS, chuyển sang Region khác, dựng RDS mới, cập nhật Route 53) — chậm nhất trong bốn phương án: dựng cả cụm ECS từ đầu cộng với toàn bộ quy trình sao lưu và khôi phục, tất cả xảy ra sau khi sự cố đã bắt đầu.

• D (dựng sẵn cụm ECS, sao lưu RDS định kỳ và lưu ở Region phụ, Lambda dựng RDS mới từ bản sao lưu mới nhất) — khá hơn A nhưng vẫn dựa vào khôi phục từ bản sao lưu, nên vẫn chậm và vẫn mất dữ liệu phát sinh từ lần sao lưu cuối.

Ghi nhớ

⚠ Bốn chiến lược DR — bảng phải thuộc: | Chiến lược | Tầng dữ liệu | Tầng tính toán | RTO | |---|---|---|---| | Backup & Restore | chỉ sao lưu | không có gì | giờ | | Pilot Light | replica chạy sẵn | tắt | chục phút | | Warm Standby | replica chạy sẵn | chạy quy mô nhỏ | phút | | Active/Active | multi-master | đầy đủ | gần bằng 0 |

Từ khoá nhận diện:

"quick restoration in another Region" → read replica + hạ tầng dựng sẵn "snapshot khi sự cố xảy ra" → quá chậm "dựng cụm từ đầu khi có sự cố" → chậm nhất cross-Region read replica → promote mất vài phút, mất rất ít dữ liệu RTO gần bằng 0 → cần active/active, đắt hơn nhiều

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ sao chép | ReplicaLag của replica | | RTO thật | diễn tập chuyển vùng, bấm giờ từ lúc alarm kêu | | Image có ở Region DR không | aws ecr describe-images ở Region đó |

Và một lời khuyên: hãy nhân bản container image sang ECR của Region dự phòng, và kiểm tra điều đó định kỳ. Đây là thứ phá hỏng kế hoạch DR cho ứng dụng container một cách chắc chắn nhất: cụm ECS đã dựng, service đã cấu hình, task definition đã có — nhưng task definition trỏ tới một image URI ở ECR của Region chính. Khi Region đó gặp sự cố, task không kéo được image và ở mãi trạng thái PENDING. Mọi thứ khác trong kế hoạch đều hoạt động hoàn hảo; chỉ có ứng dụng là không bao giờ khởi động.

Đáp án

D — Cấu hình Glue crawler quét các cơ sở dữ liệu và tạo bảng trong Glue Data Catalog; tạo Glue ETL job nạp dữ liệu từ RDS vào S3; dùng Athena chạy truy vấn.

Vì sao đúng

Hai dữ kiện quyết định: mỗi cơ sở dữ liệu hơn 50 TB, và báo cáo chỉ chạy mỗi tuần một lần với truy vấn ad-hoc.

⚠ Điểm mấu chốt: tải chỉ chạy mỗi tuần một lần thì mọi cụm chạy 24/7 đều lãng phí:

Redshift hoặc Aurora
        ↓
    Trả tiền cụm suốt 168 giờ mỗi tuần
    Dùng thật vài giờ để chạy báo cáo
        ↓
S3 + Athena
        ↓
    Trả tiền lưu trữ (rất rẻ) + trả theo byte quét khi truy vấn
        ↓
    → sáu ngày không dùng thì không tốn gì cho phần tính toán

Với hàng trăm TB, khác biệt này rất lớn: một cụm Redshift đủ sức chứa dữ liệu đó tốn hàng nghìn đô mỗi tháng, trong khi S3 tính theo GB lưu trữ và Athena chỉ tính khi có người chạy truy vấn.

aws glue create-crawler --name quet-rds \
  --role AWSGlueServiceRole --database-name kho_bao_cao \
  --targets '{"JdbcTargets":[{"ConnectionName":"rds-conn","Path":"csdl/%"}]}'

⚠ Với 50 TB mỗi cơ sở dữ liệu, phải nạp gia tăng chứ không nạp lại toàn bộ mỗi tuần:

Nạp lại toàn bộ 50 TB mỗi tuần
        ↓
    Tốn thời gian, tốn tiền, và gây tải nặng lên RDS production
        ↓
Dùng job bookmark của Glue
        ↓
    Glue nhớ vị trí đã xử lý, lần sau chỉ nạp dữ liệu mới

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

• C (dựng cụm Redshift, Glue ETL nạp dữ liệu vào đó, dùng Redshift chạy truy vấn) — đây là phương án gần nhất và về mặt kỹ thuật nó là một kho dữ liệu rất tốt: Redshift cho hiệu năng truy vấn cao hơn Athena với dữ liệu lớn và truy vấn phức tạp. Nhưng nó thua ở đúng tiêu chí được hỏi. Một cụm Redshift đủ sức chứa hàng trăm TB chạy và tính tiền 24/7, trong khi báo cáo chỉ cần mỗi tuần một lần. Với hình thái sử dụng này, chi phí cụm nhàn rỗi lấn át mọi thứ khác. (Redshift Serverless ra đời sau đã thu hẹp khoảng cách này, nhưng nó không có trong danh sách phương án.)

• B (dựng cụm EMR, Glue ETL nạp vào cụm Redshift, dùng QuickSight truy vấn) — mô tả lộn xộn: dựng EMR rồi lại nạp vào Redshift, hai cụm cùng lúc. Đây là phương án đắt nhất trong bốn, và cả hai cụm đều chạy liên tục.

• A (Glue ETL sao chép dữ liệu từ các RDS vào một Aurora MySQL duy nhất, chạy SQL trên đó) — sai loại kho dữ liệu. Aurora là cơ sở dữ liệu giao dịch (OLTP), không tối ưu cho truy vấn phân tích quét hàng trăm TB. Nó cũng phải chạy 24/7, và gộp nhiều cơ sở dữ liệu 50 TB vào một cụm là bài toán dung lượng khó.

Ghi nhớ

⚠ Bốn kho phân tích — bảng phải thuộc, chú ý cột chi phí khi nhàn rỗi: | Kho | Chi phí khi không dùng | Hợp với | |---|---|---| | S3 + Athena | chỉ phí lưu trữ | truy vấn thỉnh thoảng, ad-hoc | | Redshift (provisioned) | cụm chạy liên tục | truy vấn thường xuyên, phức tạp | | Redshift Serverless | theo RPU dùng thật | trung gian giữa hai cái trên | | EMR | cụm chạy liên tục | xử lý dữ liệu lớn tuỳ biến sâu |

Từ khoá nhận diện:

"weekly report" + "MOST cost-effective" → S3 + Athena "ad-hoc SQL queries" → Athena hỗ trợ đầy đủ SQL "cụm Redshift" khi dùng mỗi tuần một lần → chi phí nhàn rỗi lấn át Aurora làm kho phân tích cho hàng trăm TB → sai loại kho | truy vấn liên tục, phức tạp, hàng ngày → lúc đó Redshift mới đáng |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí mỗi truy vấn | cột Data scanned trong Athena | | Nạp gia tăng có chạy không | so lượng dữ liệu mỗi lần chạy job | | Có tải nặng lên RDS không | theo dõi CPU và IOPS của RDS trong lúc job chạy |

Và một lời khuyên: hãy đặt BytesScannedCutoffPerQuery cho workgroup Athena trước khi mở quyền truy vấn cho người dùng nghiệp vụ. Athena tính tiền theo byte quét, và một truy vấn viết sai — thiếu mệnh đề lọc phân vùng, hoặc SELECT * trên bảng hàng trăm TB — có thể tốn nhiều hơn cả tháng chi phí lưu trữ chỉ trong vài phút. Truy vấn đó không lỗi, không cảnh báo, nó chạy đúng như được yêu cầu và trả về kết quả đúng. Một hạn mức ở cấp workgroup biến sự cố tài chính đó thành một thông báo lỗi mà người dùng đọc được và tự sửa.

Đáp án

B — Dùng Amazon ECS trên Spot Instance và bật Spot Instance Draining.

Vì sao đúng

Đề đòi hai thứ đối nghịch: giảm chi phí instance tối đa nhưng giảm khả năng gián đoạn dịch vụ. Spot cộng với draining là cách duy nhất đạt cả hai.

⚠ Điểm mấu chốt: draining biến hai phút báo trước thành một lần chuyển task êm ả:

AWS cần lại dung lượng
        ↓
    Gửi thông báo thu hồi trước 2 phút
        ↓
    Spot Instance Draining: ECS đặt container instance thành DRAINING
        ↓
    Ngừng xếp task mới vào máy đó
    Chuyển task đang chạy sang máy khác trong cluster
        ↓
    → dịch vụ không gián đoạn dù máy biến mất

Không bật cờ này thì khi máy bị thu hồi, task chết đột ngột cùng với máy.

# trong user data của container instance
echo "ECS_ENABLE_SPOT_INSTANCE_DRAINING=true" >> /etc/ecs/ecs.config

⚠ Draining cần có chỗ để chuyển task tới — cluster phải còn dung lượng dự phòng:

Cluster chạy sát 100% dung lượng
        ↓
    Máy bị thu hồi, ECS muốn chuyển task đi
        ↓
    Không còn chỗ trên máy nào khác
        ↓
    → task nằm chờ, dịch vụ vẫn gián đoạn
        ↓
    → nên trộn một phần On-Demand làm nền, và đa dạng loại instance

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

• D (dùng ECS Reserved Instance và bật termination protection) — đây là phương án gần nhất về mặt "giảm gián đoạn" và Reserved Instance thật sự giảm chi phí tới 72%. Nhưng nó thua Spot về mức tiết kiệm (90% so với 72%), và đề nói "reduce instance costs as much as possible". Ngoài ra termination protection không bảo vệ instance khỏi Auto Scaling hay khỏi việc thu hồi Spot — nó chỉ ngăn việc gọi TerminateInstances thủ công. Đây là bẫy ghép một lựa chọn giá hợp lý với một tính năng không làm việc mà tên nó gợi ý.

• C (dùng ECS Cluster Auto Scaling và cấu hình warm-up time) — Cluster Auto Scaling lo việc thêm bớt container instance theo nhu cầu của task, đó là quản lý dung lượng chứ không phải mô hình giá. Nó không tự giảm chi phí instance, và warm-up time chỉ tinh chỉnh tốc độ phản ứng.

• A (dùng Application Auto Scaling và tạm dừng dynamic scaling) — mâu thuẫn nội tại: tắt co giãn động nghĩa là bạn giữ dung lượng cố định, không tiết kiệm được gì khi tải thấp và không phục vụ nổi khi tải cao.

Ghi nhớ

⚠ Bốn mô hình giá — bảng phải thuộc: | Mô hình | Giảm giá | Rủi ro | |---|---|---| | On-Demand | 0% | không | | Reserved / Savings Plans | tới 72% | cam kết 1–3 năm | | Spot | tới 90% | bị thu hồi với 2 phút báo trước | | Dedicated Host | đắt hơn | dùng cho ràng buộc bản quyền |

Từ khoá nhận diện:

"reduce costs as much as possible" + chịu được gián đoạn → Spot "Spot Instance Draining" → bắt buộc khi chạy ECS trên Spot "termination protection" để chống thu hồi Spot → LUÔN SAI, không có tác dụng đó "Cluster Auto Scaling" như biện pháp giảm chi phí → đó là quản lý dung lượng "tạm dừng dynamic scaling" → đi ngược mục tiêu tiết kiệm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Draining có bật không | cat /etc/ecs/ecs.config trên container instance | | Tần suất bị thu hồi | Spot Instance Advisor cho từng lớp máy và Region | | Task có chuyển được không | huỷ thử một instance và xem task có chạy lại nơi khác |

Và một lời khuyên: hãy giữ một phần dung lượng dự phòng trong cluster, đừng chạy sát 100%. Spot Instance Draining chỉ hoạt động nếu có chỗ để chuyển task tới: khi một máy bị thu hồi, ECS cần đặt các task của nó lên máy khác trong hai phút. Nếu cluster đang chạy kín, những task đó không có chỗ và sẽ nằm ở trạng thái PENDING cho tới khi có máy mới khởi động — mà việc đó mất vài phút nữa. Cơ chế draining hoạt động đúng như thiết kế, không có lỗi nào, và dịch vụ vẫn gián đoạn.

Đáp án

B — IAM role của ECS TASK đã bị sửa đổi.

Vì sao đúng

Đề loại sẵn nhiều khả năng: cluster dựng theo thực hành tốt, bucket policy và IAM role dùng để truy cập bucket không đổi. Nhưng có hai loại role trong ECS, và đề chỉ nói tới một cách chung chung.

⚠ Điểm mấu chốt: ứng dụng trong container dùng TASK role, không dùng role của máy chủ:

Container gọi s3:PutObject
        ↓
    SDK lấy thông tin đăng nhập từ endpoint metadata của task
        ↓
    Thông tin đó đến từ TASK ROLE
        ↓
    → sửa task role là ứng dụng mất quyền, dù role của instance vẫn nguyên
    → và 403 xuất hiện đúng như đề mô tả

Đây là lý do phương án B đúng còn A sai: role của container instance dùng cho việc đăng ký vào cluster và các thao tác ở mức host, không cấp quyền cho mã trong container.

aws ecs describe-task-definition --task-definition ung-dung \
  --query 'taskDefinition.{TaskRole:taskRoleArn,ExecRole:executionRoleArn}'

⚠ 403 nghĩa là request ĐÃ tới S3 và bị từ chối vì quyền — không phải lỗi mạng hay lỗi tài nguyên:

403 Access Denied → tầng quyền
500 / timeout     → tầng mạng hoặc dịch vụ
404               → object hoặc bucket không tồn tại
        ↓
    → mã 403 thu hẹp phạm vi điều tra về IAM và bucket policy ngay lập tức

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

• A (IAM role của ECS container instance đã bị sửa) — đây là phương án gần nhất và nó chỉ khác đáp án đúng một từ. Nhưng container instance role chỉ phục vụ các thao tác ở mức host: đăng ký vào cluster, gửi trạng thái, kéo image (nếu không dùng execution role riêng). Mã ứng dụng trong container không dùng role này khi đã có task role — SDK trong container ưu tiên endpoint metadata của task. Nếu container instance role bị sửa thì triệu chứng thường là task không khởi động được hoặc instance rời khỏi cluster, không phải lỗi 403 khi ghi vào S3.

• C (ECS service không truy cập được) — không khớp với triệu chứng. Nếu service có vấn đề thì ứng dụng sẽ không chạy hoặc task liên tục khởi động lại; ở đây ứng dụng vẫn chạy và vẫn gọi được S3, chỉ là bị từ chối.

• D (task thiếu bộ nhớ) — thiếu bộ nhớ khiến container bị dừng với mã thoát 137 hoặc OutOfMemoryError, không tạo ra lỗi 403 ở phía S3.

Ghi nhớ

⚠ Ba loại IAM role trong ECS — bảng phải thuộc, đây là chỗ hay lẫn nhất: | Role | Ai dùng | Dùng để | |---|---|---| | Task role | mã trong container | gọi S3, DynamoDB, SQS... | | Task execution role | agent ECS | kéo image từ ECR, ghi log CloudWatch, lấy secret | | Container instance role | EC2 host | đăng ký cluster, báo trạng thái |

Từ khoá nhận diện:

container gọi dịch vụ AWS bị 403 → task role task không kéo được image → task execution role instance không vào được cluster → container instance role 403 → tầng quyền, không phải mạng Fargate → không có container instance role, chỉ có hai loại kia

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Container đang mang danh tính gì | aws sts get-caller-identity từ trong container | | Task role là role nào | describe-task-definition | | Ai đã sửa role | CloudTrail, sự kiện PutRolePolicy hoặc DetachRolePolicy |

Và một lời khuyên: hãy chạy aws sts get-caller-identity từ bên trong container khi gặp lỗi quyền, thay vì suy luận từ cấu hình. Đây là cách duy nhất biết chắc mã của bạn đang mang danh tính nào: nếu task definition thiếu taskRoleArn, container sẽ âm thầm rơi về instance role — nó vẫn có một danh tính, vẫn gọi được một số thứ, nên không có lỗi cấu hình nào hiện ra. Lệnh đó trả về ARN thật đang được dùng, và thường kết thúc cuộc điều tra ngay lập tức.

Đáp án

D — Dùng AWS DMS chuyển cơ sở dữ liệu sang Amazon RDS; nhân bản các máy khách sang AWS bằng AWS SMS; tạo bản ghi A trong Route 53 cho từng máy khách.

Vì sao đúng

Đề đòi giảm gánh nặng vận hành cơ sở dữ liệu và ít ảnh hưởng nhất tới nhân viên vận hành sau khi di chuyển. Hai vế đó dẫn tới hai quyết định khác nhau cho hai loại máy.

⚠ Điểm mấu chốt: "each client VM has a different configuration and saves data in the local file system" là lý do KHÔNG gộp chúng sau một load balancer:

Đặt các máy khách sau ALB (phương án A, B, C)
        ↓
    Load balancer giả định các máy phía sau TƯƠNG ĐƯƠNG nhau
        ↓
    Nhưng mỗi máy có cấu hình riêng và dữ liệu cục bộ riêng
        ↓
    → người dùng bị gửi tới nhầm máy, không thấy thủ tục và kết quả của mình
        ↓
    → nhân bản nguyên trạng và cho mỗi máy một bản ghi DNS riêng mới giữ đúng hành vi

Đây là lý do bản ghi A cho từng máy khách là chi tiết đúng chứ không phải thừa: nó giữ nguyên cách người dùng truy cập đúng máy của họ.

Vì sao DMS sang RDS. Đề nói mục tiêu là giảm công vận hành cơ sở dữ liệu. RDS lo vá lỗi, sao lưu, chuyển dự phòng. DMS với chế độ full-load-and-cdc chuyển được trong cửa sổ 48 giờ với downtime rất ngắn.

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

⚠ AWS Server Migration Service (SMS) đã được thay bằng Application Migration Service (MGN):

Đáp án đúng của câu này dùng AWS SMS
        ↓
    AWS đã ngừng nhận khách hàng mới cho SMS và khuyến nghị chuyển sang MGN
        ↓
    → khoá đáp án vẫn đúng theo bộ đề, nhưng công cụ đã lỗi thời
        ↓
    → nếu gặp bài toán này hôm nay, thay SMS bằng MGN

MGN còn tốt hơn cho chính yêu cầu của đề: nó sao chép liên tục ở mức khối, nên downtime khi cắt chuyển chỉ vài phút thay vì phải chờ một chu kỳ nhân bản. Với cửa sổ thay đổi 48 giờ và đường Direct Connect 10 Gbit, MGN xử lý thoải mái.

Không sửa khoá đáp án, chỉ ghi chú. Khoá phải khớp với cái máy chủ dùng để chấm.

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

• A (DMS sang Amazon Redshift; chuyển ứng dụng Java sang Elastic Beanstalk sau ALB) — đây là phương án gần nhất và nó cũng dùng DMS, cũng giảm công vận hành cơ sở dữ liệu. Nhưng hai chỗ lệch. Redshift là kho dữ liệu phân tích, còn đề mô tả một cơ sở dữ liệu Oracle được truy vấn bởi ứng dụng — chuyển sang Redshift đòi thay đổi cách ứng dụng hoạt động. Và đưa các máy khách vào Elastic Beanstalk sau ALB phá vỡ tính riêng biệt của từng máy: chúng có cấu hình khác nhau và lưu dữ liệu cục bộ.

• B (SMS nhân bản cơ sở dữ liệu thành EC2; ứng dụng Java lên Elastic Beanstalk sau ALB) — giữ Oracle trên EC2 nghĩa là không giảm được công vận hành nào — vẫn tự vá, tự sao lưu, tự lo tính sẵn sàng. Đó là điều đề nói phải giảm.

• C (SMS nhân bản cơ sở dữ liệu thành EC2; SMS nhân bản máy khách; đặt các EC2 sau ALB) — cùng lỗi giữ Oracle tự quản, cộng thêm việc đặt các máy khách khác nhau sau một ALB.

Ghi nhớ

⚠ Bốn công cụ di chuyển — bảng phải thuộc: | Công cụ | Dùng cho | |---|---| | DMS | cơ sở dữ liệu, có CDC để cắt chuyển ít downtime | | SCT | chuyển đổi lược đồ khi đổi engine | | MGN (thay SMS) | máy chủ — rehost, sao chép liên tục | | DataSync | dữ liệu tệp |

Từ khoá nhận diện:

"reduce operational overhead on the database" → chuyển sang dịch vụ có quản lý (RDS) "each VM has different configuration" → nhân bản riêng, KHÔNG gộp sau load balancer "saves data in the local file system" → không phải kiến trúc stateless, không đặt sau ALB "AWS SMS" → đã bị MGN thay thế "Redshift" cho cơ sở dữ liệu giao dịch → sai loại kho

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu có khớp không | bật DMS data validation | | Máy khách có chạy được sau khi nhân bản không | đăng nhập thử vào từng máy | | Bản ghi DNS có đúng không | dig từng tên máy khách |

Và một lời khuyên: hãy kiểm tra dữ liệu lưu trong file system cục bộ của từng máy khách có được nhân bản đầy đủ không. Đề nói rõ các máy này lưu thủ tục và kết quả truy vấn trên đĩa cục bộ — nghĩa là dữ liệu có giá trị nằm ngoài cơ sở dữ liệu, ở một nơi mà không quy trình sao lưu cơ sở dữ liệu nào chạm tới. Công cụ nhân bản máy chủ sao chép ở mức khối nên thường lấy được hết, nhưng nếu có ai đó quyết định "dựng lại máy cho sạch" thay vì nhân bản, phần dữ liệu ấy sẽ biến mất mà không ai nhận ra cho tới khi người dùng đi tìm một kết quả cũ.

Đáp án

B — Tạo một tài khoản AWS riêng dành cho danh tính, nơi tạo các IAM user; tạo role với quyền phù hợp trong tài khoản production và testing; thêm tài khoản danh tính vào trust policy của các role đó.

Vì sao đúng

Đề đòi quản lý tập trung danh tính và quyền cho hai môi trường tách biệt. Mẫu chuẩn cho việc này là tài khoản danh tính riêng.

⚠ Điểm mấu chốt: role phải nằm ở TÀI KHOẢN CHỨA TÀI NGUYÊN, không nằm ở tài khoản danh tính:

Người dùng đăng nhập vào tài khoản identity
        ↓
    Gọi sts:AssumeRole vào role nằm TRONG tài khoản production
        ↓
    Role đó có quyền trên tài nguyên của chính tài khoản production
        ↓
    → quyền được định nghĩa ở nơi tài nguyên tồn tại
        ↓
    → đây chính là chỗ phương án C sai: nó đặt role ở tài khoản identity

// Trust policy của role trong tài khoản production
{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::<tai-khoan-identity>:root"},
  "Action": "sts:AssumeRole",
  "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}

⚠ Ngày nay IAM Identity Center là cách được khuyến nghị cho chính mẫu này:

Tài khoản identity với IAM user là mẫu cổ điển, vẫn đúng
        ↓
    IAM Identity Center (trước là AWS SSO) làm cùng việc đó nhưng:
      - không cần tạo IAM user
      - permission set gán cho tài khoản và nhóm
      - tích hợp sẵn với IdP bên ngoài
        ↓
    → nhưng nó không có trong danh sách phương án của đề

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

• C (tạo tài khoản identity riêng — đúng; nhưng tạo role trong chính tài khoản identity và uỷ quyền sang production/testing) — đây là phương án gần nhất và nó chỉ khác đáp án đúng ở chỗ đặt role. Nhưng đặt role ở tài khoản identity thì role đó chỉ có quyền trên tài nguyên của chính tài khoản identity — vốn không có gì. Không có cơ chế nào để một role "uỷ quyền" quyền của mình sang tài khoản khác; quyền luôn được cấp bởi tài khoản sở hữu tài nguyên. Đây là bẫy đảo chiều rất tinh vi.

• A (tạo mọi user trong tài khoản production, tạo role trong cả hai, cấp cross-account access từ production sang testing) — đặt danh tính vào tài khoản production là rủi ro: tài khoản chứa tài nguyên quan trọng nhất giờ cũng là nơi lưu mọi thông tin đăng nhập. Nguyên tắc là tách danh tính khỏi khối lượng công việc.

• D (dựng Organization gồm production và testing, tạo IAM user trong từng tài khoản, dùng SCP để kiểm soát quyền tập trung) — hiểu sai vai trò SCP. SCP đặt TRẦN quyền, nó không cấp quyền và không quản lý danh tính. Tạo IAM user riêng trong từng tài khoản là điều ngược lại với "quản lý danh tính tập trung" — mỗi người sẽ có nhiều bộ thông tin đăng nhập.

Ghi nhớ

⚠ Bốn mẫu quản lý danh tính đa tài khoản — bảng phải thuộc: | Mẫu | Đặc điểm | |---|---| | IAM Identity Center | khuyến nghị hiện nay — permission set, tích hợp IdP | | Tài khoản identity + cross-account role | mẫu cổ điển, vẫn đúng | | SAML federation từ IdP tại chỗ | dùng khi đã có AD FS, Okta | | IAM user trong từng tài khoản | không nên — không tập trung được |

Từ khoá nhận diện:

"centralized control of identities" → tài khoản identity riêng hoặc Identity Center "role trong tài khoản chứa tài nguyên" → đúng, quyền cấp ở nơi tài nguyên tồn tại "role trong tài khoản identity rồi uỷ quyền sang" → SAI, không có cơ chế đó "SCP để kiểm soát quyền tập trung" → SCP đặt trần, không cấp quyền "IAM user trong từng tài khoản" → ngược với tập trung

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Role có assume được không | aws sts assume-role từ tài khoản identity | | Ai đã dùng role | CloudTrail ở tài khoản đích | | Quyền có quá rộng không | IAM Access Analyzer |

Và một lời khuyên: hãy bắt buộc MFA ngay trong trust policy của role, đừng chỉ bật MFA khi đăng nhập. Hai thứ đó khác nhau: bật MFA cho IAM user chỉ đảm bảo họ dùng MFA lúc đăng nhập vào console, nhưng một bộ access key dài hạn của cùng user đó vẫn assume role được mà không cần MFA nào. Điều kiện aws:MultiFactorAuthPresent trong trust policy đóng đúng lỗ đó — và với một tài khoản danh tính là cửa vào duy nhất của mọi môi trường, đó là chốt chặn đáng giá nhất bạn đặt được.