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

Đáp án

D — Dùng Amazon WorkSpaces làm máy tính để bàn trên cloud, nối tới mạng tại chỗ bằng VPN, tích hợp Active Directory bằng AD Connector, và dựng máy chủ RADIUS để bật MFA.

Vì sao đúng

Đề nêu bốn yêu cầu, và yêu cầu cuối cùng — tái tạo gần đúng giao diện máy tính hiện tại — là thứ phân biệt WorkSpaces với AppStream.

⚠ Điểm mấu chốt: MFA cho WorkSpaces đi qua RADIUS — không cấu hình được trong console:

Người dùng đăng nhập WorkSpaces
        ↓
    AD Connector chuyển yêu cầu xác thực về AD tại chỗ
        ↓
    Đồng thời gửi truy vấn tới máy chủ RADIUS đã khai
        ↓
    RADIUS xác minh mã OTP
        ↓
    → cả hai đạt thì mới cho vào

Đây là điểm phân biệt duy nhất giữa phương án C và D, và nó là kiến thức cụ thể: AWS Directory Service hỗ trợ MFA thông qua máy chủ RADIUS của bạn, không phải bằng một công tắc trong AWS Management Console.

Vì sao AD Connector chứ không phải Managed Microsoft AD. AD Connector là cầu nối — nó không lưu bản sao thư mục nào, chỉ chuyển tiếp yêu cầu xác thực về AD tại chỗ. Đúng với yêu cầu "dùng thông tin đăng nhập hiện tại" mà không phải đồng bộ hay di chuyển gì.

aws ds connect-directory --name congty.local --size Small \
  --connect-settings VpcId=vpc-abc,SubnetIds=subnet-a,subnet-b,\
CustomerDnsIps=10.0.1.10,10.0.2.10,CustomerUserName=ServiceAccount

aws workspaces modify-account --dedicated-tenancy-support ENABLED

⚠ AD Connector đòi đường mạng thông suốt tới domain controller — thiếu VPN là mọi thứ đứng:

AD Connector không giữ bản sao nào
        ↓
    MỌI yêu cầu xác thực đều phải đi về AD tại chỗ
        ↓
    Mất kết nối VPN → không ai đăng nhập được
        ↓
    → đường mạng trở thành thành phần trọng yếu, cần dự phòng

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

• C (WorkSpaces, VPN, AD Connector, cấu hình MFA cho WorkSpaces qua AWS Management Console) — đây là phương án gần nhất và ba phần tư của nó chính xác bằng đáp án đúng: WorkSpaces, VPN và AD Connector đều chuẩn. Nó chỉ sai ở cách bật MFA. Không có tuỳ chọn bật MFA cho WorkSpaces trực tiếp trong console — MFA của AWS Directory Service được cấu hình bằng cách khai thông tin máy chủ RADIUS (địa chỉ, cổng, shared secret, giao thức). Đây là bẫy kiểm tra đúng một chi tiết triển khai, và là kiểu câu thưởng cho người đã thật sự dựng WorkSpaces với MFA.

• A (AppStream 2.0 với giao diện giống desktop, VPN, AD FS) — sai loại dịch vụ. AppStream 2.0 phát trực tuyến từng ỨNG DỤNG, không phải cả máy tính để bàn. Đề nói nhân viên có "mix of Windows and Linux desktops with various applications installed" và giải pháp phải "closely replicate the user interface of their existing desktop environments" — đó là mô tả của một desktop đầy đủ. Ngoài ra AD FS là dịch vụ liên kết danh tính cho ứng dụng web, không phải cách để AppStream dùng thông tin đăng nhập AD.

• B (AppStream 2.0 tích hợp AD FS, cấu hình MFA trên AppStream) — cùng lỗi cốt lõi về loại dịch vụ, và bỏ luôn phần kết nối mạng về AD tại chỗ.

Ghi nhớ

⚠ Bốn dịch vụ desktop và ứng dụng ảo — bảng phải thuộc: | Dịch vụ | Phát cái gì | |---|---| | WorkSpaces | máy tính để bàn đầy đủ (Windows, Linux), lâu dài | | AppStream 2.0 | từng ứng dụng riêng lẻ, theo phiên | | WorkSpaces Web | trình duyệt an toàn trong máy ảo | | WorkSpaces Thin Client | thiết bị phần cứng đầu cuối |

Từ khoá nhận diện:

"replicate their existing desktop environment" → WorkSpaces "stream specific applications" → AppStream 2.0 "use existing on-premises AD credentials" → AD Connector "MFA cho WorkSpaces" → máy chủ RADIUS, KHÔNG phải console "AD FS" để cho WorkSpaces dùng AD → SAI, AD FS dành cho liên kết danh tính web

Ba việc kiểm chứng: | Việc | Cách | |---|---| | AD Connector có nối được không | trạng thái directory phải là Active | | MFA có bắt buộc không | thử đăng nhập không nhập OTP — phải bị từ chối | | Đường VPN có ổn định không | giám sát tunnel, và nên có hai tunnel |

Và một lời khuyên: hãy dựng đường dự phòng cho kết nối về AD tại chỗ trước khi triển khai WorkSpaces cho toàn bộ nhân viên. Với AD Connector, mọi lần đăng nhập đều phải đi về domain controller trong trung tâm dữ liệu — nghĩa là đường VPN không còn là tiện ích mà là thành phần trọng yếu của hệ thống. Điều trớ trêu là kịch bản mà giải pháp này sinh ra để phục vụ — nhân viên phải làm việc từ xa khẩn cấp — thường trùng đúng với kịch bản mà trung tâm dữ liệu hoặc đường truyền của công ty đang gặp vấn đề. Không có gì trong AWS cảnh báo bạn về sự phụ thuộc đó; nó chỉ hiện ra khi 350 người cùng không đăng nhập được vào buổi sáng bạn cần họ nhất.

Đáp án

D — Dùng AWS DMS chuyển dữ liệu sang Amazon DynamoDB bằng tác vụ sao chép liên tục; viết lại API để đọc từ DynamoDB; triển khai API đó trên Amazon API Gateway và bật API caching.

Vì sao đúng

Đề nêu hai mối lo và một đặc điểm dữ liệu quan trọng: chi phí bản quyền Db2 theo CPU, hiệu năng truy vấn, và dữ liệu cập nhật liên tục.

⚠ Điểm mấu chốt: "dataset is constantly updated" là thứ loại mọi phương án xuất dữ liệu theo lô:

Xuất hằng ngày rồi tải lên S3 (phương án C)
        ↓
    Dữ liệu cũ tới 24 giờ
        ↓
    → API trả về thông tin lỗi thời

DMS với migration-type = full-load-and-cdc
        ↓
    Chuyển toàn bộ dữ liệu ban đầu, rồi bám theo thay đổi liên tục
        ↓
    → độ trễ tính bằng giây

Vì sao rời khỏi Db2 chứ không chỉ chuyển chỗ chạy. Đề nói lo "Db2 CPU licensing costs". Chạy Db2 trên EC2 (phương án B) vẫn phải trả phí bản quyền — có khi còn đắt hơn vì mô hình cấp phép trên đám mây. Chỉ có việc đổi hẳn engine mới xoá được khoản đó.

aws dms create-replication-task \
  --replication-task-identifier db2-sang-dynamodb \
  --source-endpoint-arn <db2> --target-endpoint-arn <dynamodb> \
  --migration-type full-load-and-cdc \
  --table-mappings file://anh-xa.json

