Bỏ qua

1.Amazon S3 Lifecycle – cách mà bạn tự động xóa hoặc lưu trữ dữ liệu cũ trong S3 bucket. Mình sẽ giải thích từng phần một cách dễ hiểu nhất:

🔸 Bản gốc:

If you have an object expiration lifecycle configuration in your unversioned bucket

and you want to maintain the same permanent delete behavior when you enable versioning,

you must add a noncurrent expiration configuration .

✅ Nghĩa:

Nếu bạn đang dùng cấu hình tự động xóa đối tượng (object expiration) trong một bucket không bật versioning ,

và bạn muốn giữ nguyên hành vi "xóa vĩnh viễn" đó khi bạn bật versioning lên ,

thì bạn phải thêm một cấu hình noncurrent expiration .

🔸 Bản gốc:

The noncurrent expiration lifecycle configuration manages the deletes of the noncurrent object versions

in the versioning-enabled bucket.

✅ Nghĩa:

Cấu hình noncurrent expiration dùng để tự động xóa các phiên bản cũ (noncurrent versions)

trong bucket đã bật versioning.

🔸 Bản gốc:

(A versioning-enabled bucket maintains one current, and zero or more noncurrent, object versions.)

✅ Nghĩa:

Một bucket bật versioning sẽ lưu:

  • 1 phiên bản hiện tại ( current )
  • và 0 hoặc nhiều phiên bản cũ ( noncurrent )

📌 Tóm tắt dễ hiểu:

Trước khi bật versioning Sau khi bật versioning
Bạn dùng expirationđể xóa object vĩnh viễn S3 không còn xóa vĩnh viễn khi object bị ghi đè hoặc xóa
→ Object biến mất hoàn toàn → Object cũ trở thànhnoncurrent version
Không cần thêm gì Phải thêm noncurrent expirationđể dọn rác

🔁 Ví dụ:

Bạn có file report.pdf trong bucket:

  • ✅ Khi bucket chưa bật versioning :
  • Bạn cấu hình: "xóa sau 30 ngày"
  • → 30 ngày sau, file report.pdf bị xóa vĩnh viễn.
  • ❌ Sau khi bật versioning :
  • Khi bạn cập nhật report.pdf, thì:
    • bản cũ trở thành noncurrent version
    • bản mới là current version
  • Nếu bạn chỉ có expiration, thì chỉ bản hiện tại mới bị xóa , còn bản cũ vẫn còn.
  • 👉 Bạn cần thêm noncurrent expiration để xóa cả bản cũ sau x ngày.

2.Một trường đại học Ivy League đang hỗ trợ NASA xác định các địa điểm hạ cánh tiềm năng cho tàu thăm dò không người lái. Họ sử dụng kiến trúc ứng dụng dựa trên HPC . Hỏi ứng dụng này nên triển khai EC2 theo kiểu topology nào?

✅ Đáp án đúng:

The Amazon EC2 instances should be deployed in a cluster placement group so that the underlying workload can benefit from low network latency and high network throughput.

🔍 Giải thích chi tiết:

1. 🔬 Hiểu yêu cầu của bài toán HPC:

  • High Performance Computing (HPC) là các ứng dụng tính toán hiệu năng cao, thường xử lý khối lượng lớn dữ liệu và yêu cầu:
  • Truyền dữ liệu nhanh giữa các node
  • Độ trễ thấp
  • Băng thông mạng cao
  • Giao tiếp node-to-node thường xuyên
  • Ví dụ trong câu hỏi là một bài toán khoa học không gian , sử dụng tính toán mạnh để phân tích dữ liệu và mô phỏng, rất điển hình cho workload HPC.

2. 🧠 Cluster Placement Group phù hợp nhất cho HPC vì:

  • Cluster Placement Group đặt tất cả các instance trong một nhóm gần nhau về vật lý bên trong một Availability Zone (AZ) .
  • Điều này cho phép:
  • Độ trễ mạng thấp
  • Tốc độ truyền dữ liệu giữa các EC2 cao
  • Phù hợp với ứng dụng tightly-coupled , nơi các máy phải thường xuyên trao đổi dữ liệu.

📌 HPC workloads luôn được khuyến nghị triển khai trong Cluster Placement Group theo tài liệu chính thức của AWS.

❌ Giải thích các lựa chọn sai:

3. 🚫 Partition Placement Group :

  • Dùng để tách nhóm EC2 theo partition logic riêng biệt , mỗi partition không dùng chung phần cứng. partition có thể ở các az khác nhau,Tối đa : 7 partition mỗi AZ.
  • Tốt cho hệ thống phân tán lớn như Hadoop, Cassandra, Kafka .
  • Không tập trung các máy gần nhau → không đảm bảo độ trễ thấp → Không phù hợp cho HPC .

4. 🚫 Spread Placement Group :

  • Mỗi EC2 được đặt trên racks khác nhau , cách ly vật lý → giảm nguy cơ các lỗi đồng thời (correlated failures). , SPG có thể ở các az khác nhau,You can have a maximum of seven running instances per Availability Zone per group. (nghĩa là 7 instance trong 1 group ở 1 az )
  • Phù hợp cho workload yêu cầu độ sẵn sàng cao (HA) , nhưng không yêu cầu truyền dữ liệu nhanh giữa máy.
  • Không tối ưu mạng giữa các máy → Không phù hợp HPC

5. 🚫 Auto Scaling Group :

  • Dùng để tự động tăng/giảm số lượng EC2 theo tải.
  • Tốt cho các ứng dụng web / backend / microservices , nơi cần mở rộng linh hoạt .
  • Nhưng HPC thường cố định số lượng node , và yêu cầu hiệu năng mạng cao chứ không phải chỉ co giãn → Không phù hợp HPC

🧩 1. Partition Placement Group (PPG)

✅ Sự thật:

  • Tối đa 7 partition / AZ .
  • Mỗi partition có thể chứa nhiều EC2 instance (không giới hạn cụ thể).
  • Các EC2 trong cùng một partition có thể dùng chung phần cứng .
  • Các partition khác nhau thì không dùng chung phần cứng → tách biệt để tránh "correlated failure".

📌 Tóm lại:

Thông số Giá trị
Số partition / AZ Tối đa 7
Số EC2 / partition Gần nhưkhông giới hạn
Số EC2 / AZ Tùy số EC2 bạn đặt trong từng partition
AZ khác nhau? ✅ Có thể triển khai trên nhiều AZ

🧩 2. Spread Placement Group (SPG)

✅ Sự thật:

  • Mỗi EC2 instance được đặt trên 1 rack riêng biệt .
  • Tối đa 7 EC2 / AZ / mỗi Spread Placement Group (trừ khi xin tăng quota).
  • Một SPG có thể trải rộng nhiều AZ , và mỗi AZ được tối đa 7 EC2 .
  • Tổng cộng mỗi SPG có thể có: số AZ × 7 EC2 instance (mặc định).

📌 Tóm lại:

Thông số Giá trị
Số EC2 / AZ / SPG Tối đa 7(mỗi cái trên rack riêng)
Tổng EC2 / SPG AZ × 7
EC2 dùng chung rack? ❌ Không
Triển khai đa AZ? ✅ Có thể
Bạn có thể tạo bao nhiêu SPG tùy ý.

🧠 So sánh : Cluster vs Partition vs Spread Placement Group

