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

Tìm thấy 2194 câu.

Câu 411 Design Cost-Optimized Architectures

A media agency stores its re-creatable assets on Amazon Simple Storage Service (Amazon S3) buckets. The assets are accessed by a large number of users for the first few days and the frequency of access falls down drastically after a week. Although the assets would be accessed occasionally after the first week, but they must continue to be immediately accessible when required. The cost of maintaining all the assets on Amazon S3 storage is turning out to be very expensive and the agency is looking at reducing costs as much as possible.

As an AWS Certified Solutions Architect – Associate, can you suggest a way to lower the storage costs while fulfilling the business requirements?

  1. A

    Configure a lifecycle policy to transition the objects to Amazon S3 One Zone-Infrequent Access (S3 One Zone-IA) after 30 days
  2. B

    Configure a lifecycle policy to transition the objects to Amazon S3 One Zone-Infrequent Access (S3 One Zone-IA) after 7 days
  3. C

    Configure a lifecycle policy to transition the objects to Amazon S3 Standard-Infrequent Access (S3 Standard-IA) after 30 days
  4. D

    Configure a lifecycle policy to transition the objects to Amazon S3 Standard-Infrequent Access (S3 Standard-IA) after 7 days
Xem giải thích

Đáp án

A — Cấu hình lifecycle policy chuyển object sang S3 One Zone-Infrequent Access sau 30 NGÀY.

Vì sao đúng

Đề cho ba điều kiện, và mỗi điều kiện quyết định một phần của đáp án: | Điều kiện | Kết luận | |---|---| | Tài sản TÁI TẠO ĐƯỢC (re-creatable) | One Zone-IA chấp nhận được — mất thì dựng lại | | Vẫn phải truy cập NGAY khi cần | loại mọi lớp Glacier cần restore | | Muốn giảm chi phí tối đa | One Zone-IA rẻ hơn Standard-IA khoảng 20% |

Và con số 30 NGÀY là ràng buộc kỹ thuật cứng:

S3 yêu cầu object phải ở lớp Standard ÍT NHẤT 30 NGÀY
    trước khi chuyển sang Standard-IA hoặc One Zone-IA
        ↓
    Đặt "sau 7 ngày" → lifecycle rule KHÔNG HỢP LỆ
    → AWS từ chối cấu hình

Nên "sau 7 ngày" trong hai phương án kia là bất khả thi về mặt kỹ thuật, không chỉ là kém tối ưu.

Và vế "re-creatable" là điều cho phép chọn One Zone-IA:

One Zone-IA lưu ở MỘT AZ duy nhất
    → AZ đó bị phá huỷ → dữ liệu MẤT
    → nhưng tài sản này TẠO LẠI ĐƯỢC
    → rủi ro chấp nhận được, đổi lấy chi phí thấp hơn 20%

{"Rules": [{
  "ID": "chuyen-tai-san-cu",
  "Status": "Enabled",
  "Filter": {"Prefix": "tai-san/"},
  "Transitions": [{"Days": 30, "StorageClass": "ONEZONE_IA"}]}]}

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

  • **C. Chuyển sang Standard-IA sau 30 ngày — đây là phương án gần nhất và hoàn toàn hợp lệ về mặt kỹ thuật, nhưng nó đắt hơn khoảng 20%: Standard-IA lưu ở ba AZ, cho độ bền cao hơn — thứ mà tài sản tái tạo được không cần. Đề nhấn mạnh "reducing costs as much as possible".
  • **B. Chuyển sang One Zone-IA sau 7 ngày — vi phạm ràng buộc 30 ngày: cấu hình này không tạo được.
  • **D. Chuyển sang Standard-IA sau 7 ngày — cùng lỗi về ràng buộc thời gian.

Ghi nhớ

Ràng buộc chuyển đổi của lifecycle rule — nội dung cốt lõi:

Chuyển sang Standard-IA hoặc One Zone-IA:
    → object phải ở Standard ÍT NHẤT 30 NGÀY

Chuyển thẳng sang GLACIER:
    → KHÔNG có ràng buộc này (Days: 0 hợp lệ)

Và ràng buộc thời gian lưu tối thiểu (khác với ràng buộc chuyển đổi): | Lớp | Lưu tối thiểu | |---|---| | Standard-IA, One Zone-IA | 30 ngày | | Glacier Instant / Flexible | 90 ngày | | Glacier Deep Archive | 180 ngày |

Hai loại ràng buộc này khác nhau:

Ràng buộc CHUYỂN ĐỔI:  bao lâu ở Standard trước khi chuyển đi
Ràng buộc LƯU TỐI THIỂU: xoá trước hạn vẫn bị tính đủ phí

Standard-IA và One Zone-IA — bảng phân biệt: | | Standard-IA | One Zone-IA | |---|---|---| | Số AZ | ≥ 3 | 1 | | Độ bền | 11 số 9 | 11 số 9 NHƯNG mất nếu AZ đó bị phá huỷ | | Sẵn sàng | 99,9% | 99,5% | | Chi phí lưu trữ | ~0,0125 USD/GB | ~0,01 USD/GB (rẻ hơn ~20%) | | Phí truy xuất | có | có | | Phù hợp | dữ liệu không tái tạo được | dữ liệu TÁI TẠO ĐƯỢC ← câu này |

Quy tắc chọn One Zone-IA:

Dùng khi dữ liệu TÁI TẠO ĐƯỢC — bản sao thứ hai, thumbnail, dữ liệu trung gian, bản chuyển mã KHÔNG dùng cho dữ liệu duy nhất, không thể phục hồi

Ba câu hỏi để chọn đúng lớp:

① Dữ liệu có TÁI TẠO ĐƯỢC không?
      Không → tránh One Zone-IA
② Cần truy xuất NHANH đến mức nào?
      Ngay lập tức → Standard, IA, hoặc Glacier Instant Retrieval
③ Truy cập BAO NHIÊU LẦN?
      Nhiều → tránh lớp có phí truy xuất

Và Glacier Instant Retrieval là lựa chọn đáng cân nhắc:

Glacier Instant Retrieval:
    Truy xuất: MILI GIÂY (như IA)
    Lưu trữ:   ~0,004 USD/GB (RẺ HƠN cả One Zone-IA)
    Ba AZ:     bền hơn One Zone-IA
    Đổi lại:   phí truy xuất cao hơn, lưu tối thiểu 90 ngày

Với tài sản truyền thông đọc rất thưa sau tuần đầu, nó thường rẻ hơn One Zone-IA về tổng chi phí. (Không nằm trong các phương án; One Zone-IA vẫn là đáp án đúng.)

Và S3 Intelligent-Tiering là lựa chọn khi mẫu truy cập khó đoán: | | Lifecycle rule | Intelligent-Tiering | |---|---|---| | Quyết định chuyển tầng | theo TUỔI | theo MẪU TRUY CẬP thật | | Phí truy xuất | có | KHÔNG | | Phí giám sát | không | nhỏ, theo object | | Phù hợp | quy luật rõ ràng ← câu này | mẫu khó đoán |

Với tài sản truyền thông có thể bất ngờ được truy cập lại nhiều (nội dung lan truyền), Intelligent-Tiering tránh được hoá đơn truy xuất bất ngờ.

Ba lưu ý về kích thước object: | Lưu ý | Chi tiết | |---|---| | IA tính phí tối thiểu 128 KB mỗi object | tệp nhỏ hơn bị tính như 128 KB | | Có phí chuyển đổi mỗi object | với hàng triệu object nhỏ, khoản này đáng kể | | Lọc theo kích thước trong lifecycle | tránh chuyển tệp quá nhỏ |

{"Filter": {"ObjectSizeGreaterThan": 131072},
 "Transitions": [{"Days": 30, "StorageClass": "ONEZONE_IA"}]}

Bốn thao tác của lifecycle rule: | Thao tác | Việc | |---|---| | Transitions | chuyển lớp lưu trữ ← câu này | | Expiration | xoá object | | NoncurrentVersionTransitions/Expiration | quản lý phiên bản cũ | | AbortIncompleteMultipartUpload | dọn phần tải lên dở dang |

Dòng cuối đặc biệt quan trọng với tài sản truyền thông — tệp lớn luôn dùng multipart upload, và lần tải lên thất bại để lại các phần tính phí mãi mãi.

Ba lưu ý khi triển khai: | Lưu ý | Chi tiết | |---|---| | Lifecycle chạy MỘT LẦN mỗi ngày | không chuyển đúng vào giờ thứ N | | Chỉ chuyển XUỐNG, không ngược lên | muốn về Standard phải sao chép lại | | Đo mẫu truy cập trước khi chốt số ngày | dùng S3 Storage Class Analysis |

Và một lời khuyên: hãy dùng S3 Storage Class Analysis trong vài tháng trước khi chốt con số 30 ngày. Nó cho biết tài sản thực sự ngừng được truy cập sau bao lâu — nếu thực tế là 60 ngày, chuyển ở ngày 30 sẽ phát sinh phí truy xuất ăn hết phần tiết kiệm được.

Câu 412 Chọn nhiều đáp án Design High-Performing Architectures

A software engineering intern at an e-commerce company is documenting the process flow to provision Amazon EC2 instances via the Amazon EC2 API. These instances are to be used for an internal application that processes Human Resources payroll data. He wants to highlight those volume types that cannot be used as a boot volume.

Can you help the intern by identifying those storage volume types that CANNOT be used as boot volumes while creating the instances? (Select two)

  1. A

    Throughput Optimized Hard disk drive (st1)
  2. B

    Provisioned IOPS Solid state drive (io1)
  3. C

    General Purpose Solid State Drive (gp2)
  4. D

    Instance Store
  5. E

    Cold Hard disk drive (sc1)
Xem giải thích

Đáp án

A và E.

  • A — Throughput Optimized HDD (st1)
  • E — Cold HDD (sc1)

Vì sao đúng

Đề hỏi loại volume nào KHÔNG dùng làm boot volume được — và đó là hai loại HDD của EBS.

Vì sao st1 và sc1 không làm được boot volume:

Cả hai đều là ĐĨA TỪ (HDD), tối ưu cho THÔNG LƯỢNG TUẦN TỰ
    → hiệu năng rất kém với truy cập NGẪU NHIÊN
        ↓
Quá trình khởi động hệ điều hành:
    → đọc rất nhiều tệp nhỏ ở vị trí rải rác
    → là truy cập NGẪU NHIÊN điển hình
        ↓
    HDD làm việc này rất chậm
    → AWS chặn hẳn việc dùng chúng làm boot volume

Đây là giới hạn cứng của AWS, không phải khuyến nghị — bạn không tạo instance với root volume st1 hay sc1 được.

