Chạy container cho nhóm nhỏ mà không phát sinh thêm công việc vận hành Kubernetes

Tình huống và yêu cầu

Bạn tư vấn cho một nhóm ba người đã đóng gói web API và các worker xử lý nền vào container. Họ cần mạng riêng, tự động phục hồi và khả năng mở rộng, nhưng không cần API Kubernetes, quyền truy cập máy chủ chuyên biệt hay GPU.

Mục tiêu của nhóm là giảm công việc hạ tầng, chứ không chỉ chuyển các lệnh Docker từ laptop lên EC2. Dữ liệu lưu bền phải tồn tại khi task được thay thế, và quyền của ứng dụng phải được giới hạn chặt chẽ.

Đây là một quyết định lựa chọn nền tảng giả định.

Các phương án và quyết định

Chọn ECS với Fargate, sau khi kiểm tra yêu cầu runtime và chi phí dựa trên mức sử dụng tài nguyên mang tính đại diện.

Mô hình tư duy và luồng xử lý

ECS quyết định cách chạy task; Fargate cung cấp tài nguyên tính toán; ECR lưu trữ image.

Digest của image từ CI → ECR → Định nghĩa task ECS → Các task Fargate → Lưu lượng web qua ALB hoặc công việc worker trong hàng đợi

Ba dịch vụ này bổ trợ cho nhau, không phải những tên gọi khác nhau của cùng một chức năng.

Cơ chế cốt lõi

Khai báo CPU, bộ nhớ, health check và tham chiếu image bất biến trong định nghĩa task. Đặt các task trong những subnet dự kiến, với quyền truy cập đến các endpoint cần thiết cho image, log, secret và ứng dụng.

Execution role hỗ trợ các hoạt động khởi động task như tải image và gửi log theo cấu hình. Task role cấp quyền gọi AWS API cho ứng dụng. Gộp cả hai vào một role quản trị viên sẽ làm mất đi một ranh giới hữu ích.

Lưu trạng thái cần tồn tại lâu dài trong các dịch vụ phù hợp thay vì hệ thống tệp tạm thời của task. Mở rộng API dựa trên metric dịch vụ có ý nghĩa và mở rộng worker theo lượng công việc tồn đọng hoặc thời gian chờ, đồng thời tuân thủ giới hạn năng lực của cơ sở dữ liệu và hệ thống phía sau.

ECS service auto scaling sử dụng Application Auto Scaling để thay đổi số lượng task. Trong Kubernetes, HPA thay đổi số bản sao pod, còn các cơ chế cấp năng lực node cung cấp nơi để lập lịch chạy chúng; có thêm pod đang chờ không đồng nghĩa với có thêm năng lực sử dụng được. Concurrency của Lambda là một ranh giới tiếp nhận/mở rộng khác, không cùng đơn vị với số lượng task. Thiết lập quy mô cho từng cơ chế kiểm soát theo hạn mức năng lực của hệ thống phía sau.

Sử dụng các cơ chế kiểm soát rollback triển khai và health check được hỗ trợ. Nhóm vẫn chịu trách nhiệm về image, thư viện, cấu hình ứng dụng, IAM và chính sách mạng. Fargate loại bỏ việc quản lý máy chủ, không loại bỏ trách nhiệm bảo mật ứng dụng.

Kiểm chứng và khi nào cần đổi phương án

• Dừng task và xác nhận việc thay thế không làm mất công việc cần được lưu bền.
• Triển khai một image không vượt qua health check và kiểm tra hành vi rollback.
• Thử nghiệm retry và mở rộng worker mà không làm quá tải các thành phần phụ thuộc.

Yêu cầu về hệ sinh thái Kubernetes có thể khiến EKS phù hợp hơn; yêu cầu máy chủ chuyên biệt có thể khiến năng lực EC2 phù hợp hơn. Một ứng dụng web đơn giản, nằm trong phạm vi hỗ trợ có thể phù hợp với Beanstalk hoặc nền tảng web được quản lý khác sau khi kiểm tra khả năng và mức độ sẵn có hiện tại. Tránh bổ sung các sản phẩm hybrid hoặc Kubernetes khi không có nhu cầu tương ứng.

Điểm cần nhớ và tài liệu AWS

• Điều phối, tính toán và lưu trữ image là những vai trò khác nhau.
• Fargate là một lựa chọn tài nguyên tính toán, không phải một bộ điều phối riêng.
• Execution role và task role phục vụ các luồng cấp quyền khác nhau.
• Đóng gói vào container không có nghĩa là có thể bỏ đi trạng thái ứng dụng.
• Giảm công việc vận hành máy chủ không bảo đảm tổng chi phí thấp hơn.

AWS: Các kiểu khởi chạy ECS

Dịch vụ trong bài: ECS · EKS · Fargate · ECR · Application Auto Scaling

Xử lý tệp tải lên đôi khi mất tới bốn mươi phút

Tình huống và yêu cầu

Bạn xây dựng chức năng chuẩn hóa tài liệu cho một cổng thông tin khách hàng. Người dùng tải tệp lên và có thể kiểm tra trạng thái sau; quá trình xử lý mất từ hai đến bốn mươi phút. Bước xử lý dài nhất không thể chia thành các thao tác có checkpoint độc lập. Nhu cầu không đều, nên việc duy trì máy chủ worker thường xuyên nhàn rỗi không hấp dẫn.

Các công việc đã tiếp nhận phải tồn tại qua những lần triển khai web và hỗ trợ retry an toàn. Bạn cần giới hạn concurrency, lưu bền đầu vào/đầu ra và một mô hình tính toán có thể xử lý tệp hợp lệ mất nhiều thời gian nhất.

Đây là workload giả định; thời lượng công việc là dữ kiện đầu vào được giả định.

Các phương án và quyết định

Tách việc tiếp nhận tệp tải lên khỏi việc xử lý. Dùng các hàm chạy ngắn để xác thực và task ECS cho công việc chạy lâu, được điều phối bằng workflow Standard Step Functions khi hữu ích.

Mô hình tư duy và luồng xử lý

Yêu cầu web gửi công việc vào nơi lưu bền; nó không quyết định vòng đời của worker.

Client → Tải lên S3 → Sự kiện/hàng đợi → Đăng ký công việc có tính idempotent → Workflow → Task tính toán → Đầu ra trên S3 và trạng thái công việc

Tải lên thành công và xử lý tài liệu thành công là hai trạng thái riêng biệt được hiển thị cho người dùng.

Cơ chế cốt lõi

Sử dụng URL tải lên có phạm vi và thời hạn giới hạn. Nhận diện công việc bằng định danh đầu vào ổn định, bao gồm phiên bản object khi phù hợp. Sự kiện S3 và thông điệp hàng đợi có thể được gửi lặp lại, vì vậy hãy đăng ký công việc có điều kiện và bảo đảm việc công bố đầu ra có tính idempotent.

Xác định thời điểm xác nhận thông điệp điều phối: chỉ sau khi đã thiết lập workflow lưu bền hoặc cơ chế tương đương xác lập bên chịu trách nhiệm cho công việc. Nếu không, sự cố ở bộ điều phối có thể làm mất công việc hoặc khởi chạy các task trùng lặp không được kiểm soát.

Worker đọc đầu vào từ S3, ghi đầu ra có phiên bản và chỉ ghi nhận hoàn tất sau khi các kết quả bắt buộc đã được lưu bền. Cấu hình retry, timeout, báo lỗi và giới hạn concurrency theo năng lực thực tế của hệ thống phía sau.

Durable Lambda functions có thể tạo checkpoint cho các workflow nhiều bước được hỗ trợ và tiếp tục sau gián đoạn; thực thi bền vững không biến một bước tính toán nặng CPU chạy liên tục thành một lần gọi có thời lượng vô hạn. Chỉ chia tại những ranh giới lưu bền có ý nghĩa khi thuật toán hỗ trợ. Task ECS vẫn phù hợp hơn cho phép tính kéo dài không thể chia nhỏ này.

Lập kế hoạch hủy công việc và dọn dẹp task mồ côi. Workflow hết thời gian chờ không tự động hoàn tác các tác động bên ngoài của task. Không được nhầm đầu ra trung gian với kết quả đã hoàn tất.

Kiểm chứng và khi nào cần đổi phương án

• Gửi các sự kiện trùng lặp và xác minh chỉ có một công việc/kết quả về mặt logic.
• Dừng cưỡng bức worker giữa chừng và xác nhận retry an toàn hoặc có trạng thái lỗi rõ ràng.
• Xử lý một tệp mất bốn mươi phút đồng thời theo dõi tuổi thông điệp trong hàng đợi, giới hạn task và chi phí trên mỗi công việc hoàn tất.

Nếu mọi công việc hợp lệ đều nằm thoải mái trong giới hạn Lambda, một Lambda consumer đọc hàng đợi đơn giản hơn có thể là đủ. Đừng chia một phép tính không thể phân chia thành các bước giả tạo chỉ để che giấu lựa chọn runtime không tương thích.

Điểm cần nhớ và tài liệu AWS

• Tiếp nhận có lưu bền khác với hoàn tất.
• Một lần gọi Lambda thông thường không thể chạy phép tính bốn mươi phút không thể chia nhỏ.
• Xác nhận điều phối cần một ranh giới xác lập trách nhiệm được lưu bền.
• Việc gửi trùng lặp đòi hỏi xử lý công việc có tính idempotent.
• Trạng thái workflow không tự động đảo ngược các tác động bên ngoài.

AWS: Tích hợp dịch vụ Step Functions

Dịch vụ trong bài: S3 · SQS · Lambda · Step Functions · ECS

Ngăn timeout thanh toán làm cạn năng lực xử lý checkout

Tình huống và yêu cầu

Bạn duy trì chức năng checkout cho một nhà bán lẻ có nhà cung cấp thanh toán đôi khi bị timeout. Các lần retry trong SDK, ứng dụng và bộ xử lý yêu cầu cộng dồn cho đến khi pool kết nối web cạn kiệt.

Khách hàng có thể chấp nhận đơn hàng ở trạng thái chờ tối đa hai phút, nhưng một payment intent không được bị thu tiền hai lần. Bạn cần xử lý có lưu bền, retry có giới hạn và cách xác định kết quả của lần thu tiền bị mất phản hồi.

Đây là bài tập tích hợp thanh toán giả định.

Các phương án và quyết định

Lưu bền đơn hàng chờ và xử lý thanh toán bất đồng bộ. Hàng đợi cô lập thành phần phụ thuộc chậm; tính đúng đắn của thanh toán vẫn cần sự phối hợp giữa ứng dụng và nhà cung cấp.

Mô hình tư duy và luồng xử lý

Timeout có nghĩa là kết quả có thể chưa rõ, không nhất thiết là chưa có gì xảy ra.

Khóa checkout → Đơn hàng chờ và outbox → SQS → Worker → Nhà cung cấp với khóa thanh toán ổn định → Kết quả được lưu bền → Xóa thông điệp

Nếu nhà cung cấp đã thu tiền thành công nhưng phản hồi bị mất, quá trình phục hồi phải tìm ra lần thu tiền đó thay vì tạo một intent khác.

Cơ chế cốt lõi

Ghi đơn hàng và bản ghi outbox một cách nguyên tử, bằng mô hình giao dịch mà cơ sở dữ liệu hỗ trợ. Việc phát thông điệp có thể lặp lại, nên consumer phải xử lý được thông điệp trùng lặp. Đừng dựa vào hai thao tác độc lập kiểu “ghi cơ sở dữ liệu, rồi gửi vào hàng đợi” mà không có cơ chế phục hồi.

Dùng lại cùng một idempotency key của nhà cung cấp cho cùng một payment intent. Áp dụng timeout, exponential backoff có jitter và tổng hạn mức retry. Khi kết quả chưa rõ, truy vấn hoặc đối soát với bản ghi của nhà cung cấp theo những bảo đảm từ API của họ.

Sử dụng chuyển trạng thái đơn hàng có điều kiện để ngăn các worker xung đột ghi đè kết quả đã hoàn tất. Thiết lập hoặc gia hạn SQS visibility phù hợp và chỉ xóa thông điệp sau khi kết quả đã được lưu bền.

Dead-letter queue cần có bên chịu trách nhiệm và quy trình redrive. Thiết lập cảnh báo theo tuổi thông điệp cũ nhất và thời gian đơn hàng ở trạng thái chờ; hàng đợi rỗng không chứng minh mọi thanh toán đều thành công. Sắp thứ tự/khử trùng lặp của FIFO không bảo đảm thu tiền đúng một lần tại nhà cung cấp bên ngoài.

Kiểm chứng và khi nào cần đổi phương án

• Làm mất phản hồi của nhà cung cấp sau khi thu tiền thành công và xác minh việc đối soát.
• Cho worker gặp sự cố sau khi lưu kết quả nhưng trước khi xóa thông điệp.
• Thử nghiệm thông điệp trùng lặp và tình trạng nhà cung cấp ngừng hoạt động kéo dài, bao gồm cả những gì người dùng thấy sau hai phút.

Nếu nhà cung cấp không hỗ trợ tính idempotent hoặc tra cứu kết quả, retry tự động sẽ rủi ro hơn đáng kể và có thể cần đối soát thủ công. Nếu nghiệp vụ yêu cầu trạng thái thanh toán cuối cùng ngay lập tức, hãy xem xét lại hành vi khi xử lý đồng bộ thất bại thay vì hứa hẹn trải nghiệm bất đồng bộ tương tự.

Điểm cần nhớ và tài liệu AWS

• Hàng đợi tách biệt năng lực xử lý, không bảo đảm tính đúng đắn của giao dịch.
• Kết quả thanh toán chưa rõ cần được đối soát.
• Định danh intent ổn định ngăn retry trở thành giao dịch mua mới.
• Visibility timeout không có nghĩa là thực thi đúng một lần.
• Hạn mức retry phải tính đến mọi lớp có retry.

AWS: Visibility timeout của SQS

Dịch vụ trong bài: SQS · Lambda · DynamoDB

Gửi sự kiện đơn hàng đến các nhóm độc lập mà không để sự cố của họ ảnh hưởng lẫn nhau

Tình huống và yêu cầu

Bạn thiết kế việc gửi sự kiện đơn hàng cho các nhóm email, phân tích và xử lý giao hàng. Mỗi nhóm phải nhận được mọi sự kiện đơn hàng liên quan. Hệ thống phân tích có thể không khả dụng trong một giờ mà không làm chậm việc xử lý giao hàng.

Hiện tại, việc định tuyến đơn giản, nhưng mỗi consumer cần chính sách retry, lượng công việc tồn đọng và hàng đợi phục vụ điều tra riêng. Producer không nên giữ yêu cầu của khách hàng mở trong khi gọi từng dịch vụ phía sau.

Đây là bài tập tích hợp giả định.

Các phương án và quyết định

Sử dụng SNS fan-out đến các hàng đợi SQS riêng biệt. Cân nhắc EventBridge nếu nhu cầu định tuyến, tích hợp hoặc lưu trữ/phát lại có cấu hình trở nên phức tạp hơn.

Mô hình tư duy và luồng xử lý

Fan-out sao chép sự kiện; hàng đợi đệm công việc của một consumer.

Outbox đơn hàng → SNS → Hàng đợi email → Worker email
                     → Hàng đợi phân tích → Worker phân tích
                     → Hàng đợi xử lý giao hàng → Worker xử lý giao hàng

Worker phân tích tạm dừng sẽ tích lũy lượng công việc tồn đọng riêng thay vì lấy thông điệp của bộ phận xử lý giao hàng.

Cơ chế cốt lõi

Commit đơn hàng và bản ghi outbox một cách nguyên tử, rồi phát sự kiện với ID ổn định và phiên bản schema. Việc phát hoặc gửi trùng lặp có thể xảy ra, nên consumer cần tạo ra tác động có tính idempotent: xử lý lặp lại không được dẫn đến giao hàng trùng lặp hoặc gửi email không kiểm soát.

Giới hạn chính sách hàng đợi cho đúng topic và các principal dự kiến. Dùng bộ lọc cho các loại sự kiện không liên quan, đồng thời rà soát thay đổi schema đối chiếu với các bộ lọc đó. Chỉ đưa vào dữ liệu mà mỗi subscriber được phép nhận; hàng đợi độc lập không phải lý do để quảng bá toàn bộ thông tin khách hàng.

Cấp cho mỗi hàng đợi cơ chế retry xử lý, chính sách dead-letter và cảnh báo tồn đọng riêng. Mở rộng consumer trong giới hạn của hệ thống phía sau. Phân biệt lỗi gửi đến subscription SNS với thông điệp xử lý thất bại nhiều lần sau khi đã vào SQS; hai trường hợp này cần cách xử lý lỗi khác nhau.

Với định tuyến EventBridge xuyên tài khoản, cấu hình riêng chính sách bus nhận, quyền thực thi của rule chuyển tiếp và các rule/target ở phía nhận. Chuyển tiếp xuyên Region cần đích đến được hỗ trợ và cơ chế ngăn vòng lặp rõ ràng. Chính sách bus không phải là quyền truy cập mọi hàng đợi phía sau hay khóa KMS.

Khi phải giữ lại broker cũ, adapter có thể chuyển đổi quy ước thông điệp của nó sang định dạng sự kiện chuẩn, đồng thời giữ nguyên ID ổn định, cơ chế xác nhận và hành vi phát lại. Amazon MQ phù hợp khi cần giữ nguyên giao thức broker hoặc ngữ nghĩa ứng dụng hiện có. Không nhất thiết cần Amazon MQ chỉ vì thiết kế có thông điệp.

Kiểm chứng và khi nào cần đổi phương án

• Dừng hệ thống phân tích và xác minh email cùng xử lý giao hàng vẫn tiếp tục, sau đó xử lý hết phần tồn đọng của phân tích một cách an toàn.
• Gửi sự kiện trùng lặp và sự kiện có phiên bản chưa biết rồi kiểm tra hành vi consumer.
• Thử nghiệm riêng lỗi quyền từ topic đến hàng đợi và lỗi xử lý của worker.

Định tuyến nội dung phức tạp hoặc tích hợp SaaS có thể khiến EventBridge phù hợp hơn. Một nhóm worker có thể thay thế lẫn nhau, xử lý mỗi công việc một lần về mặt logic, sẽ phù hợp với một hàng đợi duy nhất, không cần fan-out.

Điểm cần nhớ và tài liệu AWS

• Hàng đợi dùng chung cân bằng tải công việc; nó không quảng bá đến mọi consumer.
• Các hàng đợi riêng cô lập tốc độ xử lý và sự cố.
• Gửi theo fan-out vẫn cần các tác động phụ có tính idempotent.
• Lỗi gửi và lỗi xử lý xảy ra tại những ranh giới khác nhau.
• Schema sự kiện và quyền truy cập dữ liệu là một phần của quy ước tích hợp.

AWS: SNS fan-out đến SQS

Dịch vụ trong bài: SNS · SQS · EventBridge · Amazon MQ

Phục hồi workflow đơn hàng khi một dịch vụ thành công nhưng dịch vụ tiếp theo thất bại

Tình huống và yêu cầu

Bạn thiết kế workflow xử lý đơn hàng gồm giữ chỗ hàng tồn kho, ủy quyền thanh toán, yêu cầu giao hàng và thu tiền. Mỗi hành động thuộc về một dịch vụ riêng, và một số phản hồi từ đối tác đến muộn hơn.

Nhóm vận hành cần biết đơn hàng mắc kẹt ở đâu và liệu có cần hành động bù trừ hay can thiệp của con người hay không. Không có giao dịch cơ sở dữ liệu dùng chung nào có thể hoàn tác đồng thời công việc của mọi dịch vụ.

Đây là bài tập workflow giả định.

Các phương án và quyết định

Sử dụng state machine Standard với các nhánh bù trừ và chuyển cấp xử lý rõ ràng. Cơ chế điều phối ghi nhận quy trình; quy tắc nghiệp vụ quyết định phục hồi nghĩa là gì.

Mô hình tư duy và luồng xử lý

Saga bù trừ cho các hành động nghiệp vụ đã hoàn tất thay vì rollback một giao dịch cơ sở dữ liệu phân tán.

Giữ chỗ hàng tồn kho → Ủy quyền thanh toán → Yêu cầu giao hàng → Thu tiền

Ủy quyền bị từ chối → Giải phóng phần hàng giữ chỗ → Ghi nhận kết quả đã bù trừ

Sau khi giao hàng hoặc thu tiền, việc phục hồi có thể cần quy trình hủy, trả hàng hoặc hoàn tiền thay thế.

Cơ chế cốt lõi

Giữ ID đơn hàng và các tham chiếu trong trạng thái workflow thay vì payload lớn chứa dữ liệu nhạy cảm. Lịch sử thực thi là dữ liệu vận hành, với những yêu cầu riêng về quyền truy cập và thời gian lưu giữ.

Mỗi task làm thay đổi dữ liệu cần có định danh hành động ổn định, timeout và chính sách retry. Retry lỗi tạm thời trong một hạn mức; việc bị từ chối theo nghiệp vụ không tự động có nghĩa là có thể retry. Task timeout có thể khiến kết quả của hành động bên ngoài chưa rõ, đòi hỏi đối soát trước khi thử lại.

Sử dụng các mẫu callback token được hỗ trợ cho công việc đối tác phản hồi chậm hoặc phê duyệt, đồng thời bảo vệ token bằng giao diện có xác thực. Workflow Standard và Express có đặc tính thực thi và phân phối khác nhau; đừng hoán đổi chúng chỉ vì giá.

So sánh phí chuyển trạng thái của Standard với mô hình chi phí theo yêu cầu/thời lượng của Express dựa trên workload đã đo. Express có thể phù hợp với các luồng ngắn, lưu lượng lớn và có tính idempotent, nhưng không phải phương án thay thế trực tiếp cho workflow callback chạy lâu này. Durable Lambda là một lựa chọn workflow thiên về mã nguồn khác khi ngữ nghĩa step/checkpoint được hỗ trợ phù hợp; vẫn phải giữ nguyên yêu cầu xác lập trách nhiệm và bù trừ rõ ràng.

Ghi nhận kết quả bù trừ và chuyển lỗi đến người vận hành được chỉ định. Bản thân việc bù trừ cũng có thể thất bại, và các hành động không thể đảo ngược có thể không có thao tác nghịch đảo chính xác. Workflow phải phản ánh trung thực các trạng thái đó thay vì đánh dấu mọi lỗi là đã rollback.

Kiểm chứng và khi nào cần đổi phương án

• Làm từng bước thất bại sau khi các bước trước đã thành công và kiểm tra nhánh phục hồi được chọn.
• Thử nghiệm phản hồi trùng lặp từ đối tác, callback hết hạn và kết quả thanh toán chưa rõ.
• Xác minh mỗi đơn hàng đều đi đến trạng thái hoàn tất, đã bù trừ hoặc cần can thiệp có bên chịu trách nhiệm.

Một luồng thông báo độc lập đơn giản có thể chỉ cần điều phối phân tán theo sự kiện. Trình tự nghiệp vụ phức tạp xuyên dịch vụ được lợi từ một bộ điều phối tường minh, nhưng vẫn không trở thành giao dịch ACID.

Điểm cần nhớ và tài liệu AWS

• Điều phối làm trạng thái workflow trở nên tường minh.
• Bù trừ là một hành động nghiệp vụ, không phải hoàn tác tự động.
• Retry đòi hỏi tính idempotent và cơ chế xử lý kết quả đã xác định.
• Chờ lâu cần trạng thái lưu bền thay vì giữ ngăn xếp lời gọi mở.
• Can thiệp của con người là một kết quả hợp lệ cần được mô hình hóa cho các lỗi chưa giải quyết được.

AWS: Xử lý lỗi trong Step Functions

Dịch vụ trong bài: Step Functions · Lambda · SQS · DynamoDB

Cô lập tenant SaaS mà không cấp cho mỗi khách hàng cả một nền tảng riêng

Tình huống và yêu cầu

Một ứng dụng SaaS phục vụ 800 khách hàng nhỏ và năm khách hàng doanh nghiệp chịu yêu cầu quản lý chuyên ngành. Các tenant nhỏ dùng chung tài nguyên tính toán để kiểm soát chi phí. Hợp đồng doanh nghiệp yêu cầu ranh giới dữ liệu riêng và khả năng phục hồi độc lập. Đăng nhập hợp lệ tuyệt đối không được cho phép truy cập bản ghi của tenant khác, kể cả khi bên gọi thay đổi URL hoặc trường trong yêu cầu.

Các phương án và quyết định

Sử dụng mô hình bridge với ngữ cảnh tenant đáng tin cậy được thực thi trên mọi đường truy cập dữ liệu. Xác thực xác định người dùng; phân quyền xác định tài nguyên tenant nào mà người dùng đó được phép truy cập.

Mô hình tư duy và luồng xử lý

Cơ chế cô lập tenant phải đứng vững ngay cả khi người dùng hợp lệ gửi yêu cầu độc hại.

Danh tính đã xác minh → Tra cứu tư cách thành viên phía máy chủ → Ngữ cảnh tenant giới hạn phạm vi → Thao tác dữ liệu được cấp quyền → Sự kiện sử dụng gắn nhãn tenant

Công việc nền, tác vụ xuất dữ liệu, cache và công cụ hỗ trợ phải mang cùng ngữ cảnh đó.

Cơ chế cốt lõi

Gắn định danh tenant với tư cách thành viên đã xác thực, không phải nội dung yêu cầu tùy ý. Sử dụng kiểm tra ở ứng dụng và, khi được hỗ trợ, điều kiện IAM/session tag hoặc role tạm thời giới hạn phạm vi để củng cố ranh giới dữ liệu. Quy ước partition key của DynamoDB và prefix của S3 chỉ hữu ích khi mọi đường truy cập liên quan đều bị giới hạn; backend có quyền rộng có thể vượt qua quy ước đặt tên.

Tách khóa cache và payload công việc bất đồng bộ theo tenant. Xác minh tenant và thao tác của công việc trước khi thực thi, đồng thời tránh dùng lại thông tin xác thực hoặc kết quả cache của tenant khác. Thiết lập cơ chế giả danh người dùng an toàn cho hỗ trợ và quy trình truy cập khẩn cấp break-glass có kiểm toán.

Giới hạn tốc độ của tenant gây tải lớn và đo độ trễ, lỗi, dung lượng lưu trữ cùng mức sử dụng được đo đếm ở cấp tenant. Tag tính phí trên tài nguyên dùng chung không thể tự động phân bổ từng thao tác API cho các tenant; suy ra phân bổ từ mức sử dụng ứng dụng mà không ghi log payload nhạy cảm. Các phân hạng tách riêng cần workflow cấp phát, vá lỗi, sao lưu và xóa nhất quán để việc cô lập không tạo ra sai lệch cấu hình không được quản lý.

Kiểm chứng và khi nào cần đổi phương án

• Thay đổi ID tenant trong URL, nội dung yêu cầu, khóa cache và công việc trong hàng đợi bằng thông tin xác thực hợp lệ.
• Kiểm thử tải với một tenant gây tải lớn và đo tác động lên các tenant khác.
• Khôi phục và xóa một tenant mà không ảnh hưởng đến các tenant không liên quan.

Ranh giới cứng theo hợp đồng có thể đòi hỏi mỗi tenant có một tài khoản hoặc cơ sở dữ liệu riêng. Sản phẩm dùng chung có rủi ro thấp có thể không cần chi phí bổ sung đó, nhưng vẫn cần cơ chế phân quyền và cô lập vận hành đã được kiểm chứng.

Điểm cần nhớ và tài liệu AWS

• Xác thực không phải là cô lập tenant.
• Pool, silo và bridge là những lựa chọn đánh đổi, tự chúng không phải nhãn bảo đảm bảo mật.
• Cô lập cũng áp dụng cho các đường xử lý bất đồng bộ và quản trị.

AWS: Chiến lược cô lập tenant SaaS · AWS: ABAC trong IAM

Dịch vụ trong bài: Cognito · STS · IAM · DynamoDB · S3 · CloudWatch

Đẩy cập nhật đơn hàng trực tiếp mà không coi WebSocket là hàng đợi lưu bền

Tình huống và yêu cầu

Dashboard giao hàng cần nhận cập nhật đơn hàng kịp thời mà không phải polling mỗi giây. Người dùng chỉ được xem những đơn hàng được giao cho mình. Trình duyệt mất kết nối, token hết hạn và client di động có thể bỏ lỡ nhiều cập nhật. Khi kết nối lại, client phải khôi phục trạng thái hiện tại mà không giả định mọi thông báo đều đến đúng một lần.

Các phương án và quyết định

Sử dụng API Gateway WebSocket APIs để gửi trực tiếp, với trạng thái nghiệp vụ được lưu bền và giao thức kết nối lại tường minh làm nền tảng. Giữ luồng sự kiện xử lý đơn hàng độc lập với tình trạng khả dụng của trình duyệt.

Mô hình tư duy và luồng xử lý

Kết nối là cơ hội gửi dữ liệu, không phải bằng chứng rằng client đã nhận hoặc được phép xem sự kiện.

Commit đơn hàng → Sự kiện lưu bền → Tra cứu subscription được cấp quyền → Các client đang kết nối

Kết nối lại → Subscription đã xác thực → Snapshot/phiên bản hiện tại hoặc cơ chế phát lại được hỗ trợ

Cơ chế cốt lõi

Xác thực khi thiết lập kết nối bằng cơ chế được hỗ trợ, sau đó thực thi phân quyền nghiệp vụ khi thay đổi subscription và thực hiện hành động qua thông điệp. Đừng giả định authorizer ở thời điểm kết nối ban đầu sẽ kiểm tra lại mọi thông điệp sau đó hoặc thu hồi quyền ngay lập tức của người dùng đã kết nối. Xác định hành vi hết hạn, xác minh lại và ngắt kết nối.

Duy trì bản ghi ánh xạ kết nối với người dùng/tenant/subscription, có thời hạn và cơ chế dọn dẹp kết nối không còn hoạt động. Giới hạn phạm vi quyền quản lý kết nối của backend. ID đơn hàng do client cung cấp không được cho phép client đăng ký nhận cập nhật của khách hàng khác.

Chỉ phát sự kiện sau khi cập nhật đơn hàng đã được commit và lưu bền, bằng outbox hoặc mẫu thiết kế tin cậy tương đương. Giới hạn fan-out và retry; xử lý kết nối đã đóng mà không retry vô hạn. Đưa thông tin thứ tự/phiên bản vào thông báo để client có thể từ chối cập nhật cũ và yêu cầu snapshot mới sau khi phát hiện khoảng trống.

Giữ trạng thái nguồn chuẩn bên ngoài sổ đăng ký kết nối. Nếu cần phát lại dữ liệu đã bỏ lỡ khi ngoại tuyến, hãy xác định rõ thời gian lưu giữ và quyền phát lại; dịch vụ WebSocket không tự động cung cấp những khả năng đó.

Kiểm chứng và khi nào cần đổi phương án

• Ngắt kết nối trong lúc có nhiều cập nhật, kết nối lại và xác minh thông tin hiện tại hiển thị chính xác.
• Thử đăng ký subscription xuyên tenant bằng một kết nối đã xác thực hợp lệ.
• Cho quyền truy cập hết hạn trong khi vẫn kết nối và xác minh cơ chế thực thi đã cấu hình.

Polling có thể là đáp án đơn giản hơn khi cập nhật ít thường xuyên và số người nhận nhỏ. Dùng WebSocket vì tương tác đòi hỏi, không phải vì kết nối duy trì liên tục nghe có vẻ hiện đại hơn.

Điểm cần nhớ và tài liệu AWS

• Kênh truyền WebSocket không thay thế sự kiện lưu bền hay trạng thái nghiệp vụ.
• Xác thực kết nối và phân quyền liên tục là các biện pháp kiểm soát khác nhau.
• Kết nối lại, bỏ lỡ cập nhật và kết nối không còn hoạt động là những tình huống vận hành bình thường.

AWS: WebSocket APIs của API Gateway

Dịch vụ trong bài: API Gateway · Lambda · DynamoDB · EventBridge · SQS

Kết nối dịch vụ giữa các tài khoản mà không xây dựng mạng phẳng

Tình huống và yêu cầu

Một dịch vụ thanh toán ECS phải gọi dịch vụ định giá trong tài khoản khác. Các nhóm khác chạy dịch vụ EC2 và Lambda. Họ cần phân quyền ở cấp dịch vụ và khả năng quan sát yêu cầu, nhưng không cần kết nối tùy ý giữa các máy chủ. Các nhóm ứng dụng không nên phải duy trì ma trận tuyến peering và bộ cân bằng tải nội bộ ngày càng lớn.

Các phương án và quyết định

Dùng VPC Lattice cho mạng ứng dụng dùng chung và chính sách phân quyền rõ ràng cho bên gọi. Giữ Transit Gateway cho những yêu cầu thực sự cần kết nối mạng có định tuyến.

Mô hình tư duy và luồng xử lý

Khám phá xác định vị trí dịch vụ; kết nối giúp truy cập nó; phân quyền quyết định ai được phép gọi nó.

Danh tính task thanh toán → dịch vụ/listener Lattice → đánh giá phân quyền → target group định giá → target khỏe mạnh

Chỉ tên Cloud Map không tạo tuyến hay cấp quyền truy cập.

Cơ chế cốt lõi

Liên kết các VPC và dịch vụ cần thiết với service network, sử dụng RAM cho mô hình chia sẻ liên tài khoản được hỗ trợ. Định nghĩa listener, quy tắc định tuyến và kiểm tra sức khỏe target. Tích hợp ECS đăng ký và hủy đăng ký target task khi dịch vụ thay đổi.

Với truy cập được IAM phân quyền, sử dụng cách ký yêu cầu được hỗ trợ và đánh giá quyền bên gọi cùng chính sách phân quyền của dịch vụ/service network. Endpoint có thể truy cập nhưng không có ranh giới phân quyền chủ đích không đáp ứng nguyên tắc đặc quyền tối thiểu. Giữ phân quyền tenant của ứng dụng bên trong dịch vụ; danh tính được phép gọi dịch vụ định giá không tự động có quyền với bảng giá của mọi khách hàng.

Cấu hình bảo mật mạng và quyền phía target độc lập. Kiểm thử giao thức đã chọn và hành vi kết thúc TLS thay vì giả định hỗ trợ TCP tùy ý hoặc có ngữ nghĩa mã hóa đầu cuối. Ghi nhật ký truy cập và chỉ số độ trễ/lỗi mà không ghi bí mật khách hàng.

Kiểm chứng và khi nào cần đổi phương án

• Chứng minh task được phê duyệt có thể gọi dịch vụ định giá trong khi một role ngang hàng khác không thể.
• Thay thế task và xác nhận kiểm tra sức khỏe cùng đăng ký target hội tụ về trạng thái đúng.
• Kiểm thử sự cố dịch vụ dùng chung và giới hạn số lần thử lại cùng thời gian chờ của bên gọi.

Một môi trường ECS đơn lẻ có thể đơn giản hơn với Service Connect. Giao thức cơ sở dữ liệu hoặc kết nối IP tổng quát có thể đòi hỏi thiết kế mạng khác. Chọn ranh giới trước, không phải tên dịch vụ mới nhất.

Điểm cần nhớ và tài liệu AWS

• Lattice là mạng ứng dụng, không phải phương án thay thế tổng quát cho toàn bộ định tuyến VPC.
• Khám phá dịch vụ, khả năng kết nối mạng và phân quyền là các việc riêng biệt.
• Chia sẻ liên tài khoản không loại bỏ kiểm tra quyền bên gọi hay tenant.

AWS: ECS và VPC Lattice · AWS: ECS Service Connect

Dịch vụ trong bài: VPC Lattice · ECS Service Connect · Cloud Map · IAM · RAM

Cho phát hiện gian lận, phân tích và lưu trữ truy cập độc lập vào sự kiện nhấp chuột

Tình huống và yêu cầu

Bạn thiết kế luồng nạp clickstream cho một nhà bán lẻ. Phát hiện gian lận, tổng hợp trực tiếp và lưu trữ đều cần cùng các sự kiện và phải khôi phục độc lập sau thời gian ngừng hoạt động.

Đội ngũ cần khả năng phát lại trong bảy ngày và xử lý đúng thứ tự trong luồng của từng người dùng, không cần thứ tự toàn cục giữa tất cả người dùng. Đội ngũ chưa có kinh nghiệm vận hành Kafka vững chắc. Consumer phân tích chậm không được tiêu thụ sự kiện thay cho bộ phát hiện gian lận.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Dùng Kinesis Data Streams với thời gian lưu giữ cần thiết và checkpoint riêng cho từng consumer. Chọn năng lực và chế độ đọc của consumer theo yêu cầu lưu lượng thực tế.

Mô hình tư duy và luồng xử lý

Stream là lịch sử dùng chung với nhiều vị trí đọc; hàng đợi công việc phân công phần việc còn chờ xử lý.

Producer → stream Kinesis → checkpoint phát hiện gian lận
                         → checkpoint phân tích
                         → chuyển giao để lưu trữ

Đẩy checkpoint phát hiện gian lận tiến lên không xác nhận các bản ghi thay cho phân tích.

Cơ chế cốt lõi

Chọn partition key phù hợp với phạm vi cần giữ thứ tự, chẳng hạn ID người dùng. Các bản ghi có thứ tự trong từng shard, nhưng thứ tự nghiêm ngặt ở cấp ứng dụng còn phụ thuộc vào cách producer sắp thứ tự, thử lại và mức độ đồng thời của consumer. Khóa của một người dùng có lưu lượng cao có thể làm quá tải một partition dù tổng năng lực có vẻ đủ.

Dùng ID sự kiện ổn định và đích nhận dữ liệu có tính idempotent vì thử lại và khôi phục có thể tạo hiệu ứng trùng lặp. Chỉ ghi checkpoint sau khi kết quả xử lý đã được lưu an toàn; xác định cách xử lý nếu hệ thống sập giữa lúc cập nhật đích nhận và ghi checkpoint.

Flink có thể duy trì các cửa sổ theo thời gian sự kiện và xử lý sự kiện đến muộn thông qua chính sách watermark rõ ràng. Firehose có thể chuyển dữ liệu đã đệm đến S3; nó không thay thế stream được lưu giữ và các checkpoint độc lập.

Giám sát throttling, iterator age và độ trễ đầu cuối. Chỉ có thể phát lại khi các bản ghi cần thiết vẫn nằm trong thời gian lưu giữ đã cấu hình.

Kiểm chứng và khi nào cần đổi phương án

• Tạm dừng một consumer trong khi các consumer khác tiếp tục, rồi chạy lại và phát lại mà không bỏ sót hiệu ứng nghiệp vụ.
• Thử các bản trùng lặp, partition key có lưu lượng cao và sự kiện đến không theo thứ tự thời gian sự kiện.
• Xác minh yêu cầu khôi phục bảy ngày dựa trên thời gian lưu giữ thực tế và năng lực xử lý để bắt kịp.

Nếu một nhóm worker cần xử lý từng job rồi xóa nó, SQS đơn giản hơn. Công cụ Kafka sẵn có hoặc yêu cầu giao thức có thể khiến MSK phù hợp hơn dù có khác biệt về vận hành.

Điểm cần nhớ và tài liệu AWS

• Consumer độc lập cần theo dõi tiến độ độc lập.
• Phát lại cần lịch sử được lưu giữ, không chỉ chuyển giao thành công.
• Thứ tự trong partition không phải thứ tự toàn cục hay thứ tự thời gian sự kiện.
• Checkpoint và đích nhận có tính idempotent giải quyết các khoảng lỗi khác nhau.
• Hot key có thể giới hạn thông lượng dù tổng năng lực vẫn còn dư.

AWS: consumer Kinesis

Dịch vụ trong bài: Kinesis Data Streams · Firehose · MSK · Managed Service for Apache Flink

Trả lời từ các tài liệu chính sách thay đổi liên tục bằng truy xuất có phân quyền

Tình huống và yêu cầu

Một trợ lý hỗ trợ phải trích dẫn các chính sách sản phẩm hiện hành từ 60,000 tài liệu. Chính sách thay đổi hằng ngày, và các hạng khách hàng khác nhau được truy cập những tài liệu khác nhau. Nhóm có yêu cầu rõ ràng là giữ quyền kiểm soát một kho vector hiện có được hỗ trợ cùng cấu hình truy xuất của nó. Một câu trả lời có vẻ đúng nhưng dựa trên tài liệu lỗi thời hoặc không được phép truy cập vẫn là thất bại.

Các phương án và quyết định

Dùng RAG với Bedrock Knowledge Base do khách hàng quản lý và kho vector hiện có được hỗ trợ. Với một workload mới không có yêu cầu kiểm soát kho vector, hãy đánh giá Knowledge Base được quản lý thay vì mặc định mọi nhóm đều nên vận hành hạ tầng vector.

Mô hình tư duy và luồng xử lý

Chỉ mục là bản sao dẫn xuất của bằng chứng, không phải nguồn quyết định quyền người dùng hay chính sách hiện hành.

Tài liệu đã phê duyệt → phân tích/chia đoạn → embedding + metadata đáng tin cậy → chỉ mục

Câu hỏi đã xác thực → bộ lọc quyền bắt buộc → truy xuất → xếp hạng lại tùy chọn → bằng chứng có giới hạn → sinh nội dung → câu trả lời có trích dẫn hoặc không trả lời

Cơ chế cốt lõi

Chọn ranh giới chia đoạn sao cho giữ nguyên ý nghĩa, đặc biệt là tiêu đề, bảng, ngoại lệ và ngày hiệu lực. Bảo đảm mô hình/số chiều embedding khớp với chỉ mục và lên kế hoạch lập lại chỉ mục khi quy ước tương thích đó thay đổi. Chọn tích hợp kho vector được hỗ trợ dựa trên khả năng lọc, quy mô, vận hành và kiến trúc dữ liệu hiện có, không chỉ dựa vào mức độ quen thuộc của thương hiệu.

Gắn metadata về phân loại, tenant/hạng khách hàng, phiên bản và ngày hiệu lực trong quá trình nạp dữ liệu có kiểm soát. Ứng dụng phải cung cấp các bộ lọc bắt buộc từ ngữ cảnh danh tính đáng tin cậy trong mọi lệnh gọi truy xuất có liên quan. Bộ lọc do client chọn hoặc do mô hình tạo không được mở rộng quyền của bên gọi. Hạn chế quyền truy xuất trực tiếp có thể bỏ qua ranh giới ứng dụng.

Trong nền tảng nhiều tài khoản, hãy so sánh gateway suy luận tập trung với các triển khai suy luận do từng workload sở hữu. Gateway tập trung hóa chính sách, hạn ngạch và đo lường mức sử dụng nhưng trở thành ranh giới chung về tính sẵn sàng và cách ly tenant. Quyền truy cập do workload sở hữu tách biệt trách nhiệm vận hành nhưng cần các biện pháp kiểm soát nhất quán. Trong cả hai trường hợp, dùng cơ chế ủy quyền IAM role được hỗ trợ và quyền truy cập dịch vụ có phạm vi giới hạn; không bao giờ chia sẻ thông tin xác thực quản trị viên hoặc suy ra quyền tài liệu chỉ từ việc thuộc một tài khoản.

Theo dõi việc nạp dữ liệu thành công, lan truyền thao tác xóa và tài liệu lỗi thời. Quyết định liệu truy xuất thất bại hoặc thiếu bằng chứng có đồng nghĩa với không trả lời hay không, thay vì âm thầm yêu cầu mô hình bịa ra chính sách. Văn bản truy xuất được có thể chứa prompt injection: hãy coi nó là bằng chứng không đáng tin cậy và không để nó cấp quyền cho công cụ.

Đánh giá độ bao phủ truy xuất riêng với chất lượng câu trả lời. Mô hình không thể trích dẫn bằng chứng chưa từng được truy xuất, và một trích dẫn không chứng minh rằng khẳng định được tạo ra có cơ sở từ nguồn đó.

Kiểm chứng và khi nào cần đổi phương án

• Thay đổi hoặc xóa một chính sách và đo thời gian cho đến khi các câu trả lời lỗi thời biến mất.
• Kiểm thử trực tiếp việc truy xuất chéo hạng khách hàng, bao gồm các bộ lọc bị bỏ sót hoặc sửa đổi trái phép.
• Chấm điểm các câu hỏi đã biết, tài liệu mâu thuẫn và câu hỏi không có câu trả lời.

Fine-tuning có thể giúp duy trì phong cách phản hồi ổn định hoặc hành vi chuyên biệt; nó không thay thế bằng chứng cập nhật. SQL/tìm kiếm trực tiếp có thể đơn giản hơn khi câu hỏi cần một giá trị có cấu trúc chính xác thay vì tổng hợp thông tin.

Điểm cần nhớ và tài liệu AWS

• RAG giải quyết tính cập nhật của bằng chứng; nó không tự động cung cấp phân quyền.
• Chia đoạn, embedding, metadata và đồng bộ hóa tạo thành một quy trình vận hành.
• Đánh giá truy xuất và sinh nội dung riêng biệt.

AWS: Knowledge Bases · AWS: truy xuất an toàn và lọc metadata

Dịch vụ trong bài: Bedrock Knowledge Bases · Bedrock · S3 · OpenSearch Service · Aurora

Phục vụ mô hình gian lận trực tuyến mà không dùng endpoint của nó cho mọi tác vụ

Tình huống và yêu cầu

Một dịch vụ thanh toán sở hữu mô hình gian lận đã huấn luyện và cần dự đoán có độ trễ thấp trong quá trình thanh toán. Một tác vụ hằng đêm chấm điểm toàn bộ danh mục khách hàng trước 06:00. Mô hình phụ thuộc vào các đặc trưng giao dịch gần đây và phải được rà soát về sự chênh lệch tỷ lệ lỗi giữa các nhóm khách hàng liên quan. Mô hình nền tảng hội thoại không phải phương án thay thế đã được phê duyệt cho mô hình chấm điểm đã được kiểm chứng này.

Các phương án và quyết định

Dùng suy luận thời gian thực của SageMaker cho thanh toán và batch transform cho tập dữ liệu hằng đêm. Thay vào đó, dùng suy luận bất đồng bộ khi các yêu cầu đến riêng lẻ chấp nhận kết quả qua hàng đợi và cần payload lớn hơn hoặc thời gian xử lý dài hơn. Chọn API mô hình nền tảng Bedrock cho một yêu cầu thực sự mang tính tạo sinh, không phải bằng cách đổi nhãn chấm điểm gian lận thành trò chuyện.

Mô hình tư duy và luồng xử lý

Cùng một mô hình có thể có nhiều cam kết phục vụ. Huấn luyện thành công không đồng nghĩa với sẵn sàng cho môi trường production.

Đặc trưng có phiên bản → mô hình đã huấn luyện/đánh giá → artifact đã phê duyệt → endpoint thời gian thực + tác vụ theo lô có lịch

Dự đoán + nhãn có sau đó → rà soát chất lượng/drift/thiên lệch → cập nhật mô hình đã phê duyệt

Cơ chế cốt lõi

Quản lý phiên bản mô hình, mã tiền xử lý và định nghĩa đặc trưng cùng nhau. Ngăn sự sai lệch giữa huấn luyện và phục vụ, đồng thời kiểm thử các đặc trưng thiếu hoặc lỗi thời. Autoscaling nên dựa trên workload và độ trễ đã đo, với năng lực nền đủ để bù thời gian khởi động; nó không thể sửa một mô hình sai hoặc một thành phần phụ thuộc chậm.

Đo hiệu năng các phương án CPU, GPU hoặc Inferentia được hỗ trợ bằng framework và mô hình thực tế, bao gồm cả công việc biên dịch và bảo đảm tương thích. Các bộ tăng tốc huấn luyện như Trainium phục vụ một giai đoạn khác trong vòng đời. Chọn chi phí cho mỗi dự đoán đáp ứng mục tiêu chất lượng và độ trễ, không phải giá mỗi giờ instance rẻ nhất.

Dùng Model Monitor và cơ chế thu thập dữ liệu phù hợp cho các triển khai được hỗ trợ, kèm sự đồng ý, giảm thiểu dữ liệu và thời hạn lưu giữ. Drift là tín hiệu cần điều tra, không phải bằng chứng rằng tự động huấn luyện lại là an toàn. Dùng Clarify hoặc quy trình đánh giá phù hợp để xem xét thiên lệch và khả năng giải thích. So sánh dương tính giả và âm tính giả giữa các nhóm con, ghi lại các hạn chế và chuyển những trường hợp ngoại lệ có hệ quả đáng kể cho con người chịu trách nhiệm xem xét.

Kiểm chứng và khi nào cần đổi phương án

• Kiểm thử tải với lưu lượng thanh toán cao điểm trong khi tác vụ theo lô hằng đêm chạy độc lập.
• Xác minh khả năng rollback mô hình và tính tương thích với schema đặc trưng hiện tại.
• Đánh giá kết quả theo nhóm con và chất lượng dựa trên nhãn thực tế có sau một khoảng trễ, không chỉ độ chính xác tổng thể.

Lưu lượng không liên tục và tương thích có thể phù hợp hơn với suy luận serverless. Các dự đoán xử lý lâu qua hàng đợi có thể phù hợp hơn với suy luận bất đồng bộ. Không lựa chọn phục vụ nào trong số này loại bỏ nhu cầu đánh giá và quản trị.

Điểm cần nhớ và tài liệu AWS

• Thời gian thực, serverless, bất đồng bộ và theo lô đáp ứng các cam kết độ trễ khác nhau.
• Tính đúng đắn của đặc trưng là một phần của tính đúng đắn của mô hình.
• Giám sát drift và rà soát AI có trách nhiệm phải tiếp tục sau khi triển khai.

AWS: các phương án suy luận SageMaker · AWS: SageMaker Clarify

Dịch vụ trong bài: SageMaker AI · SageMaker Clarify · SageMaker Model Monitor · Bedrock · S3

Giữ định danh Windows doanh nghiệp khi ứng dụng chuyển lên AWS

Tình huống và yêu cầu

Bạn di chuyển một ứng dụng Windows cần gia nhập domain, Kerberos và group policy. Nhân viên phải tiếp tục dùng định danh doanh nghiệp, và Active Directory tại chỗ sẽ được giữ lại.

Ứng dụng có thể chạy trong một resource domain riêng có quan hệ trust, và nhóm muốn dùng các domain controller được quản lý trên AWS trải rộng qua các AZ. Bạn cũng phải giải thích những thao tác xác thực nào vẫn phụ thuộc vào domain tại chỗ và kết nối WAN.

Đây là bài tập di chuyển định danh giả định.

Các phương án và quyết định

Dùng Managed Microsoft AD với quan hệ trust được xác định phạm vi có chủ đích, sau khi xác nhận ứng dụng hỗ trợ resource domain riêng.

Mô hình tư duy và luồng xử lý

Trust cho phép một domain chấp nhận định danh của domain khác; nó không sao chép các định danh đó vào một thư mục cục bộ độc lập.

Người dùng doanh nghiệp → xác thực tại domain gốc → đường trust được hỗ trợ → ứng dụng trong domain AWS → cấp quyền tài nguyên

Đường xác thực chính xác phụ thuộc vào cách bố trí domain và thao tác đang thực hiện.

Cơ chế cốt lõi

Triển khai thư mục theo các yêu cầu multi-AZ của nó. Thiết lập DNS hybrid và lưu lượng thư mục cần thiết qua VPN hoặc DX. Kerberos phụ thuộc vào tên chính xác, service principal name và đồng bộ thời gian, không chỉ khả năng kết nối mạng.

Chọn chiều và loại trust dựa trên vị trí của người dùng và tài nguyên; đừng mặc định dùng trust hai chiều khi không cần. Cho máy chủ ứng dụng gia nhập domain dự kiến và xác minh service account, SPN và quyền nhóm.

Hạ tầng thư mục được quản lý giảm công việc vận hành domain controller, nhưng khách hàng vẫn quản lý người dùng, nhóm, chính sách và cấu hình ứng dụng liên quan trong phạm vi quyền được hỗ trợ.

IAM Identity Center xử lý quyền truy cập của nhân sự vào tài khoản AWS và các ứng dụng được hỗ trợ; nó không thay thế dịch vụ domain Windows. AD Connector không lưu giữ bản sao định danh độc lập để sử dụng khi AD tại chỗ không khả dụng.

Kiểm chứng và khi nào cần đổi phương án

• Kiểm thử việc gia nhập domain, Kerberos, service account, DNS và truy cập dựa trên nhóm.
• Ngắt WAN trong một cuộc diễn tập có kiểm soát và xác định các lần đăng nhập hoặc thao tác nào thất bại thay vì cho rằng mọi xác thực đều diễn ra cục bộ.
• Xác minh rằng mất một AZ của AWS không làm mất toàn bộ năng lực phục vụ của thư mục.

Nếu ứng dụng phải ở lại domain ban đầu, có thể cần các bản sao domain controller tự quản lý trên EC2. Điều đó kéo theo trách nhiệm sao chép, vá lỗi, khôi phục và bảo mật mà thiết kế resource domain được quản lý tránh được.

Điểm cần nhớ và tài liệu AWS

• Định danh AWS API và định danh domain Windows giải quyết các vấn đề khác nhau.
• AD Connector không phải bản sao domain controller.
• Chiều trust tuân theo vị trí của người dùng và tài nguyên.
• Trust không loại bỏ phụ thuộc vào domain gốc.
• DNS, thời gian và SPN là các yếu tố bảo đảm Kerberos hoạt động đúng.

AWS: Directory Service

Dịch vụ trong bài: Directory Service · Managed Microsoft AD · AD Connector · Site-to-Site VPN

Mở rộng dung lượng tệp tại chỗ trong khi giữ bộ nhớ đệm làm việc cục bộ

Tình huống và yêu cầu

Bạn hỗ trợ một ứng dụng hồ sơ tại chỗ chỉ hiểu các thư mục chia sẻ SMB hoặc NFS. Phần lớn tệp ít được truy cập, nhưng nhân viên thường xuyên mở lại một tập dữ liệu làm việc nhỏ hơn và cần tốc độ phản hồi cục bộ. Viết lại ứng dụng để gọi S3 nằm ngoài giai đoạn di chuyển này.

Trong bài tập giả định này, giả sử kiểm thử tương thích đã xác nhận rằng ngữ nghĩa tệp/đối tượng của S3 File Gateway là đủ. Ứng dụng không yêu cầu hành vi POSIX không hạn chế, và nhóm chấp nhận tải lên bất đồng bộ với lượng dữ liệu tồn đọng được giám sát.

Các phương án và quyết định

Dùng S3 File Gateway với bộ nhớ đệm có dung lượng phù hợp và giám sát tải lên rõ ràng. Đừng coi đây là giải pháp thay thế trực tiếp không cần điều chỉnh cho mọi ứng dụng dùng hệ thống tệp.

Mô hình tư duy và luồng xử lý

Gateway chuyển giao diện tệp thành lưu trữ đối tượng và giữ dữ liệu hữu ích ở gần.

Ứng dụng tại chỗ → thư mục chia sẻ SMB/NFS → bộ nhớ đệm gateway cục bộ → tải lên bất đồng bộ → S3

Một thao tác ghi vừa được chấp nhận cục bộ và một đối tượng đã tải lên đám mây hoàn tất là các cột mốc độ bền dữ liệu khác nhau.

Cơ chế cốt lõi

Xác định dung lượng bộ nhớ đệm theo tập dữ liệu làm việc và lượng dữ liệu chờ tải lên dự kiến. Cấu hình quyền truy cập thư mục chia sẻ, quyền bucket/prefix được giới hạn, mã hóa và quyền truy cập KMS khi cần. Giám sát phần bộ nhớ đệm chưa đồng bộ và tiến độ tải lên thay vì cho rằng có kết nối nghĩa là mọi thao tác ghi đã được tải lên an toàn.

Tránh để các bên ghi thiếu phối hợp sửa cùng đối tượng bên ngoài gateway. Tính nhất quán mạnh của S3 không tự động làm mới mọi bộ nhớ đệm gateway; hãy tuân theo quy trình làm mới và quyền sở hữu được hỗ trợ.

Khi mất WAN, dữ liệu đã lưu đệm và các thao tác được hỗ trợ có thể vẫn sử dụng được trong giới hạn dịch vụ và dung lượng. Gateway không phải kho lưu trữ ngoại tuyến vô hạn, và việc đọc dữ liệu chưa được lưu đệm vẫn có thể cần đám mây.

Các chế độ Storage Gateway giải quyết những vấn đề khác nhau: File Gateway cung cấp giao diện tệp, Volume Gateway phục vụ giao diện lưu trữ khối với các mô hình riêng, và Tape Gateway cung cấp hạ tầng băng từ ảo. FSx hoặc EFS có thể phù hợp hơn khi yêu cầu chính là đầy đủ khả năng của hệ thống tệp.

Kiểm chứng và khi nào cần đổi phương án

• Thử nghiệm gián đoạn WAN, áp lực dung lượng bộ nhớ đệm và tải lên bị chậm với các tệp tiêu biểu.
• Xác minh quyền, ánh xạ metadata và khả năng khôi phục sau khi thay gateway.
• Thiết lập điểm đồng bộ cuối cùng và nguồn dữ liệu có thẩm quyền trước khi cutover.

Nếu workload cần cơ chế khóa không được hỗ trợ hoặc các ngữ nghĩa hệ thống tệp khác không được hỗ trợ, hãy chọn dịch vụ tệp phù hợp hoặc thiết kế lại ứng dụng. Nếu về sau có thể dùng trực tiếp đối tượng, loại bỏ gateway có thể đơn giản hóa vận hành.

Điểm cần nhớ và tài liệu AWS

• Giao diện tệp trên lưu trữ đối tượng có các giới hạn tương thích cụ thể.
• Xác nhận cục bộ và tải lên hoàn tất là các trạng thái khác nhau.
• Dung lượng bộ nhớ đệm giới hạn khả năng hoạt động khi mất kết nối.
• Các bên ghi bên ngoài cần phối hợp và có xét đến bộ nhớ đệm.
• Bộ nhớ đệm làm việc không phải bản sao lưu độc lập.

AWS: Storage Gateway

Dịch vụ trong bài: Storage Gateway · S3 · FSx · EFS

Giữ điều khiển nhà máy tại chỗ trong khi chuẩn hóa nền tảng triển khai

Tình huống và yêu cầu

Một nhà máy phải giữ vòng điều khiển tại chỗ với độ trễ đến máy móc ở mức mili giây một chữ số. Nhà máy phải tiếp tục vận hành an toàn khi WAN bị gián đoạn. Phân tích dữ liệu có thể chạy trong một AWS Region. Công ty đã sở hữu các máy chủ được hỗ trợ, nhưng cũng đang đánh giá hạ tầng tại chỗ do AWS quản lý cho đợt thay mới phần cứng trong tương lai.

Các phương án và quyết định

Giữ mặt phẳng điều khiển phục vụ an toàn vật lý tại chỗ và chọn mô hình triển khai tại chỗ được hỗ trợ. Đừng khẳng định rằng nền tảng tích hợp AWS khiến mọi thao tác quản lý đều khả dụng khi không có kết nối.

Mô hình tư duy và luồng xử lý

Vị trí triển khai, quyền sở hữu và hành vi khi mất kết nối là những quyết định riêng biệt.

Máy móc → bộ điều khiển cục bộ → bộ đệm cục bộ bền vững → phân tích tại Region sau khi dữ liệu được chuyển tới

Dây chuyền sản xuất không được phụ thuộc vào một yêu cầu API đám mây thành công cho mỗi hành động điều khiển.

Cơ chế cốt lõi

ECS Anywhere đăng ký các instance bên ngoài theo mô hình quản lý ECS tại Region; hãy xác minh những hành vi nào của tác vụ đang chạy và thao tác quản lý nào vẫn hoạt động khi mất kết nối. EKS Anywhere cung cấp môi trường Kubernetes do khách hàng vận hành, với trách nhiệm về vòng đời và năng lực tài nguyên khác với EKS được quản lý tại Region. Outposts có các yêu cầu riêng về service-link, địa điểm, năng lực tài nguyên và dịch vụ được hỗ trợ; nó không phải bản sao đầy đủ của một AWS Region có thể hoạt động khi mất kết nối.

Với mỗi phương án, xác định khả năng sẵn có của image, secret, DNS cục bộ, đồng bộ thời gian, lưu trữ lâu bền, hành vi lập lịch/khởi động lại và khoảng thời gian mất kết nối tối đa. Lưu đệm sự kiện cục bộ với ID thứ tự và đối soát idempotent để khi kết nối được khôi phục không tạo trùng bản ghi sản xuất.

Local Zones đặt các tài nguyên AWS được hỗ trợ gần khu vực đô thị hơn, không nhất thiết ở bên trong nhà máy. Chọn chúng khi độ trễ mạng đo được và vị trí dữ liệu đáp ứng yêu cầu, thay vì đánh đồng khoảng cách địa lý gần với việc lưu trú tại chỗ.

Kiểm chứng và khi nào cần đổi phương án

• Ngắt WAN và kiểm thử riêng các luồng workload đang chạy, khởi động lại, lập lịch và hết hạn thông tin xác thực.
• Làm đầy bộ đệm cục bộ và xác minh hành vi an toàn thay vì mất dữ liệu âm thầm.
• Khôi phục kết nối và đối soát các bản trùng cùng sự kiện đến muộn.

Nếu ứng dụng có thể chấp nhận phụ thuộc WAN và độ trễ đến Region, tài nguyên điện toán được quản lý tại Region sẽ đơn giản hơn. Nếu quản lý hoàn toàn khi mất kết nối là thiết yếu, hãy xác minh toàn bộ nền tảng cục bộ thay vì lựa chọn chỉ dựa vào từ hybrid.

Điểm cần nhớ và tài liệu AWS

• Hạ tầng đám mây ở gần không giống tài nguyên điện toán tại chỗ.
• Các tác vụ hiện có vẫn chạy không chứng minh rằng triển khai và khôi phục hoạt động được khi ngoại tuyến.
• An toàn cục bộ và phân tích tại Region có thể dùng các ranh giới lỗi khác nhau.

AWS: ECS Anywhere · AWS: Outposts · AWS: kiến trúc hybrid trong SAP-C03

Dịch vụ trong bài: Outposts · Local Zones · ECS Anywhere · EKS Anywhere · Direct Connect

Duy trì hoạt động nền tảng đặt hàng hybrid khi một địa điểm Direct Connect gặp sự cố

Tình huống và yêu cầu

Bạn quản lý mạng cho một nhà phân phối có nền tảng đặt hàng trên AWS vẫn phụ thuộc vào hệ thống tồn kho trong trung tâm dữ liệu của họ. Trong giờ giao hàng, các lời gọi API và hoạt động sao chép cộng lại cần 2 Gbps. Bộ phận vận hành cần duy trì năng lực đó sau khi mất một đường truyền hoặc toàn bộ một địa điểm Direct Connect.

Cơ chế thử lại của ứng dụng chịu được gián đoạn failover ngắn, nhưng không chịu được nghẽn kéo dài. Kết nối internet tại cơ sở cung cấp chưa đến 500 Mbps để dùng trong tình huống khẩn cấp. Lưu lượng nhạy cảm phải được mã hóa đầu cuối; các ứng dụng hiện có hỗ trợ TLS.

Đây là bài tập giả định; các mức năng lực là yêu cầu giả định, không phải kết quả benchmark.

Các phương án và quyết định

Chọn các đường DX độc lập tại hai địa điểm. Một kết nối đủ dung lượng tại mỗi địa điểm đáp ứng các trường hợp lỗi đơn lẻ đã nêu. Hai kết nối mỗi địa điểm bổ sung dự phòng thiết bị cục bộ và sự linh hoạt khi bảo trì, theo mô hình khả năng phục hồi tối đa của AWS; chi phí bổ sung đó cần có lý do thuyết phục.

Mô hình tư duy và luồng xử lý

Dự phòng nghĩa là còn đủ năng lực độc lập sau sự cố, không chỉ có thêm một sợi cáp. Địa điểm DX là cơ sở kết nối, không phải Availability Zone của ứng dụng.

Bộ định tuyến trung tâm dữ liệu → transit virtual interface DX → Direct Connect Gateway → Transit Gateway → VPC ứng dụng

Cả hai địa điểm đều cung cấp đường kết nối logic này. Direct Connect Gateway kết nối DX với TGW của Region; nó không mã hóa lưu lượng.

Cơ chế cốt lõi

Sử dụng các bộ định tuyến phía khách hàng riêng biệt và các tuyến nhà mạng độc lập. Hai đường truyền dùng chung một ống dẫn cáp có thể cùng hỏng. Thiết kế đường kết nối còn lại có năng lực trên 2 Gbps kèm phần dư, kiểm tra mọi liên kết và thiết bị thay vì chỉ tốc độ cổng AWS.

BGP quảng bá các tiền tố mạng có thể truy cập và chọn đường đi. Xác minh failover theo cả hai chiều: firewall có trạng thái có thể từ chối lưu lượng khi yêu cầu và phản hồi đi theo các đường không tương thích.

DX không được mã hóa theo mặc định. Bắt buộc TLS cho các phiên ứng dụng và sao chép. Nếu mã hóa lớp IP trở thành yêu cầu bắt buộc, hãy đánh giá riêng các phương án VPN-over-DX được hỗ trợ và thông lượng của chúng. MACsec bảo vệ một đoạn liên kết được hỗ trợ, không tự động bảo vệ toàn bộ đường đi của ứng dụng.

Giữ VPN qua internet làm phương án cuối cùng. Chủ động tạm dừng truyền dữ liệu khối lượng lớn trong chế độ đó để các hoạt động thiết yếu không phải cạnh tranh với nhu cầu bình thường 2 Gbps trên đường truyền dưới 500 Mbps.

Kiểm chứng và khi nào cần đổi phương án

• Với tải đại diện cho thực tế, lần lượt ngắt một đường truyền, một bộ định tuyến và một địa điểm trong các buổi diễn tập riêng.
• Đo thời gian hội tụ, yêu cầu thất bại, khả năng phục hồi qua thử lại và mức sử dụng đường kết nối còn lại. Xác minh việc thử lại không thể tạo đơn hàng trùng lặp.
• Diễn tập hoạt động chỉ qua internet và xác nhận cả việc giảm lưu lượng lẫn mã hóa.

Phiên BGP khỏe mạnh không chứng minh năng lực ứng dụng có thể sử dụng được. Nếu doanh nghiệp cũng yêu cầu sống sót qua sự cố trung tâm dữ liệu, hãy bổ sung thiết kế khôi phục tài nguyên tính toán/dữ liệu; các kết nối DX độc lập không thể thay thế hệ thống tồn kho đang không khả dụng.

Điểm cần nhớ và tài liệu AWS

• Đa dạng địa điểm xử lý những sự cố mà các đường truyền cùng địa điểm không xử lý được.
• Đường dự phòng cần đủ năng lực đầu cuối.
• Quá trình khôi phục BGP có thể làm gián đoạn các phiên hiện có.
• Kết nối riêng tư và mã hóa là hai yêu cầu riêng biệt.
• VPN năng lực thấp là phương án dự phòng suy giảm, không phải phương án thay thế toàn bộ dịch vụ.

AWS: khả năng phục hồi của DX · AWS: mã hóa DX

Dịch vụ trong bài: Direct Connect · Direct Connect Gateway · Site-to-Site VPN · Transit Gateway

Phân giải tên ứng dụng riêng tư trong quá trình di chuyển từng giai đoạn lên AWS

Tình huống và yêu cầu

Bạn đang di chuyển ứng dụng đặt hàng của một nhà sản xuất lên AWS trong khi hệ thống ERP vẫn ở nhà máy. VPN hoạt động và các địa chỉ riêng tư có thể truy cập được, nhưng người dùng văn phòng không phân giải được orders.cloud.example.com; ứng dụng mới không phân giải được erp.corp.example.com.

Nhóm hạ tầng phải giữ quyền sở hữu DNS doanh nghiệp, còn nhóm đám mây sở hữu các bản ghi ứng dụng riêng tư của mình. Bạn cần hostname ổn định theo cả hai chiều mà không công bố bản ghi nội bộ hay duy trì các tệp hosts.

Đây là bài tập thiết kế giả định sử dụng tên miền example.com.

Các phương án và quyết định

Chọn endpoint inbound và outbound của Resolver với chuyển tiếp có điều kiện. VPN cung cấp đường truyền; Resolver bổ sung phần tích hợp DNS còn thiếu.

Mô hình tư duy và luồng xử lý

Inbound và outbound mô tả hướng truy vấn DNS so với AWS, không phải hướng giao dịch nghiệp vụ của ứng dụng.

Văn phòng → DNS doanh nghiệp → endpoint inbound → zone riêng tư AWS
Ứng dụng AWS → VPC resolver → endpoint outbound → DNS doanh nghiệp

Lần tra cứu đầu tìm ứng dụng đặt hàng. Lần thứ hai tìm ERP. Bản thân cả hai lần tra cứu đều không mở kết nối ứng dụng.

Cơ chế cốt lõi

Liên kết private hosted zone cloud.example.com với VPC của endpoint inbound. Cấu hình DNS doanh nghiệp chuyển tiếp hậu tố đó đến các IP của endpoint inbound, không phải địa chỉ resolver do Amazon cung cấp của VPC.

Tạo quy tắc outbound cho corp.example.com, trỏ đến các máy chủ DNS doanh nghiệp và liên kết quy tắc với VPC ứng dụng. Các ứng dụng tiếp tục dùng VPC resolver thông thường; quy tắc khớp chỉ gửi các truy vấn doanh nghiệp ra ngoài. AWS RAM có thể chia sẻ quy tắc đó với các tài khoản khác, nhưng chia sẻ quy tắc không tự động liên kết private hosted zone.

Đặt IP endpoint trong nhiều AZ và dùng các máy chủ DNS doanh nghiệp dự phòng. Cho phép UDP và TCP 53, với security group và tuyến định tuyến phù hợp theo cả hai chiều. TCP quan trọng với các phản hồi không thể hoàn tất qua UDP.

Tránh quy tắc chuyển tiếp quá rộng khiến cùng một truy vấn bị gửi qua lại. Một private zone khớp nhưng thiếu bản ghi có thể trả về NXDOMAIN thay vì chuyển sang DNS công khai; không gian tên chồng lấn cần được xác định quyền sở hữu rõ ràng.

Kiểm chứng và khi nào cần đổi phương án

• Phân giải từng dịch vụ từ các máy khách thực tế bằng thiết lập DNS bình thường, bao gồm cả truy vấn TCP.
• Kiểm tra một tên không tồn tại, một đích DNS không khả dụng và xem nhật ký truy vấn để tìm vòng lặp hoặc việc khớp hậu tố sai.
• Sau khi phân giải thành công, kiểm tra riêng cổng ứng dụng và xác thực.

Hành vi DNS tùy chỉnh mà Resolver không hỗ trợ có thể là lý do để dùng máy chủ chuyển tiếp EC2. Nếu ứng dụng không còn phụ thuộc dịch vụ doanh nghiệp, hãy loại bỏ chuyển tiếp không cần thiết thay vì giữ lại vô thời hạn.

Điểm cần nhớ và tài liệu AWS

• Khả năng kết nối mạng không tự động cung cấp khả năng phân giải DNS.
• Endpoint inbound cho phép mạng bên ngoài truy vấn AWS Resolver.
• Quy tắc outbound gửi những truy vấn VPC được chọn đến máy chủ DNS bên ngoài.
• Liên kết private zone và liên kết quy tắc chuyển tiếp là hai việc riêng biệt.
• Tra cứu DNS thành công không chứng minh dịch vụ có thể truy cập hoặc đang khỏe mạnh.

AWS: Resolver hybrid · AWS: lưu ý về private zone

Dịch vụ trong bài: Route 53 Resolver · Route 53 Private Hosted Zones · AWS RAM

Kết nối các nhóm sản phẩm mà không mở quyền truy cập từ môi trường phát triển sang môi trường sản xuất

Tình huống và yêu cầu

Bạn là kiến trúc sư nền tảng tại một nhà bán lẻ. Các nhóm thanh toán, tồn kho và xử lý đơn hàng chạy ứng dụng trong 20 VPC, các mạng AWS biệt lập, trên nhiều tài khoản. Hiện tại, nhóm mạng của bạn thêm từng kết nối peering mỗi khi các ứng dụng cần giao tiếp. Khi có thêm dự án mới, việc rà soát các kết nối và tuyến định tuyến đó ngày càng khó khăn.

Vấn đề: Mạng ngày càng lớn nhưng vẫn quản lý từng kết nối riêng lẻ.
Nhu cầu: Giao tiếp nội bộ trong dev và nội bộ trong prod; cả hai đều cần kho gói phần mềm và dịch vụ giám sát dùng chung.
Phải ngăn chặn: Truy cập từ dev sang prod theo cả hai chiều, kể cả thông qua dịch vụ dùng chung.
Ràng buộc chính: Kết nối IP tổng quát, không chỉ một API. Tất cả VPC nằm trong một Region với các dải địa chỉ (CIDR) không chồng lấn.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Chọn TGW với các bảng định tuyến riêng cho dev, prod và dịch vụ dùng chung. Cách này thay thế tập hợp kết nối từng cặp ngày càng lớn bằng một quy trình attachment tiêu chuẩn. Việc cô lập vẫn phụ thuộc vào cấu hình tuyến định tuyến chính xác.

Mô hình tư duy và luồng xử lý

TGW là bộ định tuyến trung tâm, không phải một mạng không giới hạn quyền truy cập. Một attachment kết nối VPC với TGW; attachment nguồn quyết định bảng định tuyến nào xử lý gói tin đi vào.

Một build agent trong môi trường phát triển tải gói phần mềm theo luồng:

Build agent
  → Bảng định tuyến VPC
  → Attachment của VPC dev
  → Bảng định tuyến dev trên TGW
  → Attachment của dịch vụ dùng chung
  → Kho gói phần mềm

Phản hồi đi vào qua attachment dùng chung và sử dụng bảng định tuyến shared trên TGW để quay về dev. Gói tin từ dev gửi đến prod không tìm thấy tuyến được phép trong bảng dev và bị loại bỏ.

Cơ chế cốt lõi

Tài khoản mạng sở hữu TGW và chia sẻ nó qua AWS Resource Access Manager (RAM). Các tài khoản ứng dụng gắn VPC của mình vào TGW.

• Association chọn bảng định tuyến TGW được sử dụng cho lưu lượng đi vào từ một attachment.
• Propagation thêm các tuyến của một attachment vào những bảng định tuyến TGW được chọn. Nó không quyết định bảng mà attachment đó sử dụng cho lưu lượng đi vào.

Cấu hình hai cơ chế này độc lập:

Bảng định tuyến của subnet chạy workload cũng phải gửi lưu lượng đến các đích từ xa đã được phê duyệt qua TGW. Tránh association, propagation mặc định hoặc các tuyến quá rộng vô tình kết nối dev với prod.

Bảng shared cho phép định tuyến đến cả hai môi trường, không chỉ cho phản hồi. Định tuyến không phải chính sách truy cập một chiều. Hạn chế cổng và nguồn bằng security group, xác thực yêu cầu dịch vụ và không cho phép máy chủ dùng chung làm proxy chuyển tiếp lưu lượng giữa các môi trường.

Kiểm chứng và khi nào cần đổi phương án

Trước khi triển khai, hãy xác minh:

• Dev và prod có thể sử dụng kho gói phần mềm và dịch vụ giám sát, bao gồm cả lưu lượng phản hồi.
• Ứng dụng thanh toán trên production có thể truy cập ứng dụng tồn kho trên production, trong khi các kết nối dev sang prod và prod sang dev đều thất bại.
• VPC mới được gắn chỉ nhận các tuyến dự kiến, không nhận propagation mặc định không hạn chế.

Nếu có truy cập ngoài dự kiến, hãy kiểm tra cả tuyến VPC và TGW. Vượt qua các kiểm tra này không chứng minh rằng một máy chủ dùng chung bị xâm nhập không thể nối thông các môi trường.

Yêu cầu thay đổi thì lựa chọn cũng thay đổi: hai VPC với một quan hệ ổn định phù hợp với peering; bên sử dụng chỉ cần API của nhà cung cấp phù hợp với PrivateLink. CIDR chồng lấn đòi hỏi giải pháp quản lý địa chỉ hoặc cung cấp dịch vụ, không thể chỉ thêm TGW.

Điểm cần nhớ và tài liệu AWS

• Peering không có tính bắc cầu: A↔B và B↔C không tạo ra kết nối A↔C.
• TGW tập trung hóa định tuyến; các bảng định tuyến riêng xác định ranh giới khả năng kết nối mạng.
• Association chọn bảng tra cứu; propagation cung cấp tuyến cho các bảng.
• RAM chia sẻ quyền truy cập TGW giữa các tài khoản, không chia sẻ quyền ứng dụng.
• Kết nối dịch vụ dùng chung cần cả tuyến phản hồi và biện pháp kiểm soát truy cập ngoài dự kiến.

AWS: bảng định tuyến TGW · AWS: giới hạn của peering

Dịch vụ trong bài: VPC · Transit Gateway · AWS RAM

Tích hợp API giá của công ty được mua lại khi cả hai mạng dùng cùng dải IP

Tình huống và yêu cầu

Bạn là kiến trúc sư đám mây tại một nhà phân phối vừa mua lại một nhà cung cấp. Ứng dụng đặt hàng của bạn phải lấy giá của nhà cung cấp trước chu kỳ bán hàng tiếp theo. Hai công ty đều dùng 10.0.0.0/16 trong các tài khoản AWS riêng biệt ở cùng Region, vì vậy một địa chỉ có thể chỉ đến máy chủ ở bất kỳ mạng nào trong hai mạng.

Nhà cung cấp có thể công bố API HTTPS hiện có nhưng không thể đổi dải địa chỉ production trong tháng này. Bạn cần truy cập riêng tư đến API đó, không cần truy cập cơ sở dữ liệu hay toàn bộ mạng của họ. Nhà cung cấp không cần chủ động khởi tạo kết nối vào VPC của bạn.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Chọn PrivateLink. Ứng dụng kết nối đến địa chỉ bên trong VPC của chính nó, còn AWS chuyển yêu cầu đến dịch vụ mà nhà cung cấp công bố.

Mô hình tư duy và luồng xử lý

PrivateLink là lối vào riêng tư của một dịch vụ, không phải cầu nối giữa hai mạng.

Dịch vụ đặt hàng → ENI endpoint của bên sử dụng → PrivateLink → NLB của nhà cung cấp → API giá

ENI là giao diện mạng. Các ENI của endpoint sử dụng địa chỉ từ subnet của bên sử dụng, tránh phải định tuyến đến CIDR xung đột của nhà cung cấp. Phản hồi quay về qua kết nối đã thiết lập; nhà cung cấp không thể sử dụng dịch vụ này để chủ động khởi tạo các kết nối tùy ý theo chiều ngược lại.

Cơ chế cốt lõi

Nhà cung cấp đặt API sau Network Load Balancer (NLB), tạo endpoint service, cho phép tài khoản của bạn và chấp nhận yêu cầu kết nối endpoint của tài khoản đó. Tài khoản của bạn tạo interface endpoint và giới hạn security group của nó chỉ cho HTTPS từ ứng dụng đặt hàng.

Cấu hình tên DNS ổn định và chứng chỉ TLS khớp với tên đó. Tên DNS riêng tư đã được xác minh trên endpoint service có thể giữ nguyên hostname của API. Listener TCP của NLB có thể chuyển tiếp TLS nguyên vẹn đến các target API. Quyền thiết lập endpoint không phải quyền lấy giá dành cho khách hàng: API vẫn phải xác thực và phân quyền cho từng bên gọi.

Sử dụng endpoint và năng lực xử lý khỏe mạnh của nhà cung cấp trên nhiều Availability Zone được hỗ trợ. So sánh AZ ID giữa các tài khoản, vì tên AZ có thể ánh xạ khác nhau. Endpoint dự phòng không thể bù đắp cho một backend API duy nhất bị lỗi.

Kiểm chứng và khi nào cần đổi phương án

• Phân giải tên API từ VPC của bên sử dụng và thực hiện lời gọi có xác thực mà không đi ra internet.
• Xác minh tài khoản chưa được phê duyệt không thể thiết lập kết nối được chấp nhận, và ứng dụng chưa xác thực không thể lấy giá.
• Xác nhận các máy chủ tùy ý của nhà cung cấp vẫn không thể truy cập; diễn tập mất các target của nhà cung cấp trong một AZ.

Nếu việc mua lại sau này đòi hỏi tích hợp dịch vụ thư mục hoặc kết nối hai chiều tổng quát, hãy xem xét lại việc đổi dải địa chỉ hoặc chuyển đổi địa chỉ. PrivateLink giải quyết ranh giới dịch vụ hiện tại, không giải quyết việc hợp nhất mạng dài hạn của hai công ty.

Điểm cần nhớ và tài liệu AWS

• CIDR chồng lấn khiến định tuyến mạng thông thường trở nên nhập nhằng.
• Interface endpoint cung cấp địa chỉ riêng tư trong VPC của bên sử dụng.
• PrivateLink cung cấp quyền truy cập một dịch vụ, không phải toàn bộ mạng của nhà cung cấp.
• Phê duyệt kết nối, phân quyền API và TLS giải quyết các vấn đề khác nhau.
• Tính sẵn sàng đòi hỏi năng lực xử lý khỏe mạnh ở cả hai phía endpoint.

AWS: khái niệm PrivateLink · AWS: endpoint service

Dịch vụ trong bài: VPC · PrivateLink · Network Load Balancer

Cho phép worker xử lý theo lô trong mạng riêng đọc S3 và Secrets Manager mà không đi ra internet

Tình huống và yêu cầu

Bạn thiết kế pipeline xử lý tài liệu cho một công ty bảo hiểm. Các worker EC2 trong mạng riêng đọc vài terabyte từ S3 mỗi đêm và lấy thông tin xác thực cơ sở dữ liệu từ Secrets Manager. Mọi thứ nằm trong một Region và worker sử dụng image dựng sẵn thay vì tải gói phần mềm khi chạy.

Bộ phận bảo mật cấm truy cập internet tổng quát và chỉ cho phép bucket prefix cùng secret đã được phê duyệt. Bộ phận tài chính muốn tránh đưa lưu lượng S3 khối lượng lớn qua NAT gateway. Chỉ loại bỏ IP công khai sẽ không đáp ứng được yêu cầu nào trong hai yêu cầu này.

Đây là bài tập giả định; khối lượng dữ liệu là giả định.

Các phương án và quyết định

Chọn thiết kế kết hợp endpoint, sau đó hạn chế quyền tài nguyên riêng. Có kết nối đến dịch vụ AWS không có nghĩa là có quyền sử dụng mọi tài nguyên trong dịch vụ đó.

Mô hình tư duy và luồng xử lý

Gateway endpoint thay đổi định tuyến; interface endpoint cung cấp giao diện mạng riêng tư.

Worker → tuyến prefix list S3 → gateway endpoint → bucket được phê duyệt
Worker → DNS riêng tư → ENI interface endpoint → Secrets Manager

Cả hai đều dùng tên dịch vụ SDK thông thường. Máy khách không cần IP endpoint đặc biệt trong mã ứng dụng.

Cơ chế cốt lõi

Liên kết gateway endpoint S3 với bảng định tuyến của mọi subnet worker. Nó sử dụng prefix list do AWS quản lý chứa các dải địa chỉ S3 và không có security group endpoint. DNS S3 vẫn có thể trả về địa chỉ trông như công khai dù tuyến định tuyến không sử dụng internet. Gateway endpoint không có phí endpoint theo giờ hay phí xử lý; phí S3 thông thường vẫn áp dụng.

Với Secrets Manager, tạo ENI endpoint trên các AZ của worker, bật DNS riêng tư và hỗ trợ DNS của VPC, đồng thời cho phép TCP 443 từ security group của worker. Phí interface endpoint theo giờ và dữ liệu được áp dụng; triển khai nhiều AZ không bảo đảm mọi kết nối đều ở trong cùng AZ.

Instance role chỉ cho phép đọc object cần thiết, lấy secret và giải mã KMS. Chính sách endpoint hạn chế yêu cầu; chúng không tự cấp quyền IAM. Hạn chế bucket bằng aws:SourceVpce phải tính đến các đường quản trị và khôi phục để tránh khóa chúng ngoài hệ thống.

Việc S3 hoặc Secrets Manager sử dụng KMS thay mặt ứng dụng tự nó không đòi hỏi endpoint KMS phía worker. Lời gọi API KMS trực tiếp thì có. Kiểm kê các phụ thuộc khác lúc chạy, bao gồm ghi nhật ký, trước khi loại bỏ tuyến internet.

Kiểm chứng và khi nào cần đổi phương án

• Chạy tác vụ từ cả hai AZ mà không có tuyến internet mặc định.
• Xác minh các thao tác đọc dự kiến thành công còn prefix hoặc secret khác bị từ chối.
• Xác nhận nhật ký, truy cập vận hành và giải mã vẫn hoạt động; kiểm tra DNS và tuyến định tuyến riêng biệt.

Máy khách tại chỗ không thể trực tiếp sử dụng gateway endpoint S3 của VPC này qua VPN hoặc DX. Với yêu cầu đó, hãy đánh giá interface endpoint S3 và DNS hybrid thay vì tái sử dụng nguyên thiết kế này.

Điểm cần nhớ và tài liệu AWS

• Subnet riêng tư vẫn có thể đi ra internet qua NAT.
• Gateway endpoint và interface endpoint dùng mô hình định tuyến/bảo mật khác nhau.
• Truy cập endpoint và phân quyền tài nguyên là các bước kiểm tra riêng.
• Kết quả DNS trông như công khai không xác định tuyến đi của gói tin.
• Không có NAT không có nghĩa là không có phí dịch vụ hay phụ thuộc lúc chạy.

AWS: gateway endpoint S3 · AWS: endpoint Secrets Manager

Dịch vụ trong bài: VPC Endpoints · S3 · Secrets Manager · IAM · KMS

Chẩn đoán timeout cơ sở dữ liệu sau khi thêm subnet node EKS

Tình huống và yêu cầu

Bạn là kỹ sư trực vận hành ứng dụng EKS sử dụng RDS PostgreSQL riêng tư. Sau khi thêm một subnet node, các pod trên node mới bị timeout khi mở kết nối cơ sở dữ liệu; các pod trên node cũ vẫn hoạt động. Cả hai chạy cùng image và dùng cùng thông tin xác thực.

Cluster sử dụng địa chỉ pod của VPC CNI, không dùng security group cho pod. Cả hai nhóm node dùng chung một security group và RDS nằm trong cùng VPC. Bạn cần sửa đúng chỗ, không phải công khai cơ sở dữ liệu hay tạm thời bỏ mọi hạn chế mạng.

Tất cả quan sát và nguyên nhân gốc dưới đây là dữ liệu đầu vào giả định của bài tập.

Các phương án và quyết định

So sánh trước, rồi sửa sai lệch đã được chứng minh. Ghi lại IP pod, subnet, kết quả DNS cơ sở dữ liệu và lỗi xảy ra ở bước DNS, TCP, TLS, xác thực hay thực thi SQL.

Mô hình tư duy và luồng xử lý

Phản hồi cũng cần đường đi được cho phép. Với một kết nối mẫu:

Yêu cầu: pod:40000 → RDS:5432
Phản hồi: RDS:5432 → pod:40000

Cổng 40000 là cổng tạm thời, hay ephemeral, của máy khách. Đích của phản hồi không phải cổng lắng nghe của cơ sở dữ liệu.

Cơ chế cốt lõi

Security group có trạng thái: kết nối được cho phép thì lưu lượng phản hồi của nó cũng được cho phép. Network ACL không có trạng thái: quy tắc phải cho phép riêng từng chiều.

Trong bài tập này, cả hai pod phân giải ra cùng địa chỉ RDS. Pod lỗi bị timeout trước bước xác thực. Tuyến và security group khớp với đường kết nối hoạt động, nhưng flow log cho thấy lưu lượng phản hồi bị từ chối. So sánh ACL cho thấy subnet mới thiếu quy tắc cho phép cổng ephemeral chiều vào mà subnet cũ có.

Sửa ACL đó thông qua hạ tầng dưới dạng mã. Cho phép dải cổng ephemeral thực tế của máy khách từ các dải địa chỉ subnet cơ sở dữ liệu, đồng thời kiểm tra thứ tự quy tắc. Không chỉ cho phép cổng mẫu 40000; các kết nối tiếp theo có thể dùng cổng khác. Kiểm tra cả hai ranh giới subnet, không chỉ ACL nguồn.

Một bản ghi flow log REJECT tự nó không chỉ ra quy tắc gây ra vấn đề. Reachability Analyzer có thể kiểm tra các đường mạng AWS được hỗ trợ bằng ENI mang địa chỉ pod, nhưng không gửi gói tin, kiểm tra sức khỏe cơ sở dữ liệu hay đánh giá mọi chính sách Kubernetes.

Kiểm chứng và khi nào cần đổi phương án

• Lặp lại kiểm tra kết nối và truy vấn từ node cũ và mới với lưu lượng đại diện cho thực tế.
• Xác nhận lỗi kết nối giảm trong khi truy cập chiều vào không liên quan vẫn bị chặn.
• Sửa mẫu subnet để lần triển khai tiếp theo không lặp lại thiếu sót.

Nếu kết nối TCP thành công nhưng SQL chậm, hãy điều tra truy vấn và năng lực cơ sở dữ liệu. Bản ghi ACCEPT cũng không chứng minh thành công đầu cuối: TLS, chính sách mạng và pool kết nối vẫn có thể gặp lỗi.

Điểm cần nhớ và tài liệu AWS

• Xác định giai đoạn kết nối thất bại trước khi thay đổi hạ tầng.
• Với VPC CNI, lưu lượng pod không nhất thiết xuất phát từ IP chính của node.
• Security group có trạng thái và ACL không có trạng thái xử lý phản hồi khác nhau.
• Flow log và phân tích cấu hình bổ sung chứ không thay thế bằng chứng từ ứng dụng.
• Lỗi EKS chập chờn không tự động có nghĩa là vấn đề ACL.

AWS: Reachability Analyzer · AWS: ACL và cổng ephemeral

Dịch vụ trong bài: VPC Flow Logs · Reachability Analyzer · EKS · RDS

Cải thiện cửa hàng đặt tại Singapore cho người mua ở châu Âu mà không di chuyển hồ sơ khách hàng

Tình huống và yêu cầu

Bạn hỗ trợ một nhà bán lẻ Singapore mở rộng sang châu Âu. Trang sản phẩm tải chậm với người dùng châu Âu dù xử lý tại origin vẫn tốt. Hình ảnh, script và phản hồi danh mục công khai chiếm khoảng 80% số byte được phân phối; thanh toán vẫn được cá nhân hóa và ghi dữ liệu về Singapore.

Bộ phận bảo mật cho phép cache nội dung công khai trên toàn cầu, nhưng chưa phê duyệt xử lý tại edge toàn cầu cho API có xác thực. Nhóm sản phẩm chấp nhận danh mục cũ tối đa một phút, miễn là bước thanh toán kiểm tra lại giá và tồn kho. Bạn phải cải thiện việc duyệt hàng mà không hứa hẹn thanh toán nhanh như tại địa phương hay khởi động dự án cơ sở dữ liệu đa Region.

Đây là bài tập giả định; các quan sát lưu lượng là giả định được cung cấp.

Các phương án và quyết định

Đặt tài nguyên công khai và phản hồi danh mục sau CloudFront. Trong giai đoạn này, giữ các thao tác có xác thực trên API theo Region hiện có.

Mô hình tư duy và luồng xử lý

CDN đưa phản hồi có thể tái sử dụng đến gần người đọc, không đưa cơ sở dữ liệu nguồn có thẩm quyền đến gần người ghi.

Hình ảnh → cache CloudFront → chỉ đến S3 khi cache miss
Danh mục công khai → cache CloudFront → chỉ đến ALB Singapore khi cache miss
Thanh toán → API Singapore → cơ sở dữ liệu Singapore

Chỉ định tuyến theo độ trễ của Route 53 sẽ không giúp ích: nó chọn giữa các bản triển khai hiện có, không tạo ra một bản triển khai gần hơn.

Cơ chế cốt lõi

Dùng thời gian lưu dài cho tài nguyên có phiên bản. Với phản hồi danh mục, cấu hình cache cả tại edge và trình duyệt trong giới hạn một phút, đồng thời tránh thiết lập phục vụ nội dung cũ vượt giới hạn đó. Cache key phải bao gồm các khác biệt về cách biểu diễn được hỗ trợ, chẳng hạn tiền tệ và ngôn ngữ.

Chỉ trình xử lý thực sự công khai mới được đặt sau behavior danh mục đó. Phản hồi chứa chiết khấu theo tài khoản không được đưa vào cache dùng chung nếu chưa có thiết kế cô lập có chủ đích. Ở đây, loại hoàn toàn phản hồi cá nhân hóa khỏi cache. Cấu hình tích hợp API theo Region của trình duyệt, bao gồm CORS với phạm vi hẹp khi cần.

Giữ S3 riêng tư bằng CloudFront Origin Access Control. Bảo vệ origin ALB riêng, chẳng hạn bằng hạn chế mạng dành cho kết nối đến origin của CloudFront kết hợp header origin riêng cho distribution được listener kiểm tra. Chỉ hạn chế mạng không xác định được distribution của bạn. Sử dụng HTTPS xuyên suốt.

CloudFront Functions có thể xử lý logic nhẹ ở viewer-request/response như chuẩn hóa URL; Lambda@Edge hỗ trợ tập trigger và khả năng runtime khác. Cả hai đều không nên thực hiện giao dịch thanh toán có thẩm quyền. Giữ các phép biến đổi tại edge trong ranh giới dữ liệu công khai đã được phê duyệt.

Bước thanh toán tính lại giá và tình trạng hàng. Giao diện phải xử lý trường hợp giá thay đổi thay vì coi danh mục được cache là cam kết mua hàng.

Kiểm chứng và khi nào cần đổi phương án

• So sánh thời gian tải tại châu Âu khi cache lạnh và cache đã có dữ liệu, tỷ lệ cache hit và độ trễ origin.
• Kiểm tra các biến thể tiền tệ/ngôn ngữ, tuổi nội dung tối đa và hạn chế truy cập trực tiếp origin.
• Xác minh lưu lượng có xác thực bỏ qua cache công khai và thanh toán phát hiện thay đổi giá mới xảy ra.

Nếu độ trễ khi không có cache vẫn không chấp nhận được, hãy điều tra số lượt đi-về của yêu cầu và vị trí dữ liệu. Yêu cầu IP tĩnh hoặc giao thức không phải HTTP có thể phù hợp với Global Accelerator. Cả hai dịch vụ đều không loại bỏ khoảng cách đến thao tác ghi có thẩm quyền tại Singapore.

Điểm cần nhớ và tài liệu AWS

• CloudFront cache nội dung; Global Accelerator tối ưu định tuyến mạng.
• Cache key phải phân biệt các cách biểu diễn thực sự khác nhau.
• Phân phối tại edge không biến thao tác ghi cơ sở dữ liệu ở xa thành thao tác cục bộ.
• Bảo vệ origin và phân quyền người xem là các biện pháp kiểm soát riêng.
• Định tuyến theo độ trễ cần các endpoint thay thế hữu ích.

AWS: CloudFront · AWS: hạn chế truy cập origin ALB

Dịch vụ trong bài: CloudFront · S3 · Application Load Balancer · Global Accelerator · Route 53

Áp dụng chính sách bảo mật chiều ra trên các tài khoản ứng dụng mà không tạo một điểm lỗi chung

Tình huống và yêu cầu

Bạn là kiến trúc sư bảo mật cho các ứng dụng trải trên nhiều tài khoản AWS. Các nhóm cần API thanh toán và email được phê duyệt, nhưng quy tắc chiều ra không nhất quán khiến việc kiểm soát đích ngoài dự kiến trở nên khó khăn.

Bộ phận bảo mật muốn chính sách kiểm tra lưu lượng do trung tâm sở hữu, không phải một proxy dùng chung mà khi hỏng sẽ ngắt kết nối mọi sản phẩm. Ứng dụng đã trải trên nhiều AZ và doanh nghiệp chấp nhận chi phí hạ tầng theo AZ. Giai đoạn này bao gồm lưu lượng IPv4 đi ra internet, không bắt buộc thiết bị bên thứ ba hay giải mã TLS toàn bộ.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Chọn Network Firewall phân tán đa AZ với quản lý chính sách tập trung. Dùng Firewall Manager khi các điều kiện tiên quyết và chế độ triển khai chính sách của nó phù hợp với cấu trúc tài khoản.

Mô hình tư duy và luồng xử lý

Sở hữu chính sách tập trung không đòi hỏi điểm nghẽn lưu lượng tập trung. Mỗi AZ có đường đi riêng:

Subnet ứng dụng A → endpoint firewall A → NAT gateway A → internet gateway → nhà cung cấp

AZ B dùng đường tương đương của riêng mình. NAT chuyển đổi địa chỉ; firewall quyết định lưu lượng nào được phép.

Cơ chế cốt lõi

Dùng subnet riêng cho firewall và subnet công khai riêng cho NAT. Tuyến mặc định của ứng dụng trỏ đến firewall, còn tuyến mặc định của firewall trỏ đến NAT gateway cùng AZ. Subnet NAT cần tuyến phản hồi cụ thể cho các subnet ứng dụng được kiểm tra, đưa trở lại qua cùng endpoint firewall; nếu không, tuyến local của VPC có thể bỏ qua kiểm tra.

Kiểm tra có trạng thái đòi hỏi tính đối xứng của luồng. Với thiết kế TGW tập trung, appliance mode có thể giúp giữ luồng gắn với cùng đường xử lý, nhưng không sửa được lỗi định tuyến tùy ý. Ngăn các đường internet thay thế đi vòng qua mô hình đã chọn.

Cấu hình xử lý không trạng thái để chuyển tiếp lưu lượng dự kiến đến bộ máy xử lý có trạng thái. Không giải mã TLS thì firewall không thể kiểm tra toàn bộ URL hay nội dung HTTPS. Lọc theo tên máy chủ nhìn thấy được không chứng minh payload mã hóa là an toàn.

Resolver DNS Firewall lọc truy vấn sử dụng Route 53 Resolver. Bản thân nó không chặn kết nối bằng IP trực tiếp hay DNS thay thế. Tính đến những đường đó trong chính sách tổng hợp. WAF bảo vệ yêu cầu web; nó không phải firewall chiều ra tổng quát.

Kiểm chứng và khi nào cần đổi phương án

• Diễn tập các luồng được cho phép và bị từ chối trong mọi AZ, bao gồm phản hồi và phiên tồn tại lâu.
• Thử đi vòng bằng DNS thay thế và IP trực tiếp, rồi đối chiếu kết quả với nhật ký.
• Loại bỏ một AZ và xác minh năng lực ứng dụng khỏe mạnh vẫn dùng đường ra cục bộ khỏe mạnh. Triển khai thay đổi chính sách từng bước.

Endpoint hỏng không tự động viết lại tuyến subnet. Phiên hiện có có thể thất bại; khôi phục phụ thuộc vào việc ứng dụng thử lại hoặc được lập lịch lại. Năng lực bắt buộc của nhà cung cấp phù hợp với GWLB; nhiều VPC ít lưu lượng có thể khiến kiểm tra tập trung kinh tế hơn sau khi so sánh toàn bộ phí định tuyến và xử lý.

Điểm cần nhớ và tài liệu AWS

• NAT không phải chính sách kiểm tra lưu lượng.
• Firewall có trạng thái cần đường yêu cầu và phản hồi tương thích.
• Đường ra đa AZ phải đi cùng năng lực ứng dụng đa AZ.
• Lọc DNS và kiểm tra payload mã hóa có mức độ quan sát khác nhau.
• Có thể áp dụng chính sách nhất quán mà không tập trung toàn bộ lưu lượng.

AWS: kiến trúc Network Firewall · AWS: điều kiện tiên quyết của Firewall Manager

Dịch vụ trong bài: Network Firewall · NAT Gateway · Gateway Load Balancer · Route 53 Resolver DNS Firewall · Firewall Manager

Chuyển worker trong mạng riêng sang IPv6 mà không làm mất kết nối nhà cung cấp IPv4

Tình huống và yêu cầu

Một cụm máy cần nhiều địa chỉ hơn mức mà kế hoạch IPv4 riêng hiện tại có thể đáp ứng thuận lợi. Worker mới hỗ trợ IPv6, nhưng nhà cung cấp thanh toán vẫn chỉ công bố địa chỉ IPv4 qua DNS. Worker chủ động khởi tạo yêu cầu HTTPS chiều ra; internet không được chủ động khởi tạo kết nối đến chúng. Việc di chuyển phải diễn ra từng bước, với đường quay lui đã được kiểm thử.

Các phương án và quyết định

Bắt đầu với dual-stack, xác minh các phụ thuộc và dùng DNS64/NAT64 cho worker chỉ IPv6 đủ điều kiện gọi nhà cung cấp IPv4. Lưu lượng IPv6 nguyên bản đi ra internet dùng egress-only internet gateway, không mặc định dùng NAT IPv4.

Mô hình tư duy và luồng xử lý

Một họ địa chỉ là cam kết xuyên suốt đầu cuối: ứng dụng, DNS, tuyến, firewall, đích.

Worker → đích AAAA nguyên bản → egress-only internet gateway

Worker chỉ IPv6 → địa chỉ tổng hợp bởi DNS64 → NAT64 trên NAT gateway → nhà cung cấp IPv4

Cơ chế cốt lõi

Cấp phát không gian địa chỉ không chồng lấn và theo dõi quyền sở hữu trong IPAM. Thêm rõ ràng các tuyến IPv6 và quy tắc security group/NACL; quy tắc IPv4 không cho phép luồng IPv6 tương ứng. Địa chỉ IPv6 có thể định tuyến công khai tự nó không cho phép truy cập chiều vào.

DNS64 tổng hợp địa chỉ IPv6 khi phản hồi DNS đủ điều kiện chỉ có địa chỉ IPv4. Định tuyến tiền tố chuyển đổi 64:ff9b::/96 đến NAT gateway. NAT64 chuyển đổi lưu lượng đó; egress-only internet gateway không chuyển đổi IPv6 sang IPv4. Địa chỉ IPv4 viết trực tiếp trong ứng dụng chỉ IPv6 không được DNS64 tự động khắc phục.

Kiểm tra khả năng hỗ trợ dual-stack của chính endpoint AWS, bộ cân bằng tải, thư viện máy khách và đường kết nối tại chỗ đang dùng. Quan sát họ địa chỉ mà máy khách thực sự sử dụng. Tính đến phí xử lý NAT trên các đường chuyển đổi và phí IPv4 còn lại thay vì khẳng định IPv6 loại bỏ mọi chi phí mạng.

Kiểm chứng và khi nào cần đổi phương án

• Kiểm tra riêng các phụ thuộc AAAA, chỉ có bản ghi A, lỗi DNS và IP viết trực tiếp.
• Xác minh kết nối chiều ra thành công và lưu lượng chiều vào không được yêu cầu bị từ chối qua IPv6.
• Triển khai canary cho một nhóm worker và chứng minh khả năng quay lui trước khi loại bỏ IPv4.

Driver hoặc thiết bị mạng riêng không tương thích có thể là lý do giữ một số subnet ở dual-stack. Không ép chỉ IPv6 bằng cách hy sinh yêu cầu kết nối hoặc kiểm tra lưu lượng.

Điểm cần nhớ và tài liệu AWS

• Dual-stack là chiến lược chuyển tiếp, không phải bằng chứng mọi phụ thuộc đều hỗ trợ IPv6.
• Egress-only internet gateway cung cấp đường ra IPv6 nguyên bản; NAT64 thực hiện chuyển đổi.
• DNS, tuyến và chính sách phải thống nhất trên cả hai họ địa chỉ.

AWS: DNS64 và NAT64 · AWS: thiết kế DNS IPv6

Dịch vụ trong bài: VPC · NAT Gateway · Route 53 Resolver · VPC IPAM

Giảm lạm dụng chức năng thanh toán mà không chặn người mua hợp lệ

Tình huống và yêu cầu

Bạn vận hành cửa hàng HTTPS của một nhà bán lẻ trực tuyến. Bot dò quét các đường dẫn dễ bị khai thác và liên tục gọi chức năng thanh toán, làm tăng tải origin trong các đợt khuyến mãi. Chỉ thêm máy chủ sẽ tăng chi phí trong khi vẫn để lộ các điểm nghẽn ở hệ thống thanh toán và cơ sở dữ liệu.

Bộ phận bảo mật muốn lọc lưu lượng độc hại trước khi tới ứng dụng, nhưng bộ phận kinh doanh không thể chấp nhận các quy tắc chặn người mua thật dùng chung địa chỉ mạng doanh nghiệp hoặc mạng di động. Thiết kế phải phân biệt lạm dụng ứng dụng với tấn công bằng lưu lượng mạng lớn.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Áp dụng WAF tại CloudFront và bảo vệ origin khỏi việc truy cập vòng qua lớp này. Duy trì kiểm tra ở cấp ứng dụng và các biện pháp bảo vệ thanh toán; bộ lọc tại edge không thay thế chúng.

Mô hình tư duy và luồng xử lý

Các lớp khác nhau loại bỏ những loại lưu lượng không mong muốn khác nhau.

Máy khách → CloudFront với WAF web ACL → ALB được bảo vệ → ứng dụng có xác thực → quy trình thanh toán

Shield cung cấp các biện pháp bảo vệ DDoS được hỗ trợ; WAF đánh giá yêu cầu HTTP; ứng dụng quyết định thao tác nghiệp vụ đã xác thực có hợp lệ hay không.

Cơ chế cốt lõi

Khi phù hợp, bắt đầu các managed rule và quy tắc dựa trên tốc độ có mục tiêu ở chế độ đếm, kiểm tra kết quả rồi mới bật chặn. IP nguồn dùng chung có thể đại diện cho nhiều người dùng hợp lệ, vì vậy ngưỡng tốc độ dựa trên IP không tương đương giới hạn theo từng khách hàng.

Chỉ dùng challenge hoặc CAPTCHA trên các luồng máy khách tương thích. Challenge trên trình duyệt có thể làm hỏng các tích hợp không dùng trình duyệt, nên hãy tách riêng callback thanh toán và API theo đặc điểm xác thực, lưu lượng của chúng thay vì miễn kiểm tra một cách tùy tiện.

Hạn chế truy cập trực tiếp origin bằng các biện pháp kiểm soát mạng và xác minh origin được hỗ trợ. Không cache chức năng thanh toán. Thực thi giới hạn theo người dùng, kiểm tra đầu vào, giới hạn sử dụng kết nối và yêu cầu thanh toán có tính idempotent trong ứng dụng.

Shield Standard cung cấp bảo vệ cơ bản cho các tài nguyên được hỗ trợ. Cân nhắc Shield Advanced khi nhu cầu hỗ trợ ứng phó, mức độ phơi nhiễm và chi phí đủ để biện minh cho lựa chọn này; không cấp nào cấp quyền nghiệp vụ hay sửa mã có lỗ hổng.

Kiểm chứng và khi nào cần đổi phương án

• Chỉ phát lại các yêu cầu hợp lệ và độc hại đại diện trong môi trường kiểm thử được cho phép.
• Đo đồng thời số yêu cầu bị chặn, tải origin, trường hợp chặn nhầm và tỷ lệ chuyển đổi thanh toán.
• Kiểm thử người mua dùng chung IP, máy khách API và callback của nhà cung cấp trước khi mở rộng phạm vi thực thi.

Nếu tải là nhu cầu hợp lệ, thiết kế năng lực và cơ sở dữ liệu có thể là cách sửa đúng. Với tấn công mạng không dùng HTTP, WAF không phải cơ chế kiểm tra chính.

Điểm cần nhớ và tài liệu AWS

• Mở rộng năng lực xử lý nhu cầu; lọc quyết định nhu cầu nào được chấp nhận.
• WAF thấy ngữ cảnh HTTP mà security group không thấy.
• Địa chỉ IP dùng chung khiến giới hạn tốc độ đơn giản tiềm ẩn rủi ro.
• Truy cập vòng qua lớp bảo vệ tới origin có thể vô hiệu hóa các biện pháp tại edge dù chúng được cấu hình đúng.
• Tính đúng đắn của thanh toán vẫn là trách nhiệm của ứng dụng.

AWS: WAF

Dịch vụ trong bài: CloudFront · WAF · Shield · ALB

Mở rộng khả năng đọc danh mục mà không viết lại xử lý đơn hàng quan hệ

Tình huống và yêu cầu

Bạn thiết kế cách truy cập dữ liệu cho một nhà bán lẻ trực tuyến. Đơn hàng phụ thuộc vào các ràng buộc quan hệ, giao dịch trên nhiều bảng và báo cáo SQL linh hoạt. Các yêu cầu danh mục chủ yếu lấy sản phẩm theo ID hoặc danh mục và có thể chấp nhận độ trễ cập nhật vài giây.

Trong bài tập giả định này, kiểm thử mang tính đại diện được giả định cho thấy mức tăng trưởng của danh mục vượt quá tỷ lệ chi phí/hiệu năng chấp nhận được của thiết kế read replica quan hệ và cache hiện tại. Đội ngũ có thể vận hành kho dữ liệu thứ hai, nhưng bước thanh toán vẫn phải xác thực giá và tồn kho từ nguồn dữ liệu có thẩm quyền.

Các phương án và quyết định

Giữ đơn hàng trong cơ sở dữ liệu quan hệ và xây dựng mô hình đọc DynamoDB cho truy cập danh mục. Kho dữ liệu bổ sung phải được chứng minh là cần thiết bằng bằng chứng, không phải vì thích kiến trúc dùng nhiều loại kho dữ liệu.

Mô hình tư duy và luồng xử lý

Bản chiếu danh mục là bản sao phục vụ truy cập, không phải nguồn sự thật độc lập thứ hai.

Giao dịch danh mục tại nguồn có thẩm quyền → outbox hoặc CDC → worker tạo bản chiếu có tính idempotent → DynamoDB → lượt đọc trang sản phẩm

Bước thanh toán quay về dữ liệu nghiệp vụ có thẩm quyền trước khi chấp nhận giao dịch mua.

Cơ chế cốt lõi

Thiết kế partition key/sort key và chỉ mục DynamoDB từ các truy vấn thực tế. Tránh scan trên luồng yêu cầu thường xuyên và các khóa dồn lưu lượng vào một hot partition. Tính đến kích thước item và hành vi của chỉ mục.

Dùng luồng thay đổi bền vững thay vì ghi kép không được phối hợp vào SQL và DynamoDB. Nếu không, lần ghi thứ hai thất bại sẽ để lại sai lệch âm thầm. Bổ sung phiên bản sự kiện hoặc cơ chế kiểm soát thứ tự tương đương để sự kiện cũ được thử lại không thể ghi đè trạng thái danh mục mới hơn.

DynamoDB hỗ trợ giao dịch và đọc nhất quán mạnh trong các ngữ cảnh được hỗ trợ, nhưng không phải mọi chỉ mục hay chế độ global table đều có hành vi nhất quán giống nhau. Thiết kế này chấp nhận rõ ràng việc bản chiếu danh mục có độ trễ.

Chọn năng lực cơ sở dữ liệu quan hệ theo workload. Aurora Serverless v2 có thể phù hợp với nhu cầu biến động trong các giới hạn được hỗ trợ; dịch vụ này không phải lúc nào cũng rẻ hơn, và khả năng thu hẹp về không phụ thuộc vào cấu hình được hỗ trợ.

Kiểm chứng và khi nào cần đổi phương án

• Đo hiệu năng các truy vấn sản phẩm và danh mục thực tế, bao gồm lưu lượng phân bố lệch.
• Dừng worker tạo bản chiếu, khôi phục nó và đo độ trễ cùng tính đúng đắn khi phát lại.
• Thay đổi giá trong lúc bản chiếu bị trễ và xác nhận bước thanh toán dùng giá trị từ nguồn có thẩm quyền.

Nếu các bản đọc quan hệ và cache đáp ứng mục tiêu, hãy giữ hệ thống đơn giản hơn. Nếu mọi lượt đọc đều phải phản ánh cập nhật đã commit mới nhất, hãy cân nhắc lại việc đưa bản chiếu bất đồng bộ vào luồng đó.

Điểm cần nhớ và tài liệu AWS

• Lựa chọn kho dữ liệu dựa trên kiểu truy cập và nhu cầu nhất quán.
• Mô hình đọc làm phát sinh trách nhiệm đồng bộ.
• Thu thập thay đổi bền vững an toàn hơn ghi kép không được phối hợp.
• Thiết kế khóa quyết định hành vi truy vấn và mở rộng của DynamoDB.
• Độ mới của dữ liệu đọc và nguồn có thẩm quyền cho giao dịch là hai quyết định riêng biệt.

AWS: các thực hành thiết kế tốt nhất cho DynamoDB

Dịch vụ trong bài: RDS · Aurora · DynamoDB

Cung cấp tệp dùng chung giữa các Availability Zone cho ứng dụng Linux cũ

Tình huống và yêu cầu

Bạn đang chuyển một ứng dụng tài liệu từ một máy chủ Linux sang nhiều instance ứng dụng trên các AZ. Phần mềm cần hệ thống tệp NFS với hành vi thư mục, quyền và khóa thông thường; hiện chưa thể dùng API lưu trữ đối tượng.

Người dùng trên các máy chủ khác nhau phải thấy các tệp dùng chung. Workload có nhu cầu thông lượng vừa phải, và đội ngũ không muốn vận hành hệ thống tệp dạng cụm. Các tệp tạm cục bộ không cần lưu trữ dùng chung bền vững.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Dùng Regional EFS cho các tệp làm việc dùng chung, tính quy mô và cấu hình từ các kiểu truy cập đã đo. Tách riêng dữ liệu tạm có thể bỏ đi.

Mô hình tư duy và luồng xử lý

Lưu trữ khối cung cấp các khối đĩa cho máy; lưu trữ tệp cung cấp hệ thống tệp được phối hợp cho nhiều client; lưu trữ đối tượng cung cấp đối tượng được định địa chỉ qua API.

Instance Linux trong mỗi AZ → mount target EFS cục bộ → hệ thống tệp Regional dùng chung

Chọn giao diện ứng dụng thực sự cần giúp tránh ép ngữ nghĩa không tương thích qua một bộ chuyển đổi.

Cơ chế cốt lõi

Tạo mount target trong các AZ của ứng dụng và chỉ cho phép NFS từ những workload được chỉ định. Dùng cách mount qua TLS được hỗ trợ và cơ chế cấp quyền IAM khi phù hợp. Access point có thể áp đặt đường dẫn hệ thống tệp và danh tính POSIX cho một workload; security group, IAM và quyền tệp vẫn là các biện pháp kiểm soát riêng biệt.

Chọn thiết lập thông lượng và hiệu năng dựa trên kích thước tệp thực tế, thao tác metadata, mức độ đồng thời và nhu cầu độ trễ. Chỉ ước tính dung lượng lưu trữ không đủ để xác định hiệu năng hệ thống tệp có đáp ứng hay không.

EBS vẫn phù hợp với workload hướng khối có thiết kế chia sẻ/nhân bản riêng. FSx là một họ dịch vụ: Windows File Server đáp ứng nhu cầu SMB/AD, Lustre nhắm đến các workload HPC phù hợp, còn ONTAP/OpenZFS có các bộ giao thức và tính năng khác nhau.

Duy trì bản sao lưu để khôi phục khi xóa hoặc hỏng dữ liệu. Tính sẵn sàng Multi-AZ không cung cấp bản lịch sử của tệp bị người dùng ghi đè.

Kiểm chứng và khi nào cần đổi phương án

• Thử đọc/ghi đồng thời, khóa, quyền và các thao tác metadata của ứng dụng.
• Loại bỏ một AZ của ứng dụng và xác nhận các client còn lại tiếp tục hoạt động với hiệu năng chấp nhận được.
• Khôi phục một tệp mẫu bị xóa nhầm từ bản sao lưu.

Nếu sau này ứng dụng chỉ lưu tệp tải lên theo khóa đối tượng, S3 có thể mang lại mô hình đơn giản hơn. Nếu cần tích hợp Windows SMB, hãy đánh giá dịch vụ FSx phù hợp thay vì EFS.

Điểm cần nhớ và tài liệu AWS

• Lưu trữ khối, tệp và đối tượng cung cấp các ngữ nghĩa khác nhau.
• Multi-Attach không phải hệ thống tệp dạng cụm được quản lý.
• Regional EFS cung cấp NFS dùng chung cho các workload Linux được hỗ trợ.
• Hiệu năng lưu trữ phụ thuộc vào kiểu truy cập, không chỉ dung lượng.
• Tính sẵn sàng cao không thay thế khả năng khôi phục theo phiên bản hay bản sao lưu.

AWS: Amazon EFS

Dịch vụ trong bài: EBS · EFS · S3 · FSx

Cache trang sản phẩm mà không biến giá trong cache thành giá có thẩm quyền

Tình huống và yêu cầu

Bạn tối ưu một ứng dụng bán lẻ có cơ sở dữ liệu quan hệ dành phần lớn thời gian trả lời các lượt đọc sản phẩm lặp lại. Tinh chỉnh truy vấn đã có tác dụng, nhưng chính những sản phẩm phổ biến đó vẫn chiếm phần lớn lưu lượng.

Mô tả sản phẩm được phép chậm cập nhật tối đa sáu mươi giây. Tuy nhiên, bước thanh toán phải dùng giá có hiệu lực khi đơn hàng được chấp nhận. Bạn cần giảm tải đọc mà không để cache cũ quyết định một giao dịch tài chính.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Dùng ElastiCache cho dữ liệu duyệt sản phẩm được truy cập nhiều và giữ bước thanh toán dựa vào nguồn có thẩm quyền. Cache là tầng tăng tốc có thể bỏ đi, không phải bản sao duy nhất của trạng thái quan trọng.

Mô hình tư duy và luồng xử lý

Nội dung hiển thị từ cache là một góc nhìn gần đây, không phải lời bảo đảm rằng cơ sở dữ liệu chưa thay đổi.

Yêu cầu sản phẩm → cache hit → phản hồi

Cache miss → cơ sở dữ liệu → nạp cache → phản hồi

Thanh toán → xác thực giá/tồn kho tại nguồn có thẩm quyền → đơn hàng đã commit

Cơ chế cốt lõi

Đặt TTL trong khoảng độ mới được chấp nhận và dùng độ lệch ngẫu nhiên có giới hạn để tránh hết hạn đồng loạt. Sau khi cập nhật cơ sở dữ liệu đã commit, vô hiệu hóa hoặc làm mới mục cache liên quan qua một luồng thay đổi đáng tin cậy. Tính đến race condition giữa cập nhật và các lượt nạp cache đang diễn ra; kiểm tra phiên bản có thể ngăn giá trị cũ thay thế giá trị mới hơn.

Gộp các cache miss đồng thời hoặc dùng khóa ngắn hạn để ngăn cache stampede. Chỉ cache kết quả không tồn tại của sản phẩm trong thời gian ngắn. Nếu cache lỗi, giới hạn lưu lượng dự phòng về cơ sở dữ liệu thay vì để mọi instance ứng dụng dồn yêu cầu vào nguồn.

Chọn thiết lập nhân bản và failover cache để bảo đảm tính sẵn sàng, nhưng giữ dữ liệu chuẩn bền vững trong cơ sở dữ liệu. DAX tăng tốc các kiểu truy cập DynamoDB được hỗ trợ, không phải truy vấn RDS tùy ý. CloudFront cache phản hồi HTTP tại edge thay vì đóng vai trò cache truy vấn nội bộ đa dụng.

Kiểm chứng và khi nào cần đổi phương án

• Đo tỷ lệ cache hit, độ trễ đuôi, lượt đọc tại nguồn và tuổi dữ liệu, không chỉ tỷ lệ hit.
• Thay đổi giá khi các trang vẫn còn trong cache và xác nhận bước thanh toán dùng giá có hiệu lực.
• Xóa sạch cache hoặc gây lỗi cache dưới tải được kiểm soát và kiểm tra biện pháp bảo vệ cơ sở dữ liệu.

Nếu mọi lượt đọc phải thấy giá trị đã commit mới nhất, có thể cần bỏ qua hoặc thiết kế lại cache. Những truy vấn thay đổi thường xuyên, ít được tái sử dụng có thể hưởng lợi từ thiết kế cơ sở dữ liệu nhiều hơn từ cache.

Điểm cần nhớ và tài liệu AWS

• Mức độ phù hợp của cache phụ thuộc vào độ cũ được chấp nhận và khả năng tái sử dụng.
• Cần chủ động xử lý việc vô hiệu hóa và race condition khi nạp cache.
• Lỗi cache có thể dẫn đến quá tải cơ sở dữ liệu.
• Nguồn có thẩm quyền cho giao dịch không nên phụ thuộc vào dữ liệu hiển thị đã cũ.
• DAX, ElastiCache và CloudFront cache các luồng truy cập khác nhau.

AWS: ElastiCache

Dịch vụ trong bài: ElastiCache · DAX · RDS · CloudFront

Cải thiện mô phỏng MPI có các node mất quá nhiều thời gian trao đổi dữ liệu

Tình huống và yêu cầu

Bạn hỗ trợ cụm mô phỏng của một đội kỹ thuật. Thêm node EC2 không còn rút ngắn thời gian chạy vì các tiến trình MPI liên tục trao đổi dữ liệu và chờ nhau. Job cũng đọc một tập dữ liệu dùng chung lớn.

Mục tiêu là hoàn thành trong sáu giờ. Ứng dụng hỗ trợ checkpoint, nhưng đội ngũ phải đo xem lỗi và công việc khởi động lại có còn cho phép đáp ứng thời hạn đó không. Trong bài tập giả định này, kết quả phân tích hiệu năng được giả định xác định giao tiếp giữa các node là nút thắt chính.

Các phương án và quyết định

Đo hiệu năng một cụm hỗ trợ EFA với phần mềm MPI tương thích và cách bố trí phù hợp, bổ sung FSx for Lustre khi nhu cầu thông lượng tệp dùng chung đủ để biện minh cho việc đó.

Mô hình tư duy và luồng xử lý

Tiến độ của các job liên kết chặt chẽ phụ thuộc vào tốc độ của cả tính toán lẫn giao tiếp.

Bộ lập lịch → các node EC2 được phối hợp ↔ trao đổi MPI được EFA hỗ trợ

Các node ↔ dữ liệu làm việc trên FSx for Lustre → checkpoint bền vững trong S3 hoặc kho lưu trữ khác được phê duyệt

Bộ lập lịch khởi chạy công việc; nó không phải mạng vận chuyển thông điệp MPI.

Cơ chế cốt lõi

EFA yêu cầu loại instance, driver và thư viện giao tiếp được hỗ trợ. Cluster placement group có thể cải thiện tính cục bộ khi được hỗ trợ, nhưng phải lập kế hoạch bố trí và năng lực cung ứng instance. EFA không tự động tăng tốc mọi ứng dụng TCP thông thường.

Đo nhu cầu metadata và thông lượng hệ thống tệp trước khi chọn thiết lập lưu trữ. FSx for Lustre hỗ trợ workload dùng chung hiệu năng cao và các khả năng tích hợp S3 được hỗ trợ; instance storage cục bộ có thể hữu ích làm vùng dữ liệu tạm nhưng không phải đích lưu checkpoint bền vững.

Bộ lập lịch HPC điều phối job và tài nguyên; chức năng điều khiển đó tách biệt với luồng dữ liệu EFA. Giữ checkpoint sử dụng được sau khi mất node và xác nhận đã lưu đầy đủ mọi trạng thái cần thiết.

Spot có thể giảm chi phí, nhưng mất một node trong job liên kết chặt chẽ có thể khiến phải làm lại đáng kể. Với thời hạn cứng, hãy so sánh rủi ro gián đoạn và mức bảo đảm năng lực với khoản tiết kiệm theo giờ nhìn thấy trước mắt.

Kiểm chứng và khi nào cần đổi phương án

• So sánh thời gian chạy, hiệu quả mở rộng và chi phí mỗi job hoàn thành khi số node tăng.
• Đo riêng thời gian giao tiếp và I/O với thời gian tính toán.
• Ngắt một node trong lần chạy được kiểm soát và xác minh hành vi khởi động lại từ checkpoint mới nhất.

Workload có thể song song hóa độc lập, với các tác vụ hiếm khi giao tiếp, có thể dùng đội Spot phân tán đơn giản hơn. Tính sẵn sàng Multi-AZ không mặc nhiên là cấu trúc tài nguyên tính toán đang hoạt động tốt nhất cho mô phỏng liên kết chặt chẽ.

Điểm cần nhớ và tài liệu AWS

• Thêm node có thể làm tăng chi phí giao tiếp.
• EFA mang lại lợi ích cho các bộ phần mềm giao tiếp tương thích, không phải mọi ứng dụng.
• Lập lịch và data plane của workload là hai phần riêng biệt.
• Checkpoint phải tồn tại lâu hơn tài nguyên tính toán mà nó bảo vệ.
• Tối ưu thời gian và chi phí để có kết quả hoàn chỉnh, bao gồm cả việc làm lại.

AWS: Elastic Fabric Adapter

Dịch vụ trong bài: EC2 · EFA · FSx for Lustre

Chuyển các phân tích không thường xuyên ra khỏi cơ sở dữ liệu thanh toán

Tình huống và yêu cầu

Bạn hỗ trợ một nhà bán lẻ có các nhà phân tích chạy phép join và scan lớn trên cơ sở dữ liệu giao dịch. Báo cáo làm chậm thanh toán trong giờ làm việc, trong khi các nhà phân tích chỉ chạy vài truy vấn ad hoc mỗi ngày và có thể chấp nhận dữ liệu chậm hơn production mười lăm phút.

Bạn cần tách biệt công việc phân tích mà chưa phải vận hành ngay một cụm phân tích thường trực. Các trường dữ liệu khách hàng nhạy cảm phải tiếp tục được quản trị, và người dùng báo cáo cần thấy chỉ báo độ mới dữ liệu.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Xây dựng bản sao phân tích trong S3 và truy vấn bằng Athena. Dùng luồng thay đổi/xuất dữ liệu gia tăng được nguồn hiện tại hỗ trợ thay vì liên tục quét toàn bộ cơ sở dữ liệu production.

Mô hình tư duy và luồng xử lý

Tách hệ thống tiếp nhận giao dịch khỏi hệ thống khám phá dữ liệu giao dịch.

Thay đổi OLTP → nạp dữ liệu gia tăng → S3 thô → biến đổi bằng Glue → Parquet đã chuẩn hóa → Athena → nhà phân tích hoặc QuickSight

Độ mới dữ liệu phụ thuộc vào toàn bộ luồng nạp và biến đổi, không chỉ tốc độ truy vấn.

Cơ chế cốt lõi

Phân biệt rõ dữ liệu thô và dữ liệu đã chuẩn hóa. Dùng định dạng cột như Parquet và partition phù hợp với các bộ lọc phổ biến. Gộp các tệp nhỏ khi có quá nhiều; nhiều đối tượng rất nhỏ và chia partition quá mức có thể tự tạo ra chi phí xử lý.

Glue Data Catalog cung cấp metadata. Athena truy vấn dữ liệu bên dưới; nó không tự động làm sạch bản ghi sai định dạng hay mãi suy ra được schema nghiệp vụ đúng. Theo dõi rõ ràng thay đổi schema và các lần nạp thất bại.

Dùng workgroup và các biện pháp kiểm soát truy vấn phù hợp để giới hạn chi phí scan. Lưu trữ dạng cột chỉ giảm công việc khi truy vấn và cách bố trí tệp cho phép bỏ qua các cột và partition không cần thiết.

Lake Formation có thể quản trị các hình thức truy cập dữ liệu được hỗ trợ, kết hợp với cấu hình IAM, S3 và KMS cần thiết. Cấu hình cache hoặc truy vấn trực tiếp của QuickSight theo yêu cầu độ mới. Đừng vô tình trình bày dashboard cache cũ như một góc nhìn hiện tại.

Kiểm chứng và khi nào cần đổi phương án

• Đo độ trễ từ nguồn đến báo cáo và hiển thị mốc dữ liệu mới nhất đã xử lý thành công.
• So sánh độ trễ thanh toán trước và sau khi loại bỏ các lượt scan phân tích.
• Kiểm tra số byte được scan và xác thực quyền truy cập hàng/cột với các vai trò nhà phân tích khác nhau.

Mức độ đồng thời BI cao và các phép join phức tạp lặp lại có thể phù hợp hơn với Redshift. Các framework xử lý phân tán tùy chỉnh có thể phù hợp hơn với EMR. Lựa chọn thay đổi theo kiểu truy vấn và nhu cầu vận hành, không chỉ theo kích thước tập dữ liệu.

Điểm cần nhớ và tài liệu AWS

• Tách biệt phân tích bảo vệ độ trễ giao dịch.
• Độ mới dữ liệu bao trùm khâu nạp, biến đổi và trình bày.
• Hiệu quả chi phí Athena phụ thuộc vào dữ liệu được scan và cách bố trí.
• Data lake vẫn cần quản lý schema và chất lượng.
• Quản trị đòi hỏi quyền nhất quán trên toàn bộ luồng dữ liệu.

AWS: tinh chỉnh hiệu năng Athena

Dịch vụ trong bài: S3 · Glue · Athena · Redshift · EMR · Lake Formation · QuickSight

Chia sẻ lakehouse có quản trị mà không sao chép dữ liệu cho từng đội

Tình huống và yêu cầu

Bộ phận tài chính và phân tích sản phẩm cần truy cập SQL vào dữ liệu giao dịch dùng chung trong S3. Tài chính được xem các cột định danh; nhà phân tích sản phẩm thì không. Các chỉnh sửa hằng ngày phải cập nhật bản ghi trước đó, và nhiều engine cần một góc nhìn bảng nhất quán. Một đối tác cũng muốn hợp tác phân tích tổng hợp mà không nhận bản sao không hạn chế của các bản ghi cấp khách hàng.

Các phương án và quyết định

Dùng lakehouse S3 với metadata catalog Glue, quyền Lake Formation và thiết kế Iceberg được hỗ trợ để cập nhật và truy cập chung từ nhiều engine. Đánh giá Clean Rooms riêng cho yêu cầu hợp tác có giới hạn của đối tác.

Mô hình tư duy và luồng xử lý

Lưu trữ giữ các byte; catalog mô tả bảng; định dạng bảng phối hợp các phiên bản; quản trị kiểm soát truy cập.

Nạp dữ liệu đã xác thực → tệp bảng S3 + metadata → catalog/engine có quản trị → truy vấn được cấp quyền

Bản thân một mục catalog không phải ranh giới quyền hay trình quản lý giao dịch.

Cơ chế cốt lõi

Chọn các phiên bản engine và định dạng bảng tương thích. Snapshot và metadata Iceberg hỗ trợ phát triển cấu trúc bảng và thay đổi có giao dịch, nhưng bên đọc/ghi phải dùng các triển khai được hỗ trợ. Lập kế hoạch gộp tệp, xử lý tệp mồ côi và lưu giữ snapshot; xóa mù quáng các đối tượng S3 cũ có thể làm hỏng dữ liệu mà bảng đang tham chiếu.

Dùng cấp quyền Lake Formation và bộ lọc hàng/cột được hỗ trợ cùng các quyền IAM, S3 và KMS cần thiết. Hạn chế truy cập đối tượng trực tiếp có thể bỏ qua truy vấn có quản trị. Chia sẻ liên tài khoản cần cấu hình catalog/chia sẻ tài nguyên được hỗ trợ cùng cấp quyền phía bên nhận; chia sẻ metadata không tự động cấp quyền truy cập cho mọi người dùng.

Dùng Athena cho SQL ad hoc phù hợp, Redshift/Spectrum khi phù hợp với workload kho dữ liệu và truy cập bảng ngoài, và EMR cho xử lý cần các engine phân tán được hỗ trợ cùng khả năng kiểm soát của nó. Phân vùng, định dạng cột, nén và gộp tệp giảm công việc scan cùng chi phí xử lý tệp nhỏ; chúng không sửa được mô hình quyền sai.

Clean Rooms cung cấp các kiểu hợp tác/truy vấn có kiểm soát theo quy tắc phân tích đã cấu hình. Nó không phải quyền xuất toàn bộ hàng đầu vào, và các biện pháp kiểm soát quyền riêng tư phải phù hợp với trường hợp sử dụng được phê duyệt. Xác thực định dạng được hỗ trợ và hành vi truy vấn trước khi đề xuất nó như một cơ sở dữ liệu liên công ty dùng cho mọi mục đích.

Kiểm chứng và khi nào cần đổi phương án

• Truy vấn với tư cách người dùng tài chính và sản phẩm, rồi thử truy cập S3 trực tiếp vào dữ liệu bị hạn chế.
• Áp dụng chỉnh sửa trong khi các bên đọc đang hoạt động và xác minh hành vi snapshot được hỗ trợ.
• Đo khối lượng scan và xác minh việc lưu giữ/gộp tệp bảo toàn các snapshot còn hiệu lực.

Tập dữ liệu nhỏ, bất biến có thể chỉ cần S3 và Athena thay vì lakehouse có giao dịch. Workload giao dịch vận hành với yêu cầu nghiêm ngặt phải nằm trong cơ sở dữ liệu vận hành phù hợp, không phải trong bảng phân tích chỉ vì bảng đó hỗ trợ cập nhật.

Điểm cần nhớ và tài liệu AWS

• Lakehouse bổ sung ngữ nghĩa bảng cho lưu trữ lake; nó không thay thế mọi cơ sở dữ liệu.
• Truy cập qua engine có quản trị có thể bị vô hiệu hóa bởi quyền truy cập S3 trực tiếp quá rộng.
• Chia sẻ liên tài khoản và hợp tác bên ngoài có các mô hình kiểm soát khác nhau.

AWS: Lake Formation · AWS: bảng Iceberg trong Athena · AWS: Clean Rooms

Dịch vụ trong bài: S3 · Glue · Lake Formation · Athena · Redshift Spectrum · EMR · Clean Rooms

Tách biệt tính sẵn sàng cao của cơ sở dữ liệu với mở rộng khả năng đọc

Tình huống và yêu cầu

Bạn hỗ trợ một ứng dụng PostgreSQL sử dụng một RDS primary và một read replica bất đồng bộ để lập báo cáo. Trong một sự cố primary giả định, đội vận hành nâng cấp replica thành primary thủ công, nhưng các pool kết nối của ứng dụng vẫn tiếp tục thử các kết nối cũ và việc khôi phục mất quá nhiều thời gian.

Nhóm muốn có failover được quản lý trong cùng Region mà không phải viết lại ứng dụng hay đổi engine. Báo cáo có thể chấp nhận độ trễ; các thao tác ghi giao dịch cần một quy trình khôi phục xác định và cách xử lý an toàn những kết quả không chắc chắn.

Các phương án và quyết định

Sử dụng hình thức triển khai RDS Multi-AZ phù hợp, giữ lại replica báo cáo nếu tải đọc của nó vẫn đủ để biện minh cho việc duy trì. Đừng xem hai vai trò đó là có thể thay thế cho nhau.

Mô hình tư duy và luồng xử lý

Read replica mở rộng khả năng đọc; standby HA bảo vệ tính sẵn sàng của writer.

Ứng dụng → endpoint DNS của writer được quản lý → primary có standby đồng bộ

Primary gặp sự cố → failover được quản lý → endpoint phân giải tới primary mới → client kết nối lại

Dịch vụ cơ sở dữ liệu thay đổi đích đến, nhưng không thể giữ nguyên mọi kết nối ứng dụng hiện có.

Cơ chế cốt lõi

Trong hình thức triển khai RDS Multi-AZ DB instance, standby không phục vụ đọc. Multi-AZ DB cluster có mô hình khác với các instance có thể đọc; Aurora có kiến trúc lưu trữ và replica riêng. Hãy kiểm tra loại triển khai thay vì học thuộc một quy tắc cho mọi thứ mang tên Multi-AZ.

Dùng endpoint DNS được quản lý, không dùng IP cố định. Pool kết nối phải loại bỏ kết nối lỗi, phân giải lại khi phù hợp và thử lại trong giới hạn. Cache DNS kéo dài có thể làm chậm khôi phục.

Một thao tác ghi bị timeout có thể đã commit. Sử dụng mã định danh thao tác, tính idempotent hoặc đối soát thay vì lặp lại một thay đổi tài chính một cách mù quáng. Client báo cáo cũng cần hiểu độ trễ replica và việc đọc dữ liệu cũ.

HA cơ sở dữ liệu không bao phủ sự cố cache, ứng dụng hay Region. Giữ các kế hoạch khôi phục đó tách biệt.

Kiểm chứng và khi nào cần đổi phương án

• Kích hoạt failover có kiểm soát dưới lưu lượng đại diện và đo thời gian cho tới khi các thao tác ghi thành công trở lại.
• Kiểm tra quá trình khôi phục của pool kết nối, hành vi DNS và các kết quả giao dịch không rõ ràng.
• Xác minh báo cáo vẫn đáp ứng yêu cầu về độ mới dữ liệu trong khi writer phục hồi.

Nếu yêu cầu bao gồm các khả năng riêng của Aurora hoặc khôi phục liên Region, hãy đánh giá rõ ràng những kiến trúc đó. Tên dịch vụ hay sự tồn tại của một replica đều không xác lập RTO ứng dụng được bảo đảm.

Điểm cần nhớ và tài liệu AWS

• Mở rộng khả năng đọc và HA cho writer là những yêu cầu riêng biệt.
• Standby của Multi-AZ DB instance không phải là replica có thể đọc.
• Failover được quản lý vẫn yêu cầu client kết nối lại.
• Timeout không chứng minh rằng thao tác ghi chưa commit thành công.
• Loại triển khai quyết định hành vi sao chép và failover thực tế.

AWS: các hình thức triển khai RDS Multi-AZ

Dịch vụ trong bài: RDS · Aurora · Route 53

Tách việc đồng bộ CRM hằng giờ khỏi các sự kiện giao hàng tức thời

Tình huống và yêu cầu

Bạn tích hợp CRM và nền tảng đơn hàng của một nhà bán lẻ. Bộ phận bán hàng cần một bản sao CRM trong S3 được cập nhật hằng giờ, còn bộ phận xử lý đơn hàng cần nhận cập nhật kịp thời khi một đơn hàng được gửi đi. Khách hàng cũng truy vấn các đơn hàng của chính mình thông qua một API web có xác thực.

CRM có một connector được hỗ trợ và đã được phê duyệt. Bạn cần cơ chế thử lại độc lập cho việc đồng bộ dữ liệu và xử lý giao hàng, hạn chế tối đa việc di chuyển dữ liệu cá nhân, và cơ chế phân quyền ngăn khách hàng đọc đơn hàng của người khác.

Đây là bài tập tích hợp giả định.

Các phương án và quyết định

Dùng AppFlow để trích xuất dữ liệu CRM qua connector được hỗ trợ và dùng luồng EventBridge/SQS để xử lý giao hàng. Giữ việc phân quyền API khách hàng thành một ranh giới riêng.

Mô hình tư duy và luồng xử lý

Tác vụ đồng bộ dữ liệu sao chép một tập dữ liệu; sự kiện nghiệp vụ kích hoạt một hành động.

CRM → AppFlow theo lịch → bản sao S3 được mã hóa
Outbox đơn hàng → EventBridge → hàng đợi giao hàng → worker xử lý đơn hàng
Token khách hàng → API → kiểm tra quyền sở hữu đơn hàng → phản hồi

Một lần chạy CRM thất bại không nên khiến việc xử lý giao hàng bị lặp lại.

Cơ chế cốt lõi

Cấu hình ánh xạ trường và bộ lọc để bản sao chỉ chứa dữ liệu cần thiết. Phải kiểm chứng hành vi đồng bộ gia tăng của từng connector, bao gồm việc xóa dữ liệu và hết hạn token. Định kỳ đối soát với nguồn; không phải connector SaaS nào cũng cung cấp đầy đủ cơ chế CDC.

Phát hành sự kiện giao hàng thông qua một luồng ghi nhận thay đổi bền vững như outbox. Dùng ID sự kiện giao hàng ổn định và các bước chuyển trạng thái có điều kiện ở bên tiêu thụ. Nếu tiến trình gặp sự cố sau khi thực hiện một hành động bên ngoài nhưng trước khi lưu kết quả, kết quả sẽ không chắc chắn; hãy đối soát trước khi thử lại thay vì hứa hẹn xử lý đơn hàng đúng một lần.

Cognito xác thực người dùng. API Gateway hoặc AppSync có thể cung cấp các mô hình API phù hợp, nhưng backend vẫn phải xác minh quyền sở hữu của từng đơn hàng được yêu cầu. Token hợp lệ không phải là quyền đọc tất cả bản ghi.

Kiểm chứng và khi nào cần đổi phương án

• Kiểm thử giới hạn tốc độ CRM, thông tin xác thực hết hạn, các lần chạy bị bỏ lỡ và việc đối soát.
• Gửi các sự kiện giao hàng trùng lặp và ngắt worker sau khi thực hiện hành động bên ngoài nhưng trước khi xác nhận xử lý.
• Thử truy cập đơn hàng của khách hàng khác bằng token hợp lệ và xác minh rằng truy cập bị từ chối.

Các thao tác CRM không được hỗ trợ có thể cần tích hợp tùy chỉnh. Nhu cầu fan-out phức tạp có thể phù hợp hơn với SNS hoặc định tuyến sự kiện bổ sung. Chọn từng dịch vụ theo chức năng của nó thay vì xem luồng dữ liệu, API và event bus là những thứ có thể thay thế lẫn nhau.

Điểm cần nhớ và tài liệu AWS

• Đồng bộ theo lịch và xử lý sự kiện cần các ranh giới thử lại riêng.
• Việc connector được hỗ trợ không có nghĩa là có đầy đủ cơ chế thu thập thay đổi.
• Việc phân phối sự kiện và việc hoàn tất xử lý nghiệp vụ là hai sự kiện khác nhau.
• Xác thực không thay thế phân quyền ở cấp đối tượng.
• Thiết kế tính lũy đẳng phải tính đến các khoảng thời gian có thể xảy ra lỗi liên quan đến tác động phụ bên ngoài.

AWS: AppFlow

Dịch vụ trong bài: AppFlow · EventBridge · SQS · API Gateway · Cognito

Bổ sung tìm kiếm sản phẩm mà không thay thế cơ sở dữ liệu giao dịch

Tình huống và yêu cầu

Bạn xây dựng chức năng tìm kiếm danh mục sản phẩm cho một nhà bán lẻ. Người dùng cần tìm kiếm văn bản được xếp hạng theo mức độ liên quan và các bộ lọc, trong khi cơ sở dữ liệu quan hệ vẫn là nguồn dữ liệu chuẩn cho việc cập nhật sản phẩm và mua hàng. Tìm kiếm có thể chậm hơn nguồn vài giây và phải có khả năng xây dựng lại.

Trong bài tập giả định này, giả sử kiểm thử cho thấy cách tìm kiếm bằng SQL hiện tại không đáp ứng yêu cầu về mức độ liên quan và tải. Tính năng hiện tại không yêu cầu duyệt đồ thị hay một mô hình giao dịch khác.

Các phương án và quyết định

Bổ sung OpenSearch làm chỉ mục đọc được suy ra từ dữ liệu nguồn. Đừng biến nó thành nguồn dữ liệu chuẩn bền vững duy nhất cho đơn hàng hoặc danh mục sản phẩm.

Mô hình tư duy và luồng xử lý

Cơ sở dữ liệu giao dịch ghi nhận các thay đổi chuẩn; chỉ mục tìm kiếm tổ chức một góc nhìn dữ liệu có thể tìm kiếm.

Giao dịch danh mục sản phẩm → outbox/CDC → bộ lập chỉ mục có xét phiên bản → OpenSearch → kết quả tìm kiếm

Khi cần quyết định trong giao dịch, bạn có thể lấy dữ liệu chuẩn sau khi tìm được sản phẩm qua chức năng tìm kiếm.

Cơ chế cốt lõi

Thiết kế analyzer, mapping, định danh tài liệu và chiến lược shard/dung lượng theo hành vi tìm kiếm thực tế. Sao chép JSON vào một chỉ mục không đồng nghĩa với việc tạo ra mức độ liên quan hữu ích hay độ trễ có thể dự đoán.

Sự kiện có thể bị trùng lặp hoặc đến muộn. Dùng ID tài liệu ổn định và thứ tự phiên bản để các bản cập nhật cũ không thể ghi đè trạng thái mới hơn. Chuyển các bản cập nhật thất bại vào một quy trình phát lại có bên chịu trách nhiệm và giám sát độ trễ cập nhật chỉ mục.

Hỗ trợ xây dựng lại song song từ nguồn, kiểm chứng kết quả, rồi chuyển alias hoặc tham chiếu tương đương trong ứng dụng. Quyền tìm kiếm và bộ lọc tenant phải luôn chính xác trong quá trình cập nhật và xây dựng lại; bản chiếu dữ liệu có thể làm lộ dữ liệu nếu bỏ sót bộ lọc.

Các cơ sở dữ liệu chuyên dụng khác giải quyết những nhu cầu khác. Neptune phù hợp với các nhu cầu duyệt đồ thị thích hợp, DocumentDB đòi hỏi kiểm thử tính tương thích tài liệu/API, còn Keyspaces phục vụ các mẫu tương thích Cassandra được hỗ trợ. Không dịch vụ nào mặc nhiên là bản nâng cấp tổng quát so với SQL hoặc thay thế cho tìm kiếm toàn văn chỉ vì nó là dịch vụ chuyên dụng.

Kiểm chứng và khi nào cần đổi phương án

• Đo mức độ liên quan trên các truy vấn đại diện, cùng với độ trễ p95 và độ trễ cập nhật chỉ mục.
• Gửi các bản cập nhật trùng lặp và sai thứ tự, rồi xác minh phiên bản cuối cùng trong chỉ mục.
• Xây dựng lại trong khi vẫn phục vụ lưu lượng và kiểm thử các tìm kiếm không được phép hoặc truy cập chéo tenant.

Nếu sau này tìm kiếm SQL đáp ứng yêu cầu với chi phí vận hành thấp hơn, việc duy trì thêm chỉ mục có thể không còn hợp lý. Nếu bài toán chuyển thành khám phá quan hệ qua nhiều bước, hãy đánh giá lại mô hình dữ liệu thay vì ép nó vào tìm kiếm văn bản.

Điểm cần nhớ và tài liệu AWS

• Lưu trữ chuyên dụng phải theo mẫu truy cập, không phải theo trào lưu.
• Bản chiếu dữ liệu phục vụ tìm kiếm phải có thể khôi phục từ dữ liệu chuẩn.
• Đồng bộ chỉ mục cần các cơ chế kiểm soát thứ tự và phát lại.
• Mức độ liên quan là yêu cầu về tính đúng đắn, không chỉ là một chỉ số độ trễ.
• Các chỉ mục được suy ra từ dữ liệu nguồn vẫn cần thực thi kiểm soát truy cập.

AWS: OpenSearch Service

Dịch vụ trong bài: OpenSearch Service · Neptune · DocumentDB · Keyspaces · RDS

Thu hồi quyền truy cập của nhân viên trên nhiều tài khoản mà không phải tìm từng IAM user

Tình huống và yêu cầu

Bạn quản trị quyền truy cập AWS cho một công ty có 15 tài khoản. Nhân viên có các IAM user và access key riêng trong nhiều tài khoản, nên việc thu hồi quyền khi họ nghỉ việc phụ thuộc vào việc tìm đủ mọi thông tin xác thực.

Công ty đã có nhà cung cấp danh tính doanh nghiệp (IdP) với MFA. Nhân sự muốn một vòng đời danh tính thống nhất, bộ phận bảo mật muốn các phiên AWS ngắn hạn, còn bộ phận vận hành cần quyền truy cập khẩn cấp nếu IdP gặp sự cố. Bạn phải tính đến các phiên dòng lệnh hiện có, không chỉ việc đăng nhập qua trình duyệt.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Dùng Identity Center với IdP hiện có, gán quyền truy cập theo nhóm và tài khoản thay vì cấp thông tin xác thực dài hạn cho từng người.

Mô hình tư duy và luồng xử lý

IdP xác định nhân viên là ai; các quyền được gán cho tài khoản xác định IAM role nào họ có thể sử dụng.

Nhân viên → đăng nhập IdP và MFA → quyền được gán trong Identity Center → phiên role tạm thời trong tài khoản → AWS API

SCIM đồng bộ người dùng và nhóm vào Identity Center. Đây là giao thức cấp phát danh tính, không phải cơ chế đăng nhập.

Cơ chế cốt lõi

Định nghĩa permission set theo trách nhiệm thực tế, chẳng hạn điều tra với quyền chỉ đọc hoặc triển khai trong phạm vi giới hạn. Identity Center cấp phát các role tương ứng trong tài khoản. Dùng luồng đăng nhập CLI được hỗ trợ thay vì phân phối access key vĩnh viễn.

Khi nhân viên nghỉ việc, vô hiệu hóa danh tính, gỡ các quyền được gán và thực hiện quy trình thu hồi phiên được hỗ trợ. Chặn đăng nhập mới không nhất thiết vô hiệu hóa mọi thông tin xác thực tạm thời đã cấp. Chọn thời lượng phiên theo mức rủi ro và kiểm thử cả phiên trên cổng truy cập lẫn thông tin xác thực CLI hiện có.

Duy trì một đường truy cập khẩn cấp được kiểm soát riêng, không phụ thuộc vào IdP đang gặp sự cố. Bảo vệ đường truy cập này bằng MFA mạnh, giới hạn người chịu trách nhiệm, cảnh báo và diễn tập định kỳ. Không để nó trở thành tài khoản quản trị dùng hằng ngày mà không được giám sát.

Kiểm chứng và khi nào cần đổi phương án

• Cấp quyền cho người dùng thông qua tư cách thành viên nhóm và xác minh chỉ những tài khoản, role dự kiến mới xuất hiện.
• Thu hồi quyền khi người dùng đang có phiên CLI và đo hành vi thu hồi thực tế.
• Diễn tập sự cố IdP và sau đó xem lại bản ghi kiểm toán truy cập khẩn cấp.

Một hệ thống liên kết danh tính hiện có với quy mô nhỏ có thể chưa cần thay thế ngay. Đăng nhập vào ứng dụng của khách hàng là bài toán khác, thường được giải quyết bằng Cognito; phạm vi ở đây là quyền truy cập tài khoản của nhân viên.

Điểm cần nhớ và tài liệu AWS

• Xác thực, cấp phát danh tính và phân quyền là các chức năng riêng biệt.
• Permission set ánh xạ trách nhiệm của nhân viên tới role trong tài khoản.
• Thông tin xác thực tạm thời giảm, nhưng không loại bỏ, rủi ro liên quan đến thông tin xác thực.
• Thu hồi quyền khi nghỉ việc phải tính đến các phiên đã cấp.
• Truy cập khẩn cấp cần khả năng sẵn sàng độc lập và giám sát chặt chẽ.

AWS: IAM Identity Center

Dịch vụ trong bài: IAM Identity Center · IAM · STS

Cấp quyền truy cập cho nhà cung cấp giám sát mà không nhầm lẫn danh tính khách hàng

Tình huống và yêu cầu

Bạn đang tích hợp một nhà cung cấp giám sát SaaS vào tài khoản AWS của công ty. Nhà cung cấp phục vụ nhiều khách hàng và cần một số chỉ số cùng siêu dữ liệu tài nguyên, không cần dữ liệu ứng dụng hay quyền quản trị.

Bộ phận bảo mật cấm access key vĩnh viễn. Họ cũng hỏi nhà cung cấp sẽ tránh sử dụng role của bạn như thế nào khi một khách hàng khác cung cấp ARN của role đó lúc đăng ký tích hợp. Bạn cần quyền truy cập tạm thời, ngữ cảnh yêu cầu riêng cho từng khách hàng và quy trình chấm dứt quyền truy cập rõ ràng.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Tạo một role có phạm vi quyền hẹp, yêu cầu external ID riêng cho khách hàng do nhà cung cấp cấp. Nhà cung cấp phải gán và sử dụng nhất quán các mã định danh khác nhau cho các khách hàng của mình.

Mô hình tư duy và luồng xử lý

External ID cho nhà cung cấp được tin cậy biết họ đang thực thi quyền của khách hàng nào; đây không phải mật khẩu.

Principal của nhà cung cấp → STS AssumeRole với external ID của bạn → thông tin xác thực role tạm thời → các API giám sát được phê duyệt

Một khách hàng khác biết ARN của role của bạn không được phép khiến nhà cung cấp đưa ra đúng ngữ cảnh khách hàng cho role đó.

Cơ chế cốt lõi

Trust policy của role kiểm soát ai có thể assume role và kiểm tra sts:ExternalId. Permissions policy kiểm soát phiên được tạo ra có thể làm gì. Đây là hai quyết định riêng biệt.

Giới hạn hành động ở các API giám sát cần thiết và tài nguyên khi được hỗ trợ. Một policy chỉ đọc rộng vẫn có thể làm lộ dữ liệu nhạy cảm, vì vậy đừng đánh đồng “không thể ghi” với “an toàn để chia sẻ”.

Ghi lại thông tin danh tính phiên hữu ích trong CloudTrail và xem xét việc sử dụng thực tế. IAM Access Analyzer giúp xác định quyền truy cập vượt ngoài ranh giới tin cậy dự kiến, nhưng không thay thế việc kiểm tra quy trình cô lập tenant của nhà cung cấp.

Khi hợp đồng chấm dứt, gỡ quan hệ tin cậy và xử lý các phiên hiện có bằng quy trình thu hồi được hỗ trợ. Chỉ chặn việc assume role trong tương lai không bảo đảm mọi thông tin xác thực đã cấp đều ngừng hoạt động.

Kiểm chứng và khi nào cần đổi phương án

• Assume role với principal và external ID dự kiến, sau đó lặp lại với ID sai và một principal khác.
• Xác nhận việc giám sát thành công trong khi các thao tác đọc và thay đổi dữ liệu ứng dụng bị từ chối.
• Diễn tập chấm dứt quyền truy cập khi có phiên đang hoạt động.

Nếu bên gọi là một dịch vụ AWS thay vì nhà cung cấp bên thứ ba đa tenant, các điều kiện được hỗ trợ như tài khoản nguồn và ARN nguồn có thể mới là biện pháp kiểm soát confused deputy phù hợp. Chọn mô hình tin cậy phù hợp với bên gọi.

Điểm cần nhớ và tài liệu AWS

• Trust policy và permissions policy trả lời các câu hỏi khác nhau.
• External ID ràng buộc yêu cầu của nhà cung cấp với ngữ cảnh khách hàng.
• External ID không phải thông tin xác thực bí mật.
• Quyền chỉ đọc vẫn có thể làm lộ thông tin nhạy cảm.
• Thu hồi quan hệ tin cậy và thu hồi các phiên hiện có là hai vấn đề riêng biệt.

AWS: quyền truy cập bên thứ ba và external ID

Dịch vụ trong bài: IAM · STS · IAM Access Analyzer · CloudTrail

Luân chuyển thông tin xác thực cơ sở dữ liệu mà không dựng lại image ứng dụng

Tình huống và yêu cầu

Bạn duy trì một ứng dụng đặt chỗ chạy trong container. Mật khẩu cơ sở dữ liệu được nhúng trong image, nên các bản sao tồn tại ở nhiều registry và môi trường. Bộ phận bảo mật yêu cầu luân chuyển định kỳ, nhưng bộ phận vận hành không thể điều phối một đợt phát hành đầy đủ mỗi lần mật khẩu thay đổi.

Bạn cần thông tin xác thực riêng theo môi trường, quyền truy xuất bị giới hạn và máy khách vẫn hoạt động qua quá trình luân chuyển mà không làm lộ bí mật trong log. Thông tin xác thực đã bị lộ phải bị thu hồi, không chỉ được sao chép vào một dịch vụ lưu trữ mới.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Dùng Secrets Manager và đưa việc làm mới thông tin xác thực vào logic kết nối của ứng dụng. Chỉ lưu trữ bí mật sẽ không khiến tiến trình đang chạy sử dụng mật khẩu mới.

Mô hình tư duy và luồng xử lý

Luân chuyển là một thay đổi được phối hợp giữa cơ sở dữ liệu, các phiên bản bí mật và máy khách.

Quy trình luân chuyển → cập nhật và kiểm thử thông tin xác thực cơ sở dữ liệu → đưa phiên bản bí mật vào sử dụng → máy khách làm mới → kết nối cơ sở dữ liệu mới

Kết nối hiện có và kết nối mới mở có thể hoạt động khác nhau trong chuỗi bước đó.

Cơ chế cốt lõi

Task role của ứng dụng chỉ được truy xuất bí mật của môi trường tương ứng và sử dụng khóa KMS cần thiết. Lấy bí mật qua SDK và lưu vào bộ nhớ đệm trong thời gian giới hạn. Đưa bí mật vào biến môi trường lúc khởi động không tự động làm mới biến đó về sau.

Chọn chiến lược luân chuyển một người dùng hoặc luân phiên người dùng được hỗ trợ dựa trên engine và nhu cầu về tính sẵn sàng. Quy trình phải kiểm thử thông tin xác thực mới trước khi đưa phiên bản đó vào sử dụng cho máy khách.

Connection pool nên xử lý lỗi xác thực bằng việc làm mới và kết nối lại có kiểm soát, không phải thử lại vô hạn hay tạo đợt yêu cầu bí mật đồng loạt trên toàn bộ hệ thống. Dùng TLS và ngăn bí mật xuất hiện trong ngoại lệ, trace hoặc đầu ra triển khai.

Loại bỏ mật khẩu khỏi image và thu hồi thông tin xác thực đã lộ. Chuyển nó sang Secrets Manager mà không thay đổi vẫn khiến các bản sao cũ hữu dụng với kẻ tấn công.

Kiểm chứng và khi nào cần đổi phương án

• Luân chuyển dưới lưu lượng đại diện cho thực tế và kiểm tra cả phiên hiện có lẫn kết nối mới.
• Mô phỏng một bước luân chuyển thất bại và xác minh ứng dụng vẫn có một đường hoạt động đã được xác nhận là tốt.
• Tìm dấu hiệu vô tình tiết lộ bí mật trong đầu ra chẩn đoán được phê duyệt.

Xác thực cơ sở dữ liệu bằng IAM có thể loại bỏ mật khẩu dài hạn của ứng dụng khi engine và kiểu kết nối hỗ trợ. Cách này vẫn cần người dùng cơ sở dữ liệu, quyền, TLS và quản lý kết nối phù hợp.

Điểm cần nhớ và tài liệu AWS

• Lưu trữ an toàn không tự động cập nhật các máy khách đang chạy.
• Luân chuyển phải phối hợp trạng thái cơ sở dữ liệu và các phiên bản bí mật.
• Bộ nhớ đệm thông tin xác thực cần thời hạn hết hiệu lực và hành vi làm mới có kiểm soát.
• Phải thu hồi thông tin xác thực cũ trong image.
• Xác thực tạm thời không loại bỏ nhu cầu phân quyền cơ sở dữ liệu.

AWS: luân chuyển trong Secrets Manager

Dịch vụ trong bài: Secrets Manager · Systems Manager Parameter Store · IAM · RDS

Cấp danh tính AWS tạm thời riêng biệt cho pod và worker tại chỗ

Tình huống và yêu cầu

Một dịch vụ báo cáo chạy trong EKS, còn một worker ký số vẫn ở hệ thống tại chỗ. Cả hai cần một số AWS API, nhưng không bên nào nên dùng chung IAM access key dài hạn. Một pod báo cáo bị xâm phạm không được có khả năng lấy quyền rộng của node hay role của worker ký số.

Các phương án và quyết định

Dùng các liên kết EKS Pod Identity được hỗ trợ cho workload báo cáo và IAM Roles Anywhere cho worker bên ngoài được xác thực bằng chứng chỉ. Giữ quyền và quan hệ tin cậy của role riêng cho từng workload.

Mô hình tư duy và luồng xử lý

Nơi workload chạy quyết định cách nó chứng minh danh tính, không quyết định quyền của nó nên rộng đến đâu.

Cụm EKS + namespace + service account → liên kết pod → thông tin xác thực role tạm thời

Chứng chỉ của worker bên ngoài → xác thực CA được tin cậy/profile → phiên Roles Anywhere → AWS role giới hạn phạm vi

Cơ chế cốt lõi

Với Pod Identity, kiểm tra hỗ trợ về tài nguyên tính toán/nền tảng và cấu hình agent, liên kết, quan hệ tin cậy của role cùng chuỗi cung cấp thông tin xác thực SDK được hỗ trợ theo yêu cầu. Tên namespace/service account phải trỏ tới đúng workload dự kiến. Giới hạn ai có thể thay đổi liên kết hoặc chạy pod bằng service account đặc quyền, và ngăn việc vô tình chuyển sang dùng thông tin xác thực của node.

Roles Anywhere dùng chứng chỉ X.509 và trust anchor/profile đã cấu hình để lấy thông tin xác thực AWS tạm thời. Bảo vệ khóa riêng, kiểm soát việc cấp chứng chỉ, xác thực thuộc tính chứng chỉ trong trust policy được hỗ trợ và lập kế hoạch gia hạn, thu hồi. Chứng chỉ vẫn là vật liệu xác thực nhạy cảm; thay access key bằng một khóa riêng được bảo vệ kém chưa phải cải thiện đầy đủ.

Dùng role policy theo nguyên tắc quyền tối thiểu cho từng API/tài nguyên. Thông tin xác thực tạm thời giảm thời gian phơi nhiễm nhưng vẫn sử dụng được trong phạm vi quyền của nó cho đến khi hết hạn hoặc bị các biện pháp kiểm soát áp dụng chặn lại. Quyền truy cập mạng, endpoint policy và resource/KMS policy vẫn áp dụng độc lập.

Kiểm chứng và khi nào cần đổi phương án

• Chạy một pod không liên quan và xác nhận nó không thể assume role báo cáo hay dùng thông tin xác thực của node.
• Kiểm thử chứng chỉ hết hạn/không được tin cậy và worker ký số yêu cầu tài nguyên không được cấp quyền.
• Luân chuyển chứng chỉ và role mà không nhúng bí mật thay thế vào image.

Một thiết kế IRSA hiện có và được hỗ trợ có thể vẫn phù hợp; đừng chuyển đổi chỉ vì tên dịch vụ thay đổi. SSO cho nhân viên dành cho con người, không thay thế danh tính của workload chạy không có người giám sát.

Điểm cần nhớ và tài liệu AWS

• Danh tính workload và danh tính node không nên dùng thay thế cho nhau.
• Thông tin xác thực tạm thời vẫn cần quan hệ tin cậy và quyền được giới hạn chặt chẽ.
• Vòng đời chứng chỉ là một phần của bảo mật workload bên ngoài.

AWS: EKS Pod Identity · AWS: IAM Roles Anywhere

Dịch vụ trong bài: EKS Pod Identity · IAM Roles Anywhere · STS · IAM · Private CA

Triển khai website nhỏ có xác thực mà không phải bảo trì máy chủ web

Tình huống và yêu cầu

Bạn xây dựng cổng thông tin khách hàng với một ứng dụng đơn trang tĩnh và một API nhỏ. Lưu lượng biến động, người dùng chỉ được đọc bản ghi của chính mình, và nhóm không muốn vá hệ điều hành của máy chủ web.

Một pipeline CI hiện có đảm nhiệm việc build frontend. Bạn cần kiểm soát trực tiếp việc lưu trữ website và hành vi bộ nhớ đệm, phát hành an toàn, và xác thực mà không nhúng thông tin xác thực đám mây vào mã chạy trên trình duyệt.

Đây là bài tập nền tảng web giả định.

Các phương án và quyết định

Dùng S3 riêng tư phía sau CloudFront cho frontend và một backend API được quản lý. Website tĩnh và dữ liệu riêng tư của người dùng có các ranh giới bảo mật khác nhau.

Mô hình tư duy và luồng xử lý

Mã ứng dụng công khai không có nghĩa là dữ liệu ứng dụng cũng công khai.

Trình duyệt → CloudFront → tài nguyên S3 riêng tư
Trình duyệt → đăng nhập Cognito → token → API Gateway → kiểm tra quyền sở hữu tại backend → dữ liệu người dùng

Backend phải quyết định người dùng đã xác thực được phép truy cập bản ghi nào.

Cơ chế cốt lõi

Dùng S3 REST origin được hỗ trợ cùng Origin Access Control thay vì yêu cầu một bucket website công khai. Build các tài nguyên với tên tệp có phiên bản, giữ thời gian lưu bộ nhớ đệm HTML ngắn ở mức phù hợp, và giữ lại một bản phát hành đã được xác nhận hoạt động tốt để rollback. Cấu hình liên kết sâu của SPA mà không vô tình che giấu các lỗi API thực sự.

Với client công khai chạy trên trình duyệt, dùng luồng OAuth Cognito phù hợp có PKCE. Không bao giờ lưu client secret bí mật hay khóa bí mật AWS trong mã frontend. Xác thực token API xác lập danh tính; phân quyền ở cấp tài nguyên vẫn thuộc trách nhiệm của backend.

Không tin rằng userId được gửi lên là bằng chứng về quyền sở hữu. Suy ra hoặc xác minh danh tính từ ngữ cảnh đã xác thực và giới hạn phạm vi thao tác cơ sở dữ liệu tương ứng. Dùng các role backend theo nguyên tắc đặc quyền tối thiểu và các biện pháp điều tiết lưu lượng hoặc kiểm soát WAF phù hợp với rủi ro.

CORS kiểm soát hành vi truy cập khác nguồn của trình duyệt; nó không thay thế kiểm soát truy cập đối với các bên gọi API trực tiếp. Lưu trữ website tĩnh không loại bỏ trách nhiệm bảo mật ứng dụng.

Kiểm chứng và khi nào cần đổi phương án

• Thử cho người dùng A truy cập bản ghi của người dùng B, kể cả khi có token hợp lệ.
• Kiểm thử token hết hạn, liên kết sâu, truy cập bucket trực tiếp và hành vi bộ nhớ đệm khi rollback một bản phát hành.
• Xác minh rằng HTML cũ không thể tham chiếu đến các tài nguyên đã bị xóa trong quá trình triển khai.

Nếu frontend yêu cầu kết xuất phía máy chủ hoặc middleware tùy chỉnh chạy khi xử lý yêu cầu, tầng web chạy trong container có thể phù hợp. Nếu trình duyệt cần truy cập trực tiếp các tài nguyên AWS được hỗ trợ, Cognito identity pool có thể cấp thông tin xác thực AWS tạm thời với phạm vi quyền giới hạn; bản thân user pool chỉ cấp token ứng dụng, không phải thông tin xác thực để gọi API AWS nói chung.

Điểm cần nhớ và tài liệu AWS

• Phân phối nội dung tĩnh và phân quyền backend là hai vấn đề riêng biệt.
• OAC bảo vệ S3 origin, không bảo vệ quyền API ở cấp người dùng.
• Client công khai chạy trên trình duyệt không thể giữ an toàn các thông tin bí mật.
• CORS không phải là phân quyền.
• Tài nguyên có phiên bản và việc kiểm soát bộ nhớ đệm HTML giúp phát hành an toàn hơn.

AWS: CloudFront truy cập nội dung S3 riêng tư

Dịch vụ trong bài: S3 · CloudFront · Cognito · API Gateway · Lambda · ECS

Chia sẻ báo cáo S3 đã mã hóa với tài khoản đối tác

Tình huống và yêu cầu

Bạn duy trì một pipeline báo cáo trong tài khoản A. Một đối tác phân tích trong tài khoản B phải đọc được một prefix S3, nhưng role của họ nhận AccessDenied ngay cả sau khi bạn thêm quyền cho phép trong bucket policy. Các đối tượng sử dụng mã hóa phía máy chủ với AWS KMS.

Bộ phận bảo mật yêu cầu lưu trữ có mã hóa, TLS khi truyền và khả năng kiểm toán việc sử dụng khóa. Không có yêu cầu giữ khóa bên ngoài AWS hay vận hành phần cứng mật mã chuyên dụng. Bạn cần sửa luồng phân quyền mà không làm lộ phần còn lại của bucket.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Dùng khóa KMS do khách hàng quản lý và đồng bộ bucket policy, IAM policy của bên gọi và key policy. Không dùng khóa aws/s3 do AWS quản lý cho yêu cầu chia sẻ liên tài khoản này.

Mô hình tư duy và luồng xử lý

Đọc dữ liệu mã hóa cần mở hai cánh cửa: quyền truy cập đối tượng và quyền truy cập khóa giải mã của đối tượng đó.

Role của đối tác → kiểm tra quyền S3 GetObject → giải mã khóa dữ liệu được KMS cho phép → S3 trả về đối tượng qua TLS

KMS xử lý thao tác với khóa mã hóa, không xử lý toàn bộ nội dung báo cáo.

Cơ chế cốt lõi

Bucket policy của tài khoản A cho phép role của đối tác chỉ đọc prefix đã thống nhất. IAM policy của tài khoản B cho phép đọc các đối tượng đó và thực hiện kms:Decrypt trên khóa cụ thể. Key policy trong A cũng phải cho phép sử dụng liên tài khoản.

Các điều kiện như kms:ViaService và ngữ cảnh mã hóa có thể thu hẹp việc sử dụng khóa, nhưng phải khớp với các yêu cầu thực tế của S3. S3 Bucket Keys thay đổi hành vi liên quan đến ngữ cảnh mã hóa, vì vậy hãy kiểm chứng các điều kiện với cấu hình đã chọn.

Luân chuyển khóa không tự động mã hóa lại tất cả đối tượng hiện có. Bảo vệ khả năng sẵn sàng của khóa và quyền xóa khóa trong suốt thời gian dữ liệu cần duy trì khả năng đọc. TLS bảo vệ đường truyền; KMS bảo vệ dữ liệu lưu trữ. Quản lý chứng chỉ ACM cho endpoint ứng dụng không thay thế quyền KMS.

CloudHSM phù hợp khi thực sự cần kiểm soát HSM chuyên dụng, tích hợp mật mã được hỗ trợ và người dùng/hoạt động vận hành do khách hàng quản lý; đây không phải cách sửa mặc định khi thiếu quyền cho phép trong KMS. Với chứng chỉ dịch vụ riêng tư, hãy so sánh chứng chỉ công khai do ACM quản lý với AWS Private CA và việc phân phối kho chứng chỉ tin cậy cho máy khách. Cấp chứng chỉ, gia hạn, thương lượng giao thức và phân quyền sử dụng khóa là các vòng đời riêng biệt.

Kiểm chứng và khi nào cần đổi phương án

• Đọc một đối tượng được cho phép, thử một prefix khác, rồi gỡ quyền giải mã của role kiểm thử và xác nhận bị từ chối.
• Kiểm tra các sự kiện CloudTrail đã cấu hình cho hoạt động trên đối tượng và khóa.
• Xác minh quản trị viên khôi phục vẫn có thể giải mã các báo cáo được lưu giữ theo các policy dự kiến.

Nếu bản rõ phải được giữ kín với chính dịch vụ xử lý, mã hóa phía máy chủ là chưa đủ. Xem xét lại mã hóa phía máy khách và ai được phép nắm giữ vật liệu giải mã.

Điểm cần nhớ và tài liệu AWS

• Phân quyền S3 và phân quyền KMS là các bước kiểm tra độc lập.
• Truy cập KMS liên tài khoản cần sự phối hợp của cả hai tài khoản.
• Khóa do khách hàng quản lý hỗ trợ các biện pháp kiểm soát chia sẻ cần thiết.
• Luân chuyển khóa không phải mã hóa lại hàng loạt.
• Mã hóa khi lưu trữ, bảo mật đường truyền và khả năng sẵn sàng của khóa giải quyết các rủi ro khác nhau.

AWS: quyền KMS liên tài khoản

Dịch vụ trong bài: S3 · KMS · ACM · CloudHSM

Lập kế hoạch chuyển đổi sang mật mã hậu lượng tử mà không nhầm lẫn chữ ký với mã hóa

Tình huống và yêu cầu

Một công ty lưu giữ các thiết kế mật trong mười lăm năm và ký phần mềm để khách hàng xác minh ngoại tuyến. Bộ phận bảo mật lo ngại kẻ tấn công ghi lại lưu lượng mã hóa ngay bây giờ rồi giải mã về sau. Công ty không thể thay thế mọi máy khách cùng lúc, và thay đổi chữ ký không được khiến thiết bị cũ mất khả năng sử dụng.

Các phương án và quyết định

Dùng kế hoạch linh hoạt về mật mã: TLS hậu lượng tử lai được hỗ trợ cho nhu cầu bảo mật dài hạn, và một luồng ký ML-DSA được kiểm chứng riêng khi bộ xác minh hỗ trợ. Đừng gọi toàn bộ ứng dụng là an toàn trước máy tính lượng tử chỉ vì một kết nối AWS API dùng cơ chế bắt tay mới hơn.

Mô hình tư duy và luồng xử lý

Thiết lập khóa bảo vệ một phiên; chữ ký chứng minh tính xác thực; mã hóa đối xứng bảo vệ dữ liệu.

Máy khách + endpoint → trao đổi khóa lai được thương lượng → phiên TLS đối xứng

Artifact phần mềm → khóa ký KMS ML-DSA → chữ ký → bộ xác minh ngoại tuyến tương thích

Cơ chế cốt lõi

AWS KMS hỗ trợ trao đổi khóa TLS lai kết hợp ECDH cổ điển với ML-KEM. Ngăn xếp phần mềm phía máy khách và endpoint phải thương lượng được tổ hợp được hỗ trợ. Hãy kiểm kê cả proxy và thiết bị kiểm tra lưu lượng: một thiết bị trung gian có thể kết thúc kết nối được bảo vệ và mở một kết nối khác ở phía sau.

Khóa KMS ML-DSA là khóa ký bất đối xứng. Chúng không thay thế khóa dữ liệu đối xứng của S3 hay biến chữ ký thành nội dung mã hóa. Xác minh hỗ trợ thuật toán, kích thước chữ ký, quy tắc tiền xử lý thông điệp và khả năng tương thích của bộ xác minh bên ngoài trước khi thay đổi định dạng artifact phần mềm.

Ưu tiên dữ liệu cần giữ bí mật lâu dài và khóa công khai được nhúng trong sản phẩm có vòng đời dài. Đánh phiên bản cho siêu dữ liệu chữ ký, lập kế hoạch phân phối gốc tin cậy và duy trì chiến lược tương thích có kiểm soát. Không âm thầm chuyển về thuật toán không được phép khi thương lượng thất bại.

Kiểm chứng và khi nào cần đổi phương án

• Kiểm tra cơ chế trao đổi khóa TLS thực sự được thương lượng, bao gồm cả proxy.
• Xác minh artifact phần mềm hợp lệ và đã bị sửa đổi với từng thế hệ máy khách được hỗ trợ.
• Đo độ trễ, kích thước payload, tỷ lệ thất bại và khả năng rollback trong vận hành.

Nếu một thiết bị không thể cập nhật bộ xác minh, việc chuyển đổi gốc tin cậy của nó có thể là dự án then chốt. Một tập dữ liệu tồn tại ngắn có mức phơi nhiễm về tính bí mật khác, nhưng vẫn cần kiểm soát truy cập và quản lý khóa thông thường.

Điểm cần nhớ và tài liệu AWS

• ML-KEM là cơ chế đóng gói khóa; ML-DSA là ký số.
• Luân chuyển khóa không phải chuyển đổi thuật toán của khóa.
• Hỗ trợ hậu lượng tử phải bao phủ toàn bộ đường xử lý liên quan.

AWS: TLS hậu lượng tử lai · AWS: khóa ML-DSA

Dịch vụ trong bài: KMS · ACM · Secrets Manager

Tách biệt môi trường sản phẩm mà vẫn duy trì quản trị tập trung

Tình huống và yêu cầu

Bạn dẫn dắt đội nền tảng của một nhà bán lẻ có các đội sản phẩm dùng chung một tài khoản AWS. Một lần dọn dẹp môi trường phát triển đã xóa mất tài nguyên production, và các đội tranh nhau hạn ngạch cấp tài khoản. Đội bảo mật muốn tăng cường cô lập, trong khi lập trình viên vẫn cần triển khai mà không phải tạo phiếu yêu cầu cho từng thay đổi.

Bạn phải tách production khỏi hoạt động thử nghiệm, duy trì quản lý danh tính và kiểm toán tập trung, đồng thời xác định rõ trách nhiệm chi phí. Việc di chuyển các workload hiện có không được làm gián đoạn quy trình thanh toán.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Sử dụng AWS Organizations và một landing zone của Control Tower, tách các workload production quan trọng khỏi môi trường ngoài production. Nhóm các tài khoản vào các đơn vị tổ chức (OU) theo biện pháp kiểm soát cần thiết, không chỉ theo sơ đồ tổ chức công ty.

Mô hình tư duy và luồng xử lý

Tài khoản tạo ra ranh giới; tổ chức quản trị những ranh giới đó.

Nhân viên → bộ quyền Identity Center → role trong tài khoản workload → yêu cầu API được đánh giá theo IAM và các biện pháp kiểm soát của tổ chức

Hoạt động kiểm toán đi theo một luồng riêng đến tài khoản lưu trữ log được bảo vệ.

Cơ chế cốt lõi

Không đặt workload thông thường trong tài khoản quản lý. Sử dụng tài khoản bảo mật và tài khoản lưu trữ log cho từng trách nhiệm tương ứng, với quản trị viên được ủy quyền ở nơi có hỗ trợ.

Service control policy (SCP) giới hạn các quyền khả dụng cho những tài khoản chịu tác động; nó không cấp quyền. Role của workload vẫn cần một quyền cho phép từ IAM. Control Tower thiết lập và quản trị landing zone trong phạm vi đã cấu hình, chứ không tự động bảo đảm mọi tài nguyên đều an toàn.

Quy trình tiếp nhận cần có người chịu trách nhiệm, phân bổ địa chỉ, ngân sách, ghi log, chính sách sao lưu và quy trình ngừng sử dụng. Nhìn chung, bạn không thể di chuyển tài nguyên hiện có bằng cách thay đổi một trường tài khoản: hãy lập kế hoạch di chuyển theo từng dịch vụ, truyền dữ liệu và chuyển đổi vận hành.

Quan hệ tin cậy liên tài khoản và chính sách tài nguyên công khai có thể vượt qua các ranh giới dự kiến. Hãy rà soát rõ những yếu tố này thay vì cho rằng tách tài khoản sẽ ngăn được mọi đường truy cập.

Kiểm chứng và khi nào cần đổi phương án

• Xác minh quản trị viên môi trường phát triển không thể sửa đổi production hoặc log kiểm toán đã lưu trữ.
• Tạo một tài khoản mẫu và xác nhận danh tính, biện pháp kiểm soát và ghi log trước khi bàn giao.
• Diễn tập di chuyển một workload, bao gồm rollback và quyền truy cập các thành phần phụ thuộc.

Một dự án thử nghiệm rất nhỏ có thể không cần một tài khoản cho từng thành phần. Ranh giới hữu ích là khác biệt có ý nghĩa về rủi ro, quyền sở hữu hoặc biện pháp kiểm soát, chứ không phải số lượng tài khoản tối đa có thể tạo.

Điểm cần nhớ và tài liệu AWS

• Tách tài khoản giúp giảm rủi ro do dùng chung phạm vi quản trị và hạn ngạch.
• OU nhóm các tài khoản cần những biện pháp kiểm soát tương tự.
• SCP giới hạn quyền; IAM cấp quyền.
• Quản trị tập trung không đòi hỏi tập trung workload.
• Di chuyển liên tài khoản và truy cập liên tài khoản cần các thiết kế riêng.

AWS: tổ chức môi trường đa tài khoản

Dịch vụ trong bài: Organizations · Control Tower · IAM

Cho phép lập trình viên tạo role ứng dụng mà không leo thang đặc quyền

Tình huống và yêu cầu

Bạn phụ trách kiểm soát truy cập đám mây cho một công ty phần mềm. Lập trình viên triển khai ứng dụng Lambda và container thông qua hạ tầng dưới dạng mã, nhưng mỗi execution role mới hiện đều phải chờ đội bảo mật phê duyệt.

Đội bảo mật chỉ ủy quyền tạo role nếu lập trình viên không thể tạo quản trị viên IAM, chuyển giao role đặc quyền cho dịch vụ hoặc triển khai ngoài các Region được phê duyệt. Bạn cần các biện pháp ràng buộc có thể tái sử dụng, thay vì một hàng đợi phiếu yêu cầu xử lý nhanh hơn.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Ủy quyền tạo role có giới hạn. Sử dụng permissions boundary đã được phê duyệt cho các role ứng dụng và SCP cho những hạn chế áp dụng trên toàn tổ chức.

Mô hình tư duy và luồng xử lý

Quyền cho phép cấp một hành động; boundary giới hạn những gì quyền đó có thể thực hiện.

Lập trình viên → CreateRole với boundary đã được phê duyệt → gắn chính sách workload → PassRole trong phạm vi giới hạn → dịch vụ ứng dụng đảm nhận role

Bảo vệ từng bước. Luồng tạo role bị hạn chế sẽ vô hiệu nếu lập trình viên có thể chuyển giao một role quản trị viên hiện có thay thế.

Cơ chế cốt lõi

Chỉ cho phép CreateRole khi yêu cầu gắn boundary đã được phê duyệt. Ngăn lập trình viên gỡ boundary đó, thay bằng boundary yếu hơn hoặc chỉnh sửa chính sách của nó. Giới hạn iam:PassRole vào các role và dịch vụ đích được phê duyệt.

Chính sách ứng dụng cấp các hành động nghiệp vụ cụ thể. Boundary đặt trần cho quyền dựa trên danh tính; bản thân nó không cấp quyền gì. Từ chối tường minh vẫn có tính quyết định. Việc cấp quyền dựa trên tài nguyên, đặc biệt là cấp trực tiếp cho ARN của phiên role, có những điểm tinh tế trong cách đánh giá, vì vậy đừng coi từ chối ngầm định của boundary là một từ chối tường minh áp dụng phổ quát.

Áp dụng hạn chế Region thông qua các điều kiện SCP có phạm vi được xác định cẩn thận, chẳng hạn aws:RequestedRegion, có tính đến ngoại lệ cho dịch vụ toàn cầu. SCP không giới hạn tài khoản quản lý hoặc service-linked role theo cùng cách như các role thông thường trong tài khoản thành viên.

Resource control policy (RCP) giới hạn truy cập vào các tài nguyên được hỗ trợ trong tài khoản thành viên, bao gồm cả truy cập do principal bên ngoài thực hiện. SCP chủ yếu giới hạn các principal chịu tác động trong tổ chức. Cả hai đều không cấp quyền truy cập; hãy kiểm tra dịch vụ được hỗ trợ, ngoại lệ đối với principal, chính sách tài nguyên và từ chối tường minh. Sử dụng RCP cho vành đai bảo vệ dữ liệu phía tài nguyên, không dùng nó thay cho boundary của role.

Kiểm tra cả role của dịch vụ triển khai. Chỉ giới hạn danh tính con người là chưa đủ nếu CloudFormation hoặc một dịch vụ triển khai khác thực thi với đặc quyền không bị giới hạn.

Kiểm chứng và khi nào cần đổi phương án

• Thử tạo role không có boundary, sửa boundary và chuyển giao role quản trị viên; xác minh các thao tác bị từ chối.
• Xác nhận một lần triển khai được phép thành công và một lần triển khai vào Region không được phép thất bại mà không làm hỏng các dịch vụ toàn cầu cần thiết.
• Rà soát các đường cấp quyền qua chính sách tài nguyên và role triển khai để tìm quyền được cấp ngoài dự kiến.

Workload cần đặc quyền bảo mật ngoại lệ vẫn có thể cần role được quản lý tập trung. Mục tiêu là ủy quyền an toàn cho công việc thông thường, không phải loại bỏ mọi ranh giới phê duyệt.

Điểm cần nhớ và tài liệu AWS

• Permissions boundary và SCP không cấp quyền truy cập.
• Bảo vệ chính boundary, không chỉ việc gắn nó ban đầu.
• PassRole có thể mở ra đặc quyền mà lập trình viên không thể trực tiếp đảm nhận.
• Role của dịch vụ triển khai là một phần của luồng phân quyền.
• Việc đánh giá IAM có những điểm tinh tế liên quan đến chính sách tài nguyên và loại principal.

AWS: permissions boundary

Dịch vụ trong bài: IAM · Organizations

Bảo toàn bằng chứng kiểm toán bên ngoài tài khoản workload bị xâm nhập

Tình huống và yêu cầu

Bạn vận hành bảo mật cho một công ty có 40 tài khoản AWS. Trong một cuộc điều tra, bạn cần xác định ai đã thay đổi tài nguyên và liệu thay đổi đó có xảy ra trước hoạt động đáng ngờ hay không. Log do quản trị viên của tài khoản bị ảnh hưởng kiểm soát không đủ để bảo vệ bằng chứng.

Bạn cần các bản ghi kiểm toán được lưu giữ tập trung, lịch sử cấu hình, cảnh báo mối đe dọa và một luồng đáng tin cậy đến đội trực. Quản trị viên workload không được có khả năng xóa bằng chứng đã lưu trữ hoặc tắt trail của tổ chức.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Sử dụng trail CloudTrail của tổ chức gửi đến tài khoản lưu trữ log, cùng với lịch sử Config và khả năng phát hiện mối đe dọa được quản lý tập trung.

Mô hình tư duy và luồng xử lý

Log kiểm toán ghi lại hành động; phát hiện bảo mật diễn giải rủi ro. Bạn cần cả hai.

Hành động API của workload → trail của tổ chức → kho lưu trữ S3 được bảo vệ
Cấu hình tài nguyên → bộ ghi Config → bộ tổng hợp
Phát hiện mối đe dọa → EventBridge → quy trình xử lý sự cố bảo mật

Đây là các luồng bổ trợ nhau, không phải ba bản sao của cùng một thông tin.

Cơ chế cốt lõi

Cấu hình trail trên các Region cần thiết. Sự kiện quản lý và sự kiện dữ liệu là hai loại khác nhau: hãy chọn rõ những thao tác dữ liệu nhạy cảm cần ghi lại thay vì cho rằng mọi truy cập đối tượng đều được ghi theo mặc định. Tính đến chi phí của chúng.

Bảo vệ chính sách bucket và KMS của kho lưu trữ, thời gian lưu giữ và các role quản trị. Object Lock có thể bổ sung tính bất biến khi cần. Tách quyền truy cập phục vụ điều tra khỏi quản trị workload và bảo vệ cả cấu hình ghi log.

Bộ ghi Config phải được bật trong các tài khoản và Region liên quan. Bộ tổng hợp thu thập các bản ghi hiện có; nó không kích hoạt việc ghi. GuardDuty tạo các phát hiện mối đe dọa, còn Security Hub tổng hợp các phát hiện và thông tin về trạng thái bảo mật. Chủ động cấu hình quản trị được ủy quyền và độ bao phủ theo Region của từng dịch vụ.

Để phân tích tập trung, Security Lake chuẩn hóa các nguồn bảo mật được hỗ trợ vào một kho dữ liệu dạng lake dựa trên S3; nó không thay thế việc bật các nguồn đó. Subscription liên tài khoản của CloudWatch Logs có thể truyền liên tục các log ứng dụng được chọn đến một đích tập trung với quyền đích và thời gian lưu giữ được xác định rõ. Ghi log lời gọi mô hình AI là một cấu hình riêng: quyết định liệu prompt/phản hồi có được lưu hay không, giảm thiểu nội dung nhạy cảm và bảo vệ kho lưu trữ thay vì cho rằng CloudTrail chứa mọi payload của mô hình.

Định tuyến các phát hiện cần hành động qua EventBridge với quyền bus, bộ lọc mức độ nghiêm trọng và biện pháp ngăn vòng lặp được xác định rõ. Gửi mọi sự kiện đến thiết bị báo động cho người trực không phải là một thiết kế ứng phó khả dụng.

Kiểm chứng và khi nào cần đổi phương án

• Thực hiện một thay đổi API có kiểm soát rồi tìm chủ thể thực hiện và dấu thời gian của nó trong kho lưu trữ, cùng thay đổi cấu hình tương ứng trong Config.
• Sử dụng một phát hiện mẫu để xác minh việc chuyển đến đúng người ứng phó.
• Xác nhận quản trị viên workload không thể sửa bản ghi đã lưu trữ; kiểm tra thời gian lưu giữ và quyền giải mã.

Nếu câu hỏi liên quan đến sự kiện nghiệp vụ của ứng dụng thay vì hoạt động API AWS, hãy bổ sung ghi log kiểm toán ứng dụng. Không dịch vụ nào trong số này tự động giải thích mọi đơn hàng hoặc hành động của khách hàng.

Điểm cần nhớ và tài liệu AWS

• CloudTrail ghi lại hoạt động API; Config ghi lại cấu hình tài nguyên.
• Các phát hiện không thay thế bằng chứng gốc.
• Tổng hợp không tự động bật thu thập.
• Bảo vệ bằng chứng bao gồm quyền đối với khóa mã hóa và quyền kiểm soát ghi log.
• Việc chuyển cảnh báo cần người nhận và hành động đã được kiểm thử, không chỉ một bảng điều khiển.

AWS: trail của tổ chức

Dịch vụ trong bài: CloudTrail · Config · GuardDuty · Security Hub · Security Lake · CloudWatch Logs · EventBridge

Chia sẻ mạng trong khi các đội sản phẩm vẫn giữ tài khoản AWS riêng

Tình huống và yêu cầu

Bạn quản lý nền tảng mạng cho nhiều đội sản phẩm trong cùng một tổ chức AWS. Hiện tại, mỗi tài khoản mới đều tạo lại subnet, chuyển tiếp DNS và cấu hình lưu lượng đi ra. Những khác biệt nhỏ liên tục gây ra sự cố kết nối.

Đội mạng cần sở hữu các tuyến mạng và DNS, còn các đội sản phẩm triển khai và trả tiền cho tài nguyên tính toán của mình. Các đội này không cần ranh giới định tuyến VPC riêng; họ cần quyền sở hữu tài khoản riêng và không có quyền thay đổi mạng dùng chung.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Chia sẻ các subnet được phê duyệt bằng AWS RAM. Giữ quyền định tuyến ở tài khoản mạng thay vì cấp quyền quản trị viên.

Mô hình tư duy và luồng xử lý

Chia sẻ subnet giống như thuê không gian trong một tòa nhà được quản lý: bên thuê sở hữu thiết bị của mình, không sở hữu các lối ra của tòa nhà.

Role triển khai của tài khoản sản phẩm → tài nguyên được hỗ trợ trong subnet dùng chung → tuyến mạng/DNS do chủ sở hữu quản lý → đích

Tài nguyên thuộc về tài khoản tham gia dù mạng bao quanh thuộc về chủ sở hữu.

Cơ chế cốt lõi

Bật chia sẻ trong tổ chức theo yêu cầu và chia sẻ subnet với các tài khoản hoặc OU đủ điều kiện. Chia sẻ subnet VPC có các ràng buộc về tổ chức và theo từng dịch vụ; hãy xác minh khả năng hỗ trợ cho từng loại tài nguyên dự định sử dụng.

Bên tham gia tạo và quản lý các tài nguyên workload được hỗ trợ cùng biện pháp kiểm soát bảo mật liên quan trong mô hình được phép. Họ không có quyền đối với bảng định tuyến của chủ sở hữu chỉ nhờ được chia sẻ subnet.

Chia sẻ riêng các quy tắc chuyển tiếp Resolver khi cần. Chủ sở hữu vẫn vận hành các endpoint DNS và kết nối đến đích của chúng. RAM là cơ chế chia sẻ, không phải quyền cấp chung cho mọi API AWS hoặc loại tài nguyên.

Ghi rõ ai xử lý việc cạn địa chỉ IP, hạn ngạch và sự cố mạng. Mức sử dụng tài nguyên tính toán của bên tham gia được tính phí cho tài khoản của họ, còn chi phí NAT, DNS hoặc kết nối dùng chung cần một phương pháp phân bổ được thống nhất. Hóa đơn tài khoản riêng không tự động giải thích chi phí mạng dùng chung.

Kiểm chứng và khi nào cần đổi phương án

• Triển khai một workload được hỗ trợ từ tài khoản tham gia và xác minh kết nối dự kiến.
• Xác nhận quản trị viên bên tham gia không thể sửa các tuyến mạng của chủ sở hữu.
• Kiểm tra dung lượng địa chỉ, hạn ngạch dịch vụ, hành vi DNS và báo cáo chi phí dùng chung trước khi tiếp nhận thêm đội.

Chọn các VPC riêng kết nối qua TGW nếu các đội cần định tuyến độc lập hoặc cô lập sự cố mạng mạnh hơn. Tránh ép mô hình subnet dùng chung lên các workload có yêu cầu kiểm soát không tương thích.

Điểm cần nhớ và tài liệu AWS

• Chia sẻ VPC tách quyền sở hữu workload khỏi quyền sở hữu mạng.
• RAM không khiến mọi dịch vụ hoặc tài nguyên đều có thể chia sẻ.
• Các quy tắc DNS dùng chung vẫn phụ thuộc vào endpoint và tuyến mạng hoạt động bình thường.
• Dung lượng IP và sự cố mạng trở thành mối quan tâm vận hành chung.
• Việc tính phí theo tài khoản không tự động phân bổ chi phí hạ tầng chung.

AWS: chia sẻ VPC

Dịch vụ trong bài: RAM · VPC · Route 53 Resolver

Bàn giao tài khoản sẵn sàng sử dụng cho các đội dự án thay vì tài khoản còn dang dở

Tình huống và yêu cầu

Bạn vận hành một nền tảng đám mây mở tài khoản cho các dự án mới mỗi tháng. Quản trị viên làm theo danh sách kiểm tra, nhưng đôi khi các đội nhận quyền truy cập trước khi cấu hình ghi log, danh tính hoặc mạng hoàn tất.

Trưởng nhóm nền tảng muốn quy trình bàn giao tài khoản có kết quả nhất quán, dự đoán được và các stack ứng dụng tự phục vụ đã được phê duyệt. Tài khoản phải có người chịu trách nhiệm, đúng đơn vị tổ chức, được bao phủ bởi hoạt động kiểm toán và có quyền truy cập sử dụng được trước khi bàn giao. Việc thiết lập thất bại phải có thể khôi phục mà không tạo tài khoản trùng lặp hoặc bỏ mặc tài nguyên mới tạo một phần.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Sử dụng Control Tower Account Factory để cấp tài khoản có quản trị, sau đó áp dụng các tùy chỉnh cần thiết và xác minh mức độ sẵn sàng. Triển khai các mẫu workload đã được phê duyệt thông qua pipeline có phạm vi giới hạn sau khi bàn giao.

Mô hình tư duy và luồng xử lý

Tạo tài khoản, chuẩn bị tài khoản và triển khai sản phẩm là ba công việc khác nhau.

Yêu cầu đã được phê duyệt → Account Factory → tùy chỉnh cấu hình nền tảng → kiểm tra mức độ sẵn sàng → quyền truy cập cho đội → triển khai workload đã được phê duyệt

Phản hồi tạo tài khoản thành công chỉ là một cột mốc, không phải điều kiện nghiệm thu cuối cùng.

Cơ chế cốt lõi

Thu thập người chịu trách nhiệm dự án, email tài khoản, OU đích và ngân sách trước khi cấp tài khoản. Quản trị của Control Tower áp dụng trong phạm vi landing zone đã cấu hình; các cảnh báo ứng dụng, role hoặc tài nguyên mạng bổ sung vẫn cần tùy chỉnh.

Sử dụng StackSets hoặc pipeline hạ tầng hiện có cho các tài nguyên nền tảng lặp lại. Giới hạn đặc quyền của execution role và kiểm thử thay đổi trong OU sandbox trước khi triển khai diện rộng. Nếu không, một mẫu lỗi áp dụng toàn tổ chức có thể lan truyền cùng một sự cố ngừng hoạt động đến mọi nơi.

Quản lý phiên bản các mẫu workload tách biệt với cấu hình nền tảng tài khoản. Giới hạn role triển khai và tham số được phép, đồng thời yêu cầu rà soát change set khi việc triển khai có thể thay thế tài nguyên có trạng thái. Công bố một mẫu không tự động cập nhật các stack hiện có. Account Factory và pipeline triển khai quản lý các vòng đời khác nhau.

Kiểm tra mức độ sẵn sàng cần xác minh quyền truy cập thực tế, việc chuyển log, các biện pháp kiểm soát và kết nối. Theo dõi tiến độ hoàn tất từng phần để các lần thử lại tiếp tục an toàn. Duy trì quy trình ngừng sử dụng để loại bỏ quyền truy cập trong khi vẫn giữ các bản ghi kiểm toán cần thiết.

Kiểm chứng và khi nào cần đổi phương án

• Cấp một tài khoản mẫu và chứng minh từng yêu cầu bàn giao đã được đáp ứng.
• Ngắt một bước tùy chỉnh, sau đó thử lại mà không tạo tài nguyên trùng lặp.
• Nâng cấp một sản phẩm mẫu và kiểm tra sai lệch cấu hình, rollback và trách nhiệm quản lý phiên bản.

Một tập hợp tài khoản nhỏ, cố định có thể chỉ cần StackSets cho cấu hình nền tảng thay vì toàn bộ quy trình yêu cầu tài khoản. Ngược lại, việc cấp tài khoản có mức tùy chỉnh cao có thể đáng để xây dựng một pipeline cấp tài khoản chuyên dụng trong cùng các ranh giới quản trị đó.

Điểm cần nhớ và tài liệu AWS

• Tạo tài khoản không đồng nghĩa với sẵn sàng vận hành.
• StackSets phân phối hạ tầng, không xử lý mọi quyết định về vòng đời tài khoản.
• Triển khai workload và cấp tài khoản là các vòng đời khác nhau.
• Thay đổi cấu hình nền tảng cần triển khai theo giai đoạn và giới hạn đặc quyền thực thi.
• Công bố sản phẩm và nâng cấp sản phẩm đã cài đặt là các sự kiện riêng biệt.

AWS: Account Factory

Dịch vụ trong bài: Control Tower · CloudFormation StackSets · CodePipeline

Khắc phục sai lệch bảo mật tái diễn mà không gây gián đoạn do tự động hóa

Tình huống và yêu cầu

Bạn phụ trách kỹ thuật bảo mật cho nhiều nhóm ứng dụng. Các đợt rà soát hằng quý liên tục phát hiện cùng những vấn đề: cấu hình lưu trữ công khai và máy chủ chưa vá lỗi. Các nhóm sửa từng tài nguyên, nhưng template triển khai của họ lại tái tạo các điểm yếu.

Bạn cần phát hiện nhanh hơn và phòng ngừa bền vững. Các thay đổi an toàn, được phê duyệt trước có thể chạy tự động; thay đổi trên production có thể làm gián đoạn dịch vụ cần phê duyệt và rollback. Chỉ đạt điểm cao trên bảng điều khiển không phải mục tiêu.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Kết hợp phòng ngừa, phát hiện và ứng phó dựa trên rủi ro. Sửa cả template hạ tầng lẫn tài nguyên đang chạy, và chỉ tự động hóa những hành động đã hiểu rõ tác động.

Mô hình tư duy và luồng xử lý

Một phát hiện khởi đầu cho việc ra quyết định, không phải một thao tác ghi vô điều kiện vào production.

Phát hiện từ Config/Inspector → phân loại rủi ro → kiểm tra lại trạng thái hiện tại → tự động hóa đã được phê duyệt hoặc phê duyệt của con người → khắc phục → xác minh

Việc kiểm tra lại quan trọng vì phát hiện có thể đã lỗi thời vào lúc quy trình thực hiện hành động.

Cơ chế cốt lõi

AWS Config đánh giá cấu hình tài nguyên; Inspector đánh giá lỗ hổng trên các tài nguyên được hỗ trợ; Security Hub tổng hợp tình trạng bảo mật và các phát hiện. Ưu tiên dựa trên mức độ phơi nhiễm, khả năng khai thác, độ nhạy cảm của dữ liệu và tác động kinh doanh, không chỉ dựa vào điểm mức độ nghiêm trọng.

Dùng EventBridge và Systems Manager Automation hoặc một quy trình có giới hạn tương đương cho các phát hiện được chọn. Làm cho việc khắc phục có tính idempotent, giới hạn từng đợt triển khai và tránh kích hoạt vòng lặp sự kiện-khắc phục vô tận. Yêu cầu phê duyệt cho các thay đổi như vá máy chủ quan trọng hoặc thay đổi kết nối production, trừ khi đã được cho phép trước một cách rõ ràng.

Ngăn vi phạm lặp lại thông qua template hạ tầng đã được rà soát và các biện pháp kiểm soát cấp tổ chức được hỗ trợ. Duy trì các ngoại lệ có tài liệu, người chịu trách nhiệm và ngày hết hạn thay vì các mục loại trừ âm thầm tồn tại vĩnh viễn.

Audit Manager có thể thu thập bằng chứng; Artifact cung cấp báo cáo và thỏa thuận của AWS. Không công cụ nào tự động chứng nhận tính bảo mật hay tuân thủ của ứng dụng của bạn.

Kiểm chứng và khi nào cần đổi phương án

• Tạo một vi phạm có kiểm soát trong sandbox và quan sát việc phát hiện, khắc phục, xác minh.
• Đưa một phát hiện lỗi thời vào quy trình và xác nhận nó không hoàn tác một thay đổi hợp lệ diễn ra sau đó.
• Diễn tập khắc phục thất bại, rollback và một ngoại lệ sắp hết hạn.

Một workload cũ dễ gặp sự cố ban đầu có thể cần phát hiện và con người rà soát thay vì thay đổi tự động. Chỉ tăng tự động hóa sau khi hiểu các trường hợp thất bại của nó, không phải để cải thiện chỉ số trên bảng điều khiển.

Điểm cần nhớ và tài liệu AWS

• Tuân thủ cấu hình và phát hiện lỗ hổng phần mềm là hai việc khác nhau.
• Xác thực lại phát hiện trước khi sửa tài nguyên.
• Tự động hóa an toàn cần phạm vi giới hạn và hành vi có thể lặp lại.
• Sửa nguồn triển khai ngăn sai lệch tái diễn.
• Thu thập bằng chứng không phải tự động chứng nhận tuân thủ.

AWS: khắc phục với Config

Dịch vụ trong bài: Config · Security Hub · Inspector · Systems Manager · Audit Manager · Artifact

Lưu giữ hồ sơ đã ký mà không cho phép xóa sớm

Tình huống và yêu cầu

Bạn thiết kế hệ thống lưu trữ tài liệu cho một công ty bảo hiểm. Bộ phận pháp lý đã xác nhận một loại hồ sơ đã ký cụ thể phải giữ nguyên, không thể sửa đổi trong bảy năm. Quản trị viên thông thường, bao gồm quản trị viên cấp tài khoản, không được có khả năng rút ngắn thời hạn lưu giữ đó.

Hồ sơ chứa dữ liệu cá nhân, nên việc đọc cần tuân theo nguyên tắc quyền tối thiểu. Hồ sơ cũ hiếm khi được truy cập và có thể chấp nhận thời gian truy xuất vài giờ. Bạn cần lưu giữ, bảo mật và lưu trữ dài hạn với chi phí hợp lý mà không khiến tài liệu được lưu giữ trở nên không thể giải mã.

Đây là bài tập giả định; yêu cầu pháp lý là đầu vào được giả định, không phải tư vấn pháp lý.

Các phương án và quyết định

Dùng Object Lock ở chế độ compliance cho loại hồ sơ đã được xác nhận, cùng với mã hóa và chuyển lớp lưu trữ bằng Lifecycle. Kiểm chứng chính sách trên dữ liệu mẫu trước khi áp dụng thời hạn lưu giữ dài cho hồ sơ thật.

Mô hình tư duy và luồng xử lý

Cơ chế lưu giữ bảo vệ một phiên bản đã lưu cụ thể; phân quyền kiểm soát ai được đọc phiên bản đó.

Hồ sơ đã ký → đối tượng S3 có phiên bản và thời hạn lưu giữ → chuyển sang lớp lưu trữ dài hạn → khôi phục được cấp quyền → giải mã KMS → người đọc

Giữ lại các byte là chưa đủ nếu nhiều năm sau khóa hoặc quy trình khôi phục không còn khả dụng.

Cơ chế cốt lõi

Object Lock sử dụng S3 Versioning. Áp dụng thời hạn lưu giữ cho từng phiên bản liên quan hoặc đặt mặc định phù hợp cho đối tượng mới. Chế độ compliance ngăn xóa hoặc rút ngắn thời hạn lưu giữ đang có hiệu lực, kể cả với root user. Legal hold là biện pháp riêng và kéo dài cho đến khi được một principal có quyền chủ động gỡ bỏ.

Dùng bucket/IAM policy hạn chế quyền, Block Public Access, TLS và mã hóa phù hợp. Bảo vệ quyền xóa và truy cập khóa KMS trong toàn bộ thời gian lưu giữ. Macie có thể giúp nhận diện nội dung nhạy cảm, nhưng không tự động thực thi mọi chính sách truy cập cần thiết.

Chọn lớp lưu trữ dài hạn và cấp khôi phục đáp ứng khoảng thời gian truy xuất cho phép. Cơ chế hết hạn của Lifecycle không thể xóa một phiên bản được bảo vệ khi thời hạn lưu giữ hoặc legal hold còn ngăn việc đó. Delete marker có thể ẩn đối tượng khỏi chế độ xem hiện tại mà không xóa phiên bản đã khóa.

Kiểm chứng và khi nào cần đổi phương án

• Thử xóa sớm và giảm thời hạn lưu giữ bằng một tài khoản quản trị viên kiểm thử.
• Khôi phục một hồ sơ kiểm thử đã chuyển sang lớp lưu trữ dài hạn và giải mã thông qua role khôi phục dự kiến.
• Xác minh chỉ loại hồ sơ thuộc phạm vi pháp lý mới được áp dụng thời hạn lưu giữ dài.

Nếu quản trị viên có quyền phải giữ khả năng bỏ qua trong trường hợp khẩn cấp, chế độ governance có thể phù hợp hơn. Không áp dụng thời hạn lưu giữ nghiêm ngặt bảy năm một cách tràn lan cho dữ liệu có nghĩa vụ xóa hoặc giảm thiểu khác.

Điểm cần nhớ và tài liệu AWS

• Quản lý vòng đời không đồng nghĩa với tính bất biến.
• Object Lock bảo vệ các phiên bản đối tượng.
• Chế độ governance và compliance có hành vi bỏ qua khác nhau.
• Legal hold và lưu giữ theo thời hạn là các biện pháp riêng biệt.
• Lưu giữ phải bảo toàn cả dữ liệu lẫn quyền giải mã có thể sử dụng được.

AWS: S3 Object Lock

Dịch vụ trong bài: S3 Object Lock · Macie · KMS

Thực thi yêu cầu về nơi lưu trú dữ liệu cho bản sao lưu, suy luận AI và bằng chứng kiểm toán

Tình huống và yêu cầu

Một doanh nghiệp chịu sự quản lý của các quy định chỉ cho phép hồ sơ khách hàng nằm trong một nhóm Region được phê duyệt. Nhóm của họ muốn có khả năng khôi phục liên Region và một trợ lý AI tạo sinh. Kiểm toán viên yêu cầu bằng chứng về cấu hình và các biện pháp kiểm soát vận hành, không chỉ một ảnh chụp màn hình cho thấy AWS có chứng nhận tuân thủ.

Các phương án và quyết định

Lập bản đồ mọi đích lưu trữ và xử lý, sau đó thực thi tập đích được phê duyệt. Xem báo cáo AWS Artifact là bằng chứng từ nhà cung cấp và dùng Audit Manager cùng các biện pháp kiểm soát do bạn chịu trách nhiệm cho chương trình bằng chứng phía khách hàng.

Mô hình tư duy và luồng xử lý

Nơi lưu trú dữ liệu đi theo sự di chuyển của dữ liệu, không phải Region hiển thị trên trang console của ứng dụng.

Hồ sơ → lưu trữ chính → bản sao/bản sao lưu → log → ngữ cảnh AI → đích suy luận → phản hồi được lưu giữ

Mỗi mũi tên cần có mục đích, đích đến, quyền cho phép và chính sách lưu giữ được ghi thành tài liệu.

Cơ chế cốt lõi

Lập mô hình mối đe dọa cho luồng trước khi chọn biện pháp kiểm soát: tài sản là hồ sơ khách hàng và bằng chứng kiểm toán; các ranh giới bao gồm tài khoản workload, tài khoản ghi log tập trung và endpoint mô hình. Cân nhắc tình huống role của workload bị xâm phạm rồi xuất hồ sơ hoặc sửa bằng chứng của chính nó. Ánh xạ mỗi mối đe dọa tới một biện pháp phòng ngừa và một tín hiệu phát hiện được lưu giữ độc lập, chỉ định người chịu trách nhiệm và ghi lại rủi ro còn lại.

Chọn Region được phép từ các yêu cầu pháp lý và hợp đồng. Áp dụng các biện pháp kiểm soát Organizations/Control Tower phù hợp và cấu hình dịch vụ rõ ràng. Điều kiện về Region của yêu cầu không phải bảo đảm phổ quát cho nơi lưu trú dữ liệu: dịch vụ toàn cầu và việc chuyển dữ liệu do dịch vụ thực hiện cần phân tích riêng theo dịch vụ.

Với suy luận liên Region của Bedrock, kiểm tra các Region đích đủ điều kiện trong profile và các yêu cầu IAM/SCP tương ứng. Profile địa lý và profile toàn cầu có tác động khác nhau tới nơi lưu trú dữ liệu. Nếu tập Region được phép không đáp ứng được một profile, chọn mô hình/luồng xử lý trong Region đã được phê duyệt hoặc thay đổi yêu cầu dịch vụ qua đúng quy trình phê duyệt; không lách lệnh từ chối ở cấp tổ chức.

Giới hạn sao chép bản sao lưu, tác vụ xuất dữ liệu, đích ghi log và các bản sao phục vụ phân tích. Mã hóa bằng các khóa KMS bắt buộc và hạn chế quyền giải mã, nhưng nhớ rằng mã hóa không chuyển dữ liệu trở lại khu vực tài phán được phê duyệt.

Artifact cung cấp báo cáo và thỏa thuận tuân thủ của AWS. Audit Manager có thể tổ chức bằng chứng tự động và thủ công theo một khuôn khổ đã chọn; công cụ này không chứng nhận workload hay quyết định một ngoại lệ có được chấp nhận về mặt pháp lý hay không. Chỉ định người chịu trách nhiệm cho các biện pháp kiểm soát và ghi lại việc phê duyệt, khắc phục, rà soát định kỳ.

Kiểm chứng và khi nào cần đổi phương án

• Thử triển khai bị cấm và thử dùng một đích sao lưu/xuất dữ liệu ngoài dự kiến.
• Truy vết một yêu cầu AI tới phạm vi định tuyến đã cấu hình và xác minh các đích bị từ chối.
• Tái dựng bằng chứng, người chịu trách nhiệm, ngày rà soát và lịch sử khắc phục của một biện pháp kiểm soát.

Nếu chính sách chỉ cho phép một Region, hãy thiết kế khôi phục trong ràng buộc đó và công khai rủi ro sự cố cấp Region còn lại. Đừng hứa khả năng chống chịu liên Region mà chính sách nơi lưu trú dữ liệu cấm.

Điểm cần nhớ và tài liệu AWS

• Chứng nhận của nhà cung cấp không chứng nhận cấu hình của khách hàng.
• Vị trí xử lý cũng quan trọng như vị trí lưu trữ.
• Hạn chế về Region và mục tiêu chống chịu sự cố có thể xung đột trực tiếp.

AWS: suy luận liên Region của Bedrock · AWS: Audit Manager · AWS: Artifact

Dịch vụ trong bài: Organizations · Control Tower · Artifact · Audit Manager · Bedrock · KMS

Kiểm soát trợ lý AI nội bộ mà không coi guardrail là cơ chế kiểm soát truy cập

Tình huống và yêu cầu

Bạn xây dựng một trợ lý cho nhân viên để trả lời câu hỏi từ các tài liệu nội bộ. Mỗi nhân viên có quyền truy cập tài liệu khác nhau, và một số hồ sơ chứa thông tin cá nhân. Trợ lý không được tiết lộ tài liệu hạn chế truy cập của nhóm khác hoặc trình bày lời tư vấn pháp lý do mô hình tạo ra như quan điểm đã được công ty phê duyệt.

Bộ phận bảo mật cũng cần các quyết định có thể kiểm toán mà không thu thập tràn lan các prompt nhạy cảm ở dạng thô. Bạn cần các biện pháp kiểm soát trước bước truy xuất và suy luận, cũng như kiểm tra đầu ra được tạo.

Đây là bài tập thiết kế AI giả định.

Các phương án và quyết định

Phân quyền truy xuất trước, sau đó áp dụng Bedrock Guardrails được hỗ trợ và kiểm tra ở tầng ứng dụng. Đừng gửi ngữ cảnh trái phép đến mô hình rồi hy vọng bộ lọc đầu ra sẽ che giấu nó.

Mô hình tư duy và luồng xử lý

Kiểm soát truy cập quyết định trợ lý được phép xem gì; guardrail đánh giá những gì trợ lý được hỏi và những gì nó trả về.

Danh tính người dùng → truy xuất được phân quyền → ngữ cảnh đã giảm thiểu → kiểm tra đầu vào đã cấu hình → mô hình → kiểm tra đầu ra → câu trả lời an toàn hoặc từ chối

Ứng dụng chịu trách nhiệm cho toàn bộ luồng thực thi kiểm soát.

Cơ chế cốt lõi

Lọc tài liệu bằng quyền của người dùng/tenant đã được xác minh trước khi xây dựng ngữ cảnh. Giảm thiểu dữ liệu cá nhân không cần thiết và loại trừ thông tin xác thực. Coi văn bản truy xuất được là nội dung có thể không đáng tin cậy, không phải chỉ dẫn có thể thay đổi việc phân quyền.

Cấu hình các chính sách nội dung, chủ đề và thông tin nhạy cảm được hỗ trợ cho mô hình, ngôn ngữ và trường hợp sử dụng. Nếu dùng riêng một API như ApplyGuardrail, hãy xử lý rõ ràng kết quả của nó tại các ranh giới đầu vào/đầu ra dự kiến. Không thử lại nội dung bị chặn bằng cách âm thầm gỡ bỏ các biện pháp kiểm soát.

Việc neo câu trả lời vào nguồn dữ liệu và trích dẫn có thể cải thiện khả năng truy vết nhưng không chứng minh tính đúng đắn. Xác định hành vi dự phòng an toàn, bao gồm chuyển các quyết định thuộc diện hạn chế cho người có chuyên môn phù hợp.

Ghi nhật ký mã định danh yêu cầu, phiên bản chính sách và kết quả, với quyền truy cập và thời gian lưu giữ được giới hạn. Mã hóa và xử lý dữ liệu tại khu vực được phê duyệt vẫn là các yêu cầu riêng ngoài việc lọc nội dung.

Kiểm chứng và khi nào cần đổi phương án

• Đánh giá các câu hỏi hợp lệ cùng với các trường hợp dữ liệu hạn chế truy cập, prompt injection và thông tin nhạy cảm.
• Kiểm thử trực tiếp việc truy xuất chéo vai trò, không chỉ kiểm tra xem mô hình có tình cờ từ chối hay không.
• Đo lường hành vi rò rỉ và dương tính giả sau các thay đổi về mô hình, chính sách hoặc truy xuất.

Nếu trợ lý không cần tài liệu nhạy cảm, loại trừ hoàn toàn chúng có thể an toàn hơn việc bổ sung bộ lọc. Các quyết định có hệ quả nghiêm trọng có thể cần con người phê duyệt bất kể độ tin cậy của mô hình.

Điểm cần nhớ và tài liệu AWS

• Prompt không phải chính sách phân quyền.
• Quyền truy xuất phải được thực thi trước khi ngữ cảnh đến mô hình.
• Kiểm tra đầu vào và đầu ra bảo vệ các giai đoạn khác nhau.
• Trích dẫn và guardrail không chứng nhận tính chính xác về sự thật hoặc pháp lý.
• Việc đánh giá phải bao quát cả câu trả lời không an toàn lẫn những lần từ chối không cần thiết.

AWS: Bedrock Guardrails

Dịch vụ trong bài: Bedrock Guardrails · Bedrock · KMS

Cho phép agent hành động thay người dùng mà không trao cho mọi người dùng các đặc quyền rộng nhất của agent

Tình huống và yêu cầu

Bạn xây dựng một trợ lý tìm kiếm trong CRM và tạo phiếu hỗ trợ cho nhân viên. Mỗi nhân viên chỉ được thao tác với các khách hàng được phân công. Các công cụ bao gồm AWS API và một SaaS API dùng OAuth.

Bản mẫu dùng một bộ thông tin xác thực quản trị viên, nên một nhân viên hợp lệ có thể yêu cầu agent truy cập khách hàng của nhóm khác. Bạn cần phân quyền theo phạm vi người dùng, các thao tác công cụ có thể kiểm toán và giữ thông tin xác thực ngoài ngữ cảnh của mô hình.

Đây là bài tập bảo mật agent giả định.

Các phương án và quyết định

Tách xác thực đầu vào khỏi phân quyền truy cập ra ngoài. Dùng các tích hợp AgentCore Identity, IAM và OAuth được hỗ trợ mà không giao quyết định về quyền truy cập nghiệp vụ cho văn bản của mô hình.

Mô hình tư duy và luồng xử lý

Danh tính của môi trường chạy, danh tính của nhân viên và thông tin xác thực SaaS là những thứ khác nhau.

Nhân viên đăng nhập → yêu cầu đến môi trường chạy đã được xác minh → phân quyền người dùng/tenant → thông tin xác thực công cụ có phạm vi giới hạn → thao tác CRM được phép → bản ghi kiểm toán

Token đầu vào không tự động cấp các quyền tương đương trong mọi hệ thống phía sau.

Cơ chế cốt lõi

Chọn AgentCore Harness được quản lý cho một vòng lặp agent có thể cấu hình và được hỗ trợ; dùng môi trường chạy tùy chỉnh khi ứng dụng thực sự cần hành vi vòng lặp/framework tùy chỉnh. Duy trì một quy trình xác định cho các quy tắc phê duyệt/thực thi cố định thay vì yêu cầu mô hình tự ứng biến. Đặt giới hạn số vòng lặp, token, thời gian và số lần gọi công cụ, đồng thời giới hạn bộ nhớ phiên theo người dùng và tenant đã xác minh. Việc chọn môi trường chạy không loại bỏ công việc phân quyền.

Xác minh bên phát hành, đối tượng nhận, thời hạn và cơ chế xác thực đã cấu hình. Suy ra ngữ cảnh người dùng và tenant từ dữ liệu danh tính đáng tin cậy, không phải từ một prompt tự nhận “Tôi là quản trị viên.”

Kiểm tra các đối số công cụ theo quyền sở hữu tài nguyên và các thao tác được phép trước khi thực thi. Công cụ AWS dùng các role có phạm vi phù hợp và yêu cầu đã ký. Truy cập SaaS dùng nhà cung cấp/luồng được hỗ trợ, bao gồm sự đồng ý ủy quyền của người dùng khi áp dụng; một tích hợp lưu thông tin xác thực không tự động hiểu các quy tắc phân công khách hàng trong CRM.

Giữ token ngoài prompt, phản hồi được tạo và nhật ký thông thường. Áp dụng chính sách làm mới, thu hồi và truy cập thông tin xác thực tại tầng thông tin xác thực. Mô hình nên nhận kết quả công cụ phù hợp với bên gọi, không phải dữ liệu cấp quyền truy cập không hạn chế.

Coi nội dung truy xuất được và đầu ra công cụ là đầu vào không đáng tin cậy, không được phép mở rộng đặc quyền. Backend của công cụ phải thực thi ranh giới riêng ngay cả khi agent bị thao túng để yêu cầu một thao tác trái phép.

Kiểm chứng và khi nào cần đổi phương án

• Dùng danh tính tenant-A để yêu cầu bản ghi của tenant-B và xác minh backend từ chối.
• Kiểm thử thông tin xác thực hết hạn, sự đồng ý đã thu hồi, đối số công cụ bị sửa và phạm vi quyền không đủ.
• Truy vết từng thao tác công cụ về người dùng khởi tạo và lần thực thi agent mà không làm lộ token.

Một tác vụ bảo trì do hệ thống sở hữu có thể dùng danh tính dịch vụ thay vì ủy quyền người dùng, nhưng phạm vi được phép và mô hình phê duyệt của nó phải rõ ràng. Không âm thầm dùng nó thay cho quyền của người dùng.

Điểm cần nhớ và tài liệu AWS

• Xác thực tại điểm vào không cấp quyền cho mọi thao tác phía sau.
• Không được đánh đồng danh tính môi trường chạy và danh tính người dùng.
• Phân quyền công cụ phải nằm ngoài các chỉ dẫn dành cho mô hình.
• Xử lý thông tin xác thực tách biệt với quyền sở hữu tài nguyên nghiệp vụ.
• Kiểm toán phải kết nối ý định của người dùng với tác động thực tế của công cụ.

AWS: xác thực AgentCore · AWS: AgentCore Harness

Dịch vụ trong bài: Bedrock AgentCore · Bedrock AgentCore Identity · IAM · Cognito

Yêu cầu phê duyệt chính xác khoản hoàn tiền mà agent đề xuất

Tình huống và yêu cầu

Bạn bổ sung chức năng hỗ trợ hoàn tiền cho một nền tảng hỗ trợ khách hàng. Agent có thể chuẩn bị một khoản hoàn tiền lớn, nhưng nhân viên có thẩm quyền phải phê duyệt chính xác giao dịch, người nhận, loại tiền và số tiền trước khi bất kỳ thao tác thanh toán nào diễn ra.

Agent không được thay đổi payload sau khi phê duyệt hoặc gọi API hoàn tiền qua một đường khác. Việc thử lại quy trình không được chuyển tiền hai lần, và các đề xuất hết hạn hoặc bị từ chối phải luôn ở trạng thái chưa thực thi.

Đây là bài tập quy trình phê duyệt giả định.

Các phương án và quyết định

Dùng quy trình Standard chờ phê duyệt có xác thực cho một đề xuất cố định. Giữ quyền hoàn tiền trong một role thực thi riêng mà agent đề xuất không thể sử dụng.

Mô hình tư duy và luồng xử lý

Phê duyệt cho phép một thao tác cụ thể, không phải bất kỳ thao tác nào sau đó có mô tả tương tự.

Đề xuất của agent → bản ghi bất biến/có phiên bản → người xét duyệt đã xác thực → phê duyệt đã ghi nhận → kiểm tra lại payload → hoàn tiền có tính idempotent → kết quả đã đối soát

Thay đổi số tiền hoặc người nhận tạo ra một đề xuất mới cần được phê duyệt lại.

Cơ chế cốt lõi

Lưu giao dịch đích, người nhận, số tiền, loại tiền, lý do và phiên bản/giá trị băm chuẩn hóa. Hiển thị chính xác nội dung đó trong giao diện phê duyệt. Giá trị băm giúp nhận diện nội dung; bản thân nó không chứng minh người phê duyệt có thẩm quyền.

Endpoint phê duyệt xác minh danh tính, tenant, vai trò, trạng thái, thời hạn và mọi quy tắc phân tách nhiệm vụ. Dùng chuyển trạng thái có điều kiện để các yêu cầu phê duyệt/từ chối cạnh tranh không thể cùng thành công.

Callback token của Step Functions hỗ trợ việc chờ, nhưng hãy giữ nó phía sau backend có xác thực thay vì để lộ trong liên kết email hoặc nhật ký. Lưu bền vững quyết định và bằng chứng kiểm toán, kèm một cách có thể khôi phục để báo cho quy trình nếu việc gửi callback thất bại.

Bộ thực thi đọc lại phiên bản đã phê duyệt, kiểm tra điều kiện nghiệp vụ hiện tại và dùng một khóa idempotency ổn định của nhà cung cấp. Nếu nhà cung cấp hết thời gian chờ sau khi chấp nhận khoản hoàn tiền, hãy đối soát trước khi thử thanh toán lần nữa. Việc bị từ chối, hết hạn hoặc payload không khớp không được dẫn đến phương án dự phòng cho agent thực thi trực tiếp.

Kiểm chứng và khi nào cần đổi phương án

• Thử phê duyệt trùng lặp, phê duyệt trái phép, đề xuất hết hạn và thay đổi payload.
• Làm bộ thực thi dừng đột ngột sau khi nhà cung cấp chấp nhận khoản hoàn tiền nhưng trước khi trạng thái hoàn tất được ghi nhận cục bộ.
• Rà soát thiết kế quyền để tìm mọi đường truy cập trực tiếp có thể bỏ qua phê duyệt.

Các thao tác rủi ro thấp và có thể đảo ngược có thể dùng một chính sách tự động hóa được phê duyệt riêng. Điều đó không biện minh cho việc bỏ qua bước kiểm soát rõ ràng của con người trong quy trình hoàn tiền có tác động lớn này.

Điểm cần nhớ và tài liệu AWS

• Phê duyệt của con người cần một ranh giới thực thi về mặt kỹ thuật.
• Gắn việc cấp quyền với nội dung và phiên bản chính xác của thao tác.
• Sở hữu callback token không đồng nghĩa với có quyền nghiệp vụ.
• Tách đặc quyền đề xuất khỏi đặc quyền thực thi.
• Tính idempotent và đối soát xử lý các trường hợp khác nhau khi kết quả chưa chắc chắn.

AWS: tác vụ callback của Step Functions

Dịch vụ trong bài: Step Functions · API Gateway · Lambda · DynamoDB

Mua ưu đãi giá cho tải ổn định, không phải đỉnh tải cuối tuần

Tình huống và yêu cầu

Bạn rà soát chi phí điện toán cho một nhà bán lẻ. Tải nền EC2 chạy liên tục, lưu lượng cuối tuần khiến nhu cầu tăng gấp ba trong thời gian ngắn, còn các tác vụ batch có thể lưu checkpoint và chịu được gián đoạn. Nhóm có thể đổi họ instance trong năm tới.

Bộ phận tài chính muốn tiết kiệm mà không phải trả tiền cho công suất đỉnh suốt cả tuần hay cản trở những thay đổi kiến trúc sau này. Bạn cần tách mức sử dụng chắc chắn khỏi các đợt tăng tải khó đoán và công việc có thể chịu gián đoạn.

Đây là bài tập mua dịch vụ giả định.

Các phương án và quyết định

Điều chỉnh quy mô cho phù hợp trước, rồi cam kết thận trọng cho tải nền chắc chắn. Dùng On-Demand cho các đợt tăng tải khó đoán và Spot cho các tác vụ batch có cơ chế phục hồi phù hợp.

Mô hình tư duy và luồng xử lý

Cam kết để được giảm giá là nghĩa vụ tài chính, không phải dự đoán rằng nhu cầu sẽ luôn cao.

Lịch sử sử dụng → loại bỏ lãng phí → xác định tải nền ổn định → chọn phạm vi cam kết → theo dõi mức tiêu thụ

Hãy tính công việc phục hồi batch sau gián đoạn vào chi phí, thay vì coi đó là công sức vận hành miễn phí.

Cơ chế cốt lõi

So sánh các kỳ tính phí có tính đại diện, tính mùa vụ và thiết lập chia sẻ ưu đãi giá. Compute Savings Plans linh hoạt hơn về điện toán so với EC2 Instance Savings Plans; Reserved Instances có các quy tắc riêng theo dịch vụ và phạm vi. Đánh giá lựa chọn thời hạn và thanh toán theo những thay đổi dự kiến, không chỉ theo phần trăm giảm giá quảng cáo lớn nhất.

Trước khi mua cam kết, benchmark các bản dựng tương thích Graviton với môi trường chạy hiện tại bằng chi phí cho mỗi giao dịch hoàn tất, tính cả công việc di chuyển và đảm bảo tương thích. Với tải container tăng đột biến, Fargate Spot chỉ hữu ích khi có thể chấp nhận gián đoạn và thay thế. Đơn giá thấp hơn không phải là tiết kiệm nếu xử lý chậm hơn hoặc retry làm tiêu thụ nhiều đơn vị hơn.

Coverage đo tỷ lệ sử dụng đủ điều kiện được hưởng giảm giá. Utilization đo mức tiêu thụ phần cam kết đã mua. Coverage cao nhưng utilization thấp vẫn có thể là lãng phí.

Tải chạy Spot cần checkpoint, retry, khả năng linh hoạt về công suất và thời hạn thực tế. Thông báo gián đoạn không đảm bảo phần công việc còn lại có thể hoàn tất.

Savings Plans không đặt trước công suất EC2. EC2 Reserved Instances phạm vi Regional và Zonal cũng khác nhau về cơ chế đặt trước công suất. Nếu ứng dụng yêu cầu đảm bảo công suất khi khởi chạy, hãy xử lý việc đó tách biệt với giá.

Kiểm chứng và khi nào cần đổi phương án

• Mô hình hóa nhu cầu thấp hơn và kế hoạch đổi họ instance trước khi mua.
• Kiểm tra xem cam kết mới có chồng lặp với phần sử dụng đã được ưu đãi hoặc các thỏa thuận chia sẻ hiện có không.
• Diễn tập gián đoạn Spot và tính công việc phải làm lại vào chi phí cho mỗi batch hoàn tất.

Nếu ứng dụng có khả năng ngừng tồn tại hoặc thay đổi căn bản, sự linh hoạt của On-Demand có thể đáng giá hơn khoản tiết kiệm từ cam kết. Một quy mô tài nguyên ổn định, được hiểu rõ có thể phù hợp với cam kết hẹp hơn hoặc dài hơn sau khi rà soát.

Điểm cần nhớ và tài liệu AWS

• Điều chỉnh quy mô phù hợp trước khi cam kết chi tiêu định kỳ.
• Tải nền, tải tăng đột biến và công việc chịu được gián đoạn cần các mô hình mua khác nhau.
• Coverage và utilization đo những điều khác nhau.
• Ưu đãi giá không tự động đặt trước công suất.
• Tính công việc làm lại do gián đoạn khi đánh giá mức tiết kiệm từ Spot.

AWS: Savings Plans

Dịch vụ trong bài: Savings Plans · Reserved Instances · EC2 Spot · Cost Explorer

Giảm chi phí AI mà không đánh đổi chất lượng câu trả lời

Tình huống và yêu cầu

Một trợ lý hỗ trợ xử lý 100,000 yêu cầu mỗi ngày. Phần lớn là tra cứu chính sách ngắn, nhưng một số cần suy luận phức tạp. Hiện mọi yêu cầu đều gửi một tiền tố chỉ dẫn dài lặp đi lặp lại đến mô hình đắt nhất trong số các mô hình đã chọn. Tác vụ tóm tắt hằng đêm có thời hạn tám giờ. Bộ phận tài chính muốn giảm chi phí cho mỗi yêu cầu được giải quyết thành công, không chỉ giảm hóa đơn nhờ từ chối nhiều hơn.

Các phương án và quyết định

Đo chi phí đơn vị có xét đến chất lượng, rồi điều chỉnh ngữ cảnh vừa đủ và định tuyến công việc đủ điều kiện đến mô hình rẻ hơn. Dùng prompt caching được hỗ trợ cho ngữ cảnh lặp lại và batch inference cho công việc ngoại tuyến đủ điều kiện. Chỉ đánh giá công suất provisioned dựa trên mức tải nền ổn định đã đo được.

Mô hình tư duy và luồng xử lý

Tổng chi phí yêu cầu không chỉ gồm phản hồi cuối cùng của mô hình.

Truy xuất + embeddings + đầu vào/đầu ra mô hình + thao tác cache + xếp hạng lại + công cụ/retry + hạ tầng → chi phí cho mỗi kết quả thành công

Ví dụ, giảm đầu vào từ 8,000 xuống 2,000 token trên 100,000 yêu cầu hằng ngày loại bỏ 600 triệu token đầu vào mỗi ngày trước khi xét tác động của cache. Điều đó chưa chứng minh được mức tiết kiệm bằng tiền cho đến khi tính cả giá hiện tại của mô hình và thay đổi về đầu ra/retry.

Cơ chế cốt lõi

Đặt chỉ dẫn ổn định trước ngữ cảnh biến đổi khi cơ chế caching được hỗ trợ yêu cầu tái sử dụng tiền tố. Kiểm tra mức tối thiểu của cache, TTL, đơn giá ghi/đọc và bộ đếm sử dụng của mô hình đã chọn. Prompt caching tái sử dụng tính toán của mô hình cho đầu vào đủ điều kiện; nó không phải cache câu trả lời của ứng dụng và không cho phép chia sẻ câu trả lời giữa các tenant.

Đánh giá định tuyến trên các câu hỏi dễ và khó có tính đại diện. Định tuyến thông minh tích hợp sẵn có giới hạn về họ mô hình/cấu hình được hỗ trợ; bộ định tuyến tùy chỉnh cần cơ chế kiểm soát chất lượng, fallback và khả năng quan sát riêng. Giới hạn độ dài đầu ra và số lần retry thay vì để các công cụ lặp vô hạn xóa sạch khoản tiết kiệm từ giá mô hình.

Giữ dữ liệu huấn luyện, kho truy xuất và máy khách suy luận gần vị trí điện toán được phép của chúng khi khả thi. Tính phí truyền dữ liệu thực tế theo từng dịch vụ và phí suy luận liên Region vào mô hình chi phí, thay vì cho rằng đích mô hình rẻ hơn khiến toàn bộ đường xử lý rẻ hơn. Profile liên Region phải đáp ứng các hạn chế về lưu trú dữ liệu và SCP; không định tuyến ra ngoài khu vực địa lý được phê duyệt để có công suất.

Tách tác vụ ngoại tuyến khỏi lưu lượng tương tác. Chỉ so sánh giá on-demand, batch và provisioned hiện tại cho các tổ hợp mô hình/Region được hỗ trợ. Với SageMaker, tính cả thời gian endpoint nhàn rỗi, mức tận dụng bộ tăng tốc, thời gian khởi động và chi phí vận hành. Không có quy tắc chung nào cho thấy tự vận hành mô hình luôn rẻ hơn.

Phân bổ mức sử dụng thông qua application inference profile/tag được hỗ trợ và đo đếm yêu cầu ứng dụng khi cần. Theo dõi token đầu vào/đầu ra/cache, mô hình/profile, tenant/nhóm, độ trễ và kết quả mà không ghi log nội dung prompt chỉ để tính phí. Budgets và cảnh báo bất thường thông báo cho chủ sở hữu; chúng không phải trần chi tiêu đồng bộ trên từng yêu cầu.

Kiểm chứng và khi nào cần đổi phương án

• So sánh chi phí cho mỗi trường hợp được giải quyết cùng với độ chính xác, tỷ lệ từ chối, độ trễ và số lần chuyển cấp.
• Xác nhận các lượt đọc cache thực tế và quyết định định tuyến mô hình trong dữ liệu đo lường sử dụng.
• Kiểm thử throttling, fallback có giới hạn và hành vi quota/ngân sách cuối tháng.

Tải công việc ổn định với khối lượng lớn có thể phù hợp với công suất cam kết sau khi đo lường. Một tác vụ có hệ quả nghiêm trọng có thể cần mô hình mạnh hơn hoặc con người rà soát dù chi phí mỗi yêu cầu cao hơn.

Điểm cần nhớ và tài liệu AWS

• Tối ưu kết quả thành công, không tối ưu riêng token.
• Khả năng hỗ trợ cache và giá phụ thuộc từng mô hình.
• Thời hạn batch và độ trễ tương tác cần các luồng riêng.

AWS: prompt caching của Bedrock · AWS: giá Bedrock · AWS: inference profile

Dịch vụ trong bài: Bedrock · SageMaker AI · Cost Explorer · Budgets · CloudWatch

Sửa tìm kiếm đơn hàng chậm trước khi mua máy chủ lớn hơn

Tình huống và yêu cầu

Bạn điều tra độ trễ tìm kiếm đơn hàng tại một nhà bán lẻ đang tăng trưởng. Trong sự cố giả định này, p99 đã tăng từ 300 ms lên ba giây khi tập dữ liệu lớn dần. CPU web thấp trong khi I/O cơ sở dữ liệu tăng.

Đội ngũ cần bằng chứng cho một thay đổi có mục tiêu và phép so sánh trước/sau công bằng. Ngân sách không cho phép tăng kích thước mọi instance vô thời hạn, nhưng mở rộng vẫn là một lựa chọn nếu số đo xác định được giới hạn năng lực thực sự.

Các phương án và quyết định

Đo luồng truy vấn trước khi thay đổi năng lực. Trong bài tập này, việc kiểm tra kế hoạch thực thi sau đó cho thấy tìm kiếm theo khách hàng và ngày phải quét lượng dữ liệu lớn, do không có chỉ mục phù hợp.

Mô hình tư duy và luồng xử lý

CPU web thấp có thể có nghĩa máy chủ web đang chờ, chứ không phải yêu cầu được xử lý nhanh.

Yêu cầu tìm kiếm → trace ứng dụng → span truy vấn cơ sở dữ liệu → kế hoạch truy vấn và thời gian chờ → thay đổi có mục tiêu → đo hiệu năng trong điều kiện tương đương

Trace định vị độ trễ; bằng chứng từ cơ sở dữ liệu giải thích nguyên nhân.

Cơ chế cốt lõi

Kiểm tra số hàng được xem xét, đường truy cập dữ liệu, thời gian chờ khóa, độ trễ lưu trữ và thời gian chờ pool kết nối. Đừng suy ra rằng cần “thêm chỉ mục” chỉ từ I/O; chính bằng chứng kế hoạch truy vấn được cung cấp mới là cơ sở cho lựa chọn đó ở đây.

Thiết kế chỉ mục cho các điều kiện lọc và thứ tự sắp xếp thực tế, rồi đánh giá trên dữ liệu đại diện. Chỉ mục tiêu thụ dung lượng lưu trữ và tăng công việc ghi, còn việc xây dựng chỉ mục có thể ảnh hưởng đến khóa hoặc tài nguyên. Tránh thêm chỉ mục tùy tiện.

Giảm các hàng và cột không cần thiết trong truy vấn. Triển khai với kế hoạch khôi phục phù hợp với engine và các truy vấn khác sử dụng những cấu trúc bị ảnh hưởng.

Nếu workload đã tối ưu vẫn bị giới hạn năng lực, hãy đo hiệu năng các lựa chọn instance hoặc lưu trữ phù hợp. Compute Optimizer có thể đề xuất thay đổi tài nguyên, nhưng không thể xác định mục tiêu độ trễ nghiệp vụ đã được đáp ứng hay chưa.

Kiểm chứng và khi nào cần đổi phương án

• So sánh với cùng quy mô dữ liệu, cơ cấu yêu cầu, mức độ đồng thời và điều kiện làm nóng.
• Đo p50/p95/p99, thông lượng, lỗi, tác động lên ghi và chi phí mỗi yêu cầu.
• Kiểm tra các truy vấn khác trước khi xóa hoặc thay đổi chỉ mục dùng chung trong quá trình rollback.

Nếu trace cho thấy thời gian chờ mạng thanh toán, thêm chỉ mục cơ sở dữ liệu sẽ không liên quan. Nếu chứng minh được khả năng tái sử dụng rộng rãi các lượt đọc, cache có thể bổ trợ việc sửa truy vấn. Hãy để bằng chứng thay đổi khuyến nghị.

Điểm cần nhớ và tài liệu AWS

• Xác định chỗ chờ trước khi chọn tài nguyên để mở rộng.
• Kế hoạch truy vấn giải thích lượng công việc mà chỉ số CPU tổng hợp không thể hiện được.
• Chỉ mục đánh đổi chi phí ghi và lưu trữ để lấy hiệu quả đọc.
• Giá trị trung bình có thể che khuất độ trễ đuôi không chấp nhận được.
• Các tuyên bố về hiệu năng cần điều kiện workload có thể so sánh.

AWS: trụ cột Hiệu quả hiệu năng

Dịch vụ trong bài: CloudWatch · X-Ray · RDS · Compute Optimizer

Loại bỏ xử lý NAT không cần thiết mà không đánh đổi tính sẵn sàng đa AZ

Tình huống và yêu cầu

Bạn điều tra hóa đơn mạng ngày càng tăng của một dịch vụ tài liệu. Các EC2 worker riêng tư trong ba AZ gửi lượng dữ liệu đáng kể đến S3 qua một NAT gateway ở AZ A. Hóa đơn ghi nhận phí xử lý NAT và truyền dữ liệu liên AZ dù lưu lượng khách hàng vẫn ổn định.

Bộ phận tài chính muốn giảm chi phí cho mỗi tài liệu được xử lý. Các yêu cầu bảo mật và độ tin cậy không thay đổi: không đưa worker ra công khai, không mở rộng quyền dữ liệu và không gom vào một AZ chỉ để loại bỏ phí truyền dữ liệu.

Đây là cuộc điều tra chi phí giả định.

Các phương án và quyết định

Định tuyến truy cập S3 trong cùng Region qua gateway endpoint. Đánh giá riêng lưu lượng đi ra còn lại thay vì áp dụng một quy tắc chi phí mạng cho mọi đích đến.

Mô hình tư duy và luồng xử lý

Hóa đơn mạng phản ánh đường đi của dữ liệu, không chỉ số byte ứng dụng tạo ra.

Trước: worker AZ B → NAT AZ A → S3
Sau: worker AZ B → S3 gateway endpoint → S3

Tải công việc vẫn gửi dữ liệu; thành phần trung gian không cần thiết được loại bỏ.

Cơ chế cốt lõi

Dùng CUR hoặc bản xuất dữ liệu thanh toán chi tiết để xác định loại sử dụng và khoảng thời gian. Flow Logs có thể giúp xác định nguồn và đích lưu lượng nhưng không phải hóa đơn đầy đủ. Lập sơ đồ từng chặng tính phí và dùng bảng giá của Region liên quan, tránh tính trùng cùng một đường truyền.

Liên kết gateway endpoint với mọi bảng định tuyến liên quan của worker. Giữ nguyên các giới hạn ở endpoint, IAM và bucket; chi phí thấp hơn không phải lý do để mở rộng quyền truy cập.

Với các phụ thuộc thực sự cần internet, hãy giữ thiết kế tính sẵn sàng NAT/firewall cần thiết. Interface endpoint có phí theo giờ và phí dữ liệu, vì vậy hãy so sánh tổng chi phí và lợi ích bảo mật thay vì cho rằng endpoint nào cũng tiết kiệm tiền.

Tính cả phí attachment/xử lý dữ liệu của Transit Gateway và phí giờ endpoint/dữ liệu của PrivateLink khi so sánh đường truyền dùng chung với đường truyền phân tán. Chỉ sao chép những tập dữ liệu và đến những Region mà chính sách phục hồi/lưu trú dữ liệu yêu cầu, đồng thời tính lưu lượng sao chép, các bản sao lưu giữ và lượt đọc liên Region vào mô hình. Giảm số bản sao là không chấp nhận được nếu vi phạm RPO hoặc nghĩa vụ pháp lý.

CloudFront có thể giảm truyền dữ liệu từ origin cho nội dung công khai có thể cache. Origin Shield bổ sung một lớp cache trung gian có thể giảm các lần lấy dữ liệu trùng lặp từ origin, nhưng cần so sánh phí yêu cầu và vị trí được chọn với mức tiết kiệm tại origin đo được. Nó không loại bỏ lưu lượng xử lý riêng tư hay biện minh cho việc bỏ sao chép cơ sở dữ liệu liên AZ cần thiết cho tính sẵn sàng.

Kiểm chứng và khi nào cần đổi phương án

• Xác nhận đường định tuyến S3 thực tế và việc cho phép/từ chối truy cập không thay đổi.
• So sánh chi phí mạng trên mỗi GB hoặc mỗi tài liệu ở các mức lưu lượng tương tự.
• Diễn tập failover cho lưu lượng đi ra còn lại và xác minh không có phụ thuộc ẩn vào đường NAT đã loại bỏ.

Với máy khách tại chỗ hoặc dịch vụ khác, loại endpoint và mô hình chi phí sẽ khác. Phân tích riêng các luồng đó thay vì áp dụng khuyến nghị S3 gateway này cho mọi trường hợp.

Điểm cần nhớ và tài liệu AWS

• Các chặng mạng tính phí quan trọng không kém dung lượng dữ liệu.
• Flow Logs hỗ trợ điều tra nhưng không thay thế dữ liệu thanh toán.
• S3 gateway endpoint có thể loại bỏ xử lý NAT không cần thiết.
• Lựa chọn endpoint có tác động riêng đến chi phí và quyền truy cập.
• Tối ưu chi phí phải giữ được mức cô lập sự cố cần thiết.

AWS: hướng dẫn về chi phí truyền dữ liệu

Dịch vụ trong bài: CUR · VPC Flow Logs · NAT Gateway · VPC Endpoints · CloudFront

Điều tra hóa đơn tăng trước khi xóa tài nguyên có vẻ nhàn rỗi

Tình huống và yêu cầu

Bạn rà soát hóa đơn nền tảng đã tăng 35% trong khi số lượng đơn hàng không đổi. Bộ phận tài chính yêu cầu cắt giảm, nhưng môi trường production có các tác vụ batch hằng tháng và một môi trường khôi phục thảm họa ít được sử dụng.

Bạn cần xác định những yếu tố thực sự gây ra chi phí và giữ nguyên các mục tiêu dịch vụ. CPU trung bình thấp không đồng nghĩa với việc được phép xóa tài nguyên, và việc mua ưu đãi giá không nên khiến bạn bị ràng buộc với phần lãng phí có thể tránh được.

Đây là bài tập rà soát chi phí giả định.

Các phương án và quyết định

Giải thích nguyên nhân tăng trước, rồi điều chỉnh quy mô hoặc loại bỏ tài nguyên khi được chủ sở hữu phê duyệt. Mua cam kết sau khi đã hiểu rõ mức tải nền hiệu quả.

Mô hình tư duy và luồng xử lý

Mức sử dụng thấp đặt ra câu hỏi về mục đích, không phải bằng chứng lãng phí.

Hóa đơn tăng → phân tích theo dịch vụ/tài khoản/loại sử dụng → chủ sở hữu tài nguyên và chu kỳ tải → thay đổi được phê duyệt → rà soát SLO và mức tiết kiệm

Một máy chủ phục hồi và một máy chủ phát triển bị bỏ quên có thể có biểu đồ CPU tương tự nhưng giá trị rất khác nhau.

Cơ chế cốt lõi

Dùng Cost Explorer để xem xu hướng và CUR hoặc bản xuất chi tiết để tìm yếu tố sử dụng gây chi phí như số byte NAT, dung lượng volume, thời gian lưu giữ log và số giờ điện toán. Tách tăng trưởng sử dụng khỏi thay đổi về giá, khoản tín dụng hoặc ưu đãi giá. Theo dõi chi phí trên mỗi đơn hàng cùng với tổng chi phí.

Xem khuyến nghị của Compute Optimizer và Trusted Advisor là bằng chứng để điều tra. Bổ sung chỉ số bộ nhớ và chỉ số riêng của tải công việc khi cần, đồng thời xem xét toàn bộ chu kỳ kinh doanh thay vì một khoảng ngắn ít tải.

Trước khi loại bỏ, xác nhận các phụ thuộc, chủ sở hữu, yêu cầu lưu giữ và mục đích phục hồi. EC2 instance đã dừng vẫn có thể phát sinh phí lưu trữ và phí khác; một volume đã tháo rời vẫn có thể chứa dữ liệu cần thiết.

Triển khai điều chỉnh quy mô trên một nhóm nhỏ có tính đại diện. Chỉ lên lịch tắt môi trường phi production sau khi tính đến múi giờ, các phụ thuộc khi khởi động và mức sẵn sàng mong đợi. Đánh giá công suất dự phòng DR theo mục tiêu phục hồi, không theo mức sử dụng ngày thường.

Kiểm chứng và khi nào cần đổi phương án

• So sánh độ trễ, lỗi và việc hoàn tất batch trước và sau mỗi thay đổi.
• Đo mức tiết kiệm thực tế qua một chu kỳ có tính đại diện bằng cơ sở chi phí nhất quán.
• Xác nhận khả năng phục hồi vẫn được giữ nguyên cùng các phương án rollback.

Nếu mức tăng đến từ yêu cầu truyền dữ liệu hoặc lưu giữ mới hợp lý, giảm cấu hình điện toán sẽ không giải quyết được. Kết quả đúng có thể là một ngân sách cao hơn có căn cứ thay vì cắt giảm thiếu an toàn.

Điểm cần nhớ và tài liệu AWS

• Xác định nguồn thay đổi chi phí trước khi đề xuất cách tiết kiệm.
• Khuyến nghị không phải là sự cho phép thực thi.
• Đỉnh tải và vai trò phục hồi có thể là lý do chính đáng cho mức sử dụng trung bình thấp.
• Dừng điện toán không chấm dứt mọi khoản phí liên quan.
• Tiết kiệm chỉ hữu ích nếu dịch vụ cần thiết vẫn hoạt động.

AWS: Compute Optimizer

Dịch vụ trong bài: Cost Explorer · CUR · Compute Optimizer · Trusted Advisor · CloudWatch

Kiểm soát chi tiêu sandbox mà không để cảnh báo thanh toán tắt production

Tình huống và yêu cầu

Bạn quản lý các rào chắn kiểm soát đám mây cho một công ty có tài khoản thử nghiệm và dịch vụ tạo doanh thu. Chủ sở hữu sandbox có ngân sách hằng tháng, trong khi production không được dừng chỉ vì chi tiêu tăng trong một đợt nhu cầu tăng đột biến hợp lý.

Bộ phận tài chính cần cảnh báo sớm, chủ sở hữu rõ ràng và cơ chế kiểm soát việc cấp phát mới. Bạn phải thừa nhận rằng dữ liệu thanh toán đến có độ trễ, nên cảnh báo không thể đảm bảo trần chi tiêu chính xác theo thời gian thực.

Đây là bài tập quản trị giả định.

Các phương án và quyết định

Tách kiểm soát sandbox khỏi cách ứng phó cho production. Kết hợp cảnh báo ngân sách theo kế hoạch với phát hiện bất thường và các hạn chế cấp phát được hỗ trợ.

Mô hình tư duy và luồng xử lý

Ngân sách là tín hiệu tài chính có độ trễ; chính sách cấp phát là ranh giới truy cập mang tính phòng ngừa.

Sử dụng → dữ liệu thanh toán → cảnh báo ngân sách thực tế/dự báo → chủ sở hữu → hành động sandbox được phê duyệt hoặc chuyển cấp xử lý production

Yêu cầu cấp phát → ràng buộc IAM/SCP/danh mục → tài nguyên được phép

Các luồng này bổ sung cho nhau chứ không tạo thành một trần cứng tức thời.

Cơ chế cốt lõi

Xác định phạm vi ngân sách theo tài khoản hoặc các chiều thanh toán phù hợp, với ngưỡng thực tế và dự báo. Cost Anomaly Detection tìm các kiểu chi tiêu bất thường; ngân sách cố định và bất thường trả lời những câu hỏi khác nhau.

Đặt sandbox trong các tài khoản/OU riêng. Giới hạn Region được hỗ trợ, lựa chọn tài nguyên hoặc hành động tạo bằng điều kiện IAM/SCP phù hợp và sản phẩm được phê duyệt. Kiểm tra khả năng hỗ trợ điều kiện riêng của từng dịch vụ thay vì cho rằng mọi API chấp nhận mọi hạn chế.

Budgets Actions có thể thực hiện các hành động chính sách hoặc tài nguyên được hỗ trợ với quyền và cơ chế phê duyệt đã cấu hình. Từ chối cấp phát mới không ngăn tài nguyên hiện có tiếp tục phát sinh phí. Lập kế hoạch riêng cho dọn dẹp và hết hạn.

Với production, cảnh báo chủ sở hữu chịu trách nhiệm và bộ phận tài chính. Bất kỳ việc giảm công suất nào cũng phải giữ được nhu cầu về tính sẵn sàng, lưu giữ và phục hồi; tổng hóa đơn không thể tự đưa ra quyết định kiến trúc đó.

Kiểm chứng và khi nào cần đổi phương án

• Xác minh thông báo được gửi đến nơi, chủ sở hữu và phạm vi của vai trò thực thi.
• Kiểm thử một hành động sandbox và việc hoàn tác mà không đụng đến production.
• Mô hình hóa chi tiêu tiếp tục phát sinh trong thời gian dữ liệu thanh toán bị trễ và sau khi cấp phát đã bị chặn.

Một môi trường đào tạo được kiểm soát chặt có thể phù hợp với dọn dẹp tự động quyết liệt hơn. Tải công việc trọng yếu cho doanh nghiệp cần một luồng chuyển cấp và rà soát thay vì sao chép cùng một chính sách khắp nơi.

Điểm cần nhớ và tài liệu AWS

• Budgets không phải trần chi tiêu chính xác theo thời gian thực.
• Dự báo, bất thường và ngưỡng cố định cung cấp các tín hiệu khác nhau.
• Ngăn tạo mới không chấm dứt chi tiêu hiện có.
• Giới hạn tự động hóa trong đúng môi trường nghiệp vụ dự kiến.
• Quota giới hạn số lượng tài nguyên, không giới hạn tổng hóa đơn.

AWS: Budgets Actions

Dịch vụ trong bài: Budgets · Cost Anomaly Detection · Organizations · IAM

Giải thích chi phí AWS dùng chung mà không che giấu khoản chi chưa phân bổ

Tình huống và yêu cầu

Bạn là kỹ sư nền tảng hỗ trợ đợt rà soát chi phí hằng tháng của bộ phận tài chính. Một số sản phẩm sở hữu tài khoản AWS; số khác dùng chung tài khoản và dịch vụ mạng. Bộ phận tài chính nhìn thấy tổng hóa đơn nhưng không thể tách chi phí production, phát triển và hạ tầng dùng chung một cách đáng tin cậy.

Bạn cần báo cáo showback theo sản phẩm và môi trường với cách phân bổ có cơ sở giải trình. Các trường hợp thiếu tag phải vẫn hiển thị và có người chịu trách nhiệm khắc phục, không biến mất khỏi tổng chi phí hoặc bị âm thầm tính cho đội khác.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Ưu tiên quyền sở hữu tài khoản, dùng tag phân bổ chi phí đã kích hoạt trong các tài khoản dùng chung và ghi lại các quy tắc chi phí dùng chung. Cost Categories cung cấp cách nhóm nhất quán theo nghiệp vụ.

Mô hình tư duy và luồng xử lý

Báo cáo chi phí là một mô hình phân bổ trên các bản ghi tính phí, không chỉ là truy vấn tag tài nguyên.

Mức sử dụng AWS → bản xuất dữ liệu tính phí trong S3 → quy tắc tài khoản/tag/danh mục → chi phí đã phân bổ và chưa phân bổ → đối soát với bộ phận tài chính

Cost Explorer hỗ trợ tìm hiểu tương tác; dữ liệu CUR hoặc Data Exports chi tiết hỗ trợ lập báo cáo có thể tái lập bằng Athena.

Cơ chế cốt lõi

Chuẩn hóa các tag như Product, Environment và Owner, sau đó kích hoạt các tag phân bổ chi phí do người dùng xác định có liên quan trong hệ thống tính phí. Thêm tag vào tài nguyên và bật tag đó để tính phí là hai hành động riêng biệt. Đừng cho rằng tất cả bản ghi lịch sử đều sẽ được điều chỉnh hồi tố.

Thống nhất cách xử lý phí hỗ trợ, khoản ghi có, NAT dùng chung và các cam kết sử dụng. So sánh nhất quán giá trị chi phí phân bổ dần (amortized) hoặc chi phí không gộp (unblended); trộn lẫn các cơ sở chi phí có thể khiến một truy vấn đúng trông như không khớp hóa đơn.

Chính sách tag giúp chuẩn hóa các tag được hỗ trợ, nhưng không tự động bảo đảm mọi yêu cầu tạo tài nguyên đều chứa đủ mọi tag bắt buộc. Sử dụng các kiểm tra khi cấp tài nguyên, điều kiện IAM và phát hiện tuân thủ phù hợp để lấp các khoảng trống.

Với một endpoint AI dùng chung, ghi lại các định danh ứng dụng/tenant đã được phê duyệt và lượng token đầu vào/đầu ra sử dụng trong luồng đo lường mức sử dụng mà không ghi log nội dung prompt. Đối soát mức sử dụng này với đơn giá mô hình/tier được tính phí và chi phí dung lượng dùng chung; chỉ riêng tag tài nguyên không thể phân chia từng yêu cầu trên một endpoint dùng chung.

Duy trì danh mục Unallocated với người chịu trách nhiệm khắc phục được chỉ định rõ. Một số khoản phí không thể gắn tag trực tiếp, nên quy tắc phân bổ được ghi lại trung thực hơn việc giả vờ rằng từng đô la đều ánh xạ rõ ràng đến một tài nguyên.

Kiểm chứng và khi nào cần đổi phương án

• Đối soát tổng chi phí đã phân bổ cộng với chưa phân bổ với dữ liệu tính phí, sử dụng cùng kỳ và cơ sở chi phí.
• Kiểm tra một tài nguyên thiếu tag, một khoản phí không thể gắn tag và mức sử dụng mạng dùng chung.
• Để người chịu trách nhiệm sản phẩm rà soát các giả định phân bổ trước khi coi báo cáo là cơ sở chuyển giao chi phí tài chính.

Các tài khoản chuyên biệt có thể khiến báo cáo cấp tài khoản là đủ. Chargeback thực tế cần quyết định kế toán của doanh nghiệp; chỉ riêng showback về mặt kỹ thuật không cho phép tính phí cho các phòng ban.

Điểm cần nhớ và tài liệu AWS

• Tag tài nguyên và tag tính phí đã kích hoạt là hai bước khác nhau.
• Tài khoản chuyên biệt cung cấp ranh giới phân bổ ban đầu hữu ích.
• Chi phí dùng chung cần mô hình phân bổ rõ ràng.
• Khoản chi chưa phân bổ là ngoại lệ hiển thị rõ, không phải phần bị bỏ sót.
• Đối soát đòi hỏi kỳ và cơ sở chi phí nhất quán.

AWS: tag phân bổ chi phí

Dịch vụ trong bài: Cost Categories · Cost Explorer · CUR · Organizations

Lưu trữ tài liệu theo nhu cầu truy xuất, không chỉ theo tuổi dữ liệu

Tình huống và yêu cầu

Bạn quản lý lưu trữ S3 cho một cổng tài liệu. Các tệp mới được mở thường xuyên trong ba mươi ngày. Hồ sơ hỗ trợ cũ hiếm khi được yêu cầu nhưng vẫn phải mở ngay lập tức; hồ sơ tuân thủ có thể mất vài giờ để truy xuất. Một tập dữ liệu khác có kiểu truy cập khó đoán.

Bộ phận tài chính muốn giảm chi phí lưu trữ, nhưng nhóm hỗ trợ không thể yêu cầu khách hàng chờ hàng giờ để lấy tệp đã hứa cung cấp tức thì. Bạn cần các chính sách lưu trữ riêng cho những yêu cầu truy xuất thực sự khác nhau.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Phân loại trước, rồi chuyển lớp. Tuổi dữ liệu là dấu hiệu hữu ích về khả năng truy cập, không thay thế được cam kết truy xuất.

Mô hình tư duy và luồng xử lý

Dữ liệu ít truy cập vẫn có thể cần truy cập tức thì; lưu trữ dạng archive thay đổi quy trình truy xuất của ứng dụng.

Phân loại tài liệu → chính sách lưu trữ → GET tức thì hoặc yêu cầu khôi phục → thông báo sẵn sàng → tải xuống

Nhánh khôi phục bất đồng bộ phải được thể hiện rõ cho người dùng, thay vì trông như một lượt tải xuống bị lỗi.

Cơ chế cốt lõi

Dùng Storage Lens, Inventory và dữ liệu đo lường truy cập để hiểu kích thước và mức sử dụng. Giữ các tệp truy cập thường xuyên trong Standard. Đánh giá Standard-IA hoặc Glacier Instant Retrieval cho truy cập không thường xuyên nhưng cần tức thì, bao gồm phí truy xuất, thời gian tối thiểu và hiệu quả chi phí theo kích thước đối tượng.

Với hồ sơ có thể chờ hàng giờ, so sánh các lựa chọn truy xuất của Glacier Flexible Retrieval và Deep Archive với thời hạn thực tế. Đừng cho rằng mọi tầng truy xuất đều có cùng thời gian hoặc tính sẵn sàng.

Intelligent-Tiering có thể phù hợp với kiểu truy cập khó đoán. Các tầng archive tùy chọn của nó cần được chủ động kích hoạt và có cơ chế khôi phục khác nhau; đặc điểm giám sát và đối tượng nhỏ ảnh hưởng đến hiệu quả chi phí.

Xử lý cả phiên bản hiện tại và không hiện tại trong quy tắc vòng đời, đồng thời tuân thủ Object Lock và thời hạn lưu giữ. Một đối tượng hiện tại giá rẻ không loại bỏ các phiên bản cũ đang tích lũy. One Zone-IA không phù hợp để giữ bản sao duy nhất khi yêu cầu độ bền bao gồm khả năng sống sót sau khi mất một AZ.

Kiểm chứng và khi nào cần đổi phương án

• Mô hình hóa đồng thời phí lưu trữ, yêu cầu, chuyển lớp, truy xuất và thời gian tối thiểu.
• Khôi phục các tệp archive có tính đại diện và kiểm thử trạng thái chờ/lỗi của cổng tài liệu.
• Xác minh tài liệu cần truy cập tức thì không bao giờ được đưa vào tầng truy xuất bất đồng bộ.

Nếu các tệp cũ lại được truy cập thường xuyên, giá archive rẻ nhất có thể khiến toàn bộ dịch vụ đắt hơn. Đánh giá lại bằng tổng chi phí cho mỗi lần truy xuất hữu ích, không chỉ chi phí lưu trữ GB hằng tháng.

Điểm cần nhớ và tài liệu AWS

• Tần suất truy cập và độ trễ truy xuất yêu cầu là hai khía cạnh riêng biệt.
• Truy xuất archive có thể là một quy trình ứng dụng bất đồng bộ.
• Hiệu quả chi phí vòng đời bao gồm chuyển lớp và thời gian tối thiểu.
• Dữ liệu có phiên bản cần quy tắc vòng đời có xét đến phiên bản.
• Đơn giá lưu trữ thấp nhất không nhất thiết mang lại tổng chi phí thấp nhất.

AWS: các lớp lưu trữ S3

Dịch vụ trong bài: S3 · S3 Storage Lens · S3 Intelligent-Tiering

So sánh PostgreSQL được quản lý với toàn bộ chi phí tự vận hành

Tình huống và yêu cầu

Bạn tư vấn cho một nhóm ba kỹ sư đang chạy PostgreSQL trên EC2. Doanh nghiệp hiện yêu cầu tính sẵn sàng cao, bản sao lưu đã được kiểm thử và vá lỗi định kỳ. Một kỹ sư cho rằng EC2 rẻ hơn vì một instance có giá thấp hơn một triển khai RDS Multi-AZ.

Ứng dụng không cần quyền truy cập hệ điều hành đặc biệt hay extension không được hỗ trợ. Bạn phải so sánh các kết quả dịch vụ tương đương, bao gồm công việc trực vận hành và phục hồi, thay vì so một máy chủ với cả cấu hình HA được quản lý.

Đây là quyết định lựa chọn cách cung ứng dịch vụ giả định.

Các phương án và quyết định

Đánh giá RDS Multi-AZ so với một thiết kế tự quản lý thực sự tương đương. Chọn phương án này trong tình huống này nếu tính tương thích và tổng chi phí đo được cho thấy lợi ích tiết kiệm vận hành.

Mô hình tư duy và luồng xử lý

Đơn vị bạn mua là kết quả dịch vụ cơ sở dữ liệu, không phải một giờ instance.

Yêu cầu ứng dụng → các thiết kế HA tương đương → ước tính tài nguyên và nhân công → kiểm tra tương thích/hiệu năng → quyết định di chuyển

Hóa đơn hạ tầng thấp hơn có thể che giấu tổng chi phí sở hữu (TCO) lớn hơn.

Cơ chế cốt lõi

Tính cả điện toán cho primary và standby, hiệu năng lưu trữ, sao lưu, truyền dữ liệu, giám sát, giấy phép, thời gian kỹ sư, công sức di chuyển và mức độ chịu rủi ro sự cố trong cùng một khoảng thời gian. Pricing Calculator ước tính tài nguyên AWS; công cụ này không biết khối lượng vận hành thực tế của nhóm.

RDS giảm các nhiệm vụ hạ tầng nhưng không chịu trách nhiệm về thiết kế schema, tinh chỉnh truy vấn, quyền người dùng hay hành vi kết nối của máy khách. Xác nhận phiên bản engine, extension và các hạn chế vận hành trước khi cam kết.

Aurora là một kiến trúc khác, không tự động là phương án thay thế RDS rẻ nhất. So sánh hiệu năng liên quan và hiệu quả chi phí I/O của nó với tải công việc. Mô hình công suất serverless cũng cần phân tích tải duy trì liên tục và công suất tối thiểu, thay vì giả định chi phí nhàn rỗi luôn bằng không.

Với cơ sở dữ liệu đã được quản lý, so sánh các yếu tố định giá thực tế: công suất DynamoDB on-demand so với provisioned/tự động co giãn, RDS reserved instances và Database Savings Plans đủ điều kiện. Kiểm tra điều kiện áp dụng hiện tại theo engine/Region và quy tắc cam kết thay vì áp dụng ưu đãi EC2 cho mọi cơ sở dữ liệu. Với Aurora, đo phí I/O trước khi chọn I/O-Optimized và so sánh mức công suất sàn serverless với chi phí provisioned ở trạng thái ổn định. Những lựa chọn này thay đổi mô hình chi phí, không thay đổi yêu cầu về tính đúng đắn hoặc phục hồi của tải công việc.

Lập kế hoạch rõ ràng cho việc kiểm chứng di chuyển và chuyển đổi hệ thống. Tiết kiệm vận hành chỉ bắt đầu sau khi dịch vụ mới đáp ứng các yêu cầu của ứng dụng.

Kiểm chứng và khi nào cần đổi phương án

• Benchmark cùng một cơ cấu giao dịch và kịch bản phục hồi trên các cấu hình tương đương.
• So sánh hóa đơn dự kiến với mức sử dụng quan sát được và các giả định nhân công thực tế.
• Tính lại cho tăng trưởng, giai đoạn ít tải hơn và thay đổi nhân sự.

Một mô-đun hệ điều hành không được hỗ trợ hoặc yêu cầu kiểm soát cơ sở dữ liệu ở mức thấp có thể khiến EC2 là lựa chọn đúng dù cần nhiều công việc vận hành hơn. Ngược lại, hạn chế nhân sự có thể khiến hóa đơn dịch vụ được quản lý cao hơn trở thành quyết định ít tốn kém hơn về tổng thể.

Điểm cần nhớ và tài liệu AWS

• So sánh các kết quả tương đương về tính sẵn sàng và phục hồi.
• TCO bao gồm nhân công và di chuyển, không chỉ giá tài nguyên.
• Cơ sở dữ liệu được quản lý vẫn để lại trách nhiệm cho khách hàng.
• Tính tương thích có thể quan trọng hơn lợi thế giá.
• Serverless và được quản lý không có nghĩa là luôn rẻ hơn.

AWS Pricing Calculator · AWS: tổng quan RDS · AWS: Database Savings Plans

Dịch vụ trong bài: RDS · Aurora · EC2 · Pricing Calculator

Khắc phục độ trễ lưu trữ khi volume cơ sở dữ liệu vẫn còn nhiều chỗ trống

Tình huống và yêu cầu

Bạn chạy cơ sở dữ liệu tự quản lý trên EC2 với volume EBS gp3 dung lượng 2-TB. Đĩa vẫn còn chỗ trống, nhưng độ trễ I/O ngẫu nhiên tăng trong giờ giao dịch cao điểm. Dữ liệu phải tồn tại sau khi thay instance, nên thay lưu trữ bền vững bằng đĩa tạm cục bộ không phải lối tắt chấp nhận được.

Bạn cần xác định nút thắt nằm ở số thao tác mỗi giây, thông lượng truyền, giới hạn instance hay chính ứng dụng trước khi tăng chi phí.

Đây là bài tập chẩn đoán giả định.

Các phương án và quyết định

Kiểm tra giới hạn của cả volume và EC2 trước. Trong bài tập này, các chỉ số được cung cấp cho thấy volume chạm mức IOPS đã cấp phát trong khi instance vẫn còn dư năng lực EBS, nên tăng IOPS gp3 là phương án đầu tiên cần xem xét.

Mô hình tư duy và luồng xử lý

Dung lượng lưu trữ, tốc độ thao tác và tốc độ byte là các khía cạnh khác nhau.

I/O cơ sở dữ liệu → hàng đợi hệ thống tệp → giới hạn IOPS/thông lượng volume EBS → giới hạn EBS của EC2 → thao tác hoàn tất

Tăng một giới hạn không thể vượt qua giới hạn chặt hơn ở nơi khác trên luồng.

Cơ chế cốt lõi

So sánh độ trễ đọc/ghi, độ dài hàng đợi, IOPS, thông lượng và mức EBS cho phép của instance. Kích thước yêu cầu liên kết tốc độ thao tác với tốc độ truyền: 10,000 thao tác mỗi giây, mỗi thao tác 16 KiB, tương đương khoảng 156 MiB/s, trước khi xét các ràng buộc khác.

Chỉ tăng hiệu năng gp3 trong giới hạn được hỗ trợ và xác nhận workload hưởng lợi. io2 có thể phù hợp với nhu cầu hiệu năng hoặc độ bền khắt khe hơn, nhưng tên và giá của nó không phải bằng chứng cho thấy cần dùng nó.

Kiểm tra kiểu truy cập của truy vấn và độ sâu hàng đợi. Tăng mức độ đồng thời có thể làm hàng đợi dài hơn thay vì tăng thông lượng hữu ích. Tách I/O tạm có thể bỏ đi khỏi dữ liệu bền vững nếu ứng dụng hỗ trợ việc đó an toàn.

Giữ các điểm khôi phục được mã hóa và nhất quán ở cấp ứng dụng. Lưu trữ khối bền vững không loại bỏ nhu cầu sao lưu hay quy trình khôi phục cơ sở dữ liệu.

Kiểm chứng và khi nào cần đổi phương án

• Đo hiệu năng với tỷ lệ I/O ngẫu nhiên/tuần tự và kích thước I/O thực tế, không dùng một mức đỉnh tổng hợp thuận tiện.
• So sánh độ trễ giao dịch p99 và chi phí mỗi giao dịch trước và sau thay đổi.
• Xác minh cải thiện không chỉ chuyển nút thắt sang băng thông instance hoặc khóa cơ sở dữ liệu.

Nếu giới hạn instance đang gây nghẽn, chỉ tăng IOPS volume sẽ không giúp ích. Nếu dữ liệu là dữ liệu tạm có thể bỏ đi với cách tái tạo đáng tin cậy, instance store có thể lại là lựa chọn phù hợp.

Điểm cần nhớ và tài liệu AWS

• Còn GB trống không có nghĩa còn dư IOPS hay thông lượng.
• Cả giới hạn volume và instance đều ràng buộc hiệu năng EBS.
• Kích thước I/O liên kết số thao tác mỗi giây với số byte mỗi giây.
• Mức độ đồng thời cao hơn không tự động tạo thông lượng cao hơn.
• Tinh chỉnh lưu trữ phải giữ nguyên mô hình độ bền của workload.

AWS: hiệu năng EBS

Dịch vụ trong bài: EBS · EC2 · CloudWatch

Xây dựng danh mục di chuyển có cả các phụ thuộc của ứng dụng

Tình huống và yêu cầu

Bạn phụ trách khảo sát hiện trạng cho một công ty sẽ đóng trung tâm dữ liệu trong chín tháng nữa. Danh mục hiện tại liệt kê hàng trăm máy ảo nhưng thiếu người phụ trách ứng dụng, mức sử dụng cao điểm, giấy phép và các phụ thuộc dịch vụ.

Người quản lý di chuyển cần các đợt di chuyển hợp lý và ước tính chi phí đáng tin cậy. Bộ phận bảo mật phải phê duyệt quyền truy cập phục vụ khảo sát, và không được bỏ sót các tác vụ cuối tháng chỉ vì thời gian quan sát tình cờ rơi vào một tuần ít hoạt động.

Đây là bài tập lập kế hoạch di chuyển giả định.

Các phương án và quyết định

Xây dựng danh mục lấy ứng dụng làm trung tâm và xác minh đồ thị phụ thuộc của nó. Danh sách máy chỉ là điểm khởi đầu, không phải kế hoạch di chuyển.

Mô hình tư duy và luồng xử lý

Khảo sát xác định những gì đang tồn tại; đánh giá giải thích ý nghĩa của chúng; theo dõi ghi nhận những gì đã được di chuyển.

CMDB và dữ liệu đo đạc được phê duyệt → bản đồ ứng dụng/phụ thuộc → người phụ trách rà soát → chiến lược và các đợt di chuyển → theo dõi tiến độ

Bản thân dịch vụ theo dõi không sao chép máy chủ hay di chuyển cơ sở dữ liệu.

Cơ chế cốt lõi

Ghi lại người phụ trách, mức độ quan trọng, phân loại dữ liệu, mục tiêu khôi phục, môi trường thực thi, giấy phép, cơ sở dữ liệu và các giao diện. Thu thập mức sử dụng CPU, bộ nhớ, đĩa và mạng qua các chu kỳ kinh doanh có ý nghĩa trước khi ước tính quy mô tài nguyên đích.

Với các cạnh phụ thuộc, ghi lại chiều kết nối, giao thức, lưu lượng và mức nhạy cảm với độ trễ. Dữ liệu đo đạc kết nối cho thấy hoạt động giao tiếp, chứ không cho biết liệu một kết nối không được quan sát thấy có thể được loại bỏ an toàn hay không. Đánh dấu rõ các phụ thuộc chưa được xác minh và đối chiếu chúng với người phụ trách ứng dụng.

Sử dụng các công cụ khảo sát và đánh giá đã được phê duyệt cho môi trường. Quyền truy cập của công cụ không được bỏ qua quy trình thay đổi production hoặc quy trình bảo mật, và dữ liệu cấu trúc liên kết hay tiến trình thu thập được cần được bảo vệ phù hợp.

Đánh giá các khả năng khảo sát và đánh giá hiện tại của AWS Transform đối với hệ thống nguồn, cùng với bằng chứng được phê duyệt về danh mục và mức sử dụng. Kiểm tra khả năng hỗ trợ workload và các quyền cần thiết trước khi chọn công cụ. Các khuyến nghị về phụ thuộc vẫn cần người phụ trách xác nhận: tự động hóa không thể biết một tác vụ nghiệp vụ hằng năm là quan trọng nếu dữ liệu đầu vào bỏ sót nó. Bảo đảm danh mục và các quyết định về đợt di chuyển có thể xuất ra và có người chịu trách nhiệm, thay vì ràng buộc kế hoạch vào một quy trình thiết lập ban đầu đã ngừng sử dụng.

Kiểm chứng và khi nào cần đổi phương án

• Lần theo một ứng dụng tiêu biểu từ điểm truy cập của người dùng qua hệ thống định danh, cơ sở dữ liệu, xử lý theo lô và các phụ thuộc bên ngoài.
• So sánh mức sử dụng đo được với hiểu biết của người phụ trách về các đợt cao điểm và tác vụ ít khi chạy.
• Đưa cả công sức di chuyển và chi phí vận hành tại đích vào đánh giá, không chỉ giá VM.

Với một hệ thống nhỏ được ghi chép đầy đủ, danh mục đơn giản và các phép đo có mục tiêu có thể là đủ. Với một hệ thống chưa rõ hiện trạng, bỏ qua khảo sát tạo ra rủi ro di chuyển mà công cụ sao chép nhanh hơn cũng không giải quyết được.

Điểm cần nhớ và tài liệu AWS

• Ứng dụng, chứ không phải kích thước VM, xác định các nhóm di chuyển hữu ích.
• Dữ liệu đo đạc và hiểu biết của người phụ trách trả lời những câu hỏi khác nhau.
• Không quan sát thấy lưu lượng không chứng minh rằng không có phụ thuộc.
• Khảo sát, đánh giá và thực hiện di chuyển là các hoạt động riêng biệt.
• Đánh giá tự động vẫn cần người phụ trách xác nhận và khả năng hỗ trợ hệ thống nguồn hiện tại.

AWS: các nhiệm vụ di chuyển trong SAP-C03 · AWS: lập kế hoạch di chuyển

Dịch vụ trong bài: AWS Transform · Migration Evaluator

Chọn chiến lược di chuyển khi hạn chót rời trung tâm dữ liệu không cho phép viết lại mọi thứ

Tình huống và yêu cầu

Bạn phụ trách kế hoạch rời trung tâm dữ liệu trong sáu tháng. Danh mục gồm một công cụ nội bộ không còn được sử dụng, một hệ thống ERP được nhà cung cấp hỗ trợ, một website cũ tạo ra doanh thu và một dịch vụ đang tăng trưởng sẽ hưởng lợi từ việc thiết kế lại.

Nhóm không thể viết lại mọi thứ trước khi hợp đồng thuê kết thúc. Bạn phải quyết định workload nào cần di chuyển với thay đổi tối thiểu, cải tiến trong quá trình di chuyển, thay thế, tạm giữ lại hoặc ngừng sử dụng. Các phụ thuộc và giấy phép có thể khiến một kế hoạch vốn hấp dẫn trở nên không khả thi.

Đây là bài tập danh mục ứng dụng giả định.

Các phương án và quyết định

Dùng bảy chiến lược di chuyển làm các nhóm lựa chọn, không phải bảng xếp hạng. Rehost ngay và hiện đại hóa sau có thể là kế hoạch có chủ đích nếu công việc sau đó có người chịu trách nhiệm và ngân sách.

Mô hình tư duy và luồng xử lý

Câu hỏi di chuyển là nên làm gì với từng ứng dụng, không phải công cụ sao chép nào sẽ chuyển mọi máy chủ.

Mục đích kinh doanh và ràng buộc → quyết định chiến lược → đợt di chuyển có xét phụ thuộc → di chuyển hoặc ngừng sử dụng → kiểm chứng kết quả

Cơ chế cốt lõi

• Retire (ngừng sử dụng): loại bỏ ứng dụng sau khi xác nhận mức sử dụng và nghĩa vụ lưu giữ dữ liệu. Công cụ không được dùng là một ứng viên, không phải đối tượng tự động bị xóa.
• Retain (giữ lại): tạm giữ workload ở nơi hiện tại khi các ràng buộc ngăn cản việc di chuyển, kèm ngày rà soát và phương án lưu trú hệ thống khả thi.
• Rehost (chuyển nguyên trạng): di chuyển máy chủ với ít thay đổi, có thể dùng AWS Transform MGN (trước đây là Application Migration Service) cho các hệ thống được hỗ trợ.
• Relocate (di dời nền tảng): di chuyển hệ thống nền tảng bằng các khả năng được nền tảng hỗ trợ với ít thay đổi ứng dụng; xác minh dịch vụ hiện có và sự hỗ trợ về giấy phép.
• Repurchase (mua giải pháp thay thế): thay thế chức năng bằng SaaS, bao gồm cả công việc di chuyển dữ liệu và tích hợp.
• Replatform (chuyển nền tảng): giữ phần lớn hành vi của ứng dụng trong khi sử dụng một thành phần được quản lý như RDS.
• Refactor/re-architect (tái cấu trúc/tái kiến trúc): thiết kế lại khi giá trị kinh doanh xứng đáng với chi phí và rủi ro triển khai.

Với mỗi lựa chọn, ghi lại người phụ trách, thời gian ngừng hoạt động cho phép, các phụ thuộc, kỹ năng, chi phí di chuyển, chi phí vận hành tương lai và ràng buộc từ nhà cung cấp. Với mainframe hoặc hệ thống cũ có liên kết chặt chẽ khác, hãy lập danh mục ranh giới giao dịch, lịch xử lý theo lô, định dạng dữ liệu và hợp đồng tích hợp trước khi chọn các khả năng được AWS Transform hỗ trợ. Kết quả chuyển đổi được tạo ra vẫn cần kiểm thử hồi quy và đối soát nghiệp vụ; chuyển đổi không chứng minh hành vi tương đương.

Di chuyển tăng dần theo mô hình strangler đặt một ranh giới định tuyến/API trước hệ thống cũ, rồi chuyển từng chức năng một. Xác định quyền sở hữu dữ liệu và cơ chế đồng bộ trong giai đoạn cùng tồn tại để dịch vụ cũ và mới không cùng trở thành các bên ghi dữ liệu thiếu kiểm soát. Cách này giảm phạm vi cutover nhưng có thể kéo dài thời gian vận hành hai hệ thống. Công cụ không bao giờ cấp quyền sử dụng giấy phép hay thay thế các điều khoản của nhà cung cấp.

Kiểm chứng và khi nào cần đổi phương án

• Kiểm tra rằng các workload được giữ lại vẫn có nơi vận hành khả thi sau khi rời trung tâm dữ liệu.
• Rà soát tổng thể các đợt di chuyển dựa trên năng lực của nhóm và các phụ thuộc dùng chung.
• Xác nhận nghiệm thu việc di chuyển và ngừng sử dụng với người phụ trách ứng dụng, bao gồm các hồ sơ được lưu giữ và các tích hợp.

Hợp đồng nhà cung cấp sắp hết hạn có thể khiến repurchase trở nên hấp dẫn; một phụ thuộc không được hỗ trợ có thể buộc phải tạm giữ lại. Chiến lược thay đổi khi ràng buộc thay đổi, không phải khi một dịch vụ khác trở thành xu hướng.

Điểm cần nhớ và tài liệu AWS

• Chiến lược di chuyển phụ thuộc vào từng workload.
• Rehost và hiện đại hóa sau đó có thể là hai giai đoạn được cấp ngân sách riêng.
• Ngừng sử dụng cần xác minh mức sử dụng và yêu cầu lưu giữ dữ liệu.
• Giữ lại cần có kế hoạch tương lai rõ ràng.
• Theo dõi giấy phép không đồng nghĩa với quyền sử dụng giấy phép.

AWS: các chiến lược di chuyển

Dịch vụ trong bài: AWS Transform MGN · AWS Transform · RDS · API Gateway

Lập kế hoạch các đợt di chuyển theo phụ thuộc và khung cutover bốn giờ

Tình huống và yêu cầu

Bạn điều phối việc di chuyển của một nhà sản xuất. Các máy chủ ERP, cơ sở dữ liệu, tác vụ xử lý theo lô hằng đêm và Active Directory phụ thuộc lẫn nhau. Mỗi cuối tuần chỉ có bốn giờ để cutover, trong khi AWS landing zone vẫn thiếu sự nhất quán về định danh, ghi log và mạng.

Doanh nghiệp không thể chuyển mọi thứ cùng lúc. Bạn cần các đợt di chuyển phù hợp với năng lực của nhóm mà không để các lời gọi ứng dụng/cơ sở dữ liệu trao đổi liên tục phải đi qua một kết nối WAN không phù hợp.

Đây là bài tập di chuyển giả định.

Các phương án và quyết định

Xây dựng nền tảng landing zone trước, rồi phân nhóm các đợt theo phụ thuộc và mức độ quan trọng. Thực hiện một đợt thí điểm tiêu biểu có rủi ro thấp hơn trước đợt ERP cốt lõi.

Mô hình tư duy và luồng xử lý

Một đợt di chuyển là một hệ thống nghiệp vụ nhất quán trong giai đoạn tạm thời, không chỉ là danh sách máy chủ.

Landing zone và kết nối hybrid → thí điểm tiêu biểu → diễn tập nhóm phụ thuộc → cutover → kiểm chứng nghiệp vụ

Giai đoạn hybrid cũng phải hoạt động được, không chỉ thiết kế cuối cùng hoàn toàn trên đám mây.

Cơ chế cốt lõi

Chuẩn bị tài khoản, định danh, kiểm toán, mã hóa, sao lưu và trách nhiệm quản lý mạng thông qua quy trình quản trị và hạ tầng đã thiết lập. DX hoặc VPN và DNS hybrid cần được kiểm tra thông lượng và độ trễ, không chỉ kiểm tra ping thành công.

Lập bản đồ những phụ thuộc phải chuyển cùng nhau và những phụ thuộc có thể chấp nhận đường kết nối tạm thời qua ranh giới môi trường. Đưa vào cả định danh, tác vụ theo lịch, tích hợp bên ngoài và giấy phép thay vì chỉ máy chủ web và cơ sở dữ liệu.

Chỉ định rõ người chịu trách nhiệm tạm dừng ghi, kiểm tra sao chép, định tuyến, kiểm chứng và quyết định tiếp tục hay dừng. Trước khung thời gian thực hiện, xác minh bản sao lưu, năng lực tài nguyên đích, hạn ngạch và tiêu chí rollback.

Trong quá trình cutover, dừng hoặc kiểm soát thao tác ghi, áp dụng các thay đổi còn lại, kiểm chứng, chuyển lưu lượng và quan sát hành vi nghiệp vụ. Khi đích đã nhận thao tác ghi mới, chuyển lưu lượng trở lại nguồn cũ đòi hỏi đối soát hoặc đồng bộ ngược; đó không còn là rollback mạng đơn giản.

Kiểm chứng và khi nào cần đổi phương án

• Diễn tập toàn bộ trình tự bốn giờ, bao gồm thời gian ra quyết định và rollback.
• Đo độ trễ của các phụ thuộc hybrid trong các đợt trung gian.
• Yêu cầu người phụ trách kiểm chứng các luồng xử lý theo lô và downstream, không chỉ việc khởi động máy chủ.

Một ứng dụng liên kết chặt chẽ có thể cần một đợt phối hợp lớn hơn hoặc thỏa thuận bảo trì khác. Các dịch vụ stateless độc lập có thể chuyển riêng. Bằng chứng về phụ thuộc, chứ không phải kích thước đợt cố định, quyết định cách phân nhóm.

Điểm cần nhớ và tài liệu AWS

• Quản trị và kết nối phải có trước khi di chuyển production.
• Ranh giới phụ thuộc hữu ích hơn số lượng VM.
• Các trạng thái hybrid trung gian cần được hỗ trợ rõ ràng.
• Khung cutover bao gồm cả kiểm chứng và ra quyết định.
• Thao tác ghi tại đích làm thay đổi bài toán rollback.

AWS: hướng dẫn di chuyển quy mô lớn

Dịch vụ trong bài: Control Tower · Organizations · Direct Connect · Route 53

Di chuyển máy chủ cũ với quy trình cutover một giờ đã được kiểm thử

Tình huống và yêu cầu

Bạn di chuyển một ứng dụng cũ có quá trình cài đặt phụ thuộc vào các thành phần Linux hoặc Windows được ghi chép sơ sài. Dựng lại từ đầu có nguy cơ khiến bạn lỡ hạn rời trung tâm dữ liệu.

Hệ điều hành và đĩa được AWS Transform MGN (trước đây là AWS Application Migration Service) hỗ trợ, bộ phận bảo mật cho phép agent sao chép của dịch vụ, và mạng có thể duy trì việc sao chép. Doanh nghiệp cho phép gián đoạn tối đa một giờ khi cutover. Bạn phải chứng minh hành vi ứng dụng đúng, không chỉ EC2 khởi động được.

Đây là bài tập di chuyển giả định.

Các phương án và quyết định

Dùng MGN để chuẩn bị và kiểm thử đích trước khi cutover. Sao chép làm giảm lượng thay đổi cuối cùng cần đồng bộ; nó không loại bỏ công việc dừng ứng dụng và nghiệm thu.

Mô hình tư duy và luồng xử lý

Di chuyển phần lớn máy chủ khi nó đang chạy, rồi chuyển quyền vận hành trong một khoảng tạm dừng có kiểm soát.

Agent nguồn → vùng lưu trữ sao chép trung gian → khởi chạy thử cô lập → đồng bộ cuối cùng → EC2 cutover → chuyển lưu lượng

Đích thử nghiệm không được vô tình hoạt động như một instance production thứ hai.

Cơ chế cốt lõi

Trước tiên, xác nhận các giới hạn về hệ điều hành, đĩa, khởi động, giấy phép và dịch vụ. Chuẩn bị subnet trung gian, IAM role, mã hóa và kết nối cần thiết theo thiết kế MGN được hỗ trợ. Giới hạn chặt quyền của người vận hành và quyền truy cập mạng.

Cấu hình thiết lập khởi chạy cho loại instance đích, subnet, security group và đĩa. Kiểm thử trong môi trường cô lập để các tác vụ theo lịch, email và tích hợp được sao chép không thể thay đổi hệ thống production hoặc liên hệ khách hàng.

Khi cutover, dừng các thao tác ghi ứng dụng phù hợp, chờ sao chép phần còn lại, khởi chạy và kiểm chứng đích, rồi chuyển DNS hoặc lưu lượng khác. Giữ nguồn ở trạng thái bị chặn hoạt động hoặc đã dừng theo kế hoạch rollback.

Khi đích nhận thao tác ghi mới, các thay đổi đó không tự động quay về nguồn ban đầu. Xác định cách rollback bảo toàn chúng trước khi mở lưu lượng. Chỉ hoàn tất và xóa tài nguyên sao chép sau thời gian quan sát đã thống nhất.

Kiểm chứng và khi nào cần đổi phương án

• Kiểm thử giao dịch ứng dụng, các phụ thuộc, giấy phép và hiệu năng trên đích cô lập.
• Diễn tập toàn bộ khung gián đoạn, bao gồm đồng bộ cuối cùng và nghiệm thu.
• Xác minh các thao tác ghi tại đích và việc chặn nguồn hoạt động trước khi tuyên bố hoàn tất.

Một workload đã sẵn sàng chuyển nền tảng sang dịch vụ được quản lý có thể không cần sao chép toàn bộ máy chủ. Khôi phục sau thảm họa liên tục là một vòng đời khác, trong đó Elastic Disaster Recovery có thể phù hợp; đừng coi di chuyển và DR thường trực là các quy trình giống nhau.

Điểm cần nhớ và tài liệu AWS

• Rehost giữ lại nhiều giả định hiện có của ứng dụng.
• Sao chép ban đầu nên hoàn tất trước khung cutover.
• Khởi chạy thử cần được cô lập khỏi các tác động nghiệp vụ thực tế.
• Khởi động thành công không chứng minh ứng dụng hoạt động đúng.
• Các thao tác ghi sau cutover đòi hỏi kế hoạch dữ liệu rollback rõ ràng.

AWS: AWS Transform MGN

Dịch vụ trong bài: AWS Transform MGN · EC2 · IAM

Di chuyển dữ liệu Oracle sang PostgreSQL với khoảng tạm dừng ghi ngắn ở bước cuối

Tình huống và yêu cầu

Bạn phụ trách một đợt di chuyển nhiều terabyte từ Oracle sang PostgreSQL. Ứng dụng dùng stored procedure và các kiểu dữ liệu riêng của Oracle, nhưng nhóm có thời gian điều chỉnh mã trước lịch di chuyển. Doanh nghiệp chỉ cho phép ngừng ghi ba mươi phút khi cutover.

Nguồn hỗ trợ ghi log giao dịch cần thiết để thu thập thay đổi. Bạn cần schema và hành vi ứng dụng tương thích, đích được đồng bộ, cùng kế hoạch rollback có tính đến mọi thao tác ghi được chấp nhận sau khi chuyển đổi.

Đây là bài tập di chuyển giả định.

Các phương án và quyết định

Tách việc chuyển đổi schema/ứng dụng khỏi việc di chuyển dữ liệu. Sử dụng công cụ chuyển đổi được hỗ trợ và khắc phục thủ công, sau đó dùng DMS full load với change data capture (CDC).

Mô hình tư duy và luồng xử lý

DMS di chuyển các thay đổi dữ liệu được hỗ trợ; nó không tự động chuyển đổi mọi quy tắc nghiệp vụ.

Đánh giá schema → đích PostgreSQL tương thích

Dữ liệu Oracle ban đầu + thay đổi trong log giao dịch → DMS → đích → tạm dừng ghi cuối cùng và đồng bộ bắt kịp → chuyển ứng dụng

Khoảng tạm dừng cuối chỉ ngắn nếu công tác chuẩn bị và sao chép đã hoàn thành phần lớn công việc.

Cơ chế cốt lõi

Đánh giá procedure, kiểu dữ liệu, sequence, ràng buộc và hành vi SQL bằng DMS Schema Conversion hoặc công cụ chuyển đổi khác được hỗ trợ cho cặp nguồn/đích. Kiểm thử các truy vấn ứng dụng đã viết lại trước khi lên lịch cutover.

Chuẩn bị endpoint, thông tin xác thực, TLS, quyền và năng lực sao chép. Giữ log nguồn đủ lâu cho full load và đồng bộ bắt kịp; mất các log cần thiết có thể buộc phải bắt đầu lại. Rà soát cách xử lý đối tượng lớn và các bảng không có khóa phù hợp.

Theo dõi độ trễ nguồn/đích, lỗi bảng và sai lệch khi kiểm chứng. Một tác vụ sao chép đang chạy không chứng minh mọi bảng đều đúng hay các thao tác ghi đã được đồng bộ kịp.

Khi cutover, dừng ghi tại nguồn, xử lý hết các thay đổi CDC còn lại, đối soát trạng thái cuối, xử lý sequence và ràng buộc theo kế hoạch, rồi thay đổi kết nối ứng dụng. Giữ các bản sao lưu và tiếp tục ngăn nguồn nhận thao tác ghi. Đồng bộ ngược sau khi đích nhận thao tác ghi là một thiết kế riêng, không phải hệ quả tự động của việc bật CDC.

Kiểm chứng và khi nào cần đổi phương án

• So sánh các bất biến nghiệp vụ và giao dịch tiêu biểu, không chỉ số hàng.
• Diễn tập khoảng tạm dừng cuối, giá trị sequence, thay đổi kết nối và quyết định rollback.
• Kiểm thử việc lưu giữ log nguồn và khôi phục sau gián đoạn sao chép.

Một cơ sở dữ liệu nhỏ với khung thời gian rộng có thể phù hợp hơn với dump/restore đơn giản. Di chuyển cùng engine có thể dùng cơ chế sao chép tích hợp của engine. Chuyển đổi engine làm phát sinh công việc về ngữ nghĩa mà dịch vụ truyền dữ liệu nhanh hơn không thể loại bỏ.

Điểm cần nhớ và tài liệu AWS

• Chuyển đổi schema và sao chép dữ liệu là các công việc khác nhau.
• CDC phụ thuộc vào khả năng truy cập log thay đổi của nguồn.
• Sao chép gần thời gian thực vẫn có độ trễ và các trường hợp lỗi.
• Các hàng dữ liệu bằng nhau không chứng minh ứng dụng tương thích.
• Thao tác ghi tại đích làm thay đổi yêu cầu rollback.

AWS: Database Migration Service

Dịch vụ trong bài: DMS · DMS Schema Conversion · RDS · Aurora

Di chuyển hai trăm terabyte trước hạn di chuyển

Tình huống và yêu cầu

Bạn phải chuyển kho lưu trữ tệp của một công ty lên S3 trong hai tuần. Nguồn có 200 TB, nhưng đường truyền tải lên hiện tại chỉ có băng thông sử dụng được là 200 Mbps. Các tệp vẫn tiếp tục thay đổi, và bộ phận bảo mật yêu cầu truyền có mã hóa, xác minh và xử lý có kiểm soát mọi phương tiện lưu trữ vật lý.

Trong bài tập này, nhà mạng có thể cung cấp kết nối nhanh hơn kịp thời, với điều kiện thử nghiệm thí điểm thông lượng đạt yêu cầu. Bạn phải xác định dung lượng đường truyền đó và tính cả các thay đổi cuối cùng, thay vì chọn công cụ trước khi kiểm tra liệu dữ liệu có thể đến đúng hạn hay không.

Dung lượng, băng thông và thời gian cung cấp của nhà mạng là các giả định hư cấu.

Các phương án và quyết định

Dùng đường truyền được nâng cấp và DataSync sau một đợt thí điểm tiêu biểu. Chỉ tăng tốc truyền không thể loại bỏ trần năng lực của đường truyền tải lên hiện có.

Mô hình tư duy và luồng xử lý

Bản dữ liệu nền khối lượng lớn chuyển dữ liệu cũ; lần đồng bộ cuối thiết lập trạng thái cutover.

Tệp nguồn → lần truyền DataSync ban đầu → các lần chạy tăng dần → tạm dừng ghi có kiểm soát hoặc snapshot nguồn nhất quán → xác minh cuối cùng → chuyển bên sử dụng dữ liệu

Cả phương án trực tuyến lẫn ngoại tuyến đều cần kế hoạch cho các thao tác ghi phát sinh trong quá trình truyền.

Cơ chế cốt lõi

Ước tính thời gian bằng bytes × 8 / số bit sử dụng được mỗi giây. Ở 200 Mbps, 200 TB theo hệ thập phân mất khoảng tám triệu giây. Để đáp ứng hai tuần, cần khoảng 1.32 Gbps chỉ cho việc truyền khối lượng lớn liên tục trong điều kiện lý tưởng, cộng thêm dung lượng dự phòng cho thời gian thiết lập, chi phí phụ trội, thử lại và dữ liệu thay đổi.

Kiểm tra thông lượng đọc của nguồn, số lượng tệp, cách xử lý metadata và các yêu cầu đến đích. Đường truyền nhanh hơn không khắc phục được hệ thống tệp nguồn không thể cấp dữ liệu đủ nhanh. Cấu hình agent/connector DataSync được hỗ trợ, quyền endpoint, mã hóa và hành vi xác minh cho các loại lưu trữ đã chọn.

Transfer Family cung cấp các endpoint giao thức truyền tệp được quản lý và hỗ trợ cho đối tác; nó không mặc nhiên là công cụ tối ưu hóa di chuyển dữ liệu khối lượng lớn.

Nếu không thể có băng thông trực tuyến kịp thời, đánh giá một địa điểm Data Transfer Terminal sẵn có hoặc đối tác truyền dữ liệu vật lý được phê duyệt. Tính cả việc sao chép sang thiết bị lưu trữ di động, vận chuyển vật lý, đặt lịch/quyền vào địa điểm, thời gian tải lên, mã hóa và quản lý bàn giao phương tiện lưu trữ, cùng phần thay đổi cuối truyền trực tuyến. Data Transfer Terminal cung cấp địa điểm vật lý để truyền dữ liệu băng thông cao; đây không phải cam kết AWS gửi thiết bị đến mọi khách hàng.

Kiểm chứng và khi nào cần đổi phương án

• Thí điểm với các tệp lớn và nhỏ tiêu biểu, kiểm tra thông lượng sử dụng được, metadata và kết quả xác minh.
• Đo khối lượng thay đổi hằng ngày và diễn tập khung đồng bộ cuối.
• Xác nhận quyền truy cập của bên sử dụng dữ liệu, chi phí và việc lưu giữ nguồn trước khi tuyên bố hoàn tất.

Nếu năng lực đường truyền nâng cấp không thể được cung cấp kịp thời, truyền bằng phương tiện vật lý có thể trở nên cần thiết. Thời gian vận chuyển và xử lý của phương án này phải được đưa vào cùng phép tính thời hạn, và phần thay đổi truyền trực tuyến vẫn cần đủ năng lực đường truyền.

Điểm cần nhớ và tài liệu AWS

• Tính khả thi của việc truyền bắt đầu từ dung lượng, băng thông sử dụng được và thời gian.
• Tăng tốc không thể vượt qua nút thắt cứng của đường truyền tải lên tại nguồn.
• Số lượng tệp và I/O nguồn có thể giới hạn thông lượng.
• Truyền khối lượng lớn và đạt tính nhất quán cuối cùng là hai cột mốc riêng.
• Phải kiểm tra tính sẵn có của dịch vụ trước khi dựa vào thiết bị vật lý.

AWS: DataSync · AWS: Data Transfer Terminal

Dịch vụ trong bài: DataSync · Transfer Family · S3 · Direct Connect · Data Transfer Terminal

Khôi phục nền tảng giao dịch trong vòng ba mươi phút sau sự cố cấp Region

Tình huống và yêu cầu

Bạn thiết kế phương án khôi phục sau thảm họa cho một nền tảng giao dịch. Doanh nghiệp cho phép gián đoạn ba mươi phút và mất tối đa năm phút cập nhật sau sự cố cấp Region.

Trong bài tập này, giả định một lần diễn tập trước đó cho thấy việc khôi phục cơ sở dữ liệu 4-TB mất hơn hai giờ và khởi động toàn bộ hệ thống điện toán mất bốn mươi phút. Bộ phận tài chính sẽ cấp ngân sách cho một môi trường nhỏ hơn đang chạy ở Region khác, nhưng không đủ cho hai môi trường triển khai hoạt động đầy đủ.

Đây là dữ liệu đầu vào giả định cho bài tập, không phải kết quả đo hiệu năng.

Các phương án và quyết định

Chọn warm standby làm thiết kế ứng viên, rồi chứng minh thiết kế đáp ứng các mục tiêu. Active-active có thể giảm công việc khôi phục nhưng làm tăng chi phí và độ phức tạp của việc phối hợp ghi vượt quá yêu cầu này.

Mô hình tư duy và luồng xử lý

Duy trì một hệ thống nhỏ hoạt động được, không chỉ những thành phần để tạo nên hệ thống đó.

Ghi tại hệ thống chính → sao chép bất đồng bộ giữa các Region → cơ sở dữ liệu dự phòng

Tuyên bố sự cố → chặn writer cũ → nâng cấp dự phòng thành chính → mở rộng và kiểm tra ứng dụng → định tuyến người dùng

RTO là thời gian khôi phục có thể chấp nhận; RPO là mức mất dữ liệu có thể chấp nhận, đo bằng thời gian.

Cơ chế cốt lõi

Cấu hình sẵn mạng, vai trò, thông tin bí mật, chứng chỉ và tài nguyên điện toán tối thiểu. Giám sát độ trễ sao chép so với RPO năm phút, đồng thời hiểu rằng sao chép bất đồng bộ không thể bảo đảm giới hạn đó trong mọi sự cố.

RTO bao gồm phát hiện, ra quyết định, nâng cấp dự phòng thành chính, mở rộng, kiểm chứng và chuyển lưu lượng. Hạn ngạch và năng lực tài nguyên sẵn có đều quan trọng khi mở rộng; chỉ có mẫu triển khai không đồng nghĩa với việc đã giữ chỗ tài nguyên.

Với container, duy trì một cụm ECS/EKS riêng được hỗ trợ trong Region khôi phục, có manifest tương thích, image sẵn có, thông tin bí mật, ingress, danh tính và năng lực tối thiểu. Chỉ có cụm thứ hai không tự sao chép persistent volume hay dữ liệu ứng dụng. Kiểm thử triển khai cùng với khôi phục dữ liệu; đừng mặc định một cụm Kubernetes trải rộng qua các Region xa nhau là thiết kế DR.

Ngăn cả hai Region cùng chấp nhận các thao tác ghi xung đột trong quá trình khôi phục. Xác định dữ liệu nào đã tới bản sao trước khi công bố mốc dữ liệu được khôi phục. Lưu trữ đối tượng và các thành phần phụ thuộc bên ngoài cần đường khôi phục riêng, không chỉ bản sao cơ sở dữ liệu.

Duy trì các bản sao lưu độc lập vì quá trình sao chép có thể lan truyền việc xóa nhầm hoặc dữ liệu hỏng. Elastic Disaster Recovery phù hợp với các hình thức khôi phục dựa trên máy chủ được hỗ trợ; dịch vụ này không thay thế cơ chế sao chép của mọi cơ sở dữ liệu được quản lý.

Kiểm chứng và khi nào cần đổi phương án

• Diễn tập sự cố cấp Region với tải đại diện và ghi lại thời gian khôi phục dịch vụ thực tế cùng các cập nhật đã commit nhưng bị thiếu.
• Bao gồm tình huống phát hiện chậm, sao chép bị trễ và năng lực dự phòng không đủ.
• Diễn tập failback để hệ thống được khôi phục không mất các thao tác ghi khi quay về Region ban đầu.

Nếu có thể ngừng hoạt động vài giờ, sao lưu/khôi phục có thể kinh tế hơn. Nếu bắt buộc phải có tính sẵn sàng gần như liên tục và mục tiêu nghiêm ngặt hơn về mất dữ liệu ghi, hãy đánh giá một kiến trúc dữ liệu khác thay vì chỉ đổi tên thiết kế này.

Điểm cần nhớ và tài liệu AWS

• RTO đo thời gian khôi phục; RPO đo mức mất dữ liệu cho phép.
• Warm standby vẫn cần nâng cấp dự phòng thành chính, bổ sung năng lực và xử lý định tuyến.
• Sao chép bất đồng bộ có nguy cơ mất dữ liệu liên quan đến độ trễ.
• Các bản sao không thay thế những điểm khôi phục độc lập.
• DR được chứng minh bằng diễn tập, không phải bằng tên gọi kiến trúc.

AWS: các chiến lược khôi phục sau thảm họa

Dịch vụ trong bài: RDS · Route 53 · AWS Backup · Elastic Disaster Recovery · ECS · EKS

Chỉ chuyển lưu lượng giữa các Region sau khi hệ thống dự phòng sẵn sàng nhận ghi

Tình huống và yêu cầu

Bạn vận hành một dịch vụ đơn hàng có Region dự phòng. Việc nâng cấp cơ sở dữ liệu dự phòng thành chính là một phần của runbook khôi phục, nhưng không được chuyển lưu lượng cho đến khi hệ thống dự phòng có writer hợp lệ và vượt qua các kiểm tra giao dịch.

Đội vận hành muốn chuẩn bị các cơ chế điều khiển khôi phục trước sự cố, thay vì phụ thuộc vào việc tạo bản ghi DNS khẩn cấp. Một số client cache DNS rất lâu, nên Region ban đầu không được tiếp tục chấp nhận các thao tác ghi xung đột trong quá trình chuyển đổi.

Đây là một bài tập thiết kế giả định.

Các phương án và quyết định

Cấu hình sẵn failover của Route 53 và routing control của ARC. Gắn việc chuyển lưu lượng với trình tự khôi phục ứng dụng, không chỉ với một phép thăm dò HTTP.

Mô hình tư duy và luồng xử lý

DNS chuyển hướng các lần tra cứu trong tương lai; nó không di chuyển các phiên hiện có hay nâng cấp cơ sở dữ liệu dự phòng thành chính.

Chặn writer cũ → nâng cấp dự phòng thành chính → xác minh giao dịch → thay đổi trạng thái định tuyến ARC → câu trả lời Route 53 ưu tiên hệ thống dự phòng → client kết nối lại

Tiếp tục chặn writer cũ trong khi các câu trả lời được cache vẫn có thể đưa client tới đó.

Cơ chế cốt lõi

Tạo trước các bản ghi và kiểm tra tình trạng cho routing control. Routing control của ARC cho phép quy trình khôi phục thay đổi trạng thái tình trạng mà cấu hình DNS đã chuẩn bị sử dụng. Dùng các endpoint data plane khôi phục của ARC theo tài liệu thay vì dựa vào việc tạo tài nguyên mới trong sự cố.

Các quy tắc an toàn có thể ngăn những tổ hợp trạng thái routing control không hợp lệ, chẳng hạn vô tình vô hiệu hóa tất cả các tuyến dự định sử dụng. Bản thân chúng không thực thi quyền sở hữu ghi của cơ sở dữ liệu; fencing vẫn là trách nhiệm của ứng dụng/dữ liệu.

TTL DNS ảnh hưởng tới thời gian tồn tại của cache, nhưng client và các kết nối hiện có có thể mất nhiều thời gian để chuyển hơn so với một ước tính TTL đơn giản. Đo hành vi trên các loại client thực tế.

Chọn chính sách định tuyến theo mục đích: định tuyến có trọng số phân phối lưu lượng, định tuyến theo độ trễ lựa chọn giữa các endpoint cấp Region, còn định tuyến failover thể hiện ưu tiên chính/phụ. Định tuyến theo vị trí địa lý không phải cơ chế kiểm soát đầy đủ về nơi lưu trú dữ liệu.

Kiểm chứng và khi nào cần đổi phương án

• Diễn tập khôi phục khi hệ thống dự phòng ban đầu chưa khỏe mạnh và xác minh lưu lượng không chuyển quá sớm.
• Kiểm tra nhiều DNS resolver, các kết nối tồn tại lâu và các client vẫn dùng địa chỉ cũ.
• Kiểm thử các thay đổi routing control không hợp lệ và xác nhận fencing writer vẫn có hiệu lực.

Một dịch vụ phi trạng thái với hệ thống phụ luôn sẵn sàng có thể dùng failover dựa trên tình trạng đơn giản hơn. Tình huống này cần trình tự có kiểm soát vì một endpoint truy cập được chưa chắc đã là đích an toàn cho giao dịch.

Điểm cần nhớ và tài liệu AWS

• Chuẩn bị cơ chế điều khiển khôi phục trước sự cố.
• HTTP khỏe mạnh không đồng nghĩa với cơ sở dữ liệu sẵn sàng.
• Thay đổi DNS không di chuyển các kết nối hiện có.
• Các biện pháp bảo vệ định tuyến của ARC không thay thế fencing writer.
• Các chính sách định tuyến biểu đạt những quyết định khác nhau, không phải những tính năng HA có thể thay thế cho nhau.

AWS: routing control của ARC

Dịch vụ trong bài: Route 53 · ARC

Quay về Region ban đầu mà không mất các giao dịch phát sinh trong giai đoạn khôi phục

Tình huống và yêu cầu

Bạn đang khôi phục hoạt động bình thường sau sự cố cấp Region. Region dự phòng B hiện nhận toàn bộ thao tác ghi, trong khi Region ban đầu A đã hoạt động trở lại với dữ liệu cũ hơn. Bộ phận tài chính yêu cầu mọi giao dịch đã được chấp nhận tại B phải được giữ nguyên khi chuyển về.

Ứng dụng hỗ trợ một writer và có thể chấp nhận tạm dừng ghi trong thời gian ngắn theo kế hoạch. Bạn cần việc chuyển đổi dữ liệu và chuyển đổi lưu lượng nhất quán với nhau, bao gồm cả các client vẫn dùng địa chỉ được cache.

Đây là một bài tập khôi phục sau thảm họa giả định.

Các phương án và quyết định

Giữ B là nguồn dữ liệu có thẩm quyền cho tới khi A được đồng bộ và xác minh. Xem failback là một cuộc di chuyển có kiểm soát, không phải đảo ngược một lần sửa DNS.

Mô hình tư duy và luồng xử lý

Writer hiện tại nắm giữ dữ liệu chuẩn, bất kể Region nào từng là chính.

Writer B → dựng lại/sao chép sang A → tạm dừng ghi tại B → xác nhận đã bắt kịp → chuyển writer sang A → xác minh → chuyển lưu lượng

B phải từ chối các thao tác ghi từ client dùng thông tin cũ khi A trở thành nguồn có thẩm quyền.

Cơ chế cốt lõi

Khắc phục sai lệch hạ tầng, vai trò, thông tin bí mật và phiên bản ứng dụng của A trước khi chuyển đổi dữ liệu. Với Aurora Global Database, dùng topology và quy trình switchover được quản lý mà engine/phiên bản hỗ trợ. Các cấu hình RDS thông thường có thể cần dựng lại sao chép hoặc khôi phục rồi đồng bộ lại; không có API failback chung cho mọi trường hợp.

Giám sát độ trễ và đối soát các mã định danh giao dịch có ý nghĩa. Sau khi tạm dừng ghi, xác minh giao dịch cuối cùng được B chấp nhận đã có mặt ở A trước khi bật writer mới.

Xử lý riêng từng kho dữ liệu. Sao chép S3 có các quy tắc riêng về phiên bản, xóa và đối tượng đã tồn tại; cơ sở dữ liệu đã bắt kịp không chứng minh rằng mọi tài liệu đều đã có mặt. DynamoDB global tables có mô hình nhất quán và xung đột riêng thay vì hoạt động như một replica RDS có một writer.

Khi A đã chấp nhận các thao tác ghi mới, rollback về B còn dữ liệu cũ có thể làm mất những thao tác ghi đó. Xác định quy trình đồng bộ ngược và fencing trước khi chuyển đổi.

Kiểm chứng và khi nào cần đổi phương án

• Đối soát ID giao dịch cuối cùng, các tổng số và những điều kiện bất biến nghiệp vụ giữa các Region.
• Kiểm thử client dùng câu trả lời DNS cũ và xác nhận chúng không thể ghi vào B.
• Thiết lập lại khôi phục sau thảm họa từ A sang B và xác minh vẫn có thể thực hiện lần failover tiếp theo.

Nếu doanh nghiệp chấp nhận một khoảng bảo trì dài, khôi phục snapshot khi đã dừng ghi có thể đơn giản hơn. Nếu không thể tạm dừng ghi dù chỉ trong thời gian ngắn, cần chiến lược di chuyển và xử lý xung đột phức tạp hơn.

Điểm cần nhớ và tài liệu AWS

• Failback là di chuyển dữ liệu, không chỉ định tuyến lưu lượng.
• Chỉ writer hiện tại mới là nguồn có thẩm quyền.
• Fencing writer bảo vệ trước client dùng thông tin cũ và tình trạng split-brain.
• Mỗi dịch vụ dữ liệu cần các kiểm tra đồng bộ riêng.
• Cách rollback thay đổi khi writer mới đã chấp nhận giao dịch.

AWS: khôi phục toàn cầu với Aurora

Dịch vụ trong bài: Aurora · RDS · S3 · DynamoDB · Route 53

Biến các tác vụ sao lưu thành công thành một dịch vụ có thể khôi phục

Tình huống và yêu cầu

Bạn chịu trách nhiệm khôi phục một ứng dụng tài chính nội bộ. Trong một cuộc diễn tập giả định, mọi tác vụ sao lưu đều báo thành công, nhưng nhóm không thể khôi phục dịch vụ: vai trò khôi phục thiếu quyền giải mã và mạng đích chưa tồn tại.

Doanh nghiệp yêu cầu các điểm khôi phục hằng ngày, một bản sao nằm ngoài cả tài khoản lẫn Region của workload, và khôi phục dịch vụ trong vòng tám giờ. Bạn phải chứng minh toàn bộ quy trình khôi phục, bao gồm cả trường hợp không thể sử dụng tài khoản ban đầu.

Các phương án và quyết định

Sử dụng AWS Backup với phạm vi bao phủ rõ ràng và các bản sao khôi phục được cô lập, cùng với quy trình khôi phục hạ tầng và ứng dụng.

Mô hình tư duy và luồng xử lý

Một điểm khôi phục là một đầu vào cho quá trình khôi phục, không phải một dịch vụ đang chạy.

Workload được bảo vệ → sao lưu theo lịch → sao chép liên tài khoản/Region được hỗ trợ → kho khôi phục → tạo hạ tầng → khôi phục → kiểm chứng nghiệp vụ

Bước cuối cùng, chứ không phải trạng thái tác vụ sao lưu, quyết định bộ phận tài chính có thể làm việc trở lại hay không.

Cơ chế cốt lõi

Kiểm kê cơ sở dữ liệu, tệp, cấu hình và các thành phần phụ thuộc. Gán tài nguyên vào kế hoạch sao lưu thông qua các tag hoặc ID đã được rà soát, rồi phát hiện những phần chưa được bao phủ. Chọn thời gian lưu giữ và quy trình bảo đảm tính nhất quán ứng dụng theo workload, không áp dụng một quy tắc snapshot hằng ngày chung cho mọi trường hợp.

Xác minh khả năng hỗ trợ sao chép liên tài khoản và liên Region cho từng tài nguyên và cấu hình mã hóa. Việc một dịch vụ hỗ trợ đường sao chép nào đó không có nghĩa dịch vụ khác cũng hỗ trợ.

Bảo vệ quyền truy cập kho sao lưu và vòng đời khóa KMS trong tài khoản khôi phục. Nếu dùng Vault Lock, hãy hiểu chế độ đã chọn và thời gian gia hạn của chế độ compliance trước khi đưa ra cam kết lưu giữ không thể đảo ngược. Giữ lại các bản sao lưu đã mã hóa nhưng mất quyền truy cập khóa không bảo đảm bạn còn sử dụng được chúng.

Sử dụng chính sách sao lưu của tổ chức để phân phối cấu hình cơ sở, rồi xác minh việc chọn tài nguyên và các bản sao được bảo vệ thành công trong từng tài khoản. Với nhu cầu quản lý vòng đời riêng cho EBS, so sánh Data Lifecycle Manager với khả năng quản trị rộng hơn của AWS Backup thay vì vô tình cấu hình các lịch cạnh tranh nhau. Lập mô hình các thế hệ bản sao lưu được giữ lại, các bản sao, phí khôi phục và thời gian lưu giữ bất biến trước khi chọn một chính sách có vẻ rẻ; không bao giờ rút ngắn thời gian lưu giữ bắt buộc theo pháp luật để đáp ứng ngân sách lưu trữ.

Dùng infrastructure as code cho các điều kiện tiên quyết về mạng và bảo mật. Khôi phục dữ liệu, cung cấp thông tin bí mật, khởi động ứng dụng và kiểm chứng các bản ghi cùng giao dịch có ý nghĩa. Tính năng kiểm thử khôi phục của AWS Backup hỗ trợ các tài nguyên được hỗ trợ; những thành phần phụ thuộc khác vẫn cần diễn tập.

Kiểm chứng và khi nào cần đổi phương án

• Khôi phục chỉ bằng bản sao cô lập và thông tin xác thực khôi phục đã được phê duyệt.
• Đo toàn bộ khoảng thời gian tám giờ, bao gồm hạ tầng, khôi phục và xác minh.
• Kiểm tra dữ liệu bị thiếu, checksum hoặc đối soát bản ghi, và một thao tác tài chính xuyên suốt từ đầu đến cuối.

Nếu thời gian khôi phục đo được không thể nằm trong tám giờ, bổ sung năng lực dự phòng hoặc sao chép. Ngay cả khi đó vẫn giữ các bản sao lưu lịch sử: failover nhanh hơn và khôi phục sau hỏng dữ liệu logic là hai nhu cầu khác nhau.

Điểm cần nhớ và tài liệu AWS

• Hoàn thành sao lưu không đồng nghĩa với khôi phục ứng dụng.
• Sao chép có thể lan truyền hư hỏng logic.
• Khả năng hỗ trợ sao chép và mã hóa khác nhau theo loại tài nguyên.
• Khôi phục cần khóa, quyền và hạ tầng sử dụng được.
• Kiểm chứng hoạt động nghiệp vụ, không chỉ trạng thái tác vụ khôi phục.

AWS: AWS Backup

Dịch vụ trong bài: AWS Backup · KMS · Organizations

Duy trì toàn bộ ứng dụng khi một Availability Zone gặp sự cố

Tình huống và yêu cầu

Bạn duy trì một trang đặt chỗ với bốn máy chủ EC2, tất cả đều nằm trong một Availability Zone. Phiên người dùng nằm trên đĩa cục bộ, còn cơ sở dữ liệu và kết nối đi ra ngoài cũng phụ thuộc vào chính zone đó.

Doanh nghiệp muốn việc đặt chỗ tiếp tục sau khi một AZ gặp sự cố, nhưng chưa yêu cầu khôi phục sau thảm họa cấp Region. Bạn có thể giữ chỗ đủ năng lực tài nguyên ở một AZ khác. Thêm máy chủ chỉ hữu ích nếu người dùng, trạng thái và các thành phần phụ thuộc thực sự có thể sử dụng chúng sau sự cố.

Đây là một bài tập thiết kế giả định.

Các phương án và quyết định

Làm cho tầng web có thể thay thế được và mọi thành phần phụ thuộc bắt buộc đều sẵn sàng trên nhiều AZ. Tính sẵn sàng bị giới hạn bởi thành phần bắt buộc yếu nhất.

Mô hình tư duy và luồng xử lý

Một máy chủ khỏe mạnh cũng vô ích nếu kho phiên hoặc cơ sở dữ liệu của nó không sẵn sàng.

Trình duyệt → ALB → ứng dụng khỏe mạnh ở AZ A hoặc B → các dịch vụ phiên/dữ liệu dùng chung

Sau khi mất AZ A, đường xử lý còn lại vẫn phải có đủ năng lực, quyền truy cập trạng thái và các thành phần phụ thuộc hướng ra ngoài hoạt động được.

Cơ chế cốt lõi

Sử dụng ALB và nhóm Auto Scaling trên nhiều AZ với các kiểm tra tình trạng phù hợp cho target và việc thay thế instance. NLB là một lựa chọn cho các yêu cầu TCP/UDP phù hợp, không phải phương án thay thế luôn nhanh hơn cho bộ cân bằng tải hiểu HTTP.

Chuyển phiên sang một kho có tính sẵn sàng cao phù hợp hoặc dùng token phiên được thiết kế an toàn. Đưa các tệp tải lên cần lưu bền vững vào lưu trữ đối tượng thay vì tệp cục bộ trên instance. Cache không được trở thành bản sao bền vững duy nhất của các bản ghi quan trọng.

Chọn cấu hình RDS Multi-AZ phù hợp và kiểm thử việc client kết nối lại khi cơ sở dữ liệu failover. Cung cấp cho mỗi AZ một đường kết nối đi ra ngoài phù hợp để các instance còn hoạt động không phụ thuộc vào NAT gateway của zone đã gặp sự cố.

Cấp sẵn năng lực còn lại đủ cho tình huống sự cố thay vì mặc định các instance mới luôn khởi chạy đủ nhanh. Tránh các kiểm tra tình trạng loại bỏ mọi instance ứng dụng chỉ vì một thành phần phụ thuộc dùng chung chậm lại trong thời gian ngắn.

Kiểm chứng và khi nào cần đổi phương án

• Loại bỏ năng lực ứng dụng của một zone trong một cuộc diễn tập có kiểm soát và kiểm tra giao dịch thành công cùng tính liên tục của phiên.
• Diễn tập failover cơ sở dữ liệu và kho phiên, không chỉ định tuyến của bộ cân bằng tải.
• Kiểm tra năng lực điện toán và kết nối đi ra ngoài còn lại dưới tải cao điểm.

Yêu cầu chịu được sự cố cấp Region cần một thiết kế dữ liệu và khôi phục đa Region riêng. Đừng thêm độ phức tạp đó chỉ vì “nhiều Region hơn” nghe có vẻ sẵn sàng hơn.

Điểm cần nhớ và tài liệu AWS

• Nhiều instance hơn trong một AZ không tạo ra khả năng chịu lỗi AZ.
• Điện toán phi trạng thái đơn giản hóa việc thay thế và phân phối lại lưu lượng.
• Mọi thành phần phụ thuộc bắt buộc đều góp phần quyết định tính sẵn sàng.
• Năng lực cho failover phải có sẵn khi cần.
• Multi-AZ và đa Region giải quyết các phạm vi sự cố khác nhau.

AWS: trụ cột Độ tin cậy

Dịch vụ trong bài: ALB · Auto Scaling · RDS · ElastiCache

Kiểm thử xem thiết kế khôi phục quy trình thanh toán có thực sự hoạt động

Tình huống và yêu cầu

Bạn tiếp quản một nền tảng thanh toán có sơ đồ bao gồm các dịch vụ Multi-AZ và bản sao lưu, nhưng chưa ai diễn tập sự cố. Doanh nghiệp có mục tiêu tính sẵn sàng 99.9% và mục tiêu khôi phục cấp Region riêng là một giờ với tối đa mười lăm phút cập nhật bị mất.

Bạn phải biến những khẳng định đó thành bằng chứng mà không gây gián đoạn production chưa được phê duyệt. Nhóm cần các thử nghiệm xác định rõ, người chịu trách nhiệm, điều kiện dừng và quy trình khôi phục, không phải chèn lỗi ngẫu nhiên.

Đây là một bài tập lập kế hoạch giả định; không khẳng định có bất kỳ kết quả thử nghiệm nào.

Các phương án và quyết định

Tiến hành các game day có kiểm soát, bắt đầu trong một môi trường đại diện. Thử nghiệm trên production cần được cho phép rõ ràng riêng và có giới hạn tác động.

Mô hình tư duy và luồng xử lý

Một thử nghiệm kiểm tra một khẳng định cụ thể dưới một sự cố cụ thể, không phải “AWS có đáng tin cậy hay không”.

Giả thuyết → đo đường cơ sở → gây lỗi trong giới hạn → quan sát giao dịch và cảnh báo → dừng/khôi phục → so sánh với tiêu chí chấp nhận

Một khẳng định phù hợp có thể là mất một node ứng dụng không gây ra khoảng thời gian thanh toán thất bại dài đến mức không thể chấp nhận.

Cơ chế cốt lõi

Xác định trạng thái ổn định bằng tỷ lệ thành công nghiệp vụ cùng với độ trễ, lỗi và năng lực. Một tiến trình còn chạy không phải bằng chứng rằng giao dịch mua hàng có thể hoàn tất. Quy định độ lệch cho phép và khoảng thời gian quan sát trước khi chèn lỗi.

AWS Fault Injection Service hỗ trợ một số hành động gây lỗi nhất định với vai trò thực thi được giới hạn phạm vi và cảnh báo dừng CloudWatch. Hiểu hành vi của từng hành động: dừng một thử nghiệm không nhất thiết đảo ngược mọi thay đổi hay khôi phục mọi tài nguyên đã mất.

Dùng Resilience Hub để đánh giá các tài nguyên ứng dụng được hỗ trợ theo các mục tiêu khôi phục đã khai báo và xác định khoảng trống về khả năng chống chịu. Một bản đánh giá và các kiểm thử đề xuất là bằng chứng phục vụ lập kế hoạch, không phải bảo đảm dựa trên đo lường rằng ứng dụng đáp ứng RTO/RPO. Chuyển các phát hiện thành runbook khôi phục và các cuộc diễn tập có người chịu trách nhiệm.

Kiểm thử riêng các nhóm sự cố khác nhau: mất instance, lỗi thành phần phụ thuộc, khôi phục bản sao lưu, failover cấp Region và failback. Chỉ một tỷ lệ phần trăm tính sẵn sàng không quy định hành vi chấp nhận được cho từng sự kiện; hãy xác định rõ tiêu chí chấp nhận của thử nghiệm.

Đo RTO từ khi gián đoạn tới khi dịch vụ nghiệp vụ được khôi phục, bao gồm cả các quyết định của con người. Đo RPO từ mốc dữ liệu được khôi phục, không phải thời điểm tác vụ sao lưu bắt đầu.

Kiểm chứng và khi nào cần đổi phương án

• Xác nhận cơ chế chọn mục tiêu không thể bao gồm tài nguyên ngoài phạm vi được phê duyệt.
• Diễn tập cảnh báo dừng và việc dọn dẹp trước khi mở rộng tác động.
• Ghi lại các bước thủ công, quyền còn thiếu, thời gian khôi phục và sai lệch dữ liệu; sửa chữa và chạy lại các thử nghiệm có giả thuyết không đạt.

Nếu không thể gây lỗi an toàn cho một thành phần phụ thuộc, hãy dùng một thành phần thay thế có tính đại diện hoặc thử nghiệm hẹp hơn và nêu rõ giới hạn của bằng chứng. Một lần rà soát Well-Architected ghi nhận rủi ro và cải tiến; bản thân nó không chứng nhận khả năng chống chịu.

Điểm cần nhớ và tài liệu AWS

• Bắt đầu bằng một khẳng định về khôi phục có thể bị bác bỏ qua kiểm chứng.
• Đo công việc mà người dùng nhận thấy, không chỉ trạng thái hạ tầng.
• Điều kiện dừng và rollback là các cơ chế khác nhau.
• Các phạm vi sự cố khác nhau đòi hỏi những cuộc diễn tập khác nhau.
• Kiến trúc chưa được kiểm thử vẫn là giả thuyết, không phải khả năng khôi phục đã được chứng minh.

AWS: Fault Injection Service

Dịch vụ trong bài: Fault Injection Service · Resilience Hub · CloudWatch · AWS Backup · Well-Architected Tool

Đưa các môi trường bị lệch cấu hình vào quản lý phiên bản mà không thay thế dữ liệu đang sử dụng

Tình huống và yêu cầu

Bạn duy trì các môi trường staging và production vốn ban đầu giống nhau nhưng đã khác biệt do thay đổi qua console. Cấu hình đã kiểm thử trên staging không còn dự đoán được hành vi của production.

Nhóm muốn các thay đổi hạ tầng được review, có thể lặp lại và nhìn thấy được độ lệch cấu hình. Cơ sở dữ liệu production không được vô tình bị thay thế khi ai đó thay đổi thuộc tính template. Vẫn phải cho phép thay đổi khẩn cấp qua console bằng quyền truy cập được kiểm soát, sau đó đồng bộ lại với mã nguồn.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Áp dụng template CloudFormation có quản lý phiên bản cùng với review change set. Import tài nguyên hiện có khi được hỗ trợ thay vì tạo bản trùng lặp rồi bỏ lại tài nguyên đang sử dụng.

Mô hình tư duy và luồng xử lý

Infrastructure as code mô tả trạng thái tài nguyên mong muốn; nó không tự động di chuyển dữ liệu bên trong tài nguyên.

Template đã review → change set → review việc thay thế/xóa → cập nhật stack → kiểm tra độ lệch và ứng dụng

Một đề xuất thay thế là quyết định di chuyển dữ liệu khi tài nguyên đó lưu giữ trạng thái.

Cơ chế cốt lõi

CDK biểu diễn hạ tầng bằng ngôn ngữ lập trình và tổng hợp thành template CloudFormation; các construct của nó không bỏ qua hành vi thay thế của CloudFormation. Dùng CDK aspect hoặc xác thực template để kiểm tra sớm, và CloudFormation Hooks ở nơi được hỗ trợ để thực thi chính sách tại thời điểm cấp phát. Config phát hiện tính tuân thủ và độ lệch của trạng thái đã triển khai; phát hiện sau cấp phát không giống với từ chối một thay đổi rủi ro trước khi nó chạy.

Dùng một template được kiểm soát với các tham số môi trường được chủ đích xác định. Tham chiếu secret qua cơ chế được hỗ trợ thay vì ghi cứng trong mã nguồn.

Review hành vi thay thế và xóa trước khi thực thi. Chủ động chọn DeletionPolicy và UpdateReplacePolicy cho tài nguyên có trạng thái, đồng thời giữ các bản sao lưu sử dụng được. Retain giữ lại tài nguyên trong các trường hợp vòng đời liên quan; nó không sao chép dữ liệu sang tài nguyên thay thế hay bảo đảm tài nguyên đó tiếp tục được stack quản lý.

Phát hiện độ lệch bao phủ các tài nguyên và thuộc tính được hỗ trợ, không phải mọi khác biệt cấu hình. Bổ sung AWS Config hoặc các kiểm tra tập trung khi cần. Sau một thay đổi bằng quyền truy cập khẩn cấp, hãy cập nhật mã nguồn hoặc chủ động hoàn tác thay đổi để lần triển khai tiếp theo không gây bất ngờ cho người vận hành.

Termination protection ngăn xóa stack, không ngăn mọi cập nhật tài nguyên gây hại. Sử dụng stack policy và chốt review phù hợp. Rollback stack cũng không thể hoàn tác thay đổi dữ liệu ứng dụng trong mọi trường hợp.

Kiểm chứng và khi nào cần đổi phương án

• Tạo một độ lệch thử nghiệm an toàn và xác minh cơ chế phát hiện đã chọn nhận ra nó.
• Xem trước một thay đổi thuộc tính gây thay thế và xác nhận nó không thể diễn ra mà không bị chú ý.
• Diễn tập cập nhật thất bại và khôi phục cho một tài nguyên có trạng thái mang tính đại diện.

Một tác vụ vận hành một lần có thể phù hợp với script API phạm vi hẹp. Hạ tầng dùng chung lâu dài hưởng lợi từ trạng thái mong muốn, quyền sở hữu và quản lý vòng đời rõ ràng hơn là một chuỗi script ngày càng dài.

Điểm cần nhớ và tài liệu AWS

• Quản lý trạng thái mong muốn không phải di chuyển dữ liệu.
• Change set phơi bày rủi ro nhưng vẫn cần được diễn giải.
• Chính sách giữ lại không tự động làm cho việc thay thế trở nên an toàn.
• Phát hiện độ lệch có giới hạn về phạm vi bao phủ.
• Thay đổi khẩn cấp phải được đồng bộ lại với cấu hình đã khai báo.

AWS: Change set của CloudFormation

Dịch vụ trong bài: CloudFormation · CDK · Config · Secrets Manager

Đưa artifact đã vượt qua staging lên production thay vì build lại

Tình huống và yêu cầu

Bạn phụ trách phát hành cho một ứng dụng chạy trong container. Lập trình viên build trên máy cá nhân, staging build lại, rồi production lại build từ cùng commit. Vì vậy, một bản cập nhật dependency có thể làm thay đổi binary trên production sau khi staging đã vượt qua kiểm thử.

Người quản lý phát hành cần truy vết được về commit đã được review, có phê duyệt trước khi lên production và rollback đáng tin cậy. Không được nhúng secret vào artifact, và hệ thống build không được nhận quyền quản trị production.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Build một lần, sau đó đưa chính artifact đó lên các môi trường tiếp theo. Giá trị riêng của từng môi trường thuộc về cấu hình triển khai/runtime, không phải một lần build binary mới.

Mô hình tư duy và luồng xử lý

Một bản phát hành là artifact có định danh cộng với cấu hình, không chỉ là tên nhánh Git.

Commit đã review → CodeBuild → digest image trên ECR → kiểm chứng trên staging → phê duyệt → production dùng cùng digest

CodePipeline điều phối các giai đoạn; nó không làm cho đầu ra được build lại độc lập trở nên giống nhau.

Cơ chế cốt lõi

Sử dụng lockfile và các nguồn dependency được kiểm soát. ECR lưu trữ container image; việc phân giải dependency vẫn cần phiên bản được ghim và nguồn package được kiểm soát. Ghi lại commit ID, build ID và image digest làm metadata của bản phát hành.

Tham chiếu image digest thay vì chỉ dựa vào tag có thể thay đổi. Truy xuất secret lúc runtime thông qua danh tính của workload. Log build, cache và các lớp image không được lưu giữ giá trị secret vô tình được đưa vào trong quá trình biên dịch.

Tách riêng role build và role triển khai. Role triển khai cross-account chỉ nên sửa đổi service hoặc stack được chỉ định, không quản trị toàn bộ tài khoản production. Bổ sung các bước review, kiểm thử và chốt kiểm soát bảo mật bắt buộc trước khi đưa artifact lên môi trường tiếp theo.

Chặn hoặc cho phép đưa artifact lên môi trường tiếp theo dựa trên phát hiện lỗ hổng image theo chính sách mức độ nghiêm trọng/ngoại lệ rõ ràng. Tính năng quét nâng cao của ECR sử dụng Inspector; kết quả quét không phải chữ ký. Ký các artifact đã được phê duyệt bằng tích hợp ký được hỗ trợ và xác minh chữ ký/nguồn gốc khi triển khai, thay vì chỉ đính kèm metadata. Khi đưa artifact sang tài khoản hoặc Region khác, cấu hình rõ ràng quyền truy cập bucket artifact/KMS và quan hệ tin cậy của role triển khai với phạm vi hẹp; role build không được thừa hưởng quyền production không giới hạn.

Không để quy tắc lifecycle của ECR xóa image digest đang chạy hoặc dùng để rollback. Giữ lại các artifact đã biết là hoạt động tốt và đủ thông tin nguồn gốc để điều tra. Kết quả quét không có lỗ hổng chỉ có giá trị tại thời điểm quét; lỗ hổng mới có thể được phát hiện sau đó. Rollback cũng đòi hỏi tính tương thích của cơ sở dữ liệu và cấu hình.

Kiểm chứng và khi nào cần đổi phương án

• So sánh digest đã triển khai trên staging và production.
• Xác nhận build thất bại hoặc phê duyệt bị từ chối không thể trở thành bản phát hành.
• Diễn tập rollback với schema hiện tại và kiểm tra artifact/log để tìm rò rỉ secret.

Các kiến trúc bộ xử lý khác nhau có thể cần artifact riêng cho từng nền tảng hoặc image đa kiến trúc đã được review. Giữ định danh và kiểm chứng riêng cho từng nền tảng thay vì coi một binary có thể chạy trên các runtime không tương thích.

Điểm cần nhớ và tài liệu AWS

• Commit nguồn giống nhau không bảo đảm binary giống nhau.
• Digest xác định nội dung image; tag có thể được chuyển sang nội dung khác.
• Kho package và kho container đảm nhiệm vai trò khác nhau.
• Quyền build không nên đồng nghĩa với quyền quản trị production.
• Rollback artifact vẫn phụ thuộc vào tính tương thích của trạng thái.

AWS: Các khái niệm CodePipeline

Dịch vụ trong bài: CodePipeline · CodeBuild · ECR · Inspector · AWS Signer

Phát hành thay đổi checkout mà không biến rollback thành sự cố cơ sở dữ liệu

Tình huống và yêu cầu

Bạn triển khai một dịch vụ checkout trên ECS. Một bản phát hành lỗi trước đây đã ảnh hưởng đến toàn bộ khách hàng cùng lúc, và việc chuyển lại image cũ thất bại vì bản phát hành mới đã xóa một cột trong cơ sở dữ liệu.

Doanh nghiệp muốn phạm vi tiếp xúc ban đầu nhỏ, các chốt kiểm soát phát hành đo lường được và khả năng rollback lưu lượng nhanh chóng. Doanh nghiệp chấp nhận chi phí cho hai task set trong khi triển khai. Cả hai phiên bản ứng dụng phải duy trì tương thích với cơ sở dữ liệu dùng chung trong suốt khoảng thời gian cho phép rollback.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Sử dụng cơ chế chuyển lưu lượng blue/green được ECS hỗ trợ cùng với alarm, và coi tính tương thích schema là một yêu cầu phát hành độc lập.

Mô hình tư duy và luồng xử lý

Blue/green thay đổi nơi xử lý request; nó không đảo ngược những gì request đã ghi.

Artifact đã build → task set green → một phần nhỏ lưu lượng ALB → chỉ số và thời gian theo dõi ổn định → toàn bộ lưu lượng hoặc quay lại blue

Cả hai phiên bản đọc cùng một trạng thái đang thay đổi trong quá trình chuyển đổi.

Cơ chế cốt lõi

Tạo task set green và target group của nó bằng cấu hình CodeDeploy được hỗ trợ. Theo dõi lỗi ứng dụng, độ trễ và thất bại nghiệp vụ bằng CloudWatch alarm. Canary cần đủ request mang tính đại diện để có ý nghĩa, không chỉ đơn thuần là một khoảng thời gian ngắn.

Sử dụng thay đổi cơ sở dữ liệu theo expand-contract: thêm cấu trúc tương thích, triển khai code chấp nhận cả hai dạng cấu trúc, backfill an toàn, rồi chỉ xóa cấu trúc cũ sau khi khoảng thời gian cho phép rollback kết thúc. Không thể hoàn tác migration mang tính phá hủy chỉ bằng cách chọn image cũ hơn.

Giữ blue hoạt động tốt cho đến khi hoàn tất kiểm chứng và thời gian theo dõi ổn định. Session và message phải tương thích giữa các phiên bản; trạng thái cục bộ trong task có thể khiến rollback lưu lượng không hiệu quả.

Xác định alarm thực sự làm gì và xác minh hành vi rollback của cơ chế triển khai đã chọn. Đừng cho rằng mọi dịch vụ điện toán AWS đều hỗ trợ cùng một cách chuyển lưu lượng.

Kiểm chứng và khi nào cần đổi phương án

• Triển khai một phiên bản thử nghiệm cố ý có lỗi và xác nhận lưu lượng quay về blue.
• Thực hiện các thao tác ghi mới, rồi xác minh phiên bản cũ vẫn đọc và xử lý được chúng.
• Kiểm thử tính liên tục của session và các message bị trễ khi đi qua ranh giới phiên bản.

Triển khai rolling có thể đủ cho dịch vụ stateless ít rủi ro hơn với năng lực chạy song song hạn chế. Nếu thay đổi schema không tương thích, hãy thiết kế lại migration trước khi cam kết rollback nhanh dưới bất kỳ chiến lược triển khai nào.

Điểm cần nhớ và tài liệu AWS

• Rollback lưu lượng không phải rollback dữ liệu.
• Quyết định canary cần bằng chứng mang tính đại diện.
• Expand-contract duy trì tính tương thích khi vận hành nhiều phiên bản cùng lúc.
• Giữ môi trường cũ sử dụng được cho đến khi hết khoảng thời gian cho phép rollback.
• Chiến lược triển khai và migration trạng thái phải được thiết kế cùng nhau.

AWS: Triển khai blue/green trên ECS

Dịch vụ trong bài: CodeDeploy · ALB · CloudWatch · ECS

Chỉ phát hành trợ lý AI sau khi vượt qua kiểm tra chất lượng và an toàn

Tình huống và yêu cầu

Một nhóm muốn thay thế mô hình và cấu hình truy xuất của trợ lý. Unit test đều đạt, nhưng một bản phát hành trước đó đã đưa ra câu trả lời tự tin từ tài liệu lỗi thời. Bản phát hành mới phải duy trì khả năng hoàn thành tác vụ và cách ly tenant, đồng thời đáp ứng mục tiêu độ trễ và chi phí. Giám sát production phải phát hiện suy giảm mà không lưu mọi prompt riêng tư.

Các phương án và quyết định

Coi mô hình, prompt, thiết lập truy xuất, quyền công cụ và chính sách an toàn là một bản phát hành có quản lý phiên bản. Dùng khả năng đánh giá Bedrock được hỗ trợ cùng baseline do con người review và kiểm thử phân quyền mang tính xác định, rồi triển khai canary trước khi đưa vào sử dụng rộng rãi.

Mô hình tư duy và luồng xử lý

Một lần gọi thành công không phải một câu trả lời thành công, và điểm chất lượng câu trả lời không phải kiểm thử kiểm soát truy cập.

Bản phát hành ứng viên → bộ đánh giá cố định → ngưỡng chất lượng/an toàn/chi phí → canary được phê duyệt → SLI production → mở rộng triển khai hoặc rollback

Cơ chế cốt lõi

Xây dựng các trường hợp đại diện cho câu hỏi có thể trả lời, thiếu bằng chứng, bằng chứng mâu thuẫn, hành động bị cấm, prompt injection và truy cập cross-tenant. Kiểm soát kết quả kỳ vọng và dữ liệu đánh giá; không tinh chỉnh chỉ dựa trên bộ dữ liệu dùng làm chốt phát hành.

Tách riêng mức liên quan của truy xuất, mức độ bám sát bằng chứng, khả năng hoàn thành tác vụ, hành vi từ chối, tính đúng đắn khi dùng công cụ và độ trễ đầu cuối. Bộ chấm tự động hoặc dựa trên mô hình có thể mở rộng quy mô review, nhưng hãy hiệu chuẩn chúng với đánh giá của con người và kiểm tra các bất đồng. Điểm trung bình cao không thể bù cho một hành động trái phép nghiêm trọng.

Ghim các artifact có thể triển khai và ghi lại phiên bản đã kiểm thử. Việc đưa bản phát hành lên môi trường tiếp theo không được âm thầm thay đổi mô hình, snapshot chỉ mục hay chính sách công cụ. Xác định tính tương thích khi rollback cho trạng thái session/bộ nhớ và giữ lại cấu hình đã biết là tốt.

Giám sát tỷ lệ request thành công, độ trễ, việc bị giới hạn tốc độ, mức sử dụng token/chi phí, thất bại truy xuất, lỗi công cụ và các chỉ báo chất lượng/an toàn được chọn. Với mô hình SageMaker tùy chỉnh, các workflow Model Monitor được hỗ trợ xử lý độ lệch mô hình/dữ liệu; trợ lý còn cần giám sát riêng cho agent/công cụ và truy xuất. Chỉ thu thập mẫu chẩn đoán đã được phê duyệt với kiểm soát truy cập và lưu giữ.

Kiểm chứng và khi nào cần đổi phương án

• Cố ý đưa vào một thay đổi làm giảm chất lượng truy xuất và xác nhận chốt kiểm soát chặn nó.
• Xác minh một trường hợp kiểm thử phân quyền thất bại sẽ chặn phát hành ngay cả khi chất lượng trung bình cải thiện.
• Kích hoạt rollback canary và xác minh toàn bộ cấu hình trước đó được khôi phục.

Một bộ phân loại mang tính xác định có thể dùng chỉ số offline dựa trên nhãn thay vì bộ chấm bằng mô hình ngôn ngữ. Ứng dụng có hệ quả nghiêm trọng có thể cần phê duyệt của con người cho cả việc triển khai lẫn từng quyết định riêng lẻ.

Điểm cần nhớ và tài liệu AWS

• Quản lý phiên bản toàn bộ ứng dụng AI, không chỉ tên mô hình.
• Đánh giá chất lượng không thay thế kiểm thử bảo mật mang tính xác định.
• Giám sát kết quả của người dùng và hành vi mô hình/công cụ sau phát hành.

AWS: Đánh giá Bedrock · AWS: CI/CD và khả năng quan sát trong SAP-C03

Dịch vụ trong bài: CodePipeline · Bedrock Evaluations · Bedrock · SageMaker Model Monitor · CloudWatch

Tìm nguyên nhân request checkout chậm khi CPU máy chủ vẫn có vẻ bình thường

Tình huống và yêu cầu

Bạn là kỹ sư độ tin cậy cho một cửa hàng trực tuyến. Khách hàng báo checkout chậm, nhưng CPU trung bình vẫn quanh 30%. Mục tiêu nội bộ là 99.9% lượt checkout thành công và độ trễ p95 dưới 800 ms; SLA bên ngoài cũng đi kèm hệ quả tài chính.

Bạn cần phân biệt thời gian tiêu tốn trong code ứng dụng, cơ sở dữ liệu và nhà cung cấp thanh toán. Giám sát phải hỗ trợ chẩn đoán và cảnh báo có thể hành động mà không thu thập mật khẩu, chi tiết thanh toán hay lượng log ít giá trị không giới hạn.

Đây là bài tập giả định; các chỉ số và mục tiêu là đầu vào giả định.

Các phương án và quyết định

Bổ sung instrumentation cho hành trình checkout, sau đó liên kết triệu chứng tổng hợp với bằng chứng ở cấp request. Chỉ thêm công cụ khi chúng lấp một khoảng trống thực sự.

Mô hình tư duy và luồng xử lý

Metric cho bạn biết có vấn đề; trace định vị độ trễ; log giải thích sự kiện liên quan.

Request checkout có trace ID → span ứng dụng → span cơ sở dữ liệu → span nhà cung cấp thanh toán → metric kết quả và log có cấu trúc

CPU thấp không loại trừ khả năng tiến trình đang chờ một dependency chậm.

Cơ chế cốt lõi

Định nghĩa chỉ báo mức dịch vụ (SLI), bao gồm request nào được tính và điều gì được coi là thành công. SLO là mục tiêu nội bộ cho phép đo đó; SLA là cam kết bên ngoài. Chúng có liên quan nhưng không thể thay thế cho nhau.

Theo dõi tỷ lệ lỗi và các phân vị độ trễ thay vì chỉ giá trị trung bình. Log có cấu trúc nên chứa request/trace ID, kết quả và thời gian mà không chứa payload nhạy cảm. Instrumentation OpenTelemetry có thể xuất trace sang X-Ray hoặc backend được chọn.

Cảnh báo khi có tác động kéo dài đến người dùng hoặc tiêu hao error budget, với người chịu trách nhiệm cụ thể và runbook. Phân tích theo các chiều có ý nghĩa như bản phát hành hoặc Region, nhưng tránh dùng ID khách hàng có số lượng không giới hạn làm chiều metric.

Với ECS/EKS, Container Insights bổ sung dữ liệu telemetry của task/pod/node nhưng vẫn cần trace request và SLI nghiệp vụ. AWS Distro for OpenTelemetry cung cấp các thành phần instrumentation/thu thập được hỗ trợ. Application Signals có thể giúp biểu diễn chỉ báo dịch vụ và SLO; cả dashboard lẫn việc cài agent đều không tự động xác định đúng mẫu số nghiệp vụ.

Dùng CloudWatch RUM cho trải nghiệm trình duyệt thực tế với sự đồng ý và tối thiểu hóa dữ liệu, và Synthetics cho các phép thăm dò có thể lặp lại. Sử dụng kiểm tra tổng hợp không tạo giao dịch tài chính thật. Nếu hệ thống đã dùng Prometheus, Prometheus được quản lý và Grafana có thể phù hợp; tự việc đưa thêm một hệ thống dashboard không phải là cải thiện khả năng quan sát.

Lọc sự kiện không cần thiết trước khi nạp nếu được hỗ trợ, tổng hợp metric, và đặt thời gian lưu giữ/lớp log theo yêu cầu truy vấn và tuân thủ. Tính chung chi phí nạp, lưu trữ, truy vấn, custom metric và trace. Loại bỏ payload debug có thể tiết kiệm tiền; xóa bằng chứng kiểm toán bắt buộc theo pháp luật không phải tối ưu chi phí chấp nhận được.

Kiểm chứng và khi nào cần đổi phương án

• Chèn độ trễ thanh toán có kiểm soát và xác minh trace xác định đúng span đó, đồng thời cảnh báo đến được nhóm chịu trách nhiệm.
• Kiểm tra rằng các thất bại vẫn được nhìn thấy với chính sách lấy mẫu đã chọn.
• Đo chi phí hiệu năng của instrumentation và kiểm tra log để tìm dữ liệu nhạy cảm.

Với dịch vụ đơn giản chỉ có một tiến trình, bộ metric/log nhỏ hơn có thể đủ. Distributed tracing trở nên có giá trị khi độ trễ đi qua các ranh giới mà log cục bộ không thể giải thích đáng tin cậy.

Điểm cần nhớ và tài liệu AWS

• Chỉ số hạ tầng tốt không chứng minh hành trình người dùng tốt.
• Phân vị bộc lộ phần đuôi có độ trễ cao bị giá trị trung bình che khuất.
• Correlation ID liên kết những bằng chứng vốn tách rời.
• Lấy mẫu có thể bỏ sót từng thất bại riêng lẻ.
• Cảnh báo cần người chịu trách nhiệm và cách ứng phó, không chỉ một ngưỡng.

AWS: CloudWatch

Dịch vụ trong bài: CloudWatch · X-Ray · ADOT · Managed Service for Prometheus · Managed Grafana

Vá một nhóm EC2 hỗn hợp mà không khởi động lại toàn bộ dịch vụ cùng lúc

Tình huống và yêu cầu

Bạn vận hành hàng trăm EC2 instance cho một công ty đặt chỗ. Bộ phận bảo mật đã xác định các lỗ hổng cần được khắc phục trong thời hạn dựa trên rủi ro. Các node web stateless có thể thay thế, nhưng một số máy chủ legacy vẫn cần bảo trì tại chỗ.

Bộ phận vận hành phải duy trì năng lực phục vụ trong khi khởi động lại và ghi nhận máy nào tuân thủ. Không chấp nhận mở SSH ra internet hay áp dụng một bản nâng cấp chưa kiểm thử lên toàn bộ nhóm máy.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Dùng Systems Manager để vá legacy có kiểm soát và image được build lại cho các node web có thể thay thế. Ưu tiên theo mức độ phơi nhiễm và khả năng bị khai thác, không chỉ theo số lượng lỗ hổng được báo cáo.

Mô hình tư duy và luồng xử lý

Vá nguồn triển khai khi có thể; chỉ vá từng máy khi việc thay thế chưa khả thi.

Stateless: image đã cập nhật → canary → phiên bản launch template → instance refresh có biện pháp bảo vệ
Legacy: patch baseline → quét → đợt bảo trì → khởi động lại → xác minh ứng dụng

Cả hai hướng đều cần cách dừng trước đợt tiếp theo.

Cơ chế cốt lõi

Chuẩn bị SSM Agent, quyền của instance và kết nối đến các endpoint quản lý cần thiết. Sử dụng Session Manager để quản trị có cấp quyền khi phù hợp thay vì mở SSH đầu vào.

Với việc vá tại chỗ, chọn baseline và nhóm theo hệ điều hành và workload. Đặt ngưỡng đồng thời và ngưỡng lỗi, rút lưu lượng khỏi máy, rồi xác nhận năng lực còn lại trước khi khởi động lại. Ngoài quy tắc phê duyệt của baseline, vẫn cần cân nhắc tính sẵn có của package và tính tương thích ứng dụng.

Với máy stateless, Image Builder có thể tạo image đã kiểm thử. Cập nhật launch template và thay thế instance dần dần. Image rollback có thể khôi phục dịch vụ nhưng cũng khôi phục cả lỗ hổng; hãy coi đó là biện pháp khoanh vùng tạm thời kèm kế hoạch xử lý tiếp theo.

Máy chủ legacy cần quy trình sao lưu và khôi phục nhất quán với ứng dụng. Chỉ một snapshot không phải lúc nào cũng đủ cho mọi ứng dụng có trạng thái.

Kiểm chứng và khi nào cần đổi phương án

• Vá một máy canary và xác minh giao dịch, log cùng tình trạng sau khởi động lại trước khi mở rộng.
• Quét lại lỗ hổng và tính tuân thủ; chỉ lệnh chạy thành công là chưa đủ.
• Diễn tập một đợt thất bại và xác minh các ngưỡng giúp duy trì năng lực không bị ảnh hưởng.

Dịch vụ được quản lý có thể loại bỏ một số nhiệm vụ bảo trì máy chủ, nhưng thư viện ứng dụng, container image, quyền và cấu hình vẫn thuộc trách nhiệm của khách hàng. Migration là quyết định riêng, không phải lối tắt để né nghĩa vụ vá khẩn cấp.

Điểm cần nhớ và tài liệu AWS

• Tự động hóa không có giới hạn triển khai có thể lan truyền lỗi nhanh hơn.
• Thay thế bất biến phù hợp với workload có thể thay thế.
• Bảo trì tại chỗ cần lập kế hoạch năng lực và khôi phục.
• Vá thành công bao gồm sức khỏe ứng dụng và việc xác minh.
• Rollback bản vá có thể khôi phục mức phơi nhiễm ban đầu.

AWS: Systems Manager Patch Manager

Dịch vụ trong bài: Systems Manager · Inspector · EC2 Image Builder

Triển khai feature flag mà không build lại ứng dụng

Tình huống và yêu cầu

Bạn phụ trách một dịch vụ gợi ý. Bộ phận sản phẩm muốn bật hành vi xếp hạng mới cho một số nhóm khách hàng được chọn, rồi mở rộng nếu độ trễ và mức độ tương tác vẫn tốt. Hiện tại, thay đổi một flag đòi hỏi build lại image.

Bộ phận vận hành cần xác thực, triển khai dần và đảo ngược nhanh mà không cần triển khai code. Cấu hình thông thường không phải secret; mật khẩu phải giữ quy trình lưu trữ và luân chuyển riêng.

Đây là bài tập thiết kế giả định.

Các phương án và quyết định

Dùng AppConfig cho cấu hình được triển khai và feature flag. Giữ secret trong Secrets Manager thay vì trộn vòng đời truy cập và luân chuyển của chúng vào thiết lập thông thường.

Mô hình tư duy và luồng xử lý

Cấu hình là một bản phát hành có payload nhỏ hơn, không phải chỉnh sửa không có rủi ro.

Cấu hình đề xuất → bộ xác thực → triển khai theo giai đoạn → client làm mới/cache → chỉ số hành vi → tiếp tục hoặc rollback

Một giá trị đúng cú pháp vẫn có thể gây ra hành vi ứng dụng có hại.

Cơ chế cốt lõi

Định nghĩa kiểu, khoảng giá trị và tổ hợp được phép thông qua bộ xác thực được hỗ trợ và kiểm tra trong ứng dụng. Cấu hình cách triển khai dần và hành vi CloudWatch alarm trước khi áp dụng rộng rãi cấu hình mới.

Dùng AppConfig Agent hoặc tích hợp client được hỗ trợ có cache. Đừng khiến mọi request người dùng phụ thuộc vào một lệnh gọi API cấu hình mới. Xác định giá trị gần nhất đã biết là tốt và hành vi khi không truy xuất được cập nhật.

Cấu hình đến các tiến trình theo thời gian; hoàn tất triển khai không có nghĩa mọi tiến trình đều thay đổi trong cùng một mili giây. Cả phiên bản cũ và mới phải duy trì an toàn trong quá trình triển khai.

Triển khai cấu hình theo tỷ lệ phần trăm không tự động đồng nghĩa với nhắm chọn khách hàng một cách xác định. Định nghĩa rõ chiến lược đánh giá nhóm người dùng để khách hàng nhận được hành vi ổn định. Chỉ định người phụ trách và ngày loại bỏ cho flag để tránh độ phức tạp tồn tại vĩnh viễn.

Kiểm chứng và khi nào cần đổi phương án

• Gửi cấu hình không hợp lệ và xác minh nó bị từ chối trước khi sử dụng.
• Triển khai giá trị thử nghiệm hợp lệ nhưng có hại và xác nhận alarm dừng hoặc rollback đợt triển khai.
• Ngắt khả năng truy xuất cấu hình của một client và xác minh hành vi an toàn khi dùng cache.

Một tham số ít thay đổi, ít rủi ro có thể chỉ cần Parameter Store. Thay đổi đòi hỏi hành vi thực thi mới vẫn cần phát hành code. Hoàn tác cấu hình cũng không thể hoàn tác các giao dịch đã thực hiện với giá trị sai.

Điểm cần nhớ và tài liệu AWS

• Thay đổi cấu hình cần xác thực và kiểm soát triển khai.
• Schema hợp lệ không chứng minh an toàn vận hành.
• Client cần cache an toàn và hành vi khi cập nhật thất bại.
• Triển khai trên nhóm máy và nhắm chọn khách hàng là hai quyết định khác nhau.
• Rollback flag không đảo ngược tác động phụ đã hoàn tất.

AWS: AppConfig

Dịch vụ trong bài: AppConfig · Systems Manager Parameter Store · Secrets Manager

Tự động khởi động lại một worker mà không khởi động lại toàn bộ nhóm máy

Tình huống và yêu cầu

Bạn đang trực vận hành cho một dịch vụ xử lý tài liệu. Tình trạng worker bị treo lặp đi lặp lại khiến tuổi message trong hàng đợi tăng. Cho worker bị ảnh hưởng xử lý hết công việc đang nhận rồi khởi động lại thường giúp tiến trình xử lý tiếp tục, nhưng làm vậy với mọi worker cùng lúc sẽ khiến việc xử lý dừng lại.

Nhóm của bạn muốn tự động hóa bước khôi phục phạm vi hẹp này trong khi tiếp tục điều tra lỗi. Workflow phải chịu được alarm trùng lặp, từ chối hành động không an toàn trong khi triển khai và chuyển cấp khi một lần thử không có tác dụng.

Đây là bài tập vận hành giả định.

Các phương án và quyết định

Tự động hóa quy trình đã biết là an toàn, không phải chỉ dẫn mơ hồ “sửa hàng đợi”. Giữ phạm vi và số lần thử có giới hạn.

Mô hình tư duy và luồng xử lý

Alarm yêu cầu điều tra; trạng thái hiện tại quyết định việc sửa chữa còn phù hợp hay không.

Alarm tuổi message trong hàng đợi → EventBridge → Automation → kiểm tra lại và khóa → rút công việc khỏi một worker → khởi động lại → xác minh tiến trình xử lý hoặc chuyển cấp

Một sự kiện trùng lặp không được trở thành lần khởi động lại thứ hai diễn ra đồng thời.

Cơ chế cốt lõi

Dùng execution role có phạm vi hẹp cho nhóm máy được chỉ định. Kiểm tra sức khỏe hiện tại, đợt triển khai đang diễn ra và năng lực phục vụ tối thiểu trước khi hành động. Ghi lại định danh hành động và lấy khóa ở cấp tài nguyên hoặc dùng cơ chế phối hợp tương đương.

Rút công việc khỏi worker một cách an toàn, thực hiện khởi động lại, rồi chờ cả sức khỏe worker lẫn tiến triển xử lý. Thêm thời gian chờ giữa các lần và giới hạn số lần thử. Nếu hành động thất bại hoặc hàng đợi vẫn không khỏe, hãy dừng và gọi người phụ trách trực thay vì lặp lại mãi.

Systems Manager Automation điều phối các bước vận hành và phê duyệt tùy chọn; Lambda có thể thực hiện kiểm tra hoặc hành động ngắn. Tách biệt lỗi vận hành đã biết với phát hiện bảo mật chưa rõ; trường hợp sau cần phân loại và quy trình ứng phó đã được phê duyệt, không phải khởi động lại hàng loạt.

Giữ bản ghi về tác nhân kích hoạt, quyết định, hành động và kết quả. Tự động hóa không được che mất bằng chứng cần để xác định vì sao worker tiếp tục bị treo.

Kiểm chứng và khi nào cần đổi phương án

• Gửi sự kiện trùng lặp và đã lỗi thời; xác minh chỉ một hành động hợp lệ tác động đến tài nguyên.
• Mô phỏng năng lực khỏe mạnh không đủ và một đợt triển khai đang diễn ra; runbook phải từ chối hoặc hoãn khởi động lại.
• Cố ý làm khởi động lại thất bại và xác minh có chuyển cấp mà không có vòng lặp thử lại trên toàn bộ nhóm máy.

Nếu triệu chứng có nhiều nguyên nhân không liên quan, hãy chẩn đoán và xin phê duyệt của con người trước khi khắc phục theo cách gây gián đoạn. Một hành động an toàn có tính lặp lại cao phù hợp để tự động hóa hơn là phỏng đoán nguyên nhân gốc chưa chắc chắn.

Điểm cần nhớ và tài liệu AWS

• Kiểm tra lại trạng thái hiện tại trước khi hành động dựa trên sự kiện.
• Tính idempotent và khóa ngăn tác động vận hành trùng lặp.
• Kiểm tra năng lực giới hạn tác động của việc sửa chữa.
• Khôi phục cần điều kiện dừng và đường chuyển cấp.
• Tự động hóa biện pháp xử lý tạm thời không sửa được nguyên nhân gốc.

AWS: Systems Manager Automation

Dịch vụ trong bài: EventBridge · Systems Manager Automation · Lambda

Mở rộng trước khi chiến dịch theo lịch tăng tải nhanh hơn tốc độ khởi động instance

Tình huống và yêu cầu

Bạn chuẩn bị tầng web của một nhà bán lẻ cho chiến dịch bắt đầu lúc 20:00. Lưu lượng dự kiến tăng gấp mười lần trong hai phút, trong khi các instance cần bốn phút để khởi động và đạt trạng thái khỏe mạnh.

Trong bài tập giả định này, kết quả kiểm thử tải được giả định cho thấy mỗi instance xử lý an toàn 200 yêu cầu mỗi giây với mục tiêu p95 là 500 ms. Bạn cần đủ năng lực sẵn sàng khi chiến dịch bắt đầu, tiếp tục điều chỉnh sau đó và thu hẹp an toàn khi chiến dịch kết thúc.

Các phương án và quyết định

Mở rộng trước sự kiện và duy trì mở rộng động sau đó. Tính năng lực dự phòng theo cơ cấu yêu cầu đã đo, không chọn số lượng instance tùy ý.

Mô hình tư duy và luồng xử lý

Có độ trễ từ lúc yêu cầu một máy chủ đến lúc nhận được năng lực thực sự hữu ích.

Lịch chiến dịch → tăng năng lực sớm → khởi tạo và kiểm tra tình trạng → lưu lượng từ ALB → target tracking → thu hẹp sau khi rút hết kết nối

Thời gian chuẩn bị phải bao quát thời gian khởi động thực tế, không chỉ thời gian API khởi chạy EC2 trả về phản hồi.

Cơ chế cốt lõi

Dùng Auto Scaling group trải trên nhiều AZ với launch template đã được kiểm thử. Tăng năng lực tối thiểu và mong muốn đủ sớm để có thời gian làm nóng. Theo dõi chỉ số liên quan đến nút thắt, chẳng hạn số yêu cầu trên mỗi target khi phù hợp; CPU có thể gây hiểu nhầm với workload bị giới hạn bởi bộ nhớ hoặc hệ thống phụ thuộc.

Cấu hình thời gian làm nóng instance theo hành vi quan sát được. Warm pool có thể giảm một phần độ trễ khởi động nhưng phát sinh thêm chi phí. Predictive scaling hữu ích với các quy luật đã hình thành, nhưng không tự dự đoán một chiến dịch mới mà chưa ai cấu hình vào hệ thống.

Tính đến việc mất một AZ trong thời gian tải đỉnh. Kiểm tra hạn ngạch, khả năng cung cấp instance, địa chỉ trong subnet và ngân sách kết nối cơ sở dữ liệu. Số instance web tăng mười lần có thể tạo ra số kết nối cơ sở dữ liệu gấp mười lần nếu không giới hạn các pool kết nối.

Rút hết kết nối trong quá trình thu hẹp và lưu trạng thái công việc quan trọng bên ngoài instance. Khôi phục mức tối thiểu bình thường sau sự kiện thay vì để đội instance đã mở rộng trước chạy vô thời hạn.

Kiểm chứng và khi nào cần đổi phương án

• Tái hiện tốc độ tăng tải của chiến dịch và kiểm tra p95, tỷ lệ lỗi cùng số target sẵn sàng.
• Lặp lại khi năng lực AZ bị giảm và xác minh các giới hạn của hệ thống phía sau vẫn an toàn.
• Diễn tập kết thúc chiến dịch, rút hết kết nối và đưa chi phí về mức bình thường.

Với các đợt tăng tải khó dự đoán, có thể cần tài nguyên tính toán khởi động nhanh hơn, năng lực đã làm nóng hoặc bộ đệm dựa trên hàng đợi. Mở rộng theo lịch phù hợp ở đây vì doanh nghiệp đã biết khi nào nhu cầu bắt đầu.

Điểm cần nhớ và tài liệu AWS

• Độ trễ khởi động có thể vượt quá thời gian có thể phản ứng.
• Mở rộng theo lịch và mở rộng động có thể bổ trợ nhau.
• Chọn tín hiệu mở rộng phản ánh đúng nút thắt thực tế.
• Tăng năng lực front-end có thể làm quá tải các hệ thống phụ thuộc.
• Thu hẹp an toàn là một phần của thiết kế mở rộng.

AWS: mở rộng động

Dịch vụ trong bài: EC2 · Auto Scaling · ALB · CloudWatch

Chuẩn bị Auto Scaling cho đợt flash sale thay vì chỉ tăng mức tối đa

Tình huống và yêu cầu

Bạn đang chuẩn bị cho một nhà bán lẻ tổ chức đợt flash sale theo lịch. Lưu lượng dự báo gấp năm lần bình thường, và ứng dụng vẫn phải hoạt động sau khi mất một AZ.

Trong bài tập giả định này, lần diễn tập tải đầu tiên chạm hạn ngạch vCPU của EC2. Sau khi tăng giới hạn đó, các instance mới không khởi chạy được vì subnet đích thiếu địa chỉ trống. Doanh nghiệp cần một kế hoạch năng lực bao quát toàn bộ đường đi của yêu cầu, không phải thêm một lần tăng kích thước tối đa của nhóm Auto Scaling.

Các phương án và quyết định

Lập kế hoạch đáp ứng lưu lượng cao điểm bằng năng lực còn lại sau sự cố, rồi mở rộng trước đợt bán hàng. Duy trì hành vi xử lý quá tải có kiểm soát khi nhu cầu vượt phạm vi đã kiểm thử.

Mô hình tư duy và luồng xử lý

Auto Scaling yêu cầu năng lực tài nguyên; nhiều hệ thống khác quyết định năng lực đó có trở nên hữu ích hay không.

Tín hiệu nhu cầu → năng lực mong muốn của ASG → kiểm tra hạn ngạch → năng lực instance và IP subnet sẵn có → instance khỏe mạnh → năng lực của thành phần phụ thuộc

Bất kỳ bước nào thất bại đều khiến năng lực được yêu cầu không sẵn sàng.

Cơ chế cốt lõi

Chuyển thông lượng dự kiến thành số instance, kết nối cơ sở dữ liệu, mức tiêu thụ IP/ENI, nhu cầu kết nối NAT và giới hạn API phía sau. Tính cả trường hợp mất một AZ, không chỉ vận hành cao điểm bình thường.

Kiểm tra hạn ngạch theo tài khoản/Region và sớm yêu cầu tăng các hạn ngạch có thể điều chỉnh. Service Quotas không bao quát mọi giới hạn dịch vụ. Xác minh địa chỉ subnet trống và khả năng tương thích kiến trúc khi dùng các loại instance và AZ thay thế.

Khi cần bảo đảm có năng lực điện toán khớp với yêu cầu, hãy đánh giá On-Demand Capacity Reservations. Savings Plan giảm giá sử dụng nhưng không giữ chỗ năng lực. Ngay cả việc tăng hạn ngạch cũng không bảo đảm loại instance mong muốn có sẵn vào lúc khởi chạy.

Dùng hàng đợi có giới hạn, kiểm soát tiếp nhận và loại bỏ tải có chọn lọc khi các thành phần phụ thuộc bão hòa. Thêm instance ứng dụng mà không kiểm soát mức đồng thời truy cập cơ sở dữ liệu có thể làm sự cố tệ hơn. Giới hạn số lần thử lại và áp dụng backoff thay vì nhân thêm các yêu cầu thất bại.

Kiểm chứng và khi nào cần đổi phương án

• Diễn tập tải cao điểm khi một AZ không sẵn sàng và kiểm tra lỗi khởi chạy cùng phần năng lực còn dư của các thành phần phụ thuộc.
• Thiết lập cảnh báo về địa chỉ trống, mức sử dụng hạn ngạch liên quan, tuổi của mục trong hàng đợi và các lần khởi chạy thất bại.
• Xác nhận các giao dịch thiết yếu vẫn hoạt động khi quá tải, trong khi công việc ưu tiên thấp hơn được hoãn hoặc bị từ chối rõ ràng.

Nhu cầu khó dự đoán có thể đòi hỏi linh hoạt hơn về loại instance và khả năng tự động mở rộng mạnh hơn. Một nút thắt cứng cố định có thể cần phân vùng hoặc thiết kế lại, không phải một yêu cầu tăng hạn ngạch lớn hơn.

Điểm cần nhớ và tài liệu AWS

• Mức tối đa của ASG là quyền được tăng quy mô, không phải năng lực sẵn có.
• Hạn ngạch, năng lực vật lý và địa chỉ subnet là các ràng buộc riêng biệt.
• Kế hoạch cao điểm phải tính cả phần năng lực dự phòng cho sự cố.
• Giảm giá không nhất thiết đi kèm giữ chỗ năng lực.
• Mở rộng một tầng có thể làm tầng tiếp theo quá tải.

AWS: Service Quotas

Dịch vụ trong bài: Service Quotas · Auto Scaling · EC2 · CloudWatch