Tiêu chí Cluster Placement Group Partition Placement Group Spread Placement Group
💡Khái niệm cốt lõi Nhóm các EC2 gần nhau về vật lý để đạthiệu suất mạng tối đa Nhóm EC2 thànhcác partition độc lập phần cứng nhằmgiảm rủi ro lan truyền lỗi phần cứng Mỗi EC2 nằmtrên một rack riêng biệt , tối đa hóa khả năng cách ly lỗi phần cứng
📌Mô hình triển khai phần cứng Các EC2 nằmrất gần nhau(có thể cùng rack hoặc lân cận trong AZ) Mỗi partition dùng phần cứng riêng; các partitionkhông chia sẻ thiết bị Mỗi EC2 nằm trênmột rack khác nhau→ mỗi rack có nguồn điện, mạng riêng biệt
⚙️Kiến trúc phù hợp Tightly-coupled systems– hệ thống cần truyền thông liên tục, tốc độ cao (HPC, AI, ML, MPI, CFD) Distributed systems– hệ thống phân tán, cần song song hóa, ví dụ Hadoop, Cassandra, Kafka Critical systems– hệ thống lõi không được phép cùng hỏng, như DB, quorum-based clusters, control planes
🔌Hiệu suất mạng ✅Cao nhất– bandwidth lớn, latency thấp ❌ Không đảm bảo cao vì có thể trải qua nhiều AZ ❌ Không đảm bảo cao, vì các EC2 phân tán vật lý
🔒Tách biệt lỗi phần cứng (fault isolation) ❌ Không (các EC2 có thể cùng rack) ✅ Theo nhóm (partition cách ly nhau, nhưng cùng partition vẫn có thể bị lỗi chung) ✅ Tối đa – mỗi EC2 nằm rack khác, gần như lỗi phần cứng không bao giờ ảnh hưởng đồng thời 2 instance
🧱Khả năng chịu lỗi (resilience) Thấp – nếu rack lỗi có thể ảnh hưởng cả nhóm Trung bình – lỗi chỉ ảnh hưởng 1 partition Cao – lỗi chỉ ảnh hưởng 1 EC2, các EC2 còn lại vẫn hoạt động
📚Khả năng mở rộng (scalability) Hạn chế – càng nhiều EC2 càng khó giữ gần nhau Rất tốt – có thể mở rộng dễ dàng bằng thêm partition hoặc AZ khác Kém – bị giới hạn 7 EC2 / AZ / SPG mặc định
🔁Auto Scaling phù hợp không? Không phù hợp lắm vì phụ thuộc vào khả năng gói cụm ✅ Phù hợp với workload phân tán mở rộng tự nhiên ❌ Không khuyến khích – dễ vượt giới hạn instance
🌐Multi-AZ hỗ trợ? ❌ Không – chỉ được trong1 AZ duy nhất ✅ Có thể trải rộngnhiều AZ ✅ Có thể trải rộngnhiều AZ
🧮Số lượng phần tử / giới hạn mặc định Không giới hạn cụ thể, nhưng khó đạt hiệu quả khi nhiều EC2 Tối đa 7 partition / AZ, mỗi partition chứanhiều EC2 Tối đa 7 EC2 / AZ / SPG (mặc định)
🧭Cách điều phối phần cứng của AWS Gán EC2 vào vùng phần cứng cực gần (low-latency fabric) Mỗi partition được đặt trên cụm phần cứng riêng, không dùng chung network/power với partition khác Mỗi EC2 ép buộc vào rack vật lý riêng – mỗi rack có power/network riêng

Giới hạn mặc định trên mỗi Region 100 cho cả 3 loại

🧪 Khi nào dùng loại nào?

Tình huống Loại nên dùng
Cần tính toán hiệu năng cao (AI/ML/HPC) – giao tiếp nhanh giữa EC2 Cluster Placement
Xử lý Big Data phân tán, nhiều node, tính song song cao (Kafka, Hadoop, Cassandra) Partition Placement
Hệ thống quan trọng, không được lỗi cùng lúc (DB, master node, quorum, etcd...) Spread Placement

3.Cost of test file storage on

Amazon S3 Standard < Cost of test file storage on Amazon EFS < Cost of test file storage on Amazon EBS**

With Amazon EBS Elastic Volumes, you pay only for the resources that you use. The Amazon EFS Standard Storage pricing is $0.30 per GB per month. Therefore the cost for storing the test file on EFS is $0.30 for the month.

For Amazon EBS General Purpose SSD (gp2) volumes, the charges are $0.10 per GB-month of provisioned storage. Therefore, for a provisioned storage of 100GB for this use-case, the monthly cost on EBS is $0.10*100 = $10. This cost is irrespective of how much storage is actually consumed by the test file.

For S3 Standard storage, the pricing is $0.023 per GB per month. Therefore, the monthly storage cost on S3 for the test file is $0.023.

4.Kịch bản: Công ty bán lẻ có trang web động chạy trên máy chủ tại trung tâm dữ liệu ở Mỹ. Sắp ra mắt ở Châu Á, cần giảm độ trễ cho người dùng tại đây ngay lập tức , trong khi backend (máy chủ xử lý logic) VẪN PHẢI ở Mỹ .