Bảng loại volume và khả năng làm boot volume: | Loại | Boot volume | Ghi chú | |---|---|---| | gp2, gp3 (SSD) | ✅ | phổ biến nhất | | io1, io2 (Provisioned IOPS SSD) | ✅ | cho database I/O cao | | standard (Magnetic, thế hệ cũ) | ✅ | không dùng cho mới | | st1 (Throughput Optimized HDD) | ❌ | big data, log | | sc1 (Cold HDD) | ❌ | dữ liệu lạnh, rẻ nhất | | Instance store | ✅ | với instance store-backed AMI |

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

  • **D. Instance Store — đây là phương án gần nhất và là bẫy chính: nhiều người nghĩ instance store chỉ dùng làm ổ tạm, nhưng instance store-backed AMI thực sự tồn tại và instance khởi động từ đó. Đó là mô hình cũ, hiếm dùng hiện nay, nhưng hoàn toàn hợp lệ.
  • **B. Provisioned IOPS SSD (io1) — dùng làm boot volume được, và là lựa chọn cho hệ điều hành cần I/O rất cao.
  • **C. General Purpose SSD (gp2) — loại boot volume phổ biến nhất, mặc định cho hầu hết AMI.

Ghi nhớ

Các loại EBS volume — bảng cần thuộc: | Loại | Công nghệ | Tối ưu cho | Boot | |---|---|---|---| | gp3 | SSD | cân bằng, IOPS và throughput cấu hình ĐỘC LẬP | ✅ | | gp2 | SSD | cân bằng, IOPS gắn với dung lượng | ✅ | | io1 | SSD | I/O cao, độ trễ thấp | ✅ | | io2 / io2 Block Express | SSD | IOPS cao nhất, độ bền 99,999% | ✅ | | st1 | HDD | THÔNG LƯỢNG tuần tự — big data, log, ETL | ❌ | | sc1 | HDD | dữ liệu lạnh, RẺ NHẤT | ❌ | | standard | HDD (cũ) | không dùng cho mới | ✅ |

Quy tắc nhớ: HAI loại HDD hiện hành (st1 và sc1) đều KHÔNG làm boot volume được.

Ba thông số của st1 và sc1: | | st1 | sc1 | |---|---|---| | Thông lượng tối đa | 500 MB/giây | 250 MB/giây | | IOPS tối đa | 500 | 250 | | Chi phí | ~0,045 USD/GB | ~0,015 USD/GB — rẻ nhất trong EBS | | Dung lượng | 125 GB – 16 TB | 125 GB – 16 TB |

Cả hai đều RẤT KÉM cho truy cập ngẫu nhiên — chỉ dùng khi dữ liệu được đọc ghi tuần tự thành khối lớn.

Ba trường hợp dùng st1 và sc1: | Trường hợp | Loại | |---|---| | Xử lý log, ETL, MapReduce | st1 | | Kho dữ liệu quét toàn bảng | st1 | | Dữ liệu lạnh, truy cập rất thưa | sc1 |

Tỷ lệ IOPS trên dung lượng của các loại SSD: | Loại | Tỷ lệ | IOPS tối đa | |---|---|---| | gp2 | 3 IOPS/GB (burst 3.000) | 16.000 | | gp3 | 500 IOPS/GB, 3.000 IOPS MIỄN PHÍ | 16.000 | | io1 | 50 IOPS/GB | 64.000 | | io2 | 500 IOPS/GB | 64.000 (256.000 Block Express) |

gp3 là cải tiến quan trọng so với gp2:

gp2: muốn nhiều IOPS phải mua nhiều dung lượng
    → nhiều người cấp 1 TB chỉ để có đủ IOPS

gp3: IOPS và throughput khai RIÊNG
    → và rẻ hơn gp2 khoảng 20% ở cùng dung lượng

Chuyển gp2 sang gp3 là tối ưu dễ nhất trên AWS:

aws ec2 modify-volume --volume-id vol-0abc123 --volume-type gp3

Một lệnh, không gián đoạn, giảm ngay chi phí.

Ba đặc điểm căn bản của EBS: | Đặc điểm | Chi tiết | |---|---| | Gắn với MỘT Availability Zone | chuyển AZ phải qua snapshot | | Bền vững độc lập với instance | trừ khi DeleteOnTermination = true | | Snapshot có phạm vi Region | sao chép chéo Region được |

Instance store và EBS — bảng phân biệt: | | Instance store | EBS | |---|---|---| | Vị trí | đĩa VẬT LÝ trên máy chủ | qua mạng | | Hiệu năng | cao nhất | rất tốt | | Bền vững qua stop/terminate | ❌ MẤT | ✅ | | Snapshot | ❌ | ✅ | | Boot volume | ✅ (instance store-backed AMI) | ✅ |

Và instance store-backed AMI có hạn chế: | Hạn chế | Chi tiết | |---|---| | KHÔNG dừng (stop) được | chỉ reboot hoặc terminate | | Không đổi loại instance | | | Dữ liệu mất khi terminate | | | Trạng thái | cũ, hiếm dùng hiện nay |

Ba cách tối ưu chi phí EBS: | Cách | Tiết kiệm | |---|---| | Chuyển gp2 sang gp3 | ~20%, một lệnh | | Xoá volume mồ côi | volume available vẫn tính tiền | | Dọn snapshot cũ bằng Data Lifecycle Manager | snapshot tích tụ âm thầm |

Và multi-attach — chi tiết đáng biết: | Đặc điểm | Chi tiết | |---|---| | Chỉ io1 và io2 | gp3 KHÔNG hỗ trợ | | Tối đa 16 instance trong CÙNG AZ | | | Cần hệ thống tệp hỗ trợ truy cập đồng thời | ext4 hay XFS thông thường sẽ HỎNG DỮ LIỆU |

Và một lời khuyên khi chọn volume: mặc định dùng gp3 cho hầu hết trường hợp. Chỉ chuyển sang io2 khi đo được rằng gp3 không đủ IOPS, và chỉ dùng st1 hoặc sc1 cho dữ liệu thực sự được đọc tuần tự thành khối lớn — dùng sai loại HDD cho truy cập ngẫu nhiên là nguyên nhân của những vấn đề hiệu năng rất khó chẩn đoán.

Câu 413 Design Resilient Architectures

A healthcare company uses its on-premises infrastructure to run legacy applications that require specialized customizations to the underlying Oracle database as well as its host operating system (OS). The company also wants to improve the availability of the Oracle database layer. The company has hired you as an AWS Certified Solutions Architect – Associate to build a solution on AWS that meets these requirements while minimizing the underlying infrastructure maintenance effort.

Which of the following options represents the best solution for this use case?

  1. A

    Leverage multi-AZ configuration of Amazon RDS Custom for Oracle that allows the Database Administrator (DBA) to access and customize the database environment and the underlying operating system
  2. B

    Leverage multi-AZ configuration of Amazon RDS for Oracle that allows the Database Administrator (DBA) to access and customize the database environment and the underlying operating system
  3. C

    Leverage cross AZ read-replica configuration of Amazon RDS for Oracle that allows the Database Administrator (DBA) to access and customize the database environment and the underlying operating system
  4. D

    Deploy the Oracle database layer on multiple Amazon EC2 instances spread across two Availability Zones (AZs). This deployment configuration guarantees high availability and also allows the Database Administrator (DBA) to access and customize the database environment and the underlying operating system
Xem giải thích

Đáp án

A — Dùng cấu hình Multi-AZ của Amazon RDS Custom for Oracle, cho phép DBA truy cập và tuỳ chỉnh cả môi trường database lẫn hệ điều hành bên dưới.

Vì sao đúng

Đề nêu ba yêu cầu, và RDS Custom là dịch vụ duy nhất đáp ứng đủ: | Yêu cầu | Cơ chế | |---|---| | Cần TUỲ CHỈNH database VÀ HỆ ĐIỀU HÀNH | RDS Custom cho quyền truy cập hệ điều hành | | Cải thiện tính SẴN SÀNG của tầng Oracle | Multi-AZ với failover tự động | | GIẢM THIỂU công bảo trì hạ tầng | AWS vẫn lo sao lưu, vá lỗi, giám sát |

RDS Custom là gì — điểm giữa của RDS và EC2:

RDS thường:
    ✓ AWS lo mọi thứ
    ✗ KHÔNG truy cập được hệ điều hành
    ✗ KHÔNG cài được gói phần mềm riêng

EC2 tự quản lý:
    ✓ toàn quyền
    ✗ bạn lo TẤT CẢ: cài đặt, vá lỗi, sao lưu, sẵn sàng cao

RDS Custom:
    ✓ TRUY CẬP hệ điều hành (SSH, quyền sudo)
    ✓ cài agent, thư viện, tuỳ chỉnh tham số cấp OS
    ✓ AWS VẪN lo sao lưu, Multi-AZ, giám sát

Và đây chính xác là nhu cầu của ứng dụng cũ trong đề:

"require specialized customizations to the underlying Oracle database
 AS WELL AS its host operating system"
    ↓
    → RDS thường KHÔNG làm được
    → nhưng vẫn muốn "minimizing infrastructure maintenance effort"
    → RDS Custom là điểm cân bằng

Và Multi-AZ cho RDS Custom hoạt động như RDS thường:

Primary (AZ-a) ──sao chép──▶ Standby (AZ-b)
    → failover tự động khi primary hỏng

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

  • **B. Dùng RDS for Oracle thường với Multi-AZ cho phép DBA tuỳ chỉnh hệ điều hành — đây là phương án gần nhất và có vế Multi-AZ đúng, nhưng nó sai về khả năng: RDS thường KHÔNG cho truy cập hệ điều hành. Bạn không SSH vào được, không cài gói nào, không sửa tệp cấu hình OS.
  • **C. Dùng cross-AZ read replica của RDS for Oracle — hai vấn đề: read replica không phải cơ chế sẵn sàng cao (failover thủ công), và vẫn không cho truy cập hệ điều hành.
  • **D. Triển khai Oracle trên nhiều EC2 instance qua hai AZ — đáp ứng vế tuỳ chỉnh nhưng vi phạm vế công bảo trì: bạn phải tự cài Oracle, tự cấu hình sao chép, tự dựng cơ chế failover, tự vá lỗi. Và câu "deployment configuration guarantees high availability" là sai — đặt hai máy ở hai AZ không tự động cho sẵn sàng cao; phải cấu hình Data Guard hoặc RAC.

Ghi nhớ

Ba lựa chọn chạy Oracle trên AWS — bảng cần thuộc: | Lựa chọn | Truy cập OS | Công bảo trì | Sẵn sàng cao | |---|---|---|---| | RDS for Oracle | ❌ | thấp nhất | Multi-AZ dựng sẵn | | RDS Custom for Oracle | ✅ | vừa | Multi-AZ dựng sẵn ← câu này | | Oracle trên EC2 | ✅ toàn quyền | cao nhất | tự dựng (Data Guard, RAC) |

Quy tắc chọn:

Không cần tuỳ chỉnh OS → RDS thường Cần tuỳ chỉnh OS nhưng vẫn muốn dịch vụ được quản lý → RDS Custom Cần Oracle RAC hoặc kiểm soát tuyệt đối → EC2

Ba khả năng riêng của RDS Custom: | Khả năng | Chi tiết | |---|---| | Truy cập hệ điều hành qua SSM Session Manager | quyền sudo | | Cài agent và gói phần mềm riêng | công cụ giám sát, backup của bên thứ ba | | Tuỳ chỉnh tham số ở cấp OS và database | thứ RDS thường khoá lại |