⚠ API Gateway cache là lớp giảm độ trễ cuối cùng và rẻ nhất:

Request lặp lại cùng tham số
        ↓
    API Gateway trả từ cache, KHÔNG gọi backend
        ↓
    → độ trễ xuống vài mili giây, và giảm cả tải lẫn chi phí phía sau
        ↓
    → nhưng phải đặt TTL hợp lý: dữ liệu cập nhật liên tục thì TTL dài là trả dữ liệu cũ

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

• B (rehost Db2 lên EC2, cache bằng instance store, viết lại API, API Gateway + caching) — đây là phương án gần nhất và nó cải thiện được hiệu năng: máy mạnh hơn, cache cục bộ, thêm API caching. Nhưng nó bỏ trắng mối lo lớn nhất của đề. Chạy Db2 trên EC2 vẫn trả nguyên phí bản quyền theo CPU — đúng khoản chi mà công ty đang muốn thoát. Ngoài ra dùng instance store làm cache là lựa chọn nguy hiểm: dữ liệu ở đó mất hoàn toàn khi instance dừng hoặc bị thay thế, và không có cách khôi phục. Đây là bẫy hay vì nó giải quyết được vế hiệu năng một cách thuyết phục rồi để nguyên vế chi phí.

• C (xuất dữ liệu hằng ngày lên S3, viết lại API để đọc từ S3, API Gateway + caching) — mâu thuẫn với chính đề: "the dataset is constantly updated". Xuất hằng ngày nghĩa là API phục vụ dữ liệu cũ tới một ngày. Ngoài ra S3 không cho truy cập từng bản ghi với độ trễ mili giây như DynamoDB; muốn truy vấn phải qua Athena, vốn có độ trễ hàng giây.

• A (cache kết quả truy vấn ở lưu trữ cục bộ, đồng bộ dữ liệu lên S3 bằng lệnh COPY, viết lại API dùng EFS, API Gateway + caching) — mô tả lộn xộn giữa nhiều dịch vụ. COPY là lệnh của Redshift, không phải công cụ đồng bộ từ Db2 lên S3. EFS là hệ thống tệp, không phải nơi phục vụ truy vấn dữ liệu có cấu trúc cho API. Và nó vẫn giữ nguyên Db2 nên không giải quyết vấn đề bản quyền.

Ghi nhớ

⚠ Bốn chế độ của DMS — bảng phải thuộc: | Chế độ | Việc | |---|---| | full-load | chuyển một lần, chấp nhận downtime | | full-load-and-cdc | chuyển toàn bộ rồi bám theo thay đổi — cắt chuyển gần như không downtime | | cdc | chỉ bám thay đổi, dữ liệu ban đầu đã chuyển bằng cách khác |

Từ khoá nhận diện:

"licensing costs" → phải đổi engine, không chỉ đổi chỗ chạy "constantly updated" → CDC, loại mọi cách xuất theo lô "read-only API" + độ trễ thấp → DynamoDB + API Gateway cache "lift and shift to EC2" khi lo phí bản quyền → LUÔN SAI, phí vẫn còn "instance store làm cache bền" → SAI, mất dữ liệu khi dừng máy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ CDC | CDCLatencySource và CDCLatencyTarget | | Dữ liệu có khớp không | bật DMS data validation | | Cache có hiệu quả không | CacheHitCount so với CacheMissCount của API Gateway |

Và một lời khuyên: hãy đặt TTL cache của API Gateway theo mức chấp nhận được của nghiệp vụ, và ghi rõ con số đó ở đâu đó. Đây là chỗ hai quyết định đúng cộng lại thành một kết quả sai: bạn chọn DMS với CDC để dữ liệu chỉ trễ vài giây, rồi bật API caching với TTL 3.600 giây để giảm độ trễ — và người dùng nhận về dữ liệu cũ tới một giờ. Toàn bộ công sức xây đường ống sao chép gần thời gian thực bị vô hiệu hoá bởi một tham số ở tầng trên cùng. Không có gì báo lỗi, độ trễ đo được rất đẹp, và mọi chỉ số về sao chép đều xanh — chỉ có nội dung trả về là không mới như bạn tưởng.

Đáp án

B — Dùng SCP kiểu deny list, gắn ở TỪNG cấp OU, giữ nguyên SCP mặc định của AWS ở root và các OU; với tài khoản cần ngoại lệ thì tạo một OU riêng dưới root và gắn SCP chặn ít dịch vụ hơn.

Vì sao đúng

Đề đòi ba thứ: chặn nhiều dịch vụ trên mọi tài khoản, có đường xử lý ngoại lệ hợp lệ, ít việc vận hành nhất.

⚠ Điểm mấu chốt: SCP không thể "cho phép lại" thứ đã bị Deny ở tầng trên — nên ngoại lệ phải nằm ở NHÁNH KHÁC, không phải ở tầng dưới:

Deny ở root
        ↓
    Mọi OU và tài khoản bên dưới đều dính, không có ngoại lệ
        ↓
    Thêm Allow ở OU con → vô nghĩa, Deny vẫn thắng
        ↓
    → cách duy nhất tạo ngoại lệ: đặt tài khoản đó vào một NHÁNH
      không có cái Deny ấy trên đường đi

Đây là lý do phương án B gắn SCP ở từng OU thay vì ở root: mỗi OU có bộ chặn riêng, nên tạo một OU với bộ chặn nhẹ hơn là cách diễn đạt ngoại lệ hợp lệ duy nhất.

Root  (chỉ giữ FullAWSAccess mặc định)
├── OU-KinhDoanh      ← SCP deny list đầy đủ
├── OU-CongNghe       ← SCP deny list đầy đủ
└── OU-NgoaiLe        ← SCP deny list NHẸ HƠN (cho phép thêm vài dịch vụ)

Vì sao deny list dễ vận hành hơn allow list. Với allow list, bạn phải liệt kê đủ mọi dịch vụ mà mọi tài khoản đang dùng — thiếu một cái là gãy ngay, và mỗi dịch vụ mới AWS ra mắt lại phải cân nhắc thêm vào. Deny list chỉ liệt kê thứ muốn chặn.

⚠ Đừng gỡ SCP mặc định FullAWSAccess:

FullAWSAccess là SCP AWS gắn sẵn ở root và mọi OU
        ↓
    Nó không cấp quyền cho ai, nhưng nó mở TRẦN
        ↓
    Gỡ đi mà không có SCP Allow thay thế → trần đóng lại hoàn toàn
        ↓
    → mọi hành động ở nhánh đó bị chặn, kể cả những thứ bạn không định chặn

Đây là lý do phương án A và D sai một cách nguy hiểm.

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

• C (deny list gắn ở ROOT, ngoại lệ bằng cách tạo SCP mới cho OU đó và thêm dịch vụ vào allow list) — đây là phương án gần nhất và nó chọn đúng kiểu deny list. Nhưng nó không tạo được ngoại lệ. Deny gắn ở root áp cho mọi tài khoản, và như đã nói, một SCP Allow ở OU con không ghi đè được Deny ở root. Kết quả là ngoại lệ không bao giờ có hiệu lực, dù cấu hình trông hoàn toàn hợp lý. Đây là bẫy quan trọng nhất của câu hỏi và cũng là hiểu nhầm phổ biến nhất về SCP: người ta hình dung nó như IAM policy, nơi Allow ở một chỗ có thể bù cho hạn chế ở chỗ khác.