Giải pháp phù hợp nhất: Sử dụng Amazon CloudFront với Custom Origin trỏ đến máy chủ On-Premises của bạn.

  • Giải thích:
  • Amazon CloudFront là dịch vụ Mạng phân phối nội dung (CDN) toàn cầu của AWS. Nó có mạng lưới các điểm biên (edge locations) và bộ nhớ đệm khu vực (regional edge caches) đặt rải rác khắp thế giới (gần người dùng cuối).
  • Custom Origin: CloudFront có thể lấy nội dung gốc từ nhiều nguồn (origin). Ngoài S3 hoặc EC2, nó có thể lấy nội dung từ bất kỳ máy chủ HTTP nào có thể truy cập được qua Internet, bao gồm cả máy chủ On-Premises của bạn. Máy chủ On-Premises trong trường hợp này chính là "Custom Origin" của CloudFront.
  • Tại sao giải quyết vấn đề: Khi người dùng ở Châu Á truy cập trang web, yêu cầu của họ sẽ được chuyển đến điểm biên CloudFront gần nhất. CloudFront sẽ lưu bản sao nội dung (đặc biệt là nội dung tĩnh hoặc nội dung động có thể cache được) tại điểm biên này. Lần truy cập tiếp theo hoặc bởi người dùng khác trong cùng khu vực, CloudFront sẽ phục vụ nội dung trực tiếp từ điểm biên gần đó. Điều này giảm đáng kể quãng đường vật lý mà dữ liệu phải di chuyển, từ đó giảm độ trễ và tối ưu thời gian tải trang cho người dùng ở Châu Á, mà không cần di chuyển backend (máy chủ xử lý chính ở Mỹ).

Tại sao các lựa chọn khác không phù hợp:

  • CloudFront Custom Origin trỏ đến Route 53 DNS record: Sai cấu hình . CloudFront Origin cần trỏ đến một endpoint chứa nội dung (như máy chủ HTTP hoặc S3 bucket), không phải bản ghi DNS trong Route 53 (Route 53 chỉ giải quyết tên miền thành địa chỉ IP).
  • Di chuyển website sang S3 + S3 CRR: Sai . Trang web là động . S3 chỉ phù hợp cho website tĩnh . S3 không chạy code xử lý phía máy chủ (server-side scripting). S3 CRR (sao chép dữ liệu giữa các bucket S3) không liên quan đến việc chạy website động hoặc giảm độ trễ cho xử lý backend.
  • Route 53 Geo-proximity routing trỏ đến máy chủ On-Premises: Sai . Geo-proximity routing của Route 53 chỉ giúp định tuyến người dùng đến endpoint gần nhất bạn đã định nghĩa. Tuy nhiên, vì máy chủ On-Premises duy nhất vẫn ở Mỹ, người dùng ở Châu Á vẫn sẽ được định tuyến trực tiếp đến máy chủ xa đó. Nó không giảm quãng đường thực tế và không giải quyết được độ trễ do khoảng cách địa lý đối với các tương tác với backend ở Mỹ.

CloudFront mang nội dung (cache) lại gần người dùng ở Châu Á -> giảm quãng đường -> giảm độ trễ -> tải nhanh hơn, backend vẫn ở chỗ cũ .

35.Đội DevOps của một công ty thương mại điện tử cần thực hiện công việc bảo trì (cụ thể là triển khai bản vá - maintenance patch) trên một phiên bản EC2 cụ thể thuộc về một Auto Scaling Group đang sử dụng chính sách điều chỉnh quy mô theo bước (step scaling policy).^1^ Vấn đề họ gặp phải là khi áp dụng bản vá, trạng thái kiểm tra sức khỏe (health check status) của phiên bản đó hiển thị là "không hoạt động" (out of service) trong vài phút. Điều này khiến Auto Scaling Group kích hoạt tính năng tự động và ngay lập tức khởi tạo một phiên bản thay thế.

Vấn đề cần giải quyết: Làm thế nào để thực hiện bảo trì mà không bị Auto Scaling Group tự động thay thế phiên bản bị đánh dấu là không khỏe tạm thời? Cần các bước hiệu quả nhất về thời gian và tài nguyên.