Và RDS Custom hỗ trợ hai engine:

RDS Custom for Oracle
RDS Custom for SQL Server

Ba đánh đổi khi dùng RDS Custom: | Đánh đổi | Chi tiết | |---|---| | Bạn chịu trách nhiệm về thay đổi mình làm | AWS không hỗ trợ nếu tuỳ chỉnh gây lỗi | | Có chế độ "support perimeter" | RDS Custom kiểm tra và có thể đánh dấu instance là không được hỗ trợ | | Đắt hơn RDS thường | thêm chi phí cho khả năng tuỳ chỉnh |

Dòng giữa đáng lưu ý: nếu bạn sửa thứ mà RDS Custom cần để hoạt động (ví dụ gỡ agent của nó), instance chuyển sang trạng thái unsupported-configuration và mất khả năng tự động hoá.

Ba việc RDS Custom vẫn tự động hoá: | Việc | Chi tiết | |---|---| | Sao lưu tự động và point-in-time recovery | như RDS thường | | Multi-AZ với failover tự động | | | Giám sát và metric | CloudWatch, Enhanced Monitoring |

Multi-AZ và Read Replica — nhắc lại vì phương án C nhắc tới: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | mở rộng đọc | | Failover | TỰ ĐỘNG | thủ công (promote) | | Standby phục vụ đọc | ❌ | ✅ | | Sao chép | đồng bộ | bất đồng bộ |

Ba lưu ý về giấy phép Oracle trên AWS: | Mô hình | Chi tiết | |---|---| | License Included | giá instance đã gồm giấy phép — chỉ Standard Edition Two | | Bring Your Own License (BYOL) | dùng giấy phép sẵn có | | Dedicated Host | cần cho giấy phép tính theo lõi VẬT LÝ |

Với Oracle Enterprise Edition, thường phải dùng BYOL — và điều đó ảnh hưởng tới lựa chọn kiến trúc.

Ba lựa chọn dài hạn đáng cân nhắc: | Lựa chọn | Lợi ích | |---|---| | Chuyển sang Aurora PostgreSQL với Babelfish | bỏ chi phí giấy phép Oracle | | Chuyển sang RDS thường nếu bỏ được tuỳ chỉnh | ít công hơn | | Giữ RDS Custom | cân bằng hiện tại |

Và AWS SCT + DMS là bộ công cụ chuẩn nếu quyết định chuyển đổi engine:

SCT: chuyển lược đồ và mã PL/SQL sang PL/pgSQL
DMS: chuyển dữ liệu với CDC, ít gián đoạn

Với ứng dụng y tế cũ nhiều tuỳ chỉnh, đây là dự án lớn — nhưng khoản tiết kiệm giấy phép Oracle thường rất đáng kể.

Ba lưu ý khi triển khai RDS Custom: | Lưu ý | Chi tiết | |---|---| | Cần IAM role và instance profile riêng | RDS Custom dùng chúng để quản lý | | Cần VPC endpoint hoặc NAT | cho SSM, S3, CloudWatch | | Ghi lại mọi tuỳ chỉnh đã làm | để tái tạo được khi cần dựng lại |

Và một lời khuyên: hãy ghi lại và tự động hoá các tuỳ chỉnh bằng script hoặc SSM document thay vì sửa tay. Với RDS Custom, instance có thể bị thay trong quá trình failover hoặc bảo trì — và tuỳ chỉnh không được tự động hoá sẽ mất theo.

Câu 414 Design High-Performing Architectures

A digital wallet company plans to launch a new cloud-based service for processing user cash transfers and peer-to-peer payments. The application will receive transaction requests from mobile clients via a secure endpoint. Each transaction request must go through a lightweight validation step before being forwarded for backend processing, which includes fraud detection, ledger updates, and notifications. The backend workload is compute- and memory-intensive, requires scaling based on volume, and must run for a longer duration than typical short-lived tasks. The engineering team prefers a fully managed solution that minimizes infrastructure maintenance, including provisioning and patching of virtual machines or containers.

Which solution will meet these requirements with the LEAST operational overhead?

  1. A

    Configure Amazon SQS to receive encrypted payment notifications from mobile devices. Use Amazon EventBridge rules to extract the payload and perform validation. Route the messages to a backend system hosted on Amazon Lightsail instances with dynamic scaling policies based on memory thresholds and instance health checks
  2. B

    Expose an Amazon API Gateway REST API endpoint to receive transaction requests from mobile clients. Integrate the API with AWS Lambda to perform basic validation. For backend processing, deploy the long-running application to Amazon ECS using the Fargate launch type, allowing ECS to manage compute and memory provisioning automatically, with no server management required
  3. C

    Create an Amazon API Gateway endpoint to receive transaction requests from mobile devices. Use AWS Lambda to validate the transactions. For backend processing, deploy the application on Amazon EKS Anywhere, running on on-premises servers in the company’s data center. Use a custom provisioning script to scale Kubernetes worker nodes based on transaction volume
  4. D

    Build a REST API using Amazon API Gateway. Integrate it with an AWS Step Functions state machine for validation. Launch the backend application using Amazon EKS with self-managed nodes, and use Kubernetes Jobs to handle transaction processing workflows. Manually scale the cluster based on demand
Xem giải thích

Đáp án

B — Phơi endpoint API Gateway REST API nhận yêu cầu giao dịch; tích hợp với AWS Lambda để kiểm tra sơ bộ; xử lý phía sau bằng Amazon ECS với Fargate launch type.

Vì sao đúng

Đề nêu năm yêu cầu, và đáp án ghép hai dịch vụ đúng cho hai loại việc: | Yêu cầu | Giải pháp | |---|---| | Endpoint an toàn nhận yêu cầu từ mobile | API Gateway | | Kiểm tra NHẸ trước khi chuyển tiếp | Lambda — nhanh, rẻ, tự co giãn | | Xử lý nền nặng CPU và bộ nhớ | Fargate — không giới hạn 15 phút | | Chạy LÂU HƠN tác vụ ngắn thông thường | Fargate không có giới hạn thời gian | | Được quản lý hoàn toàn, không vá máy | cả ba đều serverless |

Và điểm mấu chốt: hai loại việc cần hai công cụ khác nhau.

Kiểm tra nhẹ (vài trăm mili giây):
    → Lambda hoàn hảo — khởi động nhanh, trả tiền theo mili giây

Xử lý nền (phát hiện gian lận, cập nhật sổ cái, thông báo):
    → "compute- and memory-intensive"
    → "run for a LONGER DURATION than typical short-lived tasks"
        ↓
    → VƯỢT giới hạn 15 phút của Lambda
    → cần Fargate

Và Fargate là "fully managed" đúng nghĩa:

Fargate:
    ✓ không có EC2 instance nào để cấp phát
    ✓ không vá lỗi hệ điều hành
    ✓ mỗi task tự có vCPU và bộ nhớ riêng
    ✓ tự co giãn theo Service Auto Scaling

Kiến trúc đầy đủ:

Ứng dụng di động
    ↓ HTTPS
API Gateway (xác thực, giới hạn tốc độ, WAF)
    ↓
Lambda (kiểm tra định dạng, xác minh chữ ký)
    ↓ đẩy vào SQS
ECS Fargate task (phát hiện gian lận, sổ cái, thông báo)

Và đặt SQS ở giữa là mẫu nên có — nó tách rời hai tầng và hấp thụ đỉnh tải.

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

  • **D. API Gateway + Step Functions để kiểm tra; xử lý nền trên EKS với self-managed node, co giãn THỦ CÔNG — đây là phương án gần nhất vì cũng dùng API Gateway và container, nhưng nó vi phạm yêu cầu "least operational overhead": self-managed node nghĩa là bạn quản lý EC2, vá lỗi, và co giãn thủ công — ngược hẳn với "fully managed".
  • **C. API Gateway + Lambda; xử lý nền trên EKS Anywhere chạy tại trung tâm dữ liệu với script co giãn tự viết — đi ngược hoàn toàn: EKS Anywhere chạy trên hạ tầng của bạn — bạn lo phần cứng, mạng, điện. Và script co giãn tự viết là công vận hành lớn.
  • **A. Dùng SQS nhận thông báo từ thiết bị di động; EventBridge kiểm tra; xử lý trên Lightsail — hai lỗi: SQS không phải endpoint HTTPS cho ứng dụng di động gọi trực tiếp. Và Lightsail là máy ảo đơn giản hoá — bạn vẫn quản lý hệ điều hành, và nó không phải "fully managed".

Ghi nhớ

Chọn dịch vụ compute theo thời gian chạy — bảng cần thuộc: | Thời gian chạy | Dịch vụ | |---|---| | Dưới 15 phút, theo sự kiện | Lambda | | Chạy lâu, không giới hạn, không quản lý máy | Fargate | | Chạy lâu, cần kiểm soát hoặc GPU | ECS/EKS trên EC2 | | Xử lý lô hàng nghìn công việc | AWS Batch |

Giới hạn của Lambda — nhắc lại: | Giới hạn | Giá trị | |---|---| | Thời gian chạy | 15 phút | | Bộ nhớ | 10 GB | | vCPU | ~6 (theo bộ nhớ) | | Payload đồng bộ | 6 MB |

Giới hạn của Fargate: | Giới hạn | Giá trị | |---|---| | vCPU | 16 | | Bộ nhớ | 120 GB | | Thời gian chạy | không giới hạn | | Lưu trữ tạm | 20–200 GB |

Và Fargate có ràng buộc kết hợp CPU–bộ nhớ:

1 vCPU  → 2–8 GB
2 vCPU  → 4–16 GB
4 vCPU  → 8–30 GB
8 vCPU  → 16–60 GB
16 vCPU → 32–120 GB

Ba mức "được quản lý" — phân biệt rõ: | Mức | Ví dụ | |---|---| | Fully managed (serverless) | Lambda, Fargate, API Gateway, DynamoDB | | Managed nhưng bạn thấy máy | RDS, ElastiCache, EMR | | Bạn quản lý máy | EC2, Lightsail, EKS Anywhere, ECS trên EC2 |

Lightsail hay bị nhầm là serverless — nó là máy ảo với giá đơn giản hoá, bạn vẫn lo hệ điều hành.

Ba tính năng của API Gateway nên bật cho ứng dụng thanh toán: | Tính năng | Lý do | |---|---| | Xác thực (Cognito hoặc Lambda authorizer) | chỉ người dùng hợp lệ gửi giao dịch | | Throttling và usage plan | bảo vệ backend khỏi lạm dụng | | AWS WAF | chặn tấn công tầng 7 | | Request validation | loại payload sai định dạng sớm |

Hai loại API của API Gateway: | Loại | Đặc điểm | |---|---| | HTTP API | rẻ hơn ~70%, độ trễ thấp, ít tính năng | | REST API | đầy đủ: usage plan, caching, request validation, WAF |

Với ứng dụng thanh toán cần kiểm soát chặt, REST API thường là lựa chọn đúng — và đề cũng nêu rõ "REST API".