• A (allow list ở root, gỡ SCP mặc định khỏi root và mọi OU, ngoại lệ bằng cách thêm dịch vụ vào allow list của OU) — hai vấn đề. Allow list đòi liệt kê mọi dịch vụ mà mọi đơn vị đang dùng — công việc bảo trì không có điểm dừng, trái với "minimal operational overhead". Và gỡ FullAWSAccess là thao tác rủi ro cao: nếu allow list sót một dịch vụ đang được dùng, nó ngừng hoạt động ngay lập tức trên toàn tổ chức.

• D (deny list ở cả root lẫn mọi OU, gỡ SCP mặc định, ngoại lệ bằng cách thêm allow vào SCP của OU) — gộp mọi lỗi: gắn Deny ở root nên không tạo được ngoại lệ, gỡ SCP mặc định nên đóng trần, và vẫn dựa vào ý tưởng sai rằng Allow ở dưới ghi đè được Deny ở trên.

Ghi nhớ

⚠ Bốn quy tắc SCP — bảng phải thuộc: | Quy tắc | Hệ quả | |---|---| | SCP đặt trần, không cấp quyền | vẫn cần IAM policy để làm được việc | | Quyền hiệu dụng = giao của mọi SCP từ root xuống | thêm tầng chỉ thu hẹp | | Deny tường minh không thể bị ghi đè ở tầng dưới | ngoại lệ phải nằm ở nhánh khác | | Không áp cho management account | thử nghiệm ở đó luôn "qua" |

Từ khoá nhận diện:

"prohibit many services" → deny list (ít việc bảo trì hơn allow list) "valid exception must be achievable" → OU riêng với SCP nhẹ hơn, KHÔNG phải Allow ở tầng dưới "Deny ở root rồi Allow ở OU" → LUÔN SAI, Deny thắng "remove the default AWS managed SCP" → rủi ro cao, thường là dấu hiệu phương án sai "minimal operational overhead" → deny list, giữ FullAWSAccess

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SCP nào đang áp cho một tài khoản | list-policies-for-target lặp lên tới root | | Ngoại lệ có hiệu lực không | thử hành động đó trong chính tài khoản ngoại lệ | | Có ai bị chặn nhầm không | CloudTrail, lọc errorCode = AccessDenied kèm thông điệp về SCP |

Và một lời khuyên: hãy dùng điều kiện trong SCP thay vì tạo thêm OU khi ngoại lệ chỉ áp cho một vài role cụ thể. Tạo OU riêng cho mỗi ngoại lệ nghe gọn gàng ở lần đầu, nhưng sau vài chục yêu cầu, cây tổ chức của bạn biến thành một tập hợp các nhánh đặc thù mà không ai còn nhớ vì sao chúng tồn tại — và việc di chuyển một tài khoản giữa các OU trở thành thao tác rủi ro vì nó thay đổi toàn bộ trần quyền cùng lúc. Một mệnh đề Condition với aws:PrincipalArn giữ ngoại lệ nằm ngay trong chính sách, nơi người đọc sau này nhìn thấy được lý do, thay vì phải suy ra nó từ hình dạng của cây OU.

Đáp án

C — Dùng AWS Elastic Beanstalk và tạo một môi trường thứ hai làm đích triển khai cho pipeline CI/CD; khi triển khai thì hoán đổi URL giữa môi trường staging và production.

Vì sao đúng

Đề đòi hai thứ: nhiều lần phát hành mỗi giờ và lùi lại nhanh. Cả hai đều trỏ tới blue/green, và Elastic Beanstalk có cơ chế dựng sẵn cho nó.

⚠ Điểm mấu chốt: swap URL chỉ đổi bản ghi CNAME — cả hai môi trường vẫn chạy nguyên vẹn:

Môi trường A (production) ← CNAME app.congty.vn
Môi trường B (staging)    ← triển khai phiên bản mới vào đây
        ↓
    Kiểm thử trên B bằng URL riêng của nó
        ↓
    Swap: AWS đổi CNAME của hai môi trường cho nhau
        ↓
    → B thành production, A thành staging và VẪN ĐANG CHẠY
        ↓
    Có sự cố → swap lại → về A trong vài phút

Đây là điều phân biệt nó với mọi chiến lược tại chỗ: phiên bản cũ không bị ghi đè, nên lùi lại là một thao tác chứ không phải một lần triển khai lại.

aws elasticbeanstalk swap-environment-cnames \
  --source-environment-name app-prod \
  --destination-environment-name app-staging

⚠ Swap CNAME phụ thuộc TTL của DNS — đó là giới hạn thật của tốc độ chuyển:

Beanstalk đổi CNAME
        ↓
    Client và resolver còn giữ cache bản ghi cũ tới hết TTL
        ↓
    → trong khoảng đó vẫn còn lưu lượng đi vào môi trường cũ
        ↓
    → giữ TTL thấp (60 giây) cho bản ghi trỏ tới Beanstalk

Vì lý do này, đừng chấm dứt môi trường cũ ngay sau khi swap — hãy để nó chạy thêm ít nhất vài TTL.

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

• A (CloudFormation StackSets tạo stack production và staging, cập nhật stack staging rồi dùng Route 53 weighted routing trỏ tới "StackSet endpoint address") — đây là phương án gần nhất và ý tưởng có hai môi trường song song là đúng hướng. Nhưng nó vướng hai chỗ. StackSets dùng để triển khai cùng một stack ra nhiều TÀI KHOẢN và REGION, không phải để quản hai môi trường trong một tài khoản — đó là việc của stack thường. Và không có thứ gọi là "StackSet endpoint address": StackSet không phơi ra endpoint nào cả. Route 53 weighted routing thì chia được lưu lượng, nhưng nó phụ thuộc TTL và phải chỉnh trọng số thủ công, chậm hơn hẳn một lần swap.

• B (đóng gói bản cập nhật vào AMI, cập nhật Auto Scaling group, huỷ dần instance cũ để máy mới khởi động với AMI mới) — đây là mẫu rolling replacement, và nó quá chậm cho nhiều lần phát hành mỗi giờ. Dựng AMI mất hàng chục phút, thay thế toàn bộ đội máy mất thêm chừng đó nữa. Lùi lại cũng đòi lặp lại toàn bộ quá trình với AMI cũ — đúng thứ mà một sự cố production không cho phép.

• D (pipeline dựa trên AMI chứa ứng dụng và cấu hình, triển khai bằng cách thay thế EC2 instance) — cùng vấn đề với B: chu kỳ dựng AMI quá dài so với nhịp phát hành mà đề yêu cầu, và không có cơ chế lùi lại tức thì.

Ghi nhớ

⚠ Bốn chính sách triển khai của Elastic Beanstalk — bảng phải thuộc: | Chính sách | Downtime | Lùi lại | |---|---|---| | All at once | có | phải triển khai lại | | Rolling | không | chậm | | Rolling with additional batch | không | chậm | | Immutable | không | nhanh — dựng nhóm mới song song | | Blue/green bằng swap URL | không | nhanh nhất — swap ngược |

Từ khoá nhận diện:

"multiple releases every hour" → cần cơ chế triển khai nhanh, không dựng AMI "quickly rolled back" → blue/green "swap the staging and production environment URLs" → đúng, đây là blue/green của Beanstalk "StackSets" cho hai môi trường trong một tài khoản → SAI, StackSets dành cho đa tài khoản/Region "build an AMI for each update" khi phát hành hằng giờ → quá chậm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Swap có xong chưa | kiểm CNAME của hai môi trường | | Còn lưu lượng vào môi trường cũ không | theo dõi request count của cả hai | | Lùi lại có nhanh thật không | diễn tập swap ngược trong môi trường thử |

Và một lời khuyên: hãy giữ môi trường cũ chạy ít nhất vài giờ sau khi swap, đừng chấm dứt nó ngay để tiết kiệm. Đây là chỗ khả năng lùi lại biến mất đúng lúc cần: swap URL diễn ra ngay lập tức ở phía AWS, mọi chỉ số trông tốt trong mười phút đầu, và việc dọn dẹp môi trường cũ có vẻ là bước hoàn tất hợp lý. Nhưng nhiều lỗi chỉ lộ ra sau khi đủ lưu lượng thật đi qua — một truy vấn chậm chỉ xuất hiện với dữ liệu production, một rò rỉ bộ nhớ chỉ tích lại sau một giờ. Đến lúc đó, thứ lẽ ra là một lần swap ngược ba phút đã trở thành một lần triển khai lại từ đầu, giữa sự cố.

Đáp án

A — Định nghĩa tài nguyên AWS bằng JavaScript hoặc TypeScript; dùng AWS Cloud Development Kit (CDK) sinh ra CloudFormation template từ mã của lập trình viên và dựng stack; đưa CDK vào CodePipeline dưới dạng một job CodeBuild.

Vì sao đúng

Đề nêu đúng hai nỗi lo của lập trình viên, và CDK sinh ra để giải chính xác cả hai.

⚠ Điểm mấu chốt: CDK không thay thế CloudFormation — nó SINH RA CloudFormation template:

Mã TypeScript của lập trình viên
        ↓
    cdk synth
        ↓
    CloudFormation template (JSON/YAML)
        ↓
    cdk deploy → CloudFormation dựng stack
        ↓
    → giữ nguyên toàn bộ chuẩn triển khai bằng CloudFormation của công ty

Đây là lý do CDK khớp hoàn hảo với đề: công ty đã chuẩn hoá quanh CodePipeline và CloudFormation, và CDK không phá vỡ điều đó — nó chỉ đổi cách viết template.

Vòng lặp là ví dụ rõ nhất về thứ mà YAML thuần không làm được tự nhiên:

import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';

export class HaTangStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string) {
    super(scope, id);

    // vòng lặp thật, không phải cú pháp đặc thù của template
    for (const moiTruong of ['dev', 'staging', 'prod']) {
      new s3.Bucket(this, `Bucket-${moiTruong}`, {
        bucketName: `cong-ty-${moiTruong}`,
        encryption: s3.BucketEncryption.S3_MANAGED,
        versioned: moiTruong === 'prod',
      });
    }
  }
}

⚠ CDK sinh ra rất nhiều tài nguyên ngầm — luôn đọc cdk diff trước khi triển khai:

Một dòng CDK có thể sinh ra hàng chục tài nguyên
        ↓
    Ví dụ: một construct cấp cao tự tạo IAM role, log group, security group
        ↓
    → tiện lợi, nhưng dễ tạo ra thứ bạn không định tạo
        ↓
    → `cdk diff` cho thấy đúng những gì sẽ thay đổi trên CloudFormation

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

• C (tạo CloudFormation template và dùng lại phần mã JavaScript/TypeScript làm instance user data, rồi dùng CDK triển khai bằng những template đó) — đây là phương án gần nhất và nó có nhắc tới CDK, nên dễ trông như đúng. Nhưng nó hiểu sai vai trò của CDK: CDK là để VIẾT hạ tầng, không phải để triển khai template có sẵn. Và "dùng lại mã JavaScript làm user data" là nhầm lẫn hai lớp hoàn toàn khác nhau — user data là script khởi động chạy bên trong EC2 instance, không liên quan gì tới việc định nghĩa hạ tầng. Lập trình viên vẫn phải viết CloudFormation template bằng tay, tức là nỗi lo ban đầu của họ không được giải quyết.

• B (dùng AWS SAM với serverless transform, thêm mã JS/TS làm metadata vào template, CodeBuild dựng và xuất ra CloudFormation template) — SAM là phần mở rộng của CloudFormation cho ứng dụng serverless, viết bằng YAML — nên lập trình viên vẫn phải học cú pháp template, đúng thứ họ e ngại. Và "thêm mã vào metadata của template" không phải cách SAM hoạt động: metadata là thông tin bổ sung, không phải nơi định nghĩa tài nguyên.

• D (dùng công cụ cấp phát tài nguyên của bên thứ ba trong CodeBuild, điều phối bằng CodePipeline, dùng CloudFormation để triển khai) — mơ hồ và đi ngược mục tiêu chuẩn hoá. Đưa một công cụ ngoài vào nghĩa là lập trình viên lại phải học công cụ đó — có thể chính là một DSL mới, đúng điều họ muốn tránh. Nó cũng thêm một thành phần phải bảo trì mà AWS đã có lời giải sẵn.

Ghi nhớ

⚠ Bốn cách định nghĩa hạ tầng trên AWS — bảng phải thuộc: | Công cụ | Ngôn ngữ | Đặc điểm | |---|---|---| | CloudFormation | YAML/JSON | nền tảng, mọi thứ khác đều sinh ra nó | | CDK | TypeScript, Python, Java, C#, Go | ngôn ngữ lập trình đầy đủ, sinh ra CloudFormation | | SAM | YAML (mở rộng CFN) | tối giản cho serverless | | Terraform | HCL | đa nhà cung cấp, không thuộc AWS |

Từ khoá nhận diện:

"developers know JavaScript/TypeScript" → CDK "don't want to learn a domain-specific language" → CDK "want language features like looping" → CDK "SAM" khi lập trình viên ngại YAML → vẫn là YAML, không giải quyết "reuse code as instance user data" → nhầm lớp, user data chạy trong máy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Template sinh ra đúng chưa | cdk synth rồi đọc YAML đầu ra | | Thay đổi sẽ ảnh hưởng gì | cdk diff — đặc biệt chú ý tài nguyên bị thay thế | | Có tạo ra tài nguyên thừa không | đếm tài nguyên trong template sinh ra |

Và một lời khuyên: hãy chạy cdk diff và đọc kỹ phần tài nguyên bị thay thế trước mỗi lần triển khai. Đây là nơi sức mạnh của CDK trở thành rủi ro: một thay đổi trông vô hại trong mã TypeScript — đổi tên một biến dùng để đặt id của construct, chẳng hạn — có thể khiến CDK sinh ra một logical ID khác, và CloudFormation hiểu điều đó là xoá tài nguyên cũ, tạo tài nguyên mới. Với một bucket S3 hay một cơ sở dữ liệu, đó là mất dữ liệu. Bản diff của mã nguồn không hề gợi ý điều đó; chỉ có bản diff của CloudFormation mới nói ra, và nó nói rất rõ ràng nếu bạn đọc.

Đáp án

C — Dùng S3 static website cho ứng dụng web, lưu video tải lên trong bucket S3, dùng S3 event notification đẩy sự kiện vào SQS, xử lý hàng đợi bằng Lambda gọi API của Amazon Rekognition để phân tích khuôn mặt.