Hai Bước Hiệu quả nhất được đề xuất (và lý do):

  1. Đưa phiên bản vào trạng thái Standby và sau đó cập nhật phiên bản bằng cách áp dụng bản vá bảo trì. Sau khi phiên bản sẵn sàng, bạn có thể thoát khỏi trạng thái Standby và đưa phiên bản trở lại hoạt động.
  2. Giải thích: Trạng thái Standby cho phép một phiên bản EC2 vẫn là một phần của Auto Scaling Group nhưng không chủ động xử lý lưu lượng truy cập ứng dụng và không được tính vào số lượng phiên bản "InService" của nhóm.
  3. Tại sao hiệu quả: Khi phiên bản ở trạng thái Standby, Auto Scaling Group sẽ không thực hiện hành động thay thế nó ngay cả khi trạng thái kiểm tra sức khỏe của nó thay đổi tạm thời (ví dụ: hiển thị là không khỏe trong lúc bảo trì).
  4. Các bước thực hiện:
    • Đưa phiên bản cần bảo trì vào trạng thái Standby.
    • Áp dụng bản vá bảo trì lên phiên bản đó.
    • Sau khi bảo trì xong và phiên bản hoạt động bình thường trở lại, thoát trạng thái Standby.
    • Phiên bản sẽ được đưa trở lại trạng thái "InService" và tiếp tục xử lý lưu lượng.
  5. Lợi ích: Quá trình này diễn ra trực tiếp trên phiên bản ban đầu, giữ nó là một phần của ASG và tránh việc khởi tạo không cần thiết một phiên bản mới.
  6. Tạm dừng (Suspend) tiến trình ReplaceUnhealthy cho Auto Scaling Group và áp dụng bản vá bảo trì cho phiên bản. Khi phiên bản sẵn sàng, bạn có thể bật lại tiến trình ReplaceUnhealthy.
  7. Giải thích: Tiến trình **ReplaceUnhealthy là một trong các "process type" của Auto Scaling Group.^2^ Chức năng của nó là chấm dứt (terminate) các phiên bản bị đánh dấu là không khỏe và khởi tạo phiên bản mới để thay thế** .
  8. Tại sao hiệu quả: Khi bạn tạm dừng tiến trình ReplaceUnhealthy, bạn ra lệnh cho Auto Scaling Group dừng ngay việc thay thế các phiên bản bị đánh dấu là không khỏe . Các phiên bản vẫn có thể bị đánh dấu là không khỏe (do kiểm tra sức khỏe EC2 hoặc ELB thất bại) trong thời gian này, nhưng ASG sẽ không hành động.
  9. Các bước thực hiện:
    • Tạm dừng tiến trình ReplaceUnhealthy cho ASG.
    • Áp dụng bản vá bảo trì lên phiên bản (phiên bản có thể bị đánh dấu là không khỏe).
    • Sau khi bảo trì xong và phiên bản hoạt động bình thường.
    • Bật lại (Resume) tiến trình ReplaceUnhealthy. (Lưu ý: Nếu phiên bản vẫn còn bị đánh dấu là không khỏe khi bạn Resume, ASG có thể sẽ thay thế nó ngay lúc đó. Đôi khi bạn có thể cần cấu hình hoặc chờ phiên bản tự chuyển sang trạng thái khỏe mạnh trước khi Resume nếu nó không tự động).
  10. Lợi ích: Ngăn chặn ASG tự động thay thế phiên bản chỉ vì nó tạm thời không khỏe trong quá trình bảo trì.

Tại sao các lựa chọn khác không phù hợp (dựa trên giải thích):

  • Chụp Snapshot, tạo AMI mới, khởi chạy phiên bản mới dùng AMI đó, áp dụng bản vá cho phiên bản mới, thêm lại vào ASG, chấm dứt phiên bản cũ: Không hiệu quả về thời gian và tài nguyên . Quá trình này bao gồm nhiều bước phức tạp và tốn thời gian (chụp snapshot, tạo AMI là các thao tác tốn thời gian), chỉ để áp dụng bản vá cho một phiên bản duy nhất. Có những cách đơn giản hơn nhiều (Standby hoặc Suspend).
  • Xóa Auto Scaling Group, sửa lỗi trên phiên bản, tạo ASG mới, thêm lại các phiên bản: Không được khuyến nghị và rất không hiệu quả/gây gián đoạn . Việc xóa và tạo lại toàn bộ Auto Scaling Group là một hoạt động lớn, gây gián đoạn hoạt động và không cần thiết chỉ để bảo trì một phiên bản.
  • Tạm dừng tiến trình ScheduledActions: Không liên quan đến vấn đề thay thế phiên bản không khỏe. ScheduledActions (các hành động theo lịch trình) được dùng để điều chỉnh quy mô ASG vào các thời điểm cụ thể theo lịch (ví dụ: tăng số lượng phiên bản vào giờ cao điểm), chứ không phải để phản ứng với trạng thái sức khỏe của phiên bản.