Ba lưu ý về giới hạn của API Gateway: | Giới hạn | Giá trị | |---|---| | Timeout tích hợp | 29 giây | | Payload | 10 MB | | Throttling mặc định | 10.000 request/giây |

Timeout 29 giây là lý do PHẢI tách xử lý nền ra:

Không thể để API Gateway chờ Fargate xử lý xong
    → phải trả về ngay một mã theo dõi
    → xử lý bất đồng bộ ở nền

Mẫu bất đồng bộ chuẩn:

API Gateway → Lambda: kiểm tra, đẩy vào SQS, trả về mã giao dịch (202 Accepted)
    ↓
SQS → Fargate service: xử lý nền
    ↓
Kết quả → DynamoDB → client hỏi lại bằng mã giao dịch, hoặc nhận push notification

Ba cách co giãn ECS Fargate: | Cách | Metric | |---|---| | Target tracking theo CPU hoặc bộ nhớ | mức dùng của task | | Target tracking theo ALBRequestCountPerTarget | số request | | Theo độ sâu hàng đợi SQS | phù hợp nhất với mô hình bất đồng bộ |

Và Fargate Spot giảm chi phí cho phần không thiết yếu:

{"capacityProviderStrategy": [
   {"capacityProvider": "FARGATE", "base": 2, "weight": 1},
   {"capacityProvider": "FARGATE_SPOT", "weight": 4}]}

Với giao dịch tài chính, giữ mức nền trên Fargate thường để đảm bảo luôn có năng lực xử lý.

Ba yêu cầu tuân thủ cho ví điện tử: | Yêu cầu | Chi tiết | |---|---| | PCI-DSS nếu xử lý thẻ | cân nhắc tokenization để thu hẹp phạm vi | | Mã hoá at rest và in transit | KMS + TLS | | Audit trail đầy đủ | CloudTrail, log của API Gateway và ứng dụng |

Và một lời khuyên: hãy dùng SQS FIFO cho hàng đợi giao dịch tài chính. Nó đảm bảo thứ tự và không trùng lặp — với việc chuyển tiền, xử lý một giao dịch hai lần là hậu quả rất khó khắc phục.

Câu 415 Design Secure Architectures

A software company has a globally distributed team of developers, that requires secure and compliant access to AWS environments. The company manages multiple AWS accounts under AWS Organizations and uses an on-premises Microsoft Active Directory for user authentication. To simplify access control and identity governance across projects and accounts, the company wants a centrally managed solution that integrates with their existing infrastructure. The solution should require the least amount of ongoing operational management.

Which approach best meets the company’s requirements?

  1. A

    Use AWS Control Tower to enable account access for developers. Create AWS IAM roles in each member account and manually assign permissions. Instruct developers to assume roles across accounts using the AWS CLI
  2. B

    Use AWS Directory Service AD Connector to connect AWS to the on-premises Active Directory. Integrate AD Connector with AWS IAM Identity Center. Use permission sets to assign access to AWS accounts and resources based on Active Directory group membership
  3. C

    Deploy AWS Directory Service for Microsoft Active Directory in AWS. Establish a trust relationship with the on-premises Active Directory. Use IAM roles linked to AD groups to control access to AWS resources
  4. D

    Deploy an open-source identity provider (IdP) on Amazon EC2. Synchronize it with the on-premises Active Directory and use SAML to federate access to AWS accounts. Assign IAM roles to federated users based on SAML assertions
Xem giải thích

Đáp án

B — Dùng AWS Directory Service AD Connector kết nối AWS với Active Directory tại chỗ; tích hợp AD Connector với IAM Identity Center; dùng permission set để cấp quyền theo nhóm Active Directory.

Vì sao đúng

Đề nêu bốn yêu cầu, và đáp án đáp ứng đủ với ít công nhất: | Yêu cầu | Cơ chế | |---|---| | Nhiều tài khoản AWS trong Organizations | IAM Identity Center quản lý tập trung | | Dùng Active Directory TẠI CHỖ sẵn có | AD Connector — cầu nối, không nhân bản dữ liệu | | Quản lý truy cập tập trung | permission set gán cho nhóm × tài khoản | | ÍT công vận hành nhất | không dựng hạ tầng danh tính mới |

AD Connector là cầu nối, không lưu dữ liệu:

AD Connector:
    → chuyển tiếp yêu cầu xác thực về AD TẠI CHỖ
    → KHÔNG sao chép người dùng hay mật khẩu lên AWS
    → không có AD nào để vận hành trên AWS

Và IAM Identity Center dùng nhóm AD để gán quyền:

Nhóm AD "KySuHaTang"
    → gán permission set "QuanTriHaTang" cho tài khoản Production
    → gán permission set "ReadOnly" cho tài khoản Audit
        ↓
    Thêm người vào nhóm AD → tự có quyền tương ứng
    Xoá khỏi nhóm → mất quyền ngay

Và thông tin đăng nhập là TẠM THỜI:

Lập trình viên đăng nhập portal của Identity Center
    → chọn tài khoản và vai
    → nhận thông tin đăng nhập ngắn hạn qua STS
    → KHÔNG có access key dài hạn nào

aws sso-admin create-permission-set   --instance-arn <arn-identity-center>   --name QuanTriHaTang --session-duration PT4H

aws sso-admin create-account-assignment   --instance-arn <arn> --permission-set-arn <arn-ps>   --principal-type GROUP --principal-id <id-nhom-ad>   --target-id 111122223333 --target-type AWS_ACCOUNT

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

  • **C. Triển khai AWS Managed Microsoft AD trên AWS và tạo trust relationship với AD tại chỗ; dùng IAM role gắn với nhóm AD — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó nhiều công hơn: phải vận hành một AD thật trên AWS, thiết lập và duy trì quan hệ tin cậy hai chiều, và tự quản lý IAM role ở từng tài khoản thay vì dùng permission set tập trung.
  • **A. Dùng Control Tower rồi tạo IAM role ở TỪNG tài khoản và gán quyền THỦ CÔNG — vi phạm yêu cầu ít công nhất: gán quyền thủ công ở mỗi tài khoản không mở rộng được với đội ngũ phân tán toàn cầu.
  • **D. Triển khai IdP mã nguồn mở trên EC2, đồng bộ với AD và liên kết qua SAML — nhiều công nhất: phải vận hành, vá lỗi, và đảm bảo sẵn sàng cao cho một hệ thống danh tính tự quản lý — thứ có rủi ro cao nếu hỏng.

Ghi nhớ

Bốn nguồn danh tính của IAM Identity Center: | Nguồn | Phù hợp | |---|---| | Identity Center directory | tổ chức chưa có hệ thống danh tính | | AWS Managed Microsoft AD | cần AD hoạt động ĐỘC LẬP trên AWS | | AD Connector | AD tại chỗ là nguồn duy nhất ← câu này | | IdP hỗ trợ SAML 2.0 | Okta, Entra ID, Google Workspace, Ping |

Ba lựa chọn của AWS Directory Service: | Lựa chọn | Lưu dữ liệu trên AWS | Hoạt động khi mất kết nối | |---|---|---| | AWS Managed Microsoft AD | ✅ AD thật trên AWS | ✅ độc lập | | AD Connector | ❌ chỉ chuyển tiếp | ❌ ngừng xác thực | | Simple AD | ✅ (tương thích Samba) | ✅ |

Đánh đổi của AD Connector:

Ưu: không nhân bản dữ liệu danh tính lên đám mây
     (tốt cho tuân thủ), ít công vận hành

Nhược: VPN hoặc Direct Connect đứt
       → lập trình viên KHÔNG đăng nhập được vào AWS

Với môi trường quan trọng, Managed Microsoft AD với trust hai chiều an toàn hơn.

Ba khái niệm của IAM Identity Center: | Khái niệm | Việc | |---|---| | Identity source | nơi lấy danh tính | | Permission set | tập policy — trở thành IAM role trong tài khoản đích | | Assignment | (người dùng hoặc nhóm) × (permission set) × (tài khoản) |

Cách permission set hoạt động bên dưới:

Gán permission set cho nhóm ở tài khoản X
    → Identity Center TỰ TẠO một IAM role trong tài khoản X
    → người dùng đăng nhập → đảm nhận role đó qua STS
    → nhận thông tin đăng nhập tạm thời

Bạn không phải tạo hay quản lý role đó.

IAM Identity Center và IAM user — bảng phân biệt: | | Identity Center | IAM user | |---|---|---| | Thông tin đăng nhập | TẠM THỜI, tự hết hạn | dài hạn | | Quản lý nhiều tài khoản | ✅ tập trung | mỗi tài khoản riêng | | Người nghỉ việc | xoá ở một chỗ | phải xoá ở từng tài khoản | | MFA | quản lý tập trung | từng người tự cấu hình | | Trạng thái | được khuyến nghị | trường hợp đặc biệt |

AWS khuyến nghị Identity Center thay IAM user cho MỌI truy cập của con người.

Ba loại policy trong permission set: | Loại | Chi tiết | |---|---| | AWS managed policy | policy có sẵn | | Customer managed policy | phải TỒN TẠI ở từng tài khoản đích với cùng tên | | Inline policy | viết trực tiếp trong permission set | | Permissions boundary | giới hạn quyền tối đa |

Và đăng nhập qua CLI rất tiện:

aws configure sso
aws sso login --profile san-xuat

Thông tin đăng nhập tự hết hạn theo session-duration — không có access key nào để rò rỉ.

Ba lưu ý về session-duration: | Lưu ý | Chi tiết | |---|---| | Mặc định 1 giờ, tối đa 12 giờ | định dạng ISO 8601 (PT4H) | | Ngắn hơn = an toàn hơn | nhưng bất tiện hơn | | Cân bằng theo mức nhạy cảm của tài khoản | prod ngắn, dev dài hơn |

Ba biện pháp bổ sung cho tổ chức đa quốc gia: | Biện pháp | Chi tiết | |---|---| | SCP giới hạn Region được dùng | tuân thủ về vị trí dữ liệu | | MFA bắt buộc | cấu hình ở Identity Center | | Attribute-based access control (ABAC) | dùng thuộc tính AD làm điều kiện trong policy |

ABAC với Identity Center rất mạnh:

{"Effect": "Allow", "Action": "ec2:*", "Resource": "*",
 "Condition": {"StringEquals":
   {"ec2:ResourceTag/PhongBan": "${aws:PrincipalTag/PhongBan}"}}}

Thuộc tính PhongBan lấy từ AD — một permission set phục vụ mọi phòng ban.

Ba yêu cầu mạng cho AD Connector: | Yêu cầu | Chi tiết | |---|---| | Kết nối tới AD tại chỗ | VPN hoặc Direct Connect | | Mở các cổng AD | 389/636 (LDAP), 88 (Kerberos), 53 (DNS) | | Hai subnet ở hai AZ | yêu cầu của dịch vụ |

Và một lời khuyên về sẵn sàng: AD Connector phụ thuộc hoàn toàn vào kết nối tới trung tâm dữ liệu. Hãy đảm bảo có đường dự phòng (VPN backup cho Direct Connect) — nếu không, một sự cố mạng ở trụ sở sẽ khiến toàn bộ đội ngũ toàn cầu không đăng nhập được vào AWS.