Vì sao đúng

Đề đòi giảm công vận hành bằng cách dùng dịch vụ có quản lý ở mọi chỗ có thể. Kiến trúc hiện tại có bốn thành phần tự quản, và phương án C thay cả bốn.

⚠ Điểm mấu chốt: thay phần mềm nhận diện tự viết bằng Rekognition là khoản giảm công vận hành LỚN NHẤT:

Phần mềm nhận diện tự viết
        ↓
    Phải tự huấn luyện, tự cập nhật mô hình, tự vận hành máy có GPU
    Phải tự lo độ chính xác, tự lo quy mô
        ↓
Amazon Rekognition
        ↓
    Gọi API, trả kết quả — AWS lo mô hình và hạ tầng
        ↓
    → đây chính là nghĩa của "AWS managed services where possible"

Đề nói phần mềm hiện tại làm facial analysis — đúng năng lực cốt lõi của Rekognition, nên không có lý do giữ bản tự viết.

import boto3
rekognition = boto3.client('rekognition')

def handler(su_kien, ngu_canh):
    for ban_ghi in su_kien['Records']:
        th = json.loads(ban_ghi['body'])['Records'][0]['s3']
        ket_qua = rekognition.detect_faces(
            Image={'S3Object': {'Bucket': th['bucket']['name'],
                                'Name': th['object']['key']}},
            Attributes=['ALL'])
        luu_ket_qua(ket_qua['FaceDetails'])

⚠ Rekognition xử lý VIDEO theo cách bất đồng bộ, khác với ảnh:

Ảnh: DetectFaces — gọi và nhận kết quả ngay

Video: StartFaceDetection → nhận JobId
        ↓
    Rekognition xử lý trong nền, gửi thông báo qua SNS khi xong
        ↓
    GetFaceDetection với JobId để lấy kết quả
        ↓
    → cần thiết kế bất đồng bộ, không chờ trong Lambda

Vì clip video có thể dài, đây là chi tiết quan trọng khi triển khai thật.

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

• A (S3 static website, S3 event → SQS, xử lý bằng ECS Fargate chạy phần mềm nhận diện TỰ VIẾT) — đây là phương án gần nhất và nó đã hiện đại hoá gần hết kiến trúc: S3 cho web và video, SQS làm bộ đệm, Fargate bỏ được việc quản lý EC2. Nhưng nó giữ lại phần mềm nhận diện tự viết, tức là giữ lại đúng thành phần tốn công vận hành nhất: mô hình phải huấn luyện và cập nhật, phụ thuộc thư viện phải vá, độ chính xác phải tự đánh giá, và tài nguyên tính toán phải tự điều chỉnh. Đề nói "using AWS managed services where possible" — và ở đây rõ ràng là có thể. Fargate cũng đắt hơn Lambda cho tải theo sự kiện, ngắt quãng.

• B (như A nhưng dùng ECS với launch type EC2) — tệ hơn A ở đúng một điểm: EC2 launch type nghĩa là bạn quay lại quản lý các instance trong cluster — vá lỗi, co giãn, giám sát dung lượng. Đó là bước lùi so với chính mục tiêu của đề.

• D (lưu video trong EFS, mount vào EC2 cho ứng dụng web, xử lý bằng Lambda gọi Rekognition) — đúng ở vế Rekognition nhưng sai ở vế lưu trữ và phục vụ. Giữ EC2 cho ứng dụng web là giữ lại thứ đề muốn bỏ. Và EFS đắt hơn S3 nhiều lần cho việc lưu trữ tệp media chỉ đọc; S3 mới là nơi đúng cho object lớn, có tích hợp sẵn event notification, lifecycle và CloudFront.

Ghi nhớ

⚠ Bốn dịch vụ AI có quản lý thay cho mô hình tự viết — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Rekognition | ảnh và video: khuôn mặt, vật thể, văn bản, kiểm duyệt | | Transcribe | giọng nói → văn bản | | Comprehend | phân tích văn bản, thực thể, cảm xúc | | Textract | trích xuất văn bản và bảng từ tài liệu |

Từ khoá nhận diện:

"facial analysis" / "image recognition" → Rekognition "reduce operational overhead using managed services" → thay mọi thành phần tự viết "custom recognition software" trong phương án → dấu hiệu phương án chưa tối ưu "EFS để lưu video" → đắt hơn S3 nhiều, S3 mới đúng "static website" → S3, không cần EC2

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí Rekognition | tính theo số ảnh hoặc số phút video — ước lượng trước | | Có tin nhắn hỏng không | độ sâu dead-letter queue | | Độ chính xác có đủ không | so kết quả với tập mẫu đã gán nhãn thủ công |

Và một lời khuyên: hãy ước lượng chi phí Rekognition theo khối lượng thật trước khi chuyển đổi, và đặt cảnh báo ngân sách cho nó. Đây là chỗ chuyển sang dịch vụ có quản lý gây bất ngờ về chi phí: mô hình tự viết chạy trên máy bạn đã trả tiền, nên chi phí biên của việc phân tích thêm một video gần như bằng không — bạn quen với việc xử lý bao nhiêu cũng được. Rekognition tính tiền theo từng phút video hoặc từng ảnh, nên một đợt người dùng tải lên tăng đột biến chuyển thẳng thành một hoá đơn tăng đột biến. Không có gì hỏng, không có hạn mức nào bị chạm, dịch vụ vẫn phục vụ hoàn hảo mọi yêu cầu — và đó chính là vấn đề.

Đáp án

A, C, F — ba thay đổi cứu hiệu năng của cụm HPC hơn 800 node:

• A — Thay Amazon EFS bằng Amazon FSx for Lustre.
• C — Đảm bảo cụm HPC nằm trong một Availability Zone duy nhất.
• F — Bật Elastic Fabric Adapter (EFA) trên loại instance được hỗ trợ.

Vì sao đúng

Đề mô tả tightly coupled workload với hơn 800 instance dùng chung một hệ thống tệp. Ở quy mô đó, cả hai nút thắt — lưu trữ và mạng — đều đã chạm trần.

⚠ Điểm mấu chốt: EFS và Lustre khác nhau về BẬC thông lượng, không phải về vài phần trăm:

Amazon EFS
        ↓
    Hệ thống tệp NFS đa mục đích, thông lượng theo GB lưu trữ hoặc provisioned
        ↓
    Với 800 client đọc ghi đồng thời → nghẽn ở tầng metadata và thông lượng

FSx for Lustre
        ↓
    Hệ thống tệp SONG SONG, dựng riêng cho HPC
        ↓
    Thông lượng tới hàng trăm GB/s, độ trễ dưới mili giây
        ↓
    → chênh nhau hàng chục lần, không phải vài chục phần trăm

C — vì sao một AZ. Với workload gắn kết chặt, các node trao đổi tin nhắn liên tục. Lưu lượng liên AZ thêm hàng trăm micro giây cho mỗi chặng — mức phạt khổng lồ khi nhân với hàng triệu tin nhắn. Đây cũng là điều kiện bắt buộc: cluster placement group và EFA đều chỉ hoạt động trong một AZ.

F — vì sao EFA. EFA cho phép ứng dụng nói thẳng với phần cứng mạng, bỏ qua kernel — đó là chỗ độ trễ giảm mạnh nhất cho MPI.