Tóm lại, hai phương pháp Standby và Suspend ReplaceUnhealthy đều cho phép bạn "tách" phiên bản ra khỏi sự giám sát tự động thay thế của ASG trong quá trình bảo trì, nhưng giữ nó vẫn là một phần của nhóm (Standby) hoặc tạm dừng quy trình thay thế của nhóm (Suspend ReplaceUnhealthy), giúp bảo trì hiệu quả và ít gây gián đoạn nhất.

As soon as you resume the ReplaceUnhealthy process, Amazon EC2 Auto Scaling replaces instances that were marked unhealthy while this process was suspended

Ví dụ:

  • Bạn tạm dừng ReplaceUnhealthy.
  • Phiên bản A bị lỗi và bị đánh dấu là không khỏe (nhưng ASG không làm gì cả vì bạn đã tạm dừng).
  • Bạn bảo trì Phiên bản B, nó cũng bị đánh dấu là không khỏe trong 5 phút (ASG vẫn không làm gì). Sau 5 phút, Phiên bản B khỏe lại.
  • Bạn bật lại ReplaceUnhealthy.
  • Ngay lập tức, ASG sẽ nhìn vào trạng thái hiện tại. Nếu Phiên bản A vẫn đang không khỏe, nó sẽ bị thay thế. Nếu Phiên bản B đã khỏe lại, nó sẽ không bị thay thế.

Điều này nhấn mạnh rằng bạn cần đảm bảo phiên bản của mình thực sự khỏe mạnh trở lại trước khi bật lại tiến trình ReplaceUnhealthy, nếu không nó có thể bị thay thế ngay sau khi bạn Resume.

Trong Auto Scaling Group, Desired Capacity là số lượng phiên bản mà bạn muốn nhóm duy trì ở trạng thái "InService" (đang hoạt động và xử lý lưu lượng).

Khi bạn đưa một phiên bản từ trạng thái "InService" sang trạng thái Standby , có hai cách xử lý giá trị Desired Capacity:

  1. Hành vi Mặc định:
  2. Theo mặc định, giá trị Desired Capacity sẽ bị GIẢM đi 1 đơn vị (hoặc bằng số phiên bản bạn đưa vào Standby).
  3. Lý do: Điều này nhằm ngăn chặn Auto Scaling Group tự động khởi chạy thêm một phiên bản khác ngay lập tức để bù đắp cho phiên bản vừa chuyển sang Standby. ASG hiểu rằng bạn tạm thời chỉ cần số lượng phiên bản "InService" ít hơn 1 (bằng Desired Capacity mới) trong khi phiên bản kia đang ở trạng thái Standby.
  4. Hành vi Tùy chọn (Không giảm Desired Capacity):
  5. Thay vì để giá trị Desired Capacity bị giảm theo mặc định, bạn có thể chỉ định rõ ràng rằng Desired Capacity KHÔNG BỊ GIẢM khi bạn đưa phiên bản vào trạng thái Standby.
  6. Kết quả: Nếu bạn chọn tùy chọn này, Auto Scaling Group sẽ khởi chạy thêm một phiên bản mới ngay lập tức để thay thế cho phiên bản vừa được đưa vào trạng thái Standby.
  7. Mục đích của tùy chọn này: Nhằm giúp bạn duy trì đủ số lượng phiên bản "InService" bằng với giá trị Desired Capacity ban đầu, ngay cả khi một hoặc nhiều phiên bản đang tạm thời ở trạng thái Standby (ví dụ: để bảo trì). ASG đảm bảo năng lực ứng dụng của bạn không bị giảm sút do có phiên bản đang ở Standby.

Tóm lại:

  • Mặc định: Đưa 1 instance vào Standby -> Desired Capacity giảm 1 -> ASG không launch thêm.
  • Tùy chọn: Đưa 1 instance vào Standby + chỉ định KHÔNG giảm Desired Capacity -> Desired Capacity giữ nguyên -> ASG launch thêm 1 instance để bù vào -> Duy trì tổng số instance InService bằng Desired Capacity ban đầu.