Câu 416 Design Secure Architectures

A US-based healthcare startup is building an interactive diagnostic tool for COVID-19 related assessments. The users would be required to capture their personal health records via this tool. As this is sensitive health information, the backup of the user data must be kept encrypted in Amazon Simple Storage Service (Amazon S3). The startup does not want to provide its own encryption keys but still wants to maintain an audit trail of when an encryption key was used and by whom.

Which of the following is the BEST solution for this use-case?

  1. A

    Use server-side encryption with customer-provided keys (SSE-C) to encrypt the user data on Amazon S3
  2. B

    Use client-side encryption with client provided keys and then upload the encrypted user data to Amazon S3
  3. C

    Use server-side encryption with Amazon S3 managed keys (SSE-S3) to encrypt the user data on Amazon S3
  4. D

    Use server-side encryption with AWS Key Management Service keys (SSE-KMS) to encrypt the user data on Amazon S3
Xem giải thích

Đáp án

D — Dùng server-side encryption với AWS KMS keys (SSE-KMS) để mã hoá dữ liệu người dùng trên S3.

Vì sao đúng

Đề nêu ba yêu cầu, và SSE-KMS là lựa chọn duy nhất thoả cả ba: | Yêu cầu | Cơ chế | |---|---| | Dữ liệu sao lưu phải MÃ HOÁ trên S3 | mọi phương án SSE đều làm được | | KHÔNG muốn tự cung cấp khoá | loại SSE-C và client-side encryption | | CÓ audit trail: ai dùng khoá, khi nào | CHỈ SSE-KMS có |

Vế thứ ba là điểm phân biệt tuyệt đối:

SSE-KMS:
    → mỗi lời gọi Encrypt và Decrypt được ghi vào CloudTrail
    → biết CHÍNH XÁC: principal nào, object nào, lúc nào, từ IP nào

SSE-S3:
    → AWS quản lý khoá hoàn toàn
    → KHÔNG có bản ghi nào về việc dùng khoá

Ví dụ bản ghi CloudTrail cho SSE-KMS:

{"eventName": "Decrypt",
 "userIdentity": {"arn": "arn:aws:sts::...:assumed-role/vai-tro-ung-dung/i-0abc"},
 "requestParameters": {"encryptionContext": {
     "aws:s3:arn": "arn:aws:s3:::kho-ho-so-suc-khoe/benh-nhan-001.json"}},
 "sourceIPAddress": "10.0.1.25"}

Trường encryptionContext cho biết chính xác object nào được giải mã.

Và vế "không muốn cung cấp khoá riêng" được đáp ứng:

SSE-KMS:
    → AWS KMS tạo và lưu vật liệu khoá
    → bạn chỉ kiểm soát CHÍNH SÁCH và xoay vòng
    → không phải tự sinh, tự lưu, tự gửi khoá

Cấu hình mã hoá mặc định cho bucket:

aws s3api put-bucket-encryption --bucket kho-ho-so-suc-khoe   --server-side-encryption-configuration '{
    "Rules": [{"ApplyServerSideEncryptionByDefault":
      {"SSEAlgorithm": "aws:kms", "KMSMasterKeyID": "<arn-khoa>"},
      "BucketKeyEnabled": true}]}'

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

  • **C. Dùng SSE-S3 — đây là phương án gần nhất và cũng là mã hoá phía máy chủ do AWS quản lý khoá, nhưng nó thiếu vế audit: SSE-S3 không ghi lại việc dùng khoá. Với dữ liệu sức khoẻ, câu hỏi "ai đã giải mã hồ sơ bệnh nhân nào" thường là thứ kiểm toán viên hỏi đầu tiên.
  • **A. Dùng SSE-C (khoá do khách hàng cung cấp) — vi phạm yêu cầu: đề nói rõ startup không muốn tự cung cấp khoá. SSE-C bắt bạn gửi khoá theo mỗi request, và AWS không lưu khoá nên cũng không có audit trail.
  • **B. Dùng client-side encryption với khoá của client — vi phạm nhiều nhất: bạn phải tự sinh, tự lưu, tự xoay vòng khoá, và tự viết logic mã hoá. Không có audit trail của AWS.

Ghi nhớ

Bốn cách mã hoá S3 — bảng cần thuộc: | Cách | Ai quản lý khoá | Audit ai giải mã | Chi phí | |---|---|---|---| | SSE-S3 | AWS hoàn toàn | ❌ | miễn phí | | SSE-KMS | KMS, bạn kiểm soát policy | ✅ CloudTrail | phí KMS | | DSSE-KMS | KMS, mã hoá HAI lớp | ✅ | phí cao hơn | | SSE-C | BẠN — gửi theo mỗi request | ❌ | miễn phí | | Client-side | BẠN hoàn toàn | ❌ | miễn phí |

Từ khoá nhận diện trong đề thi:

"audit trail", "who used the key", "when" → SSE-KMS "don't want to manage keys", "simplest" → SSE-S3 "full control of keys", "keys never leave my premises" → client-side

Giá trị header tương ứng: | Cách | Header | |---|---| | SSE-S3 | AES256 | | SSE-KMS | aws:kms | | DSSE-KMS | aws:kms:dsse |

Hai giá trị này hay bị nhầm và là chi tiết phân biệt trong nhiều câu hỏi.

Ba loại khoá KMS: | Loại | Chi phí | Kiểm soát | |---|---|---| | AWS managed key (aws/s3) | miễn phí lưu | không đổi được policy | | Customer managed key | ~1 USD/tháng | đầy đủ: policy, xoay vòng, vô hiệu hoá | | AWS owned key | miễn phí | AWS dùng nội bộ |

Với dữ liệu sức khoẻ, customer managed key là lựa chọn đúng — nó cho phép đặt key policy riêng và có audit chi tiết hơn.

Và bật S3 Bucket Keys giảm mạnh chi phí KMS:

{"BucketKeyEnabled": true}

Nó dùng một khoá cấp bucket để giảm tới 99% số lời gọi KMS — nên bật cho mọi bucket dùng SSE-KMS.

Ba chi phí của KMS: | Khoản | Chi tiết | |---|---| | Lưu khoá | ~1 USD/khoá/tháng (customer managed) | | Lời gọi API | ~0,03 USD mỗi 10.000 lời gọi | | Bucket Keys | giảm mạnh khoản thứ hai |

Ba biện pháp bảo mật bổ sung cho dữ liệu sức khoẻ: | Biện pháp | Cấu hình | |---|---| | Bắt buộc mã hoá bằng bucket policy | chặn PutObject không có header đúng | | Bắt buộc HTTPS | điều kiện aws:SecureTransport | | Block Public Access ở mức tài khoản | ngăn cấu hình sai | | Bật CloudTrail data event | ghi mọi thao tác object-level |

Chính sách bắt buộc SSE-KMS:

{"Effect": "Deny", "Principal": "*", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::kho-ho-so-suc-khoe/*",
 "Condition": {"StringNotEquals":
   {"s3:x-amz-server-side-encryption": "aws:kms"}}}

Nhớ thêm statement thứ hai chặn request thiếu hẳn header:

{"Condition": {"Null": {"s3:x-amz-server-side-encryption": "true"}}}

Và CloudTrail data event bổ sung cho audit của KMS:

KMS CloudTrail:      ai GIẢI MÃ (dùng khoá)
S3 data event:       ai ĐỌC object (kể cả khi không mã hoá)
    → hai nguồn bổ sung nhau

Ba yêu cầu tuân thủ HIPAA: | Yêu cầu | Chi tiết | |---|---| | Ký BAA với AWS | bắt buộc về pháp lý cho PHI | | Chỉ dùng dịch vụ đủ điều kiện HIPAA | S3, KMS, CloudTrail đều nằm trong danh sách | | Mã hoá at rest và in transit | SSE-KMS + TLS |

Và key policy là chỗ hay gây lỗi AccessDenied:

Quyền dùng khoá = CẢ key policy LẪN IAM policy
    → cấp kms:Decrypt trong IAM là CHƯA ĐỦ
    → key policy cũng phải cho phép principal đó

Ba lưu ý về xoay vòng khoá: | Lưu ý | Chi tiết | |---|---| | Bật xoay vòng tự động hằng năm | aws kms enable-key-rotation | | Vật liệu khoá cũ được GIỮ LẠI | để giải mã dữ liệu cũ | | Trong suốt với ứng dụng | không phải mã hoá lại gì |

Và một lời khuyên: hãy bật MFA Delete và versioning cho bucket chứa hồ sơ sức khoẻ. Mã hoá bảo vệ dữ liệu khỏi bị đọc, nhưng không bảo vệ khỏi bị xoá — và với dữ liệu y tế, mất dữ liệu cũng nghiêm trọng như lộ dữ liệu.

Câu 417 Design Cost-Optimized Architectures

A video analytics company runs data-intensive batch processing workloads that generate large log files and metadata daily. These files are currently stored in an on-premises NFS-based storage system located in the company's primary data center. However, the storage system is becoming increasingly difficult to scale and is unable to meet the company's growing storage demands. The IT team wants to migrate to a cloud-based storage solution that minimizes costs, retains NFS compatibility, and supports automated tiering of rarely accessed data to lower-cost storage. The team prefers to continue using existing NFS-based tools and protocols for compatibility with their current application stack.

Which solution will meet these requirements MOST cost-effectively?

  1. A

    Provision an Amazon Elastic File System (Amazon EFS) file system with the One Zone–IA storage class. Use AWS DataSync to migrate the NFS data to EFS. Configure the application to mount the file system over NFS and activate lifecycle management to tier infrequently accessed files
  2. B

    Deploy an AWS Storage Gateway Volume Gateway in cached mode. Attach it as a block device to an on-premises file server and mount NFS on top. Store snapshots in Amazon S3 Glacier Deep Archive, and use AWS Backup to manage recovery operations and tiering
  3. C

    Deploy an AWS Storage Gateway File Gateway on premises. Configure it to present an NFS-compatible file share to the workloads. Store the uploaded files in Amazon S3, and use S3 Lifecycle policies to automatically transition infrequently accessed objects to lower-cost storage classes
  4. D

    Use Amazon FSx for Windows File Server to replace the NFS workload. Enable data deduplication and automatic backups. Use Amazon S3 Glacier to move snapshots to a cost-efficient storage tier. Reconfigure the analytics application to access files using SMB protocol
Xem giải thích

Đáp án

C — Triển khai AWS Storage Gateway File Gateway tại chỗ, cấu hình phơi ra NFS file share; lưu tệp vào Amazon S3 và dùng S3 Lifecycle policy tự chuyển dữ liệu ít truy cập sang lớp lưu trữ rẻ hơn.

Vì sao đúng

Đề nêu bốn yêu cầu, và File Gateway đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Giữ tương thích NFS, dùng công cụ hiện có | File Gateway phơi ra NFS file share | | Mở rộng không giới hạn | S3 làm nền — dung lượng vô hạn | | Tự phân tầng dữ liệu ít truy cập | S3 Lifecycle policy | | Tiết kiệm nhất | S3 rẻ hơn EFS khoảng 10 lần |

Cách File Gateway hoạt động:

Ứng dụng tại chỗ mount NFS share
    → ghi tệp như ổ đĩa mạng bình thường
        ↓
File Gateway đồng bộ lên S3
    → MỖI TỆP = MỘT OBJECT trong S3
    → giữ nguyên cấu trúc thư mục
    → cache cục bộ giữ dữ liệu hay dùng

Và mỗi tệp là một object S3 nên lifecycle rule áp trực tiếp:

{"Rules": [{
  "Status": "Enabled", "Filter": {},
  "Transitions": [
    {"Days": 30, "StorageClass": "STANDARD_IA"},
    {"Days": 90, "StorageClass": "GLACIER_IR"},
    {"Days": 365, "StorageClass": "DEEP_ARCHIVE"}]}]}

So sánh chi phí — đây là điểm quyết định:

Amazon EFS Standard:     ~0,30 USD/GB-tháng
Amazon EFS One Zone-IA:  ~0,016 USD/GB-tháng
S3 Standard:             ~0,023 USD/GB-tháng
S3 Standard-IA:          ~0,0125 USD/GB-tháng
S3 Glacier Deep Archive: ~0,00099 USD/GB-tháng

Với dữ liệu tăng liên tục và phần lớn ít truy cập, S3 với lifecycle rẻ hơn rất nhiều.

Và vế "giữ NFS" được đáp ứng nguyên vẹn — ứng dụng không biết dữ liệu thật nằm ở S3.

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

  • **A. Dùng EFS với lớp One Zone-IA và DataSync để di chuyển — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó đắt hơn và không giải quyết vế "tại chỗ": EFS nằm trong VPC, và mount từ trung tâm dữ liệu qua Direct Connect có độ trễ cao vì không có cache cục bộ. Và EFS đắt hơn S3 đáng kể ngay cả ở lớp IA.
  • **B. Dùng Volume Gateway ở chế độ cached, gắn làm thiết bị khối rồi mount NFS lên trên — vòng vo và phức tạp: Volume Gateway dùng iSCSI (giao thức KHỐI). Bạn phải tự dựng một máy chủ tệp lên trên nó để phơi NFS — thêm một thành phần phải quản lý mà File Gateway đã làm sẵn.
  • **D. Dùng FSx for Windows File Server và cấu hình lại ứng dụng dùng SMB — vi phạm yêu cầu rõ ràng nhất: đề nói muốn giữ NFS và công cụ hiện có. Chuyển sang SMB đòi sửa toàn bộ ứng dụng.

Ghi nhớ

Ba loại Storage Gateway — bảng cần thuộc: | Loại | Giao thức | Đích | Dùng cho | |---|---|---|---| | File Gateway | NFS, SMB | S3 | chia sẻ tệp, kho dữ liệu ← câu này | | Volume Gateway | iSCSI | S3 dạng EBS snapshot | ổ đĩa khối cho ứng dụng | | Tape Gateway | iSCSI VTL | S3 Glacier | thay thư viện băng từ |

Từ khoá nhận diện:

"NFS", "SMB", "file share", "keep existing tools" → File Gateway "iSCSI", "block volume" → Volume Gateway "tape", "backup software" → Tape Gateway

Ba đặc điểm quan trọng của S3 File Gateway: | Đặc điểm | Chi tiết | |---|---| | Mỗi tệp = một object S3 | truy cập được bằng CẢ NFS LẪN S3 API | | Cache cục bộ | dữ liệu hay dùng đọc nhanh như đĩa nội bộ | | Tích hợp lifecycle của S3 | tự phân tầng — đúng yêu cầu của đề |

Dòng đầu là lợi ích chiến lược lớn nhất:

Dữ liệu vừa dùng được như tệp tại chỗ
    vừa xử lý được bằng Athena, Glue, EMR, học máy
    → mà không cần bước chuyển đổi nào

Với công ty phân tích video, đó là mở ra cả một tầng khả năng mới.

Các lớp lưu trữ S3 và lifecycle: | Lớp | Truy xuất | Chi phí | |---|---|---| | Standard | tức thì | ~0,023 USD/GB | | Standard-IA | tức thì | ~0,0125 USD/GB | | Glacier Instant Retrieval | mili giây | ~0,004 USD/GB | | Glacier Flexible | 1 phút – 12 giờ | ~0,0036 USD/GB | | Deep Archive | 12–48 giờ | ~0,00099 USD/GB |

Và ràng buộc thời gian lưu tối thiểu:

Standard-IA:      30 ngày
Glacier IR/Flex:  90 ngày
Deep Archive:     180 ngày

Ba lưu ý khi dùng File Gateway với lifecycle: | Lưu ý | Chi tiết | |---|---| | Tệp chuyển sang Glacier KHÔNG đọc trực tiếp qua NFS được | phải RESTORE trước | | Nên dùng Glacier Instant Retrieval cho dữ liệu còn có thể cần | truy xuất mili giây | | Deep Archive chỉ cho dữ liệu gần như không đọc | chờ 12–48 giờ |

Dòng đầu rất quan trọng: nếu người dùng mở một tệp đã chuyển sang Glacier Flexible qua NFS share, thao tác sẽ thất bại chứ không tự động chờ.

Ba yêu cầu triển khai File Gateway: | Yêu cầu | Chi tiết | |---|---| | Nền tảng chạy gateway | VMware, Hyper-V, KVM, EC2, hoặc thiết bị phần cứng | | Đĩa cho CACHE | kích thước quyết định trải nghiệm đọc | | Đĩa cho upload buffer | vùng đệm chờ đẩy lên S3 |

Kích thước cache là yếu tố quyết định:

Cache nhỏ hơn tập dữ liệu nóng
    → mọi lần đọc phải lấy từ S3
    → mất hết lợi ích của mô hình

Ba metric cần theo dõi: | Metric | Ý nghĩa | |---|---| | CacheHitPercent | thấp nghĩa là cache quá nhỏ | | CachePercentUsed | gần đầy thì cần mở rộng | | UploadBufferPercentUsed | buffer đầy sẽ chặn việc ghi |

Các dịch vụ lưu trữ lai — chọn đúng: | Dịch vụ | Phù hợp | |---|---| | Storage Gateway | truy cập LIÊN TỤC — tại chỗ dùng, dữ liệu ở AWS ← câu này | | DataSync | DI CHUYỂN hoặc đồng bộ định kỳ | | Snow Family | khối lượng rất lớn, băng thông kém | | FSx File Gateway | truy cập FSx for Windows từ tại chỗ |

Và DataSync + Storage Gateway thường dùng CÙNG NHAU:

DataSync chuyển khối lượng ban đầu (nhanh hơn nhiều)
    ↓
File Gateway phục vụ truy cập hằng ngày sau đó

Ba biện pháp bảo vệ dữ liệu trên bucket đích: | Biện pháp | Chống lại | |---|---| | Versioning | ghi đè và xoá nhầm | | Cross-Region Replication | sự cố cả Region | | Object Lock | xoá cố ý, ransomware |

Và lifecycle rule bắt buộc cho mọi bucket:

{"AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}

Và một lời khuyên về băng thông: đặt giới hạn băng thông theo lịch cho gateway để việc đẩy dữ liệu lên S3 không nghẽn đường truyền trong giờ làm việc. Với công ty tạo ra hàng terabyte log mỗi ngày, đó là thiết lập cần thiết ngay từ đầu.

Câu 418 Design High-Performing Architectures

The product team at a startup has figured out a market need to support both stateful and stateless client-server communications via the application programming interface (APIs) developed using its platform. You have been hired by the startup as a solutions architect to build a solution to fulfill this market need using Amazon API Gateway.

Which of the following would you identify as correct?

  1. A

    Amazon API Gateway creates RESTful APIs that enable stateless client-server communication and Amazon API Gateway also creates WebSocket APIs that adhere to the WebSocket protocol, which enables stateful, full-duplex communication between client and server
  2. B

    Amazon API Gateway creates RESTful APIs that enable stateful client-server communication and Amazon API Gateway also creates WebSocket APIs that adhere to the WebSocket protocol, which enables stateless, full-duplex communication between client and server
  3. C

    Amazon API Gateway creates RESTful APIs that enable stateful client-server communication and Amazon API Gateway also creates WebSocket APIs that adhere to the WebSocket protocol, which enables stateful, full-duplex communication between client and server
  4. D

    Amazon API Gateway creates RESTful APIs that enable stateless client-server communication and Amazon API Gateway also creates WebSocket APIs that adhere to the WebSocket protocol, which enables stateless, full-duplex communication between client and server
Xem giải thích

Đáp án

A — API Gateway tạo RESTful API cho giao tiếp KHÔNG TRẠNG THÁI (stateless), và tạo WebSocket API theo giao thức WebSocket cho giao tiếp CÓ TRẠNG THÁI (stateful), song công đầy đủ (full-duplex).

Vì sao đúng

Câu hỏi kiểm tra hai khái niệm căn bản, và đáp án gán đúng cả hai.

REST là KHÔNG TRẠNG THÁI theo định nghĩa:

Mỗi request HTTP là ĐỘC LẬP
    → chứa đủ mọi thông tin cần thiết
    → máy chủ KHÔNG nhớ gì về request trước
        ↓
    Đó là nguyên tắc kiến trúc cốt lõi của REST

WebSocket là CÓ TRẠNG THÁI và SONG CÔNG:

Client và máy chủ mở MỘT kết nối và GIỮ NÓ
    → kết nối tồn tại qua nhiều lượt trao đổi (có trạng thái)
    → CẢ HAI bên gửi được bất cứ lúc nào (song công đầy đủ)
        ↓
    Máy chủ ĐẨY dữ liệu tới client mà không cần client hỏi

Bảng phân biệt: | | REST API | WebSocket API | |---|---|---| | Trạng thái | KHÔNG trạng thái | CÓ trạng thái | | Chiều giao tiếp | client hỏi, máy chủ trả | SONG CÔNG — cả hai chủ động | | Kết nối | mở rồi đóng mỗi request | giữ lâu dài | | Phù hợp | CRUD, API thông thường | chat, thông báo thời gian thực, bảng giá trực tuyến |

Ba route dựng sẵn của WebSocket API: | Route | Khi nào | |---|---| | $connect | client mở kết nối — xác thực ở đây | | $disconnect | client đóng kết nối | | $default | thông điệp không khớp route nào |

Và máy chủ đẩy dữ liệu tới client bằng connection ID:

apigw = boto3.client('apigatewaymanagementapi',
                     endpoint_url=f'https://{domain}/{stage}')
apigw.post_to_connection(ConnectionId=ma_ket_noi,
                         Data=json.dumps({'gia': 25000}))

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

  • **C. REST là CÓ trạng thái và WebSocket là CÓ trạng thái — đây là phương án gần nhất vì vế WebSocket đúng, nhưng nó sai vế REST: không trạng thái là nguyên tắc định nghĩa của REST.
  • **B. REST CÓ trạng thái và WebSocket KHÔNG trạng thái — đảo ngược cả hai.
  • **D. Cả hai đều KHÔNG trạng thái — sai vế WebSocket: kết nối được duy trì chính là trạng thái.

Ghi nhớ

Ba loại API của Amazon API Gateway: | Loại | Giao thức | Trạng thái | |---|---|---| | REST API | HTTP/HTTPS | không trạng thái | | HTTP API | HTTP/HTTPS | không trạng thái | | WebSocket API | WebSocket (wss://) | có trạng thái |

REST API và HTTP API — bảng phân biệt: | | REST API | HTTP API | |---|---|---| | Chi phí | cao hơn | rẻ hơn ~70% | | Độ trễ | cao hơn | thấp hơn | | Usage plan và API key | ✅ | ❌ | | Caching | ✅ | ❌ | | Request validation | ✅ | hạn chế | | AWS WAF | ✅ | ❌ | | Private API trong VPC | ✅ | ❌ | | Xác thực | IAM, Cognito, Lambda authorizer | thêm JWT authorizer |

Quy tắc chọn:

API đơn giản, ưu tiên chi phí và độ trễ → HTTP API Cần usage plan, caching, WAF, private endpoint → REST API Cần đẩy dữ liệu tới client thời gian thực → WebSocket API

Ba ứng dụng của WebSocket API: | Ứng dụng | Chi tiết | |---|---| | Chat và nhắn tin | hai chiều tự nhiên | | Bảng giá, tỷ số trực tiếp | máy chủ đẩy cập nhật | | Cộng tác thời gian thực | nhiều người sửa cùng tài liệu | | Thông báo trong ứng dụng | không cần polling |

Và WebSocket thay thế được mẫu polling kém hiệu quả:

Polling:    client hỏi mỗi 5 giây → 99% lần trả về "không có gì mới"
WebSocket:  máy chủ đẩy khi CÓ dữ liệu → không lãng phí request

Ba lưu ý về WebSocket API: | Lưu ý | Chi tiết | |---|---| | Thời gian kết nối tối đa 2 GIỜ | client phải kết nối lại | | Idle timeout 10 phút | gửi ping định kỳ để giữ kết nối | | Phải tự lưu connection ID | thường lưu trong DynamoDB |

Mẫu lưu connection ID:

# Route $connect
bang.put_item(Item={'ma_ket_noi': event['requestContext']['connectionId'],
                    'ma_nguoi_dung': ma_nguoi_dung,
                    'het_han': int(time.time()) + 7200})
# Route $disconnect
bang.delete_item(Key={'ma_ket_noi': ...})

Bật TTL trên bảng để tự dọn kết nối chết — client mất mạng đột ngột không luôn gửi $disconnect.

Ba lựa chọn khác cho giao tiếp thời gian thực trên AWS: | Lựa chọn | Đặc điểm | |---|---| | API Gateway WebSocket | tự kiểm soát hoàn toàn ← câu này | | AWS AppSync subscription | GraphQL — subscription dựng sẵn, ít mã hơn | | AWS IoT Core (MQTT over WebSocket) | tối ưu cho thiết bị, có device shadow |

AppSync đáng cân nhắc nếu ứng dụng đã dùng GraphQL — subscription tự hoạt động khi có mutation, không phải tự quản lý connection ID.

Ba lưu ý về tính không trạng thái của REST: | Lưu ý | Chi tiết | |---|---| | Trạng thái phiên phải ở NGOÀI máy chủ | ElastiCache, DynamoDB, hoặc JWT | | Đó là điều kiện để co giãn ngang | mọi máy chủ tương đương | | Cookie hay token KHÔNG làm REST thành có trạng thái | trạng thái nằm ở client, không ở máy chủ |

Dòng cuối là điểm hay bị hiểu nhầm: REST vẫn không trạng thái ngay cả khi dùng token xác thực — vì token do client gửi kèm mỗi request, máy chủ không nhớ gì.

Ba cách tính phí của API Gateway: | Loại | Giá tham khảo | |---|---| | REST API | ~3,50 USD/triệu request | | HTTP API | ~1,00 USD/triệu request | | WebSocket API | ~1,00 USD/triệu thông điệp + phí PHÚT KẾT NỐI |

Phí phút kết nối của WebSocket đáng lưu ý — với nhiều client giữ kết nối lâu, khoản này có thể lớn hơn phí thông điệp.

Và một lời khuyên về thiết kế: hãy dùng cả hai loại API cùng nhau — REST cho các thao tác CRUD thông thường, WebSocket chỉ cho phần thực sự cần đẩy dữ liệu. Dùng WebSocket cho mọi thứ khiến kiến trúc phức tạp hơn cần thiết và tốn phí kết nối không đáng.

Câu 419 Design Resilient Architectures

A healthcare analytics company centralizes clinical and operational datasets in an Amazon S3–based data lake. Incoming data is ingested in Apache Parquet format from multiple hospitals and wearable health devices. To ensure quality and standardization, the company applies several transformation steps: anomaly filtering, datetime normalization, and aggregation by patient cohort. The company needs a solution to support a code-free interface that enables data engineers and business analysts to collaborate on data preparation workflows. The company also requires data lineage tracking, data profiling capabilities, and an easy way to share transformation logic across teams without writing or managing code.

Which AWS solution best meets these requirements?

  1. A

    Use Amazon AppFlow to move and transform Parquet files in S3. Configure AppFlow transformations and mappings within the visual interface. Share flows with collaborators through AWS IAM policies and scheduled executions
  2. B

    Use AWS Glue Studio’s visual canvas to design data transformation workflows on top of the Parquet files in Amazon S3. Configure Glue Studio jobs to run these transformations without writing code. Share the job definitions with team members for reuse. Use the visual job editor to track transformation progress and inspect profiling statistics for each dataset column
  3. C

    Use AWS Glue DataBrew to visually build transformation workflows on top of the raw Parquet files in S3. Use DataBrew recipes to track, audit, and share the transformation steps with others. Enable data profiling to inspect column statistics, null values, and data types across datasets
  4. D

    Create Amazon Athena SQL queries to perform transformation steps directly on S3. Store queries in AWS Glue Data Catalog and share saved queries with other users through Amazon Athena's query editor
Xem giải thích

Đáp án

C — Dùng AWS Glue DataBrew để dựng quy trình biến đổi trực quan trên tệp Parquet trong S3; dùng DataBrew recipe để theo dõi, kiểm toán và chia sẻ các bước; bật data profiling để xem thống kê cột, giá trị rỗng và kiểu dữ liệu.

Vì sao đúng

Đề nêu năm yêu cầu, và DataBrew được thiết kế cho đúng tất cả: | Yêu cầu | Cơ chế | |---|---| | Giao diện KHÔNG CẦN VIẾT MÃ | DataBrew là công cụ trực quan hoàn toàn | | Kỹ sư dữ liệu VÀ nhà phân tích cùng cộng tác | giao diện dùng được bởi người không lập trình | | Theo dõi nguồn gốc dữ liệu (lineage) | recipe ghi lại mọi bước biến đổi | | Khả năng lập hồ sơ dữ liệu (profiling) | tính năng dựng sẵn | | Chia sẻ logic biến đổi mà không viết mã | recipe xuất và tái dùng được |

AWS Glue DataBrew là gì:

Công cụ chuẩn bị dữ liệu TRỰC QUAN:
    → hơn 250 phép biến đổi dựng sẵn
    → lọc, chuẩn hoá ngày tháng, tổng hợp, loại bỏ ngoại lai
    → không viết một dòng mã nào

Và ba phép biến đổi mà đề nêu đều có sẵn: | Phép biến đổi trong đề | Trong DataBrew | |---|---| | Lọc bất thường (anomaly filtering) | phép loại ngoại lai dựng sẵn | | Chuẩn hoá ngày giờ | phép chuẩn hoá định dạng ngày | | Tổng hợp theo nhóm bệnh nhân | group by và aggregate |

Recipe là thứ đáp ứng vế "lineage" và "chia sẻ":

Recipe = danh sách có thứ tự các bước biến đổi
    → phiên bản hoá được
    → xuất ra JSON hoặc YAML
    → chia sẻ giữa các đội
    → chạy lại trên tập dữ liệu khác
        ↓
    Đó chính là "track, audit, and share the transformation steps"

Và data profiling cho thống kê chi tiết:

DataBrew profile job trả về:
    ✓ số giá trị rỗng và duy nhất mỗi cột
    ✓ phân bố giá trị, min, max, trung bình, trung vị
    ✓ tương quan giữa các cột
    ✓ phát hiện dữ liệu nhạy cảm (PII)

aws databrew create-profile-job --name ho-so-du-lieu-lam-sang   --dataset-name du-lieu-benh-nhan   --output-location Bucket=kho-ket-qua,Key=ho-so/   --role-arn <arn-role>

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

  • **B. Dùng AWS Glue Studio với canvas trực quan — đây là phương án gần nhất và Glue Studio thực sự có giao diện kéo thả, nhưng nó thiếu hai thứ: nó không có tính năng data profiling (thống kê cột, giá trị rỗng), và nó nhắm tới kỹ sư dữ liệu — các phép biến đổi phức tạp vẫn cần viết mã Spark. Nhà phân tích nghiệp vụ khó dùng được.
  • **A. Dùng Amazon AppFlow để di chuyển và biến đổi tệp Parquet trong S3 — sai mục đích dịch vụ: AppFlow là công cụ tích hợp dữ liệu giữa SaaS và AWS (Salesforce, Slack, Google Analytics). Nó có phép ánh xạ đơn giản nhưng không phải công cụ chuẩn bị dữ liệu và không có profiling.
  • **D. Dùng Athena SQL viết truy vấn biến đổi và chia sẻ qua query editor — vi phạm yêu cầu cốt lõi: đề nói rõ cần giao diện KHÔNG CẦN VIẾT MÃ. Athena đòi viết SQL, và không có lineage hay profiling.

Ghi nhớ

Ba công cụ trong họ AWS Glue — bảng phân biệt: | Công cụ | Đối tượng | Viết mã | |---|---|---| | Glue ETL job | kỹ sư dữ liệu | ✅ Spark hoặc Python | | Glue Studio | kỹ sư dữ liệu | kéo thả, nhưng phức tạp thì cần mã | | Glue DataBrew | nhà phân tích VÀ kỹ sư | ❌ hoàn toàn trực quan ← câu này |

Quy tắc nhận diện trong đề thi:

"code-free", "business analysts", "data profiling", "recipe" → Glue DataBrew "visual ETL for engineers", "Spark" → Glue Studio "SQL queries on S3" → Athena "SaaS integration" → AppFlow

Ba khái niệm của DataBrew: | Khái niệm | Việc | |---|---| | Dataset | nguồn dữ liệu (S3, Glue Data Catalog, JDBC) | | Recipe | danh sách bước biến đổi — phiên bản hoá và chia sẻ được | | Job | chạy recipe trên dataset, hoặc chạy profiling |

Hai loại job của DataBrew: | Loại | Việc | |---|---| | Recipe job | áp recipe và ghi kết quả ra đích | | Profile job | phân tích và tạo báo cáo thống kê |

Hơn 250 phép biến đổi của DataBrew — các nhóm chính: | Nhóm | Ví dụ | |---|---| | Làm sạch | xoá giá trị rỗng, loại trùng lặp, cắt khoảng trắng | | Chuẩn hoá | định dạng ngày, chữ hoa chữ thường, đơn vị | | Ngoại lai | phát hiện và xử lý giá trị bất thường | | Tổng hợp | group by, pivot, join | | Che dữ liệu nhạy cảm | hash, mã hoá, thay thế |

Nhóm cuối rất phù hợp với dữ liệu y tế — DataBrew tự phát hiện PII và cho phép che ngay trong recipe.

Ba lợi ích của recipe với việc cộng tác: | Lợi ích | Chi tiết | |---|---| | Ghi lại MỌI bước theo thứ tự | lineage minh bạch, kiểm toán được | | Phiên bản hoá | quay lại phiên bản trước khi cần | | Xuất và tái dùng | áp cho tập dữ liệu khác |

Và với dữ liệu y tế, lineage là yêu cầu tuân thủ:

Kiểm toán viên hỏi: "kết quả này được tính từ dữ liệu nào,
                      qua những bước xử lý gì?"
    → recipe trả lời chính xác câu đó

Ba thông tin mà profile job cung cấp: | Thông tin | Chi tiết | |---|---| | Thống kê cột | min, max, trung bình, trung vị, độ lệch chuẩn | | Chất lượng dữ liệu | số giá trị rỗng, duy nhất, không hợp lệ | | Tương quan | quan hệ giữa các cột | | Phát hiện PII | cột nào chứa thông tin cá nhân |

Ba lưu ý về chi phí DataBrew: | Khoản | Chi tiết | |---|---| | Phiên tương tác | ~1 USD mỗi 30 phút — nhớ đóng khi xong | | Job chạy | theo node-giờ | | Profile job | tính như recipe job |

Phiên tương tác bị quên là chi phí âm thầm — nó tính phí theo thời gian mở, không theo thao tác.

Và DataBrew tích hợp với hệ sinh thái Glue:

Dataset đọc từ Glue Data Catalog
    → dùng chung metadata với Athena, Redshift Spectrum, EMR
Kết quả ghi ra S3 dạng Parquet
    → truy vấn được ngay bằng Athena

Ba nguồn dữ liệu mà DataBrew hỗ trợ: | Nguồn | Định dạng | |---|---| | S3 | CSV, JSON, Parquet, ORC, Excel | | Glue Data Catalog | bảng đã khai báo | | JDBC | RDS, Redshift, Snowflake |

Và Parquet như đề mô tả được hỗ trợ nguyên bản — không cần chuyển đổi trước.

Ba lưu ý khi làm việc với dữ liệu y tế: | Lưu ý | Chi tiết | |---|---| | Ký BAA với AWS | bắt buộc cho PHI | | Mã hoá dữ liệu ở mọi tầng | S3 với SSE-KMS | | Che PII trong recipe | trước khi chia sẻ với nhà phân tích |

Và một lời khuyên về quy trình: hãy để kỹ sư dữ liệu dựng recipe nền (làm sạch, chuẩn hoá, che PII), rồi chia sẻ recipe đó cho nhà phân tích để họ thêm bước tổng hợp riêng. Cách đó vừa đảm bảo dữ liệu nhạy cảm luôn được che, vừa cho nhà phân tích tự chủ với phần nghiệp vụ của họ.

Câu 420 Design High-Performing Architectures

A file-hosting service uses Amazon Simple Storage Service (Amazon S3) under the hood to power its storage offerings. Currently all the customer files are uploaded directly under a single Amazon S3 bucket. The engineering team has started seeing scalability issues where customer file uploads have started failing during the peak access hours with more than 5000 requests per second.

Which of the following is the MOST resource efficient and cost-optimal way of addressing this issue?

  1. A

    Change the application architecture to create customer-specific custom prefixes within the single Amazon S3 bucket and then upload the daily files into those prefixed locations
  2. B

    Change the application architecture to create a new Amazon S3 bucket for each day's data and then upload the daily files directly under that day's bucket
  3. C

    Change the application architecture to create a new Amazon S3 bucket for each customer and then upload each customer's files directly under the respective buckets
  4. D

    Change the application architecture to use Amazon Elastic File System (Amazon EFS) instead of Amazon S3 for storing the customers' uploaded files
Xem giải thích

Đáp án

A — Đổi kiến trúc để tạo prefix riêng cho từng khách hàng trong CÙNG MỘT bucket S3, rồi tải tệp hằng ngày vào các prefix đó.

Vì sao đúng

Đề cho một con số then chốt: hỏng ở mức trên 5.000 request mỗi giây.

Và đó chính xác là hạn mức của S3 — tính THEO PREFIX: | Thao tác | Hạn mức mỗi prefix | |---|---| | GET / HEAD | 5.500 request/giây | | PUT / COPY / POST / DELETE | 3.500 request/giây |

Mấu chốt: hạn mức áp cho PREFIX, không phải cho BUCKET.

Toàn bộ tệp nằm dưới MỘT prefix (gốc bucket):
    → trần 3.500 PUT/giây
    → vượt → lỗi 503 SlowDown

Chia thành 10 prefix theo khách hàng:
    → 10 × 3.500 = 35.000 PUT/giây
    → mở rộng TUYẾN TÍNH theo số prefix

Ví dụ cấu trúc:

s3://kho-tep/khach-hang-001/2026-08-30/tep.dat
s3://kho-tep/khach-hang-002/2026-08-30/tep.dat
s3://kho-tep/khach-hang-003/2026-08-30/tep.dat
        ↑
    mỗi khách hàng = một prefix = một trần hiệu năng riêng

Và vì sao đây là cách "tiết kiệm tài nguyên và chi phí nhất": | Ưu điểm | Chi tiết | |---|---| | Không tạo tài nguyên mới | vẫn một bucket | | Không đụng hạn mức bucket | mặc định 100 bucket mỗi tài khoản | | Chỉ đổi cách đặt tên khoá | thay đổi ở tầng ứng dụng, không phải hạ tầng |

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

  • **C. Tạo một bucket RIÊNG cho mỗi khách hàng — đây là phương án gần nhất và cũng giải quyết được vấn đề hiệu năng, nhưng nó tốn tài nguyên hơn nhiều: hạn mức mặc định là 100 bucket mỗi tài khoản (nâng tối đa 1.000), nên dịch vụ lưu trữ tệp có hàng nghìn khách hàng sẽ đâm vào trần. Và quản lý chính sách, mã hoá, lifecycle cho hàng nghìn bucket là gánh nặng vận hành lớn.
  • **B. Tạo bucket mới cho dữ liệu MỖI NGÀY — cùng vấn đề về số lượng bucket, và còn tệ hơn: 365 bucket mỗi năm, tăng vô hạn theo thời gian.
  • **D. Chuyển sang Amazon EFS thay S3 — đắt hơn rất nhiều và sai bài toán: EFS đắt hơn S3 khoảng 13 lần mỗi GB, và nó là hệ thống tệp NFS chứ không phải kho object phục vụ qua HTTP.

Ghi nhớ

Hạn mức hiệu năng của S3 — con số phải thuộc:

5.500 GET/HEAD mỗi giây  MỖI PREFIX
3.500 PUT/POST/DELETE     MỖI PREFIX
    → KHÔNG có trần cho toàn bucket
    → thêm prefix = thêm thông lượng, tuyến tính

Và có một lời khuyên CŨ hay bị nhắc lại sai:

❌ "Thêm tiền tố NGẪU NHIÊN (hash) vào tên khoá để phân tán partition"
    → LỖI THỜI từ tháng 7 năm 2018
    → S3 giờ TỰ chia partition theo tải

Khác biệt quan trọng: lời khuyên lỗi thời là thêm chuỗi ngẫu nhiên; điều vẫn đúng là dùng nhiều prefix có ý nghĩa để nhân trần hiệu năng. Câu này thuộc vế thứ hai.

Ba cách đặt prefix có ý nghĩa: | Cách | Ví dụ | |---|---| | Theo khách hàng | khach-hang-{id}/ ← câu này | | Theo ngày | nam=2026/thang=08/ngay=30/ | | Theo loại dữ liệu | anh/, video/, log/ |

Cách thứ hai (kiểu Hive partition) còn giúp Athena và Glue quét ít dữ liệu hơn — lợi ích kép.

Ba hạn mức khác của S3 cần nhớ: | Hạn mức | Giá trị | |---|---| | Số bucket mỗi tài khoản | 100 mặc định, tối đa 1.000 | | Kích thước object tối đa | 5 TB | | Kích thước một lần PUT | 5 GB (trên đó phải multipart) | | Số object trong bucket | KHÔNG giới hạn |

Dòng cuối là điểm khiến "một bucket, nhiều prefix" luôn thắng "nhiều bucket".

Ba dấu hiệu đang chạm trần hiệu năng: | Dấu hiệu | Ý nghĩa | |---|---| | HTTP 503 SlowDown | vượt hạn mức request của prefix | | HTTP 500 InternalError | thỉnh thoảng, cần thử lại | | Độ trễ tăng dần | đang tiến gần trần |

Và cách xử lý đúng khi gặp 503:

① Thử lại với exponential backoff (SDK làm sẵn)
② Phân tán tải ra nhiều prefix   ← giải pháp căn bản
③ Dùng S3 Transfer Acceleration nếu nghẽn ở đường truyền

Ba cách tăng tốc tải lên (khác với tăng thông lượng request): | Cách | Giải quyết | |---|---| | Multipart upload | tệp lớn — tải song song nhiều phần | | S3 Transfer Acceleration | khoảng cách địa lý xa | | Nhiều prefix | số request mỗi giây ← câu này |

Ba thứ này giải quyết ba nút thắt khác nhau — nhầm lẫn giữa chúng là lỗi phổ biến.

Và S3 Express One Zone là lựa chọn cho tải rất cao: | Đặc điểm | Chi tiết | |---|---| | Độ trễ thấp hơn Standard tới 10 lần | | | Hàng trăm nghìn request/giây | không có khái niệm trần theo prefix như Standard | | Đổi lại | một AZ, giá lưu trữ cao hơn |

Ba lưu ý khi thiết kế lược đồ khoá: | Lưu ý | Chi tiết | |---|---| | Prefix là mọi thứ trước dấu / cuối cùng | S3 không có thư mục thật | | Đổi lược đồ khoá của dữ liệu CŨ phải sao chép lại | không đổi tên tại chỗ được | | Cân nhắc cả truy vấn tương lai | prefix tốt cho ghi có thể xấu cho phân tích |

Và một lời khuyên: hãy dùng S3 Storage Lens để xem phân bố request theo prefix. Với dịch vụ lưu trữ tệp, thường có vài khách hàng lớn chiếm phần lớn lưu lượng — và họ có thể cần được chia nhỏ thành nhiều prefix con thay vì mỗi người một prefix.