aws fsx create-file-system --file-system-type LUSTRE \
  --storage-capacity 24000 --subnet-ids subnet-hpc-1a \
  --lustre-configuration DeploymentType=PERSISTENT_2,PerUnitStorageThroughput=1000

⚠ FSx for Lustre liên kết được với S3 — đó là mẫu chuẩn của HPC:

Dữ liệu gốc nằm trong S3 (rẻ, bền)
        ↓
    Tạo Lustre file system liên kết với bucket đó
        ↓
    Lustre nạp dữ liệu theo nhu cầu, xử lý ở tốc độ cao
        ↓
    Ghi kết quả ngược về S3, rồi xoá file system
        ↓
    → chỉ trả tiền Lustre trong thời gian tính toán

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

• D (thay EFS bằng nhiều FSx for Windows File Server) — đây là phương án gần nhất và nó đúng ở chỗ nhận ra phải rời khỏi EFS. Nhưng nó chọn sai loại FSx. FSx for Windows File Server phục vụ giao thức SMB cho máy Windows, trong khi đề nói rõ cụm chạy Linux. Ngoài ra nó không phải hệ thống tệp song song: nó tối ưu cho chia sẻ tệp doanh nghiệp, không cho hàng trăm node cùng đọc ghi một tập dữ liệu ở tốc độ HPC. Chia thành "nhiều" file system càng làm phức tạp thêm mà không giải quyết được vấn đề thông lượng gốc. Đây là bẫy kiểm tra xem có phân biệt được bốn biến thể của FSx hay không.

• E (triển khai cụm trên nhiều Availability Zone) — đi ngược trực tiếp mục tiêu. Trải nhiều AZ làm tăng độ trễ giữa các node, và với workload gắn kết chặt thì đó là điều tệ nhất có thể làm. Nó cũng loại trừ cluster placement group và EFA, vốn chỉ hoạt động trong một AZ.

• B (gắn nhiều elastic network interface để giảm độ trễ) — hiểu sai cơ chế. Thêm ENI tăng số địa chỉ IP và có thể tăng tổng băng thông trong một số trường hợp, nhưng KHÔNG giảm độ trễ. Độ trễ do đường đi vật lý và do ngăn xếp mạng của hệ điều hành quyết định — thứ mà EFA giải quyết bằng cách bỏ qua kernel, còn ENI thì không đụng tới.

Ghi nhớ

⚠ Bốn biến thể FSx — bảng phải thuộc: | Biến thể | Giao thức | Dành cho | |---|---|---| | FSx for Lustre | POSIX, Lustre | HPC, machine learning, thông lượng cực cao | | FSx for Windows File Server | SMB | Windows, cần ACL và AD | | FSx for NetApp ONTAP | NFS + SMB + iSCSI | môi trường lai đa giao thức | | FSx for OpenZFS | NFS | thay thế máy chủ ZFS tại chỗ |

Từ khoá nhận diện:

"HPC" / "tightly coupled" + hệ thống tệp dùng chung → FSx for Lustre "low latency inter-instance" → EFA + cluster placement group + một AZ "multiple Availability Zones" cho HPC gắn kết chặt → LUÔN SAI, tăng độ trễ "thêm ENI để giảm độ trễ" → SAI, ENI không giảm độ trễ "FSx for Windows" cho cụm Linux → SAI giao thức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hệ thống tệp có nghẽn không | chỉ số throughput của FSx so với mức đã cấp | | EFA có bật thật không | fi_info -p efa trên instance | | Độ trễ giữa node | OSU micro-benchmarks hoặc ib_write_lat |

Và một lời khuyên: hãy cấp thông lượng cho FSx for Lustre theo nhu cầu tổng của cả cụm, đừng theo dung lượng dữ liệu. Đây là chỗ hiệu năng HPC bị bóp nghẹt một cách khó hiểu: thông lượng của Lustre được cấp theo đơn vị MB/s cho mỗi TiB dung lượng, nên một hệ thống tệp vừa đủ chỗ chứa dữ liệu có thể hoàn toàn không đủ thông lượng cho 800 node cùng đọc. Không có lỗi nào xuất hiện — các job vẫn chạy, vẫn cho kết quả đúng, chỉ là chậm hơn nhiều lần so với khả năng của CPU đang chờ dữ liệu. Chỉ số cần nhìn là thông lượng thực tế của file system so với mức đã cấp, và nếu nó cắm trần suốt thì bạn đang trả tiền cho hàng trăm node để chúng ngồi đợi đĩa.

Đáp án

A — Cấu hình CodePipeline với giai đoạn triển khai dùng AWS CodeDeploy theo kiểu blue/green; sau khi triển khai bản mới thì theo dõi hiệu năng và bảo mật, dùng tính năng rollback của CodeDeploy nếu có vấn đề.

Vì sao đúng

Đề nêu hai yêu cầu then chốt cho một ứng dụng tài chính: giảm downtime khi cập nhật và có cơ chế lùi lại nhanh.

⚠ Điểm mấu chốt: CodeDeploy blue/green cho EC2 chuyển tải bằng cách đổi TARGET GROUP của ALB — không phụ thuộc DNS:

Auto Scaling group xanh (blue) đang nhận tải qua target group A
        ↓
    CodeDeploy dựng Auto Scaling group mới (green) với bản mới
        ↓
    Chờ mọi instance qua health check
        ↓
    ALB chuyển listener từ target group A sang target group B
        ↓
    → chuyển tức thì, không chờ TTL của DNS
        ↓
    Có sự cố → chuyển ngược listener → về blue trong vài giây

Đây là điểm mạnh so với các cách dựa trên DNS: không có cache nào phải chờ hết hạn.

CodeDeploy còn cho phép tự động lùi lại theo CloudWatch alarm:

aws deploy update-deployment-group \
  --application-name app-tai-chinh \
  --current-deployment-group-name prod \
  --auto-rollback-configuration enabled=true,events=DEPLOYMENT_FAILURE,DEPLOYMENT_STOP_ON_ALARM \
  --alarm-configuration enabled=true,alarms=[{name=TyLeLoi5xx}]

⚠ Đừng chấm dứt môi trường cũ ngay — đặt thời gian chờ trước khi huỷ:

CodeDeploy cho chọn: huỷ instance cũ ngay, hoặc chờ N phút/giờ
        ↓
    Huỷ ngay → tiết kiệm tiền, nhưng mất khả năng lùi lại
        ↓
    → với ứng dụng tài chính, luôn để chờ ít nhất vài giờ

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

• D (CodePipeline với giai đoạn dùng CloudFormation quản lý stack riêng cho testing và production; theo dõi rồi đẩy bản cập nhật nếu có vấn đề) — đây là phương án gần nhất và có hai stack riêng cho hai môi trường là thực hành tốt. Nhưng nó không đáp ứng yêu cầu lùi lại nhanh. Câu "push updates if issues arise" mô tả việc triển khai một bản sửa mới — tức là phải viết mã, build, chạy lại pipeline, trong khi sự cố đang diễn ra trên hệ thống xử lý giao dịch tài chính. Đó là cách chậm nhất có thể để phản ứng. Blue/green cho phép quay về trạng thái tốt đã biết trong vài giây, không cần biết nguyên nhân là gì.