1.Một công ty IT gặp sự cố bảo mật: một nhà phát triển mới được cấp quyền truy cập đầy đủ vào Amazon DynamoDB trong môi trường production. Trong khi làm việc trên một tính năng mới, nhà phát triển này đã vô tình xóa mất một vài bảng quan trọng trong môi trường production. Công ty muốn tìm cách hiệu quả nhất để ngăn chặn sự cố tương tự tái diễn.

Vấn đề cần giải quyết: Làm thế nào để kiểm soát chặt chẽ quyền hạn được cấp cho các nhân viên mới (và nói chung là các nhân viên khác) để họ không thể vô tình (hoặc cố ý) gây ra thiệt hại nghiêm trọng như xóa dữ liệu production, ngay cả khi người quản lý cấp quyền cho họ vô tình cấp quá tay?

Giải pháp Hiệu quả nhất được đề xuất (và lý do):

Giải pháp hiệu quả nhất để giải quyết vấn đề này là: Sử dụng Permissions Boundary (Ranh giới quyền) để kiểm soát quyền tối đa mà nhân viên có thể cấp cho các thực thể IAM (người dùng và vai trò).

  • Permissions Boundary làm gì trong trường hợp này?
  • Người quản trị IAM của công ty (hoặc người có quyền phù hợp) sẽ tạo ra một chính sách ranh giới quyền (permissions boundary policy) . Chính sách này sẽ định nghĩa các quyền tối đa mà bất kỳ người dùng hoặc vai trò IAM nào được tạo và quản lý bởi các nhà phát triển (hoặc một nhóm nhân viên cụ thể) có thể có .
  • Quan trọng là, chính sách ranh giới quyền này sẽ được thiết kế để KHÔNG BAO GỒM các quyền nguy hiểm như dynamodb:DeleteTable hoặc các quyền truy cập đầy đủ (dynamodb:*) vào các bảng production.
  • Khi một nhà phát triển tạo một người dùng hoặc vai trò IAM mới, họ sẽ được yêu cầu (hoặc cấu hình bắt buộc) phải đính kèm chính sách ranh giới quyền này vào thực thể mới đó.
  • Sau đó, nhà phát triển có thể đính kèm các chính sách quyền thông thường (identity-based policies) cho phép thực thể mới truy cập các tài nguyên cần thiết cho công việc (ví dụ: quyền dynamodb:PutItem, dynamodb:GetItem trên các bảng dev/test, hoặc thậm chí trên bảng production nếu cần đọc).
  • Quyền Hạn Thực Tế ngăn chặn sự cố:
  • Như đã giải thích trước đó, quyền hạn thực tế của người dùng/vai trò IAM sẽ là giao điểm của chính sách quyền thông thường VÀ chính sách ranh giới quyền.
  • Trong trường hợp này, dù nhà phát triển có vô tình đính kèm một chính sách quyền rộng rãi (ví dụ: cho phép dynamodb:*), thì chính sách ranh giới quyền (không cho phép dynamodb:DeleteTable) sẽ ghi đè và giới hạn lại.
  • Kết quả là, người dùng IAM mới được tạo sẽ không có quyền thực tế để xóa các bảng DynamoDB production, ngay cả khi ý định cấp quyền ban đầu của người tạo là rộng rãi hơn.
  • Tại sao đây là cách hiệu quả nhất để ngăn sự cố tái diễn:
  • Nó thiết lập một hàng rào bảo vệ ở cấp độ chính sách , được kiểm soát bởi người quản trị an ninh.
  • Nó cho phép ủy quyền việc tạo tài khoản/vai trò cho các nhóm khác (như đội phát triển) mà vẫn đảm bảo an toàn, không cần người quản trị trung tâm phải duyệt từng yêu cầu quyền chi tiết.
  • Nó ngăn chặn các sự cố do vô tình cấp quá nhiều quyền ngay từ đầu bởi những người không chuyên về quản lý quyền IAM sâu.