• B (CodePipeline triển khai qua AWS OpsWorks với rolling deployment, quay về cấu hình stack trước nếu cần) — hai vấn đề. Rolling deployment ghi đè lên các instance đang chạy theo từng lô, nên lùi lại đòi chạy ngược cả quá trình — chậm, và trong lúc đó hệ thống ở trạng thái hỗn hợp hai phiên bản. Ngoài ra AWS OpsWorks đã ngừng hoạt động từ tháng 5/2024, nên đây là lựa chọn không còn triển khai được.

• C (CodePipeline triển khai qua Elastic Beanstalk với rolling update, theo dõi rồi TRIỂN KHAI LẠI thủ công bản cũ nếu có vấn đề) — cùng vấn đề với rolling update, và câu "manually redeploy the previous version" nói thẳng ra rằng việc lùi lại là thủ công và chậm. (Elastic Beanstalk có hỗ trợ blue/green bằng swap URL, nhưng phương án này không chọn cách đó.) Nó cũng đòi đóng gói lại ứng dụng theo mô hình Beanstalk, thay đổi lớn so với kiến trúc EC2 + ALB hiện có.

Ghi nhớ

⚠ Ba kiểu triển khai của CodeDeploy cho EC2 — bảng phải thuộc: | Kiểu | Cách làm | Lùi lại | |---|---|---| | In-place | cập nhật chính các instance đang chạy | chậm — phải triển khai lại | | Blue/green | dựng đội máy mới, chuyển target group | nhanh — chuyển ngược | | Rolling (qua ASG) | thay thế theo lô | chậm |

Từ khoá nhận diện:

"minimize downtime" + "quick rollback" → blue/green "EC2 behind ALB" → CodeDeploy blue/green với target group | "manually redeploy the previous version" → SAI, đó không phải lùi lại nhanh "push updates if issues arise" → SAI, đó là sửa lỗi chứ không phải lùi lại "OpsWorks" → dịch vụ đã ngừng (5/2024)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lùi lại có tự động không | kiểm auto-rollback-configuration và alarm gắn kèm | | Môi trường cũ còn bao lâu | thiết lập "terminate original instances" trong deployment group | | Health check có đủ sâu không | endpoint kiểm tra phải chạm tới CSDL, không chỉ trả 200 |

Và một lời khuyên: hãy gắn CloudWatch alarm vào deployment group để CodeDeploy tự lùi lại, đừng dựa vào việc con người phát hiện kịp. Đây là khoảng cách giữa lý thuyết và thực tế của mọi kế hoạch triển khai: blue/green cho bạn khả năng quay về trong vài giây, nhưng khả năng đó chỉ có giá trị nếu ai đó nhận ra vấn đề trong vài giây. Với một bản phát hành lúc 2 giờ sáng, hoặc một lỗi chỉ biểu hiện thành tỷ lệ giao dịch thất bại tăng thêm hai phần trăm, con người không phải là cơ chế phát hiện đáng tin. Một alarm trên tỷ lệ lỗi 5xx hoặc trên độ trễ p99 thì có — và nó không cần ai thức.

Đáp án

B — Chuyển bảng sang chế độ on-demand để tính tiền theo từng request đọc và ghi.

Vì sao đúng

Đề mô tả một hình thái tải rất cụ thể: đỉnh chỉ vài giờ mỗi cuối tuần, gấp đôi mức thường ngày, và dung lượng hiện đang được cấp theo mức đỉnh cao nhất.

⚠ Điểm mấu chốt: provisioned tính tiền theo dung lượng CẤP, không theo dung lượng DÙNG:

Cấp WCU theo đỉnh cuối tuần
        ↓
    Trả tiền mức đó cả 168 giờ mỗi tuần
        ↓
    Nhưng chỉ dùng tới mức đó vài giờ
        ↓
    → phần lớn hoá đơn là dung lượng không dùng

On-demand
        ↓
    Tính tiền theo từng request thực tế
        ↓
    → giờ thấp điểm trả ít, giờ cao điểm trả nhiều, không lãng phí

Vì sao on-demand mà không phải auto scaling. Auto scaling phản ứng theo CloudWatch alarm, mất vài phút mới điều chỉnh — với đỉnh tải kéo dài chỉ vài giờ và tăng đột ngột, nó vừa chậm vừa vẫn phải giữ mức nền. On-demand hấp thụ tức thì mà không cần cấu hình gì.

aws dynamodb update-table --table-name ung-dung \
  --billing-mode PAY_PER_REQUEST

⚠ On-demand không phải lúc nào cũng rẻ hơn — điểm hoà vốn nằm ở mức tận dụng:

On-demand đắt hơn provisioned khoảng 6-7 lần cho mỗi đơn vị request
        ↓
    Nên nó rẻ hơn khi mức tận dụng dung lượng cấp DƯỚI khoảng 15-20%
        ↓
    Tải đều đặn, đoán được → provisioned + auto scaling rẻ hơn
    Tải lệch mạnh, đỉnh ngắn → on-demand rẻ hơn
        ↓
    → trường hợp của đề rơi rõ vào vế thứ hai

Đề cũng nói đây là môi trường phát triển sắp lên production — thêm một lý do chọn on-demand: chưa có dữ liệu lịch sử đủ tin cậy để cấp phát chính xác.

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

• C (mua reserved RCU/WCU và dùng Application Auto Scaling để khớp tải tăng lúc cao điểm) — đây là phương án gần nhất và nó kết hợp hai kỹ thuật tối ưu chi phí có thật: reserved capacity giảm giá cho phần nền, auto scaling lo phần đỉnh. Trong nhiều trường hợp đó là cấu hình tối ưu. Nhưng nó không hợp với đề ở hai điểm. Reserved capacity của DynamoDB là cam kết một hoặc ba năm — đặt lên một ứng dụng chưa phát hành production, chưa biết hình thái tải thật, là cam kết mù. Và auto scaling phản ứng chậm với đỉnh ngắn, nên vẫn phải đặt mức nền cao để an toàn, làm giảm phần tiết kiệm.

• A (on-demand + DAX) — nửa đầu đúng, nhưng DAX là cache cho ĐỌC, trong khi đề nói rõ "write operations are significant and take up most of the traffic". Thêm một cụm DAX là thêm chi phí cố định hằng giờ cho một thứ không giải quyết được nút thắt. Với tải nghiêng về ghi, DAX gần như vô dụng.

• D (giảm provisioned read capacity cho khớp đỉnh mới và thêm DAX) — sai hướng hoàn toàn. Đề nói ghi là phần lớn lưu lượng, nên chỉnh read capacity không chạm tới chi phí chính. Và lại thêm DAX, vốn không giúp gì cho ghi. Phương án này tối ưu đúng thứ không phải vấn đề.

Ghi nhớ

⚠ Hai chế độ dung lượng DynamoDB — bảng phải thuộc: | | Provisioned | On-demand | |---|---|---| | Tính tiền | theo dung lượng CẤP | theo request THỰC TẾ | | Hợp với | tải đều, đoán được | tải lệch, đỉnh ngắn, mới bắt đầu | | Co giãn | qua auto scaling (chậm vài phút) | tức thì | | Giá mỗi đơn vị | rẻ hơn ~6-7 lần | đắt hơn nhưng không lãng phí | | Reserved capacity | có | không |

Từ khoá nhận diện:

"spiky / unpredictable traffic" → on-demand "steady predictable traffic" → provisioned (+ reserved nếu dài hạn) "write-heavy" → DAX không giúp gì "reserved capacity" cho ứng dụng chưa production → cam kết mù, rủi ro "DAX" → chỉ tăng tốc và giảm chi phí ĐỌC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mức tận dụng hiện tại | so ConsumedWriteCapacityUnits với ProvisionedWriteCapacityUnits | | Có bị throttle không | WriteThrottleEvents | | Chế độ nào rẻ hơn | tính chi phí cả hai chế độ với chính số liệu tiêu thụ của bạn |

Và một lời khuyên: hãy tính lại chi phí của cả hai chế độ bằng số liệu tiêu thụ thật sau vài tuần chạy production, đừng coi quyết định hôm nay là vĩnh viễn. On-demand là lựa chọn đúng khi bạn chưa biết hình thái tải — nhưng hình thái tải của một ứng dụng thường ổn định lại sau vài tháng, và khi đó provisioned với auto scaling có thể rẻ hơn nhiều lần. Không có gì nhắc bạn xem lại: bảng vẫn chạy hoàn hảo, không có throttle, không có cảnh báo, và dòng chi phí DynamoDB chỉ tăng đều đặn theo lưu lượng đúng như mong đợi. Khoản chênh lệch chỉ hiện ra nếu có người chủ động đặt hai con số cạnh nhau.

Đáp án

C, E — hai bước để chia sẻ một mạng chung cho nhiều tài khoản:

• C — Bật resource sharing từ tài khoản quản lý của AWS Organizations.
• E — Tạo resource share trong AWS Resource Access Manager ở tài khoản vận hành, chọn OU sẽ dùng mạng chung, và chọn từng SUBNET để đưa vào resource share.

Vì sao đúng

Đề mô tả chính xác mô hình VPC sharing: một đội sở hữu và quản lý mạng, các đội khác dựng tài nguyên trong đó nhưng không sửa được mạng.

⚠ Điểm mấu chốt: chia sẻ SUBNET, không phải chia sẻ VPC — và đó là chỗ ranh giới quyền nằm:

Tài khoản vận hành (chủ VPC)
        ↓
    Chia sẻ từng subnet qua RAM
        ↓
Tài khoản tham gia (participant)
        ↓
    ĐƯỢC: chạy EC2, RDS, Lambda, ALB trong subnet đó
    KHÔNG ĐƯỢC: sửa subnet, route table, NACL, gateway, peering
        ↓
    → đúng nghĩa "individual accounts cannot manage their own networks"

Vì sao cần bước C. Chia sẻ với OU hoặc cả tổ chức chỉ khả dụng sau khi tài khoản quản lý bật tính năng tích hợp giữa RAM và Organizations. Không bật thì chỉ chia sẻ được cho từng tài khoản một, theo id.

# Ở tài khoản quản lý của Organizations
aws ram enable-sharing-with-aws-organization

# Ở tài khoản vận hành
aws ram create-resource-share --name mang-chung \
  --resource-arns arn:aws:ec2:ap-southeast-1:111122223333:subnet/subnet-a \
                  arn:aws:ec2:ap-southeast-1:111122223333:subnet/subnet-b \
  --principals arn:aws:organizations::111122223333:ou/o-abc/ou-def

⚠ Bên tham gia không nhìn thấy tài nguyên của bên khác trong cùng subnet:

Nhiều tài khoản dùng chung một subnet
        ↓
    Mỗi tài khoản chỉ thấy và quản lý tài nguyên CỦA MÌNH
        ↓
    Nhưng chúng dùng chung dải IP → hết IP là ảnh hưởng tất cả
        ↓
    → chủ VPC phải theo dõi số IP còn lại của từng subnet

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

• B (tạo resource share trong RAM ở tài khoản vận hành, chọn OU, rồi chọn từng PREFIX LIST để đưa vào resource share) — đây là phương án gần nhất và nó chỉ khác E đúng một danh từ: cùng dịch vụ, cùng tài khoản, cùng cách chọn OU. Nhưng nó chia sẻ prefix list thay vì subnet. Prefix list là danh sách dải CIDR dùng lại trong security group và route table — chia sẻ nó cho phép các tài khoản khác tham chiếu cùng một danh sách IP, nhưng không cho họ dựng tài nguyên trong mạng của bạn. Đây là bẫy kiểm tra xem có biết chính xác loại tài nguyên nào cần chia sẻ để đạt được VPC sharing.

• A (tạo VPC riêng trong mỗi tài khoản với cùng CIDR và subnet, rồi peering với VPC của tài khoản vận hành) — sai về kỹ thuật và về mục tiêu. VPC peering không cho phép hai VPC có CIDR chồng lấn — mà phương án này lại yêu cầu chúng dùng cùng dải CIDR, nên peering không thể thiết lập. Ngoài ra mỗi tài khoản vẫn có VPC riêng để quản, trái với yêu cầu tập trung việc quản mạng.

• D (tạo transit gateway ở tài khoản vận hành và bật định tuyến bắc cầu) — transit gateway nối các VPC riêng biệt lại với nhau, nghĩa là mỗi tài khoản vẫn có VPC của mình và vẫn tự quản mạng của mình. Đó là mô hình khác hẳn VPC sharing, và không đáp ứng yêu cầu "individual accounts cannot manage their own networks".

Ghi nhớ

⚠ Bốn thứ chia sẻ được qua AWS RAM — bảng phải thuộc: | Tài nguyên | Cho phép bên nhận | |---|---| | Subnet của VPC | dựng tài nguyên trong mạng của bạn | | Transit gateway | gắn VPC của họ vào | | Route 53 Resolver rule | dùng chung cấu hình DNS | | License Manager, Aurora DB cluster, prefix list, capacity reservation | tuỳ loại |

Từ khoá nhận diện:

"share a common network across accounts" → RAM chia sẻ subnet (VPC sharing) "individual accounts cannot manage their own networks" → VPC sharing, không phải transit gateway "chia sẻ prefix list" khi cần dựng tài nguyên → SAI loại tài nguyên "peering với cùng CIDR" → LUÔN SAI, peering cấm CIDR chồng lấn "enable sharing with AWS Organizations" → bước bắt buộc để chia sẻ theo OU

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bên nhận đã chấp nhận chưa | aws ram get-resource-share-associations | | Subnet có hiện ở tài khoản kia không | describe-subnets từ tài khoản tham gia | | IP còn lại bao nhiêu | AvailableIpAddressCount của subnet |

Và một lời khuyên: hãy giám sát AvailableIpAddressCount của từng subnet dùng chung và đặt cảnh báo từ sớm. Đây là chỗ VPC sharing gây sự cố theo cách khó lần ra nhất: nhiều đội cùng dựng tài nguyên trong một subnet, mỗi đội chỉ nhìn thấy tài nguyên của mình, và không ai có bức tranh tổng thể về số địa chỉ còn lại. Khi subnet cạn IP, triệu chứng xuất hiện ở phía đội xui xẻo nhất — một Auto Scaling group không khởi động được máy mới, một task Fargate mãi ở trạng thái pending — kèm theo thông báo lỗi nói về dung lượng chứ không nói về địa chỉ. Đội đó sẽ đi tìm nguyên nhân trong tài khoản của họ, nơi mọi thứ đều đúng, vì nguyên nhân nằm ở một tài nguyên họ không sở hữu và không nhìn thấy.