Tại sao các lựa chọn khác không phù hợp (theo giải thích):

  • CTO xem xét quyền hạn của từng người dùng IAM mới: Không hiệu quả và không mở rộng được . Ở quy mô công ty lớn với nhiều nhà phát triển mới thường xuyên, việc CTO phải duyệt thủ công từng bộ quyền hạn là không khả thi, tốn thời gian và dễ xảy ra sai sót.
  • Loại bỏ quyền truy cập đầy đủ CSDL cho tất cả người dùng trong tổ chức: Không thực tế . Sẽ có những người dùng hợp lệ (ví dụ: quản trị viên cơ sở dữ liệu, hệ thống backup tự động) cần có quyền truy cập đầy đủ hoặc các quyền quản trị mạnh mẽ đối với cơ sở dữ liệu để làm công việc của họ.
  • Chỉ người dùng Root có quyền truy cập đầy đủ CSDL: Thực hành không tốt (bad practice) . Tài khoản Root có quyền hạn cao nhất và không bị giới hạn bởi chính sách IAM. Sử dụng tài khoản Root cho các tác vụ hàng ngày làm tăng rủi ro bị lộ thông tin xác thực Root và gây ra thiệt hại không thể phục hồi. Các tác vụ quản trị nên được thực hiện bởi các người dùng/vai trò IAM với quyền hạn được giới hạn ở mức cần thiết (least privilege).

Tóm lại: Permissions Boundary là giải pháp có hệ thống và hiệu quả nhất để giải quyết vấn đề này bằng cách giới hạn quyền tối đa có thể được cấp, ngăn chặn việc cấp nhầm quyền nguy hiểm cho các thực thể IAM và từ đó phòng ngừa các sự cố như xóa bảng production một cách vô tình.

2.Kịch bản: Nhà khoa học tải ảnh 3GB lên Amazon S3 dùng S3 Transfer Acceleration (S3TA), nhưng quá trình không được tăng tốc .

Câu trả lời đúng: Nhà khoa học không phải trả bất kỳ khoản phí truyền dữ liệu nào cho việc tải ảnh lên.

Giải thích (gọn gàng):

Có hai quy tắc tính phí áp dụng ở đây:

  1. Tải dữ liệu vào S3 từ Internet: Amazon S3 không tính phí truyền dữ liệu khi dữ liệu được tải vào từ Internet.
  2. S3 Transfer Acceleration (S3TA): Bạn chỉ trả phí cho S3TA khi quá trình truyền dữ liệu thực sự được tăng tốc .

Trong kịch bản này, dữ liệu được tải vào S3 từ Internet (nghĩa là không mất phí S3 truyền dữ liệu) VÀ quá trình S3TA không mang lại hiệu quả tăng tốc (nghĩa là không mất phí S3TA). Do đó, tổng cộng không có khoản phí truyền dữ liệu nào phải trả.

Các lựa chọn khác sai vì:

  • Trả phí S3TA: Sai, vì quá trình không được tăng tốc.
  • Trả phí S3 truyền dữ liệu: Sai, vì tải dữ liệu vào S3 từ Internet là miễn phí.

  • Trả cả hai: Sai, vì cả hai đều không phát sinh phí trong trường hợp này.

  • Việc tải dữ liệu vào (IN) S3 từ Internet thông thường không mất phí truyền dữ liệu (Data Transfer IN).

  • Việc tải dữ liệu ra (OUT) khỏi S3 để đi ra Internet thông thường có mất phí truyền dữ liệu (Data Transfer OUT).

Còn S3 Transfer Acceleration (S3TA) thì sao? S3TA có biểu phí riêng, áp dụng THÊM VÀO phí truyền dữ liệu cơ bản (nếu có) nếu quá trình truyền thực sự được tăng tốc .

  • Tải LÊN S3 (IN) dùng S3TA: Phí truyền dữ liệu cơ bản là 0 đồng. Nếu S3TA tăng tốc, bạn trả chỉ phí S3TA . Nếu S3TA không tăng tốc, bạn trả 0 đồng (không S3 phí, không S3TA phí).
  • Tải XUỐNG từ S3 (OUT) dùng S3TA: Phí truyền dữ liệu cơ bản (ra Internet) có thể có . Nếu S3TA tăng tốc, bạn trả phí truyền dữ liệu cơ bản (nếu có) + phí S3TA . Nếu S3TA không tăng tốc, bạn chỉ trả phí truyền dữ liệu cơ bản (nếu có) .

Vậy, việc "ra" (tải xuống thứ từ s3) khỏi S3 thường mất phí, bất kể có dùng S3TA hay không (trừ các trường hợp ngoại lệ như tải xuống nội dung tĩnh từ CloudFront origin). S3TA là một khoản phí bổ sung nếu nó hiệu quả.

Bình luận